* [PATCH v2 01/13] soc: samsung: pmu: Provide global function to get PMU regmap
From: Tomasz Figa @ 2017-01-18 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657084-26227-2-git-send-email-m.szyprowski@samsung.com>
Hi Marek,
2017-01-17 21:44 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
> PMU is something like a SoC wide service, so add a helper function to get
> PMU regmap. This will be used by other Exynos device drivers. This way it
> can be avoided to model this dependency in device tree (as phandles to PMU
> node) for almost every device in the SoC.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/soc/samsung/exynos-pmu.c | 11 +++++++++++
> include/linux/soc/samsung/exynos-pmu.h | 7 +++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
> index 0acdfd82e751..5c269bf23210 100644
> --- a/drivers/soc/samsung/exynos-pmu.c
> +++ b/drivers/soc/samsung/exynos-pmu.c
> @@ -11,6 +11,7 @@
>
> #include <linux/of.h>
> #include <linux/of_address.h>
> +#include <linux/mfd/syscon.h>
> #include <linux/platform_device.h>
> #include <linux/delay.h>
>
> @@ -92,6 +93,16 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
> { /*sentinel*/ },
> };
>
> +struct regmap *exynos_get_pmu_regmap(void)
> +{
> + struct device_node *np = of_find_matching_node(NULL,
> + exynos_pmu_of_device_ids);
> + if (np)
> + return syscon_node_to_regmap(np);
> + return ERR_PTR(-ENODEV);
> +}
> +EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap);
> +
> static int exynos_pmu_probe(struct platform_device *pdev)
> {
> const struct of_device_id *match;
> diff --git a/include/linux/soc/samsung/exynos-pmu.h b/include/linux/soc/samsung/exynos-pmu.h
> index e2e9de1acc5b..2a841a474684 100644
> --- a/include/linux/soc/samsung/exynos-pmu.h
> +++ b/include/linux/soc/samsung/exynos-pmu.h
> @@ -12,6 +12,8 @@
> #ifndef __LINUX_SOC_EXYNOS_PMU_H
> #define __LINUX_SOC_EXYNOS_PMU_H
>
> +#include <linux/regmap.h>
> +
nit: It would save some compilation time to just add a forward
declaration of struct regmap here instead, in case of files that
include this header, but don't need regmap functionality.
> enum sys_powerdown {
> SYS_AFTR,
> SYS_LPA,
> @@ -20,5 +22,10 @@ enum sys_powerdown {
> };
>
> extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
> +#ifdef CONFIG_EXYNOS_PMU
> +extern struct regmap *exynos_get_pmu_regmap(void);
> +#else
> +static inline struct regmap *exynos_get_pmu_regmap(void) { return NULL; }
Shouldn't be some ERR_PTR() instead?
Best regards,
Tomasz
^ permalink raw reply
* [PATCH v8 12/18] irqdomain: Add irq domain MSI and MSI_REMAP flags
From: Tomasz Nowicki @ 2017-01-18 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484127714-3263-13-git-send-email-eric.auger@redhat.com>
On 11.01.2017 10:41, Eric Auger wrote:
> We introduce two new enum values for the irq domain flag:
> - IRQ_DOMAIN_FLAG_MSI indicates the irq domain corresponds to
> an MSI domain
> - IRQ_DOMAIN_FLAG_MSI_REMAP indicates the irq domain has MSI
> remapping capabilities.
>
> Those values will be useful to check all MSI irq domains have
> MSI remapping support when assessing the safety of IRQ assignment
> to a guest.
>
> irq_domain_hierarchical_is_msi_remap() allows to check if an
> irq domain or any parent implements MSI remapping.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Tomasz Nowicki <tomasz.nowicki@caviumnetworks.com>
Thanks,
Tomasz
>
> ---
>
> v7 -> v8:
> - remove h variable in irq_domain_hierarchical_is_msi_remap
> - add Marc's R-b
>
> v6:
> - add IRQ_DOMAIN_FLAG_MSI as suggested by Marc
> - add irq_domain_is_msi, irq_domain_is_msi_remap and
> irq_domain_hierarchical_is_msi_remap
> ---
> include/linux/irqdomain.h | 35 +++++++++++++++++++++++++++++++++++
> kernel/irq/irqdomain.c | 14 ++++++++++++++
> 2 files changed, 49 insertions(+)
>
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index ffb8460..bc2f571 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -183,6 +183,12 @@ enum {
> /* Irq domain is an IPI domain with single virq */
> IRQ_DOMAIN_FLAG_IPI_SINGLE = (1 << 3),
>
> + /* Irq domain implements MSIs */
> + IRQ_DOMAIN_FLAG_MSI = (1 << 4),
> +
> + /* Irq domain implements MSI remapping */
> + IRQ_DOMAIN_FLAG_MSI_REMAP = (1 << 5),
> +
> /*
> * Flags starting from IRQ_DOMAIN_FLAG_NONCORE are reserved
> * for implementation specific purposes and ignored by the
> @@ -446,6 +452,19 @@ static inline bool irq_domain_is_ipi_single(struct irq_domain *domain)
> {
> return domain->flags & IRQ_DOMAIN_FLAG_IPI_SINGLE;
> }
> +
> +static inline bool irq_domain_is_msi(struct irq_domain *domain)
> +{
> + return domain->flags & IRQ_DOMAIN_FLAG_MSI;
> +}
> +
> +static inline bool irq_domain_is_msi_remap(struct irq_domain *domain)
> +{
> + return domain->flags & IRQ_DOMAIN_FLAG_MSI_REMAP;
> +}
> +
> +extern bool irq_domain_hierarchical_is_msi_remap(struct irq_domain *domain);
> +
> #else /* CONFIG_IRQ_DOMAIN_HIERARCHY */
> static inline void irq_domain_activate_irq(struct irq_data *data) { }
> static inline void irq_domain_deactivate_irq(struct irq_data *data) { }
> @@ -477,6 +496,22 @@ static inline bool irq_domain_is_ipi_single(struct irq_domain *domain)
> {
> return false;
> }
> +
> +static inline bool irq_domain_is_msi(struct irq_domain *domain)
> +{
> + return false;
> +}
> +
> +static inline bool irq_domain_is_msi_remap(struct irq_domain *domain)
> +{
> + return false;
> +}
> +
> +static inline bool
> +irq_domain_hierarchical_is_msi_remap(struct irq_domain *domain)
> +{
> + return false;
> +}
> #endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */
>
> #else /* CONFIG_IRQ_DOMAIN */
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 8c0a0ae..876e131 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -1392,6 +1392,20 @@ static void irq_domain_check_hierarchy(struct irq_domain *domain)
> if (domain->ops->alloc)
> domain->flags |= IRQ_DOMAIN_FLAG_HIERARCHY;
> }
> +
> +/**
> + * irq_domain_hierarchical_is_msi_remap - Check if the domain or any
> + * parent has MSI remapping support
> + * @domain: domain pointer
> + */
> +bool irq_domain_hierarchical_is_msi_remap(struct irq_domain *domain)
> +{
> + for (; domain; domain = domain->parent) {
> + if (irq_domain_is_msi_remap(domain))
> + return true;
> + }
> + return false;
> +}
> #else /* CONFIG_IRQ_DOMAIN_HIERARCHY */
> /**
> * irq_domain_get_irq_data - Get irq_data associated with @virq and @domain
>
^ permalink raw reply
* [PATCH v2 10/13] pinctrl: samsung: Add infrastructure for pin-bank retention control
From: Tomasz Figa @ 2017-01-18 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657084-26227-11-git-send-email-m.szyprowski@samsung.com>
Hi Marek,
2017-01-17 21:44 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
> Pad retention control after suspend/resume cycle should be done from pin
> controller driver instead of PMU (power management unit) driver to avoid
> possible ordering and logical dependencies. Till now it worked fine only
> because PMU driver registered its sys_ops after pin controller.
>
> This patch adds infrastructure to handle pad retention during pin control
> driver resume.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> drivers/pinctrl/samsung/pinctrl-samsung.c | 12 +++++++++
> drivers/pinctrl/samsung/pinctrl-samsung.h | 42 +++++++++++++++++++++++++++++++
> 2 files changed, 54 insertions(+)
>
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> index 59f99ea7e65b..021abd7221f8 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> @@ -1060,6 +1060,13 @@ static int samsung_pinctrl_probe(struct platform_device *pdev)
> if (res)
> drvdata->irq = res->start;
>
> + if (ctrl->retention_data) {
> + drvdata->retention_ctrl = ctrl->retention_data->init(drvdata,
> + ctrl->retention_data);
> + if (IS_ERR(drvdata->retention_ctrl))
> + return PTR_ERR(drvdata->retention_ctrl);
> + }
> +
> ret = samsung_gpiolib_register(pdev, drvdata);
> if (ret)
> return ret;
> @@ -1126,6 +1133,8 @@ static void samsung_pinctrl_suspend_dev(
>
> if (drvdata->suspend)
> drvdata->suspend(drvdata);
> + if (drvdata->retention_ctrl && drvdata->retention_ctrl->enable)
> + drvdata->retention_ctrl->enable(drvdata);
Do we need to check presence of ->enable? I think it doesn't make much
sense to provide retention_ctrl with NULL enable or disable.
> }
>
> /**
> @@ -1173,6 +1182,9 @@ static void samsung_pinctrl_resume_dev(struct samsung_pinctrl_drv_data *drvdata)
> if (widths[type])
> writel(bank->pm_save[type], reg + offs[type]);
> }
> +
> + if (drvdata->retention_ctrl && drvdata->retention_ctrl->disable)
> + drvdata->retention_ctrl->disable(drvdata);
Ditto.
> }
>
> /**
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
> index 6f7ce7539a00..5ebbf4137a06 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.h
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
> @@ -185,10 +185,48 @@ struct samsung_pin_bank {
> };
>
> /**
> + * struct samsung_retention_data: runtime pin-bank retention control data.
> + * @regs: array of PMU registers to control pad retention.
> + * @nr_regs: number of registers in @regs array.
> + * @value: value to store to registers to turn off retention.
> + * @refcnt: atomic counter if retention control affects more than one bank.
> + * @priv: retention control code private data
> + * @on: platform specific callback to enter retention mode.
> + * @off: platform specific callback to exit retention mode.
s/on/enable/ and s/off/disable/ in comments too. Thanks for taking my
bikeshedding into account, though. :)
> + **/
> +struct samsung_retention_ctrl {
> + const u32 *regs;
> + int nr_regs;
> + u32 value;
> + atomic_t *refcnt;
> + void *priv;
> + void (*enable)(struct samsung_pinctrl_drv_data *);
> + void (*disable)(struct samsung_pinctrl_drv_data *);
^^
Best regards,
Tomasz
^ permalink raw reply
* [PATCH v8 13/18] genirq/msi: Set IRQ_DOMAIN_FLAG_MSI on MSI domain creation
From: Tomasz Nowicki @ 2017-01-18 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484127714-3263-14-git-send-email-eric.auger@redhat.com>
On 11.01.2017 10:41, Eric Auger wrote:
> Now we have a flag value indicating an IRQ domain implements MSI,
> let's set it on msi_create_irq_domain().
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Tomasz Nowicki <tomasz.nowicki@caviumnetworks.com>
Thanks,
Tomasz
>
> ---
>
> v7 -> v8
> - Added Marc's R-b
>
> v6: new
> ---
> kernel/irq/msi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
> index ee23006..ddc2f54 100644
> --- a/kernel/irq/msi.c
> +++ b/kernel/irq/msi.c
> @@ -270,8 +270,8 @@ struct irq_domain *msi_create_irq_domain(struct fwnode_handle *fwnode,
> if (info->flags & MSI_FLAG_USE_DEF_CHIP_OPS)
> msi_domain_update_chip_ops(info);
>
> - return irq_domain_create_hierarchy(parent, 0, 0, fwnode,
> - &msi_domain_ops, info);
> + return irq_domain_create_hierarchy(parent, IRQ_DOMAIN_FLAG_MSI, 0,
> + fwnode, &msi_domain_ops, info);
> }
>
> int msi_domain_prepare_irqs(struct irq_domain *domain, struct device *dev,
>
^ permalink raw reply
* [PATCH v8 14/18] irqdomain: irq_domain_check_msi_remap
From: Tomasz Nowicki @ 2017-01-18 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5eb6945b-9d4c-9521-1d5d-10eba633fd59@caviumnetworks.com>
On 17.01.2017 15:06, Tomasz Nowicki wrote:
> On 17.01.2017 14:53, Auger Eric wrote:
>> Hi Tomasz,
>>
>> On 17/01/2017 14:40, Tomasz Nowicki wrote:
>>> On 11.01.2017 10:41, Eric Auger wrote:
>>>> This new function checks whether all MSI irq domains
>>>> implement IRQ remapping. This is useful to understand
>>>> whether VFIO passthrough is safe with respect to interrupts.
>>>>
>>>> On ARM typically an MSI controller can sit downstream
>>>> to the IOMMU without preventing VFIO passthrough.
>>>> As such any assigned device can write into the MSI doorbell.
>>>> In case the MSI controller implements IRQ remapping, assigned
>>>> devices will not be able to trigger interrupts towards the
>>>> host. On the contrary, the assignment must be emphasized as
>>>> unsafe with respect to interrupts.
>>>>
>>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>>> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>
>>>> ---
>>>> v7 -> v8:
>>>> - remove goto in irq_domain_check_msi_remap
>>>> - Added Marc's R-b
>>>>
>>>> v5 -> v6:
>>>> - use irq_domain_hierarchical_is_msi_remap()
>>>> - comment rewording
>>>>
>>>> v4 -> v5:
>>>> - Handle DOMAIN_BUS_FSL_MC_MSI domains
>>>> - Check parents
>>>> ---
>>>> include/linux/irqdomain.h | 1 +
>>>> kernel/irq/irqdomain.c | 22 ++++++++++++++++++++++
>>>> 2 files changed, 23 insertions(+)
>>>>
>>>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>>>> index bc2f571..188eced 100644
>>>> --- a/include/linux/irqdomain.h
>>>> +++ b/include/linux/irqdomain.h
>>>> @@ -222,6 +222,7 @@ struct irq_domain *irq_domain_add_legacy(struct
>>>> device_node *of_node,
>>>> void *host_data);
>>>> extern struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec
>>>> *fwspec,
>>>> enum irq_domain_bus_token bus_token);
>>>> +extern bool irq_domain_check_msi_remap(void);
>>>> extern void irq_set_default_host(struct irq_domain *host);
>>>> extern int irq_domain_alloc_descs(int virq, unsigned int nr_irqs,
>>>> irq_hw_number_t hwirq, int node,
>>>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>>>> index 876e131..d889751 100644
>>>> --- a/kernel/irq/irqdomain.c
>>>> +++ b/kernel/irq/irqdomain.c
>>>> @@ -278,6 +278,28 @@ struct irq_domain
>>>> *irq_find_matching_fwspec(struct irq_fwspec *fwspec,
>>>> EXPORT_SYMBOL_GPL(irq_find_matching_fwspec);
>>>>
>>>> /**
>>>> + * irq_domain_check_msi_remap - Check whether all MSI
>>>> + * irq domains implement IRQ remapping
>>>> + */
>>>> +bool irq_domain_check_msi_remap(void)
>>>> +{
>>>> + struct irq_domain *h;
>>>> + bool ret = true;
>>>> +
>>>> + mutex_lock(&irq_domain_mutex);
>>>> + list_for_each_entry(h, &irq_domain_list, link) {
>>>> + if (irq_domain_is_msi(h) &&
>>>> + !irq_domain_hierarchical_is_msi_remap(h)) {
>>>> + ret = false;
>>>> + break;
>>>> + }
>>>> + }
>>>> + mutex_unlock(&irq_domain_mutex);
>>>> + return ret;
>>>> +}
>>>
>>> Above function returns true, even though there is no MSI irq domains. Is
>>> it intentional ?
>> From the VFIO integration point of view this is what we want. If there
>> is no MSI controller in the system, we have no vulnerability with
>> respect to IRQ assignment and we consider the system as safe. If
>> requested I can add a comment?
>>
>
> I see. Yes, a comment would be helpful then :) Thanks!
>
Anyway:
Reviewed-by: Tomasz Nowicki <tomasz.nowicki@caviumnetworks.com>
Thanks,
Tomasz
^ permalink raw reply
* [PATCH v2 00/13] Move pad retention control to Exynos pin controller driver
From: Tomasz Figa @ 2017-01-18 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657084-26227-1-git-send-email-m.szyprowski@samsung.com>
Hi Marek,
2017-01-17 21:44 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
> Changelog:
>
> v2:
> - reworked exynos_get_pmu_regmap() function and moved to Exynos PMU driver,
> now it doesn't depend on driver probe order thus doesn't need to defer probing
> of pinctrl driver if PMU has not yet been probed
> - collected Acks, minor fixes according to review comments
After fixing remaining nits in patch 1 and 10, for all pinctrl patches (4-13):
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
and for other patches (1-3):
Reviewed-by: Tomasz Figa <tomasz.figa@gmail.com>
Best regards,
Tomasz
^ permalink raw reply
* [PATCH RFC 0/5] mvebu cleanups and preparation for Armada 7k/8k
From: Linus Walleij @ 2017-01-18 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113112829.GP14217@n2100.armlinux.org.uk>
On Fri, Jan 13, 2017 at 12:28 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Fri, Jan 13, 2017 at 11:02:40AM +0000, Russell King - ARM Linux wrote:
>> (Resend including linux-arm-kernel)
>
> BTW, would be useful if MAINTAINERS could list maintainers for both
> this code and the mvebu gpio code too. At the moment, it seems Linus
> is the person responsible for both of those - but I suspect the mvebu
> people want to be copied on patches...
Agreed. Since they are silent I will likely simply apply the patches,
they certainly look good to me.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 1/5] pinctrl: mvebu: constify mvebu_mpp_ctrl structures
From: Linus Walleij @ 2017-01-18 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cRzdb-0002YP-8q@rmk-PC.armlinux.org.uk>
On Fri, Jan 13, 2017 at 12:03 PM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> As the mvebu_mpp_ctrl structures contain function pointers, it is
> preferable for these to be made read-only to prevent the function
> pointers being modified. So make these const.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 2/5] pinctrl: mvebu: provide per-control private data
From: Linus Walleij @ 2017-01-18 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cRzdg-0002YX-D7@rmk-PC.armlinux.org.uk>
On Fri, Jan 13, 2017 at 12:03 PM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> Provide per-control private data into each mvebu pinctrl method, which
> will allow us to provide some completely generic helpers without the
> global variable and per-instance function definitions that would be
> required when we have multiple pin controllers on a SoC.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 4/5] pinctrl: mvebu: switch drivers to generic simple mmio
From: Linus Walleij @ 2017-01-18 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cRzdq-0002Yl-Lv@rmk-PC.armlinux.org.uk>
On Fri, Jan 13, 2017 at 12:03 PM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> Move the mvebu pinctrl drivers over to the generic simple mmio
> implementation, saving a substantial number of lines of code in
> the process.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Very nice patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 5/5] pinctrl: mvebu: add simple regmap based pinctrl implementation
From: Linus Walleij @ 2017-01-18 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cRzdv-0002Ys-Pe@rmk-PC.armlinux.org.uk>
On Fri, Jan 13, 2017 at 12:03 PM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> Add a simple regmap based pinctrl implementation for mvebu, for syscon
> based regmap drivers.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 06/14] ARM: davinci: da850: model the SATA refclk
From: Sekhar Nori @ 2017-01-18 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484655976-25382-7-git-send-email-bgolaszewski@baylibre.com>
On Tuesday 17 January 2017 05:56 PM, Bartosz Golaszewski wrote:
> Register a dummy clock modelling the external SATA oscillator for
I would not call it a dummy clock. Its representing something physically
present. Just call it "fixed rate clock" ?
> da850 DT mode. For non-DT boot we don't register the clock - instead
> we rely on the default MPY value defined in the da850 ahci driver (as
> is done currently).
Here too, like David suggested, it will be nice to register it both for
DT and non-DT case. With that I think your driver will be simple too
since you dont have to worry about the case when refclkpn is not supplied.
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/mach-davinci/da8xx-dt.c | 8 ++++++++
> arch/arm/mach-davinci/devices-da8xx.c | 23 +++++++++++++++++++++++
> arch/arm/mach-davinci/include/mach/da8xx.h | 1 +
> 3 files changed, 32 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index b83e5d1..13137cb 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -61,6 +61,14 @@ static void __init da850_init_machine(void)
> pr_warn("%s: registering USB 1.1 PHY clock failed: %d",
> __func__, ret);
>
> + if (of_machine_is_compatible("ti,da850-evm") ||
> + of_machine_is_compatible("ti,da850-lcdk")) {
> + ret = da850_register_sata_refclk(100000000);
> + if (ret)
> + pr_warn("%s: registering SATA_REFCLK clock failed: %d",
> + __func__, ret);
> + }
Since all supported boards use 100 Mhz refclk anyway, I would drop the
machine check and just do:
/* All existing boards use 100MHz SATA refclkpn */
unsigned long sata_refclkpn = 100 * 1000 * 1000;
ret = da850_register_sata_refclk(sata_refclkpn);
It should then be easy for the odd board (when it comes) to set
sata_refclkpn to a different value.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 01/14] devicetree: bindings: add bindings for ahci-da850
From: Sekhar Nori @ 2017-01-18 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e3c8946-2a19-3e11-c071-b3737554005c@lechnology.com>
On Wednesday 18 January 2017 12:05 AM, David Lechner wrote:
> On 01/17/2017 06:26 AM, Bartosz Golaszewski wrote:
>> Add DT bindings for the TI DA850 AHCI SATA controller.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> Documentation/devicetree/bindings/ata/ahci-da850.txt | 18
>> ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
>>
>> diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt
>> b/Documentation/devicetree/bindings/ata/ahci-da850.txt
>> new file mode 100644
>> index 0000000..e7111b4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt
>> @@ -0,0 +1,18 @@
>> +Device tree binding for the TI DA850 AHCI SATA Controller
>> +---------------------------------------------------------
>> +
>> +Required properties:
>> + - compatible: must be "ti,da850-ahci"
>> + - reg: physical base addresses and sizes of the controller's
>> register areas
>> + - interrupts: interrupt specifier (refer to the interrupt binding)
>> +
>> +Optional properties:
>> + - clocks: clock specifier (refer to the common clock binding)
>
> Won't you also need a clock-names property since there are two clocks?
>
>> +
>> +Example:
>> +
>> + sata: ahci at 218000 {
>> + compatible = "ti,da850-ahci";
>> + reg = <0x218000 0x2000>, <0x22c018 0x4>;
>> + interrupts = <67>;
>> + };
>>
>
> It would be nice to have clocks and clock-names in the example as well.
Well, we don't use the common clock binding today. Is it really
necessary to add them now. Thats basically going to remain completely
untested.
I would drop the mention of clocks specification as an optional property
too.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v7 3/8] PWM: add pwm-stm32 DT bindings
From: Thierry Reding @ 2017-01-18 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483608344-9012-4-git-send-email-benjamin.gaignard@st.com>
On Thu, Jan 05, 2017 at 10:25:39AM +0100, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 6:
> - change st,breakinput parameter format to make it usuable on stm32f7 too.
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> new file mode 100644
> index 0000000..866f222
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> @@ -0,0 +1,33 @@
> +STMicroelectronics STM32 Timers PWM bindings
> +
> +Must be a sub-node of an STM32 Timers device tree node.
> +See ../mfd/stm32-timers.txt for details about the parent node.
> +
> +Required parameters:
> +- compatible: Must be "st,stm32-pwm".
> +- pinctrl-names: Set to "default".
> +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
> + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
> +
> +Optional parameters:
> +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
> + "index" indicates on which break input the configuration should be applied.
It might be useful to specify what the valid values are for the break
input index.
Also, u32 is kind of a Linuxism, perhaps "Arrays of three cells"? Also,
does this mean there can be multiple entries? Such as 6 cells for two
configurations? What's the maximum number of such configurations?
If it's possible to specify multiple configurations, maybe a slightly
clearer wording would be: "One or more <index level filter> triplets to
describe..."
> + "level" gives the active level (0=low or 1=high) for this configuration.
So how does this work exactly? "level" specifies the output level if the
filter value is matched?
> + "filter" gives the filtering value to be applied.
Is this a single value at which "level" will be applied? Or is it an
upper/lower bound that can be used to restrict the output to "level" if
the signal goes beyond/below a certain threshold?
Maybe an example would clarify this. Or perhaps a reference to a manual
where a more in-depth description of this functionality can be found.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170118/45afc3e2/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: DT: STiH407: Add RTS / CTS pinctrl definition for UARTs.
From: Lee Jones @ 2017-01-18 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484671615-16343-1-git-send-email-peter.griffin@linaro.org>
Couple of nits and a question.
On Tue, 17 Jan 2017, Peter Griffin wrote:
> The uart IP is capable of doing hardware flow control. Define
UART
> the RTS and CTS pins for STiH407 family Socs so we can use this
SoCs
> feature in the future if we wish to.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
> arch/arm/boot/dts/stih407-pinctrl.dtsi | 50 ++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index daab16b..3bbb0c0 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -149,6 +149,16 @@
> rx = <&pio3 5 ALT1 IN>;
> };
> };
> + pinctrl_sbc_serial0_rts: sbc_serial0-0_rts {
> + st,pins {
> + rts = <&pio3 7 ALT1 OUT>;
> + };
> + };
> + pinctrl_sbc_serial0_cts: sbc_serial0-0_cts {
> + st,pins {
> + cts = <&pio3 6 ALT1 IN>;
> + };
> + };
Basic premise looks good, but why have you separated the lines?
I believe they are used together when HW flow-control is enabled.
> };
> /* SBC_ASC1 - UART11 */
> sbc_serial1 {
> @@ -158,6 +168,16 @@
> rx = <&pio2 7 ALT3 IN>;
> };
> };
> + pinctrl_sbc_serial1_rts: sbc_serial1-0_rts {
> + st,pins {
> + rts = <&pio3 1 ALT3 OUT>;
> + };
> + };
> + pinctrl_sbc_serial1_cts: sbc_serial1-0_cts {
> + st,pins {
> + cts = <&pio3 0 ALT3 IN>;
> + };
> + };
> };
>
> i2c10 {
> @@ -469,6 +489,16 @@
> rx = <&pio17 1 ALT1 IN>;
> };
> };
> + pinctrl_serial0_rts: serial0-0_rts {
> + st,pins {
> + rts = <&pio17 3 ALT1 OUT>;
> + };
> + };
> + pinctrl_serial0_cts: serial0-0_cts {
> + st,pins {
> + cts = <&pio17 2 ALT1 IN>;
> + };
> + };
> };
>
> serial1 {
> @@ -478,6 +508,16 @@
> rx = <&pio16 1 ALT1 IN>;
> };
> };
> + pinctrl_serial1_rts: serial1-0_rts {
> + st,pins {
> + rts = <&pio16 3 ALT1 OUT>;
> + };
> + };
> + pinctrl_serial1_cts: serial1-0_cts {
> + st,pins {
> + cts = <&pio16 2 ALT1 IN>;
> + };
> + };
> };
>
> serial2 {
> @@ -487,6 +527,16 @@
> rx = <&pio15 1 ALT1 IN>;
> };
> };
> + pinctrl_serial2_rts: serial2-0_rts {
> + st,pins {
> + rts = <&pio15 3 ALT1 OUT>;
> + };
> + };
> + pinctrl_serial2_cts: serial2-0_cts {
> + st,pins {
> + cts = <&pio15 2 ALT1 IN>;
> + };
> + };
> };
>
> mmc1 {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 2/3] spi: pxa2xx: Prepare for edge-triggered interrupts
From: Jan Kiszka @ 2017-01-18 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r340eq28.fsf@belgarion.home>
On 2017-01-18 09:21, Robert Jarzmik wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
>
>> On 2017-01-17 08:54, Robert Jarzmik wrote:
>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>
>>>> When using the a device with edge-triggered interrupts, such as MSIs,
>>>> the interrupt handler has to ensure that there is a point in time during
>>>> its execution where all interrupts sources are silent so that a new
>>>> event can trigger a new interrupt again.
>>>>
>>>> This is achieved here by looping over SSSR evaluation. We need to take
>>>> into account that SSCR1 may be changed by the transfer handler, thus we
>>>> need to redo the mask calculation, at least regarding the volatile
>>>> interrupt enable bit (TIE).
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> Hi Jan,
>>>
>>>> + while (1) {
>>> This bit worries me a bit, as this can be either :
>>> - hogging the SoC's CPU, endlessly running
>>> - or even worse, blocking the CPU for ever
>>>
>>> The question behind is, should this be done in a top-half, or moved to a irq
>>> thread ?
>>
>> Every device with a broken interrupt source can hog CPUs, nothing
>> special with this one. If you don't close the loop in the handler
>> itself, you close it over the hardware retriggering the interrupt over
>> and over again.
> I'm not speaking of a broken interrupt source, I'm speaking of a broken code,
> such as in the handler, or broken status readback, or lack of understanding on
> the status register which may imply the while(1) to loop forever.
>
>> So, I don't see a point in offloading to a thread. The normal case is
>> some TX done (FIFO available) event followed by an RX event, then the
>> transfer is complete, isn't it?
> The point is if you stay forever in the while(1) loop, you can at least have a
> print a backtrace (LOCKUP_DETECTOR).
I won't consider "debugability" as a good reason to move interrupt
handlers into threads. There should be real workload that requires
offloading or specific prioritization.
>
>>> Imagine that on first iteration the handler returns IRQ_NONE, and on second
>>> IRQ_HANDLED. This makes ret IRQ_HANDLED. Yet after the first iteration the
>>> handler should have exited, especially if the interrupt is shared with another
>>> driver.
>>
>> That would be a bug in transfer_handler, because we don't enter it
>> without a reason (status != 0).
> Sure, but can you be sure that all the people modifying the code after you will
> see that also ? The other way will _force_ them to see it.
>
>>> Another thing which is along what Andy already said : it would be better
>>> practice to have this loop in the form :
>>> do {
>>> ...
>>> } while (exit_condition_not_met);
>>
>> This implies code duplication in order to calculate the condition
>> (mask...). I can do this if desired, I wouldn't do this to my own code,
>> though.
> Okay, that's acceptable.
> Why not have something like this :
>
> sccr1_reg = pxa2xx_spi_read(drv_data, SSCR1);
> if (!(sccr1_reg & SSCR1_TIE))
> mask &= ~SSSR_TFS;
>
> /* Ignore RX timeout interrupt if it is disabled */
> if (!(sccr1_reg & SSCR1_TINTE))
> mask &= ~SSSR_TINT;
>
> status = pxa2xx_spi_read(drv_data, SSR);
> while (status & mask) {
> ... handlers etc ...
> status = pxa2xx_spi_read(drv_data, SSR);
> };
>
> There is a duplication of the status read, but that looks acceptable, and the
> mask calculation is moved out of the loop (this should be checked more
> thoroughly as it looked to me only probe() would change these values, yet I
> might be wrong).
Unfortunately, mask can change if SSCR1_TIE is cleared. So this is not
correct.
What would be an alternative to looping is masking (would be required
for threaded irq anyway - but then we won't need to loop in the first
place): disable all irq sources, check the status bits once, re-enable
according to a potentially updated set, leave the handler and let the
hardware call us again.
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* [PATCH 2/3] Documentation: devicetree: amlogic: Add R-Box Pro
From: Neil Armstrong @ 2017-01-18 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117225459.4438-2-afaerber@suse.de>
On 01/17/2017 11:54 PM, Andreas F?rber wrote:
> Cc: ada at kingnoval.com
> Signed-off-by: Andreas F?rber <afaerber@suse.de>
> ---
> Originally I thought we would group by SoC (6, 8, 8b, gxbb, gxl, gmx, etc.)
> but this got out of order with nexbox,a95x - so inserting kingnovel between
> amlogic and nexbox here. If that's what we want going forward, we should move
> the old entries to make the scheme clearer. The alternative would be to
> reorder alphabetically within each SoC group, but nexbox,a95x with two SoCs
> makes it difficult to categorize, we could choose gxbb as the earlier one.
Andreas,
Feel free to provide a fixup.
Neil
>
> Documentation/devicetree/bindings/arm/amlogic.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> index 9b2b41ab6817..fb0ee7d9a921 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> @@ -45,5 +45,6 @@ Board compatible values:
> - "amlogic,p231" (Meson gxl s905d)
> - "amlogic,q200" (Meson gxm s912)
> - "amlogic,q201" (Meson gxm s912)
> + - "kingnovel,r-box-pro" (Meson gxm S912)
> - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
> - "nexbox,a1" (Meson gxm s912)
>
^ permalink raw reply
* [PATCH] [media] s5p-mfc: Align stream buffer and CPB buffer to 512
From: Smitha T Murthy @ 2017-01-18 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20170118094212epcas5p22e588016d2b330dcd0b99b6e1012c744@epcas5p2.samsung.com>
>From MFCv6 onwards encoder stream buffer and decoder CPB buffer
need to be aligned with 512.
Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 9 +++++++++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h | 3 +++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index d6f207e..57da798 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -408,8 +408,15 @@ static int s5p_mfc_set_dec_stream_buffer_v6(struct s5p_mfc_ctx *ctx,
struct s5p_mfc_dev *dev = ctx->dev;
const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
struct s5p_mfc_buf_size *buf_size = dev->variant->buf_size;
+ size_t cpb_buf_size;
mfc_debug_enter();
+ cpb_buf_size = ALIGN(buf_size->cpb, CPB_ALIGN);
+ if (strm_size >= set_strm_size_max(cpb_buf_size)) {
+ mfc_debug(2, "Decrease strm_size : %u -> %zu, gap : %d\n",
+ strm_size, set_strm_size_max(cpb_buf_size), CPB_ALIGN);
+ strm_size = set_strm_size_max(cpb_buf_size);
+ }
mfc_debug(2, "inst_no: %d, buf_addr: 0x%08x,\n"
"buf_size: 0x%08x (%d)\n",
ctx->inst_no, buf_addr, strm_size, strm_size);
@@ -519,6 +526,8 @@ static int s5p_mfc_set_enc_stream_buffer_v6(struct s5p_mfc_ctx *ctx,
struct s5p_mfc_dev *dev = ctx->dev;
const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
+ size = ALIGN(size, 512);
+
writel(addr, mfc_regs->e_stream_buffer_addr); /* 16B align */
writel(size, mfc_regs->e_stream_buffer_size);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
index 8055848..16a7b1d 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
@@ -40,6 +40,9 @@
#define FRAME_DELTA_H264_H263 1
#define TIGHT_CBR_MAX 10
+#define CPB_ALIGN 512
+#define set_strm_size_max(cpb_max) ((cpb_max) - CPB_ALIGN)
+
struct s5p_mfc_hw_ops *s5p_mfc_init_hw_ops_v6(void);
const struct s5p_mfc_regs *s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev *dev);
#endif /* S5P_MFC_OPR_V6_H_ */
--
1.7.2.3
^ permalink raw reply related
* [PATCH v2 12/14] ARM: dts: da850: add pinmux settings for the SATA controller
From: Sekhar Nori @ 2017-01-18 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484655976-25382-13-git-send-email-bgolaszewski@baylibre.com>
Hi Bartosz,
On Tuesday 17 January 2017 05:56 PM, Bartosz Golaszewski wrote:
> Add pinmux sub-nodes for all muxed SATA pins.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Since these are all unused at this time, we should drop adding them
until a time someone really needs these.
Thanks,
Sekhar
^ permalink raw reply
* [RESEND PATCH 0/2] Add i2c DT binding and device node for Mediatek MT2701 Soc
From: Jun Gao @ 2017-01-18 9:40 UTC (permalink / raw)
To: linux-arm-kernel
This patch series based on v4.10-rc2, include MT2701 i2c DT binding and device node.
Dependent on "Add clock and power domain DT nodes for Mediatek MT2701"[1].
[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-December/007637.html
Jun Gao (2):
Documentation: devicetree: Add i2c binding for mediatek MT2701 Soc
Platform
arm: dts: mt2701: Add i2c device node
.../devicetree/bindings/i2c/i2c-mt6577.txt | 11 ++---
arch/arm/boot/dts/mt2701-evb.dts | 44 ++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 42 +++++++++++++++++++
3 files changed, 92 insertions(+), 5 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [RESEND PATCH 1/2] Documentation: devicetree: Add i2c binding for mediatek MT2701 Soc Platform
From: Jun Gao @ 2017-01-18 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484732461-13594-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
This add i2c DT binding to i2c-mt6577.txt for MT2701.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
.../devicetree/bindings/i2c/i2c-mt6577.txt | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
index 0ce6fa3..ef22ecf 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
@@ -4,11 +4,12 @@ The Mediatek's I2C controller is used to interface with I2C devices.
Required properties:
- compatible: value should be either of the following.
- (a) "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
- (b) "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
- (c) "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
- (d) "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
- (e) "mediatek,mt8173-i2c", for i2c compatible with mt8173 i2c.
+ "mediatek,mt2701-i2c", for i2c compatible with mt2701 i2c.
+ "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
+ "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
+ "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
+ "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
+ "mediatek,mt8173-i2c", for i2c compatible with mt8173 i2c.
- reg: physical base address of the controller and dma base, length of memory
mapped region.
- interrupts: interrupt number to the cpu.
--
1.7.9.5
^ permalink raw reply related
* [RESEND PATCH 2/2] arm: dts: mt2701: Add i2c device node
From: Jun Gao @ 2017-01-18 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484732461-13594-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
Add i2c device node for MT2701.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
arch/arm/boot/dts/mt2701-evb.dts | 44 ++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 42 ++++++++++++++++++++++++++++++++++++
2 files changed, 86 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index 082ca88..a908e94 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -24,6 +24,50 @@
};
};
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+};
+
+&pio {
+ i2c0_pins_a: i2c0 at 0 {
+ pins1 {
+ pinmux = <MT2701_PIN_75_SDA0__FUNC_SDA0>,
+ <MT2701_PIN_76_SCL0__FUNC_SCL0>;
+ bias-disable;
+ };
+ };
+
+ i2c1_pins_a: i2c1 at 0 {
+ pins1 {
+ pinmux = <MT2701_PIN_57_SDA1__FUNC_SDA1>,
+ <MT2701_PIN_58_SCL1__FUNC_SCL1>;
+ bias-disable;
+ };
+ };
+
+ i2c2_pins_a: i2c2 at 0 {
+ pins1 {
+ pinmux = <MT2701_PIN_77_SDA2__FUNC_SDA2>,
+ <MT2701_PIN_78_SCL2__FUNC_SCL2>;
+ bias-disable;
+ };
+ };
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index bdf8954..0d1539f 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -227,6 +227,48 @@
status = "disabled";
};
+ i2c0: i2c at 11007000 {
+ compatible = "mediatek,mt2701-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11007000 0 0x70>,
+ <0 0x11000200 0 0x80>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_LOW>;
+ clock-div = <16>;
+ clocks = <&pericfg CLK_PERI_I2C0>, <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 11008000 {
+ compatible = "mediatek,mt2701-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11008000 0 0x70>,
+ <0 0x11000280 0 0x80>;
+ interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_LOW>;
+ clock-div = <16>;
+ clocks = <&pericfg CLK_PERI_I2C1>, <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c at 11009000 {
+ compatible = "mediatek,mt2701-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11009000 0 0x70>,
+ <0 0x11000300 0 0x80>;
+ interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_LOW>;
+ clock-div = <16>;
+ clocks = <&pericfg CLK_PERI_I2C2>, <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
mmsys: syscon at 14000000 {
compatible = "mediatek,mt2701-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v7 3/8] PWM: add pwm-stm32 DT bindings
From: Benjamin Gaignard @ 2017-01-18 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118092021.GE18989@ulmo.ba.sec>
2017-01-18 10:20 GMT+01:00 Thierry Reding <thierry.reding@gmail.com>:
> On Thu, Jan 05, 2017 at 10:25:39AM +0100, Benjamin Gaignard wrote:
>> Define bindings for pwm-stm32
>>
>> version 6:
>> - change st,breakinput parameter format to make it usuable on stm32f7 too.
>>
>> version 2:
>> - use parameters instead of compatible of handle the hardware configuration
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> new file mode 100644
>> index 0000000..866f222
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> @@ -0,0 +1,33 @@
>> +STMicroelectronics STM32 Timers PWM bindings
>> +
>> +Must be a sub-node of an STM32 Timers device tree node.
>> +See ../mfd/stm32-timers.txt for details about the parent node.
>> +
>> +Required parameters:
>> +- compatible: Must be "st,stm32-pwm".
>> +- pinctrl-names: Set to "default".
>> +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
>> + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
>> +
>> +Optional parameters:
>> +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
>> + "index" indicates on which break input the configuration should be applied.
>
> It might be useful to specify what the valid values are for the break
> input index.
It could 0 and 1, I will add this information.
>
> Also, u32 is kind of a Linuxism, perhaps "Arrays of three cells"? Also,
> does this mean there can be multiple entries? Such as 6 cells for two
> configurations? What's the maximum number of such configurations?
>
> If it's possible to specify multiple configurations, maybe a slightly
> clearer wording would be: "One or more <index level filter> triplets to
> describe..."
>
You can have one configuration per index so I will rephrase it like that:
One or two <index level filter> to describe break input configurations.
"index" indicates on which break input (0 or 1 ) the configuration
should be applied.
>> + "level" gives the active level (0=low or 1=high) for this configuration.
>
> So how does this work exactly? "level" specifies the output level if the
> filter value is matched?
No it specify on which input level the break event is generated
>
>> + "filter" gives the filtering value to be applied.
>
> Is this a single value at which "level" will be applied? Or is it an
> upper/lower bound that can be used to restrict the output to "level" if
> the signal goes beyond/below a certain threshold?
Very very basically filter is more a debounce value set on the signal
to avoid glitches.
The goal of break input feature is to stop PWM generation in hardware
errors failure case.
For a more completed description you can read "using break input
function" (starting page 645) in this doc:
http://www.st.com/content/ccc/resource/technical/document/reference_manual/c5/cf/ef/52/c0/f1/4b/fa/DM00124865.pdf/files/DM00124865.pdf/jcr:content/translations/en.DM00124865.pdf
>
> Maybe an example would clarify this. Or perhaps a reference to a manual
> where a more in-depth description of this functionality can be found.
>
> Thierry
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC
From: Andre Przywara @ 2017-01-18 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116163124.c5gusyd3j3goivnf@lukather>
Hi,
On 16/01/17 16:31, Maxime Ripard wrote:
> On Mon, Jan 09, 2017 at 12:16:00AM +0000, Andr? Przywara wrote:
>> On 05/01/17 22:42, Maxime Ripard wrote:
>>> On Fri, Dec 30, 2016 at 01:55:44PM +0100, Linus Walleij wrote:
>>>> On Mon, Dec 26, 2016 at 3:33 PM, Andr? Przywara <andre.przywara@arm.com> wrote:
>>>>
>>>>> So while this patch technically looks correct, I was wondering if we
>>>>> should really explore the possibility of making the whole of sunxi
>>>>> pinctrl DT controlled.
>>>>> I brought this up a while ago, but people weren't overly enthusiastic
>>>>> about it, though their argument weren't really convincing to me[1].
>>>>>
>>>>> So:
>>>>> As this "driver" here is basically a table linking GPIO bit settings
>>>>> (the actual mux value) to names and every pin we care about needs to be
>>>>> enumerated in the DT anyway, why not just add something like:
>>>>> allwinner,pinmux = <4>;
>>>>> to each pin(group) in the DT and get rid of this "driver" file here
>>>>> entirely?
>>>>
>>>> I'm open to that if you can use pinctrl-single which is in the kernel
>>>> for this purpose only, and is used with both OMAPs and HiSilicon.
>>>
>>> I'm not open to that, and I'm getting tired of discussing it over and
>>> over again. Andre, if you want to be convinced again, please read the
>>> last discussion we had on this topic.
>>
>> As I said: It didn't convince me back then. And frankly we didn't really
>> discuss it back then, I just refrained from entering a discussion
>> against _two_ maintainers at this time, since my capacity on this kind
>> of email threads is really very limited - especially for something that
>> is a hobby to me.
>
> This is also (mostly) a hobby to me, which is exactly why I prefer to
> work on something actually useful, rather than just discussing this
> over and over again. Just like I don't want (myself, or anyone,
> really, since we're all in the same boat) to have to maintain two
> separate pinctrl drivers.
>
> We're having a documented, simple, pinctrl binding, using the generic
> bindings now (that almost everyone else is using now, or is very close
> to), and we can leverage as much documentation and code from that. Why
> would we want to create and maintain a new driver with a new binding,
> that will need to be documented again, learned by everyone, and will
> lead only to confusion across the people who just want to have their
> board supported?
I agree, and thus was proposing a _slightly changed_ pinctrl driver
which actually *reduces* the maintenance burden in the kernel.
In the moment we need to add _both_ a pinctrl .dtsi node _and_ a kernel
"driver" file, which is really boilerplate code plus a table.
Also we need to make sure that both these files match.
If a new SoC is really 99% similar to an existing one, atm we still need
explicit kernel support if only one pin is changed (see the H5).
So my idea was to basically add the mux value as a DT property, thus
making the kernel pinctrl-sun[x]i-a[yz].c files obsolete and greatly
_reduce_ the maintenance burden. Ideally there wouldn't be any pinctrl
code changes in the kernel for future SoCs anymore - at least if
Allwinner sticks with their current pace of releasing copy&pasted SoC
designs. Changes beyond that would require a driver change anyway, even
with the current model.
I gave Linus' proposal to use the pinctrl-single binding a quick look
and don't think it's a match for Allwinner SoC. So my idea was to
basically just add a new compatible and the muxsel property to the
existing driver and binding. It would basically look the same, apart
from one or two additions (to cover interrupts, for instance).
Any future SoCs could then just use that compatible and would describe
the SoC details in the DT, like it's meant to be and like we do already,
but extended by putting the mux value in there as well.
So the only kernel contribution would then be the DT, really, which
technically could be delivered on some device storage as well, but
that's a different discussion ...
> And imagine the kind of mess we would be in if everyone getting a bit
> involved in the support of one platform at one point wanted to trash
> one big part of its infrastructure and start all over again because he
> likes it better this way.
Like I said above, I didn't mean to trash the current pinctrl binding,
just make it a bit more generic and simplify future kernel support.
> I'm sorry, but this is also our jobs as maintainers to prevent all
> these kind of issues, and to maintain consistency. Switching to one
> binding to another breaks that consistency on many level,
Yet we did it for the clocks. The very same argumentation that you gave
above applies there as well (two different bindings, two sets of drivers
in the kernel, new learnings for people, etc.)
One difference would be that the new pinctrl binding wouldn't be
fundamentally different to the old one, up to the point where the old
driver could possibly use the very same DT nodes (but that would need to
be worked out).
Cheers,
Andre.
> both in
> pinctrl and in the platform support itself. So sorry, but that's not
> going to happen.
>
> Maxime
>
^ permalink raw reply
* [PATCH] arm: Use generic irq_migrate_all_off_this_cpu() for CPU hotplug
From: Alexander Sverdlin @ 2017-01-18 9:45 UTC (permalink / raw)
To: linux-arm-kernel
I have found that .irq_bus_lock/.irq_bus_sync_unlock of irqchip are not
honored during CPU hotplug migration and the reason for this is open-coded
IRQ affinity re-configuration in the existing ARM migrate_irqs()
implementation. Fortunately, this was already fixed for ARM64 in 217d453d
("arm64: fix a migrating irq bug when hotplug cpu").
So, just switch to the same generic code for ARM.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Aaron Tomlin <atomlin@redhat.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Andiii <andi.shyti@samsung.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/irq.h | 1 -
arch/arm/kernel/irq.c | 61 ----------------------------------------------
arch/arm/kernel/smp.c | 2 +-
4 files changed, 2 insertions(+), 63 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 186c4c214e0a..43080f4bbe4d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1463,6 +1463,7 @@ config NR_CPUS
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
+ select GENERIC_IRQ_MIGRATION
help
Say Y here to experiment with turning CPUs off and on. CPUs
can be controlled through /sys/devices/system/cpu.
diff --git a/arch/arm/include/asm/irq.h b/arch/arm/include/asm/irq.h
index e53638c8ed8a..61e1d089ce1a 100644
--- a/arch/arm/include/asm/irq.h
+++ b/arch/arm/include/asm/irq.h
@@ -24,7 +24,6 @@
#ifndef __ASSEMBLY__
struct irqaction;
struct pt_regs;
-extern void migrate_irqs(void);
extern void asm_do_IRQ(unsigned int, struct pt_regs *);
void handle_IRQ(unsigned int, struct pt_regs *);
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index ece04a457486..a7e047127c05 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -119,64 +119,3 @@ int __init arch_probe_nr_irqs(void)
return nr_irqs;
}
#endif
-
-#ifdef CONFIG_HOTPLUG_CPU
-static bool migrate_one_irq(struct irq_desc *desc)
-{
- struct irq_data *d = irq_desc_get_irq_data(desc);
- const struct cpumask *affinity = irq_data_get_affinity_mask(d);
- struct irq_chip *c;
- bool ret = false;
-
- /*
- * If this is a per-CPU interrupt, or the affinity does not
- * include this CPU, then we have nothing to do.
- */
- if (irqd_is_per_cpu(d) || !cpumask_test_cpu(smp_processor_id(), affinity))
- return false;
-
- if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
- affinity = cpu_online_mask;
- ret = true;
- }
-
- c = irq_data_get_irq_chip(d);
- if (!c->irq_set_affinity)
- pr_debug("IRQ%u: unable to set affinity\n", d->irq);
- else if (c->irq_set_affinity(d, affinity, false) == IRQ_SET_MASK_OK && ret)
- cpumask_copy(irq_data_get_affinity_mask(d), affinity);
-
- return ret;
-}
-
-/*
- * The current CPU has been marked offline. Migrate IRQs off this CPU.
- * If the affinity settings do not allow other CPUs, force them onto any
- * available CPU.
- *
- * Note: we must iterate over all IRQs, whether they have an attached
- * action structure or not, as we need to get chained interrupts too.
- */
-void migrate_irqs(void)
-{
- unsigned int i;
- struct irq_desc *desc;
- unsigned long flags;
-
- local_irq_save(flags);
-
- for_each_irq_desc(i, desc) {
- bool affinity_broken;
-
- raw_spin_lock(&desc->lock);
- affinity_broken = migrate_one_irq(desc);
- raw_spin_unlock(&desc->lock);
-
- if (affinity_broken)
- pr_warn_ratelimited("IRQ%u no longer affine to CPU%u\n",
- i, smp_processor_id());
- }
-
- local_irq_restore(flags);
-}
-#endif /* CONFIG_HOTPLUG_CPU */
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 7dd14e8395e6..d28a06fc7001 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -222,7 +222,7 @@ int __cpu_disable(void)
/*
* OK - migrate IRQs away from this CPU
*/
- migrate_irqs();
+ irq_migrate_all_off_this_cpu();
/*
* Flush user cache and TLB mappings, and then remove this CPU
--
2.11.0
^ permalink raw reply related
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