On Fri, May 11, 2012 at 12:09 AM, Jon Medhurst (Tixy) tixy@linaro.org wrote:

On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote:

...

Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7.

I may have misunderstood but....

Doesn't this mean on next Wednesday you be tracking Wednesdays tip, then on Thursdays move back in time to this Sundays rc7 release?

Yeah, I wondered about the same. In general I am very suspicious if we say we would have to go back and feel we might duplicate work in a direction where we shouldn't invest...

How bad is the tip revision you aim for Andrey? Maybe we can check how well that works and if there are problems collaboratively try to fix that with the goal to release from tip? e.g. with help from ARM and Samsung LT? Is that a bad idea?

On 11/05/12 06:57, Somebody in the thread at some point said:

On Fri, 2012-05-11 at 00:46 +0200, Alexander Sack wrote:

...

On Fri, May 11, 2012 at 12:09 AM, Jon Medhurst (Tixy)tixy@linaro.org wrote:

...

On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote:

...

Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7.

I may have misunderstood but....

Doesn't this mean on next Wednesday you be tracking Wednesdays tip, then on Thursdays move back in time to this Sundays rc7 release?

Yeah, I wondered about the same. In general I am very suspicious if we say we would have to go back and feel we might duplicate work in a direction where we shouldn't invest...

How bad is the tip revision you aim for Andrey? Maybe we can check how well that works and if there are problems collaboratively try to fix that with the goal to release from tip?

Should we not release based on a specific Linux rc or final release rather than some random intermediate commit. It seems a lot neater and easier to communicate.

We don't have to take this 'tracking' thing too far :-)

Tracking is tracking, it's best done at whatever current basis head is.

But what is a 'release' here? For normal mortals it's when Linus puts out a tag without the -rc bit, due to Linus' judgement that the breakages are largely ironed out.

When we talk about applying the Linaro Release-industrial complex with its mailing lists and rules and dedicated staff to a 'release' of tracking content, especially on this febrile unified tree, I think there's a bit of an impedence mismatch coming.

Being on some -rc or some other intermediate HEAD isn't going to make much odds, either that kernel performs overall better than a recent one at another HEAD or it doesn't, that's the only "release criteria". If the current one performs best and is on a random HEAD commit, we certainly shouldn't wind it backwards to last -rc that performs worse just because that's "easier to communicate".

Likewise in unified case, there might not be much choice about which recent kernels had most LTs participating with workable content, if that's on an intermediate HEAD we can't be sniffy.

-Andy

On 11/05/12 07:43, Somebody in the thread at some point said:

On Fri, 2012-05-11 at 07:14 +0800, Andy Green wrote:If

...

the current one performs best and is on a random HEAD commit, we certainly shouldn't wind it backwards to last -rc that performs worse just because that's "easier to communicate".

I agree, I wasn't envisioning winding backwards, more that we stop winding forwards at a chosen -rc, or stop merging topics on a Friday, bring the common tree up-to-date with the weekends Torvalds -rc, then build, test and fix this ready for Linaro RC on the Friday.

Right... the problem with that would have been though that on a random day - and Linaro's monthly release cycle is random for tracking - our tracking may be dead. Right now I have local tracking tree that's considerably ahead of last public push but OMAP4 boot dies in a novel and cool way we didn't get to the bottom of yet.

We have good local-to-LT reasons for having got ourselves into that situation, we took in 70 patches from TI that are fixes or improvements to core support we want to have in for 3.4. That reasoning might occur the day or week before this Linaro monthly release and we should again choose to temporarily trash the tree. Sometimes, we get demand to hold tracking for other reasons again asynchronous to monthly release.

In short monthly release action will have to make do with "last thing that was working best" as a single LT tree and for unified "last unified build that was working best for most trees", which sometimes might be weeks old. To facilitate the single LT case we are tagging our pushes we believe are worth something, even if they might go backwards sometimes as we integrate new drops of stuff.

For ARM LT the situation is a bit simpler, you have largely parallel feature trees with new - super valuable, don't get me wrong - content, in our case we have 1,000 - 2,000 patches with conflicting content to definitive stuff pouring in to mainline all the time. We usually can't do any special planning to converge with the monthly release. (Nor will it get better in medium term, 3.5 has a huge convulsion in hwmod coming that might send us back to the Stone Age for a while)

-Andy

On 11/05/12 08:32, Somebody in the thread at some point said:

On Fri, May 11, 2012 at 2:20 AM, Andy Greenandy.green@linaro.org wrote:

...

On 11/05/12 07:43, Somebody in the thread at some point said:

...

On Fri, 2012-05-11 at 07:14 +0800, Andy Green wrote:If

...

the current one performs best and is on a random HEAD commit, we certainly shouldn't wind it backwards to last -rc that performs worse just because that's "easier to communicate".

I agree, I wasn't envisioning winding backwards, more that we stop winding forwards at a chosen -rc, or stop merging topics on a Friday, bring the common tree up-to-date with the weekends Torvalds -rc, then build, test and fix this ready for Linaro RC on the Friday.

Right... the problem with that would have been though that on a random day - and Linaro's monthly release cycle is random for tracking - our tracking may be dead. Right now I have local tracking tree that's considerably ahead of last public push but OMAP4 boot dies in a novel and cool way we didn't get to the bottom of yet.

We have good local-to-LT reasons for having got ourselves into that situation, we took in 70 patches from TI that are fixes or improvements to core support we want to have in for 3.4. That reasoning might occur the day or week before this Linaro monthly release and we should again choose to temporarily trash the tree. Sometimes, we get demand to hold tracking for other reasons again asynchronous to monthly release.

In short monthly release action will have to make do with "last thing that was working best" as a single LT tree and for unified "last unified build that was working best for most trees", which sometimes might be weeks old. To facilitate the single LT case we are tagging our pushes we believe are worth something, even if they might go backwards sometimes as we integrate new drops of stuff.

