Attendees

  • David Rusling (Linaro)
  • Kiko (Linaro)
  • Sree K. (Samsung)
  • Roger T. (ARM)
  • Yves V. (Freescale)
  • Andrea G. (ST-Ericsson)

Guest Participants

  • Deepax Saxena (Linaro)

Information

Agenda

  • Kernel Focus Topic: Consolidation, linux-linaro, device-trees
  • Action Review
  • License Requests
  • Update on hard-float and Genesi video
  • TSC Call Protocol
    • Changing TSC dial-in

Minutes

  • Kernel Focus Topic
    • Kiko: what value do members get out of the Linaro Kernel WG
      • Deepak: kernel consolidation, fundamentally.
        • Driving ARM SoC tree maintenence
        • Helping vendors get their patches in shape for upstreaming
        • Doing work on a single kernel binary; today we need build-time configuration to even boot on multiple platforms and SoCs

        • Device tree work upstream; once this is done, solve difficulties in new board ports which historically have been done by copying-and-changing code from other SoCs.

      • Sree: what about work happening in u-boot
        • Deepak: KWG not focusing on u-boot, but John Rigby (Platform) has been doing work on it
        • Deepak: U-Boot changes to support supplying DTB to Kernel are pretty simple
          • Not sure about work to actually use DTB for U-Boot
          • ACTION: research whether what this work entails and where it stands
      • Kiko: what benefit would u-boot DTB support provide?
        • Deepak: would allow single u-boot source running on multiple boards
          • Probably not a single binary, but would minimize the amount of variation
          • Would require drivers to be aware of the DTB; scanning DTB for boot devices on the board, for instance
      • Vijay: are there platforms that have been fully converted over to DT from a board file
        • Deepak: platforms are in progress, but none complete
      • Vijay: once the board files are converted, do we move remaining SoC data across to DT
        • Deepak: good question. The plan of record is to convert SoC configuration across, including power domain, but it remains as a research topic
          • Being discussed with Paul and Kevin (TI); part of the issue is that some of the data isn't clearly hierarchical and may not be easily modeled as a tree
      • Kiko: there was concern about the size of the device-tree if it describes the entire SoC; is this a valid concern?
        • Deepak: probably a valid concern, need to discuss this further with Grant; may be able to dump portions of the DT
        • ACTION: Will do some research and contact TSC with findings
      • Vijay: on the consolidation front, are there plans to look at other areas: GPIOs, timers and other generic drivers
        • Deepak: definitely. Kernel consolidation has many aspects: single zImage, DT, and driver cleanup/consolidation.
          • First step in driver consolidation: moving everything into drivers/
          • Have been quite a few patches since Linaro@UDS moving drivers out of arch/arm and into drivers/
          • Next step is looking at similar drivers in the same directory and evaluating candidates for merging
      • Vijay: work going on in linux-omap to move GPIO drivers out of arch/arm; beyond that Linaro could start looking at other GPIO drivers
      • Yves: from Freescale's perspective, one of the most important things is seeing the WG output going upstream. Freescale now sees two sources for the kernel; one being Linaro and one being kernel.org; there is only one possible source that they can manage, and that should be kernel.org
        • Deepak: completely focused on upstream work; goal of the linaro kernel tree itself is just to serve as a demonstration of what's going upstream -- a type of arm-next tree. If you look at 3.0 cycle, apart from ARM-specific changes, there were also large infrastructure changes that would cause instability. The Linaro kernel would provide you with a 2.6.39 tree with all the current ARM-specific changes without the bleeding edge instability
          • Good question, because it does create extra work for us -- if it isn't valuable, then we should reconsider doing it.
          • One issue with linux-linaro is that not a lot of patches are flowing directly into linux-linaro; part of the issue is the focus on Android and Ubuntu kernel specifics, which make them less applicable to linux-linaro.
          • If having a single tree is simpler, then just working against upstream might be helpful
        • Kiko: one issue is how do we get access to consolidated infrastructure before it goes upstream
        • Sree: use the tree for experimental work, but not for shipping products
          • Use the tree for verification of Device Tree work, and memory management patches; using it to prove that this functionality works
        • Yves: even after the Linaro release, do you still see the tree as experimental?
          • Sree: yes, because commercial development is always based on kernel.org
        • Deepak: good point; could definitely change the tree's messaging to provide an infrastructure consolidation point
      • Vijay: is there a communication gap between the Kernel WG versus the kernel community?
        • Device Tree is an example; many people in the community are curious about device tree work upstream
        • Work should involve upstream communities from day zero
        • Deepak: in terms of patches being generated, all patches are being sent upstream
          • Storage patches to MMC and block ML, Device Tree is being submitted to the Linux ARM ML
          • Issue is probably more a lack of clarity in direction rather than patches
        • Manjunath DT work example: he is posting this to device-tree work, but isn't cross-posting to omap-kernel lists
        • Deepak: definitely want to ensure that patches are cross-posted
        • Deepak: one idea is to make status reports available more widely, so others can look at what we're doing
      • Kiko: do vendors go and divulge our plans to their own developer communities?
      • Roger: trying to get a picture to describe how the KWG work flows into LEBs and upstream
      • David: so point is how do we get the different communities well-involved
        • Need help from the vendors to kick-start that
        • Kiko: apart from linux-omap, are there other communities we need to reach out to?
          • Sree: okay with current set of lists
          • Roger: okay with linaro-dev and linaro-kernel
          • Yves: do have imxcommunity, but only internel kernel mailing lists
          • Andrea: have two mailing lists, Linaro assignees are already sharing internally
      • Closing comments
        • Deepak: curious about Roger's question -- the concern seems to be about having a way to message in a high level about benefits the Linaro Kernel WG brings to ARM and its partners?
          • Roger: in simple terms, how do the trees work -- do we have a staging tree? Do LTs pull from a maintainer tree? How does this go into the LEBs?
          • ACTION: Should document purpose of tree better, and draw up how communication with LTs and LEBs should work
  • Hard-float work
    • Andrea: have seen Youtube video and Android improvements, want to know more about this work and results
    • David: in OCTO, Steve M. working on cross-building/bootstrapping hard-float and Konstantinos working on hard-float porting
      • https://wiki.linaro.org/OfficeofCTO/HardFloat

      • Recent Nokia phone hard-float; Fedora, Debian and Ubuntu interested
      • Outputs are "it works", and benchmarking
      • Startling result: recursive FP calls end up being 300% faster (because you avoid the swapping overhead)
      • Overall performance is probably 5%, but for specific cases there's a definite benefit
      • Would like to persuade Android to consider moving, but need Android's support in it
  • Andrea: separately, Mats M. (ST-Ericsson) has suggested sharing with Linaro a Kernel that runs under secure mode (non-Linux-specific); are considering releasing this under and open source license. Andrea: typically used where you have algorithms that use secure certificates; for instance, DRM or PPV authorization code.
  • License Requests
    • John Stultz would like to push changes into AOSP
    • Android is under Apache Software License 2.0
      • Not pre-approved, so requires TSC approval
      • Will do through e-mail
      • ACTION: David to resolve license approval on TSC list
    • Wants permission to contribute under the AOSP CLA
    • Two parts to this agreement:
      • Code written inside Linaro; this should be fine for us, and we should sign
      • Code written by third parties; not sure about this since it has IP leakage risks
        • Operational concern: will the engineers know that their work is being CLA'd off to AOSP, in particular if that code comes from a LT
        • ACTION: David to raise with John what code is being submitted now
  • Call protocol
    • Changes to the conference call system used for the TSC
      • Andrea: would like this to work from mobile phones
        • ACTION: Kiko to provide TSC with a list of dial-ins so you can test before we confirm the change
    • Can we dial in 5 minutes early?
      • Yves: mostly yes, though when it does happen that we have a call before it may be hard
    • Vijay: has moved to Bangalore this week, could we move the call down a bit
      • ACTION: Kiko to email to check time change

TSC/2011-06-29 (last modified 2011-06-29 16:22:57)