Re: [PATCH 1/7 v2] dmaengine: add a simple dma library
On Thu, 2012-01-26 at 15:56 +0100, Guennadi Liakhovetski wrote: This patch adds a library of functions, helping to implement dmaengine drivers for hardware, unable to handle scatter-gather lists natively. The first version of this driver only supports memcpy and slave DMA operation. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- v2: 1. switch from using a tasklet to threaded IRQ, which allowed to 2. remove lock / unlock inline functions 3. remove __devinit, __devexit annotations Sorry to join the discussion late, was on vacation, travel, long weekend... I don't still comprehend the need for a library on top of dmaengine which gain is just a library between clients and dmacs. Surely we don't want to write another abstraction on top of one provided? If the question is to handle scatter-gather even if the hardware doesn't have the capability, then why don't add that in dmaengine itself rather than one more layer? -- ~Vinod -- 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/7 v2] dmaengine: add a simple dma library
Hi Vinod Thanks for your email. On Mon, 30 Jan 2012, Vinod Koul wrote: On Thu, 2012-01-26 at 15:56 +0100, Guennadi Liakhovetski wrote: This patch adds a library of functions, helping to implement dmaengine drivers for hardware, unable to handle scatter-gather lists natively. The first version of this driver only supports memcpy and slave DMA operation. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- v2: 1. switch from using a tasklet to threaded IRQ, which allowed to 2. remove lock / unlock inline functions 3. remove __devinit, __devexit annotations Sorry to join the discussion late, was on vacation, travel, long weekend... I don't still comprehend the need for a library on top of dmaengine which gain is just a library between clients and dmacs. Surely we don't want to write another abstraction on top of one provided? If the question is to handle scatter-gather even if the hardware doesn't have the capability, then why don't add that in dmaengine itself rather than one more layer? Well, yes, adding new abstraction layers is always a decision, that has to be well justified. In this case it does at least make the life easier for two sh-mobile drivers: shdma and the new SUDMAC driver. However, I did name the library in a generic way without reference to sh, assuming, that it might with time become useful for other architectures too. The reasons why I prefered to keep it as an optional addition to dmaengine core, instead of tightly integrating it with it are, that (1) I did not want to add useless code to drivers, that do not need it, (2) I am not sure if and when this library will become useful for other drivers: apart from sh I am only familiar with one more dmaengine driver: ipu/ipu_idmac.c, and that one supports scatter-gather lists in a limited way and has some further peculiarities, that would likely make it a bad match for the simple DMA library, (3) keeping it separate makes its further development easier. OTOH, I'm certainly fine with a tighter library integration with the dmaengine core. I think, it still would be better to keep it in a separate file and only build it if needed, right? This woult also simplify code debugging and further development. I can remove the simple notation, which does make it look like an additional abstraction layer, and replace it with, say, sgsoft (scatter-gather software implementation)? A more interesting question is what to do with struct dma_simple_dev, struct dma_simple_chan, struct dma_simple_desc, that embed struct dma_device, struct dma_chan and struct dma_async_tx_descriptor respectively. I don't think we want to merge all the additions from those wrapping structs back into their dmaengine counterparts? How would you like to do this? Don't you think, it would be good to allow both: either implement a dmaengine driver directly, exactly as all drivers are doing now, or use the additional helper library for suitable (simple) hardware types? I see it similar to I2C, where you either implement an I2C driver directly, or you use the bitbanging abstraction for simpler hardware. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 6/6] mmc: sdhci-s3c: Add device tree support
Am Mittwoch, 2. November 2011, 21:36:03 schrieb Thomas Abraham:
Hi Thomas,
in patch 1/6:
+static struct platform_device_id sdhci_s3c_driver_ids[] = {
+ {
+ .name = s3c-sdhci,
+ .driver_data= (kernel_ulong_t)NULL,
+ },
+ {
+ .name = exynos4-sdhci,
+ .driver_data= EXYNOS4_SDHCI_DRV_DATA,
+ },
+};
+MODULE_DEVICE_TABLE(platform, sdhci_s3c_driver_ids);
and in patch 6/6:
+#ifdef CONFIG_OF
+static const struct of_device_id sdhci_s3c_dt_match[] = {
+ { .compatible = samsung,s3c6410-sdhci, },
+ { .compatible = samsung,exynos4210-sdhci,
+ .data = exynos4_sdhci_drv_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sdhci_s3c_dt_match);
wouldn't it be better to keep the naming consistent between of and non-of?
I.e. s3c-sdhci vs. s3c6410-sdhci. Since the driver is used for all S3C SoCs
containing hsmmc controllers I think s3c-sdhci would be preferable here.
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
Re: omap_hsmmc.c and MMC_CAP_SDIO_IRQ
Hello Steve, on 01/27/2012 03:09 PM Steve Sakoman said the following: On Tue, Jan 24, 2012 at 6:33 AM, Michael Hunold hun...@linuxtv.org wrote: Your summary below is a pretty accurate description of the current state. Ok. I've made an attempt at creating a patch for 3.2 that follows David Vrabel's original patch series as closely as possible with the new structure. Unfortunately it doesn't quite work. I've only been doing this as a background task so progress is pretty slow. I understand, no problem. The patch doesn't seem to break support for memory devices (which is good since my rootfs is on an mmc device!) and I do see SDIO interrupts occurring and being handled in the debug log, so it is a good start: However the SDIO device does not function properly due to multiple timeout errors, so something is still not quite right. Let me know if you would like to help with further development of the patch and I will send you a copy. It is rough enough and broken enough that it probably isn't yet ready for even an RFC to these lists. Yes, please send them to me. I will give them a try and let you know the results. As a side node: actually I'm working double tracked. I plan to use it on some OMAP-based board like Beagleboard or Pandaboard for a stationary system, running any kernel that is needed. But I'd like to use some spare N900s as well, because I can carry them around easily. But these are running ancient 2.6.28.1 kernels. David Vrabel mentioned that he originally developed his patches on the N900. I sent him a mail using his mail address from csr.com, but I have not received a reply yet. If you or anybody else has every seen his original patches for the N900 (he did not sent them to any list as far as I know) please let me know as well. Regards, Steve CU Michael. -- 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 0/2] mmc: sdhci-pci: fixes for Medfield SDIO suspend / resume
Hi Here are a couple of fixes for Medfield SDIO suspend / resume. Adrian Hunter (2): mmc: sdhci-pci: set Medfield SDIO as non-removable mmc: sdhci: always reset all during resume drivers/mmc/host/sdhci-pci.c |2 +- drivers/mmc/host/sdhci.c | 29 +++-- 2 files changed, 12 insertions(+), 19 deletions(-) Regards Adrian -- 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: sdhci-pci: set Medfield SDIO as non-removable
Set Medfield SDIO as non-removable to avoid un-necessary
card detect activity.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
drivers/mmc/host/sdhci-pci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
index 7165e6a..6ebdc40 100644
--- a/drivers/mmc/host/sdhci-pci.c
+++ b/drivers/mmc/host/sdhci-pci.c
@@ -250,7 +250,7 @@ static int mfd_emmc_probe_slot(struct sdhci_pci_slot *slot)
static int mfd_sdio_probe_slot(struct sdhci_pci_slot *slot)
{
- slot-host-mmc-caps |= MMC_CAP_POWER_OFF_CARD;
+ slot-host-mmc-caps |= MMC_CAP_POWER_OFF_CARD | MMC_CAP_NONREMOVABLE;
return 0;
}
--
1.7.6.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] mmc: core: Ensure clocks are always enabled before host interaction
On Tue, Jan 24, 2012 at 4:44 AM, Sujit Reddy Thumma sthu...@codeaurora.org wrote: Hi Linus Walleij, On 12/30/2011 7:44 AM, Linus Walleij wrote: On Mon, Dec 12, 2011 at 9:21 AM, Sujit Reddy Thumma sthu...@codeaurora.org wrote: Ensure clocks are always enabled before any interaction with the host controller driver. This makes sure that there is no race between host execution and the core layer turning off clocks in different context with clock gating framework. Signed-off-by: Sujit Reddy Thummasthu...@codeaurora.org I guess Per Förlin may not be available, but would have preferred to have his view on this as well, since he knows the semantics of pre/post-req. I have checked the implementation for pre-req and post-req in mmc host drivers. There is no interaction to the controller or card registers in these functions, but in future if drivers appeal to configure their controller in these functions then we must have clocks enabled. Per, if you are available can you comment on this? I just got back from 2 months of leave so I apologize for not being up to date. It makes sense to ensure clocking in pre-req() and post-req() implemented by this patch. My only concern from a throughput point of view is if the clocking adds an overhead, but AFAIK the clocking doesn't add an overhead (that would increase the prepare time). Currently the pre-req() and post-req() only prepares DMA for next transfer without interacting with the controller. The intention is to increase throughput by minimizing start latency for the next transfer. It's perfectly ok to do other useful preparations in these hooks as well. The hooks are generic. It should be possible to do clock dependent stuff in these hooks too, it's up to the host driver to do what's best. Acked-by: Per Forlin per.for...@stericsson.com Thanks, Per -- 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/1] of_mmc_spi: fix little endian support
On Mon, Jan 30, 2012 at 05:15:29AM +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
the voltage_ranges is supposed to switch from big endian to little endian
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: linux-mmc@vger.kernel.org
Applied, thanks.
g.
---
drivers/mmc/host/of_mmc_spi.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/of_mmc_spi.c b/drivers/mmc/host/of_mmc_spi.c
index ab66f24..ede2c64 100644
--- a/drivers/mmc/host/of_mmc_spi.c
+++ b/drivers/mmc/host/of_mmc_spi.c
@@ -109,12 +109,13 @@ struct mmc_spi_platform_data *mmc_spi_get_pdata(struct
spi_device *spi)
goto err_ocr;
}
+
for (i = 0; i num_ranges; i++) {
const int j = i * 2;
u32 mask;
- mask = mmc_vddrange_to_ocrmask(voltage_ranges[j],
-voltage_ranges[j + 1]);
+ mask = mmc_vddrange_to_ocrmask(be32_to_cpu(voltage_ranges[j]),
+be32_to_cpu(voltage_ranges[j +
1]));
if (!mask) {
ret = -EINVAL;
dev_err(dev, OF: voltage-range #%d is invalid\n, i);
--
1.7.7
--
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/1] of_mmc_spi: fix little endian support
On Mon, Jan 30, 2012 at 6:14 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Mon, Jan 30, 2012 at 05:15:29AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: the voltage_ranges is supposed to switch from big endian to little endian Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: linux-mmc@vger.kernel.org Applied, thanks. Actually, this one should go via Chris' tree since it is part of drivers/mmc. So I've dropped it from my tree and change that s-o-b of mine to an a-b. g. -- 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/1] of_mmc_spi: fix little endian support
Hi, On Mon, Jan 30 2012, Grant Likely wrote: On Mon, Jan 30, 2012 at 6:14 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Mon, Jan 30, 2012 at 05:15:29AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: the voltage_ranges is supposed to switch from big endian to little endian Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: linux-mmc@vger.kernel.org Applied, thanks. Actually, this one should go via Chris' tree since it is part of drivers/mmc. So I've dropped it from my tree and change that s-o-b of mine to an a-b. Thanks, done that, and removed the extra/incorrect punctuation change from the patch. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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] mmc: core: Ensure clocks are always enabled before host interaction
On Mon, Jan 30, 2012 at 1:48 PM, Per Forlin per.l...@gmail.com wrote: It makes sense to ensure clocking in pre-req() and post-req() implemented by this patch. My only concern from a throughput point of view is if the clocking adds an overhead, but AFAIK the clocking doesn't add an overhead (that would increase the prepare time). Shouldn't be a concern here since there is already a hysteresis window across these calls, so the clock never get disabled on back-to-back transfers AFAICT. Acked-by: Per Forlin per.for...@stericsson.com Thanks, Linus Walleij -- 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 6/6] mmc: sdhci-s3c: Add device tree support
On Mon, Jan 30, 2012 at 10:51:11AM +0100, Heiko Stübner wrote:
Am Mittwoch, 2. November 2011, 21:36:03 schrieb Thomas Abraham:
Hi Thomas,
in patch 1/6:
+static struct platform_device_id sdhci_s3c_driver_ids[] = {
+ {
+ .name = s3c-sdhci,
+ .driver_data= (kernel_ulong_t)NULL,
+ },
+ {
+ .name = exynos4-sdhci,
+ .driver_data= EXYNOS4_SDHCI_DRV_DATA,
+ },
+};
+MODULE_DEVICE_TABLE(platform, sdhci_s3c_driver_ids);
and in patch 6/6:
+#ifdef CONFIG_OF
+static const struct of_device_id sdhci_s3c_dt_match[] = {
+ { .compatible = samsung,s3c6410-sdhci, },
+ { .compatible = samsung,exynos4210-sdhci,
+ .data = exynos4_sdhci_drv_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sdhci_s3c_dt_match);
wouldn't it be better to keep the naming consistent between of and non-of?
I.e. s3c-sdhci vs. s3c6410-sdhci. Since the driver is used for all S3C SoCs
containing hsmmc controllers I think s3c-sdhci would be preferable here.
History has shown that future devices aren't always compatible with earlier
ones. Compatible strings are expected to be specific to an exact device to
reduce the possibility of new hardware breaking assumptions.
Instead, new hardware can either claim compatibility with older
compatible strings (the compatible property in the DT is a list), or
can have the new string added to the match table in the driver;
whichever option makes the most sense.
g.
--
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 03/16] mmc: fix for some -Wuninitialized warning
Fix for some -Wuninitialized compiler warnings, by moving the
retry block up so that from, nr and arg variables get set correctly
if the code jumps from the out-block.
Signed-off-by: Danny Kukawka danny.kuka...@bisect.de
---
drivers/mmc/card/block.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 0cad48a..c9350ae 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -889,6 +889,7 @@ static int mmc_blk_issue_secdiscard_rq(struct mmc_queue *mq,
goto out;
}
+retry:
from = blk_rq_pos(req);
nr = blk_rq_sectors(req);
@@ -896,7 +897,7 @@ static int mmc_blk_issue_secdiscard_rq(struct mmc_queue *mq,
arg = MMC_SECURE_TRIM1_ARG;
else
arg = MMC_SECURE_ERASE_ARG;
-retry:
+
if (card-quirks MMC_QUIRK_INAND_CMD38) {
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
INAND_CMD38_ARG_EXT_CSD,
--
1.7.7.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
[RESEND PATCH] mmc: core: add the capability for broken voltage
To Chris...
Samsung-SoC need to add this patch..i want to merge so early.
This patch is added the MMC_CAP2_BROKEN_VOLTAGE.
There is an understood mismatch between the voltage the host controller is
set to and the voltage supplied to the card by a fixed voltage regulator.
Teaching the driver to accept the mismatch is overly complicated. Instead
just accept the regulator's voltage.
if the voltage didn't satisfy between min_uV and max_uV,
try to change the voltage in core.c.
When change the voltage, maybe use the regulator_set_voltage().
In regulator_set_voltage(), check the below condition.
/* sanity check */
if (!rdev-desc-ops-set_voltage
!rdev-desc-ops-set_voltage_sel) {
ret = -EINVAL;
goto out;
}
If Some-board should use the fixed-regulator, always return -EINVAL.
Then, eMMC didn't initialize always.
So if use the fixed-regulator or etc, we need to add the
MMC_CAP2_BROKEN_VOLTAGE.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Adrian Hunter adrian.hun...@intel.com
---
drivers/mmc/core/core.c |4
include/linux/mmc/host.h |1 +
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index bec0bf2..6848789 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1121,6 +1121,10 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
* might not allow this operation
*/
voltage = regulator_get_voltage(supply);
+
+ if (mmc-caps2 MMC_CAP2_BROKEN_VOLTAGE)
+ min_uV = max_uV = voltage;
+
if (voltage 0)
result = voltage;
else if (voltage min_uV || voltage max_uV)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index dd13e05..5659aee 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -257,6 +257,7 @@ struct mmc_host {
#define MMC_CAP2_HS200_1_2V_SDR(1 6)/* can support */
#define MMC_CAP2_HS200 (MMC_CAP2_HS200_1_8V_SDR | \
MMC_CAP2_HS200_1_2V_SDR)
+#define MMC_CAP2_BROKEN_VOLTAGE(1 7)/* Use the broken
voltage */
mmc_pm_flag_t pm_caps;/* supported pm features */
--
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] mmc: core: Fix Low speed mmc card detection failure
Hi Chris,
can you consider this patch in your next branch.
regards
Girish K S
On 19 January 2012 08:56, Girish K S girish.shivananja...@linaro.org wrote:
This patch fixes the failure of low speed mmc card detection
Signed-off-by: Girish K S girish.shivananja...@linaro.org
---
drivers/mmc/core/mmc.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index dc03291..2bc586b 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1020,7 +1020,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
err = mmc_select_hs200(card);
else if (host-caps MMC_CAP_MMC_HIGHSPEED)
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_HS_TIMING, 1, 0);
+ EXT_CSD_HS_TIMING, 1,
+ card-ext_csd.generic_cmd6_time);
if (err err != -EBADMSG)
goto free_card;
@@ -1130,7 +1131,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
* Activate wide bus and DDR (if supported).
*/
if (!mmc_card_hs200(card)
- (card-csd.mmca_vsn = CSD_SPEC_VER_3)
+ (card-csd.mmca_vsn = CSD_SPEC_VER_4)
(host-caps (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA))) {
static unsigned ext_csd_bits[][2] = {
{ EXT_CSD_BUS_WIDTH_8, EXT_CSD_DDR_BUS_WIDTH_8 },
--
1.7.1
--
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 V2 02/12] dmaengine: Add flow controller information to dma_slave_config
On Wed, 2012-01-18 at 14:41 +0530, Viresh Kumar wrote:
Flow controller is programmable for few controllers and there are few
intelligent peripherals like, Synopsys JPEG controller, that needs to be a
flow
controller of DMA transfers on dest side.
For this, currently two drivers, pl08x and dw_dmac, support flow controller to
be passed from platform to these drivers.
Perhaps, this should be a part of struct dma_slave_config. This patch adds
another field device_fc to this structure. User drivers must pass this as true
if they want to be flow controller of certain transfers.
Signed-off-by: Viresh Kumar viresh.ku...@st.com
---
include/linux/dmaengine.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 5532bb8..dd1915f 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -25,6 +25,7 @@
#include linux/uio.h
#include linux/scatterlist.h
#include linux/bitmap.h
+#include linux/types.h
#include asm/page.h
/**
@@ -330,6 +331,9 @@ enum dma_slave_buswidth {
* may or may not be applicable on memory sources.
* @dst_maxburst: same as src_maxburst but for destination target
* mutatis mutandis.
+ * @device_fc: Flow Controller Settings for ccfg register. Only valid for
slave
ccfg maybe true for your controller, not others...
+ * channels. Fill with 'true' if peripheral should be flow controller.
Direction
+ * will be selected at Runtime.
*
* This struct is passed in as configuration data to a DMA engine
* in order to set up a certain channel for DMA transport at runtime.
@@ -356,6 +360,7 @@ struct dma_slave_config {
enum dma_slave_buswidth dst_addr_width;
u32 src_maxburst;
u32 dst_maxburst;
+ bool device_fc;
};
static inline const char *dma_chan_name(struct dma_chan *chan)
--
~Vinod
--
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 6/6] mmc: sdhci-s3c: Add device tree support
Am Montag 30 Januar 2012, 20:01:14 schrieb Grant Likely:
On Mon, Jan 30, 2012 at 10:51:11AM +0100, Heiko Stübner wrote:
Am Mittwoch, 2. November 2011, 21:36:03 schrieb Thomas Abraham:
Hi Thomas,
in patch 1/6:
+static struct platform_device_id sdhci_s3c_driver_ids[] = {
+ {
+ .name = s3c-sdhci,
+ .driver_data= (kernel_ulong_t)NULL,
+ },
+ {
+ .name = exynos4-sdhci,
+ .driver_data= EXYNOS4_SDHCI_DRV_DATA,
+ },
+};
+MODULE_DEVICE_TABLE(platform, sdhci_s3c_driver_ids);
and in patch 6/6:
+#ifdef CONFIG_OF
+static const struct of_device_id sdhci_s3c_dt_match[] = {
+ { .compatible = samsung,s3c6410-sdhci, },
+ { .compatible = samsung,exynos4210-sdhci,
+ .data = exynos4_sdhci_drv_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sdhci_s3c_dt_match);
wouldn't it be better to keep the naming consistent between of and
non-of? I.e. s3c-sdhci vs. s3c6410-sdhci. Since the driver is used for
all S3C SoCs containing hsmmc controllers I think s3c-sdhci would be
preferable here.
History has shown that future devices aren't always compatible with earlier
ones. Compatible strings are expected to be specific to an exact device to
reduce the possibility of new hardware breaking assumptions.
Instead, new hardware can either claim compatibility with older
compatible strings (the compatible property in the DT is a list), or
can have the new string added to the match table in the driver;
whichever option makes the most sense.
ah, ok. Thanks for the explanation and I will keep that in mind.
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
Re: [PATCH 1/7 v2] dmaengine: add a simple dma library
On Mon, 2012-01-30 at 10:34 +0100, Guennadi Liakhovetski wrote: I don't still comprehend the need for a library on top of dmaengine which gain is just a library between clients and dmacs. Surely we don't want to write another abstraction on top of one provided? If the question is to handle scatter-gather even if the hardware doesn't have the capability, then why don't add that in dmaengine itself rather than one more layer? Well, yes, adding new abstraction layers is always a decision, that has to be well justified. In this case it does at least make the life easier for two sh-mobile drivers: shdma and the new SUDMAC driver. However, I did name the library in a generic way without reference to sh, assuming, that it might with time become useful for other architectures too. The reasons why I prefered to keep it as an optional addition to dmaengine core, instead of tightly integrating it with it are, that (1) I did not want to add useless code to drivers, that do not need it, So are we sure that only sh-mobile drivers need this capablity? Btw does you hardware only support single transfers and no sg support, would this remain the same in future? (2) I am not sure if and when this library will become useful for other drivers: apart from sh I am only familiar with one more dmaengine driver: ipu/ipu_idmac.c, and that one supports scatter-gather lists in a limited way and has some further peculiarities, that would likely make it a bad match for the simple DMA library, typically the dmacs will support this in some form or other, so your point is valid :) (3) keeping it separate makes its further development easier. OTOH, I'm certainly fine with a tighter library integration with the dmaengine core. I think, it still would be better to keep it in a separate file and only build it if needed, right? This woult also simplify code debugging and further development. I can remove the simple notation, which does make it look like an additional abstraction layer, and replace it with, say, sgsoft (scatter-gather software implementation)? that would be more apt :) A more interesting question is what to do with struct dma_simple_dev, struct dma_simple_chan, struct dma_simple_desc, that embed struct dma_device, struct dma_chan and struct dma_async_tx_descriptor respectively. I don't think we want to merge all the additions from those wrapping structs back into their dmaengine counterparts? Sure they should be kept separate. I like the wrapping, this keeps it simple. How would you like to do this? Don't you think, it would be good to allow both: either implement a dmaengine driver directly, exactly as all drivers are doing now, or use the additional helper library for suitable (simple) hardware types? I see it similar to I2C, where you either implement an I2C driver directly, or you use the bitbanging abstraction for simpler hardware. I think it would be good to have both, this can be used by folks who don't have sg support available. -- ~Vinod -- 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 0/0] mmc: use capability for the broken voltage
This patch-set is supported the broken-voltage capability. Jaehoon Chung (2): mmc: core: support broken voltage mmc: sdhci-s3c: support the broken voltage drivers/mmc/core/core.c |4 drivers/mmc/host/sdhci-s3c.c |7 +++ include/linux/mmc/host.h |1 + 3 files changed, 8 insertions(+), 4 deletions(-) -- 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: add the capability for broken voltage.
This patch is added the MMC_CAP2_BROKEN_VOLTAGE.
There is an understood mismatch between the voltage the host controller is
set to and the voltage supplied to the card by a fixed voltage regulator.
Teaching the driver to accept the mismatch is overly complicated. Instead
just accept the regulator's voltage.
if the voltage didn't satisfy between min_uV and max_uV,
try to change the voltage in core.c.
When change the voltage, maybe use the regulator_set_voltage().
In regulator_set_voltage(), check the below condition.
/* sanity check */
if (!rdev-desc-ops-set_voltage
!rdev-desc-ops-set_voltage_sel) {
ret = -EINVAL;
goto out;
}
If Some-board should use the fixed-regulator, always return -EINVAL.
Then, eMMC didn't initialize always.
So if use the fixed-regulator or etc, we need to add the
MMC_CAP2_BROKEN_VOLTAGE.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Adrian Hunter adrian.hun...@intel.com
---
drivers/mmc/core/core.c |4
include/linux/mmc/host.h |1 +
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index bec0bf2..6848789 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1121,6 +1121,10 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
* might not allow this operation
*/
voltage = regulator_get_voltage(supply);
+
+ if (mmc-caps2 MMC_CAP2_BROKEN_VOLTAGE)
+ min_uV = max_uV = voltage;
+
if (voltage 0)
result = voltage;
else if (voltage min_uV || voltage max_uV)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index dd13e05..5659aee 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -257,6 +257,7 @@ struct mmc_host {
#define MMC_CAP2_HS200_1_2V_SDR(1 6)/* can support */
#define MMC_CAP2_HS200 (MMC_CAP2_HS200_1_8V_SDR | \
MMC_CAP2_HS200_1_2V_SDR)
+#define MMC_CAP2_BROKEN_VOLTAGE(1 7)/* Use the broken
voltage */
mmc_pm_flag_t pm_caps;/* supported pm features */
--
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: sdhci-s3c: support the broken voltage.
Samsung-SoC need to add the MMC_CAP2_BROKEN_VOLTAGE.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/host/sdhci-s3c.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index d065e37..e7e2b6b 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -521,9 +521,12 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
if (pdata-cd_type == S3C_SDHCI_CD_PERMANENT)
host-mmc-caps = MMC_CAP_NONREMOVABLE;
+ /* It supports additional host capabilities if needed */
if (pdata-host_caps)
host-mmc-caps |= pdata-host_caps;
+ host-mmc-caps2 = MMC_CAP2_BROKEN_VOLTAGE;
+
if (pdata-pm_caps)
host-mmc-pm_caps |= pdata-pm_caps;
@@ -543,10 +546,6 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
sdhci_s3c_ops.get_max_clock = sdhci_cmu_get_max_clock;
}
- /* It supports additional host capabilities if needed */
- if (pdata-host_caps)
- host-mmc-caps |= pdata-host_caps;
-
ret = sdhci_add_host(host);
if (ret) {
dev_err(dev, sdhci_add_host() failed\n);
--
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
