linaro-dev August 2012

linaro-dev@lists.linaro.org

54 participants
64 discussions

by Paul E. McKenney

Hello! Silas posted a series of four patches that fix bugs where the online CPUs are iterated over without proper protection against CPUs coming online and going offline: 0/4: https://lkml.org/lkml/2012/8/3/416 1/4: https://lkml.org/lkml/2012/8/3/422 2/4: https://lkml.org/lkml/2012/8/3/423 3/4: https://lkml.org/lkml/2012/8/3/418 4/4: https://lkml.org/lkml/2012/8/3/417 Could you please pull these into the integration tree? Thanx, Paul

13 years

TI LT Android for Panda board and perf

by Dmitry Antipov

Hello, I'm running https://android-build.linaro.org/builds/~linaro-android/panda-jb-gcc47-tilt…, build 23 (Aug15). It's kernel version is 3.4.0-xxx, but 'perf --version' reports 3.0.8_android. Why such a version mismatch? Usually it's the very poor idea to run perf on top of mismatched kernel. For the particular build, any attempt to run something beyond 'perf --help' or 'perf --version' crashes everything, for example: [ 65.116027] Unable to handle kernel paging request at virtual address e66107c0 [ 65.123687] pgd = e4664000 [ 65.126525] [e66107c0] *pgd=00000000 [ 65.130310] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 65.135955] Modules linked in: wl12xx wlcore mac80211 cfg80211 lib80211 btwilink rfcomm bnep bluetooth gator [ 65.146423] CPU: 0 Not tainted (3.4.0-gcc0d09f #1) [ 65.151885] PC is at vmap_page_range_noflush+0xc8/0x19c [ 65.157409] LR is at map_kernel_range_noflush+0x1c/0x20 [ 65.162963] pc : [<c00e5b28>] lr : [<c00e7018>] psr: 80030113 [ 65.162963] sp : e3ff5d80 ip : e66107c0 fp : e3ff5dc4 [ 65.175109] r10: e66107c0 r9 : c0725048 r8 : c07ba0c0 [ 65.180633] r7 : c0007f98 r6 : fe7f1000 r5 : 00000000 r4 : fe7f0000 [ 65.187622] r3 : e3900c40 r2 : e66107c0 r1 : fe7f0fff r0 : fe7f0000 [ 65.194549] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 65.202087] Control: 10c5387d Table: a466404a DAC: 00000015 <...registers...> [ 66.326110] Process perf (pid: 1811, stack limit = 0xe3ff42f8) [ 66.332244] Stack: (0xe3ff5d80 to 0xe3ff6000) [ 66.336853] 5d80: e3ff5e0c 00000000 c0779c44 e3900c40 0000065f fe7f1000 c00d69fc e3900f40 [ 66.345489] 5da0: 00000800 00000000 00000000 00000000 e3900940 00000000 e3ff5dd4 e3ff5dc8 [ 66.354125] 5dc0: c00e7018 c00e5a6c e3ff5e44 e3ff5dd8 c00d7b5c c00e7008 e3ff5e34 e3ff5de8 [ 66.362762] 5de0: fe7f0000 00001000 e4666e20 c0721ea8 00000001 00000001 00000004 e3900c40 [ 66.371398] 5e00: 00000001 00000000 e3fb2800 e3900940 00000000 00000001 00000001 00000004 [ 66.380035] 5e20: c07b5510 c0721efc 00000000 e3fb2800 c07b5670 c074e510 e3ff5e54 e3ff5e48 [ 66.388641] 5e40: c00d7fa0 c00d76a8 e3ff5e7c e3ff5e58 c00ab740 c00d7f90 00000800 00000000 [ 66.397277] 5e60: e3fb2800 00000000 e3fb2800 e3ff5f28 e3ff5e9c e3ff5e80 c00b0fe8 c00ab5b8 [ 66.405914] 5e80: c00b0fac c0750924 e3fb2800 c0750814 e3ff5ec4 e3ff5ea0 c00b7854 c00b0fb8 [ 66.414550] 5ea0: 00000000 c0750924 00000001 00000000 00000000 00000000 e3ff5ef4 e3ff5ec8 [ 66.423187] 5ec0: c00b7b04 c00b77e8 00000000 00000000 00000000 ffffffff 00000000 00000000 [ 66.431823] 5ee0: 00000000 00000000 e3ff5fa4 e3ff5ef8 c00b8458 c00b78b0 00000000 00000000 [ 66.440460] 5f00: 00000000 c001a188 e40a7590 00000010 e3ff5f2c e3ff5f20 00000003 00000000 [ 66.449096] 5f20: e3ff5f64 00000000 00000002 00000048 00000037 00000000 00000001 00000000 [ 66.457733] 5f40: 000004c7 00000000 00000007 00000000 00040302 00000000 00000000 00000000 [ 66.466339] 5f60: 00000000 00000000 00000000 00000000 00000000 00000000 e3ff5fa4 00000000 [ 66.474975] 5f80: 00000000 ffffffff 0000016c c000e6e8 e3ff4000 00000000 00000000 e3ff5fa8 [ 66.483612] 5fa0: c000e480 c00b8024 00000000 00000000 b899c630 ffffffff 00000000 ffffffff [ 66.492248] 5fc0: 00000000 00000000 ffffffff 0000016c b899c628 b899d160 00000008 b899e580 [ 66.500885] 5fe0: be8f3870 be8f3860 b6f886a9 b6eecef0 20030110 b899c630 00000000 20000000 [ 66.509521] Backtrace: [ 66.512115] [<c00e5a60>] (vmap_page_range_noflush+0x0/0x19c) from [<c00e7018>] (map_kernel_range_noflush+0x1c/0x20) [ 66.523162] [<c00e6ffc>] (map_kernel_range_noflush+0x0/0x20) from [<c00d7b5c>] (pcpu_alloc+0x4c0/0x8e8) [ 66.533081] [<c00d769c>] (pcpu_alloc+0x0/0x8e8) from [<c00d7fa0>] (__alloc_percpu+0x1c/0x20) [ 66.541992] [<c00d7f84>] (__alloc_percpu+0x0/0x20) from [<c00ab740>] (perf_trace_init+0x194/0x2c4) [ 66.551483] [<c00ab5ac>] (perf_trace_init+0x0/0x2c4) from [<c00b0fe8>] (perf_tp_event_init+0x3c/0x60) [ 66.561218] [<c00b0fac>] (perf_tp_event_init+0x0/0x60) from [<c00b7854>] (perf_init_event+0x78/0xc8) [ 66.570861] r6:c0750814 r5:e3fb2800 r4:c0750924 r3:c00b0fac [ 66.576843] [<c00b77dc>] (perf_init_event+0x0/0xc8) from [<c00b7b04>] (perf_event_alloc+0x260/0x420) [ 66.586486] r7:00000000 r6:00000000 r5:00000000 r4:00000001 [ 66.592498] [<c00b78a4>] (perf_event_alloc+0x0/0x420) from [<c00b8458>] (sys_perf_event_open+0x440/0x818) [ 66.602600] [<c00b8018>] (sys_perf_event_open+0x0/0x818) from [<c000e480>] (ret_fast_syscall+0x0/0x30) [ 66.612426] Code: e59f90d4 e1a0a00c e1a0200a e51b3038 (e592e000) [ 66.619354] ---[ end trace 8f2771e9f1c2026e ]--- [ 66.624450] Kernel panic - not syncing: Fatal exception [ 66.630035] CPU1: stopping [ 66.632904] Backtrace: [ 66.635498] [<c0012a04>] (dump_backtrace+0x0/0x114) from [<c04e0f90>] (dump_stack+0x20/0x24) [ 66.644409] r6:00000000 r5:fa240100 r4:00000001 r3:c074bccc [ 66.650421] [<c04e0f70>] (dump_stack+0x0/0x24) from [<c00141ec>] (handle_IPI+0x10c/0x1e0) [ 66.659057] [<c00140e0>] (handle_IPI+0x0/0x1e0) from [<c0008678>] (gic_handle_irq+0x68/0x70) [ 66.667968] r7:e609ff9c r6:c0721900 r5:fa240100 r4:e609ff68 [ 66.673980] [<c0008610>] (gic_handle_irq+0x0/0x70) from [<c000e080>] (__irq_svc+0x40/0x70) [ 66.682678] Exception stack(0xe609ff68 to 0xe609ffb0) [ 66.688018] ff60: c077c428 27aa89aa 4030a263 fe404000 e609e000 c04ee620 [ 66.696655] ff80: c077c270 c077c284 8000406a 411fc092 00000000 e609ffbc e609ff9c e609ffb0 [ 66.705291] ffa0: c0025384 c000f7a8 a0010113 ffffffff [ 66.710632] r6:ffffffff r5:a0010113 r4:c000f7a8 r3:c0025384 [ 66.716613] [<c000f774>] (default_idle+0x0/0x3c) from [<c000fb94>] (cpu_idle+0xbc/0x114) [ 66.725158] [<c000fad8>] (cpu_idle+0x0/0x114) from [<c04ddd94>] (secondary_start_kernel+0x130/0x154) [ 66.734802] r5:00000001 r4:00000001 [ 66.738616] [<c04ddc64>] (secondary_start_kernel+0x0/0x154) from [<804dd6d4>] (0x804dd6d4) [ 66.747314] r6:10c0387d r5:00000015 r4:a608c06a r3:c04dd6bc [ 66.753326] panic occurred, switching back to text console Dmitry

