From: Jason Liu <r64343(a)freescale.com>
This patchset adds Freescale i.mx51 device tree support.
This is based on
git://git.secretlab.ca/git/linux-2.6 devicetree/test
This patch has been tested on MX51 babbage board and can
boot up succesfully to linux console with DT enabled.
Grant, I think it's almost ready for you to merge it.
V3:
- prefix the property name with the vendor name as like:
"fsl,has-rts-cts" and "fsl,irda-mode"
- use the ttymxc0 as the console
- add FEC support, nfs can be used now
Jason Liu (5):
arm/dt: add basic mx51 device tree support
arm/dt: add very basic dts file for babbage board
serial/imx: parse from device tree support
net/fec: check id_entry pointer before using it
net/fec: add device tree matching support
arch/arm/boot/dts/babbage.dts | 110 +++++++++++++++++++++++++++++++
arch/arm/mach-mx5/Kconfig | 8 ++
arch/arm/mach-mx5/Makefile | 1 +
arch/arm/mach-mx5/board-dt.c | 64 ++++++++++++++++++
arch/arm/mach-mx5/clock-mx51-mx53.c | 43 ++++++++++++-
arch/arm/plat-mxc/include/mach/common.h | 1 +
drivers/net/fec.c | 25 +++++--
drivers/tty/serial/imx.c | 79 +++++++++++++++++++---
8 files changed, 314 insertions(+), 17 deletions(-)
create mode 100644 arch/arm/boot/dts/babbage.dts
create mode 100644 arch/arm/mach-mx5/board-dt.c
Hi.
This is my first post to this mailing list, and in fact to any Debian
mailing list in general so I'd like to introduce myself first. To keep
Your interest focused on the problem I moved this to the footer of this
message. With that of the way here's the core topic:
I'd like to define and document the recommended best practice of
packaging Django 1.0+ (and especially 1.3) web applications and projects
for Debian. I started this on the Debian wiki at
http://wiki.debian.org/DjangoPackagingDraft
The topics I want to cover are:
* Packaging Django applications:
- where to install code
- where to install templates
- where to install static files (as understood by
http://docs.djangoproject.com/en/dev/howto/static-files/)
- where to install documentation (if any)
* Packaging Django projects:
- where to install code (like urls, settings, etc)
- where to install templates
- how to do settings (debconf integration / configuration files /
python module vs real config file?)
- what to with web server integration (aka
http://localhost/packagename vs do-it-yourself-after-installation)
- how do to database configuration and integration (dbconfig-common?)
There are some things I did not want to enforce because either there is
no clear best method or I don't feel that the topic is relevant before
specifying more fundamental pieces. In particular this includes:
- Shipping web server configuration files so that application can work
out of the box after installation.
- Handling of project configuration (it's both executable code and
administrator-oriented settings file)
I started a demo native package (still work in progress, comments
welcome) called django-hello that contains a simple django project with
one application. I deliberately used django-staticfiles as that's how
upcoming web applications will distribute their static files. The code
is at lp:~zkrynicki/+junk/django_hello. There is an Ubuntu PPA with
python-django-staticfiles package that is required at
https://launchpad.net/~zkrynicki/+archive/lava).
There are some compromises I needed to make though. This package is
using python-support as I still need to target the current Ubuntu LTS
release (lucid) where dh_python2 is not available. I'm more than happy
to convert this package to dh_python2 assuming that the same rules can
be applied in a backwards compatible manner to Lucid packages.
That's it.
I'd like to know what you think.
About me:
My name is Zygmunt Krynicki. I'm work in the Linaro Validation team and
I'd like to start a process that will make the output of the Linaro
Validation team available to Debian users. I'd like to maintain the
packages we're making and learn to do those packages properly.
Most of my work revolves around server-side technology, specifically
around Django web applications. I did not find any strong guidelines on
how to package Django web applications and projects for Debian.
Therefore I decided that I'd like to contribute to Debian and help
define and apply those guidelines to various Django applications as they
become available.
Best regards
Zygmunt Krynicki
PS: I cross-posted to linaro-dev to make sure people there that might be
interested in this discussion can notice it and participate.
Hi all,
on March 7th MM WG has organize a v4l2 meeting to collect ideas for next
development cycle.
you can found the minutes of meeting here:
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/2011-03-07-V4L2…
mains outcomes:
- investigate/improve the library between v4l2 and Android camera interface
- work on memory allocators: pmem, UMP or hwmem
- design a thin, easy IPC layer in kernel space
- develop an OMX library on top of v4l2
v4l2 developers have demonstrated lot of interest on hwmem topic
v4l2 is active on ISP/DSP/co-processors topic
Benjamin
This set of patches, along with some other patches under
discussion on alkml, should enable omap3 and omap4 kernels to be
built with CONFIG_THUMB2_KERNEL.
This patch set builds on recent cleanup done by the omap
maintainers.
At least some of this code definitely works, most features have
been tested successfully. Further testing, especially of Thumb-2
behaviour, is still welcome.
In particular, I still have no Ack/Tested-by on the following
patches, so it would be great if anyone who has an opportunity
to do a final review / re-test can do so.
* ARM: omap3: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL
* ARM: omap3: Thumb-2 compatibility for sram34xx.S
* ARM: omap3: Thumb-2 compatibility for sleep34xx.S
Seems to work with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL
enabled on Beagle xM A2 and Panda A1.
Thanks also to Santosh Shilimkar and Kevin Hilman for their help
with testing so far.
v3:
* make SMC instruction syntax more consistent
* remove do_wfi() in favour of the generic wfi() macro
v4:
* revert to the OMAP-specific do_wfi() implementation, pending
discussion of how generic macros can/should be provided
v5:
* use ARM for low-level code in mach-omap2/*34xx.S, for
correct interoperation with non-Thumb-capable firmware.
I've stripped the Acked/Tested-bys from the major patches to
mach-omap2/*34xx.S, since the reversion to ARM constitutes a
significant change -- I would be grateful if people could re-
test / re-review if they have the chance.
For best future compatibility, I've left the changes which
avoid architecturally deprecated features.
Details below.
Cheers,
Dave
The patches can be found, along with a buildable working tree,
in the following repo:
git://git.linaro.org/people/dmart/linux-2.6-arm.git
* arm/omap-thumb2: has the patches proposed here
* arm/omap-thumb2+merged: additionally has some patches cherry-
picked from other trees which are needed in order for the
patches on arm/omap-thumb2 to work usefully.
* dirty/arm/omap-thumb2+merged: buildable test tree, which adds
2 local patches to work around a toolchain bug.
A working kernel config for this tree is here:
http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config :
CONFIG_SMP_ON_UP=y
CONFIG_THUMB2_KERNEL=y
CONFIG_SERIAL_OMAP=y (to avoid garbage on xM; for Panda use console=ttyS2)
(The config is derived from the linaro omap config and so turns on
loads of modules -- don't feel you have to build them all...)
Cherry-picked patches originated from Russell's devel tree
and Tony Lindgren's omap-testing tree:
http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git devel
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-testing
This series also depends on one un-merged patch to generic-ise
the wfi() macro:
git://git.linaro.org/people/dmart/linux-2.6-arm.git arm/wfi-macro
Dave Martin (5):
ARM: omap4: Provide do_wfi() for Thumb-2
ARM: omap4: Convert END() to ENDPROC() for correct linkage with
CONFIG_THUMB2_KERNEL
ARM: omap3: Remove hand-encoded SMC instructions
ARM: omap3: Thumb-2 compatibility for sram34xx.S
ARM: omap3: Thumb-2 compatibility for sleep34xx.S
arch/arm/mach-omap2/include/mach/omap4-common.h | 4 ++
arch/arm/mach-omap2/omap-headsmp.S | 2 +-
arch/arm/mach-omap2/omap44xx-smc.S | 8 ++--
arch/arm/mach-omap2/sleep34xx.S | 62 ++++++++++++++++++----
arch/arm/mach-omap2/sram34xx.S | 36 ++++++++++---
5 files changed, 87 insertions(+), 25 deletions(-)
The Linaro Toolchain Working Group is pleased to announce the release
of Linaro GDB 7.2.
Linaro GDB 7.2 2011.03-0 is the fourth release in the 7.2 series.
Based off the latest GDB 7.2, it includes ARM-focused bug fixes and
enhancements.
Interesting changes include:
* Hardware watchpoint support
* Backtracing while in the Linux kernel trampoline frame
Hardware watchpoints use the support built into ARM devices to watch
for changes in values in memory with little performance impact. A
2.6.37 or later kernel is required.
The source tarball is available at:
https://launchpad.net/gdb-linaro/+milestone/7.2-2011.03-0
More information on Linaro GDB is available at:
https://launchpad.net/gdb-linaro
-- Michael
The Linaro Toolchain Working Group is pleased to announce the release
of both Linaro GCC 4.5 and Linaro GCC 4.6.
Linaro GCC 4.5 is the eighth release in the 4.5 series. Based off the
latest GCC 4.5.2+svn170352, it includes many ARM-focused performance
improvements and bug fixes.
Interesting changes include:
* Adds a new 'shrink wrap' optimisation
* Improves performance by making better use of the LDM/STM instructions
* Fixes a segfault crash in Qt applications (LP: #705689)
* Fixes a mis-compilation in the SPEC2006 gromacs benchmark (LP: #693502)
* Fixes to the NEON intrinsics exposed through a NEON test suite (LP:
#710623, LP: #710652)
* Fixes an internal compiler error when tuning for XSCALE (LP: #721021)
* Fixes a problem with loading zero using a NEON conditional load (LP: #709453)
Shrink wrapping is an optimisation that delays writing out the prologue until it
is first needed. This helps functions that exit early by reducing the
amount of data pushed out to memory. It is enabled by default at -O1
and can be disabled using '-fno-shrink-wrap'.
Linaro GCC 4.6 is an alpha release of the upcoming 4.6 series, and is
intended for distributions or integrators who wish to start packaging
and testing the compiler early.
Note that no changes were made to Linaro GCC 4.4. 4.4-2010.02-0 stays
the current release.
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.5-2011.03-0
and
https://launchpad.net/gcc-linaro/+milestone/4.6-2011.03-0
Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro
-- Michael
Attached is a pdf with all the results of the buffer size testing on the
Beagle C4 and Panda. I think this pretty much conclusively shows that
increasing the buffer size when using timer based scheduling results in no
improvement in cpu wakes per second. I also went back and tested alsa 1.0.24
in the audio stack to enable the recently added check for period disable. I
appears that the beagle and panda do not have support, or it is not yet
enabled in the driver. Does anyone know if these boards have the ability to
turn off period wakes for the sound companion chips?
Kurt Taylor (irc krtaylor)
Hi,
Throughout Linaro we are looking at ways to better coordinate the
deliverables that come from Linaro's Working Groups and Platform teams.
The idea of Monthly Component releases, a fixed date in the month where
each team would release their latest work fits well with what we do and
to that end a wiki page proposing the exact dates has been produced at:
https://wiki.linaro.org/Releases/MonthlyMilestones
You will notice that the dates are fixed, always the third Thursday in
the month promoting a unified consistency across the teams. Please note
that the Linaro Ubuntu Evaluation Builds do not follow this schedule
and will continue to be closely coupled with the Ubuntu schedule.
Please take a look at the dates and highlight any problems that could
arise from them. If there is positive feedback we can make these dates
'official' very soon meaning teams could start using this format next
month.
Regards,
Jamie.
--
Linaro Release Manager | Platform Project Manager
== Wiki Work ==
* Started work on Wiki Tagging
* Update of https://wiki.linaro.org/Mentoring/KernelDeploy to describe
method for getting default linaro .config for kernel
* Began analyzing daily updates to wiki.l.o
* Expanding usage of CategoryHowTo
== Dev Work ==
* overo testing on alpha3
* investigating eth0 issue with Overo
== Vacation ==
* Took off Tuesday (Mar 1)
