Re: [PATCHv2] usb: musb: Fix unbalanced platform_disable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bin,

On Tuesday 13 Sep 2016 09:14:48 Bin Liu wrote:
> On Mon, Sep 12, 2016 at 08:18:05PM -0700, Tony Lindgren wrote:
> > * Bin Liu <b-liu@xxxxxx> [160912 11:36]:
> > > On Mon, Sep 12, 2016 at 08:05:30PM +0200, Andreas Kemnade wrote:
> > > > Hmm, then the question is: Couldn't the X_musb_disable simply be
> > > > called
> > > > from X_probe if needed to be an the safe side?
> > > 
> > > In general, we try not to do so if all possible. We want to put common
> > > code in the core, not repleat them in glue layers.
> > > 
> > > In this specific case, we cannot do it. For example in dsps glue, the
> > > musb reset is done in dsps_musb_init(), so no place in dsps_probe() to
> > > call dsps_musb_disable().
> > 
> > OK yeah if we need to do something, then disabling the irq in
> > musb_core.c until we're done should be enough.
> 
> I don't think we can disable it in musb core directly. *_musb_disable()
> in glue layers disables the musb wrapper's irq, not the core's irq.
> 
> But I guess we can let *_musb_init() directly calls *_musb_disable() in
> the glue drivers right after musb reset. This would have to touch almost
> all glue drivers, but trivial change. Thoughts?

Is there any use case for starting a glue layer with interrupts enabled ? If 
not I agree that all glue layers should do so in *_musb_init(). Probably not 
by calling *_musb_disable() directly though, as that would reintroduce the 
unbalanced PHY power control problem.

> > Anyways, I tested the $subject patch also with am35x code with the
> > following patch and no issues. So I've now tested with omap3,
> > omap4, am335x, and am35x.
> 
> I don't expect your v2 breaks am35x either, as I believe its default of
> out-of-reset already disables the irq. I just don't like that SW relies
> on unguaranteed HW default state.
> 
> > There are also am35x musb device tree patches from last year by
> > Rolf Peukert <rolf.peukert@xxxxxxx>:
> > 
> > https://patchwork.kernel.org/project/linux-omap/list/?submitter=144061
> 
> Good to know this work.
> 
> > And we now have new drivers/phy/phy-da8xx-usb.c that might be the
> > same phy on am35x except with register bits moved around.
> > 
> > So maybe we'll have it working with device tree quite easily.
> > Meanwhile, we should probably apply the following patch so we
> > get things working again.
> 
> Yup.

-- 
Regards,

Laurent Pinchart

--
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



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux