* [PATCH] arm64: dts: renesas: r8a7796: Add PCIe device nodes
From: Simon Horman @ 2018-06-08 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605080336.5xt64komcjbqbt7k@verge.net.au>
On Tue, Jun 05, 2018 at 10:03:37AM +0200, Simon Horman wrote:
> On Tue, Jun 05, 2018 at 02:49:08AM +0900, Yoshihiro Kaneko wrote:
> > From: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
> >
> > This patch adds PCIe{0,1} device nodes for R8A7796 SoC.
> >
> > Signed-off-by: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
> > Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> > Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>
> Hi,
>
> This looks fine to me but I will wait to see if there are other reviews
> before applying.
>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Thanks Kaneko-san, applied.
^ permalink raw reply
* [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
From: Simon Horman @ 2018-06-08 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <390fabf0-4caf-1600-3780-1893207d94f7@cogentembedded.com>
On Thu, Jun 07, 2018 at 11:17:03PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20180604-v4.17' tag. We're adding the R8A77980 FCPVD/VSPD/
> DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder
> connected to the LVDS output. These patches depend on the Thine THC63LVD1024
> driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO
> DT patches in order to apply/compile...
>
> [1/5] arm64: dts: renesas: r8a77980: add FCPVD support
> [2/5] arm64: dts: renesas: r8a77980: add VSPD support
> [3/5] arm64: dts: renesas: r8a77980: add DU support
> [4/5] arm64: dts: renesas: r8a77980: add LVDS support
> [5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
Sergei,
what are the changes in this series between v1 and v2?
^ permalink raw reply
* [PATCH 1/3] arm64: dts: renesas: r8a77980: add GPIO support
From: Simon Horman @ 2018-06-08 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdU4smhy0Z6YUVP2wr+YnJof=eW86Q9jN47r0yo3VEsB9A@mail.gmail.com>
On Wed, Jun 06, 2018 at 11:07:27AM +0200, Geert Uytterhoeven wrote:
> On Fri, Jun 1, 2018 at 10:44 PM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
> > Describe all 6 GPIO controllers in the R8A77980 device tree.
> >
> > Based on the original (and large) patch by Vladimir Barinov.
> >
> > Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks Sergei, applied.
^ permalink raw reply
* [PATCH] ASoC: rockchip: add config for rockchip dmaengine pcm register
From: Jianqun Xu @ 2018-06-08 8:31 UTC (permalink / raw)
To: linux-arm-kernel
This patch makes the rockchip i2s pcm configurable by adding
rockchip pcm config for devm_snd_dmaengine_pcm_register.
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
---
sound/soc/rockchip/Makefile | 3 ++-
sound/soc/rockchip/rockchip_i2s.c | 3 ++-
sound/soc/rockchip/rockchip_pcm.c | 45 +++++++++++++++++++++++++++++++++++++++
sound/soc/rockchip/rockchip_pcm.h | 14 ++++++++++++
4 files changed, 63 insertions(+), 2 deletions(-)
create mode 100644 sound/soc/rockchip/rockchip_pcm.c
create mode 100644 sound/soc/rockchip/rockchip_pcm.h
diff --git a/sound/soc/rockchip/Makefile b/sound/soc/rockchip/Makefile
index 05b078e..65e814d 100644
--- a/sound/soc/rockchip/Makefile
+++ b/sound/soc/rockchip/Makefile
@@ -1,10 +1,11 @@
# SPDX-License-Identifier: GPL-2.0
# ROCKCHIP Platform Support
snd-soc-rockchip-i2s-objs := rockchip_i2s.o
+snd-soc-rockchip-pcm-objs := rockchip_pcm.o
snd-soc-rockchip-pdm-objs := rockchip_pdm.o
snd-soc-rockchip-spdif-objs := rockchip_spdif.o
-obj-$(CONFIG_SND_SOC_ROCKCHIP_I2S) += snd-soc-rockchip-i2s.o
+obj-$(CONFIG_SND_SOC_ROCKCHIP_I2S) += snd-soc-rockchip-i2s.o snd-soc-rockchip-pcm.o
obj-$(CONFIG_SND_SOC_ROCKCHIP_PDM) += snd-soc-rockchip-pdm.o
obj-$(CONFIG_SND_SOC_ROCKCHIP_SPDIF) += snd-soc-rockchip-spdif.o
diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c
index 908211e..5e60181 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -22,6 +22,7 @@
#include <sound/dmaengine_pcm.h>
#include "rockchip_i2s.h"
+#include "rockchip_pcm.h"
#define DRV_NAME "rockchip-i2s"
@@ -667,7 +668,7 @@ static int rockchip_i2s_probe(struct platform_device *pdev)
goto err_suspend;
}
- ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
+ ret = rockchip_pcm_platform_register(&pdev->dev);
if (ret) {
dev_err(&pdev->dev, "Could not register PCM\n");
return ret;
diff --git a/sound/soc/rockchip/rockchip_pcm.c b/sound/soc/rockchip/rockchip_pcm.c
new file mode 100644
index 0000000..f775383
--- /dev/null
+++ b/sound/soc/rockchip/rockchip_pcm.c
@@ -0,0 +1,45 @@
+/*
+ * Copyright (c) 2018 Rockchip Electronics Co. Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/module.h>
+
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/soc.h>
+#include <sound/dmaengine_pcm.h>
+
+#include "rockchip_pcm.h"
+
+static const struct snd_pcm_hardware snd_rockchip_hardware = {
+ .info = SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID |
+ SNDRV_PCM_INFO_PAUSE |
+ SNDRV_PCM_INFO_RESUME,
+ .period_bytes_min = 32,
+ .period_bytes_max = 8192,
+ .periods_min = 1,
+ .periods_max = 52,
+ .buffer_bytes_max = 64 * 1024,
+ .fifo_size = 32,
+};
+
+static const struct snd_dmaengine_pcm_config rk_dmaengine_pcm_config = {
+ .pcm_hardware = &snd_rockchip_hardware,
+ .prealloc_buffer_size = 32 * 1024,
+};
+
+int rockchip_pcm_platform_register(struct device *dev)
+{
+ return devm_snd_dmaengine_pcm_register(dev, &rk_dmaengine_pcm_config,
+ SND_DMAENGINE_PCM_FLAG_COMPAT);
+}
+EXPORT_SYMBOL_GPL(rockchip_pcm_platform_register);
+
+MODULE_LICENSE("GPL v2");
diff --git a/sound/soc/rockchip/rockchip_pcm.h b/sound/soc/rockchip/rockchip_pcm.h
new file mode 100644
index 0000000..d6c3611
--- /dev/null
+++ b/sound/soc/rockchip/rockchip_pcm.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright (c) 2018 Rockchip Electronics Co. Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _ROCKCHIP_PCM_H
+#define _ROCKCHIP_PCM_H
+
+int rockchip_pcm_platform_register(struct device *dev);
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v4 8/9] drm/mediatek: add third ddp path
From: Stu Hsieh @ 2018-06-08 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527493677.24367.10.camel@mtksdaap41>
On Mon, 2018-05-28 at 15:47 +0800, CK Hu wrote:
> Hi, Stu:
>
> One inline comment.
>
> On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> > This patch create third crtc by third ddp path
> >
> > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +++++
> > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +++++--
> > 3 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 658b8dd45b83..2d6aa150a9ff 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -539,6 +539,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > int ret;
> > int i;
> >
> > + if (!path)
> > + return 0;
> > +
> > for (i = 0; i < path_len; i++) {
> > enum mtk_ddp_comp_id comp_id = path[i];
> > struct device_node *node;
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 08d5d0b47bfe..3d279a299383 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -232,6 +232,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > if (ret < 0)
> > goto err_component_unbind;
> >
> > + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> > + private->data->third_len);
> > + if (ret < 0)
> > + goto err_component_unbind;
> > +
> > /* Use OVL device for all DMA memory allocations */
> > np = private->comp_node[private->data->main_path[0]] ?:
> > private->comp_node[private->data->ext_path[0]];
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > index c3378c452c0a..d867e2683923 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > @@ -17,8 +17,8 @@
> > #include <linux/io.h>
> > #include "mtk_drm_ddp_comp.h"
> >
> > -#define MAX_CRTC 2
> > -#define MAX_CONNECTOR 2
> > +#define MAX_CRTC 3
> > +#define MAX_CONNECTOR 3
>
> MAX_CONNECTOR is useless, maybe we just need to remove it in a clean up
> patch. Or you could keep its value.
ok
For this patch, I would keep its value.
Regards,
Stu
>
> Regards,
> CK
>
> >
> > struct device;
> > struct device_node;
> > @@ -33,6 +33,9 @@ struct mtk_mmsys_driver_data {
> > unsigned int main_len;
> > const enum mtk_ddp_comp_id *ext_path;
> > unsigned int ext_len;
> > + const enum mtk_ddp_comp_id *third_path;
> > + unsigned int third_len;
> > +
> > bool shadow_register;
> > };
> >
>
>
^ permalink raw reply
* [PATCH v2 2/2] KVM: arm/arm64: harden unmap_stage2_ptes in case end is not PAGE_SIZE aligned
From: Christoffer Dall @ 2018-06-08 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50c98169-1606-48bf-0489-124adefd2a54@gmail.com>
On Fri, May 18, 2018 at 09:04:40PM +0800, Jia He wrote:
>
>
> On 5/18/2018 5:48 PM, Marc Zyngier Wrote:
> > On 18/05/18 10:27, Jia He wrote:
> >> If it passes addr=0x202920000,size=0xfe00 to unmap_stage2_range->
> >> ...->unmap_stage2_ptes, unmap_stage2_ptes will get addr=0x202920000,
> >> end=0x20292fe00. After first while loop addr=0x202930000, end=0x20292fe00,
> >> then addr!=end. Thus it will touch another pages by put_pages() in the
> >> 2nd loop.
> >>
> >> This patch fixes it by hardening the break condition of while loop.
> >>
> >> Signed-off-by: jia.he at hxt-semitech.com
> >> ---
> >> v2: newly added
> >>
> >> virt/kvm/arm/mmu.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> >> index 8dac311..45cd040 100644
> >> --- a/virt/kvm/arm/mmu.c
> >> +++ b/virt/kvm/arm/mmu.c
> >> @@ -217,7 +217,7 @@ static void unmap_stage2_ptes(struct kvm *kvm, pmd_t *pmd,
> >>
> >> put_page(virt_to_page(pte));
> >> }
> >> - } while (pte++, addr += PAGE_SIZE, addr != end);
> >> + } while (pte++, addr += PAGE_SIZE, addr < end);
> >>
> >> if (stage2_pte_table_empty(start_pte))
> >> clear_stage2_pmd_entry(kvm, pmd, start_addr);
> >>
> >
> > I don't think this change is the right thing to do. You get that failure
> > because you're being passed a size that is not a multiple of PAGE_SIZE.
> > That's the mistake.
> >
> > You should ensure that this never happens, rather than changing the page
> > table walkers (which are consistent with the way this kind of code is
> > written in other places of the kernel). As you mentioned in your first
> > patch, the real issue is that KSM is broken, and this is what should be
> > fixed.
> >
> Got it, thanks
> Should I resend the patch 1/2 without any changes after droping patch 2/2?
>
That's fine if you trim the commit message to make it look nicer.
Also, in the future, please include a cover letter if you send more than
one patch to the list.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v4 9/9] drm/mediatek: Add support for mediatek SOC MT2712
From: Stu Hsieh @ 2018-06-08 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527494014.24367.14.camel@mtksdaap41>
Hi, CK:
On Mon, 2018-05-28 at 15:53 +0800, CK Hu wrote:
> Hi, Stu:
>
> Two inline comment.
>
> On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> > This patch add support for the Mediatek MT2712 DISP subsystem.
> > There are two OVL engine and three disp output in MT2712.
> >
> > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 39 ++++++++++++++++++++++++++++++++++
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 +++++++++++++++++++++++++++++++++
> > 2 files changed, 77 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > index 8bfc0debd2c2..3b22b48a6022 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > @@ -61,6 +61,24 @@
> > #define MT8173_MUTEX_MOD_DISP_PWM1 24
> > #define MT8173_MUTEX_MOD_DISP_OD 25
> >
> > +#define MT2712_MUTEX_MOD_DISP_PWM2 10
> > +#define MT2712_MUTEX_MOD_DISP_OVL0 11
> > +#define MT2712_MUTEX_MOD_DISP_OVL1 12
> > +#define MT2712_MUTEX_MOD_DISP_RDMA0 13
> > +#define MT2712_MUTEX_MOD_DISP_RDMA1 14
> > +#define MT2712_MUTEX_MOD_DISP_RDMA2 15
> > +#define MT2712_MUTEX_MOD_DISP_WDMA0 16
> > +#define MT2712_MUTEX_MOD_DISP_WDMA1 17
> > +#define MT2712_MUTEX_MOD_DISP_COLOR0 18
> > +#define MT2712_MUTEX_MOD_DISP_COLOR1 19
> > +#define MT2712_MUTEX_MOD_DISP_AAL0 20
> > +#define MT2712_MUTEX_MOD_DISP_UFOE 22
> > +#define MT2712_MUTEX_MOD_DISP_PWM0 23
> > +#define MT2712_MUTEX_MOD_DISP_PWM1 24
> > +#define MT2712_MUTEX_MOD_DISP_OD0 25
> > +#define MT2712_MUTEX_MOD2_DISP_AAL1 33
> > +#define MT2712_MUTEX_MOD2_DISP_OD1 34
> > +
> > #define MT2701_MUTEX_MOD_DISP_OVL 3
> > #define MT2701_MUTEX_MOD_DISP_WDMA 6
> > #define MT2701_MUTEX_MOD_DISP_COLOR 7
> > @@ -110,6 +128,26 @@ static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> > };
> >
> > +static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > + [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
> > + [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
> > + [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
> > + [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
> > + [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
> > + [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
> > + [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
> > + [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
> > + [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
> > + [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
> > + [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
> > + [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
> > + [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
> > + [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
> > + [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
> > + [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
> > + [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
> > +};
> > +
> > static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
> > [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> > @@ -430,6 +468,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
> >
> > static const struct of_device_id ddp_driver_dt_match[] = {
> > { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
> > + { .compatible = "mediatek,mt2712-disp-mutex", .data = mt2712_mutex_mod},
> > { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
> > {},
> > };
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 3d279a299383..3a866e1d6af4 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -146,6 +146,32 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
> > DDP_COMPONENT_DPI0,
> > };
> >
> > +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
> > + DDP_COMPONENT_OVL0,
> > + DDP_COMPONENT_COLOR0,
> > + DDP_COMPONENT_AAL0,
> > + DDP_COMPONENT_OD0,
> > + DDP_COMPONENT_RDMA0,
> > + DDP_COMPONENT_DPI0,
> > + DDP_COMPONENT_PWM0,
> > +};
> > +
> > +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_ext[] = {
> > + DDP_COMPONENT_OVL1,
> > + DDP_COMPONENT_COLOR1,
> > + DDP_COMPONENT_AAL1,
> > + DDP_COMPONENT_OD1,
> > + DDP_COMPONENT_RDMA1,
> > + DDP_COMPONENT_DPI1,
>
> Where do you define DDP_COMPONENT_DPI1?
>
> > + DDP_COMPONENT_PWM1,
> > +};
> > +
> > +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] = {
> > + DDP_COMPONENT_RDMA2,
> > + DDP_COMPONENT_DSI2,
>
> Where do you define DDP_COMPONENT_DSI2?
>
I would add another patch for these component in next version patch
series.And add some connection patch from RDMAx to
DPI0/DPI1/DSI1/DSI2/DSI3.
Regards,
Stu
> Regards,
> CK
>
> > + DDP_COMPONENT_PWM2,
> > +};
> > +
> > static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> > DDP_COMPONENT_OVL0,
> > DDP_COMPONENT_COLOR0,
> > @@ -173,6 +199,15 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> > .shadow_register = true,
> > };
> >
> > +static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
> > + .main_path = mt2712_mtk_ddp_main,
> > + .main_len = ARRAY_SIZE(mt2712_mtk_ddp_main),
> > + .ext_path = mt2712_mtk_ddp_ext,
> > + .ext_len = ARRAY_SIZE(mt2712_mtk_ddp_ext),
> > + .third_path = mt2712_mtk_ddp_third,
> > + .third_len = ARRAY_SIZE(mt2712_mtk_ddp_third),
> > +};
> > +
> > static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
> > .main_path = mt8173_mtk_ddp_main,
> > .main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
> > @@ -379,6 +414,7 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> > { .compatible = "mediatek,mt8173-dsi", .data = (void *)MTK_DSI },
> > { .compatible = "mediatek,mt8173-dpi", .data = (void *)MTK_DPI },
> > { .compatible = "mediatek,mt2701-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> > + { .compatible = "mediatek,mt2712-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> > { .compatible = "mediatek,mt8173-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> > { .compatible = "mediatek,mt2701-disp-pwm", .data = (void *)MTK_DISP_BLS },
> > { .compatible = "mediatek,mt8173-disp-pwm", .data = (void *)MTK_DISP_PWM },
> > @@ -557,6 +593,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
> > static const struct of_device_id mtk_drm_of_ids[] = {
> > { .compatible = "mediatek,mt2701-mmsys",
> > .data = &mt2701_mmsys_driver_data},
> > + { .compatible = "mediatek,mt2712-mmsys",
> > + .data = &mt2712_mmsys_driver_data},
> > { .compatible = "mediatek,mt8173-mmsys",
> > .data = &mt8173_mmsys_driver_data},
> > { }
>
>
^ permalink raw reply
* [v3, 07/10] fsl/fman_port: support getting timestamp
From: kbuild test robot @ 2018-06-08 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607092050.46128-8-yangbo.lu@nxp.com>
Hi Yangbo,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on next-20180608]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Yangbo-Lu/Support-DPAA-PTP-clock-and-timestamping/20180608-131649
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/freescale/fman/fman_port.c:879:26: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:879:26: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1035:36: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1247:17: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1249:17: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1249:17: sparse: expression using sizeof(void)
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
vim +1739 drivers/net/ethernet/freescale/fman/fman_port.c
1733
1734 int fman_port_get_tstamp(struct fman_port *port, const void *data, u64 *tstamp)
1735 {
1736 if (port->buffer_offsets.time_stamp_offset == ILLEGAL_BASE)
1737 return -EINVAL;
1738
> 1739 *tstamp = be64_to_cpu(*(u64 *)(data +
1740 port->buffer_offsets.time_stamp_offset));
1741
1742 return 0;
1743 }
1744 EXPORT_SYMBOL(fman_port_get_tstamp);
1745
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH 2/3] arm64: dts: renesas: condor: specify EtherAVB PHY IRQ
From: Simon Horman @ 2018-06-08 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <049a712d-7381-c771-c352-6badc2978175@cogentembedded.com>
On Mon, Jun 04, 2018 at 05:22:52PM +0300, Sergei Shtylyov wrote:
> On 06/04/2018 01:33 PM, Simon Horman wrote:
>
> >> Specify EtherAVB PHY IRQ in the Condor board's device tree, now that
> >> we have the GPIO support (previously phylib had to resort to polling).
> >>
> >> Based on the original (and large) patch by Vladimir Barinov.
> >>
> >> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> >> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >>
> >> ---
> >> arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> >> ===================================================================
> >> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> >> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> >> @@ -59,6 +59,8 @@
> >> phy0: ethernet-phy at 0 {
> >> rxc-skew-ps = <1500>;
> >> reg = <0>;
> >> + interrupt-parent = <&gpio1>;
> >> + interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
> >
> > I don't see this documented. Perhaps I'm missing something obvious.
>
> Have you looked into the V3H PFC section for where in the GPSRs AVB_PHY_INT
> is mapped?
Thanks, I see that now.
> The Condor schematics doesn't explicitly list the GPIO for AVB_PHY_INT
> because that signal is meant to be routed thru the MAC. Unfortunately, the
> sh_eth/ravb drivers don't support the PHY interrupt (the phylib function,
> phy_mac_interrupt() reporting the PHY interrupts routed thru MAC is clearly
> inadequate as it wants the link state as an argument), so we have to resort
> to the GPIO interrupts...
Understood.
> > Or you have some extra information or newer documentation?
>
> No.
>
> > Also, given Olof Johansson's recent comments in ("Re: [GIT PULL] Renesas
> > ARM64 Based SoC DT Updates for v4.18") please consider squashing this patch
> > and the following one.
>
> Hm... note that the different Ether cores are involved in these 2 PHY IRQ
> patches. If that's OK, I can merge the patches...
Tough call. Functionally these are both ethernet even though they are
different IP cores. So I think I prefer a squash.
I have applied 1/3 of this series and will push shortly.
^ permalink raw reply
* [PATCH v2 0/5] add virt-dma support for imx-sdma
From: Sascha Hauer @ 2018-06-08 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528465490-19684-1-git-send-email-yibin.gong@nxp.com>
On Fri, Jun 08, 2018 at 09:44:45PM +0800, Robin Gong wrote:
> The legacy sdma driver has below limitations or drawbacks:
> 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
> one page size for one channel regardless of only few BDs needed
> most time. But in few cases, the max PAGE_SIZE maybe not enough.
> 2. One SDMA channel can't stop immediatley once channel disabled which
> means SDMA interrupt may come in after this channel terminated.There
> are some patches for this corner case such as commit "2746e2c389f9",
> but not cover non-cyclic.
>
> The common virt-dma overcomes the above limitations. It can alloc bd
> dynamically and free bd once this tx transfer done. No memory wasted or
> maximum limititation here, only depends on how many memory can be requested
> from kernel. For No.2, such issue can be workaround by checking if there
> is available descript("sdmac->desc") now once the unwanted interrupt
> coming. At last the common virt-dma is easier for sdma driver maintain.
>
> Change from v1:
> 1. split v1 patch into 5 patches.
> 2. remove some unnecessary condition check.
> 3. remove unneccessary 'pending' list.
>
> Robin Gong (5):
> dmaengine: imx-sdma: add virt-dma support
> Revert "dmaengine: imx-sdma: fix pagefault when channel is disabled
> during interrupt"
> dmaengine: imx-sdma: remove usless lock
> dmaengine: imx-sdma: remove the maximum limation for bd numbers
> dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
>
> drivers/dma/Kconfig | 1 +
> drivers/dma/imx-sdma.c | 392 ++++++++++++++++++++++++++++---------------------
> 2 files changed, 227 insertions(+), 166 deletions(-)
Please put the attached patch in front of your series. It makes the
virt-dma support patch smaller and thus easier to review.
Sascha
--------------------------------8<----------------------------------
>From a70ccdf780cc6fcddd2d06c4a3eb0123d4aba443 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Fri, 8 Jun 2018 10:20:18 +0200
Subject: [PATCH 1/2] dmaengine: imx-sdma: factor out a struct sdma_desc from
struct sdma_channel
This is a preparation step to make the adding of virt-dma easier.
We create a struct sdma_desc, move some fields from struct sdma_channel
there and add a pointer from the former to the latter. For now we
allocate the data statically in struct sdma_channel, but with
virt-dma support it will be dynamically allocated.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/dma/imx-sdma.c | 137 +++++++++++++++++++++++++----------------
1 file changed, 83 insertions(+), 54 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ccd03c3cedfe..556d08712f4a 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -295,6 +295,30 @@ struct sdma_context_data {
struct sdma_engine;
+/**
+ * struct sdma_desc - descriptor structor for one transfer
+ * @vd descriptor for virt dma
+ * @num_bd max NUM_BD. number of descriptors currently handling
+ * @buf_tail ID of the buffer that was processed
+ * @buf_ptail ID of the previous buffer that was processed
+ * @period_len period length, used in cyclic.
+ * @chn_real_count the real count updated from bd->mode.count
+ * @chn_count the transfer count setuped
+ * @sdmac sdma_channel pointer
+ * @bd pointer of alloced bd
+ */
+struct sdma_desc {
+ unsigned int num_bd;
+ dma_addr_t bd_phys;
+ unsigned int buf_tail;
+ unsigned int buf_ptail;
+ unsigned int period_len;
+ unsigned int chn_real_count;
+ unsigned int chn_count;
+ struct sdma_channel *sdmac;
+ struct sdma_buffer_descriptor *bd;
+};
+
/**
* struct sdma_channel - housekeeping for a SDMA channel
*
@@ -305,11 +329,10 @@ struct sdma_engine;
* @event_id0 aka dma request line
* @event_id1 for channels that use 2 events
* @word_size peripheral access size
- * @buf_tail ID of the buffer that was processed
- * @buf_ptail ID of the previous buffer that was processed
- * @num_bd max NUM_BD. number of descriptors currently handling
*/
struct sdma_channel {
+ struct sdma_desc *desc;
+ struct sdma_desc _desc;
struct sdma_engine *sdma;
unsigned int channel;
enum dma_transfer_direction direction;
@@ -317,12 +340,6 @@ struct sdma_channel {
unsigned int event_id0;
unsigned int event_id1;
enum dma_slave_buswidth word_size;
- unsigned int buf_tail;
- unsigned int buf_ptail;
- unsigned int num_bd;
- unsigned int period_len;
- struct sdma_buffer_descriptor *bd;
- dma_addr_t bd_phys;
unsigned int pc_from_device, pc_to_device;
unsigned int device_to_device;
unsigned long flags;
@@ -332,10 +349,8 @@ struct sdma_channel {
u32 shp_addr, per_addr;
struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor desc;
+ struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- unsigned int chn_count;
- unsigned int chn_real_count;
struct tasklet_struct tasklet;
struct imx_dma_data data;
bool enabled;
@@ -398,6 +413,8 @@ struct sdma_engine {
u32 spba_start_addr;
u32 spba_end_addr;
unsigned int irq;
+ dma_addr_t bd0_phys;
+ struct sdma_buffer_descriptor *bd0;
};
static struct sdma_driver_data sdma_imx31 = {
@@ -632,7 +649,7 @@ static int sdma_run_channel0(struct sdma_engine *sdma)
static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,
u32 address)
{
- struct sdma_buffer_descriptor *bd0 = sdma->channel[0].bd;
+ struct sdma_buffer_descriptor *bd0 = sdma->bd0;
void *buf_virt;
dma_addr_t buf_phys;
int ret;
@@ -707,7 +724,9 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
* call callback function.
*/
while (1) {
- bd = &sdmac->bd[sdmac->buf_tail];
+ struct sdma_desc *desc = sdmac->desc;
+
+ bd = &desc->bd[desc->buf_tail];
if (bd->mode.status & BD_DONE)
break;
@@ -723,11 +742,11 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
* the number of bytes present in the current buffer descriptor.
*/
- sdmac->chn_real_count = bd->mode.count;
+ desc->chn_real_count = bd->mode.count;
bd->mode.status |= BD_DONE;
- bd->mode.count = sdmac->period_len;
- sdmac->buf_ptail = sdmac->buf_tail;
- sdmac->buf_tail = (sdmac->buf_tail + 1) % sdmac->num_bd;
+ bd->mode.count = desc->period_len;
+ desc->buf_ptail = desc->buf_tail;
+ desc->buf_tail = (desc->buf_tail + 1) % desc->num_bd;
/*
* The callback is called from the interrupt context in order
@@ -736,7 +755,7 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
* executed.
*/
- dmaengine_desc_get_callback_invoke(&sdmac->desc, NULL);
+ dmaengine_desc_get_callback_invoke(&sdmac->txdesc, NULL);
if (error)
sdmac->status = old_status;
@@ -749,17 +768,17 @@ static void mxc_sdma_handle_channel_normal(unsigned long data)
struct sdma_buffer_descriptor *bd;
int i, error = 0;
- sdmac->chn_real_count = 0;
+ sdmac->desc->chn_real_count = 0;
/*
* non loop mode. Iterate over all descriptors, collect
* errors and call callback function
*/
- for (i = 0; i < sdmac->num_bd; i++) {
- bd = &sdmac->bd[i];
+ for (i = 0; i < sdmac->desc->num_bd; i++) {
+ bd = &sdmac->desc->bd[i];
if (bd->mode.status & (BD_DONE | BD_RROR))
error = -EIO;
- sdmac->chn_real_count += bd->mode.count;
+ sdmac->desc->chn_real_count += bd->mode.count;
}
if (error)
@@ -767,9 +786,9 @@ static void mxc_sdma_handle_channel_normal(unsigned long data)
else
sdmac->status = DMA_COMPLETE;
- dma_cookie_complete(&sdmac->desc);
+ dma_cookie_complete(&sdmac->txdesc);
- dmaengine_desc_get_callback_invoke(&sdmac->desc, NULL);
+ dmaengine_desc_get_callback_invoke(&sdmac->txdesc, NULL);
}
static irqreturn_t sdma_int_handler(int irq, void *dev_id)
@@ -897,7 +916,7 @@ static int sdma_load_context(struct sdma_channel *sdmac)
int channel = sdmac->channel;
int load_address;
struct sdma_context_data *context = sdma->context;
- struct sdma_buffer_descriptor *bd0 = sdma->channel[0].bd;
+ struct sdma_buffer_descriptor *bd0 = sdma->bd0;
int ret;
unsigned long flags;
@@ -1100,18 +1119,22 @@ static int sdma_set_channel_priority(struct sdma_channel *sdmac,
static int sdma_request_channel(struct sdma_channel *sdmac)
{
struct sdma_engine *sdma = sdmac->sdma;
+ struct sdma_desc *desc;
int channel = sdmac->channel;
int ret = -EBUSY;
- sdmac->bd = dma_zalloc_coherent(NULL, PAGE_SIZE, &sdmac->bd_phys,
+ sdmac->desc = &sdmac->_desc;
+ desc = sdmac->desc;
+
+ desc->bd = dma_zalloc_coherent(NULL, PAGE_SIZE, &desc->bd_phys,
GFP_KERNEL);
- if (!sdmac->bd) {
+ if (!desc->bd) {
ret = -ENOMEM;
goto out;
}
- sdma->channel_control[channel].base_bd_ptr = sdmac->bd_phys;
- sdma->channel_control[channel].current_bd_ptr = sdmac->bd_phys;
+ sdma->channel_control[channel].base_bd_ptr = desc->bd_phys;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
sdma_set_channel_priority(sdmac, MXC_SDMA_DEFAULT_PRIORITY);
return 0;
@@ -1176,10 +1199,10 @@ static int sdma_alloc_chan_resources(struct dma_chan *chan)
if (ret)
goto disable_clk_ahb;
- dma_async_tx_descriptor_init(&sdmac->desc, chan);
- sdmac->desc.tx_submit = sdma_tx_submit;
+ dma_async_tx_descriptor_init(&sdmac->txdesc, chan);
+ sdmac->txdesc.tx_submit = sdma_tx_submit;
/* txd.flags will be overwritten in prep funcs */
- sdmac->desc.flags = DMA_CTRL_ACK;
+ sdmac->txdesc.flags = DMA_CTRL_ACK;
return 0;
@@ -1194,6 +1217,7 @@ static void sdma_free_chan_resources(struct dma_chan *chan)
{
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
+ struct sdma_desc *desc = sdmac->desc;
sdma_disable_channel(chan);
@@ -1207,7 +1231,7 @@ static void sdma_free_chan_resources(struct dma_chan *chan)
sdma_set_channel_priority(sdmac, 0);
- dma_free_coherent(NULL, PAGE_SIZE, sdmac->bd, sdmac->bd_phys);
+ dma_free_coherent(NULL, PAGE_SIZE, desc->bd, desc->bd_phys);
clk_disable(sdma->clk_ipg);
clk_disable(sdma->clk_ahb);
@@ -1223,6 +1247,7 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
int ret, i, count;
int channel = sdmac->channel;
struct scatterlist *sg;
+ struct sdma_desc *desc = sdmac->desc;
if (sdmac->status == DMA_IN_PROGRESS)
return NULL;
@@ -1230,9 +1255,9 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
sdmac->flags = 0;
- sdmac->buf_tail = 0;
- sdmac->buf_ptail = 0;
- sdmac->chn_real_count = 0;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->chn_real_count = 0;
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
sg_len, channel);
@@ -1249,9 +1274,9 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
goto err_out;
}
- sdmac->chn_count = 0;
+ desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
- struct sdma_buffer_descriptor *bd = &sdmac->bd[i];
+ struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
bd->buffer_addr = sg->dma_address;
@@ -1266,7 +1291,7 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
}
bd->mode.count = count;
- sdmac->chn_count += count;
+ desc->chn_count += count;
if (sdmac->word_size > DMA_SLAVE_BUSWIDTH_4_BYTES) {
ret = -EINVAL;
@@ -1307,10 +1332,10 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
bd->mode.status = param;
}
- sdmac->num_bd = sg_len;
- sdma->channel_control[channel].current_bd_ptr = sdmac->bd_phys;
+ desc->num_bd = sg_len;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
- return &sdmac->desc;
+ return &sdmac->txdesc;
err_out:
sdmac->status = DMA_ERROR;
return NULL;
@@ -1326,6 +1351,7 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
int ret, i = 0, buf = 0;
+ struct sdma_desc *desc = sdmac->desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
@@ -1334,10 +1360,10 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
sdmac->status = DMA_IN_PROGRESS;
- sdmac->buf_tail = 0;
- sdmac->buf_ptail = 0;
- sdmac->chn_real_count = 0;
- sdmac->period_len = period_len;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->chn_real_count = 0;
+ desc->period_len = period_len;
sdmac->flags |= IMX_DMA_SG_LOOP;
sdmac->direction = direction;
@@ -1358,7 +1384,7 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
}
while (buf < buf_len) {
- struct sdma_buffer_descriptor *bd = &sdmac->bd[i];
+ struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
bd->buffer_addr = dma_addr;
@@ -1389,10 +1415,10 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
i++;
}
- sdmac->num_bd = num_periods;
- sdma->channel_control[channel].current_bd_ptr = sdmac->bd_phys;
+ desc->num_bd = num_periods;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
- return &sdmac->desc;
+ return &sdmac->txdesc;
err_out:
sdmac->status = DMA_ERROR;
return NULL;
@@ -1431,13 +1457,14 @@ static enum dma_status sdma_tx_status(struct dma_chan *chan,
struct dma_tx_state *txstate)
{
struct sdma_channel *sdmac = to_sdma_chan(chan);
+ struct sdma_desc *desc = sdmac->desc;
u32 residue;
if (sdmac->flags & IMX_DMA_SG_LOOP)
- residue = (sdmac->num_bd - sdmac->buf_ptail) *
- sdmac->period_len - sdmac->chn_real_count;
+ residue = (desc->num_bd - desc->buf_ptail) *
+ desc->period_len - desc->chn_real_count;
else
- residue = sdmac->chn_count - sdmac->chn_real_count;
+ residue = desc->chn_count - desc->chn_real_count;
dma_set_tx_state(txstate, chan->completed_cookie, chan->cookie,
residue);
@@ -1661,6 +1688,8 @@ static int sdma_init(struct sdma_engine *sdma)
if (ret)
goto err_dma_alloc;
+ sdma->bd0 = sdma->channel[0].desc->bd;
+
sdma_config_ownership(&sdma->channel[0], false, true, false);
/* Set Command Channel (Channel Zero) */
--
2.17.1
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply related
* [PATCH v2 1/5] dmaengine: imx-sdma: add virt-dma support
From: Sascha Hauer @ 2018-06-08 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528465490-19684-2-git-send-email-yibin.gong@nxp.com>
On Fri, Jun 08, 2018 at 09:44:46PM +0800, Robin Gong wrote:
> The legacy sdma driver has below limitations or drawbacks:
> 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
> one page size for one channel regardless of only few BDs needed
> most time. But in few cases, the max PAGE_SIZE maybe not enough.
> 2. One SDMA channel can't stop immediatley once channel disabled which
> means SDMA interrupt may come in after this channel terminated.There
> are some patches for this corner case such as commit "2746e2c389f9",
> but not cover non-cyclic.
>
> The common virt-dma overcomes the above limitations. It can alloc bd
> dynamically and free bd once this tx transfer done. No memory wasted or
> maximum limititation here, only depends on how many memory can be requested
> from kernel. For No.2, such issue can be workaround by checking if there
> is available descript("sdmac->desc") now once the unwanted interrupt
> coming. At last the common virt-dma is easier for sdma driver maintain.
>
> The main changes as below:
> --new "sdma_desc" structure containing virt_dma_desc and some members
> which moved from "sdma_channel" such as "num_bd","bd_phys","bd",etc,
> since multi descriptors may exist on virtual dma framework
> rather than only one as before.
> --remove some members of "sdma_channel" structure since it's handled
> by virtual dma common framework, such as "tasklet", "dma_chan",etc.
> --add specific BD0 for channel0 since such bd descriptor is must and
> basic for other dma channel, no need alloc/free as other channel,so
> request it during probe.
> --remove sdma_request_channel(),sdma_tx_submit(),etc.
> --alloc/free bd descriptor added and code changes for virtual dma.
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> ---
> drivers/dma/Kconfig | 1 +
> drivers/dma/imx-sdma.c | 332 ++++++++++++++++++++++++++++++++-----------------
> 2 files changed, 220 insertions(+), 113 deletions(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index ca1680a..d4a4230 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -250,6 +250,7 @@ config IMX_SDMA
> tristate "i.MX SDMA support"
> depends on ARCH_MXC
> select DMA_ENGINE
> + select DMA_VIRTUAL_CHANNELS
> help
> Support the i.MX SDMA engine. This engine is integrated into
> Freescale i.MX25/31/35/51/53/6 chips.
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index ccd03c3..8d0c1fd 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -48,6 +48,7 @@
> #include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
>
> #include "dmaengine.h"
> +#include "virt-dma.h"
>
> /* SDMA registers */
> #define SDMA_H_C0PTR 0x000
> @@ -296,6 +297,31 @@ struct sdma_context_data {
> struct sdma_engine;
>
> /**
> + * struct sdma_desc - descriptor structor for one transfer
> + * @vd descriptor for virt dma
> + * @num_bd max NUM_BD. number of descriptors currently handling
> + * @buf_tail ID of the buffer that was processed
> + * @buf_ptail ID of the previous buffer that was processed
> + * @period_len period length, used in cyclic.
> + * @chn_real_count the real count updated from bd->mode.count
> + * @chn_count the transfer count setuped
> + * @sdmac sdma_channel pointer
> + * @bd pointer of alloced bd
> + */
> +struct sdma_desc {
> + struct virt_dma_desc vd;
> + unsigned int num_bd;
> + dma_addr_t bd_phys;
> + unsigned int buf_tail;
> + unsigned int buf_ptail;
> + unsigned int period_len;
> + unsigned int chn_real_count;
> + unsigned int chn_count;
> + struct sdma_channel *sdmac;
> + struct sdma_buffer_descriptor *bd;
> +};
> +
> +/**
> * struct sdma_channel - housekeeping for a SDMA channel
> *
> * @sdma pointer to the SDMA engine for this channel
> @@ -305,11 +331,10 @@ struct sdma_engine;
> * @event_id0 aka dma request line
> * @event_id1 for channels that use 2 events
> * @word_size peripheral access size
> - * @buf_tail ID of the buffer that was processed
> - * @buf_ptail ID of the previous buffer that was processed
> - * @num_bd max NUM_BD. number of descriptors currently handling
> */
> struct sdma_channel {
> + struct virt_dma_chan vc;
> + struct sdma_desc *desc;
> struct sdma_engine *sdma;
> unsigned int channel;
> enum dma_transfer_direction direction;
> @@ -317,12 +342,6 @@ struct sdma_channel {
> unsigned int event_id0;
> unsigned int event_id1;
> enum dma_slave_buswidth word_size;
> - unsigned int buf_tail;
> - unsigned int buf_ptail;
> - unsigned int num_bd;
> - unsigned int period_len;
> - struct sdma_buffer_descriptor *bd;
> - dma_addr_t bd_phys;
> unsigned int pc_from_device, pc_to_device;
> unsigned int device_to_device;
> unsigned long flags;
> @@ -330,13 +349,10 @@ struct sdma_channel {
> unsigned long event_mask[2];
> unsigned long watermark_level;
> u32 shp_addr, per_addr;
> - struct dma_chan chan;
> spinlock_t lock;
> - struct dma_async_tx_descriptor desc;
> enum dma_status status;
> unsigned int chn_count;
> unsigned int chn_real_count;
These are no longer used here and should be removed.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Geert Uytterhoeven @ 2018-06-08 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <OSBPR01MB2054A701CF65784FAB947692D27B0@OSBPR01MB2054.jpnprd01.prod.outlook.com>
On Fri, Jun 8, 2018 at 8:50 AM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> On 07 June 2018 16:55, Rob wrote:
>> On Thu, Jun 7, 2018 at 1:59 AM, Michel Pollet
>> <michel.pollet@bp.renesas.com> wrote:
>> > On 06 June 2018 22:53, Frank wrote:
>> >> On 06/06/18 14:48, Frank Rowand wrote:
>> >> > On 06/05/18 23:36, Michel Pollet wrote:
>> >> >> On 05 June 2018 18:34, Frank wrote:
>> >> >>> On 06/05/18 04:28, Michel Pollet wrote:
>> >> >>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot
>> >> >>>> time, it requires a special enable method to get it started.
>>
>> [...]
>>
>> >> >>>> + * The second CPU is parked in ROM at boot time. It requires
>> >> >>>> +waking it after
>> >> >>>> + * writing an address into the BOOTADDR register of sysctrl.
>> >> >>>> + *
>> >> >>>> + * So the default value of the "cpu-release-addr" corresponds
>> >> >>>> +to
>> >> >>> BOOTADDR...
>> >> >>>> + *
>> >> >>>> + * *However* the BOOTADDR register is not available when the
>> >> >>>> +kernel
>> >> >>>> + * starts in NONSEC mode.
>> >> >>>> + *
>> >> >>>> + * So for NONSEC mode, the bootloader re-parks the second CPU
>> >> >>>> +into a pen
>> >> >>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to
>> >> >>>> +a SRAM address,
>> >> >>>> + * which is not restricted.
>> >> >>>
>> >> >>> The binding document for cpu-release-addr does not have a
>> >> >>> definition for 32 bit arm. The existing definition is only 64
>> >> >>> bit arm. Please add the definition for 32 bit arm to patch 1.
>> >> >>
>> >> >> Hmmm I do find a definition in
>> >> >> Documentation/devicetree/bindings/arm/cpus.txt -- just under where
>> >> >> I added my 'enable-method' -- And it is already used as 32 bits in
>> >> >> at least arch/arm/boot/dts/stih407-family.dtsi.
>> >> >
>> >> > If the correct answer is for cpu-release-addr to be 64 bits in
>> >> > certain cases (that discussion is ongoing further downthread) then
>> >> > one approach to maintain compatibility _and_ to fix the devicetree
>> >> > source files is to change the source code that currently gets
>> >> > cpu-release-addr as a
>> >> > 32 bit object to check the size of the property and get it as
>> >> > either a
>> >> > 32 bit or 64 bit object, based on the actual size of the property
>> >> > in the device tree and then change the value in the devicetree
>> >> > source files to be two cells. BUT this does not consider the
>> >> > bootloader complication. arch/arm/boot/dts/axm5516-cpus.dtsi has a
>> >> > note "// Fixed by the boot loader", so the boot loader also has to
>> >> > be modified to be able to handle the possibility that the property
>> >> > could be either
>> >> > 32 bits or 64 bits. I don't know how to maintain compatibility
>> >> > with the boot loader since we can't force it to change
>> >> > synchronously with changes in the kernel.
>> >> >
>> >> > You can consider this comment to be a drive-by observation. I
>> >> > think Rob and Geert and people like that are likely to be more
>> >> > helpful with what to actually do, and you can treat my comment more
>> >> > as pointing out the issue than as providing the perfect solution.
>> >>
>> >> Darn it, hit <send> too quickly.
>> >>
>> >> I meant to mention that there are several devicetree source files
>> >> that have a single cell value for cpu-release-addr, and thus
>> >> potentially face the same situation, depending on what the final
>> >> decision is on the proper size for cpu- release-addr. As of v4.17, a git grep
>> shows one cell values in:
>> >>
>> >> arch/arm/boot/dts/axm5516-cpus.dtsi
>> >> arch/arm/boot/dts/stih407-family.dtsi
>> >> arch/arm/boot/dts/stih418.dtsi
>> >
>> > Yes, I had grepped before I used 32 bits on mine...
>> >
>> > Now, what is the decision here? Our bootloader is already modified to
>> > set it to 32 bits, so I propose that
>>
>> And too late to fix the bootloader?
>
>
> Well not too late, but read further on...
>
>>
>> >
>> > + I change the driver to handle 32 and 64 bits properties
>>
>> That's fine if you can't fix the bootloader.
>>
>> > + I add this to the cpu.txt, as a separate patch:
>> > # On other systems, the property can be either
>> > 32 bits or 64 bits, it is the driver's responsibility
>> > to deal with either sizes.
>>
>> That is definitely not what we want to say. Use of 32-bit should be
>> considered out of spec. Yes, we have a few platforms in that category, but
>> they already handle that themselves. Would be nice to fix them, but at least
>> the STi platforms don't seem too active.
>>
>> IMO, we should delete whatever text we can here and at most just refer to
>> the spec.
>
> So actually I didn't use 32 bits by plain chance, I read the cpu.txt file which says
> that 64 bits systems use 64 bits property, concluded that in my case I ought to
> use 32 bits, then grepped around and found other systems using 32 bits, therefore
> I went forward and used it..
>
> Nothing said here that it should be 64 bits everywhere -- So the documentation
> needs fixing somehow. Right now it certainly led me wrong.
Perhaps we should add to Documentation/devicetree/bindings/ the standard
bindings from ePAPR and successors, too?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-08 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180608082125.tjnd6jayecv26csv@verge.net.au>
On 6/8/2018 11:21 AM, Simon Horman wrote:
>> Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
>> 'renesas-devel-20180604-v4.17' tag. We're adding the R8A77980 FCPVD/VSPD/
>> DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder
>> connected to the LVDS output. These patches depend on the Thine THC63LVD1024
>> driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO
>> DT patches in order to apply/compile...
>>
>> [1/5] arm64: dts: renesas: r8a77980: add FCPVD support
>> [2/5] arm64: dts: renesas: r8a77980: add VSPD support
>> [3/5] arm64: dts: renesas: r8a77980: add DU support
>> [4/5] arm64: dts: renesas: r8a77980: add LVDS support
>> [5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
>
> Sergei,
>
> what are the changes in this series between v1 and v2?
See patch #5. I've added the V3HSK DT update there...
MBR, Sergei
^ permalink raw reply
* [PATCH v2] crypto: arm64/aes-blk - fix and move skcipher_walk_done out of kernel_neon_begin,_end
From: Will Deacon @ 2018-06-08 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528443704-26850-1-git-send-email-hejianet@gmail.com>
On Fri, Jun 08, 2018 at 03:41:44PM +0800, Jia He wrote:
> In a arm64 server(QDF2400),I met a similar might-sleep warning as [1]:
> [ 7.019116] BUG: sleeping function called from invalid context at
> ./include/crypto/algapi.h:416
> [ 7.027863] in_atomic(): 1, irqs_disabled(): 0, pid: 410, name:
> cryptomgr_test
> [ 7.035106] 1 lock held by cryptomgr_test/410:
> [ 7.039549] #0: (ptrval) (&drbg->drbg_mutex){+.+.}, at:
> drbg_instantiate+0x34/0x398
> [ 7.048038] CPU: 9 PID: 410 Comm: cryptomgr_test Not tainted
> 4.17.0-rc6+ #27
> [ 7.068228] dump_backtrace+0x0/0x1c0
> [ 7.071890] show_stack+0x24/0x30
> [ 7.075208] dump_stack+0xb0/0xec
> [ 7.078523] ___might_sleep+0x160/0x238
> [ 7.082360] skcipher_walk_done+0x118/0x2c8
> [ 7.086545] ctr_encrypt+0x98/0x130
> [ 7.090035] simd_skcipher_encrypt+0x68/0xc0
> [ 7.094304] drbg_kcapi_sym_ctr+0xd4/0x1f8
> [ 7.098400] drbg_ctr_update+0x98/0x330
> [ 7.102236] drbg_seed+0x1b8/0x2f0
> [ 7.105637] drbg_instantiate+0x2ac/0x398
> [ 7.109646] drbg_kcapi_seed+0xbc/0x188
> [ 7.113482] crypto_rng_reset+0x4c/0xb0
> [ 7.117319] alg_test_drbg+0xec/0x330
> [ 7.120981] alg_test.part.6+0x1c8/0x3c8
> [ 7.124903] alg_test+0x58/0xa0
> [ 7.128044] cryptomgr_test+0x50/0x58
> [ 7.131708] kthread+0x134/0x138
> [ 7.134936] ret_from_fork+0x10/0x1c
>
> Seems there is a bug in Ard Biesheuvel's commit.
> Fixes: 683381747270 ("crypto: arm64/aes-blk - move kernel mode neon
> en/disable into loop")
>
> [1] https://www.spinics.net/lists/linux-crypto/msg33103.html
>
> Signed-off-by: jia.he at hxt-semitech.com
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: <stable@vger.kernel.org> # 4.17
> ---
> v2: cc stable
> ---
> arch/arm64/crypto/aes-glue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Will Deacon <will.deacon@arm.com>
I'm assuming Herbert will pick this up as a fix.
Cheers,
Will
^ permalink raw reply
* [PATCH v2 1/5] arm64: dts: renesas: r8a77980: add FCPVD support
From: Simon Horman @ 2018-06-08 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <73f61c34-d0ec-75cd-b6fd-a41cfb39078f@cogentembedded.com>
On Thu, Jun 07, 2018 at 11:19:31PM +0300, Sergei Shtylyov wrote:
> Describe FCPVD0 in the R8A77980 device tree; it will be used by VSPD0 in
> the next patch...
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Hi,
This looks fine to me but I will wait for the dependencies of this series
to land and to see if there are other reviews before applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH v2 2/2] KVM: arm/arm64: harden unmap_stage2_ptes in case end is not PAGE_SIZE aligned
From: Jia He @ 2018-06-08 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180608083414.GA5097@C02W217FHV2R.local>
Hi Christoffer
I ever sent out the v3 patch set with the single patch 1/2
[link] https://patchwork.kernel.org/patch/10413803/
Sorry,I ping-ed the wrong mail thread ;-).
Cheers,
Jia
On 6/8/2018 4:34 PM, Christoffer Dall Wrote:
> On Fri, May 18, 2018 at 09:04:40PM +0800, Jia He wrote:
>>
>>
>> On 5/18/2018 5:48 PM, Marc Zyngier Wrote:
>>> On 18/05/18 10:27, Jia He wrote:
>>>> If it passes addr=0x202920000,size=0xfe00 to unmap_stage2_range->
>>>> ...->unmap_stage2_ptes, unmap_stage2_ptes will get addr=0x202920000,
>>>> end=0x20292fe00. After first while loop addr=0x202930000, end=0x20292fe00,
>>>> then addr!=end. Thus it will touch another pages by put_pages() in the
>>>> 2nd loop.
>>>>
>>>> This patch fixes it by hardening the break condition of while loop.
>>>>
>>>> Signed-off-by: jia.he at hxt-semitech.com
>>>> ---
>>>> v2: newly added
>>>>
>>>> virt/kvm/arm/mmu.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>>>> index 8dac311..45cd040 100644
>>>> --- a/virt/kvm/arm/mmu.c
>>>> +++ b/virt/kvm/arm/mmu.c
>>>> @@ -217,7 +217,7 @@ static void unmap_stage2_ptes(struct kvm *kvm, pmd_t *pmd,
>>>>
>>>> put_page(virt_to_page(pte));
>>>> }
>>>> - } while (pte++, addr += PAGE_SIZE, addr != end);
>>>> + } while (pte++, addr += PAGE_SIZE, addr < end);
>>>>
>>>> if (stage2_pte_table_empty(start_pte))
>>>> clear_stage2_pmd_entry(kvm, pmd, start_addr);
>>>>
>>>
>>> I don't think this change is the right thing to do. You get that failure
>>> because you're being passed a size that is not a multiple of PAGE_SIZE.
>>> That's the mistake.
>>>
>>> You should ensure that this never happens, rather than changing the page
>>> table walkers (which are consistent with the way this kind of code is
>>> written in other places of the kernel). As you mentioned in your first
>>> patch, the real issue is that KSM is broken, and this is what should be
>>> fixed.
>>>
>> Got it, thanks
>> Should I resend the patch 1/2 without any changes after droping patch 2/2?
>>
>
> That's fine if you trim the commit message to make it look nicer.
>
> Also, in the future, please include a cover letter if you send more than
> one patch to the list.
>
> Thanks,
> -Christoffer
>
^ permalink raw reply
* [PATCH v3] KVM: arm/arm64: add WARN_ON if size is not PAGE_SIZE aligned in unmap_stage2_range
From: Jia He @ 2018-06-08 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526871930-1231-1-git-send-email-hejianet@gmail.com>
Ping
Cheers,
Jia
On 5/21/2018 11:05 AM, Jia He Wrote:
> There is a panic in armv8a server(QDF2400) under memory pressure tests
> (start 20 guests and run memhog in the host).
>
> ---------------------------------begin--------------------------------
> [35380.800950] BUG: Bad page state in process qemu-kvm pfn:dd0b6
> [35380.805825] page:ffff7fe003742d80 count:-4871 mapcount:-2126053375
> mapping: (null) index:0x0
> [35380.815024] flags: 0x1fffc00000000000()
> [35380.818845] raw: 1fffc00000000000 0000000000000000 0000000000000000
> ffffecf981470000
> [35380.826569] raw: dead000000000100 dead000000000200 ffff8017c001c000
> 0000000000000000
> [35380.805825] page:ffff7fe003742d80 count:-4871 mapcount:-2126053375
> mapping: (null) index:0x0
> [35380.815024] flags: 0x1fffc00000000000()
> [35380.818845] raw: 1fffc00000000000 0000000000000000 0000000000000000
> ffffecf981470000
> [35380.826569] raw: dead000000000100 dead000000000200 ffff8017c001c000
> 0000000000000000
> [35380.834294] page dumped because: nonzero _refcount
> [35380.839069] Modules linked in: vhost_net vhost tap ebtable_filter
> ebtables ip6table_filter ip6_tables iptable_filter fcoe libfcoe libfc
> 8021q garp mrp stp llc scsi_transport_fc openvswitch nf_conntrack_ipv6
> nf_nat_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_defrag_ipv6
> nf_nat nf_conntrack vfat fat rpcrdma ib_isert iscsi_target_mod ib_iser
> libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp
> scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm
> ib_cm iw_cm mlx5_ib ib_core crc32_ce ipmi_ssif tpm_tis tpm_tis_core sg
> nfsd auth_rpcgss nfs_acl lockd grace sunrpc dm_multipath ip_tables xfs
> libcrc32c mlx5_core mlxfw devlink ahci_platform libahci_platform libahci
> qcom_emac sdhci_acpi sdhci hdma mmc_core hdma_mgmt i2c_qup dm_mirror
> dm_region_hash dm_log dm_mod
> [35380.908341] CPU: 29 PID: 18323 Comm: qemu-kvm Tainted: G W
> 4.14.15-5.hxt.aarch64 #1
> [35380.917107] Hardware name: <snip for confidential issues>
> [35380.930909] Call trace:
> [35380.933345] [<ffff000008088f00>] dump_backtrace+0x0/0x22c
> [35380.938723] [<ffff000008089150>] show_stack+0x24/0x2c
> [35380.943759] [<ffff00000893c078>] dump_stack+0x8c/0xb0
> [35380.948794] [<ffff00000820ab50>] bad_page+0xf4/0x154
> [35380.953740] [<ffff000008211ce8>] free_pages_check_bad+0x90/0x9c
> [35380.959642] [<ffff00000820c430>] free_pcppages_bulk+0x464/0x518
> [35380.965545] [<ffff00000820db98>] free_hot_cold_page+0x22c/0x300
> [35380.971448] [<ffff0000082176fc>] __put_page+0x54/0x60
> [35380.976484] [<ffff0000080b1164>] unmap_stage2_range+0x170/0x2b4
> [35380.982385] [<ffff0000080b12d8>] kvm_unmap_hva_handler+0x30/0x40
> [35380.988375] [<ffff0000080b0104>] handle_hva_to_gpa+0xb0/0xec
> [35380.994016] [<ffff0000080b2644>] kvm_unmap_hva_range+0x5c/0xd0
> [35380.999833] [<ffff0000080a8054>]
> kvm_mmu_notifier_invalidate_range_start+0x60/0xb0
> [35381.007387] [<ffff000008271f44>]
> __mmu_notifier_invalidate_range_start+0x64/0x8c
> [35381.014765] [<ffff0000082547c8>] try_to_unmap_one+0x78c/0x7a4
> [35381.020493] [<ffff000008276d04>] rmap_walk_ksm+0x124/0x1a0
> [35381.025961] [<ffff0000082551b4>] rmap_walk+0x94/0x98
> [35381.030909] [<ffff0000082555e4>] try_to_unmap+0x100/0x124
> [35381.036293] [<ffff00000828243c>] unmap_and_move+0x480/0x6fc
> [35381.041847] [<ffff000008282b6c>] migrate_pages+0x10c/0x288
> [35381.047318] [<ffff00000823c164>] compact_zone+0x238/0x954
> [35381.052697] [<ffff00000823c944>] compact_zone_order+0xc4/0xe8
> [35381.058427] [<ffff00000823d25c>] try_to_compact_pages+0x160/0x294
> [35381.064503] [<ffff00000820f074>]
> __alloc_pages_direct_compact+0x68/0x194
> [35381.071187] [<ffff000008210138>] __alloc_pages_nodemask+0xc20/0xf7c
> [35381.077437] [<ffff0000082709e4>] alloc_pages_vma+0x1a4/0x1c0
> [35381.083080] [<ffff000008285b68>]
> do_huge_pmd_anonymous_page+0x128/0x324
> [35381.089677] [<ffff000008248a24>] __handle_mm_fault+0x71c/0x7e8
> [35381.095492] [<ffff000008248be8>] handle_mm_fault+0xf8/0x194
> [35381.101049] [<ffff000008240dcc>] __get_user_pages+0x124/0x34c
> [35381.106777] [<ffff000008241870>] populate_vma_page_range+0x90/0x9c
> [35381.112941] [<ffff000008241940>] __mm_populate+0xc4/0x15c
> [35381.118322] [<ffff00000824b294>] SyS_mlockall+0x100/0x164
> [35381.123705] Exception stack(0xffff800dce5f3ec0 to 0xffff800dce5f4000)
> [35381.130128] 3ec0: 0000000000000003 d6e6024cc9b87e00 0000aaaabe94f000
> 0000000000000000
> [35381.137940] 3ee0: 0000000000000002 0000000000000000 0000000000000000
> 0000aaaacf6fc3c0
> [35381.145753] 3f00: 00000000000000e6 0000aaaacf6fc490 0000ffffeeeab0f0
> d6e6024cc9b87e00
> [35381.153565] 3f20: 0000000000000000 0000aaaabe81b3c0 0000000000000020
> 00009e53eff806b5
> [35381.161379] 3f40: 0000aaaabe94de48 0000ffffa7c269b0 0000000000000011
> 0000ffffeeeabf68
> [35381.169190] 3f60: 0000aaaaceacfe60 0000aaaabe94f000 0000aaaabe9ba358
> 0000aaaabe7ffb80
> [35381.177003] 3f80: 0000aaaabe9ba000 0000aaaabe959f64 0000000000000000
> 0000aaaabe94f000
> [35381.184815] 3fa0: 0000000000000000 0000ffffeeeabdb0 0000aaaabe5f3bf8
> 0000ffffeeeabdb0
> [35381.192628] 3fc0: 0000ffffa7c269b8 0000000060000000 0000000000000003
> 00000000000000e6
> [35381.200440] 3fe0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [35381.208254] [<ffff00000808339c>] __sys_trace_return+0x0/0x4
> [35381.213809] Disabling lock debugging due to kernel taint
> --------------------------------end--------------------------------------
>
> The root cause might be what I fixed at [1]. But from arm kvm points of
> view, it would be better we caught the exception earlier and clearer.
>
> If the size is not PAGE_SIZE aligned, unmap_stage2_range might unmap the
> wrong(more or less) page range. Hence it caused the "BUG: Bad page
> state"
>
> [1] https://lkml.org/lkml/2018/5/3/1042
>
> Signed-off-by: jia.he at hxt-semitech.com
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> v3: resend after dropping patch 2/2 of the series
>
> virt/kvm/arm/mmu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index 7f6a944..8dac311 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -297,6 +297,8 @@ static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
> phys_addr_t next;
>
> assert_spin_locked(&kvm->mmu_lock);
> + WARN_ON(size & ~PAGE_MASK);
> +
> pgd = kvm->arch.pgd + stage2_pgd_index(addr);
> do {
> /*
>
^ permalink raw reply
* [PATCH v2 2/2] media: mtk-vcodec: Support VP9 profile in decoder
From: Hans Verkuil @ 2018-06-08 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530071613.125768-3-keiichiw@chromium.org>
On 05/30/2018 09:16 AM, Keiichi Watanabe wrote:
> Add V4L2_CID_MPEG_VIDEO_VP9_PROFILE control in MediaTek decoder's
> driver.
> MediaTek decoder only supports profile 0 for now.
>
> Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
> ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> index 86f0a7134365..f9393504356d 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> @@ -1400,6 +1400,12 @@ int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_ctx *ctx)
> V4L2_CID_MIN_BUFFERS_FOR_CAPTURE,
> 0, 32, 1, 1);
> ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
> + v4l2_ctrl_new_std_menu(&ctx->ctrl_hdl,
> + &mtk_vcodec_dec_ctrl_ops,
> + V4L2_CID_MPEG_VIDEO_VP9_PROFILE,
> + V4L2_MPEG_VIDEO_VP9_PROFILE_3,
It makes no sense to set max to PROFILE_3 if PROFILE_0 is the only choice.
Just set max to PROFILE_0 as well.
> + ~(1U << V4L2_MPEG_VIDEO_VP9_PROFILE_0),
> + V4L2_MPEG_VIDEO_VP9_PROFILE_0);
>
> if (ctx->ctrl_hdl.error) {
> mtk_v4l2_err("Adding control failed %d",
> --
> 2.17.0.921.gf22659ad46-goog
>
Regards,
Hans
^ permalink raw reply
* [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
From: Suzuki K Poulose @ 2018-06-08 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607164747.7e4bb30f69a1fb4c160b6ef1@arm.com>
On 06/07/2018 10:47 PM, Kim Phillips wrote:
> On Thu, 7 Jun 2018 22:10:07 +0100
> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
>> On 06/07/2018 06:13 PM, Kim Phillips wrote:
>>> I'm going to assume the series is still valid after this discussion,
>>> since technically just this patch can get dropped, and the user is able
>>> to shoot themselves in the foot.
>>
>> That doesn't mean the kernel can panic() if the user decided to unload
>> the module while the trace session is in progress. It only means that
>> the trace session could be stopped in between in the worst case. But
>> nothing more harmful to the system.
Kim,
>
> FWIW, I didn't see the kernel panic in my basic tests; just some bad
> accesses: the new remove functions take care of cleaning up most items,
> and most drivers still depend on the links and sinks (funnel,
> replicator) drivers, so they can't be upset too bad.
Bad accesses are still bad. The bad access could trigger an Oops for
e.g, or could even corrupt the other parts of the kernel if we try
to access a memory that is free'd (and reallocated to somebody else).
So, the point is there are issues with the series which we know for
sure from code analysis. It may take different forms to show up at
runtime.
>
>>> This series is for development purposes, after all.
>>
>> Do you mean that this series is for internal development purposes and
>> not upstream ? Making the drivers modular are always helpful, especially
>
> no, I'm posting them for upstream review because I'd like them upstream.
>
>> for something related to tracing, that allows the module to be unloaded
>> after use. So, it would be good to have this series in, but in a manner
>> which is usable and doesn't cause harm to the overall system usage.
>>
>> I think the summary of the discussion is that we need more robust code
>> to handle the situation, which also allows unloading the modules without
>> any trouble.
>
> Trouble's relative. My point was since the series is going to be used
> mainly by developers testing their code, they already prepare for, and
> expect badness to occur anyway. Greg's point isn't lost here, and in
Making something modular is not really just for the use of developers.
There are and will be other users for a device driver as a module and
it is a fundamental feature people expect (especially in the enterprise
world, where there is one kernel which builds most of the stuff as
module to let the users pick the individual drivers as they need).
So, at the kernel driver you can't really be sure, if the user is
actually aware of the "developer" only mode and he knows that we can
crash the kernel.
> my interpretation, his review of this patch was that it was in the
> wrong direction of safety: it made things unnecessarily too safe, up
> front, and that items relative to the perf core should strive to adhere
One of the areas of improvement towards the "modern" behavior is failing
the activation of the trace schedule, when a component in the path has
been removed when we go through coresight_enable_path(). Right now, we
create a path and then we do enable_path() and disable_path() around the
trace schedules and the path is destroyed only at pmu->free_aux(). With
the current patch, we hold the reference to the device/driver throughout
the duration of the life time of the tracing, even when the tracing
may be disabled in between.
I think, if we get to that point, we should be at the best we can reach
towards the expected behavior. But having said that, it is indeed tricky
to get that. May be we could play a little bit with the refcounting on
csdev and check if the refcount is only held by the number of paths this
component is part of (needs more thought).
Suzuki
^ permalink raw reply
* [PATCH] net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode
From: Vadim Lomovtsev @ 2018-06-08 9:27 UTC (permalink / raw)
To: linux-arm-kernel
From: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
For each network interface linux network stack issue ndo_set_rx_mode call
in order to configure MAC address filters (e.g. for multicast filtering).
Currently ThunderX NICVF driver has only one ordered workqueue to process
such requests for all VFs.
And because of that it is possible that subsequent call to
ndo_set_rx_mode would corrupt data which is currently in use
by nicvf_set_rx_mode_task. Which in turn could cause following issue:
[...]
[ 48.978341] Unable to handle kernel paging request at virtual address 1fffff0000000000
[ 48.986275] Mem abort info:
[ 48.989058] Exception class = DABT (current EL), IL = 32 bits
[ 48.994965] SET = 0, FnV = 0
[ 48.998020] EA = 0, S1PTW = 0
[ 49.001152] Data abort info:
[ 49.004022] ISV = 0, ISS = 0x00000004
[ 49.007869] CM = 0, WnR = 0
[ 49.010826] [1fffff0000000000] address between user and kernel address ranges
[ 49.017963] Internal error: Oops: 96000004 [#1] SMP
[...]
[ 49.072138] task: ffff800fdd675400 task.stack: ffff000026440000
[ 49.078051] PC is at prefetch_freepointer.isra.37+0x28/0x3c
[ 49.083613] LR is at kmem_cache_alloc_trace+0xc8/0x1fc
[...]
[ 49.272684] [<ffff0000082738f0>] prefetch_freepointer.isra.37+0x28/0x3c
[ 49.279286] [<ffff000008276bc8>] kmem_cache_alloc_trace+0xc8/0x1fc
[ 49.285455] [<ffff0000082c0c0c>] alloc_fdtable+0x78/0x134
[ 49.290841] [<ffff0000082c15c0>] dup_fd+0x254/0x2f4
[ 49.295709] [<ffff0000080d1954>] copy_process.isra.38.part.39+0x64c/0x1168
[ 49.302572] [<ffff0000080d264c>] _do_fork+0xfc/0x3b0
[ 49.307524] [<ffff0000080d29e8>] SyS_clone+0x44/0x50
[...]
This patch is to prevent such concurrent data write with spinlock.
Reported-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nic.h | 2 +
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 50 +++++++++++++++++-------
2 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
index 448d1fafc827..f4d81765221e 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -325,6 +325,8 @@ struct nicvf {
struct tasklet_struct qs_err_task;
struct work_struct reset_task;
struct nicvf_work rx_mode_work;
+ /* spinlock to protect workqueue arguments from concurrent access */
+ spinlock_t rx_mode_wq_lock;
/* PTP timestamp */
struct cavium_ptp *ptp_clock;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 7135db45927e..135766c4296b 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1923,17 +1923,12 @@ static int nicvf_ioctl(struct net_device *netdev, struct ifreq *req, int cmd)
}
}
-static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
+static void __nicvf_set_rx_mode_task(u8 mode, struct xcast_addr_list *mc_addrs,
+ struct nicvf *nic)
{
- struct nicvf_work *vf_work = container_of(work_arg, struct nicvf_work,
- work.work);
- struct nicvf *nic = container_of(vf_work, struct nicvf, rx_mode_work);
union nic_mbx mbx = {};
int idx;
- if (!vf_work)
- return;
-
/* From the inside of VM code flow we have only 128 bits memory
* available to send message to host's PF, so send all mc addrs
* one by one, starting from flush command in case if kernel
@@ -1944,7 +1939,7 @@ static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
mbx.xcast.msg = NIC_MBOX_MSG_RESET_XCAST;
nicvf_send_msg_to_pf(nic, &mbx);
- if (vf_work->mode & BGX_XCAST_MCAST_FILTER) {
+ if (mode & BGX_XCAST_MCAST_FILTER) {
/* once enabling filtering, we need to signal to PF to add
* its' own LMAC to the filter to accept packets for it.
*/
@@ -1954,23 +1949,46 @@ static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
}
/* check if we have any specific MACs to be added to PF DMAC filter */
- if (vf_work->mc) {
+ if (mc_addrs) {
/* now go through kernel list of MACs and add them one by one */
- for (idx = 0; idx < vf_work->mc->count; idx++) {
+ for (idx = 0; idx < mc_addrs->count; idx++) {
mbx.xcast.msg = NIC_MBOX_MSG_ADD_MCAST;
- mbx.xcast.data.mac = vf_work->mc->mc[idx];
+ mbx.xcast.data.mac = mc_addrs->mc[idx];
nicvf_send_msg_to_pf(nic, &mbx);
}
- kfree(vf_work->mc);
+ kfree(mc_addrs);
}
/* and finally set rx mode for PF accordingly */
mbx.xcast.msg = NIC_MBOX_MSG_SET_XCAST;
- mbx.xcast.data.mode = vf_work->mode;
+ mbx.xcast.data.mode = mode;
nicvf_send_msg_to_pf(nic, &mbx);
}
+static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
+{
+ struct nicvf_work *vf_work = container_of(work_arg, struct nicvf_work,
+ work.work);
+ struct nicvf *nic = container_of(vf_work, struct nicvf, rx_mode_work);
+ u8 mode;
+ struct xcast_addr_list *mc;
+
+ if (!vf_work)
+ return;
+
+ /* Save message data locally to prevent them from
+ * being overwritten by next ndo_set_rx_mode call().
+ */
+ spin_lock(&nic->rx_mode_wq_lock);
+ mode = vf_work->mode;
+ mc = vf_work->mc;
+ vf_work->mc = NULL;
+ spin_unlock(&nic->rx_mode_wq_lock);
+
+ __nicvf_set_rx_mode_task(mode, mc, nic);
+}
+
static void nicvf_set_rx_mode(struct net_device *netdev)
{
struct nicvf *nic = netdev_priv(netdev);
@@ -2004,9 +2022,12 @@ static void nicvf_set_rx_mode(struct net_device *netdev)
}
}
}
+ spin_lock(&nic->rx_mode_wq_lock);
+ kfree(nic->rx_mode_work.mc);
nic->rx_mode_work.mc = mc_list;
nic->rx_mode_work.mode = mode;
- queue_delayed_work(nicvf_rx_mode_wq, &nic->rx_mode_work.work, 2 * HZ);
+ queue_delayed_work(nicvf_rx_mode_wq, &nic->rx_mode_work.work, 0);
+ spin_unlock(&nic->rx_mode_wq_lock);
}
static const struct net_device_ops nicvf_netdev_ops = {
@@ -2163,6 +2184,7 @@ static int nicvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
INIT_WORK(&nic->reset_task, nicvf_reset_task);
INIT_DELAYED_WORK(&nic->rx_mode_work.work, nicvf_set_rx_mode_task);
+ spin_lock_init(&nic->rx_mode_wq_lock);
err = register_netdev(netdev);
if (err) {
--
2.14.4
^ permalink raw reply related
* [PATCH v2 1/2] media: v4l2-ctrl: Add control for VP9 profile
From: Hans Verkuil @ 2018-06-08 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530071613.125768-2-keiichiw@chromium.org>
On 05/30/2018 09:16 AM, Keiichi Watanabe wrote:
> Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired
> profile for VP9 encoder and querying for supported profiles by VP9 encoder
> or decoder.
>
> An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE cannot be
> used for querying since it is not a menu control but an integer
> control, which cannot return an arbitrary set of supported profiles.
>
> The new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE is a menu control as
> with controls for other codec profiles. (e.g. H264)
Please ignore my reply to patch 2/2. I looked at this a bit more and what you
should do is to change the type of V4L2_CID_MPEG_VIDEO_VPX_PROFILE to enum.
All other codec profile controls are all enums, so the fact that VPX_PROFILE
isn't is a bug. Changing the type should not cause any problems since the same
control value is used when you set the control.
Sylwester: I see that s5p-mfc uses this control, but it is explicitly added
as an integer type control, so the s5p-mfc driver should not be affected by
changing the type of this control.
Stanimir: this will slightly change the venus driver, but since it is a very
recent driver I think we can get away with changing the core type of the
VPX_PROFILE control. I think that's better than ending up with two controls
that do the same thing.
Regards,
Hans
>
> Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
> ---
> .../media/uapi/v4l/extended-controls.rst | 26 +++++++++++++++++++
> drivers/media/v4l2-core/v4l2-ctrls.c | 12 +++++++++
> include/uapi/linux/v4l2-controls.h | 8 ++++++
> 3 files changed, 46 insertions(+)
>
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
> index 03931f9b1285..4f7f128a4998 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -1959,6 +1959,32 @@ enum v4l2_vp8_golden_frame_sel -
> Select the desired profile for VPx encoder. Acceptable values are 0,
> 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
>
> +.. _v4l2-mpeg-video-vp9-profile:
> +
> +``V4L2_CID_MPEG_VIDEO_VP9_PROFILE``
> + (enum)
> +
> +enum v4l2_mpeg_video_vp9_profile -
> + This control allows to select the profile for VP9 encoder.
> + This is also used to enumerate supported profiles by VP9 encoder or decoder.
> + Possible values are:
> +
> +
> +
> +.. flat-table::
> + :header-rows: 0
> + :stub-columns: 0
> +
> + * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_0``
> + - Profile 0
> + * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_1``
> + - Profile 1
> + * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_2``
> + - Profile 2
> + * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_3``
> + - Profile 3
> +
> +
>
> High Efficiency Video Coding (HEVC/H.265) Control Reference
> -----------------------------------------------------------
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index d29e45516eb7..401ce21c2e63 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -431,6 +431,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> "Use Previous Specific Frame",
> NULL,
> };
> + static const char * const vp9_profile[] = {
> + "0",
> + "1",
> + "2",
> + "3",
> + NULL,
> + };
>
> static const char * const flash_led_mode[] = {
> "Off",
> @@ -614,6 +621,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> return mpeg4_profile;
> case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
> return vpx_golden_frame_sel;
> + case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
> + return vp9_profile;
> case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
> return jpeg_chroma_subsampling;
> case V4L2_CID_DV_TX_MODE:
> @@ -841,6 +850,8 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
> case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX Profile";
>
> + case V4L2_CID_MPEG_VIDEO_VP9_PROFILE: return "VP9 Profile";
> +
> /* HEVC controls */
> case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
> case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP: return "HEVC P-Frame QP Value";
> @@ -1180,6 +1191,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> case V4L2_CID_DEINTERLACING_MODE:
> case V4L2_CID_TUNE_DEEMPHASIS:
> case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
> + case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
> case V4L2_CID_DETECT_MD_MODE:
> case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
> case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index 8d473c979b61..56203b7b715c 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -589,6 +589,14 @@ enum v4l2_vp8_golden_frame_sel {
> #define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510)
> #define V4L2_CID_MPEG_VIDEO_VPX_PROFILE (V4L2_CID_MPEG_BASE+511)
>
> +#define V4L2_CID_MPEG_VIDEO_VP9_PROFILE (V4L2_CID_MPEG_BASE+512)
> +enum v4l2_mpeg_video_vp9_profile {
> + V4L2_MPEG_VIDEO_VP9_PROFILE_0 = 0,
> + V4L2_MPEG_VIDEO_VP9_PROFILE_1 = 1,
> + V4L2_MPEG_VIDEO_VP9_PROFILE_2 = 2,
> + V4L2_MPEG_VIDEO_VP9_PROFILE_3 = 3,
> +};
> +
> /* CIDs for HEVC encoding. */
>
> #define V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (V4L2_CID_MPEG_BASE + 600)
> --
> 2.17.0.921.gf22659ad46-goog
>
^ permalink raw reply
* [PATCH 11/17] arm64: dts: r8a77965: Add VSP instances
From: Geert Uytterhoeven @ 2018-06-08 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1787243.JuNJAuBqMb@avalon>
Hi Laurent,
CC Sergei (for V3H/V3M)
On Thu, Apr 26, 2018 at 11:11 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday, 26 April 2018 19:53:40 EEST Kieran Bingham wrote:
>> The r8a77965 has 4 VSP instances.
>>
>> Based on a similar patch of the R8A7796 device tree
>> by Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>.
>>
>> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>> [Kieran: Rebased to top of tree, fixed sort orders]
>> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
>> ---
>> arch/arm64/boot/dts/renesas/r8a77965.dtsi | 44 +++++++++++++++++++++++
>> 1 file changed, 44 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a77965.dtsi index
>> 1f44ed7c1b1c..e92e6b03333a 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> @@ -1025,6 +1047,17 @@
>> resets = <&cpg 611>;
>> };
>>
>> + vspd0: vsp at fea20000 {
>> + compatible = "renesas,vsp2";
>> + reg = <0 0xfea20000 0 0x4000>;
>
> RFP2 has a CLUT so the register range needs to be extended. I'd recommend
> covering the entire space (0x8000) even if no LUT or CLU module is present.
Even on V3H/V3M, which have some part of the CLUT, and could do
with 0x5000?
Note that this makes it overlap with fcpvd0 on all R-Car Gen3 SoCs,
as mentioned by Simon on IRC.
>> + interrupts = <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&cpg CPG_MOD 623>;
>> + power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
>> + resets = <&cpg 623>;
>> +
>> + renesas,fcp = <&fcpvd0>;
>> + };
>> +
>> fcpvd0: fcp at fea27000 {
>> compatible = "renesas,fcpv";
>> reg = <0 0xfea27000 0 0x200>;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 1/2] media: v4l2-ctrl: Add control for VP9 profile
From: Tomasz Figa @ 2018-06-08 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a16dca32-4198-72c1-cf22-83f18a8cfcb6@xs4all.nl>
Hi Hans,
On Fri, Jun 8, 2018 at 6:29 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> On 05/30/2018 09:16 AM, Keiichi Watanabe wrote:
> > Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired
> > profile for VP9 encoder and querying for supported profiles by VP9 encoder
> > or decoder.
> >
> > An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE cannot be
> > used for querying since it is not a menu control but an integer
> > control, which cannot return an arbitrary set of supported profiles.
> >
> > The new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE is a menu control as
> > with controls for other codec profiles. (e.g. H264)
>
> Please ignore my reply to patch 2/2. I looked at this a bit more and what you
> should do is to change the type of V4L2_CID_MPEG_VIDEO_VPX_PROFILE to enum.
Note that we still need a way to query VP8 and VP9 separately, since
the supported profiles will differ. (Most of hardware we have today
support all 4 profiles of VP8 and only profile 0 of VP9.)
Best regards,
Tomasz
>
> All other codec profile controls are all enums, so the fact that VPX_PROFILE
> isn't is a bug. Changing the type should not cause any problems since the same
> control value is used when you set the control.
>
> Sylwester: I see that s5p-mfc uses this control, but it is explicitly added
> as an integer type control, so the s5p-mfc driver should not be affected by
> changing the type of this control.
>
> Stanimir: this will slightly change the venus driver, but since it is a very
> recent driver I think we can get away with changing the core type of the
> VPX_PROFILE control. I think that's better than ending up with two controls
> that do the same thing.
>
> Regards,
>
> Hans
>
> >
> > Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
> > ---
> > .../media/uapi/v4l/extended-controls.rst | 26 +++++++++++++++++++
> > drivers/media/v4l2-core/v4l2-ctrls.c | 12 +++++++++
> > include/uapi/linux/v4l2-controls.h | 8 ++++++
> > 3 files changed, 46 insertions(+)
> >
> > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
> > index 03931f9b1285..4f7f128a4998 100644
> > --- a/Documentation/media/uapi/v4l/extended-controls.rst
> > +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> > @@ -1959,6 +1959,32 @@ enum v4l2_vp8_golden_frame_sel -
> > Select the desired profile for VPx encoder. Acceptable values are 0,
> > 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
> >
> > +.. _v4l2-mpeg-video-vp9-profile:
> > +
> > +``V4L2_CID_MPEG_VIDEO_VP9_PROFILE``
> > + (enum)
> > +
> > +enum v4l2_mpeg_video_vp9_profile -
> > + This control allows to select the profile for VP9 encoder.
> > + This is also used to enumerate supported profiles by VP9 encoder or decoder.
> > + Possible values are:
> > +
> > +
> > +
> > +.. flat-table::
> > + :header-rows: 0
> > + :stub-columns: 0
> > +
> > + * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_0``
> > + - Profile 0
> > + * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_1``
> > + - Profile 1
> > + * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_2``
> > + - Profile 2
> > + * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_3``
> > + - Profile 3
> > +
> > +
> >
> > High Efficiency Video Coding (HEVC/H.265) Control Reference
> > -----------------------------------------------------------
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index d29e45516eb7..401ce21c2e63 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -431,6 +431,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > "Use Previous Specific Frame",
> > NULL,
> > };
> > + static const char * const vp9_profile[] = {
> > + "0",
> > + "1",
> > + "2",
> > + "3",
> > + NULL,
> > + };
> >
> > static const char * const flash_led_mode[] = {
> > "Off",
> > @@ -614,6 +621,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > return mpeg4_profile;
> > case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
> > return vpx_golden_frame_sel;
> > + case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
> > + return vp9_profile;
> > case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
> > return jpeg_chroma_subsampling;
> > case V4L2_CID_DV_TX_MODE:
> > @@ -841,6 +850,8 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
> > case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX Profile";
> >
> > + case V4L2_CID_MPEG_VIDEO_VP9_PROFILE: return "VP9 Profile";
> > +
> > /* HEVC controls */
> > case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
> > case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP: return "HEVC P-Frame QP Value";
> > @@ -1180,6 +1191,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> > case V4L2_CID_DEINTERLACING_MODE:
> > case V4L2_CID_TUNE_DEEMPHASIS:
> > case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
> > + case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
> > case V4L2_CID_DETECT_MD_MODE:
> > case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
> > case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
> > diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> > index 8d473c979b61..56203b7b715c 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -589,6 +589,14 @@ enum v4l2_vp8_golden_frame_sel {
> > #define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510)
> > #define V4L2_CID_MPEG_VIDEO_VPX_PROFILE (V4L2_CID_MPEG_BASE+511)
> >
> > +#define V4L2_CID_MPEG_VIDEO_VP9_PROFILE (V4L2_CID_MPEG_BASE+512)
> > +enum v4l2_mpeg_video_vp9_profile {
> > + V4L2_MPEG_VIDEO_VP9_PROFILE_0 = 0,
> > + V4L2_MPEG_VIDEO_VP9_PROFILE_1 = 1,
> > + V4L2_MPEG_VIDEO_VP9_PROFILE_2 = 2,
> > + V4L2_MPEG_VIDEO_VP9_PROFILE_3 = 3,
> > +};
> > +
> > /* CIDs for HEVC encoding. */
> >
> > #define V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (V4L2_CID_MPEG_BASE + 600)
> > --
> > 2.17.0.921.gf22659ad46-goog
> >
>
^ permalink raw reply
* [PATCH v2 1/2] media: v4l2-ctrl: Add control for VP9 profile
From: Hans Verkuil @ 2018-06-08 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAFQd5B8W0KqnPXs3yo8-ndKTE2n5yYmNEjbCWq6yR6iQYjouA@mail.gmail.com>
On 06/08/2018 11:31 AM, Tomasz Figa wrote:
> Hi Hans,
>
> On Fri, Jun 8, 2018 at 6:29 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>
>> On 05/30/2018 09:16 AM, Keiichi Watanabe wrote:
>>> Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired
>>> profile for VP9 encoder and querying for supported profiles by VP9 encoder
>>> or decoder.
>>>
>>> An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE cannot be
>>> used for querying since it is not a menu control but an integer
>>> control, which cannot return an arbitrary set of supported profiles.
>>>
>>> The new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE is a menu control as
>>> with controls for other codec profiles. (e.g. H264)
>>
>> Please ignore my reply to patch 2/2. I looked at this a bit more and what you
>> should do is to change the type of V4L2_CID_MPEG_VIDEO_VPX_PROFILE to enum.
>
> Note that we still need a way to query VP8 and VP9 separately, since
> the supported profiles will differ. (Most of hardware we have today
> support all 4 profiles of VP8 and only profile 0 of VP9.)
Urgh. So V4L2_CID_MPEG_VIDEO_VPX_PROFILE is really just for VP8?
In that case I would suggest that we rename V4L2_CID_MPEG_VIDEO_VPX_PROFILE to
V4L2_CID_MPEG_VIDEO_VP8_PROFILE and change it to an enum. Also add this line
to v4l2-controls.h:
#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE V4L2_CID_MPEG_VIDEO_VP8_PROFILE
And add a new V4L2_CID_MPEG_VIDEO_VP9_PROFILE (basically this patch).
Would that work?
This standardizes on enums for all profile controls (except s5p-mfc, which
makes its own int control, up to samsung to decide whether or not to change
that), and you have VP8 and VP9 specific profiles.
Regards,
Hans
>
> Best regards,
> Tomasz
>
>>
>> All other codec profile controls are all enums, so the fact that VPX_PROFILE
>> isn't is a bug. Changing the type should not cause any problems since the same
>> control value is used when you set the control.
>>
>> Sylwester: I see that s5p-mfc uses this control, but it is explicitly added
>> as an integer type control, so the s5p-mfc driver should not be affected by
>> changing the type of this control.
>>
>> Stanimir: this will slightly change the venus driver, but since it is a very
>> recent driver I think we can get away with changing the core type of the
>> VPX_PROFILE control. I think that's better than ending up with two controls
>> that do the same thing.
>>
>> Regards,
>>
>> Hans
>>
>>>
>>> Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
>>> ---
>>> .../media/uapi/v4l/extended-controls.rst | 26 +++++++++++++++++++
>>> drivers/media/v4l2-core/v4l2-ctrls.c | 12 +++++++++
>>> include/uapi/linux/v4l2-controls.h | 8 ++++++
>>> 3 files changed, 46 insertions(+)
>>>
>>> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
>>> index 03931f9b1285..4f7f128a4998 100644
>>> --- a/Documentation/media/uapi/v4l/extended-controls.rst
>>> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
>>> @@ -1959,6 +1959,32 @@ enum v4l2_vp8_golden_frame_sel -
>>> Select the desired profile for VPx encoder. Acceptable values are 0,
>>> 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
>>>
>>> +.. _v4l2-mpeg-video-vp9-profile:
>>> +
>>> +``V4L2_CID_MPEG_VIDEO_VP9_PROFILE``
>>> + (enum)
>>> +
>>> +enum v4l2_mpeg_video_vp9_profile -
>>> + This control allows to select the profile for VP9 encoder.
>>> + This is also used to enumerate supported profiles by VP9 encoder or decoder.
>>> + Possible values are:
>>> +
>>> +
>>> +
>>> +.. flat-table::
>>> + :header-rows: 0
>>> + :stub-columns: 0
>>> +
>>> + * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_0``
>>> + - Profile 0
>>> + * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_1``
>>> + - Profile 1
>>> + * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_2``
>>> + - Profile 2
>>> + * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_3``
>>> + - Profile 3
>>> +
>>> +
>>>
>>> High Efficiency Video Coding (HEVC/H.265) Control Reference
>>> -----------------------------------------------------------
>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
>>> index d29e45516eb7..401ce21c2e63 100644
>>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>>> @@ -431,6 +431,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>>> "Use Previous Specific Frame",
>>> NULL,
>>> };
>>> + static const char * const vp9_profile[] = {
>>> + "0",
>>> + "1",
>>> + "2",
>>> + "3",
>>> + NULL,
>>> + };
>>>
>>> static const char * const flash_led_mode[] = {
>>> "Off",
>>> @@ -614,6 +621,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>>> return mpeg4_profile;
>>> case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
>>> return vpx_golden_frame_sel;
>>> + case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
>>> + return vp9_profile;
>>> case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
>>> return jpeg_chroma_subsampling;
>>> case V4L2_CID_DV_TX_MODE:
>>> @@ -841,6 +850,8 @@ const char *v4l2_ctrl_get_name(u32 id)
>>> case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
>>> case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX Profile";
>>>
>>> + case V4L2_CID_MPEG_VIDEO_VP9_PROFILE: return "VP9 Profile";
>>> +
>>> /* HEVC controls */
>>> case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
>>> case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP: return "HEVC P-Frame QP Value";
>>> @@ -1180,6 +1191,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
>>> case V4L2_CID_DEINTERLACING_MODE:
>>> case V4L2_CID_TUNE_DEEMPHASIS:
>>> case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
>>> + case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
>>> case V4L2_CID_DETECT_MD_MODE:
>>> case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
>>> case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
>>> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
>>> index 8d473c979b61..56203b7b715c 100644
>>> --- a/include/uapi/linux/v4l2-controls.h
>>> +++ b/include/uapi/linux/v4l2-controls.h
>>> @@ -589,6 +589,14 @@ enum v4l2_vp8_golden_frame_sel {
>>> #define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510)
>>> #define V4L2_CID_MPEG_VIDEO_VPX_PROFILE (V4L2_CID_MPEG_BASE+511)
>>>
>>> +#define V4L2_CID_MPEG_VIDEO_VP9_PROFILE (V4L2_CID_MPEG_BASE+512)
>>> +enum v4l2_mpeg_video_vp9_profile {
>>> + V4L2_MPEG_VIDEO_VP9_PROFILE_0 = 0,
>>> + V4L2_MPEG_VIDEO_VP9_PROFILE_1 = 1,
>>> + V4L2_MPEG_VIDEO_VP9_PROFILE_2 = 2,
>>> + V4L2_MPEG_VIDEO_VP9_PROFILE_3 = 3,
>>> +};
>>> +
>>> /* CIDs for HEVC encoding. */
>>>
>>> #define V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (V4L2_CID_MPEG_BASE + 600)
>>> --
>>> 2.17.0.921.gf22659ad46-goog
>>>
>>
^ permalink raw reply
* [PATCH v2 0/5] add virt-dma support for imx-sdma
From: Robin Gong @ 2018-06-08 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180608084310.bzxeazqht5u6mgdw@pengutronix.de>
Thanks Sacha, I'll intergrate it into v3.
-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
Sent: 2018?6?8? 16:43
To: Robin Gong <yibin.gong@nxp.com>
Cc: vkoul at kernel.org; dan.j.williams at intel.com; dmaengine at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH v2 0/5] add virt-dma support for imx-sdma
On Fri, Jun 08, 2018 at 09:44:45PM +0800, Robin Gong wrote:
> The legacy sdma driver has below limitations or drawbacks:
> 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
> one page size for one channel regardless of only few BDs needed
> most time. But in few cases, the max PAGE_SIZE maybe not enough.
> 2. One SDMA channel can't stop immediatley once channel disabled which
> means SDMA interrupt may come in after this channel terminated.There
> are some patches for this corner case such as commit "2746e2c389f9",
> but not cover non-cyclic.
>
> The common virt-dma overcomes the above limitations. It can alloc bd
> dynamically and free bd once this tx transfer done. No memory wasted
> or maximum limititation here, only depends on how many memory can be
> requested from kernel. For No.2, such issue can be workaround by
> checking if there is available descript("sdmac->desc") now once the
> unwanted interrupt coming. At last the common virt-dma is easier for sdma driver maintain.
>
> Change from v1:
> 1. split v1 patch into 5 patches.
> 2. remove some unnecessary condition check.
> 3. remove unneccessary 'pending' list.
>
> Robin Gong (5):
> dmaengine: imx-sdma: add virt-dma support
> Revert "dmaengine: imx-sdma: fix pagefault when channel is disabled
> during interrupt"
> dmaengine: imx-sdma: remove usless lock
> dmaengine: imx-sdma: remove the maximum limation for bd numbers
> dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
>
> drivers/dma/Kconfig | 1 +
> drivers/dma/imx-sdma.c | 392
> ++++++++++++++++++++++++++++---------------------
> 2 files changed, 227 insertions(+), 166 deletions(-)
Please put the attached patch in front of your series. It makes the virt-dma support patch smaller and thus easier to review.
Sascha
--------------------------------8<----------------------------------
>From a70ccdf780cc6fcddd2d06c4a3eb0123d4aba443 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Fri, 8 Jun 2018 10:20:18 +0200
Subject: [PATCH 1/2] dmaengine: imx-sdma: factor out a struct sdma_desc from struct sdma_channel
This is a preparation step to make the adding of virt-dma easier.
We create a struct sdma_desc, move some fields from struct sdma_channel there and add a pointer from the former to the latter. For now we allocate the data statically in struct sdma_channel, but with virt-dma support it will be dynamically allocated.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/dma/imx-sdma.c | 137 +++++++++++++++++++++++++----------------
1 file changed, 83 insertions(+), 54 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index ccd03c3cedfe..556d08712f4a 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -295,6 +295,30 @@ struct sdma_context_data {
struct sdma_engine;
+/**
+ * struct sdma_desc - descriptor structor for one transfer
+ * @vd descriptor for virt dma
+ * @num_bd max NUM_BD. number of descriptors currently handling
+ * @buf_tail ID of the buffer that was processed
+ * @buf_ptail ID of the previous buffer that was processed
+ * @period_len period length, used in cyclic.
+ * @chn_real_count the real count updated from bd->mode.count
+ * @chn_count the transfer count setuped
+ * @sdmac sdma_channel pointer
+ * @bd pointer of alloced bd
+ */
+struct sdma_desc {
+ unsigned int num_bd;
+ dma_addr_t bd_phys;
+ unsigned int buf_tail;
+ unsigned int buf_ptail;
+ unsigned int period_len;
+ unsigned int chn_real_count;
+ unsigned int chn_count;
+ struct sdma_channel *sdmac;
+ struct sdma_buffer_descriptor *bd;
+};
+
/**
* struct sdma_channel - housekeeping for a SDMA channel
*
@@ -305,11 +329,10 @@ struct sdma_engine;
* @event_id0 aka dma request line
* @event_id1 for channels that use 2 events
* @word_size peripheral access size
- * @buf_tail ID of the buffer that was processed
- * @buf_ptail ID of the previous buffer that was processed
- * @num_bd max NUM_BD. number of descriptors currently handling
*/
struct sdma_channel {
+ struct sdma_desc *desc;
+ struct sdma_desc _desc;
struct sdma_engine *sdma;
unsigned int channel;
enum dma_transfer_direction direction;
@@ -317,12 +340,6 @@ struct sdma_channel {
unsigned int event_id0;
unsigned int event_id1;
enum dma_slave_buswidth word_size;
- unsigned int buf_tail;
- unsigned int buf_ptail;
- unsigned int num_bd;
- unsigned int period_len;
- struct sdma_buffer_descriptor *bd;
- dma_addr_t bd_phys;
unsigned int pc_from_device, pc_to_device;
unsigned int device_to_device;
unsigned long flags;
@@ -332,10 +349,8 @@ struct sdma_channel {
u32 shp_addr, per_addr;
struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor desc;
+ struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- unsigned int chn_count;
- unsigned int chn_real_count;
struct tasklet_struct tasklet;
struct imx_dma_data data;
bool enabled;
@@ -398,6 +413,8 @@ struct sdma_engine {
u32 spba_start_addr;
u32 spba_end_addr;
unsigned int irq;
+ dma_addr_t bd0_phys;
+ struct sdma_buffer_descriptor *bd0;
};
static struct sdma_driver_data sdma_imx31 = { @@ -632,7 +649,7 @@ static int sdma_run_channel0(struct sdma_engine *sdma) static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,
u32 address)
{
- struct sdma_buffer_descriptor *bd0 = sdma->channel[0].bd;
+ struct sdma_buffer_descriptor *bd0 = sdma->bd0;
void *buf_virt;
dma_addr_t buf_phys;
int ret;
@@ -707,7 +724,9 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
* call callback function.
*/
while (1) {
- bd = &sdmac->bd[sdmac->buf_tail];
+ struct sdma_desc *desc = sdmac->desc;
+
+ bd = &desc->bd[desc->buf_tail];
if (bd->mode.status & BD_DONE)
break;
@@ -723,11 +742,11 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
* the number of bytes present in the current buffer descriptor.
*/
- sdmac->chn_real_count = bd->mode.count;
+ desc->chn_real_count = bd->mode.count;
bd->mode.status |= BD_DONE;
- bd->mode.count = sdmac->period_len;
- sdmac->buf_ptail = sdmac->buf_tail;
- sdmac->buf_tail = (sdmac->buf_tail + 1) % sdmac->num_bd;
+ bd->mode.count = desc->period_len;
+ desc->buf_ptail = desc->buf_tail;
+ desc->buf_tail = (desc->buf_tail + 1) % desc->num_bd;
/*
* The callback is called from the interrupt context in order @@ -736,7 +755,7 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
* executed.
*/
- dmaengine_desc_get_callback_invoke(&sdmac->desc, NULL);
+ dmaengine_desc_get_callback_invoke(&sdmac->txdesc, NULL);
if (error)
sdmac->status = old_status;
@@ -749,17 +768,17 @@ static void mxc_sdma_handle_channel_normal(unsigned long data)
struct sdma_buffer_descriptor *bd;
int i, error = 0;
- sdmac->chn_real_count = 0;
+ sdmac->desc->chn_real_count = 0;
/*
* non loop mode. Iterate over all descriptors, collect
* errors and call callback function
*/
- for (i = 0; i < sdmac->num_bd; i++) {
- bd = &sdmac->bd[i];
+ for (i = 0; i < sdmac->desc->num_bd; i++) {
+ bd = &sdmac->desc->bd[i];
if (bd->mode.status & (BD_DONE | BD_RROR))
error = -EIO;
- sdmac->chn_real_count += bd->mode.count;
+ sdmac->desc->chn_real_count += bd->mode.count;
}
if (error)
@@ -767,9 +786,9 @@ static void mxc_sdma_handle_channel_normal(unsigned long data)
else
sdmac->status = DMA_COMPLETE;
- dma_cookie_complete(&sdmac->desc);
+ dma_cookie_complete(&sdmac->txdesc);
- dmaengine_desc_get_callback_invoke(&sdmac->desc, NULL);
+ dmaengine_desc_get_callback_invoke(&sdmac->txdesc, NULL);
}
static irqreturn_t sdma_int_handler(int irq, void *dev_id) @@ -897,7 +916,7 @@ static int sdma_load_context(struct sdma_channel *sdmac)
int channel = sdmac->channel;
int load_address;
struct sdma_context_data *context = sdma->context;
- struct sdma_buffer_descriptor *bd0 = sdma->channel[0].bd;
+ struct sdma_buffer_descriptor *bd0 = sdma->bd0;
int ret;
unsigned long flags;
@@ -1100,18 +1119,22 @@ static int sdma_set_channel_priority(struct sdma_channel *sdmac, static int sdma_request_channel(struct sdma_channel *sdmac) {
struct sdma_engine *sdma = sdmac->sdma;
+ struct sdma_desc *desc;
int channel = sdmac->channel;
int ret = -EBUSY;
- sdmac->bd = dma_zalloc_coherent(NULL, PAGE_SIZE, &sdmac->bd_phys,
+ sdmac->desc = &sdmac->_desc;
+ desc = sdmac->desc;
+
+ desc->bd = dma_zalloc_coherent(NULL, PAGE_SIZE, &desc->bd_phys,
GFP_KERNEL);
- if (!sdmac->bd) {
+ if (!desc->bd) {
ret = -ENOMEM;
goto out;
}
- sdma->channel_control[channel].base_bd_ptr = sdmac->bd_phys;
- sdma->channel_control[channel].current_bd_ptr = sdmac->bd_phys;
+ sdma->channel_control[channel].base_bd_ptr = desc->bd_phys;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
sdma_set_channel_priority(sdmac, MXC_SDMA_DEFAULT_PRIORITY);
return 0;
@@ -1176,10 +1199,10 @@ static int sdma_alloc_chan_resources(struct dma_chan *chan)
if (ret)
goto disable_clk_ahb;
- dma_async_tx_descriptor_init(&sdmac->desc, chan);
- sdmac->desc.tx_submit = sdma_tx_submit;
+ dma_async_tx_descriptor_init(&sdmac->txdesc, chan);
+ sdmac->txdesc.tx_submit = sdma_tx_submit;
/* txd.flags will be overwritten in prep funcs */
- sdmac->desc.flags = DMA_CTRL_ACK;
+ sdmac->txdesc.flags = DMA_CTRL_ACK;
return 0;
@@ -1194,6 +1217,7 @@ static void sdma_free_chan_resources(struct dma_chan *chan) {
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
+ struct sdma_desc *desc = sdmac->desc;
sdma_disable_channel(chan);
@@ -1207,7 +1231,7 @@ static void sdma_free_chan_resources(struct dma_chan *chan)
sdma_set_channel_priority(sdmac, 0);
- dma_free_coherent(NULL, PAGE_SIZE, sdmac->bd, sdmac->bd_phys);
+ dma_free_coherent(NULL, PAGE_SIZE, desc->bd, desc->bd_phys);
clk_disable(sdma->clk_ipg);
clk_disable(sdma->clk_ahb);
@@ -1223,6 +1247,7 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
int ret, i, count;
int channel = sdmac->channel;
struct scatterlist *sg;
+ struct sdma_desc *desc = sdmac->desc;
if (sdmac->status == DMA_IN_PROGRESS)
return NULL;
@@ -1230,9 +1255,9 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
sdmac->flags = 0;
- sdmac->buf_tail = 0;
- sdmac->buf_ptail = 0;
- sdmac->chn_real_count = 0;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->chn_real_count = 0;
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
sg_len, channel);
@@ -1249,9 +1274,9 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
goto err_out;
}
- sdmac->chn_count = 0;
+ desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
- struct sdma_buffer_descriptor *bd = &sdmac->bd[i];
+ struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
bd->buffer_addr = sg->dma_address;
@@ -1266,7 +1291,7 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
}
bd->mode.count = count;
- sdmac->chn_count += count;
+ desc->chn_count += count;
if (sdmac->word_size > DMA_SLAVE_BUSWIDTH_4_BYTES) {
ret = -EINVAL;
@@ -1307,10 +1332,10 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
bd->mode.status = param;
}
- sdmac->num_bd = sg_len;
- sdma->channel_control[channel].current_bd_ptr = sdmac->bd_phys;
+ desc->num_bd = sg_len;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
- return &sdmac->desc;
+ return &sdmac->txdesc;
err_out:
sdmac->status = DMA_ERROR;
return NULL;
@@ -1326,6 +1351,7 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
int ret, i = 0, buf = 0;
+ struct sdma_desc *desc = sdmac->desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
@@ -1334,10 +1360,10 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
sdmac->status = DMA_IN_PROGRESS;
- sdmac->buf_tail = 0;
- sdmac->buf_ptail = 0;
- sdmac->chn_real_count = 0;
- sdmac->period_len = period_len;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->chn_real_count = 0;
+ desc->period_len = period_len;
sdmac->flags |= IMX_DMA_SG_LOOP;
sdmac->direction = direction;
@@ -1358,7 +1384,7 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
}
while (buf < buf_len) {
- struct sdma_buffer_descriptor *bd = &sdmac->bd[i];
+ struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
bd->buffer_addr = dma_addr;
@@ -1389,10 +1415,10 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
i++;
}
- sdmac->num_bd = num_periods;
- sdma->channel_control[channel].current_bd_ptr = sdmac->bd_phys;
+ desc->num_bd = num_periods;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
- return &sdmac->desc;
+ return &sdmac->txdesc;
err_out:
sdmac->status = DMA_ERROR;
return NULL;
@@ -1431,13 +1457,14 @@ static enum dma_status sdma_tx_status(struct dma_chan *chan,
struct dma_tx_state *txstate) {
struct sdma_channel *sdmac = to_sdma_chan(chan);
+ struct sdma_desc *desc = sdmac->desc;
u32 residue;
if (sdmac->flags & IMX_DMA_SG_LOOP)
- residue = (sdmac->num_bd - sdmac->buf_ptail) *
- sdmac->period_len - sdmac->chn_real_count;
+ residue = (desc->num_bd - desc->buf_ptail) *
+ desc->period_len - desc->chn_real_count;
else
- residue = sdmac->chn_count - sdmac->chn_real_count;
+ residue = desc->chn_count - desc->chn_real_count;
dma_set_tx_state(txstate, chan->completed_cookie, chan->cookie,
residue);
@@ -1661,6 +1688,8 @@ static int sdma_init(struct sdma_engine *sdma)
if (ret)
goto err_dma_alloc;
+ sdma->bd0 = sdma->channel[0].desc->bd;
+
sdma_config_ownership(&sdma->channel[0], false, true, false);
/* Set Command Channel (Channel Zero) */
--
2.17.1
--
Pengutronix e.K. | |
Industrial Linux Solutions | https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pengutronix.de%2F&data=02%7C01%7Cyibin.gong%40nxp.com%7Cf4671adfeaa947506e2b08d5cd1be23d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636640442016947893&sdata=6FkizxBudOfDkWUrj28qYaycOz%2Br0bwf7DJJ8vZgaKg%3D&reserved=0 |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ 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