linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Golly, is that the dual SD card you and David from tincantools have been working on?

by Zach Pfeffer

Yuppers... Pictures here: https://plus.google.com/u/0/104422661029399872488/posts/3KpdBSzW4FK Its working! -- 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

14 years

LAVA tests in fast models have started!

by Zygmunt Krynicki

Hey folks. Initial batch of LAVA tests in fast models are now running in the Linaro validation lab. This initial run is designed to see how behaves in practice and to check for omissions occurring away from my computer. The branch that I've deployed is lp:~zkrynicki/lava-core/demo-3 (it depends on unreleased json-document tree from github if you want to try it out, there are instructions in the tree). We've got the licensing server setup for production usage and started a (arguably dummy) stream lava-test test based on hwpack_linaro-vexpressdt-rtsm_20120511-22_armhf_supported.tar.gz and linaro-precise-developer-20120426-86.tar.gz which is the combination I was using locally. Over the next few days we'll be working on improving the process so that we can start accepting more realistic tests. Initially do expect high failure rate due to imperfections in the technology, configuration issues, etc. The plan is to quickly move to practical use cases. So far I'm aware of the switcher tests that the QA team is using, and the kvm tests but I have not checked either, in practice, on a fast model yet. My question to you, is to give me pointers (ideally as simple, practical instructions that show it works) for things that you want to run. I'm pretty ignorant about Android side of the story so any message from our android team would be appreciated. Please note that iteraction cycle is very slow. It takes 10+ hours to do trivial things (doing apt-get update, installing a few packages, compiling trivial program and getting it to run for a short moment). Please don't ask us to run monkey for you as we'll be wasting time at this point. My goal is to understand what's missing and to estimate how long given tests typically takes so that we can compare how our infrastructure compares to your needs. Many thanks Zygmunt Krynicki -- Zygmunt Krynicki Linaro Validation Team

14 years

Re: FW: STM Drviers update patch

by Ryan Harkin

(CC'd "inaro-dev" as opposed to "linaro-dev" as I guess that was a previous typo) On 14 May 2012 14:41, Deao, Douglas <d-deao(a)ti.com> wrote: > Andy, > > The commit to my clone was right after "config tilt stm and omap driver" > on tracking-topic-stm. I used "git format-patch -1" to generate the > patch. > > I sent my patch before Ryan's showed up on the landing team site. > My patches are only a new "driver" (stm_arm.c) and the Kconfig/makefile changes needed. This new driver doesn't do anything yet, BTW, it's just a load of debug code. But it shouldn't effect your patch merging over the top of your existing stm_fw.c as I haven't touched that file. > > The Framework driver is not using /sys in any way, just /debugfs, so > anything with /sys was added by Ryan. > Not guilty :-) I think Andy was simply referring to the /debugfs stuff, but called it /sys. > > The Framework driver has always had a debugfs fops API. The first > release supported only character based messages, but the new patch > supports binary transfers using the same fops API. Trying to keep > it easy to use for both cases. > > Regards, > Doug > > > -----Original Message----- > > From: Andy Green [mailto:andy.green@linaro.org] > > Sent: Sunday, May 13, 2012 10:29 PM > > To: Deao, Douglas > > Cc: inaro-dev(a)lists.linaro.org; Ryan Harkin; Arnd Bergmann > > Subject: Re: FW: STM Drviers update patch > > > > On 11/05/12 01:29, Somebody in the thread at some point said: > > > > (looping Ryan and Arnd) > > > > > This time without the copy/paste error. > > > > > > -----Original Message----- > > > From: Deao, Douglas > > > Sent: Thursday, May 10, 2012 12:26 PM > > > To: 'Andy Green' > > > Cc: 'mailto:patches@linaro.org'; 'mailto:linaro-dev@lists.linaro.org' > > > Subject: STM Drviers update patch > > > > > > Andy, > > > > > > Just found the Linaro "Process/UpstreamPatches" page. > > > > > > Anything else that's not obvious to a newbie I need to be aware of? > > > > Hi Doug - > > > > I'm not sure I'm the integration point for these patches or it should > > be > > Ryan... he has sent some refactor patches for omap support recently for > > OMAP5 testing. > > > > Either way patches(a)linaro.org only cares about patches when they're > > sent > > upstream, and we're not there yet. > > > > I wasn't able to get this patch to apply to tracking-topic-stm with or > > without Ryan's changes... is it intended to replace what's there? > > That's fine if so, otherwise what should it apply to? Is it aware of > > Ryan's changes? > > > > http://git.linaro.org/gitweb?p=landing- > > teams/working/ti/kernel.git;a=shortlog;h=refs/heads/tracking-topic-stm > > > > Something I noticed when testing for Ryan was there's a kind of shell > > command type interface via /sys nodes, with commandlines like > > > > echo "rm xyz" > /sys/blah > > > > In the past, I believe there has been some resistance to this kind of > > thing upstream, with a hardline one-token-one-sys-node approach > > demanded. In other /sys based subsystems, they seem to use the idea of > > elaborating the possible commands as /sys nodes themselves, so you > > would > > echo > /sys/.../rm to delete. Maybe Arnd can guide us if that's still > > a > > problem. > > > > Also while we're bothering Arnd, IIRC at one point there was a char > > device, but I can't see it any more with a quick look through the > > framework code. Did you replace it? If so what's the way to transfer > > the bulk data now? > > > > -Andy > > > > > -----Original Message----- > > > From: Deao, Douglas > > > Sent: Tuesday, May 08, 2012 4:40 PM > > > To: Andy Green > > > Cc: Loic Pallardy; scott.bambrough(a)linaro.org; Ryan Harkin; Lee > > Jones; Philippe Langlais > > > Subject: STM Drviers update patch > > > > > > Andy, > > > > > > I have attached a patch for tracking-topic-stm that contains both my > > latest updates and feedback/patches I merged from Loic Pallardy. > > > > > > This patch includes: > > > - Binary data transport > > > - mmap support for mapping channels to user space > > > - PID change notification > > > - Added patched/feedback provided by Loic Pallardy for: > > > echo support improvement > > > API improvements > > > > > > Let me know if there is any additional process for adding patches > > beyond simply sending you the patch. > > > > > > P.S Just noticed you have a change to stm_omap_ti1.0.c that I did not > > manage to update. Let me know if applying the patch causes you any > > grief. > > > > > > Thanks, > > > Doug > > > > > > -- > > 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 >

