On Wed, Sep 14, 2016 at 10:37 AM, Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> wrote: > Am Dienstag, den 13.09.2016, 17:59 -0700 schrieb Kevin Hilman: >> Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx> writes: >> >> > On Tue, Sep 13, 2016 at 5:28 PM, Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> 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? I guess that this is the rmmod case: I haven't tested it yet but that should work (even with the current code and .dts) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
