24 Jan, 2009

1 commit

  • Camcorders have a tendency to fail read requests to their config ROM and
    write request to their FCP command register with ack_busy_X. This has
    become a problem with newer kernels and especially Panasonic camcorders,
    causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently
    logs "send oops"; kino reports loss of AV/C control. I suspect that
    lower CPU scheduling latencies in newer kernels made this issue more
    prominent now.

    According to
    https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103
    this can be fixed by configuring the FireWire controller for more
    hardware retries for request transmission; these retries are evidently
    more successful than libavc1394's own retry loop (typically 3 tries on
    top of hardware retries).

    Presumably the same issue has been reported at
    https://bugzilla.redhat.com/show_bug.cgi?id=449252 and
    https://bugzilla.redhat.com/show_bug.cgi?id=477279 .

    Tested-by: Mathias Beilstein
    Signed-off-by: Stefan Richter

    Stefan Richter
     

10 Jul, 2007

1 commit

  • 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
     

30 Apr, 2007

1 commit


13 Jun, 2006

1 commit

  • This patch supplies the API extension introduced by patch
    "ieee1394: extend lowlevel API for address range properties"
    with proper addresses.

    Like in patch ''ohci1394, sbp2: fix "scsi_add_device failed"
    with PL-3507 based devices'', 1 TeraByte is chosen as physical
    upper bound. This leaves a window for the middle address range.
    This choice is only relevant for adapters which actually have a
    programmable pysical upper bound register. (Only ALi and
    Fujitsu adapters are known for this. Most adapters have a fixed
    bound at 4 GB.) The middle address range is suitable for posted
    writes.

    AFAIK, PCILynx does not support physical DMA nor posted writes,
    therefore no equivalent change in the pcilynx driver is necessary.
    There is also a driver for GP2Lynx, although not in mainline Linux.
    I assume this hardware does not support these OHCI features either.

    Signed-off-by: Stefan Richter
    Signed-off-by: Ben Collins

    Ben Collins
     

18 Nov, 2005

1 commit

  • Remove the Audio and Music Data Transmission Protocol driver and the
    Connection Management Procedures driver. These are incomplete, have never
    worked, and are better implemented in userland via raw1394 (see
    http://freebob.sourceforge.net/ for example.)

    Signed-off-by: Jody McIntyre
    Cc: Adrian Bunk

    Jody McIntyre
     

17 May, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds