linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[PATCH 0/4 v4] pin controller subsystem v4

by Linus Walleij

From: Linus Walleij <linus.walleij(a)linaro.org> This is the fourth iteration of the pin controller subsystem, most changes are described in the first patch, copied here for reference: ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). Linus Walleij (4): drivers: create a pinmux subsystem v4 pinmux: add a driver for the U300 pinmux amba: request muxing for PrimeCell devices mach-u300: activate pinmux driver, delete old padmux driver Documentation/ABI/testing/sysfs-class-pinmux | 11 + Documentation/pinctrl.txt | 512 +++++++++++++++++++ MAINTAINERS | 5 + arch/arm/mach-u300/Kconfig | 2 + arch/arm/mach-u300/Makefile | 2 +- arch/arm/mach-u300/core.c | 31 ++- arch/arm/mach-u300/include/mach/syscon.h | 136 ----- arch/arm/mach-u300/mmc.c | 16 - arch/arm/mach-u300/padmux.c | 367 -------------- arch/arm/mach-u300/padmux.h | 39 -- arch/arm/mach-u300/spi.c | 20 - drivers/Kconfig | 4 + drivers/Makefile | 2 + drivers/amba/bus.c | 49 ++- drivers/pinctrl/Kconfig | 36 ++ drivers/pinctrl/Makefile | 7 + drivers/pinctrl/core.c | 437 ++++++++++++++++ drivers/pinctrl/core.h | 22 + drivers/pinctrl/pinmux-u300.c | 421 ++++++++++++++++ drivers/pinctrl/pinmux-u300.h | 141 ++++++ drivers/pinctrl/pinmux.c | 700 ++++++++++++++++++++++++++ drivers/pinctrl/pinmux.h | 4 + include/linux/amba/bus.h | 2 + include/linux/pinctrl/machine.h | 62 +++ include/linux/pinctrl/pinctrl.h | 120 +++++ include/linux/pinctrl/pinmux.h | 122 +++++ 26 files changed, 2687 insertions(+), 583 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-pinmux create mode 100644 Documentation/pinctrl.txt delete mode 100644 arch/arm/mach-u300/padmux.c delete mode 100644 arch/arm/mach-u300/padmux.h create mode 100644 drivers/pinctrl/Kconfig create mode 100644 drivers/pinctrl/Makefile create mode 100644 drivers/pinctrl/core.c create mode 100644 drivers/pinctrl/core.h create mode 100644 drivers/pinctrl/pinmux-u300.c create mode 100644 drivers/pinctrl/pinmux-u300.h create mode 100644 drivers/pinctrl/pinmux.c create mode 100644 drivers/pinctrl/pinmux.h create mode 100644 include/linux/pinctrl/machine.h create mode 100644 include/linux/pinctrl/pinctrl.h create mode 100644 include/linux/pinctrl/pinmux.h -- 1.7.3.2

13 years, 10 months

[PATCH v9 00/12] use nonblock mmc requests to minimize latency

by Per Forlin

How significant is the cache maintenance over head? It depends, the eMMC are much faster now compared to a few years ago and cache maintenance cost more due to multiple cache levels and speculative cache pre-fetch. In relation the cost for handling the caches have increased and is now a bottle neck dealing with fast eMMC together with DMA. The intention for introducing non-blocking mmc requests is to minimize the time between a mmc request ends and another mmc request starts. In the current implementation the MMC controller is idle when dma_map_sg and dma_unmap_sg is processing. Introducing non-blocking mmc request makes it possible to prepare the caches for next job in parallel to an active mmc request. This is done by making the issue_rw_rq() non-blocking. The increase in throughput is proportional to the time it takes to prepare (major part of preparations is dma_map_sg and dma_unmap_sg) a request and how fast the memory is. The faster the MMC/SD is the more significant the prepare request time becomes. Measurements on U5500 and Panda on eMMC and SD shows significant performance gain for large reads when running DMA mode. In the PIO case the performance is unchanged. There are two optional hooks pre_req() and post_req() that the host driver may implement in order to move work to before and after the actual mmc_request function is called. In the DMA case pre_req() may do dma_map_sg() and prepare the dma descriptor and post_req runs the dma_unmap_sg. Details on measurements from IOZone and mmc_test: https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req Tested on platforms * Development and extensive testing is done on ux500 and Pandaboard * Additional testing is done on * Patches are tested on samsung exynos4 platform * Boot tested on Omap4430 Blaze board * U300 MMC/PL180 mmc_test and ad hoc FS test * ARM realview mmc_test and ad hoc FS test Changes since v8: * add comment to clarify bug print in issue_rw_rq. * mmc_test: * align size for sg_len test cases, * use MAX_SIZE define for test size for all non-blocking, * allow non-blocking test even if pre/post is not implemented, * return error if only one of pre or post is implemented. Per Forlin (12): mmc: core: add non-blocking mmc request function omap_hsmmc: add support for pre_req and post_req mmci: implement pre_req() and post_req() mmc: mmc_test: add debugfs file to list all tests mmc: mmc_test: add test for non-blocking transfers mmc: mmc_test: test to measure how sg_len affect performance mmc: block: add member in mmc queue struct to hold request data mmc: block: add a block request prepare function mmc: block: move error code in issue_rw_rq to a separate function. mmc: queue: add a second mmc queue request member mmc: core: add random fault injection mmc: block: add handling for two parallel block requests in issue_rw_rq drivers/mmc/card/block.c | 507 ++++++++++++++++++++++++---------------- drivers/mmc/card/mmc_test.c | 498 +++++++++++++++++++++++++++++++++++++++-- drivers/mmc/card/queue.c | 184 ++++++++++------ drivers/mmc/card/queue.h | 33 ++- drivers/mmc/core/core.c | 167 +++++++++++++- drivers/mmc/core/debugfs.c | 5 + drivers/mmc/host/mmci.c | 147 +++++++++++- drivers/mmc/host/mmci.h | 8 + drivers/mmc/host/omap_hsmmc.c | 87 +++++++- include/linux/mmc/core.h | 6 +- include/linux/mmc/host.h | 24 ++ lib/Kconfig.debug | 11 + 12 files changed, 1356 insertions(+), 321 deletions(-) -- 1.7.4.1

