Quoting Evan Green (2019-02-13 15:25:26) > The phy code was using implicit sequencing between the PHY driver > and the UFS driver to implement certain hardware requirements. > Specifically, the PHY reset register in the UFS controller needs > to be deasserted before serdes start occurs in the PHY. > > Before this change, the code was doing this by utilizing the two > phy callbacks, phy_init() and phy_poweron(), as "init step 1" and > "init step 2", where the UFS driver would deassert reset between > these two steps. > > This makes it challenging to power off the regulators in suspend, > as regulators are initialized in init, not in poweron(), but only > poweroff() is called during suspend, not exit(). > > For UFS, move the actual firing up of the PHY to phy_poweron() and > phy_poweroff() callbacks, rather than init()/exit(). UFS calls > phy_poweroff() during suspend, so now all clocks and regulators for > the phy can be powered down during suspend. > > QMP is a little tricky because the PHY is also shared with PCIe and > USB3, which have their own definitions for init() and poweron(). Rename > the meaty functions to _enable() and _disable() to disentangle from the > PHY core names, and then create two different ops structures: one for > UFS and one for the other PHY types. > > In phy-qcom-ufs, remove the 'is_powered_on' and 'is_started' guards, > as the generic PHY code does the reference counting. The > 14/20nm-specific init functions get collapsed into the generic power_on() > function, with the addition of a calibrate() callback specific to 14/20nm. > > Signed-off-by: Evan Green <evgreen@xxxxxxxxxxxx> > --- Reviewed-by: Stephen Boyd <swboyd@xxxxxxxxxxxx>
