problem about the boot panda images
Hi, All I want to use the panda-linaro build from here: https://android-build.linaro.org/builds/~linaro-android-member-ti/panda-linaro/#build=228 but with the sdcard create by linaro-android-media-create, I can't boot the panda board. Anyone has met the same problem? attached linaro-android-media-create.log is the output of the linaro-android-media-create Following is the output of minicom: Welcome to minicom 2.5 OPTIONS: I18n Compiled on May 2 2011, 10:05:24. Port /dev/ttyUSB0 Press CTRL-A Z for help on special keys U-Boot SPL 2013.01.-rc1 (Mar 12 2013 - 01:42:53) OMAP4460 ES1.1 OMAP SD/MMC: 0 ** Partition 1 not valid on device 0 ** spl: fat register err - -1 ### ERROR ### Please RESET the board ### U-Boot SPL 2013.01.-rc1 (Mar 12 2013 - 01:42:53) OMAP4460 ES1.1 OMAP SD/MMC: 0 ** Partition 1 not valid on device 0 ** spl: fat register err - -1 ### ERROR ### Please RESET the board ### U-Boot SPL 2013.01.-rc1 (Mar 12 2013 - 01:42:53) OMAP4460 ES1.1 OMAP SD/MMC: 0 ** Partition 1 not valid on device 0 ** spl: fat register err - -1 ### ERROR ### Please RESET the board ### U-Boot SPL 2013.01.-rc1 (Mar 12 2013 - 01:42:53) OMAP4460 ES1.1 OMAP SD/MMC: 0 ** Partition 1 not valid on device 0 ** spl: fat register err - -1 ### ERROR ### Please RESET the board ### -- Thanks, Yongqin Liu --- #mailing list linaro-andr...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android linaro-validat...@lists.linaro.org http://lists.linaro.org/pipermail/linaro-validation linaro-android-media-create.log Description: Binary data ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[no subject]
Basic patch to show thermal related info in the powertop tool. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH powertop] thermal: add window for thermal related infromation
add a window to display the stats of thermal, cooling zones and also
information given by the hwmon sensor.
Signed-off-by: Sanjay Singh Rawat
---
src/Makefile.am |2 +-
src/display.cpp |1 +
src/main.cpp|3 +-
src/measurement/thermal.cpp | 148 +++
src/measurement/thermal.h |1 +
5 files changed, 153 insertions(+), 2 deletions(-)
create mode 100644 src/measurement/thermal.cpp
create mode 100644 src/measurement/thermal.h
diff --git a/src/Makefile.am b/src/Makefile.am
index f60426a..335fb6c 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -34,7 +34,7 @@ powertop_SOURCES = parameters/persistent.cpp
parameters/learn.cpp parameters/par
report/report-formatter-base.cpp report/report-formatter-base.h
\
report/report-formatter-csv.cpp report/report-formatter-csv.h \
report/report-formatter-html.cpp report/report-formatter-html.h
\
- main.cpp css.h powertop.css cpu/intel_gpu.cpp
+ main.cpp css.h powertop.css cpu/intel_gpu.cpp
measurement/thermal.h measurement/thermal.cpp
powertop_CXXFLAGS = -fno-omit-frame-pointer -fstack-protector -Wall -Wshadow
-Wformat $(NCURSES_CFLAGS) $(PCIUTILS_CFLAGS) $(LIBNL_CFLAGS) $(GLIB2_CFLAGS)
diff --git a/src/display.cpp b/src/display.cpp
index c76ba27..adcf80d 100644
--- a/src/display.cpp
+++ b/src/display.cpp
@@ -71,6 +71,7 @@ void init_display(void)
create_tab("Idle stats", _("Idle stats"));
create_tab("Frequency stats", _("Frequency stats"));
create_tab("Device stats", _("Device stats"));
+ create_tab("Thermal stats", _("Thermal stats"));
display = 1;
}
diff --git a/src/main.cpp b/src/main.cpp
index e6036ae..e649919 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -51,7 +51,7 @@
#include "parameters/parameters.h"
#include "calibrate/calibrate.h"
-
+#include "measurement/thermal.h"
#include "tuning/tuning.h"
#include "display.h"
@@ -214,6 +214,7 @@ void one_measurement(int seconds, char *workload)
report_display_cpu_pstates();
report_process_update_display();
+ thermal_update_display();
tuning_update_display();
end_process_data();
diff --git a/src/measurement/thermal.cpp b/src/measurement/thermal.cpp
new file mode 100644
index 000..c2c4c11
--- /dev/null
+++ b/src/measurement/thermal.cpp
@@ -0,0 +1,148 @@
+/*
+ * This is part of PowerTOP
+ *
+ * This program file is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program in a file named COPYING; if not, write to the
+ * Free Software Foundation, Inc,
+ * 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301 USA
+ * or just google for it.
+ *
+ * getopt code is taken from "The GNU C Library" reference manual,
+ * section 24.2 "Parsing program options using getopt"
+ * http://www.gnu.org/s/libc/manual/html_node/Getopt-Long-Option-Example.html
+ * Manual published under the terms of the Free Documentation License.
+ */
+
+#include
+#include
+#include "../display.h"
+#include "../lib.h"
+
+enum attr_length {
+ SHORTT,
+ LONGT
+};
+
+static int get_thermal_attr(WINDOW *win, char *zone, const char *attr, int
wide)
+{
+char buf[512];
+int val;
+string line;
+
+ if(!wide)
+ wprintw(win,"%17s : ",attr);
+ else
+ wprintw(win,"%s : ",attr);
+for(val=0 ; val<255 ; val++) {
+sprintf(buf,"%s%d/%s",zone,val,attr);
+ if (access(buf, R_OK) !=0) {
+ wprintw(win," *\n");
+ return -1;
+ }
+line = read_sysfs_string("%s", buf);
+ wprintw(win," %s -",line.c_str());
+}
+wprintw(win,"\n");
+ return 0;
+}
+
+static int get_thermal_zone_info(WINDOW *win)
+{
+ char linebuf[1024];
+ string line;
+
+ sprintf(linebuf,"/sys/class/thermal/thermal_zone");
+
+ wprintw(win,"\n[Zone :
Thermal]--\n");
+ get_thermal_attr(win, linebuf, "type",SHORTT);
+ get_thermal_attr(win, linebuf, "temp",SHORTT);
+ get_thermal_attr(win, linebuf, "mode",SHORTT);
+ get_thermal_attr(win, linebuf, "policy",SHORTT);
+ get_thermal_attr(win, linebuf, "passive",SHORTT);
+ //todo: currently assuming only 3 trip points
+ get_thermal_attr(win, linebuf, "trip_point_0_temp",LONG
[RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
Add the below four notifier events so drivers which are interested in
knowing the clock status can act accordingly. This is extremely useful
in some of the DVFS (Dynamic Voltage Frequency Scaling) design.
PRE_CLK_ENABLE
POST_CLK_ENABLE
PRE_CLK_DISABLE
POST_CLK_DISABLE
Signed-off-by: Bill Huang
---
drivers/clk/clk.c | 58 +++
include/linux/clk.h | 40 ---
2 files changed, 81 insertions(+), 17 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ed87b24..720a16a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1104,6 +1104,64 @@ struct clk *clk_get_parent(struct clk *clk)
}
EXPORT_SYMBOL_GPL(clk_get_parent);
+/**
+ * clk_prepare_enable - call clk_enable in non-atomic context.
+ * @clk: the clk to enable
+ *
+ * Send PRE_CLK_ENABLE/POST_CLK_ENABLE before/after calling
+ * clk_enalbe respectively
+ *
+ * Return success (0) or errno.
+ */
+int clk_prepare_enable(struct clk *clk)
+{
+ int ret;
+
+ mutex_lock(&prepare_lock);
+ ret = __clk_prepare(clk);
+ if (ret)
+ return ret;
+
+ if (clk->notifier_count)
+ __clk_notify(clk, PRE_CLK_ENABLE, clk->rate, clk->rate);
+
+ ret = clk_enable(clk);
+ if (ret)
+ __clk_unprepare(clk);
+
+ if (clk->notifier_count)
+ __clk_notify(clk, POST_CLK_ENABLE, clk->rate, clk->rate);
+
+ mutex_unlock(&prepare_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(clk_prepare_enable);
+
+/**
+ * clk_disable_unprepare - call clk_disable in non-atomic context.
+ * @clk: the clk to enable
+ *
+ * Send PRE_CLK_DISABLE/POST_CLK_DISABLE before/after calling
+ * clk_disalbe respectively
+ */
+void clk_disable_unprepare(struct clk *clk)
+{
+ mutex_lock(&prepare_lock);
+
+ if (clk->notifier_count)
+ __clk_notify(clk, PRE_CLK_DISABLE, clk->rate, clk->rate);
+
+ clk_disable(clk);
+ __clk_unprepare(clk);
+
+ if (clk->notifier_count)
+ __clk_notify(clk, POST_CLK_DISABLE, clk->rate, clk->rate);
+
+ mutex_unlock(&prepare_lock);
+}
+EXPORT_SYMBOL_GPL(clk_disable_unprepare);
+
/*
* .get_parent is mandatory for clocks with multiple possible parents. It is
* optional for single-parent clocks. Always call .get_parent if it is
diff --git a/include/linux/clk.h b/include/linux/clk.h
index b3ac22d..4bbe1903 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -43,6 +43,10 @@ struct clk;
#define PRE_RATE_CHANGEBIT(0)
#define POST_RATE_CHANGE BIT(1)
#define ABORT_RATE_CHANGE BIT(2)
+#define PRE_CLK_ENABLE BIT(3)
+#define POST_CLK_ENABLEBIT(4)
+#define PRE_CLK_DISABLEBIT(5)
+#define POST_CLK_DISABLE BIT(6)
/**
* struct clk_notifier - associate a clk with a notifier
@@ -276,6 +280,20 @@ struct clk *clk_get_parent(struct clk *clk);
*/
struct clk *clk_get_sys(const char *dev_id, const char *con_id);
+/**
+ * clk_prepare_enable - helps cases using clk_enable in non-atomic context.
+ * @clk: clock source
+ *
+ * Return success (0) or nagative errno.
+ */
+int clk_prepare_enable(struct clk *clk);
+
+/**
+ * clk_disable_unprepare - helps cases using clk_disable in non-atomic context.
+ * @clk: clock source
+ */
+void clk_disable_unprepare(struct clk *clk);
+
#else /* !CONFIG_HAVE_CLK */
static inline struct clk *clk_get(struct device *dev, const char *id)
@@ -324,30 +342,18 @@ static inline struct clk *clk_get_parent(struct clk *clk)
return NULL;
}
-#endif
-
-/* clk_prepare_enable helps cases using clk_enable in non-atomic context. */
static inline int clk_prepare_enable(struct clk *clk)
{
- int ret;
-
- ret = clk_prepare(clk);
- if (ret)
- return ret;
- ret = clk_enable(clk);
- if (ret)
- clk_unprepare(clk);
-
- return ret;
+ return 0;
}
-/* clk_disable_unprepare helps cases using clk_disable in non-atomic context.
*/
-static inline void clk_disable_unprepare(struct clk *clk)
+static inline int clk_disable_unprepare(struct clk *clk)
{
- clk_disable(clk);
- clk_unprepare(clk);
+ return 0;
}
+#endif
+
/**
* clk_add_alias - add a new clock alias
* @alias: name for clock alias
--
1.7.9.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote: > Add the below four notifier events so drivers which are interested in > knowing the clock status can act accordingly. This is extremely useful > in some of the DVFS (Dynamic Voltage Frequency Scaling) design. > > PRE_CLK_ENABLE > POST_CLK_ENABLE > PRE_CLK_DISABLE > POST_CLK_DISABLE > > Signed-off-by: Bill Huang NAK. *Sigh* NO, this is the wrong level to be doing stuff like this. The *ONLY* thing that clk_prepare_enable() and clk_prepare_disable() should *EVER* be doing is calling clk_prepare(), clk_enable(), clk_disable() and clk_unprepare(). Those two functions are *merely* helpers for drivers who don't wish to make the individual calls. Drivers are still completely free to call the individual functions, at which point your proposal breaks horribly - and they _do_ call the individual functions. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: arm64 Debian/Ubuntu port image available
+++ Wookey [2013-02-27 02:10 +]: > State of the Debian/Ubuntu arm64 port > = > > *** Arm64 lives! *** > > Executive summary > - > > * There is now a bootable (raring) image to download and run > * A bit more work is needed to make the rootfs useable as a native buildd Networking and apt, and various bits of breakage was fixed shortly after the initial upload. After some jolly hacking at Connect, with much help from Doko, we got the build and install dependencies of debhelper (what a lot of crap it (recursively) needs!) crossed and uploaded, and fixed some missing perl bits, so I have now successfully built the 'hello' package with the image. It's such fun to watch configure scroll by one line at a time for about an hour Cross-building stuff: Ian Campbell also got the Xen arm64/aarch64 cross-build working for raring (not yet integrated into the packaging), using the info on https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/arm64bootstrap without too much aggravation (libyajl needed to be cross-fixed first), so the environment is already useful for building and getting stuff cross-ready, so long as you don't have too many build-deps. Feedback from anyone else who tries this is welcome. > The images are available for download: > http://wiki.debian.org/Arm64Port#Pre-built_Rootfs > Along with destructions there for making your own. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote: > On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote: > > Add the below four notifier events so drivers which are interested in > > knowing the clock status can act accordingly. This is extremely useful > > in some of the DVFS (Dynamic Voltage Frequency Scaling) design. > > > > PRE_CLK_ENABLE > > POST_CLK_ENABLE > > PRE_CLK_DISABLE > > POST_CLK_DISABLE > > > > Signed-off-by: Bill Huang > > NAK. *Sigh* NO, this is the wrong level to be doing stuff like this. > > The *ONLY* thing that clk_prepare_enable() and clk_prepare_disable() should > *EVER* be doing is calling clk_prepare(), clk_enable(), clk_disable() and > clk_unprepare(). Those two functions are *merely* helpers for drivers > who don't wish to make the individual calls. > > Drivers are still completely free to call the individual functions, at > which point your proposal breaks horribly - and they _do_ call the > individual functions. I'm proposing to give device driver a choice when it knows that some driver might be interested in knowing its clock's enabled/disabled state change at runtime, this is very important for centralized DVFS core driver. It is not meant to be covering all cases especially for drivers which is not part of the DVFS, so we don't care if it is calling clk_enable/disable directly or not. One major side effect being that it affects those existing drivers who were calling clk_prepare_enable and clk_prepare_disable but it should not hurt if they don't care the notifier, or maybe we should define a new set of functions for the purpose? Mike, how do you think? Thanks. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
On 03/12/2013 07:47 PM, Bill Huang wrote: > On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote: >> On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote: >>> Add the below four notifier events so drivers which are interested in >>> knowing the clock status can act accordingly. This is extremely useful >>> in some of the DVFS (Dynamic Voltage Frequency Scaling) design. >>> >>> PRE_CLK_ENABLE >>> POST_CLK_ENABLE >>> PRE_CLK_DISABLE >>> POST_CLK_DISABLE >>> >>> Signed-off-by: Bill Huang >> >> NAK. *Sigh* NO, this is the wrong level to be doing stuff like this. >> >> The *ONLY* thing that clk_prepare_enable() and clk_prepare_disable() should >> *EVER* be doing is calling clk_prepare(), clk_enable(), clk_disable() and >> clk_unprepare(). Those two functions are *merely* helpers for drivers >> who don't wish to make the individual calls. >> >> Drivers are still completely free to call the individual functions, at >> which point your proposal breaks horribly - and they _do_ call the >> individual functions. > > I'm proposing to give device driver a choice when it knows that some > driver might be interested in knowing its clock's enabled/disabled state > change at runtime, this is very important for centralized DVFS core > driver. It is not meant to be covering all cases especially for drivers > which is not part of the DVFS, so we don't care if it is calling > clk_enable/disable directly or not. I believe the point Russell is making is not that the idea behind this patch is wrong, but simply that the function where you put the hooks is wrong. The hooks should at least be in clk_enable/clk_disable and not clk_prepare_enable/clk_disable_unprepare, since any driver is free to call clk_prepare separately from clk_enable. The hooks should be implemented in the lowest-level common function that all driver-accessible paths call through. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
On Wed, 2013-03-13 at 12:42 +0800, Stephen Warren wrote: > On 03/12/2013 07:47 PM, Bill Huang wrote: > > On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote: > >> On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote: > >>> Add the below four notifier events so drivers which are interested in > >>> knowing the clock status can act accordingly. This is extremely useful > >>> in some of the DVFS (Dynamic Voltage Frequency Scaling) design. > >>> > >>> PRE_CLK_ENABLE > >>> POST_CLK_ENABLE > >>> PRE_CLK_DISABLE > >>> POST_CLK_DISABLE > >>> > >>> Signed-off-by: Bill Huang > >> > >> NAK. *Sigh* NO, this is the wrong level to be doing stuff like this. > >> > >> The *ONLY* thing that clk_prepare_enable() and clk_prepare_disable() should > >> *EVER* be doing is calling clk_prepare(), clk_enable(), clk_disable() and > >> clk_unprepare(). Those two functions are *merely* helpers for drivers > >> who don't wish to make the individual calls. > >> > >> Drivers are still completely free to call the individual functions, at > >> which point your proposal breaks horribly - and they _do_ call the > >> individual functions. > > > > I'm proposing to give device driver a choice when it knows that some > > driver might be interested in knowing its clock's enabled/disabled state > > change at runtime, this is very important for centralized DVFS core > > driver. It is not meant to be covering all cases especially for drivers > > which is not part of the DVFS, so we don't care if it is calling > > clk_enable/disable directly or not. > > I believe the point Russell is making is not that the idea behind this > patch is wrong, but simply that the function where you put the hooks is > wrong. The hooks should at least be in clk_enable/clk_disable and not > clk_prepare_enable/clk_disable_unprepare, since any driver is free to > call clk_prepare separately from clk_enable. The hooks should be > implemented in the lowest-level common function that all > driver-accessible paths call through. Thanks, I know the point, but unfortunately there is no good choice for hooking this since those low level functions clk_enable/clk_disable will be called in interrupt context so it is not possible to send notify. We might need to come out a better approach if we can think of any. Currently I still think this is acceptable (Having all the drivers which are using our interested clocks call these function to enable/disable clock in their runtime_pm calls) though it's not perfect. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
On 03/12/2013 11:08 PM, Bill Huang wrote: > On Wed, 2013-03-13 at 12:42 +0800, Stephen Warren wrote: >> On 03/12/2013 07:47 PM, Bill Huang wrote: >>> On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote: On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote: > Add the below four notifier events so drivers which are interested in > knowing the clock status can act accordingly. This is extremely useful > in some of the DVFS (Dynamic Voltage Frequency Scaling) design. > > PRE_CLK_ENABLE > POST_CLK_ENABLE > PRE_CLK_DISABLE > POST_CLK_DISABLE > > Signed-off-by: Bill Huang NAK. *Sigh* NO, this is the wrong level to be doing stuff like this. The *ONLY* thing that clk_prepare_enable() and clk_prepare_disable() should *EVER* be doing is calling clk_prepare(), clk_enable(), clk_disable() and clk_unprepare(). Those two functions are *merely* helpers for drivers who don't wish to make the individual calls. Drivers are still completely free to call the individual functions, at which point your proposal breaks horribly - and they _do_ call the individual functions. >>> >>> I'm proposing to give device driver a choice when it knows that some >>> driver might be interested in knowing its clock's enabled/disabled state >>> change at runtime, this is very important for centralized DVFS core >>> driver. It is not meant to be covering all cases especially for drivers >>> which is not part of the DVFS, so we don't care if it is calling >>> clk_enable/disable directly or not. >> >> I believe the point Russell is making is not that the idea behind this >> patch is wrong, but simply that the function where you put the hooks is >> wrong. The hooks should at least be in clk_enable/clk_disable and not >> clk_prepare_enable/clk_disable_unprepare, since any driver is free to >> call clk_prepare separately from clk_enable. The hooks should be >> implemented in the lowest-level common function that all >> driver-accessible paths call through. > > Thanks, I know the point, but unfortunately there is no good choice for > hooking this since those low level functions clk_enable/clk_disable will > be called in interrupt context so it is not possible to send notify. We > might need to come out a better approach if we can think of any. > Currently I still think this is acceptable (Having all the drivers which > are using our interested clocks call these function to enable/disable > clock in their runtime_pm calls) though it's not perfect. No, that definitely won't work. Not all drivers use those APIs, nor should they. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
On Wed, 2013-03-13 at 13:24 +0800, Stephen Warren wrote: > On 03/12/2013 11:08 PM, Bill Huang wrote: > > On Wed, 2013-03-13 at 12:42 +0800, Stephen Warren wrote: > >> On 03/12/2013 07:47 PM, Bill Huang wrote: > >>> On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote: > On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote: > > Add the below four notifier events so drivers which are interested in > > knowing the clock status can act accordingly. This is extremely useful > > in some of the DVFS (Dynamic Voltage Frequency Scaling) design. > > > > PRE_CLK_ENABLE > > POST_CLK_ENABLE > > PRE_CLK_DISABLE > > POST_CLK_DISABLE > > > > Signed-off-by: Bill Huang > > NAK. *Sigh* NO, this is the wrong level to be doing stuff like this. > > The *ONLY* thing that clk_prepare_enable() and clk_prepare_disable() > should > *EVER* be doing is calling clk_prepare(), clk_enable(), clk_disable() and > clk_unprepare(). Those two functions are *merely* helpers for drivers > who don't wish to make the individual calls. > > Drivers are still completely free to call the individual functions, at > which point your proposal breaks horribly - and they _do_ call the > individual functions. > >>> > >>> I'm proposing to give device driver a choice when it knows that some > >>> driver might be interested in knowing its clock's enabled/disabled state > >>> change at runtime, this is very important for centralized DVFS core > >>> driver. It is not meant to be covering all cases especially for drivers > >>> which is not part of the DVFS, so we don't care if it is calling > >>> clk_enable/disable directly or not. > >> > >> I believe the point Russell is making is not that the idea behind this > >> patch is wrong, but simply that the function where you put the hooks is > >> wrong. The hooks should at least be in clk_enable/clk_disable and not > >> clk_prepare_enable/clk_disable_unprepare, since any driver is free to > >> call clk_prepare separately from clk_enable. The hooks should be > >> implemented in the lowest-level common function that all > >> driver-accessible paths call through. > > > > Thanks, I know the point, but unfortunately there is no good choice for > > hooking this since those low level functions clk_enable/clk_disable will > > be called in interrupt context so it is not possible to send notify. We > > might need to come out a better approach if we can think of any. > > Currently I still think this is acceptable (Having all the drivers which > > are using our interested clocks call these function to enable/disable > > clock in their runtime_pm calls) though it's not perfect. > > No, that definitely won't work. Not all drivers use those APIs, nor > should they. > That will be too bad, it looks like we deadlock in the mechanism, we cannot change existing drivers behavior (that means some call clk_disable/enable directly, some are not), and we cannot hook notifier in clk_disable/enable either, that means there seems no any chance to get what we want, any idea? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
