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

[Tim Bird]

Thanks very much.  I will try out the things you mention and let you
know if I make progress.
 -- Tim


On Wed, Feb 19, 2014 at 6:58 AM, Ivan T. Ivanov <iivanov@xxxxxxxxxx> wrote:
>
> 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/
>
>



-- 
 -- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/