This month's meetings

WorkingGroups/Kernel/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:
  • Linus Walleij:
  • Mounir Bsaibes: x
  • Nicolas Pitre: x
  • Niklas Hernaeus: x
  • Paul McKenney:

  • Per Forlin:
  • Grant Likely:
  • Andy Green:
  • Tixy: x
  • John Stultz: x
  • Thomas Abraham:
  • Manjunath Kondaiah:
  • Shawn Guo: x
  • Venkatraman Sathiyamoorthy: x
  • bones10: x

Agenda

  1. Milestone Process
    • Keeping WIs updated
    • Need to assign WIs to proper monthly milestones
  2. Blueprints / Around the table
  3. 1. Pending Action Items
  4. BUGS review

Action Items from Previous Meeting

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

Minutes From Today's Meetings

  • Milestone progress - the work being done is not reflected the work that is being done. Request to keep the WI's updated.
  • We need to start with the monthly planning, Deepak wanted to handle the planning during the 1x1 meetings at the beginning of the month.
  • Blueprint updates / Around the table
    • jstultz_vm
      • android upstreaming: currently blocked on AOSP group membership/license grant stuff. working on a test case to demonstrate that my mending of the anrdoid patches to use the newly upstreamed posix alarm timer work is functioning properly the aosp stuff needs to get fixed soon, its been 2+ weeks now.
      • kconfigstuff: has been going slowly due to other distractions
      • android-common tree: lots of discussion over the last few weeks about kernel flow process. But for 11.07 i'm pushing a 3.0 kernel out so the android platform team can get started testing, and will merge in nico's 11.07 bits as soon as they become availab.e
    • shawnguo:
      • I'm working on migrating imx driver to device tree aware. Right now, serial, fec, gpio, esdhc and spi are basically done, and I'm confident they will hit v3.1 window. next will be i2c, sdma, ssi, etc ...
    • bones10
      • I've been working moving tegra over to use the device tree. I have most of the devices being initialized using the device tree. I've had to make adjustments to Grant's AUXDATA array structure to include a device id - i2s needs an id. I need to rebase to Grant's latest devicetree/test branch - tegra device tree compatible strings changed. The biggest thing I have left for things to be an a good state is to move the pin mappings for the audio card into the device tree
      • dmart
        • One think that came up last week it that my work items are in a bit of a mess, due to some tasks being assigned to other people, and due to things going missing when the blueprints were rearranged. I'll try to finish sorting that out this week. Workwise, I'm still working on kernel standard architecture. Currently, I'm experimenting with merging ARM's Cortex-A15/LPAE support with the current linaro kernel.
    • nhe
      • DT on Snowball: Booted Snowball, with DT, it would seem, but most wi:s left to do. Trying to verify kexec on Snowball at the moment.
    • tixy Last week had iscussions with dmart and npitre about how kprobes should handle Thumb/ARM interworking, and supporting ARM probes on Thumb kernels. After reworking my code for this I finally submitted kprobe Thumb-2 support patches for review on Saturday. I'm now preparing patches for moving kprobe ARM support to new decoding table scheme, and patches to add my kprobes test code. I also need to discuss with maintainers of generic kprobes code about fixing a potential deadlock issue involving text_mutex and cpu-hotplug. I hope that I will have some time this week to finally start on blueprint "Investigate block allocation in FS"
    • npitre:
      • the 11.06 kernel is "released"
      • I'm currently intensively interacting with the upstream ARM kernel community around new patches pushed for mainline
    • arnd:
      • I've been busy merging branches from subarch maintainers, and learning how to do it in the process. My feeling is that it's going well enough, but some (samsung, qualcomm, nvidia) have not sent anything yet. I should probably remind them that if there is nothing coming now, they will be left out of 3.1. Last week was crazy with incoming email though, I'm hardly catching up. also, a lot of discussions about CMA recently, but the code looks good now IMHO, we just need to convince Russell. well, and fix the problem that he complained about

Action Items From Today's Meetings

IRC Logs

Morning meeting IRC log

