linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by Tom Gall

Announcing the release of live-build_3.0~a45-1-1linaro3 to ppa:linaro-maintainers/tools Included in this release are two minor but important fixes 1) for cross builds make sure to qualify the use of the linaro-overlay ppa correctly so armel isn't hardcoded 2) for precise, defend against the movement of insserv out of the system path, which if not present will cause packages such as module-init-tools to fail. -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

13 years, 3 months

[PATCH v3 0/4] OMAP serial device tree support

by Rajendra Nayak

v3 is rebased on top of the latest serial runtime patches[1] and boot tested with/without DT on OMAP4 SDP and OMAP4 Panda boards. Patches can be found here.. git://gitorious.org/omap-pm/linux.git for-dt/serial I also had to pull in a fix[2] for DT testing (already in linux-omap master) which was missing as the serial runtime branch[1] was based on an older master commit. Changes in v3: -1- Rebased on latest serial runtime patches -2- Minor typr fixes Changes in v2: -1- Got rid of binding to define which uart is console -2- Added checks to default clock speed to 48Mhz -3- Added compatible for each OMAP family -4- Used of_alias_get_id to populate port.line [1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime [2] http://www.spinics.net/lists/arm-kernel/msg150751.html Rajendra Nayak (4): omap-serial: Get rid of all pdev->id usage omap-serial: Use default clock speed (48Mhz) if not specified omap-serial: Add minimal device tree support ARM: omap: pass minimal SoC/board data for UART from dt .../devicetree/bindings/serial/omap_serial.txt | 10 +++ arch/arm/boot/dts/omap3.dtsi | 31 ++++++++ arch/arm/boot/dts/omap4.dtsi | 28 +++++++ arch/arm/mach-omap2/board-generic.c | 1 - drivers/tty/serial/omap-serial.c | 80 +++++++++++++++---- 5 files changed, 132 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt

13 years, 3 months

[RFC] Scheduler recorder and playback

by Pantelis Antoniou

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

13 years, 3 months

Call for testing Linaro Android 12.04 candidates

by Fathi Boudra

We have prepared Linaro Android 12.04 candidates. Spreadsheets have been updated. Please, run the tests that have a 'w' after them. Thanks! Testers, builds and spreadsheets ================================ Jon https://android-build.linaro.org/builds/~linaro-android/vexpress-ics-gcc46-… https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadExQd… Chenglie https://android-build.linaro.org/builds/~linaro-android/origen-ics-gcc46-sa… https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadDRDV… Bernard https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc46-free… https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadDE1M… Vishal https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-til… https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadGVWd… Botao https://android-build.linaro.org/builds/~linaro-android/imx53-ics-gcc46-fre… https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadDE1M… Mathieu https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc46-… https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadEF1N… Amit https://android-build.linaro.org/builds/~linaro-android/vexpress-rtsm-ics-g… No spreadsheet for vexpress-rtsm build.

13 years, 3 months

ARM porting jam on Wednesday

by Marcin Juszkiewicz

Dear ARM fans, Linaro Developer Platform team organises every week an ARM porting Jam. Next one will be on Wednesday 11th April (we moved from Friday cause weekend does not help in remembering which patches are still to send upstream). The idea is to gather all developers together to fix user space portability issues across the board. There are several things to work on: - the list of bugs being worked on is at launchpad [1] with more useful web interface at [2] 1. https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby… 2. http://people.linaro.org/~rsalveti/arm-porting-queue/arm-porting-queue-repo… - list from 'make multiarch cross-building work' process which is described at [3][4] with logfiles available at [5] - now that the release is close non-trivial fixes should rather go into Debian than Ubuntu. As this is cross compiler related you do not even have to use ARM devices. 3. http://wiki.linaro.org/Platform/DevPlatform/CrossCompile/MultiarchCrossBuil… 4. http://wiki.debian.org/Multiarch/CrossDependencies 5. http://people.linaro.org/~wookey/buildd/precise/sbuild-ma/status.html - You can also help with libffi related issues if you can - list is available at Debian wiki [6] 6. http://wiki.debian.org/ArmHardFloatTodo#libffi Interested in making the software in Ubuntu run better on ARM? Join us on the #linaro channel on irc.linaro.org (aka freenode) today!

13 years, 3 months

Fwd: [PATCHv2 0/5] coupled cpuidle state support

by Amit Kucheria

