Upstream synchronization

[roma-jam]

Requirements

Keep the release/v0.17 branch in sync.

Description

Sync request. Important changes/fixes:

• feat(uvc): support format frame based
• fix(dcd_dwc2): Reset allocated_epin_count on bus reset and close all ep (merged in: fix(usbd/dcd_dwc2): Fixed epin counter assert, update buffer name for TU_LOG > 1 #41)
• fix(dcd_dwc2): Correct usage of dwc2_controller (merged in: fix(usbd/dcd_dwc2): Fixed epin counter assert, update buffer name for TU_LOG > 1 #41)
• refactor(usbd_control): Updated the buffer name for deeper debug (merged in: fix(usbd/dcd_dwc2): Fixed epin counter assert, update buffer name for TU_LOG > 1 #41)

Limitations

N/A

Breaking change

No breaking changes

Checklist

• Pull Request name has appropriate format (for example: "fix(dcd_dwc2): Resolved address selection when several phy are present")
• Optional: README.md updated
• CI passing

Related issues

No related issues

[roma-jam]

@tore-espressif @peter-marcisovsky
I have created the upstream sync PR, via a temp branch sync/upstream.
The steps:

1. Create a sync/upstream branch from current release/v0.17
2. Sync master to the upstream/master
3. Merge master to sync/upstream
4. Create a PR from sync/upstream to release/v0.17

Why I need the step 3 when I could create a PR directly from the master -> release/v0.17?
In case of the conflicts, I need somehow resolve them and I prefer to do it in the branch (which is not master and not target release/v0.17).
Note: We didn't have any conflict on this step for this PR.

As this is a first attempt to sync it, all ideas are welcome.

I will also check the history again and try to understand, what do we might need to add in the description to make it more clear.

Feel free to review and share you ideas.

[tore-espressif]

@roma-jam If I understand it correctly, this PR is step 4 'Create a PR from sync/upstream to release/v0.17'

The git history is clean, so LGTM

[tore-espressif]

Could you please check if we need this commit too hathach@d502a0c ?

We did not get any erros without it, so I'm wondering whether it is actually correct...

[roma-jam]

@tore-espressif

This is correct (to some extend). But could lead to error in a very rare scenario. Also interesting, that the ep_count has two different sources: ghwcfg2_bm.num_dev_ep by macro DWC2_EP_COUNT(_dwc2) and from the description of the dwc_controller[rhport]: ..., .ep_count = 7, .ep_in_count = 5, ...

In dfifo_alloc() and dcd_edpt_close_all() the second option is used. The first one in such calls as handle_bus_reset() and handle_ep_irq().

So, that means that we allocate all fifo correctly (with value 7), but handle bus reset and irq with value 6 (In our case). That means that we probably should miss the IRQ for the very last EP, as we iterate the EPs for one less.

Seems, that it could be confirmed with our 2xCDC example, as there we have exactly 7 EPs (EP0, and 3 EPs per CDC).

UPD: Which is EP IN (0x84). So that means that we are not able to send any data there should be an error during sending the data to the Host by using the second CDC interface.

[roma-jam]

@tore-espressif,

I will merge this PR and create another one with the upcoming upstream changes.
Anyway, there are still couple of open questions, such as:

• ep_count (PR: Upstream synchronization #45)
• tusb_teardown (PR: feature(tusb): Added tusb_teardown() #44)

So, the rest upstream changes we'll sync in the following sync PRs.

[roma-jam]

@tore-espressif
I checked it again and we have the test for both CDC interfaces:

first instance has novfs and second doesn't.

But we don't have any error, because the last EP IN (which is overall 7th) is only in the position of 4 (because we don't iterate the overall amount, but the ep_num only).
So, for our case it is 0x84 => 0x04 => 0x04 < 6. That is why it works.

Then this means, that to get this error, we need 7 EP with the same direction: OUT.