The following 2 patches add driver for S5K4ECGX sensor with embedded ISP SoC,
and minor v4l2 control API enhancement. S5K4ECGX is 5M CMOS Image sensor from Samsung.
Changes since v1:
- fixed s_stream(0) when it called twice
- changed mutex_X position to be used when strictly necessary
- add additional s_power(0) in case that error happens
- update more accurate debugging statements
- remove dummy else
Sangwook Lee (2):
v4l: Add factory register values form S5K4ECGX sensor
v4l: Add v4l2 subdev driver for S5K4ECGX sensor
drivers/media/video/Kconfig | 7 +
drivers/media/video/Makefile | 1 +
drivers/media/video/s5k4ecgx.c | 881 ++++++++++
drivers/media/video/s5k4ecgx_regs.h | 3121 +++++++++++++++++++++++++++++++++++
include/media/s5k4ecgx.h | 29 +
5 files changed, 4039 insertions(+)
create mode 100644 drivers/media/video/s5k4ecgx.c
create mode 100644 drivers/media/video/s5k4ecgx_regs.h
create mode 100644 include/media/s5k4ecgx.h
--
1.7.9.5
From: "hongbo.zhang" <hongbo.zhang(a)linaro.com>
Hi all,
This is the ST-Ericsson db8500 thermal dirver, here are some notes of this patch set:
1.
0001-Remove-un-necessary-variable-checking.patch is a trivial update of the thermal framework.
0002-ST-Ericsson-db8500-thermal-dirver.patch is the ST-Ericsson db8500 thermal dirver.
2.
Since there is no PRCMU interface to read temperature directly, the PRCMU interrupts are used instead,
and a pseudo current temperature is returned, but this works for the thermal management framework.
This can be updated when the corresponding PRCMU interface is available.
3.
As suggested by Vincent Guittot, the cooling device codes are seperated from thermal zone, this makes it
easy to add/remove other cooling devices. CPU frequency limiting is the current cooling device.
4.
The driver isn't added into device tree currently, this can be done soon if needed.
hongbo.zhang (2):
Remove un-necessary variable checking
ST-Ericsson db8500 thermal dirver
arch/arm/configs/u8500_defconfig | 4 +
arch/arm/mach-ux500/board-mop500.c | 69 ++++
drivers/thermal/Kconfig | 20 ++
drivers/thermal/Makefile | 4 +-
drivers/thermal/cpu_cooling.c | 3 +-
drivers/thermal/db8500_cpufreq_cooling.c | 167 +++++++++
drivers/thermal/db8500_thermal.c | 476 ++++++++++++++++++++++++++
include/linux/platform_data/db8500_thermal.h | 39 +++
8 files changed, 779 insertions(+), 3 deletions(-)
create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c
create mode 100644 drivers/thermal/db8500_thermal.c
create mode 100644 include/linux/platform_data/db8500_thermal.h
--
1.7.10
Hey,
Amber just reminded me about the the Ubuntu Developer Week, and
pointed out that we'll have another one from Tue 28th Aug to Thu 30th
Aug.
Here's the blog post with more details:
http://ubuntuclassroom.wordpress.com/2012/07/17/ubuntu-developer-week-plann…
As we're also involved with topics involving Ubuntu development, it'd
be nice if we could also be part of it, or at least request a few
topics to be covered. In case you want to learn things specifically
with Ubuntu, also let us know, so we can try to have someone to cover
such topic.
The sessions happens at IRC, and they are quite useful for people
wanting to know more about how the development of Ubuntu happens.
Now for the Dev Plat team, anything specifically you want to cover?
Package cross build and multi-arch would be interesting to have. John,
guess you could also demonstrate how we're packaging up our kernels,
and how people can easily generate debian packages for any tree they
want.
Thanks,
--
Ricardo Salveti de Araujo
We can't rely on Kconfig options to set the fast and slow CPU lists for
HMP scheduling if we want a single kernel binary to support multiple
devices with different CPU topology. E.g. ARM's TC2, Fast Models, or
even non big.LITTLE devices.
This patch adds the function arch_get_fast_and_slow_cpus() to generate
the lists at run-time by parsing the CPU nodes in device-tree; it
assumes slow cores are A7s and everything else is fast. The function
still supports the old Kconfig options as this is useful for testing the
HMP scheduler on devices without big.LITTLE.
Signed-off-by: Jon Medhurst <tixy(a)linaro.org>
---
The reason I'm pushing this patch is that I want to use it for this
month's Linaro vexpress release to help with the goal of having a single
build which will work on all CoreTiles (and possibly Fast Models).
arch/arm/kernel/topology.c | 69 ++++++++++++++++++++++++++++++++++++++++++++
kernel/sched/fair.c | 18 ++++--------
2 files changed, 75 insertions(+), 12 deletions(-)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index f59193c..61302df 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -287,6 +287,75 @@ void store_cpu_topology(unsigned int cpuid)
cpu_topology[cpuid].socket_id, mpidr);
}
+
+#ifdef CONFIG_SCHED_HMP
+
+static const char * const little_cores[] = {
+ "arm,cortex-a7",
+ NULL,
+};
+
+static bool is_little_cpu(struct device_node *cn)
+{
+ const char * const *lc;
+ for (lc = little_cores; *lc; lc++)
+ if (of_device_is_compatible(cn, *lc))
+ return true;
+ return false;
+}
+
+void __init arch_get_fast_and_slow_cpus(struct cpumask *fast,
+ struct cpumask *slow)
+{
+ struct device_node *cn = NULL;
+ int cpu = 0;
+
+ cpumask_clear(fast);
+ cpumask_clear(slow);
+
+ /*
+ * Use the config options if they are given. This helps testing
+ * HMP scheduling on systems without a big.LITTLE architecture.
+ */
+ if (strlen(CONFIG_HMP_FAST_CPU_MASK) && strlen(CONFIG_HMP_SLOW_CPU_MASK)) {
+ if (cpulist_parse(CONFIG_HMP_FAST_CPU_MASK, fast))
+ WARN(1, "Failed to parse HMP fast cpu mask!\n");
+ if (cpulist_parse(CONFIG_HMP_SLOW_CPU_MASK, slow))
+ WARN(1, "Failed to parse HMP slow cpu mask!\n");
+ return;
+ }
+
+ /*
+ * Else, parse device tree for little cores.
+ */
+ while ((cn = of_find_node_by_type(cn, "cpu"))) {
+
+ if (cpu >= num_possible_cpus())
+ break;
+
+ if (is_little_cpu(cn))
+ cpumask_set_cpu(cpu, slow);
+ else
+ cpumask_set_cpu(cpu, fast);
+
+ cpu++;
+ }
+
+ if (!cpumask_empty(fast) && !cpumask_empty(slow))
+ return;
+
+ /*
+ * We didn't find both big and little cores so let's call all cores
+ * fast as this will keep the system running, with all cores being
+ * treated equal.
+ */
+ cpumask_setall(fast);
+ cpumask_clear(slow);
+}
+
+#endif /* CONFIG_SCHED_HMP */
+
+
/*
* init_cpu_topology is called at boot when only one cpu is running
* which prevent simultaneous write access to cpu_topology array
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f705a87..e056361 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3084,25 +3084,19 @@ done:
#ifdef CONFIG_SCHED_HMP
/* Heterogenous multiprocessor (HMP) optimizations
- * We need to know which cpus that are fast and slow. Ideally, this
- * information would be provided by the platform in some way. For now it is
- * set in the kernel config. */
+ * We need to know which cpus that are fast and slow. */
static struct cpumask hmp_fast_cpu_mask;
static struct cpumask hmp_slow_cpu_mask;
-/* Setup fast and slow cpumasks.
- * This should be setup based on device tree somehow. */
+extern void __init arch_get_fast_and_slow_cpus(struct cpumask *fast,
+ struct cpumask *slow);
+
+/* Setup fast and slow cpumasks. */
static int __init hmp_cpu_mask_setup(void)
{
char buf[64];
- cpumask_clear(&hmp_fast_cpu_mask);
- cpumask_clear(&hmp_slow_cpu_mask);
-
- if (cpulist_parse(CONFIG_HMP_FAST_CPU_MASK, &hmp_fast_cpu_mask))
- WARN(1, "Failed to parse HMP fast cpu mask!\n");
- if (cpulist_parse(CONFIG_HMP_SLOW_CPU_MASK, &hmp_slow_cpu_mask))
- WARN(1, "Failed to parse HMP slow cpu mask!\n");
+ arch_get_fast_and_slow_cpus(&hmp_fast_cpu_mask, &hmp_slow_cpu_mask);
printk(KERN_DEBUG "Initializing HMP scheduler:\n");
cpulist_scnprintf(buf, 64, &hmp_fast_cpu_mask);
--
1.7.10.4
Hello,
Over lifetime of Linaro CI services, we've been experiencing number of
episodes when service stability was influenced by Ubuntu package
mirror issues, with it being used to configure each and every build
slave, usually dozen times a day.
Linaro Infrastructure team and CI service stakeholders tried different
approaches to solve this issue, and over time we come to conclusion that
sustainable way to do it is to maintain custom Amazon Machine
Images (AMI) with preinstalled packages, which will simply cut the
dependency on Ubuntu mirror's 100% availability. In addition to that,
they also speed up build startup time noticeably.
A special tool, linaro-ami, was developed to help maintain custom AMIs,
with two main requirements being centralized configuration location for
EC2 admins control, as well as being easy to use for individual custom
AMI maintainers. We still may need to improve UI functionality for the
latter, and would need stakeholder feedback for that, but otherwise the
tool seems to work pretty well. It is available as part of
linaro-aws-tools project, https://launchpad.net/linaro-aws-tools . The
README is available at
http://bazaar.launchpad.net/~linaro-aws-devs/linaro-aws-tools/trunk/view/he…ci.linaro.org and android-build.linaro.org has been already switched to
new custom AMIs. Using custom AMIs for CBuild service is under
consideration by Toolchain group.
So, from this point on, it's important that all stakeholders follow
build slave configuration change process centered around linaro-ami
tool: any package set changes should be applied to slave init script
(as referenced in linaro-ami config), a new version of corresponding AMI
generated, and Jenkins configuration updated with new AMI ID. (No
package installation should be happen directly in Jenkins.)
The Infrastructure team can help with maintaining AMIs, and is open for
suggestions on improving new setup.
Thanks,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
The Raspbian project is a rebuild of Debian for the Raspberry Pi.
adama did some benchmarks that show the improvement in going from
ARMv4T with soft float to ARMv6 with hard float:
http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/
The page says that there's a 4-10 % improvement on integer programs
and up to 40 % on floating point programs. It's hard to tell the new
instruction vs pipeline influence and if the baseline is soft float or
softfp/VFP based.
-- Michael