Re: [PATCH v2 0/3] usb: chipidea: msm: Clean and fix glue layer driver

Hi Tim, 

On Tue, 2014-02-18 at 22:21 -0800, Tim Bird wrote: 

Ivan,

I'm having tremendous problems getting this driver to initialize.  For
some reason, I can't get the driver to actually transition the
hardware into peripheral mode.  At first I was getting a lot of probe
deferrals, based on not finding the regulators early enough in the
boot, and I thought it was an issue with the gadget drivers loading
before the driver could complete its setup.  However, I switched
everything to loading via modules, and now have less probe deferrals,
but I still can't get the driver to activate.

My understanding for gadget drivers is that you can have only one 
of them active in particular time. When compiled in kernel you can 
chose only one of them, also you can have only one module (function)
loaded. 

  I see zero interrupts.

Right, I think that we will not see interrupts until we have
SPMI drivers which could control PMIC chip, PMIC is responsible
to do ID line detection and generate IRQ to APQ/MSM chip.

In particular the routine hw_device_state (which turns on interrupts
in the controller) is never called, because I can't get
msm_otg_start_peripheral to actually kick the hardware.

OTG state machine is not used at all. This phy-"otg" driver is 
working only in "peripheral" mode, because of missing PMIC
communication. 

The only callback which you could see to be executed is 
struct usb_otg::set_peripheral(), when you load gadget driver.


<snip>

(Would you mind sharing your config?).

Sure. Attached. 

I tried configuring the qcom,otg-control for user controlled mode
setting (via debugfs), 

Never testes this. It was there before.

My kernel is based on an internal Sony 3.13-rc6 kernel with clock and
regulator patches applied, as well as your phy-msm-usb.c patches from
November and your chipidea patches from yesterday.

You will need also 4th chipidea patch[1]. I have dropped it, because 
I will like to upstream PHY driver changes first. They are depended
anyway.

To reduce dependency to other drivers, I could recommend you to 
use Zero gadget driver. It should be enough to test USB stack, 
where APQ device will be peripheral and development workstation 
will be a host[2]. 


# cat zero.sh 
#!/bin/sh
cd /lib/modules/$(uname -r)/kernel/drivers/usb/gadget
insmod ./libcomposite.ko 
insmod ./usb_f_ss_lb.ko
insmod ./g_zero.ko

[   22.454287] [<c022afd8>] (warn_slowpath_common+0x68/0x88) from
[<c022b08c>] (warn_slowpath_fmt+0x30/0x40)
[   22.463060] [<c022b08c>] (warn_slowpath_fmt+0x30/0x40) from
[<bf005024>] (msm_otg_probe+0x24/0x904 [phy_msm_usb])
[   22.472703] [<bf005024>] (msm_otg_probe+0x24/0x904 [phy_msm_usb])

This is know non-fatal issue. I will try to see how to fix it.


Regards,
Ivan

[1] usb: chipidea: msm: Use USB PHY API to control PHY state
[2] http://www.linux-usb.org/usbtest/