Changeset 1451

Timestamp:

11/22/08 07:01:20 (14 years ago)

Author:

wagi

Message:

Add workaround for the Edirol FA-101. The device issues more
than one FCP respond to one request. The IEEE1394 allows now
to filter for duplicated FCP packets. Though the filtering is
a rather ugly thing, it is only enabled for the FA-101. For all other
devices nothing changes.

Now with this fix the mixer should work for the FA-101 again.

Files:

• branches/libffado-2.0/src/bebob/edirol/edirol_fa101.cpp (modified) (1 diff)
• branches/libffado-2.0/src/libieee1394/ieee1394service.cpp (modified) (5 diffs)
• branches/libffado-2.0/src/libieee1394/ieee1394service.h (modified) (2 diffs)

branches/libffado-2.0/src/bebob/edirol/edirol_fa101.cpp

@@ -40 +40 @@
-    m_fixed_clocksource.slipping = false;
-    m_fixed_clocksource.description = "Device Controlled";
+
+    get1394Service().setFCPResponseFiltering(true);
-}
-

branches/libffado-2.0/src/libieee1394/ieee1394service.cpp

@@ -63 +63 @@
-    , m_pCTRHelper ( new CycleTimerHelper( *this, IEEE1394SERVICE_CYCLETIMER_DLL_UPDATE_INTERVAL_USEC ) )
-    , m_have_new_ctr_read ( false )
+    , m_filterFCPResponse ( false )
-    , m_pWatchdog ( new Util::Watchdog() )
-{
@@ -92 +93 @@
-                                           IEEE1394SERVICE_CYCLETIMER_HELPER_PRIO ) )
-    , m_have_new_ctr_read ( false )
+    , m_filterFCPResponse ( false )
-    , m_pWatchdog ( new Util::Watchdog() )
-{
@@ -822 +824 @@
-                                   unsigned char *data)
-{
+    static struct sFcpBlock fcp_block_last;
+
-    fb_quadlet_t *data_quads = (fb_quadlet_t *)data;
-    #ifdef DEBUG
@@ -857 +861 @@
-                             FCP_MASK_SUBUNIT_AND_OPCODE(first_quadlet),
-                             FCP_MASK_SUBUNIT_AND_OPCODE(CondSwapFromBus32(m_fcp_block.request[0])));
+            } else if(m_filterFCPResponse && (memcmp(fcp_block_last.response, data, length) == 0)) {
+                // This is workaround for the Edirol FA-101. The device tends to send more than
+                // one responde to one request. This seems to happen when discovering 
+                // function blocks and looks very likely there is a race condition in the 
+                // device. The workaround here compares the just arrived FCP responde
+                // to the last one. If it is the same as the previously one then we
+                // just ignore it. The downside of this approach is, we cannot issue
+                // the same FCP twice.
+                debugWarning("Received duplicate FCP response. Ignore it\n");
-            } else {
-                m_fcp_block.response_length = (length + sizeof(quadlet_t) - 1) / sizeof(quadlet_t);
-                memcpy(m_fcp_block.response, data, length);
+                if (m_filterFCPResponse) {
+                    memcpy(fcp_block_last.response, data, length);
+                }
-                m_fcp_block.status = eFS_Responded;
-            }
@@ -919 +935 @@
-
-    return (split_timeout_hi & 7) * 1000000 + (split_timeout_low >> 19) * 125;
+}
+
+void 
+Ieee1394Service::setFCPResponseFiltering(bool enable)
+{
+    m_filterFCPResponse = enable;
-}
-

branches/libffado-2.0/src/libieee1394/ieee1394service.h

@@ -322 +322 @@
-
-    Util::Configuration *getConfiguration() {return m_configuration;};
+
+    /**
+     * @brief enable or disable FCP response doublicate filtering
+     *
+     * this is use only for devices (e.g. edirol fa101) which have a 
+     * buggy FCP implementation and send more then one FCP response 
+     * for one request. 
+     */
+    void setFCPResponseFiltering(bool enable);
-
-// ISO channel stuff
@@ -394 +403 @@
-    bool                    m_have_new_ctr_read;
-
+    bool            m_filterFCPResponse;
+
-    // the RT watchdog
-    Util::Watchdog*     m_pWatchdog;