Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
On Thu, 2013-03-14 at 02:10 +0800, Stephen Warren wrote: > On 03/12/2013 11:40 PM, Bill Huang wrote: > > 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 > ... > >>> 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? > > I don't know the correct answer. > > But I have a question: Why can't we run notifications from the real > clk_enable? Does the notification mechanism itself inherently block, or > are we worried that implementations/receivers of these notifications > might block. Perhaps we can simply define that these notification types I think both. > may be triggered in atomic context and hence implementations have to > support executing in atomic context. Is possible to make that a > requirement? Is it possible to implement the code that receives these > notifications in atomic context? Making it executing in atomic context won't work since for DVFS we generally having to set voltage (while receiving the notify) through I2C interface which can sleep. > > Is it possible to defer triggering of notifications to some non-atomic > context, even if they happen in an atomic context? I don't think deferring will work either, considering the usage of DVFS, device voltage is tightly coupled with frequency, when clock rate is about to increase, we have to boost voltage first and we can lower the voltage after the clock rate has decreased. All the above sequence have to be guaranteed or you might crash, so deferring not only make thing complicated in controlling the order but also hurt performance. > > I also wonder if this is the right conceptual level to be hooking into > the system. Perhaps DVFS is not something that should be triggered by > noticing that clocks have changed rates, but rather it should be some > form of higher layer that controls (calls into) both the regulator and > clock APIs? I wonder will there be a feasible API can do that since most of SoC is characterizing DVFS on frequency vs. voltage, it makes sense that reviewing voltage when the clock rate change happen, and the only mechanism seem to be hooking notifier in not only clock rate change but also clock enable/disable. ___ 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:40 PM, Bill Huang wrote: > 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 ... >>> 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? I don't know the correct answer. But I have a question: Why can't we run notifications from the real clk_enable? Does the notification mechanism itself inherently block, or are we worried that implementations/receivers of these notifications might block. Perhaps we can simply define that these notification types may be triggered in atomic context and hence implementations have to support executing in atomic context. Is possible to make that a requirement? Is it possible to implement the code that receives these notifications in atomic context? Is it possible to defer triggering of notifications to some non-atomic context, even if they happen in an atomic context? I also wonder if this is the right conceptual level to be hooking into the system. Perhaps DVFS is not something that should be triggered by noticing that clocks have changed rates, but rather it should be some form of higher layer that controls (calls into) both the regulator and clock APIs? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Fwd: tjbench for libjpeg-8c
CCing the list as well. -- Forwarded message -- From: Tom Gall Date: Wed, Mar 13, 2013 at 10:35 AM Subject: Re: tjbench for libjpeg-8c To: Anand Kumar Hi Anand, I had to build tjbench from other sources in order to use it with libjpeg8c. It's a pretty straight forward recompile. It's been awhile since I had worked on this. I seem to remember I used the libjpeg-turbo tjbench source code. I'll be working on this again quite quite soon as I need to refresh and push things upstream. On Wed, Mar 13, 2013 at 8:10 AM, Anand Kumar wrote: > With respect to investigation report on Libjpeg-turbo vs Libjpeg8c, i have a > query on Libjpeg8c's tjbench. > https://wiki.linaro.org/TomGall/LibJpeg8. > > When i downloaded libjpeg8c source code from the community, i couldn't find > the tjbench support in libjpeg8c package. But in the above mentioned link i > could see the benchmark results of tjbench for Libjpeg8c. > > Please let me know, where i can get the libjpeg8c package with tjbench > support. > > ~ Ananda > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Tech Lead, Graphics Working Group | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
ATTENTION: OpenEmbedded layers from Linaro have new structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Today I made several changes to OpenEmbedded layers hosted on git.linaro.org: - - meta-aarch64 - - meta-linaro Meta-aarch64 is now empty and is obsolete. Probably will be removed from server in about month or two. Meta-linaro repository got new structure based on meta-openembedded one and contains three layers: - - meta-aarch64 - - meta-linaro - - meta-linaro-toolchain Today meta-aarch64 is just a copy of old one but everything not related to ARMv8 will be moved from it to meta-linaro. Meta-linaro-toolchain contains just gcc-linaro and support for external Linaro cross toolchains (armv7a and armv8 ones). I considered creation of meta-aarch64-arm-toolchain one with ARM Ltd. version of gcc but it is not often used option so can stay where it is now (meta-aarch64). Instructions how to start building for ARMv8 (with OE) are in wiki: https://wiki.linaro.org/HowTo/ARMv8/OpenEmbedded Note that any scripts present in 'meta-aarch64' got dropped. If you want easy way then use 'jenkins-setup' scripts like it is described in wiki. They are written to be as easy to use as possible. If you have any problems/questions: reply to this email. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRQJERAAoJECbKqQEReiUeKFgQAMUYDB1ymQs8ZspWVynJVJMQ InFsFQUd/QZCgNB9GcG6IepzmViHeMlIxNQ7u+KFABGV8uAz8gwdgcPtWwa/dc1b wu8u84mmwy77WBIMuX087AiXdg8WhJDJz5sztBoK2PL8Ljn1TFB/R17Ew90eN3zn o1DpPnbgMGs67phNiTy8GiQxyaaLZub0ZZZ5v00tWdt7x4vazw6n2r8/o+wzGLj2 536KI13Sepso2dg2mrpqzrwVH8KFP7S/rRiDdKI4Gw9FlTPiaiEEadX7OPKx8YC5 j1WIR0u66LCSe+F3NsfNfEgTOXPGVUNgqvemwGYXQuOLUKz7nnnkEdVRUegSuEVj +bZsgzFunghOsvEgX4ynxLVXgOrkiH4PPMhD+OWcB1pso9+ZdVFTVO2oGOnDg9pK ov7lidEoUDDIZqHxjy5cV36jDnXt8BTI9uEIjVo9gH/0g/67QImXHVONcppg2MfM GDfhYorkah3VTo9zgHZKCDEIstT1OsCSg+PNeKCAN6fDUdmnzGxCJNEj2CaRAzaI vJekxAK0+ptscJ9c+bUmAtcBK+XRvJ9K3naN+apUm13Y6INwKuS68knWzOJc0xhd rpPQ2EcYd8FP1gspjNJPyQKWr2pAUGQkOGkhHrsrb4nj6mkMDDgZ2ET1x8uxI056 vMRn7PKF7x3bItUP9NzA =GNf7 -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/5] clk: notifier handler for dynamic voltage scaling
On 4 March 2013 08:25, Mike Turquette wrote:
> Quoting Richard Zhao (2013-03-03 05:27:52)
>> Hi Mike,
>>
>> On Sun, Mar 03, 2013 at 02:54:24AM -0800, Mike Turquette wrote:
>> > Quoting Richard Zhao (2013-03-02 00:22:19)
>> > > On Fri, Mar 01, 2013 at 06:55:54PM -0800, Bill Huang wrote:
>> > > > On Sat, 2013-03-02 at 04:48 +0800, Mike Turquette wrote:
>> > > > > Quoting Mike Turquette (2013-03-01 10:22:34)
>> > > > > > Quoting Bill Huang (2013-03-01 01:41:31)
>> > > > > > > On Thu, 2013-02-28 at 12:49 +0800, Mike Turquette wrote:
>> > > > > > > > Dynamic voltage and frequency scaling (dvfs) is a common power
>> > > > > > > > saving
>> > > > > > > > technique in many of today's modern processors. This patch
>> > > > > > > > introduces a
>> > > > > > > > common clk rate-change notifier handler which scales voltage
>> > > > > > > > appropriately whenever clk_set_rate is called on an affected
>> > > > > > > > clock.
>> > > > > > >
>> > > > > > > I really think clk_enable and clk_disable should also be
>> > > > > > > triggering
>> > > > > > > notifier call and DVFS should act accordingly since there are
>> > > > > > > cases
>> > > > > > > drivers won't set clock rate but instead disable its clock
>> > > > > > > directly, do
>> > > > > > > you agree?
>> > > > > > > >
>> > > > > >
>> > > > > > Hi Bill,
>> > > > > >
>> > > > > > I'll think about this. Perhaps a better solution would be to adapt
>> > > > > > these drivers to runtime PM. Then a call to runtime_pm_put() would
>> > > > > > result in a call to clk_disable(...) and
>> > > > > > regulator_set_voltage(...).
>> > > > > >
>> > > > > > There is no performance-based equivalent to runtime PM, which is
>> > > > > > one
>> > > > > > reason why clk_set_rate is a likely entry point into dvfs. But for
>> > > > > > operations that have nice api's like runtime PM it would be better
>> > > > > > to
>> > > > > > use those interfaces and not overload the clk.h api unnecessarily.
>> > > > > >
>> > > > >
>> > > > > Bill,
>> > > > >
>> > > > > I wasn't thinking at all when I wrote this. Trying to rush to the
>> > > > > airport I guess...
>> > > > >
>> > > > > clk_enable() and clk_disable() must not sleep and all operations are
>> > > > > done under a spinlock. So this rules out most use of notifiers. It
>> > > > > is
>> > > > > expected for some drivers to very aggressively enable/disable clocks
>> > > > > in
>> > > > > interrupt handlers so scaling voltage as a function of
>> > > > > clk_{en|dis}able
>> > > > > calls is also likely out of the question.
>> > > >
>> > > > Yeah for those existing drivers to call enable/disable clocks in
>> > > > interrupt have ruled out this, I didn't think through when I was
>> > > > asking.
>> > > > >
>> > > > > Some platforms have chosen to implement voltage scaling in their
>> > > > > .prepare callbacks. I personally do not like this and still prefer
>> > > > > drivers be adapted to runtime pm and let those callbacks handle
>> > > > > voltage
>> > > > > scaling along with clock handling.
>> > > Voltage scaling in clock notifiers seems similar. Clock and regulater
>> > > embedded code into each other will cause things complicated.
>> >
>> > Hi Richard,
>> >
>> > Sorry, I do not follow the above statement. Can you clarify what you
>> > mean?
>> As we have agreement that a operating point may have multiple clocks
>> and regulators, this patch is impossible to support multi clocks. And
>> it might mislead dvfs implementer to use clock notifier. It may be good
>> to have unified api like dvfs_set_opp(opp), or drivers can handle clocks
>> and regulators theirselves which is more flexible. What do you think?
>>
>
> Yes, there is a long-standing question whether clk_set_rate is
> sufficient to cover dvfs needs or if a new api is required. There are
> many possible solutions.
>
> One solution is to use clk_set_rate and use the rate-change notifiers to
> call clk_set_rate on the other required clocks. This is graceful from
> the perspective of the driver since the driver author only has to think
> about directly managing the clock(s) for that device and the rest is
> managed automagically. It is more complicated for the platform
> integrator that must make sure the automagical stuff is set up
> correctly. This might be considered a more "distributed" approach.
>From my point of view, I see some concern with this solution. Mainly
because of a lot of complexity with regards to DVFS will be pushed
down to be handled by each an every driver. Probably it will be okay
for SoC specific drivers but likely not for cross SoC drivers, if you
see what I mean.
>
> Another solution would be a new api which calls clk_set_rate
> individually on the affected clocks (e.g. a functional clk, an async
> bridge child clock, and some other related non-child clock). This is
> less complicated for the platform integrator and represents a more
> "centralized" approach. It is less graceful for the device driver
> author who must learn a new ap
tjbench for libjpeg-8c
With respect to investigation report on Libjpeg-turbo vs Libjpeg8c, i have a query on Libjpeg8c's tjbench. https://wiki.linaro.org/TomGall/LibJpeg8. When i downloaded libjpeg8c source code from the community, i couldn't find the tjbench support in libjpeg8c package. But in the above mentioned link i could see the benchmark results of tjbench for Libjpeg8c. Please let me know, where i can get the libjpeg8c package with tjbench support. ~ Ananda ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Planned maintenance - lists.linaro.org
Hello You are receiving this email because you are subscribed to one or more mailing lists provided by the lists.linaro.org server. IT Services are announcing planned maintenance for this server scheduled for *Friday 15th March 2013, starting at 2pm GMT*. The purpose of the work is to move the service to another server. There will be some disruption during this maintenance. In order to ensure that you do not accidentally try to use the service while it is being moved, the current server will be shut down at 2pm. A further email will be sent on Friday afternoon to confirm that the migration of the service is completed. However, due to the way servers are found, it may take a while before your computer is able to connect to the relocated service. After the old server has been shut down, email sent to any of the lists will be queued, but it is possible that the sending server will still trying to deliver the email to the old server rather than the new one when it is started. It is therefore *strongly* recommended that you do not send any email to an @lists.linaro.org email address until you can connect to the new service, which you will be able to test by trying to use a web browser to connect to http://lists.linaro.org after you receive the email confirming that the migration has been completed. Since the old service will be shut down, if you are able to connect, you can be sure you have connected to the new service. If by Monday you are still unable to connect to the service or you are not able to send email to an @lists.linaro.org email address, please send an email to i...@linaro.org. Thank you. Regards Philip IT Services Manager Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: libjpeg8c vs libjpeg-turbo with libjpeg8 compat on
Dear Tom, With respect to your nice investigation report on Libjpeg-turbo Vs Libjpeg8c, I have a query on Libjpeg8c's tjbench https://wiki.linaro.org/TomGall/LibJpeg8 When i took the Libjpeg8c source code from the Libjpeg community, I did not find the tjbench support in the libjpeg8c package. But in your Libjpeg8c's performance report, I have observed that tjbench is used for benchmarking. So please let me know whether the tjbench support for Libjpeg8c package is released to the community. Thanks & Regards, Ananda Kumar B This email is confidential and intended only for the use of the individual or entity named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message. - This mail is sent via Sony Asia Pacific Mail Gateway.. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
