Re: Very verbose message about em28174 chip.

[Steve Kerrison]

Hi,

It's normal for em28xx to give you that sort of information on 
device-plug - it does seem like a lot, but it's effectively one-off 
and you probably won't see much else during use of the device, under 
default module parameters. It's very useful log output if you have a new 
device or a slight variant of an existing one, as it takes very little 
effort to copy  paste the details here to help figure out how easy it 
is to support the device.


But as you know, that device works already, so you can just ignore it :)

Regards,
Steve.

On 28/07/13 14:19, Chris Rankin wrote:

Hi,

I plugged my PCTV 290e device into my newly compiled 3.10.3 kernel today, and 
found this message in the dmesg log.


[  511.041412] usb 10-4: new high-speed USB device number 3 using ehci-pci
[  511.216218] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, 
interface 0, class 0)
[  511.223916] em28xx: DVB interface 0 found: isoc
[  511.227398] em28xx: chip ID is em28174
[  511.548310] em28174 #0: i2c eeprom : 26 00 01 00 02 09 d8 85 80 80 e5 80 
f4 f5 94 90
[  511.54] em28174 #0: i2c eeprom 0010: 78 0d e4 f0 f5 46 12 00 5a c2 eb c2 
e8 30 e9 03
[  511.562682] em28174 #0: i2c eeprom 0020: 12 09 de 30 eb 03 12 09 10 30 ec f1 
12 07 72 80
[  511.569827] em28174 #0: i2c eeprom 0030: ec 00 60 00 e5 f5 64 01 60 09 e5 f5 
64 09 60 03
[  511.576937] em28174 #0: i2c eeprom 0040: c2 c6 22 e5 f7 b4 03 13 e5 f6 b4 87 
03 02 09 92
[  511.584138] em28174 #0: i2c eeprom 0050: e5 f6 b4 93 03 02 07 e6 c2 c6 22 c2 
c6 22 12 09
[  511.591273] em28174 #0: i2c eeprom 0060: cf 02 06 19 1a eb 67 95 13 20 4f 02 
c0 13 6b 10
[  511.598453] em28174 #0: i2c eeprom 0070: a0 1a ba 14 ce 1a 39 57 00 5c 18 00 
00 00 00 00
[  511.605572] em28174 #0: i2c eeprom 0080: 00 00 00 00 44 36 00 00 f0 10 02 00 
00 00 00 00
[  511.612694] em28174 #0: i2c eeprom 0090: 5b 23 c0 00 00 00 20 40 20 80 02 20 
01 01 00 00
[  511.619821] em28174 #0: i2c eeprom 00a0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00
[  511.627001] em28174 #0: i2c eeprom 00b0: c6 40 00 00 00 00 a7 00 00 00 00 00 
00 00 00 00
[  511.634120] em28174 #0: i2c eeprom 00c0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 38 32
[  511.641199] em28174 #0: i2c eeprom 00d0: 34 31 30 31 31 36 36 30 31 37 31 31 
32 36 58 59
[  511.648319] em28174 #0: i2c eeprom 00e0: 56 49 00 4f 53 49 30 30 33 30 38 44 
30 31 30 36
[  511.655473] em28174 #0: i2c eeprom 00f0: 58 59 56 49 00 00 00 00 00 00 00 00 
00 00 30 36
[  511.662628] em28174 #0: i2c eeprom 0100: ... (skipped)
[  511.666500] em28174 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1eb936d2
[  511.672023] em28174 #0: EEPROM info:
[  511.674338] em28174 #0: microcode start address = 0x0004, boot 
configuration = 0x01
[  511.705368] em28174 #0: No audio on board.
[  511.708286] em28174 #0: 500mA max power
[  511.710988] em28174 #0: Table at offset 0x00, strings=0x, 0x, 
0x
[  511.717120] em28174 #0: Identified as PCTV nanoStick T2 290e (card=78)
[  511.722436] em28174 #0: v4l2 driver version 0.2.0
[  511.731410] em28174 #0: V4L2 video device registered as video1
[  511.736043] em28174 #0: dvb set to isoc mode.
[  511.739638] usbcore: registered new interface driver em28xx
[  511.821414] tda18271 7-0060: creating new instance
[  511.829520] TDA18271HD/C2 detected @ 7-0060
[  512.000542] DVB: registering new adapter (em28174 #0)
[  512.004325] usb 10-4: DVB: registering adapter 0 frontend 0 (Sony 
CXD2820R)...
[  512.011191] em28174 #0: Successfully loaded em28xx-dvb
[  512.015077] Em28xx: Initialized (Em28xx dvb Extension) extension
[  512.056753] Registered IR keymap rc-pinnacle-pctv-hd
[  512.060784] input: em28xx IR (em28174 #0) as 
/devices/pci:00/:00:1d.7/usb10/10-4/rc/rc0/input16
[  512.069167] rc0: em28xx IR (em28174 #0) as 
/devices/pci:00/:00:1d.7/usb10/10-4/rc/rc0
[  512.076882] Em28xx: Initialized (Em28xx Input Extension) extension
[  552.064828] tda18271: performing RF tracking filter calibration
[  554.417676] tda18271: RF tracking filter calibration complete


Presumably something this verbose is intended to be shared, so here it is. (I 
can't think of any other reason why this amount of information would be logged 
by default).


Cheers,
Chris

--
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


--
Steve Kerrison MEng Hons.
http://www.stevekerrison.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: DVB_T2 Multistream support (PLP)

[Steve Kerrison]

Hi Michael,

In terms of Linux support I think you will struggle. The 290e is the 
only DVB-T2 device with (open) driver support in Linux. I haven't tried 
a TBS5880 myself but the linuxtv Wiki page doesn't look promising 
http://www.linuxtv.org/wiki/index.php/TBS5880_USB_DVB-T2/T/C_CI_hybrid_TV_Box


In any case, that device will have the same demod (CXD2820R), and if 
what Antti says about the Windows driver not supporting multi-PLP either 
(if I've read his remarks correctly), you're probably out of luck.


As far as I know the CXD2820R is the only T2 demod that's made it into 
any USB/PCI receivers so there are no other options. There might be a 
datasheet somewhere that would hint at how to provide PLP selection and 
then it would need implementing. The question is where to find it and 
how much effort would be required.


Regards,
Steve.

On 31/01/13 15:02, Michael Stilmant-Rovi wrote:

Thanks,

Looking for a tuner supporting multiple PLP, is it conceivable to add
to the driver the possibility to pass to the hardware that value? (I
don't know if that need other math though) ( I will look the sources
anyway but I don't have good knowledge)

If I want to look for another USB stick how could I know if the driver
will support that feature?
For example is TBS5880 DVB-T2 USB TV Tuner ?

I understand here that the difficulties is that few people are in a
MultiPLP DVB_T2 range. even myself.. .

Regards,

On Thu, Jan 31, 2013 at 3:39 PM, Antti Palosaari cr...@iki.fi wrote:

On 01/31/2013 04:27 PM, Michael Stilmant-Rovi wrote:

Hello,

I would like to know the support status of Multiple PLPs in DVB-T2.
Is someone know if tests were performed in a broadcast with an
effective Multistream? (PLP Id: 0 and 1 for example)

I'm out of range of such multiplex but I'm trying some tunes on London
DVB-T2 (CrystalPalace tower)
unfortunately that mux seems Single PLP and everything work well :-(
( yes tune always succeed :-D )

I'm using DVB API 5.6.
If I tune with FE_SET_PROPERTY without or with DTV_DVBT2_PLP_ID set to
0, 1 or 15. the tune succeed.

I'm not sure of the expected behavior, I was expecting if I tune with
plp_id 1 that the tuner would fail somewhere finding that stream.

So in short I don't understand what is the requirements to be able to
use the DVB_T2 Multistream support proposed in APIs:
   o I see that the DVB API 5.8(?) had some patch at that level and so
it is maybe requested?
   o How can I know if my driver support that feature on DVB API 5.6?
(PCTV nanoStick T2 290e)?

Thank you for all indications.

-Michael


nanoStick T2 290e Linux driver does not support multiple PLPs. I did that
driver and I has only Live signal with single TS. What I think Windows
driver either supports that feature. It just tunes to first PLP regardless
of whole property and that's it.

regards
Antti

--
http://palosaari.fi/

On Thu, Jan 31, 2013 at 3:39 PM, Antti Palosaari cr...@iki.fi wrote:

On 01/31/2013 04:27 PM, Michael Stilmant-Rovi wrote:

Hello,

I would like to know the support status of Multiple PLPs in DVB-T2.
Is someone know if tests were performed in a broadcast with an
effective Multistream? (PLP Id: 0 and 1 for example)

I'm out of range of such multiplex but I'm trying some tunes on London
DVB-T2 (CrystalPalace tower)
unfortunately that mux seems Single PLP and everything work well :-(
( yes tune always succeed :-D )

I'm using DVB API 5.6.
If I tune with FE_SET_PROPERTY without or with DTV_DVBT2_PLP_ID set to
0, 1 or 15. the tune succeed.

I'm not sure of the expected behavior, I was expecting if I tune with
plp_id 1 that the tuner would fail somewhere finding that stream.

So in short I don't understand what is the requirements to be able to
use the DVB_T2 Multistream support proposed in APIs:
   o I see that the DVB API 5.8(?) had some patch at that level and so
it is maybe requested?
   o How can I know if my driver support that feature on DVB API 5.6?
(PCTV nanoStick T2 290e)?

Thank you for all indications.

-Michael


nanoStick T2 290e Linux driver does not support multiple PLPs. I did that
driver and I has only Live signal with single TS. What I think Windows
driver either supports that feature. It just tunes to first PLP regardless
of whole property and that's it.

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


--
Steve Kerrison MEng Hons.
http://www.stevekerrison.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: comments for DVB LNA API

[Steve Kerrison]

Hi Antti,

On 10/07/12 17:20, Antti Palosaari wrote:

I am looking how to implement LNA support for the DVB API.

What we need to be configurable at least is: OFF, ON, AUTO.

There is LNAs that support variable gain and likely those will be
sooner or later. Actually I think there is already LNAs integrated to
the RF-tuner that offers adjustable gain. Also looking to NXP catalog
and you will see there is digital TV LNAs with adjustable gain.

Coming from that requirements are:
adjustable gain 0-xxx dB
LNA OFF
LNA ON
LNA AUTO

Setting LNA is easy but how to query capabilities of supported LNA
values? eg. this device has LNA which supports Gain=5dB, Gain=8dB, LNA
auto?

Without having a sample of device capabilities this question may be
irrelevant, but what if the gain is somewhat continuiously configurable
vs. discretized? For example can some be configured just for 5,8 and 11,
whilst some might have some 8-bit value that controls gain between 5 and 11?


LNA ON (bypass) could be replaced with Gain=0 and LNA ON with Gain0,
Gain=-1 is for auto example.


How should the API handle differences between the specified gain and the
capabilities of the LNA? Round to nearest possible config if it's within
the operating range; return error if out of range?




regards
Antti



--
Steve Kerrison MEng Hons.
http://www.stevekerrison.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: Display hotplug

[Steve Kerrison]

Hi James,

When I plug my laptop's (Toshiba R630, Intel i3 with integrated on-die
graphics) HDMI port into a TV, the display manager in Ubuntu is able to
detect it and, after a click or two, mirror or extended-desktop to it.

So I would say the answer is... it already does. It's more likely that
your distribution doesn't have the tools you need to do what you want,
or the driver for your graphics device needs some work :)

And I don't think this problem falls into the remit of linux-media;
graphics drivers are dealt with elsewhere, aren't they?
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Tue, 2011-10-25 at 10:09 +0100, James Courtier-Dutton wrote:
 Hi,
 
 Does anyone know when X will support display hotplug?
 I have a PC connected via HDMI to a TV.
 Unless I turn the TV on first, I have to reboot the PC before it
 displays anything on the HDMI TV.
 
 Kind Regards
 
 James
 --
 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: UK Digital Switchover - w_scan results for Mendip transmitter

[Steve Kerrison]

Hi Rupert,

It looks like you're picking up more than just Mendip there; Mendip only
has 6 muxes: http://www.ukfree.tv/txdetail.php?a=ST564488

Unless it's announcing other frequencies? I'll do a rescan in MythTV and
see what happens.

As the switchover progresses and transmit powers are increased, however,
some antennae will pick up signals from more than one transmitter. So we
should be careful not to assume that the muxes we see are necessarily
from the transmitter we think we're pointing at!

Cheers,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Mon, 2011-10-10 at 18:49 +0100, Rupert Plumridge wrote:
 Hi
 
 As part of the UK's digital switchover, it seems some of the pre-set
 mux information is now out of date. I don't know the technicals here,
 but for example adding channels to tvheadend git version now fails as
 the mux information at my location is out of date.
 
 I used w_scan to check the current situaiton and it gave me the
 following for the Mendip Transmitter (since that is where my antennae
 is pointed):
 
 dumping lists (193 services)
 #--
 # file automatically generated by w_scan
 #
 #! w_scan 20101001 1 0 OFDM GB /w_scan
 #--
 # location and provider: UK - Mendip
 # date (-mm-dd): 2011-10-09
 # provided by (opt): prupert
 #
 # T[2] freq bw fec_hi fec_lo mod tm guard hi [# comment]
 #--
 T 47400 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 49000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 49800 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 50600 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 51400 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 52200 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 53000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 634167000 8MHz  2/3 NONEQAM64   8k 1/32 NONE # Wales
 T 69800 8MHz  3/4 NONEQAM64   8k 1/32 NONE # Wales
 T 65800 8MHz  2/3 NONEQAM64   8k 1/32 NONE # Wales
 T 642167000 8MHz  2/3 NONEQAM64   8k 1/32 NONE
 T 66600 8MHz  2/3 NONEQAM64   8k 1/32 NONE
 T 65000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 69000 8MHz  2/3 NONEQAM64   8k 1/32 NONE # West
 T 79400 8MHz  2/3 NONEQAM64   8k 1/32 NONE # West
 T 73800 8MHz  2/3 NONEQAM64   8k 1/32 NONE # West
 T 72200 8MHz  2/3 NONEQAM64   8k 1/32 NONE # West
 T 75400 8MHz  2/3 NONEQAM64   8k 1/32 NONE
 T 70600 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 73000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO # West
 T 76200 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 78600 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
 T 84200 8MHz AUTO AUTO AUTO AUTO AUTO AUTO # West
 
 The #West settings seem to work for me on tvheadend, ignore the #Wales
 ones, unless you want all the welsh channels, which you don't.
 
 Hope this is useful. It is all beyond me.
 Rupert
 --
 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: recursive locking problem

[Steve Kerrison]

At the risk of sounding silly, why do we rely on i2c gating so much? The
whole point of i2c is that you can sit a bunch of devices on the same
pair of wires and talk to one at a time.

Why not just open up the gates and be done with it, except for
situations where the i2c chain foolishly has two devices that have the
same address because somebody didn't net the address configuration pins
correctly, or it's a really big system with more devices on it that a
particular chip family has sub-addresses?

From a signal-driving point of view, the gate circuitry is surely a
sufficient buffer. I guess the only two things I can think of as real
reasons are to 1) reduce the chance of misbehaving devices from causing
problems and 2) to save power by not sending clocks and data where we
know they aren't needed.

Can any one shed some light on this? I appreciate it's not a linux or
indeed linux-media specific issue as the hardware itself is designed
this way.

Getting back to the subject, Antti's af9015 example demonstrates
precisely when gating is needed. But I have to ask, does the MXL5003
really only support one address; can it not be reconfigured? it's a bit
late to ask that question once the PCB is fabbed, I admit.

Would it make any sense to haul the gate locking (or some wrapper at
least) up into the uC for that particular configuration?

E.g:

Tuner driver wants to i2c write tuner 0
Calls i2c_gate_ctrl(open)
uC checks if a gate is already open, if it is, and is the same gate as
is already open, just carry on. If not, wait on a lock, then set which
gate is open and proceed to the 'real' gate_ctrl op.
Similar path for i2c_gate_ctrl(close), as relaxed as it needs to be to
cope with how different tuner drivers work.

You could wrap the checking of which gate is open in a lock for
atomicity, and only wait on a device lock where necessary. This way you
can also check whether you're trying to change the state of a gate or
not and early-out (unless calling gate_ctrl(open) more than once does
something /different/ to calling it just once, in which case we're
doomed and this was nothing more than naive rambling).

Cheers,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Tue, 2011-09-13 at 23:59 +0300, Antti Palosaari wrote:
 On 09/09/2011 01:45 PM, David Waring wrote:
  On 08/09/11 17:34, Antti Palosaari wrote:
  [snip]
 
  Is there any lock can do recursive locking but unlock frees all locks?
 
  Like that:
  gate_open
  +gate_open
  +gate_close
  == lock is free
 
  AFAIK mutex can do only simple lock() + unlock(). Semaphore can do
  recursive locking, like lock() + lock() + unlock() + unlock(). But how I
  can do lock() + lock() + unlock() == free.
 
  Antti,
 
  It's a very bad idea to try and use a mutex like that. The number of
  locks and unlocks must be balanced otherwise you risk accessing
  variables without a lock.
 
  Consider:
 
  static struct mutex foo_mutex;
  static int foo=3;
 
  void a() {
 mutex_lock(foo_mutex);
 if (foo5) foo++;
 b();
 foo--; /*  still need lock here */
 mutex_unlock(foo_mutex);
  }
 
  void b() {
 mutex_lock(foo_mutex);
 if (foo6) foo=(foo1);
 mutex_unlock(foo_mutex);
  }
 
  Note: this assumes mutex_lock will allow the same thread get multiple
  locks as you would like (which it doesn't).
 
  As pointed out in the code, when a() is called, you still need the lock
  for accesses to foo after the call to b() that also requires the lock.
  If we used the locks in the way you propose then foo would be accessed
  without a lock.
 
  To code properly for cases like these I usually use a wrapper functions
  to acquire the lock and call a thread unsafe version (i.e. doesn't use
  locks) of the function that only uses other thread unsafe functions. e.g.
 
  void a() {
 mutex_lock(foo_mutex);
 __a_thr_unsafe();
 mutex_unlock(foo_mutex);
  }
 
  void b() {
 mutex_lock(foo_mutex);
 __b_thr_unsafe();
 mutex_unlock(foo_mutex);
  }
 
  static void __a_thr_unsafe() {
 if (foo5) foo++;
 __b_thr_unsafe();
 foo--;
  }
 
  static void __b_thr_unsafe() {
 if (foo6) foo=(foo1);
  }
 
  This way a call to a() or b() will acquire the lock once for that
  thread, perform all actions and then release the lock. The mutex is
  handled properly.
 
  Can you restructure the code so that you don't need multiple locks?
 
 Thank you for very long and detailed reply with examples :)
 
 I need lock for hardware access. Single I2C-adapter have two I2C-clients 
 that have same I2C-address in same bus. There is gate (demod I2C-gate) 
 logic that is used to select desired tuner. See that:
 http://palosaari.fi/linux/v4l-dvb/controlling_tuner_af9015_dual_demod.txt
 
 You can never know surely how tuner drivers calls to open or close gate, 
 very commonly there is situations where multiple close or open happens. 
 That's why lock/unlock is problematic.
 
 .i2c_gate_ctrl() is demod driver callback (struct dvb_frontend_ops) 
 which

Re: PCTV 290e - assorted problems

[Steve Kerrison]

That is most likely the em28xx locking bug. It'll happen when you plug a
second em28xx device in, or plug one in for a second time. The steps
you've shown include that process. Try doing `rmmod em28xx-dvb` before
re-plugging the device. If that 'cures' it, you're a victim of the same
problem.

I'm not overtly familiar with the interactions of em28xx with the rest
of the kernel  userland and why the bug manifests, but it is on my list
of things to (try to) fix, although I'm hoping somebody more able than
me figures it out first :)

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Sun, 2011-08-14 at 17:05 -0700, Chris Rankin wrote:
  INFO: task khubd:1100 blocked for more than 120 seconds.
  echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this message.
  khubd   D  0  1100  2 0x
   8801a694e930 0046 8801a691ffd8 8162b020
   00010280 8801a691ffd8 4000 00010280
   8801a691ffd8 8801a694e930 00010280 8801a691e000
  Call Trace:
   [8128580e] ? apic_timer_interrupt+0xe/0x20
   [8113] ? memscan+0x3/0x18
   [8128354e] ? __mutex_lock_slowpath+0x15c/0x295
   [81283690] ? mutex_lock+0x9/0x18
   [a06af671] ? dvb_init+0x99/0xcc8 [em28xx_dvb]
   [a067d459] ? em28xx_init_extension+0x35/0x53 [em28xx]
   [a067b938] ? em28xx_usb_probe+0x827/0x8df [em28xx]
 
  I think it crashes before it even goes to PCTV 290e specific part. I
  suspect it is bug somewhere in em28xx driver.
 
 The scenario that triggers this crash is:
 a) Plug the 290e in, and allow it to initialise correctly
 b) Use xine to watch any DVB-T channel successfully
 c) Try switching to previously-tuned DVB-T2 channel; this makes xine hang.
 d) Kill xine
 e) Physically replug adapter
 
 em28xx re-initialisation will now fail:
 
 ...
 tda18271: performing RF tracking filter calibration
 tda18271: RF tracking filter calibration complete
 usb 4-1: USB disconnect, device number 3
 em28xx #0: disconnecting em28xx #0 video
 em28xx #0: V4L2 device video1 deregistered
 tda18271 7-0060: destroying instance
 usb 4-1: new high speed USB device number 4 using ehci_hcd
 em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, 
 class 0)
 em28xx #0: chip ID is em28174
 em28xx #0: Identified as PCTV nanoStick T2 290e (card=78)
 Registered IR keymap rc-pinnacle-pctv-hd
 input: em28xx IR (em28xx #0) as 
 /devices/pci:00/:00:1d.7/usb4/4-1/rc/rc1/input8
 rc1: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb4/4-1/rc/rc1
 em28xx #0: v4l2 driver version 0.1.2
 em28xx #0: V4L2 video device registered as video1
 INFO: task khubd:1217 blocked for more than 120 seconds.
 echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this message.
 khubd   D  0  1217  2 0x
  8801a7081ef0 0046 8801a69a9fd8 8162b020
  00010280 8801a69a9fd8 4000 00010280
  8801a69a9fd8 8801a7081ef0 00010280 8801a69a8000
 Call Trace:
  [8128580e] ? apic_timer_interrupt+0xe/0x20
  [8113] ? memscan+0x3/0x18
  [8128354e] ? __mutex_lock_slowpath+0x15c/0x295
  [81283690] ? mutex_lock+0x9/0x18
  [a0694671] ? dvb_init+0x99/0xcc8 [em28xx_dvb]
  [a0662459] ? em28xx_init_extension+0x35/0x53 [em28xx]
  [a0660938] ? em28xx_usb_probe+0x827/0x8df [em28xx]
 
 Cheers,
 Chris
 
 --
 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: PCTV 290e - assorted problems

[Steve Kerrison]

Hi Chris,

Take a look at this breakdown of muxes on the crystal palace
transmitter:

http://www.ukfree.tv/txdetail.php?a=TQ339712

You'll see mixed power levels and FFT sizes. I have the same thing
(albeit with a larger range of power levels) here in Mendip and as a
result its very difficult to get certain muxes.

You could try a variable attenuator to see if you can trim things a bit
to make the tuner/frontend happier getting a lock on all the muxes. It
depends on whether the problem is a weak signal or a too strong signal.

Of course it might be something else altogether, but this sort of thing
is precisely the kind of rubbish we have to deal with during the UK
digital switchover.

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Sun, 2011-08-14 at 16:56 -0700, Chris Rankin wrote:
 --- On Mon, 15/8/11, Antti Palosaari cr...@iki.fi wrote:
  T 55400 8MHz + auto auto auto etc.
  is enough.
 
 Hmm, not here it isn't:
 
 $ scandvb -u -vvv uk-CrystalPalace 
 scanning uk-CrystalPalace
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 initial transponder 55400 0 9 9 6 2 4 4
  tune to: 
  55400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x0f
  tuning status == 0x0f
  tuning status == 0x0f
  tuning status == 0x0f
  tuning status == 0x0f
  tuning status == 0x0f
  tuning status == 0x0f
 WARNING:  tuning failed!!!
  tune to: 
  55400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO
   (tuning failed)
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x0f
  tuning status == 0x0f
  tuning status == 0x0f
  tuning status == 0x0f
  tuning status == 0x0f
  tuning status == 0x0f
  tuning status == 0x0f
 WARNING:  tuning failed!!!
 ERROR: initial tuning failed
 dumping lists (0 services)
 Done.
 
 Although it was working (briefly) on Saturday morning.
 
  Have you tried it on Windows?
 
 No, because I don't own a Windows machine.
 
 Cheers,
 Chris
 
 --
 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

[PATCH v2] CXD2820R: Replace i2c message translation with repeater gate control

[Steve Kerrison]

This patch implements an i2c_gate_ctrl op for the cxd2820r. Thanks to Robert
Schlabbach for identifying the register address and field to set.

The old i2c intercept code that prefixed messages with a passthrough byte has
been removed and the PCTV nanoStick T2 290e entry in em28xx-dvb has been
updated appropriately.

Tested for DVB-T2 use; I would appreciate it if somebody with DVB-C capabilities
could test it as well - from inspection I cannot see any problems.

This is patch v2. It fixes some schoolboy style errors and removes superfluous
i2c entries in cxd2820r.h.

Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 drivers/media/dvb/frontends/cxd2820r.h  |9 ---
 drivers/media/dvb/frontends/cxd2820r_c.c|1 -
 drivers/media/dvb/frontends/cxd2820r_core.c |   76 +++
 drivers/media/dvb/frontends/cxd2820r_priv.h |1 -
 drivers/media/dvb/frontends/cxd2820r_t.c|1 -
 drivers/media/dvb/frontends/cxd2820r_t2.c   |1 -
 drivers/media/video/em28xx/em28xx-dvb.c |7 +--
 7 files changed, 11 insertions(+), 85 deletions(-)

diff --git a/drivers/media/dvb/frontends/cxd2820r.h 
b/drivers/media/dvb/frontends/cxd2820r.h
index 2906582..03cab7b 100644
--- a/drivers/media/dvb/frontends/cxd2820r.h
+++ b/drivers/media/dvb/frontends/cxd2820r.h
@@ -93,9 +93,6 @@ extern struct dvb_frontend *cxd2820r_attach(
struct i2c_adapter *i2c,
struct dvb_frontend *fe
 );
-extern struct i2c_adapter *cxd2820r_get_tuner_i2c_adapter(
-   struct dvb_frontend *fe
-);
 #else
 static inline struct dvb_frontend *cxd2820r_attach(
const struct cxd2820r_config *config,
@@ -106,12 +103,6 @@ static inline struct dvb_frontend *cxd2820r_attach(
printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
return NULL;
 }
-static inline struct i2c_adapter *cxd2820r_get_tuner_i2c_adapter(
-   struct dvb_frontend *fe
-)
-{
-   return NULL;
-}
 
 #endif
 
diff --git a/drivers/media/dvb/frontends/cxd2820r_c.c 
b/drivers/media/dvb/frontends/cxd2820r_c.c
index 3c07d40..b85f501 100644
--- a/drivers/media/dvb/frontends/cxd2820r_c.c
+++ b/drivers/media/dvb/frontends/cxd2820r_c.c
@@ -335,4 +335,3 @@ int cxd2820r_get_tune_settings_c(struct dvb_frontend *fe,
 
return 0;
 }
-
diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c 
b/drivers/media/dvb/frontends/cxd2820r_core.c
index d416e85..0151267 100644
--- a/drivers/media/dvb/frontends/cxd2820r_core.c
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c
@@ -727,70 +727,20 @@ static void cxd2820r_release(struct dvb_frontend *fe)
struct cxd2820r_priv *priv = fe-demodulator_priv;
dbg(%s, __func__);
 
-   if (fe-ops.info.type == FE_OFDM) {
-   i2c_del_adapter(priv-tuner_i2c_adapter);
+   if (fe-ops.info.type == FE_OFDM)
kfree(priv);
-   }
 
return;
 }
 
-static u32 cxd2820r_tuner_i2c_func(struct i2c_adapter *adapter)
-{
-   return I2C_FUNC_I2C;
-}
-
-static int cxd2820r_tuner_i2c_xfer(struct i2c_adapter *i2c_adap,
-   struct i2c_msg msg[], int num)
-{
-   struct cxd2820r_priv *priv = i2c_get_adapdata(i2c_adap);
-   int ret;
-   u8 *obuf = kmalloc(msg[0].len + 2, GFP_KERNEL);
-   struct i2c_msg msg2[2] = {
-   {
-   .addr = priv-cfg.i2c_address,
-   .flags = 0,
-   .len = msg[0].len + 2,
-   .buf = obuf,
-   }, {
-   .addr = priv-cfg.i2c_address,
-   .flags = I2C_M_RD,
-   .len = msg[1].len,
-   .buf = msg[1].buf,
-   }
-   };
-
-   if (!obuf)
-   return -ENOMEM;
-
-   obuf[0] = 0x09;
-   obuf[1] = (msg[0].addr  1);
-   if (num == 2) { /* I2C read */
-   obuf[1] = (msg[0].addr  1) | I2C_M_RD; /* I2C RD flag */
-   msg2[0].len = msg[0].len + 2 - 1; /* '-1' maybe HW bug ? */
-   }
-   memcpy(obuf[2], msg[0].buf, msg[0].len);
-
-   ret = i2c_transfer(priv-i2c, msg2, num);
-   if (ret  0)
-   warn(tuner i2c failed ret:%d, ret);
-
-   kfree(obuf);
-
-   return ret;
-}
-
-static struct i2c_algorithm cxd2820r_tuner_i2c_algo = {
-   .master_xfer   = cxd2820r_tuner_i2c_xfer,
-   .functionality = cxd2820r_tuner_i2c_func,
-};
-
-struct i2c_adapter *cxd2820r_get_tuner_i2c_adapter(struct dvb_frontend *fe)
+static int cxd2820r_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
 {
struct cxd2820r_priv *priv = fe-demodulator_priv;
-   return priv-tuner_i2c_adapter;
+   dbg(%s: %d, __func__, enable);
+
+   /* Bit 0 of reg 0xdb in bank 0x00 controls I2C repeater */
+   return cxd2820r_wr_reg_mask(priv, 0xdb, enable ? 1 : 0, 0x1);
 }
-EXPORT_SYMBOL(cxd2820r_get_tuner_i2c_adapter);
 
 static struct dvb_frontend_ops cxd2820r_ops[2];
 
@@ -831,18 +781,6 @@ struct dvb_frontend *cxd2820r_attach(const struct

Re: Anyone tested the DVB-T2 dual tuner TBS6280?

[Steve Kerrison]

Hi Harald,

Currently the controller chip on the BlackGold card is unsupported - I
don't know if there's any development work going on for that in this
arena or if perhaps BlackGold are working on something themselves.
Perhaps somebody else here knows the full story.

This TBS card has only just been brought to my attention. I cannot tell
what PCIe chip it uses and if it's supported. The alleged Linux driver
download for it doesn't have the cxd2820r code in it, so I can't see
that having much chance of working.

Perhaps ask TBS directly what the status on this one is? I don't know of
anybody who has used it yet (even in Windows).

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Tue, 2011-08-09 at 12:35 +0200, Harald Gustafsson wrote:
 Hi,
 
 I searched for a dual tuner PCI-e DVB-T2 card with Linux support and
 found this TBS6280 card:
 http://tbsdvb.blog.com/2011/07/22/tbs-6280-freeview-hd-twin-tuner-card/
 http://www.buydvb.net/tbs6280-pcie-dvbt2t-dual-tuner-card_p38.html
 http://www.tbsdtv.com/english/Download.html
 
 Previously I have only found the blackgold product that state they
 will have Linux support but have not seen any drivers yet.
 
 But when searching the mythtv lists and the linux dvb list I could not
 find anyone using it. Do anyone have any info about this card, does it
 work well with terrestrial DVB-T2 reception, is linux support working,
 does it work with mythtv, etc.
 
 /Harald
 --
 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: [GIT PULL FOR 2.6.40] PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C)

[Steve Kerrison]

Here in the UK the mux strengths and parameters are all over the place.

I have had situations in the past (with dib0700 I think) where I've had
to twiddle the force_lna setting one way or the other depending on how
they've decided to reconfigure my local transmitter.

So I'd be cautious about flat-out enabling it the whole time.
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Fri, 2011-06-03 at 15:29 +0200, Bjørn Mork wrote:
 Antti Palosaari cr...@iki.fi writes:
  On 06/01/2011 04:27 PM, Mauro Carvalho Chehab wrote:
  Em 25-05-2011 17:42, Antti Palosaari escreveu:
  Antti Palosaari (7):
 em28xx-dvb: add module param options and use it for LNA
 
  That patch is ugly, for several reasons:
 
  1) we don't want a generic options parameter, whose meaning changes from
  device to devices;
 
  I agree it is not proper solution, but in my mind it is better to
  offer some solution than no solution at all.
 
  2) what happens if someone has two em28xx devices plugged?
 
  It depends depends devices, currently only nanoStick T2 only looks
  that param, other just ignore. If there is two nanoStics then both
  have same LNA settings.
 
  That's just like same behaviour as for example remote controller
  polling. Or for example DiBcom driver LNA, since it does have similar
  module param already. Will you you commit it if I rename it similarly
  as DiBcom?
 
  3) the better would be to detect if LNA is needed, or to add a DVBS2API
  call to enable/disable LNA.
 
  True, but it needs some research. There is many hardware which gets
  signal input from demod or tuner and makes some fine tune according to
  that. We need to define some new callbacks for demod and tuner in
  order to do this kind of actions.
  Or just add new LNA param to API use it manually.
 
 
 Or option 
 4) just enable the LNA unconditionally.  
 
 I did some testing in my environment, and I was unable to tune anything
 on either DVB-T or DVB-C without the LNA enabled.  I'm of course aware
 that this depends on your signal, but have you actually seen a real life
 signal where tuning fails with the LNA enabled and works without it?
 
 I do believe that my DVB-C signal at least is pretty strong.
 
 
 
 Bjørn
 
 --
 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: PCTV nanoStick T2 290e support - Thank you!

