[J_E_F_F]

OK, this seems really weird

I have a RPi2 running a daily build of openelec, and used the following
arm_freq=1000
gpu_freq=333

I am using bcmstat.sh -c to view things.

After a reboot:
Arm is at 1000 until it finishes a SMB library scan (good)
Core is at 333 until it finishes a SMB library scan (good)
H264 is at 0 until it finishes a SMB library scan (good)

Once library scan is complete
Arm reduces to 600 (good)
Core reduces to 250 (good)
H264 goes up to 250 and stays there (What the heck?)

This is all sitting at the desktop, not playing anything.
I have tried watching a H264 encoded movie to see if the H264 clock would revert back to 0 after viewing stopped, it did not. The H264 Freq went between 250-333 all throughout the show, and remained at 250 after the video ended.

There is no change if I add: avoid_pwm_pll=1

Here are some screen shots.
Stock: you can see the ARM freq at 900 during a library scan after reboot. H264 remains at 0, Kodi just sitting at the desktop. (good)
After the library scan finishes, ARM reverts back to 600 and H264 remains at 0 since we are just sitting at the Kodi desktop. (good)



This is overclocked as above: arm_freq=1000, gpu_freq=333. You can see the header in the first pic, and in the 2nd pic, you can see the ARM freq at 1000 and Core at 333 during a library scan after reboot. As soon as the library scan is complete ARM and Core drop back to the minimum freqs, 600 and 250 respectively. The odd thing is that as soon as that happens, H264 enables and stays at 250 even though nothing is playing. (bad) It stays at 250 forever just sitting at the Kodi Desktop. (bad) Why is this, and can it be set to idle at its defined 0 minimum freq like it does without an overclock?

[Warez]

i think you have set core to 333 and not gpu to 333....
http://www47.zippyshare.com/v/Lyp1AiW6/file.html

test this addon and set it to preset super turbo

[popcornmix]

Yes I have seen this behaviour. It is benign. The h264 block is powered off so having the clock running doesn't really cost you anything (I believe it is < 1mA).
It would be neater to ensure the clock is disabled, but it's not a high priority thing.

[J_E_F_F]

setting is exactly:

gpu_freq=333

[J_E_F_F]

OK, getting stranger. Tried my other RPi2, and similar but different results.
It still sticks at 250mhz when it should be 0, but in addition to that, where the first Pi H264 clock is ZERO during a library scan, this Pi clocks H264 to 333mhz during the library scan. What the heck?

[J_E_F_F]

They were both on different Millhouse builds. The first I posted was 7/18 build, and the 2nd was on 7/14

I have just updated both to 7/23 builds and they exhibit the same behavior now.

They now both spin up the H264 core to 333mhz upon boot up and remain at 333 until the library scan is complete and settle out at 250mhz They should settle out at ZERO after that, not 250 after the library scan completes, ideally, they remain at ZERO during the library scan, not like they are decoding H264 at that point.

[J_E_F_F]

It has been 8+ months, is there any progress on this? The behavior still exists in the latest nightly builds.
It it still benign with all the changes that have been made over time?

[popcornmix]

It has been 8+ months, is there any progress on this? The behavior still exists in the latest nightly builds.
It it still benign with all the changes that have been made over time?

Yes it is benign. The h264 is powered off when not in use, so the clock frequency reported makes no real difference.