dcd_da146xx: Add VBUS handling

[kasjer]

Describe the PR
DA146xx are Bluetooth devices that may be battery
powered and when not connected to USB host there
is no need for USB peripheral to be running.

This change allows to enable USB peripheral when
VBUS is present otherwise USB is down reducing
power consumption.

tud_vsub_changed() function must be called
whenever VBUS change was detected.
For bus-powered devices this function should be called
at startup since VBUS must be present while device
is working.

Two BSP were updated to reflect driver change.

Most of the driver code that touches registers is unchanged just
moved from dcd_init() to dcd_connect()

Additional context
This is fallow up of #1019
Now that NRF and DA146xx have VBUS/power handling it could
be considered to make some sort of API for this.
Both NRF and DA146xx notification functions are not even
present in header files which makes usage awkward.

[hathach]

Thank you for your PR. I agree that we need an unified API for managing vbus/power. The nrf implementation is a good candidate with an API(vbus_state) which is detected/ready/removed. These can be useful for port that does not have built-in vbus detect (required external gpio) such as esp32s2. For those vbus detection is only way to distinguish between Suspend vs Disconnection. Do you need to merge this right away, else give me a few days, I will try to review all the dcd and try to finalize the API. Or we can just merge this right away and go for an follow up pr.

[kasjer]

I prefer to merge and you can take more time to rethink it. It will not be a problem if API will slightly change later on.

I can also implement dcd_edpt_close_all() for Dialog in spare time. Do you have any scenario that this function can be tested?

[hathach]

The code looks great, I haven't tested it on the hardware, last time I have some difficulties with flashing bin to external flash or something (kind of forgot). Will do a overall test later on.

[hathach]

I prefer to merge and you can take more time to rethink it. It will not be a problem if API will slightly change later on.

Yeah, I prefer to merge this as well. Since I can be late on the API revising --> merged

I can also implement dcd_edpt_close_all() for Dialog in spare time. Do you have any scenario that this function can be tested?

The close_all() is quite similar to bus_reset(), except it does not reset control endpoints. It is used when host switching from active configuration to non-active to another configuration https://github.com/hathach/tinyusb/blob/master/src/device/usbd.c#L701

To be honest, I don't know any host driver would do that, but it is required for USB Compliance Verification (USBCV) test suite, please check out #1059 for more USBCV details . There are 2 test suite that use it:

• chapter9 : one of the test is SET_CONFIGU(1) -> 0 -> 1 basically it will try to on/off the configuration. If not close_all() is not implemented you are likely to have issue when re-openning all endpoints i.e attempt to open an already opened endpoint
• msc test suite: one of the test sequence between the error recovery test and case 1 test, the test will not clean up the current state (leaving one of endpoint as stalled and/or PID=DATA1). Then use SET_CONFIGURE(0) -> (1) as way to reset endpoints. Therefore you need to reset endpoint as well as explicitly set data toggle to DATA0 when opening an endpoint to pass.

When all the compliant test is passed, it is good indicate that most of dcd work well. I have been fixing quite some corner bug with every DCD lately to get them passed the USBCV. If you have time and want to get it passed the USBCV as well, I will be more than happy to help since I am pretty familiar with most of the test suite.