Re: [PATCH v13 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
On Tue, Jul 07, 2020 at 03:01:25PM +0800, Nicolas Boichat wrote:
Hi Nicolas, thanks for the replay.
> On Tue, Jun 9, 2020 at 3:20 PM Xin Ji wrote:
> >
> > The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> > for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
> >
> > Signed-off-by: Xin Ji
> > ---
> > drivers/gpu/drm/bridge/analogix/Kconfig |9 +
> > drivers/gpu/drm/bridge/analogix/Makefile |1 +
> > drivers/gpu/drm/bridge/analogix/anx7625.c | 1999
> > +
> > drivers/gpu/drm/bridge/analogix/anx7625.h | 397 ++
> > 4 files changed, 2406 insertions(+)
> > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
> > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
> >
> > [snip]
> > +static int anx7625_parse_dt(struct device *dev,
> > + struct anx7625_platform_data *pdata)
> > +{
> > + struct device_node *np = dev->of_node;
> > + struct device_node *panel_node, *out_ep;
> > +
> > + pdata->node.mipi_dsi_host_node = of_graph_get_remote_node(np, 0, 0);
> > + if (!pdata->node.mipi_dsi_host_node) {
> > + DRM_DEV_ERROR(dev, "fail to get internal panel.\n");
> > + return -EPROBE_DEFER;
>
> This does not look correct. I don't think of_graph_get_remote_node
> will ever return NULL if the device tree is configured properly, and
> it's useless to retry later (EPROBE_DEFER). You should just fail (e.g.
> return EINVAL).
OK
>
> > + }
> > +
> > + of_node_put(pdata->node.mipi_dsi_host_node);
>
> You are using pdata->node.mipi_dsi_host_node in other places in the
> code, so I don't think it's ok to call of_node_put?
I'll move the related code to here.
>
> > + DRM_DEV_DEBUG_DRIVER(dev, "found dsi host node.\n");
> > +
> > + pdata->node.panel_node = of_graph_get_port_by_id(np, 1);
> > + if (!pdata->node.panel_node) {
> > + DRM_DEV_ERROR(dev, "fail to get panel node.\n");
> > + return -EPROBE_DEFER;
>
> -EINVAL.
OK
>
> > + }
> > +
> > + of_node_put(pdata->node.panel_node);
> > + out_ep = of_get_child_by_name(pdata->node.panel_node,
> > + "endpoint");
> > + if (!out_ep) {
> > + DRM_DEV_DEBUG_DRIVER(dev, "cannot get endpoint.\n");
>
> DRM_DEV_ERROR seems more appropriate
OK, also I'll remove drm_panel based on Sam comment.
>
> > + return -EPROBE_DEFER;
>
> -EINVAL
OK
>
> > + }
> > +
> > + panel_node = of_graph_get_remote_port_parent(out_ep);
> > + of_node_put(out_ep);
> > + pdata->panel = of_drm_find_panel(panel_node);
> > + DRM_DEV_DEBUG_DRIVER(dev, "get panel node.\n");
> > +
> > + of_node_put(panel_node);
> > + if (IS_ERR_OR_NULL(pdata->panel))
> > + return -EPROBE_DEFER;
>
> of_drm_find_panel cannot return NULL, so, do this instead:
>
> if (IS_ERR(pdata->panel))
>return PTR_ERR(pdata->panel);
>
> (which actually _may_ return EPROBE_DEFER)
I'll remove drm_panel, use panel_bridge.
>
> > +
> > + return 0;
> > +}
> > [snip]
> > +static int anx7625_i2c_probe(struct i2c_client *client,
> > +const struct i2c_device_id *id)
> > +{
> > + struct anx7625_data *platform;
> > + struct anx7625_platform_data *pdata;
> > + int ret = 0;
> > + struct device *dev = &client->dev;
> > +
> > + if (!i2c_check_functionality(client->adapter,
> > +I2C_FUNC_SMBUS_I2C_BLOCK)) {
> > + DRM_DEV_ERROR(dev, "anx7625's i2c bus doesn't support\n");
> > + return -ENODEV;
> > + }
> > +
> > + platform = kzalloc(sizeof(*platform), GFP_KERNEL);
> > + if (!platform) {
> > + DRM_DEV_ERROR(dev, "fail to allocate driver data\n");
> > + return -ENOMEM;
> > + }
> > +
> > + pdata = &platform->pdata;
> > +
> > + ret = anx7625_parse_dt(dev, pdata);
> > + if (ret) {
> > + DRM_DEV_ERROR(dev, "fail to parse devicetree.\n");
>
> Please do not print this error (or at least not if err == -EPROBE_DEFER).
OK
>
> > + goto free_platform;
> > + }
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Replace HTTP links with HTTPS ones: STAGING - NVIDIA COMPLIANT EMBEDDED CONTROLLER INTERFACE (nvec)
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov --- Continuing my work started at 93431e0607e5. See also: git log --oneline '--author=Alexander A. Klimov ' v5.7..master (Actually letting a shell for loop submit all this stuff for me.) If there are any URLs to be removed completely or at least not HTTPSified: Just clearly say so and I'll *undo my change*. See also: https://lkml.org/lkml/2020/6/27/64 If there are any valid, but yet not changed URLs: See: https://lkml.org/lkml/2020/6/26/837 If you apply the patch, please let me know. drivers/staging/nvec/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/nvec/README b/drivers/staging/nvec/README index 0e2d5c4c875f..510e6933f402 100644 --- a/drivers/staging/nvec/README +++ b/drivers/staging/nvec/README @@ -10,5 +10,5 @@ but the source code[1] of the published nvec reference drivers can be a guide. This driver is currently only used by the AC100 project[2], but it is likely, that other Tegra boards (not yet mainlined, if ever) also use it. -[1] e.g. http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=tree;f=arch/arm/mach-tegra/nvec;hb=android-tegra-2.6.32 +[1] e.g. https://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=tree;f=arch/arm/mach-tegra/nvec;hb=android-tegra-2.6.32 [2] http://gitorious.org/ac100, http://launchpad.net/ac100 -- 2.27.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Replace HTTP links with HTTPS ones: STAGING - NVIDIA COMPLIANT EMBEDDED CONTROLLER INTERFACE (nvec)
You need to have a subsystem prefix in the subject. [PATCH] Staging: nvec: Replace HTTP links with HTTPS regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] media: uapi: h264: update reference lists
Hello Jernej,
I'd like to post a new H264 uAPI cleanup series soon,
would you mind resending this, or otherwise do you
mind if I include this patch in the series?
See below for a tiny comment.
On Thu, 4 Jun 2020 at 15:55, Jernej Skrabec wrote:
>
> When dealing with with interlaced frames, reference lists must tell if
> each particular reference is meant for top or bottom field. This info
> is currently not provided at all in the H264 related controls.
>
> Make reference lists hold a structure which will also hold flags along
> index into DPB array. Flags will tell if reference is meant for top or
> bottom field.
>
> Currently the only user of these lists is Cedrus which is just compile
> fixed here. Actual usage of newly introduced flags will come in
> following commit.
>
> Signed-off-by: Jernej Skrabec
> ---
> .../media/v4l/ext-ctrls-codec.rst | 40 ++-
> .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 +--
> include/media/h264-ctrls.h| 12 +-
> 3 files changed, 51 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> index d0d506a444b1..6c36d298db20 100644
> --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> @@ -1843,10 +1843,10 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
> * - __u32
>- ``slice_group_change_cycle``
>-
> -* - __u8
> +* - struct :c:type:`v4l2_h264_reference`
>- ``ref_pic_list0[32]``
>- Reference picture list after applying the per-slice modifications
> -* - __u8
> +* - struct :c:type:`v4l2_h264_reference`
>- ``ref_pic_list1[32]``
>- Reference picture list after applying the per-slice modifications
> * - __u32
> @@ -1926,6 +1926,42 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>- ``chroma_offset[32][2]``
>-
>
> +``Picture Reference``
> +
> +.. c:type:: v4l2_h264_reference
> +
> +.. cssclass:: longtable
> +
> +.. flat-table:: struct v4l2_h264_reference
> +:header-rows: 0
> +:stub-columns: 0
> +:widths: 1 1 2
> +
> +* - __u16
> + - ``flags``
> + - See :ref:`Picture Reference Flags `
> +* - __u8
> + - ``index``
> + -
> +
> +.. _h264_reference_flags:
> +
> +``Picture Reference Flags``
> +
> +.. cssclass:: longtable
> +
> +.. flat-table::
> +:header-rows: 0
> +:stub-columns: 0
> +:widths: 1 1 2
> +
> +* - ``V4L2_H264_REFERENCE_FLAG_TOP_FIELD``
> + - 0x0001
> + -
> +* - ``V4L2_H264_REFERENCE_FLAG_BOTTOM_FIELD``
> + - 0x0002
> + -
> +
> ``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS (struct)``
> Specifies the decode parameters (as extracted from the bitstream)
> for the associated H264 slice data. This includes the necessary
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> index 54ee2aa423e2..cce527bbdf86 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> @@ -166,8 +166,8 @@ static void cedrus_write_frame_list(struct cedrus_ctx
> *ctx,
>
> static void _cedrus_write_ref_list(struct cedrus_ctx *ctx,
>struct cedrus_run *run,
> - const u8 *ref_list, u8 num_ref,
> - enum cedrus_h264_sram_off sram)
> + const struct v4l2_h264_reference *ref_list,
> + u8 num_ref, enum cedrus_h264_sram_off sram)
> {
> const struct v4l2_ctrl_h264_decode_params *decode =
> run->h264.decode_params;
> struct vb2_queue *cap_q;
> @@ -188,7 +188,7 @@ static void _cedrus_write_ref_list(struct cedrus_ctx *ctx,
> int buf_idx;
> u8 dpb_idx;
>
> - dpb_idx = ref_list[i];
> + dpb_idx = ref_list[i].index;
> dpb = &decode->dpb[dpb_idx];
>
> if (!(dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE))
> diff --git a/include/media/h264-ctrls.h b/include/media/h264-ctrls.h
> index 080fd1293c42..9b1cbc9bc38e 100644
> --- a/include/media/h264-ctrls.h
> +++ b/include/media/h264-ctrls.h
> @@ -140,6 +140,14 @@ struct v4l2_h264_pred_weight_table {
> #define V4L2_H264_SLICE_FLAG_DIRECT_SPATIAL_MV_PRED0x04
> #define V4L2_H264_SLICE_FLAG_SP_FOR_SWITCH 0x08
>
> +#define V4L2_H264_REFERENCE_FLAG_TOP_FIELD 0x01
> +#define V4L2_H264_REFERENCE_FLAG_BOTTOM_FIELD 0x02
> +
> +struct v4l2_h264_reference {
> + __u8 flags;
> + __u8 index;
> +};
> +
> struct v4l2_ctrl_h264_slice_params {
> /* Size in bytes, including header */
> __u32 size;
> @@ -182,8 +190,8 @@ struct v4l2_ctrl_h264_slice_params {
> * Entries o
Re: [PATCH 1/3] media: uapi: h264: update reference lists
Hi!
Dne sreda, 08. julij 2020 ob 15:28:52 CEST je Ezequiel Garcia napisal(a):
> Hello Jernej,
>
> I'd like to post a new H264 uAPI cleanup series soon,
> would you mind resending this, or otherwise do you
> mind if I include this patch in the series?
I don't mind at all. Currently my focus was elsewhere...
>
> See below for a tiny comment.
>
> On Thu, 4 Jun 2020 at 15:55, Jernej Skrabec wrote:
> > When dealing with with interlaced frames, reference lists must tell if
> > each particular reference is meant for top or bottom field. This info
> > is currently not provided at all in the H264 related controls.
> >
> > Make reference lists hold a structure which will also hold flags along
> > index into DPB array. Flags will tell if reference is meant for top or
> > bottom field.
> >
> > Currently the only user of these lists is Cedrus which is just compile
> > fixed here. Actual usage of newly introduced flags will come in
> > following commit.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > .../media/v4l/ext-ctrls-codec.rst | 40 ++-
> > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 +--
> > include/media/h264-ctrls.h| 12 +-
> > 3 files changed, 51 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index
> > d0d506a444b1..6c36d298db20 100644
> > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > @@ -1843,10 +1843,10 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type
> > ->
> > * - __u32
> >
> >- ``slice_group_change_cycle``
> >-
> >
> > -* - __u8
> > +* - struct :c:type:`v4l2_h264_reference`
> >
> >- ``ref_pic_list0[32]``
> >- Reference picture list after applying the per-slice modifications
> >
> > -* - __u8
> > +* - struct :c:type:`v4l2_h264_reference`
> >
> >- ``ref_pic_list1[32]``
> >- Reference picture list after applying the per-slice modifications
> >
> > * - __u32
> >
> > @@ -1926,6 +1926,42 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type
> > -
> >
> >- ``chroma_offset[32][2]``
> >-
> >
> > +``Picture Reference``
> > +
> > +.. c:type:: v4l2_h264_reference
> > +
> > +.. cssclass:: longtable
> > +
> > +.. flat-table:: struct v4l2_h264_reference
> > +:header-rows: 0
> > +:stub-columns: 0
> > +:widths: 1 1 2
> > +
> > +* - __u16
> > + - ``flags``
> > + - See :ref:`Picture Reference Flags `
> > +* - __u8
> > + - ``index``
> > + -
> > +
> > +.. _h264_reference_flags:
> > +
> > +``Picture Reference Flags``
> > +
> > +.. cssclass:: longtable
> > +
> > +.. flat-table::
> > +:header-rows: 0
> > +:stub-columns: 0
> > +:widths: 1 1 2
> > +
> > +* - ``V4L2_H264_REFERENCE_FLAG_TOP_FIELD``
> > + - 0x0001
> > + -
> > +* - ``V4L2_H264_REFERENCE_FLAG_BOTTOM_FIELD``
> > + - 0x0002
> > + -
> > +
> >
> > ``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS (struct)``
> >
> > Specifies the decode parameters (as extracted from the bitstream)
> > for the associated H264 slice data. This includes the necessary
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index
> > 54ee2aa423e2..cce527bbdf86 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > @@ -166,8 +166,8 @@ static void cedrus_write_frame_list(struct cedrus_ctx
> > *ctx,>
> > static void _cedrus_write_ref_list(struct cedrus_ctx *ctx,
> >
> >struct cedrus_run *run,
> >
> > - const u8 *ref_list, u8 num_ref,
> > - enum cedrus_h264_sram_off sram)
> > + const struct v4l2_h264_reference
> > *ref_list, + u8 num_ref, enum
> > cedrus_h264_sram_off sram)>
> > {
> >
> > const struct v4l2_ctrl_h264_decode_params *decode =
> > run->h264.decode_params; struct vb2_queue *cap_q;
> >
> > @@ -188,7 +188,7 @@ static void _cedrus_write_ref_list(struct cedrus_ctx
> > *ctx,>
> > int buf_idx;
> > u8 dpb_idx;
> >
> > - dpb_idx = ref_list[i];
> > + dpb_idx = ref_list[i].index;
> >
> > dpb = &decode->dpb[dpb_idx];
> >
> > if (!(dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE))
> >
> > diff --git a/include/media/h264-ctrls.h b/include/media/h264-ctrls.h
> > index 080fd1293c42..9b1cbc9bc38e 100644
> > --- a/include/media/h264-ctrls.h
> > +++ b/include/media/h264-ctrls.h
> > @@ -140,6 +140,14 @@ struct v4l2_h264_pred_weight_table {
> >
> > #define V
[PATCH] Staging: nvec: Replace HTTP links with HTTPS ones
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov --- Continuing my work started at 93431e0607e5. See also: git log --oneline '--author=Alexander A. Klimov ' v5.7..master (Actually letting a shell for loop submit all this stuff for me.) If there are any URLs to be removed completely or at least not HTTPSified: Just clearly say so and I'll *undo my change*. See also: https://lkml.org/lkml/2020/6/27/64 If there are any valid, but yet not changed URLs: See: https://lkml.org/lkml/2020/6/26/837 If you apply the patch, please let me know. drivers/staging/nvec/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/nvec/README b/drivers/staging/nvec/README index 0e2d5c4c875f..510e6933f402 100644 --- a/drivers/staging/nvec/README +++ b/drivers/staging/nvec/README @@ -10,5 +10,5 @@ but the source code[1] of the published nvec reference drivers can be a guide. This driver is currently only used by the AC100 project[2], but it is likely, that other Tegra boards (not yet mainlined, if ever) also use it. -[1] e.g. http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=tree;f=arch/arm/mach-tegra/nvec;hb=android-tegra-2.6.32 +[1] e.g. https://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=tree;f=arch/arm/mach-tegra/nvec;hb=android-tegra-2.6.32 [2] http://gitorious.org/ac100, http://launchpad.net/ac100 -- 2.27.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-linus] BUILD SUCCESS 617894cd848f592fa84d7cf561dc80929afc66ff
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-linus branch HEAD: 617894cd848f592fa84d7cf561dc80929afc66ff Merge tag 'iio-fixes-for-5.8a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus elapsed time: 720m configs tested: 115 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allnoconfig arm allmodconfig arm allyesconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig powerpc pasemi_defconfig armcerfcube_defconfig xtensa iss_defconfig sh se7343_defconfig arm ixp4xx_defconfig sh se7780_defconfig m68k alldefconfig arc axs103_smp_defconfig arm prima2_defconfig sh sh2007_defconfig mips maltaaprp_defconfig i386 allnoconfig i386defconfig i386 debian-10.3 i386 allyesconfig ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a002-20200708 i386 randconfig-a001-20200708 i386 randconfig-a006-20200708 i386 randconfig-a005-20200708 i386 randconfig-a004-20200708 i386 randconfig-a003-20200708 i386 randconfig-a002-20200709 i386 randconfig-a001-20200709 i386 randconfig-a006-20200709 i386 randconfig-a005-20200709 i386 randconfig-a004-20200709 i386 randconfig-a003-20200709 x86_64 randconfig-a001-20200708 x86_64 randconfig-a006-20200708 x86_64 randconfig-a003-20200708 x86_64 randconfig-a002-20200708 x86_64 randconfig-a004-20200708 x86_64 randconfig-a005-20200708 i386 randconfig-a011-20200708 i386 randconfig-a015-20200708 i386 randconfig-a014-20200708 i386 randconfig-a016-20200708 i386 randconfig-a012-20200708 i386 randconfig-a013-20200708 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconf
[PATCH v7 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
The function of_dma_get_range() has been modified so that it takes a single
argument -- the device node -- and returns a map, NULL, or an error code.
The map is an array that holds the information regarding the DMA regions.
Each range entry contains the address offset, the cpu_start address, the
dma_start address, and the size of the region.
of_dma_configure() is the typical manner to set range offsets but there are
a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
driver code. These cases now invoke the function
dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 9 +-
arch/arm/mach-keystone/keystone.c | 17 ++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 +-
arch/sh/kernel/dma-coherent.c | 16 ++--
arch/x86/pci/sta2x11-fixup.c | 7 +-
drivers/acpi/arm64/iort.c | 5 +-
drivers/gpu/drm/sun4i/sun4i_backend.c | 7 +-
drivers/iommu/io-pgtable-arm.c| 2 +-
.../platform/sunxi/sun4i-csi/sun4i_csi.c | 6 +-
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 5 +-
drivers/of/address.c | 95 ++-
drivers/of/device.c | 47 +
drivers/of/of_private.h | 9 +-
drivers/of/unittest.c | 35 +--
drivers/remoteproc/remoteproc_core.c | 2 +-
.../staging/media/sunxi/cedrus/cedrus_hw.c| 8 +-
drivers/usb/core/message.c| 4 +-
drivers/usb/core/usb.c| 2 +-
include/linux/device.h| 4 +-
include/linux/dma-direct.h| 10 +-
include/linux/dma-mapping.h | 37
include/linux/pfn.h | 2 +
kernel/dma/coherent.c | 10 +-
kernel/dma/mapping.c | 53 +++
24 files changed, 277 insertions(+), 124 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index bdd80ddbca34..b7cdde9fb83d 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -35,8 +35,9 @@ static inline const struct dma_map_ops
*get_arch_dma_ops(struct bus_type *bus)
#ifndef __arch_pfn_to_dma
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
- if (dev)
- pfn -= dev->dma_pfn_offset;
+ if (dev && dev->dma_range_map)
+ pfn -= DMA_ADDR_PFN(dma_offset_from_phys_addr(dev,
PFN_PHYS(pfn)));
+
return (dma_addr_t)__pfn_to_bus(pfn);
}
@@ -44,8 +45,8 @@ static inline unsigned long dma_to_pfn(struct device *dev,
dma_addr_t addr)
{
unsigned long pfn = __bus_to_pfn(addr);
- if (dev)
- pfn += dev->dma_pfn_offset;
+ if (dev && dev->dma_range_map)
+ pfn += DMA_ADDR_PFN(dma_offset_from_dma_addr(dev, addr));
return pfn;
}
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index 638808c4e122..a1a19781983b 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -8,6 +8,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -24,8 +25,6 @@
#include "keystone.h"
-static unsigned long keystone_dma_pfn_offset __read_mostly;
-
static int keystone_platform_notifier(struct notifier_block *nb,
unsigned long event, void *data)
{
@@ -38,9 +37,12 @@ static int keystone_platform_notifier(struct notifier_block
*nb,
return NOTIFY_BAD;
if (!dev->of_node) {
- dev->dma_pfn_offset = keystone_dma_pfn_offset;
- dev_err(dev, "set dma_pfn_offset%08lx\n",
- dev->dma_pfn_offset);
+ int ret = dma_attach_offset_range(dev, KEYSTONE_HIGH_PHYS_START,
+ KEYSTONE_LOW_PHYS_START,
+ KEYSTONE_HIGH_PHYS_SIZE);
+ dev_err(dev, "set dma_offset%08llx%s\n",
+ KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START,
+ ret ? " failed" : "");
}
return NOTIFY_OK;
}
@@ -51,11 +53,8 @@ static struct notifier_block platform_nb = {
static void __init keystone_init(void)
{
- if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START) {
- keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
- KEYSTONE_LOW_PHYS_START);
+ if (PHYS_OFFSE
[PATCH v7 00/12] PCI: brcmstb: enable PCIe for STB chips
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
v7:
Commit: "device core: Introduce DMA range map, supplanting ..."
-- remove second kcalloc/copy in device.c (AndyS)
-- use PTR_ERR_OR_ZERO() and PHYS_PFN() (AndyS)
-- indentation, sizeof(struct ...) => sizeof(*r) (AndyS)
-- add pfn.h definitions: PFN_DMA_ADDR(), DMA_ADDR_PFN() (AndyS)
-- Fixed compile error in "sun6i_csi.c" (kernel test robot)
Commit "ata: ahci_brcm: Fix use of BCM7216 reset controller"
-- correct name of function in the commit msg (SergeiS)
v6:
Commit "device core: Introduce DMA range map":
-- of_dma_get_range() now takes a single argument and returns either
NULL, a valid map, or an ERR_PTR. (Robin)
-- offsets are no longer a PFN value but an actual address. (Robin)
-- the bus_dma_region struct stores the range size instead of
the cpu_end and pci_end values. (Robin)
-- devices that were setting a single offset with no boundaries
have been modified to have boundaries; in a few places
where this informatino was unavilable a /* FIXME: ... */
comment was added. (Robin)
-- dma_attach_offset_range() can be called when an offset
map already exists; if it's range is already present
nothing is done and success is returned. (Robin)
All commits:
-- Man name/style/corrections/etc changed (Bjorn)
-- rebase to Torvalds master
v5:
Commit "device core: Introduce multiple dma pfn offsets"
-- in of/address.c: "map_size = 0" => "*map_size = 0"
-- use kcalloc instead of kzalloc (AndyS)
-- use PHYS_ADDR_MAX instead of "~(phys_addr_t)0"
Commit "PCI: brcmstb: Set internal memory viewport sizes"
-- now gives error on missing dma-ranges property.
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- removed "Allof:" from brcm,scb-sizes definition (RobH)
All Commits:
-- indentation style, use max chars 100 (AndyS)
-- rebased to torvalds master
v4:
Commit "device core: Introduce multiple dma pfn offsets"
-- of_dma_get_range() does not take a dev param but instead
takes two "out" params: map and map_size. We do this so
that the code that parses dma-ranges is separate from
the code that modifies 'dev'. (Nicolas)
-- the separate case of having a single pfn offset has
been removed and is now processed by going through the
map array. (Nicolas)
-- move attach_uniform_dma_pfn_offset() from of/address.c to
dma/mapping.c so that it does not depend on CONFIG_OF. (Nicolas)
-- devm_kcalloc => devm_kzalloc (DanC)
-- add/fix assignment to dev->dma_pfn_offset_map for func
attach_uniform_dma_pfn_offset() (DanC, Nicolas)
-- s/struct dma_pfn_offset_region/struct bus_dma_region/ (Nicolas)
-- s/attach_uniform_dma_pfn_offset/dma_attach_uniform_pfn_offset/
-- s/attach_dma_pfn_offset_map/dma_attach_pfn_offset_map/
-- More use of PFN_{PHYS,DOWN,UP}. (AndyS)
Commit "of: Include a dev param in of_dma_get_range()"
-- this commit was sqaushed with "device core: Introduce ..."
v3:
Commit "device core: Introduce multiple dma pfn offsets"
Commit "arm: dma-mapping: Invoke dma offset func if needed"
-- The above two commits have been squashed. More importantly,
the code has been modified so that the functionality for
multiple pfn offsets subsumes the use of dev->dma_pfn_offset.
In fact, dma_pfn_offset is removed and supplanted by
dma_pfn_offset_map, which is a pointer to an array. The
more common case of a uniform offset is now handled as
a map with a single entry, while cases requiring multiple
pfn offsets use a map with multiple entries. Code paths
that used to do this:
dev->dma_pfn_offset = mydrivers_pfn_offset;
have been changed to do this:
attach_uniform_dma_pfn_offset(dev, pfn_offset);
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- Add if/then clause for required props: resets, reset-names (RobH)
-- Change compatible list from const to enum (RobH)
-- Change list of u32-tuples to u64 (RobH)
Commit "of: Include a dev param in of_dma_get_range()"
-- modify of/unittests.c to add NULL param in of_dma_get_range() call.
Commit "device core: Add ability to handle multiple dma offsets"
-- align comment in device.h (AndyS).
-- s/cpu_beg/cpu_start/ and s/dma_beg/dma_start/ in struct
dma_pfn_offset_region (AndyS).
v2:
Commit: "device core: Add ability to handle multiple dma offsets"
o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
o dev->dma_pfn_map => dev->dma_pfn_offset_map
o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
o In device.h: s/co
Re: [PATCH 1/3] media: uapi: h264: update reference lists
Le mercredi 08 juillet 2020 à 17:57 +0200, Jernej Škrabec a écrit :
> Hi!
>
> Dne sreda, 08. julij 2020 ob 15:28:52 CEST je Ezequiel Garcia napisal(a):
> > Hello Jernej,
> >
> > I'd like to post a new H264 uAPI cleanup series soon,
> > would you mind resending this, or otherwise do you
> > mind if I include this patch in the series?
>
> I don't mind at all. Currently my focus was elsewhere...
>
> > See below for a tiny comment.
> >
> > On Thu, 4 Jun 2020 at 15:55, Jernej Skrabec wrote:
> > > When dealing with with interlaced frames, reference lists must tell if
> > > each particular reference is meant for top or bottom field. This info
> > > is currently not provided at all in the H264 related controls.
> > >
> > > Make reference lists hold a structure which will also hold flags along
> > > index into DPB array. Flags will tell if reference is meant for top or
> > > bottom field.
> > >
> > > Currently the only user of these lists is Cedrus which is just compile
> > > fixed here. Actual usage of newly introduced flags will come in
> > > following commit.
> > >
> > > Signed-off-by: Jernej Skrabec
> > > ---
> > >
> > > .../media/v4l/ext-ctrls-codec.rst | 40 ++-
> > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 +--
> > > include/media/h264-ctrls.h| 12 +-
> > > 3 files changed, 51 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index
> > > d0d506a444b1..6c36d298db20 100644
> > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > > @@ -1843,10 +1843,10 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type
> > > ->
> > > * - __u32
> > >
> > >- ``slice_group_change_cycle``
> > >-
> > >
> > > -* - __u8
> > > +* - struct :c:type:`v4l2_h264_reference`
> > >
> > >- ``ref_pic_list0[32]``
> > >- Reference picture list after applying the per-slice modifications
> > >
> > > -* - __u8
> > > +* - struct :c:type:`v4l2_h264_reference`
> > >
> > >- ``ref_pic_list1[32]``
> > >- Reference picture list after applying the per-slice modifications
> > >
> > > * - __u32
> > >
> > > @@ -1926,6 +1926,42 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type
> > > -
> > >
> > >- ``chroma_offset[32][2]``
> > >-
> > >
> > > +``Picture Reference``
> > > +
> > > +.. c:type:: v4l2_h264_reference
> > > +
> > > +.. cssclass:: longtable
> > > +
> > > +.. flat-table:: struct v4l2_h264_reference
> > > +:header-rows: 0
> > > +:stub-columns: 0
> > > +:widths: 1 1 2
> > > +
> > > +* - __u16
> > > + - ``flags``
> > > + - See :ref:`Picture Reference Flags `
> > > +* - __u8
> > > + - ``index``
> > > + -
> > > +
> > > +.. _h264_reference_flags:
> > > +
> > > +``Picture Reference Flags``
> > > +
> > > +.. cssclass:: longtable
> > > +
> > > +.. flat-table::
> > > +:header-rows: 0
> > > +:stub-columns: 0
> > > +:widths: 1 1 2
> > > +
> > > +* - ``V4L2_H264_REFERENCE_FLAG_TOP_FIELD``
> > > + - 0x0001
> > > + -
> > > +* - ``V4L2_H264_REFERENCE_FLAG_BOTTOM_FIELD``
> > > + - 0x0002
> > > + -
> > > +
> > >
> > > ``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS (struct)``
> > >
> > > Specifies the decode parameters (as extracted from the bitstream)
> > > for the associated H264 slice data. This includes the necessary
> > >
> > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index
> > > 54ee2aa423e2..cce527bbdf86 100644
> > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > > @@ -166,8 +166,8 @@ static void cedrus_write_frame_list(struct cedrus_ctx
> > > *ctx,>
> > > static void _cedrus_write_ref_list(struct cedrus_ctx *ctx,
> > >
> > >struct cedrus_run *run,
> > >
> > > - const u8 *ref_list, u8 num_ref,
> > > - enum cedrus_h264_sram_off sram)
> > > + const struct v4l2_h264_reference
> > > *ref_list, + u8 num_ref, enum
> > > cedrus_h264_sram_off sram)>
> > > {
> > >
> > > const struct v4l2_ctrl_h264_decode_params *decode =
> > > run->h264.decode_params; struct vb2_queue *cap_q;
> > >
> > > @@ -188,7 +188,7 @@ static void _cedrus_write_ref_list(struct cedrus_ctx
> > > *ctx,>
> > > int buf_idx;
> > > u8 dpb_idx;
> > >
> > > - dpb_idx = ref_list[i];
> > > + dpb_idx = ref_list[i].index;
> > >
> > > dpb = &decode->dpb[dpb_idx];
> > >
> > >
