--- /dev/null
+From stefanr@s5r6.in-berlin.de Sun Feb 8 12:42:41 2009
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Sat, 7 Feb 2009 13:08:41 +0100 (CET)
+Subject: firewire: ohci: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others
+To: stable@kernel.org
+Message-ID: <tkrat.c40219855501ef69@s5r6.in-berlin.de>
+Content-Disposition: INLINE
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+Commit 8b7b6afaa84708d08139daa08538ca3e56c351f1 upstream.
+
+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 .
+
+In a quick test with a JVC camcorder (which didn't malfunction like the
+reported camcorders), this change decreased the number of ack_busy_X
+from 16 in three runs of dvgrab to 4 in three runs of the same capture
+duration.
+
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/firewire/fw-ohci.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/firewire/fw-ohci.c
++++ b/drivers/firewire/fw-ohci.c
+@@ -226,7 +226,7 @@ static inline struct fw_ohci *fw_ohci(st
+ #define CONTEXT_DEAD 0x0800
+ #define CONTEXT_ACTIVE 0x0400
+
+-#define OHCI1394_MAX_AT_REQ_RETRIES 0x2
++#define OHCI1394_MAX_AT_REQ_RETRIES 0xf
+ #define OHCI1394_MAX_AT_RESP_RETRIES 0x2
+ #define OHCI1394_MAX_PHYS_RESP_RETRIES 0x8
+
--- /dev/null
+From stefanr@s5r6.in-berlin.de Sun Feb 8 12:43:24 2009
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Sat, 7 Feb 2009 13:10:00 +0100 (CET)
+Subject: firewire: sbp2: add workarounds for 2nd and 3rd generation iPods
+To: stable@kernel.org
+Message-ID: <tkrat.5e8cf2d4c64d3087@s5r6.in-berlin.de>
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+Commit c8c4707cf7ca8ff7dcc1653447e48cb3de0bf114 upstream.
+
+According to https://bugs.launchpad.net/bugs/294391
+ - 3rd generation iPods need the "fix capacity" workaround after all
+ (apparently they crash after the last sector was accessed),
+ - 2nd generation iPods need the "128 kB maximum request size"
+ workaround.
+
+Alas both iPod generations feature the same model ID in the config ROM,
+hence we can only define a shared quirks list entry for them. Luckily
+the fix capacity workaround did not show a negative effect in Jarod's
+tests with 2nd gen. iPod.
+
+A side note: Apple computers in target mode (or at least an x86 Mac
+mini) don't have firmware_version and model_id, hence none of the iPod
+quirks list entries is active for them.
+
+Tested-by: Jarod Wilson <jarod@redhat.com>
+Acked-by: Jarod Wilson <jarod@redhat.com>
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/firewire/fw-sbp2.c | 16 +++++++++-------
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+--- a/drivers/firewire/fw-sbp2.c
++++ b/drivers/firewire/fw-sbp2.c
+@@ -350,15 +350,17 @@ static const struct {
+ .model = ~0,
+ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS,
+ },
+-
+ /*
+- * There are iPods (2nd gen, 3rd gen) with model_id == 0, but
+- * these iPods do not feature the read_capacity bug according
+- * to one report. Read_capacity behaviour as well as model_id
+- * could change due to Apple-supplied firmware updates though.
++ * iPod 2nd generation: needs 128k max transfer size workaround
++ * iPod 3rd generation: needs fix capacity workaround
+ */
+-
+- /* iPod 4th generation. */ {
++ {
++ .firmware_revision = 0x0a2700,
++ .model = 0x000000,
++ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS |
++ SBP2_WORKAROUND_FIX_CAPACITY,
++ },
++ /* iPod 4th generation */ {
+ .firmware_revision = 0x0a2700,
+ .model = 0x000021,
+ .workarounds = SBP2_WORKAROUND_FIX_CAPACITY,
--- /dev/null
+From stefanr@s5r6.in-berlin.de Sun Feb 8 12:43:01 2009
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Sat, 7 Feb 2009 13:09:15 +0100 (CET)
+Subject: firewire: sbp2: fix DMA mapping leak on the failure path
+To: stable@kernel.org
+Message-ID: <tkrat.16226a54fdb77ef3@s5r6.in-berlin.de>
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+Commit 5e2125677fd72d36396cc537466e07ffcbbd4b2b upstream.
+
+Reported-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
+who also provided a first version of the fix.
+
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/firewire/fw-sbp2.c | 27 +++++++++++++++++----------
+ 1 file changed, 17 insertions(+), 10 deletions(-)
+
+--- a/drivers/firewire/fw-sbp2.c
++++ b/drivers/firewire/fw-sbp2.c
+@@ -1293,6 +1293,19 @@ static struct fw_driver sbp2_driver = {
+ .id_table = sbp2_id_table,
+ };
+
++static void sbp2_unmap_scatterlist(struct device *card_device,
++ struct sbp2_command_orb *orb)
++{
++ if (scsi_sg_count(orb->cmd))
++ dma_unmap_sg(card_device, scsi_sglist(orb->cmd),
++ scsi_sg_count(orb->cmd),
++ orb->cmd->sc_data_direction);
++
++ if (orb->request.misc & cpu_to_be32(COMMAND_ORB_PAGE_TABLE_PRESENT))
++ dma_unmap_single(card_device, orb->page_table_bus,
++ sizeof(orb->page_table), DMA_TO_DEVICE);
++}
++
+ static unsigned int
+ sbp2_status_to_sense_data(u8 *sbp2_status, u8 *sense_data)
+ {
+@@ -1372,15 +1385,7 @@ complete_command_orb(struct sbp2_orb *ba
+
+ dma_unmap_single(device->card->device, orb->base.request_bus,
+ sizeof(orb->request), DMA_TO_DEVICE);
+-
+- if (scsi_sg_count(orb->cmd) > 0)
+- dma_unmap_sg(device->card->device, scsi_sglist(orb->cmd),
+- scsi_sg_count(orb->cmd),
+- orb->cmd->sc_data_direction);
+-
+- if (orb->page_table_bus != 0)
+- dma_unmap_single(device->card->device, orb->page_table_bus,
+- sizeof(orb->page_table), DMA_TO_DEVICE);
++ sbp2_unmap_scatterlist(device->card->device, orb);
+
+ orb->cmd->result = result;
+ orb->done(orb->cmd);
+@@ -1530,8 +1535,10 @@ static int sbp2_scsi_queuecommand(struct
+ orb->base.request_bus =
+ dma_map_single(device->card->device, &orb->request,
+ sizeof(orb->request), DMA_TO_DEVICE);
+- if (dma_mapping_error(device->card->device, orb->base.request_bus))
++ if (dma_mapping_error(device->card->device, orb->base.request_bus)) {
++ sbp2_unmap_scatterlist(device->card->device, orb);
+ goto out;
++ }
+
+ sbp2_send_orb(&orb->base, lu, lu->tgt->node_id, lu->generation,
+ lu->command_block_agent_address + SBP2_ORB_POINTER);
--- /dev/null
+From stefanr@s5r6.in-berlin.de Sun Feb 8 12:42:14 2009
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Sat, 7 Feb 2009 13:08:01 +0100 (CET)
+Subject: ieee1394: ohci1394: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others
+To: stable@kernel.org
+Message-ID: <tkrat.c437ea34aa36a48c@s5r6.in-berlin.de>
+Content-Disposition: INLINE
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+Commit 64c634ef83991b390ec0503e61f16efb0ba3c60b upstream.
+
+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 <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/ieee1394/ohci1394.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/ieee1394/ohci1394.h
++++ b/drivers/ieee1394/ohci1394.h
+@@ -26,7 +26,7 @@
+
+ #define OHCI1394_DRIVER_NAME "ohci1394"
+
+-#define OHCI1394_MAX_AT_REQ_RETRIES 0x2
++#define OHCI1394_MAX_AT_REQ_RETRIES 0xf
+ #define OHCI1394_MAX_AT_RESP_RETRIES 0x2
+ #define OHCI1394_MAX_PHYS_RESP_RETRIES 0x8
+ #define OHCI1394_MAX_SELF_ID_ERRORS 16
--- /dev/null
+From stefanr@s5r6.in-berlin.de Sun Feb 8 12:43:44 2009
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Sat, 7 Feb 2009 13:10:36 +0100 (CET)
+Subject: ieee1394: sbp2: add workarounds for 2nd and 3rd generation iPods
+To: stable@kernel.org
+Message-ID: <tkrat.10bd7aedbacd0f70@s5r6.in-berlin.de>
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+Commit 1448d7c6a2ff96d3b52ecae49e2d0f046a097fe0 upstream.
+
+As per https://bugs.launchpad.net/bugs/294391. These got one sample of
+each iPod generation going. However there still occurred I/O stalls
+with the 3rd generation iPod which remain undiagnosed at the time of
+this writing.
+
+Acked-by: Jarod Wilson <jarod@redhat.com>
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/ieee1394/sbp2.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/ieee1394/sbp2.c
++++ b/drivers/ieee1394/sbp2.c
+@@ -395,6 +395,16 @@ static const struct {
+ .model_id = SBP2_ROM_VALUE_WILDCARD,
+ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS,
+ },
++ /*
++ * iPod 2nd generation: needs 128k max transfer size workaround
++ * iPod 3rd generation: needs fix capacity workaround
++ */
++ {
++ .firmware_revision = 0x0a2700,
++ .model_id = 0x000000,
++ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS |
++ SBP2_WORKAROUND_FIX_CAPACITY,
++ },
+ /* iPod 4th generation */ {
+ .firmware_revision = 0x0a2700,
+ .model_id = 0x000021,
sound-usb-audio-handle-wmaxpacketsize-for-fixed_endpoint-devices.patch
wait-prevent-exclusive-waiter-starvation.patch
x86-apic-enable-workaround-on-amd-fam10h-cpus.patch
+ieee1394-ohci1394-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch
+firewire-ohci-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch
+firewire-sbp2-fix-dma-mapping-leak-on-the-failure-path.patch
+firewire-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch
+ieee1394-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
