On Mon, 31 Dec 2018 09:23:01 +0200 Tero Kristo <t-kristo@xxxxxx> wrote: > On 28/12/2018 22:02, Tony Lindgren wrote: > > * Andreas Kemnade <andreas@xxxxxxxxxxxx> [181227 20:13]: > >> Hi, > >> > >> On Tue, 4 Dec 2018 08:45:57 -0800 > >> Tony Lindgren <tony@xxxxxxxxxxx> wrote: > >> > >>> * Andreas Kemnade <andreas@xxxxxxxxxxxx> [181204 06:17]: > >>>> On Mon, 3 Dec 2018 07:39:10 -0800 > >>>> Tony Lindgren <tony@xxxxxxxxxxx> wrote: > >>>>> The consumer device stays active just fine with PM runtime > >>>>> calls. So yes, the problem is keeping a clock controller forced > >>>>> active for the period of consumer device reset. Other than > >>>>> that typically autoidle can be just kept enabled. > >>>>> > >>>> Are we still talking about the same problem? Maybe I am losing track > >>>> here. Just to make sure. > >>>> The patch series was about disabling autoidle for devices which cannot > >>>> work with it during normal operation. Not during reset or something > >>>> like that. > >>>> Or is the keep-clock-active-during-reset just a requirement for bigger > >>>> restructuring ideas? > >>> > >>> Yeah there are two issues: The fix needed for the issue you brought up, > >>> and also how to let a reset driver to block autoidle for reset. > >>> > >> Hmm, is this set now waiting for the famous "somebody" fixing all > >> the stuff? > > > > Well I think we're still waiting on Tero to comment on this. > > The only item requiring immediate fixing is the point Stephen made out, > removing the usage of CLK_IS_BASIC from this patch. > > Afaics, the reset related concerns Tony has can be handled later. > hmm, and there we need Stephen's opinion about having the allow/deny autoidle functions in the main clk_ops struct. Regards, Andreas
Attachment:
pgpRpcaJBh168.pgp
Description: OpenPGP digital signature
