* Felipe Balbi <balbi@xxxxxxxxxx> [161208 11:19]:
>
> Hi,
>
> Tony Lindgren <tony@xxxxxxxxxxx> writes:
> >> Is there also some dwc3 internal clock? If we assume the usb_otg_ss
> >> module is properly enabled it could be some dwc3 internal clock not
> >> enabled?
> >>
> >> We do have a srst_udelay needed for enabling musb controller for some
> >> SoCs, I'll check if that's the case here.
> >
> > If there are no dwc3 internal clocks that may be causing the imprecise
> > external abort, then most likely we should apply the following change
> > for srst_udelay. Looks like srst_udelay value of 2 is not enough here
> > but 3 seems to do the job.
> >
> > The issue of the spurious interrupts on dwc3 probe remains though.
> >
> > Regards,
> >
> > Tony
> >
> > 8< ------------------------------------
> > --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> > @@ -1952,6 +1952,7 @@ static struct omap_hwmod omap54xx_usb_tll_hs_hwmod = {
> > static struct omap_hwmod_class_sysconfig omap54xx_usb_otg_ss_sysc = {
> > .rev_offs = 0x0000,
> > .sysc_offs = 0x0010,
> > + .srst_udelay = 3,
>
> nothing against it. Would be nice if TI could confirm this is needed and
> check if other families might also need it.
But as we currently are not using the WRAPRESET bit, the reset
function is nop except for the delay. So this just papers over
the problem with the delay. We are not really resetting anything
until WRAPRESET and probably also CORE_SW_RESET reset are used.
I'm now thinking the original $subject patch for dwc3-omap.c
is the way to go for the fix. Or possibly even writing to the
CORE_SW_RESET bit in dwc3-omap.c probe. The driver needs to be
able to initialize the hardware no matter what it's state is
in probe :)
Then later on we can add separate resets for the wrapper module
and dwc3 core. But that's way too intrusive for a fix for sure.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
