* [GIT PULL 4/4] arm64: tegra: Device tree changes for v4.12-rc1
From: Thierry Reding @ 2017-04-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419131905.GD29219@localhost>
On Wed, Apr 19, 2017 at 06:19:05AM -0700, Olof Johansson wrote:
> On Fri, Apr 07, 2017 at 01:10:20AM +0200, Thierry Reding wrote:
> > Hi ARM SoC maintainers,
> >
> > The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
> >
> > Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.12-arm64-dt
> >
> > for you to fetch changes up to 18236a14883b718ce973e4c090db6ecb49b38287:
> >
> > arm64: tegra: Update the Tegra132 flowctrl compatible string (2017-04-04 17:15:05 +0200)
> >
> > Thanks,
> > Thierry
> >
> > ----------------------------------------------------------------
> > arm64: tegra: Device tree changes for v4.12-rc1
> >
> > This adds a bunch of features for Tegra186, such as PMC, ethernet, I2C,
> > SDHCI and GPIO. It also enables various features on the P2771 devkit.
> >
> > A small fix is made to the compatible string list for the flow
> > controller on Tegra132 and the IOMMU is enabled for host1x on Tegra210.
>
> Nice, merged. Any chance we'll see Jetson TX2 support for 4.13?
P2771 *is* Jetson TX2. I suppose I could go and update the DTS file and
clarify that in the model string.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170419/7a32be7d/attachment.sig>
^ permalink raw reply
* [GIT PULL] ARM: mvebu: defconfig64 for v4.12 (#2)
From: Gregory CLEMENT @ 2017-04-19 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419140720.GP29219@localhost>
Hi Olof,
On mer., avril 19 2017, Olof Johansson <olof@lixom.net> wrote:
> On Thu, Apr 13, 2017 at 06:25:28PM +0200, Gregory CLEMENT wrote:
>> Hi,
>>
>> Here is the second pull request for defconfig64 for mvebu for v4.12.
>> There is a trivial merge conflict already solved by Stephen Rothwell
>> there:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/500998.html
>>
>> Gregory
>>
>> The following changes since commit 66e56302842e9971426bd7e504c4db4f88cbb037:
>>
>> arm64: defconfig: enable MVPP2 (2017-03-23 17:50:13 +0100)
>>
>> are available in the git repository at:
>>
>> git://git.infradead.org/linux-mvebu.git tags/mvebu-defconfig64-4.12-2
>>
>> for you to fetch changes up to 10ebb57ffcbf062ff224585fefa274e703fc363d:
>>
>> arm64: defconfig: enable the Safexcel crypto engine as a module (2017-04-12 15:35:16 +0200)
>>
>> ----------------------------------------------------------------
>> mvebu defconfig64 for 4.12 (part 2)
>>
>> Select two new drivers for ARM64 mvebu SoCs:
>> - Xenon SDHCI controller on Armada 37xx and Armada 7K/8K
>> - Safexcel crypto engine on Armada 7K/8K
>>
>> ----------------------------------------------------------------
>> Antoine Tenart (1):
>> arm64: defconfig: enable the Safexcel crypto engine as a module
>>
>> Gregory CLEMENT (1):
>> arm64: configs: enable SDHCI driver for Xenon
>
> Merged, thanks!
>
> Please keep an eye on patch prefixes for consistency in the future.
OK I will do it.
Thanks,
Gregory
>
>
> -Olof
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v24 08/11] acpi: Introduce acpi_unregister_irq function
From: Mark Rutland @ 2017-04-19 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418155841.GK17866@leverpostej>
On Tue, Apr 18, 2017 at 04:58:41PM +0100, Mark Rutland wrote:
> On Sat, Apr 15, 2017 at 02:40:11AM +0800, fu.wei at linaro.org wrote:
> > From: Fu Wei <fu.wei@linaro.org>
> >
> > This patch introduces acpi_unregister_irq function to free a
> > linux IRQ number<->GSI mapping by a given linux IRQ number.
> >
> > Even we have successfully registered the GSI, when some error occurs, we
> > may need to unmap it for freeing the IRQ resource. But in some cases, we
> > only have IRQ, but not GSI.
> >
> > This patch is the preparation for memory-mapped timer support in GTDT
> > driver.
> >
> > Signed-off-by: Fu Wei <fu.wei@linaro.org>
> > ---
> > drivers/acpi/irq.c | 10 ++++++++++
> > include/linux/acpi.h | 7 +++++++
> > 2 files changed, 17 insertions(+)
>
> This will need comments/acks from the ACPI folk.
I've now reworked the cleanup to not require this API, and will drop
this patch.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v6 6/8] coresight: add support for CPU debug module
From: Leo Yan @ 2017-04-19 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f42088f6-aa53-06b1-b332-22198744ab7a@arm.com>
On Wed, Apr 19, 2017 at 03:32:39PM +0100, Suzuki K Poulose wrote:
[...]
> >>>+static int debug_probe(struct amba_device *adev, const struct amba_id *id)
> >>>+{
> >>>+ void __iomem *base;
> >>>+ struct device *dev = &adev->dev;
> >>>+ struct debug_drvdata *drvdata;
> >>>+ struct resource *res = &adev->res;
> >>>+ struct device_node *np = adev->dev.of_node;
> >>>+ int ret;
> >>>+
> >>>+ drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> >>>+ if (!drvdata)
> >>>+ return -ENOMEM;
> >>>+
> >>>+ drvdata->cpu = np ? of_coresight_get_cpu(np) : 0;
> >>>+ if (per_cpu(debug_drvdata, drvdata->cpu)) {
> >>>+ dev_err(dev, "CPU%d drvdata has been initialized\n",
> >>>+ drvdata->cpu);
> >>
> >>May be we could warn about a possible issue in the DT ?
> >
> >So can I understand the suggestion is to add warning in function
> >of_coresight_get_cpu() when cannot find CPU number, and here directly
> >bail out?
>
> No. One could have single CPU DT, where he doesn't need to provide the CPU number.
> Hence, it doesn't make sense to WARN in of_coresight_get_cpu().
>
> But when we hit the case above, we find that the some node was registered for
> the given CPU (be it 0 or any other), which is definitely an error in DT. Due to
>
> 1) Hasn't specified the CPU number for more than one node
>
> OR
>
> 2) CPU number duplicated in the more than one nodes.
Thanks for explaination. It's clear for me now.
> Cheers
> Suzuki
^ permalink raw reply
* [PATCH v24 09/11] acpi/arm64: Add memory-mapped timer support in GTDT driver
From: Mark Rutland @ 2017-04-19 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418172107.GA1401@red-moon>
On Tue, Apr 18, 2017 at 06:21:07PM +0100, Lorenzo Pieralisi wrote:
> On Sat, Apr 15, 2017 at 02:40:12AM +0800, fu.wei at linaro.org wrote:
> > +error:
> > + for (i = 0; i < ARCH_TIMER_MEM_MAX_FRAMES; i++) {
> > + frame = &timer_mem->frame[i];
> > + if (frame->phys_irq > 0)
> > + acpi_unregister_irq(frame->phys_irq);
> > + if (frame->virt_irq > 0)
> > + acpi_unregister_irq(frame->virt_irq);
> > + }
>
> There are three error paths, none of them reset [i,gtdt_frame],
> correct ?
Correct.
> If yes, why can't it simply be written like this ?
>
> for (; i >= 0; i--, gtdt_frame--) {
> frame = &timer_mem->frame[gtdt_frame->frame_number];
>
> /* not sure this check is actually needed */
> if (gtdt_frame->common_flags & ACPI_GTDT_GT_IS_SECURE_TIMER)
> continue;
>
> if (frame->phys_irq > 0)
> acpi_unregister_gsi(gtdt_frame->timer_interrupt);
> if (frame->virt_irq > 0)
> acpi_unregister_gsi(gtdt_frame->virtual_timer_interrupt);
> }
A reverse loop of this form will work.
That requires some restructuring, and care to avoid going out of bounds
instantaneously with the gtdt_frame--, so as to not invoke nasal demons.
I've attacked this locally, and will send this out after testing. I'll
drop the new ACPI API patch.
Thanks,
Mark.
^ permalink raw reply
* [GIT PULL] arm64: dts: hisilicon dts updates for v4.12
From: Wei Xu @ 2017-04-19 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419132420.GK29219@localhost>
Hi Olof,
On 2017/4/19 14:24, Olof Johansson wrote:
> On Mon, Apr 10, 2017 at 04:44:33PM +0100, Wei Xu wrote:
>> Hi Arnd, Hi Olof, Hi Kevin,
>>
>> Please help to pull the following changes.
>> Thanks!
>>
>> Best Regards,
>> Wei
>>
>> ---
>> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>>
>> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>>
>> are available in the git repository at:
>>
>> git://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-dt-for-4.12
>>
>> for you to fetch changes up to d4e1eaeee56894f45d0093f9d432be0c868f7c4c:
>>
>> arm64: dts: hisi: add pinctrl dtsi file for HiKey960 development board (2017-04-10 23:34:26 +0800)
>>
>> ----------------------------------------------------------------
>> ARM64: DT: Hisilicon SoC DT updates for 4.12
>>
>> - Reset the hi6220 mmc hosts to avoid hang
>> - Add the binding for the hi3798cv200 SoC and the poplar board
>> - Add basic dts files to support the hi3798cv200 poplar board
>> - Enable the Mbigen, XGE, RoCE and SAS for the hip07 d05 board
>> - Add driver strength MACRO for the hi3660 SoC
>> - Add the pinctrl dtsi file for hikey960 board to configure the pins
>
> Merged, thanks.
Thanks!
Best Regards,
Wei
>
>
> -Olof
>
> .
>
^ permalink raw reply
* [GIT PULL] ARM: hisi: soc updates for v4.12
From: Wei Xu @ 2017-04-19 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419140302.GL29219@localhost>
Hi Olof,
On 2017/4/19 15:03, Olof Johansson wrote:
> On Mon, Apr 10, 2017 at 04:48:06PM +0100, Wei Xu wrote:
>> Hi Arnd, Hi Olof, Hi Kevin,
>>
>> Please help to pull the following changes.
>> Thanks!
>>
>> Best Regards,
>> Wei
>>
>> ---
>>
>> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>>
>> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>>
>> are available in the git repository at:
>>
>> git://github.com/hisilicon/linux-hisi.git tags/hisi-armv7-soc-for-4.12
>>
>> for you to fetch changes up to f147140c7f0350d363c10aeb51b78b65b2425266:
>>
>> ARM: hisi: fix error return code in hip04_smp_init() (2017-03-28 15:30:54 +0100)
>>
>> ----------------------------------------------------------------
>> ARM: mach-hisi: Hisilicon SoC updates for 4.12
>>
>> - Fix the error return code in hip04_smp_init
>>
>> ----------------------------------------------------------------
>> Wei Yongjun (1):
>> ARM: hisi: fix error return code in hip04_smp_init()
>>
>> arch/arm/mach-hisi/platmcpm.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>
> Merged, thanks!
Thanks!
BR,
Wei
>
>
> -Olof
>
> .
>
^ permalink raw reply
* [PATCH 4.4 18/45] irqchip/irq-imx-gpcv2: Fix spinlock initialization
From: Greg Kroah-Hartman @ 2017-04-19 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419141634.793081968@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tyler Baker <tyler.baker@linaro.org>
commit 75eb5e1e7b4edbc8e8f930de59004d21cb46961f upstream.
The raw_spinlock in the IMX GPCV2 interupt chip is not initialized before
usage. That results in a lockdep splat:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
Add the missing raw_spin_lock_init() to the setup code.
Fixes: e324c4dc4a59 ("irqchip/imx-gpcv2: IMX GPCv2 driver for wakeup sources")
Signed-off-by: Tyler Baker <tyler.baker@linaro.org>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Cc: jason at lakedaemon.net
Cc: marc.zyngier at arm.com
Cc: shawnguo at kernel.org
Cc: andrew.smirnov at gmail.com
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/20170413222731.5917-1-tyler.baker at linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/irq-imx-gpcv2.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -230,6 +230,8 @@ static int __init imx_gpcv2_irqchip_init
return -ENOMEM;
}
+ raw_spin_lock_init(&cd->rlock);
+
cd->gpc_base = of_iomap(node, 0);
if (!cd->gpc_base) {
pr_err("fsl-gpcv2: unable to map gpc registers\n");
^ permalink raw reply
* [PATCH 0/4] ARM: sunxi: device tree pinctrl clean up and H3 OTG
From: Maxime Ripard @ 2017-04-19 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419050919.6762-1-wens@csie.org>
On Wed, Apr 19, 2017 at 01:09:15PM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> This series has 2 parts. The parts are largely unrelated, though the
> second part should be applied after the first part, so we don't
> accidentally mux pins that we shouldn't. Hence I'm sending them
> together.
>
> The first 2 patches clean up the sunxi device tree files, removing
> pinmux settings for common GPIO pins. These include the enable pins
> for the common regulators, and the mmc0 card detect pin from the
> reference designs.
>
> The second part, the latter 2 patches, enable USB OTG on the Orangepi
> PC, PC Plus, Plus 2E, and the Bananapi M2+. The first 3 boards are
> bunched together, due to how the PC Plus and Plus 2E device trees include
> the device tree of the Opi PC.
Applied, thanks!
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170419/97e6c778/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: dts: allwinner: pine64: Prepare optional UART nodes with pinctrl
From: Maxime Ripard @ 2017-04-19 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418192538.24174-1-afaerber@suse.de>
On Tue, Apr 18, 2017 at 09:25:38PM +0200, Andreas F?rber wrote:
> Pine64 exposes all A64 UARTs, not just UART0.
>
> Since the pins can be used as GPIO, don't enable the new UART nodes by
> default, but prepare the pinctrl settings to aid in activating them via
> overlays, i.e., overriding the status property of &uartX nodes.
>
> For UART4 (Euler) the safer route of not including RTS/CTS pins is chosen,
> whereas for UART1 (Bluetooth) they are included.
>
> Add the corresponding pinctrl nodes where missing.
>
> Suggested-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Signed-off-by: Andreas F?rber <afaerber@suse.de>
Applied, thanks!
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170419/9463c8d7/attachment.sig>
^ permalink raw reply
* [PATCH v6 6/8] coresight: add support for CPU debug module
From: Mathieu Poirier @ 2017-04-19 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419001807.GB8524@leoy-linaro>
On 18 April 2017 at 18:18, Leo Yan <leo.yan@linaro.org> wrote:
> On Tue, Apr 18, 2017 at 11:40:50AM -0600, Mathieu Poirier wrote:
>> On Thu, Apr 06, 2017 at 09:30:59PM +0800, Leo Yan wrote:
>> > Coresight includes debug module and usually the module connects with CPU
>> > debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
>> > description for related info in "Part H: External Debug".
>> >
>> > Chapter H7 "The Sample-based Profiling Extension" introduces several
>> > sampling registers, e.g. we can check program counter value with
>> > combined CPU exception level, secure state, etc. So this is helpful for
>> > analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
>> > loop with IRQ disabled. In this case the CPU cannot switch context and
>> > handle any interrupt (including IPIs), as the result it cannot handle
>> > SMP call for stack dump.
>> >
>> > This patch is to enable coresight debug module, so firstly this driver
>> > is to bind apb clock for debug module and this is to ensure the debug
>> > module can be accessed from program or external debugger. And the driver
>> > uses sample-based registers for debug purpose, e.g. when system triggers
>> > panic, the driver will dump program counter and combined context
>> > registers (EDCIDSR, EDVIDSR); by parsing context registers so can
>> > quickly get to know CPU secure state, exception level, etc.
>> >
>> > Some of the debug module registers are located in CPU power domain, so
>> > this requires the CPU power domain stays on when access related debug
>> > registers, but the power management for CPU power domain is quite
>> > dependent on SoC integration for power management. For the platforms
>> > which with sane power controller implementations, this driver follows
>> > the method to set EDPRCR to try to pull the CPU out of low power state
>> > and then set 'no power down request' bit so the CPU has no chance to
>> > lose power.
>> >
>> > If the SoC has not followed up this design well for power management
>> > controller, the user should use the command line parameter or sysfs
>> > to constrain all or partial idle states to ensure the CPU power
>> > domain is enabled and access coresight CPU debug component safely.
>> >
>> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
>>
>> This is coming along well - a few comment below. In your next revision please
>> add GKH to the 'To' list.
>
> Sure. Will send out in this week and add Greg in 'To' list.
>
>> > ---
>> > drivers/hwtracing/coresight/Kconfig | 14 +
>> > drivers/hwtracing/coresight/Makefile | 1 +
>> > drivers/hwtracing/coresight/coresight-cpu-debug.c | 667 ++++++++++++++++++++++
>> > 3 files changed, 682 insertions(+)
>> > create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
>> >
>> > diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
>> > index 130cb21..8d55d6d 100644
>> > --- a/drivers/hwtracing/coresight/Kconfig
>> > +++ b/drivers/hwtracing/coresight/Kconfig
>> > @@ -89,4 +89,18 @@ config CORESIGHT_STM
>> > logging useful software events or data coming from various entities
>> > in the system, possibly running different OSs
>> >
>> > +config CORESIGHT_CPU_DEBUG
>> > + tristate "CoreSight CPU Debug driver"
>> > + depends on ARM || ARM64
>> > + depends on DEBUG_FS
>> > + help
>> > + This driver provides support for coresight debugging module. This
>> > + is primarily used to dump sample-based profiling registers when
>> > + system triggers panic, the driver will parse context registers so
>> > + can quickly get to know program counter (PC), secure state,
>> > + exception level, etc. Before use debugging functionality, platform
>> > + needs to ensure the clock domain and power domain are enabled
>> > + properly, please refer Documentation/trace/coresight-cpu-debug.txt
>> > + for detailed description and the example for usage.
>> > +
>> > endif
>> > diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
>> > index af480d9..433d590 100644
>> > --- a/drivers/hwtracing/coresight/Makefile
>> > +++ b/drivers/hwtracing/coresight/Makefile
>> > @@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>> > coresight-etm4x-sysfs.o
>> > obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
>> > obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>> > +obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
>> > diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c b/drivers/hwtracing/coresight/coresight-cpu-debug.c
>> > new file mode 100644
>> > index 0000000..8470e31
>> > --- /dev/null
>> > +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
>> > @@ -0,0 +1,667 @@
>> > +/*
>> > + * Copyright (c) 2017 Linaro Limited. All rights reserved.
>> > + *
>> > + * Author: Leo Yan <leo.yan@linaro.org>
>> > + *
>> > + * This program is free software; you can redistribute it and/or modify it
>> > + * under the terms of the GNU General Public License version 2 as published by
>> > + * the Free Software Foundation.
>> > + *
>> > + * This program is distributed in the hope that it will be useful, but WITHOUT
>> > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
>> > + * more details.
>> > + *
>> > + * You should have received a copy of the GNU General Public License along with
>> > + * this program. If not, see <http://www.gnu.org/licenses/>.
>> > + *
>> > + */
>> > +#include <linux/amba/bus.h>
>> > +#include <linux/coresight.h>
>> > +#include <linux/cpu.h>
>> > +#include <linux/debugfs.h>
>> > +#include <linux/delay.h>
>> > +#include <linux/device.h>
>> > +#include <linux/err.h>
>> > +#include <linux/init.h>
>> > +#include <linux/io.h>
>> > +#include <linux/iopoll.h>
>> > +#include <linux/kernel.h>
>> > +#include <linux/module.h>
>> > +#include <linux/moduleparam.h>
>> > +#include <linux/pm_qos.h>
>> > +#include <linux/slab.h>
>> > +#include <linux/smp.h>
>> > +#include <linux/types.h>
>> > +#include <linux/uaccess.h>
>> > +
>> > +#include "coresight-priv.h"
>> > +
>> > +#define EDPCSR 0x0A0
>> > +#define EDCIDSR 0x0A4
>> > +#define EDVIDSR 0x0A8
>> > +#define EDPCSR_HI 0x0AC
>> > +#define EDOSLAR 0x300
>> > +#define EDPRCR 0x310
>> > +#define EDPRSR 0x314
>> > +#define EDDEVID1 0xFC4
>> > +#define EDDEVID 0xFC8
>> > +
>> > +#define EDPCSR_PROHIBITED 0xFFFFFFFF
>> > +
>> > +/* bits definition for EDPCSR */
>> > +#define EDPCSR_THUMB BIT(0)
>> > +#define EDPCSR_ARM_INST_MASK GENMASK(31, 2)
>> > +#define EDPCSR_THUMB_INST_MASK GENMASK(31, 1)
>> > +
>> > +/* bits definition for EDPRCR */
>> > +#define EDPRCR_COREPURQ BIT(3)
>> > +#define EDPRCR_CORENPDRQ BIT(0)
>> > +
>> > +/* bits definition for EDPRSR */
>> > +#define EDPRSR_DLK BIT(6)
>> > +#define EDPRSR_PU BIT(0)
>> > +
>> > +/* bits definition for EDVIDSR */
>> > +#define EDVIDSR_NS BIT(31)
>> > +#define EDVIDSR_E2 BIT(30)
>> > +#define EDVIDSR_E3 BIT(29)
>> > +#define EDVIDSR_HV BIT(28)
>> > +#define EDVIDSR_VMID GENMASK(7, 0)
>> > +
>> > +/*
>> > + * bits definition for EDDEVID1:PSCROffset
>> > + *
>> > + * NOTE: armv8 and armv7 have different definition for the register,
>> > + * so consolidate the bits definition as below:
>> > + *
>> > + * 0b0000 - Sample offset applies based on the instruction state, we
>> > + * rely on EDDEVID to check if EDPCSR is implemented or not
>> > + * 0b0001 - No offset applies.
>> > + * 0b0010 - No offset applies, but do not use in AArch32 mode
>> > + *
>> > + */
>> > +#define EDDEVID1_PCSR_OFFSET_MASK GENMASK(3, 0)
>> > +#define EDDEVID1_PCSR_OFFSET_INS_SET (0x0)
>> > +#define EDDEVID1_PCSR_NO_OFFSET_DIS_AARCH32 (0x2)
>> > +
>> > +/* bits definition for EDDEVID */
>> > +#define EDDEVID_PCSAMPLE_MODE GENMASK(3, 0)
>> > +#define EDDEVID_IMPL_EDPCSR (0x1)
>> > +#define EDDEVID_IMPL_EDPCSR_EDCIDSR (0x2)
>> > +#define EDDEVID_IMPL_FULL (0x3)
>> > +
>> > +#define DEBUG_WAIT_SLEEP 1000
>> > +#define DEBUG_WAIT_TIMEOUT 32000
>> > +
>> > +struct debug_drvdata {
>> > + void __iomem *base;
>> > e struct device *dev;
>> > + int cpu;
>> > +
>> > + bool edpcsr_present;
>> > + bool edcidsr_present;
>> > + bool edvidsr_present;
>> > + bool pc_has_offset;
>> > +
>> > + u32 edpcsr;
>> > + u32 edpcsr_hi;
>> > + u32 edprsr;
>> > + u32 edvidsr;
>> > + u32 edcidsr;
>> > +};
>> > +
>> > +static DEFINE_MUTEX(debug_lock);
>> > +static DEFINE_PER_CPU(struct debug_drvdata *, debug_drvdata);
>> > +static int debug_count;
>> > +static struct dentry *debug_debugfs_dir;
>> > +
>> > +static bool debug_enable;
>> > +module_param_named(enable, debug_enable, bool, 0600);
>> > +MODULE_PARM_DESC(enable, "Knob to enable debug functionality "
>> > + "(default is 0, which means is disabled by default)");
>>
>> For this driver we have a debugFS interface so I question the validity of a
>> kernel module parameter. Other than adding complexity to the code it offers no
>> real added value. If a user is to insmod a module, it is just as easy to switch
>> on the functionality using debugFS in a second step.
>
> This module parameter can be used for kernel command line, so
> it's useful when user wants to dynamically turn on/off the
> functionality at boot up time.
>
> Does this make sense for you? Removing this parameter is okay for
> me, but this means users need to decide if use it by Kernel config
> with static building in. This is a bit contradictory with before's
> discussion.
My hope was to use the kernel command line and the debugFS interface,
avoiding the module parameter. Look at what the baycom_par and
blacklist drivers are doing with the "__setup()" function and see if
we can void a module parameter. If not then let it be, unless someone
else has a better idea.
[1]. drivers/net/hamradio/baycom_par.c
[2]. drivers/se90/cio/blacklist.c
>
>> > +static void debug_os_unlock(struct debug_drvdata *drvdata)
>> > +{
>> > + /* Unlocks the debug registers */
>> > + writel_relaxed(0x0, drvdata->base + EDOSLAR);
>>
>> Here the wmb is to make sure reordering (either at compile time or in the CPU)
>> doesn't happend. You need a comment here otherwise checkpatch will complain.
>> Speaking of which, did you run this through checkpatch?
>
> Right. Everytime I run checkpatch before sending patch and it has
> complain for this. Will add comment. Sorry for imprecise working.
>
>> > + wmb();
>> > +}
>> > +
>> > +/*
>> > + * According to ARM DDI 0487A.k, before access external debug
>> > + * registers should firstly check the access permission; if any
>> > + * below condition has been met then cannot access debug
>> > + * registers to avoid lockup issue:
>> > + *
>> > + * - CPU power domain is powered off;
>> > + * - The OS Double Lock is locked;
>> > + *
>> > + * By checking EDPRSR can get to know if meet these conditions.
>> > + */
>> > +static bool debug_access_permitted(struct debug_drvdata *drvdata)
>> > +{
>> > + /* CPU is powered off */
>> > + if (!(drvdata->edprsr & EDPRSR_PU))
>> > + return false;
>> > +
>> > + /* The OS Double Lock is locked */
>> > + if (drvdata->edprsr & EDPRSR_DLK)
>> > + return false;
>> > +
>> > + return true;
>> > +}
>> > +
>> > +static void debug_force_cpu_powered_up(struct debug_drvdata *drvdata)
>> > +{
>> > + bool retried = false;
>> > + u32 edprcr;
>> > +
>> > +try_again:
>> > +
>> > + /*
>> > + * Send request to power management controller and assert
>> > + * DBGPWRUPREQ signal; if power management controller has
>> > + * sane implementation, it should enable CPU power domain
>> > + * in case CPU is in low power state.
>> > + */
>> > + edprcr = readl_relaxed(drvdata->base + EDPRCR);
>> > + edprcr |= EDPRCR_COREPURQ;
>> > + writel_relaxed(edprcr, drvdata->base + EDPRCR);
>> > +
>> > + /* Wait for CPU to be powered up (timeout~=32ms) */
>> > + if (readx_poll_timeout_atomic(readl_relaxed, drvdata->base + EDPRSR,
>> > + drvdata->edprsr, (drvdata->edprsr & EDPRSR_PU),
>> > + DEBUG_WAIT_SLEEP, DEBUG_WAIT_TIMEOUT)) {
>> > + /*
>> > + * Unfortunately the CPU cannot be powered up, so return
>> > + * back and later has no permission to access other
>> > + * registers. For this case, should disable CPU low power
>> > + * states to ensure CPU power domain is enabled!
>> > + */
>> > + pr_err("%s: power up request for CPU%d failed\n",
>> > + __func__, drvdata->cpu);
>> > + return;
>> > + }
>> > +
>> > + /*
>> > + * At this point the CPU is powered up, so set the no powerdown
>> > + * request bit so we don't lose power and emulate power down.
>> > + */
>> > + edprcr = readl_relaxed(drvdata->base + EDPRCR);
>> > + edprcr |= EDPRCR_COREPURQ | EDPRCR_CORENPDRQ;
>> > + writel_relaxed(edprcr, drvdata->base + EDPRCR);
>> > +
>> > + drvdata->edprsr = readl_relaxed(drvdata->base + EDPRSR);
>> > +
>> > + /* Bail out if CPU is powered up */
>> > + if (likely(drvdata->edprsr & EDPRSR_PU))
>> > + return;
>>
>> /* The core power domain got switched off on use, try again */
>> if (unlikely(!drvdata->edprsr & EDPRSR_PU))
>> goto try_again;
>>
>> I understand you don't want to introduce a infinite loop but if that happens
>> here, something else has gone very wrong. The above readx_poll_timeout_atomic
>> loop should take care of bailing out in case of problems. That way you also get
>> to rid of the retried variable and the code is more simple.
>
> Okay. I will follow your method. Thinking the duration of CPU power
> on/off is not same magnitude with this piece code, the infinite loop
> will not happen.
>
>> > +
>> > + /*
>> > + * Handle race condition if CPU has been waken up but it sleeps
>> > + * again if EDPRCR_CORENPDRQ has been flipped, so try to run
>> > + * waken flow one more time.
>> > + */
>> > + if (!retried) {
>> > + retried = true;
>> > + goto try_again;
>> > + }
>> > +}
>> > +
>> > +static void debug_read_regs(struct debug_drvdata *drvdata)
>> > +{
>> > + u32 save_edprcr;
>> > +
>> > + CS_UNLOCK(drvdata->base);
>> > +
>> > + /* Unlock os lock */
>> > + debug_os_unlock(drvdata);
>> > +
>> > + /* Save EDPRCR register */
>> > + save_edprcr = readl_relaxed(drvdata->base + EDPRCR);
>> > +
>> > + /*
>> > + * Ensure CPU power domain is enabled to let registers
>> > + * are accessiable.
>> > + */
>> > + debug_force_cpu_powered_up(drvdata);
>> > +
>> > + if (!debug_access_permitted(drvdata))
>> > + goto out;
>> > +
>> > + drvdata->edpcsr = readl_relaxed(drvdata->base + EDPCSR);
>> > +
>> > + /*
>> > + * As described in ARM DDI 0487A.k, if the processing
>> > + * element (PE) is in debug state, or sample-based
>> > + * profiling is prohibited, EDPCSR reads as 0xFFFFFFFF;
>> > + * EDCIDSR, EDVIDSR and EDPCSR_HI registers also become
>> > + * UNKNOWN state. So directly bail out for this case.
>> > + */
>> > + if (drvdata->edpcsr == EDPCSR_PROHIBITED)
>> > + goto out;
>> > +
>> > + /*
>> > + * A read of the EDPCSR normally has the side-effect of
>> > + * indirectly writing to EDCIDSR, EDVIDSR and EDPCSR_HI;
>> > + * at this point it's safe to read value from them.
>> > + */
>> > + if (IS_ENABLED(CONFIG_64BIT))
>> > + drvdata->edpcsr_hi = readl_relaxed(drvdata->base + EDPCSR_HI);
>> > +
>> > + if (drvdata->edcidsr_present)
>> > + drvdata->edcidsr = readl_relaxed(drvdata->base + EDCIDSR);
>> > +
>> > + if (drvdata->edvidsr_present)
>> > + drvdata->edvidsr = readl_relaxed(drvdata->base + EDVIDSR);
>> > +
>> > +out:
>> > + /* Restore EDPRCR register */
>> > + writel_relaxed(save_edprcr, drvdata->base + EDPRCR);
>> > +
>> > + CS_LOCK(drvdata->base);
>> > +}
>> > +
>> > +static unsigned long debug_adjust_pc(struct debug_drvdata *drvdata)
>> > +{
>> > + unsigned long arm_inst_offset = 0, thumb_inst_offset = 0;
>> > + unsigned long pc;
>> > +
>> > + if (IS_ENABLED(CONFIG_64BIT))
>> > + return (unsigned long)drvdata->edpcsr_hi << 32 |
>> > + (unsigned long)drvdata->edpcsr;
>> > +
>> > + pc = (unsigned long)drvdata->edpcsr;
>> > +
>> > + if (drvdata->pc_has_offset) {
>> > + arm_inst_offset = 8;
>> > + thumb_inst_offset = 4;
>> > + }
>> > +
>> > + /* Handle thumb instruction */
>> > + if (pc & EDPCSR_THUMB) {
>> > + pc = (pc & EDPCSR_THUMB_INST_MASK) - thumb_inst_offset;
>> > + return pc;
>> > + }
>> > +
>> > + /*
>> > + * Handle arm instruction offset, if the arm instruction
>> > + * is not 4 byte alignment then it's possible the case
>> > + * for implementation defined; keep original value for this
>> > + * case and print info for notice.
>> > + */
>> > + if (pc & BIT(1))
>> > + pr_emerg("Instruction offset is implementation defined\n");
>> > + else
>> > + pc = (pc & EDPCSR_ARM_INST_MASK) - arm_inst_offset;
>> > +
>> > + return pc;
>> > +}
>> > +
>> > +static void debug_dump_regs(struct debug_drvdata *drvdata)
>> > +{
>> > + unsigned long pc;
>> > +
>> > + pr_emerg("\tEDPRSR: %08x (Power:%s DLK:%s)\n", drvdata->edprsr,
>> > + drvdata->edprsr & EDPRSR_PU ? "On" : "Off",
>> > + drvdata->edprsr & EDPRSR_DLK ? "Lock" : "Unlock");
>> > +
>> > + if (!debug_access_permitted(drvdata)) {
>> > + pr_emerg("No permission to access debug registers!\n");
>> > + return;
>> > + }
>> > +
>> > + if (drvdata->edpcsr == EDPCSR_PROHIBITED) {
>> > + pr_emerg("CPU is in Debug state or profiling is prohibited!\n");
>> > + return;
>> > + }
>> > +
>> > + pc = debug_adjust_pc(drvdata);
>> > + pr_emerg("\tEDPCSR: [<%p>] %pS\n", (void *)pc, (void *)pc);
>> > +
>> > + if (drvdata->edcidsr_present)
>> > + pr_emerg("\tEDCIDSR: %08x\n", drvdata->edcidsr);
>> > +
>> > + if (drvdata->edvidsr_present)
>> > + pr_emerg("\tEDVIDSR: %08x (State:%s Mode:%s Width:%dbits VMID:%x)\n",
>> > + drvdata->edvidsr,
>> > + drvdata->edvidsr & EDVIDSR_NS ? "Non-secure" : "Secure",
>> > + drvdata->edvidsr & EDVIDSR_E3 ? "EL3" :
>> > + (drvdata->edvidsr & EDVIDSR_E2 ? "EL2" : "EL1/0"),
>> > + drvdata->edvidsr & EDVIDSR_HV ? 64 : 32,
>> > + drvdata->edvidsr & (u32)EDVIDSR_VMID);
>> > +}
>> > +
>> > +static void debug_init_arch_data(void *info)
>> > +{
>> > + struct debug_drvdata *drvdata = info;
>> > + u32 mode, pcsr_offset;
>> > + u32 eddevid, eddevid1;
>> > +
>> > + CS_UNLOCK(drvdata->base);
>> > +
>> > + /* Read device info */
>> > + eddevid = readl_relaxed(drvdata->base + EDDEVID);
>> > + eddevid1 = readl_relaxed(drvdata->base + EDDEVID1);
>> > +
>> > + CS_LOCK(drvdata->base);
>> > +
>> > + /* Parse implementation feature */
>> > + mode = eddevid & EDDEVID_PCSAMPLE_MODE;
>> > + pcsr_offset = eddevid1 & EDDEVID1_PCSR_OFFSET_MASK;
>> > +
>> > + drvdata->edpcsr_present = false;
>> > + drvdata->edcidsr_present = false;
>> > + drvdata->edvidsr_present = false;
>> > + drvdata->pc_has_offset = false;
>> > +
>> > + switch (mode) {
>> > + case EDDEVID_IMPL_FULL:
>> > + drvdata->edvidsr_present = true;
>> > + /* Fall through */
>> > + case EDDEVID_IMPL_EDPCSR_EDCIDSR:
>> > + drvdata->edcidsr_present = true;
>> > + /* Fall through */
>> > + case EDDEVID_IMPL_EDPCSR:
>> > + /*
>> > + * In ARM DDI 0487A.k, the EDDEVID1.PCSROffset is used to
>> > + * define if has the offset for PC sampling value; if read
>> > + * back EDDEVID1.PCSROffset == 0x2, then this means the debug
>> > + * module does not sample the instruction set state when
>> > + * armv8 CPU in AArch32 state.
>> > + */
>> > + drvdata->edpcsr_present = (IS_ENABLED(CONFIG_64BIT) ||
>> > + (pcsr_offset != EDDEVID1_PCSR_NO_OFFSET_DIS_AARCH32));
>> > +
>> > + drvdata->pc_has_offset =
>> > + (pcsr_offset == EDDEVID1_PCSR_OFFSET_INS_SET);
>> > + break;
>> > + default:
>> > + break;
>> > + }
>> > +}
>> > +
>> > +/*
>> > + * Dump out information on panic.
>> > + */
>> > +static int debug_notifier_call(struct notifier_block *self,
>> > + unsigned long v, void *p)
>> > +{
>> > + int cpu;
>> > + struct debug_drvdata *drvdata;
>> > +
>> > + pr_emerg("ARM external debug module:\n");
>> > +
>> > + for_each_possible_cpu(cpu) {
>> > + drvdata = per_cpu(debug_drvdata, cpu);
>> > + if (!drvdata)
>> > + continue;
>> > +
>> > + pr_emerg("CPU[%d]:\n", drvdata->cpu);
>> > +
>> > + debug_read_regs(drvdata);
>> > + debug_dump_regs(drvdata);
>> > + }
>> > +
>> > + return 0;
>> > +}
>> > +
>> > +static struct notifier_block debug_notifier = {
>> > + .notifier_call = debug_notifier_call,
>> > +};
>> > +
>> > +static int debug_enable_func(void)
>> > +{
>> > + struct debug_drvdata *drvdata;
>> > + int cpu;
>> > +
>> > + for_each_possible_cpu(cpu) {
>> > + drvdata = per_cpu(debug_drvdata, cpu);
>> > + if (!drvdata)
>> > + continue;
>> > +
>> > + pm_runtime_get_sync(drvdata->dev);
>> > + }
>> > +
>> > + return atomic_notifier_chain_register(&panic_notifier_list,
>> > + &debug_notifier);
>> > +}
>> > +
>> > +static int debug_disable_func(void)
>> > +{
>> > + struct debug_drvdata *drvdata;
>> > + int cpu;
>> > +
>> > + for_each_possible_cpu(cpu) {
>> > + drvdata = per_cpu(debug_drvdata, cpu);
>> > + if (!drvdata)
>> > + continue;
>> > +
>> > + pm_runtime_put(drvdata->dev);
>> > + }
>> > +
>> > + return atomic_notifier_chain_unregister(&panic_notifier_list,
>> > + &debug_notifier);
>> > +}
>> > +
>> > +static ssize_t debug_func_knob_write(struct file *f,
>> > + const char __user *buf, size_t count, loff_t *ppos)
>> > +{
>> > + u8 val;
>> > + int ret;
>> > +
>> > + ret = kstrtou8_from_user(buf, count, 2, &val);
>> > + if (ret)
>> > + return ret;
>> > +
>> > + mutex_lock(&debug_lock);
>> > +
>> > + if (val == debug_enable)
>> > + goto out;
>> > +
>> > + if (val)
>> > + ret = debug_enable_func();
>> > + else
>> > + ret = debug_disable_func();
>>
>> I don't think you need to install the handler every time the functionality is
>> switched on/off. I suggest to install the handler at boot time (or module
>> insertion time) and in the notifier handler, check the debug_enable flag before
>> moving on with the output.
>
> Will do.
>
>> > +
>> > + if (ret) {
>> > + pr_err("%s: unable to %s debug function: %d\n",
>> > + __func__, val ? "enable" : "disable", ret);
>> > + goto err;
>> > + }
>> > +
>> > + debug_enable = val;
>>
>> Using a true/false value is probably better here. That way you don't end up
>> with miscellaneous values in debugFS.
>
> From my testing here will not assign other values rather than 0 or 1.
> This is controlled by function kstrtou8_from_user(), the 3rd parameter
> '2' is to define the value range [0..1], so other values will report
> error after return back from kstrtou8_from_user().
Ok that works.
>
>> > +out:
>> > + ret = count;
>> > +err:
>> > + mutex_unlock(&debug_lock);
>> > + return ret;
>> > +}
>> > +
>> > +static ssize_t debug_func_knob_read(struct file *f,
>> > + char __user *ubuf, size_t count, loff_t *ppos)
>> > +{
>> > + ssize_t ret;
>> > + char buf[2];
>> > +
>> > + mutex_lock(&debug_lock);
>> > +
>> > + buf[0] = '0' + debug_enable;
>> > + buf[1] = '\n';
>>
>> snprintf()
>
> Will fix.
>
>> > + ret = simple_read_from_buffer(ubuf, count, ppos, buf, sizeof(buf));
>> > +
>> > + mutex_unlock(&debug_lock);
>> > + return ret;
>> > +}
>> > +
>> > +static const struct file_operations debug_func_knob_fops = {
>> > + .open = simple_open,
>> > + .read = debug_func_knob_read,
>> > + .write = debug_func_knob_write,
>> > +};
>> > +
>> > +static int debug_func_init(void)
>> > +{
>> > + struct dentry *file;
>> > + int ret;
>> > +
>> > + /* Create debugfs node */
>> > + debug_debugfs_dir = debugfs_create_dir("coresight_cpu_debug", NULL);
>> > + if (!debug_debugfs_dir) {
>> > + pr_err("%s: unable to create debugfs directory\n", __func__);
>> > + return -ENOMEM;
>> > + }
>> > +
>> > + file = debugfs_create_file("enable", S_IRUGO | S_IWUSR,
>> > + debug_debugfs_dir, NULL, &debug_func_knob_fops);
>>
>> Please align this properly.
>
> Will fix. Thanks a lot for detailed reviewing.
>
> [...]
>
> Thanks,
> Leo Yan
^ permalink raw reply
* [PATCH net-next 1/4] ixgbe: sparc: rename the ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER
From: Gabriele Paoloni @ 2017-04-19 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E205352FC@FRAEML521-MBX.china.huawei.com>
Hi Amir
> From: Amir Ancel [mailto:amira at mellanox.com]
> Sent: 18 April 2017 21:18
> To: David Laight; Gabriele Paoloni; davem at davemloft.net
> Cc: Catalin Marinas; Will Deacon; Mark Rutland; Robin Murphy;
> jeffrey.t.kirsher at intel.com; alexander.duyck at gmail.com; linux-arm-
> kernel at lists.infradead.org; netdev at vger.kernel.org; Dingtianhong;
> Linuxarm
> Subject: Re: Re: [PATCH net-next 1/4] ixgbe: sparc: rename the
> ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER
>
> Hi,
> mlx5 driver is planned to have RO support this year.
> I believe drivers should be able to query whether the arch support it
I guess that here when you say query you mean having a config symbol
that is set accordingly to the host architecture, right?
As already said I have looked around a bit and other drivers do not seem
to enable/disable RO for their EP on the basis of the host architecture.
So why should mlx5 do it according to the host?
Also my understating is that some architectures (like ARM64 for example)
can have different PCI host controller implementations depending on the
vendor...therefore maybe it is not appropriate there to have a Kconfig
symbol selected by the architecture...
Thanks
Gab
> or not and enable it in the network adapter accordingly.
>
> -Amir
> ________________________________________
> From: netdev-owner at vger.kernel.org <netdev-owner@vger.kernel.org> on
> behalf of David Laight <David.Laight@ACULAB.COM>
> Sent: Tuesday, April 18, 2017 4:25:44 PM
> To: 'Gabriele Paoloni'; davem at davemloft.net
> Cc: Catalin Marinas; Will Deacon; Mark Rutland; Robin Murphy;
> jeffrey.t.kirsher at intel.com; alexander.duyck at gmail.com; linux-arm-
> kernel at lists.infradead.org; netdev at vger.kernel.org; Dingtianhong;
> Linuxarm
> Subject: RE: Re: [PATCH net-next 1/4] ixgbe: sparc: rename the
> ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER
>
> From: Gabriele Paoloni
> > Sent: 13 April 2017 10:11
> > > > Till now only the Intel ixgbe could support enable
> > > > Relaxed ordering in the drivers for special architecture,
> > > > but the ARCH_WANT_RELAX_ORDER is looks like a general name
> > > > for all arch, so rename to a specific name for intel
> > > > card looks more appropriate.
> > > >
> > > > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> > >
> > > This is not a driver specific facility.
> > >
> > > Any driver can test this symbol and act accordingly.
> > >
> > > Just because IXGBE is the first and only user, doesn't mean
> > > the facility is driver specific.
> >
> >
> > Please correct me if I am wrong but my understanding is that the
> standard
> > way to enable/disable relaxed ordering is to set/clear bit 4 of the
> Device
> > Control Register (PCI_EXP_DEVCTL_RELAX_EN 0x0010 /* Enable relaxed
> > ordering */).
> > Now I have looked up for all drivers either enabling or disabling
> relaxed
> > ordering and none of them seems to need a symbol to decide whether to
> > enable it or not.
> > Also it seems to me enabling/disabling relaxed ordering is never
> bound to the
> > host architecture.
> >
> > So why this should be (or it is expected to be) a generic symbol?
> > Wouldn't it be more correct to have this as a driver specific symbol
> now and
> > move it to a generic one later once we have other drivers requiring
> it?
>
> 'Relaxed ordering' is a bit in the TLP header.
> A device (like the ixgbe hardware) can set it for some transactions and
> still have the transactions 'ordered enough' for the driver to work.
> (If all transactions have 'relaxed ordering' set then I suspect it is
> almost impossible to write a working driver.)
> The host side could (probably does) have a bit to enable 'relaxed
> ordering',
> it could also enforce stronger ordering than required by the PCIe spec
> (eg keeping reads in order).
>
> Clearly, on some sparc64 systems, ixgbe needs to use 'relaxed
> ordering'.
> To me this requires two separate bits be enabled:
> 1) to the ixgbe driver to generate the 'relaxed' TLP.
> 2) to the host to actually act on them.
> If the ixgbe driver works when both are enabled why have options to
> disable either (except for bug-finding)?
>
> ??????? David
^ permalink raw reply
* [PATCH v2] KVM: arm/arm64: vgic-v3: De-optimize VMCR save/restore when emulating a GICv2
From: Christoffer Dall @ 2017-04-19 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419111526.21073-1-marc.zyngier@arm.com>
On Wed, Apr 19, 2017 at 12:15:26PM +0100, Marc Zyngier wrote:
> When emulating a GICv2-on-GICv3, special care must be taken to only
> save/restore VMCR_EL2 when ICC_SRE_EL1.SRE is cleared. Otherwise,
> all Group-0 interrupts end-up being delivered as FIQ, which is
> probably not what the guest expects, as demonstrated here with
> an unhappy EFI:
>
> FIQ Exception at 0x000000013BD21CC4
>
> This means that we cannot perform the load/put trick when dealing
> with VMCR_EL2 (because the host has SRE set), and we have to deal
> with it in the world-switch.
>
> Fortunately, this is not the most common case (modern guests should
> be able to deal with GICv3 directly), and the performance is not worse
> than what it was before the VMCR optimization.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
I have applied both fixes.
Thanks,
-Christoffer
> ---
> * From v1:
> - Move vgic_sre testing from vgic_{load,put} to vgic_v3_{load,put}
>
> virt/kvm/arm/hyp/vgic-v3-sr.c | 8 ++++++--
> virt/kvm/arm/vgic/vgic-v3.c | 11 +++++++++--
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/virt/kvm/arm/hyp/vgic-v3-sr.c b/virt/kvm/arm/hyp/vgic-v3-sr.c
> index 3d0b1ddb6929..91922c1eddc8 100644
> --- a/virt/kvm/arm/hyp/vgic-v3-sr.c
> +++ b/virt/kvm/arm/hyp/vgic-v3-sr.c
> @@ -128,8 +128,10 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
> * Make sure stores to the GIC via the memory mapped interface
> * are now visible to the system register interface.
> */
> - if (!cpu_if->vgic_sre)
> + if (!cpu_if->vgic_sre) {
> dsb(st);
> + cpu_if->vgic_vmcr = read_gicreg(ICH_VMCR_EL2);
> + }
>
> if (used_lrs) {
> int i;
> @@ -205,11 +207,13 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
> * delivered as a FIQ to the guest, with potentially fatal
> * consequences. So we must make sure that ICC_SRE_EL1 has
> * been actually programmed with the value we want before
> - * starting to mess with the rest of the GIC.
> + * starting to mess with the rest of the GIC, and VMCR_EL2 in
> + * particular.
> */
> if (!cpu_if->vgic_sre) {
> write_gicreg(0, ICC_SRE_EL1);
> isb();
> + write_gicreg(cpu_if->vgic_vmcr, ICH_VMCR_EL2);
> }
>
> val = read_gicreg(ICH_VTR_EL2);
> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
> index bc7010db9f4d..df1503650300 100644
> --- a/virt/kvm/arm/vgic/vgic-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-v3.c
> @@ -373,12 +373,19 @@ void vgic_v3_load(struct kvm_vcpu *vcpu)
> {
> struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
>
> - kvm_call_hyp(__vgic_v3_write_vmcr, cpu_if->vgic_vmcr);
> + /*
> + * If dealing with a GICv2 emulation on GICv3, VMCR_EL2.VFIQen
> + * is dependent on ICC_SRE_EL1.SRE, and we have to perform the
> + * VMCR_EL2 save/restore in the world switch.
> + */
> + if (likely(cpu_if->vgic_sre))
> + kvm_call_hyp(__vgic_v3_write_vmcr, cpu_if->vgic_vmcr);
> }
>
> void vgic_v3_put(struct kvm_vcpu *vcpu)
> {
> struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
>
> - cpu_if->vgic_vmcr = kvm_call_hyp(__vgic_v3_read_vmcr);
> + if (likely(cpu_if->vgic_sre))
> + cpu_if->vgic_vmcr = kvm_call_hyp(__vgic_v3_read_vmcr);
> }
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH 4.9 41/69] irqchip/irq-imx-gpcv2: Fix spinlock initialization
From: Greg Kroah-Hartman @ 2017-04-19 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419141616.919951169@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tyler Baker <tyler.baker@linaro.org>
commit 75eb5e1e7b4edbc8e8f930de59004d21cb46961f upstream.
The raw_spinlock in the IMX GPCV2 interupt chip is not initialized before
usage. That results in a lockdep splat:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
Add the missing raw_spin_lock_init() to the setup code.
Fixes: e324c4dc4a59 ("irqchip/imx-gpcv2: IMX GPCv2 driver for wakeup sources")
Signed-off-by: Tyler Baker <tyler.baker@linaro.org>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Cc: jason at lakedaemon.net
Cc: marc.zyngier at arm.com
Cc: shawnguo at kernel.org
Cc: andrew.smirnov at gmail.com
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/20170413222731.5917-1-tyler.baker at linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/irq-imx-gpcv2.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -230,6 +230,8 @@ static int __init imx_gpcv2_irqchip_init
return -ENOMEM;
}
+ raw_spin_lock_init(&cd->rlock);
+
cd->gpc_base = of_iomap(node, 0);
if (!cd->gpc_base) {
pr_err("fsl-gpcv2: unable to map gpc registers\n");
^ permalink raw reply
* [PATCH 4.10 49/69] irqchip/irq-imx-gpcv2: Fix spinlock initialization
From: Greg Kroah-Hartman @ 2017-04-19 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419141555.114738231@linuxfoundation.org>
4.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tyler Baker <tyler.baker@linaro.org>
commit 75eb5e1e7b4edbc8e8f930de59004d21cb46961f upstream.
The raw_spinlock in the IMX GPCV2 interupt chip is not initialized before
usage. That results in a lockdep splat:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
Add the missing raw_spin_lock_init() to the setup code.
Fixes: e324c4dc4a59 ("irqchip/imx-gpcv2: IMX GPCv2 driver for wakeup sources")
Signed-off-by: Tyler Baker <tyler.baker@linaro.org>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Cc: jason at lakedaemon.net
Cc: marc.zyngier at arm.com
Cc: shawnguo at kernel.org
Cc: andrew.smirnov at gmail.com
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/20170413222731.5917-1-tyler.baker at linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/irq-imx-gpcv2.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -230,6 +230,8 @@ static int __init imx_gpcv2_irqchip_init
return -ENOMEM;
}
+ raw_spin_lock_init(&cd->rlock);
+
cd->gpc_base = of_iomap(node, 0);
if (!cd->gpc_base) {
pr_err("fsl-gpcv2: unable to map gpc registers\n");
^ permalink raw reply
* [PATCH v6 6/8] coresight: add support for CPU debug module
From: Suzuki K Poulose @ 2017-04-19 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419142812.GA16160@leoy-linaro>
On 19/04/17 15:28, Leo Yan wrote:
> Hi Suzuki,
>
> On Wed, Apr 19, 2017 at 02:23:04PM +0100, Suzuki K Poulose wrote:
>> Hi Leo,
>>
>> This version looks good to me. I have two minor comments below.
>
> Thanks for reviewing. Will take the suggestions. Just check a bit for
> last comment.
>
> [...]
>
>>> +static int debug_probe(struct amba_device *adev, const struct amba_id *id)
>>> +{
>>> + void __iomem *base;
>>> + struct device *dev = &adev->dev;
>>> + struct debug_drvdata *drvdata;
>>> + struct resource *res = &adev->res;
>>> + struct device_node *np = adev->dev.of_node;
>>> + int ret;
>>> +
>>> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
>>> + if (!drvdata)
>>> + return -ENOMEM;
>>> +
>>> + drvdata->cpu = np ? of_coresight_get_cpu(np) : 0;
>>> + if (per_cpu(debug_drvdata, drvdata->cpu)) {
>>> + dev_err(dev, "CPU%d drvdata has been initialized\n",
>>> + drvdata->cpu);
>>
>> May be we could warn about a possible issue in the DT ?
>
> So can I understand the suggestion is to add warning in function
> of_coresight_get_cpu() when cannot find CPU number, and here directly
> bail out?
No. One could have single CPU DT, where he doesn't need to provide the CPU number.
Hence, it doesn't make sense to WARN in of_coresight_get_cpu().
But when we hit the case above, we find that the some node was registered for
the given CPU (be it 0 or any other), which is definitely an error in DT. Due to
1) Hasn't specified the CPU number for more than one node
OR
2) CPU number duplicated in the more than one nodes.
Cheers
Suzuki
^ permalink raw reply
* [PATCH v6 6/8] coresight: add support for CPU debug module
From: Leo Yan @ 2017-04-19 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5c5cb6f8-1dcb-8a9d-1605-c006656005eb@arm.com>
Hi Suzuki,
On Wed, Apr 19, 2017 at 02:23:04PM +0100, Suzuki K Poulose wrote:
> Hi Leo,
>
> This version looks good to me. I have two minor comments below.
Thanks for reviewing. Will take the suggestions. Just check a bit for
last comment.
[...]
> >+static int debug_probe(struct amba_device *adev, const struct amba_id *id)
> >+{
> >+ void __iomem *base;
> >+ struct device *dev = &adev->dev;
> >+ struct debug_drvdata *drvdata;
> >+ struct resource *res = &adev->res;
> >+ struct device_node *np = adev->dev.of_node;
> >+ int ret;
> >+
> >+ drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> >+ if (!drvdata)
> >+ return -ENOMEM;
> >+
> >+ drvdata->cpu = np ? of_coresight_get_cpu(np) : 0;
> >+ if (per_cpu(debug_drvdata, drvdata->cpu)) {
> >+ dev_err(dev, "CPU%d drvdata has been initialized\n",
> >+ drvdata->cpu);
>
> May be we could warn about a possible issue in the DT ?
So can I understand the suggestion is to add warning in function
of_coresight_get_cpu() when cannot find CPU number, and here directly
bail out?
Thanks,
Leo Yan
^ permalink raw reply
* [PATCH net-next 1/4] ixgbe: sparc: rename the ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER
From: Gabriele Paoloni @ 2017-04-19 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DCFFD3C52@AcuExch.aculab.com>
Hi David
Many thanks for your reply
> -----Original Message-----
> From: David Laight [mailto:David.Laight at ACULAB.COM]
> Sent: 18 April 2017 14:26
> To: Gabriele Paoloni; davem at davemloft.net
> Cc: Catalin Marinas; Will Deacon; Mark Rutland; Robin Murphy;
> jeffrey.t.kirsher at intel.com; alexander.duyck at gmail.com; linux-arm-
> kernel at lists.infradead.org; netdev at vger.kernel.org; Dingtianhong;
> Linuxarm
> Subject: RE: Re: [PATCH net-next 1/4] ixgbe: sparc: rename the
> ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER
>
> From: Gabriele Paoloni
> > Sent: 13 April 2017 10:11
> > > > Till now only the Intel ixgbe could support enable
> > > > Relaxed ordering in the drivers for special architecture,
> > > > but the ARCH_WANT_RELAX_ORDER is looks like a general name
> > > > for all arch, so rename to a specific name for intel
> > > > card looks more appropriate.
> > > >
> > > > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> > >
> > > This is not a driver specific facility.
> > >
> > > Any driver can test this symbol and act accordingly.
> > >
> > > Just because IXGBE is the first and only user, doesn't mean
> > > the facility is driver specific.
> >
> >
> > Please correct me if I am wrong but my understanding is that the
> standard
> > way to enable/disable relaxed ordering is to set/clear bit 4 of the
> Device
> > Control Register (PCI_EXP_DEVCTL_RELAX_EN 0x0010 /* Enable relaxed
> > ordering */).
> > Now I have looked up for all drivers either enabling or disabling
> relaxed
> > ordering and none of them seems to need a symbol to decide whether to
> > enable it or not.
> > Also it seems to me enabling/disabling relaxed ordering is never
> bound to the
> > host architecture.
> >
> > So why this should be (or it is expected to be) a generic symbol?
> > Wouldn't it be more correct to have this as a driver specific symbol
> now and
> > move it to a generic one later once we have other drivers requiring
> it?
>
> 'Relaxed ordering' is a bit in the TLP header.
> A device (like the ixgbe hardware) can set it for some transactions and
> still have the transactions 'ordered enough' for the driver to work.
> (If all transactions have 'relaxed ordering' set then I suspect it is
> almost impossible to write a working driver.)
> The host side could (probably does) have a bit to enable 'relaxed
> ordering',
> it could also enforce stronger ordering than required by the PCIe spec
> (eg keeping reads in order).
My understanding is that from the host side the host is always allowed
(as long as it complies with the rules specified in sec.2.4.1 of the PCIe
Specs) to set the RO attribute in the TLP and the target function should
be abel to cope with it.
On the device side the device is allowed to set the RO attribute in the
TLP only if bit4 of the "Device Control Register" is set.
>
> Clearly, on some sparc64 systems, ixgbe needs to use 'relaxed
> ordering'.
> To me this requires two separate bits be enabled:
> 1) to the ixgbe driver to generate the 'relaxed' TLP.
> 2) to the host to actually act on them.
My understanding is that for performance reasons when possible we
should enable relaxed ordering and I think this is up to the host
(i.e. the host somehow should know when he is capable of handling
RO TLPs and therefore it will try to enable it on the driver)
> If the ixgbe driver works when both are enabled why have options to
> disable either (except for bug-finding)?
I think that by default the ixgbe driver disable RO since there are
issues with "some chipsets" according to commit 3d5c520727ce "ixgbe:
move disabling of relaxed ordering in start_hw()".
What this means is a bit obscure to me and seems to be not related to
the host architecture
Also looking at where and why the other drivers set/clear the "Enable
Relaxed Ordering" bit it seems that currently this is not tied to the
host architecture nor to any global symbol; instead it seems purely
dependent on the PCIe device chipset itself.
>
> David
^ permalink raw reply
* [PATCH 2/2] arm64: Fix power-of-ten vs. power-of-two prefixes in comments etc.
From: Olof Johansson @ 2017-04-19 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418141312.GD27592@e104818-lin.cambridge.arm.com>
On Tue, Apr 18, 2017 at 03:13:12PM +0100, Catalin Marinas wrote:
> On Mon, Apr 17, 2017 at 01:54:49PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Apr 17, 2017 at 1:12 AM, Simon Horman <horms@verge.net.au> wrote:
> > > On Thu, Apr 13, 2017 at 01:18:58PM +0100, David Woodhouse wrote:
> > >> Less important than in user-visible messages, but still good practice as
> > >> there's still no excuse for ARM64 code to look like it was written before
> > >> 1996.
> > >>
> > >> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> > >
> > > Hi David,
> > >
> > > I'd be happy to take the Renesas portions of this change if they were
> > > broken out into a separate patch. The reason I would prefer a separate
> > > patch is to avoid the possibility of conflicts, even trivial ones.
> >
> > s/possibility/reality/, unless this series goes in before v4.12-rc1.
>
> Maybe the arm-soc guys can take both patches on top of the other series
> they pull, in which case, for both patches:
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Sure, please resend to arm at kernel.org with collected acks.
-Olo
^ permalink raw reply
* [PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G
From: Olof Johansson @ 2017-04-19 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492603726250.cnoz1xemvxpkp3sd4toaurm2@android.mail.163.com>
Hi,
On Wed, Apr 19, 2017 at 08:09:00PM +0800, Lyra Zhang wrote:
> Hi Arnd, Olof, Could you please take this patch through arm-soc git if
> there are no further comments? (The three other patches in this series
> have been taken by Greg.) Thanks, Chunyan On
First, something bad seems to have happened with this email, the formatting
was all wrapped and it was hard to read. You might want to look into it so
you can avoid more problems like it in the future.
That being said, we can apply the patches but please re-send the series to
arm at kernel.org with any acks received added, etc.
Thanks!
-Olof
^ permalink raw reply
* [PATCH V3] PM / OPP: Use - instead of @ for DT entries
From: Olof Johansson @ 2017-04-19 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <734c5d5a66ef8a5505f368fc68a8ab9c02d710f9.1492492253.git.viresh.kumar@linaro.org>
Hi Viresh,
On Tue, Apr 18, 2017 at 10:44:50AM +0530, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> (sunxi)
> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> (uniphier)
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Tony Lindgren <tony@atomide.com>
We've already turned down other patches that does this in a sweeping manner
like this, since they tend to be conflict prone with other DT changes.
Please split per platform and merge with each maintainer.
Thanks,
-Olof
^ permalink raw reply
* [PATCH v3 0/7] ARM: Fix dma_alloc_coherent() and friends for NOMMU
From: Vladimir Murzin @ 2017-04-19 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419115658.GD5077@suse.de>
On 19/04/17 12:56, Joerg Roedel wrote:
> On Tue, Apr 18, 2017 at 01:51:35PM +0100, Vladimir Murzin wrote:
>> FYI, nothing has changed since last "ping" - Andr?s and Alexandre are still
>> dependant on this series to safely enable DMA on their platforms. It is really
>> scary that these patches do not move forward even though they are supposed to
>> fix the real issue :(
>
> That's probably because you didn't include all relevant people in this
> post. I think patches the patches for dma-noop.c should go through
> Andrew Morton.
>
Thanks for suggestion, Joerg! Andrew is already in the loop.
I'm wondering if there is better way/tool to get relevant people except
get_maintainer.pl?
./scripts/get_maintainer.pl -f lib/dma-noop.c
Bart Van Assche <bart.vanassche@sandisk.com> (commit_signer:3/3=100%,authored:2/3=67%,added_lines:2/7=29%,removed_lines:2/6=33%)
Vineet Gupta <vgupta@synopsys.com> (commit_signer:2/3=67%)
Robin Murphy <robin.murphy@arm.com> (commit_signer:2/3=67%)
Doug Ledford <dledford@redhat.com> (commit_signer:2/3=67%)
Joerg Roedel <jroedel@suse.de> (commit_signer:2/3=67%)
Krzysztof Kozlowski <krzk@kernel.org> (authored:1/3=33%,added_lines:5/7=71%,removed_lines:4/6=67%)
linux-kernel at vger.kernel.org (open list)
./scripts/get_maintainer.pl -f drivers/base/dma-coherent.c
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (supporter:DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS)
linux-kernel at vger.kernel.org (open list)
Cheers
Vladimir
>
>
> Joerg
>
>
^ permalink raw reply
* [PATCH v3 5/7] ARM: NOMMU: Introduce dma operations for noMMU
From: Vladimir Murzin @ 2017-04-19 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a37QAZNp9hvbM10EjMNnTsiiN-Z3u8o=883bev4Th-iOQ@mail.gmail.com>
On 19/04/17 11:10, Arnd Bergmann wrote:
> On Fri, Mar 10, 2017 at 10:23 AM, Vladimir Murzin
> <vladimir.murzin@arm.com> wrote:
>> R/M classes of cpus can have memory covered by MPU which in turn might
>> configure RAM as Normal i.e. bufferable and cacheable. It breaks
>> dma_alloc_coherent() and friends, since data can stuck in caches now
>> or be buffered.
>>
>> This patch factors out DMA support for NOMMU configuration into
>> separate entity which provides dedicated dma_ops. We have to handle
>> there several cases:
>> - configurations with MMU/MPU setup
>> - configurations without MMU/MPU setup
>> - special case for M-class, since caches and MPU there are optional
>>
>> In general we rely on default DMA area for coherent allocations or/and
>> per-device memory reserves suitable for coherent DMA, so if such
>> regions are set coherent allocations go from there.
>>
>> In case MPU/MPU was not setup we fallback to normal page allocator for
>> DMA memory allocation.
>>
>> In case we run M-class cpus, for configuration without cache support
>> (like Cortex-M3/M4) dma operations are forced to be coherent and wired
>> with dma-noop (such decision is made based on cacheid global
>> variable); however, if caches are detected there and no DMA coherent
>> region is given (either default or per-device), dma is disallowed even
>> MPU is not set - it is because M-class implement system memory map
>> which defines part of address space as Normal memory.
>>
>> Reported-by: Alexandre Torgue <alexandre.torgue@st.com>
>> Reported-by: Andras Szemzo <sza@esh.hu>
>> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
>> Tested-by: Andras Szemzo <sza@esh.hu>
>> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com>
>> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>
> I thought I found a couple of problems with this, but after reading more
> carefully I was wrong about all of them and I think the code is doing
> exactly the right thing. I also like the way this is split out into a separate
> set of dma_map_ops to simplify the normal MMU case.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
Much appreciated!
Vladimir
^ permalink raw reply
* [GIT PULL] Allwinner H5 DT changes for 4.12
From: Maxime Ripard @ 2017-04-19 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419124552.GT17004@localhost>
Hi Olof,
On Wed, Apr 19, 2017 at 05:45:52AM -0700, Olof Johansson wrote:
> On Thu, Apr 06, 2017 at 11:37:48AM +0200, Maxime Ripard wrote:
> > Hi Arnd, Olof,
> >
> > Here is a serie of patches a bit unusual for the next merge window.
> >
> > Allwinner released a new SoC, the H5, that is basically an H3 with
> > arm64 CPU cores (A53 instead of A7).
> >
> > In order to support it properly, we've created a common DTSI, and
> > built on top. Since that DTSI is spread across arm and arm64, it took
> > a bit of rework (all the patches in that PR until commit da89e1d5cbaf
> > ("ARM: sunxi: h3/h5: add usb_otg and OHCI/EHCI for usbc0 on H3/H5"))
> > that is shared with the PR I just sent with the H3-only patches.
> >
> > The patches on top of that commit are H5-specific commits (new boards,
> > new features) and should be merged through your arm64 DT branch.
> >
> > Thanks,
> > Maxime
> >
> > The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
> >
> > Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
> >
> > are available in the git repository at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt-h5-for-4.12
> >
> > for you to fetch changes up to d7bb5b966174fee6e4b0085124b75787a5d81b8a:
> >
> > ARM: sunxi: h3/h5: switch apb0-related clocks to r_ccu (2017-04-04 17:45:24 +0200)
> >
> > ----------------------------------------------------------------
> > Allwinner H5 DT changes for 4.12
> >
> > H5 patches for 4.12, which are mostly related to reworking the H3 DTSI to
> > be usable on the arm64 H5 DTSI, that shares almost everything with the H3
> > but the CPU cores.
> >
> > We then have patches to support the H5 boards on top.
> >
> > ----------------------------------------------------------------
> > Andre Przywara (3):
> > arm: sun8i: h3: split Allwinner H3 .dtsi
> > arm64: allwinner: h5: add Allwinner H5 .dtsi
> > arm64: allwinner: h5: add support for the Orange Pi PC 2 board
> >
> > Icenowy Zheng (6):
> > arm: sun8i: h3: drop skeleton.dtsi inclusion in H3 DTSI
> > arm: sun8i: h3: drop pinctrl-a10.h inclusion for H3 DTSI
> > arm: sun8i: h3: correct the GIC compatible in H3 to gic-400
> > ARM: sunxi: h3/h5: add usb_otg and OHCI/EHCI for usbc0 on H3/H5
> > arm64: allwinner: h5: enable USB OTG on Orange Pi PC 2 board
> > ARM: sunxi: h3/h5: switch apb0-related clocks to r_ccu
> >
> > arch/arm/boot/dts/sun8i-h3.dtsi | 602 ++-------------------
> > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 601 ++++++++++++++++++++
> > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > .../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 188 +++++++
> > arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 124 +++++
> > arch/arm64/boot/dts/allwinner/sunxi-h3-h5.dtsi | 1 +
> > 6 files changed, 955 insertions(+), 562 deletions(-)
> > create mode 100644 arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > create mode 120000 arch/arm64/boot/dts/allwinner/sunxi-h3-h5.dtsi
>
> So, I really don't like these symlinks. We had some discussions here:
>
> https://marc.info/?m=147547436324674&w=2
>
> Given my lack of attention on this, it's obviously way late in the release
> cycle to ask you to respin so I'll merge this branch as-is right now.
>
> What I'll do though, is that I'll apply that patch that sets up those
> symlinks here, and may I ask that you revisit right after -rc1 with
> a pull request that moves over to that model? I.e. the arm64 dts
> would then include <arm/sunxi-h3-h5.dtsi> instead.
I'll do it.
Thanks!
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170419/3a31b68b/attachment.sig>
^ permalink raw reply
* [PATCH v3 7/7] ARM: dma-mapping: Remove traces of NOMMU code
From: Vladimir Murzin @ 2017-04-19 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a3ogS9RyxqOvxN1EQi2BWo-bpMVHasgY=eh48RMhmzVWw@mail.gmail.com>
On 19/04/17 10:56, Arnd Bergmann wrote:
> On Fri, Mar 10, 2017 at 10:23 AM, Vladimir Murzin
> <vladimir.murzin@arm.com> wrote:
>> DMA operations for NOMMU case have been just factored out into
>> separate compilation unit, so don't keep dead code.
>>
>> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
>> Tested-by: Andras Szemzo <sza@esh.hu>
>> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>
> The patch is "obviously correct" after the previous changes,
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
Thanks!
Vladimir
^ 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