* Discussion to generalize the maintenance process of kernel branches
> for the periodic Linaro releases. This still needs documenting in the
> wiki.
>
> * Merged a set of patches put together by Anand Gadiyar to add display
> support to the PandaBoard.
>
> * Merged the following additional patches:
>
> * d983450 cpufreq: Add documentation for sampling_down_factor
> * 054fcd5 ARM: S5P: Fix end address in memory resource information for UART devices
> * bf47520 ARM: make SWP emulation explicit on !CPU_USE_DOMAINS
> * 459967a ARM: fixup SMP alternatives in modules
> * 7144fbc ARM: 6654/1: perf/oprofile: fix off-by-one in stack check
> * 067dfdf ARM: 6659/1: Thumb-2: Make CONFIG_OABI_COMPAT depend on !CONFIG_THUMB2_KERNEL
> * cc0f308 ARM: 6656/1: hw_breakpoint: avoid UNPREDICTABLE behaviour when reading DBGDSCR
> * 40ef21c ARM: 6657/1: hw_breakpoint: fix ptrace breakpoint advertising on unsupported arch
> * 9e97118 ARM: ptrace: remove single-step emulation code
>
== Upstream oriented activities ==
* Review of Arnd Bergmann's flash card article for LWN.
* Incorporation of feedback to the patch adding Thumb2 support to the
P2V branch.
* Another look at the Thumb-2 compatibility fixes for OMAP from Dave
Martin.
* Review of a patch series adding support for SDHCI v3.00.
* Posted patches:
* Rework of the kernel decompressor code to improve efficiency
* Removal of the 4x expansion presumption while decompressing the kernel
* kprobes insn decoding fix
* Ignore mdesc->boot_params if out of range
* Fold lookup_machine_type() into setup_machine()
== Linaro kernel activities ==
* Looked at some bugs:
* Bug 660811
* Bug 720055
* Merged 2.6.37.1 into linaro-2.6.37
* Merged Dave Martin's Thumb2 compatibility patches for OMAP.
* Merged core ARM ffixes from RMK.
* Merged OMAP fixes from Tony Lindgren.
* Opened up the linaro-2.6.38 branch.
Nicolas
=== Highlights ===
* Did an IBM internal presentation on Android and how Linaro is helping
* Worked on my Kconfig talk for Linux Plumbers.
* Implemented the proposed config tooling for config fragments, as
discussed in my Kconfig talk.
* Did Beagle XM testing for the 11.08-rc Android Platform Images.
* Made final 11.08 linaro+android kernel, and managed to push it
properly through Gerrit
* Pinged Ingo about patches for 3.1 I sent to tglx, which haven't yet
been merged.
=== Plans ===
* On vacation until Linux Plumbers Conf. Will effectively be out for the
next two weeks.
=== Issues ===
* Number of patches queued for 3.1 still haven't been pulled into -tip
because of Thomas being offline. Concerned they might not make the 3.1
release while I'm out of town.
== Thomas Abraham <thomas-ab> ==
=== Highlights ===
* Submitted pl330 DMA driver device tree support patches for review.
* Samsung's uart irq handling patches that move irq handling from platform
code to driver is accepted in Greg's tty tree.
=== Plans ===
* Submit second version of pl330 DMA driver dt patches.
* Submit gpio and pinctrl dt support patches for Exynos4.
=== Misc ===
* Was on leave on 29th August.
=== Highlights ===
* Wrote kernel process overview for August member update
* Lots of 1:1s
* Complete reviews for IBM folks (Arnd, John)
* Started thinking about post 11.11 tasks
=== Plans for This Week ===
* 1:1s, regularly scheduled meetings
* Follow up with Nicolas P. on zImage consolidation task list
* Develop BPs and specs for kernel CI loop
=== Upcoming Travel/Time Off ===
* Linux Plumber's Conf Sept 7-9
* PTO Sept. 12th/13th, 26th/27th
* Tentative travel to ELC-E/LinuxCon-E Oct 26-28
* Linaro Connect Oct 31st - Nov 4
== Per Forlin <perfor> ==
=== Highlights ===
* Started work on kexec for snowball, large block size and upgrade
snowball u-boot patches to 2011-v6.
=== Completed work items ===
none this week
=== Plans ===
* bug fixing dma and mmc in linux 3.1
* wrap up kexec and u-boot upgrade for snowball
* only 7 days left in Linaro, 2 days in week 35 and 5 days in week 37
=== Device Tree ===
* Brought up i.mx6q SMP support
* Added the support of ARM Dormant/Shutdown mode on i.mx6q
* A v3.1-rc2 and device tree based kernel is running on i.mx6q
=== Plan ===
* Sort the clock code out and start submitting i.mx6q series
--
Regards,
Shawn
=== Highlights ===
* Posted a patch to fix jprobes on Thumb kernels then realised that
this was insufficient. There is a more basic problem with thumb symbol
lookup which needs resolving.
* Finished preparing and posted kprobes test code to the
linux-arm-kernel list.
* Improved my flash performance use case an simulation programs to
provide details of timings so that simulation accuracy can be more
easily judged.
* Ran more combinations of flash performance use cases.
* Single zImage work: The patches "Remove define CONSISTENT_DMA_SIZE"
were pulled by RMK for inclusion in Linux 3.2.
=== Plans ===
* Write up current results for flash performance investigation.
* On holiday Sept 2nd, start new job in Linaro after that.
=== Issues ===
* I don't know if I will have enough time to resolve the thumb symbol
lookup issue.
* If kprobes test code doesn't get accepted into mainline kernel then
we need to find another home for it.
== Linus Walleij linusw ==
=== Highlights ===
* Pushed out v5 of the pinctrl/pinmux subsystem:
http://marc.info/?l=linux-arm-kernel&m=131460922230406&w=2
addressed numerous review comments and likely creating new
noise, there is no end to the fun :-D
* Russell merged the bulk of gpio.h cleanup patches from
Linaro Connect, iterating the remaining pieces that collide
with other subtrees.
* Put PrimeCell magic consolidation patch into Russells
tracker for consideration.
* Got new ARM Integrator core modules from Philippe at
ARM - now I can test and maintain Integrator a bit more.
* Discussed a standardized secure world interface following
Russells remark that this is very needed, send off a
suggestion to Rusling to poke the ARM Global Platform
assignees and the TSC about doing something about this
through Global Platform.
=== Plans ===
* v6 iteration of the pinctrl + pinmux subsystem
* Third round around the gpio.h cleanups.
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Drive generalization of U300 and Nomadik GPIO
* Get into struct clk generalization and movement of clk
drivers into drivers/clk - handover from Jeremy Kerr.
We will do this in Cambridge or something like that.
* Watch the DBx500 PRCMU drivers update
=== Issues ===
* Shanghaiied for internal advisory at ST-Ericsson for
say 25% of working hours last week.
Thanks,
Linus Walleij
== Highlights ==
* i.MX code clean up and consolidation: patch-set has been merged to
soc tree through Sascha pull request.
Jason Liu (6):
ARM: mx25: Print silicon revision on boot
ARM: mx27: Print silicon revision on boot
ARM: mx31: use generic function for displaying silicon revision
ARM: mx35: use generic function for displaying silicon revision
ARM: mx5: use generic function for displaying silicon revision
ARM: i.MX: initialize l2x0 at early_init time
* The following patch-set has been send out for review:
Jason Liu (2):
ARM: i.MX5/mm: Consolidate arch/arm/mach-mx5/mm-*.c
ARM: i.MX5/mm: use static mapping for TZIC
* MTD core bug fix: https://lkml.org/lkml/2011/8/24/143
== Plan ==
* 11.11 task
* 1:1 with Deepak
* uboot upstream
* kernel upstream
Best Regards,
Jason Liu
== Manjunath GK <manjugk> ==
=== Highlights ===
* Reworked OMAP DT patches and posted to DTML
http://comments.gmane.org/gmane.linux.ports.arm.omap/62300
* DT adaptation for OMAP4 i2c driver
- dt support jas been added for omap4panda
=== Plans ===
* Followup review comments in the mailing lists and align on further
changes/proposals.
* Convert remaining i2c controller and it's child devices to dt model
- dt framework does not attach platform_data in i2c_probe. Need to
align with grant.
* Updating blueprint as per alignment and according to on going work items.
===Leave plans===
* on leave 29th and 30th aug 2011
-Manjunath
=== Highlights ===
* Trying to decipher algorithms used by SD cards. (Turns out Arnd had
already documented some SanDisk peculiarities which probably explains
a lot of what I was seeing [1])
* Re-running SD media usecases and benchmarks after is became apparent
that the initial btrfs results were bogus due to environment and
scripting bugs.
* Documented kprobes test code in preparation for publishing.
* Discovered that jprobes no longer work on Thumb kernels. This seems to
be a new or previously overlooked bug with symbol lookup. Needs
investigating...
* Buying and setting up a new laptop ready for when I officially start
working for Linaro.
=== Plans ===
* Make some SD card performance results available, even if they are
negative results.
* Single zImage work: Submit patches "Remove define CONSISTENT_DMA_SIZE"
to appropriate branch.
[1] Section "Mixed SLC/MLC flashes" in https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey?actio…
=== Device Tree ===
* The updated "alias" patch is waiting for Grant's comment/ack
* Keeping monitoring the pinmux DT patches from Stephen Warren and
Jamie Iles, as I have the same issue in the way of converting non-dt
board files to dt.
* Got one i.mx6q board. Started adding DT support for it as well as
trying to get the initial support for this new SoC upstreamed.
Right now, I have got a v3.1-rc2 based device tree kernel running
into console with nfs root on this board. But there are still some
codes I need to rework before I can post the patches, especially on
clock support.
=== Misc ===
* The imx mach/gpio.h cleanup patch set was picked by Sascha.
* Refactor the ifdeffery of i.mx DEBUG_LL support based on Kconfig choice patch from Will Deacon.
=== Plan ===
* i.MX6Q upstreaming with device tree support
--
Regards,
Shawn
== Dave Martin <dmart> ==
=== Activity Summary ===
* vexpress device tree: got a booting kernel (with some hacks)
platform devices are now populated from the device tree, but IRQ
assignments are all messed up -- I need to discuss with Lorenzo
about this.
* v6/v7 single kernel Thumb-2 undef fixup patches accepted by
Russell for v3.2 window.
* Some time spent supporting local people using linaro deliverables.
=== Plans ===
* fix, tidy up vexpress dt patches
* Write up brief advice for Thumb-2 kernel migration.
* Write up detailed proposal for assembler state save/restore.
* Check whether the new kernel trees work in Thumb-2 on mx51evk and
follow up with Freescale landing team.
=== Work Items ===
no status change
=== Absences ===
probable absence of ~3 days around the start of September
== Thomas Abraham <thomas-ab> ==
=== Highlights ===
* Working on dt support for dma driver.
=== Plans ===
* Submit dt support patches for dma driver.
=== Misc ===
* Was on leave from 17th to 19th August.
== Jason Liu <jasnliu> ==
== Highlights ==
* MX53 NAND driver support, done, patches send out to mtd ML, driver
patch accepted by Artem to l2-mtd-2.6.git
* MX53 EVK NAND support, done, patches send out linux-arm ML, this
patch-set is blocked by DT support. I will
re-submit it with DT support after current board level DT convert finished.
* Post arch/arm/mach-mx5/mm: clean and consolidate patchset to linux-arm ML.
* watch the discussion for the DEBUG_LL and uart setting for
uncompress on linux-arm ML.
* review and test i.mx5 u-boot patches of ML:u-boot@lists.denx.de
== Plan ==
* 11.11 task
* uboot upstream
* kernel upstream
Best Regards,
Jason Liu
== Per Forlin <perfor> ==
=== Highlights ===
* This week (only 3 days), finishing up the last patches on MMC and USB BPs.
* The USB mass storage patch about having variable number of
pipeline buffers is queued for 3.2.
[PATCH v5] usb: gadget: storage: make FSG_NUM_BUFFERS variable size
* Fault injection for MMC is queued for 3.2
[PATCH v9 0/3] mmc: make fault injection available for MMC IO
* Started to work on
https://blueprints.edge.launchpad.net/linux-linaro/+spec/vfs-larger-than-4k…
first step is to study the current implementation and
infrastructure in block layer and vfs
=== Completed work items ===
The following two BPs are done, some patches are merged for 3.1 and
the rest will be in 3.2.
* https://blueprints.edge.launchpad.net/linux-linaro/+spec/usb-gadget-mass-st…
* https://blueprints.edge.launchpad.net/linux-linaro/+spec/mmc-async-request
=== Plans ===
Prio 1. Start on large block size support
Prio 2. kexec for Snowball
== Linus Walleij linusw ==
=== Highlights ===
* Pushed out v4 of the pinctrl/pinmux subsystem:
http://marc.info/?l=linux-arm-kernel&m=131374768302199&w=2
Now iterating review comments for v5, one big outstanding
item to fix before Steven Warren from nvidia is happy so
focus is on that right now.
* Put the gpio.h cleanup patches from Linaro connect into
Russell's patch tracker after OK from Grant, awaiting
Russell's feedback.
* Consolidated some PrimeCell magic, as I was pretty tired
of seeing this pattern repeating itself.
http://marc.info/?l=linux-arm-kernel&m=131365435714431&w=2
* Talked to ARM about obtaining some more core modules for
the ARM Integrator - seems to be on its way!
=== Plans ===
* v5 iteration of the pinctrl + pinmux subsystem
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Drive generalization of U300 and Nomadik GPIO
* Get into struct clk generalization and movement of clk
drivers into drivers/clk - handover from Jeremy Kerr.
We will do this in Cambridge or something like that.
* Watch the DBx500 PRCMU drivers update
=== Issues ===
* Shanghaiied for some internal conflict resolution
at ST-Ericsson and weekend review of internal patches.
Not too much though. Also a lot of internal mail
and oral advisory going on.
Thanks,
Linus Walleij
=== Highlights ===
* Attended LinuxCon:
- Good forward movement on long term support kernel. GregKH presented his
proposal for the community supported LTS and the LF Consumer Electronics
Working Group presented their plans to build an industry driven LTS on top
of that. I will be in contact with the CEWG to understand how we can stay
in the loop. Follow up meeting is planned for ELC-E in Prague. Met
with GregKH
along with David R. and Grant L. to talk about getting ARM bits
into the loop for
-stable and -longterm.
- Good mention of Linaro on several occasions, including by Linus.
=== Plans for This Week ===
* Catch up email/wiki updates/etc after 3 weeks of travel & time off
* Complete reviews for IBM folks
* Start preparing ARM queue for next 3.0.x stable release. First pass
will be very
limited number of patches to keep my sanity.
* 1:1s
* Follow up with Nicolas P. on zImage consolidation task list
=== Upcoming Travel/Time Off ===
* Linux Plumber's Conf Sept 7-9
* PTO Sept. 12th/13th, 26th/27th
* Tentative travel to ELC-E/LinuxCon-E Oct 26-28
* Linaro Connect Oct 31st - Nov 4
=== Highlights ===
* Effort merging Android patches (specifically timer related) was noted
during the Linux Con chat between Linus and Greg.
* Merged 11.08 Linaro kernel into Linaro+Android tree
* Tested, tagged, and released linux-linaro-3.0-2011.08-0-android-0 &
linux-linaro-3.0-2011.08-0-android-1 kernels.
* Worked on internal presentation
* Worked on Kconfig fragment talk for LPC
* Did beagle xm testing for Android 11.08 release. Ran into some issues
with 0xbench not completing.
* Helped diagnose some community RTC issues
=== Plans ===
* Continue to work on LPC talk for the majority of next week.
=== Issues ===
* Still need to sort out internal gerrit process for linaro+android
kernel (I still can't push to gerrit without requiring each change to be
reviewed by two people, which won't work).
== Manjunath GK <manjugk> ==
=== Highlights ===
* Alignment for DT-HWMOD hook at linaro-connect
- Temparory solution to have DT-HWMOD hook is aligned and changes
are tested successfully at linaro-connect
* DT adaptation for OMAP i2c driver
- With DT-HWMOD hook, i2c-omap driver is converted to use DT
* RFC patches posted to mailing lists with DT-HWMOD changes
- Discussion is in progress in the mailing lists
=== Plans ===
* Followup review comments in the mailing lists and align on further
changes/proposals.
* Convert remaining i2c controller and it's child devices to dt model
* Add dt support for panda board
-Manjunath
== Jason Liu <jasnliu> ==
== Highlights ==
* MX53 NAND driver support, done, patches send out to mtd ML
* MX53 EVK NAND support, done, patches send out linux-arm ML, but it
more likely be postponed due to DT support for i.MX
* Linaro i.mx u-boot bug analysis and fix.
== Plan ==
* 11.11 task
* uboot upstream
* kernel upstream
Best Regards,
Jason Liu
== Thomas Abraham <thomas-ab> ==
=== Highlights ===
* Submitted patches to move uart irq handling from platform code to
uart driver for Samsung platforms. This was required to simplify
adding device tree support to uart driver.
* Submitted another proposal for adding device tree support for Exynos
GPIO and PinMux modules. (Most of the Exynos4 drivers perform gpio and
pinmux setup in the probe function by calling a platform specific
callback function listed in the platform data of the driver. So until
the dt support for gpio and pinctrl are finalized, I will continue
adding dt support to drivers utilizing the auxdata feature to populate
the platform data with callback for gpio and pinmux setup).
* Started looking into dt support for dma driver.
=== Plans ===
* Submit dt support patches for dma driver.
=== Misc ===
* Will be on leave on 17th, 18th and 19th August.
=== Device Tree ===
* Repost "alias" support patch to get both flat-tree and prom-tree
supported, so that it will not break SPARC architecture.
* Had seen another two custom pinmux bindings for Tegra and Exynos,
and the common register-value pair binding will probably make less
sense, so will keep purchasing iomuxc binding I have proposed.
* Per request from Freescale Landing team, published a imx51/53 DT
support tree on git.linaro.org, so that they can starting playing
more DT support on drivers.
=== Misc ===
* Posted a patch series to clean up imx (mxc & mxs) mach/gpio.h to
empty headers, and wait for a global removal from asm/gpio.h.
This is one step to single-image.
* Ran a i.mx53 quick start demo on APM (ARM Parter Meeting?)
* Flight back from UK
--
Regards,
Shawn
=== Highlights ===
* Merged basic Origen enablement patch into the linaro+android tree
* Worked with Mathieu Poirier to get familiar with my new Origen board
and managed to get a working defconfig for the Origen board committed to
the linaro+android tree (serial console functionality, only).
* Did a very rough first draft on Kconfig Fragments talk for LPC
* Got Linaro Connect expenses submitted
* Merged a number of RTC fixes from lkml into my dev tree and submitted
them for 3.1
* Did a major rework of the Alarm Timers internal code to address
comments from the Android developers. Submitted some smaller fixes for
3.1 and queued the rest of the rework for 3.2
* Made the omap3, omap4 and origen android defconfigs consistent.
* Merged fixes for beagle xm revC usb bug from 3.1-rc1 (bug #825343).
Big thanks to Jassi for pointing out the fix!
* Updated the Linaro+Android tree, and made the initial pre-release for
11.08
* Worked with Paul Sokolovsky to push the Linaro+Android tree through
gerrit. There are still some kinks to work out, but its getting there.
=== Plans ===
* Lots more focus on Kconfig presentation. I'm likely going to try to
put the boards away and avoid doing anything else.
=== Issues ===
* N/A
== Dave Martin <dmart> ==
=== Activity Summary ===
* Linaro Connect and ARM Partner Meeting consumed much of the last two weeks
* Main output from Linaro Connect was some progress on vexpress
device tree support (with much help from Lorenzo Pieralisi and Grant
Likely). I have a kernel _building_ now, but I still need to test it,
and write the Makefile rules properly.
* Alignment fault fixup mode patches now merged by Russell for the
3.2 window. If these are included in linux-linaro we will be able to
find and resolve outstanding problems by booting with e.g. alignment=5
on the kernel command-line.
* Posted patches to fix multiplatform kernels for Thumb-2 userspace.
This issue can affect any single kernel image which contains both v6
and v7 support, when running Thumb-2 userspace containing VFP
instructions (i.e., Linaro filesystems fail with a torrent of
SIGILLs). Some rework is needed, but no major objections received so
far.
* Posted a suggestion on the binutils list about a more generic way
to save/restore the assembler state during assembly. Some positive
feedback received; I will draft a more detailed proposal for review.
For now it's just an RFC, and I haven't committed to spending real
time on it.
=== Plans ===
* Test new vexpress devicetree patches, rework and post.
* Rework and repost multiplatform Thumb-2 undef handling patches.
* Write up brief advice for Thumb-2 kernel migration.
* Write up detailed proposal for assembler state save/restore.
* Check whether the new kernel trees work in Thumb-2 on mx51evk and
follow up with Freescale landing team.
* Suggest we disable aligment fixups for linaro images, since
gtk-sharp2 is now the only thing known to be affected, once my
alignment fixup patchas have been posted for review.
=== Work Items ===
no status change
=== Absences ===
probable absence of ~3 days around the start of September
=== Highlights ===
* Posted "Remove define CONSISTENT_DMA_SIZE" patch series to
linux-arm-kernel for review. This was part of the 'single zImage' work
done at Linaro Connect in the previous week.
* As part of the work for blueprint "Investigate block allocation in FS"
wrote program to issue writes to SD in various sequences to try and
get a handle on algorithms used by SD cards. (Seems to be not as
simple as we assume.)
* Spent time on tasks in preparation for officially starting work at
Linaro in September.
=== Plans ===
* Modify flash simulation program to match real SD cards performance (or
give up trying to match 'difficult' algorithms.)
* Run flash media use cases with different ext4 options.
(I'm using my new Linaro email address to post this weeks summary to see
if I've managed to subvert GMail's broken handling of mailing lists, see
http://mail.google.com/support/bin/answer.py?answer=6588)
== Linus Walleij linusw ==
=== Highlights ===
* Rebased the gpio.h cleanups from Linaro connect on top of
Russells gpio.h cleanup patchset and mailed it out:
http://marc.info/?l=linux-arm-kernel&m=131297866928334&w=2
* Submitted an update of the DBx500 PRCMU drivers
carved out from the internal ST-Ericsson 3.0-based git:
http://marc.info/?l=linux-kernel&m=131313768415616&w=2
* RealView PB11MPCore, TCM support and TCM fixes
merged for 3.1
http://marc.info/?l=linux-arm-kernel&m=130944303522448&w=2http://marc.info/?l=linux-arm-kernel&m=130944291922298&w=2http://marc.info/?l=linux-arm-kernel&m=130944294622342&w=2
* I now have a working Integrator AP setup, also sent two
patches for it:
http://marc.info/?l=linux-arm-kernel&m=131037711822519&w=2http://marc.info/?l=linux-arm-kernel&m=131189136402449&w=2
First patch merged for v3.1-rc1 through Arnds tree
* DMA40 patches merged for 3.1
http://marc.info/?l=linux-kernel&m=130916853306730&w=2
* Fix to RMI4 staging driver merged for 3.1
http://marc.info/?l=linux-kernel&m=130941558024742&w=2
* Fixed a PL022 bug reported by Russell King, merged for 3.1.
* Reviewed David Browns patches for moving and refactoring
the qualcomm GPIO drivers.
* Various upstreamed patches for AB8500, STMPE, MMCI...
* Reviewed Viresh Kumar's patches to the PL08x DMA
driver.
* Reviewed Samsungs patches to the PL08x DMA driver.
* Discussed pinmux/pinctrl subsystem at Linaro Connect,
not much to say about it, input was that the number space
for each pinmux controller need to be local to the controller
and we should avoid a global numberspace.
=== Plans ===
* New iteration of the pinctrl + pinmux subsystem
* Finalize the gpio.h cleanups
* Drive generalization of U300 and Nomadik GPIO
* Get into struct clk generalization and movement of clk
drivers into drivers/clk - handover from Jeremy Kerr.
We will do this in Cambridge or something like that.
=== Issues ===
* GPIO pincontrol aspects stalled on the mailing list,
who cares, directing my attention elsewhere FTM.
* Shanghaiied for some internal conflict resolution
at ST-Ericsson. Not too much though.
Thanks,
Linus Walleij
Hi all,
I wanted to provide an update of what the kernel team accomplished at
Linaro Connect last week for those who were unable to attend.
The team was split into two main groups, the first being led by Grant
Likely and focusing on continuing the work on enabling Device Tree
support on ARM platforms. In addition to Linaro members, David Brown
and Nicolas Ferre also worked on DT support for their platforms
and all together the team got much accomplished in 5 days there
with a number of patches ready for the 3.2 merge windows:
* Several device drivers for the Freescale iMX were converted
to use DT-base discovery.
* Code was written to bridge between the Device Tree model and
TI OMAP's HWMOD.
* Initial support for DT was added to the Samsung Exynos, Qualcomm MSM86,
and Atmel AT91 by Nicolas Ferre
* DT skeleton code was written for the ARM Versatile and ST-E platforms.
The rest of the team primarilly focused on code cleanup and development
to work towards a multi-SOC zImage. Nicolas posted and original
email with info at http://bit.ly/oVQRQm and folks took individual
bits to work on. Russel King was also in attendance and there was
good discussion around some of these topics. What we discovered
is that many of these issues are multi-layered and as we start
cleaning up one bit of code, we need to fix other areas to make
them work consistently. The areas we looked into were:
* Replacing low level IO accessor macros with runtime selected functions
based on platform type.
* Replacing the global NR_IRQS constant with per-board information
* Removing duplicated low-level serial output functions. Currently the
code to print "Uncompressing kernel..." and the code for low-level
in-kernel serial output are completely different but could be made
to be the same. At the end of the day, the method we're looking
at using is providing a special node in the DT that contains the
physical mapping of the debug serial registers in place.
* Removing CLOCK_TICK_RATE from the kernel
* Replace CONSISTENT_DMA_SIZE with a runtime variable
* Removing arch_idle() and moving to using the run time
selected pm_idle hooks. Similar work to be done with
arch_reset()
* Getting rid of VMALLOC_END. Russel and Nicolas agreed
that we'll just use a static VMALLOC_END for everyone
and insert static I/O mappings in there.
In addition the the above work, KWG members also were involved in
discussions about continuous integration and testing of the upstream
kernels on ARM platforms, kernel development process at Linaro and
how to better stay in sync with upstream, -stable patches for ARM
platforms, Android development, and flash storage roadmap to name a few.
Overall, the team had an extremely productive week of hacking on existing
projects and on coming up with more detailed plans on what other items
on which we need to focus.
I want to thank everone on the team for their hard work last week
and also the non-Linaro developers David Brown, Will Deacon, Nicolas
Ferre, and Marc Zyngier for taking time to join us in hacking and planning.
All together connect was a great technically focused event and I highly
encourage folks to join us in Orlando in November. You can register now
at http://connect.linaro.org/events/event/linaro-connect-q411/.
Thanks,
~Deepak
== Per Forlin <perfor> ==
=== Highlights ===
* Sent out patches to improve performance in usb gadget mass storage
* https://lkml.org/lkml/2011/8/8/107
* https://lkml.org/lkml/2011/8/8/411
* It's not necessary to make any further optimizations in the usb
gadget buffer pipeline form a throughput point of view.
=== Completed work items ===
* https://blueprints.edge.launchpad.net/linux-linaro/+spec/usb-gadget-mass-st…
* Run tests and analysis to identify performance issues in usb
gadget mass storage: DONE
* Implementation will be broken down and added here when the design
decision is made: DONE
* Make the number of gadget pipeline buffers variable: DONE
=== Plans ===
* Leaving for vacation today (Aug 10) back again Aug 17.
* Update design and status on my storage BPs.
== Jason Liu <jasnliu> ==
== Highlights ==
* Attended Linaro Q3 connect, has some good discussion for:
the 11.11 task assignment and one zImage support,
* Uboot patch review, one imx5 patch upstream, accepted.
* 2 kernel patch upstream, one is accepted and one is waiting for feedback.
== Plan ==
* 11.11 task
* uboot upstream
* kernel upstream
Best Regards,
Jason Liu
== Deepak Saxena <dsaxena> ==
== Highlights ==
* Attended Linaro connect, had lots of good discussions re:
- Kernel process
- Testing
- Storage work direction
- Future KWG work
* Wrote code, posted patches!
== Upcoming Travel/Holiday ==
* Off this friday
* At Linuxcon next Tue - Friday
* Linux Plumber's Conf first week of september
To everyone, and especially to those who are expected to work on this
topic next week, please find below a list of tasks that needs to be
investigated and/or accomplished. I'll coordinate the work and collect
patches for the team.
If you have comments on this, or if you know about some omissions,
please feel free to provide them as a reply to this message.
I'd like to know if people are particularly interested in one (or more :-))
items they would like to work on. If so please say so as well.
Without further ado, here it is:
<><><><><>
0) The so called "single zImage" project
We wish to provide the ability to build as many ARM platforms as
possible into a single kernel binary image. This will greatly simplify
the archive packaging and maintenance effort by having only one kernel
that could be built and booted on multiple ARM targets. A side effect
of this is also to enforce better source code architecture even if the
resulting binaries are not always supporting multiple targets.
This work started a while ago. Some initial description can be found
here:
https://wiki.ubuntu.com/Specs/ARMSingleKernel
Part of it has been implemented already, namely the runtime determined
PHYS_OFFSET, the AUTO_ZRELADDR and some other items referenced below.
But there is still a large amount of work remaining.
1) Removal of any dependencies on <mach/*.h> from generic header files
To see the current culprits:
$ git grep "#include <mach/.*.h>" arch/arm/include/
arch/arm/include/asm/clkdev.h:#include <mach/clkdev.h>
arch/arm/include/asm/dma.h:#include <mach/isa-dma.h>
arch/arm/include/asm/floppy.h:#include <mach/floppy.h>
arch/arm/include/asm/gpio.h:#include <mach/gpio.h>
arch/arm/include/asm/hardware/dec21285.h:#include <mach/hardware.h>
arch/arm/include/asm/hardware/iop3xx-adma.h:#include <mach/hardware.h>
arch/arm/include/asm/hardware/iop3xx-gpio.h:#include <mach/hardware.h>
arch/arm/include/asm/hardware/sa1111.h:#include <mach/bitfield.h>
arch/arm/include/asm/io.h:#include <mach/io.h>
arch/arm/include/asm/irq.h:#include <mach/irqs.h>
arch/arm/include/asm/mc146818rtc.h:#include <mach/irqs.h>
arch/arm/include/asm/memory.h:#include <mach/memory.h>
arch/arm/include/asm/mtd-xip.h:#include <mach/mtd-xip.h>
arch/arm/include/asm/pci.h:#include <mach/hardware.h> /* for PCIBIOS_MIN_* */
arch/arm/include/asm/pgtable.h:#include <mach/vmalloc.h>
arch/arm/include/asm/system.h:#include <mach/barriers.h>
arch/arm/include/asm/timex.h:#include <mach/timex.h>
arch/arm/include/asm/vga.h:#include <mach/hardware.h>
1.1) mach/memory.h
This may contain the following defines:
1.1.1) ARM_DMA_ZONE_SIZE
This can be eliminated by moving that value into struct machine_desc.
The work is done already, but presented as an example for other tasks:
http://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=refs/head…
And as of now this is merged in mainline already for v3.1-rc1.
1.1.2) PLAT_PHYS_OFFSET
Most occurrences can be eliminated. With CONFIG_ARM_PATCH_PHYS_VIRT, it
is possible to determine PHYS_OFFSET at run time. Remains to remove the
direct uses, mostly by mdesc->boot_params initializers. Changing
boot_params into atag_offset has two effects: that makes it clearer that
it is only about ATAGs and not DT, and a relative offset plays more
nicely with a runtime determined PHYS_OFFSET.
This work is done but not yet accepted:
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=123480
1.1.3) FLUSH_BASE, FLUSH_BASE_PHYS, FLUSH_BASE_MINICACHE, UNCACHEABLE_ADDR
Those are StrongARM related constants, and different for each variants.
Fixing this involves making the virtual addresses constant for all
variants, and hiding the differences in the physical addresses during
the actual mapping.
The solution is here:
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=123477/forc…
1.1.4) CONSISTENT_DMA_SIZE
Maybe the CMA work will make this obsolete and the consistent DMA area
could be dynamically adjusted. In the mean time, the easiest solution
is probably to store this in the machine_desc structure just like with
ARM_DMA_ZONE_SIZE.
This has not been addressed yet.
1.1.5) Other weird things
Some machines have non linear memory maps or bus address translations,
sparsemem, etc. Examples of that are:
arch/arm/mach-realview/include/mach/memory.h
arch/arm/mach-integrator/include/mach/memory.h
I think solving this is out of scope for this round. Deleting
arch/arm/mach-*/include/mach/memory.h can't be done universally. So a
new Kconfig symbol (NO_MACH_MEMORY_H) is introduced to indicate which
machine class has its legacy <mach/memory.h> file removed. The single
zImage for multiple targets will be restricted, amongst other things, to
those machines or SOCs with that symbol selected. Partial result here:
http://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=refs/head…
1.2) mach/io.h
This contains things like IO_SPACE_LIMIT, __io(), __mem_pci(), and
sometimes __arch_ioremap()/__arch_unmap(). but in most cases, the
definitions here are pretty similar from one machine class to another.
Arnd says:
|I have a plan. When CONFIG_PCI is disabled (along with CONFIG_ISA and
|CONFIG_PCMCIA), we should have neither of IO_SPACE_LIMIT, __io()
|and get no inb/outb functions as a result.
|
|When it is enabled, the 'common' platforms need only one I/O window
|of 64KB, so we should find a common place in the virtual address space
|for that and hardcode __io, while the platform specific PCI initialization
|code (or map_io for that matter) ensures that the window is pointing
|to the physical window.
|
|__arch_ioremap()/__arch_unmap() are not really needed as far as I can
|tell but are used as an optimization to redirect ioremap to the
|hardcoded virtal address mapping. In the first step we can disable
|this for combined kernels, later we can find a generic way so
|__arch_ioremap walks the list of static mappings.
1.3) mach/timex.h
Most instances simply define a dummy CLOCK_TICK_RATE value. This can
probably be removed altogether, or simply have a common value in
arch/arm/include/asm/timex.h, as nothing seriously uses that anymore.
Reference: http://lkml.org/lkml/2011/2/21/323
1.4) mach/vmalloc.h
This universally contains only a definition for VMALLOC_END, but not an
universal definition. Would be nice to have VMALLOC_eND dynamically
determined from the static IO mappings, but the highmem threshold
depends on the value of VMALLOC_END, and memory has to be initialized
before the static IO mappings can be processed.
Therefore the best solution so far appears to use another value in
struct machine_desc for it so it can be set at run time. this is a
mechanical conversion that has to be done.
1.5) mach/irqs.h
The only information globally required from those files is the value of
NR_IRQS. Yet there is already a nr_irqs member in the machine_desc
structure for this, used by arch_probe_nr_irqs() in
arch/arm/kernel/irq.c).
So the first step would be to add
.nr_irqs = NR_IRQS,
to all machine_desc instances, making sure that <mach/irqs.h> is
included in those files. Then, <mach/irqs.h> should be removed from
arch/arm/include/asm/irq.h, and adjust things so everything still
compiles.
1.6) mach/gpio.h
This is a tough one. This depends on CONFIG_GENERIC_GPIO which is
selected by many machine types. They should all be converted to (or
configurable with) CONFIG_GPIOLIB so each SOC's specific GPIO handling
is made into runtime code instead of static inline functions. Care to
preserve the ability to not use gpiolib might be desireable in some
cases for performance reasons.
Definitely in need of serious investigation.
1.7) mach/mtd-xip.h
No need to care about those. This is for running the kernel XIP from
ROM memory. A XIP kernel is already incompatible with the notion of a
single kernel image since it obviously can't be modified at run time (as
needed by CONFIG_ARM_PATCH_PHYS_VIRT).
1.8) mach/isa-dma.h, mach/floppy.h
Those are used by old targets we might not care much about.
1.9) mach/entry-macro.S
This one gets included directly from arch/arm/kernel/entry-armv.S.
The only relevant macro still widely used is get_irqnr_preamble and
get_irqnr_and_base. They can be overridden by CONFIG_MULTI_IRQ_HANDLER
and the equivalent code hooked to the handle_irq member of the
machine_desc structure.
1.10) mach/debug-macro.S
This is used when CONFIG_DEBUG_LL is set. Supporting that option with a
single kernel image might prove very difficult with a rapidly
diminishing return on the investment.
This code is in need of some refactoring already:
http://article.gmane.org/gmane.linux.ports.arm.kernel/118525
To still benefit from the most likely needed debugging aid, we might
consider the ability to still allow the selection of one amongst the
existing implementation when building a kernel with many SOC support.
Obviously that would only work on the one hardware platform for which the selected printch implementation was
designed, but that should be good enough for debugging purposes.
1.11) mach/system.h
This is included from arch/arm/kernel/process.c and expected to provide
the following static inline functions or equivalent:
1.11.1) arch_idle()
Called when system is idle. Most of them just call cpu_do_idle().
The call to cpu_do_idle() should be moved to default_idle() and the exception
cases moved out of line where they can be hooked to the pm_idle callback.
1.11.2) arch_reset()
Used to reset the system. This is far from being a hot path and doesn't
justify a static inline function. An out-of-line version hooked to a
global arch_reset function pointer would work just fine.
1.12) mach/uncompress.h
This is used to define per SOC methods to output some progress feedback
from the kernel decompressor over a serial port. Once again, supporting
this with a single kernel image might prove very difficult with a
rapidly diminishing return on the investment. So it is probably best to
simply use generic empty stubs whenever more than one SOC family is
configured in a common kernel image.
2) Removal of any dependencies on <mach/*.h> from driver code
A couple possibilities:
a) We move the required header files next to the driver code. In many
cases, having a .h file with only the defines relevant to the concerned
driver is best. But this is a _lot_ of work.
b) We change those <mach/foo.h> into something more absolute, such as
<mach/omap2/foo.h>. This can be done on a per SOC basis, first by
moving the header files one level deeper, and then fixing up all
affected drivers.
c) We change those <mach/foo.h> files into something more precise, e.g.
<mach/omap2_foo.h> and fix concerned drivers.
I think the best solution here is (b) which doesn't preclude (a)
eventually or if it is trivial. But (c) is dangerous as files might be
added easily without paying too much attention to the file prefix.
3) Change thes to the build system
We need to move towards the ability to actually build more than one SOC
family at the same time.
3.1) Kconfig
This involves changes to Kconfig where currently only one out of all the
different architectures is selected through the big "ARM system type"
choice prompt. We need to determine a good way to move some of them
into simply bool prompts and keep track of which architecture can be
built concurrently with which. We know for instance that it is unlikely
that pre-ARMv6 and ARMv6/7 will ever be buildable together. Today we
know that nothing can be built with anything else and therefore this
should be the starting default. This needs investigating.
3.2) Makefile
Currently the arch/arm/Makefile is organized so the lowest instruction
set level and the highest optimization level are selected from all the
configured options. So this part should already be fine.
However the machine-$(*), plat-$(*), machdirs and platdirs variables
must go. In (2) above we should have removed the need for adding to the
global KBUILD_CPPFLAGS to add a path to some specific architecture
includes already. Keeping them only for the code under each
architecture subdirectory should be sufficient.
For example, this might be all that is needed:
obj-$(CONFIG_ARCH_MSM) += mach-msm/
or
obj-$(CONFIG_ARCH_KIRKWOOD) += mach-kirkwood/ plat-orion/
obj-$(CONFIG_ARCH_ORION5X) += mach-orion5x/ plat-orion/
Etc.
And within each of these directories, using the subdir-ccflags-y
variable to include the locally needed architecture specific include
files will do the trick.
3.3) defconfig
We need a defconfig file adding as many architectures to it as possible
for build coverage. Ideally the resulting binary should be boot tested
on as many targets it supports as possible.
4) Picking up broken pieces
Things will certainly break along the way. There are certainly issues
that I didn't foresee. My experience so far tend to indicate that
this is a somewhat recursive process where the tackling of one work item
reveals a few more which are prerequisite to the first one, etc. So any
estimate for this work needs to consider a large fudge factor.
Nicolas
== Per Forlin <perfor> ==
=== Highlights ===
* CAtching up after 4 weeks of vacation and parental leave
* mmc non-blocking and mmc -non-blocking documentation are now
available in linux-next.
* mmc fault injection got pulled out from linux-next because it
couldn't be compiled as a module.
* Send out patches on fault-injection lib to export symbols.
* Fix some minor USB issues concerning gadget mass storage on Snowball.
* Run performance tests on Snowball to identify performance issues in
usb gadget mass storage framework. (None obvious found so far)
=== Completed work items ===
* https://blueprints.edge.launchpad.net/linux-linaro/+spec/usb-gadget-mass-st…
* Set up and test usb gadget mass storage on a board: DONE
Hi,
I had a good discussion with the validation team and they are
going to try to have some automated defconfig building working
by the end of the week. What they need from us is :
- What defconfigs do we want them to build? Either defconfigs
that are in the kernel tree or that are out of tree. My thought is
one per board that we care about, but I'm not sure if all the
boards have upstream defconfigs.
- What trees to test? I'm thinking linus HEAD and also the arm-soc
tree's -next branch.
~Deepak
