Re: [PATCH v2 2/2] sh_mobile_ceu: Add field signal operation
On Tue, 3 Feb 2009, Kuninori Morimoto wrote:
sh_mobile_ceu can support field signal from external module.
To support this operation, SH_CEU_FLAG_USE_FLDID_{HIGH, LOW}
are added to header.
I never dealt with interlaced video, so, I probably just don't understand
something, please explain. I understand the Field ID signal is optional,
and, if used, it can be either active high or low. But who gets to decide
which polarity is applicable in a specific case? The platform? Is it not
like with other control signals, where if both partners are freely
configurable, then any polarity can be used; if one is configurable and
another is hard-wired, only one polarity can be used. And as long as the
signal is available (connected), the platform has no further influence on
its use? Ok, there can be an inverter there, but that we can handle too.
So, wouldn't something like
+ if (pcdev-pdata-flags SH_CEU_FLAG_USE_FLDID)
+ flags |= SOCAM_FIELD_ID_ACTIVE_HIGH | SOCAM_FIELD_ID_ACTIVE_LOW;
+
...
+ if (common_flags (SOCAM_FIELD_ID_ACTIVE_HIGH |
SOCAM_FIELD_ID_ACTIVE_LOW) ==
+ SOCAM_FIELD_ID_ACTIVE_LOW)
+ /* The client only supports active low field ID */
+ value |= 1 16;
+ /* Otherwise we are free to choose, leave default active high */
Or does Field ID work differently?
And what do you do, if the platform doesn't specify SH_CEU_FLAG_USE_FLDID,
i.e., it is not connected, but the client does? Or the other way round? In
other words, is it a working configuration, when one of the partners
provides this signal and the other one doesn't? I guess it is, because,
you say, it is optional. So we shouldn't test it in
soc_camera_bus_param_compatible()?
Thanks
Guennadi
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
v1 - v2
o field name fix
drivers/media/video/sh_mobile_ceu_camera.c |7 +++
include/media/sh_mobile_ceu.h |2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index aa20745..1f746e1 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -118,6 +118,12 @@ static unsigned long make_bus_param(struct
sh_mobile_ceu_dev *pcdev)
if (pcdev-pdata-flags SH_CEU_FLAG_USE_16BIT_BUS)
flags |= SOCAM_DATAWIDTH_16;
+ if (pcdev-pdata-flags SH_CEU_FLAG_USE_FLDID_HIGH)
+ flags |= SOCAM_FIELD_ID_ACTIVE_HIGH;
+
+ if (pcdev-pdata-flags SH_CEU_FLAG_USE_FLDID_LOW)
+ flags |= SOCAM_FIELD_ID_ACTIVE_LOW;
+
if (flags SOCAM_DATAWIDTH_MASK)
return flags;
@@ -474,6 +480,7 @@ static int sh_mobile_ceu_set_bus_param(struct
soc_camera_device *icd,
icd-current_fmt-fourcc == V4L2_PIX_FMT_NV61)
value ^= 0x0100; /* swap U, V to change from NV1x-NVx1 */
+ value |= common_flags SOCAM_FIELD_ID_ACTIVE_LOW ? 1 16 : 0;
value |= common_flags SOCAM_VSYNC_ACTIVE_LOW ? 1 1 : 0;
value |= common_flags SOCAM_HSYNC_ACTIVE_LOW ? 1 0 : 0;
value |= buswidth == 16 ? 1 12 : 0;
diff --git a/include/media/sh_mobile_ceu.h b/include/media/sh_mobile_ceu.h
index 0f3524c..8da9437 100644
--- a/include/media/sh_mobile_ceu.h
+++ b/include/media/sh_mobile_ceu.h
@@ -3,6 +3,8 @@
#define SH_CEU_FLAG_USE_8BIT_BUS (1 0) /* use 8bit bus width */
#define SH_CEU_FLAG_USE_16BIT_BUS(1 1) /* use 16bit bus width */
+#define SH_CEU_FLAG_USE_FLDID_HIGH (1 2) /* top field if FLD is high */
+#define SH_CEU_FLAG_USE_FLDID_LOW(1 3) /* top field if FLD is low */
struct sh_mobile_ceu_info {
unsigned long flags;
--
1.5.6.3
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
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
[PULL] gspca
Hi Mauro, The changes relative to 'gspca - main' should go to the kernel 2.6.29. Please pull from http://linuxtv.org/hg/~jfrancois/gspca/ for: changeset: 10433:fd2cb3b7916e gspca - vc032x: Remove the vc0321 reset. changeset: 10434:3f4a7bc53d8e gspca - some drivers: Fix compilation warnings. changeset: 10435:4d0827823ebc gspca - main: Don't kill the URBs when the device is disconnected. changeset: 10436:2dd691c92f20 gspca - main: Destroy the URBs at disconnection time. changeset: 10437:f9e9cf9bfbf4 gspca - main: More checks of the device disconnection. changeset: 10438:949a12648c68 gspca - main: Better handling of disconnection at the API. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Mantis Bug (was Technisat HD2 cannot szap/scan)
Hi,
checked it again. Your lnbp21 patch definitely kills S2 tuning
on the Terratec Cinergy S2 PCI HD.
mfg
Edgar ( gimli ) Hucek
I looked at it again and here is a new patch to set the LNBP21
options for the Twinhan VP-1041. This works better for me, including
DVB-S2 channels. The EN enable bit is now not permanently set so
sleep behavior is correct.
Please note that I have a DiSEqC 1.2 rotor between the VP-1041 card
and the LNB. That is quite a normal configuration, but the driver was
probably not properly tested with rotors (and switches?) before.
To rotate with scan-s2 use the patch I posted, which will be applied
there soon:
http://linuxtv.org/pipermail/linux-dvb/2009-January/031660.html
Regards,
Hans
Patch is against latest http://mercurial.intuxication.org/hg/s2-liplianin repo.
Signed-off-by: Hans Werner hwern...@gmx.de
diff -r 084878324629 linux/drivers/media/dvb/mantis/mantis_dvb.c
--- a/linux/drivers/media/dvb/mantis/mantis_dvb.c
+++ b/linux/drivers/media/dvb/mantis/mantis_dvb.c
@@ -239,7 +239,8 @@ int __devinit mantis_frontend_init(struc
vp1041_config.demod_address);
if (stb6100_attach(mantis-fe, vp1041_stb6100_config,
mantis-adapter)) {
- if (!lnbp21_attach(mantis-fe,
mantis-adapter, 0, 0)) {
+ // static current limit, no extra 1V, high
current limit, tone from DSQIN pin (stb0899)
+ if (!lnbp21_attach(mantis-fe,
mantis-adapter, LNBP21_PCL , LNBP21_LLC | LNBP21_ISEL | LNBP21_TEN)) {
printk(%s: No LNBP21 found!\n,
__FUNCTION__);
mantis-fe = NULL;
}
--
Release early, release often.
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re : [linux-dvb] Re : Technotrend Budget S2-3200 Digital artefacts on HDchannels
Le 02.02.2009 18:43:33, Chris Silva a écrit : On Tue, Jan 27, 2009 at 9:13 PM, Manu Abraham abraham.m...@gmail.com wrote: Alex Betis wrote: On Tue, Jan 27, 2009 at 9:56 PM, Manu Abraham abraham.m...@gmail.comwrote: Hmm OK, but is there by any chance a fix for those issues somewhere or in the pipe at least? I am willing to test (as I already offered), I can compile the drivers, spread printk or whatever else is needed to get useful reports. Let me know if I can help sort this problem. BTW in my case it is DVB-S2 3 SR and FEC 5/6. It was quite not appreciable on my part to provide a fix or reply in time nor spend much time on it earlier, but that said i was quite stuck up with some other things. Can you please pull a copy of the multiproto tree http://jusst.de/hg/multiproto or the v4l-dvb tree from http://jusst.de/hg/v4l-dvb and apply the following patch and comment what your result is ? Before applying please do check whether you still have the issues. Manu, I've tried to increase those timers long ago when played around with my card (Twinhan 1041) and scan utility. I must say that I've concentrated mostly on DVB-S channels that wasn't always locking. I didn't notice much improvements. The thing that did help was increasing the resolution of scan zigzags. With regards to the zig-zag, one bug is fixed in the v4l-dvb tree. Most likely you haven't tried that change. I've sent a patch on that ML and people were happy with the results. I did look at your patch, but that was completely against the tuning algorithm. [..] I believe DVB-S2 lock suffer from the same problem, but in that case the zigzag is done in the chip and not in the driver. Along with the patch i sent, does the attached patch help you in anyway (This works out for DVB-S2 only)? Manu, I've tried both multiproto branches you indicated above, *with* and *without* the patches you sent to the ML (fix_iterations.patch and increase timeout.patch) on this thread. Sadly, same behavior as S2API V4L-DVB current branch. No lock on 3 3/4 channels. It achieves a 0.5 second jittery sound but no image. It seems the driver is struggling to correctly lock on that channel, but doesn't get there in time... Or maybe the hardware... Dunno... Channels like ASTRA HD +;BetaDigital:11914:hC910M2O35S1:S19.2E:27500:1279=27:0;1283=deu:0:0:131:133:6:0 PREMIERE HD,PREM HD;PREMIERE:11914:hC910M2O35S1:S19.2E:27500:767=27:0;771=deu,772=eng:32:1837,1833,1834,9C4:129:133:6:0 DISCOVERY HD,DISC HD;PREMIERE:11914:hC910M2O35S1:S19.2E:27500:1023=27:0;1027=deu:32:1837,1833,1834,9C4:130:133:6 work just fine. But channels like National Geographic HD;National Geographic HD:11731:vC34M5O25S1:S30.0W:29000:6496=27:6497:0:1802:943:54:47:0 MOV HD;MOV HD:11731:vC34M5O25S1:S30.0W:29000:6512=27:6513=por:0:1802:944:54:47:0 Sport TV - HD;Sport TV - HD:11731:vC34M5O25S1:S30.0W:29000:6528=27:6529=por:0:1802:945:54:47:0 RTP HD;RTP HD:11731:vC34M5O25S1:S30.0W:29000:6544=27:6545:0:1802:946:54:47:0 TVCine 4 HD;TVCine 4 HD:11731:vC34M5O25S1:S30.0W:29000:6560=27:6561:0:1802:947:54:47:0 Disney Cinemagic HD:11731:vC34M5O25S1:S30.0W:29000:6576=27:6577=por:0:1802:948:54:47:0 Eurosport HD:11731:vC34M5O25S1:S30.0W:29000:6592=27:6593=por:0:1802:949:54:47:0 or [0065];:12012:hC34M5S1:S30.0W:3:4097:4098:4100:100:101:0:0:0 [0066];:12012:hC34M5S1:S30.0W:3:4105:4106:4100:100:102:0:0:0 [0067];:12012:hC34M5S1:S30.0W:3:4113:4114:4100:100:103:0:0:0 [0068];:12012:hC34M5S1:S30.0W:3:4121:4122:4100:100:104:0:0:0 [0069];:12012:hC34M5S1:S30.0W:3:4129:4130:4100:100:105:0:0:0 [006a];:12012:hC34M5S1:S30.0W:3:4137:4138:4100:100:106:0:0:0 [006b];:12012:hC34M5S1:S30.0W:3:4145:4146:4100:100:107:0:0:0 simply don't work. BTW, I think the channels above that don't work have a 0x0B stream indication. Satellite operators are misleading on the stream (h.222) when in fact they are h.264. Read that were on the ML. Don't know if it affects anything, but hey... I have to try everything! ;) I'm available to any tests necessary to fix this once and for all, if possible. Could I suggest something (probably stupid): I think that the TT 3650 is the same card but using USB, right (I mean it uses the stb0899/ stb6100 chips also)? So if someone could sniff the usb transactions during a successfull lock on a problematic channel (using windows then), we could see what is different. I do not have neither Windows, neither this card, but a good soul could help us here. Manu, is that sensible? Bye Manu (the other one ;-) -- 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 -tip] fix 22 make headers_check - 200901
On Wednesday 04 February 2009, H. Peter Anvin wrote: Actually, if anything we should move the *non* __KERNEL_STRICT_NAMES out of linux/types.h into something else, or completely deep-six them. I don't know of any libc which wants these anymore, and I think they're just residual libc5 cruft. However, if we want linux/extra_types.h that's fine with me; but linux/types.h really should be clean, which means doing what __KERNEL_STRICT_NAMES does now. Right now, we have 15 exported headers [1] that use the non-strict posix types (pid_t, off_t, clock_t, ...) and a set of 106 (!) files [2] using non-strict integer types (u_int32_t, uint32_t, u32, ...), 76 of those alone in netfilter. Do you think we should fix up all of them before 2.6.29? I'm worried that we might introduce more regressions in the process. Also, should we leave netfilter alone, in order to reduce the changes? I'm also unsure whether a hack in headers_install would be better than changing the headers in the source tree. Arnd [1] for i in dev_t mode_t off_t pid_t suseconds_t timer_t uid_t gid_t \ loff_t time_t clock_t caddr_t ; do grep \\\$i\\\ $obj/usr/include ; \ done | sort | grep -v linux/types.h [2] grep '\\(\(u_\|u\|\)int\(8\|16\|32\|64\)_t\|[us]\(8\|16\|32\|64\)\)\' \ $obj/usr/include | grep -v linux/types.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
Re: [GIT PULL -tip] fix 22 make headers_check - 200901
Arnd Bergmann wrote: On Wednesday 04 February 2009, H. Peter Anvin wrote: Actually, if anything we should move the *non* __KERNEL_STRICT_NAMES out of linux/types.h into something else, or completely deep-six them. I don't know of any libc which wants these anymore, and I think they're just residual libc5 cruft. However, if we want linux/extra_types.h that's fine with me; but linux/types.h really should be clean, which means doing what __KERNEL_STRICT_NAMES does now. Right now, we have 15 exported headers [1] that use the non-strict posix types (pid_t, off_t, clock_t, ...) and a set of 106 (!) files [2] using non-strict integer types (u_int32_t, uint32_t, u32, ...), 76 of those alone in netfilter. Geez. The integer types is just a pattern replacement, so those we can just fix. The 15 exported headers that use other types may very well be real bugs -- we have had a fair share of broken ioctl signatures due to exactly this problem. Do you think we should fix up all of them before 2.6.29? I'm worried that we might introduce more regressions in the process. Also, should we leave netfilter alone, in order to reduce the changes? I'm also unsure whether a hack in headers_install would be better than changing the headers in the source tree. I have been advocating for hacking headers_install for a while. That takes care of the 106. The 15 *need* to be audited immediately, because that is even likely to be actual manifest bugs. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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
cx8802.ko module not being built with current HG tree
Hi, Maybe I'm wrong, but I think there is something wrong in current Kconfig file for cx88 drivers. I've been struggling for some hours trying to find why, after compiling a fresh copy of the LinuxTV HG drivers, I wasn't unable to modprobe cx88-dvb module, which I need for HVR-3000. The module was not being load because kernel was failing to find cx8802_get_driver, etc... entry points, which are exported by cx88-mpeg.c. The strange part is that, according to the cx88/Kconfig file this file should be automatically added as dependency if either CX88_DVB or CX88_BLACKBIRD were selected, but for some strange reason it wasn't. After a 'make menuconfig' in HG tree the kernel configuration contained these lines (this was using the default config, without adding / removing anything): CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_MPEG=y CONFIG_VIDEO_CX88_VP3054=m Notice that they are all marked as 'm' excepting CONFIG_VIDEO_CX88_MPEG, which is marked as 'y'. I don't know if it's relevant or not, but the fact is that the module was not being compiled at all. The option was not visible inside menuconfig, by the way. I've done some changes inside Kconfig to make it visible in menuconfig, and by doing this I've been able to set it to 'm' and rebuild, which has just worked apparently. This Kconfig file was edited in revisions 10190 10191, precisely for reasons related to cx8802 dependencies, so I'm not sure the solution taken there was the right one. Best regards, Eduard Huguet -- 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] Make exported headers use strict posix types
A number of standard posix types are used in exported headers, which
is not allowed if __STRICT_KERNEL_NAMES is defined. Change them all
to use the safe __kernel variant so that we can make __STRICT_KERNEL_NAMES
the default.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
On Thursday 05 February 2009, H. Peter Anvin wrote:
I have been advocating for hacking headers_install for a while. That
takes care of the 106. The 15 *need* to be audited immediately, because
that is even likely to be actual manifest bugs.
This is what I found, please review.
diff --git a/include/asm-generic/fcntl.h b/include/asm-generic/fcntl.h
index b847741..4d3e483 100644
--- a/include/asm-generic/fcntl.h
+++ b/include/asm-generic/fcntl.h
@@ -117,9 +117,9 @@
struct flock {
short l_type;
short l_whence;
- off_t l_start;
- off_t l_len;
- pid_t l_pid;
+ __kernel_off_t l_start;
+ __kernel_off_t l_len;
+ __kernel_pid_t l_pid;
__ARCH_FLOCK_PAD
};
#endif
@@ -140,9 +140,9 @@ struct flock {
struct flock64 {
short l_type;
short l_whence;
- loff_t l_start;
- loff_t l_len;
- pid_t l_pid;
+ __kernel_loff_t l_start;
+ __kernel_loff_t l_len;
+ __kernel_pid_t l_pid;
__ARCH_FLOCK64_PAD
};
#endif
diff --git a/include/asm-generic/siginfo.h b/include/asm-generic/siginfo.h
index 9695701..35f75a3 100644
--- a/include/asm-generic/siginfo.h
+++ b/include/asm-generic/siginfo.h
@@ -23,7 +23,7 @@ typedef union sigval {
#endif
#ifndef __ARCH_SI_UID_T
-#define __ARCH_SI_UID_Tuid_t
+#define __ARCH_SI_UID_T__kernel_uid_t
#endif
/*
@@ -47,13 +47,13 @@ typedef struct siginfo {
/* kill() */
struct {
- pid_t _pid; /* sender's pid */
+ __kernel_pid_t _pid;/* sender's pid */
__ARCH_SI_UID_T _uid; /* sender's uid */
} _kill;
/* POSIX.1b timers */
struct {
- timer_t _tid; /* timer id */
+ __kernel_timer_t _tid; /* timer id */
int _overrun; /* overrun count */
char _pad[sizeof( __ARCH_SI_UID_T) - sizeof(int)];
sigval_t _sigval; /* same as below */
@@ -62,18 +62,18 @@ typedef struct siginfo {
/* POSIX.1b signals */
struct {
- pid_t _pid; /* sender's pid */
+ __kernel_pid_t _pid;/* sender's pid */
__ARCH_SI_UID_T _uid; /* sender's uid */
sigval_t _sigval;
} _rt;
/* SIGCHLD */
struct {
- pid_t _pid; /* which child */
+ __kernel_pid_t _pid;/* which child */
__ARCH_SI_UID_T _uid; /* sender's uid */
int _status;/* exit code */
- clock_t _utime;
- clock_t _stime;
+ __kernel_clock_t _utime;
+ __kernel_clock_t _stime;
} _sigchld;
/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
diff --git a/include/linux/agpgart.h b/include/linux/agpgart.h
index 110c600..f6778ec 100644
--- a/include/linux/agpgart.h
+++ b/include/linux/agpgart.h
@@ -77,20 +77,20 @@ typedef struct _agp_setup {
* The prot down below needs still a sleep flag somehow ...
*/
typedef struct _agp_segment {
- off_t pg_start; /* starting page to populate*/
- size_t pg_count;/* number of pages */
- int prot; /* prot flags for mmap */
+ __kernel_off_t pg_start;/* starting page to populate*/
+ __kernel_size_t pg_count; /* number of pages */
+ int prot; /* prot flags for mmap */
} agp_segment;
typedef struct _agp_region {
- pid_t pid; /* pid of process */
- size_t seg_count; /* number of segments */
+ __kernel_pid_t pid; /* pid of process */
+ __kernel_size_t seg_count; /* number of segments */
struct _agp_segment *seg_list;
} agp_region;
typedef struct _agp_allocate {
int key;/* tag of allocation*/
- size_t pg_count;/* number of pages */
+ __kernel_size_t pg_count;/* number of pages */
__u32 type; /* 0 == normal, other devspec */
__u32 physical; /* device specific (some devices
* need a phys address of the
@@ -100,7 +100,7 @@ typedef struct _agp_allocate {
typedef struct _agp_bind {
int key;
[PULL] http://linuxtv.org/hg/~dougsland/radios/
Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/radios/ for the following: - radio-mr800: fix checking of retval after usb_bulk_msg - radio-mr800: increase version and add comments - radio-mr800: add few lost mutex locks - radio-mr800: add stereo support - radio-mr800: fix amradio_set_freq - radio-mr800: move radio start and stop in one function - radio-mr800: add more dev_err messages in probe - radio-mr800: place dev_err instead of dev_warn - radio-mr800: codingstyle cleanups Thanks, Douglas -- 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] Make exported headers use strict posix types
Arnd Bergmann wrote: A number of standard posix types are used in exported headers, which is not allowed if __STRICT_KERNEL_NAMES is defined. Change them all to use the safe __kernel variant so that we can make __STRICT_KERNEL_NAMES the default. Signed-off-by: Arnd Bergmann a...@arndb.de --- On Thursday 05 February 2009, H. Peter Anvin wrote: I have been advocating for hacking headers_install for a while. That takes care of the 106. The 15 *need* to be audited immediately, because that is even likely to be actual manifest bugs. This is what I found, please review. Indeed a lot of these look like real bugs, e.g. the use of off_t (which may be 32 bits in userspace while __kernel_off_t is 64 bits.) So these are, indeed, critical bug fixes and should go into 2.6.29. Some of these changes may require changes in userspace code if userspace has hacked around the problems. Those changes, though, really should happen, too. -hpa -- 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] LV8093: Add driver for LV8093 lens actuator.
-Original Message- From: Juan Jesús García de Soria Lucena [mailto:skanda...@gmail.com] Sent: Thursday, February 05, 2009 1:26 AM To: Curran, Dominic Cc: linux-media@vger.kernel.org Subject: Re: [REVIEW][PATCH] LV8093: Add driver for LV8093 lens actuator. Hi. 2009/2/4 Dominic Curran dcur...@ti.com: The device has only one read register which contains a single BUSY bit. For large relative lens movements the device can be busy for sometime and we need to know when the lens has stopped moving. My question is what is the most appropriate mechanism to read the BUSY bit ? Currently the driver uses the VIDIOC_G_CTRL ioctl + V4L2_CID_FOCUS_RELATIVE ctrl ID to return the BUSY bit. Is this acceptable ? [...] A 3rd solution is to read the BUSY bit everytime after a write and not return until device is ready. However this adds extra time to the operation (particularly for small lens moves) and I would like the user to be in change of when the reads of BUSY bit occur. And what about waiting for not BUSY at the *beginning* of the next lens adjustment if the previous one hasn't finished yet? This could be combined with either a polling interface or a sync style interface (wait for not BUSY function) for the case in which the user wants to actually be sure that the lens got up to its target state. Yes, poll would be a good solution, but I'm can not workout how I can add a poll() method to a v4l slave driver ? Are there an examples of such v4l slave drivers you can point me too ? All the v4l drivers I can find that have .poll fops register using video_register_device(). My slave driver uses v4l2_int_device_register(). Any pointers appreciated. Thanks dom -- 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: Re : [linux-dvb] Re : Technotrend Budget S2-3200 Digital artefacts on HDchannels
Manu wrote: Le 02.02.2009 18:43:33, Chris Silva a écrit : On Tue, Jan 27, 2009 at 9:13 PM, Manu Abraham abraham.m...@gmail.com wrote: Alex Betis wrote: On Tue, Jan 27, 2009 at 9:56 PM, Manu Abraham abraham.m...@gmail.comwrote: Hmm OK, but is there by any chance a fix for those issues somewhere or in the pipe at least? I am willing to test (as I already offered), I can compile the drivers, spread printk or whatever else is needed to get useful reports. Let me know if I can help sort this problem. BTW in my case it is DVB-S2 3 SR and FEC 5/6. It was quite not appreciable on my part to provide a fix or reply in time nor spend much time on it earlier, but that said i was quite stuck up with some other things. Can you please pull a copy of the multiproto tree http://jusst.de/hg/multiproto or the v4l-dvb tree from http://jusst.de/hg/v4l-dvb and apply the following patch and comment what your result is ? Before applying please do check whether you still have the issues. Manu, I've tried to increase those timers long ago when played around with my card (Twinhan 1041) and scan utility. I must say that I've concentrated mostly on DVB-S channels that wasn't always locking. I didn't notice much improvements. The thing that did help was increasing the resolution of scan zigzags. With regards to the zig-zag, one bug is fixed in the v4l-dvb tree. Most likely you haven't tried that change. I've sent a patch on that ML and people were happy with the results. I did look at your patch, but that was completely against the tuning algorithm. [..] I believe DVB-S2 lock suffer from the same problem, but in that case the zigzag is done in the chip and not in the driver. Along with the patch i sent, does the attached patch help you in anyway (This works out for DVB-S2 only)? Manu, I've tried both multiproto branches you indicated above, *with* and *without* the patches you sent to the ML (fix_iterations.patch and increase timeout.patch) on this thread. Sadly, same behavior as S2API V4L-DVB current branch. No lock on 3 3/4 channels. It achieves a 0.5 second jittery sound but no image. It seems the driver is struggling to correctly lock on that channel, but doesn't get there in time... Or maybe the hardware... Dunno... Can you please send me a complete trace with the stb6100 and stb0899 modules loaded with verbose=5 for the 30MSPS transponder what you are trying ? One simple szap would be enough (no scan please) based on the http://jusst.de/hg/v4l-dvb tree. Before you start testing, start clean from a cold boot after a powerdown. This makes it a bit more easier identify things. Regards, Manu -- 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: [PULL] http://linuxtv.org/hg/~dougsland/radios/
Hi Mauro, I've added a new patch. On Thu, 5 Feb 2009 15:46:02 -0200 Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/radios/ for the following: - radio-mr800: fix checking of retval after usb_bulk_msg - radio-mr800: increase version and add comments - radio-mr800: add few lost mutex locks - radio-mr800: add stereo support - radio-mr800: fix amradio_set_freq - radio-mr800: move radio start and stop in one function - radio-mr800: add more dev_err messages in probe - radio-mr800: place dev_err instead of dev_warn - radio-mr800: codingstyle cleanups - radio-si470x: use usb_make_path in usb-radio drivers Thanks, Douglas -- 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] Mantis Bug (was Technisat HD2 cannot szap/scan)
Hello,
i'm sorry to bother you with this small thing.
On Thu, 2009-02-05 at 13:34 +0100, Hans Werner wrote:
Hi,
checked it again. Your lnbp21 patch definitely kills S2 tuning
on the Terratec Cinergy S2 PCI HD.
mfg
Edgar ( gimli ) Hucek
I looked at it again and here is a new patch to set the LNBP21
options for the Twinhan VP-1041. This works better for me, including
DVB-S2 channels. The EN enable bit is now not permanently set so
sleep behavior is correct.
Please note that I have a DiSEqC 1.2 rotor between the VP-1041 card
and the LNB. That is quite a normal configuration, but the driver was
probably not properly tested with rotors (and switches?) before.
To rotate with scan-s2 use the patch I posted, which will be applied
there soon:
http://linuxtv.org/pipermail/linux-dvb/2009-January/031660.html
Regards,
Hans
Patch is against latest http://mercurial.intuxication.org/hg/s2-liplianin
repo.
Signed-off-by: Hans Werner hwern...@gmx.de
diff -r 084878324629 linux/drivers/media/dvb/mantis/mantis_dvb.c
--- a/linux/drivers/media/dvb/mantis/mantis_dvb.c
+++ b/linux/drivers/media/dvb/mantis/mantis_dvb.c
@@ -239,7 +239,8 @@ int __devinit mantis_frontend_init(struc
vp1041_config.demod_address);
if (stb6100_attach(mantis-fe, vp1041_stb6100_config,
mantis-adapter)) {
- if (!lnbp21_attach(mantis-fe,
mantis-adapter, 0, 0)) {
+ // static current limit, no extra 1V, high
current limit, tone from DSQIN pin (stb0899)
May i ask you not to use C99-style // ... comments ?
Linux style for comments is the C89 /* ... */ style.
Honestly, when you do make checkpatch it will notify you about bad
things (style of comments included).
+ if (!lnbp21_attach(mantis-fe,
mantis-adapter, LNBP21_PCL , LNBP21_LLC | LNBP21_ISEL | LNBP21_TEN)) {
printk(%s: No LNBP21 found!\n,
__FUNCTION__);
mantis-fe = NULL;
}
--
Best regards, Klimov Alexey
--
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] LV8093: Add driver for LV8093 lens actuator.
Hello, Dominic
May i make few comments ?
On Wed, 2009-02-04 at 12:40 -0600, Dominic Curran wrote:
Hi
Below is a new driver for the LV8093 lens actuator.
Of course all comments are welcome, however I have a specific issue that i am
concerned about...
The lens position cannot be read back from this device, and it
only takes relative positions (it uses V4L2_CID_FOCUS_RELATIVE ctrl ID).
The device has only one read register which contains a single BUSY bit.
For large relative lens movements the device can be busy for sometime and we
need
to know when the lens has stopped moving.
My question is what is the most appropriate mechanism to read the BUSY bit ?
Currently the driver uses the VIDIOC_G_CTRL ioctl + V4L2_CID_FOCUS_RELATIVE
ctrl
ID to return the BUSY bit. Is this acceptable ?
The only other solution I can think of is:
* Use does VIDIOC_S_CTRL ioctl
.id = V4L2_CID_FOCUS_RELATIVE
.value = 0
* If driver detects .value=0 then it reads the BUSY bit and returns either
0 - Ready
-EBUSY - lens busy
A 3rd solution is to read the BUSY bit everytime after a write and not return
until device is ready. However this adds extra time to the operation
(particularly for small lens moves) and I would like the user to be in change
of
when the reads of BUSY bit occur.
I hope I have made my question clear.
Any guidance appreciated
thanks
dom
From: Dominic Curran dcur...@ti.com
Subject: [PATCH v2 1/3] LV8093: Add driver for LV8093 lens actuator.
Support for the Sanyo LV8093CS piezo-actuator lens driver.
The lens position cannot be read back from this device, and it
only takes relative positions. Thus it:
- Supports the VIDIOC_G_CTRL ioctl to return BUSY bit (0 - Ready, ~0 - Busy)
- Supports the VIDIOC_S_CTRL ioctl with the V4L2_CID_FOCUS_RELATIVE control
ID.
One relative step requested through the V4L2_CID_FOCUS_RELATIVE control will
produce a 5.0um step @ 5.2mm/s of the lens.
Signed-off-by: Kraig Proehl kraig.pro...@hp.com
Signed-off-by: Dominic Curran dcur...@ti.com
---
drivers/media/video/lv8093.c | 595
+++
drivers/media/video/lv8093.h | 92 ++
2 files changed, 687 insertions(+)
Index: omapzoom04/drivers/media/video/lv8093.c
===
--- /dev/null
+++ omapzoom04/drivers/media/video/lv8093.c
@@ -0,0 +1,595 @@
+/*
+ * drivers/media/video/lv8093.c
+ *
+ * LV8093 Piezo Motor (LENS) driver
+ *
+ * Copyright (C) 2008-2009 Texas Instruments.
+ * Copyright (C) 2009 Hewlett-Packard.
+ *
+ * This package 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include linux/mutex.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/cdev.h
+#include linux/device.h
+
+#include media/v4l2-int-device.h
+#include mach/gpio.h
+
+#include lv8093.h
+
+static int
+lv8093_probe(struct i2c_client *client, const struct i2c_device_id *id);
+static int __exit lv8093_remove(struct i2c_client *client);
+
+struct lv8093_device {
+ const struct lv8093_platform_data *pdata;
+ struct v4l2_int_device *v4l2_int_device;
+ struct i2c_client *i2c_client;
+ int state;
+ int power_state;
+};
+
+static const struct i2c_device_id lv8093_id[] = {
+ {LV8093_NAME, 0},
+ {}
+};
+
+MODULE_DEVICE_TABLE(i2c, lv8093_id);
+
+static struct i2c_driver lv8093_i2c_driver = {
+ .driver = {
+.name = LV8093_NAME,
+.owner = THIS_MODULE,
+},
+ .probe = lv8093_probe,
+ .remove = __exit_p(lv8093_remove),
+ .id_table = lv8093_id,
+};
+
+static struct lv8093_device lv8093 = {
+ .state = LENS_NOT_DETECTED,
+};
+
+static struct vcontrol {
+ struct v4l2_queryctrl qc;
+} video_control[] = {
+ {
+ {
+ .id = V4L2_CID_FOCUS_RELATIVE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Lens Relative Position,
+ .minimum = 0,
+ .maximum = 0,
+ .step = LV8093_MAX_RELATIVE_STEP,
+ .default_value = 0,
+ }
+ ,}
+};
+
+static struct i2c_driver lv8093_i2c_driver;
+
+static struct lv8093_lens_settings {
+ u8 reg;
+ u8 val;
+} lens_settings[] = {
+ { /* Set control register */
+ .reg = CAMAF_LV8093_CTL_REG,
+ .val = CAMAF_LV8093_GATE0 |
+ CAMAF_LV8093_ENIN |
+ CAMAF_LV8093_CKSEL_ONE |
+
