* [PATCHv3 8/8] ARM: configs: stm32: Add RTC support in STM32 defconfig
From: Alexandre Torgue @ 2017-01-16 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483623809-29937-9-git-send-email-amelie.delaunay@st.com>
Hi Am?lie,
On 01/05/2017 02:43 PM, Amelie Delaunay wrote:
> This patch adds STM32 RTC support in stm32_defconfig file.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> arch/arm/configs/stm32_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
> index be19e09..0acff9e 100644
> --- a/arch/arm/configs/stm32_defconfig
> +++ b/arch/arm/configs/stm32_defconfig
> @@ -57,6 +57,8 @@ CONFIG_LEDS_CLASS=y
> CONFIG_LEDS_GPIO=y
> CONFIG_LEDS_TRIGGERS=y
> CONFIG_LEDS_TRIGGER_HEARTBEAT=y
> +CONFIG_RTC_CLASS=y
> +CONFIG_RTC_DRV_STM32=y
> CONFIG_DMADEVICES=y
> CONFIG_STM32_DMA=y
> # CONFIG_FILE_LOCKING is not set
>
Applied on stm32-defconfig-for-v4.11
thanks
Alex
^ permalink raw reply
* [Question] A question about arm64 pte
From: Catalin Marinas @ 2017-01-16 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b7a9bd2-37af-40cd-b723-9e648fbbc7c8@huawei.com>
On Mon, Jan 16, 2017 at 08:39:56PM +0800, Yisheng Xie wrote:
> On 2017/1/16 19:56, Catalin Marinas wrote:
> > On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
> >> I have question about arm64 pte.
> >
> > I assume the context is ARMv8.0 (without hardware DBM support).
>
> Yes.
> >
> >> For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
> >> and PTE_DIRTY is to mark whether the page is dirty.
> >> However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.
> >
> > That's what set_pte_at() does.
> >
>
> So if we mmap a memory region use /dev/mem like:
> fildes = open("/dev/mem", O_RDWR | O_CREAT, 0777);
> addr = mmap(NULL, LEN, PROT_READ | PROT_WRITE, MAP_SHARED, fildes, offset);
>
> The PTE_RDONLY will be set? Right ?
Possibly, I haven't checked mmap_mem(). However, that's what you would
get with an anonymous mmap() as well.
> However?when use memset to write the region it still works well, and
> the bit PTE_RDONLY is also cleared. Is there anywhere clear the
> PTE_RDONLY before write that page ?
See handle_pte_fault(). On the first access to a writable+clean page
(PTE_WRITE set, PTE_RDONLY set, PTE_DIRTY cleared), the kernel traps it
and, if pte_write() is true (your case), it calls pte_mkdirty(). The
subsequently called ptep_set_access_flags() function would clear
PTE_RDONLY, giving you a writable mapping.
--
Catalin
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Will Deacon @ 2017-01-16 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116162225-mutt-send-email-mst@kernel.org>
On Mon, Jan 16, 2017 at 04:27:28PM +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 16, 2017 at 02:21:03PM +0000, Will Deacon wrote:
> > On Mon, Jan 16, 2017 at 04:18:03PM +0200, Michael S. Tsirkin wrote:
> > > On Mon, Jan 16, 2017 at 10:40:28AM +0000, Will Deacon wrote:
> > > > On Fri, Jan 13, 2017 at 08:23:35PM +0200, Michael S. Tsirkin wrote:
> > > > > On Fri, Jan 13, 2017 at 05:21:54PM +0000, Will Deacon wrote:
> > > > > > On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote:
> > > > > > > On Fri, Jan 13, 2017 at 09:25:22AM +0000, Will Deacon wrote:
> > > > > > > > On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> > > > > > > > > I'd rather people didn't use SMMU with legacy devices.
> > > > > > > >
> > > > > > > > I'm afraid we've been doing that for two years and the model already
> > > > > > > > exists in a mature state, being actively used for development and
> > > > > > > > validation by ARM and our partners. One of the big things its used for
> > > > > > > > is to develop SMMU and GIC (our interrupt controller) code with PCI, so
> > > > > > > > dropping the SMMU from the picture isn't an option.
> > > > > > >
> > > > > > > Oh so this fixes a regression? This is something I didn't realize.
> > > > > >
> > > > > > Yes, thanks. The regression came about because we implemented SMMU-backed
> > > > > > DMA ops and only then was it apparent that the virtio stuff was bypassing
> > > > > > even with translation enabled (because it wasn't using the DMA API).
> > > > >
> > > > > Could you point out a commit ID?
> > > >
> > > > There has been a fair amount of work in this area recently, but you're
> > > > probably after something like 876945dbf649 ("arm64: Hook up IOMMU dma_ops")
> > > > as the culprit, which is the point at which we started to swizzle DMA
> > > > ops for devices upstream of an SMMU automatically.
> > > >
> > > > > > > A "Fixes:" tag can't hurt here. I then wonder
> > > > > > > might DMA ops ever use a DMA address which isn't a physical address
> > > > > > > from QEMU point of view? If that happens, this hack breaks
> > > > > > > because in legacy mode QEMU still uses the GPA.
> > > > > >
> > > > > > If QEMU doesn't advertise an SMMU, then it will work fine with the GPA,
> > > > > > because we won't swizzle the DMA ops for the master device. If QEMU does
> > > > > > advertise an SMMU, then we'll allocate DMA addresses to fit within the
> > > > > > the intersection of the SMMU aperture and device's DMA mask.
> > > > >
> > > > >
> > > > > Right but doesn't just poking from qemu into phys addresses work
> > > > > anymore? It used to ...
> > > >
> > > > Provided that there's no SMMU, then it will continue to work. and my
> > > > understanding (from talking to Peter Maydell) is that qemu doesn't model
> > > > an SMMU for ARM-based machines.
> > > >
> > >
> > > So how come people report failures due to presence of SMMU?
> > > Using some other hypervisor?
> >
> > The failures are reported on the ARM fastmodel (a complete system
> > emulation that runs on an x86 box), where an SMMU *is* present
> > downstream of the virtio-pci masters. There's no qemu involved there.
> >
> I see. And this hypervisor actually coded up looking up
> translations in the SMMU unconditionally for legacy devices,
> and this worked as long as guest didn't touch the SMMU?
Well, the fastmodel isn't a hypervisor really. It's a full system emulation,
so it's better to think of it like a piece of hardware. For example, you
could run KVM on the fastmodel. But yes, when Linux didn't swizzle the
DMA ops to point at the SMMU, then everything defaults to bypass (because
that's the default behaviour of the SMMU driver -- this is configurable
on the command line) which is why things used to work.
Will
^ permalink raw reply
* [PATCH 03/10] devicetree: bindings: add bindings for ahci-da850
From: Bartosz Golaszewski @ 2017-01-16 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d8406f53-b97d-ca9a-f7d1-94ce5b7064f7@ti.com>
2017-01-16 13:45 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
> On Monday 16 January 2017 03:43 PM, Bartosz Golaszewski wrote:
>> 2017-01-13 20:25 GMT+01:00 David Lechner <david@lechnology.com>:
>>>
>>> A clock multiplier property seems redundant if you are specifying a clock.
>>> It should be possible to get the rate from the clock to determine which
>>> multiplier is needed.
>>>
>>
>> I probably should have named it differently. This is not a multiplier
>> of a clock derived from PLL0 or PLL1. Instead it's a value set by
>> writing to the Port PHY Control Register (MPY bits) of the SATA
>> controller that configures the multiplier for the external low-jitter
>> clock. On the lcdk the signals (REFCLKP, REFCLKN) are provided by
>> CDCM61001 (SATA OSCILLATOR component on the schematics).
>>
>> I'll find a better name and comment the property accordingly.
>>
>> FYI: the da850 platform does not use the common clock framework, so I
>> don't specify the clock property on the sata node in the device tree.
>> Instead I add the clock lookup entry in patch [01/10]. This is
>> transparent for AHCI which can get the clock as usual by calling
>> clk_get() in ahci_platform_get_resources().
>
> I think David's point is that the SATA_REFCLK needs to be modeled as a
> actual clock input to the IP. You should be able to get the rate using
> clk_get_rate() and make the MPY bits calculation depending on the
> incoming rate.
>
> You should be able to model the clock even when not using common clock
> framework.
>
> DA850 AHCI does not use a con_id at the moment (it assumes a single
> clock), and that needs to change.
>
It's true that once davinci gets ported (is this planned?) to using
the common clock framework, we could just create a fixed-clock node in
da850-lcdk for the SATA oscillator, so the new property is redundant.
What I don't get is how should I model a clock that is not
configurable and is board-specific? Is hard-coding the relevant rate
in da850.c with a huge FIXME the right way?
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH v2 3/3] reset: zx2967: add reset controller driver for ZTE's zx2967 family
From: Jun Nie @ 2017-01-16 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484564194-18530-3-git-send-email-baoyou.xie@linaro.org>
On 2017?01?16? 18:56, Baoyou Xie wrote:
> This patch adds reset controller driver for ZTE's zx2967 family.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> ---
> drivers/reset/Kconfig | 6 +++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-zx2967.c | 125 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 132 insertions(+)
> create mode 100644 drivers/reset/reset-zx2967.c
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 172dc96..f4cdfe9 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -86,6 +86,12 @@ config RESET_UNIPHIER
> Say Y if you want to control reset signals provided by System Control
> block, Media I/O block, Peripheral Block.
>
> +config RESET_ZX2967
> + bool "ZTE ZX2967 Reset Driver"
> + depends on ARCH_ZX || COMPILE_TEST
> + help
> + This enables the reset controller driver for ZTE's zx2967 family.
> +
> config RESET_ZYNQ
> bool "ZYNQ Reset Driver" if COMPILE_TEST
> default ARCH_ZYNQ
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 13b346e..2cd3f6c 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -13,4 +13,5 @@ obj-$(CONFIG_RESET_STM32) += reset-stm32.o
> obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
> obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
> obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
> +obj-$(CONFIG_RESET_ZX2967) += reset-zx2967.o
> obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
> diff --git a/drivers/reset/reset-zx2967.c b/drivers/reset/reset-zx2967.c
> new file mode 100644
> index 0000000..bc95261
> --- /dev/null
> +++ b/drivers/reset/reset-zx2967.c
> @@ -0,0 +1,125 @@
> +/*
> + * ZTE's zx2967 family reset controller driver
> + *
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie <baoyou.xie@linaro.org>
> + *
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset-controller.h>
> +
> +struct zx2967_reset {
> + void __iomem *reg_base;
> + spinlock_t lock;
> + struct reset_controller_dev rcdev;
> +};
> +
> +static int zx2967_reset_act(struct reset_controller_dev *rcdev,
> + unsigned long id, bool assert)
> +{
> + struct zx2967_reset *reset = NULL;
> + u32 bank = id / 32;
> + u32 offset = id % 32;
> + u32 reg;
> + unsigned long flags;
> +
> + reset = container_of(rcdev, struct zx2967_reset, rcdev);
> +
> + spin_lock_irqsave(&reset->lock, flags);
> +
> + reg = readl(reset->reg_base + (bank * 4));
readl_relaxed is recommended.
> + if (assert)
> + reg &= ~BIT(offset);
> + else
> + reg |= BIT(offset);
> + writel(reg, reset->reg_base + (bank * 4));
writel_relaxed is recommended.
> +
> + spin_unlock_irqrestore(&reset->lock, flags);
> +
> + return 0;
> +}
> +
> +static int zx2967_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + return zx2967_reset_act(rcdev, id, true);
> +}
> +
> +static int zx2967_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + return zx2967_reset_act(rcdev, id, false);
> +}
> +
> +static struct reset_control_ops zx2967_reset_ops = {
> + .assert = zx2967_reset_assert,
> + .deassert = zx2967_reset_deassert,
> +};
> +
> +static int zx2967_reset_probe(struct platform_device *pdev)
> +{
> + struct zx2967_reset *reset;
> + struct resource *res;
> +
> + reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
> + if (!reset)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + reset->reg_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(reset->reg_base))
> + return PTR_ERR(reset->reg_base);
> +
> + spin_lock_init(&reset->lock);
> +
> + reset->rcdev.owner = THIS_MODULE;
> + reset->rcdev.nr_resets = resource_size(res) * 8;
> + reset->rcdev.ops = &zx2967_reset_ops;
> + reset->rcdev.of_node = pdev->dev.of_node;
> +
> + dev_info(&pdev->dev, "reset controller cnt:%d",
> + reset->rcdev.nr_resets);
> +
> + return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
> +}
> +
> +static int zx2967_reset_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}
> +
> +static const struct of_device_id zx2967_reset_dt_ids[] = {
> + { .compatible = "zte,zx296718-reset", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, zx2967_reset_dt_ids);
> +
> +static struct platform_driver zx2967_reset_driver = {
> + .probe = zx2967_reset_probe,
> + .remove = zx2967_reset_remove,
> + .driver = {
> + .name = "zx2967-reset",
> + .of_match_table = zx2967_reset_dt_ids,
> + },
> +};
This line can replace all below code if you do not have any other
dependency in earlier stage.
builtin_platform_driver(zx2967_reset_driver);
> +
> +static int __init zx2967_reset_init(void)
> +{
> + return platform_driver_register(&zx2967_reset_driver);
> +}
> +arch_initcall(zx2967_reset_init);
> +
> +static void __exit zx2967_reset_exit(void)
> +{
> + platform_driver_unregister(&zx2967_reset_driver);
> +}
> +module_exit(zx2967_reset_exit);
> +
> +MODULE_AUTHOR("Baoyou Xie <baoyou.xie@linaro.org>");
> +MODULE_DESCRIPTION("ZTE zx2967 Reset Controller Driver");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Michael S. Tsirkin @ 2017-01-16 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116142103.GF1510@arm.com>
On Mon, Jan 16, 2017 at 02:21:03PM +0000, Will Deacon wrote:
> On Mon, Jan 16, 2017 at 04:18:03PM +0200, Michael S. Tsirkin wrote:
> > On Mon, Jan 16, 2017 at 10:40:28AM +0000, Will Deacon wrote:
> > > On Fri, Jan 13, 2017 at 08:23:35PM +0200, Michael S. Tsirkin wrote:
> > > > On Fri, Jan 13, 2017 at 05:21:54PM +0000, Will Deacon wrote:
> > > > > On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote:
> > > > > > On Fri, Jan 13, 2017 at 09:25:22AM +0000, Will Deacon wrote:
> > > > > > > On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> > > > > > > > I'd rather people didn't use SMMU with legacy devices.
> > > > > > >
> > > > > > > I'm afraid we've been doing that for two years and the model already
> > > > > > > exists in a mature state, being actively used for development and
> > > > > > > validation by ARM and our partners. One of the big things its used for
> > > > > > > is to develop SMMU and GIC (our interrupt controller) code with PCI, so
> > > > > > > dropping the SMMU from the picture isn't an option.
> > > > > >
> > > > > > Oh so this fixes a regression? This is something I didn't realize.
> > > > >
> > > > > Yes, thanks. The regression came about because we implemented SMMU-backed
> > > > > DMA ops and only then was it apparent that the virtio stuff was bypassing
> > > > > even with translation enabled (because it wasn't using the DMA API).
> > > >
> > > > Could you point out a commit ID?
> > >
> > > There has been a fair amount of work in this area recently, but you're
> > > probably after something like 876945dbf649 ("arm64: Hook up IOMMU dma_ops")
> > > as the culprit, which is the point at which we started to swizzle DMA
> > > ops for devices upstream of an SMMU automatically.
> > >
> > > > > > A "Fixes:" tag can't hurt here. I then wonder
> > > > > > might DMA ops ever use a DMA address which isn't a physical address
> > > > > > from QEMU point of view? If that happens, this hack breaks
> > > > > > because in legacy mode QEMU still uses the GPA.
> > > > >
> > > > > If QEMU doesn't advertise an SMMU, then it will work fine with the GPA,
> > > > > because we won't swizzle the DMA ops for the master device. If QEMU does
> > > > > advertise an SMMU, then we'll allocate DMA addresses to fit within the
> > > > > the intersection of the SMMU aperture and device's DMA mask.
> > > >
> > > >
> > > > Right but doesn't just poking from qemu into phys addresses work
> > > > anymore? It used to ...
> > >
> > > Provided that there's no SMMU, then it will continue to work. and my
> > > understanding (from talking to Peter Maydell) is that qemu doesn't model
> > > an SMMU for ARM-based machines.
> > >
> >
> > So how come people report failures due to presence of SMMU?
> > Using some other hypervisor?
>
> The failures are reported on the ARM fastmodel (a complete system
> emulation that runs on an x86 box), where an SMMU *is* present
> downstream of the virtio-pci masters. There's no qemu involved there.
>
> Will
I see. And this hypervisor actually coded up looking up
translations in the SMMU unconditionally for legacy devices,
and this worked as long as guest didn't touch the SMMU?
--
MST
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Christopher Covington @ 2017-01-16 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111184555.GF29247@leverpostej>
Hi Mark,
On 01/11/2017 01:45 PM, Mark Rutland wrote:
> On Wed, Jan 11, 2017 at 12:40:42PM -0600, Timur Tabi wrote:
>> On 01/11/2017 12:37 PM, Mark Rutland wrote:
>>> The name, as it is, is perfectly descriptive.
>>>
>>> Let's not sacrifice legibility over a non-issue.
>>
>> I don't want to kick a dead horse or anything, but changing it to
>> QCOM_FLKR_ERRATUM_1003 would eliminate all the spacing problems
>> without sacrificing anything.
>
> The CPU is called "Falkor", not "FLKR", and we're not coming up with an
> ACPI table name...
>
> The ARM Ltd. erratum numbers are global to all parts, so we don't
> include the part name. Is the 1003 erratum number specific to Falkor?
>
> If it's global, you could use QCOM_ERRATUM_1003 instead.
E1003 is specific to Falkor, and hopefully just its first major revision.
Qualcomm Technology's first/previous generation ARMv8 custom
microarchitecture used errata numbers below 1000. I am not aware of
global coordination in the numbering, unfortunately.
> Otherwise, QCOM_FALKOR_ERRATUM_1003 is preferable.
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [GIT PULL] Amlogic fixes for v4.10-rc4
From: Andreas Färber @ 2017-01-16 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2inpi6d09.fsf@baylibre.com>
Am 13.01.2017 um 19:17 schrieb Kevin Hilman:
> ----------------------------------------------------------------
> Amlogic fixes for v4.10-rc4
> - odroid-c2: disable DVFS to avoid crashes due to broken SCPI
> - fix misc. crashes by adding known reserved memory regions
>
> ----------------------------------------------------------------
> Neil Armstrong (2):
> ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
> ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
Objection against the latter patch introducing widespread usage of
hardcoded linux,usable-memory properties - please review closely before
considering to merge.
Thanks,
Andreas
>
> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 5 -----
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 ++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 10 +++++++++-
> arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 9 +++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 9 +++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 5 -----
> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 9 +++++++++
> arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 9 +++++++++
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 9 +++++++++
> arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 9 +++++++++
> 18 files changed, 111 insertions(+), 19 deletions(-)
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH v7 15/15] irqchip: mbigen: Add ACPI support
From: Hanjun Guo @ 2017-01-16 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116113804.GB23703@red-moon>
Hi Lorenzo,
On 2017/1/16 19:38, Lorenzo Pieralisi wrote:
> On Sat, Jan 14, 2017 at 10:56:54AM +0800, Hanjun Guo wrote:
>> Hi Lorenzo,
>>
>> On 2017/1/13 18:21, Lorenzo Pieralisi wrote:
>>> On Wed, Jan 11, 2017 at 11:06:39PM +0800, Hanjun Guo wrote:
>>>> With the preparation of platform msi support and interrupt producer
>>>> in DSDT, we can add mbigen ACPI support now.
>>>>
>>>> We are using _PRS methd to indicate number of irq pins instead
>>>> of num_pins in DT to avoid _DSD usage in this case.
>>>>
>>>> For mbi-gen,
>>>> Device(MBI0) {
>>>> Name(_HID, "HISI0152")
>>>> Name(_UID, Zero)
>>>> Name(_CRS, ResourceTemplate() {
>>>> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
>>>> })
>>>>
>>>> Name (_PRS, ResourceTemplate() {
>>>> Interrupt(ResourceProducer,...) {12,14,....}
>>> I still do not understand why you are using _PRS for this, I think
>>> the MBIgen configuration is static and if it is so the Interrupt
>>> resource should be part of the _CRS unless there is something I am
>>> missing here.
>> Sorry for not clear in the commit message. MBIgen is an interrupt producer
>> which produces irq resource to devices connecting to it, and MBIgen itself
>> don't consume wired interrupts.
> That's why you mark it as ResourceProducer, but that's not a reason to
> put it in the _PRS instead of _CRS.
If using _CRS for the interrupt resource, the irq number represented will be mapped
(i.e acpi_register_gsi()), then will conflict with the irq number of devices consuming
it (mbigen is producing the interrupts), but I agree with you that let's ask Rafael's
point of view.
>
> IIUC _PRS is there to provide a way to define the possible resource
> settings of a _configurable_ device (ie programmable) so that the actual
> resource value you would programme with a call to its _SRS is sane (ie
> the OS has a way, through the _PRS, to detect what possible resource
> settings are available for the device).
>
> I think Rafael has more insights into how the _PRS is used on x86
> systems so I would ask his point of view here before merrily merging
> this code.
OK, Rafael is traveling now, hope he will have time to take a look.
How about updating this patch set then sending a new version for review
with this patch unchanged? if Rafael have comments on this one, I will
send a single updated one for this patch (if no other changes).
>
>> Also devices connecting MBIgen may not consume all the interrupts produced
>> by MBIgen, for example, MBIgen may produce 128 interrupts but only half of
>> them are currently used, so _PRS here means "provide interrupt resources
>> may consumed by devices connecting to it".
> See above.
Thanks
Hanjun
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Will Deacon @ 2017-01-16 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116161639-mutt-send-email-mst@kernel.org>
On Mon, Jan 16, 2017 at 04:18:03PM +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 16, 2017 at 10:40:28AM +0000, Will Deacon wrote:
> > On Fri, Jan 13, 2017 at 08:23:35PM +0200, Michael S. Tsirkin wrote:
> > > On Fri, Jan 13, 2017 at 05:21:54PM +0000, Will Deacon wrote:
> > > > On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote:
> > > > > On Fri, Jan 13, 2017 at 09:25:22AM +0000, Will Deacon wrote:
> > > > > > On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> > > > > > > I'd rather people didn't use SMMU with legacy devices.
> > > > > >
> > > > > > I'm afraid we've been doing that for two years and the model already
> > > > > > exists in a mature state, being actively used for development and
> > > > > > validation by ARM and our partners. One of the big things its used for
> > > > > > is to develop SMMU and GIC (our interrupt controller) code with PCI, so
> > > > > > dropping the SMMU from the picture isn't an option.
> > > > >
> > > > > Oh so this fixes a regression? This is something I didn't realize.
> > > >
> > > > Yes, thanks. The regression came about because we implemented SMMU-backed
> > > > DMA ops and only then was it apparent that the virtio stuff was bypassing
> > > > even with translation enabled (because it wasn't using the DMA API).
> > >
> > > Could you point out a commit ID?
> >
> > There has been a fair amount of work in this area recently, but you're
> > probably after something like 876945dbf649 ("arm64: Hook up IOMMU dma_ops")
> > as the culprit, which is the point at which we started to swizzle DMA
> > ops for devices upstream of an SMMU automatically.
> >
> > > > > A "Fixes:" tag can't hurt here. I then wonder
> > > > > might DMA ops ever use a DMA address which isn't a physical address
> > > > > from QEMU point of view? If that happens, this hack breaks
> > > > > because in legacy mode QEMU still uses the GPA.
> > > >
> > > > If QEMU doesn't advertise an SMMU, then it will work fine with the GPA,
> > > > because we won't swizzle the DMA ops for the master device. If QEMU does
> > > > advertise an SMMU, then we'll allocate DMA addresses to fit within the
> > > > the intersection of the SMMU aperture and device's DMA mask.
> > >
> > >
> > > Right but doesn't just poking from qemu into phys addresses work
> > > anymore? It used to ...
> >
> > Provided that there's no SMMU, then it will continue to work. and my
> > understanding (from talking to Peter Maydell) is that qemu doesn't model
> > an SMMU for ARM-based machines.
> >
>
> So how come people report failures due to presence of SMMU?
> Using some other hypervisor?
The failures are reported on the ARM fastmodel (a complete system
emulation that runs on an x86 box), where an SMMU *is* present
downstream of the virtio-pci masters. There's no qemu involved there.
Will
^ permalink raw reply
* [PATCH 2/3] KVM: arm64: Access CNTHCTL_EL2 bit fields correctly on VHE systems
From: Suzuki K Poulose @ 2017-01-16 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c82f705e-c32a-15b1-92f6-d7694f91fe0e@arm.com>
On 16/01/17 14:11, Marc Zyngier wrote:
> On 16/01/17 13:30, Marc Zyngier wrote:
>> On 13/01/17 14:56, Suzuki K Poulose wrote:
>>> On 13/01/17 13:30, Marc Zyngier wrote:
>>>> [+ Suzuki, who wrote the whole cpus_have_const_cap thing]
>>>>
>>
>> [...]
>>
>>>> But maybe we should have have some stronger guarantees that we'll
>>>> always get things inlined, and that the "const" side is enforced:
>>>
>>> Agreed.
>>>
>>>>
>>>> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
>>>> index b4989df..4710469 100644
>>>> --- a/arch/arm64/include/asm/cpufeature.h
>>>> +++ b/arch/arm64/include/asm/cpufeature.h
>>>> @@ -105,10 +105,11 @@ static inline bool cpu_have_feature(unsigned int num)
>>>> }
>>>>
>>>> /* System capability check for constant caps */
>>>> -static inline bool cpus_have_const_cap(int num)
>>>> +static __always_inline bool cpus_have_const_cap(int num)
>>>
>>> I think we should have the above change and make it inline always.
>>>
>>>> {
>>>> - if (num >= ARM64_NCAPS)
>>>> - return false;
>>>> + BUILD_BUG_ON(!__builtin_constant_p(num));
>>>
>>> This is not needed, as the compilation would fail if num is not a constant with
>>> static key code.
>
> I also just checked this, and it doesn't fail if the compiler doesn't
> directly supports jump labels (we then fallback to the static key being
> a standard memory access).
Ah, I missed that part of the story. Sorry about that. Please go ahead with the
changes. I had a similar check in my first version and was dropped later with a
similar review comment. We hadn't considered older tool chain.
Suzuki
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Michael S. Tsirkin @ 2017-01-16 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116104028.GA1510@arm.com>
On Mon, Jan 16, 2017 at 10:40:28AM +0000, Will Deacon wrote:
> On Fri, Jan 13, 2017 at 08:23:35PM +0200, Michael S. Tsirkin wrote:
> > On Fri, Jan 13, 2017 at 05:21:54PM +0000, Will Deacon wrote:
> > > On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote:
> > > > On Fri, Jan 13, 2017 at 09:25:22AM +0000, Will Deacon wrote:
> > > > > On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> > > > > > I'd rather people didn't use SMMU with legacy devices.
> > > > >
> > > > > I'm afraid we've been doing that for two years and the model already
> > > > > exists in a mature state, being actively used for development and
> > > > > validation by ARM and our partners. One of the big things its used for
> > > > > is to develop SMMU and GIC (our interrupt controller) code with PCI, so
> > > > > dropping the SMMU from the picture isn't an option.
> > > >
> > > > Oh so this fixes a regression? This is something I didn't realize.
> > >
> > > Yes, thanks. The regression came about because we implemented SMMU-backed
> > > DMA ops and only then was it apparent that the virtio stuff was bypassing
> > > even with translation enabled (because it wasn't using the DMA API).
> >
> > Could you point out a commit ID?
>
> There has been a fair amount of work in this area recently, but you're
> probably after something like 876945dbf649 ("arm64: Hook up IOMMU dma_ops")
> as the culprit, which is the point at which we started to swizzle DMA
> ops for devices upstream of an SMMU automatically.
>
> > > > A "Fixes:" tag can't hurt here. I then wonder
> > > > might DMA ops ever use a DMA address which isn't a physical address
> > > > from QEMU point of view? If that happens, this hack breaks
> > > > because in legacy mode QEMU still uses the GPA.
> > >
> > > If QEMU doesn't advertise an SMMU, then it will work fine with the GPA,
> > > because we won't swizzle the DMA ops for the master device. If QEMU does
> > > advertise an SMMU, then we'll allocate DMA addresses to fit within the
> > > the intersection of the SMMU aperture and device's DMA mask.
> >
> >
> > Right but doesn't just poking from qemu into phys addresses work
> > anymore? It used to ...
>
> Provided that there's no SMMU, then it will continue to work. and my
> understanding (from talking to Peter Maydell) is that qemu doesn't model
> an SMMU for ARM-based machines.
>
> Will
So how come people report failures due to presence of SMMU?
Using some other hypervisor?
--
MST
^ permalink raw reply
* [PATCH V9 0/3] irqchip: qcom: Add IRQ combiner driver
From: Marc Zyngier @ 2017-01-16 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <266105963441d1cdddeaf40c4b78c239@codeaurora.org>
On 16/01/17 14:07, Agustin Vega-Frias wrote:
> Hi Rafael,
>
> On 2017-01-03 16:56, Rafael J. Wysocki wrote:
>> On Tue, Jan 3, 2017 at 4:19 PM, Agustin Vega-Frias
>> <agustinv@codeaurora.org> wrote:
>>> Hi,
>>>
>>> Is there any more feedback on this beyond Lorenzo's suggestion to drop
>>> the conditional check on the first patch?
>>> How can we move forward on this series?
>>
>> Essentially, I need to convince myself that patches [1-2/3] are fine
>> which hasn't happened yet.
>
> Pinging again. Do you have any questions that might help with your
> review? I have some minor changes I have to make to the driver itself
> (patch 3) and I'd like to submit any changes you might want along with
> those.
I'd like to add that these two initial patches are now a prerequisite
for Hanjun's series, so it'd be good to have an idea of where we're
going on that front.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 2/3] KVM: arm64: Access CNTHCTL_EL2 bit fields correctly on VHE systems
From: Marc Zyngier @ 2017-01-16 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61f7dbf1-e20d-e9e4-950c-6a224619cf31@arm.com>
On 16/01/17 13:30, Marc Zyngier wrote:
> On 13/01/17 14:56, Suzuki K Poulose wrote:
>> On 13/01/17 13:30, Marc Zyngier wrote:
>>> [+ Suzuki, who wrote the whole cpus_have_const_cap thing]
>>>
>
> [...]
>
>>> But maybe we should have have some stronger guarantees that we'll
>>> always get things inlined, and that the "const" side is enforced:
>>
>> Agreed.
>>
>>>
>>> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
>>> index b4989df..4710469 100644
>>> --- a/arch/arm64/include/asm/cpufeature.h
>>> +++ b/arch/arm64/include/asm/cpufeature.h
>>> @@ -105,10 +105,11 @@ static inline bool cpu_have_feature(unsigned int num)
>>> }
>>>
>>> /* System capability check for constant caps */
>>> -static inline bool cpus_have_const_cap(int num)
>>> +static __always_inline bool cpus_have_const_cap(int num)
>>
>> I think we should have the above change and make it inline always.
>>
>>> {
>>> - if (num >= ARM64_NCAPS)
>>> - return false;
>>> + BUILD_BUG_ON(!__builtin_constant_p(num));
>>
>> This is not needed, as the compilation would fail if num is not a constant with
>> static key code.
I also just checked this, and it doesn't fail if the compiler doesn't
directly supports jump labels (we then fallback to the static key being
a standard memory access).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] IOMMU: SMMUv2: Support for Extended Stream ID (16 bit)
From: Aleksey Makarov @ 2017-01-16 14:11 UTC (permalink / raw)
To: linux-arm-kernel
Enable the Extended Stream ID feature when available.
This patch on top of series "KVM PCIe/MSI passthrough on ARM/ARM64
and IOVA reserved regions" by Eric Auger [1] allows to passthrough
an external PCIe network card on a ThunderX server successfully.
Without this patch that card caused a warning like
pci 0006:90:00.0: stream ID 0x9000 out of range for SMMU (0x7fff)
during boot.
[1] https://lkml.kernel.org/r/1484127714-3263-1-git-send-email-eric.auger at redhat.com
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
---
v2:
- remove unnecessary parentheses (Robin Murphy)
- refactor testing SMR fields to after setting sCR0 as theirs width
depends on sCR0_EXIDENABLE (Robin Murphy)
v1 (rfc):
https://lkml.kernel.org/r/20170110115755.19102-1-aleksey.makarov at linaro.org
drivers/iommu/arm-smmu.c | 67 ++++++++++++++++++++++++++++++++++--------------
1 file changed, 48 insertions(+), 19 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 13d26009b8e0..c33df4083d24 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -24,6 +24,7 @@
* - v7/v8 long-descriptor format
* - Non-secure access to the SMMU
* - Context fault reporting
+ * - Extended Stream ID (16 bit)
*/
#define pr_fmt(fmt) "arm-smmu: " fmt
@@ -87,6 +88,7 @@
#define sCR0_CLIENTPD (1 << 0)
#define sCR0_GFRE (1 << 1)
#define sCR0_GFIE (1 << 2)
+#define sCR0_EXIDENABLE (1 << 3)
#define sCR0_GCFGFRE (1 << 4)
#define sCR0_GCFGFIE (1 << 5)
#define sCR0_USFCFG (1 << 10)
@@ -126,6 +128,7 @@
#define ID0_NUMIRPT_MASK 0xff
#define ID0_NUMSIDB_SHIFT 9
#define ID0_NUMSIDB_MASK 0xf
+#define ID0_EXIDS (1 << 8)
#define ID0_NUMSMRG_SHIFT 0
#define ID0_NUMSMRG_MASK 0xff
@@ -169,6 +172,7 @@
#define ARM_SMMU_GR0_S2CR(n) (0xc00 + ((n) << 2))
#define S2CR_CBNDX_SHIFT 0
#define S2CR_CBNDX_MASK 0xff
+#define S2CR_EXIDVALID (1 << 10)
#define S2CR_TYPE_SHIFT 16
#define S2CR_TYPE_MASK 0x3
enum arm_smmu_s2cr_type {
@@ -354,6 +358,7 @@ struct arm_smmu_device {
#define ARM_SMMU_FEAT_FMT_AARCH64_64K (1 << 9)
#define ARM_SMMU_FEAT_FMT_AARCH32_L (1 << 10)
#define ARM_SMMU_FEAT_FMT_AARCH32_S (1 << 11)
+#define ARM_SMMU_FEAT_EXIDS (1 << 12)
u32 features;
#define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
@@ -1051,7 +1056,7 @@ static void arm_smmu_write_smr(struct arm_smmu_device *smmu, int idx)
struct arm_smmu_smr *smr = smmu->smrs + idx;
u32 reg = smr->id << SMR_ID_SHIFT | smr->mask << SMR_MASK_SHIFT;
- if (smr->valid)
+ if (!(smmu->features & ARM_SMMU_FEAT_EXIDS) && smr->valid)
reg |= SMR_VALID;
writel_relaxed(reg, ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_SMR(idx));
}
@@ -1063,6 +1068,9 @@ static void arm_smmu_write_s2cr(struct arm_smmu_device *smmu, int idx)
(s2cr->cbndx & S2CR_CBNDX_MASK) << S2CR_CBNDX_SHIFT |
(s2cr->privcfg & S2CR_PRIVCFG_MASK) << S2CR_PRIVCFG_SHIFT;
+ if (smmu->features & ARM_SMMU_FEAT_EXIDS && smmu->smrs &&
+ smmu->smrs[idx].valid)
+ reg |= S2CR_EXIDVALID;
writel_relaxed(reg, ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_S2CR(idx));
}
@@ -1073,6 +1081,35 @@ static void arm_smmu_write_sme(struct arm_smmu_device *smmu, int idx)
arm_smmu_write_smr(smmu, idx);
}
+/*
+ * The width of SMR's mask field depends on sCR0_EXIDENABLE, so this function
+ * should be called after sCR0 is written.
+ */
+static void arm_smmu_test_smr_masks(struct arm_smmu_device *smmu)
+{
+ void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+ u32 smr;
+
+ if (!smmu->smrs)
+ return;
+
+ /*
+ * SMR.ID bits may not be preserved if the corresponding
+ * MASK bits are set, so check each one separately.
+ * We can reject masters later if they try to claim IDs
+ * outside these masks.
+ */
+ smr = smmu->streamid_mask << SMR_ID_SHIFT;
+ writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
+ smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
+ smmu->streamid_mask = smr >> SMR_ID_SHIFT;
+
+ smr = smmu->streamid_mask << SMR_MASK_SHIFT;
+ writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
+ smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
+ smmu->smr_mask_mask = smr >> SMR_MASK_SHIFT;
+}
+
static int arm_smmu_find_sme(struct arm_smmu_device *smmu, u16 id, u16 mask)
{
struct arm_smmu_smr *smrs = smmu->smrs;
@@ -1674,6 +1711,9 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
if (smmu->features & ARM_SMMU_FEAT_VMID16)
reg |= sCR0_VMID16EN;
+ if (smmu->features & ARM_SMMU_FEAT_EXIDS)
+ reg |= sCR0_EXIDENABLE;
+
/* Push the button */
__arm_smmu_tlb_sync(smmu);
writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
@@ -1761,11 +1801,14 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
"\t(IDR0.CTTW overridden by FW configuration)\n");
/* Max. number of entries we have for stream matching/indexing */
- size = 1 << ((id >> ID0_NUMSIDB_SHIFT) & ID0_NUMSIDB_MASK);
+ if (smmu->version == ARM_SMMU_V2 && id & ID0_EXIDS) {
+ smmu->features |= ARM_SMMU_FEAT_EXIDS;
+ size = 1 << 16;
+ } else {
+ size = 1 << ((id >> ID0_NUMSIDB_SHIFT) & ID0_NUMSIDB_MASK);
+ }
smmu->streamid_mask = size - 1;
if (id & ID0_SMS) {
- u32 smr;
-
smmu->features |= ARM_SMMU_FEAT_STREAM_MATCH;
size = (id >> ID0_NUMSMRG_SHIFT) & ID0_NUMSMRG_MASK;
if (size == 0) {
@@ -1774,21 +1817,6 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
return -ENODEV;
}
- /*
- * SMR.ID bits may not be preserved if the corresponding MASK
- * bits are set, so check each one separately. We can reject
- * masters later if they try to claim IDs outside these masks.
- */
- smr = smmu->streamid_mask << SMR_ID_SHIFT;
- writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
- smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
- smmu->streamid_mask = smr >> SMR_ID_SHIFT;
-
- smr = smmu->streamid_mask << SMR_MASK_SHIFT;
- writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
- smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
- smmu->smr_mask_mask = smr >> SMR_MASK_SHIFT;
-
/* Zero-initialised to mark as invalid */
smmu->smrs = devm_kcalloc(smmu->dev, size, sizeof(*smmu->smrs),
GFP_KERNEL);
@@ -2120,6 +2148,7 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
iommu_register_instance(dev->fwnode, &arm_smmu_ops);
platform_set_drvdata(pdev, smmu);
arm_smmu_device_reset(smmu);
+ arm_smmu_test_smr_masks(smmu);
/* Oh, for a proper bus abstraction */
if (!iommu_present(&platform_bus_type))
--
2.11.0
^ permalink raw reply related
* [RFC PATCH] IOMMU: SMMUv2: Support for Extended Stream ID (16 bit)
From: Aleksey Makarov @ 2017-01-16 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <63d66004-bf8c-146d-2af4-b5f035159480@arm.com>
On 01/11/2017 05:15 PM, Robin Murphy wrote:
> On 10/01/17 11:57, Aleksey Makarov wrote:
>> Enable the Extended Stream ID feature when available.
>>
>> This patch on top of series "[PATCH v7 00/19] KVM PCIe/MSI passthrough
>> on ARM/ARM64 and IOVA reserved regions" by Eric Auger allows
>> to passthrough an external PCIe network card on a ThunderX server
>> successfully.
>>
>> Without this patch that card caused a warning like
>>
>> pci 0006:90:00.0: stream ID 0x9000 out of range for SMMU (0x7fff)
>>
>> during boot.
>>
>> Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
>> ---
>> drivers/iommu/arm-smmu.c | 53 +++++++++++++++++++++++++++++++++---------------
>> 1 file changed, 37 insertions(+), 16 deletions(-)
>>
[...]
>> @@ -1761,7 +1772,12 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
>> "\t(IDR0.CTTW overridden by FW configuration)\n");
>>
>> /* Max. number of entries we have for stream matching/indexing */
>> - size = 1 << ((id >> ID0_NUMSIDB_SHIFT) & ID0_NUMSIDB_MASK);
>> + if (smmu->version == ARM_SMMU_V2 && id & ID0_EXIDS) {
>> + smmu->features |= ARM_SMMU_FEAT_EXIDS;
>> + size = (1 << 16);
>
> Unnecessary parentheses.
Thank you
>> + } else {
>> + size = 1 << ((id >> ID0_NUMSIDB_SHIFT) & ID0_NUMSIDB_MASK);
>> + }
>
> Given what the architecture says about the relationship between EXIDS
> and NUMSIDB, I suppose an even shorter version could be:
>
> if (smmu->version == ARM_SMMU_V2 && id & ID0_EXIDS)
> size *= 2;
>
> but I'm not sure that's actually any nicer to read.
I think it is not nicer: the one who reads this needs to know what is the value of NUMSIDB
in the case id & ID0_EXIDS == true; and also this makes the code depend on this, i. e.
on the correct implementation of hardware.
So I would like to leave it as is. If you are not agree, I will change it.
>> smmu->streamid_mask = size - 1;
>> if (id & ID0_SMS) {
>> u32 smr;
>> @@ -1774,20 +1790,25 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
>> return -ENODEV;
>> }
>>
>> - /*
>> - * SMR.ID bits may not be preserved if the corresponding MASK
>> - * bits are set, so check each one separately. We can reject
>> - * masters later if they try to claim IDs outside these masks.
>> - */
>> - smr = smmu->streamid_mask << SMR_ID_SHIFT;
>> - writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
>> - smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
>> - smmu->streamid_mask = smr >> SMR_ID_SHIFT;
>> -
>> - smr = smmu->streamid_mask << SMR_MASK_SHIFT;
>> - writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
>> - smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
>> - smmu->smr_mask_mask = smr >> SMR_MASK_SHIFT;
>> + if (smmu->features & ARM_SMMU_FEAT_EXIDS) {
>> + smmu->smr_mask_mask = smmu->streamid_mask;
>> + } else {
>> + /*
>> + * SMR.ID bits may not be preserved if the corresponding
>> + * MASK bits are set, so check each one separately.
>> + * We can reject masters later if they try to claim IDs
>> + * outside these masks.
>> + */
>> + smr = smmu->streamid_mask << SMR_ID_SHIFT;
>> + writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
>> + smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
>> + smmu->streamid_mask = smr >> SMR_ID_SHIFT;
>> +
>> + smr = smmu->streamid_mask << SMR_MASK_SHIFT;
>> + writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
>> + smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
>> + smmu->smr_mask_mask = smr >> SMR_MASK_SHIFT;
>> + }
>
> This hunk is quite possibly wrong. I don't see any guarantee in the
> architecture that all EXMASK/EXID bits *must* be implemented, and even
> so there's still no harm in the driver determining that experimentally.
> It looks like we need a bit of refactoring such that we move the probing
> of SMR fields to after counting and allocating the SME structures, then
> in the EXIDS case we can explicitly clear the SMEs and poke EXIDENABLE
> inbetween.
I am not quite sure I understand where you are suggesting to poke EXIDENABLE.
I am going to send v2 of the patch, I'd appreciate if you would review that please.
Thank you for review
Aleksey Makarov
^ permalink raw reply
* [PATCH V9 0/3] irqchip: qcom: Add IRQ combiner driver
From: Agustin Vega-Frias @ 2017-01-16 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0h_v-iER5Fffdoczj4CAhetGYqOfJOhdO561_kNCnsEFg@mail.gmail.com>
Hi Rafael,
On 2017-01-03 16:56, Rafael J. Wysocki wrote:
> On Tue, Jan 3, 2017 at 4:19 PM, Agustin Vega-Frias
> <agustinv@codeaurora.org> wrote:
>> Hi,
>>
>> Is there any more feedback on this beyond Lorenzo's suggestion to drop
>> the conditional check on the first patch?
>> How can we move forward on this series?
>
> Essentially, I need to convince myself that patches [1-2/3] are fine
> which hasn't happened yet.
Pinging again. Do you have any questions that might help with your
review? I have some minor changes I have to make to the driver itself
(patch 3) and I'd like to submit any changes you might want along with
those.
Thanks,
Agustin
>
> Thanks,
> Rafael
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
From: Andreas Färber @ 2017-01-16 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9a1dbb0b-ad3d-7898-3b43-fd8f85892985@baylibre.com>
Am 16.01.2017 um 11:26 schrieb Neil Armstrong:
> On 01/15/2017 04:44 PM, Andreas F?rber wrote:
>> Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
>>> it really makes a difference if we write
>>>
>>> memory at 0 {
>>> device_type = "memory";
>>> linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>>> };
>>>
>>> or
>>>
>>> memory at 0 {
>>> device_type = "memory";
>>> reg = <0x0 0x1000000 0x0 0x7f000000>;
>>> };
>>>
>>> The second version leads to failure of the Odroid C2.
>>>
>>> When I looked at /sys/firmware/fdt I saw this difference:
>>>
>>> --- fails
>>> +++ works
>>>
>>> memory at 0 {
>>> - device_type = "memory";
>>> reg = <0x0 0x0 0x0 0x78000000>;
>>> + device_type = "memory";
>>> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>>> };
>>>
>>> I found the following sentence in the NXP forum:
>>> In case you want to overwrite the memory usage passed from u-boot, you
>>> can use "linux,usable-memory".
>>> https://community.nxp.com/thread/382284
>>
>> The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
>> instead of forcing the creation of unnecessary new .dts files onto
>> everyone due to hardcoded linux,usable-memory properties. In fact, it
>> already reserves 0x1000000, so it seems you are merely using an older
>> U-Boot.
>>
>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39
>>
>> I would bet that the upper limit is unrelated here.
>>
>> Regards,
>> Andreas
>>
>
> Hi Andreas,
>
> I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
> a lot of u-boot version in the field, and the Odroid-C2 is part of this.
>
> Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using
> any U-boot version even with the one provided by Amlogic on their openlinux distribution channel.
That is not the position of the kernel maintainers though. They
deliberately rely on timers being enabled before entering Linux, which
broke my afboot-stm32 (which I could fix) as well as s5pv210 and vf610
based platforms by F+S (which remain broken to date).
And I documented how to chainload mainline U-Boot from downstream
Amlogic U-Boot, so it is easily fixable on Meson. The only thing missing
is Carlo resubmitting his MMC patches.
A bug somewhere does not justify breaking the whole Meson-gx* .dts
design for everyone, especially not without CC'ing me as the original
creator!
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH v3 16/24] media: Add i.MX media core driver
From: Philipp Zabel @ 2017-01-16 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a94025b4-c4dd-de51-572e-d2615a7246e4@gmail.com>
On Sat, 2017-01-14 at 14:46 -0800, Steve Longerbeam wrote:
[...]
> >> +Unprocessed Video Capture:
> >> +--------------------------
> >> +
> >> +Send frames directly from sensor to camera interface, with no
> >> +conversions:
> >> +
> >> +-> ipu_smfc -> camif
> > I'd call this capture interface, this is not just for cameras. Or maybe
> > idmac if you want to mirror hardware names?
>
> Camif is so named because it is the V4L2 user interface for video
> capture. I suppose it could be named "capif", but that doesn't role
> off the tongue quite as well.
Agreed, capif sounds weird. I find camif a bit confusing though, because
Samsung S3C has a camera interface that is actually called "CAMIF".
> >> +Note the ipu_smfc can do pixel reordering within the same colorspace.
> > That isn't a feature of the SMFC, but of the IDMAC (FCW & FCR).
>
> yes, the doc is re-worded to make that more clear.
>
> >> +For example, its sink pad can take UYVY2X8, but its source pad can
> >> +output YUYV2X8.
> > I don't think this is correct. Re-reading "37.4.3.7 Packing to memory"
> > in the CSI chapter, for 8-bit per component data, the internal format
> > between CSI, SMFC, and IDMAC is always some 32-bit RGBx/YUVx variant
> > (or "bayer/generic data"). In either case, the internal format does not
> > change along the way.
>
> these are pixels in memory buffers, not the IPU internal formats.
As long as we are talking about the CSI -> SMFC -> IDMAC path, these
should be IPU internal formats. How else would one choose between 8-bit
companded RGB, and 16-bit expanded RGB for a 10-bit per component input
signal? This is the same issue as in the next comment.
> >> + media-ctl -V "\"camif0\":0 [fmt:UYVY2X8/640x480]"
> >> + media-ctl -V "\"camif0\":1 [fmt:UYVY2X8/640x480]"
> >> + # Configure pads for OV5640 pipeline
> >> + media-ctl -V "\"ov5640_mipi 1-0040\":0 [fmt:UYVY2X8/640x480]"
> >> + media-ctl -V "\"imx-mipi-csi2\":0 [fmt:UYVY2X8/640x480]"
> >> + media-ctl -V "\"imx-mipi-csi2\":2 [fmt:UYVY2X8/640x480]"
> >> + media-ctl -V "\"ipu1_csi1\":0 [fmt:UYVY2X8/640x480]"
> >> + media-ctl -V "\"ipu1_csi1\":1 [fmt:UYVY2X8/640x480]"
> > [...]
> >> + media-ctl -V "\"camif1\":0 [fmt:UYVY2X8/640x480]"
> > I agree this looks very intuitive, but technically correct for the
> > csi1:1 and camif1:0 pads would be a 32-bit YUV format.
> > (MEDIA_BUS_FMT_YUV8_1X32_PADLO doesn't exist yet).
> >
> > I think it would be better to use the correct format
>
> I'm not sure I follow you here.
The ov5640 sends UYVY2X8 on the wire, so pads "ov5640_mipi 1-0040":0
up to "ipu1_csi1":0 are correct. But the CSI writes 32-bit YUV values
into the SMFC, so the CSI output pad and the IDMAC input pad should have
a YUV8_1X32 format.
Chapter 37.4.2.3 "FCW & FCR - Format converter write and read" in the
IDMAC chapter states that all internal submodules only work on 8-bit per
component formats with four components: YUVA or RGBA.
> > [...]
> > Is this a whole software buffer queue implementation? I thought the
> > whole point of putting the custom mem2mem framework into the capture
> > driver was to use the hardware FSU channel linking?
>
> see below.
>
> > What is the purpose of this if the sink should be triggered by the FSU?
>
> Ok, here is where I need to make an admission.
>
> The only FSU links I have attempted (and which currently have entries
> in the fsu_link_info[] table), are the enc/vf/pp --> IRT links for rotation.
Which are not described as media entity links because the rotation units
do not have separate media entities. So me arguing against handling
mem2mem chaining via media entity links doesn't concern these implicit
links.
> There does not appear to be support in the FSU for linking a write channel
> to the VDIC read channels (8, 9, 10) according to VDI_SRC_SEL field. There
> is support for the direct link from CSI (which I am using), but that's
> not an
> IDMAC channel link.
>
> There is a PRP_SRC_SEL field, with linking from IDMAC (SMFC) channels
> 0..2 (and 3? it's not clear, and not clear whether this includes channel 1).
As I read it, that is 0 and 2 only, no idea why. But since there are
only 2 CSIs, that shouldn't be a problem.
> But I think this links to channel 12, and not to channels 8,9,10 to the
> VDIC.
> Or will it? It's worth experimenting. It would have helped if FSL listed
> which
> IDMAC channels these FSU links correspond to, instead of making us guess
> at it.
I would have assumed that the FSU triggering only works on 1:1 channels
and the VDIC with its three input channels is different. But then
there's the alleged VDOA link to ch8/9/10 ro ch9, depending on
VDI_MOT_SEL.
This makes me more convinced that the CSI -> VDIC link should only
describe the direct path (real-time mode, single field).
> In any event, the docs are not clear enough to implement a real FSU
> link to the VDIC read channels, if it's even possible. And trying to get
> programming help from FSL can be difficult, and no coding examples
> for this link AFAIK.
>
> So I ended resorted to linking to VDIC channels 8,9,10 with a software
> approach, instead of attempting a hardware FSU link.
>
> The EOF interrupt handler for the SMFC channels informs the VDIC
> entity via a v4l2_subdev_ioctl() call that a buffer is available. The
> VDIC then manually kicks off its read channels to bring that buffer
> (and a previous buffer for F(n-1) field) into the VDIC.
>
> There is a small amount of extra overhead going this route compared
> to a FSU hardware link: there is the EOF irq latency (a few usec), and
> the CPU overhead for the VDIC to manually start the read channels,
> which is also a few usec at most (see prepare_vdi_in_buffers() in
> imx-vdic.c). So in total at most ~10 usec of extra overhead (CPU
> use plus irq latency) under normal system load.
That the same low overhead could be reached by linking videobuf2 queues
of different video devices, that would be a lot more flexible.
> Of course, in order to implement this software link, I had to implement
> a straightforward FIFO dma buffer ring. The sink (VDIC) allocates the ring
> at stream on, and the source requests a pointer to this ring in its own
> stream on. Passing buffers from source to sink then follows a
> straightforward
> FIFO queue/done/dequeue/queue model: sink queues buffers to src, src
> grabs queued buffers and makes them active, src signals completed
> buffers to sink, sink dequeues buffers in response, and sink queues
> buffers back when it is finished with them.
Thank you for the explanation.
[...]
> >> +static const u32 power_off_seq[] = {
> >> + IMX_MEDIA_GRP_ID_IC_PP,
> >> + IMX_MEDIA_GRP_ID_IC_PRPVF,
> >> + IMX_MEDIA_GRP_ID_IC_PRPENC,
> >> + IMX_MEDIA_GRP_ID_SMFC,
> >> + IMX_MEDIA_GRP_ID_CSI,
> >> + IMX_MEDIA_GRP_ID_VIDMUX,
> >> + IMX_MEDIA_GRP_ID_SENSOR,
> >> + IMX_MEDIA_GRP_ID_CSI2,
> >> +};
> > This seems somewhat arbitrary. Why is a power sequence needed?
>
> The CSI-2 receiver must be powered up before the sensor, that's the
> only requirement IIRC. The others have no s_power requirement. So I
> can probably change this to power up in the frontend -> backend order
> (IC_PP to sensor). And vice-versa for power off.
Yes, I think that should work (see below).
> > [...]
> >> +/*
> >> + * Turn current pipeline power on/off starting from start_entity.
> >> + * Must be called with mdev->graph_mutex held.
> >> + */
> >> +int imx_media_pipeline_set_power(struct imx_media_dev *imxmd,
> >> + struct media_entity_graph *graph,
> >> + struct media_entity *start_entity, bool on)
> >> +{
> >> + struct media_entity *entity;
> >> + struct v4l2_subdev *sd;
> >> + int i, ret = 0;
> >> + u32 id;
> >> +
> >> + for (i = 0; i < NUM_POWER_ENTITIES; i++) {
> >> + id = on ? power_on_seq[i] : power_off_seq[i];
> >> + entity = find_pipeline_entity(imxmd, graph, start_entity, id);
> >> + if (!entity)
> >> + continue;
> >> +
> >> + sd = media_entity_to_v4l2_subdev(entity);
> >> +
> >> + ret = v4l2_subdev_call(sd, core, s_power, on);
> >> + if (ret && ret != -ENOIOCTLCMD)
> >> + break;
> >> + }
> >> +
> >> + return (ret && ret != -ENOIOCTLCMD) ? ret : 0;
> >> +}
> >> +EXPORT_SYMBOL_GPL(imx_media_pipeline_set_power);
> > This should really be handled by v4l2_pipeline_pm_use.
>
> I thought about this earlier, but v4l2_pipeline_pm_use() seems to be
> doing some other stuff that bothered me, at least that's what I remember.
> I will revisit this.
I have used it with a tc358743 -> mipi-csi2 pipeline, it didn't cause
any problems. It would be better to reuse and, if necessary, fix the
existing infrastructure where available.
> >> +int imx_media_add_internal_subdevs(struct imx_media_dev *imxmd,
> >> + struct imx_media_subdev *csi[4])
> >> +{
> >> + int ret;
> >> +
> >> + /* there must be at least one CSI in first IPU */
> > Why?
>
> Well yeah, imx-media doesn't necessarily need a CSI if things
> like the VDIC or post-processor are being used by an output
> overlay pipeline, for example. I'll fix this.
I haven't even thought that far, but there could be boards with only a
parallel sensor connected to IPU2 CSI1 and IPU1 disabled for power
saving reasons.
regards
Philipp
^ permalink raw reply
* [PATCH] arm64: defconfig: disable CONFIG_DEVMEM
From: Leif Lindholm @ 2017-01-16 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115124254.GF25883@bivouac.eciton.net>
On Sun, Jan 15, 2017 at 12:42:54PM +0000, Leif Lindholm wrote:
> On a side note, comparing the resulting configs, there is a
> semi-broken config dependency in lib/Kconfig.debug, meaning
> CONFIG_*STRICT_DEVMEM get set even if CONFIG_DEVMEM is not.
> But I'll send that out as a separate patch.
Ah - never mind, that one has already been fixed upstream for 4.10rc.
/
Leif
^ permalink raw reply
* [PATCH 8/8] efi: Add EFI_SECURE_BOOT bit [ver #6]
From: Matt Fleming @ 2017-01-16 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7979.1484148564@warthog.procyon.org.uk>
On Wed, 11 Jan, at 03:29:24PM, David Howells wrote:
> Matt Fleming <matt@codeblueprint.co.uk> wrote:
>
> > Before we add more efi.flags bits I'd like this series to include the
> > patch that makes use of EFI_SECURE_BOOT. Alternatively, you move this
> > last patch to a new series.
>
> Are you willing to take the kernel lock-down patches also?
I'm happy to take them through the EFI tree provided that they've been
Reviewed/Ack-ed by the security folks.
^ permalink raw reply
* [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files
From: Joao Pinto @ 2017-01-16 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587CAEBD.1010803@ti.com>
?s 11:30 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
> Hi Joao,
>
> On Monday 16 January 2017 03:57 PM, Joao Pinto wrote:
>>
>> Hi,
>>
>> ?s 5:21 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
>>> Hi Joao,
>>>
>>> On Friday 13 January 2017 10:19 PM, Joao Pinto wrote:
>>>> ?s 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
>>>>> Split pcie-designware.c into pcie-designware-host.c that contains
>>>>> the host specific parts of the driver and pcie-designware.c that
>>>>> contains the parts used by both host driver and endpoint driver.
>>>>>
>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>>>> ---
>>>>> drivers/pci/dwc/Makefile | 2 +-
>>>>> drivers/pci/dwc/pcie-designware-host.c | 619 ++++++++++++++++++++++++++++++++
>>>>> drivers/pci/dwc/pcie-designware.c | 613 +------------------------------
>>>>> drivers/pci/dwc/pcie-designware.h | 8 +
>>>>> 4 files changed, 634 insertions(+), 608 deletions(-)
>>>>> create mode 100644 drivers/pci/dwc/pcie-designware-host.c
>>>>>
>>>>> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
>>>>> index 7d27c14..3b57e55 100644
>>>>> --- a/drivers/pci/dwc/Makefile
>>>>> +++ b/drivers/pci/dwc/Makefile
>>>>> @@ -1,4 +1,4 @@
>>>>
>>>> (snip...)
>>>>
>>>>> -static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
>>>>> - int type, u64 cpu_addr, u64 pci_addr,
>>>>> - u32 size)
>>>>> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
>>>>> + u64 cpu_addr, u64 pci_addr, u32 size)
>>>>> {
>>>>> u32 retries, val;
>>>>>
>>>>> @@ -186,220 +151,6 @@ static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
>>>>> dev_err(pci->dev, "iATU is not being enabled\n");
>>>>> }
>>>>
>>>> Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
>>>> the pcie-designware-host.
>>>
>>> That is not true. Outbound ATU should be programmed to access host side buffers
>>> and inbound ATU should be programmed for the host to access EP mem space.
>>
>> Sorry, I was not clear enough. What I was trying to suggest is, since the ATU
>> programming is done by the host, wouldn't be better to include it in the
>> pcie-designware-host? It is just an architectural detail.
>
> ATU programming is required in EP mode. See "[PATCH 24/37] PCI: dwc:
> designware: Add EP mode support" in this patch series.
>
> Anything that's required by both EP mode and RC mode, I've placed in
> pcie-designware.c
Agreed!
>
> Thanks
> Kishon
>
^ permalink raw reply
* [RFC PATCH 07/10] arm64/sve: Add vector length inheritance control
From: Dave Martin @ 2017-01-16 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116122755.GH28060@E107787-LIN>
On Mon, Jan 16, 2017 at 12:27:55PM +0000, Yao Qi wrote:
> On 17-01-12 11:26:06, Dave Martin wrote:
> > Currently the vector length is inherited across both fork() and
> > exec().
> >
> > Inheritance across fork() is desirable both for creating a copy of
> > a process (traditional fork) or creating a thread (where we want
> > all threads to share the same VL by default).
> >
> > Inheritance across exec() is less desirable, because of the ABI
> > impact of large vector lengths on the size of the signal frame --
> > when running a new binary, there is no guarantee that the new
> > binary is compatible with these ABI changes.
> >
> > This flag makes the vector length non-inherited by default.
>
> Can we make vector length inherited across fork but non-inherited
> across exec by default?
That is the behaviour: I always inherit across fork/clone, since
you are still running the same binary after those.
I could word the commit message a bit more clearly here.
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/3] watchdog: imx2: Only i.MX35 and later have a WMCR register
From: Fabio Estevam @ 2017-01-16 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109095039.11979-2-u.kleine-koenig@pengutronix.de>
Hi Magnus,
On Mon, Jan 9, 2017 at 7:50 AM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> Commit 5fe65ce7ccbb ("watchdog: imx2_wdt: Disable power down counter on
> boot") introduced a write to the WMCR register that doesn't exist on
> i.MX21, i.MX27 and i.MX31 and so makes the SoC hang during probe.
>
> So teach the driver to differentiate between these two types. Note that
> this effectively undoes commit 5fe65ce7ccbb for machines using dt until
> their dtb is updated accordingly. This is critical iff the bootloader
> doesn't disable the power down counter and the #WDOG signal actually
> does something to the machine.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Is it possible for you to try this series and let us know if it fixes
the mx31 watchdog issue?
Thanks
^ permalink raw reply
* [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting
From: Dave Martin @ 2017-01-16 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116122038.GG28060@E107787-LIN>
On Mon, Jan 16, 2017 at 12:20:38PM +0000, Yao Qi wrote:
> On 17-01-12 11:26:07, Dave Martin wrote:
> > This patch adds support for manipulating a task's vector length at
> > runtime via ptrace.
> >
>
> I hope kernel doesn't provide such interface to ptracer to change vector
> length.
It does, with this patch, beacuse...
> The vector length is sort of a read-only property of thread/process/
> program to debugger, unless we really have a clear requirement to modify
> vector length in debugging. I may miss something because I haven't debug
> SVE code yet.
...the vector length is no longer read-only for the task, thanks to
the new prctls().
This does add complexity, but I figured that any programmer's model
state that the thread can modify for itself should be modifiable by the
debugger, if for no other reason than the user may want to experiment to
see what happens. Without a ptrace interface, it would be necessary
to inject a prctl() call into the target, which is possible but awkward.
gdb must already re-detect the vector length on stop, since the target
could have called the prctl() in the meantime.
Access via ptrace also allows things like trapping on exec, fork or
clone and changing the vector length for the new process or thread
before it starts to run. I'm guessing here, but such a scenario seems
legitimate (?)
[...]
Cheers
---Dave
^ 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