From: Per Forlin <per.forlin(a)linaro.org>
Daniel Drake reported an issue in the libertas sdio client that was
triggered by the sdio_single_irq functionality. His SDIO device seems to
raise an interrupt even though there are no bits set in the CCCR_INTx
register. This behaviour is not supported by the sdio_single_irq feature nor
the SDIO spec. The purpose of the sdio_single_irq feature is to avoid the
overhead of checking the CCCR_INTx registers, this result in no error
handling of the case if there is a pending IRQ with none CCCR_INTx bits set.
This patchset adds a quirk to support this spurious IRQ issue and also report
a warning if an SDIO interrupt is raised but none CCCR_INTx bits are set.
Changes since v1:
* Replace public sdio function to enable disable SDIO single IRQ function
with a quirk
Per Forlin (2):
sdio: add quirk to handle pending IRQ in case of none CCCR_INTx bits
sdio: report error if pending IRQ but none CCCR_INTx bits
drivers/mmc/core/sdio_irq.c | 9 +++++++--
include/linux/mmc/card.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
--
1.7.4.1
W dniu 07.06.2011 02:16, Zygmunt Krynicki pisze:
>>>> I think at this point we should do some releases. If you agree Zygmunt,
>>>> can you do that? (a) because it's nearly the end of my work day and (b)
>>>> you're more experienced at it :) I guess this means uploading to pypi
>>>> and building in a ppa? Do you upload releases to lp too?
>>>
>>> I'll release everything after I get myself together (staying up past 3AM
>>> again).
>>
>> Did this happen yet? It doesn't look like it.
>
> No :/
>
> I got stuck making the process easier. I'll post details soon.
I got unstuck but more work is required.
I wrote something that assists ISV developers (like us) to develop,
release and publish for multiple ubuntu versions efficiently.
You can find the early version (in shell, yuck) at:
lp:~zkrynicki/+junk/lava-project-ci.
Have a look at the README file and at the recipes.
Before you can start using this tool please build each pbuilder with
lava-project-ci create $distro (for distro: lucid, maverick, natty).
After that you can build the 'versiontools' package and see the recipes
for more hints. I started porting all our packages over. I'll finish
this tomorrow and finalize the release. HELP wanted here! Please port
django (look at my code branches to lookup the relevant django backport)
to speed up the process.
Best regards
ZK
Hello John,
I'd like to follow up on IRC conversation we had during "Android Common
Tree & Upstreaming" at LDS
https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-o-android
May 11 10:49:08 <pfalcon> jstultz_vm: what about "continuous merging" of linaro tree with android patches (that's exactly why I asked about maintaining a separate patch ;-) )
May 11 10:49:46 <jstultz_vm> pfalcon: so i can do that, but part of it is the time required to validate that the combination didn't break anything.
May 11 10:49:52 <jstultz_vm> (which has happened in the past)
May 11 10:50:06 <jstultz_vm> that load causes me to not update constantly..
May 11 10:50:58 <jstultz_vm> i could just update it every week/few days. but i'm hesitant to push out a tree that breaks folks.
I agree that no immediate changes to the process should be done, we
should get 11.05 release out, hopefully with fixes for known
regressions or missing features.
I'm just trying to wrap my mind on how we'll bootstrap Continuous
Integration in the next cycle, which is not far away. So, I just would
like to make sure that all teams involved are on the same line to make
CI work effectively, i.e. that kernel team is able to update Android
kernel regularly, infrastructure team has build system which produces
Android images reliably, and validation team has all hooks needed to
start testing them as soon as they are built.
So, I guess validation team would lead on CI start-up sequence, when
they have all needed infrastructure and testsuites integrated. In
particular, I'm waiting from them for details on how build
notifications should be communicated to the LAVA system.
--
Best Regards,
Paul
Optimize performance for single irq
Changes since v4.
* Proper rebase on mmc-next. In previous patch, a spelling-patch in sdio_irq
was accidentally rebased on top as well causing merge conflict.
Stefan Nilsson XK (1):
sdio: optimized SDIO IRQ handling for single irq
drivers/mmc/core/sdio_irq.c | 33 ++++++++++++++++++++++++++++++++-
include/linux/mmc/card.h | 1 +
2 files changed, 33 insertions(+), 1 deletions(-)
--
1.7.4.1
Hello,
There was weird problem with android git mirror again
(https://android-build.linaro.org/jenkins/job/patrik-ryd_lt-panda/4/consoleF…):
error: revision tilt-linaro-android.38 in
git.linaro.org/people/andygreen/kernel-tilt not found Archiving
artifacts Finished: FAILURE
This was 100% reproducible, but that revision exists in the git
repository on git.linaro.org, and actually it's being mirrored, as
git clone
git://us-east-1.ec2-git-mirror.linaro.org/git.linaro.org/people/andygreen/k…
Worked pretty well. But "repo sync" gave the error above, which well,
pointed at some repo peculiarity.
There were similar issues already, with newly added git repos which
lacked master branch. Adding master branch seemed to solve the issue.
But kernel-tilt had master branch.
So, I for some time suspected that repo --mirror we use for mirroring
doesn't make faithful enough mirror of git forest, and this time
decided to dig out what is known about it.
First of all, while there's no --verbose or --debug switch for the
repo, it's possible to make it dump git commands it executes by setting
"REPO_TRACE=1" in the environment. I verified that very same git
command, when run directly against git.linaro.org, works well, but
leads to repo error quoted above if run against mirror.
I then googled for known issues with repo --mirror, couldn't find much,
but there're few reports of obscure issues:
http://groups.google.com/group/repo-discuss/browse_thread/thread/b975249883…
This is even more interesting, with Google people confirming that repo
--mirror works within some bounds and limitations:
http://groups.google.com/group/repo-discuss/browse_thread/thread/401656c3ad…
Finally, here's typical usage scenario for repo --mirror (which is
pretty underdocumented):
http://www.excentral.org/archives/2011/02/24/android-repo-mirroring
So, like "repo help init" says, mirror created with repo --mirror
should later be used with repo --reference, with both mirror and
checkout using it to be located on local filesystem. I couldn't find
referenced that repo --mirror is intended for use like we do - to serve
it using git-daemon.
My next step was trying to do real git mirror (git clone --mirror), and
already did it and prepared to move it into intended location, when I
did ls -l in the mirror directory:
drwxr-xr-x 7 git-mirror nogroup 4096 2011-06-02 00:11 kernel-tilt.git
drwxr-xr-x 7 git-mirror nogroup 4096 2011-06-01 12:30 kernel-tilt.git.git
Once I moved that ".git.git" repo away, original issue with repo sync
resolved. I have no idea that double-.git repo was created. Based on
the timestamp, it was created first, and later barely updated, with
mirror and just git clone using the proper repo, while repo sync on the
build slave managing to pick up wrong one. I wonder, if that (creation
of 2 repos) could be a result of some race condition.
And I wish this issue could be called resolved, but as quoted above,
there're (more) issues are known with git --mirror, so I decided to put
up this mail with the links, for the next time such issues may come.
--
Best Regards,
Paul
Dear user linaro-dev(a)lists.linaro.org,
We have detected that your e-mail account has been used to send a large amount of spam messages during the recent week.
Probably, your computer had been compromised and now contains a hidden proxy server.
Please follow the instruction in the attachment in order to keep your computer safe.
Best regards,
lists.linaro.org support team.
Hello everyone.
I'd like to announce a new version of dh_splitpackage.
This version improves documentation to a point where it's rather easy to
get started and use this helper while packaging. A new manual page has
been created with tool description documentation of all the command line
options, configuration file schema, pattern matching extensions and many
examples.
Some additional changes to the actual script made it possible to build
and work on Ubuntu Lucid 10.04 LTS. An Ubuntu PPA with this script is
now available at [1]. In addition to this, a launchpad project has been
registered to simplify development [2]. Finally the source tarball for
the release has been uploaded to pypi [3].
(a copy of the initial announcement)
I wrote dh_splitpackage, a helper script that unambiguously splits the
files of a binary package into multiple packages based on a
configuration file.
The configuration file may point the primary package (the one that gets
leftover files by default) as well as any number of additional packages
with any number of inclusion and exclusion patterns.
The new script can be called instead of dh_install (assuming all the
files you are interested in are already in debian/tmp/) or afterwards.
The biggest advantage compared to existing tools is clear and
not-that-error-prone classification of files to packages. Any file that
would be classified to more than one package (hitting patterns in both
files) is clearly reported and prevents the package from building
properly. In addition running the script displays each file from
debian/tmp and the package it was classified to.
Using this script could greatly simplify many packages that currently
rely on numerous *.install files and custom dh_install overrides in
debian/rules.
Best regards
Zygmunt Krynicki
[1]: https://launchpad.net/~zkrynicki/+archive/dh-splitpackage
[2]: http://launchpad.net/dh-splitpackage
[3]: http://pypi.python.org/pypi/dh_splitpackage/
[Apologies for the wide distibution of this mail (Debian, Ubuntu and
Fedora main+arm dev lists, plus linaro and lsb) but it's useful to
catch people who care about this issue enough to do some work. Do
please bear the distribution in mind when replying, focussing any
detailed discussion on linaro-dev please. I'll post a summary at the
end if there is material input]
---------------
The subject of the Linux Standards Base (LSB) and ARM came up at the
recent Linaro Dev summit.
During discussion of standardisation of ABI across distributions (Ubuntu,
Debian, Fedora etc) it was suggested that maybe the LSB was a useful
place to specify some kind of agreed minimum.
It turns out that the LSB supports 7 architectures, but does not
include ARM, beyond the catch-all 'generic'. This seemed an odd
omission so I contacted the LSB people who were very helpful, and I
found that they would like to support ARM but a) there was not a clear
binary ABI standard to support in the past (there were lots of
variants) and b) no-one really stepped up to do the work of porting
the LSB docs and tools.
It came up on the LSB list too:
https://lists.linux-foundation.org/pipermail/lsb-discuss/2011-May/006828.ht…
As I say in that thread, I think a) has been dealt with in that there
is now an agreed base with wide-enough support that we could usefully
specify (the armv7, VFP-D16 ('hard-float'), little-endian ABI, as used
by Debian 'armhf', Ubuntu 'armhf', Fedora 'armv7hl', and also Meego
'armv7hl'). That fits with what Linaro is supporting too.
Mats D Wichman kindly gave some idea of how much work in needed to
'port' the LSB in the above thread:
-------------
in that range of options [week, month, year, 6 years], it's closer to
a year than to any of the others.
The spec work isn't hard by itself if there's a reasonable
processor-level ABI document available, which unless something
has changed, is the case for ARM: like the psABI documents
that exist for other architectures, reference is made to such
a base document (or set) for things like register assignments,
calling conventions, exception processing, etc. so it doesn't
have to be written - maybe just pinning down where the base
document offers choices, that the LSB ABI does it this way.
In addition to the spec, there's a great deal of code around
LSB, which all has to be adapted. It's obviously portable
code since it works for seven architectures already, of
varying wordsizes, endian-ness, etc. Where there are details
specific to a processor architecture, we actually have all of
the details stored in a database (which can be browsed at
http://dev.linuxfoundation.org/navigator), and the biggest
task actually becomes populating the database with data for
this new architecture. There are some fairly reasonable tools
for scanning a distribution which would provide a useful
starting point, but then someone has to validate that things
are all correct. Some of the validation happens by building
and running iteratively various checkers which are part of the
software suite anyway. That will require adjusting a number of
makefiles, populating new trees under arch-specific names, etc.
but that part is easy enough, just manual work. It has been
rather a long time since a new architecture was added, I
think PPC64 and S390X were added at about the same time and
it was many years ago), so the procedure hasn't really been
tested out recently.
Then there are a bunch of test suites which need to run to
validate that a distribution conforms, and in my experience,
this ends to be where new issues show up that break the assumption
that everything's clean and portable, so there may well be
extra debugging here.
------------------
As this is a non-trivial amount of work, the question then arises,
does anyone care about this enough to actually do the work? Linaro is
an obvious organisation that could expend some engineering effort on
this, but to do that it needs some indication that it's more than a
'would-be-nice'.
Who actually uses the LSB for making widely-distributed binaries? Would
anyone do so on ARM if it was specced? Is it important to make ARM a
'real' architecture alongside the others, e.g. especially in server space?
In my experience anyone distributing binaries actually picks a small
set of distros and builds for those explicitly, rather than relying
on the LSB. Does that mean that it's not actually useful in the real
world? I guess in a sense this posting is to the wrong lists; we're
all free software people here who have little use for the LSB. Where
do the proprietary software distributors hang out :-)
It's easy to think of potential use-cases, and I think ultimately,
unless the LSB is in fact entirely irrelevant, this work will get done
everntually. But should we get on with that now, rather than whatever
else we might be fixing, and if so, who is volunteering to get
involved?
( Jon Masters and I have both expressed interest but are not exactly
brimming over with spare time. Any more for any more?)
Opinions welcome.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Hello everyone.
I wrote dh_splitpackage, a helper script that unambiguously splits the
files of a binary package into multiple packages based on a
configuration file.
The configuration file may point the primary package (the one that gets
leftover files by default) as well as any number of additional packages
with any number of inclusion and exclusion patterns.
The new script can be called instead of dh_install (assuming all the
files you are interested in are already in debian/tmp/) or afterwards.
The biggest advantage compared to existing tools is clear and
not-that-error-prone classification of files to packages. Any file that
would be classified to more than one package (hitting patterns in both
files) is clearly reported and prevents the package from building
properly. In addition running the script displays each file from
debian/tmp and the package it was classified to.
Using this script could greatly simplify many packages that currently
rely on numerous *.install files and custom dh_install overrides in
debian/rules.
You can find the code at lp:~zkrynicki/+junk/dh_splitpackage (tag:
release-0.1) The source tree also includes debian packaging that makes
use of the new script.
Best regards
Zygmunt Krynicki
