1. 30 4月, 2013 1 次提交
  2. 16 4月, 2013 1 次提交
    • A
      dma: acpi-dma: introduce ACPI DMA helpers · 1b2e98bc
      Andy Shevchenko 提交于
      There is a new generic API to get a DMA channel for a slave device (commit
      9a6cecc8 "dmaengine: add helper function to request a slave DMA channel"). In
      similar fashion to the DT case (commit aa3da644 "of: Add generic device tree
      DMA helpers") we introduce helpers to the DMAC drivers which are enumerated by
      ACPI.
      
      The proposed extension provides the following API calls:
      	acpi_dma_controller_register(), devm_acpi_dma_controller_register()
      	acpi_dma_controller_free(), devm_acpi_dma_controller_free()
      	acpi_dma_simple_xlate()
      	acpi_dma_request_slave_chan_by_index()
      	acpi_dma_request_slave_chan_by_name()
      
      The first two should be used, for example, at probe() and remove() of the
      corresponding DMAC driver. At the register stage the DMAC driver supplies a
      custom xlate() function to translate a struct dma_spec into struct dma_chan.
      
      Accordingly to the ACPI Fixed DMA resource specification the only two pieces of
      information the slave device has are the channel id and the request line (slave
      id). Those two are represented by struct dma_spec. The
      acpi_dma_request_slave_chan_by_index() provides access to the specifix FixedDMA
      resource by its index. Whereas dma_request_slave_channel() takes a string
      parameter to identify the DMA resources required by the slave device. To make a
      slave device driver work with both DeviceTree and ACPI enumeration a simple
      convention is established: "tx" corresponds to the index 0 and "rx" to the
      index 1. In case of robust configuration the slave device driver unfortunately
      needs to call acpi_dma_request_slave_chan_by_index() directly.
      
      Additionally the patch provides "managed" version of the register/free pair
      i.e. devm_acpi_dma_controller_register() and devm_acpi_dma_controller_free().
      Usually, the driver uses only devm_acpi_dma_controller_register().
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      1b2e98bc
  3. 15 4月, 2013 4 次提交
    • A
      dmatest: append verify result to results · d86b2f29
      Andy Shevchenko 提交于
      Comparison between buffers is stored to the dedicated structure.
      
      Note that the verify result is now accessible only via file 'results' in the
      debugfs.
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      d86b2f29
    • A
      dmatest: gather test results in the linked list · 95019c8c
      Andy Shevchenko 提交于
      The patch provides a storage for the test results in the linked list. The
      gathered data could be used after test is done.
      
      The new file 'results' represents gathered data of the in progress test. The
      messages collected are printed to the kernel log as well.
      
      Example of output:
      	% cat /sys/kernel/debug/dmatest/results
      	dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0)
      
      The message format is unified across the different types of errors. A number in
      the parens represents additional information, e.g. error code, error counter,
      or status.
      
      Note that the buffer comparison is done in the old way, i.e. data is not
      collected and just printed out.
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      95019c8c
    • A
      dmatest: return actual state in 'run' file · 3e5ccd86
      Andy Shevchenko 提交于
      The following command should return actual state of the test.
      	% cat /sys/kernel/debug/dmatest/run
      
      To wait for test done the user may perform a busy loop that checks the state.
      	% while [ $(cat /sys/kernel/debug/dmatest/run) = "Y" ]
      	> do
      	> 	echo -n "."
      	> 	sleep 1
      	> done
      	> echo
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      3e5ccd86
    • A
      dmatest: run test via debugfs · 851b7e16
      Andy Shevchenko 提交于
      Instead of doing
      	modprobe dmatest ...
      	modprobe -r dmatest
      we allow user to run tests interactively.
      
      The dmatest could be built as module or inside kernel. Let's consider those
      cases.
      
      1. When dmatest is built as a module...
      
      After mounting debugfs and loading the module, the /sys/kernel/debug/dmatest
      folder with nodes will be created. They are the same as module parameters with
      addition of the 'run' node that controls run and stop phases of the test.
      
      Note that in this case test will not run on load automatically.
      
      Example of usage:
      	% echo dma0chan0 > /sys/kernel/debug/dmatest/channel
      	% echo 2000 > /sys/kernel/debug/dmatest/timeout
      	% echo 1 > /sys/kernel/debug/dmatest/iterations
      	% echo 1 > /sys/kernel/debug/dmatest/run
      
      After a while you will start to get messages about current status or error like
      in the original code.
      
      Note that running a new test will stop any in progress test.
      
      2. When built-in in the kernel...
      
      The module parameters that is supplied to the kernel command line will be used
      for the first performed test. After user gets a control, the test could be
      interrupted or re-run with same or different parameters. For the details see
      the above section "1. When dmatest is built as a module..."
      
      In both cases the module parameters are used as initial values for the test case.
      You always could check them at run-time by running
      	% grep -H . /sys/module/dmatest/parameters/*
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      851b7e16
  4. 06 4月, 2013 1 次提交
  5. 04 4月, 2013 2 次提交
  6. 22 3月, 2013 1 次提交
  7. 19 3月, 2013 2 次提交
    • J
      ipvs: add backup_only flag to avoid loops · 0c12582f
      Julian Anastasov 提交于
      Dmitry Akindinov is reporting for a problem where SYNs are looping
      between the master and backup server when the backup server is used as
      real server in DR mode and has IPVS rules to function as director.
      
      Even when the backup function is enabled we continue to forward
      traffic and schedule new connections when the current master is using
      the backup server as real server. While this is not a problem for NAT,
      for DR and TUN method the backup server can not determine if a request
      comes from client or from director.
      
      To avoid such loops add new sysctl flag backup_only. It can be needed
      for DR/TUN setups that do not need backup and director function at the
      same time. When the backup function is enabled we stop any forwarding
      and pass the traffic to the local stack (real server mode). The flag
      disables the director function when the backup function is enabled.
      
      For setups that enable backup function for some virtual services and
      director function for other virtual services there should be another
      more complex solution to support DR/TUN mode, may be to assign
      per-virtual service syncid value, so that we can differentiate the
      requests.
      Reported-by: NDmitry Akindinov <dimak@stalker.com>
      Tested-by: NGerman Myzovsky <lawyer@sipnet.ru>
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      0c12582f
    • J
      hwmon: (lm75) Fix tcn75 prefix · 25eba81b
      Jean Delvare 提交于
      The TCN75 has its own prefix for a long time now.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      25eba81b
  8. 17 3月, 2013 1 次提交
  9. 12 3月, 2013 2 次提交
  10. 09 3月, 2013 1 次提交
  11. 08 3月, 2013 1 次提交
  12. 07 3月, 2013 1 次提交
  13. 04 3月, 2013 4 次提交
  14. 03 3月, 2013 3 次提交
    • J
      metag: Basic documentation · fdabf525
      James Hogan 提交于
      Add basic metag documentation. This includes an outline description of
      the ABIs (including syscall ABI) and calling conventions, similar to the
      one in Documentation/frv/.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Rob Landley <rob@landley.net>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Cc: linux-doc@vger.kernel.org
      fdabf525
    • J
      metag: Internal and external irqchips · 5698c50d
      James Hogan 提交于
      Meta core internal interrupts (from HWSTATMETA and friends) are vectored
      onto the TR1 core trigger for the current thread. This is demultiplexed
      in irq-metag.c to individual Linux IRQs for each internal interrupt.
      
      External SoC interrupts (from HWSTATEXT and friends) are vectored onto
      the TR2 core trigger for the current thread. This is demultiplexed in
      irq-metag-ext.c to individual Linux IRQs for each external SoC interrupt.
      The external irqchip has devicetree bindings for configuring the number
      of irq banks and the type of masking available.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Rob Landley <rob@landley.net>
      Cc: Dom Cobley <popcornmix@gmail.com>
      Cc: Simon Arlott <simon@fire.lp0.eu>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
      Cc: devicetree-discuss@lists.ozlabs.org
      Cc: linux-doc@vger.kernel.org
      5698c50d
    • Y
      x86, ACPI, mm: Revert movablemem_map support · 20e6926d
      Yinghai Lu 提交于
      Tim found:
      
        WARNING: at arch/x86/kernel/smpboot.c:324 topology_sane.isra.2+0x6f/0x80()
        Hardware name: S2600CP
        sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
        smpboot: Booting Node   1, Processors  #1
        Modules linked in:
        Pid: 0, comm: swapper/1 Not tainted 3.9.0-0-generic #1
        Call Trace:
          set_cpu_sibling_map+0x279/0x449
          start_secondary+0x11d/0x1e5
      
      Don Morris reproduced on a HP z620 workstation, and bisected it to
      commit e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock
      is ready")
      
      It turns out movable_map has some problems, and it breaks several things
      
      1. numa_init is called several times, NOT just for srat. so those
      	nodes_clear(numa_nodes_parsed)
      	memset(&numa_meminfo, 0, sizeof(numa_meminfo))
         can not be just removed.  Need to consider sequence is: numaq, srat, amd, dummy.
         and make fall back path working.
      
      2. simply split acpi_numa_init to early_parse_srat.
         a. that early_parse_srat is NOT called for ia64, so you break ia64.
         b.  for (i = 0; i < MAX_LOCAL_APIC; i++)
      	     set_apicid_to_node(i, NUMA_NO_NODE)
           still left in numa_init. So it will just clear result from early_parse_srat.
           it should be moved before that....
         c.  it breaks ACPI_TABLE_OVERIDE...as the acpi table scan is moved
             early before override from INITRD is settled.
      
      3. that patch TITLE is total misleading, there is NO x86 in the title,
         but it changes critical x86 code. It caused x86 guys did not
         pay attention to find the problem early. Those patches really should
         be routed via tip/x86/mm.
      
      4. after that commit, following range can not use movable ram:
        a. real_mode code.... well..funny, legacy Node0 [0,1M) could be hot-removed?
        b. initrd... it will be freed after booting, so it could be on movable...
        c. crashkernel for kdump...: looks like we can not put kdump kernel above 4G
      	anymore.
        d. init_mem_mapping: can not put page table high anymore.
        e. initmem_init: vmemmap can not be high local node anymore. That is
           not good.
      
      If node is hotplugable, the mem related range like page table and
      vmemmap could be on the that node without problem and should be on that
      node.
      
      We have workaround patch that could fix some problems, but some can not
      be fixed.
      
      So just remove that offending commit and related ones including:
      
       f7210e6c ("mm/memblock.c: use CONFIG_HAVE_MEMBLOCK_NODE_MAP to
          protect movablecore_map in memblock_overlaps_region().")
      
       01a178a9 ("acpi, memory-hotplug: support getting hotplug info from
          SRAT")
      
       27168d38 ("acpi, memory-hotplug: extend movablemem_map ranges to
          the end of node")
      
       e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock is
          ready")
      
       fb06bc8e ("page_alloc: bootmem limit with movablecore_map")
      
       42f47e27 ("page_alloc: make movablemem_map have higher priority")
      
       6981ec31 ("page_alloc: introduce zone_movable_limit[] to keep
          movable limit for nodes")
      
       34b71f1e ("page_alloc: add movable_memmap kernel parameter")
      
       4d59a751 ("x86: get pg_data_t's memory from other node")
      
      Later we should have patches that will make sure kernel put page table
      and vmemmap on local node ram instead of push them down to node0.  Also
      need to find way to put other kernel used ram to local node ram.
      Reported-by: NTim Gardner <tim.gardner@canonical.com>
      Reported-by: NDon Morris <don.morris@hp.com>
      Bisected-by: NDon Morris <don.morris@hp.com>
      Tested-by: NDon Morris <don.morris@hp.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      20e6926d
  15. 02 3月, 2013 3 次提交
  16. 01 3月, 2013 5 次提交
  17. 28 2月, 2013 6 次提交
  18. 27 2月, 2013 1 次提交
    • D
      dma-buf: implement vmap refcounting in the interface logic · f00b4dad
      Daniel Vetter 提交于
      All drivers which implement this need to have some sort of refcount to
      allow concurrent vmap usage. Hence implement this in the dma-buf core.
      
      To protect against concurrent calls we need a lock, which potentially
      causes new funny locking inversions. But this shouldn't be a problem
      for exporters with statically allocated backing storage, and more
      dynamic drivers have decent issues already anyway.
      
      Inspired by some refactoring patches from Aaron Plattner, who
      implemented the same idea, but only for drm/prime drivers.
      
      v2: Check in dma_buf_release that no dangling vmaps are left.
      Suggested by Aaron Plattner. We might want to do similar checks for
      attachments, but that's for another patch. Also fix up ERR_PTR return
      for vmap.
      
      v3: Check whether the passed-in vmap address matches with the cached
      one for vunmap. Eventually we might want to remove that parameter -
      compared to the kmap functions there's no need for the vaddr for
      unmapping.  Suggested by Chris Wilson.
      
      v4: Fix a brown-paper-bag bug spotted by Aaron Plattner.
      
      Cc: Aaron Plattner <aplattner@nvidia.com>
      Reviewed-by: NAaron Plattner <aplattner@nvidia.com>
      Tested-by: NAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: NRob Clark <rob@ti.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
      f00b4dad