Stephen Warren <swarren@wwwdotorg.org> writes:

> On 10/11/2015 01:46 PM, Lubomir Rintel wrote:
>> +static u32 bcm2835_cpufreq_set_clock(int cur_rate, int arm_rate)
>> +{
>> +	int ret = 0;
>> +	struct prop msg = {
>> +		.dev_id = VCMSG_ID_ARM_CLOCK,
>> +		.val = arm_rate * 1000,
>> +	};
>> +
>> +	/* send the message */
>> +	ret = rpi_firmware_property(fw, VCMSG_SET_CLOCK_RATE, &msg,
>> +							sizeof(msg));
>
> Why does this driver call the firmware directly, rather than using the
> clock API?

The firmware's running a thread, watching our temperature and setting
the ARM and SDRAM clock according to its policy.  This call asks the
firmware to kindly go to a higher ARM and SDRAM (note: we can't do SDRAM
From Linux) clock from the default, and it will when it feels it can.
We do expose the ARM clock from Linux, but we can only really use it
informatively with the current firmware.

I may not like this architecture, the option we have available for now.