What I mean by better results is that as mentioned I observe PTS needing to
be resubmitted repeatedly. When handling SOF and ATL interrupts, I've
observed 3 cases:
(1) PTDs are resubmitted multiple times but get handled eventually before
USB timeout mechanisms kick in (OK, I guess)
(2) PTDs are resubmitted multiple times but get handled eventually after USB
timeout mechanisms kick in (not good as OHCI then shuts down the offending
endpoint)
(3) PTDs never seem to get handled (I've added some support to detect this
case and pass the offending PTD back as device not responding to avoid
hanging driver, but this shouldn't happen in the first place)
When switching to SOF handling, I have not yet observed (2) or (3). I
agree, it should not matter which way this is done. In fact handling the
ATL interrupt when it happens should increase performance as you are reading
from the buffer while the device is idle anyway. I have no good explanation
why this happens in the first place, as I can't determine if (a) the isp has
not processed the PTD or (b) the USB device has not ACK'ed the transaction.
All I know is that the isp would have had ample of time processing the PTD.
Note: This is a very easy 2 line change in Lothar's driver:
pretending we did not have this masked when reading the status:
dev->int_mask = __isp1362_read_reg16(dev, HCuPINTENB) |
HCuPINT_ISP116x_ATL
| HCuPINT_OPR;
writing the mask back in the ISR:
__isp1362_write_reg16(dev, HCuPINTENB, dev->int_mask &
~HCuPINT_ISP116x_ATL
& ~HCuPINT_OPR);
On a different note, I have observed an undocumented interrupt bit as shown
below in the InterruptStatus register (0x0080). It is masked out, so I'm
not worried about it. But it would be nice what it is. OHCI considers this
bit reserved, and so does the isp1160 documentation. Has anyone else seen
this?
bash-2.05# ./getispregs
0x0000: 0x00000010 HcRevision
0x0001: 0x00000080 HcControl
0x0002: 0x00000000 HcCommandStatus
0x0003: 0x00000080 HcInterruptStatus
0x0004: 0x8000001c HcInterruptEnable
0x0005: 0x8000001c HcInterruptDisable
0x000d: 0x27782edf HcFmInterval
0x000e: 0x00001f37 HcFmRemaining
0x000f: 0x0000d185 HcFmNumber
0x0011: 0x00000628 HcLSThreshold
0x0012: 0x00000202 HcRhDescriptorA
0x0013: 0x00000000 HcRhDescriptorB
0x0014: 0x00000000 HcRhStatus
0x0015: 0x00000103 HcRhPortStatus0
0x0016: 0x00000100 HcRhPortStatus1
0x0020: 0x00000009 HcHardwareConfiguration
0x0021: 0x00000000 HcDMAConfiguration
0x0022: 0x00000009 HcTransferCounter
0x0024: 0x00000014 HcmPInterrupt
0x0025: 0x00000021 HcmPInterruptEnable
-----Original Message-----
From: Olav Kongas [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 22, 2004 4:09 AM
To: Philipp Schmid
Cc: linux-usb-devel@lists.sourceforge.net
Subject: RE: [linux-usb-devel] ISP116x / 1362 driver progress
Hi Philipp,
Thank you for the comprehensive overview.
> A couple of observations:
>
> (a) I find many PTDS have to be resubmitted many times before they get
> handled by the device even if they are finished submitting early in the
> frame remaining cycle.
Transfers start after subsequent SOF after the submission is
finished. Therefore, it should make no difference whether
you finish submission early or late in the frame. I remember
that from my experiments with a logic analyzer on usb bus.
I have also seen that the ptd's for control transfers have
to be resubmitted repeatedly. Maybe this is normal.
> (b) I found better results by only using the SOF interrupt for timing
(still
> handle the other ints, but only on a SOF).
Could you please elaborate on what you mean by better
results here.
Olav
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
