Re: i.MX6: Increasing VPU frequency

[Jon Nettleton]

On Thu, Nov 5, 2015 at 7:43 AM, Jean-Michel Hautbois
<jean-michel.hautbois@xxxxxxxxxxxx> wrote:
>
> Le 5 nov. 2015 05:23, "Jon Nettleton" <jon.nettleton@xxxxxxxxx> a Ãcrit :
>>
>> On Wed, Nov 4, 2015 at 8:33 PM, Jean-Michel Hautbois
>> <jean-michel.hautbois@xxxxxxxxxxxx> wrote:
>> > 2015-11-04 18:04 GMT+01:00 Jon Nettleton <jon.nettleton@xxxxxxxxx>:
>> >> On Wed, Nov 4, 2015 at 5:52 PM, Jean-Michel Hautbois
>> >> <jean-michel.hautbois@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/