13 years

Reboot call fails in cpu_v7_proc_fin()

by Koteswararao Nelakurthi

Hi, While executing reboot call on my ARMv7 board, the system hangs during cpu_proc_fin() call. Commenting out this line of code, the reboot works properly. Index: mvlinux/arch/arm/mm/proc-v7.S =================================================================== --- mvlinux.orig/arch/arm/mm/proc-v7.S 2012-08-15 14:12:50.396190110 +0900 +++ mvlinux/arch/arm/mm/proc-v7.S 2012-08-15 14:21:28.730760416 +0900 @@ -51,7 +51,7 @@ mrc p15, 0, r0, c1, c0, 0 @ ctrl register bic r0, r0, #0x1000 @ ...i............ bic r0, r0, #0x0006 @ .............ca. - mcr p15, 0, r0, c1, c0, 0 @ disable caches + #mcr p15, 0, r0, c1, c0, 0 @ disable caches ldmfd sp!, {pc} ENDPROC(cpu_v7_proc_fin) is it a CPU_V7 specific issue? Please provide your valuable input to fix the issue. Any hint also..will help me in debugging further in this issue. I have seen above fix in one of the linaro mailing list. Regards, koteswararao.

13 years

Android Platform Team Meeting Agenda Posted

by Zach Pfeffer

