Re: HVR-930C DVB-T mode report
Hi Mauro, drxk driver seems to have 2 issue with w_scan: - dvb-t tune error while scanning (solved by forcing w_scan to open dvb-t fe without autoscan) - dvb-t scan fail so... we should have an issue that when the driver release dvb-c adapter drxk (or xc5000?) stay in dvb-c mode Can you check if you can replicate my error and if Terratec H5 have same issue? follow the test: I build w_scan 20111011 like you -unplug tuner -replug tuner dmesg says: [ 1030.370462] DVB: registering new adapter (em28xx #0) [ 1030.370470] DVB: registering adapter 0 frontend 0 (DRXK DVB-C)... [ 1030.370689] DVB: registering adapter 0 frontend 1 (DRXK DVB-T)... [ 1030.371393] em28xx #0: Successfully loaded em28xx-dvb - w_scan -a /dev/dvb/adapter0/frontend1 (the autodetect of adapter is disabled) dmesg says: [ 1117.000725] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... [ 1117.005404] xc5000: firmware read 12401 bytes. [ 1117.005410] xc5000: firmware uploading... [ 1117.416085] xc5000: firmware upload complete... However, like Fedrik, I don't get errors on dmesg but w_scan ends with ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! - w_scan -a /dev/dvb/adapter0/frontend1 -I it-All no error on dmesg... - w_scan -f t -c IT Leaving autodetect turned on I get [ 794.964818] drxk: Error -22 on QAMSetSymbolrate [ 794.964827] drxk: Error -22 on SetQAM [ 794.964832] drxk: Error -22 on Start [ 795.164518] drxk: Error -22 on QAMSetSymbolrate [ 795.164528] drxk: Error -22 on SetQAM [ 795.164534] drxk: Error -22 on Start trying scan now... scan -f1 it-All dmesg days [ 2044.103987] drxk: Error -22 on Start [ 2045.293728] drxk: Error -22 on SetQAM [ 2045.293738] drxk: Error -22 on Start [ 2045.431231] drxk: Error -22 on QAMSetSymbolrate [ 2045.431241] drxk: Error -22 on SetQAM [ 2045.431246] drxk: Error -22 on Start 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: HVR-930C DVB-T mode report
On 08-12-2011 22:45, Eddi De Pieri wrote: Hi Mauro... I applied your patch... the patch seems good using scan, but still some issue with w_scan: tune to: 17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE 0x 0x0d49: pmt_pid 0x0102 RAI -- Rai 1 (running) 0x 0x0d4a: pmt_pid 0x0101 RAI -- Rai 2 (running) 0x 0x0d4b: pmt_pid 0x0100 RAI -- Rai 3 TGR Veneto (running) 0x 0x0d53: pmt_pid 0x0118 RAI -- Rai News (running) 0x 0x0d54: pmt_pid 0x0119 Rai -- Rai 3 TGR Emilia Romagna (running) 0x 0x0d4c: pmt_pid 0x0103 Rai -- Rai Radio1 (running) 0x 0x0d4d: pmt_pid 0x0104 Rai -- Rai Radio2 (running) 0x 0x0d4e: pmt_pid 0x0105 Rai -- Rai Radio3 (running) Network Name 'Rai' tune to: 21250:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE 0x 0x0001: pmt_pid 0x0023 TV7 -- TV7 MOVIE (running) 0x 0x0002: pmt_pid 0x002f TV7 -- TV7 DOC (running) 0x 0x0003: pmt_pid 0x002d TV7 -- TV7 SANITA (running) 0x 0x0004: pmt_pid 0x0026 TV7 -- TV7 ITALIA (running) 0x 0x0005: pmt_pid 0x0032 TV7 -- TV7 ATENEO (running) 0x 0x0006: pmt_pid 0x0022 TV7 -- TV7 SPORT (running) 0x 0x000b: pmt_pid 0x002b TV7 -- TV7 AZZURRA (running) Network Name 'Triveneta TV' Good! I'll merge it upstream then. using w_scan still persist issues. Will comment about it on your next email. Here is the results: root@depieri1lnx:~# w_scan -f t -c IT w_scan version 20110616 (compiled for DVB API 5.3) using settings for ITALY DVB aerial DVB-T Europe frontend_type DVB-T, channellist 4 output format vdr-1.6 output charset 'UTF-8', use -Ccharset to override Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - DVB-C DRXK DVB-C: specified was DVB-T - SEARCH NEXT ONE. /dev/dvb/adapter0/frontend1 - DVB-T DRXK DVB-T: good :-) Using DVB-T frontend (adapter /dev/dvb/adapter0/frontend1) -_-_-_-_ Getting frontend capabilities-_-_-_-_ Using DVB API 5.4 frontend 'DRXK DVB-T' supports INVERSION_AUTO QAM_AUTO TRANSMISSION_MODE_AUTO GUARD_INTERVAL_AUTO HIERARCHY_AUTO FEC_AUTO FREQ (47.12MHz ... 865.00MHz) -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Scanning 7MHz frequencies... 177500: (time: 00:00) 184500: (time: 00:03) 191500: (time: 00:06) 198500: (time: 00:09) 205500: (time: 00:12) 212500: (time: 00:15) 219500: (time: 00:17) 226500: (time: 00:20) Scanning 8MHz frequencies... 474000: (time: 00:23) [...] 85: (time: 02:38) 858000: (time: 02:40) ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! dmesg says: [ 794.964818] drxk: Error -22 on QAMSetSymbolrate [ 794.964827] drxk: Error -22 on SetQAM [ 794.964832] drxk: Error -22 on Start [ 795.164518] drxk: Error -22 on QAMSetSymbolrate [ 795.164528] drxk: Error -22 on SetQAM [ 795.164534] drxk: Error -22 on Start -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] MX2: Add platform definitions for eMMa-PrP device.
On Thu, Dec 08, 2011 at 10:58:32AM -0200, Mauro Carvalho Chehab wrote:
On 23-11-2011 13:13, Javier Martin wrote:
eMMa-PrP device included in Freescale i.MX2 chips can also
be used separately to process memory buffers.
This patch is just the arch glue to the driver, so it should be applied via
the
media tree, and likely as patch 2, in order to avoid breaking git bisect.
Yet, I'd like to have the mach-imx maintainer's ack on this.
Acked-by: Sascha Hauer s.ha...@pengutronix.de
Sascha
Regards,
Mauro.
Changes since v2:
- Define imx_add_mx2_emmaprp function which also registers device,
not only alloc.
- Change definition of emma_clk.
- Minor fixes.
Signed-off-by: Javier Martinjavier.mar...@vista-silicon.com
---
arch/arm/mach-imx/clock-imx27.c |2 +-
arch/arm/mach-imx/devices-imx27.h |2 ++
arch/arm/plat-mxc/devices/platform-mx2-camera.c | 18 ++
arch/arm/plat-mxc/include/mach/devices-common.h |2 ++
4 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-imx/clock-imx27.c
b/arch/arm/mach-imx/clock-imx27.c
index 88fe00a..dc2d7a5 100644
--- a/arch/arm/mach-imx/clock-imx27.c
+++ b/arch/arm/mach-imx/clock-imx27.c
@@ -661,7 +661,7 @@ static struct clk_lookup lookups[] = {
_REGISTER_CLOCK(NULL, dma, dma_clk)
_REGISTER_CLOCK(NULL, rtic, rtic_clk)
_REGISTER_CLOCK(NULL, brom, brom_clk)
-_REGISTER_CLOCK(NULL, emma, emma_clk)
+_REGISTER_CLOCK(m2m-emmaprp.0, NULL, emma_clk)
_REGISTER_CLOCK(NULL, slcdc, slcdc_clk)
_REGISTER_CLOCK(imx27-fec.0, NULL, fec_clk)
_REGISTER_CLOCK(NULL, emi, emi_clk)
diff --git a/arch/arm/mach-imx/devices-imx27.h
b/arch/arm/mach-imx/devices-imx27.h
index 2f727d7..28537a5 100644
--- a/arch/arm/mach-imx/devices-imx27.h
+++ b/arch/arm/mach-imx/devices-imx27.h
@@ -50,6 +50,8 @@ extern const struct imx_imx_uart_1irq_data
imx27_imx_uart_data[];
extern const struct imx_mx2_camera_data imx27_mx2_camera_data;
#define imx27_add_mx2_camera(pdata)\
imx_add_mx2_camera(imx27_mx2_camera_data, pdata)
+#define imx27_add_mx2_emmaprp(pdata)\
+imx_add_mx2_emmaprp(imx27_mx2_camera_data)
extern const struct imx_mxc_ehci_data imx27_mxc_ehci_otg_data;
#define imx27_add_mxc_ehci_otg(pdata) \
diff --git a/arch/arm/plat-mxc/devices/platform-mx2-camera.c
b/arch/arm/plat-mxc/devices/platform-mx2-camera.c
index b3f4828..11eace9 100644
--- a/arch/arm/plat-mxc/devices/platform-mx2-camera.c
+++ b/arch/arm/plat-mxc/devices/platform-mx2-camera.c
@@ -62,3 +62,21 @@ struct platform_device *__init imx_add_mx2_camera(
res, data-iobaseemmaprp ? 4 : 2,
pdata, sizeof(*pdata), DMA_BIT_MASK(32));
}
+
+struct platform_device *__init imx_add_mx2_emmaprp(
+const struct imx_mx2_camera_data *data)
+{
+struct resource res[] = {
+{
+.start = data-iobaseemmaprp,
+.end = data-iobaseemmaprp + data-iosizeemmaprp - 1,
+.flags = IORESOURCE_MEM,
+}, {
+.start = data-irqemmaprp,
+.end = data-irqemmaprp,
+.flags = IORESOURCE_IRQ,
+},
+};
+return imx_add_platform_device_dmamask(m2m-emmaprp, 0,
+res, 2, NULL, 0, DMA_BIT_MASK(32));
+}
diff --git a/arch/arm/plat-mxc/include/mach/devices-common.h
b/arch/arm/plat-mxc/include/mach/devices-common.h
index def9ba5..1b2258d 100644
--- a/arch/arm/plat-mxc/include/mach/devices-common.h
+++ b/arch/arm/plat-mxc/include/mach/devices-common.h
@@ -223,6 +223,8 @@ struct imx_mx2_camera_data {
struct platform_device *__init imx_add_mx2_camera(
const struct imx_mx2_camera_data *data,
const struct mx2_camera_platform_data *pdata);
+struct platform_device *__init imx_add_mx2_emmaprp(
+const struct imx_mx2_camera_data *data);
#includemach/mxc_ehci.h
struct imx_mxc_ehci_data {
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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
Hauppauge ImpactVCB-e (cx23885)
Hello, we have been using bttv based framegrabber cards for years now, but slowly computers featuring PCI-slots are starting to extinct now. For this reason we got an ImpactVCB-e card to check if this one could be a future option for our analog capture needs. Unfortunately this cards do not seem to be supported by the cx23885 driver yet (at least by the driver in the mainline kernel). Looking at the sources (cx23885-cards.c) I found that some minor adjustments seem to be needed and just adding the new subvendor ID will probably not be enough. Any suggestion for a patch that I could try my luck with? Would it be a good Idea to add something like this to struct cx23885_subid? .subvendor = 0x0070, .subdevice = 0x7133, .card = CX23885_BOARD_UNKNOWN, BTW, here is what lsusb looks like: 05:00.0 0400: 14f1:8852 (rev 04) Subsystem: 0070:7133 Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at d220 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Express Endpoint, MSI 00 Capabilities: [80] Power Management version 2 Capabilities: [90] Vital Product Data Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [100] Advanced Error Reporting Capabilities: [200] Virtual Channel Regards Sven -- Unix is simple and coherent, but it takes a genius – or at any rate a programmer – to understand and appreciate the simplicity (Dennis M. Ritchie) /me is giggls@ircnet, http://sven.gegg.us/ on the Web -- 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: HVR-930C DVB-T mode report
On 09-12-2011 07:35, Eddi De Pieri wrote: Hi Mauro, drxk driver seems to have 2 issue with w_scan: - dvb-t tune error while scanning (solved by forcing w_scan to open dvb-t fe without autoscan) - dvb-t scan fail so... we should have an issue that when the driver release dvb-c adapter drxk (or xc5000?) stay in dvb-c mode Can you check if you can replicate my error and if Terratec H5 have same issue? follow the test: I build w_scan 20111011 like you -unplug tuner -replug tuner dmesg says: [ 1030.370462] DVB: registering new adapter (em28xx #0) [ 1030.370470] DVB: registering adapter 0 frontend 0 (DRXK DVB-C)... [ 1030.370689] DVB: registering adapter 0 frontend 1 (DRXK DVB-T)... [ 1030.371393] em28xx #0: Successfully loaded em28xx-dvb - w_scan -a /dev/dvb/adapter0/frontend1 (the autodetect of adapter is disabled) dmesg says: [ 1117.000725] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... [ 1117.005404] xc5000: firmware read 12401 bytes. [ 1117.005410] xc5000: firmware uploading... [ 1117.416085] xc5000: firmware upload complete... However, like Fedrik, I don't get errors on dmesg but w_scan ends with ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! - w_scan -a /dev/dvb/adapter0/frontend1 -I it-All no error on dmesg... - w_scan -f t -c IT Leaving autodetect turned on I get [ 794.964818] drxk: Error -22 on QAMSetSymbolrate [ 794.964827] drxk: Error -22 on SetQAM [ 794.964832] drxk: Error -22 on Start [ 795.164518] drxk: Error -22 on QAMSetSymbolrate [ 795.164528] drxk: Error -22 on SetQAM [ 795.164534] drxk: Error -22 on Start That's weird... SetQAM and QAMSetSymbolrate are only called for DVB-C. From DRX-K driver, the only way to get EINVAL on QAMSetSymbolrate is when there would be a division by zero, e. g. symbol rate = 0 or frequency equal to 0. Did a quick test here with HVR-930C, using strace: open(/dev/dvb/adapter0/frontend0, O_RDWR|O_NONBLOCK) = 3 ioctl(3, FE_GET_INFO, 0x635120) = 0 write(2, \t/dev/dvb/adapter0/frontend0 - ..., 92/dev/dvb/adapter0/frontend0 - DVB-C DRXK DVB-C: specified was DVB-T - SEARCH NEXT ONE. ) = 92 close(3)= 0 open(/dev/dvb/adapter0/frontend1, O_RDWR|O_NONBLOCK) = 3 ioctl(3, FE_GET_INFO, 0x635120) = 0 write(2, \t/dev/dvb/adapter0/frontend1 - ..., 52/dev/dvb/adapter0/frontend1 - DVB-T DRXK DVB-T: ) = 52 write(2, good :-)\n, 9good :-) ) = 9 close(3)= 0 ... open(/dev/dvb/adapter0/frontend1, O_RDWR) = 3 write(2, -_-_-_-_ Getting frontend capabi..., 48-_-_-_-_ Getting frontend capabilities-_-_-_-_ ) = 48 ioctl(3, FE_GET_INFO, 0x635120) = 0 ioctl(3, FE_GET_PROPERTY, 0x7fff81f5de70) = 0 ... ioctl(3, FE_SET_PROPERTY, 0x7fff81f5de60) = 0 So far so good, but then drxk tries to use DVB-C, instead of DVB-T: [ 717.260140] drxk: Error -22 on SetQAM [ 717.263858] drxk: Error -22 on Start It seems that there's a bug at the dvb-t on the current version. I'll try to fix it. trying scan now... scan -f1 it-All dmesg days [ 2044.103987] drxk: Error -22 on Start [ 2045.293728] drxk: Error -22 on SetQAM [ 2045.293738] drxk: Error -22 on Start [ 2045.431231] drxk: Error -22 on QAMSetSymbolrate [ 2045.431241] drxk: Error -22 on SetQAM [ 2045.431246] drxk: Error -22 on Start 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: HVR-930C DVB-T mode report
On 09-12-2011 08:46, Mauro Carvalho Chehab wrote:
On 09-12-2011 07:35, Eddi De Pieri wrote:
Hi Mauro,
drxk driver seems to have 2 issue with w_scan:
- dvb-t tune error while scanning (solved by forcing w_scan to open
dvb-t fe without autoscan)
- dvb-t scan fail
so... we should have an issue that when the driver release dvb-c
adapter drxk (or xc5000?) stay in dvb-c mode
Can you check if you can replicate my error and if Terratec H5 have same issue?
follow the test:
I build w_scan 20111011 like you
-unplug tuner
-replug tuner
dmesg says:
[ 1030.370462] DVB: registering new adapter (em28xx #0)
[ 1030.370470] DVB: registering adapter 0 frontend 0 (DRXK DVB-C)...
[ 1030.370689] DVB: registering adapter 0 frontend 1 (DRXK DVB-T)...
[ 1030.371393] em28xx #0: Successfully loaded em28xx-dvb
- w_scan -a /dev/dvb/adapter0/frontend1 (the autodetect of adapter is disabled)
dmesg says:
[ 1117.000725] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
[ 1117.005404] xc5000: firmware read 12401 bytes.
[ 1117.005410] xc5000: firmware uploading...
[ 1117.416085] xc5000: firmware upload complete...
However, like Fedrik, I don't get errors on dmesg but w_scan ends with
ERROR: Sorry - i couldn't get any working frequency/transponder
Nothing to scan!!
- w_scan -a /dev/dvb/adapter0/frontend1 -I it-All
no error on dmesg...
- w_scan -f t -c IT
Leaving autodetect turned on I get
[ 794.964818] drxk: Error -22 on QAMSetSymbolrate
[ 794.964827] drxk: Error -22 on SetQAM
[ 794.964832] drxk: Error -22 on Start
[ 795.164518] drxk: Error -22 on QAMSetSymbolrate
[ 795.164528] drxk: Error -22 on SetQAM
[ 795.164534] drxk: Error -22 on Start
That's weird... SetQAM and QAMSetSymbolrate are only called for DVB-C.
From DRX-K driver, the only way to get EINVAL on QAMSetSymbolrate is when
there would be a division by zero, e. g. symbol rate = 0 or frequency equal to
0.
Did a quick test here with HVR-930C, using strace:
open(/dev/dvb/adapter0/frontend0, O_RDWR|O_NONBLOCK) = 3
ioctl(3, FE_GET_INFO, 0x635120) = 0
write(2, \t/dev/dvb/adapter0/frontend0 - ..., 92 /dev/dvb/adapter0/frontend0 - DVB-C
DRXK DVB-C: specified was DVB-T - SEARCH NEXT ONE.
) = 92
close(3) = 0
open(/dev/dvb/adapter0/frontend1, O_RDWR|O_NONBLOCK) = 3
ioctl(3, FE_GET_INFO, 0x635120) = 0
write(2, \t/dev/dvb/adapter0/frontend1 - ..., 52 /dev/dvb/adapter0/frontend1 - DVB-T
DRXK DVB-T: ) = 52
write(2, good :-)\n, 9good :-)
) = 9
close(3) = 0
...
open(/dev/dvb/adapter0/frontend1, O_RDWR) = 3
write(2, -_-_-_-_ Getting frontend capabi..., 48-_-_-_-_ Getting frontend
capabilities-_-_-_-_
) = 48
ioctl(3, FE_GET_INFO, 0x635120) = 0
ioctl(3, FE_GET_PROPERTY, 0x7fff81f5de70) = 0
...
ioctl(3, FE_SET_PROPERTY, 0x7fff81f5de60) = 0
So far so good, but then drxk tries to use DVB-C, instead of DVB-T:
[ 717.260140] drxk: Error -22 on SetQAM
[ 717.263858] drxk: Error -22 on Start
It seems that there's a bug at the dvb-t on the current version.
I'll try to fix it.
I got it. What happens is that, drx-k is changing the DVB type at the frontend
init, and not when FE_SET_PROPERTY is called. This causes issues with tools
like w_scan that opens both devices.
The enclosed patch should fix it. I can't actually test DVB-T here, but
w_scan is properly switching from/to DVB-T/DVB-C now:
$ dmesg|grep SetO|grep DVB
[ 5003.825868] drxk: SetOperationMode: DVB-C Annex C
[ 5004.944909] drxk: SetOperationMode: DVB-T
[ 5054.158016] drxk: SetOperationMode: DVB-C Annex C
[ 5073.899228] drxk: SetOperationMode: DVB-T
-
[media] drxk: Switch the delivery system on FE_SET_PROPERTY
The DRX-K doesn't change the delivery system at set_properties,
but do it at frontend init. This causes problems on programs like
w_scan that, by default, opens both frontends.
Instead, explicitly set the format when set_parameters callback is
called.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index 95cbc98..c8e0921 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -1847,6 +1847,7 @@ static int SetOperationMode(struct drxk_state *state,
*/
switch (oMode) {
case OM_DVBT:
+ dprintk(1, : DVB-T\n);
state-m_OperationMode = oMode;
status = SetDVBTStandard(state, oMode);
if (status 0)
@@ -1854,6 +1855,8 @@ static int SetOperationMode(struct drxk_state *state,
break;
case OM_QAM_ITU_A: /* fallthrough */
case OM_QAM_ITU_C:
+ dprintk(1, : DVB-C Annex %c\n,
+ (state-m_OperationMode == OM_QAM_ITU_A) ? 'A' : 'C');
state-m_OperationMode = oMode;
status = SetQAMStandard(state, oMode);
if (status 0)
@@ -6183,7 +6186,10 @@ static int drxk_c_init(struct dvb_frontend *fe)
dprintk(1, \n);
if (mutex_trylock(state-ctlock) ==
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Thursday 08 December 2011, Daniel Vetter wrote: c) only allowing streaming mappings, even if those are non-coherent (requiring strict serialization between CPU (in-kernel) and dma users of the buffer) I think only allowing streaming access makes the most sense: - I don't see much (if any need) for the kernel to access a dma_buf - in all current usecases it just contains pixel data and no hw-specific things (like sg tables, command buffers, ..). At most I see the need for the kernel to access the buffer for dma bounce buffers, but that is internal to the dma subsystem (and hence does not need to be exposed). - Userspace can still access the contents through the exporting subsystem (e.g. use some gem mmap support). For efficiency reason gpu drivers are already messing around with cache coherency in a platform specific way (and hence violated the dma api a bit), so we could stuff the mmap coherency in there, too. When we later on extend dma_buf support so that other drivers than the gpu can export dma_bufs, we can then extend the official dma api with already a few drivers with use-patterns around. But I still think that the kernel must not be required to enforce correct access ordering for the reasons outlined in my other mail. I still don't think that's possible. Please explain how you expect to change the semantics of the streaming mapping API to allow multiple mappers without having explicit serialization points that are visible to all users. For simplicity, let's assume a cache coherent system with bounce buffers where map() copies the buffer to a dma area and unmap() copies it back to regular kernel memory. How does a driver know if it can touch the buffer in memory or from DMA at any given point in time? Note that this problem is the same as the cache coherency problem but may be easier to grasp. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
I still don't think that's possible. Please explain how you expect to change the semantics of the streaming mapping API to allow multiple mappers without having explicit serialization points that are visible to all users. For simplicity, let's assume a cache coherent system I would agree. It's not just about barriers but in many cases where you have multiple mappings by hardware devices the actual hardware interface is specific to the devices. Just take a look at the fencing in TTM and the graphics drivers. Its not something the low level API can deal with, it requires high level knowledge. Alan -- 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
Product Order
Hello, I am Manager of SIMKINS LTD. USA, My company is interested in the purchase of your products. Kindly send me an email with details of: *Minimum Order Quantity *Your delivery time *Payment terms *And your products warranty I await to hear from you urgently Mr Stefan Al Simkins. Purchasing Manager. SIMKINS LTD ___ NOCC, http://nocc.sourceforge.net -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 6/7] media: video: introduce face detection driver module
On Fri, Dec 9, 2011 at 7:25 AM, Sylwester Nawrocki snj...@gmail.com wrote: On 12/07/2011 02:40 PM, Ming Lei wrote: I understand the API you mentioned here should belong to kernel internal API, correct me if it is wrong. Yes, I meant the in kernel design, i.e. generic face detection kernel module and an OMAP4 FDIF driver. It makes lots of sense to separate common code in this way, maybe even when there would be only OMAP devices using it. Yes, that is the motivation of the generic FD module. I think we can focus on two use cases for the generic FD now: - one is to detect faces from user space image data - another one is to detect faces in image data generated from HW(SoC internal bus, resize hardware) For OMAP4 hardware, input data is always from physically continuous memory directly, so it is very easy to support the two cases. For the use case 2, if buffer copy is to be avoided, we can use the coming shared dma-buf[1] to pass the image buffer produced by other HW to FD hw directly. Some H/W uses direct data buses to exchange data between processing blocks, and there is no need for additional memory. We only need to manage the data links, for which MC has been designed. For OMAP4 FD, it is not needed to include FD into MC framework since a intermediate buffer is always required. If your HW doesn't belong to this case, what is the output of your HW FD in the link? Also sounds FD results may not be needed at all for use space application in the case. For other FD hardware, if it supports to detect faces in image data from physically continuous memory, I think the patch is OK to support it. If the FD hw doesn't support to detect faces from physically continuous memory, I have some questions: how does user space app to parse the FD result if application can't get the input image data? If user space can Do we need the map of detected objects on a input image in all cases ? For normal cases, I think we need, :-) If an application needs only coordinates of detected object on a video signal to for example, focus on it, trigger some action, or just count detected faces, etc. Perhaps there are more practical similar use cases. Could you provide some practical use cases about these? get image data, how does it connect the image data with FD result? and If hardware provides frame sequence numbers the FD result can be associated with a frame, whether it's passing through H/W interconnect or is located in memory. If FD result is associated with a frame, how can user space get the frame seq if no v4l2 buffer is involved? Without a frame sequence, it is a bit difficult to retrieve FD results from user space. what standard v4l2 ways(v4l2_buffer?) can the app use to describe the image data? We have USERPTR and MMAP memeory buffer for streaming IO, those use v4l2_buffer 1). read()/write() is also used 2), mostly for compressed formats. Except that there are works on shared buffers. If the input image data is from other HW(SoC bus, resizer HW, ...), is the v4l2_buffer needed for the FD HW driver or application? I'm sure now the Samsung devices won't fit in video output node based driver design. They read image data in different ways and also the FD result format is totally different. I think user space will need the FD result, so it is very important to define API to describe the FD result format to user space. And the input about your FD HW result format is certainly helpful to define the API. I'll post exact attributes generated by our FD detection H/W soon. Good news, :-) AFAICS OMAP4 FDIF processes only data stored in memory, thus it seems reasonable to use the videodev interface for passing data to the kernel from user space. But there might be face detection devices that accept data from other H/W modules, e.g. transferred through SoC internal data buses between image processing pipeline blocks. Thus any new interfaces need to be designed with such devices in mind. Also the face detection hardware block might now have an input DMA engine in it, the data could be fed from memory through some other subsystem (e.g. resize/colour converter). Then the driver for that subsystem would implement a video node. I think the direct input image or frame data to FD should be from memory no matter the actual data is from external H/W modules or input DMA because FD will take lot of time to detect faces in one image or frame and FD can't have so much memory to cache several images or frames data. Sorry, I cannot provide much details at the moment, but there exists hardware that reads data from internal SoC buses and even if it uses some sort of cache memory it doesn't necessarily have to be available for the user. Without some hardware background, it is not easy to give a generic FD module design. Yes, please give me some time so I can prepare the list of requirements. Still the FD result is associated with an image frame for such
[PATCH] s5p-g2d: remove two unused variables from the G2D driver
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-g2d/g2d-hw.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/s5p-g2d/g2d-hw.c
b/drivers/media/video/s5p-g2d/g2d-hw.c
index e5249f3..39937cf 100644
--- a/drivers/media/video/s5p-g2d/g2d-hw.c
+++ b/drivers/media/video/s5p-g2d/g2d-hw.c
@@ -27,7 +27,6 @@ void g2d_reset(struct g2d_dev *d)
void g2d_set_src_size(struct g2d_dev *d, struct g2d_frame *f)
{
u32 n;
- u32 stride;
w(f-stride 0x, SRC_STRIDE_REG);
@@ -52,7 +51,6 @@ void g2d_set_src_addr(struct g2d_dev *d, dma_addr_t a)
void g2d_set_dst_size(struct g2d_dev *d, struct g2d_frame *f)
{
u32 n;
- u32 stride;
w(f-stride 0x, DST_STRIDE_REG);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v3 4/4] v4l: Update subdev drivers to handle framesamples parameter
Update the sub-device drivers having a devnode enabled so they properly
handle the new framesamples field of struct v4l2_mbus_framefmt.
These drivers don't support compressed (entropy encoded) formats so the
framesamples field is simply initialized to 0, altogether with the
reserved structure member.
There is a few other drivers that expose a devnode (mt9p031, mt9t001,
mt9v032), but they already implicitly initialize the new data structure
field to 0, so they don't need to be touched.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Hi,
In this version the whole reserved field in struct v4l2_mbus_framefmt
is also cleared, rather than setting only framesamples to 0.
The omap3isp driver changes have been only compile tested.
Thanks,
Sylwester
---
drivers/media/video/noon010pc30.c |5 -
drivers/media/video/omap3isp/ispccdc.c|2 ++
drivers/media/video/omap3isp/ispccp2.c|2 ++
drivers/media/video/omap3isp/ispcsi2.c|2 ++
drivers/media/video/omap3isp/isppreview.c |2 ++
drivers/media/video/omap3isp/ispresizer.c |2 ++
drivers/media/video/s5k6aa.c |2 ++
7 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/noon010pc30.c
b/drivers/media/video/noon010pc30.c
index 50838bf..5af9b60 100644
--- a/drivers/media/video/noon010pc30.c
+++ b/drivers/media/video/noon010pc30.c
@@ -519,13 +519,14 @@ static int noon010_get_fmt(struct v4l2_subdev *sd, struct
v4l2_subdev_fh *fh,
mf = fmt-format;
mutex_lock(info-lock);
+ memset(mf, 0, sizeof(mf));
mf-width = info-curr_win-width;
mf-height = info-curr_win-height;
mf-code = info-curr_fmt-code;
mf-colorspace = info-curr_fmt-colorspace;
mf-field = V4L2_FIELD_NONE;
-
mutex_unlock(info-lock);
+
return 0;
}
@@ -546,12 +547,14 @@ static const struct noon010_format
*noon010_try_fmt(struct v4l2_subdev *sd,
static int noon010_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
struct v4l2_subdev_format *fmt)
{
+ const int offset = offsetof(struct v4l2_mbus_framefmt, framesamples);
struct noon010_info *info = to_noon010(sd);
const struct noon010_frmsize *size = NULL;
const struct noon010_format *nf;
struct v4l2_mbus_framefmt *mf;
int ret = 0;
+ memset(fmt-format + offset, 0, sizeof(fmt-format) - offset);
nf = noon010_try_fmt(sd, fmt-format);
noon010_try_frame_size(fmt-format, size);
fmt-format.colorspace = V4L2_COLORSPACE_JPEG;
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index b0b0fa5..a608149 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -1802,6 +1802,7 @@ ccdc_try_format(struct isp_ccdc_device *ccdc, struct
v4l2_subdev_fh *fh,
unsigned int pad, struct v4l2_mbus_framefmt *fmt,
enum v4l2_subdev_format_whence which)
{
+ const int offset = offsetof(struct v4l2_mbus_framefmt, framesamples);
struct v4l2_mbus_framefmt *format;
const struct isp_format_info *info;
unsigned int width = fmt-width;
@@ -1863,6 +1864,7 @@ ccdc_try_format(struct isp_ccdc_device *ccdc, struct
v4l2_subdev_fh *fh,
*/
fmt-colorspace = V4L2_COLORSPACE_SRGB;
fmt-field = V4L2_FIELD_NONE;
+ memset(fmt + offset, 0, sizeof(*fmt) - offset);
}
/*
diff --git a/drivers/media/video/omap3isp/ispccp2.c
b/drivers/media/video/omap3isp/ispccp2.c
index 904ca8c..a56a6ad 100644
--- a/drivers/media/video/omap3isp/ispccp2.c
+++ b/drivers/media/video/omap3isp/ispccp2.c
@@ -673,6 +673,7 @@ static void ccp2_try_format(struct isp_ccp2_device *ccp2,
struct v4l2_mbus_framefmt *fmt,
enum v4l2_subdev_format_whence which)
{
+ const int offset = offsetof(struct v4l2_mbus_framefmt, framesamples);
struct v4l2_mbus_framefmt *format;
switch (pad) {
@@ -711,6 +712,7 @@ static void ccp2_try_format(struct isp_ccp2_device *ccp2,
fmt-field = V4L2_FIELD_NONE;
fmt-colorspace = V4L2_COLORSPACE_SRGB;
+ memset(fmt + offset, 0, sizeof(*fmt) - offset);
}
/*
diff --git a/drivers/media/video/omap3isp/ispcsi2.c
b/drivers/media/video/omap3isp/ispcsi2.c
index 0c5f1cb..c41443b 100644
--- a/drivers/media/video/omap3isp/ispcsi2.c
+++ b/drivers/media/video/omap3isp/ispcsi2.c
@@ -846,6 +846,7 @@ csi2_try_format(struct isp_csi2_device *csi2, struct
v4l2_subdev_fh *fh,
unsigned int pad, struct v4l2_mbus_framefmt *fmt,
enum v4l2_subdev_format_whence which)
{
+ const int offset = offsetof(struct v4l2_mbus_framefmt, framesamples);
enum v4l2_mbus_pixelcode pixelcode;
struct v4l2_mbus_framefmt *format;
const struct isp_format_info *info;
@@
[PATCH] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
The DRX-K doesn't change the delivery system at set_properties,
but do it at frontend init. This causes problems on programs like
w_scan that, by default, opens both frontends.
Instead, explicitly set the format when set_parameters callback is
called.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/drxk_hard.c | 32 ++
drivers/media/dvb/frontends/drxk_hard.h |2 +
2 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index 95cbc98..c8e0921 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -1847,6 +1847,7 @@ static int SetOperationMode(struct drxk_state *state,
*/
switch (oMode) {
case OM_DVBT:
+ dprintk(1, : DVB-T\n);
state-m_OperationMode = oMode;
status = SetDVBTStandard(state, oMode);
if (status 0)
@@ -1854,6 +1855,8 @@ static int SetOperationMode(struct drxk_state *state,
break;
case OM_QAM_ITU_A: /* fallthrough */
case OM_QAM_ITU_C:
+ dprintk(1, : DVB-C Annex %c\n,
+ (state-m_OperationMode == OM_QAM_ITU_A) ? 'A' : 'C');
state-m_OperationMode = oMode;
status = SetQAMStandard(state, oMode);
if (status 0)
@@ -6183,7 +6186,10 @@ static int drxk_c_init(struct dvb_frontend *fe)
dprintk(1, \n);
if (mutex_trylock(state-ctlock) == 0)
return -EBUSY;
- SetOperationMode(state, OM_QAM_ITU_A);
+ if (state-m_itut_annex_c)
+ SetOperationMode(state, OM_QAM_ITU_C);
+ else
+ SetOperationMode(state, OM_QAM_ITU_A);
return 0;
}
@@ -6219,14 +6225,6 @@ 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);
if (fe-ops.tuner_ops.set_params)
@@ -6235,6 +6233,22 @@ static int drxk_set_parameters(struct dvb_frontend *fe,
fe-ops.i2c_gate_ctrl(fe, 0);
state-param = *p;
fe-ops.tuner_ops.get_if_frequency(fe, IF);
+
+ /*
+* Make sure that the frontend is on the right state
+*/
+
+ if (fe-ops.info.type == FE_QAM) {
+ if (fe-dtv_property_cache.rolloff == ROLLOFF_13) {
+ state-m_itut_annex_c = true;
+ SetOperationMode(state, OM_QAM_ITU_C);
+ } else {
+ state-m_itut_annex_c = false;
+ SetOperationMode(state, OM_QAM_ITU_A);
+ }
+ } else
+ SetOperationMode(state, OM_DVBT);
+
Start(state, 0, IF);
/* printk(KERN_DEBUG drxk: %s IF=%d done\n, __func__, IF); */
diff --git a/drivers/media/dvb/frontends/drxk_hard.h
b/drivers/media/dvb/frontends/drxk_hard.h
index a05c32e..85a423f 100644
--- a/drivers/media/dvb/frontends/drxk_hard.h
+++ b/drivers/media/dvb/frontends/drxk_hard.h
@@ -263,6 +263,8 @@ struct drxk_state {
u8 m_TSDataStrength;
u8 m_TSClockkStrength;
+ bool m_itut_annex_c; /* If true, uses ITU-T DVB-C Annex C,
instead of Annex A */
+
enum DRXMPEGStrWidth_t m_widthSTR;/** MPEG start width */
u32m_mpegTsStaticBitrate; /** Maximum bitrate in b/s in
case
static clockrate is
selected */
--
1.7.8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
On 12/09/2011 08:20 PM, Mauro Carvalho Chehab wrote: The DRX-K doesn't change the delivery system at set_properties, but do it at frontend init. This causes problems on programs like w_scan that, by default, opens both frontends. Instead, explicitly set the format when set_parameters callback is called. May I ask why you don't use mfe_shared flag instead? 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
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:Fri Dec 9 19:00:26 CET 2011 git hash:2bf936290baff2507763a2540cd9029e70ae39e2 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS 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: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The 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] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
On 09-12-2011 16:26, Antti Palosaari wrote: On 12/09/2011 08:20 PM, Mauro Carvalho Chehab wrote: The DRX-K doesn't change the delivery system at set_properties, but do it at frontend init. This causes problems on programs like w_scan that, by default, opens both frontends. Instead, explicitly set the format when set_parameters callback is called. May I ask why you don't use mfe_shared flag instead? Tested with it. Works. It takes a little more time to switch, but the solution will be cleaner. version 2 will follow. 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
[PATCHv2] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
The DRX-K doesn't change the delivery system at set_properties,
but do it at frontend init. This causes problems on programs like
w_scan that, by default, opens both frontends.
Use adap-mfe_shared in order to prevent this, and be sure that Annex A
or C are properly selected.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
v2: Use mfe_shared
drivers/media/dvb/frontends/drxk_hard.c | 16 ++--
drivers/media/dvb/frontends/drxk_hard.h |2 ++
drivers/media/video/em28xx/em28xx-dvb.c |4
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index 95cbc98..388b815 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -1847,6 +1847,7 @@ static int SetOperationMode(struct drxk_state *state,
*/
switch (oMode) {
case OM_DVBT:
+ dprintk(1, : DVB-T\n);
state-m_OperationMode = oMode;
status = SetDVBTStandard(state, oMode);
if (status 0)
@@ -1854,6 +1855,8 @@ static int SetOperationMode(struct drxk_state *state,
break;
case OM_QAM_ITU_A: /* fallthrough */
case OM_QAM_ITU_C:
+ dprintk(1, : DVB-C Annex %c\n,
+ (state-m_OperationMode == OM_QAM_ITU_A) ? 'A' : 'C');
state-m_OperationMode = oMode;
status = SetQAMStandard(state, oMode);
if (status 0)
@@ -6183,7 +6186,10 @@ static int drxk_c_init(struct dvb_frontend *fe)
dprintk(1, \n);
if (mutex_trylock(state-ctlock) == 0)
return -EBUSY;
- SetOperationMode(state, OM_QAM_ITU_A);
+ if (state-m_itut_annex_c)
+ SetOperationMode(state, OM_QAM_ITU_C);
+ else
+ SetOperationMode(state, OM_QAM_ITU_A);
return 0;
}
@@ -6219,13 +6225,11 @@ 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-ops.info.type == FE_QAM) {
if (fe-dtv_property_cache.rolloff == ROLLOFF_13)
- state-m_OperationMode = OM_QAM_ITU_C;
+ state-m_itut_annex_c = true;
else
- state-m_OperationMode = OM_QAM_ITU_A;
- }
+ state-m_itut_annex_c = false;
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
diff --git a/drivers/media/dvb/frontends/drxk_hard.h
b/drivers/media/dvb/frontends/drxk_hard.h
index a05c32e..85a423f 100644
--- a/drivers/media/dvb/frontends/drxk_hard.h
+++ b/drivers/media/dvb/frontends/drxk_hard.h
@@ -263,6 +263,8 @@ struct drxk_state {
u8 m_TSDataStrength;
u8 m_TSClockkStrength;
+ bool m_itut_annex_c; /* If true, uses ITU-T DVB-C Annex C,
instead of Annex A */
+
enum DRXMPEGStrWidth_t m_widthSTR;/** MPEG start width */
u32m_mpegTsStaticBitrate; /** Maximum bitrate in b/s in
case
static clockrate is
selected */
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c
b/drivers/media/video/em28xx/em28xx-dvb.c
index 7f0592c..3868c1e 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -899,6 +899,8 @@ static int em28xx_dvb_init(struct em28xx *dev)
dvb-fe[0]-ops.tuner_ops,
sizeof(dvb-fe[0]-ops.tuner_ops));
+ mfe_shared = 1;
+
break;
}
case EM2884_BOARD_TERRATEC_H5:
@@ -935,6 +937,8 @@ static int em28xx_dvb_init(struct em28xx *dev)
dvb-fe[0]-ops.tuner_ops,
sizeof(dvb-fe[0]-ops.tuner_ops));
+ mfe_shared = 1;
+
break;
case EM28174_BOARD_PCTV_460E:
/* attach demod */
--
1.7.8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
On 12/09/2011 08:58 PM, Mauro Carvalho Chehab wrote: On 09-12-2011 16:26, Antti Palosaari wrote: On 12/09/2011 08:20 PM, Mauro Carvalho Chehab wrote: The DRX-K doesn't change the delivery system at set_properties, but do it at frontend init. This causes problems on programs like w_scan that, by default, opens both frontends. Instead, explicitly set the format when set_parameters callback is called. May I ask why you don't use mfe_shared flag instead? Tested with it. Works. It takes a little more time to switch, but the solution will be cleaner. version 2 will follow. Yes, there is kind of loop timer which tries to take FE and swithing takes second or two because it waits FE is freed. I looked it when I did MFE and I did not understood why it was done like that. cxd2820r has earlier simple lock (inside of demod driver) that just returned error immediately when busy. It is a little bit mystery for me why mfe_shared has that kind of waiting mechanism. Could someone explain reason for that? 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: [RFC] Resolution change support in video codecs in v4l2
Hi Kamil, On Tue, Dec 06, 2011 at 04:03:33PM +0100, Kamil Debski wrote: ... The user space still wants to be able to show these buffers, so a new flag would likely be required --- V4L2_BUF_FLAG_READ_ONLY, for example. Huh? Assuming a capture device, when kernel makes a buffer available to userspace, kernel should not touch on it anymore (not even for read - although reading from it probably won't cause any issues, as video applications in general don't write into those buffers). The opposite is true for output devices: once userspace fills it, and queues, it should not touch that buffer again. This is part of the queue/dequeue logic. I can't see any need for an extra flag to explicitly say that. There is a reason to do so. An example of this is below. The memory-to-memory device has two queues, output can capture. A video decoder memory-to-memory device's output queue handles compressed video and the capture queue provides the application decoded frames. Certain frames in the stream are key frames, meaning that the decoding of the following non-key frames requires access to the key frame. The number of non-key frame can be relatively large, say 16, depending on the codec. If the user should wait for all the frames to be decoded before the key frame can be shown, then either the key frame is to be skipped or delayed. Both of the options are highly undesirable. I don't think that such a delay is worrisome. This is only initial delay. The hw will process these N buffers and after that it works exactly the same as it would without the delay in terms of processing time. Well, yes, but consider that the decoder also processes key frames when the decoding is in progress. The dequeueing of the key frames (and any further frames as long as the key frame is needed by the decoder) will be delayed until the key frame is no longer required. You need extra buffers to cope with such a situation, and in the worst case, or when the decoder is just as fast as you want to show the frames on the display, you need double the amount of buffers compared to what you'd really need for decoding. To make matters worse, this tends to happen at largest resolutions. I think we'd like to avoid this. -- 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: [RFC] Resolution change support in video codecs in v4l2
On Wed, Dec 07, 2011 at 12:12:08PM +0100, Kamil Debski wrote: From: Sakari Ailus [mailto:sakari.ai...@iki.fi] Sent: 06 December 2011 23:42 [...] That's a good point. It's more related to changes in stream properties --- the frame rate of the stream could change, too. That might be when you could like to have more buffers in the queue. I don't think this is critical either. This could also depend on the properties of the codec. Again, I'd wish a comment from someone who knows codecs well. Some codecs need to be able to access buffers which have already been decoded to decode more buffers. Key frames, simply. Ok, but let's not add unneeded things at the API if you're not sure. If we have such need for a given hardware, then add it. Otherwise, keep it simple. This is not so much dependent on hardware but on the standards which the cdoecs implement. Could you please elaborate it? On what scenario this is needed? This is a property of the stream, not a property of the decoder. To reconstruct each frame, a part of the stream is required and already decoded frames may be used to accelerate the decoding. What those parts are. depends on the codec, not a particular implementation. They are not used to accelerate decoding. They are used to predict what should be displayed. If that frame is missing or modified it will cause corruption in consecutive frames. I want to make it clear - they are necessary, not optional to accelerate decoding speed. I think we're talking about the same thing. They are being used to accelerate it --- instead of reconstructing the previous frame from the compressed stream, the codecjust reuses it. In practice this is always done and the implementations probably require it. -- 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: [PATCHv2] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
Hi, v2: Use mfe_shared on hvr930c this patch solve the commutation issue of frontend. still persist same issue like Fredrik on w_scan. scan still works perfectly... root@depieri1lnx:~# w_scan -f t -c IT w_scan version 20110616 (compiled for DVB API 5.3) using settings for ITALY DVB aerial DVB-T Europe frontend_type DVB-T, channellist 4 output format vdr-1.6 output charset 'UTF-8', use -C charset to override Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - DVB-C DRXK DVB-C: specified was DVB-T - SEARCH NEXT ONE. /dev/dvb/adapter0/frontend1 - DVB-T DRXK DVB-T: good :-) Using DVB-T frontend (adapter /dev/dvb/adapter0/frontend1) -_-_-_-_ Getting frontend capabilities-_-_-_-_ Using DVB API 5.4 frontend 'DRXK DVB-T' supports INVERSION_AUTO QAM_AUTO TRANSMISSION_MODE_AUTO GUARD_INTERVAL_AUTO HIERARCHY_AUTO FEC_AUTO FREQ (47.12MHz ... 865.00MHz) -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Scanning 7MHz frequencies... [...] 858000: (time: 03:10) (time: 03:13) ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! this verbose mode seems interesting but I don't figure out why i get timeout. 177500: (time: 00:04) set_frontend: using DVB API 5.4 (time: 00:06) set_frontend: using DVB API 5.4 signal ok: QAM_AUTO f = 177500 kHz I999B7C999D999T999G999Y999 NIT (actual TS) new transponder: (QAM_64 f = 160 kHz I999B8C34D0T8G16Y0) Info: NIT(other) filter timeout -- 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: [PATCHv2] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
On 09-12-2011 18:04, Eddi De Pieri wrote: Hi, v2: Use mfe_shared on hvr930c this patch solve the commutation issue of frontend. Ok, good. One issue solved. still persist same issue like Fredrik on w_scan. scan still works perfectly... root@depieri1lnx:~# w_scan -f t -c IT w_scan version 20110616 (compiled for DVB API 5.3) using settings for ITALY DVB aerial DVB-T Europe frontend_type DVB-T, channellist 4 output format vdr-1.6 output charset 'UTF-8', use -Ccharset to override Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - DVB-C DRXK DVB-C: specified was DVB-T - SEARCH NEXT ONE. /dev/dvb/adapter0/frontend1 - DVB-T DRXK DVB-T: good :-) Using DVB-T frontend (adapter /dev/dvb/adapter0/frontend1) -_-_-_-_ Getting frontend capabilities-_-_-_-_ Using DVB API 5.4 frontend 'DRXK DVB-T' supports INVERSION_AUTO QAM_AUTO TRANSMISSION_MODE_AUTO GUARD_INTERVAL_AUTO HIERARCHY_AUTO FEC_AUTO FREQ (47.12MHz ... 865.00MHz) -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Scanning 7MHz frequencies... [...] 858000: (time: 03:10) (time: 03:13) ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! this verbose mode seems interesting but I don't figure out why i get timeout. 177500: (time: 00:04) set_frontend: using DVB API 5.4 (time: 00:06) set_frontend: using DVB API 5.4 signal ok: QAM_AUTO f = 177500 kHz I999B7C999D999T999G999Y999 NIT (actual TS) new transponder: (QAM_64 f = 160 kHz I999B8C34D0T8G16Y0) Info: NIT(other) filter timeout Try to use w_scan with -F parameter, to increase the timeout. Maybe this issue is due to a smaller timeout on w_scan, when compared with scan. If this doesn't help, then you'll need to figure out what w_scan is doing different than scan. 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
On 09-12-2011 17:08, Antti Palosaari wrote: On 12/09/2011 08:58 PM, Mauro Carvalho Chehab wrote: On 09-12-2011 16:26, Antti Palosaari wrote: On 12/09/2011 08:20 PM, Mauro Carvalho Chehab wrote: The DRX-K doesn't change the delivery system at set_properties, but do it at frontend init. This causes problems on programs like w_scan that, by default, opens both frontends. Instead, explicitly set the format when set_parameters callback is called. May I ask why you don't use mfe_shared flag instead? Tested with it. Works. It takes a little more time to switch, but the solution will be cleaner. version 2 will follow. Yes, there is kind of loop timer which tries to take FE and swithing takes second or two because it waits FE is freed. I looked it when I did MFE and I did not understood why it was done like that. cxd2820r has earlier simple lock (inside of demod driver) that just returned error immediately when busy. It is a little bit mystery for me why mfe_shared has that kind of waiting mechanism. Still, it doesn't make much sense, at least on w_scan, as the only thing that is called with each adapter is FE_GET_INFO: open(/dev/dvb/adapter0/frontend0, O_RDWR|O_NONBLOCK) = 3 ioctl(3, FE_GET_INFO, 0x635120) = 0 write(2, \t/dev/dvb/adapter0/frontend0 - ..., 92/dev/dvb/adapter0/frontend0 - DVB-C DRXK DVB-C: specified was DVB-T - SEARCH NEXT ONE. ) = 92 close(3)= 0 open(/dev/dvb/adapter0/frontend1, O_RDWR|O_NONBLOCK) = 3 ioctl(3, FE_GET_INFO, 0x635120) = 0 write(2, \t/dev/dvb/adapter0/frontend1 - ..., 52/dev/dvb/adapter0/frontend1 - DVB-T DRXK DVB-T: ) = 52 write(2, good :-)\n, 9good :-) ) = 9 close(3)= 0 Still, the second open takes about 4 seconds to complete, _even_ with O_NONBLOCK. There's something bad there, as it is violating POSIX. Could someone explain reason for that? I dunno, but I think this needs to be fixed, at least when the frontend is opened with O_NONBLOCK. Regards, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
On Fri, Dec 9, 2011 at 5:11 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Could someone explain reason for that? I dunno, but I think this needs to be fixed, at least when the frontend is opened with O_NONBLOCK. Are you doing the drx-k firmware load on dvb_init()? That could easily take 4 seconds. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: On Friday 02 December 2011, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. [...] + return dmabuf; +} +EXPORT_SYMBOL(dma_buf_export); I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL, because it's really a low-level function that I would expect to get used by in-kernel subsystems providing the feature to users and having back-end drivers, but it's not the kind of thing we want out-of-tree drivers to mess with. Is this really necessary? If this is intended to be a lowest-common-denominator between many drivers to allow buffer sharing, it seems like it needs to be able to be usable by all drivers. If the interface is not accessible then I fear many drivers will be forced to continue to roll their own buffer sharing mechanisms (which is exactly what we're trying to avoid here, needless to say). - Robert -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
On 09-12-2011 20:33, Devin Heitmueller wrote: On Fri, Dec 9, 2011 at 5:11 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Could someone explain reason for that? I dunno, but I think this needs to be fixed, at least when the frontend is opened with O_NONBLOCK. Are you doing the drx-k firmware load on dvb_init()? That could easily take 4 seconds. No. The firmware were opened previously. This is what happens at the driver: (frontend0 open - DVB-C) [ 5177.932326] drxk: drxk_c_init [ 5177.932330] drxk: SetOperationMode [ 5177.932691] drxk: drxk_gate_ctrlenable [ 5177.932695] drxk: ConfigureI2CBridge [ 5177.932697] xc5000: xc5000_init() [ 5177.936565] xc5000: xc5000_is_firmware_loaded() returns True id = 0x1388 [ 5177.943306] xc5000: xc_initialize() [ 5178.187199] xc5000: *** ADC envelope (0-1023) = 4 [ 5178.192569] xc5000: *** Frequency error = 0 Hz [ 5178.197566] xc5000: *** Lock status (0-Wait, 1-Locked, 2-No-signal) = 1 [ 5178.205291] xc5000: *** HW: V03.02, FW: V01.06.0072 [ 5178.210662] xc5000: *** Horizontal sync frequency = 15473 Hz [ 5178.216909] xc5000: *** Frame lines = 789 [ 5178.221659] xc5000: *** Quality (0:8dB, 7:56dB) = 9 [ 5178.226753] drxk: drxk_gate_ctrldisable [ 5178.226755] drxk: ConfigureI2CBridge (frontend1 open - DVB-T) [ 5181.224873] drxk: drxk_gate_ctrlenable [ 5181.224877] drxk: ConfigureI2CBridge [ 5181.224880] xc5000: xc5000_sleep() [ 5181.228327] xc5000: xc5000_TunerReset() [ 5181.232204] drxk: drxk_gate_ctrldisable [ 5181.232205] drxk: ConfigureI2CBridge [ 5181.232207] drxk: drxk_c_sleep [ 5181.232209] drxk: ShutDown [ 5181.232211] drxk: MPEGTSStop [ 5181.731673] drxk: drxk_t_init [ 5181.731677] drxk: SetOperationMode [ 5181.732101] drxk: MPEGTSStop [ 5181.734075] drxk: PowerDownQAM [ 5181.735075] drxk: scu_command [ 5181.737970] drxk: SetIqmAf [ 5181.738948] drxk: SetOperationMode: DVB-T [ 5181.738950] drxk: SetDVBTStandard [ 5181.738952] drxk: PowerUpDVBT [ 5181.738954] drxk: CtrlPowerMode [ 5181.738956] drxk: PowerUpDevice [ 5181.740321] drxk: DVBTEnableOFDMTokenRing [ 5181.741947] drxk: SwitchAntennaToDVBT [ 5181.741949] drxk: scu_command [ 5181.744718] drxk: scu_command [ 5181.750317] drxk: SetIqmAf [ 5181.755439] drxk: BLChainCmd [ 5181.760710] drxk: ADCSynchronization [ 5181.760713] drxk: ADCSyncMeasurement [ 5181.763596] drxk: SetPreSaw [ 5181.764309] drxk: SetAgcRf [ 5181.766433] drxk: SetAgcIf [ 5181.773183] drxk: MPEGTSDtoSetup [ 5181.777948] drxk: DVBTActivatePresets [ 5181.777951] drxk: DVBTCtrlSetIncEnable [ 5181.778301] drxk: DVBTCtrlSetFrEnable [ 5181.778703] drxk: DVBTCtrlSetEchoThreshold [ 5181.779697] drxk: DVBTCtrlSetEchoThreshold [ 5181.781053] drxk: drxk_gate_ctrlenable [ 5181.781056] drxk: ConfigureI2CBridge [ 5181.781058] xc5000: xc5000_init() [ 5181.785050] xc5000: xc5000_is_firmware_loaded() returns True id = 0x1388 [ 5181.791790] xc5000: xc_initialize() [ 5182.041187] xc5000: *** ADC envelope (0-1023) = 4 [ 5182.046559] xc5000: *** Frequency error = 0 Hz [ 5182.051557] xc5000: *** Lock status (0-Wait, 1-Locked, 2-No-signal) = 1 [ 5182.059448] xc5000: *** HW: V03.02, FW: V01.06.0072 [ 5182.065154] xc5000: *** Horizontal sync frequency = 14817 Hz [ 5182.071424] xc5000: *** Frame lines = 1283 [ 5182.076273] xc5000: *** Quality (0:8dB, 7:56dB) = 9 [ 5182.081366] drxk: drxk_gate_ctrldisable [ 5182.081368] drxk: ConfigureI2CBridge [ 5185.079823] drxk: drxk_gate_ctrlenable [ 5185.079827] drxk: ConfigureI2CBridge [ 5185.079830] xc5000: xc5000_sleep() [ 5185.083276] xc5000: xc5000_TunerReset() [ 5185.087104] drxk: drxk_gate_ctrldisable [ 5185.087107] drxk: ConfigureI2CBridge [ 5185.087111] drxk: drxk_t_sleep [ 5185.087323] drxk: drxk_c_init [ 5185.087326] drxk: SetOperationMode [ 5185.087778] drxk: MPEGTSStop [ 5185.089993] drxk: PowerDownDVBT [ 5185.090780] drxk: scu_command [ 5185.094100] drxk: scu_command [ 5185.098219] drxk: SetIqmAf [ 5185.099221] drxk: CtrlPowerMode [ 5185.099223] drxk: MPEGTSStop [ 5185.101218] drxk: PowerDownDVBT [ 5185.101854] drxk: scu_command [ 5185.105090] drxk: scu_command [ 5185.109215] drxk: SetIqmAf [ 5185.110215] drxk: DVBTEnableOFDMTokenRing [ 5185.112566] drxk: SetOperationMode: DVB-C Annex C [ 5185.112568] drxk: SetQAMStandard [ 5185.112570] drxk: SwitchAntennaToQAM [ 5185.112572] drxk: PowerUpQAM [ 5185.112574] drxk: CtrlPowerMode [ 5185.112575] drxk: QAMResetQAM [ 5185.112962] drxk: scu_command [ 5185.116838] drxk: BLChainCmd [ 5185.127954] drxk: SetIqmAf [ 5185.129306] drxk: ADCSynchronization [ 5185.129308] drxk: ADCSyncMeasurement [ 5185.132949] drxk: InitAGC [ 5185.149315] drxk: SetPreSaw [ 5185.149721] drxk: SetAgcRf [ 5185.151720] drxk: SetAgcIf [ 5185.155817] drxk: drxk_gate_ctrlenable [ 5185.155820] drxk: ConfigureI2CBridge [ 5185.155822] xc5000: xc5000_init() [ 5185.159694] xc5000: xc5000_is_firmware_loaded() returns True id = 0x1388 [ 5185.166432] xc5000: xc_initialize() [ 5185.416305] xc5000: *** ADC envelope (0-1023) = 4 [ 5185.421593] xc5000: *** Frequency error = 0 Hz [
Re: [PATCH] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
On 09-12-2011 21:37, Mauro Carvalho Chehab wrote:
On 09-12-2011 20:33, Devin Heitmueller wrote:
On Fri, Dec 9, 2011 at 5:11 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Could someone explain reason for that?
I dunno, but I think this needs to be fixed, at least when the frontend
is opened with O_NONBLOCK.
Are you doing the drx-k firmware load on dvb_init()? That could
easily take 4 seconds.
No. The firmware were opened previously.
Maybe the delay is due to this part of dvb_frontend.c:
static int dvb_mfe_wait_time = 5;
...
int mferetry = (dvb_mfe_wait_time 1);
mutex_unlock (adapter-mfe_lock);
while (mferetry-- (mfedev-users != -1 ||
mfepriv-thread != NULL)) {
if(msleep_interruptible(500)) {
if(signal_pending(current))
return -EINTR;
}
}
If I set this modprobe parameter to 1, the delay reduces drastically:
[ 5975.865162] drxk: ConfigureI2CBridge
[ 5975.865164] xc5000: xc5000_init()
[ 5975.869257] xc5000: xc5000_is_firmware_loaded() returns True id = 0x1388
[ 5975.876009] xc5000: xc_initialize()
[ 5976.120891] xc5000: *** ADC envelope (0-1023) = 4
[ 5976.126260] xc5000: *** Frequency error = 0 Hz
[ 5976.131260] xc5000: *** Lock status (0-Wait, 1-Locked, 2-No-signal) = 1
[ 5976.139111] xc5000: *** HW: V03.02, FW: V01.06.0072
[ 5976.144733] xc5000: *** Horizontal sync frequency = 11292 Hz
[ 5976.150976] xc5000: *** Frame lines = 1442
[ 5976.155850] xc5000: *** Quality (0:8dB, 7:56dB) = 9
[ 5976.160937] drxk: drxk_gate_ctrldisable
[ 5976.160939] drxk: ConfigureI2CBridge
[ 5977.161897] drxk: drxk_c_get_tune_settings
[ 5977.162085] drxk: drxk_c_init
[ 5977.162089] drxk: drxk_gate_ctrlenable
[ 5977.162091] drxk: ConfigureI2CBridge
[ 5977.162094] xc5000: xc5000_init()
[ 5977.166095] xc5000: xc5000_is_firmware_loaded() returns True id = 0x1388
[ 5977.172836] xc5000: xc_initialize()
[ 5977.422213] xc5000: *** ADC envelope (0-1023) = 4
[ 5977.427706] xc5000: *** Frequency error = 0 Hz
[ 5977.432832] xc5000: *** Lock status (0-Wait, 1-Locked, 2-No-signal) = 1
[ 5977.440682] xc5000: *** HW: V03.02, FW: V01.06.0072
[ 5977.446177] xc5000: *** Horizontal sync frequency = 10460 Hz
[ 5977.452482] xc5000: *** Frame lines = 1442
[ 5977.457296] xc5000: *** Quality (0:8dB, 7:56dB) = 9
[ 5977.462385] drxk: drxk_gate_ctrldisable
[ 5977.462388] drxk: ConfigureI2CBridge
[ 5977.462390] drxk: drxk_set_parameters
[ 5977.462392] drxk: drxk_gate_ctrlenable
[ 5977.462394] drxk: ConfigureI2CBridge
[ 5977.463043] xc5000: xc5000_is_firmware_loaded() returns True id = 0x1388
[ 5977.469781] xc5000: xc5000_set_params() frequency=5700 (Hz)
[ 5977.475740] xc5000: xc5000_set_params() QAM modulation
[ 5977.480912] xc5000: xc5000_set_params() Bandwidth 6MHz (5999550)
[ 5977.486948] xc5000: xc5000_set_params() frequency=5525 (compensated)
[ 5977.493677] xc5000: xc_SetSignalSource(1) Source = CABLE
[ 5977.500024] xc5000: xc_SetTVStandard(0x8002,0x00c0)
[ 5977.504930] xc5000: xc_SetTVStandard() Standard = DTV6
[ 5977.518267] xc5000: xc_set_IF_frequency(freq_khz = 4000) freq_code = 0x1000
[ 5977.527135] xc5000: xc_tune_channel(5525)
[ 5977.531530] xc5000: xc_set_RF_frequency(5525)
[ 5977.728050] xc5000: *** ADC envelope (0-1023) = 768
[ 5977.733671] xc5000: *** Frequency error = 0 Hz
[ 5977.738649] xc5000: *** Lock status (0-Wait, 1-Locked, 2-No-signal) = 1
[ 5977.746523] xc5000: *** HW: V03.02, FW: V01.06.0072
[ 5977.752017] xc5000: *** Horizontal sync frequency = 14970 Hz
[ 5977.758288] xc5000: *** Frame lines = 65535
[ 5977.763137] xc5000: *** Quality (0:8dB, 7:56dB) = 5
[ 5977.768224] drxk: drxk_gate_ctrldisable
[ 5977.768226] drxk: ConfigureI2CBridge
[ 5977.768228] xc5000: xc5000_get_if_frequency()
[ 5977.772624] drxk: Start
[ 5977.772626] drxk: SetQAM
[ 5977.773530] drxk: QAMResetQAM
[ 5977.773880] drxk: scu_command
[ 5977.777653] drxk: QAMSetSymbolrate
[ 5977.778880] drxk: scu_command
[ 5977.782647] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:
[ 5977.789298] drxk: 02 00 00 00 10 00 05 00 03 02..
[ 5977.789490] drxk: scu_command
[ 5977.792644] drxk: scu_command
[ 5977.795641] drxk: SetFrequencyShifter
[ 5977.796119] drxk: SetQAMMeasurement
[ 5977.806489] drxk: SetQAM64
[ 5977.827502] drxk: MPEGTSDtoSetup
[ 5977.834621] drxk: scu_command
[ 5978.161550] drxk: drxk_read_status
[ 5978.161554] drxk: GetLockStatus
[ 5978.161556] drxk: GetQAMLockStatus
[ 5978.161558] drxk: scu_command
[ 5978.315220] drxk: drxk_read_status
[ 5978.315223] drxk: GetLockStatus
[ 5978.315225] drxk: GetQAMLockStatus
[ 5978.315227] drxk: scu_command
[ 5978.469137] drxk: drxk_read_status
[ 5978.469141] drxk: GetLockStatus
[ 5978.469143] drxk: GetQAMLockStatus
[ 5978.469144] drxk: scu_command
[ 5978.623043]
Re: Mantis CAM not SMP safe / Activating CAM on Technisat Skystar HD2 (DVB-S2)
Hi, has anyone an idea how the SMP problems could be fixed? I did some further investigation. When comparing the number of interrupts with all cores enabled and the interrupts with only one core enabled it seems like only the IRQ0 changed, the other IRQs and the total number stays quite the same: 4 Cores: All IRQ/sec: 493 Masked IRQ/sec: 400 Unknown IRQ/sec: 0 DMA/sec: 400 IRQ-0/sec: 143 IRQ-1/sec: 0 OCERR/sec: 0 PABRT/sec: 0 RIPRR/sec: 0 PPERR/sec: 0 FTRGT/sec: 0 RISCI/sec: 258 RACK/sec: 0 1 Core: All IRQ/sec: 518 Masked IRQ/sec: 504 Unknown IRQ/sec: 0 DMA/sec: 504 IRQ-0/sec: 246 IRQ-1/sec: 0 OCERR/sec: 0 PABRT/sec: 0 RIPRR/sec: 0 PPERR/sec: 0 FTRGT/sec: 0 RISCI/sec: 258 RACK/sec: 0 So, where might be the problem? I don't think the IRQ gets lost on the way from the device to the driver, because only IRQ0 is affected. I don't think the device or the driver is to slow because it works fine with only one Core and it also works with SMP when ignoring the timeout and just read the data at the time the IRQ should have fired. Maybe the (cam) locking is faulty (looks fine to me...). Maybe the IRQ handler gets executed parallel on two cores which leads to the problem. But then I think this should be fixed when setting IRQ affinity to only core, but it didn't help with the problem. I hope somebody can help, because I think we are very close to a fully functional CAM here. I ran out of things to test to get closer to the solution :( Btw: Is there any documentation available for the mantis PCI bridge? Manuel -- 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] DVB: dvb_frontend: fix delayed thread exit
On 10.12.2011 00:43, Mauro Carvalho Chehab wrote:
On 09-12-2011 21:37, Mauro Carvalho Chehab wrote:
On 09-12-2011 20:33, Devin Heitmueller wrote:
On Fri, Dec 9, 2011 at 5:11 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Could someone explain reason for that?
I dunno, but I think this needs to be fixed, at least when the frontend
is opened with O_NONBLOCK.
Are you doing the drx-k firmware load on dvb_init()? That could
easily take 4 seconds.
No. The firmware were opened previously.
Maybe the delay is due to this part of dvb_frontend.c:
static int dvb_mfe_wait_time = 5;
...
int mferetry = (dvb_mfe_wait_time 1);
mutex_unlock (adapter-mfe_lock);
while (mferetry-- (mfedev-users != -1 ||
mfepriv-thread != NULL)) {
if(msleep_interruptible(500)) {
if(signal_pending(current))
return -EINTR;
}
}
I haven't looked at the mfe code, but in case it's waiting for the
frontend thread to exit, there's a problem that causes the thread
not to exit immediately. Here's a patch that's been sitting in my
queue for a while:
---
Signed-off-by: Andreas Oberritter o...@linuxtv.org
diff --git a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
index 7784d74..6823c2b 100644
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 2011-09-07
12:32:24.0 +0200
+++ a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 2011-09-13
15:55:48.865742791 +0200
@@ -514,7 +514,7 @@
return 1;
if (fepriv-dvbdev-writers == 1)
- if (time_after(jiffies, fepriv-release_jiffies +
+ if (time_after_eq(jiffies, fepriv-release_jiffies +
dvb_shutdown_timeout * HZ))
return 1;
@@ -2070,12 +2070,15 @@
dprintk (%s\n, __func__);
- if ((file-f_flags O_ACCMODE) != O_RDONLY)
+ if ((file-f_flags O_ACCMODE) != O_RDONLY) {
fepriv-release_jiffies = jiffies;
+ mb();
+ }
ret = dvb_generic_release (inode, file);
if (dvbdev-users == -1) {
+ wake_up(fepriv-wait_queue);
if (fepriv-exit != DVB_FE_NO_EXIT) {
fops_put(file-f_op);
file-f_op = NULL;
--
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] DVB: dvb_frontend: fix delayed thread exit
On Fri, Dec 9, 2011 at 8:37 PM, Andreas Oberritter o...@linuxtv.org wrote:
On 10.12.2011 00:43, Mauro Carvalho Chehab wrote:
On 09-12-2011 21:37, Mauro Carvalho Chehab wrote:
On 09-12-2011 20:33, Devin Heitmueller wrote:
On Fri, Dec 9, 2011 at 5:11 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Could someone explain reason for that?
I dunno, but I think this needs to be fixed, at least when the frontend
is opened with O_NONBLOCK.
Are you doing the drx-k firmware load on dvb_init()? That could
easily take 4 seconds.
No. The firmware were opened previously.
Maybe the delay is due to this part of dvb_frontend.c:
static int dvb_mfe_wait_time = 5;
...
int mferetry = (dvb_mfe_wait_time 1);
mutex_unlock (adapter-mfe_lock);
while (mferetry-- (mfedev-users != -1 ||
mfepriv-thread != NULL)) {
if(msleep_interruptible(500)) {
if(signal_pending(current))
return -EINTR;
}
}
I haven't looked at the mfe code, but in case it's waiting for the
frontend thread to exit, there's a problem that causes the thread
not to exit immediately. Here's a patch that's been sitting in my
queue for a while:
---
Signed-off-by: Andreas Oberritter o...@linuxtv.org
diff --git a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
index 7784d74..6823c2b 100644
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 2011-09-07
12:32:24.0 +0200
+++ a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 2011-09-13
15:55:48.865742791 +0200
@@ -514,7 +514,7 @@
return 1;
if (fepriv-dvbdev-writers == 1)
- if (time_after(jiffies, fepriv-release_jiffies +
+ if (time_after_eq(jiffies, fepriv-release_jiffies +
dvb_shutdown_timeout * HZ))
return 1;
@@ -2070,12 +2070,15 @@
dprintk (%s\n, __func__);
- if ((file-f_flags O_ACCMODE) != O_RDONLY)
+ if ((file-f_flags O_ACCMODE) != O_RDONLY) {
fepriv-release_jiffies = jiffies;
+ mb();
+ }
ret = dvb_generic_release (inode, file);
if (dvbdev-users == -1) {
+ wake_up(fepriv-wait_queue);
if (fepriv-exit != DVB_FE_NO_EXIT) {
fops_put(file-f_op);
file-f_op = NULL;
This patch needs to have a much better explanation of exactly what it
does and what problem it solves. We have a history of race conditions
in dvb_frontend.c, and it's patches like this with virtually no
details just makes it worse.
I'm not arguing the actual merits of the code change - it *may* be
correct. But without the appropriate background there is no real way
of knowing...
Mauro, this patch should be NACK'd and resubmitted with a detailed
explanation of the current behavior, what the problem is, and how the
code changes proposed solve that problem.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DVB: dvb_frontend: fix delayed thread exit
On 10.12.2011 02:59, Devin Heitmueller wrote:
On Fri, Dec 9, 2011 at 8:37 PM, Andreas Oberritter o...@linuxtv.org wrote:
On 10.12.2011 00:43, Mauro Carvalho Chehab wrote:
On 09-12-2011 21:37, Mauro Carvalho Chehab wrote:
On 09-12-2011 20:33, Devin Heitmueller wrote:
On Fri, Dec 9, 2011 at 5:11 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Could someone explain reason for that?
I dunno, but I think this needs to be fixed, at least when the frontend
is opened with O_NONBLOCK.
Are you doing the drx-k firmware load on dvb_init()? That could
easily take 4 seconds.
No. The firmware were opened previously.
Maybe the delay is due to this part of dvb_frontend.c:
static int dvb_mfe_wait_time = 5;
...
int mferetry = (dvb_mfe_wait_time 1);
mutex_unlock (adapter-mfe_lock);
while (mferetry-- (mfedev-users != -1 ||
mfepriv-thread != NULL)) {
if(msleep_interruptible(500)) {
if(signal_pending(current))
return -EINTR;
}
}
I haven't looked at the mfe code, but in case it's waiting for the
frontend thread to exit, there's a problem that causes the thread
not to exit immediately. Here's a patch that's been sitting in my
queue for a while:
---
Signed-off-by: Andreas Oberritter o...@linuxtv.org
diff --git a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
index 7784d74..6823c2b 100644
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 2011-09-07
12:32:24.0 +0200
+++ a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 2011-09-13
15:55:48.865742791 +0200
@@ -514,7 +514,7 @@
return 1;
if (fepriv-dvbdev-writers == 1)
- if (time_after(jiffies, fepriv-release_jiffies +
+ if (time_after_eq(jiffies, fepriv-release_jiffies +
dvb_shutdown_timeout * HZ))
return 1;
@@ -2070,12 +2070,15 @@
dprintk (%s\n, __func__);
- if ((file-f_flags O_ACCMODE) != O_RDONLY)
+ if ((file-f_flags O_ACCMODE) != O_RDONLY) {
fepriv-release_jiffies = jiffies;
+ mb();
+ }
ret = dvb_generic_release (inode, file);
if (dvbdev-users == -1) {
+ wake_up(fepriv-wait_queue);
if (fepriv-exit != DVB_FE_NO_EXIT) {
fops_put(file-f_op);
file-f_op = NULL;
This patch needs to have a much better explanation of exactly what it
does and what problem it solves. We have a history of race conditions
in dvb_frontend.c, and it's patches like this with virtually no
details just makes it worse.
I'm not arguing the actual merits of the code change - it *may* be
correct. But without the appropriate background there is no real way
of knowing...
Mauro, this patch should be NACK'd and resubmitted with a detailed
explanation of the current behavior, what the problem is, and how the
code changes proposed solve that problem.
WTF, Devin, you again? I haven't asked anyone to upstream it. Feel free
to analyze the code and resubmit it.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DVB: dvb_frontend: fix delayed thread exit
Hello Andreas, On Fri, Dec 9, 2011 at 9:06 PM, Andreas Oberritter o...@linuxtv.org wrote: WTF, Devin, you again? I haven't asked anyone to upstream it. Feel free to analyze the code and resubmit it. 1. It's marked with a subject line that starts with [PATCH] 2. It has your SIgned-Off-By line. 3. it was sent to the mailing list. 4. It doesn't have any keywords like RFC or proposed. If you don't intend for it to go upstream then don't do all of the above. I'm not sure if your WTF, Devin, you again? is some indication that I'm annoying you. The last patch you submitted that touches the threading in dvb_frontend.c had a host of problems and was clearly not well researched (i.e. DVB: dvb_frontend: convert semaphore to mutex). As in this case, there is no background indicating that this patch has been fully thought out and due diligence has been done. Maybe you have thoroughly researched the change, taken the time to fully understand its effects, and tested it with a variety of boards and scenarios. Without a good patch description, there is no way to know. I apologize if you're inconvenienced if I'm making an active effort to prevent poorly documented changes from getting merged (which often result in regressions). Oh wait, I'm not sorry at all. Nevermind. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
On Friday 09 December 2011 20:00:12 Mauro Carvalho Chehab wrote: The DRX-K doesn't change the delivery system at set_properties, but do it at frontend init. This causes problems on programs like w_scan that, by default, opens both frontends. Use adap-mfe_shared in order to prevent this, and be sure that Annex A or C are properly selected. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- v2: Use mfe_shared drivers/media/dvb/frontends/drxk_hard.c | 16 ++-- drivers/media/dvb/frontends/drxk_hard.h |2 ++ drivers/media/video/em28xx/em28xx-dvb.c |4 3 files changed, 16 insertions(+), 6 deletions(-) ... Please commit Manu's patch to 'Query DVB frontend delivery capabilities'. Then you will no longer have to struggle with multi-frontend problems. We could finally get rid of having 2 mutual-exclusive frontends, which is just an ugly workaround, barely covered by the API spec... CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ Oliver Endriss ESCAPE GmbH e-mail: o.endr...@escape-edv.de EDV-Loesungen phone: +49 (0)7722 21504 Birkenweg 9 fax: +49 (0)7722 21510 D-78098 Triberg -- 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: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Fri, Dec 9, 2011 at 15:24, Alan Cox a...@lxorguk.ukuu.org.uk wrote: I still don't think that's possible. Please explain how you expect to change the semantics of the streaming mapping API to allow multiple mappers without having explicit serialization points that are visible to all users. For simplicity, let's assume a cache coherent system I think I understand the cache flushing issues on arm (we're doing a similar madness with manually flushing caches for i915 because the gpu isn't coherent with the cpu and other dma devices). And I also agree that you cannot make concurrent mappings work without adding something on top of the current streaming api/dma-buf proposal. I just think that it's not the kernel's business (well, at least not dma_buf's business) to enforce that. If userspace (through some driver calls) tries to do stupid things, it'll just get garbage. See Message-ID: cakmk7uhexyn-v_8cmplnwsfy14ktmurzy8yrkr5xst2-2wd...@mail.gmail.com for my reasons why it think this is the right way to go forward. So in essence I'm really interested in the reasons why you want the kernel to enforce this (or I'm completely missing what's the contentious issue here). I would agree. It's not just about barriers but in many cases where you have multiple mappings by hardware devices the actual hardware interface is specific to the devices. Just take a look at the fencing in TTM and the graphics drivers. Its not something the low level API can deal with, it requires high level knowledge. Yes, we might want to add some form of in-kernel sync objects on top of dma_buf, but I'm not really convinced that this will buy us much above simply synchronizing access in userspace with the existing ipc tools. In my experience the expensive part of syncing two graphics engines with the cpu is that we wake up the cpu and prevent it from going into low-power states if we do this too often. Adding some more overhead by going through userspace doesn't really make it much worse. It's a completely different story if there's a hw facility to synchronize engines without the cpu's involvement (like there is on every multi-pipe gpu) and there sync objects make tons of sense. But I'm not aware of that existing on SoCs between different IP blocks. Cheers, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch -- 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
v4 [PATCH 00/10] Query DVB frontend delivery capabilities
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 -- 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
v4 [PATCH 01/10] DVB: Query DVB frontend delivery capabilities
From 330879841c1fb90182986d9c5edb2ae4e72ba2c7 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/10] 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
Acked-by: Andreas Oberritter o...@linuxtv.org
Acked-by: Oliver Endriss o.endr...@gmx.de
---
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
v4 [PATCH 02/10] DVB: Docbook update for DTV_ENUM_DELSYS
From e846a84ba0f83dabf6bf5a82f27159553ab0f030 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/10] 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
v4 [PATCH 03/10] STB0899: Query DVB frontend delivery capabilities
From 905d5929532dd66b950fbe4a6dc3996615bec4c1 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 03/10] 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
v4 [PATCH 04/10] STV090x: Query DVB frontend delivery capabilities
From 97cc469a2442849667ae4560b2b57d55ba39fb91 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 04/10] 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
v4 [PATCH 05/10] STV0900: Query DVB frontend delivery capabilities
From 3a0e7537e94532cb4df5789cebacfd98ca4fa183 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 05/10] 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
v4 [PATCH 06/10] DVB: Use a unique delivery system identifier for DVBC_ANNEX_C
From 92a79a1e0a1b5403f06f60661f00ede365b10108 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Thu, 24 Nov 2011 17:09:09 +0530
Subject: [PATCH 06/10] DVB: Use a unique delivery system identifier for DVBC_ANNEX_C,
just like any other. DVBC_ANNEX_A and DVBC_ANNEX_C have slightly
different parameters and used in 2 geographically different
locations.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
---
include/linux/dvb/frontend.h |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index f80b863..a3c7623 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -335,7 +335,7 @@ typedef enum fe_rolloff {
typedef enum fe_delivery_system {
SYS_UNDEFINED,
- SYS_DVBC_ANNEX_AC,
+ SYS_DVBC_ANNEX_A,
SYS_DVBC_ANNEX_B,
SYS_DVBT,
SYS_DSS,
@@ -352,8 +352,13 @@ typedef enum fe_delivery_system {
SYS_DAB,
SYS_DVBT2,
SYS_TURBO,
+ SYS_DVBC_ANNEX_C,
} fe_delivery_system_t;
+
+#define SYS_DVBC_ANNEX_AC SYS_DVBC_ANNEX_A
+
+
struct dtv_cmds_h {
char *name; /* A display name for debugging purposes */
--
1.7.1
v4 [PATCH 07/10] TDA18271: Allow frontend to set DELSYS
From 252d4ec800ba73bde8958b8c23ca92a6e17288e2 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Thu, 24 Nov 2011 19:15:56 +0530
Subject: [PATCH 07/10] 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 | 81 +++--
1 files changed, 41 insertions(+), 40 deletions(-)
diff --git a/drivers/media/common/tuners/tda18271-fe.c b/drivers/media/common/tuners/tda18271-fe.c
index 3347c5b..cee1a39 100644
--- a/drivers/media/common/tuners/tda18271-fe.c
+++ b/drivers/media/common/tuners/tda18271-fe.c
@@ -935,69 +935,70 @@ static int tda18271_set_params(struct dvb_frontend *fe,
struct tda18271_std_map *std_map = priv-std;
struct tda18271_std_map_item *map;
int ret;
- u32 bw, freq = params-frequency;
+ u32 bw, bandwidth = 0, freq;
+ fe_delivery_system_t delsys;
+
+ delsys = fe-dtv_property_cache.delivery_system;
+ bw = fe-dtv_property_cache.bandwidth_hz;
+ freq = fe-dtv_property_cache.frequency;
priv-mode = TDA18271_DIGITAL;
- if (fe-ops.info.type == FE_ATSC) {
- switch (params-u.vsb.modulation) {
- case VSB_8:
- case VSB_16:
- map = std_map-atsc_6;
- break;
- case QAM_64:
- case QAM_256:
- map = std_map-qam_6;
- break;
- default:
- tda_warn(modulation not set!\n);
+ if (!delsys || !freq) {
+ tda_warn(delsys:%d freq:%d!\n, delsys, freq);
+ return -EINVAL;
+ }
+ switch (delsys) {
+ case SYS_ATSC:
+ map = std_map-atsc_6;
+ bandwidth = 600;
+ break;
+ case SYS_DVBC_ANNEX_B:
+ map = std_map-qam_6;
+ bandwidth = 600;
+ break;
+ case SYS_DVBC_ANNEX_A:
+ case SYS_DVBC_ANNEX_C:
+ map = std_map-qam_8;
+ bandwidth = 800;
+ break;
+ case SYS_DVBT:
+ case SYS_DVBT2:
+ if (!bw)
return -EINVAL;
- }
-#if 0
- /* userspace request is already center adjusted */
- freq += 175; /* Adjust to center (+1.75MHZ) */
-#endif
- bw = 600;
- } else if (fe-ops.info.type == FE_OFDM) {
- switch (params-u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
- bw = 600;
+ switch (bw) {
+ case 600:
map = std_map-dvbt_6;
break;
- case BANDWIDTH_7_MHZ:
- bw = 700;
+ case 700:
map = std_map-dvbt_7;
break;
- case BANDWIDTH_8_MHZ:
- bw = 800;
+ case 800:
map = std_map-dvbt_8;
break;
default:
- tda_warn(bandwidth not set!\n);
- return -EINVAL;
+ ret = -EINVAL;
+ goto fail;
}
- } else if (fe-ops.info.type == FE_QAM) {
- /* DVB-C */
- map = std_map-qam_8;
- bw = 800;
- } else {
- tda_warn(modulation type not supported!\n);
- return -EINVAL;
+ break;
+ default:
+ tda_warn(Invalid delivery system!\n);
+ ret = -EINVAL;
+ goto fail;
}
-
/* 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, freq, bw);
+ ret = tda18271_tune(fe, map, freq, bandwidth);
if (tda_fail(ret))
goto fail;
priv-if_freq = map-if_freq;
priv-frequency = freq;
- priv-bandwidth = (fe-ops.info.type == FE_OFDM) ?
- params-u.ofdm.bandwidth : 0;
+ priv-bandwidth = (delsys == SYS_DVBT || delsys == SYS_DVBT2) ?
+ bandwidth : 0;
fail:
return ret;
}
--
1.7.1
v4 [PATCH 08/10] TDA18271c2dd: Allow frontend to set DELSYS
From 707877f5a61b3259704d42e7dd5e647e9196e9a4 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Thu, 24 Nov 2011 19:56:34 +0530
Subject: [PATCH 08/10] 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 | 42
1 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/media/dvb/frontends/tda18271c2dd.c b/drivers/media/dvb/frontends/tda18271c2dd.c
index 1b1bf20..43a3dd4 100644
--- a/drivers/media/dvb/frontends/tda18271c2dd.c
+++ b/drivers/media/dvb/frontends/tda18271c2dd.c
@@ -1145,28 +1145,46 @@ static int set_params(struct dvb_frontend *fe,
int status = 0;
int Standard;
- state-m_Frequency = params-frequency;
+ u32 bw;
+ fe_delivery_system_t delsys;
- if (fe-ops.info.type == FE_OFDM)
- switch (params-u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
+ delsys = fe-dtv_property_cache.delivery_system;
+ bw = fe-dtv_property_cache.bandwidth_hz;
+
+ state-m_Frequency = fe-dtv_property_cache.frequency;
+
+ if (!delsys || !state-m_Frequency) {
+ printk(KERN_ERR Invalid delsys:%d freq:%d\n, delsys, state-m_Frequency);
+ return -EINVAL;
+ }
+
+ switch (delsys) {
+ case SYS_DVBT:
+ case SYS_DVBT2:
+ if (!bw)
+ return -EINVAL;
+ switch (bw) {
+ case 600:
Standard = HF_DVBT_6MHZ;
break;
- case BANDWIDTH_7_MHZ:
+ case 700:
Standard = HF_DVBT_7MHZ;
break;
default:
- case BANDWIDTH_8_MHZ:
+ case 800:
Standard = HF_DVBT_8MHZ;
break;
}
- else if (fe-ops.info.type == FE_QAM) {
- if (params-u.qam.symbol_rate = MAX_SYMBOL_RATE_6MHz)
- Standard = HF_DVBC_6MHZ;
- else
- Standard = HF_DVBC_8MHZ;
- } else
+ break;
+ case SYS_DVBC_ANNEX_A:
+ Standard = HF_DVBC_6MHZ;
+ break;
+ case SYS_DVBC_ANNEX_C:
+ Standard = HF_DVBC_8MHZ;
+ break;
+ default:
return -EINVAL;
+ }
do {
status = RFTrackingFiltersCorrection(state, params-frequency);
if (status 0)
--
1.7.1
v4 [PATCH 09/10] CXD2820r: Query DVB frontend delivery capabilities
From 4fdffdcc77228a140c944c20ce2a9f2b6c5b7658 Mon Sep 17 00:00:00 2001
From: Manu Abraham abraham.m...@gmail.com
Date: Thu, 24 Nov 2011 20:29:53 +0530
Subject: [PATCH 09/10] 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|2 +-
drivers/media/dvb/frontends/cxd2820r_core.c | 651 +--
drivers/media/dvb/frontends/cxd2820r_priv.h |5 +-
drivers/media/dvb/frontends/cxd2820r_t.c|2 +-
drivers/media/dvb/frontends/cxd2820r_t2.c |2 +-
5 files changed, 221 insertions(+), 441 deletions(-)
diff --git a/drivers/media/dvb/frontends/cxd2820r_c.c b/drivers/media/dvb/frontends/cxd2820r_c.c
index b85f501..01baeae 100644
--- a/drivers/media/dvb/frontends/cxd2820r_c.c
+++ b/drivers/media/dvb/frontends/cxd2820r_c.c
@@ -22,7 +22,7 @@
#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;
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, p);
+ if (ret 0)
+ goto err;
+ break;
+ case SYS_DVBT2:
+ ret = cxd2820r_init_t(fe);
+ if (ret 0)
+ goto err;
+ ret = cxd2820r_set_frontend_t2(fe, p);
+ if (ret 0)
+ goto err;
+ break;
+ case SYS_DVBC_ANNEX_AC:
+ ret = cxd2820r_init_c(fe);
+ if (ret 0)
+ goto err;
ret = cxd2820r_set_frontend_c(fe, p);
+ if (ret 0)
+ goto err;
+ break;
+ default:
+ dbg(%s: error state=%d, __func__, fe-dtv_property_cache.delivery_system);
+ ret = -EINVAL;
+ break;
}
-
+err:
return ret;
}
-
static int cxd2820r_read_status(struct dvb_frontend *fe, fe_status_t *status)
{
- struct cxd2820r_priv *priv = fe-demodulator_priv;
int ret;
- dbg(%s: delsys=%d,
v4 [PATCH 10/10] PCTV290E: Attach a single frontend
From 4c8f7f787db6a7faf9d89b656ef2b005beacc948 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 10/10] 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