[Steve Kerrison]

The demodulator chip supports T,T2 and C.

Here in the UK you're not really allowed to attach cable receivers that
aren't supplied by the cable company (Virgin Media). That and the fact
that it has no access module for obvious reasons, I guess PCTV Systems
didn't see the benefit in marketing the C functionality.

I don't actually know if the windows driver supports C mode, it would be
amusing if we deliver more functionality with the Linux driver :)

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Fri, 2011-05-27 at 13:36 +0200, Bjørn Mork wrote:
 Antti Palosaari cr...@iki.fi writes:
  On 05/27/2011 12:25 AM, Nicolas WILL wrote:
  Just installed mine for MythTV.
 
  Works great on the first try!
 
  Many, many thanks!
 
  Thank you for the feedback!
 
 I'm a bit curious about this device.  It seems to only be marketed as a
 DVB-T2 device in areas where that spec is used.  But looking at your
 driver, it seems that the device also supports DVB-C.  Is that correct?
 
 
 
 Bjørn
 
 --
 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: PCTV nanoStick T2 290e support - Thank you!

[Steve Kerrison]

Hi Bjørn,

 I thought downloading the Windows driver would tell, but
 a) I cannot seem to find the Windows driver for this device, and
 b) this info isn't easily found in the drivers I looked at

