From: Tero Kristo <t-kristo@ti.com> To: "Menon, Nishanth" <nm@ti.com> Cc: linux-omap@vger.kernel.org, khilman@ti.com, paul@pwsan.com, Rajendra Nayak <rnayak@ti.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count Date: Thu, 19 Jul 2012 12:49:40 +0300 [thread overview] Message-ID: <1342691380.4672.123.camel@sokoban> (raw) In-Reply-To: <CAOMWX4dWnJSOwLVvrAfMd7a9eKE97ywR0TrS6imHFA67V5QZag@mail.gmail.com> On Thu, 2012-07-19 at 00:55 -0500, Menon, Nishanth wrote: > On Wed, Jul 18, 2012 at 4:15 AM, Tero Kristo <t-kristo@ti.com> wrote: > > > > On Tue, 2012-07-17 at 02:59 -0500, Menon, Nishanth wrote: > > > Couple of minor comments: > > > On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo <t-kristo@ti.com> wrote: > > > [...] > > > > /** > > > > + * _omap4_update_context_lost - increment hwmod context loss counter > > > > if > > > > + * hwmod context was lost, and clear hardware context loss reg > > > > + * @oh: hwmod to check for context loss > > > > + * > > > > + * If the PRCM indicates that the hwmod @oh lost context, increment > > > > + * our in-memory context loss counter, and clear the RM_*_CONTEXT > > > > + * bits. No return value. > > > > + */ > > > > +static void _omap4_update_context_lost(struct omap_hwmod *oh) > > > > +{ > > > > + u32 r; > > > > + > > > > + if (oh->prcm.omap4.context_offs == USHRT_MAX) > > > > + return; > > > would'nt it be better to return a dummy incremental counter instead of > > > returning no context loss (count = 0)? > > > > I guess you are right, this way we may have some extra context restores > > for modules which don't have context offs defined, rather than not > > restoring them at all. Only thing I can think might prevent this is if > > there are modules that never lose context but don't have context > > register? How about omap5+? > > there has been an interesting debate ongoing with HWAUTO and context > loss count handling -> since we update only on _enable, this might > actually be interesting to consider: > enable > idle > un_idle (lost context) > read counter -> no update > > Now to handle modules that never loose context - they have to be in > wakeup domain.. should we consider a flag for those? would'nt matter > o5 or not, context is still the same.. this issue could be resolved if > counter update is done even when a check is done. Yea, that would be an option. I think I'll add a flag for not losing context ever. > > > > > > > > > + > > > > + r = > > > > omap4_prminst_read_inst_reg(oh->clkdm->pwrdm.ptr->prcm_partition, > > > > + > > > > oh->clkdm->pwrdm.ptr->prcm_offs, > > > > + oh->prcm.omap4.context_offs); > > > > + > > > > + if (!r) > > > > + return; > > > > + > > > > + oh->prcm.omap4.context_lost_counter++; > > > need to be careful about counter overflow. > > > > Well, this code can't do much for that even if it overflows... the type > > for the context_lost_counter is unsigned though, maybe it should be > > expanded if you are worried...? > > it can hit 0 with overflow(no context loss). that will not be good, right? Zero doesn't mean no context loss. If counter was previous MAX_INT, if it goes to zero it is still a context loss, as the counter value differs. Drivers do check against diff in the context loss counter, and if there is one, they do restore which is the right way to handle it. No need to unnecessarily make this more complicated than it is. -Tero
WARNING: multiple messages have this Message-ID (diff)
From: t-kristo@ti.com (Tero Kristo) To: linux-arm-kernel@lists.infradead.org Subject: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count Date: Thu, 19 Jul 2012 12:49:40 +0300 [thread overview] Message-ID: <1342691380.4672.123.camel@sokoban> (raw) In-Reply-To: <CAOMWX4dWnJSOwLVvrAfMd7a9eKE97ywR0TrS6imHFA67V5QZag@mail.gmail.com> On Thu, 2012-07-19 at 00:55 -0500, Menon, Nishanth wrote: > On Wed, Jul 18, 2012 at 4:15 AM, Tero Kristo <t-kristo@ti.com> wrote: > > > > On Tue, 2012-07-17 at 02:59 -0500, Menon, Nishanth wrote: > > > Couple of minor comments: > > > On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo <t-kristo@ti.com> wrote: > > > [...] > > > > /** > > > > + * _omap4_update_context_lost - increment hwmod context loss counter > > > > if > > > > + * hwmod context was lost, and clear hardware context loss reg > > > > + * @oh: hwmod to check for context loss > > > > + * > > > > + * If the PRCM indicates that the hwmod @oh lost context, increment > > > > + * our in-memory context loss counter, and clear the RM_*_CONTEXT > > > > + * bits. No return value. > > > > + */ > > > > +static void _omap4_update_context_lost(struct omap_hwmod *oh) > > > > +{ > > > > + u32 r; > > > > + > > > > + if (oh->prcm.omap4.context_offs == USHRT_MAX) > > > > + return; > > > would'nt it be better to return a dummy incremental counter instead of > > > returning no context loss (count = 0)? > > > > I guess you are right, this way we may have some extra context restores > > for modules which don't have context offs defined, rather than not > > restoring them at all. Only thing I can think might prevent this is if > > there are modules that never lose context but don't have context > > register? How about omap5+? > > there has been an interesting debate ongoing with HWAUTO and context > loss count handling -> since we update only on _enable, this might > actually be interesting to consider: > enable > idle > un_idle (lost context) > read counter -> no update > > Now to handle modules that never loose context - they have to be in > wakeup domain.. should we consider a flag for those? would'nt matter > o5 or not, context is still the same.. this issue could be resolved if > counter update is done even when a check is done. Yea, that would be an option. I think I'll add a flag for not losing context ever. > > > > > > > > > + > > > > + r = > > > > omap4_prminst_read_inst_reg(oh->clkdm->pwrdm.ptr->prcm_partition, > > > > + > > > > oh->clkdm->pwrdm.ptr->prcm_offs, > > > > + oh->prcm.omap4.context_offs); > > > > + > > > > + if (!r) > > > > + return; > > > > + > > > > + oh->prcm.omap4.context_lost_counter++; > > > need to be careful about counter overflow. > > > > Well, this code can't do much for that even if it overflows... the type > > for the context_lost_counter is unsigned though, maybe it should be > > expanded if you are worried...? > > it can hit 0 with overflow(no context loss). that will not be good, right? Zero doesn't mean no context loss. If counter was previous MAX_INT, if it goes to zero it is still a context loss, as the counter value differs. Drivers do check against diff in the context loss counter, and if there is one, they do restore which is the right way to handle it. No need to unnecessarily make this more complicated than it is. -Tero
next prev parent reply other threads:[~2012-07-19 9:49 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-06-11 15:26 [PATCHv6 0/7] ARM: OMAP4: core retention support Tero Kristo 2012-06-11 15:26 ` Tero Kristo 2012-06-11 15:26 ` [PATCHv6 1/7] ARM: OMAP4: PM: add errata support Tero Kristo 2012-06-11 15:26 ` Tero Kristo 2012-06-11 15:26 ` [PATCHv6 2/7] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change Tero Kristo 2012-06-11 15:26 ` Tero Kristo 2012-07-18 9:17 ` Paul Walmsley 2012-07-18 9:17 ` Paul Walmsley 2012-07-18 9:51 ` Tero Kristo 2012-07-18 9:51 ` Tero Kristo 2012-07-18 9:54 ` Paul Walmsley 2012-07-18 9:54 ` Paul Walmsley 2012-06-11 15:26 ` [PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status Tero Kristo 2012-06-11 15:26 ` Tero Kristo 2012-07-17 8:11 ` Menon, Nishanth 2012-07-17 8:11 ` Menon, Nishanth 2012-07-18 9:00 ` Tero Kristo 2012-07-18 9:00 ` Tero Kristo 2012-07-18 16:23 ` Tero Kristo 2012-07-18 16:23 ` Tero Kristo 2012-07-18 17:24 ` Paul Walmsley 2012-07-18 17:24 ` Paul Walmsley 2012-07-19 9:50 ` Tero Kristo 2012-07-19 9:50 ` Tero Kristo 2012-06-11 15:26 ` [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count Tero Kristo 2012-06-11 15:26 ` Tero Kristo 2012-07-17 7:59 ` Menon, Nishanth 2012-07-17 7:59 ` Menon, Nishanth 2012-07-18 9:15 ` Tero Kristo 2012-07-18 9:15 ` Tero Kristo 2012-07-19 5:55 ` Menon, Nishanth 2012-07-19 5:55 ` Menon, Nishanth 2012-07-19 9:49 ` Tero Kristo [this message] 2012-07-19 9:49 ` Tero Kristo 2012-07-19 10:27 ` Menon, Nishanth 2012-07-19 10:27 ` Menon, Nishanth 2012-07-19 11:47 ` Tero Kristo 2012-07-19 11:47 ` Tero Kristo 2012-07-19 10:35 ` Shilimkar, Santosh 2012-07-19 10:35 ` Shilimkar, Santosh 2012-07-19 11:44 ` Tero Kristo 2012-07-19 11:44 ` Tero Kristo 2012-07-19 7:00 ` Menon, Nishanth 2012-07-19 7:00 ` Menon, Nishanth 2012-06-11 15:26 ` [PATCHv6 5/7] ARM: OMAP4: pwrdm: add support for reading prev logic and mem states Tero Kristo 2012-06-11 15:26 ` Tero Kristo 2012-06-11 15:26 ` [PATCHv6 6/7] ARM: OMAP4: suspend: Program all domains to retention Tero Kristo 2012-06-11 15:26 ` Tero Kristo 2012-06-11 15:26 ` [PATCHv6 7/7] ARM: OMAP4: PM: put all domains to OSWR during suspend Tero Kristo 2012-06-11 15:26 ` Tero Kristo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1342691380.4672.123.camel@sokoban \ --to=t-kristo@ti.com \ --cc=khilman@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=nm@ti.com \ --cc=paul@pwsan.com \ --cc=rnayak@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.