1. 21 4月, 2008 19 次提交
  2. 19 4月, 2008 7 次提交
  3. 18 4月, 2008 14 次提交
    • A
      firewire: cleanups · db8be076
      Adrian Bunk 提交于
      This patch contains the following cleanups:
      - #if 0 the following unused structs:
        - fw-transaction.c:fw_low_memory_region
        - fw-transaction.c:fw_private_region
        - fw-transaction.c:fw_csr_region
        - fw-transaction.c:fw_unit_space_region
      - remove the following unused EXPORT_SYMBOL's:
        - fw-card.c:fw_core_add_descriptor
        - fw-card.c:fw_core_remove_descriptor
        - fw-iso.c:fw_iso_context_create
        - fw-iso.c:fw_iso_context_destroy
        - fw-iso.c:fw_iso_context_start
        - fw-iso.c:fw_iso_context_queue
        - fw-iso.c:fw_iso_context_stop
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      db8be076
    • S
      firewire: fix synchronization of gap counts · 25b1c3d8
      Stefan Richter 提交于
      Fix:  The fact that nodes had different gap counts would be overlooked
      if the bus manager code would pick gap count 63 because of beta
      repeaters or because of very large hop counts.  In this case, the bus
      manager code would miss that it actually has to send the PHY config
      packet with gap count 63.
      
      Related trivial changes:  Use bool for an int used as bool, touch up
      some comments.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      25b1c3d8
    • S
      firewire: wait until PHY configuration packet was transmitted (fix bus reset loop) · 2a0a2590
      Stefan Richter 提交于
      We now exit fw_send_phy_config /after/ the PHY config packet has been
      transmitted, instead of before.  A subsequent fw_core_initiate_bus_reset
      will therefore not overlap with the transmission.  This is meant to make
      the send PHY config packet + reset bus routine more deterministic.
      
      Fixes bus reset loop and eventual panic with
        - VIA VT6307 + IOGEAR hub + Unibrain Fire-i camera
          http://bugzilla.kernel.org/show_bug.cgi?id=10128
        - JMicron card
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      2a0a2590
    • S
      firewire: remove unused struct member · e09770db
      Stefan Richter 提交于
      request_generation is internal to fw-ohci and unneeded in fw_card.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      e09770db
    • J
      firewire: use bitwise and to get reg in handle_registers · 15f0d833
      Jarod Wilson 提交于
      for code efficiency.
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      15f0d833
    • J
      firewire: replace more hex values with defined csr constants · cca60977
      Jarod Wilson 提交于
      Trivial change to replace more meaningless (to the untrained eye) hex
      values with defined CSR constants.
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      cca60977
    • S
      firewire: reread config ROM when device reset the bus · c9755e14
      Stefan Richter 提交于
      When a device changes its configuration ROM, it announces this with a
      bus reset.  firewire-core has to check which node initiated a bus reset
      and whether any unit directories went away or were added on this node.
      
      Tested with an IOI FWB-IDE01AB which has its link-on bit set if bus
      power is available but does not respond to ROM read requests if self
      power is off.  This implements
        - recognition of the units if self power is switched on after fw-core
          gave up the initial attempt to read the config ROM,
        - shutdown of the units when self power is switched off.
      
      Also tested with a second PC running Linux/ieee1394.  When the eth1394
      driver is inserted and removed on that node, fw-core now notices the
      addition and removal of the IPv4 unit on the ieee1394 node.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      c9755e14
    • S
      firewire: replace static ROM cache by allocated cache · 1dadff71
      Stefan Richter 提交于
      read_bus_info_block() is repeatedly called by workqueue jobs.
      These will step on each others toes eventually if there are multiple
      workqueue threads, and we end up with corrupt config ROM images.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      1dadff71
    • S
      firewire: fw-ohci: work around generation bug in TI controllers (fix AV/C and more) · d34316a4
      Stefan Richter 提交于
      Unlike the ohci1394 driver, fw-ohci uses the selfIDGeneration field of
      bus reset packets to determine the generation of incoming requests as
      per OHCI 1.1 clause 8.4.2.3.  This is more precise --- provided that the
      controller inserts the correct generation.  Texas Instruments chips
      often don't.
      
      This prevented the transmission of response packets, which for example
      broke AV/C transactions as used when communicating with miniDV cameras
      and any other AV/C devices.
      
      There is apparently no way to detect and adjust incorrect generations.
      Therefore we ignore the generation of bus reset packets from TI chips
      and use the generation of the self ID buffer instead.  Alas this is
      received at a slightly wrong time.  In rare cases, this could cause us
      to not respond to legitimate requests or to respond to expired requests.
      (The latter is less likely because the bus reset packet AR event is
      typically handled before the self ID complete event.)
      
      Bug reported by Mladen Kuntner, who was extraordinarily patient while
      dealing with the driver maintainers.  Fix confirmed to be required and
      effective for TSB82AA2 and a TSB43AB22 or TSB43AB22A.
      https://bugzilla.redhat.com/show_bug.cgi?id=243081Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      d34316a4
    • S
      firewire: fw-ohci: extend logging of bus generations and node ID · 08ddb2f4
      Stefan Richter 提交于
      Extend the logging of "AR evt_bus_reset, link internal" to "AR
      evt_bus_reset, generation ${selfIDGeneration}".  That way we can check
      whether this generation matches the one seen in self ID complete event
      logging.  See OHCI 1.1 clause 8.4.2.3.
      
      Also extend logging of "firewire_ohci: * selfIDs, generation *" by
      "local node ID ffc*" in self ID logging to make the local node in AT/AR
      event logs more obvious.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      08ddb2f4
    • S
      firewire: fw-ohci: conditionally log busReset interrupts · a007bb85
      Stefan Richter 提交于
      Add a debug option to watch bus reset interrupt events.  Half of this
      patch is taken from Jarod Wilson's first version of the JMicron fix.
      
      BusReset interrupts are only generated if the respective module
      parameter flag was set before the controller is being initialized.
      Else we keep this event masked to reduce IRQ load in normal operation
      and to avoid potential problems with buggy chips.
      
      Note, this is unlike the other IRQ events whose logging can be enabled
      any time after chip initialization.  This and the influence on what
      interrupts the chip generates is why I added an extra flag for it.
      
      Also, reorder the debug parameter flags according to their perceived
      usefulness.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      a007bb85
    • J
      firewire: fw-ohci: don't append to AT context when it's not active · 76f73ca1
      Jarod Wilson 提交于
      I finally tracked down the issues with this JMicron PCI-e card in my
      possession to a failure to comply with section 7.2.3.2 of the OHCI 1.1
      specification (thanks to Kristian for the pointer to illustrate that it
      is indeed a flaw in this card, not the driver). The controller should
      simply flush the packets we've appended to its AT queue if a bus reset
      occurs before they've been transmitted and we'll try again, but
      something goes wrong and the controller winds up hung.
      
      However, we can avoid the problem by simply checking if the
      IntEvent.busReset register had been set before we try appending to the
      AT context. When busReset is set, the AT context is completely halted
      until busReset is cleared, so there's no point in appending AT packets
      until the register is cleared. So at_context_queue_packet() now checks
      for busReset being set, and bails with an RCODE_GENERATION packet ack,
      which results in us trying to append the packet again after recognizing
      the fact there has been a bus reset, and clearing busReset.
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      76f73ca1
    • J
      firewire: fw-ohci: log regAccessFail events · 75f7832e
      Jarod Wilson 提交于
      While trying to debug this piece of crap JMicron PCI-e controller in my
      possession, one thought was that perhaps I was encountering register access
      failures. I'm not, but logging them would be good, so we can see if they
      are a real problem we should be taking into account anywhere in the code.
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (added list contact)
      75f7832e
    • J
      firewire: fw-ohci: make sure HCControl register LPS bit is set · 02214724
      Jarod Wilson 提交于
      I've now witnessed multiple occasions where one of my controllers (a very
      poorly working JMicron PCIe card) fails to get its registers properly set
      up in ohci_enable(), apparently due to an occasionally very slow to
      initiate SClk. The easy fix for this problem is to add a tiny while loop
      to try again a time or three after initially enabling LPS before we
      move on (or give up).
      
      Of course, the card still isn't fully functional yet, but this gets it at
      least one tiny step closer...
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      02214724