For ARM LT the situation is a bit simpler, you have largely parallel feature trees with new - super valuable, don't get me wrong - content, in our case we have 1,000 - 2,000 patches with conflicting content to definitive stuff pouring in to mainline all the time. We usually can't do any special planning to converge with the monthly release. (Nor will it get better in medium term, 3.5 has a huge convulsion in hwmod coming that might send us back to the Stone Age for a while)

From my (granted high level) perspective keeping good logs/statistics of patches/topics that cause conflicts and pain over and over again might serve as good indication to target investment in upstreaming or frameworks improvements/refactoring.

I assume this idea has been played through? What's the plan forward to solve this problem? Maybe if we look closely there might be potential base framework topics hidden that could be tackled by our kernel WG to help you out mid/long term?

We have been doing quite a bit of musing and discussion about how to make this better, the main thing that would help is greater integration to other pieces of TI that are the "domain experts" for our topics.

That has problems though, we are focused on tracking Linus HEAD to produce featureful Linus release trees at very low latency. The member domain experts are focused on upstream solution on linux-omap-next basis, and at timescale mandated by upstream demands about how and with what their solutions must work.

I wish we could get KWG to do "something" that would help but I think the underlying issue is we are on a different basis than where all the effort is being poured into these topics by TI. Then we only see the result of that work when it comes back on our mainline basis after a long lag.

If we just waited for everything, there'd be no point having an LT tree, although my life would be easier ^^, it means we have to take or scavenge and rebase more or less aging pieces that we are alone with for uplevel. Surprisingly that has been fairly workable for us. For example there's 650 patches near the start of our tree we uplevelled from 3.1 basis back in Feb that provides the core OMAP4 and OMAP5 support. I don't find it hard to imagine a better flow but we are just one piece of the puzzle and there are genuine disconnects such as different goals leading to different basis-trees (and different belief about suitability of merge-managed trees as input to rebase-managed process).

In any event nobody can do anything about hwmod changes coming down the pike we will just have to adapt to whatever it is (I found people don't want to hear about how to get rid of hwmod altogether ^^).

We plan to discuss this in depth at the HK Connect with all the stakeholders and see if we can find a better way to interface that provides advantages to everyone.

-Andy

On 11/05/12 08:27, Somebody in the thread at some point said:

4. in between RCs, we only move mainline on our linux-linaro release

baseline forward if we see a working tracking build that wouldn't drop any topics that already made it into this RC cycle.

The probability of getting a good unified tree follows the kernel cycle, we all have good reasons to have tried to arrive at a good, working, release. Sometimes we only get a reasonably good result a week or two after Linus' release.

For that reason maybe you should just be trying to 'release' a release-basis unified tree, ie, the 3.4 one targeted now as the deliverable. It still has meaning to make a monthly release of that since it can collect stable mainline updates and updates from each LT release tree that happened in the meanwhile.

We do need to create these intermediate unified trees so we know what to fix on our trees so they can go in smoothly, but it matters less then if one day half the LT trees are missing on it since it's of interest only for LTs and platform guys to study what else needs solving on the LT trees.

I still think you won't get anywhere useful until we are trying to build the unified trees for real. Then we can start the needed work to make them fit together properly, until then we're treading water in "technical debt". Discussing how to run the tree is something to do later after gaining this experience.

I had a look at the LT gits

ARM Merge-managed integration-linux-vexpress 3.4-rc4 TI Rebase-managed tilt-tracking 3.4-rc4 Freescale Merge-managed lt-3.4 3.4-rc3 Samsung Rebase-managed tracking 3.4-rc3 STE Merge-managed integration-linux-ux500 3.4-rc6

(wow STE - on igloocommunity.org - have a LOT of patches! I thought we were leading the way)

Actually locally TILT are on -rc6 but there was almost no conflict coming between -rc4 and -rc6. If you take the approach to merge these trees, I found that late in the cycle it's usually pretty forgiving about some variation in basis.

So why not give these all a test merge today and see what starts falling out? I am sure we all have something to fix and there may be larger issues like two trees with conflicting versions of, I dunno, Mali driver, that needs planning to resolve. Or if people aren't using linux-linaro-core-tracking to get their CMA and so on, we need to know and start that migration.

-Andy

On 11/05/12 10:19, Somebody in the thread at some point said:

On Fri, May 11, 2012 at 3:43 AM, Andy Greenandy.green@linaro.org wrote:

...

On 11/05/12 08:27, Somebody in the thread at some point said:

...

4. in between RCs, we only move mainline on our linux-linaro release

baseline forward if we see a working tracking build that wouldn't drop any topics that already made it into this RC cycle.

The probability of getting a good unified tree follows the kernel cycle, we all have good reasons to have tried to arrive at a good, working, release. Sometimes we only get a reasonably good result a week or two after Linus' release.

For that reason maybe you should just be trying to 'release' a release-basis unified tree, ie, the 3.4 one targeted now as the deliverable. It still has meaning to make a monthly release of that since it can collect stable mainline updates and updates from each LT release tree that happened in the meanwhile.

We do need to create these intermediate unified trees so we know what to fix on our trees so they can go in smoothly, but it matters less then if one day half the LT trees are missing on it since it's of interest only for LTs and platform guys to study what else needs solving on the LT trees.

I still think you won't get anywhere useful until we are trying to build the unified trees for real. Then we can start the needed work to make them fit together properly, until then we're treading water in "technical debt". Discussing how to run the tree is something to do later after gaining this experience.

I had a look at the LT gits

ARM Merge-managed integration-linux-vexpress 3.4-rc4 TI Rebase-managed tilt-tracking 3.4-rc4 Freescale Merge-managed lt-3.4 3.4-rc3 Samsung Rebase-managed tracking 3.4-rc3 STE Merge-managed integration-linux-ux500 3.4-rc6

(wow STE - on igloocommunity.org - have a LOT of patches! I thought we were leading the way)

Actually locally TILT are on -rc6 but there was almost no conflict coming between -rc4 and -rc6. If you take the approach to merge these trees, I found that late in the cycle it's usually pretty forgiving about some variation in basis.

So why not give these all a test merge today and see what starts falling out? I am sure we all have something to fix and there may be larger issues

I will check with Andrey/Ricardo if we can do that :) ... would it be exciting enough if we just try adding TI to the mix this month (and not all?)?