The bundled CD has the drivers on it, but I think it's also in the
driver bundle on their site for their other empia based cards:

ftp://ftp.pctvsystems.com/TV/driver/PCTV%2070e%2080e%20100e%20320e%
20330e%20800e/PCTV%2070e%2080e%20100e%20320e%20330e%20800e%20880e.zip

Found via
http://www.pctvsystems.com/tabid/62/default.aspx/Downloads/Driver/tabid/123/language/en-GB/Default.aspx

I'm not sure how you'd tell, other than perhaps firing up VLC on Windows
and seeing if you can open it as a DVB-C device?

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Fri, 2011-05-27 at 14:41 +0200, Bjørn Mork wrote:
 Steve Kerrison st...@stevekerrison.com writes:
 
  The demodulator chip supports T,T2 and C.
 
  Here in the UK you're not really allowed to attach cable receivers that
  aren't supplied by the cable company (Virgin Media). That and the fact
  that it has no access module for obvious reasons, I guess PCTV Systems
  didn't see the benefit in marketing the C functionality.
 
 Well, I found it a bit weird that they do announce DVB-T + DVB-C support
 for the PCTV QuatroStick nano (which has the exact same form factor
 and look, and therefore obviously no CA slot either):
 http://www.pctvsystems.com/Products/ProductsEuropeAsia/Hybridproducts/PCTVQuatroSticknano/tabid/254/language/en-GB/Default.aspx
 
 While the PCTV nanoStick T2 is announced as only DVB-T2 + DVB-T:
 http://www.pctvsystems.com/Products/ProductsEuropeAsia/Digitalproducts/PCTVnanoStickT2/tabid/248/language/en-GB/Default.aspx
 
 That's why I asked, even though the driver clearly supports DVB-C.  But
 you may be right that this is because the nanoStick T2 currently is
 targeted for the UK.
 
 Around here, we've actually got some cable companies supporting TV sets
 with integrated receivers.  Of course requiring their CAM.  They
 probably still don't like the thought of PC based receivers, but there
 is some hope...
 
 
  I don't actually know if the windows driver supports C mode, it would be
  amusing if we deliver more functionality with the Linux driver :)
 
 I thought downloading the Windows driver would tell, but
 a) I cannot seem to find the Windows driver for this device, and
 b) this info isn't easily found in the drivers I looked at
 
 So who knows?  It would certainly be amusing.
 
 
 Bjørn
 
 --
 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: dvb: one demux per tuner or one demux per demod?

[Steve Kerrison]

Hi Rémi,

The cxd2820r supports DVB-T/T2 and also DVB-C. As such antti coded up a
multiple front end (MFE) implementation for em28xx then attaches the
cxd2820r in both modes.

I believe you can only use one frontend at once per adapter (this is
certainly enforced in the cxd2820r module), so I don't see how it would
cause a problem for mappings. I think a dual tuner device would register
itself as two adapters, wouldn't it?

But I'm new at this, so forgive me if I've overlooked something or
misunderstood the issue you've raised.

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Tue, 2011-05-24 at 12:55 +0200, Rémi Denis-Courmont wrote:
 Hello,
 
 Been testing the bleeding-edge Hauppauge 290E (em28174 + Sony cxd2820r)
 from Antti Palosaari and Steve Kerrison, now in linux-media GIT tree.
 
 It seems the device creates two frontends and only one demux/dvr nodes.
 Are they not supposed to be one demux per frontend? Or how is user-space
 supposed to map the demux/dvr and the frontend, on a multi-proto card? on a
 multi-tuner card?
 
 Best regards,
 

--
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: dvb: one demux per tuner or one demux per demod?

[Steve Kerrison]

Hi Devin,

 Oh wow, is that what Antti did?  I didn't really give much thought but
 I can appreciate why he did it (the DVB 3.x API won't allow a single
 frontend to advertise support for DVB-C and DVB-T).

Yup, here's a quote from his initial pull request. I guess it doesn't
make completely clear why he did what he did unless you knew in advance
that the demod did DVB-T and DVB-C.

 Main part of this patch series is new demod driver for Sony CXD2820R. 
 Other big part is multi frontend (MFE) support for em28xx driver. I 
 don't have any other MFE device, so I cannot say if it is implemented 
 correctly or not. At least it seems to work. MFE locking is done in 
 demod driver. If there is some problems let me know and I will try to 
 fix those - I think there is no such big major problems still.

Back to your comments:

 This is one of the big things that S2API fixes (through S2API you can
 specify the modulation that you want).  Do we really want to be
 advertising two frontends that point to the same demod, when they
 cannot be used in parallel?  This seems doomed to create problems with
 applications not knowing that they are in fact the same frontend.

Agreed, but I had thought that with a single adapter with two frontends
it would be possible to obey the rules and only use one at once. If
frontend0 is in use, then if you try to open either frontend0 or
frontend1, you should get device busy... so I don't see it causing
massive issues.

Like you say, though, S2API is probably the better approach, with the
frontend advertising its supported modulations and selecting one as
required.

 I'm tempted to say that this patch should be scapped and we should
 simply say that you cannot use DVB-C on this device unless you are
 using S2API.  That would certainly be cleaner but it comes at the cost
 of DVB-C not working with tools that haven't been converted over to
 S2API yet.

Seeing as the 290e is the only cxd2820r based device supported in Linux
right now, combined with the fact that it isn't even advertised as a
DVB-C device by PCTV Systems, that's probably an acceptable hit to take.

I'd be interested to see what Antti thinks though. :)

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Tue, 2011-05-24 at 08:28 -0400, Devin Heitmueller wrote:
 2011/5/24 Steve Kerrison st...@stevekerrison.com:
  Hi Rémi,
 
  The cxd2820r supports DVB-T/T2 and also DVB-C. As such antti coded up a
  multiple front end (MFE) implementation for em28xx then attaches the
  cxd2820r in both modes.
 
  I believe you can only use one frontend at once per adapter (this is
  certainly enforced in the cxd2820r module), so I don't see how it would
  cause a problem for mappings. I think a dual tuner device would register
  itself as two adapters, wouldn't it?
 
  But I'm new at this, so forgive me if I've overlooked something or
  misunderstood the issue you've raised.
 
 Oh wow, is that what Antti did?  I didn't really give much thought but
 I can appreciate why he did it (the DVB 3.x API won't allow a single
 frontend to advertise support for DVB-C and DVB-T).
 
 This is one of the big things that S2API fixes (through S2API you can
 specify the modulation that you want).  Do we really want to be
 advertising two frontends that point to the same demod, when they
 cannot be used in parallel?  This seems doomed to create problems with
 applications not knowing that they are in fact the same frontend.
 
 I'm tempted to say that this patch should be scapped and we should
 simply say that you cannot use DVB-C on this device unless you are
 using S2API.  That would certainly be cleaner but it comes at the cost
 of DVB-C not working with tools that haven't been converted over to
 S2API yet.
 
 Devin
 

