From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OJFBe-000325-38 for mharc-grub-devel@gnu.org; Mon, 31 May 2010 20:18:30 -0400 Received: from [140.186.70.92] (port=37482 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJFBb-000320-Be for grub-devel@gnu.org; Mon, 31 May 2010 20:18:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OJFBa-00010V-6Y for grub-devel@gnu.org; Mon, 31 May 2010 20:18:27 -0400 Received: from mail-ew0-f216.google.com ([209.85.219.216]:44540) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJFBZ-00010L-T9 for grub-devel@gnu.org; Mon, 31 May 2010 20:18:26 -0400 Received: by ewy8 with SMTP id 8so1087762ewy.8 for ; Mon, 31 May 2010 17:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=vVyUX+qhz5TDeBvKD7o/BTYMJM8vNeB2nlHTPubQ/XY=; b=FqdPgO/9QqNvgQYgkryJiqTftTbrzBcDLVWotmxpwn+FkYuhLyweZf2TyU9CrehUVk N9wJGtYX26qRw5ClUNethrMV4uwAAUQLC6WE+UJ+L3psK0nKm0W3i5Kl75lp8rJZD+bl dZ9xqYTMhIdXULChAoY2JMs25ZoJHRJnFSbP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=BPQcBVoo6UnCQUpjk6P7QPRTc7Hymd1o7jHTdSwf/D4Uh2gCdiioN8GNFvYgrb8Txu A5drplLavkrDe9w4YkpR+yvr/zT3OmJ4od0gJ1jJ8j0FXB2NcP+kBViwKP/qxBhLDGrT m4BXybv+Y6UriDmqJj+j1psD3JOoNTZ9wi3bg= Received: by 10.213.14.71 with SMTP id f7mr2559054eba.98.1275351504181; Mon, 31 May 2010 17:18:24 -0700 (PDT) Received: from debian.bg45.phnet (gprs17.swisscom-mobile.ch [193.247.250.17]) by mx.google.com with ESMTPS id 13sm3374591ewy.13.2010.05.31.17.18.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 May 2010 17:18:23 -0700 (PDT) Message-ID: <4C0451C4.90409@gmail.com> Date: Tue, 01 Jun 2010 02:18:12 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: The development of GNU GRUB References: <1268605383.2839.26.camel@homenes1> <4BB657BB.60801@gmail.com> <1270669741.2732.129.camel@homenes1> <4BBCED68.3080900@gmail.com> <1270762038.2730.37.camel@homenes1> <4BC892C3.3090507@gmail.com> <1271794445.4221.93.camel@pracovna> <1274485618.18038.56.camel@pracovna> <4BF86523.4090509@gmail.com> <1274610426.5231.67.camel@pracovna> <4BF93F58.3080307@gmail.com> <1274634978.6742.13.camel@pracovna> <4BF9839A.2030704@gmail.com> <1274813892.18826.36.camel@pracovna> <1275238274.6704.21.camel@pracovna> <4C02E60A.3060407@gmail.com> <4C03AA29.2020807@gmail.com> <1275342853.4170.133.camel@pracovna> In-Reply-To: <1275342853.4170.133.camel@pracovna> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig7011501165CC7A1F4748B2E8" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: [RFT] Re: [Patch] [bug #26237] multiple problems with usb devices X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 00:18:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7011501165CC7A1F4748B2E8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ale=C5=A1 Nesrsta wrote: > Vladimir '=CF=86-coder/phcoder' Serbinenko wrote: > =20 >>> Hello, Ale=C5=A1. I've seen that your assignment was completed. I add= ed 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 thin= gs >>> like shutting the controller down before booting OS to avoid memory u= sed >>> by OS to be clobbered by e.g. HCCA. >>> =20 > > Yes, thanks, I was also sometimes thinking what happens when ohci modul= e > is unloaded or OS booting started, but I never had time to check it, I > have little bit another priorities... > > =20 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 els= e) >>> 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 a= ll. >>> Merging into mainline doesn't mean that no further developpement shou= ld >>> be done on usb, just that this part is already a huge improvement. >>> >>> =20 >>> =20 >> 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? >> =20 > > 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. > =20 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. >>> =20 >>> =20 >>>> 3. >>>> There is not working USB hub support, GRUB does not see device conne= cted >>>> via USB hub - does anybody know some details or have some specificat= ion >>>> 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 ot= her >>>> handling of ED to prevent changes in OHCI registers which are slowin= g >>>> down OHCI performance (OHCI is approx. 3 times slower than UHCI now = from >>>> this reason). >>>> =20 >>>> =20 >>>> =20 >>> How useful would the interrupts be for this matter? If the answer is >>> "very useful" I can implement them. Also we need some restructuring o= f >>> code of both ohci and grub in general to decrease the wait time. I th= ink >>> 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. >>> =20 > > 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 i= t > with the time consumed by some BIOS starts... > But nothing against such improving, it can be done when interrupts will= > be available. > > =20 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 on= e > 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 d= o > 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 hav= e > to be used as "starting" (first) TD of next transfer - in fact we shoul= d > do it in the similar way as it is described in OHCI specification in HC= D > sample. > > =20 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... :-) > > =20 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 > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig7011501165CC7A1F4748B2E8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iF4EAREKAAYFAkwEUcoACgkQNak7dOguQgnd6wD/X9Jmnb/8LCoTivquTb1WpaP0 XnOxVz7YUHFfJBrrv00A/2n948ddxFGn1Q/DfK0IfkbBUuVlZRo6W+svdrTT918H =5D0P -----END PGP SIGNATURE----- --------------enig7011501165CC7A1F4748B2E8--