These couple of patches use the new cpuidle core api to refactor
some part of the code. The first one declares the states directly
in the driver declaration and the second one use the timekeeping
flag to let the cpuidle core to compute the idle time.
I don't have this board, I was not able to test these patches.
Daniel Lezcano (2):
ARM: s3c64xx: cpuidle - declare the states with the new api
ARM: s3c64xx: cpuidle - use timekeeping wrapper
arch/arm/mach-s3c64xx/cpuidle.c | 45 +++++++++++++--------------------------
1 files changed, 15 insertions(+), 30 deletions(-)
--
1.7.5.4
Hi everyone,
I've been discussing multiplatform kernels with a few people recently,
and we will have a lot of discussion sessions about this at Linaro
Connect in Hong Kong.
One question that came up repeatedly is whether we should support all
possible board files for each platform in a multiplatform kernel,
or just the ones that are already using DT probing. I would like
to get a quick poll of opinions on that and I've tried to put those
people on Cc that would be most impacted by this, i.e. the maintainers
for platforms that have both DT and non-DT board files at the moment.
My feeling is that we should just mandate DT booting for multiplatform
kernels, because it significantly reduces the combinatorial space
at compile time, avoids a lot of legacy board files that we cannot
test anyway, reduces the total kernel size and gives an incentive
for people to move forward to DT with their existing boards.
The counterargument is that we won't be able to support all the
boards we currently do when the user switches on multiplatform,
but I think that is acceptable.
Note that I would still want to allow users to build platforms
separately in order to enable the ATAG style board files, even
for platforms that are not multiplatform capable.
Other opinions?
Arnd
Sounds like a very basic question, I would like to test some of the
recent patches related to mx28 for freescale EVK board.
( Some thing like - https://lkml.org/lkml/2012/3/13/176 )
Is there specific branch one should be looking for in
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git? Or these
changes are being staged some place other than arm-soc.git?
Thanks for the help
-Subodh
P.S. I posting it linaro mailing list 'cause lot of this device-tree
patches seem to be coming from folks with at-linaro.org email addresses.
We have a new channel on FreeNode for LAVA specific discussions:
#linaro-lava
This channel allows participants who are working with Linaro to join and
just follow progress on LAVA.
We should be using the same guidelines for deciding whether something
belongs on #linaro or not as channels like #linaro-android currently do.
Hi all,
These five patches are hopefully the final set of core framework changes
for 3.5. There is the obligatory MAINTAINERS file change, three new
fixes and the fixed-factor clock patch. That last patch is being
reposted since three bugs were found in it (one on the list, two in my
testing).
If no one complains about these then I'll commit them to clk-next and
(finally) send my pull request to Arnd.
Note that the Orion patches aren't here, but I figure that Andrew L.
probably wants to check those against the final clk-next before I pull
them.
Regards,
Mike
Mike Turquette (4):
MAINTAINERS: add entry for common clk framework
clk: prevent spurious parent rate propagation
clk: remove COMMON_CLK_DISABLE_UNUSED
clk: mux: assign init data
Sascha Hauer (1):
clk: add a fixed factor clock
MAINTAINERS | 10 ++++
drivers/clk/Kconfig | 11 -----
drivers/clk/Makefile | 2 +-
drivers/clk/clk-fixed-factor.c | 95 ++++++++++++++++++++++++++++++++++++++++
drivers/clk/clk-mux.c | 1 +
drivers/clk/clk.c | 9 +++-
include/linux/clk-private.h | 20 ++++++++
include/linux/clk-provider.h | 23 ++++++++++
8 files changed, 156 insertions(+), 15 deletions(-)
create mode 100644 drivers/clk/clk-fixed-factor.c
--
1.7.5.4
Hi all,
PM-QA is updated:
1. Removed obsolete test cases under pm-qa/tastcases
2. Thermal test scripts has been merged into, but is temporarily disabled
form the top 'make check', while ‘make -C thermal check’ still works for
this sub-test.
3. Temporarily disabled suspend function form top 'make check', this will
be enabled after fully test on LEBs later, also 'make -C suspend check' is
available.
Any problems you found please let me know, thanks.
Hi there. Hopefully an easy question but I'm stumped. How do I
install the armel softfp libc6 on a new Precise armhf install?
I set APT::Architectures to { "armel" } and then tried a apt-get
install libc6:armel but I get errors about the package not matching
the host architecture.
-- Michael