--
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 v3] DVB: Add basic API support for DVB-T2 and bump minor version

[Steve Kerrison]

From: Andreas Oberritter o...@linuxtv.org

st...@stevekerrison.com: Remove private definitions from cxd2820r that existed 
before API was defined

Signed-off-by: Andreas Oberritter o...@linuxtv.org
Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 drivers/media/dvb/dvb-core/dvb_frontend.c   |   13 +
 drivers/media/dvb/dvb-core/dvb_frontend.h   |3 +++
 drivers/media/dvb/frontends/cxd2820r_priv.h |   12 
 include/linux/dvb/frontend.h|   20 
 include/linux/dvb/version.h |2 +-
 5 files changed, 29 insertions(+), 21 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 31e2c0d..8c9ff8a 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1148,10 +1148,9 @@ static void dtv_property_adv_params_sync(struct 
dvb_frontend *fe)
break;
}
 
-   if(c-delivery_system == SYS_ISDBT) {
-   /* Fake out a generic DVB-T request so we pass validation in 
the ioctl */
-   p-frequency = c-frequency;
-   p-inversion = c-inversion;
+   /* Fake out a generic DVB-T request so we pass validation in the ioctl 
*/
+   if ((c-delivery_system == SYS_ISDBT) ||
+   (c-delivery_system == SYS_DVBT2)) {
p-u.ofdm.constellation = QAM_AUTO;
p-u.ofdm.code_rate_HP = FEC_AUTO;
p-u.ofdm.code_rate_LP = FEC_AUTO;
@@ -1324,6 +1323,9 @@ static int dtv_property_process_get(struct dvb_frontend 
*fe,
case DTV_ISDBS_TS_ID:
tvp-u.data = fe-dtv_property_cache.isdbs_ts_id;
break;
+   case DTV_DVBT2_PLP_ID:
+   tvp-u.data = fe-dtv_property_cache.dvbt2_plp_id;
+   break;
default:
r = -1;
}
@@ -1479,6 +1481,9 @@ static int dtv_property_process_set(struct dvb_frontend 
*fe,
case DTV_ISDBS_TS_ID:
fe-dtv_property_cache.isdbs_ts_id = tvp-u.data;
break;
+   case DTV_DVBT2_PLP_ID:
+   fe-dtv_property_cache.dvbt2_plp_id = tvp-u.data;
+   break;
default:
r = -1;
}
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h 
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 3b86050..5590eb6 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -358,6 +358,9 @@ struct dtv_frontend_properties {
 
/* ISDB-T specifics */
u32 isdbs_ts_id;
+
+   /* DVB-T2 specifics */
+   u32 dvbt2_plp_id;
 };
 
 struct dvb_frontend {
diff --git a/drivers/media/dvb/frontends/cxd2820r_priv.h 
b/drivers/media/dvb/frontends/cxd2820r_priv.h
index d4e2e0b..25adbee 100644
--- a/drivers/media/dvb/frontends/cxd2820r_priv.h
+++ b/drivers/media/dvb/frontends/cxd2820r_priv.h
@@ -40,18 +40,6 @@
 #undef warn
 #define warn(f, arg...) printk(KERN_WARNING LOG_PREFIX:  f \n , ## arg)
 
-/*
- * FIXME: These are totally wrong and must be added properly to the API.
- * Only temporary solution in order to get driver compile.
- */
-#define SYS_DVBT2 SYS_DAB
-#define TRANSMISSION_MODE_1K  0
-#define TRANSMISSION_MODE_16K 0
-#define TRANSMISSION_MODE_32K 0
-#define GUARD_INTERVAL_1_128  0
-#define GUARD_INTERVAL_19_128 0
-#define GUARD_INTERVAL_19_256 0
-
 struct reg_val_mask {
u32 reg;
u8  val;
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 493a2bf..36a3ed6 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -175,14 +175,20 @@ typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
TRANSMISSION_MODE_AUTO,
-   TRANSMISSION_MODE_4K
+   TRANSMISSION_MODE_4K,
+   TRANSMISSION_MODE_1K,
+   TRANSMISSION_MODE_16K,
+   TRANSMISSION_MODE_32K,
 } fe_transmit_mode_t;
 
 typedef enum fe_bandwidth {
BANDWIDTH_8_MHZ,
BANDWIDTH_7_MHZ,
BANDWIDTH_6_MHZ,
-   BANDWIDTH_AUTO
+   BANDWIDTH_AUTO,
+   BANDWIDTH_5_MHZ,
+   BANDWIDTH_10_MHZ,
+   BANDWIDTH_1_712_MHZ,
 } fe_bandwidth_t;
 
 
@@ -191,7 +197,10 @@ typedef enum fe_guard_interval {
GUARD_INTERVAL_1_16,
GUARD_INTERVAL_1_8,
GUARD_INTERVAL_1_4,
-   GUARD_INTERVAL_AUTO
+   GUARD_INTERVAL_AUTO,
+   GUARD_INTERVAL_1_128,
+   GUARD_INTERVAL_19_128,
+   GUARD_INTERVAL_19_256,
 } fe_guard_interval_t;
 
 
@@ -305,7 +314,9 @@ struct dvb_frontend_event {
 
 #define DTV_ISDBS_TS_ID42
 
-#define DTV_MAX_COMMANDDTV_ISDBS_TS_ID
+#define DTV_DVBT2_PLP_ID   43
+
+#define DTV_MAX_COMMANDDTV_DVBT2_PLP_ID
 
 typedef enum fe_pilot {
PILOT_ON,
@@ -337,6 +348,7 @@ typedef enum fe_delivery_system {
SYS_DMBTH,
SYS_CMMB

Re: [PATCH v2 5/5] Documentation: Update to include DVB-T2 additions

[Steve Kerrison]

I've just realised there is some illegal whitespace in this patch here:

 @@ -553,5 +568,20 @@ typedef enum fe_guard_interval {
 /section
 /section
 /section
 +   section id=dvbt2-params
 +   titleDVB-T2 parameters/title
 +   
 +   paraThis section covers parameters that apply only
 to the DVB-T2 delivery method. DVB-T2

Auto-tab between the title and first paragraph. My apologies! If I need
to do anything about this let me know.
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Sun, 2011-05-08 at 20:17 +0100, Steve Kerrison wrote:
 A few new capabilities added to frontend.h for DVB-T2. Added these
 to the documentation plus some notes explaining that they are
 used by the T2 delivery system.
 
 Signed-off-by: Steve Kerrison st...@stevekerrison.com
 ---
  Documentation/DocBook/dvb/dvbproperty.xml |   36 ++--
  Documentation/DocBook/dvb/frontend.h.xml  |   20 +---
  2 files changed, 49 insertions(+), 7 deletions(-)
 
 diff --git a/Documentation/DocBook/dvb/dvbproperty.xml 
 b/Documentation/DocBook/dvb/dvbproperty.xml
 index 05ce603..52d5e3c 100644
 --- a/Documentation/DocBook/dvb/dvbproperty.xml
 +++ b/Documentation/DocBook/dvb/dvbproperty.xml
 @@ -217,9 +217,12 @@ get/set up to 64 properties. The actual meaning of each 
 property is described on
   paraBandwidth for the channel, in HZ./para
  
   paraPossible values:
 + constant1712000/constant,
 + constant500/constant,
   constant600/constant,
   constant700/constant,
 - constant800/constant.
 + constant800/constant,
 + constant1000/constant.
   /para
  
   paraNotes:/para
 @@ -231,6 +234,8 @@ get/set up to 64 properties. The actual meaning of each 
 property is described on
   para4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily 
 derived from
   other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
   DTV_ISDBT_SB_SEGMENT_COUNT)./para
 + para5) DVB-T supports 6, 7 and 8MHz./para
 + para6) In addition, DVB-T2 supports 1.172, 5 and 10MHz./para
   /section
  
   section id=DTV_DELIVERY_SYSTEM
 @@ -257,6 +262,7 @@ typedef enum fe_delivery_system {
   SYS_DMBTH,
   SYS_CMMB,
   SYS_DAB,
 + SYS_DVBT2,
  } fe_delivery_system_t;
  /programlisting
  
 @@ -273,7 +279,10 @@ typedef enum fe_transmit_mode {
   TRANSMISSION_MODE_2K,
   TRANSMISSION_MODE_8K,
   TRANSMISSION_MODE_AUTO,
 - TRANSMISSION_MODE_4K
 + TRANSMISSION_MODE_4K,
 + TRANSMISSION_MODE_1K,
 + TRANSMISSION_MODE_16K,
 + TRANSMISSION_MODE_32K,
  } fe_transmit_mode_t;
  /programlisting
  
 @@ -284,6 +293,8 @@ typedef enum fe_transmit_mode {
   para2) If constantDTV_TRANSMISSION_MODE/constant is set 
 the constantTRANSMISSION_MODE_AUTO/constant the
   hardware will try to find the correct FFT-size (if 
 capable) and will
   use TMCC to fill in the missing parameters./para
 + para3) DVB-T specifies 2K and 8K as valid sizes./para
 + para4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K./para
   /section
  
   section id=DTV_GUARD_INTERVAL
 @@ -296,7 +307,10 @@ typedef enum fe_guard_interval {
   GUARD_INTERVAL_1_16,
   GUARD_INTERVAL_1_8,
   GUARD_INTERVAL_1_4,
 - GUARD_INTERVAL_AUTO
 + GUARD_INTERVAL_AUTO,
 + GUARD_INTERVAL_1_128,
 + GUARD_INTERVAL_19_128,
 + GUARD_INTERVAL_19_256,
  } fe_guard_interval_t;
  /programlisting
  
 @@ -304,6 +318,7 @@ typedef enum fe_guard_interval {
   para1) If constantDTV_GUARD_INTERVAL/constant is set the 
 constantGUARD_INTERVAL_AUTO/constant the hardware will
   try to find the correct guard interval (if capable) and 
 will use TMCC to fill
   in the missing parameters./para
 + para2) Intervals 1/128, 19/128 and 19/256 are used only for 
 DVB-T2 at present/para
   /section
  /section
  
 @@ -553,5 +568,20 @@ typedef enum fe_guard_interval {
   /section
   /section
   /section
 + section id=dvbt2-params
 + titleDVB-T2 parameters/title
 + 
 + paraThis section covers parameters that apply only to the 
 DVB-T2 delivery method. DVB-T2
 + support is currently in the early stages development so 
 expect this section to grow
 + and become more detailed with time./para
 +
 + section id=dvbt2-plp-id
 + titleconstantDTV_DVBT2_PLP_ID/constant/title
 +
 + paraDVB-T2 supports Physical Layer Pipes (PLP) to 
 allow transmission of
 + many data

Re: [PATCH v2 2/5] drxd: Fix warning caused by new entries in an enum

[Steve Kerrison]

Hi Andreas,

 I'd prefer returning -EINVAL for unsupported parameters.

 [snip]
 
 I already had a patch for this, but forgot to submit it together with
 the frontend.h bits.

That seems reasonable. Do I need to do anything with this? I'm happy for
Mauro to scrub my drxd and mxl patches and use yours instead.

 Btw., status = status; looks odd.

Heh, yes it does. I wonder if that was put in to deal with an unused
variable compiler warning before the switch statement had a default
case? Otherwise, perhaps it's from the department of redundancy
department.

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Mon, 2011-05-09 at 00:10 +0200, Andreas Oberritter wrote:
 On 05/08/2011 09:17 PM, Steve Kerrison wrote:
  Additional bandwidth modes have been added in frontend.h
  drxd_hard.c had no default case so the compiler was warning about
  a non-exhausive switch statement.
  
  This has been fixed by making the default behaviour the same as
  BANDWIDTH_AUTO, with the addition of a printk to notify if this
  ever happens.
  
  Signed-off-by: Steve Kerrison st...@stevekerrison.com
  ---
   drivers/media/dvb/frontends/drxd_hard.c |4 
   1 files changed, 4 insertions(+), 0 deletions(-)
  
  diff --git a/drivers/media/dvb/frontends/drxd_hard.c 
  b/drivers/media/dvb/frontends/drxd_hard.c
  index 30a78af..b3b0704 100644
  --- a/drivers/media/dvb/frontends/drxd_hard.c
  +++ b/drivers/media/dvb/frontends/drxd_hard.c
  @@ -2325,6 +2325,10 @@ static int DRX_Start(struct drxd_state *state, s32 
  off)
 InitEC and ResetEC
 functions */
  switch (p-bandwidth) {
  +   default:
  +   printk(KERN_INFO drxd: Unsupported bandwidth mode %u, 
  reverting to default\n,
  +   p-bandwidth);
  +   /* Fall back to auto */
 
 I'd prefer returning -EINVAL for unsupported parameters.
 
  case BANDWIDTH_AUTO:
  case BANDWIDTH_8_MHZ:
  /* (64/7)*(8/8)*100 */
 
 I already had a patch for this, but forgot to submit it together with the 
 frontend.h bits.
 
 From 73d630b57f584d7e35cac5e27149cbc564aedde2 Mon Sep 17 00:00:00 2001
 From: Andreas Oberritter o...@linuxtv.org
 Date: Fri, 8 Apr 2011 16:39:20 +
 Subject: [PATCH 2/2] DVB: drxd_hard: handle new bandwidths by returning 
 -EINVAL
 
 Signed-off-by: Andreas Oberritter o...@linuxtv.org
 ---
  drivers/media/dvb/frontends/drxd_hard.c |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/media/dvb/frontends/drxd_hard.c 
 b/drivers/media/dvb/frontends/drxd_hard.c
 index 30a78af..53319f4 100644
 --- a/drivers/media/dvb/frontends/drxd_hard.c
 +++ b/drivers/media/dvb/frontends/drxd_hard.c
 @@ -2348,6 +2348,9 @@ static int DRX_Start(struct drxd_state *state, s32 off)
   status = Write16(state,
FE_AG_REG_IND_DEL__A, 71, 0x);
   break;
 + default:
 + status = -EINVAL;
 + break;
   }
   status = status;
   if (status  0)

--
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 0/6] DVB-T2 API updates, documentation and accompanying small fixes

[Steve Kerrison]

Hi Mauro, Antti, Andreas,

I hope this patch set is formed appropriately - it is my first patch
submission direct to the linux-media group.

Following the pull of Antti's work on support for the cxd2820r and PCTV
nanoStick T2 290e, this patch set implements Andreas' modifications to the API
to give provisional DVB-T2 support and the removal of a workaround for this
in the cxd2820r module.

In addition, there are some minor fixes to compiler warnings as a result
of the expanded enums. I cannot test these myself but they treat unrecognized
values as *_AUTO and I can't see where a problem would be created.

I have updated the documentation a little. If I've done the right thing then
I guess there is incentive there for me continue to expand DVB related
elements of the API docs.

This patch set has been tested by me on two systems, with one running a MythTV
backend utilising a long-supported DVB tuner. MythTV works fine with the old
tuner and the nanoStick T2 290e works in VLC. I've yet to test the 290e in
MythTV - I was more intent on making sure the patches hadn't broken userland
or older devices.

Feedback, testing  and discussion of where to go next is welcomed!

Regards,
Steve Kerrison.

--
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 1/6] DVB: Add basic API support for DVB-T2 and bump minor version

[Steve Kerrison]

From: Andreas Oberritter o...@linuxtv.org

Signed-off-by: Andreas Oberritter o...@linuxtv.org
Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |7 +++
 include/linux/dvb/frontend.h  |   20 
 include/linux/dvb/version.h   |2 +-
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 31e2c0d..e30beef 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1148,10 +1148,9 @@ static void dtv_property_adv_params_sync(struct 
dvb_frontend *fe)
break;
}
 
