05 Jan, 2009

4 commits

  • Two access functions get_max_rom and set_hw_config_rom are
    changed to take __be32 as well. Only bus_info_data was
    ever passed in so this is OK. All other uses of bus_info_data
    treated it as a be32 value already.

    Signed-off-by: Harvey Harrison
    Signed-off-by: Stefan Richter

    Harvey Harrison
     
  • and replace busy-wait by msleep.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • Signed-off-by: Stefan Richter

    Stefan Richter
     
  • On my HP 2510p I get the following in dmesg during near the end of most
    resumes from suspend to RAM:

    irq 19: nobody cared (try booting with the "irqpoll" option)
    Pid: 0, comm: swapper Not tainted 2.6.28-rc7 #67
    Call Trace:
    [] ? ohci_irq_handler+0x60/0x7e9 [ohci1394]
    [] __report_bad_irq+0x38/0x87
    [] note_interrupt+0x10e/0x174
    [] handle_fasteoi_irq+0xa7/0xd1
    [] do_IRQ+0x73/0xe4
    [] ret_from_intr+0x0/0xa
    [] ? acpi_idle_enter_bm+0x26b/0x2b2 [processor]
    [] ? acpi_idle_enter_bm+0x261/0x2b2 [processor]
    [] ? notifier_call_chain+0x33/0x5b
    [] ? cpuidle_idle_call+0x8c/0xc4
    [] ? cpu_idle+0x4a/0x9a
    [] ? rest_init+0x5c/0x5e
    handlers:
    [] (ohci_irq_handler+0x0/0x7e9 [ohci1394])
    Disabling IRQ #19

    There also seems to be an interrupt storm during suspend/resume when this
    happens:
    19: 99968 33 IO-APIC-fasteoi ohci1394

    This patch gets rid of both issues and makes the resume as a whole
    significantly faster.

    Signed-off-by: Frans Pop

    As was pointed out in http://lkml.org/lkml/2008/12/6/127, this does not
    fix the cause of the interrupt storm. However, since the source of the
    interrupts could not be determined yet, we make the system at least more
    usable with this change.

    Signed-off-by: Stefan Richter

    Frans Pop
     

26 Apr, 2008

1 commit

  • As it seems, some host controllers have issues that can cause them to
    skip cycles now and then when using large packets. I suspect that this
    is due to DMA not succeeding in time. If the transmit fifo can't contain
    more than one packet (big packets), the DMA should provide a new packet
    each cycle (125us). I am under the impression that my current PCI
    express test system can't guarantee this.

    In any case, the patch tries to provide a workaround as follows:
    The DMA program descriptors are modified such that when an error occurs,
    the DMA engine retries the descriptor the next cycle instead of
    stalling. This way no data is lost. The side effect of this is that
    packets are sent with one cycle delay. This however might not be that
    much of a problem for certain protocols (e.g. AM824). If they use
    padding packets for e.g. rate matching they can drop one of those to
    resync the streams.

    The amount of skips between two userspace wakeups is counted. This
    number is then propagated to userspace through the upper 16 bits of the
    'dropped' parameter. This allows unmodified userspace applications due
    to the following:
    1) libraw simply passes this dropped parameter to the user application
    2) the meaning of the dropped parameter is: if it's nonzero, something
    bad has happened. The actual value of the parameter at this moment does
    not have a specific meaning.

    A libraw client can then retrieve the number of skipped cycles and
    account for them if needed.

    Signed-off-by: Pieter Palmers
    Signed-off-by: Stefan Richter

    Pieter Palmers
     

18 Apr, 2008

7 commits


31 Jan, 2008

1 commit


21 Sep, 2007

1 commit

  • Initialization of ohci1394 was broken according to one reporter if the
    driver was statically linked, i.e. not built as loadable module. Dmesg:

    PCI: Device 0000:02:07.0 not available because of resource collisions
    ohci1394: Failed to enable OHCI hardware.

    This was reported for a Toshiba Satellite 5100-503. The cause is commit
    8df4083c5291b3647e0381d3c69ab2196f5dd3b7 in Linux 2.6.19-rc1 which only
    served purposes of early remote debugging via FireWire. This
    functionality is better provided by the currently out-of-tree driver
    ohci1394_earlyinit. Reversal of the commit was OK'd by Andi Kleen.

    Signed-off-by: Stefan Richter

    Stefan Richter
     

10 Jul, 2007

2 commits

  • Based on patch "the scheduled removal of RAW1394_REQ_ISO_{SEND,LISTEN}"
    from Adrian Bunk, November 20 2006.

    This patch also removes the underlying facilities in ohci1394 and
    disables them in pcilynx. That is, hpsb_host_driver.devctl() and
    hpsb_host_driver.transmit_packet() are no longer used for iso reception
    and transmission.

    Since video1394 and dv1394 only work with ohci1394 and raw1394's rawiso
    interface has never been implemented in pcilynx, pcilynx is now no
    longer useful for isochronous applications.

    raw1394 will still handle the request types but will complete the
    requests with errors that indicate API version conflicts.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • spotted by Robert P. J. Day

    Signed-off-by: Stefan Richter

    Stefan Richter
     

30 Apr, 2007

