Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Nov 20, 2011
  1. tools: user space app demo for using rpmsg sockets

    authored
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
  2. rpmsg sockets

    authored
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Commits on Nov 10, 2011
  1. ARM: OMAP3: support a phony omap3isp device

    authored
    This is non-upstream stuff.
    
    Only required to test omap3isp IOMMU functionality.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
  2. tools: /dev/rpmsg-omx demo app

    authored
    *** I'm carrying it here so it doesn't get lost, but this sample
    *** probably needs to be refreshed (and moved to samples/...)
    
    This is a user space application that demonstrates usage
    of the /dev/rpmsg-omx device.
    
    The app creates a remote OMX instance, and once connection
    is established, it starts ping-ponging raw messages with that new OMX
    instance (note: currently a generic "OMX" name is used while connecting.
    this can be changed to a specific OMX instance name, such as
    "h264_decode", when we implement the entire GetHandle function within
    the context of the connect ioctl).
    
    We don't really invoke meaningful OMX remote API yet, but this
    should be enough infrastructure to start doing real OMX work on both sides
    (A9 and Ducati).
    
    Btw I'm using eventfd(2), which I'm not sure bionic supports. Anyway it
    can be trivially replaced by pipe(2).
    
    Designed with Brian Swetland <swetland@google.com>.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
  3. amp/rpmsg: add OMX driver

    authored
    *** I'm carrying it here so it doesn't get lost, but this driver needs
    *** to be refreshed
    
    Add an rpmsg OMX driver, which enables user space to offload
    cpu-intensive multimedia tasks to OMX instances running on remote
    processors.
    
    The current driver is a raw skeleton: it supports connecting to (and by
    that, creating) remote OMX instances, and sending and receiving raw
    messages from them, but there's no OMX API knowledge yet, no buffer
    management, and no per-connection resource tracking and cleaning up.
    
    The goal of this driver is to demonstrate rpmsg usage and the life
    cycle (and usage) of local/remote rpmsg addresses while allowing
    creation of, and connection to multiple remote OMX instances, while
    only enabling a strict point-to-point communications between user space
    and those OMX components.
    
    Designed with Brian Swetland <swetland@google.com>.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
  4. amp/rpmsg: add server sample

    authored
    *** I'm carrying this around so it won't get lost, but this sample
    *** doesn't work for now as I've dropped the static channels support
    *** (that's why it's not in the samples folder, too).
    
    There's some resource table groundwork to do for the static channels
    to return, so this sample will be revised later when that happens.
    
    Designed with Brian Swetland <swetland@google.com>.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
  5. samples/amp: add an rpmsg driver sample

    authored
    Add an rpmsg driver sample, which demonstrates how to communicate with
    an AMP-configured remote processor over the rpmsg bus.
    
    The driver repeatedly sends a "Hello World!" message to the remote
    processor.
    
    Note that once probed, the driver can immediately start sending messages
    using the rpmsg_send() API, without having to worry about creating endpoints
    or allocating rpmsg addresses: all that work is done by the rpmsg bus,
    and the required information is already embedded in the rpmsg channel
    that the driver is probed with.
    
    Designed with Brian Swetland <swetland@google.com>.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: Brian Swetland <swetland@google.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Cc: Tony Lindgren <tony@atomide.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Greg KH <greg@kroah.com>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
  6. amp/rpmsg: add virtio-based remote processor messaging bus

    authored
    Add a virtio-based inter-processor communication bus, which enables
    kernel drivers to communicate with entities, running on remote
    processors, over shared memory using a simple messaging protocol.
    
    Every pair of AMP processors share two vrings, which are used to send
    and receive the messages over shared memory.
    
    The header of every message sent on the rpmsg bus contains src and dst
    addresses, which make it possible to multiplex several rpmsg channels on
    the same vring.
    
    Every rpmsg channel is a device on this bus. When a channel is added,
    and an appropriate rpmsg driver is found and probed, it is also assigned
    a local rpmsg address, which is then bound to the driver's callback.
    
    When inbound messages carry the local address of a bound driver,
    its callback is invoked by the bus.
    
    This patch provides a kernel interface only; user space interfaces
    will be later exposed by kernel users of this rpmsg bus.
    
    Designed with Brian Swetland <swetland@google.com>.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: Brian Swetland <swetland@google.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Cc: Tony Lindgren <tony@atomide.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Greg KH <greg@kroah.com>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
  7. ARM: OMAP: add amp/remoteproc devices

    authored
    Add an omap-rproc device with which one can start using OMAP4's
    dual-M3 "Ducati" ipu subsystem.
    
    Currently we're adding support only for the first M3 core (hence
    the name "ipu_c0"); support for the second M3 core, as well as for
    the DSP subsystem, will be added later on.
    
    Bind this device to its dedicated IOMMU device, and assign it a
    dedicated mailbox instance too.
    
    In addition, reserve it a physically contiguous memory region using
    the upcoming CMA mechanism (this makes this patch impossible to merge
    at this point, but this patch only).
    
    This patch also depends on:
    - https://lkml.org/lkml/2011/9/25/44
    - http://www.spinics.net/lists/linux-omap/msg59342.html
    
    Note: at this point we're using a fixed CMA base address (as defined by
    OMAP_RPROC_CMA_BASE), but this will go away once the generic iommu-based
    DMA API will materialize, because at that point we will (almost) not care about
    the physical location of the CMA memory.
    
    Based on (but now quite far from) work done by Fernando Guzman Lugo
    <fernando.lugo@ti.com>.
    
    Designed with Brian Swetland <swetland@google.com>.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: Brian Swetland <swetland@google.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Cc: Tony Lindgren <tony@atomide.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Greg KH <greg@kroah.com>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
  8. amp/omap: add a remoteproc driver

    authored
    Add a remoteproc driver for OMAP4, so we can boot the dual-M3 "Ducati"
    and DSP subsystems.
    
    Use the omap_device_* API to control the hardware state, and utilize
    the OMAP mailbox to interrupt the remote processor when a new message
    is pending (the mailbox payload is used to tell it which virtqueue was
    the message placed in).
    
    Conversely, when an inbound mailbox message arrives, tell the remoteproc
    core which virtqueue is triggered.
    
    Later we will also use the mailbox payload to signal omap-specific
    events like remote crashes (which will be used to trigger remoteproc
    recovery) and power management transitions. At that point we will also
    extend the remoteproc core to support this.
    
    Based on (but now quite far from) work done by Fernando Guzman Lugo
    <fernando.lugo@ti.com> and Hari Kanigeri <h-kanigeri2@ti.com>.
    
    Designed with Brian Swetland <swetland@google.com>.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: Brian Swetland <swetland@google.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Cc: Tony Lindgren <tony@atomide.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Greg KH <greg@kroah.com>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
  9. amp/remoteproc: create rpmsg virtio device

    authored
    Create an rpmsg virtio device to allow message-based communication
    with the remote processor (but only if supported by its firmware).
    
    There are several advantages to provide this functionality at
    the remoteproc-level:
    - to support it, platforms only have to provide their own ->kick()
      handler; no need to duplicate the rest of the code.
    - the virtio device is created only when the remote processor is
      registered and ready to go. No need to depend on initcall magic.
      moreover, we only add the virtio device if the firmware really
      supports it, and only after we know the supported virtio device features.
    - correct device model hierarchy can be set, and that is useful
      for natural power management and DMA API behavior.
    - when the remote processor crashes (or removed) we only need
      to remove the virtio device, and the driver core will take care of
      the rest. No need to implement any out-of-bound notifiers.
    - we can now easily bind the virtio device to its rproc handle, and
      this way we don't need any name-based remoteproc ->get() API.
    
    Currently we only support creating a single rpmsg virtio device per
    remote processor, but later this is going to be extended to support
    creating numerous virtio devices of other types too (block, net,
    console...).
    
    Designed with Brian Swetland <swetland@google.com>.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: Brian Swetland <swetland@google.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Cc: Tony Lindgren <tony@atomide.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Greg KH <greg@kroah.com>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
  10. amp/remoteproc: add debugfs entries

    authored
    Expose several remote processor properties (name, state, trace buffer)
    that are helpful for debugging.
    
    This part is extracted to a separate patch just to keep the review load
    down.
    
    Designed with Brian Swetland <swetland@google.com>.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: Brian Swetland <swetland@google.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Cc: Tony Lindgren <tony@atomide.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Greg KH <greg@kroah.com>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
  11. amp/remoteproc: add framework for controlling remote processors

    authored
    Modern SoCs typically employ a central symmetric multiprocessing (SMP)
    application processor running Linux, with several other asymmetric
    multiprocessing (AMP) heterogeneous processors running different instances
    of operating system, whether Linux or any other flavor of real-time OS.
    
    Booting a remote processor in an AMP configuration typically involves:
    - Loading a firmware which contains the OS image
    - Allocating and providing it required system resources (e.g. memory)
    - Programming an IOMMU (when relevant)
    - Powering on the device
    
    This patch introduces a generic framework that allows drivers to do
    that. In the future, this framework will also include runtime power
    management and error recovery.
    
    Based on (but now quite far from) work done by Fernando Guzman Lugo
    <fernando.lugo@ti.com>.
    
    ELF loader was written by Mark Grosen <mgrosen@ti.com>, based on
    msm's Peripheral Image Loader (PIL) by Stephen Boyd <sboyd@codeaurora.org>.
    
    Designed with Brian Swetland <swetland@google.com>.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: Brian Swetland <swetland@google.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Cc: Tony Lindgren <tony@atomide.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Greg KH <greg@kroah.com>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
  12. iommu/omap: be verbose when omap_iommu_iova_to_phys fails

    authored
    An omap_iommu_iova_to_phys failure usually means that iova wasn't mapped.
    
    When that happens, it's helpful to know the value of iova, so add it
    to the error message.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
  13. iommu/omap: eliminate the public omap_find_iommu_device() method

    authored
    Eliminate the public omap_find_iommu_device() method, and don't
    expect clients to provide the omap_iommu handle anymore.
    
    Instead, OMAP's iommu driver should now utilize dev_archdata's private iommu
    extension to be able to access the required iommu information.
    
    Update omap3isp appropriately.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
    Cc: Tony Lindgren <tony@atomide.com>
  14. ARM: OMAP3: bind omap3isp_device to its iommu device

    authored
    Bind OMAP3's isp device to the isp's dedicated iommu, by setting
    the device's archdata iommu member.
    
    This way omap3isp will be able to use the generic IOMMU API without
    having to call any omap-specific binding method.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: Tony Lindgren <tony@atomide.com>
  15. ARM: OMAP: iommu: declare a private iommu binding struct

    authored
    Declare an omap iommu private struct, which binds an iommu user
    to its iommu device. This struct should be placed at the iommu user's
    dev_archdata so generic IOMMU API can be used without having to
    utilize omap-specific plumbing anymore.
    
    While at it, provide an accessor method to ease the retrieval of the
    omap_iommu handle from a user device.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: Tony Lindgren <tony@atomide.com>
    Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
  16. ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register}

    authored
    Expose omap_device_{alloc, delete, register} so we can use them outside
    of omap_device.c.
    
    This approach allows users, which need to manipulate an archdata member
    of a device before it is registered, to do so. This is also useful
    for users who have their devices created very early so they can be used
    at ->reserve() time to reserve CMA memory.
    
    The immediate use case for this is to set the private iommu archdata
    member, which binds a device to its associated iommu controller.
    This way, generic code will be able to attach omap devices to their
    iommus, without calling any omap-specific API.
    
    With this in hand, we can further clean the existing mainline OMAP iommu
    driver and its mainline users, and focus on generic IOMMU approaches
    for future users (rpmsg/remoteproc and the upcoming generic DMA API).
    
    This patch is still considered an interim solution until DT fully materializes
    for omap; at that point, this functionality will be removed as DT will
    take care of creating the devices and configuring them correctly.
    
    Tested on OMAP4 with a generic rpmsg/remoteproc that doesn't use any
    omap-specific IOMMU API anymore.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
  17. iommu/omap: disable mmu interrupts after the first fault

    Guzman Lugo, Fernando authored committed
  18. omap:iommu-dmm fixes

    Hari Kanigeri authored committed
    This fixes the following:
      1. pgd and pte entries weren't getting flushed out leading to MMU faults.
      2. Cache invalidate was setting wrong size parameter to
         memory_regain_ownership leading cache invalidate function to fail.
    
    Change-Id: I7ab72956325b0de6c58ffa7796c6f8a061793d14
    Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
  19. omap:iommu-added cache flushing operation for L2 cache

    authored
    Change-Id: I6e22cc125daf84a23a9a07d68e696390e64f5c75
    Signed-off-by: Ramesh Gupta <grgupta@ti.com>
    Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
    
    Conflicts:
    
    	arch/arm/plat-omap/iommu.c
  20. iommu/omap: temporary clk_enable workaround

    authored
    will be removed once Omar's iommu hwmod patches will be merged
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
  21. iommu/core: remove the temporary pgsize settings

    authored
    Now that all IOMMU drivers are exporting their supported pgsizes,
    we can remove the default pgsize settings in register_iommu().
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
  22. iommu/intel: announce supported page sizes

    authored
    Let the IOMMU core know we support arbitrary page sizes (as long as
    they're an order of 4KiB).
    
    This way the IOMMU core will retain the existing behavior we're used to;
    it will let us map regions that:
    - their size is an order of 4KiB
    - they are naturally aligned
    
    Note: Intel IOMMU hardware doesn't support arbitrary page sizes,
    but the driver does (it splits arbitrary-sized mappings into
    the pages supported by the hardware).
    
    To make everything simpler for now, though, this patch effectively tells
    the IOMMU core to keep giving this driver the same memory regions it did
    before, so nothing is changed as far as it's concerned.
    
    At this point, the page sizes announced remain static within the IOMMU
    core. To correctly utilize the pgsize-splitting of the IOMMU core by
    this driver, it seems that some core changes should still be done,
    because Intel's IOMMU page size capabilities seem to have the potential
    to be different between different DMA remapping devices.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
  23. iommu/amd: announce supported page sizes

    authored
    Let the IOMMU core know we support arbitrary page sizes (as long as
    they're an order of 4KiB).
    
    This way the IOMMU core will retain the existing behavior we're used to;
    it will let us map regions that:
    - their size is an order of 4KiB
    - they are naturally aligned
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: Joerg Roedel <Joerg.Roedel@amd.com>
  24. iommu/msm: announce supported page sizes

    authored
    Let the IOMMU core know we support 4KiB, 64KiB, 1MiB and 16MiB page sizes.
    
    This way the IOMMU core can split any arbitrary-sized physically
    contiguous regions (that it needs to map) as needed.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Acked-by: David Brown <davidb@codeaurora.org>
    Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
  25. iommu/omap: announce supported page sizes

    authored
    Let the IOMMU core know we support 4KiB, 64KiB, 1MiB and 16MiB page sizes.
    
    This way the IOMMU core can split any arbitrary-sized physically
    contiguous regions (that it needs to map) as needed.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: Hiroshi DOYU <hdoyu@nvidia.com>
  26. iommu/core: split mapping to page sizes as supported by the hardware

    authored
    When mapping a memory region, split it to page sizes as supported
    by the iommu hardware. Always prefer bigger pages, when possible,
    in order to reduce the TLB pressure.
    
    The logic to do that is now added to the IOMMU core, so neither the iommu
    drivers themselves nor users of the IOMMU API have to duplicate it.
    
    This allows a more lenient granularity of mappings; traditionally the
    IOMMU API took 'order' (of a page) as a mapping size, and directly let
    the low level iommu drivers handle the mapping, but now that the IOMMU
    core can split arbitrary memory regions into pages, we can remove this
    limitation, so users don't have to split those regions by themselves.
    
    Currently the supported page sizes are advertised once and they then
    remain static. That works well for OMAP and MSM but it would probably
    not fly well with intel's hardware, where the page size capabilities
    seem to have the potential to be different between several DMA
    remapping devices.
    
    register_iommu() currently sets a default pgsize behavior, so we can convert
    the IOMMU drivers in subsequent patches. After all the drivers
    are converted, the temporary default settings will be removed.
    
    Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
    to deal with bytes instead of page order.
    
    Many thanks to Joerg Roedel <Joerg.Roedel@amd.com> for significant review!
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: David Brown <davidb@codeaurora.org>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Joerg Roedel <Joerg.Roedel@amd.com>
    Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
    Cc: KyongHo Cho <pullip.cho@samsung.com>
    Cc: Hiroshi DOYU <hdoyu@nvidia.com>
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: kvm@vger.kernel.org
  27. iommu/core: stop converting bytes to page order back and forth

    authored
    Express sizes in bytes rather than in page order, to eliminate the
    size->order->size conversions we have whenever the IOMMU API is calling
    the low level drivers' map/unmap methods.
    
    Adopt all existing drivers.
    
    Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
    Cc: David Brown <davidb@codeaurora.org>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Joerg Roedel <Joerg.Roedel@amd.com>
    Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
    Cc: KyongHo Cho <pullip.cho@samsung.com>
    Cc: Hiroshi DOYU <hdoyu@nvidia.com>
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Commits on Nov 9, 2011
  1. Merge remote-tracking branch 'samsung/3.1-rc10-cma-v16' into rpmsg_3.…

    authored
    …2_rc1
    
    Conflicts:
    	arch/arm/Kconfig
    	arch/arm/include/asm/mach/map.h
    	arch/arm/mm/dma-mapping.c
    	arch/arm/mm/mmu.c
    	arch/arm/plat-s5p/dev-mfc.c
Commits on Nov 8, 2011
  1. @torvalds

    Linux 3.2-rc1

    torvalds authored
    .. with new name.  Because nothing says "really solid kernel release"
    like naming it after an extinct animal that just happened to be in the
    news lately.
  2. @torvalds

    Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git…

    torvalds authored
    …/tmlind/linux-omap
    
    * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (31 commits)
      ARM: OMAP: Fix export.h or module.h includes
      ARM: OMAP: omap_device: Include linux/export.h
      ARM: OMAP2: Fix H4 matrix keyboard warning
      ARM: OMAP1: Remove unused omap-alsa.h
      ARM: OMAP1: Fix warnings about enabling 32 KiHz timer
      ARM: OMAP2+: timer: Remove omap_device_pm_latency
      ARM: OMAP2+: clock data: Remove redundant timer clkdev
      ARM: OMAP: Devkit8000: Remove double omap_mux_init_gpio
      ARM: OMAP: usb: musb: OMAP: Delete unused function
      MAINTAINERS: Update linux-omap git repository
      ARM: OMAP: change get_context_loss_count ret value to int
      ARM: OMAP4: hsmmc: configure SDMMC1_DR0 properly
      ARM: OMAP4: hsmmc: Fix Pbias configuration on regulator OFF
      ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list
      ARM: OMAP: I2C: Fix omap_register_i2c_bus() return value on success
      ARM: OMAP: dmtimer: Include linux/module.h
      ARM: OMAP2+: l3-noc: Include linux/module.h
      ARM: OMAP2+: devices: Fixes for McPDM
      ARM: OMAP: Fix errors and warnings when building for one board
      ARM: OMAP3: PM: restrict erratum i443 handling to OMAP3430 only
      ...
Commits on Nov 7, 2011
  1. @torvalds

    VFS: we need to set LOOKUP_JUMPED on mountpoint crossing

    Al Viro authored torvalds committed
    Mountpoint crossing is similar to following procfs symlinks - we do
    not get ->d_revalidate() called for dentry we have arrived at, with
    unpleasant consequences for NFS4.
    
    Simple way to reproduce the problem in mainline:
    
        cat >/tmp/a.c <<'EOF'
        #include <unistd.h>
        #include <fcntl.h>
        #include <stdio.h>
        main()
        {
                struct flock fl = {.l_type = F_RDLCK, .l_whence = SEEK_SET, .l_len = 1};
                if (fcntl(0, F_SETLK, &fl))
                        perror("setlk");
        }
        EOF
        cc /tmp/a.c -o /tmp/test
    
    then on nfs4:
    
        mount --bind file1 file2
        /tmp/test < file1		# ok
        /tmp/test < file2		# spews "setlk: No locks available"...
    
    What happens is the missing call of ->d_revalidate() after mountpoint
    crossing and that's where NFS4 would issue OPEN request to server.
    
    The fix is simple - treat mountpoint crossing the same way we deal with
    following procfs-style symlinks.  I.e.  set LOOKUP_JUMPED...
    
    Cc: stable@kernel.org
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  2. @torvalds

    Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/…

    torvalds authored
    …linux/kernel/git/tip/tip
    
    * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
      perf top: Fix live annotation in the --stdio interface
      perf top tui: Don't recalc column widths considering just the first page
      perf report: Add progress bar when processing time ordered events
      perf hists browser: Warn about lost events
      perf tools: Fix a typo of command name as trace-cmd
      perf hists: Fix recalculation of total_period when sorting entries
      perf header: Fix build on old systems
      perf ui browser: Handle K_RESIZE in dialog windows
      perf ui browser: No need to switch char sets that often
      perf hists browser: Use K_TIMER
      perf ui: Rename ui__warning_paranoid to ui__error_paranoid
      perf ui: Reimplement the popup windows using libslang
      perf ui: Reimplement ui__popup_menu using ui__browser
      perf ui: Reimplement ui_helpline using libslang
      perf ui: Improve handling sigwinch a bit
      perf ui progress: Reimplement using slang
      perf evlist: Fix grouping of multiple events
  3. @tmlind
Something went wrong with that request. Please try again.