On 8/23/2011 10:45 PM, Kevin Hilman wrote:
Rajendra Nayak<rnayak@xxxxxx> writes:
On 8/23/2011 5:28 AM, Kevin Hilman wrote:
Rajendra Nayak<rnayak@xxxxxx> writes:
[...]
FWIK, its a one time requirement to set the clock rate to the
right rate the device can operate in based on what a platform
supports.
Except $SUBJECT patch hard-codes the clock rate for all platforms in the
driver.
The device has a requirement to operate in a 1Mhz to 2Mhz range.
You mean the device on OMAP4 has this requirement.
Will this requirement exist on every platform that uses any version of
this IP (or future similar IPs)? I suspect not.
I agree, the current limitation is specific to the IP rev used, and
might change for a never version of the IP.
So the driver is using a clk_round_rate() to get the closest rate
supported and sets it using a clk_set_rate().
If the clock rate is to be platform-specific, it should be done in
platform-specific code.
I am fine if this needs to be moved to platform-specific code, but I
wasn't quite sure this needs to be done in clock framework as was
suggested.
No, it should't be in clock framework. But since the frequency range is
platform-specific, it should be initialized in platform-specific code.
Having min/max parameters passed by platform data as suggested by
J. Keerthy is fine.
Probably even better is to have the driver have a default min/max rang
which can be overridden by platform_data only if needed.
This sounds better since if the same IP rev is used on other platforms
which does not change the min/max, the driver can do with the default
and that would avoid duplications of same min/max having to be passed
for multiple platforms.
Kevin
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
