Re: [FFADO-devel] [alsa-devel] [PATCH 52/52] bebob: Add support for M-Audio special Firewire series

From: "Малышев Михаил" <miha.malyshev@yandex.ru>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: alsa-devel@alsa-project.org,
	linux1394-devel@lists.sourceforge.net, ffado-devel@lists.sf.net
Subject: Re: [FFADO-devel] [alsa-devel] [PATCH 52/52] bebob: Add support for M-Audio special Firewire series
Date: Wed, 26 Feb 2014 00:12:22 +0400	[thread overview]
Message-ID: <169421393359142@web13g.yandex.ru> (raw)
In-Reply-To: <530CF745.40309@ladisch.de>

I have posted on wiki my findings about fcp transaction timings and some other info about timing for fw 1814. It worked good in my version of Takashi's driver. Unfortunatly I forgot to push it to my fork of git repo befor I moved to Finland and cannot do it remotly right now. I have implemented special fcp related function specially for fw 1814 which deals with timeouts about 350ms and when driver sets samplong rate there must be 1s delay before any following fw write operation

--Michael

26.02.14, 00:05, "Clemens Ladisch" <clemens@ladisch.de>":
> 
> Takashi Sakamoto wrote:
> > Can I request your comment for this patch about a quirk of transaction?
> >
> > M-Audio Firewire 1814 and ProjectMix I/O often send no response against
> > driver's request, even if the device handle the request.
> >
> > For CMP and Isochronous Resource Management, this quirk works badly.
> > When a request from driver is handled by the device but the device
> > don't respond, the drivers (firewire_core/snd-firewire-lib) retry the
> > request. Then a response for the second request brings error because
> > the operation for connection or isochronous resource management is
> > already done in device side.
> 
> Maybe we should change how these functions handle timeouts.  Any other
> error code indicates that the lock transaction failed definitely, but
> after a timeout, we don't know if it was the request or the response
> that got lost.
> 
> We could try to read the register, and, if we see that the change that we
> tried to do actually happend, assume that our driver's transaction did
> this change.
> 
> Are read transactions more reliable than locks?  If not, we might need
> to increase the number of retries for these devices.
> 
> > Against this quirk, I want to merge this patch for upstream
> 
> This patch (no. 52) does not change the CMP code.
> 
> 
> Regards,
> Clemens
> 
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> FFADO-devel mailing list
> FFADO-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ffado-devel

-- 
Отправлено из мобильной Яндекс.Почты: http://m.ya.ru/ymail

------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
mailing list linux1394-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-devel