Re: [PATCH v4 3/6] drivers:staging: ti-st: fmdrv_common sources
On Tuesday, November 16, 2010 14:18:11 manjunatha_ha...@ti.com wrote:
From: Manjunatha Halli manjunatha_ha...@ti.com
These are the sources for the common interfaces required by the FM
V4L2 driver for TI WL127x and WL128x chips.
These implement the FM channel-8 protocol communication with
the chip. This makes use of the Shared Transport as its transport.
Signed-off-by: Manjunatha Halli manjunatha_ha...@ti.com
---
drivers/staging/ti-st/fmdrv_common.c | 2141
++
drivers/staging/ti-st/fmdrv_common.h | 458
2 files changed, 2599 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/ti-st/fmdrv_common.c
create mode 100644 drivers/staging/ti-st/fmdrv_common.h
diff --git a/drivers/staging/ti-st/fmdrv_common.c
b/drivers/staging/ti-st/fmdrv_common.c
new file mode 100644
index 000..7b8f2da
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv_common.c
@@ -0,0 +1,2141 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ *
+ * This sub-module of FM driver is common for FM RX and TX
+ * functionality. This module is responsible for:
+ * 1) Forming group of Channel-8 commands to perform particular
+ * functionality (eg., frequency set require more than
+ * one Channel-8 command to be sent to the chip).
+ * 2) Sending each Channel-8 command to the chip and reading
+ * response back over Shared Transport.
+ * 3) Managing TX and RX Queues and Tasklets.
+ * 4) Handling FM Interrupt packet and taking appropriate action.
+ * 5) Loading FM firmware to the chip (common, FM TX, and FM RX
+ * firmware files based on mode selection)
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Raja Mani raja_m...@ti.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.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/firmware.h
+#include linux/delay.h
+#include fmdrv.h
+#include fmdrv_v4l2.h
+#include fmdrv_common.h
+#include linux/ti_wilink_st.h
+#include fmdrv_rx.h
+#include fmdrv_tx.h
+
+/* FM chip register table */
+static struct fm_reg_table fm_reg_info[] = {
+ /* - FM RX registers ---*/
+ /* opcode, type(rd/wr), reg name */
+ {0x00, REG_RD, STEREO_GET},
+ {0x01, REG_RD, RSSI_LVL_GET},
+ {0x02, REG_RD, IF_COUNT_GET},
+ {0x03, REG_RD, FLAG_GET},
+ {0x04, REG_RD, RDS_SYNC_GET},
+ {0x05, REG_RD, RDS_DATA_GET},
+ {0x0a, REG_WR, FREQ_SET},
+ {0x0a, REG_RD, FREQ_GET},
+ {0x0b, REG_WR, AF_FREQ_SET},
+ {0x0b, REG_RD, AF_FREQ_GET},
+ {0x0c, REG_WR, MOST_MODE_SET},
+ {0x0c, REG_RD, MOST_MODE_GET},
+ {0x0d, REG_WR, MOST_BLEND_SET},
+ {0x0d, REG_RD, MOST_BLEND_GET},
+ {0x0e, REG_WR, DEMPH_MODE_SET},
+ {0x0e, REG_RD, DEMPH_MODE_GET},
+ {0x0f, REG_WR, SEARCH_LVL_SET},
+ {0x0f, REG_RD, SEARCH_LVL_GET},
+ {0x10, REG_WR, RX_BAND_SET},
+ {0x10, REG_RD, RX_BAND_GET},
+ {0x11, REG_WR, MUTE_STATUS_SET},
+ {0x11, REG_RD, MUTE_STATUS_GET},
+ {0x12, REG_WR, RDS_PAUSE_LVL_SET},
+ {0x12, REG_RD, RDS_PAUSE_LVL_GET},
+ {0x13, REG_WR, RDS_PAUSE_DUR_SET},
+ {0x13, REG_RD, RDS_PAUSE_DUR_GET},
+ {0x14, REG_WR, RDS_MEM_SET},
+ {0x14, REG_RD, RDS_MEM_GET},
+ {0x15, REG_WR, RDS_BLK_B_SET},
+ {0x15, REG_RD, RDS_BLK_B_GET},
+ {0x16, REG_WR, RDS_MSK_B_SET},
+ {0x16, REG_RD, RDS_MSK_B_GET},
+ {0x17, REG_WR, RDS_PI_MASK_SET},
+ {0x17, REG_RD, RDS_PI_MASK_GET},
+ {0x18, REG_WR, RDS_PI_SET},
+ {0x18, REG_RD, RDS_PI_GET},
+ {0x19, REG_WR, RDS_SYSTEM_SET},
+ {0x19, REG_RD, RDS_SYSTEM_GET},
+ {0x1a, REG_WR, INT_MASK_SET},
+ {0x1a, REG_RD, INT_MASK_GET},
+ {0x1b, REG_WR, SRCH_DIR_SET},
+ {0x1b, REG_RD, SRCH_DIR_GET},
+ {0x1c, REG_WR, VOLUME_SET},
+ {0x1c, REG_RD, VOLUME_GET},
+ {0x1d, REG_WR, AUDIO_ENABLE(SET)},
+ {0x1d, REG_RD, AUDIO_ENABLE(GET)},
+ {0x1e, REG_WR, PCM_MODE_SET},
+ {0x1e, REG_RD, PCM_MODE_SET},
+ {0x1f, REG_WR, I2S_MD_CFG_SET},
+ {0x1f, REG_RD, I2S_MD_CFG_GET},
+ {0x20, REG_WR, POWER_SET},
+ {0x20, REG_RD, POWER_GET},
+ {0x21, REG_WR, INTx_CONFIG_SET},
+ {0x21, REG_RD, INTx_CONFIG_GET},
+ {0x22, REG_WR, PULL_EN_SET},
+ {0x22, REG_RD, PULL_EN_GET},
+ {0x23, REG_WR, HILO_SET},
+
Re: [linux-dvb] cx23885 crashes with TeVii S470
My issue was that the only PCIe 1X slot shared an IRQ with the onboard Sound card and that caused all kinds of problems. Also I had to power off my machine if I ever had problems with the DVB cards. They would not function properly after a warm reboot. Good luck with the issues, my system is not entirely stable as well. Hans - Oorspronkelijk bericht - Van: Frank Wohlfahrt frank-i...@gmx.de Aan: linux-...@linuxtv.org Verzonden: Donderdag 18 november 2010 08:33:32 Onderwerp: [linux-dvb] cx23885 crashes with TeVii S470 I have a TeVii S470 installed on the only PCIe slot of my MSI H55M-ED55. The driver crashes about 50% already immediately after booting, but also some time afterwards, working properly until then. [ 190.764711] ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)... [ 190.764722] cx23885 :02:00.0: firmware: requesting dvb-fe-ds3000.fw [ 190.767173] ds3000_firmware_ondemand: Waiting for firmware upload(2)... [ 193.151417] cx23885[0]: mpeg risc op code error [ 193.151427] cx23885[0]: TS1 B - dma channel status dump [ 193.151434] cx23885[0]: cmds: init risc lo : 0x2390e000 [ 193.151440] cx23885[0]: cmds: init risc hi : 0x [ 193.151446] cx23885[0]: cmds: cdt base : 0x00010580 [ 193.151451] cx23885[0]: cmds: cdt size : 0x000a [ 193.151456] cx23885[0]: cmds: iq base: 0x00010400 [ 193.151462] cx23885[0]: cmds: iq size: 0x0010 [ 193.151468] cx23885[0]: cmds: risc pc lo : 0x2390e1cc [ 193.151473] cx23885[0]: cmds: risc pc hi : 0x [ 193.151478] cx23885[0]: cmds: iq wr ptr : 0x4103 ... The related source module is (I think): cx23885-core.c Only yesterday I had the error during shutdown (preventing the system to switch off): [ 5021.188012] cx23885 :02:00.0: PCI INT A disabled [ 5021.211443] saa7146: unregister extension 'dvb'. [ 5021.243256] BUG: unable to handle kernel NULL pointer dereference at (null) [ 5021.243262] IP: [ef9824ce] v4l2_device_unregister+0x1e/0x50 [videodev] [ 5021.243272] *pde = 76190067 [ 5021.243274] Oops: [#1] SMP [ 5021.243277] last sysfs file: /sys/devices/pci:00/:00:1c.3/:02:00.0/firmware/:02:00.0/loading I don't know if this failure has something to do with the problem above. The software I use is Ubuntu Lucid (Kernel 2.6.32-25-generic) coming with the VDR distribution yavdr 0.3. The firmware for the card is from packet linux-firmware-yavdr Version: 1.1-3yavdr1 -rw-r--r-- 1 root root8192 2010-07-18 21:54 dvb-fe-ds3000.fw I get the same problems using the original kernel module from 2.6.32 or the DKMS modules from v4l-dvb-dkms (0~20101018.15139) or s2-liplianin-dkms (0~20101016.14629). I think I have a hardware problem and I just have to know wether it can be fixed with maybe BIOS settings or if I have to get a different DVB-S2 card. What is the reason for a mpeg risc op code error ? Thanks in advance !! TeVii S470: 02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02) Rest of the system: Intel Core i3 530,+ Hauppauge Nexus-s 2.2 (PCI slot) cx23885 117401 6 cx2341x12404 1 cx23885 v4l2_common16390 2 cx23885,cx2341x videodev 36345 3 saa7146_vv,cx23885,v4l2_common v4l1_compat13251 1 videodev videobuf_dma_sg10782 2 saa7146_vv,cx23885 videobuf_dvb5096 1 cx23885 Frank Wohlfahrt ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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 v4 4/6] drivers:staging: ti-st: fmdrv_rx sources
On Tuesday, November 16, 2010 14:18:12 manjunatha_ha...@ti.com wrote:
From: Manjunatha Halli manjunatha_ha...@ti.com
This has implementation for FM RX functionality.
It communicates with FM V4l2 module and FM common module.
Signed-off-by: Manjunatha Halli manjunatha_ha...@ti.com
---
drivers/staging/ti-st/fmdrv_rx.c | 979
++
drivers/staging/ti-st/fmdrv_rx.h | 59 +++
2 files changed, 1038 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/ti-st/fmdrv_rx.c
create mode 100644 drivers/staging/ti-st/fmdrv_rx.h
diff --git a/drivers/staging/ti-st/fmdrv_rx.c
b/drivers/staging/ti-st/fmdrv_rx.c
new file mode 100644
index 000..5f802da
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv_rx.c
@@ -0,0 +1,979 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ * This sub-module of FM driver implements FM RX functionality.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Raja Mani raja_m...@ti.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.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include fmdrv.h
+#include fmdrv_common.h
+#include fmdrv_rx.h
+
+void fm_rx_reset_rds_cache(struct fmdrv_ops *fmdev)
+{
+ fmdev-rx.rds.flag = FM_RDS_DISABLE;
+ fmdev-rx.rds.last_block_index = 0;
+ fmdev-rx.rds.wr_index = 0;
+ fmdev-rx.rds.rd_index = 0;
+
+ if (fmdev-rx.af_mode == FM_RX_RDS_AF_SWITCH_MODE_ON)
+ fmdev-irq_info.mask |= FM_LEV_EVENT;
+}
+
+void fm_rx_reset_curr_station_info(struct fmdrv_ops *fmdev)
+{
+ fmdev-rx.cur_station_info.picode = FM_NO_PI_CODE;
+ fmdev-rx.cur_station_info.no_of_items_in_afcache = 0;
+ fmdev-rx.cur_station_info.af_list_max = 0;
+}
+
+int fm_rx_set_frequency(struct fmdrv_ops *fmdev, unsigned int freq_to_set)
+{
+ unsigned long timeleft;
+ unsigned short payload, curr_frq, frq_index;
+ unsigned int curr_frq_in_khz;
+ int ret, resp_len;
+
+ if (fmdev-curr_fmmode != FM_MODE_RX)
+ return -EPERM;
+
+ if (freq_to_set fmdev-rx.region.bottom_frequency ||
+ freq_to_set fmdev-rx.region.top_frequency) {
+ pr_err((fmdrv): Invalid frequency %d\n, freq_to_set);
+ return -EINVAL;
+ }
+
+ /* Set audio enable */
+ FM_STORE_LE16_TO_BE16(payload, FM_RX_FM_AUDIO_ENABLE_I2S_AND_ANALOG);
Why do this? You should use the cpu_to_be16 function instead. This code makes
the incorrect assumption that this will always run on a little-endian machine.
That's not necessarily true. The kernel macros do the right thing.
+ ret = fmc_send_cmd(fmdev, AUDIO_ENABLE_SET, payload, sizeof(payload),
+ fmdev-maintask_completion, NULL, NULL);
Actually, shouldn't fmc_send_cmd do this conversion instead of requiring all
callers to do it?
For that matter, is fmc_send_cmd ever called with a different completion
pointer?
If it always uses maintask_completion, then that argument can be omitted.
+ if (ret 0) {
+ pr_err((fmdrv): Failed to set RX audio enable path - %d\n,
+ ret);
Is it possible to move this error into fmc_send_cmd? That will again save a
lot of repetitive code. Something like: pr_err((fmdrv): Command %d failed\n,
cmd);
By and large I find that this driver seems to be bigger than it really needs
to be. Some tightening of the code is definitely required. It will look better
for it.
+ return ret;
+ }
+
+ /* Set hilo to automatic selection */
+ FM_STORE_LE16_TO_BE16(payload, FM_RX_IFFREQ_HILO_AUTOMATIC);
+ ret = fmc_send_cmd(fmdev, HILO_SET, payload, sizeof(payload),
+ fmdev-maintask_completion, NULL, NULL);
+ if (ret 0) {
+ pr_err((fmdrv): Failed to set HILO to automatic selection
+ - %d\n, ret);
+ return ret;
+ }
+
+ /* Calculate frequency index to write */
+ frq_index = (freq_to_set - fmdev-rx.region.bottom_frequency) /
+ FM_FREQ_MUL;
+
+ /* Set frequency index */
+ FM_STORE_LE16_TO_BE16(payload, frq_index);
+ ret = fmc_send_cmd(fmdev, FREQ_SET, payload, sizeof(payload),
+ fmdev-maintask_completion, NULL, NULL);
+ if (ret 0) {
+ pr_err((fmdrv): Failed to
Re: [PATCH v4 0/6] FM V4L2 drivers for WL128x
Hi Pavan, On Wed, Nov 17, 2010 at 6:32 PM, Ohad Ben-Cohen o...@wizery.com wrote: drivers/staging/ti-st/Kconfig | 10 + drivers/staging/ti-st/Makefile | 2 + drivers/staging/ti-st/fmdrv.h | 259 drivers/staging/ti-st/fmdrv_common.c | 2141 ++ drivers/staging/ti-st/fmdrv_common.h | 458 drivers/staging/ti-st/fmdrv_rx.c | 979 drivers/staging/ti-st/fmdrv_rx.h | 59 + drivers/staging/ti-st/fmdrv_tx.c | 461 drivers/staging/ti-st/fmdrv_tx.h | 37 + drivers/staging/ti-st/fmdrv_v4l2.c | 757 drivers/staging/ti-st/fmdrv_v4l2.h | 32 + 11 files changed, 5195 insertions(+), 0 deletions(-) Usually when a driver is added to staging, it should also have a TODO file specifying what needs to be done before the driver can be taken out of staging (at least as far as the author knows of today). It helps keeping track of the open issues in the driver, which is good for everyone - the author, the random contributor/observer, and probably even the staging maintainer. Can you please add such a TODO file ? ... Thanks Ohad, for the comments, We do have an internal TODO. In terms of functionality we have stuff like TX RDS which already has few CIDs in the extended controls. extend V4L2 for complete-scan, add in stop search during hw_seek .. etc... You need to understand and list the reasons why this driver cannot go directly to mainline; missing functionality is usually not the culprit. But I just wanted to ask whether this is good enough to be staged. Because as we begin to implement and add in the items in TODO - the patch set will keep continuing to grow. So Hans, Mauro, What do you think ? It would be real helpful - if this can be staged, it is becoming difficult to maintain for us. Greg has mentioned that staging acceptance rules are: 1. Code compiles 2. Is self sustained (does not touch code out of staging) 3. Has a clear roadmap out of staging (that TODO file) 4. Is maintained But I really think you should always prefer to upstream your code directly to mainline. Submit the code, have it reviewed by the relevant maintainers and upstream developers, and fix it appropriately until it is accepted. Only if you feel (/know) it would take substantial cleanup/redesign efforts until it is accepted upstream, then staging is indeed the way to go. But then you should know what gates it from upstream merger, and focus on that (rather than on adding functionality) until it is taken out of staging. IMHO adding functionality will just make it harder for you to take it out of staging eventually. Usually the opposite road is taken: first get a minimal driver accepted upstream, and then gradually add the missing functionality. Good luck, Ohad. -- 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 v4 0/6] FM V4L2 drivers for WL128x
Ohad, -Original Message- From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: Thursday, November 18, 2010 2:36 AM To: Savoy, Pavan Cc: mche...@infradead.org; hverk...@xs4all.nl; Halli, Manjunatha; linux- ker...@vger.kernel.org; linux-media@vger.kernel.org; Greg KH Subject: Re: [PATCH v4 0/6] FM V4L2 drivers for WL128x Hi Pavan, On Wed, Nov 17, 2010 at 6:32 PM, Ohad Ben-Cohen o...@wizery.com wrote: drivers/staging/ti-st/Kconfig | 10 + drivers/staging/ti-st/Makefile | 2 + drivers/staging/ti-st/fmdrv.h | 259 drivers/staging/ti-st/fmdrv_common.c | 2141 ++ drivers/staging/ti-st/fmdrv_common.h | 458 drivers/staging/ti-st/fmdrv_rx.c | 979 drivers/staging/ti-st/fmdrv_rx.h | 59 + drivers/staging/ti-st/fmdrv_tx.c | 461 drivers/staging/ti-st/fmdrv_tx.h | 37 + drivers/staging/ti-st/fmdrv_v4l2.c | 757 drivers/staging/ti-st/fmdrv_v4l2.h | 32 + 11 files changed, 5195 insertions(+), 0 deletions(-) Usually when a driver is added to staging, it should also have a TODO file specifying what needs to be done before the driver can be taken out of staging (at least as far as the author knows of today). It helps keeping track of the open issues in the driver, which is good for everyone - the author, the random contributor/observer, and probably even the staging maintainer. Can you please add such a TODO file ? ... Thanks Ohad, for the comments, We do have an internal TODO. In terms of functionality we have stuff like TX RDS which already has few CIDs in the extended controls. extend V4L2 for complete-scan, add in stop search during hw_seek .. etc... You need to understand and list the reasons why this driver cannot go directly to mainline; missing functionality is usually not the culprit. I don't. I always doubt I would get all the answers from the maintainers if I keep posting 10 files with 200 lines of code in each of them every time. But I just wanted to ask whether this is good enough to be staged. Because as we begin to implement and add in the items in TODO - the patch set will keep continuing to grow. So Hans, Mauro, What do you think ? It would be real helpful - if this can be staged, it is becoming difficult to maintain for us. Greg has mentioned that staging acceptance rules are: 1. Code compiles 2. Is self sustained (does not touch code out of staging) 3. Has a clear roadmap out of staging (that TODO file) 4. Is maintained But I really think you should always prefer to upstream your code directly to mainline. Submit the code, have it reviewed by the relevant maintainers and upstream developers, and fix it appropriately until it is accepted. Yes, I would love to do that too, however this is the problem we have with submission of functionally completed code. Only if you feel (/know) it would take substantial cleanup/redesign efforts until it is accepted upstream, then staging is indeed the way to go. But then you should know what gates it from upstream merger, and focus on that (rather than on adding functionality) until it is taken out of staging. IMHO adding functionality will just make it harder for you to take it out of staging eventually. Usually the opposite road is taken: first get a minimal driver accepted upstream, and then gradually add the missing functionality. Yes, hence inputs from Hans, Mauro and you too are welcome in suggesting as To whether it is good enough for staging, and once staged, you are also Welcome to add on to list of TODOs which we will take care :) Thanks, Pavan Good luck, Ohad. -- 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
saa7146_i2c_writeout issue
Hi, I'm using a DVB-S card Technotrend TT budget S-1500 in my production environment (Debian, 2.6.26-2-686, MuMuDVB). I get the last v4l-dvb from http://linuxtv.org/hg/v4l-dvb/. Basically cards works OK, but I have repeatable error from the Kernel in Syslog: Nov 18 11:40:11 hannibal kernel: [1202064.284030] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer How can I fix this ? Is this working http://www.mail-archive.com/linux-...@linuxtv.org/msg24759.html ? Regards, Ludovic -- 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: [linux-dvb] cx23885 crashes with TeVii S470
Try reverting the change that enabled MSI in cx23885. R, Andy Hans Houwaard h...@ginder.xs4all.nl wrote: My issue was that the only PCIe 1X slot shared an IRQ with the onboard Sound card and that caused all kinds of problems. Also I had to power off my machine if I ever had problems with the DVB cards. They would not function properly after a warm reboot. Good luck with the issues, my system is not entirely stable as well. Hans - Oorspronkelijk bericht - Van: Frank Wohlfahrt frank-i...@gmx.de Aan: linux-...@linuxtv.org Verzonden: Donderdag 18 november 2010 08:33:32 Onderwerp: [linux-dvb] cx23885 crashes with TeVii S470 I have a TeVii S470 installed on the only PCIe slot of my MSI H55M-ED55. The driver crashes about 50% already immediately after booting, but also some time afterwards, working properly until then. [ 190.764711] ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)... [ 190.764722] cx23885 :02:00.0: firmware: requesting dvb-fe-ds3000.fw [ 190.767173] ds3000_firmware_ondemand: Waiting for firmware upload(2)... [ 193.151417] cx23885[0]: mpeg risc op code error [ 193.151427] cx23885[0]: TS1 B - dma channel status dump [ 193.151434] cx23885[0]: cmds: init risc lo : 0x2390e000 [ 193.151440] cx23885[0]: cmds: init risc hi : 0x [ 193.151446] cx23885[0]: cmds: cdt base : 0x00010580 [ 193.151451] cx23885[0]: cmds: cdt size : 0x000a [ 193.151456] cx23885[0]: cmds: iq base: 0x00010400 [ 193.151462] cx23885[0]: cmds: iq size: 0x0010 [ 193.151468] cx23885[0]: cmds: risc pc lo : 0x2390e1cc [ 193.151473] cx23885[0]: cmds: risc pc hi : 0x [ 193.151478] cx23885[0]: cmds: iq wr ptr : 0x4103 ... The related source module is (I think): cx23885-core.c Only yesterday I had the error during shutdown (preventing the system to switch off): [ 5021.188012] cx23885 :02:00.0: PCI INT A disabled [ 5021.211443] saa7146: unregister extension 'dvb'. [ 5021.243256] BUG: unable to handle kernel NULL pointer dereference at (null) [ 5021.243262] IP: [ef9824ce] v4l2_device_unregister+0x1e/0x50 [videodev] [ 5021.243272] *pde = 76190067 [ 5021.243274] Oops: [#1] SMP [ 5021.243277] last sysfs file: /sys/devices/pci:00/:00:1c.3/:02:00.0/firmware/:02:00.0/loading I don't know if this failure has something to do with the problem above. The software I use is Ubuntu Lucid (Kernel 2.6.32-25-generic) coming with the VDR distribution yavdr 0.3. The firmware for the card is from packet linux-firmware-yavdr Version: 1.1-3yavdr1 -rw-r--r-- 1 root root8192 2010-07-18 21:54 dvb-fe-ds3000.fw I get the same problems using the original kernel module from 2.6.32 or the DKMS modules from v4l-dvb-dkms (0~20101018.15139) or s2-liplianin-dkms (0~20101016.14629). I think I have a hardware problem and I just have to know wether it can be fixed with maybe BIOS settings or if I have to get a different DVB-S2 card. What is the reason for a mpeg risc op code error ? Thanks in advance !! TeVii S470: 02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02) Rest of the system: Intel Core i3 530,+ Hauppauge Nexus-s 2.2 (PCI slot) cx23885 117401 6 cx2341x12404 1 cx23885 v4l2_common16390 2 cx23885,cx2341x videodev 36345 3 saa7146_vv,cx23885,v4l2_common v4l1_compat13251 1 videodev videobuf_dma_sg10782 2 saa7146_vv,cx23885 videobuf_dvb5096 1 cx23885 Frank Wohlfahrt ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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/7] v4l: add videobuf2 Video for Linux 2 driver framework
Hi Hans and Marek,
Some meta-comments below... ;)
On Thu, 2010-11-18 at 10:17 +0100, Hans Verkuil wrote:
+#define mem_ops(q, plane) ((q)-alloc_ctx[plane]-mem_ops)
+
+#define call_memop(q, plane, op, args...) \
+ (((q)-alloc_ctx[plane]-mem_ops-op) ? \
+ ((q)-alloc_ctx[plane]-mem_ops-op(args)) : 0)
Why not use mem_ops in the call_memop macro? That would simplify it a
bit.
I think you meant
Why not use the the mem_ops macro in the call_memop macro?
Yes, that's what I meant.
Asking the user to pass in a mem_ops pointer as an argument to the
call_memop() macro isn't a simplification, but that's how I first read
your comment.
snip
+
+ if (req-count == 0) {
+ /* Free/release memory for count = 0, but only if unused */
+ if (q-memory == V4L2_MEMORY_MMAP __buffers_in_use(q)) {
+ dprintk(1, reqbufs: memory in use, cannot free\n);
+ ret = -EBUSY;
+ goto end;
+ }
+
+ ret = __vb2_queue_free(q);
OK, I have a problem here. How do I detect as an application whether a
driver
supports MMAP and/or USERPTR?
What I am using in qv4l2 (and it doesn't work properly with videobuf) is
that
I call REQBUFS with count == 0 for MMAP and for USERPTR and I check
whether it
returns 0 or -EINVAL.
It seems a reasonable test since it doesn't allocate anything. It would
be nice
if vb2 can check for the memory field here based on what the driver
supports.
Ideally we should make this an official part of the spec (or have some
other
mechanism to find out what it supported).
Well it seems to be documented, just not clearly:
First paragraph here:
http://linuxtv.org/downloads/v4l-dvb-apis/mmap.html
First second Paragraph here:
http://linuxtv.org/downloads/v4l-dvb-apis/userp.html
(which mentions not allocating things.)
And in the description here:
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
As you said, it is documented, sort of.
I suppose adding flags to VIDIOC_QUERYCAP results would remove all the
hokey algorithmic probing of what the driver should already know.
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html
V4L2_CAP_STREAMING0x0400
V4L2_CAP_STREAMING_MMAP 0x0800
V4L2_CAP_STREAMING_USER_PTR 0x1000
I don't think there is any need for yet more cap bits. If I can call
REQBUFS with count of 0 and it returns -EINVAL if the memory is incorrect,
then I'm happy. There is a small complication: the memory check should
happen before the check whether another capture is in progress. Otherwise
I would get back EBUSY and still not know if my requested memory type is
ok or not.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by 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
cx24116_cmd_execute() Firmware not responding
Hi, sorry to bother you again, but I'm still in the course to get DVB/VDR going _again_. Hardware: 2 * Hauppauge WinTV-HVR4000(Lite), 1 * Hauppauge WinTV Nexus-S Software: openSUSE 11.1/i586 with Kernel:HEAD 2.6.36-94.1 VDR 1.6.0-2 VDR is limited operational, some recordings stutter, and the logs are flodded with: Nov 18 13:09:03 tyrex kernel: [14180.392584] cx24116_cmd_execute() Firmware not responding Nov 18 13:09:10 tyrex kernel: [14186.959970] cx24116_cmd_execute() Firmware not responding Nov 18 13:09:19 tyrex kernel: [14196.433715] cx24116_cmd_execute() Firmware not responding Nov 18 13:09:24 tyrex kernel: [14201.364116] cx24116_cmd_execute() Firmware not responding Nov 18 13:09:31 tyrex kernel: [14207.927543] cx24116_cmd_execute() Firmware not responding Nov 18 13:09:40 tyrex kernel: [14217.409232] cx24116_cmd_execute() Firmware not responding Nov 18 13:09:50 tyrex kernel: [14226.886942] cx24116_cmd_execute() Firmware not responding Nov 18 13:09:52 tyrex kernel: [14228.887018] cx24116_cmd_execute() Firmware not responding Nov 18 13:09:02 tyrex vdr: [24392] buffer stats: 0 (0%) used Nov 18 13:09:02 tyrex vdr: [24384] ERROR (dvbdevice.c,263): Die Wartezeit für die Verbindung ist abgelaufen Nov 18 13:09:09 tyrex vdr: [24384] ERROR (dvbdevice.c,263): Die Wartezeit für die Verbindung ist abgelaufen Nov 18 13:09:18 tyrex vdr: [24384] frontend 1 timed out while tuning to channel 2, tp 111954 Nov 18 13:09:18 tyrex vdr: [24384] ERROR (dvbdevice.c,263): Die Wartezeit für die Verbindung ist abgelaufen Nov 18 13:09:23 tyrex vdr: [24392] buffer stats: 0 (0%) used Nov 18 13:09:23 tyrex vdr: [24384] ERROR (dvbdevice.c,263): Die Wartezeit für die Verbindung ist abgelaufen Nov 18 13:09:30 tyrex vdr: [24384] ERROR (dvbdevice.c,263): Die Wartezeit für die Verbindung ist abgelaufen Nov 18 13:09:38 tyrex vdr: [24392] streamdev-server: Detaching current receiver Nov 18 13:09:38 tyrex vdr: [24392] streamdev-server: Detaching current receiver Nov 18 13:09:38 tyrex vdr: [24392] streamdev-server: Detaching current receiver Nov 18 13:09:39 tyrex vdr: [24384] frontend 1 timed out while tuning to channel 1330, tp 111992 Nov 18 13:09:39 tyrex vdr: [24384] ERROR (dvbdevice.c,263): Die Wartezeit für die Verbindung ist abgelaufen Nov 18 13:09:44 tyrex vdr: [24392] streamdev-server: Detaching current receiver Nov 18 13:09:44 tyrex vdr: [24392] streamdev-server: Detaching current receiver Nov 18 13:09:44 tyrex vdr: [24392] streamdev-server: Detaching current receiver Nov 18 13:09:49 tyrex vdr: [24384] ERROR (dvbdevice.c,263): Die Wartezeit für die Verbindung ist abgelaufen Nov 18 13:09:51 tyrex vdr: [24384] ERROR (dvbdevice.c,263): Die Wartezeit für die Verbindung ist abgelaufen Nov 18 13:09:59 tyrex vdr: [24392] streamdev-server: Detaching current receiver Nov 18 13:09:59 tyrex vdr: [24392] streamdev-server: Detaching current receiver Nov 18 13:09:59 tyrex vdr: [24392] streamdev-server: Detaching current receiver Die Wartezeit für die Verbindung ist abgelaufen is an translated ioctl error from this call: CHECK(ioctl(fd_frontend, FE_SET_TONE, tone)); It might be translated with: timeout for idle time of connection. Running cx24116 with debugging enabled results in: ftp://urpla.net/cx24116-debug.log [One minute, 540 kiB] vdr log from the same period: Nov 18 14:00:03 tyrex vdr: [31450] streamdev-server: Detaching current receiver Nov 18 14:00:03 tyrex vdr: [31450] streamdev-server: Detaching current receiver Nov 18 14:00:03 tyrex vdr: [31450] streamdev-server: Detaching current receiver Nov 18 14:00:06 tyrex vdr: [31445] ERROR (dvbdevice.c,263): Die Wartezeit für die Verbindung ist abgelaufen Nov 18 14:00:08 tyrex vdr: [31445] ERROR (dvbdevice.c,263): Die Wartezeit für die Verbindung ist abgelaufen Nov 18 14:00:08 tyrex vdr: [31443] changing pids of channel 1331 from 151+151:160=hun,161=cze,162=eng,163=eng:0:170 to 1 51+151:160=hun,161=cze,162=eng,163=eng:171=hun,172=cze:170 Nov 18 14:00:09 tyrex vdr: [31443] changing pids of channel 1341 from 651+651:660=hun,661=cze:0:0 to 651+651:660=hun,661 =cze:670=cze,671=hun,672=cze:0 Nov 18 14:00:17 tyrex vdr: [31445] frontend 2 timed out while tuning to channel 62, tp 112031 Nov 18 14:00:17 tyrex vdr: [31445] ERROR (dvbdevice.c,263): Die Wartezeit für die Verbindung ist abgelaufen Nov 18 14:00:20 tyrex vdr: [31450] streamdev-server: Detaching current receiver Nov 18 14:00:20 tyrex vdr: [31450] streamdev-server: Detaching current receiver Nov 18 14:00:20 tyrex vdr: [31450] streamdev-server: Detaching current receiver Nov 18 14:00:24 tyrex vdr: [31450] streamdev-server: Detaching current receiver Nov 18 14:00:24 tyrex vdr: [31450] streamdev-server: Detaching current receiver Nov 18 14:00:24 tyrex vdr: [31450] streamdev-server: Detaching current receiver Nov 18 14:00:27 tyrex vdr: [31445] ERROR (dvbdevice.c,263): Die Wartezeit für die Verbindung ist abgelaufen Nov 18 14:00:29 tyrex vdr: [31445] ERROR (dvbdevice.c,263):
Re: [RFCv2 PATCH 07/15] dsbr100: convert to unlocked_ioctl.
This driver has quite a few locking issues that would only be made worse by your patch. A much better patch for this can be found here: http://desource.dyndns.org/~atog/gitweb?p=linux-media.git;a=commitdiff;h=9c5d8ebb602e9af46902c5f3d4d4cc80227d3f7c Regards, David Ellingsworth -- 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: [RFCv2 PATCH 07/15] dsbr100: convert to unlocked_ioctl.
This driver has quite a few locking issues that would only be made worse by your patch. A much better patch for this can be found here: http://desource.dyndns.org/~atog/gitweb?p=linux-media.git;a=commitdiff;h=9c5d8ebb602e9af46902c5f3d4d4cc80227d3f7c Much too big for 2.6.37. I'll just drop this patch from my patch series. Instead it will rely on the new lock in v4l2_device (BKL replacement) that serializes all ioctls. For 2.6.38 we can convert it to core assisted locking which is much easier. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by 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: [RFCv2 PATCH 07/15] dsbr100: convert to unlocked_ioctl.
On Thu, Nov 18, 2010 at 9:46 AM, Hans Verkuil hverk...@xs4all.nl wrote: This driver has quite a few locking issues that would only be made worse by your patch. A much better patch for this can be found here: http://desource.dyndns.org/~atog/gitweb?p=linux-media.git;a=commitdiff;h=9c5d8ebb602e9af46902c5f3d4d4cc80227d3f7c Much too big for 2.6.37. I'll just drop this patch from my patch series. Instead it will rely on the new lock in v4l2_device (BKL replacement) that serializes all ioctls. For 2.6.38 we can convert it to core assisted locking which is much easier. I don't see how this patch is really any bigger than some of the others in your series. Sure there are a lot of deletions, but the number of additions is quite small. There are much worse ways all the locking issues in this driver could have been corrected. This patch manages to do just that while reducing the overall size of the driver at the same time. Regards, David Ellingsworth -- 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/7] v4l: videobuf2: add DMA coherent allocator
Hello,
On Thursday, November 18, 2010 8:15 AM Sewoon Park wrote:
Marek Szyprowski wrote:
Sent: Wednesday, November 17, 2010 5:40 PM
To: linux-media@vger.kernel.org
Cc: m.szyprow...@samsung.com; pa...@osciak.com; kyungmin.p...@samsung.com
Subject: [PATCH 4/7] v4l: videobuf2: add DMA coherent allocator
From: Pawel Osciak p.osc...@samsung.com
Add an implementation of DMA coherent memory allocator and handling
routines for videobuf2, implemented on top of dma_alloc_coherent() call.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/Kconfig |5 +
drivers/media/video/Makefile |1 +
drivers/media/video/videobuf2-dma-coherent.c | 208
++
include/media/videobuf2-dma-coherent.h | 27
4 files changed, 241 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/videobuf2-dma-coherent.c
create mode 100644 include/media/videobuf2-dma-coherent.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9351423..e7752ee1 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -55,6 +55,11 @@ config VIDEOBUF2_CORE
config VIDEOBUF2_MEMOPS
tristate
+config VIDEOBUF2_DMA_COHERENT
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ tristate
+
config VIDEOBUF2_VMALLOC
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 538bee9..baa74e7 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -117,6 +117,7 @@ obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o
obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o
obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
obj-$(CONFIG_VIDEOBUF2_VMALLOC)+= videobuf2-vmalloc.o
+obj-$(CONFIG_VIDEOBUF2_DMA_COHERENT) += videobuf2-dma_coherent.o
obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
diff --git a/drivers/media/video/videobuf2-dma-coherent.c
b/drivers/media/video/videobuf2-dma-coherent.c
new file mode 100644
index 000..761f366
--- /dev/null
+++ b/drivers/media/video/videobuf2-dma-coherent.c
@@ -0,0 +1,208 @@
+/*
+ * videobuf2-dma-coherent.c - DMA coherent memory allocator for videobuf2
+ *
+ * Copyright (C) 2010 Samsung Electronics
+ *
+ * Author: Pawel Osciak p.osc...@samsung.com
+ *
+ * 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.
+ */
+
+#include linux/module.h
+#include linux/dma-mapping.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-memops.h
+
+struct vb2_dc_conf {
+ struct vb2_alloc_ctxalloc_ctx;
+ struct device *dev;
+};
(snip)
+static void vb2_dma_coherent_put_userptr(void *mem_priv)
+{
+ struct vb2_dc_buf *buf = mem_priv;
+
+ if (!buf)
+ return;
+
+ vb2_put_userptr(buf-vma);
+ kfree(buf);
+}
+
+const struct vb2_mem_ops vb2_dma_coherent_ops = {
+ .alloc = vb2_dma_coherent_alloc,
+ .put= vb2_dma_coherent_put,
+ .paddr = vb2_dma_coherent_paddr,
The paddr is not exist in vb2_mem_ops after [PATCH v4 xxx] lists.
I think you should fix from paddr to cookie like CMA allocator.
Right, my fault. Looks I've mixed something and forgot to update this patch
before
posting. Thanks for spotting this!
Best regards
--
Marek Szyprowski
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: [RFCv2 PATCH 07/15] dsbr100: convert to unlocked_ioctl.
On Thu, Nov 18, 2010 at 9:46 AM, Hans Verkuil hverk...@xs4all.nl wrote: This driver has quite a few locking issues that would only be made worse by your patch. A much better patch for this can be found here: http://desource.dyndns.org/~atog/gitweb?p=linux-media.git;a=commitdiff;h=9c5d8ebb602e9af46902c5f3d4d4cc80227d3f7c Much too big for 2.6.37. I'll just drop this patch from my patch series. Instead it will rely on the new lock in v4l2_device (BKL replacement) that serializes all ioctls. For 2.6.38 we can convert it to core assisted locking which is much easier. I don't see how this patch is really any bigger than some of the others in your series. Sure there are a lot of deletions, but the number of additions is quite small. There are much worse ways all the locking issues in this driver could have been corrected. This patch manages to do just that while reducing the overall size of the driver at the same time. Basically there are two reasons why I'm not including this in my patch series: 1) you disagreed with my patch and 2) I disagree with your patch. In this case the patch for 2.6.37 should either be small and trivial, or we should postpone it to 2.6.38 and use proper core-assisted locking (which makes the most sense for this driver in my opinion). And I really dislike those BUG_ONs you've added, to be honest. Sorry about that... Anyway, feel free to post your own patch for this driver. I've no problems with that at all. It is clear that this driver takes more time to get a proper patch for that makes everyone happy, and I really need to make the git pull request for 2.6.37 tomorrow as we don't want to do this too late in the 2.6.37 cycle. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by 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 1/7] v4l: add videobuf2 Video for Linux 2 driver framework
Hi Hans, On Thu, Nov 18, 2010 at 01:17, Hans Verkuil hverk...@xs4all.nl wrote: Hi Marek! Some comments below... On Wednesday, November 17, 2010 09:39:28 Marek Szyprowski wrote: From: Pawel Osciak p.osc...@samsung.com +/** + * struct vb2_mem_ops - memory handling/memory allocator operations + * @alloc: allocate video memory and, optionally, allocator private data, + * return NULL on failure or a pointer to allocator private, + * per-buffer data on success, NULL on failure; the returned + * private structure will then be passed as buf_priv argument + * to other ops in this structure + * @put: inform the allocator that the buffer will no longer be used; + * usually will result in the allocator freeing the buffer (if + * no other users of this buffer are present); the buf_priv + * argument is the allocator private per-buffer structure + * previously returned from the alloc callback + * @get_userptr: acquire userspace memory for a hardware operation; used for + * USERPTR memory types; vaddr is the address passed to the + * videobuf layer when queuing a video buffer of USERPTR type; + * should return an allocator private per-buffer structure + * associated with the buffer on success, NULL on failure; + * the returned private structure will then be passed as buf_priv + * argument to other ops in this structure + * @put_userptr: inform the allocator that a USERPTR buffer will no longer + * be used 'get' and 'put' imply reference counting. However, I don't believe that's the case for USERPTR. If I am right, then I would like to see different names for these callbacks. Actually, they are intended for reference counting. The idea is to allow using the same memory for creating pipelines. Please take a look at the second patch in the series, generic implementations of get() and put() are in there. -- Best regards, Pawel Osciak -- 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: [RFCv2 PATCH 07/15] dsbr100: convert to unlocked_ioctl.
On Thu, Nov 18, 2010 at 10:29 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Thu, Nov 18, 2010 at 9:46 AM, Hans Verkuil hverk...@xs4all.nl wrote: This driver has quite a few locking issues that would only be made worse by your patch. A much better patch for this can be found here: http://desource.dyndns.org/~atog/gitweb?p=linux-media.git;a=commitdiff;h=9c5d8ebb602e9af46902c5f3d4d4cc80227d3f7c Much too big for 2.6.37. I'll just drop this patch from my patch series. Instead it will rely on the new lock in v4l2_device (BKL replacement) that serializes all ioctls. For 2.6.38 we can convert it to core assisted locking which is much easier. I don't see how this patch is really any bigger than some of the others in your series. Sure there are a lot of deletions, but the number of additions is quite small. There are much worse ways all the locking issues in this driver could have been corrected. This patch manages to do just that while reducing the overall size of the driver at the same time. Basically there are two reasons why I'm not including this in my patch series: 1) you disagreed with my patch and 2) I disagree with your patch. In this case the patch for 2.6.37 should either be small and trivial, or we should postpone it to 2.6.38 and use proper core-assisted locking (which makes the most sense for this driver in my opinion). And I really dislike those BUG_ONs you've added, to be honest. Sorry about that... The reality is that the BUG_ONs should never be hit. I added those because I don't have the hardware needed to test my changes. So if I missed something, the issue would be very apparent to whoever was doing the testing. If someone would actually test this series, the BUG_ONs could be removed. Maybe a WARN_ON would have been better, but to me accessing the device struct without holding the lock is a bug. The only valid case where it would be okay to do that would be from within the probe function before the device is registered. Anyway, feel free to post your own patch for this driver. I've no problems with that at all. It is clear that this driver takes more time to get a proper patch for that makes everyone happy, and I really need to make the git pull request for 2.6.37 tomorrow as we don't want to do this too late in the 2.6.37 cycle. I understand, but if you or anyone else had actually bothered to review this patch when it was submitted back in May then it might have made its way into the kernel by now. At the time the patch was written, core assisted locking wasn't even implemented. Granted the ioctl added to correct the locking might cause a cache miss, but this is acceptable for such a simple driver. This is a good first step towards core assisted locking. Regards, David Ellingsworth -- 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: [RFC PATCH 0/2] Apple remote support
On Wed, Nov 17, 2010 at 12:26:36AM +0100, David Härdeman wrote: On Tue, Nov 16, 2010 at 10:08:29AM -0200, Mauro Carvalho Chehab wrote: ... Also, changing the current tables to 32 bits will break userspace API, as all userspace keytables for NEC will stop working, all due to a few vendors that decided to abuse on the NEC protocol. This doesn't sound fair. The NEC protocol is hardly a standard. There's lot's of variations out there. And intentionally throwing away information inside the kernel doesn't sound fair either. Considering that the new setkeycode/getkeycode ioctls support a variable size for scancodes, it seems to me that the proper solution is properly add support for variable-size scancode tables. By doing this, one of the properties for a scancode table is the size of the scancode. The NEC decoding logic can take the scancode size into account, when deciding to check checksum or not. With that approach you'd have to have the same scancode mangling code in each driver which generates NEC scancodes as well as in the nec raw decoder. One suggestion would be to use a full 32-bit scancode table, but use the size from the ioctl to determine how to generate the scancode to be inserted into the table. So if the ioctl was called with a 2 byte scancode, assume NEC with addr(8 bits) + cmd(8 bits); 3 byte - NEC Extended with addr(16 bits) + cmd(8 bits); 4 byte - 32 bit scancode. That way the nec decoder and other scancode drivers can be kept simple, the scancode table has a full 32 bit scancode for all keys and userspace won't see the difference (though I still think we should use the new large scancode API to let userspace properly indicate the protocol along with the scancode in the future). I hacked together a semi-nasty variant of this, which I already know Mauro isn't too keen on, but its perhaps a step in the right direction. At least, its hopefully better than a modparam approach... ;) http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=commitdiff;h=a2eabcb44fa72e98a912c05a23659d0c946a17e5 http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=commitdiff;h=164dc9cf5dec582bda5f7a059957ac2da2b0c1aa Mauro's suggestion, iirc, was that max scancode size should be a property of the keytable uploaded, and something set at load time (and probably exposed as a sysfs node, similar to protocols). However, the one issue I see there is that if someone loads a 16-bit keytable, then does a single scancode replacement with something much larger, how are we going to handle that? -- Jarod Wilson ja...@redhat.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/7] v4l: add videobuf2 Video for Linux 2 driver framework
Hello,
On Thursday, November 18, 2010 1:27 PM Andy Walls wrote:
Hi Hans and Marek,
Some meta-comments below... ;)
On Thu, 2010-11-18 at 10:17 +0100, Hans Verkuil wrote:
Hi Marek!
Some comments below...
On Wednesday, November 17, 2010 09:39:28 Marek Szyprowski wrote:
...
+/**
+ * vb2_reqbufs() - Initiate streaming
+ * @q: videobuf2 queue
+ * @req: struct passed from userspace to vidioc_reqbufs handler in driver
+ *
+ * Should be called from vidioc_reqbufs ioctl handler of a driver.
+ * This function:
+ * 1) verifies streaming parameters passed from the userspace,
+ * 2) sets up the queue,
+ * 3) negotiates number of buffers and planes per buffer with the driver
+ *to be used during streaming,
+ * 4) allocates internal buffer structures (struct vb2_buffer),
according to
+ *the agreed parameters,
+ * 5) for MMAP memory type, allocates actual video memory, using the
+ *memory handling/allocation routines provided during queue
initialization
+ *
+ * If req-count is 0, all the memory will be freed instead.
+ * If the queue has been allocated previously (by a previous
vb2_reqbufs) call
+ * and the queue is not busy, memory will be reallocated.
+ *
+ * The return values from this function are intended to be directly
returned
+ * from vidioc_reqbufs handler in driver.
+ */
+int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
+{
+ unsigned int num_buffers, num_planes;
+ int ret = 0;
+
+ if (req-memory != V4L2_MEMORY_MMAP
+ req-memory != V4L2_MEMORY_USERPTR) {
+ dprintk(1, reqbufs: unsupported memory type\n);
+ return -EINVAL;
+ }
+
+ if (req-type != q-type) {
+ dprintk(1, reqbufs: queue type invalid\n);
+ return -EINVAL;
+ }
+
+ if (q-streaming) {
+ dprintk(1, reqbufs: streaming active\n);
+ return -EBUSY;
+ }
+
+ if (req-count == 0) {
+ /* Free/release memory for count = 0, but only if unused */
+ if (q-memory == V4L2_MEMORY_MMAP __buffers_in_use(q)) {
+ dprintk(1, reqbufs: memory in use, cannot free\n);
+ ret = -EBUSY;
+ goto end;
+ }
+
+ ret = __vb2_queue_free(q);
OK, I have a problem here. How do I detect as an application whether a
driver
supports MMAP and/or USERPTR?
What I am using in qv4l2 (and it doesn't work properly with videobuf) is
that
I call REQBUFS with count == 0 for MMAP and for USERPTR and I check whether
it
returns 0 or -EINVAL.
It seems a reasonable test since it doesn't allocate anything. It would be
nice
if vb2 can check for the memory field here based on what the driver
supports.
Ideally we should make this an official part of the spec (or have some other
mechanism to find out what it supported).
Well it seems to be documented, just not clearly:
First paragraph here:
http://linuxtv.org/downloads/v4l-dvb-apis/mmap.html
First second Paragraph here:
http://linuxtv.org/downloads/v4l-dvb-apis/userp.html
(which mentions not allocating things.)
And in the description here:
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
I suppose adding flags to VIDIOC_QUERYCAP results would remove all the
hokey algorithmic probing of what the driver should already know.
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html
V4L2_CAP_STREAMING0x0400
V4L2_CAP_STREAMING_MMAP 0x0800
V4L2_CAP_STREAMING_USER_PTR 0x1000
Good idea! This way querying memory access types will be much less intrusive :)
...
Great job! Thanks for all the hard work!
Ditto!
Thx :)
Best regards
--
Marek Szyprowski
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
[cron job] v4l-dvb daily build: WARNINGS
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 Nov 18 19:00:10 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: 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 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
Re: HVR900H : IR Remote Control
Le 17/11/2010 20:33, Massis Sirapian a écrit :
load the tm6000 module with the parameter ir_debug=1. (not the
tm6000_dvb), and check dmsg after you pressed a button. Have the
received code the same from the map?
I have only
[ 5232.133592] tm5600/60x0 IR (tm6000 #0)/ir: ir-get_key result
data=
endlessly, and nothing seems to change when I press a button.
can you test a little change in tm6000-input.c. The dprintk line this
line move to here, and then testing it.
return;
}
dprintk(ir-get_key result data=%04x\n, poll_result.rc_data); // this
line
if (ir-key) {
// here
ir_keydown(ir-rc, poll_result.rc_data, 0);
ir-key = 0;
--
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
I've just tested the new kernel compiled with the modifie tm6000-cards.c
Nothing happens when I press a button :
[ 227.643920] input: tm5600/60x0 IR (tm6000 #0) as
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.4/rc/rc0/input7
[ 227.643965] rc0: tm5600/60x0 IR (tm6000 #0) as
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.4/rc/rc0
[ 227.759492] usbcore: registered new interface driver tm6000
[ 229.015963] tm6000: open called (dev=video1)
are the last lines of dmesg, and my pressing any button doesn't change
anything.
Massis
--
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
Hi,
Does it mean that the IR isn't wired in the case of HVR900H ? When you
said that your Terratec equals the HVR900H, does it imply that if IR
works on cinergy xe, it should on the HVR900H?
Thank you
Massis
--
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: HVR900H : IR Remote Control
On Thu, Nov 18, 2010 at 2:59 PM, Massis Sirapian msirap...@free.fr wrote: Does it mean that the IR isn't wired in the case of HVR900H ? When you said that your Terratec equals the HVR900H, does it imply that if IR works on cinergy xe, it should on the HVR900H? One thing you may wish to consider is that if I recall the Terratec remotes are typically NEC and the Hauppauge remotes are typically RC5. So it's possible that only the NEC support is working in the current tm6010 driver, which is why the Hauppauge remote doesn't work. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: [RFC PATCH 0/2] Apple remote support
On Thu, Nov 18, 2010 at 11:33:04AM -0500, Jarod Wilson wrote: Mauro's suggestion, iirc, was that max scancode size should be a property of the keytable uploaded, and something set at load time (and probably exposed as a sysfs node, similar to protocols). I think that would be a step in the wrong direction. It would make the keytables less flexible while providing no real advantages. -- David Härdeman -- 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: [RFC PATCH 0/2] Apple remote support
On Thu, Nov 18, 2010 at 09:43:19PM +0100, David Härdeman wrote: On Thu, Nov 18, 2010 at 11:33:04AM -0500, Jarod Wilson wrote: Mauro's suggestion, iirc, was that max scancode size should be a property of the keytable uploaded, and something set at load time (and probably exposed as a sysfs node, similar to protocols). I think that would be a step in the wrong direction. It would make the keytables less flexible while providing no real advantages. I think it was supposed to be something you could update on the fly when uploading new keys, so its not entirely inflexible. Default keymap might be 24-bit NEC, then you upload 32-bit NEC codes, and the max scancode size would get updated at the same time. Of course, it probably wouldn't work terribly well to have a mix of 24-bit and 32-bit NEC codes in the same table. -- Jarod Wilson ja...@redhat.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: [RFC PATCH 0/2] Apple remote support
Em 18-11-2010 18:49, Jarod Wilson escreveu: On Thu, Nov 18, 2010 at 09:43:19PM +0100, David Härdeman wrote: On Thu, Nov 18, 2010 at 11:33:04AM -0500, Jarod Wilson wrote: Mauro's suggestion, iirc, was that max scancode size should be a property of the keytable uploaded, and something set at load time (and probably exposed as a sysfs node, similar to protocols). I think that would be a step in the wrong direction. It would make the keytables less flexible while providing no real advantages. We can't simply just change NEC to 32 bits, as we'll break userspace ABI (as current NEC keycode tables use only 16 bits). So, an old table will not worky anymore, if we do such change. I think it was supposed to be something you could update on the fly when uploading new keys, so its not entirely inflexible. Default keymap might be 24-bit NEC, then you upload 32-bit NEC codes, and the max scancode size would get updated at the same time. Of course, it probably wouldn't work terribly well to have a mix of 24-bit and 32-bit NEC codes in the same table. There's another reason why it may be interesting to have the scancode size stored somewhere. With the new flexible scancode size, some devices may have bigger scancodes (I remember people mentioned some cases with 128 bits when we've discussed the getkeycodbig patches in the past). So, we'll need to address some cases where the scancodes don't have 32 bits. I think that the current maximum limit is 31 bits (as the search algorithm uses the signal bit for some reason). 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
BUG: sleeping function called from invalid context at...mm/fault.c:1074
Hi, got this pretty confusing BUG, probably triggered by drivers/media/dvb/siano. I had femon kaffeine running in parallel. In kaffeine output stopped so I did quit kaffeine, unplugged the DVB stick and reconnected: Nov 18 15:00:05 localhost kernel: [116557.045363] usb 5-5: USB disconnect, address 17 Nov 18 15:00:05 localhost kernel: [116557.045475] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045479] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045483] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045486] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045489] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045492] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045495] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045498] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045501] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045504] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.060214] sms_ir_exit: Nov 18 15:00:24 localhost kernel: [116575.829453] BUG: sleeping function called from invalid context at /home/rz/rpmbuild/kernels/linux-2.6.36/arch/x8 6/mm/fault.c:1074 Nov 18 15:00:24 localhost kernel: [116575.829457] in_atomic(): 0, irqs_disabled(): 1, pid: 22905, name: femon Nov 18 15:00:24 localhost kernel: [116575.829459] no locks held by femon/22905. Nov 18 15:00:24 localhost kernel: [116575.829461] irq event stamp: 17262 Nov 18 15:00:24 localhost kernel: [116575.829463] hardirqs last enabled at (17261): [c135bd4b] _raw_spin_unlock_irqrestore+0x3f/0x4c Nov 18 15:00:24 localhost kernel: [116575.829472] hardirqs last disabled at (17262): [c135b8dd] _raw_spin_lock_irqsave+0x1a/0x3f Nov 18 15:00:24 localhost kernel: [116575.829476] softirqs last enabled at (17052): [c103ad4a] __do_softirq+0x168/0x170 Nov 18 15:00:24 localhost kernel: [116575.829481] softirqs last disabled at (17047): [c103ad8b] do_softirq+0x39/0x5e Nov 18 15:00:24 localhost kernel: [116575.829486] Pid: 22905, comm: femon Not tainted 2.6.36v1 #2 Nov 18 15:00:24 localhost kernel: [116575.829488] Call Trace: Nov 18 15:00:24 localhost kernel: [116575.829493] [c102d8d4] __might_sleep+0xdb/0xe2 Nov 18 15:00:24 localhost kernel: [116575.829497] [c135ecc8] do_page_fault+0x1c0/0x304 Nov 18 15:00:24 localhost kernel: [116575.829500] [c135eb08] ? do_page_fault+0x0/0x304 Nov 18 15:00:24 localhost kernel: [116575.829504] [c135c85f] error_code+0x5f/0x70 Nov 18 15:00:24 localhost kernel: [116575.829508] [c10500d8] ? srcu_notifier_chain_register+0x14/0x72 Nov 18 15:00:24 localhost kernel: [116575.829511] [c135eb08] ? do_page_fault+0x0/0x304 Nov 18 15:00:24 localhost kernel: [116575.829515] [c105bab5] ? __lock_acquire+0x90/0xc26 Nov 18 15:00:24 localhost kernel: [116575.829518] [c105a125] ? register_lock_class+0x17/0x295 Nov 18 15:00:24 localhost kernel: [116575.829521] [c105ace9] ? mark_lock+0x1e/0x1e3 Nov 18 15:00:24 localhost kernel: [116575.829524] [c105bdac] ? __lock_acquire+0x387/0xc26 Nov 18 15:00:24 localhost kernel: [116575.829527] [c105c6e5] lock_acquire+0x9a/0xbd Nov 18 15:00:24 localhost kernel: [116575.829537] [fa8e15a7] ? smscore_find_client+0x1d/0x70 [smsmdtv] Nov 18 15:00:24 localhost kernel: [116575.829540] [c135b8f2] _raw_spin_lock_irqsave+0x2f/0x3f Nov 18 15:00:24 localhost kernel: [116575.829544] [fa8e15a7] ? smscore_find_client+0x1d/0x70 [smsmdtv] Nov 18 15:00:24 localhost kernel: [116575.829549] [fa8e15a7] smscore_find_client+0x1d/0x70 [smsmdtv] Nov 18 15:00:24 localhost kernel: [116575.829552] [c105a125] ? register_lock_class+0x17/0x295 Nov 18 15:00:24 localhost kernel: [116575.829557] [fa8e1711] smscore_validate_client+0x35/0xab [smsmdtv] Nov 18 15:00:24 localhost kernel: [116575.829562] [fa8e17e1] smsclient_sendrequest+0x5a/0x75 [smsmdtv] Nov 18 15:00:24 localhost kernel: [116575.829566] [fa9991f7] smsdvb_sendrequest_and_wait+0x1f/0x44 [smsdvb] Nov 18 15:00:24 localhost kernel: [116575.829570] [fa999250] smsdvb_send_statistics_request+0x34/0x36 [smsdvb] Nov 18 15:00:24 localhost kernel: [116575.829573] [fa999372] smsdvb_read_status+0x17/0x2f [smsdvb] Nov 18 15:00:24 localhost kernel: [116575.829582] [fa97c453] dvb_frontend_ioctl_legacy+0x610/0xc0d [dvb_core] Nov 18 15:00:24 localhost kernel: [116575.829585] [c105ace9] ? mark_lock+0x1e/0x1e3 Nov 18 15:00:24 localhost kernel:
Re: rtl2832u support
On Wed, 2010-11-17 at 12:15 +0100, Damjan Marion wrote: On Oct 19, 2010, at 10:27 PM, Hans Verkuil wrote: On Tuesday, October 19, 2010 21:26:13 Devin Heitmueller wrote: On Tue, Oct 19, 2010 at 1:42 PM, Damjan Marion damjan.mar...@gmail.com wrote: Hi, Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb? Realtek published source code under GPL: MODULE_AUTHOR(Realtek); MODULE_DESCRIPTION(Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device); MODULE_VERSION(1.4.2); MODULE_LICENSE(GPL); Unfortunately, in most cases much more is required than having a working driver under the GPL in order for it to be accepted upstream. In some cases it can mean a developer spending a few hours cleaning up whitespace and indentation, and in other cases it means significant work to the driver is required. The position the LinuxTV team has taken is that they would rather have no upstream driver at all than to have a driver which doesn't have the right indentation or other aesthetic problems which has no bearing on how well the driver actually works. This is one of the big reasons KernelLabs has tens of thousands of lines of code adding support for a variety of devices with many happy users (who are willing to go through the trouble to compile from source), but the code cannot be accepted upstream. I just cannot find the time to do the idiot work. Bullshit. First of all these rules are those of the kernel community as a whole and *not* linuxtv as such, and secondly you can upstream such drivers in the staging tree. If you want to move it out of staging, then it will take indeed more work since the quality requirements are higher there. Do we have a common agreement that this driver can go to staging as-is? If yes, I have patch ready, just need to know where to send it (It is around 1 MB). I also bought that device few days ago. Needless to say it works perfectly (better that in windows) with this driver. 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
