Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1262440 > unrolled thread

i.MX6: Increasing VPU frequency

Back to article view | Back to linux.kernel

Contents

  i.MX6: Increasing VPU frequency Jean-Michel Hautbois <jean-michel.hautbois@veo-labs.com> - 2015-11-04 18:00 +0100
    Re: i.MX6: Increasing VPU frequency Jon Nettleton <jon.nettleton@gmail.com> - 2015-11-04 18:30 +0100
      Re: i.MX6: Increasing VPU frequency Jean-Michel Hautbois <jean-michel.hautbois@veo-labs.com> - 2015-11-04 20:40 +0100
        Re: i.MX6: Increasing VPU frequency Jon Nettleton <jon.nettleton@gmail.com> - 2015-11-05 05:30 +0100
          Re: i.MX6: Increasing VPU frequency Jon Nettleton <jon.nettleton@gmail.com> - 2015-11-05 08:00 +0100

#1262440 — i.MX6: Increasing VPU frequency

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 ?

Another question is the IPU frequency, but I think it can run only @264MHz...

Thanks,
JM
--
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/

[toc] | [next] | [standalone]

#1262457

On Wed, Nov 4, 2015 at 5:52 PM, Jean-Michel Hautbois
<jean-michel.hautbois@veo-labs.com> 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.

-Jon
--
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/

[toc] | [prev] | [next] | [standalone]

#1262541

2015-11-04 18:04 GMT+01:00 Jon Nettleton <jon.nettleton@gmail.com>:
> On Wed, Nov 4, 2015 at 5:52 PM, Jean-Michel Hautbois
> <jean-michel.hautbois@veo-labs.com> 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 ?

Thanks,
JM
--
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/

[toc] | [prev] | [next] | [standalone]

#1262891

On Wed, Nov 4, 2015 at 8:33 PM, Jean-Michel Hautbois
<jean-michel.hautbois@veo-labs.com> wrote:
> 2015-11-04 18:04 GMT+01:00 Jon Nettleton <jon.nettleton@gmail.com>:
>> On Wed, Nov 4, 2015 at 5:52 PM, Jean-Michel Hautbois
>> <jean-michel.hautbois@veo-labs.com> 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.
--
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/

[toc] | [prev] | [next] | [standalone]

#1262960

On Thu, Nov 5, 2015 at 7:43 AM, Jean-Michel Hautbois
<jean-michel.hautbois@veo-labs.com> wrote:
>
> Le 5 nov. 2015 05:23, "Jon Nettleton" <jon.nettleton@gmail.com> a écrit :
>>
>> On Wed, Nov 4, 2015 at 8:33 PM, Jean-Michel Hautbois
>> <jean-michel.hautbois@veo-labs.com> wrote:
>> > 2015-11-04 18:04 GMT+01:00 Jon Nettleton <jon.nettleton@gmail.com>:
>> >> On Wed, Nov 4, 2015 at 5:52 PM, Jean-Michel Hautbois
>> >> <jean-michel.hautbois@veo-labs.com> 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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web