Andy, TI seems to be happy with the cpuidle driver based on Colin's couple C-state work. Santosh has provided a branch at the end of this message that is rebased on top of 3.4-rc2. Can we fold this into the TILT tree for April? Daniel, You should provided a consolidated version of your fixes and cleanups to the various LTs too. /Amit ---------- Forwarded message ---------- From: Santosh Shilimkar <santosh.shilimkar(a)ti.com> Date: Mon, Apr 9, 2012 at 10:11 AM Subject: Re: [PATCHv2 0/5] coupled cpuidle state support To: Colin Cross <ccross(a)android.com> Cc: linux-kernel(a)vger.kernel.org, linux-arm-kernel(a)lists.infradead.org, linux-pm(a)lists.linux-foundation.org, Kevin Hilman <khilman(a)ti.com>, Len Brown <len.brown(a)intel.com>, Trinabh Gupta <g.trinabh(a)gmail.com>, Arjan van de Ven <arjan(a)linux.intel.com>, Deepthi Dharwar <deepthi(a)linux.vnet.ibm.com>, Greg Kroah-Hartman <gregkh(a)suse.de>, Kay Sievers <kay.sievers(a)vrfy.org>, Daniel Lezcano <daniel.lezcano(a)linaro.org>, Amit Kucheria < amit.kucheria(a)linaro.org>, Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>, Rob Lee <rob.lee(a)linaro.org> On Friday 30 March 2012 06:23 PM, Santosh Shilimkar wrote: > Colin, > > On Friday 16 March 2012 05:07 AM, Colin Cross wrote: >> On Wed, Mar 14, 2012 at 11:29 AM, Colin Cross <ccross(a)android.com> wrote: > > [...] > >>> >>> v2: >>> * removed the coupled lock, replacing it with atomic counters >>> * added a check for outstanding pokes before beginning the >>> final transition to avoid extra wakeups >>> * made the cpuidle_coupled struct completely private >>> * fixed kerneldoc comment formatting >>> * added a patch with a helper function for resynchronizing >>> cpus after aborting idle >>> * added a patch (not for merging) to add trace events for >>> verification and performance testing >> >> I forgot to mention, this patch series is on v3.3-rc7, and will >> conflict with the cpuidle timekeeping patches. If those go in first >> (which is likely), I will rework this series on top of it. I left it >> on v3.3-rc7 now to make testing easier. > > I have re-based your series against Len Browns > next branch [1] which has time keeping and other cpuidle patches. > Have also folded the CPU hotplug fix which I posted in the > original coupled idle patch. > As you know, we have been playing around this series for OMAP for last few weeks. This version series seems to work as intended and found it pretty stable in my testing. Apart from the cpu hotplug fix and the trace event comment, series looks fine to me. FWIW, Reviewed-by: Santosh Shilimkar <santosh.shilimkar(a)ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar(a)ti.com> An updated version of this series along with OMAP cpuidle driver updates against 3.4-rc2 is available here [1] in case some body is interested looking at it. Regards Santosh [1] git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/coupled_cpuidle-rebase

13 years, 3 months

qemu & hardware gfx acceleration

by John Stultz

So the Google Android team just posted this: http://feedproxy.google.com/~r/blogspot/hsDu/~3/OCt1AQzfyWI/faster-emulator… Which shows their device emulator running w/ hardware acceleration. Since I know they started with qemu, I was curious if there was any details as to if these sorts of changes were making it back upstream to qemu, or if qemu had its own plans for hardware acceleration? Unfortunately there's little technical details in the post above. The video is clearly running on OS X, so I'm not sure if this will also be usable w/ Linux hosts, but I could be wrong there. thanks -john

13 years, 3 months

[ACTIVITY] Linaro Android Team 3/28-4/3

by Zach Pfeffer

Linaro Android Highlights 3/28 - 4/3 Linaro Android now at 4.0.4 Released Android 5.0 ;) Completed big.LITTLE system tests Fixed WiFi bug on Origen See all the highlights at: https://wiki.linaro.org/Platform/Android/Meetings/2012-04-04 -- 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, 3 months

Re: [PATCH] ACPI-Thermal: Make Thermal trip points writeable

by Amit Daniel Kachhap