-   if(c-delivery_system == SYS_ISDBT) {
-   /* Fake out a generic DVB-T request so we pass validation in 
the ioctl */
-   p-frequency = c-frequency;
-   p-inversion = c-inversion;
+   /* Fake out a generic DVB-T request so we pass validation in the ioctl 
*/
+   if ((c-delivery_system == SYS_ISDBT) ||
+   (c-delivery_system == SYS_DVBT2)) {
p-u.ofdm.constellation = QAM_AUTO;
p-u.ofdm.code_rate_HP = FEC_AUTO;
p-u.ofdm.code_rate_LP = FEC_AUTO;
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 493a2bf..36a3ed6 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -175,14 +175,20 @@ typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
TRANSMISSION_MODE_AUTO,
-   TRANSMISSION_MODE_4K
+   TRANSMISSION_MODE_4K,
+   TRANSMISSION_MODE_1K,
+   TRANSMISSION_MODE_16K,
+   TRANSMISSION_MODE_32K,
 } fe_transmit_mode_t;
 
 typedef enum fe_bandwidth {
BANDWIDTH_8_MHZ,
BANDWIDTH_7_MHZ,
BANDWIDTH_6_MHZ,
-   BANDWIDTH_AUTO
+   BANDWIDTH_AUTO,
+   BANDWIDTH_5_MHZ,
+   BANDWIDTH_10_MHZ,
+   BANDWIDTH_1_712_MHZ,
 } fe_bandwidth_t;
 
 
@@ -191,7 +197,10 @@ typedef enum fe_guard_interval {
GUARD_INTERVAL_1_16,
GUARD_INTERVAL_1_8,
GUARD_INTERVAL_1_4,
-   GUARD_INTERVAL_AUTO
+   GUARD_INTERVAL_AUTO,
+   GUARD_INTERVAL_1_128,
+   GUARD_INTERVAL_19_128,
+   GUARD_INTERVAL_19_256,
 } fe_guard_interval_t;
 
 
@@ -305,7 +314,9 @@ struct dvb_frontend_event {
 
 #define DTV_ISDBS_TS_ID42
 
-#define DTV_MAX_COMMANDDTV_ISDBS_TS_ID
+#define DTV_DVBT2_PLP_ID   43
+
+#define DTV_MAX_COMMANDDTV_DVBT2_PLP_ID
 
 typedef enum fe_pilot {
PILOT_ON,
@@ -337,6 +348,7 @@ typedef enum fe_delivery_system {
SYS_DMBTH,
SYS_CMMB,
SYS_DAB,
+   SYS_DVBT2,
 } fe_delivery_system_t;
 
 struct dtv_cmds_h {
diff --git a/include/linux/dvb/version.h b/include/linux/dvb/version.h
index 5a7546c..1421cc8 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 2
+#define DVB_API_VERSION_MINOR 3
 
 #endif /*_DVBVERSION_H_*/
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/6] cxd2820r: Update frontend capabilities to advertise QAM-256

[Steve Kerrison]

This is supported in DVB-T2 mode, so added to the T/T2 frontend.

Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 drivers/media/dvb/frontends/cxd2820r_core.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c 
b/drivers/media/dvb/frontends/cxd2820r_core.c
index e900c4c..0779f69 100644
--- a/drivers/media/dvb/frontends/cxd2820r_core.c
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c
@@ -855,7 +855,8 @@ static struct dvb_frontend_ops cxd2820r_ops[2] = {
FE_CAN_FEC_3_4 | FE_CAN_FEC_5_6 |
FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
FE_CAN_QPSK | FE_CAN_QAM_16 |
-   FE_CAN_QAM_64 | FE_CAN_QAM_AUTO |
+   FE_CAN_QAM_64 | FE_CAN_QAM_256 |
+   FE_CAN_QAM_AUTO |
FE_CAN_TRANSMISSION_MODE_AUTO |
FE_CAN_GUARD_INTERVAL_AUTO |
FE_CAN_HIERARCHY_AUTO |
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/6] drxd: Fix warning caused by new entries in an enum

[Steve Kerrison]

Additional bandwidth modes have been added in frontend.h
drxd_hard.c had no default case so the compiler was warning about
a non-exhausive switch statement.

This has been fixed by making the default behaviour the same as
BANDWIDTH_AUTO, with the addition of a printk to notify if this
ever happens.

Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 drivers/media/dvb/frontends/drxd_hard.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/frontends/drxd_hard.c 
b/drivers/media/dvb/frontends/drxd_hard.c
index 30a78af..f1d64f1 100644
--- a/drivers/media/dvb/frontends/drxd_hard.c
+++ b/drivers/media/dvb/frontends/drxd_hard.c
@@ -2325,6 +2325,9 @@ static int DRX_Start(struct drxd_state *state, s32 off)
   InitEC and ResetEC
   functions */
switch (p-bandwidth) {
+   default:
+   printk(KERN_INFO drxd: Unsupported bandwidth mode %u, 
reverting to default\n,
+   p-bandwidth);
case BANDWIDTH_AUTO:
case BANDWIDTH_8_MHZ:
/* (64/7)*(8/8)*100 */
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/6] Documentation: Update to include DVB-T2 additions

[Steve Kerrison]

A few new capabilities added to frontend.h for DVB-T2. Added these
to the documentation plus some notes explaining that they are
used by the T2 delivery system.

Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 Documentation/DocBook/dvb/dvbproperty.xml |   21 ++---
 Documentation/DocBook/dvb/frontend.h.xml  |   20 
 2 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/Documentation/DocBook/dvb/dvbproperty.xml 
b/Documentation/DocBook/dvb/dvbproperty.xml
index 05ce603..afe204c 100644
--- a/Documentation/DocBook/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/dvb/dvbproperty.xml
@@ -217,9 +217,12 @@ get/set up to 64 properties. The actual meaning of each 
property is described on
paraBandwidth for the channel, in HZ./para
 
paraPossible values:
+   constant1712000/constant,
+   constant500/constant,
constant600/constant,
constant700/constant,
-   constant800/constant.
+   constant800/constant,
+   constant1000/constant.
/para
 
paraNotes:/para
@@ -231,6 +234,8 @@ get/set up to 64 properties. The actual meaning of each 
property is described on
para4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily 
derived from
other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
DTV_ISDBT_SB_SEGMENT_COUNT)./para
+   para5) DVB-T supports 6, 7 and 8MHz./para
+   para6) In addition, DVB-T2 supports 1.172, 5 and 10MHz./para
/section
 
section id=DTV_DELIVERY_SYSTEM
@@ -257,6 +262,7 @@ typedef enum fe_delivery_system {
SYS_DMBTH,
SYS_CMMB,
SYS_DAB,
+   SYS_DVBT2,
 } fe_delivery_system_t;
 /programlisting
 
@@ -273,7 +279,10 @@ typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
TRANSMISSION_MODE_AUTO,
-   TRANSMISSION_MODE_4K
+   TRANSMISSION_MODE_4K,
+   TRANSMISSION_MODE_1K,
+   TRANSMISSION_MODE_16K,
+   TRANSMISSION_MODE_32K,
 } fe_transmit_mode_t;
 /programlisting
 
@@ -284,6 +293,8 @@ typedef enum fe_transmit_mode {
para2) If constantDTV_TRANSMISSION_MODE/constant is set 
the constantTRANSMISSION_MODE_AUTO/constant the
hardware will try to find the correct FFT-size (if 
capable) and will
use TMCC to fill in the missing parameters./para
+   para3) DVB-T specifies 2K and 8K as valid sizes./para
+   para4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K./para
/section
 
section id=DTV_GUARD_INTERVAL
@@ -296,7 +307,10 @@ typedef enum fe_guard_interval {
GUARD_INTERVAL_1_16,
GUARD_INTERVAL_1_8,
GUARD_INTERVAL_1_4,
-   GUARD_INTERVAL_AUTO
+   GUARD_INTERVAL_AUTO,
+   GUARD_INTERVAL_1_128,
+   GUARD_INTERVAL_19_128,
+   GUARD_INTERVAL_19_256,
 } fe_guard_interval_t;
 /programlisting
 
@@ -304,6 +318,7 @@ typedef enum fe_guard_interval {
para1) If constantDTV_GUARD_INTERVAL/constant is set the 
constantGUARD_INTERVAL_AUTO/constant the hardware will
try to find the correct guard interval (if capable) and 
will use TMCC to fill
in the missing parameters./para
+   para2) Intervals 1/128, 19/128 and 19/256 are used only for 
DVB-T2 at present/para
/section
 /section
 
diff --git a/Documentation/DocBook/dvb/frontend.h.xml 
b/Documentation/DocBook/dvb/frontend.h.xml
index d08e0d4..d792f78 100644
--- a/Documentation/DocBook/dvb/frontend.h.xml
+++ b/Documentation/DocBook/dvb/frontend.h.xml
@@ -176,14 +176,20 @@ typedef enum fe_transmit_mode {
 TRANSMISSION_MODE_2K,
 TRANSMISSION_MODE_8K,
 TRANSMISSION_MODE_AUTO,
-TRANSMISSION_MODE_4K
+TRANSMISSION_MODE_4K,
+TRANSMISSION_MODE_1K,
+TRANSMISSION_MODE_16K,
+TRANSMISSION_MODE_32K,
 } fe_transmit_mode_t;
 
 typedef enum fe_bandwidth {
 BANDWIDTH_8_MHZ,
 BANDWIDTH_7_MHZ,
 BANDWIDTH_6_MHZ,
-BANDWIDTH_AUTO
+BANDWIDTH_AUTO,
+BANDWIDTH_5_MHZ,
+BANDWIDTH_10_MHZ,
+BANDWIDTH_1_712_MHZ,
 } fe_bandwidth_t;
 
 
@@ -192,7 +198,10 @@ typedef enum fe_guard_interval {
 GUARD_INTERVAL_1_16,
 GUARD_INTERVAL_1_8,
 GUARD_INTERVAL_1_4,
-GUARD_INTERVAL_AUTO
+GUARD_INTERVAL_AUTO,
+GUARD_INTERVAL_1_128,
+GUARD_INTERVAL_19_128,
+GUARD_INTERVAL_19_256,
 } fe_guard_interval_t;
 
 
@@ -306,7 +315,9 @@ struct dvb_frontend_event {
 
 #define DTV_ISDBS_TS_ID 42
 
-#define DTV_MAX_COMMAND DTV_ISDBS_TS_ID
+#define DTV_DVBT2_PLP_ID   43
+
+#define DTV_MAX_COMMAND

[PATCH 4/6] mxl5005: Fix warning caused by new entries in an enum

[Steve Kerrison]

Additional bandwidth modes have been added in frontend.h
mxl5005s.c had no default case so the compiler was warning about
a non-exhausive switch statement.

Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 drivers/media/common/tuners/mxl5005s.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/media/common/tuners/mxl5005s.c 
b/drivers/media/common/tuners/mxl5005s.c
index 0d6e094..667e216 100644
--- a/drivers/media/common/tuners/mxl5005s.c
+++ b/drivers/media/common/tuners/mxl5005s.c
@@ -4020,6 +4020,9 @@ static int mxl5005s_set_params(struct dvb_frontend *fe,
case BANDWIDTH_7_MHZ:
req_bw  = MXL5005S_BANDWIDTH_7MHZ;
break;
+   default:
+   dprintk(1,%s: Unsupported bandwidth mode %u, 
reverting to default\n,
+   __func__,params-u.ofdm.bandwidth);
case BANDWIDTH_AUTO:
case BANDWIDTH_8_MHZ:
req_bw  = MXL5005S_BANDWIDTH_8MHZ;
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/6] cxd2820r: Remove temporary T2 API hack

[Steve Kerrison]

Unimplemented delivery system and modes were #define'd to
arbitrary values for internal use. API now includes these values
so we can remove this hack.

Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 drivers/media/dvb/frontends/cxd2820r_priv.h |   12 
 1 files changed, 0 insertions(+), 12 deletions(-)

diff --git a/drivers/media/dvb/frontends/cxd2820r_priv.h 
b/drivers/media/dvb/frontends/cxd2820r_priv.h
index d4e2e0b..25adbee 100644
--- a/drivers/media/dvb/frontends/cxd2820r_priv.h
+++ b/drivers/media/dvb/frontends/cxd2820r_priv.h
@@ -40,18 +40,6 @@
 #undef warn
 #define warn(f, arg...) printk(KERN_WARNING LOG_PREFIX:  f \n , ## arg)
 
-/*
- * FIXME: These are totally wrong and must be added properly to the API.
- * Only temporary solution in order to get driver compile.
- */
-#define SYS_DVBT2 SYS_DAB
-#define TRANSMISSION_MODE_1K  0
-#define TRANSMISSION_MODE_16K 0
-#define TRANSMISSION_MODE_32K 0
-#define GUARD_INTERVAL_1_128  0
-#define GUARD_INTERVAL_19_128 0
-#define GUARD_INTERVAL_19_256 0
-
 struct reg_val_mask {
u32 reg;
u8  val;
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/6] Documentation: Update to include DVB-T2 additions

[Steve Kerrison]

Hi Mauro

 + para3) DVB-T specifies 2K and 8K as valid sizes./para
  +   para4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K./para
 
 It makes sense to add here that ISDB-T specifies 2K, 4K and 8K.
 (yeah, sorry, it is my fault that I didn't notice it before ;) )

Actually note 1) in that list declares the sizes supported by ISDB-T;
but the patch doesn't show it. So there is no blame to assign :)

 -#define DTV_MAX_COMMAND DTV_ISDBS_TS_ID
  +#define DTV_DVBT2_PLP_ID   43
  +
 
 Please document the PLP_ID as well. Just like ISDB-T, the best seems to
 create a section with DVB-T2 specific parameters, and add this one there,
 explaining its meaning.

