10 Jul, 2011

1 commit

  • When firewire-ohci is bound to a Pinnacle MovieBoard, eventually a
    "Register access failure" is logged and an interrupt storm or a kernel
    panic happens. https://bugzilla.kernel.org/show_bug.cgi?id=36622

    Until this is sorted out (if that is going to succeed at all), let's
    just prevent firewire-ohci from touching these devices.

    Signed-off-by: Stefan Richter
    Cc:

    Stefan Richter
     

11 May, 2011

7 commits

  • The struct sbp2_logical_unit.work items can all be executed in parallel
    but are not reentrant. Furthermore, reconnect or re-login work must be
    executed in a WQ_MEM_RECLAIM workqueue.

    Hence replace the old single-threaded firewire-sbp2 workqueue by a
    concurrency-managed but non-reentrant workqueue with rescuer.
    firewire-core already maintains one, hence use this one.

    In earlier versions of this change, I observed occasional failures of
    parallel INQUIRY to an Initio INIC-2430 FireWire 800 to dual IDE bridge.
    More testing indicates that parallel INQUIRY is not actually a problem,
    but too quick successions of logout and login + INQUIRY, e.g. a quick
    sequence of cable plugout and plugin, can result in failed INQUIRY.
    This does not seem to be something that should or could be addressed by
    serialization.

    Another dual-LU device to which I currently have access to, an
    OXUF924DSB FireWire 800 to dual SATA bridge with firmware from MacPower,
    has been successfully tested with this too.

    This change is beneficial to environments with two or more FireWire
    storage devices, especially if they are located on the same bus.
    Management tasks that should be performed as soon and as quickly as
    possible, especially reconnect, are no longer held up by tasks on other
    devices that may take a long time, especially login with INQUIRY and sd
    or sr driver probe.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • We do not need slab allocations for ORB pointer write transactions
    anymore in order to satisfy streaming DMA mapping constraints, thanks to
    commit da28947e7e36 "firewire: ohci: avoid separate DMA mapping for
    small AT payloads".

    (Besides, the slab-allocated buffers that firewire-sbp2 used to provide
    for 8-byte write requests were still not fully portable since they
    shared a cacheline with unrelated CPU-accessed data.)

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • firewire-sbp2 already takes care for internal serialization where
    required (ORB list accesses), and it does not use cmd->serial_number
    internally. Hence it is safe to not grab the shost lock around
    queuecommand.

    While we are at housekeeping, drop a redundant struct member:
    sbp2_command_orb.done is set once in a hot path and dereferenced once in
    a hot path. We can as well dereference sbp2_command_orb.cmd->scsi_done
    instead.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • firewire-core manages the following types of work items:

    fw_card.br_work:
    - resets the bus on a card and possibly sends a PHY packet before that
    - does not sleep for long or not at all
    - is scheduled via fw_schedule_bus_reset() by
    - firewire-ohci's pci_probe method
    - firewire-ohci's set_config_rom method, called by kernelspace
    protocol drivers and userspace drivers which add/remove
    Configuration ROM descriptors
    - userspace drivers which use the bus reset ioctl
    - itself if the last reset happened less than 2 seconds ago

    fw_card.bm_work:
    - performs bus management duties
    - usually does not (but may in corner cases) sleep for long
    - is scheduled via fw_schedule_bm_work() by
    - firewire-ohci's self-ID-complete IRQ handler tasklet
    - firewire-core's fw_device.work instances whenever the root node
    device was (successfully or unsuccessfully) discovered,
    refreshed, or rediscovered
    - itself in case of resource allocation failures or in order to
    obey the 125ms bus manager arbitration interval

    fw_device.work:
    - performs node probe, update, shutdown, revival, removal; including
    kernel driver probe, update, shutdown and bus reset notification to
    userspace drivers
    - usually sleeps moderately long, in corner cases very long
    - is scheduled by
    - firewire-ohci's self-ID-complete IRQ handler tasklet via the
    core's fw_node_event
    - firewire-ohci's pci_remove method via core's fw_destroy_nodes/
    fw_node_event
    - itself during retries, e.g. while a node is powering up

    iso_resource.work:
    - accesses registers at the Isochronous Resource Manager node
    - usually does not (but may in corner cases) sleep for long
    - is scheduled via schedule_iso_resource() by
    - the owning userspace driver at addition and removal of the
    resource
    - firewire-core's fw_device.work instances after bus reset
    - itself in case of resource allocation if necessary to obey the
    1000ms reallocation period after bus reset

    fw_card.br_work instances should not, and instances of the others must
    not, be executed in parallel by multiple CPUs -- but were not protected
    against that. Hence allocate a non-reentrant workqueue for them.

    fw_device.work may be used in the memory reclaim path in case of SBP-2
    device updates. Hence we need a workqueue with rescuer and cannot use
    system_nrt_wq.

    Signed-off-by: Stefan Richter
    Reviewed-by: Tejun Heo

    Stefan Richter
     
  • When queueing iso packets, the run time is dominated by the two
    MMIO accesses that set the DMA context's wake bit. Because most
    drivers submit packets in batches, we can save much time by
    removing all but the last wakeup.

    The internal kernel API is changed to require a call to
    fw_iso_context_queue_flush() after a batch of queued packets.
    The user space API does not change, so one call to
    FW_CDEV_IOC_QUEUE_ISO must specify multiple packets to take
    advantage of this optimization.

    In my measurements, this patch reduces the time needed to queue
    fifty skip packets from userspace to one sixth on a 2.5 GHz CPU,
    or to one third at 800 MHz.

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Stefan Richter

    Clemens Ladisch
     
  • We do not need slab allocations anymore in order to satisfy
    streaming DMA mapping constraints, thanks to commit da28947e7e36
    "firewire: ohci: avoid separate DMA mapping for small AT payloads".

    (Besides, the slab-allocated buffers that firewire-core, firewire-sbp2,
    and firedtv used to provide for 8-byte write and lock requests were
    still not fully portable since they crossed cacheline boundaries or
    shared a cacheline with unrelated CPU-accessed data. snd-firewire-lib
    got this aspect right by using an extra kmalloc/ kfree just for the
    8-byte transaction buffer.)

    This change replaces kmalloc'ed lock transaction scratch buffers in
    firewire-core, firedtv, and snd-firewire-lib by local stack allocations.
    Perhaps the most notable result of the change is simpler locking because
    there is no need to serialize usages of preallocated per-device buffers
    anymore. Also, allocations and deallocations are simpler.

    Signed-off-by: Stefan Richter
    Acked-by: Clemens Ladisch

    Stefan Richter
     
  • in order to pull in changes in drivers/media/dvb/firewire/ and
    sound/firewire/.

    Stefan Richter
     