<mounir> Hi Who is here for the kernel WG weekly meeting?
<mounir> dsaxena, may not join today, he is not feeling well
<tixy> I am here
<bones10> Is everyone out of town today?
<mounir> hi tixy
<nhe> checking in...
<mounir> hi nhe
<shawnguo> hi everyone
<jstultz_vm> mounir:  i'm here
<tixy> hi Shawn
<shawnguo> hi tixy
<mounir> hi bones10, which town :)
<bones10> :-) their own
<mounir> hi jstultz_vm 
<mounir> hi shawn
<shawnguo> hi mounir
<bones10> I believe grant is in Korea
<shawnguo> jstultz_vm: mounir does not need to have a 1:1 meeting 12 hours later :)
<dmart> hi all
<mounir> hi dmart
* arnd (~arnd@nat/ibm/x-lqpuwsdtqkyiasui) has joined #linaro-kernel
<arnd> hi
<mounir> hi arnd
<mounir> we are about 5 minutes after let us go ahead and start
<jstultz_vm> shawnguo:  yea, with so few folks showing up to the late one, i figured it wasn't fair.
<mounir> jstultz_vm, thx that makes it easier - the question are you awake?
<mounir> #startmeeting
<mounir> https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-07-11
<mounir> #topic Milestone process
<mounir> #link http://status.linaro.org/11.11/linaro-kernel-wg.html
* matthsu has quit (Ping timeout: 240 seconds)
<mounir> I don't think the status reflects exactly the work that is being done. For example, we already produced 2 Monthly releases and that is not reflected in the status
<tixy> My work items also don't get counted as I'm not officially in the team
<mounir> tixy: yes 
<mounir> please keep up with your WI's. 
<npitre_> I probably have to mark the 11.06 kernel as released
<mounir> npitre, yes
<mounir> I like how per does his WI's. Along with his weekly activity report, he marks his WI and report on them in his weekly activity report. he kills two birds in one stone 
* svenkatr (~svenkatr@117.192.254.176) has joined #linaro-kernel
<mounir> on another note, related to the monthly milestones, deepak wanted to do the monthly planning (i.e. mark WI's that will be done in the month) during his 1x1's 
<mounir> is that work for you, or your prefer to do it differently ? 
<npitre_> I see no problem with that
<mounir> ?
<mounir> Oh sorry, you said see NO problem with that 
<mounir> ok then - this is one way to do it, has deepak  started doing it for this month?
<npitre_> no idea if he did with others, but not with me yet
<tixy> I missed my last 1:1 as was on holiday for
<mounir> Another way we can do it, is each one go over his own owrk items and divid them in blocks and mark each block for a specific month
<mounir> if you have question how to do that, please let me know, I can work with you on that it is very very simple
<tixy> don't we have to do that anyway?
<mounir> tixy, yes we have to, specially now we are doing monthly releases
<mounir> any question/discussion reagrding this before I move on to the next topic?
<shawnguo> mounir: some of us are working on blueprint against mainline tree
<shawnguo> mounir: when we mark WI done?
<shawnguo> mounir: and how those work take effect on linaro tree as far as monthly release concerned?
<mounir> shawnguo: First you mark the Wi "In Progress",  if you submitted and get accepted you mark it done.
<mounir> shawnguo, if you submitt and get hard time getting it accpeted, you mark the item BLOCKED
<jstultz_vm> shawnguo:  while mainline work doesn't impact a specific 11.07 or whatever linaro release, if the work is being done upstream in July, i'm providing updates in the blueprint as if it were part of the 11.07 release.
<jstultz_vm> shawnguo:  so when the code gets merged upstream, i mark it done.
<shawnguo> jstultz_vm: so we do not need to worry about linaro tree, right?
<jstultz_vm> shawnguo:  yea, the linaro tree should pick it up on the next cycle..
<shawnguo> understood, thanks, jstultz_vm, mounir
<mounir> anyother question?
<jstultz_vm> shawnguo:  if you want to backport it to the linaro tree, that would prob be another line item.
<mounir> #topic Blueprint/around the table
<shawnguo> jstultz_vm: no I do not want to unless I'm asked to :)
<jstultz_vm> shawnguo:  :)
<mounir> jstultz_vm, would you like to go first
* matthsu (~matt@114-25-235-204.dynamic.hinet.net) has joined #linaro-kernel
<jstultz_vm> mounir:  blueprint/ around the table? just want status on the blueprints i'm working?
<mounir> yes please - update what you are doing, planning to do, sort of you activity report, if you have an issue you like to discuss here, that sort of thing
<jstultz_vm> mounir:  so, android upstreaming: currently blocked on AOSP group membership/license grant stuff. working on a test case to demonstrate that my mending of the anrdoid patches to use the newly upstreamed posix alarm timer work is functioning properly
<jstultz_vm> the aosp stuff needs to get fixed soon, its been 2+ weeks now.
<jstultz_vm> kconfig: stuff has been going slowly due to other distractions
<mounir> jstultz_vm, I noticed that in your last activity report and I have listed as an issue for release management, will re-emphasis that this week as well
<jstultz_vm> android-common tree: lots of discussion over the last few weeks about kernel flow process.
<jstultz_vm> but for 11.07 i'm pushing a 3.0 kernel out so the android platform team can get started testing, and will merge in nico's 11.07 bits as soon as they become availab.e
<jstultz_vm> that's basically all for me right now.
<mounir> jstultz_vm, very good thanks for the update
<mounir> shawguo: next?
<mounir> shawnguo, next?
<shawnguo> I'm working on migrating imx driver to device tree aware
<mounir> ok thx
* rsajdok has quit (Ping timeout: 240 seconds)
<shawnguo> right now, serial, fec, gpio, esdhc and spi are basically done, and I'm confident they will hit v3.1 window
<shawnguo> next will be i2c, sdma, ssi, etc ...
<mounir> shawnguo - very good, are you thinking at all about the LTP tests at all?
<shawnguo> mounir: not really, I'm pretty loaded :)
<mounir> shawnguo: :) you know your priorities
<mounir> bones10, would lyou ike to report your activities?
<bones10> mounir: I can. I've been working moving tegra over to use the device tree
<pfefferz> and we're really jazzed about 3.0
<bones10> I have most of the devices being initialized using the device tree
<mounir> bones10: exciting thing, do you have a lot to do?
<bones10> I've had to make adjustments to Grant's AUXDATA array structure to include a device id - i2s needs an id
<bones10> I need to rebase to Grant's latest devicetree/test branch - tegra device tree compatible strings changed
<bones10> The biggest thing I have left for things to be an a good state is to move the pin mappings for the audio card into the device tree
<mounir> bones10 - thanks for the update - good stuff
<bones10> I don't think it's a lot left
<mounir> dmart: next? 
<bones10> mounir: thanks for asking
<mounir> nhe: do you want to go next?
<dmart> One think that came up last week it that my work items are in a bit of a mess, due to some tasks being assigned to other people,
<mounir> dmart, r u working that with deepak?
<dmart> and due to things going missing when the blueprints were rearranged.
<nhe> Short: DT on Snowball: Booted Snowball, with DT, it would seem, but most wi:s left to do.
<dmart> Yes -- I'll try to finish sorting that out this week
<nhe> Trying to verify kexec on Snowball at the moment.
<dmart> Is there documentation somewhere explaining how all the different blueprints interrelate and where work items should go?
<mounir> dmart:  you mean blueprints dependencies, how you set the dependencies for blueprints?
<dmart> I find the current setup pretty confusing.  Really, we seem to be abusing launchpad blueprints to represent things they're not designed for, but I don't know if there's an easy solution for that.
<dmart> How to set dependencies in launchpad is clear enough; the unclear part (for me) is the set of conventions that we're using in linaro
<dmart> For example, we have tr blueprints and uds blueprints (and maybe others).  It's not always clear where work items should go, or how things relate.
<mounir> dmart: can I touch base with you after the meeting to understand what is not clear for you and discuss a bit?
<dmart> OK, thanks.
<mounir> dmart; In general it try to tell people to ingnore the UDS blueprints.
<mounir> a tr blueprint the meta blueprint, that is dependent on the engineering blueprints
<mounir> that is all
<mounir> will talk after the meeting
<mounir> nhe: anything else from your side?
<dmart> OK
<nhe> I wait until gcl comes back ;-)
<mounir> nhe: ok meanwhile you work on the kexec?
<dmart> Workwise, I'm still working on kernel standard architecture.  Currently, I'm experimenting with merging ARM's Cortex-A15/LPAE support with the current linaro kernel.
<nhe> I work on both, but the boot procedure is not that easy...
<npitre_> dmart: current linaro kernel is going to be 3.0 RSN
<mounir> nhe:ok
<mounir> tixy: would you like to go next?
<tixy> Last week had iscussions with dmart and npitre about how kprobes should handle Thumb/ARM interworking, and supporting ARM probes on Thumb kernels.
<dmart> npitre_: currently I'm working on linux-linaro-2.6.39 as an intermediate step
<tixy> After reworking my code for this I finally submitted kprobe Thumb-2 support patches for review on Saturday.
<dmart> npitre_: "RSN"?
<tixy> I'm now preparing patches for moving kprobe ARM support to new decoding table scheme, and patches to add my kprobes test code.
<npitre_> dmart: real n=soon now
<tixy> I also need to discuss with maintainers of generic kprobes code about fixing a potential deadlock issue involving text_mutex and cpu-hotplug.
<npitre_> dmart: real soon now
<mounir> tixy: I think you have been keeping up with the WI's right, I see your updates everyonce in awhile
<tixy> I hope that I will have some time this week to finally start on blueprint "Investigate block allocation in FS"
<dmart> npitre_: oh, right ;)
<tixy> mounir: yes, I keep my work items up to date
<mounir> tixy: thank you for that 
<mounir> npitre: next?
<npitre_> the 11.06 kernel is "released"
<npitre_> I'm currently intensively interacting with the upstream ARM kernel community around new patches pushed for mainline
<npitre_> that's a pretty complete summary ;-)
<mounir> npitre: I have created a milestone for 11.07, release management wants a milestone page for every deliverable(component) for the integrated monthly release
<mounir> arnd: next? 
<arnd> I've been busy merging branches from subarch maintainers, and learning how to do it in the process. My feeling is that it's going well enough, but some (samsung, qualcomm, nvidia) have not sent anything yet. I should probably remind them that if there is nothing coming now, they will be left out of 3.1. Last week was crazy with incoming email though, I'm hardly catching up.
<arnd> also, a lot of discussions about CMA recently, but the code looks good now IMHO, we just need to convince Russell ;-)
<arnd> well, and fix the problem that he complained about
<npitre_> arnd: we need to address the cache attribute issue first I'm afraid
<arnd> yes
<arnd> I think if the timing is right, that may actually help get it in
<arnd> i.e. if Marek finds a working solution before rmk does
<jstultz_vm> arnd:  with all the cma discussion, have the google folks been involved? i'm seeing them shift to using their own ion work internally for the 3.0 kernel.
<npitre_> arnd: someone posted patches to move the direct kernel mapping to page level like a year ago
<arnd> jstultz_vm: I think it's unrelated, CMA is the low-level allocator used by the dma-mapping API, while ion is another user-level API that is not going anywhere
<arnd> npitre_: there should be a smarter solution than that with CMA -- you only need to make the CMA regions page level mapped
<mounir> arnd: are you doing anything related to storage optimization, or you don't have time to focus on that now?
<arnd> but we probably also still need a pool of dma pages for atomic allocations
<jstultz_vm> arnd:  ok. i just haven't been following the discussion super closely, but was hoping they were providing some input..
<npitre_> arnd: sure, but once you have the infrastructure for page mapping it is easy
<arnd> mounir: no, I'm not doing anything there in depth. I do the occasional card measurement to add to the list, and my intern will arrive in a few weeks to do a lot of work, but not myself
<mounir> arnd: ok 
<arnd> jstultz_vm: we also have work items relating to the user-level API, but I don't think anyone has posted patches for that yet
<arnd> npitre_: yes
<arnd> npitre_: what's your plan for the cleanup patches you posted?
<mounir> did I miss anyone in the meeting?
<arnd> do you want to just create branches for those in the arm-soc tree once the review is done?
<npitre_> arnd: ideally I'd want RMK to take them
<arnd> ok
<npitre_> arnd: I still need to convince him for many of them
<arnd> yes
<mounir> we are at the top of the hour, anyone would like to bring a quick topic, announce something, etc...?
<tixy> Has there been any discussion or decisions about the future of the Linaro kernel tree? (There was some question as to its usefulness.)
<mounir> npitre?
<npitre_> it is still being discussed so to say
<tixy> OK
<npitre_> the matter is brought up to the tsc, etc.
<mounir> npitre: but w are still releasing for July, correct?
<npitre_> yes, no changes for now
<mounir> ok
<mounir> anything other question, comment?
<mounir> if not, thank you all for joining the meeting, have a good day, afternoon real early morning, etc....
<mounir> #endmeeting

WorkingGroups/KernelArchived/Meetings/2011-07-11 (last modified 2013-01-14 19:40:12)