[meta-freescale] Question on CPU frequency scaling on linux-fslc

[Andreas Müller]

Hi,

Have a Variscite VarSOM running linux-fslc with devicetree
imx6q-var-som-vsc.dts from meta-freescale-3rdparty. The frequencies
available on machine are: 396/792/996MHz.

Looking into linux-fslc arch/arm/boot/dts/imx6q.dtsi (this is what
imx6q-var-som-vsc.dts includes) I would expect 396/792/852/996/1200
MHz.

Any ideas where I lost frequencies (think I had similar somewhere but
cannot remember - sigh)?

Thanks in advance

Andreas
--

[Fabio Estevam]

Hi Andreas,

Post by Andreas Müller
Hi,
Have a Variscite VarSOM running linux-fslc with devicetree
imx6q-var-som-vsc.dts from meta-freescale-3rdparty. The frequencies
available on machine are: 396/792/996MHz.
Looking into linux-fslc arch/arm/boot/dts/imx6q.dtsi (this is what
imx6q-var-som-vsc.dts includes) I would expect 396/792/852/996/1200
MHz.
Any ideas where I lost frequencies (think I had similar somewhere but
cannot remember - sigh)?

The imx6 cpufreq driver reads the "speed grading" fuses in order to
determine what are the operating frequencies that will be populated,
so what you see is the normal behavior.

On a different topic: I remember you have been trying Etnaviv with
linux-fslc. One suggestion I could give you regarding performance is
to drop the CONFIG_PROVE_LOCKING=y option from imx_v6_v7_deffconfig.

Hope this helps.
--

[Andreas Müller]

Hi Fabio,

Post by Fabio Estevam

Post by Andreas Müller
Have a Variscite VarSOM running linux-fslc with devicetree
imx6q-var-som-vsc.dts from meta-freescale-3rdparty. The frequencies
available on machine are: 396/792/996MHz.
Looking into linux-fslc arch/arm/boot/dts/imx6q.dtsi (this is what
imx6q-var-som-vsc.dts includes) I would expect 396/792/852/996/1200
MHz.
Any ideas where I lost frequencies (think I had similar somewhere but
cannot remember - sigh)?

The imx6 cpufreq driver reads the "speed grading" fuses in order to
determine what are the operating frequencies that will be populated,
so what you see is the normal behavior.
On a different topic: I remember you have been trying Etnaviv with
linux-fslc. One suggestion I could give you regarding performance is
to drop the CONFIG_PROVE_LOCKING=y option from imx_v6_v7_deffconfig.
Hope this helps.

Yes definitely: It does not happen too often that I ask one question
and get two helpful answers.

* Frequency scaling: Now I know there is no issue - cross checked with
old linux-imx - behaves identical.
* CONFIG_PROVE_LOCKING: Did let the horses turn: glmark2 changes from
81 to 84 fps. This is a performance enhancement but I am not sure if
it is worth to give up CONFIG_PROVE_LOCKING for it.

While we are at entnaviv performance: Strange is that our Qml based
application seems to perform better on etnaviv. This is not exactly
what glmark suggests: For vivante blob I remember glmark values
250-260 / etnaviv results are 80+. Wonder if the closed source driver
was optimized for glmark :)

Thanks

Andreas
--