On Tue, 2011-07-05 at 18:51 +0530, ashishj3 wrote:
> This driver adds support for the watchdog functionality provided by the Dialog
> Semiconductor DA9052 PMIC chip.
>
> Signed-off-by: David Dajun Chen <dchen(a)diasemi.com>
> Signed-off-by: Ashish Jangam <ashish.jangam(a)kpitcummins.com>
> ---
If there are no comments then can you ACK this patch?
On Thu, Jul 21, 2011 at 13:24, Paul Sokolovsky
<paul.sokolovsky(a)linaro.org> wrote:
> I have following scenario:
>
> 1. Submitted a change for branch X to Gerrit.
> 2. In the meantime, I also created a personal branch Y in the same
> repository for integration testing.
> 3. Once that branch Y is pushed into Gerrit, the original change
> (still designated for branch X) is closed as "Merged", with comment
> added "Change has been successfully pushed into branch Y."
>
> For me, this is not expected behavior - the change isn't merged, until
> it lands into the designated branch, personal development branches and
> stuff don't count.
>
> So, is this expected behavior from Gerrit (2.2.1), does it always work
> this way, or can it be configured to be branch-strict, and if no, what
> are recommendations and best practices for manual/automated integration
> testing of changes?
I thought we fixed this. Maybe its only fixed in "master" and hasn't
been released yet?
The old logic matched on Change-Id alone, and allowed a change to be
closed if that Change-Id was pushed into any branch. IIRC current
master matches on Change-Id *AND* branch pair, so pushing a commit
with the same Change-Id into a different branch won't close the open
change.
Hy Andy,
These are the required changes to make SGX to work with the external
module, as we had for 2.6.38.
These patches are just a forward port of the same patches from 2.6.38,
will try to ping the original authors to see why this is still not
upstream.
Cheers!
The following changes since commit 5b14e370cca884fa86471e909512f65b06dcaec2:
config non drm sgx (2011-07-18 11:52:26 +0100)
are available in the git repository at:
git://git.linaro.org/people/rsalveti/linux-linaro-3.0.git
rsalveti-tilt-for-andy
Hemant Hariyani (1):
Kernel changes for hwmod and omap_device initialization for GPU.
Vikram Pandita (1):
OMAP4: SGX-KM: Enable SGX initialisation
arch/arm/mach-omap2/devices.c | 59 +++++++++++++++++++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 84 ++++++++++++++++++++++++++++
arch/arm/plat-omap/include/plat/gpu.h | 33 +++++++++++
3 files changed, 176 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/gpu.h
--
Ricardo Salveti de Araujo
Given the focus of my team's efforts, it's perhaps a bit silly that we
haven't been running our own tests regularly. In any case, I've just
set up a quick n' dirty jenkins job that sets up lava-dev-tool, runs
lava-dev-tool sequence and puts the results here:
http://validation.linaro.org/jenkins/job/lava-selftest/lastSuccessfulBuild/…
which perhaps isn't an ideal summary, but it's a start. More
information on the errors will be buried in the logs somewhere :)
Cheers,
mwh
Several of us at Calxeda have been working on extensions to
lava-dispatcher with an eye toward using it as a general test management
engine not just for individual platforms, but for whole clusters of
machines as well. We've broken our extensions into three feature
branches, which can be found at https://code.launchpad.net/~david-schwarz:
ssh_qemu_clients: Adds SSH and QEMU clients to lava-dispatcher, along
with some infrastructure changes to make running dispatcher actions more
independent of client type. We also provide example scripts and
configurations for each type of client.
result-reporting: Adds the notion of a test_action, which determines
and reports test results independently of lava-test. We considered
something like this necessary to enable coordinated tests running on
groups of machines, because lava-test is necessarily a single platform
utility.
multi-target: Allows a single instance of lava-dispatcher to run
coordinated actions concurrently on an arbitrary number of target
machines. A couple of short sample job scripts are provided.
We'd be interested in any feedback anyone has about these features,
our implementations, etc.
Thanks,
David Schwarz
Calxeda, Inc.
Austin, TX
Hello,
I started to get delivery failures like below when posting to
linaro-dev@ , while having other recipients in to: or cc: too. It seems
ok if I post/forward directly (and only) to linaro-dev@. Can you please
look into this?
Thanks,
Paul
Begin forwarded message:
Date: Fri, 22 Jul 2011 13:57:52 +0000
From: Mail Delivery Subsystem <mailer-daemon(a)googlemail.com>
To: paul.sokolovsky(a)linaro.org
Subject: Delivery Status Notification (Failure)
Delivery to the following recipient failed permanently:
linaro-dev(a)lists.linaro.org
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the
recipient domain. We recommend contacting the other email provider for
further information about the cause of this error. The error that the
other server returned was: 550 550 Message headers fail syntax check
(state 18).
----- Original message -----
Received: by 10.204.15.4 with SMTP id i4mr470780bka.320.1311343071796;
Fri, 22 Jul 2011 06:57:51 -0700 (PDT)
Return-Path: <paul.sokolovsky(a)linaro.org>
Received: from x34f ([95.15.169.226])
by mx.google.com with ESMTPS id
g11sm527663bku.49.2011.07.22.06.57.49 (version=SSLv3 cipher=OTHER);
Fri, 22 Jul 2011 06:57:51 -0700 (PDT)
Date: Fri, 22 Jul 2011 16:57:42 +0300
From: Paul Sokolovsky <paul.sokolovsky(a)linaro.org>
To: linaro-android(a)linaro.org <linaro-android(a)linaro.org>,
linaro-dev(a)lists.linaro.org, James Westby <james.westby(a)linaro.org>,
Zach Pfeffer <zach.pfeffer(a)linaro.org>
Subject: Linaro Android Manifest changes
Message-ID: <20110722165742.2b01c707@x34f>
Organization: Linaro
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.0; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hello,
There have been few changes regarding manifests for Linaro Android,
which may need some actions from anybody who builds or develops Linaro
Android.
1. For compatibility with upstream, manifest git repository was renamed
to git://git.linaro.org/android/platform/manifest.git (previously it
was in plural, manifests.git). This is probably the most visible
changing, coping with which will require fresh checkout of Linaro
Android (unless you're brave enough to edit repo's/git's internal
structures and config; in which case you probably know how to do that,
there're no instructions and it's not officially supported). To
alleviate migration headaches during release time, there's still
symlink to make manifests.git work, so you're welcome to schedule
re-checkout at your convenience, the link will stay for a couple of
weeks. Otherwise, the docs throughout the wiki were updated, and builds
are being migrated. https://wiki.linaro.org/Platform/Android/GetSource
has complete instructions or checking out Linaro Android.
2. To further facilitate compatibility with upstream, and support
Gerrit patch uploading, the Linaro remote in manifests were split in
two independent ones, one referring to Android components (having
android/ path prefix) and another to any component outside of android/
subtree. This is more transparent change, and it might be picked up by
"repo sync". Note that only manifests in "linaro_android_2.3.4" were
converted, in particular pinned manifests in
"linaro-android-11.07-release" were not. It would be nice if Android
team replaced manifests in linaro-android-11.07-release with split
ones, but it's up to them to decide if it's worth doing this before
2011.07 release.
3. Gerrit Review server, http://android.git.linaro.org/ were set for
linaro-android upstream in the manifests, which together with the
changes above will allow to use "repo upload" command to post
developers' change for review to Gerrit in seamless manner.
Please note that these are just incremental changes, with more coming
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hello,
Well, before proceeding further, there seems that tarball naming
convention has changed. For example, now it's
gcc-linaro-4.6-2011.07.tar.bz2 whereas before it was
gcc-linaro-4.6-2011.06-0.tar.bz2 . What's worse is that inside it's
still gcc-linaro-4.6-2011.07-0 top-level directory. The build script
uses tarball basename to find out uncompressed dir name, so builds fail
now. This can be worked around on build script level, but is example of
random inconsistency, and if let such will proliferate, there will be
more and more workarounds everywhere, so would be nice if toolchain WG
fixed tarball name on their side.
Thanks,
Paul
On Thu, 21 Jul 2011 10:18:21 +0300
Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:
> On Wed, 20 Jul 2011 21:44:10 +0100
> Chao Yang <chao.yang(a)linaro.org> wrote:
>
> > Hi Paul,
> >
> > Just a reminder that the bug was found in gcc 4.6, to which, I
> > think, the patch should apply, not 4.5 only.
>
> Oops, sure, I just copied the wrong link, it should be
> http://launchpad.net/gcc-linaro/4.6/4.6-2011.07/+download/gcc-linaro-4.6-20…
> instead.
>
> >
> > Thanks and regards
> > On 20 Jul 2011 21:12, "Paul Sokolovsky" <paul.sokolovsky(a)linaro.org>
> > wrote:
> > > Hello Ulrich,
> > >
> > > On Wed, 20 Jul 2011 21:07:50 +0200
> > > Ulrich Weigand <Ulrich.Weigand(a)de.ibm.com> wrote:
> > >
> > >> Zach Pfeffer <zach.pfeffer(a)linaro.org> wrote on 07/20/2011
> > >> 08:56:32 PM:
> > >> > Michael Hope <michael.hope(a)linaro.org> wrote:
> > >> > > Hey, we're getting ahead of ourselves here. The patch clears
> > >> > > the problem but it hasn't landed upstream and may not be
> > >> > > correct. We also haven't laid the ground work for triaging
> > >> > > the problem including:
> > >> > > * Describing the compiler involved (mainly how it's built)
> > >> > > * Reducing to a test case (normally preprocessed source)
> > >> > > * Reproducing and reducing the fault
> > >> > >
> > >> > > Any fix can introduce other bugs, so it's generally best to
> > >> > > work around a last minute issue and then test it properly for
> > >> > > the next release. We have a range of options:
> > >> > > * Work around it in the packaging (such as changing the
> > >> > > optimisation level, turning of debug, etc)
> > >> > > * Work around it in the source
> > >> > > * Carry a local patch to GCC
> > >> > > * Use an earlier release (say 2011.05)
> > >> > >
> > >> > > We should talk about this in Cambourne especially in
> > >> > > untangling what the Android compiler is, how it's built, and
> > >> > > adding it as a test case for our releases.
> > >> >
> > >> > Michael,
> > >> >
> > >> > Thanks for the feedback. Lets chat at Cambourne. For right now,
> > >> > can we reference Ken's tree to build a WIP Android to
> > >> > facilitate debugging? Could Ken continue to work with Chao to
> > >> > create a testcase that shows the bug? I have our session on
> > >> > Wednesday at 11:00 AM now where we can sort out some more
> > >> > structural issues.
> > >>
> > >> [Pulling in Richard on CC as well.]
> > >>
> > >> Note that by now Richard has done a proper fix of the underlying
> > >> compiler problem, which has now landed upstream:
> > >> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01623.html
> > >>
> > >> So my recommendation would be to use this month's Linaro GCC
> > >> release with Richard's patch on top as the basis for the Android
> > >> compiler. (By next month, I'd assume Linaro GCC will contain
> > >> Richard's patch to start with.)
> > >
> > > That sounds like good plan. So, what process the toolchain team
> > > would suggest for this? I can imagine few choices:
> > >
> > > 1. Toolchain team prepares a tarball for Android team, which is
> > >
> > http://launchpad.net/gcc-linaro/4.5/4.5-2011.07/+download/gcc-linaro-4.5-20…
> > > + http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01623.html
> > > 2. Toolchain team creates a bzr branch withich is 2011.07 release
> > > (with any possible bugfix releases) + that patch applied.
> > > 3. I just add support for applying patches to android-build and
> > > build
> > >
> > http://launchpad.net/gcc-linaro/4.5/4.5-2011.07/+download/gcc-linaro-4.5-20…
> > > with the patch applied.
> > >
> > > My own preference probably would be even p.3, as it doesn't create
> > > extra entities, but as we want more people try and adopt Linaro
> > > tools, p.1 would be still preferable I guess.
> > >
> > >>
> > >>
> > >> Mit freundlichen Gruessen / Best Regards
> > >>
> > >> Ulrich Weigand
> > >>
> > >> --
> > >> Dr. Ulrich Weigand | Phone: +49-7031/16-3727
> > >> STSM, GNU compiler and toolchain for Linux on System z and
> > >> Cell/B.E. IBM Deutschland Research & Development GmbH
> > >> Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung:
> > >> Dirk Wittkopp
> > >> Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
> > >> Stuttgart, HRB 243294
> > >>
> > >
> > >
> > >
> > > --
> > > 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
>
>
>
--
Best Regards,
Paul