Take a look at: https://wiki.linaro.org/Platform/Android/Meetings/2012-08-15 Feel free to add to the agenda and join us in #linaro-meeting on irc.freenode.net at 13:00 UTC. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years

[PATCH v4 0/2] Add v4l2 subdev driver for S5K4ECGX sensor with embedded SoC ISP

by Sangwook Lee

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 v3: - used request_firmware to configure initial settings - added parsing functions to read initial settings - updated regulator API - reduced preview setting tables by experiment Changes since v2: - added GPIO (reset/stby) and regulators - updated I2C read/write, based on s5k6aa datasheet - fixed set_fmt errors - reduced register tables a bit - removed vmalloc 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 | 8 + drivers/media/video/Makefile | 1 + drivers/media/video/s5k4ecgx.c | 941 +++++++++++++++++++++++++++++++++++ drivers/media/video/s5k4ecgx_regs.h | 138 +++++ include/media/s5k4ecgx.h | 37 ++ 5 files changed, 1125 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

13 years

big.LITTLE MP status Aug 13, 2012

by David Zinman

Roadmap Cards ============= http://cards.linaro.org/browse/CARD-34 Issue: mobile work use cases are not progressing - dmitry to change focus and get something out based on perf record and playback - will get 2 or 3 synthetic workloads before plumbers conference http://cards.linaro.org/browse/CARD-35 Hotplug optimisations looking good and more on the way in 3.6 and 3.7: https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Hotplug#CPU_hotpl… Blueprints ========= https://blueprints.launchpad.net/linaro-power-qa/+spec/emulating-a-big-litt… - The work has been done, and tested. - No one is using it at the moment. - tools available on git.linaro - HW availability supersedes this blueprint internally https://blueprints.launchpad.net/linaro-power-kernel/+spec/bl-mp-integratio… - this functionality is being covered by ARM Landing team - linunxLinaro integration https://blueprints.launchpad.net/linaro-power-kernel/+spec/sched-add-asymme… - merged and accepted https://blueprints.launchpad.net/linaro-power-kernel/+spec/perf-record-repl… - Broken in mainline, dmitry is working on fixing it. - A few days of work. - will publish basic use case to linaro dev - re-target to august release https://blueprints.launchpad.net/linaro-power-kernel/+spec/big.little.mp-ho… - Continuing inspection of RCU for issues with __stop_machine weaning. - Thomas Gleixner's patches should be set for 3.7 -- infiniband testing complete, lack of which prevented 3.6. - Designing alternatives for faster stop_cpu() work (which is current replacement for __stop_machine()) -- low priority tasks for stop_cpus() actually slows things down under load compared to stop_machine(). https://blueprints.launchpad.net/linaro-power-kernel/+spec/cpuidle-add-cpu-… - proposal being discussed on the mailing list. - d lezcano is on vacation but will collate feedback and respond. - little opposition https://blueprints.launchpad.net/linaro-power-kernel/+spec/cpuidle-upstream… - remaining items have been discussed as part of previous blueprint. Miscellaneous items ================= Testplan - Dates added to dependency table - Not much testing progress due to lack of hardware - For testing to ramp up we need platforms to test on ie: TC2 hardware Android - progress on fastmodels! - amit p has bootwrapper in place - boots with kernel from switcher project, not working with linux-linaro yet TC2 enablement has been integrated into the linux linaro tree. Asymmetric support for ARM accepted by Russell and is already merged into 3.6 Linux kernel Thomas Gleixner's kthreads infrastructure patches are now in git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git on the branch tip/smp/hotplug. There is an updated project plan at https://docs.google.com/a/linaro.org/document/d/1XI9FaEd6dYfCEDezboF7gWtrTO… -- David Zinman Linaro Release Manager | Project Manager Linaro.org | Open source software for ARM SoCs

