Hi Sergei,

On 13 July 2015 18:10, Sergei wrote:

On 07/13/2015 07:55 PM, Phil Edworthy wrote:

quoted

quoted

quoted

quoted

quoted

quoted

quoted

Instead of statically selecting the PHY connection to either the
USBHS (Function) or PCI0 (Host) IP blocks, this change allows the
dts to specifiy gpio pins for the vbus and id signals. Additional

quoted

quoted

quoted

quoted

quoted

quoted

       These GPIOs don't have anything to do with the PHY, they're

interfacing

quoted

quoted

quoted

quoted

      Perhaps that was too strong statement but nevertheless...

quoted

quoted

quoted

Looking at your MAX3355 extcon driver, I can't see how it would work on it's
own.

quoted

quoted

     I've added the 'extcon' support into the Renesas USBHS driver, so that it
should be able to sense the ID pin status.

quoted

quoted

quoted

The system needs to sense vbus in order to determine that the board
has been plugged into a USB Host.

<snip>
Ok, so in summary, the max3355 device has two ways to communicate vbus
back to a processor. You can either use the vbus signal or the status1/2 signals
connected as gpios. The status1/2 signals give HNP information for OTG and
are preferred, but depending on the board, they might not be available.

 

quoted

quoted

quoted

My intention is to make the USB PHY driver listen for extcon events instead
of directly accessing the ID and VBUS signals, but otherwise behave in the
same way it currently does.

quoted

quoted

     I'm not sure the PHY driver should be interested in that...

quoted

Then how is the PHY going to know when to switch between pci0 (host) and
hsusb (function)?

    As I said, I planted the extcon hooks directly into USBHS (merged patch)
and USB HCD code (unmerged, low quality hack).

Unless I am missing something, the problem I see with this is that it will not
dynamically switch between Host and Gadget, hence my suggestion that the
USB PHY driver be interested in the extcon events.

quoted

quoted

quoted

After reading some other threads, I also intend to set up a fixed regulator
for the MAX3355 device to setup the shutdown and vbus enable pins.  I

know

quoted

quoted

quoted

that the vbus enable should really be controlled some other way depending
on the role, but for the moment I think it's ok just to enable it always.

quoted

quoted

     It's OK only in the host mode.
     I don't think we need regulators. SHDN- is already supported by the driver
(though it only drives it high at start-up time), in fact it was the only reason
not to use gpio.

quoted

quoted

quoted

Do you think that is the correct way to progress this?

quoted

quoted

     I didn't have a clear picture how to implement the OTG support at the time
of writing the MAX3355 driver; actually, I was tasked to only support ID p[in
sensing.

quoted

Right, so the max3355 driver needs some changes to include vbus handling.
Are you working on this, or should I take it on?

    No, not working yet, I have other things on my plate still...

Ok, thanks for your comments! Hopefully I'll find the time to have a stab at this.

quoted

quoted

     Note that there's some ongoing effort now on linux-usb to support OTG
functionality.

quoted

Yes, I need to spend some time reading that list!

quoted

Thanks
Phil

WBR, Sergei

Thanks
Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html