On Thu, 1 Dec 2022 at 23:57, Bjorn Andersson <andersson@xxxxxxxxxx> wrote: > > On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote: > > > > @Ulf, Akhil has a power-domain for a piece of hardware which may be > voted active by multiple different subsystems (co-processors/execution > contexts) in the system. > > As such, during the powering down sequence we don't wait for the > power-domain to turn off. But in the event of an error, the recovery > mechanism relies on waiting for the hardware to settle in a powered off > state. > > The proposal here is to use the reset framework to wait for this state > to be reached, before continuing with the recovery mechanism in the > client driver. I tried to review the series (see my other replies), but I am not sure I fully understand the consumer part. More exactly, when and who is going to pull the reset and at what point? > > Given our other discussions on quirky behavior, do you have any > input/suggestions on this? > > > Some clients like adreno gpu driver would like to ensure that its gdsc > > is collapsed at hardware during a gpu reset sequence. This is because it > > has a votable gdsc which could be ON due to a vote from another subsystem > > like tz, hyp etc or due to an internal hardware signal. To allow > > this, gpucc driver can expose an interface to the client driver using > > reset framework. Using this the client driver can trigger a polling within > > the gdsc driver. > > @Akhil, this description is fairly generic. As we've reached the state > where the hardware has settled and we return to the client, what > prevents it from being powered up again? > > Or is it simply a question of it hitting the powered-off state, not > necessarily staying there? Okay, so it's indeed the GPU driver that is going to assert/de-assert the reset at some point. Right? That seems like a reasonable approach to me, even if it's a bit unclear under what conditions that could happen. [...] Kind regards Uffe
