This month's meetings

WorkingGroups/Kernel/Meetings
<< <  2011 / 4 >  >>
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  

Meeting info

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

Attendance

  • Arnd Bergmann: x
  • Dave Martin: x
  • Deepak Saxena:
  • Jason Hui:
  • Linus Walleij: x
  • Mounir Bsaibes: x
  • Nicolas Pitre: x
  • Niklas Hernaeus: x
  • Per Forlin: x
  • Grant Likely:
  • Andy Green:
  • John Stultz:
  • Thomas Abraham: x
  • Manjunath Kondaiah:
  • Shawn Guo: x
  • Venkatraman Sathiyamoorthy: x

Agenda

  1. Announcement / Upcoming Release Dates
  2. Around the table: Work Items updates, what's next
  3. BUGS review

Action Items from Previous Meeting

Minutes

Announcements

Around the table

  • svenkatr
    • Working on eMMC4.5 HPI feature
    • Have an issue that the time to interrupt window is very small for the HPI to be actually exercised, was discussing with Kyungmin Park. will try to discuss /resolve also with Arnd, Per and Linusw.
    • This item relates to any Work Items in the blueprints
  • nhe
    • Working on Snowball device tree, working with Linus, still do not know if we are going to use appended device tree to zImage or u-boot. Problems either way. And I need to know this before I can update the blueprints in a meaningful way.
    • LinusW: I can just as well state something on the DT work in this context.. I tested appended device tree on U8500 and ARM RealView PB1176 and existing patches did not work on either. Nor was it easily fixable AFAICT, I have informed nico about the issue. The problem is that St-Ericson U-Boot for this platform is way out of sync with mainline from a 2009 snapshot, so it will be some weeks/months of mainlining U-boot work instead of working with device tree for U8500

    • Nico will submit patches which used to work at one time, so these patches can work again. I want to submit those patches upstream this week so they work again. LinusW and Niklas will test the patches as they come available.
  • linusw
    • mainly been doing DT investigations last week and some minor patches to keep sanity
    • this week I need to focus on the pinmux core again, nVidia have very complex requirements on the subsystems, and pretty much no one else is providing any feedback so I have to satisfy them. I'm on the verge of fixing it so think it makes sense to make a try
  • shawnguo
    • I posted the first version of imx6q patch series, Arnd criticized the clock code for not using device tree for probing the clock data.
    However, this can only be done when the clock framework and common clock device tree binding are available, and unfortunately these two things are still up in the air without a specified time for being ready. Arnd Stated: I hope we can find a way out on the meeting this wednesday, if it continues to look bad for the clock framework to go in, will take Shawnguo your patch set.
    • Shawnguo to ping tglx to comment on the patches.
    • per LinusW regarding struct clk the way forward is to look at the patch set as-is and decide for a way forward this week and Thomas NACK:ed and said that we need and infrastructure core for it as well, not just making several implemenations live in parallell. so he's reportedly ventured into sketching an outline of that.

  • dmart
    • I have been continuing with the vexpress device tree work and some miscellaneous Thumb-2 issues reported by Arnd on vexpress DT, I have some input from other ARM guys which I need to integrate -- this has slowed things down a bit, but it should give a reasonable level of initial support
    • My aim is to post patches this week, a few should be completed this week if I get as far as posting patches
    • redrafted the work items on https://blueprints.launchpad.net/linux-linaro/+spec/kernel-versatile-boad-description-and-implementation to reflect the work I'm doing

    • also started the (delayed) Thumb-2 kernel migration write-up. I'll post something for people to look at soon -- hopefully this week
  • arnd
    • I pulled patches from various soc maintainers, after finally moving the tree over to git.linaro.org (temporary while git.kernel.org is down).
    • Sending pull request for bug fixes right now.
    • I've also spend a lot of time last week on randconfig fixes mentioned by dmart, got 10 platforms to build 97% of time and still need to send out ~150 patches for this to the respective maintainers.
    • Published a short article on lwn.net about the upcoming architectures we discussed here (hexagon and c64x). -> http://lwn.net/Articles/457635/

    • the randconfig eventually will be used by the validation or build teams. once that is done, we can do all sorts of testing based on it, regression testing for myself when merging stuff into arm-soc.git, continuous testing, gcc testing .. I actually found 4 gcc bugs already using randconfig builds (gcc-4.7 beta)
  • npitre:
    • been working on the DTB append patch set lately
    • before that I sent RMK a pull request for a huge series eliminating most instances of mach/memory.h
    • otherwise reviewed the ARM kprobes test code from Tixy
  • perfor
    • mounir, linusw, npitre, nhe: We probably want to fix u-boot (rebase all patches and cleanup) for Snowball but it can't be done within the context of DT-work. perfor: what is your plan for that? I started to rebase the u-boot for snowball but I got interrupted by vacation. I can probably get something that works but wont have time to make it pretty and upstreamable
  • thomas-ab
    • I have submitted device tree support patches for Exynos4 keypad controller driver. I have rebased dt patches for pl330 dma controller driver on top of pl330 driver update patches and tested it.
    • This week, I plan to resubmit dt patches for uart, sdhci, i2c, keypad, pl330 dmac with updates and hope to get it reviewed and merged for 3.2. Also, I plan to prepare a single dt enabled board file for smdkv310 and orgien board., So I will be mainly working on dt support for exynos4 this week.
    • All the dt patches have gone through one or more rounds of review. Most of them have a acked. There are additional modifications for some of the patches like removing dependency on platform data.

