From: Omar Ramirez Luna <omar.luna@linaro.org> To: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com>, Tony Lindgren <tony@atomide.com>, Russell King <linux@arm.linux.org.uk>, Kevin Hilman <khilman@ti.com>, Ohad Ben-Cohen <ohad@wizery.com>, Tomi Valkeinen <tomi.valkeinen@ti.com>, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled Date: Tue, 21 Aug 2012 12:48:16 -0500 [thread overview] Message-ID: <CALLhW=50Ro5T=u7KTObT6g7eF=835Ywj9sQ+z8kZ_+5U7U7fJA@mail.gmail.com> (raw) In-Reply-To: <50324E84.6080407@ti.com> On 20 August 2012 09:49, Benoit Cousson <b-cousson@ti.com> wrote: > On 07/16/2012 09:21 PM, Omar Ramirez Luna wrote: >> Some IP blocks might not be using/controlling more than one >> reset line, this check loosens the restriction to fully use >> hwmod framework for those drivers. >> >> E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1. >> - cpu1 might not be used and hence (with previous check) >> won't be fully enabled by hwmod code. > > You mean that you might have some case where you need to enable the > mmu_cache and cpu0 and thus deassert only the mmu/cpu0 while keeping the > cpu1 under reset? Looks like I didn't reply to this question. Yes, initially cpu1 might not be used and kept under reset. Or even the mmu can be taken out of reset and configured, and cpu0 after it, creating a small window where one is taken out and the other is under reset. > So the any_hardreset is indeed not appropriate in that case. > > In fact, since the hardreset cannot be handled at all by the hwmod fmwk, > I'm even wondering if we should take care of checking the state at all. > But as Paul stated, if was done due to the lack of understanding about > the diver usage, so maybe things will become clearer once we will have > that code available. I still think it can, in fact all the code I'm using comes from the hwmod fmwk. _deassert_reset is almost the same as _enable, I left it this way to avoid reintroducing the issues that caused reset code to be stripped out from _enable path. Regards, Omar
WARNING: multiple messages have this Message-ID (diff)
From: omar.luna@linaro.org (Omar Ramirez Luna) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/3] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled Date: Tue, 21 Aug 2012 12:48:16 -0500 [thread overview] Message-ID: <CALLhW=50Ro5T=u7KTObT6g7eF=835Ywj9sQ+z8kZ_+5U7U7fJA@mail.gmail.com> (raw) In-Reply-To: <50324E84.6080407@ti.com> On 20 August 2012 09:49, Benoit Cousson <b-cousson@ti.com> wrote: > On 07/16/2012 09:21 PM, Omar Ramirez Luna wrote: >> Some IP blocks might not be using/controlling more than one >> reset line, this check loosens the restriction to fully use >> hwmod framework for those drivers. >> >> E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1. >> - cpu1 might not be used and hence (with previous check) >> won't be fully enabled by hwmod code. > > You mean that you might have some case where you need to enable the > mmu_cache and cpu0 and thus deassert only the mmu/cpu0 while keeping the > cpu1 under reset? Looks like I didn't reply to this question. Yes, initially cpu1 might not be used and kept under reset. Or even the mmu can be taken out of reset and configured, and cpu0 after it, creating a small window where one is taken out and the other is under reset. > So the any_hardreset is indeed not appropriate in that case. > > In fact, since the hardreset cannot be handled at all by the hwmod fmwk, > I'm even wondering if we should take care of checking the state at all. > But as Paul stated, if was done due to the lack of understanding about > the diver usage, so maybe things will become clearer once we will have > that code available. I still think it can, in fact all the code I'm using comes from the hwmod fmwk. _deassert_reset is almost the same as _enable, I left it this way to avoid reintroducing the issues that caused reset code to be stripped out from _enable path. Regards, Omar
next prev parent reply other threads:[~2012-08-21 17:48 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-16 19:21 [PATCH 0/3] OMAP: hwmod: reset API proposal Omar Ramirez Luna 2012-07-16 19:21 ` Omar Ramirez Luna 2012-07-16 19:21 ` [PATCH 1/3] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled Omar Ramirez Luna 2012-07-16 19:21 ` Omar Ramirez Luna 2012-08-20 14:49 ` Benoit Cousson 2012-08-20 14:49 ` Benoit Cousson 2012-08-20 14:49 ` Benoit Cousson 2012-08-21 1:13 ` Omar Ramirez Luna 2012-08-21 1:13 ` Omar Ramirez Luna 2012-08-21 17:48 ` Omar Ramirez Luna [this message] 2012-08-21 17:48 ` Omar Ramirez Luna 2012-07-16 19:21 ` [PATCH 2/3] ARM: OMAP: hwmod: revise deassert sequence Omar Ramirez Luna 2012-07-16 19:21 ` Omar Ramirez Luna 2012-08-02 7:52 ` Paul Walmsley 2012-08-02 7:52 ` Paul Walmsley 2012-08-02 22:20 ` Omar Ramirez Luna 2012-08-02 22:20 ` Omar Ramirez Luna 2012-08-03 5:24 ` Vaibhav Hiremath 2012-08-03 5:24 ` Vaibhav Hiremath 2012-08-03 5:24 ` Vaibhav Hiremath 2012-08-03 15:52 ` Omar Ramirez Luna 2012-08-03 15:52 ` Omar Ramirez Luna 2012-08-20 10:21 ` Benoit Cousson 2012-08-20 10:21 ` Benoit Cousson 2012-08-20 10:21 ` Benoit Cousson 2012-08-21 1:15 ` Omar Ramirez Luna 2012-08-21 1:15 ` Omar Ramirez Luna 2012-07-16 19:21 ` [PATCH 3/3] ARM: OMAP: omap_device: expose hwmod assert/deassert to omap devices Omar Ramirez Luna 2012-07-16 19:21 ` Omar Ramirez Luna 2012-08-02 7:43 ` Paul Walmsley 2012-08-02 7:43 ` Paul Walmsley 2012-08-02 17:56 ` Omar Ramirez Luna 2012-08-02 17:56 ` Omar Ramirez Luna -- strict thread matches above, loose matches on Subject: below -- 2012-06-16 1:54 [PATCH 0/3] OMAP: hwmod: reset API proposal Omar Ramirez Luna 2012-06-16 1:54 ` [PATCH 1/3] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled Omar Ramirez Luna 2012-06-16 1:54 ` Omar Ramirez Luna
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='CALLhW=50Ro5T=u7KTObT6g7eF=835Ywj9sQ+z8kZ_+5U7U7fJA@mail.gmail.com' \ --to=omar.luna@linaro.org \ --cc=b-cousson@ti.com \ --cc=khilman@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=ohad@wizery.com \ --cc=paul@pwsan.com \ --cc=tomi.valkeinen@ti.com \ --cc=tony@atomide.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.