05 May, 2011

1 commit


03 May, 2011

1 commit

  • Current implementation of ohci_set_config_rom() uses a deferred
    bus reset via fw_schedule_bus_reset(). If clients add multiple
    unit descriptors to the config_rom in quick succession, the
    deferred bus reset may not have fired before succeeding update
    requests have come in. This can lead to an incorrect partial
    update of the config_rom for both addition and removal of
    config_rom descriptors, as the ohci_set_config_rom() routine
    will return -EBUSY if a previous pending update has not been
    completed yet; the requested update just gets dropped on the floor.

    This patch recognizes that the "in-flight" update can be modified
    until it has been processed by the bus-reset, and the locking
    in the bus_reset_tasklet ensures that the update is done atomically
    with respect to modifications made by ohci_set_config_rom(). The
    -EBUSY error case is simply removed.

    [Stefan R: The bug always existed at least theoretically. But it
    became easy to trigger since 2.6.36 commit 02d37bed188c "firewire: core:
    integrate software-forced bus resets with bus management" which
    introduced long mandatory delays between janitorial bus resets.]

    Signed-off-by: Benjamin Buchalter
    Signed-off-by: Stefan Richter (trivial style changes)
    Cc: # 2.6.36.y and newer

    B.J. Buchalter
     

20 Apr, 2011

3 commits

  • When z==2, the condition "key == 2" is superfluous because it cannot
    occur without "b == 3", as a descriptor with b!=3 and key==2 would be
    an OUTPUT_MORE_IMMEDIATE descriptor which cannot be used alone.

    Also remove magic numbers and needless computations on the b field.

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Stefan Richter

    Clemens Ladisch
     
  • For AT packet payloads of up to eight bytes, we have enough unused space
    in the DMA descriptors list so that we can put a copy of the payload
    there and thus avoid having to create a separate streaming DMA mapping
    for the payload buffer.

    In a CPU-bound microbenchmark that just sends 8-byte packets, bandwidth
    was measured to increase by 5.7 %, from 1009 KB/s to 1067 KB/s. In
    practice, the only performance-sensitive usage of small asynchronous
    packets is the SBP-2 driver's write to the ORB_POINTER register during
    SCSI command submission.

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Stefan Richter

    Clemens Ladisch
     
  • OHCI 1.1 5.7.3 not only forbids enabling or starting any DMA contexts
    before the linkEnable bit is set, but also explicitly warns of undefined
    behaviour if this order is violated.

    Don't violate it then.

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Stefan Richter

    Clemens Ladisch
     

