1. 02 Mar, 2011 10 commits
    • Jarod Wilson's avatar
      [media] tda829x: fix regression in probe functions · 89a8969a
      Jarod Wilson authored
      In commit 567aba0b, the probe address
      for tda8290_probe and tda8295_probe was hard-coded to 0x4b, which is the
      default i2c address for those devices, but its possible for the device
      to be at an alternate address, 0x42, which is the case for the HVR-1950.
      If we probe the wrong address, probe fails and we have a non-working
      device. We have the actual address passed into the function by way of
      i2c_props, we just need to use it. Also fix up some copy/paste comment
      issues and streamline debug spew a touch. Verified to restore my
      HVR-1950 to full working order.
      
      Special thanks to Ken Bass for reporting the issue in the first place,
      and to both he and Gary Buhrmaster for aiding in debugging and analysis
      of the problem.
      Reported-by: default avatarKen Bass <kbass@kenbass.com>
      Tested-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      89a8969a
    • Jarod Wilson's avatar
      [media] mceusb: don't claim multifunction device non-IR parts · a6994eb0
      Jarod Wilson authored
      There's a Realtek combo card reader and IR receiver device with multiple
      usb interfaces on it. The mceusb driver is incorrectly grabbing all of
      them. This change should make it bind to only interface 2 (patch based
      on lsusb output on the linux-media list from Lucian Muresan).
      
      Tested regression-free with the six mceusb devices I have myself.
      Reported-by: default avatarPatrick Boettcher <pboettcher@kernellabs.com>
      Reported-by: default avatarLucian Muresan <lucianm@users.sourceforge.net>
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      a6994eb0
    • Jarod Wilson's avatar
      [media] nuvoton-cir: fix wake from suspend · 3198ed16
      Jarod Wilson authored
      The CIR Wake FIFO is 67 bytes long, but the stock remote appears to only
      populate 65 of them. Limit comparison to 65 bytes, and wake from suspend
      works a whole lot better (it wasn't working at all for most folks).
      
      Fix based on comparison with the old lirc_wb677 driver from Nuvoton,
      debugging and testing done by Dave Treacy by way of the lirc mailing
      list.
      Reported-by: default avatarDave Treacy <davetreacy@gmail.com>
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      3198ed16
    • Devin Heitmueller's avatar
      [media] cx18: Add support for Hauppauge HVR-1600 models with s5h1411 · e3bfeabb
      Devin Heitmueller authored
      The newest variants of the HVR-1600 have an s5h1411/tda18271 for the digital
      frontend.  Add support for these boards.
      
      Thanks to Hauppauge Computer Works for providing sample hardware.
      
      [awalls@md.metrocast.net: Changed an additional log message to clarify for
      the end user that the driver is defaulting to an original HVR-1600 for
      unknown model numbers.]
      Signed-off-by: default avatarDevin Heitmueller <dheitmueller@kernellabs.com>
      Signed-off-by: default avatarAndy Walls <awalls@md.metrocast.net>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      e3bfeabb
    • Michael's avatar
      [media] ivtv: Fix corrective action taken upon DMA ERR interrupt to avoid hang · d213ad08
      Michael authored
      After upgrading the kernel from stock Ubuntu 7.10 to
      10.04, with no hardware changes, I started getting the dreaded DMA
      TIMEOUT errors, followed by inability to encode until the machine was
      rebooted.
      
      I came across a post from Andy in March
      (http://www.gossamer-threads.com/lists/ivtv/users/40943#40943) where he
      speculates that perhaps the corrective actions being taken after a DMA
      ERROR are not sufficient to recover the situation.  After some testing
      I suspect that this is indeed the case, and that in fact the corrective
      action may be what hangs the card's DMA engine, rather than the
      original error.
      
      Specifically these DMA ERROR IRQs seem to present with two different
      values in the IVTV_REG_DMASTATUS register: 0x11 and 0x13.  The current
      corrective action is to clear that status register back to 0x01 or
      0x03, and then issue the next DMA request.  In the case of a 0x13 this
      seems to result in a minor glitch in the encoded stream due to the
      failed transfer that was not retried, but otherwise things continue OK.
      In the case of a 0x11 the card's DMA write engine is never heard from
      again, and a DMA TIMEOUT follows shortly after.  0x11 is the killer.
      
      I suspect that the two cases need to be handled differently.  The
      difference is in bit 1 (0x02), which is set when the error is about to
      be successfully recovered, and clear when things are about to go bad.
      
      Bit 1 of DMASTATUS is described differently in different places either
      as a positive "write finished", or an inverted "write busy".  If we
      take the first definition, then when an error arises with state 0x11,
      it means that the write did not complete.   It makes sense to start a
      new transfer, as in the current code.  But if we take the second
      definition, then 0x11 means "an error but the write engine is still
      busy".  Trying to feed it a new transfer in this situation might not be
      a good idea.
      
      As an experiment, I added code to ignore the DMA ERROR IRQ if DMASTATUS
      is 0x11.  I.e., don't start a new transfer, don't clear our flags, etc.
      The hope was that the card would complete the transfer and issue a ENC
      DMA COMPLETE, either successfully or with an error condition there.
      However the card still hung.
      
      The only remaining corrective action being taken with a 0x11 status was
      then the write back to the status register to clear the error, i.e.
      DMASTATUS = DMASTATUS & ~3.  This would have the effect of clearing the
      error bit 4, while leaving the lower bits indicating DMA write busy.
      
      Strangely enough, removing this write to the status register solved the
      problem!  If the DMA ERROR IRQ with DMASTATUS=0x11 is completely
      ignored, with no corrective action at all, then the card will complete
      the transfer and issue a new IRQ.  If the status register is written to
      when it has the value 0x11, then the DMA engine hangs.  Perhaps it's
      illegal to write to
      DMASTATUS while the read or write busy bit is set?  At any rate, it
      appears that the current corrective action is indeed making things
      worse rather than better.
      
      I put together a patch that modifies ivtv_irq_dma_err to do the
      following:
      
      - Don't write back to IVTV_REG_DMASTATUS.
      - If write-busy is asserted, leave the card alone.  Just extend the
      timeout slightly.
      - If write-busy is de-asserted, retry the current transfer.
      
      This has completely fixed my DMA TIMEOUT woes.  DMA ERR events still
      occur, but now they seem to be correctly handled.  0x11 events no
      longer hang the card, and 0x13 events no longer result in a glitch in
      the stream, as the failed transfer is retried.  I'm happy.
      
      I've inlined the patch below in case it is of interest.  As described
      above, I have a theory about why it works (based on a different
      interpretation of bit 1 of DMASTATUS), but I can't guarantee that my
      theory is correct.  There may be another explanation, or it may be a
      fluke.  Maybe ignoring that IRQ entirely would be equally effective?
      Maybe the status register read/writeback sequence is race condition if
      the card changes it in the mean time?  Also as I am using a PVR-150
      only, I have not been able to test it on other cards, which may be
      especially relevant for 350s that support concurrent decoding.
      Hopefully the patch does not break the DMA READ path.
      
      Mike
      
      [awalls@md.metrocast.net: Modified patch to add a verbose comment, make minor
      brace reformats, and clear the error flags in the IVTV_REG_DMASTATUS iff both
      read and write DMA were not in progress.  Mike's conjecture about a race
      condition with the writeback is correct; it can confuse the DMA engine.]
      
      [Comment and analysis from the ML post by Michael <mike@rsy.com>]
      Signed-off-by: default avatarAndy Walls <awalls@md.metrocast.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      d213ad08
    • Sven Barth's avatar
      [media] cx25840: fix probing of cx2583x chips · 1e6406b8
      Sven Barth authored
      Fix the probing of cx2583x chips, because two controls were clustered
      that are not created for these chips.
      
      This regression was introduced in 2.6.36.
      Signed-off-by: default avatarSven Barth <pascaldragon@googlemail.com>
      Signed-off-by: default avatarAndy Walls <awalls@md.metrocast.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      1e6406b8
    • Andy Walls's avatar
      [media] cx23885: Remove unused 'err:' labels to quiet compiler warning · 593110d1
      Andy Walls authored
      The previous revert-commit, that affected cx23885-i2c.c, left some
      unused labels that the compiler griped about.  Clean them up.
      Signed-off-by: default avatarAndy Walls <awalls@md.metrocast.net>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      593110d1
    • Andy Walls's avatar
      [media] cx23885: Revert "Check for slave nack on all transactions" · 67914b5c
      Andy Walls authored
      This reverts commit 44835f19.
      
      With the CX23885 hardware I2C master, checking for I2C slave ACK/NAK
      is not valid when the I2C_EXTEND or I2C_NOSTOP bits are set.
      Revert the commit that checks for I2C slave ACK/NAK on all transactions,
      so that XC5000 tuners work with the CX23885 again.
      
      Thanks go to Mark Zimmerman for reporting and bisecting this problem.
      Bisected-by: default avatarMark Zimmerman <markzimm@frii.com>
      Reported-by: default avatarMark Zimmerman <markzimm@frii.com>
      Signed-off-by: default avatarAndy Walls <awalls@md.metrocast.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      67914b5c
    • Olivier Grenie's avatar
      [media] DiB7000M: add pid filtering · e192a7cf
      Olivier Grenie authored
      This patch adds the pid filtering for the dib7000M demod. It also
      corrects the pid filtering for the dib7700 based board. It should
      prevent an oops, when using dib7700p based board.
      
      References: https://bugzilla.novell.com/show_bug.cgi?id=644807Signed-off-by: default avatarOlivier Grenie <olivier.grenie@dibcom.fr>
      Signed-off-by: default avatarPatrick Boettcher <patrick.boettcher@dibcom.fr>
      Tested-by: default avatarPavel SKARKA <paul.sp@seznam.cz>
      Cc: stable@kernel.org
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      e192a7cf
    • Antti Seppälä's avatar
      [media] Fix sysfs rc protocol lookup for rc-5-sz · 0a91be40
      Antti Seppälä authored
      With the current matching rules the lookup for rc protocol named rc-5-sz matches with "rc-5" before finding "rc-5-sz". Thus one is able to never enable/disable the rc-5-sz protocol via sysfs.
      
      Fix the lookup to require an exact match which allows the manipulation of sz protocol.
      Signed-off-by: default avatarAntti Seppälä <a.seppala@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      0a91be40
  2. 02 Feb, 2011 5 commits
  3. 31 Jan, 2011 12 commits
  4. 22 Jan, 2011 2 commits
    • Linus Torvalds's avatar
      Linux 2.6.38-rc2 · 1bae4ce2
      Linus Torvalds authored
      1bae4ce2
    • Linus Torvalds's avatar
      Merge branch 'media_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 · 13a3cec8
      Linus Torvalds authored
      * 'media_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (101 commits)
        [media] staging/lirc: fix mem leaks and ptr err usage
        [media] hdpvr: reduce latency of i2c read/write w/recycled buffer
        [media] hdpvr: enable IR part
        [media] rc/mceusb: timeout should be in ns, not us
        [media] v4l2-device: fix 'use-after-freed' oops
        [media] v4l2-dev: don't memset video_device.dev
        [media] zoran: use video_device_alloc instead of kmalloc
        [media] w9966: zero device state after a detach
        [media] v4l: Fix a use-before-set in the control framework
        [media] v4l: Include linux/videodev2.h in media/v4l2-ctrls.h
        [media] DocBook/v4l: update V4L2 revision and update copyright years
        [media] DocBook/v4l: fix validation error in dev-rds.xml
        [media] v4l2-ctrls: queryctrl shouldn't attempt to replace V4L2_CID_PRIVATE_BASE IDs
        [media] v4l2-ctrls: fix missing 'read-only' check
        [media] pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c
        [media] ir-kbd-i2c: Add back defaults setting for Zilog Z8's at addr 0x71
        [media] lirc_zilog: Update TODO.lirc_zilog
        [media] lirc_zilog: Add Andy Walls to copyright notice and authors list
        [media] lirc_zilog: Remove useless struct i2c_driver.command function
        [media] lirc_zilog: Remove unneeded tests for existence of the IR Tx function
        ...
      13a3cec8
  5. 21 Jan, 2011 11 commits