Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034281AbbKEGqr (ORCPT ); Thu, 5 Nov 2015 01:46:47 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:33436 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1034221AbbKEGqk convert rfc822-to-8bit (ORCPT ); Thu, 5 Nov 2015 01:46:40 -0500 X-Greylist: delayed 49303 seconds by postgrey-1.27 at vger.kernel.org; Thu, 05 Nov 2015 01:46:40 EST MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 5 Nov 2015 07:46:38 +0100 Message-ID: Subject: Re: i.MX6: Increasing VPU frequency From: Jon Nettleton To: Jean-Michel Hautbois Cc: Fabio Estevam , linux-arm-kernel , Michael Turquette , Sascha Hauer , linux-clk@vger.kernel.org, linux-kernel , Philipp Zabel , sboyd@codeaurora.org, Shawn Guo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3397 Lines: 71 On Thu, Nov 5, 2015 at 7:43 AM, Jean-Michel Hautbois wrote: > > Le 5 nov. 2015 05:23, "Jon Nettleton" a écrit : >> >> On Wed, Nov 4, 2015 at 8:33 PM, Jean-Michel Hautbois >> wrote: >> > 2015-11-04 18:04 GMT+01:00 Jon Nettleton : >> >> On Wed, Nov 4, 2015 at 5:52 PM, Jean-Michel Hautbois >> >> wrote: >> >>> Hi ! >> >>> >> >>> I can see in FSL kernel that VPU is configurable to 352M (it defaults >> >>> at 264MHz in mainline I think). >> >>> In the TRM, it is even specified at 352MHz as a default frequency, >> >>> with a maximum of 540MHz. >> >>> >> >>> Would it be possible to allow this clock rating modification if, for >> >>> instance, we select a performance governor in cpufreq, or if a coda >> >>> encoder is started with 1080p for instance ? >> >>> If so, then how is it doable properly ? >> >> >> >> For some reason the FSL kernel configures the VPU to run at 352Mhz in >> >> a very odd way that requires limiting the min cpu-frequency to 792Mhz. >> >> It also requires clocking down a bunch of devices on pll2_pfd2_396m to >> >> 352Mhz. >> >> >> >> The simple solution to this is to instead parent the VPU to >> >> pll2_pfd0_352m which is unused. I have found by default it is stable >> >> decoding but unstable encoding at 352Mhz, most likely due to the >> >> voltage changes needed that limiting the min cpu-freq to 792Mhz >> >> provides. However everything seems to work quite reliably clocking >> >> that pfd to 327Mhz, which still gives a boost of almost 24% >> >> >> >> In my testing the performance gain in then going from 327 to 352 is >> >> minimal. Generally I think you hit AXI bus limitations rather than >> >> VPU performance. >> > >> > Interesting. >> > So you propose to add something like the following in >> > drivers/clk/imx/clk-imx6q.cdrivers/clk/imx/clk-imx6q.c : >> > imx_clk_set_rate(clk[IMX6QDL_CLK_PLL2_PFD0_352M], 327000000); >> > imx_clk_set_parent(clk[IMX6QDL_CLK_VPU_AXI_SEL], >> > clk[IMX6QDL_CLK_PLL2_PFD0_352M]); >> > >> > This should end up with a fastest VPU (in fact ~25% boost is good). >> > Is it the correct way to do it ? >> > Should it be done in coda instead ? And only when needed ? >> >> That is how I have done it. I was going to implement dvfs for the vpu >> but found that this change really added minimal power and thermal >> overhead. Without looking it up I believe I only saw a 10-20mA rise >> in power usage and virtually no thermal differences. > > OK so it could even be integrated mainline... Should it be driven by DT > maybe? > Is it OK to have VPU at 327MHz and CPU at 396MHz? > This can certainly be changed per device via device-tree. It does run fine with the cpu at 396MHz, that limitation was previously imposed due to the clock parent that was being used when the VPU was clocked to 352MHz. There have been hints in commits that higher cpu core voltage is needed, but I have not found any instability so don't believe this is the case. Obviously the more people that we can have test this change the better. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/