13 years

New Gator version (5.11) ready for Linaro kernels

by Jon Medhurst (Tixy)

Hello All ARM have released a new version of Developer Studio 5 (DS-5) and we now have a new version of the Gator component [1] to go with this which needs updating in all Linaro kernel trees that will be part of the 12.08 release. For those people maintaining kernel trees here is what this means... - If your kernels are including the linux-linaro-core-tracking [2] branch then you will get the new Gator version from this when it is updated over the next couple of days. You don't need to do anything except to make sure you are up to date with this branch before the 12.08 release. - For Ubuntu kernels not including linux-linaro-core-tracking (and not being released from the common linux-linaro branch) then you should replace your existing Gator topic branch (or add one if it is missing). This new topic branch can be created by pulling from the ARM Landing Team's tree [3], we have three topic branches available for the last three kernel versions... tracking-armlt-gator (3.6-rc1) 3.5-armlt-gator-5.10 3.4-armlt-gator-5.10 The code in these branches is identical, they are just rebased onto different Linux versions to make pulling easier. - For Android kernels, if your kernel already includes the Gator topic, then this should be updated as above. If it does not have the Gator topic then chance are it is being included as a separate component in the manifest file; in which case, there is nothing further which needs doing as the git repo used for this has already been updated [4]. If anyone has any questions or if anything is unclear, please do hesitate to contact me. Note, for those people who have applied Mali driver patches to support profiling by Gator: you don't need to modify those Mali patches, just take the new version of Gator, this will still work OK. Cheers -- Tixy [1] Gator is the ARM target device components for ARM's Streamline Performance Analyzer which is part of their Developer Studio (DS-5). http://www.arm.com/products/tools/software-tools/ds-5/streamline.php [2] http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=shortlog;… [3] git://git.linaro.org/landing-teams/working/arm/kernel.git [4] http://git.linaro.org/gitweb?p=arm/ds5/gator.git;a=shortlog;h=refs/heads/an…

