From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Date: Thu, 23 Oct 2014 09:53:02 +0000 Subject: Re: [PATCH v2] ARM: shmobile: Add early debugging support using SCIF(A) Message-Id: <16849819.4PUYgNsGu5@avalon> List-Id: References: <1413993263-10444-1-git-send-email-geert+renesas@glider.be> <1467605.AdUxz6EOpv@avalon> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org Hi Geert, On Thursday 23 October 2014 09:02:46 Geert Uytterhoeven wrote: > On Wed, Oct 22, 2014 at 10:59 PM, Laurent Pinchart wrote: > > On Wednesday 22 October 2014 19:34:17 Geert Uytterhoeven wrote: > >> On Wed, Oct 22, 2014 at 6:08 PM, Wolfram Sang wrote: > >> >> I'm wondering whether this can be fixed in the i2c driver? Does it > >> >> really > >> >> have to enable and disable the clock? > >> > > >> > From a power-saving PoV, this makes sense. I assume serial output works > >> > again as soon as the regular scif driver takes over? Isn't that a > >> > >> Yes it continues fine afterwards. > >> With TMU0 in DT, it's enabled again even earlier, as they share the > >> parent. > > > > Would it make sense to have a list of clocks to reference from setup code > > when DEBUG_LL is defined ? It's a bit hackish, but DEBUG_LL is hackish > > anyway. > > With setup code you mean platform or MSTP setup code? I was thinking about platform setup code, but I'm open to other options as well. > That would be an option. The clock to enable depends on the SoC and SCIF(A) > address, so it's gonna need a large table. I know. It's not an ideal solution, I agree. > >> BTW, the code in sh_mobile_i2c_init() does this: > >> /* Get clock rate after clock is enabled */ > >> clk_prepare_enable(pd->clk); > >> i2c_clk_khz = clk_get_rate(pd->clk) / 1000; > >> clk_disable_unprepare(pd->clk); > >> > >> I assume the enable/disable is no longer needed with CCF? > > > > I assume so as well. > > Is it still needed with non-CCF? This driver is shared with arch/sh/. I haven't checked. If it is, I wonder whether we could move the prepare_enable and disable_unprepare calls to inside the non-CCF clk_get_rate() implementation. -- Regards, Laurent Pinchart