1. 19 5月, 2010 1 次提交
  2. 27 2月, 2010 4 次提交
  3. 06 12月, 2009 8 次提交
  4. 19 9月, 2009 1 次提交
  5. 23 6月, 2009 3 次提交
    • M
      V4L/DVB (12120): pvrusb2: Change initial default frequency setting · 6f441ed7
      Mike Isely 提交于
      Change default frequency to be US Broadcast channel 3 - with the
      transition to d igital the previous value has now become useless.
      This change is PURELY to help with my testing (I need to set some kind
      of default so it might as well be some thing usable).
      Signed-off-by: NMike Isely <isely@pobox.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      6f441ed7
    • M
      V4L/DVB (12119): pvrusb2: Re-fix hardware scaling on video standard change · a6862da2
      Mike Isely 提交于
      The cx25840 module's VBI initialization logic uses the current video
      standard as part of its internal algorithm.  This therefore means that
      we probably need to make sure that the correct video standard has been
      set before initializing VBI.  (Normally we would not care about VBI,
      but as described in an earlier changeset, VBI must be initialized
      correctly on the cx25840 in order for the chip's hardware scaler to
      operate correctly.)
      
      It's kind of messy to force the video standard to be set before
      initializing VBI (mainly because we can't know what the app really
      wants that early in the initialization process).  So this patch does
      the next best thing: VBI is re-initialized after any point where the
      video standard has been set.
      Signed-off-by: NMike Isely <isely@pobox.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      a6862da2
    • M
      V4L/DVB (12118): pvrusb2: Fix hardware scaling when used with cx25840 · e17d787c
      Mike Isely 提交于
      The cx25840 module requires that its VBI initialization entry point be
      called in order for hardware-scaled video capture to work properly -
      even if we don't care about VBI.  Making this behavior even more
      subtle is that if the capture resolution is set to 720x480 - which is
      the default that the pvrusb2 driver sets up - then the cx25840
      bypasses the hardware scaler.  Therefore this problem does not
      manifest itself until some other resolution, e.g. 640x480, is tried.
      MythTV typically defaults to 640x480 or 480x480, which means that
      things break whenever the driver is used with MythTV.
      
      This all has been known for a while (since at least Nov 2006), but
      recent changes in the pvrusb2 driver (specifically in regards to
      sub-device support) caused this to break again.  VBI initialization
      must happen *after* the chip's firmware is loaded, not before.  With
      this fix, 24xxx devices work correctly again.
      
      A related fix that is part of this changeset is that now we
      re-initialize VBI any time after we issue a reset to the cx25840
      driver.  Issuing a chip reset erases the state that the VBI setup
      previously did.  Until the HVR-1950 came along this subtlety went
      unnoticed, because the pvrusb2 driver previously never issued such a
      reset.  But with the HVR-1950 we have to do that reset in order to
      correctly transition from digital back to analog mode - and since the
      HVR-1950 always starts in digital mode (required for the DVB side to
      initialize correctly) then this device has never had a chance to work
      correctly in analog mode!  Analog capture on the HVR-1950 has been
      broken this *ENTIRE* time.  I had missed it until now because I've
      usually been testing at the default 720x480 resolution which does not
      require scaling...  What fun.  By re-initializing VBI after a cx25840
      chip reset, correct behavior is restored.
      Signed-off-by: NMike Isely <isely@pobox.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      e17d787c
  6. 17 6月, 2009 2 次提交
  7. 18 4月, 2009 1 次提交
    • D
      USB: add reset endpoint operations · 3444b26a
      David Vrabel 提交于
      Wireless USB endpoint state has a sequence number and a current
      window and not just a single toggle bit.  So allow HCDs to provide a
      endpoint_reset method and call this or clear the software toggles as
      required (after a clear halt, set configuration etc.).
      
      usb_settoggle() and friends are then HCD internal and are moved into
      core/hcd.h and all device drivers call usb_reset_endpoint() instead.
      
      If the device endpoint state has been reset (with a clear halt) but
      the host endpoint state has not then subsequent data transfers will
      not complete. The device will only work again after it is reset or
      disconnected.
      Signed-off-by: NDavid Vrabel <david.vrabel@csr.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3444b26a
  8. 07 4月, 2009 5 次提交
  9. 30 3月, 2009 15 次提交