[Top][All Lists]
[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
- EHCI driver, Christer Weinigel, 2012/05/29
- Re: EHCI driver, Vladimir 'φ-coder/phcoder' Serbinenko, 2012/05/30
- Re: EHCI driver,
Aleš Nesrsta <=
- Re: EHCI driver, Vladimir 'φ-coder/phcoder' Serbinenko, 2012/05/30