* [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
* [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 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 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 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
* [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
* [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
* [PATCH v2 2/3] MAINTAINERS: add zx2967 reset controller driver to ARM ZTE architecture
From: Philipp Zabel @ 2017-01-16 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484564194-18530-2-git-send-email-baoyou.xie@linaro.org>
On Mon, 2017-01-16 at 18:56 +0800, Baoyou Xie wrote:
> Add the zx2967 reset controller driver as maintained by ARM ZTE
> architecture maintainers, as they're parts of the core IP.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2793808..08f8155 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1980,10 +1980,12 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> F: arch/arm/mach-zx/
> F: drivers/clk/zte/
> +F: drivers/reset/reset-zx2967.c
> F: drivers/soc/zte/
> F: drivers/thermal/zx*
> F: Documentation/devicetree/bindings/arm/zte.txt
> F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
> +F: Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
> F: Documentation/devicetree/bindings/soc/zte/
> F: Documentation/devicetree/bindings/thermal/zx*
> F: include/dt-bindings/soc/zx*.h
This patch doesn't apply on top of reset/next. I can rebase it, but it
will cause a trivial merge conflict with the soc/thermal additions.
regards
Philipp
^ permalink raw reply
* [Question] A question about arm64 pte
From: Catalin Marinas @ 2017-01-16 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116143601.GB6832@e104818-lin.cambridge.arm.com>
On Mon, Jan 16, 2017 at 02:36:02PM +0000, Catalin Marinas wrote:
> 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.
A correction on anonymous mmap(): the original page links to a zeroed
page, so when dirtying it you also get a new copy, so slightly different
code path from handle_pte_fault().
--
Catalin
^ permalink raw reply
* [PATCHv3 RESEND 1/8] ARM: dts: stm32: set HSE_RTC clock frequency to 1 MHz on stm32f429
From: Alexandre Torgue @ 2017-01-16 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484573388-590-1-git-send-email-amelie.delaunay@st.com>
Hi Am?lie,
On 01/16/2017 02:29 PM, Amelie Delaunay wrote:
> This patch set HSE_RTC clock frequency to 1 MHz, as the clock supplied to
> the RTC must be 1 MHz.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index e9324a3..557c1f4 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -433,6 +433,8 @@
> reg = <0x40023800 0x400>;
> clocks = <&clk_hse>, <&clk_i2s_ckin>;
> st,syscfg = <&pwrcfg>;
> + assigned-clocks = <&rcc 1 CLK_HSE_RTC>;
> + assigned-clock-rates = <1000000>;
> };
>
> dma1: dma-controller at 40026000 {
>
Applied on stm32-dt-for-v4.11
Thanks
Alex
^ permalink raw reply
* [PATCHv3 RESEND 4/8] ARM: dts: stm32: Add RTC support for STM32F429 MCU
From: Alexandre Torgue @ 2017-01-16 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484573388-590-2-git-send-email-amelie.delaunay@st.com>
On 01/16/2017 02:29 PM, Amelie Delaunay wrote:
> This patch adds STM32 RTC bindings for STM32F429.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index 557c1f4..f05a9d9 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -125,6 +125,20 @@
> status = "disabled";
> };
>
> + rtc: rtc at 40002800 {
> + compatible = "st,stm32-rtc";
> + reg = <0x40002800 0x400>;
> + clocks = <&rcc 1 CLK_RTC>;
> + clock-names = "ck_rtc";
> + assigned-clocks = <&rcc 1 CLK_RTC>;
> + assigned-clock-parents = <&rcc 1 CLK_LSE>;
> + interrupt-parent = <&exti>;
> + interrupts = <17 1>;
> + interrupt-names = "alarm";
> + st,syscfg = <&pwrcfg>;
> + status = "disabled";
> + };
> +
> usart2: serial at 40004400 {
> compatible = "st,stm32-usart", "st,stm32-uart";
> reg = <0x40004400 0x400>;
>
Applied on stm32-dt-for-v4.11
Thanks
Alex
^ permalink raw reply
* [PATCHv3 RESEND 5/8] ARM: dts: stm32: enable RTC on stm32f429-disco
From: Alexandre Torgue @ 2017-01-16 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484573388-590-3-git-send-email-amelie.delaunay@st.com>
On 01/16/2017 02:29 PM, Amelie Delaunay wrote:
> This patch enables RTC on stm32f429-disco with LSI as clock source because
> X2 crystal for LSE is not fitted by default.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> arch/arm/boot/dts/stm32f429-disco.dts | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
> index 7d0415e..9222b9f 100644
> --- a/arch/arm/boot/dts/stm32f429-disco.dts
> +++ b/arch/arm/boot/dts/stm32f429-disco.dts
> @@ -94,6 +94,12 @@
> clock-frequency = <8000000>;
> };
>
> +&rtc {
> + assigned-clocks = <&rcc 1 CLK_RTC>;
> + assigned-clock-parents = <&rcc 1 CLK_LSI>;
> + status = "okay";
> +};
> +
> &usart1 {
> pinctrl-0 = <&usart1_pins_a>;
> pinctrl-names = "default";
>
Applied on stm32-dt-for-v4.11
Thanks
Alex
^ permalink raw reply
* [PATCHv3 RESEND 6/8] ARM: dts: stm32: enable RTC on stm32f469-disco
From: Alexandre Torgue @ 2017-01-16 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484573388-590-4-git-send-email-amelie.delaunay@st.com>
On 01/16/2017 02:29 PM, Amelie Delaunay wrote:
> This patch enables RTC on stm32f469-disco with default LSE clock source.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> arch/arm/boot/dts/stm32f469-disco.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> index fda12a4..f52b9f6 100644
> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> @@ -78,6 +78,10 @@
> clock-frequency = <8000000>;
> };
>
> +&rtc {
> + status = "okay";
> +};
> +
> &usart3 {
> pinctrl-0 = <&usart3_pins_a>;
> pinctrl-names = "default";
>
Applied on stm32-dt-for-v4.11
Thanks
Alex
^ permalink raw reply
* [PATCHv3 RESEND 7/8] ARM: dts: stm32: enable RTC on stm32429i-eval
From: Alexandre Torgue @ 2017-01-16 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484573388-590-5-git-send-email-amelie.delaunay@st.com>
On 01/16/2017 02:29 PM, Amelie Delaunay wrote:
> This patch enables RTC on stm32429i-eval with default LSE clock source.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> arch/arm/boot/dts/stm32429i-eval.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
> index 2181220..eedb27d 100644
> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> @@ -157,6 +157,10 @@
> };
> };
>
> +&rtc {
> + status = "okay";
> +};
> +
> &usart1 {
> pinctrl-0 = <&usart1_pins_a>;
> pinctrl-names = "default";
>
Applied on stm32-dt-for-v4.11
Thanks
Alex
^ permalink raw reply
* [PATCH V9 0/3] irqchip: qcom: Add IRQ combiner driver
From: Hanjun Guo @ 2017-01-16 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8587b5ab-59b1-feb7-09d9-7ade6d433a4c@arm.com>
On 2017/1/16 22:14, Marc Zyngier wrote:
> 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.
Is it helpful to test patch [1-2/3] on x86 machines (with different firmware) and
an IA64 machine (surely a different version of firmware :) ) with Lorenzo's suggestion
of removing #ifdef CONFIG_ACPI_GENERIC_GSI for is_gsi()? If yes, I can do that as
I have such machines.
Thanks
Hanjun
^ permalink raw reply
* [PATCH v2 3/3] reset: zx2967: add reset controller driver for ZTE's zx2967 family
From: Philipp Zabel @ 2017-01-16 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95ebb6fd-540b-f6d5-e039-2cd718ff35d8@linaro.org>
On Mon, 2017-01-16 at 22:28 +0800, Jun Nie wrote:
> 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;
Not terribly important, but int for bank and offset was just fine.
> > + 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.
Why? Resets are usually not performance critical.
> > +
> > + 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);
This is a bit noisy. Can we just drop it?
> > + return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
> > +}
> > +
> > +static int zx2967_reset_remove(struct platform_device *pdev)
> > +{
> > + return 0;
> > +}
Remove this function.
> > +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,
Remove the above line.
> > + .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");
> >
regards
Philipp
^ permalink raw reply
* USB: OHCI: high softirq load
From: Johan Hovold @ 2017-01-16 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116121403.4a3a7b17@bbrezillon>
[ +CC: linux-usb ]
On Mon, Jan 16, 2017 at 12:14:03PM +0100, Boris Brezillon wrote:
> On Mon, 16 Jan 2017 11:54:23 +0100
> Antoine Aubert <a.aubert@overkiz.com> wrote:
>
> > Also, I made a big misunderstanding
> >
> > With EHCI + OHCI = high level of softirq (USB2.0)
>
> Well, the number of irqs and softirqs are likely to be related (you
> usually trigger a softirq after you received an hardirq).
>
> >
> > OHCI only = normal level
>
> What about EHCI only? And what happens if you only plug 1 device?
> Please share the content of /proc/interrupts (and everything you think
> is relevant) for each of these cases.
>
> >
> > Le 16/01/2017 ? 11:31, Antoine Aubert a ?crit :
> > > Thx for your answer Boris
> > >
> > > Le 16/01/2017 ? 10:02, Boris Brezillon a ?crit :
> > >> Hi Antoine,
> > >>
> > >> On Mon, 16 Jan 2017 08:45:58 +0100
> > >> Antoine Aubert <a.aubert@overkiz.com> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> Im working on a AT91SAM9G25cu board
> > >>> (arch/arm/boot/dts/at91-kizboxmini.dts). We use linux-4.1.31, and when
> > >>> OHCI is enabled, I got some wired effects.
> > >> Can you test on a more recent kernel (4.9 or 4.10-rc4)?
> > > I'll give a try, just need little time ;)
> > >>> eg with 3 FTDI pluged, interrupts: more than 3.5k/s, cpu softirq > 24%,
> > >>> loadavg > 0.5
> > >> Can you check which interrupt is triggered (cat /proc/interrupts),
> > > cat /proc/interrupts
> > > CPU0
> > > 16: 2286 atmel-aic 1 Level pmc, at91_tick, at91_rtc, ttyS0
> > > 17: 0 PMC 17 Level main_rc_osc
> > > 18: 0 PMC 0 Level main_osc
> > > 19: 0 PMC 16 Level mainck
> > > 20: 0 PMC 1 Level clk-plla
> > > 21: 0 PMC 6 Level clk-utmi
> > > 22: 0 PMC 3 Level clk-master
> > > 23: 945527 atmel-aic 17 Level tc_clkevt
> > > 24: 21815 atmel-aic 20 Level at_hdmac
> > > 25: 0 atmel-aic 21 Level at_hdmac
> > > 30: 120299 atmel-aic 24 Level eth0
> > > 31: 22783651 atmel-aic 22 Level ehci_hcd:usb1, ohci_hcd:usb2
> > > 99: 0 GPIO 16 Edge PB_RST
> > > 100: 0 GPIO 17 Edge PB_PROG
> > > Err: 0
Note that the ftdi driver uses a low-latency setting by default which
implies that the device sends a status update every millisecond. Hence,
the 1k interrupts per second (per device) while the port is open is
expected.
You can disable the low-latency behaviour using setserial:
setserial /dev/ttyUSB0 ^low_latency
and see the number of interrupts drop to 1/16th. This can then be
reduced further by changing the latency_timer from its
(non-low-latency) default of 16 ms, for example:
echo 64 >/sys/bus/usb-serial/devices/ttyUSB0/latency_timer
Johan
^ permalink raw reply
* [PATCH v2] i2c: i2c-cadence: Initialize configuration before probing devices
From: Mike Looijmans @ 2017-01-16 14:49 UTC (permalink / raw)
To: linux-arm-kernel
The cadence I2C driver calls cdns_i2c_writereg(..) to setup a workaround
in the controller, but did so after calling i2c_add_adapter() which starts
probing devices on the bus. Change the order so that the configuration is
completely finished before using the adapter.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
---
v2: Only move the initialization to before i2c_add_adapter, don't change the
logging output.
drivers/i2c/busses/i2c-cadence.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index 6869712..45d6771 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -962,10 +962,6 @@ static int cdns_i2c_probe(struct platform_device *pdev)
goto err_clk_dis;
}
- ret = i2c_add_adapter(&id->adap);
- if (ret < 0)
- goto err_clk_dis;
-
/*
* Cadence I2C controller has a bug wherein it generates
* invalid read transaction after HW timeout in master receiver mode.
@@ -975,6 +971,10 @@ static int cdns_i2c_probe(struct platform_device *pdev)
*/
cdns_i2c_writereg(CDNS_I2C_TIMEOUT_MAX, CDNS_I2C_TIME_OUT_OFFSET);
+ ret = i2c_add_adapter(&id->adap);
+ if (ret < 0)
+ goto err_clk_dis;
+
dev_info(&pdev->dev, "%u kHz mmio %08lx irq %d\n",
id->i2c_clk / 1000, (unsigned long)r_mem->start, id->irq);
--
1.9.1
^ permalink raw reply related
* [PATCH 5/8] efi: Get the secure boot status [ver #6]
From: Matt Fleming @ 2017-01-16 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7948.1484148443@warthog.procyon.org.uk>
(Cc'ing Peter A. and Peter J. for boot params discussion)
On Wed, 11 Jan, at 03:27:23PM, David Howells wrote:
> Matt Fleming <matt@codeblueprint.co.uk> wrote:
>
> > > + movb $0, BP_secure_boot(%rsi)
> > > #ifdef CONFIG_EFI_STUB
> > > /*
> > > * The entry point for the PE/COFF executable is efi_pe_entry, so
> >
> > Is clearing ::secure_boot really necessary? Any code path that goes
> > via efi_main() will set it correctly and all other code paths should
> > get it cleared in sanitize_boot_params(), no?
>
> No.
>
> The boot_params->secure_boot parameter exists whether or not efi_main() is
> traversed (ie. if EFI isn't enabled or CONFIG_EFI_STUB=n) and, if not cleared,
> is of uncertain value.
>
> Further, sanitize_boot_params() has to be modified by this patch so as not to
> clobber the secure_boot flag.
Any new parameters that boot loaders do not know about should be
cleared to zero by default in the boot loader because boot_params
itself should be zero'd when allocated.
There are two cases to consider:
1) boot_params is not zero'd
2) boot_params is zero'd
1) This is a broken boot loader implementation that violates the x86
boot specification and I would never expect ->secure_boot to have a
valid value. It should not be special-cased in sanitize_boot_params(),
it should be zero'd.
2) In this case ->secure_boot should be zero unless modified inside of
efi_main().
Did you hit the scenario where ->secure_boot has a garbage value while
developing these patches? I wouldn't expect to see it in practice.
^ permalink raw reply
* [PATCH V9 0/3] irqchip: qcom: Add IRQ combiner driver
From: Lorenzo Pieralisi @ 2017-01-16 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587CDB96.9000906@huawei.com>
On Mon, Jan 16, 2017 at 10:41:26PM +0800, Hanjun Guo wrote:
> On 2017/1/16 22:14, Marc Zyngier wrote:
> > 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.
>
> Is it helpful to test patch [1-2/3] on x86 machines (with different firmware) and
> an IA64 machine (surely a different version of firmware :) ) with Lorenzo's suggestion
> of removing #ifdef CONFIG_ACPI_GENERIC_GSI for is_gsi()? If yes, I can do that as
> I have such machines.
Well, it is always helpful, as helpful as getting this change into -next
as soon as possible, at the end of the day it is quite simple, as soon
as (hopefully never) we find some firmware out there (x86/ia64) that
misused the resource source field in the interrupt descriptor we will
have to add that guard back, it is as simple as that.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH v3 17/24] media: imx: Add CSI subdev driver
From: Philipp Zabel @ 2017-01-16 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483755102-24785-18-git-send-email-steve_longerbeam@mentor.com>
On Fri, 2017-01-06 at 18:11 -0800, Steve Longerbeam wrote:
> This is a media entity subdevice for the i.MX Camera
> Serial Interface module.
s/Serial/Sensor/
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> drivers/staging/media/imx/Kconfig | 13 +
> drivers/staging/media/imx/Makefile | 2 +
> drivers/staging/media/imx/imx-csi.c | 644 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 659 insertions(+)
> create mode 100644 drivers/staging/media/imx/imx-csi.c
>
> diff --git a/drivers/staging/media/imx/Kconfig b/drivers/staging/media/imx/Kconfig
> index bfde58d..ce2d2c8 100644
> --- a/drivers/staging/media/imx/Kconfig
> +++ b/drivers/staging/media/imx/Kconfig
> @@ -6,3 +6,16 @@ config VIDEO_IMX_MEDIA
> Say yes here to enable support for video4linux media controller
> driver for the i.MX5/6 SOC.
>
> +if VIDEO_IMX_MEDIA
> +menu "i.MX5/6 Media Sub devices"
> +
> +config VIDEO_IMX_CAMERA
s/CAMERA/CSI/ ?
> + tristate "i.MX5/6 Camera driver"
i.MX5/6 Camera Sensor Interface driver
> + depends on VIDEO_IMX_MEDIA && VIDEO_DEV && I2C
> + select VIDEOBUF2_DMA_CONTIG
> + default y
> + ---help---
> + A video4linux camera capture driver for i.MX5/6.
> +
> +endmenu
> +endif
> diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
> index ef9f11b..133672a 100644
> --- a/drivers/staging/media/imx/Makefile
> +++ b/drivers/staging/media/imx/Makefile
> @@ -4,3 +4,5 @@ imx-media-objs := imx-media-dev.o imx-media-fim.o imx-media-internal-sd.o \
> obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
> obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
>
> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
> +
> diff --git a/drivers/staging/media/imx/imx-csi.c b/drivers/staging/media/imx/imx-csi.c
> new file mode 100644
> index 0000000..64ef862
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-csi.c
> @@ -0,0 +1,644 @@
> +/*
> + * V4L2 Capture CSI Subdev for Freescale i.MX5/6 SOC
> + *
> + * Copyright (c) 2014-2016 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <media/v4l2-ctrls.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-of.h>
> +#include <media/v4l2-subdev.h>
> +#include <media/videobuf2-dma-contig.h>
> +#include <video/imx-ipu-v3.h>
> +#include "imx-media.h"
> +
> +#define CSI_NUM_PADS 2
> +
> +struct csi_priv {
> + struct device *dev;
> + struct ipu_soc *ipu;
> + struct imx_media_dev *md;
> + struct v4l2_subdev sd;
> + struct media_pad pad[CSI_NUM_PADS];
> + struct v4l2_mbus_framefmt format_mbus[CSI_NUM_PADS];
> + struct v4l2_mbus_config sensor_mbus_cfg;
> + struct v4l2_rect crop;
> + struct ipu_csi *csi;
> + int csi_id;
> + int input_pad;
> + int output_pad;
> + bool power_on; /* power is on */
> + bool stream_on; /* streaming is on */
> +
> + /* the sink for the captured frames */
> + struct v4l2_subdev *sink_sd;
> + enum ipu_csi_dest dest;
> + struct v4l2_subdev *src_sd;
src_sd is not used except that its presence marks an enabled input link.
-> could be changed to bool.
> + struct v4l2_ctrl_handler ctrl_hdlr;
> + struct imx_media_fim *fim;
> +
> + /* the attached sensor at stream on */
> + struct imx_media_subdev *sensor;
> +};
> +
> +static inline struct csi_priv *sd_to_dev(struct v4l2_subdev *sdev)
> +{
> + return container_of(sdev, struct csi_priv, sd);
> +}
> +
> +/* Update the CSI whole sensor and active windows */
> +static int csi_setup(struct csi_priv *priv)
> +{
> + struct v4l2_mbus_framefmt infmt;
> +
> + ipu_csi_set_window(priv->csi, &priv->crop);
> +
> + /*
> + * the ipu-csi doesn't understand ALTERNATE, but it only
> + * needs to know whether the stream is interlaced, so set
> + * to INTERLACED if infmt field is ALTERNATE.
> + */
> + infmt = priv->format_mbus[priv->input_pad];
> + if (infmt.field == V4L2_FIELD_ALTERNATE)
> + infmt.field = V4L2_FIELD_INTERLACED;
That should be SEQ_TB/BT depending on video standard.
> + ipu_csi_init_interface(priv->csi, &priv->sensor_mbus_cfg, &infmt);
> +
> + ipu_csi_set_dest(priv->csi, priv->dest);
> +
> + ipu_csi_dump(priv->csi);
> +
> + return 0;
> +}
> +
> +static int csi_start(struct csi_priv *priv)
> +{
> + int ret;
> +
> + if (!priv->sensor) {
> + v4l2_err(&priv->sd, "no sensor attached\n");
> + return -EINVAL;
> + }
> +
> + ret = csi_setup(priv);
> + if (ret)
> + return ret;
> +
> + /* start the frame interval monitor */
> + if (priv->fim) {
> + ret = imx_media_fim_set_stream(priv->fim, priv->sensor, true);
> + if (ret)
> + return ret;
> + }
> +
> + ret = ipu_csi_enable(priv->csi);
> + if (ret) {
> + v4l2_err(&priv->sd, "CSI enable error: %d\n", ret);
> + goto fim_off;
> + }
> +
> + return 0;
> +
> +fim_off:
> + if (priv->fim)
> + imx_media_fim_set_stream(priv->fim, priv->sensor, false);
> + return ret;
> +}
> +
> +static void csi_stop(struct csi_priv *priv)
> +{
> + /* stop the frame interval monitor */
> + if (priv->fim)
> + imx_media_fim_set_stream(priv->fim, priv->sensor, false);
> +
> + ipu_csi_disable(priv->csi);
> +}
> +
> +static int csi_s_stream(struct v4l2_subdev *sd, int enable)
> +{
> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
> + int ret = 0;
> +
> + if (!priv->src_sd || !priv->sink_sd)
> + return -EPIPE;
> +
> + v4l2_info(sd, "stream %s\n", enable ? "ON" : "OFF");
These could be silenced a bit.
[...]
> +static int csi_s_power(struct v4l2_subdev *sd, int on)
> +{
> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
> + int ret = 0;
> +
> + v4l2_info(sd, "power %s\n", on ? "ON" : "OFF");
> +
> + if (priv->fim && on != priv->power_on)
> + ret = imx_media_fim_set_power(priv->fim, on);
> +
> + if (!ret)
> + priv->power_on = on;
> + return ret;
> +}
Is this called multiple times? I'd expect a poweron during open and a
poweroff during close, so no need for priv->power_on.
> +static int csi_link_setup(struct media_entity *entity,
> + const struct media_pad *local,
> + const struct media_pad *remote, u32 flags)
> +{
> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
> + struct v4l2_subdev *remote_sd;
> +
> + dev_dbg(priv->dev, "link setup %s -> %s", remote->entity->name,
> + local->entity->name);
> +
> + remote_sd = media_entity_to_v4l2_subdev(remote->entity);
> +
> + if (local->flags & MEDIA_PAD_FL_SINK) {
> + if (flags & MEDIA_LNK_FL_ENABLED) {
> + if (priv->src_sd)
> + return -EBUSY;
> + priv->src_sd = remote_sd;
> + } else {
> + priv->src_sd = NULL;
> + }
> +
> + return 0;
> + }
> +
> + if (flags & MEDIA_LNK_FL_ENABLED) {
> + if (priv->sink_sd)
> + return -EBUSY;
> + priv->sink_sd = remote_sd;
> + } else {
> + priv->sink_sd = NULL;
> + return 0;
> + }
> +
> + /* set CSI destination */
> + switch (remote_sd->grp_id) {
> + case IMX_MEDIA_GRP_ID_SMFC0:
> + case IMX_MEDIA_GRP_ID_SMFC1:
> + case IMX_MEDIA_GRP_ID_SMFC2:
> + case IMX_MEDIA_GRP_ID_SMFC3:
With removal of the SMFC entities, CSI0 could be fixed to SMFC0 and CSI1
to the SMFC2 channel.
[...]
> +static int csi_set_fmt(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_format *sdformat)
> +{
> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
> + struct v4l2_mbus_framefmt *infmt, *outfmt;
> + struct v4l2_rect crop;
> + int ret;
> +
> + if (sdformat->pad >= CSI_NUM_PADS)
> + return -EINVAL;
> +
> + if (priv->stream_on)
> + return -EBUSY;
> +
> + infmt = &priv->format_mbus[priv->input_pad];
> + outfmt = &priv->format_mbus[priv->output_pad];
> +
> + if (sdformat->pad == priv->output_pad) {
> + sdformat->format.code = infmt->code;
> + sdformat->format.field = infmt->field;
> + crop.left = priv->crop.left;
> + crop.top = priv->crop.top;
> + crop.width = sdformat->format.width;
> + crop.height = sdformat->format.height;
> + ret = csi_try_crop(priv, &crop);
> + if (ret)
> + return ret;
> + sdformat->format.width = crop.width;
> + sdformat->format.height = crop.height;
> + }
> +
> + if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
Should there be some limitations on the format here?
regards
Philipp
^ permalink raw reply
* [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Andreas Färber @ 2017-01-16 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7fcb8d94-840a-de2c-f43b-9123ccc65514@baylibre.com>
Hi Neil,
Am 16.01.2017 um 11:39 schrieb Neil Armstrong:
> On 01/15/2017 03:43 PM, Andreas F?rber wrote:
>> Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>
>>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>>> this patch adds this reserved zone and redefines the usable memory range.
>>>>
>>>> The memory node is also moved from the dtsi files into the proper dts files
>>>> to handle variants memory sizes.
>>>>
>>>> This patch also fixes the memory sizes for the following platforms :
>>>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>
>>> Queued for v4.10-rc.
>>
>> What is the motivation for this change? I have a local U-Boot patch to
>> detect the amount of memory available as done downstream, but U-Boot
>> only updates the reg property that you seem to be abandoning here...
>>
>> So for devices that come in multiple RAM configurations - like R-Box Pro
>> - this would require separate .dts files now! This looks very wrong to
>> me, especially since I am not aware of other platforms doing the same.
>> Instead, there's memory reservations for top and bottom done in U-Boot
>> for reg, plus reserved-memory nodes for anything in the middle.
>>
>> Another thing to consider is that uEFI boot (bootefi) handles memory
>> reservation differently yet again, on the bootloader level. I have had
>> that working fine on Odroid-C2 and Vega S95.
>>
>> So if there's no bug this is fixing (none mentioned in commit message) I
>> strongly object to this patch.
>>
>> Regards,
>> Andreas
>>
>
> Hi Andreas,
[snip]
Let's not copy&paste replies, see my response there.
> Handling multiple RAM configuration is another story, and the Arm-Soc and DT maintainers should give us
> their advices.
My point is, this should be thought through _before_ merging the patch,
not after.
It is the bootloader's task to deliver the correct memory _size_, with
kernel .dts having the minimum. If there's 1G and 2G models then the
linux.git .dts will have 1G, so that it can run on both, should the
bootloader fail to update it.
The consequence of your change would be that U-Boot needs to set
different $fdtfile values based on memory size, which is a plain stupid
idea for the reasons I already gave. And it has been fought by DT
maintainers in previous cases, such as FPGA configurations or
daughter-boards. Amlogic's vendor U-Boot does have the "fdt" command
available, for any user to adequately tweak a loaded .dtb for use with
mainline Linux (e.g., add linux,usable-memory there) - it can be
automated via environment variables or for lack of "source" command
maybe via "autoscr".
The reason that there are three vega-s95 .dts files never was the
differing memory reg size (which gets overridden), but rather connector
and Wifi chipset features as well as them simply having different names
and therefore different compatible strings.
Ideally I expect to be able to use one .dts for both R-Box Pro models as
well as for both Khadas Vim models - they are not marketed with
differing names, so the differences should hopefully be minor,
especially when we're using brcm,bcm4329-fmac for any chipset anyway.
> Actually there is a severe bug fixed here that cause a huge crash if such memory is not reserved while
> running stock u-boot version on various shipped products and Amlogic's own development boards.
>
> The bug is easily triggered by running :
> # stress --vm 4 --vm-bytes 128M --timeout 10s &
First, that should've gone into the commit message please.
But this is what I get for that command line:
flag provided but not defined: -vm
Usage of stress:
-failure regexp
fail only if output matches regexp
-ignore regexp
ignore failure if output matches regexp
-kill
kill timed out processes if true, otherwise just print pid (to
attach with gdb) (default true)
-p N
run N processes in parallel (default 8)
-timeout duration
timeout each process after duration (default 10m0s)
The only "stress" I found is in golang-org-x-tools package.
> [ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
> ...
> [ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
> ...
>
> Note this is a fix targeted for 4.10 to make the system stable and various users reported some severe
> crash now the system has more drivers and read-world use-cases are running on Amlogic SoCs.
I have been running "large" KVM guests on a Vega S95 Telos, with vendor
U-Boot as well as mainline U-Boot, and did not run into such a problem.
What I did run into yesterday during a large system update was multiple:
INFO: task grub2-probe:22018 blocked for more than 120 seconds.
Not tainted 4.10.0-rc3-next-20170113+ #58
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
grub2-probe D 0 22018 22017 0x00000000
Call trace:
[<ffffff8008085628>] __switch_to+0x90/0xa8
[<ffffff8008746238>] __schedule+0x188/0x570
[<ffffff8008746658>] schedule+0x38/0xa0
[<ffffff80081fb234>] wb_wait_for_completion+0x4c/0x80
[<ffffff80081fb2f0>] __writeback_inodes_sb_nr+0x88/0xa0
[<ffffff80081fb34c>] writeback_inodes_sb+0x2c/0x38
[<ffffff80081ff494>] sync_filesystem+0x3c/0xa8
[<ffffff8008208688>] fsync_bdev+0x20/0x70
[<ffffff80083508e8>] blkdev_ioctl+0x8b0/0x9d8
[<ffffff800820801c>] block_ioctl+0x34/0x40
[<ffffff80081e2d04>] do_vfs_ioctl+0xa4/0x748
[<ffffff80081e3434>] SyS_ioctl+0x8c/0xa0
[<ffffff8008082f30>] el0_svc_naked+0x24/0x28
I'm assuming that's an unrelated linux-next regression.
I have also been running vendor U-Boot on the R-Box Pro, without problems.
On the Odroid-C2 however the bootloader is provided on SD by the user,
so there is no excuse really for the user to use a broken bootloader.
Even if not using the mainline version for lack of MMC drivers, the
Hardkernel branch can easily be patched if necessary.
> Please feel free to push whatever changes that makes this memory reservation more coherent for 4.11,
> and respect the behavior of already shipped u-boot version and mainline U-Boot, UEFI, whatever...
Whatever the issue is, this patch is clearly wrong by design. Please
revert it ASAP!
For starters, have you tried simply adding a reserved-memory node for
0..0x01000000? v1 did not have that and instead messed with reg.
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
* [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting
From: Yao Qi @ 2017-01-16 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116133231.GO3699@e103592.cambridge.arm.com>
On 17-01-16 13:32:31, Dave Martin wrote:
> 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().
What I meant "read-only" is that debugger can't change it, while the program
itself can change it via prctl().
>
> 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.
We only need such interface if it is useful, see more below.
Suppose it is useful to change vector length through ptrace, we should align
ptrace interface to prctl() as much as possible. Looks that both prctl
change and ptrace change can go through sve_set_vector_length, easy to keep
two consistent.
>
> gdb must already re-detect the vector length on stop, since the target
> could have called the prctl() in the meantime.
Yes, gdb assumes the vector length may be changed, so it re-detects on
every stop, but I don't see the need for gdb to change the vector length.
>
> 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 (?)
>
Yes, these cases are valid, but the usefulness is still questionable to
me. I just doubt that SVE developers do need to change vector length
when they are debugging code. Note that it is not my strong objection
to this patch, if kernel people believe this is useful, I am fine with
it.
--
Yao (??)
^ permalink raw reply
* [PATCH] rtc: sun6i: Switch to the external oscillator
From: Maxime Ripard @ 2017-01-16 15:21 UTC (permalink / raw)
To: linux-arm-kernel
The RTC is clocked from either an internal, imprecise, oscillator or an
external one, which is usually much more accurate.
The difference perceived between the time elapsed and the time reported by
the RTC is in a 10% scale, which prevents the RTC from being useful at all.
Fortunately, the external oscillator is reported to be mandatory in the
Allwinner datasheet, so we can just switch to it.
Cc: stable at vger.kernel.org
Fixes: 9765d2d94309 ("rtc: sun6i: Add sun6i RTC driver")
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/rtc/rtc-sun6i.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index c169a2cd4727..dee524cfa13b 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -37,9 +37,11 @@
/* Control register */
#define SUN6I_LOSC_CTRL 0x0000
+#define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
#define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
#define SUN6I_LOSC_CTRL_RTC_HMS_ACC BIT(8)
#define SUN6I_LOSC_CTRL_RTC_YMD_ACC BIT(7)
+#define SUN6I_LOSC_CTRL_EXT_OSC BIT(0)
#define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
/* RTC */
@@ -404,6 +406,10 @@ static int sun6i_rtc_probe(struct platform_device *pdev)
/* disable alarm wakeup */
writel(0, chip->base + SUN6I_ALARM_CONFIG);
+ /* switch to the external, more precise, oscillator */
+ writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC,
+ chip->base + SUN6I_LOSC_CTRL);
+
chip->rtc = rtc_device_register("rtc-sun6i", &pdev->dev,
&sun6i_rtc_ops, THIS_MODULE);
if (IS_ERR(chip->rtc)) {
--
2.11.0
^ permalink raw reply related
* [PATCH v7 15/15] irqchip: mbigen: Add ACPI support
From: Lorenzo Pieralisi @ 2017-01-16 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587CD754.1050808@huawei.com>
On Mon, Jan 16, 2017 at 10:23:16PM +0800, Hanjun Guo wrote:
> 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.
Aha ! So here is why you are using _PRS because the kernel turns _CRS
Interrupt resources (even producers) into GSIs which is probably a
kernel bug, is that the reason ?
We don't abuse firmware bindings to make the kernel work, that's _never_
a good idea.
If the interrupt resource is a Resource Producer core ACPI should not
register the IRQ because that's not a GSI, probably this should be part of
Agustin changes too ?
> > 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).
I think this patch (and the FW that goes with it) is wrong, but the rest
of the series, in particular the IORT bits, are ok with me.
Lorenzo
^ 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