[lkml]   [2014]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 0/3] usb: chipidea: msm: Clean and fix glue layer driver
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 <> 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
> #!/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]

-- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation

 \ /
  Last update: 2014-02-20 05:41    [W:0.112 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site