1. 27 2月, 2010 1 次提交
    • S
      V4L/DVB: firedtv: do not DMA-map stack addresses · 3fb80ef3
      Stefan Richter 提交于
      This is a portability fix and reduces stack usage.
      
      The DMA mapping API cannot map on-stack addresses, as explained in
      Documentation/DMA-mapping.txt.  Convert the two cases of on-stack packet
      payload buffers in firedtv (payload of write requests in avc_write and
      of lock requests in cmp_lock) to slab-allocated memory.
      
      We use the 512 bytes sized FCP frame buffer in struct firedtv for this
      purpose.  Previously it held only incoming FCP responses, now it holds
      pending FCP requests and is then overwriten by an FCP response from the
      tuner subunit.  Ditto for CMP lock requests and responses.  Accesses to
      the payload buffer are serialized by fdtv->avc_mutex.
      
      As a welcome side effect, stack usage of the AV/C transaction functions
      is reduced by 512 bytes.
      
      Alas, avc_register_remote_control() is a special case:  It previously
      did not wait for a response.  To fit better in with the other FCP
      transactions, let it wait for an interim response.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      3fb80ef3
  2. 30 12月, 2009 1 次提交
    • C
      firewire: fix use of multiple AV/C devices, allow multiple FCP listeners · db5d247a
      Clemens Ladisch 提交于
      Control of more than one AV/C device at once --- e.g. camcorders, tape
      decks, audio devices, TV tuners --- failed or worked only unreliably,
      depending on driver implementation.  This affected kernelspace and
      userspace drivers alike and was caused by firewire-core's inability to
      accept multiple registrations of FCP listeners.
      
      The fix allows multiple address handlers to be registered for the FCP
      command and response registers.  When a request for these registers is
      received, all handlers are invoked, and the Firewire response is
      generated by the core and not by any handler.
      
      The cdev API does not change, i.e., userspace is still expected to send
      a response for FCP requests; this response is silently ignored.
      Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, rebased, whitespace)
      db5d247a
  3. 06 12月, 2009 4 次提交