dwc_otg: fiq_split: use TTs with more granularity

Before this commit, if you did USB audio playback and fiddled with alsamixer at the same time, the control transaction for volume adjustment could block the TT for several microframes leading to the isoc OUT running out of frame time. The hub would then bump up against the EOF timer and abort the isoc OUT, leading to garbled audio.

Additionally, if a start-split for another periodic endpoint was transmitted by the host in the middle of a multi-packet isoc OUT, the hub would abort the isoc OUT and start the other periodic transaction. Further start-splits would be ignored for the isoc OUT endpoint, again with garbled audio. This was mainly as a result of the uframe scheduler committing the TT to more than two periodic transactions per frame.

Hubs have two split transaction pipelines/buffers - non-periodic and periodic. The NP buffer is not subject to the same restrictions as the periodic one - namely there is no requirement to do starts or completes in-order or with microframe-precision timing. Clobbering the port allocation allows control/bulk to be queued at the same time as periodic transactions.

In addition, the port hog is required to prevent the IRQ from scheduling start-splits for periodic endpoints in the middle of an isoc transaction.

With this change I can now semi-reliably play back 5.1 audio while winding volume up and down in alsamixer. Linux interrupt latency will still occasionally scupper multi-packet isoc OUT transactions, the higher the isoc bandwidth required then the more likely that missing a microframe of scheduling will break the data flow.

Isoc IN is still going to be limited to single-packet transactions - the FIQ currently does not have the capability of dealing with the variable numbers of split-completes required.