* [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 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 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] 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 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 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
* [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
* [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
* [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
* [PATCH] arm64: Don't trace __switch_to if function graph tracer is enabled
From: Will Deacon @ 2017-01-04 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482360288-124624-1-git-send-email-joelaf@google.com>
On Wed, Dec 21, 2016 at 02:44:46PM -0800, Joel Fernandes wrote:
> Function graph tracer shows negative time (wrap around) when tracing
> __switch_to if the nosleep-time trace option is enabled.
>
> Time compensation for nosleep-time is done by an ftrace probe on
> sched_switch. This doesn't work well for the following events (with
> letters representing timestamps):
> A - sched switch probe called for task T switch out
> B - __switch_to calltime is recorded
> C - sched_switch probe called for task T switch in
> D - __switch_to rettime is recorded
>
> If C - A > D - B, then we end up over compensating for the time spent in
> __switch_to giving rise to negative times in the trace output.
>
> On x86, __switch_to is not traced if function graph tracer is enabled.
> Do the same for arm64 as well.
>
> Cc: Todd Kjos <tkjos@google.com>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Joel Fernandes <joelaf@google.com>
> ---
> arch/arm64/kernel/process.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks, queued for 4.11.
Will
^ permalink raw reply
* [GIT PULL] ARM: exynos: Late mach/soc for v4.10
From: Arnd Bergmann @ 2017-01-04 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482003132-8844-1-git-send-email-krzk@kernel.org>
On Saturday, December 17, 2016 9:32:12 PM CET Krzysztof Kozlowski wrote:
> After our discussions about not-breaking out-of-tree DTB with SCU
> change in DeviceTree, I prepared an updated pull request without
> the questioned changes.
>
> Ten days ago I prepared a tag, pushed it... and apparently forgot to send pull
> request. At least, I don't have such email in my outbox. Dunno.
>
> So let's send it now, better late then never. With just few commits (without
> the DT SCU changes). These were sitting in the next for very long.
Sorry for the delay. The patches in here are all straightforward, so
I'm applying them for fixes now.
Arnd
^ permalink raw reply
* [PATCH] arm64: mm: fix show_pte KERN_CONT fallout
From: Will Deacon @ 2017-01-04 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483453646-13617-1-git-send-email-mark.rutland@arm.com>
On Tue, Jan 03, 2017 at 02:27:26PM +0000, Mark Rutland wrote:
> Recent changes made KERN_CONT mandatory for continued lines. In the
> absence of KERN_CONT, a newline may be implicit inserted by the core
> printk code.
>
> In show_pte, we (erroneously) use printk without KERN_CONT for continued
> prints, resulting in output being split across a number of lines, and
> not matching the intended output, e.g.
>
> [ff000000000000] *pgd=00000009f511b003
> , *pud=00000009f4a80003
> , *pmd=0000000000000000
>
> Fix this by using pr_cont() for all the continuations.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/mm/fault.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Acked-by: Will Deacon <will.deacon@arm.com>
Catalin can pick this one up for 4.10.
Will
^ permalink raw reply
* [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface
From: Will Deacon @ 2017-01-04 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103173456.18154-1-lorenzo.pieralisi@arm.com>
On Tue, Jan 03, 2017 at 05:34:56PM +0000, 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.
>
> 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(-)
Thanks for following up with this cleanup, Lorenzo. I'll queue it locally,
and send it to Joerg for 4.11 if he doesn't apply it manually before then.
Will
^ permalink raw reply
* [PATCH] arm64: restore get_current() optimisation
From: Will Deacon @ 2017-01-04 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483468021-8237-1-git-send-email-mark.rutland@arm.com>
On Tue, Jan 03, 2017 at 06:27:01PM +0000, Mark Rutland wrote:
> Hi Catalin,
>
> My THREAD_INFO_IN_TASK series had an unintended performance regression in
> get_current() / current_thread_info(). Could you please take the below as a
> fix for the next rc?
>
> Thanks,
> Mark.
>
> ---->8----
> Commit c02433dd6de32f04 ("arm64: split thread_info from task stack")
> inverted the relationship between get_current() and
> current_thread_info(), with sp_el0 now holding the current task_struct
> rather than the current thead_info. The new implementation of
> get_current() prevents the compiler from being able to optimize repeated
> calls to either, resulting in a noticeable penalty in some
> microbenchmarks.
>
> This patch restores the previous optimisation by implementing
> get_current() in the same way as our old current_thread_info(), using a
> non-volatile asm statement.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reported-by: Davidlohr Bueso <dbueso@suse.de>
> ---
> arch/arm64/include/asm/current.h | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
Acked-by: Will Deacon <will.deacon@arm.com>
Thanks for putting this back like it was!
Will
^ permalink raw reply
* [PATCH v4 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Rob Herring @ 2017-01-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483536954-27203-3-git-send-email-appanad@xilinx.com>
On Wed, Jan 04, 2017 at 07:05:53PM +0530, Kedareswara rao Appana wrote:
> When VDMA is configured for more than one frame in the h/w
> for example h/w is configured for n number of frames and user
> Submits n number of frames and triggered the DMA using issue_pending API.
> In the current driver flow we are submitting one frame at a time
> but we should submit all the n number of frames at one time as the h/w
> Is configured for n number of frames.
Please fix run-on sentences, capitalization, and word wrapping.
>
> This patch fixes this issue.
>
> Reviewed-by: Jose Abreu <joabreu@synopsys.com>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> Changes for v4:
> ---> Add Check for framestore configuration on Transmit case as well
> as suggested by Jose Abreu.
> ---> Modified the dev_dbg checks to dev_warn checks as suggested
> by Jose Abreu.
> Changes for v3:
> ---> Added Checks for frame store configuration. If frame store
> Configuration is not present at the h/w level and user
> Submits less frames added debug prints in the driver as relevant.
> Changes for v2:
> ---> Fixed race conditions in the driver as suggested by Jose Abreu
> ---> Fixed unnecessray if else checks in the vdma_start_transfer
> as suggested by Laurent Pinchart.
>
> .../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 2 +
> drivers/dma/xilinx/xilinx_dma.c | 79 +++++++++++++++-------
> 2 files changed, 58 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> index a2b8bfa..1f65e09 100644
> --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> @@ -66,6 +66,8 @@ Optional child node properties:
> Optional child node properties for VDMA:
> - xlnx,genlock-mode: Tells Genlock synchronization is
> enabled/disabled in hardware.
> +- xlnx,fstore-config: Tells Whether Frame Store Configuration is
> + enabled/disabled in hardware.
What's the default (when not present)? That should be the most
common case. Looks like the code treats this as bool, but that's
not clear here. The name is not clear what it is doing. Enabling or
disabling the feature?
> Optional child node properties for AXI DMA:
> -dma-channels: Number of dma channels in child node.
>
^ permalink raw reply
* [PATCH v2 05/19] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
From: Fabio Estevam @ 2017-01-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483477049-19056-6-git-send-email-steve_longerbeam@mentor.com>
On Tue, Jan 3, 2017 at 6:57 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> + camera: ov5642 at 3c {
> + compatible = "ovti,ov5642";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ov5642>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + clock-names = "xclk";
> + reg = <0x3c>;
> + xclk = <24000000>;
> + DOVDD-supply = <&vgen4_reg>; /* 1.8v */
> + AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
> + rev B board is VGEN5 */
Please use vgen3 so that by default we have the valid AVDD-supply for
revC boards which is more recent and more the users have access to.
> + mipi_camera: ov5640 at 3c {
> + compatible = "ovti,ov5640_mipi";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ov5640>;
> + reg = <0x3c>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + clock-names = "xclk";
> + xclk = <24000000>;
> + DOVDD-supply = <&vgen4_reg>; /* 1.8v */
> + AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
> + rev B board is VGEN5 */
Same here.
> + pinctrl_ov5640: ov5640grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x80000000
> + MX6QDL_PAD_SD1_CLK__GPIO1_IO20 0x80000000
Please avoid all the 0x80000000 IOMUX settings and replace them by
their real values.
^ permalink raw reply
* [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap
From: Marc Zyngier @ 2017-01-04 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <df8e7fdb-4048-3169-c758-c2a64119a321@redhat.com>
On 04/01/17 14:11, Auger Eric wrote:
> 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?
To be completely honest, I don't like it much, as having to enumerate
all the bus types can come up with could become quite a burden in the
long run. I'd rather be able to identify MSI capable domains by
construction. I came up with the following approach (fully untested):
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 281a40f..7779796 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -183,8 +183,11 @@ 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 is MSI remapping capable */
- IRQ_DOMAIN_FLAG_MSI_REMAP = (1 << 4),
+ IRQ_DOMAIN_FLAG_MSI_REMAP = (1 << 5),
/*
* Flags starting from IRQ_DOMAIN_FLAG_NONCORE are reserved
@@ -450,6 +453,11 @@ 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;
+}
#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) { }
@@ -481,6 +489,11 @@ 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;
+}
#endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */
#else /* CONFIG_IRQ_DOMAIN */
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 700caea..33b6921 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -304,10 +304,7 @@ bool irq_domain_check_msi_remap(void)
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)) {
+ if (irq_domain_is_msi(h) && !irq_domain_is_msi_remap(h)) {
ret = false;
goto out;
}
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index ee23006..b637263 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -270,7 +270,7 @@ 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,
+ return irq_domain_create_hierarchy(parent, IRQ_DOMAIN_FLAG_MSI, 0, fwnode,
&msi_domain_ops, info);
}
Thoughts?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Nikita Yushchenko @ 2017-01-04 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3158203.Yc9Qgx82xo@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?
>
> 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.
Well anyway applying patch similar to your's will fix pcie-rcar + nvme
case - thus I don't object :) But it can break other cases ...
But why do you hook at set_dma_mask() and overwrite mask inside, instead
of hooking at dma_supported() and rejecting unsupported mask?
I think later is better, because it lets drivers to handle unsupported
high-dma case, like documented in DMA-API_HOWTO.
^ permalink raw reply
* [PATCH v3] i2c: designware: add reset interface
From: Andy Shevchenko @ 2017-01-04 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2921529.fKUMSWjgsl@wuerfel>
On Wed, 2017-01-04 at 15:55 +0100, Arnd Bergmann wrote:
> 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.
Which means that reset framework whenever work _optional is used should
return error iff (mind two f:s) there is a problem with existing
control.
>
> > @@ -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.
Please, fix reset framework first than.
For my understanding:
It should return NULL for optional reset control.
It should not fail on NULL argument.
> 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
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [GIT PULL] firmware: SCPI: fixes for v4.10
From: Arnd Bergmann @ 2017-01-04 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11909baf-8ab3-7e53-ef22-2988571392f5@arm.com>
On Tuesday, January 3, 2017 10:28:00 AM CET Sudeep Holla wrote:
> SCPI fix for v4.10
>
> A simple fix for reading only lower 32-bit sensor values on pre-1.0 SCPI
> firmwares so that upper 32-bit (garbage) value is discarded properly.
>
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Qualcomm ARM DT Fixes for 4.10-rc2
From: Arnd Bergmann @ 2017-01-04 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483387434-4655-1-git-send-email-andy.gross@linaro.org>
On Monday, January 2, 2017 2:03:54 PM CET Andy Gross wrote:
> Qualcomm ARM DTS Fixes for v4.10-rc2
>
> * Add SCM clock for APQ8064 to fix boot failures
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: dts: vexpress: fixes for v4.10
From: Arnd Bergmann @ 2017-01-04 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4df20b4c-3f07-5f1a-2f62-df090aa0cbd6@arm.com>
On Tuesday, January 3, 2017 10:30:47 AM CET Sudeep Holla wrote:
> ARMv7 VExpress fixes for v4.10
>
> A simple fix to extend GICv2 CPU interface registers from 4K to 8K
> on VExpress TC1 and TC2 platforms in order to support split priority
> drop and interrupt deactivation.
>
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] arm64: dts: vexpress: fixes for v4.10
From: Arnd Bergmann @ 2017-01-04 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <252d452b-49a3-6c62-b299-ed7a2abbf538@arm.com>
On Tuesday, January 3, 2017 10:31:52 AM CET Sudeep Holla wrote:
> ARMv8 Juno/VExpress fixes for v4.10
>
> A simple fix to extend GICv2 CPU interface registers from 4K to 8K
> on AEMv8 FVP/RTSM models in order to support split priority drop and
> interrupt deactivation.
>
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] drivers: firmware: PSCI fixes for v4.10
From: Arnd Bergmann @ 2017-01-04 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103185052.GA23238@e107981-lin.cambridge.arm.com>
On Tuesday, January 3, 2017 6:50:52 PM CET Lorenzo Pieralisi wrote:
> PSCI fixes for v4.10
>
> Two minor fixes following the merge of the PSCI checker:
>
> - Annotate the PSCI checker timer on the stack used to wake-up from
> suspend to prevent warnings when the DEBUG_OBJECTS config option
> is enabled
> - Extend the PSCI entry in the maintainers list to also include the
> PSCI checker code
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Amlogic fixes for v4.10-rc
From: Arnd Bergmann @ 2017-01-04 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hk2abgzgb.fsf@baylibre.com>
On Tuesday, January 3, 2017 9:35:00 PM CET Kevin Hilman wrote:
> This pull has one real fix, as a couple non-critical ones. The DRM
> DT/defconfig patches are coming now because I didn't expect the new
> driver to make it for the v4.10 merge window, but since it did[1], the
> DT and defconfig should go into the same release.
>
Pulled into fixes, thanks!
Arnd
^ 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