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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel