linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[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, 10 months

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, 10 months

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, 10 months

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, 10 months

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, 10 months

[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, 10 months

[PATCH v2 00/23] Introduce Xen support on ARM

by Stefano Stabellini

Hi all, this patch series implements Xen support for ARMv7 with virtualization extensions. It allows a Linux guest to boot as dom0 and as domU on Xen on ARM. PV console, disk and network frontends and backends are all working correctly. It has been tested on a Versatile Express Cortex A15 emulator, using the latest Xen ARM developement branch (git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus the "ARM hypercall ABI: 64 bit ready" patch series (http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546). The patch marked with [HACK] shouldn't be applied and is part of the series only because it is needed to create domUs. I am also attaching to this email the dts'es that I am currently using for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to Linux by Xen, while vexpress-virt.dts is the dts used for other domUs and it is appended in binary form to the guest kernel image. I am not sure where they are supposed to live yet, so I am just attaching them here so that people can actually try out this series if they want to. Comments are very welcome! Changes in v2: - fix up many comments and commit messages; - remove the early_printk patches: rely on the emulated serial for now; - remove the xen_guest_init patch: without any PV early_printk, we don't need any early call to xen_guest_init, we can rely on core_initcall alone; - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if at the moment is unused; - use ldm instead of pop in the hypercall wrappers; - return -ENOSYS rather than -1 from the unimplemented grant_table functions; - remove the pvclock ifdef in the Xen headers; - remove include linux/types.h from xen/interface/xen.h; - replace pr_info with pr_debug in xen_guest_init; - add a new patch to introduce xen_ulong_t and use it top replace all the occurences of unsigned long in the public Xen interface; - explicitely size all the pointers to 64 bit on ARM, so that the hypercall ABI is "64 bit ready"; - clean up xenbus_init; - make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI; - mark Xen guest support on ARM as EXPERIMENTAL; - introduce GRANT_TABLE_PHYSADDR; - remove unneeded initialization of boot_max_nr_grant_frames; - add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c; - return -EINVAL from xen_remap_domain_mfn_range if auto_translated_physmap; - retain binary compatibility in xen_add_to_physmap: use a union to introduce foreign_domid. Ian Campbell (1): [HACK] xen/arm: implement xen_remap_domain_mfn_range Stefano Stabellini (22): arm: initial Xen support xen/arm: hypercalls xen/arm: page.h definitions xen/arm: sync_bitops xen/arm: empty implementation of grant_table arch specific functions xen: missing includes xen/arm: Xen detection and shared_info page mapping xen/arm: Introduce xen_pfn_t for pfn and mfn types xen/arm: Introduce xen_ulong_t for unsigned long xen/arm: compile and run xenbus xen: do not compile manage, balloon, pci, acpi and cpu_hotplug on ARM xen/arm: introduce CONFIG_XEN on ARM xen/arm: get privilege status xen/arm: initialize grant_table on ARM xen/arm: receive Xen events on ARM xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree xen: allow privcmd for HVM guests xen/arm: compile blkfront and blkback xen/arm: compile netback xen: update xen_add_to_physmap interface arm/v2m: initialize arch_timers even if v2m_timer is not present arch/arm/Kconfig | 10 ++ arch/arm/Makefile | 1 + arch/arm/include/asm/hypervisor.h | 6 + arch/arm/include/asm/sync_bitops.h | 27 +++ arch/arm/include/asm/xen/events.h | 18 ++ arch/arm/include/asm/xen/hypercall.h | 69 ++++++++ arch/arm/include/asm/xen/hypervisor.h | 19 +++ arch/arm/include/asm/xen/interface.h | 72 +++++++++ arch/arm/include/asm/xen/page.h | 79 +++++++++ arch/arm/mach-vexpress/v2m.c | 11 +- arch/arm/xen/Makefile | 1 + arch/arm/xen/enlighten.c | 237 ++++++++++++++++++++++++++++ arch/arm/xen/grant-table.c | 53 ++++++ arch/arm/xen/hypercall.S | 106 +++++++++++++ arch/ia64/include/asm/xen/interface.h | 6 +- arch/x86/include/asm/xen/interface.h | 8 + arch/x86/xen/enlighten.c | 1 + arch/x86/xen/irq.c | 1 + arch/x86/xen/mmu.c | 3 + arch/x86/xen/xen-ops.h | 1 - drivers/block/xen-blkback/blkback.c | 1 + drivers/net/xen-netback/netback.c | 1 + drivers/net/xen-netfront.c | 1 + drivers/tty/hvc/hvc_xen.c | 2 + drivers/xen/Makefile | 11 +- drivers/xen/events.c | 18 ++- drivers/xen/grant-table.c | 1 + drivers/xen/privcmd.c | 20 +-- drivers/xen/xenbus/xenbus_comms.c | 2 +- drivers/xen/xenbus/xenbus_probe.c | 62 +++++--- drivers/xen/xenbus/xenbus_probe_frontend.c | 1 + drivers/xen/xenbus/xenbus_xs.c | 1 + drivers/xen/xenfs/super.c | 7 + include/xen/events.h | 2 + include/xen/interface/features.h | 3 + include/xen/interface/grant_table.h | 4 +- include/xen/interface/io/protocols.h | 3 + include/xen/interface/memory.h | 32 +++-- include/xen/interface/physdev.h | 4 +- include/xen/interface/platform.h | 4 +- include/xen/interface/version.h | 2 +- include/xen/interface/xen.h | 13 +- include/xen/privcmd.h | 3 +- include/xen/xen.h | 2 +- 44 files changed, 857 insertions(+), 72 deletions(-) A branch based on 3.5-rc7 is available here: git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.5-rc7-arm-2 Cheers, Stefano

13 years, 10 months

[PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index

by Dirk Behme

On embedded devices, often there is a combination of removable mmc devices (e.g. MMC/SD cards) and hard wired ones (e.g. eMMC). Depending on the hardware configuration, the 'mmcblkN' node might change if the removable device is available or not at boot time. E.g. if the removable device is attached at boot time, it might become mmxblk0. And the hard wired one mmcblk1. But if the removable device isn't there at boot time, the hard wired one will become mmcblk0. This makes it somehow difficult to hard code the root device to the non-removable device and boot fast. This change does simply associate 'N' of 'mmcblkN' with the slot index instead of the dynamic name index. The slot index is always the same, ensuring that the non-removable mmc device is associated always with the same mmcblkN. Independent of the availability of the removable one. This issue has a long history. One prominent one is e.g. from the Maemo based Nokia N810 device: https://bugs.maemo.org/show_bug.cgi?id=2747 Signed-off-by: Dirk Behme <dirk.behme(a)de.bosch.com> CC: Jassi Brar <jaswinder.singh(a)linaro.org> CC: Chris Ball <cjb(a)laptop.org> --- drivers/mmc/card/block.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index f1c84de..a01d306 100644 --- a/drivers/mmc/card/block.c +++ b/drivers/mmc/card/block.c @@ -1517,7 +1517,7 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card, */ snprintf(md->disk->disk_name, sizeof(md->disk->disk_name), - "mmcblk%d%s", md->name_idx, subname ? subname : ""); + "mmcblk%d%s", card->host->index, subname ? subname : ""); if (mmc_card_mmc(card)) blk_queue_logical_block_size(md->queue.queue, -- 1.7.0.4

13 years, 10 months

Linaro 2012/8/8 Android Platform Team Agenda Posted

by Zach Pfeffer

The agenda has been posted to: https://wiki.linaro.org/Platform/Android/Meetings/2012-08-08 Please take a look and add to it if you need to. See everyone tomorrow 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, 10 months

[PATCH PM-QA] cpufreq: check governor mode before using it

by hongbo.zhang

From: "hongbo.zhang" <hongbo.zhang(a)linaro.com> If we want to set one cpufreq governor mode, we must check this mode is supported or not before setting it. Otherwise we will get failure reported, this differs from the case that one mode is said to be supported but doesn't work well at all. hongbo.zhang (1): cpufreq: governor mode should be checked if it is supported before setting it. cpufreq/cpufreq_04.sh | 7 ++++++- cpufreq/cpufreq_05.sh | 54 +++++++++++++++++++++++++++++++++---------------- cpufreq/cpufreq_06.sh | 6 ++++++ cpufreq/cpufreq_07.sh | 6 ++++++ cpufreq/cpufreq_08.sh | 6 ++++++ cpufreq/cpufreq_09.sh | 6 ++++++ 6 files changed, 67 insertions(+), 18 deletions(-) -- 1.7.10

13 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev