[GIT PULL FOR v3.10] solo6x10 driver overhaul
This pull request is identical to:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg60150.html
but the slab.h includes have been kept as requested by Mauro.
Regards,
Hans
The following changes since commit b781e6be79a394cd6980e9cd8fd5c25822d152b6:
[media] sony-btf-mpx: v4l2_tuner struct is now constant (2013-03-24 14:04:34
-0300)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git solo4
for you to fetch changes up to 053aecaa6e1e24cea0e1f5222dd169b0106b6b28:
solo6x10: prefix sources with 'solo6x10-' (2013-03-25 09:47:48 +0100)
Hans Verkuil (21):
solo6x10: sync to latest code from Bluecherry's git repo.
solo6x10: fix querycap and update driver version.
solo6x10: add v4l2_device.
solo6x10: add control framework.
solo6x10: fix various format-related compliancy issues.
solo6x10: add support for prio and control event handling.
solo6x10: move global fields in solo_dev_fh to solo_dev.
solo6x10: move global fields in solo_enc_fh to solo_enc_dev.
solo6x10: convert encoder nodes to vb2.
solo6x10: convert the display node to vb2.
solo6x10: fix 'BUG: key 88081a2a9b58 not in .data!'
solo6x10: add call to pci_dma_mapping_error.
solo6x10: drop video_type and add proper s_std support.
solo6x10: also stop DMA if the SOLO_PCI_ERR_P2M_DESC is raised.
solo6x10: small big-endian fix.
solo6x10: use V4L2_PIX_FMT_MPEG4, not _FMT_MPEG
solo6x10: fix sequence handling.
solo6x10: disable the 'priv' abuse.
solo6x10: clean up motion detection handling.
solo6x10: rename headers.
solo6x10: prefix sources with 'solo6x10-'
drivers/staging/media/solo6x10/Kconfig |3 +-
drivers/staging/media/solo6x10/Makefile |4 +-
drivers/staging/media/solo6x10/TODO | 33 +-
drivers/staging/media/solo6x10/core.c | 321
drivers/staging/media/solo6x10/offsets.h| 74 --
drivers/staging/media/solo6x10/osd-font.h | 154
drivers/staging/media/solo6x10/p2m.c| 306 ---
drivers/staging/media/solo6x10/solo6x10-core.c | 709
drivers/staging/media/solo6x10/{disp.c = solo6x10-disp.c} | 128 ++-
drivers/staging/media/solo6x10/solo6x10-eeprom.c| 154
drivers/staging/media/solo6x10/{enc.c = solo6x10-enc.c}| 239 --
drivers/staging/media/solo6x10/{g723.c = solo6x10-g723.c} | 94 ++-
drivers/staging/media/solo6x10/{gpio.c = solo6x10-gpio.c} | 13 +-
drivers/staging/media/solo6x10/{i2c.c = solo6x10-i2c.c}| 26 +-
drivers/staging/media/solo6x10/solo6x10-jpeg.h | 94 ++-
drivers/staging/media/solo6x10/solo6x10-offsets.h | 85 ++
drivers/staging/media/solo6x10/solo6x10-p2m.c | 333
drivers/staging/media/solo6x10/{registers.h = solo6x10-regs.h} | 88 +-
drivers/staging/media/solo6x10/{tw28.c = solo6x10-tw28.c} | 187 +++--
drivers/staging/media/solo6x10/{tw28.h = solo6x10-tw28.h} | 12 +-
drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 1363
++
drivers/staging/media/solo6x10/solo6x10-v4l2.c | 734
+
drivers/staging/media/solo6x10/solo6x10.h | 259 --
drivers/staging/media/solo6x10/v4l2-enc.c | 1829
-
drivers/staging/media/solo6x10/v4l2.c | 961
--
25 files changed, 4165 insertions(+), 4038 deletions(-)
delete mode 100644 drivers/staging/media/solo6x10/core.c
delete mode 100644 drivers/staging/media/solo6x10/offsets.h
delete mode 100644 drivers/staging/media/solo6x10/osd-font.h
delete mode 100644 drivers/staging/media/solo6x10/p2m.c
create mode 100644 drivers/staging/media/solo6x10/solo6x10-core.c
rename drivers/staging/media/solo6x10/{disp.c = solo6x10-disp.c} (74%)
create mode 100644 drivers/staging/media/solo6x10/solo6x10-eeprom.c
rename drivers/staging/media/solo6x10/{enc.c = solo6x10-enc.c} (50%)
rename drivers/staging/media/solo6x10/{g723.c = solo6x10-g723.c} (83%)
rename drivers/staging/media/solo6x10/{gpio.c = solo6x10-gpio.c} (91%)
rename drivers/staging/media/solo6x10/{i2c.c = solo6x10-i2c.c} (92%)
create mode 100644 drivers/staging/media/solo6x10/solo6x10-offsets.h
create mode 100644 drivers/staging/media/solo6x10/solo6x10-p2m.c
rename drivers/staging/media/solo6x10/{registers.h = solo6x10-regs.h} (90%)
rename drivers/staging/media/solo6x10/{tw28.c = solo6x10-tw28.c} (84%)
rename drivers/staging/media/solo6x10/{tw28.h = solo6x10-tw28.h} (88%)
create mode 100644
Re: [REVIEW PATCH 01/19] solo6x10: sync to latest code from Bluecherry's git repo.
On Sun March 24 2013 15:27:23 Mauro Carvalho Chehab wrote: Em Mon, 18 Mar 2013 13:32:00 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: From: Hans Verkuil hans.verk...@cisco.com Synced to commit e9815ac5503ae60cfbf6ff8037035de8f62e2846 from branch next in git repository https://github.com/bluecherrydvr/solo6x10.git Only removed some code under #if LINUX_VERSION_CODE some-kernel-version, renamed the driver back to solo6x10 from solo6x10-edge and removed the unnecessary compat.h header. Otherwise the code is identical. ... @@ -21,29 +26,78 @@ #include linux/module.h #include linux/pci.h #include linux/interrupt.h -#include linux/slab.h You can't remove slab.h if any k*alloc function is used, or it will break compilation, depending on the Kconfig options selected. Well spotted, thanks! The same type of removal are on other files inside this patch. Please fix. Done. New pull request posted. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 09/42] sony-btf-mpx: the MPX driver for the sony BTF PAL/SECAM tuner
On Sun March 24 2013 16:21:12 Mauro Carvalho Chehab wrote: Em Mon, 11 Mar 2013 12:45:47 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: From: Hans Verkuil hans.verk...@cisco.com The Sony BTF PG472Z has an internal MPX to deal with mono/stereo/bilingual audio. This is split off from the wis-sony-tuner driver that is part of the go7007 driver as it should be a separate i2c sub-device driver. The wis-sony-tuner is really three i2c devices: a standard tuner, a tda9887 compatible demodulator and this mpx. After this patch the wis-sony-tuner can be replaced by this driver and the standard tuner driver. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/i2c/Kconfig| 11 +- drivers/media/i2c/Makefile |1 + drivers/media/i2c/sony-btf-mpx.c | 399 ++ Not sure what happened, but sony-btf-mpx.c got missed on the version inside the pull request. So, I got it from this patch. Grr. I found the same 'const' issue as you did, fixed it in my tree but forgot to do a git add for the file :-( Sorry. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 12/42] tw9903: add new tw9903 video decoder.
On Sun March 24 2013 16:29:32 Mauro Carvalho Chehab wrote:
Em Mon, 11 Mar 2013 12:45:50 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
From: Hans Verkuil hans.verk...@cisco.com
This based on the wis-tw9903.c driver that's part of the go7007 driver.
It has been converted to a v4l subdev driver by Pete Eberlein, and I made
additional cleanups.
Based on work by: Pete Eberlein p...@sensoray.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Cc: Pete Eberlein p...@sensoray.com
---
drivers/media/i2c/Kconfig | 10 ++
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/tw9903.c | 274
3 files changed, 285 insertions(+)
create mode 100644 drivers/media/i2c/tw9903.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 8000642..eb9ef55 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -301,6 +301,16 @@ config VIDEO_TVP7002
To compile this driver as a module, choose M here: the
module will be called tvp7002.
+config VIDEO_TW9903
+ tristate Techwell TW9903 video decoder
+ depends on VIDEO_V4L2 I2C
+ ---help---
+ Support for the Techwell 9903 multi-standard video decoder
+ with high quality down scaler.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tw9903.
+
config VIDEO_VPX3220
tristate vpx3220a, vpx3216b vpx3214c video decoders
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index b1775b3..af8fb29 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_THS7303) += ths7303.o
obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o
obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o
obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
+obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
obj-$(CONFIG_VIDEO_M52790) += m52790.o
diff --git a/drivers/media/i2c/tw9903.c b/drivers/media/i2c/tw9903.c
new file mode 100644
index 000..82626ea
--- /dev/null
+++ b/drivers/media/i2c/tw9903.c
@@ -0,0 +1,274 @@
+/*
+ * Copyright (C) 2005-2006 Micronas USA Inc.
+ *
+ * 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/init.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include linux/ioctl.h
+#include media/v4l2-device.h
+#include media/v4l2-ctrls.h
+#include linux/slab.h
+
+MODULE_DESCRIPTION(TW9903 I2C subdev driver);
+MODULE_LICENSE(GPL v2);
+
+/*
+ * This driver is based on the wis-tw9903.c source that was in
+ * drivers/staging/media/go7007. That source had commented out code for
+ * saturation and scaling (neither seemed to work). If anyone ever gets
+ * hardware to test this driver, then that code might be useful to look at.
+ * You need to get the kernel sources of, say, kernel 3.8 where that
+ * wis-tw9903 driver is still present.
+ */
+
+struct tw9903 {
+ struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ v4l2_std_id norm;
+};
+
+static inline struct tw9903 *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct tw9903, sd);
+}
+
+static const u8 initial_registers[] = {
+ 0x02, 0x44, /* input 1, composite */
+ 0x03, 0x92, /* correct digital format */
+ 0x04, 0x00,
+ 0x05, 0x80, /* or 0x00 for PAL */
+ 0x06, 0x40, /* second internal current reference */
+ 0x07, 0x02, /* window */
+ 0x08, 0x14, /* window */
+ 0x09, 0xf0, /* window */
+ 0x0a, 0x81, /* window */
+ 0x0b, 0xd0, /* window */
+ 0x0c, 0x8c,
+ 0x0d, 0x00, /* scaling */
+ 0x0e, 0x11, /* scaling */
+ 0x0f, 0x00, /* scaling */
+ 0x10, 0x00, /* brightness */
+ 0x11, 0x60, /* contrast */
+ 0x12, 0x01, /* sharpness */
+ 0x13, 0x7f, /* U gain */
+ 0x14, 0x5a, /* V gain */
+ 0x15, 0x00, /* hue */
+ 0x16, 0xc3, /* sharpness */
+ 0x18, 0x00,
+ 0x19, 0x58, /* vbi */
+ 0x1a, 0x80,
+ 0x1c, 0x0f, /* video norm */
+ 0x1d, 0x7f, /* video norm */
+ 0x20, 0xa0, /* clamping gain (working 0x50) */
+ 0x21, 0x22,
+ 0x22, 0xf0,
+ 0x23, 0xfe,
+ 0x24,
Re: [REVIEW PATCH 19/42] s2250-loader: use usbv2_cypress_load_firmware
On Sun March 24 2013 16:39:24 Mauro Carvalho Chehab wrote: Em Mon, 11 Mar 2013 12:45:57 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: From: Hans Verkuil hans.verk...@cisco.com The v2 of this function doesn't do DMA to objects on the stack like its predecessor does. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/staging/media/go7007/Makefile |4 ++-- drivers/staging/media/go7007/s2250-loader.c |7 --- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/staging/media/go7007/Makefile b/drivers/staging/media/go7007/Makefile index 5bed78b..f9c8e0f 100644 --- a/drivers/staging/media/go7007/Makefile +++ b/drivers/staging/media/go7007/Makefile @@ -11,8 +11,8 @@ s2250-y := s2250-board.o #obj-$(CONFIG_VIDEO_SAA7134) += saa7134-go7007.o #ccflags-$(CONFIG_VIDEO_SAA7134:m=y) += -Idrivers/media/video/saa7134 -DSAA7134_MPEG_GO7007=3 -# S2250 needs cypress ezusb loader from dvb-usb -ccflags-$(CONFIG_VIDEO_GO7007_USB_S2250_BOARD:m=y) += -Idrivers/media/usb/dvb-usb +# S2250 needs cypress ezusb loader from dvb-usb-v2 +ccflags-$(CONFIG_VIDEO_GO7007_USB_S2250_BOARD:m=y) += -Idrivers/media/usb/dvb-usb-v2 Please don't do it like that. Ok, for now it is in staging, but once you move it outside it, please move the cypress load firmware code to drivers/media/common, and do the proper changes for it to be shared between go7007 and dvb-usb-v2. It's a good idea to move this to common. I'll do that. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.10] go7007 driver overhaul
On Sun March 24 2013 17:13:40 Mauro Carvalho Chehab wrote: Em Fri, 22 Mar 2013 15:36:35 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: Hi all, This pull request updates the staging go7007 driver to the latest V4L2 frameworks and actually makes it work reliably. This pull request assumes that pull request http://patchwork.linuxtv.org/patch/17568/ was merged first. Some highlights: - moved the custom i2c drivers to media/i2c. - replaced the s2250-loader by a common loader for all the supported devices. - replaced all MPEG-related custom ioctls by standard ioctls and FMT support. - added the saa7134-go7007 combination (similar to the saa7134-empress). - added support for ADS Tech DVD Xpress DX2. In addition I've made some V4L2 core and saa7115 changes (the first 7 patches): - eliminate false lockdep warnings when dealing with nested control handlers. This patch is a slightly modified version from the one Andy posted a long time ago. - add support to easily test if any subdevices support a particular operation. - fix a few bugs in the code that tests if an ioctl is available: it didn't take 'disabling of ioctls' into account. - added additional configuration flags to saa7115, needed by the go7007. - improved querystd support in saa7115. This driver now passes all v4l2-compliance tests. It has been tested with: - Plextor PX-TV402U (PAL model) - Sensoray S2250S (generously provided by Sensoray, all audio inputs now work!) - Sensoray Model 614 (saa7134+go7007 PCI board, generously provided by Sensoray) - WIS X-Men II sensor board (generously provided by Sensoray) - Adlink PCI-MPG24 surveillance board - ADS Tech DVD Xpress DX2 Everything seems to work OK, but for two things: - the WIS X-Men and tthe S2250 do not honor requested frameperiod changes using S_PARM. The others work fine, and I have no idea why these work differently. - the bttv part of the Adlink card doesn't work for me: I just get black with fuzzy lines. This doesn't work in 3.8 either, so I don't know what's going on here. It's not related to my patch series, that's for sure. What needs to be done to get this driver out of staging? The main thing is the motion detection support. Volokh has some additional code for that, and I want to experiment with motion detection for this card and the solo6x10 card and see if I can come up with a nice API for that. It would also be nice to get the s2250-board.c code make use of the already existing i2c devices, but it is hooked up somewhat strangely, so I need to look at that some day. Regarding the firmware: they are available here: http://git.linuxtv.org/hverkuil/linux-firmware.git/shortlog/refs/heads/go7007 All firmwares relating to this driver have been collected in the go7007 directory with correct licensing. Note that this means that the s2250 firmwares have been renamed. Should this be an issue I can change this back and leave those files where they are today, but since the go7007 firmware files were never included in linux-firmware (and therefor the driver never worked with just linux-firmware) and because it is still a staging driver I thought it cleaner to have all firmware files in one place. Mauro, when should I make a pull request for the linux-firmware changes? After you have merged this pull request? In the meantime, the firmware files are also available here: http://hverkuil.home.xs4all.nl/go7007-fw.tar.bz2 Just unpack in /lib/firmware. Regards, Hans The following changes since commit 8bf1a5a826d06a9b6f65b3e8dffb9be59d8937c3: v4l2-ioctl: add precision when printing names. (2013-03-22 11:59:21 +0100) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git go7007 for you to fetch changes up to 651f19e2186eb92393296717afaa7fc0873d6c2f: go7007: add support for ADS Tech DVD Xpress DX2 (2013-03-22 15:20:46 +0100) Andy Walls (1): v4l2-ctrls: eliminate lockdep false alarms for struct v4l2_ctrl_handler.lock Hans Verkuil (47): v4l2-core: add code to check for specific ops. v4l2-ioctl: check if an ioctl is valid. v4l2-ctrls: add V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER control saa7115: add config flag to change the IDQ polarity. saa7115: improve querystd handling for the saa7115. saa7115: add support for double-rate ASCLK go7007: fix i2c_xfer return codes. tuner: add Sony BTF tuners sony-btf-mpx: the MPX driver for the sony BTF PAL/SECAM tuner ov7640: add new ov7640 driver uda1342: add new uda1342 audio codec driver tw9903: add new tw9903 video decoder. tw2804: add support for the Techwell tw2804. go7007: switch to
Re: [GIT PULL FOR v3.10] au0828 driver overhaul
On Sun March 24 2013 18:55:50 Devin Heitmueller wrote:
On Sun, Mar 24, 2013 at 1:51 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
drivers/media/dvb-frontends/au8522_decoder.c:static int
au8522_g_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt)
drivers/media/dvb-frontends/au8522_decoder.c-{
drivers/media/dvb-frontends/au8522_decoder.c- int val = 0;
drivers/media/dvb-frontends/au8522_decoder.c- struct au8522_state
*state = to_state(sd);
drivers/media/dvb-frontends/au8522_decoder.c- u8 lock_status;
drivers/media/dvb-frontends/au8522_decoder.c-
drivers/media/dvb-frontends/au8522_decoder.c- /* Interrogate the
decoder to see if we are getting a real signal */
drivers/media/dvb-frontends/au8522_decoder.c- lock_status =
au8522_readreg(state, 0x00);
drivers/media/dvb-frontends/au8522_decoder.c- if (lock_status == 0xa2)
drivers/media/dvb-frontends/au8522_decoder.c- vt-signal =
0x;
drivers/media/dvb-frontends/au8522_decoder.c- else
drivers/media/dvb-frontends/au8522_decoder.c- vt-signal = 0x00;
drivers/media/dvb-frontends/au8522_decoder.c-
drivers/media/dvb-frontends/au8522_decoder.c- vt-capability |=
drivers/media/dvb-frontends/au8522_decoder.c-
V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_LANG1 |
drivers/media/dvb-frontends/au8522_decoder.c-
V4L2_TUNER_CAP_LANG2 | V4L2_TUNER_CAP_SAP;
drivers/media/dvb-frontends/au8522_decoder.c-
drivers/media/dvb-frontends/au8522_decoder.c- val = V4L2_TUNER_SUB_MONO;
drivers/media/dvb-frontends/au8522_decoder.c- vt-rxsubchans = val;
drivers/media/dvb-frontends/au8522_decoder.c- vt-audmode =
V4L2_TUNER_MODE_STEREO;
drivers/media/dvb-frontends/au8522_decoder.c- return 0;
As if the i2c gate is on a wrong state, au8522_readreg() won't
work anymore.
Note that au8522_g_tuner function never actually talks to the tuner.
It's handled entirely within the au8522 driver, which is not behind
the gate. The I2C gate is only required if talking to the xc5000, not
the au8522.
There's something else broken here. I suspect it's probably some
artifact of the conversion to the new control framework (if I had to
guess).
Rather than guessing I'll be doing some testing this week. It could also be
a crappy antenna connection as that's been giving me some grief lately (due
to an unholy BNC-to-F-connector-to-coax adapter chain).
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: lirc: remove dead code
lirc uses the CONFIG_SA1100_BITSY Kconfig macro. But its Kconfig symbol
was removed in v2.4.13. So we can remove a few lines of dead code.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested, but of rather low risk. Note that support for the
machine_is_bitsy() macro was already removed in v2.4.10.
drivers/staging/media/lirc/lirc_sir.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_sir.c
b/drivers/staging/media/lirc/lirc_sir.c
index 63a554c..f781c53 100644
--- a/drivers/staging/media/lirc/lirc_sir.c
+++ b/drivers/staging/media/lirc/lirc_sir.c
@@ -787,12 +787,6 @@ static int init_hardware(void)
spin_lock_irqsave(hardware_lock, flags);
/* reset UART */
#ifdef LIRC_ON_SA1100
-#ifdef CONFIG_SA1100_BITSY
- if (machine_is_bitsy()) {
- pr_info(Power on IR module\n);
- set_bitsy_egpio(EGPIO_BITSY_IR_ON);
- }
-#endif
#ifdef CONFIG_SA1100_COLLIE
sa1100_irda_set_power_collie(3);/* power on */
#endif
@@ -942,10 +936,6 @@ static void drop_hardware(void)
Ser2UTCR3 = sr.utcr3;
Ser2HSCR0 = sr.hscr0;
-#ifdef CONFIG_SA1100_BITSY
- if (machine_is_bitsy())
- clr_bitsy_egpio(EGPIO_BITSY_IR_ON);
-#endif
#ifdef CONFIG_SA1100_COLLIE
sa1100_irda_set_power_collie(0);/* power off */
#endif
--
1.7.11.7
--
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] staging: lirc: remove dead code
Just found that the exactly the same patch has been posted a while ago:
http://driverdev.linuxdriverproject.org/pipermail/devel/2012-November/033623.html
On 3/25/13, Paul Bolle pebo...@tiscali.nl wrote:
lirc uses the CONFIG_SA1100_BITSY Kconfig macro. But its Kconfig symbol
was removed in v2.4.13. So we can remove a few lines of dead code.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested, but of rather low risk. Note that support for the
machine_is_bitsy() macro was already removed in v2.4.10.
drivers/staging/media/lirc/lirc_sir.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_sir.c
b/drivers/staging/media/lirc/lirc_sir.c
index 63a554c..f781c53 100644
--- a/drivers/staging/media/lirc/lirc_sir.c
+++ b/drivers/staging/media/lirc/lirc_sir.c
@@ -787,12 +787,6 @@ static int init_hardware(void)
spin_lock_irqsave(hardware_lock, flags);
/* reset UART */
#ifdef LIRC_ON_SA1100
-#ifdef CONFIG_SA1100_BITSY
- if (machine_is_bitsy()) {
- pr_info(Power on IR module\n);
- set_bitsy_egpio(EGPIO_BITSY_IR_ON);
- }
-#endif
#ifdef CONFIG_SA1100_COLLIE
sa1100_irda_set_power_collie(3);/* power on */
#endif
@@ -942,10 +936,6 @@ static void drop_hardware(void)
Ser2UTCR3 = sr.utcr3;
Ser2HSCR0 = sr.hscr0;
-#ifdef CONFIG_SA1100_BITSY
- if (machine_is_bitsy())
- clr_bitsy_egpio(EGPIO_BITSY_IR_ON);
-#endif
#ifdef CONFIG_SA1100_COLLIE
sa1100_irda_set_power_collie(0);/* power off */
#endif
--
1.7.11.7
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
--
Regards,
Denis
--
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] staging: lirc: remove dead code
On Mon, 2013-03-25 at 13:40 +0400, Denis Kirjanov wrote: Just found that the exactly the same patch has been posted a while ago: http://driverdev.linuxdriverproject.org/pipermail/devel/2012-November/033623.html Thanks for that. Is that previous patch queued somewhere? Paul Bolle -- 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] staging: lirc: remove dead code
Greg, looks like you have missed it in the queue for 3.8-rc1 On 3/25/13, Paul Bolle pebo...@tiscali.nl wrote: On Mon, 2013-03-25 at 13:40 +0400, Denis Kirjanov wrote: Just found that the exactly the same patch has been posted a while ago: http://driverdev.linuxdriverproject.org/pipermail/devel/2012-November/033623.html Thanks for that. Is that previous patch queued somewhere? Paul Bolle -- Regards, Denis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.10] go7007 updates
Hi Mauro, This pull request takes care of some remaining go7007 changes. Besides the patches posted by Sachin, Chen and Volokh I've applied the three remaining patches from my ealier go7007 patch series: - patch saa7134-go7007.c and include the remaining saa7134 patch to the README. - update the register tables in tw9603/6.c as you suggested. - add the 'don't continue if firmware can't be loaded.' patch that was skipped earlier. I will post the patch that moves cypress-firmware to media/common separately. pwclient update -s 'accepted' 17599 pwclient update -s 'accepted' 17600 pwclient update -s 'accepted' 17598 The patch from Volokh was posted here: http://www.spinics.net/lists/linux-media/msg61607.html but patchwork missed it, probably due to the mangled subject line. Regards, Hans The following changes since commit b781e6be79a394cd6980e9cd8fd5c25822d152b6: [media] sony-btf-mpx: v4l2_tuner struct is now constant (2013-03-24 14:04:34 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git go7007-updates for you to fetch changes up to 82799d7b0d2cc480982b422d10a9191a532adbfb: tw2804: Revert ADC Control commit 523a4f7fbcf856fb1c2a4850f44edea6738ee37b (2013-03-25 11:05:29 +0100) Chen Gang (1): go7007: using strlcpy instead of strncpy Hans Verkuil (4): saa7134-go7007: convert to a subdev and the control framework go7007: update the README go7007: don't continue if firmware can't be loaded. tw9603/6.c: use two separate const tables for the 50/60hz setup. Sachin Kamat (2): tw9906: Remove unneeded version.h header include go7007: Remove unneeded version.h header include Volokh Konstantin (1): tw2804: Revert ADC Control commit 523a4f7fbcf856fb1c2a4850f44edea6738ee37b drivers/media/i2c/tw2804.c| 17 +-- drivers/media/i2c/tw9903.c| 19 +--- drivers/media/i2c/tw9906.c| 20 +--- drivers/staging/media/go7007/Makefile |2 +- drivers/staging/media/go7007/README | 142 +++ drivers/staging/media/go7007/go7007-usb.c | 76 +++--- drivers/staging/media/go7007/go7007-v4l2.c|1 - drivers/staging/media/go7007/saa7134-go7007.c | 151 ++- 8 files changed, 288 insertions(+), 140 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
Re: [PATCH 1/2] media: davinci: vpss: enable vpss clocks
Hi Sekhar,
Thanks for the review!
On Mon, Mar 25, 2013 at 11:02 AM, Sekhar Nori nsek...@ti.com wrote:
On 3/22/2013 1:23 PM, Prabhakar lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
By default the VPSS clocks are only enabled in capture driver
for davinci family which creates duplicates. This
patch adds support to enable the VPSS clocks in VPSS driver.
This avoids duplication of code and also adding clock aliases.
This patch cleanups the VPSS clock enabling in the capture driver,
and also removes the clock alias in machine file. Along side adds
a vpss slave clock for DM365 as mentioned by Sekhar
(https://patchwork.kernel.org/patch/1221261/).
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
arch/arm/mach-davinci/dm355.c|3 -
arch/arm/mach-davinci/dm365.c|9 +++-
arch/arm/mach-davinci/dm644x.c |5 --
drivers/media/platform/davinci/dm355_ccdc.c | 39 +
drivers/media/platform/davinci/dm644x_ccdc.c | 44 ---
drivers/media/platform/davinci/isif.c| 28 ++--
drivers/media/platform/davinci/vpss.c| 60
++
7 files changed, 72 insertions(+), 116 deletions(-)
static struct clk arm_clk = {
.name = arm_clk,
.parent = pll2_sysclk2,
@@ -450,6 +456,7 @@ static struct clk_lookup dm365_clks[] = {
CLK(NULL, pll2_sysclk9, pll2_sysclk9),
CLK(NULL, vpss_dac, vpss_dac_clk),
CLK(NULL, vpss_master, vpss_master_clk),
+ CLK(NULL, vpss_slave, vpss_slave_clk),
These should use device name for look-up instead of relying just on
con_id. So the entry should look like:
CLK(vpss, slave, vpss_slave_clk),
OK
CLK(NULL, arm, arm_clk),
CLK(NULL, uart0, uart0_clk),
CLK(NULL, uart1, uart1_clk),
@@ -1239,8 +1246,6 @@ static int __init dm365_init_devices(void)
clk_add_alias(NULL, dev_name(dm365_mdio_device.dev),
NULL, dm365_emac_device.dev);
- /* Add isif clock alias */
- clk_add_alias(master, dm365_isif_dev.name, vpss_master, NULL);
platform_device_register(dm365_vpss_device);
platform_device_register(dm365_isif_dev);
platform_device_register(vpfe_capture_dev);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index ee0e994..026e7e3 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -901,11 +901,6 @@ int __init dm644x_init_video(struct vpfe_config
*vpfe_cfg,
dm644x_vpfe_dev.dev.platform_data = vpfe_cfg;
platform_device_register(dm644x_ccdc_dev);
platform_device_register(dm644x_vpfe_dev);
- /* Add ccdc clock aliases */
- clk_add_alias(master, dm644x_ccdc_dev.name,
- vpss_master, NULL);
- clk_add_alias(slave, dm644x_ccdc_dev.name,
- vpss_slave, NULL);
}
if (vpbe_cfg) {
diff --git a/drivers/media/platform/davinci/dm355_ccdc.c
b/drivers/media/platform/davinci/dm355_ccdc.c
index 2364dba..05f8fb7 100644
--- a/drivers/media/platform/davinci/dm355_ccdc.c
+++ b/drivers/media/platform/davinci/dm355_ccdc.c
@@ -37,7 +37,6 @@
#include linux/platform_device.h
#include linux/uaccess.h
#include linux/videodev2.h
-#include linux/clk.h
#include linux/err.h
#include linux/module.h
@@ -59,10 +58,6 @@ static struct ccdc_oper_config {
struct ccdc_params_raw bayer;
/* YCbCr configuration */
struct ccdc_params_ycbcr ycbcr;
- /* Master clock */
- struct clk *mclk;
- /* slave clock */
- struct clk *sclk;
/* ccdc base address */
void __iomem *base_addr;
} ccdc_cfg = {
@@ -997,32 +992,10 @@ static int dm355_ccdc_probe(struct platform_device
*pdev)
goto fail_nomem;
}
- /* Get and enable Master clock */
- ccdc_cfg.mclk = clk_get(pdev-dev, master);
- if (IS_ERR(ccdc_cfg.mclk)) {
- status = PTR_ERR(ccdc_cfg.mclk);
- goto fail_nomap;
- }
- if (clk_prepare_enable(ccdc_cfg.mclk)) {
- status = -ENODEV;
- goto fail_mclk;
- }
-
- /* Get and enable Slave clock */
- ccdc_cfg.sclk = clk_get(pdev-dev, slave);
- if (IS_ERR(ccdc_cfg.sclk)) {
- status = PTR_ERR(ccdc_cfg.sclk);
- goto fail_mclk;
- }
- if (clk_prepare_enable(ccdc_cfg.sclk)) {
- status = -ENODEV;
- goto fail_sclk;
- }
-
/* Platform data holds setup_pinmux function ptr */
if (NULL == pdev-dev.platform_data) {
status = -ENODEV;
- goto fail_sclk;
+ goto fail_nomap;
}
setup_pinmux = pdev-dev.platform_data;
/*
@@ -1033,12 +1006,6 @@ static int dm355_ccdc_probe(struct platform_device
*pdev)
ccdc_cfg.dev = pdev-dev;
Re: [PATCH 2/2] media: davinci: vpbe: venc: move the enabling of vpss clocks to driver
Hi Sekhar, On Mon, Mar 25, 2013 at 11:09 AM, Sekhar Nori nsek...@ti.com wrote: On 3/22/2013 1:23 PM, Prabhakar lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com The vpss clocks were enabled by calling a exported function from a driver in a machine code. calling driver code from platform code is incorrect way. This patch fixes this issue and calls the function from driver code itself. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- Note: This patch is based on the comment from Sekhar (https://patchwork-mail1.kernel.org/patch/2278441/). Shekar I haven't completely removed the callback, I just added the function calls after the callback. As you mentioned just to pass the VPSS_CLK_CTRL as a resource to venc but the VPSS_CLK_CTRL is already being used by VPSS driver. I'll take this cleanup task later point of time. Fine by me. Can I have your ACK on this patch ? Regards, --Prabhakar Thanks, Sekhar -- 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
[REVIEW PATCH] media: move dvb-usb-v2/cypress_firmware.c to media/common.
From: Hans Verkuil hans.verk...@cisco.com
Loading the cypress firmware is not dvb specific and should be common
functionality. Move the source to media/common and make it a standalone
module.
As a result we can remove the dependency on dvb-usb in go7007, which has
nothing to do with dvb.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/common/Kconfig|3 +
drivers/media/common/Makefile |2 +
drivers/media/common/cypress_firmware.c | 132 ++
drivers/media/common/cypress_firmware.h | 28 +
drivers/media/usb/dvb-usb-v2/Kconfig|6 +-
drivers/media/usb/dvb-usb-v2/Makefile |5 +-
drivers/media/usb/dvb-usb-v2/az6007.c |2 +-
drivers/media/usb/dvb-usb-v2/cypress_firmware.c | 133 ---
drivers/media/usb/dvb-usb-v2/cypress_firmware.h | 31 --
drivers/staging/media/go7007/Kconfig|3 +-
drivers/staging/media/go7007/Makefile |6 +-
drivers/staging/media/go7007/go7007-loader.c|4 +-
12 files changed, 173 insertions(+), 182 deletions(-)
create mode 100644 drivers/media/common/cypress_firmware.c
create mode 100644 drivers/media/common/cypress_firmware.h
delete mode 100644 drivers/media/usb/dvb-usb-v2/cypress_firmware.c
delete mode 100644 drivers/media/usb/dvb-usb-v2/cypress_firmware.h
diff --git a/drivers/media/common/Kconfig b/drivers/media/common/Kconfig
index 56c25e6..ba666c7 100644
--- a/drivers/media/common/Kconfig
+++ b/drivers/media/common/Kconfig
@@ -16,6 +16,9 @@ config VIDEO_TVEEPROM
tristate
depends on I2C
+config CYPRESS_FIRMWARE
+ tristate Cypress firmware helper routines
+
source drivers/media/common/b2c2/Kconfig
source drivers/media/common/saa7146/Kconfig
source drivers/media/common/siano/Kconfig
diff --git a/drivers/media/common/Makefile b/drivers/media/common/Makefile
index 8f8d187..2a52a22 100644
--- a/drivers/media/common/Makefile
+++ b/drivers/media/common/Makefile
@@ -2,3 +2,5 @@ obj-y += b2c2/ saa7146/ siano/
obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_CYPRESS_FIRMWARE) += cypress_firmware.o
+
diff --git a/drivers/media/common/cypress_firmware.c
b/drivers/media/common/cypress_firmware.c
new file mode 100644
index 000..577e820
--- /dev/null
+++ b/drivers/media/common/cypress_firmware.c
@@ -0,0 +1,132 @@
+/* cypress_firmware.c is part of the DVB USB library.
+ *
+ * Copyright (C) 2004-6 Patrick Boettcher (patrick.boettc...@desy.de)
+ * see dvb-usb-init.c for copyright information.
+ *
+ * This file contains functions for downloading the firmware to Cypress FX 1
+ * and 2 based devices.
+ *
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/usb.h
+#include linux/firmware.h
+#include cypress_firmware.h
+
+struct usb_cypress_controller {
+ u8 id;
+ const char *name; /* name of the usb controller */
+ u16 cs_reg; /* needs to be restarted,
+* when the firmware has been downloaded */
+};
+
+static const struct usb_cypress_controller cypress[] = {
+ { .id = CYPRESS_AN2135, .name = Cypress AN2135, .cs_reg = 0x7f92 },
+ { .id = CYPRESS_AN2235, .name = Cypress AN2235, .cs_reg = 0x7f92 },
+ { .id = CYPRESS_FX2,.name = Cypress FX2,.cs_reg = 0xe600 },
+};
+
+/*
+ * load a firmware packet to the device
+ */
+static int usb_cypress_writemem(struct usb_device *udev, u16 addr, u8 *data,
+ u8 len)
+{
+ return usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+ 0xa0, USB_TYPE_VENDOR, addr, 0x00, data, len, 5000);
+}
+
+static int cypress_get_hexline(const struct firmware *fw,
+ struct hexline *hx, int *pos)
+{
+ u8 *b = (u8 *) fw-data[*pos];
+ int data_offs = 4;
+
+ if (*pos = fw-size)
+ return 0;
+
+ memset(hx, 0, sizeof(struct hexline));
+ hx-len = b[0];
+
+ if ((*pos + hx-len + 4) = fw-size)
+ return -EINVAL;
+
+ hx-addr = b[1] | (b[2] 8);
+ hx-type = b[3];
+
+ if (hx-type == 0x04) {
+ /* b[4] and b[5] are the Extended linear address record data
+* field */
+ hx-addr |= (b[4] 24) | (b[5] 16);
+ }
+
+ memcpy(hx-data, b[data_offs], hx-len);
+ hx-chk = b[hx-len + data_offs];
+ *pos += hx-len + 5;
+
+ return *pos;
+}
+
+int cypress_load_firmware(struct usb_device *udev,
+ const struct firmware *fw, int type)
+{
+ struct hexline *hx;
+ int ret, pos = 0;
+
+ hx = kmalloc(sizeof(struct hexline), GFP_KERNEL);
+ if (!hx) {
+ dev_err(udev-dev, %s: kmalloc() failed\n, KBUILD_MODNAME);
+ return -ENOMEM;
+ }
+
+ /* stop the CPU */
+ hx-data[0] = 1;
+ ret =
Re: [REVIEW PATCH] media: move dvb-usb-v2/cypress_firmware.c to media/common.
On Mon March 25 2013 11:17:25 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Loading the cypress firmware is not dvb specific and should be common functionality. Move the source to media/common and make it a standalone module. As a result we can remove the dependency on dvb-usb in go7007, which has nothing to do with dvb. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Sorry, I forgot to mention that this applies on top of the go7007 updates I posted a few minutes earlier. The git tree is here: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cypress-common Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: davinci: vpss: enable vpss clocks
On 3/25/2013 3:44 PM, Prabhakar Lad wrote:
Hi Sekhar,
Thanks for the review!
On Mon, Mar 25, 2013 at 11:02 AM, Sekhar Nori nsek...@ti.com wrote:
On 3/22/2013 1:23 PM, Prabhakar lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
By default the VPSS clocks are only enabled in capture driver
for davinci family which creates duplicates. This
patch adds support to enable the VPSS clocks in VPSS driver.
This avoids duplication of code and also adding clock aliases.
This patch cleanups the VPSS clock enabling in the capture driver,
and also removes the clock alias in machine file. Along side adds
a vpss slave clock for DM365 as mentioned by Sekhar
(https://patchwork.kernel.org/patch/1221261/).
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
arch/arm/mach-davinci/dm355.c|3 -
arch/arm/mach-davinci/dm365.c|9 +++-
arch/arm/mach-davinci/dm644x.c |5 --
drivers/media/platform/davinci/dm355_ccdc.c | 39 +
drivers/media/platform/davinci/dm644x_ccdc.c | 44 ---
drivers/media/platform/davinci/isif.c| 28 ++--
drivers/media/platform/davinci/vpss.c| 60
++
7 files changed, 72 insertions(+), 116 deletions(-)
static struct clk arm_clk = {
.name = arm_clk,
.parent = pll2_sysclk2,
@@ -450,6 +456,7 @@ static struct clk_lookup dm365_clks[] = {
CLK(NULL, pll2_sysclk9, pll2_sysclk9),
CLK(NULL, vpss_dac, vpss_dac_clk),
CLK(NULL, vpss_master, vpss_master_clk),
+ CLK(NULL, vpss_slave, vpss_slave_clk),
These should use device name for look-up instead of relying just on
con_id. So the entry should look like:
CLK(vpss, slave, vpss_slave_clk),
OK
CLK(NULL, arm, arm_clk),
CLK(NULL, uart0, uart0_clk),
CLK(NULL, uart1, uart1_clk),
@@ -1239,8 +1246,6 @@ static int __init dm365_init_devices(void)
clk_add_alias(NULL, dev_name(dm365_mdio_device.dev),
NULL, dm365_emac_device.dev);
- /* Add isif clock alias */
- clk_add_alias(master, dm365_isif_dev.name, vpss_master, NULL);
platform_device_register(dm365_vpss_device);
platform_device_register(dm365_isif_dev);
platform_device_register(vpfe_capture_dev);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index ee0e994..026e7e3 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -901,11 +901,6 @@ int __init dm644x_init_video(struct vpfe_config
*vpfe_cfg,
dm644x_vpfe_dev.dev.platform_data = vpfe_cfg;
platform_device_register(dm644x_ccdc_dev);
platform_device_register(dm644x_vpfe_dev);
- /* Add ccdc clock aliases */
- clk_add_alias(master, dm644x_ccdc_dev.name,
- vpss_master, NULL);
- clk_add_alias(slave, dm644x_ccdc_dev.name,
- vpss_slave, NULL);
}
if (vpbe_cfg) {
diff --git a/drivers/media/platform/davinci/dm355_ccdc.c
b/drivers/media/platform/davinci/dm355_ccdc.c
index 2364dba..05f8fb7 100644
--- a/drivers/media/platform/davinci/dm355_ccdc.c
+++ b/drivers/media/platform/davinci/dm355_ccdc.c
@@ -37,7 +37,6 @@
#include linux/platform_device.h
#include linux/uaccess.h
#include linux/videodev2.h
-#include linux/clk.h
#include linux/err.h
#include linux/module.h
@@ -59,10 +58,6 @@ static struct ccdc_oper_config {
struct ccdc_params_raw bayer;
/* YCbCr configuration */
struct ccdc_params_ycbcr ycbcr;
- /* Master clock */
- struct clk *mclk;
- /* slave clock */
- struct clk *sclk;
/* ccdc base address */
void __iomem *base_addr;
} ccdc_cfg = {
@@ -997,32 +992,10 @@ static int dm355_ccdc_probe(struct platform_device
*pdev)
goto fail_nomem;
}
- /* Get and enable Master clock */
- ccdc_cfg.mclk = clk_get(pdev-dev, master);
- if (IS_ERR(ccdc_cfg.mclk)) {
- status = PTR_ERR(ccdc_cfg.mclk);
- goto fail_nomap;
- }
- if (clk_prepare_enable(ccdc_cfg.mclk)) {
- status = -ENODEV;
- goto fail_mclk;
- }
-
- /* Get and enable Slave clock */
- ccdc_cfg.sclk = clk_get(pdev-dev, slave);
- if (IS_ERR(ccdc_cfg.sclk)) {
- status = PTR_ERR(ccdc_cfg.sclk);
- goto fail_mclk;
- }
- if (clk_prepare_enable(ccdc_cfg.sclk)) {
- status = -ENODEV;
- goto fail_sclk;
- }
-
/* Platform data holds setup_pinmux function ptr */
if (NULL == pdev-dev.platform_data) {
status = -ENODEV;
- goto fail_sclk;
+ goto fail_nomap;
}
setup_pinmux = pdev-dev.platform_data;
/*
@@ -1033,12 +1006,6 @@ static int dm355_ccdc_probe(struct platform_device
Re: [PATCH 1/2] media: davinci: vpss: enable vpss clocks
Sekhar,
On Mon, Mar 25, 2013 at 3:54 PM, Sekhar Nori nsek...@ti.com wrote:
On 3/25/2013 3:44 PM, Prabhakar Lad wrote:
Hi Sekhar,
Thanks for the review!
On Mon, Mar 25, 2013 at 11:02 AM, Sekhar Nori nsek...@ti.com wrote:
On 3/22/2013 1:23 PM, Prabhakar lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
By default the VPSS clocks are only enabled in capture driver
for davinci family which creates duplicates. This
patch adds support to enable the VPSS clocks in VPSS driver.
This avoids duplication of code and also adding clock aliases.
This patch cleanups the VPSS clock enabling in the capture driver,
and also removes the clock alias in machine file. Along side adds
a vpss slave clock for DM365 as mentioned by Sekhar
(https://patchwork.kernel.org/patch/1221261/).
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
arch/arm/mach-davinci/dm355.c|3 -
arch/arm/mach-davinci/dm365.c|9 +++-
arch/arm/mach-davinci/dm644x.c |5 --
drivers/media/platform/davinci/dm355_ccdc.c | 39 +
drivers/media/platform/davinci/dm644x_ccdc.c | 44 ---
drivers/media/platform/davinci/isif.c| 28 ++--
drivers/media/platform/davinci/vpss.c| 60
++
7 files changed, 72 insertions(+), 116 deletions(-)
static struct clk arm_clk = {
.name = arm_clk,
.parent = pll2_sysclk2,
@@ -450,6 +456,7 @@ static struct clk_lookup dm365_clks[] = {
CLK(NULL, pll2_sysclk9, pll2_sysclk9),
CLK(NULL, vpss_dac, vpss_dac_clk),
CLK(NULL, vpss_master, vpss_master_clk),
+ CLK(NULL, vpss_slave, vpss_slave_clk),
These should use device name for look-up instead of relying just on
con_id. So the entry should look like:
CLK(vpss, slave, vpss_slave_clk),
OK
CLK(NULL, arm, arm_clk),
CLK(NULL, uart0, uart0_clk),
CLK(NULL, uart1, uart1_clk),
@@ -1239,8 +1246,6 @@ static int __init dm365_init_devices(void)
clk_add_alias(NULL, dev_name(dm365_mdio_device.dev),
NULL, dm365_emac_device.dev);
- /* Add isif clock alias */
- clk_add_alias(master, dm365_isif_dev.name, vpss_master, NULL);
platform_device_register(dm365_vpss_device);
platform_device_register(dm365_isif_dev);
platform_device_register(vpfe_capture_dev);
diff --git a/arch/arm/mach-davinci/dm644x.c
b/arch/arm/mach-davinci/dm644x.c
index ee0e994..026e7e3 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -901,11 +901,6 @@ int __init dm644x_init_video(struct vpfe_config
*vpfe_cfg,
dm644x_vpfe_dev.dev.platform_data = vpfe_cfg;
platform_device_register(dm644x_ccdc_dev);
platform_device_register(dm644x_vpfe_dev);
- /* Add ccdc clock aliases */
- clk_add_alias(master, dm644x_ccdc_dev.name,
- vpss_master, NULL);
- clk_add_alias(slave, dm644x_ccdc_dev.name,
- vpss_slave, NULL);
}
if (vpbe_cfg) {
diff --git a/drivers/media/platform/davinci/dm355_ccdc.c
b/drivers/media/platform/davinci/dm355_ccdc.c
index 2364dba..05f8fb7 100644
--- a/drivers/media/platform/davinci/dm355_ccdc.c
+++ b/drivers/media/platform/davinci/dm355_ccdc.c
@@ -37,7 +37,6 @@
#include linux/platform_device.h
#include linux/uaccess.h
#include linux/videodev2.h
-#include linux/clk.h
#include linux/err.h
#include linux/module.h
@@ -59,10 +58,6 @@ static struct ccdc_oper_config {
struct ccdc_params_raw bayer;
/* YCbCr configuration */
struct ccdc_params_ycbcr ycbcr;
- /* Master clock */
- struct clk *mclk;
- /* slave clock */
- struct clk *sclk;
/* ccdc base address */
void __iomem *base_addr;
} ccdc_cfg = {
@@ -997,32 +992,10 @@ static int dm355_ccdc_probe(struct platform_device
*pdev)
goto fail_nomem;
}
- /* Get and enable Master clock */
- ccdc_cfg.mclk = clk_get(pdev-dev, master);
- if (IS_ERR(ccdc_cfg.mclk)) {
- status = PTR_ERR(ccdc_cfg.mclk);
- goto fail_nomap;
- }
- if (clk_prepare_enable(ccdc_cfg.mclk)) {
- status = -ENODEV;
- goto fail_mclk;
- }
-
- /* Get and enable Slave clock */
- ccdc_cfg.sclk = clk_get(pdev-dev, slave);
- if (IS_ERR(ccdc_cfg.sclk)) {
- status = PTR_ERR(ccdc_cfg.sclk);
- goto fail_mclk;
- }
- if (clk_prepare_enable(ccdc_cfg.sclk)) {
- status = -ENODEV;
- goto fail_sclk;
- }
-
/* Platform data holds setup_pinmux function ptr */
if (NULL == pdev-dev.platform_data) {
status = -ENODEV;
- goto fail_sclk;
+ goto fail_nomap;
}
setup_pinmux = pdev-dev.platform_data;
/*
@@
Re: [PATCH] staging: lirc: remove dead code
Em Mon, 25 Mar 2013 13:59:44 +0400 Denis Kirjanov kirja...@gmail.com escreveu: Greg, looks like you have missed it in the queue for 3.8-rc1 Greg won't likely apply it, as drivers/stating/media is maintained by me. I'll pick it and apply, adding Paul SOB on it. On 3/25/13, Paul Bolle pebo...@tiscali.nl wrote: On Mon, 2013-03-25 at 13:40 +0400, Denis Kirjanov wrote: Just found that the exactly the same patch has been posted a while ago: http://driverdev.linuxdriverproject.org/pipermail/devel/2012-November/033623.html Thanks for that. Is that previous patch queued somewhere? Paul Bolle -- 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: Status of the patches under review at LMML (32 patches)
Hello, On 3/24/2013 7:11 PM, Mauro Carvalho Chehab wrote: This is the summary of the patches that are currently under review at Linux Media Mailing List linux-media@vger.kernel.org. Each patch is represented by its submission date, the subject (up to 70 chars) and the patchwork link (if submitted via email). P.S.: This email is c/c to the developers where some action is expected. If you were copied, please review the patches, acking/nacking or submitting an update. It took me a lot of time to handle patches this time. The good news is that there's just one patch without an owner. ... == Marek Szyprowski m.szyprow...@samsung.com == Nov,12 2012: [media] videobuf2-core: print current state of buffer in vb2_buffer_do http://patchwork.linuxtv.org/patch/15420 Tushar Behera tushar.beh...@linaro.org This one is ok. I acked it by gmane interface as I don't have original mail, I have no Mar, 5 2013: [media] dma-mapping: enable no mmu support in dma_common_mmap http://patchwork.linuxtv.org/patch/17112 Scott Jiang scott.jiang.li...@gmail.com IMHO this one is RFC. I would like to get some more explanation why it is needed and how it will be used. 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: [GIT PULL FOR v3.10] go7007 driver overhaul
Em Mon, 25 Mar 2013 10:02:29 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Sun March 24 2013 17:13:40 Mauro Carvalho Chehab wrote: Em Fri, 22 Mar 2013 15:36:35 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: ... saa7134-go7007: add support for this combination. I won't apply this one yet. A non-staging driver should not try to load a staging one without a notice. That change would be ok if you were also moving go7007 out of staging. Fair enough. I will prepare a patch that at least updates the saa7134-go7007.c source with my changes. That only leaves the patch to saa7134 itself that will need to be applied once this driver goes out of staging. Ok. s2250: add comment describing the hardware. go7007-loader: renamed from s2250-loader go7007-loader: add support for the other devices and move fw files go7007: update the README You need to add there: - move cypress load firmware to drivers/media/common; And some note about saa7134 integration. Would it be OK if I add the saa7134 patch to the go7007 directory? Rather than keeping it around in my git tree? What do you mean? Adding a diff file there? If so, that sounds weird. If you're afraid of losing it, post it at the ML as RFC instead and add a pointer to the patchwork number for such RFC patch at README. MAINTAINERS: add the go7007 driver. go7007: a small improvement to querystd handling. go7007: add back 'repeat sequence header' control. go7007: correct a header check: MPEG4 has a different GOP code. go7007: drop firmware name in board config, make configs const. go7007: don't continue if firmware can't be loaded. This one didn't apply. Maybe due to the lack of saa7134-go7007. Maybe it is just a trivial merging conflict, but better if you could check it before forcing it. Will do. 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: [GIT PULL FOR v3.10] go7007 driver overhaul
Em Mon, 25 Mar 2013 08:06:54 -0300 Mauro Carvalho Chehab mche...@redhat.com escreveu: Em Mon, 25 Mar 2013 10:02:29 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Sun March 24 2013 17:13:40 Mauro Carvalho Chehab wrote: Em Fri, 22 Mar 2013 15:36:35 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: ... saa7134-go7007: add support for this combination. I won't apply this one yet. A non-staging driver should not try to load a staging one without a notice. That change would be ok if you were also moving go7007 out of staging. Fair enough. I will prepare a patch that at least updates the saa7134-go7007.c source with my changes. That only leaves the patch to saa7134 itself that will need to be applied once this driver goes out of staging. Ok. s2250: add comment describing the hardware. go7007-loader: renamed from s2250-loader go7007-loader: add support for the other devices and move fw files go7007: update the README You need to add there: - move cypress load firmware to drivers/media/common; And some note about saa7134 integration. Would it be OK if I add the saa7134 patch to the go7007 directory? Rather than keeping it around in my git tree? What do you mean? Adding a diff file there? If so, that sounds weird. If you're afraid of losing it, post it at the ML as RFC instead and add a pointer to the patchwork number for such RFC patch at README. Never mind. I saw the patch. While it looks a little ugly, I'll apply. 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 2/2] media: davinci: vpbe: venc: move the enabling of vpss clocks to driver
On 3/25/2013 3:45 PM, Prabhakar Lad wrote: Hi Sekhar, On Mon, Mar 25, 2013 at 11:09 AM, Sekhar Nori nsek...@ti.com wrote: On 3/22/2013 1:23 PM, Prabhakar lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com The vpss clocks were enabled by calling a exported function from a driver in a machine code. calling driver code from platform code is incorrect way. This patch fixes this issue and calls the function from driver code itself. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- Note: This patch is based on the comment from Sekhar (https://patchwork-mail1.kernel.org/patch/2278441/). Shekar I haven't completely removed the callback, I just added the function calls after the callback. As you mentioned just to pass the VPSS_CLK_CTRL as a resource to venc but the VPSS_CLK_CTRL is already being used by VPSS driver. I'll take this cleanup task later point of time. Fine by me. Can I have your ACK on this patch ? The 'fine' from me was for the approach, not not patch ;). Seriously though, since this patch is only touching media/ I haven't really done a detailed enough review of it. In any case, it should be OK to merge this without my ack. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] dma-buf: Add support for debugfs
The patch series adds a much-missed support for debugfs to dma-buf framework. Based on the feedback received on v1 of this patch series, support is also added to allow exporters to provide name-strings that will prove useful while debugging. Some more magic can be added for more advanced debugging, but we'll leave that for the time being. Best regards, ~Sumit. Sumit Semwal (2): dma-buf: replace dma_buf_export() with dma_buf_export_named() dma-buf: Add debugfs support Documentation/dma-buf-sharing.txt | 13 ++- drivers/base/dma-buf.c| 173 - include/linux/dma-buf.h | 16 +++- 3 files changed, 193 insertions(+), 9 deletions(-) -- 1.7.10.4 -- 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/2] dma-buf: replace dma_buf_export() with dma_buf_export_named()
For debugging purposes, it is useful to have a name-string added
while exporting buffers. Hence, dma_buf_export() is replaced with
dma_buf_export_named(), which additionally takes 'exp_name' as a
parameter.
For backward compatibility, and for lazy exporters who don't wish to
name themselves, a #define dma_buf_export() is also made available,
which adds a __FILE__ instead of 'exp_name'.
Cc: Daniel Vetter daniel.vet...@ffwll.ch
[Thanks for the idea!]
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
Documentation/dma-buf-sharing.txt | 13 +++--
drivers/base/dma-buf.c| 11 +++
include/linux/dma-buf.h | 11 +--
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 4966b1b..0b23261 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -52,14 +52,23 @@ The dma_buf buffer sharing API usage contains the following
steps:
associated with this buffer.
Interface:
- struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
-size_t size, int flags)
+ struct dma_buf *dma_buf_export_named(void *priv, struct dma_buf_ops *ops,
+size_t size, int flags,
+const char *exp_name)
If this succeeds, dma_buf_export allocates a dma_buf structure, and returns
a
pointer to the same. It also associates an anonymous file with this buffer,
so it can be exported. On failure to allocate the dma_buf object, it returns
NULL.
+ 'exp_name' is the name of exporter - to facilitate information while
+ debugging.
+
+ Exporting modules which do not wish to provide any specific name may use the
+ helper define 'dma_buf_export()', with the same arguments as above, but
+ without the last argument; a __FILE__ pre-processor directive will be
+ inserted in place of 'exp_name' instead.
+
2. Userspace gets a handle to pass around to potential buffer-users
Userspace entity requests for a file-descriptor (fd) which is a handle to
the
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 2a7cb0d..d89102a 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -77,22 +77,24 @@ static inline int is_dma_buf_file(struct file *file)
}
/**
- * dma_buf_export - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
* with this buffer, so it can be exported.
* Also connect the allocator specific data and ops to the buffer.
+ * Additionally, provide a name string for exporter; useful in debugging.
*
* @priv: [in]Attach private data of allocator to this buffer
* @ops: [in]Attach allocator-defined dma buf ops to the new buffer.
* @size: [in]Size of the buffer
* @flags: [in]mode flags for the file.
+ * @exp_name: [in]name of the exporting module - useful for debugging.
*
* Returns, on success, a newly created dma_buf object, which wraps the
* supplied private data and operations for dma_buf_ops. On either missing
* ops, or error in allocating struct dma_buf, will return negative error.
*
*/
-struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops,
- size_t size, int flags)
+struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
+ size_t size, int flags, const char *exp_name)
{
struct dma_buf *dmabuf;
struct file *file;
@@ -114,6 +116,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct
dma_buf_ops *ops,
dmabuf-priv = priv;
dmabuf-ops = ops;
dmabuf-size = size;
+ dmabuf-exp_name = exp_name;
file = anon_inode_getfile(dmabuf, dma_buf_fops, dmabuf, flags);
@@ -124,7 +127,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct
dma_buf_ops *ops,
return dmabuf;
}
-EXPORT_SYMBOL_GPL(dma_buf_export);
+EXPORT_SYMBOL_GPL(dma_buf_export_named);
/**
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 9978b61..6f55c04 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -112,6 +112,7 @@ struct dma_buf_ops {
* @file: file pointer used for sharing buffers across, and for refcounting.
* @attachments: list of dma_buf_attachment that denotes all devices attached.
* @ops: dma_buf_ops associated with this buffer object.
+ * @exp_name: name of the exporter; useful for debugging.
* @priv: exporter specific private data for this buffer object.
*/
struct dma_buf {
@@ -123,6 +124,7 @@ struct dma_buf {
struct mutex lock;
unsigned vmapping_counter;
void *vmap_ptr;
+ const char *exp_name;
void *priv;
};
@@ -162,8 +164,13 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
[PATCH 2/2] dma-buf: Add debugfs support
Add debugfs support to make it easier to print debug information
about the dma-buf buffers.
Cc: Dave Airlie airl...@redhat.com
[minor fixes on init and warning fix]
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
changes since v1:
- fixes on init and warnings as reported and corrected by Dave Airlie.
- add locking while walking attachment list - reported by Daniel Vetter.
drivers/base/dma-buf.c | 162 +++
include/linux/dma-buf.h |5 +-
2 files changed, 166 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index d89102a..7d867ed 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -27,9 +27,18 @@
#include linux/dma-buf.h
#include linux/anon_inodes.h
#include linux/export.h
+#include linux/debugfs.h
+#include linux/seq_file.h
static inline int is_dma_buf_file(struct file *);
+struct dma_buf_list {
+ struct list_head head;
+ struct mutex lock;
+};
+
+static struct dma_buf_list db_list;
+
static int dma_buf_release(struct inode *inode, struct file *file)
{
struct dma_buf *dmabuf;
@@ -42,6 +51,11 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
BUG_ON(dmabuf-vmapping_counter);
dmabuf-ops-release(dmabuf);
+
+ mutex_lock(db_list.lock);
+ list_del(dmabuf-list_node);
+ mutex_unlock(db_list.lock);
+
kfree(dmabuf);
return 0;
}
@@ -125,6 +139,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
mutex_init(dmabuf-lock);
INIT_LIST_HEAD(dmabuf-attachments);
+ mutex_lock(db_list.lock);
+ list_add(dmabuf-list_node, db_list.head);
+ mutex_unlock(db_list.lock);
+
return dmabuf;
}
EXPORT_SYMBOL_GPL(dma_buf_export_named);
@@ -551,3 +569,147 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
mutex_unlock(dmabuf-lock);
}
EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+
+static int dma_buf_init_debugfs(void);
+static void dma_buf_uninit_debugfs(void);
+
+static int __init dma_buf_init(void)
+{
+ mutex_init(db_list.lock);
+ INIT_LIST_HEAD(db_list.head);
+ dma_buf_init_debugfs();
+ return 0;
+}
+
+subsys_initcall(dma_buf_init);
+
+static void __exit dma_buf_deinit(void)
+{
+ dma_buf_uninit_debugfs();
+}
+
+#ifdef CONFIG_DEBUG_FS
+static int dma_buf_describe(struct seq_file *s)
+{
+ int ret;
+ struct dma_buf *buf_obj;
+ struct dma_buf_attachment *attach_obj;
+ int count = 0, attach_count;
+ size_t size = 0;
+
+ ret = mutex_lock_interruptible(db_list.lock);
+
+ if (ret)
+ return ret;
+
+ seq_printf(s, \nDma-buf Objects:\n);
+ seq_printf(s, \texp_name\tsize\tflags\tmode\tcount\n);
+
+ list_for_each_entry(buf_obj, db_list.head, list_node) {
+ ret = mutex_lock_interruptible(buf_obj-lock);
+
+ if (ret) {
+ seq_printf(s,
+ \tERROR locking buffer object: skipping\n);
+ goto skip_buffer;
+ }
+
+ seq_printf(s, \t);
+
+ seq_printf(s, \t%s\t%08zu\t%08x\t%08x\t%08d\n,
+ buf_obj-exp_name, buf_obj-size,
+ buf_obj-file-f_flags, buf_obj-file-f_mode,
+ buf_obj-file-f_count.counter);
+
+ seq_printf(s, \t\tAttached Devices:\n);
+ attach_count = 0;
+
+ list_for_each_entry(attach_obj, buf_obj-attachments, node) {
+ seq_printf(s, \t\t);
+
+ seq_printf(s, %s\n, attach_obj-dev-init_name);
+ attach_count++;
+ }
+
+ seq_printf(s, \n\t\tTotal %d devices attached\n,
+ attach_count);
+
+ count++;
+ size += buf_obj-size;
+skip_buffer:
+ mutex_unlock(buf_obj-lock);
+ }
+
+ seq_printf(s, \nTotal %d objects, %zu bytes\n, count, size);
+
+ mutex_unlock(db_list.lock);
+ return 0;
+}
+
+static int dma_buf_show(struct seq_file *s, void *unused)
+{
+ void (*func)(struct seq_file *) = s-private;
+ func(s);
+ return 0;
+}
+
+static int dma_buf_debug_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, dma_buf_show, inode-i_private);
+}
+
+static const struct file_operations dma_buf_debug_fops = {
+ .open = dma_buf_debug_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
+static struct dentry *dma_buf_debugfs_dir;
+
+static int dma_buf_init_debugfs(void)
+{
+ int err = 0;
+ dma_buf_debugfs_dir = debugfs_create_dir(dma_buf, NULL);
+ if (IS_ERR(dma_buf_debugfs_dir)) {
+ err = PTR_ERR(dma_buf_debugfs_dir);
+ dma_buf_debugfs_dir
Re: [PATCH 3/3] dma-buf: restore args on failure of dma_buf_mmap
On 19 March 2013 05:19, Mauro Carvalho Chehab mche...@redhat.com wrote:
Em Thu, 07 Feb 2013 15:54:52 +0530
Sumit Semwal sumit.sem...@linaro.org escreveu:
Hi John,
On Thursday 07 February 2013 05:33 AM, John Sheu wrote:
From: John Sheu s...@chromium.org
Callers to dma_buf_mmap expect to fput() the vma struct's vm_file
themselves on failure. Not restoring the struct's data on failure
causes a double-decrement of the vm_file's refcount.
Thanks for your patch; could you please re-send it to the correct,
relevant lists and me (as the maintainer of dma-buf) rather than just to
linux-media ml?
Yes, it doesn't make sense to apply this one via the media tree ;)
I'm applying patches 1 and 2, as they should go through the media tree.
Sure, this patch is already in mainline as of 3.9-rc1 :)
Thanks!
Mauro
I just chanced to see this patch, otherwise it could easily have slipped
past me (and other interested parties).
You could run scripts/get_maintainer.pl on your patch to find out the
right lists / email IDs to CC.
Thanks and best regards,
~Sumit.
Signed-off-by: John Sheu s...@google.com
---
drivers/base/dma-buf.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..01daf9c 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -446,6 +446,9 @@ EXPORT_SYMBOL_GPL(dma_buf_kunmap);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
+ struct file *oldfile;
+ int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -459,14 +462,21 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
return -EINVAL;
/* readjust the vma */
- if (vma-vm_file)
- fput(vma-vm_file);
-
+ oldfile = vma-vm_file;
vma-vm_file = get_file(dmabuf-file);
vma-vm_pgoff = pgoff;
- return dmabuf-ops-mmap(dmabuf, vma);
+ ret = dmabuf-ops-mmap(dmabuf, vma);
+ if (ret) {
+ /* restore old parameters on failure */
+ vma-vm_file = oldfile;
+ fput(dmabuf-file);
+ } else {
+ if (oldfile)
+ fput(oldfile);
+ }
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_mmap);
--
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
--
Cheers,
Mauro
--
Thanks and regards,
Sumit Semwal
Linaro Kernel Engineer - Graphics working group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
[REVIEW PATCH] tuner-core fix for au0828 g_tuner bug
While testing the au0828 driver overhaul patch series:
http://patchwork.linuxtv.org/patch/17576/
I discovered that the signal strength as reported by VIDIOC_G_TUNER was
always 0. Initially I thought it was related to the i2c gate, but after
testing some more that turned out to be wrong, although it did gave me the
clue that it was related to the order in which subdevs were called. If
the g_tuner op of au8522 was called before that of tuner-core, then it would
fail, if the order was the other way around then it would work.
Some digging in tuner-core clarified it: if the has_signal callback is set,
then tuner-core would call 'vt-signal = analog_ops-has_signal(t-fe);'.
But has_signal is always filled in, even if the frontend doesn't implement
get_rf_strength, as is the case for the xc5000. And in that case vt-signal
is overwritten with 0.
Solution: don't set the has_signal callback if get_rf_strength is not
supported. Ditto for get_afc.
Regards,
Hans
patch --
If the tuner frontend does not support get_rf_strength, then don't set
the has_signal callback. Ditto for get_afc.
Both callbacks overwrite the signal and afc fields of struct v4l2_tuner
but that should only happen if the tuner can actually detect this. If
it can't, then it should leave those fields alone so other subdevices
can try and detect the signal/afc.
This fixes the bug where the au8522 detected a signal and then tuner-core
overwrote it with 0 since the xc5000 tuner does not support get_rf_strength.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/tuner-core.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index f775768..dd8a803 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -253,7 +253,7 @@ static int fe_set_config(struct dvb_frontend *fe, void
*priv_cfg)
static void tuner_status(struct dvb_frontend *fe);
-static struct analog_demod_ops tuner_analog_ops = {
+static const struct analog_demod_ops tuner_analog_ops = {
.set_params = fe_set_params,
.standby= fe_standby,
.has_signal = fe_has_signal,
@@ -453,6 +453,11 @@ static void set_type(struct i2c_client *c, unsigned int
type,
memcpy(analog_ops, tuner_analog_ops,
sizeof(struct analog_demod_ops));
+ if (fe_tuner_ops-get_rf_strength == NULL)
+ analog_ops-has_signal = NULL;
+ if (fe_tuner_ops-get_afc == NULL)
+ analog_ops-get_afc = NULL;
+
} else {
t-name = analog_ops-info.name;
}
--
1.7.10.4
--
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: [review patch] radio-mr800: move clamp_t check inside amradio_set_freq()
On Thu March 14 2013 23:12:06 Alexey Klimov wrote: Hi Hans, all, If i run verbose v4l2-compliance with my radio-mr800 device few times then i get warning about frequency out of range: Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans root@machine:~# v4l2-compliance -r /dev/radio0 -v 2 is radio Driver Info: Driver name : radio-mr800 Card type : AverMedia MR 800 USB FM Radio Bus info : usb-:00:1a.0-1.2 Driver version: 3.9.0 Capabilities : 0x80050400 Tuner Radio Device Capabilities Device Caps : 0x00050400 Tuner Radio Compliance test for device /dev/radio0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second radio open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK Debug ioctls: test VIDIOC_DBG_G_CHIP_IDENT: OK (Not Supported) test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK Input ioctls: test VIDIOC_G/S_TUNER: OK warn: v4l2-test-input-output.cpp(234): returned tuner 0 frequency out of range (6550200 not in [140...1728000]) test VIDIOC_G/S_FREQUENCY: OK test VIDIOC_S_HW_FREQ_SEEK: OK test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 1 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Control ioctls: info: checking v4l2_queryctrl of control 'User Controls' (0x00980001) info: checking v4l2_queryctrl of control 'Mute' (0x00980909) info: checking v4l2_queryctrl of control 'Mute' (0x00980909) test VIDIOC_QUERYCTRL/MENU: OK info: checking control 'User Controls' (0x00980001) info: checking control 'Mute' (0x00980909) test VIDIOC_G/S_CTRL: OK info: checking extended control 'User Controls' (0x00980001) info: checking extended control 'Mute' (0x00980909) test VIDIOC_G/S/TRY_EXT_CTRLS: OK info: checking control event 'User Controls' (0x00980001) info: checking control event 'Mute' (0x00980909) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 2 Private Controls: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_PRESETS: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported) test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK (Not Supported) test VIDIOC_TRY_FMT: OK (Not Supported) test VIDIOC_S_FMT: OK (Not Supported) test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported) Total: 38, Succeeded: 38, Failed: 0, Warnings: 1 Some printk() debugging showed that vidioc_s_hw_freq_seek() setups radio-curfreq to out of range value (lines 395-396) and calls amradio_set_freq() to set this frequency on device without any out-of-range checks. I suggest to move clamp_t check inside amradio_set_freq() function. It will protect from setting up frequency to incorrect values in different places. It also makes compliance test happy. If this fix is right may be it necessary to push this patch in 3.9 current development tree. radio-mr800: move clamp_t check inside amradio_set_freq() Patch protects from setting up frequency on device to incorrect value moving clamp_t check inside amradio_set_freq. With this patch we can call amradio_set_freq() with out of range frequency from any place. Also put comment that sometimes radio-curfreq is set to out of range value in vidioc_s_hw_freq_seek(). Signed-off-by: Alexey Klimov klimov.li...@gmail.com diff --git a/drivers/media/radio/radio-mr800.c b/drivers/media/radio/radio-mr800.c index 9c5a267..1cbdbfd 100644 --- a/drivers/media/radio/radio-mr800.c +++ b/drivers/media/radio/radio-mr800.c @@ -203,10
[GIT PULL FOR v3.10] Two fixes
These two patches were part of this patch series: http://www.mail-archive.com/linux-media@vger.kernel.org/msg59894.html But I decided to split them off since they have nothing to do with the new chip_name ioctl. Regards, Hans The following changes since commit c535cc6c714bd21b3afad35baa926b3b9eb51361: [media] staging: lirc_sir: remove dead code (2013-03-25 08:21:20 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git fixes for you to fetch changes up to 54957d2a4225d22cf6014399f88e91b794f44522: DocBook media: fix syntax problems in dvbproperty.xml (2013-03-25 12:50:42 +0100) Hans Verkuil (2): v4l2-common: remove obsolete check for ' at the end of a driver name. DocBook media: fix syntax problems in dvbproperty.xml Documentation/DocBook/media/dvb/dvbproperty.xml | 46 ++ drivers/media/v4l2-core/v4l2-common.c |3 --- 2 files changed, 22 insertions(+), 27 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
[GIT PULL FOR v3.10] Add VIDIOC_DBG_G_CHIP_NAME
This pull request is identical to: http://www.mail-archive.com/linux-media@vger.kernel.org/msg59894.html except for rebasing and adding the last DocBook change that documents that this ioctl was added. The first two patches in that patch series are in their own pull request, since those two have nothing to do with adding VIDIOC_DBG_G_CHIP_NAME. This pull request implements this proposal: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/61539 and allows us to simplify the debugging support in drivers, and to eventually get rid of v4l2-chip-ident.h, which is pretty ugly. The other major advantage is that it allows us to access subdevices directly, without requiring code in the bridge driver. And to access non-i2c subdevices, which is something that was not possible before. Once this is in drivers can be simplified until chip_ident is no longer used and everything related to that can be removed. Regards, Hans The following changes since commit c535cc6c714bd21b3afad35baa926b3b9eb51361: [media] staging: lirc_sir: remove dead code (2013-03-25 08:21:20 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git chipid for you to fetch changes up to 8573013a20e83e68a420d68779eca96cac0cf2c4: DocBook media: document 3.10 changes. (2013-03-25 13:04:07 +0100) Hans Verkuil (5): v4l2: add new VIDIOC_DBG_G_CHIP_NAME ioctl. stk1160: remove V4L2_CHIP_MATCH_AC97 placeholder. em28xx: add support for g_chip_name. DocBook media: add VIDIOC_DBG_G_CHIP_NAME documentation DocBook media: document 3.10 changes. Documentation/DocBook/media/v4l/compat.xml |4 ++ Documentation/DocBook/media/v4l/v4l2.xml|8 +-- Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml | 14 +++- Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-name.xml | 234 ++ Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml | 42 +--- drivers/media/usb/em28xx/em28xx-video.c | 41 ++-- drivers/media/usb/stk1160/stk1160-v4l.c |7 +- drivers/media/v4l2-core/v4l2-common.c |5 +- drivers/media/v4l2-core/v4l2-dev.c |5 +- drivers/media/v4l2-core/v4l2-ioctl.c| 115 ++-- include/media/v4l2-ioctl.h |3 + include/uapi/linux/videodev2.h | 34 +++--- 12 files changed, 467 insertions(+), 45 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-name.xml -- 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: [REVIEW PATCH] tuner-core fix for au0828 g_tuner bug
Em Mon, 25 Mar 2013 12:32:31 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
While testing the au0828 driver overhaul patch series:
http://patchwork.linuxtv.org/patch/17576/
I discovered that the signal strength as reported by VIDIOC_G_TUNER was
always 0. Initially I thought it was related to the i2c gate, but after
testing some more that turned out to be wrong, although it did gave me the
clue that it was related to the order in which subdevs were called. If
the g_tuner op of au8522 was called before that of tuner-core, then it would
fail, if the order was the other way around then it would work.
Some digging in tuner-core clarified it: if the has_signal callback is set,
then tuner-core would call 'vt-signal = analog_ops-has_signal(t-fe);'.
But has_signal is always filled in, even if the frontend doesn't implement
get_rf_strength, as is the case for the xc5000. And in that case vt-signal
is overwritten with 0.
Solution: don't set the has_signal callback if get_rf_strength is not
supported. Ditto for get_afc.
It looks OK to me.
Regards,
Hans
patch --
If the tuner frontend does not support get_rf_strength, then don't set
the has_signal callback. Ditto for get_afc.
Both callbacks overwrite the signal and afc fields of struct v4l2_tuner
but that should only happen if the tuner can actually detect this. If
it can't, then it should leave those fields alone so other subdevices
can try and detect the signal/afc.
This fixes the bug where the au8522 detected a signal and then tuner-core
overwrote it with 0 since the xc5000 tuner does not support get_rf_strength.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/tuner-core.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index f775768..dd8a803 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -253,7 +253,7 @@ static int fe_set_config(struct dvb_frontend *fe, void
*priv_cfg)
static void tuner_status(struct dvb_frontend *fe);
-static struct analog_demod_ops tuner_analog_ops = {
+static const struct analog_demod_ops tuner_analog_ops = {
.set_params = fe_set_params,
.standby= fe_standby,
.has_signal = fe_has_signal,
@@ -453,6 +453,11 @@ static void set_type(struct i2c_client *c, unsigned int
type,
memcpy(analog_ops, tuner_analog_ops,
sizeof(struct analog_demod_ops));
+ if (fe_tuner_ops-get_rf_strength == NULL)
+ analog_ops-has_signal = NULL;
+ if (fe_tuner_ops-get_afc == NULL)
+ analog_ops-get_afc = NULL;
+
} else {
t-name = analog_ops-info.name;
}
--
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 v2 1/5] em28xx: add support for em25xx i2c bus B read/write/check device operations
Em Sun, 24 Mar 2013 22:14:58 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 24.03.2013 15:02, schrieb Mauro Carvalho Chehab:
Em Sun, 24 Mar 2013 13:53:40 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 24.03.2013 12:38, schrieb Mauro Carvalho Chehab:
Em Sat, 23 Mar 2013 18:27:08 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
The webcam SpeedLink VAD Laplace (em2765 + ov2640) uses a special
algorithm
for i2c communication with the sensor, which is connected to a second
i2c bus.
We don't know yet how to find out which devices support/use it.
It's very likely used by all em25xx and em276x+ bridges.
Tests with other em28xx chips (em2820, em2882/em2883) show, that this
algorithm always succeeds there although no slave device is connected.
The algorithm likely also works for real i2c client devices (OV2640 uses
SCCB),
because the Windows driver seems to use it for probing Samsung and Kodak
sensors.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c |8 +-
drivers/media/usb/em28xx/em28xx-i2c.c | 229
+--
drivers/media/usb/em28xx/em28xx.h | 10 +-
3 Dateien geändert, 205 Zeilen hinzugefügt(+), 42 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index cb7cdd3..033b6cb 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3139,15 +3139,19 @@ static int em28xx_init_dev(struct em28xx *dev,
struct usb_device *udev,
rt_mutex_init(dev-i2c_bus_lock);
/* register i2c bus 0 */
-retval = em28xx_i2c_register(dev, 0);
+if (dev-board.is_em2800)
+retval = em28xx_i2c_register(dev, 0,
EM28XX_I2C_ALGO_EM2800);
+else
+retval = em28xx_i2c_register(dev, 0,
EM28XX_I2C_ALGO_EM28XX);
if (retval 0) {
em28xx_errdev(%s: em28xx_i2c_register bus 0 - error
[%d]!\n,
__func__, retval);
goto unregister_dev;
}
+/* register i2c bus 1 */
if (dev-def_i2c_bus) {
-retval = em28xx_i2c_register(dev, 1);
+retval = em28xx_i2c_register(dev, 1,
EM28XX_I2C_ALGO_EM28XX);
if (retval 0) {
em28xx_errdev(%s: em28xx_i2c_register bus 1 -
error [%d]!\n,
__func__, retval);
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 9e2fa41..ab14ac3 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -5,6 +5,7 @@
Markus Rechberger mrechber...@gmail.com
Mauro Carvalho Chehab mche...@infradead.org
Sascha Sommer saschasom...@freenet.de
+ Copyright (C) 2013 Frank Schäfer fschaefer@googlemail.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
@@ -274,6 +275,176 @@ static int em28xx_i2c_check_for_device(struct
em28xx *dev, u16 addr)
}
/*
+ * em25xx_bus_B_send_bytes
+ * write bytes to the i2c device
+ */
+static int em25xx_bus_B_send_bytes(struct em28xx *dev, u16 addr, u8
*buf,
+ u16 len)
+{
+int ret;
+
+if (len 1 || len 64)
+return -EOPNOTSUPP;
+/* NOTE: limited by the USB ctrl message constraints
+ * Zero length reads always succeed, even if no device is
connected */
+
+/* Set register and write value */
+ret = dev-em28xx_write_regs_req(dev, 0x06, addr, buf, len);
+/* NOTE:
+ * 0 byte writes always succeed, even if no device is
connected. */
You already noticed it on the previous note.
Yes. ;)
Well, there's no need to repeat the same thing twice at the same function ;)
Uhm yes... WTF... !??
This stuff has definitely been rebased too often... ;)
:)
+if (ret != len) {
+if (ret 0) {
+em28xx_warn(writing to i2c device at 0x%x
failed
+(error=%i)\n, addr, ret);
+return ret;
+} else {
+em28xx_warn(%i bytes write to i2c device at
0x%x
+requested, but %i bytes written\n,
+len, addr, ret);
+return -EIO;
+}
+}
+/* Check success */
+ret = dev-em28xx_read_reg_req(dev, 0x08, 0x);
+/* NOTE: the only error we've seen so far is
+
[PATCH 0/3] Do a few more fixes/cleanups for has_signal/get_afc
While reviewing tuner-core fix for au0828 g_tuner bug patch, I noticed a few other related issues with tuner. This series addresses it. Hans, please add on your git tree when sending me the au0828 g_tuner bug patch. Mauro Carvalho Chehab (3): tuner-core: return afc instead of zero tuner-core: Remove the now uneeded checks at fe_has_signal/get_afc tuner-core: handle errors when getting signal strength/afc drivers/media/v4l2-core/tuner-core.c | 24 +++- 1 file changed, 11 insertions(+), 13 deletions(-) -- 1.8.1.4 -- 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] tuner-core: return afc instead of zero
While the driver gets AFC from the tuner, it doesn't return it back via V4L2 API due to a mistake at the return. fix it. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/v4l2-core/tuner-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/tuner-core.c b/drivers/media/v4l2-core/tuner-core.c index dd8a803..5e18f44 100644 --- a/drivers/media/v4l2-core/tuner-core.c +++ b/drivers/media/v4l2-core/tuner-core.c @@ -235,7 +235,7 @@ static int fe_get_afc(struct dvb_frontend *fe) if (fe-ops.tuner_ops.get_afc) fe-ops.tuner_ops.get_afc(fe, afc); - return 0; + return afc; } static int fe_set_config(struct dvb_frontend *fe, void *priv_cfg) -- 1.8.1.4 -- 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] tuner-core: handle errors when getting signal strength/afc
If those callbacks fail, it should return zero, and not a random
value.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/v4l2-core/tuner-core.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index f1e8b40..cf9a9af 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -220,18 +220,20 @@ static void fe_standby(struct dvb_frontend *fe)
static int fe_has_signal(struct dvb_frontend *fe)
{
- u16 strength = 0;
+ u16 strength;
- fe-ops.tuner_ops.get_rf_strength(fe, strength);
+ if (fe-ops.tuner_ops.get_rf_strength(fe, strength) 0)
+ return 0;
return strength;
}
static int fe_get_afc(struct dvb_frontend *fe)
{
- s32 afc = 0;
+ s32 afc;
- fe-ops.tuner_ops.get_afc(fe, afc);
+ if (fe-ops.tuner_ops.get_afc(fe, afc) 0)
+ return 0;
return afc;
}
--
1.8.1.4
--
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] tuner-core: Remove the now uneeded checks at fe_has_signal/get_afc
Now that those functions are only used when the corresponding
function calls are defined, we don't need to check if those
function calls are present at the structure before using it.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/v4l2-core/tuner-core.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index 5e18f44..f1e8b40 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -222,8 +222,7 @@ static int fe_has_signal(struct dvb_frontend *fe)
{
u16 strength = 0;
- if (fe-ops.tuner_ops.get_rf_strength)
- fe-ops.tuner_ops.get_rf_strength(fe, strength);
+ fe-ops.tuner_ops.get_rf_strength(fe, strength);
return strength;
}
@@ -232,8 +231,7 @@ static int fe_get_afc(struct dvb_frontend *fe)
{
s32 afc = 0;
- if (fe-ops.tuner_ops.get_afc)
- fe-ops.tuner_ops.get_afc(fe, afc);
+ fe-ops.tuner_ops.get_afc(fe, afc);
return afc;
}
@@ -256,8 +254,6 @@ static void tuner_status(struct dvb_frontend *fe);
static const struct analog_demod_ops tuner_analog_ops = {
.set_params = fe_set_params,
.standby= fe_standby,
- .has_signal = fe_has_signal,
- .get_afc= fe_get_afc,
.set_config = fe_set_config,
.tuner_status = tuner_status
};
@@ -453,10 +449,10 @@ static void set_type(struct i2c_client *c, unsigned int
type,
memcpy(analog_ops, tuner_analog_ops,
sizeof(struct analog_demod_ops));
- if (fe_tuner_ops-get_rf_strength == NULL)
- analog_ops-has_signal = NULL;
- if (fe_tuner_ops-get_afc == NULL)
- analog_ops-get_afc = NULL;
+ if (fe_tuner_ops-get_rf_strength)
+ analog_ops-has_signal = fe_has_signal;
+ if (fe_tuner_ops-get_afc)
+ analog_ops-get_afc = fe_get_afc;
} else {
t-name = analog_ops-info.name;
--
1.8.1.4
--
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
media_build build is broken
Apologies is this is already known about but I couldn't find anything when I searched. The media_build tree appears to be currently broken, at least for my build environment (Fedora 18, gcc 4.7.2, 3.8.4-202.fc18.x86_64 kernel). $ git clone git://linuxtv.org/media_build.git $ cd media_build/ $./build Checking if the needed tools for Fedora release 18 (Spherical Cow) are available Needed package dependencies are met. ... lots of output ... CC [M] /home/username/build/v4l/media_build/v4l/mem2mem_testdev.o CC [M] /home/username/build/v4l/media_build/v4l/sh_veu.o /home/username/build/v4l/media_build/v4l/sh_veu.c: In function 'sh_veu_probe': /home/username/build/v4l/media_build/v4l/sh_veu.c:1168:2: error: implicit declaration of function 'devm_ioremap_resource' [-Werror=implicit-function-declaration] /home/username/build/v4l/media_build/v4l/sh_veu.c:1168:12: warning: assignment makes pointer from integer without a cast [enabled by default] /home/username/build/v4l/media_build/v4l/sh_veu.c: At top level: /home/username/build/v4l/media_build/v4l/sh_veu.c:1252:1: warning: data definition has no type or storage class [enabled by default] /home/username/build/v4l/media_build/v4l/sh_veu.c:1252:1: warning: type defaults to 'int' in declaration of 'module_platform_driver_probe' [-Wimplicit-int] /home/username/build/v4l/media_build/v4l/sh_veu.c:1252:1: warning: parameter names (without types) in function declaration [enabled by default] /home/username/build/v4l/media_build/v4l/sh_veu.c:1147:12: warning: 'sh_veu_probe' defined but not used [-Wunused-function] /home/username/build/v4l/media_build/v4l/sh_veu.c:1244:41: warning: 'sh_veu_pdrv' defined but not used [-Wunused-variable] cc1: some warnings being treated as errors make[3]: *** [/home/username/build/v4l/media_build/v4l/sh_veu.o] Error 1 make[2]: *** [_module_/home/username/build/v4l/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/3.8.4-202.fc18.x86_64' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/username/build/v4l/media_build/v4l' make: *** [all] Error 2 build failed at ./build line 452. This seems to be a recent regression, I successfully built from media_build on another Fedora 18 machine just a couple of weeks ago. -- 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: [REVIEW PATCH] tuner-core fix for au0828 g_tuner bug
On Mon, Mar 25, 2013 at 7:32 AM, Hans Verkuil hverk...@xs4all.nl wrote: This fixes the bug where the au8522 detected a signal and then tuner-core overwrote it with 0 since the xc5000 tuner does not support get_rf_strength. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Nice find. That makes much more sense. Cheers, 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: media_build build is broken
On Mon March 25 2013 15:33:08 Anthony Horton wrote: Apologies is this is already known about but I couldn't find anything when I searched. The media_build tree appears to be currently broken, at least for my build environment (Fedora 18, gcc 4.7.2, 3.8.4-202.fc18.x86_64 kernel). Lots of code has been merged in the past few days, and this is still ongoing. Once things have settled a bit I'll work on fixing media_build. It should be fixed this week, likely sooner rather than later. Regards, Hans $ git clone git://linuxtv.org/media_build.git $ cd media_build/ $./build Checking if the needed tools for Fedora release 18 (Spherical Cow) are available Needed package dependencies are met. ... lots of output ... CC [M] /home/username/build/v4l/media_build/v4l/mem2mem_testdev.o CC [M] /home/username/build/v4l/media_build/v4l/sh_veu.o /home/username/build/v4l/media_build/v4l/sh_veu.c: In function 'sh_veu_probe': /home/username/build/v4l/media_build/v4l/sh_veu.c:1168:2: error: implicit declaration of function 'devm_ioremap_resource' [-Werror=implicit-function-declaration] /home/username/build/v4l/media_build/v4l/sh_veu.c:1168:12: warning: assignment makes pointer from integer without a cast [enabled by default] /home/username/build/v4l/media_build/v4l/sh_veu.c: At top level: /home/username/build/v4l/media_build/v4l/sh_veu.c:1252:1: warning: data definition has no type or storage class [enabled by default] /home/username/build/v4l/media_build/v4l/sh_veu.c:1252:1: warning: type defaults to 'int' in declaration of 'module_platform_driver_probe' [-Wimplicit-int] /home/username/build/v4l/media_build/v4l/sh_veu.c:1252:1: warning: parameter names (without types) in function declaration [enabled by default] /home/username/build/v4l/media_build/v4l/sh_veu.c:1147:12: warning: 'sh_veu_probe' defined but not used [-Wunused-function] /home/username/build/v4l/media_build/v4l/sh_veu.c:1244:41: warning: 'sh_veu_pdrv' defined but not used [-Wunused-variable] cc1: some warnings being treated as errors make[3]: *** [/home/username/build/v4l/media_build/v4l/sh_veu.o] Error 1 make[2]: *** [_module_/home/username/build/v4l/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/3.8.4-202.fc18.x86_64' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/username/build/v4l/media_build/v4l' make: *** [all] Error 2 build failed at ./build line 452. This seems to be a recent regression, I successfully built from media_build on another Fedora 18 machine just a couple of weeks ago. -- 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
[GIT PULL FOR v3.10] au0828 driver overhaul and tuner-core fixes
Hi Mauro, This pull request is unchanged from http://patchwork.linuxtv.org/patch/17577/, except for being rebased. I've also added my tuner-core patch and your three tuner-core patches as requested. Regards, Hans The following changes since commit 7bce33daeaca26a3ea3f6099fdfe4e11ea46cac6: [media] solo6x10: prefix sources with 'solo6x10-' (2013-03-25 08:54:05 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git au0828d for you to fetch changes up to e9ee202be209c28559eb13d30e630a242e2beb22: tuner-core: handle errors when getting signal strength/afc (2013-03-25 15:53:19 +0100) Hans Verkuil (16): au8522_decoder: convert to the control framework. au0828: fix querycap. au0828: frequency handling fixes. au0828: fix intendation coding style issue. au0828: fix audio input handling. au0828: convert to the control framework. au0828: add prio, control event and log_status support au0828: add try_fmt_vbi support, zero vbi.reserved, pix.priv. au0828: replace deprecated current_norm by g_std. au8522_decoder: remove obsolete control ops. au0828: fix disconnect sequence. au0828: simplify i2c_gate_ctrl. au0828: don't change global state information on open(). au0828: fix initial video routing. au0828: improve firmware loading locking. tuner-core: don't set has_signal/get_afc if not supported Mauro Carvalho Chehab (3): tuner-core: return afc instead of zero tuner-core: Remove the now uneeded checks at fe_has_signal/get_afc tuner-core: handle errors when getting signal strength/afc drivers/media/dvb-frontends/au8522_decoder.c | 123 +++ drivers/media/dvb-frontends/au8522_priv.h|6 +- drivers/media/usb/au0828/au0828-core.c | 61 -- drivers/media/usb/au0828/au0828-video.c | 287 - drivers/media/usb/au0828/au0828.h|7 ++ drivers/media/v4l2-core/tuner-core.c | 23 --- 6 files changed, 274 insertions(+), 233 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
Re: Status of the patches under review at LMML (32 patches)
Hi Mauro, On Sunday 24 March 2013 15:11:11 Mauro Carvalho Chehab wrote: This is the summary of the patches that are currently under review at Linux Media Mailing List linux-media@vger.kernel.org. Each patch is represented by its submission date, the subject (up to 70 chars) and the patchwork link (if submitted via email). P.S.: This email is c/c to the developers where some action is expected. If you were copied, please review the patches, acking/nacking or submitting an update. [snip] == Laurent Pinchart laurent.pinch...@ideasonboard.com == Dec,12 2012: [v2] ad5820: Voice coil motor controller driver http://patchwork.linuxtv.org/patch/15881 Florian Neuhaus florian.neuh...@reberinformatik.ch Thanks for the reminder, I'll review that one. Jan, 4 2013: omap3isp: Add support for interlaced input data http://patchwork.linuxtv.org/patch/16133 William Swanson william.swan...@fuel7.com Jan,14 2013: omap3isp: Add support for interlaced input data http://patchwork.linuxtv.org/patch/16255 William Swanson william.swan...@fuel7.com I've recently received hardware to test interlaced video with the OMAP3 ISP, I'll work on this. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] fix compilation with both V4L2 and I2C as 'm'
When config options are: CONFIG_VIDEO_DEV=y CONFIG_VIDEO_V4L2=m CONFIG_I2C=m Compilation breaks, as reported by: https://bugzilla.kernel.org/show_bug.cgi?id=55681 Before changeset 7b34be71db533f3e0cf93d53cf62d036cdb5418a, no compilation errors occurred. However, the I2C code there at v4l2-device was incorrectly disabled. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/v4l2-core/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile index a9d3552..768aaf6 100644 --- a/drivers/media/v4l2-core/Makefile +++ b/drivers/media/v4l2-core/Makefile @@ -10,7 +10,7 @@ ifeq ($(CONFIG_COMPAT),y) videodev-objs += v4l2-compat-ioctl32.o endif -obj-$(CONFIG_VIDEO_DEV) += videodev.o +obj-$(CONFIG_VIDEO_V4L2) += videodev.o obj-$(CONFIG_VIDEO_V4L2_INT_DEVICE) += v4l2-int-device.o obj-$(CONFIG_VIDEO_V4L2) += v4l2-common.o -- 1.8.1.4 -- 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/2] dma-buf: replace dma_buf_export() with dma_buf_export_named()
On Mon, Mar 25, 2013 at 04:50:45PM +0530, Sumit Semwal wrote:
For debugging purposes, it is useful to have a name-string added
while exporting buffers. Hence, dma_buf_export() is replaced with
dma_buf_export_named(), which additionally takes 'exp_name' as a
parameter.
For backward compatibility, and for lazy exporters who don't wish to
name themselves, a #define dma_buf_export() is also made available,
which adds a __FILE__ instead of 'exp_name'.
Cc: Daniel Vetter daniel.vet...@ffwll.ch
[Thanks for the idea!]
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
Documentation/dma-buf-sharing.txt | 13 +++--
drivers/base/dma-buf.c| 11 +++
include/linux/dma-buf.h | 11 +--
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 4966b1b..0b23261 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -52,14 +52,23 @@ The dma_buf buffer sharing API usage contains the
following steps:
associated with this buffer.
Interface:
- struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
- size_t size, int flags)
+ struct dma_buf *dma_buf_export_named(void *priv, struct dma_buf_ops
*ops,
+ size_t size, int flags,
+ const char *exp_name)
If this succeeds, dma_buf_export allocates a dma_buf structure, and
returns a
pointer to the same. It also associates an anonymous file with this
buffer,
so it can be exported. On failure to allocate the dma_buf object, it
returns
NULL.
+ 'exp_name' is the name of exporter - to facilitate information while
+ debugging.
+
+ Exporting modules which do not wish to provide any specific name may use
the
+ helper define 'dma_buf_export()', with the same arguments as above, but
+ without the last argument; a __FILE__ pre-processor directive will be
+ inserted in place of 'exp_name' instead.
+
2. Userspace gets a handle to pass around to potential buffer-users
Userspace entity requests for a file-descriptor (fd) which is a handle to
the
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 2a7cb0d..d89102a 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -77,22 +77,24 @@ static inline int is_dma_buf_file(struct file *file)
}
/**
- * dma_buf_export - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
* with this buffer, so it can be exported.
* Also connect the allocator specific data and ops to the buffer.
+ * Additionally, provide a name string for exporter; useful in debugging.
*
* @priv:[in]Attach private data of allocator to this buffer
* @ops: [in]Attach allocator-defined dma buf ops to the new buffer.
* @size:[in]Size of the buffer
* @flags: [in]mode flags for the file.
+ * @exp_name:[in]name of the exporting module - useful for
debugging.
*
* Returns, on success, a newly created dma_buf object, which wraps the
* supplied private data and operations for dma_buf_ops. On either missing
* ops, or error in allocating struct dma_buf, will return negative error.
*
*/
-struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops,
- size_t size, int flags)
+struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops
*ops,
+ size_t size, int flags, const char *exp_name)
{
struct dma_buf *dmabuf;
struct file *file;
@@ -114,6 +116,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct
dma_buf_ops *ops,
dmabuf-priv = priv;
dmabuf-ops = ops;
dmabuf-size = size;
+ dmabuf-exp_name = exp_name;
file = anon_inode_getfile(dmabuf, dma_buf_fops, dmabuf, flags);
@@ -124,7 +127,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct
dma_buf_ops *ops,
return dmabuf;
}
-EXPORT_SYMBOL_GPL(dma_buf_export);
+EXPORT_SYMBOL_GPL(dma_buf_export_named);
/**
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 9978b61..6f55c04 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -112,6 +112,7 @@ struct dma_buf_ops {
* @file: file pointer used for sharing buffers across, and for refcounting.
* @attachments: list of dma_buf_attachment that denotes all devices
attached.
* @ops: dma_buf_ops associated with this buffer object.
+ * @exp_name: name of the exporter; useful for debugging.
* @priv: exporter specific private data for this buffer object.
*/
struct dma_buf {
@@ -123,6 +124,7 @@ struct dma_buf {
struct mutex lock;
Terratec Grabby hwrev 2
I just bought a Terratec Grabby hardware revision 2 in hopes that it would work on my linux box. But alas, I got only sound working. It seems that analog video picture grabbing does not work. I tried kernels 3.4.34-grsec, 3.7.1 (vanilla), 3.8.2-grsec and 3.9.0-rc4 (vanilla). And all fail the same way - no video data received. The USB ID is same as on the revision 1 board: Bus 005 Device 002: ID 0ccd:0096 TerraTec Electronic GmbH And it is properly detected as Grabby. It seems that the videobuf2 changes for 3.9.0-rc4 resulted in better debug logging, and it implies that the application (ffmpeg 1.1.4) is behaving well: all buffers are allocated, mmapped, queued, streamon called. But no data is received from the dongle. I also tested mencoder and it fails in similar manner. Dmesg (on 3.9.0-rc4) tells after module load the following: [ 1249.600246] em28xx: New device TerraTec Electronic GmbH TerraTec Grabby @ 480 Mbps (0ccd:0096, inte rface 0, class 0) [ 1249.600258] em28xx: Video interface 0 found: isoc [ 1249.600264] em28xx: DVB interface 0 found: isoc [ 1249.600443] em28xx: chip ID is em2860 [ 1249.715053] em2860 #0: i2c eeprom 00: 1a eb 67 95 cd 0c 96 00 50 00 11 03 9c 20 6a 32 [ 1249.715084] em2860 #0: i2c eeprom 10: 00 00 06 57 0e 02 00 00 00 00 00 00 00 00 00 00 [ 1249.715110] em2860 #0: i2c eeprom 20: 02 00 01 00 f0 10 01 00 00 00 00 00 5b 00 00 00 [ 1249.715136] em2860 #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [ 1249.715161] em2860 #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715186] em2860 #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715211] em2860 #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 32 03 54 00 65 00 [ 1249.715235] em2860 #0: i2c eeprom 70: 72 00 72 00 61 00 54 00 65 00 63 00 20 00 45 00 [ 1249.715261] em2860 #0: i2c eeprom 80: 6c 00 65 00 63 00 74 00 72 00 6f 00 6e 00 69 00 [ 1249.715286] em2860 #0: i2c eeprom 90: 63 00 20 00 47 00 6d 00 62 00 48 00 20 03 54 00 [ 1249.715311] em2860 #0: i2c eeprom a0: 65 00 72 00 72 00 61 00 54 00 65 00 63 00 20 00 [ 1249.715336] em2860 #0: i2c eeprom b0: 47 00 72 00 61 00 62 00 62 00 79 00 48 00 00 00 [ 1249.715361] em2860 #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715385] em2860 #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715410] em2860 #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715435] em2860 #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715464] em2860 #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xd3498090 [ 1249.715470] em2860 #0: EEPROM info: [ 1249.715475] em2860 #0: AC97 audio (5 sample rates) [ 1249.715480] em2860 #0: 500mA max power [ 1249.715487] em2860 #0: Table at 0x06, strings=0x209c, 0x326a, 0x [ 1249.715495] em2860 #0: Identified as Terratec Grabby (card=67) [ 1250.058076] em2860 #0: Config register raw data: 0x50 [ 1250.076845] em2860 #0: AC97 vendor ID = 0x60f160f1 [ 1250.086814] em2860 #0: AC97 features = 0x60f1 [ 1250.086822] em2860 #0: Unknown AC97 audio processor detected! [ 1251.116646] em2860 #0: v4l2 driver version 0.1.3 [ 1251.891145] em2860 #0: V4L2 video device registered as video0 [ 1251.891155] em2860 #0: V4L2 VBI device registered as vbi0 [ 1251.891161] em2860 #0: analog set to isoc mode. [ 1251.891167] em2860 #0: dvb set to isoc mode. [ 1251.910649] usbcore: registered new interface driver em28xx Any suggestions how to debug/fix this? Thanks, Timo -- 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: Terratec Grabby hwrev 2
Em Mon, 25 Mar 2013 19:08:46 +0200 Timo Teras timo.te...@iki.fi escreveu: I just bought a Terratec Grabby hardware revision 2 in hopes that it would work on my linux box. But alas, I got only sound working. It seems that analog video picture grabbing does not work. I tried kernels 3.4.34-grsec, 3.7.1 (vanilla), 3.8.2-grsec and 3.9.0-rc4 (vanilla). And all fail the same way - no video data received. The USB ID is same as on the revision 1 board: Bus 005 Device 002: ID 0ccd:0096 TerraTec Electronic GmbH And it is properly detected as Grabby. It seems that the videobuf2 changes for 3.9.0-rc4 resulted in better debug logging, and it implies that the application (ffmpeg 1.1.4) is behaving well: all buffers are allocated, mmapped, queued, streamon called. But no data is received from the dongle. I also tested mencoder and it fails in similar manner. Dmesg (on 3.9.0-rc4) tells after module load the following: [ 1249.600246] em28xx: New device TerraTec Electronic GmbH TerraTec Grabby @ 480 Mbps (0ccd:0096, inte rface 0, class 0) [ 1249.600258] em28xx: Video interface 0 found: isoc [ 1249.600264] em28xx: DVB interface 0 found: isoc [ 1249.600443] em28xx: chip ID is em2860 [ 1249.715053] em2860 #0: i2c eeprom 00: 1a eb 67 95 cd 0c 96 00 50 00 11 03 9c 20 6a 32 [ 1249.715084] em2860 #0: i2c eeprom 10: 00 00 06 57 0e 02 00 00 00 00 00 00 00 00 00 00 [ 1249.715110] em2860 #0: i2c eeprom 20: 02 00 01 00 f0 10 01 00 00 00 00 00 5b 00 00 00 [ 1249.715136] em2860 #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [ 1249.715161] em2860 #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715186] em2860 #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715211] em2860 #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 32 03 54 00 65 00 [ 1249.715235] em2860 #0: i2c eeprom 70: 72 00 72 00 61 00 54 00 65 00 63 00 20 00 45 00 [ 1249.715261] em2860 #0: i2c eeprom 80: 6c 00 65 00 63 00 74 00 72 00 6f 00 6e 00 69 00 [ 1249.715286] em2860 #0: i2c eeprom 90: 63 00 20 00 47 00 6d 00 62 00 48 00 20 03 54 00 [ 1249.715311] em2860 #0: i2c eeprom a0: 65 00 72 00 72 00 61 00 54 00 65 00 63 00 20 00 [ 1249.715336] em2860 #0: i2c eeprom b0: 47 00 72 00 61 00 62 00 62 00 79 00 48 00 00 00 [ 1249.715361] em2860 #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715385] em2860 #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715410] em2860 #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715435] em2860 #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715464] em2860 #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xd3498090 [ 1249.715470] em2860 #0: EEPROM info: [ 1249.715475] em2860 #0: AC97 audio (5 sample rates) [ 1249.715480] em2860 #0: 500mA max power [ 1249.715487] em2860 #0: Table at 0x06, strings=0x209c, 0x326a, 0x [ 1249.715495] em2860 #0: Identified as Terratec Grabby (card=67) [ 1250.058076] em2860 #0: Config register raw data: 0x50 [ 1250.076845] em2860 #0: AC97 vendor ID = 0x60f160f1 [ 1250.086814] em2860 #0: AC97 features = 0x60f1 That looks weird on my eyes: 3 AC97 reads returned 0x60f1. I suspect that the GPIOs for this device are different than on version 1. [ 1250.086822] em2860 #0: Unknown AC97 audio processor detected! [ 1251.116646] em2860 #0: v4l2 driver version 0.1.3 [ 1251.891145] em2860 #0: V4L2 video device registered as video0 [ 1251.891155] em2860 #0: V4L2 VBI device registered as vbi0 [ 1251.891161] em2860 #0: analog set to isoc mode. [ 1251.891167] em2860 #0: dvb set to isoc mode. [ 1251.910649] usbcore: registered new interface driver em28xx Any suggestions how to debug/fix this? The better is to run the original driver at a recent version of KVM with USB port forward enabled, and capture the USB logs. There are some pages at LinuxTV wiki explaining how to do it. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Grabby hwrev 2
On Mon, 25 Mar 2013 14:36:47 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Mon, 25 Mar 2013 19:08:46 +0200 Timo Teras timo.te...@iki.fi escreveu: I just bought a Terratec Grabby hardware revision 2 in hopes that it would work on my linux box. But alas, I got only sound working. It seems that analog video picture grabbing does not work. I tried kernels 3.4.34-grsec, 3.7.1 (vanilla), 3.8.2-grsec and 3.9.0-rc4 (vanilla). And all fail the same way - no video data received. The USB ID is same as on the revision 1 board: Bus 005 Device 002: ID 0ccd:0096 TerraTec Electronic GmbH And it is properly detected as Grabby. It seems that the videobuf2 changes for 3.9.0-rc4 resulted in better debug logging, and it implies that the application (ffmpeg 1.1.4) is behaving well: all buffers are allocated, mmapped, queued, streamon called. But no data is received from the dongle. I also tested mencoder and it fails in similar manner. Dmesg (on 3.9.0-rc4) tells after module load the following: [ 1250.076845] em2860 #0: AC97 vendor ID = 0x60f160f1 [ 1250.086814] em2860 #0: AC97 features = 0x60f1 That looks weird on my eyes: 3 AC97 reads returned 0x60f1. I suspect that the GPIOs for this device are different than on version 1. Yes, I just noticed this now too. It seems something went wrong when loading em28xx with a bunch of debug logging enabled. On normal load it returns instead: [ 12.453631] em2860 #0: AC97 vendor ID = 0x83847650 [ 12.463650] em2860 #0: AC97 features = 0x6a90 [ 12.463658] em2860 #0: Empia 202 AC97 audio processor detected Any suggestions how to debug/fix this? The better is to run the original driver at a recent version of KVM with USB port forward enabled, and capture the USB logs. There are some pages at LinuxTV wiki explaining how to do it. Oh, ok. Seems Wireshark/USBPcap might be better option for me as I don't have KVMed Windows install handy. Will try to get traces from it. - Timo -- 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] [cx88] fix Geniatech X8000-MT dvb card support
Spite the Geniatech X8000-MT dvb card is added long time ago to the
kernel, it never worked. I have one of this cards branded as notOnlyTV
LV3H http://www.linuxtv.org/wiki/index.php/NotOnlyTV_LV3H and it seems
the gpios are wrong among other things. As I wrote in the linuxtv wiki
entry this card works passing the options to work as a Leadtek WinFast
DTV1800 Hybrid. Not fully tested but the important part (DVB) works
fine with minor issues like dmesg floods with the message Calling
XC2028/3028 callback, but I don't know if this problem exists with
other cards.
This is the board
http://www.linuxtv.org/wiki/images/4/4a/X8000T-DVBT-PCI.jpg exactly
the same as mine, and other boards like X3M HPC2000, or Jactek JH-600.
I insist with the current code none of this boards work, all forums I
visited people reported the card doesn't work. I tested the patch
against 3.2.0-39 (my card is installed in a machine with Ubuntu
12.04.2 LTS), but I made the patch for what's currently in linux-tv
git.
Signed-off-by: Daniel Gonzalez dgcbueu at gmail.com
--- a/drivers/media/pci/cx88/cx88-cards.c
+++ b/drivers/media/pci/cx88/cx88-cards.c
@@ -1753,37 +1753,38 @@
},
[CX88_BOARD_GENIATECH_X8000_MT] = {
/* Also PowerColor Real Angel 330 and Geniatech X800 OEM */
+ /* Works like Leadtek WinFast DTV1800 Hybrid */
.name = Geniatech X8000-MT DVBT,
.tuner_type = TUNER_XC2028,
.tuner_addr = 0x61,
.input = { {
.type = CX88_VMUX_TELEVISION,
.vmux = 0,
- .gpio0 = 0x,
- .gpio1 = 0x00e3e341,
- .gpio2 = 0x,
- .gpio3 = 0x,
+ .gpio0 = 0x0400,
+ .gpio1 = 0x6040,
+ .gpio2 = 0x,
+ .gpio3 = 0x,
}, {
.type = CX88_VMUX_COMPOSITE1,
.vmux = 1,
- .gpio0 = 0x,
- .gpio1 = 0x00e3e361,
- .gpio2 = 0x,
- .gpio3 = 0x,
+ .gpio0 = 0x0400,
+ .gpio1 = 0x6060,
+ .gpio2 = 0x,
+ .gpio3 = 0x,
}, {
.type = CX88_VMUX_SVIDEO,
.vmux = 2,
- .gpio0 = 0x,
- .gpio1 = 0x00e3e361,
- .gpio2 = 0x,
- .gpio3 = 0x,
+ .gpio0 = 0x0400,
+ .gpio1 = 0x6060,
+ .gpio2 = 0x,
+ .gpio3 = 0x,
} },
.radio = {
.type = CX88_RADIO,
- .gpio0 = 0x,
- .gpio1 = 0x00e3e341,
- .gpio2 = 0x,
- .gpio3 = 0x,
+ .gpio0 = 0x0400,
+ .gpio1 = 0x6000,
+ .gpio2 = 0x,
+ .gpio3 = 0x,
},
.mpeg = CX88_MPEG_DVB,
},
@@ -3114,7 +3115,6 @@
/* Board-specific callbacks */
switch (core-boardnr) {
case CX88_BOARD_POWERCOLOR_REAL_ANGEL:
- case CX88_BOARD_GENIATECH_X8000_MT:
case CX88_BOARD_KWORLD_ATSC_120:
return cx88_xc3028_geniatech_tuner_callback(core,
command, arg);
@@ -3124,6 +3124,7 @@
case CX88_BOARD_DVICO_FUSIONHDTV_DVB_T_PRO:
case CX88_BOARD_DVICO_FUSIONHDTV_5_PCI_NANO:
return cx88_dvico_xc2028_callback(core, command, arg);
+ case CX88_BOARD_GENIATECH_X8000_MT:
case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL:
case CX88_BOARD_WINFAST_DTV1800H:
return cx88_xc3028_winfast1800h_callback(core, command, arg);
@@ -,6 +3334,7 @@
udelay(1000);
break;
+ case CX88_BOARD_GENIATECH_X8000_MT:
case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL:
case CX88_BOARD_WINFAST_DTV1800H:
cx88_xc3028_winfast1800h_callback(core, XC2028_TUNER_RESET, 0);
@@ -3380,11 +3382,12 @@
ctl-demod = XC3028_FE_OREN538;
break;
case CX88_BOARD_GENIATECH_X8000_MT:
- /* FIXME: For this board, the xc3028 never recovers after being
- powered down (the reset GPIO probably is not set properly).
- We don't have access to the hardware so we cannot determine
- which GPIO is used for xc3028, so just disable power xc3028
- power management for
Re: Terratec Grabby hwrev 2
Em Mon, 25 Mar 2013 19:48:20 +0200 Timo Teras timo.te...@iki.fi escreveu: On Mon, 25 Mar 2013 14:36:47 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Mon, 25 Mar 2013 19:08:46 +0200 Timo Teras timo.te...@iki.fi escreveu: I just bought a Terratec Grabby hardware revision 2 in hopes that it would work on my linux box. But alas, I got only sound working. It seems that analog video picture grabbing does not work. I tried kernels 3.4.34-grsec, 3.7.1 (vanilla), 3.8.2-grsec and 3.9.0-rc4 (vanilla). And all fail the same way - no video data received. The USB ID is same as on the revision 1 board: Bus 005 Device 002: ID 0ccd:0096 TerraTec Electronic GmbH And it is properly detected as Grabby. It seems that the videobuf2 changes for 3.9.0-rc4 resulted in better debug logging, and it implies that the application (ffmpeg 1.1.4) is behaving well: all buffers are allocated, mmapped, queued, streamon called. But no data is received from the dongle. I also tested mencoder and it fails in similar manner. Dmesg (on 3.9.0-rc4) tells after module load the following: [ 1250.076845] em2860 #0: AC97 vendor ID = 0x60f160f1 [ 1250.086814] em2860 #0: AC97 features = 0x60f1 That looks weird on my eyes: 3 AC97 reads returned 0x60f1. I suspect that the GPIOs for this device are different than on version 1. Yes, I just noticed this now too. It seems something went wrong when loading em28xx with a bunch of debug logging enabled. On normal load it returns instead: [ 12.453631] em2860 #0: AC97 vendor ID = 0x83847650 [ 12.463650] em2860 #0: AC97 features = 0x6a90 [ 12.463658] em2860 #0: Empia 202 AC97 audio processor detected Weird. Except for an additional delay, those debug stuff shouldn't be changing the driver's behavior. Are those results consistent? There are some known problems with a few em28xx devices that, from time to time, aren't able to read data from the eeprom. On such devices, it is a hardware issue. Any suggestions how to debug/fix this? The better is to run the original driver at a recent version of KVM with USB port forward enabled, and capture the USB logs. There are some pages at LinuxTV wiki explaining how to do it. Oh, ok. Seems Wireshark/USBPcap might be better option for me as I don't have KVMed Windows install handy. Will try to get traces from it. Ok, 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Mar 25 19:00:23 CET 2013 git branch: test git hash: 7bce33daeaca26a3ea3f6099fdfe4e11ea46cac6 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8-3.slh.2-amd64 linux-git-arm-davinci: OK linux-git-arm-exynos: ERRORS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9-rc1-i686: WARNINGS linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [REGRESSION] bt8xx: Fix too large height in cropcap
Since commit a1fd287780c8e91fed4957b30c757b0c93021162:
[media] bttv-driver: fix two warnings
cropcap.defrect.height and cropcap.bounds.height for the PAL entry are 32
resp 30 pixels too large, if a userspace app (ie xawtv) actually tries to use
the full advertised height, the resulting image is broken in ways only a
screenshot can describe.
The cause of this is the fix for this warning:
drivers/media/pci/bt8xx/bttv-driver.c:308:3: warning: initialized field
overwritten [-Woverride-init]
In this chunk of the commit:
@@ -301,11 +301,10 @@ const struct bttv_tvnorm bttv_tvnorms[] = {
/* totalwidth */ 1135,
/* sqwidth */ 944,
/* vdelay */ 0x20,
- /* sheight */ 576,
- /* videostart0 */ 23)
/* bt878 (and bt848?) can capture another
line below active video. */
- .cropcap.bounds.height = (576 + 2) + 0x20 - 2,
+ /* sheight */ (576 + 2) + 0x20 - 2,
+ /* videostart0 */ 23)
},{
.v4l2_id= V4L2_STD_NTSC_M | V4L2_STD_NTSC_M_KR,
.name = NTSC,
Which replaces the overriding of cropcap.bounds.height initialization outside
of the CROPCAP macro (which also initializes it), with passing a
different sheight value to the CROPCAP macro.
There are 2 problems with this warning fix:
1) The sheight value is used twice in the CROPCAP macro, and the old code
only changed one resulting value.
2) The old code increased the .cropcap.bounds.height value (and did not
touch the .cropcap.defrect.height value at all) by 2, where as the fixed
code increases it by 32, as the fixed code passes (576 + 2) + 0x20 - 2
to the CROPCAP macro, but the + 0x20 - 2 is already done by the macro so
now is done twice for .cropcap.bounds.height, and also is applied to
.cropcap.defrect.height where it should not be applied at all.
This patch fixes this by adding an extraheight parameter to the CROPCAP entry
and using it for the PAL entry.
This is a regression introduced in 3.8 and this fix should be backported to
kernels back to 3.8.x.
Signed-off-by: Hans de Goede hdego...@redhat.com
Cc: sta...@vger.kernel.org
---
drivers/media/pci/bt8xx/bttv-driver.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index e33a2d2..e7d0884 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -263,17 +263,19 @@ static u8 SRAM_Table[][60] =
vdelay start of active video in 2 * field lines relative to
trailing edge of /VRESET pulse (VDELAY register).
sheight height of active video in 2 * field lines.
+ extraheight Added to sheight for cropcap.bounds.height only
videostart0 ITU-R frame line number of the line corresponding
to vdelay in the first field. */
#define CROPCAP(minhdelayx1, hdelayx1, swidth, totalwidth, sqwidth, \
- vdelay, sheight, videostart0)\
+ vdelay, sheight, extraheight, videostart0) \
.cropcap.bounds.left = minhdelayx1, \
/* * 2 because vertically we count field lines times two, */ \
/* e.g. 23 * 2 to 23 * 2 + 576 in PAL-BGHI defrect. */ \
.cropcap.bounds.top = (videostart0) * 2 - (vdelay) + MIN_VDELAY, \
/* 4 is a safety margin at the end of the line. */ \
.cropcap.bounds.width = (totalwidth) - (minhdelayx1) - 4,\
- .cropcap.bounds.height = (sheight) + (vdelay) - MIN_VDELAY, \
+ .cropcap.bounds.height = (sheight) + (extraheight) + (vdelay) - \
+MIN_VDELAY, \
.cropcap.defrect.left = hdelayx1,\
.cropcap.defrect.top = (videostart0) * 2,\
.cropcap.defrect.width = swidth, \
@@ -314,9 +316,10 @@ const struct bttv_tvnorm bttv_tvnorms[] = {
/* totalwidth */ 1135,
/* sqwidth */ 944,
/* vdelay */ 0x20,
- /* bt878 (and bt848?) can capture another
- line below active video. */
- /* sheight */ (576 + 2) + 0x20 - 2,
+ /* sheight */ 576,
+ /* bt878 (and bt848?) can capture another
+ line below active video. */
+ /* extraheight */ 2,
/* videostart0 */ 23)
},{
.v4l2_id= V4L2_STD_NTSC_M | V4L2_STD_NTSC_M_KR,
@@ -343,6 +346,7 @@ const struct bttv_tvnorm bttv_tvnorms[] = {
/* sqwidth */ 780,
/*
Re: media_build build is broken
Sorry feeling a bit thick now... Never done a rollback using git and thought it would be straightforward as subversion, however I hadn't realised that the build is actually pulling the latest head version as part of the build itself. Had a play around trying to use git reset --hard xxx to get to a previous version on 8th March however my command of git is somewhat limited and although I've googled I can't see how to achieve this easily. If someone on the list could let me know a quick way of going back to 99fa97227ee3f4728d16c0db214637e2b61fa128 on the 8th March I'd be grateful. Regards On 25 March 2013 18:47, Another Sillyname anothersn...@googlemail.com wrote: Sorry feeling a bit thick now... Never done a rollback using git and thought it would be straightforward as subversion, however I hadn't realised that the build is actually pulling the latest head version as part of the build itself. Had a play around trying to use git reset --hard xxx to get to a previous version on 8th March however my command of git is somewhat limited and although I've googled I can't see how to achieve this easily. If someone on the list could let me know a quick way of going back to 99fa97227ee3f4728d16c0db214637e2b61fa128 on the 8th March I'd be grateful. Regards On 25 March 2013 15:17, Hans Verkuil hverk...@xs4all.nl wrote: On Mon March 25 2013 16:14:26 Another Sillyname wrote: Cripes that's hilarious. I was just about to post this as well, Fed 18 x86_64 blah blah blah. Hans, how far back do I need to go on git to get a good build version please, I'm building a new box today and only have a few days to test before buggering off for a few weeks. It was working a week ago. Regards, Hans Thanks On 25 March 2013 14:38, Hans Verkuil hverk...@xs4all.nl wrote: On Mon March 25 2013 15:33:08 Anthony Horton wrote: Apologies is this is already known about but I couldn't find anything when I searched. The media_build tree appears to be currently broken, at least for my build environment (Fedora 18, gcc 4.7.2, 3.8.4-202.fc18.x86_64 kernel). Lots of code has been merged in the past few days, and this is still ongoing. Once things have settled a bit I'll work on fixing media_build. It should be fixed this week, likely sooner rather than later. Regards, Hans $ git clone git://linuxtv.org/media_build.git $ cd media_build/ $./build Checking if the needed tools for Fedora release 18 (Spherical Cow) are available Needed package dependencies are met. ... lots of output ... CC [M] /home/username/build/v4l/media_build/v4l/mem2mem_testdev.o CC [M] /home/username/build/v4l/media_build/v4l/sh_veu.o /home/username/build/v4l/media_build/v4l/sh_veu.c: In function 'sh_veu_probe': /home/username/build/v4l/media_build/v4l/sh_veu.c:1168:2: error: implicit declaration of function 'devm_ioremap_resource' [-Werror=implicit-function-declaration] /home/username/build/v4l/media_build/v4l/sh_veu.c:1168:12: warning: assignment makes pointer from integer without a cast [enabled by default] /home/username/build/v4l/media_build/v4l/sh_veu.c: At top level: /home/username/build/v4l/media_build/v4l/sh_veu.c:1252:1: warning: data definition has no type or storage class [enabled by default] /home/username/build/v4l/media_build/v4l/sh_veu.c:1252:1: warning: type defaults to 'int' in declaration of 'module_platform_driver_probe' [-Wimplicit-int] /home/username/build/v4l/media_build/v4l/sh_veu.c:1252:1: warning: parameter names (without types) in function declaration [enabled by default] /home/username/build/v4l/media_build/v4l/sh_veu.c:1147:12: warning: 'sh_veu_probe' defined but not used [-Wunused-function] /home/username/build/v4l/media_build/v4l/sh_veu.c:1244:41: warning: 'sh_veu_pdrv' defined but not used [-Wunused-variable] cc1: some warnings being treated as errors make[3]: *** [/home/username/build/v4l/media_build/v4l/sh_veu.o] Error 1 make[2]: *** [_module_/home/username/build/v4l/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/3.8.4-202.fc18.x86_64' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/username/build/v4l/media_build/v4l' make: *** [all] Error 2 build failed at ./build line 452. This seems to be a recent regression, I successfully built from media_build on another Fedora 18 machine just a couple of weeks ago. -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
Re: Terratec Grabby hwrev 2
On Mon, 25 Mar 2013 15:32:20 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Mon, 25 Mar 2013 19:48:20 +0200 Timo Teras timo.te...@iki.fi escreveu: On Mon, 25 Mar 2013 14:36:47 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Mon, 25 Mar 2013 19:08:46 +0200 Timo Teras timo.te...@iki.fi escreveu: I just bought a Terratec Grabby hardware revision 2 in hopes that it would work on my linux box. But alas, I got only sound working. It seems that analog video picture grabbing does not work. I tried kernels 3.4.34-grsec, 3.7.1 (vanilla), 3.8.2-grsec and 3.9.0-rc4 (vanilla). And all fail the same way - no video data received. The USB ID is same as on the revision 1 board: Bus 005 Device 002: ID 0ccd:0096 TerraTec Electronic GmbH And it is properly detected as Grabby. It seems that the videobuf2 changes for 3.9.0-rc4 resulted in better debug logging, and it implies that the application (ffmpeg 1.1.4) is behaving well: all buffers are allocated, mmapped, queued, streamon called. But no data is received from the dongle. I also tested mencoder and it fails in similar manner. Dmesg (on 3.9.0-rc4) tells after module load the following: [ 1250.076845] em2860 #0: AC97 vendor ID = 0x60f160f1 [ 1250.086814] em2860 #0: AC97 features = 0x60f1 That looks weird on my eyes: 3 AC97 reads returned 0x60f1. I suspect that the GPIOs for this device are different than on version 1. Yes, I just noticed this now too. It seems something went wrong when loading em28xx with a bunch of debug logging enabled. On normal load it returns instead: [ 12.453631] em2860 #0: AC97 vendor ID = 0x83847650 [ 12.463650] em2860 #0: AC97 features = 0x6a90 [ 12.463658] em2860 #0: Empia 202 AC97 audio processor detected Weird. Except for an additional delay, those debug stuff shouldn't be changing the driver's behavior. Are those results consistent? There are some known problems with a few em28xx devices that, from time to time, aren't able to read data from the eeprom. On such devices, it is a hardware issue. Actually it seems consistent that: 1. load em28xx - attach USB - fail 2. attach USB - load em28xx - success Sounds like if the driver is loaded, it tries to access eeprom while it's still initializing or something like that. Any suggestions how to debug/fix this? The better is to run the original driver at a recent version of KVM with USB port forward enabled, and capture the USB logs. There are some pages at LinuxTV wiki explaining how to do it. Oh, ok. Seems Wireshark/USBPcap might be better option for me as I don't have KVMed Windows install handy. Will try to get traces from it. Ok, thanks! Seems that USBPcap needs compiling and TESTSIGNING enabled - so I'd rather avoid it. I did get etl format windows captures via logman start usbtrace. Can you read those, or know anyway to convert them to text / something wireshark reads? Native .etl and the .etl converted to .cap do not work in wireshark: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6694 - Timo -- 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: Null pointer dereference when loading cx88_dvb
Hello *, I get a null pointer dereference when loading the cx88_dvb module (kernel 3.9.0-rc4, but using an older kernel makes no difference). If I blacklist the cx8800 module, everything works fine. I have a Hauppauge HVR4000 card with multiple tuners (DVB-T, DVB-S, DVB-S2, analog). I'm using only the DVB-S and DVB-S2 tuners, so I don't need the cx8800 module. Below is the output of dmesg and lspci. Best regards Sebastian dmesg: [0.00] Linux version 3.9.0-rc4 (root@VDR-SF) (gcc version 4.7.2 (GCC) ) #29 SMP PREEMPT Mon Mar 25 19:43:35 CET 2013 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz root=/dev/sda1 rw rootfstype=ext4 modprobe.blacklist=mceusb quiet usbhid.quirks=0x0471:0x0613:0x4 [0.00] KERNEL supported cpus: [0.00] AMD AuthenticAMD [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009dbff] usable [0.00] BIOS-e820: [mem 0x0009dc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e3000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x5ff8] usable [0.00] BIOS-e820: [mem 0x5ff9-0x5ff9dfff] ACPI data [0.00] BIOS-e820: [mem 0x5ff9e000-0x5ffd] ACPI NVS [0.00] BIOS-e820: [mem 0x5ffe-0x5ffedfff] reserved [0.00] BIOS-e820: [mem 0x5fff-0x5fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfeef] reserved [0.00] BIOS-e820: [mem 0xfff0-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] e820: update [mem 0x-0x0fff] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x5ff90 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask FFC000 write-back [0.00] 1 base 004000 mask FFE000 write-back [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] Base memory trampoline at [88097000] 97000 size 24576 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x02731000, 0x02731fff] PGTABLE [0.00] BRK [0x02732000, 0x02732fff] PGTABLE [0.00] BRK [0x02733000, 0x02733fff] PGTABLE [0.00] init_memory_mapping: [mem 0x5fc0-0x5fdf] [0.00] [mem 0x5fc0-0x5fdf] page 2M [0.00] BRK [0x02734000, 0x02734fff] PGTABLE [0.00] init_memory_mapping: [mem 0x5c00-0x5fbf] [0.00] [mem 0x5c00-0x5fbf] page 2M [0.00] init_memory_mapping: [mem 0x0010-0x5bff] [0.00] [mem 0x0010-0x001f] page 4k [0.00] [mem 0x0020-0x5bff] page 2M [0.00] init_memory_mapping: [mem 0x5fe0-0x5ff8] [0.00] [mem 0x5fe0-0x5ff8] page 4k [0.00] BRK [0x02735000, 0x02735fff] PGTABLE [0.00] ACPI: RSDP 000fb770 00024 (v02 ACPIAM) [0.00] ACPI: XSDT 5ff90100 0006C (v01 091010 XSDT1510 20100910 MSFT 0097) [0.00] ACPI: FACP 5ff90290 000F4 (v03 091010 FACP1510 20100910 MSFT 0097) [0.00] ACPI: DSDT 5ff90460 0AAF1 (v01 A1043 A1043000 INTL 20060113) [0.00] ACPI: FACS 5ff9e000 00040 [0.00] ACPI: APIC 5ff90390 00090 (v01 091010 APIC1510 20100910 MSFT 0097) [0.00] ACPI: MCFG 5ff90420 0003C (v01 091010 OEMMCFG 20100910 MSFT 0097) [0.00] ACPI: OEMB 5ff9e040 00072 (v01 091010 OEMB1510 20100910 MSFT 0097) [0.00] ACPI: SRAT 5ff9af60 000A0 (v01 AMDFAM_F_10 0002 AMD 0001) [0.00] ACPI: HPET 5ff9b000 00038 (v01 091010 OEMHPET0 20100910 MSFT 0097) [0.00] ACPI: INFO 5ff9e0c0 00124 (v01 091010 AMDINFO 20100910 MSFT 0097) [0.00] ACPI: NVHD 5ff9e1f0 00284 (v01 091010 NVHDCP 20100910 MSFT 0097) [0.00] ACPI: SSDT 5ff9b040 0030E (v01 A M I POWERNOW 0001 AMD 0001) [0.00] ACPI: Local APIC address 0xfee0 [0.00] [ea00-ea00017f] PMD - [88005de0- 88005f5f] on node 0 [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem
Re: Status of the patches under review at LMML (32 patches)
On 03/24/2013 07:11 PM, Mauro Carvalho Chehab wrote: This is the summary of the patches that are currently under review at Linux Media Mailing Listlinux-media@vger.kernel.org. Each patch is represented by its submission date, the subject (up to 70 chars) and the patchwork link (if submitted via email). P.S.: This email is c/c to the developers where some action is expected. If you were copied, please review the patches, acking/nacking or submitting an update. It took me a lot of time to handle patches this time. The good news is that there's just one patch without an owner. This patch is there on the pile for a long time. I was actually expecting that either Jarod or David could review it, as it can affect existing NEC devices: [...] == Sylwester Nawrocki s.nawro...@samsung.com == Jan, 6 2013: s5p-tv: mixer: fix handling of VIDIOC_S_FMT http://patchwork.linuxtv.org/patch/16143 Tomasz Stanislawskit.stanisl...@samsung.com From my side I can't see any applications this patch could cause issues to. And it actually breaks some applications to not have this patch applied. Hence we keep it applied internally. I will likely not be able to address the issue at V4L2 API that some applications rely on drivers returning -EINVAL on an attempt to set unsupported format. I don't have an idea what to do with that at the moment :) I would say it is safe to apply this patch. But if you have concerns please ignore it. Or let's leave it in current state. Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-ctl PATCH] configure.ac: Respect CPPFLAGS from environment
Hi Andreas, Thanks for the patch, and sorry for the late reply. On Monday 18 February 2013 01:10:02 Andreas Bombe wrote: Signed-off-by: Andreas Bombe a...@debian.org Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com and pushed to the repository. --- configure.ac |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 98459d4..a749794 100644 --- a/configure.ac +++ b/configure.ac @@ -48,7 +48,7 @@ AC_ARG_WITH(kernel-headers, esac], [KERNEL_HEADERS_DIR=/usr/src/kernel-headers]) -CPPFLAGS=-I$KERNEL_HEADERS_DIR/include +CPPFLAGS=$CPPFLAGS -I$KERNEL_HEADERS_DIR/include # Checks for header files. AC_CHECK_HEADERS([linux/media.h \ -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-ctl PATCH] Add missing stdlib.h and ctype.h includes
Hi Andreas, Thanks for the patch, and sorry for the late reply. On Monday 18 February 2013 01:12:44 Andreas Bombe wrote: src/mediactl.c needs ctype.h for its use of isspace(). src/v4l2subdev.c needs stdlib.h for strtoul() and ctype.h for isspace() and isupper(). Signed-off-by: Andreas Bombe a...@debian.org Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com and pushed to the repository. --- src/mediactl.c |1 + src/v4l2subdev.c |2 ++ 2 files changed, 3 insertions(+) diff --git a/src/mediactl.c b/src/mediactl.c index 46562de..c2f985a 100644 --- a/src/mediactl.c +++ b/src/mediactl.c @@ -29,6 +29,7 @@ #include stdbool.h #include stdio.h #include stdlib.h +#include ctype.h #include string.h #include fcntl.h #include errno.h diff --git a/src/v4l2subdev.c b/src/v4l2subdev.c index d0c37f3..87d7eb7 100644 --- a/src/v4l2subdev.c +++ b/src/v4l2subdev.c @@ -26,6 +26,8 @@ #include errno.h #include fcntl.h #include stdbool.h +#include stdlib.h +#include ctype.h #include stdio.h #include string.h #include unistd.h -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-ctl PATCH] Fix linking of shared libraries
Hi Andreas, Thanks for the patch, and sorry for the late reply. On Tuesday 19 February 2013 22:03:53 Andreas Bombe wrote: When using libudev, it is actually libmediactl that uses it and not the media-ctl executable. libv4l2subdev uses functions from libmediactl and therefore needs to be linked against it. Signed-off-by: Andreas Bombe a...@debian.org Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com and pushed to the repository. --- In light of their relative simplicity as well as cross dependency, does it make sense to keep libmediactl and libv4l2subdev as separate libraries? I think it does, as libmediactl is supposed to be media-agnostic. I'm working on a media device enumeration library that will likely result in all those libraries being rearchitectured, I'll keep the question in mind. src/Makefile.am |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 2583464..f754763 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1,12 +1,12 @@ lib_LTLIBRARIES = libmediactl.la libv4l2subdev.la libmediactl_la_SOURCES = mediactl.c +libmediactl_la_CFLAGS = $(LIBUDEV_CFLAGS) +libmediactl_la_LDFLAGS = $(LIBUDEV_LIBS) libv4l2subdev_la_SOURCES = v4l2subdev.c +libv4l2subdev_la_LIBADD = libmediactl.la mediactl_includedir=$(includedir)/mediactl mediactl_include_HEADERS = mediactl.h v4l2subdev.h bin_PROGRAMS = media-ctl -media_ctl_CFLAGS = $(LIBUDEV_CFLAGS) -media_ctl_LDFLAGS = $(LIBUDEV_LIBS) media_ctl_SOURCES = main.c options.c options.h tools.h media_ctl_LDADD = libmediactl.la libv4l2subdev.la - -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dmxdev: Unable to handle kernel paging request
Every few days/weeks I see Oopses like the attached one. I tried to track down the problem, but with added debug printk's the error didn't occur. I'm using em28xx and dib0700 based dvb sticks at an armv5te system (Marvell Kirkwood), the user application is vdr. Any ideas what is wrong or who can help here? Thanks, Soeren Mar 25 21:47:00 guruvdr kernel: Unable to handle kernel paging request at virtual address e2134000 Mar 25 21:47:00 guruvdr kernel: pgd = def2c000 Mar 25 21:47:00 guruvdr kernel: [e2134000] *pgd=1ef4b811, *pte=, *ppte= Mar 25 21:47:00 guruvdr kernel: Internal error: Oops: 7 [#1] PREEMPT ARM Mar 25 21:47:00 guruvdr kernel: Modules linked in: uap8xxx em28xx_dvb tda18271c2dd drxk tda18271 dvb_usb_dib0700 em28xx tveeprom videobuf_vmalloc videobuf_core Mar 25 21:47:00 guruvdr kernel: CPU: 0Not tainted (3.8.0-guruvdr #42) Mar 25 21:47:00 guruvdr kernel: PC is at memcpy+0x320/0x3a4 Mar 25 21:47:00 guruvdr kernel: LR is at 0x50100 Mar 25 21:47:00 guruvdr kernel: pc : [c0172980]lr : [00050100]psr: 2013 Mar 25 21:47:00 guruvdr kernel: sp : dedabe50 ip : 616c4b05 fp : dedabe9c Mar 25 21:47:00 guruvdr kernel: r10: r9 : 2c6f6d69 r8 : 73736974 Mar 25 21:47:00 guruvdr kernel: r7 : 73657250 r6 : 206d4905 r5 : 0f756564 r4 : 404dd200 Mar 25 21:47:00 guruvdr kernel: r3 : r2 : 0020 r1 : e2133ff4 r0 : afffdf40 Mar 25 21:47:00 guruvdr kernel: Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Mar 25 21:47:00 guruvdr kernel: Control: 0005397f Table: 1ef2c000 DAC: 0015 Mar 25 21:47:00 guruvdr kernel: Process section handler (pid: 2110, stack limit = 0xdedaa1b8) Mar 25 21:47:00 guruvdr kernel: Stack: (0xdedabe50 to 0xdedac000) Mar 25 21:47:00 guruvdr kernel: be40: 049b afffde77 0189 e2133f1a Mar 25 21:47:00 guruvdr kernel: be60: afffde77 dedaa000 c017bff4 ddbcc7f4 ded50338 e17b9054 afffde77 Mar 25 21:47:00 guruvdr kernel: be80: 049b 0587 0587 0003 dedabeac dedabea0 c017c084 c017bf1c Mar 25 21:47:00 guruvdr kernel: bea0: dedabecc dedabeb0 c029a8d8 c017c074 e17b9054 afffdd8b 0587 dedaa000 Mar 25 21:47:00 guruvdr kernel: bec0: dedabf1c dedabed0 c0291dbc c029a820 0800 dedabee8 c07624c8 Mar 25 21:47:00 guruvdr kernel: bee0: c0745728 0013 0080 dedabf50 e17b9000 afffdd8b deed5180 Mar 25 21:47:00 guruvdr kernel: bf00: 0ffd 0003 e17b9070 0003 dedabf4c dedabf20 c0291f90 c0291c8c Mar 25 21:47:00 guruvdr kernel: bf20: dedabf80 1000 deed5180 afffdd88 dedabf80 c000dce4 dedaa000 Mar 25 21:47:00 guruvdr kernel: bf40: dedabf7c dedabf50 c008eba8 c0291e70 dedabf7c dedabf60 c00a82a0 deed5180 Mar 25 21:47:00 guruvdr kernel: bf60: 0001 afffdd88 1000 c000dce4 dedabfa4 dedabf80 c008ec6c c008eb00 Mar 25 21:47:00 guruvdr kernel: bf80: 002d 1000 afffdd88 0003 dedabfa8 Mar 25 21:47:00 guruvdr kernel: bfa0: c000db80 c008ec34 002d 1000 002d afffdd88 1000 1000 Mar 25 21:47:00 guruvdr kernel: bfc0: 002d 1000 afffdd88 0003 001270c8 0006 00d40d98 afffedb4 Mar 25 21:47:00 guruvdr kernel: bfe0: afffdcf8 b6f00f74 b6f00f84 8010 002d 1fffe831 1fffec31 Mar 25 21:47:00 guruvdr kernel: Backtrace: Mar 25 21:47:00 guruvdr kernel: [c017bf0c] (__copy_to_user_memcpy+0x0/0x158) from [c017c084] (__copy_to_user+0x20/0x24) Mar 25 21:47:00 guruvdr kernel: [c017c064] (__copy_to_user+0x0/0x24) from [c029a8d8] (dvb_ringbuffer_read_user+0xc8/0xfc) Mar 25 21:47:00 guruvdr kernel: [c029a810] (dvb_ringbuffer_read_user+0x0/0xfc) from [c0291dbc] (dvb_dmxdev_buffer_read.isra.8+0x140/0x19c) Mar 25 21:47:00 guruvdr kernel: r7:dedaa000 r6:0587 r5:afffdd8b r4:e17b9054 Mar 25 21:47:00 guruvdr kernel: [c0291c7c] (dvb_dmxdev_buffer_read.isra.8+0x0/0x19c) from [c0291f90] (dvb_demux_read+0x130/0x180) Mar 25 21:47:00 guruvdr kernel: [c0291e60] (dvb_demux_read+0x0/0x180) from [c008eba8] (vfs_read+0xb8/0x134) Mar 25 21:47:00 guruvdr kernel: [c008eaf0] (vfs_read+0x0/0x134) from [c008ec6c] (sys_read+0x48/0x70) Mar 25 21:47:00 guruvdr kernel: r8:c000dce4 r7:1000 r6:afffdd88 r5:0001 r4:deed5180 Mar 25 21:47:00 guruvdr kernel: [c008ec24] (sys_read+0x0/0x70) from [c000db80] (ret_fast_syscall+0x0/0x2c) Mar 25 21:47:00 guruvdr kernel: r7:0003 r6:afffdd88 r5:1000 r4:002d Mar 25 21:47:00 guruvdr kernel: Code: f5d1f07c e8b100f0 e1a03c2e e2522020 (e8b15300) Mar 25 21:47:00 guruvdr kernel: ---[ end trace ad119c47b9c422ea ]--- Mar 25 21:47:00 guruvdr kernel: note: section handler[2110] exited with preempt_count 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] [media] s5p-mfc: Change MFC clock reference w.r.t Common Clock Framework
From: Prasanna Kumar prasanna...@samsung.com
According to Common Clock framework , modified the method of getting
clock for MFC Block.
Signed-off-by: Prasanna Kumar prasanna...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
index 6aa38a5..b8ac8f6 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
@@ -50,7 +50,7 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
goto err_p_ip_clk;
}
- pm-clock = clk_get(dev-plat_dev-dev, dev-variant-mclk_name);
+ pm-clock = clk_get_parent(pm-clock_gate);
if (IS_ERR(pm-clock)) {
mfc_err(Failed to get MFC clock\n);
ret = PTR_ERR(pm-clock);
--
1.7.5.4
--
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 -next] [media] af9035: fix missing unlock on error in af9035_ctrl_msg()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing unlock before return from function af9035_ctrl_msg()
in the error handling case.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/media/usb/dvb-usb-v2/af9035.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
b/drivers/media/usb/dvb-usb-v2/af9035.c
index b1f7059..b638fc1 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -57,7 +57,7 @@ static int af9035_ctrl_msg(struct dvb_usb_device *d, struct
usb_req *req)
dev_err(d-udev-dev, %s: too much data wlen=%d rlen=%d\n,
__func__, req-wlen, req-rlen);
ret = -EINVAL;
- goto err;
+ goto exit;
}
state-buf[0] = REQ_HDR_LEN + req-wlen + CHECKSUM_LEN - 1;
@@ -81,7 +81,7 @@ static int af9035_ctrl_msg(struct dvb_usb_device *d, struct
usb_req *req)
ret = dvb_usbv2_generic_rw_locked(d,
state-buf, wlen, state-buf, rlen);
if (ret)
- goto err;
+ goto exit;
/* no ack for those packets */
if (req-cmd == CMD_FW_DL)
@@ -95,28 +95,29 @@ static int af9035_ctrl_msg(struct dvb_usb_device *d, struct
usb_req *req)
(%04x != %04x)\n, KBUILD_MODNAME, req-cmd,
tmp_checksum, checksum);
ret = -EIO;
- goto err;
+ goto exit;
}
/* check status */
if (state-buf[2]) {
/* fw returns status 1 when IR code was not received */
- if (req-cmd == CMD_IR_GET || state-buf[2] == 1)
- return 1;
+ if (req-cmd == CMD_IR_GET || state-buf[2] == 1) {
+ ret = 1;
+ goto exit;
+ }
dev_dbg(d-udev-dev, %s: command=%02x failed fw error=%d\n,
__func__, req-cmd, state-buf[2]);
ret = -EIO;
- goto err;
+ goto exit;
}
/* read request, copy returned data to return buf */
if (req-rlen)
memcpy(req-rbuf, state-buf[ACK_HDR_LEN], req-rlen);
exit:
-err:
mutex_unlock(d-usb_mutex);
- if (ret)
+ if (ret 0)
dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
return ret;
}
--
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 -next] [media] go7007: remove unused including linux/version.h
From: Wei Yongjun yongjun_...@trendmicro.com.cn Remove including linux/version.h that don't need it. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn --- drivers/staging/media/go7007/go7007-v4l2.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/media/go7007/go7007-v4l2.c b/drivers/staging/media/go7007/go7007-v4l2.c index 24ba50e..50eb69a 100644 --- a/drivers/staging/media/go7007/go7007-v4l2.c +++ b/drivers/staging/media/go7007/go7007-v4l2.c @@ -17,7 +17,6 @@ #include linux/module.h #include linux/init.h -#include linux/version.h #include linux/delay.h #include linux/sched.h #include linux/spinlock.h -- 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 -next] [media] tw9906: remove unused including linux/version.h
From: Wei Yongjun yongjun_...@trendmicro.com.cn Remove including linux/version.h that don't need it. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn --- drivers/media/i2c/tw9906.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/i2c/tw9906.c b/drivers/media/i2c/tw9906.c index 2263a91..d94325b 100644 --- a/drivers/media/i2c/tw9906.c +++ b/drivers/media/i2c/tw9906.c @@ -17,7 +17,6 @@ #include linux/module.h #include linux/init.h -#include linux/version.h #include linux/i2c.h #include linux/videodev2.h #include linux/ioctl.h -- 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
