An error occurred fetching the project authors.
  1. 18 Mar, 2013 2 commits
  2. 15 Feb, 2013 1 commit
  3. 23 Jan, 2013 2 commits
  4. 27 Dec, 2012 2 commits
  5. 28 Oct, 2012 1 commit
    • Mauro Carvalho Chehab's avatar
      [media] dvb_frontend: Don't declare values twice at a table · e6ea0b91
      Mauro Carvalho Chehab authored
      drivers/media/dvb-core/dvb_frontend.c:1032:2: warning: initialized field overwritten [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1032:2: warning: (near initialization for 'dtv_cmds[36]') [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1033:2: warning: initialized field overwritten [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1033:2: warning: (near initialization for 'dtv_cmds[37]') [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1034:2: warning: initialized field overwritten [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1034:2: warning: (near initialization for 'dtv_cmds[38]') [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1035:2: warning: initialized field overwritten [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1035:2: warning: (near initialization for 'dtv_cmds[39]') [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1036:2: warning: initialized field overwritten [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1036:2: warning: (near initialization for 'dtv_cmds[40]') [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1037:2: warning: initialized field overwritten [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1037:2: warning: (near initialization for 'dtv_cmds[60]') [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1045:2: warning: initialized field overwritten [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1045:2: warning: (near initialization for 'dtv_cmds[46]') [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1051:2: warning: initialized field overwritten [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1051:2: warning: (near initialization for 'dtv_cmds[52]') [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1060:2: warning: initialized field overwritten [-Woverride-init]
      drivers/media/dvb-core/dvb_frontend.c:1060:2: warning: (near initialization for 'dtv_cmds[61]') [-Woverride-init]
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      e6ea0b91
  6. 07 Oct, 2012 2 commits
  7. 27 Sep, 2012 2 commits
  8. 23 Sep, 2012 1 commit
  9. 10 Sep, 2012 2 commits
  10. 15 Aug, 2012 2 commits
  11. 14 Aug, 2012 1 commit
  12. 13 Aug, 2012 2 commits
  13. 12 Aug, 2012 1 commit
  14. 20 May, 2012 2 commits
  15. 08 May, 2012 1 commit
  16. 18 Apr, 2012 1 commit
  17. 09 Apr, 2012 2 commits
    • Hans Petter Selasky's avatar
      [media] dvb_frontend: fix compiler warning · c065f5b4
      Hans Petter Selasky authored
      has_get_frontend() should return a boolean, not a pointer.
      Signed-off-by: default avatarHans Petter Selasky <hselasky@c2i.net>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      c065f5b4
    • Chris Rankin's avatar
      [media] dvb_frontend: regression fix: userspace ABI broken for xine · 556a0442
      Chris Rankin authored
      The commit e399ce77 has broken the DVB ABI for xine:
      
      The problem is that xine is expecting every event after a successful
      FE_SET_FRONTEND ioctl to have a non-zero frequency parameter, regardless
      of whether the tuning process has LOCKed yet. What used to happen is
      that the events inherited the initial tuning parameters from the
      FE_SET_FRONTEND call. However, the fepriv->parameters_out struct is now
      not initialised until the status contains the FE_HAS_LOCK bit.
      
      You might argue that this behaviour is intentional, except that if an
      application other than xine uses the DVB adapter and manages to set the
      parameters_out.frequency field to something other than zero, then xine
      no longer has any problems until either the adapter is replugged or the
      kernel modules reloaded. This can only mean that the
      fepriv->parameters_out struct still contains the (stale) tuning
      information from the previous application.
      Signed-off-by: default avatarChris Rankin <rankincj@yahoo.com>
      Cc: stable@kernel.org # for kernel version 3.3
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      556a0442
  18. 14 Feb, 2012 1 commit
    • Simon Arlott's avatar
      [media] dvb-core: fix DVBFE_ALGO_HW retune bug · 45145b67
      Simon Arlott authored
      Commit 7e072221 breaks DVBFE_ALGO_HW tuning after a retune is requested,
      which causes bad tuning on my TBS 6920.
      
      [    0.769091] pci 0000:06:00.0: [14f1:8852] type 0 class 0x000400
      [   19.733530] CORE cx23885[0]: subsystem: 6920:8888, board: TurboSight TBS 6920 [card=14,autodetected]
      [  762.824912] cx24116_load_firmware: FW version 1.23.86.1
      
      7e072221 [media] dvb-core: Don't pass DVBv3 parameters on tune() fops
      
      Although re_tune is set to true when FESTATE_RETUNE occurs, it is never
      set back to false which the old code used to do when !FESTATE_RETUNE.
      
      This patch sets re_tune to false if !(state & FESTATE_RETUNE).
      
      $ szap-s2 -a 2 "Channel 5"
      reading channels from file '/home/simon/.szap/channels.conf'
      zapping to 247 'Channel 5':
      delivery DVB-S, modulation QPSK
      sat 0, frequency 10964 MHz H, symbolrate 22000000, coderate 5/6, rolloff 0.35
      vpid 0x092a, apid 0x092b, sid 0x092d
      using '/dev/dvb/adapter2/frontend0' and '/dev/dvb/adapter2/demux0'
      status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr eb33 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cec0 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      status 1f | signal cec0 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
      Signed-off-by: default avatarSimon Arlott <simon@fire.lp0.eu>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      45145b67
  19. 18 Jan, 2012 1 commit
  20. 17 Jan, 2012 1 commit
    • Mauro Carvalho Chehab's avatar
      [media] dvb_frontend: Don't call get_frontend() if idle · 51dcb19a
      Mauro Carvalho Chehab authored
      If the frontend is in idle state, don't call get_frontend.
      
      Calling get_frontend() when the device is not tuned may
      result in wrong parameters to be returned to the
      userspace.
      
      I was tempted to not call get_frontend() at all, except
      inside the dvb frontend thread, but this won't work for
      all cases. The ISDB-T specs (ABNT NBR 15601 and ARIB
      STD-B31) allow the broadcaster to dynamically change the
      channel specs at runtime. That means that an ISDB-T optimized
      application may want/need to monitor the TMCC tables, decoded
      at the frontends via get_frontend call.
      
      So, let's do the simpler change here.
      
      Eventually, the logic could be changed to work only if
      the device is tuned and has lock, but, even so, the
      lock is also standard-dependent. For ISDB-T, the right
      lock to wait is that the demod has TMCC lock. So, drivers
      may need to implement some logic to detect if the get_frontend
      info was retrieved or not.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      51dcb19a
  21. 15 Jan, 2012 2 commits
  22. 11 Jan, 2012 1 commit
  23. 07 Jan, 2012 1 commit
    • Mauro Carvalho Chehab's avatar
      [media] dvb: remove bogus modulation check · b247377a
      Mauro Carvalho Chehab authored
      This code is wrong as I should have coded it as SYS_DVBC, instead of
      SYS_DVBS & friends. Anyway, this check has other problems
      
      1) it does some "magic" by assuming that all QAM modulations are below
        QAM_AUTO;
      
      2) it checks modulation parameters only for one delivery system.
         Or the core should check invalid parameters for all delivery
         systems, or it should let the frontend drivers do it;
      
      3) frontend drivers should already be checking for invalid parameters
         (most of them do it, anyway);
      
      4) not all modulations are mapped at fe->ops.info.caps, so it is not
         even possible to check for the valid modulations inside the core
         for some delivery systems;
      
      5) The core check is incomplete anyway: it only checks for a few
         parameters. If moved into the core other parameters like bandwidth
         and fec should also be checked;
      
      6) 2nd gen DVB-C uses OFDM. So, that test would fail for it.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      b247377a
  24. 05 Jan, 2012 3 commits
  25. 04 Jan, 2012 3 commits