In any case, you should definitely send Andrey a list of topic branches you want to register for linux-linaro and things will get picked up as soon as Andrey can I guess :).

Sure, actually merging trees and dealing with the fallout, even if it's just one more tree if that's all you can handle, will get us moving further forward than just talking about it.

AIUI this topic thing is not blocking you, you can just merge tilt-tracking as a single topic for now and discover the "pain points". All I am planning to provide ultimately is an in-tree text file mapping topic names to head hashes, as I produced for Andrey before, not "register topics" anywhere.

-Andy

On 22/05/12 04:02, Somebody in the thread at some point said:

On Thu, May 10, 2012 at 10:43 PM, Andy Greenandy.green@linaro.org wrote:

...

On 11/05/12 08:27, Somebody in the thread at some point said:

...

4. in between RCs, we only move mainline on our linux-linaro release

baseline forward if we see a working tracking build that wouldn't drop any topics that already made it into this RC cycle.

The probability of getting a good unified tree follows the kernel cycle, we all have good reasons to have tried to arrive at a good, working, release. Sometimes we only get a reasonably good result a week or two after Linus' release.

For that reason maybe you should just be trying to 'release' a release-basis unified tree, ie, the 3.4 one targeted now as the deliverable. It still has meaning to make a monthly release of that since it can collect stable mainline updates and updates from each LT release tree that happened in the meanwhile.

We do need to create these intermediate unified trees so we know what to fix on our trees so they can go in smoothly, but it matters less then if one day half the LT trees are missing on it since it's of interest only for LTs and platform guys to study what else needs solving on the LT trees.

I still think you won't get anywhere useful until we are trying to build the unified trees for real. Then we can start the needed work to make them fit together properly, until then we're treading water in "technical debt". Discussing how to run the tree is something to do later after gaining this experience.

I had a look at the LT gits

ARM Merge-managed integration-linux-vexpress 3.4-rc4 TI Rebase-managed tilt-tracking 3.4-rc4 Freescale Merge-managed lt-3.4 3.4-rc3 Samsung Rebase-managed tracking 3.4-rc3 STE Merge-managed integration-linux-ux500 3.4-rc6

(wow STE - on igloocommunity.org - have a LOT of patches! I thought we were leading the way)

Actually locally TILT are on -rc6 but there was almost no conflict coming between -rc4 and -rc6. If you take the approach to merge these trees, I found that late in the cycle it's usually pretty forgiving about some variation in basis.

So why not give these all a test merge today and see what starts falling out? I am sure we all have something to fix and there may be larger issues like two trees with conflicting versions of, I dunno, Mali driver, that needs planning to resolve. Or if people aren't using linux-linaro-core-tracking to get their CMA and so on, we need to know and start that migration.

So, if I understood correctly, the llct would be the branch used to actually start producing a valuable path to get the unified tree in place.

Exactly.

As you said, it seems we should start trying to experiment merging everything together and deciding what can actually be moved or not to the core-tracking branch. This way we'd probably move to the direction of having one real unified tree, instead of just maintaining linux-linaro over the time.

Right.

So these are the useful branches I believe we'd end up having:

• Linux Linaro Core Tracking: main tree used to develop the common

changes across the different LTs/WGs and board flavours

Yes. This is already doing good stuff for us, we can carefully add more things here to give everyone an easy ride and eliminate desynchronized duplication between the trees.

• Linux Linaro: tree with llct that is stabilised between rc releases,

that's part of the LEB releases. This tree would also have additional topics from the LTs and WGs, in case they want to release it all into one single tree (releasing together with Linux Linaro is useful in a way we'll share QA and also helping identifying what other improvements might be needed in case of conflicts)

• Linux Linaro Tracking/Unified: a tree that could contain llct + all

the sauce maintained by all the LTs, to be used just for testing to help understanding what should be shared between LTs and be moved to core-tracking. This would help us getting to a position where we could identify early what are the conflicts, and work on getting a common solution with core-tracking before actually starting to send upstream.

Would this fit your needs?

I think you can forget the last two and just take care about llct. For a while I imagined there was just something I wasn't getting about this new llt scheme but now I believe it's simply unworkable and not thought through.

If you imagine just a little bit ahead of where we are today, with all LT on same or similar llct basis on any particular day, actually Andrey can imagine to wake up one morning and casually try to merge two or more LT trees and see what happens. They're on same basis, we moved most or eventually all duplicated content to a canonical version coming from llct... most of the thorns are removed from the path.

He will find:

1) merge conflicts... two or more trees both changed same code. "False alarms" will occur here a lot in Makefile and Kconfig, since other trees added stuff too, but there is no problem or bug. But there will be some genuine ones like we now know in Mali multiple trees screwed with same stuff. These will need discussion and examination of each others' changes and figure a good way to encapsulate, however general approach should be migrate the common changes (Mali basis at least) to llct and minimize diverged patches in LT trees.

2) configure conflicts... LT trees made bad assumptions about SoC assets not being dependent on SoC Arch config, and default to "y". So for example TI PM feature might insist to be enabled when building out the tree for Samsung ARCH device. It's a bug in that fictitious example in TI tree we can fix easily if we hear about it.

3) build conflicts... some trees accidentally added stuff based on <plat/blah.h> they have in their arch, but not in other trees leading to defines that aren't defined... again it's a bug in the trees that changed it, just needs discussion and explanation for simple fixes

4) breakage... workarounds and changes to common code like mmc core might be necessary or work on one arch but trash operation on another. Needs discussion on why there are changes to common core code in LT tree. Maybe the changes are really good news, in which case stick them in llct until they appear upstream. If they're dubious either convince LT to find a better way or eliminate them, or if not possible use flags for dynamic enable of the changes.

For problems 1-3, Andrey should drive it and stimulate discussion with LTs on lists about what a beneficial resolution looks like and get people to improve their trees so he can go again.

