question about drivers/media/dvb-frontends/rtl2830.c
The function rtl2830_init contains the code: buf[0] = tmp 6; buf[0] = (if_ctl 16) 0x3f; buf[1] = (if_ctl 8) 0xff; buf[2] = (if_ctl 0) 0xff; Is there any purpose to initializing buf[0] twice? julia -- 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: question about drivers/media/dvb-frontends/rtl2830.c
Julia Lawall julia.law...@lip6.fr wrote: The function rtl2830_init contains the code: buf[0] = tmp 6; buf[0] = (if_ctl 16) 0x3f; buf[1] = (if_ctl 8) 0xff; buf[2] = (if_ctl 0) 0xff; Is there any purpose to initializing buf[0] twice? julia -- 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 Hmm. Since 0x3f is the lowest 6 bits, it looks like the second line should use |= instead of = . I don't know anything about the rt2830 though. -Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug] gspca_zc3xx v.2.14.0 Auto Gain is OFF
This is a bug report for gspca_zc3xx v.2.14.0 webcam driver installed as a
module on ArchLinux plug computer, kernel 3.5.2-1-ARCH
[root@alarm ~]# dmesg
[ 15.271381] gspca_main: v2.14.0 registered
[ 15.303224] gspca_main: gspca_zc3xx-2.14.0 probing 046d:08d7
[ 16.211715] fuse init (API version 7.19)
[ 16.461436] input: gspca_zc3xx as
/devices/platform/orion-ehci.0/usb1/1-1/1-1.4/input/input0
[ 16.469635] usbcore: registered new interface driver snd-usb-audio
[ 16.470642] usbcore: registered new interface driver gspca_zc3xx
[root@alarm ~]# lsusb
Bus 001 Device 004: ID 046d:08d7 Logitech, Inc. QuickCam Communicate STX
[root@alarm ~]# v4lctl list
attribute | type | current | default | comment
---++-+-+-
norm | choice | (null) | (null) |
input | choice | gspca_z | gspca_z | gspca_zc3xx
bright | int| 128 | 128 | range is 0 = 255
contrast | int| 128 | 128 | range is 0 = 255
Gamma | int| 4 | 4 | range is 1 = 6
Exposure | int|2343 |2343 | range is 781 = 18750
Gain, Auto | bool | on | on |
Power Line | choice | Disable | Disable | Disabled 50 Hz 60 Hz
Sharpness | int| 2 | 2 | range is 0 = 3
The above output is complete, there is nothing else coming from dmesg.
In Windows 7 64-bit with the webcam connected, while running Logitech
Webcam Software, shows some extra info:
Logitech QuickCam Communicate STX
Hardware ID USB\VID_046DPID_08D7REV_0100MI_00
Procmon output for LWS.exe (from Registry):
ZC0302 chipset, Image Sensor HV7131B
Attached to this message are exported webcam Registry settings (default
and factual), and controls available for the webcam and optimally set by
LWS. Also attached are datasheets for the webcam chipset and image sensor.
The main problems now are:
- Image Sensor can't be identified by gspca_zc3xx driver or verified by
user since
not shown in dmesg
- Auto Gain is switched off permanently (despite shown On), and its choice
range is missing
- Color Saturation and White Balance controls are absent
- Changes in image are unnoticed when adjusting Brightness and Contrast
within their full range
The webcam works with exposure and other adjustments manually changed over
the day, but very difficult to get quality image in evening low light.
See also the discussion
(https://bbs.archlinux.org/viewtopic.php?pid=879810#p879810) on how
varying the driver's settings (quality and other) affects controls
responsiveness (brightness and contrast) and perceived image quality.
Thanks,
SamÿþK e y N a m e :
H K E Y _ L O C A L _ M A C H I N E \ S Y S T E M \ C o n t r o l S e t 0 0 1 \ C o n t r o l \ C l a s s \ { 6 B D D 1 F C 6 - 8 1 0 F - 1 1 D 0 - B E C 7 - 0 8 0 0 2 B E 2 0 9 2 F } \ 0 0 0 1
C l a s s N a m e : N O C L A S S
L a s t W r i t e T i m e : 6 / 2 5 / 2 0 1 2 - 7 : 0 8 P M
V a l u e 0
N a m e : C o I n s t a l l e r s 3 2
T y p e : R E G _ M U L T I _ S Z
D a t a :
l v c o 1 2 0 1 2 7 8 . d l l , L v C o I n s t a l l e r
V a l u e 1
N a m e : D e v L o a d e r
T y p e : R E G _ S Z
D a t a : * n t k e r n
V a l u e 2
N a m e : N T M P D r i v e r
T y p e : R E G _ S Z
D a t a : L V 3 0 2 V 6 4 . S Y S
V a l u e 3
N a m e : P a g e O u t W h e n U n o p e n e d
T y p e : R E G _ B I N A R Y
D a t a :
0 0 0 0 0 0 0 0 0 0
.
V a l u e 4
N a m e :
D o n t S u s p e n d I f S t r e a m s A r e R u n n i n g
T y p e : R E G _ B I N A R Y
D a t a :
0 0 0 0 0 0 0 0 0 0
.
V a l u e 5
N a m e : H a r d w a r e C o n f i g
T y p e : R E G _ B I N A R Y
D a t a :
0 0 0 0 0 0 0 0 0 1
.
V a l u e 6
N a m e : L V F u n c t i o n s
T y p e : R E G _ D W O R D
D a t a : 0 x 3
V a l u e 7
N a m e : L V F e a t u r e s
T y p e :
Re: [Bug] gspca_zc3xx v.2.14.0 Auto Gain is OFF (Chipset Config)
Webcam Chipset Config for reference:
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class
\{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001
Class Name:NO CLASS
Last Write Time: 6/25/2012 - 7:08 PM
Value 0
Name:CoInstallers32
Type:REG_MULTI_SZ
Data:lvco1201278.dll,LvCoInstaller
Value 1
Name:DevLoader
Type:REG_SZ
Data:*ntkern
Value 2
Name:NTMPDriver
Type:REG_SZ
Data:LV302V64.SYS
Value 3
Name:PageOutWhenUnopened
Type:REG_BINARY
Data:
00 .
Value 4
Name:DontSuspendIfStreamsAreRunning
Type:REG_BINARY
Data:
00 .
Value 5
Name:HardwareConfig
Type:REG_BINARY
Data:
01 .
Value 6
Name:LVFunctions
Type:REG_DWORD
Data:0x3
Value 7
Name:LVFeatures
Type:REG_DWORD
Data:0
Value 8
Name:LVCategories
Type:REG_DWORD
Data:0x1121
Value 9
Name:LVDistribution
Type:REG_DWORD
Data:0x1
Value 10
Name:USDClass
Type:REG_SZ
Data:{0527d1d0-88c2-11d2-82c7-00c04f8ec183}
Value 11
Name:EnumPropPages32
Type:REG_SZ
Data:Lvui64.dll,EnumPropPages
Value 12
Name:LVPowSaveDisable
Type:REG_DWORD
Data:0x1
Value 13
Name:LVSSDisable
Type:REG_DWORD
Data:0x1
Value 14
Name:LVSelSusInterfaceGUID
Type:REG_SZ
Data:{FA33C4CD-7C6D-4a5d-8AD4-CFB86D02AE9E}
Value 15
Name:InfPath
Type:REG_SZ
Data:oem76.inf
Value 16
Name:IncludedInfs
Type:REG_MULTI_SZ
Data:ks.inf
kscaptur.inf
ksfilter.inf
Value 17
Name:InfSection
Type:REG_SZ
Data:PID_08D7.XPAMD64
Value 18
Name:ProviderName
Type:REG_SZ
Data:Logitech
Value 19
Name:DriverDateData
Type:REG_BINARY
Data:
00 80 cf 9a 26 c9 c9 01 - ..Ï.ÉÉ.
Value 20
Name:DriverDate
Type:REG_SZ
Data:4-30-2009
Value 21
Name:DriverVersion
Type:REG_SZ
Data:12.0.1278.0
Value 22
Name:MatchingDeviceId
Type:REG_SZ
Data:usb\vid_046dpid_08d7mi_00
Value 23
Name:DriverDesc
Type:REG_SZ
Data:Logitech QuickCam Communicate STX
Value 24
Name:KS
Type:REG_SZ
Data:1
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class
\{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001\ChipConfig
Class Name:NO CLASS
Last Write Time: 6/25/2012 - 7:08 PM
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class
\{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001\ChipConfig\SupportSensor
Class Name:NO CLASS
Last Write Time: 6/25/2012 - 7:08 PM
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class
\{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001\ChipConfig\SupportSensor\HV7131B
Class Name:NO CLASS
Last Write Time: 6/25/2012 - 7:08 PM
Value 0
Name:CMD
Type:REG_BINARY
Data:
ff 20 00 00 f0 01 03 00 - f0 02 10 30 ÿ ..ð...ð..0
Value 1
Name:Initial
Type:REG_BINARY
Data:
00 00 01 cc 00 02 00 cc - 00 10 01 cc 00 01 01 cc ...Ì...Ì...Ì...Ì
0010 01 01 77 cc 00 08 03 cc - 00 12 07 cc 00 12 01 cc ..wÌ...Ì...Ì...Ì
0020 00 03 02 cc 00 04 80 cc - 00 05 01 cc 00 06 e0 cc ...Ì...Ì...Ì..àÌ
0030 00 98 00 cc 00 9a 00 cc - 00 9b 01 cc 00 9c e6 cc ...Ì...Ì...Ì..æÌ
0040 00 9d 02 cc 00 9e 86 cc - 01 1a 00 cc 01 1c 00 cc ...Ì...Ì...Ì...Ì
0050 00 12 07 cc 00 02 00 dd - 00 12 05 cc 00 01 0c aa ...Ì...Ý...Ì...ª
0060 00 11 00 aa 00 13 00 aa - 00 14 01 aa 00 15 e6 aa ...ª...ª...ª..æª
0070 00 16 02 aa 00 17 86 aa - 00 30 0b aa 00 19 00 cc ...ª...ª.0.ª...Ì
0080 01 00 0d cc 01 8d 78 cc - 01 a8 50 cc 01 ad 00 cc ...Ì..xÌ.¨PÌ..Ì
0090 01 9b c0 cc 01 9c a0 cc - 01 89 06 cc 01 c5 03 cc ..ÀÌ.. Ì...Ì.Å.Ì
00a0 01 cb 13 cc 02 50 08 cc - 03 01 08 cc .Ë.Ì.P.Ì...Ì
Value 2
Name:InitialScale
Type:REG_BINARY
Data:
00 00 01 cc 00 02 10 cc - 00 10 01 cc 00 01 01 cc ...Ì...Ì...Ì...Ì
Re: [Bug] gspca_zc3xx v.2.14.0 Auto Gain is OFF
Registry Data for reference: Image Sensor Config
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class
\{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001
Class Name: NO CLASS
Last Write Time: 6/25/2012 - 7:08 PM
Value 0
Name: CoInstallers32
Type: REG_MULTI_SZ
Data: lvco1201278.dll,LvCoInstaller
Value 1
Name: DevLoader
Type: REG_SZ
Data: *ntkern
Value 2
Name: NTMPDriver
Type: REG_SZ
Data: LV302V64.SYS
Value 3
Name: PageOutWhenUnopened
Type: REG_BINARY
Data:
00 .
Value 4
Name: DontSuspendIfStreamsAreRunning
Type: REG_BINARY
Data:
00 .
Value 5
Name: HardwareConfig
Type: REG_BINARY
Data:
01 .
Value 6
Name: LVFunctions
Type: REG_DWORD
Data: 0x3
Value 7
Name: LVFeatures
Type: REG_DWORD
Data: 0
Value 8
Name: LVCategories
Type: REG_DWORD
Data: 0x1121
Value 9
Name: LVDistribution
Type: REG_DWORD
Data: 0x1
Value 10
Name: USDClass
Type: REG_SZ
Data: {0527d1d0-88c2-11d2-82c7-00c04f8ec183}
Value 11
Name: EnumPropPages32
Type: REG_SZ
Data: Lvui64.dll,EnumPropPages
Value 12
Name: LVPowSaveDisable
Type: REG_DWORD
Data: 0x1
Value 13
Name: LVSSDisable
Type: REG_DWORD
Data: 0x1
Value 14
Name: LVSelSusInterfaceGUID
Type: REG_SZ
Data: {FA33C4CD-7C6D-4a5d-8AD4-CFB86D02AE9E}
Value 15
Name: InfPath
Type: REG_SZ
Data: oem76.inf
Value 16
Name: IncludedInfs
Type: REG_MULTI_SZ
Data: ks.inf
kscaptur.inf
ksfilter.inf
Value 17
Name: InfSection
Type: REG_SZ
Data: PID_08D7.XPAMD64
Value 18
Name: ProviderName
Type: REG_SZ
Data: Logitech
Value 19
Name: DriverDateData
Type: REG_BINARY
Data:
00 80 cf 9a 26 c9 c9 01 - ..Ï.ÉÉ.
Value 20
Name: DriverDate
Type: REG_SZ
Data: 4-30-2009
Value 21
Name: DriverVersion
Type: REG_SZ
Data: 12.0.1278.0
Value 22
Name: MatchingDeviceId
Type: REG_SZ
Data: usb\vid_046dpid_08d7mi_00
Value 23
Name: DriverDesc
Type: REG_SZ
Data: Logitech QuickCam Communicate STX
Value 24
Name: KS
Type: REG_SZ
Data: 1
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class
\{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001\ChipConfig
Class Name: NO CLASS
Last Write Time: 6/25/2012 - 7:08 PM
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class
\{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001\ChipConfig\SupportSensor
Class Name: NO CLASS
Last Write Time: 6/25/2012 - 7:08 PM
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class
\{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001\ChipConfig\SupportSensor\HV7131B
Class Name: NO CLASS
Last Write Time: 6/25/2012 - 7:08 PM
Value 0
Name: CMD
Type: REG_BINARY
Data:
ff 20 00 00 f0 01 03 00 - f0 02 10 30 ÿ ..ð...ð..0
Value 1
Name: Initial
Type: REG_BINARY
Data:
00 00 01 cc 00 02 00 cc - 00 10 01 cc 00 01 01 cc ...Ì...Ì...Ì...Ì
0010 01 01 77 cc 00 08 03 cc - 00 12 07 cc 00 12 01 cc ..wÌ...Ì...Ì...Ì
0020 00 03 02 cc 00 04 80 cc - 00 05 01 cc 00 06 e0 cc ...Ì...Ì...Ì..àÌ
0030 00 98 00 cc 00 9a 00 cc - 00 9b 01 cc 00 9c e6 cc ...Ì...Ì...Ì..æÌ
0040 00 9d 02 cc 00 9e 86 cc - 01 1a 00 cc 01 1c 00 cc ...Ì...Ì...Ì...Ì
0050 00 12 07 cc 00 02 00 dd - 00 12 05 cc 00 01 0c aa ...Ì...Ý...Ì...ª
0060 00 11 00 aa 00 13 00 aa - 00 14 01 aa 00 15 e6 aa ...ª...ª...ª..æª
0070 00 16 02 aa 00 17 86 aa - 00 30 0b aa 00 19 00 cc ...ª...ª.0.ª...Ì
0080 01 00 0d cc 01 8d 78 cc - 01 a8 50 cc 01 ad 00 cc ...Ì..xÌ.¨PÌ..Ì
0090 01 9b c0 cc 01 9c a0 cc - 01 89 06 cc 01 c5 03 cc ..ÀÌ.. Ì...Ì.Å.Ì
00a0 01 cb 13 cc 02 50 08 cc - 03 01 08 cc .Ë.Ì.P.Ì...Ì
Value 2
Name: InitialScale
Type: REG_BINARY
Data:
00 00 01 cc 00 02 10 cc - 00 10 01 cc 00 01 01 cc ...Ì...Ì...Ì...Ì
0010 01 01 77 cc 00 08 03 cc - 00 12 07 cc 00 12 01 cc ..wÌ...Ì...Ì...Ì
0020 00 03 02 cc 00 04 80 cc - 00 05 01 cc 00 06 e0 cc ...Ì...Ì...Ì..àÌ
0030 00 98 00 cc 00 9a 00 cc - 00 9b 01 cc 00 9c e8 cc ...Ì...Ì...Ì..èÌ
0040 00 9d 02 cc 00 9e 88 cc - 01 1a 00 cc 01 1c 00 cc ...Ì...Ì...Ì...Ì
0050 00 12 07 cc 00 02 00 dd - 00 12 05 cc 00 01 0c aa ...Ì...Ý...Ì...ª
0060 00 11 00 aa 00 13 00 aa - 00 14 01 aa 00 15 e8 aa ...ª...ª...ª..èª
0070 00 16 02 aa 00 17 88 aa - 00 30 0b aa 00 19 00 cc ...ª...ª.0.ª...Ì
0080 01 00 0d cc 01 8d 78 cc - 01 a8 50 cc 01 ad 00 cc ...Ì..xÌ.¨PÌ..Ì
0090 01 9b c0 cc 01 9c a0 cc - 01 89 06 cc 01 c5 03 cc ..ÀÌ.. Ì...Ì.Å.Ì
00a0 01 cb 13 cc 02 50 08 cc - 03 01 08 cc .Ë.Ì.P.Ì...Ì
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class
\{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001\ChipConfig\SupportSensor\HV7131B\AE
Class Name: NO CLASS
Last Write Time: 6/25/2012 - 7:08 PM
Value 0
Name: 50HZ
Type: REG_BINARY
Data:
00 19 00 cc 01 90 06 cc - 01 91 68 cc 01 92 a0 cc ...Ì...Ì..hÌ.. Ì
0010 01 95 00 cc 01 96 ea cc - 01 97 60 cc 01 8c 18 cc ...Ì..êÌ..`Ì...Ì
0020 01 8f 20 cc 01 a9 10 cc - 01 aa 66 cc 00 1d 00 cc .. Ì.©.Ì.ªfÌ...Ì
0030 00 1e d0 cc 00 1f 00 cc - 00 20 08 cc ..ÐÌ...Ì. .Ì
Value 1
Name: 50HZScale
Type: REG_BINARY
Data:
00 19
Re: question about drivers/media/dvb-frontends/rtl2830.c
On 08/26/2012 02:20 PM, Andy Walls wrote: Julia Lawall julia.law...@lip6.fr wrote: The function rtl2830_init contains the code: buf[0] = tmp 6; buf[0] = (if_ctl 16) 0x3f; buf[1] = (if_ctl 8) 0xff; buf[2] = (if_ctl 0) 0xff; Is there any purpose to initializing buf[0] twice? julia -- 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 Hmm. Since 0x3f is the lowest 6 bits, it looks like the second line should use |= instead of = . I don't know anything about the rt2830 though. -Andy Andy is correct. If you look few lines just before that you could see that logic. Patch is welcome. regards Antti -- http://palosaari.fi/ -- 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] drivers/media/dvb-frontends/rtl2830.c: correct double assignment
From: Julia Lawall julia.law...@lip6.fr The double assignment is meant to be a bit-or to combine two values. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // smpl @@ expression i; @@ *i = ...; i = ...; // /smpl Signed-off-by: Julia Lawall julia.law...@lip6.fr --- drivers/media/dvb-frontends/rtl2830.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/rtl2830.c b/drivers/media/dvb-frontends/rtl2830.c index 8fa8b08..b6ab858 100644 --- a/drivers/media/dvb-frontends/rtl2830.c +++ b/drivers/media/dvb-frontends/rtl2830.c @@ -254,7 +254,7 @@ static int rtl2830_init(struct dvb_frontend *fe) goto err; buf[0] = tmp 6; - buf[0] = (if_ctl 16) 0x3f; + buf[0] |= (if_ctl 16) 0x3f; buf[1] = (if_ctl 8) 0xff; buf[2] = (if_ctl 0) 0xff; -- 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: question about drivers/media/dvb-frontends/rtl2830.c
On Sun, 26 Aug 2012, Antti Palosaari wrote: On 08/26/2012 02:20 PM, Andy Walls wrote: Julia Lawall julia.law...@lip6.fr wrote: The function rtl2830_init contains the code: buf[0] = tmp 6; buf[0] = (if_ctl 16) 0x3f; buf[1] = (if_ctl 8) 0xff; buf[2] = (if_ctl 0) 0xff; Is there any purpose to initializing buf[0] twice? julia -- 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 Hmm. Since 0x3f is the lowest 6 bits, it looks like the second line should use |= instead of = . I don't know anything about the rt2830 though. -Andy Andy is correct. If you look few lines just before that you could see that logic. Patch is welcome. Done. Thanks for the quick responses. julia -- 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] drivers/media/dvb-frontends/rtl2830.c: correct double assignment
On 08/26/2012 07:15 PM, Julia Lawall wrote: From: Julia Lawall julia.law...@lip6.fr The double assignment is meant to be a bit-or to combine two values. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // smpl @@ expression i; @@ *i = ...; i = ...; // /smpl Signed-off-by: Julia Lawall julia.law...@lip6.fr --- drivers/media/dvb-frontends/rtl2830.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/rtl2830.c b/drivers/media/dvb-frontends/rtl2830.c index 8fa8b08..b6ab858 100644 --- a/drivers/media/dvb-frontends/rtl2830.c +++ b/drivers/media/dvb-frontends/rtl2830.c @@ -254,7 +254,7 @@ static int rtl2830_init(struct dvb_frontend *fe) goto err; buf[0] = tmp 6; - buf[0] = (if_ctl 16) 0x3f; + buf[0] |= (if_ctl 16) 0x3f; buf[1] = (if_ctl 8) 0xff; buf[2] = (if_ctl 0) 0xff; Thank you! Acked-by: Antti Palosaari cr...@iki.fi Reviewed-by: Antti Palosaari cr...@iki.fi Antti -- http://palosaari.fi/ -- 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] Add support to Avermedia Twinstar double tuner in af9035
On 08/25/2012 10:05 PM, Jose Alberto Reguero wrote: This patch add support to the Avermedia Twinstar double tuner in the af9035 driver. This time the patch inline because it was rejected. Also patch was malformed. Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net mailto:jaregu...@telefonica.net Jose Alberto Hello Jose, and thank you very much to hack this important and missing piece of AF9035 driver functionality. I looked it quickly and here is the comments so far. I will try to review it more carefully tomorrow. * your patch is very hard to read/review as you used some diff option that does not show function name whom code is changed * there is two new configuration parameters for af9033 demod. I don't understand why. As I don't see any need / use for those I want you to remove those. Configurations structures are something not to add any extra parameters just for fun. Use ts_mode != AF9033_TS_MODE_USB instead of second. Other parameter tuner_address is not used at all for af9033. * MXL5007T is not my driver. There seems to be new parameters no_probe and no_reset. Those sounds also something that could be avoided. But I didn't looked that code and I am not sure. Add at least comment why those are used as such parameters deviates from normal use. Could you also sent small sniff for me where is dual tuner used? regards Antti -- http://palosaari.fi/ -- 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/1] S3C244X/S3C64XX SoC camera host interface driver
Hi Tomasz, On 08/12/2012 12:22 AM, Tomasz Figa wrote: On Saturday 11 of August 2012 21:32:15 Sylwester Nawrocki wrote: On 08/11/2012 08:39 PM, Tomasz Figa wrote: Hi, On Saturday 11 of August 2012 20:06:13 Sylwester Nawrocki wrote: Hi all, This patch adds a driver for Samsung S3C244X/S3C64XX SoC series camera host interface. My intention was to create a V4L2 driver that would work with standard applications like Gstreamer or mplayer, and yet exposing possibly all features available in the hardware. It took me several weeks to do this work in my (limited) spare time. Finally I've got something that is functional and I think might be useful for others, so I'm publishing this initial version. It hopefully doesn't need much tweaking or corrections, at least as far as S3C244X is concerned. It has not been tested on S3C64XX SoCs, as I don't have the hardware. However, the driver has been designed with covering S3C64XX as well in mind, and I've already taken care of some differences between S3C2444X and S3C64XX. Mem-to-mem features are not yet supported, but these are quite separate issue and could be easily added as a next step. I will try to test it on S3C6410 in some reasonably near future and report any needed corrections. Sounds great, thanks. I have not tested the driver yet, but I am looking through the code and it seems like S3C6410 (at least according to the documentation) supports far more pixel formats than defined in the driver. Both preview and scaler paths are supposed to support 420/422 planar, 422 interleaved and 565/666/888 formats. Indeed, somehow I missed that s3c64xx supports most of the pixel formats on both: the preview and the codec data paths. I've updated the pixel format definitions to reflect that, but it still needs to be verified with proper tests. I just didn't add YUV422 packed format, I expect it to be done by someone who actually verifies that it works, after checking/updating camif-regs.c as well. Also two distinct planar 420 formats exist that simply differ by plane order YUV420 (currently supported in your driver) and YVU420 (with Cb and Cr planes swapped). It should be pretty straightforward to add support for the latter. Yeah, thanks for the suggestion. I've added support for YVU420 - it yields more options where setting up gstreamer pipelines, along with a few fixes for issues I've found after some more testing, including LKM build. It can be pulled from following git tree: git://linuxtv.org/snawrocki/media.git s3c-camif-devel It's based off of staging/for_v3.7 branch (3.6-rc3). I consider it more or less stable. The final branch for mainline is 's3c-camif', the difference is only that the fixes were squashed to a single commit adding the whole driver there. -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to add support for the em2765 webcam Speedlink VAD Laplace to the kernel ?
Sorry for the delayed reply, I got distracted by something with higher
prority.
Am 22.08.2012 20:15, schrieb Mauro Carvalho Chehab:
Em 22-08-2012 04:53, Frank Schäfer escreveu:
Am 21.08.2012 19:29, schrieb Mauro Carvalho Chehab:
Hmm... before reading the rest of this email... I found some doc saying that
em2765 is UVC compliant. Doesn't the uvcdriver work with this device?
Yeah, I stumbled over that, too. :D
But this device is definitely not UVC compliant. Take a look at the
lsusb output.
Maybe they are using a different firmware or something like that, but I
have no idea why the hell they should make a UVC compliant device
non-UVC-compliant...
Another notable difference to the devices we've seen so far is the
em25xx-style EEPROM. Maybe there is a connection.
Btw, do we know any em25xx devices ???
No, I never heard about em25xx. It seems that there are some new em275xx
chips, but I don't have any technical data.
Maybe they changed the name and there was never a em2580/em2585.
But I assume this is an older chip design.
...
[snip]
Anyway, I'm referring to how communication works on the USB level.
Take a look at http://linuxtv.org/wiki/index.php/VAD_Laplace section
Reverse Engineering (evaluation of USB-logs) to see how it is working.
Ok. From your logs, it seems that em2765 uses a different bus for
sensor communication. It is not unusual to have more than one bus on
some modern devices (cx231xx has 3 I2C buses, plus one extra bus that
can be switched).
Yes, but I'm wondering why.
Shouldn't it be possible to connect both (sensor and eeprom) to the same
bus ? Or are i2c and sccb devices incompatible ?
We've seen so many em28xx devices (some of them beeing much more
complex) and none of them has used two busses so far.
Strange...
Most devices nowadays have 2 i2c buses. TV boards typically uses an
I2C switch on them. The rationale is to avoid receiving signal
interference. Some newer em28xx devices have more than one bus, although,
on TV chipsets, this is controlled via one register, that commands
bus switch:
/* em28xx I2C Clock Register (0x06) */
#define EM2874_I2C_SECONDARY_BUS_SELECT 0x04 /* em2874 has two i2c
busses */
On those devices (em2874/em2875, afaikt), hardware manufacturers put
the TV tuner and demod at the second bus, keeping the first bus
for remote controller and eeprom.
Ok, I didn't notice that there a two i2c busses.
I wouldn't wonder if the em2765 doesn't support this bus switch and
that's why different USB reads/writes are used instead.
Shouldn't be too difficult to find out...
Perhaps it accepts both ways. IMHO, a separate req for the other bus is
better than needing to change a register for every single read/write
(If my memories are not betraying me, from some USB logs, I remind I
saw that kind of thing: for every single I2C operation, it first sets the
bus, and then reads/writes - even when the previous operation were at
the same bus).
Well, you may try to change register 6 to use the secondary bus and see
if the standard I2C code will work there for the sensor.
A quick test failed.
I enabled EM2874_I2C_SECONDARY_BUS_SELECT and tried to read from the
sensor (and other slave addresses).
It seems reading from the bus then works for ALL slave addresses but all
data bytes are 0x00.
You'll see several supported devices using the secondary bus for TV and
demod. As, currently, the TV eeprom is not read on those devices, nobody
cared enough to add a separate I2C bus code for it, as all access used
by the driver happen just on the second bus.
Well, the same applies to this webcam. We do not really need to read the
EEPROM at the moment.
A proper mapping for it to use ov2640 driver is to create two i2c
buses, one used by eeprom access, and another one for sensor.
Sure.
Interestingly, the standard I2C reads are used, too, for reading the
EEPROM. So maybe there is a physical difference.
Proprietary is probably not the best name, but I don't have e better
one at the moment (suggestions ?).
It is just another bus: instead of using req 3/4 for read/write, it uses
req 6 for both reads/writes at the i2c-like sensor bus.
- uses 16bit eeprom
- em25xx-eeprom with different layout
There are other supported chips with 16bit eeproms. Currently,
support for 16bit eeproms is disabled just because this weren't
needed so far, but I'm sure this is a need there.
Yes, I've read the comment in em28xx_i2c_eeprom():
...there is the risk that we could corrupt the eeprom (since a 16-bit
read call is interpreted as a write call by 8-bit eeproms)...
How can we know if a device uses an 8bit or 16bit EEPROM ? Can we derive
that from the uses em27xx/28xx-chip ?
I don't know any other way to check it than to read the chip ID, at
register
0x0a. Those are the chip ID's that we currently know:
enum em28xx_chip_id {
CHIP_ID_EM2800 = 7,
CHIP_ID_EM2710 = 17,
CHIP_ID_EM2820 = 18,/* Also used by some em2710 */
Re: [PATCH RFC 1/4] V4L: Add V4L2_CID_FRAMESIZE image source class control
Hi Sakari, On 08/25/2012 12:51 AM, Sakari Ailus wrote: --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -727,6 +727,7 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_VBLANK: return Vertical Blanking; case V4L2_CID_HBLANK: return Horizontal Blanking; case V4L2_CID_ANALOGUE_GAIN:return Analogue Gain; + case V4L2_CID_FRAMESIZE:return Maximum Frame Size; I would put this to the image processing class, as the control isn't related to image capture. Jpeg encoding (or image compression in general) after all is related to image processing rather than capturing it. All right, might make more sense that way. Let me move it to the image processing class then. It probably also makes sense to name it V4L2_CID_FRAME_SIZE, rather than V4L2_CID_FRAMESIZE. Hmm. While we're at it, as the size is maximum --- it can be lower --- how about V4L2_CID_MAX_FRAME_SIZE or V4L2_CID_MAX_FRAME_SAMPLES, as the unit is samples? Does sample in this context mean pixels for uncompressed formats and bytes (octets) for compressed formats? It's important to define it as we're also using the term sample to refer to data units transferred over a parallel bus per a clock cycle. I agree with Sakari here, I find the documentation quite vague, I wouldn't understand what the control is meant for from the documentation only. I thought it was clear enough: Maximum size of a data frame in media bus sample units. ^ Oops. I somehow managed to miss that. My mistake. So that means the unit is a number of bits clocked by a single clock pulse on parallel video bus... :) But how is media bus sample defined in case of CSI bus ? Looks like media bus sample is a useless term for our purpose. The CSI2 transmitters and receivers, as far as I understand, want to know a lot more about the data that I think would be necessary. This doesn't only involve the bits per sample (e.g. pixel for raw bayer formats) but some information on the media bus code, too. I.e. if you're transferring 11 bit pixels the bus has to know that. I think it would have been better to use different media bus codes for serial busses than on parallel busses that transfer the sample on a single clock cycle. But that's out of the scope of this patch. In respect to this the CCP2 AFAIR works mostly the same way. I thought it was better than just 8-bit byte, because the data receiver (bridge) could layout data received from video bus in various ways in memory, e.g. add some padding. OTOH, would any padding make sense for compressed streams ? It would break the content, wouldn't it ? I guess it't break if the padding is applied anywhere else than the end, where I hope it's ok. I'm not that familiar with compressed formats, though. The hardware typically has limitations on the DMA transaction width and that can easily be e.g. 32 or 64 bytes, so some padding may easily be introduced at the end of the compressed image. The padding at the frame end is not a problem, since it would be a property of a bridge. So the reported sizeimage value with VIDIOC_G_FMT, for example, could be easily adjusted a a bridge driver to account any padding. So I would propose to use 8-bit byte as a unit for this control and name it V4L2_CID_MAX_FRAME_SIZE. All in all it's not really tied to the media bus. It took me quite a while toe remember what the control really was for. ;) :-) Yeah, looks like I have been going in circles with this issue.. ;) How about using bytes on video nodes and bus and media bus code specific extended samples (or how we should call pixels in uncompressed formats and units of data in compressed formats?) on subdevs? The information how the former is derived from the latter resides in the driver controlling the DMA anyway. As you proposed originally, this control is more relevant to subdevs so we could also not define it for video nodes at all. Especially if the control isn't needed: the information should be available from VIDIOC_TRY_FMT. Yeah, I seem to have forgotten to add a note that this control would be valid only on subdev nodes :/ OTOH, how do we handle cases where subdev's controls are inherited by a video node ? Referring to an media bus pixel code seems wrong in that cases. Also for compressed formats, where this control is only needed, the bus receivers/DMA just do transparent transfers, without actually modifying the data stream. The problem is that ideally this V4L2_CID_FRAMESIZE control shouldn't be exposed to user space. It might be useful, for example for checking what would be resulting file size on a subdev modelling a JPEG encoder, etc. I agree on video nodes ioctls like VIDIOC_[S/G/TRY]_FMT are just sufficient for retrieving that information. -- Regards, Sylwester -- To
Terratec H7 aka az6007 with CI
Hello! Just a reminder that az6007 with CI still isn't working 100% with Kaffeine. But since I use my device with MythTV that uses the same usage pattern as my workaround for Kaffeine it works like a charm. The pattern are: * Open up device / Start Kaffeine * Tune to encrypted channel / Choose channel in Kaffeine * Close Device / Close Kaffeine * Open device / Start Kaffeine * Watch channel The exact procedure that MythTV uses when tuning to a channel. Not exactly sure if this is a driver bug or a Kaffeine bug since I'm just a user. The normal way that do not work in Kaffeine are: * Start Kaffeine * Tune to an encrypted channel * If that works tune to another encrypted channel which will not work. Since it is working with my main application I'm satisfied but look at this as a formal bug report. If you need any help or testing I'm willing to help time permitting. I know that some of you doing the actual work doesn't have access to a CAM but if you need debugging information or any output just notify me directly. I'm am running a relativly new media_build. Haven't been able to test the latest media_build since it is stopping on a compile error. (As of 25 of August 2012) Thanks again for the hard work with the driver (Mauro for the inclusion and Jose for the CI. Hopefully I got the names right). It is much appreciated by me and my better half. -- 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:Sun Aug 26 19:00:20 CEST 2012 git hash:79e8c7bebb467bbc3f2514d75bba669a3f354324 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Core + Radio profile
Hi Hans, On Sat, 2012-08-25 at 09:21 +0200, Hans Verkuil wrote: On Sat August 25 2012 02:37:15 Andy Walls wrote: On Wed, 2012-08-22 at 11:40 +0200, Hans Verkuil wrote: This RFC is my attempt to start this process by describing three profiles: the core profile that all drivers must adhere to, a profile for a radio receiver and a profile for a radio transmitter. I was thinking that profiles based on applications types might be more useful, but then I saw that applications were basically already handling different device types differently. So prfoiles for hardware device types seems the reasonable choice. MythTV seems to care about 4 classes of device http://www.mythtv.org/wiki/Video_capture_card Analog Framebuffer Analog Hardware Encoder Digital Capture Digital Tuner VLC seems to be similar to MythTV in terms of classes: http://www.videolan.org/doc/streaming-howto/en/images/global-diagram.jpg I suppose there would also be profiles to support device classes for: webcams webcams that provide video in a container format (AVI, MJPEG, whatever) integrated cameras (I'm thinking smart-phones, but I'm out of my depth here) Looking at the current set of V4L drivers I come up with the following profiles: - Core Profile (mandatory for all) - Radio Receiver Profile (with optional RDS support (sub-profile?)) I would avoid the use of the word optional in a profile. I would imagine the profile would say something like: If the device and driver support RDS, then applications can determine this by [some method consistent with the V4L2 spec] and the driver will implement the following ioctl()s: [...]; and provide data in the following manner: [...] So nothing is really optional, if the device and driver can support RDS. That way you also don't get a proliferation of profiles - Radio Receiver with RDS and also Radio Receiver w/o RDS - or subprofiles. (As a group, numerous profiles begin to create the option inconsistency problem all over again.) Again, I'm coming from the viewpoint that every option holds potential for an application - driver interoperability problem. Profiles need to set clear expectations for both applications and driver. Stating that something is optional in a profile is undersireable, IMO. - Radio Transmitter Profile (with optional RDS support) - Webcam Profile - Video Capture Profile (with optional tuner/overlay/vbi support) - Video Output Profile (with optional vbi support) Ditto, regarding optional. - Memory-to-Memory Profile (for hardware codecs) - Complex Profile (for SoCs with complex video hardware requiring the use of the Media Controller API and a supporting library) I wonder if e.g. optional tuner support and similar optional features should be defined as full profiles or as sub-profiles. I would suggest you avoid a proliferation of profiles. Fewer profiles go farther in enhancing application - driver inetroperability. I like your list above. Using your example of tuner support, you would include that in the Video Capture Profile. The language I would use is again something like: If the device has a supported analog broadcast TV tuner, then applications can detect this by [some method consistent with the V4L2 spec], and the following ioctl()s must be supported: [...]. In theory it is possible to have, say, a device that just captures VBI and no video. So there is something to be said for making it a full profile and allow drivers to support multiple profiles (although not all combinations are allowed). IMO, Combinations of profiles, just creates uncertainty and thus interoperability problems. My first inclination would be to just handle a VBI-only capture device under the Video Capture profile, with a properly worded profile. There is probably a similar situation with Video Capture devices that output raw frames vs. video capture devices that output conatiner formats (MPEG PS, MPEG TS, AVI). I think that can be handled in a single Video Capture profile as well. I am not certain where these profile descriptions should go. Should we add this to DocBook, or describe it in Documentation/video4linux? Or perhaps somehow add it to v4l2-compliance, since that tool effectively verifies the profile. Don't bury the authoritative profile in a tool, profiles should be documents easily accessed by implementors. Interoperability is promoted via clearly documentation requirments for implementors. Interoperability is assessed with tools. I would like to temper my above statements. Given the reality of man-power to write documents for Open Source software, my above recommendations might not be realistic. I've been living in a big, up-front design world lately. Also Steven Toth's Viewcast Osprey PULL request has shown how a good tool can help speed compliance after the fact. (Although good profile documents may have prevented the back
[PATCH] v2 Add support to Avermedia Twinstar double tuner in af9035
This patch add support to the Avermedia Twinstar double tuner in the af9035
driver. Version 2 of the patch with suggestions of Antti.
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Jose Alberto
diff -upr linux/drivers/media/dvb-frontends/af9033.c
linux.new/drivers/media/dvb-frontends/af9033.c
--- linux/drivers/media/dvb-frontends/af9033.c 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/dvb-frontends/af9033.c 2012-08-26
23:38:10.527070150 +0200
@@ -51,6 +51,8 @@ static int af9033_wr_regs(struct af9033_
};
buf[0] = (reg 16) 0xff;
+ if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL)
+ buf[0] |= 0x10;
buf[1] = (reg 8) 0xff;
buf[2] = (reg 0) 0xff;
memcpy(buf[3], val, len);
@@ -87,6 +89,9 @@ static int af9033_rd_regs(struct af9033_
}
};
+ if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL)
+ buf[0] |= 0x10;
+
ret = i2c_transfer(state-i2c, msg, 2);
if (ret == 2) {
ret = 0;
@@ -325,6 +330,18 @@ static int af9033_init(struct dvb_fronte
if (ret 0)
goto err;
}
+
+ if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL) {
+ ret = af9033_wr_reg_mask(state, 0x00d91c, 0x01, 0x01);
+ if (ret 0)
+ goto err;
+ ret = af9033_wr_reg_mask(state, 0x00d917, 0x00, 0x01);
+ if (ret 0)
+ goto err;
+ ret = af9033_wr_reg_mask(state, 0x00d916, 0x00, 0x01);
+ if (ret 0)
+ goto err;
+ }
state-bandwidth_hz = 0; /* force to program all parameters */
diff -upr linux/drivers/media/tuners/mxl5007t.c
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.c 2012-08-25 19:36:44.689924518
+0200
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, cfg-invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
- set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable 3);
set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
@@ -531,9 +530,11 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
- ret = mxl5007t_soft_reset(state);
- if (mxl_fail(ret))
- goto fail;
+ if (!state-config-no_reset) {
+ ret = mxl5007t_soft_reset(state);
+ if (mxl_fail(ret))
+ goto fail;
+ }
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +888,10 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
- ret = mxl5007t_get_chip_id(state);
+ if (!state-config-no_probe)
+ ret = mxl5007t_get_chip_id(state);
+
+ ret = mxl5007t_write_reg(state, 0x04,
state-config-loop_thru_enable);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.h 2012-08-25 19:38:19.990920623
+0200
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
enum mxl5007t_if_freq if_freq_hz;
unsigned int invert_if:1;
- unsigned int loop_thru_enable:1;
+ unsigned int loop_thru_enable:2;
unsigned int clk_out_enable:1;
+ unsigned int no_probe:1;
+ unsigned int no_reset:1;
};
#if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
(defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE) defined(MODULE))
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2012-08-16 05:45:24.0
+0200
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2012-08-26
23:46:10.702070148 +0200
@@ -209,7 +209,8 @@ static int af9035_i2c_master_xfer(struct
if (msg[0].len 40 || msg[1].len 40) {
/* TODO: correct limits 40 */
ret = -EOPNOTSUPP;
- } else if (msg[0].addr == state-af9033_config[0].i2c_addr) {
+ } else if ((msg[0].addr == state-af9033_config[0].i2c_addr) ||
+ (msg[0].addr == state-af9033_config[1].i2c_addr)) {
/* integrated demod */
u32 reg = msg[0].buf[0] 16 | msg[0].buf[1] 8 |
patch idea
If the driver is built into kernel it causes a timeout because it relies on udev which is not initialized yet (that is the theory). Regardless, the timeout is not needed except to load the firmware to provide analog reception. I doubt anyone who compiles it in the kernel needs the firmware. I think the following should make it into the kernel source: drivers/media/video/cx25840/cx25840-core.c #ifdef MODULE cx25840_loadfw(state-c); #endif -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Core + Radio profile
On Fri, 2012-08-24 at 14:31 +0200, Hans Verkuil wrote: Hi Mauro, Thanks for your review! On Wed August 22 2012 15:42:26 Mauro Carvalho Chehab wrote: Em 22-08-2012 07:11, Hans Verkuil escreveu: Also note that the core profile description is more strict than the spec. IMO, that's the right approach: The specs should define the several API aspects; the profile should mandate what's optional and what's mandatory. For example, G/S_PRIORITY are currently optional, After putting the profiles there, we should remove optional tags elsewhere, as the profiles section will tell what's mandatory and what is optional, as different profiles require different mandatory arguments. but I feel that all new drivers should implement this, especially since it is very easy to add provided you use struct v4l2_fh. I agree on making G/S_PRIORITY mandatory. Note that these profiles are primarily meant for driver developers. The V4L2 specification is leading for application developers. This is where we diverge ;) We need profiles primary for application developers, for them to know what is expected to be there on any media driver of a certain kind. +1 Ok, internal driver-developer profiles is also needed, in order for them to use the right internal API's and internal core functions. Well, it is all very nice to just say e.g. 'G/S_PRIORITY is mandatory' in the profile section, but the reality is that it is hit and miss whether or not it is implemented. Even if we manage to convert all drivers to implement G/S_PRIO, then it is still not something an app developer can rely on because many users use older kernel versions. A profile should either a. make no statement about G/S_PRIORITY, b. should make them mandatory, or c. should state explicitly they should not be implemented. The V4L2 spec already implies they are optional: ... V4L2 defines the VIDIOC_G_PRIORITY and VIDIOC_S_PRIORITY ioctls to request and query the access priority associate with a file descriptor. Opening a device assigns a medium priority, compatible with earlier versions of V4L2 and drivers not supporting these ioctls. ^^^ If the profile make them mandatory, legacy driver non-compliance with this should be reported. Better still, a driver should not be claimed to be profile compliant until the non-compliance is fixed. We are not going to have the drivers compliant with profiles all at once. In the long view, applications evolve too. As drivers move to comply with profiles, and old kernel versions are dropped from main stream distros, application writers can get rid of complex code to handle V4L2 quirks and exceptions. Which is why IMHO the spec should be leading for app development. The profile sections are a handy summary of what you can expect from drivers for specific types of hardware, but it can't be leading except when it comes to new driver development or driver changes in areas covered by the profile(s). I disagree here. I guess that is obvious by now. ;) Note: There are a few drivers that use a radio (pvrusb2) or video (ivtv) node to stream the audio. These are legacy exceptions to the rule. What an application developer should do with that??? Nothing. A generic application cannot support audio for these devices. You need specialized apps for that. If this should not be supported anymore, then we need instead to either fix the drivers that aren't compliant with the specs or move them to staging, in order to let them to be either fixed or dropped, if none cares enough to fix. Well, the problem is that people are actually using the existing, nonstandard, APIs for ivtv (and probably pvrusb2 as well). Please note that the profile need not prohibit the legacy radio audio API. That way the legacy drivers can be compliant with the profile without removing existing functionality. It will be sufficient for the profile to require all drivers to implement the ALSA interface. No sane person is going to work to inplement the legacy oddball audio interface in a driver after the ALSA interface is done. For ivtv it is probably not too difficult to add ALSA support. Andy, I know you implemented ALSA support for cx18, do you know how much work it would be to do the same for ivtv? I implemented the cx18-alsa-* skeleton; DEvin actually got it hooked up to ALSA and working. There are still some aspects of it that are dead code - i.e. the ALSA controls for volume - even though the skeleton has them. If Andy has absolutely no time, then I can try to find time to add ALSA support to ivtv. But the existing API should probably remain (if possible). The cx18-alsa-* code and glue is certainly copyable to ivtv. I might suggest one difference: don't make ivtv-alsa it's own module. Just build it in to the ivtv driver and reduce some module-glue complexity. ALSA
