Clarification of overcurrent config via device tree ("atmel,oc-gpio)

This forum is for users of Microchip MPUs and who are interested in using Linux OS.

Moderator: nferre

havasi
Posts: 4
Joined: Tue Jun 16, 2020 7:23 pm

Clarification of overcurrent config via device tree ("atmel,oc-gpio)

Wed Feb 03, 2021 5:11 pm

Hi there,

I am debugging an USB device disconnect issue, where our current "top candidate" for the root cause is an over-current on the USB.

I have seen in `Documentation/devicetree/bindings/usb/atmel-usb.txt`:

Code: Select all

 - atmel,vbus-gpio: If present, specifies a gpio that needs to be
   activated for the bus to be powered.
 - atmel,oc-gpio: If present, specifies a gpio that needs to be
   activated for the overcurrent detection.
These descriptions were not clear for me, so in the code I could find "atmel,vbus-gpio" from `drivers/usb/gadget/udc/at91_udc.c`

Code: Select all

board->vbus_pin = of_get_named_gpio_flags(np, "atmel,vbus-gpio", 0,  &flags);
if (gpio_is_valid(udc->board.vbus_pin)) {
		retval = devm_gpio_request(dev, udc->board.vbus_pin,
					   "udc_vbus");
		if (retval) {
			DBG("request vbus pin failed\n");
			goto err_unprepare_iclk;
		}

		gpio_direction_input(udc->board.vbus_pin);
So I understood it that the specified vbus-gpio is a kind of input to enable/disable the USB bus.

But if I grep for the "atmel,oc-gpio" string in the kernel (5.4) tree, it is only present in DTS and Documentation.

So do I need to defined a gpio via "atmel,oc-gpio" and assert it so that the kernel driver detects over-current? Or is this for some totally different reasons?

Many thanks for any pointers!

P.S. I have seen in the code also that the undocumented "atmel,vbus-polled" and "atmel,pullup-gpio" :? Any info on those
blue_z
Location: USA
Posts: 2154
Joined: Thu Apr 19, 2007 10:15 pm

Re: Clarification of overcurrent config via device tree ("atmel,oc-gpio)

Thu Feb 04, 2021 3:22 am

havasi wrote: I am debugging an USB device disconnect issue ...
To be clear, do you mean a USB gadget that is/was connected to the USB host port of the target board (that uses a MIcrochip SoC)?
Or is the target board (that uses a MIcrochip SoC) connected as a USB gadget?

havasi wrote: I have seen in `Documentation/devicetree/bindings/usb/atmel-usb.txt`:
...
These descriptions were not clear for me ...
Probably because you seem to ignore the context of what you quoted.
You seem to overlook the salient fact that bindings for four (4) different modes or drivers are documented in that file, and what you quoted applies to only one of those four modes.

havasi wrote: So do I need to defined a gpio via "atmel,oc-gpio" and assert it so that the kernel driver detects over-current? Or is this for some totally different reasons?
You neglect to provide salient details such as which SoC and kernel version you are using (as well as which end of the USB).

As stated in the bindings document, the property you mention is required (only) by the OHCI host peripheral.
Older Atmel SoCs such as AT91SAM926x have only host & gadget OHCI controllers (and no high-speed capability).
More recent Atmel/Microchip SoCs have the OHCI functionality integrated into the EHCI peripherals.

The EHCI host peripheral (of most recent Atmel/Microchip SoCs) may have built-in overcurrent detection on the USB power supply.
The OHCI host peripheral (of older Atmel SoCs) requires external overcurrent-detection circuitry on the USB power supply, and its driver can utilize a GPIO input to receive that status for each port.

havasi wrote: I have seen in the code also that the undocumented "atmel,vbus-polled" and "atmel,pullup-gpio"
You seem to conflate host mode and gadget mode and the respective controllers/drivers.
Instead you need to distinguish between the two modes, and reference the appropriate driver of the controller.


Regards

Return to “LINUX”

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 6 guests