• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 425 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3352: Controlling USBx_DRVVBUS state in kernel 4.9

Guilherme Costa
Intellectual 635 points
Part Number: AM3352

Tool/software: Linux

Hi,

We have a custom board with an AM3352 and are currently migrating from kernel 3.2 to kernel 4.9. In kernel 3.2 we had a small driver responsible for controlling the USBx_DRVVBUS state, since (due to project restrictions) we don't use the kernel's Power Management functionality.

When migrating the driver to kernel 4.9, we ran into a problem because our driver issues a request_mem_region that fails because the request memory region (USB1 power control register @ 0x47401C0) is already reserved (the region is reserved in the device tree, by the usb1 device).

Given this scenario, I have 2 questions:

  1. How can I access this register to control DRVVBUS's state without using any of the kernel's PM functionality?
  2. Is there a way to access this memory region reserved by the device?

I saw some older questions regarding this issue, but I was wondering if there were any developments in the recente kernel releases.

Regards,

Guilherme

  • 0
    TI__Guru**** 167581 points
    Hi Guilherme,

    Does your driver stay out of the kernel USB stack? If so, I don't see any way to directly control DRVVBUS, unless a certain callback is implemented.

    What function is missing in the current musb driver which cause you to use your driver to control DRVVBUS?

    It is better to modify the musb driver to meet your needs, instead of using a separate driver. Once the change is in kernel upstream, you don't have to worry about effort in migrating to newer kernel versions.

    By the way, since now you are migrating to new kernel, I highly recommend to use kernel v4.14 from Processor SDK v5.2, instead of v4.9. TI will stop supporting v4.9 in next year.
  • 0 in reply to Bin Liu
    Intellectual 635 points
    Liu,

    Yes, our driver was out of the kernel stack. We simply mapped the USBx Core register and controlled the DRVVBUS pin using.

    What we are looking for is something that allows us to do something like $(echo 'off' > /sys/bus/usb2/power/vbus # This is a fictitious path, just for illustration purposes). I've been poking around the /sys/bus/usb directory for a few days now and haven't found anything to that end.

    We're holding back updating the kernel to something beyond 4.9 due to lack of support for a specific component we use, but I will report this to the higher-ups, thanks!
  • 0 in reply to Guilherme Costa
    Intellectual 635 points
    Liu,

    I found out that the musb debugfs subsystem has a functionality similar to what I need, softconnect. If debugfs is mounted, I can do a $(echo '0' > /sys/kernel/debug/musb-hdrc.1.auto/softconnect), and the VBUS voltage will be cut off. Is there an equivalent way to do this without sysfs?

    Thanks!
  • 0 in reply to Guilherme Costa
    TI__Mastermind 30506 points
    Guilherme,

    Bin is out for a few days and will reply when he returns next week. I'm sorry for the delay.
  • 0 in reply to Guilherme Costa
    TI__Guru**** 167581 points
    Hi Guilherme,

    Sorry for my late response.

    Yes, writing '0' to the softconnect entry in kernel debugfs will cut off VBUS power, it can be used to simulate usb device disconnect/re-connect.
    It is implemented in the kernel MUSB drivers and exposed in kernel debugfs, but there is no equivalent function without kernel debugfs.