13 years, 10 months

Having some trouble boot Panda with MLO compiled from source

by Zach Pfeffer

John, I'm having some trouble booting Panda with our MLO that gets compiled from source. We've got a bug: https://bugs.launchpad.net/linaro-android/+bug/833832 Which details the current state of things. -Zach

13 years, 10 months

11.09 and beyond Android Planning

by Zach Pfeffer

Team (and others), Now that we have images for all boards (2 images for Panda) it should allow us to really start cranking. I recently reviewed the capabilities of each board and would like to focus on enabling the connectivity options for each. In order of importance we should make sure these work across all platforms: ADB over USB Fix SDCard Automatic Ethernet Support WiFi Bluetooth This support will need to come up automatically when each build boots. In addition we'll need to ensure that suspend and resume work across all boards. For our Gerrit push we'll: Connect the results of LAVA with Gerrit Generate test builds Merge changes onto test builds Run test builds through LAVA Merge to mainline based on the results We'll also be finalizing a flow to ensure that Android kernel patches can be manged within Gerrit while still allowing kernel maintainers to keep those trees running the latest kernel. This will allow Android developers around the world to help Linaro Android platforms not only run the latest kernels and best toolchains, but to do so on fully-enabled devices and upstream there work through one common interface. Extending Gerrit to support efficient upstreaming is crucial to helping ensure that functionality can flow upstream and no one is better suited to lead in this area than Linaro. Also in 11.09 we'll be planning on integrating work from the other WGs: >From PM we will be spinning up a PM tree and landing a new power app that should allow people to experiment with PM using a more familiar Android interface. >From MM we will be continuing to integrate libjpeg-turbo work with the eventual goal of pushing this to AOSP. >From GFX we will be spinning up a GFX tree with the latest CMA work and landing the glmark2 work into builds. On into 11.10 and 11.11... For 11.10 we'll continue enabling functionality in each board, hopefully some more multimedia related things like HW accelerated audio and video. We should have a full Gerrit workflow going and be able to take changes from around the world and integrate them with ease, we should also have some nascent upstreaming functionality built into Gerrit. For 11.11 and beyond we'll hopefully have worked out most of the licensing issues and be able to enable sensors and on all the boards. We'll also hopefully be bringing new boards online; since everyone will have been through things before this should go smoothly. One thing that I'd like to do is better show off the work Linaro is doing with our Android builds. Since Android is such an easy platform to extend and hack on we should be able to create some very dynamic and interesting demonstrations of the work we're doing. Happy to have comments, questions, concerns. BPs and bugs to follow. -Zach

13 years, 10 months

Please just send things to linaro-dev...

by Zach Pfeffer

It looks like just sending things to linaro-dev will be the easiest and most transparent. Hopefully this will be one less thing to worry about. I'll keep the alias around for a bit. Now the question is should we shut down #linaro-android? Ideas? -Zach

13 years, 10 months

[RFC PATCH 0/4] ARM: EXYNOS4: Use cpuidle common save/restore framework code

by Amit Daniel Kachhap