14 years

Re: FW: STM Drviers update patch

by Ryan Harkin

On 14 May 2012 14:46, Andy Green <andy.green(a)linaro.org> wrote: > On 14/05/12 21:41, Somebody in the thread at some point said: > > Hi - > > > The commit to my clone was right after "config tilt stm and omap driver" >> on tracking-topic-stm. I used "git format-patch -1" to generate the >> patch. >> >> I sent my patch before Ryan's showed up on the landing team site. >> > > OK I'll have another go at gluing it on tomorrow, unless Ryan prefers to > deal with it. I had Ryan's patches locally for a couple of weeks but was > unable to push tracking for several days due to crash bugs I fixed late > last week. Andy, you can just remove my patches from the tree if you like. I can send you a fresh set of patches that apply cleanly over the STM topic when I have something else for you to test. As mentioned in the previous mail, my current set of patches just do some debugging stuff and don't really constitute a "driver" for ARM's STM. > > > The Framework driver is not using /sys in any way, just /debugfs, so >> anything with /sys was added by Ryan. >> > > You're quite right, if I looked a little further along I would have seen > it's /sys/kernel/debugfs. Sorry for the noise. > > > The Framework driver has always had a debugfs fops API. The first >> release supported only character based messages, but the new patch >> supports binary transfers using the same fops API. Trying to keep >> it easy to use for both cases. >> > > -Andy > > > > -- > Andy Green | TI Landing Team Leader > Linaro.org │ Open source software for ARM SoCs | Follow Linaro > http://facebook.com/pages/**Linaro/155974581091106<http://facebook.com/pages/Linaro/155974581091106> - > http://twitter.com/#!/**linaroorg <http://twitter.com/#%21/linaroorg> - > http://linaro.org/linaro-blog >

14 years

[PATCH 0/2] ARM: S3C64xx: cpuidle cleanups

by Daniel Lezcano