At 4, actually I think LTs involved will have to try to build Andrey's casually unified tree with their config alone initially and check for results same as the same LT tree Andrey used. It won't scale if we ask Andrey to also test all the LT trees. So long as LTs are not prodded to do it too often, it should be fine. Then in turn LTs need to create discussion about findings, like "it boots, but now in unified tree MMC OOPSes after a few seconds like this...", look at what other LT content affected that area etc.

If all the LTs involved agree they can recover their original tree's functionality from the unified one when using just their CONFIG, then it's ready to try to build out with a single kernel binary multiarch config and deal with the new load of problems from that, eventually when they're cleared a new round of LT testing with single kernel binary.

This was the approach we took to get OMAP4 + 5 single kernel binary in our current tree and it worked well. After we got it working we threw out the individual arch configs and now only build the single kernel binary one so there can be no slippage.

After we get some good result from the casually merged trees, to the extent we can build out all the same LT kernels that went in, we can think through what we learned and talk meaningfully about predictions and how to manage release of the tree.

-Andy

On Fri, May 11, 2012 at 8:51 AM, Jon Medhurst (Tixy) tixy@linaro.org wrote:

On Fri, 2012-05-11 at 02:27 +0200, Alexander Sack wrote:

...

On Fri, May 11, 2012 at 1:43 AM, Jon Medhurst (Tixy) tixy@linaro.org wrote:

...

On Fri, 2012-05-11 at 07:14 +0800, Andy Green wrote:If

...

the current one performs best and is on a random HEAD commit, we certainly shouldn't wind it backwards to last -rc that performs worse just because that's "easier to communicate".

I agree, I wasn't envisioning winding backwards, more that we stop winding forwards at a chosen -rc, or stop merging topics on a Friday, bring the common tree up-to-date with the weekends Torvalds -rc, then build, test and fix this ready for Linaro RC on the Friday.

I think we agree ... here is how I thought so far should linux-linaro could be driven forward:

1. we have an automated -tracking baseline running that always reflects how your topics look like on tip  2. linux-linaro moves forward on the day a new RC comes around.  3. linux-linaro will not wait for topics to be ready before doing the RC jump  4. in between RCs, we only move mainline on our linux-linaro release baseline forward if we see a working tracking build that wouldn't drop any topics that already made it into this RC cycle.

I'm not sure this differs much from linux-linaro == last good automated -tracking baseline, which might be simpler to understand. But I thought linux-linaro was meant to be this tracking baseline anyway?

It's a good rule of thumb ... however, in order to ensure that we will not be stuck with non-good builds forever, I was saying that we should move to next RCs and kill topics until we are good again :), while we would only move forward in between RCs if we don't need to drop topics in such a move.

Does that explain the subtle difference better?

On 05/11/2012 09:13 AM, Andy Green wrote:

On 11/05/12 13:04, Somebody in the thread at some point said:

...

On 05/11/2012 01:04 AM, Andrey Konovalov wrote:

...

Greetings,

So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree)

Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7.

The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus the 7 generic topics currently included into the linux-linaro-core-tracking tree: ufs (ufs-for-linux-linaro) emmc (emmc-for-linux-linaro) thermal_exynos4_imx6 (thermal_exynos4_imx6_work) linaro-android-3.4 armlt-gator (tracking-armlt-gator) umm-wip (umm-3.4rc4-wip) linaro-configs-3.4 If you don't see your generic topic in this list, but you think it should be there, please let me know ASAP. If you have a new topic to add, please send me the request before the next Thursday, May 17; the sooner, the better. The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Ad...

The landing teams - please update your topic branches if needed: ARM: tracking-armlt-hdlcd tracking-armlt-mmc tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes tracking-armlt-ubuntu-config tracking-armlt-android-config Samsung: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mali topic/cma_v24 topic/android_config

Is any other LT using CMA patchset? If so, this topic branch can be moved into linux-linaro-core-tracking.

We'll be using it again shortly, CMA is in linux-linaro-core-tracking already though, I believe the same version #24.

http://git.linaro.org/gitweb?p=kernel%2Flinux-linaro-tracking.git&a=sear...

Indeed. Thanks Andy!

They came into linux-linaro-core-tracking from the umm-3.4rc4-wip topic. Would it make sense to have the CMA patches in a separate topic?

I could even start tracking the git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git, for-next-cma (or 3.4-<most recent rc>-cma-v24 ?) branch directly provided that Sumit or Tushar would do the fixes when needed (maintain cma-fixes topic).

Thanks, Andrey

On 05/12/2012 11:09 PM, Andrey Konovalov wrote:

Tushar,

On 05/11/2012 09:04 AM, Tushar Behera wrote:

...

On 05/11/2012 01:04 AM, Andrey Konovalov wrote:

...

Greetings,

So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree)

Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7.

The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus the 7 generic topics currently included into the linux-linaro-core-tracking tree: ufs (ufs-for-linux-linaro) emmc (emmc-for-linux-linaro) thermal_exynos4_imx6 (thermal_exynos4_imx6_work) linaro-android-3.4 armlt-gator (tracking-armlt-gator) umm-wip (umm-3.4rc4-wip) linaro-configs-3.4 If you don't see your generic topic in this list, but you think it should be there, please let me know ASAP. If you have a new topic to add, please send me the request before the next Thursday, May 17; the sooner, the better. The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Ad...

The landing teams - please update your topic branches if needed: ARM: tracking-armlt-hdlcd tracking-armlt-mmc tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes tracking-armlt-ubuntu-config tracking-armlt-android-config Samsung: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mali topic/cma_v24 topic/android_config

Is any other LT using CMA patchset? If so, this topic branch can be moved into linux-linaro-core-tracking.

That's a good idea, thanks!