4 commits


18 Feb, 2007

1 commit


15 Feb, 2007

1 commit

  • After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

09 Feb, 2007

3 commits


08 Dec, 2006

9 commits

  • There has been an if(...) missing, for ages.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • Adjust whitespace and line lengths

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7431
    iBook G3 threw a machine check exception and put the display backlight
    to full brightness after ohci1394 was unloaded and reloaded.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • To print irq number no need to transform to string using %d, then print
    using %s. Just use %d.

    Signed-off-by: Alexey Dobriyan

    Alexey Dobriyan
     
  • - correct thinko in one of my last commits: cannot use PRINT macro with
    ohci == NULL
    - add log messages on ohci == NULL and on pci_enable_device != 0
    - update log macros from patch "revert fail on error in suspend" to use
    PRINT and DBGMSG where possible

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • Some errors during preparation for suspended state can be skipped with a
    warning instead of a failure of the whole suspend transition, notably an
    error in pci_set_power_state.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • Reorder the definitions of ohci1394_pci_suspend and _resume. Remove
    redundant comments. Beautify return statements.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • I did a quick shot on what I described and the appended patch
    does the first thing needed for working suspend/resume
    in ohci1394 which is HW de- and re-initialisation.

    It works with suspend2disk on my Ricoh R5C552 IEEE 1394 Controller
    with the 2.6.17 kernel to the extent that if I call dvgrab --interactive
    after suspend2disk without unloading ohci1394, it does not lock up
    dvgrab with 100% CPU but properly connects to the camera, given
    that I first unplug and plug the camera after coming back from
    suspend.

    I guess that could be fixed by forcing a bus reset in the resume
    function.

    I cannot test suspend to RAM here at the moment and should
    follow the guidelines in Documentation/power/pci.txt also,
    so this is rather a quick report than a finished patch and
    there are some rough edges:

    However, with this patch, I have to unload at least some in-kernel
    users of ohci1394 like dv1394 or video1394 before suspending.

    Not doing that caused an Oops and a bad tasklet error, probably from
    not handling ISO tasklets during suspend/resume properly.

    Maybe these can be temporarily cleared or unregistered and
    re-registered for suspend/resume with help from the other
    layers or from the highlevel 1394 core, but I do not really
    know what these do.

    But this patch provides a useful base to start from and is
    already of much help for people which do not need dv1394
    and video1394 or can unload them at least during suspend.

    I cannot test function with sbp2 at the moment, but raw1394
    seems to work fine.

    Signed-off-by: Bernhard Kaindl

    Update 1: merge with previous two ohci1394 suspend/resume patches
    Update 2: version for application on top of Linux 2.6.19-rc4

    Signed-off-by: Stefan Richter

    Bernhard Kaindl
     
  • SLAB_KERNEL is an alias of GFP_KERNEL.

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

30 Oct, 2006

1 commit


05 Oct, 2006

1 commit

  • Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
    of passing regs around manually through all ~1800 interrupt handlers in the
    Linux kernel.

    The regs pointer is used in few places, but it potentially costs both stack
    space and code to pass it around. On the FRV arch, removing the regs parameter
    from all the genirq function results in a 20% speed up of the IRQ exit path
    (ie: from leaving timer_interrupt() to leaving do_IRQ()).

    Where appropriate, an arch may override the generic storage facility and do
    something different with the variable. On FRV, for instance, the address is
    maintained in GR28 at all times inside the kernel as part of general exception
    handling.

    Having looked over the code, it appears that the parameter may be handed down
    through up to twenty or so layers of functions. Consider a USB character
    device attached to a USB hub, attached to a USB controller that posts its
    interrupts through a cascaded auxiliary interrupt controller. A character
    device driver may want to pass regs to the sysrq handler through the input
    layer which adds another few layers of parameter passing.

    I've build this code with allyesconfig for x86_64 and i386. I've runtested the
    main part of the code on FRV and i386, though I can't test most of the drivers.
    I've also done partial conversion for powerpc and MIPS - these at least compile
    with minimal configurations.

    This will affect all archs. Mostly the changes should be relatively easy.
    Take do_IRQ(), store the regs pointer at the beginning, saving the old one:

    struct pt_regs *old_regs = set_irq_regs(regs);

    And put the old one back at the end:

    set_irq_regs(old_regs);

    Don't pass regs through to generic_handle_irq() or __do_IRQ().

    In timer_interrupt(), this sort of change will be necessary:

    - update_process_times(user_mode(regs));
    - profile_tick(CPU_PROFILING, regs);
    + update_process_times(user_mode(get_irq_regs()));
    + profile_tick(CPU_PROFILING);

    I'd like to move update_process_times()'s use of get_irq_regs() into itself,
    except that i386, alone of the archs, uses something other than user_mode().

    Some notes on the interrupt handling in the drivers:

    (*) input_dev() is now gone entirely. The regs pointer is no longer stored in
    the input_dev struct.

    (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
    something different depending on whether it's been supplied with a regs
    pointer or not.

    (*) Various IRQ handler function pointers have been moved to type
    irq_handler_t.

    Signed-Off-By: David Howells
    (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)

    David Howells
     

18 Sep, 2006

4 commits