From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver
Date: Tue, 23 Aug 2011 10:15:08 -0700 [thread overview]
Message-ID: <87ei0chwwz.fsf@ti.com> (raw)
In-Reply-To: <4E532A28.60103@ti.com> (Rajendra Nayak's message of "Tue, 23 Aug 2011 09:48:48 +0530")
Rajendra Nayak <rnayak@ti.com> writes:
> On 8/23/2011 5:28 AM, Kevin Hilman wrote:
>> Rajendra Nayak<rnayak@ti.com> 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.
> 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.
Kevin
next prev parent reply other threads:[~2011-08-23 17:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1312979122-5896-1-git-send-email-j-keerthy@ti.com>
[not found] ` <1312979122-5896-7-git-send-email-j-keerthy@ti.com>
2011-08-10 12:46 ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Felipe Balbi
2011-08-11 9:57 ` J, KEERTHY
2011-08-11 10:36 ` Felipe Balbi
2011-08-11 13:00 ` J, KEERTHY
2011-08-11 14:12 ` Felipe Balbi
2011-08-11 14:25 ` Rajendra Nayak
2011-08-11 14:32 ` J, KEERTHY
2011-08-11 18:54 ` Felipe Balbi
2011-08-11 18:55 ` Felipe Balbi
2011-08-11 21:37 ` Roger Quadros
2011-08-12 1:02 ` J, KEERTHY
2011-08-12 3:26 ` Rajendra Nayak
2011-08-12 8:44 ` Felipe Balbi
2011-08-22 23:58 ` Kevin Hilman
2011-08-23 4:18 ` Rajendra Nayak
2011-08-23 6:42 ` J, KEERTHY
2011-08-23 17:15 ` Kevin Hilman [this message]
2011-08-24 4:07 ` Rajendra Nayak
2011-08-11 16:38 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ei0chwwz.fsf@ti.com \
--to=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).