[PATCH v4 7/8] media: staging/imx: Improve pipeline searching
Export find_pipeline_pad(), renaming to imx_media_pipeline_pad(), and
extend its functionality to allow searching for video devices in the
enabled pipeline in addition to sub-devices.
As part of this:
- Rename imx_media_find_mipi_csi2_channel() to
imx_media_pipeline_csi2_channel().
- Remove imx_media_find_upstream_pad(), it is redundant now.
- Rename imx_media_find_upstream_subdev() to imx_media_pipeline_subdev()
with an additional boolean argument for searching upstream or downstream.
- Add imx_media_pipeline_video_device() which is analogous to
imx_media_pipeline_subdev() but searches for video devices.
- Remove imxmd pointer arg from all of the functions above, it was
never used in those functions. With that change the i.MX5/6 CSI,
VDIC, and IC sub-devices no longer require the media_device.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-ic-common.c | 4 +-
drivers/staging/media/imx/imx-ic-prp.c| 4 +-
drivers/staging/media/imx/imx-ic.h| 1 -
drivers/staging/media/imx/imx-media-csi.c | 13 +-
drivers/staging/media/imx/imx-media-fim.c | 4 -
.../staging/media/imx/imx-media-internal-sd.c | 5 +-
drivers/staging/media/imx/imx-media-utils.c | 128 ++
drivers/staging/media/imx/imx-media-vdic.c| 5 +-
drivers/staging/media/imx/imx-media.h | 20 +--
drivers/staging/media/imx/imx7-media-csi.c| 2 +-
10 files changed, 93 insertions(+), 93 deletions(-)
diff --git a/drivers/staging/media/imx/imx-ic-common.c
b/drivers/staging/media/imx/imx-ic-common.c
index ad0c291db03c..37734984beb4 100644
--- a/drivers/staging/media/imx/imx-ic-common.c
+++ b/drivers/staging/media/imx/imx-ic-common.c
@@ -22,12 +22,11 @@ static struct imx_ic_ops *ic_ops[IC_NUM_OPS] = {
[IC_TASK_VIEWFINDER] = _ic_prpencvf_ops,
};
-struct v4l2_subdev *imx_media_ic_register(struct imx_media_dev *imxmd,
+struct v4l2_subdev *imx_media_ic_register(struct v4l2_device *v4l2_dev,
struct device *ipu_dev,
struct ipu_soc *ipu,
u32 grp_id)
{
- struct v4l2_device *v4l2_dev = >v4l2_dev;
struct imx_ic_priv *priv;
int ret;
@@ -37,7 +36,6 @@ struct v4l2_subdev *imx_media_ic_register(struct
imx_media_dev *imxmd,
priv->ipu_dev = ipu_dev;
priv->ipu = ipu;
- priv->md = imxmd;
/* get our IC task id */
switch (grp_id) {
diff --git a/drivers/staging/media/imx/imx-ic-prp.c
b/drivers/staging/media/imx/imx-ic-prp.c
index 663db200e594..1432776a33f9 100644
--- a/drivers/staging/media/imx/imx-ic-prp.c
+++ b/drivers/staging/media/imx/imx-ic-prp.c
@@ -302,8 +302,8 @@ static int prp_link_validate(struct v4l2_subdev *sd,
if (ret)
return ret;
- csi = imx_media_find_upstream_subdev(ic_priv->md, _priv->sd.entity,
-IMX_MEDIA_GRP_ID_IPU_CSI);
+ csi = imx_media_pipeline_subdev(_priv->sd.entity,
+ IMX_MEDIA_GRP_ID_IPU_CSI, true);
if (IS_ERR(csi))
csi = NULL;
diff --git a/drivers/staging/media/imx/imx-ic.h
b/drivers/staging/media/imx/imx-ic.h
index 1dcbb37aeada..ff2f66f11982 100644
--- a/drivers/staging/media/imx/imx-ic.h
+++ b/drivers/staging/media/imx/imx-ic.h
@@ -16,7 +16,6 @@
struct imx_ic_priv {
struct device *ipu_dev;
struct ipu_soc *ipu;
- struct imx_media_dev *md;
struct v4l2_subdev sd;
inttask_id;
void *task_priv;
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index 68c2b1a3066a..555904759078 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -60,7 +60,6 @@ struct csi_skip_desc {
struct csi_priv {
struct device *dev;
struct ipu_soc *ipu;
- struct imx_media_dev *md;
struct v4l2_subdev sd;
struct media_pad pad[CSI_NUM_PADS];
/* the video device at IDMAC output pad */
@@ -182,8 +181,8 @@ static int csi_get_upstream_endpoint(struct csi_priv *priv,
* CSI-2 receiver if it is in the path, otherwise stay
* with video mux.
*/
- sd = imx_media_find_upstream_subdev(priv->md, src,
- IMX_MEDIA_GRP_ID_CSI2);
+ sd = imx_media_pipeline_subdev(src, IMX_MEDIA_GRP_ID_CSI2,
+ true);
if (!IS_ERR(sd))
src = >entity;
}
@@ -197,7 +196,7 @@ static int csi_get_upstream_endpoint(struct csi_priv *priv,
src = >sd.entity;
/* get source pad of entity directly upstream from src */
- pad = imx_media_find_upstream_pad(priv->md, src, 0);
+ pad = imx_media_pipeline_pad(src, 0, 0, true);
[PATCH v4 3/8] media: staging/imx: Move add_video_device into capture_device_register
Move imx_media_add_video_device() into imx_media_capture_device_register().
Also the former has no error conditions to convert to void.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-ic-prpencvf.c | 5 -
drivers/staging/media/imx/imx-media-capture.c | 3 +++
drivers/staging/media/imx/imx-media-csi.c | 7 +--
drivers/staging/media/imx/imx-media-utils.c | 9 -
drivers/staging/media/imx/imx-media.h | 4 ++--
drivers/staging/media/imx/imx7-media-csi.c| 12 +---
6 files changed, 11 insertions(+), 29 deletions(-)
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index ddcd87a17c71..8242d88dfb82 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -1241,7 +1241,6 @@ static int prp_s_frame_interval(struct v4l2_subdev *sd,
static int prp_registered(struct v4l2_subdev *sd)
{
struct prp_priv *priv = sd_to_priv(sd);
- struct imx_ic_priv *ic_priv = priv->ic_priv;
int i, ret;
u32 code;
@@ -1271,10 +1270,6 @@ static int prp_registered(struct v4l2_subdev *sd)
if (ret)
return ret;
- ret = imx_media_add_video_device(ic_priv->md, priv->vdev);
- if (ret)
- goto unreg;
-
ret = prp_init_controls(priv);
if (ret)
goto unreg;
diff --git a/drivers/staging/media/imx/imx-media-capture.c
b/drivers/staging/media/imx/imx-media-capture.c
index 211ec4df2066..335084a6b0cd 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -780,6 +780,9 @@ int imx_media_capture_device_register(struct
imx_media_video_dev *vdev)
vfd->ctrl_handler = >ctrl_hdlr;
+ /* add vdev to the video device list */
+ imx_media_add_video_device(priv->md, vdev);
+
return 0;
unreg:
video_unregister_device(vfd);
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index ea3d13103c91..c70fa6b509ae 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1820,13 +1820,8 @@ static int csi_registered(struct v4l2_subdev *sd)
if (ret)
goto free_fim;
- ret = imx_media_add_video_device(priv->md, priv->vdev);
- if (ret)
- goto unreg;
-
return 0;
-unreg:
- imx_media_capture_device_unregister(priv->vdev);
+
free_fim:
if (priv->fim)
imx_media_fim_free(priv->fim);
diff --git a/drivers/staging/media/imx/imx-media-utils.c
b/drivers/staging/media/imx/imx-media-utils.c
index c52aa59acd05..8a6e57652402 100644
--- a/drivers/staging/media/imx/imx-media-utils.c
+++ b/drivers/staging/media/imx/imx-media-utils.c
@@ -767,18 +767,17 @@ imx_media_find_subdev_by_devname(struct imx_media_dev
*imxmd,
EXPORT_SYMBOL_GPL(imx_media_find_subdev_by_devname);
/*
- * Adds a video device to the master video device list. This is called by
- * an async subdev that owns a video device when it is registered.
+ * Adds a video device to the master video device list. This is called
+ * when a video device is registered.
*/
-int imx_media_add_video_device(struct imx_media_dev *imxmd,
- struct imx_media_video_dev *vdev)
+void imx_media_add_video_device(struct imx_media_dev *imxmd,
+ struct imx_media_video_dev *vdev)
{
mutex_lock(>mutex);
list_add_tail(>list, >vdev_list);
mutex_unlock(>mutex);
- return 0;
}
EXPORT_SYMBOL_GPL(imx_media_add_video_device);
diff --git a/drivers/staging/media/imx/imx-media.h
b/drivers/staging/media/imx/imx-media.h
index ba2d75bcc4c9..71e20f53ed7b 100644
--- a/drivers/staging/media/imx/imx-media.h
+++ b/drivers/staging/media/imx/imx-media.h
@@ -189,8 +189,8 @@ imx_media_find_subdev_by_fwnode(struct imx_media_dev *imxmd,
struct v4l2_subdev *
imx_media_find_subdev_by_devname(struct imx_media_dev *imxmd,
const char *devname);
-int imx_media_add_video_device(struct imx_media_dev *imxmd,
- struct imx_media_video_dev *vdev);
+void imx_media_add_video_device(struct imx_media_dev *imxmd,
+ struct imx_media_video_dev *vdev);
int imx_media_find_mipi_csi2_channel(struct imx_media_dev *imxmd,
struct media_entity *start_entity);
struct media_pad *
diff --git a/drivers/staging/media/imx/imx7-media-csi.c
b/drivers/staging/media/imx/imx7-media-csi.c
index 96d01d8af874..f2037aba6e0e 100644
--- a/drivers/staging/media/imx/imx7-media-csi.c
+++ b/drivers/staging/media/imx/imx7-media-csi.c
@@ -1126,17 +1126,7 @@ static int imx7_csi_registered(struct v4l2_subdev *sd)
if (ret < 0)
return ret;
- ret = imx_media_capture_device_register(csi->vdev);
- if (ret < 0)
[PATCH v4 8/8] media: staging/imx: Don't set driver data for v4l2_dev
The media device is already available via multiple methods, there is no
need to set driver data for v4l2_dev to the media device.
In imx_media_link_notify(), get media device from link->graph_obj.mdev.
In imx_media_capture_device_register(), get media device from
v4l2_dev->mdev.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-media-capture.c| 5 +++--
drivers/staging/media/imx/imx-media-dev-common.c | 7 ++-
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/media/imx/imx-media-capture.c
b/drivers/staging/media/imx/imx-media-capture.c
index 8a908c3e5e60..ea7f2decfc16 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -735,15 +735,16 @@ int imx_media_capture_device_register(struct
imx_media_video_dev *vdev)
{
struct capture_priv *priv = to_capture_priv(vdev);
struct v4l2_subdev *sd = priv->src_sd;
+ struct v4l2_device *v4l2_dev = sd->v4l2_dev;
struct video_device *vfd = vdev->vfd;
struct vb2_queue *vq = >q;
struct v4l2_subdev_format fmt_src;
int ret;
/* get media device */
- priv->md = dev_get_drvdata(sd->v4l2_dev->dev);
+ priv->md = container_of(v4l2_dev->mdev, struct imx_media_dev, md);
- vfd->v4l2_dev = sd->v4l2_dev;
+ vfd->v4l2_dev = v4l2_dev;
ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
if (ret) {
diff --git a/drivers/staging/media/imx/imx-media-dev-common.c
b/drivers/staging/media/imx/imx-media-dev-common.c
index 89dc4ec8dadb..66b505f7e8df 100644
--- a/drivers/staging/media/imx/imx-media-dev-common.c
+++ b/drivers/staging/media/imx/imx-media-dev-common.c
@@ -260,10 +260,11 @@ static int imx_media_inherit_controls(struct
imx_media_dev *imxmd,
static int imx_media_link_notify(struct media_link *link, u32 flags,
unsigned int notification)
{
+ struct imx_media_dev *imxmd = container_of(link->graph_obj.mdev,
+ struct imx_media_dev, md);
struct media_entity *source = link->source->entity;
struct imx_media_pad_vdev *pad_vdev;
struct list_head *pad_vdev_list;
- struct imx_media_dev *imxmd;
struct video_device *vfd;
struct v4l2_subdev *sd;
int pad_idx, ret;
@@ -279,8 +280,6 @@ static int imx_media_link_notify(struct media_link *link,
u32 flags,
sd = media_entity_to_v4l2_subdev(source);
pad_idx = link->source->index;
- imxmd = dev_get_drvdata(sd->v4l2_dev->dev);
-
pad_vdev_list = to_pad_vdev_list(sd, pad_idx);
if (!pad_vdev_list) {
/* nothing to do if source sd has no pad vdev list */
@@ -384,8 +383,6 @@ struct imx_media_dev *imx_media_dev_init(struct device *dev,
goto cleanup;
}
- dev_set_drvdata(imxmd->v4l2_dev.dev, imxmd);
-
INIT_LIST_HEAD(>vdev_list);
v4l2_async_notifier_init(>notifier);
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 6/8] media: staging/imx: Re-organize modules
Re-organize modules, and which objects are linked into those modules, so
that:
- imx6-media (renamed from imx-media) is the media driver module for
imx5/6 only, and has no symbol exports.
- imx6-media-csi (renamed from imx-media-csi) is the subdev driver
module for imx5/6 CSI. It is now linked direcly with imx-media-fim,
since only the imx5/6 CSI makes use of the frame interval monitor.
- imx-media-common now only contains common code between imx5/6 and imx7
media drivers. It contains imx-media-utils, imx-media-of,
imx-media-dev-common, and imx-media-capture. In order to acheive that,
some functions common to imx5/6 and imx7 have been moved out of
imx-media-dev.c and into imx-media-dev-common.c.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/Makefile| 14 +-
.../staging/media/imx/imx-media-dev-common.c | 345 +-
drivers/staging/media/imx/imx-media-dev.c | 340 +
drivers/staging/media/imx/imx-media-fim.c | 5 -
drivers/staging/media/imx/imx-media-of.c | 3 +
drivers/staging/media/imx/imx-media.h | 16 +-
drivers/staging/media/imx/imx7-media-csi.c| 4 +-
7 files changed, 369 insertions(+), 358 deletions(-)
diff --git a/drivers/staging/media/imx/Makefile
b/drivers/staging/media/imx/Makefile
index 86f0c81b6a3b..aa6c4b4ad37e 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -1,14 +1,16 @@
# SPDX-License-Identifier: GPL-2.0
-imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o \
+imx6-media-objs := imx-media-dev.o imx-media-internal-sd.o \
imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o imx-media-vdic.o
-imx-media-objs += imx-media-dev-common.o
-imx-media-common-objs := imx-media-utils.o imx-media-fim.o
-obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
+imx-media-common-objs := imx-media-capture.o imx-media-dev-common.o \
+ imx-media-of.o imx-media-utils.o
+
+imx6-media-csi-objs := imx-media-csi.o imx-media-fim.o
+
+obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx6-media.o
obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
-obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-capture.o
-obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o
+obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-media-csi.o
obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o
obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o
diff --git a/drivers/staging/media/imx/imx-media-dev-common.c
b/drivers/staging/media/imx/imx-media-dev-common.c
index 6cd93419b81d..89dc4ec8dadb 100644
--- a/drivers/staging/media/imx/imx-media-dev-common.c
+++ b/drivers/staging/media/imx/imx-media-dev-common.c
@@ -8,9 +8,342 @@
#include
#include
+#include
+#include
+#include
+#include
#include "imx-media.h"
-static const struct v4l2_async_notifier_operations imx_media_subdev_ops = {
+static inline struct imx_media_dev *notifier2dev(struct v4l2_async_notifier *n)
+{
+ return container_of(n, struct imx_media_dev, notifier);
+}
+
+/* async subdev bound notifier */
+static int imx_media_subdev_bound(struct v4l2_async_notifier *notifier,
+ struct v4l2_subdev *sd,
+ struct v4l2_async_subdev *asd)
+{
+ v4l2_info(sd->v4l2_dev, "subdev %s bound\n", sd->name);
+
+ return 0;
+}
+
+/*
+ * Create the media links for all subdevs that registered.
+ * Called after all async subdevs have bound.
+ */
+static int imx_media_create_links(struct v4l2_async_notifier *notifier)
+{
+ struct imx_media_dev *imxmd = notifier2dev(notifier);
+ struct v4l2_subdev *sd;
+
+ list_for_each_entry(sd, >v4l2_dev.subdevs, list) {
+ switch (sd->grp_id) {
+ case IMX_MEDIA_GRP_ID_IPU_VDIC:
+ case IMX_MEDIA_GRP_ID_IPU_IC_PRP:
+ case IMX_MEDIA_GRP_ID_IPU_IC_PRPENC:
+ case IMX_MEDIA_GRP_ID_IPU_IC_PRPVF:
+ /*
+* links have already been created for the
+* sync-registered subdevs.
+*/
+ break;
+ case IMX_MEDIA_GRP_ID_IPU_CSI0:
+ case IMX_MEDIA_GRP_ID_IPU_CSI1:
+ case IMX_MEDIA_GRP_ID_CSI:
+ imx_media_create_csi_of_links(imxmd, sd);
+ break;
+ default:
+ /*
+* if this subdev has fwnode links, create media
+* links for them.
+*/
+ imx_media_create_of_links(imxmd, sd);
+ break;
+ }
+ }
+
+ return 0;
+}
+
+/*
+ * adds given video device to given imx-media source pad vdev list.
+ * Continues upstream from the pad entity's sink pads.
+ */
+static int imx_media_add_vdev_to_pad(struct imx_media_dev *imxmd,
+struct imx_media_video_dev *vdev,
+
[PATCH v4 2/8] media: staging/imx: Pass device to alloc/free_dma_buf
Allocate and free a DMA coherent buffer in imx_media_alloc/free_dma_buf()
from the given device. This allows DMA alloc and free using a device
that is backed by real hardware, which for the imx5/6/7 CSI is the CSI
unit, and for the internal IPU sub-devices, is the parent IPU.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-ic-prpencvf.c | 18 +-
drivers/staging/media/imx/imx-media-csi.c | 6 +++---
drivers/staging/media/imx/imx-media-utils.c | 13 ++---
drivers/staging/media/imx/imx-media.h | 4 ++--
drivers/staging/media/imx/imx7-media-csi.c | 4 ++--
5 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index 069cce512280..ddcd87a17c71 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -464,13 +464,13 @@ static int prp_setup_rotation(struct prp_priv *priv)
incc = priv->cc[PRPENCVF_SINK_PAD];
outcc = vdev->cc;
- ret = imx_media_alloc_dma_buf(ic_priv->md, >rot_buf[0],
+ ret = imx_media_alloc_dma_buf(ic_priv->ipu_dev, >rot_buf[0],
outfmt->sizeimage);
if (ret) {
v4l2_err(_priv->sd, "failed to alloc rot_buf[0], %d\n", ret);
return ret;
}
- ret = imx_media_alloc_dma_buf(ic_priv->md, >rot_buf[1],
+ ret = imx_media_alloc_dma_buf(ic_priv->ipu_dev, >rot_buf[1],
outfmt->sizeimage);
if (ret) {
v4l2_err(_priv->sd, "failed to alloc rot_buf[1], %d\n", ret);
@@ -543,9 +543,9 @@ static int prp_setup_rotation(struct prp_priv *priv)
unsetup_vb2:
prp_unsetup_vb2_buf(priv, VB2_BUF_STATE_QUEUED);
free_rot1:
- imx_media_free_dma_buf(ic_priv->md, >rot_buf[1]);
+ imx_media_free_dma_buf(ic_priv->ipu_dev, >rot_buf[1]);
free_rot0:
- imx_media_free_dma_buf(ic_priv->md, >rot_buf[0]);
+ imx_media_free_dma_buf(ic_priv->ipu_dev, >rot_buf[0]);
return ret;
}
@@ -563,8 +563,8 @@ static void prp_unsetup_rotation(struct prp_priv *priv)
ipu_ic_disable(priv->ic);
- imx_media_free_dma_buf(ic_priv->md, >rot_buf[0]);
- imx_media_free_dma_buf(ic_priv->md, >rot_buf[1]);
+ imx_media_free_dma_buf(ic_priv->ipu_dev, >rot_buf[0]);
+ imx_media_free_dma_buf(ic_priv->ipu_dev, >rot_buf[1]);
}
static int prp_setup_norotation(struct prp_priv *priv)
@@ -656,7 +656,7 @@ static int prp_start(struct prp_priv *priv)
outfmt = >fmt.fmt.pix;
- ret = imx_media_alloc_dma_buf(ic_priv->md, >underrun_buf,
+ ret = imx_media_alloc_dma_buf(ic_priv->ipu_dev, >underrun_buf,
outfmt->sizeimage);
if (ret)
goto out_put_ipu;
@@ -726,7 +726,7 @@ static int prp_start(struct prp_priv *priv)
out_unsetup:
prp_unsetup(priv, VB2_BUF_STATE_QUEUED);
out_free_underrun:
- imx_media_free_dma_buf(ic_priv->md, >underrun_buf);
+ imx_media_free_dma_buf(ic_priv->ipu_dev, >underrun_buf);
out_put_ipu:
prp_put_ipu_resources(priv);
return ret;
@@ -763,7 +763,7 @@ static void prp_stop(struct prp_priv *priv)
prp_unsetup(priv, VB2_BUF_STATE_ERROR);
- imx_media_free_dma_buf(ic_priv->md, >underrun_buf);
+ imx_media_free_dma_buf(ic_priv->ipu_dev, >underrun_buf);
/* cancel the EOF timeout timer */
del_timer_sync(>eof_timeout_timer);
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index 93b107eab5f5..ea3d13103c91 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -612,7 +612,7 @@ static int csi_idmac_start(struct csi_priv *priv)
outfmt = >fmt.fmt.pix;
- ret = imx_media_alloc_dma_buf(priv->md, >underrun_buf,
+ ret = imx_media_alloc_dma_buf(priv->dev, >underrun_buf,
outfmt->sizeimage);
if (ret)
goto out_put_ipu;
@@ -666,7 +666,7 @@ static int csi_idmac_start(struct csi_priv *priv)
out_unsetup:
csi_idmac_unsetup(priv, VB2_BUF_STATE_QUEUED);
out_free_dma_buf:
- imx_media_free_dma_buf(priv->md, >underrun_buf);
+ imx_media_free_dma_buf(priv->dev, >underrun_buf);
out_put_ipu:
csi_idmac_put_ipu_resources(priv);
return ret;
@@ -698,7 +698,7 @@ static void csi_idmac_stop(struct csi_priv *priv)
csi_idmac_unsetup(priv, VB2_BUF_STATE_ERROR);
- imx_media_free_dma_buf(priv->md, >underrun_buf);
+ imx_media_free_dma_buf(priv->dev, >underrun_buf);
/* cancel the EOF timeout timer */
del_timer_sync(>eof_timeout_timer);
diff --git a/drivers/staging/media/imx/imx-media-utils.c
b/drivers/staging/media/imx/imx-media-utils.c
index 1c63a2765a81..c52aa59acd05 100644
--- a/drivers/staging/media/imx/imx-media-utils.c
[PATCH v4 4/8] Revert "media: imx: Set capture compose rectangle in capture_device_set_format"
Rvert this commit, as imx_media_capture_device_set_format() will be
removed. The arguments to mx_media_mbus_fmt_to_pix_fmt() and
imx_media_capture_device_set_format() in imx7_csi_set_fmt() are also
reverted.
This reverts commit 5964cbd8692252615370b77eb96764dd70c2f837.
Signed-off-by: Steve Longerbeam
---
Chnges in v3:
- revert to previous args in imx7_csi_set_fmt().
---
drivers/staging/media/imx/imx-ic-prpencvf.c | 5 ++--
drivers/staging/media/imx/imx-media-capture.c | 24 +--
drivers/staging/media/imx/imx-media-csi.c | 5 ++--
drivers/staging/media/imx/imx-media-utils.c | 20
drivers/staging/media/imx/imx-media.h | 6 ++---
drivers/staging/media/imx/imx7-media-csi.c| 5 ++--
6 files changed, 25 insertions(+), 40 deletions(-)
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index 8242d88dfb82..afaa3a8b15e9 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -910,7 +910,6 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
const struct imx_media_pixfmt *cc;
struct v4l2_pix_format vdev_fmt;
struct v4l2_mbus_framefmt *fmt;
- struct v4l2_rect vdev_compose;
int ret = 0;
if (sdformat->pad >= PRPENCVF_NUM_PADS)
@@ -952,11 +951,11 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
priv->cc[sdformat->pad] = cc;
/* propagate output pad format to capture device */
- imx_media_mbus_fmt_to_pix_fmt(_fmt, _compose,
+ imx_media_mbus_fmt_to_pix_fmt(_fmt,
>format_mbus[PRPENCVF_SRC_PAD],
priv->cc[PRPENCVF_SRC_PAD]);
mutex_unlock(>lock);
- imx_media_capture_device_set_format(vdev, _fmt, _compose);
+ imx_media_capture_device_set_format(vdev, _fmt);
return 0;
out:
diff --git a/drivers/staging/media/imx/imx-media-capture.c
b/drivers/staging/media/imx/imx-media-capture.c
index 335084a6b0cd..555f6204660b 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -205,8 +205,7 @@ static int capture_g_fmt_vid_cap(struct file *file, void
*fh,
static int __capture_try_fmt_vid_cap(struct capture_priv *priv,
struct v4l2_subdev_format *fmt_src,
-struct v4l2_format *f,
-struct v4l2_rect *compose)
+struct v4l2_format *f)
{
const struct imx_media_pixfmt *cc, *cc_src;
@@ -246,8 +245,7 @@ static int __capture_try_fmt_vid_cap(struct capture_priv
*priv,
}
}
- imx_media_mbus_fmt_to_pix_fmt(>fmt.pix, compose,
- _src->format, cc);
+ imx_media_mbus_fmt_to_pix_fmt(>fmt.pix, _src->format, cc);
return 0;
}
@@ -265,7 +263,7 @@ static int capture_try_fmt_vid_cap(struct file *file, void
*fh,
if (ret)
return ret;
- return __capture_try_fmt_vid_cap(priv, _src, f, NULL);
+ return __capture_try_fmt_vid_cap(priv, _src, f);
}
static int capture_s_fmt_vid_cap(struct file *file, void *fh,
@@ -273,7 +271,6 @@ static int capture_s_fmt_vid_cap(struct file *file, void
*fh,
{
struct capture_priv *priv = video_drvdata(file);
struct v4l2_subdev_format fmt_src;
- struct v4l2_rect compose;
int ret;
if (vb2_is_busy(>q)) {
@@ -287,14 +284,17 @@ static int capture_s_fmt_vid_cap(struct file *file, void
*fh,
if (ret)
return ret;
- ret = __capture_try_fmt_vid_cap(priv, _src, f, );
+ ret = __capture_try_fmt_vid_cap(priv, _src, f);
if (ret)
return ret;
priv->vdev.fmt.fmt.pix = f->fmt.pix;
priv->vdev.cc = imx_media_find_format(f->fmt.pix.pixelformat,
CS_SEL_ANY, true);
- priv->vdev.compose = compose;
+ priv->vdev.compose.left = 0;
+ priv->vdev.compose.top = 0;
+ priv->vdev.compose.width = fmt_src.format.width;
+ priv->vdev.compose.height = fmt_src.format.height;
return 0;
}
@@ -655,8 +655,7 @@ static struct video_device capture_videodev = {
};
void imx_media_capture_device_set_format(struct imx_media_video_dev *vdev,
-const struct v4l2_pix_format *pix,
-const struct v4l2_rect *compose)
+struct v4l2_pix_format *pix)
{
struct capture_priv *priv = to_capture_priv(vdev);
@@ -664,7 +663,6 @@ void imx_media_capture_device_set_format(struct
imx_media_video_dev *vdev,
priv->vdev.fmt.fmt.pix = *pix;
priv->vdev.cc = imx_media_find_format(pix->pixelformat, CS_SEL_ANY,
true);
-
[PATCH v4 5/8] media: staging/imx: Remove capture_device_set_format
Don't propagate the source pad format to the connected capture device.
It's now the responsibility of userspace to call VIDIOC_S_FMT on the
capture device to ensure the capture format and compose rectangle
are compatible with the connected source. To check this, validate
the capture format with the source before streaming starts.
Signed-off-by: Steve Longerbeam
---
Changes in v4:
- add **cc arg to __capture_try_fmt_vid_cap() to validate colorspace,
instead of calling ipu_pixelformat_to_colorspace().
- add error message if capture format validation failed.
---
drivers/staging/media/imx/imx-ic-prpencvf.c | 16 +
drivers/staging/media/imx/imx-media-capture.c | 71 +--
drivers/staging/media/imx/imx-media-csi.c | 16 +
drivers/staging/media/imx/imx-media.h | 2 -
drivers/staging/media/imx/imx7-media-csi.c| 17 +
5 files changed, 55 insertions(+), 67 deletions(-)
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index afaa3a8b15e9..63334fd61492 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -906,9 +906,7 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
struct v4l2_subdev_format *sdformat)
{
struct prp_priv *priv = sd_to_priv(sd);
- struct imx_media_video_dev *vdev = priv->vdev;
const struct imx_media_pixfmt *cc;
- struct v4l2_pix_format vdev_fmt;
struct v4l2_mbus_framefmt *fmt;
int ret = 0;
@@ -945,19 +943,9 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
priv->cc[PRPENCVF_SRC_PAD] = outcc;
}
- if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY)
- goto out;
-
- priv->cc[sdformat->pad] = cc;
+ if (sdformat->which == V4L2_SUBDEV_FORMAT_ACTIVE)
+ priv->cc[sdformat->pad] = cc;
- /* propagate output pad format to capture device */
- imx_media_mbus_fmt_to_pix_fmt(_fmt,
- >format_mbus[PRPENCVF_SRC_PAD],
- priv->cc[PRPENCVF_SRC_PAD]);
- mutex_unlock(>lock);
- imx_media_capture_device_set_format(vdev, _fmt);
-
- return 0;
out:
mutex_unlock(>lock);
return ret;
diff --git a/drivers/staging/media/imx/imx-media-capture.c
b/drivers/staging/media/imx/imx-media-capture.c
index 555f6204660b..8a908c3e5e60 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -205,7 +205,9 @@ static int capture_g_fmt_vid_cap(struct file *file, void
*fh,
static int __capture_try_fmt_vid_cap(struct capture_priv *priv,
struct v4l2_subdev_format *fmt_src,
-struct v4l2_format *f)
+struct v4l2_format *f,
+const struct imx_media_pixfmt **retcc,
+struct v4l2_rect *compose)
{
const struct imx_media_pixfmt *cc, *cc_src;
@@ -247,6 +249,16 @@ static int __capture_try_fmt_vid_cap(struct capture_priv
*priv,
imx_media_mbus_fmt_to_pix_fmt(>fmt.pix, _src->format, cc);
+ if (retcc)
+ *retcc = cc;
+
+ if (compose) {
+ compose->left = 0;
+ compose->top = 0;
+ compose->width = fmt_src->format.width;
+ compose->height = fmt_src->format.height;
+ }
+
return 0;
}
@@ -263,7 +275,7 @@ static int capture_try_fmt_vid_cap(struct file *file, void
*fh,
if (ret)
return ret;
- return __capture_try_fmt_vid_cap(priv, _src, f);
+ return __capture_try_fmt_vid_cap(priv, _src, f, NULL, NULL);
}
static int capture_s_fmt_vid_cap(struct file *file, void *fh,
@@ -284,17 +296,12 @@ static int capture_s_fmt_vid_cap(struct file *file, void
*fh,
if (ret)
return ret;
- ret = __capture_try_fmt_vid_cap(priv, _src, f);
+ ret = __capture_try_fmt_vid_cap(priv, _src, f, >vdev.cc,
+ >vdev.compose);
if (ret)
return ret;
priv->vdev.fmt.fmt.pix = f->fmt.pix;
- priv->vdev.cc = imx_media_find_format(f->fmt.pix.pixelformat,
- CS_SEL_ANY, true);
- priv->vdev.compose.left = 0;
- priv->vdev.compose.top = 0;
- priv->vdev.compose.width = fmt_src.format.width;
- priv->vdev.compose.height = fmt_src.format.height;
return 0;
}
@@ -524,6 +531,33 @@ static void capture_buf_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(>q_lock, flags);
}
+static int capture_validate_fmt(struct capture_priv *priv)
+{
+ struct v4l2_subdev_format fmt_src;
+ const struct imx_media_pixfmt *cc;
+ struct v4l2_rect compose;
+ struct v4l2_format f;
+ int ret;
+
+
[PATCH v4 1/8] media: staging/imx: Switch to sync registration for IPU subdevs
Because the IPU sub-devices VDIC and IC are not present in the
device-tree, platform devices were created for them instead. This
allowed these sub-devices to be added to the media device's async
notifier and registered asynchronously along with the other
sub-devices that do have a device-tree presence (CSI and devices
external to the IPU and SoC).
But that approach isn't really necessary. The IPU sub-devices don't
actually require a backing device (sd->dev is allowed to be NULL).
And that approach can't get around the fact that the IPU sub-devices
are not part of a device hierarchy, which makes it awkward to retrieve
the parent IPU of these devices.
By registering them synchronously, they can be registered from the CSI
async bound notifier, so the init function for them can be given the CSI
subdev, who's dev->parent is the IPU. That is a somewhat cleaner way
to retrieve the parent IPU.
So convert to synchronous registration for the VDIC and IC task
sub-devices, at the time a CSI sub-device is bound. There is no longer
a backing device for them (sd->dev is NULL), but that's ok. Also
set the VDIC/IC sub-device owner as the IPU, so that a reference can
be taken on the IPU module.
Since the VDIC and IC task drivers are no longer platform drivers,
they are now statically linked to imx-media module.
Signed-off-by: Steve Longerbeam
---
Changes in v3:
- statically link VDIC and IC task objects to imx-media module in
Makefile.
---
drivers/staging/media/imx/Makefile| 6 +-
drivers/staging/media/imx/imx-ic-common.c | 70 ++--
drivers/staging/media/imx/imx-ic-prp.c| 34 +-
drivers/staging/media/imx/imx-ic-prpencvf.c | 70 ++--
drivers/staging/media/imx/imx-ic.h| 7 +-
drivers/staging/media/imx/imx-media-capture.c | 7 +-
drivers/staging/media/imx/imx-media-csi.c | 2 +-
drivers/staging/media/imx/imx-media-dev.c | 121 +-
.../staging/media/imx/imx-media-internal-sd.c | 356 --
drivers/staging/media/imx/imx-media-of.c | 38 +-
drivers/staging/media/imx/imx-media-vdic.c| 85 ++---
drivers/staging/media/imx/imx-media.h | 67 ++--
drivers/staging/media/imx/imx7-media-csi.c| 3 +-
13 files changed, 327 insertions(+), 539 deletions(-)
diff --git a/drivers/staging/media/imx/Makefile
b/drivers/staging/media/imx/Makefile
index d2d909a36239..86f0c81b6a3b 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -1,14 +1,12 @@
# SPDX-License-Identifier: GPL-2.0
-imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o
+imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o \
+ imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o imx-media-vdic.o
imx-media-objs += imx-media-dev-common.o
imx-media-common-objs := imx-media-utils.o imx-media-fim.o
-imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o
obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-capture.o
-obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-vdic.o
-obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-ic.o
obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o
obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o
diff --git a/drivers/staging/media/imx/imx-ic-common.c
b/drivers/staging/media/imx/imx-ic-common.c
index 1addb0893c57..ad0c291db03c 100644
--- a/drivers/staging/media/imx/imx-ic-common.c
+++ b/drivers/staging/media/imx/imx-ic-common.c
@@ -8,8 +8,6 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
-#include
-#include
#include
#include
#include "imx-media.h"
@@ -24,23 +22,25 @@ static struct imx_ic_ops *ic_ops[IC_NUM_OPS] = {
[IC_TASK_VIEWFINDER] = _ic_prpencvf_ops,
};
-static int imx_ic_probe(struct platform_device *pdev)
+struct v4l2_subdev *imx_media_ic_register(struct imx_media_dev *imxmd,
+ struct device *ipu_dev,
+ struct ipu_soc *ipu,
+ u32 grp_id)
{
- struct imx_media_ipu_internal_sd_pdata *pdata;
+ struct v4l2_device *v4l2_dev = >v4l2_dev;
struct imx_ic_priv *priv;
int ret;
- priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+ priv = devm_kzalloc(ipu_dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
- platform_set_drvdata(pdev, >sd);
- priv->dev = >dev;
+ priv->ipu_dev = ipu_dev;
+ priv->ipu = ipu;
+ priv->md = imxmd;
- /* get our ipu_id, grp_id and IC task id */
- pdata = priv->dev->platform_data;
- priv->ipu_id = pdata->ipu_id;
- switch (pdata->grp_id) {
+ /* get our IC task id */
+ switch (grp_id) {
case IMX_MEDIA_GRP_ID_IPU_IC_PRP:
priv->task_id = IC_TASK_PRP;
RFC: kpc2000 driver naming
Hello, Recently Greg KH posted the first set of drivers for our PCIe device (kpc2000) and shortly after that I posted the kpc2000_dma driver. I was wondering about naming / structure standards in the Linux kernel. First, a real quick background on these devices: Daktronics makes a PCIe card with an FPGA on it to drive our LED displays (and other processing tasks). Inside the FPGA, we use something similar to AXI-4 to divide the PCIe BAR register space [1] into separate "IP cores". The kpc2000 driver is responsible for probing the PCIe device, doing some basic setup (mapping the BAR, setting up an IRQ, PCIe configuration, etc) and then enumerating these "cores". Enumeration of the cores is facilitated by the "board info" core that is always at the beginning of the BAR and has a defined format. Most of the cores are controlled entirely by userspace - the driver will add a UIO sub device for each one which userspace uses to control FPGA registers. Only 3 core types are handled by drivers: DMA, I2C, SPI. These are IP cores inside the FPGA that (in the case of i2c and spi) interact with other physical devices on the PCIe card. Currently, we only have the one PCIe device (the "P2K" card) but we have more on our roadmap (one we've been calling "p3k" internally). I'm 99% confident that the I2C and SPI cores will be exactly the same on the new FPGA design. I'm 80% confident that the DMA engines themselves will be exactly the same on the new FPGA design. The next card PCIe driver will quite likely be separate from the kpc2000 driver because how bitstreams are stored / loaded / configured is changing due to using a newer FPGA. There will likely be common code between the two. Now on to my actual questions: Once the drivers are "good enough" to be moved outside of staging, I'm wondering where the drivers will end up and what their names will/should be. Since the I2C and SPI drivers are single-file, I'm guessing they're going to move to drivers/i2c/busses/i2c-dak/ and drivers/spi/spi-dak/, respectively. I tweaked the names, since "i2c-dak" and "spi-dak" make more sense to me than "kpc_i2c" and "kpc_spi". So that leaves the DMA and main PCIe drivers. Where do those end up in the tree? Would "dak-dma" and "dak-p2k" (and eventually "dak-p3k") make more sense as names for those drivers? The final question relates to how Kconfig entries are setup. The I2C, SPI, and DMA drivers could be "selected" on their own (even if the "dak-p2k" and "dak-p3k" drivers aren't selected), but that doesn't make much sense because they'd never get used in that configuration. Conversely, if you select the "dak-p2k" driver, the I2C, SPI, and DMA drivers better get selected too, otherwise the device won't function correctly. From what I can tell with Kconfig, if A depends on B, you can't even see (let alone select) A without already selecting B. Right now, the Kconfig entries are setup like this (using the current names, not the new ones presented above): KPC2000_DMA depends on KPC2000 (this compiles the kpc2000_dma driver) KPC2000_I2C depends on KPC2000 && I2C (this compiles the kpc2000_i2c driver) KPC2000_SPI depends on KPC2000 && SPI (this compiles the kpc2000_spi driver) KPC2000_CORE depends on KPC2000 KPC2000 depends on PCI (this compiles the kpc2000 driver) Greg, what is the purpose of the KPC2000_CORE config option? Nothing (that I see) depends on it, and it doesn't cause any code to get compiled. I would have thought something like this makes more sense [2]: KPC2000_DMA depends nothing KPC2000_I2C depends on I2C KPC2000_SPI depends on SPI KPC2000 depends on PCI && KPC2000_DMA && KPC2000_I2C && KPC2000_SPI Which way is "better"? Does it even matter which way it's setup? [1] Technically, there are two BARs. The first one is primarily registers for the DMA engines. The second one is dedicated to our IP cores. [2] Using the new naming, and taking the p3k future into account: DAK_DMA depends on nothing DAK_I2C depends on I2C DAK_SPI depends on SPI DAK_P2K depends on PCI && DAK_DMA && DAK_I2C && DAK_SPI DAK_P3K depends on PCI && DAK_DMA && DAK_I2C && DAK_SPI Thanks, Matt Sickler ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] staging: iio: ad7150: clean up of comments
General cleaning of comments to remove useless information or improve
description.
Signed-off-by: Melissa Wen
---
drivers/staging/iio/cdc/ad7150.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/iio/cdc/ad7150.c b/drivers/staging/iio/cdc/ad7150.c
index 3a4572a9e5ec..775818b0761e 100644
--- a/drivers/staging/iio/cdc/ad7150.c
+++ b/drivers/staging/iio/cdc/ad7150.c
@@ -162,7 +162,8 @@ static int ad7150_read_event_config(struct iio_dev
*indio_dev,
return -EINVAL;
}
-/* lock should be held */
+/* state_lock should be held to ensure consistent state*/
+
static int ad7150_write_event_params(struct iio_dev *indio_dev,
unsigned int chan,
enum iio_event_type type,
@@ -484,10 +485,6 @@ static const struct iio_chan_spec ad7150_channels[] = {
},
};
-/*
- * threshold events
- */
-
static irqreturn_t ad7150_event_handler(int irq, void *private)
{
struct iio_dev *indio_dev = private;
@@ -576,10 +573,6 @@ static const struct iio_info ad7150_info = {
.write_event_value = _write_event_value,
};
-/*
- * device probe and remove
- */
-
static int ad7150_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] staging: iio: ad7150: simplify i2c SMBus return treatment
Since i2c_smbus_write_byte_data returns no-positive value, this commit making the treatment of its return value less verbose. Signed-off-by: Melissa Wen --- drivers/staging/iio/cdc/ad7150.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/staging/iio/cdc/ad7150.c b/drivers/staging/iio/cdc/ad7150.c index 4ba46fb6ac02..3a4572a9e5ec 100644 --- a/drivers/staging/iio/cdc/ad7150.c +++ b/drivers/staging/iio/cdc/ad7150.c @@ -201,16 +201,12 @@ static int ad7150_write_event_params(struct iio_dev *indio_dev, ret = i2c_smbus_write_byte_data(chip->client, ad7150_addresses[chan][4], sens); - if (ret < 0) + if (ret) return ret; - - ret = i2c_smbus_write_byte_data(chip->client, + else + return i2c_smbus_write_byte_data(chip->client, ad7150_addresses[chan][5], timeout); - if (ret < 0) - return ret; - - return 0; } static int ad7150_write_event_config(struct iio_dev *indio_dev, -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] staging: iio: ad7150: organize registers definition
Use the suffix REG to make the register addresses clear
and indentation to highlight field names.
Signed-off-by: Melissa Wen
---
drivers/staging/iio/cdc/ad7150.c | 75
1 file changed, 37 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/iio/cdc/ad7150.c b/drivers/staging/iio/cdc/ad7150.c
index dd7fcab8e19e..24601ba7db88 100644
--- a/drivers/staging/iio/cdc/ad7150.c
+++ b/drivers/staging/iio/cdc/ad7150.c
@@ -15,35 +15,34 @@
#include
#include
#include
-/*
- * AD7150 registers definition
- */
-#define AD7150_STATUS 0
-#define AD7150_STATUS_OUT1 BIT(3)
-#define AD7150_STATUS_OUT2 BIT(5)
-#define AD7150_CH1_DATA_HIGH 1
-#define AD7150_CH2_DATA_HIGH 3
-#define AD7150_CH1_AVG_HIGH5
-#define AD7150_CH2_AVG_HIGH7
-#define AD7150_CH1_SENSITIVITY 9
-#define AD7150_CH1_THR_HOLD_H 9
-#define AD7150_CH1_TIMEOUT 10
-#define AD7150_CH1_SETUP 11
-#define AD7150_CH2_SENSITIVITY 12
-#define AD7150_CH2_THR_HOLD_H 12
-#define AD7150_CH2_TIMEOUT 13
-#define AD7150_CH2_SETUP 14
-#define AD7150_CFG 15
-#define AD7150_CFG_FIX BIT(7)
-#define AD7150_PD_TIMER16
-#define AD7150_CH1_CAPDAC 17
-#define AD7150_CH2_CAPDAC 18
-#define AD7150_SN3 19
-#define AD7150_SN2 20
-#define AD7150_SN1 21
-#define AD7150_SN0 22
-#define AD7150_ID 23
+/* AD7150 registers */
+
+#define AD7150_STATUS_REG 0x00
+#define AD7150_STATUS_OUT1 BIT(3)
+#define AD7150_STATUS_OUT2 BIT(5)
+#define AD7150_CH1_DATA_HIGH_REG 0x01
+#define AD7150_CH2_DATA_HIGH_REG 0x03
+#define AD7150_CH1_AVG_HIGH_REG0x05
+#define AD7150_CH2_AVG_HIGH_REG0x07
+#define AD7150_CH1_SENSITIVITY_REG 0x09
+#define AD7150_CH1_THR_HOLD_H_REG 0x09
+#define AD7150_CH2_SENSITIVITY_REG 0x0C
+#define AD7150_CH1_TIMEOUT_REG 0x0A
+#define AD7150_CH1_SETUP_REG 0x0B
+#define AD7150_CH2_THR_HOLD_H_REG 0x0C
+#define AD7150_CH2_TIMEOUT_REG 0x0D
+#define AD7150_CH2_SETUP_REG 0x0E
+#define AD7150_CFG_REG 0x0F
+#define AD7150_CFG_FIX BIT(7)
+#define AD7150_PD_TIMER_REG0x10
+#define AD7150_CH1_CAPDAC_REG 0x11
+#define AD7150_CH2_CAPDAC_REG 0x12
+#define AD7150_SN3_REG 0x13
+#define AD7150_SN2_REG 0x14
+#define AD7150_SN1_REG 0x15
+#define AD7150_SN0_REG 0x16
+#define AD7150_ID_REG 0x17
/**
* struct ad7150_chip_info - instance specific chip data
@@ -85,12 +84,12 @@ struct ad7150_chip_info {
*/
static const u8 ad7150_addresses[][6] = {
- { AD7150_CH1_DATA_HIGH, AD7150_CH1_AVG_HIGH,
- AD7150_CH1_SETUP, AD7150_CH1_THR_HOLD_H,
- AD7150_CH1_SENSITIVITY, AD7150_CH1_TIMEOUT },
- { AD7150_CH2_DATA_HIGH, AD7150_CH2_AVG_HIGH,
- AD7150_CH2_SETUP, AD7150_CH2_THR_HOLD_H,
- AD7150_CH2_SENSITIVITY, AD7150_CH2_TIMEOUT },
+ { AD7150_CH1_DATA_HIGH_REG, AD7150_CH1_AVG_HIGH_REG,
+ AD7150_CH1_SETUP_REG, AD7150_CH1_THR_HOLD_H_REG,
+ AD7150_CH1_SENSITIVITY_REG, AD7150_CH1_TIMEOUT_REG },
+ { AD7150_CH2_DATA_HIGH_REG, AD7150_CH2_AVG_HIGH_REG,
+ AD7150_CH2_SETUP_REG, AD7150_CH2_THR_HOLD_H_REG,
+ AD7150_CH2_SENSITIVITY_REG, AD7150_CH2_TIMEOUT_REG },
};
static int ad7150_read_raw(struct iio_dev *indio_dev,
@@ -133,7 +132,7 @@ static int ad7150_read_event_config(struct iio_dev
*indio_dev,
bool adaptive;
struct ad7150_chip_info *chip = iio_priv(indio_dev);
- ret = i2c_smbus_read_byte_data(chip->client, AD7150_CFG);
+ ret = i2c_smbus_read_byte_data(chip->client, AD7150_CFG_REG);
if (ret < 0)
return ret;
@@ -229,7 +228,7 @@ static int ad7150_write_event_config(struct iio_dev
*indio_dev,
if (event_code == chip->current_event)
return 0;
mutex_lock(>state_lock);
- ret = i2c_smbus_read_byte_data(chip->client, AD7150_CFG);
+ ret = i2c_smbus_read_byte_data(chip->client, AD7150_CFG_REG);
if (ret < 0)
goto error_ret;
@@ -264,7 +263,7 @@ static int ad7150_write_event_config(struct iio_dev
*indio_dev,
cfg |= (!adaptive << 7) | (thresh_type << 5);
- ret = i2c_smbus_write_byte_data(chip->client, AD7150_CFG, cfg);
+ ret = i2c_smbus_write_byte_data(chip->client, AD7150_CFG_REG, cfg);
if (ret < 0)
goto error_ret;
@@ -497,7 +496,7 @@ static irqreturn_t ad7150_event_handler(int irq, void
[PATCH 2/4] staging: iio: ad7150: use FIELD_GET and GENMASK
Use the bitfield macro FIELD_GET, and GENMASK to do the shift and mask in
one go. This makes the code more readable than explicit masking followed
by a shift.
Signed-off-by: Melissa Wen
---
drivers/staging/iio/cdc/ad7150.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/iio/cdc/ad7150.c b/drivers/staging/iio/cdc/ad7150.c
index 24601ba7db88..4ba46fb6ac02 100644
--- a/drivers/staging/iio/cdc/ad7150.c
+++ b/drivers/staging/iio/cdc/ad7150.c
@@ -5,6 +5,7 @@
* Copyright 2010-2011 Analog Devices Inc.
*/
+#include
#include
#include
#include
@@ -44,6 +45,9 @@
#define AD7150_SN0_REG 0x16
#define AD7150_ID_REG 0x17
+/* AD7150 masks */
+#define AD7150_THRESHTYPE_MSK GENMASK(6, 5)
+
/**
* struct ad7150_chip_info - instance specific chip data
* @client: i2c client for this device
@@ -136,7 +140,7 @@ static int ad7150_read_event_config(struct iio_dev
*indio_dev,
if (ret < 0)
return ret;
- threshtype = (ret >> 5) & 0x03;
+ threshtype = FIELD_GET(AD7150_THRESHTYPE_MSK, ret);
adaptive = !!(ret & 0x80);
switch (type) {
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/4] staging: iio: ad7150: improve driver readability
This patchset solves readability issues in AD7150 code, such as clarify register and mask definition, fashion improvement of mask uses, reduce tedious operation and useless comments. Melissa Wen (4): staging: iio: ad7150: organize registers definition staging: iio: ad7150: use FIELD_GET and GENMASK staging: iio: ad7150: simplify i2c SMBus return treatment staging: iio: ad7150: clean up of comments drivers/staging/iio/cdc/ad7150.c | 102 ++- 1 file changed, 47 insertions(+), 55 deletions(-) -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 08/10] staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error
On Fri, May 03, 2019 at 09:07:30PM +0200, Petr Štetiar wrote: > Dan Carpenter [2019-05-03 13:34:56]: > > Hi, > > > On Fri, May 03, 2019 at 09:56:05AM +0200, Petr Štetiar wrote: > > > There was NVMEM support added to of_get_mac_address, so it could now > > > return NULL and ERR_PTR encoded error values, so we need to adjust all > > > current users of of_get_mac_address to this new fact. > > > > Which commit added NVMEM support? It hasn't hit net-next or linux-next > > yet... Very strange. > > this patch is a part of the patch series[1], where the 1st patch[2] adds this > NVMEM support to of_get_mac_address and follow-up patches are adjusting > current of_get_mac_address users to the new ERR_PTR return value. Basically all the patches need to be folded together otherwise you're breaking git bisectibility. Imagine that we just apply patch #1 right? Then all the callers will be broken. It's not allowed. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: rtl8723bs: os_dep: Fix switch-case indentation error
Fix indentation for switch-case statements to fix following
checkpatch.pl Error:
ERROR: switch and case should be at the same indent
Signed-off-by: Puranjay Mohan
---
.../staging/rtl8723bs/os_dep/ioctl_linux.c| 442 +-
1 file changed, 221 insertions(+), 221 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index e3d356952875..9a1192e10e13 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -1671,45 +1671,45 @@ static int rtw_wx_set_rate(struct net_device *dev,
target_rate = target_rate/10;
switch (target_rate) {
- case 10:
- ratevalue = 0;
- break;
- case 20:
- ratevalue = 1;
- break;
- case 55:
- ratevalue = 2;
- break;
- case 60:
- ratevalue = 3;
- break;
- case 90:
- ratevalue = 4;
- break;
- case 110:
- ratevalue = 5;
- break;
- case 120:
- ratevalue = 6;
- break;
- case 180:
- ratevalue = 7;
- break;
- case 240:
- ratevalue = 8;
- break;
- case 360:
- ratevalue = 9;
- break;
- case 480:
- ratevalue = 10;
- break;
- case 540:
- ratevalue = 11;
- break;
- default:
- ratevalue = 11;
- break;
+ case 10:
+ ratevalue = 0;
+ break;
+ case 20:
+ ratevalue = 1;
+ break;
+ case 55:
+ ratevalue = 2;
+ break;
+ case 60:
+ ratevalue = 3;
+ break;
+ case 90:
+ ratevalue = 4;
+ break;
+ case 110:
+ ratevalue = 5;
+ break;
+ case 120:
+ ratevalue = 6;
+ break;
+ case 180:
+ ratevalue = 7;
+ break;
+ case 240:
+ ratevalue = 8;
+ break;
+ case 360:
+ ratevalue = 9;
+ break;
+ case 480:
+ ratevalue = 10;
+ break;
+ case 540:
+ ratevalue = 11;
+ break;
+ default:
+ ratevalue = 11;
+ break;
}
set_rate:
@@ -2267,22 +2267,22 @@ static int rtw_wx_read32(struct net_device *dev,
sscanf(ptmp, "%d,%x", , );
switch (bytes) {
- case 1:
- data32 = rtw_read8(padapter, addr);
- sprintf(extra, "0x%02X", data32);
- break;
- case 2:
- data32 = rtw_read16(padapter, addr);
- sprintf(extra, "0x%04X", data32);
- break;
- case 4:
- data32 = rtw_read32(padapter, addr);
- sprintf(extra, "0x%08X", data32);
- break;
- default:
- DBG_871X(KERN_INFO "%s: usage> read
[bytes],[address(hex)]\n", __func__);
- ret = -EINVAL;
- goto exit;
+ case 1:
+ data32 = rtw_read8(padapter, addr);
+ sprintf(extra, "0x%02X", data32);
+ break;
+ case 2:
+ data32 = rtw_read16(padapter, addr);
+ sprintf(extra, "0x%04X", data32);
+ break;
+ case 4:
+ data32 = rtw_read32(padapter, addr);
+ sprintf(extra, "0x%08X", data32);
+ break;
+ default:
+ DBG_871X(KERN_INFO "%s: usage> read [bytes],[address(hex)]\n",
__func__);
+ ret = -EINVAL;
+ goto exit;
}
DBG_871X(KERN_INFO "%s: addr = 0x%08X data =%s\n", __func__, addr,
extra);
@@ -2309,21 +2309,21 @@ static int rtw_wx_write32(struct net_device *dev,
sscanf(extra, "%d,%x,%x", , , );
switch (bytes) {
- case 1:
- rtw_write8(padapter, addr, (u8)data32);
- DBG_871X(KERN_INFO "%s: addr = 0x%08X data = 0x%02X\n",
__func__, addr, (u8)data32);
- break;
- case 2:
- rtw_write16(padapter, addr, (u16)data32);
- DBG_871X(KERN_INFO "%s: addr = 0x%08X data = 0x%04X\n",
__func__,
Re: [PATCH v3 08/10] staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error
Dan Carpenter [2019-05-03 13:34:56]: Hi, > On Fri, May 03, 2019 at 09:56:05AM +0200, Petr Štetiar wrote: > > There was NVMEM support added to of_get_mac_address, so it could now > > return NULL and ERR_PTR encoded error values, so we need to adjust all > > current users of of_get_mac_address to this new fact. > > Which commit added NVMEM support? It hasn't hit net-next or linux-next > yet... Very strange. this patch is a part of the patch series[1], where the 1st patch[2] adds this NVMEM support to of_get_mac_address and follow-up patches are adjusting current of_get_mac_address users to the new ERR_PTR return value. > Why would of_get_mac_address() return a mix of NULL and error pointers? I've introduced this misleading API in v3, but corrected it in v4, so it now returns only valid pointer or ERR_PTR encoded error value. Just FYI, changes for staging/octeon are currently at v5[3]. 1. https://patchwork.ozlabs.org/project/netdev/list/?series=105972 2. https://patchwork.ozlabs.org/patch/1094916/ 3. https://patchwork.ozlabs.org/patch/1094942/ -- ynezz ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 5/5] dt-bindings: imx-ocotp: Add i.MX8MM compatible
Add compatible for i.MX8MM as per arch/arm64/boot/dts/freescale/imx8mm.dtsi Signed-off-by: Bryan O'Donoghue Cc: Rob Herring Reviewed-by: Leonard Crestez --- Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt index 68f7d6fdd140..96ffd06d2ca8 100644 --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt @@ -15,6 +15,7 @@ Required properties: "fsl,imx6sll-ocotp" (i.MX6SLL), "fsl,imx7ulp-ocotp" (i.MX7ULP), "fsl,imx8mq-ocotp" (i.MX8MQ), + "fsl,imx8mm-ocotp" (i.MX8MM), followed by "syscon". - #address-cells : Should be 1 - #size-cells : Should be 1 -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 4/5] nvmem: imx-ocotp: Add i.MX8MM support
This patch adds support to burn the fuses on the i.MX8MM.
https://www.nxp.com/webapp/Download?colCode=IMX8MMRM
The i.MX8MM is similar to i.MX6 processors in terms of addressing and clock
setup.
The documentation specifies 60 discreet OTP registers but, the fusemap
address space encompasses up to 256 registers. We map the entire putative
256 OTP registers.
Signed-off-by: Bryan O'Donoghue
---
drivers/nvmem/imx-ocotp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index 2c5009691dd6..189fd5f334f4 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -479,6 +479,12 @@ static const struct ocotp_params imx8mq_params = {
.set_timing = imx_ocotp_set_imx7_timing,
};
+static const struct ocotp_params imx8mm_params = {
+ .nregs = 256,
+ .bank_address_words = 0,
+ .set_timing = imx_ocotp_set_imx6_timing,
+};
+
static const struct of_device_id imx_ocotp_dt_ids[] = {
{ .compatible = "fsl,imx6q-ocotp", .data = _params },
{ .compatible = "fsl,imx6sl-ocotp", .data = _params },
@@ -489,6 +495,7 @@ static const struct of_device_id imx_ocotp_dt_ids[] = {
{ .compatible = "fsl,imx6sll-ocotp", .data = _params },
{ .compatible = "fsl,imx7ulp-ocotp", .data = _params },
{ .compatible = "fsl,imx8mq-ocotp", .data = _params },
+ { .compatible = "fsl,imx8mm-ocotp", .data = _params },
{ },
};
MODULE_DEVICE_TABLE(of, imx_ocotp_dt_ids);
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 2/5] nvmem: imx-ocotp: Ensure WAIT bits are preserved when setting timing
The i.MX6 and i.MX8 both have a bit-field spanning bits 27:22 called the
WAIT field.
The WAIT field according to the documentation for both parts "specifies
time interval between auto read and write access in one time program. It is
given in number of ipg_clk periods."
This patch ensures that the relevant field is read and written back to the
timing register.
Fixes: 0642bac7da42 ("nvmem: imx-ocotp: add write support")
Signed-off-by: Bryan O'Donoghue
Reviewed-by: Leonard Crestez
---
drivers/nvmem/imx-ocotp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index 6600c4ddeb51..85a7d0da3abb 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -189,7 +189,8 @@ static void imx_ocotp_set_imx6_timing(struct ocotp_priv
*priv)
strobe_prog = clk_rate / (10 / 1) + 2 * (DEF_RELAX + 1) - 1;
strobe_read = clk_rate / (10 / 40) + 2 * (DEF_RELAX + 1) - 1;
- timing = strobe_prog & 0x0FFF;
+ timing = readl(priv->base + IMX_OCOTP_ADDR_TIMING) & 0x0FC0;
+ timing |= strobe_prog & 0x0FFF;
timing |= (relax << 12) & 0xF000;
timing |= (strobe_read << 16) & 0x003F;
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 3/5] nvmem: imx-ocotp: Change TIMING calculation to u-boot algorithm
The RELAX field of the OCOTP block is turning out as a zero on i.MX8MM.
This messes up the subsequent re-load of the fuse shadow registers.
After some discussion with people @ NXP its clear we have missed a trick
here in Linux.
The OCOTP fuse programming time has a physical minimum 'burn time' that is
not related to the ipg_clk.
We need to define the RELAX, STROBE_READ and STROBE_PROG fields in terms of
desired timings to allow for the burn-in to safely complete. Right now only
the RELAX field is calculated in terms of an absolute time and we are
ending up with a value of zero.
This patch inherits the u-boot timings for the OCOTP_TIMING calculation on
the i.MX6 and i.MX8. Those timings are known to work and critically specify
values such as STROBE_PROG as a minimum timing.
Fixes: 0642bac7da42 ("nvmem: imx-ocotp: add write support")
Signed-off-by: Bryan O'Donoghue
Suggested-by: Leonard Crestez
Reviewed-by: Leonard Crestez
---
drivers/nvmem/imx-ocotp.c | 36
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index 85a7d0da3abb..2c5009691dd6 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -50,7 +50,9 @@
#define IMX_OCOTP_BM_CTRL_ERROR0x0200
#define IMX_OCOTP_BM_CTRL_REL_SHADOWS 0x0400
-#define DEF_RELAX 20 /* > 16.5ns */
+#define TIMING_STROBE_PROG_US 10 /* Min time to blow a fuse */
+#define TIMING_STROBE_READ_NS 37 /* Min time before read */
+#define TIMING_RELAX_NS17
#define DEF_FSOURCE1001/* > 1000 ns */
#define DEF_STROBE_PROG1 /* IPG clocks */
#define IMX_OCOTP_WR_UNLOCK0x3E77
@@ -182,12 +184,38 @@ static void imx_ocotp_set_imx6_timing(struct ocotp_priv
*priv)
* fields with timing values to match the current frequency of the
* ipg_clk. OTP writes will work at maximum bus frequencies as long
* as the HW_OCOTP_TIMING parameters are set correctly.
+*
+* Note: there are minimum timings required to ensure an OTP fuse burns
+* correctly that are independent of the ipg_clk. Those values are not
+* formally documented anywhere however, working from the minimum
+* timings given in u-boot we can say:
+*
+* - Minimum STROBE_PROG time is 10 microseconds. Intuitively 10
+* microseconds feels about right as representative of a minimum time
+* to physically burn out a fuse.
+*
+* - Minimum STROBE_READ i.e. the time to wait post OTP fuse burn before
+* performing another read is 37 nanoseconds
+*
+* - Minimum RELAX timing is 17 nanoseconds. This final RELAX minimum
+* timing is not entirely clear the documentation says "This
+* count value specifies the time to add to all default timing
+* parameters other than the Tpgm and Trd. It is given in number
+* of ipg_clk periods." where Tpgm and Trd refer to STROBE_PROG
+* and STROBE_READ respectively. What the other timing parameters
+* are though, is not specified. Experience shows a zero RELAX
+* value will mess up a re-load of the shadow registers post OTP
+* burn.
*/
clk_rate = clk_get_rate(priv->clk);
- relax = clk_rate / (10 / DEF_RELAX) - 1;
- strobe_prog = clk_rate / (10 / 1) + 2 * (DEF_RELAX + 1) - 1;
- strobe_read = clk_rate / (10 / 40) + 2 * (DEF_RELAX + 1) - 1;
+ relax = DIV_ROUND_UP(clk_rate * TIMING_RELAX_NS, 10) - 1;
+ strobe_read = DIV_ROUND_UP(clk_rate * TIMING_STROBE_READ_NS,
+ 10);
+ strobe_read += 2 * (relax + 1) - 1;
+ strobe_prog = DIV_ROUND_CLOSEST(clk_rate * TIMING_STROBE_PROG_US,
+ 100);
+ strobe_prog += 2 * (relax + 1) - 1;
timing = readl(priv->base + IMX_OCOTP_ADDR_TIMING) & 0x0FC0;
timing |= strobe_prog & 0x0FFF;
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 1/5] nvmem: imx-ocotp: Elongate OCOTP_CTRL ADDR field to eight bits
i.MX6 defines OCOTP_CTRLn:ADDR as seven bit address-field with a one bit RSVD0 field, i.MX7 defines OCOTP_CTRLn:ADDR as a four bit address-field with a four bit RSVD0 field. i.MX8 defines the OCOTP_CTRLn:ADDR bit-field as a full range eight bits. i.MX6 and i.MX7 should return zero for their respective RSVD0 bits and ignore a write-back of zero where i.MX8 will make use of the full range. This patch expands the bit-field definition for all users to eight bits, which is safe due to RSVD0 being a no-op for the i.MX6 and i.MX7. Signed-off-by: Bryan O'Donoghue Reviewed-by: Leonard Crestez --- drivers/nvmem/imx-ocotp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c index 4cf7b61e4bf5..6600c4ddeb51 100644 --- a/drivers/nvmem/imx-ocotp.c +++ b/drivers/nvmem/imx-ocotp.c @@ -45,7 +45,7 @@ #define IMX_OCOTP_ADDR_DATA2 0x0040 #define IMX_OCOTP_ADDR_DATA3 0x0050 -#define IMX_OCOTP_BM_CTRL_ADDR 0x007F +#define IMX_OCOTP_BM_CTRL_ADDR 0x00FF #define IMX_OCOTP_BM_CTRL_BUSY 0x0100 #define IMX_OCOTP_BM_CTRL_ERROR0x0200 #define IMX_OCOTP_BM_CTRL_REL_SHADOWS 0x0400 -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RESEND PATCH v6 0/5] Add i.MX8MM OCOTP support
V6 RESEND: - Adding Greg to sender list. Greg looks like you are the right person to apply this. - Adding de...@driverdev.osuosl.org to sender list - History: https://www.spinics.net/lists/arm-kernel/msg723454.html https://www.spinics.net/lists/arm-kernel/msg723321.html https://www.spinics.net/lists/arm-kernel/msg722655.html https://www.spinics.net/lists/arm-kernel/msg722449.html https://www.spinics.net/lists/arm-kernel/msg722441.html https://www.spinics.net/lists/arm-kernel/msg722350.html V6: - Drop BV_ prefix from u-boot timing defines - Add RB Leonard V5: - Adopt u-boot method of calculating timings. On the basis that the OTP registers have a programming time that is not related to the ipg_clk rate specify the various timing inputs to the RELAX, STROBE_READ and STROBE_PROG as-is done in u-boot. The wait time to burn a given OTP fuse is not documented anywhere except in code in u-boot. The ipg_clk then is used to clock the registers in the OCOTP block and to tell the OCOTP block how long to wait for programming to complete and how long to delay before doing an automatic re-read of the registers. Tested on the i.MX8MM-EVK relax = 1 strobe_read 6 strobe_prog 670 V4: - Change the RELAX fix to drop subtraction of -1 for all users - Leonard - Expand register definition from the 60 documented OTP registers to the entire 256 registers putatively in the address space* - Add Reviewed-by as indicated - Leonard - Added Suggested-by where it made sense - Bryan * Dumping the expanded address space shows that there are indeed OTP values present that can be read back from registers that are not formally documented for i.MX8MM eg. Bank 20 0x55000801 0x00014d14 0xd503201f 0x55000801 Bank 21 0x00014d20 0xd503201f 0x 0x V3: - Fix commit log for the expanding the ADDR field i.MX6 uses seven not four bits, which is why the existing define says 0x7F not 0x0F - bod V2: - Rebased to linux-next/master to align with i.8MQ work - Two patches dropped as a result of rebase - Added patch to expand OCOTP_CTRL_ADDR to 8 bits for all users - Leonard - Makes sure nregs = 60 not 64 for i.MX8MM - Tested imx8mm-evk, imx7s-warp7 V1: This set adds support for the i.MX8MM. When adding support for this processor there are two interesting gotchas to watch for. #1 We current do not preserve the WAIT field for i.MX6 and since we are reusing the i.MX6 set_timing() values, this would also affect i.MX8. On the face of it, it appears to be an inocuous error with no real side effects. #2 Secondly the i.MX8MM will calculate a zero value for the RELAX bit-field when programming up OTP fuses. This is fine for programming the fuses but, it introduces a strange failure state with reloading the shadow registers subsequent to blowing an OTP fuse. The second important patch here then is ensuring the RELAX field is non-zero to avoid the failure state. Bryan O'Donoghue (5): nvmem: imx-ocotp: Elongate OCOTP_CTRL ADDR field to eight bits nvmem: imx-ocotp: Ensure WAIT bits are preserved when setting timing nvmem: imx-ocotp: Change TIMING calculation to u-boot algorithm nvmem: imx-ocotp: Add i.MX8MM support dt-bindings: imx-ocotp: Add i.MX8MM compatible .../devicetree/bindings/nvmem/imx-ocotp.txt | 1 + drivers/nvmem/imx-ocotp.c | 48 --- 2 files changed, 43 insertions(+), 6 deletions(-) -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v5] staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error
There was NVMEM support added to of_get_mac_address, so it could now return ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by: Petr Štetiar --- Changes since v3: * IS_ERR_OR_NULL -> IS_ERR Changes since v4: * I've just blindly replaced IS_ERR_OR_NULL with IS_ERR in v4, but this was wrong, as I've just realized, that we still need to check for NULL in this particular case as well, so I've added back IS_ERR_OR_NULL check drivers/staging/octeon/ethernet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/octeon/ethernet.c b/drivers/staging/octeon/ethernet.c index 986db76..8847a11c2 100644 --- a/drivers/staging/octeon/ethernet.c +++ b/drivers/staging/octeon/ethernet.c @@ -421,7 +421,7 @@ int cvm_oct_common_init(struct net_device *dev) if (priv->of_node) mac = of_get_mac_address(priv->of_node); - if (mac) + if (!IS_ERR_OR_NULL(mac)) ether_addr_copy(dev->dev_addr, mac); else eth_hw_addr_random(dev); -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 08/10] staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error
There was NVMEM support added to of_get_mac_address, so it could now return ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by: Petr Štetiar --- Changes since v3: * IS_ERR_OR_NULL -> IS_ERR drivers/staging/octeon/ethernet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/octeon/ethernet.c b/drivers/staging/octeon/ethernet.c index 986db76..2b03018 100644 --- a/drivers/staging/octeon/ethernet.c +++ b/drivers/staging/octeon/ethernet.c @@ -421,7 +421,7 @@ int cvm_oct_common_init(struct net_device *dev) if (priv->of_node) mac = of_get_mac_address(priv->of_node); - if (mac) + if (!IS_ERR(mac)) ether_addr_copy(dev->dev_addr, mac); else eth_hw_addr_random(dev); -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Intel-gfx] [PATCH] dma-buf: add struct dma_buf_attach_info v2
Am 03.05.19 um 14:09 schrieb Daniel Vetter: > [CAUTION: External Email] > > On Fri, May 03, 2019 at 02:05:47PM +0200, Christian König wrote: >> Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin: >>> On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote: Add a structure for the parameters of dma_buf_attach, this makes it much easier to add new parameters later on. >>> I don't understand this reasoning. What are the "new parameters" that >>> are being proposed, and why do we need to put them into memory to pass >>> them across this interface? >>> >>> If the intention is to make it easier to change the interface, passing >>> parameters in this manner mean that it's easy for the interface to >>> change and drivers not to notice the changes, since the compiler will >>> not warn (unless some member of the structure that the driver is using >>> gets removed, in which case it will error.) >>> >>> Additions to the structure will go unnoticed by drivers - what if the >>> caller is expecting some different kind of behaviour, and the driver >>> ignores that new addition? >> Well, exactly that's the intention here: That the drivers using this >> interface should be able to ignore the new additions for now as long as they >> are not going to use them. >> >> The background is that we have multiple interface changes in the pipeline, >> and each step requires new optional parameters. >> >>> This doesn't seem to me like a good idea. >> Well, the obvious alternatives are: >> >> a) Change all drivers to explicitly provide NULL/0 for the new parameters. >> >> b) Use a wrapper, so that the function signature of dma_buf_attach stays the >> same. >> >> Key point here is that I have an invalidation callback change, a P2P patch >> set and some locking changes which all require adding new parameters or >> flags. And at each step I would then start to change all drivers, adding >> some more NULL pointers or flags with 0 default value. >> >> I'm actually perfectly fine going down any route, but this just seemed to me >> simplest and with the least risk of breaking anything. Opinions? > I think given all our discussions and plans the argument object makes tons > of sense. Much easier to document well than a long list of parameters. > Maybe we should make it const, so it could work like an ops/func table and > we could store it as a pointer in the dma_buf_attachment? Yeah, the invalidation callback and P2P flags are constant. But the importer_priv field isn't. We could do something like adding the importer_priv field as parameter and the other two as const structure. Third alternative would be to throw out all the DRM abstraction and just embed the attachment structure in the buffer object and get completely rid of the importer_priv field (probably the cleanest alternative, but also the most work todo). Christian. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Intel-gfx] [PATCH] dma-buf: add struct dma_buf_attach_info v2
On Fri, May 03, 2019 at 02:05:47PM +0200, Christian König wrote: > Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin: > > On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote: > > > Add a structure for the parameters of dma_buf_attach, this makes it much > > > easier > > > to add new parameters later on. > > I don't understand this reasoning. What are the "new parameters" that > > are being proposed, and why do we need to put them into memory to pass > > them across this interface? > > > > If the intention is to make it easier to change the interface, passing > > parameters in this manner mean that it's easy for the interface to > > change and drivers not to notice the changes, since the compiler will > > not warn (unless some member of the structure that the driver is using > > gets removed, in which case it will error.) > > > > Additions to the structure will go unnoticed by drivers - what if the > > caller is expecting some different kind of behaviour, and the driver > > ignores that new addition? > > Well, exactly that's the intention here: That the drivers using this > interface should be able to ignore the new additions for now as long as they > are not going to use them. > > The background is that we have multiple interface changes in the pipeline, > and each step requires new optional parameters. > > > This doesn't seem to me like a good idea. > > Well, the obvious alternatives are: > > a) Change all drivers to explicitly provide NULL/0 for the new parameters. > > b) Use a wrapper, so that the function signature of dma_buf_attach stays the > same. > > Key point here is that I have an invalidation callback change, a P2P patch > set and some locking changes which all require adding new parameters or > flags. And at each step I would then start to change all drivers, adding > some more NULL pointers or flags with 0 default value. > > I'm actually perfectly fine going down any route, but this just seemed to me > simplest and with the least risk of breaking anything. Opinions? I think given all our discussions and plans the argument object makes tons of sense. Much easier to document well than a long list of parameters. Maybe we should make it const, so it could work like an ops/func table and we could store it as a pointer in the dma_buf_attachment? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] dma-buf: add struct dma_buf_attach_info v2
Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin: On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote: Add a structure for the parameters of dma_buf_attach, this makes it much easier to add new parameters later on. I don't understand this reasoning. What are the "new parameters" that are being proposed, and why do we need to put them into memory to pass them across this interface? If the intention is to make it easier to change the interface, passing parameters in this manner mean that it's easy for the interface to change and drivers not to notice the changes, since the compiler will not warn (unless some member of the structure that the driver is using gets removed, in which case it will error.) Additions to the structure will go unnoticed by drivers - what if the caller is expecting some different kind of behaviour, and the driver ignores that new addition? Well, exactly that's the intention here: That the drivers using this interface should be able to ignore the new additions for now as long as they are not going to use them. The background is that we have multiple interface changes in the pipeline, and each step requires new optional parameters. This doesn't seem to me like a good idea. Well, the obvious alternatives are: a) Change all drivers to explicitly provide NULL/0 for the new parameters. b) Use a wrapper, so that the function signature of dma_buf_attach stays the same. Key point here is that I have an invalidation callback change, a P2P patch set and some locking changes which all require adding new parameters or flags. And at each step I would then start to change all drivers, adding some more NULL pointers or flags with 0 default value. I'm actually perfectly fine going down any route, but this just seemed to me simplest and with the least risk of breaking anything. Opinions? Thanks, Christian. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 08/10] staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error
On Fri, May 03, 2019 at 09:56:05AM +0200, Petr Štetiar wrote: > There was NVMEM support added to of_get_mac_address, so it could now > return NULL and ERR_PTR encoded error values, so we need to adjust all > current users of of_get_mac_address to this new fact. Which commit added NVMEM support? It hasn't hit net-next or linux-next yet... Very strange. Why would of_get_mac_address() return a mix of NULL and error pointers? In that situation, then NULL is a special kind of success like when you request feature and the feature works but it's disabled by the user. We don't want to treat it as an error but we still can't return a pointer to a feature we don't have... It's hard for me to imagine how that makes sense for getting a mac address. At the very least, this patch needs a Fixes tag. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 08/10] staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error
There was NVMEM support added to of_get_mac_address, so it could now return NULL and ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by: Petr Štetiar --- drivers/staging/octeon/ethernet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/octeon/ethernet.c b/drivers/staging/octeon/ethernet.c index 986db76..8847a11c2 100644 --- a/drivers/staging/octeon/ethernet.c +++ b/drivers/staging/octeon/ethernet.c @@ -421,7 +421,7 @@ int cvm_oct_common_init(struct net_device *dev) if (priv->of_node) mac = of_get_mac_address(priv->of_node); - if (mac) + if (!IS_ERR_OR_NULL(mac)) ether_addr_copy(dev->dev_addr, mac); else eth_hw_addr_random(dev); -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: most: cdev: fix chrdev_region leak in mod_exit
On Thu, May 02, 2019 at 07:39:20PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 24, 2019 at 09:23:43PM +0200, Eugeniu Rosca wrote:
> > From: Suresh Udipi
> >
> > It looks like v4.18-rc1 commit [0] which upstreams mld-1.8.0
> > commit [1] missed to fix the memory leak in mod_exit function.
> >
> > Do it now.
> >
> > [0] aba258b7310167 ("staging: most: cdev: fix chrdev_region leak")
> > [1] https://github.com/microchip-ais/linux/commit/a2d8f7ae7ea381
> > ("staging: most: cdev: fix leak for chrdev_region")
> >
> > Signed-off-by: Suresh Udipi
> > Signed-off-by: Eugeniu Rosca
> > Acked-by: Christian Gromm
>
> In the future, please use the "correct" way to mark a fixup patch. For
> this, it would be:
> Fixes: aba258b73101 ("staging: most: cdev: fix chrdev_region leak")
>
> I'll go add it, and the needed stable tag to the patch when applying it.
Thank you for the suggestion. I'll follow it next time.
>
> thanks,
>
> greg k-h
--
Best Regards,
Eugeniu.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: kpc2000: kpc_spi: Fix build error for {read,write}q
On Thu, May 02, 2019 at 07:06:30PM -0700, Nathan Chancellor wrote:
> drivers/staging/kpc2000/kpc_spi/spi_driver.c:158:11: error: implicit
> declaration of function 'readq' [-Werror,-Wimplicit-function-declaration]
> drivers/staging/kpc2000/kpc_spi/spi_driver.c:167:5: error: implicit
> declaration of function 'writeq' [-Werror,-Wimplicit-function-declaration]
>
> Same as commit 91b6cb7216cd ("staging: kpc2000: fix up build problems
> with readq()").
>
> Signed-off-by: Nathan Chancellor
> ---
> drivers/staging/kpc2000/kpc_spi/spi_driver.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/kpc2000/kpc_spi/spi_driver.c
> b/drivers/staging/kpc2000/kpc_spi/spi_driver.c
> index 074a578153d0..3ace4e5c1284 100644
> --- a/drivers/staging/kpc2000/kpc_spi/spi_driver.c
> +++ b/drivers/staging/kpc2000/kpc_spi/spi_driver.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> --
> 2.21.0
Ah, good catch, I missed this file, sorry.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
