[RFC] Stable/Development Overlay for Ubuntu LEB
Hi, Following some complains and issues with the way we're currently maintaining our main Overlay PPA, I'd like to propose a new way to produce the Ubuntu LEBs, by generating Stable and Unstable/Development focused images. At the moment all the development work for the Ubuntu LEB happens at 2 different repositories: - Staging PPA (https://launchpad.net/~linaro-maintainers/+archive/staging-overlay): test and development related builds, usually broken but a common place to share the packages before making them official at the LEB. - Overlay PPA (https://launchpad.net/~linaro-maintainers/+archive/overlay): main overlay repository, and common location for hardware enablement packages and released components by Linaro (e.g. Linux Linaro, glmark2, etc). Using just one single main repository seems fine until you have at least one board fully enabled, with dependencies going from Kernel to user space, as the enablement usually doesn't keep up with the latest development and updates produced by the Landing Teams and Working Groups. One simple case is what happened with Pandaboard, that had a fully enabled userspace (OpenGL ES2.0 and HW Decode), but needed to be locked down with an specific kernel and user space packages. Differently than what we have with Android images, we don't just produce one single tarball where the user is unable to change or extend. At our side we're maintaining a real distro, and updating/upgrading packages is expected. Once we release a fully enabled build, we can't simply break it down with newer updates because will make all users unhappy, which is bad for the users and for Linaro (as it's hard to compare hw enablement, produce demos and such). At the same time, we don't want to be locked down into specific versions, because one of our goals is to make sure the hardware enablement is always matching the latest kernel/components available. Working with upstream based components helps us with development and validation, and also identifying what is still needed to get everything working from time to time. Looking at the problem, here's what I think it'd help to fix the situation: 1 - Overlay PPA becomes the main repository for basic platform development, without having any hardware specific package (not even the kernel): This PPA would be used by all the images we're producing (stable/unstable), as all the changes would be just related with the distribution. Once we get newer components that are not related with hardware enablement, and not critical enough to break compatibility across images, we would be integrating them at this repository (e.g. powertop, glmark2, libpng, libjpeg-turbo, etc). 2 - We create the Development Overlay PPA, to be the main place carrying the hardware related pieces, like kernel, drivers and multimedia: This would be the main PPA used during our own development, always containing the latest kernel packages from the Linux Linaro and Landing Team trees. Here we could also integrate components related with hardware enablement that are not for prime use yet, but would help people that are always looking for the latest stuff available. 3 - Create a set of Stable PPAs for every board we're officially supporting: Here the goal would be to have a single place where we can push the enablement related changes that are known to be working. At the Pandaboard case this PPA would contain the 3.1 based kernel with SGX and HW video decoding working out of the box. Once a new snapshot based on the development release is known to work in a satisfactory way, we would simply just copy them over the Stable PPA for the respective board. This would also help the cases where we have packages with hw enablement changes that conflict with other boards. So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway. I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA. Please let me know what you all think, as we could have this model working with the 12.04 Ubuntu Precise based images already. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Config fragment for Versatile Express
On Mon, 2012-04-02 at 12:30 -0700, John Stultz wrote: The difficulty is that as Tixy earlier pointed out, are that the LT kernel trees are mainline based, and thus aren't based off of something that would contain the base/distro/board config fragments. One approach we might be able to use is if the board defconfigs really are minimal, and restricted in scope to only the board options, we could switch the merge order (board/distro/base). This way the LT's additive defconfig can be used (from arch/arm/configs/ ) and we can still also get consistent generic options as well. The mainline defconfigs aren't minimal in the sense we want, they include things like file-systems and networking options so somebody can build a usable kernel, and I think it's sensible to keep it that way. For Linaro's purposes we would need a new board config. We could make that minimal, but we get back to the idea that topic branches which change configs would need to sit on top of the topic with this config. Perhaps that is something we can live with if a directory-of-config-fragments approach is deemed undesirable. It's a pity that the title of the thread possibly means no one from other LTs are reading. (Probably a bit late to change it now and get noticed.) -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Stable/Development Overlay for Ubuntu LEB
On Tue, Apr 3, 2012 at 9:08 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: snip Looking at the problem, here's what I think it'd help to fix the situation: 1 - Overlay PPA becomes the main repository for basic platform development, without having any hardware specific package (not even the kernel): This PPA would be used by all the images we're producing (stable/unstable), as all the changes would be just related with the distribution. Once we get newer components that are not related with hardware enablement, and not critical enough to break compatibility across images, we would be integrating them at this repository (e.g. powertop, glmark2, libpng, libjpeg-turbo, etc). 2 - We create the Development Overlay PPA, to be the main place carrying the hardware related pieces, like kernel, drivers and multimedia: This would be the main PPA used during our own development, always containing the latest kernel packages from the Linux Linaro and Landing Team trees. Here we could also integrate components related with hardware enablement that are not for prime use yet, but would help people that are always looking for the latest stuff available. 3 - Create a set of Stable PPAs for every board we're officially supporting: Here the goal would be to have a single place where we can push the enablement related changes that are known to be working. At the Pandaboard case this PPA would contain the 3.1 based kernel with SGX and HW video decoding working out of the box. Once a new snapshot based on the development release is known to work in a satisfactory way, we would simply just copy them over the Stable PPA for the respective board. This would also help the cases where we have packages with hw enablement changes that conflict with other boards. So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway. I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA. What would the monthly release be based on? The stable PPA? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Config fragment for Versatile Express
On 04/03/2012 01:43 PM, Jon Medhurst (Tixy) wrote: On Mon, 2012-04-02 at 12:30 -0700, John Stultz wrote: The difficulty is that as Tixy earlier pointed out, are that the LT kernel trees are mainline based, and thus aren't based off of something that would contain the base/distro/board config fragments. One approach we might be able to use is if the board defconfigs really are minimal, and restricted in scope to only the board options, we could switch the merge order (board/distro/base). This way the LT's additive defconfig can be used (from arch/arm/configs/ ) and we can still also get consistent generic options as well. The mainline defconfigs aren't minimal in the sense we want, they include things like file-systems and networking options so somebody can build a usable kernel, and I think it's sensible to keep it that way. For Linaro's purposes we would need a new board config. We could make that minimal, but we get back to the idea that topic branches which change configs would need to sit on top of the topic with this config. Perhaps that is something we can live with if a directory-of-config-fragments approach is deemed undesirable. It's a pity that the title of the thread possibly means no one from other LTs are reading. (Probably a bit late to change it now and get noticed.) I hope not. For Samsung LT kernel, we have followed an approach where in the commits in John's linaro_config_3.3 branch are taken to be stable commits and we have put those commits as the very first set of commits on LT kernel. Our LT kernel being a _serialized_ kernel where topic branches sit one over the other, the related config fragments are made part of the topic branches. A sample view of the same is posted at [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (lt/next) -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Config fragment for Versatile Express
On Tue, 2012-04-03 at 14:51 +0530, Tushar Behera wrote: For Samsung LT kernel, we have followed an approach where in the commits in John's linaro_config_3.3 branch are taken to be stable commits and we have put those commits as the very first set of commits on LT kernel. Our LT kernel being a _serialized_ kernel where topic branches sit one over the other, the related config fragments are made part of the topic branches. A sample view of the same is posted at [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (lt/next) The Samsung tree has the non samsung config files, like linaro-base.conf. I was wondering if that would cause merge problems if every LT had them and at possibly different versions. I guess it doesn't matter so long as all LTs got them from the same definitive 'upstream' source, and that they didn't edit them. I think it makes sense if this 'upstream' doesn't include board files though, they should come from LT trees. We also need a better upstream than John's personal Android tree :-) -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Config fragment for Versatile Express
On 04/03/2012 06:29 PM, Somebody in the thread at some point said: On Tue, 2012-04-03 at 14:51 +0530, Tushar Behera wrote: For Samsung LT kernel, we have followed an approach where in the commits in John's linaro_config_3.3 branch are taken to be stable commits and we have put those commits as the very first set of commits on LT kernel. Our LT kernel being a _serialized_ kernel where topic branches sit one over the other, the related config fragments are made part of the topic branches. A sample view of the same is posted at [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (lt/next) The Samsung tree has the non samsung config files, like linaro-base.conf. I was wondering if that would cause merge problems if every LT had them and at possibly different versions. I guess it doesn't matter so long as all LTs got them from the same definitive 'upstream' source, and that they didn't edit them. Squidging them all together will anyway require a lot of automated conflict resolution happening, favouring later version of this common file would probably not be noticable. I'll have a go at Tushar's method tomorrow it looks like a good plan. I think it makes sense if this 'upstream' doesn't include board files though, they should come from LT trees. Normally board files means mach-xyz/board*.c for me I am guessing you mean board-specific defconfigs ^^ -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Config fragment for Versatile Express
On Tue, 2012-04-03 at 18:43 +0800, Andy Green wrote: On 04/03/2012 06:29 PM, Somebody in the thread at some point said: I think it makes sense if this 'upstream' doesn't include board files though, they should come from LT trees. Normally board files means mach-xyz/board*.c for me I am guessing you mean board-specific defconfigs ^^ Indeed I did. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Stable/Development Overlay for Ubuntu LEB
On Tue, Apr 3, 2012 at 6:10 AM, Amit Kucheria amit.kuche...@linaro.org wrote: On Tue, Apr 3, 2012 at 9:08 AM, Ricardo Salveti So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway. I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA. What would the monthly release be based on? The stable PPA? We'd be producing the release based on both the stable and dev/unstable PPA. Stable for users that just want to have the latest userspace working with an enabled kernel, and unstable for brave users and linaro developers that are mainly concerned about upstream support and enablement there. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Stable/Development Overlay for Ubuntu LEB
On Tue, Apr 3, 2012 at 3:40 PM, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Tue, Apr 3, 2012 at 6:10 AM, Amit Kucheria amit.kuche...@linaro.org wrote: On Tue, Apr 3, 2012 at 9:08 AM, Ricardo Salveti So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway. I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA. What would the monthly release be based on? The stable PPA? We'd be producing the release based on both the stable and dev/unstable PPA. Stable for users that just want to have the latest userspace working with an enabled kernel, and unstable for brave users and linaro developers that are mainly concerned about upstream support and enablement there. This will certainly be useful for a certain category of users and increase our community size. However, I worry about a situation where everybody settles down on the stable release and the unstable versions don't get much testing. Can there be some commitment from those responsible for HW enablement (kernel porting, binary blobs, etc.) to provide periodic refreshes of these components? e.g. every 3 months. IOW, some predictable forward momentum for the stable releases instead of continuing divergence similar to internal BSPs. /Amit ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Stable/Development Overlay for Ubuntu LEB
On Tue, Apr 3, 2012 at 10:30 AM, Amit Kucheria amit.kuche...@linaro.org wrote: On Tue, Apr 3, 2012 at 3:40 PM, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Tue, Apr 3, 2012 at 6:10 AM, Amit Kucheria amit.kuche...@linaro.org wrote: On Tue, Apr 3, 2012 at 9:08 AM, Ricardo Salveti So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway. I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA. What would the monthly release be based on? The stable PPA? We'd be producing the release based on both the stable and dev/unstable PPA. Stable for users that just want to have the latest userspace working with an enabled kernel, and unstable for brave users and linaro developers that are mainly concerned about upstream support and enablement there. This will certainly be useful for a certain category of users and increase our community size. However, I worry about a situation where everybody settles down on the stable release and the unstable versions don't get much testing. Can there be some commitment from those responsible for HW enablement (kernel porting, binary blobs, etc.) to provide periodic refreshes of these components? e.g. every 3 months. IOW, some predictable forward momentum for the stable releases instead of continuing divergence similar to internal BSPs. Yeah, that's the goal. Our effort inside Linaro is to always enable and test the unstable release, so we can make sure our development is progressing properly, and that the vendor is also publishing the blogs at a useful schedule. The stable would be initially a working snapshot of the unstable PPA, to be used by end users. We would not spend resources validating it over the cycles, as I'd expect the maintenance to be more a community driven effort, that can be owned by the vendor itself, or just by community users/developers. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [PATCH 1/4] thermal: Add a new trip type to use cooling device instance number
Hello,
On Thu, Feb 23, 2012 at 04:50:14PM +0530, Amit Kachhap wrote:
On 23 February 2012 12:16, R, Durgadoss durgados...@intel.com wrote:
Hi Amit,
-Original Message-
From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
Kachhap
Sent: Wednesday, February 22, 2012 3:44 PM
To: linux...@lists.linux-foundation.org
Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux-
a...@vger.kernel.org; l...@kernel.org; linaro-dev@lists.linaro.org;
amit.kach...@linaro.org; R, Durgadoss; rob@linaro.org;
patc...@linaro.org
Subject: [PATCH 1/4] thermal: Add a new trip type to use cooling device
instance number
This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
device instance number. This helps the cooling device registered as
different instances to perform appropriate cooling action decision in
the set_cur_state call back function.
Also since the trip temperature's are in ascending order so some logic
is put in place to skip the un-necessary checks.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
Documentation/thermal/sysfs-api.txt | 4 +-
drivers/thermal/thermal_sys.c | 45
--
include/linux/thermal.h | 1 +
3 files changed, 45 insertions(+), 5 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-
api.txt
index 1733ab9..7a0c080 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -184,8 +184,8 @@ trip_point_[0-*]_temp
trip_point_[0-*]_type
Strings which indicate the type of the trip point.
- E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
- thermal zone.
+ E.g. it can be one of critical, hot, passive, active[0-1],
+ state-active[0-*] for ACPI thermal zone.
RO, Optional
cdev[0-*]
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 220ce7e..d4c9b20 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct
device_attribute *attr,
return sprintf(buf, passive\n);
case THERMAL_TRIP_ACTIVE:
return sprintf(buf, active\n);
+ case THERMAL_TRIP_STATE_ACTIVE:
+ return sprintf(buf, state-active\n);
default:
return sprintf(buf, unknown\n);
}
@@ -1034,10 +1036,10 @@ EXPORT_SYMBOL(thermal_cooling_device_unregister);
void thermal_zone_device_update(struct thermal_zone_device *tz)
{
- int count, ret = 0;
- long temp, trip_temp;
+ int count, ret = 0, inst_id;
+ long temp, trip_temp, max_state, last_trip_change = 0;
enum thermal_trip_type trip_type;
- struct thermal_cooling_device_instance *instance;
+ struct thermal_cooling_device_instance *instance, *state_instance;
struct thermal_cooling_device *cdev;
mutex_lock(tz-lock);
@@ -1086,6 +1088,43 @@ void thermal_zone_device_update(struct
thermal_zone_device *tz)
cdev-ops-set_cur_state(cdev, 0);
}
break;
+ case THERMAL_TRIP_STATE_ACTIVE:
+ list_for_each_entry(instance, tz-cooling_devices,
+ node) {
+ if (instance-trip != count)
+ continue;
+
+ if (temp = last_trip_change)
+ continue;
+
+ inst_id = 0;
+ /*
+ *For this instance how many instance of same
+ *cooling device occured before
+ */
+
+ list_for_each_entry(state_instance,
+ tz-cooling_devices, node) {
+ if (instance-cdev ==
+ state_instance-cdev)
+ inst_id++;
+ if (state_instance-trip == count)
+ break;
+ }
Can you explain a bit more on this loop and the set_cur_state below ?
Sorry, I don't get the logic behind this..
This loop is basically finding the instance id of the same cooling device.
Say we have done like this,
thermal_zone_bind_cooling_device(thermal, 2, cdev);
thermal_zone_bind_cooling_device(thermal, 3, cdev);
thermal_zone_bind_cooling_device(thermal, 4, cdev);
In above same cooling device cdev is binded to trip no 2,3 and 4 with
ANN: dumb HTTP git-hosting on git.linaro.org
Greetings, git.linaro.org supports scalable git clones over HTTP. This was done to eliminate huge resources consumption by clones over GIT and smart HTTP protocols by serving files directly with Apache server. To clone read-only git tree use following link: git clone http://git.linaro.org/*git-ro*/people/username/gitproject.git Your own tree is accessible over dumb HTTP protocol by default after creation and you need additional steps to setup only if you are using objects/info/alternates mechanism to borrow objects from other object stores. Then you have to setup objects/info/http-alternates file with appropriate contents (links to remote repositories) and ensure that alternate repository is also accessible over HTTP protocol. Please refer to https://wiki.linaro.org/Process/GitHostingAccounts for more information. -- WBR, Georgy Redkozubov 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Config fragment for Versatile Express
On 04/03/2012 03:59 PM, Jon Medhurst (Tixy) wrote: On Tue, 2012-04-03 at 14:51 +0530, Tushar Behera wrote: For Samsung LT kernel, we have followed an approach where in the commits in John's linaro_config_3.3 branch are taken to be stable commits and we have put those commits as the very first set of commits on LT kernel. Our LT kernel being a _serialized_ kernel where topic branches sit one over the other, the related config fragments are made part of the topic branches. A sample view of the same is posted at [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (lt/next) The Samsung tree has the non samsung config files, like linaro-base.conf. I was wondering if that would cause merge problems if every LT had them and at possibly different versions. I guess it doesn't This method works well if the common config fragments, once committed to some upstream tree, are stable. Then only it makes sense to base other topics on top of this. matter so long as all LTs got them from the same definitive 'upstream' source, and that they didn't edit them. I think it makes sense if this 'upstream' doesn't include board files though, they should come from LT trees. As for the board specific fragments, I feel it would be better if the config-upstream tree has the initial fragment (which I suppose is minimal enough to compile the common kernel). That way anyone taking linux-linaro-tracking can have at least a working setup. As and when some topics get merged to mainline, we can move those config-fragments to upstream tree. We also need a better upstream than John's personal Android tree :-) I suppose, it would soon get a place in linux-linaro-tracking. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