13 years

Hardware pack format V1 being dropped. V2 being deprecated.

by James Tunnicliffe

Hi, If you don't build hardware packs, you can stop reading now. Recently Linaro Image Tools added support for a new hardware pack format, which offers some new features (http://www.milo.name/2012/07/27/multiple-boards-bootloaders/). With the addition of the V3 format we will shortly be marking V2 as deprecated and finally getting rid of V1 support. There shouldn't be any V1 hardware packs in use, so that shouldn't have any impact on you. The transition to V3 may cause some alarm, but don't worry, there is a converter tool which converts V2 metadata into V3 form and you can them rebuild the hardware pack. We don't have a tool to convert hardware packs once they have been built, but if one is needed it shouldn't be difficult to provide. Please let me know dropping V1 support is going to cause any problems and any requirements for a V2 to V3 hardware pack converter. -- James Tunnicliffe

13 years

Call for topic updates and new topics for linux-linaro-core-tracking tree

by Andrey Konovalov

Greetings, The linux-linaro-core-tracking tree (llct, see http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=summary for some more details) is planned to be moved to v3.6-rc1 (or v3.6-rc2 if it is out) early next week. There will be more updates to llct as long as new -rc's are out. And this llct tree will be the base for the 12.08 linux-linaro release. Most of the current llct topics need updating for that: * topic svenkatr/ufs-for-linux-linaro : just 1 conflict, but there are newer commits by the topic owner in the kernel.org tree. Please update the topic * topic amitdanielk/thermal_exynos4_imx6_work : 3 conflicts * topic android_jstultz/linaro-android-3.5-jstultz-rebase 11 conflicts. This has been already discussed with the topic owner. We will both work on moving the current topic to v3.6. * topic arm_soc/testing/multiplatform 198 conflicts. Arnd, I don't see the multiplatform code in the current kernel.org tree. Could you please update me on the status of this effort? And if we want to keep the multiplatform topic in the llct tree, your help (updated or new branch for this topic) is needed. * topic ll_quantal/linaro-ubuntu-sauce 9 conflicts * topic perf antipov/linaro 2 conflicts. Looks like they are due to changes in the upstream. Dmitry, could you please rebase your topic branch over to v3.6-something (v3.6-rc1, current kernel.org tree, etc)? Just overwrite the existing topic branch (the earlier versions are saved in linux-linaro-tracking.git each time they are used for the llct updates, and could be reused later if needed). * topic big-LITTLE-MP-v4 b_L_mp/big-LITTLE-MP-v4 3 conflicts Let me know if there are obsoleted topics. And new topics are welcomed as usual :) Please note, that llct is for generic topics, not the board specific ones. I'll get to linux-linaro tree (which has board specific topics) right after llct is moved to v3.6-rc*. Thanks, Andrey

13 years

[PATCH v4 0/5] thermal: exynos: Add kernel thermal support for exynos platform

by Amit Daniel Kachhap