I have created a section for DVB-T2 parameters. It's within the main
ISDB-T section. If that's not appropriate I guess it can be hauled out
as it grows. However, much like Antti, I don't know much about PLP or
the other features of the T2 specification, so cannot contribute a great
deal yet. PLP_ID isn't used by the cxd2820r driver - it's simply
specified in Andreas' API patch.

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Sun, 2011-05-08 at 13:20 -0300, Mauro Carvalho Chehab wrote:
 Em 08-05-2011 12:51, Steve Kerrison escreveu:
  A few new capabilities added to frontend.h for DVB-T2. Added these
  to the documentation plus some notes explaining that they are
  used by the T2 delivery system.
  
  Signed-off-by: Steve Kerrison st...@stevekerrison.com
  ---
   Documentation/DocBook/dvb/dvbproperty.xml |   21 ++---
   Documentation/DocBook/dvb/frontend.h.xml  |   20 
   2 files changed, 34 insertions(+), 7 deletions(-)
  
  diff --git a/Documentation/DocBook/dvb/dvbproperty.xml 
  b/Documentation/DocBook/dvb/dvbproperty.xml
  index 05ce603..afe204c 100644
  --- a/Documentation/DocBook/dvb/dvbproperty.xml
  +++ b/Documentation/DocBook/dvb/dvbproperty.xml
  @@ -217,9 +217,12 @@ get/set up to 64 properties. The actual meaning of 
  each property is described on
  paraBandwidth for the channel, in HZ./para
   
  paraPossible values:
  +   constant1712000/constant,
  +   constant500/constant,
  constant600/constant,
  constant700/constant,
  -   constant800/constant.
  +   constant800/constant,
  +   constant1000/constant.
  /para
   
  paraNotes:/para
  @@ -231,6 +234,8 @@ get/set up to 64 properties. The actual meaning of each 
  property is described on
  para4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily 
  derived from
  other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
  DTV_ISDBT_SB_SEGMENT_COUNT)./para
  +   para5) DVB-T supports 6, 7 and 8MHz./para
  +   para6) In addition, DVB-T2 supports 1.172, 5 and 10MHz./para
  /section
   
  section id=DTV_DELIVERY_SYSTEM
  @@ -257,6 +262,7 @@ typedef enum fe_delivery_system {
  SYS_DMBTH,
  SYS_CMMB,
  SYS_DAB,
  +   SYS_DVBT2,
   } fe_delivery_system_t;
   /programlisting
   
  @@ -273,7 +279,10 @@ typedef enum fe_transmit_mode {
  TRANSMISSION_MODE_2K,
  TRANSMISSION_MODE_8K,
  TRANSMISSION_MODE_AUTO,
  -   TRANSMISSION_MODE_4K
  +   TRANSMISSION_MODE_4K,
  +   TRANSMISSION_MODE_1K,
  +   TRANSMISSION_MODE_16K,
  +   TRANSMISSION_MODE_32K,
   } fe_transmit_mode_t;
   /programlisting
   
  @@ -284,6 +293,8 @@ typedef enum fe_transmit_mode {
  para2) If constantDTV_TRANSMISSION_MODE/constant is set 
  the constantTRANSMISSION_MODE_AUTO/constant the
  hardware will try to find the correct FFT-size (if 
  capable) and will
  use TMCC to fill in the missing parameters./para
  +   para3) DVB-T specifies 2K and 8K as valid sizes./para
  +   para4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K./para
 
 It makes sense to add here that ISDB-T specifies 2K, 4K and 8K.
 (yeah, sorry, it is my fault that I didn't notice it before ;) )
  /section
   
  section id=DTV_GUARD_INTERVAL
  @@ -296,7 +307,10 @@ typedef enum fe_guard_interval {
  GUARD_INTERVAL_1_16,
  GUARD_INTERVAL_1_8,
  GUARD_INTERVAL_1_4,
  -   GUARD_INTERVAL_AUTO
  +   GUARD_INTERVAL_AUTO,
  +   GUARD_INTERVAL_1_128,
  +   GUARD_INTERVAL_19_128,
  +   GUARD_INTERVAL_19_256,
   } fe_guard_interval_t;
   /programlisting
   
  @@ -304,6 +318,7 @@ typedef enum fe_guard_interval {
  para1) If constantDTV_GUARD_INTERVAL/constant is set the 
  constantGUARD_INTERVAL_AUTO/constant the hardware will
  try to find the correct guard interval (if capable) and 
  will use TMCC to fill
  in the missing parameters./para
  +   para2) Intervals 1/128, 19/128 and 19/256 are used only for 
  DVB-T2 at present/para
  /section
   /section

[PATCH v2 0/5] DVB-T2 API updates, documentation and accompanying small fixes

[Steve Kerrison]

Good evening all,

This is the second version of my patch set for DVB-T2 and PCTV nanoStick T2
290e support.

Changes to cxd2820r_priv.h have been rolled into patch 1 as requested by Mauro.
I hope I have done this in an appropriate way.

I have updated my drxd and mxl5005 patches to include a comment to make clear
that the default case should fall through into BANDWIDTH_AUTO for bandwidth
selection.

My other cxd2820r patch is trivial and unchanged from the previous
submission. I considered also rolling it into the first patch in the set,
but it's a separate ehancement so I've kept it as it is.

Finally I've made some documentation changes. I've added a section of DVB-T2
specific parameters, but don't have the knowledge to contribute anything useful
to this section yet.

Any further feedback welcomed. I won't be likely to act upon it for a few days,
however. The mailing list could probably do with a break from me bungling my
way around git. :)

Regards,
Steve Kerrison.

--
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 v2 1/5] DVB: Add basic API support for DVB-T2 and bump minor version

[Steve Kerrison]

From: Andreas Oberritter o...@linuxtv.org

st...@stevekerrison.com: Remove private definitions from cxd2820r that existed 
before API was defined

Signed-off-by: Andreas Oberritter o...@linuxtv.org
Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 drivers/media/dvb/dvb-core/dvb_frontend.c   |7 +++
 drivers/media/dvb/frontends/cxd2820r_priv.h |   12 
 include/linux/dvb/frontend.h|   20 
 include/linux/dvb/version.h |2 +-
 4 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 31e2c0d..e30beef 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1148,10 +1148,9 @@ static void dtv_property_adv_params_sync(struct 
dvb_frontend *fe)
break;
}
 
-   if(c-delivery_system == SYS_ISDBT) {
-   /* Fake out a generic DVB-T request so we pass validation in 
the ioctl */
-   p-frequency = c-frequency;
-   p-inversion = c-inversion;
+   /* Fake out a generic DVB-T request so we pass validation in the ioctl 
*/
+   if ((c-delivery_system == SYS_ISDBT) ||
+   (c-delivery_system == SYS_DVBT2)) {
p-u.ofdm.constellation = QAM_AUTO;
p-u.ofdm.code_rate_HP = FEC_AUTO;
p-u.ofdm.code_rate_LP = FEC_AUTO;
diff --git a/drivers/media/dvb/frontends/cxd2820r_priv.h 
b/drivers/media/dvb/frontends/cxd2820r_priv.h
index d4e2e0b..25adbee 100644
--- a/drivers/media/dvb/frontends/cxd2820r_priv.h
+++ b/drivers/media/dvb/frontends/cxd2820r_priv.h
@@ -40,18 +40,6 @@
 #undef warn
 #define warn(f, arg...) printk(KERN_WARNING LOG_PREFIX:  f \n , ## arg)
 
-/*
- * FIXME: These are totally wrong and must be added properly to the API.
- * Only temporary solution in order to get driver compile.
- */
-#define SYS_DVBT2 SYS_DAB
-#define TRANSMISSION_MODE_1K  0
-#define TRANSMISSION_MODE_16K 0
-#define TRANSMISSION_MODE_32K 0
-#define GUARD_INTERVAL_1_128  0
-#define GUARD_INTERVAL_19_128 0
-#define GUARD_INTERVAL_19_256 0
-
 struct reg_val_mask {
u32 reg;
u8  val;
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 493a2bf..36a3ed6 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -175,14 +175,20 @@ typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
TRANSMISSION_MODE_AUTO,
-   TRANSMISSION_MODE_4K
+   TRANSMISSION_MODE_4K,
+   TRANSMISSION_MODE_1K,
+   TRANSMISSION_MODE_16K,
+   TRANSMISSION_MODE_32K,
 } fe_transmit_mode_t;
 
 typedef enum fe_bandwidth {
BANDWIDTH_8_MHZ,
BANDWIDTH_7_MHZ,
BANDWIDTH_6_MHZ,
-   BANDWIDTH_AUTO
+   BANDWIDTH_AUTO,
+   BANDWIDTH_5_MHZ,
+   BANDWIDTH_10_MHZ,
+   BANDWIDTH_1_712_MHZ,
 } fe_bandwidth_t;
 
 
@@ -191,7 +197,10 @@ typedef enum fe_guard_interval {
GUARD_INTERVAL_1_16,
GUARD_INTERVAL_1_8,
GUARD_INTERVAL_1_4,
-   GUARD_INTERVAL_AUTO
+   GUARD_INTERVAL_AUTO,
+   GUARD_INTERVAL_1_128,
+   GUARD_INTERVAL_19_128,
+   GUARD_INTERVAL_19_256,
 } fe_guard_interval_t;
 
 
@@ -305,7 +314,9 @@ struct dvb_frontend_event {
 
 #define DTV_ISDBS_TS_ID42
 
-#define DTV_MAX_COMMANDDTV_ISDBS_TS_ID
+#define DTV_DVBT2_PLP_ID   43
+
+#define DTV_MAX_COMMANDDTV_DVBT2_PLP_ID
 
 typedef enum fe_pilot {
PILOT_ON,
@@ -337,6 +348,7 @@ typedef enum fe_delivery_system {
SYS_DMBTH,
SYS_CMMB,
SYS_DAB,
+   SYS_DVBT2,
 } fe_delivery_system_t;
 
 struct dtv_cmds_h {
diff --git a/include/linux/dvb/version.h b/include/linux/dvb/version.h
index 5a7546c..1421cc8 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 2
+#define DVB_API_VERSION_MINOR 3
 
 #endif /*_DVBVERSION_H_*/
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/5] drxd: Fix warning caused by new entries in an enum

[Steve Kerrison]

Additional bandwidth modes have been added in frontend.h
drxd_hard.c had no default case so the compiler was warning about
a non-exhausive switch statement.

This has been fixed by making the default behaviour the same as
BANDWIDTH_AUTO, with the addition of a printk to notify if this
ever happens.

Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 drivers/media/dvb/frontends/drxd_hard.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/frontends/drxd_hard.c 
b/drivers/media/dvb/frontends/drxd_hard.c
index 30a78af..b3b0704 100644
--- a/drivers/media/dvb/frontends/drxd_hard.c
+++ b/drivers/media/dvb/frontends/drxd_hard.c
@@ -2325,6 +2325,10 @@ static int DRX_Start(struct drxd_state *state, s32 off)
   InitEC and ResetEC
   functions */
switch (p-bandwidth) {
+   default:
+   printk(KERN_INFO drxd: Unsupported bandwidth mode %u, 
reverting to default\n,
+   p-bandwidth);
+   /* Fall back to auto */
case BANDWIDTH_AUTO:
case BANDWIDTH_8_MHZ:
/* (64/7)*(8/8)*100 */
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/5] mxl5005: Fix warning caused by new entries in an enum

[Steve Kerrison]

Additional bandwidth modes have been added in frontend.h
mxl5005s.c had no default case so the compiler was warning about
a non-exhausive switch statement.

Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 drivers/media/common/tuners/mxl5005s.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/media/common/tuners/mxl5005s.c 
b/drivers/media/common/tuners/mxl5005s.c
index 0d6e094..d80e6f3 100644
--- a/drivers/media/common/tuners/mxl5005s.c
+++ b/drivers/media/common/tuners/mxl5005s.c
@@ -4020,6 +4020,10 @@ static int mxl5005s_set_params(struct dvb_frontend *fe,
case BANDWIDTH_7_MHZ:
req_bw  = MXL5005S_BANDWIDTH_7MHZ;
break;
+   default:
+   dprintk(1,%s: Unsupported bandwidth mode %u, 
reverting to default\n,
+   __func__,params-u.ofdm.bandwidth);
+   /* Fall back to auto */
case BANDWIDTH_AUTO:
case BANDWIDTH_8_MHZ:
req_bw  = MXL5005S_BANDWIDTH_8MHZ;
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/5] cxd2820r: Update frontend capabilities to advertise QAM-256

[Steve Kerrison]

This is supported in DVB-T2 mode, so added to the T/T2 frontend.

Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 drivers/media/dvb/frontends/cxd2820r_core.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c 
b/drivers/media/dvb/frontends/cxd2820r_core.c
index e900c4c..0779f69 100644
--- a/drivers/media/dvb/frontends/cxd2820r_core.c
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c
@@ -855,7 +855,8 @@ static struct dvb_frontend_ops cxd2820r_ops[2] = {
FE_CAN_FEC_3_4 | FE_CAN_FEC_5_6 |
FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
FE_CAN_QPSK | FE_CAN_QAM_16 |
-   FE_CAN_QAM_64 | FE_CAN_QAM_AUTO |
+   FE_CAN_QAM_64 | FE_CAN_QAM_256 |
+   FE_CAN_QAM_AUTO |
FE_CAN_TRANSMISSION_MODE_AUTO |
FE_CAN_GUARD_INTERVAL_AUTO |
FE_CAN_HIERARCHY_AUTO |
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/5] Documentation: Update to include DVB-T2 additions

[Steve Kerrison]

A few new capabilities added to frontend.h for DVB-T2. Added these
to the documentation plus some notes explaining that they are
used by the T2 delivery system.

Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
 Documentation/DocBook/dvb/dvbproperty.xml |   36 ++--
 Documentation/DocBook/dvb/frontend.h.xml  |   20 +---
 2 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/Documentation/DocBook/dvb/dvbproperty.xml 
b/Documentation/DocBook/dvb/dvbproperty.xml
index 05ce603..52d5e3c 100644
--- a/Documentation/DocBook/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/dvb/dvbproperty.xml
@@ -217,9 +217,12 @@ get/set up to 64 properties. The actual meaning of each 
property is described on
paraBandwidth for the channel, in HZ./para
 
paraPossible values:
+   constant1712000/constant,
+   constant500/constant,
constant600/constant,
constant700/constant,
-   constant800/constant.
+   constant800/constant,
+   constant1000/constant.
/para
 
paraNotes:/para
@@ -231,6 +234,8 @@ get/set up to 64 properties. The actual meaning of each 
property is described on
para4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily 
derived from
other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
DTV_ISDBT_SB_SEGMENT_COUNT)./para
+   para5) DVB-T supports 6, 7 and 8MHz./para
+   para6) In addition, DVB-T2 supports 1.172, 5 and 10MHz./para
/section
 
section id=DTV_DELIVERY_SYSTEM
@@ -257,6 +262,7 @@ typedef enum fe_delivery_system {
SYS_DMBTH,
SYS_CMMB,
SYS_DAB,
+   SYS_DVBT2,
 } fe_delivery_system_t;
 /programlisting
 
@@ -273,7 +279,10 @@ typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
TRANSMISSION_MODE_AUTO,
-   TRANSMISSION_MODE_4K
+   TRANSMISSION_MODE_4K,
+   TRANSMISSION_MODE_1K,
+   TRANSMISSION_MODE_16K,
+   TRANSMISSION_MODE_32K,
 } fe_transmit_mode_t;
 /programlisting
 
