* [PATCH v3 4/9] ARM: dts: sun8i-h3: Add dt node for the syscon control module
From: LABBE Corentin @ 2016-09-13 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912072812.GB9449@lukather>
On Mon, Sep 12, 2016 at 09:28:12AM +0200, Maxime Ripard wrote:
> On Fri, Sep 09, 2016 at 02:45:12PM +0200, Corentin Labbe wrote:
> > This patch add the dt node for the syscon register present on the
> > Allwinner H3.
> >
> > Only two register are present in this syscon and the only one useful is
> > the one dedicated to EMAC clock.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm/boot/dts/sun8i-h3.dtsi | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index fdf9fdb..a39da6f 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -140,6 +140,11 @@
> > #size-cells = <1>;
> > ranges;
> >
> > + syscon: syscon at 01c00000 {
> > + compatible = "syscon";
>
> Having our compatible would be nice here. syscon doesn't mean anything
> by itself.
>
Since no driver handle it, I follow what I saw in other DT.
At your choice, I can add a sun8i-syscon, but it will be unused.
> > + reg = <0x01c00000 0x34>;
>
> And the size of our system controller is 0x1000
>
I put the real size used, but I can put what datasheet said.
Regards
Corentin Labbe
^ permalink raw reply
* [PATCH v5 05/14] drivers: iommu: make iommu_fwspec OF agnostic
From: Robin Murphy @ 2016-09-13 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909142343.13314-6-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
On 09/09/16 15:23, Lorenzo Pieralisi wrote:
> The iommu_fwspec structure, used to hold per device iommu configuration
> data is not OF specific and therefore can be moved to a generic
> and OF independent compilation unit.
>
> In particular, the iommu_fwspec handling hinges on the device_node
> pointer to identify the IOMMU device associated with the iommu_fwspec
> structure, that is easily converted to a more generic fwnode_handle
> pointer that can cater for OF and non-OF (ie ACPI) systems.
>
> Create the files and related Kconfig entry to decouple iommu_fwspec
> structure from the OF iommu kernel layer.
>
> Given that the current iommu_fwspec implementation relies on
> the arch specific struct device.archdata.iommu field in its
> implementation, by making the code standalone and independent
> of the OF layer this patch makes sure that the iommu_fwspec
> kernel code can be selected only on arches implementing the
> struct device.archdata.iommu field by adding an explicit
> arch dependency in its config entry.
>
> Current drivers using the iommu_fwspec for streamid translation
> are converted to the new iommu_fwspec API by simply converting
> the device_node to its fwnode_handle pointer.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/iommu/Kconfig | 4 ++
> drivers/iommu/Makefile | 1 +
> drivers/iommu/arm-smmu-v3.c | 16 ++++--
> drivers/iommu/arm-smmu.c | 17 +++---
> drivers/iommu/iommu-fwspec.c | 126 +++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/of_iommu.c | 93 --------------------------------
> include/linux/iommu-fwspec.h | 70 ++++++++++++++++++++++++
> include/linux/of_iommu.h | 38 ++++---------
> 8 files changed, 234 insertions(+), 131 deletions(-)
> create mode 100644 drivers/iommu/iommu-fwspec.c
> create mode 100644 include/linux/iommu-fwspec.h
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 101cb17..873bd41 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -70,6 +70,10 @@ config OF_IOMMU
> config HAVE_IOMMU_FWSPEC
> bool
>
> +config IOMMU_FWSPEC
> + def_bool y
> + depends on IOMMU_API
> +
> # IOMMU-agnostic DMA-mapping layer
> config IOMMU_DMA
> bool
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index 195f7b9..bbbc6d6 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE_ARMV7S) += io-pgtable-arm-v7s.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE_LPAE) += io-pgtable-arm.o
> obj-$(CONFIG_IOMMU_IOVA) += iova.o
> +obj-$(CONFIG_IOMMU_FWSPEC) += iommu-fwspec.o
> obj-$(CONFIG_OF_IOMMU) += of_iommu.o
> obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o
> obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o amd_iommu_init.o
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index be293b5..a7e9de9 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -25,6 +25,7 @@
> #include <linux/err.h>
> #include <linux/interrupt.h>
> #include <linux/iommu.h>
> +#include <linux/iommu-fwspec.h>
> #include <linux/iopoll.h>
> #include <linux/module.h>
> #include <linux/msi.h>
> @@ -1720,13 +1721,18 @@ static struct platform_driver arm_smmu_driver;
>
> static int arm_smmu_match_node(struct device *dev, void *data)
> {
> - return dev->of_node == data;
> + struct fwnode_handle *fwnode;
> +
> + fwnode = dev->of_node ? &dev->of_node->fwnode : dev->fwnode;
> +
> + return fwnode == data;
> }
Maybe we should hoist the dev_fwnode() helper from property.c up to
property.h so we can just have "return dev_fwnode(dev) == data;" here?
>
> -static struct arm_smmu_device *arm_smmu_get_by_node(struct device_node *np)
> +static struct arm_smmu_device *
> +arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
> {
> struct device *dev = driver_find_device(&arm_smmu_driver.driver, NULL,
> - np, arm_smmu_match_node);
> + fwnode, arm_smmu_match_node);
> put_device(dev);
> return dev ? dev_get_drvdata(dev) : NULL;
> }
> @@ -1762,7 +1768,7 @@ static int arm_smmu_add_device(struct device *dev)
> master = fwspec->iommu_priv;
> smmu = master->smmu;
> } else {
> - smmu = arm_smmu_get_by_node(fwspec->iommu_np);
> + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
> if (!smmu)
> return -ENODEV;
> master = kzalloc(sizeof(*master), GFP_KERNEL);
> @@ -1874,7 +1880,7 @@ out_unlock:
>
> static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> {
> - int ret = iommu_fwspec_init(dev, args->np);
> + int ret = iommu_fwspec_init(dev, &args->np->fwnode);
>
> if (!ret)
> ret = iommu_fwspec_add_ids(dev, &args->args[0], 1);
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 2e20cdc..d453c55 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -517,7 +517,7 @@ static int arm_smmu_register_legacy_master(struct device *dev,
> it.cur_count = 1;
> }
>
> - err = iommu_fwspec_init(dev, smmu_dev->of_node);
> + err = iommu_fwspec_init(dev, &smmu_dev->of_node->fwnode);
> if (err)
> return err;
>
> @@ -1368,13 +1368,18 @@ static bool arm_smmu_capable(enum iommu_cap cap)
>
> static int arm_smmu_match_node(struct device *dev, void *data)
> {
> - return dev->of_node == data;
> + struct fwnode_handle *fwnode;
> +
> + fwnode = dev->of_node ? &dev->of_node->fwnode : dev->fwnode;
> +
> + return fwnode == data;
> }
>
> -static struct arm_smmu_device *arm_smmu_get_by_node(struct device_node *np)
> +static struct arm_smmu_device *
> +arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
> {
> struct device *dev = driver_find_device(&arm_smmu_driver.driver, NULL,
> - np, arm_smmu_match_node);
> + fwnode, arm_smmu_match_node);
> put_device(dev);
> return dev ? dev_get_drvdata(dev) : NULL;
> }
> @@ -1392,7 +1397,7 @@ static int arm_smmu_add_device(struct device *dev)
> if (ret)
> goto out_free;
> } else if (fwspec) {
> - smmu = arm_smmu_get_by_node(fwspec->iommu_np);
> + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
> } else {
> return -ENODEV;
> }
> @@ -1524,7 +1529,7 @@ out_unlock:
> static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> {
> u32 fwid = 0;
> - int ret = iommu_fwspec_init(dev, args->np);
> + int ret = iommu_fwspec_init(dev, &args->np->fwnode);
>
> if (ret)
> return ret;
> diff --git a/drivers/iommu/iommu-fwspec.c b/drivers/iommu/iommu-fwspec.c
> new file mode 100644
> index 0000000..be19102
> --- /dev/null
> +++ b/drivers/iommu/iommu-fwspec.c
> @@ -0,0 +1,126 @@
> +/*
> + * Firmware handling helpers for IOMMU
> + *
> + * Copyright (c) 2016 ARM Ltd. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + */
> +
> +#include <linux/iommu.h>
> +#include <linux/iommu-fwspec.h>
> +#include <linux/of_iommu.h>
> +#include <linux/slab.h>
> +
> +struct fwspec_iommu_node {
> + struct list_head list;
> + struct fwnode_handle *fwnode;
> + const struct iommu_ops *ops;
> +};
> +static LIST_HEAD(fwnode_iommu_list);
> +static DEFINE_SPINLOCK(fwspec_iommu_lock);
> +
> +void fwspec_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops)
> +{
> + struct fwspec_iommu_node *iommu =
> + kzalloc(sizeof(*iommu), GFP_KERNEL);
> +
> + if (WARN_ON(!iommu))
> + return;
> +
> + if (is_of_node(fwnode))
> + of_node_get(to_of_node(fwnode));
> +
> + INIT_LIST_HEAD(&iommu->list);
> + iommu->fwnode = fwnode;
> + iommu->ops = ops;
> + spin_lock(&fwspec_iommu_lock);
> + list_add_tail(&iommu->list, &fwnode_iommu_list);
> + spin_unlock(&fwspec_iommu_lock);
> +}
> +
> +const struct iommu_ops *fwspec_iommu_get_ops(struct fwnode_handle *fwnode)
> +{
> + struct fwspec_iommu_node *node;
> + const struct iommu_ops *ops = NULL;
> +
> + spin_lock(&fwspec_iommu_lock);
> + list_for_each_entry(node, &fwnode_iommu_list, list)
> + if (node->fwnode == fwnode) {
> + ops = node->ops;
> + break;
> + }
> + spin_unlock(&fwspec_iommu_lock);
> + return ops;
> +}
> +
> +int iommu_fwspec_init(struct device *dev,
> + struct fwnode_handle *iommu_fwnode)
> +{
> + struct iommu_fwspec *fwspec = arch_get_iommu_fwspec(dev);
> + const struct iommu_ops *ops;
> +
> + if (fwspec)
> + return 0;
> +
> + fwspec = kzalloc(sizeof(*fwspec), GFP_KERNEL);
> + if (!fwspec)
> + return -ENOMEM;
> +
> + if (is_of_node(iommu_fwnode)) {
> + ops = of_iommu_get_ops(to_of_node(iommu_fwnode));
> + of_node_get(to_of_node(iommu_fwnode));
> + } else {
> + ops = fwspec_iommu_get_ops(iommu_fwnode);
> + }
> +
> + fwspec->iommu_fwnode = iommu_fwnode;
> + fwspec->iommu_ops = ops;
> +
> + arch_set_iommu_fwspec(dev, fwspec);
> + return 0;
> +}
> +
> +void iommu_fwspec_free(struct device *dev)
> +{
> + struct iommu_fwspec *fwspec = arch_get_iommu_fwspec(dev);
> +
> + if (fwspec) {
> + if (is_of_node(fwspec->iommu_fwnode))
> + of_node_put(to_of_node(fwspec->iommu_fwnode));
> +
> + kfree(fwspec);
> + }
> +}
> +
> +int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
> +{
> + struct iommu_fwspec *fwspec = arch_get_iommu_fwspec(dev);
> + size_t size;
> +
> + if (!fwspec)
> + return -EINVAL;
> +
> + size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + 1]);
> + fwspec = krealloc(fwspec, size, GFP_KERNEL);
> + if (!fwspec)
> + return -ENOMEM;
> +
> + while (num_ids--)
> + fwspec->ids[fwspec->num_ids++] = *ids++;
You've still got the +1 bug and incomprehensible loop from the old code
here, rather than the fixed version being removed below. Although now
that I've taken the plunge and done it properly in core code from the
outset, that should hopefully become moot.
Robin.
> +
> + arch_set_iommu_fwspec(dev, fwspec);
> + return 0;
> +}
> +
> +inline struct iommu_fwspec *dev_iommu_fwspec(struct device *dev)
> +{
> + return arch_get_iommu_fwspec(dev);
> +}
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 38669b8..ab3c069 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -96,45 +96,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> }
> EXPORT_SYMBOL_GPL(of_get_dma_window);
>
> -struct of_iommu_node {
> - struct list_head list;
> - struct device_node *np;
> - const struct iommu_ops *ops;
> -};
> -static LIST_HEAD(of_iommu_list);
> -static DEFINE_SPINLOCK(of_iommu_lock);
> -
> -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops)
> -{
> - struct of_iommu_node *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> -
> - if (WARN_ON(!iommu))
> - return;
> -
> - of_node_get(np);
> - INIT_LIST_HEAD(&iommu->list);
> - iommu->np = np;
> - iommu->ops = ops;
> - spin_lock(&of_iommu_lock);
> - list_add_tail(&iommu->list, &of_iommu_list);
> - spin_unlock(&of_iommu_lock);
> -}
> -
> -const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> -{
> - struct of_iommu_node *node;
> - const struct iommu_ops *ops = NULL;
> -
> - spin_lock(&of_iommu_lock);
> - list_for_each_entry(node, &of_iommu_list, list)
> - if (node->np == np) {
> - ops = node->ops;
> - break;
> - }
> - spin_unlock(&of_iommu_lock);
> - return ops;
> -}
> -
> static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> {
> struct of_phandle_args *iommu_spec = data;
> @@ -226,57 +187,3 @@ static int __init of_iommu_init(void)
> return 0;
> }
> postcore_initcall_sync(of_iommu_init);
> -
> -int iommu_fwspec_init(struct device *dev, struct device_node *iommu_np)
> -{
> - struct iommu_fwspec *fwspec = arch_get_iommu_fwspec(dev);
> -
> - if (fwspec)
> - return 0;
> -
> - fwspec = kzalloc(sizeof(*fwspec), GFP_KERNEL);
> - if (!fwspec)
> - return -ENOMEM;
> -
> - fwspec->iommu_np = of_node_get(iommu_np);
> - fwspec->iommu_ops = of_iommu_get_ops(iommu_np);
> - arch_set_iommu_fwspec(dev, fwspec);
> - return 0;
> -}
> -
> -void iommu_fwspec_free(struct device *dev)
> -{
> - struct iommu_fwspec *fwspec = arch_get_iommu_fwspec(dev);
> -
> - if (fwspec) {
> - of_node_put(fwspec->iommu_np);
> - kfree(fwspec);
> - }
> -}
> -
> -int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
> -{
> - struct iommu_fwspec *fwspec = arch_get_iommu_fwspec(dev);
> - size_t size;
> - int i;
> -
> - if (!fwspec)
> - return -EINVAL;
> -
> - size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]);
> - fwspec = krealloc(fwspec, size, GFP_KERNEL);
> - if (!fwspec)
> - return -ENOMEM;
> -
> - for (i = 0; i < num_ids; i++)
> - fwspec->ids[fwspec->num_ids + i] = ids[i];
> -
> - fwspec->num_ids += num_ids;
> - arch_set_iommu_fwspec(dev, fwspec);
> - return 0;
> -}
> -
> -inline struct iommu_fwspec *dev_iommu_fwspec(struct device *dev)
> -{
> - return arch_get_iommu_fwspec(dev);
> -}
> diff --git a/include/linux/iommu-fwspec.h b/include/linux/iommu-fwspec.h
> new file mode 100644
> index 0000000..f88b635
> --- /dev/null
> +++ b/include/linux/iommu-fwspec.h
> @@ -0,0 +1,70 @@
> +#ifndef __IOMMU_FWSPEC_H
> +#define __IOMMU_FWSPEC_H
> +
> +#include <linux/device.h>
> +#include <linux/iommu.h>
> +
> +struct iommu_fwspec {
> + const struct iommu_ops *iommu_ops;
> + struct fwnode_handle *iommu_fwnode;
> + void *iommu_priv;
> + unsigned int num_ids;
> + u32 ids[];
> +};
> +
> +#ifdef CONFIG_IOMMU_FWSPEC
> +int iommu_fwspec_init(struct device *dev,
> + struct fwnode_handle *iommu_fwnode);
> +void iommu_fwspec_free(struct device *dev);
> +int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> +struct iommu_fwspec *dev_iommu_fwspec(struct device *dev);
> +
> +void fwspec_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops);
> +const struct iommu_ops *fwspec_iommu_get_ops(struct fwnode_handle *fwnode);
> +
> +#ifdef CONFIG_HAVE_IOMMU_FWSPEC
> +#include <asm/iommu-fwspec.h>
> +#else /* !CONFIG_HAVE_IOMMU_FWSPEC */
> +static inline void arch_set_iommu_fwspec(struct device *dev,
> + struct iommu_fwspec *fwspec) {}
> +
> +static inline struct iommu_fwspec *
> +arch_get_iommu_fwspec(struct device *dev) { return NULL; }
> +#endif
> +#else /* CONFIG_IOMMU_FWSPEC */
> +static inline int iommu_fwspec_init(struct device *dev,
> + struct fwnode_handle *iommu_fwnode)
> +{
> + return -ENODEV;
> +}
> +
> +static inline void iommu_fwspec_free(struct device *dev)
> +{
> +}
> +
> +static inline int iommu_fwspec_add_ids(struct device *dev, u32 *ids,
> + int num_ids)
> +{
> + return -ENODEV;
> +}
> +
> +static inline struct iommu_fwspec *dev_iommu_fwspec(struct device *dev)
> +{
> + return NULL;
> +}
> +
> +static inline void fwspec_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops)
> +{
> +}
> +
> +static inline const struct iommu_ops *
> +fwspec_iommu_get_ops(struct fwnode_handle *fwnode)
> +{
> + return NULL;
> +}
> +
> +#endif /* CONFIG_IOMMU_FWSPEC */
> +
> +#endif /* __IOMMU_FWSPEC_H */
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index 358db49..4b02861 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -3,6 +3,7 @@
>
> #include <linux/device.h>
> #include <linux/iommu.h>
> +#include <linux/iommu-fwspec.h>
> #include <linux/of.h>
>
> #ifdef CONFIG_OF_IOMMU
> @@ -14,14 +15,6 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
> extern const struct iommu_ops *of_iommu_configure(struct device *dev,
> struct device_node *master_np);
>
> -struct iommu_fwspec {
> - const struct iommu_ops *iommu_ops;
> - struct device_node *iommu_np;
> - void *iommu_priv;
> - unsigned int num_ids;
> - u32 ids[];
> -};
> -
> #else
>
> static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
> @@ -36,28 +29,19 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
> {
> return NULL;
> }
> -
> -struct iommu_fwspec;
> -
> #endif /* CONFIG_OF_IOMMU */
>
> -int iommu_fwspec_init(struct device *dev, struct device_node *iommu_np);
> -void iommu_fwspec_free(struct device *dev);
> -int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> -struct iommu_fwspec *dev_iommu_fwspec(struct device *dev);
> -
> -#ifdef CONFIG_HAVE_IOMMU_FWSPEC
> -#include <asm/iommu-fwspec.h>
> -#else /* !CONFIG_HAVE_IOMMU_FWSPEC */
> -static inline void arch_set_iommu_fwspec(struct device *dev,
> - struct iommu_fwspec *fwspec) {}
> -
> -static inline struct iommu_fwspec *
> -arch_get_iommu_fwspec(struct device *dev) { return NULL; }
> -#endif
> +static inline void of_iommu_set_ops(struct device_node *np,
> + const struct iommu_ops *ops)
> +{
> + fwspec_iommu_set_ops(&np->fwnode, ops);
> +}
>
> -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops);
> -const struct iommu_ops *of_iommu_get_ops(struct device_node *np);
> +static inline const struct iommu_ops *
> +of_iommu_get_ops(struct device_node *np)
> +{
> + return fwspec_iommu_get_ops(&np->fwnode);
> +}
>
> extern struct of_device_id __iommu_of_table;
>
>
^ permalink raw reply
* [PATCH v3 8/9] ARM: sunxi: Enable sun8i-emac driver on sunxi_defconfig
From: LABBE Corentin @ 2016-09-13 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912073008.GD9449@lukather>
On Mon, Sep 12, 2016 at 09:30:08AM +0200, Maxime Ripard wrote:
> Hi,
>
> On Fri, Sep 09, 2016 at 02:45:16PM +0200, Corentin Labbe wrote:
> > Enable the sun8i-emac driver in the sunxi default configuration
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
>
> Could you make the same patch for multi_v7 ?
>
I will
Thanks
^ permalink raw reply
* [PATCHv2 3/3] tty/serial: at91: fix hardware handshake on SAM9x5 (without GPIOs)
From: Alexandre Belloni @ 2016-09-13 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACQ1gAhNdPgtkpt1QPaiKjKi5oaq5vHbt4kKL5tQfwLvDBDo0w@mail.gmail.com>
On 12/09/2016 at 12:50:38 +0200, Richard Genoud wrote :
> >> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> >> index e9b4fbf88c2d..32154e7231ce 100644
> >> --- a/drivers/tty/serial/atmel_serial.c
> >> +++ b/drivers/tty/serial/atmel_serial.c
> >> @@ -2130,15 +2130,19 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> >> } else if ((termios->c_cflag & CRTSCTS) &&
> >> !mctrl_gpio_use_rtscts(atmel_port->gpios)) {
> >> /*
> >> - * RS232 with hardware handshake (RTS/CTS)
> >> - * handled by the controller.
> >> + * Automatic hardware handshake (RTS/CTS) only work with
> >> + * FIFOs or PDC.
> >> + * Meaning that on SAM9x5 the controller can't handle
> >> + * the hardware handshake (no FIFOs nor PDC on these platforms).
> >> */
> >> - if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
> >> - dev_info(port->dev, "not enabling hardware flow control because DMA is used");
> >> - termios->c_cflag &= ~CRTSCTS;
> >> - } else {
> >> + if (atmel_use_pdc_rx(port) || atmel_use_fifo(port))
> >> mode |= ATMEL_US_USMODE_HWHS;
> >> - }
> >> + else
> >> + /*
> >> + * The hardware handshake won't be handle by the
> >> + * controller but by the driver.
> >> + */
> >> + mode |= ATMEL_US_USMODE_NORMAL;
> >
> > You still need the case where HWHS is impossible and there are no gpio
> > configured. You need to inform userspace that the configuration was not
> > applied instead of silently ignoring the error.
>
> Could you explain which case it is ?
> The only one I can see is when there's no GPIO declared for RTS/CTS
> AND, there's no pin muxed for RTS/CTS either.
>
> Have you got another example in mind ?
>
Hum, actually, it is that case. The other one (CRTSCTS and gpios) is
handled in the else below. I think you need to keep the termios->c_cflag
&= ~CRTSCTS; here so that userspace knows configuring it failed.
> >
> >> } else {
> >> /* RS232 without hadware handshake or controlled by GPIOs */
> >> mode |= ATMEL_US_USMODE_NORMAL;
> >
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 05/14] drivers: iommu: make iommu_fwspec OF agnostic
From: Lorenzo Pieralisi @ 2016-09-13 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e8110c4-edf3-15db-206c-b83794f138a0@arm.com>
On Tue, Sep 13, 2016 at 02:38:35PM +0100, Robin Murphy wrote:
> > static int arm_smmu_match_node(struct device *dev, void *data)
> > {
> > - return dev->of_node == data;
> > + struct fwnode_handle *fwnode;
> > +
> > + fwnode = dev->of_node ? &dev->of_node->fwnode : dev->fwnode;
> > +
> > + return fwnode == data;
> > }
>
> Maybe we should hoist the dev_fwnode() helper from property.c up to
> property.h so we can just have "return dev_fwnode(dev) == data;" here?
Yes, that's one way of doing it. The other would be initializing
dev->fwnode to &dev->of_node->fwnode in the DT probe path but first
I need to understand why that is not done in the first place.
[...]
> > +int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
> > +{
> > + struct iommu_fwspec *fwspec = arch_get_iommu_fwspec(dev);
> > + size_t size;
> > +
> > + if (!fwspec)
> > + return -EINVAL;
> > +
> > + size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + 1]);
> > + fwspec = krealloc(fwspec, size, GFP_KERNEL);
> > + if (!fwspec)
> > + return -ENOMEM;
> > +
> > + while (num_ids--)
> > + fwspec->ids[fwspec->num_ids++] = *ids++;
>
> You've still got the +1 bug and incomprehensible loop from the old code
> here, rather than the fixed version being removed below. Although now
> that I've taken the plunge and done it properly in core code from the
> outset, that should hopefully become moot.
Gah sorry, rebase mistake. I will wait for the dust to settle before
churning out a new series, it is hard to respin without a stable
base (hopefully your series will make this patch useless).
Thanks !
Lorenzo
> Robin.
>
> > +
> > + arch_set_iommu_fwspec(dev, fwspec);
> > + return 0;
> > +}
> > +
> > +inline struct iommu_fwspec *dev_iommu_fwspec(struct device *dev)
> > +{
> > + return arch_get_iommu_fwspec(dev);
> > +}
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> > index 38669b8..ab3c069 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -96,45 +96,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> > }
> > EXPORT_SYMBOL_GPL(of_get_dma_window);
> >
> > -struct of_iommu_node {
> > - struct list_head list;
> > - struct device_node *np;
> > - const struct iommu_ops *ops;
> > -};
> > -static LIST_HEAD(of_iommu_list);
> > -static DEFINE_SPINLOCK(of_iommu_lock);
> > -
> > -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops)
> > -{
> > - struct of_iommu_node *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> > -
> > - if (WARN_ON(!iommu))
> > - return;
> > -
> > - of_node_get(np);
> > - INIT_LIST_HEAD(&iommu->list);
> > - iommu->np = np;
> > - iommu->ops = ops;
> > - spin_lock(&of_iommu_lock);
> > - list_add_tail(&iommu->list, &of_iommu_list);
> > - spin_unlock(&of_iommu_lock);
> > -}
> > -
> > -const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> > -{
> > - struct of_iommu_node *node;
> > - const struct iommu_ops *ops = NULL;
> > -
> > - spin_lock(&of_iommu_lock);
> > - list_for_each_entry(node, &of_iommu_list, list)
> > - if (node->np == np) {
> > - ops = node->ops;
> > - break;
> > - }
> > - spin_unlock(&of_iommu_lock);
> > - return ops;
> > -}
> > -
> > static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> > {
> > struct of_phandle_args *iommu_spec = data;
> > @@ -226,57 +187,3 @@ static int __init of_iommu_init(void)
> > return 0;
> > }
> > postcore_initcall_sync(of_iommu_init);
> > -
> > -int iommu_fwspec_init(struct device *dev, struct device_node *iommu_np)
> > -{
> > - struct iommu_fwspec *fwspec = arch_get_iommu_fwspec(dev);
> > -
> > - if (fwspec)
> > - return 0;
> > -
> > - fwspec = kzalloc(sizeof(*fwspec), GFP_KERNEL);
> > - if (!fwspec)
> > - return -ENOMEM;
> > -
> > - fwspec->iommu_np = of_node_get(iommu_np);
> > - fwspec->iommu_ops = of_iommu_get_ops(iommu_np);
> > - arch_set_iommu_fwspec(dev, fwspec);
> > - return 0;
> > -}
> > -
> > -void iommu_fwspec_free(struct device *dev)
> > -{
> > - struct iommu_fwspec *fwspec = arch_get_iommu_fwspec(dev);
> > -
> > - if (fwspec) {
> > - of_node_put(fwspec->iommu_np);
> > - kfree(fwspec);
> > - }
> > -}
> > -
> > -int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
> > -{
> > - struct iommu_fwspec *fwspec = arch_get_iommu_fwspec(dev);
> > - size_t size;
> > - int i;
> > -
> > - if (!fwspec)
> > - return -EINVAL;
> > -
> > - size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]);
> > - fwspec = krealloc(fwspec, size, GFP_KERNEL);
> > - if (!fwspec)
> > - return -ENOMEM;
> > -
> > - for (i = 0; i < num_ids; i++)
> > - fwspec->ids[fwspec->num_ids + i] = ids[i];
> > -
> > - fwspec->num_ids += num_ids;
> > - arch_set_iommu_fwspec(dev, fwspec);
> > - return 0;
> > -}
> > -
> > -inline struct iommu_fwspec *dev_iommu_fwspec(struct device *dev)
> > -{
> > - return arch_get_iommu_fwspec(dev);
> > -}
> > diff --git a/include/linux/iommu-fwspec.h b/include/linux/iommu-fwspec.h
> > new file mode 100644
> > index 0000000..f88b635
> > --- /dev/null
> > +++ b/include/linux/iommu-fwspec.h
> > @@ -0,0 +1,70 @@
> > +#ifndef __IOMMU_FWSPEC_H
> > +#define __IOMMU_FWSPEC_H
> > +
> > +#include <linux/device.h>
> > +#include <linux/iommu.h>
> > +
> > +struct iommu_fwspec {
> > + const struct iommu_ops *iommu_ops;
> > + struct fwnode_handle *iommu_fwnode;
> > + void *iommu_priv;
> > + unsigned int num_ids;
> > + u32 ids[];
> > +};
> > +
> > +#ifdef CONFIG_IOMMU_FWSPEC
> > +int iommu_fwspec_init(struct device *dev,
> > + struct fwnode_handle *iommu_fwnode);
> > +void iommu_fwspec_free(struct device *dev);
> > +int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> > +struct iommu_fwspec *dev_iommu_fwspec(struct device *dev);
> > +
> > +void fwspec_iommu_set_ops(struct fwnode_handle *fwnode,
> > + const struct iommu_ops *ops);
> > +const struct iommu_ops *fwspec_iommu_get_ops(struct fwnode_handle *fwnode);
> > +
> > +#ifdef CONFIG_HAVE_IOMMU_FWSPEC
> > +#include <asm/iommu-fwspec.h>
> > +#else /* !CONFIG_HAVE_IOMMU_FWSPEC */
> > +static inline void arch_set_iommu_fwspec(struct device *dev,
> > + struct iommu_fwspec *fwspec) {}
> > +
> > +static inline struct iommu_fwspec *
> > +arch_get_iommu_fwspec(struct device *dev) { return NULL; }
> > +#endif
> > +#else /* CONFIG_IOMMU_FWSPEC */
> > +static inline int iommu_fwspec_init(struct device *dev,
> > + struct fwnode_handle *iommu_fwnode)
> > +{
> > + return -ENODEV;
> > +}
> > +
> > +static inline void iommu_fwspec_free(struct device *dev)
> > +{
> > +}
> > +
> > +static inline int iommu_fwspec_add_ids(struct device *dev, u32 *ids,
> > + int num_ids)
> > +{
> > + return -ENODEV;
> > +}
> > +
> > +static inline struct iommu_fwspec *dev_iommu_fwspec(struct device *dev)
> > +{
> > + return NULL;
> > +}
> > +
> > +static inline void fwspec_iommu_set_ops(struct fwnode_handle *fwnode,
> > + const struct iommu_ops *ops)
> > +{
> > +}
> > +
> > +static inline const struct iommu_ops *
> > +fwspec_iommu_get_ops(struct fwnode_handle *fwnode)
> > +{
> > + return NULL;
> > +}
> > +
> > +#endif /* CONFIG_IOMMU_FWSPEC */
> > +
> > +#endif /* __IOMMU_FWSPEC_H */
> > diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> > index 358db49..4b02861 100644
> > --- a/include/linux/of_iommu.h
> > +++ b/include/linux/of_iommu.h
> > @@ -3,6 +3,7 @@
> >
> > #include <linux/device.h>
> > #include <linux/iommu.h>
> > +#include <linux/iommu-fwspec.h>
> > #include <linux/of.h>
> >
> > #ifdef CONFIG_OF_IOMMU
> > @@ -14,14 +15,6 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
> > extern const struct iommu_ops *of_iommu_configure(struct device *dev,
> > struct device_node *master_np);
> >
> > -struct iommu_fwspec {
> > - const struct iommu_ops *iommu_ops;
> > - struct device_node *iommu_np;
> > - void *iommu_priv;
> > - unsigned int num_ids;
> > - u32 ids[];
> > -};
> > -
> > #else
> >
> > static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
> > @@ -36,28 +29,19 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
> > {
> > return NULL;
> > }
> > -
> > -struct iommu_fwspec;
> > -
> > #endif /* CONFIG_OF_IOMMU */
> >
> > -int iommu_fwspec_init(struct device *dev, struct device_node *iommu_np);
> > -void iommu_fwspec_free(struct device *dev);
> > -int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> > -struct iommu_fwspec *dev_iommu_fwspec(struct device *dev);
> > -
> > -#ifdef CONFIG_HAVE_IOMMU_FWSPEC
> > -#include <asm/iommu-fwspec.h>
> > -#else /* !CONFIG_HAVE_IOMMU_FWSPEC */
> > -static inline void arch_set_iommu_fwspec(struct device *dev,
> > - struct iommu_fwspec *fwspec) {}
> > -
> > -static inline struct iommu_fwspec *
> > -arch_get_iommu_fwspec(struct device *dev) { return NULL; }
> > -#endif
> > +static inline void of_iommu_set_ops(struct device_node *np,
> > + const struct iommu_ops *ops)
> > +{
> > + fwspec_iommu_set_ops(&np->fwnode, ops);
> > +}
> >
> > -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops);
> > -const struct iommu_ops *of_iommu_get_ops(struct device_node *np);
> > +static inline const struct iommu_ops *
> > +of_iommu_get_ops(struct device_node *np)
> > +{
> > + return fwspec_iommu_get_ops(&np->fwnode);
> > +}
> >
> > extern struct of_device_id __iommu_of_table;
> >
> >
>
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC DT Updates for v4.9
From: Arnd Bergmann @ 2016-09-13 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1471251169.git.horms+renesas@verge.net.au>
On Monday, August 15, 2016 10:55:35 AM CEST Simon Horman wrote:
> Renesas ARM Based SoC DT Updates for v4.9
>
> * Add DU, VIN, I2C, SDHI, EtherAVB, GPIO support to r8a7792
> * Enable CAN0 on r8a7792/blanche
> * Enable sound on r8a7794/silk
> * Correct SDHI register size on r8a7794
>
Pulled into next/dt, thanks and sorry for the long delay.
Arnd
^ permalink raw reply
* [PATCH] iommu/io-pgtable-arm: Check for v7s-incapable systems
From: Auger Eric @ 2016-09-13 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2e473e263ac469bd6d3b09e7756c138325e10969.1473773198.git.robin.murphy@arm.com>
Hi,
On 13/09/2016 15:26, Robin Murphy wrote:
> On machines with no 32-bit addressable RAM whatsoever, we shouldn't
> even touch the v7s format as it's never going to work.
>
> Fixes: e5fc9753b1a8 ("iommu/io-pgtable: Add ARMv7 short descriptor support")
> Reported-by: Eric Auger <eric.auger@redhat.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/io-pgtable-arm-v7s.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> index def8ca1c982d..b7759a48f4ed 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -633,6 +633,9 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
> {
> struct arm_v7s_io_pgtable *data;
>
> + if (upper_32_bits(PHYS_OFFSET))
> + return NULL;
> +
> if (cfg->ias > ARM_V7S_ADDR_BITS || cfg->oas > ARM_V7S_ADDR_BITS)
> return NULL;
>
>
Fixes the oops on AMD Overdrive
(CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST=y and no DMA_API)
Tested-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
^ permalink raw reply
* [PATCH 0/3] ARM: dts: artpec6.dtsi updates
From: Arnd Bergmann @ 2016-09-13 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1471959733.git.larper@axis.com>
On Tuesday, August 23, 2016 4:00:49 PM CEST Lars Persson wrote:
> This brings the dtsi up to date with with tested and optimized settings from the
> Axis tree.
>
> Lars Persson (3):
> ARM: dts: artpec: use clock binding header
> ARM: dts: artpec: use optimized pl310 settings
> ARM: dts: artpec: set irq affinity on pmu interrupts
>
> arch/arm/boot/dts/artpec6.dtsi | 31 ++++++++++++++++++++-----------
> 1 file changed, 20 insertions(+), 11 deletions(-)
>
>
Applied all three to next/dt, thanks for your patience and sorry
for the delay on my side.
Arnd
^ permalink raw reply
* [GIT PULL] LPC18xx DTS changes for v4.9
From: Arnd Bergmann @ 2016-09-13 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160827143311.7303-1-manabian@gmail.com>
On Saturday, August 27, 2016 4:33:11 PM CEST Joachim Eastwood wrote:
> Device Tree additions for LPC18xx platform
>
> Small fix for the compatible string for the NXP SE97 I2C chip on the
> Hitex Eval board from Guenter and a couple of additional DT properties
> for the DWMAC that is need for correct operation.
Pulled into next/dt, thanks!
Sorry for not having looked at it earlier, I would probably have suggested
to apply both as a bugfix for v4.8, but if you didn't consider them
urgent enough then, it's probably not worth bothering now.
Arnd
^ permalink raw reply
* [GIT PULL 2/4] ARM: dts: exynos: DeviceTree for v4.9
From: Arnd Bergmann @ 2016-09-13 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472548739-20050-3-git-send-email-k.kozlowski@samsung.com>
On Tuesday, August 30, 2016 11:18:57 AM CEST Krzysztof Kozlowski wrote:
> Samsung DeviceTree update for v4.9:
> 1. Set chosen serial bitrate which allows proper serial output when
> bootloader does pass all the data in command line.
> 2. Cleanup.
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH v3 3/9] ARM: sun8i: dt: Add DT bindings documentation for Allwinner sun8i-emac
From: Andrew Lunn @ 2016-09-13 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913133417.GC31990@Red>
On Tue, Sep 13, 2016 at 03:34:17PM +0200, LABBE Corentin wrote:
> On Fri, Sep 09, 2016 at 04:17:10PM +0200, Andrew Lunn wrote:
> > > +Optional properties:
> > > +- allwinner,tx-delay: TX clock delay chain value. Range value is 0-0x07. Default is 0)
> > > +- allwinner,rx-delay: RX clock delay chain value. Range value is 0-0x1F. Default is 0)
> >
> > What are the units? pS? nS?
> >
> > Andrew
>
> No units, only raw number.
> I will add a comment for this.
And it is likely it will get NACKed by the device tree
maintainers. You should use real unit here.
Andrew
^ permalink raw reply
* [PATCH 2/3] drm: add ARM vendor format afbc
From: Brian Starkey @ 2016-09-13 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473474544-16248-2-git-send-email-mark.yao@rock-chips.com>
Hi Mark,
On Sat, Sep 10, 2016 at 10:29:03AM +0800, Mark Yao wrote:
>AFBC is arm vendor format, it's a compressed format.
>
>The AFBC format is supported by rk3399 vop big.
>
>We know little about AFBC layout, hope to some guys can
>fixme about the afbc comment.
>
>Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
>---
> include/uapi/drm/drm_fourcc.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
>diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>index a5890bf..9a47d7e 100644
>--- a/include/uapi/drm/drm_fourcc.h
>+++ b/include/uapi/drm/drm_fourcc.h
>@@ -159,6 +159,7 @@ extern "C" {
> #define DRM_FORMAT_MOD_VENDOR_NV 0x03
> #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
> #define DRM_FORMAT_MOD_VENDOR_QCOM 0x05
>+#define DRM_FORMAT_MOD_VENDOR_ARM 0x06
> /* add more to the end as needed */
>
> #define fourcc_mod_code(vendor, val) \
>@@ -233,6 +234,12 @@ extern "C" {
> */
> #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
>
>+/*
>+ * FIXME: AFBC is arm vendor format, it's a compressed format.
>+ *
>+ */
>+#define DRM_FORMAT_MOD_ARM_AFBC fourcc_mod_code(ARM, 1)
Do you have any details about the exact type of AFBC data you are
consuming here?
We need to agree what exactly a buffer with the modifier
"DRM_FORMAT_MOD_ARM_AFBC" means. For instance the block size, whether
the data has the YUV transform applied, how the data is laid out in
memory etc.
We (ARM) want to make sure that the format modifiers we expose to
userspace for AFBC are precise and non-ambiguous, cover all
possible AFBC modifiers (of which there are many, and the list can
only get longer) and all possible AFBC consuming/producing IPs'
requirements.
We had intended to delay adding any AFBC format modifiers to DRM until
we'd had this kind of discussion internally to agree the exact set
of modifiers we need, but if you need this now then we can start that
discussion here.
Thanks,
Brian
>+
> #if defined(__cplusplus)
> }
> #endif
>--
>1.9.1
>
>
>_______________________________________________
>dri-devel mailing list
>dri-devel at lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 6/8 v2] arm: orion5x: Add DT-based support for Netgear WNR854T
From: Jamie Lentin @ 2016-09-13 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913123639.GB15332@lunn.ch>
On 2016-09-13 13:36, Andrew Lunn wrote:
> On Tue, Sep 13, 2016 at 10:10:41AM +0100, Jamie Lentin wrote:
>> On 2016-09-12 23:03, Andrew Lunn wrote:
>> >>Maybe we can instead leave out the PCI support from the new
>> >>file for now and not delete the legacy board file?
>>
>> This seems a reasonable compromise. The PCI card the router comes
>> with isn't supported by mwl8k mainline anyway (There's STA-only
>> firmware that can be extracted from a windows driver and PCI IDs
>> added, but stats reporting uses a different format), so it's not a
>> huge loss, although many did replace the card with something
>> Atheros-based.
>
> O.K. So dropping the PCI code gets us going forward.
Is an arch/arm/mach-mvebu/orion5x.c also required? Or is continuing to
use arch/arm/mach-orion5x/board-dt.c until everything has been converted
the favoured approach?
> Have we missed the merge window?
I got the impression Gregory Clement had merged them? If not a good
portion of this patchset is uncontroversial generic orion5x stuff, it'd
be nice to get those in even if none of the router-specific stuff
doesn't make it.
>> Unfortunately the power regulator on my spare router has stopped
>> regulating, which will make more development tricky.
>
> The Green Light of death?
Seems that way, the 3.3v line is only getting up to 2.8v. My routers
have had their power supply sections hacked in comparison to photos I've
seen on GLOD pages, so I presumed this was fixed. Apparently not. Maybe
I can persuade it to be useful with 5v + 3.3v in the right places.
>> >Jamie, which interrupt do you see the WiFi card using? If it is
>> >IRQ_ORION5X_PCIE0_INT, (1 + 11), that is probably easier to deal with
>> >than if it uses GPIO 4.
>>
>> Definitely uses GPIO 4.
>
> O.K, that makes it more interesting. As far as i can see, no other
> PCIe system uses a GPIO for its interrupt. There is no core support
> for this, or any bus driver doing it. So there is no binding to
> follow.
Not sure if the difference is relevant at this point but it's regular
PCI, not PCIe.
>
> Andrew
^ permalink raw reply
* [PATCH V5] perf tools: adding support for address filters
From: Mathieu Poirier @ 2016-09-13 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cd7b9dc9-686c-813e-ff9f-97faba377799@intel.com>
On 13 September 2016 at 04:01, Adrian Hunter <adrian.hunter@intel.com> wrote:
> On 12/09/16 20:53, Mathieu Poirier wrote:
>> This patch makes it possible to use the current filter
>> framework with address filters. That way address filters for
>> HW tracers such as CoreSight and IntelPT can be communicated
>> to the kernel drivers.
>>
>> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>>
>> ---
>> Changes for V5:
>> - Modified perf_evsel__append_filter() to take a string format
>> rather than an operation.
>
> Hope I'm not being a pain, but aren't there other places calling
> perf_evsel__append_filter() that need to be changed. Might make
> sense as a separate patch.
No no, you're right - I completely overlooked that.
But shouldn't it be in the same patch? That way a git bisect would
stay consistent...
>
>>
>> Changes for V4:
>> - Added support for address filters over more than one
>> nibble.
>> - Removed Jiri's ack, this version is too different from
>> what was reviewed.
>>
>> Changes for V3:
>> - Added Jiri's ack.
>> - Rebased to v4.8-rc5.
>>
>> Changes for V2:
>> - Rebased to v4.8-rc4.
>> - Revisited error path.
>>
>>
>> tools/perf/util/evsel.c | 4 ++--
>> tools/perf/util/evsel.h | 2 +-
>> tools/perf/util/parse-events.c | 40 +++++++++++++++++++++++++++++++++++-----
>> 3 files changed, 38 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
>> index d40f852d2de2..a9bb277f221f 100644
>> --- a/tools/perf/util/evsel.c
>> +++ b/tools/perf/util/evsel.c
>> @@ -1047,14 +1047,14 @@ int perf_evsel__set_filter(struct perf_evsel *evsel, const char *filter)
>> }
>>
>> int perf_evsel__append_filter(struct perf_evsel *evsel,
>> - const char *op, const char *filter)
>> + const char *fmt, const char *filter)
>> {
>> char *new_filter;
>>
>> if (evsel->filter == NULL)
>> return perf_evsel__set_filter(evsel, filter);
>>
>> - if (asprintf(&new_filter,"(%s) %s (%s)", evsel->filter, op, filter) > 0) {
>> + if (asprintf(&new_filter, fmt, evsel->filter, filter) > 0) {
>> free(evsel->filter);
>> evsel->filter = new_filter;
>> return 0;
>> diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
>> index 8ceb7ebb51f5..50595c8c7207 100644
>> --- a/tools/perf/util/evsel.h
>> +++ b/tools/perf/util/evsel.h
>> @@ -236,7 +236,7 @@ void perf_evsel__set_sample_id(struct perf_evsel *evsel,
>>
>> int perf_evsel__set_filter(struct perf_evsel *evsel, const char *filter);
>> int perf_evsel__append_filter(struct perf_evsel *evsel,
>> - const char *op, const char *filter);
>> + const char *fmt, const char *filter);
>> int perf_evsel__apply_filter(struct perf_evsel *evsel, int ncpus, int nthreads,
>> const char *filter);
>> int perf_evsel__apply_drv_configs(struct perf_evsel *evsel,
>> diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
>> index 2eb8b1ed4cc8..8e683979ccd8 100644
>> --- a/tools/perf/util/parse-events.c
>> +++ b/tools/perf/util/parse-events.c
>> @@ -1760,20 +1760,50 @@ foreach_evsel_in_last_glob(struct perf_evlist *evlist,
>> static int set_filter(struct perf_evsel *evsel, const void *arg)
>> {
>> const char *str = arg;
>> + bool found = false;
>> + int nr_addr_filters = 0;
>> + struct perf_pmu *pmu = NULL;
>>
>> - if (evsel == NULL || evsel->attr.type != PERF_TYPE_TRACEPOINT) {
>> - fprintf(stderr,
>> - "--filter option should follow a -e tracepoint option\n");
>> - return -1;
>> + if (evsel == NULL)
>> + goto err;
>> +
>> + if (evsel->attr.type == PERF_TYPE_TRACEPOINT) {
>> + if (perf_evsel__append_filter(evsel,
>> + "(%s) && (%s)", str) < 0) {
>> + fprintf(stderr,
>> + "not enough memory to hold filter string\n");
>> + return -1;
>> + }
>> +
>> + return 0;
>> }
>>
>> - if (perf_evsel__append_filter(evsel, "&&", str) < 0) {
>> + while ((pmu = perf_pmu__scan(pmu)) != NULL)
>> + if (pmu->type == evsel->attr.type) {
>> + found = true;
>> + break;
>> + }
>> +
>> + if (found)
>> + perf_pmu__scan_file(pmu, "nr_addr_filters",
>> + "%d", &nr_addr_filters);
>> +
>> + if (!nr_addr_filters)
>> + goto err;
>> +
>> + if (perf_evsel__append_filter(evsel, "%s,%s", str) < 0) {
>> fprintf(stderr,
>> "not enough memory to hold filter string\n");
>> return -1;
>> }
>>
>> return 0;
>> +
>> +err:
>> + fprintf(stderr,
>> + "--filter option should follow a -e tracepoint or HW tracer option\n");
>> +
>> + return -1;
>> }
>>
>> int parse_filter(const struct option *opt, const char *str,
>>
>
^ permalink raw reply
* [PATCH v2 0/4] ARM: amlogic: Add spifc support to Amlogic's GXBB family
From: Kevin Hilman @ 2016-09-13 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473753807.2662.12.camel@baylibre.com>
jbrunet <jbrunet@baylibre.com> writes:
> On Mon, 2016-09-12 at 13:38 -0700, Kevin Hilman wrote:
>> Jerome Brunet <jbrunet@baylibre.com> writes:
>>
>> >
>> > This patch series adds the necessary pins, clocks and device tree
>> > nodes to
>> > enable the spifc controller on the GXBB family. I had to add the
>> > nand pins
>> > in pintctrl as the pinmux setting left by u-boot was conflicting
>> > with the
>> > spifc pinmux during my test on the P200.
>>
>> This series seems to be missing a patch which enables the SPIfc on
>> the
>> P200 board for use with the on-board NOR flash.
>>
>
> Indeed, I did not provide this patch, on purpose.
> The SPI-NOR at 4U2 on the P200 schematics was not present on the board
> I have. I assumed this was the case for all other P200 as well.
>
> In addition, to enable the SPI-NOR, you would also need to solder
> something at 4R3 (SPI_CS signal disconnected by default)
OK, that makes seense. I thought the NOR was on the board by default.
> Finally, all the SPIfc lines are shared with the NAND controller which,
> like the SPI-NOR, appears on the schematics (4CCN1) but is not soldered
> on the actual hardware.
>
> Of course, I can share such patch for testing purposes if you would
> like me to.
Yeah, having a testing patch in the list archives would be useful.
Thanks,
Kevin
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Sebastian Frias @ 2016-09-13 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913131208.GA23336@leverpostej>
Hi Mark,
On 09/13/2016 03:12 PM, Mark Rutland wrote:
>> Exactly, that is why I was thinking it would take less "review" time.
>> Indeed, if there is no driver, why would it matter what those bindings
>> are?
>
> If you believe that the bindings don't matter, then there is absolutely
> no reason for them to exist in the first place.
Again, they would be there serving as HW description. Like documentation.
3rd parties and the open-source community could then use them to write
drivers.
Also, it would avoid having multiple DTs (bootloader, Linux, etc.) or
using 'binary DT overlays'.
In one case the nodes/properties would be made public, most likely with
documentation (even if there's no driver for them), in the other case
undocumented 'binary DT overlays' are used.
>
> If those binding matter to *anyone*, then those collating the bindings
> have some responsibility of stewardship, and that includes
> review/maintenance/etc.
>
> Hence, the Linux community cares as stewards of those bindings, and
> don't accept bindings they don't understand, for which there is no
> obvious user, nor for which the authors claim stability does not matter.
> Those go against the aims of DT, and against out responsiblities as
> stewards.
>
> I cannot put that any clearer.
I understand that.
However, it does not looks crazy to add some sort of 'staging', actually,
I found this:
$ find . -name 'stag*'
./Documentation/devicetree/bindings/staging
./drivers/staging
...
$ ls -1R ./Documentation/devicetree/bindings/staging
./Documentation/devicetree/bindings/staging:
iio
ion
./Documentation/devicetree/bindings/staging/iio:
adc
./Documentation/devicetree/bindings/staging/iio/adc:
lpc32xx-adc.txt
spear-adc.txt
./Documentation/devicetree/bindings/staging/ion:
hi6220-ion.txt
$ ls -1R ./drivers/staging | wc -l
2134
Isn't that a similar use to the one discussed in this thread?
>> Only for bindings for which there is a driver.
>
> This is not true for all but the most trivial of hardware, as I stated
> previously.
>
> Go and take a look at all the effort that went into sorting out generic
> IOMMU bindings, when driver support was written after a large amount of
> review to sort out fundamental concepts. We had to sort out fundamentals
> before prototype driver code could be written, and while we knew drivers
> were coming, an awful lot of review effort came first.
Again, you are talking about drivers, but it is not the case at hand.
DT seems essentially free-form, like XML.
One could imagine that some tool could then be used to guarantee that
some parts of DT conform to a given XML schema, including backwards
compatibility, while at the same time ignoring 'staging' stuff.
>> Think about this:
>> - a binding with no driver is submitted and ends up in the tree
>> (it could be on a staging area if necessary)
>>
>> - if at a later point somebody attempts to upstream a driver using those
>> 'staging' bindings, the reviewers could say "you are using 'staging' bindings,
>> please add compatibility with 'staging' and 'standard' bindings", even if that
>> includes the discussion and review of newly created 'standard' bindings
>> corresponding to the 'staging' bindings.
>>
>> - the submitter may even say "there's no need for compatibility for 'staging'
>> bindings, because they were never used (or other valid reasons)".
>>
>> What would you think of something like that?
>
> As above, if they were never used, and potentially wrong, why did they
> exist?
The last step of my description, where the 'staging' bindings may not have
been used, was listed only for the sake of completeness since it is just a
possibility.
The hope is that they would be eventually used (most likely as is, but
there is also the possibility of having to rethink the bindings when
moving them from 'staging' to 'stable').
> Trying to upstream a binding with no user comees with no immediate
> benefit, and potentially creates longer-term pain, whereas you can defer
> upstreaming a binding until the driver is ready.
The immediate benefit is complete HW description, which, if generalised and
done properly would amount to HW documentation, isn't that good?
> Note that I've repeatedly pointed out that the user of the binding
> doesn't necessarily have to be linux. However, there does need to be
> some demonstration, and commitment to maintaining the principles DT aims
> towards (e.g. stability).
The commitment to stability can be enforced later, since changes would be
reviewed.
If the "user of the binding" is not Linux, under what circumstances
could "Linux" have the legitimacy of guaranteeing or enforcing any Linux-
specific commitment?
>> Let's make an abstraction of the word 'binding', 'create a binding', etc. and
>> just focus on this:
>> - Somebody submits a DT file that contains properties and nodes that are
>> *not used* by any Linux driver.
>> - Said properties and nodes serve as HW description for HW blocks for which
>> *there is no* Linux driver.
>>
>> The goal of the above is to use the DT as the authoritative (and single)
>> source of HW definition.
>
> I understand that goal, and I've asked for a specific example, as this
> is not clear-cut. e.g. there has been work on describing secure devices
> for QEMU, but this isn't necessarily something we want to expose Linux
> to in general.
Interesting, do you know where in QEMU's code should I look for that?
Because the example I had in mind is something like (totally out of my
imagination):
/sigma/ {
audio_decoder_0: {
version = <2>;
revision = <1>;
program-memory = <0x20100000 0x1000>;
data-memory = <0x20101000 0x1000>;
hwbug-list = <33, 57, 11>;
arch = <DSP32>;
mutex-id = <12>;
irq-line = <9>;
mbus-read-channels = <2, 3>;
mbus-write-channels = <12, 13>;
has-AAC-support = <1>;
has-DTS-support = <1>;
has-SPDIF-output = <1>;
...
};
audio_decoder_1: {
version = <1>;
revision = <0>;
program-memory = <0x20200000 0x1000>;
data-memory = <0x20201000 0x1000>;
hwbug-list = <33, 57>;
arch = <DSP16>;
mutex-id = <11>;
irq-line = <8>;
mbus-read-channels = <4>;
mbus-write-channels = <14>;
has-AAC-support = <1>;
has-DTS-support = <0>;
has-SPDIF-output = <0>;
...
};
ethernet: {
mac-address = [ 00 11 22 33 44 55 ];
hwbug-list = <23>;
};
video_decoder: {
version = <4>;
revision = <0>;
memory = <0x20300000 0x10000>;
arch = <MIPS4K>;
mutex-id = <12>;
irq-line = <7>;
has-H264-support = <1>;
...
};
...
};
We could even imagine a section like:
boot: {
verify-images = <1>;
boot-order = <NAND, SD, SATA>;
enable-uart = <0>;
debug-level = <1>;
};
>> Ok, so if the information is not relevant to Linux do you agree that it
>> should not affect it, and then we could imagine such details being present on
>> the DT anyway?
>
> Perhaps, or perhaps not. It depends on a number of details, and as I've
> said previously I cannot give you a general answer, because there is
> none. You must provide a specific case.
I gave one above, but I still don't understand why would it matter.
I mean, it should be easy:
- is the node/property used by a Linux driver?
- YES => you must submit both DT+driver
- NO => we don't care
>> You mention the case of another OS.
>> What is the definition of OS in this case?
>
> Generally, I am considering a general purpose OS (e.g. Linux, FreeBSD),
> and not a secure-world trusted OS nor firmware (as typically these are
> very strongly tied to the platform, and have very different strtuctures
> and requirements when compared to a general purpose OS).
>
> That's the conext in which bindings are developed.
>
I see, thanks.
>> Because one could say that "FW" or "secure world" could fit that definition,
>> right?
>
> There's been work on describing things about the secure world in DT for
> QEMU. Firmware is typically so device-specific that an upstream/common
> DT doesn't really make sense.
>
> Perhaps you have an example of the specific use-case you care about?
Like I said, this started like an hypothetical question as a way to centralise
all HW description in a single place.
Currently it is spread over multiple places and it is very error prone, not
to mention that not everybody gets all the information at once.
Also, DT is meant to be shared by at least Bootloader and Linux, so it would
be better if it was unique.
Anyway, I tried to make a more concrete example further above.
Hopefully it serves to illustrate more the idea.
>> Indeed, to me it is clear that what we conceive "differently", is that
>> "the effort", "lack of benefit for the community", "Old bindings should
>> remain supported regardless" and "backward compatibility" are considered
>> with respect to DT *plus* driver, yet the idea is to have DT describe
>> HW for which there's no upstream driver yet.
>> Hence most of those considerations should not apply, right?
>
> No.
>
> Bindings themselves should remain stable over time in that they must be
> evolved so as to allow software to handle them in a stable fashion,
> supporting old and new DTBs.
Yes, but "must be evolved so as to allow software to handle them in a stable
fashion, supporting old and new DTBs." makes sense for Linux drivers, or
from Linux's perspective.
Project independence rules should allow for projects to cooperate without
interfering with each other.
>
> While a lot of that effort is taken by code, care must also be taken wit
> the bindings themselves, and those considerations apply.
IMHO, they apply only when there's a Linux driver, or any other public
user of such bindings. But if there's no user, it seems like an unnecessary
constraint.
Best regards,
Sebastian
^ permalink raw reply
* [GIT PULL 1/2] ARM: dts: Keystone DTS for 4.9
From: Arnd Bergmann @ 2016-09-13 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472684710-22905-1-git-send-email-ssantosh@kernel.org>
On Wednesday, August 31, 2016 7:05:09 PM CEST Santosh Shilimkar wrote:
> ARM: dts: Keystone DTS for 4.9
>
> Add K2G nodes for GPIO, IRQ and Message Manager
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH 1/3] PCI: Xilinx NWL PCIe: Expanding PCIe core errors and printing event occurred.
From: Bjorn Helgaas @ 2016-09-13 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472553558-27215-1-git-send-email-bharatku@xilinx.com>
Hi Bharat,
On Tue, Aug 30, 2016 at 04:09:16PM +0530, Bharat Kumar Gogada wrote:
> The current driver prints pcie core error, for all core events.
> Instead of just printing PCIe core error, now adding prints to show
> individual core events occurred.
>
> Signed-off-by: Bharat Kumar Gogada <bharatku@xilinx.com>
> ---
> drivers/pci/host/pcie-xilinx-nwl.c | 48 +++++++++++++++++++++++++++++++-------
> 1 file changed, 40 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-xilinx-nwl.c b/drivers/pci/host/pcie-xilinx-nwl.c
> index 3479d30..86c1834 100644
> --- a/drivers/pci/host/pcie-xilinx-nwl.c
> +++ b/drivers/pci/host/pcie-xilinx-nwl.c
> @@ -85,10 +85,15 @@
> #define MSGF_MISC_SR_MASTER_ERR BIT(5)
> #define MSGF_MISC_SR_I_ADDR_ERR BIT(6)
> #define MSGF_MISC_SR_E_ADDR_ERR BIT(7)
> -#define MSGF_MISC_SR_UR_DETECT BIT(20)
> -
> -#define MSGF_MISC_SR_PCIE_CORE GENMASK(18, 16)
> -#define MSGF_MISC_SR_PCIE_CORE_ERR GENMASK(31, 22)
> +#define MSGF_MISC_SR_FATAL_AER BIT(16)
> +#define MSGF_MISC_SR_NON_FATAL_AER BIT(17)
> +#define MSGF_MISC_SR_CORR_AER BIT(18)
> +#define MSGF_MISC_SR_UR_DETECT BIT(20)
> +#define MSGF_MISC_SR_NON_FATAL_DEV BIT(22)
> +#define MSGF_MISC_SR_FATAL_DEV BIT(23)
> +#define MSGF_MISC_SR_LINK_DOWN BIT(24)
> +#define MSGF_MSIC_SR_LINK_AUTO_BWIDTH BIT(25)
> +#define MSGF_MSIC_SR_LINK_BWIDTH BIT(26)
>
> #define MSGF_MISC_SR_MASKALL (MSGF_MISC_SR_RXMSG_AVAIL | \
> MSGF_MISC_SR_RXMSG_OVER | \
> @@ -96,9 +101,15 @@
> MSGF_MISC_SR_MASTER_ERR | \
> MSGF_MISC_SR_I_ADDR_ERR | \
> MSGF_MISC_SR_E_ADDR_ERR | \
> + MSGF_MISC_SR_FATAL_AER | \
> + MSGF_MISC_SR_NON_FATAL_AER | \
> + MSGF_MISC_SR_CORR_AER | \
> MSGF_MISC_SR_UR_DETECT | \
> - MSGF_MISC_SR_PCIE_CORE | \
> - MSGF_MISC_SR_PCIE_CORE_ERR)
> + MSGF_MISC_SR_NON_FATAL_DEV | \
> + MSGF_MISC_SR_FATAL_DEV | \
> + MSGF_MISC_SR_LINK_DOWN | \
> + MSGF_MSIC_SR_LINK_AUTO_BWIDTH | \
> + MSGF_MSIC_SR_LINK_BWIDTH)
>
> /* Legacy interrupt status mask bits */
> #define MSGF_LEG_SR_INTA BIT(0)
> @@ -291,8 +302,29 @@ static irqreturn_t nwl_pcie_misc_handler(int irq, void *data)
> dev_err(pcie->dev,
> "In Misc Egress address translation error\n");
>
> - if (misc_stat & MSGF_MISC_SR_PCIE_CORE_ERR)
> - dev_err(pcie->dev, "PCIe Core error\n");
> + if (misc_stat & MSGF_MISC_SR_FATAL_AER)
> + dev_err(pcie->dev, "Fatal Error in AER Capability\n");
> +
> + if (misc_stat & MSGF_MISC_SR_NON_FATAL_AER)
> + dev_err(pcie->dev, "Non-Fatal Error in AER Capability\n");
> +
> + if (misc_stat & MSGF_MISC_SR_CORR_AER)
> + dev_err(pcie->dev, "Correctable Error in AER Capability\n");
> +
> + if (misc_stat & MSGF_MISC_SR_UR_DETECT)
> + dev_err(pcie->dev, "Unsupported request Detected\n");
> +
> + if (misc_stat & MSGF_MISC_SR_NON_FATAL_DEV)
> + dev_err(pcie->dev, "Non-Fatal Error Detected\n");
> +
> + if (misc_stat & MSGF_MISC_SR_FATAL_DEV)
> + dev_err(pcie->dev, "Fatal Error Detected\n");
> +
> + if (misc_stat & MSGF_MSIC_SR_LINK_AUTO_BWIDTH)
> + dev_info(pcie->dev, "Link Autonomous Bandwidth Management Status bit set\n");
> +
> + if (misc_stat & MSGF_MSIC_SR_LINK_BWIDTH)
> + dev_info(pcie->dev, "Link Bandwidth Management Status bit set\n");
>
> /* Clear misc interrupt status */
> nwl_bridge_writel(pcie, misc_stat, MSGF_MISC_STATUS);
This patch looks fine, but looking at the code as a whole, I have a
question. You basically have this:
misc_stat = nwl_bridge_readl(pcie, MSGF_MISC_STATUS) & MSGF_MISC_SR_MASKALL;
if (!misc_stat)
return IRQ_NONE;
...
nwl_bridge_writel(pcie, misc_stat, MSGF_MISC_STATUS);
The masking with MSGF_MISC_SR_MASKALL seems wrong. Let's say
MSGF_MISC_STATUS had some other bit set, e.g., BIT(31), indicating
some yet-unsupported interrupt cause. BIT(31) is not in
MSGF_MISC_SR_MASKALL, so we return IRQ_NONE without clearing the
interrupt bit in MSGF_MISC_STATUS. Won't that cause an interrupt
storm where the interrupt is continually re-asserted because we never
clear it?
It seems like it would make more sense to do this:
misc_stat = nwl_bridge_readl(pcie, MSGF_MISC_STATUS);
if (!misc_stat)
return IRQ_NONE;
...
if (misc_stat != (misc_stat & MSGF_MISC_SR_MASKALL))
dev_err(dev, "unexpected IRQ, MSGF_MISC_STATUS %#010x\n", misc_stat);
nwl_bridge_writel(pcie, misc_stat, MSGF_MISC_STATUS);
^ permalink raw reply
* [PATCH net-next 1/2] net: mvneta: add xmit_more support
From: Eric Dumazet @ 2016-09-13 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473750006-21199-2-git-send-email-mw@semihalf.com>
On Tue, 2016-09-13 at 09:00 +0200, Marcin Wojtas wrote:
> From: Simon Guinot <simon.guinot@sequanux.org>
>
> Basing on xmit_more flag of the skb, TX descriptors can be concatenated
> before flushing. This commit delay Tx descriptor flush if the queue is
> running and if there is more skb's to send.
>
> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> ---
> drivers/net/ethernet/marvell/mvneta.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index d41c28d..b9dccea 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -512,6 +512,7 @@ struct mvneta_tx_queue {
> * descriptor ring
> */
> int count;
> + int pending;
> int tx_stop_threshold;
> int tx_wake_threshold;
>
> @@ -802,8 +803,9 @@ static void mvneta_txq_pend_desc_add(struct mvneta_port *pp,
> /* Only 255 descriptors can be added at once ; Assume caller
> * process TX desriptors in quanta less than 256
> */
Hi Marcin
Well, given the above comment, and fact that MVNETA_MAX_TXD == 532, it
looks like you might add a bug if more than 256 skb are given to your
ndo_start_xmit() with skb->xmit_more = 1
I therefore suggest you make sure it does not happen.
txq->pending += frags;
if (!skb->xmit_more ||
txq->pending > 256 - MVNETA_MAX_SKB_DESCS ||
netif_xmit_stopped(nq))
mvneta_txq_pend_desc_add(pp, txq)
^ permalink raw reply
* [PATCH v5 06/14] drivers: acpi: implement acpi_dma_configure
From: Robin Murphy @ 2016-09-13 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909142343.13314-7-lorenzo.pieralisi@arm.com>
On 09/09/16 15:23, Lorenzo Pieralisi wrote:
> On DT based systems, the of_dma_configure() API implements DMA
> configuration for a given device. On ACPI systems an API equivalent to
> of_dma_configure() is missing which implies that it is currently not
> possible to set-up DMA operations for devices through the ACPI generic
> kernel layer.
>
> This patch fills the gap by introducing acpi_dma_configure/deconfigure()
> calls that for now are just wrappers around arch_setup_dma_ops() and
> arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
> the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
>
> The DMA range size passed to arch_setup_dma_ops() is sized according
> to the device coherent_dma_mask (starting at address 0x0), mirroring the
> DT probing path behaviour when a dma-ranges property is not provided
> for the device being probed; this changes the current arch_setup_dma_ops()
> call parameters in the ACPI probing case, but since arch_setup_dma_ops()
> is a NOP on all architectures but ARM/ARM64 this patch does not change
> the current kernel behaviour on them.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com> [pci]
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> ---
> drivers/acpi/glue.c | 4 ++--
> drivers/acpi/scan.c | 24 ++++++++++++++++++++++++
> drivers/pci/probe.c | 3 +--
> include/acpi/acpi_bus.h | 2 ++
> include/linux/acpi.h | 5 +++++
> 5 files changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index 5ea5dc2..f8d6564 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -227,8 +227,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>
> attr = acpi_get_dma_attr(acpi_dev);
> if (attr != DEV_DMA_NOT_SUPPORTED)
> - arch_setup_dma_ops(dev, 0, 0, NULL,
> - attr == DEV_DMA_COHERENT);
> + acpi_dma_configure(dev, attr);
>
> acpi_physnode_link_name(physical_node_name, node_id);
> retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj,
> @@ -251,6 +250,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
> return 0;
>
> err:
> + acpi_dma_deconfigure(dev);
> ACPI_COMPANION_SET(dev, NULL);
> put_device(dev);
> put_device(&acpi_dev->dev);
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index e878fc7..9614232 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1370,6 +1370,30 @@ enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> return DEV_DMA_NON_COHERENT;
> }
>
> +/**
> + * acpi_dma_configure - Set-up DMA configuration for the device.
> + * @dev: The pointer to the device
> + * @attr: device dma attributes
> + */
> +void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
> +{
> + /*
> + * Assume dma valid range starts at 0 and covers the whole
> + * coherent_dma_mask.
> + */
> + arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, NULL,
> + attr == DEV_DMA_COHERENT);
This looks a bit hairy - if we're setting up the DMA configuration at
this point can we really always rely on the device already having a
valid DMA mask? I think it would make sense to at least check, and apply
the standard default 32-bit mask if not.
> +}
> +
> +/**
> + * acpi_dma_deconfigure - Tear-down DMA configuration for the device.
> + * @dev: The pointer to the device
> + */
> +void acpi_dma_deconfigure(struct device *dev)
> +{
> + arch_teardown_dma_ops(dev);
> +}
As touched upon in the dwc-usb3 thread, is it worth exporting these for
the benefit of modular bus/glue code, to match of_dma_configure()?
> +
> static void acpi_init_coherency(struct acpi_device *adev)
> {
> unsigned long long cca = 0;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 93f280d..e96d482 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1734,8 +1734,7 @@ static void pci_dma_configure(struct pci_dev *dev)
> if (attr == DEV_DMA_NOT_SUPPORTED)
> dev_warn(&dev->dev, "DMA not supported.\n");
> else
> - arch_setup_dma_ops(&dev->dev, 0, 0, NULL,
> - attr == DEV_DMA_COHERENT);
> + acpi_dma_configure(&dev->dev, attr);
> }
What about non-PCI stuff? I see there's at least an
acpi_create_platform_device() which I'd also kind of expect to see as a
caller (which indeed might also tie in with the aforementioned default
mask initialisation).
Robin.
>
> pci_put_host_bridge_device(bridge);
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index c1a524d..4242c31 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -573,6 +573,8 @@ struct acpi_pci_root {
>
> bool acpi_dma_supported(struct acpi_device *adev);
> enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev);
> +void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
> +void acpi_dma_deconfigure(struct device *dev);
>
> struct acpi_device *acpi_find_child_device(struct acpi_device *parent,
> u64 address, bool check_children);
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index c5eaf2f..05d4e48 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -729,6 +729,11 @@ static inline enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> return DEV_DMA_NOT_SUPPORTED;
> }
>
> +static inline void acpi_dma_configure(struct device *dev,
> + enum dev_dma_attr attr) { }
> +
> +static inline void acpi_dma_deconfigure(struct device *dev) { }
> +
> #define ACPI_PTR(_ptr) (NULL)
>
> static inline void acpi_device_set_enumerated(struct acpi_device *adev)
>
^ permalink raw reply
* [PATCH net-next 1/2] net: mvneta: add xmit_more support
From: Eric Dumazet @ 2016-09-13 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473777182.18970.118.camel@edumazet-glaptop3.roam.corp.google.com>
On Tue, 2016-09-13 at 07:33 -0700, Eric Dumazet wrote:
> Hi Marcin
>
> Well, given the above comment, and fact that MVNETA_MAX_TXD == 532, it
> looks like you might add a bug if more than 256 skb are given to your
> ndo_start_xmit() with skb->xmit_more = 1
>
> I therefore suggest you make sure it does not happen.
>
> txq->pending += frags;
> if (!skb->xmit_more ||
> txq->pending > 256 - MVNETA_MAX_SKB_DESCS ||
> netif_xmit_stopped(nq))
> mvneta_txq_pend_desc_add(pp, txq)
>
Another solution would be to test the potential overflow in mvneta_tx()
and force a mvneta_txq_pend_desc_add(pp, txq) _before_ adding the desc
of the "about to be cooked" TSO packet.
(This is because MVNETA_MAX_SKB_DESCS is 217, so 255-217 leaves few room
for xmit_more to show its power)
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD and Regulator due for the v4.9 merge window
From: Chen-Yu Tsai @ 2016-09-13 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913133127.GC31719@dell>
Hi Lee,
On Tue, Sep 13, 2016 at 9:31 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Mark,
>
> Try this instead.
>
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>
> Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-regulator-v4.9
>
> for you to fetch changes up to 8824ee8573483e1c91691b5be3d3730e75551dce:
>
> mfd: axp20x: Add support for AXP806 PMIC (2016-09-13 14:10:04 +0100)
>
> ----------------------------------------------------------------
> Immutable branch between MFD and Regualtor due for the v4.9 merge window
>
> ----------------------------------------------------------------
> Chen-Yu Tsai (3):
> regulator: axp20x: Support AXP806 variant
> mfd: axp20x: Add bindings for AXP806 PMIC
> mfd: axp20x: Add support for AXP806 PMIC
The mfd driver patch should come before the regulator patch for bisectability.
I'm guessing Mark is fine with you taking it through your tree though.
Thanks!
ChenYu
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 28 +++++-
> drivers/mfd/axp20x-rsb.c | 1 +
> drivers/mfd/axp20x.c | 72 ++++++++++++++
> drivers/regulator/axp20x-regulator.c | 118 +++++++++++++++++++++--
> include/linux/mfd/axp20x.h | 60 ++++++++++++
> 5 files changed, 270 insertions(+), 9 deletions(-)
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Mark Rutland @ 2016-09-13 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D80B91.4020306@laposte.net>
Hi,
On Tue, Sep 13, 2016 at 04:22:09PM +0200, Sebastian Frias wrote:
> On 09/13/2016 03:12 PM, Mark Rutland wrote:
[context was deleted, TL;DR: binding review is necessary, and takes
effort, regardless of presence/absence of a driver]
> >> Only for bindings for which there is a driver.
> >
> > This is not true for all but the most trivial of hardware, as I stated
> > previously.
> >
> > Go and take a look at all the effort that went into sorting out generic
> > IOMMU bindings, when driver support was written after a large amount of
> > review to sort out fundamental concepts. We had to sort out fundamentals
> > before prototype driver code could be written, and while we knew drivers
> > were coming, an awful lot of review effort came first.
>
> Again, you are talking about drivers, but it is not the case at hand.
No, I am not. Please do not presume to put words in my mouth.
I explicitly described a case where binding review took effort, and the
presence or absence of drivers was irrelevant. We later had drivers,
yes, but we had to understand the hardware to get the binding right
first.
If there's data which has no consumer, it has no value being in the DT.
Placing data with no consumer in the DT comes with a number of issues,
e.g.
a) Some DTS authors will ignore it, and not place data according to it
in DTs. Hence there's no gain in consistency.
b) Though some accident (perhaps a typo, perhaps a misunderstanding of
the binding), a DT will come to have erroneous data, yet this will go
unnoticed, as there is no consumer. When later a consumer appears, it
can't trust existing DTs, and has to either ignore the binding
entirely, or bodge around each and every broken DT.
c) When a consumer eventually appears, it turned out we didn't capture
details of the hardware sufficiently, and the binding turns out to be
useless. At worst, this boils down to (b), at best, we require
additional properties. In this case absolutely nothing is gained.
In all cases, all we end up doing is enlarging DTBs, and risk causing
even more work.
If there *is* going to be a consumer, and if information regarding that
will be provided, then matters are different, and we can consider a
binding on its own merit. We need a specific example for that.
> If the "user of the binding" is not Linux, under what circumstances
> could "Linux" have the legitimacy of guaranteeing or enforcing any Linux-
> specific commitment?
To at least the extent that if someone says they're not going to bother,
we clearly have no reason to bother supporting them.
Note that *nothing* stops you from using the DT container format for
your own purposes, in violation of every binding and rule we have.
However, for those cases we clearly won't document them as the standard
mechanism.
There are other things build atop of the DTB format, e.g. FIT, which
aren't quite devicetree in the usual sense.
> > I understand that goal, and I've asked for a specific example, as this
> > is not clear-cut. e.g. there has been work on describing secure devices
> > for QEMU, but this isn't necessarily something we want to expose Linux
> > to in general.
>
> Interesting, do you know where in QEMU's code should I look for that?
Documentation/devicetree/bindings/arm/secure.txt for the basics.
Generally, I'd expect that even if the secure OS were using DT in this
fashion, the non-secure general purpose OS would be handed a DT
containing only the non-secure world portions.
> > While a lot of that effort is taken by code, care must also be taken wit
> > the bindings themselves, and those considerations apply.
>
> IMHO, they apply only when there's a Linux driver, or any other public
> user of such bindings. But if there's no user, it seems like an unnecessary
> constraint.
If there's no user, there's no need for the binding.
If there's some user somewhere, and that user wants the binding
rubber-stamped as an "official" binding, they need to follow the usual
rules for bindings.
If there is a user, and they don't want to follow the usual rules,
there's no point trying to get the binding rubber-stamped.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7
From: Srinivas Ramana @ 2016-09-13 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7608c508-0537-267c-0cdf-6995445b811e@arm.com>
On 09/12/2016 11:21 PM, Robin Murphy wrote:
> On 12/09/16 07:57, Srinivas Ramana wrote:
>> If the bootloader uses the long descriptor format and jumps to
>> kernel decompressor code, TTBCR may not be in a right state.
>> Before enabling the MMU, it is required to clear the TTBCR.PD0
>> field to use TTBR0 for translation table walks.
>>
>> The 'commit dbece45894d3a ("ARM: 7501/1: decompressor:
>> reset ttbcr for VMSA ARMv7 cores")' does the reset of TTBCR.N, but
>> doesn't consider all the bits for the size of TTBCR.N.
>>
>> Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to
>> indicate the use of TTBR0 and the correct base address width.
>>
>> Signed-off-by: Srinivas Ramana <sramana@codeaurora.org>
>> ---
>> arch/arm/boot/compressed/head.S | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> index af11c2f8f3b7..fc6d541549a2 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -779,7 +779,7 @@ __armv7_mmu_cache_on:
>> orrne r0, r0, #1 @ MMU enabled
>> movne r1, #0xfffffffd @ domain 0 = client
>> bic r6, r6, #1 << 31 @ 32-bit translation system
>
> Hmm, if TTBCR.EAE _was_ actually set...
>
>> - bic r6, r6, #3 << 0 @ use only ttbr0
>> + bic r6, r6, #(7 << 0) | (1 << 4) @ use only ttbr0
>> mcrne p15, 0, r3, c2, c0, 0 @ load page table pointer
>> mcrne p15, 0, r1, c3, c0, 0 @ load domain access control
>> mcrne p15, 0, r6, c2, c0, 2 @ load ttb control
>
> ...then strictly the TLBIALL needs to happen after the ISB following
> this update. Otherwise per B3.10.2 of DDI406C.c I think we might be into
> unpredictable territory - i.e. if the TLB happens to treat long- and
> short-descriptor entries differently then the TLBI beforehand (with EAE
> set) may be at liberty to only discard long-descriptor entries and leave
> bogus short-descriptor entries sitting around.
Yes, it seems this has to be taken care of, along with resetting
TTBCR.PD0 and TTBCR.N. Do you say that this needs to be done in the same
patch or a different one?
>
> In other words, something like (completely untested):
>
> ---8<---
> diff --git a/arch/arm/boot/compressed/head.S
> b/arch/arm/boot/compressed/head.S
> index af11c2f8f3b7..536b7781024a 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -764,7 +764,6 @@ __armv7_mmu_cache_on:
> mov r0, #0
> mcr p15, 0, r0, c7, c10, 4 @ drain write buffer
> tst r11, #0xf @ VMSA
> - mcrne p15, 0, r0, c8, c7, 0 @ flush I,D TLBs
Shouldn't this be still there for the same reason you explained above? I
mean to discard the long descriptor entries when EAE was 1 (before we
reset it).
> #endif
> mrc p15, 0, r0, c1, c0, 0 @ read control reg
> bic r0, r0, #1 << 28 @ clear SCTLR.TRE
> @@ -783,8 +782,11 @@ __armv7_mmu_cache_on:
> mcrne p15, 0, r3, c2, c0, 0 @ load page table pointer
> mcrne p15, 0, r1, c3, c0, 0 @ load domain access control
> mcrne p15, 0, r6, c2, c0, 2 @ load ttb control
> -#endif
> mcr p15, 0, r0, c7, c5, 4 @ ISB
> + mcrne p15, 0, r0, c8, c7, 0 @ flush I,D TLBs
> +#else
> + mcr p15, 0, r0, c7, c5, 4 @ ISB
> +#endif
> mcr p15, 0, r0, c1, c0, 0 @ load control register
> mrc p15, 0, r0, c1, c0, 0 @ and read it back
> ---8<---
>
> Robin.
>
i have tested this change (flush I, D, TLBs after TTB control is
written) and don't see any issue. But on my setup decompression is
successful even without this (probably not hitting the case in discussion).
Thanks,
-- Srinivas R
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative
Project.
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Sebastian Frias @ 2016-09-13 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913131208.GA23336@leverpostej>
Hi Mark,
On 09/13/2016 03:12 PM, Mark Rutland wrote:
>> Exactly, that is why I was thinking it would take less "review" time.
>> Indeed, if there is no driver, why would it matter what those bindings
>> are?
>
> If you believe that the bindings don't matter, then there is absolutely
> no reason for them to exist in the first place.
>
> If those binding matter to *anyone*, then those collating the bindings
> have some responsibility of stewardship, and that includes
> review/maintenance/etc.
The thing is that right now it seems the "responsibility of stewardship"
lies only within "Linux", whereas DT is proposed as open for everybody,
Bootloaders, FreeBSD, etc.
In that case, shouldn't the "responsibility" be shared?
Alternatively, maybe 'borders' could be created, in order to enable the
allocation of responsibility of different sections to different parties,
right?
Obviously, moving properties/nodes from one 'section' to another crossing
responsibility 'borders' would require agreements.
Shouldn't that be something good to think about?
Best regards,
Sebastian
^ 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;
as well as URLs for NNTP newsgroup(s).