Re: [PATCH v3 1/3] fbdev: Add FOURCC-based format configuration API
Hi Florian,
On Sunday 20 November 2011 03:00:33 Florian Tobias Schandinat wrote:
Hi Laurent,
On 08/31/2011 11:18 AM, Laurent Pinchart wrote:
This API will be used to support YUV frame buffer formats in a standard
way.
looks like the union is causing problems. With this patch applied I get
errors like this:
CC [M] drivers/auxdisplay/cfag12864bfb.o
drivers/auxdisplay/cfag12864bfb.c:57: error: unknown field ‘red’ specified
in initializer
*ouch*
gcc 4.6 chokes on anonymous unions initializers :-/
[snip]
@@ -246,12 +251,23 @@ struct fb_var_screeninfo {
__u32 yoffset; /* resolution */
__u32 bits_per_pixel; /* guess what */
- __u32 grayscale;/* != 0 Graylevels instead of colors */
- struct fb_bitfield red; /* bitfield in fb mem if true color, */
- struct fb_bitfield green; /* else only length is significant */
- struct fb_bitfield blue;
- struct fb_bitfield transp; /* transparency */
+ union {
+ struct {/* Legacy format API*/
+ __u32 grayscale; /* 0 = color, 1 = grayscale*/
+ /* bitfields in fb mem if true color, else only */
+ /* length is significant*/
+ struct fb_bitfield red;
+ struct fb_bitfield green;
+ struct fb_bitfield blue;
+ struct fb_bitfield transp; /* transparency */
+ };
+ struct {/* FOURCC-based format API */
+ __u32 fourcc; /* FOURCC format*/
+ __u32 colorspace;
+ __u32 reserved[11];
+ } fourcc;
+ };
We can't name the union, otherwise this will change the userspace API.
We could fix the problem on the kernel side with
#ifdef __KERNEL__
} color;
#else
};
#endif
That's quite hackish though... What's your opinion ?
It would also not handle userspace code that initializes an fb_var_screeninfo
structure with named initializers, but that shouldn't happen, as application
should read fb_var_screeninfo , modify it and write it back.
__u32 nonstd; /* != 0 Non standard pixel format */
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] initial support for HAUPPAUGE HVR-930C again...
Em 19-11-2011 13:37, Eddi De Pieri escreveu: With this patch I try again to add initial support for HVR930C. Tested only DVB-T, since in Italy Analog service is stopped. Actually scan -a0 -f1, find only about 50 channel while 400 should be available. Signed-off-by: Eddi De Pieri e...@depieri.net Tested here with DVB-C, using the Terratec firmware. It worked as expected: 213 channels scanned, tested a few non-encrypted ones, and it seems to be working as expected. It didn't work with the firmware used by ddbrigde driver (the one that get_dvb_firmware script is capable of retrieving). Regards Eddi -- 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: Leadtek PxDVR3200H and mythbuntu 11.04/11.10
On 11/20/2011 02:30 AM, john wrote: I have tried downloading clean v4l repositories and trying to patch for xc4000 but I can't get it to compile. XC4000 support is included in the V4L repositories starting from staging/for_v3.1, if you have recent sources, then no patching is needed. As well, I'm in Australia so I need the 7MHz version particular to our transmission type. The driver does support 7 MHz bandwidth. You need a firmware file for XC4000, I have attached it in case it is not included yet with the V4L sources. Note that the firmware available at kernellabs.com is not compatible with the driver in the V4L repositories. dvb-fe-xc4000-1.4.fw Description: Binary data
[PATCH 1/8] [media] dvb: Allow select between DVB-C Annex A and Annex C
DVB-C, as defined by ITU-T J.83 has 3 annexes. The differences between
Annex A and Annex C is that Annex C uses a subset of the modulation
types, and uses a different rolloff factor. A different rolloff means
that the bandwidth required is slicely different, and may affect the
saw filter configuration at the tuners. Also, some demods have different
configurations, depending on using Annex A or Annex C.
So, allow userspace to specify it, by changing the rolloff factor.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
Documentation/DocBook/media/dvb/dvbproperty.xml |4
drivers/media/dvb/dvb-core/dvb_frontend.c |2 ++
include/linux/dvb/frontend.h|2 ++
3 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 3bc8a61..6ac8039 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -311,6 +311,8 @@ typedef enum fe_rolloff {
ROLLOFF_20,
ROLLOFF_25,
ROLLOFF_AUTO,
+ ROLLOFF_15, /* DVB-C Annex A */
+ ROLLOFF_13, /* DVB-C Annex C */
} fe_rolloff_t;
/programlisting
/section
@@ -778,8 +780,10 @@ typedef enum fe_hierarchy {
listitemparalink
linkend=DTV-MODULATIONconstantDTV_MODULATION/constant/link/para/listitem
listitemparalink
linkend=DTV-INVERSIONconstantDTV_INVERSION/constant/link/para/listitem
listitemparalink
linkend=DTV-SYMBOL-RATEconstantDTV_SYMBOL_RATE/constant/link/para/listitem
+ listitemparalink
linkend=DTV-ROLLOFFconstantDTV_ROLLOFF/constant/link/para/listitem
listitemparalink
linkend=DTV-INNER-FECconstantDTV_INNER_FEC/constant/link/para/listitem
/itemizedlist
+ paraThe Rolloff of 0.15 (ROLLOFF_15) is assumed, as ITU-T
J.83 Annex A is more common. For Annex C, rolloff should be 0.13 (ROLLOFF_13).
All other values are invalid./para
/section
section id=dvbc-annex-b-params
titleDVB-C Annex B delivery system/title
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 2c0acdb..c849455 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -876,6 +876,7 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
c-symbol_rate = QAM_AUTO;
c-code_rate_HP = FEC_AUTO;
c-code_rate_LP = FEC_AUTO;
+ c-rolloff = ROLLOFF_AUTO;
c-isdbt_partial_reception = -1;
c-isdbt_sb_mode = -1;
@@ -1030,6 +1031,7 @@ static void dtv_property_cache_init(struct dvb_frontend
*fe,
break;
case FE_QAM:
c-delivery_system = SYS_DVBC_ANNEX_AC;
+ c-rolloff = ROLLOFF_15; /* implied for Annex A */
break;
case FE_OFDM:
c-delivery_system = SYS_DVBT;
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 1b1094c..d9251df 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -329,6 +329,8 @@ typedef enum fe_rolloff {
ROLLOFF_20,
ROLLOFF_25,
ROLLOFF_AUTO,
+ ROLLOFF_15, /* DVB-C Annex A */
+ ROLLOFF_13, /* DVB-C Annex C */
} fe_rolloff_t;
typedef enum fe_delivery_system {
--
1.7.7.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 2/8] [media] Properly implement ITU-T J.88 Annex C support
The Annex C support were broken with the previous implementation,
as, at xc5000 and tda18271c2dd, it were choosing the wrong bandwidth
for some symbol rates.
At DRX-J, it were always selecting Annex A, even having Annex C
support coded there.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/xc5000.c | 26 +++---
drivers/media/dvb/frontends/drxk_hard.c|7 ++
drivers/media/dvb/frontends/tda18271c2dd.c | 32 ++-
3 files changed, 37 insertions(+), 28 deletions(-)
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index aa1b2e8..88b329c 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -628,20 +628,12 @@ static void xc_debug_dump(struct xc5000_priv *priv)
dprintk(1, *** Quality (0:8dB, 7:56dB) = %d\n, quality);
}
-/*
- * As defined on EN 300 429, the DVB-C roll-off factor is 0.15.
- * So, the amount of the needed bandwith is given by:
- * Bw = Symbol_rate * (1 + 0.15)
- * As such, the maximum symbol rate supported by 6 MHz is given by:
- * max_symbol_rate = 6 MHz / 1.15 = 5217391 Bauds
- */
-#define MAX_SYMBOL_RATE_6MHz 5217391
-
static int xc5000_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
struct xc5000_priv *priv = fe-tuner_priv;
int ret;
+ u32 bw;
if (xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
if (xc_load_fw_and_init_tuner(fe) != XC_RESULT_SUCCESS) {
@@ -707,11 +699,19 @@ static int xc5000_set_params(struct dvb_frontend *fe,
dprintk(1, %s() QAM modulation\n, __func__);
priv-rf_mode = XC_RF_MODE_CABLE;
/*
-* Using a 8MHz bandwidth sometimes fail
-* with 6MHz-spaced channels, due to inter-carrier
-* interference. So, use DTV6 firmware
+* Using a higher bandwidth at the tuner filter may
+* allow inter-carrier interference.
+* So, determine the minimal channel spacing, in order
+* to better adjust the tuner filter.
+* According with ITU-T J.83, the bandwidth is given by:
+* bw = Simbol Rate * (1 + roll_off), where the roll_off
+* is equal to 0.15 for Annex A, and 0.13 for annex C
*/
- if (params-u.qam.symbol_rate = MAX_SYMBOL_RATE_6MHz) {
+ if (fe-dtv_property_cache.rolloff == ROLLOFF_13)
+ bw = (params-u.qam.symbol_rate * 13) / 10;
+ else
+ bw = (params-u.qam.symbol_rate * 15) / 10;
+ if (bw = 600) {
priv-bandwidth = BANDWIDTH_6_MHZ;
priv-video_standard = DTV6;
priv-freq_hz = params-frequency - 175;
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index f6431ef..dc13fd8 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -6218,6 +6218,13 @@ static int drxk_set_parameters(struct dvb_frontend *fe,
return -EINVAL;
}
+ if (state-m_OperationMode == OM_QAM_ITU_A ||
+ state-m_OperationMode == OM_QAM_ITU_C) {
+ if (fe-dtv_property_cache.rolloff == ROLLOFF_13)
+ state-m_OperationMode = OM_QAM_ITU_C;
+ else
+ state-m_OperationMode = OM_QAM_ITU_A;
+ }
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
diff --git a/drivers/media/dvb/frontends/tda18271c2dd.c
b/drivers/media/dvb/frontends/tda18271c2dd.c
index 1b1bf20..de544f6 100644
--- a/drivers/media/dvb/frontends/tda18271c2dd.c
+++ b/drivers/media/dvb/frontends/tda18271c2dd.c
@@ -1123,20 +1123,6 @@ static int release(struct dvb_frontend *fe)
return 0;
}
-/*
- * As defined on EN 300 429 Annex A and on ITU-T J.83 annex A, the DVB-C
- * roll-off factor is 0.15.
- * According with the specs, the amount of the needed bandwith is given by:
- * Bw = Symbol_rate * (1 + 0.15)
- * As such, the maximum symbol rate supported by 6 MHz is
- * max_symbol_rate = 6 MHz / 1.15 = 5217391 Bauds
- *NOTE: For ITU-T J.83 Annex C, the roll-off factor is 0.13. So:
- * max_symbol_rate = 6 MHz / 1.13 = 5309735 Baud
- * That means that an adjustment is needed for Japan,
- * but, as currently DRX-K is hardcoded to Annex A, let's stick
- * with 0.15 roll-off factor.
- */
-#define MAX_SYMBOL_RATE_6MHz 5217391
static int set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
@@ -1144,6
[PATCH 3/8] [media] em28xx: Fix some Terratec entries (H5 and XS)
As reported by Andreas Oberritter o...@linuxtv.org, changeset
33ba28eebc3e1758e6adc1fcec9e1e3151bac453 did the wrong thing.
Fix it to properly reflect the entries for Terratec H5 revs 1 and 2,
and restore Terratec XS entry.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
Documentation/video4linux/CARDLIST.em28xx |6 +++---
drivers/media/video/em28xx/em28xx-cards.c |6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/video4linux/CARDLIST.em28xx
b/Documentation/video4linux/CARDLIST.em28xx
index d8c8544..7734b2c 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -11,7 +11,7 @@
10 - Hauppauge WinTV HVR 900 (em2880)[2040:6500]
11 - Terratec Hybrid XS (em2880)
12 - Kworld PVR TV 2800 RF(em2820/em2840)
- 13 - Terratec Prodigy XS (em2880)[0ccd:10ad]
+ 13 - Terratec Prodigy XS (em2880)
14 - SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 (em2820/em2840)
15 - V-Gear PocketTV (em2800)
16 - Hauppauge WinTV HVR 950 (em2883)
[2040:6513,2040:6517,2040:651b]
@@ -41,7 +41,7 @@
40 - Plextor ConvertX PX-TV100U (em2861)[093b:a005]
41 - Kworld 350 U DVB-T (em2870)[eb1a:e350]
42 - Kworld 355 U DVB-T (em2870)
[eb1a:e355,eb1a:e357]
- 43 - Terratec Cinergy T XS(em2870)
+ 43 - Terratec Cinergy T XS(em2870)[0ccd:0043]
44 - Terratec Cinergy T XS (MT2060) (em2870)
45 - Pinnacle PCTV DVB-T (em2870)
46 - Compro, VideoMate U3 (em2870)[185b:2870]
@@ -76,5 +76,5 @@
76 - KWorld PlusTV 340U or UB435-Q (ATSC) (em2870)[1b80:a340]
77 - EM2874 Leadership ISDBT (em2874)
78 - PCTV nanoStick T2 290e (em28174)
- 79 - Terratec Cinergy H5 (em2884)
[0ccd:0043,0ccd:10a2]
+ 79 - Terratec Cinergy H5 (em2884)
[0ccd:10a2,0ccd:10ad]
80 - PCTV DVB-S2 Stick (460e) (em28174)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 9b747c2..19a5be3 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -1914,11 +1914,11 @@ struct usb_device_id em28xx_id_table[] = {
{ USB_DEVICE(0x0ccd, 0x0042),
.driver_info = EM2882_BOARD_TERRATEC_HYBRID_XS },
{ USB_DEVICE(0x0ccd, 0x0043),
+ .driver_info = EM2870_BOARD_TERRATEC_XS },
+ { USB_DEVICE(0x0ccd, 0x10a2), /* H5 Rev. 1 */
.driver_info = EM2884_BOARD_TERRATEC_H5 },
- { USB_DEVICE(0x0ccd, 0x10a2), /* Rev. 1 */
+ { USB_DEVICE(0x0ccd, 0x10ad), /* H5 Rev. 2 */
.driver_info = EM2884_BOARD_TERRATEC_H5 },
- { USB_DEVICE(0x0ccd, 0x10ad), /* Rev. 2 */
- .driver_info = EM2880_BOARD_TERRATEC_PRODIGY_XS },
{ USB_DEVICE(0x0ccd, 0x0084),
.driver_info = EM2860_BOARD_TERRATEC_AV350 },
{ USB_DEVICE(0x0ccd, 0x0096),
--
1.7.7.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 7/8] [media] em28xx: Add IR support for em2884
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/video/em28xx/em28xx-input.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/em28xx/em28xx-input.c b/drivers/media/video/em28xx/em28xx-input.c index 679da48..2630b26 100644 --- a/drivers/media/video/em28xx/em28xx-input.c +++ b/drivers/media/video/em28xx/em28xx-input.c @@ -306,7 +306,8 @@ static void em28xx_ir_handle_key(struct em28xx_IR *ir) poll_result.rc_data[0], poll_result.toggle_bit); - if (ir-dev-chip_id == CHIP_ID_EM2874) + if (ir-dev-chip_id == CHIP_ID_EM2874 || + ir-dev-chip_id == CHIP_ID_EM2884) /* The em2874 clears the readcount field every time the register is read. The em2860/2880 datasheet says that it is supposed to clear the readcount, but it doesn't. So with @@ -371,13 +372,15 @@ int em28xx_ir_change_protocol(struct rc_dev *rc_dev, u64 rc_type) case CHIP_ID_EM2883: ir-get_key = default_polling_getkey; break; + case CHIP_ID_EM2884: case CHIP_ID_EM2874: case CHIP_ID_EM28174: ir-get_key = em2874_polling_getkey; em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, ir_config, 1); break; default: - printk(Unrecognized em28xx chip id: IR not supported\n); + printk(Unrecognized em28xx chip id 0x%02x: IR not supported\n, + dev-chip_id); rc = -EINVAL; } -- 1.7.7.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 6/8] [media] em28xx: Fix CodingStyle issues introduced by changeset 82e7dbb
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/drxk_hard.c |2 +-
drivers/media/video/em28xx/em28xx-cards.c | 17 +
drivers/media/video/em28xx/em28xx-dvb.c | 57 +++--
3 files changed, 32 insertions(+), 44 deletions(-)
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index 2392092..95cbc98 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -682,7 +682,7 @@ static int init_state(struct drxk_state *state)
state-m_hasAudio = false;
if (!state-m_ChunkSize)
- state-m_ChunkSize = 124;
+ state-m_ChunkSize = 124;
state-m_oscClockFreq = 0;
state-m_smartAntInverted = false;
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 705aedf..d92e0af 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -337,9 +337,8 @@ static struct em28xx_reg_seq pctv_460e[] = {
};
static struct em28xx_reg_seq hauppauge_930c_gpio[] = {
-// xc5000 reset
{EM2874_R80_GPIO, 0x6f, 0xff, 10},
- {EM2874_R80_GPIO, 0x4f, 0xff, 10},
+ {EM2874_R80_GPIO, 0x4f, 0xff, 10}, /* xc5000 reset */
{EM2874_R80_GPIO, 0x6f, 0xff, 10},
{EM2874_R80_GPIO, 0x4f, 0xff, 10},
{ -1, -1, -1, -1},
@@ -905,6 +904,8 @@ struct em28xx_board em28xx_boards[] = {
.tuner_addr = 0x41,
.dvb_gpio = terratec_h5_digital, /* FIXME: probably wrong */
.tuner_gpio = terratec_h5_gpio,
+#else
+ .tuner_type = TUNER_ABSENT,
#endif
.i2c_speed= EM2874_I2C_SECONDARY_BUS_SELECT |
EM28XX_I2C_CLK_WAIT_ENABLE |
@@ -913,12 +914,14 @@ struct em28xx_board em28xx_boards[] = {
[EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C] = {
.name = Hauppauge WinTV HVR 930C,
.has_dvb = 1,
-//#if 0
-// .tuner_type = TUNER_XC5000,
-// .tuner_addr = 0x41,
-// .dvb_gpio = hauppauge_930c_digital, /* FIXME: probably
wrong */
+#if 0 /* FIXME: Add analog support */
+ .tuner_type = TUNER_XC5000,
+ .tuner_addr = 0x41,
+ .dvb_gpio = hauppauge_930c_digital,
.tuner_gpio = hauppauge_930c_gpio,
-//#endif
+#else
+ .tuner_type = TUNER_ABSENT,
+#endif
.i2c_speed= EM2874_I2C_SECONDARY_BUS_SELECT |
EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c
b/drivers/media/video/em28xx/em28xx-dvb.c
index d19939b..55a9008 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -347,42 +347,27 @@ static void hauppauge_hvr930c_init(struct em28xx *dev)
int i;
struct em28xx_reg_seq hauppauge_hvr930c_init[] = {
- {EM2874_R80_GPIO, 0xff, 0xff, 101}, //
-// {0xd, 0xff, 0xff, 101}, //
- {EM2874_R80_GPIO, 0xfb, 0xff, 50}, //1011 init
bit 3
- {EM2874_R80_GPIO, 0xff, 0xff, 184}, //
+ {EM2874_R80_GPIO, 0xff, 0xff, 0x65},
+ {EM2874_R80_GPIO, 0xfb, 0xff, 0x32},
+ {EM2874_R80_GPIO, 0xff, 0xff, 0xb8},
{ -1, -1, -1, -1},
};
struct em28xx_reg_seq hauppauge_hvr930c_end[] = {
- {EM2874_R80_GPIO, 0xef, 0xff, 1},//1110
- {EM2874_R80_GPIO, 0xaf, 0xff, 101}, //1010 init
bit 7
- {EM2874_R80_GPIO, 0xef, 0xff, 118}, //1110
+ {EM2874_R80_GPIO, 0xef, 0xff, 0x01},
+ {EM2874_R80_GPIO, 0xaf, 0xff, 0x65},
+ {EM2874_R80_GPIO, 0xef, 0xff, 0x76},
+ {EM2874_R80_GPIO, 0xef, 0xff, 0x01},
+ {EM2874_R80_GPIO, 0xcf, 0xff, 0x0b},
+ {EM2874_R80_GPIO, 0xef, 0xff, 0x40},
+
+ {EM2874_R80_GPIO, 0xcf, 0xff, 0x65},
+ {EM2874_R80_GPIO, 0xef, 0xff, 0x65},
+ {EM2874_R80_GPIO, 0xcf, 0xff, 0x0b},
+ {EM2874_R80_GPIO, 0xef, 0xff, 0x65},
-
-//per il tuner?
- {EM2874_R80_GPIO, 0xef, 0xff, 1}, //1110
- {EM2874_R80_GPIO, 0xcf, 0xff, 11},//1100
init bit 6
- {EM2874_R80_GPIO, 0xef, 0xff, 64}, //1110
-
- {EM2874_R80_GPIO, 0xcf, 0xff, 101},
[PATCH 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again
From: Eddi De Pieri e...@depieri.net
With this patch I try again to add initial support for HVR930C.
Tested only DVB-T, since in Italy Analog service is stopped.
Actually scan -a0 -f1, find only about 50 channel while 400 should
be available.
[mche...@redhat.com: Tested with DVB-C and fixed a few whitespace issues]
Tested-by: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Eddi De Pieri e...@depieri.net
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/xc5000.c |4 +
drivers/media/dvb/frontends/drxk.h|2 +
drivers/media/dvb/frontends/drxk_hard.c |4 +-
drivers/media/video/em28xx/em28xx-cards.c | 37 -
drivers/media/video/em28xx/em28xx-dvb.c | 136 -
drivers/media/video/em28xx/em28xx.h |2 +
6 files changed, 181 insertions(+), 4 deletions(-)
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index ecd1f95..048f489 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -1004,6 +1004,8 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend
*fe)
struct xc5000_priv *priv = fe-tuner_priv;
int ret = 0;
+ mutex_lock(xc5000_list_mutex);
+
if (xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
ret = xc5000_fwupload(fe);
if (ret != XC_RESULT_SUCCESS)
@@ -1023,6 +1025,8 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend
*fe)
/* Default to CABLE mode */
ret |= xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE);
+ mutex_unlock(xc5000_list_mutex);
+
return ret;
}
diff --git a/drivers/media/dvb/frontends/drxk.h
b/drivers/media/dvb/frontends/drxk.h
index 58baf41..e6d42e2 100644
--- a/drivers/media/dvb/frontends/drxk.h
+++ b/drivers/media/dvb/frontends/drxk.h
@@ -26,6 +26,8 @@ struct drxk_config {
boolantenna_dvbt;
u16 antenna_gpio;
+ intchunk_size;
+
const char *microcode_name;
};
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index dc13fd8..2392092 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -681,7 +681,8 @@ static int init_state(struct drxk_state *state)
state-m_hasOOB = false;
state-m_hasAudio = false;
- state-m_ChunkSize = 124;
+ if (!state-m_ChunkSize)
+ state-m_ChunkSize = 124;
state-m_oscClockFreq = 0;
state-m_smartAntInverted = false;
@@ -6430,6 +6431,7 @@ struct dvb_frontend *drxk_attach(const struct drxk_config
*config,
state-no_i2c_bridge = config-no_i2c_bridge;
state-antenna_gpio = config-antenna_gpio;
state-antenna_dvbt = config-antenna_dvbt;
+ state-m_ChunkSize = config-chunk_size;
/* NOTE: as more UIO bits will be used, add them to the mask */
state-UIO_mask = config-antenna_gpio;
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 19a5be3..705aedf 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -336,6 +336,24 @@ static struct em28xx_reg_seq pctv_460e[] = {
{ -1, -1, -1, -1},
};
+static struct em28xx_reg_seq hauppauge_930c_gpio[] = {
+// xc5000 reset
+ {EM2874_R80_GPIO, 0x6f, 0xff, 10},
+ {EM2874_R80_GPIO, 0x4f, 0xff, 10},
+ {EM2874_R80_GPIO, 0x6f, 0xff, 10},
+ {EM2874_R80_GPIO, 0x4f, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
+#if 0
+static struct em28xx_reg_seq hauppauge_930c_digital[] = {
+ {EM2874_R80_GPIO, 0xf6, 0xff, 10},
+ {EM2874_R80_GPIO, 0xe6, 0xff, 100},
+ {EM2874_R80_GPIO, 0xa6, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+#endif
+
/*
* Board definitions
*/
@@ -892,6 +910,19 @@ struct em28xx_board em28xx_boards[] = {
EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
},
+ [EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C] = {
+ .name = Hauppauge WinTV HVR 930C,
+ .has_dvb = 1,
+//#if 0
+// .tuner_type = TUNER_XC5000,
+// .tuner_addr = 0x41,
+// .dvb_gpio = hauppauge_930c_digital, /* FIXME: probably
wrong */
+ .tuner_gpio = hauppauge_930c_gpio,
+//#endif
+ .i2c_speed= EM2874_I2C_SECONDARY_BUS_SELECT |
+ EM28XX_I2C_CLK_WAIT_ENABLE |
+ EM28XX_I2C_FREQ_400_KHZ,
+ },
[EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900] = {
.name = Hauppauge WinTV HVR 900,
.tda9887_conf = TDA9887_PRESENT,
@@ -1975,6 +2006,8 @@ struct usb_device_id
[PATCH 8/8] [media] em28xx: Add IR support for HVR-930C
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/rc/keymaps/rc-hauppauge.c | 51 +
drivers/media/video/em28xx/em28xx-cards.c |1 +
2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/drivers/media/rc/keymaps/rc-hauppauge.c
b/drivers/media/rc/keymaps/rc-hauppauge.c
index cd3db77..0afb23b 100644
--- a/drivers/media/rc/keymaps/rc-hauppauge.c
+++ b/drivers/media/rc/keymaps/rc-hauppauge.c
@@ -182,6 +182,57 @@ static struct rc_map_table rc5_hauppauge_new[] = {
{ 0x1d3f, KEY_HOME },
/*
+* Keycodes for PT# R-005 remote bundled with Haupauge HVR-930C
+* Keycodes start with address = 0x1c
+*/
+ { 0x1c3b, KEY_GOTO },
+ { 0x1c3d, KEY_POWER },
+
+ { 0x1c14, KEY_UP },
+ { 0x1c15, KEY_DOWN },
+ { 0x1c16, KEY_LEFT },
+ { 0x1c17, KEY_RIGHT },
+ { 0x1c25, KEY_OK },
+
+ { 0x1c00, KEY_0 },
+ { 0x1c01, KEY_1 },
+ { 0x1c02, KEY_2 },
+ { 0x1c03, KEY_3 },
+ { 0x1c04, KEY_4 },
+ { 0x1c05, KEY_5 },
+ { 0x1c06, KEY_6 },
+ { 0x1c07, KEY_7 },
+ { 0x1c08, KEY_8 },
+ { 0x1c09, KEY_9 },
+
+ { 0x1c1f, KEY_EXIT }, /* BACK */
+ { 0x1c0d, KEY_MENU },
+ { 0x1c1c, KEY_TV },
+
+ { 0x1c10, KEY_VOLUMEUP },
+ { 0x1c11, KEY_VOLUMEDOWN },
+
+ { 0x1c20, KEY_CHANNELUP },
+ { 0x1c21, KEY_CHANNELDOWN },
+
+ { 0x1c0f, KEY_MUTE },
+ { 0x1c12, KEY_PREVIOUS }, /* Prev */
+
+ { 0x1c36, KEY_STOP },
+ { 0x1c37, KEY_RECORD },
+
+ { 0x1c24, KEY_LAST }, /* | */
+ { 0x1c1e, KEY_NEXT }, /* | */
+
+ { 0x1c0a, KEY_TEXT },
+ { 0x1c0e, KEY_SUBTITLE }, /* CC */
+
+ { 0x1c32, KEY_REWIND },
+ { 0x1c30, KEY_PAUSE },
+ { 0x1c35, KEY_PLAY },
+ { 0x1c34, KEY_FASTFORWARD },
+
+ /*
* Keycodes for the old Black Remote Controller
* This one also uses RC-5 protocol
* Keycodes start with address = 0x00
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index d92e0af..f63a715 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -922,6 +922,7 @@ struct em28xx_board em28xx_boards[] = {
#else
.tuner_type = TUNER_ABSENT,
#endif
+ .ir_codes = RC_MAP_HAUPPAUGE,
.i2c_speed= EM2874_I2C_SECONDARY_BUS_SELECT |
EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
--
1.7.7.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 4/8] [media] xc5000: Add support for get_if_frequency
This is needed for devices with DRX-K and xc5000.
Tested with a HVR 930C hardware.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/xc5000.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index 88b329c..ecd1f95 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -968,6 +968,14 @@ static int xc5000_get_frequency(struct dvb_frontend *fe,
u32 *freq)
return 0;
}
+static int xc5000_get_if_frequency(struct dvb_frontend *fe, u32 *freq)
+{
+ struct xc5000_priv *priv = fe-tuner_priv;
+ dprintk(1, %s()\n, __func__);
+ *freq = priv-if_khz * 1000;
+ return 0;
+}
+
static int xc5000_get_bandwidth(struct dvb_frontend *fe, u32 *bw)
{
struct xc5000_priv *priv = fe-tuner_priv;
@@ -1108,6 +1116,7 @@ static const struct dvb_tuner_ops xc5000_tuner_ops = {
.set_params= xc5000_set_params,
.set_analog_params = xc5000_set_analog_params,
.get_frequency = xc5000_get_frequency,
+ .get_if_frequency = xc5000_get_if_frequency,
.get_bandwidth = xc5000_get_bandwidth,
.get_status= xc5000_get_status
};
--
1.7.7.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: [PATCH] initial support for HAUPPAUGE HVR-930C again...
Attached the patch for for get_firmware
Regards,
Eddi
On Sun, Nov 20, 2011 at 1:57 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 19-11-2011 13:37, Eddi De Pieri escreveu:
With this patch I try again to add initial support for HVR930C.
Tested only DVB-T, since in Italy Analog service is stopped.
Actually scan -a0 -f1, find only about 50 channel while 400 should
be available.
Signed-off-by: Eddi De Pieri e...@depieri.net
Tested here with DVB-C, using the Terratec firmware. It worked as expected:
213 channels scanned, tested a few non-encrypted ones, and it seems to be
working as expected.
It didn't work with the firmware used by ddbrigde driver (the one that
get_dvb_firmware
script is capable of retrieving).
Regards
Eddi
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index c466f58..503d70f 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -27,7 +27,7 @@ use IO::Handle;
or51211, or51132_qam, or51132_vsb, bluebird,
opera1, cx231xx, cx18, cx23885, pvrusb2, mpc718,
af9015, ngene, az6027, lme2510_lg, lme2510c_s7395,
- lme2510c_s7395_old, drxk, drxk_terratec_h5);
+ lme2510c_s7395_old, drxk, drxk_hauppauge_hvr930c, drxk_terratec_h5);
# Check args
syntax() if (scalar(@ARGV) != 1);
@@ -652,6 +652,24 @@ sub drxk {
$fwfile
}
+sub drxk_hauppauge_hvr930c {
+my $url = http://www.wintvcd.co.uk/drivers/;;
+my $zipfile = HVR-9x0_5_10_325_28153_SIGNED.zip;
+my $hash = 83ab82e7e9480ec8bf1ae0155ca63c88;
+my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 1);
+my $drvfile = HVR-900/emOEM.sys;
+my $fwfile = dvb-usb-hauppauge-hvr930c-drxk.fw;
+
+checkstandard();
+
+wgetfile($zipfile, $url . $zipfile);
+verify($zipfile, $hash);
+unzip($zipfile, $tmpdir);
+extract($tmpdir/$drvfile, 0x117b0, 42692, $fwfile);
+
+$fwfile
+}
+
sub drxk_terratec_h5 {
my $url = http://www.linuxtv.org/downloads/firmware/;;
my $hash = 19000dada8e2741162ccc50cc91fa7f1;
Re: [PATCH] initial support for HAUPPAUGE HVR-930C again...
Em 20-11-2011 13:00, Eddi De Pieri escreveu: Attached the patch for for get_firmware Thanks! Could you please sign it? Regards, Eddi On Sun, Nov 20, 2011 at 1:57 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 19-11-2011 13:37, Eddi De Pieri escreveu: With this patch I try again to add initial support for HVR930C. Tested only DVB-T, since in Italy Analog service is stopped. Actually scan -a0 -f1, find only about 50 channel while 400 should be available. Signed-off-by: Eddi De Pieri e...@depieri.net Tested here with DVB-C, using the Terratec firmware. It worked as expected: 213 channels scanned, tested a few non-encrypted ones, and it seems to be working as expected. It didn't work with the firmware used by ddbrigde driver (the one that get_dvb_firmware script is capable of retrieving). Regards Eddi -- 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] omap3isp: fix compilation of ispvideo.c
Fix following build error by explicitely including linux/module.h header file. CC drivers/media/video/omap3isp/ispvideo.o drivers/media/video/omap3isp/ispvideo.c:1267: error: 'THIS_MODULE' undeclared here (not in a function) make[4]: *** [drivers/media/video/omap3isp/ispvideo.o] Error 1 make[3]: *** [drivers/media/video/omap3isp] Error 2 make[2]: *** [drivers/media/video] Error 2 make[1]: *** [drivers/media] Error 2 make: *** [drivers] Error 2 Signed-off-by: Dmitry Artamonow mad_s...@inbox.ru --- drivers/media/video/omap3isp/ispvideo.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap3isp/ispvideo.c b/drivers/media/video/omap3isp/ispvideo.c index d100072..f229057 100644 --- a/drivers/media/video/omap3isp/ispvideo.c +++ b/drivers/media/video/omap3isp/ispvideo.c @@ -26,6 +26,7 @@ #include asm/cacheflush.h #include linux/clk.h #include linux/mm.h +#include linux/module.h #include linux/pagemap.h #include linux/scatterlist.h #include linux/sched.h -- 1.7.4.rc3 -- 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 resent] Fix logic in sanity check
Hi, On 11/04/2011 10:16 AM, Sylwester Nawrocki wrote: On 10/15/2011 11:38 PM, Thomas Jarosch wrote: Detected by cppcheck. This time with Signed-off-by line. When a note like this is added, not suitable for the changelog, it should be placed after your SOB line, and below a line containing only the --- marker. Please check with Documentation/SubmittingPatches for more details. Signed-off-by: Thomas Jaroschthomas.jaro...@intra2net.com Acked-by: Sylwester Nawrockis.nawro...@samsung.com Sorry, I was a bit too quick with this ack. If you care to resend the patch, please add m5mols: as a subsystem name in the subject so it looks something like: [PATCH ...] m5mols: Fix ... --- drivers/media/video/m5mols/m5mols_core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- 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
[PATCH] Update dvb-t scan frequencies for uk-Oxford, following digital switchover
Hi All The scan channels file in dvb-apps/util/scan/dvb-t/uk-Oxford needs to be updated with the new frequencies for Oxford, UK, following the digital switchover here that happend a short time ago. Based on some public information, w_scan and some trial+error, I believe the patch below will update the file to the new frequencies Cheers Nick --- a/util/scan/dvb-t/uk-Oxford Fri Oct 07 01:26:04 2011 +0530 +++ b/util/scan/dvb-t/uk-Oxford Sun Nov 20 17:44:17 2011 + @@ -1,10 +1,26 @@ # UK, Oxford -# Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html -# and http://www.ofcom.org.uk/static/reception_advice/index.asp.html -# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 57800 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 85000 8MHz 2/3 NONE QAM64 2k 1/32 NONE +# +# Post-Switchover, found from a mixture of w_scan, trial+error +# and http://www.ukfree.tv/txdetail.php?a=SP567105 + +# Local Channels, C51, details still TBA T 713833000 8MHz 2/3 NONE QAM64 2k 1/32 NONE -T 721833000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 69000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 53800 8MHz 3/4 NONE QAM16 2k 1/32 NONE + +# PSB1 BBC-A, C53+. Apparently 730.2 but actually looks to be 730.167 +T 730167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE + +# ArqB (COM6), C55, 746.0 +T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE + +# PSB3 BBC-B, C57, 256QAM DVB-T2, TBA +# May well be wrong, needs a DVB-T2 tuner to be sure! +T 76200 8MHz 2/3 NONE QAM256 8k 1/32 NONE + +# ArqA (COM5), C59-, Apparently 777.8 but actually looks to be 777.833 +T 777833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE + +# PSB2, D3+4, C60-, Apparently 785.0 but actually looks to be 785.833 +T 785833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE + +# SDN (COM4), C62, 802.0 +T 80200 8MHz 2/3 NONE QAM64 8k 1/32 NONE -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun Nov 20 19:00:19 CET 2011 git hash:e9eb0dadba932940f721f9d27544a7818b2fa1c5 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS 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-rc1-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS 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-rc1-x86_64: ERRORS spec-git: WARNINGS 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: [PATCH 1/8] [media] dvb: Allow select between DVB-C Annex A and Annex C
Le dimanche 20 novembre 2011 16:56:11 Mauro Carvalho Chehab, vous avez écrit : DVB-C, as defined by ITU-T J.83 has 3 annexes. The differences between Annex A and Annex C is that Annex C uses a subset of the modulation types, and uses a different rolloff factor. A different rolloff means that the bandwidth required is slicely different, and may affect the saw filter configuration at the tuners. Also, some demods have different configurations, depending on using Annex A or Annex C. So, allow userspace to specify it, by changing the rolloff factor. I assume you'll bump the minor DVB version at some point too? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: [KS workshop follow-up] multiple sensor contexts
Hi Guennadi, On Mon, Nov 07, 2011 at 05:17:23PM +0100, Guennadi Liakhovetski wrote: Hi all At the V4L/DVB workshop in Prague a couple of weeks ago possible merits of supporting multiple camera sensor contexts have been discussed. Such contexts are often promoted by camera manufacturers as a hardware optimization to support fast switching to the snapshot mode. Such a switch is often accompanied by a change of the frame format. Typically, a smaller frame is used for the preview mode and a larger frame is used for photo shooting. Those sensors provide 2 (or more) sets of frame size and data format registers and a single command to switch between them. The decision, whether or not to support these multiple camera contexts has been postponed until some measurements become available, how much time such a fast switching implementation would save us. I took the mt9m111 driver, that supports mt9m111, mt9m131, and mt9m112 camera sensors from Aptina. They do indeed implement two contexts, however, the driver first had to be somewhat reorganised to make use of them. I pushed my (highly!) experimental tree to git://linuxtv.org/gliakhovetski/v4l-dvb.git staging-3.3 with the addition of the below debugging diff, that pre-programs a fixed format into the second context registers and switches to it, once a matching S_FMT is called. On the i.MX31 based pcm037 board, that I've got, this sensor is attached to the I2C bus #2, running at 20kHz. The explicit programming of the new format parameters measures to take around 27ms, which is also about what we win, when using the second context. 27 ms isn't a lot. May I ask what's the reason for such an unusual I2C speed? Even the relatively low speed 400 kHz spec has been available for almost 20 years by now. As for interpretation: firstly 20kHz is not much, I expect many other set ups to run much faster. But even if we accept, that on some hardware 20kHz doesn't work and we really lose 27ms when not using multiple register contexts, is it a lot? Thinking about my personal photographing experiences with cameras and camera-phones, I don't think, I'd notice a 27ms latency;-) I don't think anything below 200ms really makes a difference and, I think, the major contributor to the snapshot latency is the need to synchronise on a frame, and, possibly skip or shoot several frames, instead of just one. So, my conclusion would be: when working with sane camera sensors, i.e., those, where you don't have to reprogram 100s of registers from some magic tables to configure a different frame format (;-)), supporting several register contexts doesn't bring a huge advantage in terms of snapshot latency. OTOH, it can well happen, that at some point we anyway will have to support those multiple register contexts for some other reason. Sensor have seldom anything which would require passing a huge amount of data to configure the sensor. I personally don't see need for supporting different contects in the foreseeable future --- but of course I could be wrong. Also knowing much of a future desired configuration is a difficult guess. The hardware people will hopefully rather provide a faster bus to transfer the settings to the sensor to make the configuration delays smaller. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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: Regression with kernel 3.1 and bt87x?
Am 17.11.2011 17:29, schrieb Sebastian Steinhuber: Hi all, I've got a Hauppauge WinTV pci board that used to be working until kernel 3.1 was used; I tried 3.1.1, too, without luck. 3.0.7 is working, with the same config as the 3.1s regarding the media parts. I'm compiling my customized kernel from vanilla sources and a linux-vserver patch, and I also tested the 3.1.0-1-amd64 from debian stock with very result. On starting up Zapping, I got these messages: 'Unable to open /dev/video0.' 'The device cannot be attached to any controller.' Tvtime simply complained about 'No signal'. I couldn't find further messages or any errors in syslog nor in messages, so I'm feeling there might be a bug somewhere. The same modules are loaded into the kernel with 3.0.7 (working, with the same config as the 3.1s regarding the media parts), 3.1 and also 3.1.1: bttv btcx_risc rc_core tuner tuner_simple tuner_types videobuf_dma_sg videobuf_core tveeprom $lspci -vv … 05:00.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 02) Subsystem: Hauppauge computer works Inc. WinTV Series Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 (4000ns min, 1ns max) Interrupt: pin A routed to IRQ 16 Region 0: Memory at d0001000 (32-bit, prefetchable) [size=4K] Kernel driver in use: bttv 05:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 02) Subsystem: Hauppauge computer works Inc. WinTV Series Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 (1000ns min, 63750ns max) Interrupt: pin A routed to IRQ 16 Region 0: Memory at d000 (32-bit, prefetchable) [size=4K] Kernel driver in use: Bt87x Update: There are no issues with 3.0.9. If someone has an idea which commit could cause the problem, I would like to check it out. I have cloned the stable kernel repository and despite of being new to git, I can test every commit with the hardware. Thanks in advance, Sebastian -- 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: mt9p031 based sensor and ack lockups. Ie CCDC won't become idle.
Hi All:
I'm having fun with my new camera project that uses the mt9p031
camera. I'm getting nice raw stills, and that's great, but every 16 or
so images I take I get a troublesome error.
CCDC won't become idle!
The message is coming from...
static int ccdc_isr_buffer(struct isp_ccdc_device *ccdc)
in ...
linux-2.6.39.1/drivers/media/video/omap3isp/ispccdc.c
I printed out the return of the status of the registers on the CCDC
and found that the only bit set was the CCDC_BUSY register.
static int ccdc_sbl_busy(struct isp_ccdc_device *ccdc)
{
struct isp_device *isp = to_isp_device(ccdc);
return omap3isp_ccdc_busy(ccdc)
| (isp_reg_readl(isp, OMAP3_ISP_IOMEM_SBL, ISPSBL_CCDC_WR_0)
ISPSBL_CCDC_WR_0_DATA_READY)
| (isp_reg_readl(isp, OMAP3_ISP_IOMEM_SBL, ISPSBL_CCDC_WR_1)
ISPSBL_CCDC_WR_0_DATA_READY)
| (isp_reg_readl(isp, OMAP3_ISP_IOMEM_SBL, ISPSBL_CCDC_WR_2)
ISPSBL_CCDC_WR_0_DATA_READY)
| (isp_reg_readl(isp, OMAP3_ISP_IOMEM_SBL, ISPSBL_CCDC_WR_3)
ISPSBL_CCDC_WR_0_DATA_READY);
}
I THINK I'm suffering from a data underflow, where the previous batch
of images did not complete, or something. Which is funny because I
almost always get a full data set if everything starts up with no
hiccup. I should add that I get this error when I start a exposure and
data ack. The error is immediate, not in the middle of an ack. In fact
the error is thrown during the yavta init sequence. During a
ioctl(STREAM_ON).
I tried to issue a isp flush to the flush bit as described on (fig
Table 12-88 ISP_CTRL) pg 1512 of the TI-OMAP manual. This froze the
whole system. I'm wondering if anyone else is running into a similar
or even the same problem and if they know of a solution, a fix, or a
workaround?
Thanks.
Andrew
--
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