@@ -284,6 +293,8 @@ typedef enum fe_transmit_mode {
para2) If constantDTV_TRANSMISSION_MODE/constant is set 
the constantTRANSMISSION_MODE_AUTO/constant the
hardware will try to find the correct FFT-size (if 
capable) and will
use TMCC to fill in the missing parameters./para
+   para3) DVB-T specifies 2K and 8K as valid sizes./para
+   para4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K./para
/section
 
section id=DTV_GUARD_INTERVAL
@@ -296,7 +307,10 @@ typedef enum fe_guard_interval {
GUARD_INTERVAL_1_16,
GUARD_INTERVAL_1_8,
GUARD_INTERVAL_1_4,
-   GUARD_INTERVAL_AUTO
+   GUARD_INTERVAL_AUTO,
+   GUARD_INTERVAL_1_128,
+   GUARD_INTERVAL_19_128,
+   GUARD_INTERVAL_19_256,
 } fe_guard_interval_t;
 /programlisting
 
@@ -304,6 +318,7 @@ typedef enum fe_guard_interval {
para1) If constantDTV_GUARD_INTERVAL/constant is set the 
constantGUARD_INTERVAL_AUTO/constant the hardware will
try to find the correct guard interval (if capable) and 
will use TMCC to fill
in the missing parameters./para
+   para2) Intervals 1/128, 19/128 and 19/256 are used only for 
DVB-T2 at present/para
/section
 /section
 
