[linux-dvb] mt352/bt878 cleanups, DVICO FusionHDTV DVB-T1/DVB-T Lite patches

[Christopher Pascoe <c.pascoe@itee.uq.edu.au>]

Hi,

The two times I've sent this mail with patches attached, it hasn't made it
to the list...  So, I'm trying again without them.  See
  http://www.itee.uq.edu.au/~chrisp/DVICO-Linux/patches/
for the "attachments".

Regards,
Chris

---------- Forwarded message ----------

Hello,

Attached are a set of patches to cleanup the mt352 frontend and add
support for the DVICO FusionHDTV DVB-T1 and FusionHDTV DVB-T Lite boards
into the dvb-kernel tree.  These were seemingly lost earlier on (mail
server changes?), so I have rediffed against the current CVS.

Note that to use this with either of the DVICO FusionHDTV DVB-T boards you
will need to fetch and build against a recent snapshot of the video4linux
code that you can obtain from http://dl.bytesex.org/cvs-snapshots/.  This
will get you the board ID for the Lite board, and/or the kernel I2C
support needed for the DVB-T1.

For those who have been waiting to use the DVICO FusionHDTV DVB-T Lite
board with this - sorry for the delays in resending this.  I had been
holding out for CVS access so that I could break these patches up into
much smaller parts (which could still be some time off) and also had a
brief hospital trip.  Could someone who currently has access please commit
this code - it is well tested.

Cleanups (mt352-0-cleanup.patch) include:
  - moving the card_type and dvb_frontend_info structure into the adapter
    state to permit more than one card type in a system at once converting
    the force_card parameter to an array to permit the same;
  - removing incorrect "shift" values reintroduced by the merge of the
    TDTC9251DH01C driver which was based on an old version of the code
    with incorrect values - changes discussed and tested by Antonio
    Mancuso;
  - removing the incorrect use of I2C_M_NOSTART from the driver.  The
    only boards where this worked were the boards where use_i2c_hw
    was enabled in the bttv driver, and there only because the i2c_hw
    code ignores the I2C_M_NOSTART flag and always generates a start
    condition.  On other boards where the clag is respected, this
    violates the i2c protocol and causes only errors.  No-op;
  - cleaning up some double initialisation (specifically that of the
    ACQ_CTL register - no-op;
  - converts some routines to pass the true frequency around, rather
    than the frequency in MHz - need the real frequency for other
    boards - no-op;
  - ignoring FEC_NONE for the LP coderate in the case where OFDM
    hierarchy mode is either set to be auto-detected or is disabled.
    The demodulator ignores our settings anyway;
  - changing the detect_avermedia function to a more generic function
    that can be used to detect other bt878 or cx2388x cards in a
    similar way;
  - rounding the frequency programmed into the PLL so that it will be
    closer to the desired received frequency;
  - decoupling requirement for FE_REGISTER/FE_UNREGISTER to be called
    synchronously from within mt352_attach_adapter/mt352_detach_client,
    so that mt352 can be used with drivers such as cx88 which have
    i2c and DVB support in separate modules.

The DVICO hardware support (mt352-1-dvico.patch):
  - introduces functionality for the DVICO FusionHDTV DVB-T1 and
    DVICO FusionHDTV DVB-T Lite boards in the mt352 frontend;
  - activates autodetection for these boards;

The dvb-bt8xx patch (dvb-bt8xx.patch):
  - adds hardware support for the DVICO FusionHDTV DVB-T Lite
  - adds functionality to the bt8xx code to switch on/off DMA of the
    transport stream only when the DVB layer wants data, rather than
    generating a constant interrupt stream the entire time that the
    driver is loaded.

The mt352 speedup patch (mt352-2-speedups.patch) helps with tuning
speed on the mt352 frontend, by:
  - reinitialising the frontend only in the case when it has not yet
    been initialised or when it has been put to sleep;
  - ignoring requests from the frontend thread to repetitively acquire
    a transponder with the same parameters.  Each time it does this,
    the tuner/demodulator lose sync and acquisition time is needlessly
    extended.

Regards
Chris
-- 
Christopher Pascoe
IT Infrastructure Manager
School of Information Technology and Electrical Engineering
The University of Queensland   Brisbane  QLD  4072  Australia