Ben,
Here is a little more analysis on the OHCI bug. Here is
the flow of events when the first packet is sent to a new
control or bulk endpoint before Aki's fix:
1) A new OHCI endpoint descriptor is created and initialized
by calling ep_add_ed() at the front of sohci_submit_urb().
The TailP and HeadP transfer descriptor list pointers are
set to the same dummy transfer descriptor which marks the
list as empty. The NextED pointer is not initialized.
2) The transfer descriptor(s) are allocated in sohci_submit_urb().
3) The transfer descriptor(s) are filled and linked together
by calling td_submit_urb() from sohci_submit_urb(). For
bulk and control transfers, td_submit_urb() also activates
the corresponding list by writing to the OHCI controllers
HcCommandStatus register.
4) The new endpoint descriptor is added to the OHCI controller's
control or bulk endpoint descriptor list by calling el_link
at the end of sohci_submit_urb(). This involves setting
NextED to 0 and either adding to the existing list or if
this is the first endpoint, then writing the endpoint
descriptor address to the OHCI controller's HcControlHeadED
or HcBulkHeadED register.
The problem is that the new endpoint descriptor is not on the
OHCI controller's control or bulk list when that list is
started. The contents of the HcControlHeadED and HcBulkHeadED
registers are 0 between steps 3 and 4 above and apparently
the Lucent and NEC controllers try to access the list at this
address and generate an error but the OPTi and other controllers
either do not access address 0 or do not report an error.
Aki's fix is to switch steps 3 and 4 above so that the
HcControlHeadED or HcBulkHeadED registers get initialized with
the address of a valid endpoint descriptor before the
corresponding list is started. This is the right thing to
do!
Bob
Benjamin Herrenschmidt wrote:
>
> On Thu, Mar 23, 2000, Bob Cutler <[EMAIL PROTECTED]> wrote:
>
> >> which if I understood signals that HC is free to do its stuff by writing
> >> appropriate bits in the cmdStatus register. Then however there is this
> >> code
>
> My understanding of the Compaq OHCI spec was that if TDs and EDs are
> manipulated correctly (correctly means like it's explained in the spec),
> there's no problem doing that when the controller is active. well, we may
> have some problems in the code that links/unlinks TDs. Since we are
> working on RAM, we are not sure that the CPU respect ordering of write
> operations and this may cause problems we are encountering.
>
> I tried playing with memory barriers in the previous code, but it didn't
> help. So I beleive something else is wrong. If you fix actually works,
> then at least we know where the problem is. I beleive there would still
> be a hole if the EP is already linked while reaching td_sumit_urb().
>
> Ben.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
