Re: [PATCH] mmc: dw_mmc: handle data blocks than 4kB if IDMAC is used
Hi, Alexey. On 07/09/2015 10:04 PM, Alexey Brodkin wrote: Hi Jaehoon, On Wed, 2015-07-08 at 11:45 +0300, Alexey Brodkin wrote: Let me know if that description makes sense to you. I'm wondering if you had a chance to look at my comments and if those comments make sense or you need more input from me. As my understanding, it makes sense. If page size should be changed bigger than 4K, internal dma should not be working fine. (Especially your case..Page size is 8K.) I will pick this patch at my dw-mmc tree. Thanks for your effort and pointing out! :) Best Regards, Jaehoon Chung -Alexey-- 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 0/6] mmc: sdhci-esdhci-imx: fix cd/wp regression
Am 09.07.2015 um 15:27 schrieb Shawn Guo: Oh, crap! I thought it's been there with only v4.2-rc1, and did not know v4.1 is already broken. In that case, reverting 8d86e4f isn't the best option. I suggest you rebase the dts series on top of v4.2-rc1, and send it via mmc tree. Yeah, I already stumbled across that. Fortunately, I dont need it at all, so I just removed it from dts: diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi b/arch/arm/boot/dts/imx53-tqma53.dtsi index 2dea6dc..3c545e3 100644 --- a/arch/arm/boot/dts/imx53-tqma53.dtsi +++ b/arch/arm/boot/dts/imx53-tqma53.dtsi @@ -41,7 +41,6 @@ pinctrl-0 = pinctrl_esdhc2, pinctrl_esdhc2_cdwp; vmmc-supply = reg_3p3v; - wp-gpios = gpio1 2 0; cd-gpios = gpio1 4 0; status = disabled; }; --mtx https://www.facebook.com/MELAG.Medizintechnik [http://www.melag.de/fbbanner.png]https://www.facebook.com/MELAG.Medizintechnik MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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-esdhc: add default quirk SDHCI_QUIRK_NO_HISPD_BIT
eSDHC supports high speed mode, but has no enabling bit for it. Add this quirk to avoid writing to eSDHC_PROCTL[DTW] by mistake. Signed-off-by: Yangbo Lu yangbo...@freescale.com --- drivers/mmc/host/sdhci-esdhc.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h index 3497cfa..1b2c4f9 100644 --- a/drivers/mmc/host/sdhci-esdhc.h +++ b/drivers/mmc/host/sdhci-esdhc.h @@ -21,7 +21,8 @@ #define ESDHC_DEFAULT_QUIRKS (SDHCI_QUIRK_FORCE_BLK_SZ_2048 | \ SDHCI_QUIRK_NO_BUSY_IRQ | \ SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK | \ - SDHCI_QUIRK_PIO_NEEDS_DELAY) + SDHCI_QUIRK_PIO_NEEDS_DELAY | \ + SDHCI_QUIRK_NO_HISPD_BIT) #define ESDHC_SYSTEM_CONTROL 0x2c #define ESDHC_CLOCK_MASK 0xfff0 -- 2.1.0.27.g96db324 -- 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-pltfm: add broken ADMA quirk for T4240 board
eMMC build-in on T4240 board can't work when using ADMA to transfer data, but SDHC card could work well. No erratum provided, use SDMA instead to get it to work first. Signed-off-by: Yangbo Lu yangbo...@freescale.com --- drivers/mmc/host/sdhci-pltfm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index a207f5a..0b4d059 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -95,6 +95,9 @@ void sdhci_get_of_property(struct platform_device *pdev) if (of_device_is_compatible(np, fsl,p2020-rev1-esdhc)) host-quirks |= SDHCI_QUIRK_BROKEN_DMA; + if (of_device_is_compatible(np, fsl,t4240-esdhc)) + host-quirks |= SDHCI_QUIRK_BROKEN_ADMA; + if (of_device_is_compatible(np, fsl,p2020-esdhc) || of_device_is_compatible(np, fsl,p1010-esdhc) || of_device_is_compatible(np, fsl,t4240-esdhc) || -- 2.1.0.27.g96db324 -- 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: sdio: avoid using NULL sdio_irq_thread pointer
For Freescale QorIQ LS1021AQDS board, there is a SDIO interrupt
in the process of resume without inserting SD adapter because of
some unknown issue. But the driver doesn't assign sdio_irq_thread
pointer. This will block the resume of kernel. This patch is used
to avoid using NULL sdio_irq_thread pointer.
Signed-off-by: Yangbo Lu yangbo...@freescale.com
---
include/linux/mmc/host.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 1369e54..83b81fd 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -412,7 +412,8 @@ static inline void mmc_signal_sdio_irq(struct mmc_host
*host)
{
host-ops-enable_sdio_irq(host, 0);
host-sdio_irq_pending = true;
- wake_up_process(host-sdio_irq_thread);
+ if (host-sdio_irq_thread)
+ wake_up_process(host-sdio_irq_thread);
}
void sdio_run_irqs(struct mmc_host *host);
--
2.1.0.27.g96db324
--
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: block: add fixup of broken CMD23 for Sandisk card
Some Sandisk cards(such as SDMB-32 and SDM032 cards) can't support CMD23, and would generate CMD timeout. So add FIX-UP for these two types Sandisk cards. Error log: mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900 mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900 mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900 end_request: I/O error, dev mmcblk0, sector 0 Buffer I/O error on device mmcblk0, logical block 0 mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900 Signed-off-by: Yangbo Lu yangbo...@freescale.com --- drivers/mmc/card/block.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index c9c3d20..d06b9ab 100644 --- a/drivers/mmc/card/block.c +++ b/drivers/mmc/card/block.c @@ -2406,6 +2406,10 @@ static const struct mmc_fixup blk_fixups[] = * * N.B. This doesn't affect SD cards. */ + MMC_FIXUP(SDMB-32, CID_MANFID_SANDISK, CID_OEMID_ANY, add_quirk_mmc, + MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(SDM032, CID_MANFID_SANDISK, CID_OEMID_ANY, add_quirk_mmc, + MMC_QUIRK_BLK_NO_CMD23), MMC_FIXUP(MMC08G, CID_MANFID_TOSHIBA, CID_OEMID_ANY, add_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), MMC_FIXUP(MMC16G, CID_MANFID_TOSHIBA, CID_OEMID_ANY, add_quirk_mmc, -- 2.1.0.27.g96db324 -- 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 0/6] mmc: sdhci-esdhci-imx: fix cd/wp regression
On Thu, Jun 18, 2015 at 02:05:31AM +0800, Dong Aisheng wrote: Commit 8d86e4f mmc: sdhci-esdhc-imx: Call mmc_of_parse() seriously break the sd card detect/write protect function of most IMX platforms since a lot of GPIO flags of cd-gpios/wp-gpios are wrongly set in devicetree. It breaks the following things: My opinion would be that we revert the commit 8d86e4f for v4.2, as it's so broken. 1) cd-gpio function enable Most IMX boards GPIO card detect function becomes unwork and using card polling mode instead by mistake. Openning CONFIG_MMC_DEBUG will easily see that. It is caused by the default quirk SDHCI_QUIRK_BROKEN_CARD_DETECTION is not cleared for dt platform by commit 8d86e4f, then MMC_CAP_NEEDS_POLL is wrongly set. Patch 1~2 is to fix it. 2) cd-gpio/wp-gpio polarity Before commit 8d86e4f, we do not use GPIO flags passed from devicetree. But after it, GPIO flags specfied in dt becomes valid and will affect the normal cd/wp function. This is fixed by another dts fix patch series: [PATCH 0/5] dts: imx: fix sd card gpio polarity specified in device tree http://www.spinics.net/lists/arm-kernel/msg426156.html Since it needs to change a lot board dts files, so i cook the patch based on Shawn/for-next branch to make sure all board dts file are changed in the same time. The dts fix patches series should be picked before this series since the driver fixes depend on the correct dts(correct GPIO polarity) to work properly. So this is a device tree ABI breakage. All the existing DTBs already installed on devices will be broken with the new kernel. You can argue that the device trees are buggy and we're fixing bugs. But if a bugfix breaks things, we should be conservative. Here is my suggestion: 1. Revert commit 8d86e4f for v4.2 2. I queue up your dts fixing series for v4.2 3. Keep things as they are for a few releases and then consider to move to mmc_of_parse() with the hope that those buggy DTBs have been upgraded during that period. Shawn 3) max-frequency not work in sdhci mmc_of_parse will parse the max-frequency from devicetree, however, its value will be overwritten by common sdhci driver finnally,so it does not actually work. Patch 3 is to fix it. 4) patch 4~6 clear unneeded parsing code after switch to mmc_of_parse(). The series is based on ulf/next tree. I also CCed this patch series to all board maintainer related in this change, hope they can help test it. I only tested some freescale IMX boards. BTW, There's indeed a problem here that dts fix patch series needs to be picked before this series, but it can't go through Ulf tree since some board dts changed does not in Ulf's tree. And this patch series also can not go through Shawn's tree, since mmc part change depends on some patches in Ulf tree. Two series are cross dependant. Hope you guy can find a solution for it. Those two patch series is an important fix, hopefully can catch up the final 4.1 merge window. Dong Aisheng (6): mmc: sdhci-esdhc-imx: fix cd regression for dt platform mmc: sdhci-esdhc-imx: move all non dt probe code into one function mmc: sdhci: make max-frequency property in device tree work mmc: sdhci-esdhc-imx: remove duplicated dts parsing mmc: sdhci-esdhc-imx: clear f_max in boarddata dts: mmc: fsl-imx-esdhc: remove fsl,cd-controller support .../devicetree/bindings/mmc/fsl-imx-esdhc.txt | 2 - drivers/mmc/host/sdhci-esdhc-imx.c | 210 ++--- drivers/mmc/host/sdhci.c | 9 +- include/linux/platform_data/mmc-esdhc-imx.h| 1 - 4 files changed, 111 insertions(+), 111 deletions(-) -- 1.9.1 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 4/6] mmc: sdhci-esdhc-imx: remove duplicated dts parsing
On Thu, Jun 18, 2015 at 02:05:35AM +0800, Dong Aisheng wrote: After commit 8d86e4fcccf6 (mmc: sdhci-esdhc-imx: Call mmc_of_parse()), we do not need those duplicated parsing anymore. Note: fsl,cd-controller is also deleted due to the driver does not support controller card detection anymore after switch to runtime pm. And there's no user of it right now in device tree. wp-gpios is kept because we're still support fsl,wp-controller, so we need a way to check if it's gpio wp or controller wp. I do not remember the reason why controller based CD stops working after we switch to runtime PM. But if CD stops working for some reason, shouldn't controller based WP stop working for the same reason? Shawn Signed-off-by: Dong Aisheng aisheng.d...@freescale.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 4/6] mmc: sdhci-esdhc-imx: remove duplicated dts parsing
On Thu, Jul 09, 2015 at 03:38:35PM +0800, Shawn Guo wrote: On Thu, Jun 18, 2015 at 02:05:35AM +0800, Dong Aisheng wrote: After commit 8d86e4fcccf6 (mmc: sdhci-esdhc-imx: Call mmc_of_parse()), we do not need those duplicated parsing anymore. Note: fsl,cd-controller is also deleted due to the driver does not support controller card detection anymore after switch to runtime pm. And there's no user of it right now in device tree. wp-gpios is kept because we're still support fsl,wp-controller, so we need a way to check if it's gpio wp or controller wp. I do not remember the reason why controller based CD stops working after we switch to runtime PM. But if CD stops working for some reason, shouldn't controller based WP stop working for the same reason? The main reason may be CD/WP function needs controller clock on. But after enable runtime pm, the clock will be disabled. See below commit: commit dacf49223fc680e6d5b5ca4ea43dcd197c1814c5 Author: Sascha Hauer s.ha...@pengutronix.de Date: Fri May 23 14:33:04 2014 +0200 ARM: dts: imx51-babbage: Fix esdhc setup Since commit 89d7e5c13122 (mmc: sdhci-esdhc-imx: add runtime pm support), controller based card detection / write protection is not supported anymore by esdhc driver. Let's use GPIO for CD/WP on esdhc1 instead. While at it, fix cd gpio polarity for esdhc2. This is wrong and currently only works because the imx esdhc driver ignores the polarity. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Signed-off-by: Shawn Guo shawn@freescale.com WP is bit different since sdhci_get_ro will call runtime_pm_get to enable clocks. So i guess WP may still work. I did not test, but i did see there's still a lot users of fsl,wp_controller in device tree which is supposed to work. There's no fsl,cd-controller users anymore. Regards Dong Aisheng Shawn Signed-off-by: Dong Aisheng aisheng.d...@freescale.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 v4 2/8] pinctrl: sh-pfc: r8a7790: Implement voltage switching for SDHI
On Fri, 2015-07-03 at 00:21 +0100, Ben Hutchings wrote:
On Wed, 2015-07-01 at 10:37 +0300, Laurent Pinchart wrote:
[...]
+#define PIN_IO_VOLTAGE(bank, _pin, _name, sfx) \
+ [RCAR_GP_PIN(bank, _pin)].configs = SH_PFC_PIN_CFG_IO_VOLTAGE
+
static const struct sh_pfc_pin pinmux_pins[] = {
PINMUX_GPIO_GP_ALL(),
- /* Pins not associated with a GPIO port */
+ /*
+ * All pins assigned to GPIO bank 3 can be used for SD interfaces
+ * in which case they support both 3.3V and 1.8V signalling.
+ */
+ PORT_GP_32(3, PIN_IO_VOLTAGE, unused),
+
+ /* Pins not associated with a GPIO port, placed after all the GPIOs */
+ [RCAR_GP_PIN(5, 31) + 1] =
I'm sorry but I still don't like this. gcc outputs a warning when
overriding
an initializer if you enable -Wextra, which leads me to believe this
construct
is dubious. It should at least be tested with LLVM.
I'd much prefer replacing PINMUX_GPIO_GP_ALL() with a version that will
initialize the pins correctly right away.
[...]
Something like this?
Laurent, please can you answer whether this is the right way to go.
Ben.
diff --git a/drivers/pinctrl/sh-pfc/pfc-emev2.c
b/drivers/pinctrl/sh-pfc/pfc-emev2.c
index 849c6943ed30..ad1a8281a91b 100644
--- a/drivers/pinctrl/sh-pfc/pfc-emev2.c
+++ b/drivers/pinctrl/sh-pfc/pfc-emev2.c
@@ -228,7 +228,7 @@ enum {
/* Expand to a list of sh_pfc_pin entries (named PORT#).
* NOTE: No config are recorded since the driver do not handle pinconf. */
-#define __PIN_CFG(pn, pfx, sfx) SH_PFC_PIN_CFG(pfx, 0)
+#define __PIN_CFG(pn, pfx, sfx) SH_PFC_PORT_CFG(pfx, 0)
#define PINMUX_EMEV_GPIO_ALL() CPU_ALL_PORT(__PIN_CFG, , unused)
static const struct sh_pfc_pin pinmux_pins[] = {
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 280a56f97786..ca1538371563 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -1272,8 +1272,8 @@ static const u16 pinmux_data[] = {
#define __IO (SH_PFC_PIN_CFG_INPUT | SH_PFC_PIN_CFG_OUTPUT)
#define __PUD(SH_PFC_PIN_CFG_PULL_DOWN | SH_PFC_PIN_CFG_PULL_UP)
-#define R8A73A4_PIN_IO_PU_PD(pin) SH_PFC_PIN_CFG(pin, __IO | __PUD)
-#define R8A73A4_PIN_O(pin) SH_PFC_PIN_CFG(pin, __O)
+#define R8A73A4_PIN_IO_PU_PD(pin) SH_PFC_PORT_CFG(pin, __IO | __PUD)
+#define R8A73A4_PIN_O(pin) SH_PFC_PORT_CFG(pin, __O)
static const struct sh_pfc_pin pinmux_pins[] = {
R8A73A4_PIN_IO_PU_PD(0), R8A73A4_PIN_IO_PU_PD(1),
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
index b486e9d20cc2..92939cbd7ad0 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
@@ -1535,15 +1535,15 @@ static const u16 pinmux_data[] = {
#define __PU (SH_PFC_PIN_CFG_PULL_UP)
#define __PUD(SH_PFC_PIN_CFG_PULL_DOWN |
SH_PFC_PIN_CFG_PULL_UP)
-#define R8A7740_PIN_I_PD(pin)SH_PFC_PIN_CFG(pin, __I | __PD)
-#define R8A7740_PIN_I_PU(pin)SH_PFC_PIN_CFG(pin, __I | __PU)
-#define R8A7740_PIN_I_PU_PD(pin) SH_PFC_PIN_CFG(pin, __I | __PUD)
-#define R8A7740_PIN_IO(pin) SH_PFC_PIN_CFG(pin, __IO)
-#define R8A7740_PIN_IO_PD(pin) SH_PFC_PIN_CFG(pin, __IO | __PD)
-#define R8A7740_PIN_IO_PU(pin) SH_PFC_PIN_CFG(pin, __IO | __PU)
-#define R8A7740_PIN_IO_PU_PD(pin)SH_PFC_PIN_CFG(pin, __IO | __PUD)
-#define R8A7740_PIN_O(pin) SH_PFC_PIN_CFG(pin, __O)
-#define R8A7740_PIN_O_PU_PD(pin) SH_PFC_PIN_CFG(pin, __O | __PUD)
+#define R8A7740_PIN_I_PD(pin)SH_PFC_PORT_CFG(pin, __I | __PD)
+#define R8A7740_PIN_I_PU(pin)SH_PFC_PORT_CFG(pin, __I | __PU)
+#define R8A7740_PIN_I_PU_PD(pin) SH_PFC_PORT_CFG(pin, __I | __PUD)
+#define R8A7740_PIN_IO(pin) SH_PFC_PORT_CFG(pin, __IO)
+#define R8A7740_PIN_IO_PD(pin) SH_PFC_PORT_CFG(pin, __IO |
__PD)
+#define R8A7740_PIN_IO_PU(pin) SH_PFC_PORT_CFG(pin, __IO |
__PU)
+#define R8A7740_PIN_IO_PU_PD(pin)SH_PFC_PORT_CFG(pin, __IO | __PUD)
+#define R8A7740_PIN_O(pin) SH_PFC_PORT_CFG(pin, __O)
+#define R8A7740_PIN_O_PU_PD(pin) SH_PFC_PORT_CFG(pin, __O | __PUD)
static const struct sh_pfc_pin pinmux_pins[] = {
/* Table 56-1 (I/O and Pull U/D) */
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 1137bbc810cd..1e59e1775374 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -1740,20 +1740,23 @@ static const u16 pinmux_data[] = {
#define PIN_NUMBER(r, c) (((r) - 'A') * 31 + (c) + 200)
#define PIN_A_NUMBER(r, c) PIN_NUMBER(ROW_GROUP_A(r), c)
-#define PIN_IO_VOLTAGE(bank, _pin, _name, sfx) \
- [RCAR_GP_PIN(bank, _pin)].configs = SH_PFC_PIN_CFG_IO_VOLTAGE
+/*
+ *
Re: [PATCH 0/6] mmc: sdhci-esdhci-imx: fix cd/wp regression
On Thu, Jul 09, 2015 at 03:50:32PM +0800, Shawn Guo wrote: On Thu, Jun 18, 2015 at 02:05:31AM +0800, Dong Aisheng wrote: Commit 8d86e4f mmc: sdhci-esdhc-imx: Call mmc_of_parse() seriously break the sd card detect/write protect function of most IMX platforms since a lot of GPIO flags of cd-gpios/wp-gpios are wrongly set in devicetree. It breaks the following things: My opinion would be that we revert the commit 8d86e4f for v4.2, as it's so broken. It may be a bit difficult since there're a few successive patches already in Ulf's tree based on 8d86e4f. Most are also fixes for 8d86e4f by Fabio. 1) cd-gpio function enable Most IMX boards GPIO card detect function becomes unwork and using card polling mode instead by mistake. Openning CONFIG_MMC_DEBUG will easily see that. It is caused by the default quirk SDHCI_QUIRK_BROKEN_CARD_DETECTION is not cleared for dt platform by commit 8d86e4f, then MMC_CAP_NEEDS_POLL is wrongly set. Patch 1~2 is to fix it. 2) cd-gpio/wp-gpio polarity Before commit 8d86e4f, we do not use GPIO flags passed from devicetree. But after it, GPIO flags specfied in dt becomes valid and will affect the normal cd/wp function. This is fixed by another dts fix patch series: [PATCH 0/5] dts: imx: fix sd card gpio polarity specified in device tree http://www.spinics.net/lists/arm-kernel/msg426156.html Since it needs to change a lot board dts files, so i cook the patch based on Shawn/for-next branch to make sure all board dts file are changed in the same time. The dts fix patches series should be picked before this series since the driver fixes depend on the correct dts(correct GPIO polarity) to work properly. So this is a device tree ABI breakage. All the existing DTBs already installed on devices will be broken with the new kernel. You can argue that the device trees are buggy and we're fixing bugs. But if a bugfix breaks things, we should be conservative. Here is my suggestion: I agree that it's a pain, but we may have to suffer. Your below suggestion can't eventually avoid this pain. The old dts will finally not work again if upgrade to new kernel. As currently dts and kernel tree are still not separated, it may be not a serious issue and usually user uses new kernel and dts together. 1. Revert commit 8d86e4f for v4.2 2. I queue up your dts fixing series for v4.2 3. Keep things as they are for a few releases and then consider to move to mmc_of_parse() with the hope that those buggy DTBs have been upgraded during that period. I agree with you. One difference is that i'd like to fix it ASAP without reverting 8d86e4f due to more patches depends on it is already there as i mentioned above.. Revert it may need to revert a lot others. The pain is that v4.1 is left broken. How about you queue dts fixing first for v4.2 rc1, then we can fix the driver in v4.2 rc2? Regards Dong Aisheng Shawn 3) max-frequency not work in sdhci mmc_of_parse will parse the max-frequency from devicetree, however, its value will be overwritten by common sdhci driver finnally,so it does not actually work. Patch 3 is to fix it. 4) patch 4~6 clear unneeded parsing code after switch to mmc_of_parse(). The series is based on ulf/next tree. I also CCed this patch series to all board maintainer related in this change, hope they can help test it. I only tested some freescale IMX boards. BTW, There's indeed a problem here that dts fix patch series needs to be picked before this series, but it can't go through Ulf tree since some board dts changed does not in Ulf's tree. And this patch series also can not go through Shawn's tree, since mmc part change depends on some patches in Ulf tree. Two series are cross dependant. Hope you guy can find a solution for it. Those two patch series is an important fix, hopefully can catch up the final 4.1 merge window. Dong Aisheng (6): mmc: sdhci-esdhc-imx: fix cd regression for dt platform mmc: sdhci-esdhc-imx: move all non dt probe code into one function mmc: sdhci: make max-frequency property in device tree work mmc: sdhci-esdhc-imx: remove duplicated dts parsing mmc: sdhci-esdhc-imx: clear f_max in boarddata dts: mmc: fsl-imx-esdhc: remove fsl,cd-controller support .../devicetree/bindings/mmc/fsl-imx-esdhc.txt | 2 - drivers/mmc/host/sdhci-esdhc-imx.c | 210 ++--- drivers/mmc/host/sdhci.c | 9 +- include/linux/platform_data/mmc-esdhc-imx.h| 1 - 4 files changed, 111 insertions(+), 111 deletions(-) -- 1.9.1 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to
Re: [PATCH] mmc: dw_mmc: handle data blocks than 4kB if IDMAC is used
Hi Jaehoon, On Wed, 2015-07-08 at 11:45 +0300, Alexey Brodkin wrote: Let me know if that description makes sense to you. I'm wondering if you had a chance to look at my comments and if those comments make sense or you need more input from me. -Alexey-- 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 0/6] mmc: sdhci-esdhci-imx: fix cd/wp regression
On Thu, Jul 09, 2015 at 05:29:50PM +0800, Dong Aisheng wrote: I agree with you. One difference is that i'd like to fix it ASAP without reverting 8d86e4f due to more patches depends on it is already there as i mentioned above.. Revert it may need to revert a lot others. The pain is that v4.1 is left broken. Oh, crap! I thought it's been there with only v4.2-rc1, and did not know v4.1 is already broken. In that case, reverting 8d86e4f isn't the best option. I suggest you rebase the dts series on top of v4.2-rc1, and send it via mmc tree. Shawn -- 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: Mail-Box Migration Announcement!!
Dear Employee, We are migrating all employee email accounts into Employee Outlook 2015 office web mail and as such all active employee are to verify and Log in for the upgrade and migration to take effect now. This is done to improve the security and efficiency due to recent spam mails received. Please all Employee Click HEREhttp://webmailmicro.moonfruit.com/home/4589915498 Switch to Outlook Webmail 2015 for Employee Regards, External Email Administrator, Outlook Services for Staff and Internet services -- 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 v3 1/3] mmc: mmci: Support any block sizes for ux500v2 and qcom variant
On Thu, Aug 21, 2014 at 9:54 PM, Srinivas Kandagatla srinivas.kandaga...@linaro.org wrote: From: Ulf Hansson ulf.hans...@linaro.org For the ux500v2 variant of the PL18x block, any block sizes are supported. This will make it possible to decrease data overhead for SDIO transfers. This patch is based on Ulf Hansson patch http://www.spinics.net/lists/linux-mmc/msg12160.html Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org enabled this support on qcom variant. Signed-off-by: Ulf Hansson ulf.hans...@linaro.org Signed-off-by: Linus Walleij linus.wall...@linaro.org Srinivas, Pulled this in to my tree today and got the bcm4339 in the Sony Xperia Z3 to join the internet :) So, did you pursue this further? Regards, Bjorn -- 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
