Hi Guys ,
I am working on a samsung sp5v310 development kit.
I wanted to read a peripheral register (battery charger) in u-boot.
This device is interfaced on i2c0. I am working with the u-boot in
git://git.linaro.org/boot/u-boot-linaro-stable.git
I wanted to do i2c_read in the code, but as i understand the i2c
support is not there in u-boot for s5pv310 SOCs. Please confirm, if this
is correct or i am wrong.
If there is support to do i2c operations on s5pv310 SOCs, please point
me to the right file, where i can find i2c configurations for s5pv310 SOCs.
thanks,
- Avinash
PS:
1. There are no i2c macros in include/configs/smdkv310.h.
2. After adding,below macros to enable i2c support for smdkv310,
/* I1C */
#define CONFIG_HARD_I2C 1
#define CONFIG_SYS_I2C_SPEED 100000
#define CONFIG_SYS_I2C_SLAVE 1
#define CONFIG_SYS_I2C_BUS 0
#define CONFIG_SYS_I2C_BUS_SELECT 1
#define CONFIG_I2C_MULTI_BUS 1
i get below error:
/media/data/avinash/c.labs/
git.clones/bootloader/uboot/arch/arm/lib/board.c:189: undefined reference
to `i2c_init'
common/libcommon.o: In function `stdio_init':
/media/data/avinash/c.labs/git.clones/bootloader/uboot/common/stdio.c:215:
undefined reference to `i2c_init'
And there are no i2c related support inside the u-boot for samsung smdkv310.
avinash@avinash-desktop:/media/data/avinash/c.labs/git.clones/bootloader-new/uboot$
grep -inlr 'v310' . > v310.files.txt
avinash@avinash-desktop:/media/data/avinash/c.labs/git.clones/bootloader-new/uboot$
cat v310.files.txt | xargs grep -inr 'i2c_init'
Binary file ./uboot.PS matches
avinash@avinash-desktop:/media/data/avinash/c.labs/git.clones/bootloader-new/uboot$
== Niklas Hernaeus <nhe> ==
=== General activity ===
* DT-work started on the RTC, PL031.
* Due to non-synchronization among us, some work has been duplicated.
* A google document is now used for synchronization and status.
* There seem to be no patches ready for PL180, Saugata Das is
probably assigned (?).
* Arnd helped out with an integration of my previous patch and Lee's
patches. Thanks.
* There is now a working DT environment for Snowball. Work continues with
new drivers.
== Rajendra Nayak <rnayak> ==
=== Highlights ===
* mmc platform callback cleanups posted. Ground work before these
callbacks get moved into a system control module driver.
* More mmc driver general cleanups while working on DT.
* mmc dt series v2 with minor comments from Grant. Found an issue
with the previous series which seemed to work only with MMC_DEBUG
enabled. Issue root caused to OMAP4 controllers needing a special
reset mechanism.
* Worked some more on the system control module driver adding support
for omap2 and omap3. The SCM driver is still limited to adding only
mmc functionality.
=== Plans ===
* Get mmc-dt patches merged.
* Post all mmc driver cleanups accumulated.
* Make System control module driver work with multiple SCM hmwod
instances added (latest series from Paul W)
=== Misc ===
* None
=== Highlights ===
* Reviewed the current android common/android-3.3 branch and pulled out
updates to the already upstream items in staging, and submitted them to
Greg for staging-next, so they'll be ready when the 3.4 window opens
soon. These efforts got some positive press here:
http://www.phoronix.com/scan.php?page=news_item&px=MTA2ODA
* Discussed androidization topic branch for Andrey's linaro linux
kernel. Sent the current AOSP 3.3 branch to Andrey for the 12.3 release.
* Reworked my range-tree code for fadvise volatile to use a rbtree for
better balancing & to simplify the code. Also spent time trying to work
out dual-list locking issues.
* Got pulled into some community timekeeping bug reports, I've tried,
but haven't been able to reproduce yet.
* Verified PaulW's omap resume fix patch
* Got pulled into a sched_clock issue. Reviewed and acked a fix on lkml.
* Updated my rtc, timekeeping and clocksource queues for 3.4.
=== Plans ===
* Continue implementing solution to fadvise volatile dual-list locking
issue
* Likely a few other timekeeping issues & trying to make sure everything
I have pending for 3.4 is queued upstream.
=== Issues ===
* NA
== Arnd Bergmann <arnd> ==
=== Highlights ===
* Merged tons of patches into the arm-soc tree, then handed over to Olof for
the meantime but will probably take over again for the merge window
* Sent out status of the arm-soc tree report for the 3.4 merge window
* Worked with Jason Cooper to get Kirkwood DT conversion started
* Worked with Roland Stigge to get him established as lpc32xx maintainer
and get his code for that platform in, he will work on lpc32xx DT stuff
in the v3.5 cycle.
* Worked with Alan Ott and Mathieu Poirier to start getting my randconfig
patches merged.
* Worked with Niklas Hernaeus and Lee Jones to speed up the ux500 DT conversion.
* Code review: pxa/mmp DT patches, bmp085 driver, at91, dreamplug, ...
=== Plans ===
* Keep watching over various DT conversions
* Dig out my old series for inb/outb elimination and get that
into shape for -next after the merge window
== Linus Walleij linusw ==
=== Highlights ===
* Merged pin control patches from Stephen Warren,
finalizing the API transition.
* Sent a patch series converting U300 over to using
pin control.
* Updated pinctrl blueprints, created work for myself by
opening a ux500 pinctrl transition blueprint.
* Sent some AB8500 updates including AB8505 support
to Sam for MFD.
* Looking over some other internal patches, particularly
patches touching the core kernel outside our own drivers,
posting a cpufreq-ondemand patch today.
* Discussed dmaengine.
* Discussed internal alignment of Linaro activities for
two issues as requested by Andrea.
=== Plans ===
* Test the U9540 patches on real hardware and rework
as outlined by Arnd.
* Accumulate pinctrl patches for kernel v3.4 merge
window.
* Work on the blueprint for ux500 pinctrl.
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Look into other Ux500 stuff in need of mainlining...
like
- Ux500 clocks
- the HWMON stuff.
=== Issues ===
* None!
Thanks,
Linus Walleij
Hi there,
There's considerable activity in the subject of the scheduler lately and how to
adapt it to the peculiarities of the new class of hardware coming out lately,
like the big.LITTLE class of devices from a number of manufacturers.
The platforms that Linux runs are very diverse, and run differing workloads.
For example most consumer devices will very likely run something like Android,
with common use cases such as audio and/or video playback. Methods to achieve
lower power consumption using a power aware scheduler are under investigation.
Similarly for server applications, or VM hosting, the behavior of the scheduler
shouldn't have adverse performance implications; any power saving on top of that
would be a welcome improvement.
The current issue is that scheduler development is not easily shared between
developers. Each developer has their own 'itch', be it Android use cases, server
workloads, VM, etc. The risk is high of optimizing for one's own use case and
causing severe degradation on most other use cases.
One way to fix this problem would be the development of a method with which one
could perform a given use-case workload in a host, record the activity in a
interchangeable portable trace format file, and then play it back on another
host via a playback application that will generate an approximately similar load
which was observed during recording.
The way that the two hosts respond under the same load generated by the playback
application can be compared, so that the performance of the two scheduler implementations
measured in various metrics (like performance, power consumption etc.) can be
evaluated.
The fidelity of the this approximation is of great importance but it is debatable
if it is possible to have a fully identical load generated, since details of the hosts
might differ in such a way that such a thing is impossible.
I believe that it should be possible at least to simulate a purely CPU load, and the
blocking behavior of tasks, in such a way that it would result in scheduler decisions
that can be compared and shared among developers.
The recording part I believe can be handled by the kernel's tracing infrastructure,
either by using the existing tracepoints, or need be adding more; possibly even
creating a new tracer solely for this purpose.
Since some applications can adapt their behavior according to insufficient system
resources (think media players that can drop frames for example), I think it would
be beneficial to record such events to the same trace file.
The trace file should have a portable format so that it can be freely shared between
developers. An ASCII format like we currently use should be OK, as long as it
doesn't cause too much of an effect during execution of the recording.
The playback application can be implemented via two ways.
One way, which is the LinSched way would be to have the full scheduler implementation
compiled as part of said application, and use application specific methods to evaluate
performance. While this will work, it won't allow comparison of the two hosts in a meaningful
manner.
For both scheduler and platform evaluation, the playback application will generate the load
on the running host by simulating the source host's recorded work load session.
That means emulating process activity like forks, thread spawning, blocking on resources
etc. It is not clear to me yet if that's possible without using some kind of kernel
level helper module, but not requiring such is desirable.
Since one would have the full trace of scheduling activity: past, present and future; there would
be the possibility of generating a perfect schedule (as defined by best performance, or best
power consumption), and use it as a yardstick of evaluation against the actual scheduler.
Comparing the results, you would get an estimate of the best case improvement that could be
achieved if the ideal scheduler existed.
I know this is a bit long, but I hope this can be a basis of thinking on how to go about
developing this.
Regards
-- Pantelis
== Highlights ==
* Debugged cgroups inaccuracy when calculating memory usage,
prepared a hack that fixes the issue, sent an RFC. A proper fix
needs to be implemented though;
* Reviewing/comparing various low memory notifications:
the one from Minchan Kim (http://lwn.net/Articles/475791/), Nokia's
memory meter (http://lkml.org/lkml/2012/1/4/208) and vmevent
(http://lkml.org/lkml/2012/1/17/370). Feature and reception-wise
VM event framework looks like a winner;
* Tried vmevents notifications framework, prepared a few fixes;
* Added two-way notifications to vmevents;
* Added vmevents support for the ulmkd.
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
Hi all,
We are know that the OMAP4460's PMU is buggy, which loses PMU interrupt always.
But I do not know what the real bug is, the HW bug or Software bug?
What the bug is?
Could some one give a point?
Kyler Zhang
