[RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()
Add a dmaengine API to retrieve per channel capabilities.
Currently, only channel ops and SG segment limitations are
implemented caps.
The API is optionally implemented by drivers and when
unimplemented will return a NULL pointer. It is intended
to be executed after a channel has been requested and, if
the channel is intended to be used with slave SG transfers,
then it may only be called after dmaengine_slave_config()
has executed. The slave driver provides parameters such as
burst size and address width which may be necessary for
the dmaengine driver to use in order to properly return SG
segment limit caps.
Suggested-by: Vinod Koul
Signed-off-by: Matt Porter
---
include/linux/dmaengine.h | 52 +
1 file changed, 52 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 11d9e25..0181887 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -371,6 +371,38 @@ struct dma_slave_config {
unsigned int slave_id;
};
+enum dmaengine_apis {
+ DMAENGINE_MEMCPY= 0x0001,
+ DMAENGINE_XOR = 0x0002,
+ DMAENGINE_XOR_VAL = 0x0004,
+ DMAENGINE_PQ= 0x0008,
+ DMAENGINE_PQ_VAL= 0x0010,
+ DMAENGINE_MEMSET= 0x0020,
+ DMAENGINE_SLAVE = 0x0040,
+ DMAENGINE_CYCLIC= 0x0080,
+ DMAENGINE_INTERLEAVED = 0x0100,
+ DMAENGINE_SG= 0x0200,
+};
+
+/* struct dmaengine_chan_caps - expose capability of a channel
+ * Note: each channel can have same or different capabilities
+ *
+ * This primarily classifies capabilities into
+ * a) APIs/ops supported
+ * b) channel physical capabilities
+ *
+ * @ops: or'ed api capability
+ * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ * @seg_len: maximum length of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ */
+struct dmaengine_chan_caps {
+ enum dmaengine_apis ops;
+ int seg_nr;
+ int seg_len;
+};
+
static inline const char *dma_chan_name(struct dma_chan *chan)
{
return dev_name(&chan->dev->device);
@@ -534,6 +566,7 @@ struct dma_tx_state {
* struct with auxiliary transfer status information, otherwise the call
* will just return a simple status code
* @device_issue_pending: push pending transactions to hardware
+ * @device_channel_caps: return the channel capabilities
*/
struct dma_device {
@@ -602,6 +635,8 @@ struct dma_device {
dma_cookie_t cookie,
struct dma_tx_state *txstate);
void (*device_issue_pending)(struct dma_chan *chan);
+ struct dmaengine_chan_caps *(*device_channel_caps)(
+ struct dma_chan *chan, enum dma_transfer_direction direction);
};
static inline int dmaengine_device_control(struct dma_chan *chan,
@@ -969,6 +1004,23 @@ dma_set_tx_state(struct dma_tx_state *st, dma_cookie_t
last, dma_cookie_t used,
}
}
+/**
+ * dma_get_channel_caps - flush pending transactions to HW
+ * @chan: target DMA channel
+ * @dir: direction of transfer
+ *
+ * Get the channel-specific capabilities. If the dmaengine
+ * driver does not implement per channel capbilities then
+ * NULL is returned.
+ */
+static inline struct dmaengine_chan_caps
+*dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir)
+{
+ if (chan->device->device_channel_caps)
+ return chan->device->device_channel_caps(chan, dir);
+ return NULL;
+}
+
enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
#ifdef CONFIG_DMA_ENGINE
enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/3] dmaengine: add per channel capabilities api
This series adds a new dmaengine api, dma_get_channels_caps(), which may be used by a driver to get channel-specific capabilities. This is based on a starting point suggested by Vinod Koul, but only implements the minimal sets of channel capabilities to fulfill the needs of the EDMA DMA Engine driver at this time. Specifically, this implementation supports reporting of a set of transfer type operations, maximum number of SG segments, and the maximum size of an SG segment that a channel can support. The call is implemented as follows: struct dmaengine_chan_caps *dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir); The dma transfer direction parameter may appear a bit out of place but it is necessary since the direction field in struct dma_slave_config was deprecated. In some cases, EDMA for one, it is necessary for the dmaengine driver to have the burst and address width slave configuration parameters available in order to compute the maximum segment size that can be handle. Due to this requirement, the calling order of this api is as follows: 1. Allocate a DMA slave channel 1a. [Optionally] Get channel capabilities 2. Set slave and controller specific parameters 3. Get a descriptor for transaction 4. Submit the transaction 5. Issue pending requests and wait for callback notification Along with the API implementation, this series implements the backend device_channel_caps() in the EDMA DMA Engine driver and converts the davinci_mmc driver to use dma_get_channel_caps() to replace hardcoded limits. This is tested on the AM1808-EVM. Matt Porter (3): dmaengine: add dma_get_channel_caps() dma: edma: add device_channel_caps() support mmc: davinci: get SG segment limits with dma_get_channel_caps() drivers/dma/edma.c| 26 drivers/mmc/host/davinci_mmc.c| 66 + include/linux/dmaengine.h | 52 +++ include/linux/platform_data/mmc-davinci.h |3 -- 4 files changed, 99 insertions(+), 48 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/3] dma: edma: add device_channel_caps() support
Implement device_channel_caps().
EDMA has a finite set of PaRAM slots available for linking
a multi-segment SG transfer. In order to prevent any one
channel from consuming all PaRAM slots to fulfill a large SG
transfer, the driver reports a static per-channel max number
of SG segments it will handle.
The maximum size of SG segment is limited by the slave config
maxburst and addr_width for the channel in question. These values
are used from the current channel config to calculate and return
the max segment length cap.
Signed-off-by: Matt Porter
---
drivers/dma/edma.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 47ba7bf..8b41045 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -70,6 +70,7 @@ struct edma_chan {
boolalloced;
int slot[EDMA_MAX_SLOTS];
struct dma_slave_config cfg;
+ struct dmaengine_chan_caps caps;
};
struct edma_cc {
@@ -462,6 +463,28 @@ static void edma_issue_pending(struct dma_chan *chan)
spin_unlock_irqrestore(&echan->vchan.lock, flags);
}
+static struct dmaengine_chan_caps
+*edma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir)
+{
+ struct edma_chan *echan;
+ enum dma_slave_buswidth width = 0;
+ u32 burst = 0;
+
+ if (chan) {
+ echan = to_edma_chan(chan);
+ if (dir == DMA_MEM_TO_DEV) {
+ width = echan->cfg.dst_addr_width;
+ burst = echan->cfg.dst_maxburst;
+ } else if (dir == DMA_DEV_TO_MEM) {
+ width = echan->cfg.src_addr_width;
+ burst = echan->cfg.src_maxburst;
+ }
+ echan->caps.seg_len = (SZ_64K - 1) * width * burst;
+ return &echan->caps;
+ }
+ return NULL;
+}
+
static size_t edma_desc_size(struct edma_desc *edesc)
{
int i;
@@ -521,6 +544,8 @@ static void __init edma_chan_init(struct edma_cc *ecc,
echan->ch_num = EDMA_CTLR_CHAN(ecc->ctlr, i);
echan->ecc = ecc;
echan->vchan.desc_free = edma_desc_free;
+ echan->caps.ops = DMAENGINE_SLAVE | DMAENGINE_SG;
+ echan->caps.seg_nr = MAX_NR_SG;
vchan_init(&echan->vchan, dma);
@@ -537,6 +562,7 @@ static void edma_dma_init(struct edma_cc *ecc, struct
dma_device *dma,
dma->device_alloc_chan_resources = edma_alloc_chan_resources;
dma->device_free_chan_resources = edma_free_chan_resources;
dma->device_issue_pending = edma_issue_pending;
+ dma->device_channel_caps = edma_get_channel_caps;
dma->device_tx_status = edma_tx_status;
dma->device_control = edma_control;
dma->dev = dev;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 3/3] mmc: davinci: get SG segment limits with dma_get_channel_caps()
Replace the hardcoded values used to set max_segs/max_seg_size with
a dma_get_channel_caps() query to the dmaengine driver.
Signed-off-by: Matt Porter
---
drivers/mmc/host/davinci_mmc.c| 66 +
include/linux/platform_data/mmc-davinci.h |3 --
2 files changed, 21 insertions(+), 48 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index f5d46ea..d1efacc 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -145,18 +145,6 @@
/* MMCSD Init clock in Hz in opendrain mode */
#define MMCSD_INIT_CLOCK 20
-/*
- * One scatterlist dma "segment" is at most MAX_CCNT rw_threshold units,
- * and we handle up to MAX_NR_SG segments. MMC_BLOCK_BOUNCE kicks in only
- * for drivers with max_segs == 1, making the segments bigger (64KB)
- * than the page or two that's otherwise typical. nr_sg (passed from
- * platform data) == 16 gives at least the same throughput boost, using
- * EDMA transfer linkage instead of spending CPU time copying pages.
- */
-#define MAX_CCNT ((1 << 16) - 1)
-
-#define MAX_NR_SG 16
-
static unsigned rw_threshold = 32;
module_param(rw_threshold, uint, S_IRUGO);
MODULE_PARM_DESC(rw_threshold,
@@ -217,8 +205,6 @@ struct mmc_davinci_host {
u8 version;
/* for ns in one cycle calculation */
unsigned ns_in_one_cycle;
- /* Number of sg segments */
- u8 nr_sg;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
@@ -422,16 +408,7 @@ static int mmc_davinci_send_dma_request(struct
mmc_davinci_host *host,
int ret = 0;
if (host->data_dir == DAVINCI_MMC_DATADIR_WRITE) {
- struct dma_slave_config dma_tx_conf = {
- .direction = DMA_MEM_TO_DEV,
- .dst_addr = host->mem_res->start + DAVINCI_MMCDXR,
- .dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
- .dst_maxburst =
- rw_threshold / DMA_SLAVE_BUSWIDTH_4_BYTES,
- };
chan = host->dma_tx;
- dmaengine_slave_config(host->dma_tx, &dma_tx_conf);
-
desc = dmaengine_prep_slave_sg(host->dma_tx,
data->sg,
host->sg_len,
@@ -444,16 +421,7 @@ static int mmc_davinci_send_dma_request(struct
mmc_davinci_host *host,
goto out;
}
} else {
- struct dma_slave_config dma_rx_conf = {
- .direction = DMA_DEV_TO_MEM,
- .src_addr = host->mem_res->start + DAVINCI_MMCDRR,
- .src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
- .src_maxburst =
- rw_threshold / DMA_SLAVE_BUSWIDTH_4_BYTES,
- };
chan = host->dma_rx;
- dmaengine_slave_config(host->dma_rx, &dma_rx_conf);
-
desc = dmaengine_prep_slave_sg(host->dma_rx,
data->sg,
host->sg_len,
@@ -1166,6 +1134,7 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
struct resource *r, *mem = NULL;
int ret = 0, irq = 0;
size_t mem_size;
+ struct dmaengine_chan_caps *dma_chan_caps;
/* REVISIT: when we're fully converted, fail if pdata is NULL */
@@ -1215,12 +1184,6 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
init_mmcsd_host(host);
- if (pdata->nr_sg)
- host->nr_sg = pdata->nr_sg - 1;
-
- if (host->nr_sg > MAX_NR_SG || !host->nr_sg)
- host->nr_sg = MAX_NR_SG;
-
host->use_dma = use_dma;
host->mmc_irq = irq;
host->sdio_irq = platform_get_irq(pdev, 1);
@@ -1249,14 +1212,27 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
mmc->caps |= pdata->caps;
mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
- /* With no iommu coalescing pages, each phys_seg is a hw_seg.
-* Each hw_seg uses one EDMA parameter RAM slot, always one
-* channel and then usually some linked slots.
-*/
- mmc->max_segs = MAX_NR_SG;
+ {
+ struct dma_slave_config dma_txrx_conf = {
+ .src_addr = host->mem_res->start + DAVINCI_MMCDRR,
+ .src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .src_maxburst =
+ rw_threshold / DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .dst_addr = host->mem_res->start + DAVINCI_MMCDXR,
+ .dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .dst_maxburst =
+ rw_threshold / DMA_SLAVE_BUSWIDTH_4_BYTES,
+ };
+ dmaengine_slave_config(host->dm
Re: [PATCH 3/6] mmc: core: sdio_bus.c: Fixed lines > 80 chars
Hi,
your patch[1/3] is also "Fixed lines > 80chars".
Why do you separate with patch[1/6] and patch[3/6]?
Best Regards,
Jaehoon Chung
On 10/19/2012 01:31 AM, Sangho Yi wrote:
> I fixed lines over 80 characters per line.
>
> Signed-off-by: Sangho Yi
> ---
> drivers/mmc/core/sdio_bus.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
> index 13146d2..efa30eb 100644
> --- a/drivers/mmc/core/sdio_bus.c
> +++ b/drivers/mmc/core/sdio_bus.c
> @@ -27,7 +27,7 @@
> /* show configuration fields */
> #define sdio_config_attr(field, format_string)
> \
> static ssize_t
> \
> -field##_show(struct device *dev, struct device_attribute *attr, char *buf)
> \
> +field##_show(struct device *dev, struct device_attribute *attr, char *buf)\
> {\
> struct sdio_func *func; \
> \
> @@ -39,7 +39,8 @@ sdio_config_attr(class, "0x%02x\n");
> sdio_config_attr(vendor, "0x%04x\n");
> sdio_config_attr(device, "0x%04x\n");
>
> -static ssize_t modalias_show(struct device *dev, struct device_attribute
> *attr, char *buf)
> +static ssize_t modalias_show(struct device *dev, struct device_attribute
> *attr,
> + char *buf)
> {
> struct sdio_func *func = dev_to_sdio_func (dev);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/4] sdio: pm: set device's power state after driver runtime suspended it
On Friday 12 of October 2012 11:12:41 Aaron Lu wrote:
> In sdio bus level runtime callback function, after call the driver's
> runtime suspend callback, we will check if the device supports a
> platform level power management, and if so, a proper power state is
> chosen by the corresponding platform callback and then set.
>
> Platform level runtime wakeup is also set, if device is enabled for
> runtime wakeup by its driver, it will be armed the ability to generate
> a wakeup event by the platform.
>
> Signed-off-by: Aaron Lu
> ---
> drivers/mmc/core/sdio_bus.c | 49
> +++--
> 1 file changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
> index aaec9e2..d83dea8 100644
> --- a/drivers/mmc/core/sdio_bus.c
> +++ b/drivers/mmc/core/sdio_bus.c
> @@ -23,6 +23,7 @@
>
> #include "sdio_cis.h"
> #include "sdio_bus.h"
> +#include "sdio.h"
> #include "sdio_acpi.h"
>
> /* show configuration fields */
> @@ -194,10 +195,54 @@ static int sdio_bus_remove(struct device *dev)
> }
>
> #ifdef CONFIG_PM
> +
> +static int sdio_bus_runtime_suspend(struct device *dev)
> +{
> + int ret;
> + sdio_power_t state;
> +
> + ret = pm_generic_runtime_suspend(dev);
> + if (ret)
> + goto out;
> +
> + if (!platform_sdio_power_manageable(dev))
> + goto out;
> +
> + platform_sdio_run_wake(dev, true);
> +
> + state = platform_sdio_choose_power_state(dev);
> + if (state == SDIO_POWER_ERROR) {
> + ret = -EIO;
> + goto out;
> + }
> +
> + ret = platform_sdio_set_power_state(dev, state);
> +
> +out:
> + return ret;
> +}
> +
> +static int sdio_bus_runtime_resume(struct device *dev)
> +{
> + int ret;
> +
> + if (platform_sdio_power_manageable(dev)) {
> + platform_sdio_run_wake(dev, false);
> + ret = platform_sdio_set_power_state(dev, SDIO_D0);
> + if (ret)
> + goto out;
> + }
> +
> + ret = pm_generic_runtime_resume(dev);
> +
> +out:
> + return ret;
> +}
> +
Most likely we will need to make analogous changes for other bus types that
don't support power management natively, like platform, SPI, I2C etc. In all
of them the _runtime_suspend() and _runtime_resume() routine will look
almost exactly the same except for the platform_sdio_ prefix.
For this reason, I think it would be better to simply define two functions
acpi_pm_runtime_suspend() and acpi_pm_runtime_resume() that will do all of
the ACPI-specific operations related to runtime suspend/resume. Then, we
will be able to use these functions for all of the bus types in question
in the same way (we may also need to add analogous functions for system
suspend/resume handling).
If we do that, then the sdio_platform_pm_ops structure from the previous
patch won't be necessary any more.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/4] sdio: introduce sdio_platform_pm_ops
On Friday 12 of October 2012 11:12:40 Aaron Lu wrote: > Some platform has the ability to set the sdio device into a low power > state with some specific method, e.g. ACPI on x86 based system can use > acpi control methods to change the device's power state. > > Considering there may be different platforms utilizing different > mechanisms to achieve this, a new structure is introduced to let > individual platform to use these callbacks to do the job. > > The structure contains 4 callbacks: > - is_manageable > return true when the platform can manage the device's power; > return false otherwise. > - choose_state > Choose a proper power state for the device > - set_state > Set the device's power state > - run_wake > Enable the device's runtime wakeup capability from the platform's > perspective. > > And 4 functions to wrap these callbacks: > - bool platform_sdio_power_manageable(struct device *dev) > - int platform_sdio_choose_power_state(struct device *dev) > - int platform_sdio_set_power_state(struct device *dev, int state) > - int platform_sdio_run_wake(struct device *dev, bool enable) > So when these callbacks are desired, these wrapper functions should be > used. And if someday some sdio function driver which lives out of the > mmc subsystem has a need to use these wrapper functions, they can be > exported. > > sdio_acpi.c implements these callbacks utilizing ACPI code. > > The idea of this patch and the definition/wrapper of these callbacks > are heavily based on the one used in PCI subsystem. > > Signed-off-by: Aaron Lu I'm not really sure if we need to make it so complicated. Please see my comments on the next patch. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/4] mmc: sdio: bind sdio device with acpi device
On Friday 12 of October 2012 11:12:39 Aaron Lu wrote:
> ACPI spec defines the _ADDR encoding for sdio bus as:
> High word - slot number (0 based)
> Low word - function number
>
> This patch adds support for sdio device binding with acpi using the
> generic ACPI glue framework.
>
> Signed-off-by: Aaron Lu
> ---
> drivers/mmc/core/Makefile| 1 +
> drivers/mmc/core/sdio_acpi.c | 35 +++
> drivers/mmc/core/sdio_bus.c | 14 --
> drivers/mmc/core/sdio_bus.h | 2 ++
> 4 files changed, 50 insertions(+), 2 deletions(-)
> create mode 100644 drivers/mmc/core/sdio_acpi.c
>
> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
> index 38ed210..c8300aa 100644
> --- a/drivers/mmc/core/Makefile
> +++ b/drivers/mmc/core/Makefile
> @@ -10,3 +10,4 @@ mmc_core-y := core.o bus.o host.o \
> quirks.o slot-gpio.o
>
> mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
> +mmc_core-$(CONFIG_ACPI) += sdio_acpi.o
> diff --git a/drivers/mmc/core/sdio_acpi.c b/drivers/mmc/core/sdio_acpi.c
> new file mode 100644
> index 000..0f92e90
> --- /dev/null
> +++ b/drivers/mmc/core/sdio_acpi.c
> @@ -0,0 +1,35 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "sdio_bus.h"
> +
> +static int acpi_sdio_find_device(struct device *dev, acpi_handle *handle)
> +{
> + struct sdio_func *func;
> + struct sdhci_host *host;
> + u64 addr;
> +
> + func = dev_to_sdio_func(dev);
> + host = mmc_priv(func->card->host);
> +
> + addr = (host->slotno << 16) | func->num;
> +
> + *handle = acpi_get_child(DEVICE_ACPI_HANDLE(dev), addr);
> + if (!*handle)
> + return -ENODEV;
> +
> + return 0;
> +}
> +
> +static struct acpi_bus_type acpi_sdio_bus = {
> + .bus = &sdio_bus_type,
> + .find_device = acpi_sdio_find_device,
> +};
> +
> +int sdio_acpi_register(void)
I'd call it sdio_acpi_register_bus().
> +{
> + return register_acpi_bus_type(&acpi_sdio_bus);
> +}
> diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
> index 6bf6879..aaec9e2 100644
> --- a/drivers/mmc/core/sdio_bus.c
> +++ b/drivers/mmc/core/sdio_bus.c
> @@ -23,6 +23,7 @@
>
> #include "sdio_cis.h"
> #include "sdio_bus.h"
> +#include "sdio_acpi.h"
>
> /* show configuration fields */
> #define sdio_config_attr(field, format_string)
> \
> @@ -209,7 +210,7 @@ static const struct dev_pm_ops sdio_bus_pm_ops = {
>
> #endif /* !CONFIG_PM */
>
> -static struct bus_type sdio_bus_type = {
> +struct bus_type sdio_bus_type = {
> .name = "sdio",
> .dev_attrs = sdio_dev_attrs,
> .match = sdio_bus_match,
> @@ -221,7 +222,16 @@ static struct bus_type sdio_bus_type = {
>
> int sdio_register_bus(void)
> {
> - return bus_register(&sdio_bus_type);
> + int ret;
> +
> + ret = bus_register(&sdio_bus_type);
> + if (ret)
> + goto out;
> +
> + ret = sdio_acpi_register();
What happens if this fails?
> +
> +out:
> + return ret;
> }
>
> void sdio_unregister_bus(void)
> diff --git a/drivers/mmc/core/sdio_bus.h b/drivers/mmc/core/sdio_bus.h
> index 567a768..91c0e93 100644
> --- a/drivers/mmc/core/sdio_bus.h
> +++ b/drivers/mmc/core/sdio_bus.h
> @@ -18,5 +18,7 @@ void sdio_remove_func(struct sdio_func *func);
> int sdio_register_bus(void);
> void sdio_unregister_bus(void);
>
> +extern struct bus_type sdio_bus_type;
> +
> #endif
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mmc: core: sd.c: Added a space after comma on an argument definition
On Fri, 2012-10-19 at 02:19 +0900, Sangho Yi wrote:
> Added a space between comma and an argument on the function definition
Hi Sangho.
Please don't just be a checkpatch robot, but look at the
code and see if you can improve it.
> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
> index 74972c2..91a73d7 100644
> --- a/drivers/mmc/core/sd.c
> +++ b/drivers/mmc/core/sd.c
> @@ -44,7 +44,7 @@ static const unsigned int tacc_mant[] = {
> 35, 40, 45, 50, 55, 60, 70, 80,
> };
>
> -#define UNSTUFF_BITS(resp,start,size)
> \
> +#define UNSTUFF_BITS(resp, start, size)
> \
> ({ \
> const int __size = size;\
> const u32 __mask = (__size < 32 ? 1 << __size : 0) - 1; \
I'd prefer that UNSTUFF_BITS be converted from
a statement expression macro to a proper function.
Something like:
drivers/mmc/core/sd.c | 118 +-
1 file changed, 59 insertions(+), 59 deletions(-)
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 74972c2..ec32ba48 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -44,19 +44,19 @@ static const unsigned int tacc_mant[] = {
35, 40, 45, 50, 55, 60, 70, 80,
};
-#define UNSTUFF_BITS(resp,start,size) \
- ({ \
- const int __size = size;\
- const u32 __mask = (__size < 32 ? 1 << __size : 0) - 1; \
- const int __off = 3 - ((start) / 32); \
- const int __shft = (start) & 31;\
- u32 __res; \
- \
- __res = resp[__off] >> __shft; \
- if (__size + __shft > 32) \
- __res |= resp[__off-1] << ((32 - __shft) % 32); \
- __res & __mask; \
- })
+static __always_inline u32 unstuff_bits(u32 resp[4], int start, int size)
+{
+ const u32 mask = (size < 32 ? 1 << size : 0) - 1;
+ const int offset = 3 - (start / 32);
+ const int shift = start & 31;
+ u32 res;
+
+ res = resp[offset] >> shift;
+ if (size + shift > 32)
+ res |= resp[offset - 1] << ((32 - shift) % 32);
+
+ return res & mask;
+}
/*
* Given the decoded CSD structure, decode the raw CID to our CID structure.
@@ -71,18 +71,18 @@ void mmc_decode_cid(struct mmc_card *card)
* SD doesn't currently have a version field so we will
* have to assume we can parse this.
*/
- card->cid.manfid= UNSTUFF_BITS(resp, 120, 8);
- card->cid.oemid = UNSTUFF_BITS(resp, 104, 16);
- card->cid.prod_name[0] = UNSTUFF_BITS(resp, 96, 8);
- card->cid.prod_name[1] = UNSTUFF_BITS(resp, 88, 8);
- card->cid.prod_name[2] = UNSTUFF_BITS(resp, 80, 8);
- card->cid.prod_name[3] = UNSTUFF_BITS(resp, 72, 8);
- card->cid.prod_name[4] = UNSTUFF_BITS(resp, 64, 8);
- card->cid.hwrev = UNSTUFF_BITS(resp, 60, 4);
- card->cid.fwrev = UNSTUFF_BITS(resp, 56, 4);
- card->cid.serial= UNSTUFF_BITS(resp, 24, 32);
- card->cid.year = UNSTUFF_BITS(resp, 12, 8);
- card->cid.month = UNSTUFF_BITS(resp, 8, 4);
+ card->cid.manfid= unstuff_bits(resp, 120, 8);
+ card->cid.oemid = unstuff_bits(resp, 104, 16);
+ card->cid.prod_name[0] = unstuff_bits(resp, 96, 8);
+ card->cid.prod_name[1] = unstuff_bits(resp, 88, 8);
+ card->cid.prod_name[2] = unstuff_bits(resp, 80, 8);
+ card->cid.prod_name[3] = unstuff_bits(resp, 72, 8);
+ card->cid.prod_name[4] = unstuff_bits(resp, 64, 8);
+ card->cid.hwrev = unstuff_bits(resp, 60, 4);
+ card->cid.fwrev = unstuff_bits(resp, 56, 4);
+ card->cid.serial= unstuff_bits(resp, 24, 32);
+ card->cid.year = unstuff_bits(resp, 12, 8);
+ card->cid.month = unstuff_bits(resp, 8, 4);
card->cid.year += 2000; /* SD cards year offset */
}
@@ -96,36 +96,36 @@ static int mmc_decode_csd(struct mmc_card *card)
unsigned int e, m, csd_struct;
u32 *resp = card->raw_csd;
- csd_struct = UNSTUFF_BITS(resp, 126, 2);
+ csd_struct = unstuff_bits(resp, 126, 2);
swi
[PATCH 3/4] mmc: core: sd.c: Modified pr_warning to pr_warn
Fixed the coding style warning;
from pr_warning(...) to pr_warn(...)
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sd.c | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 7c6b38e..0622b9b 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -219,7 +219,7 @@ static int mmc_read_ssr(struct mmc_card *card)
u32 *ssr;
if (!(card->csd.cmdclass & CCC_APP_SPEC)) {
- pr_warning("%s: card lacks mandatory SD Status "
+ pr_warn("%s: card lacks mandatory SD Status "
"function.\n", mmc_hostname(card->host));
return 0;
}
@@ -230,7 +230,7 @@ static int mmc_read_ssr(struct mmc_card *card)
err = mmc_app_sd_status(card, ssr);
if (err) {
- pr_warning("%s: problem reading SD Status "
+ pr_warn("%s: problem reading SD Status "
"register.\n", mmc_hostname(card->host));
err = 0;
goto out;
@@ -254,7 +254,7 @@ static int mmc_read_ssr(struct mmc_card *card)
card->ssr.erase_offset = eo * 1000;
}
} else {
- pr_warning("%s: SD Status: Invalid Allocation Unit "
+ pr_warn("%s: SD Status: Invalid Allocation Unit "
"size.\n", mmc_hostname(card->host));
}
out:
@@ -274,7 +274,7 @@ static int mmc_read_switch(struct mmc_card *card)
return 0;
if (!(card->csd.cmdclass & CCC_SWITCH)) {
- pr_warning("%s: card lacks mandatory switch "
+ pr_warn("%s: card lacks mandatory switch "
"function, performance might suffer.\n",
mmc_hostname(card->host));
return 0;
@@ -304,8 +304,8 @@ static int mmc_read_switch(struct mmc_card *card)
if (err != -EINVAL && err != -ENOSYS && err != -EFAULT)
goto out;
- pr_warning("%s: problem reading Bus Speed modes.\n",
- mmc_hostname(card->host));
+ pr_warn("%s: problem reading Bus Speed modes.\n",
+ mmc_hostname(card->host));
err = 0;
goto out;
@@ -360,8 +360,7 @@ int mmc_sd_switch_hs(struct mmc_card *card)
goto out;
if ((status[16] & 0xF) != 1) {
- pr_warning("%s: Problem switching card "
- "into high-speed mode!\n",
+ pr_warn("%s: Problem switching card into high-speed mode!\n",
mmc_hostname(card->host));
err = 0;
} else {
@@ -428,8 +427,8 @@ static int sd_select_driver_type(struct mmc_card *card, u8
*status)
return err;
if ((status[15] & 0xF) != drive_strength) {
- pr_warning("%s: Problem setting drive strength!\n",
- mmc_hostname(card->host));
+ pr_warn("%s: Problem setting drive strength!\n",
+ mmc_hostname(card->host));
return 0;
}
@@ -507,8 +506,8 @@ static int sd_set_bus_speed_mode(struct mmc_card *card, u8
*status)
return err;
if ((status[16] & 0xF) != card->sd_bus_speed)
- pr_warning("%s: Problem setting bus speed mode!\n",
- mmc_hostname(card->host));
+ pr_warn("%s: Problem setting bus speed mode!\n",
+ mmc_hostname(card->host));
else {
mmc_set_timing(card->host, timing);
mmc_set_clock(card->host, card->sw_caps.uhs_max_dtr);
@@ -587,8 +586,8 @@ static int sd_set_current_limit(struct mmc_card *card, u8
*status)
return err;
if (((status[15] >> 4) & 0x0F) != current_limit)
- pr_warning("%s: Problem setting current limit!\n",
- mmc_hostname(card->host));
+ pr_warn("%s: Problem setting current limit!\n",
+ mmc_hostname(card->host));
}
@@ -852,7 +851,7 @@ int mmc_sd_setup_card(struct mmc_host *host, struct
mmc_card *card,
}
if (ro < 0) {
- pr_warning("%s: host does not "
+ pr_warn("%s: host does not "
"support reading read-only "
"switch. assuming write-enable.\n",
mmc_hostname(host));
@@ -1179,17 +1178,17 @@ int mmc_attach_sd(struct mmc_host *host)
* support.
*/
if (ocr & 0x7F) {
- pr_warning("%s: card claims to support voltages "
- "below the defined range. These will be ignored.\n",
- mmc_hostname(host));
+ pr_war
[PATCH 2/4] mmc: core: sd.c: Made alignment for the multiline function calls
I made the alignment based on the strict coding style as follows;
CHECK: Alignment should match open parenthesis
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sd.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 91a73d7..7c6b38e 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -165,7 +165,7 @@ static int mmc_decode_csd(struct mmc_card *card)
break;
default:
pr_err("%s: unrecognised CSD structure version %d\n",
- mmc_hostname(card->host), csd_struct);
+ mmc_hostname(card->host), csd_struct);
return -EINVAL;
}
@@ -189,7 +189,7 @@ static int mmc_decode_scr(struct mmc_card *card)
scr_struct = UNSTUFF_BITS(resp, 60, 4);
if (scr_struct != 0) {
pr_err("%s: unrecognised SCR structure version %d\n",
- mmc_hostname(card->host), scr_struct);
+ mmc_hostname(card->host), scr_struct);
return -EINVAL;
}
@@ -305,7 +305,7 @@ static int mmc_read_switch(struct mmc_card *card)
goto out;
pr_warning("%s: problem reading Bus Speed modes.\n",
- mmc_hostname(card->host));
+ mmc_hostname(card->host));
err = 0;
goto out;
@@ -429,7 +429,7 @@ static int sd_select_driver_type(struct mmc_card *card, u8
*status)
if ((status[15] & 0xF) != drive_strength) {
pr_warning("%s: Problem setting drive strength!\n",
- mmc_hostname(card->host));
+ mmc_hostname(card->host));
return 0;
}
@@ -508,7 +508,7 @@ static int sd_set_bus_speed_mode(struct mmc_card *card, u8
*status)
if ((status[16] & 0xF) != card->sd_bus_speed)
pr_warning("%s: Problem setting bus speed mode!\n",
- mmc_hostname(card->host));
+ mmc_hostname(card->host));
else {
mmc_set_timing(card->host, timing);
mmc_set_clock(card->host, card->sw_caps.uhs_max_dtr);
@@ -588,7 +588,7 @@ static int sd_set_current_limit(struct mmc_card *card, u8
*status)
if (((status[15] >> 4) & 0x0F) != current_limit)
pr_warning("%s: Problem setting current limit!\n",
- mmc_hostname(card->host));
+ mmc_hostname(card->host));
}
@@ -662,9 +662,9 @@ out:
}
MMC_DEV_ATTR(cid, "%08x%08x%08x%08x\n", card->raw_cid[0], card->raw_cid[1],
- card->raw_cid[2], card->raw_cid[3]);
+card->raw_cid[2], card->raw_cid[3]);
MMC_DEV_ATTR(csd, "%08x%08x%08x%08x\n", card->raw_csd[0], card->raw_csd[1],
- card->raw_csd[2], card->raw_csd[3]);
+card->raw_csd[2], card->raw_csd[3]);
MMC_DEV_ATTR(scr, "%08x%08x\n", card->raw_scr[0], card->raw_scr[1]);
MMC_DEV_ATTR(date, "%02d/%04d\n", card->cid.month, card->cid.year);
MMC_DEV_ATTR(erase_size, "%u\n", card->erase_size << 9);
@@ -758,7 +758,7 @@ try_again:
* Switch procedure. SPI mode doesn't support CMD11.
*/
if (!mmc_host_is_spi(host) && rocr &&
- ((*rocr & 0x4100) == 0x4100)) {
+ ((*rocr & 0x4100) == 0x4100)) {
err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180,
true);
if (err) {
ocr &= ~SD_OCR_S18R;
@@ -989,7 +989,7 @@ static int mmc_sd_init_card(struct mmc_host *host, u32 ocr,
* Switch to wider bus (if supported).
*/
if ((host->caps & MMC_CAP_4_BIT_DATA) &&
- (card->scr.bus_widths & SD_SCR_BUS_WIDTH_4)) {
+ (card->scr.bus_widths & SD_SCR_BUS_WIDTH_4)) {
err = mmc_app_set_bus_width(card, MMC_BUS_WIDTH_4);
if (err)
goto free_card;
@@ -1227,7 +1227,7 @@ err:
mmc_detach_bus(host);
pr_err("%s: error %d whilst initialising SD card\n",
- mmc_hostname(host), err);
+ mmc_hostname(host), err);
return err;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] mmc: core: sd.c: Fixed line over 80 chars
Fixed line over 80 characters per line.
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sd.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 0622b9b..ff82b7d 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -758,7 +758,8 @@ try_again:
*/
if (!mmc_host_is_spi(host) && rocr &&
((*rocr & 0x4100) == 0x4100)) {
- err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180,
true);
+ err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180,
+true);
if (err) {
ocr &= ~SD_OCR_S18R;
goto try_again;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] mmc: core: sd.c: Added a space after comma on an argument definition
Added a space between comma and an argument on the function definition
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 74972c2..91a73d7 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -44,7 +44,7 @@ static const unsigned int tacc_mant[] = {
35, 40, 45, 50, 55, 60, 70, 80,
};
-#define UNSTUFF_BITS(resp,start,size) \
+#define UNSTUFF_BITS(resp, start, size)
\
({ \
const int __size = size;\
const u32 __mask = (__size < 32 ? 1 << __size : 0) - 1; \
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] mmc: core: sdio_bus.c: Fixed lines > 80 chars
I fixed lines over 80 characters per line.
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sdio_bus.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
index 13146d2..efa30eb 100644
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -27,7 +27,7 @@
/* show configuration fields */
#define sdio_config_attr(field, format_string) \
static ssize_t \
-field##_show(struct device *dev, struct device_attribute *attr, char *buf)
\
+field##_show(struct device *dev, struct device_attribute *attr, char *buf)\
{ \
struct sdio_func *func; \
\
@@ -39,7 +39,8 @@ sdio_config_attr(class, "0x%02x\n");
sdio_config_attr(vendor, "0x%04x\n");
sdio_config_attr(device, "0x%04x\n");
-static ssize_t modalias_show(struct device *dev, struct device_attribute
*attr, char *buf)
+static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
struct sdio_func *func = dev_to_sdio_func (dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] mmc: core: sdio_bus.c: Removed space between func name and ()
Fixed a coding style warning like this:
from foo (arg) --> to foo(arg)
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sdio_bus.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
index efa30eb..1a1d96c 100644
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -31,8 +31,8 @@ field##_show(struct device *dev, struct device_attribute
*attr, char *buf)\
{ \
struct sdio_func *func; \
\
- func = dev_to_sdio_func (dev); \
- return sprintf (buf, format_string, func->field); \
+ func = dev_to_sdio_func(dev); \
+ return sprintf(buf, format_string, func->field);\
}
sdio_config_attr(class, "0x%02x\n");
@@ -42,7 +42,7 @@ sdio_config_attr(device, "0x%04x\n");
static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
- struct sdio_func *func = dev_to_sdio_func (dev);
+ struct sdio_func *func = dev_to_sdio_func(dev);
return sprintf(buf, "sdio:c%02Xv%04Xd%04X\n",
func->class, func->vendor, func->device);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] mmc: core: sdio_bus.c: Fixed a warning for the pr_warning(...
I fixed a line which had the following warning:
WARNING: Prefer pr_warn(... to pr_warning(...
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sdio_bus.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
index 1a1d96c..e5b7197 100644
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -175,7 +175,7 @@ static int sdio_bus_remove(struct device *dev)
drv->remove(func);
if (func->irq_handler) {
- pr_warning("WARNING: driver %s did not remove "
+ pr_warn("WARNING: driver %s did not remove "
"its interrupt handler!\n", drv->name);
sdio_claim_host(func);
sdio_release_irq(func);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mmc: core: sdio_cis.c: Fixed the position of opening braces {
I fixed the following coding style error:
ERROR: that open brace { should be on the previous line
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sdio_cis.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/core/sdio_cis.c b/drivers/mmc/core/sdio_cis.c
index e4221df..c81cda3 100644
--- a/drivers/mmc/core/sdio_cis.c
+++ b/drivers/mmc/core/sdio_cis.c
@@ -93,11 +93,10 @@ static int cistpl_manfid(struct mmc_card *card, struct
sdio_func *func,
return 0;
}
-static const unsigned char speed_val[16] =
- { 0, 10, 12, 13, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 70, 80 };
-static const unsigned int speed_unit[8] =
- { 1, 10, 100, 1000, 0, 0, 0, 0 };
-
+static const unsigned char speed_val[16] = { 0, 10, 12, 13, 15, 20, 25, 30, 35,
+ 40, 45, 50, 55, 60, 70, 80 };
+static const unsigned int speed_unit[8] = { 1, 10, 100, 1000,
+ 0, 0, 0, 0 };
typedef int (tpl_parse_t)(struct mmc_card *, struct sdio_func *,
const unsigned char *, unsigned);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] mmc: core: sdio_cis.c: Fixed pointer casting coding style error
I fixed the following two kinds of errors on coding style.
ERROR: "(foo*)" should be "(foo *)"
ERROR: "(foo**)" should be "(foo **)"
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sdio_cis.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/core/sdio_cis.c b/drivers/mmc/core/sdio_cis.c
index 8e94e55..e4221df 100644
--- a/drivers/mmc/core/sdio_cis.c
+++ b/drivers/mmc/core/sdio_cis.c
@@ -47,11 +47,11 @@ static int cistpl_vers_1(struct mmc_card *card, struct
sdio_func *func,
size = i;
- buffer = kzalloc(sizeof(char*) * nr_strings + size, GFP_KERNEL);
+ buffer = kzalloc(sizeof(char *) * nr_strings + size, GFP_KERNEL);
if (!buffer)
return -ENOMEM;
- string = (char*)(buffer + nr_strings);
+ string = (char *)(buffer + nr_strings);
for (i = 0; i < nr_strings; i++) {
buffer[i] = string;
@@ -62,10 +62,10 @@ static int cistpl_vers_1(struct mmc_card *card, struct
sdio_func *func,
if (func) {
func->num_info = nr_strings;
- func->info = (const char**)buffer;
+ func->info = (const char **)buffer;
} else {
card->num_info = nr_strings;
- card->info = (const char**)buffer;
+ card->info = (const char **)buffer;
}
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] mmc: core: sdio_io.c: Fixed lines with > 80 chars
On Fri, 2012-10-19 at 01:31 +0900, Sangho Yi wrote:
> I fixed lines over 80 characters per line.
If you really must do these things, please use
checkpatch.pl --strict for guidance on how to align
function arguments.
> diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
[]
> @@ -664,7 +665,8 @@ void sdio_f0_writeb(struct sdio_func *func, unsigned char
> b, unsigned int addr,
>
> BUG_ON(!func);
>
> - if ((addr < 0xF0 || addr > 0xFF) &&
> (!mmc_card_lenient_fn0(func->card))) {
> + if ((addr < 0xF0 || addr > 0xFF) &&
> + (!mmc_card_lenient_fn0(func->card))) {
ugly alignment and unnecessary parenthesis too.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] mmc: core: sdio_bus.c: Fixed a warning for the pr_warning(...
I fixed a line which had the following warning:
WARNING: Prefer pr_warn(... to pr_warning(...
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sdio_bus.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
index 1a1d96c..e5b7197 100644
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -175,7 +175,7 @@ static int sdio_bus_remove(struct device *dev)
drv->remove(func);
if (func->irq_handler) {
- pr_warning("WARNING: driver %s did not remove "
+ pr_warn("WARNING: driver %s did not remove "
"its interrupt handler!\n", drv->name);
sdio_claim_host(func);
sdio_release_irq(func);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] mmc: core: sdio_bus.c: Fixed lines > 80 chars
I fixed lines over 80 characters per line.
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sdio_bus.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
index 13146d2..efa30eb 100644
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -27,7 +27,7 @@
/* show configuration fields */
#define sdio_config_attr(field, format_string) \
static ssize_t \
-field##_show(struct device *dev, struct device_attribute *attr, char *buf)
\
+field##_show(struct device *dev, struct device_attribute *attr, char *buf)\
{ \
struct sdio_func *func; \
\
@@ -39,7 +39,8 @@ sdio_config_attr(class, "0x%02x\n");
sdio_config_attr(vendor, "0x%04x\n");
sdio_config_attr(device, "0x%04x\n");
-static ssize_t modalias_show(struct device *dev, struct device_attribute
*attr, char *buf)
+static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
struct sdio_func *func = dev_to_sdio_func (dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] mmc: core: sdio_bus.c: Removed space between func name and ()
Fixed a coding style warning like this:
from foo (arg) --> to foo(arg)
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sdio_bus.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
index efa30eb..1a1d96c 100644
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -31,8 +31,8 @@ field##_show(struct device *dev, struct device_attribute
*attr, char *buf)\
{ \
struct sdio_func *func; \
\
- func = dev_to_sdio_func (dev); \
- return sprintf (buf, format_string, func->field); \
+ func = dev_to_sdio_func(dev); \
+ return sprintf(buf, format_string, func->field);\
}
sdio_config_attr(class, "0x%02x\n");
@@ -42,7 +42,7 @@ sdio_config_attr(device, "0x%04x\n");
static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
- struct sdio_func *func = dev_to_sdio_func (dev);
+ struct sdio_func *func = dev_to_sdio_func(dev);
return sprintf(buf, "sdio:c%02Xv%04Xd%04X\n",
func->class, func->vendor, func->device);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] drivers: mmc: core: sdio.c: fixed coding style error on for() statement
On 18 Oct 2012, at 17:06, Sangho Yi wrote:
> add a whitespace after ";" on for statement, to follow a coding style
> guideline.
>
> Signed-off-by: Sangho Yi
> ---
> drivers/mmc/core/sdio.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index 14326e8..df09b63 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -819,7 +819,7 @@ static void mmc_sdio_remove(struct mmc_host *host)
> BUG_ON(!host);
> BUG_ON(!host->card);
>
> - for (i = 0;i < host->card->sdio_funcs;i++) {
> + for (i = 0; i < host->card->sdio_funcs; i++) {
> if (host->card->sdio_func[i]) {
> sdio_remove_func(host->card->sdio_func[i]);
> host->card->sdio_func[i] = NULL;
> @@ -1151,7 +1151,7 @@ int mmc_attach_sdio(struct mmc_host *host)
> /*
>* ...then the SDIO functions.
>*/
> - for (i = 0;i < funcs;i++) {
> + for (i = 0; i < funcs; i++) {
> err = sdio_add_func(host->card->sdio_func[i]);
> if (err)
> goto remove_added;
> --
> 1.7.9.5
>
> --
Reviewed-by: Philip Rakity
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] drivers: mmc: core: sdio.c: fixed from pr_warning(... to pr_warn(...
Replaced pr_warning(... to pr_warn(... on sdio.c
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sdio.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index df09b63..889d3da 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -220,7 +220,7 @@ static int sdio_enable_wide(struct mmc_card *card)
return ret;
if ((ctrl & SDIO_BUS_WIDTH_MASK) == SDIO_BUS_WIDTH_RESERVED)
- pr_warning("%s: SDIO_CCCR_IF is invalid: 0x%02x\n",
+ pr_warn("%s: SDIO_CCCR_IF is invalid: 0x%02x\n",
mmc_hostname(card->host), ctrl);
/* set as 4-bit bus width */
@@ -1068,7 +1068,7 @@ int mmc_attach_sdio(struct mmc_host *host)
* support.
*/
if (ocr & 0x7F) {
- pr_warning("%s: card claims to support voltages "
+ pr_warn("%s: card claims to support voltages "
"below the defined range. These will be ignored.\n",
mmc_hostname(host));
ocr &= ~0x7F;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] drivers: mmc: core: sdio.c: fixed coding style error on for() statement
add a whitespace after ";" on for statement, to follow a coding style guideline.
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sdio.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 14326e8..df09b63 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -819,7 +819,7 @@ static void mmc_sdio_remove(struct mmc_host *host)
BUG_ON(!host);
BUG_ON(!host->card);
- for (i = 0;i < host->card->sdio_funcs;i++) {
+ for (i = 0; i < host->card->sdio_funcs; i++) {
if (host->card->sdio_func[i]) {
sdio_remove_func(host->card->sdio_func[i]);
host->card->sdio_func[i] = NULL;
@@ -1151,7 +1151,7 @@ int mmc_attach_sdio(struct mmc_host *host)
/*
* ...then the SDIO functions.
*/
- for (i = 0;i < funcs;i++) {
+ for (i = 0; i < funcs; i++) {
err = sdio_add_func(host->card->sdio_func[i]);
if (err)
goto remove_added;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] drivers: mmc: core: sdio.c: fixed lines with > 80 chars
Fixed coding style warning cases for exceeding 80 chars per line on
sdio.c.
Signed-off-by: Sangho Yi
---
drivers/mmc/core/sdio.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 2273ce6..14326e8 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -47,7 +47,8 @@ static int sdio_read_fbr(struct sdio_func *func)
if (data == 0x0f) {
ret = mmc_io_rw_direct(func->card, 0, 0,
- SDIO_FBR_BASE(func->num) + SDIO_FBR_STD_IF_EXT, 0,
&data);
+ SDIO_FBR_BASE(func->num) + SDIO_FBR_STD_IF_EXT,
+ 0, &data);
if (ret)
goto out;
}
@@ -619,7 +620,8 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32
ocr,
card->type = MMC_TYPE_SD_COMBO;
if (oldcard && (oldcard->type != MMC_TYPE_SD_COMBO ||
- memcmp(card->raw_cid, oldcard->raw_cid,
sizeof(card->raw_cid)) != 0)) {
+ memcmp(card->raw_cid, oldcard->raw_cid,
+ sizeof(card->raw_cid)) != 0)) {
mmc_remove_card(card);
return -ENOENT;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
On 18 October 2012 20:48, Huang Shijie wrote: > On Thu, Oct 18, 2012 at 5:29 AM, Jassi Brar > wrote: >> On 18 October 2012 12:15, Huang Shijie wrote: >>> 于 2012年10月18日 14:18, Vinod Koul 写道: >>> Why cant you do start (prepare clock etc) when you submit the descriptor to dmaengine. Can be done in tx_submit callback. Similarly remove the clock when dma transaction gets completed. >>> >>> I ever thought this method too. >>> >>> But it will become low efficient in the following case: >>> >>> Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ >>> read operation. >>> The gpmi-nand will submit the descriptor to dmaengine per page. So with your >>> method, >>> the system will repeat the enable/disable dma clock 1024 time. At every >>> enable/disable dma clock, >>> the system has to enable the clock chain and it's parents ... >>> >>> But with this patch, we only need to enable/disable dma clock one time, just >>> at we select the nand chip. >>> >> If the clock is the dmac's property (not channels'), the toggling >> seems too aggressive. >> You could try using runtime_suspend/resume for clock >> disabling/enabling. How about employing autosuspend with a few ms >> delay? > > Yes, employing the autosuspend is workable method too.o > But it's a little more complicated then this patch. You have to create > a thread or workqueue to > do the job. > I am not sure why you would need to create any thread/workqueue ? Just pm_runtime_put_autosuspend() in drivers/ to see how it works. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
On Thu, Oct 18, 2012 at 5:29 AM, Jassi Brar wrote: > On 18 October 2012 12:15, Huang Shijie wrote: >> 于 2012年10月18日 14:18, Vinod Koul 写道: >> >>> Why cant you do start (prepare clock etc) when you submit the descriptor >>> to dmaengine. Can be done in tx_submit callback. >>> Similarly remove the clock when dma transaction gets completed. >> >> I ever thought this method too. >> >> But it will become low efficient in the following case: >> >> Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ >> read operation. >> The gpmi-nand will submit the descriptor to dmaengine per page. So with your >> method, >> the system will repeat the enable/disable dma clock 1024 time. At every >> enable/disable dma clock, >> the system has to enable the clock chain and it's parents ... >> >> But with this patch, we only need to enable/disable dma clock one time, just >> at we select the nand chip. >> > If the clock is the dmac's property (not channels'), the toggling > seems too aggressive. > You could try using runtime_suspend/resume for clock > disabling/enabling. How about employing autosuspend with a few ms > delay? Yes, employing the autosuspend is workable method too.o But it's a little more complicated then this patch. You have to create a thread or workqueue to do the job. What's more, I think other DMA engine may also meets the same issue as the mxs-dma, such as the imx-sdma. It's somehow a common issue to disable the clocks when no one use the DMA engine. Do you also suggest employing the autosuspend? Why not use a simple way to handle this issue? When the dma device want to use a DMA engine, it just needs to issue a DMA_START command. thanks Huang Shijie Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
On Thu, Oct 18, 2012 at 6:51 AM, Marek Vasut wrote: > Dear Huang Shijie, > >> 于 2012年10月18日 16:49, Marek Vasut 写道: >> > Dear Huang Shijie, >> > >> >> 于 2012年10月18日 16:16, Marek Vasut 写道: >> >>> So we can't stream data from the chip? About time to adjust the MTD >> >>> framework to allow that. Maybe implement a command queue? >> >> >> >> IMHO, it's not possible. Because the READ-PAGE(00h-30h) command needs to >> >> check the busy status >> >> which means we have to stop in the middle, so we can not chain the all >> >> the read-pages DMA commands. >> > >> > Can the DMA not branch? >> >> it's too complicated to the MTD layer, as well as the gpmi driver. > > Can you please elaborate ? could you read the nand spec about how to read a page out with the READ-PAGE(00-30) command, and tell me how to make the DMA branch? I really have no idea about how to make the DMA branch. thanks Huang Shijie . > Best regards, > Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3 04/16] ARM: edma: add DT and runtime PM support for AM33XX
Adds support for parsing the TI EDMA DT data into the required
EDMA private API platform data.
Calls runtime PM API only in the DT case in order to unidle the
associated hwmods on AM33XX.
Signed-off-by: Matt Porter
---
arch/arm/common/edma.c | 255 +--
arch/arm/mach-davinci/board-da830-evm.c |4 +-
arch/arm/mach-davinci/board-da850-evm.c |8 +-
arch/arm/mach-davinci/board-dm646x-evm.c|4 +-
arch/arm/mach-davinci/board-omapl138-hawk.c |8 +-
arch/arm/mach-davinci/devices-da8xx.c |8 +-
arch/arm/mach-davinci/devices-tnetv107x.c |4 +-
arch/arm/mach-davinci/dm355.c |4 +-
arch/arm/mach-davinci/dm365.c |4 +-
arch/arm/mach-davinci/dm644x.c |4 +-
arch/arm/mach-davinci/dm646x.c |4 +-
include/linux/platform_data/edma.h |8 +-
12 files changed, 272 insertions(+), 43 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a3d189d..6d2a590 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
@@ -1366,31 +1373,237 @@ void edma_clear_event(unsigned channel)
EXPORT_SYMBOL(edma_clear_event);
/*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+const char *propname, s8 *out_values,
+size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) > prop->length)
+ return -EOVERFLOW;
+
+ val = prop->value;
+
+ while (sz--)
+ *out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+const char *propname, s16 *out_values,
+size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) > prop->length)
+ return -EOVERFLOW;
+
+ val = prop->value;
+
+ while (sz--)
+ *out_values++ = (s16)(be32_to_cpup(val++) & 0x);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_parse_dt(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata)
+{
+ int ret = 0;
+ u32 value;
+ struct property *prop;
+ size_t sz;
+ struct edma_rsv_info *rsv_info;
+ s16 (*rsv_chans)[2], (*rsv_slots)[2];
+ s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ ret = of_property_read_u32(node, "dma-channels", &value);
+ if (ret < 0)
+ return ret;
+ pdata->n_channel = value;
+
+ ret = of_property_read_u32(node, "ti,edma-regions", &value);
+ if (ret < 0)
+ return ret;
+ pdata->n_region = value;
+
+ ret = of_property_read_u32(node, "ti,edma-slots", &value);
+ if (ret < 0)
+ return ret;
+ pdata->n_slot = value;
+
+ pdata->n_cc = 1;
+ /* This is unused */
+ pdata->n_tc = 3;
+
+ rsv_info =
+ devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
+ if (!rsv_info)
+ return -ENOMEM;
+ pdata->rsv = rsv_info;
+
+ /* Build the reserved channel/slots arrays */
+ prop = of_find_property(node, "ti,edma-reserved-channels", &sz);
+ if (prop) {
+ rsv_chans = devm_kzalloc(dev,
+sz/sizeof(s16) + 2*sizeof(s16),
+GFP_KERNEL);
+ if (!rsv_chans)
+ return -ENOMEM;
+ pdata->rsv->rsv_chans = rsv_chans;
+
+ ret = edma_of_read_u32_to_s16_array(node,
+ "ti,edma-reserved-channels",
+ (s16 *)rsv_chans,
+ sz/sizeof(u32));
+ if (ret < 0)
+ return ret;
+ }
+
+ prop = of_find_property(node, "ti,edma-reserved-slots", &sz);
+ if (prop) {
+ rsv_slots = devm_kzalloc(dev,
+sz/sizeof(s16) + 2*s
[RFC PATCH v3 05/16] ARM: edma: add AM33XX crossbar event support
Adds support for the per-EDMA channel event mux. This is required
for any peripherals using DMA crossbar mapped events.
Signed-off-by: Matt Porter
---
arch/arm/common/edma.c | 63 +++-
include/linux/platform_data/edma.h |1 +
2 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 6d2a590..b761b7a 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1425,6 +1425,53 @@ static int edma_of_read_u32_to_s16_array(const struct
device_node *np,
return 0;
}
+static int edma_xbar_event_map(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata, int len)
+{
+ int ret = 0;
+ int i;
+ struct resource res;
+ void *xbar;
+ s16 (*xbar_chans)[2];
+ u32 shift, offset, mux;
+
+ xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!xbar_chans)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 1, &res);
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ xbar = devm_ioremap(dev, res.start, resource_size(&res));
+ if (!xbar)
+ return -EIO;
+
+ ret = edma_of_read_u32_to_s16_array(node,
+ "ti,edma-xbar-event-map",
+ (s16 *)xbar_chans,
+ len/sizeof(u32));
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ for (i = 0; xbar_chans[i][0] != -1; i++) {
+ shift = (xbar_chans[i][1] % 4) * 8;
+ offset = xbar_chans[i][1] >> 2;
+ offset <<= 2;
+ mux = __raw_readl((void *)((u32)xbar + offset));
+ mux &= (~(0xff << shift));
+ mux |= (xbar_chans[i][0] << shift);
+ __raw_writel(mux, (void *)((u32)xbar + offset));
+ }
+
+ pdata->xbar_chans = xbar_chans;
+
+ return 0;
+}
+
static int edma_of_parse_dt(struct device *dev,
struct device_node *node,
struct edma_soc_info *pdata)
@@ -1453,7 +1500,6 @@ static int edma_of_parse_dt(struct device *dev,
pdata->n_slot = value;
pdata->n_cc = 1;
- /* This is unused */
pdata->n_tc = 3;
rsv_info =
@@ -1538,6 +1584,10 @@ static int edma_of_parse_dt(struct device *dev,
return ret;
pdata->default_queue = value;
+ prop = of_find_property(node, "ti,edma-xbar-event-map", &sz);
+ if (prop)
+ ret = edma_xbar_event_map(dev, node, pdata, sz);
+
return ret;
}
@@ -1554,6 +1604,7 @@ static int __init edma_probe(struct platform_device *pdev)
int status = -1;
s16 (*rsv_chans)[2];
s16 (*rsv_slots)[2];
+ s16 (*xbar_chans)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
struct resource *r[EDMA_MAX_CC] = {NULL, NULL};
@@ -1678,6 +1729,16 @@ static int __init edma_probe(struct platform_device
*pdev)
}
}
+ /* Clear the xbar mapped channels in unused list */
+ xbar_chans = info[j]->xbar_chans;
+ if (xbar_chans) {
+ for (i = 0; xbar_chans[i][1] != -1; i++) {
+ off = xbar_chans[i][1];
+ clear_bits(off, 1,
+ edma_cc[j]->edma_unused);
+ }
+ }
+
if (node)
irq[j] = irq_of_parse_and_map(node, 0);
else {
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index b20b586..888a3c6 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -191,6 +191,7 @@ struct edma_soc_info {
/* Resource reservation for other cores */
struct edma_rsv_info*rsv;
+ s16 (*xbar_chans)[2];
s8 (*queue_tc_mapping)[2];
s8 (*queue_priority_mapping)[2];
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3 09/16] dmaengine: add dma_request_slave_channel_compat()
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Suggested-by: Tony Lindgren
Signed-off-by: Matt Porter
---
include/linux/dmaengine.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index c88f302..11d9e25 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1007,6 +1007,16 @@ void dma_run_dependencies(struct dma_async_tx_descriptor
*tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
+static inline struct dma_chan
+*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ if (dev->of_node)
+ return dma_request_slave_channel(dev, name);
+ else
+ return dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3 02/16] ARM: davinci: move private EDMA API to arm/common
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well. This just moves the
private EDMA API but does not support OMAP.
Signed-off-by: Matt Porter
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci/dma.c => common/edma.c} |2 +-
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
arch/arm/mach-davinci/davinci.h|2 +-
arch/arm/mach-davinci/devices-tnetv107x.c |2 +-
arch/arm/mach-davinci/devices.c|7 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
arch/arm/mach-davinci/include/mach/edma.h | 267
arch/arm/plat-omap/Kconfig |1 +
drivers/dma/edma.c |2 +-
drivers/mmc/host/davinci_mmc.c |1 +
include/linux/mfd/davinci_voicecodec.h |3 +-
include/linux/platform_data/edma.h | 198 ++
include/linux/platform_data/spi-davinci.h |2 +-
sound/soc/davinci/davinci-evm.c|1 +
sound/soc/davinci/davinci-pcm.c|1 +
sound/soc/davinci/davinci-pcm.h|2 +-
sound/soc/davinci/davinci-sffsdr.c |6 +-
25 files changed, 228 insertions(+), 288 deletions(-)
rename arch/arm/{mach-davinci/dma.c => common/edma.c} (99%)
delete mode 100644 arch/arm/mach-davinci/include/mach/edma.h
create mode 100644 include/linux/platform_data/edma.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 73067ef..23c2343 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -924,6 +924,7 @@ config ARCH_DAVINCI
select GENERIC_IRQ_CHIP
select HAVE_IDE
select NEED_MACH_GPIO_H
+ select TI_PRIV_EDMA
select ZONE_DMA
help
Support for TI's DaVinci platform.
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 45ceeb0..9e32d0d 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -40,3 +40,6 @@ config SHARP_PARAM
config SHARP_SCOOP
bool
+
+config TI_PRIV_EDMA
+ bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..d09a39b 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP) += scoop.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
+obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
similarity index 99%
rename from arch/arm/mach-davinci/dma.c
rename to arch/arm/common/edma.c
index a685e97..4411087 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include
#include
-#include
+#include
/* Offsets matching "struct edmacc_param" */
#define PARM_OPT 0x00
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 2227eff..97c639e 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
# Common objects
obj-y := time.o clock.o serial.o psc.o \
- dma.o usb.o common.o sram.o aemif.o
+ usb.o common.o sram.o aemif.o
obj-$(CONFIG_DAVINCI_MUX) += mux.o
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c
b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index be30997..86f55ba 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -26,12 +26,12 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..d26a6bc 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -23,9 +23,9 @@
#include
#include
#include
+#include
#include
#include
-#include
#include
#include
diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c
b/arch/arm/mach-davinci/devices-tnetv107x.c
index 29b17f7..59efd7f 100644
--- a/arch/arm/mach-davinci/devices-tnetv107x.c
+++ b/arch/arm/mach-davinci/devices-tnetv107x.c
@@ -18,10 +18,10 @@
#include
#include
#include
+#include
#include
#include
-#include
#include
#include "clock.h"
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 4c48a36..f45d591 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinc
[RFC PATCH v3 03/16] ARM: edma: remove unused transfer controller handlers
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.
Signed-off-by: Matt Porter
---
arch/arm/common/edma.c | 37 -
1 file changed, 37 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 4411087..a3d189d 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -494,26 +494,6 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
return IRQ_HANDLED;
}
-/**
- *
- * Transfer controller error interrupt handlers
- *
- */
-
-#define tc_errs_handledfalse /* disabled as long as they're NOPs */
-
-static irqreturn_t dma_tc0err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc0err_handler\n");
- return IRQ_HANDLED;
-}
-
-static irqreturn_t dma_tc1err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc1err_handler\n");
- return IRQ_HANDLED;
-}
-
static int reserve_contiguous_slots(int ctlr, unsigned int id,
unsigned int num_slots,
unsigned int start_slot)
@@ -1538,23 +1518,6 @@ static int __init edma_probe(struct platform_device
*pdev)
arch_num_cc++;
}
- if (tc_errs_handled) {
- status = request_irq(IRQ_TCERRINT0, dma_tc0err_handler, 0,
- "edma_tc0", &pdev->dev);
- if (status < 0) {
- dev_dbg(&pdev->dev, "request_irq %d failed --> %d\n",
- IRQ_TCERRINT0, status);
- return status;
- }
- status = request_irq(IRQ_TCERRINT, dma_tc1err_handler, 0,
- "edma_tc1", &pdev->dev);
- if (status < 0) {
- dev_dbg(&pdev->dev, "request_irq %d --> %d\n",
- IRQ_TCERRINT, status);
- return status;
- }
- }
-
return 0;
fail:
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3 01/16] dmaengine: edma: fix slave config dependency on direction
The edma_slave_config() implementation depends on the
direction field such that it will not properly configure
a slave channel when called without direction set.
This fixes the implementation so that the slave config
is copied as is and prep_slave_sg() handles the
direction dependent handling. spi-omap2-mcspi and
omap_hsmmc both expose this bug as they configure the
slave channel config from a common path with an unconfigured
direction field.
Signed-off-by: Matt Porter
---
drivers/dma/edma.c | 55 ++--
1 file changed, 27 insertions(+), 28 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 05aea3c..fdcf079 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -69,9 +69,7 @@ struct edma_chan {
int ch_num;
boolalloced;
int slot[EDMA_MAX_SLOTS];
- dma_addr_t addr;
- int addr_width;
- int maxburst;
+ struct dma_slave_config cfg;
};
struct edma_cc {
@@ -178,29 +176,14 @@ static int edma_terminate_all(struct edma_chan *echan)
return 0;
}
-
static int edma_slave_config(struct edma_chan *echan,
- struct dma_slave_config *config)
+ struct dma_slave_config *cfg)
{
- if ((config->src_addr_width > DMA_SLAVE_BUSWIDTH_4_BYTES) ||
- (config->dst_addr_width > DMA_SLAVE_BUSWIDTH_4_BYTES))
+ if (cfg->src_addr_width == DMA_SLAVE_BUSWIDTH_8_BYTES ||
+ cfg->dst_addr_width == DMA_SLAVE_BUSWIDTH_8_BYTES)
return -EINVAL;
- if (config->direction == DMA_MEM_TO_DEV) {
- if (config->dst_addr)
- echan->addr = config->dst_addr;
- if (config->dst_addr_width)
- echan->addr_width = config->dst_addr_width;
- if (config->dst_maxburst)
- echan->maxburst = config->dst_maxburst;
- } else if (config->direction == DMA_DEV_TO_MEM) {
- if (config->src_addr)
- echan->addr = config->src_addr;
- if (config->src_addr_width)
- echan->addr_width = config->src_addr_width;
- if (config->src_maxburst)
- echan->maxburst = config->src_maxburst;
- }
+ memcpy(&echan->cfg, cfg, sizeof(echan->cfg));
return 0;
}
@@ -235,6 +218,9 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
struct edma_chan *echan = to_edma_chan(chan);
struct device *dev = chan->device->dev;
struct edma_desc *edesc;
+ dma_addr_t dev_addr;
+ enum dma_slave_buswidth dev_width;
+ u32 burst;
struct scatterlist *sg;
int i;
int acnt, bcnt, ccnt, src, dst, cidx;
@@ -243,7 +229,20 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
if (unlikely(!echan || !sgl || !sg_len))
return NULL;
- if (echan->addr_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
+ if (direction == DMA_DEV_TO_MEM) {
+ dev_addr = echan->cfg.src_addr;
+ dev_width = echan->cfg.src_addr_width;
+ burst = echan->cfg.src_maxburst;
+ } else if (direction == DMA_MEM_TO_DEV) {
+ dev_addr = echan->cfg.dst_addr;
+ dev_width = echan->cfg.dst_addr_width;
+ burst = echan->cfg.dst_maxburst;
+ } else {
+ dev_err(dev, "%s: bad direction?\n", __func__);
+ return NULL;
+ }
+
+ if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
dev_err(dev, "Undefined slave buswidth\n");
return NULL;
}
@@ -275,14 +274,14 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
}
}
- acnt = echan->addr_width;
+ acnt = dev_width;
/*
* If the maxburst is equal to the fifo width, use
* A-synced transfers. This allows for large contiguous
* buffer transfers using only one PaRAM set.
*/
- if (echan->maxburst == 1) {
+ if (burst == 1) {
edesc->absync = false;
ccnt = sg_dma_len(sg) / acnt / (SZ_64K - 1);
bcnt = sg_dma_len(sg) / acnt - ccnt * (SZ_64K - 1);
@@ -302,7 +301,7 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
*/
} else {
edesc->absync = true;
- bcnt = echan->maxburst;
+ bcnt = burst;
ccnt = sg_dma_len(sg) / (acnt * bcnt);
if (ccnt > (SZ_64K - 1)) {
dev_err(dev, "Exceeded max SG segment size\n");
@@ -313,13 +312,13 @
[RFC PATCH v3 00/16] DMA Engine support for AM33XX
Changes since v2: - Rebased on 3.7-rc1 - Fixed bug in DT/pdata parsing first found by Gururaja that turned out to be masked by some toolchains - Dropped unused mach-omap2/devices.c hsmmc patch - Added AM33XX crossbar DMA event mux support - Added am335x-evm support Changes since v1: - Rebased on top of mainline from 12250d8 - Dropped the feature removal schedule patch - Implemented dma_request_slave_channel_compat() and converted the mmc and spi drivers to use it - Dropped unneeded #address-cells and #size-cells from EDMA DT support - Moved private EDMA header to linux/platform_data/ and removed some unneeded definitions - Fixed parsing of optional properties TODO: - Add dmaengine support for per-channel caps so the hack to set the maximum segments can be replaced with a query to the dmaengine driver This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. The series applies on top of 3.7-rc1 and the following patches: - GPMC fails to reserve memory fix: http://www.spinics.net/lists/linux-omap/msg79675.html - TPS65910 regulator fix: https://patchwork.kernel.org/patch/1593651/ - dmaengine DT support from Vinod's dmaengine_dt branch in git://git.infradead.org/users/vkoul/slave-dma.git since 027478851791df751176398be02a3b1c5f6aa824 The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx *only* boots using DT so we leverage Jon's generic DT DMA helpers to register EDMA DMAC with the of_dma framework and then add support for calling the dma_request_slave_channel() API to both the mmc and spi drivers. With this series both BeagleBone and the AM335x EVM have working MMC and SPI support. This is tested on BeagleBone with a SPI framebuffer driver and MMC rootfs. A trivial gpio DMA event misc driver was used to test the crossbar DMA event support. It is also tested on the AM335x EVM with the onboard SPI flash and MMC rootfs. The branch at https://github.com/ohporter/linux/tree/edma-dmaengine-v3 has the complete series, dependencies, and some test drivers/defconfigs. Regression testing was done on AM180x-EVM (which also makes use of the EDMA dmaengine driver and the EDMA private API) using SD, SPI flash, and the onboard audio supported by the ASoC Davinci driver. After this series, the plan is to convert the last in-tree user of the private EDMA API (davinci-pcm/mcasp) and then eliminate the private EDMA API by folding its functionality into drivers/dma/edma.c. Matt Porter (16): dmaengine: edma: fix slave config dependency on direction ARM: davinci: move private EDMA API to arm/common ARM: edma: remove unused transfer controller handlers ARM: edma: add DT and runtime PM support for AM33XX ARM: edma: add AM33XX crossbar event support dmaengine: edma: enable build for AM33XX dmaengine: edma: Add TI EDMA device tree binding ARM: dts: add AM33XX EDMA support dmaengine: add dma_request_slave_channel_compat() mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() mmc: omap_hsmmc: limit max_segs with the EDMA DMAC mmc: omap_hsmmc: add generic DMA request support to the DT binding ARM: dts: add AM33XX MMC support spi: omap2-mcspi: convert to dma_request_slave_channel_compat() spi: omap2-mcspi: add generic DMA request support to the DT binding ARM: dts: add AM33XX SPI support Documentation/devicetree/bindings/dma/ti-edma.txt | 51 + .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +- Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +- arch/arm/Kconfig |1 + arch/arm/boot/dts/am335x-bone.dts | 23 + arch/arm/boot/dts/am335x-evm.dts | 15 + arch/arm/boot/dts/am33xx.dtsi | 101 ++ arch/arm/common/Kconfig|3 + arch/arm/common/Makefile |1 + arch/arm/common/edma.c | 1841 arch/arm/mach-davinci/Makefile |2 +- arch/arm/mach-davinci/board-da830-evm.c|4 +- arch/arm/mach-davinci/board-da850-evm.c|8 +- arch/arm/mach-davinci/board-dm646x-evm.c |4 +- arch/arm/mach-davinci/board-omapl138-hawk.c|8 +- arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +- arch/arm/mach-davinci/davinci.h|
[RFC PATCH v3 07/16] dmaengine: edma: Add TI EDMA device tree binding
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 51 +
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..3344345
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,51 @@
+TI EDMA
+
+Required properties:
+- compatible : "ti,edma3"
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- ti,edma-queue-tc-map: List of transfer control to queue mappings
+- ti,edma-queue-priority-map: List of queue priority mappings
+- ti,edma-default-queue: Default queue value
+
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4900 0x1>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-reserved-channels = <0 2
+14 2
+26 6
+48 4
+56 8>;
+ ti,edma-reserved-slots = <0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ ti,edma-xbar-event-map = <1 12
+ 2 13>;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3 10/16] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 54bfd0c..b327cd0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1866,14 +1866,20 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host->rx_chan = dma_request_channel(mask, omap_dma_filter_fn, &rx_req);
+ host->rx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&rx_req, &pdev->dev, "rx");
+
if (!host->rx_chan) {
dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine
channel %u\n", rx_req);
ret = -ENXIO;
goto err_irq;
}
- host->tx_chan = dma_request_channel(mask, omap_dma_filter_fn, &tx_req);
+ host->tx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&tx_req, &pdev->dev, "tx");
+
if (!host->tx_chan) {
dev_err(mmc_dev(host->mmc), "unable to obtain TX DMA engine
channel %u\n", tx_req);
ret = -ENXIO;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3 11/16] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
The EDMA DMAC has a hardware limitation that prevents supporting
scatter gather lists with any number of segments. Since the EDMA
DMA Engine driver sets the maximum segments to 16, we do the
same.
TODO: this will be replaced once the DMA Engine API supports an
API to query the DMAC's segment size limit.
Signed-off-by: Matt Porter
---
drivers/mmc/host/omap_hsmmc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b327cd0..52bab01 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1828,6 +1828,16 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
* as we want. */
mmc->max_segs = 1024;
+ /* Eventually we should get our max_segs limitation for EDMA by
+* querying the dmaengine API */
+ if (pdev->dev.of_node) {
+ struct device_node *parent = pdev->dev.of_node->parent;
+ struct device_node *node;
+ node = of_find_node_by_name(parent, "edma");
+ if (node)
+ mmc->max_segs = 16;
+ }
+
mmc->max_blk_size = 512; /* Block Length at max can be 1024 */
mmc->max_blk_count = 0x;/* No. of Blocks is 16 bits */
mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3 13/16] ARM: dts: add AM33XX MMC support
Adds AM33XX MMC support for am335x-bone and am335x-evm.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am335x-bone.dts |6 ++
arch/arm/boot/dts/am335x-evm.dts |6 ++
arch/arm/boot/dts/am33xx.dtsi | 27 +++
3 files changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..5510979 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -70,6 +70,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
@@ -78,3 +80,7 @@
};
};
};
+
+&mmc1 {
+ vmmc-supply = <&ldo3_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..d63fce8 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -114,7 +114,13 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
};
};
+
+&mmc1 {
+ vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index ab9c78f..26a6af7 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -234,6 +234,33 @@
status = "disabled";
};
+ mmc1: mmc@4806 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = <&edma 24
+ &edma 25>;
+ dma-names = "tx", "rx";
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc2";
+ ti,needs-special-reset;
+ dmas = <&edma 2
+ &edma 3>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ mmc3: mmc@4781 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc3";
+ ti,needs-special-reset;
+ status = "disabled";
+ };
+
wdt2: wdt@44e35000 {
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3 08/16] ARM: dts: add AM33XX EDMA support
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am33xx.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..ab9c78f 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -62,6 +62,37 @@
reg = <0x4820 0x1000>;
};
+ edma: edma@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-reserved-channels = <0 2
+14 2
+26 6
+48 4
+56 8>;
+ ti,edma-reserved-slots = <0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ };
+
gpio1: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3 06/16] dmaengine: edma: enable build for AM33XX
Enable TI EDMA option on OMAP. Signed-off-by: Matt Porter --- drivers/dma/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 677cd6e..eaea1c2 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -210,7 +210,7 @@ config SIRF_DMA config TI_EDMA tristate "TI EDMA support" - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS default n -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3 14/16] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter
---
drivers/spi/spi-omap2-mcspi.c | 65 -
1 file changed, 45 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 3542fdc..793ae8c 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -103,6 +103,9 @@ struct omap2_mcspi_dma {
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+ char dma_rx_ch_name[14];
+ char dma_tx_ch_name[14];
};
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -819,14 +822,23 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma->dma_rx_sync_dev;
- mcspi_dma->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+ mcspi_dma->dma_rx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_rx_ch_name);
+
if (!mcspi_dma->dma_rx) {
dev_err(&spi->dev, "no RX DMA engine channel for McSPI\n");
return -EAGAIN;
}
sig = mcspi_dma->dma_tx_sync_dev;
- mcspi_dma->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+ mcspi_dma->dma_tx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_tx_ch_name);
+
if (!mcspi_dma->dma_tx) {
dev_err(&spi->dev, "no TX DMA engine channel for McSPI\n");
dma_release_channel(mcspi_dma->dma_rx);
@@ -1217,29 +1229,42 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
goto free_master;
for (i = 0; i < master->num_chipselect; i++) {
- char dma_ch_name[14];
+ char *dma_rx_ch_name = mcspi->dma_channels[i].dma_rx_ch_name;
+ char *dma_tx_ch_name = mcspi->dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
- sprintf(dma_ch_name, "rx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA RX channel\n");
- status = -ENODEV;
- break;
- }
+ sprintf(dma_rx_ch_name, "rx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_rx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA RX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_rx_sync_dev = dma_res->start;
- sprintf(dma_ch_name, "tx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA TX channel\n");
- status = -ENODEV;
- break;
+ mcspi->dma_channels[i].dma_rx_sync_dev =
+ dma_res->start;
}
+ sprintf(dma_tx_ch_name, "tx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_tx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA TX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_tx_sync_dev = dma_res->start;
+ mcspi->dma_channels[i].dma_tx_sync_dev =
+ dma_res->st
[RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
Adds AM33XX SPI support for am335x-bone and am335x-evm.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am335x-bone.dts | 17 +++
arch/arm/boot/dts/am335x-evm.dts |9
arch/arm/boot/dts/am33xx.dtsi | 43 +
3 files changed, 69 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5510979..23edfd8 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,6 +18,17 @@
reg = <0x8000 0x1000>; /* 256 MB */
};
+ am3358_pinmux: pinmux@44e10800 {
+ spi1_pins: pinmux_spi1_pins {
+ pinctrl-single,pins = <
+ 0x190 0x13 /* mcasp0_aclkx.spi1_sclk,
OUTPUT_PULLUP | MODE3 */
+ 0x194 0x33 /* mcasp0_fsx.spi1_d0,
INPUT_PULLUP | MODE3 */
+ 0x198 0x13 /* mcasp0_axr0.spi1_d1,
OUTPUT_PULLUP | MODE3 */
+ 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0,
OUTPUT_PULLUP | MODE3 */
+ >;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = "okay";
@@ -84,3 +95,9 @@
&mmc1 {
vmmc-supply = <&ldo3_reg>;
};
+
+&spi1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d63fce8..8d5f660 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -124,3 +124,12 @@
&mmc1 {
vmmc-supply = <&vmmc_reg>;
};
+
+&spi0 {
+ status = "okay";
+ spi-flash@0 {
+ compatible = "spansion,s25fl064k", "m25p80";
+ spi-max-frequency = <2400>;
+ reg = <0>;
+ };
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 26a6af7..063ecea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
+ am3358_pinmux: pinmux@44e10800 {
+ compatible = "pinctrl-single";
+ reg = <0x44e10800 0x0238>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x7f>;
+ };
+
/*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex.Since
@@ -261,6 +270,40 @@
status = "disabled";
};
+ spi0: spi@4803 {
+ compatible = "ti,omap4-mcspi";
+ ti,hwmods = "spi0";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4803 0x400>;
+ interrupt-parent = <&intc>;
+ interrupt = <65>;
+ dmas = <&edma 16
+ &edma 17
+ &edma 18
+ &edma 19>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
+ ti,spi-num-cs = <2>;
+ status = "disabled";
+ };
+
+ spi1: spi@481a {
+ compatible = "ti,omap4-mcspi";
+ ti,hwmods = "spi1";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x481a 0x400>;
+ interrupt-parent = <&intc>;
+ interrupt = <125>;
+ dmas = <&edma 42
+ &edma 43
+ &edma 44
+ &edma 45>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
+ ti,spi-num-cs = <2>;
+ status = "disabled";
+ };
+
wdt2: wdt@44e35000 {
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3 15/16] spi: omap2-mcspi: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 81df374..11aff04 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -7,8 +7,18 @@ Required properties:
- ti,spi-num-cs : Number of chipselect supported by the instance.
- ti,hwmods: Name of the hwmod associated to the McSPI
+Optional properties:
+- dmas: List of DMA controller phandle and DMA request ordered
+ pairs. One tx and one rx pair is required for each chip
+ select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the ordered pairs in dmas. The string naming is
+ to be "rxN" and "txN" for RX and TX requests,
+ respectively, where N equals the chip select number.
-Example:
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = <1>;
@@ -18,3 +28,18 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = <4>;
};
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "ti,omap4-mcspi";
+ti,hwmods = "mcspi1";
+ti,spi-num-cs = <2>;
+dmas = <&edma 42
+ &edma 43
+ &edma 44
+ &edma 45>;
+dma-names = "tx0", "rx0", "tx1", "rx1";
+};
+
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3 12/16] mmc: omap_hsmmc: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..d1b8932 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,8 +19,28 @@ ti,dual-volt: boolean, supports dual voltage cards
"supply-name" examples are "vmmc", "vmmc_aux" etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+dmas: DMA controller phandle and DMA request value ordered pair
+One tx and one rx pair is required.
+dma-names: DMA request names. These strings correspond 1:1 with
+the ordered pairs in dmas. The RX request must be "rx" and the
+TX request must be "tx".
+
+Examples:
+
+[hwmod populated DMA resources]
+
+ mmc1: mmc@0x4809c000 {
+ compatible = "ti,omap4-hsmmc";
+ reg = <0x4809c000 0x400>;
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ bus-width = <4>;
+ vmmc-supply = <&vmmc>; /* phandle to regulator node */
+ ti,non-removable;
+ };
+
+[generic DMA request binding]
-Example:
mmc1: mmc@0x4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
@@ -29,4 +49,7 @@ Example:
bus-width = <4>;
vmmc-supply = <&vmmc>; /* phandle to regulator node */
ti,non-removable;
+ dmas = <&edma 24
+ &edma 25>;
+ dma-names = "tx", "rx";
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] mmc: sdhci-s3c: fix the card detection in runtime-pm
If host clock is disabled, host cannot detect a card in case of using the internal or gpio card-detect for detection. Signed-off-by: Seungwon Jeon Tested-by: Heiko Stuebner --- I've added the SDHCI_CD_GPIO to the conditional. With this change it works on my machine. But I'm not sure if this would also be necessary for the external card detect. drivers/mmc/host/sdhci-s3c.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c index 0cabf18..649dc32 100644 --- a/drivers/mmc/host/sdhci-s3c.c +++ b/drivers/mmc/host/sdhci-s3c.c @@ -750,7 +750,9 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev) sdhci_s3c_setup_card_detect_gpio(sc); #ifdef CONFIG_PM_RUNTIME - clk_disable(sc->clk_io); + if (pdata->cd_type != S3C_SDHCI_CD_INTERNAL && + pdata->cd_type != S3C_SDHCI_CD_GPIO) + clk_disable(sc->clk_io); #endif return 0; @@ -797,7 +799,9 @@ static int __devexit sdhci_s3c_remove(struct platform_device *pdev) gpio_free(sc->ext_cd_gpio); #ifdef CONFIG_PM_RUNTIME - clk_enable(sc->clk_io); + if (pdata->cd_type != S3C_SDHCI_CD_INTERNAL && + pdata->cd_type != S3C_SDHCI_CD_GPIO) + clk_enable(sc->clk_io); #endif sdhci_remove_host(host, 1); -- 1.7.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] mmc: sdhci-s3c: ensure non-transaction of bus before clk_disable
Clock should be supplied during bus transaction. This patch defers
clk_disabe in runtime_suspend if CMD/DATA line is used.
Signed-off-by: Seungwon Jeon
Acked-by: Heiko Stuebner
---
It's also necessary to destaticise the forward declarations in the top of
sdhci.c, which I've done in this v2.
drivers/mmc/host/sdhci-s3c.c | 13 +
drivers/mmc/host/sdhci.c | 14 --
drivers/mmc/host/sdhci.h |2 ++
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 30e3d01..0cabf18 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -848,12 +848,17 @@ static int sdhci_s3c_runtime_suspend(struct device *dev)
struct sdhci_host *host = dev_get_drvdata(dev);
struct sdhci_s3c *ourhost = to_s3c(host);
struct clk *busclk = ourhost->clk_io;
- int ret;
+ int ret = 0;
- ret = sdhci_runtime_suspend_host(host);
+ if (!(readl(host->ioaddr + SDHCI_PRESENT_STATE) &
+ (SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT))) {
+ ret = sdhci_runtime_suspend_host(host);
+ clk_disable(ourhost->clk_bus[ourhost->cur_clk]);
+ clk_disable(busclk);
+ } else {
+ sdhci_runtime_pm_put(host);
+ }
- clk_disable(ourhost->clk_bus[ourhost->cur_clk]);
- clk_disable(busclk);
return ret;
}
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7922adb..57de949 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -55,14 +55,14 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32
opcode);
static void sdhci_tuning_timer(unsigned long data);
#ifdef CONFIG_PM_RUNTIME
-static int sdhci_runtime_pm_get(struct sdhci_host *host);
-static int sdhci_runtime_pm_put(struct sdhci_host *host);
+int sdhci_runtime_pm_get(struct sdhci_host *host);
+int sdhci_runtime_pm_put(struct sdhci_host *host);
#else
-static inline int sdhci_runtime_pm_get(struct sdhci_host *host)
+inline int sdhci_runtime_pm_get(struct sdhci_host *host)
{
return 0;
}
-static inline int sdhci_runtime_pm_put(struct sdhci_host *host)
+inline int sdhci_runtime_pm_put(struct sdhci_host *host)
{
return 0;
}
@@ -2535,16 +2535,18 @@ EXPORT_SYMBOL_GPL(sdhci_enable_irq_wakeups);
#ifdef CONFIG_PM_RUNTIME
-static int sdhci_runtime_pm_get(struct sdhci_host *host)
+int sdhci_runtime_pm_get(struct sdhci_host *host)
{
return pm_runtime_get_sync(host->mmc->parent);
}
+EXPORT_SYMBOL_GPL(sdhci_runtime_pm_get);
-static int sdhci_runtime_pm_put(struct sdhci_host *host)
+int sdhci_runtime_pm_put(struct sdhci_host *host)
{
pm_runtime_mark_last_busy(host->mmc->parent);
return pm_runtime_put_autosuspend(host->mmc->parent);
}
+EXPORT_SYMBOL_GPL(sdhci_runtime_pm_put);
int sdhci_runtime_suspend_host(struct sdhci_host *host)
{
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 97653ea..fbf9a08 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -384,6 +384,8 @@ extern void sdhci_enable_irq_wakeups(struct sdhci_host
*host);
#endif
#ifdef CONFIG_PM_RUNTIME
+extern int sdhci_runtime_pm_get(struct sdhci_host *host);
+extern int sdhci_runtime_pm_put(struct sdhci_host *host);
extern int sdhci_runtime_suspend_host(struct sdhci_host *host);
extern int sdhci_runtime_resume_host(struct sdhci_host *host);
#endif
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
Dear Huang Shijie, > 于 2012年10月18日 16:49, Marek Vasut 写道: > > Dear Huang Shijie, > > > >> 于 2012年10月18日 16:16, Marek Vasut 写道: > >>> So we can't stream data from the chip? About time to adjust the MTD > >>> framework to allow that. Maybe implement a command queue? > >> > >> IMHO, it's not possible. Because the READ-PAGE(00h-30h) command needs to > >> check the busy status > >> which means we have to stop in the middle, so we can not chain the all > >> the read-pages DMA commands. > > > > Can the DMA not branch? > > it's too complicated to the MTD layer, as well as the gpmi driver. Can you please elaborate ? Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: sdhci-s3c: fix the card detection in runtime-pm
If host clock is disabled, host cannot detect a card in case of using CD internal for detection. Signed-off-by: Seungwon Jeon --- drivers/mmc/host/sdhci-s3c.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c index 2903949..e57f200 100644 --- a/drivers/mmc/host/sdhci-s3c.c +++ b/drivers/mmc/host/sdhci-s3c.c @@ -747,7 +747,8 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev) sdhci_s3c_setup_card_detect_gpio(sc); #ifdef CONFIG_PM_RUNTIME - clk_disable(sc->clk_io); + if (pdata->cd_type != S3C_SDHCI_CD_INTERNAL) + clk_disable(sc->clk_io); #endif return 0; @@ -794,7 +795,8 @@ static int __devexit sdhci_s3c_remove(struct platform_device *pdev) gpio_free(sc->ext_cd_gpio); #ifdef CONFIG_PM_RUNTIME - clk_enable(sc->clk_io); + if (pdata->cd_type != S3C_SDHCI_CD_INTERNAL) + clk_enable(sc->clk_io); #endif sdhci_remove_host(host, 1); -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: sdhci-s3c: ensure non-transaction of bus before clk_disable
Clock should be supplied during bus transaction. This patch defers
clk_disabe in runtime_suspend if CMD/DATA line is used.
Signed-off-by: Seungwon Jeon
---
drivers/mmc/host/sdhci-s3c.c | 13 +
drivers/mmc/host/sdhci.c |6 --
drivers/mmc/host/sdhci.h |2 ++
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 2903949..490b781 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -845,12 +845,17 @@ static int sdhci_s3c_runtime_suspend(struct device *dev)
struct sdhci_host *host = dev_get_drvdata(dev);
struct sdhci_s3c *ourhost = to_s3c(host);
struct clk *busclk = ourhost->clk_io;
- int ret;
+ int ret = 0;
- ret = sdhci_runtime_suspend_host(host);
+ if (!(readl(host->ioaddr + SDHCI_PRESENT_STATE) &
+ (SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT))) {
+ ret = sdhci_runtime_suspend_host(host);
+ clk_disable(ourhost->clk_bus[ourhost->cur_clk]);
+ clk_disable(busclk);
+ } else {
+ sdhci_runtime_pm_put(host);
+ }
- clk_disable(ourhost->clk_bus[ourhost->cur_clk]);
- clk_disable(busclk);
return ret;
}
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7922adb..deeffce 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2535,16 +2535,18 @@ EXPORT_SYMBOL_GPL(sdhci_enable_irq_wakeups);
#ifdef CONFIG_PM_RUNTIME
-static int sdhci_runtime_pm_get(struct sdhci_host *host)
+int sdhci_runtime_pm_get(struct sdhci_host *host)
{
return pm_runtime_get_sync(host->mmc->parent);
}
+EXPORT_SYMBOL_GPL(sdhci_runtime_pm_get);
-static int sdhci_runtime_pm_put(struct sdhci_host *host)
+int sdhci_runtime_pm_put(struct sdhci_host *host)
{
pm_runtime_mark_last_busy(host->mmc->parent);
return pm_runtime_put_autosuspend(host->mmc->parent);
}
+EXPORT_SYMBOL_GPL(sdhci_runtime_pm_put);
int sdhci_runtime_suspend_host(struct sdhci_host *host)
{
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 97653ea..fbf9a08 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -384,6 +384,8 @@ extern void sdhci_enable_irq_wakeups(struct sdhci_host
*host);
#endif
#ifdef CONFIG_PM_RUNTIME
+extern int sdhci_runtime_pm_get(struct sdhci_host *host);
+extern int sdhci_runtime_pm_put(struct sdhci_host *host);
extern int sdhci_runtime_suspend_host(struct sdhci_host *host);
extern int sdhci_runtime_resume_host(struct sdhci_host *host);
#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: sdhci-s3c: Add clk_(enable/disable) in runtime suspend/resume
Am Donnerstag, 18. Oktober 2012, 11:36:03 schrieb Seungwon Jeon: > On Thursday, October 18, 2012, Heiko Stübner wrote: > > Hi, > > > > Am Donnerstag, 18. Oktober 2012, 04:04:42 schrieb Jaehoon Chung: > > > Sorry, i didn't check this patch with s3c2416. > > > (i didn't have the s3c2416 board.) > > > If you have a problem, i think good that revert this patch for fixing > > > your problem. Also, i will check and share the result. > > > > After looking a bit more through the code, I don't think the problem is > > 2416- specific but seems to be caused by the gpio card-detect code. > > > > sdhci_s3c_gpio_card_detect_thread calls sdhci_s3c_notify_change which in > > turn runs host->card_tasklet that seems to want to read stuff from the > > card. But this path seems to be missing a runtime-pm wakeup. > > > > I'm not yet sure what to add, especially, as tasklet_finish (called on > > some occasions from tasklet_card) already has a runtime_pm_put call, > > which would be unpaired in this code path. > > > > As there also could be other Samsung platforms affected that use the > > ext-gpio code, it's probably right to revert it for now. Or you see a > > easy fix :-) . > > Hi, > > I think clock is disabled during bus transaction. > I'll send a patch. Could you test it? Sure, I'll test it. Heiko > > > On 10/17/2012 06:15 PM, Heiko Stübner wrote: > > > > Hi, > > > > > > > > Am Freitag, 14. September 2012, 11:08:51 schrieb Chander Kashyap: > > > >> Perform clock disable/enable in runtime suspend/resume. > > > >> > > > >> Signed-off-by: Chander Kashyap > > > > > > > > It seems this patch breaks my S3C2416 based machine with 3.7-rc1. I'm > > > > not > > > > > > > > yet sure why, but the only response I get is loop of: > > > > mmc0: Timeout waiting for hardware interrupt. > > > > mmc0: Internal clock never stabilised. > > > > mmc0: Timeout waiting for hardware interrupt. > > > > mmc0: Internal clock never stabilised. > > > > > > > > This only happens on the hsmmc channel using the gpio-based card > > > > detect and even prevents the card from beeing fully detected. The > > > > other hsmmc channel using a permanent emmc seems to be working fine. > > > > > > > > And of course, when I revert this patch everything works fine again. > > > > > > > > I'll investigate further, but it'd be also ok if someone has a fix > > > > for this before me :-) . > > > > > > > > > > > > Heiko > > > > -- > > > > To unsubscribe from this list: send the line "unsubscribe linux-mmc" > > > > in the body of a message to majord...@vger.kernel.org > > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: sdhci-s3c: Add clk_(enable/disable) in runtime suspend/resume
On Thursday, October 18, 2012, Heiko Stübner wrote: > Hi, > > Am Donnerstag, 18. Oktober 2012, 04:04:42 schrieb Jaehoon Chung: > > Sorry, i didn't check this patch with s3c2416. > > (i didn't have the s3c2416 board.) > > If you have a problem, i think good that revert this patch for fixing your > > problem. Also, i will check and share the result. > > > After looking a bit more through the code, I don't think the problem is 2416- > specific but seems to be caused by the gpio card-detect code. > > sdhci_s3c_gpio_card_detect_thread calls sdhci_s3c_notify_change which in turn > runs host->card_tasklet that seems to want to read stuff from the card. But > this path seems to be missing a runtime-pm wakeup. > > I'm not yet sure what to add, especially, as tasklet_finish (called on some > occasions from tasklet_card) already has a runtime_pm_put call, which would be > unpaired in this code path. > > As there also could be other Samsung platforms affected that use the ext-gpio > code, it's probably right to revert it for now. Or you see a easy fix :-) . > Hi, I think clock is disabled during bus transaction. I'll send a patch. Could you test it? Thanks. Seungwon Jeon > > Heiko > > > > Best Regards, > > Jaehoon Chung > > > > On 10/17/2012 06:15 PM, Heiko Stübner wrote: > > > Hi, > > > > > > Am Freitag, 14. September 2012, 11:08:51 schrieb Chander Kashyap: > > >> Perform clock disable/enable in runtime suspend/resume. > > >> > > >> Signed-off-by: Chander Kashyap > > > > > > It seems this patch breaks my S3C2416 based machine with 3.7-rc1. I'm not > > > > > > yet sure why, but the only response I get is loop of: > > > mmc0: Timeout waiting for hardware interrupt. > > > mmc0: Internal clock never stabilised. > > > mmc0: Timeout waiting for hardware interrupt. > > > mmc0: Internal clock never stabilised. > > > > > > This only happens on the hsmmc channel using the gpio-based card detect > > > and even prevents the card from beeing fully detected. The other hsmmc > > > channel using a permanent emmc seems to be working fine. > > > > > > And of course, when I revert this patch everything works fine again. > > > > > > I'll investigate further, but it'd be also ok if someone has a fix for > > > this before me :-) . > > > > > > > > > Heiko > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > > > the body of a message to majord...@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
On 18 October 2012 12:15, Huang Shijie wrote: > 于 2012年10月18日 14:18, Vinod Koul 写道: > >> Why cant you do start (prepare clock etc) when you submit the descriptor >> to dmaengine. Can be done in tx_submit callback. >> Similarly remove the clock when dma transaction gets completed. > > I ever thought this method too. > > But it will become low efficient in the following case: > > Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ > read operation. > The gpmi-nand will submit the descriptor to dmaengine per page. So with your > method, > the system will repeat the enable/disable dma clock 1024 time. At every > enable/disable dma clock, > the system has to enable the clock chain and it's parents ... > > But with this patch, we only need to enable/disable dma clock one time, just > at we select the nand chip. > If the clock is the dmac's property (not channels'), the toggling seems too aggressive. You could try using runtime_suspend/resume for clock disabling/enabling. How about employing autosuspend with a few ms delay? -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
于 2012年10月18日 16:49, Marek Vasut 写道: Dear Huang Shijie, 于 2012年10月18日 16:16, Marek Vasut 写道: So we can't stream data from the chip? About time to adjust the MTD framework to allow that. Maybe implement a command queue? IMHO, it's not possible. Because the READ-PAGE(00h-30h) command needs to check the busy status which means we have to stop in the middle, so we can not chain the all the read-pages DMA commands. Can the DMA not branch? it's too complicated to the MTD layer, as well as the gpmi driver. Best Regards Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
于 2012年10月18日 16:52, Russell King - ARM Linux 写道: On Thu, Oct 18, 2012 at 02:45:41PM +0800, Huang Shijie wrote: 于 2012年10月18日 14:18, Vinod Koul 写道: Why cant you do start (prepare clock etc) when you submit the descriptor to dmaengine. Can be done in tx_submit callback. Similarly remove the clock when dma transaction gets completed. I ever thought this method too. But it will become low efficient in the following case: Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ read operation. The gpmi-nand will submit the descriptor to dmaengine per page. So with your method, the system will repeat the enable/disable dma clock 1024 time. At every enable/disable dma clock, the system has to enable the clock chain and it's parents ... And what if you stop using clk_prepare_enable(), and prepare the clock when the channel is requested and only use clk_enable() in the tx_submit yes. it's a little better. There is nearly no difference between the clk_prepare_enable() and clk_enable() in actually. the clk_gate2_ops does not have any @->prepare. thanks Huang Shijie method? -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
On Thu, Oct 18, 2012 at 02:45:41PM +0800, Huang Shijie wrote: > 于 2012年10月18日 14:18, Vinod Koul 写道: >> Why cant you do start (prepare clock etc) when you submit the descriptor >> to dmaengine. Can be done in tx_submit callback. >> Similarly remove the clock when dma transaction gets completed. > I ever thought this method too. > > But it will become low efficient in the following case: > > Assuming the gpmi-nand driver has to read out 1024 pages in one > _SINGLE_ read operation. > The gpmi-nand will submit the descriptor to dmaengine per page. So with > your method, > the system will repeat the enable/disable dma clock 1024 time. At every > enable/disable dma clock, > the system has to enable the clock chain and it's parents ... And what if you stop using clk_prepare_enable(), and prepare the clock when the channel is requested and only use clk_enable() in the tx_submit method? -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
Dear Huang Shijie, > 于 2012年10月18日 16:16, Marek Vasut 写道: > > So we can't stream data from the chip? About time to adjust the MTD > > framework to allow that. Maybe implement a command queue? > > IMHO, it's not possible. Because the READ-PAGE(00h-30h) command needs to > check the busy status > which means we have to stop in the middle, so we can not chain the all > the read-pages DMA commands. Can the DMA not branch? > thanks > Huang Shijie Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
于 2012年10月18日 16:16, Marek Vasut 写道: So we can't stream data from the chip? About time to adjust the MTD framework to allow that. Maybe implement a command queue? IMHO, it's not possible. Because the READ-PAGE(00h-30h) command needs to check the busy status which means we have to stop in the middle, so we can not chain the all the read-pages DMA commands. thanks Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
于 2012年10月18日 16:16, Marek Vasut 写道: So we can't stream data from the chip? About time to adjust the MTD framework to allow that. Maybe implement a command queue? to Artem & David: is this possible to stream the data out with a command queue? thanks Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
Dear Huang Shijie, > 于 2012年10月18日 15:14, Marek Vasut 写道: > > Dear Huang Shijie, > > > > Why such massive CC ? > > > >> 于 2012年10月18日 14:18, Vinod Koul 写道: > >>> Why cant you do start (prepare clock etc) when you submit the > >>> descriptor to dmaengine. Can be done in tx_submit callback. > >>> Similarly remove the clock when dma transaction gets completed. > >> > >> I ever thought this method too. > >> > >> But it will become low efficient in the following case: > >> Assuming the gpmi-nand driver has to read out 1024 pages in one > >> > >> _SINGLE_ read operation. > >> The gpmi-nand will submit the descriptor to dmaengine per page. > > > > It will? Then GPMI NAND is flat our broken ... again. > > yes. > > Please read the NAND chip spec about the comand READ PAGE(00h-30h) and > the code > nand_do_read_ops(). The nand chip limits us only read one page out one > time. So the driver will submit the descriptor to dmaengine per page. So we can't stream data from the chip? About time to adjust the MTD framework to allow that. Maybe implement a command queue? > >> So with > >> your method, > >> the system will repeat the enable/disable dma clock 1024 time. > > > > Yes, it is the driver that's wrong. > > not the driver. > > >> At every > >> enable/disable dma clock, > >> the system has to enable the clock chain and it's parents ... > >> > >> But with this patch, we only need to enable/disable dma clock one time, > >> just at we select the nand chip. > > > > You are fixing a driver problem at a framework level, wrong. > > > > So, check how the MXS SPI driver handles descriptor chaining. Indeed, the > > Sigmatel screwed the DMA stuff good. But if you analyze the SPI driver, > > you'll notice a few important points that might come handy when you fix > > the GPMI NAND driver properly. > > > > The direction to take here is: > > 1) Implement DMA chaining into the GPMI NAND driver > > How can i implement the DMA chain if the nand chip READ-PAGE command > gives us the one page limit? This smells like a time to extend the MTD api ? > thanks > Huang Shijie > > > 2) You might need to do one PIO transfer to reconfigure the IP registers > > between each segment of the DMA chain (just as MXS SPI does it) > > 3) You might run out of DMA descriptors when doing too long chains -- so > > you might need to fix that part of the mxs DMA driver. Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
于 2012年10月18日 15:14, Marek Vasut 写道: Dear Huang Shijie, Why such massive CC ? 于 2012年10月18日 14:18, Vinod Koul 写道: Why cant you do start (prepare clock etc) when you submit the descriptor to dmaengine. Can be done in tx_submit callback. Similarly remove the clock when dma transaction gets completed. I ever thought this method too. But it will become low efficient in the following case: Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ read operation. The gpmi-nand will submit the descriptor to dmaengine per page. It will? Then GPMI NAND is flat our broken ... again. yes. Please read the NAND chip spec about the comand READ PAGE(00h-30h) and the code nand_do_read_ops(). The nand chip limits us only read one page out one time. So the driver will submit the descriptor to dmaengine per page. So with your method, the system will repeat the enable/disable dma clock 1024 time. Yes, it is the driver that's wrong. not the driver. At every enable/disable dma clock, the system has to enable the clock chain and it's parents ... But with this patch, we only need to enable/disable dma clock one time, just at we select the nand chip. You are fixing a driver problem at a framework level, wrong. So, check how the MXS SPI driver handles descriptor chaining. Indeed, the Sigmatel screwed the DMA stuff good. But if you analyze the SPI driver, you'll notice a few important points that might come handy when you fix the GPMI NAND driver properly. The direction to take here is: 1) Implement DMA chaining into the GPMI NAND driver How can i implement the DMA chain if the nand chip READ-PAGE command gives us the one page limit? thanks Huang Shijie 2) You might need to do one PIO transfer to reconfigure the IP registers between each segment of the DMA chain (just as MXS SPI does it) 3) You might run out of DMA descriptors when doing too long chains -- so you might need to fix that part of the mxs DMA driver. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: sdhci-s3c: Add clk_(enable/disable) in runtime suspend/resume
Hi, Am Donnerstag, 18. Oktober 2012, 04:04:42 schrieb Jaehoon Chung: > Sorry, i didn't check this patch with s3c2416. > (i didn't have the s3c2416 board.) > If you have a problem, i think good that revert this patch for fixing your > problem. Also, i will check and share the result. After looking a bit more through the code, I don't think the problem is 2416- specific but seems to be caused by the gpio card-detect code. sdhci_s3c_gpio_card_detect_thread calls sdhci_s3c_notify_change which in turn runs host->card_tasklet that seems to want to read stuff from the card. But this path seems to be missing a runtime-pm wakeup. I'm not yet sure what to add, especially, as tasklet_finish (called on some occasions from tasklet_card) already has a runtime_pm_put call, which would be unpaired in this code path. As there also could be other Samsung platforms affected that use the ext-gpio code, it's probably right to revert it for now. Or you see a easy fix :-) . Heiko > Best Regards, > Jaehoon Chung > > On 10/17/2012 06:15 PM, Heiko Stübner wrote: > > Hi, > > > > Am Freitag, 14. September 2012, 11:08:51 schrieb Chander Kashyap: > >> Perform clock disable/enable in runtime suspend/resume. > >> > >> Signed-off-by: Chander Kashyap > > > > It seems this patch breaks my S3C2416 based machine with 3.7-rc1. I'm not > > > > yet sure why, but the only response I get is loop of: > > mmc0: Timeout waiting for hardware interrupt. > > mmc0: Internal clock never stabilised. > > mmc0: Timeout waiting for hardware interrupt. > > mmc0: Internal clock never stabilised. > > > > This only happens on the hsmmc channel using the gpio-based card detect > > and even prevents the card from beeing fully detected. The other hsmmc > > channel using a permanent emmc seems to be working fine. > > > > And of course, when I revert this patch everything works fine again. > > > > I'll investigate further, but it'd be also ok if someone has a fix for > > this before me :-) . > > > > > > Heiko > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] mmc: esdhc: enable polling to detect card by itself
Shawn,
Thanks, I will update the patch for sdhci-esdhc-imx.c and also fix my mail
ASAP:-)
-Original Message-
From: Shawn Guo [mailto:shawn@linaro.org]
Sent: 2012年10月18日 14:38
To: Yong Ding
Cc: Chris Ball; Anton Vorontsov; Marek Szyprowski; Wolfram Sang; Daniel Drake;
Sascha Hauer; Wilson Callan; Ben Dooks; Zhangfei Gao; Kevin Liu; Jialing Fu;
linux-mmc@vger.kernel.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH 1/3] mmc: esdhc: enable polling to detect card by itself
Can you fix your mailer to use bottom posting rather than top posting,
and have texts wrap around column 70? Otherwise, you message stands
a good chance to be ignored by people.
On Wed, Oct 17, 2012 at 11:27:17PM -0700, Yong Ding wrote:
> Shawn,
> Thanks. Oh, sorry I really have missed the fact u mentioned. U are right in
> the current code, the bit will also be cleared for ESDHC_CD_GPIO.
> But I think this is improper since for GPIO detection type, we don't use the
> host controller internal card detection(ESDHC_CD_CONTROLLER), but with
> SDHCI_QUIRK_BROKEN_CARD_DETECTION cleared, we'll still enable/disable
> relevant INT bits (in sdhci_set_card_detection in sdhci.c). This is my
> biggest concern. And I think the SDHCI_QUIRK_BROKEN_CARD_DETECTION shall be
> purely used to notify whether the host controller detection method is used or
> not. So even for the ESDHC_CD_GPIO type, we should still set this flag. How
> do u think?
>
I'm fine with that. Just remind you a fact you seem missed in case
you need to change sdhci-esdhc-imx.c to adapt the changes you are going
to make on sdhci.c.
Shawn
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��g"��^n�r■�z���h�ㄨ��&Ⅷ �G���h�(�茛j"���m赇z罐��帼f＂�h���~�m�
Re: [PATCH] dma: add new DMA control commands
Dear Huang Shijie, Why such massive CC ? > 于 2012年10月18日 14:18, Vinod Koul 写道: > > Why cant you do start (prepare clock etc) when you submit the descriptor > > to dmaengine. Can be done in tx_submit callback. > > Similarly remove the clock when dma transaction gets completed. > > I ever thought this method too. > > But it will become low efficient in the following case: > >Assuming the gpmi-nand driver has to read out 1024 pages in one > _SINGLE_ read operation. > The gpmi-nand will submit the descriptor to dmaengine per page. It will? Then GPMI NAND is flat our broken ... again. > So with > your method, > the system will repeat the enable/disable dma clock 1024 time. Yes, it is the driver that's wrong. > At every > enable/disable dma clock, > the system has to enable the clock chain and it's parents ... > > But with this patch, we only need to enable/disable dma clock one time, > just at we select the nand chip. You are fixing a driver problem at a framework level, wrong. So, check how the MXS SPI driver handles descriptor chaining. Indeed, the Sigmatel screwed the DMA stuff good. But if you analyze the SPI driver, you'll notice a few important points that might come handy when you fix the GPMI NAND driver properly. The direction to take here is: 1) Implement DMA chaining into the GPMI NAND driver 2) You might need to do one PIO transfer to reconfigure the IP registers between each segment of the DMA chain (just as MXS SPI does it) 3) You might run out of DMA descriptors when doing too long chains -- so you might need to fix that part of the mxs DMA driver. > thanks > Huang Shijie Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
