On Mon, Oct 10, 2022 at 1:52 PM Ferry Toth <fntoth@xxxxxxxxx> wrote:
Hi
Op 10-10-2022 om 13:04 schreef Ferry Toth:
Hi
On 10-10-2022 07:02, Andrey Smirnov wrote:
On Fri, Oct 7, 2022 at 6:07 AM Ferry Toth <fntoth@xxxxxxxxx> wrote:
On 07-10-2022 04:11, Thinh Nguyen wrote:
On Thu, Oct 06, 2022, Ferry Toth wrote:If you would like me to test your suspicion, just tell me what to do
HiRight. Thanks for narrowing it down. There are still many steps in
On 06-10-2022 04:12, Thinh Nguyen wrote:
On Wed, Oct 05, 2022, Ferry Toth wrote:Ok. I first tried the code move suggested by Andrey (didn't work).
Hi,Ok.
Thanks!
Does the failure only happen the first time host is
initialized? Or can
it recover after switching to device then back to host mode?
I can switch back and forth and device mode works each time,
host mode remains
dead.
Probably the failure happens if some step(s) inI saw the experiment you did from the link you provided. We want
dwc3_core_init() hasn't
completed.
tusb1210 is a phy driver right? The issue is probably
because we didn't
initialize the phy yet. So, I suspect placing
dwc3_get_extcon() after
initializing the phy will probably solve the dependency
problem.
You can try something for yourself or I can provide
something to test
later if you don't mind (maybe next week if it's ok).
Yes, the code move I mentioned above "moves dwc3_get_extcon()
until after
dwc3_core_init() but just before dwc3_core_init_mode(). AFAIU
initially
dwc3_get_extcon() was called from within dwc3_core_init_mode()
but only for
case USB_DR_MODE_OTG. So with this change order of events is
more or less
unchanged" solves the issue.
to also
confirm exactly which step in dwc3_core_init() was needed.
Then
after reading the actual code I moved a bit further.
This move was on top of -rc6 without any reverts. I did not make
additional
changes to dwc3_core_init()
So current v6.0 has: dwc3_get_extcon - dwc3_get_dr_mode - ... -
dwc3_core_init - .. - dwc3_core_init_mode (not working)
I changed to: dwc3_get_dr_mode - dwc3_get_extcon - .. -
dwc3_core_init - ..
- dwc3_core_init_mode (no change)
Then to: dwc3_get_dr_mode - .. - dwc3_core_init - .. -
dwc3_get_extcon -
dwc3_core_init_mode (works)
.. are what I believe for this issue irrelevant calls to
dwc3_alloc_scratch_buffers, dwc3_check_params and dwc3_debugfs_init.
dwc3_core_init(). We have some suspicion, but we still haven't
confirmed
the exact cause of the failure. We can write a proper patch once we
know
the reason.
:-)
OK, Ferry, I think I'm going to need clarification on specifics on
your test setup. Can you share your kernel config, maybe your
"/proc/config.gz", somewhere? When you say you are running vanilla
Linux, do you mean it or do you mean vanilla tree + some patch delta?
For v6.0 I can get the exacts tonight. But earlier I had this for v5.17:
https://github.com/htot/meta-intel-edison/blob/master/meta-intel-edison-bsp/recipes-kernel/linux/linux-yocto_5.17.bb
There are 2 patches referred in #67 and #68. One is related to the
infinite loop. The other is I believe also needed to get dwc3 to work.
All the kernel config are applied as .cfg.
Patches and cfs's here:
https://github.com/htot/meta-intel-edison/tree/master/meta-intel-edison-bsp/recipes-kernel/linux/files
Updated Yocto recipe for v6.0 here:
https://github.com/htot/meta-intel-edison/blob/honister/meta-intel-edison-bsp/recipes-kernel/linux/linux-yocto_6.0.bb
#75-#77 are the 2 reverts from Andy, + one SOF revert (not related to
this thread).
Please drop all of this
https://github.com/htot/meta-intel-edison/blob/honister/meta-intel-edison-bsp/recipes-kernel/linux/linux-yocto_6.0.bb#L69-L77
and re do the testing. Assuming things are still broken, that's how
you want to do the bisecting.