31 Mar, 2011

1 commit


22 Mar, 2011

1 commit

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
    firewire: core: ignore link-active bit of new nodes, fix device recognition
    firewire: sbp2: revert obsolete 'fix stall with "Unsolicited response"'
    firewire: core: increase default SPLIT_TIMEOUT value
    firewire: ohci: Misleading kfree in ohci.c::pci_probe/remove
    firewire: ohci: omit IntEvent.busReset check rom AT queueing
    firewire: ohci: prevent starting of iso contexts with empty queue
    firewire: ohci: prevent iso completion callbacks after context stop
    firewire: core: rename some variables
    firewire: nosy: should work on Power Mac G4 PCI too
    firewire: core: fix card->reset_jiffies overflow
    firewire: cdev: remove unneeded reference
    firewire: cdev: always wait for outbound transactions to complete
    firewire: cdev: remove unneeded idr_find() from complete_transaction()
    firewire: ohci: log dead DMA contexts

    Linus Torvalds
     

20 Mar, 2011

3 commits

  • Like the older ieee1394 core driver, firewire-core skipped scanning of
    any new node whose PHY sent a self ID without "link active" bit. If a
    device had this bit off mistakenly, it meant that it was inaccessible to
    kernel drivers with the old IEEE 1394 driver stack but could still be
    accessed by userspace drivers through the raw1394 interface.

    But with firewire-core, userspace drivers don't get to see such buggy
    devices anymore. This is effectively a driver regression since this
    device bug is otherwise harmless.

    We now attempt to scan all devices, even repeaters that don't have a
    link or powered-down devices that have everything but their PHY shut
    down when plugged in. This results in futile repeated scanning attempts
    in case of such devices that really don't have an active link, but this
    doesn't hurt since recent workqueue infrastructure lets us run more
    concurrent scanning jobs than we can shake a stick at.

    This should fix accessibility of Focusrite Saffire PRO 26 I/O:
    http://sourceforge.net/mailarchive/forum.php?thread_name=20110314215622.5c751bb0%40stein&forum_name=ffado-user

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • Now that firewire-core sets the local node's SPLIT_TIMEOUT to 2 seconds
    per default, commit a481e97d3cdc40b9d58271675bd4f0abb79d4872 is no
    longer required.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • The SPLIT_TIMEOUT mechanism is intended to detect requests that somehow
    got lost. However, when the timeout value is too low, transactions that
    could have been completed successfully will be cancelled. Furthermore,
    there are chips whose firmwares ignore the configured split timeout and
    send late split response; known examples are the DM1x00 (BeBoB), TCD22x0
    (DICE), and some OXUF936QSE firmwares.

    This patch changes the default timeout to two seconds, which happens to
    be the default on other OSes, too.

    Actual lost requests are extremely rare, so there should be no practical
    downside to increasing the split timeout even on devices that work
    correctly.

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Stefan Richter

    Clemens Ladisch
     

15 Mar, 2011

3 commits

  • Add a driver for two playback-only FireWire devices based on the OXFW970
    chip.

    v2: better AMDTP API abstraction; fix fw_unit leak; small fixes
    v3: cache the iPCR value
    v4: FireWave constraints; fix fw_device reference counting;
    fix PCR caching; small changes and fixes
    v5: volume/mute support; fix crashing due to pcm stop races
    v6: fix build; one-channel volume for LaCie
    v7: use signed values to make volume (range checks) work; fix function
    block IDs for volume/mute; always use channel 0 for LaCie volume

    Signed-off-by: Clemens Ladisch
    Acked-by: Stefan Richter
    Tested-by: Jay Fenlason
    Signed-off-by: Takashi Iwai

    Clemens Ladisch
     
  • It seems drivers/firewire/ohci.c is making some optimistic assumptions
    about struct fw_ohci and that member "card" will always remain the first
    member of the struct.
    Plus it's probably going to confuse a lot of static code analyzers too.

    So I wonder if there is a good reason not to free the ohci struct just
    like it was allocated instead of the tricky &ohci->card way?

    Signed-off-by: Oleg Drokin

    It is perhaps just a rudiment from before mainline submission of the
    driver.

    Signed-off-by: Stefan Richter

    Oleg Drokin
     
  • Since commit 82b662dc4102 "flush AT contexts after bus reset for OHCI 1.2",
    the driver takes care of any AT packets that were enqueued during a bus
    reset phase. The check from commit 76f73ca1b291 is therefore no longer
    necessary and the MMIO read can be avoided.

    Signed-off-by: Stefan Richter

    Stefan Richter
     

