grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EHCI driver


From: Aleš Nesrsta
Subject: Re: EHCI driver
Date: Wed, 30 May 2012 19:28:36 +0200

Hi Vladimir and Chris:

Chris:
Thank You for the research, correction of my mistakes (classical
copy-paste mistake... :-) ) and the patch.
As I see, Vladimir is currently discussing Your patch to be accepted, so
I am writing only some notes below mainly for Vladimir.
 
Vladimir:
1.
> interrupt transfers have nothing to do with CPU interrupts per se. You
> can check whether PCI interrupt occurred without having to enable CPU
> interrupts.

Yes, I know, of course. I mentioned CPU interrupt only because doing
such things via CPU interrupt is/could be easier... :-)
Without interrupt You need to have some program loop which will
guarantee periodic polling with frequency higher than USB interrupt
transfer frequency - in opposite case You can loose data from some
transfers. (I think it cannot happen in GRUB bulk "emulation" of
interrupt transfer working on UHCI/OHCI - because when bulk trasfer is
used, no new transfer is started before data are overtaken from old
transfer. But interrupt transfers are initiated by *HCI periodically
independently even if program overtake data or not.)
I was not sure if such fast-enough program loop can be fulfilled in GRUB
- probably yes. Butmaybe with some exceptions - ? - e.g. during some
large file-disk operations on slow media?.

2.
>> +  /* low speed interrupt transfers are linked to the periodic
>> +   * scheudle, everything else to the asynchronous schedule */
>> +  if (transfer->dev->speed == GRUB_USB_SPEED_LOW &&
>> +      transfer->type != GRUB_USB_TRANSACTION_TYPE_CONTROL)
>> +      head = &qh[0];
>> +  else
>> +      head = &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.

It is probably not necessary - I think, really there will be "allocated"
the same total number of QHs during communication by this new algorithm
as with old algorithm.
The reason is: Now will be used more "sync. QHs" but less "async.
QHs" (because some "async. QHs" were "allocated" before to "emulate"
interrupt transfer via bulk) - so the total sum should be the same now
as before.

BR,
Ales





reply via email to

[Prev in Thread] Current Thread [Next in Thread]