RE: [GIT PULL FOR 3.10] DiBxxxx: fixes and improvements
Hello Mauro,
can you apply the attached patch. This patch correct the proposed patch by
Patrick for the dib807x. Sorry to not have seen it before.
regards,
Olivier
From: Mauro Carvalho Chehab [mche...@redhat.com]
Sent: Saturday, April 27, 2013 4:28 PM
To: Patrick Boettcher
Cc: linux-media@vger.kernel.org; Olivier GRENIE; Patrick BOETTCHER
Subject: Re: [GIT PULL FOR 3.10] DiB: fixes and improvements
Hi Patrick,
Em Mon, 22 Apr 2013 10:12:34 +0200
Patrick Boettcher escreveu:
> Hi Mauro,
>
> These patches contains some fixes and changes for the DiBcom demods and
> SIPs.
>
> Please merge for 3.10 if possible.
>
>
> The following changes since commit 60d509fa6a9c4653a86ad830e4c4b30360b23f0e:
>
> Linux 3.9-rc8 (2013-04-21 14:38:45 -0700)
>
> are available in the git repository at:
>
> git://git.linuxtv.org/pb/media_tree.git/ master
Hmm... I suspect that there's something wrong with those changes.
Testing it with a dib8076 usb stick seems that the code is worse than
before, as it is now harder to get a lock here.
With the previous code:
INFO Scanning frequency #1 725142857
Carrier(0x03) Signal= 67.46% C/N= 0.00% UCB= 0 postBER= 0
Viterbi(0x05) Signal= 67.08% C/N= 0.00% UCB= 0 postBER= 2097151
Viterbi(0x07) Signal= 67.54% C/N= 0.25% UCB= 165 postBER= 0
Sync (0x0f) Signal= 67.06% C/N= 0.23% UCB= 151 postBER= 0
Lock (0x1f) Signal= 67.58% C/N= 0.24% UCB= 160 postBER= 338688
Service #0 (60320) BAND HD channel 57.1.0
Service #1 (60345) BAND 1SEG channel 57.1.1
With the new code:
INFO Scanning frequency #1 725142857
(0x00) Signal= 68.80% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.78% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.69% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.82% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.29% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.27% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.28% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.27% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.55% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.50% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.43% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.65% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.75% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.29% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.28% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.25% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.43% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.46% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.43% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.90% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.50% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.28% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.22% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.22% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.43% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.41% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.41% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 68.96% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.42% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.24% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.22% C/N= 0.00% UCB= 0 postBER= 0
RF (0x01) Signal= 69.25% C/N= 0.00% UCB= 0 postBER= 0
So, it seems that the changes broke something.
Regards,
MauroFrom 6d5679558aa99d9763fb2d638de771a8f52c94fa Mon Sep 17 00:00:00 2001
From: Olivier Grenie
Date: Thu, 2 May 2013 16:11:14 +0200
Subject: [PATCH] [media] dib8000: correct previous commit The intend of this
patch is to correct a previous commit. This commit corrects
the behavior of the dib807x.
Signed-off-by: Olivier Grenie
---
drivers/media/dvb-frontends/dib8000.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/dib8000.c b/drivers/media/dvb-frontends/dib8000.c
index 4ba7c90..a57926b 100644
--- a/drivers/media/dvb-frontends/dib8000.c
+++ b/drivers/media/dvb-frontends/dib8000.c
@@ -2439,7 +2439,7 @@ static int dib8000_autosearch_start(struct dvb_frontend *fe)
if (state->revision == 0x8090)
internal = dib8000_read32(state, 23) / 1000;
- if (state->autosearch_state == AS_SEARCHING_FFT) {
+ if ((state->revision >= 0x8002) && (state->autosearch_state == AS_SEARCHING_FFT)) {
dib8000_write_word(state, 37, 0x0065); /* P_ctrl_pha_off_max default values */
dib8000_write_word(state, 116, 0x); /* P_ana_gain to 0 */
@@ -2475,7 +2475,7 @@ static int dib8000_autosearch_start(struct dvb_frontend *fe)
dib8000_write_word(state, 770, (dib8000_read_word(state, 770) & 0xdfff) | (1 << 13)); /* P_restart_ccg = 1 */
dib8000_write_word(state, 770, (dib8000_read_word(state, 770) & 0xdfff) | (0 << 13)); /* P_restart_ccg = 0 */
dib8000_write_word(state, 0, (dib8000_read_word(state, 0) & 0x7ff)
Re: [PATCH] [media] uvcvideo: Retry usb_submit_urb on -EPERM return
Hi Laurent,
Thanks for the changes! I agree that your synchronization logic is
correct. Just two small comments:
On Mon, Apr 29, 2013 at 1:34 PM, Laurent Pinchart
wrote:
> Hi Shawn,
>
> Thank you for the patch.
>
> On Tuesday 23 April 2013 17:42:32 Shawn Nematbakhsh wrote:
>> While usb_kill_urb is in progress, calls to usb_submit_urb will fail
>> with -EPERM (documented in Documentation/usb/URB.txt). The UVC driver
>> does not correctly handle this case -- there is no synchronization
>> between uvc_v4l2_open / uvc_status_start and uvc_v4l2_release /
>> uvc_status_stop.
>
> Wouldn't it be better to synchronize status operations in open/release ?
> Something like the following patch:
>
> From 9285d678ed2f823bb215f6bdec3ca1a9e1cac977 Mon Sep 17 00:00:00 2001
> From: Laurent Pinchart
> Date: Fri, 26 Apr 2013 03:28:51 +0200
> Subject: [PATCH] uvcvideo: Fix open/close race condition
>
> Maintaining the users count using an atomic variable makes sure that
> access to the counter won't be racy, but doesn't serialize access to the
> operations protected by the counter. This creates a race condition that
> could result in the status URB being submitted multiple times.
>
> Use a mutex to protect the users count and serialize access to the
> status start and stop operations.
>
> Reported-by: Shawn Nematbakhsh
> Signed-off-by: Laurent Pinchart
> ---
> drivers/media/usb/uvc/uvc_driver.c | 22 --
> drivers/media/usb/uvc/uvc_status.c | 21 ++---
> drivers/media/usb/uvc/uvc_v4l2.c | 14 ++
> drivers/media/usb/uvc/uvcvideo.h | 7 +++
> 4 files changed, 31 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c
> index e68fa53..b638037 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1836,8 +1836,8 @@ static int uvc_probe(struct usb_interface *intf,
> INIT_LIST_HEAD(&dev->chains);
> INIT_LIST_HEAD(&dev->streams);
> atomic_set(&dev->nstreams, 0);
> - atomic_set(&dev->users, 0);
I think dev->users is uninitialized now? Probably we should initialize
to 0 here.
> atomic_set(&dev->nmappings, 0);
> + mutex_init(&dev->lock);
>
> dev->udev = usb_get_dev(udev);
> dev->intf = usb_get_intf(intf);
> @@ -1953,8 +1953,12 @@ static int uvc_suspend(struct usb_interface *intf,
> pm_message_t message)
>
> /* Controls are cached on the fly so they don't need to be saved. */
> if (intf->cur_altsetting->desc.bInterfaceSubClass ==
> - UVC_SC_VIDEOCONTROL)
> - return uvc_status_suspend(dev);
> + UVC_SC_VIDEOCONTROL) {
> + mutex_lock(&dev->lock);
> + if (dev->users)
> + uvc_status_stop(dev);
> + mutex_unlock(&dev->lock);
To keep the same control flow, should we return here?
> + }
>
> list_for_each_entry(stream, &dev->streams, list) {
> if (stream->intf == intf)
> @@ -1976,14 +1980,20 @@ static int __uvc_resume(struct usb_interface *intf,
> int reset)
>
> if (intf->cur_altsetting->desc.bInterfaceSubClass ==
> UVC_SC_VIDEOCONTROL) {
> - if (reset) {
> - int ret = uvc_ctrl_resume_device(dev);
> + int ret = 0;
>
> + if (reset) {
> + ret = uvc_ctrl_resume_device(dev);
> if (ret < 0)
> return ret;
> }
>
> - return uvc_status_resume(dev);
> + mutex_lock(&dev->lock);
> + if (dev->users)
> + ret = uvc_status_start(dev, GFP_NOIO);
> + mutex_unlock(&dev->lock);
> +
> + return ret;
> }
>
> list_for_each_entry(stream, &dev->streams, list) {
> diff --git a/drivers/media/usb/uvc/uvc_status.c
> b/drivers/media/usb/uvc/uvc_status.c
> index b749277..f552ab9 100644
> --- a/drivers/media/usb/uvc/uvc_status.c
> +++ b/drivers/media/usb/uvc/uvc_status.c
> @@ -206,32 +206,15 @@ void uvc_status_cleanup(struct uvc_device *dev)
> uvc_input_cleanup(dev);
> }
>
> -int uvc_status_start(struct uvc_device *dev)
> +int uvc_status_start(struct uvc_device *dev, gfp_t flags)
> {
> if (dev->int_urb == NULL)
> return 0;
>
> - return usb_submit_urb(dev->int_urb, GFP_KERNEL);
> + return usb_submit_urb(dev->int_urb, flags);
> }
>
> void uvc_status_stop(struct uvc_device *dev)
> {
> usb_kill_urb(dev->int_urb);
> }
> -
> -int uvc_status_suspend(struct uvc_device *dev)
> -{
> - if (atomic_read(&dev->users))
> - usb_kill_urb(dev->int_urb);
> -
> - return 0;
> -}
> -
> -int uvc_status_resume(struct uvc_device *dev)
> -{
> - if (dev->int_urb == NULL || atomic_read(&dev->users) == 0)
> - return 0;
> -
> - return usb_submit
Re: Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c
On Fri, May 3, 2013 at 3:50 PM, The Bit Pit wrote: > I am Wilson Michaels, please let me introduce myself: > > Eight years ago I contributed a driver for the DViCO FusionHDTV 3 & 5 > PCI TV tuner cards (see lgdt330x.c). The code is still in linux today. > One of my tuners is starting to fail so a purchased a KWorld UB435Q > Version 3 (ATSC) from Newegg. It's not supported so I started working > on a driver. Is anyone else working on a driver for the KWorld UB435Q V-3? > > I opened the case easily as it just snaps together with a plastic clip. > It is not glued :-) I verified that it contains: > EM2874B > NXP TDA18272/M > lgdt3305 > > I git the latest media_build tree and added entries to make it recognize > the KWorld USB id: 1b80:e34c. The added code is like the KWorld UB435Q > Version 2 code with lgdt3304 replaced by lgdt3305 and no .dvb_gpio or > .tuner_gpio. It reports finding an em2874 chip using bulk transfer mode > as expected. No bulk support currently for em28xx dvb. I never got around to it because the only sticks I ever came across them that use them is that particular KWorld model, and from everything I've heard it's a piece of garbage (unreliable, prone to failure even under WIndows). That said, a bulk endpoint driver isn't rocket science to add support for. :-) > There appears to be code in the em28xx driver to handle > bulk transfer. It does not recognize the lgdt3305. The lgdt3305 is probably on the second i2c bus -- typical for em2874 based devices. The tuner is probably gated behind the 3305. It's also likely that the 3305 is being held in reset by default. You'll probably need to tweak a GPIO to take it out of reset before it will answer i2c. > I discovered (brute force scan) that there are two i2c addresses 0x50 > and 0xd0. The lgdt3305 detection code is able to read something from > either i2c address, but is is always 0. One is probably the eeprom. > Does the eeprom data below have anything to help writing a driver for > the KWorld UB435Q? Almost certainly not. > I suspect some initialization needs to be done, but I don't know what to > try. Does anyone have any information about how the hardware is > configured or information captured from the Windows driver? > > Does anyone know where I can get a copy of the programming spec for the > lgdt3305? The em2874 spec would be useful too. I have them both, but under NDA (neither are publicly available). You probably don't need either though. Aside from the bulk support, the em2874 implementation is pretty complete. Same goes for the 3305. 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
[PATCH] [media] dib8000: Fix dib8000_set_frontend() never setting ret
drivers/media/dvb-frontends/dib8000.c: In function ‘dib8000_set_frontend’:
drivers/media/dvb-frontends/dib8000.c:3556: warning: ‘ret’ is used
uninitialized in this function
Remove the variable and return zero instead.
Signed-off-by: Geert Uytterhoeven
---
drivers/media/dvb-frontends/dib8000.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-frontends/dib8000.c
b/drivers/media/dvb-frontends/dib8000.c
index a54182d..9053614 100644
--- a/drivers/media/dvb-frontends/dib8000.c
+++ b/drivers/media/dvb-frontends/dib8000.c
@@ -3406,7 +3406,7 @@ static int dib8000_set_frontend(struct dvb_frontend *fe)
{
struct dib8000_state *state = fe->demodulator_priv;
struct dtv_frontend_properties *c = &state->fe[0]->dtv_property_cache;
- int l, i, active, time, ret, time_slave = FE_CALLBACK_TIME_NEVER;
+ int l, i, active, time, time_slave = FE_CALLBACK_TIME_NEVER;
u8 exit_condition, index_frontend;
u32 delay, callback_time;
@@ -3553,7 +3553,7 @@ static int dib8000_set_frontend(struct dvb_frontend *fe)
}
}
- return ret;
+ return 0;
}
static int dib8000_read_status(struct dvb_frontend *fe, fe_status_t * stat)
--
1.7.0.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] [it913x] Add support for 'Digital Dual TV Receiver CTVDIGDUAL v2
Tested on a MIPSel box with 3.3.6 kernel
The kernel output when the device will be detected follows:
usbcore: registered new interface driver dvb_usb_it913x
it913x: Chip Version=01 Chip Type=9135
it913x: Remote propriety (raw) mode
it913x: Dual mode=3 Tuner Type=38
it913x: Chip Version=01 Chip Type=9135
usb 2-1: dvb_usb_v2: found a 'Digital Dual TV Receiver CTVDIGDUAL_V2' in cold
state
usb 2-1: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9137-01.fw'
it913x: FRM Starting Firmware Download
it913x: FRM Firmware Download Completed - Resetting Device
it913x: Chip Version=01 Chip Type=9135
it913x: Firmware Version 204147968
usb 2-1: dvb_usb_v2: found a 'Digital Dual TV Receiver CTVDIGDUAL_V2' in warm
state
usb 2-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the
software demuxer
DVB: registering new adapter (Digital Dual TV Receiver CTVDIGDUAL_V2)
it913x-fe: ADF table value :00
it913x-fe: Crystal Frequency :1200 Adc Frequency :2025 ADC X2: 00
it913x-fe: Tuner LNA type :38
usb 2-1: DVB: registering adapter 1 frontend 0 (Digital Dual TV Receiver
CTVDIGDUAL_V2_1)...
usb 2-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the
software demuxer
DVB: registering new adapter (Digital Dual TV Receiver CTVDIGDUAL_V2)
it913x-fe: ADF table value :00
it913x-fe: Crystal Frequency :1200 Adc Frequency :2025 ADC X2: 00
it913x-fe: Tuner LNA type :38
usb 2-1: DVB: registering adapter 2 frontend 0 (Digital Dual TV Receiver
CTVDIGDUAL_V2_2)...
usb 2-1: dvb_usb_v2: 'Digital Dual TV Receiver CTVDIGDUAL_V2' successfully
initialized and connected
RC part not tested
Signed-off-by: Alessandro Miceli
---
drivers/media/dvb-core/dvb-usb-ids.h |1 +
drivers/media/usb/dvb-usb-v2/it913x.c |5 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 335a8f4..2e0709a 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -367,4 +367,5 @@
#define USB_PID_TECHNISAT_USB2_HDCI_V2 0x0002
#define USB_PID_TECHNISAT_AIRSTAR_TELESTICK_2 0x0004
#define USB_PID_TECHNISAT_USB2_DVB_S2 0x0500
+#define USB_PID_CTVDIGDUAL_V2 0xe410
#endif
diff --git a/drivers/media/usb/dvb-usb-v2/it913x.c
b/drivers/media/usb/dvb-usb-v2/it913x.c
index e48cdeb..1cb6899 100644
--- a/drivers/media/usb/dvb-usb-v2/it913x.c
+++ b/drivers/media/usb/dvb-usb-v2/it913x.c
@@ -45,7 +45,7 @@ MODULE_PARM_DESC(debug, "set debugging level (1=info
(or-able)).");
static int dvb_usb_it913x_firmware;
module_param_named(firmware, dvb_usb_it913x_firmware, int, 0644);
-MODULE_PARM_DESC(firmware, "set firmware 0=auto"\
+MODULE_PARM_DESC(firmware, "set firmware 0=auto "\
"1=IT9137 2=IT9135 V1 3=IT9135 V2");
#define FW_IT9137 "dvb-usb-it9137-01.fw"
#define FW_IT9135_V1 "dvb-usb-it9135-01.fw"
@@ -796,6 +796,9 @@ static const struct usb_device_id it913x_id_table[] = {
{ DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A835B_4835,
&it913x_properties, "Avermedia A835B(4835)",
RC_MAP_IT913X_V2) },
+ { DVB_USB_DEVICE(USB_VID_KWORLD_2, USB_PID_CTVDIGDUAL_V2,
+ &it913x_properties, "Digital Dual TV Receiver CTVDIGDUAL_V2",
+ RC_MAP_IT913X_V1) },
{} /* Terminating entry */
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c
I am Wilson Michaels, please let me introduce myself: Eight years ago I contributed a driver for the DViCO FusionHDTV 3 & 5 PCI TV tuner cards (see lgdt330x.c). The code is still in linux today. One of my tuners is starting to fail so a purchased a KWorld UB435Q Version 3 (ATSC) from Newegg. It's not supported so I started working on a driver. Is anyone else working on a driver for the KWorld UB435Q V-3? I opened the case easily as it just snaps together with a plastic clip. It is not glued :-) I verified that it contains: EM2874B NXP TDA18272/M lgdt3305 I git the latest media_build tree and added entries to make it recognize the KWorld USB id: 1b80:e34c. The added code is like the KWorld UB435Q Version 2 code with lgdt3304 replaced by lgdt3305 and no .dvb_gpio or .tuner_gpio. It reports finding an em2874 chip using bulk transfer mode as expected. There appears to be code in the em28xx driver to handle bulk transfer. It does not recognize the lgdt3305. I discovered (brute force scan) that there are two i2c addresses 0x50 and 0xd0. The lgdt3305 detection code is able to read something from either i2c address, but is is always 0. Does the eeprom data below have anything to help writing a driver for the KWorld UB435Q? I suspect some initialization needs to be done, but I don't know what to try. Does anyone have any information about how the hardware is configured or information captured from the Windows driver? Does anyone know where I can get a copy of the programming spec for the lgdt3305? The em2874 spec would be useful too. Here is the dmsg after plugging in the KWorld UB435Q v-3: [ 566.649812] hub 1-1:1.0: state 7 ports 6 chg evt 0010 [ 566.650257] hub 1-1:1.0: port 4, status 0101, change 0001, 12 Mb/s [ 566.753819] hub 1-1:1.0: debounce: port 4: total 100ms stable 100ms status 0x101 [ 566.764810] hub 1-1:1.0: port 4 not reset yet, waiting 10ms [ 566.826760] usb 1-1.4: new high-speed USB device number 4 using ehci_hcd [ 566.837765] hub 1-1:1.0: port 4 not reset yet, waiting 10ms [ 566.912465] usb 1-1.4: default language 0x0409 [ 566.912830] usb 1-1.4: udev 4, busnum 1, minor = 3 [ 566.912836] usb 1-1.4: New USB device found, idVendor=1b80, idProduct=e34c [ 566.912838] usb 1-1.4: New USB device strings: Mfr=0, Product=1, SerialNumber=2 [ 566.912841] usb 1-1.4: Product: USB 2875 Device [ 566.912844] usb 1-1.4: SerialNumber: 1 [ 566.912930] usb 1-1.4: usb_probe_device [ 566.912932] usb 1-1.4: configuration #1 chosen from 1 choice [ 566.913034] usb 1-1.4: adding 1-1.4:1.0 (config #1, interface 0) [ 566.962815] em28xx 1-1.4:1.0: usb_probe_interface [ 566.962818] em28xx 1-1.4:1.0: usb_probe_interface - got id [ 566.962822] em28xx: New device USB 2875 Device @ 480 Mbps (1b80:e34c, interface 0, class 0) [ 566.962823] em28xx: DVB interface 0 found: bulk [ 566.962916] em28xx: chip ID is em2874 [ 567.037248] em2874 #0: i2c eeprom : 26 00 01 00 02 09 0f e5 f5 64 01 60 09 e5 f5 64 [ 567.037260] em2874 #0: i2c eeprom 0010: 09 60 03 c2 c6 22 e5 f7 b4 03 13 e5 f6 b4 87 03 [ 567.037269] em2874 #0: i2c eeprom 0020: 02 08 a3 e5 f6 b4 93 03 02 07 58 c2 c6 22 c2 c6 [ 567.037278] em2874 #0: i2c eeprom 0030: 22 00 60 00 ef 70 08 85 3a 82 85 39 83 93 ff ef [ 567.037288] em2874 #0: i2c eeprom 0040: 60 19 85 3a 82 85 39 83 e4 93 12 06 67 12 08 f5 [ 567.037297] em2874 #0: i2c eeprom 0050: 05 3a e5 3a 70 02 05 39 1f 80 e4 22 12 08 fd 02 [ 567.037306] em2874 #0: i2c eeprom 0060: 06 02 02 00 1a eb 67 95 80 1b 4c e3 d0 13 6c 00 [ 567.037315] em2874 #0: i2c eeprom 0070: 6a 20 8a 04 00 00 24 57 00 5c 39 00 00 00 00 00 [ 567.037330] em2874 #0: i2c eeprom 0080: 00 00 00 00 44 00 00 00 f0 10 44 00 00 00 00 00 [ 567.037334] em2874 #0: i2c eeprom 0090: 5b 1c c0 00 00 00 20 40 20 80 02 20 01 01 00 00 [ 567.037338] em2874 #0: i2c eeprom 00a0: 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 [ 567.037342] em2874 #0: i2c eeprom 00b0: c6 40 00 00 00 00 87 00 00 80 00 00 00 00 00 00 [ 567.037346] em2874 #0: i2c eeprom 00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 03 [ 567.037349] em2874 #0: i2c eeprom 00d0: 55 00 53 00 42 00 20 00 32 00 38 00 37 00 35 00 [ 567.037353] em2874 #0: i2c eeprom 00e0: 20 00 44 00 65 00 76 00 69 00 63 00 65 00 04 03 [ 567.037357] em2874 #0: i2c eeprom 00f0: 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 567.037361] em2874 #0: i2c eeprom 0100: ... (skipped) [ 567.037363] em2874 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x5d3e97ab [ 567.037363] em2874 #0: EEPROM info: [ 567.037364] em2874 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 567.061606] em2874 #0: No audio on board. [ 567.061610] em2874 #0: 500mA max power [ 567.061612] em2874 #0: Table at offset 0x00, strings=0x, 0x, 0x [ 567.061615] em2874 #0: Identified as KWorld UB435-Q v-3 (ATSC) (card=89) [ 567.061618] em2874 #0: v4l2 driver version 0.2.0 [ 567.066790] em2874 #0: V4L2 video device registered as video2 [ 567.066792] em2874
[PATCH v2] solo6x10: Approximate frame intervals with non-standard denominator
Instead of falling back to 1/25 (PAL) or 1/30 (NTSC).
Signed-off-by: Ismael Luceno
---
drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 38 +-
1 file changed, 15 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
index 98e2902..a4c5896 100644
--- a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
+++ b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
@@ -996,12 +996,11 @@ static int solo_g_parm(struct file *file, void *priv,
struct v4l2_streamparm *sp)
{
struct solo_enc_dev *solo_enc = video_drvdata(file);
- struct solo_dev *solo_dev = solo_enc->solo_dev;
struct v4l2_captureparm *cp = &sp->parm.capture;
cp->capability = V4L2_CAP_TIMEPERFRAME;
cp->timeperframe.numerator = solo_enc->interval;
- cp->timeperframe.denominator = solo_dev->fps;
+ cp->timeperframe.denominator = solo_enc->solo_dev->fps;
cp->capturemode = 0;
/* XXX: Shouldn't we be able to get/set this from videobuf? */
cp->readbuffers = 2;
@@ -1009,36 +1008,29 @@ static int solo_g_parm(struct file *file, void *priv,
return 0;
}
+static inline int calc_interval(u8 fps, u32 n, u32 d)
+{
+ if (!n || !d)
+ return 1;
+ if (d == fps)
+ return n;
+ n *= fps;
+ return min(15U, n / d + (n % d >= (fps >> 1)));
+}
+
static int solo_s_parm(struct file *file, void *priv,
struct v4l2_streamparm *sp)
{
struct solo_enc_dev *solo_enc = video_drvdata(file);
- struct solo_dev *solo_dev = solo_enc->solo_dev;
- struct v4l2_captureparm *cp = &sp->parm.capture;
+ struct v4l2_fract *t = &sp->parm.capture.timeperframe;
+ u8 fps = solo_enc->solo_dev->fps;
if (vb2_is_streaming(&solo_enc->vidq))
return -EBUSY;
- if ((cp->timeperframe.numerator == 0) ||
- (cp->timeperframe.denominator == 0)) {
- /* reset framerate */
- cp->timeperframe.numerator = 1;
- cp->timeperframe.denominator = solo_dev->fps;
- }
-
- if (cp->timeperframe.denominator != solo_dev->fps)
- cp->timeperframe.denominator = solo_dev->fps;
-
- if (cp->timeperframe.numerator > 15)
- cp->timeperframe.numerator = 15;
-
- solo_enc->interval = cp->timeperframe.numerator;
-
- cp->capability = V4L2_CAP_TIMEPERFRAME;
- cp->readbuffers = 2;
-
+ solo_enc->interval = calc_interval(fps, t->numerator, t->denominator);
solo_update_mode(solo_enc);
- return 0;
+ return solo_g_parm(file, priv, sp);
}
static long solo_enc_default(struct file *file, void *fh,
--
1.8.2.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
cron job: media_tree daily build: WARNINGS
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: Fri May 3 19:00:23 CEST 2013 git branch: test git hash: 02615ed5e1b2283db2495af3cf8f4ee172c77d80 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: WARNINGS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS 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: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-3.9-rc1-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS 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: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: OK linux-3.9-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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
Re: [PATCH RFC v3] media: i2c: mt9p031: add OF support
On Friday 03 May 2013, Prabhakar Lad wrote:
>
> +static struct mt9p031_platform_data *
> +mt9p031_get_pdata(struct i2c_client *client)
> +{
> + struct device_node *np;
> + struct mt9p031_platform_data *pdata;
> +
> + if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
> + return client->dev.platform_data;
> +
> + np = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
> + if (!np)
> + return NULL;
> +
> + pdata = devm_kzalloc(&client->dev, sizeof(struct
> mt9p031_platform_data),
> +GFP_KERNEL);
> + if (!pdata)
> + return NULL;
> +
> + pdata->reset = of_get_named_gpio(client->dev.of_node, "gpio-reset",
> 0);
> + of_property_read_u32(np, "input-clock-frequency", &pdata->ext_freq);
> + of_property_read_u32(np, "pixel-clock-frequency",
> &pdata->target_freq);
> +
> + return pdata;
> +}
Ok, good.
> @@ -955,7 +998,17 @@ static int mt9p031_probe(struct i2c_client *client,
> mt9p031->pdata = pdata;
> mt9p031->output_control = MT9P031_OUTPUT_CONTROL_DEF;
> mt9p031->mode2 = MT9P031_READ_MODE_2_ROW_BLC;
> - mt9p031->model = did->driver_data;
> +
> + if (!client->dev.of_node) {
> + mt9p031->model = (enum mt9p031_model)did->driver_data;
> + } else {
> + const struct of_device_id *of_id;
> +
> + of_id = of_match_device(of_match_ptr(mt9p031_of_match),
> + &client->dev);
> + if (of_id)
> + mt9p031->model = (enum mt9p031_model)of_id->data;
> + }
> mt9p031->reset = -1;
Is this actually required? I thought the i2c core just compared the
part of the "compatible" value after the first comma to the string, so
"mt9p031->model = (enum mt9p031_model)did->driver_data" should work
in both cases.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: davinci: vpbe: fix layer availability for NV12 format
Hello.
On 03-05-2013 13:53, Prabhakar Lad wrote:
From: Lad, Prabhakar
For NV12 format, even if display data is single image,
both VIDWIN0 and VIDWIN1 parameters must be used. The start
address of Y data plane and C data plane is configured in
VIDEOWIN0ADH/L and VIDEOWIN1ADH/L respectively.
cuurently only one layer was requested, which is suffice
for yuv422, but for yuv420(NV12) two layers are required and
fix the same by requesting for other layer if pix fmt is NV12
during set_fmt.
Signed-off-by: Lad, Prabhakar
---
drivers/media/platform/davinci/vpbe_display.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index 0341dcc..f2ee07b 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -922,6 +922,22 @@ static int vpbe_display_s_fmt(struct file *file, void
*priv,
other video window */
layer->pix_fmt = *pixfmt;
+ if (pixfmt->pixelformat == V4L2_PIX_FMT_NV12 &&
+ cpu_is_davinci_dm365()) {
cpu_is_*() shouldn't be used in the drivers.
+ struct vpbe_layer *otherlayer;
+
+ otherlayer = _vpbe_display_get_other_win_layer(disp_dev, layer);
+ /* if other layer is available, only
+ * claim it, do not configure it
+ */
+ ret = osd_device->ops.request_layer(osd_device,
+ otherlayer->layer_info.id);
+ if (ret < 0) {
+ v4l2_err(&vpbe_dev->v4l2_dev,
+"Display Manager failed to allocate layer\n");
+ return -EBUSY;
+ }
+ }
WBR, Sergei
--
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] it913x: add support for 'Digital Dual TV Receiver CTVDIGDUAL v2
This patch add support for 'Digital Dual TV Receiver CTVDIGDUAL v2.
It's tested with a MIPSEL Linux box with 3.3.6 kernel.
The kernel output text when the device is being detected is:
usbcore: registered new interface driver dvb_usb_it913x
it913x: Chip Version=01 Chip Type=9135
it913x: Remote propriety (raw) mode
it913x: Dual mode=3 Tuner Type=38
it913x: Chip Version=01 Chip Type=9135
usb 2-1: dvb_usb_v2: found a 'Digital Dual TV Receiver CTVDIGDUAL_V2'
in cold state
usb 2-1: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9137-01.fw'
it913x: FRM Starting Firmware Download
it913x: FRM Firmware Download Completed - Resetting Device
it913x: Chip Version=01 Chip Type=9135
it913x: Firmware Version 204147968
usb 2-1: dvb_usb_v2: found a 'Digital Dual TV Receiver CTVDIGDUAL_V2'
in warm state
usb 2-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to
the software demuxer
DVB: registering new adapter (Digital Dual TV Receiver CTVDIGDUAL_V2)
it913x-fe: ADF table value :00
it913x-fe: Crystal Frequency :1200 Adc Frequency :2025 ADC X2: 00
it913x-fe: Tuner LNA type :38
usb 2-1: DVB: registering adapter 1 frontend 0 (Digital Dual TV
Receiver CTVDIGDUAL_V2_1)...
usb 2-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to
the software demuxer
DVB: registering new adapter (Digital Dual TV Receiver CTVDIGDUAL_V2)
it913x-fe: ADF table value :00
it913x-fe: Crystal Frequency :1200 Adc Frequency :2025 ADC X2: 00
it913x-fe: Tuner LNA type :38
usb 2-1: DVB: registering adapter 2 frontend 0 (Digital Dual TV
Receiver CTVDIGDUAL_V2_2)...
usb 2-1: dvb_usb_v2: 'Digital Dual TV Receiver CTVDIGDUAL_V2'
successfully initialized and connected
RC part not tested
DVB-T services scan and tune works regularly.
Signed-off-by: Alessandro Miceli
---
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 335a8f4..2e0709a 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -367,4 +367,5 @@
#define USB_PID_TECHNISAT_USB2_HDCI_V2 0x0002
#define USB_PID_TECHNISAT_AIRSTAR_TELESTICK_2 0x0004
#define USB_PID_TECHNISAT_USB2_DVB_S2 0x0500
+#define USB_PID_CTVDIGDUAL_V2 0xe410
#endif
diff --git a/drivers/media/usb/dvb-usb-v2/it913x.c
b/drivers/media/usb/dvb-usb-v2/it913x.c
index e48cdeb..1cb6899 100644
--- a/drivers/media/usb/dvb-usb-v2/it913x.c
+++ b/drivers/media/usb/dvb-usb-v2/it913x.c
@@ -45,7 +45,7 @@ MODULE_PARM_DESC(debug, "set debugging level (1=info
(or-able)).");
static int dvb_usb_it913x_firmware;
module_param_named(firmware, dvb_usb_it913x_firmware, int, 0644);
-MODULE_PARM_DESC(firmware, "set firmware 0=auto"\
+MODULE_PARM_DESC(firmware, "set firmware 0=auto "\
"1=IT9137 2=IT9135 V1 3=IT9135 V2");
#define FW_IT9137 "dvb-usb-it9137-01.fw"
#define FW_IT9135_V1 "dvb-usb-it9135-01.fw"
@@ -796,6 +796,9 @@ static const struct usb_device_id it913x_id_table[] = {
{ DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A835B_4835,
&it913x_properties, "Avermedia A835B(4835)",
RC_MAP_IT913X_V2) },
+ { DVB_USB_DEVICE(USB_VID_KWORLD_2, USB_PID_CTVDIGDUAL_V2,
+ &it913x_properties, "Digital Dual TV Receiver CTVDIGDUAL_V2",
+ RC_MAP_IT913X_V1) },
{} /* Terminating entry */
};
--
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/3] saa7115: move the autodetection code out of the probe function
Em 03-05-2013 08:20, Ezequiel Garcia escreveu: Hi Jon, On Fri, May 03, 2013 at 08:58:46AM +0200, Jon Arne Jørgensen wrote: [...] You can read more about this in Documentation/SubmittingPatches. I just re-read SubmittingPatches. I couldn't see that there is anything wrong with multiple sign-off's. Indeed there isn't anything wrong with multiple SOBs tags, but they're used a bit differently than this. Quote: The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path. Ah, I see your point. @Mauro, perhaps you can explain this better then me? The SOB is used mainly to describe the patch flow. Each one that touched on a patch attests that: "Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved." In other words, it tracks the custody chain, with is typically one of the alternatives below[1]: Author -> maintainer's tree -> upstream Author -> sub-maintainer's tree -> maintainer's tree -> upstream Author -> driver's maintainer -> maintainer's tree -> upstream Author -> driver's maintainer -> sub-maintainer's tree -> maintainer's tree -> upstream\ In this specific case, as patches 1 and 2 are identical to the ones I submitted, the right way would be for you both to just reply to my original e-mail with your tested-by or reviewed-by. That patches will then be applied (either directly or via Hverkuil's tree, as he is the sub-maintainer for those I2C drivers). I hope that helps to clarify it. Regards, Mauro [1] when the driver is developed/patched internally on some company's trees, it is possible to have there also the SOBs for that company's internal maintainers. There are also some other corner cases, like patches that are sent in non-public mailing lists or in private, where everybody in the custody chain sign it. -- 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 RESEND] media: davinci: vpbe: fix checkpatch warning for CamelCase
From: Lad, Prabhakar
This patch fixes checkpatch warning to avoid CamelCase.
Signed-off-by: Lad, Prabhakar
---
The initial version of this patch was a part of series, which
is intended to be dropped so sending this patch individually.
drivers/media/platform/davinci/vpbe_display.c |2 +-
drivers/media/platform/davinci/vpbe_osd.c | 24
include/media/davinci/vpbe_osd.h |4 ++--
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index 1802f11..1c4ba89 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -929,7 +929,7 @@ static int vpbe_display_s_fmt(struct file *file, void *priv,
cfg->interlaced = vpbe_dev->current_timings.interlaced;
if (V4L2_PIX_FMT_UYVY == pixfmt->pixelformat)
- cfg->pixfmt = PIXFMT_YCbCrI;
+ cfg->pixfmt = PIXFMT_YCBCRI;
/* Change of the default pixel format for both video windows */
if (V4L2_PIX_FMT_NV12 == pixfmt->pixelformat) {
diff --git a/drivers/media/platform/davinci/vpbe_osd.c
b/drivers/media/platform/davinci/vpbe_osd.c
index 396a51c..6ed82e8 100644
--- a/drivers/media/platform/davinci/vpbe_osd.c
+++ b/drivers/media/platform/davinci/vpbe_osd.c
@@ -119,7 +119,7 @@ static inline u32 osd_modify(struct osd_state *sd, u32
mask, u32 val,
#define is_rgb_pixfmt(pixfmt) \
(((pixfmt) == PIXFMT_RGB565) || ((pixfmt) == PIXFMT_RGB888))
#define is_yc_pixfmt(pixfmt) \
- (((pixfmt) == PIXFMT_YCbCrI) || ((pixfmt) == PIXFMT_YCrCbI) || \
+ (((pixfmt) == PIXFMT_YCBCRI) || ((pixfmt) == PIXFMT_YCRCBI) || \
((pixfmt) == PIXFMT_NV12))
#define MAX_WIN_SIZE OSD_VIDWIN0XP_V0X
#define MAX_LINE_LENGTH (OSD_VIDWIN0OFST_V0LO << 5)
@@ -360,8 +360,8 @@ static void _osd_enable_color_key(struct osd_state *sd,
osd_write(sd, colorkey & OSD_TRANSPVALL_RGBL,
OSD_TRANSPVALL);
break;
- case PIXFMT_YCbCrI:
- case PIXFMT_YCrCbI:
+ case PIXFMT_YCBCRI:
+ case PIXFMT_YCRCBI:
if (sd->vpbe_type == VPBE_VERSION_3)
osd_modify(sd, OSD_TRANSPVALU_Y, colorkey,
OSD_TRANSPVALU);
@@ -813,8 +813,8 @@ static int try_layer_config(struct osd_state *sd, enum
osd_layer layer,
if (osd->vpbe_type == VPBE_VERSION_1)
bad_config = !is_vid_win(layer);
break;
- case PIXFMT_YCbCrI:
- case PIXFMT_YCrCbI:
+ case PIXFMT_YCBCRI:
+ case PIXFMT_YCRCBI:
bad_config = !is_vid_win(layer);
break;
case PIXFMT_RGB888:
@@ -950,9 +950,9 @@ static void _osd_set_cbcr_order(struct osd_state *sd,
* The caller must ensure that all windows using YC pixfmt use the same
* Cb/Cr order.
*/
- if (pixfmt == PIXFMT_YCbCrI)
+ if (pixfmt == PIXFMT_YCBCRI)
osd_clear(sd, OSD_MODE_CS, OSD_MODE);
- else if (pixfmt == PIXFMT_YCrCbI)
+ else if (pixfmt == PIXFMT_YCRCBI)
osd_set(sd, OSD_MODE_CS, OSD_MODE);
}
@@ -981,8 +981,8 @@ static void _osd_set_layer_config(struct osd_state *sd,
enum osd_layer layer,
winmd |= (2 << OSD_OSDWIN0MD_BMP0MD_SHIFT);
_osd_enable_rgb888_pixblend(sd, OSDWIN_OSD0);
break;
- case PIXFMT_YCbCrI:
- case PIXFMT_YCrCbI:
+ case PIXFMT_YCBCRI:
+ case PIXFMT_YCRCBI:
winmd |= (3 << OSD_OSDWIN0MD_BMP0MD_SHIFT);
break;
default:
@@ -1128,8 +1128,8 @@ static void _osd_set_layer_config(struct osd_state *sd,
enum osd_layer layer,
_osd_enable_rgb888_pixblend(sd,
OSDWIN_OSD1);
break;
- case PIXFMT_YCbCrI:
- case PIXFMT_YCrCbI:
+ case PIXFMT_YCBCRI:
+ case PIXFMT_YCRCBI:
winmd |=
(3 << OSD_OSDWIN1MD_BMP1MD_SHIFT);
break;
@@ -1508,7 +1508,7 @@ static int osd_initialize(struct osd_state *osd)
_osd_init(osd);
/* set default Cb/Cr order */
- osd->yc_pixfmt = PIXFMT_YCbCrI;
+ osd->yc_pixfmt = PIXFMT_YCBCRI;
if (osd->vpbe_type == VPBE_VERSION_3) {
/*
diff --git a/include/media/davinci/vpbe_osd.h b/include/media/davinci/vpbe_osd.h
index 42628fc..de59364 100644
--- a/include/media/davinci/vpbe_os
Re: [PATCH V2 1/3] saa7115: move the autodetection code out of the probe function
Em 03-05-2013 03:32, Jon Arne Jørgensen escreveu: On Thu, May 02, 2013 at 11:09:14PM -0300, Ezequiel Garcia wrote: Hi Jon, On Mon, Apr 29, 2013 at 10:41:07PM +0200, Jon Arne Jørgensen wrote: As we're now seeing other variants from chinese clones, like gm1113c, we'll need to add more bits at the detection code. So, move it into a separate function. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jon Arne Jørgensen As far as I can see, this patch is identical to the one sent by Mauro. Therefore, your SOB here is incorrect, since you are not the author of the patch. The proper way of re-submitting patches that have been previously submitted by another developer is this: -- From: Mauro Carvalho Chehab Commit message goes here. Notice how the first line is a 'From:' tagcindicating who's the real submitter. The SOB tag indicates the patch author, and you can add your acked-by, tested-by or reported-by if you want. Signed-off-by: Mauro Carvalho Chehab Reported-by: Jon Arne Jørgensen Please also add here your Tested-by: if you tested (very likely you did it). The same applies to patch 2/3. -- You can read more about this in Documentation/SubmittingPatches. Ok, I'll fix this 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: [PATCH V2 1/3] saa7115: move the autodetection code out of the probe function
Hi Jon, On Fri, May 03, 2013 at 08:58:46AM +0200, Jon Arne Jørgensen wrote: [...] > > You can read more about this in Documentation/SubmittingPatches. > > I just re-read SubmittingPatches. > I couldn't see that there is anything wrong with multiple sign-off's. > Indeed there isn't anything wrong with multiple SOBs tags, but they're used a bit differently than this. > Quote: > The Signed-off-by: tag indicates that the signer was involved in the > development of the patch, or that he/she was in the patch's delivery > path. > > Ah, I see your point. @Mauro, perhaps you can explain this better then me? -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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: Terratec Grabby hwrev 2
Hi Jon, On Fri, May 03, 2013 at 11:13:17AM +0200, Jon Arne Jørgensen wrote: [...] > > I've tested the changes, and it doesn't seem to break/change the smi2021 > driver. > I'll append this to the pending saa7115 patch and ask Ezequiel Garcia to check > that the change doesn't break the stk1160 driver. > Wow, this gm7113c are starting to appear everywhere. Will you submit a v5 including this? In that case please drop my Tested-by from the 3/3 patch since I need to re-test that again. Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC 21/22] davinci: vpfe_capture needs i2c
Hi Arnd, Thanks for the patch. On Thu, May 2, 2013 at 8:46 PM, Arnd Bergmann wrote: > The vpfe_capture driver is implicitly built for three of the davinci > capture drivers but depends on i2c, so we need to add the dependency > in Kconfig for each driver using this. > > drivers/media/platform/davinci/vpfe_capture.c: In function 'vpfe_probe': > drivers/media/platform/davinci/vpfe_capture.c:1934:2: error: implicit > declaration of function 'i2c_get_adapter' > [-Werror=implicit-function-declaration] > drivers/media/platform/davinci/vpfe_capture.c:1934:11: warning: assignment > makes pointer from integer without a cast [enabled by default] > > Cc: Lad, Prabhakar > Cc: Hans Verkuil > Cc: Mauro Carvalho Chehab > Signed-off-by: Arnd Bergmann Acked-by: Lad, Prabhakar Regards, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media_build: enable uvcvideo starting from kernel 2.6.32
This patch already provides all the required compat bits: http://git.linuxtv.org/media_build.git/commit/d84f5306d8bd62ca0d8f49f06557c54573addaf4 Tested with the integrated webcam in my Dell Precision M6500 laptop on Ubuntu 10.04 with kernel 2.6.32 and the latest media_build drivers. Signed-off-by: Gianluca Gennari --- v4l/versions.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/v4l/versions.txt b/v4l/versions.txt index c541319..ea203b2 100644 --- a/v4l/versions.txt +++ b/v4l/versions.txt @@ -58,8 +58,6 @@ VIDEO_VIA_CAMERA [2.6.36] [2.6.35] -# Requires ss_ep_comp in usb_host_endpoint -USB_VIDEO_CLASS [2.6.34] MACH_DAVINCI_DM6467_EVM @@ -98,6 +96,8 @@ IR_ITE_CIR IR_FINTEK # Relies on i2c_lock_adapter DVB_DRXK +# Requires ss_ep_comp in usb_host_endpoint +USB_VIDEO_CLASS [2.6.31] # These rely on arch support that wasn't available until 2.6.31 -- 1.8.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Davinci fbdev driver and enable it for DMx platform
On Fri, May 3, 2013 at 3:25 PM, Sekhar Nori wrote: > On 4/26/2013 11:16 AM, Prabhakar Lad wrote: >> Hi Laurent, >> >> On Thu, Apr 25, 2013 at 2:32 AM, Laurent Pinchart >> wrote: >>> Hi Prabhakar, >>> >>> Thank you for the patch. >>> >>> On Wednesday 24 April 2013 17:30:02 Prabhakar Lad wrote: From: Lad, Prabhakar This patch series adds an fbdev driver for Texas Instruments Davinci SoC.The display subsystem consists of OSD and VENC, with OSD supporting 2 RGb planes and 2 video planes. http://focus.ti.com/general/docs/lit/ getliterature.tsp?literatureNumber=sprue37d&fileType=pdf A good amount of the OSD and VENC enabling code is present in the kernel, and this patch series adds the fbdev interface. The fbdev driver exports 4 nodes representing each plane to the user - from fb0 to fb3. >>> >>> The obvious question is: why not a KMS driver instead ? :-) >>> >> I did go through the KMS model (thanks for pointing to your work and the >> video) >> and it looks like this would require a fair amount of development, at this >> point >> of time I would go with the current implementation and revisit on KMS model >> at later point of time. > > But I doubt you will be able to sneak a new fbdev driver through. Last > time I heard, Andrew is only taking in fixes not new features. > Then we have no choice left and go with KMS driver itself though it would take some time since KMS is a new inclusion into DRM. Regards, --Prabhakar -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: i2c: tvp7002: enable TVP7002 decoder for media controller based usage
Hi Prabhakar,
Thank you for the patch.
On Friday 03 May 2013 13:47:19 Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> This patch enables tvp7002 decoder driver for media controller
> based usage by adding v4l2_subdev_pad_ops operations support
> for enum_mbus_code, set_pad_format, get_pad_format and media_entity_init()
> on probe and media_entity_cleanup() on remove.
>
> Signed-off-by: Lad, Prabhakar
Acked-by: Laurent Pinchart
> ---
> Changes for v2:
> 1: Fixed review comment pointed by Laurent, Don’t return error for set_fmt
> but fix the input parameters according to current timings.
>
> Changes for v3:
> 1: Fixed review comments pointed by Laurent.
>
> drivers/media/i2c/tvp7002.c | 96 ++--
> include/media/tvp7002.h |2 +
> 2 files changed, 93 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
> index 027809c..270e699 100644
> --- a/drivers/media/i2c/tvp7002.c
> +++ b/drivers/media/i2c/tvp7002.c
> @@ -424,6 +424,7 @@ struct tvp7002 {
> int streaming;
>
> const struct tvp7002_timings_definition *current_timings;
> + struct media_pad pad;
> };
>
> /*
> @@ -880,6 +881,65 @@ static const struct v4l2_ctrl_ops tvp7002_ctrl_ops = {
> .s_ctrl = tvp7002_s_ctrl,
> };
>
> +/*
> + * tvp7002_enum_mbus_code() - Enum supported digital video format on pad
> + * @sd: pointer to standard V4L2 sub-device structure
> + * @fh: file handle for the subdev
> + * @code: pointer to subdev enum mbus code struct
> + *
> + * Enumerate supported digital video formats for pad.
> + */
> +static int
> +tvp7002_enum_mbus_code(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
> +struct v4l2_subdev_mbus_code_enum *code)
> +{
> + /* Check requested format index is within range */
> + if (code->index != 0)
> + return -EINVAL;
> +
> + code->code = V4L2_MBUS_FMT_YUYV10_1X20;
> +
> + return 0;
> +}
> +
> +/*
> + * tvp7002_get_pad_format() - get video format on pad
> + * @sd: pointer to standard V4L2 sub-device structure
> + * @fh: file handle for the subdev
> + * @fmt: pointer to subdev format struct
> + *
> + * get video format for pad.
> + */
> +static int
> +tvp7002_get_pad_format(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
> +struct v4l2_subdev_format *fmt)
> +{
> + struct tvp7002 *tvp7002 = to_tvp7002(sd);
> +
> + fmt->format.code = V4L2_MBUS_FMT_YUYV10_1X20;
> + fmt->format.width = tvp7002->current_timings->timings.bt.width;
> + fmt->format.height = tvp7002->current_timings->timings.bt.height;
> + fmt->format.field = tvp7002->current_timings->scanmode;
> + fmt->format.colorspace = tvp7002->current_timings->color_space;
> +
> + return 0;
> +}
> +
> +/*
> + * tvp7002_set_pad_format() - set video format on pad
> + * @sd: pointer to standard V4L2 sub-device structure
> + * @fh: file handle for the subdev
> + * @fmt: pointer to subdev format struct
> + *
> + * set video format for pad.
> + */
> +static int
> +tvp7002_set_pad_format(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
> +struct v4l2_subdev_format *fmt)
> +{
> + return tvp7002_get_pad_format(sd, fh, fmt);
> +}
> +
> /* V4L2 core operation handlers */
> static const struct v4l2_subdev_core_ops tvp7002_core_ops = {
> .g_chip_ident = tvp7002_g_chip_ident,
> @@ -910,10 +970,18 @@ static const struct v4l2_subdev_video_ops
> tvp7002_video_ops = { .enum_mbus_fmt = tvp7002_enum_mbus_fmt,
> };
>
> +/* media pad related operation handlers */
> +static const struct v4l2_subdev_pad_ops tvp7002_pad_ops = {
> + .enum_mbus_code = tvp7002_enum_mbus_code,
> + .get_fmt = tvp7002_get_pad_format,
> + .set_fmt = tvp7002_set_pad_format,
> +};
> +
> /* V4L2 top level operation handlers */
> static const struct v4l2_subdev_ops tvp7002_ops = {
> .core = &tvp7002_core_ops,
> .video = &tvp7002_video_ops,
> + .pad = &tvp7002_pad_ops,
> };
>
> /*
> @@ -993,19 +1061,35 @@ static int tvp7002_probe(struct i2c_client *c, const
> struct i2c_device_id *id) timings = device->current_timings->timings;
> error = tvp7002_s_dv_timings(sd, &timings);
>
> +#if defined(CONFIG_MEDIA_CONTROLLER)
> + strlcpy(sd->name, TVP7002_MODULE_NAME, sizeof(sd->name));
> + device->pad.flags = MEDIA_PAD_FL_SOURCE;
> + device->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> + device->sd.entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
> +
> + error = media_entity_init(&device->sd.entity, 1, &device->pad, 0);
> + if (error < 0)
> + return error;
> +#endif
> +
> v4l2_ctrl_handler_init(&device->hdl, 1);
> v4l2_ctrl_new_std(&device->hdl, &tvp7002_ctrl_ops,
> V4L2_CID_GAIN, 0, 255, 1, 0);
> sd->ctrl_handler = &device->hdl;
> if (device->hdl.error) {
> - int err = device->hdl.error;
> -
> - v4l2_ctrl_handler_free(&device->hdl)
Re: [PATCH 0/6] Davinci fbdev driver and enable it for DMx platform
On 4/26/2013 11:16 AM, Prabhakar Lad wrote: > Hi Laurent, > > On Thu, Apr 25, 2013 at 2:32 AM, Laurent Pinchart > wrote: >> Hi Prabhakar, >> >> Thank you for the patch. >> >> On Wednesday 24 April 2013 17:30:02 Prabhakar Lad wrote: >>> From: Lad, Prabhakar >>> >>> This patch series adds an fbdev driver for Texas >>> Instruments Davinci SoC.The display subsystem consists >>> of OSD and VENC, with OSD supporting 2 RGb planes and >>> 2 video planes. >>> http://focus.ti.com/general/docs/lit/ >>> getliterature.tsp?literatureNumber=sprue37d&fileType=pdf >>> >>> A good amount of the OSD and VENC enabling code is >>> present in the kernel, and this patch series adds the >>> fbdev interface. >>> >>> The fbdev driver exports 4 nodes representing each >>> plane to the user - from fb0 to fb3. >> >> The obvious question is: why not a KMS driver instead ? :-) >> > I did go through the KMS model (thanks for pointing to your work and the > video) > and it looks like this would require a fair amount of development, at this > point > of time I would go with the current implementation and revisit on KMS model > at later point of time. But I doubt you will be able to sneak a new fbdev driver through. Last time I heard, Andrew is only taking in fixes not new features. 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] media: davinci: vpbe: fix layer availability for NV12 format
From: Lad, Prabhakar
For NV12 format, even if display data is single image,
both VIDWIN0 and VIDWIN1 parameters must be used. The start
address of Y data plane and C data plane is configured in
VIDEOWIN0ADH/L and VIDEOWIN1ADH/L respectively.
cuurently only one layer was requested, which is suffice
for yuv422, but for yuv420(NV12) two layers are required and
fix the same by requesting for other layer if pix fmt is NV12
during set_fmt.
Signed-off-by: Lad, Prabhakar
---
drivers/media/platform/davinci/vpbe_display.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index 0341dcc..f2ee07b 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -922,6 +922,22 @@ static int vpbe_display_s_fmt(struct file *file, void
*priv,
other video window */
layer->pix_fmt = *pixfmt;
+ if (pixfmt->pixelformat == V4L2_PIX_FMT_NV12 &&
+ cpu_is_davinci_dm365()) {
+ struct vpbe_layer *otherlayer;
+
+ otherlayer = _vpbe_display_get_other_win_layer(disp_dev, layer);
+ /* if other layer is available, only
+ * claim it, do not configure it
+ */
+ ret = osd_device->ops.request_layer(osd_device,
+ otherlayer->layer_info.id);
+ if (ret < 0) {
+ v4l2_err(&vpbe_dev->v4l2_dev,
+"Display Manager failed to allocate layer\n");
+ return -EBUSY;
+ }
+ }
/* Get osd layer config */
osd_device->ops.get_layer_config(osd_device,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Grabby hwrev 2
On Fri, May 03, 2013 at 08:47:55AM +0300, Timo Teras wrote:
> On Thu, 2 May 2013 10:04:56 +0300
> Timo Teras wrote:
>
> > On Wed, 1 May 2013 19:11:53 +0200
> > Jon Arne Jørgensen wrote:
> >
> > > On Thu, Mar 28, 2013 at 04:54:59PM +0200, Timo Teras wrote:
> > > > On Thu, 28 Mar 2013 15:35:56 +0200
> > > > Timo Teras wrote:
> > > >
> > > > > On Thu, 28 Mar 2013 09:40:52 -0300
> > > > > Mauro Carvalho Chehab wrote:
> > > > >
> > > > > > Em Thu, 28 Mar 2013 10:52:01 +0200
> > > > > > Timo Teras escreveu:
> > > > > >
> > > > > > > On Wed, 27 Mar 2013 16:10:49 +0200
> > > > > > > Timo Teras wrote:
> > > > > > >
> > > > > > > > On Tue, 26 Mar 2013 10:20:56 +0200
> > > > > > > > Timo Teras wrote:
> > > > > > > >
> > > > > > > > > I did manage to get decent traces with USBlyzer
> > > > > > > > > evaluation version.
> > > > > > > >
> > > > > > > > Nothing _that_ exciting there. Though, there's quite a bit
> > > > > > > > of differences on certain register writes. I tried copying
> > > > > > > > the changed parts, but did not really help.
> > > > > > > >
> > > > > > > > Turning on saa7115 debug gave:
> > > > > > > >
> > > > > > > > saa7115 1-0025: chip found @ 0x4a (ID 000)
> > > > > > > > does not match a known saa711x chip.
> > > > > > >
> > > > > > > Well, I just made saa7115.c ignore this ID check, and
> > > > > > > defeault to saa7113 which is apparently the chip used.
> > > > > > >
> > > > > > > And now it looks like things start to work a lot better.
> > > > > > >
> > > > > > > Weird that the saa7113 chip is missing the ID string. Will
> > > > > > > continue testing.
> > > > > >
> > > > > > That could happen if saa7113 is behind some I2C bridge and
> > > > > > when saa7113 is not found when the detection code is called.
> > > > >
> > > > > Smells to me that they replaced the saa7113 with cheaper clone
> > > > > that does not support the ID string.
> > > > >
> > > > > Sounds like the same issue as:
> > > > > http://www.spinics.net/lists/linux-media/msg57926.html
> > > > >
> > > > > Additionally noted that something is not initialized right:
> > > > >
> > > > > With PAL signal:
> > > > > - there's some junk pixel in beginning of each line (looks like
> > > > > pixes from previous lines end), sync issue?
> > > > > - some junk lines at the end
> > > > > - distorted colors when white and black change between pixels
> > > >
> > > > Still have not figured out this one. Could be probably related to
> > > > the saa7113 differences.
> > > >
> > > > > With NTSC signal:
> > > > > - unable to get a lock, and the whole picture looks garbled
> > > >
> > > > NTSC started working after I removed all the saa711x writes to
> > > > following registers:
> > > > R_14_ANAL_ADC_COMPAT_CNTL
> > > > R_15_VGATE_START_FID_CHG
> > > > R_16_VGATE_STOP
> > > > R_17_MISC_VGATE_CONF_AND_MSB
> > > >
> > >
> > > This is the exact same behavior as i see on the gm7113c chip
> > > in the stk1160, and the smi2021 devices.
> > >
> > > See here:
> > > http://www.spinics.net/lists/linux-media/msg63163.html
> >
> > Thanks. I tested the patch and it detects it properly, and I get
> > picture. However, there's problems synchronizing to my PAL signal. The
> > picture "jumps" once in a while.
> >
> > I guess the problem is in the init sequence. The W7 driver had
> > following differences sequence changes compared to saa7113_init:
> > - R_02_INPUT_CNTL_1, 0xc2,
> > + R_02_INPUT_CNTL_1, 0xc0,
> > - R_04_INPUT_CNTL_3, 0x00,
> > - R_05_INPUT_CNTL_4, 0x00,
> > - R_06_H_SYNC_START, 0x89,
> > + R_06_H_SYNC_START, 0xeb,
> > - R_12_RT_SIGNAL_CNTL, 0x07,
> > + R_12_RT_SIGNAL_CNTL, 0xe7,
> > - R_14_ANAL_ADC_COMPAT_CNTL, 0x00,
> > - R_15_VGATE_START_FID_CHG, 0x00,
> > - R_16_VGATE_STOP, 0x00,
> > - R_17_MISC_VGATE_CONF_AND_MSB, 0x00,
> >
> > Seems that R_14 is filtered in your patch, but other changes are not
> > taken into account.
> >
> > Otherwise, the patchset looks good.
>
> Not sure if part of the problems were related to the fact that I tried
> this patch set first with 3.8.10. And that had problems.
>
> Now I'm using 3.9.0 with the above mentioned patchset, and my
> additional patch (below). This seems to work nicely.
>
> In any case it strongly looks like Terratec Grabby hwrev2 has also
> the gm7113c chip; I still have not opened one to look, though.
>
> --- a/drivers/media/i2c/saa7115.c
> +++ b/drivers/media/i2c/saa7115.c
> @@ -450,6 +450,28 @@
> /* == SAA7715 VIDEO templates (end) === */
>
> /* == GM7113C VIDEO templates = */
> +static const unsigned char gm7113c_init[] = {
> + R_01_INC_DELAY, 0x08,
> + R_02_INPUT_CNTL_1, 0xc0,
Register 0x02 is overridden when saa711x_s_routing is
called to select input, so the value of that register in this table shouldn't
make any difference :)
> + R_03_INPUT_CNTL_2, 0x30,
> + R_06_H_SYNC_START, 0xeb,
> + R_07_H_SYNC_STOP, 0x0d,
> + R_08_SYNC_CNTL, 0x88,
> + R_09_LUMA
[PATCH] v4l-utils: Fix POLARIZATION support for dvbv5-scan
Hi all,
The attached patch fix support for the POLARIZATION parameter in
channel files used by dvbv5-scan.
I took the liberty of removing the parsing of the 'extra DTV_foo'
properties since they are all handled separately in dvb-file.c.
Please note that the size of struct dvb_v5_fe_parms as well as struct
dvb_entry changes which might require a bump in library version.
Tested with DVB-S and DVB-S2.
Support for POLARIZATION is not working yet with dvbv5-zap and will
come in a later patch.
Regards,
Guy
dvbv5-scan: Add support for POLARIZATION setting
Signed-off-by: Guy Martin
diff --git a/lib/include/dvb-fe.h b/lib/include/dvb-fe.h
index d725a42..9e87d14 100644
--- a/lib/include/dvb-fe.h
+++ b/lib/include/dvb-fe.h
@@ -104,7 +104,7 @@ struct dvb_v5_fe_parms {
unsigned freq_bpf;
/* Satellite specific stuff, used internally */
- //enum dvb_sat_polarization pol;
+ enum dvb_sat_polarization pol;
inthigh_band;
unsigned diseqc_wait;
unsigned freq_offset;
diff --git a/lib/include/dvb-file.h b/lib/include/dvb-file.h
index ea76080..2259844 100644
--- a/lib/include/dvb-file.h
+++ b/lib/include/dvb-file.h
@@ -35,7 +35,7 @@ struct dvb_entry {
char *location;
-// enum dvbsat_polarization pol;
+ enum dvb_sat_polarization pol;
int sat_number;
unsigned freq_bpf;
unsigned diseqc_wait;
diff --git a/lib/libdvbv5/dvb-file.c b/lib/libdvbv5/dvb-file.c
index d8d583c..3ea40cc 100644
--- a/lib/libdvbv5/dvb-file.c
+++ b/lib/libdvbv5/dvb-file.c
@@ -392,31 +392,6 @@ static int fill_entry(struct dvb_entry *entry, char *key, char *value)
return 0;
}
- /* Handle the DVB extra DTV_foo properties */
- for (i = 0; i < ARRAY_SIZE(dvb_user_name); i++) {
- if (!dvb_user_name[i])
- continue;
- if (!strcasecmp(key, dvb_user_name[i]))
- break;
- }
- if (i < ARRAY_SIZE(dvb_user_name)) {
- const char * const *attr_name = dvb_attr_names(i);
- n_prop = entry->n_props;
- entry->props[n_prop].cmd = i + DTV_USER_COMMAND_START;
- if (!attr_name || !*attr_name)
- entry->props[n_prop].u.data = atol(value);
- else {
- for (j = 0; attr_name[j]; j++)
-if (!strcasecmp(value, attr_name[j]))
- break;
- if (!attr_name[j])
-return -2;
- entry->props[n_prop].u.data = j + DTV_USER_COMMAND_START;
- }
- entry->n_props++;
- return 0;
- }
-
/* Handle the other properties */
if (!strcasecmp(key, "SERVICE_ID")) {
@@ -453,16 +428,15 @@ static int fill_entry(struct dvb_entry *entry, char *key, char *value)
is_video = 1;
else if (!strcasecmp(key, "AUDIO_PID"))
is_audio = 1;
- /*else if (!strcasecmp(key, "POLARIZATION")) {
- entry->service_id = atol(value);
- for (j = 0; ARRAY_SIZE(pol_name); j++)
- if (!strcasecmp(value, pol_name[j]))
+ else if (!strcasecmp(key, "POLARIZATION")) {
+ for (j = 0; ARRAY_SIZE(dvb_sat_pol_name); j++)
+ if (!strcasecmp(value, dvb_sat_pol_name[j]))
break;
- if (j == ARRAY_SIZE(pol_name))
+ if (j == ARRAY_SIZE(dvb_sat_pol_name))
return -2;
entry->pol = j;
return 0;
- }*/ else if (!strncasecmp(key,"PID_", 4)){
+ } else if (!strncasecmp(key,"PID_", 4)){
type = strtol(&key[4], NULL, 16);
if (!type)
return 0;
@@ -672,10 +646,10 @@ int write_dvb_file(const char *fname, struct dvb_file *dvb_file)
fprintf(fp, "\n");
}
- /*if (entry->pol != POLARIZATION_OFF) {*/
- /*fprintf(fp, "\tPOLARIZATION = %s\n",*/
-/*pol_name[entry->pol]);*/
- /*}*/
+ if (entry->pol != POLARIZATION_OFF) {
+ fprintf(fp, "\tPOLARIZATION = %s\n",
+dvb_sat_pol_name[entry->pol]);
+ }
if (entry->sat_number >= 0) {
fprintf(fp, "\tSAT_NUMBER = %d\n",
diff --git a/lib/libdvbv5/dvb-sat.c b/lib/libdvbv5/dvb-sat.c
index d00a09e..89f8e88 100644
--- a/lib/libdvbv5/dvb-sat.c
+++ b/lib/libdvbv5/dvb-sat.c
@@ -272,8 +272,7 @@ static int dvbsat_scr_odu_channel_change(struct dvb_v5_fe_parms *parms, struct d
static int dvbsat_diseqc_set_input(struct dvb_v5_fe_parms *parms, uint16_t t)
{
int rc;
- enum dvb_sat_polarization pol;
- dvb_fe_retrieve_parm(parms, DTV_POLARIZATION,& pol);
+ enum dvb_sat_polarization pol = parms->pol;
int pol_v = (pol == POLARIZATION_V) || (pol == POLARIZATION_R);
int high_band = parms->high_band;
int sat_number = parms->sat_number;
@@ -284,12 +283,6 @@ static int dvbsat_diseqc_set_input(struct dvb_v5_fe_parms *parms, uint16_t t)
if (!lnb->rangeswitch) {
/*
- * Bandstacking and single LO may not be using DISEqC
- */
- if (sat_number < 0)
- return 0;
-
- /*
* Bandstacking switches don't use 2 bands nor use
* DISEqC for setting the polarization. It also doesn't
* use any tone/tone burst
@@ -297,11 +290,6 @@ static int dvbsat_diseqc_set_input(struct dvb_v5_fe_parms *parms, uint16_t t)
pol_v = 0;
high_band = 1;
} else {
- if (sat_number < 0) {
- dvb_logerr("Need a satellite number for DISEqC");
- return -EINVAL;
- }
-
/* Adjust voltage/tone accordingly */
if (parms->sat_number < 2) {
vol_high = pol_v ? 0 : 1;
@@ -310,32 +298,35 @@ static int dvbsat_d
[PATCH v3] media: i2c: tvp7002: enable TVP7002 decoder for media controller based usage
From: Lad, Prabhakar
This patch enables tvp7002 decoder driver for media controller
based usage by adding v4l2_subdev_pad_ops operations support
for enum_mbus_code, set_pad_format, get_pad_format and media_entity_init()
on probe and media_entity_cleanup() on remove.
Signed-off-by: Lad, Prabhakar
---
Changes for v2:
1: Fixed review comment pointed by Laurent, Don’t return error for set_fmt
but fix the input parameters according to current timings.
Changes for v3:
1: Fixed review comments pointed by Laurent.
drivers/media/i2c/tvp7002.c | 96 --
include/media/tvp7002.h |2 +
2 files changed, 93 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
index 027809c..270e699 100644
--- a/drivers/media/i2c/tvp7002.c
+++ b/drivers/media/i2c/tvp7002.c
@@ -424,6 +424,7 @@ struct tvp7002 {
int streaming;
const struct tvp7002_timings_definition *current_timings;
+ struct media_pad pad;
};
/*
@@ -880,6 +881,65 @@ static const struct v4l2_ctrl_ops tvp7002_ctrl_ops = {
.s_ctrl = tvp7002_s_ctrl,
};
+/*
+ * tvp7002_enum_mbus_code() - Enum supported digital video format on pad
+ * @sd: pointer to standard V4L2 sub-device structure
+ * @fh: file handle for the subdev
+ * @code: pointer to subdev enum mbus code struct
+ *
+ * Enumerate supported digital video formats for pad.
+ */
+static int
+tvp7002_enum_mbus_code(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ /* Check requested format index is within range */
+ if (code->index != 0)
+ return -EINVAL;
+
+ code->code = V4L2_MBUS_FMT_YUYV10_1X20;
+
+ return 0;
+}
+
+/*
+ * tvp7002_get_pad_format() - get video format on pad
+ * @sd: pointer to standard V4L2 sub-device structure
+ * @fh: file handle for the subdev
+ * @fmt: pointer to subdev format struct
+ *
+ * get video format for pad.
+ */
+static int
+tvp7002_get_pad_format(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_format *fmt)
+{
+ struct tvp7002 *tvp7002 = to_tvp7002(sd);
+
+ fmt->format.code = V4L2_MBUS_FMT_YUYV10_1X20;
+ fmt->format.width = tvp7002->current_timings->timings.bt.width;
+ fmt->format.height = tvp7002->current_timings->timings.bt.height;
+ fmt->format.field = tvp7002->current_timings->scanmode;
+ fmt->format.colorspace = tvp7002->current_timings->color_space;
+
+ return 0;
+}
+
+/*
+ * tvp7002_set_pad_format() - set video format on pad
+ * @sd: pointer to standard V4L2 sub-device structure
+ * @fh: file handle for the subdev
+ * @fmt: pointer to subdev format struct
+ *
+ * set video format for pad.
+ */
+static int
+tvp7002_set_pad_format(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_format *fmt)
+{
+ return tvp7002_get_pad_format(sd, fh, fmt);
+}
+
/* V4L2 core operation handlers */
static const struct v4l2_subdev_core_ops tvp7002_core_ops = {
.g_chip_ident = tvp7002_g_chip_ident,
@@ -910,10 +970,18 @@ static const struct v4l2_subdev_video_ops
tvp7002_video_ops = {
.enum_mbus_fmt = tvp7002_enum_mbus_fmt,
};
+/* media pad related operation handlers */
+static const struct v4l2_subdev_pad_ops tvp7002_pad_ops = {
+ .enum_mbus_code = tvp7002_enum_mbus_code,
+ .get_fmt = tvp7002_get_pad_format,
+ .set_fmt = tvp7002_set_pad_format,
+};
+
/* V4L2 top level operation handlers */
static const struct v4l2_subdev_ops tvp7002_ops = {
.core = &tvp7002_core_ops,
.video = &tvp7002_video_ops,
+ .pad = &tvp7002_pad_ops,
};
/*
@@ -993,19 +1061,35 @@ static int tvp7002_probe(struct i2c_client *c, const
struct i2c_device_id *id)
timings = device->current_timings->timings;
error = tvp7002_s_dv_timings(sd, &timings);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ strlcpy(sd->name, TVP7002_MODULE_NAME, sizeof(sd->name));
+ device->pad.flags = MEDIA_PAD_FL_SOURCE;
+ device->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ device->sd.entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+
+ error = media_entity_init(&device->sd.entity, 1, &device->pad, 0);
+ if (error < 0)
+ return error;
+#endif
+
v4l2_ctrl_handler_init(&device->hdl, 1);
v4l2_ctrl_new_std(&device->hdl, &tvp7002_ctrl_ops,
V4L2_CID_GAIN, 0, 255, 1, 0);
sd->ctrl_handler = &device->hdl;
if (device->hdl.error) {
- int err = device->hdl.error;
-
- v4l2_ctrl_handler_free(&device->hdl);
- return err;
+ error = device->hdl.error;
+ goto error;
}
v4l2_ctrl_handler_setup(&device->hdl);
return 0;
+
+error:
+ v4l2_ctrl_handler_free(&device->hdl);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ media_ent
[PATCH V4 3/3] saa7115: Add register setup and config for gm7113c
The gm7113c chip is similar to the original saa7113 chip, so I try to
re-use most of the saa7113 specific setup-/configuration registers.
According to the datasheet, the gm7113c chip has not implemented
any register addresses after 0x1f, so I add a new entry for the chip
in the saa711x_has_reg function.
The devices I've seen using this chip will fail to get stable video-sync
if these registers are not zeroed:
R_14_ANAL_ADC_COMPAT_CNTL
R_15_VGATE_START_FID_CHG
R_16_VGATE_STOP
R_17_MISC_VGATE_CONF_AND_MSB
The saa711x_set_v4lstd is updated to send a simpler configuration-table
to avoid setting these registers.
Signed-off-by: Jon Arne Jørgensen
Tested-by: Ezequiel Garcia
---
drivers/media/i2c/saa7115.c | 47 +++--
1 file changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
index eb2c19d..efdc7fd 100644
--- a/drivers/media/i2c/saa7115.c
+++ b/drivers/media/i2c/saa7115.c
@@ -126,6 +126,8 @@ static int saa711x_has_reg(const int id, const u8 reg)
return 0;
switch (id) {
+ case V4L2_IDENT_GM7113C:
+ return reg != 0x14 && (reg < 0x18 || reg > 0x1e) && reg < 0x20;
case V4L2_IDENT_SAA7113:
return reg != 0x14 && (reg < 0x18 || reg > 0x1e) && (reg < 0x20
|| reg > 0x3f) &&
reg != 0x5d && reg < 0x63;
@@ -213,7 +215,10 @@ static const unsigned char saa7111_init[] = {
0x00, 0x00
};
-/* SAA7113 init codes */
+/* SAA7113/GM7113C init codes
+ * It's important that R_14... R_17 == 0x00
+ * for the gm7113c chip to deliver stable video
+ */
static const unsigned char saa7113_init[] = {
R_01_INC_DELAY, 0x08,
R_02_INPUT_CNTL_1, 0xc2,
@@ -447,6 +452,24 @@ static const unsigned char saa7115_cfg_50hz_video[] = {
/* == SAA7715 VIDEO templates (end) === */
+/* == GM7113C VIDEO templates = */
+static const unsigned char gm7113c_cfg_60hz_video[] = {
+ R_08_SYNC_CNTL, 0x68, /* 0xBO: auto detection, 0x68 =
NTSC */
+ R_0E_CHROMA_CNTL_1, 0x07, /* video autodetection is on */
+
+ 0x00, 0x00
+};
+
+static const unsigned char gm7113c_cfg_50hz_video[] = {
+ R_08_SYNC_CNTL, 0x28, /* 0x28 = PAL */
+ R_0E_CHROMA_CNTL_1, 0x07,
+
+ 0x00, 0x00
+};
+
+/* == GM7113C VIDEO templates (end) === */
+
+
static const unsigned char saa7115_cfg_vbi_on[] = {
R_80_GLOBAL_CNTL_1, 0x00, /* reset tasks */
R_88_POWER_SAVE_ADC_PORT_CNTL, 0xd0,/* reset scaler */
@@ -927,11 +950,17 @@ static void saa711x_set_v4lstd(struct v4l2_subdev *sd,
v4l2_std_id std)
// This works for NTSC-M, SECAM-L and the 50Hz PAL variants.
if (std & V4L2_STD_525_60) {
v4l2_dbg(1, debug, sd, "decoder set standard 60 Hz\n");
- saa711x_writeregs(sd, saa7115_cfg_60hz_video);
+ if (state->ident == V4L2_IDENT_GM7113C)
+ saa711x_writeregs(sd, gm7113c_cfg_60hz_video);
+ else
+ saa711x_writeregs(sd, saa7115_cfg_60hz_video);
saa711x_set_size(sd, 720, 480);
} else {
v4l2_dbg(1, debug, sd, "decoder set standard 50 Hz\n");
- saa711x_writeregs(sd, saa7115_cfg_50hz_video);
+ if (state->ident == V4L2_IDENT_GM7113C)
+ saa711x_writeregs(sd, gm7113c_cfg_50hz_video);
+ else
+ saa711x_writeregs(sd, saa7115_cfg_50hz_video);
saa711x_set_size(sd, 720, 576);
}
@@ -944,7 +973,8 @@ static void saa711x_set_v4lstd(struct v4l2_subdev *sd,
v4l2_std_id std)
011 NTSC N (3.58MHz)PAL M (3.58MHz)
100 reservedNTSC-Japan (3.58MHz)
*/
- if (state->ident <= V4L2_IDENT_SAA7113) {
+ if (state->ident <= V4L2_IDENT_SAA7113 ||
+ state->ident == V4L2_IDENT_GM7113C) {
u8 reg = saa711x_read(sd, R_0E_CHROMA_CNTL_1) & 0x8f;
if (std == V4L2_STD_PAL_M) {
@@ -1215,7 +1245,8 @@ static int saa711x_s_routing(struct v4l2_subdev *sd,
input, output);
/* saa7111/3 does not have these inputs */
- if (state->ident <= V4L2_IDENT_SAA7113 &&
+ if ((state->ident <= V4L2_IDENT_SAA7113 ||
+state->ident == V4L2_IDENT_GM7113C) &&
(input == SAA7115_COMPOSITE4 ||
input == SAA7115_COMPOSITE5)) {
return -EINVAL;
@@ -1687,11 +1718,6 @@ static int saa711x_probe(struct i2c_client *client,
if (ident < 0)
return ident;
- if (ident == V4L2_IDENT_GM7113C) {
- v4l_warn(client, "%s not yet supported\n", name);
- return -ENODEV;
- }
-
strlcpy(client->name, name, sizeof(client->name))
[PATCH V4 1/3] saa7115: move the autodetection code out of the probe function
As we're now seeing other variants from chinese clones, like
gm1113c, we'll need to add more bits at the detection code.
So, move it into a separate function.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Jon Arne Jørgensen
Tested-by: Ezequiel Garcia
---
drivers/media/i2c/saa7115.c | 133 +++-
1 file changed, 83 insertions(+), 50 deletions(-)
diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
index 6b6788c..aa92478 100644
--- a/drivers/media/i2c/saa7115.c
+++ b/drivers/media/i2c/saa7115.c
@@ -1561,46 +1561,103 @@ static const struct v4l2_subdev_ops saa711x_ops = {
/* --- */
+/**
+ * saa711x_detect_chip - Detects the saa711x (or clone) variant
+ * @client:I2C client structure.
+ * @id:I2C device ID structure.
+ * @name: Name of the device to be filled.
+ * @size: Size of the name var.
+ *
+ * Detects the Philips/NXP saa711x chip, or some clone of it.
+ * if 'id' is NULL or id->driver_data is equal to 1, it auto-probes
+ * the analog demod.
+ * If the tuner is not found, it returns -ENODEV.
+ * If auto-detection is disabled and the tuner doesn't match what it was
+ * requred, it returns -EINVAL and fills 'name'.
+ * If the chip is found, it returns the chip ID and fills 'name'.
+ */
+static int saa711x_detect_chip(struct i2c_client *client,
+ const struct i2c_device_id *id,
+ char *name, unsigned size)
+{
+ char chip_ver[size - 1];
+ char chip_id;
+ int i;
+ int autodetect;
+
+ autodetect = !id || id->driver_data == 1;
+
+ /* Read the chip version register */
+ for (i = 0; i < size - 1; i++) {
+ i2c_smbus_write_byte_data(client, 0, i);
+ chip_ver[i] = i2c_smbus_read_byte_data(client, 0);
+ name[i] = (chip_ver[i] & 0x0f) + '0';
+ if (name[i] > '9')
+ name[i] += 'a' - '9' - 1;
+ }
+ name[i] = '\0';
+
+ /* Check if it is a Philips/NXP chip */
+ if (!memcmp(name + 1, "f711", 4)) {
+ chip_id = name[5];
+ snprintf(name, size, "saa711%c", chip_id);
+
+ if (!autodetect && strcmp(name, id->name))
+ return -EINVAL;
+
+ switch (chip_id) {
+ case '1':
+ if (chip_ver[0] & 0xf0) {
+ snprintf(name, size, "saa711%ca", chip_id);
+ v4l_info(client, "saa7111a variant found\n");
+ return V4L2_IDENT_SAA7111A;
+ }
+ return V4L2_IDENT_SAA7111;
+ case '3':
+ return V4L2_IDENT_SAA7113;
+ case '4':
+ return V4L2_IDENT_SAA7114;
+ case '5':
+ return V4L2_IDENT_SAA7115;
+ case '8':
+ return V4L2_IDENT_SAA7118;
+ default:
+ v4l2_info(client,
+ "WARNING: Philips/NXP chip unknown - Falling
back to saa7111\n");
+ return V4L2_IDENT_SAA7111;
+ }
+ }
+
+ /* Chip was not discovered. Return its ID and don't bind */
+ v4l_dbg(1, debug, client, "chip %*ph @ 0x%x is unknown.\n",
+ 16, chip_ver, client->addr << 1);
+ return -ENODEV;
+}
+
static int saa711x_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct saa711x_state *state;
struct v4l2_subdev *sd;
struct v4l2_ctrl_handler *hdl;
- int i;
+ int ident;
char name[17];
- char chip_id;
- int autodetect = !id || id->driver_data == 1;
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
return -EIO;
- for (i = 0; i < 0x0f; i++) {
- i2c_smbus_write_byte_data(client, 0, i);
- name[i] = (i2c_smbus_read_byte_data(client, 0) & 0x0f) + '0';
- if (name[i] > '9')
- name[i] += 'a' - '9' - 1;
- }
- name[i] = '\0';
-
- chip_id = name[5];
-
- /* Check whether this chip is part of the saa711x series */
- if (memcmp(name + 1, "f711", 4)) {
- v4l_dbg(1, debug, client, "chip found @ 0x%x (ID %s) does not
match a known saa711x chip.\n",
- client->addr << 1, name);
+ ident = saa711x_detect_chip(client, id, name, sizeof(name));
+ if (ident == -EINVAL) {
+ /* Chip exists, but doesn't match */
+ v4l_warn(client, "found %s while %s was expected\n",
+name, id->name);
r
[PATCH V4 2/3] saa7115: add detection code for gm7113c
Adds a code that (auto)detects gm7113c clones. The auto-detection
here is not perfect, as, on contrary to what it would be expected
by looking into its datasheets some devices would return, instead:
saa7115 0-0025: chip 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 @
0x4a is unknown
(found on a device labeled as GM7113C 1145 by Ezequiel Garcia)
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Jon Arne Jørgensen
Tested-by: Ezequiel Garcia
---
drivers/media/i2c/saa7115.c | 36
include/media/v4l2-chip-ident.h | 2 ++
2 files changed, 38 insertions(+)
diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
index aa92478..eb2c19d 100644
--- a/drivers/media/i2c/saa7115.c
+++ b/drivers/media/i2c/saa7115.c
@@ -1628,6 +1628,36 @@ static int saa711x_detect_chip(struct i2c_client *client,
}
}
+ /* Check if it is a gm7113c */
+ if (!memcmp(name, "", 4)) {
+ chip_id = 0;
+ for (i = 0; i < 4; i++) {
+ chip_id = chip_id << 1;
+ chip_id |= (chip_ver[i] & 0x80) ? 1 : 0;
+ }
+
+ /*
+* Note: From the datasheet, only versions 1 and 2
+* exists. However, tests on a device labeled as:
+* "GM7113C 1145" returned "10" on all 16 chip
+* version (reg 0x00) reads. So, we need to also
+* accept at least verion 0. For now, let's just
+* assume that a device that returns "" for
+* the lower nibble is a gm7113c.
+*/
+
+ snprintf(name, size, "gm7113c");
+
+ if (!autodetect && strcmp(name, id->name))
+ return -EINVAL;
+
+ v4l_dbg(1, debug, client,
+ "It seems to be a %s chip (%*ph) @ 0x%x.\n",
+ name, 16, chip_ver, client->addr << 1);
+
+ return V4L2_IDENT_GM7113C;
+ }
+
/* Chip was not discovered. Return its ID and don't bind */
v4l_dbg(1, debug, client, "chip %*ph @ 0x%x is unknown.\n",
16, chip_ver, client->addr << 1);
@@ -1657,6 +1687,11 @@ static int saa711x_probe(struct i2c_client *client,
if (ident < 0)
return ident;
+ if (ident == V4L2_IDENT_GM7113C) {
+ v4l_warn(client, "%s not yet supported\n", name);
+ return -ENODEV;
+ }
+
strlcpy(client->name, name, sizeof(client->name));
state = kzalloc(sizeof(struct saa711x_state), GFP_KERNEL);
@@ -1744,6 +1779,7 @@ static const struct i2c_device_id saa711x_id[] = {
{ "saa7114", 0 },
{ "saa7115", 0 },
{ "saa7118", 0 },
+ { "gm7113c", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, saa711x_id);
diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
index 4ee125b..ef7e1c4 100644
--- a/include/media/v4l2-chip-ident.h
+++ b/include/media/v4l2-chip-ident.h
@@ -52,6 +52,8 @@ enum {
V4L2_IDENT_SAA7115 = 105,
V4L2_IDENT_SAA7118 = 108,
+ V4L2_IDENT_GM7113C = 140,
+
/* module saa7127: reserved range 150-199 */
V4L2_IDENT_SAA7127 = 157,
V4L2_IDENT_SAA7129 = 159,
--
1.8.2.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 V4 0/3] saa7115: add the gm7113c chip
The purpose of this patch is to add support for the gm7113c chip in the saa7115 driver. The gm7113c chip is a chinese clone of the Philips/NXP saa7113 chip. The chip is found in several cheap usb video capture devices. This is the forth version of a patch-set previously posted by Mauro, the first verson was posted on 26 April, and can be found here: http://www.spinics.net/lists/linux-media/msg63079.html The second version was posted by Mauro on 26 April, and can be found here: http://www.spinics.net/lists/linux-media/msg63087.html The third version was posted by me on 29 April and had a bad cover-letter: http://www.spinics.net/lists/linux-media/msg63163.html This version has a better cover-letter and I've added a commit message to the last patch. Jon Arne Jørgensen (3): saa7115: move the autodetection code out of the probe function saa7115: add detection code for gm7113c saa7115: Add register setup and config for gm7113c drivers/media/i2c/saa7115.c | 206 +--- include/media/v4l2-chip-ident.h | 2 + 2 files changed, 153 insertions(+), 55 deletions(-) -- 1.8.2.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
