From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Date: Tue, 23 Aug 2011 10:15:08 -0700 Message-ID: <87ei0chwwz.fsf@ti.com> References: <1312979122-5896-1-git-send-email-j-keerthy@ti.com> <1312979122-5896-7-git-send-email-j-keerthy@ti.com> <20110810124629.GJ12882@legolas.emea.dhcp.ti.com> <20110811103658.GG27742@legolas.emea.dhcp.ti.com> <20110811141248.GK28500@legolas.emea.dhcp.ti.com> <20110811185408.GB15970@legolas.emea.dhcp.ti.com> <20110811185558.GC15970@legolas.emea.dhcp.ti.com> <4E444B8F.9060908@ti.com> <4E449D65.9000004@ti.com> <874o19gfrr.fsf@ti.com> <4E532A28.60103@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from na3sys009aog118.obsmtp.com ([74.125.149.244]:51775 "EHLO na3sys009aog118.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755460Ab1HWRPT (ORCPT ); Tue, 23 Aug 2011 13:15:19 -0400 Received: by mail-gy0-f174.google.com with SMTP id 6so248231gya.19 for ; Tue, 23 Aug 2011 10:15:16 -0700 (PDT) In-Reply-To: <4E532A28.60103@ti.com> (Rajendra Nayak's message of "Tue, 23 Aug 2011 09:48:48 +0530") Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Rajendra Nayak Cc: Roger Quadros , balbi@ti.com, "J, KEERTHY" , Tony Lindgren , lm-sensors@lm-sensors.org, vishwanath.bs@ti.com, linux-omap@vger.kernel.org, b-cousson@ti.com, Russell King , Linux ARM Kernel Mailing List , khali@linux-fr.org, guenter.roeck@ericsson.com Rajendra Nayak writes: > On 8/23/2011 5:28 AM, Kevin Hilman wrote: >> Rajendra Nayak 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