From 2add87a95068d6457d4e5824d0417d39007665a4 Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:10 -0700 Subject: [PATCH] dvb: b2c2/flexcop driver refactoring part 2: add modular Flexcop driver b2c2/flexcop driver refactoring to support PCI and USB based cards part 2: add modular Flexcop driver Signed-off-by: Patrick Boettcher Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/README.flexcop | 279 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 279 insertions(+) create mode 100644 Documentation/dvb/README.flexcop (limited to 'Documentation/dvb') diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop new file mode 100644 index 00000000000..9ec735714e4 --- /dev/null +++ b/Documentation/dvb/README.flexcop @@ -0,0 +1,279 @@ +This README escorted the skystar2-driver rewriting procedure. It describes the +state of the new flexcop-driver set and some internals are written down here +too. + +How to do something in here? +============================ + +make -f Makefile.t +make -C ../build-2.6 +./in.sh # load the drivers +./rm.sh # unload the drivers + +Please read this file, if you want to contribute. + +This document hopefully describes things about the flexcop and its +device-offsprings. Goal is to write a easy-to-write and easy-to-read set of +drivers based on the skystar2.c and other information. + +This directory is temporary. It is used for rewriting the skystar2.c and to +create shared code, which then can be used by the usb box as well. + +Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been +touched and rewritten. + +General coding processing +========================= + +We should proceed as follows (as long as no one complains): + +0) Think before start writing code! + +1) rewriting the skystar2.c with the help of the flexcop register descriptions +and splitting up the files to a pci-bus-part and a flexcop-part. +The new driver will be called b2c2-flexcop-pci.ko/b2c2-flexcop-usb.ko for the +device-specific part and b2c2-flexcop.ko for the common flexcop-functions. + +2) Search for errors in the leftover of flexcop-pci.c (compare with pluto2.c +and other pci drivers) + +3) make some beautification (see 'Improvements when rewriting (refactoring) is +done') + +4) Testing the new driver and maybe substitute the skystar2.c with it, to reach +a wider tester audience. + +5) creating an usb-bus-part using the already written flexcop code for the pci +card. + +Idea: create a kernel-object for the flexcop and export all important +functions. This option saves kernel-memory, but maybe a lot of functions have +to be exported to kernel namespace. + + +Current situation +================= + +0) Done :) +1) Done (some minor issues left) +2) Done +3) Not ready yet, more information is necessary +4) next to be done (see the table below) +5) USB driver is working (yes, there are some minor issues) + +What seems to be ready? +----------------------- + +1) Rewriting +1a) i2c is cut off from the flexcop-pci.c and seems to work +1b) moved tuner and demod stuff from flexcop-pci.c to flexcop-tuner-fe.c +1c) moved lnb and diseqc stuff from flexcop-pci.c to flexcop-tuner-fe.c +1e) eeprom (reading MAC address) +1d) sram (no dynamic sll size detection (commented out) (using default as JJ told me)) +1f) misc. register accesses for reading parameters (e.g. resetting, revision) +1g) pid/mac filter (flexcop-hw-filter.c) +1i) dvb-stuff initialization in flexcop.c (done) +1h) dma stuff (now just using the size-irq, instead of all-together, to be done) +1j) remove flexcop initialization from flexcop-pci.c completely (done) +1l) use a well working dma IRQ method (done, see 'Known bugs and problems and TODO') +1k) cleanup flexcop-files (remove unused EXPORT_SYMBOLs, make static from +non-static where possible, moved code to proper places) + +2) Search for errors in the leftover of flexcop-pci.c (partially done) +5a) add MAC address reading + +What to do in the near future? +-------------------------------------- +(no special order here) + + +5) USB driver +5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting) +5c) feeding of ISOC data to the software demux (format of the isochronous data +and speed optimization, no real error) + +Testing changes +--------------- + +O = item is working +P = item is partially working +X = item is not working +N = item does not apply here + = item need to be examined + + | PCI | USB +item | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312 +-------+-------+---------+---------+-------+-------+---------+---------+------- +1a) | O | | | | N | N | N | N +1b) | O | | | | | | O | +1c) | N | N | | | N | N | O | +1d) | O | O +1e) | O | O +1f) | P +1g) | O +1h) | P | +1i) | O | N +1j) | O | N +1l) | O | N +2) | O | N +5a) | N | O +5b)* | N | +5c)* | N | + +* - not done yet + +Known bugs and problems and TODO +-------------------------------- + +1g/h/l) when pid filtering is enabled on the pci card + +DMA usage currently: + The DMA is splitted in 2 equal-sized subbuffers. The Flexcop writes to first + address and triggers an IRQ when it's full and starts writing to the second + address. When the second address is full, the IRQ is triggered again, and + the flexcop writes to first address again, and so on. + The buffersize of each address is currently 640*188 bytes. + + Problem is, when using hw-pid-filtering and doing some low-bandwidth + operation (like scanning) the buffers won't be filled enough to trigger + the IRQ. That's why: + + When PID filtering is activated, the timer IRQ is used. Every 1.97 ms the IRQ + is triggered. Is the current write address of DMA1 different to the one + during the last IRQ, then the data is passed to the demuxer. + + There is an additional DMA-IRQ-method: packet count IRQ. This isn't + implemented correctly yet. + + The solution is to disable HW PID filtering, but I don't know how the DVB + API software demux behaves on slow systems with 45MBit/s TS. + +Solved bugs :) +-------------- +1g) pid-filtering (somehow pid index 4 and 5 (EMM_PID and ECM_PID) aren't +working) +SOLUTION: also index 0 was affected, because net_translation is done for +these indexes by default + +5b) isochronous transfer does only work in the first attempt (for the Sky2PC USB, +Air2PC is working) +SOLUTION: the flexcop was going asleep and never really woke up again (don't +know if this need fixes, see flexcop-fe-tuner.c:flexcop_sleep) + +Improvements when rewriting (refactoring) is done +================================================= + +- split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control + (enable sleeping for other demods than dvb-s) +- add support for CableStar (stv0297 Microtune 203x/ALPS) + +Debugging +--------- +- add verbose debugging to skystar2.c (dump the reg_dw_data) and compare it + with this flexcop, this is important, because i2c is now using the + flexcop_ibi_value union from flexcop-reg.h (do you have a better idea for + that, please tell us so). + +Everything which is identical in the following table, can be put into a common +flexcop-module. + + PCI USB +------------------------------------------------------------------------------- +Different: +Register access: accessing IO memory USB control message +I2C bus: I2C bus of the FC USB control message +Data transfer: DMA isochronous transfer +EEPROM transfer: through i2c bus not clear yet + +Identical: +Streaming: accessing registers +PID Filtering: accessing registers +Sram destinations: accessing registers +Tuner/Demod: I2C bus +DVB-stuff: can be written for common use + +Restrictions: +============ + +We need to create a bus-specific-struct and a flexcop-struct. + +bus-specific-struct: + +struct flexcop_pci +... + +struct flexcop_usb +... + + +struct flexcop_device { + void *bus_specific; /* container for bus-specific struct */ +... +} + +PCI i2c can read/write max 4 bytes at a time, USB can more + +Functions +========= + +Syntax +------ + +- Flexcop functions will be called "flexcop(_[a-z0-9]+)+" and exported as such + if needed. +- Flexcop-device functions will be called "flexcop_device(_[a-z0-9]+)+" and + exported as such if needed. +- Both will be compiled to b2c2-flexcop.ko and their source can be found in the + flexcop*.[hc] + +Callbacks and exports +--------------------- + +Bus-specific functions will be given as callbacks (function pointers) to the +flexcop-module. (within the flexcop_device-struct) + +Initialization process +====================== + +b2c2-flexcop.ko is loaded +b2c2-flexcop-.ko is loaded + +suppose a device is found: +malloc flexcop and the bus-specific variables (via flexcop_device_malloc) +fill the bus-specific variable +fill the flexcop variable (especially the bus-specific callbacks) +bus-specific initialization + - ... +do the common initialization (via flexcop_device_initialize) + - reset the card + - determine flexcop type (II, IIB, III) + - hw_filters (bus dependent) + - 0x204 + - set sram size + - create the dvb-stuff + - create i2c stuff + - frontend-initialization +done +bus specific: + - media_destination (this and the following 3 are bus specific) + - cai_dest + - cao_dest + - net_destination + +Bugs fixed while rewriting the driver +===================================== + +- EEPROM access (to read the MAC address) was fixed to death some time last + year. (fixed here and in skystar2.c) (Bjarne, this was the piece of code + (fix-chipaddr) we were wondering about) + + +Acknowledgements (just for the rewriting part) +================ + +Bjarne Steinsbo thought a lot in the first place of the pci part for this code +sharing idea. + +Andreas Oberritter for providing a recent PCI initialization template (pluto2.c). + +comments, critics and ideas to linux-dvb@linuxtv.org or patrick.boettcher@desy.de -- cgit v1.2.3-18-g5258 From 3ed8a31cb387b2ae3e4ca508f973931b61e6f6bd Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:13 -0700 Subject: [PATCH] dvb: flexcop: add acknowledgements add acknowledgements Signed-off-by: Patrick Boettcher Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/README.flexcop | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation/dvb') diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop index 9ec735714e4..8036faa1ead 100644 --- a/Documentation/dvb/README.flexcop +++ b/Documentation/dvb/README.flexcop @@ -274,6 +274,11 @@ Acknowledgements (just for the rewriting part) Bjarne Steinsbo thought a lot in the first place of the pci part for this code sharing idea. -Andreas Oberritter for providing a recent PCI initialization template (pluto2.c). +Andreas Oberritter for providing a recent PCI initialization template +(pluto2.c). + +Boleslaw Ciesielski for pointing out a problem with firmware loader. + +Vadim Catana for correcting the USB transfer. comments, critics and ideas to linux-dvb@linuxtv.org or patrick.boettcher@desy.de -- cgit v1.2.3-18-g5258 From c6ee197ccf4af454638c044706f0ba7ef6c1bb76 Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:17 -0700 Subject: [PATCH] dvb: flexcop: readme update readme update Signed-off-by: Patrick Boettcher Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/README.flexcop | 121 +++++++-------------------------------- 1 file changed, 21 insertions(+), 100 deletions(-) (limited to 'Documentation/dvb') diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop index 8036faa1ead..a50c70f9ca7 100644 --- a/Documentation/dvb/README.flexcop +++ b/Documentation/dvb/README.flexcop @@ -2,26 +2,20 @@ This README escorted the skystar2-driver rewriting procedure. It describes the state of the new flexcop-driver set and some internals are written down here too. -How to do something in here? -============================ - -make -f Makefile.t -make -C ../build-2.6 -./in.sh # load the drivers -./rm.sh # unload the drivers - -Please read this file, if you want to contribute. - This document hopefully describes things about the flexcop and its -device-offsprings. Goal is to write a easy-to-write and easy-to-read set of +device-offsprings. Goal was to write an easy-to-write and easy-to-read set of drivers based on the skystar2.c and other information. -This directory is temporary. It is used for rewriting the skystar2.c and to -create shared code, which then can be used by the usb box as well. - Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been touched and rewritten. +History & News +============== + 2005-04-01 - correct USB ISOC transfers (thanks to Vadim Catana) + + + + General coding processing ========================= @@ -81,16 +75,15 @@ non-static where possible, moved code to proper places) 2) Search for errors in the leftover of flexcop-pci.c (partially done) 5a) add MAC address reading +5c) feeding of ISOC data to the software demux (format of the isochronous data +and speed optimization, no real error) (thanks to Vadim Catana) What to do in the near future? -------------------------------------- (no special order here) - 5) USB driver 5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting) -5c) feeding of ISOC data to the software demux (format of the isochronous data -and speed optimization, no real error) Testing changes --------------- @@ -118,7 +111,7 @@ item | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312 2) | O | N 5a) | N | O 5b)* | N | -5c)* | N | +5c) | N | O * - not done yet @@ -155,17 +148,21 @@ working) SOLUTION: also index 0 was affected, because net_translation is done for these indexes by default -5b) isochronous transfer does only work in the first attempt (for the Sky2PC USB, -Air2PC is working) -SOLUTION: the flexcop was going asleep and never really woke up again (don't -know if this need fixes, see flexcop-fe-tuner.c:flexcop_sleep) +5b) isochronous transfer does only work in the first attempt (for the Sky2PC +USB, Air2PC is working) SOLUTION: the flexcop was going asleep and never really +woke up again (don't know if this need fixes, see +flexcop-fe-tuner.c:flexcop_sleep) + +NEWS: when the driver is loaded and unloaded and loaded again (w/o doing +anything in the while the driver is loaded the first time), no transfers take +place anymore. Improvements when rewriting (refactoring) is done ================================================= - split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control (enable sleeping for other demods than dvb-s) -- add support for CableStar (stv0297 Microtune 203x/ALPS) +- add support for CableStar (stv0297 Microtune 203x/ALPS) (almost done, incompatibilities with the Nexus-CA) Debugging --------- @@ -192,82 +189,6 @@ Sram destinations: accessing registers Tuner/Demod: I2C bus DVB-stuff: can be written for common use -Restrictions: -============ - -We need to create a bus-specific-struct and a flexcop-struct. - -bus-specific-struct: - -struct flexcop_pci -... - -struct flexcop_usb -... - - -struct flexcop_device { - void *bus_specific; /* container for bus-specific struct */ -... -} - -PCI i2c can read/write max 4 bytes at a time, USB can more - -Functions -========= - -Syntax ------- - -- Flexcop functions will be called "flexcop(_[a-z0-9]+)+" and exported as such - if needed. -- Flexcop-device functions will be called "flexcop_device(_[a-z0-9]+)+" and - exported as such if needed. -- Both will be compiled to b2c2-flexcop.ko and their source can be found in the - flexcop*.[hc] - -Callbacks and exports ---------------------- - -Bus-specific functions will be given as callbacks (function pointers) to the -flexcop-module. (within the flexcop_device-struct) - -Initialization process -====================== - -b2c2-flexcop.ko is loaded -b2c2-flexcop-.ko is loaded - -suppose a device is found: -malloc flexcop and the bus-specific variables (via flexcop_device_malloc) -fill the bus-specific variable -fill the flexcop variable (especially the bus-specific callbacks) -bus-specific initialization - - ... -do the common initialization (via flexcop_device_initialize) - - reset the card - - determine flexcop type (II, IIB, III) - - hw_filters (bus dependent) - - 0x204 - - set sram size - - create the dvb-stuff - - create i2c stuff - - frontend-initialization -done -bus specific: - - media_destination (this and the following 3 are bus specific) - - cai_dest - - cao_dest - - net_destination - -Bugs fixed while rewriting the driver -===================================== - -- EEPROM access (to read the MAC address) was fixed to death some time last - year. (fixed here and in skystar2.c) (Bjarne, this was the piece of code - (fix-chipaddr) we were wondering about) - - Acknowledgements (just for the rewriting part) ================ @@ -281,4 +202,4 @@ Boleslaw Ciesielski for pointing out a problem with firmware loader. Vadim Catana for correcting the USB transfer. -comments, critics and ideas to linux-dvb@linuxtv.org or patrick.boettcher@desy.de +comments, critics and ideas to linux-dvb@linuxtv.org. -- cgit v1.2.3-18-g5258 From 71e3420111530273f2b26fabfac4d021c2a2b79f Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:36 -0700 Subject: [PATCH] dvb: tda10046: support for different firmware versions added support for different tda10046 firmware versions. tested with v20, v21 and v25. (Andreas Oberritter) Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/get_dvb_firmware | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation/dvb') diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 3ffdcb39429..a750f0101d9 100644 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -107,7 +107,7 @@ sub tda10045 { sub tda10046 { my $sourcefile = "tt_budget_217g.zip"; my $url = "http://www.technotrend.de/new/217g/$sourcefile"; - my $hash = "a25b579e37109af60f4a36c37893957c"; + my $hash = "6a7e1e2f2644b162ff0502367553c72d"; my $outfile = "dvb-fe-tda10046.fw"; my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); @@ -115,7 +115,7 @@ sub tda10046 { wgetfile($sourcefile, $url); unzip($sourcefile, $tmpdir); - extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24479, "$tmpdir/fwtmp"); + extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24478, "$tmpdir/fwtmp"); verify("$tmpdir/fwtmp", $hash); copy("$tmpdir/fwtmp", $outfile); -- cgit v1.2.3-18-g5258 From daeb6aa40be55b0750aea92dea78b8ebc40ca9a8 Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:40 -0700 Subject: [PATCH] dvb: bt8xx: update documentation update bt8xx documentation (Uwe Bugla) Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/bt8xx.txt | 29 +++++++++-------------------- 1 file changed, 9 insertions(+), 20 deletions(-) (limited to 'Documentation/dvb') diff --git a/Documentation/dvb/bt8xx.txt b/Documentation/dvb/bt8xx.txt index e3cacf4f234..d84df8072d7 100644 --- a/Documentation/dvb/bt8xx.txt +++ b/Documentation/dvb/bt8xx.txt @@ -17,34 +17,23 @@ Because of this, you need to enable "Device drivers" => "Multimedia devices" => "Video For Linux" => "BT848 Video For Linux" +Furthermore you need to enable +"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices" + => "DVB for Linux" "DVB Core Support" "Nebula/Pinnacle PCTV/TwinHan PCI Cards" + 2) Loading Modules ================== In general you need to load the bttv driver, which will handle the gpio and -i2c communication for us. Next you need the common dvb-bt8xx device driver -and one frontend driver. - -The bttv driver will HANG YOUR SYSTEM IF YOU DO NOT SPECIFY THE CORRECT -CARD ID! - -(If you don't get your card running and you suspect that the card id you're -using is wrong, have a look at "bttv-cards.c" for a list of possible card -ids.) - -Pay attention to failures when you load the frontend drivers -(e.g. dmesg, /var/log/messages). +i2c communication for us, plus the common dvb-bt8xx device driver. +The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110) and +TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver. 3a) Nebula / Pinnacle PCTV -------------------------- - $ modprobe bttv i2c_hw=1 card=0x68 - $ modprobe dvb-bt8xx - -For Nebula cards use the "nxt6000" frontend driver: - $ modprobe nxt6000 - -For Pinnacle PCTV cards use the "cx24110" frontend driver: - $ modprobe cx24110 + $ modprobe bttv (normally bttv is being loaded automatically by kmod) + $ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading) 3b) TwinHan ----------- -- cgit v1.2.3-18-g5258 From 50b215a05878ce9636dace6cd21f7e91ff005058 Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:41 -0700 Subject: [PATCH] dvb: DST: reorganize Twinhan DST driver to support CI - reorganize Twinhan DST driver to support CI - add support for more cards (Manu Abraham) Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/ci.txt | 219 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 219 insertions(+) create mode 100644 Documentation/dvb/ci.txt (limited to 'Documentation/dvb') diff --git a/Documentation/dvb/ci.txt b/Documentation/dvb/ci.txt new file mode 100644 index 00000000000..62e0701b542 --- /dev/null +++ b/Documentation/dvb/ci.txt @@ -0,0 +1,219 @@ +* For the user +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +NOTE: This document describes the usage of the high level CI API as +in accordance to the Linux DVB API. This is a not a documentation for the, +existing low level CI API. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To utilize the High Level CI capabilities, + +(1*) This point is valid only for the Twinhan/clones + For the Twinhan/Twinhan clones, the dst_ca module handles the CI + hardware handling.This module is loaded automatically if a CI + (Common Interface, that holds the CAM (Conditional Access Module) + is detected. + +(2) one requires a userspace application, ca_zap. This small userland + application is in charge of sending the descrambling related information + to the CAM. + +This application requires the following to function properly as of now. + + (a) Tune to a valid channel, with szap. + eg: $ szap -c channels.conf -r "TMC" -x + + (b) a channels.conf containing a valid PMT PID + + eg: TMC:11996:h:0:27500:278:512:650:321 + + here 278 is a valid PMT PID. the rest of the values are the + same ones that szap uses. + + (c) after running a szap, you have to run ca_zap, for the + descrambler to function, + + eg: $ ca_zap patched_channels.conf "TMC" + + The patched means a patch to apply to scan, such that scan can + generate a channels.conf_with pmt, which has this PMT PID info + (NOTE: szap cannot use this channels.conf with the PMT_PID) + + + (d) Hopeflly Enjoy your favourite subscribed channel as you do with + a FTA card. + +(3) Currently ca_zap, and dst_test, both are meant for demonstration + purposes only, they can become full fledged applications if necessary. + + +* Cards that fall in this category +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +At present the cards that fall in this category are the Twinhan and it's +clones, these cards are available as VVMER, Tomato, Hercules, Orange and +so on. + +* CI modules that are supported +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The CI module support is largely dependant upon the firmware on the cards +Some cards do support almost all of the available CI modules. There is +nothing much that can be done in order to make additional CI modules +working with these cards. + +Modules that have been tested by this driver at present are + +(1) Irdeto 1 and 2 from SCM +(2) Viaccess from SCM +(3) Dragoncam + +* The High level CI API +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* For the programmer +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +With the High Level CI approach any new card with almost any random +architecture can be implemented with this style, the definitions +insidethe switch statement can be easily adapted for any card, thereby +eliminating the need for any additional ioctls. + +The disadvantage is that the driver/hardware has to manage the rest. For +the application programmer it would be as simple as sending/receiving an +array to/from the CI ioctls as defined in the Linux DVB API. No changes +have been made in the API to accomodate this feature. + + +* Why the need for another CI interface ? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This is one of the most commonly asked question. Well a nice question. +Strictly speaking this is not a new interface. + +The CI interface is defined in the DVB API in ca.h as + +typedef struct ca_slot_info { + int num; /* slot number */ + + int type; /* CA interface this slot supports */ +#define CA_CI 1 /* CI high level interface */ +#define CA_CI_LINK 2 /* CI link layer level interface */ +#define CA_CI_PHYS 4 /* CI physical layer level interface */ +#define CA_DESCR 8 /* built-in descrambler */ +#define CA_SC 128 /* simple smart card interface */ + + unsigned int flags; +#define CA_CI_MODULE_PRESENT 1 /* module (or card) inserted */ +#define CA_CI_MODULE_READY 2 +} ca_slot_info_t; + + + +This CI interface follows the CI high level interface, which is not +implemented by most applications. Hence this area is revisited. + +This CI interface is quite different in the case that it tries to +accomodate all other CI based devices, that fall into the other categories + +This means that this CI interface handles the EN50221 style tags in the +Application layer only and no session management is taken care of by the +application. The driver/hardware will take care of all that. + +This interface is purely an EN50221 interface exchanging APDU's. This +means that no session management, link layer or a transport layer do +exist in this case in the application to driver communication. It is +as simple as that. The driver/hardware has to take care of that. + + +With this High Level CI interface, the interface can be defined with the +regular ioctls. + +All these ioctls are also valid for the High level CI interface + +#define CA_RESET _IO('o', 128) +#define CA_GET_CAP _IOR('o', 129, ca_caps_t) +#define CA_GET_SLOT_INFO _IOR('o', 130, ca_slot_info_t) +#define CA_GET_DESCR_INFO _IOR('o', 131, ca_descr_info_t) +#define CA_GET_MSG _IOR('o', 132, ca_msg_t) +#define CA_SEND_MSG _IOW('o', 133, ca_msg_t) +#define CA_SET_DESCR _IOW('o', 134, ca_descr_t) +#define CA_SET_PID _IOW('o', 135, ca_pid_t) + + +On querying the device, the device yields information thus + +CA_GET_SLOT_INFO +---------------------------- +Command = [info] +APP: Number=[1] +APP: Type=[1] +APP: flags=[1] +APP: CI High level interface +APP: CA/CI Module Present + +CA_GET_CAP +---------------------------- +Command = [caps] +APP: Slots=[1] +APP: Type=[1] +APP: Descrambler keys=[16] +APP: Type=[1] + +CA_SEND_MSG +---------------------------- +Descriptors(Program Level)=[ 09 06 06 04 05 50 ff f1] +Found CA descriptor @ program level + +(20) ES type=[2] ES pid=[201] ES length =[0 (0x0)] +(25) ES type=[4] ES pid=[301] ES length =[0 (0x0)] +ca_message length is 25 (0x19) bytes +EN50221 CA MSG=[ 9f 80 32 19 03 01 2d d1 f0 08 01 09 06 06 04 05 50 ff f1 02 e0 c9 00 00 04 e1 2d 00 00] + + +Not all ioctl's are implemented in the driver from the API, the other +features of the hardware that cannot be implemented by the API are achieved +using the CA_GET_MSG and CA_SEND_MSG ioctls. An EN50221 style wrapper is +used to exchange the data to maintain compatibility with other hardware. + + +/* a message to/from a CI-CAM */ +typedef struct ca_msg { + unsigned int index; + unsigned int type; + unsigned int length; + unsigned char msg[256]; +} ca_msg_t; + + +The flow of data can be described thus, + + + + + + App (User) + ----- + parse + | + | + v + en50221 APDU (package) + -------------------------------------- + | | | High Level CI driver + | | | + | v | + | en50221 APDU (unpackage) | + | | | + | | | + | v | + | sanity checks | + | | | + | | | + | v | + | do (H/W dep) | + -------------------------------------- + | Hardware + | + v + + + + +The High Level CI interface uses the EN50221 DVB standard, following a +standard ensures futureproofness. -- cgit v1.2.3-18-g5258 From df481ae59074756f1d0b2712d8b3fe8d04eb16c1 Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:45 -0700 Subject: [PATCH] dvb: bt8xx: updated documentation updated documentation (Manu Abraham) Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/bt8xx.txt | 42 ++++++++++++++++-------------------------- 1 file changed, 16 insertions(+), 26 deletions(-) (limited to 'Documentation/dvb') diff --git a/Documentation/dvb/bt8xx.txt b/Documentation/dvb/bt8xx.txt index d84df8072d7..d64430bf4bb 100644 --- a/Documentation/dvb/bt8xx.txt +++ b/Documentation/dvb/bt8xx.txt @@ -35,45 +35,35 @@ TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver. $ modprobe bttv (normally bttv is being loaded automatically by kmod) $ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading) -3b) TwinHan ------------ + +3b) TwinHan and Clones +-------------------------- $ modprobe bttv i2c_hw=1 card=0x71 $ modprobe dvb-bt8xx $ modprobe dst -The value 0x71 will override the PCI type detection for dvb-bt8xx, which -is necessary for TwinHan cards.# +The value 0x71 will override the PCI type detection for dvb-bt8xx, +which is necessary for TwinHan cards. -If you're having an older card (blue color circuit) and card=0x71 locks your -machine, try using 0x68, too. If that does not work, ask on the DVB mailing list. +If you're having an older card (blue color circuit) and card=0x71 locks +your machine, try using 0x68, too. If that does not work, ask on the +mailing list. -The DST module takes a couple of useful parameters, in case the -dst drivers fails to detect your type of card correctly. +The DST module takes a couple of useful parameters. -dst_type takes values 0 (satellite), 1 (terrestial TV), 2 (cable). +verbose takes values 0 to 5. These values control the verbosity level. -dst_type_flags takes bit combined values: -1 = new tuner type packets. You can use this if your card is detected - and you have debug and you continually see the tuner packets not - working (make sure not a basic problem like dish alignment etc.) +debug takes values 0 and 1. You can either disable or enable debugging. -2 = TS 204. If your card tunes OK, but the picture is terrible, seemingly - breaking up in one half continually, and crc fails a lot, then - this is worth a try (or trying to turn off) +dst_addons takes values 0 and 0x20. A value of 0 means it is a FTA card. +0x20 means it has a Conditional Access slot. -4 = has symdiv. Some cards, mostly without new tuner packets, require - a symbol division algorithm. Doesn't apply to terrestial TV. - -You can also specify a value to have the autodetected values turned off -(e.g. 0). The autodected values are determined bythe cards 'response +The autodected values are determined bythe cards 'response string' which you can see in your logs e.g. -dst_check_ci: recognize DST-MOT - -or +dst_get_device_id: Recognise [DSTMCI] -dst_check_ci: unable to recognize DSTXCI or STXCI -- -Authors: Richard Walker, Jamie Honan, Michael Hunold +Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham -- cgit v1.2.3-18-g5258