On Tue, Jan 30, 2024 at 05:00:28PM -0600, Bjorn Andersson wrote: > On Mon, Jan 22, 2024 at 10:47:03AM +0200, Abel Vesa wrote: > > From: Jagadeesh Kona <quic_jkona@xxxxxxxxxxx> > > > > Add support for set and get hwmode callbacks to switch the GDSC between > > SW and HW modes. Currently, the GDSC is moved to HW control mode > > using HW_CTRL flag and if this flag is present, GDSC is moved to HW > > mode as part of GDSC enable itself. The intention is to keep the > > HW_CTRL flag functionality as is, since many older chipsets still use > > this flag. > > > > This provides insight into why we end up with both HW_CTRL and > HW_CTRL_TRIGGER. This doesn't describe why this change is needed, but > rather just an implementation detail. > > > But consumer drivers also require the GDSC mode to be switched dynamically > > at runtime based on requirement for certain usecases. Some of these > > usecases are switching the GDSC to SW mode to keep it ON during the > > enablement of clocks that are dependent on GDSC and while programming > > certain configurations that require GDSC to be ON. Introduce a new > > HW_CTRL_TRIGGER flag to register the set_hwmode_dev and get_hwmode_dev > > callbacks which allows the consumer drivers to switch the GDSC back and > > forth between HW/SW modes dynamically at runtime using new > > dev_pm_genpd_set_hwmode API. > > > > This still expresses the need for HW_CTRL_TRIGGER in terms of "some > drivers need for some use case". We don't need these many words to say: > "Introduce HW_CTRL_TRIGGER for client drivers that need it." > > > I find that it would be useful to document that every time a GDSC is > turned on the mode will be switched to SW... > I believe I'm wrong here. Reading the patch again, I think we might retain the mode across a disable/enable cycle. I at least don't see anything explicit returning us to SW mode. According to Linux though, the GDSC is off, so as described below, there will be no votes for supplying resources. Regards, Bjorn
