All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@ti.com>
To: Rajendra Nayak <rnayak@ti.com>
Cc: Roger Quadros <rogerq@ti.com>,
	balbi@ti.com, "J, KEERTHY" <j-keerthy@ti.com>,
	Tony Lindgren <tony@atomide.com>,
	lm-sensors@lm-sensors.org, vishwanath.bs@ti.com,
	linux-omap@vger.kernel.org, b-cousson@ti.com,
	Russell King <linux@arm.linux.org.uk>,
	Linux ARM Kernel Mailing List
	<linux-arm-kernel@lists.infradead.org>,
	khali@linux-fr.org, guenter.roeck@ericsson.com
Subject: Re: [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver
Date: Fri, 12 Aug 2011 11:44:55 +0300	[thread overview]
Message-ID: <20110812084454.GD19467@legolas.emea.dhcp.ti.com> (raw)
In-Reply-To: <4E449D65.9000004@ti.com>

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

Hi,

On Fri, Aug 12, 2011 at 08:56:29AM +0530, Rajendra Nayak wrote:
> On 8/12/2011 3:07 AM, Roger Quadros wrote:
> >On 08/11/2011 01:55 PM, Felipe Balbi wrote:
> >>Hi,
> >>
> >>On Thu, Aug 11, 2011 at 09:54:09PM +0300, Felipe Balbi wrote:
> >>>>>you need some other way to handle this. Why do you need to manually set
> >>>>>the rate rather than having hwmod handle this for you ?
> >>>>>
> >>>>>your argument that "it's a one time setting" is not enough to have this
> >>>>>in the driver. Drivers should not care about clocks anymore, this should
> >>>>>have been done on another layer.
> >>>>
> >>>>Hwmod will have no idea on the rate required.
> >>>
> >>>does the rate need to change ? Also, I have not mentioned hwmod anytime
> >>
> >>i did mention hwmod, nevermind that part. Still I'm not sure where is
> >>the right place to handle this.
> >>
> >
> >Aren't the omap_device_pm_latency callbacks the right place to do it?
> >
> >e.g. in the following snippet from mach-omap2/temp_sensor_device.c
> >
> >+static struct omap_device_pm_latency omap_temp_sensor_latency[] = {
> >+	{
> >+	 .deactivate_func = omap_device_idle_hwmods,
> >+	 .activate_func = omap_device_enable_hwmods,
> >+	 .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> >+	}
> >+};
> >
> >instead of directly pointing activate_func to omap_device_enable_hwmods,
> >it could point to a function that sets the required clock rate and then
> >enables the hwmod.
> 
> 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. What you are suggesting would add the overhead of doing
> this every time the device is runtime enabled/idled.

if it's a one time setting, why don't you just change the clock fwk to
handle this nicely ? Maybe provide a different ->enable() function which
would already set the correct rate ?

Russell, what would be the best way here ? driver needs clock to be at a
particular rate for the device to work, but it's a one time setting and
I don't think driver should be doing clk_get() - clk_enable() -
clk_set_rate(), where should that functionality be put ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: balbi@ti.com (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver
Date: Fri, 12 Aug 2011 11:44:55 +0300	[thread overview]
Message-ID: <20110812084454.GD19467@legolas.emea.dhcp.ti.com> (raw)
In-Reply-To: <4E449D65.9000004@ti.com>

Hi,

On Fri, Aug 12, 2011 at 08:56:29AM +0530, Rajendra Nayak wrote:
> On 8/12/2011 3:07 AM, Roger Quadros wrote:
> >On 08/11/2011 01:55 PM, Felipe Balbi wrote:
> >>Hi,
> >>
> >>On Thu, Aug 11, 2011 at 09:54:09PM +0300, Felipe Balbi wrote:
> >>>>>you need some other way to handle this. Why do you need to manually set
> >>>>>the rate rather than having hwmod handle this for you ?
> >>>>>
> >>>>>your argument that "it's a one time setting" is not enough to have this
> >>>>>in the driver. Drivers should not care about clocks anymore, this should
> >>>>>have been done on another layer.
> >>>>
> >>>>Hwmod will have no idea on the rate required.
> >>>
> >>>does the rate need to change ? Also, I have not mentioned hwmod anytime
> >>
> >>i did mention hwmod, nevermind that part. Still I'm not sure where is
> >>the right place to handle this.
> >>
> >
> >Aren't the omap_device_pm_latency callbacks the right place to do it?
> >
> >e.g. in the following snippet from mach-omap2/temp_sensor_device.c
> >
> >+static struct omap_device_pm_latency omap_temp_sensor_latency[] = {
> >+	{
> >+	 .deactivate_func = omap_device_idle_hwmods,
> >+	 .activate_func = omap_device_enable_hwmods,
> >+	 .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> >+	}
> >+};
> >
> >instead of directly pointing activate_func to omap_device_enable_hwmods,
> >it could point to a function that sets the required clock rate and then
> >enables the hwmod.
> 
> 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. What you are suggesting would add the overhead of doing
> this every time the device is runtime enabled/idled.

if it's a one time setting, why don't you just change the clock fwk to
handle this nicely ? Maybe provide a different ->enable() function which
would already set the correct rate ?

Russell, what would be the best way here ? driver needs clock to be at a
particular rate for the device to work, but it's a one time setting and
I don't think driver should be doing clk_get() - clk_enable() -
clk_set_rate(), where should that functionality be put ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110812/e7038205/attachment-0001.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@ti.com>
To: Rajendra Nayak <rnayak@ti.com>
Cc: Roger Quadros <rogerq@ti.com>,
	balbi@ti.com, "J, KEERTHY" <j-keerthy@ti.com>,
	Tony Lindgren <tony@atomide.com>,
	lm-sensors@lm-sensors.org, vishwanath.bs@ti.com,
	linux-omap@vger.kernel.org, b-cousson@ti.com,
	Russell King <linux@arm.linux.org.uk>,
	Linux ARM Kernel Mailing List
	<linux-arm-kernel@lists.infradead.org>,
	khali@linux-fr.org, guenter.roeck@ericsson.com
Subject: Re: [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature
Date: Fri, 12 Aug 2011 08:44:55 +0000	[thread overview]
Message-ID: <20110812084454.GD19467@legolas.emea.dhcp.ti.com> (raw)
In-Reply-To: <4E449D65.9000004@ti.com>


[-- Attachment #1.1: Type: text/plain, Size: 2193 bytes --]

Hi,

On Fri, Aug 12, 2011 at 08:56:29AM +0530, Rajendra Nayak wrote:
> On 8/12/2011 3:07 AM, Roger Quadros wrote:
> >On 08/11/2011 01:55 PM, Felipe Balbi wrote:
> >>Hi,
> >>
> >>On Thu, Aug 11, 2011 at 09:54:09PM +0300, Felipe Balbi wrote:
> >>>>>you need some other way to handle this. Why do you need to manually set
> >>>>>the rate rather than having hwmod handle this for you ?
> >>>>>
> >>>>>your argument that "it's a one time setting" is not enough to have this
> >>>>>in the driver. Drivers should not care about clocks anymore, this should
> >>>>>have been done on another layer.
> >>>>
> >>>>Hwmod will have no idea on the rate required.
> >>>
> >>>does the rate need to change ? Also, I have not mentioned hwmod anytime
> >>
> >>i did mention hwmod, nevermind that part. Still I'm not sure where is
> >>the right place to handle this.
> >>
> >
> >Aren't the omap_device_pm_latency callbacks the right place to do it?
> >
> >e.g. in the following snippet from mach-omap2/temp_sensor_device.c
> >
> >+static struct omap_device_pm_latency omap_temp_sensor_latency[] = {
> >+	{
> >+	 .deactivate_func = omap_device_idle_hwmods,
> >+	 .activate_func = omap_device_enable_hwmods,
> >+	 .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> >+	}
> >+};
> >
> >instead of directly pointing activate_func to omap_device_enable_hwmods,
> >it could point to a function that sets the required clock rate and then
> >enables the hwmod.
> 
> 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. What you are suggesting would add the overhead of doing
> this every time the device is runtime enabled/idled.

if it's a one time setting, why don't you just change the clock fwk to
handle this nicely ? Maybe provide a different ->enable() function which
would already set the correct rate ?

Russell, what would be the best way here ? driver needs clock to be at a
particular rate for the device to work, but it's a one time setting and
I don't think driver should be doing clk_get() - clk_enable() -
clk_set_rate(), where should that functionality be put ?

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  reply	other threads:[~2011-08-12  8:45 UTC|newest]

Thread overview: 105+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-10 12:25 [RFC PATCH 0/6] OMAP4: Temperature sensor driver Keerthy
2011-08-10 12:37 ` [lm-sensors] " Keerthy
2011-08-10 12:25 ` [RFC PATCH 1/6] OMAP4: Clock: Associate clocks for OMAP temperature sensor Keerthy
2011-08-10 12:37   ` [lm-sensors] [RFC PATCH 1/6] OMAP4: Clock: Associate clocks for Keerthy
2011-08-10 12:25 ` [RFC PATCH 2/6] OMAP4: Adding the temperature sensor register set bit fields Keerthy
2011-08-10 12:37   ` [lm-sensors] [RFC PATCH 2/6] OMAP4: Adding the temperature sensor Keerthy
2011-08-10 12:25 ` [RFC PATCH 3/6] OMAP4: Hwmod: OMAP " Keerthy
2011-08-10 12:37   ` [lm-sensors] " Keerthy
2011-08-10 12:25 ` [RFC PATCH 4/6] OMAP4: Temperature sensor device support Keerthy
2011-08-10 12:37   ` [lm-sensors] [RFC PATCH 4/6] OMAP4: Temperature sensor device Keerthy
2011-08-10 12:36   ` [RFC PATCH 4/6] OMAP4: Temperature sensor device support Felipe Balbi
2011-08-10 12:36     ` [lm-sensors] [RFC PATCH 4/6] OMAP4: Temperature sensor device Felipe Balbi
2011-08-10 12:41     ` [RFC PATCH 4/6] OMAP4: Temperature sensor device support Tony Lindgren
2011-08-10 12:41       ` [lm-sensors] [RFC PATCH 4/6] OMAP4: Temperature sensor device Tony Lindgren
2011-08-10 12:48       ` [RFC PATCH 4/6] OMAP4: Temperature sensor device support Felipe Balbi
2011-08-10 12:48         ` [lm-sensors] [RFC PATCH 4/6] OMAP4: Temperature sensor device Felipe Balbi
2011-08-10 14:17         ` [RFC PATCH 4/6] OMAP4: Temperature sensor device support Cousson, Benoit
2011-08-10 14:17           ` [lm-sensors] [RFC PATCH 4/6] OMAP4: Temperature sensor device Cousson, Benoit
2011-08-10 21:37           ` [RFC PATCH 4/6] OMAP4: Temperature sensor device support Felipe Balbi
2011-08-10 21:37             ` [lm-sensors] [RFC PATCH 4/6] OMAP4: Temperature sensor device Felipe Balbi
2011-08-11  2:40     ` [RFC PATCH 4/6] OMAP4: Temperature sensor device support J, KEERTHY
2011-08-11  2:52       ` [lm-sensors] [RFC PATCH 4/6] OMAP4: Temperature sensor device J, KEERTHY
2011-08-11 10:30       ` [RFC PATCH 4/6] OMAP4: Temperature sensor device support Felipe Balbi
2011-08-11 10:30         ` [lm-sensors] [RFC PATCH 4/6] OMAP4: Temperature sensor device Felipe Balbi
2011-08-11 11:01         ` [RFC PATCH 4/6] OMAP4: Temperature sensor device support J, KEERTHY
2011-08-11 11:13           ` [lm-sensors] [RFC PATCH 4/6] OMAP4: Temperature sensor device J, KEERTHY
2011-08-11 14:05           ` [RFC PATCH 4/6] OMAP4: Temperature sensor device support Felipe Balbi
2011-08-11 14:05             ` [lm-sensors] [RFC PATCH 4/6] OMAP4: Temperature sensor device Felipe Balbi
2011-08-11 14:15             ` [RFC PATCH 4/6] OMAP4: Temperature sensor device support J, KEERTHY
2011-08-11 14:27               ` [lm-sensors] [RFC PATCH 4/6] OMAP4: Temperature sensor device J, KEERTHY
2011-08-10 12:25 ` [RFC PATCH 5/6] OMAP4460: Temperature sensor data Keerthy
2011-08-10 12:37   ` [lm-sensors] " Keerthy
2011-08-10 12:37   ` Felipe Balbi
2011-08-10 12:37     ` [lm-sensors] " Felipe Balbi
2011-08-10 15:08     ` J, KEERTHY
2011-08-10 15:20       ` [lm-sensors] " J, KEERTHY
2011-08-10 12:25 ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Keerthy
2011-08-10 12:37   ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Keerthy
2011-08-10 12:46   ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Felipe Balbi
2011-08-10 12:46     ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Felipe Balbi
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:09       ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature J, KEERTHY
2011-08-11  9:57       ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver J, KEERTHY
2011-08-11 10:36       ` Felipe Balbi
2011-08-11 10:36         ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Felipe Balbi
2011-08-11 10:36         ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Felipe Balbi
2011-08-11 13:00         ` J, KEERTHY
2011-08-11 13:12           ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature J, KEERTHY
2011-08-11 13:00           ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver J, KEERTHY
2011-08-11 14:12           ` Felipe Balbi
2011-08-11 14:12             ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Felipe Balbi
2011-08-11 14:12             ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Felipe Balbi
2011-08-11 14:25             ` Rajendra Nayak
2011-08-11 14:37               ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Rajendra Nayak
2011-08-11 14:25               ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Rajendra Nayak
2011-08-11 14:32             ` J, KEERTHY
2011-08-11 14:44               ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature J, KEERTHY
2011-08-11 14:32               ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver J, KEERTHY
2011-08-11 18:54               ` Felipe Balbi
2011-08-11 18:54                 ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Felipe Balbi
2011-08-11 18:54                 ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Felipe Balbi
2011-08-11 18:55                 ` Felipe Balbi
2011-08-11 18:55                   ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Felipe Balbi
2011-08-11 18:55                   ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Felipe Balbi
2011-08-11 21:37                   ` Roger Quadros
2011-08-11 21:37                     ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Roger Quadros
2011-08-11 21:37                     ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Roger Quadros
2011-08-12  1:02                     ` J, KEERTHY
2011-08-12  1:14                       ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature J, KEERTHY
2011-08-12  1:02                       ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver J, KEERTHY
2011-08-12  3:26                     ` Rajendra Nayak
2011-08-12  3:38                       ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Rajendra Nayak
2011-08-12  3:26                       ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Rajendra Nayak
2011-08-12  8:44                       ` Felipe Balbi [this message]
2011-08-12  8:44                         ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Felipe Balbi
2011-08-12  8:44                         ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Felipe Balbi
2011-08-22 23:58                       ` Kevin Hilman
2011-08-22 23:58                         ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Kevin Hilman
2011-08-22 23:58                         ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Kevin Hilman
2011-08-23  4:18                         ` Rajendra Nayak
2011-08-23  4:30                           ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Rajendra Nayak
2011-08-23  4:18                           ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Rajendra Nayak
2011-08-23  6:42                           ` J, KEERTHY
2011-08-23  6:54                             ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature J, KEERTHY
2011-08-23  6:42                             ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver J, KEERTHY
2011-08-23 17:15                           ` Kevin Hilman
2011-08-23 17:15                             ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Kevin Hilman
2011-08-23 17:15                             ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Kevin Hilman
2011-08-24  4:07                             ` Rajendra Nayak
2011-08-24  4:19                               ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Rajendra Nayak
2011-08-24  4:07                               ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Rajendra Nayak
2011-08-11 16:38           ` Guenter Roeck
2011-08-11 16:38             ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Guenter Roeck
2011-08-11 16:38             ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Guenter Roeck
2011-08-10 16:35   ` [lm-sensors] " R, Durgadoss
2011-08-10 16:47     ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die R, Durgadoss
2011-08-15  6:22     ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver J, KEERTHY
2011-08-15  6:34       ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature J, KEERTHY
2011-08-17 10:37       ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver J, KEERTHY
2011-08-17 10:49         ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature J, KEERTHY
2011-08-17 13:45         ` [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver Guenter Roeck
2011-08-17 13:45           ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature Guenter Roeck
2011-08-17 15:03           ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver J, KEERTHY
2011-08-17 15:15             ` [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature J, KEERTHY

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=20110812084454.GD19467@legolas.emea.dhcp.ti.com \
    --to=balbi@ti.com \
    --cc=b-cousson@ti.com \
    --cc=guenter.roeck@ericsson.com \
    --cc=j-keerthy@ti.com \
    --cc=khali@linux-fr.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=lm-sensors@lm-sensors.org \
    --cc=rnayak@ti.com \
    --cc=rogerq@ti.com \
    --cc=tony@atomide.com \
    --cc=vishwanath.bs@ti.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.