diff options
author | Russell King <[email protected]> | 2016-01-26 13:40:37 +0000 |
---|---|---|
committer | Ulf Hansson <[email protected]> | 2016-02-29 11:03:22 +0100 |
commit | 94538e51d67da97e798d379d6bcf3d386d609bfb (patch) | |
tree | 5c78bf6836b36b206a89a23171566f92ea988dac /tools/perf/util/scripting-engines/trace-event-python.c | |
parent | f48f039cd2d33d01ba15e92018dc18a0ea68c764 (diff) |
mmc: sdhci: clean up host cookie handling
Commit d31911b9374a ("mmc: sdhci: fix dma memory leak in sdhci_pre_req()")
added a complicated method to manage the DMA map state for the data
transfer, but this complexity is not required.
There are three states:
* Unmapped
* Mapped by sdhci_pre_req()
* Mapped by sdhci_prepare_data()
sdhci_prepare_data() needs to know when the data buffers have been
successfully mapped by sdhci_pre_req(), and if so, there is no need to
map them a second time.
When we come to tear down the mapping, we want to know whether
sdhci_post_req() will be called (which is determined by sdhci_pre_req()
having been previously called) so that we can postpone the unmap
operation.
Hence, it makes sense to simply record when the successful DMA map
happened (via COOKIE_PRE_MAPPED vs COOKIE_MAPPED) rather than having
the complex mechanics involving COOKIE_MAPPED vs COOKIE_GIVEN.
If a mapping is created by sdhci_prepare_data(), we must tear it down
ourselves, without waiting for sdhci_post_req() (hence, the new
COOKIE_MAPPED case). If the mapping is created by sdhci_pre_req()
then sdhci_post_req() is responsible for tearing the mapping down.
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Adrian Hunter <[email protected]>
Tested-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Diffstat (limited to 'tools/perf/util/scripting-engines/trace-event-python.c')
0 files changed, 0 insertions, 0 deletions