Re: [PATCH] initial support for HAUPPAUGE HVR-930C again...
Attached the patch for for get_firmware
Signed-off-by: Eddi De Pieri e...@depieri.net
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] media: vb2: vmalloc-based allocator user pointer handling
Hello, On Thursday, November 17, 2011 11:41 AM javier Martin wrote: what is the current status of this patch? Do you plan to send an improved version? I want to test it against my mem2mem driver I recently submitted (emma-PrP) and a UVC camera in order to transform YUYV to YUV420. Provided we ignore the locking problems you have mentioned is it in a 'working' state? The updated version will be posted soon. However using it for accessing mmaped buffers from your mem2mem driver (which relies on videobuf2-dma-contig allocator) requires some additional work to get access to direct PFNMAP-type mappings in kernel space. Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] initial support for HAUPPAUGE HVR-930C again...
Em 21-11-2011 08:43, Eddi De Pieri escreveu: Attached the patch for for get_firmware Signed-off-by: Eddi De Pieri e...@depieri.net Regards, Eddi Applied, thanks. Did a quick test here with DVB-C and the HVR-930C firmware. It worked properly with both scan and vlc. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.3] [media] dvb: Allow select between DVB-C Annex A and Annex C
Hi Mauro,
On Fri, Nov 11, 2011 at 8:16 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] dvb: Allow select between DVB-C Annex A and Annex C
Author: Mauro Carvalho Chehab mche...@redhat.com
Date: Fri Nov 11 12:46:23 2011 -0200
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(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=39ce61a846c8e1fa00cb57ad5af021542e6e8403
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 {
Please don't do this.
Why ?
- It is an API bug: DVBC_ANNEX_AC should not have existed.
- We should handle systems by their delivery systems and each
delivery system should be unique.
- We wouldn't want the user to know more details, such as rolloff,
the user would know whether they are in the Europe, US or Japan, which
would imply ANNEX_A, ANNEX_B, ANNEX_C respectively.
Ok, that said there exists the issue and you found some way to
workaround the issue. But it doesn't look nice.
- I would instead like to have the API bug fix instead, as Andreas
suggested in another thread.
in frontend.h
#define DVBC_ANNEX_AC DVBC_ANNEX_A
and in enum fe_delivery system_t
replace DVBC_ANNEX_AC with DVBC_ANNEX_A
add in DVBC_ANNEX_B and DVBC_ANNEX_C
What would this gain ?
- A unique delivery system descriptor (This is what I am trying to
address in the query fe delivery system capabilities. If you have a
device that supports
Re: Nova-T Stick 2 on kernel 3.0
Hi Jos, On Monday 21 November 2011 14:14:25 Jos Lemmens wrote: Hello Patrick, I have a Device 008: ID 2040:7060 Hauppauge Nova-T Stick 2 dvb adapter. It worked great with your driver in Linux kernel 2. But since kernel 3.0 it doesn't work anymore. When I try to start the tv with the tzap tool, I get this message: dib0700: tx buffer length is larger than 4. Not supported. Oh, I wasn't aware that this problem exists (or I forgot). If you can please try a newer version of the kernel. Or try the media_build + the v4l-dvb-repository to track down (via git bisect, for example) which commit broke it. What was the latest version you have tried? Anyone else confirms this problem? -- Patrick -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Mon Nov 21 19:00:21 CET 2011 git hash:6fd7dba026f17076ac4bd63a3590f993c1f5c2c6 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/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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
PATCH 00/13: Enumerate DVB frontend Delivery System capabilities to identify devices correctly.
Hi, As discussed prior, the following changes help to advertise a frontend's delivery system capabilities. Sending out the patches as they are being worked out. The following patch series are applied against media_tree.git after the following commit commit e9eb0dadba932940f721f9d27544a7818b2fa1c5 Author: Hans Verkuil hans.verk...@cisco.com Date: Tue Nov 8 11:02:34 2011 -0300 [media] V4L menu: add submenu for platform devices Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 01/13: 0001-DVB-Query-DVB-frontend-delivery-capabilities
From 6359555647f7082846a1bb8f229299260af0db5f Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Mon, 14 Nov 2011 03:17:44 +0530
Subject: [PATCH 01/13] DVB: Query DVB frontend delivery capabilities.
Currently, for any multi-standard frontend it is assumed that it just
has a single standard capability. This is fine in some cases, but
makes things hard when there are incompatible standards in conjuction.
Eg: DVB-S can be seen as a subset of DVB-S2, but the same doesn't hold
the same for DSS. This is not specific to any driver as it is, but a
generic issue. This was handled correctly in the multiproto tree,
while such functionality is missing from the v5 API update.
http://www.linuxtv.org/pipermail/vdr/2008-November/018417.html
Later on a FE_CAN_2G_MODULATION was added as a hack to workaround this
issue in the v5 API, but that hack is incapable of addressing the
issue, as it can be used to simply distinguish between DVB-S and
DVB-S2 alone, or another X vs X2 modulation. If there are more systems,
then you have a potential issue.
An application needs to query the device capabilities before requesting
any operation from the device.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 36 +
include/linux/dvb/frontend.h |4 ++-
include/linux/dvb/version.h |2 +-
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 2c0acdb..1368d8c 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -973,6 +973,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
_DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
_DTV_CMD(DTV_HIERARCHY, 0, 0),
+
+ _DTV_CMD(DTV_ENUM_DELSYS, 0, 0),
};
static void dtv_property_dump(struct dtv_property *tvp)
@@ -1207,6 +1209,37 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
static int dvb_frontend_ioctl_properties(struct file *file,
unsigned int cmd, void *parg);
+static void dtv_set_default_delivery_caps(const struct dvb_frontend *fe, struct dtv_property *p)
+{
+ const struct dvb_frontend_info *info = fe-ops.info;
+ u32 ncaps = 0;
+
+ switch (info-type) {
+ case FE_QPSK:
+ p-u.buffer.data[ncaps++] = SYS_DVBS;
+ if (info-caps FE_CAN_2G_MODULATION)
+ p-u.buffer.data[ncaps++] = SYS_DVBS2;
+ if (info-caps FE_CAN_TURBO_FEC)
+ p-u.buffer.data[ncaps++] = SYS_TURBO;
+ break;
+ case FE_QAM:
+ p-u.buffer.data[ncaps++] = SYS_DVBC_ANNEX_AC;
+ break;
+ case FE_OFDM:
+ p-u.buffer.data[ncaps++] = SYS_DVBT;
+ if (info-caps FE_CAN_2G_MODULATION)
+ p-u.buffer.data[ncaps++] = SYS_DVBT2;
+ break;
+ case FE_ATSC:
+ if (info-caps (FE_CAN_8VSB | FE_CAN_16VSB))
+ p-u.buffer.data[ncaps++] = SYS_ATSC;
+ if (info-caps (FE_CAN_QAM_16 | FE_CAN_QAM_64 | FE_CAN_QAM_128 | FE_CAN_QAM_256))
+ p-u.buffer.data[ncaps++] = SYS_DVBC_ANNEX_B;
+ break;
+ }
+ p-u.buffer.len = ncaps;
+}
+
static int dtv_property_process_get(struct dvb_frontend *fe,
struct dtv_property *tvp,
struct file *file)
@@ -1227,6 +1260,9 @@ static int dtv_property_process_get(struct dvb_frontend *fe,
}
switch(tvp-cmd) {
+ case DTV_ENUM_DELSYS:
+ dtv_set_default_delivery_caps(fe, tvp);
+ break;
case DTV_FREQUENCY:
tvp-u.data = c-frequency;
break;
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 1b1094c..f80b863 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -316,7 +316,9 @@ struct dvb_frontend_event {
#define DTV_DVBT2_PLP_ID 43
-#define DTV_MAX_COMMANDDTV_DVBT2_PLP_ID
+#define DTV_ENUM_DELSYS 44
+
+#define DTV_MAX_COMMANDDTV_ENUM_DELSYS
typedef enum fe_pilot {
PILOT_ON,
diff --git a/include/linux/dvb/version.h b/include/linux/dvb/version.h
index 66594b1..0559e2b 100644
--- a/include/linux/dvb/version.h
+++ b/include/linux/dvb/version.h
@@ -24,6 +24,6 @@
#define _DVBVERSION_H_
#define DVB_API_VERSION 5
-#define DVB_API_VERSION_MINOR 4
+#define DVB_API_VERSION_MINOR 5
#endif /*_DVBVERSION_H_*/
--
1.7.1
PATCH 02/13: 0002-DVB-Docbook-update-for-DTV_ENUM_DELSYS
From eb420e766b79aa3b55f18227f337288f28237f86 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Wed, 16 Nov 2011 19:04:24 +0530
Subject: [PATCH 02/13] DVB: Docbook update for DTV_ENUM_DELSYS
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
Documentation/DocBook/media/dvb/dvbproperty.xml | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 3bc8a61..09ada6c 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -647,6 +647,18 @@ typedef enum fe_hierarchy {
many data types via a single multiplex. The API will soon support this
at which point this section will be expanded./para
/section
+ section id=DTV_ENUM_DELSYS
+ titleconstantDTV_ENUM_DELSYS/constant/title
+ paraA Multi standard frontend needs to advertise the delivery systems provided.
+ Applications need to enumerate the provided delivery systems, before using
+ any other operation with the frontend. Prior to it's introduction,
+ FE_GET_INFO was used to determine a frontend type. A frontend which
+ provides more than a single delivery system, FE_GET_INFO doesn't help much.
+ Applications which intends to use a multistandard frontend must enumerate
+ the delivery systems associated with it, rather than trying to use
+ FE_GET_INFO. In the case of a legacy frontend, the result is just the same
+ as with FE_GET_INFO, but in a more structured format /para
+ /section
/section
section id=frontend-property-terrestrial-systems
titleProperties used on terrestrial delivery systems/title
--
1.7.1
PATCH 03/13: 0003-DVB-Allow-frontend-to-set-DELSYS-Modulation
From 0f1010bd5b1813cff087db9ccaaf95abe5858e53 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Sat, 19 Nov 2011 19:00:38 +0530
Subject: [PATCH 03/13] DVB: Allow frontend to set DELSYS/Modulation rather than querying fe-ops.info.type
With any tuner that can tune to multiple delivery systems/standards, it does
query fe-ops.info.type to determine frontend type and set the delivery
system type. fe-ops.info.type can handle only 4 delivery systems, viz FE_QPSK,
FE_QAM, FE_OFDM and FE_ATSC.
The change allows the tuner to be set to any delivery system specified in
fe_delivery_system_t and any modulation as specified in fe_modulation_t,
thereby simplification of issues.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/dvb/dvb-core/dvb_frontend.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 67bbfa7..ec6e8e9 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -113,6 +113,8 @@ enum tuner_param {
DVBFE_TUNER_BANDWIDTH = (1 3),
DVBFE_TUNER_REFCLOCK = (1 4),
DVBFE_TUNER_IQSENSE = (1 5),
+ DVBFE_TUNER_DELSYS = (1 6),
+ DVBFE_TUNER_MODULATION = (1 7),
DVBFE_TUNER_DUMMY = (1 31)
};
@@ -149,6 +151,8 @@ enum dvbfe_algo {
};
struct tuner_state {
+ fe_delivery_system_t delsys;
+ fe_modulation_t modulation;
u32 frequency;
u32 tunerstep;
u32 ifreq;
--
1.7.1
PATCH 04/13: 0004-TDA18271-Allow-frontend-to-set-DELSYS
From 2ece38602678ae323450d0e35379147e6e086326 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Sat, 19 Nov 2011 19:50:09 +0530
Subject: [PATCH 04/13] TDA18271: Allow frontend to set DELSYS, rather than querying fe-ops.info.type
With any tuner that can tune to multiple delivery systems/standards, it does
query fe-ops.info.type to determine frontend type and set the delivery
system type. fe-ops.info.type can handle only 4 delivery systems, viz FE_QPSK,
FE_QAM, FE_OFDM and FE_ATSC.
The change allows the tuner to be set to any delivery system specified in
fe_delivery_system_t, thereby simplifying a lot of issues.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/common/tuners/tda18271-fe.c | 80 +++
drivers/media/common/tuners/tda18271-priv.h |2 +
2 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/media/common/tuners/tda18271-fe.c b/drivers/media/common/tuners/tda18271-fe.c
index 3347c5b..6e29faf 100644
--- a/drivers/media/common/tuners/tda18271-fe.c
+++ b/drivers/media/common/tuners/tda18271-fe.c
@@ -928,6 +928,85 @@ fail:
/* -- */
+static int tda18271_set_state(struct dvb_frontend *fe,
+ enum tuner_param param,
+ struct tuner_state *state)
+{
+ struct tda18271_priv *priv = fe-tuner_priv;
+ struct tuner_state *req = priv-request;
+ struct tda18271_std_map *std_map = priv-std;
+ struct tda18271_std_map_item *map;
+ int ret;
+
+ BUG_ON(!priv);
+ if (param DVBFE_TUNER_DELSYS)
+ req-delsys = state-delsys;
+ if (param DVBFE_TUNER_FREQUENCY)
+ req-frequency = state-frequency;
+ if (param DVBFE_TUNER_BANDWIDTH)
+ req-bandwidth = state-bandwidth;
+
+ priv-mode = TDA18271_DIGITAL;
+
+ switch (req-delsys) {
+ case SYS_ATSC:
+ map = std_map-atsc_6;
+ req-bandwidth = 600;
+ break;
+ case SYS_DVBC_ANNEX_B:
+ map = std_map-qam_6;
+ req-bandwidth = 600;
+ break;
+ case SYS_DVBT:
+ case SYS_DVBT2:
+ switch (req-bandwidth) {
+ case 600:
+ map = std_map-dvbt_6;
+ break;
+ case 700:
+ map = std_map-dvbt_7;
+ break;
+ case 800:
+ map = std_map-dvbt_8;
+ break;
+ default:
+ ret = -EINVAL;
+ goto fail;
+ }
+ break;
+ case SYS_DVBC_ANNEX_AC:
+ map = std_map-qam_8;
+ req-bandwidth = 800;
+ break;
+ default:
+ tda_warn(Invalid delivery system!\n);
+ ret = -EINVAL;
+ goto fail;
+ }
+ tda_dbg(Trying to tune .. delsys=%d modulation=%d frequency=%d bandwidth=%d,
+ req-delsys,
+ req-modulation,
+ req-frequency,
+ req-bandwidth);
+
+ /* When tuning digital, the analog demod must be tri-stated */
+ if (fe-ops.analog_ops.standby)
+ fe-ops.analog_ops.standby(fe);
+
+ ret = tda18271_tune(fe, map, req-frequency, req-bandwidth);
+
+ if (tda_fail(ret))
+ goto fail;
+
+ priv-if_freq = map-if_freq;
+ priv-frequency = req-frequency;
+ priv-bandwidth = (req-delsys == SYS_DVBT || req-delsys == SYS_DVBT2) ?
+ req-bandwidth : 0;
+fail:
+ return ret;
+}
+
+
static int tda18271_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
@@ -1249,6 +1328,7 @@ static const struct dvb_tuner_ops tda18271_tuner_ops = {
.init = tda18271_init,
.sleep = tda18271_sleep,
.set_params= tda18271_set_params,
+ .set_state = tda18271_set_state,
.set_analog_params = tda18271_set_analog_params,
.release = tda18271_release,
.set_config= tda18271_set_config,
diff --git a/drivers/media/common/tuners/tda18271-priv.h b/drivers/media/common/tuners/tda18271-priv.h
index 454c152..bd1bf58 100644
--- a/drivers/media/common/tuners/tda18271-priv.h
+++ b/drivers/media/common/tuners/tda18271-priv.h
@@ -126,6 +126,8 @@ struct tda18271_priv {
u32 frequency;
u32 bandwidth;
+
+ struct tuner_state request;
};
/*-*/
--
1.7.1
PATCH 05/13: 0005-TDA18271c2dd-Allow-frontend-to-set-DELSYS
From 73c0b7c386beae392cff568e08914582ed6329d1 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Sat, 19 Nov 2011 21:01:03 +0530
Subject: [PATCH 05/13] TDA18271c2dd: Allow frontend to set DELSYS, rather than querying fe-ops.info.type
With any tuner that can tune to multiple delivery systems/standards, it does
query fe-ops.info.type to determine frontend type and set the delivery
system type. fe-ops.info.type can handle only 4 delivery systems, viz FE_QPSK,
FE_QAM, FE_OFDM and FE_ATSC.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/dvb/frontends/tda18271c2dd.c | 56
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/tda18271c2dd.c b/drivers/media/dvb/frontends/tda18271c2dd.c
index 1b1bf20..6077674 100644
--- a/drivers/media/dvb/frontends/tda18271c2dd.c
+++ b/drivers/media/dvb/frontends/tda18271c2dd.c
@@ -1180,6 +1180,61 @@ static int set_params(struct dvb_frontend *fe,
return status;
}
+static int set_state(struct dvb_frontend *fe, enum tuner_param param, struct tuner_state *tuner)
+{
+ struct tda_state *state = fe-tuner_priv;
+ fe_delivery_system_t delsys = SYS_UNDEFINED;
+ u32 bandwidth = 0;
+ int status = 0;
+ int Standard = 0;
+
+ if (param DVBFE_TUNER_DELSYS)
+ delsys = tuner-delsys;
+ if (param DVBFE_TUNER_FREQUENCY)
+ state-m_Frequency = tuner-frequency;
+ if (param DVBFE_TUNER_BANDWIDTH)
+ bandwidth = tuner-bandwidth;
+
+ switch (delsys) {
+ case SYS_DVBT:
+ switch (bandwidth) {
+ case 600:
+ Standard = HF_DVBT_6MHZ;
+ break;
+ case 700:
+ Standard = HF_DVBT_7MHZ;
+ break;
+ case 800:
+ Standard = HF_DVBT_8MHZ;
+ break;
+ }
+ break;
+ case SYS_DVBC_ANNEX_AC:
+ /*
+ * FIXME! API BUG! DVB-C ANNEX A C are different
+ * This should have been simply DVBC_ANNEX_A
+ */
+ Standard = HF_DVBC_6MHZ;
+ break;
+ default:
+ status = -EINVAL;
+ goto err;
+ }
+
+ do {
+ status = RFTrackingFiltersCorrection(state, state-m_Frequency);
+ if (status 0)
+ break;
+ status = ChannelConfiguration(state, state-m_Frequency, Standard);
+ if (status 0)
+ break;
+
+ msleep(state-m_SettlingTime); /* Allow AGC's to settle down */
+ } while (0);
+err:
+ return status;
+}
+
#if 0
static int GetSignalStrength(s32 *pSignalStrength, u32 RFAgc, u32 IFAgc)
{
@@ -1221,6 +1276,7 @@ static struct dvb_tuner_ops tuner_ops = {
.init = init,
.sleep = sleep,
.set_params= set_params,
+ .set_state = set_state,
.release = release,
.get_if_frequency = get_if_frequency,
.get_bandwidth = get_bandwidth,
--
1.7.1
PATCH 06/13: 0006-STB0899-Query-DVB-frontend-delivery-capabilities
From 0a6b6cab5c64c6f8287ec19ac2d419777e723203 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Thu, 17 Nov 2011 06:44:53 +0530
Subject: [PATCH 06/13] STB0899: Query DVB frontend delivery capabilities
Override default delivery system information provided by FE_GET_INFO, so
that applications can enumerate delivery systems provided by the frontend.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/dvb/frontends/stb0899_drv.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/stb0899_drv.c b/drivers/media/dvb/frontends/stb0899_drv.c
index 8408ef8..9c93d9f 100644
--- a/drivers/media/dvb/frontends/stb0899_drv.c
+++ b/drivers/media/dvb/frontends/stb0899_drv.c
@@ -1605,6 +1605,21 @@ static enum dvbfe_algo stb0899_frontend_algo(struct dvb_frontend *fe)
return DVBFE_ALGO_CUSTOM;
}
+static int stb0899_get_property(struct dvb_frontend *fe, struct dtv_property *p)
+{
+ switch (p-cmd) {
+ case DTV_ENUM_DELSYS:
+ p-u.buffer.data[0] = SYS_DSS;
+ p-u.buffer.data[1] = SYS_DVBS;
+ p-u.buffer.data[2] = SYS_DVBS2;
+ p-u.buffer.len = 3;
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
static struct dvb_frontend_ops stb0899_ops = {
.info = {
@@ -1647,6 +1662,8 @@ static struct dvb_frontend_ops stb0899_ops = {
.diseqc_send_master_cmd = stb0899_send_diseqc_msg,
.diseqc_recv_slave_reply = stb0899_recv_slave_reply,
.diseqc_send_burst = stb0899_send_diseqc_burst,
+
+ .get_property = stb0899_get_property,
};
struct dvb_frontend *stb0899_attach(struct stb0899_config *config, struct i2c_adapter *i2c)
--
1.7.1
PATCH 07/13: 0007-CX24116-Query-DVB-frontend-delivery-capabilities
From c314b95085f4567d90b4e02272e60f8e15385aac Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Thu, 17 Nov 2011 07:06:26 +0530
Subject: [PATCH 07/13] CX24116: Query DVB frontend delivery capabilities
Override default delivery system information provided by FE_GET_INFO, so
that applications can enumerate delivery systems provided by the frontend.
The hardware also supports DSS, but there is currently no code within the
driver to handle the delivery system. When code exists to handle DSS, the
frontend needs to advertise it's DSS delivery system capability.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/dvb/frontends/cx24116.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/cx24116.c b/drivers/media/dvb/frontends/cx24116.c
index ccd0525..8860285 100644
--- a/drivers/media/dvb/frontends/cx24116.c
+++ b/drivers/media/dvb/frontends/cx24116.c
@@ -1223,6 +1223,15 @@ static int cx24116_get_property(struct dvb_frontend *fe,
struct dtv_property *tvp)
{
dprintk(%s(..)\n, __func__);
+ switch (tvp-cmd) {
+ case DTV_ENUM_DELSYS:
+ tvp-u.buffer.data[0] = SYS_DVBS;
+ tvp-u.buffer.data[1] = SYS_DVBS2;
+ tvp-u.buffer.len = 2;
+ break;
+ default:
+ break;
+ }
return 0;
}
--
1.7.1
PATCH 08/13: 0008-STV090x-Query-DVB-frontend-delivery-capabilities
From 5bb1e67b5d4f16132bac18c37c93153e9e5a8aba Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Thu, 17 Nov 2011 10:07:06 +0530
Subject: [PATCH 08/13] STV090x: Query DVB frontend delivery capabilities
Override default delivery system information provided by FE_GET_INFO, so
that applications can enumerate delivery systems provided by the frontend.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/dvb/frontends/stv090x.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/frontends/stv090x.c b/drivers/media/dvb/frontends/stv090x.c
index ebda419..8a2637c 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -4711,6 +4711,21 @@ int stv090x_set_gpio(struct dvb_frontend *fe, u8 gpio, u8 dir, u8 value,
}
EXPORT_SYMBOL(stv090x_set_gpio);
+static int stv090x_get_property(struct dvb_frontend *fe, struct dtv_property *p)
+{
+ switch (p-cmd) {
+ case DTV_ENUM_DELSYS:
+ p-u.buffer.data[0] = SYS_DSS;
+ p-u.buffer.data[1] = SYS_DVBS;
+ p-u.buffer.data[2] = SYS_DVBS2;
+ p-u.buffer.len = 3;
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
static struct dvb_frontend_ops stv090x_ops = {
.info = {
@@ -4743,7 +4758,9 @@ static struct dvb_frontend_ops stv090x_ops = {
.read_status = stv090x_read_status,
.read_ber = stv090x_read_per,
.read_signal_strength = stv090x_read_signal_strength,
- .read_snr = stv090x_read_cnr
+ .read_snr = stv090x_read_cnr,
+
+ .get_property = stv090x_get_property,
};
--
1.7.1
PATCH 09/13: 0009-DS3000-Query-DVB-frontend-delivery-capabilities
From be644cd7dc586621338a9c4c41567cc351723c05 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Thu, 17 Nov 2011 13:02:42 +0530
Subject: [PATCH 09/13] DS3000: Query DVB frontend delivery capabilities
Override default delivery system information provided by FE_GET_INFO, so
that applications can enumerate delivery systems provided by the frontend.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/dvb/frontends/ds3000.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/frontends/ds3000.c b/drivers/media/dvb/frontends/ds3000.c
index 90bf573..2fc76c9 100644
--- a/drivers/media/dvb/frontends/ds3000.c
+++ b/drivers/media/dvb/frontends/ds3000.c
@@ -941,10 +941,18 @@ static int ds3000_set_property(struct dvb_frontend *fe,
return 0;
}
-static int ds3000_get_property(struct dvb_frontend *fe,
- struct dtv_property *tvp)
+static int ds3000_get_property(struct dvb_frontend *fe, struct dtv_property *p)
{
dprintk(%s(..)\n, __func__);
+ switch (p-cmd) {
+ case DTV_ENUM_DELSYS:
+ p-u.buffer.data[0] = SYS_DVBS;
+ p-u.buffer.data[1] = SYS_DVBS2;
+ p-u.buffer.len = 2;
+ break;
+ default:
+ break;
+ }
return 0;
}
--
1.7.1
PATCH 10/13: 0010-TDA10071-Query-DVB-frontend-delivery-capabilities
From a7d7ceb62b0a00ba3093df6b196669826a3c625f Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Thu, 17 Nov 2011 13:28:29 +0530
Subject: [PATCH 10/13] TDA10071: Query DVB frontend delivery capabilities
Override default delivery system information provided by FE_GET_INFO, so
that applications can enumerate delivery systems provided by the frontend.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/dvb/frontends/tda10071.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/tda10071.c b/drivers/media/dvb/frontends/tda10071.c
index 0c37434..f9abe1d 100644
--- a/drivers/media/dvb/frontends/tda10071.c
+++ b/drivers/media/dvb/frontends/tda10071.c
@@ -1216,6 +1216,20 @@ error:
}
EXPORT_SYMBOL(tda10071_attach);
+static int tda10071_get_property(struct dvb_frontend *fe, struct dtv_property *p)
+{
+ switch (p-cmd) {
+ case DTV_ENUM_DELSYS:
+ p-u.buffer.data[0] = SYS_DVBS;
+ p-u.buffer.data[1] = SYS_DVBS2;
+ p-u.buffer.len = 2;
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
static struct dvb_frontend_ops tda10071_ops = {
.info = {
.name = NXP TDA10071,
@@ -1262,6 +1276,8 @@ static struct dvb_frontend_ops tda10071_ops = {
.set_tone = tda10071_set_tone,
.set_voltage = tda10071_set_voltage,
+
+ .get_property = tda10071_get_property,
};
MODULE_AUTHOR(Antti Palosaari cr...@iki.fi);
--
1.7.1
PATCH 11/13: 0011-STV0900-Query-DVB-frontend-delivery-capabilities
From e83bf5b01b1a5084df3c1a8f8b15c5219be618d2 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Thu, 17 Nov 2011 13:40:49 +0530
Subject: [PATCH 11/13] STV0900: Query DVB frontend delivery capabilities
Override default delivery system information provided by FE_GET_INFO, so
that applications can enumerate delivery systems provided by the frontend.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/dvb/frontends/stv0900_core.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/frontends/stv0900_core.c b/drivers/media/dvb/frontends/stv0900_core.c
index 0ca316d..2b8d78c 100644
--- a/drivers/media/dvb/frontends/stv0900_core.c
+++ b/drivers/media/dvb/frontends/stv0900_core.c
@@ -985,7 +985,16 @@ static int stb0900_get_property(struct dvb_frontend *fe,
struct dtv_property *tvp)
{
dprintk(%s(..)\n, __func__);
-
+ switch (tvp-cmd) {
+ case DTV_ENUM_DELSYS:
+ tvp-u.buffer.data[0] = SYS_DSS;
+ tvp-u.buffer.data[1] = SYS_DVBS;
+ tvp-u.buffer.data[2] = SYS_DVBS2;
+ tvp-u.buffer.len = 3;
+ break;
+ default:
+ break;
+ }
return 0;
}
--
1.7.1
PATCH 12/13: 0012-CXD2820r-Query-DVB-frontend-delivery-capabilities
From 096bca663d076255852b88ce9a87c0f07fa17dec Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Mon, 21 Nov 2011 19:58:03 +0530
Subject: [PATCH 12/13] CXD2820r: Query DVB frontend delivery capabilities
Override default delivery system information provided by FE_GET_INFO, so
that applications can enumerate delivery systems provided by the frontend.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/dvb/frontends/cxd2820r_c.c| 17 +-
drivers/media/dvb/frontends/cxd2820r_core.c | 651 +--
drivers/media/dvb/frontends/cxd2820r_priv.h |5 +-
drivers/media/dvb/frontends/cxd2820r_t.c| 19 +-
drivers/media/dvb/frontends/cxd2820r_t2.c | 20 +-
5 files changed, 265 insertions(+), 447 deletions(-)
diff --git a/drivers/media/dvb/frontends/cxd2820r_c.c b/drivers/media/dvb/frontends/cxd2820r_c.c
index b85f501..f6d0ff7 100644
--- a/drivers/media/dvb/frontends/cxd2820r_c.c
+++ b/drivers/media/dvb/frontends/cxd2820r_c.c
@@ -22,10 +22,11 @@
#include cxd2820r_priv.h
int cxd2820r_set_frontend_c(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *params)
+ struct dvb_frontend_parameters *params)
{
struct cxd2820r_priv *priv = fe-demodulator_priv;
struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ struct tuner_state tstate;
int ret, i;
u8 buf[2];
u16 if_ctl;
@@ -55,8 +56,18 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe,
goto error;
/* program tuner */
- if (fe-ops.tuner_ops.set_params)
- fe-ops.tuner_ops.set_params(fe, params);
+ tstate.delsys = SYS_DVBC_ANNEX_AC;
+ tstate.frequency = c-frequency;
+
+ if (fe-ops.tuner_ops.set_state) {
+ fe-ops.tuner_ops.set_state(fe,
+ DVBFE_TUNER_DELSYS|
+ DVBFE_TUNER_FREQUENCY,
+ tstate);
+ } else {
+ if (fe-ops.tuner_ops.set_params)
+ fe-ops.tuner_ops.set_params(fe, params);
+ }
if (priv-delivery_system != SYS_DVBC_ANNEX_AC) {
for (i = 0; i ARRAY_SIZE(tab); i++) {
diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c b/drivers/media/dvb/frontends/cxd2820r_core.c
index 036480f..5b0120a 100644
--- a/drivers/media/dvb/frontends/cxd2820r_core.c
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c
@@ -240,43 +240,6 @@ error:
return ret;
}
-/* lock FE */
-static int cxd2820r_lock(struct cxd2820r_priv *priv, int active_fe)
-{
- int ret = 0;
- dbg(%s: active_fe=%d, __func__, active_fe);
-
- mutex_lock(priv-fe_lock);
-
- /* -1=NONE, 0=DVB-T/T2, 1=DVB-C */
- if (priv-active_fe == active_fe)
- ;
- else if (priv-active_fe == -1)
- priv-active_fe = active_fe;
- else
- ret = -EBUSY;
-
- mutex_unlock(priv-fe_lock);
-
- return ret;
-}
-
-/* unlock FE */
-static void cxd2820r_unlock(struct cxd2820r_priv *priv, int active_fe)
-{
- dbg(%s: active_fe=%d, __func__, active_fe);
-
- mutex_lock(priv-fe_lock);
-
- /* -1=NONE, 0=DVB-T/T2, 1=DVB-C */
- if (priv-active_fe == active_fe)
- priv-active_fe = -1;
-
- mutex_unlock(priv-fe_lock);
-
- return;
-}
-
/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
{
@@ -284,378 +247,230 @@ u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
}
static int cxd2820r_set_frontend(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *p)
+ struct dvb_frontend_parameters *p)
{
- struct cxd2820r_priv *priv = fe-demodulator_priv;
struct dtv_frontend_properties *c = fe-dtv_property_cache;
int ret;
- dbg(%s: delsys=%d, __func__, fe-dtv_property_cache.delivery_system);
-
- if (fe-ops.info.type == FE_OFDM) {
- /* DVB-T/T2 */
- ret = cxd2820r_lock(priv, 0);
- if (ret)
- return ret;
-
- switch (priv-delivery_system) {
- case SYS_UNDEFINED:
- if (c-delivery_system == SYS_DVBT) {
-/* SLEEP = DVB-T */
-ret = cxd2820r_set_frontend_t(fe, p);
- } else {
-/* SLEEP = DVB-T2 */
-ret = cxd2820r_set_frontend_t2(fe, p);
- }
- break;
- case SYS_DVBT:
- if (c-delivery_system == SYS_DVBT) {
-/* DVB-T = DVB-T */
-ret = cxd2820r_set_frontend_t(fe, p);
- } else if (c-delivery_system == SYS_DVBT2) {
-/* DVB-T = DVB-T2 */
-ret = cxd2820r_sleep_t(fe);
-if (ret)
- break;
-ret = cxd2820r_set_frontend_t2(fe, p);
- }
- break;
- case SYS_DVBT2:
- if (c-delivery_system == SYS_DVBT2) {
-/* DVB-T2 = DVB-T2 */
-ret = cxd2820r_set_frontend_t2(fe, p);
- } else if (c-delivery_system == SYS_DVBT) {
-/* DVB-T2 = DVB-T */
-ret = cxd2820r_sleep_t2(fe);
-if (ret)
- break;
-ret = cxd2820r_set_frontend_t(fe, p);
- }
- break;
- default:
- dbg(%s: error state=%d, __func__,
-priv-delivery_system);
- ret = -EINVAL;
- }
- } else {
- /* DVB-C */
- ret = cxd2820r_lock(priv, 1);
- if (ret)
- return ret;
+ dbg(%s: delsys=%d, __func__, fe-dtv_property_cache.delivery_system);
+ switch (c-delivery_system) {
+ case SYS_DVBT:
+ ret = cxd2820r_init_t(fe);
+ if (ret 0)
+ goto err;
+ ret = cxd2820r_set_frontend_t(fe,
PATCH 13/13: 0013-PCTV290E-Attach-a-single-frontend
From 937c8b2d24ddd6df4af8e19026827a8cb1e3547b Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Mon, 21 Nov 2011 20:15:36 +0530
Subject: [PATCH 13/13] PCTV290E: Attach a single frontend, rather than a frontend each
per delivery system, whereby a multistandard frontend can advertise
all associated delivery systems.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/video/em28xx/em28xx-dvb.c | 27 +--
1 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c b/drivers/media/video/em28xx/em28xx-dvb.c
index cef7a2d..8a12094 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -761,31 +761,22 @@ static int em28xx_dvb_init(struct em28xx *dev)
dev-i2c_adap, kworld_a340_config);
break;
case EM28174_BOARD_PCTV_290E:
- /* MFE
- * FE 0 = DVB-T/T2 + FE 1 = DVB-C, both sharing same tuner. */
- /* FE 0 */
dvb-fe[0] = dvb_attach(cxd2820r_attach,
- em28xx_cxd2820r_config, dev-i2c_adap, NULL);
+ em28xx_cxd2820r_config,
+ dev-i2c_adap,
+ NULL);
if (dvb-fe[0]) {
/* FE 0 attach tuner */
- if (!dvb_attach(tda18271_attach, dvb-fe[0], 0x60,
-dev-i2c_adap, em28xx_cxd2820r_tda18271_config)) {
+ if (!dvb_attach(tda18271_attach,
+ dvb-fe[0],
+ 0x60,
+ dev-i2c_adap,
+ em28xx_cxd2820r_tda18271_config)) {
+
dvb_frontend_detach(dvb-fe[0]);
result = -EINVAL;
goto out_free;
}
- /* FE 1. This dvb_attach() cannot fail. */
- dvb-fe[1] = dvb_attach(cxd2820r_attach, NULL, NULL,
-dvb-fe[0]);
- dvb-fe[1]-id = 1;
- /* FE 1 attach tuner */
- if (!dvb_attach(tda18271_attach, dvb-fe[1], 0x60,
-dev-i2c_adap, em28xx_cxd2820r_tda18271_config)) {
-dvb_frontend_detach(dvb-fe[1]);
-/* leave FE 0 still active */
- }
-
- mfe_shared = 1;
}
break;
case EM2884_BOARD_TERRATEC_H5:
--
1.7.1
Re: PATCH 04/13: 0004-TDA18271-Allow-frontend-to-set-DELSYS
Thank you, Manu... After the Linux Kernel Summit in Prague, I had intentions of solving this exact problem, but you did it first -- good job! I have reviewed the patch to the tda18271 driver, and the changes make good sense to me. I have one question, however: Perhaps my eyes have overlooked something -- I fail to see any code that defines the new set_state callback or any code that calls this new callback within dvb-core (assuming dvb_frontend.c) I also can't find the structure declaration of the tuner_state struct... ... is this patch missing from your series, or did I just overlook it? That missing patch is what interests me most. Once I can see that missing code, I'd like to begin discussion on whether we actually need the additional callback, or if it can simply be handled by the set_params call. Likewise, I'm not exactly sure why we need this affional struct tuner_state ... Perhaps the answer will be self-explanatory once I see the code - maybe no discussion is necessary :-P But this does look good to me so far. I'd be happy to provide my reviewed-by tag once I can see the missing code mentioned above. Best regards, Michael Krufky On Mon, Nov 21, 2011 at 4:06 PM, Manu Abraham abraham.m...@gmail.com wrote: -- 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 04/13: 0004-TDA18271-Allow-frontend-to-set-DELSYS
On 11/22/11, Michael Krufky mkru...@linuxtv.org wrote:
Thank you, Manu... After the Linux Kernel Summit in Prague, I had
intentions of solving this exact problem, but you did it first -- good
job!
I have reviewed the patch to the tda18271 driver, and the changes make
good sense to me. I have one question, however:
Perhaps my eyes have overlooked something -- I fail to see any code
that defines the new set_state callback or any code that calls this
new callback within dvb-core (assuming dvb_frontend.c) I also can't
find the structure declaration of the tuner_state struct... ... is
this patch missing from your series, or did I just overlook it?
I guess more like that. The data structure existed for quite a long
while in dvb_frontend.h and hence you don't find any new changes. Only
delivery and modulation added to it.
That missing patch is what interests me most. Once I can see that
missing code, I'd like to begin discussion on whether we actually need
the additional callback, or if it can simply be handled by the
set_params call. Likewise, I'm not exactly sure why we need this
affional struct tuner_state ... Perhaps the answer will be
self-explanatory once I see the code - maybe no discussion is
necessary :-P
But this does look good to me so far. I'd be happy to provide my
reviewed-by tag once I can see the missing code mentioned above.
The callback is used from within a demodulator context as usual and hence.
eg:
/* program tuner */
- if (fe-ops.tuner_ops.set_params)
- fe-ops.tuner_ops.set_params(fe, params);
+ tstate.delsys = SYS_DVBC_ANNEX_AC;
+ tstate.frequency = c-frequency;
+
+ if (fe-ops.tuner_ops.set_state) {
+ fe-ops.tuner_ops.set_state(fe,
+ DVBFE_TUNER_DELSYS|
+ DVBFE_TUNER_FREQUENCY,
+ tstate);
+ } else {
+ if (fe-ops.tuner_ops.set_params)
+ fe-ops.tuner_ops.set_params(fe, params);
+ }
Best Regards,
Manu
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH 04/13: 0004-TDA18271-Allow-frontend-to-set-DELSYS
On Mon, Nov 21, 2011 at 4:28 PM, Manu Abraham abraham.m...@gmail.com wrote:
On 11/22/11, Michael Krufky mkru...@linuxtv.org wrote:
Thank you, Manu... After the Linux Kernel Summit in Prague, I had
intentions of solving this exact problem, but you did it first -- good
job!
I have reviewed the patch to the tda18271 driver, and the changes make
good sense to me. I have one question, however:
Perhaps my eyes have overlooked something -- I fail to see any code
that defines the new set_state callback or any code that calls this
new callback within dvb-core (assuming dvb_frontend.c) I also can't
find the structure declaration of the tuner_state struct... ... is
this patch missing from your series, or did I just overlook it?
I guess more like that. The data structure existed for quite a long
while in dvb_frontend.h and hence you don't find any new changes. Only
delivery and modulation added to it.
That missing patch is what interests me most. Once I can see that
missing code, I'd like to begin discussion on whether we actually need
the additional callback, or if it can simply be handled by the
set_params call. Likewise, I'm not exactly sure why we need this
affional struct tuner_state ... Perhaps the answer will be
self-explanatory once I see the code - maybe no discussion is
necessary :-P
But this does look good to me so far. I'd be happy to provide my
reviewed-by tag once I can see the missing code mentioned above.
The callback is used from within a demodulator context as usual and hence.
eg:
/* program tuner */
- if (fe-ops.tuner_ops.set_params)
- fe-ops.tuner_ops.set_params(fe, params);
+ tstate.delsys = SYS_DVBC_ANNEX_AC;
+ tstate.frequency = c-frequency;
+
+ if (fe-ops.tuner_ops.set_state) {
+ fe-ops.tuner_ops.set_state(fe,
+ DVBFE_TUNER_DELSYS |
+ DVBFE_TUNER_FREQUENCY,
+ tstate);
+ } else {
+ if (fe-ops.tuner_ops.set_params)
+ fe-ops.tuner_ops.set_params(fe, params);
+ }
Best Regards,
Manu
Manu,
Thank you for explaining -- I found that structure in dvb_frontend.h,
now that you've pointed that out.
I am on board with this change -- it is a positive move in the right
direction. I believe that after this is merged, we may be able to
obsolete and remove the set_params callback. In fact, we can even
obsolete the set_analog_params callback as well, using set_state as
the single entry point for setting the tuner. Of course, one step at
a time -- this is great for now. We should consider the other
optimizations after this has been merged and tested. :-)
Reviewed-by: Michael Krufky mkru...@linuxtv.org
--
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 00/13: Enumerate DVB frontend Delivery System capabilities to identify devices correctly.
On Mon, Nov 21, 2011 at 4:05 PM, Manu Abraham abraham.m...@gmail.com wrote: Hi, As discussed prior, the following changes help to advertise a frontend's delivery system capabilities. Sending out the patches as they are being worked out. The following patch series are applied against media_tree.git after the following commit commit e9eb0dadba932940f721f9d27544a7818b2fa1c5 Author: Hans Verkuil hans.verk...@cisco.com Date: Tue Nov 8 11:02:34 2011 -0300 [media] V4L menu: add submenu for platform devices Regards, Manu I am on board with this change -- it is a positive move in the right direction. I believe that after this is merged, we may be able to obsolete and remove the set_params callback. In fact, we can even obsolete the set_analog_params callback as well, using set_state as the single entry point for setting the tuner. Of course, one step at a time -- this is great for now. We should consider the other optimizations after this has been merged and tested. :-) Reviewed-by: Michael Krufky mkru...@linuxtv.org -- 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 12/13: 0012-CXD2820r-Query-DVB-frontend-delivery-capabilities
Hello
On 11/21/2011 11:09 PM, Manu Abraham wrote:
/* program tuner */
- if (fe-ops.tuner_ops.set_params)
- fe-ops.tuner_ops.set_params(fe, params);
+ tstate.delsys = SYS_DVBC_ANNEX_AC;
+ tstate.frequency = c-frequency;
+
+ if (fe-ops.tuner_ops.set_state) {
+ fe-ops.tuner_ops.set_state(fe,
+ DVBFE_TUNER_DELSYS|
+ DVBFE_TUNER_FREQUENCY,
+ tstate);
I want to raise that point, switch from .set_params() to .set_state()
when programming tuner. I don't see it reasonable to introduce (yes, it
have existed ages but not used) new way to program tuner.
Both demod and tuner got same params;
.set_frontend(struct dvb_frontend *, struct dvb_frontend_parameters *)
.set_params(struct dvb_frontend *, struct dvb_frontend_parameters *)
and can get access to APIv5 property_cache similarly. Both, demod and
tuner, can read all those params that are now passed using .set_state()
There is some new tuner drivers which are already using APIv5.
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 v2] [media] gspca: replaced static allocation by video_device_alloc/video_device_release
On Sun, Nov 20, 2011 at 11:03:21AM +0100, Hans de Goede wrote: NACK again! There is no reason to do this, it just makes the code more complicated without gaining anything. As already commented by Antonio Ospite your commit message lacks the why of this patch / the reason to do such a patch. The diffstat clearly shows it is adding code not removing / simplifying it and it so doing so without any good reasons! Yes, it's true: I omit the the reason in the commit message. The point of the patch was improving readability of the code. But it was altogether wrong, as Jean-Francois patiently explained to me in another thread. Thanks to you too for the patience, Ezequiel. -- 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 12/13: 0012-CXD2820r-Query-DVB-frontend-delivery-capabilities
Hi,
On Tue, Nov 22, 2011 at 3:58 AM, Antti Palosaari cr...@iki.fi wrote:
Hello
On 11/21/2011 11:09 PM, Manu Abraham wrote:
/* program tuner */
- if (fe-ops.tuner_ops.set_params)
- fe-ops.tuner_ops.set_params(fe, params);
+ tstate.delsys = SYS_DVBC_ANNEX_AC;
+ tstate.frequency = c-frequency;
+
+ if (fe-ops.tuner_ops.set_state) {
+ fe-ops.tuner_ops.set_state(fe,
+ DVBFE_TUNER_DELSYS |
+ DVBFE_TUNER_FREQUENCY,
+ tstate);
I want to raise that point, switch from .set_params() to .set_state() when
programming tuner. I don't see it reasonable to introduce (yes, it have
existed ages but not used) new way to program tuner.
I didn't introduce set_state() now. It was there for quite a long
while, as old v5API itself, IIRC.
Both demod and tuner got same params;
.set_frontend(struct dvb_frontend *, struct dvb_frontend_parameters *)
.set_params(struct dvb_frontend *, struct dvb_frontend_parameters *)
The argument passed to set_params: struct dvb_frontend_parameters is
useless for any device that's been around recently. Although one can
get the parameters from the property_cache.
Using set_state(), makes it independant and less kludgy, simplifying
things. on the other hand it may be used with analog as well, llly to
Michael Krufky said.
Eventually, it just provides the tuner an independence from struct
dvb_frontend_parameters (which is rigid) and the frontend cache.
That said, a few tuners already uses the mentioned callback, stb6100,
tda8261, tda665x,
If you imply that you feel overly depressed by the use of the
set_state in the cxd2820r module ;-), then as a workaround, the
parameters required for operation can be retrieved from the property
cache, but then if tuner drivers are cleaned up by someone to remove
obsolete ? set_params, then you wouldn't have any other option, but to
later on fall back to set_state.
I am fine with either way, but for the tuners themselves, set_state
behaves a bit more better as it provides independence from the legacy
dvb_frontend_properties. It takes a bit of time for someone new to
understand that (he cannot use dvb_frontend_properties anymore)
and can get access to APIv5 property_cache similarly. Both, demod and tuner,
can read all those params that are now passed using .set_state()
If you want to pass other parameters, as what exists already in
tuner_state, that is not possible with set_params. If you can't have
the required parameters through a parameters which is passed, but then
why would you want to have such a parameter itself passed in the first
case ?
There is some new tuner drivers which are already using APIv5.
regards
Antti
Eventually it is all a matter of taste. I am fine with either. ;-)
Regards,
Manu
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH 12/13: 0012-CXD2820r-Query-DVB-frontend-delivery-capabilities
On Mon, Nov 21, 2011 at 6:01 PM, Manu Abraham abraham.m...@gmail.com wrote:
Hi,
On Tue, Nov 22, 2011 at 3:58 AM, Antti Palosaari cr...@iki.fi wrote:
Hello
On 11/21/2011 11:09 PM, Manu Abraham wrote:
/* program tuner */
- if (fe-ops.tuner_ops.set_params)
- fe-ops.tuner_ops.set_params(fe, params);
+ tstate.delsys = SYS_DVBC_ANNEX_AC;
+ tstate.frequency = c-frequency;
+
+ if (fe-ops.tuner_ops.set_state) {
+ fe-ops.tuner_ops.set_state(fe,
+ DVBFE_TUNER_DELSYS |
+ DVBFE_TUNER_FREQUENCY,
+ tstate);
I want to raise that point, switch from .set_params() to .set_state() when
programming tuner. I don't see it reasonable to introduce (yes, it have
existed ages but not used) new way to program tuner.
I didn't introduce set_state() now. It was there for quite a long
while, as old v5API itself, IIRC.
Both demod and tuner got same params;
.set_frontend(struct dvb_frontend *, struct dvb_frontend_parameters *)
.set_params(struct dvb_frontend *, struct dvb_frontend_parameters *)
The argument passed to set_params: struct dvb_frontend_parameters is
useless for any device that's been around recently. Although one can
get the parameters from the property_cache.
Using set_state(), makes it independant and less kludgy, simplifying
things. on the other hand it may be used with analog as well, llly to
Michael Krufky said.
Eventually, it just provides the tuner an independence from struct
dvb_frontend_parameters (which is rigid) and the frontend cache.
That said, a few tuners already uses the mentioned callback, stb6100,
tda8261, tda665x,
If you imply that you feel overly depressed by the use of the
set_state in the cxd2820r module ;-), then as a workaround, the
parameters required for operation can be retrieved from the property
cache, but then if tuner drivers are cleaned up by someone to remove
obsolete ? set_params, then you wouldn't have any other option, but to
later on fall back to set_state.
I am fine with either way, but for the tuners themselves, set_state
behaves a bit more better as it provides independence from the legacy
dvb_frontend_properties. It takes a bit of time for someone new to
understand that (he cannot use dvb_frontend_properties anymore)
and can get access to APIv5 property_cache similarly. Both, demod and tuner,
can read all those params that are now passed using .set_state()
If you want to pass other parameters, as what exists already in
tuner_state, that is not possible with set_params. If you can't have
the required parameters through a parameters which is passed, but then
why would you want to have such a parameter itself passed in the first
case ?
There is some new tuner drivers which are already using APIv5.
regards
Antti
Eventually it is all a matter of taste. I am fine with either. ;-)
Regards,
Manu
Antti is correct, this *can* be done by accessing the property cache,
and I would naturally agree with him that we should not add yet a 3rd
entry point for tuning.
However, this set_state is v4l/dvb agnostic. if we go with this
set_state callback, we can in fact eliminate both set_params *and*
set_analog_params callbacks, finally having a single entry point for
setting the tuner.
If the community would prefer to use set_params, I am fine with
that... but I also like the idea of unifying the set_params and
set_analog_params into a single call. If the community wants to see
*that*, then lets go ahead with set_state. I think this is a good
step into that direction.
Agreeing with Manu, it is indeed a matter of taste and I am fine with
either way. If we choose the set_state way, then future steps can
unify the calls into a single entry point -- that would be the best,
ultimately, in my opinion.
Regards,
Mike Krufky
--
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: Cleanup proposal for media/gspca
On Sun, Nov 20, 2011 at 08:24:29AM +0100, Jean-Francois Moine wrote: Hi Ezequiel, It is not a minor patch, but maybe you don't know about object programming. As it is defined, a gspca device _is_ a video device, as a gspca subdriver is a gspca device, and as a video device is a device: each lower structure is contained in a higher one. Your patch defines the gspca structure as a separate entity which is somewhat related to a video device by two reverse pointers. It complexifies the structure accesses, adds more code and hides the nature of a gspca device. Hi Jef, Thanks for the explanation, I have things much clear now. I didn't realize linux coding style enforces so explicitly OOP. I based my patch on tm6000 driver and your previous mail about the -supposedly- ugly cast: gspca_dev = (struct gspca_dev *) video_devdata(file); Now it doesn't seems so ugly, I guess I went too far. Still, maybe the 'container_of' trick could make thins easier to understand. Thanks again for your patience, Ezequiel. -- 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 04/13: 0004-TDA18271-Allow-frontend-to-set-DELSYS
On 21.11.2011 22:06, Manu Abraham wrote:
0004-TDA18271-Allow-frontend-to-set-DELSYS-rather-than-qu.patch
From 2ece38602678ae323450d0e35379147e6e086326 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Sat, 19 Nov 2011 19:50:09 +0530
Subject: [PATCH 04/13] TDA18271: Allow frontend to set DELSYS, rather than
querying fe-ops.info.type
With any tuner that can tune to multiple delivery systems/standards, it does
query fe-ops.info.type to determine frontend type and set the delivery
system type. fe-ops.info.type can handle only 4 delivery systems, viz
FE_QPSK,
FE_QAM, FE_OFDM and FE_ATSC.
The change allows the tuner to be set to any delivery system specified in
fe_delivery_system_t, thereby simplifying a lot of issues.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/common/tuners/tda18271-fe.c | 80
+++
drivers/media/common/tuners/tda18271-priv.h |2 +
2 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/media/common/tuners/tda18271-fe.c
b/drivers/media/common/tuners/tda18271-fe.c
index 3347c5b..6e29faf 100644
--- a/drivers/media/common/tuners/tda18271-fe.c
+++ b/drivers/media/common/tuners/tda18271-fe.c
@@ -928,6 +928,85 @@ fail:
/* -- */
+static int tda18271_set_state(struct dvb_frontend *fe,
+ enum tuner_param param,
+ struct tuner_state *state)
+{
+ struct tda18271_priv *priv = fe-tuner_priv;
+ struct tuner_state *req = priv-request;
+ struct tda18271_std_map *std_map = priv-std;
+ struct tda18271_std_map_item *map;
+ int ret;
+
+ BUG_ON(!priv);
At this point priv has already been dereferenced.
+ if (param DVBFE_TUNER_DELSYS)
+ req-delsys = state-delsys;
+ if (param DVBFE_TUNER_FREQUENCY)
+ req-frequency = state-frequency;
+ if (param DVBFE_TUNER_BANDWIDTH)
+ req-bandwidth = state-bandwidth;
What happens if one of these flags is not set, when the function is
called for the first time? priv-request doesn't seem to get initialized.
Regards,
Andreas
+
+ priv-mode = TDA18271_DIGITAL;
+
+ switch (req-delsys) {
+ case SYS_ATSC:
+ map = std_map-atsc_6;
+ req-bandwidth = 600;
+ break;
+ case SYS_DVBC_ANNEX_B:
+ map = std_map-qam_6;
+ req-bandwidth = 600;
+ break;
+ case SYS_DVBT:
+ case SYS_DVBT2:
+ switch (req-bandwidth) {
+ case 600:
+ map = std_map-dvbt_6;
+ break;
+ case 700:
+ map = std_map-dvbt_7;
+ break;
+ case 800:
+ map = std_map-dvbt_8;
+ break;
+ default:
+ ret = -EINVAL;
+ goto fail;
+ }
+ break;
+ case SYS_DVBC_ANNEX_AC:
+ map = std_map-qam_8;
+ req-bandwidth = 800;
+ break;
+ default:
+ tda_warn(Invalid delivery system!\n);
+ ret = -EINVAL;
+ goto fail;
+ }
+ tda_dbg(Trying to tune .. delsys=%d modulation=%d frequency=%d
bandwidth=%d,
+ req-delsys,
+ req-modulation,
+ req-frequency,
+ req-bandwidth);
+
+ /* When tuning digital, the analog demod must be tri-stated */
+ if (fe-ops.analog_ops.standby)
+ fe-ops.analog_ops.standby(fe);
+
+ ret = tda18271_tune(fe, map, req-frequency, req-bandwidth);
+
+ if (tda_fail(ret))
+ goto fail;
+
+ priv-if_freq = map-if_freq;
+ priv-frequency = req-frequency;
+ priv-bandwidth = (req-delsys == SYS_DVBT || req-delsys == SYS_DVBT2)
?
+req-bandwidth : 0;
+fail:
+ return ret;
+}
+
+
static int tda18271_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
@@ -1249,6 +1328,7 @@ static const struct dvb_tuner_ops tda18271_tuner_ops = {
.init = tda18271_init,
.sleep = tda18271_sleep,
.set_params= tda18271_set_params,
+ .set_state = tda18271_set_state,
.set_analog_params = tda18271_set_analog_params,
.release = tda18271_release,
.set_config= tda18271_set_config,
diff --git a/drivers/media/common/tuners/tda18271-priv.h
b/drivers/media/common/tuners/tda18271-priv.h
index 454c152..bd1bf58 100644
--- a/drivers/media/common/tuners/tda18271-priv.h
+++ b/drivers/media/common/tuners/tda18271-priv.h
@@ -126,6 +126,8 @@ struct tda18271_priv {
u32 frequency;
u32 bandwidth;
+
+ struct tuner_state request;
Re: PATCH 00/13: Enumerate DVB frontend Delivery System capabilities to identify devices correctly.
On 21.11.2011 22:05, Manu Abraham wrote: Hi, As discussed prior, the following changes help to advertise a frontend's delivery system capabilities. Sending out the patches as they are being worked out. The following patch series are applied against media_tree.git after the following commit Patches 7, 9 and 10 semm to be unneeded, because they just set the defaults. Regarding the patches adding SYS_DSS: If I remember correctly, DSS doesn't use MPEG-2 TS packets. Do we have a way to deliver DSS payload to userspace? Regards, Andreas -- 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 04/13: 0004-TDA18271-Allow-frontend-to-set-DELSYS
On Tue, Nov 22, 2011 at 5:34 AM, Andreas Oberritter o...@linuxtv.org wrote:
On 21.11.2011 22:06, Manu Abraham wrote:
0004-TDA18271-Allow-frontend-to-set-DELSYS-rather-than-qu.patch
From 2ece38602678ae323450d0e35379147e6e086326 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Sat, 19 Nov 2011 19:50:09 +0530
Subject: [PATCH 04/13] TDA18271: Allow frontend to set DELSYS, rather than
querying fe-ops.info.type
With any tuner that can tune to multiple delivery systems/standards, it does
query fe-ops.info.type to determine frontend type and set the delivery
system type. fe-ops.info.type can handle only 4 delivery systems, viz
FE_QPSK,
FE_QAM, FE_OFDM and FE_ATSC.
The change allows the tuner to be set to any delivery system specified in
fe_delivery_system_t, thereby simplifying a lot of issues.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
drivers/media/common/tuners/tda18271-fe.c | 80
+++
drivers/media/common/tuners/tda18271-priv.h | 2 +
2 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/media/common/tuners/tda18271-fe.c
b/drivers/media/common/tuners/tda18271-fe.c
index 3347c5b..6e29faf 100644
--- a/drivers/media/common/tuners/tda18271-fe.c
+++ b/drivers/media/common/tuners/tda18271-fe.c
@@ -928,6 +928,85 @@ fail:
/* -- */
+static int tda18271_set_state(struct dvb_frontend *fe,
+ enum tuner_param param,
+ struct tuner_state *state)
+{
+ struct tda18271_priv *priv = fe-tuner_priv;
+ struct tuner_state *req = priv-request;
+ struct tda18271_std_map *std_map = priv-std;
+ struct tda18271_std_map_item *map;
+ int ret;
+
+ BUG_ON(!priv);
At this point priv has already been dereferenced.
True, that check is useless.
+ if (param DVBFE_TUNER_DELSYS)
+ req-delsys = state-delsys;
+ if (param DVBFE_TUNER_FREQUENCY)
+ req-frequency = state-frequency;
+ if (param DVBFE_TUNER_BANDWIDTH)
+ req-bandwidth = state-bandwidth;
What happens if one of these flags is not set, when the function is
called for the first time? priv-request doesn't seem to get initialized.
Request needs to be evaluated, whether it is a valid request for the
tuner operation. Need to fix.
Thanks,
Manu
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH 00/13: Enumerate DVB frontend Delivery System capabilities to identify devices correctly.
On Mon, Nov 21, 2011 at 7:22 PM, Andreas Oberritter o...@linuxtv.org wrote: On 21.11.2011 22:05, Manu Abraham wrote: Hi, As discussed prior, the following changes help to advertise a frontend's delivery system capabilities. Sending out the patches as they are being worked out. The following patch series are applied against media_tree.git after the following commit Patches 7, 9 and 10 semm to be unneeded, because they just set the defaults. Regarding the patches adding SYS_DSS: If I remember correctly, DSS doesn't use MPEG-2 TS packets. Do we have a way to deliver DSS payload to userspace? Regards, Andreas I need this as well for delivering ATSC-MH raw payload to userspace. I propose the following patch (attached) dvb-demux-add-functionality-to-send-raw-payload-to-t.patch Description: Binary data
Re: PATCH 00/13: Enumerate DVB frontend Delivery System capabilities to identify devices correctly.
On Tue, Nov 22, 2011 at 5:52 AM, Andreas Oberritter o...@linuxtv.org wrote: On 21.11.2011 22:05, Manu Abraham wrote: Hi, As discussed prior, the following changes help to advertise a frontend's delivery system capabilities. Sending out the patches as they are being worked out. The following patch series are applied against media_tree.git after the following commit Patches 7, 9 and 10 semm to be unneeded, because they just set the defaults. cx24116 AFAIR handles dss, but no code exists in the driver to handle the same. ds3000, I have no clue tda10071, is a derivative of the CX demods and likely supports DSS, just like the ST ones. but that said no code exists in the driver. As you state, yes, it is pointless to have these 3 patches, but then I thought maybe if someone adds in DSS it would be okay. DSS hasn't been added to most frontends for the reasons - earlier there was no support from the frontend API - need to handle it with demux as well. Well, anyway patch exists, so anyone can add it in later if they need when adding support to the driver. Regarding the patches adding SYS_DSS: If I remember correctly, DSS doesn't use MPEG-2 TS packets. Do we have a way to deliver DSS payload to userspace? Yes, even the SYNC is different, length is different too. Somebody wrote a parser a while back. But nothing happened on that front due to the mentioned 2 reasons. there are 2 options, - send the captured packets as it is to userspace - based on delivery system (dvb-s2 has generic streams as well, other than MPEG2-TS, didn't look at dvb-t2, most likely the same option exists there as well), look for sync and length, send packets to userspace. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v1 0/2] app_offset field for plane format
Hi, At the Media Workshop during the Linux Kernel Summit we discussed the need for an additional field in the plane format struct, which we named the 'app_offset'. This field is intended to allow userspace to reserve a piece of memory at the very beginning of the plane that would be guaranteed not to be touched by kernel or hardware (apart from zeroing it out on allocation, if done by the kernel). This field could be used to store information that would be useful after the buffer has been processed, for example if the buffer were to be passed to another thread/process/module or to different hardware (in pipelines). There already exists a similar field in the plane format struct - data_offset, which should not be confused with this field. Memory reserved using data_offset can be filled by both userspace (for OUTPUT buffers) and driver/hardware (for CAPTURE buffers) and is intended to contain metadata related to the image data stored in the buffer and generated together with it, such as headers, etc. Memory reserved using app_offset, on the other hand, is intended for use solely by userspace and is a way to attach additional information to be read/passed along after the buffer is dequeued and there is no difference in its handling for OUTPUT and CAPTURE types (i.e. just passing it to the driver so it can skip enough memory at the beginning of the buffer). app_offset is to be added to the data_offset, i.e. each plane looks like this: |-- app_offset --|-- data_offset --|-- image data --| Regards, Pawel Osciak Pawel Osciak (2): media: Add app_offset field to the v4l2_plane structure vb2: add support for app_offset field of the v4l2_plane struct Documentation/DocBook/media/v4l/io.xml| 21 - drivers/media/video/v4l2-compat-ioctl32.c | 11 --- drivers/media/video/v4l2-ioctl.c | 10 ++ drivers/media/video/videobuf2-core.c |5 + include/linux/videodev2.h | 18 -- 5 files changed, 55 insertions(+), 10 deletions(-) -- 1.7.7.3 -- 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 v1 1/2] media: Add app_offset field to the v4l2_plane structure
app_offset allows the userspace to reserve memory at the beginning of a
plane that will not be touched by the kernel or hardware.
Signed-off-by: Pawel Osciak pa...@osciak.com
---
Documentation/DocBook/media/v4l/io.xml| 21 -
drivers/media/video/v4l2-compat-ioctl32.c | 11 ---
drivers/media/video/v4l2-ioctl.c | 10 ++
include/linux/videodev2.h | 18 --
4 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/io.xml
b/Documentation/DocBook/media/v4l/io.xml
index 3f47df1..dce648a 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -750,11 +750,30 @@ should set this to 0./entry
entrystructfielddata_offset/structfield/entry
entry/entry
entryOffset in bytes to video data in the plane, if applicable.
+ This offset can be used to indicate that the data in the plane
+ is preceded by additional metadata, such as headers, specific to
+ the current format.
+ If app_offset != 0, this memory comes after the memory reserved
+ with app_offset and start of data = app_offset + data_offset.
+ This offset can be set by either drivers/hardware (for CAPTURE
+ buffers) or userspace (for OUTPUT types).
/entry
/row
row
entry__u32/entry
- entrystructfieldreserved[11]/structfield/entry
+ entrystructfieldapp_offset/structfield/entry
+ entry/entry
+ entryOffset in the plane to the beginning of memory usable by
+ the driver/hardware. Applications may use this field
+ to reserve memory at the beginning of the plane for own
+ use. Neither drivers nor hardware should ever write to
+ the plane before this offset (with the exception of
+ zeroing on allocation, if performed by kernel).
+ /entry
+ /row
+ row
+ entry__u32/entry
+ entrystructfieldreserved[10]/structfield/entry
entry/entry
entryReserved for future use. Should be zeroed by an
application./entry
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index c68531b..9e51e05 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -307,7 +307,8 @@ struct v4l2_plane32 {
compat_long_t userptr;
} m;
__u32 data_offset;
- __u32 reserved[11];
+ __u32 app_offset;
+ __u32 reserved[10];
};
struct v4l2_buffer32 {
@@ -338,9 +339,11 @@ static int get_v4l2_plane32(struct v4l2_plane *up, struct
v4l2_plane32 *up32,
void __user *up_pln;
compat_long_t p;
+ /* bytesused and length */
if (copy_in_user(up, up32, 2 * sizeof(__u32)) ||
+ /* data_offset and app_offset */
copy_in_user(up-data_offset, up32-data_offset,
- sizeof(__u32)))
+ 2 * sizeof(__u32)))
return -EFAULT;
if (memory == V4L2_MEMORY_USERPTR) {
@@ -361,9 +364,11 @@ static int get_v4l2_plane32(struct v4l2_plane *up, struct
v4l2_plane32 *up32,
static int put_v4l2_plane32(struct v4l2_plane *up, struct v4l2_plane32 *up32,
enum v4l2_memory memory)
{
+ /* bytesused and length */
if (copy_in_user(up32, up, 2 * sizeof(__u32)) ||
+ /* data_offset and app_offset */
copy_in_user(up32-data_offset, up-data_offset,
- sizeof(__u32)))
+ 2 * sizeof(__u32)))
return -EFAULT;
/* For MMAP, driver might've set up the offset, so copy it back.
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..7cc9193 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -332,10 +332,12 @@ static void dbgbuf(unsigned int cmd, struct video_device
*vfd,
if (V4L2_TYPE_IS_MULTIPLANAR(p-type) p-m.planes) {
for (i = 0; i p-length; ++i) {
plane = p-m.planes[i];
- dbgarg2(plane %d: bytesused=%d, data_offset=0x%08x
- offset/userptr=0x%08lx, length=%d\n,
- i, plane-bytesused, plane-data_offset,
- plane-m.userptr, plane-length);
+ dbgarg2(plane %d: bytesused=%d, app_offset=0x%08x,
+data_offset=0x%08x, offset/userptr=0x%08lx,
+length=%d\n,
+ i, plane-bytesused, plane-app_offset,
+
[PATCH v1 2/2] vb2: add support for app_offset field of the v4l2_plane struct
The app_offset can only be set by userspace and will be passed by vb2 to
the driver.
Signed-off-by: Pawel Osciak pa...@osciak.com
CC: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/video/videobuf2-core.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 979e544..41cc8e9 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -830,6 +830,11 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb, const
struct v4l2_buffer *b,
}
}
+ /* App offset can only be set by userspace, for all types */
+ for (plane = 0; plane vb-num_planes; ++plane)
+ v4l2_planes[plane].app_offset =
+ b-m.planes[plane].app_offset;
+
if (b-memory == V4L2_MEMORY_USERPTR) {
for (plane = 0; plane vb-num_planes; ++plane) {
v4l2_planes[plane].m.userptr =
--
1.7.7.3
--
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 v1 2/2] vb2: add support for app_offset field of the v4l2_plane struct
Thanks Pawel for this enhancement. The app_offset is needed in the ICS for the
app to store meta data header in recording frame.
--Mingcheng
-Original Message-
From: Pawel Osciak [mailto:pa...@osciak.com]
Sent: Monday, November 21, 2011 9:27 PM
To: linux-media@vger.kernel.org
Cc: Zhu, Mingcheng; hverk...@xs4all.nl; Pawel Osciak; Marek Szyprowski
Subject: [PATCH v1 2/2] vb2: add support for app_offset field of the v4l2_plane
struct
The app_offset can only be set by userspace and will be passed by vb2 to
the driver.
Signed-off-by: Pawel Osciak pa...@osciak.com
CC: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/video/videobuf2-core.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 979e544..41cc8e9 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -830,6 +830,11 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb, const
struct v4l2_buffer *b,
}
}
+ /* App offset can only be set by userspace, for all types */
+ for (plane = 0; plane vb-num_planes; ++plane)
+ v4l2_planes[plane].app_offset =
+ b-m.planes[plane].app_offset;
+
if (b-memory == V4L2_MEMORY_USERPTR) {
for (plane = 0; plane vb-num_planes; ++plane) {
v4l2_planes[plane].m.userptr =
--
1.7.7.3
--
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: good programm for FM radio
Hi I switch back to worked 2.6.38rc2 and write working start helper for gnomeradio: #!/bin/sh sox -q -c 2 -s -r 48000 -t alsa hw:1,0 -t alsa hw:0,0 rate -s -a 44100 dither -s gnomeradio wait gnomeradio t=`pidof sox`; kill $t; It works with dmesg startup tm6000 and tm6000-alsa [ 103.816270] tm6000: Found Beholder Wander DVB-T/TV/FM USB2.0 [ 103.818751] lirc_dev: IR Remote Control driver registered, major 252 [ 103.819789] IR LIRC bridge handler initialized [ 103.822010] Found tm6010 [ 104.573019] tm6000 #0: i2c eeprom 00: 42 59 54 45 12 01 00 02 00 00 00 40 00 60 c0 de BYTE...@.`.. [ 104.685017] tm6000 #0: i2c eeprom 10: 01 00 10 20 40 01 28 03 42 00 65 00 68 00 6f 00 ... @.(.B.e.h.o. [ 104.797017] tm6000 #0: i2c eeprom 20: 6c 00 64 00 65 00 72 00 20 00 49 00 6e 00 74 00 l.d.e.r. .I.n.t. [ 104.909018] tm6000 #0: i2c eeprom 30: 6c 00 2e 00 20 00 4c 00 74 00 64 00 2e 00 ff ff l... .L.t.d. [ 105.021016] tm6000 #0: i2c eeprom 40: 22 03 42 00 65 00 68 00 6f 00 6c 00 64 00 20 00 .B.e.h.o.l.d. . [ 105.133018] tm6000 #0: i2c eeprom 50: 54 00 56 00 20 00 57 00 61 00 6e 00 64 00 65 00 T.V. .W.a.n.d.e. [ 105.245016] tm6000 #0: i2c eeprom 60: 72 00 ff ff ff ff ff ff ff ff 1a 03 56 00 69 00 r...V.i. [ 105.357016] tm6000 #0: i2c eeprom 70: 64 00 65 00 6f 00 43 00 61 00 70 00 74 00 75 00 d.e.o.C.a.p.t.u. [ 105.469015] tm6000 #0: i2c eeprom 80: 72 00 65 00 ff ff ff ff ff ff ff ff ff ff ff ff r.e. [ 105.581016] tm6000 #0: i2c eeprom 90: ff ff ff ff 16 03 30 00 30 00 30 00 30 00 30 00 ..0.0.0.0.0. [ 105.693013] tm6000 #0: i2c eeprom a0: 30 00 32 00 30 00 34 00 31 00 ff ff ff ff ff ff 0.2.0.4.1... [ 105.805017] tm6000 #0: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 105.917015] tm6000 #0: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 106.029017] tm6000 #0: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 106.141018] tm6000 #0: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 106.253017] tm6000 #0: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 106.358018] [ 106.361883] i2c-core: driver [tuner] using legacy suspend method [ 106.361886] i2c-core: driver [tuner] using legacy resume method [ 106.361985] tuner 7-0061: Tuner -1 found with type(s) Radio TV. [ 106.386950] xc5000 7-0061: creating new instance [ 106.413017] xc5000: Successfully identified at address 0x61 [ 106.413021] xc5000: Firmware has not been loaded previously [ 106.465014] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... [ 106.512117] xc5000: firmware read 12401 bytes. [ 106.512121] xc5000: firmware uploading... [ 113.187010] xc5000: firmware upload complete... [ 114.698098] tm6000 #0: registered device video0 [ 114.698144] tm6000 #0: registered device radio0 [ 114.698148] Trident TVMaster TM5600/TM6000/TM6010 USB2 board (Load status: 0) [ 114.698177] usbcore: registered new interface driver tm6000 [ 114.708931] b switch [ 114.708934] tm6000: open called (dev=radio0) [ 114.708935] b user [ 114.708936] b kzalloc [ 114.708937] b private [ 114.708939] b get_res [ 114.708940] b init_analog [ 114.905013] tm6000_set_standard start [ 114.905018] tm6000_config_video_input start [ 114.947015] tm6000_config_video_input stop [ 114.947019] tm6000_config_video_std start [ 115.217014] tm6000_config_video_std stop [ 115.217018] tm6000_set_audio_std start [ 115.301014] b if analog_mode [ 115.301019] b vmalloc_init [ 115.301022] b init_demdec [ 115.355016] b if radio [ 115.443016] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... [ 115.445486] xc5000: firmware read 12401 bytes. [ 115.445488] xc5000: firmware uploading... [ 122.120011] xc5000: firmware upload complete... [ 122.730644] video open stop OK [ 122.730673] b switch [ 122.730677] tm6000: open called (dev=video0) [ 122.730678] b user [ 122.730679] b kzalloc [ 122.730683] b private [ 122.730684] b get_res [ 122.730686] b init_analog [ 122.926013] tm6000_set_standard start [ 122.926018] tm6000_config_video_input start [ 122.968012] tm6000_config_video_input stop [ 122.968016] tm6000_config_video_std start [ 123.238011] tm6000_config_video_std stop [ 123.238016] tm6000_set_audio_std start [ 123.280020] tm6000_set_audio_std stop [ 123.280024] tm6000_set_standard stop [ 123.292012] b if analog_mode [ 123.292014] b vmalloc_init [ 123.292016] b init_demdec [ 123.346011] b if radio [ 123.382010] video open stop OK [ 123.389577] tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) [ 123.395318] tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) [ 123.401067] tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) [ 123.406824] tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) [ 123.412571] tm6000 tm6000_irq_callback :urb
