linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[PATCH 0/5] make sdhci device drivers self registered

by Shawn Guo

This patch set is to take sdhci device driver specific things out from sdhci-pltfm.c and make them self registered. Here are the difference it makes. * Get the sdhci device driver follow the Linux trend that driver take the registration by its own * sdhci-pltfm.c becomes significantly simpler and only has common support functions there * All sdhci device specific stuff are going back its own driver * The dt and non-dt support share the same pair of .probe and .remove hooks. The first one patch adds common support function into sdhci-pltfm.c when changing sdhci-esdhc-imx driver, while the last one clean up sdhci-pltfm.c when changing sdhci-tegra driver. Only the patch of sdhci-esdhc-imx are tested on hardware, and others are just build tested. Regards, Shawn Shawn Guo (5): mmc: sdhci: make sdhci-esdhc-imx driver self registered mmc: sdhci: make sdhci-cns3xxx driver self registered mmc: sdhci: make sdhci-dove driver self registered mmc: sdhci: make sdhci-tegra driver self registered mmc: sdhci: update Makefile/Kconfig for sdhci_pltfm change drivers/mmc/host/Kconfig | 24 +++-- drivers/mmc/host/Makefile | 11 +- drivers/mmc/host/sdhci-cns3xxx.c | 68 +++++++++++++- drivers/mmc/host/sdhci-dove.c | 70 +++++++++++++- drivers/mmc/host/sdhci-esdhc-imx.c | 98 +++++++++++++++---- drivers/mmc/host/sdhci-pltfm.c | 165 ++----------------------------- drivers/mmc/host/sdhci-pltfm.h | 14 ++- drivers/mmc/host/sdhci-tegra.c | 189 +++++++++++++++++++++---------------

14 years, 10 months

No support of platform device instance id?

by Shawn Guo

Hello all, I'm looking at function of_device_alloc in drivers/of/platform.c, and surprisingly found that the platform device instance id is being hard-coded as -1 when calling platform_device_alloc. Does this mean that there is no support of pdev id in DT? If yes, can anyone please help me understand why we do not have something in DT node to reflect this id and get it supported? Or this is something on TODO list? I'm asking this because I feel we still need pdev id support in DT when reviewing the patch set of 'mx51 basic DT support'. -- Regards, Shawn

14 years, 10 months

Some GL benchmarks for ARM devices

by Jesse Barker

Hi all, Thought this might be of interest to folks. http://www.glbenchmark.com/result.jsp?benchmark=glpro20&orderby=405&screen-… http://www.glbenchmark.com/compare.jsp?benchmark=glpro20&showhide=true&cert… The first is an overall comparison (pretty high level) of available boards, and the second is a breakdown of the top 2 results: the Apple iPad2 and the Hardkernel ODROID-A (FWIW, according to androidtablets.net, the odroid-a is an Orion). While this can certainly be a red herring, it might be nice to see these comparisons with identical screen resolutions (i.e. not all performance measurements are sensitive to pixel resolution). cheers, Jesse

14 years, 10 months

Notes & Actions: Linaro Graphics Working Group - Mar 16, 2011

by Alexandros Frantzis

Hi, notes and actions from our Wednesday graphics working group call are available on the wiki: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-03-16 Details about when and where of this meeting can be found here: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2… Summary ======= * Kwin: * crash solved with the toolchain fix in Linaro gcc 4.5-2011.03-0. * Patch "Fix GL_INVALID_OPERATION" accepted by upstream (commit). * DRI/Mali: Investigation is ON for ASHMEM (uses IPC for sharing memory among processes) in Android to get a hint for user space memory sharing. * Refactoring Mali and UMP driver Kconfig and Makefiles. * Started adding OpenGL ES and EGL support to GLEW. * Compiz : build system changes for switching between GL/GLES mostly done Thanks, -- - Alexandros

14 years, 10 months

[NOTES] 3/16 Linaro Developer Platform Weekly Status Meeting

by Tom Gall

Enclosed you'll find a link to the agenda, notes and actions from the Linaro Developer Platforms Weekly Status meeting held on March 16th in #linaro-meeting on irc.freenode.net at 16:00 UTC. http://wiki.linaro.org/Platform/DevPlatform/Meetings/2011-03-16 Actions from the meeting where as follows: * slangasek to raise a bug on launchpad about it allowing new bugs to be opened for non-existent packages * aviksil to talk to ltrace upstream about doing an official 0.6.0 release * slangasek to have StephenDoel send Orion to JamieBennett Regards, Tom (tgall_foo) Developer Platforms Team "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

14 years, 10 months

[RFC] kprobes with thumb2 conditional code

by Tixy

