Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 09 10月, 2011 2 次提交
  3. 17 9月, 2011 3 次提交
  5. 12 8月, 2011 1 次提交
  7. 10 7月, 2011 1 次提交
  9. 09 7月, 2011 4 次提交
    • S
      firewire: ohci: skip soft reset retries after card ejection · 9f426173
      由 Stefan Richter 提交于 
      The software reset in firewire-ohci's pci_remove does not have a great
prospect of success if the card was already physically removed at this
point.  So let's skip the 500 ms that were spent in retries here.

Also, replace a defined constant by its open-coded value.  This is not a
constant from a specification but an arbitrarily chosen retry limit.  It
was only used in this single place.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      9f426173
    • S
      firewire: ohci: fix PHY reg access after card ejection · 215fa444
      由 Stefan Richter 提交于 
      Detect and handle ejection of FireWire CardBus cards in PHY register
accesses:

  - The last attempt of firewire-core to reset the bus during shutdown
    caused a spurious "firewire_ohci: failed to write phy reg" error
    message in the log.  Skip this message as well as the prior retry
    loop that needlessly took 100 milliseconds.

  - In the unlikely case that a PHY register was read right after card
    ejection, a bogus value was obtained and possibly acted upon.
    Instead, fail the read attempt.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      215fa444
    • S
      firewire: ohci: add a comment on PHY reg access serialization · b14c369d
      由 Stefan Richter 提交于 
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      b14c369d
    • S
      firewire: ohci: reduce potential context_stop latency · 9ef28ccd
      由 Stefan Richter 提交于 
      Stopping an isochronous reception DMA context takes two loop iterations
in context_stop on several controllers (JMicron, NEC, VIA).  But there
is no extra delay necessary between these two reg_read trials; the MMIO
reads themselves are slow enough.  Hence bring back the behavior from
before commit dd6254e5 "firewire: ohci:
remove superfluous posted write flushes" on these controllers by means
of an "if (i)" condition.

Isochronous context stop is performed in preemptible contexts (and only
rarely), hence this change is of little impact.  (Besides, Agere and TI
controllers always, or almost always, have the context stopped already
at the first ContextControl read.)

More important is asynchronous transmit context stop, which is performed
while local interrupts are disabled (on the two AT DMAs in
bus_reset_tasklet, i.e. after a self-ID-complete event).  In my
experience with several controllers, tested with a usermode AT-request
transmitter as well as with FTP transmission over firewire-net, the AT
contexts were luckily already stopped at the first ContextControl read,
i.e. never required another MMIO read let alone mdelay.  A possible
explanation for this is that the controllers which I tested perhaps stop
AT DMA before they perform the self-ID reception DMA.

But we cannot be sure about that and should keep the interrupts-disabled
busy loop as short as possible.  Hence, query the ContextControl
register in 1000 udelay(10) intervals instead of 10 udelay(1000)
intervals.  I understand from an estimation by Clemens Ladisch that
stopping a busy DMA context should take microseconds or at worst tens of
microseconds, not milliseconds.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      9ef28ccd
  11. 02 6月, 2011 1 次提交
    • C
      firewire: ohci: remove superfluous posted write flushes · dd6254e5
      由 Clemens Ladisch 提交于 
      The call to flush_writes() in context_stop() is superfluous because
another register read is done immediately afterwards.

The call to flush_writes() in ar_context_run() does not need to be done
individually for each AR context, so move it to ohci_enable().  This
also makes ohci_enable() clearer because it no longer depends on a side
effect of ar_context_run() to flush its own register writes.

Finally, the setting of a context's wake bit does not need to be flushed
because neither the driver logic nor the API require the CPU to wait for
this action.  This removes the last MMIO reads from the packet queueing
code paths.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      dd6254e5
  13. 11 5月, 2011 1 次提交
    • C
      firewire: optimize iso queueing by setting wake only after the last packet · 13882a82
      由 Clemens Ladisch 提交于 
      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: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      13882a82
  15. 03 5月, 2011 1 次提交
    • B
      firewire: Fix for broken configrom updates in quick succession · 2e053a27
      由 B.J. Buchalter 提交于 
      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 02d37bed "firewire: core:
integrate software-forced bus resets with bus management" which
introduced long mandatory delays between janitorial bus resets.]
Signed-off-by: NBenjamin Buchalter <bj@mhlabs.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (trivial style changes)
Cc: <stable@kernel.org> # 2.6.36.y and newer
      2e053a27
  17. 20 4月, 2011 3 次提交
  19. 15 3月, 2011 2 次提交
  21. 26 2月, 2011 2 次提交
  23. 23 1月, 2011 1 次提交
  25. 13 1月, 2011 1 次提交
    • C
      firewire: ohci: fix compilation on arches without PAGE_KERNEL_RO · 14271304
      由 Clemens Ladisch 提交于 
      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: NClemens Ladisch <clemens@ladisch.de>

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: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      14271304
  27. 04 1月, 2011 4 次提交
  29. 14 12月, 2010 9 次提交
  31. 12 12月, 2010 2 次提交
  33. 31 10月, 2010 2 次提交