diff options
Diffstat (limited to 'index.txt')
| -rw-r--r-- | index.txt | 132 |
1 files changed, 128 insertions, 4 deletions
@@ -47,9 +47,9 @@ TOPICS: - Linux News - Slides ^^^^^^ +- Linux Kernel Device - Dateisysteme - Flash Devices - UBI @@ -75,14 +75,24 @@ Board Bringup - LWN - summary: ============== 13.04.2012: ^^^^^^^^^^^ -3.4-rc2 +More than eight years after the 2.6.0 release, Willy Tarreau has announced that +he will no longer be releasing updates to the 2.4 series. +For those who really are unable to move on, he may maintain a git tree with an +occasional fix, "but with no guarantees." + +Development of SCHED_DEADLINE returns + - it's a new scheduling policy like SCHED_FIFO + - kernel git repo: https://github.com/jlelli/sched-deadline + - example application: https://github.com/gbagnoli/rt-app + - Mailinglist: http://feanor.sssup.it/mailman/listinfo/linux-dl + +3.4-rc2 (released on April, 7th) ^^^^^^^ - The x32 system call ABI @@ -91,11 +101,125 @@ LWN - summary: - printk: support structured and multi-facility log messages (lwn.net/Articles/490690/) +- The Common Clk Framework (see drivers/clk/clk-*.c for examples) + - Introduce a led trigger for CPU activity and consolidate LED driver in ARM (lwn.net/Articles/489612/) -- The Common Clk Framework (see drivers/clk/clk-*.c for examples) +<< INSERT SLIDES ABOUT struct device >> + +- Reworking the DMA mapping code Patchset + * merge ARM DMA API in generic DMA code + * remove duplicated code + * remove special alloc/mapping functions for writecombine, (non)coherent + * use flags in dma_(alloc/mapping) for writecombine, (non)coherent + + * now each architecture can implement the following functions: + +include/linux/dma-mapping.h (very simplified pseudo code): + + struct dma_map_ops { + vaddr = alloc(dev, size, &paddr, attr) + free(dev, size, vaddr, paddr, attr) + vaddr = mmap(dev, paddr, attr) + sync_for_cpu (dev, paddr) + sync_for_device (dev, vaddr) + ... + yes/no = dma_supported(dev) + }; + + e.g. arm does this in arch/arm/common/dmabounce.c + + * add per-device i/o mmu support to (ARM) DMA API: + + Some hardware has a separate IOMMU built into it that cannot be used + for other devices, so the IOMMU cannot be made available to the system + as a whole. + + But it is possible to attach a device-specific dma_map_ops structure + to such devices that would cause the DMA API to use the IOMMU without + the device driver even needing to know about it. + +arch/arm/include/asm/dma-iommu.h: + + struct dma_iommu_mapping { + /* iommu specific data */ + struct iommu_domain *domain; + + void *bitmap; + size_t bits; + unsigned int order; + dma_addr_t base; + + spinlock_t lock; + struct kref kref; + }; + + struct dma_iommu_mapping *arm_iommu_create_mapping(dma_addr_t base, + size_t size, int order); + + void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping); + + int arm_iommu_attach_device(struct device *dev, + struct dma_iommu_mapping *mapping); + (implementation see below) + +arch/arm/mm/dma-mapping.c: + + struct dma_map_ops iommu_ops = { + .alloc = arm_iommu_alloc_attrs, + .free = arm_iommu_free_attrs, + .mmap = arm_iommu_mmap_attrs, + + .map_page = arm_iommu_map_page, + .unmap_page = arm_iommu_unmap_page, + .sync_single_for_cpu = arm_iommu_sync_single_for_cpu, + .sync_single_for_device = arm_iommu_sync_single_for_device, + + .map_sg = arm_iommu_map_sg, + .unmap_sg = arm_iommu_unmap_sg, + .sync_sg_for_cpu = arm_iommu_sync_sg_for_cpu, + .sync_sg_for_device = arm_iommu_sync_sg_for_device, + }; + + int arm_iommu_attach_device(struct device *dev, + struct dma_iommu_mapping *mapping) + { + int err; + + err = iommu_attach_device(mapping->domain, dev); + if (err) + return err; + + kref_get(&mapping->kref); + dev->archdata.mapping = mapping; + set_dma_ops(dev, &iommu_ops); + + printk(KERN_INFO "Attached IOMMU controller to %s device.\n", + dev_name(dev)); + + return 0; + } + + + Prior to this work, IOMMU awareness had been built into specific drivers + directly. + + +Status of Android merge: +^^^^^^^^^^^^^^^^^^^^^^^^ +Grant Likely asked about the progress of the Android patches into the mainline; +when is that job "done"? + +Once Android is using mainline kernels was the answer Bottomley gave. + +Kroah-Hartman noted that the real problem is on the user-space side. +Kernel hackers can't do anything about changing the Android user space, +but companies like Linaro and Samsung are making some progress in doing so. +The 3.3 kernel can boot an Android user space, but it will +"eat your battery alive", +he said. We are making progress, but it will require teamwork to get there. Plumbers: ^^^^^^^^^ |