From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SZi8B-0001Zv-W8 for mharc-grub-devel@gnu.org; Wed, 30 May 2012 08:36:03 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SZi84-0001Xw-CW for grub-devel@gnu.org; Wed, 30 May 2012 08:36:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SZi7u-0001Bl-7N for grub-devel@gnu.org; Wed, 30 May 2012 08:35:55 -0400 Received: from mail-ey0-f169.google.com ([209.85.215.169]:58670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SZi7t-0001BO-Hl for grub-devel@gnu.org; Wed, 30 May 2012 08:35:46 -0400 Received: by eaan1 with SMTP id n1so1609181eaa.0 for ; Wed, 30 May 2012 05:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=pqWL1BQ+8sJLPPU5rw+gA/xtci9sMDBLQMi/NcGxTjU=; b=vv5ylmDf1SNKG3QNmfQuApR70EWNLJDTJM0tR2i3PT+Hgd1IkWM0/mQu9GXuu2idsZ 0ujjcoZsrwGa9mHbRKcngVlzj05seEsQE1na24EiKH4eTlZ4mgvYp+XCRUrnpzZdwq5q YDIDBC4dnR8Un2/gohMw6oafTgMZJ2L7pn8ZlEq3aAWsbhJA5zGXNzwJOoPIM24vWaqd DAdXZi1zz6wISl1H74m5WVH4jldXB4hmQxgK49Cab/8oyAzytmN6UXMaPGTz0FpMzRGB JYa/qXa6EMvcjqv5/ly7KoYFGdwqxPE4umF5biAWs7OKDJCFPKlJ0ZDd7YICZf0JcbOb y4zA== Received: by 10.14.96.142 with SMTP id r14mr6549940eef.46.1338381342714; Wed, 30 May 2012 05:35:42 -0700 (PDT) Received: from debian.x201.phnet (49-234.197-178.cust.bluewin.ch. [178.197.234.49]) by mx.google.com with ESMTPS id u7sm60167353eeb.7.2012.05.30.05.35.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 May 2012 05:35:42 -0700 (PDT) Message-ID: <4FC6141C.5040302@gmail.com> Date: Wed, 30 May 2012 14:35:40 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: EHCI driver References: <4FC491EC.8010808@weinigel.se> <1338331586.6016.156.camel@king.jenpiliny.cz> <4FC5E820.1060505@weinigel.se> <4FC60E90.2030703@weinigel.se> In-Reply-To: <4FC60E90.2030703@weinigel.se> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig05D22B7CE2442F61AA6203B1" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.215.169 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 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: Wed, 30 May 2012 12:36:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig05D22B7CE2442F61AA6203B1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > diff --git a/grub-core/bus/usb/ehci.c b/grub-core/bus/usb/ehci.c > index 0f41361..d8ecf26 100644 > --- a/grub-core/bus/usb/ehci.c > +++ b/grub-core/bus/usb/ehci.c > @@ -209,18 +209,22 @@ enum > { > GRUB_EHCI_MULT_MASK =3D (3 << 30), > GRUB_EHCI_MULT_RESERVED =3D (0 << 30), > - GRUB_EHCI_MULT_ONE =3D (0 << 30), > - GRUB_EHCI_MULT_TWO =3D (0 << 30), > - GRUB_EHCI_MULT_THREE =3D (0 << 30), > + GRUB_EHCI_MULT_ONE =3D (1 << 30), > + GRUB_EHCI_MULT_TWO =3D (2 << 30), > + GRUB_EHCI_MULT_THREE =3D (3 << 30), > GRUB_EHCI_DEVPORT_MASK =3D (0x7f << 23), > - GRUB_EHCI_HUBADDR_MASK =3D (0x7f << 16) > + GRUB_EHCI_HUBADDR_MASK =3D (0x7f << 16), > + GRUB_EHCI_CMASK_MASK =3D (0xff << 8), > + GRUB_EHCI_SMASK_MASK =3D (0xff << 0), > }; > =20 > enum > { > GRUB_EHCI_MULT_OFF =3D 30, > GRUB_EHCI_DEVPORT_OFF =3D 23, > - GRUB_EHCI_HUBADDR_OFF =3D 16 > + GRUB_EHCI_HUBADDR_OFF =3D 16, > + GRUB_EHCI_CMASK_OFF =3D 8, > + GRUB_EHCI_SMASK_OFF =3D 0, > }; > =20 > #define GRUB_EHCI_TERMINATE (1<<0) > @@ -782,6 +786,7 @@ grub_ehci_pci_iter (grub_pci_device_t dev, > /* Enable asynchronous list */ > grub_ehci_oper_write32 (e, GRUB_EHCI_COMMAND, > GRUB_EHCI_CMD_AS_ENABL > + | GRUB_EHCI_CMD_PS_ENABL > | grub_ehci_oper_read32 (e, GRUB_EHCI_COMMAND)); > =20 > /* Now should be possible to power-up and enumerate ports etc. */ > @@ -926,6 +931,12 @@ grub_ehci_setup_qh (grub_ehci_qh_t qh, grub_usb_tr= ansfer_t transfer) > & GRUB_EHCI_DEVPORT_MASK; > ep_cap |=3D (transfer->dev->hubaddr << GRUB_EHCI_HUBADDR_OFF) > & GRUB_EHCI_HUBADDR_MASK; > + if (transfer->dev->speed =3D=3D GRUB_USB_SPEED_LOW && > + transfer->type !=3D GRUB_USB_TRANSACTION_TYPE_CONTROL) > + { > + ep_cap |=3D (1<<0) << GRUB_EHCI_SMASK_OFF; > + ep_cap |=3D (7<<2) << GRUB_EHCI_CMASK_OFF; > + } Could you use enums rather than hardcoding constants? > + /* low speed interrupt transfers are linked to the periodic > + * scheudle, everything else to the asynchronous schedule */ > + if (transfer->dev->speed =3D=3D GRUB_USB_SPEED_LOW && > + transfer->type !=3D GRUB_USB_TRANSACTION_TYPE_CONTROL) > + head =3D &qh[0]; > + else > + head =3D &qh[1]; Wouldn't it be easier to have a range reserved for interrupt transfer? It's not like if we were short on QHs. > =20 > /* EHCI and AL are running. What to do? > * Try to Halt QH via de-scheduling QH. */ > - /* Find index of current QH - we need previous QH, i.e. i-1 */ > - i =3D ((int) (e->qh_virt - cdata->qh_virt)) / sizeof (struct grub_eh= ci_qh); > + /* Find index of previous QH */ > + qh_phys =3D grub_dma_virt2phys(cdata->qh_virt, e->qh_chunk); > + for (i =3D 0; i < GRUB_EHCI_N_QH; i++) > + { > + if ((e->qh_virt[i].qh_hptr & GRUB_EHCI_QHTDPTR_MASK) =3D=3D qh_p= hys) > + break; > + } This makes it iterate through uncached memory which may be very slow. > + /* If this is an interrupt transfer, we just wait for the periodic > + * schedule to advance a few times and then assume that the EHCI > + * controller has read the updated QH. */ > + if (cdata->qh_virt->ep_cap & GRUB_EHCI_SMASK_MASK) > + { > + grub_millisleep(20); Isn't there a better way than arbitrary sleep? This sleep is pretty large= =2E > + /* Wait answer with timeout */ > + maxtime =3D grub_get_time_ms () + 2; 2 ms seems to be short as a maximum timeout. There is quite some number of buggy and slow hardware around. > + while (((grub_ehci_oper_read32 (e, GRUB_EHCI_STATUS) > + & GRUB_EHCI_ST_AS_ADVANCE) =3D=3D 0) > + && (grub_get_time_ms () < maxtime)); > =20 > - /* Shut up the doorbell */ > - grub_ehci_oper_write32 (e, GRUB_EHCI_COMMAND, > - ~GRUB_EHCI_CMD_AS_ADV_D > - & grub_ehci_oper_read32 (e, GRUB_EHCI_COMMAND)); > - grub_ehci_oper_write32 (e, GRUB_EHCI_STATUS, > - GRUB_EHCI_ST_AS_ADVANCE > - | grub_ehci_oper_read32 (e, GRUB_EHCI_STATUS)); > - /* Ensure command is written */ > - grub_ehci_oper_read32 (e, GRUB_EHCI_STATUS); > + /* We do not detect the timeout because if timeout occurs, it mo= st > + * probably means something wrong with EHCI - maybe stopped etc.= */ > + Which should be reported as an error if it occurs. > =20 > + /* FIXME Putting the QH back on the list should work, but for some > + * strange reason doing that will affect other QHs on the periodic > + * list. So free the QH instead of putting it back on the list > + * which does seem to work, but I would like to know why. */ > + > +#if 0 > /* Finaly we should return QH back to the AL... */ > - e->qh_virt[i - 1].qh_hptr =3D > + e->qh_virt[i].qh_hptr =3D > grub_cpu_to_le32 (grub_dma_virt2phys > (cdata->qh_virt, e->qh_chunk)); You may link it into wrong list AFAICS (interrupt vs bulk). --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig05D22B7CE2442F61AA6203B1 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.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk/GFBwACgkQNak7dOguQgkTvgEAkRxtQ494gouzS8IholR55/i3 I96XETOYXSgmXoFjjoYA/2nrEoJo0eFn4OFkGkKC/BiZ3N2V5OaSjb5fGyvSIWEP =/f7V -----END PGP SIGNATURE----- --------------enig05D22B7CE2442F61AA6203B1--