Re: ext_lock (was viafb camera controller driver)
On Wednesday, October 20, 2010 21:23:42 Jonathan Corbet wrote: On Tue, 19 Oct 2010 08:54:40 +0200 Hans Verkuil hverk...@xs4all.nl wrote: We are working on removing the BKL. As part of that effort it is now possible for drivers to pass a serialization mutex to the v4l core (a mutex pointer was added to struct video_device). If the core sees that mutex then the core will serialize all open/ioctl/read/write/etc. file ops. So all file ops will in that case be called with that mutex held. Which is fine, but if the driver has to do a blocking wait, then you need to unlock the mutex first and lock it again afterwards. And since videobuf does a blocking wait it needs to know about that mutex. So videobuf is expecting that you're passing this special device mutex in particular? In that case, why not just use it directly? The problem is that videobuf has to cater for two possible scenarios regarding external locks: either it is the core lock which can be obtained through struct video_device, or it is a driver-owned lock. In both cases videobuf has to unlock before the wait. So I can't just give it a pointer to video_device. For the next kernel cycle we should start the work to convert drivers to unlocked_ioctl and the core lock or a private lock. Hopefully that will give us a better idea of how this can be improved. Having a separate pointer to (what looks like) a distinct lock seems like a way to cause fatal confusion. Given the tightness of the rules here (you *must* know that this ext_lock has been grabbed by the v4l core in the current call chain or you cannot possibly unlock it safely), I don't get why you wouldn't use the lock directly. I would be inclined to go even further and emit a warning if the mutex is *not* locked. It seems that the rules would require it, no? If mutex debugging is turned on, you could even check if the current task is the locker, would would be even better. I agree with this. Mauro, I propose this change: BUG_ON(q-ext_lock !mutex_is_locked(q-ext_lock)); if (q-ext_lock) mutex_unlock(q-ext_lock); ... if (q-ext_lock) mutex_lock(q-ext_lock); It makes no sense to provide an external lock and not having it locked here. In general, put me in the leery of central locking camp. If you don't understand locking, you're going to mess things up somewhere along the way. And, as soon as you get into hardware with interrupts, it seems like you have to deal with your own locking for access to the hardware regardless... Do you want to tackle the task of fixing all the old BKL drivers? That is still the primary motivation for doing this, you know. I really don't fancy putting manual locking in those drivers and auditing them all. BTW, I want to add another reason why core-assisted locking is a good idea for many drivers: the chances of hitting a race condition if the locking isn't quite right are exceedingly low for v4l drivers. In general there is just a single application that opens the device, streams and closes it again. It is very rare for, say two apps to open the device at almost the same time, or one closing it and another opening it. Or for two apps calling an ioctl at the same time. So things may seem to work just dandy, even though a driver contains more races than you can shake a stick at. Given the fact that a considerable amount of work went into verifying that the v4l2 core does locking right (and I'm talking not just about the new core locking feature, but also about the locks protecting internal core data structures), and that it usually took several tries to get it right, I am not at all confident that the same wouldn't happen on a much larger scale in all the drivers. Particularly if it is a hot-pluggable driver. Anyway, driver developers are completely free to choose either core-assisted locking or manual locking. But for the BKL conversion core-assisted locking is the only way if we want to have any hope of finishing that conversion in a reasonable amount of time and with a reasonable degree of confidence in the correctness of the locking. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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 PATCHES FOR 2.6.36] gspca for_2.6.36
Hi Mauro, I added two fixes of an other regression. They should go to 2.6.36. The following changes since commit d65728875a85ac7c8b7d6eb8d51425bacc188980: V4L/DVB: v4l: radio: si470x: fix unneeded free_irq() call (2010-09-30 07:35:12 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.36 Jean-François Moine (3): gspca - main: Fix a regression with the PS3 Eye webcam gspca - sonixj: Fix a regression of sensors hv7131r and mi0360 gspca - sonixj: Fix a regression with sensor hv7131r drivers/media/video/gspca/gspca.c |4 ++-- drivers/media/video/gspca/sonixj.c |6 ++ 2 files changed, 4 insertions(+), 6 deletions(-) Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] v4l-utils: Add support for new RDS CAP bits.
Add support for V4L2_TUNER_CAP_RDS_BLOCK_IO and V4L2_TUNER_CAP_RDS_CONTROLS tuner/modulator capability bits. Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com --- utils/v4l2-ctl/v4l2-ctl.cpp |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/utils/v4l2-ctl/v4l2-ctl.cpp b/utils/v4l2-ctl/v4l2-ctl.cpp index ab9a7d1..bd971dc 100644 --- a/utils/v4l2-ctl/v4l2-ctl.cpp +++ b/utils/v4l2-ctl/v4l2-ctl.cpp @@ -1266,6 +1266,10 @@ static std::string tcap2s(unsigned cap) s += lang2 ; if (cap V4L2_TUNER_CAP_RDS) s += rds ; + if (cap V4L2_TUNER_CAP_RDS_BLOCK_IO) + s += rds-block-io ; + if (cap V4L2_TUNER_CAP_RDS_CONTROLS) + s += rds-controls ; return s; } -- 1.6.1.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 5/6 v5] V4L/DVB: s5p-fimc: Add camera capture support
Latest your reply is easy to understand.
And I send you another parts review comments.
Tuesday, October 12, 2010 2:27, Sylwester Nawrocki wrote :
Add a video device driver per each FIMC entity to support
the camera capture input mode. Video capture node is registered
only if CCD sensor data is provided through driver's platfrom data
and board setup code.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/video/s5p-fimc/Makefile |2 +-
drivers/media/video/s5p-fimc/fimc-capture.c | 819
+++
drivers/media/video/s5p-fimc/fimc-core.c| 563 +--
drivers/media/video/s5p-fimc/fimc-core.h| 205 +++-
drivers/media/video/s5p-fimc/fimc-reg.c | 173 +-
include/media/s3c_fimc.h| 60 ++
6 files changed, 1630 insertions(+), 192 deletions(-)
create mode 100644 drivers/media/video/s5p-fimc/fimc-capture.c
create mode 100644 include/media/s3c_fimc.h
diff --git a/drivers/media/video/s5p-fimc/Makefile
b/drivers/media/video/s5p-fimc/Makefile
index 0d9d541..7ea1b14 100644
--- a/drivers/media/video/s5p-fimc/Makefile
+++ b/drivers/media/video/s5p-fimc/Makefile
@@ -1,3 +1,3 @@
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) := s5p-fimc.o
-s5p-fimc-y := fimc-core.o fimc-reg.o
+s5p-fimc-y := fimc-core.o fimc-reg.o fimc-capture.o
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
new file mode 100644
index 000..e8f13d3
--- /dev/null
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -0,0 +1,819 @@
+/*
+ * Samsung S5P SoC series camera interface (camera capture) driver
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd
+ * Author: Sylwester Nawrocki, s.nawro...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/version.h
+#include linux/types.h
+#include linux/errno.h
+#include linux/bug.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/clk.h
+#include linux/i2c.h
+
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-mem2mem.h
+#include media/videobuf-core.h
+#include media/videobuf-dma-contig.h
+
+#include fimc-core.h
+
+static struct v4l2_subdev *fimc_subdev_register(struct fimc_dev *fimc,
+ struct s3c_fimc_isp_info *isp_info)
+{
+ struct i2c_adapter *i2c_adap;
+ struct fimc_vid_cap *vid_cap = fimc-vid_cap;
+ struct v4l2_subdev *sd = NULL;
+
+ i2c_adap = i2c_get_adapter(isp_info-i2c_bus_num);
+ if (!i2c_adap)
+ return ERR_PTR(-ENOMEM);
+
+ sd = v4l2_i2c_new_subdev_board(vid_cap-v4l2_dev, i2c_adap,
+MODULE_NAME, isp_info-board_info, NULL);
+ if (!sd) {
+ v4l2_err(vid_cap-v4l2_dev, failed to acquire subdev\n);
+ return NULL;
+ }
+
+ v4l2_info(vid_cap-v4l2_dev, subdevice %s registered
successfuly\n,
+ isp_info-board_info-type);
+
+ return sd;
+}
+
+static void fimc_subdev_unregister(struct fimc_dev *fimc)
+{
+ struct fimc_vid_cap *vid_cap = fimc-vid_cap;
+ struct i2c_client *client;
+
+ if (vid_cap-input_index 0)
+ return; /* Subdevice already released or not registered.
*/
+
+ if (vid_cap-sd) {
+ v4l2_device_unregister_subdev(vid_cap-sd);
+ client = v4l2_get_subdevdata(vid_cap-sd);
+ i2c_unregister_device(client);
+ i2c_put_adapter(client-adapter);
+ vid_cap-sd = NULL;
+ }
+
+ vid_cap-input_index = -1;
+}
(snip)
+static int fimc_cap_s_fmt(struct file *file, void *priv,
+ struct v4l2_format *f)
+{
+ struct fimc_ctx *ctx = priv;
+ struct fimc_dev *fimc = ctx-fimc_dev;
+ struct fimc_frame *frame;
+ struct v4l2_pix_format *pix;
+ int ret;
+
+ if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
+ ret = fimc_vidioc_try_fmt(file, priv, f);
+ if (ret)
+ return ret;
+
+ if (mutex_lock_interruptible(fimc-lock))
+ return -ERESTARTSYS;
+
+ if (fimc_capture_active(fimc)) {
+ ret = -EBUSY;
+ goto sf_unlock;
+ }
I suggest to use vb_lock on here.
You already use vb_lock fimc_m2m_s_fmt function in fimc-core.c code
-- sample --
struct fimc_capture_device *cap = ctx-fimc_dev-vid_cap;
mutex_lock(cap-vbq-vb-lock);
+
+ frame = ctx-d_frame;
+
+ pix
Re: [PATCH] v4l-utils: Add support for new RDS CAP bits.
Hi Matti, Looks good. I'll merge it in v4l-utils once the driver is merged in v4l-dvb. Regards, Hans Add support for V4L2_TUNER_CAP_RDS_BLOCK_IO and V4L2_TUNER_CAP_RDS_CONTROLS tuner/modulator capability bits. Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com --- utils/v4l2-ctl/v4l2-ctl.cpp |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/utils/v4l2-ctl/v4l2-ctl.cpp b/utils/v4l2-ctl/v4l2-ctl.cpp index ab9a7d1..bd971dc 100644 --- a/utils/v4l2-ctl/v4l2-ctl.cpp +++ b/utils/v4l2-ctl/v4l2-ctl.cpp @@ -1266,6 +1266,10 @@ static std::string tcap2s(unsigned cap) s += lang2 ; if (cap V4L2_TUNER_CAP_RDS) s += rds ; + if (cap V4L2_TUNER_CAP_RDS_BLOCK_IO) + s += rds-block-io ; + if (cap V4L2_TUNER_CAP_RDS_CONTROLS) + s += rds-controls ; return s; } -- 1.6.1.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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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/4] MFC: Add MFC 5.1 V4L2 driver
I have some opinion about the usage of wait_event_interruptible_timeout()
k.deb...@samsung.com wrote:
[snip]
+
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_intr.c
b/drivers/media/video/s5p-mfc/s5p_mfc_intr.c
new file mode 100644
index 000..543f3fb
--- /dev/null
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_intr.c
@@ -0,0 +1,77 @@
+/*
+ * drivers/media/video/samsung/mfc5/s5p_mfc_intr.c
+ *
+ * C file for Samsung MFC (Multi Function Codec - FIMV) driver
+ * This file contains functions used to wait for command completion.
+ *
+ * Kamil Debski, Copyright (c) 2010 Samsung Electronics
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/errno.h
+#include linux/wait.h
+#include linux/sched.h
+#include linux/io.h
+#include regs-mfc5.h
+#include s5p_mfc_intr.h
+#include s5p_mfc_logmsg.h
+#include s5p_mfc_common.h
+
+int s5p_mfc_wait_for_done_dev(struct s5p_mfc_dev *dev, int command)
+{
+ if (wait_event_interruptible_timeout(dev-queue,
+ (dev-int_cond (dev-int_type == command
+ || dev-int_type == S5P_FIMV_R2H_CMD_DECODE_ERR_RET)),
+ msecs_to_jiffies(MFC_INT_TIMEOUT)) == 0) {
+ mfc_err(Interrupt (%d dev) timed out.\n, dev-int_type);
+ return 1;
+ }
+ mfc_debug(Finished waiting (dev-queue, %d).\n, dev-int_type);
+ if (dev-int_type == S5P_FIMV_R2H_CMD_ERROR_RET)
+ return 1;
+ return 0;
+}
You used wait_event_interruptible_timeout() in the driver, but this
function is
considered not only int. by MFC but also int. by some signal. I'm wondering
whether we have to consider interrupt by signal in the middle of hw
operation.
and also I cannot see some operation(handler) in case of wake-up by signal.
So, why don’t you remove the interruptible function or add some operation
in case of
wake-up by signal. (refer to the other driver in the kernel)
+
+void s5p_mfc_clean_dev_int_flags(struct s5p_mfc_dev *dev)
+{
+ dev-int_cond = 0;
+ dev-int_type = 0;
+ dev-int_err = 0;
+}
+
+int s5p_mfc_wait_for_done_ctx(struct s5p_mfc_ctx *ctx,
+ int command, int interrupt)
+{
+ int ret;
+ if (interrupt) {
+ ret = wait_event_interruptible_timeout(ctx-queue,
+ (ctx-int_cond (ctx-int_type == command
+ || ctx-int_type ==
S5P_FIMV_R2H_CMD_DECODE_ERR_RET)),
+ msecs_to_jiffies(MFC_INT_TIMEOUT));
+ } else {
+ ret = wait_event_timeout(ctx-queue,
+ (ctx-int_cond (ctx-int_type == command
+ || ctx-int_type ==
S5P_FIMV_R2H_CMD_DECODE_ERR_RET)),
+ msecs_to_jiffies(MFC_INT_TIMEOUT));
+ }
+ if (ret == 0) {
+ mfc_err(Interrupt (%d ctx) timed out.\n, ctx-int_type);
+ return 1;
+ }
+ mfc_debug(Finished waiting (ctx-queue, %d).\n, ctx-int_type);
+ if (ctx-int_type == S5P_FIMV_R2H_CMD_ERROR_RET)
+ return 1;
+ return 0;
+}
+
+void s5p_mfc_clean_ctx_int_flags(struct s5p_mfc_ctx *ctx)
+{
+ ctx-int_cond = 0;
+ ctx-int_type = 0;
+ ctx-int_err = 0;
+}
[snip]
--
1.6.3.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
--
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: Old patches sent via the Mailing list
Em 20-10-2010 16:01, Sven Barth escreveu: On 20.10.2010 14:00, Andy Walls wrote: On Wed, 2010-10-20 at 07:19 +0200, Sven Barth wrote: Am 18.10.2010 08:15, schrieb Mauro Carvalho Chehab: Em 17-10-2010 21:36, Andy Walls escreveu: The last time I sent this list, I was about to travel, and I may have missed some comments, or maybe I may just forgot to update. But I suspect that, for the list bellow, most of them are stuff where the driver maintainer just forgot at limbo. From the list of patches under review, we have: Waiting for new patch, signed, from Sven Barthpascaldra...@googlemail.com Apr,25 2010: Problem with cx25840 and Terratec Grabster AV400 http://patchwork.kernel.org/patch/94960 Sven Barthpascaldra...@googlemail.com Sven, We need a Signed-off-by: for your submitted patch: http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Sign_your_work Note, your patch has an obvious, unintentional white space change for if (std == V4L2_STD_NTSC_M_JP), so could you fix that up and send a new signed off version? Eh... I thought I had superseeded it with the patch from 10th July (mail title: [PATCH] Add support for AUX_PLL on cx2583x chips). It included a Signed-of by from me as well as Acked by from Mike and Andy and I also excluded the whitespace change ^^ Hi Sven, http://www.mail-archive.com/linux-media@vger.kernel.org/msg20296.html So you have. How embarrassing.:} Well... it's a bit hard to keep the overview in this list. ;) I only saw this thread about old patches by pure luck. And thank you for digging up the link, I only had the mail version lying around. [And finally I won't have to patch v4l manually anymore... yippieh! I'm looking forward to 2.6.37 :D (Good that I use a distro (ArchLinux) that has a rolling release style ^^) ] OK, I've replaced the non-signed patch to the signed one, at the new branch I've created for the patches that I'll send during the merge window (staging/v2.6.37-rc1). The reason why the new patch were not catched is that the emailer broke long lines on your patch, so, patchwork didn't catch it. Please, next time, be sure that you'll submit your patch with an emailer that don't break long lines. Thanks, 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
RE: [PATCH 3/4] MFC: Add MFC 5.1 V4L2 driver
Hi,
I commented as belows,
And you missed one important things 'cause there were my comments
in the very long email which is strongly fixed in the reset seq.
Yes, thanks for your suggestion.
[]
+#define READL(offset) readl(dev-regs_base + (offset))
+#define WRITEL(data, offset) writel((data), dev-regs_base +
(offset))
+#define OFFSETA(x) (((x) - dev-port_a) 11)
+#define OFFSETB(x) (((x) - dev-port_b) 11)
+
+/* Reset the device */
+static int s5p_mfc_cmd_reset(struct s5p_mfc_dev *dev)
+{
+ unsigned int mc_status;
+ unsigned long timeout;
+ mfc_debug(s5p_mfc_cmd_reset++\n);
+ /* Stop procedure */
+ WRITEL(0x3f7, S5P_FIMV_SW_RESET); /* reset VI */
Ahm, This (WRITEL(0x3f7, S5P_FIMV_SW_RESET)) might be a problem.
In the reset seq. of MFC driver, we checked out
That FW(s5pc110-mfc.fw in the s5p_mfc_load_firmware()) runned by RISC
core
at this point could access invalid address. It should be removed.
Thanks for pointing this out. I will remove it in the next version.
[snip]
Best regards
--
Kamil Debski
Linux Platform Group
Samsung Poland RD Center
--
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/4] MFC: Add MFC 5.1 V4L2 driver
Hello,
I have some opinion about the usage of
wait_event_interruptible_timeout()
k.deb...@samsung.com wrote:
[snip]
+
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_intr.c
b/drivers/media/video/s5p-mfc/s5p_mfc_intr.c
new file mode 100644
index 000..543f3fb
--- /dev/null
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_intr.c
@@ -0,0 +1,77 @@
+/*
+ * drivers/media/video/samsung/mfc5/s5p_mfc_intr.c
+ *
+ * C file for Samsung MFC (Multi Function Codec - FIMV) driver
+ * This file contains functions used to wait for command completion.
+ *
+ * Kamil Debski, Copyright (c) 2010 Samsung Electronics
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/errno.h
+#include linux/wait.h
+#include linux/sched.h
+#include linux/io.h
+#include regs-mfc5.h
+#include s5p_mfc_intr.h
+#include s5p_mfc_logmsg.h
+#include s5p_mfc_common.h
+
+int s5p_mfc_wait_for_done_dev(struct s5p_mfc_dev *dev, int command)
+{
+ if (wait_event_interruptible_timeout(dev-queue,
+ (dev-int_cond (dev-int_type == command
+ || dev-int_type == S5P_FIMV_R2H_CMD_DECODE_ERR_RET)),
+ msecs_to_jiffies(MFC_INT_TIMEOUT)) == 0) {
+ mfc_err(Interrupt (%d dev) timed out.\n, dev-int_type);
+ return 1;
+ }
+ mfc_debug(Finished waiting (dev-queue, %d).\n, dev-int_type);
+ if (dev-int_type == S5P_FIMV_R2H_CMD_ERROR_RET)
+ return 1;
+ return 0;
+}
You used wait_event_interruptible_timeout() in the driver, but this
function is
considered not only int. by MFC but also int. by some signal. I'm
wondering
whether we have to consider interrupt by signal in the middle of hw
operation.
and also I cannot see some operation(handler) in case of wake-up by
signal.
So, why don't you remove the interruptible function or add some
operation
in case of
wake-up by signal. (refer to the other driver in the kernel)
I can see a situation when handling a signal might be useful. If for some
reason (corrupt firmware file for example) the MFC fails to initialize then
the
application will seem frozen to the user. The user can press Ctrl-C and
expects the app to terminate. This would not happen if the used wait
procedure
was non interruptible.
Therefore I think adding code to handle signal is better than changing this
wait
to non interruptible.
+
+void s5p_mfc_clean_dev_int_flags(struct s5p_mfc_dev *dev)
+{
+ dev-int_cond = 0;
+ dev-int_type = 0;
+ dev-int_err = 0;
+}
+
+int s5p_mfc_wait_for_done_ctx(struct s5p_mfc_ctx *ctx,
+ int command, int interrupt)
+{
+ int ret;
+ if (interrupt) {
+ ret = wait_event_interruptible_timeout(ctx-queue,
+ (ctx-int_cond (ctx-int_type == command
+ || ctx-int_type ==
S5P_FIMV_R2H_CMD_DECODE_ERR_RET)),
+ msecs_to_jiffies(MFC_INT_TIMEOUT));
+ } else {
+ ret = wait_event_timeout(ctx-queue,
+ (ctx-int_cond (ctx-int_type == command
+ || ctx-int_type ==
S5P_FIMV_R2H_CMD_DECODE_ERR_RET)),
+ msecs_to_jiffies(MFC_INT_TIMEOUT));
+ }
+ if (ret == 0) {
+ mfc_err(Interrupt (%d ctx) timed out.\n, ctx-int_type);
+ return 1;
+ }
+ mfc_debug(Finished waiting (ctx-queue, %d).\n, ctx-int_type);
+ if (ctx-int_type == S5P_FIMV_R2H_CMD_ERROR_RET)
+ return 1;
+ return 0;
+}
+
+void s5p_mfc_clean_ctx_int_flags(struct s5p_mfc_ctx *ctx)
+{
+ ctx-int_cond = 0;
+ ctx-int_type = 0;
+ ctx-int_err = 0;
+}
[snip]
Best regards,
--
Kamil Debski
Linux Platform Group
Samsung Poland RD Center
--
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] mceusb: add support for cx231xx-based IR (e. g. Polaris)
Em 19-10-2010 15:50, Jarod Wilson escreveu: On Mon, Oct 18, 2010 at 08:52:57PM -0200, Mauro Carvalho Chehab wrote: For now, it adds support for Conexant EVK and for Pixelview. We should probably find a better way to specify all Conexant Polaris devices, to avoid needing to repeat this setup on both mceusb and cx231xx-cards. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Looks good to me. Reviewed-by: Jarod Wilson ja...@redhat.com Thanks! I'll remove the Pixelview ID from it, as it has an extra chip for IR decoding, so, we'll likely need to do something else for IR to work on it. So, I'm keeping, for now, just the Conexant EVK USB ID. Probably other cx231xx non-ISDB-T devices should work via mceusb as well. Thanks, 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
Re: [PATCH RFC] ir-rc5-decoder: don't wait for the end space to produce a code
On Oct 20, 2010, at 1:18 PM, Mauro Carvalho Chehab wrote: The RC5 decoding is complete at a BIT_END state. there's no reason to wait for the next space to produce a code. Well, if I'm reading things correctly here, I think the only true functional difference made to the decoder here was to skip the if (ev.pulse) break; check in STATE_FINISHED, no? In other words, this looks like it was purely an issue with the receiver data parsing, which was ending on a pulse instead of a space. I can make this guess in greater confidence having seen another patch somewhere that implements a different buffer parsing routine for the polaris devices though... ;) The mceusb portion of the patch is probably a worthwhile micro-optimization of its ir processing routine though -- don't call ir_raw_event_handle if there's no event to handle. Lemme just go ahead and merge that part via my staging tree, if you don't mind. (I've got a dozen or so IR patches that have been queueing up, planning on another pull req relatively soon). -- Jarod Wilson ja...@wilsonet.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
USB DVBT af9015: tuner id:177 not supported, please report!
I could not get this DVBT-Stick (USB) to work: auvisio USB-DVB-T-Receiver -Recorder DR-340 h t t p : / / w w w .pearl.de/product.jsp?pdid=HPM1520catid=8909vid=922curr=DEM dmesg: [25239.410175] usb 2-1: new high speed USB device using ehci_hcd and address 6 [25239.569729] Afatech DVB-T 2: Fixing fullspeed to highspeed interval: 10 - 7 [25239.570294] input: Afatech DVB-T 2 as /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.1/input/input12 [25239.570642] generic-usb 0003:15A4:9016.0003: input,hidraw2: USB HID v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:1d.7-1/input1 [25239.982243] af9015: tuner id:177 not supported, please report! [25239.982339] usbcore: registered new interface driver dvb_usb_af9015 Cheers! -- 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 RFC] ir-rc5-decoder: don't wait for the end space to produce a code
Em 21-10-2010 11:46, Jarod Wilson escreveu: On Oct 20, 2010, at 1:18 PM, Mauro Carvalho Chehab wrote: The RC5 decoding is complete at a BIT_END state. there's no reason to wait for the next space to produce a code. Well, if I'm reading things correctly here, I think the only true functional difference made to the decoder here was to skip the if (ev.pulse) break; check in STATE_FINISHED, no? In other words, this looks like it was purely an issue with the receiver data parsing, which was ending on a pulse instead of a space. I can make this guess in greater confidence having seen another patch somewhere that implements a different buffer parsing routine for the polaris devices though... ;) This patch doesn't solve the Polaris issue ;) While I made it in the hope that it would fix Polaris (it ended by not solving), I still think it can be kept, as it speeds up a little bit the RC-5 output, by not waiting for the last space. I'll be forwarding soon the polaris decoder fixes patch, and another mceusb patch I did, improving data decode on debug mode. The mceusb portion of the patch is probably a worthwhile micro-optimization of its ir processing routine though -- don't call ir_raw_event_handle if there's no event to handle. Lemme just go ahead and merge that part via my staging tree, if you don't mind. (I've got a dozen or so IR patches that have been queueing up, planning on another pull req relatively soon). Oh! I didn't notice that this went into the patch... for sure it doesn't belong here. Yes, it is just a cleanup for mceusb. Feel free to split it, adding a proper description for it and preserving my SOB. Thanks, 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 3/4] [media] mceusb: Improve parser to get codes sent together with IR RX data
On cx231xx, sometimes, several control messages are sent together
with data. Improves the parser to also handle those cases.
For example:
[38777.211690] mceusb 7-6:1.0: rx data: 9f 14 01 9f 15 00 00 80 (length=8)
[38777.211696] mceusb 7-6:1.0: Got long-range receive sensor in use
[38777.211700] mceusb 7-6:1.0: Received pulse count is 0
[38777.211703] mceusb 7-6:1.0: IR data len = 0
[38777.211707] mceusb 7-6:1.0: New data. rem: 0x1f, cmd: 0x80
Before this patch, only the first message would be displayed, as the
parser would be stopping at 9f 14 01.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index a726f63..609bf3d 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -343,99 +343,130 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir,
char *buf,
else
strcpy(inout, Got\0);
- cmd= buf[idx] 0xff;
- subcmd = buf[idx + 1] 0xff;
- data1 = buf[idx + 2] 0xff;
- data2 = buf[idx + 3] 0xff;
+ while (idx len) {
+ cmd= buf[idx] 0xff;
+ subcmd = buf[idx + 1] 0xff;
+ data1 = buf[idx + 2] 0xff;
+ data2 = buf[idx + 3] 0xff;
- switch (cmd) {
- case 0x00:
- if (subcmd == 0xff data1 == 0xaa)
- dev_info(dev, Device reset requested\n);
- else
- dev_info(dev, Unknown command 0x%02x 0x%02x\n,
-cmd, subcmd);
- break;
- case 0xff:
- switch (subcmd) {
- case 0x0b:
- if (len == 2)
- dev_info(dev, Get hw/sw rev?\n);
- else
- dev_info(dev, hw/sw rev 0x%02x 0x%02x
-0x%02x 0x%02x\n, data1, data2,
-buf[idx + 4], buf[idx + 5]);
- break;
- case 0xaa:
- dev_info(dev, Device reset requested\n);
- break;
- case 0xfe:
- dev_info(dev, Previous command not supported\n);
- break;
- case 0x18:
- case 0x1b:
- default:
- dev_info(dev, Unknown command 0x%02x 0x%02x\n,
-cmd, subcmd);
- break;
- }
- break;
- case 0x9f:
- switch (subcmd) {
- case 0x03:
- dev_info(dev, Ping\n);
- break;
- case 0x04:
- dev_info(dev, Resp to 9f 05 of 0x%02x 0x%02x\n,
-data1, data2);
- break;
- case 0x06:
- dev_info(dev, %s carrier mode and freq of
-0x%02x 0x%02x\n, inout, data1, data2);
- break;
- case 0x07:
- dev_info(dev, Get carrier mode and freq\n);
- break;
- case 0x08:
- dev_info(dev, %s transmit blaster mask of 0x%02x\n,
-inout, data1);
- break;
- case 0x0c:
- /* value is in units of 50us, so x*50/100 or x/2 ms */
- dev_info(dev, %s receive timeout of %d ms\n,
-inout, ((data1 8) | data2) / 2);
- break;
- case 0x0d:
- dev_info(dev, Get receive timeout\n);
- break;
- case 0x13:
- dev_info(dev, Get transmit blaster mask\n);
- break;
- case 0x14:
- dev_info(dev, %s %s-range receive sensor in use\n,
-inout, data1 == 0x02 ? short : long);
- break;
- case 0x15:
- if (len == 2)
- dev_info(dev, Get receive sensor\n);
+ /*
+* skip command/subcommand
+* The size of each package at the protocol depends
+* on the given command/subcommand
+*/
+ idx += 2;
+
+ switch (cmd) {
+ case 0x00:
+ if (subcmd == 0xff data1 == 0xaa)
+ dev_info(dev, Device reset requested\n);
else
- dev_info(dev, Received pulse count is %d\n,
-((data1 8) | data2));
+ dev_info(dev, Unknown command 0x%02x 0x%02x\n,
+cmd, subcmd);
+
[PATCH 4/4] [media] mceusb: Fix parser for Polaris
Add a parser for polaris mce. On this device, sometimes, a control
data appears together with the IR data, causing problems at the parser.
Also, it signalizes the end of a data with a 0x80 value. The normal
parser would believe that this is a time with 0x1f size, but cx231xx
provides just one byte for it.
I'm not sure if the new parser would work for other devices (probably, it
will), but the better is to just write it as a new parser, to avoid breaking
support for other supported IR devices.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index 609bf3d..7210760 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -265,6 +265,7 @@ struct mceusb_dev {
u32 connected:1;
u32 tx_mask_inverted:1;
u32 microsoft_gen1:1;
+ u32 is_polaris:1;
u32 reserved:29;
} flags;
@@ -697,6 +698,90 @@ static int mceusb_set_tx_carrier(void *priv, u32 carrier)
return carrier;
}
+static void mceusb_parse_polaris(struct mceusb_dev *ir, int buf_len)
+{
+ struct ir_raw_event rawir;
+ int i;
+ u8 cmd;
+
+ while (i buf_len) {
+ cmd = ir-buf_in[i];
+
+ /* Discard any non-IR cmd */
+
+ if ((cmd 0xe0) 5 != 4) {
+ i++;
+ if (i = buf_len)
+ return;
+
+ cmd = ir-buf_in[i];/* sub cmd */
+ i++;
+ switch (cmd) {
+ case 0x08:
+ case 0x14:
+ case 0x17:
+ i += 1;
+ break;
+ case 0x11:
+ i += 5;
+ break;
+ case 0x06:
+ case 0x81:
+ case 0x15:
+ case 0x16:
+ i += 2;
+ break;
+ }
+ } else if (cmd == 0x80) {
+ /*
+* Special case: timeout event on cx231xx
+* Is it needed to check if is_polaris?
+*/
+ rawir.pulse = 0;
+ rawir.duration = IR_MAX_DURATION;
+ dev_dbg(ir-dev, Storing %s with duration %d\n,
+ rawir.pulse ? pulse : space,
+ rawir.duration);
+
+ ir_raw_event_store(ir-idev, rawir);
+ } else {
+ ir-rem = (cmd MCE_PACKET_LENGTH_MASK);
+ ir-cmd = (cmd ~MCE_PACKET_LENGTH_MASK);
+ dev_dbg(ir-dev, New data. rem: 0x%02x, cmd: 0x%02x\n,
+ ir-rem, ir-cmd);
+ i++;
+ for (; (ir-rem 0) (i buf_len); i++) {
+ ir-rem--;
+
+ rawir.pulse = ((ir-buf_in[i] MCE_PULSE_BIT)
!= 0);
+ rawir.duration = (ir-buf_in[i]
MCE_PULSE_MASK)
+* MCE_TIME_UNIT * 1000;
+
+ if ((ir-buf_in[i] MCE_PULSE_MASK) == 0x7f) {
+ if (ir-rawir.pulse == rawir.pulse)
+ ir-rawir.duration +=
rawir.duration;
+ else {
+ ir-rawir.duration =
rawir.duration;
+ ir-rawir.pulse = rawir.pulse;
+ }
+ continue;
+ }
+ rawir.duration += ir-rawir.duration;
+ ir-rawir.duration = 0;
+ ir-rawir.pulse = rawir.pulse;
+
+ dev_dbg(ir-dev, Storing %s with duration
%d\n,
+ rawir.pulse ? pulse : space,
+ rawir.duration);
+
+ ir_raw_event_store(ir-idev, rawir);
+ }
+ }
+ }
+ dev_dbg(ir-dev, calling ir_raw_event_handle\n);
+ ir_raw_event_handle(ir-idev);
+}
+
static void mceusb_process_ir_data(struct mceusb_dev *ir, int buf_len)
{
DEFINE_IR_RAW_EVENT(rawir);
@@ -707,6 +792,11 @@ static void mceusb_process_ir_data(struct mceusb_dev *ir,
int buf_len)
if (ir-flags.microsoft_gen1)
start_index = 2;
+ if (ir-flags.is_polaris) {
+ mceusb_parse_polaris(ir, buf_len);
+ return;
+ }
+
for (i = start_index; i
[PATCH 0/4] Some cx231xx IR fixes
This patch series fix the remaining issues with IR for Polaris (cx231xx). Basically, it adds another parser at mceusb, that works better with Polaris. I think that the same parser may also work well for other devices. Mauro Carvalho Chehab (4): [media] cx231xx: Fix compilation breakage if DVB is not selected [media] ir-raw-event: Fix a stupid error at a printk [media] mceusb: Improve parser to get codes sent together with IR RX data [media] mceusb: Fix parser for Polaris drivers/media/IR/ir-raw-event.c |2 +- drivers/media/IR/mceusb.c | 300 +++-- drivers/media/video/cx231xx/cx231xx.h |3 - 3 files changed, 212 insertions(+), 93 deletions(-) -- 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/4] [media] cx231xx: Fix compilation breakage if DVB is not selected
In file included from drivers/media/video/cx231xx/cx231xx-audio.c:40: drivers/media/video/cx231xx/cx231xx.h:559: error: field ‘frontends’ has incomplete type make[4]: ** [drivers/media/video/cx231xx/cx231xx-audio.o] Erro 1 make[3]: ** [drivers/media/video/cx231xx] Erro 2 make[2]: ** [drivers/media/video] Erro 2 make[1]: ** [drivers/media] Erro 2 make: ** [drivers] Erro 2 Reported-by: Marcio Araujo Alves fr...@gmail.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/video/cx231xx/cx231xx.h b/drivers/media/video/cx231xx/cx231xx.h index 9c98886..d067df9 100644 --- a/drivers/media/video/cx231xx/cx231xx.h +++ b/drivers/media/video/cx231xx/cx231xx.h @@ -35,10 +35,7 @@ #include media/videobuf-vmalloc.h #include media/v4l2-device.h #include media/ir-core.h -#if defined(CONFIG_VIDEO_CX231XX_DVB) || \ - defined(CONFIG_VIDEO_CX231XX_DVB_MODULE) #include media/videobuf-dvb.h -#endif #include cx231xx-reg.h #include cx231xx-pcb-cfg.h -- 1.7.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
[PATCH 2/4] [media] ir-raw-event: Fix a stupid error at a printk
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c index 0d59ef7..a06a07e 100644 --- a/drivers/media/IR/ir-raw-event.c +++ b/drivers/media/IR/ir-raw-event.c @@ -89,7 +89,7 @@ int ir_raw_event_store(struct input_dev *input_dev, struct ir_raw_event *ev) if (!ir-raw) return -EINVAL; - IR_dprintk(2, sample: (05%dus %s)\n, + IR_dprintk(2, sample: (%05dus %s)\n, TO_US(ev-duration), TO_STR(ev-pulse)); if (kfifo_in(ir-raw-kfifo, ev, sizeof(*ev)) != sizeof(*ev)) -- 1.7.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/4] [media] ir-raw-event: Fix a stupid error at a printk
On Thu, Oct 21, 2010 at 10:07 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c index 0d59ef7..a06a07e 100644 --- a/drivers/media/IR/ir-raw-event.c +++ b/drivers/media/IR/ir-raw-event.c @@ -89,7 +89,7 @@ int ir_raw_event_store(struct input_dev *input_dev, struct ir_raw_event *ev) if (!ir-raw) return -EINVAL; - IR_dprintk(2, sample: (05%dus %s)\n, + IR_dprintk(2, sample: (%05dus %s)\n, TO_US(ev-duration), TO_STR(ev-pulse)); if (kfifo_in(ir-raw-kfifo, ev, sizeof(*ev)) != sizeof(*ev)) Acked-by: Jarod Wilson ja...@redhat.com -- Jarod Wilson ja...@wilsonet.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
Re: [PATCH 1/4] [media] cx231xx: Fix compilation breakage if DVB is not selected
On Thu, Oct 21, 2010 at 10:07 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: In file included from drivers/media/video/cx231xx/cx231xx-audio.c:40: drivers/media/video/cx231xx/cx231xx.h:559: error: field ‘frontends’ has incomplete type make[4]: ** [drivers/media/video/cx231xx/cx231xx-audio.o] Erro 1 make[3]: ** [drivers/media/video/cx231xx] Erro 2 make[2]: ** [drivers/media/video] Erro 2 make[1]: ** [drivers/media] Erro 2 make: ** [drivers] Erro 2 Reported-by: Marcio Araujo Alves fr...@gmail.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Acked-by: Jarod Wilson ja...@redhat.com -- Jarod Wilson ja...@wilsonet.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
Technisat CableStar HD2 some issues/questions
Hey guys, I recently bought a Technisat CableStar HD2: lspci -s 04:05.0 -vv -n 04:05.0 0480: 1822:4e35 (rev 01) Subsystem: 1ae4:0002 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort+ MAbort- SERR- PERR- INTx- Latency: 64 (2000ns min, 63750ns max) Interrupt: pin A routed to IRQ 20 Region 0: Memory at f6fff000 (32-bit, prefetchable) [size=4K] Kernel driver in use: Mantis So to question one: I read the wiki article[1] to setup my new card and then noticed that the following drivers are enough: CONFIG_MEDIA_SUPPORT CONFIG_VIDEO_DEV CONFIG_DVB_CORE CONFIG_MEDIA_ATTACH CONFIG_MANTIS_CORE CONFIG_DVB_MANTIS CONFIG_DVB_FE_CUSTOMISE CONFIG_DVB_TDA10023 and CONFIG_DVB_PLL (Auto selected) So my question is now, do I really need for some reason the: CONFIG_DVB_TDA10021 and CONFIG_DVB_B2C2_FLEXCOP / CONFIG_DVB_B2C2_FLEXCOP_PCI drivers? The cu1216 isn't available in 2.6.36 so I guess I don't need this one at least.. It seems he uses the same card there but in my case just CONFIG_DVB_TDA10021 seems to not work but I'll test it again later if I get to it. To my second question: I saw two threads [2][3] (unfortunately German only) that I'd have to patch the kernel drivers or I even have to use other[4]/non-kernel[5] driver. Is it still necessary or has it been fixed in any of the 2.6.3x kernels? I didn't test the IR stuff yet so I just ask... The third thing I noticed is: Get such a card (Might be even reproducible without the card) Build the drivers above (at least CONFIG_DVB_TDA10023) as module Boot and you'll get something like here: [ 161.383486] BUG: unable to handle kernel NULL pointer dereference at 0308 [ 161.384004] IP: [8131a7ce] dvb_unregister_frontend+0xe/0x100 [ 161.384004] PGD 9f731067 PUD a051a067 PMD 0 [ 161.384004] Oops: [#1] SMP [ 161.384004] last sysfs file: /sys/devices/pci:00/:00:11.0/host1/target1:0:0/1:0:0:0/block/sdb/uevent [ 161.384004] CPU 3 [ 161.384004] Modules linked in: mantis(+) nvidia(P) k10temp asus_atk0110 hwmon pata_atiixp [ 161.384004] [ 161.384004] Pid: 4992, comm: modprobe Tainted: P 2.6.36-gentoo #9 M4A79XTD EVO/System Product Name [ 161.384004] RIP: 0010:[8131a7ce] [8131a7ce] dvb_unregister_frontend+0xe/0x100 [ 161.384004] RSP: 0018:88009ff77c38 EFLAGS: 00010282 [ 161.384004] RAX: 0023 RBX: 8800ab127000 RCX: 88012fccf1c0 [ 161.384004] RDX: 0022 RSI: 0009 RDI: [ 161.384004] RBP: 88009ff77c78 R08: R09: 0001 [ 161.384004] R10: 816ecaee R11: 0001 R12: [ 161.384004] R13: R14: 8800ab127450 R15: 8800ab127740 [ 161.384004] FS: 7f4d1092d700() GS:880001b8() knlGS: [ 161.384004] CS: 0010 DS: ES: CR0: 8005003b [ 161.384004] CR2: 0308 CR3: 9f73e000 CR4: 06e0 [ 161.384004] DR0: DR1: DR2: [ 161.384004] DR3: DR6: 0ff0 DR7: 0400 [ 161.498034] Process modprobe (pid: 4992, threadinfo 88009ff76000, task 88012c358690) [ 161.498034] Stack: [ 161.498034] 88012c358690 88012b6c [ 161.498034] 0 88009ff77c78 8800ab127000 8800ab127000 8800ab1273c0 [ 161.498034] 0 88009ff77ce8 8142e865 88009ff77ce8 8800ab127818 [ 161.498034] Call Trace: [ 161.498034] [8142e865] mantis_dvb_init+0x3a6/0x3fb [ 161.498034] [a000a3dd] mantis_pci_probe+0x192/0x2a0 [mantis] [ 161.498034] [811dcb7a] local_pci_probe+0x5a/0xd0 [ 161.498034] [811dcfe0] pci_device_probe+0x80/0xb0 [ 161.498034] [8125e15a] ? driver_sysfs_add+0x7a/0xb0 [ 161.498034] [8125e29e] driver_probe_device+0x8e/0x1b0 [ 161.498034] [8125e453] __driver_attach+0x93/0xa0 [ 161.498034] [8125e3c0] ? __driver_attach+0x0/0xa0 [ 161.498034] [8125d97c] bus_for_each_dev+0x5c/0x90 [ 161.498034] [8125e0d9] driver_attach+0x19/0x20 [ 161.498034] [8125d298] bus_add_driver+0x1c8/0x250 [ 161.498034] [a000a4eb] ? mantis_init+0x0/0x20 [mantis] [ 161.498034] [8125e758] driver_register+0x78/0x140 [ 161.498034] [a000a4eb] ? mantis_init+0x0/0x20 [mantis] [ 161.498034] [811dd251] __pci_register_driver+0x51/0xd0 [ 161.498034] [a000a509] mantis_init+0x1e/0x20 [mantis] [ 161.498034] [810001de] do_one_initcall+0x3e/0x180 [ 161.498034] [81073cb2] sys_init_module+0xb2/0x200 [ 161.498034] [81002d82] system_call_fastpath+0x16/0x1b [ 161.498034] Code: 00 eb 84 48 c7 c7 30 5d 70 81 31 c0 e8 da 65 11 00 eb d2 66 2e 0f 1f 84 00 00 00
Re: [PATCH 1/2] ov7670: allow configuration of image size, clock speed, and I/O method
On Tue, 19 Oct 2010 22:24:05 +0100 (BST) Daniel Drake d...@laptop.org wrote: These parameters need to be configurable based on the host system. They can now be communicated through the s_config call. The old CONFIG_OLPC_XO_1 selector was not correct; this kind of arrangement wouldn't allow for a universal kernel that would work on both laptops. Certain parts of the probe routine had to be moved later (into s_config), because we can't do any I/O until we know which I/O method has been selected through this mechanism. OK, I've had a look at this. I'm OK with it to go in as it is, but, for the record, I'll note that I would have done it a bit differently. There are three different things (minimum size, clock speed, I/O method) being dealt with here; it might have been nice to separate them out. Yes, they're all part of the s_config() call, I know... I dislike deferring the probe of the sensor, it strikes me as something that could create timing problems. Maybe I'm overly nervous about this and it's not really a problem. My biggest issue, though, is this: SMBUS I/O is actually never the right thing to do with the ov7670. This isn't something I knew when I wrote the Cafe driver (suffice to say the ov7670 seems to hold more than its share of mysteries and surprises). What I *should* have done - and what should be done now - is to forget the built-in Cafe SMBUS mode and do a straight bit-banging i2c driver. As I recall, the Cafe controller does provide that level of access for those who want it. That's a bigger fix, of course. I have it on my list, but my list is, well, you know. So I won't try to hold up this patch, which works around my initial screwup, on the promise of a proper fix one of these days. Sometime when I have a few hours I will take a crack at it, though. Thanks, jon -- 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/4] [media] mceusb: Improve parser to get codes sent together with IR RX data
On Oct 21, 2010, at 10:07 AM, Mauro Carvalho Chehab wrote: On cx231xx, sometimes, several control messages are sent together with data. Improves the parser to also handle those cases. For example: [38777.211690] mceusb 7-6:1.0: rx data: 9f 14 01 9f 15 00 00 80 (length=8) [38777.211696] mceusb 7-6:1.0: Got long-range receive sensor in use [38777.211700] mceusb 7-6:1.0: Received pulse count is 0 [38777.211703] mceusb 7-6:1.0: IR data len = 0 [38777.211707] mceusb 7-6:1.0: New data. rem: 0x1f, cmd: 0x80 Before this patch, only the first message would be displayed, as the parser would be stopping at 9f 14 01. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com So two minor issues with this patch... First, the debug spew looks slightly confusing, though through no fault of yours, really. Now that you're parsing all three chunks of that final sequence, you see a New data. message that actually comes from the first chunk of the three, but after you've already seen the other three. We should probably just drop that dev_dbg and rely on the 'IR data len' one. The second issue is the very last hunk of the patch that moves the call to ir_raw_event_handle, which should be unrelated to the rest of this patch (and may, iirc, cause issues for the first-gen transceiver -- I'd have to re-test to be sure). But otherwise, looks good to me. diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c index a726f63..609bf3d 100644 --- a/drivers/media/IR/mceusb.c +++ b/drivers/media/IR/mceusb.c ... @@ -724,9 +755,9 @@ static void mceusb_process_ir_data(struct mceusb_dev *ir, int buf_len) if (ir-buf_in[i] == 0x80 || ir-buf_in[i] == 0x9f) ir-rem = 0; - dev_dbg(ir-dev, calling ir_raw_event_handle\n); - ir_raw_event_handle(ir-idev); } + dev_dbg(ir-dev, calling ir_raw_event_handle\n); + ir_raw_event_handle(ir-idev); } static void mceusb_dev_recv(struct urb *urb, struct pt_regs *regs) ^^^ the unrelated hunk. -- Jarod Wilson ja...@wilsonet.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
[cron job] v4l-dvb daily build 2.6.26 and up: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Oct 21 19:00:22 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15167:abd3aac6644e git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: a348e9110ddb5d494e060d989b35dd1f35359d58 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.32.6-armv5: WARNINGS linux-2.6.33-armv5: WARNINGS linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: ERRORS linux-2.6.34-armv5-davinci: ERRORS linux-2.6.35.3-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: ERRORS linux-2.6.34-armv5-ixp: ERRORS linux-2.6.35.3-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: ERRORS linux-2.6.34-armv5-omap2: ERRORS linux-2.6.35.3-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: WARNINGS linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification 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
[patch] V4L/DVB: cx231xx: fix double lock typo
This was supposed to be an unlock on the error path.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/cx231xx/cx231xx-i2c.c
b/drivers/media/video/cx231xx/cx231xx-i2c.c
index cce74e5..8356706 100644
--- a/drivers/media/video/cx231xx/cx231xx-i2c.c
+++ b/drivers/media/video/cx231xx/cx231xx-i2c.c
@@ -372,7 +372,7 @@ static int cx231xx_i2c_xfer(struct i2c_adapter *i2c_adap,
rc = cx231xx_i2c_check_for_device(i2c_adap, msgs[i]);
if (rc 0) {
dprintk2(2, no device\n);
- mutex_lock(dev-i2c_lock);
+ mutex_unlock(dev-i2c_lock);
return rc;
}
--
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] V4L/DVB: s5p-fimc: add unlock on error path
There was an unlock missing if kzalloc() failed.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 1802701..8335045 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -1326,16 +1326,18 @@ static int fimc_m2m_open(struct file *file)
* is already opened.
*/
if (fimc-vid_cap.refcnt 0) {
- mutex_unlock(fimc-lock);
- return -EBUSY;
+ err = -EBUSY;
+ goto err_unlock;
}
fimc-m2m.refcnt++;
set_bit(ST_OUTDMA_RUN, fimc-state);
ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
- if (!ctx)
- return -ENOMEM;
+ if (!ctx) {
+ err = -ENOMEM;
+ goto err_unlock;
+ }
file-private_data = ctx;
ctx-fimc_dev = fimc;
@@ -1355,6 +1357,7 @@ static int fimc_m2m_open(struct file *file)
kfree(ctx);
}
+err_unlock:
mutex_unlock(fimc-lock);
return err;
}
--
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 3/3] V4L/DVB: s5p-fimc: dubious one-bit signed bitfields
These are signed so instead of being 1 and 0 as intended they are -1 and
0. It doesn't cause a bug in the current code but Sparse warns about it:
drivers/media/video/s5p-fimc/fimc-core.h:226:28:
error: dubious one-bit signed bitfield
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index e3a7c6a..7665a3f 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -222,10 +223,10 @@ struct fimc_effect {
* @real_height: source pixel (height - offset)
*/
struct fimc_scaler {
- int scaleup_h:1;
- int scaleup_v:1;
- int copy_mode:1;
- int enabled:1;
+ unsigned intscaleup_h:1;
+ unsigned intcaleup_v:1;
+ unsigned intcopy_mode:1;
+ unsigned intenabled:1;
u32 hfactor;
u32 vfactor;
u32 pre_hratio;
--
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] V4L/DVB: s5p-fimc: make it compile
The work_queue was partially removed in f93000ac11: [media] s5p-fimc:
mem2mem driver refactoring and cleanup but this bit was missed. Also
we need to include sched.h otherwise the compile fails with:
drivers/media/video/s5p-fimc/fimc-core.c:
In function ‘fimc_capture_handler’:
drivers/media/video/s5p-fimc/fimc-core.c:286:
error: ‘TASK_NORMAL’ undeclared (first use in this function)
Signed-off-by: Dan Carpenter erro...@gmail.com
---
Compile tested only. :P
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index e3a7c6a..1c1437c 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -14,6 +14,7 @@
/*#define DEBUG*/
#include linux/types.h
+#include linux/sched.h
#include media/videobuf-core.h
#include media/v4l2-device.h
#include media/v4l2-mem2mem.h
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 8335045..cf9bc8e 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -1593,12 +1593,6 @@ static int fimc_probe(struct platform_device *pdev)
goto err_clk;
}
- fimc-work_queue = create_workqueue(dev_name(fimc-pdev-dev));
- if (!fimc-work_queue) {
- ret = -ENOMEM;
- goto err_irq;
- }
-
ret = fimc_register_m2m_device(fimc);
if (ret)
goto err_irq;
--
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 4/4] [media] mceusb: Fix parser for Polaris
On Oct 21, 2010, at 10:07 AM, Mauro Carvalho Chehab wrote:
Add a parser for polaris mce. On this device, sometimes, a control
data appears together with the IR data, causing problems at the parser.
Also, it signalizes the end of a data with a 0x80 value. The normal
parser would believe that this is a time with 0x1f size, but cx231xx
provides just one byte for it.
I'm not sure if the new parser would work for other devices (probably, it
will), but the better is to just write it as a new parser, to avoid breaking
support for other supported IR devices.
After staring at it for a while, I think it would work okay for all 2nd and
3rd-gen mceusb devices, but it would almost certainly break 1st-gen, as it can
have distinct IR data packets split across urb -- that's the whole reason for
the if rem == 0 check in the existing routine.
Ultimately though, this routine isn't that much different, and I *think* I see
a way to extend the existing routine with some of the code from this one to
make it work better for the polaris device.
Will still go ahead with some review comments here though.
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index 609bf3d..7210760 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -265,6 +265,7 @@ struct mceusb_dev {
u32 connected:1;
u32 tx_mask_inverted:1;
u32 microsoft_gen1:1;
+ u32 is_polaris:1;
u32 reserved:29;
reserved should be decremented by 1 here if adding another flag.
} flags;
@@ -697,6 +698,90 @@ static int mceusb_set_tx_carrier(void *priv, u32 carrier)
return carrier;
}
+static void mceusb_parse_polaris(struct mceusb_dev *ir, int buf_len)
+{
+ struct ir_raw_event rawir;
+ int i;
+ u8 cmd;
+
+ while (i buf_len) {
i is being used uninitialized here.
+ cmd = ir-buf_in[i];
+
+ /* Discard any non-IR cmd */
+
+ if ((cmd 0xe0) 5 != 4) {
I'd probably just stick with if ((cmd 0xe0) != 0x80), or even !=
MCE_PULSE_BIT, since we have a #define for 0x80 already. (Though its not quite
an accurate name in this case).
+ i++;
+ if (i = buf_len)
+ return;
+
+ cmd = ir-buf_in[i];/* sub cmd */
+ i++;
+ switch (cmd) {
+ case 0x08:
+ case 0x14:
+ case 0x17:
+ i += 1;
+ break;
+ case 0x11:
+ i += 5;
+ break;
+ case 0x06:
+ case 0x81:
+ case 0x15:
+ case 0x16:
+ i += 2;
+ break;
#define's for each of these hex values would be good, if we can determine what
they actually are.
+ } else if (cmd == 0x80) {
+ /*
+ * Special case: timeout event on cx231xx
+ * Is it needed to check if is_polaris?
+ */
+ rawir.pulse = 0;
+ rawir.duration = IR_MAX_DURATION;
+ dev_dbg(ir-dev, Storing %s with duration %d\n,
+ rawir.pulse ? pulse : space,
+ rawir.duration);
+
+ ir_raw_event_store(ir-idev, rawir);
I think this and the prior hunk are really the only things that need to be
grafted into the existing routine to make it behave with this device. Lemme see
what I can come up with...
--
Jarod Wilson
ja...@wilsonet.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
Re: [PATCH 4/4] [media] mceusb: Fix parser for Polaris
Em 21-10-2010 18:06, Jarod Wilson escreveu:
On Oct 21, 2010, at 10:07 AM, Mauro Carvalho Chehab wrote:
Add a parser for polaris mce. On this device, sometimes, a control
data appears together with the IR data, causing problems at the parser.
Also, it signalizes the end of a data with a 0x80 value. The normal
parser would believe that this is a time with 0x1f size, but cx231xx
provides just one byte for it.
I'm not sure if the new parser would work for other devices (probably, it
will), but the better is to just write it as a new parser, to avoid breaking
support for other supported IR devices.
After staring at it for a while, I think it would work okay for all 2nd and
3rd-gen mceusb devices, but it would almost certainly break 1st-gen, as it
can have distinct IR data packets split across urb -- that's the whole reason
for the if rem == 0 check in the existing routine.
Ultimately though, this routine isn't that much different, and I *think* I
see a way to extend the existing routine with some of the code from this one
to make it work better for the polaris device.
Will still go ahead with some review comments here though.
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index 609bf3d..7210760 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -265,6 +265,7 @@ struct mceusb_dev {
u32 connected:1;
u32 tx_mask_inverted:1;
u32 microsoft_gen1:1;
+u32 is_polaris:1;
u32 reserved:29;
reserved should be decremented by 1 here if adding another flag.
Ok. By curiosity, why are you reserving space on a bit array like that?
} flags;
@@ -697,6 +698,90 @@ static int mceusb_set_tx_carrier(void *priv, u32
carrier)
return carrier;
}
+static void mceusb_parse_polaris(struct mceusb_dev *ir, int buf_len)
+{
+struct ir_raw_event rawir;
+int i;
+u8 cmd;
+
+while (i buf_len) {
i is being used uninitialized here.
Ops!
+cmd = ir-buf_in[i];
+
+/* Discard any non-IR cmd */
+
+if ((cmd 0xe0) 5 != 4) {
I'd probably just stick with if ((cmd 0xe0) != 0x80), or even !=
MCE_PULSE_BIT, since we have a #define for 0x80 already. (Though its not
quite an accurate name in this case).
Ok.
+i++;
+if (i = buf_len)
+return;
+
+cmd = ir-buf_in[i];/* sub cmd */
+i++;
+switch (cmd) {
+case 0x08:
+case 0x14:
+case 0x17:
+i += 1;
+break;
+case 0x11:
+i += 5;
+break;
+case 0x06:
+case 0x81:
+case 0x15:
+case 0x16:
+i += 2;
+break;
#define's for each of these hex values would be good, if we can determine
what they actually are.
Maybe we can determine a few of them, as they also occur at the debug parsing
loop.
+} else if (cmd == 0x80) {
+/*
+ * Special case: timeout event on cx231xx
+ * Is it needed to check if is_polaris?
+ */
+rawir.pulse = 0;
+rawir.duration = IR_MAX_DURATION;
+dev_dbg(ir-dev, Storing %s with duration %d\n,
+rawir.pulse ? pulse : space,
+rawir.duration);
+
+ir_raw_event_store(ir-idev, rawir);
I think this and the prior hunk are really the only things that need to be
grafted into the existing routine to make it behave with this device. Lemme
see what I can come up with...
True, although the double loop at the original logic is a bit confusing. I
suspect you did it to handle
the (cmd 0xe0) != 0x80 condition, probably at the gen1 times, and then you
modified it to handle other
devices.
Cheers,
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
Re: [PATCH 4/4] [media] mceusb: Fix parser for Polaris
On Oct 21, 2010, at 4:38 PM, Mauro Carvalho Chehab wrote:
Em 21-10-2010 18:06, Jarod Wilson escreveu:
On Oct 21, 2010, at 10:07 AM, Mauro Carvalho Chehab wrote:
Add a parser for polaris mce. On this device, sometimes, a control
data appears together with the IR data, causing problems at the parser.
Also, it signalizes the end of a data with a 0x80 value. The normal
parser would believe that this is a time with 0x1f size, but cx231xx
provides just one byte for it.
I'm not sure if the new parser would work for other devices (probably, it
will), but the better is to just write it as a new parser, to avoid breaking
support for other supported IR devices.
After staring at it for a while, I think it would work okay for all 2nd and
3rd-gen mceusb devices, but it would almost certainly break 1st-gen, as it
can have distinct IR data packets split across urb -- that's the whole
reason for the if rem == 0 check in the existing routine.
Ultimately though, this routine isn't that much different, and I *think* I
see a way to extend the existing routine with some of the code from this one
to make it work better for the polaris device.
Will still go ahead with some review comments here though.
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index 609bf3d..7210760 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -265,6 +265,7 @@ struct mceusb_dev {
u32 connected:1;
u32 tx_mask_inverted:1;
u32 microsoft_gen1:1;
+ u32 is_polaris:1;
u32 reserved:29;
reserved should be decremented by 1 here if adding another flag.
Ok. By curiosity, why are you reserving space on a bit array like that?
Legacy, mostly, I guess. Its been that way going back ages. I suppose we could
just convert them all to bools and/or leave them as is and drop the reserved
part entirely...
+ i++;
+ if (i = buf_len)
+ return;
+
+ cmd = ir-buf_in[i];/* sub cmd */
+ i++;
+ switch (cmd) {
+ case 0x08:
+ case 0x14:
+ case 0x17:
+ i += 1;
+ break;
+ case 0x11:
+ i += 5;
+ break;
+ case 0x06:
+ case 0x81:
+ case 0x15:
+ case 0x16:
+ i += 2;
+ break;
#define's for each of these hex values would be good, if we can determine
what they actually are.
Maybe we can determine a few of them, as they also occur at the debug parsing
loop.
Yeah, a few of them are at least reasonably well understood.
+ } else if (cmd == 0x80) {
+ /*
+* Special case: timeout event on cx231xx
+* Is it needed to check if is_polaris?
+*/
+ rawir.pulse = 0;
+ rawir.duration = IR_MAX_DURATION;
+ dev_dbg(ir-dev, Storing %s with duration %d\n,
+ rawir.pulse ? pulse : space,
+ rawir.duration);
+
+ ir_raw_event_store(ir-idev, rawir);
I think this and the prior hunk are really the only things that need to be
grafted into the existing routine to make it behave with this device. Lemme
see what I can come up with...
True, although the double loop at the original logic is a bit confusing. I
suspect you did it to handle
the (cmd 0xe0) != 0x80 condition, probably at the gen1 times, and then you
modified it to handle other devices.
Yeah, this sorta grew from merging the old lirc_mceusb and lirc_mceusb2 drivers
into one, and believe it or not, its actually cleaner than it used to be... :)
You've got a test patch in your inbox that attempts to merge the logic in this
patch into the existing loop, and I'll see if I can beat on it with all three
generations of stand-alone mceusb devices tonight...
--
Jarod Wilson
ja...@wilsonet.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
Re: [PATCH 4/4] [media] mceusb: Fix parser for Polaris
Em 21-10-2010 19:06, Jarod Wilson escreveu:
On Oct 21, 2010, at 4:38 PM, Mauro Carvalho Chehab wrote:
Em 21-10-2010 18:06, Jarod Wilson escreveu:
@@ -265,6 +265,7 @@ struct mceusb_dev {
u32 connected:1;
u32 tx_mask_inverted:1;
u32 microsoft_gen1:1;
+ u32 is_polaris:1;
u32 reserved:29;
reserved should be decremented by 1 here if adding another flag.
Ok. By curiosity, why are you reserving space on a bit array like that?
Legacy, mostly, I guess. Its been that way going back ages. I suppose we
could just convert them all to bools and/or leave them as is and drop the
reserved part entirely...
Agreed. If this is not part of any kabi (and it isn't, as far as I see), we can
just
drop the reserved, as gcc will pad it accordingly.
Yeah, this sorta grew from merging the old lirc_mceusb and lirc_mceusb2
drivers into one, and believe it or not, its actually cleaner than it used to
be... :)
You've got a test patch in your inbox that attempts to merge the logic in
this patch into the existing loop, and I'll see if I can beat on it with all
three generations of stand-alone mceusb devices tonight...
I'll do some tests and send you a feedback.
Cheers,
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
Wintv-HVR-1120 woes
I'm having all sorts of troubles with Wintv-HVR-1120 on Ubuntu 10.10 (kernel 2.6.35-22). Judging from what I've seen on the net, including this mailing list, I'm not the only one not being able to use this card and no solution seem to exist. Problems: 1. The driver yells various cryptic error messages (tda18271_write_regs: [1-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5, tda18271_set_analog_params: [1-0060|M] error -5 on line 1045, etc) 2. DVB-T scan (using w_scan) produces no results 3. Analog seems to work, but with very poor quality Any suggestions would be greatly appreciated. -- 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
Wintv-HVR-1120 woes
I'm having all sorts of troubles with Wintv-HVR-1120 on Ubuntu 10.10 (kernel 2.6.35-22). Judging from what I've seen on the net, including this mailing list, I'm not the only one not being able to use this card and no solution seem to exist. Problems: 1. The driver yells various cryptic error messages (tda18271_write_regs: [1-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5, tda18271_set_analog_params: [1-0060|M] error -5 on line 1045, etc) 2. DVB-T scan (using w_scan) produces no results 3. Analog seems to work, but with very poor quality Any suggestions would be greatly appreciated. -- 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 0/3] Remaining patches in my queue for IR
On Wed, 2010-10-20 at 14:40 -0400, Jarod Wilson wrote: On Sun, Oct 17, 2010 at 12:56:27AM +0200, Maxim Levitsky wrote: Hi, This series is rebased on top of media_tree/staging/v2.6.37 only. Really this time, sorry for cheating, last time :-) The first patch like we agreed extends the raw packets. It touches all drivers (except imon as it isn't a raw IR driver). Code is compile tested with all drivers, and run tested with ENE and all receiver protocols (except the streamzap rc5 flavour) Since it also moves timeouts to lirc bridge, at least streazap driver should have its timeout gap support removed. I am afraid to break the code if I do so. I've tested both mceusb and streamzap with this patchset included, don't see any ill side-effects. Only issue I really saw was that the raw event init call was added somewhat superfluously to a number of drivers -- the rawir struct its initializing was already kzalloc'd, so we're just needlessly re-zero'ing it out again. Its not bad for clarity's sake, but does add some unnecessary inefficiency. Yes, I somewhat agree. On the other hand, I had an idea to add a magic field to ir_raw_event to guard against uninitialized uses. (something like the struct scatterlist). Don't know it that is worth it. Or that I sound like a typical supporter of OOP style of abstracting everything because sometime at the future there will be need to change it.. Anyway, as Andy pointed, note that few drivers became broken due to that patch because these don't initialize the ir_raw_event. I will send a patch tomorrow (I was very busy this week). Best regards, Maxim Levitsky -- 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