@@ -553,5 +568,20 @@ typedef enum fe_guard_interval {
/section
/section
/section
+   section id=dvbt2-params
+   titleDVB-T2 parameters/title
+   
+   paraThis section covers parameters that apply only to the 
DVB-T2 delivery method. DVB-T2
+   support is currently in the early stages development so 
expect this section to grow
+   and become more detailed with time./para
+
+   section id=dvbt2-plp-id
+   titleconstantDTV_DVBT2_PLP_ID/constant/title
+
+   paraDVB-T2 supports Physical Layer Pipes (PLP) to 
allow transmission of
+   many data types via a single multiplex. The API 
will soon support this
+   at which point this section will be 
expanded./para
+   /section
+   /section
 /section
 /section
diff --git a/Documentation/DocBook/dvb/frontend.h.xml 
b/Documentation/DocBook/dvb/frontend.h.xml
index d08e0d4..d792f78 100644
--- a/Documentation/DocBook/dvb/frontend.h.xml
+++ b/Documentation/DocBook/dvb/frontend.h.xml
@@ -176,14 +176,20 @@ typedef enum fe_transmit_mode {
 TRANSMISSION_MODE_2K,
 TRANSMISSION_MODE_8K,
 TRANSMISSION_MODE_AUTO,
-TRANSMISSION_MODE_4K

Re: [git:v4l-dvb/for_v2.6.40] [media] Sony CXD2820R DVB-T/T2/C demodulator driver

[Steve Kerrison]

Hi Andreas,

From cxd2820r_priv.h:

 +/*
 + * FIXME: These are totally wrong and must be added properly to the API.
 + * Only temporary solution in order to get driver compile.
 + */
 +#define SYS_DVBT2 SYS_DAB
 +#define TRANSMISSION_MODE_1K  0
 +#define TRANSMISSION_MODE_16K 0
 +#define TRANSMISSION_MODE_32K 0
 +#define GUARD_INTERVAL_1_128  0
 +#define GUARD_INTERVAL_19_128 0
 +#define GUARD_INTERVAL_19_256 0


I believe Antti didn't want to make frontent.h changes until a consensus
was reached on how to develop the API for T2 support.

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Fri, 2011-05-06 at 12:01 +0200, Andreas Oberritter wrote:
 On 05/05/2011 12:53 PM, Mauro Carvalho Chehab wrote:
  +   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);
  +   ret = cxd2820r_set_frontend_t2(fe, p);
  +   }
  +   break;
  +   case SYS_DVBT2:
  +   if (c-delivery_system == SYS_DVBT2) {
 
 Is this driver compilable? I don't see the necessary changes to
 linux/dvb/frontend.h to add SYS_DVBT2 in your tree.
 
 See below for a patch that I used for testing DVB-T2 internally.
 
 Regards,
 Andreas
 
 --
 commit e89f95641f29b7a4457e7a68649f4374933e36a2
 Author: Andreas Oberritter o...@linuxtv.org
 Date:   Mon Mar 15 14:43:52 2010 +0100
 
 DVB: Add basic API support for DVB-T2 and bump minor version
 
 Signed-off-by: Andreas Oberritter o...@linuxtv.org
 
 diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
 b/drivers/media/dvb/dvb-core/dvb_frontend.c
 index f5016ae..6f06efe 100644
 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
 +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
 @@ -1141,10 +1141,9 @@ static void dtv_property_adv_params_sync(struct 
 dvb_frontend *fe)
   break;
   }
  
 - if(c-delivery_system == SYS_ISDBT) {
 - /* Fake out a generic DVB-T request so we pass validation in 
 the ioctl */
 - p-frequency = c-frequency;
 - p-inversion = c-inversion;
 + /* Fake out a generic DVB-T request so we pass validation in the ioctl 
 */
 + if ((c-delivery_system == SYS_ISDBT) ||
 + (c-delivery_system == SYS_DVBT2)) {
   p-u.ofdm.constellation = QAM_AUTO;
   p-u.ofdm.code_rate_HP = FEC_AUTO;
   p-u.ofdm.code_rate_LP = FEC_AUTO;
 diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
 index 493a2bf..36a3ed6 100644
 --- a/include/linux/dvb/frontend.h
 +++ b/include/linux/dvb/frontend.h
 @@ -175,14 +175,20 @@ typedef enum fe_transmit_mode {
   TRANSMISSION_MODE_2K,
   TRANSMISSION_MODE_8K,
   TRANSMISSION_MODE_AUTO,
 - TRANSMISSION_MODE_4K
 + TRANSMISSION_MODE_4K,
 + TRANSMISSION_MODE_1K,
 + TRANSMISSION_MODE_16K,
 + TRANSMISSION_MODE_32K,
  } fe_transmit_mode_t;
  
  typedef enum fe_bandwidth {
   BANDWIDTH_8_MHZ,
   BANDWIDTH_7_MHZ,
   BANDWIDTH_6_MHZ,
 - BANDWIDTH_AUTO
 + BANDWIDTH_AUTO,
 + BANDWIDTH_5_MHZ,
 + BANDWIDTH_10_MHZ,
 + BANDWIDTH_1_712_MHZ,
  } fe_bandwidth_t;
  
 
 @@ -191,7 +197,10 @@ typedef enum fe_guard_interval {
   GUARD_INTERVAL_1_16,
   GUARD_INTERVAL_1_8,
   GUARD_INTERVAL_1_4,
 - GUARD_INTERVAL_AUTO
 + GUARD_INTERVAL_AUTO,
 + GUARD_INTERVAL_1_128,
 + GUARD_INTERVAL_19_128,
 + GUARD_INTERVAL_19_256,
  } fe_guard_interval_t;
  
 
 @@ -305,7 +314,9 @@ struct dvb_frontend_event {
  
  #define DTV_ISDBS_TS_ID  42
  
 -#define DTV_MAX_COMMAND  DTV_ISDBS_TS_ID
 +#define DTV_DVBT2_PLP_ID 43
 +
 +#define DTV_MAX_COMMAND  DTV_DVBT2_PLP_ID
  
  typedef enum fe_pilot {
   PILOT_ON,
 @@ -337,6 +348,7 @@ typedef enum fe_delivery_system {
   SYS_DMBTH,
   SYS_CMMB,
   SYS_DAB,
 + SYS_DVBT2,
  } fe_delivery_system_t;
  
  struct dtv_cmds_h {
 diff --git a/include/linux/dvb/version.h b/include/linux/dvb/version.h
 index 5a7546c..1421cc8 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

i2c_gate_ctrl question

[Steve Kerrison]

Hi media men  women,

I have a question regarding the cxd2820r I'm working on with a couple of
other people.

In my naivety I implemented i2c gate control for the device (to access
the tuner behind it) as a separate i2c device that did the passthrough.
Now that I realise this, it would make sense to use the gate_ctrl
features.

However, picking apart the USB data it looks as though the way the
cxd2820r implements gate control isn't immediately compatible with the
implementation seen in other devices.

Example, and I2C send to the tuner at (addr  1) of:
{ xx, xx, ..., xx}

becomes a write to (demod_addr  1) of :
{ 09, (addr  1) | flags, xx, xx, ..., xx}

And an i2c receive is implemented to a receive from the demod address,
not from the tuner address.

So, unless there are open and close gate commands that aren't apparent
from the snoop, or there's something I've missed, all i2c transfers to
the tuner have to be mangled - sorry I mean encapsulated - prior to
sending. To my understanding this doesn't fit in with the gate_ctrl
implementation for i2c.

I haven't had time to examine all other gate control implementations in
the media modules, so if anyone knows any good examples that might work
in a similar way, I'd appreciate the tip-off. Otherwise, would there be
any objections to my implementation of a dummy i2c device that does the
encapsulation?

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.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

em28xx: dvb lock bug on re-plug of device?

[Steve Kerrison]

Hi all,

I wonder if Devin/Mauro could help me with something as I've run into a
problem developing a driver for the PCTV 290e?

First plug of the device works fine, em28xx and em28xx_dvb are loaded.
However, if I disconnect and then re-plug the device, the em28xx_dvb
module will hang in dvb_init() where it performs mutex_lock(dev-lock);

It looks like the code to handle udev locking runs into a problem
if the em28xx_dvb is already loaded. I'm referring to this:
https://patchwork.kernel.org/patch/91160/

I don't have any other em28xx DVB devices to test against at the moment.
I have modified dvb_init to give up if it doesn't get a lock straight
away. This is not a valid fix, but it means I can run rmmod instead of
rebooting.

Below is a copy of khubd's complaint about the hangup. I pulled from
media_tree.git. Perhaps this is already fixed in another branch? Thanks.

[31498.792677] INFO: task khubd:28 blocked for more than 120 seconds.
[31498.792682] echo 0  /proc/sys/kernel/hung_task_timeout_secs
disables this message.
[31498.792685] khubd   D 880232d59a58 028  2
0x
[31498.792689]  880232d4d6b0 0046 880232d4d600
81036bb9
[31498.792692]  00013a80 880232d596c0 880232d59a58
880232d4dfd8
[31498.792695]  880232d59a60 00013a80 880232d4c010
00013a80
[31498.792699] Call Trace:
[31498.792708]  [81036bb9] ? default_spin_lock_flags+0x9/0x10
[31498.792714]  [81598817] __mutex_lock_slowpath+0xf7/0x180
[31498.792717]  [815986fb] mutex_lock+0x2b/0x50
[31498.792722]  [a07f43c9] dvb_init+0x69/0xc20 [em28xx_dvb]
[31498.792730]  [a07a84c2] em28xx_init_extension+0x42/0x70
[em28xx]
[31498.792735]  [a07a7e89] em28xx_usb_probe+0x6a9/0xb10
[em28xx]
[31498.792741]  [814173c3] usb_probe_interface+0xf3/0x210
[31498.792746]  [813979f6] driver_probe_device+0x96/0x1c0
[31498.792749]  [81397bc0] ? __device_attach+0x0/0x60
[31498.792751]  [81397c13] __device_attach+0x53/0x60
[31498.792755]  [81396a88] bus_for_each_drv+0x68/0x90
[31498.792757]  [81397cdf] device_attach+0x8f/0xb0
[31498.792760]  [8139685d] bus_probe_device+0x2d/0x50
[31498.792764]  [813951c9] device_add+0x639/0x710
[31498.792767]  [81393a01] ? dev_set_name+0x41/0x50
[31498.792770]  [81415a26] usb_set_configuration+0x606/0x6d0
[31498.792774]  [8141f064] generic_probe+0x44/0xa0
[31498.792777]  [81416c10] usb_probe_device+0x30/0x60
[31498.792779]  [813979f6] driver_probe_device+0x96/0x1c0
[31498.792782]  [81397bc0] ? __device_attach+0x0/0x60
[31498.792784]  [81397c13] __device_attach+0x53/0x60
[31498.792787]  [81396a88] bus_for_each_drv+0x68/0x90
[31498.792789]  [81397cdf] device_attach+0x8f/0xb0
[31498.792792]  [8139685d] bus_probe_device+0x2d/0x50
[31498.792795]  [813951c9] device_add+0x639/0x710
[31498.792797]  [81415279] ? usb_cache_string+0x99/0xb0
[31498.792800]  [8140e3cb] usb_new_device+0x9b/0x140
[31498.792803]  [8140f428] hub_thread+0xc18/0x11a0
[31498.792806]  [8105afee] ? dequeue_task_fair+0x29e/0x2b0
[31498.792811]  [81083000] ? autoremove_wake_function+0x0/0x40
[31498.792813]  [8140e810] ? hub_thread+0x0/0x11a0
[31498.792816]  [81082ab6] kthread+0x96/0xa0
[31498.792820]  [8100cde4] kernel_thread_helper+0x4/0x10
[31498.792823]  [81082a20] ? kthread+0x0/0xa0
[31498.792825]  [8100cde0] ? kernel_thread_helper+0x0/0x10
[31498.792868] INFO: task usb_id:19221 blocked for more than 120
seconds.
[31498.792870] echo 0  /proc/sys/kernel/hung_task_timeout_secs
disables this message.
[31498.792872] usb_id  D 8802016b8398 0 19221  1
0x
[31498.792875]  88018ac9fda8 0082 03a65c58

[31498.792878]  00013a80 8802016b8000 8802016b8398
88018ac9ffd8
[31498.792882]  8802016b83a0 00013a80 88018ac9e010
00013a80
[31498.792885] Call Trace:
[31498.792888]  [81598817] __mutex_lock_slowpath+0xf7/0x180
[31498.792891]  [815986fb] mutex_lock+0x2b/0x50
[31498.792895]  [8141a51f] show_manufacturer+0x2f/0x70
[31498.792898]  [81393a37] dev_attr_show+0x27/0x50
[31498.792904]  [8110abae] ? __get_free_pages+0xe/0x50
[31498.792910]  [811c6e9e] sysfs_read_file+0xce/0x1c0
[31498.792914]  [81159995] vfs_read+0xc5/0x190
[31498.792916]  [81159b61] sys_read+0x51/0x90
[31498.792922]  [8100bfc2] system_call_fastpath+0x16/0x1b
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.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: em28xx: dvb lock bug on re-plug of device?

[Steve Kerrison]

Re-sending due to HTML accident.

Thank you Devin, that is useful to know. It means I can have some
confidence in the problem not being caused by my actions. I will focus
my efforts on getting the device working in spite of this, but might
have a chance to look into this bug thereafter.

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Thu, 2011-03-03 at 11:07 -0500, Devin Heitmueller wrote:
 On Thu, Mar 3, 2011 at 11:01 AM, Steve Kerrison st...@stevekerrison.com 
 wrote:
  Hi all,
 
  I wonder if Devin/Mauro could help me with something as I've run into a
  problem developing a driver for the PCTV 290e?
 
  First plug of the device works fine, em28xx and em28xx_dvb are loaded.
  However, if I disconnect and then re-plug the device, the em28xx_dvb
  module will hang in dvb_init() where it performs mutex_lock(dev-lock);
 
 Hi Steve,
 
 I saw this too and brought it to Mauro's attention some months ago
 (because I believed strongly it was related to locking changes).  It
 looks like he never did anything to address it though (and I've been
 working on other bridges so haven't had any time to dig into it).
 
 So, for what it's worth, I can confirm the problem that you are experiencing.
 
 Devin
 

--
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

CXD2820 PCTV nanoStick T2 290e bringup

[Steve Kerrison]

Hello everyone,

I've done some work on bringup of this device in Linux, and now have a
stub for the CXD2820 demod that includes the capability to pass I2C
commands through to the tuner that sits behind it.

The focus was on bringup, not compatibility with linux-media or Linus'
coding guidelines, but hopefully it's not so horrendous that it makes
you want to cry. This isn't a formal patch submission, but anyone with
an interest is welcome to read more and grab the patch here:
http://stevekerrison.com/290e/index.html#20110227 taking heed of the
warnings and advice where necessary :)

Only I2C passthrough is supported - none of the other demodulator or
frontend functions work, and it doesn't detach properly.

I'd like to know what the best approach would be for me to allow others
to contribute to this if they so wish?

Many thanks,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.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: PCTV nanoStick T2 in stock - Driver work?

[Steve Kerrison]

On Wed, 2011-02-23 at 12:07 -0500, Devin Heitmueller wrote:
 On Wed, Feb 23, 2011 at 11:49 AM, Nicolas Will n...@youplala.net wrote:
  Hello
 
  The DVB-T2 USB stick appears to be in stock in the UK.
 
  Product page:
  http://www.pctvsystems.com/Products/ProductsEuropeAsia/Digitalproducts/PCTVnanoStickT2/tabid/248/language/en-GB/Default.aspx
 
  Play.com, Dabs and Amzon.co.uk list it as in stock.
 
  Is there any work started on a driver at this point?
 
  If no work has started, would a loan/donation of a stick help?
 
  What can be done to trigger/accelerate the provision of a driver?
 
 Somebody would have to break down and reverse engineer the Sony T2
 demod.  I saw something over in mythtv-users where somebody took a
 unit apart and photographed it, and he's suggested that he's started
 working on a driver.
 
 http://stevekerrison.com/290e/index.html
 
 Devin
 
That would be me :)

I have indeed, but don't have much to speak of seeing as when I started
I'd never touched Linux kernel-space driver development.

At the moment I have hardware and usb data from myself and others. I'm
hoping to publish some code that at least initialises the device with
the Sony demod code stub'd so that I and whoever wants to join me, can
attempt to get the demod to spit out some transport streams :)

Donations won't get sony to give me the datasheet, so none requested
right now.

I actually have a free weekend coming up (a rare occurrence) in which I
hope to make some further progress...

Or the short answer: No hardware/donations needed, but things might take
a while!

Regards,
-- 
Steve Kerrison MEng Hons.
http://stevekerrison.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: SAA7160 (Compro E750) Drivers

[Steve Kerrison]

I believe somewhere I have an E700. If somebody does wish to take up
development on this then I am willing to ship it to them provided the
cost isn't prohibitive. Otherwise I will hang on to it and respond to
any requests to run tests if I can.

As far as I'm aware there's not much momentum in PCIe tuner support in
Linux, so this might be a slow mover, or even or a non-starter.

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Fri, 2010-11-26 at 20:37 +1100, Marc Bakker wrote:
 Hi
 
 I'm no developer but I can help test.  I have an Ubuntu 10.10 server and 
 have a Compro E750 dual DVB-T video card which isn't yet supported.  I have 2 
 other tuners working in the machine so I'm happy to take some time to get 
 this new card going because I can live without it :)
 
 What can I do to help?
 
 
 A few bits of info...
 
 lshw
 
 *-multimedia UNCLAIMED
  description: Multimedia controller
  product: SAA7160
  vendor: Philips Semiconductors
  physical id: 0
  bus info: p...@:03:00.0
  version: 03
  width: 64 bits
  clock: 33MHz
  capabilities: msi pciexpress pm bus_master cap_list
  configuration: latency=0
  resources: memory:dff0-dfff
 
 
 lspci
   
   :03:00.0 Multimedia controller: Philips Semiconductors SAA7160 (rev 
 03)
   Subsystem: Compro Technology, Inc. Device e750
   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR+ FastB2B- DisINTx-
   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
 MAbort- SERR- PERR- INTx-
   Latency: 0, Cache Line Size: 64 bytes
   Interrupt: pin A routed to IRQ 11
   Region 0: Memory at dff0 (64-bit, non-prefetchable) [size=1M]
   Capabilities: [40] MSI: Enable- Count=1/32 Maskable- 64bit+
   Address:   Data: 
   Capabilities: [50] Express (v1) Endpoint, MSI 00
   DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 256ns, 
 L1 1us
   ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
   DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
 Unsupported-
   RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
   MaxPayload 128 bytes, MaxReadReq 128 bytes
   DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- 
 TransPend-
   LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency 
 L0 4us, L1 64us
   ClockPM- Surprise- LLActRep- BwNot-
   LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk-
   ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
   LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- 
 DLActive- BWMgmt- ABWMgmt-
   Capabilities: [74] Power Management version 2
   Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
 PME(D0+,D1+,D2+,D3hot-,D3cold-)
   Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
   Capabilities: [80] Vendor Specific Information: Len=50 ?
   Capabilities: [100 v1] Vendor Specific Information: ID= Rev=0 
 Len=088 ?
 
 
 vendor ID's -- 1131:7160 (rev 03)
 
 
 Cheers
 Marc
 
 
 --
 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: DVB-T2 tuner dismantled: PCTV Nanostick T2 290e

[Steve Kerrison]

Hi Konstantin,

That's an interesting observation, and a valid one given, for example,
the addition of QAM-256. I don't know enough about T or T2 to know how
the difference impact the tuner requirements.

Nevertheless, I can receive the T2 mux that is broadcast in my area. It
has to be through my roof antenna, and even when digital switchover is
complete here, I doubt that portable antennas will work particularly
well here then.

If PCTV had the option of using the better tuner, maybe they decided not
to because the cost of the Sony demod pushed up the BoM too far already.
Impossible to say for sure.

I guess we'll have to wait and see if somebody brings out a solution
with TDA18272/Sony demod combo before we can compare reception quality.

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

-Original Message-
From: Konstantin Dimitrov kosio.dimit...@gmail.com
To: st...@stevekerrison.com
Cc: Anca Emanuel anca.eman...@gmail.com, linux-media@vger.kernel.org
Subject: Re: DVB-T2 tuner dismantled: PCTV Nanostick T2 290e
Date:   Wed, 24 Nov 2010 21:11:07 +0200

On Wed, Nov 24, 2010 at 6:44 PM,  st...@stevekerrison.com wrote:

 - it looks like the demod is the only new piece of hardware to deal with

and actually it makes DVB-T2 performance of that device very
questionable (at least in my opinion), because NXP silicon tuner
TDA18271 is old model and not DVB-T2 ready:

http://www.nxp.com/#/pip/pip=[pip=TDA18271HD]|pp=[t=pip,i=TDA18271HD]

like the new DVB-T2 ready NXP silicon tuner TDA18272:

http://www.nxp.com/#/pip/pip=[pip=TDA18272HN_SDS]|pp=[t=pip,i=TDA18272HN_SDS]

and so it's quite reasonable to assume that old silicon tuner designed
for DVB-T such as TDA18271 is not capable to provide optimal
performance for DVB-T2, which has high requirements for sure.

--konstantin
--
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

DVB-T2 tuner dismantled: PCTV Nanostick T2 290e

[Steve Kerrison]

Hello everyone,

One of these arrived at my door today, the world's first USB DVB-T2
tuner. So PCs can finally receive Freeview HD here in the UK... but only
on Windows.

My experience with Linux kernel development is more or less zilch - more
of a spectator sport for me, although I've been subscribed to
linux-media for a couple of months now. I will help how I can, but I
expect that by myself, this would take an awful long time and never make
it into the kernel. So everyone's help is appreciated.

Pics to follow once my camera battery is recharged, but here is
preliminary info:

dmesg
-

[27892.030018] usb 2-2: new high speed USB device using ehci_hcd and
address 54

lsusb
-

Bus 002 Device 054: ID 2013:024f Unknown (Pinnacle?) 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x2013 Unknown (Pinnacle?)
  idProduct  0x024f 
  bcdDevice1.00
  iManufacturer   1 PCTV Systems
  iProduct2 PCTV 290e
  iSerial 3 0006LL9R
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   55
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x  1x 0 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x  1x 0 bytes
bInterval   1
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   1
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x03ac  1x 940 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x03ac  1x 940 bytes
bInterval   1
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x
  (Bus Powered)

PCB
---

It's a very small (smaller than most USB-stick tuners) device,
implemented on two PCBs sandwiched together.

Tuner: NXP TDA18271HDA2
USB IC: Empia em28174 (is this part of the 2874 family, the 2871, or
something else?
http://www.linuxtv.org/wiki/index.php/Em28xx_devices#em2874 )
Demod: Sony CXD2820R

The demod is no surprise given it's about the only T2 compatible demod
out there (LSI might have one too, if memory serves).

So, what's next? Any PCTV Linux driver contributors active here? I will
next attempt to find a datasheet for the Sony demod, then grab some
usbsnoop data, although the only Windows machine I have that can get
near a fixed antenna is Atom powered... so it ain't great.

Questions, requests, demands and insults are all welcomed.

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body

Re: DVB-T2 tuner dismantled: PCTV Nanostick T2 290e

[Steve Kerrison]

Quick correction: The tuner is TDA18271HDC2 not TDA18271HDA2; it's dark
and I'm tired.

Photos are now available at http://www.stevekerrison.com/290e/pics.html

The most interesting are the two PCB shots.

Tuner: http://www.stevekerrison.com/290e/img/tuner.jpg 
Controller/Demod: http://www.stevekerrison.com/290e/img/hastalavista.jpg

I'll put this information into the wiki when I have a chance, and when I
can take some better photos in daylight.

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.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

First DVB-T2 tuner announced - Hauppauge PCTV Nanostick T2 290e

[Steve Kerrison]

Hauppauge has released details of its first DVB-T2 tuner at IFA. Some
scarce details are here:

http://www.wegotserved.com/2010/09/04/ifa-2010-hauppauge-announces-freeview-hd-dvbt2-tuner-pc/

along with a datasheet (without very much data) here:

http://www.wegotserved.com/2010/09/06/ifa-2010-pctv-nanostick-t2-290e-freeview-hd-tuner-full-specs-data-sheet/

Only 720p video support is claimed, but that can't be anything to do
with receiving the mux so I suspect that's a software limitation in the
bundled player.

Does anyone have (or have a means of getting) more info on the internals
of this stick to aid Linux development? I will be attempting to acquire
one of these at first release in October, and will do what I can, from
USB snooping through to module development - as far as my time and skill
can muster.

Regards,
Steve Kerrison.

--
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