These patch adds support for samsung exynos4 platform cpuidle driver to use the common cpuidle framework submitted earlier by Lorenzo Pieralisi. Basically a single interface cpu_enter_idle takes care of saving and restoring single cpu or whole cluster information. The link to the framework patchset is, http://www.spinics.net/lists/arm-kernel/msg132044.html Description of patches in this list: 1)Patch (ARM: kernel: Some fixes in save/restore common code) adds some essential fixes for the common save/restore to work on exynos4 platform. 2)Patch (ARM: EXYNOS4: Fix to work with origen boards) adds a fix for extracting chip revision number. 3)Patch (ARM: EXYNOS4: Add support AFTR mode cpuidle state on EXYNOS4210) rebases the L2 retention C state cpuidle driver submitted earlier by Jaecheol Lee. 4)Patch (Modify cpuidle code to adapt to save/restore common code) uses the generic infrastructure to enter and exit from the retention idle state. All these codes have been tested on Samsung ORIGEN board against the tree git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next. Amit Daniel Kachhap (4): ARM: kernel: Some fixes in save/restore common code. ARM: EXYNOS4: Fix to work with origen boards. ARM: EXYNOS4: Add support AFTR mode cpuidle state on EXYNOS4210 ARM: EXYNOS4: Modify cpuidle code to adapt to save/restore common code arch/arm/Kconfig | 1 + arch/arm/common/gic.c | 1 - arch/arm/kernel/sr_helpers.h | 2 +- arch/arm/mach-exynos4/cpu.c | 10 ++ arch/arm/mach-exynos4/cpuidle.c | 150 +++++++++++++++++++++++++++++- arch/arm/mach-exynos4/include/mach/pmu.h | 1 - arch/arm/mm/cache-l2x0.c | 10 ++- arch/arm/plat-s5p/include/plat/exynos4.h | 1 + 8 files changed, 169 insertions(+), 7 deletions(-)

13 years, 10 months

[NOTES] Kernel WG Weekly Status report for week ending 2011-08-26

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status report for the kernel working group for the week ending 2011-08-26. == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-08-22 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-08-25 == Summary == * Released 11.08 Linaro kernel based on 3.0.3 stable kernel including the merge of 3.1-rc1 core ARM updates from Russell King's tree. * Merged 11.08 Linaro kernel into Linaro+Android tree * Initial support of Origen board and support of BeagleBoard<https://wiki.linaro.org/BeagleBoard>-xM revision C. * Integrated patch set for Qualcomm Hexagon architecture * The v6/v7 single kernel patches are now accepted by Russell; these should allow linaro filesystems to work on omap2plus_defconfig kernels * Started DT support for i.mx6Q * vexpress DT got a booting kernel (with some hacks) platform devices are now populated from the device tree * MX53 NAND driver support * The USB mass storage patch for variable number of pipeline buffers is queued for 3.2. * Fault injection for MMC is queued for 3.2 -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

13 years, 10 months

[NOTES] Power Management WG Weekly Status report week ending 2011-08-26

by Mounir Bsaibes

Enclosed please find the link to the Meeting Minutes & Weekly Status report for the Power Management working group for the week ending 2011-08-26. == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-08-24 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-08-25 == Summary == * Rebased PMWG consolidation kernel tree to 3.1-rc2 * Delivered powerqa first release, new powerdebug release (fixes only) and new powertop release working on Android * Updated sched_mc wiki page * Continued work on cpuidle driver for i.MX platform * implemented gpio dump code for powerdebug * Completed monthly release planning for September -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

13 years, 10 months

Re: Linaro 11.08 released

by Dave Martin

On Fri, Aug 26, 2011 at 1:06 PM, Dave Martin <dave.martin(a)linaro.org> wrote: [...] > the impact of bugs in releases. For example, bug 824545 means that > the user will get an unbootable image on some boards by following our > instructions -- that feels like the kind of thing that definitely needs to be > visible in the release notes, even though from a technical standpoint we know > the issue is actually rather trivial and easily fixed. Just to follow up on this, I see that particular bug is fixed in the final release. So it may be that we have no issues missing from the release notes after all. Cheers ---Dave

13 years, 10 months

Erro "make: *** /lib/modules/2.6.38-1003-linaro-omap/build: No such file or directory."

by Juan Gao

Dear Linaro team, I have a problem when I try to make a module. To make the module file xx.c, I have the following command line in my Makefile: make -C /lib/modules/$(shell uname -r)/build M=$(pwd) modules an error occured: make: *** /lib/modules/2.6.38-1003-linaro-omap/build: No such file or directory. I looked up the /lib/modules/ folder, there are two sub folders: /lib/modules/2.6.38-1003-linaro-omap /lib/modules/2.6.38-1208-omap4 Under /lib/modules/2.6.38-1003-linaro-omap, there is not a 'build' folder, but under /lib/modules/2.6.38-1208-omap4, there is the 'build' folder that is needed for building the modules. Please could you kindly let me know why this happens, and how to resolve this issue? Many thanks, Juan ------------------------------------------------------------------ Juan Gao Software Applications Engineer--Compiler tools UK Support Team: +44(0)1223 400600 ARM Ltd. US Support Team: +1 512 381 2928 110 Fulbourn Road Direct Dial: +44(0)1223 406988 Cambridge CB1 9NJ Fax: +44(0)1223 400410 England E-Mail: Juan.Gao(a)arm.com ------------------------------------------------------------------ -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

13 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev