This month's meetings

<< <  2011 / 8 >  >>
Mon Tue Wed Thu Fri Sat Sun
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Meeting info

  • Kernel WG meetings are conducted over IRC: #linaro-kernel on Freenode.

Morning Attendees

  • Arnd Bergmann: x
  • Dave Martin: x
  • Deepak Saxena:
  • Jason Hui:
  • Linus Walleij: x
  • Mounir Bsaibes: x
  • Nicolas Pitre: x
  • Niklas Hernaeus: x
  • Nishant Kamat:
  • Paul McKenney:

  • Per Forlin: x
  • Grant Likely: x
  • Andy Green:
  • Tixy:
  • Shawnguo: x
  • Zach Pfeffer: x
  • Dirk Behme: x
  • John Linn: x

Evening Attendees

  • Deepak Saxena:
  • John Stultz: x
  • Jason Hui:
  • Grant Likely:
  • Thomas Abraham:
  • Manjunath Kondaiah:
  • Mounir Bsaibes: x
  • Shawn Guo:
  • Venkatraman Sathiyamoorthy:
  • Zack Pfeffer


  1. Announcement / Upcoming Release Dates
  2. Android upstreaming - requested by Zach
  3. Alignment Faulting - Requested by Dave
  4. The status of the Freescale loco kernel - requested by Dirk Behme
  5. Blueprints / Around the table
  6. BUGS review
  7. August Sprint Planning
    • Sprint format
      • Remaining 11.11 Kernel planning discussions
      • coding
      • Future direction/areas to focus on?
    • git process presentation for other Linaro groups (LT, PMWG, etc...)
  8. Pending Action Items

Action Items from Previous Meeting

To see the completed action items: WorkingGroups/Kernel/ActionItemsDone

Minutes From Today's Meetings

  • Announcement, see agenda
  • Arnd want to start pulling stuff into arm-soc.git,JohnLinn to send him pull request

  • Arnd want to look at the CSR SiRFprima support, maybe it gets done quicker than expected and can get merged in 3.1 as well
  • Zach likes to invite some Google and SoC kernel guys to Cambridge and perhaps, even get something stage for upstream, the KWG will be open to work with them. There is a lot of interest in this from ARM and OCTO.
  • Dave started a discussion to get rid of alignment faults in userspace"
    • need help/volunteers for this work
  • Shawnguo has fixed

  • HDMI on Panda still broken, it is release blocker
  • Discussion between who's tree do we base our Android work off of. Need to close with LTs, Rodger Teague, Kiko an kernel team

Action Items From Today's Meetings

  • gcl to get a tree to npitre to be able to pull the DT patches
  • Mounir to discuss with Operations about Arnd registration issue: "The registration doesn't work if I arrive too early and/or don't stay in the hotel..."
  • linusw to send pull requests to Arnd for U300 and Ux500
  • Mounir/Deepak to set further discussion/planning for Android upstreaming at LDS - Done.
  • Mounir to follow up with asac, fathi and agreen on the HDMi issue
  • Mounir to go over targeting bugs to milestones and send a note/reminder to the team about targeting bugs to milestones

IRC Logs

Morning meeting IRC log

