* [PATCH v4 01/10] arm64: KVM: Use static keys for selecting the GIC backend
From: Marc Zyngier @ 2016-09-22 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-2-git-send-email-vladimir.murzin@arm.com>
On 12/09/16 15:49, Vladimir Murzin wrote:
> Currently GIC backend is selected via alternative framework and this
> is fine. We are going to introduce vgic-v3 to 32-bit world and there
> we don't have patching framework in hand, so we can either check
> support for GICv3 every time we need to choose which backend to use or
> try to optimise it by using static keys. The later looks quite
> promising because we can share logic involved in selecting GIC backend
> between architectures if both uses static keys.
>
> This patch moves arm64 from alternative to static keys framework for
> selecting GIC backend. For that we embed static key into vgic_global
> and enable the key during vgic initialisation based on what has
> already been exposed by the host GIC driver.
>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
> arch/arm64/kvm/hyp/switch.c | 21 +++++++++++----------
> include/kvm/arm_vgic.h | 4 ++++
> virt/kvm/arm/vgic/vgic-init.c | 4 ++++
> virt/kvm/arm/vgic/vgic.c | 2 +-
> 4 files changed, 20 insertions(+), 11 deletions(-)
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v4 06/10] KVM: arm: vgic: Support 64-bit data manipulation on 32-bit host systems
From: Marc Zyngier @ 2016-09-22 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-7-git-send-email-vladimir.murzin@arm.com>
On 12/09/16 15:49, Vladimir Murzin wrote:
> We have couple of 64-bit registers defined in GICv3 architecture, so
> unsigned long accesses to these registers will only access a single
> 32-bit part of that regitser. On the other hand these registers can't
> be accessed as 64-bit with a single instruction like ldrd/strd or
> ldmia/stmia if we run a 32-bit host because KVM does not support
> access to MMIO space done by these instructions.
>
> It means that a 32-bit guest accesses these registers in 32-bit
> chunks, so the only thing we need to do is to ensure that
> extract_bytes() always takes 64-bit data.
>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
> virt/kvm/arm/vgic/vgic-mmio-v3.c | 2 +-
> virt/kvm/arm/vgic/vgic-mmio.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v4 07/10] ARM: Introduce MPIDR_LEVEL_SHIFT macro
From: Marc Zyngier @ 2016-09-22 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-8-git-send-email-vladimir.murzin@arm.com>
On 12/09/16 15:49, Vladimir Murzin wrote:
> vgic-v3 driver uses architecture specific MPIDR_LEVEL_SHIFT macro to
> encode the affinity in a form compatible with ICC_SGI* registers.
> Unfortunately, that macro is missing on ARM, so let's add it.
>
> Cc: Russell King <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
> arch/arm/include/asm/cputype.h | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v4 08/10] ARM: Move system register accessors to asm/cp15.h
From: Marc Zyngier @ 2016-09-22 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-9-git-send-email-vladimir.murzin@arm.com>
On 12/09/16 15:49, Vladimir Murzin wrote:
> Headers linux/irqchip/arm-gic.v3.h and arch/arm/include/asm/kvm_hyp.h
> are included in virt/kvm/arm/hyp/vgic-v3-sr.c and both define macros
> called __ACCESS_CP15 and __ACCESS_CP15_64 which obviously creates a
> conflict. These macros were introduced independently for GIC and KVM
> and, in fact, do the same thing.
>
> As an option we could add prefixes to KVM and GIC version of macros so
> they won't clash, but it'd introduce code duplication. Alternatively,
> we could keep macro in, say, GIC header and include it in KVM one (or
> vice versa), but such dependency would not look nicer.
>
> So we follow arm64 way (it handles this via sysreg.h) and move only
> single set of macros to asm/cp15.h
>
> Cc: Russell King <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
> arch/arm/include/asm/arch_gicv3.h | 27 +++++++++++----------------
> arch/arm/include/asm/cp15.h | 15 +++++++++++++++
> arch/arm/include/asm/kvm_hyp.h | 15 +--------------
> 3 files changed, 27 insertions(+), 30 deletions(-)
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v4 10/10] ARM: KVM: Support vgic-v3
From: Marc Zyngier @ 2016-09-22 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-11-git-send-email-vladimir.murzin@arm.com>
On 12/09/16 15:49, Vladimir Murzin wrote:
> This patch allows to build and use vgic-v3 in 32-bit mode.
>
> Unfortunately, it can not be split in several steps without extra
> stubs to keep patches independent and bisectable. For instance,
> virt/kvm/arm/vgic/vgic-v3.c uses function from vgic-v3-sr.c, handling
> access to GICv3 cpu interface from the guest requires vgic_v3.vgic_sre
> to be already defined.
>
> It is how support has been done:
>
> * handle SGI requests from the guest
>
> * report configured SRE on access to GICv3 cpu interface from the guest
>
> * required vgic-v3 macros are provided via uapi.h
>
> * static keys are used to select GIC backend
>
> * to make vgic-v3 build KVM_ARM_VGIC_V3 guard is removed along with
> the static inlines
>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
> arch/arm/include/asm/kvm_asm.h | 3 ++
> arch/arm/include/asm/kvm_host.h | 5 ++++
> arch/arm/include/asm/kvm_hyp.h | 3 ++
> arch/arm/include/uapi/asm/kvm.h | 7 +++++
> arch/arm/kvm/Makefile | 2 ++
> arch/arm/kvm/coproc.c | 35 +++++++++++++++++++++++
> arch/arm/kvm/hyp/Makefile | 1 +
> arch/arm/kvm/hyp/switch.c | 12 ++++++--
> arch/arm64/kvm/Kconfig | 4 ---
> include/kvm/arm_vgic.h | 8 ------
> virt/kvm/arm/vgic/vgic-kvm-device.c | 8 ------
> virt/kvm/arm/vgic/vgic-mmio.c | 2 --
> virt/kvm/arm/vgic/vgic-mmio.h | 2 --
> virt/kvm/arm/vgic/vgic.h | 54 -----------------------------------
> 14 files changed, 66 insertions(+), 80 deletions(-)
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v4 09/10] ARM: gic-v3: Introduce 32-to-64-bit mappings for GICv3 cpu registers
From: Marc Zyngier @ 2016-09-22 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-10-git-send-email-vladimir.murzin@arm.com>
On 12/09/16 15:49, Vladimir Murzin wrote:
> vgic-v3 save/restore routines are written in such way that they map
> arm64 system register naming nicely, but it does not fit to arm
> world. To keep virt/kvm/arm/hyp/vgic-v3-sr.c untouched we create a
> mapping with a function for each register mapping the 32-bit to the
> 64-bit accessors.
>
> Please, note that 64-bit wide ICH_LR is split in two 32-bit halves
> (ICH_LR and ICH_LRC) accessed independently.
>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
> arch/arm/include/asm/arch_gicv3.h | 64 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 64 insertions(+)
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Lorenzo Pieralisi @ 2016-09-22 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921180457.GB20006@localhost>
On Wed, Sep 21, 2016 at 01:04:57PM -0500, Bjorn Helgaas wrote:
> On Wed, Sep 21, 2016 at 03:05:49PM +0100, Lorenzo Pieralisi wrote:
> > On Tue, Sep 20, 2016 at 02:17:44PM -0500, Bjorn Helgaas wrote:
> > > On Tue, Sep 20, 2016 at 04:09:25PM +0100, Ard Biesheuvel wrote:
> >
> > [...]
> >
> > > > None of these platforms can be fixed entirely in software, and given
> > > > that we will not be adding quirks for new broken hardware, we should
> > > > ask ourselves whether having two versions of a quirk, i.e., one for
> > > > broken hardware + currently shipping firmware, and one for the same
> > > > broken hardware with fixed firmware is really an improvement over what
> > > > has been proposed here.
> > >
> > > We're talking about two completely different types of quirks:
> > >
> > > 1) MCFG quirks to use memory-mapped config space that doesn't quite
> > > conform to the ECAM model in the PCIe spec, and
> > >
> > > 2) Some yet-to-be-determined method to describe address space
> > > consumed by a bridge.
> > >
> > > The first two patches of this series are a nice implementation for 1).
> > > The third patch (ThunderX-specific) is one possibility for 2), but I
> > > don't like it because there's no way for generic software like the
> > > ACPI core to discover these resources.
> >
> > Ok, so basically this means that to implement (2) we need to assign
> > some sort of _HID to these quirky PCI bridges (so that we know what
> > device they represent and we can retrieve their _CRS). I take from
> > this discussion that the goal is to make sure that all non-config
> > resources have to be declared through _CRS device objects, which is
> > fine but that requires a FW update (unless we can fabricate ACPI
> > devices and corresponding _CRS in the kernel whenever we match a
> > given MCFG table signature).
>
> All resources consumed by ACPI devices should be declared through
> _CRS. If you want to fabricate ACPI devices or _CRS via kernel
> quirks, that's fine with me. This could be triggered via MCFG
> signature, DMI info, host bridge _HID, etc.
I think the PNP quirk approach + PNP0c02 resource put forward by Gab
is enough.
> > We discussed this already and I think we should make a decision:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414722.html
> >
> > > > > I'd like to step back and come up with some understanding of how
> > > > > non-broken firmware *should* deal with this issue. Then, if we *do*
> > > > > work around this particular broken firmware in the kernel, it would be
> > > > > nice to do it in a way that fits in with that understanding.
> > > > >
> > > > > For example, if a companion ACPI device is the preferred solution, an
> > > > > ACPI quirk could fabricate a device with the required resources. That
> > > > > would address the problem closer to the source and make it more likely
> > > > > that the rest of the system will work correctly: /proc/iomem could
> > > > > make sense, things that look at _CRS generically would work (e.g,
> > > > > /sys/, an admittedly hypothetical "lsacpi", etc.)
> > > > >
> > > > > Hard-coding stuff in drivers is a point solution that doesn't provide
> > > > > any guidance for future platforms and makes it likely that the hack
> > > > > will get copied into even more drivers.
> > > > >
> > > >
> > > > OK, I see. But the guidance for future platforms should be 'do not
> > > > rely on quirks', and what I am arguing here is that the more we polish
> > > > up this code and make it clean and reusable, the more likely it is
> > > > that will end up getting abused by new broken hardware that we set out
> > > > to reject entirely in the first place.
> > > >
> > > > So of course, if the quirk involves claiming resources, let's make
> > > > sure that this occurs in the cleanest and most compliant way possible.
> > > > But any factoring/reuse concerns other than for the current crop of
> > > > broken hardware should be avoided imo.
> > >
> > > If future hardware is completely ECAM-compliant and we don't need any
> > > more MCFG quirks, that would be great.
> >
> > Yes.
> >
> > > But we'll still need to describe that memory-mapped config space
> > > somewhere. If that's done with PNP0C02 or similar devices (as is done
> > > on my x86 laptop), we'd be all set.
> >
> > I am not sure I understand what you mean here. Are you referring
> > to MCFG regions reported as PNP0c02 resources through its _CRS ?
>
> Yes. PCI Firmware Spec r3.0, Table 4-2, note 2 says address ranges
> reported via MCFG or _CBA should be reserved by _CRS of a PNP0C02
> device.
Ok, that's agreed. It goes without saying that since you are quoting
the PCI spec, if FW fails to report MCFG regions in a PNP0c02 device
_CRS I will consider that a FW bug.
> > IIUC PNP0C02 is a reservation mechanism, but it does not help us
> > associate its _CRS to a specific PCI host bridge instance, right ?
>
> Gab proposed a hierarchy that *would* associate a PNP0C02 device with
> a PCI bridge:
>
> Device (PCI1) {
> Name (_HID, "HISI0080") // PCI Express Root Bridge
> Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
> Method (_CRS, 0, Serialized) { // Root complex resources (windows) }
> Device (RES0) {
> Name (_HID, "HISI0081") // HiSi PCIe RC config base address
> Name (_CID, "PNP0C02") // Motherboard reserved resource
> Name (_CRS, ResourceTemplate () { ... }
> }
> }
>
> That's a possibility. The PCI Firmware Spec suggests putting RES0 at
> the root (under \_SB), but I don't know why.
>
> Putting it at the root means we couldn't generically associate it with
> a bridge, although I could imagine something like this:
>
> Device (RES1) {
> Name (_HID, "HISI0081") // HiSi PCIe RC config base address
> Name (_CID, "PNP0C02") // Motherboard reserved resource
> Name (_CRS, ResourceTemplate () { ... }
> Method (BRDG) { "PCI1" } // hand-wavy ASL
> }
> Device (PCI1) {
> Name (_HID, "HISI0080") // PCI Express Root Bridge
> Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
> Method (_CRS, 0, Serialized) { // Root complex resources (windows) }
> }
>
> Where you could search PNP0C02 devices for a cookie that matched the
> host bridge.o
Ok, I am fine with both and I think we are converging, but the way
to solve this problem has to be uniform for all ARM partners (and
not only ARM). Two points here:
1) Adding a device/subdevice allows people to add a _CRS reporting the
non-window bridge resources. Fine. It also allows people to chuck in
there all sorts of _DSD properties to describe their PCI host bridge
as it is done with DT properties (those _DSD can contain eg clocks
etc.), this may be tempting (so that they can reuse the same DT
driver and do not have to update their firmware) but I want to be
clear here: that must not happen. So, a subdevice with a _CRS to
report resources, yes, but it will stop there.
2) It is unclear to me how to formalize the above. People should not
write FW by reading the PCI mailing list, so these guidelines have to
be written, somehow. I do not want to standardize quirks, I want
to prevent random ACPI table content, which is different.
Should I report this to the ACPI spec working group ? If we do
not do that everyone will go solve this problem as they deem fit.
[...]
> > For FW that is immutable I really do not see what we can do apart
> > from hardcoding the non-config resources (consumed by a bridge),
> > somehow.
>
> Right. Well, I assume you mean we should hard-code "non-window
> resources consumed directly by a bridge". If firmware in the field is
> broken, we should work around it, and that may mean hard-coding some
> resources.
>
> My point is that the hard-coding should not be buried in a driver
> where it's invisible to the rest of the kernel. If we hard-code it in
> a quirk that adds _CRS entries, then the kernel will work just like it
> would if the firmware had been correct in the first place. The
> resource will appear in /sys/devices/pnp*/*/resources and /proc/iomem,
> and if we ever used _SRS to assign or move ACPI devices, we would know
> to avoid the bridge resource.
We are in complete agreement here.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCHv2 2/3] tty/serial: at91: fix hardware handshake with GPIOs
From: Greg Kroah-Hartman @ 2016-09-22 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912094733.21501-3-richard.genoud@gmail.com>
On Mon, Sep 12, 2016 at 11:47:32AM +0200, Richard Genoud wrote:
> Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
> hardware handshake is enabled") broke the hardware handshake when GPIOs
> where used.
>
> Hardware handshake with GPIOs used to work before this commit because
> the CRTSCTS flag (termios->c_cflag) was set, but not the
> ATMEL_US_USMODE_HWHS flag (controller register) ; so hardware handshake
> enabled, but not handled by the controller.
>
> This commit restores this behaviour.
>
> NB: -stable is not Cced because it doesn't cleanly apply on 4.1+
> and it will also need previous commit:
> "serial: mctrl_gpio: implement mctrl_gpio_use_rtscts"
>
> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")
> ---
> drivers/tty/serial/atmel_serial.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
This patch doesn't apply to my tree, are you sure it's up to date?
Can you please refresh this whole series against linux-next and resend?
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 2/3] devicetree: bindings: uart: Add new compatible string for ZynqMP
From: Greg KH @ 2016-09-22 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473930931-1034-2-git-send-email-navam@xilinx.com>
On Thu, Sep 15, 2016 at 02:45:30PM +0530, Nava kishore Manne wrote:
> From: Nava kishore Manne <nava.manne@xilinx.com>
>
> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> [stelford at cadence.com: cherry picked from
> https://github.com/Xilinx/linux-xlnx commit
> 37b8a9780766422b2437f5166ddef3767bb60887]
> Signed-off-by: Scott Telford <stelford@cadence.com>
I can't take patches without any changelog comment at all, sorry.
greg k-h
^ permalink raw reply
* [PATCH] tty/serial: atmel: fix fractional baud rate computation
From: Boris Brezillon @ 2016-09-22 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922093904.5b738ad6@bbrezillon>
On Thu, 22 Sep 2016 09:39:04 +0200
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> On Thu, 22 Sep 2016 09:07:46 +0200
> Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> wrote:
>
> > On Wed, Sep 21, 2016 at 12:44:14PM +0200, Nicolas Ferre wrote:
> > > From: Alexey Starikovskiy <aystarik@gmail.com>
> > >
> > > The problem with previous code was it rounded values in wrong
> > > place and produced wrong baud rate in some cases.
> > >
> > > Signed-off-by: Alexey Starikovskiy <aystarik@gmail.com>
> > > [nicolas.ferre at atmel.com: port to newer kernel and add commit log]
> > > Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> > > ---
> > > drivers/tty/serial/atmel_serial.c | 10 ++++++----
> > > include/linux/atmel_serial.h | 1 +
> > > 2 files changed, 7 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> > > index 5f550d9feed9..fd8aa1f4ba78 100644
> > > --- a/drivers/tty/serial/atmel_serial.c
> > > +++ b/drivers/tty/serial/atmel_serial.c
> > > @@ -2170,13 +2170,15 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> > > * accurately. This feature is enabled only when using normal mode.
> > > * baudrate = selected clock / (8 * (2 - OVER) * (CD + FP / 8))
> > > * Currently, OVER is always set to 0 so we get
> > > - * baudrate = selected clock (16 * (CD + FP / 8))
> > > + * baudrate = selected clock / (16 * (CD + FP / 8))
> > > + * then
> > > + * 8 CD + FP = selected clock / (2 * baudrate)
> > > */
> > > if (atmel_port->has_frac_baudrate &&
> > > (mode & ATMEL_US_USMODE) == ATMEL_US_USMODE_NORMAL) {
> > > - div = DIV_ROUND_CLOSEST(port->uartclk, baud);
> > > - cd = div / 16;
> > > - fp = DIV_ROUND_CLOSEST(div % 16, 2);
> > > + div = DIV_ROUND_CLOSEST(port->uartclk, baud * 2);
> > > + cd = div >> 3;
> > > + fp = div & ATMEL_US_FP_MASK;
> >
> > given baud = 115200 and uartclk = 5414300 this results in:
> >
> > div = DIV_ROUND_CLOSEST(5414300, 115200 * 2) = 23
> > cd = 2
> > fp = 7
>
> How about:
>
> div = DIV_ROUND_CLOSEST(port->uartclk, baud);
> cd = div / 16;
> fp = (div % 16) / 2;
>
> best_baud = port->uartclk / ((16 * cd) + (8 * fp));
>
> /* Check if we can get a better approximation by rounding up. */
> if (div % 2) {
> int alt_baud, alt_fp, alt_cd;
>
> alt_fp = fp++;
> alt_cd = cd;
> if (alt_fp > 7) {
> alt_cd++;
> alt_fp = 0;
> }
>
> alt_baud = port->uartclk / ((16 * alt_cd) + (8 *alt_fp));
> if (abs(best_baud - baud) > abs(alt_baud - baud)) {
After a lengthy discussion that happened on IRC (#armlinux), Uwe
proved me wrong. This should actually be
/*
* Calculate the Error in the time domain:
* Error = (RealBaudPeriod - ExpectedBaudPeriod) /
* ExpectedBaudPeriod;
*
* which after conversion to the frequency domain gives:
* Error = 1 - (ExpectedBaudRate/RealBaudRate);
*
* and since we want to compare 2 errors and avoid
* approximation, we have:
*
* if (RealBaudRate2 * (RealBaudRate1 - ExpectedBaudRate) <
* RealBaudRate1 * (RealBaudRate2 - ExpectedBaudRate))
* ...
*
*/
if (alt_baud * abs(best_baud - baud) >
best_baud * abs(alt_baud - baud))
Thanks for your patience ;-).
> best_baud = alt_baud;
> fp = alt_fp;
> cd = alt_cd;
> }
> }
>
> >
> > which yields a rate of 5414300 / 46 = 117702.17. With cd = 3 and fp = 0
> > however the resulting rate is 5414300 / 48 = 112797.92.
> >
> > Which one is better?
> >
> > > } else {
> > > cd = uart_get_divisor(port, baud);
> > > }
> > > diff --git a/include/linux/atmel_serial.h b/include/linux/atmel_serial.h
> > > index f8e452aa48d7..bd2560502f3c 100644
> > > --- a/include/linux/atmel_serial.h
> > > +++ b/include/linux/atmel_serial.h
> > > @@ -119,6 +119,7 @@
> > > #define ATMEL_US_BRGR 0x20 /* Baud Rate Generator Register */
> > > #define ATMEL_US_CD GENMASK(15, 0) /* Clock Divider */
> > > #define ATMEL_US_FP_OFFSET 16 /* Fractional Part */
> > > +#define ATMEL_US_FP_MASK 0x7
> >
> > Is there another user of this header? If not, this can be folded into
> > the driver.
> >
> > Best regards
> > Uwe
> >
>
^ permalink raw reply
* [RESEND PATCH v7 2/2] sdhci-of-arasan: Set controller to test mode when xlnx,fails-without-test-cd is present
From: Ulf Hansson @ 2016-09-22 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474038102-20937-2-git-send-email-zach.brown@ni.com>
On 16 September 2016 at 17:01, Zach Brown <zach.brown@ni.com> wrote:
> The sdhci controller on xilinx zynq devices will not function unless
> the CD bit is provided. http://www.xilinx.com/support/answers/61064.html
> In cases where it is impossible to provide the CD bit in hardware,
> setting the controller to test mode and then setting inserted to true
> will get the controller to function without the CD bit.
>
> When the device has the property xlnx,fails-without-test-cd the driver
> changes the controller to test mode and sets test inserted to true to
> make the controller function.
>
> Signed-off-by: Zach Brown <zach.brown@ni.com>
Thanks, applied for next! I took the liberty to shrink the commit msg
header bit and to add "mmc: " prefix.
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 27 ++++++++++++++++++++++++++-
> drivers/mmc/host/sdhci.h | 2 ++
> 2 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 33601a8..da8e40a 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -26,6 +26,7 @@
> #include <linux/phy/phy.h>
> #include <linux/regmap.h>
> #include "sdhci-pltfm.h"
> +#include <linux/of.h>
>
> #define SDHCI_ARASAN_CLK_CTRL_OFFSET 0x2c
> #define SDHCI_ARASAN_VENDOR_REGISTER 0x78
> @@ -98,6 +99,10 @@ struct sdhci_arasan_data {
>
> struct regmap *soc_ctl_base;
> const struct sdhci_arasan_soc_ctl_map *soc_ctl_map;
> + unsigned int quirks; /* Arasan deviations from spec */
> +
> +/* Controller does not have CD wired and will not function normally without */
> +#define SDHCI_ARASAN_QUIRK_FORCE_CDTEST BIT(0)
> };
>
> static const struct sdhci_arasan_soc_ctl_map rk3399_soc_ctl_map = {
> @@ -245,12 +250,27 @@ static void sdhci_arasan_hs400_enhanced_strobe(struct mmc_host *mmc,
> writel(vendor, host->ioaddr + SDHCI_ARASAN_VENDOR_REGISTER);
> }
>
> +void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
> +{
> + u8 ctrl;
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
> +
> + sdhci_reset(host, mask);
> +
> + if (sdhci_arasan->quirks & SDHCI_ARASAN_QUIRK_FORCE_CDTEST) {
> + ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> + ctrl |= SDHCI_CTRL_CDTEST_INS | SDHCI_CTRL_CDTEST_EN;
> + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> + }
> +}
> +
> static struct sdhci_ops sdhci_arasan_ops = {
> .set_clock = sdhci_arasan_set_clock,
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .get_timeout_clock = sdhci_arasan_get_timeout_clock,
> .set_bus_width = sdhci_set_bus_width,
> - .reset = sdhci_reset,
> + .reset = sdhci_arasan_reset,
> .set_uhs_signaling = sdhci_set_uhs_signaling,
> };
>
> @@ -545,6 +565,7 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> struct sdhci_host *host;
> struct sdhci_pltfm_host *pltfm_host;
> struct sdhci_arasan_data *sdhci_arasan;
> + struct device_node *np = pdev->dev.of_node;
>
> host = sdhci_pltfm_init(pdev, &sdhci_arasan_pdata,
> sizeof(*sdhci_arasan));
> @@ -599,6 +620,10 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> }
>
> sdhci_get_of_property(pdev);
> +
> + if (of_property_read_bool(np, "xlnx,fails-without-test-cd"))
> + sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_FORCE_CDTEST;
> +
> pltfm_host->clk = clk_xin;
>
> if (of_device_is_compatible(pdev->dev.of_node,
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index a2bc9e1..c722cd2 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -84,6 +84,8 @@
> #define SDHCI_CTRL_ADMA32 0x10
> #define SDHCI_CTRL_ADMA64 0x18
> #define SDHCI_CTRL_8BITBUS 0x20
> +#define SDHCI_CTRL_CDTEST_INS 0x40
> +#define SDHCI_CTRL_CDTEST_EN 0x80
>
> #define SDHCI_POWER_CONTROL 0x29
> #define SDHCI_POWER_ON 0x01
> --
> 2.7.4
>
^ permalink raw reply
* [RESEND PATCH v7 1/2] sdhci-of-arasan: Add device tree parameter xlnx,fails-without-test-cd bit
From: Ulf Hansson @ 2016-09-22 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474038102-20937-1-git-send-email-zach.brown@ni.com>
On 16 September 2016 at 17:01, Zach Brown <zach.brown@ni.com> wrote:
> The sdhci controller on xilinx zynq devices will not function unless
> the CD bit is provided. http://www.xilinx.com/support/answers/61064.html
> In cases where it is impossible to provide the CD bit in hardware,
> setting the controller to test mode and then setting inserted to true
> will get the controller to function without the CD bit.
>
> The device property "xlnx,fails-without-test-cd" will let the arasan
> driver know the controller does not have the CD line wired and that the
> controller does not function without it.
>
> Signed-off-by: Zach Brown <zach.brown@ni.com>
Thanks, applied for next! I took the liberty to shrink the commit msg
header bit and to add "dt: " prefix.
Kind regards
Uffe
> ---
> v2:
> * improved commit messages
> * removed fake-cd device property
> * removed fake-cd quirk
> * use broken-cd device property
> * documented new usage of broken-cd
> v3:
> * removed new usage of broken-cd
> * created fails-without-test-cd device property
> * created arasan controller specific quirk
> v4:
> * changed fails-without-test-cd to xlnx-fails-without-test-cd
> * removed extra blank line
> v5:
> * Fixed style mistake
> * Changed (1 << 0 ) to BIT(0)
> v6:
> * Fixed style mistakes
> * Condensed unnecessarily long variable names
> * Removed line wraps that were no longer necessary.
> * Rebased changes off Ulf's mmc tree's next branch.
> v7:
> * Removed erroneous re-creation of Optional Properties section
> * Changed xlnx-fails-without-test-cd to xlnx,fails-without-test-cd
> * Changed of_get_property to of_property_read_bool
>
>
> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> index 3404afa..49df630 100644
> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -36,6 +36,9 @@ Optional Properties:
> - #clock-cells: If specified this should be the value <0>. With this property
> in place we will export a clock representing the Card Clock. This clock
> is expected to be consumed by our PHY. You must also specify
> + - xlnx,fails-without-test-cd: when present, the controller doesn't work when
> + the CD line is not connected properly, and the line is not connected
> + properly. Test mode can be used to force the controller to function.
>
> Example:
> sdhci at e0100000 {
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] PCI: rockchip: fix uninitialized variable use
From: Arnd Bergmann @ 2016-09-22 9:39 UTC (permalink / raw)
To: linux-arm-kernel
The newly added pcie-rockchip driver fails to initialize the
io_size variable if the DT doesn't provide ranges for the PCI
I/O space, as found by building it with -Wmaybe-uninitialized:
drivers/pci/host/pcie-rockchip.c: In function 'rockchip_pcie_probe':
drivers/pci/host/pcie-rockchip.c:1007:6: warning: 'io_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
This adds an appropriate initialization immediately in front of
the loop, so the io_size is zero as expected afterwards for that
case.
Fixes: abe17181b16f ("PCI: rockchip: Add Rockchip PCIe controller support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/pci/host/pcie-rockchip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index c3593e633ccd..8bedc1e1ef80 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -1078,6 +1078,7 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
goto err_vpcie;
/* Get the I/O and memory ranges from DT */
+ io_size = 0;
resource_list_for_each_entry(win, &res) {
switch (resource_type(win->res)) {
case IORESOURCE_IO:
--
2.9.0
^ permalink raw reply related
* [PATCHv2] arm64: Correctly bounds check virt_addr_valid
From: Will Deacon @ 2016-09-22 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474496704-30541-1-git-send-email-labbott@redhat.com>
On Wed, Sep 21, 2016 at 03:25:04PM -0700, Laura Abbott wrote:
>
> virt_addr_valid is supposed to return true if and only if virt_to_page
> returns a valid page structure. The current macro does math on whatever
> address is given and passes that to pfn_valid to verify. vmalloc and
> module addresses can happen to generate a pfn that 'happens' to be
> valid. Fix this by only performing the pfn_valid check on addresses that
> have the potential to be valid.
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v2: Properly parenthesize macro arguments. Re-factor to common macro.
>
> Also in case it wasn't clear, there's no need to try and squeeze this
> into 4.8. Hardened usercopy should have all the checks, this is just for
> full correctness.
Thanks, I'll push this onto for-next/core later today.
Will
^ permalink raw reply
* [PATCH 2/2] net: thunderx: Support for byte queue limits
From: sunil.kovvuri at gmail.com @ 2016-09-22 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474535121-13958-1-git-send-email-sunil.kovvuri@gmail.com>
From: Sunil Goutham <sgoutham@cavium.com>
This patch adds support for byte queue limits
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 11 ++++++--
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 30 ++++++++++++++--------
2 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 7d00162..453e3a0 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -516,7 +516,8 @@ static int nicvf_init_resources(struct nicvf *nic)
static void nicvf_snd_pkt_handler(struct net_device *netdev,
struct cmp_queue *cq,
struct cqe_send_t *cqe_tx,
- int cqe_type, int budget)
+ int cqe_type, int budget,
+ unsigned int *tx_pkts, unsigned int *tx_bytes)
{
struct sk_buff *skb = NULL;
struct nicvf *nic = netdev_priv(netdev);
@@ -547,6 +548,8 @@ static void nicvf_snd_pkt_handler(struct net_device *netdev,
}
nicvf_put_sq_desc(sq, hdr->subdesc_cnt + 1);
prefetch(skb);
+ (*tx_pkts)++;
+ *tx_bytes += skb->len;
napi_consume_skb(skb, budget);
sq->skbuff[cqe_tx->sqe_ptr] = (u64)NULL;
} else {
@@ -662,6 +665,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;
+ unsigned int tx_pkts = 0, tx_bytes = 0;
spin_lock_bh(&cq->lock);
loop:
@@ -701,7 +705,7 @@ loop:
case CQE_TYPE_SEND:
nicvf_snd_pkt_handler(netdev, cq,
(void *)cq_desc, CQE_TYPE_SEND,
- budget);
+ budget, &tx_pkts, &tx_bytes);
tx_done++;
break;
case CQE_TYPE_INVALID:
@@ -730,6 +734,9 @@ done:
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;
if (netif_tx_queue_stopped(txq) && netif_carrier_ok(netdev)) {
netif_tx_start_queue(txq);
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index 178c5c7..a4fc501 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -1082,6 +1082,24 @@ static inline void nicvf_sq_add_cqe_subdesc(struct snd_queue *sq, int qentry,
imm->len = 1;
}
+static inline void nicvf_sq_doorbell(struct nicvf *nic, struct sk_buff *skb,
+ int sq_num, int desc_cnt)
+{
+ struct netdev_queue *txq;
+
+ txq = netdev_get_tx_queue(nic->pnicvf->netdev,
+ skb_get_queue_mapping(skb));
+
+ netdev_tx_sent_queue(txq, skb->len);
+
+ /* make sure all memory stores are done before ringing doorbell */
+ smp_wmb();
+
+ /* Inform HW to xmit all TSO segments */
+ nicvf_queue_reg_write(nic, NIC_QSET_SQ_0_7_DOOR,
+ sq_num, desc_cnt);
+}
+
/* Segment a TSO packet into 'gso_size' segments and append
* them to SQ for transfer
*/
@@ -1141,12 +1159,8 @@ static int nicvf_sq_append_tso(struct nicvf *nic, struct snd_queue *sq,
/* Save SKB in the last segment for freeing */
sq->skbuff[hdr_qentry] = (u64)skb;
- /* make sure all memory stores are done before ringing doorbell */
- smp_wmb();
+ nicvf_sq_doorbell(nic, skb, sq_num, desc_cnt);
- /* Inform HW to xmit all TSO segments */
- nicvf_queue_reg_write(nic, NIC_QSET_SQ_0_7_DOOR,
- sq_num, desc_cnt);
nic->drv_stats.tx_tso++;
return 1;
}
@@ -1219,12 +1233,8 @@ doorbell:
nicvf_sq_add_cqe_subdesc(sq, qentry, tso_sqe, skb);
}
- /* make sure all memory stores are done before ringing doorbell */
- smp_wmb();
+ nicvf_sq_doorbell(nic, skb, sq_num, subdesc_cnt);
- /* Inform HW to xmit new packet */
- nicvf_queue_reg_write(nic, NIC_QSET_SQ_0_7_DOOR,
- sq_num, subdesc_cnt);
return 1;
append_fail:
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] net: thunderx: Fix issue with IRQ namimg
From: sunil.kovvuri at gmail.com @ 2016-09-22 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474535121-13958-1-git-send-email-sunil.kovvuri@gmail.com>
From: Sunil Goutham <sgoutham@cavium.com>
This patch fixes a regression caused by previous commit
'Use netdev's name for naming VF's interrupts' where
irq name exceeds 20 byte array if interface's name size
is large.
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
index 18d12d3..3042610 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -305,7 +305,7 @@ struct nicvf {
bool msix_enabled;
u8 num_vec;
struct msix_entry msix_entries[NIC_VF_MSIX_VECTORS];
- char irq_name[NIC_VF_MSIX_VECTORS][20];
+ char irq_name[NIC_VF_MSIX_VECTORS][IFNAMSIZ + 15];
bool irq_allocated[NIC_VF_MSIX_VECTORS];
cpumask_var_t affinity_mask[NIC_VF_MSIX_VECTORS];
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] BQL support and fix for a regression issue
From: sunil.kovvuri at gmail.com @ 2016-09-22 9:05 UTC (permalink / raw)
To: linux-arm-kernel
From: Sunil Goutham <sgoutham@cavium.com>
These patches add byte queue limit support and also fixes a regression
issue introduced by commit
'net: thunderx: Use netdev's name for naming VF's interrupts'
Sunil Goutham (2):
net: thunderx: Fix issue with IRQ namimg
net: thunderx: Support for byte queue limits
drivers/net/ethernet/cavium/thunder/nic.h | 2 +-
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 11 ++++++--
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 30 ++++++++++++++--------
3 files changed, 30 insertions(+), 13 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2] drivers: psci: PSCI checker module
From: Lorenzo Pieralisi @ 2016-09-22 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hfuothzff.fsf@baylibre.com>
On Wed, Sep 21, 2016 at 11:37:24AM -0700, Kevin Hilman wrote:
> Kevin Brodsky <kevin.brodsky@arm.com> writes:
>
> > On arm and arm64, PSCI is one of the possible firmware interfaces
> > used for power management. This includes both turning CPUs on and off,
> > and suspending them (entering idle states).
> >
> > This patch adds a PSCI checker module that enables basic testing of
> > PSCI operations during startup. There are two main tests: CPU
> > hotplugging and suspending.
> >
> > In the hotplug tests, the hotplug API is used to turn off and on again
> > all CPUs in the system, and then all CPUs in each cluster, checking
> > the consistency of the return codes.
> >
> > In the suspend tests, a high-priority thread is created on each core
> > and uses low-level cpuidle functionalities to enter suspend, in all
> > the possible states and multiple times. This should allow a maximum
> > number of CPUs to enter the same sleep state at the same or slightly
> > different time.
>
> Since you're doing it multiple times, it might be useful to track the
> actual time it takes to suspend and wakeup, and possibly even warn
> if the time is longer than the target_residency. This could catch
> poorly configured idle states.
That's a good point, we can add a couple of checks for latencies on top
of the existing code, we will definitely do, at the moment we are
concerned with the overall design in particular in relation to usage of
high priority threads and tick broadcast to test the PSCI suspend
interface.
Thank you for having a look !
Lorenzo
^ permalink raw reply
* ftrace function_graph causes system crash
From: Bean Huo (beanhuo) @ 2016-09-22 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921141705.6ab0be03@gandalf.local.home>
> -----Original Message-----
> From: Steven Rostedt [mailto:rostedt at goodmis.org]
> Sent: Mittwoch, 21. September 2016 20:17
> To: Jisheng Zhang <jszhang@marvell.com>
> Cc: Bean Huo (beanhuo) <beanhuo@micron.com>; Zoltan Szubbocsev
> (zszubbocsev) <zszubbocsev@micron.com>; catalin.marinas at arm.com;
> will.deacon at arm.com; rfi at lists.rocketboards.org; linux-
> kernel at vger.kernel.org; mingo at redhat.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: ftrace function_graph causes system crash
>
> On Wed, 21 Sep 2016 17:13:07 +0800
> Jisheng Zhang <jszhang@marvell.com> wrote:
>
> > I'm not sure whether the commit d6df3576e6b4
> ("clocksource/drivers/arm_global_timer
> > : Prevent ftrace recursion") can fix this issue.
> >
> > this commit is merged since v4.3, I noticed your kernel version is v4.0
>
> BTW, yes, that would be the fix.
>
> -- Steve
>
> >
> > Thanks,
> > Jisheng
> >
> > > Do you know now how to deeply debug and trace which line is wrong
> through Ftrace?
> > >
Hi, Steven and Jisheng
Thanks to both warm-hearted guys. I merged d6df3576e6b4 patch into my kernel 4.0.
Then it is true, no cash appears again.
I have one more question that current ftrace can trace DMA latency, include mapping and unmapping?
Means I want to know when one BIO request be completed. Just like blktrace.
But blktrace can not tell me the function calling sequence.
--Bean
^ permalink raw reply
* [PATCH v6 4/4] arm/arm64: arch_timer: Use archdata to indicate vdso suitability
From: Scott Wood @ 2016-09-22 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-1-git-send-email-oss@buserror.net>
Instead of comparing the name to a magic string, use archdata to
explicitly communicate whether the arch timer is suitable for
direct vdso access.
Signed-off-by: Scott Wood <oss@buserror.net>
Acked-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/clocksource.h | 8 ++++++++
arch/arm/kernel/vdso.c | 2 +-
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/clocksource.h | 8 ++++++++
arch/arm64/kernel/vdso.c | 2 +-
drivers/clocksource/arm_arch_timer.c | 11 +++--------
7 files changed, 23 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/include/asm/clocksource.h
create mode 100644 arch/arm64/include/asm/clocksource.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a9c4e48..b2113c2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1,6 +1,7 @@
config ARM
bool
default y
+ select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/arm/include/asm/clocksource.h b/arch/arm/include/asm/clocksource.h
new file mode 100644
index 0000000..0b350a7
--- /dev/null
+++ b/arch/arm/include/asm/clocksource.h
@@ -0,0 +1,8 @@
+#ifndef _ASM_CLOCKSOURCE_H
+#define _ASM_CLOCKSOURCE_H
+
+struct arch_clocksource_data {
+ bool vdso_direct; /* Usable for direct VDSO access? */
+};
+
+#endif
diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index 994e971..a0affd1 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -270,7 +270,7 @@ static bool tk_is_cntvct(const struct timekeeper *tk)
if (!IS_ENABLED(CONFIG_ARM_ARCH_TIMER))
return false;
- if (strcmp(tk->tkr_mono.clock->name, "arch_sys_counter") != 0)
+ if (!tk->tkr_mono.clock->archdata.vdso_direct)
return false;
return true;
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0e11c8a..8f868ec 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -4,6 +4,7 @@ config ARM64
select ACPI_GENERIC_GSI if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ACPI_MCFG if ACPI
+ select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
diff --git a/arch/arm64/include/asm/clocksource.h b/arch/arm64/include/asm/clocksource.h
new file mode 100644
index 0000000..0b350a7
--- /dev/null
+++ b/arch/arm64/include/asm/clocksource.h
@@ -0,0 +1,8 @@
+#ifndef _ASM_CLOCKSOURCE_H
+#define _ASM_CLOCKSOURCE_H
+
+struct arch_clocksource_data {
+ bool vdso_direct; /* Usable for direct VDSO access? */
+};
+
+#endif
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 6225612..a2c2478 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -201,7 +201,7 @@ up_fail:
*/
void update_vsyscall(struct timekeeper *tk)
{
- u32 use_syscall = strcmp(tk->tkr_mono.clock->name, "arch_sys_counter");
+ u32 use_syscall = !tk->tkr_mono.clock->archdata.vdso_direct;
++vdso_data->tb_seq_count;
smp_wmb();
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index eb5fb41..73c487d 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -602,23 +602,18 @@ static void __init arch_counter_register(unsigned type)
else
arch_timer_read_counter = arch_counter_get_cntpct;
+ clocksource_counter.archdata.vdso_direct = true;
+
#ifdef CONFIG_FSL_ERRATUM_A008585
/*
* Don't use the vdso fastpath if errata require using
* the out-of-line counter accessor.
*/
if (static_branch_unlikely(&arch_timer_read_ool_enabled))
- clocksource_counter.name = "arch_sys_counter_ool";
+ clocksource_counter.archdata.vdso_direct = false;
#endif
} else {
arch_timer_read_counter = arch_counter_get_cntvct_mem;
-
- /* If the clocksource name is "arch_sys_counter" the
- * VDSO will attempt to read the CP15-based counter.
- * Ensure this does not happen when CP15-based
- * counter is not available.
- */
- clocksource_counter.name = "arch_mem_counter";
}
start_count = arch_timer_read_counter();
--
2.7.4
^ permalink raw reply related
* [PATCH v6 3/4] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Scott Wood @ 2016-09-22 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-1-git-send-email-oss@buserror.net>
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) \
+({ \
+ u64 _val; \
+ if (needs_fsl_a008585_workaround()) \
+ _val = __fsl_a008585_read_##reg(); \
+ else \
+ _val = read_sysreg(reg); \
+ _val; \
+})
+
/*
* These register accessors are marked inline so the compiler can
* nicely work out which register we want, and chuck away the rest of
@@ -67,14 +108,14 @@ u32 arch_timer_reg_read_cp15(int access, enum arch_timer_reg reg)
case ARCH_TIMER_REG_CTRL:
return read_sysreg(cntp_ctl_el0);
case ARCH_TIMER_REG_TVAL:
- return read_sysreg(cntp_tval_el0);
+ return arch_timer_unstable_reg_read(cntp_tval_el0);
}
} else if (access == ARCH_TIMER_VIRT_ACCESS) {
switch (reg) {
case ARCH_TIMER_REG_CTRL:
return read_sysreg(cntv_ctl_el0);
case ARCH_TIMER_REG_TVAL:
- return read_sysreg(cntv_tval_el0);
+ return arch_timer_unstable_reg_read(cntv_tval_el0);
}
}
@@ -108,7 +149,7 @@ static inline u64 arch_counter_get_cntpct(void)
static inline u64 arch_counter_get_cntvct(void)
{
isb();
- return read_sysreg(cntvct_el0);
+ return arch_timer_unstable_reg_read(cntvct_el0);
}
static inline int arch_timer_arch_init(void)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 5677886..8a753fd 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -305,6 +305,16 @@ config ARM_ARCH_TIMER_EVTSTREAM
This must be disabled for hardware validation purposes to detect any
hardware anomalies of missing events.
+config FSL_ERRATUM_A008585
+ bool "Workaround for Freescale/NXP Erratum A-008585"
+ default y
+ depends on ARM_ARCH_TIMER && ARM64
+ help
+ This option enables a workaround for Freescale/NXP Erratum
+ A-008585 ("ARM generic timer may contain an erroneous
+ value"). The workaround will only be active if the
+ fsl,erratum-a008585 property is found in the timer node.
+
config ARM_GLOBAL_TIMER
bool "Support for the ARM global timer" if COMPILE_TEST
select CLKSRC_OF if OF
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 5770054..eb5fb41 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -94,6 +94,43 @@ early_param("clocksource.arm_arch_timer.evtstrm", early_evtstrm_cfg);
* Architected system timer support.
*/
+#ifdef CONFIG_FSL_ERRATUM_A008585
+DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
+EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
+
+static int fsl_a008585_enable = -1;
+
+static int __init early_fsl_a008585_cfg(char *buf)
+{
+ int ret;
+ bool val;
+
+ ret = strtobool(buf, &val);
+ if (ret)
+ return ret;
+
+ fsl_a008585_enable = val;
+ return 0;
+}
+early_param("clocksource.arm_arch_timer.fsl-a008585", early_fsl_a008585_cfg);
+
+u32 __fsl_a008585_read_cntp_tval_el0(void)
+{
+ return __fsl_a008585_read_reg(cntp_tval_el0);
+}
+
+u32 __fsl_a008585_read_cntv_tval_el0(void)
+{
+ return __fsl_a008585_read_reg(cntv_tval_el0);
+}
+
+u64 __fsl_a008585_read_cntvct_el0(void)
+{
+ return __fsl_a008585_read_reg(cntvct_el0);
+}
+EXPORT_SYMBOL(__fsl_a008585_read_cntvct_el0);
+#endif /* CONFIG_FSL_ERRATUM_A008585 */
+
static __always_inline
void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val,
struct clock_event_device *clk)
@@ -243,6 +280,40 @@ static __always_inline void set_next_event(const int access, unsigned long evt,
arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
}
+#ifdef CONFIG_FSL_ERRATUM_A008585
+static __always_inline void fsl_a008585_set_next_event(const int access,
+ unsigned long evt, struct clock_event_device *clk)
+{
+ unsigned long ctrl;
+ u64 cval = evt + arch_counter_get_cntvct();
+
+ ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, clk);
+ ctrl |= ARCH_TIMER_CTRL_ENABLE;
+ ctrl &= ~ARCH_TIMER_CTRL_IT_MASK;
+
+ if (access == ARCH_TIMER_PHYS_ACCESS)
+ write_sysreg(cval, cntp_cval_el0);
+ else if (access == ARCH_TIMER_VIRT_ACCESS)
+ write_sysreg(cval, cntv_cval_el0);
+
+ arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
+}
+
+static int fsl_a008585_set_next_event_virt(unsigned long evt,
+ struct clock_event_device *clk)
+{
+ fsl_a008585_set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
+ return 0;
+}
+
+static int fsl_a008585_set_next_event_phys(unsigned long evt,
+ struct clock_event_device *clk)
+{
+ fsl_a008585_set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
+ return 0;
+}
+#endif /* CONFIG_FSL_ERRATUM_A008585 */
+
static int arch_timer_set_next_event_virt(unsigned long evt,
struct clock_event_device *clk)
{
@@ -271,6 +342,19 @@ static int arch_timer_set_next_event_phys_mem(unsigned long evt,
return 0;
}
+static void fsl_a008585_set_sne(struct clock_event_device *clk)
+{
+#ifdef CONFIG_FSL_ERRATUM_A008585
+ if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
+ return;
+
+ if (arch_timer_uses_ppi == VIRT_PPI)
+ clk->set_next_event = fsl_a008585_set_next_event_virt;
+ else
+ clk->set_next_event = fsl_a008585_set_next_event_phys;
+#endif
+}
+
static void __arch_timer_setup(unsigned type,
struct clock_event_device *clk)
{
@@ -299,6 +383,8 @@ static void __arch_timer_setup(unsigned type,
default:
BUG();
}
+
+ fsl_a008585_set_sne(clk);
} else {
clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
clk->name = "arch_mem_timer";
@@ -515,6 +601,15 @@ static void __init arch_counter_register(unsigned type)
arch_timer_read_counter = arch_counter_get_cntvct;
else
arch_timer_read_counter = arch_counter_get_cntpct;
+
+#ifdef CONFIG_FSL_ERRATUM_A008585
+ /*
+ * Don't use the vdso fastpath if errata require using
+ * the out-of-line counter accessor.
+ */
+ if (static_branch_unlikely(&arch_timer_read_ool_enabled))
+ clocksource_counter.name = "arch_sys_counter_ool";
+#endif
} else {
arch_timer_read_counter = arch_counter_get_cntvct_mem;
@@ -800,6 +895,15 @@ static int __init arch_timer_of_init(struct device_node *np)
arch_timer_c3stop = !of_property_read_bool(np, "always-on");
+#ifdef CONFIG_FSL_ERRATUM_A008585
+ if (fsl_a008585_enable < 0)
+ fsl_a008585_enable = of_property_read_bool(np, "fsl,erratum-a008585");
+ if (fsl_a008585_enable) {
+ static_branch_enable(&arch_timer_read_ool_enabled);
+ pr_info("Enabling workaround for FSL erratum A-008585\n");
+ }
+#endif
+
/*
* If we cannot rely on firmware initializing the timer registers then
* we should use the physical timers instead.
--
2.7.4
^ permalink raw reply related
* [PATCH v6 2/4] arm64: dts: Add timer erratum property for LS2080A and LS1043A
From: Scott Wood @ 2016-09-22 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-1-git-send-email-oss@buserror.net>
Signed-off-by: Scott Wood <oss@buserror.net>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index e669fbd..952531d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -123,6 +123,7 @@
<1 14 0x1>, /* Physical Non-Secure PPI */
<1 11 0x1>, /* Virtual PPI */
<1 10 0x1>; /* Hypervisor PPI */
+ fsl,erratum-a008585;
};
pmu {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 21023a3..9d3ac19 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -195,6 +195,7 @@
<1 14 0x8>, /* Physical Non-Secure PPI, active-low */
<1 11 0x8>, /* Virtual PPI, active-low */
<1 10 0x8>; /* Hypervisor PPI, active-low */
+ fsl,erratum-a008585;
};
pmu {
--
2.7.4
^ permalink raw reply related
* [PATCH v6 1/4] arm64: arch_timer: Add device tree binding for A-008585 erratum
From: Scott Wood @ 2016-09-22 8:35 UTC (permalink / raw)
To: linux-arm-kernel
This erratum describes a bug in logic outside the core, so MIDR can't be
used to identify its presence, and reading an SoC-specific revision
register from common arch timer code would be awkward. So, describe it
in the device tree.
Signed-off-by: Scott Wood <oss@buserror.net>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
index e774128..ef5fbe9 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -25,6 +25,12 @@ to deliver its interrupts via SPIs.
- always-on : a boolean property. If present, the timer is powered through an
always-on power domain, therefore it never loses context.
+- fsl,erratum-a008585 : A boolean property. Indicates the presence of
+ QorIQ erratum A-008585, which says that reading the counter is
+ unreliable unless the same value is returned by back-to-back reads.
+ This also affects writes to the tval register, due to the implicit
+ counter read.
+
** Optional properties:
- arm,cpu-registers-not-fw-configured : Firmware does not initialize
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Scott Wood @ 2016-09-22 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920093503.GA1045@leverpostej>
On Tue, 2016-09-20 at 10:35 +0100, Mark Rutland wrote:
> On Mon, Sep 19, 2016 at 02:16:00PM -0500, Scott Wood wrote:
> >
> > On Mon, 2016-09-19 at 18:07 +0100, Mark Rutland wrote:
> > >
> > > >
> > > > >
> > > > > Reconsidering my suggestion, I realise this will also affect the
> > > > > MMIO
> > > > > timers, so that doesn't work.
> > > > >
> > > > > So for the moment, I guess we have to keep
> > > > > fsl_a008585_set_next_event().
> > > > What is the problem with MMIO timers? ?needs_fsl_a008585_workaround()
> > > > should
> > > > always be false for them.
> > > As suggested, needs_fsl_a008585_workaround() takes no parameter, and
> > > set_next_event is called for both cp15/sysreg and MMIO timers. So it
> > > would either be true for all, or false for all.
> > >
> > > If it's true for all, we'd end up calling fsl_a008585_set_next_event()
> > > for the MMIO timers too.
> > There should not be any MMIO timers on a system where
> > fsl_a008585_set_next_event() returns true.
> I'm generally not keen on relying on that.
>
> For reference, are no MMIO timers implemented at all, or are they simply
> not listed in the DT today?
As far as I can tell they're not implemented, but it's possible I'm just not
looking at the right documentation. ?
I agree though that depending on that isn't particularly pretty. ?I'll stick
with the current approach for set_next_event().
-Scott
^ permalink raw reply
* [PATCH v5 0/3] ASoC: sun4i-codec: Distinguish sun4i from sun7i
From: Maxime Ripard @ 2016-09-22 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922071313.12891-1-dannym@scratchpost.org>
Hi,
On Thu, Sep 22, 2016 at 09:13:10AM +0200, Danny Milosavljevic wrote:
> ASoC: sun4i-codec: Introduce mechanism to detect sun7i and provide a
> different regmap different compared to sun4i Allwinner A10.
>
> The controls will be extended in a forthcoming patch - it is necessary
> to distinguish between sun4i and sun7i controls because they have different
> registers.
>
> Renamed SUN4I_CODEC_AC_SYS_VERI to SUN7I_CODEC_AC_DAC_CAL and renamed
> SUN4I_CODEC_AC_MIC_PHONE_CAL to SUN7I_CODEC_AC_MIC_PHONE_CAL because these
> are actually not present on Allwinner A10.
>
> Handle quirks by regmap config and codec and select the correct quirks
> automatically.
Usually, you would set the history of changes from one version to the
other here.
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/20160922/2b5924b5/attachment.sig>
^ 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