* [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface
From: Robin Murphy @ 2017-01-04 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103173456.18154-1-lorenzo.pieralisi@arm.com>
[+Yong Wu for mtk_iommu]
On 03/01/17 17:34, Lorenzo Pieralisi wrote:
> With the introduction of the new iommu_{register/get}_instance()
> interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT
> agnostic") (based on struct fwnode_handle as look-up token, so firmware
> agnostic) to register IOMMU instances with the core IOMMU layer there is
> no reason to keep the old OF based interface around any longer.
>
> Convert all the IOMMU drivers (and OF IOMMU core code) that rely on the
> of_iommu_{set/get}_ops() to the new kernel interface to register/retrieve
> IOMMU instances and remove the of_iommu_{set/get}_ops() remaining glue
> code in order to complete the interface rework.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Looking at before-and-after disassemblies, of_iommu.o is binary
identical, and exynos-iommu.o differs only in the use of dev->fwnode
rather than &dev->of_node->fwnode (and is binary identical if I hack it
back to the latter). I'm not sure why the (GCC 6.2) codegen for
mtk_iommu.o changes quite so much when merely replacing a callsite with
the contents of its static inline callee, but it does :/
Robin.
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> Exynos, msm and mtk code compile tested only owing to lack of
> test platforms, I would appreciate some help in testing this
> patch on those platforms before merging it even if it is just
> a simple interface conversion.
>
> Thanks,
> Lorenzo
>
> drivers/iommu/exynos-iommu.c | 2 +-
> drivers/iommu/msm_iommu.c | 2 +-
> drivers/iommu/mtk_iommu.c | 2 +-
> drivers/iommu/of_iommu.c | 4 ++--
> include/linux/of_iommu.h | 11 -----------
> 5 files changed, 5 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 57ba0d3..b79e4c4 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -628,7 +628,7 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
>
> pm_runtime_enable(dev);
>
> - of_iommu_set_ops(dev->of_node, &exynos_iommu_ops);
> + iommu_register_instance(dev->fwnode, &exynos_iommu_ops);
>
> return 0;
> }
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index b09692b..9cd3cee 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -737,7 +737,7 @@ static int msm_iommu_probe(struct platform_device *pdev)
> }
>
> list_add(&iommu->dev_node, &qcom_iommu_devices);
> - of_iommu_set_ops(pdev->dev.of_node, &msm_iommu_ops);
> + iommu_register_instance(pdev->dev.fwnode, &msm_iommu_ops);
>
> pr_info("device mapped at %p, irq %d with %d ctx banks\n",
> iommu->base, iommu->irq, iommu->ncb);
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 1479c76..0596ab2 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -655,7 +655,7 @@ static int mtk_iommu_init_fn(struct device_node *np)
> return ret;
> }
>
> - of_iommu_set_ops(np, &mtk_iommu_ops);
> + iommu_register_instance(&np->fwnode, &mtk_iommu_ops);
> return 0;
> }
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 0f57ddc..d7f480a 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -127,7 +127,7 @@ static const struct iommu_ops
> "iommu-map-mask", &iommu_spec.np, iommu_spec.args))
> return NULL;
>
> - ops = of_iommu_get_ops(iommu_spec.np);
> + ops = iommu_get_instance(&iommu_spec.np->fwnode);
> if (!ops || !ops->of_xlate ||
> iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
> ops->of_xlate(&pdev->dev, &iommu_spec))
> @@ -157,7 +157,7 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
> "#iommu-cells", idx,
> &iommu_spec)) {
> np = iommu_spec.np;
> - ops = of_iommu_get_ops(np);
> + ops = iommu_get_instance(&np->fwnode);
>
> if (!ops || !ops->of_xlate ||
> iommu_fwspec_init(dev, &np->fwnode, ops) ||
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index 6a7fc50..13394ac 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -31,17 +31,6 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>
> #endif /* CONFIG_OF_IOMMU */
>
> -static inline void of_iommu_set_ops(struct device_node *np,
> - const struct iommu_ops *ops)
> -{
> - iommu_register_instance(&np->fwnode, ops);
> -}
> -
> -static inline const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> -{
> - return iommu_get_instance(&np->fwnode);
> -}
> -
> extern struct of_device_id __iommu_of_table;
>
> typedef int (*of_iommu_init_fn)(struct device_node *);
>
^ permalink raw reply
* [GIT PULL] Qualcomm ARM64 Fixes for 4.10-rc1
From: Arnd Bergmann @ 2017-01-04 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482958692-18978-1-git-send-email-andy.gross@linaro.org>
On Wednesday, December 28, 2016 2:58:12 PM CET Andy Gross wrote:
> Qualcomm ARM64 Fixes for v4.10-rc1
>
> * Fix instability in MSM8996 due to incorrect carveouts
>
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Fixes for v4.10
From: Arnd Bergmann @ 2017-01-04 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481530910.git.horms+renesas@verge.net.au>
On Monday, December 12, 2016 9:30:00 AM CET Simon Horman wrote:
> This provides an sd0_uhs node rather than duplicate sdh0 nodes
> resolving an error introduced in a clean-up patch.
>
> This pull request is based on "Second Round of Renesas ARM Based SoC DT
> Updates for v4.10", tagged as renesas-arm64-dt2-for-v4.10,
> which you have already pulled. The error corrected by this change
> was introduced in that pull-request.
>
Pulled into fixes, sorry for the delay.
Arnd
^ permalink raw reply
* [PATCH v2 15/19] media: imx: Add MIPI CSI-2 Receiver subdev driver
From: Vladimir Zapolskiy @ 2017-01-04 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483477049-19056-16-git-send-email-steve_longerbeam@mentor.com>
On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
> for sensors with a MIPI CSI2 interface.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> drivers/staging/media/imx/Makefile | 1 +
> drivers/staging/media/imx/imx-mipi-csi2.c | 509 ++++++++++++++++++++++++++++++
> 2 files changed, 510 insertions(+)
> create mode 100644 drivers/staging/media/imx/imx-mipi-csi2.c
>
> diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
> index fe9e992..0decef7 100644
> --- a/drivers/staging/media/imx/Makefile
> +++ b/drivers/staging/media/imx/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-ic.o
> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-smfc.o
> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-camif.o
> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-mipi-csi2.o
> diff --git a/drivers/staging/media/imx/imx-mipi-csi2.c b/drivers/staging/media/imx/imx-mipi-csi2.c
> new file mode 100644
> index 0000000..84df16e
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-mipi-csi2.c
> @@ -0,0 +1,509 @@
> +/*
> + * MIPI CSI-2 Receiver Subdev for Freescale i.MX5/6 SOC.
> + *
> + * Copyright (c) 2012-2014 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include <linux/module.h>
> +#include <linux/export.h>
> +#include <linux/types.h>
> +#include <linux/init.h>
> +#include <linux/platform_device.h>
> +#include <linux/err.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/list.h>
> +#include <linux/irq.h>
> +#include <linux/of_device.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-of.h>
> +#include <media/v4l2-subdev.h>
> +#include <media/v4l2-async.h>
Please sort the list of headers alphabetically.
> +#include <asm/mach/irq.h>
Why do you need to include this header?
> +#include <video/imx-ipu-v3.h>
> +#include "imx-media.h"
> +
[snip]
> +static int imxcsi2_s_stream(struct v4l2_subdev *sd, int enable)
> +{
> + struct imxcsi2_dev *csi2 = sd_to_dev(sd);
> + int i, ret = 0;
> +
> + if (!csi2->src_sd)
> + return -EPIPE;
> + for (i = 0; i < CSI2_NUM_SRC_PADS; i++) {
> + if (csi2->sink_sd[i])
> + break;
> + }
> + if (i >= CSI2_NUM_SRC_PADS)
> + return -EPIPE;
> +
> + v4l2_info(sd, "stream %s\n", enable ? "ON" : "OFF");
> +
> + if (enable && !csi2->stream_on) {
> + clk_prepare_enable(csi2->pix_clk);
It can complicate the design for you, but in general clk_prepare_enable()
can return an error.
> + ret = imxcsi2_dphy_wait(csi2);
> + if (ret)
> + clk_disable_unprepare(csi2->pix_clk);
> + } else if (!enable && csi2->stream_on) {
> + clk_disable_unprepare(csi2->pix_clk);
> + }
> +
> + if (!ret)
> + csi2->stream_on = enable;
> + return ret;
> +}
> +
[snip]
> +
> +static int imxcsi2_parse_endpoints(struct imxcsi2_dev *csi2)
> +{
> + struct device_node *node = csi2->dev->of_node;
> + struct device_node *epnode;
> + struct v4l2_of_endpoint ep;
> + int ret = 0;
> +
> + epnode = of_graph_get_next_endpoint(node, NULL);
> + if (!epnode) {
> + v4l2_err(&csi2->sd, "failed to get endpoint node\n");
> + return -EINVAL;
> + }
> +
> + v4l2_of_parse_endpoint(epnode, &ep);
Do of_node_put(epnode) here and remove 'out' goto label.
> + if (ep.bus_type != V4L2_MBUS_CSI2) {
> + v4l2_err(&csi2->sd, "invalid bus type, must be MIPI CSI2\n");
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + csi2->bus = ep.bus.mipi_csi2;
> +
> + v4l2_info(&csi2->sd, "data lanes: %d\n", csi2->bus.num_data_lanes);
> + v4l2_info(&csi2->sd, "flags: 0x%08x\n", csi2->bus.flags);
> +out:
> + of_node_put(epnode);
> + return ret;
> +}
> +
[snip]
> +static const struct of_device_id imxcsi2_dt_ids[] = {
> + { .compatible = "fsl,imx-mipi-csi2", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, imxcsi2_dt_ids);
> +
> +static struct platform_driver imxcsi2_driver = {
> + .driver = {
> + .name = DEVICE_NAME,
> + .owner = THIS_MODULE,
Please drop .owner assignment.
> + .of_match_table = imxcsi2_dt_ids,
> + },
> + .probe = imxcsi2_probe,
> + .remove = imxcsi2_remove,
> +};
> +
> +module_platform_driver(imxcsi2_driver);
> +
> +MODULE_DESCRIPTION("i.MX5/6 MIPI CSI-2 Receiver driver");
> +MODULE_AUTHOR("Steve Longerbeam <steve_longerbeam@mentor.com>");
> +MODULE_LICENSE("GPL");
> +
>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v8] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Ard Biesheuvel @ 2017-01-04 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481813205-3305-1-git-send-email-ard.biesheuvel@linaro.org>
On 15 December 2016 at 14:46, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Currently, we allow kernel mode NEON in softirq or hardirq context by
> stacking and unstacking a slice of the NEON register file for each call
> to kernel_neon_begin() and kernel_neon_end(), respectively.
>
> Given that
> a) a CPU typically spends most of its time in userland, during which time
> no kernel mode NEON in process context is in progress,
> b) a CPU spends most of its time in the kernel doing other things than
> kernel mode NEON when it gets interrupted to perform kernel mode NEON
> in softirq context
>
> the stacking and subsequent unstacking is only necessary if we are
> interrupting a thread while it is performing kernel mode NEON in process
> context, which means that in all other cases, we can simply preserve the
> userland FP/SIMD state once, and only restore it upon return to userland,
> even if we are being invoked from softirq or hardirq context.
>
> However, with support being added to the arm64 kernel for Scalable Vector
> Extensions (SVE), which shares the bottom 128 bits of each FP/SIMD register,
> but could scale up to 2048 bits per register, the nested stacking and
> unstacking that occurs in interrupt context is no longer sufficient, given
> that the register contents will be truncated to 128 bits upon restore, unless
> we add support for stacking/unstacking the entire SVE state, which does not
> sound that appealing.
>
> This means that the FP/SIMD save state operation that encounters the
> userland state first *has* to be able to run to completion (since any
> interruption could truncate the contents of the registers, which would
> result in corrupted state to be restored once the interrupted context is
> allowed to resume preserving the state)
>
> Since executing all code involving the FP/SIMD state with interrupts
> disabled is undesirable, let's ban kernel mode NEON in hardirq context
> when running on SVE capable hardware. This is a small price to pay, given
> that the primary usecase of kernel mode NEON, crypto, can deal with this
> quite easily (and simply falls back to generic scalar algorithms whose
> worse performance should not matter in hardirq context anyway)
>
> With hardirq context removed from the equation, we can modify the FP/SIMD
> state manipulation code to execute with softirqs disabled. This allows the
> critical sections to complete without the risk of having the register
> contents getting corrupted half way through.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> v8:
> - disallow kernel mode NEON in hardirq context only on SVE capable hardware,
> otherwise we can allow it as long we ensure that interruptions of
> fpsimd_save_state() don't modify the FP/SIMD state as it is being preserved
>
> Existing code will need to be updated to take may_use_simd() into account:
> https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/log/?h=arm64-sve-crypto
>
> v7:
> - ban kernel mode NEON in hardirq context, and execute all FP/SIMD state
> manipulations with softirqs disabled
>
> v6:
> - use a spinlock instead of disabling interrupts
>
> v5:
> - perform the test-and-set and the fpsimd_save_state with interrupts disabled,
> to prevent nested kernel_neon_begin()/_end() pairs to clobber the state
> while it is being preserved
>
> v4:
> - use this_cpu_inc/dec, which give sufficient guarantees regarding
> concurrency, but do not imply SMP barriers, which are not needed here
>
> v3:
> - avoid corruption by concurrent invocations of kernel_neon_begin()/_end()
>
> v2:
> - BUG() on unexpected values of the nesting level
> - relax the BUG() on num_regs>32 to a WARN, given that nothing actually
> breaks in that case
>
> arch/arm64/include/asm/Kbuild | 1 -
> arch/arm64/include/asm/simd.h | 24 ++++++
> arch/arm64/kernel/fpsimd.c | 82 +++++++++++++++-----
> 3 files changed, 86 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
> index 44e1d7f10add..39ca0409e157 100644
> --- a/arch/arm64/include/asm/Kbuild
> +++ b/arch/arm64/include/asm/Kbuild
> @@ -33,7 +33,6 @@ generic-y += segment.h
> generic-y += sembuf.h
> generic-y += serial.h
> generic-y += shmbuf.h
> -generic-y += simd.h
> generic-y += sizes.h
> generic-y += socket.h
> generic-y += sockios.h
> diff --git a/arch/arm64/include/asm/simd.h b/arch/arm64/include/asm/simd.h
> new file mode 100644
> index 000000000000..40a6a177faf2
> --- /dev/null
> +++ b/arch/arm64/include/asm/simd.h
> @@ -0,0 +1,24 @@
> +
> +#include <linux/hardirq.h>
> +#include <asm/hwcap.h>
> +
> +/*
> + * may_use_simd - whether it is allowable at this time to issue SIMD
> + * instructions or access the SIMD register file
> + *
> + * On arm64, we allow kernel mode NEON in hardirq context but only when
> + * support for SVE is disabled, or when running on non-SVE capable hardware.
> + */
> +static __must_check inline bool may_use_simd(void)
> +{
> + if (!IS_ENABLED(CONFIG_ARM64_SVE))
> + return true;
> +
> + return !(elf_hwcap & HWCAP_SVE) || !in_irq();
> +}
> +
After having given this some more thought, it has become clear to me
that we should leave the simd.h header alone: it is used by generic
async crypto wrappers to decide when to process requests immediately
or to defer them to a cryptd kernel thread. The fact that we *can* use
the NEON in interrupt context does not mean we should do so in cases
where the API client is perfectly capable of dealing with deferred
processing by async ciphers.
Instead, I propose we add something like 'bool
kernel_neon_allowed(void)' to indicate whether the current context
supports kernel mode NEON. On non-SVE kernels, it could simply return
a compile-time 'true' value, so that fallback code to handle crypto
invocations in hardirq context are optimized away completely. On SVE
enabled kernels, it would return true except when running in hardirq
context on a SVE capable system.
I will wait for the discussion to resume before respinning this yet
again, especially given the RFC nature of the SVE patches, and the
fact that this is only a small piece of the puzzle.
--
Ard.
> +/*
> + * In some cases, it is useful to know at compile time if may_use_simd()
> + * could ever return false.
> + */
> +#define need_nonsimd_fallback() (IS_ENABLED(CONFIG_ARM64_SVE))
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 394c61db5566..94bd9f611a72 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -127,6 +127,8 @@ void do_fpsimd_exc(unsigned int esr, struct pt_regs *regs)
>
> void fpsimd_thread_switch(struct task_struct *next)
> {
> + BUG_ON(!irqs_disabled());
> +
> /*
> * Save the current FPSIMD state to memory, but only if whatever is in
> * the registers is in fact the most recent userland FPSIMD state of
> @@ -169,8 +171,10 @@ void fpsimd_flush_thread(void)
> void fpsimd_preserve_current_state(void)
> {
> preempt_disable();
> + local_bh_disable();
> if (!test_thread_flag(TIF_FOREIGN_FPSTATE))
> fpsimd_save_state(¤t->thread.fpsimd_state);
> + local_bh_enable();
> preempt_enable();
> }
>
> @@ -182,6 +186,7 @@ void fpsimd_preserve_current_state(void)
> void fpsimd_restore_current_state(void)
> {
> preempt_disable();
> + local_bh_disable();
> if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> struct fpsimd_state *st = ¤t->thread.fpsimd_state;
>
> @@ -189,6 +194,7 @@ void fpsimd_restore_current_state(void)
> this_cpu_write(fpsimd_last_state, st);
> st->cpu = smp_processor_id();
> }
> + local_bh_enable();
> preempt_enable();
> }
>
> @@ -200,6 +206,7 @@ void fpsimd_restore_current_state(void)
> void fpsimd_update_current_state(struct fpsimd_state *state)
> {
> preempt_disable();
> + local_bh_disable();
> fpsimd_load_state(state);
> if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> struct fpsimd_state *st = ¤t->thread.fpsimd_state;
> @@ -207,6 +214,7 @@ void fpsimd_update_current_state(struct fpsimd_state *state)
> this_cpu_write(fpsimd_last_state, st);
> st->cpu = smp_processor_id();
> }
> + local_bh_enable();
> preempt_enable();
> }
>
> @@ -220,45 +228,75 @@ void fpsimd_flush_task_state(struct task_struct *t)
>
> #ifdef CONFIG_KERNEL_MODE_NEON
>
> -static DEFINE_PER_CPU(struct fpsimd_partial_state, hardirq_fpsimdstate);
> -static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
> +static DEFINE_PER_CPU(struct fpsimd_partial_state, nested_fpsimdstate[2]);
> +static DEFINE_PER_CPU(int, kernel_neon_nesting_level);
>
> /*
> * Kernel-side NEON support functions
> */
> void kernel_neon_begin_partial(u32 num_regs)
> {
> - if (in_interrupt()) {
> - struct fpsimd_partial_state *s = this_cpu_ptr(
> - in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> + struct fpsimd_partial_state *s;
> + int level;
>
> - BUG_ON(num_regs > 32);
> - fpsimd_save_partial_state(s, roundup(num_regs, 2));
> - } else {
> + /*
> + * On SVE capable hardware, we don't allow kernel mode NEON in hard IRQ
> + * context. This is necessary because allowing that would force us to
> + * either preserve/restore the entire SVE state (which could be huge) in
> + * fpsimd_[save|load]_partial_state(), or perform all manipulations
> + * involving the preserved FP/SIMD state with interrupts disabled.
> + * Otherwise, a call to fpsimd_save_sate() could be interrupted by a
> + * kernel_neon_begin()/kernel_neon_end() sequence, after which the top
> + * SVE end of the shared SVE/NEON register contents will be gone.
> + */
> + if (IS_ENABLED(CONFIG_ARM64_SVE))
> + BUG_ON((elf_hwcap & HWCAP_SVE) && in_irq());
> +
> + preempt_disable();
> +
> + level = this_cpu_inc_return(kernel_neon_nesting_level);
> + BUG_ON(level > 3);
> +
> + if (current->mm && !test_thread_flag(TIF_FOREIGN_FPSTATE)) {
> /*
> * Save the userland FPSIMD state if we have one and if we
> * haven't done so already. Clear fpsimd_last_state to indicate
> * that there is no longer userland FPSIMD state in the
> * registers.
> */
> - preempt_disable();
> - if (current->mm &&
> - !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> + local_bh_disable();
> + if (!test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> fpsimd_save_state(¤t->thread.fpsimd_state);
> - this_cpu_write(fpsimd_last_state, NULL);
> + local_bh_enable();
> + }
> + this_cpu_write(fpsimd_last_state, NULL);
> +
> + if (level > 1) {
> + s = this_cpu_ptr(nested_fpsimdstate);
> +
> + WARN_ON_ONCE(num_regs > 32);
> + num_regs = max(roundup(num_regs, 2), 32U);
> +
> + fpsimd_save_partial_state(&s[level - 2], num_regs);
> }
> }
> EXPORT_SYMBOL(kernel_neon_begin_partial);
>
> void kernel_neon_end(void)
> {
> - if (in_interrupt()) {
> - struct fpsimd_partial_state *s = this_cpu_ptr(
> - in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> - fpsimd_load_partial_state(s);
> - } else {
> - preempt_enable();
> + struct fpsimd_partial_state *s;
> + int level;
> +
> + level = this_cpu_read(kernel_neon_nesting_level);
> + BUG_ON(level < 1);
> +
> + if (level > 1) {
> + s = this_cpu_ptr(nested_fpsimdstate);
> + fpsimd_load_partial_state(&s[level - 2]);
> }
> +
> + this_cpu_dec(kernel_neon_nesting_level);
> + preempt_enable();
> }
> EXPORT_SYMBOL(kernel_neon_end);
>
> @@ -270,8 +308,12 @@ static int fpsimd_cpu_pm_notifier(struct notifier_block *self,
> {
> switch (cmd) {
> case CPU_PM_ENTER:
> - if (current->mm && !test_thread_flag(TIF_FOREIGN_FPSTATE))
> - fpsimd_save_state(¤t->thread.fpsimd_state);
> + if (current->mm) {
> + local_bh_disable();
> + if (!test_thread_flag(TIF_FOREIGN_FPSTATE))
> + fpsimd_save_state(¤t->thread.fpsimd_state);
> + local_bh_enable();
> + }
> this_cpu_write(fpsimd_last_state, NULL);
> break;
> case CPU_PM_EXIT:
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] mailbox: sti: Fix mbox-names copy and paste error
From: Rob Herring @ 2017-01-04 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104120527.24806-1-lee.jones@linaro.org>
On Wed, Jan 04, 2017 at 12:05:27PM +0000, Lee Jones wrote:
> Due to an over-sight, mbox-names has become mbox-name in some instances.
>
> Let's put it right.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> Documentation/devicetree/bindings/mailbox/sti-mailbox.txt | 4 ++--
> arch/arm/boot/dts/stih407-family.dtsi | 8 ++++----
> drivers/mailbox/mailbox-sti.c | 2 +-
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> index 351f612..648d176 100644
> --- a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> +++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> @@ -9,7 +9,7 @@ Controller
> Required properties:
> - compatible : Should be "st,stih407-mailbox"
> - reg : Offset and length of the device's register set
> -- mbox-name : Name of the mailbox
> +- mbox-names : Name of the mailbox
It's worse than this. mbox-names is for the mailbox client side. This
should just be dropped. Plus, *-names is pointless when there is only 1
element.
Rob
^ permalink raw reply
* [PATCH v2 14/19] media: imx: Add Camera Interface subdev driver
From: Vladimir Zapolskiy @ 2017-01-04 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483477049-19056-15-git-send-email-steve_longerbeam@mentor.com>
On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
> This is the camera interface driver that provides the v4l2
> user interface. Frames can be received from various sources:
>
> - directly from SMFC for capturing unconverted images directly from
> camera sensors.
>
> - from the IC pre-process encode task.
>
> - from the IC pre-process viewfinder task.
>
> - from the IC post-process task.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> drivers/staging/media/imx/Makefile | 2 +-
> drivers/staging/media/imx/imx-camif.c | 1010 +++++++++++++++++++++++++++++++++
> 2 files changed, 1011 insertions(+), 1 deletion(-)
> create mode 100644 drivers/staging/media/imx/imx-camif.c
>
> diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
> index d2a962c..fe9e992 100644
> --- a/drivers/staging/media/imx/Makefile
> +++ b/drivers/staging/media/imx/Makefile
> @@ -8,4 +8,4 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-ic.o
>
> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-smfc.o
> -
> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-camif.o
obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-camif.o imx-csi.o imx-smfc.o
as an option.
> diff --git a/drivers/staging/media/imx/imx-camif.c b/drivers/staging/media/imx/imx-camif.c
> new file mode 100644
> index 0000000..3cf167e
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-camif.c
> @@ -0,0 +1,1010 @@
> +/*
> + * Video Camera Capture Subdev for Freescale i.MX5/6 SOC
> + *
> + * Copyright (c) 2012-2016 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include <linux/module.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <linux/timer.h>
> +#include <linux/sched.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/platform_device.h>
> +#include <linux/pinctrl/consumer.h>
> +#include <linux/of_platform.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-ioctl.h>
> +#include <media/videobuf2-dma-contig.h>
> +#include <media/v4l2-subdev.h>
> +#include <media/v4l2-of.h>
> +#include <media/v4l2-ctrls.h>
> +#include <media/v4l2-event.h>
Please sort the list of headers alphabetically.
> +#include <video/imx-ipu-v3.h>
> +#include <media/imx.h>
> +#include "imx-media.h"
> +
> +#define DEVICE_NAME "imx-media-camif"
I would propose to drop this macro.
> +
> +#define CAMIF_NUM_PADS 2
> +
> +#define CAMIF_DQ_TIMEOUT 5000
Add a comment about time unit?
> +
> +struct camif_priv;
> +
This is a leftover apparently.
> +struct camif_priv {
> + struct device *dev;
> + struct video_device vfd;
> + struct media_pipeline mp;
> + struct imx_media_dev *md;
[snip]
> +static int camif_probe(struct platform_device *pdev)
> +{
> + struct imx_media_internal_sd_platformdata *pdata;
> + struct camif_priv *priv;
> + struct video_device *vfd;
> + int ret;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> + priv->dev = &pdev->dev;
> +
> + pdata = priv->dev->platform_data;
> +
> + mutex_init(&priv->mutex);
> + spin_lock_init(&priv->q_lock);
> +
> + v4l2_subdev_init(&priv->sd, &camif_subdev_ops);
> + v4l2_set_subdevdata(&priv->sd, priv);
> + priv->sd.internal_ops = &camif_internal_ops;
> + priv->sd.entity.ops = &camif_entity_ops;
> + priv->sd.entity.function = MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER;
> + priv->sd.dev = &pdev->dev;
> + priv->sd.owner = THIS_MODULE;
> + /* get our group id and camif id */
> + priv->sd.grp_id = pdata->grp_id;
> + priv->id = (pdata->grp_id >> IMX_MEDIA_GRP_ID_CAMIF_BIT) - 1;
> + strncpy(priv->sd.name, pdata->sd_name, sizeof(priv->sd.name));
> + snprintf(camif_videodev.name, sizeof(camif_videodev.name),
> + "%s devnode", pdata->sd_name);
> +
> + priv->sd.flags = V4L2_SUBDEV_FL_HAS_DEVNODE | V4L2_SUBDEV_FL_HAS_EVENTS;
> +
> + vfd = &priv->vfd;
> + *vfd = camif_videodev;
> + vfd->lock = &priv->mutex;
> + vfd->queue = &priv->buffer_queue;
> +
> + video_set_drvdata(vfd, priv);
> +
> + v4l2_ctrl_handler_init(&priv->ctrl_hdlr, 0);
> +
> + ret = v4l2_async_register_subdev(&priv->sd);
> + if (ret)
> + goto free_ctrls;
> +
> + return 0;
> +free_ctrls:
> + v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
> + return ret;
A shorter version:
if (ret)
v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
return ret;
> +}
> +
> +static int camif_remove(struct platform_device *pdev)
> +{
> + struct camif_priv *priv =
> + (struct camif_priv *)platform_get_drvdata(pdev);
> +
> + v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
> + v4l2_async_unregister_subdev(&priv->sd);
> + media_entity_cleanup(&priv->sd.entity);
> + v4l2_device_unregister_subdev(&priv->sd);
> +
> + return 0;
> +}
> +
> +static const struct platform_device_id camif_ids[] = {
> + { .name = DEVICE_NAME },
> + { },
> +};
> +MODULE_DEVICE_TABLE(platform, camif_ids);
> +
> +static struct platform_driver imx_camif_driver = {
> + .probe = camif_probe,
> + .remove = camif_remove,
> + .driver = {
> + .name = DEVICE_NAME,
> + .owner = THIS_MODULE,
Please drop the owner assignment.
> + },
> +};
> +
> +module_platform_driver(imx_camif_driver);
> +
> +MODULE_DESCRIPTION("i.MX camera interface subdev driver");
> +MODULE_AUTHOR("Steve Longerbeam <steve_longerbeam@mentor.com>");
> +MODULE_LICENSE("GPL");
>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v3] i2c: designware: add reset interface
From: Arnd Bergmann @ 2017-01-04 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482500451-30137-1-git-send-email-zhangfei.gao@linaro.org>
On Friday, December 23, 2016 9:40:51 PM CET Zhangfei Gao wrote:
> @@ -176,6 +177,14 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
> dev->irq = irq;
> platform_set_drvdata(pdev, dev);
>
> + dev->rst = devm_reset_control_get_optional_exclusive(&pdev->dev, NULL);
> + if (IS_ERR(dev->rst)) {
> + if (PTR_ERR(dev->rst) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + } else {
> + reset_control_deassert(dev->rst);
> + }
> +
Sorry for the late reply, I only now stumbled over this. I think it's
generally wrong to ignore any error aside from -EPROBE_DEFER. It's
better to single-out the error conditions you want to ignore (e.g.
no reset specified) and ignore those but return an error for
all other problems.
> @@ -270,10 +280,18 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
> }
>
> r = i2c_dw_probe(dev);
> - if (r && !dev->pm_runtime_disabled)
> - pm_runtime_disable(&pdev->dev);
> + if (r)
> + goto exit_probe;
>
> return r;
> +
> +exit_probe:
> + if (!dev->pm_runtime_disabled)
> + pm_runtime_disable(&pdev->dev);
> +exit_reset:
> + if (!IS_ERR_OR_NULL(dev->rst))
> + reset_control_assert(dev->rst);
> + return r;
>
try to avoid the IS_ERR_OR_NULL() check, it usually indicates either
a bad interface, or that the interface is used wrong.
In this case, I think we can't get here with a NULL dev->rst
pointer, so it's better to only check IS_ERR, or to explicitly
set the pointer to NULL in case there is no reset line.
Arnd
^ permalink raw reply
* [PATCH v6 1/5] dt-bindings: zte: documents zx2967 power domain driver bindings
From: Rob Herring @ 2017-01-04 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483530494-14177-1-git-send-email-baoyou.xie@linaro.org>
On Wed, Jan 04, 2017 at 07:48:10PM +0800, Baoyou Xie wrote:
> This patch documents devicetree tree bindings for the ZTE zx2967
> power domain driver.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> ---
> Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
>
> diff --git a/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
> new file mode 100644
> index 0000000..1476318
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
> @@ -0,0 +1,17 @@
> +* ZTE 2967 SoC Power Domains
> +
> +2967 processors include support for multiple power domains which are used
> +to gate power to one or more peripherals on the processor.
> +
> +Required Properties:
> +- compatible: should be one of the following.
> + * zte,zx296718-pcu - for zx296718 board's power domain.
board? I'd expect this is for an SoC?
> +- reg: physical base address of the controller and length of memory mapped
> + region.
#power-domain-cells needed?
> +
> +Example:
> +
> + pcu_domain: pcu at 0x00117000 {
pcu at 117000
> + compatible = "zte,zx296718-pcu";
> + reg = <0x00117000 0x1000>;
> + };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 13/19] media: imx: Add IC subdev drivers
From: Vladimir Zapolskiy @ 2017-01-04 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483477049-19056-14-git-send-email-steve_longerbeam@mentor.com>
On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
> This is a set of three media entity subdevice drivers for the i.MX
> Image Converter. The i.MX IC module contains three independent
> "tasks":
>
> - Pre-processing Encode task: video frames are routed directly from
> the CSI and can be scaled, color-space converted, and rotated.
> Scaled output is limited to 1024x1024 resolution. Output frames
> are routed to the camera interface entities (camif).
>
> - Pre-processing Viewfinder task: this task can perform the same
> conversions as the pre-process encode task, but in addition can
> be used for hardware motion compensated deinterlacing. Frames can
> come either directly from the CSI or from the SMFC entities (memory
> buffers via IDMAC channels). Scaled output is limited to 1024x1024
> resolution. Output frames can be routed to various sinks including
> the post-processing task entities.
>
> - Post-processing task: same conversions as pre-process encode. However
> this entity sends frames to the i.MX IPU image converter which supports
> image tiling, which allows scaled output up to 4096x4096 resolution.
> Output frames can be routed to the camera interfaces.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
[snip]
> +static int imx_ic_probe(struct platform_device *pdev)
> +{
> + struct imx_media_internal_sd_platformdata *pdata;
> + struct imx_ic_priv *priv;
> + int ret;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, &priv->sd);
> + priv->dev = &pdev->dev;
> +
> + /* get our ipu_id, grp_id and IC task id */
> + pdata = priv->dev->platform_data;
> + priv->ipu_id = pdata->ipu_id;
> + switch (pdata->grp_id) {
> + case IMX_MEDIA_GRP_ID_IC_PRPENC:
> + priv->task_id = IC_TASK_ENCODER;
> + break;
> + case IMX_MEDIA_GRP_ID_IC_PRPVF:
> + priv->task_id = IC_TASK_VIEWFINDER;
> + break;
> + case IMX_MEDIA_GRP_ID_IC_PP0...IMX_MEDIA_GRP_ID_IC_PP3:
> + priv->task_id = IC_TASK_POST_PROCESSOR;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + v4l2_subdev_init(&priv->sd, ic_ops[priv->task_id]->subdev_ops);
> + v4l2_set_subdevdata(&priv->sd, priv);
> + priv->sd.internal_ops = ic_ops[priv->task_id]->internal_ops;
> + priv->sd.entity.ops = ic_ops[priv->task_id]->entity_ops;
> + priv->sd.entity.function = MEDIA_ENT_F_PROC_VIDEO_SCALER;
> + priv->sd.dev = &pdev->dev;
> + priv->sd.owner = THIS_MODULE;
> + priv->sd.flags = V4L2_SUBDEV_FL_HAS_DEVNODE | V4L2_SUBDEV_FL_HAS_EVENTS;
> + priv->sd.grp_id = pdata->grp_id;
> + strncpy(priv->sd.name, pdata->sd_name, sizeof(priv->sd.name));
> +
> + ret = ic_ops[priv->task_id]->init(priv);
> + if (ret)
> + return ret;
> +
> + ret = v4l2_async_register_subdev(&priv->sd);
> + if (ret)
> + goto remove;
> +
> + return 0;
> +remove:
> + ic_ops[priv->task_id]->remove(priv);
> + return ret;
if (ret)
ic_ops[priv->task_id]->remove(priv);
return ret;
as an alternative.
[snip]
> +static const struct platform_device_id imx_ic_ids[] = {
> + { .name = "imx-ipuv3-ic" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(platform, imx_ic_ids);
> +
> +static struct platform_driver imx_ic_driver = {
> + .probe = imx_ic_probe,
> + .remove = imx_ic_remove,
> + .id_table = imx_ic_ids,
> + .driver = {
> + .name = "imx-ipuv3-ic",
> + .owner = THIS_MODULE,
Please drop .owner assignment.
> + },
> +};
> +module_platform_driver(imx_ic_driver);
> +
> +MODULE_DESCRIPTION("i.MX IC subdev driver");
> +MODULE_AUTHOR("Steve Longerbeam <steve_longerbeam@mentor.com>");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:imx-ipuv3-ic");
> diff --git a/drivers/staging/media/imx/imx-ic-pp.c b/drivers/staging/media/imx/imx-ic-pp.c
> new file mode 100644
> index 0000000..5ef0581
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-ic-pp.c
> @@ -0,0 +1,636 @@
> +/*
> + * V4L2 IC Post-Processor Subdev for Freescale i.MX5/6 SOC
> + *
> + * Copyright (c) 2014-2016 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include <linux/module.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <linux/timer.h>
> +#include <linux/sched.h>
> +#include <linux/slab.h>
> +#include <linux/interrupt.h>
> +#include <linux/platform_device.h>
> +#include <linux/pinctrl/consumer.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-ioctl.h>
> +#include <media/videobuf2-dma-contig.h>
> +#include <media/v4l2-subdev.h>
> +#include <media/v4l2-of.h>
> +#include <media/v4l2-ctrls.h>
Please sort the list of headers alphabetically.
> +#include <media/imx.h>
> +#include <video/imx-ipu-image-convert.h>
> +#include "imx-media.h"
> +#include "imx-ic.h"
> +
[snip]
> +
> +static int pp_start(struct pp_priv *priv)
> +{
> + struct imx_ic_priv *ic_priv = priv->ic_priv;
> + struct ipu_image image_in, image_out;
> + const struct imx_media_pixfmt *incc;
> + struct v4l2_mbus_framefmt *infmt;
> + int i, in_size, ret;
> +
> + /* ask the sink for the buffer ring */
> + ret = v4l2_subdev_call(priv->sink_sd, core, ioctl,
> + IMX_MEDIA_REQ_DMA_BUF_SINK_RING,
> + &priv->out_ring);
> + if (ret)
> + return ret;
> +
> + imx_media_mbus_fmt_to_ipu_image(&image_in,
> + &priv->format_mbus[priv->input_pad]);
> + imx_media_mbus_fmt_to_ipu_image(&image_out,
> + &priv->format_mbus[priv->output_pad]);
> +
> + priv->ipu = priv->md->ipu[ic_priv->ipu_id];
> + priv->ic_ctx = ipu_image_convert_prepare(priv->ipu,
> + IC_TASK_POST_PROCESSOR,
> + &image_in, &image_out,
> + priv->rot_mode,
> + pp_convert_complete, priv);
> + if (IS_ERR(priv->ic_ctx))
> + return PTR_ERR(priv->ic_ctx);
> +
> + infmt = &priv->format_mbus[priv->input_pad];
> + incc = priv->cc[priv->input_pad];
> + in_size = (infmt->width * incc->bpp * infmt->height) >> 3;
> +
> + if (priv->in_ring) {
> + v4l2_warn(&ic_priv->sd, "%s: dma-buf ring was not freed\n",
> + __func__);
> + imx_media_free_dma_buf_ring(priv->in_ring);
> + }
> +
> + priv->in_ring = imx_media_alloc_dma_buf_ring(priv->md,
> + &priv->src_sd->entity,
> + &ic_priv->sd.entity,
> + in_size,
> + IMX_MEDIA_MIN_RING_BUFS,
> + true);
> + if (IS_ERR(priv->in_ring)) {
> + v4l2_err(&ic_priv->sd,
> + "failed to alloc dma-buf ring\n");
> + ret = PTR_ERR(priv->in_ring);
> + priv->in_ring = NULL;
> + goto out_unprep;
> + }
> +
> + for (i = 0; i < IMX_MEDIA_MIN_RING_BUFS; i++)
> + imx_media_dma_buf_queue(priv->in_ring, i);
> +
> + priv->out_run = kzalloc(IMX_MEDIA_MAX_RING_BUFS *
> + sizeof(*priv->out_run), GFP_KERNEL);
> + if (!priv->out_run) {
> + v4l2_err(&ic_priv->sd, "failed to alloc src ring runs\n");
In OOM situation the core will report it, probably you can drop the message.
> + ret = -ENOMEM;
> + goto out_free_ring;
> + }
> +
> + priv->stop = false;
> +
> + return 0;
> +
> +out_free_ring:
> + imx_media_free_dma_buf_ring(priv->in_ring);
> + priv->in_ring = NULL;
> +out_unprep:
> + ipu_image_convert_unprepare(priv->ic_ctx);
> + return ret;
> +}
> +
[snip]
> diff --git a/drivers/staging/media/imx/imx-ic-prpenc.c b/drivers/staging/media/imx/imx-ic-prpenc.c
> new file mode 100644
> index 0000000..e17216b
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-ic-prpenc.c
> @@ -0,0 +1,1037 @@
> +/*
> + * V4L2 Capture IC Encoder Subdev for Freescale i.MX5/6 SOC
> + *
> + * This subdevice handles capture of video frames from the CSI, which
> + * are routed directly to the Image Converter preprocess encode task,
> + * for resizing, colorspace conversion, and rotation.
> + *
> + * Copyright (c) 2012-2016 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include <linux/module.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <linux/timer.h>
> +#include <linux/sched.h>
> +#include <linux/slab.h>
> +#include <linux/interrupt.h>
> +#include <linux/spinlock.h>
> +#include <linux/platform_device.h>
> +#include <linux/pinctrl/consumer.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-ioctl.h>
> +#include <media/videobuf2-dma-contig.h>
> +#include <media/v4l2-subdev.h>
> +#include <media/v4l2-of.h>
> +#include <media/v4l2-ctrls.h>
Please sort the list of headers alphabetically.
> +#include <media/imx.h>
> +#include "imx-media.h"
> +#include "imx-ic.h"
> +
[snip]
> +static irqreturn_t prpenc_eof_interrupt(int irq, void *dev_id)
> +{
> + struct prpenc_priv *priv = dev_id;
> + struct imx_media_dma_buf *done, *next;
> + struct ipuv3_channel *channel;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->irqlock, flags);
Here spin_lock(&priv->irqlock) should be sufficient.
> +
> + if (priv->last_eof) {
> + complete(&priv->last_eof_comp);
> + priv->last_eof = false;
> + goto unlock;
> + }
> +
> + /* inform CSI of this EOF so it can monitor frame intervals */
> + v4l2_subdev_call(priv->src_sd, core, interrupt_service_routine,
> + 0, NULL);
> +
> + channel = (ipu_rot_mode_is_irt(priv->rot_mode)) ?
> + priv->enc_rot_out_ch : priv->enc_ch;
> +
> + done = imx_media_dma_buf_get_active(priv->out_ring);
> + /* give the completed buffer to the sink */
> + if (!WARN_ON(!done))
> + imx_media_dma_buf_done(done, IMX_MEDIA_BUF_STATUS_DONE);
> +
> + /* priv->next buffer is now the active one */
> + imx_media_dma_buf_set_active(priv->next);
> +
> + /* bump the EOF timeout timer */
> + mod_timer(&priv->eof_timeout_timer,
> + jiffies + msecs_to_jiffies(IMX_MEDIA_EOF_TIMEOUT));
> +
> + if (ipu_idmac_buffer_is_ready(channel, priv->ipu_buf_num))
> + ipu_idmac_clear_buffer(channel, priv->ipu_buf_num);
> +
> + /* get next queued buffer */
> + next = imx_media_dma_buf_get_next_queued(priv->out_ring);
> +
> + ipu_cpmem_set_buffer(channel, priv->ipu_buf_num, next->phys);
> + ipu_idmac_select_buffer(channel, priv->ipu_buf_num);
> +
> + /* toggle IPU double-buffer index */
> + priv->ipu_buf_num ^= 1;
> + priv->next = next;
> +
> +unlock:
> + spin_unlock_irqrestore(&priv->irqlock, flags);
> + return IRQ_HANDLED;
> +}
[snip]
> +static int prpenc_registered(struct v4l2_subdev *sd)
> +{
> + struct prpenc_priv *priv = sd_to_priv(sd);
> + struct imx_media_subdev *imxsd;
> + struct imx_media_pad *pad;
> + int i, ret;
> +
> + /* get media device */
> + priv->md = dev_get_drvdata(sd->v4l2_dev->dev);
> +
> + imxsd = imx_media_find_subdev_by_sd(priv->md, sd);
> + if (IS_ERR(imxsd))
> + return PTR_ERR(imxsd);
> +
> + if (imxsd->num_sink_pads != 1 || imxsd->num_src_pads != 1)
> + return -EINVAL;
> +
> + for (i = 0; i < PRPENC_NUM_PADS; i++) {
> + pad = &imxsd->pad[i];
> + priv->pad[i] = pad->pad;
> + if (priv->pad[i].flags & MEDIA_PAD_FL_SINK)
> + priv->input_pad = i;
> + else
> + priv->output_pad = i;
> +
> + /* set a default mbus format */
> + ret = imx_media_init_mbus_fmt(&priv->format_mbus[i],
> + 640, 480, 0, V4L2_FIELD_NONE,
> + &priv->cc[i]);
> + if (ret)
> + return ret;
> + }
> +
> + ret = prpenc_init_controls(priv);
> + if (ret)
> + return ret;
> +
> + ret = media_entity_pads_init(&sd->entity, PRPENC_NUM_PADS, priv->pad);
> + if (ret)
> + goto free_ctrls;
> +
> + return 0;
> +free_ctrls:
> + v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
> + return ret;
if (ret)
v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
return ret;
version is shorter.
> +}
[snip]
> diff --git a/drivers/staging/media/imx/imx-ic-prpvf.c b/drivers/staging/media/imx/imx-ic-prpvf.c
> new file mode 100644
> index 0000000..53ce006
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-ic-prpvf.c
> @@ -0,0 +1,1180 @@
> +/*
> + * V4L2 IC Deinterlacer Subdev for Freescale i.MX5/6 SOC
> + *
> + * Copyright (c) 2014-2016 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include <linux/module.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <linux/timer.h>
> +#include <linux/sched.h>
> +#include <linux/slab.h>
> +#include <linux/interrupt.h>
> +#include <linux/platform_device.h>
> +#include <linux/pinctrl/consumer.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-ioctl.h>
> +#include <media/videobuf2-dma-contig.h>
> +#include <media/v4l2-subdev.h>
> +#include <media/v4l2-of.h>
> +#include <media/v4l2-ctrls.h>
Please sort the list of headers alphabetically.
> +#include <media/imx.h>
> +#include "imx-media.h"
> +#include "imx-ic.h"
> +
> +/*
[snip]
> +/* prpvf_out_ch EOF interrupt (progressive frame ready) */
> +static irqreturn_t prpvf_out_eof_interrupt(int irq, void *dev_id)
> +{
> + struct prpvf_priv *priv = dev_id;
> + struct imx_media_dma_buf *done;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->irqlock, flags);
Here spin_lock(&priv->irqlock) should be sufficient.
> +
> + if (priv->last_eof) {
> + complete(&priv->last_eof_comp);
> + priv->last_eof = false;
> + goto unlock;
> + }
> +
> + if (priv->csi_direct) {
> + /* inform CSI of this EOF so it can monitor frame intervals */
> + /* FIXME: frames are coming in twice as fast in direct path! */
> + v4l2_subdev_call(priv->src_sd, core, interrupt_service_routine,
> + 0, NULL);
> + }
> +
> + done = imx_media_dma_buf_get_active(priv->out_ring);
> + /* give the completed buffer to the sink */
> + if (!WARN_ON(!done))
> + imx_media_dma_buf_done(done, IMX_MEDIA_BUF_STATUS_DONE);
> +
> + if (!priv->csi_direct) {
> + /* we're done with the input buffer, queue it back */
> + imx_media_dma_buf_queue(priv->in_ring,
> + priv->curr_in_buf->index);
> +
> + /* current input buffer is now last */
> + priv->last_in_buf = priv->curr_in_buf;
> + } else {
> + /*
> + * priv->next buffer is now the active one due
> + * to IPU double-buffering
> + */
> + imx_media_dma_buf_set_active(priv->next_out_buf);
> + }
> +
> + /* bump the EOF timeout timer */
> + mod_timer(&priv->eof_timeout_timer,
> + jiffies + msecs_to_jiffies(IMX_MEDIA_EOF_TIMEOUT));
> +
> + if (priv->csi_direct) {
> + prepare_prpvf_out_buffer(priv);
> + /* toggle IPU double-buffer index */
> + priv->ipu_buf_num ^= 1;
> + }
> +
> +unlock:
> + spin_unlock_irqrestore(&priv->irqlock, flags);
> + return IRQ_HANDLED;
> +}
> +
[snip]
> diff --git a/drivers/staging/media/imx/imx-ic.h b/drivers/staging/media/imx/imx-ic.h
> new file mode 100644
> index 0000000..9aed5f5
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-ic.h
> @@ -0,0 +1,36 @@
> +/*
> + * V4L2 Image Converter Subdev for Freescale i.MX5/6 SOC
> + *
> + * Copyright (c) 2016 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#ifndef _IMX_IC_H
> +#define _IMX_IC_H
> +
Please add header files or declarations of all used structs.
> +struct imx_ic_priv {
> + struct device *dev;
> + struct v4l2_subdev sd;
> + int ipu_id;
> + int task_id;
> + void *task_priv;
> +};
> +
> +struct imx_ic_ops {
> + struct v4l2_subdev_ops *subdev_ops;
> + struct v4l2_subdev_internal_ops *internal_ops;
> + struct media_entity_operations *entity_ops;
> +
> + int (*init)(struct imx_ic_priv *ic_priv);
> + void (*remove)(struct imx_ic_priv *ic_priv);
> +};
> +
> +extern struct imx_ic_ops imx_ic_prpenc_ops;
> +extern struct imx_ic_ops imx_ic_prpvf_ops;
> +extern struct imx_ic_ops imx_ic_pp_ops;
> +
> +#endif
> +
>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Arnd Bergmann @ 2017-01-04 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <412396ac-4535-08a3-e4c7-dd8d0078a518@cogentembedded.com>
On Wednesday, January 4, 2017 5:30:19 PM CET Nikita Yushchenko wrote:
> >> For OF platforms, this is called via of_dma_configure(), that checks
> >> dma-ranges of node that is *parent* for host bridge. Host bridge
> >> currently does not control this at all.
> >
> > We need to think about this a bit. Is it actually the PCI host
> > bridge that limits the ranges here, or the bus that it is connected
> > to. In the latter case, the caller needs to be adapted to handle
> > both.
>
> In r-car case, I'm not sure what is the source of limitation at physical
> level.
>
> pcie-rcar driver configures ranges for PCIe inbound transactions based
> on dma-ranges property in it's device tree node. In the current device
> tree for this platform, that only contains one range and it is in lower
> memory.
>
> NVMe driver tries i/o to kmalloc()ed area. That returns 0x5xxxxxxxx
> addresses here. As a quick experiment, I tried to add second range to
> pcie-rcar's dma-ranges to cover 0x5xxxxxxxx area - but that did not make
> DMA to high addresses working.
>
> My current understanding is that host bridge hardware module can't
> handle inbound transactions to PCI addresses above 4G - and this
> limitations comes from host bridge itself.
>
> I've read somewhere in the lists that pcie-rcar hardware is "32-bit" -
> but I don't remember where, and don't know lowlevel details. Maybe
> somebody from linux-renesas can elaborate?
Just a guess, but if the inbound translation windows in the host
bridge are wider than 32-bit, the reason for setting up a single
32-bit window is probably because that is what the parent bus supports.
> >> In current device trees no dma-ranges is defined for nodes that are
> >> parents to pci host bridges. This will make of_dma_configure() to fall
> >> back to 32-bit size for all devices on all current platforms. Thus
> >> applying this patch will immediately break 64-bit dma masks on all
> >> hardware that supports it.
> >
> > No, it won't break it, it will just fall back to swiotlb for all the
> > ones that are lacking the dma-ranges property. I think this is correct
> > behavior.
>
> I'd say - for all ones that have parents without dma-ranges property.
>
> As of 4.10-rc2, I see only two definitions of wide parent dma-ranges
> under arch/arm64/boot/dts/ - in amd/amd-seattle-soc.dtsi and
> apm/apm-storm.dtsi
>
> Are these the only arm64 platforms that can to DMA to high addresses?
> I'm not arm64 expert but I'd be surprised if that's the case.
It's likely that a few others also do high DMA, but a lot of arm64
chips are actually derived from earlier 32-bit chips and don't
even support any RAM above 4GB, as well as having a lot of 32-bit
DMA masters.
> >> Also related: dma-ranges property used by several pci host bridges is
> >> *not* compatible with "legacy" dma-ranges parsed by of_get_dma_range() -
> >> former uses additional flags word at beginning.
> >
> > Can you elaborate? Do we have PCI host bridges that use wrongly formatted
> > dma-ranges properties?
>
> of_dma_get_range() expects <dma_addr cpu_addr size> format.
>
> pcie-rcar.c, pci-rcar-gen2.c, pci-xgene.c and pcie-iproc.c from
> drivers/pci/host/ all parse dma-ranges using of_pci_range_parser that
> uses <flags pci-addr cpu-addr size> format - i.e. something different
> from what of_dma_get_range() uses.
The "dma_addr" here is expressed in terms of #address-cells of the
bus it is in, and that is "3" in case of PCI, where the first 32-bit
word is a bit pattern containing various things, and the other two
cells are a 64-bit address. I think this is correct, but we may
need to add some special handling for parsing PCI host bridges
in of_dma_get_range, to ensure we actually look at translations for
the memory space.
Arnd
^ permalink raw reply
* [PATCH resend v4 2/3] ARM: dts: imx6: Support Savageboard dual
From: Rob Herring @ 2017-01-04 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104070436.3425-1-woogyom.kim@gmail.com>
On Wed, Jan 04, 2017 at 04:04:36PM +0900, Milo Kim wrote:
> Common savageboard DT file is used for board support.
> Add the vendor name and specify the dtb file for i.MX6Q build.
>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
> ---
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6dl-savageboard.dts | 51 ++++++++++++++++++++++
> 3 files changed, 53 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-savageboard.dts
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: Add DT bindings info for FlexRM ring manager
From: Rob Herring @ 2017-01-04 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483508082-7008-3-git-send-email-anup.patel@broadcom.com>
On Wed, Jan 04, 2017 at 11:04:42AM +0530, Anup Patel wrote:
> This patch adds device tree bindings document for the FlexRM
> ring manager found on Broadcom iProc SoCs.
>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> ---
> .../bindings/mailbox/brcm,iproc-flexrm-mbox.txt | 60 ++++++++++++++++++++++
> 1 file changed, 60 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
> new file mode 100644
> index 0000000..ca51a39
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
> @@ -0,0 +1,60 @@
> +Broadcom FlexRM Ring Manager
> +============================
> +The Broadcom FlexRM ring manager provides a set of rings which can be
> +used to submit work to offload engines. An SoC may have multiple FlexRM
> +hardware blocks. There is one device tree entry per FlexRM block. The
> +FlexRM driver will create a mailbox-controller instance for given FlexRM
> +hardware block where each mailbox channel is a separate FlexRM ring.
> +
> +Required properties:
> +--------------------
> +- compatible: Should be "brcm,iproc-flexrm-mbox"
> +- reg: Specifies base physical address and size of the FlexRM
> + ring registers
> +- msi-parent: Phandles (and potential Device IDs) to MSI controllers
> + The FlexRM engine will send MSIs (instead of wired
> + interrupts) to CPU. There is one MSI for each FlexRM ring.
> + Refer devicetree/bindings/interrupt-controller/msi.txt
> +- #mbox-cells: Specifies the number of cells needed to encode a mailbox
> + channel. This should be 3.
> +
> + The 1st cell is the mailbox channel number.
> +
> + The 2nd cell contains MSI completion threshold. This is the
> + number of completion messages for which FlexRM will inject
> + one MSI interrupt to CPU.
> +
> + The 3nd cell contains MSI timer value representing time for
> + which FlexRM will wait to accumulate N completion messages
> + where N is the value specified by 2nd cell above. If FlexRM
> + does not get required number of completion messages in time
> + specified by this cell then it will inject one MSI interrupt
> + to CPU provided atleast one completion message is available.
> +
> +Optional properties:
> +--------------------
> +- dma-coherent: Present if DMA operations made by the FlexRM engine (such
> + as DMA descriptor access, access to buffers pointed by DMA
> + descriptors and read/write pointer updates to DDR) are
> + cache coherent with the CPU.
> +
> +Example:
> +--------
> +crypto_mbox: mbox at 67000000 {
> + compatible = "brcm,iproc-flexrm-mbox";
> + reg = <0x67000000 0x200000>;
> + msi-parent = <&gic_its 0x7f00>;
> + #mbox-cells = <3>;
> +};
> +
> +crypto_client {
crypto@<addr>
> + ...
> + mboxes = <&crypto_mbox 0 0x1 0xffff>,
> + <&crypto_mbox 1 0x1 0xffff>,
> + <&crypto_mbox 16 0x1 0xffff>,
> + <&crypto_mbox 17 0x1 0xffff>,
> + <&crypto_mbox 30 0x1 0xffff>,
> + <&crypto_mbox 31 0x1 0xffff>;
> + };
> + ...
Please somewhat fully list the contents for node.
Rob
^ permalink raw reply
* [PATCH v6 03/14] ACPI: ARM64: IORT: add missing comment for iort_dev_find_its_id()
From: Lorenzo Pieralisi @ 2017-01-04 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-4-git-send-email-hanjun.guo@linaro.org>
On Mon, Jan 02, 2017 at 09:31:34PM +0800, Hanjun Guo wrote:
> We are missing req_id's comment for iort_dev_find_its_id(),
> add it back.
"Add missing req_id parameter to the iort_dev_find_its_id() function
kernel-doc comment."
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Majun <majun258@huawei.com>
> Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> ---
> drivers/acpi/arm64/iort.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 46e2d82..174e983 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -446,6 +446,7 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> /**
> * iort_dev_find_its_id() - Find the ITS identifier for a device
> * @dev: The device.
> + * @req_id: Device's Requster ID
s/Requster/Requester
We can send it upstream independently along with some other patches
in this series but I will have a look at the whole series first.
Lorenzo
> * @idx: Index of the ITS identifier list.
> * @its_id: ITS identifier.
> *
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Will Deacon @ 2017-01-04 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104135644.GA29212@leverpostej>
On Wed, Jan 04, 2017 at 01:56:44PM +0000, Mark Rutland wrote:
> On Tue, Jan 03, 2017 at 09:33:36AM +0000, Mark Rutland wrote:
> > On Mon, Jan 02, 2017 at 09:15:29PM +0100, Linus Walleij wrote:
> > > On Mon, Jan 2, 2017 at 4:00 PM, Russell King - ARM Linux
> > > <linux@armlinux.org.uk> wrote:
> > > > On Mon, Jan 02, 2017 at 03:34:32PM +0100, Linus Walleij wrote:
> > > >> in the first line of arch_hw_breakpoint_init() in
> > > >> arch/arm/kernel/hw_breakpoint.c
> > > >>
> > > >> I suspect that is not an accepable solution ...
> > > >>
> > > >> It hangs at PC is at write_wb_reg+0x20c/0x330
> > > >> Which is c03101dc, and looks like this in objdump -d:
> > > >>
> > > >> c031020c: ee001eba mcr 14, 0, r1, cr0, cr10, {5}
> > > >> c0310210: eaffffb3 b c03100e4 <write_wb_reg+0x114>
> > > >
> > > > ... and this is several instructions after the address you mention above.
> > > > Presumably c03101dc is accessing a higher numbered register?
> > >
> > > Ah sorry. It looks like this:
> > >
> > > c03101dc: ee001ed0 mcr 14, 0, r1, cr0, cr0, {6}
> > > c03101e0: eaffffbf b c03100e4 <write_wb_reg+0x114>
> > > c03101e4: ee001ebf mcr 14, 0, r1, cr0, cr15, {5}
> > > c03101e8: eaffffbd b c03100e4 <write_wb_reg+0x114>
> > > c03101ec: ee001ebe mcr 14, 0, r1, cr0, cr14, {5}
> > > c03101f0: eaffffbb b c03100e4 <write_wb_reg+0x114>
> > > c03101f4: ee001ebd mcr 14, 0, r1, cr0, cr13, {5}
> > > c03101f8: eaffffb9 b c03100e4 <write_wb_reg+0x114>
> >
> > FWIW, I was tracking an issue in this area before the holiday.
> >
> > It looked like DBGPRSR.SPD is set unexpectedly over the default idle
> > path (i.e. WFI), causing the (otherwise valid) register accesses above
> > to be handled as undefined.
> >
> > I haven't looked at the patch in detail, but I guess that it allows idle
> > to occur between reset_ctrl_regs() and arch_hw_breakpoint_init().
>
> I've just reproduced this locally on my dragonboard APQ8060.
>
> It looks like the write_wb_reg() call that's exploding is from
> get_max_wp_len(), which we call immediately after registering the
> dbg_reset_online callback. Clearing DBGPRSR.SPD before the write_wb_reg() hides
> the problem, so I suspect we're seeing the issue I mentioned above -- it just
> so happens that we go idle in a new place.
When you say "go idle", are we just executing a WFI, or is the power
controller coming into play and we're actually powering down the non-debug
logic? In the case of the latter, the PM notifier should clear SPD in
reset_ctrl_regs, so this sounds like a hardware bug where the SPD bit is
set unconditionally on WFI.
In that case, this code has always been dodgy -- what happens if you try
to use hardware breakpoints in GDB in the face of WFI-based idle?
> The below hack allows boot to continue, but is not a real fix. I'm not
> immediately sure what to do.
If it's never worked, I suggest we blacklist the MIDR until somebody from
Qualcomm can help us further.
Will
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Nikita Yushchenko @ 2017-01-04 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2104402.puPT8SttTe@wuerfel>
>> For OF platforms, this is called via of_dma_configure(), that checks
>> dma-ranges of node that is *parent* for host bridge. Host bridge
>> currently does not control this at all.
>
> We need to think about this a bit. Is it actually the PCI host
> bridge that limits the ranges here, or the bus that it is connected
> to. In the latter case, the caller needs to be adapted to handle
> both.
In r-car case, I'm not sure what is the source of limitation at physical
level.
pcie-rcar driver configures ranges for PCIe inbound transactions based
on dma-ranges property in it's device tree node. In the current device
tree for this platform, that only contains one range and it is in lower
memory.
NVMe driver tries i/o to kmalloc()ed area. That returns 0x5xxxxxxxx
addresses here. As a quick experiment, I tried to add second range to
pcie-rcar's dma-ranges to cover 0x5xxxxxxxx area - but that did not make
DMA to high addresses working.
My current understanding is that host bridge hardware module can't
handle inbound transactions to PCI addresses above 4G - and this
limitations comes from host bridge itself.
I've read somewhere in the lists that pcie-rcar hardware is "32-bit" -
but I don't remember where, and don't know lowlevel details. Maybe
somebody from linux-renesas can elaborate?
>> In current device trees no dma-ranges is defined for nodes that are
>> parents to pci host bridges. This will make of_dma_configure() to fall
>> back to 32-bit size for all devices on all current platforms. Thus
>> applying this patch will immediately break 64-bit dma masks on all
>> hardware that supports it.
>
> No, it won't break it, it will just fall back to swiotlb for all the
> ones that are lacking the dma-ranges property. I think this is correct
> behavior.
I'd say - for all ones that have parents without dma-ranges property.
As of 4.10-rc2, I see only two definitions of wide parent dma-ranges
under arch/arm64/boot/dts/ - in amd/amd-seattle-soc.dtsi and
apm/apm-storm.dtsi
Are these the only arm64 platforms that can to DMA to high addresses?
I'm not arm64 expert but I'd be surprised if that's the case.
>> Also related: dma-ranges property used by several pci host bridges is
>> *not* compatible with "legacy" dma-ranges parsed by of_get_dma_range() -
>> former uses additional flags word at beginning.
>
> Can you elaborate? Do we have PCI host bridges that use wrongly formatted
> dma-ranges properties?
of_dma_get_range() expects <dma_addr cpu_addr size> format.
pcie-rcar.c, pci-rcar-gen2.c, pci-xgene.c and pcie-iproc.c from
drivers/pci/host/ all parse dma-ranges using of_pci_range_parser that
uses <flags pci-addr cpu-addr size> format - i.e. something different
from what of_dma_get_range() uses.
Nikita
^ permalink raw reply
* [PATCH v2 12/19] media: imx: Add SMFC subdev driver
From: Vladimir Zapolskiy @ 2017-01-04 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483477049-19056-13-git-send-email-steve_longerbeam@mentor.com>
On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
> This is a media entity subdevice driver for the i.MX Sensor Multi-FIFO
> Controller module. Video frames are received from the CSI and can
> be routed to various sinks including the i.MX Image Converter for
> scaling, color-space conversion, motion compensated deinterlacing,
> and image rotation.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> drivers/staging/media/imx/Makefile | 1 +
> drivers/staging/media/imx/imx-smfc.c | 739 +++++++++++++++++++++++++++++++++++
> 2 files changed, 740 insertions(+)
> create mode 100644 drivers/staging/media/imx/imx-smfc.c
>
> diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
> index 133672a..3559d7b 100644
> --- a/drivers/staging/media/imx/Makefile
> +++ b/drivers/staging/media/imx/Makefile
> @@ -5,4 +5,5 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
> obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
>
> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-smfc.o
May be
obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o imx-smfc.o
>
> diff --git a/drivers/staging/media/imx/imx-smfc.c b/drivers/staging/media/imx/imx-smfc.c
> new file mode 100644
> index 0000000..565048c
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-smfc.c
> @@ -0,0 +1,739 @@
> +/*
> + * V4L2 Capture SMFC Subdev for Freescale i.MX5/6 SOC
> + *
> + * This subdevice handles capture of raw/unconverted video frames
> + * from the CSI, directly to memory via the Sensor Multi-FIFO Controller.
> + *
> + * Copyright (c) 2012-2016 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include <linux/module.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <linux/timer.h>
> +#include <linux/sched.h>
> +#include <linux/slab.h>
> +#include <linux/interrupt.h>
> +#include <linux/spinlock.h>
> +#include <linux/platform_device.h>
> +#include <linux/pinctrl/consumer.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-ioctl.h>
> +#include <media/videobuf2-dma-contig.h>
> +#include <media/v4l2-subdev.h>
> +#include <media/v4l2-of.h>
> +#include <media/v4l2-ctrls.h>
Please sort the list of headers alphabetically.
> +#include <media/imx.h>
> +#include "imx-media.h"
> +
[snip]
> +static irqreturn_t imx_smfc_eof_interrupt(int irq, void *dev_id)
> +{
> + struct imx_smfc_priv *priv = dev_id;
> + struct imx_media_dma_buf *done, *next;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->irqlock, flags);
spin_lock(&priv->irqlock) should be sufficient.
> +
> + if (priv->last_eof) {
> + complete(&priv->last_eof_comp);
> + priv->last_eof = false;
> + goto unlock;
> + }
> +
> + /* inform CSI of this EOF so it can monitor frame intervals */
> + v4l2_subdev_call(priv->src_sd, core, interrupt_service_routine,
> + 0, NULL);
> +
> + done = imx_media_dma_buf_get_active(priv->out_ring);
> + /* give the completed buffer to the sink */
> + if (!WARN_ON(!done))
> + imx_media_dma_buf_done(done, IMX_MEDIA_BUF_STATUS_DONE);
> +
> + /* priv->next buffer is now the active one */
> + imx_media_dma_buf_set_active(priv->next);
> +
> + /* bump the EOF timeout timer */
> + mod_timer(&priv->eof_timeout_timer,
> + jiffies + msecs_to_jiffies(IMX_MEDIA_EOF_TIMEOUT));
> +
> + if (ipu_idmac_buffer_is_ready(priv->smfc_ch, priv->ipu_buf_num))
> + ipu_idmac_clear_buffer(priv->smfc_ch, priv->ipu_buf_num);
> +
> + /* get next queued buffer */
> + next = imx_media_dma_buf_get_next_queued(priv->out_ring);
> +
> + ipu_cpmem_set_buffer(priv->smfc_ch, priv->ipu_buf_num, next->phys);
> + ipu_idmac_select_buffer(priv->smfc_ch, priv->ipu_buf_num);
> +
> + /* toggle IPU double-buffer index */
> + priv->ipu_buf_num ^= 1;
> + priv->next = next;
> +
> +unlock:
> + spin_unlock_irqrestore(&priv->irqlock, flags);
> + return IRQ_HANDLED;
> +}
> +
[snip]
> +
> +static const struct platform_device_id imx_smfc_ids[] = {
> + { .name = "imx-ipuv3-smfc" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(platform, imx_smfc_ids);
> +
> +static struct platform_driver imx_smfc_driver = {
> + .probe = imx_smfc_probe,
> + .remove = imx_smfc_remove,
> + .id_table = imx_smfc_ids,
> + .driver = {
> + .name = "imx-ipuv3-smfc",
> + .owner = THIS_MODULE,
You can drop owner assignment.
> + },
> +};
> +module_platform_driver(imx_smfc_driver);
> +
> +MODULE_DESCRIPTION("i.MX SMFC subdev driver");
> +MODULE_AUTHOR("Steve Longerbeam <steve_longerbeam@mentor.com>");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:imx-ipuv3-smfc");
>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH 2/2] ARM: dts: sun7i: Enable audio codec on Banana Pro
From: Jörg Krause @ 2017-01-04 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104142250.22171-1-joerg.krause@embedded.rocks>
This commit enables the on-chip audio codec present on the A20 SoC
on the Banana Pro board.
Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
---
arch/arm/boot/dts/sun7i-a20-bananapro.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
index 439ad50dcd4a..797de4c352a5 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
@@ -100,6 +100,10 @@
status = "okay";
};
+&codec {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: sun7i: Add wifi dt node on Banana Pro
From: Jörg Krause @ 2017-01-04 14:22 UTC (permalink / raw)
To: linux-arm-kernel
The Banana Pro has an AMPAK AP6181 WiFi+Bluetooth module. The WiFi part
is a BCM43362 IC connected to MMC3 of the A20 SoC via SDIO. The IC also
takes a power enable signal via GPIO.
This commit adds a device-tree node to power it up, so the mmc subsys
can scan it, and enables the mmc controller which is connected to it.
As the wifi enable pin of the AP6181 module is not really a regulator,
switch the mmc3 node to the mmc-pwrseq framework for controlling it.
This more accurately reflectes how the hardware actually works.
Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
---
arch/arm/boot/dts/sun7i-a20-bananapro.dts | 35 ++++++++++++++++++++-----------
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
index 19d63d4049de..439ad50dcd4a 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
@@ -76,6 +76,13 @@
};
};
+ mmc3_pwrseq: mmc3_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&vmmc3_pin_bananapro>;
+ reset-gpios = <&pio 7 22 GPIO_ACTIVE_LOW>;
+ };
+
reg_gmac_3v3: gmac-3v3 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -87,17 +94,6 @@
enable-active-high;
gpio = <&pio 7 23 GPIO_ACTIVE_HIGH>;
};
-
- reg_vmmc3: vmmc3 {
- compatible = "regulator-fixed";
- pinctrl-names = "default";
- pinctrl-0 = <&vmmc3_pin_bananapro>;
- regulator-name = "vmmc3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- enable-active-high;
- gpio = <&pio 7 22 GPIO_ACTIVE_HIGH>;
- };
};
&ahci {
@@ -166,10 +162,25 @@
&mmc3 {
pinctrl-names = "default";
pinctrl-0 = <&mmc3_pins_a>;
- vmmc-supply = <®_vmmc3>;
+ vmmc-supply = <®_vcc3v3>;
+ mmc-pwrseq = <&mmc3_pwrseq>;
bus-width = <4>;
non-removable;
+ wakeup-source;
status = "okay";
+
+ brcmf: bcrmf at 1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&pio>;
+ interrupts = <7 15 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "host-wake";
+ };
+};
+
+&mmc3_pins_a {
+ /* AP6181 requires pull-up */
+ allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
};
&ohci0 {
--
2.11.0
^ permalink raw reply related
* [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR
From: Kirill A. Shutemov @ 2017-01-04 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALCETrW3=SsQeC-gWOVqwTtg022+gHei=xfUc2ei3kkX0CACpg@mail.gmail.com>
On Tue, Jan 03, 2017 at 10:27:22AM -0800, Andy Lutomirski wrote:
> On Tue, Jan 3, 2017 at 8:04 AM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
> > And what about stack? I'm not sure that everybody would be happy with
> > stack in the middle of address space.
>
> I would, personally. I think that, for very large address spaces, we
> should allocate a large block of stack and get rid of the "stack grows
> down forever" legacy idea. Then we would never need to worry about
> the stack eventually hitting some other allocation. And 2^57 bytes is
> hilariously large for a default stack.
The stack in the middle of address space can prevent creating other huuuge
contiguous mapping. Databases may want this.
--
Kirill A. Shutemov
^ permalink raw reply
* [PATCH v3 1/2] Doc: devicetree: bindings: Add vendor prefix entry - lwn
From: Rob Herring @ 2017-01-04 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483440381-24268-1-git-send-email-lukma@denx.de>
On Tue, Jan 03, 2017 at 11:46:20AM +0100, Lukasz Majewski wrote:
> This patch adds entry for LWN - the Liebherr-Werk Nenzing GmbH company to
> vendor-prefixes.txt file.
>
> Signed-off-by: Lukasz Majewski <lukma@denx.de>
> ---
> Changes for v3:
> - Update to v4.10-rc2
>
> Changes for v2:
> - New patch
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
I guess LWN.net will never make any devices...
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/4] input: Add support for the tm2 touchkey device driver
From: Rob Herring @ 2017-01-04 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483430237-26823-2-git-send-email-jcsing.lee@samsung.com>
On Tue, Jan 03, 2017 at 04:57:14PM +0900, Jaechul Lee wrote:
> This patch adds the binding description of the tm2 touchkey
> device driver.
>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> ---
> .../bindings/input/samsung,tm2-touchkey.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/samsung,tm2-touchkey.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/3] nvmem: imx-ocotp: Add support for i.MX6UL
From: Srinivas Kandagatla @ 2017-01-04 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480689949-17957-1-git-send-email-d.schultz@phytec.de>
On 02/12/16 14:45, Daniel Schultz wrote:
> This patch adds OCOTP support for the i.MX6UL SoC.
>
> Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
As Shawn said, there is already a similar patch in the mailing list
http://www.spinics.net/lists/arm-kernel/msg543203.html
http://www.spinics.net/lists/arm-kernel/msg543204.html
I will pick that patch + I will queue up fix from you "[PATCH 3/3]
nvmem: imx-ocotp: Fix wrong register size"
thanks,
srini
> ---
> Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 5 +++--
> drivers/nvmem/imx-ocotp.c | 1 +
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> index 383d588..fcb1a48 100644
> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> @@ -1,13 +1,14 @@
> Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings
>
> This binding represents the on-chip eFuse OTP controller found on
> -i.MX6Q/D, i.MX6DL/S, i.MX6SL, and i.MX6SX SoCs.
> +i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX and i.MX6UL SoCs.
>
> Required properties:
> - compatible: should be one of
> "fsl,imx6q-ocotp" (i.MX6Q/D/DL/S),
> "fsl,imx6sl-ocotp" (i.MX6SL), or
> - "fsl,imx6sx-ocotp" (i.MX6SX), followed by "syscon".
> + "fsl,imx6sx-ocotp" (i.MX6SX), or
> + "fsl,imx6ul-ocotp" (i.MX6UL), followed by "syscon".
> - reg: Should contain the register base and length.
> - clocks: Should contain a phandle pointing to the gated peripheral clock.
>
> diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
> index ac27b9b..d2f78d3 100644
> --- a/drivers/nvmem/imx-ocotp.c
> +++ b/drivers/nvmem/imx-ocotp.c
> @@ -71,6 +71,7 @@ static int imx_ocotp_read(void *context, unsigned int offset,
>
> static const struct of_device_id imx_ocotp_dt_ids[] = {
> { .compatible = "fsl,imx6q-ocotp", (void *)128 },
> + { .compatible = "fsl,imx6ul-ocotp", (void *)128 },
> { .compatible = "fsl,imx6sl-ocotp", (void *)32 },
> { .compatible = "fsl,imx6sx-ocotp", (void *)128 },
> { },
>
^ permalink raw reply
* [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap
From: Auger Eric @ 2017-01-04 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ecb7ddf6-074f-50e4-6402-d59ceb1edd1d@arm.com>
Hi Marc,
On 04/01/2017 14:46, Marc Zyngier wrote:
> Hi Eric,
>
> On 04/01/17 13:32, Eric Auger wrote:
>> This new function checks whether all platform and PCI
>> MSI 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>
>>
>> ---
>>
>> v4 -> v5:
>> - Handle DOMAIN_BUS_FSL_MC_MSI domains
>> - Check parents
>> ---
>> include/linux/irqdomain.h | 1 +
>> kernel/irq/irqdomain.c | 41 +++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 42 insertions(+)
>>
>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>> index ab017b2..281a40f 100644
>> --- a/include/linux/irqdomain.h
>> +++ b/include/linux/irqdomain.h
>> @@ -219,6 +219,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 8c0a0ae..700caea 100644
>> --- a/kernel/irq/irqdomain.c
>> +++ b/kernel/irq/irqdomain.c
>> @@ -278,6 +278,47 @@ struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec *fwspec,
>> EXPORT_SYMBOL_GPL(irq_find_matching_fwspec);
>>
>> /**
>> + * irq_domain_is_msi_remap - Check if @domain or any parent
>> + * has MSI remapping support
>> + * @domain: domain pointer
>> + */
>> +static bool irq_domain_is_msi_remap(struct irq_domain *domain)
>> +{
>> + struct irq_domain *h = domain;
>> +
>> + for (; h; h = h->parent) {
>> + if (h->flags & IRQ_DOMAIN_FLAG_MSI_REMAP)
>> + return true;
>> + }
>> + return false;
>> +}
>> +
>> +/**
>> + * irq_domain_check_msi_remap() - Checks 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 (((h->bus_token & DOMAIN_BUS_PCI_MSI) ||
>> + (h->bus_token & DOMAIN_BUS_PLATFORM_MSI) ||
>> + (h->bus_token & DOMAIN_BUS_FSL_MC_MSI)) &&
>> + !irq_domain_is_msi_remap(h)) {
>
> (h->bus_token & DOMAIN_BUS_PCI_MSI) and co looks quite wrong. bus_token
> is not a bitmap, and DOMAIN_BUS_* not a single bit value (see enum
> irq_domain_bus_token). Surely this should read
> (h->bus_token == DOMAIN_BUS_PCI_MSI).
Oh I did not notice that. Thanks.
Any other comments on the irqdomain side? Do you think the current
approach consisting in looking at those bus tokens and their parents
looks good?
Thanks
Eric
>
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH 2/5] drivers: mmc: sunxi: limit A64 MMC2 to 8K DMA buffer
From: Rob Herring @ 2017-01-04 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483398226-29321-3-git-send-email-andre.przywara@arm.com>
On Mon, Jan 02, 2017 at 11:03:43PM +0000, Andre Przywara wrote:
> From: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Unlike the A64 user manual reports, the third MMC controller on the
> A64 (and the only one capable of 8-bit HS400 eMMC transfers) has a
> DMA buffer size limit of 8KB (much like the very old Allwinner SoCs).
> This does not affect the other two controllers, so introduce a new
> DT compatible string to let the driver use different settings for that
> particular device. This will also help to enable the high-speed transfer
> modes of that controller later.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 1 +
> drivers/mmc/host/sunxi-mmc.c | 7 +++++++
> 2 files changed, 8 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ 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