[PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB

Philipp Zabel p.zabel at pengutronix.de
Wed Sep 14 01:37:20 PDT 2016

Am Dienstag, den 13.09.2016, 17:59 -0700 schrieb Kevin Hilman:
> Martin Blumenstingl <martin.blumenstingl at googlemail.com> writes:
> > On Tue, Sep 13, 2016 at 5:28 PM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> [...]
> >>> I added Philipp and Hans to this thread - maybe they can comment on this.
> >>> To sum it up, our problem is:
> >>> - there are two separate USB PHYs on Meson GXBB
> >>> - both are sharing the same reset line (provided by the reset-meson driver)
> >>> - during initialization of the PHYs we must only call
> >>> reset_control_reset(rstc) once (if we do it for the first *and* second
> >>> PHY then the first PHY gets confused once the second PHY uses the
> >>> reset because the first PHY's state is reset as well)
> >>
> >> If you have an initially asserted reset line and you can enable the
> >> first module by deasserting the reset via reset_control_deassert (and
> >> reset_control_assert to signal when the module may be disabled again
> >> after use), shared resets are for you.
> >>
> >> If you need a reset pulse or have no direct control over the reset line,
> >> (device_reset), the reset framework currently has no solution for this.
> >> The ugly thing about reset_control_once would be that it can't re-reset
> >> modules when unloading and reloading driver modules.
> >
> > The corresponding reset driver in question is reset-meson, which only
> > implements reset (assert/deassert are not implemented). However, I
> > don't know if this is due to hardware design.
> > I think the hardware implements the latter, but maybe Neil can give
> > more information here (I currently don't have access to my board so I
> > cannot test how the hardware actually behaves).
> It's implemented that way because the hardware only supports a reset
> pulse.

Would it be possible to bring down both PHYs drivers, pull the reset
line once, and then bring the drivers back up again?


More information about the linux-amlogic mailing list