Hello All I'm about to start work on getting kprobes working with thumb2. One of the issues I have is that when probes are placed onto conditionally executed instructions in a IT block, they may not fire if the condition is not met. This is because on ARM we use invalid instructions for breakpoints, and the ARM ARM says: "it is IMPLEMENTATION DEFINED whether the instruction executes as a NOP or causes an Undefined Instruction exception" This is a similar issue to that already encountered by GDB [1][2] If we take this code as an example... probe1: if(condition) { probe2: some_code; } It seams reasonable at first sight that probe2 would only fire if the condition is true. This will always be the case if the compiler generates test-and-branch code, but if it generates conditionally executed instructions for 'some_code' then it gets complicated... The current arm kprobes implementation will always fire probe2 because it uses unconditional instructions for its breakpoints. With thumb instructions we can't force unconditional execution, so we would have an 'implementation defined' situation whether it would fire or not when the condition is false. (Thought you would hope it would be consistent on a particular device.) Some options for dealing with this, in increasing order of complexity... 1. Accept the situation as described. 2. Change arm probes to use conditional instructions so we would (hopefully) have consistent undefined behaviour in both arm and thumb code. (If that isn't an oxymoron :-) 3. Do 2, and modify kprobe_handler to test for false firings (breakpoint when condition false) and not execute the probe's callback functions in these cases. E.g. consistently make probe2 appear to not fire when condition is false. 4. Make thumb probes fire unconditionally like current arm implementation... 4a. Use breakpoint instructions rather than undefined instructions for kprobes. Apparently this doesn't play nicely with hardware debuggers [2] though I don't have enough experience in this area to otherwise comment. 4b. Rewrite IT blocks when probes are inserted into them to make the breakpoint unconditional. This would require parsing backwards through the instruction stream to find the IT instruction, which I don't believe is possible with variable length thumb instructions. Or, another possibility which was suggested to me, use the unwind table to find the start of the containing function and parse forwards to find the IT instruction. Though the kernel doesn't currently have enough information to skip things like inline data that may be the function. The effort, complexity and bloat involved in 4b seems to be rather excessive to me, even before getting into the book-keeping required to handle multiple probes in the same IT block. So 4b is a bit of a straw man. BTW, does anyone know of any test code for kprobes, particularly with regard to checking emulation/single-stepping of the different CPU instructions? Thanks for any feedback -- Tixy [1] http://permalink.gmane.org/gmane.comp.gdb.patches/54862 [2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/72199/focus=73489

14 years, 10 months

[PATCH RFC 0/5] Dynamically add clk to clkdev per dt clock nodes

by Shawn Guo

Before translating all mx5 clocks from static adding way to dynamic way, I would send this out for review and comment, so that I can turn around in case that I'm on a wrong direction. It's based on Jason's mx51-basic-dt-support patch set, and only adds gpt and uart related clocks, but it's enough to get the system at where Jason's patch can get. [PATCH 1/5] arm/dts: babbage: add gpt and uart related clock nodes [PATCH 2/5] arm/mxc: add clk members to ease dt clock support [PATCH 3/5] arm/dt: mx51: dynamically add gpt and uart related clocks per dt nodes [PATCH 4/5] arm/dt: mx5: change timer init function to dt clock way [PATCH 5/5] of/clock: eliminate function __of_clk_get_from_provider arch/arm/boot/dts/babbage.dts | 162 ++++++++++++- arch/arm/mach-mx5/board-dt.c | 9 +- arch/arm/mach-mx5/clock-mx51-mx53.c | 436 +++++++++++++++++++++++++++++++- arch/arm/plat-mxc/include/mach/clock.h | 4 + drivers/of/clock.c | 23 +-- drivers/tty/serial/imx.c | 79 +++++- 6 files changed, 661 insertions(+), 52 deletions(-) Regards, Shawn

14 years, 10 months

[PATCH V5 0/4] Add MX51 basic DT support

by Jason Liu

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. V5: - Add bidings for uart and fec - resolve s-o-b issue - move dt clock part to seperate file V4: - Add Linaro sign off and copyrightt 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 (4): 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: add device tree matching support .../devicetree/bindings/net/fsl-imx-fec.txt | 17 +++ .../bindings/tty/serial/fsl-imx-uart.txt | 19 +++ arch/arm/boot/dts/babbage.dts | 122 ++++++++++++++++++++ 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-dt.c | 52 +++++++++ arch/arm/plat-mxc/include/mach/common.h | 1 + drivers/net/fec.c | 17 +++ drivers/tty/serial/imx.c | 78 +++++++++++-- 10 files changed, 369 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/fsl-imx-fec.txt create mode 100644 Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt create mode 100644 arch/arm/boot/dts/babbage.dts create mode 100644 arch/arm/mach-mx5/board-dt.c create mode 100644 arch/arm/mach-mx5/clock-dt.c

14 years, 10 months

[REPORT] 2011-03-17 Infrastructure team weekly report

by Jamie Bennett

Hi, The Infrastructure team weekly report for 2011-03-17 is now available and can be found at: https://wiki.linaro.org/Platform/Infrastructure/Status/2011-03-17 The report is also reproduced in full below. Regards, Jamie. -- Linaro Release Manager | Platform Project Manager -- * Period: (20110310-20110316) * PM: JamieBennett <jamie.bennett(a)linaro.org> * Past reports : https://wiki.linaro.org/Platform/Infrastructure/Status * Burndown information : http://status.linaro.org/linaro-infrastructure.html * Stakeholder process: https://wiki.linaro.org/Platform/Infrastructure/CurrentProjects == Key Points for wider discussion == * A blog aggregator instance has been setup at planet.linaro.org, please take a look. * https://android-build.linaro.org/ is now feature complete and can be used by the Android team for requesting builds. == Team Highlights == * Initial investigations into how the Infrastructure team could help on the Validation LAVA scheduler have happened. No decision has been made to commit resources to this project at this time. * Work continues on svammel as fixes and functionality go into the branch. Some reviews and feedback have been given by the Developer Platform team. * The continuous integration work saw its first deployment on EC2 as Jenkins was installed and configured. More work is needed before this is useful. * Work on http://status.linaro.org is ramping down with a couple of fixes being worked on this week. == Upcoming Deliverables == * linaro-image-tools will be getting a release soon (likely before the monthly release date to ease the process of getting it in to Ubuntu) * Final patch metrics for the next member report. == Risks / Issues == * '''VERY HIGH IMPACT''': Mattias unable to work productively due to IT restrictions in ST-E (6 weeks): some progress. Has process now to request changes, but little response to his requests in more than 4 weeks. Mattias is working from home or over 3G in the meantime. * '''HIGH IMPACT''': PatchTracking requires deploying Patchwork (5 weeks): Discussion with IS, and it is not expected to take them long to do once they get to it. They have indicated that they may be able to start at the end of this week, or in the week after. * '''HIGH IMPACT''': Gerrit instance needed for Android (5 weeks): Co-ordination with IS has started. Waiting to hear from them if we can get it this month, and what we need to do to help with that. * '''MEDIUM IMPACT''': Deepti lacking hardware to work with her Panda board: Deepti has received the Panda board, but doesn't have a USB->serial cable for it, so is still unable to use it for much. Working on tasks that don't require it, but unable to participate in image testing. (many weeks). * '''MEDIUM IMPACT''': OurOwnOffspring is still being setup (many weeks) * '''MEDIUM IMPACT''': Want a Jenkins/Hudson instance for Continuous Integration purposes (many weeks): Discussions with IS, and they will provide one, but timeframe is unclear at this point. Will host ourselves until IS can provide. Work on an ec2 instance for this has started, and should be completed soon. * '''MEDIUM IMPACT''': Deepti and Avik are sharing one Panda board meaning some hardware specific work is being blocked (2 weeks). == Miscellaneous == * Guilherme at PyCon 10-15 March * James away 21st March

14 years, 10 months

[REPORT] 2011-03-17 Validation team weekly report

by Jamie Bennett

Hi, The Validation team weekly report for 2011-03-17 is now available and can be found at: https://wiki.linaro.org/Platform/Validation/Status/2011-03-17 The report is also reproduced in full below. Regards, Jamie. -- Linaro Release Manager | Platform Project Manager -- * Period: (20110310-20110316) * PM: JamieBennett <jamie.bennett(a)linaro.org> * Past reports : https://wiki.linaro.org/Platform/Validation/Status * Burndown information : http://status.linaro.org/linaro-validation.html == Key Points for wider discussion == * Please take a look at http://validation.linaro.org/launch-control/ and give feedback. == Team Highlights == * launch-control 0.3 release candidate 3 was deployed on validation.linaro.org (http://validation.linaro.org/launch-control/). * QEMU continuous integration testing now boots some known-good test images every time there is a commit and a new build of QEMU in Jenkins. * Initial work on power management tests in abrek has begun. More discussions about next steps for those tests is underway. * Investigations into how to build and test android images in the validation farm are underway. Some modification of the master image is needed but the partitioning layout for Android is causing problems. == Upcoming Deliverables == * dashboard.linaro.org upgrade to 0.3. == Risks / Issues == * '''HIGH IMPACT''': The validation scheduler Blueprint continues to lag behind with 37 work items to complete (none completed so far) - https://launchpad.net/lava/+spec/linaro-n-validation-scheduler (several weeks). Discussions are on going to find a way to unblock this project. == Miscellaneous == * None.

14 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev