Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 4 年多

通知 15
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 15 1月, 2014 1 次提交
    • L
      dma: Indicate residue granularity in dma_slave_caps · 50720563
      由 Lars-Peter Clausen 提交于 
      This patch adds a new field to the dma_slave_caps struct which indicates the
granularity with which the driver is able to update the residue field of the
dma_tx_state struct. Making this information available to dmaengine users allows
them to make better decisions on how to operate. E.g. for audio certain features
like wakeup less operation or timer based scheduling only make sense and work
correctly if the reported residue is fine-grained enough.

Right now four different levels of granularity are supported:
	* DESCRIPTOR: The DMA channel is only able to tell whether a descriptor has
	  been completed or not, which means residue reporting is not supported by
	  this channel. The residue field of the dma_tx_state field will always be
	  0.
	* SEGMENT: The DMA channel updates the residue field after each successfully
	  completed segment of the transfer (For cyclic transfers this is after each
	  period). This is typically implemented by having the hardware generate an
	  interrupt after each transferred segment and then the drivers updates the
	  outstanding residue by the size of the segment. Another possibility is if
	  the hardware supports SG and the segment descriptor has a field which gets
	  set after the segment has been completed. The driver then counts the
	  number of segments without the flag set to compute the residue.
	* BURST: The DMA channel updates the residue field after each transferred
	  burst. This is typically only supported if the hardware has a progress
	  register of some sort (E.g. a register with the current read/write address
	  or a register with the amount of bursts/beats/bytes that have been
	  transferred or still need to be transferred).
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
      50720563
  3. 10 1月, 2014 1 次提交
  5. 08 1月, 2014 3 次提交
  7. 07 1月, 2014 1 次提交
  9. 30 12月, 2013 1 次提交
  11. 25 12月, 2013 1 次提交
  13. 22 12月, 2013 1 次提交
    • B
      aio/migratepages: make aio migrate pages sane · 8e321fef
      由 Benjamin LaHaise 提交于 
      The arbitrary restriction on page counts offered by the core
migrate_page_move_mapping() code results in rather suspicious looking
fiddling with page reference counts in the aio_migratepage() operation.
To fix this, make migrate_page_move_mapping() take an extra_count parameter
that allows aio to tell the code about its own reference count on the page
being migrated.

While cleaning up aio_migratepage(), make it validate that the old page
being passed in is actually what aio_migratepage() expects to prevent
misbehaviour in the case of races.
Signed-off-by: NBenjamin LaHaise <bcrl@kvack.org>
      8e321fef
  15. 21 12月, 2013 2 次提交
  17. 19 12月, 2013 5 次提交
  19. 17 12月, 2013 1 次提交
  21. 13 12月, 2013 5 次提交
  23. 12 12月, 2013 1 次提交
  25. 11 12月, 2013 5 次提交
  27. 10 12月, 2013 2 次提交
    • S
      dma: add channel request API that supports deferred probe · 0ad7c000
      由 Stephen Warren 提交于 
      dma_request_slave_channel() simply returns NULL whenever DMA channel
lookup fails. Lookup could fail for two distinct reasons:

a) No DMA specification exists for the channel name.
   This includes situations where no DMA specifications exist at all, or
   other general lookup problems.

b) A DMA specification does exist, yet the driver for that channel is not
   yet registered.

Case (b) should trigger deferred probe in client drivers. However, since
they have no way to differentiate the two situations, it cannot.

Implement new function dma_request_slave_channel_reason(), which performs
identically to dma_request_slave_channel(), except that it returns an
error-pointer rather than NULL, which allows callers to detect when
deferred probe should occur.

Eventually, all drivers should be converted to this new API, the old API
removed, and the new API renamed to the more desirable name. This patch
doesn't convert the existing API and all drivers in one go, since some
drivers call dma_request_slave_channel() then dma_request_channel() if
that fails. That would require either modifying dma_request_channel() in
the same way, or adding extra error-handling code to all affected
drivers, and there are close to 100 drivers using the other API, rather
than just the 15-20 or so that use dma_request_slave_channel(), which
might be tenable in a single patch.

acpi_dma_request_slave_chan_by_name() doesn't currently implement
deferred probe. It should, but this will be addressed later.
Acked-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      0ad7c000
    • P
      ASoC: davinci-mcasp: Support for McASP version found in DRA7xx · 453c4990
      由 Peter Ujfalusi 提交于 
      The IP in DRA7xx is similar to the IP found in TI81xxAM3xxx/AM4xxx type of
SoCs but it is is integrated with sDMA instead of eDMA. The suitable pcm
driver for DRA7xx is the omap-pcm driver which is using dmaengine.
In the driver we can configure both dma related structures used for eDMA and
sDMA. The only thing we need to make sure that we set the correct dma_data
at startup with snd_soc_dai_set_dma_data()
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
      453c4990
  29. 08 12月, 2013 2 次提交
  31. 06 12月, 2013 2 次提交
    • P
      xen-netback: fix fragment detection in checksum setup · 1431fb31
      由 Paul Durrant 提交于 
      The code to detect fragments in checksum_setup() was missing for IPv4 and
too eager for IPv6. (It transpires that Windows seems to send IPv6 packets
with a fragment header even if they are not a fragment - i.e. offset is zero,
and M bit is not set).

This patch also incorporates a fix to callers of maybe_pull_tail() where
skb->network_header was being erroneously added to the length argument.
Signed-off-by: NPaul Durrant <paul.durrant@citrix.com>
Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: David Vrabel <david.vrabel@citrix.com>
cc: David Miller <davem@davemloft.net>
Acked-by: NWei Liu <wei.liu2@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1431fb31
    • T
      percpu: fix spurious sparse warnings from DEFINE_PER_CPU() · b1a0fbfd
      由 Tejun Heo 提交于 
      When CONFIG_DEBUG_FORCE_WEAK_PER_CPU or CONFIG_ARCH_NEEDS_WEAK_PER_CPU
is set, DEFINE_PER_CPU() explodes into cryptic series of definitions
to still allow using "static" for percpu variables while keeping all
per-cpu symbols unique in the kernel image which is required for weak
symbols.  This ultimately converts the actual symbol to global whether
DEFINE_PER_CPU() is prefixed with static or not.

Unfortunately, the macro forgot to add explicit extern declartion of
the actual symbol ending up defining global symbol without preceding
declaration for static definitions which naturally don't have matching
DECLARE_PER_CPU().  The only ill effect is triggering of the following
warnings.

 fs/inode.c:74:8: warning: symbol 'nr_inodes' was not declared. Should it be static?
 fs/inode.c:75:8: warning: symbol 'nr_unused' was not declared. Should it be static?

Fix it by adding extern declaration in the DEFINE_PER_CPU() macro.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NWanlong Gao <gaowanlong@cn.fujitsu.com>
Tested-by: NWanlong Gao <gaowanlong@cn.fujitsu.com>
      b1a0fbfd
  33. 03 12月, 2013 6 次提交