Re: Proposal for a low-level Linux display framework
On Thu, 2011-09-15 at 19:55 -0500, Keith Packard wrote: On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen tomi.valkei...@ti.com wrote: 2) panel drivers, handles panel specific things. Each panel may support custom commands and features, for which we need a dedicated driver. And this driver is not platform specific, but should work with any platform which has the output used with the panel. Right, we've got DDC ports (which are just i2c) and DisplayPort aux channel stuff. The DDC stuff is abstracted out and shared across the drivers, but the DisplayPort aux channel code is not -- it's duplicated in every output driver. I feel that you are still talking about the output driver, not the panel. DDC and DP aux are part of the connector-entity in DRM, right? But there's no separate display-entity behind the connector, which would handle the peculiarities for a particular panel/display, say DSI panel model L33T from AcmeCorp. So, as I see it, DDC and DP aux are on the output driver, and the panel driver uses those to do whatever is needed for a particular panel. DSI bus is a half-duplex serial bus, and while it's designed for displays you could use it easily for any communication between the SoC and the peripheral. Yeah, HDMI uses DDC for all kinds of crazy stuff in the CE world. But that is still more or less standard HDMI stuff, isn't it? So you implement it once for HDMI, and then it works with all HDMI monitors? Or is there some way to implement custom behavior for one particular HDMI monitor? Is this custom behavior in a kernel driver or handled in userspace? The point is that we cannot have standard MIPI DSI command mode panel driver which would work for all DSI cmd mode panels, but we need (in the worst case) separate driver for each panel. It sounds like we do want to share code for those bits, much like we have DDC split out now. And, we should do something about the DisplayPort aux channel stuff to avoid duplicating it everywhere. Yep. What I had in mind for DSI with my low-level fmwk would be a mipi_dsi component that offers services to use the DSI bus. Each platform which supports DSI would implement the DSI support for their HW. Then the DSI panel driver could do things like: dsi-write(dev, virtual_channel_id, buf, len); dsi-set_max_return_packet_size(dev, 10); dsi-read(dev, virtual_channel_id, read_cmd, recv_buf, len); An example DSI command mode panel driver can be found from drivers/video/omap2/displays/panel-taal.c, which uses omapdss' dsi functions directly but could quite easily use a common DSI interface and thus be platform independent. I'm not sure a common interface to all of these different channels makes sense, but surely a DSI library and an aux channel library would fit nicely alongside the existing DDC library. What do you mean with channel? Any video or command bus going to the display? Yes, I think they are quite different and I don't see a point in trying to make a common interface for them. DSI is in many ways a real bus. You can connect multiple peripherals to one DSI bus (but it needs a DSI hub), and communicate with them by using their virtual channel ID. And quite often there are DSI chips that transform the DSI packets to some other form. Some real example configurations: Plain DSI panel: [SoC] ---DSI--- [DSI panel] DSI-2-DisplayPort converter chip: [SoC] ---DSI--- [DSI chip] ---DP--- [DP monitor] DSI buffer chip supporting to DSI panels: [SoC] ---DSI--- [DSI chip] +--DSI--- [DSI panel 1] |--DSI--- [DSI panel 2] It would be nice to be able to model this somehow neatly with device drivers. For example, the DSI panel from the first example could be used in the two-panel configuration, and if (and when) the panel requires custom configuration, the same panel driver could be used in both cases. In the first case the panel driver would use DSI support from the Soc, in the third case the panel driver would use the DSI support from the DSI chip (which would, in turn, use DSI support from the SoC). Tomi ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [Samsung] [PATCH] ORIGEN : enable device tree support
Dear Angus Ainslie, On 12 September 2011 16:04, Chander Kashyap chander.kash...@linaro.org wrote: Dear Angus, On 10 September 2011 03:32, angus.ains...@linaro.org wrote: From: Angus Ainslie angus.ains...@linaro.org Enable passing a flattened device tree to the kernel. Signed-off-by: Angus Ainslie angus.ains...@linaro.org Acked-by: Chander Kashyap chander.kash...@linaro.org --- include/configs/origen.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) applied to u-boot-samsung. Thanks. Minkyu Kang -- from. prom. www.promsoft.net ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Proposal for a low-level Linux display framework
On Thu, 15 Sep 2011 18:39:21 +, Florian Tobias Schandinat florianschandi...@gmx.de wrote: Well, I'm not against sharing the code and not against taking DRM's current implementation as a base but the steps required to make it generally acceptable would be to split it of, probably as a standalone module and strip all DRM specific things off. Than all things that require EDID can use it, DRM can add DRM-specific things on top and fb can add fb-specific things. The rendering portions of the DRM drivers are all device-specific. The core DRM ioctls are largely about providing some sharing control over the device, mapping memory around and mode setting. One of my biggest problems with KMS is that it has (naturally) a lot more complexity than the fb API which leads to instability. The mode setting portions are of necessity the same. The KMS API exposes more functionality for mode setting, but doesn't actually require any additional hardware-specific knowledge. You still have to be able to bring the hardware up from power on and light up every connected monitor. However, if you want acceleration, you're going to run into bugs that crash the machine. It's a sad reality that graphics hardware just isn't able to recover cleanly in all cases from programmer errors, and that includes errors that come from user mode. Hardware is improving in this area, and reset is getting more reliable than it used to be. But, until we can context switch the graphics hardware at arbitrary points during execution, we're kinda stuck with using the really big reset hammer when programs go awry. -- keith.pack...@intel.com pgpIUDWjnKqy5.pgp Description: PGP signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH V4] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN
Tushar Behera wrote:
Dear Wolfgang Denk,
On Thursday 15 September 2011 02:44 PM, Wolfgang Denk wrote:
Dear Tushar Behera,
In message1316076867-2138-1-git-send-email-tushar.beh...@linaro.org
you
wrote:
ORIGEN board is fitted with 7 LCD panel HV070WSA. The pixel
resolution of the LCD panel is 1024x600.
...
+static struct s3c_fb_pd_win origen_fb_win0 = {
+ .win_mode = {
+ .left_margin= 64,
+ .right_margin = 16,
+ .upper_margin = 64,
+ .lower_margin = 16,
+ .hsync_len = 48,
+ .vsync_len = 3,
+ .xres = 1024,
+ .yres = 600,
+ },
+ .max_bpp= 32,
+ .default_bpp= 24,
+};
Does it still make sense to hard-code such parameters?
In PowerPC-land we pass display mode information in the device tree
using a verbatim EDID block.
Would it be not better (and way more flexible) to do the same here,
now that ARM has device tree support?
Thanks for your suggestions.
Currently work for enabling device tree support for EXYNOS4 based
machine is going on. Once it is done, we should be able to pass this
information through device tree blob.
For non-DT machines, IMHO, we have to follow the current approach.
OK, applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[NOTES] Linaro Release Meeting 2011-09-15
Enclosed, please find a link to the agenda, notes and actions from the Linaro Release Weekly meeting held on September 15th in #linaro-meeting on irc.freenode.net at 16:00 UTC. == Meeting Minutes == http://wiki.linaro.org/Cycles/WeeklyReleaseMeeting/2011-09-15 == Meeting Log == http://irclogs.linaro.org/meeting-logs/linaro-meeting/2011/linaro-meeting.2011-09-15-16.02.log.html == Announcements == * Toolchain WG 2011.09 release: - Linaro GCC 4.6 and 4.5 2011.09 released. - Linaro QEMU 2011.09 released. - Linaro GDB 7.3 2011.09 released. == Previous actions items == * james_w/pfalcon/fabo to follow-up closely on disk space issues, quote of hardrive. - INPROGRESS The disks are plugged in and ready for provisioning. * PM/TL to re-discuss weekly testing and comes out with a plan. - TODO * pfefferz/mansson/dzin to sort out the PoC for Android. might need some redefinition of who we need. - DONE Android Team has provided their point of contacts. * fabo to drop all patched repo instance from the release websites. - DONE Zach would like to mention repo in the lessons learned for Linaro 11.09 post-mortem. == Agenda == * The blueprints have a headline and an acceptance criteria - INPROGRESS See http://wiki.linaro.org/Cycles/1109/Release/Blueprints * Release response team The release response team setup is completed. We have a good coverage of supported boards. For more information, see: http://wiki.linaro.org/Cycles/1109/Release/PointOfContacts * Android/Ubuntu kernel process The Android Team have 6 different processes for handling kernels. These differences slow them down. dzin/mansson have been asked to drive the effort to unify how kernels and other code get delivered and managed for Android/Dev Platform. Zach should write something on how the components get delivered. He has a list of requirements already. The output will land on the Release process. == Image status == * Ubuntu-build - 2 minor build failures to report. build system issues. We triggered a rebuild and images were built successfully. * Android-build is back to normal after reverting repo-linaro. == Bugs == * http://bugs.launchpad.net/bugs/709245 High ARM SMP scheduler performance bug = Tracked by jcrigby, patch available * http://bugs.launchpad.net/bugs/732912 High omapdss DISPC error: GFX_FIFO_UNDERFLOW = Tracked by mounir/doanac; fixed according to doanac; need a comment * http://bugs.launchpad.net/bugs/753878 High Ubuntu image - icons and parts of screen disappear with Origen = Assigned to rsalveti and tbehera, need LT help, no progress * http://bugs.launchpad.net/bugs/754254 High imx51 randomly truncates serial input at 31 characters = Waiting for springz, blocked * http://bugs.launchpad.net/bugs/788746 High Ethernet is not enabled be default = Assigned to mpoirier, in progress * http://bugs.launchpad.net/bugs/804091 High Snowball USB not working = Hardware issue on V2/V3, fixed on V5 to confirm, release notes candidate * http://bugs.launchpad.net/bugs/807230 High ADB requires new userland setup w/ linux-linaro-android 3.0-2011.07 = Assigned to vishal, in progress * http://bugs.launchpad.net/bugs/816638 High Pulseaudio consumes 100% of the cpu when trying to play a sound with natty's linaro LEB and 3.0.0-1402-linaro-lt-omap = Assigned to rsalveti, kan_hu is helping, in progress * http://bugs.launchpad.net/bugs/817317 High [mx51evk] root not found and boot failed to initramfs shell = need LT help * http://bugs.launchpad.net/bugs/819723 High Panda-LEB Build hangs on bringup sometimes = Assigned to Jassi Brar, patch available * http://bugs.launchpad.net/bugs/823313 High Android LEB fails to mount system and user partition interminttently = Assigned to mpoirier, in progress * http://bugs.launchpad.net/bugs/829220 High linaro-media-create fails for snowball_emmc = Fixed but trigger another issue, mpoirier to comment * http://bugs.launchpad.net/bugs/832356 High LT-Panda 11.07/08 lacks device tree support = Assigned to rsalveti, no progress * http://bugs.launchpad.net/bugs/832680 High Make available source and debug packages corresponding to Linaro binary images = Assigned to rsalveti and jcrigby, in progress * http://bugs.launchpad.net/bugs/839539 Undecided mx51evk can't load uImage and dtd from mmc card = need LT help/triage * http://bugs.launchpad.net/bugs/839541 Undecided mx51evk can't find rootfs by UUID, LABEL or device node, then drop to initramfs = need LT help/triage * http://bugs.launchpad.net/bugs/843628 High perf failure on panda (omap4) = Assigned to Dave L./aviksil, in progress * http://bugs.launchpad.net/bugs/850099 High Current gcc 4.6-11.09 tip fails to build kernel = Assigned to rsandifo, work around available, in progress == Action items == * dzin to gather info for lessons learned concerning repo-linaro. * dzin/mansson to drive the effort to unify how kernels and
RE: [PATCH] ARM: EXYNOS4: Add keypad support for Origen
Sachin Kamat wrote:
This patch adds keypad support for Origen board as GPIO keys.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/mach-exynos4/mach-origen.c | 58
+++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
origen.c
index ed59f86..61da36b 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -14,6 +14,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/input.h
+#include linux/gpio_keys.h
#include asm/mach/arch.h
#include asm/mach-types.h
@@ -79,10 +80,67 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
__initdata = {
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
};
+static struct gpio_keys_button origen_gpio_keys_table[] = {
+ {
+ .code = KEY_MENU,
If you're ok, will change tab between '.code' and '=', I think it would be
better to read code.
+ .gpio = EXYNOS4_GPX1(5),
+ .desc = gpio-keys: KEY_MENU,
+ .type = EV_KEY,
+ .active_low = 1,
+ .wakeup = 1,
+ .debounce_interval = 1,
+ }, {
+ .code = KEY_HOME,
+ .gpio = EXYNOS4_GPX1(6),
+ .desc = gpio-keys: KEY_HOME,
+ .type = EV_KEY,
+ .active_low = 1,
+ .wakeup = 1,
+ .debounce_interval = 1,
+ }, {
+ .code = KEY_BACK,
+ .gpio = EXYNOS4_GPX1(7),
+ .desc = gpio-keys: KEY_BACK,
+ .type = EV_KEY,
+ .active_low = 1,
+ .wakeup = 1,
+ .debounce_interval = 1,
+ }, {
+ .code = KEY_UP,
+ .gpio = EXYNOS4_GPX2(0),
+ .desc = gpio-keys: KEY_UP,
+ .type = EV_KEY,
+ .active_low = 1,
+ .wakeup = 1,
+ .debounce_interval = 1,
+ }, {
+ .code = KEY_DOWN,
+ .gpio = EXYNOS4_GPX2(1),
+ .desc = gpio-keys: KEY_DOWN,
+ .type = EV_KEY,
+ .active_low = 1,
+ .wakeup = 1,
+ .debounce_interval = 1,
+ },
+};
+
+static struct gpio_keys_platform_data origen_gpio_keys_data = {
+ .buttons = origen_gpio_keys_table,
+ .nbuttons = ARRAY_SIZE(origen_gpio_keys_table),
+};
+
+static struct platform_device origen_device_gpiokeys = {
+ .name = gpio-keys,
+ .dev = {
+ .platform_data = origen_gpio_keys_data,
+ },
+};
+
static struct platform_device *origen_devices[] __initdata = {
s3c_device_hsmmc2,
s3c_device_rtc,
s3c_device_wdt,
+ origen_device_gpiokeys,
};
static void __init origen_map_io(void)
--
1.7.4.1
Looks ok to me, will apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 0/2] pin controller subsystem v7
From: Linus Walleij linus.wall...@linaro.org
This is the sixth iteration of the controller subsystem, most
changes are described in the individual patches, mainly we are
now doing away with the patch to the AMBA bus to acquire
pinmuxes, instead this is done from the U300 machine core. This
way the impacts on the existing drivers and buses are kept to a
minimum for the time being.
Further I squashed the patch removing the old pinmux driver from
the U300 machine into the patch adding the new driver, because
it was not really possible to do a clean cut anyway.
ChangeLog v6-v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
linux/pinctrl/pinctrl.h API, the drivers do not need to know
the members of this struct. It is now in the local header
core.h.
- Rename the concept of anonymous mux maps to system muxes
and add convenience macros and documentation.
U300 driver:
- Adjust the driver to return the group list as an array of
strings instead of a unsigned * array.
- Add support for the EMIF0 and EMIF1 pin groups.
- Acquire all muxmaps using pinmux hogs from the core using
a subsystem_initcall(). This way we need not change any
drivers or buses. We have the correct struct device *
pointers anyway so why not do it from there, and it
illustrates pretty well what the pinmux core will be able
to do once it can access the device tree.
- Use new convenience macros for system mappings.
- Unregister the GPIO range at removal.
Linus Walleij (2):
drivers: create a pin control subsystem v7
pinmux: add a driver for the U300 pinmux
Documentation/ABI/testing/sysfs-class-pinmux | 11 +
Documentation/pinctrl.txt| 951 +
MAINTAINERS |5 +
arch/arm/mach-u300/Kconfig |2 +
arch/arm/mach-u300/Makefile |2 +-
arch/arm/mach-u300/core.c| 84 ++-
arch/arm/mach-u300/include/mach/syscon.h | 136 ---
arch/arm/mach-u300/mmc.c | 16 -
arch/arm/mach-u300/padmux.c | 367
arch/arm/mach-u300/padmux.h | 39 -
arch/arm/mach-u300/spi.c | 20 -
drivers/Kconfig |4 +
drivers/Makefile |2 +
drivers/pinctrl/Kconfig | 36 +
Android Build Jenkins Log Parser plugin deployed
Hello, 20Mb Android build logs were never easy to parse, and with increasing number of builds we do, it becomes real chore. I had installing Jenkins Log Parser plugin (https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin) in my background queue (https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gradually-improve-build-ui) for some time, and actually started deploying it few weeks ago, which uncovered some issue in the build frontend. Today I finally enabled it for all jobs (including future). What changes this brings? At Jenkin's build page, e.g. https://android-build.linaro.org/jenkins/job/patrik-ryd_pandroid/57/ you'll see new section with error count, e.g. 1 errors, 0 warnings. Then by clicking Parsed Console Output link at the left, you can open parsed log: https://android-build.linaro.org/jenkins/job/patrik-ryd_pandroid/57/parsed_console/ , get list of errors, and easily navigate to their location in the complete build log. Besides showing errors/warnings, there's also category for info messages, and example usage can be seen here: https://android-build.linaro.org/jenkins/job/linaro-android_leb-origen/51/parsed_console/ where it provides quick way to look up which gcc version was used for the build. What is treated as error/warning/info is fully configured in the plugin using regexps. Current config is here: https://android-build.linaro.org/jenkins/userContent/android.parse/*view*/ That's pretty basic so far, and may miss some errors. So, if you'll see such case, or have an idea what would be useful to export as an info message, please let me know. I have bunch of ideas myself, which I'm going to pursue with background priority as part of the aforementioned blueprint. -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 11.07 oprofile on panda busted?
David, Please find below my replies (CB). I hope that they can help you. Sorry all the I cannot say due to legal stuffs but you should be in touch with ARM guys of Linaro to have the errata list. This does not provide many more info but at least you will have their official communication. They could also provide more details on a HW point of view. The issue is referenced by ARM as 751469. Best regards, Cyril Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 On Fri, Sep 16, 2011 at 3:04 PM, David Long dave.l...@linaro.org wrote: ** On Fri, 2011-09-16 at 11:30 +0200, Bianconi, Cyril wrote: I don't think that the A9 issue is the same as the A8. However, effects are the same i.e. it's hard to use PMU. I cannot communicate the A9 errata document as-is due to legal stuff but I belive that I can explain the issue. The issue happens when counters are in overflow (then not sure that this impacts OProfile). Overflow is the only way of getting a counter interrupt right? Then it's a fundamental problem for oprofile. CB Yes, to my understanding, this is the only way. I'm not an OProfile expert and how it behaves internally. Here are my assumptions for the not sure that this impacs OProfile CB As I remember, counter is 32 bits, then interrupt should fire only at about 2 Billion cycles, meaning for a device running at 1GHz, after about 2s. CB OProfile is monitoring processes or functions durations. My high level view is that OProfile is looking at this profiling counter at system transitions like interrupts, context switches, ... CBThen this means that the monitored activity should be longer than 2s without being preempted by the system in order to face the issue. Is such a use-case realistic? or may be I missed stg Theoritically, an interrupt should fire in this case. In reality, this interrupt is lost randomly. The ARM proposed workaround is to use 2 counters: counter 0 and counter1 initialized at counter0+1. If one interrupt is lost, the other one should fire just after. We have noticed that this could not be sufficient and that a third counter should be used to have close to 0% of the interrupts lost. So, even with three counters there's still a statistical chance of failure? CB ARM did not expain the root cause of their issue but only proposed a workaround, so its quite difficult to know the probability of the issue. CB However, your are right that there is always a statistical chance of failure. You can only reduce the probability. CB I saw the following percentage of missed interrupts in my tests (few 10s of seconds): CB 1 counter: about 28% CB 2 counters: about 5.5% CB 3 counters: about 0% Note: This HW issue has been fixed by ARM quite late, so I think that most of the devices on the market should be impacted. Are there part numbers that we can be reasonably sure do work, say perhaps the 4460? CB For legal reasons, I don't think that I can provide the revision of A9 in 4460. However, ARM fixed it late i.e. in A9 r3p0, then ro, r1 and r2 series are impacted. I don't think that 4460 uses r3. May be the official TI representative at Linaro can provide you these info. Thanks, -dl ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Export kernel defconfig through android-build
On Thu, 15 Sep 2011 16:13:32 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: It just does it by name. Thinking more about this. Replacing a kernel is a pretty normal operation. I think if we just generated a script that had the relevant paths from the build and posted that on the build page then that would streamline this operation. Something like: Sorry, let me clarify something, this is with the intent of building an updated kernel to put back in the image, for the purpose of testing a new kernel without rebuilding the whole image? git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0 wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-linaro-master-with-generic-target/18/artifact/build/out/android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2 tar -jxvf android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2 make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- defconfig android_omap4_defconfig make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- uImage Most of those values come out of the build system and you can find most of them, but have a script would be just one more way we're making it easier to work with these builds. That looks like something that would be fairly easy to generate. I generally prefer producing data, and then have scripts to act on that data (e.g. in linaro-image-tools,) but this looks ok. Would you want e.g. the kernel repo to be the one from the build, or to always be jstultz's? If this is something you want you can spin up a blueprint for this work. Paul, would you be interested in completing this one? Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: 11.07 oprofile on panda busted?
Hi, - To my understanding, oprofile is only a statistical tool based on regular sampling like top (well, I shall say /proc/stat). So it runs without impacting much your use case. I don't think it is triggered on system transitions. For that, I would use kernel traces or kprobes. Still a very useful (and used) tool. You choose oprofile to be triggered every X ms by timer or every overflow of 1 PMU counter. Of course, overflow interrupt issue kills use of PMU for triggering (but I found only 1 article in the past really leveraging that). When tool wakes-up, it reads ARM registers + any info allowing to state in which function, thread, kernel/userspace we are (requires also debug symbols) By the way, ARM has a tool, which is an oprofile like where they tune wake-up timer and capture everything they can (kind of combination of top, oprofile, PMU counters reading... down to every ms). Not open source I think. - PMU counter values are writable, no ? So if you want an interrupt every N events, you write Overflow value - N in counter and let counter run. On overflow interrupt, you reset counter to Overflow value - N again. With this overflow interrupt issue, this is clearly killing the use of it as an oprofile trigger. Regards Fred Overflow is the only way of getting a counter interrupt right? Then it's a fundamental problem for oprofile. CB Yes, to my understanding, this is the only way. I'm not an OProfile expert and how it behaves internally. Here are my assumptions for the not sure that this impacs OProfile CB As I remember, counter is 32 bits, then interrupt should fire only at about 2 Billion cycles, meaning for a device running at 1GHz, after about 2s. CB OProfile is monitoring processes or functions durations. My high level view is that OProfile is looking at this profiling counter at system transitions like interrupts, context switches, ... CBThen this means that the monitored activity should be longer than 2s without being preempted by the system in order to face the issue. Is such a use-case realistic? or may be I missed stg Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Building Linaro Android from source and replacing the kernel in an Linaro Android build
On Thu, Sep 15, 2011 at 05:02:24PM -0500, Zach Pfeffer wrote: http://www.linaro.org/linaro-blog/2011/09/15/switching-out-a-pre-built-android-images-kernel/ Nice. To guide the audience, you might want to put some headings in, like Getting the kernel source, Building the kernel, Flashing the base OS and Replacing the kernel. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Export kernel defconfig through android-build
On 16 September 2011 08:53, James Westby james.wes...@linaro.org wrote: On Thu, 15 Sep 2011 16:13:32 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: It just does it by name. Thinking more about this. Replacing a kernel is a pretty normal operation. I think if we just generated a script that had the relevant paths from the build and posted that on the build page then that would streamline this operation. Something like: Sorry, let me clarify something, this is with the intent of building an updated kernel to put back in the image, for the purpose of testing a new kernel without rebuilding the whole image? Yeah. git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0 wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-linaro-master-with-generic-target/18/artifact/build/out/android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2 tar -jxvf android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2 make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- defconfig android_omap4_defconfig make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- uImage Most of those values come out of the build system and you can find most of them, but have a script would be just one more way we're making it easier to work with these builds. That looks like something that would be fairly easy to generate. I generally prefer producing data, and then have scripts to act on that data (e.g. in linaro-image-tools,) but this looks ok. Would you want e.g. the kernel repo to be the one from the build, or to always be jstultz's? The one from the build. If this is something you want you can spin up a blueprint for this work. Paul, would you be interested in completing this one? Yup. Done: https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-kernel-build-script I also spun up: https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-script-to-rebuild-android-locally For rebuilding the entire image and: https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-script-to-download-and-prog-builds For making downloading a programming builds easy. Thanks, James -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Export kernel defconfig through android-build
On Fri, 16 Sep 2011 10:19:49 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-script-to-download-and-prog-builds For making downloading a programming builds easy. That one should be done as an addition to the existing linaro-fetch-image tools in linaro-image-tools. That way there will be a one-stop-shop for fetching and programming linaro platform images, with GUI and command line interfaces. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Export kernel defconfig through android-build
Hello, Just my 2 cents. On Thu, 15 Sep 2011 16:13:32 -0500 Zach Pfeffer zach.pfef...@linaro.org wrote: On 15 September 2011 15:58, James Westby james.wes...@linaro.org wrote: On Thu, 15 Sep 2011 15:08:26 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: I'm writing up some notes on building Android from scratch and replacing the kernel in an Android build from one built locally, and I realized that's it a bit of a chore to extract the kernel config that got used. How is it chore? You get uImage out of boot.tar.bz2 and run scripts/extract-ikconfig from kernel tree on it, voila. As long as we have CONFIG_IKCONFIG_PROC in defconfig, we're ok, and every (open) kernel in the world has to have that option on. Btw, I was really astonished to find out that Ubuntu doesn't have that option set. Horror! My noname cheap tablet doesn't conceal its kernel config from me, and Ubuntu does. I thought, it may make sense to provide an way in android-build to control what gets used - which would make finding this information easier since if would one of the configs that gets passed to the build like TARGET_PRODUCT. Thoughts? Hi, We could (fairly easily I imagine) make the actual config an artefact of the build. Then you could go to any build, grab the config, and so build the same thing locally. Passing it in would be ok, but I'm not sure we would want to make every build have the config specified as well as everything else? The only way that it would be universal would be if you had to specify this on every config, which seems to duplicate information inside the tree. Providing the config that was used as an artefact would be universal. I guess we even have a choice between providing the full .config, and just the name of the defconfig, if that's how the Android build system selects them. It just does it by name. Thinking more about this. Replacing a kernel is a pretty normal operation. It's normal operation for those who know how to do that. And giving people who don't know a script doesn't help at all, because very next question will be I get error running your script, wazzup?, next one will be I made some random changes to defconfig and it no longer boots, etc, etc. I think if we just generated a script that had the relevant paths from the build and posted that on the build page then that would streamline this operation. Something like: git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0 wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-linaro-master-with-generic-target/18/artifact/build/out/android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2 tar -jxvf android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2 make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- defconfig android_omap4_defconfig make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- uImage Most of those values come out of the build system and you can find most of them, but have a script would be just one more way we're making it easier to work with these builds. I am usually proponent of providing more information about builds (and introspection into systems in general), but that seems a bit too much/misplaced to me. First of all, kernel is of course a bit special, but there're thousand other components in Android which might be good to replace, so what about providing 1K scripts to handle that? With that in mind, for me, threshold for how many such scripts to provide is at 0, not 1. Secondly, kernel, while special, is still integral component of Android, so our job is to provide the best kernel and its config, and those who need to tweak/replace it, need to already know how to do that, or learn their way thru it. And that knowledge is not Android-specific, as argued above, and as argued above, providing shortcuts for that would be more of disservice. YMMV ;-) Thanks, James -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Export kernel defconfig through android-build
On 16 September 2011 10:39, James Westby james.wes...@linaro.org wrote: On Fri, 16 Sep 2011 10:19:49 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-script-to-download-and-prog-builds For making downloading a programming builds easy. That one should be done as an addition to the existing linaro-fetch-image tools in linaro-image-tools. That way there will be a one-stop-shop for fetching and programming linaro platform images, with GUI and command line interfaces. I'm not so sure. I'm just looking for a script that contains: wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_panda-11.09-release/2/artifact/build/out/target/product/pandaboard/boot.tar.bz2 wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_panda-11.09-release/2/artifact/build/out/target/product/pandaboard/system.tar.bz2 wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_panda-11.09-release/2/artifact/build/out/target/product/pandaboard/userdata.tar.bz2 bzr branch lp:linaro-image-tools ./linaro-image-tools/linaro-android-media-create --mmc /dev/sdc --dev panda --system system.tar.bz2 --userdata userdata.tar.bz2 --boot boot.tar.bz2 ...verbatim. Maybe with an argument for the SD card. Thanks, James -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Export kernel defconfig through android-build
On 16 September 2011 10:55, Paul Sokolovsky paul.sokolov...@linaro.org wrote: Hello, Just my 2 cents. On Thu, 15 Sep 2011 16:13:32 -0500 Zach Pfeffer zach.pfef...@linaro.org wrote: On 15 September 2011 15:58, James Westby james.wes...@linaro.org wrote: On Thu, 15 Sep 2011 15:08:26 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: I'm writing up some notes on building Android from scratch and replacing the kernel in an Android build from one built locally, and I realized that's it a bit of a chore to extract the kernel config that got used. How is it chore? You get uImage out of boot.tar.bz2 and run scripts/extract-ikconfig from kernel tree on it, voila. Sure, and that's a valid usecase, but I'm really just looking for a script that has all the links already in it that someone could run or run with minor modification. As long as we have CONFIG_IKCONFIG_PROC in defconfig, we're ok, and every (open) kernel in the world has to have that option on. Btw, I was really astonished to find out that Ubuntu doesn't have that option set. Horror! My noname cheap tablet doesn't conceal its kernel config from me, and Ubuntu does. John, Andy, Angus, Bernhard, Mathieu would you turn on CONFIG_IKCONFIG_PROC in your configs? I thought, it may make sense to provide an way in android-build to control what gets used - which would make finding this information easier since if would one of the configs that gets passed to the build like TARGET_PRODUCT. Thoughts? Hi, We could (fairly easily I imagine) make the actual config an artefact of the build. Then you could go to any build, grab the config, and so build the same thing locally. Passing it in would be ok, but I'm not sure we would want to make every build have the config specified as well as everything else? The only way that it would be universal would be if you had to specify this on every config, which seems to duplicate information inside the tree. Providing the config that was used as an artefact would be universal. I guess we even have a choice between providing the full .config, and just the name of the defconfig, if that's how the Android build system selects them. It just does it by name. Thinking more about this. Replacing a kernel is a pretty normal operation. It's normal operation for those who know how to do that. And giving people who don't know a script doesn't help at all, because very next question will be I get error running your script, wazzup?, next one will be I made some random changes to defconfig and it no longer boots, etc, etc. Sure, that's actually okay. That would be a good email because people would be working with our stuff and we could help them out etc. I think if we just generated a script that had the relevant paths from the build and posted that on the build page then that would streamline this operation. Something like: git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0 wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-linaro-master-with-generic-target/18/artifact/build/out/android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2 tar -jxvf android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2 make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- defconfig android_omap4_defconfig make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- uImage Most of those values come out of the build system and you can find most of them, but have a script would be just one more way we're making it easier to work with these builds. I am usually proponent of providing more information about builds (and introspection into systems in general), but that seems a bit too much/misplaced to me. First of all, kernel is of course a bit special, but there're thousand other components in Android which might be good to replace, so what about providing 1K scripts to handle that? With that in mind, for me, threshold for how many such scripts to provide is at 0, not 1. Sure, but we'd just do the kernel. Secondly, kernel, while special, is still integral component of Android, so our job is to provide the best kernel and its config, and those who need to tweak/replace it, need to already know how to do that, or learn their way thru it. And that knowledge is not Android-specific, as argued above, and as argued above, providing shortcuts for that would be more of disservice. YMMV ;-) I don't think so. The script would have all the commands in it so it would help people make this leap while lowering the burden on our team to answer each email with the steps that would be in the scripts. Thanks, James -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro
Re: Export kernel defconfig through android-build
On Fri, 16 Sep 2011 11:02:34 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: On 16 September 2011 10:39, James Westby james.wes...@linaro.org wrote: On Fri, 16 Sep 2011 10:19:49 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-script-to-download-and-prog-builds For making downloading a programming builds easy. That one should be done as an addition to the existing linaro-fetch-image tools in linaro-image-tools. That way there will be a one-stop-shop for fetching and programming linaro platform images, with GUI and command line interfaces. I'm not so sure. I'm just looking for a script that contains: Ok, but Alexander is keen to see this integration with the linaro-fetch-image tools, and I think it would lead to an improved experience as well. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Proposal for a low-level Linux display framework
I'm not sure a common interface to all of these different channels makes sense, but surely a DSI library and an aux channel library would fit nicely alongside the existing DDC library. DSI and the various other MIPI bits tend to be horribly panel and device specific. In one sense yes its a standard with standard commands, processes, queries etc, on the other a lot of stuff is oriented around the 'its a fixed configuration unit we don't need to have queries' view. There also tends to be a lot of vendor magic initialisation logic both chipset and device dependant, and often 'plumbing dependant' on SoC systems. This is doubly ugly with the I²C abstractions for DDC because SoC systems are not above putting the DDC on a standard I²C port being shared with other functionality. Oh, I think you're also trying to get at how we expose some of these controls outside of the display driver -- right now, they're mostly exposed as properties on the output device. Things like backlight brightness, a million analog TV output values, dithering control and other more esoteric controls. This is how the MIPI handling in the GMA500 driver works, although the existing code needs to be taken out and shot, which should be happening soon. There is a lot, like panel initialisation which is however not really going to fit a properties model. Alan ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Building Linaro Android from source and replacing the kernel in an Linaro Android build
Great feedback Kiko! Update the post. On 16 September 2011 10:10, Christian Robottom Reis k...@linaro.org wrote: On Thu, Sep 15, 2011 at 05:02:24PM -0500, Zach Pfeffer wrote: http://www.linaro.org/linaro-blog/2011/09/15/switching-out-a-pre-built-android-images-kernel/ Nice. To guide the audience, you might want to put some headings in, like Getting the kernel source, Building the kernel, Flashing the base OS and Replacing the kernel. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Export kernel defconfig through android-build
On 16 September 2011 11:17, James Westby james.wes...@linaro.org wrote: On Fri, 16 Sep 2011 11:02:34 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: On 16 September 2011 10:39, James Westby james.wes...@linaro.org wrote: On Fri, 16 Sep 2011 10:19:49 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-script-to-download-and-prog-builds For making downloading a programming builds easy. That one should be done as an addition to the existing linaro-fetch-image tools in linaro-image-tools. That way there will be a one-stop-shop for fetching and programming linaro platform images, with GUI and command line interfaces. I'm not so sure. I'm just looking for a script that contains: Ok, but Alexander is keen to see this integration with the linaro-fetch-image tools, and I think it would lead to an improved experience as well. Sounds like we need to all have a chat. I don't think it has to be an either or thing. Thanks, James -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[Activity] Power Management WG Weekly Status report for week ending 2011-09-16
Enclosed please find the link to the Weekly Status report for the Power Management working group for the week ending 2011-09-16. == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-09-15 == Summary == * The PMWG will handle the common struck clk work, going forward * Steve Jahnke gave thermal talk at Linux Plumbers Conference which was pretty well received. Got a lot of comments and feedback from not just upstream, but also other Si vendors (Intel, Nvidia, Qualcomm). * Basic feedback was that existing framework SHOULD be able to handle what we need (governor structure, etc.) so we should submit patches to that first. * The more complex items (tying multiple sensors into a single thermal zone) would be welcomed additions so we should propose and take the lead here * Samsung: Hosted the thermal sensor driver, thermal governor , cooling devices and the DVFS fixes that are not in mainline * Started testing sched_mc features in samsung exynos board. * Continuing the work on imx cpuidle driver, modifying code to be more community friendly and testing and fixing issues for compatibility with i.MX6Q. * Initial tests on the cpuidle menu governor showed some significant power inefficiency for some contexts, will discuss the findings with Linaro PMWG. * Studying the impact of flags and fields of struct sched_domain in scheduling policy Best regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Android 2011.09 toolchains ready
The toolchain builds featuring the 11.09 release from the toolchain WG are ready: https://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.09/ https://android-build.linaro.org/builds/~linaro-android/toolchain-4.5-2011.09/ Please update your builds to use it, and let me know if anything goes wrong. ttyl bero ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Export kernel defconfig through android-build
On Thu, 2011-09-15 at 16:13 -0500, Zach Pfeffer wrote: git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0 Minor nit here, going forward I think we want to point folks to the tree here: git://android.git.linaro.org/kernel/linaro-android.git Since at some point I'm likely to move the linaro-android kernel away from my people repo. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android Build Jenkins Log Parser plugin deployed
On 16 September 2011 07:17, Paul Sokolovsky paul.sokolov...@linaro.org wrote: Hello, 20Mb Android build logs were never easy to parse, and with increasing number of builds we do, it becomes real chore. I had installing Jenkins Log Parser plugin (https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin) in my background queue (https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gradually-improve-build-ui) for some time, and actually started deploying it few weeks ago, which uncovered some issue in the build frontend. Today I finally enabled it for all jobs (including future). What changes this brings? At Jenkin's build page, e.g. https://android-build.linaro.org/jenkins/job/patrik-ryd_pandroid/57/ you'll see new section with error count, e.g. 1 errors, 0 warnings. Then by clicking Parsed Console Output link at the left, you can open parsed log: https://android-build.linaro.org/jenkins/job/patrik-ryd_pandroid/57/parsed_console/ , get list of errors, and easily navigate to their location in the complete build log. Besides showing errors/warnings, there's also category for info messages, and example usage can be seen here: https://android-build.linaro.org/jenkins/job/linaro-android_leb-origen/51/parsed_console/ where it provides quick way to look up which gcc version was used for the build. What is treated as error/warning/info is fully configured in the plugin using regexps. Current config is here: https://android-build.linaro.org/jenkins/userContent/android.parse/*view*/ That's pretty basic so far, and may miss some errors. So, if you'll see such case, or have an idea what would be useful to export as an info message, please let me know. I have bunch of ideas myself, which I'm going to pursue with background priority as part of the aforementioned blueprint. Hey, this is really cool. Thanks Paul! -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Export kernel defconfig through android-build
On 16 September 2011 14:10, john stultz johns...@us.ibm.com wrote: On Thu, 2011-09-15 at 16:13 -0500, Zach Pfeffer wrote: git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0 Minor nit here, going forward I think we want to point folks to the tree here: git://android.git.linaro.org/kernel/linaro-android.git Since at some point I'm likely to move the linaro-android kernel away from my people repo. Oh definitely. If you want to move it now I can update the manifest. Just send me the git and the branch. thanks -john -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Export kernel defconfig through android-build
On Fri, 2011-09-16 at 14:13 -0500, Zach Pfeffer wrote: On 16 September 2011 14:10, john stultz johns...@us.ibm.com wrote: On Thu, 2011-09-15 at 16:13 -0500, Zach Pfeffer wrote: git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0 Minor nit here, going forward I think we want to point folks to the tree here: git://android.git.linaro.org/kernel/linaro-android.git Since at some point I'm likely to move the linaro-android kernel away from my people repo. Oh definitely. If you want to move it now I can update the manifest. Just send me the git and the branch. git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.0 thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Export kernel defconfig through android-build
On 16 September 2011 14:27, john stultz johns...@us.ibm.com wrote: On Fri, 2011-09-16 at 14:13 -0500, Zach Pfeffer wrote: On 16 September 2011 14:10, john stultz johns...@us.ibm.com wrote: On Thu, 2011-09-15 at 16:13 -0500, Zach Pfeffer wrote: git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0 Minor nit here, going forward I think we want to point folks to the tree here: git://android.git.linaro.org/kernel/linaro-android.git Since at some point I'm likely to move the linaro-android kernel away from my people repo. Oh definitely. If you want to move it now I can update the manifest. Just send me the git and the branch. git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.0 http://review.android.git.linaro.org/#change,228,patchset=1 And thanks for being awesome! thanks -john -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[pm-qa 1/2] fix error in script
Prevent a syntax error when running the test which leads to an
exception in the script and exiting wildely the loop.
The cpuburn stays running in background.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
include/functions.sh | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/functions.sh b/include/functions.sh
index 2cc44b3..f003414 100644
--- a/include/functions.sh
+++ b/include/functions.sh
@@ -109,8 +109,18 @@ get_governor() {
wait_latency() {
local cpu=$1
local dirpath=$CPU_PATH/$cpu/cpufreq
-local latency=$(cat $dirpath/cpuinfo_transition_latency)
-local nrfreq=$(cat $dirpath/scaling_available_frequencies | wc -w)
+local latency=
+local nrfreq=
+
+latency=$(cat $dirpath/cpuinfo_transition_latency)
+if [ $? != 0 ]; then
+ return $?
+fi
+
+nrfreq=$(cat $dirpath/scaling_available_frequencies | wc -w)
+if [ $? != 0 ]; then
+ return $?
+fi
nrfreq=$((nrfreq + 1))
../utils/nanosleep $(($nrfreq * $latency))
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[pm-qa 2/2] prevent spurious char with the echo file
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org --- cpufreq/Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/cpufreq/Makefile b/cpufreq/Makefile index 9c9133e..e9050e4 100644 --- a/cpufreq/Makefile +++ b/cpufreq/Makefile @@ -28,7 +28,8 @@ LOG=$(TST:.sh=.log) check: uncheck $(LOG) %.log: %.sh - @echo -e ###\n### $(:.sh=): + @echo ### + @echo ### $(:.sh=): @echo -n ### ; cat $(:.sh=.txt); echo ### @./$ 2 $@ -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
HDMI on Overo with Linaro ALIP
I've got a tobi board with HDMI, I just put in the ALIP image and plugged it into my TV for the first time, but I get nothing (but I'm also plugged in via serial and see that it boots completely). So I try X -configure and I get No devices to configure. Configuration failed. ddxSigGiveUp: Closing log I googled a bit, but I must not have the right terms. It's been years since I've had to configure X. Is there some special setup or a tutorial for this? AJ ONeal ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
