Re: [PATCH 1/3] thermal: fix a Kconfig help section
On 03/10/2012 07:44 AM, Somebody in the thread at some point said: Thanks a lot for your work Mircea. [PATCH tilt-3.2] syslink: add a missing header to fix a build error - tilt-3.2 [PATCH tilt-3.2] OPP: export symbols for modules - tilt-3.2 [PATCH tilt-3.2] tiler: export the SiTA initializer - tilt-3.2 [PATCH tilt-3.2] DSS: export the omap_dss_get_def_disp symbol - tilt-3.2 The new tree we have has come from OMAP5 pedigree, which is why it's not in good shape for OMAP4 right now. We planned to start solving that last week but had to fight a fire instead. From this week on we'll be building the same tree with an omap4 defconfig routinely and get it back into shape for both. [PATCH 1/3] thermal: fix a Kconfig help section - I fixed it Friday [PATCH 2/3] ARM: fix compilation of timer watchdog - tracking-topic-omap54xx [PATCH 3/3] OMAP: fix a typo in the Makefile - tracking-topic-omap54xx-pm [PATCH] OMAP: remove merge artifacts from the PandaBoard file - tracking-topic-audio-3.3 [PATCH] v4l/omap: fix a compilation error - tracking-topic-54xx-dss Just to advise though we may well squash some or all the merge damage fixes into the patches that introduce the damage. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 2/3] clk: introduce the common clock framework
Hi Mike,
I was about to give my tested-by when I decided to test the set_rate
function. Unfortunately this is broken for several reasons. I'll try
to come up with a fixup series later the day.
On Fri, Mar 09, 2012 at 11:54:23PM -0800, Mike Turquette wrote:
+
+/**
+ * DOC: Using the CLK_SET_RATE_PARENT flag
+ *
+ * __clk_set_rate changes the child's rate before the parent's to more
+ * easily handle failure conditions.
+ *
+ * This means clk might run out of spec for a short time if its rate is
+ * increased before the parent's rate is updated.
+ *
+ * To prevent this consider setting the CLK_SET_RATE_GATE flag on any
+ * clk where you also set the CLK_SET_RATE_PARENT flag
+ *
+ * PRE_RATE_CHANGE notifications are supposed to stack as a rate change
+ * request propagates up the clk tree. This reflects the different
+ * rates that a downstream clk might experience if left enabled while
+ * upstream parents change their rates.
+ */
+static struct clk *__clk_set_rate(struct clk *clk, unsigned long rate)
+{
+ struct clk *fail_clk = NULL;
+ int ret = NOTIFY_DONE;
+ unsigned long old_rate = clk-rate;
+ unsigned long new_rate;
+ unsigned long parent_old_rate;
+ unsigned long parent_new_rate = 0;
+ struct clk *child;
+ struct hlist_node *tmp;
+
+ /* bail early if we can't change rate while clk is enabled */
+ if ((clk-flags CLK_SET_RATE_GATE) clk-enable_count)
+ return clk;
+
+ /* find the new rate and see if parent rate should change too */
+ WARN_ON(!clk-ops-round_rate);
+
+ new_rate = clk-ops-round_rate(clk-hw, rate, parent_new_rate);
You don't need a WARN_ON when you derefence clk-ops-round_rate anyway.
Also, even when the current clock does not have a set_rate function it
can still change its rate when the CLK_SET_RATE_PARENT is set.
+
+ /* NOTE: pre-rate change notifications will stack */
+ if (clk-notifier_count)
+ ret = __clk_notify(clk, PRE_RATE_CHANGE, clk-rate, new_rate);
+
+ if (ret == NOTIFY_BAD)
+ return clk;
+
+ /* speculate rate changes down the tree */
+ hlist_for_each_entry(child, tmp, clk-children, child_node) {
+ ret = __clk_speculate_rates(child, new_rate);
+ if (ret == NOTIFY_BAD)
+ return clk;
+ }
+
+ /* change the rate of this clk */
+ if (clk-ops-set_rate)
+ ret = clk-ops-set_rate(clk-hw, new_rate);
I don't know the reason why you change the child clock before the parent
clock, but it cannot work since this clock will change its rate based on
the old parent rate and not the new one.
There are more things, as said I'll try to come up with a fixup series.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 2/3] clk: introduce the common clock framework
On Sun, Mar 11, 2012 at 4:34 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
Hi Mike,
I was about to give my tested-by when I decided to test the set_rate
function. Unfortunately this is broken for several reasons. I'll try
to come up with a fixup series later the day.
I haven't tested clk_set_rate since V4, but I also haven't changed the
code appreciably. I'll retest on my end also.
On Fri, Mar 09, 2012 at 11:54:23PM -0800, Mike Turquette wrote:
+ /* find the new rate and see if parent rate should change too */
+ WARN_ON(!clk-ops-round_rate);
+
+ new_rate = clk-ops-round_rate(clk-hw, rate, parent_new_rate);
You don't need a WARN_ON when you derefence clk-ops-round_rate anyway.
Agreed that the WARN_ON should not be there.
The v6 Documentation/clk.txt states that .round_rate is mandatory for
clocks that can adjust their rate, but I need to clarify this a bit
more. Ideally we want to be able to call clk_set_rate on any clock
and get a changed rate (if possible) by either adjusting that clocks
rate direction (e.g. a PLL or an adjustable divider) or by propagating
__clk_set_rate up the parents (assuming of course that
CLK_SET_RATE_PARENT flag is set appropriately).
Also, even when the current clock does not have a set_rate function it
can still change its rate when the CLK_SET_RATE_PARENT is set.
Correct. I'll clean this up and make the documentation a bit more
verbose on when .set_rate/.round_rate/.recalc_rate are mandatory.
+
+ /* NOTE: pre-rate change notifications will stack */
+ if (clk-notifier_count)
+ ret = __clk_notify(clk, PRE_RATE_CHANGE, clk-rate, new_rate);
+
+ if (ret == NOTIFY_BAD)
+ return clk;
+
+ /* speculate rate changes down the tree */
+ hlist_for_each_entry(child, tmp, clk-children, child_node) {
+ ret = __clk_speculate_rates(child, new_rate);
+ if (ret == NOTIFY_BAD)
+ return clk;
+ }
+
+ /* change the rate of this clk */
+ if (clk-ops-set_rate)
+ ret = clk-ops-set_rate(clk-hw, new_rate);
I don't know the reason why you change the child clock before the parent
clock, but it cannot work since this clock will change its rate based on
the old parent rate and not the new one.
This depends on the .round_rate implementation, which I admit to
having lost some sleep over. A clever .round_rate will request the
intermediate rate for a clock when propagating a request to change
the parent rate later on. Take for instance the following:
pll @ 200MHz (locked)
|
parent @ 100MHz (can divide by 1 or 2; currently divider is 2)
|
child @ 25MHz (can divide by 2 or 4; currently divider is 4)
If we want child to run at 100MHz then the desirable configuration
would be to have parent divide-by-1 and child divide-by-2. When we
call,
clk_set_rate(child, 100MHz);
Its .round_rate should return 50MHz, and parent_new_rate should be
200MHz. So 50MHz is an intermediate rate, but it gets us the
divider we want. And in fact 50MHz reflects reality because that will
be the rate of child until the parent propagation completes and we can
adjust parent's dividers. (this is one reason why I prefer for
pre-rate change notifiers to stack on top of each other).
So now that parent_new_rate is 0, __clk_set_rate will propagate the
request up and parent's .round_rate will simply return 200MHz and
leave it's own parent_new_rate at 0. This will change from
divide-by-2 to divide-by-1 and from this highest point in the tree we
will propagate post-rate change notifiers downstream, as part of the
recalc_rate tree walk.
I have tested this with OMAP4's CPUfreq driver and I think, while
complicated, it is a sound way to approach the problem. Maybe the API
can be cleaned up, if you have any suggestions.
Regards,
Mike
There are more things, as said I'll try to come up with a fixup series.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announcing Linarotv-xmbc image
On Sun, Mar 11, 2012 at 1:14 PM, Tom Gall tom.g...@linaro.org wrote: On Sat, Mar 10, 2012 at 9:43 PM, Hui Zhang son...@gmail.com wrote: Hi Christian, thank you for the information! Yes, I eventually decided not to use XBMC on hardware without 3D, and use qtmediahub instead. And, I have run XBMC on pandaboard and found out that XBMC requires a lot of CPU(often 90%+). So on hardware without 3D, it is impossilbe to run... What does impossible to run here mean? I've certainly run xbmc on my panda boards and on both video, audio etc was fine. The interface was displaying at 1080p as would be expected and not unusable. Sure lots of CPU might be in use, but it's not like one is going to be running xbmc and compiling kernels at -j16 or something. I mean on hardware without 3D support, XBMC runs very very slow. AFAIK, the majority of platforms for STBs will not have 3D hardware support. But platforms for Smart-TVs, theire hardwares are good, for example, 4-core SXG. On these platforms, XBMC can run well, I think. On Fri, Mar 9, 2012 at 11:08 PM, Christian Robottom Reis k...@linaro.org wrote: On Thu, Jan 26, 2012 at 04:29:40PM +0800, Hui Zhang wrote: Thank you, Ricardo! By your experience,do you think xbmc can perform well on boards without hardware OpenGL ES acceleration? I don't know if Ricardo answered, but unless XBMC has a non-composited 2D mode, I think it's unlikely. You're asking a lot of the CPU, and I don't think the memory is fast enough to handle all the copies. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs -- Regards, Tom Where's the kaboom!? There was supposed to be an earth-shattering kaboom! Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announcing Linarotv-xmbc image
Hi, On Thu, Jan 26, 2012 at 12:30 AM, Tom Gall tom.g...@linaro.org wrote: For the 12.01 cycle the Linaro Platforms team is pleased to announce the availability of the new linarotv-xbmc based image. This combines the xbmc media server project with linaro's leb to result in a works out of the box arm based media server image. It can be found at http://snapshots.linaro.org/oneiric/linaro-o-linarotv-xbmc/ Just tyring to unpack linaro-xbmc with linaro-media-create tool on 2GB SD card but when creating rootfs I get error no space left on device. Do I need bigger SD card or I'm doing something wrong? Currently the best experience can be found on Panda/Panda ES however boards with hardware video acceleration enabled should work well. We welcome feedback and suggestions on the image. Support is on a as best can basis. Bugs if found should be written against linaro-ubuntu in lauchpad. Enjoy! -- Regards, Tom Where's the kaboom!? There was supposed to be an earth-shattering kaboom! Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev regards, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
