boards: nuvoton: numaker_m2l31ki: disable usb vbus detect#107657
boards: nuvoton: numaker_m2l31ki: disable usb vbus detect#107657ccli8 wants to merge 2 commits intozephyrproject-rtos:mainfrom
Conversation
zephyrbot
added
platform: Nuvoton Numicro Numaker
zephyrbot
requested review from
JarmouniA,
cyliangtw,
jfischer-no,
josuah,
ssekar15 and
tmon-nordic
|
|
||
| disable-vbus-detect: | ||
| type: boolean | ||
| description: | | ||
| All USB controllers support VBUS detect function, except some targets may | ||
| need extra USB-C control for the function to get enabled. For these targets, | ||
| if USB-C control is not added, disable the function. |
There was a problem hiding this comment.
This makes the function configurable so that user can disable it for these targets
if USB-C control is not added.
I am not sure what does it mean. Do you want to disable it when there is a USB PPC?
Yet another DT property does not seems to be right way to handle it. User application does not have to use usbd_can_detect_vbus(). Also, there is no need to mix USB device support with whatever is needed to be done for the PPC part.
There was a problem hiding this comment.
I am not sure what does it mean. Do you want to disable it when there is a USB PPC?
I try to rephrase the description to make it clear. Yes, the target e.g. numaker_m2l31ki integrates USB-C circuitry. VBUS detect function becomes unsupported without extra USB-C control code.
Yet another DT property does not seems to be right way to handle it. User application does not have to use usbd_can_detect_vbus()
I think user application needs to check usbd_can_detect_vbus for VBUS detect function; otherwise, it will fail on targets without this support.
Also, there is no need to mix USB device support with whatever is needed to be done for the PPC part.
That is also what I want. But with USB-C circuitry integration, VBUS detect logic scatters among UDC HAL (udc_numaker.c) and USB-C control. In this case, just mark VBUS detect unsupported can make UDC HAL code clear.
There was a problem hiding this comment.
I try to rephrase the description to make it clear. Yes, the target e.g. numaker_m2l31ki integrates USB-C circuitry. VBUS detect function becomes unsupported without extra USB-C control code.
What does FLDET bit do? Is it effectively not usable on numaker_m2l31ki? Is the USB-C circuitry a separate component on the board?
This sounds like yet another use case for #103840
There was a problem hiding this comment.
I think user application needs to check usbd_can_detect_vbus for VBUS detect function; otherwise, it will fail on targets without this support
That is not true, we have samples in the tree that do not use usbd_can_detect_vbus().
Also, there is no need to mix USB device support with whatever is needed to be done for the PPC part.
That is also what I want. But with USB-C circuitry integration, VBUS detect logic scatters among UDC HAL (udc_numaker.c) and USB-C control. In this case, just mark VBUS detect unsupported can make UDC HAL code clear.
What is UDC HAL?
There was a problem hiding this comment.
What does FLDET bit do? Is it effectively not usable on numaker_m2l31ki? Is the USB-C circuitry a separate component on the board?
Without USB-C circuitry integration, FLDET is just for VBUS detect with PA12 wired as VBUS detect pin for USBD. However, after integration with USB-C circuitry, PA12 is no longer wired as VBUS detect pin for USBD and FLDET gets to not work. Instead, UTCPD (another hardware IP for USB-C) will take over VBUS detect.
This sounds like yet another use case for #103840
#103840 has one related point: abstract VBUS detect function to one separate driver. For numaker_m2l31ki board to enable VBUS detect, it needs another implementation of VBUS detect driver using above UTCPD.
There was a problem hiding this comment.
That is not true, we have samples in the tree that do not use usbd_can_detect_vbus().
For samples/tests that don't rely on VBUS detect events (USBD_MSG_VBUS_READY/USBD_MSG_VBUS_REMOVED), they needn't invoke usbd_can_detect_vbus(). Per scan of zephyr/samples and zephyr/tests, these samples/tests meet the point.
What is UDC HAL?
Oh I mean drivers under zephyr/drivers/usb/udc.
There was a problem hiding this comment.
Without USB-C circuitry integration,
FLDETis just for VBUS detect withPA12wired as VBUS detect pin for USBD. However, after integration with USB-C circuitry,PA12is no longer wired as VBUS detect pin for USBD andFLDETgets to not work. Instead, UTCPD (another hardware IP for USB-C) will take over VBUS detect.
Are both USBD and UTCPD peripherals on the same SoC? And is it that the PCB layout determines which peripheral will be used to detect VBUS?
There was a problem hiding this comment.
Yes, your understandings are correct. Without adding UTCPD code for VBUS detect, disable VBUS detect can be most concise approach to make samples relying on usbd_can_detect_vbus work.
All USB controllers support VBUS detect function, except some targets may integrate USB-C circuitry and need extra USB-C control for the function to get enabled. This makes the function configurable so that user can disable it to reflect real condition for these targets if USB-C control is not added. Signed-off-by: Chun-Chieh Li <ccli8@nuvoton.com>
This board integrates USB-C circuitry and its USB VBUS detect function needs extra USB-C control. Disable the function to reflect real condition because the needed USB-C control is not added by default. Signed-off-by: Chun-Chieh Li <ccli8@nuvoton.com>
ccli8
force-pushed
the
nvt_m2l31_fix_usb_float_detect
branch
from
3ff0038 to
14a9d8e
Compare
|
4 participants
The Nuvoton NuMaker-M2L31KI board needs extra USB-C control to enable USB VBUS detect. Some USB samples e.g.
samples/subsys/usb/cdc_acmwill rely on this functionality if it is listed in the USB capability list. Make this functionality configurable and disable it for the NuMaker-M2L31KI board to be consistent with real condition.