The only problem is that your topic/cma_v24 is based on the topic/base, and thus includes "CONFIG: ORIGEN:" commits and an older version of linaro-configs-3.4 topic. In particular, the latter recreates configs/panda.conf file which has been deleted from the current linaro-configs-3.4. Could you please make topic/cma_v24 mainline based (drop these "CONFIG: ORIGEN:" and configs/* changes)? And is the "CONFIG_CMA_SIZE_MBYTES=32" option Origen specific or generic? If it is generic, it should go into a separate file, e.g. configs/cma.conf.

I didn't mean to include topic/cma_v24 with the patches from topic/base, rather the clean patchset from Marek. But now that we have the umm topic branch in linux-linaro-core-tracking, we don't need topic/cma_v24 anymore. If any fixes with respect to Origen are required, I will queue them up in another topic branch.

I will shortly send you the list of topic branches for 2012.05 release, now that 3.4-rc7 is already released.

Thanks, Andrey

Hi Tushar,

On Mon, May 14, 2012 at 8:04 PM, Tushar Behera tushar.behera@linaro.org wrote:

On 14 May 2012 13:40, Tushar Behera tushar.behera@linaro.org wrote:

...

On 05/12/2012 11:09 PM, Andrey Konovalov wrote:

...

Tushar,

On 05/11/2012 09:04 AM, Tushar Behera wrote:

...

On 05/11/2012 01:04 AM, Andrey Konovalov wrote:

...

Greetings,

So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree)

Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7.

The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus the 7 generic topics currently included into the linux-linaro-core-tracking tree:     ufs (ufs-for-linux-linaro)     emmc (emmc-for-linux-linaro)     thermal_exynos4_imx6 (thermal_exynos4_imx6_work)     linaro-android-3.4     armlt-gator (tracking-armlt-gator)     umm-wip (umm-3.4rc4-wip)     linaro-configs-3.4 If you don't see your generic topic in this list, but you think it should be there, please let me know ASAP. If you have a new topic to add, please send me the request before the next Thursday, May 17; the sooner, the better. The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Ad...

The landing teams - please update your topic branches if needed: ARM:     tracking-armlt-hdlcd tracking-armlt-mmc     tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes     tracking-armlt-ubuntu-config tracking-armlt-android-config Samsung:     topic/base topic/core topic/bl topic/dt topic/fb topic/pd     topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg     topic/gadget topic/touch topic/wlan topic/audio topic/hdmi     topic/mali topic/cma_v24 topic/android_config

Is any other LT using CMA patchset? If so, this topic branch can be moved into linux-linaro-core-tracking.

That's a good idea, thanks!

The only problem is that your topic/cma_v24 is based on the topic/base, and thus includes "CONFIG: ORIGEN:" commits and an older version of linaro-configs-3.4 topic. In particular, the latter recreates configs/panda.conf file which has been deleted from the current linaro-configs-3.4. Could you please make topic/cma_v24 mainline based (drop these "CONFIG: ORIGEN:" and configs/* changes)? And is the "CONFIG_CMA_SIZE_MBYTES=32" option Origen specific or generic? If it is generic, it should go into a separate file, e.g. configs/cma.conf.

I didn't mean to include topic/cma_v24 with the patches from topic/base, rather the clean patchset from Marek. But now that we have the umm topic branch in linux-linaro-core-tracking, we don't need topic/cma_v24 anymore. If any fixes with respect to Origen are required, I will queue them up in another topic branch.

I will shortly send you the list of topic branches for 2012.05 release, now that 3.4-rc7 is already released.

While migrating the Android solution to use linux-linaro-core-tracking, I get kernel panic with umm-patchset (haven't dug deep into it though, it might be because the multimedia drivers are not yet migrated for using UMM). Would it be ok if we only include CMA patchset, but not the dma-buf and dma-mapping patches?

are you asking whether we would consider to drop dma-mapping from linux-linaro tree or if it would be a bad idea to do that in your samsung LT tree?

For linux-linaro, we probably would prefer to try to fix it before talking about the option to drop such a core topic. Do you have more info about the kernel panic you see?

On 15 May 2012 08:17, Andy Green andy.green@linaro.org wrote:

On 15/05/12 07:03, Somebody in the thread at some point said:

...

...

While migrating the Android solution to use linux-linaro-core-tracking, I get kernel panic with umm-patchset (haven't dug deep into it though, it might be because the multimedia drivers are not yet migrated for using UMM). Would it be ok if we only include CMA patchset, but not the dma-buf and dma-mapping patches?

are you asking whether we would consider to drop dma-mapping from linux-linaro tree or if it would be a bad idea to do that in your samsung LT tree?

We will need latest dmabuf and associated stuff.

...

For linux-linaro, we probably would prefer to try to fix it before talking about the option to drop such a core topic. Do you have more info about the kernel panic you see?

The issue is something that we are somewhat aware of, as we had similar issue when we had tried to migrate our multimedia solution to use dma-buf/dma-mapping.

Yes approach of dropping -core topics to manage problems isn't really workable.  Even if you did it Tushar's older stuff will conflict when you try to unify the kernels.

If it's the case that stuff in linaro tree is more upstream-converged than what Tushar's tree works with, then we can put it another way: the current implementation in Samsung tree (no ding intended since it can just as easily be any of us and no doubt soon will be) needs to be fixed to work with current upstream-headed pieces it needs.

Yes, indeed. We are working on fixing this stuff. Just that, it won't be fixed before 2012.05 release. That is why I was wondering whether Samsung LT Android solution could use linux-linaro tree.

When you put it like that, it's clearer that there's value for Samsung in fixing this in Samsung LT tree to work with latest upstream-headed series, because they're going to have to deal with same breakage shortly from upstream path anyway.

I dunno if it helps, but Rob Clark has a few patches on top of current stuff that might also be something to do with something for Tushar

http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...

Sure, I will have a look at them if they help.

-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/#%21/linaroorg - http://linaro.org/linaro-blog

On 15 May 2012 04:33, Alexander Sack asac@linaro.org wrote:

Hi Tushar,

On Mon, May 14, 2012 at 8:04 PM, Tushar Behera tushar.behera@linaro.org wrote:

...

On 14 May 2012 13:40, Tushar Behera tushar.behera@linaro.org wrote:

...

On 05/12/2012 11:09 PM, Andrey Konovalov wrote:

...

Tushar,

On 05/11/2012 09:04 AM, Tushar Behera wrote:

...

On 05/11/2012 01:04 AM, Andrey Konovalov wrote:

...

Greetings,

So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree)

Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7.

The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus the 7 generic topics currently included into the linux-linaro-core-tracking tree:     ufs (ufs-for-linux-linaro)     emmc (emmc-for-linux-linaro)     thermal_exynos4_imx6 (thermal_exynos4_imx6_work)     linaro-android-3.4     armlt-gator (tracking-armlt-gator)     umm-wip (umm-3.4rc4-wip)     linaro-configs-3.4 If you don't see your generic topic in this list, but you think it should be there, please let me know ASAP. If you have a new topic to add, please send me the request before the next Thursday, May 17; the sooner, the better. The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Ad...

The landing teams - please update your topic branches if needed: ARM:     tracking-armlt-hdlcd tracking-armlt-mmc     tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes     tracking-armlt-ubuntu-config tracking-armlt-android-config Samsung:     topic/base topic/core topic/bl topic/dt topic/fb topic/pd     topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg     topic/gadget topic/touch topic/wlan topic/audio topic/hdmi     topic/mali topic/cma_v24 topic/android_config

Is any other LT using CMA patchset? If so, this topic branch can be moved into linux-linaro-core-tracking.

That's a good idea, thanks!

The only problem is that your topic/cma_v24 is based on the topic/base, and thus includes "CONFIG: ORIGEN:" commits and an older version of linaro-configs-3.4 topic. In particular, the latter recreates configs/panda.conf file which has been deleted from the current linaro-configs-3.4. Could you please make topic/cma_v24 mainline based (drop these "CONFIG: ORIGEN:" and configs/* changes)? And is the "CONFIG_CMA_SIZE_MBYTES=32" option Origen specific or generic? If it is generic, it should go into a separate file, e.g. configs/cma.conf.

I didn't mean to include topic/cma_v24 with the patches from topic/base, rather the clean patchset from Marek. But now that we have the umm topic branch in linux-linaro-core-tracking, we don't need topic/cma_v24 anymore. If any fixes with respect to Origen are required, I will queue them up in another topic branch.

I will shortly send you the list of topic branches for 2012.05 release, now that 3.4-rc7 is already released.

While migrating the Android solution to use linux-linaro-core-tracking, I get kernel panic with umm-patchset (haven't dug deep into it though, it might be because the multimedia drivers are not yet migrated for using UMM). Would it be ok if we only include CMA patchset, but not the dma-buf and dma-mapping patches?

are you asking whether we would consider to drop dma-mapping from linux-linaro tree or if it would be a bad idea to do that in your samsung LT tree?

Actually we were planning to base 2012.05 release on linux-linaro kernel, that is why I was looking at options.

We will rather have 2012.05 release based Samsung LT tree till this issue has been fixed.

For linux-linaro, we probably would prefer to try to fix it before talking about the option to drop such a core topic. Do you have more info about the kernel panic you see?

-- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog

Hi Tushar,

On 05/17/2012 01:06 PM, Tushar Behera wrote:

On 05/11/2012 01:04 AM, Andrey Konovalov wrote:

...

Samsung: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mali topic/cma_v24 topic/android_config

Following topic branches are available to be pulled to linux-linaro tree.

topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi *topic/mfc* topic/mali *topic/cma_origen* topic/android_config *topic/ubuntu_config*

These topics have been merged ok into the linux-linaro tree yesterday. Thanks!

• topic/base is based on v3.4-rc7 and has config patches, both internal

and from John's linaro-config-3.4 branch. All other topic branches are based on topic/base.

• topic/cma_v24 has been dropped. Instead we have topic/cma_origen that

has only Origen specific CMA patches.

With this set of patches, I can boot-test Ubuntu and it fails for Android. I will update you if the Android related kernel panic is fixed before 2012.05 release.

OK

Please let me know if you run across any issues while merging these branches.

There were two simple conflicts when merging the topic/mali. The solutions are attached for your reference.

Thanks, Andrey

On 17/05/12 17:41, Somebody in the thread at some point said:

On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote:

...

Greetings,

So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree)

Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base.

What happened to this?

linux-linaro hasn't changed for 4 weeks now, so our vexpress 'tracking' builds of Android and Ubuntu are in fact the same kernels as the 12.04 release.

It doesn't matter as long as llct is moving - and it has been, Andrey is doing a really nice job. If we can get all the LTs to base on llct, and get all the important things standardized in llct, then everything will come right.

Nobody cares that we glued a couple dozen patches from ARM LT on one other LT tree as a one-off.

-Andy

On Thu, 2012-05-17 at 18:59 +0400, Andrey Konovalov wrote:

Have pushed to the linux-linaro some time ago

Thanks Andrey.

On Tue, May 22, 2012 at 8:10 AM, Deepti Kalakeri deepti.kalakeri@linaro.org wrote:

On Thu, May 17, 2012 at 8:29 PM, Andrey Konovalov andrey.konovalov@linaro.org wrote:

...

On 05/17/2012 06:40 PM, Andy Green wrote:

...

On 17/05/12 17:41, Somebody in the thread at some point said:

...

On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote:

...

Greetings,

So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree)

Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base.

What happened to this?

I had some minor conflicts and build failures, so kept the updated tree locally for a while.

...

...

linux-linaro hasn't changed for 4 weeks now, so our vexpress 'tracking' builds of Android and Ubuntu are in fact the same kernels as the 12.04 release.

It doesn't matter as long as llct is moving - and it has been, Andrey is doing a really nice job. If we can get all the LTs to base on llct, and get all the important things standardized in llct, then everything will come right.

Actually, it (not moving linux-linaro forward for too long) was my fault.. Have pushed to the linux-linaro some time ago (no Samsung LT topics added yet). BTW, for llct I've added the linux-linaro-core-tracking-v3.4-rc7 tag just in case the v3.4-rc7 tree is needed. As llct tip has moved beyond v3.4-rc7.

...

Nobody cares that we glued a couple dozen patches from ARM LT on one other LT tree as a one-off.

linux-linaro tree is used by some CI jobs. To have the 12.05 stuff being tested in LAVA and such, I should have updated the linux-linaro tree as early as possible.

Should we stop to build linux-linaro and switch to llct or continue to build linux-linaro and include llct builds as well?

llct is a convenience tag used by LTs that have their own tree. We always said we won't validate and test that alone also because it does not include enablement and testing/validating it properly is not possible.

Hi Deepti,

On 05/22/2012 10:10 AM, Deepti Kalakeri wrote:

On Thu, May 17, 2012 at 8:29 PM, Andrey Konovalov <andrey.konovalov@linaro.org mailto:andrey.konovalov@linaro.org> wrote:

On 05/17/2012 06:40 PM, Andy Green wrote:

    On 17/05/12 17:41, Somebody in the thread at some point said:

        On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote:

            Greetings,

            So far I wasn't updating the linux-linaro tree since the
            12.04 release.
            (The generic topic updates were being done to the
            linux-linaro-core-tracking tree)

            Now it is time to move the focus to the linux-linaro
            tree. For one week
            it will use the mainline tip as the base.


        What happened to this?


I had some minor conflicts and build failures, so kept the updated
tree locally for a while.


        linux-linaro hasn't changed for 4 weeks now, so our vexpress
        'tracking'
        builds of Android and Ubuntu are in fact the same kernels as
        the 12.04
        release.


    It doesn't matter as long as llct is moving - and it has been,
    Andrey is
    doing a really nice job. If we can get all the LTs to base on
    llct, and
    get all the important things standardized in llct, then
    everything will
    come right.


Actually, it (not moving linux-linaro forward for too long) was my
fault.. Have pushed to the linux-linaro some time ago (no Samsung LT
topics added yet).
BTW, for llct I've added the linux-linaro-core-tracking-v3.__4-rc7
tag just in case the v3.4-rc7 tree is needed. As llct tip has moved
beyond v3.4-rc7.


    Nobody cares that we glued a couple dozen patches from ARM LT on one
    other LT tree as a one-off.


linux-linaro tree is used by some CI jobs. To have the 12.05 stuff
being tested in LAVA and such, I should have updated the
linux-linaro tree as early as possible.

Should we stop to build linux-linaro and switch to llct or continue to build linux-linaro and include llct builds as well?

Guess we should continue to build linux-linaro and include llct builds as well

Thanks, Andrey

-- Thanks and Regards, Deepti Infrastructure Team Member, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog

On 17/05/12 23:01, Somebody in the thread at some point said:

On Thu, 2012-05-17 at 22:40 +0800, Andy Green wrote:

...

On 17/05/12 17:41, Somebody in the thread at some point said:

...

On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote:

...

Greetings,

So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree)

Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base.

What happened to this?

linux-linaro hasn't changed for 4 weeks now, so our vexpress 'tracking' builds of Android and Ubuntu are in fact the same kernels as the 12.04 release.

It doesn't matter as long as llct is moving - and it has been, Andrey is doing a really nice job. If we can get all the LTs to base on llct, and get all the important things standardized in llct, then everything will come right.

Nobody cares that we glued a couple dozen patches from ARM LT on one other LT tree as a one-off.

OK, so you're saying linux-linaro is dead/on-hold and I should go back to maintaining my own branches for releasing Ubuntu and Android VExpress kernels? If that's true, I wish people would actually tell me these things.

Dude I'm not in charge, I'm just relating the facts.

linux-linaro-tracking is currently meaningless to anyone. Naturally it doesn't get updated, it's a meaningless Potemkin village.

llct is very valuable though and if we take care about it as we all should, eventually it will be able to generate a meaningful linux-linaro-tracking itself because it caused the LTs to converge on all the critical points.

In the meanwhile the thing we should all be taking care about is understanding the current deep incompatibilities in LT trees - like Mali - and steering things in the right direction. But somehow excluding topics became the fetish for half a year now and afaik nobody - nobody - has actually tried to bind the LT trees together to discover the issues since I last did it in Dec.

-Andy

Greetings,

Moving to v3.4 release caused one conflict in drivers/dma/pl330.c when merging the Samsung LT's topic/core. I've emailed the details to Tushar for review.

My conflict resolutions didn't work for Origen, so the following fix has been added (via the "last-minute-fixes" topic): commit 774c3a28353943ee57c0e36c035cca98225b3000 "dma: dmaengine: Remove BUG_ON condition in dma_cookie_complete"

The new version is tagged linux-linaro-3.4-2012.05-1.

This commit is the only difference from linux-linaro-3.4-2012.05-0.

Thanks, Andrey

On 05/21/2012 09:06 PM, Andrey Konovalov wrote:

Greetings,

Changes since last Friday, May 18:

• new ubuntu-sauce topic added
• new umm_fixes topic added (one patch from the Samsung LT to fix

kernel panic while booting Android on Origen board)

• the tree has been moved from v3.4-rc7 to v3.4 release

Moving to v3.4 release caused one conflict in drivers/dma/pl330.c when merging the Samsung LT's topic/core. I've emailed the details to Tushar for review.

Starting from today, the linux-linaro branch is frozen until the 12.05 release is out. Only important bug fixes would be accepted.

Here is the list of the topics included into the 12.05 linux-linaro tree:

Generic topics: ufs (ufs-for-linux-linaro) emmc (emmc-for-linux-linaro) thermal_exynos4_imx6 (thermal_exynos4_imx6_work) linaro-android-3.4 armlt-gator (tracking-armlt-gator) umm-wip (umm-3.4rc4-wip) unsorted (tracking-orphan-unsorted branch from people/ynk/linux-linaro-tracking.git for the stuff that doesn't fit into any existing topics) linaro-configs-3.4 ubuntu-sauce (git://git.linaro.org/ubuntu/linux-linaro-quantal.git linaro-ubuntu-sauce-packaging-topic)

ARM LT's topics: tracking-armlt-hdlcd tracking-armlt-mmc tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes (can be dropped actually, as these fixes are in the mainline already - thanks, Tixy) tracking-armlt-ubuntu-config tracking-armlt-android-config

Samsung LT's topics: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mfc topic/mali topic/cma_origen topic/android_config topic/ubuntu_config llt/umm_fixes

last-minute-fixes topic:

• trivial fix to include/linux/dma-buf.h to make it compile in the

CONFIG_DMA_SHARED_BUFFER=n case

Thanks, Andrey

On 06/08/2012 08:25 PM, the mail apparently from Andrey Konovalov included:

Greetings,

There will be three linux-linaro trees this month. Also some LTs have moved to 3.5, while the others will stay on older kernels.

In addition to linux-linaro-core-tracking and linux-linaro ones (described under https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess), linux-linaro-tracking tree will be created as a merge of the tracking trees of TI (v3.4 based) and Samsung (currently v3.4-rc7 based) LTs.

For reference the TI + Samsung trees I did during Connect can be found here:

http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...

This builds and works for OMAP at least.

Probably more LT tracking trees would be added, but I am not sure due to the different bases the others use. Each LT's tracking tree act as a topic here, so the call for topics doesn't apply to this tree.

linux-linaro-core-tracking tree is moving to 3.5 (but not published at git.linaro.org yet). For those using the 3.4, llct_3.4 branch has been created. This is a copy of the most recent v3.4 based linux-linaro-core-tracking tree. *New generic (not board specific) topics and updates to the existing topics are welcomed for the 3.5 based linux-linaro-core-tracking tree* The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Ad...

The current topics are:

• arm_soc/testing/multiplatform
• svenkatr/ufs-for-linux-linaro
• svenkatr/emmc-for-linux-linaro
• amitdanielk/thermal_exynos4_imx6_work

Not sure if this will now already have it, but this patch

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg63852.html

is important for OMAP... thanks to Tushar for digging up the context of it for us. We're carrying a replica of it in our tracking atm but since what was

tracking-thermal_exynos4_imx6-3.4-2012.05

had just one of the pair of patches in older llct, it should be improved to have both, if it doesn't already with this update.

-Andy

On 06/11/2012 07:33 AM, Tushar Behera wrote:

On 06/08/2012 07:30 PM, Andy Green wrote:

...

On 06/08/2012 08:25 PM, the mail apparently from Andrey Konovalov included:

...

Greetings,

There will be three linux-linaro trees this month. Also some LTs have moved to 3.5, while the others will stay on older kernels.

In addition to linux-linaro-core-tracking and linux-linaro ones (described under https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess),

linux-linaro-tracking tree will be created as a merge of the tracking trees of TI (v3.4 based) and Samsung (currently v3.4-rc7 based) LTs.

I would be publishing 3.4 based Samsung Kernel today. So, you can use that in linux-linaro-tracking.

OK. Thanks, Tushar!

...

For reference the TI + Samsung trees I did during Connect can be found here:

http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...

This builds and works for OMAP at least.

Thanks, Andy! Have had a quick look at it. I could probably ask you about some more details of some your fixes with no or too short (for me) comments. But this is rather my ignorance/curiosity then an issue.

Thanks, Andrey

Greetings,

The linux-linaro-core-tracking branch has finally been moved to 3.5. Not all the topics listed in the previous message are here yet (the umm and the ubuntu-sauce are not there yet); the current list is (see also the attached pinned manifest): * svenkatr/ufs-for-linux-linaro * svenkatr/emmc-for-linux-linaro * amitdanielk/thermal_exynos4_imx6_work * android_jstultz/linaro-android-3.5-jstultz-rebase * lt_arm/tracking-armlt-gator * arm_soc/testing/multiplatform * configs/config-core-tracking

Andy Green pointed out that

this patch

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg63852.html

is important for OMAP... thanks to Tushar for digging up the context of it for us. We're carrying a replica of it in our tracking atm but since what was

tracking-thermal_exynos4_imx6-3.4-2012.05

had just one of the pair of patches in older llct, it should be improved to have both, if it doesn't already with this update.

The current answer is that thermal_exynos4_imx6_work doesn't have the 2nd patch (and this topic has not been updated for 8 weeks). And the reason for having just the 1st patch is probably that the 1st patch is the ARM generic one, while the 2nd one is for OMAP. And AFAIK the topic doesn't support OMAPs yet. The 2nd patch worth including into llct, but I haven't decided how to do that yet - need to sync with the PMWG.

The thermal stuff is most probably doesn't quite work for imx6 in this version for the following reason:

After a new clk-imx6q.c driver had been introduced (commit 2acd1b6f889c04f8f303a5a11993f60fda6a7885), the previous clock-imx6q.c driver was deleted (commit c818f97bc3266f0fbf619f2348d951272f8ac335). As a result, commit 3ecb31851f236df5099e21696325776b2e800fe4 "arm/imx6q: register arm_clk as cpu to clkdev" from the thermal_exynos4_imx6_work topic can not be applied as is to the new driver.

So I had to drop the "arm/imx6q: register arm_clk as cpu to clkdev" commit.

Thanks, Andrey

On 06/08/2012 04:25 PM, Andrey Konovalov wrote:

The current topics are:

• arm_soc/testing/multiplatform
• svenkatr/ufs-for-linux-linaro
• svenkatr/emmc-for-linux-linaro
• amitdanielk/thermal_exynos4_imx6_work
• android_jstultz/linaro-android-3.5-jstultz-rebase
• lt_arm/tracking-armlt-gator
• umm_sumitsemwal/umm-3.4-wip (needs updating to 3.5?)
• lt_samsung/llt/umm_fixes (should be better included into the topic

above?)

• android_jstultz/linaro-configs-3.5
• ll_quantal/linaro-ubuntu-sauce-packaging-topic (needs updating to 3.5?)