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 +++++++++++++++++++++---------------
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
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
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
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
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
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
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
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.