Actions

  • Mounir to check for per on the linaro email, how long can he keeps it. There are few patches submitted under his linaro email, he needs to keep up with them.
  • Suggestion for next meeting: after about 5 minutes, when most announced themselves to the meeting, create an ordered list of who will go first, second, next while going around the table. This way, attendees, will have an idea when they will go next and be ready.
  • Shawnguo to ping tglx to comment on his imx6q patches.

Issues

  • Venkat working on eMMC4.5 HPI feature, have an issue that the time to interrupt window is very small for the HPI to be actually exercised. Will discuss it with Arnd, LinusW and Per to resolve.
  • Need to resolve clock framework and common clock device tree binding

IRC Log

<mounir> Hello - anyone here for the Linaro kernel weekly meeting?
* joey (~joey@75.145.125.61) has joined #linaro-kernel
* joey has quit (Changing host)
* joey (~joey@linaro/pdpc.professional.joey) has joined #linaro-kernel
<dmart> hi there
<mounir> Hi Dave
<nhe> hi
<mounir> Deepak cannot attend today, I will run the meeting on his behalf
<mounir> Hi Niklas
<mounir> https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-09-12
<perfor> Hi mounir
<mounir> Hi Per
<mounir> let us wait few mote minuted, before we start.
<linusw> Hi
<mounir> Hi Linus
<mounir> I have put few announcement/reminders in the agenda, will start with that then go around the table as usual
<shawnguo> hello everyone
<mounir> it is 5 after, let us go ahead and start
<mounir> Hi Shawn
<shawnguo> Hi mounir
<mounir> first annoucement/reminder - Q4.2011 planning and initial schedule has started, I have placed the link in the meeting
<mounir>  https://wiki.linaro.org/Internal/Events/LinaroConnectQ4.11/Planning#Summits_and_Tracks
<mounir> Second announcement, Kiko has started to collect requirement for Q4.2011 if you have a suggestion and/or want to see something worked on in the next cycle, please reply to Kiko's note for everyone to see
<mounir> https://docs.google.com/present/edit?id=0AVOqOgJxyLZOZGZnOXFuZGRfMGZycnY0OWRm&hl=en_US
<mounir> Third reminder: register as soon as you can for the Orlando connect
* svenkatr (~svenkatr@nat/ti/x-shoiqzcuphidvgoz) has left #linaro-kernel
<mounir> If you want a visa  you should be addressing it by now
* svenkatr (~svenkatr@nat/ti/x-shoiqzcuphidvgoz) has joined #linaro-kernel
<mounir> another announcement - For monthly planning, we ae being asked ( where it make sense) to provide a Header for the blueprints that will be delivered this month. So, I am going to review what we have planned to delivered this month and ask owners to provide the headers to be used in the release announcement
<mounir> finally, next Thursday 9/22/2011, is our release freeze. right after that we will go trhough another monthly planning exercise like we did this month
<mounir> that is all from my side on announcement/reminders
<mounir> any other topic  from anyone, you like to announce with the team?
<mounir> anyone has gone to Linux Plumbers and like to share some info back to the team?
<perfor> I can announce that I am leaving Linaro after this week.
<mounir> per - again we are sorry to see you leave, good luck with your new assignments
<mounir> per - keep in touch somehow
<perfor> thanks mounir, I hope to stay in contact with Linaro in the future as well.
<mounir> perfor:  yes please do.
<perfor> I also hope to keep my Linaro email for some time.
<perfor> All my commits upstream refers to this email.
<mounir> perfor: ok, I will check on this, I don't think it is a problem keeping the email, I will check on that to be sure
<mounir> let us go over the accomplishments, plans, issues, etc...
<perfor> Thanks mounir.
<mounir> svenkatr, would you like to start
<mounir> perfor:yw
<svenkatr> mounir: I am working on eMMC4.5 HPI feature.
<mounir> svenkatr, does this relates to any Work Items in the blueprints?
<svenkatr> I have an issue that the time to interrupt window is very small for the HPI to be actually exercised
<svenkatr> yes.
<mounir> svenkatr, are you discussing this issue with anyone? Do you think the feature still make sense to work on? 
<svenkatr> I was discussing this with Kyungmin Park. It is still required to be worked on
<svenkatr> https://blueprints.launchpad.net/linux-linaro/+spec/utilize-emmc-hpi-to-minimze-flash-latency
<perfor> svenkatr: could you clarify? For large write wouldn't it make sense to use HPI to make way for a read
<perfor> or is the window still too small
<svenkatr> perfor: yes
<svenkatr> HPI command can only be sent in 'programming state' of the card
<arnd> I thought hpi was mainly interesting in combination with the 'garbage collection' ioctl, I forgot what that's called im mmc terms
<linusw> arnd: BKOPS?
<arnd> right
<perfor> HPI can be used to interrupt BKOPS.
<svenkatr> HPI is not garbage collection. It's a preemption of an ongoing write to make way for a read
<svenkatr> yes. Can also be used to interrupt BKOPS, but mostly the interest is on preemption
<arnd> ok
<arnd> I guess a simple write can also take on the order of hundreds of miliseconds if things go wrong
<arnd> svenkatr: if you want to enforce worse-case behavior, you could run 'flashbench --open-au-nr=100' on one partition while reading from another partition
<arnd> in that case, every write that flashbench does will take the maximum time, usually around 500ms
<svenkatr> arnd, perfor: In OMAP case, while the dma is programmed to write out each element in the sg_list, I think the card starts to write the data out, which results in a shrinking 'programming state'
<svenkatr> When HPI is sent out, I get an invalid command or command error
<arnd> svenkatr: but the card might need to do a GC in order to write, if you have exceeded the number of open erase blocks and did not do a BKOPS
<svenkatr> On the card I have, BKOPS is not supported, only HPI
<arnd> right, but that just makes it more likely to require a GC, since it is never triggered by user space
<svenkatr> yes. But can I forward guess a need for GC ? The MMC spec is very tight about the timing of sending HPI
<arnd> svenkatr: as I said: if you run 'flashbench --open-au-nr=100' on one partition, it will require GC with every write
<svenkatr> ok
<arnd> don't run it on a partition that you still need though, it overwrites your data
<mounir> svenkatr, arnd seems to have some ideas, please work with him to try things out. 
<arnd> (you probably know that, but I've had a few complaints recently from people who didn't)
<mounir> svenkatr,  for house keeping, please update the WI as INPROGRESS  if you have not done so already
<svenkatr> arnd: ok
<svenkatr> mounir: I have updated it
<mounir> svenkatr, great - thank you.
<svenkatr> anrd: I will message you on IM offline
<mounir> nhe: would you like to go next?
<perfor> There are patches on the mmc-list implementing HPI together with BKOPS. One patchset from Intel and another refactored version from ST-Ericsson. We use those patches internally.
<nhe> Snowball device tree work in short: Working with Linus, still do not know if we are going to use appended device tree to zImage or u-boot. Problems either way.
<perfor> I have not verified them my self though
<nhe> And I need to know this before I can update the blueprints in a meaningful way.
<svenkatr> perfor: Can you send a link ?
<linusw> I can just as well state something on the DT work in this context...
<nhe> next...
<mounir> nhe: do you think by this week you would know?
<linusw> I tested appended device tree on U8500 and ARM RealView PB1176 and existing patches did not work on either
<linusw> Nor was it easily fixable AFAICT, I have informed nico about the issue.
<mounir> linusw: should grant be involved as well?
<perfor> svenkatr: http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg08931.html
<nhe> mounir: I sincerely hope so, but no promise.
<linusw> mounir: depends, the appended device tree work is Nicos work
<linusw> If we can't get appended trees to work, we need to fix U-boot instead
<mounir> nhe: linusw: ok thank you
<npitre> linusw: those patches did work for sure at some point
<linusw> npitre: yeah :-/
<perfor> going away, back in 5 minutes.
<npitre> linusw: but if you can fix your uboot then all the better
<svenkatr> perfor: I've seen this patch. This uses HPI only for BKOPS and not for write preemption
<linusw> npitre: the problem is that our internal U-Boot for this platform is way out of sync with mainline from a 2009 snapshot
<linusw> npitre: so it will be some weeks/months of mainlining U-boot work instead of working with device tree for U8500
<npitre> linusw: I want to submit those patches upstream this week so they will work again  ;-)
<linusw> npitre: expect me & Niklas to be ready to test them at high pace
<npitre> linusw:  good
<mounir> linusw: since you have the floor - would like to go next?
<linusw> npitre: right now even CONFIG_USE_OF causes my kernel to freeze on 3.1-rc4 so there is some other nasty DT regression AFAICT
<linusw> mounir: sure
<linusw> mainly been doing DT investigations last week and some minor patches to keep sanity
<linusw> this week I need to focus on the pinmux core again
<npitre> linusw: if you could pursue this independently that woule be good
<linusw> npitre: I can dive into it after next pin control/pinmux iteration
<linusw> npitre: it will likely need som JTAG:ing since I don't even get early prints
<mounir> linusw:  I saw you are on v7 for pinmux, this seems real complicated
<linusw> mounir: to cut a long story short, nVidia have very complex requirements on the subsystems
<linusw> mounir: and pretty much noone else is providing any feedback so I have to satisfy them
<npitre> linusw: would it make sense to leave them out as a special case if their requirements are too odd?
<linusw> npitre: I'm on the verge of fixing it so think it makes sense to make a try
<linusw> mounir: that's it for me...
<mounir> linusw: thank you
<mounir> shawnguo, next?
<shawnguo> mounir:
<shawnguo> ok
<shawnguo> I posted the first version of imx6q patch series
<shawnguo> Arnd criticized the clock code for not using device tree for probing the clock data.
<perfor> svenktr: I thought there was an issue to use HPI to interrupt BKOPS as well.
<shawnguo> However, this can only be done when the clock framework and common clock device tree binding are available, and unfortunately these two things are still up in the air without a specified time for being ready.
<shawnguo> I really do not see the possibility that these two things will hit mainline in v3.2
<mounir> shawnguo, will this be a needed requirement fro next cycle, or it may be solved before then?
<shawnguo> while I'm hoping imx6q can go into v3.2
<arnd> I hope we can find a way out on the meeting this wednesday, if it continues to look bad for the clock framework to go in, I'll take your patches
<perfor> svenkatr: Does this patch make sure the HPI is only sent during "programming state". This is the tricky part with HPI preemption right?
<shawnguo> arnd, that's great
<arnd> I really want to have people who know about the state of the clock framework to comment on your patch
<shawnguo> let's see what we get on wednesday, thanks
<mounir> shawnguo, maybe we need to start collecting DT requirements to give to grant so he can plan for next cycle DT work
<svenkatr> perfor: No. Actually this patch probably meets 10% of the HPI feature requirements (in it's true spirit)
<arnd> if tglx and gcl want to have the imx6q stuff go in as is, I definitely won't complain about the missing binding for now
<shawnguo> mounir: I believe gcl knows about the clock requirement pretty well
<arnd> not sure how many other platforms we can take that way, there are quite a few lined up, and I think most of them are blocked on the clock stuff
* mansson (~tony@static-213-115-104-186.sme.bredbandsbolaget.se) has joined #linaro-kernel
<mounir> shawnguo, ok  then, anything else from your side?
<linusw> we had this struct clk meeting last friday BTW
<linusw> people attended from Plumbers and by phone
<shawnguo> arnd: should I ping tglx to comment?  You cc-ed him on the thread, but he said nothing there so far
<arnd> shawnguo: yes, that would be good
<svenkatr> perfor: HPI can be used to stop (a) an ongoing BKOPS or (b) an ongoing write (multiblock write transfer). This patch does (a) only
<shawnguo> arnd: ok, will do
<linusw> regarding struct clk the way forward is to look at the patch set as-is and decide for a way forward this week
<arnd> is tglx the one working on it the clock framework right now, or is there someone else?
<linusw> arnd: he says he will write a proposal skeleton this week
<arnd> ok, good
<mounir> arnd: linusw:shawnguo: looks like an important thing to follow up on
<linusw> arnd: in the meeting lots of people wanted to merge the struct clk patches that make possible a single kernel today
<arnd> mounir: yes, definitely
<mounir> dmart, would like to go next?
<linusw> arnd: Thomas NACK:ed and said that we need and infrastructure core for it as well, not just making several implemenations live in parallell
<dmart> mounir: sure
<linusw> arnd: so he's reportedly ventured into sketching an outline of that
<perfor> svenkatr: I need to read up on the mmc states. You mentioned that HPI can only be sent during "programming states". When interrupt BKOPS will you by deafault always hit a programming state?
<dmart> I have been continuing with the vexpress device tree work and some miscellaneous Thumb-2 issues reported by Arnd
<dmart> On vexpress DT, I have some input from other ARM guys which I need to integrate -- this has slowed things down a bit, but it should give a reasonable level of initial support
<dmart> My aim is to post patches this week
<mounir> dmart: is this work related to WI by posting this week, you may be able to complete some of the Work items?
<svenkatr> perfor: BKOPS doesn't have that restriction. By definition, interrupting a BKOPS means there are no transactions ongoing with the card and it is interruptible. The programming state is an internal card state which occurs during writes only
* kapare has quit (Ping timeout: 276 seconds)
<dmart> mounir: I've redrafted the work items on https://blueprints.launchpad.net/linux-linaro/+spec/kernel-versatile-boad-description-and-implementation to reflect the work I'm doing
<perfor> svenkatr: I see. Thanks for explaining.
<dmart> mounir: a few should be completed this week if I get as far as posting patches
<mounir> dmart: yes thank you for that
<mounir> dmart: anything else?
<mounir> arnd: next?
<dmart> I've also started the (delayed) Thumb-2 kernel migration write-up.  I'll post something for people to look at soon -- hopefully this week
<arnd> I pulled patches from various soc maintainers, after finally moving the tree over to git.linaro.org (temporary while git.kernel.org is down).
<dmart> arnd, npitre: would you guys be available after this meeting for a quick chat about the Thumb-2 randconfig issues?
<arnd> Sending pull request for bug fixes right now.
<arnd> dmart: yes, no problem
<arnd> I've also spend a lot of time last week on randconfig fixes mentioned by dmart, got 10 platforms to build 97% of time and still need to send out ~150 patches for this to the respective maintainers.
<mounir> dmart: thanks
<arnd> Published a short article on lwn.net about the upcoming architectures we discussed here (hexagon and c64x). -> http://lwn.net/Articles/455342/
<mounir> arnd: will the randconfig eventually be used by the validation or build teams?
<arnd> http://lwn.net/Articles/457635/ I mean
<arnd> mounir: yes, that is part of the plan
<linusw> arnd: very interesting article, thanks for that
<arnd> right now, getting randconfig to build at all is a major effort
<arnd> once that is done, we can do all sorts of testing based on it
<arnd> - regression testing for myself when merging stuff into arm-soc.git
<mounir> arnd: yes - it is a worthy cause
<arnd> - continuous testing in the validation team on linux-next
<mounir> npitre: next?
<arnd> - gcc testing
<arnd> I actually found 4 gcc bugs already using randconfig builds (gcc-4.7 beta)
<perfor> mounir, linusw, npitre, nhe: We probably want to fix u-boot (rebase all patches and cleanup) for Snowball but it can't be done within the context of DT-work.
<mounir> arnd: this is great stuff, sorry for rushing, we are at the top of the hour
<mounir> perfor: what is your plan for that?
<npitre> been working on the DTB append patch set lately
<npitre> before that I sent RMK a pull request for a huge series eliminating most instances of mach/memory.h
<perfor> mounir: I started to rebase the u-boot for snowball but I got interrupted by vacation. I can probably get something that works but wont have time to make it pretty and upstreamable
<npitre> otherwise reviewed the ARM kprobes test code from Tixy
<mounir> npitre: mach/memory.h another step towards single kernel, right? Is this WI listed in the blueprint?
<npitre> mounir: not sure what level of details the bp has
<npitre> mounir: I've been working on that item on and off for at least the last 6 months
<mounir> npitre: one time we discussed, due to how long this work may take, it would be nice to have a handle on at least what is been done 
<mounir> npitre and what we know now what needs to be done, knowing that we still discovering work as we go along
<linusw> npitre: regarding memory.h I think the mach-u300 memory.h can also be eliminated, but you need the branch that Arnd has merged to -next
<npitre> mounir: I do have a list that I (try to) keep up to date
<npitre> linusw: good, but we'll see to it next cycle
<mounir> npitre should we add your list to the blueprint? we may need it for next cycle planning, to allocate the right time/resources for this work
<linusw> npitre: agreed
<npitre> mounir: I must admit that so far all my estimates for this work have been completely off the mark
<arnd> I got a number of regression from missing hardware.h files, which get included from drivers etc
<npitre> mounir: problem is that putting more resources won't make it much faster as the review cycle has to go its course, etc.
<mounir> npitre: it is understandeable, but I bet know your planning will be more accurate as you know more now
<npitre> arnd: those drivers need fixing
<arnd> npitre: sure, I've got patches for all of those I found
<npitre> mounir: maybe
<mounir> anyone else on the meeting? I have missed?
<thomas-ab> mounir: I am in the meeting. Can I do next?
<mounir> thomas-ab, yes please 
<thomas-ab> mounir: thanks.
<thomas-ab> Last week, I have submitted device tree support patches for Exynos4 keypad controller driver. I have rebased dt patches for pl330 dma controller driver on top of pl330 driver update patches and tested it.
<thomas-ab> This week, I plan to resubmit dt patches for uart, sdhci, i2c, keypad, pl330 dmac with updates and hope to get it reviewed and merged for 3.2. Also, I plan to prepare a single dt enabled board file for smdkv310 and orgien board.
<thomas-ab> mounir: So I will be mainly working on dt support for exynos4 this week.
<mounir> thomas-ab, have these patches been accepted upstream yet, or it is too early to know?
<thomas-ab> mounir: All the dt patches have gone through one or more rounds of review. Most of them have a acked. There are additional modifications for some of the patches like removing dependency on platform data.
<mounir> thomas-ab, another thing, I don think all of the DT work is reflected correctly on blueprints and Wor items. I have mentioned this to Deepak and he may want to clean this up with Grant to know what we still have to do, and what may spill to next cycle
<mounir> thomas-ab, ok good
<thomas-ab> mounir: So, I hope these patches will get accepted and merged.
<thomas-ab> mounir: ok. thanks.
<mounir> thomas-ab, very good - good stuff
<mounir> my last statement: Whenever you complete something, please let be reflected in your Work items, mark the corresponding Work Item on Launchpad complete
<mounir> that is all from me, any other topic?  - final call 
<dmart> mounir: a thought about this meeting -- in some other groups' IRC meetings, the order in which people give round-table updates is proposed at the start of the meeting.  This seemed to work quite well -- people know roughly how many people the time is shared between, and know when they should be ready with their input.  It could be interesting to try that for this meeting?
<dmart> I find it a bit hard to know when to speak up...
<mounir> dmart agreed: in the other meetings do they know ahead of time who will be attending? or they just take names as they announce the attendees announce themselves?
<dmart> I think they just waited 5 mins or so for everyone to arrive, and made the list from those present
<dmart> The list of attendes from the previous week is a good first approximation, too
<mounir> dmart: we can certainly try it. 
<mounir> I'll add it to the minutes, so we can start next meeting
* svenkatr has quit (Quit: Leaving.)
* ssvb (~ssvb@a88-114-220-213.elisa-laajakaista.fi) has joined #linaro-kernel
<dmart> ok -- no need to pursue if it turns out not to be useful
<mounir> dmart: one time I got a fortune cookie that said: You will never going to loose more than if you don't try. So we will try it :)
<dmart> :)
<mounir> #endmeeting 

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