All,
There are normally company network restrictions such only port 80 or 443 is
allowed. And that's making it difficult for git to work. Do we have any proxy
or tunnel so that members behind the company firewall can work more
productively?
- eric
Hi Jeremy,
In power management group of linaro, we want to export debug information of
clock to user space and make a common interface to all the SOC platform.
Currently, each SOC platform has their own way to export clock information,
like freesale and TI, which is not ideal.
To do so, I need to make somethings done, and some of them are related to
common clock code, for which I am more than happy to hear your comments.
1. Create clock information based on common clock device, more specific,
based on struct clk_lookup. Since platform drivers are supposed to register
their clock
using 'void clkdev_add(struct clk_lookup *cl)', clk_lookup should contain
enough information for clock display, like clock name and platform clk
definition 'struck clk'. An extra field need to be added into clk_lookup is
a 'struct dentry *' to store a pointer of the dentry node which will be
exported in debug fs, like below:
struct clk_lookup {
struct list_head node;
const char *dev_id;
const char *con_id;
struct clk *clk;
+
+#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
+ struct dentry *dent;
+#endif
};
2. clock names is a little bit fuzzy, cause there are two names in the
clk_lookup, they are dev_id and con_id. And there is no name checking in
clkdev_add, which means that two clock with the same name could be register
into system and it is not reasonable. Also, it is impossible to create clock
information with two clocks having the same name, since user will be
confused about that. So, I plan to
add name checking to avoid name confilt in clkdev_add.
To avoid confusion, I am going to use the combination of dev name and
connection name togather to display clock. It goes like dev-id_con-id.
3. Currently, 'struct clk' is defined in platform related code, common
clk interface did not impose any assumption on how each platform define
their own 'struct clk', therefore, clock debug interface can not make any
assumption on how much information the platform defined clock contains as
well. So far, only clk_get_rate is there as a common defined interface which
I can use to export clock rate information, and I plan to add some optional
interface like clk_get_count, clk_get_flag, so more useful information can
be displayed.
I also attached a draft patch and the clock information displayed on the
console is a tree pattern like below(generated by powerdebug, a user
space application which can display clock information based on the debug
interface I made in the kernel).
|-- NULL-osc <flags=0x0:rate=24000000:usecount=0>
| |-- NULL-spdif_xtal_clk <flags=0x0:rate=24000000:usecount=0>
| | |-- mxc_alsa_spdif.0-NULL <flags=0x0:rate=24000000:usecount=0>
| |-- NULL-usb_phy1_clk <flags=0x0:rate=24000000:usecount=0>
| |-- NULL-lp_apm <flags=0x0:rate=24000000:usecount=0>
| | |-- NULL-ssi_lp_apm_clk <flags=0x0:rate=24000000:usecount=0>
| | | |-- mxc_ssi.1-NULL <flags=0x0:rate=12000000:usecount=0>
| | | | |-- NULL-ssi_ext2_clk <flags=0x0:rate=12000000:usecount=0>
| | | |-- mxc_ssi.0-NULL <flags=0x0:rate=12000000:usecount=0>
| | | | |-- NULL-ssi_ext1_clk <flags=0x0:rate=12000000:usecount=0>
Yong
== [ACTIVITY] [dave-martin-arm] Activity report for weeks 45-46 (2010-11-08 - 2010-11-19) ==
=== Activity ===
==== hardware-n-kernel-standard-architecture ====
* posted various patches for Thumb-2 kernel enablement
* (probably) ported SMP-on-UP to be Thumb-2 compatible --
looking good so far, but needs to be tested on a real
uniprocessor platform.
==== hardware-n-bsp-investigations ====
* spec drafting
* started looking at Freescale's i.MX BSP code for 2.6.35
==== performance-linaro-n-memory-footprint ====
* spec drafting
==== other-linaro-n-gdbserver-integration ====
* spec drafting
==== testing ====
* brief testing of the 11.05 final release on vexpress
==== miscellaneous ====
* set up a kernel git tree on git.linaro.org
* reposted outstanding perf tools patch to linux kernel mailing
list
=== Plans ===
* Test and post SMP-on-uniprocessor Thumb-2 compatibility
patches
* Feed back on Freescale BSP
=== Absences ===
* 2010-12-09 until early January (to be confirmed)
Steve,
Likewise new tree for meta for natty.
John
The following changes since commit 61cb9ff7af265a28043724678b4d3b0482c2e525:
LINARO: Linaro-2.6.35.1008.13 (2010-10-22 07:02:42 -0600)
are available in the git repository at:
git://git.linaro.org/ubuntu/linux-meta-linaro-natty.git master
John Rigby (1):
LINARO: Linaro-2.6.36.1000.1
meta-source/debian/changelog | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
The find_next_bit, find_first_bit, find_next_zero_bit
and find_first_zero_bit functions were not properly
clamping to the maxbit argument at the bit level. They
were instead only checking maxbit at the byte level.
To fix this, add a compare and a conditional move
instruction to the end of the common bit-within-the-
byte code used by all the functions and be sure not to
clobber the maxbit argument before it is used.
Signed-off-by: James Jones <jajones(a)nvidia.com>
Tested-by: Stephen Warren <swarren(a)nvidia.com>
---
arch/arm/lib/findbit.S | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/lib/findbit.S b/arch/arm/lib/findbit.S
index 1e4cbd4..64f6bc1 100644
--- a/arch/arm/lib/findbit.S
+++ b/arch/arm/lib/findbit.S
@@ -174,8 +174,8 @@ ENDPROC(_find_next_bit_be)
*/
.L_found:
#if __LINUX_ARM_ARCH__ >= 5
- rsb r1, r3, #0
- and r3, r3, r1
+ rsb r0, r3, #0
+ and r3, r3, r0
clz r3, r3
rsb r3, r3, #31
add r0, r2, r3
@@ -190,5 +190,7 @@ ENDPROC(_find_next_bit_be)
addeq r2, r2, #1
mov r0, r2
#endif
+ cmp r1, r0 @ Clamp to maxbit
+ movlo r0, r1
mov pc, lr
--
1.7.1
Greetings,
Enclosed you'll find a link to the agenda, notes and actions from the
Linaro User Platforms Weekly Status meeting dated November 17th held in
#linaro-meeting on irc.freenode.net at 13:00 UTC.
https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-11-17
Status Summary:
- blueprint and spec work review continues in advance of public
reviews for Graphics on the 19th and Multimedia on the 23rd
- updated clutter and mutter packages with EGL TFP patches posted to
ppa:asac/armel1
- texture_from_pixmap_glesv2 EGL TFP example pushed to upstream mesa-demos
- No SIMD copy of libjpeg-turbo created as part of understanding
acceleration infrastructure
- Issue created for runtime detection of NEON in skia created
upstream, no feedback yet
- omxil bellagio packaged
- Investigation of ogre using GLES2 rendering engine on arm begun.
Regards,
Tom (tgall_foo)
User Platforms Team
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
FYI, I've set up a tree with my currently posted patches, with
branches currently as follows:
git://git.linaro.org/people/dmart/linux-2.6-arm.git
Upstreamable branches:
* master : base branch in sync with linus' tree
* arm/* : topic branches for ARM architecture support stuff
* arm-all : merge branch of arm/* (excluding arm/development/ branches)
Changes appearing in the above branches has either been posted on
upstream lists or is about to be posted.
Development branches:
* development/* : development versions of upstreamable branches.
These are more volatile and may not have been discussed upstream.
Dirty branches:
* dirty/* : hacking branches which are considered unsuitable for upstream
* dirty-all : merge of all interesting changes including dirty ones
The dirty* branches are not ready for upstreaming:
Don't pull these branches without good reason.
Do we have a systematic place to document the contents of git trees?
I put the above text in linux-2.6-arm.git/description, but gitweb only
seems to show the first line.
I'm a bit of a newbie to this, so any comments welcome regarding how
I've set this up.
Note: If you want to build a Thumb-2 kernel, you'll probably need
dirty/gas-adr-bug, which contains a fix which is needed when building
a Thumb-2 kernel due to a bug in gas.
Cheers
---Dave
All,
The weekly report for the Linaro Infrastructure team may be found at:-
Status report: https://wiki.linaro.org/Platform/Infrastructure/Status/2010-11-18
Burndown chart:http://people.canonical.com/~pitti/workitems/maverick/linaro-infrastr…
The Infrastructure related blueprints, of which currently there are 4 active ones (4 from the last report), are showing that there are 8 work items in progress (11 last report), and 11 work items to undertake (12 last report).
arm-m-validation-dashboard; 0 work items completed since last report; 3 in progress; 7 to do
arm-m-image-building-console; 1 work items completed since last report; 3 in progress; 3 to do
arm-m-automated-testing-framework; no change in status from last report; 1 in progress; 0 to do
arm-m-testsuites-and-profilers; no change in status from last report; 1 in progress; 1 to do
The focus for the team in the past week has remained on preparing Blueprints for the next cycle and holding the review conference call on Monday (2010-11-15).
The team had two new members join this week.
Specifics accomplished this week include:-
* A number of new PPAs were produced this week, including an improved linaro-json package and a stable API for working with dashboard bundles.
* Work started on ImproveLinaroMediaCreate
* Two bugs were fixed for Linaro Image Tools covering apt-get running in rootfs and replacing "sfdisk -l"with "fdisk -l" to give more useful information.
Please let me know if you have any comments or questions.
Kind Regards,
Ian