[PATCH 3/3 v2] dts: Add ESDHC weird voltage bits workaround
P4080 ESDHC controller does not support 1.8V and 3.0V voltage. but the host controller capabilities register wrongly set the bits. This patch adds the workaround to correct the weird voltage setting bits. Only 3.3V voltage is supported for P4080 ESDHC controller. Signed-off-by: Roy Zang --- arch/powerpc/boot/dts/p4080ds.dts |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/dts/p4080ds.dts b/arch/powerpc/boot/dts/p4080ds.dts index efa0091..2f0de24 100644 --- a/arch/powerpc/boot/dts/p4080ds.dts +++ b/arch/powerpc/boot/dts/p4080ds.dts @@ -280,6 +280,7 @@ reg = <0x114000 0x1000>; interrupts = <48 2>; interrupt-parent = <&mpic>; + voltage-ranges = <3300 3300>; sdhci,auto-cmd12; }; -- 1.5.6.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 v2] dts: Add sdhci,auto-cmd12 field for p4080 device tree
Signed-off-by: Roy Zang
---
Documentation/powerpc/dts-bindings/fsl/esdhc.txt |2 ++
arch/powerpc/boot/dts/p4080ds.dts|1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
index 8a00407..64bcb8b 100644
--- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
@@ -14,6 +14,8 @@ Required properties:
reports inverted write-protect state;
- sdhci,1-bit-only : (optional) specifies that a controller can
only handle 1-bit data transfers.
+ - sdhci,auto-cmd12: (optional) specifies that a controller can
+only handle auto CMD12.
Example:
diff --git a/arch/powerpc/boot/dts/p4080ds.dts
b/arch/powerpc/boot/dts/p4080ds.dts
index 6b29eab..efa0091 100644
--- a/arch/powerpc/boot/dts/p4080ds.dts
+++ b/arch/powerpc/boot/dts/p4080ds.dts
@@ -280,6 +280,7 @@
reg = <0x114000 0x1000>;
interrupts = <48 2>;
interrupt-parent = <&mpic>;
+ sdhci,auto-cmd12;
};
i...@118000 {
--
1.5.6.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 v2] sdhci: Add auto CMD12 support for eSDHC driver
From: Jerry Huang
Add auto CMD12 command support for eSDHC driver.
This is needed by P4080 and P1022 for block read/write.
Manual asynchronous CMD12 abort operation causes protocol violations on
these silicons.
Signed-off-by: Jerry Huang
Signed-off-by: Roy Zang
---
drivers/mmc/host/sdhci-of-core.c |4
drivers/mmc/host/sdhci.c | 14 --
drivers/mmc/host/sdhci.h |2 ++
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index a2e9820..dd1bdd1 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -154,6 +154,10 @@ static int __devinit sdhci_of_probe(struct of_device
*ofdev,
host->ops = &sdhci_of_data->ops;
}
+ if (of_get_property(np, "sdhci,auto-cmd12", NULL))
+ host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
+
+
if (of_get_property(np, "sdhci,1-bit-only", NULL))
host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c6d1bd8..a92566e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -817,8 +817,12 @@ static void sdhci_set_transfer_mode(struct sdhci_host
*host,
WARN_ON(!host->data);
mode = SDHCI_TRNS_BLK_CNT_EN;
- if (data->blocks > 1)
- mode |= SDHCI_TRNS_MULTI;
+ if (data->blocks > 1) {
+ if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
+ mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_ACMD12;
+ else
+ mode |= SDHCI_TRNS_MULTI;
+ }
if (data->flags & MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
if (host->flags & SDHCI_REQ_USE_DMA)
@@ -1108,6 +1112,12 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
#ifndef SDHCI_USE_LEDS_CLASS
sdhci_activate_led(host);
#endif
+ if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12) {
+ if (mrq->stop) {
+ mrq->data->stop = NULL;
+ mrq->stop = NULL;
+ }
+ }
host->mrq = mrq;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index c846813..8fb088c 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -240,6 +240,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN (1<<25)
/* Controller cannot support End Attribute in NOP ADMA descriptor */
#define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC (1<<26)
+/* Controller uses Auto CMD12 command to stop the transfer */
+#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (1<<27)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.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
+ mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-update-2.patch added to -mm tree
The patch titled
mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-update-2
has been added to the -mm tree. Its filename is
mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-update-2.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
--
Subject:
mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-update-2
From: Maxim Levitsky
If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
suspend, the card will be removed, therefore this patch doesn't change the
behavior of this option.
However the removal will be done by pm notifier, which runs while
userspace is still not frozen and thus can freely use del_gendisk, without
the risk of deadlock which would happen otherwise.
Card detect workqueue is now disabled while userspace is frozen, Therefore
if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
suspend, the removal will be detected as soon as userspace is unfrozen,
again at the moment it is safe to call del_gendisk.
Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
Signed-off-by: Maxim Levitsky
Cc: David Brownell
Cc: Alan Stern
Cc:
Signed-off-by: Andrew Morton
---
drivers/mmc/core/core.c |4 ++--
drivers/mmc/core/host.c |1 -
include/linux/mmc/host.h |1 -
3 files changed, 2 insertions(+), 4 deletions(-)
diff -puN
drivers/mmc/core/core.c~mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-update-2
drivers/mmc/core/core.c
---
a/drivers/mmc/core/core.c~mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-update-2
+++ a/drivers/mmc/core/core.c
@@ -1323,6 +1323,7 @@ int mmc_resume_host(struct mmc_host *hos
return err;
}
+EXPORT_SYMBOL(mmc_resume_host);
/* Do the card removal on suspend if card is assumed removeable
* Do that in pm notifier while userspace isn't yet frozen, so we will be able
@@ -1343,6 +1344,7 @@ int mmc_pm_notify(struct notifier_block
spin_lock_irqsave(&host->lock, flags);
host->rescan_disable = 1;
spin_unlock_irqrestore(&host->lock, flags);
+ cancel_delayed_work_sync(&host->detect);
if (!host->bus_ops || host->bus_ops->suspend)
break;
@@ -1369,8 +1371,6 @@ int mmc_pm_notify(struct notifier_block
return 0;
}
-EXPORT_SYMBOL(mmc_resume_host);
-
#endif
static int __init mmc_init(void)
diff -puN
drivers/mmc/core/host.c~mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-update-2
drivers/mmc/core/host.c
---
a/drivers/mmc/core/host.c~mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-update-2
+++ a/drivers/mmc/core/host.c
@@ -88,7 +88,6 @@ struct mmc_host *mmc_alloc_host(int extr
INIT_DELAYED_WORK_DEFERRABLE(&host->disable, mmc_host_deeper_disable);
host->pm_notify.notifier_call = mmc_pm_notify;
-
/*
* By default, hosts do not support SGIO or large requests.
* They have to set these according to their abilities.
diff -puN
include/linux/mmc/host.h~mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-update-2
include/linux/mmc/host.h
---
a/include/linux/mmc/host.h~mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-update-2
+++ a/include/linux/mmc/host.h
@@ -261,7 +261,6 @@ int mmc_host_disable(struct mmc_host *ho
int mmc_host_lazy_disable(struct mmc_host *host);
int mmc_pm_notify(struct notifier_block *notify_block, unsigned long, void *);
-
static inline void mmc_set_disable_delay(struct mmc_host *host,
unsigned int disable_delay)
{
_
Patches currently in -mm which might be from maximlevit...@gmail.com are
linux-next.patch
maintainers-update-ricoh-smartmedia-xd-driver-file-patterns.patch
mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume.patch
mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-update-2.patch
mmc-make-sdhci-work-with-ricoh-mmc-controller.patch
--
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 03/20] mmc: support embedded data field in mmc_host
Hi Vitaly, On Mon, Aug 2, 2010 at 7:25 PM, Vitaly Wool wrote: > On Mon, Aug 2, 2010 at 5:54 PM, Ohad Ben-Cohen wrote: >> SPI is using these spi_board_info tables to populate the SPI device >> trees. These tables are registered early at the board-specific init >> code, and are later used by SPI core to populate the devices when the >> SPI master controller is registered. >> >> SDIO doesn't normally needs any kind of hard coded data: most devices >> are dynamically probed and populated. >> >> On rare cases like the wl1271, we have some platform-specific data we >> need to deliver the SDIO function driver (i.e. the irq info in this >> case). Since the device is hardwired to a specific controller, it does >> make some sense to pass this private data from the controller's info >> in the board files, through the host driver, and make it accessible >> through the specific host instance that drives this controller. >> >> Btw, if our problem was be broader (e.g., needs to supply private data >> for non-hardwired devices), then I agree that a more complex >> mechanism, such as the one you suggest, would be needed. But currently >> the problem is very simple and the solution is even simpler: just add >> 1 private pointer to the host. >> >> Hope you find this reasonable, > > no, actually I don't. I think this is a hack that intrudes into the > area it completely doesn't belong to. > > In fact, one can have 2 views on this problem: either this is a fairly > generic problem we need to address, or this is a very specific corner > case. > Your solution will be treated as a hack in both cases. > > If we consider it a generic problem, then we need to find a generic > solution, which is the board_info solution, for instance. FWIW, I2C > also uses this approach now. > > If we consider it to be a corner case, let's just add a dummy > platform_device like it's done in WL1251 implementation and keep the > MMC subsystem clean. Let's start by defining the problem exactly: SDIO devices that are hardwired to a specific controller and have some platform data that needs to be available to the SDIO function driver. It doesn't get more generic than that - it's not needed with common fully-enumerable SDIO devices (at least I'm not aware of such need), hence a generic mechanism of maintaining a global pile of platform data pointers, which can be queried with the device and vendor ID, really sounds like an overkill. But it's not specific to the wl1271 device - I prefer to support this at the MMC level, so we wouldn't have to add an extra platform device for every SDIO function driver that needs to cope with such issue (we already have two drivers - wl1271_sdio.c and wl1251_sdio.c); Adding an extra platform device for every driver is just too much dummy code (that btw adds a well-hidden race condition between the two probe calls), which can be nicely eliminated if we just introduce this new per-host private data pointer. So we have a SDIO device hardwired to a specific controller, that is driven by a specific host controller driver instance. This patch allows this specific host instance to carry platform data for the device that is hardwired to it. The platform data would be available only to SDIO function driver instances of that specific host controller. The solution is generic enough to support all SDIO function drivers with similar needs, and it's extremely simple. I'm honestly trying to understand your concerns, but I'm afraid that just saying "it's a hack" is not too informative. Can you please explain what do you think is technically wrong with the proposed solution ? is it not general enough for other use cases ? will it break something ? Thanks, Ohad. > > Thanks, > Vitaly > -- 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 00/20] native support for wl1271 on ZOOM
Hi Vitaly, On Mon, Aug 2, 2010 at 7:19 PM, Vitaly Wool wrote: > On Mon, Aug 2, 2010 at 5:59 PM, Ohad Ben-Cohen wrote: >> >> Check out patch no. 9: > > sorry for the confusion. However, I guess if the platform doesn't > supply this value, we'll just consider it 0? Without any warning, > right? > > The problem is, we can't really distinguish between this field not set > and value zero, and that means something is wrong with the design. The > easiest way is probably changing the clock ids to start with 1. I don't think it's a huge deal as adding new devices on board files is anyway something that is done carefully and not so often. Btw, we have this kind of mechanism in other locations of the kernel as well and it doesn't seem to be problematic (e.g. spi->chip_select, spi->mode, spi->irq, ...). Having said that I don't mind applying your proposal either and pushing those defines by 1 in the driver. Luca what do you think ? Thanks, Ohad. > > Thanks, > Vitaly > -- 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 03/20] mmc: support embedded data field in mmc_host
Hi Ohad, On Mon, Aug 2, 2010 at 5:54 PM, Ohad Ben-Cohen wrote: > SPI is using these spi_board_info tables to populate the SPI device > trees. These tables are registered early at the board-specific init > code, and are later used by SPI core to populate the devices when the > SPI master controller is registered. > > SDIO doesn't normally needs any kind of hard coded data: most devices > are dynamically probed and populated. > > On rare cases like the wl1271, we have some platform-specific data we > need to deliver the SDIO function driver (i.e. the irq info in this > case). Since the device is hardwired to a specific controller, it does > make some sense to pass this private data from the controller's info > in the board files, through the host driver, and make it accessible > through the specific host instance that drives this controller. > > Btw, if our problem was be broader (e.g., needs to supply private data > for non-hardwired devices), then I agree that a more complex > mechanism, such as the one you suggest, would be needed. But currently > the problem is very simple and the solution is even simpler: just add > 1 private pointer to the host. > > Hope you find this reasonable, no, actually I don't. I think this is a hack that intrudes into the area it completely doesn't belong to. In fact, one can have 2 views on this problem: either this is a fairly generic problem we need to address, or this is a very specific corner case. Your solution will be treated as a hack in both cases. If we consider it a generic problem, then we need to find a generic solution, which is the board_info solution, for instance. FWIW, I2C also uses this approach now. If we consider it to be a corner case, let's just add a dummy platform_device like it's done in WL1251 implementation and keep the MMC subsystem clean. Thanks, Vitaly -- 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 00/20] native support for wl1271 on ZOOM
Hi Ohad, On Mon, Aug 2, 2010 at 5:59 PM, Ohad Ben-Cohen wrote: > > Check out patch no. 9: sorry for the confusion. However, I guess if the platform doesn't supply this value, we'll just consider it 0? Without any warning, right? The problem is, we can't really distinguish between this field not set and value zero, and that means something is wrong with the design. The easiest way is probably changing the clock ids to start with 1. Thanks, Vitaly -- 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 03/20] mmc: support embedded data field in mmc_host
Hi Vitaly, On Thu, Jul 29, 2010 at 7:16 PM, Vitaly Wool wrote: > On Thu, Jul 29, 2010 at 8:00 AM, Ohad Ben-Cohen wrote: >>> To my understanding, this data doesn't belong to mmc_host. It's not a >>> host data at all. E. g. imagine a GPIO IRQ for some SDIO chip -- it's >>> totally unrelated to host. >>> >>> I think a cleaner way would be to introduce something similar to what >>> we have for SPI, e. g. struct sdio_board_info. This board info will >>> contain platform-specific stuff and vendor id/chip id for each onboard >>> SDIO device. Then the SDIO core will pick up the appropriate data >>> basing on vendor id/chip id. >> >> Can you please elaborate some more about your proposal (specifically >> where does this sdio_board_info get set and how do function drivers >> access it) ? >> >> If I understand you correctly, you suggest to have a global, >> board-specific table of sdio_board_info structures, which would be >> accessible to the SDIO core (through the host driver ?). When a new >> SDIO device is found the core would search this table for the >> appropriate sdio_board_info struct and make it accessible to the SDIO >> function driver ? > > Well, let's look at how it's implemented for SPI. There is the > function spi_register_board_info in the SPI core which copies the > board info into the local data structure (a linked list, actually). > Whenever needed, the core walks through the list to find the > appropriate board_info basing on some search key. > > I think this may be the way to go for SDIO as well. IMHO this is a bit overkill solution for our problem. SPI is using these spi_board_info tables to populate the SPI device trees. These tables are registered early at the board-specific init code, and are later used by SPI core to populate the devices when the SPI master controller is registered. SDIO doesn't normally needs any kind of hard coded data: most devices are dynamically probed and populated. On rare cases like the wl1271, we have some platform-specific data we need to deliver the SDIO function driver (i.e. the irq info in this case). Since the device is hardwired to a specific controller, it does make some sense to pass this private data from the controller's info in the board files, through the host driver, and make it accessible through the specific host instance that drives this controller. Btw, if our problem was be broader (e.g., needs to supply private data for non-hardwired devices), then I agree that a more complex mechanism, such as the one you suggest, would be needed. But currently the problem is very simple and the solution is even simpler: just add 1 private pointer to the host. Hope you find this reasonable, Thanks, Ohad. > > ~Vitaly > -- 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 00/20] native support for wl1271 on ZOOM
On Mon, Aug 2, 2010 at 6:12 PM, Vitaly Wool wrote: > Also, specifically to 12xx, I'd like to see REF_CLOCK moved on and > have this set by platform too (I haven't found anything like that in > the patches but maybe I've overlooked that). Check out patch no. 9: http://www.spinics.net/lists/arm-kernel/msg93836.html > > Thanks, > Vitaly > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 v6] OMAP4 HSMMC: Adding Card detect support for MMC1 on OMAP4
> -Original Message-
> From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com]
> Sent: Monday, August 02, 2010 9:33 AM
> To: Andrew Morton
> Cc: linux-mmc@vger.kernel.org; linux-o...@vger.kernel.org;
> t...@atomide.com; madhu...@ti.com; adrian.hun...@nokia.com
> Subject: Re: [PATCH v6] OMAP4 HSMMC: Adding Card detect support for MMC1
> on OMAP4
>
> Andrew,
>
> Can this patch be taken now as there are no comments.
>
> Regards,
> Kishore
>
Kishore,
As Andrew mentioned some time back this series has to go through Linux-omap.
Tony had a comment on the below first patch in the series.
[PATCH v5 1/2] OMAP HSMMC: Adding a Flag to determine the type of Card
detect
How is the NON-GPIO card detect handled now? Is the above patch not needed
anymore?
Regards,
Madhu
> On Wed, Jul 7, 2010 at 7:42 PM, kishore kadiyala
> wrote:
> > Adding card detect callback function and card detect configuration
> > function for MMC1 Controller.
> >
> > Card detect configuration function does initial configuration of the
> > MMC Control & PullUp-PullDown registers of Phoenix.
> >
> > For MMC1 Controller, Card detect interrupt source is
> > twl6030 and the card detect call back function provides card
> present/absent
> > status by reading MMC Control register.
> >
> > Signed-off-by: Kishore Kadiyala
> > Cc: Tony Lindgren
> > Cc: Madhusudhan Chikkature
> > Cc: Adrian Hunter
> > ---
> > V5:
> > https://patchwork.kernel.org/patch/106697/
> > https://patchwork.kernel.org/patch/106698/
> > V4:
> > http://www.mail-archive.com/linux-
> m...@vger.kernel.org/msg01958.html
> > http://www.mail-archive.com/linux-
> m...@vger.kernel.org/msg01949.html
> >
> >
> > arch/arm/mach-omap2/board-4430sdp.c | 7 +++-
> > drivers/mfd/twl6030-irq.c | 76
> +++
> > drivers/mmc/host/omap_hsmmc.c | 4 +-
> > include/linux/i2c/twl.h | 16 +++
> > 4 files changed, 100 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
> omap2/board-4430sdp.c
> > index f287461..388b96d 100644
> > --- a/arch/arm/mach-omap2/board-4430sdp.c
> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
> > @@ -227,9 +227,14 @@ static int omap4_twl6030_hsmmc_late_init(struct
> device *dev)
> > struct omap_mmc_platform_data *pdata = dev->platform_data;
> >
> > /* Setting MMC1 Card detect Irq */
> > - if (pdev->id == 0)
> > + if (pdev->id == 0) {
> > + ret = twl6030_mmc_card_detect_config();
> > + if (ret)
> > + pr_err("Failed configuring MMC1 card detect\n");
> > pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE +
> > MMCDETECT_INTR_OFFSET;
> > + pdata->slots[0].card_detect = twl6030_mmc_card_detect;
> > + }
> > return ret;
> > }
> >
> > diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
> > index 10bf228..c027692 100644
> > --- a/drivers/mfd/twl6030-irq.c
> > +++ b/drivers/mfd/twl6030-irq.c
> > @@ -36,6 +36,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /*
> > * TWL6030 (unlike its predecessors, which had two level interrupt
> handling)
> > @@ -223,6 +224,81 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
> > }
> > EXPORT_SYMBOL(twl6030_interrupt_mask);
> >
> > +int twl6030_mmc_card_detect_config(void)
> > +{
> > + int ret;
> > + u8 reg_val = 0;
> > +
> > + /* Unmasking the Card detect Interrupt line for MMC1 from
> Phoenix */
> > + if (twl_class_is_6030()) {
> > + twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
> > +
> REG_INT_MSK_LINE_B);
> > + twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
> > +
> REG_INT_MSK_STS_B);
> > + }
> > +
> > + /*
> > + * Intially Configuring MMC_CTRL for receving interrupts &
> > + * Card status on TWL6030 for MMC1
> > + */
> > + ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, ®_val,
> TWL6030_MMCCTRL);
> > + if (ret < 0) {
> > + pr_err("twl6030: Failed to read MMCCTRL, error %d\n",
> ret);
> > + return ret;
> > + }
> > + reg_val &= ~VMMC_AUTO_OFF;
> > + reg_val |= SW_FC;
> > + ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
> TWL6030_MMCCTRL);
> > + if (ret < 0) {
> > + return ret;
> > + pr_err("twl6030: Failed to write MMCCTRL, error %d\n",
> ret);
> > + }
> > +
> > + /* Configuring PullUp-PullDown register */
> > + ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, ®_val,
> > +
> TWL6030_CFG_INPUT_PUPD3);
> > + if (ret < 0) {
> > + return ret;
> > + pr_err("twl6030: Failed to read CFG_INPUT_PUPD3, error
> %d\n",
> > +
> ret);
> > + }
> > + reg_val &= ~(MMC_PU | MMC_PD);
> > + ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
>
Re: [PATCH v2 00/20] native support for wl1271 on ZOOM
On Mon, Aug 2, 2010 at 1:42 PM, Tony Lindgren wrote: > Nicolas Pitre made a comment saying he wants to look at these patches > more, are there other pending comments? Yep, I'm feeling quite uncomfortable with the way platform data is being passed over to sdio device now. Also, specifically to 12xx, I'd like to see REF_CLOCK moved on and have this set by platform too (I haven't found anything like that in the patches but maybe I've overlooked that). Thanks, Vitaly -- 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: add SDHCI driver for STM platforms.
Hi Matt, > -Original Message- > From: Matt Fleming [mailto:m...@console-pimps.org] > Sent: Monday, August 02, 2010 4:37 PM > To: Peppe CAVALLARO > Cc: Andrew Morton; linux-mmc@vger.kernel.org > Subject: Re: [PATCH] mmc: add SDHCI driver for STM platforms. > > On Mon, Aug 02, 2010 at 04:03:30PM +0200, Peppe CAVALLARO wrote: > > Hi Matt, > > > > > -Original Message- > > > From: Matt Fleming [mailto:m...@console-pimps.org] > > > Sent: Monday, August 02, 2010 3:41 PM > > > To: Peppe CAVALLARO > > > Cc: Andrew Morton > > > Subject: Re: [PATCH] mmc: add SDHCI driver for STM platforms. > > > > > > On Fri, Jul 30, 2010 at 04:04:16PM +0200, Peppe CAVALLARO wrote: > > > > Hello! > > > > I wonder if somebody's had some spare moment to review this patch. > > > > Welcome advice and feedback as usual > > > > > > > > Many thanks in advance. > > > > > > > > Best Regards, > > > > Giuseppe > > > > > > You're best bet is to CC Andrew on mmc patches (which I've now done). > > > > Thanks for your feedback and sorry if I didn't put Andrew on CC before. > > I'm newer in this mailing list. > > I'm sorry, I dropped the linux-mmc mailing list when I replied to your > mail! My bad. No problem! Thanks! > > > > What is devm_stm_pad_claim()? I can't find this function in linus' > > > tree, or in -next, or in Andrew's -mm series. Where is this function > > > from? > > > > This comes from our STMicroelectronics platform pad management > > infrastructure; code available from: > > http://git.stlinux.com/?p=stm/linux-sh4-2.6.32.y.git;a=summary It's > > used to claim/manage various resources i.e. PIO and clock lines. > > That's interesting. So, this driver won't build with linus' tree? I No, it won't. > didn't think that the kernel catered for external interfaces like this > - it causes all sorts of issues, not least of which is the fact that > the driver can't be built or tested with the mainline kernel. > I know that this can be a problem but, having it in the main-line, it could also help me on developing and testing the Arasan HC on newer Kernels for our STM platforms. > Andrew, what do you make of this? Regards, Peppe -- 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: add SDHCI driver for STM platforms.
On Mon, Aug 02, 2010 at 04:03:30PM +0200, Peppe CAVALLARO wrote: > Hi Matt, > > > -Original Message- > > From: Matt Fleming [mailto:m...@console-pimps.org] > > Sent: Monday, August 02, 2010 3:41 PM > > To: Peppe CAVALLARO > > Cc: Andrew Morton > > Subject: Re: [PATCH] mmc: add SDHCI driver for STM platforms. > > > > On Fri, Jul 30, 2010 at 04:04:16PM +0200, Peppe CAVALLARO wrote: > > > Hello! > > > I wonder if somebody's had some spare moment to review this patch. > > > Welcome advice and feedback as usual > > > > > > Many thanks in advance. > > > > > > Best Regards, > > > Giuseppe > > > > You're best bet is to CC Andrew on mmc patches (which I've now done). > > Thanks for your feedback and sorry if I didn't put Andrew on CC before. > I'm newer in this mailing list. I'm sorry, I dropped the linux-mmc mailing list when I replied to your mail! My bad. > > What is devm_stm_pad_claim()? I can't find this function in linus' > > tree, or in -next, or in Andrew's -mm series. Where is this function > > from? > > This comes from our STMicroelectronics platform pad management > infrastructure; code available from: > http://git.stlinux.com/?p=stm/linux-sh4-2.6.32.y.git;a=summary It's > used to claim/manage various resources i.e. PIO and clock lines. That's interesting. So, this driver won't build with linus' tree? I didn't think that the kernel catered for external interfaces like this - it causes all sorts of issues, not least of which is the fact that the driver can't be built or tested with the mainline kernel. Andrew, what do you make of this? -- 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 v6] OMAP4 HSMMC: Adding Card detect support for MMC1 on OMAP4
Andrew,
Can this patch be taken now as there are no comments.
Regards,
Kishore
On Wed, Jul 7, 2010 at 7:42 PM, kishore kadiyala
wrote:
> Adding card detect callback function and card detect configuration
> function for MMC1 Controller.
>
> Card detect configuration function does initial configuration of the
> MMC Control & PullUp-PullDown registers of Phoenix.
>
> For MMC1 Controller, Card detect interrupt source is
> twl6030 and the card detect call back function provides card present/absent
> status by reading MMC Control register.
>
> Signed-off-by: Kishore Kadiyala
> Cc: Tony Lindgren
> Cc: Madhusudhan Chikkature
> Cc: Adrian Hunter
> ---
> V5:
> https://patchwork.kernel.org/patch/106697/
> https://patchwork.kernel.org/patch/106698/
> V4:
> http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg01958.html
> http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg01949.html
>
>
> arch/arm/mach-omap2/board-4430sdp.c | 7 +++-
> drivers/mfd/twl6030-irq.c | 76
> +++
> drivers/mmc/host/omap_hsmmc.c | 4 +-
> include/linux/i2c/twl.h | 16 +++
> 4 files changed, 100 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
> b/arch/arm/mach-omap2/board-4430sdp.c
> index f287461..388b96d 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -227,9 +227,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device
> *dev)
> struct omap_mmc_platform_data *pdata = dev->platform_data;
>
> /* Setting MMC1 Card detect Irq */
> - if (pdev->id == 0)
> + if (pdev->id == 0) {
> + ret = twl6030_mmc_card_detect_config();
> + if (ret)
> + pr_err("Failed configuring MMC1 card detect\n");
> pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE +
> MMCDETECT_INTR_OFFSET;
> + pdata->slots[0].card_detect = twl6030_mmc_card_detect;
> + }
> return ret;
> }
>
> diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
> index 10bf228..c027692 100644
> --- a/drivers/mfd/twl6030-irq.c
> +++ b/drivers/mfd/twl6030-irq.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * TWL6030 (unlike its predecessors, which had two level interrupt handling)
> @@ -223,6 +224,81 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
> }
> EXPORT_SYMBOL(twl6030_interrupt_mask);
>
> +int twl6030_mmc_card_detect_config(void)
> +{
> + int ret;
> + u8 reg_val = 0;
> +
> + /* Unmasking the Card detect Interrupt line for MMC1 from Phoenix */
> + if (twl_class_is_6030()) {
> + twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
> + REG_INT_MSK_LINE_B);
> + twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
> + REG_INT_MSK_STS_B);
> + }
> +
> + /*
> + * Intially Configuring MMC_CTRL for receving interrupts &
> + * Card status on TWL6030 for MMC1
> + */
> + ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, ®_val, TWL6030_MMCCTRL);
> + if (ret < 0) {
> + pr_err("twl6030: Failed to read MMCCTRL, error %d\n", ret);
> + return ret;
> + }
> + reg_val &= ~VMMC_AUTO_OFF;
> + reg_val |= SW_FC;
> + ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
> + if (ret < 0) {
> + return ret;
> + pr_err("twl6030: Failed to write MMCCTRL, error %d\n", ret);
> + }
> +
> + /* Configuring PullUp-PullDown register */
> + ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, ®_val,
> + TWL6030_CFG_INPUT_PUPD3);
> + if (ret < 0) {
> + return ret;
> + pr_err("twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n",
> + ret);
> + }
> + reg_val &= ~(MMC_PU | MMC_PD);
> + ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
> + TWL6030_CFG_INPUT_PUPD3);
> + if (ret < 0) {
> + pr_err("twl6030: Failed to write CFG_INPUT_PUPD3, error %d\n",
> + ret);
> + return ret;
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL(twl6030_mmc_card_detect_config);
> +
> +int twl6030_mmc_card_detect(struct device *dev, int slot)
> +{
> + int ret = -EIO;
> + u8 read_reg;
> + struct platform_device *pdev = container_of(dev,
> + struct platform_device, dev);
> +
> + switch (pdev->id) {
> + case 0:
> + /*
> + * BIT0
Re: MX27 libertas_sdio SDIO Interrupts vs available bitrate
Hi Julien! Julien Boibessot wrote: > Andreas Feuersinger a écrit : > > Everything works except for very bad datarate. So far the mxc_mmc > > driver does not handle any SDIO interrupts. Could that be the reason > > for the bad performance? > > > Definitly ! > (I had the same "problem" on my i.MX27 platform before using SDIO > interrupts) thank you! At least I know where to go ;) While trying to enable SDIO handling I look at the mainline kernel patch for SDIO interrupts in mxcmmc.c. But in order to apply that I have to port that driver, introduced in 2.6.29 to my 2.6.22 kernel version. In the first step I try to get it run without sdio support. The driver seems to load helper firmware successfully and also real firmware. After that it stops where the libertas driver says: "waiting for firmware to boot." Register status is as follows: mxcmci_irq:status: <6>BUF_WRITE_RDY |<6>END_CMD_RESP |<6>BUF_UND_RUN |<6>XBUF_EMPTY |<6>YBUF_EMPTY |<6> Looks like stopped clock? Is the firmware supposed to start some cmd? I have a different question: Does anybody know if it is possible to boot freescale development board mx27pdk using kernel versions greater 2.6.30 ? thanks Andreas -- 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 00/20] native support for wl1271 on ZOOM
On Mon, Aug 2, 2010 at 2:42 PM, Tony Lindgren wrote: > Nicolas Pitre made a comment saying he wants to look at these patches > more, are there other pending comments? I plan to post a v3 series this week with some of the comments that were already discussed after v2. Thanks everyone for the attention, Ohad. > > Regards, > > Tony > -- 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 00/20] native support for wl1271 on ZOOM
* Luciano Coelho [100802 11:10]: > On Mon, 2010-07-26 at 21:30 +0200, ext John W. Linville wrote: > > On Wed, Jul 21, 2010 at 08:33:34PM +0300, Ohad Ben-Cohen wrote: > > > This patch series adds native support for wl1271 on ZOOM. > > > > Just for the record, I'm fine with the wl1271 bits here going through > > the omap tree with the rest of the series. > > Yeah, I agree. This is probably the best way to keep things in sync. OK, let's do that then. Nicolas Pitre made a comment saying he wants to look at these patches more, are there other pending comments? Regards, Tony -- 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 00/20] native support for wl1271 on ZOOM
On Mon, 2010-07-26 at 21:30 +0200, ext John W. Linville wrote: > On Wed, Jul 21, 2010 at 08:33:34PM +0300, Ohad Ben-Cohen wrote: > > This patch series adds native support for wl1271 on ZOOM. > > Just for the record, I'm fine with the wl1271 bits here going through > the omap tree with the rest of the series. Yeah, I agree. This is probably the best way to keep things in sync. -- Cheers, Luca. -- 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_test: Fix large memory allocation
From 665c12a94bd66a96adfad0b83deb6c6a72fb60e9 Mon Sep 17 00:00:00 2001
From: Adrian Hunter
Date: Mon, 2 Aug 2010 11:15:17 +0300
Subject: [PATCH] mmc_test: Fix large memory allocation
- Fix mmc_test_alloc_mem.
- Use nr_free_buffer_pages() instead of sysinfo.totalram to
determine total lowmem pages.
- Change variables containing memory sizes to unsigned long.
- Limit maximum test area size to 128MiB because that is the
maximum MMC high capacity erase size (the maxmium SD allocation
unit size is just 4MiB)
Signed-off-by: Adrian Hunter
---
drivers/mmc/card/mmc_test.c | 76 ++
1 files changed, 47 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 197f387..5dd8576 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -16,6 +16,7 @@
#include
#include
+#include /* For nr_free_buffer_pages() */
#define RESULT_OK 0
#define RESULT_FAIL 1
@@ -25,6 +26,12 @@
#define BUFFER_ORDER2
#define BUFFER_SIZE (PAGE_SIZE << BUFFER_ORDER)
+/*
+ * Limit the test area size to the maximum MMC HC erase group size. Note that
+ * the maximum SD allocation unit size is just 4MiB.
+ */
+#define TEST_AREA_MAX_SIZE (128 * 1024 * 1024)
+
/**
* struct mmc_test_pages - pages allocated by 'alloc_pages()'.
* @page: first page in the allocation
@@ -47,8 +54,8 @@ struct mmc_test_mem {
/**
* struct mmc_test_area - information for performance tests.
- * @dev_addr: address on card at which to do performance tests
* @max_sz: test area size (in bytes)
+ * @dev_addr: address on card at which to do performance tests
* @max_segs: maximum segments in scatterlist @sg
* @blocks: number of (512 byte) blocks currently mapped by @sg
* @sg_len: length of currently mapped scatterlist @sg
@@ -56,8 +63,8 @@ struct mmc_test_mem {
* @sg: scatterlist
*/
struct mmc_test_area {
+ unsigned long max_sz;
unsigned int dev_addr;
- unsigned int max_sz;
unsigned int max_segs;
unsigned int blocks;
unsigned int sg_len;
@@ -238,20 +245,19 @@ static void mmc_test_free_mem(struct mmc_test_mem *mem)
/*
* Allocate a lot of memory, preferrably max_sz but at least min_sz. In case
- * there isn't much memory do not exceed 1/16th total RAM.
+ * there isn't much memory do not exceed 1/16th total lowmem pages.
*/
-static struct mmc_test_mem *mmc_test_alloc_mem(unsigned int min_sz,
- unsigned int max_sz)
+static struct mmc_test_mem *mmc_test_alloc_mem(unsigned long min_sz,
+ unsigned long max_sz)
{
- unsigned int max_page_cnt = DIV_ROUND_UP(max_sz, PAGE_SIZE);
- unsigned int min_page_cnt = DIV_ROUND_UP(min_sz, PAGE_SIZE);
- unsigned int page_cnt = 0;
+ unsigned long max_page_cnt = DIV_ROUND_UP(max_sz, PAGE_SIZE);
+ unsigned long min_page_cnt = DIV_ROUND_UP(min_sz, PAGE_SIZE);
+ unsigned long page_cnt = 0;
+ unsigned long limit = nr_free_buffer_pages() >> 4;
struct mmc_test_mem *mem;
- struct sysinfo si;
- si_meminfo(&si);
- if (max_page_cnt > si.totalram >> 4)
- max_page_cnt = si.totalram >> 4;
+ if (max_page_cnt > limit)
+ max_page_cnt = limit;
if (max_page_cnt < min_page_cnt)
max_page_cnt = min_page_cnt;
@@ -270,7 +276,7 @@ static struct mmc_test_mem *mmc_test_alloc_mem(unsigned int
min_sz,
gfp_t flags = GFP_KERNEL | GFP_DMA | __GFP_NOWARN |
__GFP_NORETRY;
- order = get_order(page_cnt << PAGE_SHIFT);
+ order = get_order(max_page_cnt << PAGE_SHIFT);
while (1) {
page = alloc_pages(flags, order);
if (page || !order)
@@ -285,8 +291,10 @@ static struct mmc_test_mem *mmc_test_alloc_mem(unsigned
int min_sz,
mem->arr[mem->cnt].page = page;
mem->arr[mem->cnt].order = order;
mem->cnt += 1;
- max_page_cnt -= 1 << order;
- page_cnt += 1 << order;
+ if (max_page_cnt <= (1UL << order))
+ break;
+ max_page_cnt -= 1UL << order;
+ page_cnt += 1UL << order;
}
return mem;
@@ -300,7 +308,7 @@ out_free:
* Map memory into a scatterlist. Optionally allow the same memory to be
* mapped more than once.
*/
-static int mmc_test_map_sg(struct mmc_test_mem *mem, unsigned int sz,
+static int mmc_test_map_sg(struct mmc_test_mem *mem, unsigned long sz,
struct scatterlist *sglist, int repeat,
unsigned int max_segs, unsigned int *sg_len)
{
@@ -312,7 +320,7 @@ static int mmc_test_map_sg(struct mmc_test_mem *mem,
unsigned int sz,
*sg_len = 0;
do {
for (i = 0; i < mem->cnt; i++)