Hi Andrew/Rui, As discussed with Rui Zhang, I dropped the patch for new trip type THERMAL_TRIP_STATE_INSTANCE and made the necessary state magnagement changes in cpufreq cooling functions. Also I fixed all the review comments suggested by Andrew. If any other changes please let me know. This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git omap4460_thermal) * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) The is a small change in cpufreq cooling registration APIs, so a minor change is needed for OMAP and Freescale platforms. Thanks, Amit Daniel Changes since V3: * Dropped the concept of using new trip type THERMAL_TRIP_STATE_INSTANCE as discussed with Rui Zhang. This requires adding some state management logic in cpufreq cooling implementation. * Many review comments suggested by Andrew Morton * More documentation added in cpufreq cooling codes. Changes since V2: *Added Exynos5 TMU sensor support by enhancing the exynos4 tmu driver. Exynos5 TMU driver was internally developed by SangWook Ju <sw.ju(a)samsung.com>. *Removed cpuhotplug cooling code in this patchset. *Rebased the patches against 3.4-rc6 kernel. Changes since V1: *Moved the sensor driver to driver/thermal folder from driver/hwmon folder as suggested by Mark Brown and Guenter Roeck *Added notifier support to notify the registered drivers of any cpu cooling action. The driver can modify the default cooling behaviour(eg set different max clip frequency). *The percentage based frequency replaced with absolute clipped frequency. *Some more conditional checks when setting max frequency. *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to THERMAL_TRIP_STATE_INSTANCE *Many review comments from R, Durgadoss <durgadoss.r(a)intel.com> and eduardo.valentin(a)ti.com implemented. *Removed cooling stats through debugfs patch *The V1 based can be found here, https://lkml.org/lkml/2012/2/22/123 http://lkml.org/lkml/2012/3/3/32 Changes since RFC: *Changed the cpu cooling registration/unregistration API's to instance based *Changed the STATE_ACTIVE trip type to pass correct instance id *Adding support to restore back the policy->max_freq after doing frequency clipping. *Moved the trip cooling stats from sysfs node to debugfs node as suggested by Greg KH greg(a)kroah.com *Incorporated several review comments from eduardo.valentin(a)ti.com *Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd as discussed with Guenter Roeck <guenter.roeck(a)ericsson.com> and Donggeun Kim <dg77.kim(a)samsung.com> (https://lkml.org/lkml/2012/1/5/7) *Some changes according to the changes in common cpu cooling APIs *The RFC based patches can be found here, https://lkml.org/lkml/2011/12/13/186 https://lkml.org/lkml/2011/12/21/169 Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This codes is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) . But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a)struct thermal_cooling_device *cpufreq_cooling_register( struct freq_clip_table *tab_ptr, unsigned int tab_size) b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. All this patchset is based on Kernel version 3.4-rc6 A simple data/control flow diagrams is shown below, Core Linux thermal <-----> Exynos thermal interface <----- Temperature Sensor | | \|/ | Cpufreq cooling device <--------------- TODO: *Will send the DT enablement patches later after the driver is merged. Amit Daniel Kachhap (5): thermal: Add generic cpufreq cooling implementation hwmon: exynos4: Move thermal sensor driver to driver/thermal directory thermal: exynos5: Add exynos5 thermal sensor driver support thermal: exynos: Register the tmu sensor with the kernel thermal layer ARM: exynos: Add thermal sensor driver platform data support Documentation/hwmon/exynos4_tmu | 81 --- Documentation/thermal/cpu-cooling-api.txt | 60 ++ Documentation/thermal/exynos_thermal | 52 ++ drivers/hwmon/Kconfig | 10 - drivers/hwmon/Makefile | 1 - drivers/hwmon/exynos4_tmu.c | 514 -------------- drivers/thermal/Kconfig | 20 + drivers/thermal/Makefile | 4 +- drivers/thermal/cpu_cooling.c | 483 +++++++++++++ drivers/thermal/exynos_thermal.c | 956 ++++++++++++++++++++++++++ include/linux/cpu_cooling.h | 99 +++ include/linux/platform_data/exynos4_tmu.h | 83 --- include/linux/platform_data/exynos_thermal.h | 100 +++ 13 files changed, 1773 insertions(+), 690 deletions(-) delete mode 100644 Documentation/hwmon/exynos4_tmu create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 Documentation/thermal/exynos_thermal delete mode 100644 drivers/hwmon/exynos4_tmu.c create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 drivers/thermal/exynos_thermal.c create mode 100644 include/linux/cpu_cooling.h delete mode 100644 include/linux/platform_data/exynos4_tmu.h create mode 100644 include/linux/platform_data/exynos_thermal.h

13 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev August 2012