Re: [PATCH] isp1760-hcd: rework usb errata poller to isr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Arvid,

On Mon, Apr 16, 2012 at 05:11:25PM +0000, Arvid Brodin wrote:
> On 2012-04-13 16:39, Michael Grzeschik wrote:
> > Hi Arvid,
> > 
> > On Fri, Apr 13, 2012 at 01:58:25PM +0000, Arvid Brodin wrote:
> >> On 2012-04-13 12:59, Michael Grzeschik wrote:
> >>> The errata2 workaround is described in the Datasheet as follows:
> >>>
> >>>   An SOF INT can be used instead of an ATL INT with polling on Done
> >>>   bits. A time-out can be implemented and if a certain Done bit is never
> >>>   set, verification of the PTD completion can be done by reading PTD
> >>>   contents (valid bit). This is a proven workaround implemented in
> >>>   software.
> >>>
> >>> Therefore, we should do so, and ignore the check
> >>> for the ACTIVE_BIT in DW3. Because it is possible
> >>> that this bit is still set when the issue accures.
> >>
> >> I believe you trust the datasheet too much! :) I've tried this before (in fact, most of
> >> your code seems to be from an earlier patch of mine). It doesn't work, as explained in the
> >> comment to errata2_function() (and as tested with the usbtest/testusb suite).
> > 
> > Yes, i know the older patches struggling with that issue. But in both
> > cases there were some details which does not fit to the exact errata2
> > fix description.
> > 
> > In the first patch (USB: isp1760: Implement solution for erratum 2)
> > the content checking (Valid Bit: 0) was totaly left out of sight.
> > 
> > The second patch (usb/isp1760: Use polling instead of SOF interrupts to
> > fix Errata 2) was checking too much. As described above, the check for
> > the ACTIVE_BIT must not be done.
> > 
> > In the current implementation we still run into hanging unhandled urbs
> > because they sometimes doesn't get both bits toggled. (V==0 && A==0)
> > 
> > After solving this, it is easy to change the polling function back to
> > always enabled interrupts. In fact the enabling of SOF Interrupts
> > doesn't have anything else in mind than to guarantee that we never run
> > out of interrupts. That actually is nothing else then polling in
> > hardware. Instead of doing it with a timer function.
> 
> Aha, I missed the removal of the ACTIVE_BIT==0 check in the patch. Nice find!
> 
> So your patch is really doing two things:
> 
> 1) Remove the ACTIVE_BIT==0 check - this fixes the bug you are hitting. Great!
> 2) Switch from software timer checking at ~5 Hz to SOF interrupt checking at, was it 1
> kHz? Is this really neccessary/useful?

Yes, because with some high rated transfers going via the host
controller, especially in the case of having many slots queued at once,
the issue can trigger actually a lot. Its better not to wait that long
time every time that issue happens. This can run that host controller
actually worthless and not worth calling "high speed" capable. ;-)

Regards,
Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux