Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-09-20 15:03:04 +00:00
Code Issues Packages Projects Releases Wiki Activity
master
linux/drivers/dma/dw/dw.c

146 lines
3.6 KiB
C
Raw Permalink Normal View History

dmaengine: dw: Split DW and iDMA 32-bit operations Here is a kinda big refactoring that should have been done in the first place, when Intel iDMA 32-bit support appeared. It splits operations which are different to Synopsys DesignWare and Intel iDMA 32-bit controllers. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-01-07 11:07:38 +00:00
// SPDX-License-Identifier: GPL-2.0
// Copyright (C) 2007-2008 Atmel Corporation
// Copyright (C) 2010-2011 ST Microelectronics
// Copyright (C) 2013,2018 Intel Corporation
#include <linux/bitops.h>
dmaengine: dw: Don't pollute CTL_LO on iDMA 32-bit Intel iDMA 32-bit doesn't have a concept of bus masters and thus there is no need to setup any kind of masters in the CTL_LO register. Moreover, the burst size for memory-to-memory transfer is not what is says, we need to have a corrected list of possible sizes. Note, that the size of 8 items, each of that up to 4 bytes, is chosen because of maximum of 1/2 FIFO, which is 64 bytes on Intel Merrifield. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-01-07 11:07:40 +00:00
#include <linux/dmaengine.h>
dmaengine: dw: Split DW and iDMA 32-bit operations Here is a kinda big refactoring that should have been done in the first place, when Intel iDMA 32-bit support appeared. It splits operations which are different to Synopsys DesignWare and Intel iDMA 32-bit controllers. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-01-07 11:07:38 +00:00
#include <linux/errno.h>
#include <linux/slab.h>
#include <linux/types.h>
#include "internal.h"
static void dw_dma_initialize_chan(struct dw_dma_chan *dwc)
{
struct dw_dma *dw = to_dw_dma(dwc->chan.device);
dmaengine: dw: Activate FIFO-mode for memory peripherals only CFGx.FIFO_MODE field controls a DMA-controller "FIFO readiness" criterion. In other words it determines when to start pushing data out of a DW DMAC channel FIFO to a destination peripheral or from a source peripheral to the DW DMAC channel FIFO. Currently FIFO-mode is set to one for all DW DMAC channels. It means they are tuned to flush data out of FIFO (to a memory peripheral or by accepting the burst transaction requests) when FIFO is at least half-full (except at the end of the block transfer, when FIFO-flush mode is activated) and are configured to get data to the FIFO when it's at least half-empty. Such configuration is a good choice when there is no slave device involved in the DMA transfers. In that case the number of bursts per block is less than when CFGx.FIFO_MODE = 0 and, hence, the bus utilization will improve. But the latency of DMA transfers may increase when CFGx.FIFO_MODE = 1, since DW DMAC will wait for the channel FIFO contents to be either half-full or half-empty depending on having the destination or the source transfers. Such latencies might be dangerous in case if the DMA transfers are expected to be performed from/to a slave device. Since normally peripheral devices keep data in internal FIFOs, any latency at some critical moment may cause one being overflown and consequently losing data. This especially concerns a case when either a peripheral device is relatively fast or the DW DMAC engine is relatively slow with respect to the incoming data pace. In order to solve problems, which might be caused by the latencies described above, let's enable the FIFO half-full/half-empty "FIFO readiness" criterion only for DMA transfers with no slave device involved. Thanks to the commit 99ba8b9b0d97 ("dmaengine: dw: Initialize channel before each transfer") we can freely do that in the generic dw_dma_initialize_chan() method. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200731200826.9292-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-07-31 20:08:23 +00:00
u32 cfghi = is_slave_direction(dwc->direction) ? 0 : DWC_CFGH_FIFO_MODE;
dmaengine: dw: Split DW and iDMA 32-bit operations Here is a kinda big refactoring that should have been done in the first place, when Intel iDMA 32-bit support appeared. It splits operations which are different to Synopsys DesignWare and Intel iDMA 32-bit controllers. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-01-07 11:07:38 +00:00
u32 cfglo = DWC_CFGL_CH_PRIOR(dwc->priority);
bool hs_polarity = dwc->dws.hs_polarity;
cfghi |= DWC_CFGH_DST_PER(dwc->dws.dst_id);
cfghi |= DWC_CFGH_SRC_PER(dwc->dws.src_id);
cfghi |= DWC_CFGH_PROTCTL(dw->pdata->protctl);
/* Set polarity of handshake interface */
cfglo |= hs_polarity ? DWC_CFGL_HS_DST_POL | DWC_CFGL_HS_SRC_POL : 0;
channel_writel(dwc, CFG_LO, cfglo);
channel_writel(dwc, CFG_HI, cfghi);
}
static void dw_dma_suspend_chan(struct dw_dma_chan *dwc, bool drain)
{
u32 cfglo = channel_readl(dwc, CFG_LO);
channel_writel(dwc, CFG_LO, cfglo | DWC_CFGL_CH_SUSP);
}
dmaengine: dw: Reset DRAIN bit when resume the channel For Intel iDMA 32-bit the channel can be drained on a suspend. We need to reset the bit on the resume to return a status quo. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-01-07 11:07:39 +00:00
static void dw_dma_resume_chan(struct dw_dma_chan *dwc, bool drain)
{
u32 cfglo = channel_readl(dwc, CFG_LO);
channel_writel(dwc, CFG_LO, cfglo & ~DWC_CFGL_CH_SUSP);
}
dmaengine: dw: Split DW and iDMA 32-bit operations Here is a kinda big refactoring that should have been done in the first place, when Intel iDMA 32-bit support appeared. It splits operations which are different to Synopsys DesignWare and Intel iDMA 32-bit controllers. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-01-07 11:07:38 +00:00
static u32 dw_dma_bytes2block(struct dw_dma_chan *dwc,
size_t bytes, unsigned int width, size_t *len)
{
u32 block;
if ((bytes >> width) > dwc->block_size) {
block = dwc->block_size;
*len = dwc->block_size << width;
} else {
block = bytes >> width;
*len = bytes;
}
return block;
}
static size_t dw_dma_block2bytes(struct dw_dma_chan *dwc, u32 block, u32 width)
{
return DWC_CTLH_BLOCK_TS(block) << width;
}
dmaengine: dw: Simplify max-burst calculation procedure In order to have a more coherent DW AHB DMA slave configuration method - dwc_config() - let's simplify the source and destination channel max-burst calculation procedure: 1. Create the max-burst verification method as it has been just done for the memory and peripheral address widths. Thus the dwc_config() method will turn to a set of the verification methods execution. 2. Since both the generic DW AHB DMA and Intel iDMA 32-bit engines support the power-of-2 bursts only, then the specified by the client driver max-burst values can be converted to being power-of-2 right in the max-burst verification method. 3. Since max-burst encoded value is required on the CTL_LO fields calculation stage, the encode_maxburst() callback can be easily dropped from the dw_dma structure meanwhile the encoding procedure will be executed right in the CTL_LO register value calculation. Thus the update will provide the next positive effects: the internal DMA-slave config structure will contain only the real DMA-transfer config values, which will be encoded to the DMA-controller register fields only when it's required on the buffer mapping; the redundant encode_maxburst() callback will be dropped simplifying the internal HW-abstraction API; dwc_config() will look more readable executing the verification functions one-by-one. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240802075100.6475-6-fancer.lancer@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2024-08-02 07:50:50 +00:00
static inline u8 dw_dma_encode_maxburst(u32 maxburst)
dmaengine: dw: Define encode_maxburst() above prepare_ctllo() callbacks As a preparatory change before dropping the encode_maxburst() callbacks let's move dw_dma_encode_maxburst() and idma32_encode_maxburst() to being defined above the dw_dma_prepare_ctllo() and idma32_prepare_ctllo() methods respectively. That's required since the former methods will be called from the later ones directly. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240802075100.6475-5-fancer.lancer@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2024-08-02 07:50:49 +00:00
{
/*
* Fix burst size according to dw_dmac. We need to convert them as:
* 1 -> 0, 4 -> 1, 8 -> 2, 16 -> 3.
*/
dmaengine: dw: Simplify max-burst calculation procedure In order to have a more coherent DW AHB DMA slave configuration method - dwc_config() - let's simplify the source and destination channel max-burst calculation procedure: 1. Create the max-burst verification method as it has been just done for the memory and peripheral address widths. Thus the dwc_config() method will turn to a set of the verification methods execution. 2. Since both the generic DW AHB DMA and Intel iDMA 32-bit engines support the power-of-2 bursts only, then the specified by the client driver max-burst values can be converted to being power-of-2 right in the max-burst verification method. 3. Since max-burst encoded value is required on the CTL_LO fields calculation stage, the encode_maxburst() callback can be easily dropped from the dw_dma structure meanwhile the encoding procedure will be executed right in the CTL_LO register value calculation. Thus the update will provide the next positive effects: the internal DMA-slave config structure will contain only the real DMA-transfer config values, which will be encoded to the DMA-controller register fields only when it's required on the buffer mapping; the redundant encode_maxburst() callback will be dropped simplifying the internal HW-abstraction API; dwc_config() will look more readable executing the verification functions one-by-one. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240802075100.6475-6-fancer.lancer@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2024-08-02 07:50:50 +00:00
return maxburst > 1 ? fls(maxburst) - 2 : 0;
dmaengine: dw: Define encode_maxburst() above prepare_ctllo() callbacks As a preparatory change before dropping the encode_maxburst() callbacks let's move dw_dma_encode_maxburst() and idma32_encode_maxburst() to being defined above the dw_dma_prepare_ctllo() and idma32_prepare_ctllo() methods respectively. That's required since the former methods will be called from the later ones directly. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240802075100.6475-5-fancer.lancer@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2024-08-02 07:50:49 +00:00
}
dmaengine: dw: Don't pollute CTL_LO on iDMA 32-bit Intel iDMA 32-bit doesn't have a concept of bus masters and thus there is no need to setup any kind of masters in the CTL_LO register. Moreover, the burst size for memory-to-memory transfer is not what is says, we need to have a corrected list of possible sizes. Note, that the size of 8 items, each of that up to 4 bytes, is chosen because of maximum of 1/2 FIFO, which is 64 bytes on Intel Merrifield. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-01-07 11:07:40 +00:00
static u32 dw_dma_prepare_ctllo(struct dw_dma_chan *dwc)
{
struct dma_slave_config *sconfig = &dwc->dma_sconfig;
dmaengine: dw: Simplify prepare CTL_LO methods Currently the CTL LO fields are calculated on the platform-specific basis. It's implemented by means of the prepare_ctllo() callbacks using the ternary operator within the local variables init block at the beginning of the block scope. The functions code currently is relatively hard to comprehend and isn't that optimal since implies four conditional statements executed and two additional local variables defined. Let's simplify the DW AHB DMA prepare_ctllo() method by unrolling the ternary operators into the normal if-else statement, dropping redundant master-interface ID variables and initializing the local variables based on the singly evaluated DMA-transfer direction check. Thus the method will look much more readable since now the fields content can be easily inferred right from the if-else branch. Provide the same update in the Intel DMA32 core driver for the sake of the driver code unification. Note besides of the effects described above this update is basically a preparation before dropping the max burst encoding callback. The dropping will require to call the burst fields calculation methods right in the prepare_ctllo() callbacks. It would have made the later functions code even more complex should they were left in the original state. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240802075100.6475-4-fancer.lancer@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2024-08-02 07:50:48 +00:00
u8 smsize = 0, dmsize = 0;
u8 sms, dms;
if (dwc->direction == DMA_MEM_TO_DEV) {
sms = dwc->dws.m_master;
dms = dwc->dws.p_master;
dmaengine: dw: Simplify max-burst calculation procedure In order to have a more coherent DW AHB DMA slave configuration method - dwc_config() - let's simplify the source and destination channel max-burst calculation procedure: 1. Create the max-burst verification method as it has been just done for the memory and peripheral address widths. Thus the dwc_config() method will turn to a set of the verification methods execution. 2. Since both the generic DW AHB DMA and Intel iDMA 32-bit engines support the power-of-2 bursts only, then the specified by the client driver max-burst values can be converted to being power-of-2 right in the max-burst verification method. 3. Since max-burst encoded value is required on the CTL_LO fields calculation stage, the encode_maxburst() callback can be easily dropped from the dw_dma structure meanwhile the encoding procedure will be executed right in the CTL_LO register value calculation. Thus the update will provide the next positive effects: the internal DMA-slave config structure will contain only the real DMA-transfer config values, which will be encoded to the DMA-controller register fields only when it's required on the buffer mapping; the redundant encode_maxburst() callback will be dropped simplifying the internal HW-abstraction API; dwc_config() will look more readable executing the verification functions one-by-one. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240802075100.6475-6-fancer.lancer@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2024-08-02 07:50:50 +00:00
dmsize = dw_dma_encode_maxburst(sconfig->dst_maxburst);
dmaengine: dw: Simplify prepare CTL_LO methods Currently the CTL LO fields are calculated on the platform-specific basis. It's implemented by means of the prepare_ctllo() callbacks using the ternary operator within the local variables init block at the beginning of the block scope. The functions code currently is relatively hard to comprehend and isn't that optimal since implies four conditional statements executed and two additional local variables defined. Let's simplify the DW AHB DMA prepare_ctllo() method by unrolling the ternary operators into the normal if-else statement, dropping redundant master-interface ID variables and initializing the local variables based on the singly evaluated DMA-transfer direction check. Thus the method will look much more readable since now the fields content can be easily inferred right from the if-else branch. Provide the same update in the Intel DMA32 core driver for the sake of the driver code unification. Note besides of the effects described above this update is basically a preparation before dropping the max burst encoding callback. The dropping will require to call the burst fields calculation methods right in the prepare_ctllo() callbacks. It would have made the later functions code even more complex should they were left in the original state. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240802075100.6475-4-fancer.lancer@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2024-08-02 07:50:48 +00:00
} else if (dwc->direction == DMA_DEV_TO_MEM) {
sms = dwc->dws.p_master;
dms = dwc->dws.m_master;
dmaengine: dw: Simplify max-burst calculation procedure In order to have a more coherent DW AHB DMA slave configuration method - dwc_config() - let's simplify the source and destination channel max-burst calculation procedure: 1. Create the max-burst verification method as it has been just done for the memory and peripheral address widths. Thus the dwc_config() method will turn to a set of the verification methods execution. 2. Since both the generic DW AHB DMA and Intel iDMA 32-bit engines support the power-of-2 bursts only, then the specified by the client driver max-burst values can be converted to being power-of-2 right in the max-burst verification method. 3. Since max-burst encoded value is required on the CTL_LO fields calculation stage, the encode_maxburst() callback can be easily dropped from the dw_dma structure meanwhile the encoding procedure will be executed right in the CTL_LO register value calculation. Thus the update will provide the next positive effects: the internal DMA-slave config structure will contain only the real DMA-transfer config values, which will be encoded to the DMA-controller register fields only when it's required on the buffer mapping; the redundant encode_maxburst() callback will be dropped simplifying the internal HW-abstraction API; dwc_config() will look more readable executing the verification functions one-by-one. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240802075100.6475-6-fancer.lancer@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2024-08-02 07:50:50 +00:00
smsize = dw_dma_encode_maxburst(sconfig->src_maxburst);
dmaengine: dw: Simplify prepare CTL_LO methods Currently the CTL LO fields are calculated on the platform-specific basis. It's implemented by means of the prepare_ctllo() callbacks using the ternary operator within the local variables init block at the beginning of the block scope. The functions code currently is relatively hard to comprehend and isn't that optimal since implies four conditional statements executed and two additional local variables defined. Let's simplify the DW AHB DMA prepare_ctllo() method by unrolling the ternary operators into the normal if-else statement, dropping redundant master-interface ID variables and initializing the local variables based on the singly evaluated DMA-transfer direction check. Thus the method will look much more readable since now the fields content can be easily inferred right from the if-else branch. Provide the same update in the Intel DMA32 core driver for the sake of the driver code unification. Note besides of the effects described above this update is basically a preparation before dropping the max burst encoding callback. The dropping will require to call the burst fields calculation methods right in the prepare_ctllo() callbacks. It would have made the later functions code even more complex should they were left in the original state. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240802075100.6475-4-fancer.lancer@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2024-08-02 07:50:48 +00:00
} else /* DMA_MEM_TO_MEM */ {
sms = dwc->dws.m_master;
dms = dwc->dws.m_master;
}
dmaengine: dw: Don't pollute CTL_LO on iDMA 32-bit Intel iDMA 32-bit doesn't have a concept of bus masters and thus there is no need to setup any kind of masters in the CTL_LO register. Moreover, the burst size for memory-to-memory transfer is not what is says, we need to have a corrected list of possible sizes. Note, that the size of 8 items, each of that up to 4 bytes, is chosen because of maximum of 1/2 FIFO, which is 64 bytes on Intel Merrifield. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-01-07 11:07:40 +00:00
return DWC_CTLL_LLP_D_EN | DWC_CTLL_LLP_S_EN |
DWC_CTLL_DST_MSIZE(dmsize) | DWC_CTLL_SRC_MSIZE(smsize) |
DWC_CTLL_DMS(dms) | DWC_CTLL_SMS(sms);
}
dmaengine: dw: Split DW and iDMA 32-bit operations Here is a kinda big refactoring that should have been done in the first place, when Intel iDMA 32-bit support appeared. It splits operations which are different to Synopsys DesignWare and Intel iDMA 32-bit controllers. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-01-07 11:07:38 +00:00
static void dw_dma_set_device_name(struct dw_dma *dw, int id)
{
snprintf(dw->name, sizeof(dw->name), "dw:dmac%d", id);
}
static void dw_dma_disable(struct dw_dma *dw)
{
do_dw_dma_off(dw);
}
static void dw_dma_enable(struct dw_dma *dw)
{
do_dw_dma_on(dw);
}
int dw_dma_probe(struct dw_dma_chip *chip)
{
struct dw_dma *dw;
dw = devm_kzalloc(chip->dev, sizeof(*dw), GFP_KERNEL);
if (!dw)
return -ENOMEM;
/* Channel operations */
dw->initialize_chan = dw_dma_initialize_chan;
dw->suspend_chan = dw_dma_suspend_chan;
dmaengine: dw: Reset DRAIN bit when resume the channel For Intel iDMA 32-bit the channel can be drained on a suspend. We need to reset the bit on the resume to return a status quo. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-01-07 11:07:39 +00:00
dw->resume_chan = dw_dma_resume_chan;
dmaengine: dw: Don't pollute CTL_LO on iDMA 32-bit Intel iDMA 32-bit doesn't have a concept of bus masters and thus there is no need to setup any kind of masters in the CTL_LO register. Moreover, the burst size for memory-to-memory transfer is not what is says, we need to have a corrected list of possible sizes. Note, that the size of 8 items, each of that up to 4 bytes, is chosen because of maximum of 1/2 FIFO, which is 64 bytes on Intel Merrifield. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-01-07 11:07:40 +00:00
dw->prepare_ctllo = dw_dma_prepare_ctllo;
dmaengine: dw: Split DW and iDMA 32-bit operations Here is a kinda big refactoring that should have been done in the first place, when Intel iDMA 32-bit support appeared. It splits operations which are different to Synopsys DesignWare and Intel iDMA 32-bit controllers. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-01-07 11:07:38 +00:00
dw->bytes2block = dw_dma_bytes2block;
dw->block2bytes = dw_dma_block2bytes;
/* Device operations */
dw->set_device_name = dw_dma_set_device_name;
dw->disable = dw_dma_disable;
dw->enable = dw_dma_enable;
chip->dw = dw;
return do_dma_probe(chip);
}
EXPORT_SYMBOL_GPL(dw_dma_probe);
int dw_dma_remove(struct dw_dma_chip *chip)
{
return do_dma_remove(chip);
}
EXPORT_SYMBOL_GPL(dw_dma_remove);
Reference in New Issue Copy Permalink