26 Feb, 2011

4 commits

  • If a misguided program tried to start an isochronous context before it
    has queued any packets, the call would appear to succeed, but the
    context would not actually go into the running state, and the OHCI
    controller would then raise an unrecoverableError interrupt because the
    first Z value is zero and thus invalid. The driver logs such errors,
    but there is no mechanism to report this back to the program.

    Add an explicit check so that this error can be returned synchronously.

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Stefan Richter

    Clemens Ladisch
     
  • To prevent the iso packet callback from being called after
    fw_iso_context_stop() has returned, make sure that the
    context's tasklet has finished executing before that.

    This fixes access-after-free bugs that have so far been
    observed only in the upcoming snd-firewire-speakers driver,
    but can theoretically also happen in the firedtv driver.

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Stefan Richter

    Clemens Ladisch
     
  • In manage_channel(), rename the variables "c" and "i" to the more
    expressive "bit" and "channel".

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Stefan Richter

    Clemens Ladisch
     
  • The first board generation of Power Mac G4 ("Yikes!", those with PCI
    graphics) still had a PCILynx controller like their G3 predecessors,
    but not the later AGP models. (Jonathan Woithe recalls to have heard
    of it, and some web sources reinforce it.)

    Signed-off-by: Stefan Richter

    Stefan Richter
     

23 Jan, 2011

5 commits


22 Jan, 2011

1 commit


21 Jan, 2011

3 commits

  • thanks to Clemens' and Maxim's fixes to firewire-ohci and -net in the
    last two kernel releases.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • This makes it possible to resume communication with a node that dropped
    off the bus for a brief period. Otherwise communication will only be
    possible after ARP cache entry timeouts.

    Signed-off-by: Maxim Levitsky
    Signed-off-by: Stefan Richter (rebased)

    Maxim Levitsky
     
  • Regression since commit 10389536742c, "firewire: core: check for 1394a
    compliant IRM, fix inaccessibility of Sony camcorder":

    The camcorder Canon MV5i generates lots of bus resets when asynchronous
    requests are sent to it (e.g. Config ROM read requests or FCP Command
    write requests) if the camcorder is not root node. This causes drop-
    outs in videos or makes the camcorder entirely inaccessible.
    https://bugzilla.redhat.com/show_bug.cgi?id=633260

    Fix this by allowing any Canon device, even if it is a pre-1394a IRM
    like MV5i are, to remain root node (if it is at least Cycle Master
    capable). With the FireWire controller cards that I tested, MV5i always
    becomes root node when plugged in and left to its own devices.

    Reported-by: Ralf Lange
    Signed-off-by: Stefan Richter
    Cc: # 2.6.32.y and newer

    Stefan Richter
     

13 Jan, 2011

1 commit

  • PAGE_KERNEL_RO is not available on all architectures, so its use
    in the new AR code broke compilation on sparc64.

    Because the read-only mapping was just a debugging aid, just use
    PAGE_KERNEL instead.

    Signed-off-by: Clemens Ladisch

    James Bottomley wrote:
    > On Thu, 2011-01-13 at 08:27 +0100, Clemens Ladisch wrote:
    >> firewire: ohci: fix compilation on arches without PAGE_KERNEL_RO, e.g. sparc
    >>
    >> PAGE_KERNEL_RO is not available on all architectures, so its use in the
    >> new AR code broke compilation on sparc64.
    >>
    >> Because the R/O mapping is only used to catch drivers that try to write
    >> to the reception buffer and not actually required for correct operation,
    >> we can just use a normal PAGE_KERNEL mapping where _RO is not available.
    [...]
    >> +/*
    >> + * For archs where PAGE_KERNEL_RO is not supported;
    >> + * mapping the AR buffers readonly for the CPU is just a debugging aid.
    >> + */
    >> +#ifndef PAGE_KERNEL_RO
    >> +#define PAGE_KERNEL_RO PAGE_KERNEL
    >> +#endif
    >
    > This might cause interesting issues on sparc64 if it ever acquired a
    > PAGE_KERNEL_RO. Sparc64 has extern pgprot_t for it's PAGE_KERNEL types
    > rather than #defines, so the #ifdef check wouldn't see this.
    >
    > I think either PAGE_PROT_RO becomes part of our arch API (so all
    > architectures are forced to add it), or, if it's not part of the API,
    > ohci isn't entitled to use it. The latter seems simplest since you have
    > no real use for write protection anyway.

    Reported-by: Andrew Morton
    Signed-off-by: Stefan Richter

    Clemens Ladisch
     

04 Jan, 2011

5 commits