Re: [PATCH v6 0/5] mmc: core: Signal voltage switch procedure for UHS mode
On 29 January 2013 05:32, Kevin Liu keyuan@gmail.com wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Johan Rudholm Sent: Monday, January 28, 2013 10:08 PM To: linux-mmc@vger.kernel.org; Chris Ball Cc: Per Forlin; Ulf Hansson; Fredrik Soderstedt; Kevin Liu; Philip Rakity; Daniel Drake; Aaron; Subhash Jadavani; Sujit Reddy Thumma; Wei WANG; Johan Rudholm Subject: [PATCH v6 0/5] mmc: core: Signal voltage switch procedure for UHS mode This patch series attempts to make the 1.8V signal voltage switch required for UHS mode work according to the SD specification. These patches have been tested with a couple of UHS SD cards, one of which sometimes requires up to five power cycles before it accepts the signal voltage switch. The patches have also been tested with various other SD cards, as well as one SDIO WLAN chip (cw1200) to check for regressions. The patches have also been tested with CONFIG_MMC_CLKGATE. As usual, I'd be very grateful if someone could help me test this patch with an UHS SDIO card and perhaps also a combo card (which does seem to be rare these days?)? This patch series is based on previous RFC/patch: [RFC/PATCH v2] mmc: core: Fixup signal voltage switch and more recently on Kevin Liu's patches: [PATCH v2 1/3] mmc: core: enhance the code for signal voltage setting [PATCH v2 2/3] mmc: core: cycle power the card in voltage switch rather than mmc_sd_get_cid Changelog: v5 - v6 - Rebase - Adapt sd.c to use mmc_host_uhs introduced by mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence v4 - v5 - Reset signal_voltage in struct ios if switch fails v3 - v4 - Added mmc: core: Break out start_signal_voltage_switch, which divides up mmc_set_signal_voltage to avoid a recursive call from mmc_power_up. This removed the third argument (cmd11) of the function - Minor bug fixes v2 - v3 - Minor bug fixes v1 - v2 - Move mmc_power_cycle to the mmc_set_signal_voltage function - Check card_busy before switching voltages - Return -EPERM if signal voltage switch with cmd11 is requested, but no start_signal_voltage_switch is defined. - If we're switching back to 3.3 V, just do the switch without checking card_busy etc v2 - This patch series - Removed the extra argument to the card_busy host_ops function - Added mmc_power_cycle - Some clarifying comments v1 - v2 - Removed reset of signal voltage in mmc_sd_get_cid, since mmc: core: reset signal voltage on power up previous two patches - v1: - Keep calls to mmc_host_clk_hold / mmc_host_clk_release - Add retry-loop / power cycle in sdio.c - Fall back to 3.3 V if the switch repeatedly fails - Add an extra argument to the card_busy host_ops function, which can be used to signal polling use of the function Johan Rudholm (5): mmc: sd: Simplify by using mmc_host_uhs mmc: core: Add mmc_power_cycle mmc: core: Add card_busy to host_ops mmc: core: Break out start_signal_voltage_switch mmc: core: Fixup signal voltage switch drivers/mmc/core/core.c | 114 +++--- drivers/mmc/core/core.h |5 +- drivers/mmc/core/mmc.c |8 ++-- drivers/mmc/core/sd.c| 27 +++ drivers/mmc/core/sdio.c | 23 -- include/linux/mmc/host.h |3 ++ 6 files changed, 145 insertions(+), 35 deletions(-) Tested-by: Kevin Liu kl...@marvell.com Tested with both high speed and UHS sd cards. Tested with emmc chip. Tested with sdio card (non UHS). Tested all the patchset together with below patch (update sdhci.c accordingly) on sdhci-pxav3 platforms. From fc6069b79203f64e7efa8dd0bb295bebcd22f710 Mon Sep 17 00:00:00 2001 From: Kevin Liu kl...@marvell.com Date: Fri, 14 Dec 2012 16:44:10 +0800 Subject: [PATCH v3 3/3] mmc: sdhci: update signal voltage switch code The protocal related code is moved to core stack. So update the host driver accordingly. I think one patch in this set have not got my ack yet, so to be clear, for the hole series: Acked-by: Ulf Hansson ulf.hans...@linaro.org Chris, unless you see some issues with this patch set, could this be merged for 3.9? I have some mmci patches that I would like to upstream that relies on these fixes, and since those goes though Russell's tree I will always one kernel version behind. Kind regards Ulf Hansson -- 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 2/3] mmc: davinci_mmc: add DT support
Hi,
[...]
diff --git a/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
new file mode 100644
index 000..6717ab1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
@@ -0,0 +1,30 @@
+* TI Highspeed MMC host controller for DaVinci
+
+The Highspeed MMC Host Controller on TI DaVinci family
+provides an interface for MMC, SD and SDIO types of memory cards.
+
+This file documents the properties used by the davinci_mmc driver.
+
+Required properties:
+- compatible:
+ Should be ti,davinci-mmc-da830: for da830, da850, dm365
+ Should be ti,davinci-mmc-dm355: for dm355, dm644x
+
+Optional properties:
+- bus-width: Number of data lines, can be 4, or 8, default 1
+- max-frequency: Maximum operating clock frequency, default 25MHz.
+- mmc-cap-mmc-highspeed: Indicates support for MMC in high speed mode
+- mmc-cap-sd-highspeed: Indicates support for SD in high speed mode
[...]
+static struct davinci_mmc_config
+ *mmc_parse_pdata(struct platform_device *pdev)
{
+ struct device_node *np;
struct davinci_mmc_config *pdata = pdev-dev.platform_data;
+ const struct of_device_id *match =
+ of_match_device(of_match_ptr(davinci_mmc_dt_ids), pdev-dev);
+ u32 data;
+
+ np = pdev-dev.of_node;
+ if (!np)
+ return pdata;
+
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev, Failed to allocate memory for struct
davinci_mmc_config\n);
+ goto nodata;
+ }
+
+ if (match-data)
+ pdata-version = (u8)((int)match-data);
+
+ of_property_read_u32(np, max-frequency, pdata-max_freq);
+ if (!pdata-max_freq)
+ dev_info(pdev-dev, 'max-frequency' property not specified,
defaulting to 25MHz\n);
+
+ if (of_get_property(np, mmc-cap-mmc-highspeed, NULL))
+ pdata-caps |= MMC_CAP_MMC_HIGHSPEED;
+ if (of_get_property(np, mmc-cap-sd-highspeed, NULL))
+ pdata-caps |= MMC_CAP_SD_HIGHSPEED;
If these aren't derivable from max-frequency, you could use
of_property_read_bool to make this clearer.
Correct, I will decide these based on max-frequency.
+
+ of_property_read_u32(np, bus-width, data);
+ switch (data) {
+ case 0:
Judging by the binding doc, should this be 1 rather than 0?
By default driver comes up in 4 bit mode when bus-width is not specified.
Bus-width is set to 1 bit for invalid bus-widths. Below are the cases
when bus-width 0 or 4, bus-width is set to 4bit mode
When bus-width is 8, bus-width is set to 8 bit mode
Why is 0 a special value that means 4? Why not just use 4?
Here you just assign 0 to pdata-wires.
I see the current version of the driver handles this specially in
davinci_mmcsd_probe, but I don't see why this should leak into the binding.
What I was originally trying to get at is that the binding says 8, 4, and 1 are
acceptable values, but you check the cases 8, 4, or 0. So you're accepting
something not documented, and producing a warning in a valid case (1).
I thought that if somebody specifies bus-width as 2, 3, 5, 6, 7..., then
it should be defaulted to 1 bit mode, so I specified it as 1 bit in binding
doc.
If they specify something invalid, falling back to a sane value with a warning
sounds good.
But I feel that a person who is editing dts file will not make such a mistake.
I will change binding document to default as 4 bit mode.
There have been and inevitably will be plenty of errors in dts files. I think
it'd be good to provide a warning and either use a value that's guaranteed to
work, or bail out if that can't be done.
If it's always valid to use 1 data line even if the hardware has more, I think
falling back to 1 makes more sense, as it'd be guaranteed to work.
+ case 4:
+ case 8:
+ pdata-wires = data;
+ break;
+ default:
+ pdata-wires = 1;
+ dev_info(pdev-dev, Unsupported buswidth, defaulting to 1
bit\n);
+ }
+nodata:
+ return pdata;
+}
With the first case changed to case 1:, this block makes sense to me.
Thanks,
Mark.
--
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 2/3] mmc: davinci_mmc: add DT support
Hi,
On Fri, Feb 08, 2013 at 15:07:54, Mark Rutland wrote:
Hi,
[...]
diff --git a/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
new file mode 100644
index 000..6717ab1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
@@ -0,0 +1,30 @@
+* TI Highspeed MMC host controller for DaVinci
+
+The Highspeed MMC Host Controller on TI DaVinci family
+provides an interface for MMC, SD and SDIO types of memory cards.
+
+This file documents the properties used by the davinci_mmc driver.
+
+Required properties:
+- compatible:
+ Should be ti,davinci-mmc-da830: for da830, da850, dm365
+ Should be ti,davinci-mmc-dm355: for dm355, dm644x
+
+Optional properties:
+- bus-width: Number of data lines, can be 4, or 8, default 1
+- max-frequency: Maximum operating clock frequency, default 25MHz.
+- mmc-cap-mmc-highspeed: Indicates support for MMC in high speed mode
+- mmc-cap-sd-highspeed: Indicates support for SD in high speed mode
[...]
+static struct davinci_mmc_config
+ *mmc_parse_pdata(struct platform_device *pdev)
{
+ struct device_node *np;
struct davinci_mmc_config *pdata = pdev-dev.platform_data;
+ const struct of_device_id *match =
+ of_match_device(of_match_ptr(davinci_mmc_dt_ids),
pdev-dev);
+ u32 data;
+
+ np = pdev-dev.of_node;
+ if (!np)
+ return pdata;
+
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev, Failed to allocate memory for
struct davinci_mmc_config\n);
+ goto nodata;
+ }
+
+ if (match-data)
+ pdata-version = (u8)((int)match-data);
+
+ of_property_read_u32(np, max-frequency, pdata-max_freq);
+ if (!pdata-max_freq)
+ dev_info(pdev-dev, 'max-frequency' property not
specified, defaulting to 25MHz\n);
+
+ if (of_get_property(np, mmc-cap-mmc-highspeed, NULL))
+ pdata-caps |= MMC_CAP_MMC_HIGHSPEED;
+ if (of_get_property(np, mmc-cap-sd-highspeed, NULL))
+ pdata-caps |= MMC_CAP_SD_HIGHSPEED;
If these aren't derivable from max-frequency, you could use
of_property_read_bool to make this clearer.
Correct, I will decide these based on max-frequency.
+
+ of_property_read_u32(np, bus-width, data);
+ switch (data) {
+ case 0:
Judging by the binding doc, should this be 1 rather than 0?
By default driver comes up in 4 bit mode when bus-width is not specified.
Bus-width is set to 1 bit for invalid bus-widths. Below are the cases
when bus-width 0 or 4, bus-width is set to 4bit mode
When bus-width is 8, bus-width is set to 8 bit mode
Why is 0 a special value that means 4? Why not just use 4?
Here you just assign 0 to pdata-wires.
I see the current version of the driver handles this specially in
davinci_mmcsd_probe, but I don't see why this should leak into the binding.
Yes, I was trying to push in current driver behavior into binding documentation.
What I was originally trying to get at is that the binding says 8, 4, and 1
are
acceptable values, but you check the cases 8, 4, or 0. So you're accepting
something not documented, and producing a warning in a valid case (1).
Valid point.
I thought that if somebody specifies bus-width as 2, 3, 5, 6, 7..., then
it should be defaulted to 1 bit mode, so I specified it as 1 bit in binding
doc.
If they specify something invalid, falling back to a sane value with a warning
sounds good.
True.
But I feel that a person who is editing dts file will not make such a
mistake.
I will change binding document to default as 4 bit mode.
There have been and inevitably will be plenty of errors in dts files. I think
it'd be good to provide a warning and either use a value that's guaranteed to
work, or bail out if that can't be done.
If it's always valid to use 1 data line even if the hardware has more, I think
falling back to 1 makes more sense, as it'd be guaranteed to work.
I completely agree with you, thanks for your inputs.
Will add valid case 1:
Thanks,
Prakash
+ case 4:
+ case 8:
+ pdata-wires = data;
+ break;
+ default:
+ pdata-wires = 1;
+ dev_info(pdev-dev, Unsupported buswidth, defaulting
to 1 bit\n);
+ }
+nodata:
+ return pdata;
+}
With the first case changed to case 1:, this block makes sense to me.
Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to
Re: [PATCH 1/2] mmc: core: fix permanent sleep of mmcqd during card removal
Works for me.
Tested-by: Konstantin Dorfman kdorf...@codeaurora.org
On 01/22/2013 12:48 PM, Seungwon Jeon wrote:
This patch is derived from 'mmc: fix async request mechanism ...'.
According as async transfer, a request is handled with twice mmc_start_req.
When the card is removed, the request is actually not issued in the first
mmc_start_req [__mmc_start_data_req]. And then mmc_wait_for_data_req_done
will come in the next mmc_start_req. But there is no event for completions.
wake_up_interruptible is needed in __mmc_start_data_req for the case of
removed card.
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
drivers/mmc/core/core.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 8b3a122..997b257 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -350,6 +350,7 @@ static int __mmc_start_data_req(struct mmc_host *host,
struct mmc_request *mrq)
mrq-host = host;
if (mmc_card_removed(host-card)) {
mrq-cmd-error = -ENOMEDIUM;
+ mmc_wait_data_done(mrq);
return -ENOMEDIUM;
}
mmc_start_request(host, mrq);
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.
On Thu, 20 Dec 2012 23:12:12 +0100, Andreas Fenkart
andreas.fenk...@streamunlimited.com wrote:
Without functional clock the omap_hsmmc module can't forward
SDIO IRQs to the system. This patch reconfigures dat1 line
as a gpio while the fclk is off. And uses SDIO IRQ detection of
the module, while fclk is present.
Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 42
arch/arm/plat-omap/include/plat/mmc.h |4 +
drivers/mmc/host/omap_hsmmc.c | 219
++--
3 files changed, 247 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index d1b8932..4d57637 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -24,6 +24,29 @@ 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.
+ti,cirq-gpio: When omap_hsmmc module is suspended, its functional
+clock is turned off. Without fclk it can't forward SDIO IRQs to the
+system. For that to happen, it needs to tell the PRCM to restore
+its fclk, which is done through the swakeup line.
+
+ --
+ | PRCM |
+ --
+| ^
+ fclk | | swakeup
+v |
+ --- --
+ -- IRQ -- | hsmmc | -- CIRQ -- | card |
+ --- --
+
+The problem is, that on the AM335x family the swakeup line is
+missing, it has not been routed from the module to the PRCM.
+The way to work around this, is to reconfigure the dat1 line as a
+GPIO upon suspend. Beyond this option you also need to set named
+states default and idle in the .dts file for the pins, using
+pinctrl-single.c. The MMC driver will then then toggle between
+default and idle during the runtime.
+
Examples:
@@ -53,3 +76,22 @@ Examples:
edma 25;
dma-names = tx, rx;
};
+
+[am335x with with gpio for sdio irq]
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
+ ;
+ };
+
+ mmc1: mmc@4806 {
+ pinctrl-names = default, idle;
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_cirq_pin;
+ ti,cirq-gpio = gpio3 28 0;
+ ti,non-removable;
+ bus-width = 4;
+ vmmc-supply = ldo2_reg;
+ vmmc_aux-supply = vmmc;
+ };
Binding looks reasonable.
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
--
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 v9 0/2] mmc: support packed command feature of eMMC4.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 v9 0/2] mmc: support packed command feature of eMMC4.5
Hi Seungwon Jeon, Your findings on the packed reads are very interesting. Thanks for sharing. Regarding the write packing: We tested the write packing feature on 4 different card vendors with msm_sdcc controller, using the following benchmarks: tiotest seq:tiotest -t 1 -d /data -f 800 -b $((512*1024)) -k 1 -k 3 tiotest rand: tiotest -t 4 -d /data -f 800 -b 4096 -k 2 -k 0 -p -s 2012 -r 12500 -n 20 lmdd write: lmdd if=internal of=/data/push1 bs=128k count=2000 sync=1 iozone (many flushes): iozone -i0 -i2 -r4k s100m -O -o -I -f /data/file3 iozone: iozone -i0 -i2 -r4k s100m -O -I -f /data/file3 Our conclusions are as follows: - In case the card supports write packing in API level only, there is no improvement - Some of cards benefit from the write packing for sequential scenarios (~30% improvement) - Some of the cards benefit from the write packing for random scenarios (with tiotest we could even see doubling the performance with write packing) All the above tests were performed with HS-200. The results were collected using the previous version of the patch. I have a very busy week and Im not sure I will be able to test the new version of the patch. I will make an effort to test it as soon as I have some free time. Thanks, Maya This patch-set adds support of packed command feature for eMMC4.5 devices. Specially, packed write is introduced. Seeing the NAND flash, write is expensive operation including the block management internally. Because write data cannot be overwritten on the NAND cell, additional operation is needed. Overhead of the management can be reduced with once large write size rather than several data of small size. That is when writing large amounts of data, eMMC gives a significant speed advantage. Packed write can help it by gathering the data. Actually we got the performance gain. For experiments, three eMMCs of different type from two vendor are used. Additionally, there is a interesting result for packed read. Packed read has been excluded from whole patch-set with a performance regression conclusively. I found the reason for this regression. As we know, asynchronous transfer improves the performance over than 20% for the read. And I found that packed read actually gives performance gain of 2% only if asynchronous transfer is disabled. This shows that asynchronous transfer is more effective than packed read although packed read is a bit useful. When several requests is packed for read, asynchronous transfer doesn't occur. That is packed read replaces asynchronous transfer. Choice of packed read equals to the abandonment of asynchronous transfer. This also means the abandonment of performance advantage. As a result, asynchronous transfer is currently best choice regarding the read. Changes in v9: - Rebase with the latest mmc. - Rework including reconstitution of data struct, on the whole. * Extend the number of blocks for packed header considering large sector (according to the eMMC 4.51) * Use flag of mmc_blk_data to identify permission of packed command. * Check the max commands strictly conforming to mandatory minimum values of spec. Note: These patch-set is dependant in the following patch. [PATCH 2/2] mmc: block: don't start new request when the card is removed Changes in v8: - Ensure the alignment of sector size for native 4KB sector in command packing(from Subhash Jadavani) - Exclude packed read in this phase due to performance issue. Changes in v7: - Break the endless execution in some error handling(from Maya Erez). - Change the condition for enabling packed command(from Subhash Jadavani). - Spilt the error related routine from mmc_blk_issue_rw_rq. Changes in v6: - Split the patch for packed read. - Remove the unnecessary code. Changes in v5: - Revert Add a variable member in mmc_host for minimum number of packed entries. - Fix the partial packed command from failure index. - Clean an unnecessary parameter of mmc_blk_packed_hdr_wrq_prep - Clean warning of checkpatch. Changes in v4: - Add Data-tag as CMD23 argument for packed header. - Separate the capability of MMC_CAP2_PACKED_CMD into read and write. - Remove unncessary initial value. Changes in v3: - Add a variable member in mmc_host for minimum number of packed entries. This value can be overridden by host. - Fix a handling of error sequence. Changes in v2: - Fix the packed read sequence and error handling. - Apply checking the exception status for all cases with the comments from Maya Erez and Sahitya Tummala. - Fix preparing the packed list with the comment from Maya Erez and Venkatraman. Seungwon Jeon (2): mmc: add packed command feature of eMMC4.5 mmc: support packed write command for eMMC4.5 device drivers/mmc/card/block.c |
Re: [PATCH] mfd:rtsx: Fix issue that booting OS with SD card inserted
Hi Wei, On Fri, Feb 08, 2013 at 03:24:27PM +0800, wei_w...@realsil.com.cn wrote: From: Wei WANG wei_w...@realsil.com.cn Realtek card reader supports both SD and MS card. According to the settings of rtsx MFD driver, SD host will be probed before MS host. If we boot/reboot Linux with SD card inserted, the resetting flow of SD card will succeed, and the following resetting flow of MS is sure to fail. Then MS upper-level driver will ask rtsx driver to turn power off. This request leads to the result that the following SD commands fail and SD card can't be accessed again. In this commit, Realtek's SD and MS host driver will check whether the card that upper driver requesting is the one existing in the slot. If not, Realtek's host driver will refuse the operation to make sure the exlusive accessing at the same time. Signed-off-by: Wei WANG wei_w...@realsil.com.cn --- drivers/memstick/host/rtsx_pci_ms.c |7 +++ drivers/mfd/rtsx_pcr.c | 30 ++ drivers/mmc/host/rtsx_pci_sdmmc.c | 18 ++ include/linux/mfd/rtsx_pci.h|2 ++ 4 files changed, 57 insertions(+) Patch applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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: s3cmci: moved mach/regs-sdi.h into s3cmci device driver
Kukjin Kim wrote: Sylwester Nawrocki wrote: Hi, Hi, On 02/02/2013 01:45 AM, Kukjin Kim wrote: Since mach/regs-sdi.h is used only for s3cmci.c, so this moves the header file into the driver file, drivers/mmc/host/s3cmci.c file. Signed-off-by: Kukjin Kimkgene@samsung.com FIW, I have tested this patch on mini2440 board: Tested-by: Sylwester Nawrocki sylvester.nawro...@gmail.com Sylwester, thanks for your test :-) Chris, if you're ok on this, please take this in your tree. Or if you want, let me pick this up in Samsung tree. Applied into Samsung tree, thanks. - Kukjin -- 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: dt: bus-width can be an optional property
On Mon, 21 Jan 2013 19:02:29 +0800, Shawn Guo shawn@linaro.org wrote: None of mmc drivers implements bus-width as a required device tree property. Instead, some drivers like atmel-mci, dw_mmc, sdhci-s3c implement it as an optional one, and will force bus width to be 1 when the property is absent. Let's change the common binding to reflect what the drivers are usually doing. Signed-off-by: Shawn Guo shawn@linaro.org Cc: devicetree-disc...@lists.ozlabs.org Acked-by: Grant Likely grant.lik...@secretlab.ca --- Documentation/devicetree/bindings/mmc/mmc.txt |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index a591c67..cef217d 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -6,9 +6,6 @@ Interpreted by the OF core: - reg: Registers location and length. - interrupts: Interrupts used by the MMC controller. -Required properties: -- bus-width: Number of data lines, can be 1, 4, or 8 - Card detection: If no property below is supplied, standard SDHCI card detect is used. Only one of the properties in this section should be supplied: @@ -17,6 +14,8 @@ Only one of the properties in this section should be supplied: - non-removable: non-removable slot (like eMMC); assume always present. Optional properties: +- bus-width: Number of data lines, can be 1, 4, or 8. The default + will be 1 if the property is absent. - wp-gpios: Specify GPIOs for write protection, see gpio binding - cd-inverted: when present, polarity on the cd gpio line is inverted - wp-inverted: when present, polarity on the wp gpio line is inverted -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- 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 REPOST] mmc: bcm2835: set SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK does basically the same as
implementing struct sdhci_ops .get_timeout_clock, so simply set that
quirk and remove the custom code to simplify the driver.
Reported-by: Lars-Peter Clausen l...@metafoo.de
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
drivers/mmc/host/sdhci-bcm2835.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
index 453825f..21fc735 100644
--- a/drivers/mmc/host/sdhci-bcm2835.c
+++ b/drivers/mmc/host/sdhci-bcm2835.c
@@ -133,14 +133,6 @@ unsigned int bcm2835_sdhci_get_min_clock(struct sdhci_host
*host)
return MIN_FREQ;
}
-unsigned int bcm2835_sdhci_get_timeout_clock(struct sdhci_host *host)
-{
- struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
- struct bcm2835_sdhci *bcm2835_host = pltfm_host-priv;
-
- return clk_get_rate(bcm2835_host-clk);
-}
-
static struct sdhci_ops bcm2835_sdhci_ops = {
.write_l = bcm2835_sdhci_writel,
.write_w = bcm2835_sdhci_writew,
@@ -150,11 +142,11 @@ static struct sdhci_ops bcm2835_sdhci_ops = {
.read_b = bcm2835_sdhci_readb,
.get_max_clock = bcm2835_sdhci_get_max_clock,
.get_min_clock = bcm2835_sdhci_get_min_clock,
- .get_timeout_clock = bcm2835_sdhci_get_timeout_clock,
};
static struct sdhci_pltfm_data bcm2835_sdhci_pdata = {
- .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION,
+ .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
+ SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
.ops = bcm2835_sdhci_ops,
};
--
1.7.10.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