* #linaro-kernel :
<mounir> Hi everyone
<shawnguo> mounir: hi
<perfor> mounir: hi
<mounir> hi shawnguo 
<mounir> Deepak is out camping, I will moderate today's meeting
<mounir> who else is on the call?
<linusw> me
<mounir> hi perfor
<nhe> and me
<mounir> hi linusw
<mounir> hi nhe
<thomas-ab> Hi Mounir
<arnd> hi mounir
<bones10> I'm here
<svenkatr> hi mounir
<JohnLinn> hi, I'm visiting again
<robher> here
* dmart ( has joined #linaro-kernel
<mounir> hello thomas-ab, arnd, bones10, svenkatr, Johnlinn, robher
<dirk_b> I'm visting, too
<mounir> hi dirk-b
* pfefferz ( has joined #linaro-kernel
<pfefferz> hello
<mounir> hi dirk_b
<dmart> hi all
<mounir> hello dmart, pfefferz
<pfefferz> hey mounir
<mounir> will use the linaro-meeting bot - thank to Fathi
<mounir> #startmeeting
<linarobot> Meeting started Mon Jun 20 15:05:00 2011 UTC. The chair is mounir.
<linarobot> Useful Commands: #action #agreed #help #info #idea #link #topic.
<mounir> #link
<mounir> #topic announcement
<gcl> hi folks
<mounir> hi gcl
<mounir> 1st announcement - this week is our first kernel freeze, this Thursday is the freeze date
<mounir> is nico on?
<mounir> npitre - are you on the call?
<pfefferz> got something for the agenda
<mounir> pfefferz,  what is the item?
<dmart> I have an item too
<pfefferz> Android upstreaming
<pfefferz> ;)
<mounir> pfefferz, I should have guessed -  let me finish with the announcement topic then will move to your item
<pfefferz> cool
<dmart> my item is the alignment faulting
<dirk_b> If there is some time at the end I'd like to talk about the status of the Freescale loco kernel if possible
<mounir> dmart ok will do yours after pfefferz 
<mounir> dirk_b, sure
<mounir> any comments/issues regarding the kernel freeze this week?
<dmart> mounir: that's fine -- no rush
<mounir> hearing none, will move on
<mounir> second announce/request please fill up your registration to LDS in August if you have not done so yet
<mounir> #link
<mounir> that is all the announcements from my side. Anyone has an announcement/news to share with the team?
<gcl> mounir: I need to get npitre a pull req for the DT patches today or tomorrow
<gcl> but other than that I don't have any comments about the freeze
<arnd> mounir: the registration doesn't work if I arrive too early and/or don't stay in the hotel...
<mounir> gcl:  will you follow up with him, or you need me to touch base with him? Should I register this one as Action to npitre?
<gcl> mounir: npitre and I have already discussed privately.  I promised to get him a tree last week, but got distracted with other work
<gcl> no, it is an action for me
<mounir> arnd: hmmm - I will take that to the operations to see if we can improve for next time
<arnd> I've filled out no flight number and "other" now
<mounir> gcl,  ok
<arnd> I really want to start pulling stuff into arm-soc.git now
<mounir> #action - Mounir to discuss with Operations about Arnd registration issue above
<mounir> arnd: ok
<gcl> arnd: are you going to pull JohnLinn's Xilinx patches in this week?
<arnd> gcl, JohnLinn: Can you send me a pull request?
<arnd> did you address Russell's final concerns?
<gcl> JohnLinn: you should send the pull req
<JohnLinn> arnd: yes I can
<linusw> #action - linusw to send pull requests to Arnd for U300 and Ux500
<JohnLinn> arnd: not sure, would need to review them again as they weren't clear
<arnd> I also want to look at the CSR SiRFprima support, maybe it gets done quicker than expected and can get merged in 3.1 as well
<gcl> The comment had been that the patches need to use more common infrastructure, but as far as I can tell, it is already using the common stuf that is currently available
<arnd> ok
<mounir> pfefferz, you'r up go ahead
<pfefferz> cool
<arnd> gcl, JohnLinn: I'll definitely pull it then, but might wait for addon patches if more common support comes in before I send the pull request to Linus
<mounir> #topic Android upstreaming
<pfefferz> I'd like to bring up AOSP kernel upstreaming and team engagement
<linusw> arnd: To: Arnd / Cc: arm-linux-kernel / Subject: [GIT PULL] arm-soc patches for X - correct?
<JohnLinn> arnd: thanks, appreciate the help, will send a pull
<arnd> linusw: correct
<pfefferz> one of our jobs at Linaro is to engage AOSP
<pfefferz> I'd like to encourage everyone to start looking at the AOSP kernel tree
<arnd> AOSP == == "Android Open Source Project", I presume
* npitre is there, was distracted elsewhere
<pfefferz> at Cambridge I'd like to invite some Google and SoC kernel guys
<pfefferz> and see if we can hammer out some plans for the future
<pfefferz> and perhaps, even get somethings stage for upstream
<mounir> hi npitre
<pfefferz> any thoughts?
<mounir> pfefferz, are you in touch with John Stultz ?
<pfefferz> yeah...
* CosmicPenguin ( has joined #linaro-kernel
<arnd> pfefferz: are you talking about the master branch of git://, or are there other branches as well?
<pfefferz> if we could get some Android kernel and other SoC guys to Cambridge would the kernel team be open to working with them?
<pfefferz> arnd, I think that's it
<pfefferz> arnd, but that would be a good starter question for the Linaro kernel team to start talking to the Google kernel team
<arnd> pfefferz: the plan right now is to spend most of the time in Cambridge working on the single-zimage
<pfefferz> arnd, sure...that's why I'm bring this up
<pfefferz> arnd, lots of interest in this from ARM and OCTO
* rsajdok has quit (Ping timeout: 260 seconds)
<linusw> pfefferz: I would be happy talking to them, like if they could for example present how they think.
<mounir> pfefferz, what do you have in mind as far as time in the Sprint, all week, or some limites number of sessions?
<pfefferz> linusw, I appreciate it
<arnd> my impression (which may be wrong) of the android work is that the common android patches are fairly separate from the soc specific stuff, and both sides are primarily interested in seeing the other side move their code upstream
<arnd> since we're focusing on the cross-platform consolidation anyway in Cambridge, I think it would be great to have more SoC people there
<pfefferz> mounir, well the only way we'll be able to get Google to Cambridge is if we can offer some concrete things like, we'll all work together to plan the next kernel release, or lets try and get wakelocks in, or some such
<pfefferz> arnd, yeah...
<arnd> so we can talk about both Android upstreaming and the cross-SoC stuff
<pfefferz> arnd, if we can get Russell to Cambridge then a lot of people will come from industry
<pfefferz> the basic idea is for Linaro to take a big tent approach
<pfefferz> and try and work with everyone
<linusw> pfefferz, arnd: it would be great if someone from Tegra could join, preferably Colin Cross.
<pfefferz> and try and bridge differences
<mounir> pfefferz, during last meeting, we have discussed the format of the Sprint. It was discussed that the Sprint will be in 2 parts, 1) actual engineering work 2) planning for future direction
<pfefferz> I'd like to ask David Brown, Steve Mo, and Cosmic Penguin to come from QC
<mounir> pfefferz, so i think this would fit very well with the planning for future direction
<pfefferz> cool
<pfefferz> I'd like to be able to offer some real work getting done as well
<pfefferz> like, lets see if we can fast track these n patches upstream
<pfefferz> since all the interested parties would be co-located
<pfefferz> perhaps if everyone talks
<pfefferz> then we'll be able to come together
<linusw> pfefferz: sounds like it could be a good idea to ask participants to bring their reference design boards for quick turn-around testing
<pfefferz> yeah
<npitre> pfefferz: for that to succeed, you need to pull in those people who have problems with the android changes
<pfefferz> npitre, sure
<pfefferz> npitre, but we have to keep this bounded
<pfefferz> npitre, and we have to have an inclusive attitude
<pfefferz> npitre, find a way forward, etc...
<npitre> pfefferz: not having the opposition in the room is futile
<pfefferz> npitre, I'm not suggesting that
<linusw> pfefferz, npitre: if the subject is wakelocks (again, again) bringing Peter Zijlstra would be essential
<pfefferz> npitre, but its counter productive to get people there and then just start throwning around, you're stuff garbage, etc
<npitre> pfefferz: you have no choice but to bring people with different views together
<pfefferz> if Linaro can work with all sides and pull things together
<npitre> pfefferz: that's the only way to make progress
<pfefferz> then we'll make things a lot easier on everyone
<pfefferz> and set the stage for DT
<arnd> I still fear we will not get enough of the work that we have already planned done if we work on too many things at once during the sprint, it's already pretty ambitious if we want to get the same kernel booted on five eval boards as we discussed last week
<npitre> arnd:  won't happen
<npitre> arnd:  too unrealistic
<npitre> arnd: it is best to make a list of the steps we need to get there, and target some of them
<mounir> pfefferz,  I think we should dicuss this further with Deepak and the KWg to plan ahead, to see what will be covered and how much time we can allocate for this topic, so we will not jeopardize the rest of the 11.11 cycle work. Is this fair?
<pfefferz> yeah, that's fair
<pfefferz> want to set something up?
<npitre> pfefferz:  I think this is a bit late to invite outside people for the cambridge sprint
<mounir> #action Mounir/Deepak to set further discussion/planning for Android upstreaming at LDS
<pfefferz> npitre, no we just have to close on this ASAP
<mounir> dmart - do you want to go next ?
<pfefferz> npitre, if the right people are at Cambridge, then the SoC anvendors and Google will be there
<npitre> pfefferz: sure, but target the contentious people in priority
<dmart> mounir: sure
<dmart> Relating to the alignment fixups thing
<mounir> #topic  alignment faulting
<pfefferz> npitre, that's fine, but we need people with constructive contentions points
<dmart> (I'll assume everyone glanced at the thread, but give me a shout if you want more explanation)
<linusw> npitre: I'd suggest since we're in Cambridge, could the ARM folks bring their Integrator, Versatile, RealView and Vexpress boards and we could get a single kernel for them? They all have different CPUs ... :-/
<npitre> linusw: sure, but those are the easy targets -- we already supports multiple CPUs
<dmart> Steve Langasek pointed out that there's a prctl(PR_SET_UNALIGN) call supported on some arches, to enable alignment faulting per process
<dmart> I don't think this exists for ARM
<dmart> Does anyone have an opinion on whether this is something we should look at?
<linusw> npitre: sound like it could be done then, actually...
<npitre> pfefferz: no matter how you spin it, if you don't get a agreement with the opposing people, you'll achieve nothing in mainline
<dmart> Currently, alignment faulting can only be controlled globally, and the kernel doesn't support full alignment faulting at all on v6|
<dmart> v6+
<arnd> linusw: merging the three plat-versatile subarchitectures requires very different steps from merging across plat-* directories
<linusw> arnd: true
<pfefferz> npitre, sure
<arnd> dmart: I didn't really understand the v6+ part. If we don't get faults there, why do we even care about alignment exceptions on v7?
<npitre> arnd:  only some instructions support misaligned accesses in hardware on v6+
<dmart> unaligned access is still suboptimal, and often unintentional.  Some apps people (such as the mozilla community) work hard to get all the unaligned accesses out of their software
<dmart> So the prctl facility is potentially useful for userspace optimisation
<dmart> This is a separate issue from the unconditional faults which cause an expensive kernel trap
<npitre> dmart:  currently the alignment trap config is inconsistent on v6+ so that part at least deserves to be fixed
<dmart> npitre: you mean, full alignment faulting should be the default? (?)
<npitre> dmart:  whether or not we want to go to a per process config for it is a separate issue
<npitre> dmart:  I mean that you won't obtain the expected result if you change its config in /proc/cpu/align
* linusw has missed the unaligned business and is looking for a ML pointer
<npitre> dmart: on v6 you need to play with the CR_U bit as well, while the code only deals with the CR_A bit at the moment
<dmart> yes, I think CR_U is just left set at the moment, if supported
<arnd> fwiw, the GET_UNALIGN_CTL macro is currently implemented on alpha, ia64, parisc, powerpc and sh
<arnd> the ABI is there, calling it just returns -EINVAL on ARM
<dmart> So, do we want to do anything about that?
<arnd> I think implementing {GET,SET}_UNALIGN_CTL would be good
<npitre> would be good to fix
<dmart> arnd: is that the same as the PR_GET_UNALIGN and PR_SET_UNALIGN prctl() calls?
<mounir> dmart, will you handle, or we mark help needed for this?
<arnd> dmart: yes
<dmart> arnd: ok
<arnd> dmart: see kernel/sys.c
<dmart> arnd: oh, right
<arnd> linusw: See thread "Getting rid of alignment faults in userspace" on linaro-dev
<dmart> mounir: it sounds like it would be nice for someone to look at it.  I can take an initial look if people want, but this is an extra work item
<linusw> #info discussion under subject "Getting rid of alignment faults in userspace" on the linaro-dev mailing list
<mounir> #help with alignment faulting
<mounir> few minutes left I want to skip to bugs to ask shawnguo about:
<mounir> shawnguo,  is this bug fixed, done?
<shawnguo> mounir: yes, it's done
<mounir> shawnguo, very good. thank you
<shawnguo> mounir: sure
<mounir> gcl: you had an action to get with linusw,deepak and jeremy,  was this done?
<linusw> mounir: due 30th! We still have a few days...
<mounir> linusw: ok 
<gcl> mounir: no, we've not talked about it at all
<mounir> #info we can now get burndown per team per milestone. Also we can get burdown per person per milestone. But first we have to mark the Wok Items to specific milestones
<mounir> we will be doing more and more of monthly planning as we everyone in Linaro is now focused on monthly releases
<mounir> npitre: any words before we close the meeting about this Thursday upcoming kernel freeze?
<npitre> HDMI on Panda is still broken
<mounir> will that be a release bloker or no?
<npitre> we'll also need a way to associate bugs with a particular monthly kernel release, and work out if bugs should be transferred to the next release, etc.
<npitre> mounir:  yes, that's certainly a blocker
<npitre> nothing else for the moment
<mounir> npitre: who is engaged with this one? I will talk with asac and fathi about so they put additional focus
<npitre> mounir:  agreen I guess
<mounir> #action: Mounir to follow up with asac, fathi and agreen on the HDMi issue
<mounir> npitre: can't we target bugs to milesone, I think we can
<npitre> mounir:  OK then we'll have to be more diligent about that
<mounir> npitre: yes - can I ask you off line what do we need to do, so we can tell the team what to do?
<mounir> any other topic?
<npitre> just to properly identify to what kernel the bug applies to, and then we'll have to test those bugs in later kernels
<mounir> npitre: ok I will go over targeting a bug and then will send a note reminder
<mounir> if not other topic, I move to close the meeting 
<mounir> thank you everyone
<mounir> #endmeeting
<linarobot> Meeting ended Mon Jun 20 16:05:05 2011 UTC.
<linarobot> Minutes:
<linarobot> Minutes (text):
<linarobot> Log:  
<linarobot> Wiki: 
* svenkatr (~svenkatr@nat/ti/x-blrwehkpyujexdqt) has left #linaro-kernel
* dmart ( has left #linaro-kernel

Evening meeting IRC log

<mounir> Hello anyone there?
<jstultz_vm> mounir:  hey
<pfefferz> hey
<jstultz_vm> mounir:  sorry, busy writing..
<mounir> jstultz_vm, not sure whether to run the meeting or not. But since you and pfefferz are on. There is at least one item worth mentioning
<jstultz_vm> :)
<mounir> I have setup a meeting (based on one of the morning meeting action) to discuss Android upstreaming at the LDS 
<mounir> in August
<jstultz_vm> mounir:  yea, pfefferz and i chatted some today on that. would be interesting, sadly i won't be there, so i'm not sure how much i can contribute.
<jstultz_vm> mounir:  i think the CMA/pmem/etc work from Jesse and Arnd would be good to continue to keep google folks involved in.
<mounir> jstultz_vm, Arnd raised the issue of over committing, that why we have the meeting to discuss what can be done without jeopordizing cycle 11.11
<jstultz_vm> overcommitting?
<mounir> Arnd thinks we should keep focusing on the single kernel image
<jstultz_vm> mounir:  so he's feeling constrained with that vs the cma bits? ok..
* jstultz_vm is reading the irc logs
<mounir> pfefferz, do you want to state what you are suggesting for jstultz_vm or he already knows of what you want to accomplish in LDS
<pfefferz> I think he knows
<pfefferz> but the whole discussion brings up a key point we need to close on first
<pfefferz> which is...who's tree do we base our Android work off of
<pfefferz> ..and for that I need to get input from all the LTs and Rodger Teague and Kiko and the kernel team
<jstultz_vm> pfefferz:  at this point i think its based off of nico's tree.  some arguments can be made for nico's tree to be closer to mainline, but nico is porting quite a bit of upstream changes back into his tree..
<pfefferz> ...but john wasn't opposed to having an upstream plugfest
<pfefferz> sure...
<jstultz_vm> so its not that far.. i'd rather it just be mainline personally, but i'm not maintaining the tree, so my opinions are somewhat limited
<jstultz_vm> in value
<pfefferz> I think they're very important
<jstultz_vm> it also keeps the landing teams focused for both android and ubuntu images on nicos tree.
<pfefferz> if the work is based off of Nico's tree then the focus is on upstreaming
<pfefferz> if the work is based off of AOSP kernel tip (3.0) then the focus is on enablement
<jstultz_vm> pfefferz:  some of that is one and the same..
<pfefferz> sure...
<jstultz_vm> pfefferz:  ie: enablement being upstreamed via nico's tree.
<mounir>  I thought the flow is Nico's -> jstultz_vm's work, with the LT's pushing to Nico's tree. Is this not the right understanding
<jstultz_vm> pfefferz:  what other "enablement" work do you see out there?
<pfefferz> well...since Nico's tree isn't tip AOSP
<jstultz_vm> mounir:  that is correct..
<pfefferz> then our vendors are behind
<pfefferz> if our work was off AOSP tip
<jstultz_vm> pfefferz:  eeehh..  that's not quite the case..
<pfefferz> then we;re shipping Panda enablement on AOSP tip
<pfefferz> for instance
<jstultz_vm> pfefferz:  first of all, most hardware enablement isn't AOSP specific..
<jstultz_vm> pfefferz:  there's not much new in the common tree, release to release,  in otherwords.
<pfefferz> ..sure...
<pfefferz> take it for granted that I know all the issues
<jstultz_vm> pfefferz:  and nico's tree pulls most of linus' git tree for arm
<pfefferz> I'm just giving you my expereince with vendors
<jstultz_vm> pfefferz:  so the hardware enablement picture should be similar.
<pfefferz> similar, but vendors don't see it that way
<pfefferz> they're on AOSP tip or not
<pfefferz> which means...
<pfefferz> when 3.1 comes out
<pfefferz> the kernel is already done
<jstultz_vm> pfefferz:  in my experience they're 4 versions behind anyway, so i'm not sure tip vs almost tip is that big of a difference
<pfefferz> I didn't say the belief was rational
<pfefferz> its more like a checkbox
<jstultz_vm> pfefferz:  i do think nico's tree being on the latest release would have benefits, but again, you have to convince nico on this, not me..  because there are also tradeoffs that nico would have to deal with
<pfefferz> anyway...its the bigger question
<pfefferz> ...but I'm not going to convince nico...
<jstultz_vm> pfefferz:  and non-rational checkbox arguments aren't what we should be basing our work on here.
<pfefferz> perhaps...
<pfefferz> but if our members ask for it
<pfefferz> then we'll need to help them out
<pfefferz> and I'm pretty sure Rodger's thinking that way
<jstultz_vm> pfefferz:  again, its not in the cards for 11.06... 11.07 or 11.08 maybe we can talk about it, but its going to require more debate in the kernel team.
<pfefferz> ...but I could be wrong
<pfefferz> agreed...actually I would expect the requirement to come down from David Rustling
<jstultz_vm> so i'd stick with the nico->jstultz->LT path for now.. and we can work on trying to discuss the pros/cons more with nico.
<pfefferz> I'll let you handle that bit
<jstultz_vm> otherwise we end up with *more* trees and that doesn't help things.
<pfefferz> or mounir or Paul McKenny
<pfefferz> well, it helps us stay funded
<pfefferz> which is pretty cool
<pfefferz> customer apps engineer is showing ...
<jstultz_vm> pfefferz:  funded to unproductively juggle kernel trees won't last long :)
* robher ( has joined #linaro-kernel
<mounir> pfefferz, this discussion has to proceed the request to invite and engage Google engineers to LDS?
<pfefferz> I'm not sure, being about to put out Android builds across all boards with full enablement, based on AOSP + you're patches doesn't sound unproductive to me
<jstultz_vm> mounir:  i don't think so, personally. i think figuring out the (limited) scope of what we want to discuss would be important.
<jstultz_vm> we need to have realistic set of items that we can focus on and hammer out with the google folks.
<pfefferz> maybe not proceed...but we have to figure out how we want to engage the Google engineers, do we want to help on the frontend or the backend or both
<pfefferz> with the upstream only model we're helping from the backend
<jstultz_vm> personally i think the cma discussion from ELC was really good, and we should try to continue that effort.
<pfefferz> with the AOSP model we're helping from the front end
<pfefferz> it was a good discussion, but nothings been done
<pfefferz> and Google will always saw, yup, great idea
<pfefferz> but go they're own way
<jstultz_vm> pfefferz:  don't know about that.. arnd was looking at the cma code, and seemed to have a good grasp on next steps.
<pfefferz> we should be actively engaging
<pfefferz> for the upstream task
<jstultz_vm> having time is likely an issue there, but the multimedia team may be able to help
<pfefferz> maybe
<pfefferz> if our CMA plans don't get buy in from Google, in their tree, then they haven't bought in
<pfefferz> if CMA lands upstream without that, they won't use it
<pfefferz> and the problem won't be solved
<pfefferz> basically agreement from Google == code in AOSP
<jstultz_vm> right, but just having folks understand the problem (on both sides) was a large amount of work
<pfefferz> yup
<pfefferz> and I brought in a lot of those people
<jstultz_vm> so it seems that that effort should continue.
<pfefferz> since I did that work at QC
<pfefferz> yeah...but the effort should push to Google
<pfefferz> because then we'll really be helping
<pfefferz> if Google says yes and upstream says yes...then we're good
<pfefferz> if Google says yes and upstream says no...we'll help 99% of all ARM vendors
<jstultz_vm> pfefferz:  right, but google already has an implementation (multiple ones :)
<pfefferz> if upstream says yes and Google says no we'll only be supporting non-Android ARM vendors who have giant SoCs
<pfefferz> sure...
<jstultz_vm> pfefferz: so understanding google's implementation, and pushing community implementations to either adapt googles solution or implement something compatible also solves the issue.
<jstultz_vm> (and pushign the api mending via ASOP is fine...)
<pfefferz> long as its modular and easy to switch out, its okay
<jstultz_vm> but the fight for long term solution is upstream..  if google says yes, and the community says no, we help 99% of arm vendors for 6 months.
<jstultz_vm> and then it has to be done again.
<pfefferz> actually no
<pfefferz> because all the ARM vendor stuff will get rebased
<jstultz_vm> right, but the arm vendors will be doing something else slightly incompatible..
<jstultz_vm> google doesn't use pmem with tegra..
<pfefferz> right...they're building something very specific for it
<pfefferz> which they'll use
<jstultz_vm> but again.. we can hash around this for awhile.. i'm not doing work in the area so my opinions are again of less value here.
<jstultz_vm> so its probably not worth the debate.
<pfefferz> yeah...
<jstultz_vm> i just thought i saw really positive interaction at ELC, and i'd hope that would continue
<pfefferz> heck if you could end the wakelock stuff
<pfefferz> you'd be a hero
<pfefferz> sure...but ELC wasn't the whole crew
<jstultz_vm> pfefferz:  wakelocks is radioactive right now.. not even for technical reasons.. it has its own mythology!
<pfefferz> I know
<pfefferz> like I said ...hero
<jstultz_vm> pfefferz:  so its probably something to handle last.
<pfefferz> of first...the patches are pretty small
<pfefferz> s/of/or/
<jstultz_vm> paul and i already hammered a bunch of runtime-pm folks on the need for wakelocks at ELC.. its going to be a long effort of education
<pfefferz> sure...
<pfefferz> I I think theres an end there
<pfefferz> Arve did reengage the community
<pfefferz> who would need to be convinced?
<pfefferz> how much beer are we talking here?
<pfefferz> heck we could just invite Arve...the runtime PM guys and russell
<jstultz_vm> pfefferz:  years of beer. :)
<jstultz_vm> pfefferz:  already been tried.. i'd be hesitant there.
<pfefferz> and put them in a room and say...sort it out
<pfefferz> for the good of Linux
<pfefferz> If the kernel team accomplished that one thing
<jstultz_vm> pfefferz:  already been attempted. i think there's some rough feelings there. so any sort of "sit in a room and hammer it out" is going to be tough on entrenched issues (most specifically wakelocks)
<pfefferz> that would be a buge marketing boost to other members who are on the fence
<pfefferz> perhaps posix timers
<pfefferz> Collin sounded positive?
<jstultz_vm> pfefferz:  i suspect slow and steady is the approach..
<pfefferz> sure
<jstultz_vm> pfefferz:  regarding the posix alarmtimers, colin didn't sound positive, or negative, just said it was temporary until arve can look at it
<jstultz_vm> pfefferz:  and i mailed him and arve to say i'd be happy to help answer questions and try to integrate things.
<pfefferz> hehe...I can imagine how that conversation may go
<jstultz_vm> pfefferz:  arve has been really reasonable in my conversations with him.
<pfefferz> that's cool
<pfefferz> I like working with him too
<pfefferz> and Brian
<pfefferz> good guys...
<jstultz_vm> anyway...
<jstultz_vm> mounir:  anything else?
<mounir> no - just to remind you that kernel freeze is this Thursday  
<jstultz_vm> mounir:  yep. i'm planning on pushing a frozen linaro+android tree on friday based off of nico's frozen tree.
<jstultz_vm> i suspect the omap4 hdmi issue will still be at large
<mounir> pfefferz, anything else from your side?
<mounir> jstultz_vm, yes the HDMi still not fixed and nico said it is a blocker for the release
<pfefferz> nope, just need to get some clarification from Rodger...lots to talk about in Cambridge
* robher has quit (Read error: Operation timed out)
<mounir> ok - then good night everyone
<jstultz_vm> mounir:  night!
<pfefferz> pmem stuff

WorkingGroups/KernelArchived/Meetings/2011-06-20 (last modified 2013-01-14 19:43:04)