Hello
I am Barrister Sysndey Walter, i have an important issue to discuss with you please kindly get back to me for info via my private email: mrs.sydneywaltercham...@hotmail.com-- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] V4L2: UVC: allow using larger buffers
A test in uvc_video_decode_isoc() checks whether an image has been
received from the camera completely. For this the data amount is compared
to the buffer length, which, however, doesn't have to be equal to the
image size. Switch to using formats .sizeimage field for an exact
expected image size.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Thanks to Laurent for the idea
drivers/media/usb/uvc/uvc_v4l2.c | 1 +
drivers/media/usb/uvc/uvc_video.c | 2 +-
drivers/media/usb/uvc/uvcvideo.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index 3b548b8..87d15c2 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -318,6 +318,7 @@ static int uvc_v4l2_set_format(struct uvc_streaming *stream,
stream-ctrl = probe;
stream-cur_format = format;
stream-cur_frame = frame;
+ stream-image_size = fmt-fmt.pix.sizeimage;
done:
mutex_unlock(stream-mutex);
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index e568e07..60abf6f 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1172,7 +1172,7 @@ static void uvc_video_decode_isoc(struct urb *urb, struct
uvc_streaming *stream,
urb-iso_frame_desc[i].actual_length);
if (buf-state == UVC_BUF_STATE_READY) {
- if (buf-length != buf-bytesused
+ if (stream-image_size != buf-bytesused
!(stream-cur_format-flags
UVC_FMT_FLAG_COMPRESSED))
buf-error = 1;
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 404793b..d3a3b71 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -480,6 +480,7 @@ struct uvc_streaming {
struct uvc_format *def_format;
struct uvc_format *cur_format;
struct uvc_frame *cur_frame;
+ size_t image_size;
/* Protect access to ctrl, cur_format, cur_frame and hardware video
* probe control.
*/
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i.MX6 status for IPU/VPU/GPU
2014-08-27 16:23 GMT+02:00 Steve Longerbeam steve_longerb...@mentor.com: Hi Jean-Michel, Phillip, Hi Steve, I've done some work on Philipp's June 12 patchset, converting the CSI driver to a CSI subdev entity, and fixing some issues here and there. This June 12 patchset doesn't appear to be a fully working driver, Phillip correct me if I am wrong. I can post this work as it exists, it is incomplete but compiles. Dos it compile against a 3.17-rc3 kernel :) ? I've also worked out what I think is a workable video pipeline graph for i.MX, suitable for defining the entities, pads, and links. Unfortunately I haven't been able to spend as much time as I'd like on it. This is very interesting, do you have written this somewhere ? The complete driver I posted to the list does have some minor issues mostly suggested by Hans Verkuil (switch to new selection API instead of cropping API for example). It is a full featured driver but it does not implement the media device framework, i.e. user does not have direct control of the video pipeline, rather the driver chooses the pipeline based on the traditional inputs from user (video format and controls). If there is interest I can submit another version of the traditional driver to resolve the issues. But media device is a major rework, so I don't know whether it would make sense to start from the traditional driver and then implement media device on top later, since media device is almost a complete rewrite. I, at least, am interested by this driver, even in its traditionnal form :). If you don't want to submit it directly because this is not using media controller, this is ok, you can provide me a git repo in order to get it, or send a patchset. JM -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i.MX6 status for IPU/VPU/GPU
On 09/09/14 09:49, Jean-Michel Hautbois wrote: 2014-08-27 16:23 GMT+02:00 Steve Longerbeam steve_longerb...@mentor.com: Hi Jean-Michel, Phillip, Hi Steve, I've done some work on Philipp's June 12 patchset, converting the CSI driver to a CSI subdev entity, and fixing some issues here and there. This June 12 patchset doesn't appear to be a fully working driver, Phillip correct me if I am wrong. I can post this work as it exists, it is incomplete but compiles. Dos it compile against a 3.17-rc3 kernel :) ? I've also worked out what I think is a workable video pipeline graph for i.MX, suitable for defining the entities, pads, and links. Unfortunately I haven't been able to spend as much time as I'd like on it. This is very interesting, do you have written this somewhere ? The complete driver I posted to the list does have some minor issues mostly suggested by Hans Verkuil (switch to new selection API instead of cropping API for example). It is a full featured driver but it does not implement the media device framework, i.e. user does not have direct control of the video pipeline, rather the driver chooses the pipeline based on the traditional inputs from user (video format and controls). If there is interest I can submit another version of the traditional driver to resolve the issues. But media device is a major rework, so I don't know whether it would make sense to start from the traditional driver and then implement media device on top later, since media device is almost a complete rewrite. I, at least, am interested by this driver, even in its traditionnal form :). If you don't want to submit it directly because this is not using media controller, this is ok, you can provide me a git repo in order to get it, or send a patchset. Is it possible to create a staging driver? Even if there are bits missing, having the code in the kernel as a staging driver would help a lot. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] [media] firewire: firedtv-avc: potential buffer overflow
On Mon, Sep 08, 2014 at 02:40:33PM +0200, Stefan Richter wrote: On Sep 08 Stefan Richter wrote: On Sep 08 Dan Carpenter wrote: program_info_length is user controlled and can go up to 4095. The operand[] array has 509 bytes so we need to add a limit here to prevent buffer overflows. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Reviewed-by: Stefan Richter stef...@s5r6.in-berlin.de Thank you. Oops, that was a bit too quick. After the memcpy() accesses which you protect, there are another four bytes written, still without checking the bounds. Thanks for catching that. I'll send a v2 soon. Btw, my static checker complains about the remaining memcpy() in this file: drivers/media/firewire/firedtv-avc.c:1310 avc_ca_get_mmi() error: '*len' from user is not capped properly This static checker warning has a lot of false positives. I looked at the code for a long time but couldn't figure out why it thinks *len is untrusted. I also wasn't totally sure that it was safe? regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.18] uvcvideo changes
Hi Mauro, The following changes since commit 91f96e8b7255537da3a58805cf465003521d7c5f: [media] tw68: drop bogus cpu_to_le32() call (2014-09-08 16:40:54 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git uvc/next for you to fetch changes up to 18e27c1f02310ecc196b059d890bd840fe247960: media: usb: uvc: add a quirk for Dell XPS M1330 webcam (2014-09-09 11:37:43 +0300) Paul Fertser (1): media: usb: uvc: add a quirk for Dell XPS M1330 webcam Vincent Palatin (2): v4l: Add camera pan/tilt speed controls v4l: uvcvideo: Add support for pan/tilt speed controls William Manley (1): uvcvideo: Work around buggy Logitech C920 firmware Documentation/DocBook/media/v4l/compat.xml | 10 ++ Documentation/DocBook/media/v4l/controls.xml | 21 + drivers/media/usb/uvc/uvc_ctrl.c | 60 --- drivers/media/usb/uvc/uvc_driver.c | 20 +++- drivers/media/usb/uvc/uvc_video.c| 6 drivers/media/usb/uvc/uvcvideo.h | 3 +- drivers/media/v4l2-core/v4l2-ctrls.c | 2 ++ include/uapi/linux/v4l2-controls.h | 2 ++ 8 files changed, 118 insertions(+), 6 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] mceusb: fix usbdev leak
On Tue, Sep 09, 2014 at 02:10:43AM +0400, Alexey Khoroshilov wrote: mceusb_init_rc_dev() does usb_get_dev(), but there is no any usb_put_dev() in the driver. drivers/media/rc/imon.c suffers from the same problem. Thanks Sean -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media_build] Add compat clock helpers
The clk_prepare_enable() and clk_disable_unprepare() clock helpers were
introduced in kernel v3.3. Add them to compat.h for kernels that don't
provide them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
v4l/compat.h | 23 +++
v4l/scripts/make_config_compat.pl | 1 +
2 files changed, 24 insertions(+)
diff --git a/v4l/compat.h b/v4l/compat.h
index ee05f3a..77abb55 100644
--- a/v4l/compat.h
+++ b/v4l/compat.h
@@ -1492,4 +1492,27 @@ static inline u32 prandom_u32_max(u32 ep_ro)
)
#endif
+#ifdef NEED_CLK_HELPERS
+#include linux/clk.h
+static inline int clk_prepare_enable(struct clk *clk)
+{
+ int ret;
+
+ ret = clk_prepare(clk);
+ if (ret)
+ return ret;
+ ret = clk_enable(clk);
+ if (ret)
+ clk_unprepare(clk);
+
+ return ret;
+}
+
+static inline void clk_disable_unprepare(struct clk *clk)
+{
+ clk_disable(clk);
+ clk_unprepare(clk);
+}
+#endif
+
#endif /* _COMPAT_H */
diff --git a/v4l/scripts/make_config_compat.pl
b/v4l/scripts/make_config_compat.pl
index cb362be..88d8cd0 100644
--- a/v4l/scripts/make_config_compat.pl
+++ b/v4l/scripts/make_config_compat.pl
@@ -617,6 +617,7 @@ sub check_other_dependencies()
check_files_for_func(prandom_u32, NEED_PRANDOM_U32,
include/linux/random.h);
check_files_for_func(GENMASK, NEED_GENMASK,
include/linux/bitops.h);
check_files_for_func(mult_frac, NEED_MULT_FRAC,
include/linux/kernel.h);
+ check_files_for_func(clk_prepare_enable, NEED_CLOCK_HELPERS,
include/linux/clk.h);
# For tests for uapi-dependent logic
check_files_for_func_uapi(usb_endpoint_maxp,
NEED_USB_ENDPOINT_MAXP, usb/ch9.h);
--
1.8.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] media: spi: Add support for LMH0395
This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.
LMH0395 enables the use of up to two outputs.
These can be configured using DT.
Controls should be accessible from userspace too...
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
.../devicetree/bindings/media/spi/lmh0395.txt | 44 +++
MAINTAINERS| 6 +
drivers/media/spi/Kconfig | 14 +
drivers/media/spi/Makefile | 1 +
drivers/media/spi/lmh0395.c| 355 +
5 files changed, 420 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
create mode 100644 drivers/media/spi/Kconfig
create mode 100644 drivers/media/spi/Makefile
create mode 100644 drivers/media/spi/lmh0395.c
diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
new file mode 100644
index 000..0a640a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,44 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to 2.97
Gbps
+and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI
standards.
+
+Required Properties :
+- compatible: Must be ti,lmh0395
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+ Port LMH0395
+
+ SDI input0
+ SDI output 1,2
+
+Example:
+
+ecspi@0201 {
+ ...
+ ...
+
+ lmh0395@1 {
+ compatible = ti,lmh0395;
+ reg = 1;
+ spi-max-frequency = 2000;
+ ports {
+ port@0 {
+ reg = 0;
+ sdi0_in: endpoint {};
+ };
+ port@1 {
+ reg=1;
+ sdi0_out0: endpoint {};
+ };
+ };
+ };
+ ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index cf24bb5..ca42b9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9141,6 +9141,12 @@ S: Maintained
F: sound/soc/codecs/lm49453*
F: sound/soc/codecs/isabelle*
+TI LMH0395 DRIVER
+M: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/spi/lmh0395*
+
TI LP855x BACKLIGHT DRIVER
M: Milo Kim milo@ti.com
S: Maintained
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..291e7ea
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+ tristate LMH0395 equalizer
+ depends on VIDEO_V4L2 SPI MEDIA_CONTROLLER
+ ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395)+= lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..ecf8f83
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,355 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014 Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable Equalizer
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/ioctl.h
+#include linux/module.h
+#include linux/of.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/uaccess.h
+#include linux/spi/spi.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include
[patch] [media] dvb: si21xx: buffer overflow in si21_writeregs()
len is user controlled and can be up to 255. Anything more than 59 will cause a buffer overflow so we need to add a test for that. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/media/dvb-frontends/si21xx.c b/drivers/media/dvb-frontends/si21xx.c index 73b47cc..16850e2 100644 --- a/drivers/media/dvb-frontends/si21xx.c +++ b/drivers/media/dvb-frontends/si21xx.c @@ -236,6 +236,9 @@ static int si21_writeregs(struct si21xx_state *state, u8 reg1, .len = len + 1 }; + if (len sizeof(buf) - 1) + return -EINVAL; + msg.buf[0] = reg1; memcpy(msg.buf + 1, data, len); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch v2] [media] firewire: firedtv-avc: potential buffer overflow
program_info_length is user controlled and can go up to 4095. The
operand[] array has 509 bytes so we need to add a limit here to prevent
buffer overflows.
The - 4 in the limit check is because we have 4 bytes more data to
add after the memcpy().
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
v2: The first version didn't have the - 4. Thanks for catching that
Stafan.
diff --git a/drivers/media/firewire/firedtv-avc.c
b/drivers/media/firewire/firedtv-avc.c
index d1a1a13..251a556 100644
--- a/drivers/media/firewire/firedtv-avc.c
+++ b/drivers/media/firewire/firedtv-avc.c
@@ -1157,6 +1157,10 @@ int avc_ca_pmt(struct firedtv *fdtv, char *msg, int
length)
if (pmt_cmd_id != 1 pmt_cmd_id != 4)
dev_err(fdtv-device,
invalid pmt_cmd_id %d\n, pmt_cmd_id);
+ if (program_info_length sizeof(c-operand) - 4 - write_pos) {
+ ret = -EINVAL;
+ goto out;
+ }
memcpy(c-operand[write_pos], msg[read_pos],
program_info_length);
@@ -1180,6 +1184,12 @@ int avc_ca_pmt(struct firedtv *fdtv, char *msg, int
length)
dev_err(fdtv-device, invalid pmt_cmd_id %d
at stream level\n, pmt_cmd_id);
+ if (es_info_length sizeof(c-operand) - 4 -
+write_pos) {
+ ret = -EINVAL;
+ goto out;
+ }
+
memcpy(c-operand[write_pos], msg[read_pos],
es_info_length);
read_pos += es_info_length;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] uvcvideo: Move to video_ioctl2
Simplify ioctl handling by using video_ioctl2.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/usb/uvc/uvc_driver.c |1 +
drivers/media/usb/uvc/uvc_v4l2.c | 1011
drivers/media/usb/uvc/uvcvideo.h |2 +-
3 files changed, 560 insertions(+), 454 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index f8135f4..799295d 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1744,6 +1744,7 @@ static int uvc_register_video(struct uvc_device *dev,
*/
vdev-v4l2_dev = dev-vdev;
vdev-fops = uvc_fops;
+ vdev-ioctl_ops = uvc_ioctl_ops;
vdev-release = uvc_release;
vdev-prio = stream-chain-prio;
if (stream-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index 378ae02..f33a067 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -551,553 +551,636 @@ static int uvc_v4l2_release(struct file *file)
return 0;
}
-static long uvc_v4l2_do_ioctl(struct file *file, unsigned int cmd, void *arg)
+static int uvc_ioctl_querycap(struct file *file, void *fh,
+ struct v4l2_capability *cap)
{
struct video_device *vdev = video_devdata(file);
struct uvc_fh *handle = file-private_data;
struct uvc_video_chain *chain = handle-chain;
struct uvc_streaming *stream = handle-stream;
- long ret = 0;
- switch (cmd) {
- /* Query capabilities */
- case VIDIOC_QUERYCAP:
- {
- struct v4l2_capability *cap = arg;
-
- memset(cap, 0, sizeof *cap);
- strlcpy(cap-driver, uvcvideo, sizeof cap-driver);
- strlcpy(cap-card, vdev-name, sizeof cap-card);
- usb_make_path(stream-dev-udev,
- cap-bus_info, sizeof(cap-bus_info));
- cap-version = LINUX_VERSION_CODE;
- cap-capabilities = V4L2_CAP_DEVICE_CAPS | V4L2_CAP_STREAMING
- | chain-caps;
- if (stream-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
- cap-device_caps = V4L2_CAP_VIDEO_CAPTURE
-| V4L2_CAP_STREAMING;
- else
- cap-device_caps = V4L2_CAP_VIDEO_OUTPUT
-| V4L2_CAP_STREAMING;
- break;
- }
+ memset(cap, 0, sizeof(*cap));
+ strlcpy(cap-driver, uvcvideo, sizeof(cap-driver));
+ strlcpy(cap-card, vdev-name, sizeof(cap-card));
+ usb_make_path(stream-dev-udev, cap-bus_info, sizeof(cap-bus_info));
+ cap-capabilities = V4L2_CAP_DEVICE_CAPS | V4L2_CAP_STREAMING
+ | chain-caps;
+ if (stream-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ cap-device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ else
+ cap-device_caps = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
- /* Priority */
- case VIDIOC_G_PRIORITY:
- *(u32 *)arg = v4l2_prio_max(vdev-prio);
- break;
+ return 0;
+}
- case VIDIOC_S_PRIORITY:
- ret = v4l2_prio_check(vdev-prio, handle-vfh.prio);
- if (ret 0)
- return ret;
+static int uvc_ioctl_enum_fmt(struct uvc_streaming *stream,
+ struct v4l2_fmtdesc *fmt)
+{
+ struct uvc_format *format;
+ enum v4l2_buf_type type = fmt-type;
+ __u32 index = fmt-index;
- return v4l2_prio_change(vdev-prio, handle-vfh.prio,
- *(u32 *)arg);
+ if (fmt-type != stream-type || fmt-index = stream-nformats)
+ return -EINVAL;
- /* Get, Set Query control */
- case VIDIOC_QUERYCTRL:
- return uvc_query_v4l2_ctrl(chain, arg);
+ memset(fmt, 0, sizeof(*fmt));
+ fmt-index = index;
+ fmt-type = type;
+
+ format = stream-format[fmt-index];
+ fmt-flags = 0;
+ if (format-flags UVC_FMT_FLAG_COMPRESSED)
+ fmt-flags |= V4L2_FMT_FLAG_COMPRESSED;
+ strlcpy(fmt-description, format-name, sizeof(fmt-description));
+ fmt-description[sizeof(fmt-description) - 1] = 0;
+ fmt-pixelformat = format-fcc;
+ return 0;
+}
- case VIDIOC_G_CTRL:
- {
- struct v4l2_control *ctrl = arg;
- struct v4l2_ext_control xctrl;
+static int uvc_ioctl_enum_fmt_vid_cap(struct file *file, void *fh,
+ struct v4l2_fmtdesc *fmt)
+{
+ struct uvc_fh *handle = fh;
+ struct uvc_streaming *stream = handle-stream;
- memset(xctrl, 0, sizeof xctrl);
- xctrl.id = ctrl-id;
+ return uvc_ioctl_enum_fmt(stream, fmt);
+}
-
[GIT PULL FOR v3.18] Media core changes
Hi Mauro, The following changes since commit 91f96e8b7255537da3a58805cf465003521d7c5f: [media] tw68: drop bogus cpu_to_le32() call (2014-09-08 16:40:54 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git v4l2/core for you to fetch changes up to acac9bf2c8bfb78258230f9dd8e317e83242066e: media: Use strlcpy instead of custom code (2014-09-09 15:43:14 +0300) Laurent Pinchart (1): media: Use strlcpy instead of custom code drivers/media/media-device.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l: Clarify RGB666 pixel format definition
On Tuesday 22 July 2014 00:44:34 Hans Verkuil wrote: On 07/22/2014 12:30 AM, Laurent Pinchart wrote: On Monday 21 July 2014 23:43:16 Hans Verkuil wrote: On 07/21/2014 10:39 PM, Laurent Pinchart wrote: The RGB666 pixel format doesn't include an alpha channel. Document it as such. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- .../DocBook/media/v4l/pixfmt-packed-rgb.xml | 20 +-- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index 32feac9..c47692a 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml @@ -330,20 +330,12 @@ colorspace constantV4L2_COLORSPACE_SRGB/constant./para entry/entry entryrsubscript1/subscript/entry entryrsubscript0/subscript/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry Just to clarify: BGR666 is a three byte format, not a four byte format? Well... :-) Three drivers seem to support the BGR666 in mainline : sh_veu, s3c-camif and exynos4-is. Further investigation shows that the sh_veu driver lists the BGR666 format internally but doesn't expose it to userspace and doesn't actually support it, so we're down to two drivers. Looking at the S3C6410 datasheet, it's unclear how the hardware stores RGB666 pixels in memory. It could be either Byte 0 Byte 1 Byte 2 Byte 3 --RR GGBB or GGBB --RR None of those correspond to the RGB666 format defined in the spec. The Exynos4 FIMC isn't documented in the public datasheet, so I can't check how the format is defined. Furthermore, various Renesas video-related IP cores support many different RGB666 variants, on either 32 or 24 bits per pixel, with and without alpha. Beside a loud *sigh*, any comment ? :-) You'll have to check with Samsung then. Sylwester, can you shed any light on what this format *really* is? Ping ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.18] Media core changes
Hi Mauro, This pull request supersedes the [GIT PULL FOR v3.18] Media core changes pull request I've just sent. Sorry for the noise. The following changes since commit 91f96e8b7255537da3a58805cf465003521d7c5f: [media] tw68: drop bogus cpu_to_le32() call (2014-09-08 16:40:54 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git v4l2/core for you to fetch changes up to 7616a92e9801122e432edebdda04d8a42f349c54: v4l: Fix ARGB32 fourcc value in the documentation (2014-09-09 16:20:59 +0300) Laurent Pinchart (3): media: Use strlcpy instead of custom code v4l: Add ARGB555X and XRGB555X pixel formats v4l: Fix ARGB32 fourcc value in the documentation Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml | 52 +++--- drivers/media/media-device.c | 6 ++-- include/uapi/linux/videodev2.h| 3 ++ 3 files changed, 53 insertions(+), 8 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
We want to be able to COMPILE_TEST the omap1_camera driver.
It compiles fine, but it fails linkediting:
ERROR: omap_stop_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_start_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_dma_link_lch [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_set_dma_dest_burst_mode
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_src_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_request_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_set_dma_transfer_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_dest_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_free_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
So, add some stub functions to avoid it.
Reported-by: Stephen Rothwell s...@canb.auug.org.au
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 6f06f8bc612c..7c8bfdd90a33 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -294,43 +294,24 @@ struct omap_system_dma_plat_info {
extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
-extern int omap_request_dma(int dev_id, const char *dev_name,
- void (*callback)(int lch, u16 ch_status, void *data),
- void *data, int *dma_ch);
extern void omap_enable_dma_irq(int ch, u16 irq_bits);
extern void omap_disable_dma_irq(int ch, u16 irq_bits);
-extern void omap_free_dma(int ch);
-extern void omap_start_dma(int lch);
-extern void omap_stop_dma(int lch);
-extern void omap_set_dma_transfer_params(int lch, int data_type,
-int elem_count, int frame_count,
-int sync_mode,
-int dma_trigger, int src_or_dst_synch);
extern void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode,
u32 color);
extern void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode mode);
extern void omap_set_dma_channel_mode(int lch, enum omap_dma_channel_mode
mode);
-extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
- unsigned long src_start,
- int src_ei, int src_fi);
extern void omap_set_dma_src_index(int lch, int eidx, int fidx);
extern void omap_set_dma_src_data_pack(int lch, int enable);
extern void omap_set_dma_src_burst_mode(int lch,
enum omap_dma_burst_mode burst_mode);
-extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
-unsigned long dest_start,
-int dst_ei, int dst_fi);
extern void omap_set_dma_dest_index(int lch, int eidx, int fidx);
extern void omap_set_dma_dest_data_pack(int lch, int enable);
-extern void omap_set_dma_dest_burst_mode(int lch,
-enum omap_dma_burst_mode burst_mode);
extern void omap_set_dma_params(int lch,
struct omap_dma_channel_params *params);
-extern void omap_dma_link_lch(int lch_head, int lch_queue);
extern void omap_dma_unlink_lch(int lch_head, int lch_queue);
extern int omap_set_dma_callback(int lch,
@@ -356,18 +337,9 @@ extern void omap_dma_disable_irq(int lch);
/* Chaining APIs */
#ifndef CONFIG_ARCH_OMAP1
-extern int omap_request_dma_chain(int dev_id, const char *dev_name,
- void (*callback) (int lch, u16 ch_status,
- void *data),
- int *chain_id, int no_of_chans,
- int chain_mode,
- struct omap_dma_channel_params params);
-extern int omap_free_dma_chain(int chain_id);
extern int omap_dma_chain_a_transfer(int chain_id, int src_start,
int dest_start, int elem_count,
int frame_count, void *callbk_data);
-extern int omap_start_dma_chain_transfers(int chain_id);
-extern int omap_stop_dma_chain_transfers(int chain_id);
extern int omap_get_dma_chain_index(int chain_id, int *ei, int *fi);
extern int omap_get_dma_chain_dst_pos(int chain_id);
extern int omap_get_dma_chain_src_pos(int chain_id);
@@ -377,6 +349,87 @@ extern int omap_modify_dma_chain_params(int chain_id,
extern int omap_dma_chain_status(int chain_id);
#endif
+#ifndef CONFIG_COMPILE_TEST
+extern int omap_request_dma(int dev_id, const char *dev_name,
+ void (*callback)(int lch, u16 ch_status, void
[PATCH 3/3] [media] vpif: Fix compilation with allmodconfig
When vpif is compiled as module, those errors happen: ERROR: vpif_lock [drivers/media/platform/davinci/vpif_display.ko] undefined! ERROR: vpif_lock [drivers/media/platform/davinci/vpif_capture.ko] undefined! That's because vpif_lock symbol is not exported. Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c index cd08e5248387..3dad5bd7fe0a 100644 --- a/drivers/media/platform/davinci/vpif.c +++ b/drivers/media/platform/davinci/vpif.c @@ -38,6 +38,7 @@ MODULE_LICENSE(GPL); #define VPIF_CH3_MAX_MODES 2 spinlock_t vpif_lock; +EXPORT_SYMBOL_GPL(vpif_lock); void __iomem *vpif_base; EXPORT_SYMBOL_GPL(vpif_base); -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
ERROR: __bad_ndelay [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined! Yet, it sounds a bad idea to use ndelay to wait for 100 us for the device to reset. Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c index e51c078360f5..01eeacf28843 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); +#ifndef CONFIG_COMPILE_TEST ndelay(10); +#endif writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); } -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
+linux-omap, tony
-Balaji
On 09/09/2014 09:38 AM, Mauro Carvalho Chehab wrote:
We want to be able to COMPILE_TEST the omap1_camera driver.
It compiles fine, but it fails linkediting:
ERROR: omap_stop_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_start_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_dma_link_lch
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_dest_burst_mode
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_src_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_request_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_set_dma_transfer_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_dest_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_free_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
So, add some stub functions to avoid it.
Reported-by: Stephen Rothwell s...@canb.auug.org.au
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 6f06f8bc612c..7c8bfdd90a33 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -294,43 +294,24 @@ struct omap_system_dma_plat_info {
extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
-extern int omap_request_dma(int dev_id, const char *dev_name,
- void (*callback)(int lch, u16 ch_status, void *data),
- void *data, int *dma_ch);
extern void omap_enable_dma_irq(int ch, u16 irq_bits);
extern void omap_disable_dma_irq(int ch, u16 irq_bits);
-extern void omap_free_dma(int ch);
-extern void omap_start_dma(int lch);
-extern void omap_stop_dma(int lch);
-extern void omap_set_dma_transfer_params(int lch, int data_type,
- int elem_count, int frame_count,
- int sync_mode,
- int dma_trigger, int src_or_dst_synch);
extern void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode,
u32 color);
extern void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode mode);
extern void omap_set_dma_channel_mode(int lch, enum omap_dma_channel_mode
mode);
-extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
- unsigned long src_start,
- int src_ei, int src_fi);
extern void omap_set_dma_src_index(int lch, int eidx, int fidx);
extern void omap_set_dma_src_data_pack(int lch, int enable);
extern void omap_set_dma_src_burst_mode(int lch,
enum omap_dma_burst_mode burst_mode);
-extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
- unsigned long dest_start,
- int dst_ei, int dst_fi);
extern void omap_set_dma_dest_index(int lch, int eidx, int fidx);
extern void omap_set_dma_dest_data_pack(int lch, int enable);
-extern void omap_set_dma_dest_burst_mode(int lch,
- enum omap_dma_burst_mode burst_mode);
extern void omap_set_dma_params(int lch,
struct omap_dma_channel_params *params);
-extern void omap_dma_link_lch(int lch_head, int lch_queue);
extern void omap_dma_unlink_lch(int lch_head, int lch_queue);
extern int omap_set_dma_callback(int lch,
@@ -356,18 +337,9 @@ extern void omap_dma_disable_irq(int lch);
/* Chaining APIs */
#ifndef CONFIG_ARCH_OMAP1
-extern int omap_request_dma_chain(int dev_id, const char *dev_name,
- void (*callback) (int lch, u16 ch_status,
- void *data),
- int *chain_id, int no_of_chans,
- int chain_mode,
- struct omap_dma_channel_params params);
-extern int omap_free_dma_chain(int chain_id);
extern int omap_dma_chain_a_transfer(int chain_id, int src_start,
int dest_start, int elem_count,
int frame_count, void *callbk_data);
-extern int omap_start_dma_chain_transfers(int chain_id);
-extern int omap_stop_dma_chain_transfers(int chain_id);
extern int omap_get_dma_chain_index(int chain_id, int *ei, int *fi);
extern int omap_get_dma_chain_dst_pos(int chain_id);
extern int omap_get_dma_chain_src_pos(int chain_id);
@@ -377,6 +349,87 @@ extern int omap_modify_dma_chain_params(int chain_id,
extern int omap_dma_chain_status(int chain_id);
#endif
+#ifndef
Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote: We want to be able to COMPILE_TEST the omap1_camera driver. It compiles fine, but it fails linkediting: ERROR: omap_stop_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_start_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_dma_link_lch [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_dest_burst_mode [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_src_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_request_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_transfer_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_dest_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_free_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! So, add some stub functions to avoid it. The real answer to this is to find someone who still uses it, and convert it to the DMA engine API. If there's no users, the driver might as well be killed off. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l: Clarify RGB666 pixel format definition
On 09/09/14 15:18, Laurent Pinchart wrote: On Tuesday 22 July 2014 00:44:34 Hans Verkuil wrote: On 07/22/2014 12:30 AM, Laurent Pinchart wrote: On Monday 21 July 2014 23:43:16 Hans Verkuil wrote: On 07/21/2014 10:39 PM, Laurent Pinchart wrote: The RGB666 pixel format doesn't include an alpha channel. Document it as such. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- .../DocBook/media/v4l/pixfmt-packed-rgb.xml | 20 +-- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index 32feac9..c47692a 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml @@ -330,20 +330,12 @@ colorspace constantV4L2_COLORSPACE_SRGB/constant./para entry/entry entryrsubscript1/subscript/entry entryrsubscript0/subscript/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry - entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry Just to clarify: BGR666 is a three byte format, not a four byte format? Well... :-) Three drivers seem to support the BGR666 in mainline : sh_veu, s3c-camif and exynos4-is. Further investigation shows that the sh_veu driver lists the BGR666 format internally but doesn't expose it to userspace and doesn't actually support it, so we're down to two drivers. Looking at the S3C6410 datasheet, it's unclear how the hardware stores RGB666 pixels in memory. It could be either Byte 0 Byte 1 Byte 2 Byte 3 --RR GGBB or GGBB --RR None of those correspond to the RGB666 format defined in the spec. The Exynos4 FIMC isn't documented in the public datasheet, so I can't check how the format is defined. Furthermore, various Renesas video-related IP cores support many different RGB666 variants, on either 32 or 24 bits per pixel, with and without alpha. Beside a loud *sigh*, any comment ? :-) You'll have to check with Samsung then. Sylwester, can you shed any light on what this format *really* is? Ping ? My apologies, I didn't notice this earlier. In case of S5P/Exynos FIMC the format is: Byte 0 Byte 1 Byte 2 Byte 3 BBGG RR-- i.e. 4 byte per pixel, with 14-bit padding (don't care bits). As far as S3C6410 CAMIF is concerned it's hard to say. I primarily developed the s3c-camif driver for S3C2440 SoC, which doesn't support BGR666 format. I merged some patches from others adding s3c6410 support, before sending upstream. Nevertheless, looking at the S3C CAMIF datasheet the RGB666 format seems identical with the FIMC one. See [1], chapter 20.7.4 MEMORY STORING METHOD. This would make sense, since the S5P/Exynos FIMC is basically a significantly evolved S3C CAMIF AFAICT. -- Regards, Sylwester [1] http://www.arm9board.net/download/OK6410/docs/S3C6410X.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
* Nishanth Menon n...@ti.com [140909 07:40]:
+linux-omap, tony
-Balaji
On 09/09/2014 09:38 AM, Mauro Carvalho Chehab wrote:
We want to be able to COMPILE_TEST the omap1_camera driver.
It compiles fine, but it fails linkediting:
ERROR: omap_stop_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_start_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_dma_link_lch
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_dest_burst_mode
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_src_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_request_dma
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_transfer_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_dest_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_free_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
So, add some stub functions to avoid it.
How about just remove that old driver? I doubt it works, and I'm
almost certain nobody has actually tried to use it for many
years. At least I'm not aware of any hardware supported in the
mainline kernel with it. And we're moving things to dma engine
API anyways.
Regards,
Tony
Reported-by: Stephen Rothwell s...@canb.auug.org.au
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 6f06f8bc612c..7c8bfdd90a33 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -294,43 +294,24 @@ struct omap_system_dma_plat_info {
extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
-extern int omap_request_dma(int dev_id, const char *dev_name,
- void (*callback)(int lch, u16 ch_status, void *data),
- void *data, int *dma_ch);
extern void omap_enable_dma_irq(int ch, u16 irq_bits);
extern void omap_disable_dma_irq(int ch, u16 irq_bits);
-extern void omap_free_dma(int ch);
-extern void omap_start_dma(int lch);
-extern void omap_stop_dma(int lch);
-extern void omap_set_dma_transfer_params(int lch, int data_type,
-int elem_count, int frame_count,
-int sync_mode,
-int dma_trigger, int src_or_dst_synch);
extern void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode,
u32 color);
extern void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode
mode);
extern void omap_set_dma_channel_mode(int lch, enum omap_dma_channel_mode
mode);
-extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
- unsigned long src_start,
- int src_ei, int src_fi);
extern void omap_set_dma_src_index(int lch, int eidx, int fidx);
extern void omap_set_dma_src_data_pack(int lch, int enable);
extern void omap_set_dma_src_burst_mode(int lch,
enum omap_dma_burst_mode burst_mode);
-extern void omap_set_dma_dest_params(int lch, int dest_port, int
dest_amode,
-unsigned long dest_start,
-int dst_ei, int dst_fi);
extern void omap_set_dma_dest_index(int lch, int eidx, int fidx);
extern void omap_set_dma_dest_data_pack(int lch, int enable);
-extern void omap_set_dma_dest_burst_mode(int lch,
-enum omap_dma_burst_mode burst_mode);
extern void omap_set_dma_params(int lch,
struct omap_dma_channel_params *params);
-extern void omap_dma_link_lch(int lch_head, int lch_queue);
extern void omap_dma_unlink_lch(int lch_head, int lch_queue);
extern int omap_set_dma_callback(int lch,
@@ -356,18 +337,9 @@ extern void omap_dma_disable_irq(int lch);
/* Chaining APIs */
#ifndef CONFIG_ARCH_OMAP1
-extern int omap_request_dma_chain(int dev_id, const char *dev_name,
- void (*callback) (int lch, u16 ch_status,
- void *data),
- int *chain_id, int no_of_chans,
- int chain_mode,
- struct omap_dma_channel_params params);
-extern int omap_free_dma_chain(int chain_id);
extern int omap_dma_chain_a_transfer(int chain_id, int src_start,
int dest_start, int elem_count,
int frame_count, void *callbk_data);
-extern int omap_start_dma_chain_transfers(int chain_id);
-extern int
I Need A Help from You
-- I came down to Russia for a short vacation. Unfortunately, i was mugged at the park of the hotel where i stayed. All cash, credit cards and mobile phones were stolen from me but luckily i still have my passport with me. I've been to the Embassy and the Police here but they're not helping issues at all the bad news is my flight will be leaving in less than 8-hrs from now but i am having problems settling the hotel bills and the hotel manager won't let me leave until i settle the bills. I'll need your help (LOAN) financially of $2,530 USD. I promise to make the refund once i get back home. Please let me know how you can help and I need you to keep me posted via email. Bu e-posta (ve ekler) mesaji, mesajin alici kisminda belirtilmis olan kullanici icindir ve sadece gonderilen kisiye yoneliktir. Bu e-postayi yanlislikla aldiysaniz, lutfen dogrudan veya dolayli olarak mesaji kullanmayiniz, yollayan kisiyi bilgilendirip mesajin tum kopyalarini sisteminizden derhal siliniz. E- posta iletiminin guvenli veya hatasiz oldugunun garantisi olmadigindan gec veya eksik iletim veya icerik ve bilgilerde eksiklik, kayip, degisiklik veya virus olabileceginden, bu mesajin iletiminden, icerikteki hatadan, eksiklikten, dogrulugun ve gizliligin ihlalinden veya bu yolla bilgi paylasimi, iletimi, depolanmasi gibi herhangi bir kullanimdan Universitemiz hicbir sekilde sorumlu degildir. Bu mesajin icerigi yazarina ait olup hicbir sekilde Yuzuncu Yil Universitesi'ne atfedilemeyecegi gibi, Universitemizi baglayici da degildir. This e-mail (and the attachments), is solely for the individual or the entity who has been mentioned specifically in the recipient section of the e- mail and intended solely for the addressee. If you are not the recipient of this message or the intended addressee (or if you have received it accidentally), please do not use it directly or indirectly and delete the message and all its copies from your system by notifying the sender immediately. Since safe and healthy transmission of an e-mail cannot be guaranteed and there is a possibility of delayed or incomplete delivery of a message or absence, loss, change or presence of virus in content and information,Yuzuncu Yil University is not liable for the delivery of the message; the fault and incompleteness in the content; violation of confidentiality or integrity; or sharing, transmission and storage of information via this way. The content of the message does solely belong to the writer of it and under no circumstances can be endorsed b y Yuzuncu Yil University. Also, Yuzuncu Yil University does not accept any legal responsibility whatsoever for the content of the message. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
On 09/09/14 16:38, Mauro Carvalho Chehab wrote: ERROR: __bad_ndelay [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined! Yet, it sounds a bad idea to use ndelay to wait for 100 us for the device to reset. Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c index e51c078360f5..01eeacf28843 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); +#ifndef CONFIG_COMPILE_TEST ndelay(10); +#endif Wouldn't be a better fix to replace ndelay(10); with udelay(100), rather than sticking in a not so pretty #ifndef ? I guess usleep_range() couldn't simply be used, since exynos4_jpeg_sw_reset() is called with a spinlock held. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
Em Tue, 09 Sep 2014 16:58:58 +0200 Sylwester Nawrocki s.nawro...@samsung.com escreveu: On 09/09/14 16:38, Mauro Carvalho Chehab wrote: ERROR: __bad_ndelay [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined! Yet, it sounds a bad idea to use ndelay to wait for 100 us for the device to reset. Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c index e51c078360f5..01eeacf28843 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); +#ifndef CONFIG_COMPILE_TEST ndelay(10); +#endif Wouldn't be a better fix to replace ndelay(10); with udelay(100), rather than sticking in a not so pretty #ifndef ? Works for me. I'll submit a new version. I guess usleep_range() couldn't simply be used, since exynos4_jpeg_sw_reset() is called with a spinlock held. Ok. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] v4l2-common: fix overflow in v4l_bound_align_image()
Fix clamp_align() used in v4l_bound_align_image() to prevent overflow when passed large value like UINT32_MAX. In the current implementation: clamp_align(UINT32_MAX, 8, 8192, 3) returns 8, because in line: x = (x + (1 (align - 1))) mask; x overflows to (-1 + 4) 0x7 = 3, while expected value is 8192. v4l_bound_align_image() is heavily used in VIDIOC_S_FMT and VIDIOC_SUBDEV_S_FMT ioctls handlers, and documentation of the latter explicitly states that: The modified format should be as close as possible to the original request. -- http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-subdev-g-fmt.html Thus one would expect, that passing UINT32_MAX as format width and height will result in setting maximum possible resolution for the device. Particularly, when the driver doesn't support VIDIOC_ENUM_FRAMESIZES ioctl, which is common in the codebase. Fixes: b0d3159be9a3 (V4L/DVB (11901): v4l2: Create helper function for bounding and aligning images) Signed-off-by: Maciej Matraszek m.matras...@samsung.com --- drivers/media/v4l2-core/v4l2-common.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c index ccaa38f65cf1..506cf8b7763b 100644 --- a/drivers/media/v4l2-core/v4l2-common.c +++ b/drivers/media/v4l2-core/v4l2-common.c @@ -435,16 +435,13 @@ static unsigned int clamp_align(unsigned int x, unsigned int min, /* Bits that must be zero to be aligned */ unsigned int mask = ~((1 align) - 1); + /* Clamp to aligned min and max */ + x = clamp_t(unsigned int, x, (min + ~mask) mask, max mask); + /* Round to nearest aligned value */ if (align) x = (x + (1 (align - 1))) mask; - /* Clamp to aligned value of min and max */ - if (x min) - x = (min + ~mask) mask; - else if (x max) - x = max mask; - return x; } -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
Hi Mauro, Sylwester, On 09/09/2014 05:09 PM, Mauro Carvalho Chehab wrote: Em Tue, 09 Sep 2014 16:58:58 +0200 Sylwester Nawrocki s.nawro...@samsung.com escreveu: On 09/09/14 16:38, Mauro Carvalho Chehab wrote: ERROR: __bad_ndelay [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined! Yet, it sounds a bad idea to use ndelay to wait for 100 us for the device to reset. Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c index e51c078360f5..01eeacf28843 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); +#ifndef CONFIG_COMPILE_TEST ndelay(10); +#endif Wouldn't be a better fix to replace ndelay(10); with udelay(100), rather than sticking in a not so pretty #ifndef ? Works for me. I'll submit a new version. I guess usleep_range() couldn't simply be used, since exynos4_jpeg_sw_reset() is called with a spinlock held. Ok. Within few days I will perform some hardware tests, to verify if there is more room for improvement here. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
Em Tue, 9 Sep 2014 15:41:58 +0100 Russell King - ARM Linux li...@arm.linux.org.uk escreveu: On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote: We want to be able to COMPILE_TEST the omap1_camera driver. It compiles fine, but it fails linkediting: ERROR: omap_stop_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_start_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_dma_link_lch [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_dest_burst_mode [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_src_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_request_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_transfer_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_dest_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_free_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! So, add some stub functions to avoid it. The real answer to this is to find someone who still uses it, and convert it to the DMA engine API. If there's no users, the driver might as well be killed off. Hmm... it seems that there are still several drivers still relying on the functions declared at: omap-dma.h: $ grep extern include/linux/omap-dma.h |perl -ne 'print $1\n if (m/extern\s\S+\s(.*)\(/)' funcs git grep -f funcs -l arch/arm/mach-omap1/pm.c arch/arm/mach-omap2/pm24xx.c arch/arm/plat-omap/dma.c drivers/dma/omap-dma.c drivers/media/platform/omap/omap_vout_vrfb.c drivers/media/platform/omap3isp/isphist.c drivers/media/platform/soc_camera/omap1_camera.c drivers/mtd/onenand/omap2.c drivers/usb/gadget/udc/omap_udc.c drivers/usb/musb/tusb6010_omap.c drivers/video/fbdev/omap/omapfb_main.c include/linux/omap-dma.h Perhaps we can remove the header and mark all the above as BROKEN. If nobody fixes, we can strip all of them from the Kernel. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] media: spi: Add support for LMH0395
This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.
LMH0395 enables the use of up to two outputs.
These can be configured using DT.
Controls should be accessible from userspace too.
This will have to be done later.
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
.../devicetree/bindings/media/spi/lmh0395.txt | 44 +++
MAINTAINERS| 6 +
drivers/media/spi/Kconfig | 14 +
drivers/media/spi/Makefile | 1 +
drivers/media/spi/lmh0395.c| 360 +
5 files changed, 425 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
create mode 100644 drivers/media/spi/Kconfig
create mode 100644 drivers/media/spi/Makefile
create mode 100644 drivers/media/spi/lmh0395.c
diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
new file mode 100644
index 000..0a640a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,44 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to 2.97
Gbps
+and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI
standards.
+
+Required Properties :
+- compatible: Must be ti,lmh0395
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+ Port LMH0395
+
+ SDI input0
+ SDI output 1,2
+
+Example:
+
+ecspi@0201 {
+ ...
+ ...
+
+ lmh0395@1 {
+ compatible = ti,lmh0395;
+ reg = 1;
+ spi-max-frequency = 2000;
+ ports {
+ port@0 {
+ reg = 0;
+ sdi0_in: endpoint {};
+ };
+ port@1 {
+ reg=1;
+ sdi0_out0: endpoint {};
+ };
+ };
+ };
+ ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index cf24bb5..ca42b9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9141,6 +9141,12 @@ S: Maintained
F: sound/soc/codecs/lm49453*
F: sound/soc/codecs/isabelle*
+TI LMH0395 DRIVER
+M: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/spi/lmh0395*
+
TI LP855x BACKLIGHT DRIVER
M: Milo Kim milo@ti.com
S: Maintained
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..291e7ea
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+ tristate LMH0395 equalizer
+ depends on VIDEO_V4L2 SPI MEDIA_CONTROLLER
+ ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395)+= lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..fe5c5f8
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,360 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014 Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable Equalizer
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/ioctl.h
+#include linux/module.h
+#include linux/of.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/uaccess.h
+#include linux/spi/spi.h
+#include linux/videodev2.h
+#include
Re: i.MX6 status for IPU/VPU/GPU
On 09/09/2014 12:52 AM, Hans Verkuil wrote: On 09/09/14 09:49, Jean-Michel Hautbois wrote: 2014-08-27 16:23 GMT+02:00 Steve Longerbeam steve_longerb...@mentor.com: Hi Jean-Michel, Phillip, Hi Steve, I've done some work on Philipp's June 12 patchset, converting the CSI driver to a CSI subdev entity, and fixing some issues here and there. This June 12 patchset doesn't appear to be a fully working driver, Phillip correct me if I am wrong. I can post this work as it exists, it is incomplete but compiles. Dos it compile against a 3.17-rc3 kernel :) ? I've also worked out what I think is a workable video pipeline graph for i.MX, suitable for defining the entities, pads, and links. Unfortunately I haven't been able to spend as much time as I'd like on it. This is very interesting, do you have written this somewhere ? The complete driver I posted to the list does have some minor issues mostly suggested by Hans Verkuil (switch to new selection API instead of cropping API for example). It is a full featured driver but it does not implement the media device framework, i.e. user does not have direct control of the video pipeline, rather the driver chooses the pipeline based on the traditional inputs from user (video format and controls). If there is interest I can submit another version of the traditional driver to resolve the issues. But media device is a major rework, so I don't know whether it would make sense to start from the traditional driver and then implement media device on top later, since media device is almost a complete rewrite. I, at least, am interested by this driver, even in its traditionnal form :). If you don't want to submit it directly because this is not using media controller, this is ok, you can provide me a git repo in order to get it, or send a patchset. Is it possible to create a staging driver? Even if there are bits missing, having the code in the kernel as a staging driver would help a lot. Hi Hans, that's a good idea. I can post it as a staging driver. The capture driver does require more support in the i.MX IPU driver which is not yet merged or proposed. Phillip has forwarded most of them to drm-next, but there are a few more required. I need to post those patches to drm-next as a first step. I can start working on converting the driver to staging and addressing the earlier issues, but posting it to media-tree will need to wait until the IPU patches are merged, unless I include the IPU patches along with the capture driver patchset. Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
ERROR: __bad_ndelay [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined! That happens because asm-generic doesn't like any ndelay time bigger than 20us. Currently, usleep_range() couldn't simply be used, since exynos4_jpeg_sw_reset() is called with a spinlock held. So, let's use ndelay() instead. Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c index e51c078360f5..ab6d6f43c96f 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,7 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); - ndelay(10); + udelay(100); writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); } -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i.MX6 status for IPU/VPU/GPU
Hi Jean-Michel, On 09/09/2014 12:49 AM, Jean-Michel Hautbois wrote: 2014-08-27 16:23 GMT+02:00 Steve Longerbeam steve_longerb...@mentor.com: Hi Jean-Michel, Phillip, Hi Steve, I've done some work on Philipp's June 12 patchset, converting the CSI driver to a CSI subdev entity, and fixing some issues here and there. This June 12 patchset doesn't appear to be a fully working driver, Phillip correct me if I am wrong. I can post this work as it exists, it is incomplete but compiles. Dos it compile against a 3.17-rc3 kernel :) ? No, not anymore, the original posted driver was against 3.16 IIRC. I've also worked out what I think is a workable video pipeline graph for i.MX, suitable for defining the entities, pads, and links. Unfortunately I haven't been able to spend as much time as I'd like on it. This is very interesting, do you have written this somewhere ? Yes, I'll try to find some time to create a pdf image. The complete driver I posted to the list does have some minor issues mostly suggested by Hans Verkuil (switch to new selection API instead of cropping API for example). It is a full featured driver but it does not implement the media device framework, i.e. user does not have direct control of the video pipeline, rather the driver chooses the pipeline based on the traditional inputs from user (video format and controls). If there is interest I can submit another version of the traditional driver to resolve the issues. But media device is a major rework, so I don't know whether it would make sense to start from the traditional driver and then implement media device on top later, since media device is almost a complete rewrite. I, at least, am interested by this driver, even in its traditionnal form :). If you don't want to submit it directly because this is not using media controller, this is ok, you can provide me a git repo in order to get it, or send a patchset. I think I'll follow Hans' proposal and submit it again to media-tree as a staging driver. Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i.MX6 status for IPU/VPU/GPU
On 09/09/2014 12:49 AM, Jean-Michel Hautbois wrote: 2014-08-27 16:23 GMT+02:00 Steve Longerbeam steve_longerb...@mentor.com: The complete driver I posted to the list does have some minor issues mostly suggested by Hans Verkuil (switch to new selection API instead of cropping API for example). It is a full featured driver but it does not implement the media device framework, i.e. user does not have direct control of the video pipeline, rather the driver chooses the pipeline based on the traditional inputs from user (video format and controls). If there is interest I can submit another version of the traditional driver to resolve the issues. But media device is a major rework, so I don't know whether it would make sense to start from the traditional driver and then implement media device on top later, since media device is almost a complete rewrite. I, at least, am interested by this driver, even in its traditionnal form :). If you don't want to submit it directly because this is not using media controller, this is ok, you can provide me a git repo in order to get it, or send a patchset. Hi Jean-Michel, I forgot to mention I will be working on the staging capture driver in a copy of the media-tree on github at: g...@github.com:slongerbeam/mediatree.git Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
On 09/09/14 18:10, Mauro Carvalho Chehab wrote: ERROR: __bad_ndelay [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined! That happens because asm-generic doesn't like any ndelay time bigger than 20us. Currently, usleep_range() couldn't simply be used, since exynos4_jpeg_sw_reset() is called with a spinlock held. So, let's use ndelay() instead. Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com Acked-by: Sylwester Nawrocki s.nawro...@samsung.com -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
On Tue, Sep 9, 2014 at 1:10 PM, Mauro Carvalho Chehab m.che...@samsung.com wrote: ERROR: __bad_ndelay [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined! That happens because asm-generic doesn't like any ndelay time bigger than 20us. Currently, usleep_range() couldn't simply be used, since exynos4_jpeg_sw_reset() is called with a spinlock held. So, let's use ndelay() instead. You meant 'udelay() instead'. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i.MX6 status for IPU/VPU/GPU
Hi Steve, Am Dienstag, den 09.09.2014, 09:12 -0700 schrieb Steve Longerbeam: Hi Jean-Michel, On 09/09/2014 12:49 AM, Jean-Michel Hautbois wrote: 2014-08-27 16:23 GMT+02:00 Steve Longerbeam steve_longerb...@mentor.com: Hi Jean-Michel, Phillip, Hi Steve, I've done some work on Philipp's June 12 patchset, converting the CSI driver to a CSI subdev entity, and fixing some issues here and there. This June 12 patchset doesn't appear to be a fully working driver, Phillip correct me if I am wrong. I can post this work as it exists, it is incomplete but compiles. Dos it compile against a 3.17-rc3 kernel :) ? No, not anymore, the original posted driver was against 3.16 IIRC. I've also worked out what I think is a workable video pipeline graph for i.MX, suitable for defining the entities, pads, and links. Unfortunately I haven't been able to spend as much time as I'd like on it. This is very interesting, do you have written this somewhere ? Yes, I'll try to find some time to create a pdf image. I'd be very interested in this, too. I have in the meantime started to implement everything that has a source or destination selector in the Frame Synchronization Unit (FSU) as media entity. I wonder which of these parts should reasonably be unified into a single entity: CSI0 CSI1 SMFC0 SMFC1 SMFC2 SMFC3 IC preprocessor (input to VF and ENC, if I understood correctly) IC viewfinder task (scaling, csc) IC encoding task IC post processing task IRT viewfinder task (rotation) IRT encoding task IRT post processing task VDIC (deinterlacing, combining) (and probably some entry for DP/DC/DMFC for the direct viewfinder path) I suppose the SMFC channels need to be separate because they can belong to different pipelines (and each entity can only belong to one). The three IC task entities could probably be combined with their corresponding IRT task entity somehow, but that would be at the cost of not being able to tell the kernel whether to rotate before or after scaling, which might be useful when handling chroma subsampled formats. I have put my current state up here: git://git.pengutronix.de/git/pza/linux.git test/nitrogen6x-ipu-media So far I've captured video through the SMFC on a Nitrogen6X board with OV5652 parallel camera with this. The complete driver I posted to the list does have some minor issues mostly suggested by Hans Verkuil (switch to new selection API instead of cropping API for example). It is a full featured driver but it does not implement the media device framework, i.e. user does not have direct control of the video pipeline, rather the driver chooses the pipeline based on the traditional inputs from user (video format and controls). If there is interest I can submit another version of the traditional driver to resolve the issues. But media device is a major rework, so I don't know whether it would make sense to start from the traditional driver and then implement media device on top later, since media device is almost a complete rewrite. I, at least, am interested by this driver, even in its traditionnal form :). If you don't want to submit it directly because this is not using media controller, this is ok, you can provide me a git repo in order to get it, or send a patchset. I think I'll follow Hans' proposal and submit it again to media-tree as a staging driver. I'm not too fond of adding a staging driver that we know will have to be replaced. Maybe we could work together to get a media entity based version up to speed? regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
Em Tue, 09 Sep 2014 12:36:54 -0300 Mauro Carvalho Chehab m.che...@samsung.com escreveu: Em Tue, 9 Sep 2014 15:41:58 +0100 Russell King - ARM Linux li...@arm.linux.org.uk escreveu: On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote: We want to be able to COMPILE_TEST the omap1_camera driver. It compiles fine, but it fails linkediting: ERROR: omap_stop_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_start_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_dma_link_lch [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_dest_burst_mode [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_src_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_request_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_transfer_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_dest_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_free_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! So, add some stub functions to avoid it. The real answer to this is to find someone who still uses it, and convert it to the DMA engine API. If there's no users, the driver might as well be killed off. Hmm... it seems that there are still several drivers still relying on the functions declared at: omap-dma.h: $ grep extern include/linux/omap-dma.h |perl -ne 'print $1\n if (m/extern\s\S+\s(.*)\(/)' funcs git grep -f funcs -l arch/arm/mach-omap1/pm.c arch/arm/mach-omap2/pm24xx.c arch/arm/plat-omap/dma.c drivers/dma/omap-dma.c drivers/media/platform/omap/omap_vout_vrfb.c drivers/media/platform/omap3isp/isphist.c drivers/media/platform/soc_camera/omap1_camera.c drivers/mtd/onenand/omap2.c drivers/usb/gadget/udc/omap_udc.c drivers/usb/musb/tusb6010_omap.c drivers/video/fbdev/omap/omapfb_main.c include/linux/omap-dma.h Perhaps we can remove the header and mark all the above as BROKEN. If nobody fixes, we can strip all of them from the Kernel. Are all the functions declared at omap-dma.h part of the old DMA API that should be deprecated? If so, it seems that the OMAP2 and OMAP3 also depends on this thing, as all the PM code for OMAP depends on the functions declared inside omap-dma.h, and marking them as BROKEN causes compilation to failure: arch/arm/mach-omap2/built-in.o: In function `omap3_save_scratchpad_contents': :(.text+0x798): undefined reference to `omap3_restore_3630' :(.text+0x7a8): undefined reference to `omap3_restore' :(.text+0x7ac): undefined reference to `omap3_restore_es3' arch/arm/mach-omap2/built-in.o: In function `omap3_sram_restore_context': :(.text+0x925c): undefined reference to `omap_push_sram_idle' arch/arm/mach-omap2/built-in.o: In function `option_set': :(.text+0xc15c): undefined reference to `omap3_pm_off_mode_enable' arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_set': :(.text+0xc1a0): undefined reference to `omap3_pm_set_suspend_state' arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_get': :(.text+0xc1e4): undefined reference to `omap3_pm_get_suspend_state' arch/arm/mach-omap2/built-in.o: In function `omap3_enter_idle_bm': :(.text+0xc7ec): undefined reference to `omap_sram_idle' :(.text+0xc848): undefined reference to `pm34xx_errata' arch/arm/mach-omap2/built-in.o: In function `omap2420_init_late': :(.init.text+0xf64): undefined reference to `omap2_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap2430_init_late': :(.init.text+0x1024): undefined reference to `omap2_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap3_init_late': :(.init.text+0x1248): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap3430_init_late': :(.init.text+0x1264): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap35xx_init_late': :(.init.text+0x1280): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap3630_init_late': :(.init.text+0x129c): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o: In function `am35xx_init_late': :(.init.text+0x12b8): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o::(.init.text+0x12d4): more undefined references to `omap3_pm_init' follow This was compiled with allmodconfig on arm, with COMPILE_TEST disabled (a few sub-archs disabled too), to avoid spurious unrelated compilation issues). Am I missing something? BTW, CONFIG_PM is auto-selected by ARCH_OMAP3. And those are the functions that the OMAP3 code uses from omap-dma.h: arch/arm/mach-omap2/pm34xx.c:92:2: error: implicit declaration of function ‘omap_dma_global_context_save’ [-Werror=implicit-function-declaration] arch/arm/mach-omap2/pm34xx.c:103:2: error:
Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
On Tuesday 09 September 2014 12:09:36 Mauro Carvalho Chehab wrote: -exynos4.c index e51c078360f5..01eeacf28843 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); +#ifndef CONFIG_COMPILE_TEST ndelay(10); +#endif Wouldn't be a better fix to replace ndelay(10); with udelay(100), rather than sticking in a not so pretty #ifndef ? Works for me. I'll submit a new version. New version looks good to me. On a more general level, I would argue that we should not disable code based on COMPILE_TEST. The typical use of this symbol is to make it possible to compile more code, not to change the behavior of code on machines that were able to build it already. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] vpif: Fix compilation with allmodconfig
On Tue, Sep 9, 2014 at 3:38 PM, Mauro Carvalho Chehab m.che...@samsung.com wrote: When vpif is compiled as module, those errors happen: ERROR: vpif_lock [drivers/media/platform/davinci/vpif_display.ko] undefined! ERROR: vpif_lock [drivers/media/platform/davinci/vpif_capture.ko] undefined! That's because vpif_lock symbol is not exported. Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Regards, --Prabhakar Lad Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c index cd08e5248387..3dad5bd7fe0a 100644 --- a/drivers/media/platform/davinci/vpif.c +++ b/drivers/media/platform/davinci/vpif.c @@ -38,6 +38,7 @@ MODULE_LICENSE(GPL); #define VPIF_CH3_MAX_MODES 2 spinlock_t vpif_lock; +EXPORT_SYMBOL_GPL(vpif_lock); void __iomem *vpif_base; EXPORT_SYMBOL_GPL(vpif_base); -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
Em Tue, 09 Sep 2014 19:54:19 +0200 Arnd Bergmann a...@arndb.de escreveu: On Tuesday 09 September 2014 12:09:36 Mauro Carvalho Chehab wrote: -exynos4.c index e51c078360f5..01eeacf28843 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); +#ifndef CONFIG_COMPILE_TEST ndelay(10); +#endif Wouldn't be a better fix to replace ndelay(10); with udelay(100), rather than sticking in a not so pretty #ifndef ? Works for me. I'll submit a new version. New version looks good to me. On a more general level, I would argue that we should not disable code based on COMPILE_TEST. The typical use of this symbol is to make it possible to compile more code, not to change the behavior of code on machines that were able to build it already. Yeah, agreed as a general concept. In this case, however, it were causing a compilation breakage on X86 (as it generates a non-existing _bad_ndelay() symbol, if the time is bigger than 2). See include/asm-generic/delay.h. Btw, I suspect that the only reason why ndelay(10) causes a compilation breakage is to avoid a big number, as the maximum limit check ndelay() code (2) at asm-generic is identical to the one for udelay(). So, for ndelay, it means 20us, while, for udelay, it means 20ms. Even so, both calls the very same implementation code. Perhaps we should fix it, for both to accept a maximum time of 20ms. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
ERROR: __bad_ndelay [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined! That happens because asm-generic doesn't like any ndelay time bigger than 20us. Currently, usleep_range() couldn't simply be used, since exynos4_jpeg_sw_reset() is called with a spinlock held. So, let's use udelay() instead. Reported-by: Stephen Rothwell s...@canb.auug.org.au Acked-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c index e51c078360f5..ab6d6f43c96f 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,7 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); - ndelay(10); + udelay(100); writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); } -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 3/3] [media] vpif: Fix compilation with allmodconfig
When vpif is compiled as module, those errors happen: ERROR: vpif_lock [drivers/media/platform/davinci/vpif_display.ko] undefined! ERROR: vpif_lock [drivers/media/platform/davinci/vpif_capture.ko] undefined! That's because vpif_lock symbol is not exported. Reported-by: Stephen Rothwell s...@canb.auug.org.au Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c index cd08e5248387..3dad5bd7fe0a 100644 --- a/drivers/media/platform/davinci/vpif.c +++ b/drivers/media/platform/davinci/vpif.c @@ -38,6 +38,7 @@ MODULE_LICENSE(GPL); #define VPIF_CH3_MAX_MODES 2 spinlock_t vpif_lock; +EXPORT_SYMBOL_GPL(vpif_lock); void __iomem *vpif_base; EXPORT_SYMBOL_GPL(vpif_base); -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/3] [media] disable OMAP1 COMPILE_TEST
This driver depends on a legacy OMAP DMA API. So, it won't compile-test on other archs. While we might add stubs to the functions, this is not a good idea, as the hole API should be replaced. So, for now, let's just remove COMPILE_TEST and wait for some time for people to fix. If not fixed, then we'll end by removing this driver as a hole. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig index 6af6c6dccda8..f2776cd415ca 100644 --- a/drivers/media/platform/soc_camera/Kconfig +++ b/drivers/media/platform/soc_camera/Kconfig @@ -63,7 +63,7 @@ config VIDEO_SH_MOBILE_CEU config VIDEO_OMAP1 tristate OMAP1 Camera Interface driver depends on VIDEO_DEV SOC_CAMERA - depends on ARCH_OMAP1 || COMPILE_TEST + depends on ARCH_OMAP1 depends on HAS_DMA select VIDEOBUF_DMA_CONTIG select VIDEOBUF_DMA_SG -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Si2165: Add experimental DVB-C support for HVR-4400/HVR-5500
This patch is sent out, because I got multiple requests for it.
So here it is.
It works only for HVR-4400/HVR-5500.
For WinTV-HVR-930C-HD it fails with bad/no reception for unknown reasons.
Signed-off-by: Matthias Schwarzott z...@gentoo.org
---
drivers/media/dvb-frontends/si2165.c | 132 +--
1 file changed, 125 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2165.c
b/drivers/media/dvb-frontends/si2165.c
index c807180..660298b 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -781,7 +781,7 @@ static int si2165_set_if_freq_shift(struct si2165_state
*state, u32 IF)
return si2165_writereg32(state, 0x00e8, reg_value);
}
-static int si2165_set_parameters(struct dvb_frontend *fe)
+static int si2165_set_parameters_t(struct dvb_frontend *fe)
{
int ret;
struct dtv_frontend_properties *p = fe-dtv_property_cache;
@@ -929,6 +929,119 @@ static int si2165_set_parameters(struct dvb_frontend *fe)
return 0;
}
+static int si2165_set_parameters_c(struct dvb_frontend *fe)
+{
+ struct dtv_frontend_properties *p = fe-dtv_property_cache;
+ struct si2165_state *state = fe-demodulator_priv;
+ u8 val[3];
+ u32 IF;
+
+ if (!state-has_dvbc)
+ return -EINVAL;
+
+ si2165_writereg8(state, 0x00e0, 0x00);
+
+ si2165_readreg8(state, 0x0118, val); /* returned 0x07 */
+
+ si2165_writereg8(state, 0x012a, 0x46);
+ si2165_writereg8(state, 0x012c, 0x00);
+ si2165_writereg8(state, 0x012e, 0x0a);
+ si2165_writereg8(state, 0x012f, 0xff);
+ si2165_writereg8(state, 0x0123, 0x70);
+ {
+ si2165_writereg8(state, 0x00ec, 0x05);
+ si2165_adjust_pll_divl(state, 0x0e);
+ }
+ si2165_readreg8(state, 0x00e0, val); /* returned 0x00 */
+ {
+ si2165_writereg32(state, 0x00e8, 0x02db6db6);
+ }
+ si2165_writereg8(state, 0x08f8, 0x00);
+ si2165_readreg8(state, 0x04e4, val); /* returned 0x21 */
+ si2165_writereg8(state, 0x04e4, 0x20); // clear bit 1
+ si2165_writereg16(state, 0x04ef, 0x00fe);
+ si2165_writereg24(state, 0x04f4, 0x55);
+ si2165_readreg8(state, 0x04e4, val); /* returned 0x20 */
+ si2165_writereg8(state, 0x04e4, 0x20);
+ si2165_readreg8(state, 0x04e5, val); /* returned 0x03 */
+ si2165_writereg8(state, 0x04e5, 0x03);
+ si2165_readreg8(state, 0x04e5, val); /* returned 0x03 */
+ si2165_writereg8(state, 0x04e5, 0x01);
+ {
+ si2165_writereg32(state, 0x00e4, 0x0494f77e);
+ si2165_writereg8(state, 0x016e, 0x50);
+ }
+ si2165_writereg8(state, 0x016c, 0x0e);
+ si2165_writereg8(state, 0x016d, 0x10);
+ si2165_writereg8(state, 0x015b, 0x03);
+ {
+ si2165_writereg8(state, 0x0150, 0x68);
+ si2165_writereg8(state, 0x01a0, 0x68);
+ si2165_writereg8(state, 0x01c8, 0x50);
+ si2165_readreg8(state, 0x0278, val); /* returned 0x0d */
+ si2165_writereg8(state, 0x0278, 0x0d);
+ si2165_writereg8(state, 0x023a, 0x05); // or 0x05
+ si2165_writereg8(state, 0x0261, 0x09);
+ si2165_writereg16(state, 0x0350, 0x3e80);
+ si2165_writereg8(state, 0x02f4, 0x00);
+ }
+ si2165_writereg32(state, 0x0348, 0xf400);
+ {
+ si2165_writereg32(state, 0x00c4, 0x007a1200);
+ si2165_writereg8(state, 0x00cb, 0x01);
+ si2165_writereg8(state, 0x00c0, 0x00);
+ si2165_writereg8(state, 0x012a, 0x46);
+ si2165_writereg8(state, 0x012c, 0x00);
+ si2165_writereg8(state, 0x012e, 0x0a);
+ si2165_writereg8(state, 0x012f, 0xff);
+ si2165_writereg8(state, 0x0123, 0x70);
+ si2165_writereg16(state, 0x024c, 0x);
+ si2165_writereg16(state, 0x027c, 0x);
+ si2165_writereg8(state, 0x0232, 0x03);
+ si2165_writereg8(state, 0x02f4, 0x0b);
+ si2165_writereg32(state, 0x00e4, 0x040ed730); // or 0x040ed730
+ si2165_writereg8(state, 0x00c0, 0x00);
+ si2165_readreg8(state, 0x0118, val); /* returned 0x07 */
+ si2165_writereg8(state, 0x018b, 0x00);
+ }
+
+ if (!fe-ops.tuner_ops.get_if_frequency) {
+ pr_err(Error: get_if_frequency() not defined at tuner. Can't
work without it!\n);
+ return -EINVAL;
+ }
+
+ if (fe-ops.tuner_ops.set_params)
+ fe-ops.tuner_ops.set_params(fe);
+
+ fe-ops.tuner_ops.get_if_frequency(fe, IF);
+
+ {
+ si2165_writereg32(state, 0x00e8, 0x02db6db6);
+ }
+ si2165_readreg8(state, 0x0341, val); /* returned 0x01 */
+ si2165_writereg8(state, 0x0341, 0x00);
+ si2165_writereg8(state, 0x00c0, 0x00);
+ si2165_writereg32(state, 0x0384, 0x);
+ si2165_writereg8(state, 0x02e0, 0x01);
+
+ return 0;
+}
+
+static int si2165_set_parameters(struct
Re: [PATCHv3 1/3] [media] disable OMAP1 COMPILE_TEST
Thanks, Mauro, On Tue, 9 Sep 2014, Mauro Carvalho Chehab wrote: This driver depends on a legacy OMAP DMA API. So, it won't compile-test on other archs. While we might add stubs to the functions, this is not a good idea, as the hole API should be replaced. So, for now, let's just remove COMPILE_TEST and wait for some time for people to fix. If not fixed, then we'll end by removing this driver as a hole. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Regards Guennadi diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig index 6af6c6dccda8..f2776cd415ca 100644 --- a/drivers/media/platform/soc_camera/Kconfig +++ b/drivers/media/platform/soc_camera/Kconfig @@ -63,7 +63,7 @@ config VIDEO_SH_MOBILE_CEU config VIDEO_OMAP1 tristate OMAP1 Camera Interface driver depends on VIDEO_DEV SOC_CAMERA - depends on ARCH_OMAP1 || COMPILE_TEST + depends on ARCH_OMAP1 depends on HAS_DMA select VIDEOBUF_DMA_CONTIG select VIDEOBUF_DMA_SG -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: spi: Add support for LMH0395
Hi Jean-Michel,
Thank you for the patch. Please see below for a couple of comments after a
very quick review.
On Tuesday 09 September 2014 17:51:25 Jean-Michel Hautbois wrote:
This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.
LMH0395 enables the use of up to two outputs.
These can be configured using DT.
Controls should be accessible from userspace too.
This will have to be done later.
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
When posting a new version please add here a description of what changed
compared to the previous version.
.../devicetree/bindings/media/spi/lmh0395.txt | 44 +++
MAINTAINERS| 6 +
drivers/media/spi/Kconfig | 14 +
drivers/media/spi/Makefile | 1 +
drivers/media/spi/lmh0395.c| 360 ++
5 files changed, 425 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
create mode 100644 drivers/media/spi/Kconfig
create mode 100644 drivers/media/spi/Makefile
create mode 100644 drivers/media/spi/lmh0395.c
diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt new file mode
100644
index 000..0a640a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,44 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to
2.97 Gbps +and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and
DVB-ASI standards.
+
+Required Properties :
+- compatible: Must be ti,lmh0395
+
+The device node must contain one 'port' child node per device input and
output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port
nodes
+are numbered as follows.
+
+ Port LMH0395
+
+ SDI input 0
+ SDI output 1,2
+
+Example:
+
+ecspi@0201 {
+ ...
+ ...
+
+ lmh0395@1 {
+ compatible = ti,lmh0395;
+ reg = 1;
+ spi-max-frequency = 2000;
+ ports {
+ port@0 {
+ reg = 0;
+ sdi0_in: endpoint {};
+ };
+ port@1 {
+ reg=1;
+ sdi0_out0: endpoint {};
+ };
This contradicts the above description, there should be 3 ports.
+ };
+ };
+ ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index cf24bb5..ca42b9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9141,6 +9141,12 @@ S: Maintained
F: sound/soc/codecs/lm49453*
F: sound/soc/codecs/isabelle*
+TI LMH0395 DRIVER
+M: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/spi/lmh0395*
+
TI LP855x BACKLIGHT DRIVER
M: Milo Kim milo@ti.com
S: Maintained
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..291e7ea
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+ tristate LMH0395 equalizer
+ depends on VIDEO_V4L2 SPI MEDIA_CONTROLLER
+ ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395) += lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..fe5c5f8
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,360 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014 Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable
Equalizer
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it
Re: [PATCH] V4L2: UVC: allow using larger buffers
Hi Guennadi,
Thank you for the patch.
On Tuesday 09 September 2014 09:42:43 Guennadi Liakhovetski wrote:
A test in uvc_video_decode_isoc() checks whether an image has been
received from the camera completely. For this the data amount is compared
to the buffer length, which, however, doesn't have to be equal to the
image size. Switch to using formats .sizeimage field for an exact
expected image size.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Thanks to Laurent for the idea
drivers/media/usb/uvc/uvc_v4l2.c | 1 +
drivers/media/usb/uvc/uvc_video.c | 2 +-
drivers/media/usb/uvc/uvcvideo.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
b/drivers/media/usb/uvc/uvc_v4l2.c index 3b548b8..87d15c2 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -318,6 +318,7 @@ static int uvc_v4l2_set_format(struct uvc_streaming
*stream, stream-ctrl = probe;
stream-cur_format = format;
stream-cur_frame = frame;
+ stream-image_size = fmt-fmt.pix.sizeimage;
done:
mutex_unlock(stream-mutex);
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c index e568e07..60abf6f 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1172,7 +1172,7 @@ static void uvc_video_decode_isoc(struct urb *urb,
struct uvc_streaming *stream, urb-iso_frame_desc[i].actual_length);
if (buf-state == UVC_BUF_STATE_READY) {
- if (buf-length != buf-bytesused
+ if (stream-image_size != buf-bytesused
!(stream-cur_format-flags
UVC_FMT_FLAG_COMPRESSED))
buf-error = 1;
diff --git a/drivers/media/usb/uvc/uvcvideo.h
b/drivers/media/usb/uvc/uvcvideo.h index 404793b..d3a3b71 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -480,6 +480,7 @@ struct uvc_streaming {
struct uvc_format *def_format;
struct uvc_format *cur_format;
struct uvc_frame *cur_frame;
+ size_t image_size;
As UVC uses the term frame size instead of image size, would you mind renaming
that field ? I can do that while applying the patch, there's no need to
resubmit if you're fine with the change.
/* Protect access to ctrl, cur_format, cur_frame and hardware video
* probe control.
*/
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Darlehen anbieten
-- Wir bieten persönliche und geschäftliche Kredite ohne Sicherheiten (nur zur Identifizierung) mit maximaler Garantie, ab € 10.000 bis € 90.000.000 bei 3% Zinsen in 1 Jahr bis 20 Jahre Laufzeit überall in der Welt! Jetzt bewerben! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Darlehen anbieten
-- Wir bieten persönliche und geschäftliche Kredite ohne Sicherheiten (nur zur Identifizierung) mit maximaler Garantie, ab € 10.000 bis € 90.000.000 bei 3% Zinsen in 1 Jahr bis 20 Jahre Laufzeit überall in der Welt! Jetzt bewerben! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Sep 10 04:00:20 CEST 2014 git branch: test git hash: f5281fc81e9a0a3e80b78720c5ae2ed06da3bfae gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.16-1.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16-i686: WARNINGS linux-3.17-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16-x86_64: WARNINGS linux-3.17-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
