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: Config fragment for Versatile Express
On Tue, 2012-04-03 at 09:13 +0800, Andy Green wrote: > On 04/03/2012 02:58 AM, Somebody in the thread at some point said: > > On Mon, 2012-04-02 at 11:18 -0700, John Stultz wrote: > >> On 04/02/2012 10:29 AM, Jon Medhurst (Tixy) wrote: > >>> On Mon, 2012-04-02 at 08:37 -0700, John Stultz wrote: > On 03/31/2012 02:17 AM, Jon Medhurst (Tixy) wrote: > > We almost certainly need board specific android and ubuntu fragments as > > well, so I'll add vexpress-android.conf and vexpress-ubuntu.conf as > > well. (Unless there is some magic to have conditional config options in > > a fragment?) > > No, the config fragments are pretty simple, so there's no conditional > logic in them. Your idea for a board-type.conf style split sounds like a > fair idea. Although, I'm curious what would be an example of this? > >>> > >>> There's often let's-just-get-it-working hacks produced, and sometimes > >>> you don't want to risk breaking other boards by putting things into a > >>> common config. > >>> > >>> My example of this is > >>> http://android.git.linaro.org/gitweb?p=kernel/vexpress-a9.git;a=commit;h=20a2abd40fff4d5942263c09b9852986c47aaa32 > >>> > >>> Of course, this could be an argument for not enabling such things. ;-) > >> > >> Ok. Interesting. I can see how this sort of flexibility is useful. So > >> I'm fine if folks want to add board-distro specific tweaks. Trying to > >> find some more unified way of building might be necessary, so folks > >> aren't having to customize things too drastically. Your directory method > >> seems like would solve this, but I need to spend some more time > >> understanding Andy's suggestion and understanding how it works with > >> Andrey's centralized tree. > > > > Possibly if we just had a symlink > > > > configs/omap_5430evm/base/main.conf --> > > arch/arm/configs/omap_5430evm_defconfig > > > > but then that defconfig has some non board specific stuff, like EXT > > file-systems configured. And Andrey's Android branch would have TI's > > Android topics, so that 'base' defconfig file would also gain TI's > > Android flavourings. (Neither of these issues might be a problem in > > practice.) > > It's really preferable to keep to one defconfig for everything but > sometimes that won't be possible (you were saying you might need more > than one for presumably very basic reasons). It depends what more than one defconfig means. I was suggesting that we have multiple fragments so topics could have there own fragment if necessary, for when people don't have stacked topics to modify a single defconfig. I also suggested it might be wise for a get-out-of-jail method so a board could override distro options. (Perhaps the later shouldn't be made part of the normal workflow and instead be a manual hack applied by distro maintainer in exceptional circumstances.) > In that case the config > deltas will need to be applied to n defconfigs as part of the rebase / > merge process creating the output tree. > > So it might be simpler instead of using multiple symlinks if the LT base > tree creates and maintains a text file that is a list of "defconfigs > this tree maintains" which will all get processed by the topic > management scripts in turn for each config delta when the flavourings > are added. I though the distro building would be using merge_config.sh to generate the .config for the build, therefore this would all just be as simple as having it use the argument "my-board-config-directory/*" instead of "my-board-config-file". For most cases I would guess even "cat my-board-config-directory/* >board.conf" would work. So perhaps we could allow each board to specify a shell script to generate a config rather than coming up with a mechanism we all agree on? We could also pass the distro as an argument so the script could apply hacks as appropriate. -- 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 wrote: > 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 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 wrote: > On Tue, Apr 3, 2012 at 6:10 AM, Amit Kucheria > 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 wrote: > On Tue, Apr 3, 2012 at 3:40 PM, Ricardo Salveti > wrote: >> On Tue, Apr 3, 2012 at 6:10 AM, Amit Kucheria >> 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 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
> >> ---
> >> 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
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//.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: [linux-pm] [PATCH 1/4] thermal: Add a new trip type to use cooling device instance number
Hi Eduardo,
On 3 April 2012 19:45, Eduardo Valentin wrote:
> Hello,
>
> On Thu, Feb 23, 2012 at 04:50:14PM +0530, Amit Kachhap wrote:
>> On 23 February 2012 12:16, R, Durgadoss 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
>> >> ---
>> >> 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;
>> >> +
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
Hi Len/Rui, Any comment or feedback from your side about the status of this patch? Is it merge-able or major re-work is needed? I have fixed most of the comments in this patchset and currently working on some of the minor comments received and will submit them shortly. Regards, Amit Daniel On 19 March 2012 11:47, Amit Daniel Kachhap wrote: > 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 and > eduardo.valen...@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 g...@kroah.com > *Incorporated several review comments from eduardo.valen...@ti.com > *Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd > as discussed with Guenter Roeck and > Donggeun Kim (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 a new trip type THERMAL_TRIP_STATE_INSTANCE which passes > cooling device instance number and may be helpful for cpufreq cooling devices > to take the correct cooling action. This trip type avoids the temperature > comparision check again inside the cooling handler. > > 3) This patchset adds generic cpu cooling low level implementation through > frequency clipping and cpu hotplug. 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, > const struct cpumask *mask_val) > b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) > > 4) 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.3-rc7 > > A simple data/control flow diagrams is shown below, > > Core Linux thermal <-> Exynos thermal interface <- Temperature Sensor > | | > \|/ | > Cpufreq cooling device <--- > > > Amit Daniel Kachhap (6): > thermal: Add a new trip type to use cooling device instance number > thermal: Add generic cpufreq cooling implementation > thermal: Add generic cpuhotplug cooling implementation > hwmon: exynos4: Move thermal sensor driver to driver/thermal > directory > thermal: exynos4: Register the tmu sensor with the kernel thermal > layer > ARM: exynos4: Add thermal sensor driver platform device support > > Documentation/hwmon/exynos4_tmu | 81 --- > Documentation/thermal/cpu-cooling-api.txt | 76 +++ > Documentation/thermal/exynos4_tmu | 52 ++ > Documentation/thermal/sysfs-api.txt | 4 +- > arch/arm/mach-exynos/Kconfig | 11 + > arch/arm/mach-exynos/Makefile | 1 + > arch/arm/mach-exynos/clock.c | 4 + > arch/arm/mach-exynos/dev-tmu.c | 39 ++ > arch/arm/mach-exynos/include/mach/irqs.h | 2 + > arch/arm/mach-exynos/include/mach/map.h | 1 + > arch/arm/mach-exynos/mach-origen.c | 1 + > arch/arm/plat-samsung/include/plat/devs.h | 1 + > drivers/hwmon/Kconfig | 10 - >
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
Re: [linux-pm] [PATCH 1/4] thermal: Add a new trip type to use cooling device instance number
Hello,
On Wed, Apr 04, 2012 at 09:53:15AM +0530, Amit Kachhap wrote:
> Hi Eduardo,
>
> On 3 April 2012 19:45, Eduardo Valentin wrote:
> > Hello,
> >
> > On Thu, Feb 23, 2012 at 04:50:14PM +0530, Amit Kachhap wrote:
> >> On 23 February 2012 12:16, R, Durgadoss 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
> >> >> ---
> >> >> 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