Hi Durgadoss, Instead of making all the trip-points of a thermal zone writeable we should only allow non-critical trip points to be writeable. Thanks, Amit Daniel > -----Original Message----- > From: Durgadoss R <durgadoss.r(a)intel.com> > Sent: Friday, January 27, 2012 9:58 PM > To: linux-acpi(a)vger.kernel.org > Cc: lenb(a)kernel.org; rui.zhang(a)intel.com; durgadoss.r(a)intel.com > Subject: [PATCH] ACPI-Thermal: Make Thermal trip points writeable >Some of the thermal drivers using the Generic Thermal Framework >require (all/some) trip points to be writeable. This patch makes >the trip point temperatures writeable on a per-trip point basis, >and modifies the required function call in thermal.c. This patch >also updates the Documentation to reflect the new change. > >Signed-off-by: Durgadoss R <durgadoss.r(a)intel.com> >--- >v1 >* patch1/2: Code for making trip points writeable >* patch2/2: Change the callee in thermal.c >v2 >* Make both the changes in a single patch >* Update Documentation/thermal/sysfs-api.txt >--- > Documentation/thermal/sysfs-api.txt | 4 +- > drivers/acpi/thermal.c | 4 +- > drivers/thermal/thermal_sys.c | 127 ++++++++++++++++++++++------------- > include/linux/thermal.h | 10 ++- > 4 files changed, 91 insertions(+), 54 deletions(-) > >diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt >index b61e46f..cd1476c 100644 >--- a/Documentation/thermal/sysfs-api.txt >+++ b/Documentation/thermal/sysfs-api.txt >@@ -32,7 +32,8 @@ temperature) and throttle appropriate devices. > > 1.1 thermal zone device interface > 1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *name, >- int trips, void *devdata, struct thermal_zone_device_ops *ops) >+ int trips, int flag, void *devdata, >+ struct thermal_zone_device_ops *ops) > > This interface function adds a new thermal zone device (sensor) to > /sys/class/thermal folder as thermal_zone[0-*]. It tries to bind all the >@@ -40,6 +41,7 @@ temperature) and throttle appropriate devices. > > name: the thermal zone name. > trips: the total number of trip points this thermal zone supports. >+ flag: Bit string: If 'n'th bit is set, then trip point 'n' is writeable. > devdata: device private data > ops: thermal zone device call-backs. > .bind: bind the thermal zone device with a thermal cooling device. >diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c >index 48fbc64..1c3133e 100644 >--- a/drivers/acpi/thermal.c >+++ b/drivers/acpi/thermal.c >@@ -845,7 +845,7 @@ static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz) > > if (tz->trips.passive.flags.valid) > tz->thermal_zone = >- thermal_zone_device_register("acpitz", trips, tz, >+ thermal_zone_device_register("acpitz", trips, 0, tz, > &acpi_thermal_zone_ops, > tz->trips.passive.tc1, > tz->trips.passive.tc2, >@@ -853,7 +853,7 @@ static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz) > tz->polling_frequency*100); > else > tz->thermal_zone = >- thermal_zone_device_register("acpitz", trips, tz, >+ thermal_zone_device_register("acpitz", trips, 0, tz, > &acpi_thermal_zone_ops, > 0, 0, 0, > tz->polling_frequency*100); >diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c >index dd9a574..3a4341e 100644 >--- a/drivers/thermal/thermal_sys.c >+++ b/drivers/thermal/thermal_sys.c >@@ -220,6 +220,28 @@ trip_point_temp_show(struct device *dev, struct device_attribute *attr, > } > > static ssize_t >+trip_point_temp_store(struct device *dev, struct device_attribute *attr, >+ const char *buf, size_t count) >+{ >+ struct thermal_zone_device *tz = to_thermal_zone(dev); >+ int trip, ret; >+ unsigned long temperature; >+ >+ if (!tz->ops->set_trip_temp) >+ return -EPERM; >+ >+ if (!sscanf(attr->attr.name, "trip_point_%d_temp", &trip)) >+ return -EINVAL; >+ >+ if (kstrtoul(buf, 10, &temperature)) >+ return -EINVAL; >+ >+ ret = tz->ops->set_trip_temp(tz, trip, temperature); >+ >+ return ret ? ret : count; >+} >+ >+static ssize_t > passive_store(struct device *dev, struct device_attribute *attr, > const char *buf, size_t count) > { >@@ -286,49 +308,6 @@ static DEVICE_ATTR(mode, 0644, mode_show, mode_store); > static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show, \ > passive_store); > >-static struct device_attribute trip_point_attrs[] = { >- __ATTR(trip_point_0_type, 0444, trip_point_type_show, NULL), >- __ATTR(trip_point_0_temp, 0444, trip_point_temp_show, NULL), >- __ATTR(trip_point_1_type, 0444, trip_point_type_show, NULL), >- __ATTR(trip_point_1_temp, 0444, trip_point_temp_show, NULL), >- __ATTR(trip_point_2_type, 0444, trip_point_type_show, NULL), >- __ATTR(trip_point_2_temp, 0444, trip_point_temp_show, NULL), >- __ATTR(trip_point_3_type, 0444, trip_point_type_show, NULL), >- __ATTR(trip_point_3_temp, 0444, trip_point_temp_show, NULL), >- __ATTR(trip_point_4_type, 0444, trip_point_type_show, NULL), >- __ATTR(trip_point_4_temp, 0444, trip_point_temp_show, NULL), >- __ATTR(trip_point_5_type, 0444, trip_point_type_show, NULL), >- __ATTR(trip_point_5_temp, 0444, trip_point_temp_show, NULL), >- __ATTR(trip_point_6_type, 0444, trip_point_type_show, NULL), >- __ATTR(trip_point_6_temp, 0444, trip_point_temp_show, NULL), >- __ATTR(trip_point_7_type, 0444, trip_point_type_show, NULL), >- __ATTR(trip_point_7_temp, 0444, trip_point_temp_show, NULL), >- __ATTR(trip_point_8_type, 0444, trip_point_type_show, NULL), >- __ATTR(trip_point_8_temp, 0444, trip_point_temp_show, NULL), >- __ATTR(trip_point_9_type, 0444, trip_point_type_show, NULL), >- __ATTR(trip_point_9_temp, 0444, trip_point_temp_show, NULL), >- __ATTR(trip_point_10_type, 0444, trip_point_type_show, NULL), >- __ATTR(trip_point_10_temp, 0444, trip_point_temp_show, NULL), >- __ATTR(trip_point_11_type, 0444, trip_point_type_show, NULL), >- __ATTR(trip_point_11_temp, 0444, trip_point_temp_show, NULL), >-}; >- >-#define TRIP_POINT_ATTR_ADD(_dev, _index, result) \ >-do { \ >- result = device_create_file(_dev, \ >- &trip_point_attrs[_index * 2]); \ >- if (result) \ >- break; \ >- result = device_create_file(_dev, \ >- &trip_point_attrs[_index * 2 + 1]); \ >-} while (0) >- >-#define TRIP_POINT_ATTR_REMOVE(_dev, _index) \ >-do { \ >- device_remove_file(_dev, &trip_point_attrs[_index * 2]); \ >- device_remove_file(_dev, &trip_point_attrs[_index * 2 + 1]); \ >-} while (0) >- > /* sys I/F for cooling device */ > #define to_cooling_device(_dev) \ > container_of(_dev, struct thermal_cooling_device, device) >@@ -1112,9 +1091,54 @@ void thermal_zone_device_update(struct thermal_zone_device *tz) > EXPORT_SYMBOL(thermal_zone_device_update); > > /** >+ * create_trip_type_attr - creates a trip point type attribute >+ * @tz: the thermal zone device >+ * @indx: index into the trip_type_attrs array >+ */ >+static int create_trip_type_attr(struct thermal_zone_device *tz, int indx) >+{ >+ char attr_name[THERMAL_NAME_LENGTH]; >+ >+ snprintf(attr_name, THERMAL_NAME_LENGTH, "trip_point_%d_type", indx); >+ >+ sysfs_attr_init(&tz->trip_type_attrs[indx].attr); >+ tz->trip_type_attrs[indx].attr.name = attr_name; >+ tz->trip_type_attrs[indx].attr.mode = S_IRUGO; >+ tz->trip_type_attrs[indx].show = trip_point_type_show; >+ >+ return device_create_file(&tz->device, &tz->trip_type_attrs[indx]); >+} >+ >+/** >+ * create_trip_temp_attr - creates a trip point temp attribute >+ * @tz: the thermal zone device >+ * @indx: index into the trip_type_attrs array >+ * @writeable: A flag: If 1, 'this' trip point is writeable; otherwise not >+ */ >+static int create_trip_temp_attr(struct thermal_zone_device *tz, >+ int indx, int writeable) >+{ >+ char attr_name[THERMAL_NAME_LENGTH]; >+ >+ snprintf(attr_name, THERMAL_NAME_LENGTH, "trip_point_%d_temp", indx); >+ >+ sysfs_attr_init(&tz->trip_temp_attrs[indx].attr); >+ tz->trip_temp_attrs[indx].attr.name = attr_name; >+ tz->trip_temp_attrs[indx].attr.mode = S_IRUGO; >+ tz->trip_temp_attrs[indx].show = trip_point_temp_show; >+ if (writeable) { >+ tz->trip_temp_attrs[indx].attr.mode |= S_IWUSR; >+ tz->trip_temp_attrs[indx].store = trip_point_temp_store; >+ } >+ >+ return device_create_file(&tz->device, &tz->trip_temp_attrs[indx]); >+} >+ >+/** > * thermal_zone_device_register - register a new thermal zone device > * @type: the thermal zone device type > * @trips: the number of trip points the thermal zone support >+ * @flag: a bit string indicating the writeablility of trip points > * @devdata: private device data > * @ops: standard thermal zone device callbacks > * @tc1: thermal coefficient 1 for passive calculations >@@ -1130,7 +1154,7 @@ EXPORT_SYMBOL(thermal_zone_device_update); > * section 11.1.5.1 of the ACPI specification 3.0. > */ > struct thermal_zone_device *thermal_zone_device_register(char *type, >- int trips, void *devdata, >+ int trips, int flag, void *devdata, > const struct thermal_zone_device_ops *ops, > int tc1, int tc2, int passive_delay, int polling_delay) > { >@@ -1199,9 +1223,15 @@ struct thermal_zone_device *thermal_zone_device_register(char *type, > } > > for (count = 0; count < trips; count++) { >- TRIP_POINT_ATTR_ADD(&tz->device, count, result); >+ result = create_trip_type_attr(tz, count); > if (result) > goto unregister; >+ >+ result = create_trip_temp_attr(tz, count, >+ (flag & (1 << count))); >+ if (result) >+ goto unregister; >+ > tz->ops->get_trip_type(tz, count, &trip_type); > if (trip_type == THERMAL_TRIP_PASSIVE) > passive = 1; >@@ -1279,9 +1309,10 @@ void thermal_zone_device_unregister(struct thermal_zone_device *tz) > if (tz->ops->get_mode) > device_remove_file(&tz->device, &dev_attr_mode); > >- for (count = 0; count < tz->trips; count++) >- TRIP_POINT_ATTR_REMOVE(&tz->device, count); >- >+ for (count = 0; count < tz->trips; count++) { >+ device_remove_file(&tz->device, &tz->trip_type_attrs[count]); >+ device_remove_file(&tz->device, &tz->trip_temp_attrs[count]); >+ } > thermal_remove_hwmon_sysfs(tz); > release_idr(&thermal_tz_idr, &thermal_idr_lock, tz->id); > idr_destroy(&tz->idr); >diff --git a/include/linux/thermal.h b/include/linux/thermal.h >index 47b4a27..4aa5a45 100644 >--- a/include/linux/thermal.h >+++ b/include/linux/thermal.h >@@ -58,6 +58,8 @@ struct thermal_zone_device_ops { > enum thermal_trip_type *); > int (*get_trip_temp) (struct thermal_zone_device *, int, > unsigned long *); >+ int (*set_trip_temp) (struct thermal_zone_device *, int, >+ unsigned long); > int (*get_crit_temp) (struct thermal_zone_device *, unsigned long *); > int (*notify) (struct thermal_zone_device *, int, > enum thermal_trip_type); >@@ -89,6 +91,8 @@ struct thermal_zone_device { > int id; > char type[THERMAL_NAME_LENGTH]; > struct device device; >+ struct device_attribute trip_temp_attrs[THERMAL_MAX_TRIPS]; >+ struct device_attribute trip_type_attrs[THERMAL_MAX_TRIPS]; > void *devdata; > int trips; > int tc1; >@@ -137,9 +141,9 @@ enum { > }; > #define THERMAL_GENL_CMD_MAX (__THERMAL_GENL_CMD_MAX - 1) > >-struct thermal_zone_device *thermal_zone_device_register(char *, int, void *, >- const struct thermal_zone_device_ops *, int tc1, int tc2, >- int passive_freq, int polling_freq); >+struct thermal_zone_device *thermal_zone_device_register(char *, int, int, >+ void *, const struct thermal_zone_device_ops *, int tc1, >+ int tc2, int passive_freq, int polling_freq); > void thermal_zone_device_unregister(struct thermal_zone_device *); > > int thermal_zone_bind_cooling_device(struct thermal_zone_device *, int, >-- >1.7.1 >

13 years, 3 months

Re: Linux 3.4-rc1

by Rob Clark

On Sat, Mar 31, 2012 at 6:58 PM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > - drm dma-buf prime support. Dave Airlie sent me the pull request but > didn't push very hard for it, it's in my "ok, I can still pull it for > 3.4 if individual DRM driver people tell me that it will make their > lives easier." So this is in limbo - I have nothing against it, but I > won't pull unless I get a few people say "yes, please". yes, please :-) Note that the core drm dma-buf/prime support has already been reviewed by a lot of folks, and tested with a few different drivers (exynos, omapdrm, i915, nouveau, udl) with some driver support that could be pushed for 3.5 cycle if the core support makes it in for 3.4 cycle. BR, -R

13 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev