Re: [powerdebug 32/35] Remove pointless function definitions
On Sun, Mar 27, 2011 at 5:06 AM, Daniel Lezcano wrote:
> By moving the functions in the right order in the file, we can get ride
> of their definitions and we can set them static.
>
Technically, those function names in head files should be declarations, not
definitions.
For this patch, it could be further split, since it is a little bit messed
up, for example: for print_clock_info(), you moved it from the original
place, but for others, it is really hard to see this. It looks like you
removed it and then changed collapse_all_subclocks to a new
print_clock_info somehow.
>
> Signed-off-by: Daniel Lezcano
> ---
> clocks.c | 195
> --
> clocks.h | 18 --
> 2 files changed, 101 insertions(+), 112 deletions(-)
>
> diff --git a/clocks.c b/clocks.c
> index c83055f..b556644 100644
> --- a/clocks.c
> +++ b/clocks.c
> @@ -15,12 +15,18 @@
>
> #include
> #include
> +#include
>
> #include "powerdebug.h"
> #include "clocks.h"
>
> +#define MAX_LINES 120
> +
> static char clk_dir_path[PATH_MAX];
> static int bold[MAX_LINES];
> +static char clock_lines[MAX_LINES][128];
> +static int clock_line_no;
> +static int old_clock_line_no;
>
> static int locate_debugfs(char *clk_path)
> {
> @@ -124,6 +130,29 @@ static void dump_parent(struct clock_info *clk, int
> line, bool dump)
>print_one_clock(maxline - line + 2, str, 1, 0);
> }
>
> +static struct clock_info *find_clock(struct clock_info *clk, char *clkarg)
> +{
> + int i;
> + struct clock_info *ret = clk;
> +
> + if (!strcmp(clk->name, clkarg))
> + return ret;
> +
> + if (clk->children) {
> + for (i = 0; i < clk->num_children; i++) {
> + if (!strcmp(clk->children[i]->name, clkarg))
> + return clk->children[i];
> + }
> + for (i = 0; i < clk->num_children; i++) {
> + ret = find_clock(clk->children[i], clkarg);
> + if (ret)
> + return ret;
> + }
> + }
> +
> + return NULL;
> +}
> +
> static void dump_all_parents(char *clkarg, bool dump)
> {
>struct clock_info *clk;
> @@ -165,6 +194,45 @@ void find_parents_for_clock(char *clkname, int
> complete)
>dump_all_parents(clkname, false);
> }
>
> +static void destroy_clocks_info_recur(struct clock_info *clock)
> +{
> + int i;
> +
> + if (clock && clock->num_children) {
> + for (i = (clock->num_children - 1); i >= 0; i--) {
> + fflush(stdin);
> + destroy_clocks_info_recur(clock->children[i]);
> + if (!i) {
> + free(clock->children);
> + clock->children = NULL;
> + clock->num_children = 0;
> + }
> + }
> + }
> +}
> +
> +static void destroy_clocks_info(void)
> +{
> + int i;
> +
> + if (!clocks_info)
> + return;
> +
> + if (clocks_info->num_children) {
> + for (i = (clocks_info->num_children - 1); i >= 0 ; i--) {
> +
> destroy_clocks_info_recur(clocks_info->children[i]);
> + if (!i) {
> + free(clocks_info->children);
> + clocks_info->children = NULL;
> + }
> + }
> + }
> + clocks_info->num_children = 0;
> + free(clocks_info);
> + clocks_info = NULL;
> +}
> +
> +
> int read_and_print_clock_info(int verbose, int hrow, int selected)
> {
>print_one_clock(0, "Reading Clock Tree ...", 1, 1);
> @@ -190,7 +258,7 @@ int read_and_print_clock_info(int verbose, int hrow,
> int selected)
>return hrow;
> }
>
> -int calc_delta_screen_size(int hrow)
> +static int calc_delta_screen_size(int hrow)
> {
>if (hrow >= (maxy - 3))
>return hrow - (maxy - 4);
> @@ -198,36 +266,7 @@ int calc_delta_screen_size(int hrow)
>return 0;
> }
>
> -void print_clock_info(int verbose, int hrow, int selected)
> -{
> - int i, count = 0, delta;
> -
> - (void)verbose;
> -
> - print_clock_header();
> -
> - for (i = 0; i < clocks_info->num_children; i++)
> - add_clock_details_recur(clocks_info->children[i],
> - hrow, selected);
> -
> - delta = calc_delta_screen_size(hrow);
> -
> - while (clock_lines[count + delta] &&
> - strcmp(clock_lines[count + delta], "")) {
> - if (count < delta) {
> - count++;
> - continue;
> - }
> - print_one_clock(count - delta, clock_lines[count + delta],
> - bold[count + delta], (hrow == (count +
> delta)));
> - count++;
> - }
Re: Libraries with NEON backends
On 28 March 2011 05:09, Michael Hope wrote:
> Hi there. I'm looking for areas where the toolchain could generate
> faster code, and a good way of doing that is seeing how compiled code
> does against the best hand-written code. I know of skia, ffmpeg,
> pixman, Orc, and efl - what others are out there?
>
hi Michael,
Great motivation to optimize the existing libraries by NEON !
As far as I know, Android depends on several libraries, and some of
them are computing bound:
- libpixelflinger -- a bit like pixman
There is no official document about PixelFlinger, but you can always
check out its source:
http://android.git.kernel.org/?p=platform/system/core.git;a=summary
I submitted one NEON optimization patch for libpixelflinger to AOSP before:
https://review.source.android.com//#change,16358
- zlib
Using SIMD, we can optimize 'copy / repeat an existing sequence' in
LZ-style encoding.
The reference Intel SSE2 optimization patch is attached in this mail.
Sincerely,
-jserv
diff -urNp zlib-1.2.5-orig/deflate.c zlib-1.2.5/deflate.c
--- zlib-1.2.5-orig/deflate.c 2010-04-20 12:12:21.0 +0800
+++ zlib-1.2.5/deflate.c2010-07-26 03:53:34.0 +0800
@@ -49,6 +49,17 @@
/* @(#) $Id$ */
+/* We can use 2-byte chunks only if 'unsigned short' has been defined
+ * appropriately and MAX_MATCH has the default value.
+ */
+#ifdef UNALIGNED_OK
+# include
+# include "zutil.h"
+# if (MAX_MATCH != 258) || (USHRT_MAX != 0x)
+#undef UNALIGNED_OK
+# endif
+#endif
+
#include "deflate.h"
const char deflate_copyright[] =
@@ -1119,7 +1130,8 @@ local uInt longest_match(s, cur_match)
* However the length of the match is limited to the lookahead, so
* the output of deflate is not affected by the uninitialized values.
*/
-#if (defined(UNALIGNED_OK) && MAX_MATCH == 258)
+#ifdef UNALIGNED_OK
+
/* This code assumes sizeof(unsigned short) == 2. Do not use
* UNALIGNED_OK if your compiler uses a different size.
*/
diff -urNp zlib-1.2.5-orig/deflate.h zlib-1.2.5/deflate.h
--- zlib-1.2.5-orig/deflate.h 2010-04-19 12:00:46.0 +0800
+++ zlib-1.2.5/deflate.h2010-07-26 03:53:34.0 +0800
@@ -251,9 +251,12 @@ typedef struct internal_state {
ulg bits_sent; /* bit length of compressed data sent mod 2^32 */
#endif
-ush bi_buf;
+ulg bi_buf;
/* Output buffer. bits are inserted starting at the bottom (least
- * significant bits).
+ * significant bits). Room for at least two short values to allow
+ * for a simpler overflow handling. However, if more than 16 bits
+ * have been buffered, it will be flushed and* and no more then 16
+ * bits will be in use afterwards.
*/
int bi_valid;
/* Number of valid bits in bi_buf. All bits above the last valid bit
@@ -274,6 +277,20 @@ typedef struct internal_state {
*/
#define put_byte(s, c) {s->pending_buf[s->pending++] = (c);}
+/* Output a short LSB first on the stream.
+ * IN assertion: there is enough room in pendingBuf.
+ */
+#if defined(LITTLE_ENDIAN) && defined(UNALIGNED_OK)
+# define put_short(s, w) { \
+*(ush*)(s->pending_buf + s->pending) = (ush)(w);\
+s->pending += 2; \
+}
+#else
+# define put_short(s, w) { \
+put_byte(s, (uch)((w) & 0xff)); \
+put_byte(s, (uch)((ush)(w) >> 8)); \
+}
+#endif
#define MIN_LOOKAHEAD (MAX_MATCH+MIN_MATCH+1)
/* Minimum amount of lookahead, except at the end of the input file.
diff -urNp zlib-1.2.5-orig/inffast.c zlib-1.2.5/inffast.c
--- zlib-1.2.5-orig/inffast.c 2010-04-19 12:16:23.0 +0800
+++ zlib-1.2.5/inffast.c2010-07-26 03:53:34.0 +0800
@@ -1,5 +1,6 @@
/* inffast.c -- fast decoding
- * Copyright (C) 1995-2008, 2010 Mark Adler
+ * Copyright (C) 1995-2004, 2010 Mark Adler
+ * 2010 Optimizations by Stefan Fuhrmann
* For conditions of distribution and use, see copyright notice in zlib.h
*/
@@ -10,16 +11,35 @@
#ifndef ASMINF
+/* This is a highly optimized implementation of the decoder function for
+ * large code blocks. It cannot be used to decode close to the end of
+ * input nor output buffers (see below).
+ *
+ * Before trying to hand-tune assembly code for your target, you should
+ * make sure that alignment, endianess, word size optimizations etc. have
+ * already been enabled for the respective target platform.
+
+ * For MS VC++ 2008, the performance gain of specialized code against
+ * DISABLE_INFLATE_FAST_OPTIMIZATIONS (base line) is as follows:
+ *
+ * x86 (32 bit):+60% throughput
+ * x64 (64 bit):+70% throughput
+ *
+ * Measurements were taken on a Core i7 CPU with a mix of small and large
+ * buffers (110MB total) or varying content and an average compression rate
+ * of 2.2 .
+ */
+
/* Allow machine dependent optimization for post-increment or pre-increment.
- Based on testing to date,
- Pre-increment preferred for:
- - PowerPC G3 (Adler)
- - MIPS R5000 (Randers-Pehrson)
Status of the linaro-2.6.38 kernel
Hello everyone, As I've been working on the integration of the latest developments and fixes from upstream into the linaro-2.6.38 kernel lately, it became quickly evident that major merge conflicts were to be expected. The problem stems from the fact that we opened the 2.6.38 branch early i.e. around the 2.6.38-rc5 kernel. Many patches that were merged into the Linaro kernel have been subsequently modified by their respective maintainers until they were merged upstream, meaning that what we have now in mainline is different from what the Linaro kernel tree has. This creates several issues: - It is hard to verify that what is in the Linaro tree is actually the latest and the best version of a patch. - Merging additional fixes from upstream often ends up in merge conflicts requiring manual resolution, sometimes non-trivial ones, which is in itself a bug hazard. - People wanting to contribute patches to the Linaro kernel potentially have to create a different patch than what they would submit upstream. Given those issues, I decided to rebuild the linaro-2.6.38 branch from scratch to see where that would bring me. And as could be expected, the result looks nicer and it is much easier to work with than the current tree. For example, this allowed me to merge the latest OMAP support from mainline as is, including the latest fixes, without any need for backport work nor major conflict resolution. Another advantage is that the commit SHA1 references are now identical in most cases to what can be found into mainline. So... my question is: should we switch to this rebuilt tree or not? There are drawbacks with such a move of course: - All the testing done so far would be void. This is however not as bad as this may look as the rebuilt kernel contains fixes for existing bugs in the current tree, and the rebuilt kernel is using patches that have and still are being tested by a wider community. - I didn't forward port a couple series of patches that are available in the current Linaro tree and not in mainline yet, including: * DT support (Grant Likely) * DVFS and PM for OMAP (Vishwanath Sripathy, Vishwanath BS) * Some ux500 fixups (Linus Walleij) * clock debug information (Yong Shen) * Samsung CPUIDLE (Amit Kachhap) So I would prefer if the people responsible for those patches did resubmit their patches once they apply to the new tree (that should be even easier now to apply patches that were meant for mainline). - The history of the rebuilt tree is obviously different from the current tree's. This means special care when updating to the new tree with Git. But overall I think there are more advantages than disadvantages for such a move. What other people think? The current rebuilt tree can be seen at: http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.38.git;a=shortlog;h=refs/heads/rebuilt or obtained from: git://git.linaro.org/kernel/linux-linaro-2.6.38.git (the "rebuilt" branch) Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Starting a cookbook
On Mon, Mar 28, 2011 at 12:29 PM, Loïc Minier wrote: > On Mon, Mar 28, 2011, Michael Hope wrote: >> Hi there. I'd like to start an official Linaro cookbook that has >> recipes on how to build and use the various Linaro outputs. This >> cookbook would answer questions such as 'how do I build Linaro GCC >> from source?' and could be expanded into others. > > Is that a Linaro Toolchain cookbook? Could be, but it doesn't have to be if there are other things that are complicated to build and use. > Othewise, it sounds much like the HowTo tab on wiki.linaro.org: > https://wiki.linaro.org/Resources/HowTo > https://wiki.linaro.org/CategoryHowTo > > In any I feel your efforts could definitely be part of the HowTos :-) Yip, but I'd like something that someone can read and run; and that we can update and make releases of. The wiki does make things easy to find - perhaps these should also be mirrored up to the wiki for reference? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Starting a cookbook
On Mon, Mar 28, 2011, Michael Hope wrote: > Hi there. I'd like to start an official Linaro cookbook that has > recipes on how to build and use the various Linaro outputs. This > cookbook would answer questions such as 'how do I build Linaro GCC > from source?' and could be expanded into others. Is that a Linaro Toolchain cookbook? Othewise, it sounds much like the HowTo tab on wiki.linaro.org: https://wiki.linaro.org/Resources/HowTo https://wiki.linaro.org/CategoryHowTo In any I feel your efforts could definitely be part of the HowTos :-) -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Starting a cookbook
Hi there. I'd like to start an official Linaro cookbook that has recipes on how to build and use the various Linaro outputs. This cookbook would answer questions such as 'how do I build Linaro GCC from source?' and could be expanded into others. I'm thinking of having a concise Makefile for each of the interesting uses. The Makefiles would be executable documentation - something that you can read and understand the steps, and also run to get a valid output. They should be correct but very focused so, for example, a broken download would be detected but make force a 'make clean' instead of adding another line to the script. I currently have a single stage cross GCC against the Linaro sysroot, a bare metal cross GCC (unsupported), and a fancy cross GCC that works against the Debian/Ubuntu ARM, PowerPC, and MIPS sysroots. This would be an official Linaro product and would be updated with each monthly release. Thoughts? What scripts do people have tucked away that I could tidy up and publish? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Yet another memory provider: can linaro organize a meeting?
I'll be at ELC, as well as living in SF, so I'll be around before and after as well. cheers, Jesse On Fri, Mar 25, 2011 at 2:41 PM, Clark, Rob wrote: > On Wed, Mar 16, 2011 at 3:14 AM, Kyungmin Park > wrote: > > > > Rough schedules. > > > > 1. Warsaw meetings (3/16~3/18): mostly v4l2 person and some SoC vendors > > Make a consensence at media developers. and share the information. > > Please note that it's v4l2 brainstorming meeting. so memory > > management is not the main issue. > > 2. ELC (4/11~4/13): DRM, DRI and v4l2 person. > > Fyi, I should be at ELC, at least for a day or two.. it would be nice, > as Andy suggested on other thread, to carve out a timeslot to discuss > in advance, because I'm not sure that I'll be able to be there the > entire time.. > > BR, > -R > > > Discuss GEM/TTM is acceptable for non-X86 system and find out the > > which modules are acceptable. > > We studied the GEM for our environment. but it's too huge and not > > much benefit for us since current frameworks are enough. > > The missing is that no generic memory passing mechanism. We need the > > generic memory passing interface. that's all. > > 3. Linaro (5/9~5/13): ARM, SoC vendors and v4l2 persons. > > I hope several person are anticipated and made a small step for final > goal. > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Libraries with NEON backends
Hi there. I'm looking for areas where the toolchain could generate faster code, and a good way of doing that is seeing how compiled code does against the best hand-written code. I know of skia, ffmpeg, pixman, Orc, and efl - what others are out there? Thanks for any input, -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: Notice: Releases to Cycles
Hi All, Just to give a bit of wider context, we want people inside and outside Linaro to stop thinking we make one "release" once every 6 months, a perception that has built up very quickly. This is for a number of reasons and particularly: - We already deliver a number of monthly releases from Working Groups, and this aspect of Linaro will increase - We will be delivering Evaluation Builds shortly relevant distributions (Android, Ubuntu etc) make their releases. Obviously, neither of the above fit into a consolidated 6 month release, but instead are releases on their own time-tick. For the time being, we will continue with an engineering cycle of 6 months, where we plan at the start and make engineering releases throughout the period. But that is all the 6 months is, and all it should be seen as - an internal Linaro planning cycle. We're still baking these plans, so by Linaro@UDS we'll be able to provide more details as we flesh things out. In the meantime, we'd welcome your feedback. Preferably don't reply all, but mail Kiko, Joey, George Grey and myself. Thx Stephen Doel Chief Operating Officer Linaro Ltd +44 77 66 014 247 -Original Message- From: Joey Stanford [mailto:joey.stanf...@linaro.org] Sent: 25 March 2011 18:21 To: everyone; Linaro Dev Subject: Notice: Releases to Cycles Hi, Kiko requested that we mass rename Releases to Cycles. This makes sense since a release is a point in time event and we operate under a larger cycle. This is now done and a redirect has been put into place. As you see references which are incorrect in wiki pages, please consider doing some drive-by clean-up/gardening. Thanks, Joey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: ELC and memory management
Hi Andy/All, We're also planning this to be one of the (major) threads at Linaro@UDS - https://wiki.linaro.org/Events/2011-05-LDS Thx Stephen Doel Chief Operating Officer Linaro Ltd +44 77 66 014 247 Date: Sat, 26 Mar 2011 09:48:14 + From: David Rusling To: "Gross, Andy" Cc: "linaro-dev@lists.linaro.org" Subject: Re: ELC and memory management Message-ID: <4ec4b3af-39e6-4c64-b563-ade7a69aa...@linaro.org> Content-Type: text/plain; charset=us-ascii Andy, good idea. Jesse will be there, so would be good to agree the problem and start thinking of some directions... Dave Sent from yet another ARM powered mobile device On 25 Mar 2011, at 21:08, "Gross, Andy" wrote: > All, > > Are there plans of having a meeting to discuss memory management at the ELC? There was a thread a week or so ago about all of the various implementations of memory managers (pmem, cmem, ump, gem/ttm, etc) where this was mentioned. > > Our interest in this stems from our current effort to migrate our OMAP display and memory management functionality to the DRI/DRM model. Like everyone else, we have to allocate large blocks of memory that are used for display, video encode/decode, and capture. We're in the same boat of having implementations that are not upstream. > > If there is not already a meeting, would it be possible to carve out some time on one of the days where there is a graphics centric presentation (Tues/Wed)? > > > Best Regards, > > Andy Gross > Linux Development Center > Texas Instruments > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev End of linaro-dev Digest, Vol 10, Issue 122 *** ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
