dwc2/host: immediately retry IN token for bInterval=1

[maximevince]

Describe the PR

When connecting a HS device with an interrupt endpoint with bInterval = 1 (1 microframe, 125us), it was being polled only at 2 microframe interval (250us), in case of a NAK. This is because the retry was deferred to the next SOF, basically wasting a full microframe.

The fix is to re-send the IN token as soon as we get the NAK, in base bInterval = 1. In other cases, we still rely on the existing polling interval calculations in the SOF IRQ handler.

Additional context

Pre-fix situation:

Post-fix situation:
(the SOF IRQ is fired, but is not used to schedule the retry, hence no xfer_kickoff from there)

@HiFiPhile @roma-jam

[HiFiPhile]

Just did some tests and confirmed my guess, all intervals are polled one frame longer.
Please try https://github.com/HiFiPhile/tinyusb/tree/retry

[maximevince]

@HiFiPhile thanks, that makes sense!

However, if I try your branch, I get a data toggle error. (Cannot just issue a channel_xfer_start(dwc2, ch_id); on the tests I did on my side)

However, I have integrated your idea into this PR and update it. Can you check?

[HiFiPhile]

However, if I try your branch, I get a data toggle error

I didn't met it in my side, what's the error message ? channel_send_in_token() doesn't work when DMA is enabled, need some investigation.

[maximevince]

I get a HCINT_DATATOGGLE_ERR when using channel_xfer_start(), since it updates edpt->next_pid, which it shouldn't for a retry.

[maximevince]

I have also rebased on master, and should have properly merged the bitfields change.

[HiFiPhile]

I get a HCINT_DATATOGGLE_ERR when using channel_xfer_start(), since it updates edpt->next_pid, which it shouldn't for a retry.

Ah that's make sense

[hathach]

thank you for your PR. I also clean up and remove the halted_sof_schedule flags (obsolete code). since channel_xfer_in_retry() is only called when halted. Please check if the changes make sense to you

[HiFiPhile]

A small fix added in #3088