[RFT] Re: [Patch] [bug #26237] multiple problems with usb devices

[Vladimir 'φ-coder/phcoder' Serbinenko]

Aleš Nesrsta wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>   
>>> Hello, Aleš. I've seen that your assignment was completed. I added you
>>> to grub contributors. Feel free to create a branch in branches/usb.
>>> Right now I'm busy but next week I should be able to assist. Perhaps
>>> even this week. Right now I send uncommitted changes sitting in my
>>> yeeloongfw branch. It's largely your rebased changes + few other things
>>> like shutting the controller down before booting OS to avoid memory used
>>> by OS to be clobbered by e.g. HCCA.
>>>       
>
> Yes, thanks, I was also sometimes thinking what happens when ohci module
> is unloaded or OS booting started, but I never had time to check it, I
> have little bit another priorities...
>
>   
I discovered it the hard way.
>>> Branch usb should contain pci improvements + your usb changes. If you
>>> have trouble with bzr or are short on time me (or perhaps someone else)
>>> can give a hand.
>>> This branch can go into mainline. Since mainline usb is in deplorable
>>> state there is no need to pass this changes through experimental at all.
>>> Merging into mainline doesn't mean that no further developpement should
>>> be done on usb, just that this part is already a huge improvement.
>>>
>>>   
>>>       
>> I've created a branch "usb" where I put all the yeeloong work and
>> previous version of your patch. Could you merge your latest patch into
>> it and test the whole on your systems?
>>     
>
> Ufff, I will try to do it but I am also busy probably whole this week
> and maybe I will need a help with bzr, I will see... So don't expect it
> soon.
>   
I've merged your latest patch into usb branch too, fixing some problems
it would have on yeeloong. Compile tested only.
Can someone give it a good test? If it works on both yeeloong and pc,
I'll merge it into mainline ASAP.
>>>   
>>>       
>>>> 3.
>>>> There is not working USB hub support, GRUB does not see device connected
>>>> via USB hub - does anybody know some details or have some specification
>>>> of USB Hub class ? I cannot find it on USB site (maybe I have not
>>>> sufficient patience...).
>>>>
>>>>
>>>> I will probably focus in OHCI speed-up now, i.e. I try to do some other
>>>> handling of ED to prevent changes in OHCI registers which are slowing
>>>> down OHCI performance (OHCI is approx. 3 times slower than UHCI now from
>>>> this reason).
>>>>   
>>>>     
>>>>         
>>> How useful would the interrupts be for this matter? If the answer is
>>> "very useful" I can implement them. Also we need some restructuring of
>>> code of both ohci and grub in general to decrease the wait time. I think
>>> specifically all the waits in init sequence. If system has 2 OHCI
>>> controllers currently you need to wait twice as long as with 1
>>> controllers while it's possible to init them in parallel and not wait
>>> longer than in the case of one controller.
>>>       
>
> I think interrupt is not important in this case, don't hurry. Why:
> A.
> Wait in initialization phase is not so critical from my point of view -
> it happens only once when ohci module is loaded - for example compare it
> with the time consumed by some BIOS starts...
> But nothing against such improving, it can be done when interrupts will
> be available.
>
>   
In the case of yeeloong this results in twice bigger time from power on
to console. On yeeloong we don't have to wait through BIOS and booting
time is an important goal. This slowdown is annoying because it happens
even if user boots from internal disk
> B.
> The main problem is changing of Control or Bulk Head registers on begin
> and end of each transfer because for each transfer we have another
> allocated memory for ED and after transfer we de-allocate it. It was one
> of thing which little bit surprised me when I first read OHCI
> specification and then I saw GRUB source code - it is different than
> ED/TD handling suggested in OHCI specification.
> Registry change and ED de-allocation have to be done on really disabled
> and inactive ED - and such situation is only after SOF (when related
> list is disabled before, of course).
> Such waiting can be avoided if EDs memory will not change - we can
> allocate necessary EDs only once when device is detected and
> enumerated / configured and do all necessary work only with TDs - in
> this case, if we will not change ED addresses, it is not necessary to do
> changes in OHCI registers on each transfer (with exception of "list
> filled" bit setting but it can be done asynchronously without waiting
> for SOF in this case) and all should be more faster, I hope as on UHCI.
> Also TDs have to be handled in little bit different way in this case
> because each ED must point to one valid memory address of TD structure
> even if there is no transfer and queue is empty - and this empty TD have
> to be used as "starting" (first) TD of next transfer - in fact we should
> do it in the similar way as it is described in OHCI specification in HCD
> sample.
>
>   
For this you can add a new field in "o".
> After all, GRUB2 is bootloader only, so probably nobody can expect full
> USB functionality as in Linux/Windows... :-)
>
>   
You don't know what our users sometimes ask us. In any case even what we
have now if we forget the lack of EHCI support is better than most
firmwares available including pmon. I was able to boot from SD card on
yeeloong, something I wasn't able to do before.
Anyway crap devices are low priority
> Best regards
> Ales
>
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

signature.asc
Description: OpenPGP digital signature