These couple of patches use the new cpuidle core api to refactor some part of the code. The first one declares the states directly in the driver declaration and the second one use the timekeeping flag to let the cpuidle core to compute the idle time. I don't have this board, I was not able to test these patches. Daniel Lezcano (2): ARM: s3c64xx: cpuidle - declare the states with the new api ARM: s3c64xx: cpuidle - use timekeeping wrapper arch/arm/mach-s3c64xx/cpuidle.c | 45 +++++++++++++-------------------------- 1 files changed, 15 insertions(+), 30 deletions(-) -- 1.7.5.4

14 years

Making ARM multiplatform kernels DT-only?

by Arnd Bergmann

Hi everyone, I've been discussing multiplatform kernels with a few people recently, and we will have a lot of discussion sessions about this at Linaro Connect in Hong Kong. One question that came up repeatedly is whether we should support all possible board files for each platform in a multiplatform kernel, or just the ones that are already using DT probing. I would like to get a quick poll of opinions on that and I've tried to put those people on Cc that would be most impacted by this, i.e. the maintainers for platforms that have both DT and non-DT board files at the moment. My feeling is that we should just mandate DT booting for multiplatform kernels, because it significantly reduces the combinatorial space at compile time, avoids a lot of legacy board files that we cannot test anyway, reduces the total kernel size and gives an incentive for people to move forward to DT with their existing boards. The counterargument is that we won't be able to support all the boards we currently do when the user switches on multiplatform, but I think that is acceptable. Note that I would still want to allow users to build platforms separately in order to enable the ATAG style board files, even for platforms that are not multiplatform capable. Other opinions? Arnd

14 years

android-build's are failing, we're on it...

by Zach Pfeffer

-- 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

14 years

[PATCH] ARM: EXYNOS: PD: Fix duplicate variable

by Sangwook Lee

struct generic_pm_domain already has a field for name. Use that field instead of creating another field in struct exynos_pm_domain Signed-off-by: Sangwook Lee <sangwook.lee(a)linaro.org> --- arch/arm/mach-exynos/pm_domains.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c index 13b3068..4d2563c 100644 --- a/arch/arm/mach-exynos/pm_domains.c +++ b/arch/arm/mach-exynos/pm_domains.c @@ -28,7 +28,6 @@ */ struct exynos_pm_domain { void __iomem *base; - char const *name; bool is_off; struct generic_pm_domain pd; }; @@ -75,10 +74,10 @@ static int exynos_pd_power_off(struct generic_pm_domain *domain) #define EXYNOS_GPD(PD, BASE, NAME) \ static struct exynos_pm_domain PD = { \ .base = (void __iomem *)BASE, \ - .name = NAME, \ .pd = { \ .power_off = exynos_pd_power_off, \ .power_on = exynos_pd_power_on, \ + .name = NAME, \ }, \ } @@ -99,7 +98,7 @@ static __init int exynos_pm_dt_parse_domains(void) if (of_get_property(np, "samsung,exynos4210-pd-off", NULL)) pd->is_off = true; - pd->name = np->name; + pd->pd.name = (char *)np->name; pd->base = of_iomap(np, 0); pd->pd.power_off = exynos_pd_power_off; pd->pd.power_on = exynos_pd_power_on; @@ -122,7 +121,7 @@ static __init void exynos_pm_add_dev_to_genpd(struct platform_device *pdev, if (pm_genpd_add_device(&pd->pd, &pdev->dev)) pr_info("%s: error in adding %s device to %s power" "domain\n", __func__, dev_name(&pdev->dev), - pd->name); + pd->pd.name); } } -- 1.7.4.1

14 years

What is right git tree/ branch for imx28/evk device tree work?

by Subodh Nijsure

Sounds like a very basic question, I would like to test some of the recent patches related to mx28 for freescale EVK board. ( Some thing like - https://lkml.org/lkml/2012/3/13/176 ) Is there specific branch one should be looking for in git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git? Or these changes are being staged some place other than arm-soc.git? Thanks for the help -Subodh P.S. I posting it linaro mailing list 'cause lot of this device-tree patches seem to be coming from folks with at-linaro.org email addresses.

14 years

Off for a bit in 30 min...

by Zach Pfeffer

Hey team, I'll be offline until tonight in 30 minutes. If you've got anything urgent please let me know. -- 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

14 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev