Re: [PATCH v5 2/2] OMAP4 HSMMC: Adding card detect support for MMC1 Controller
ext kishore kadiyala wrote:
Adrian ,
Sorry for the late response
snip
As per my email 5/5/10, I would suggest the only change to omap_hsmmc is:
Agreed and followed the changes mostly but made some more changes on top of it.
snip
And that the late init function is used to do the rest e.g.
find a home for these 3 functions:
I agree just having the 3 functions makes it work.
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
int ret = 0;
struct platform_device *pdev = container_of(dev,
struct platform_device, dev);
struct omap_mmc_platform_data *pdata = dev-platform_data;
/* MMC1 Card detect Configuration */
if (pdev-id == 0) {
ret = omap4_hsmmc1_card_detect_config();
if (ret 0)
pr_err(Unable to configure Card detect for MMC1\n);
pdata-slots[0].card_detect = twl6030_mmc_card_detect;
pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
}
return ret;
snip
Few Comments below:
1) In the above function, initializing card_detect in the driver as
done in omap_hsmmc_gpio_init might be more readable and this has been
done in nongpio_init instead.
Even having initialization of card_detect_irq inside nongpio_init is fine.
The problem is that referencing twl6030 from omap_hsmmc.c is not ok.
The driver must work with any platform and that is the reason that
platform data provides callbacks.
2)Also calling omap_hsmmc_gpio_init in case of a card detect line
which is not GPIO
doesn't make sense though it assigns -EINVAL to switch_pin in case of
invalid GPIO
which is intended for a non-removable card .
3) And also having some thing like GPIO and NON_GPIO flag to
distinguish might make sense.
Regards,
Kishore
--
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 v5 2/2] OMAP4 HSMMC: Adding card detect support for MMC1 Controller
On Tue, Jun 29, 2010 at 1:00 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
ext kishore kadiyala wrote:
Adrian ,
Sorry for the late response
snip
As per my email 5/5/10, I would suggest the only change to omap_hsmmc is:
Agreed and followed the changes mostly but made some more changes on top
of it.
snip
And that the late init function is used to do the rest e.g.
find a home for these 3 functions:
I agree just having the 3 functions makes it work.
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
int ret = 0;
struct platform_device *pdev = container_of(dev,
struct platform_device, dev);
struct omap_mmc_platform_data *pdata = dev-platform_data;
/* MMC1 Card detect Configuration */
if (pdev-id == 0) {
ret = omap4_hsmmc1_card_detect_config();
if (ret 0)
pr_err(Unable to configure Card detect for
MMC1\n);
pdata-slots[0].card_detect = twl6030_mmc_card_detect;
pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
}
return ret;
snip
Few Comments below:
1) In the above function, initializing card_detect in the driver as
done in omap_hsmmc_gpio_init might be more readable and this has been
done in nongpio_init instead.
Even having initialization of card_detect_irq inside nongpio_init is
fine.
The problem is that referencing twl6030 from omap_hsmmc.c is not ok.
The driver must work with any platform and that is the reason that
platform data provides callbacks.
ok, in that case how about having handler initialized in
mach-omap2/hsmmc.c for both gpio and non-gpio case.
-Kishore
2)Also calling omap_hsmmc_gpio_init in case of a card detect line
which is not GPIO
doesn't make sense though it assigns -EINVAL to switch_pin in case of
invalid GPIO
which is intended for a non-removable card .
3) And also having some thing like GPIO and NON_GPIO flag to
distinguish might make sense.
Regards,
Kishore
--
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 v5 2/2] OMAP4 HSMMC: Adding card detect support for MMC1 Controller
kishore kadiyala wrote:
On Tue, Jun 29, 2010 at 1:00 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
ext kishore kadiyala wrote:
Adrian ,
Sorry for the late response
snip
As per my email 5/5/10, I would suggest the only change to omap_hsmmc is:
Agreed and followed the changes mostly but made some more changes on top
of it.
snip
And that the late init function is used to do the rest e.g.
find a home for these 3 functions:
I agree just having the 3 functions makes it work.
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
int ret = 0;
struct platform_device *pdev = container_of(dev,
struct platform_device, dev);
struct omap_mmc_platform_data *pdata = dev-platform_data;
/* MMC1 Card detect Configuration */
if (pdev-id == 0) {
ret = omap4_hsmmc1_card_detect_config();
if (ret 0)
pr_err(Unable to configure Card detect for
MMC1\n);
pdata-slots[0].card_detect = twl6030_mmc_card_detect;
pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
}
return ret;
snip
Few Comments below:
1) In the above function, initializing card_detect in the driver as
done in omap_hsmmc_gpio_init might be more readable and this has been
done in nongpio_init instead.
Even having initialization of card_detect_irq inside nongpio_init is
fine.
The problem is that referencing twl6030 from omap_hsmmc.c is not ok.
The driver must work with any platform and that is the reason that
platform data provides callbacks.
ok, in that case how about having handler initialized in
mach-omap2/hsmmc.c for both gpio and non-gpio case.
Unless twl6030 is part of OMAP4 then it doesn't belong in hsmmc.c either
-Kishore
2)Also calling omap_hsmmc_gpio_init in case of a card detect line
which is not GPIO
doesn't make sense though it assigns -EINVAL to switch_pin in case of
invalid GPIO
which is intended for a non-removable card .
3) And also having some thing like GPIO and NON_GPIO flag to
distinguish might make sense.
Regards,
Kishore
--
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 v5 2/2] OMAP4 HSMMC: Adding card detect support for MMC1 Controller
On Tue, Jun 29, 2010 at 1:48 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
kishore kadiyala wrote:
On Tue, Jun 29, 2010 at 1:00 PM, Adrian Hunter adrian.hun...@nokia.com
wrote:
ext kishore kadiyala wrote:
Adrian ,
Sorry for the late response
snip
As per my email 5/5/10, I would suggest the only change to omap_hsmmc
is:
Agreed and followed the changes mostly but made some more changes on
top
of it.
snip
And that the late init function is used to do the rest e.g.
find a home for these 3 functions:
I agree just having the 3 functions makes it work.
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
int ret = 0;
struct platform_device *pdev = container_of(dev,
struct platform_device, dev);
struct omap_mmc_platform_data *pdata = dev-platform_data;
/* MMC1 Card detect Configuration */
if (pdev-id == 0) {
ret = omap4_hsmmc1_card_detect_config();
if (ret 0)
pr_err(Unable to configure Card detect for
MMC1\n);
pdata-slots[0].card_detect = twl6030_mmc_card_detect;
pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
}
return ret;
snip
Few Comments below:
1) In the above function, initializing card_detect in the driver as
done in omap_hsmmc_gpio_init might be more readable and this has been
done in nongpio_init instead.
Even having initialization of card_detect_irq inside nongpio_init is
fine.
The problem is that referencing twl6030 from omap_hsmmc.c is not ok.
The driver must work with any platform and that is the reason that
platform data provides callbacks.
ok, in that case how about having handler initialized in
mach-omap2/hsmmc.c for both gpio and non-gpio case.
Unless twl6030 is part of OMAP4 then it doesn't belong in hsmmc.c either
ok, I'll make changes as suggested and post next version.
Regards,
Kishore
-Kishore
2)Also calling omap_hsmmc_gpio_init in case of a card detect line
which is not GPIO
doesn't make sense though it assigns -EINVAL to switch_pin in case of
invalid GPIO
which is intended for a non-removable card .
3) And also having some thing like GPIO and NON_GPIO flag to
distinguish might make sense.
Regards,
Kishore
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] add non-standard SDIO card support
This is my attempt to make SDIO interfaced TI WL1251 wifi chip usable on mainline kernels. It's driver has already been merged several releases back, but the problem is current SDIO core can't detect the card because it's not following SDIO standards and does not have any required SDIO registers. Currenty attempting to use this chip only results in several pages of complains about invalid register data from SDIO core. WL1251 is used on various HTC devices and Pandora handheld at least. People wanting to use this are forced to use forked trees or patches. My solution to this problem is to add new MMC quirk that will tell SDIO core not to access any SDIO registers and rely on host's init_card callback instead, which is now responsible for filling card related structures for SDIO core to function. Patches 2 and 3 set up the card for pandora, similar method could be used for MSM too. Only patches 2,3 depend on each other, so patch 1 can be merged separately. Grazvydas Ignotas (3): sdio: allow non-standard SDIO cards omap_hsmmc: add init_card pass-through callback omap: pandora: pass information about wl1251 to SDIO core arch/arm/mach-omap2/board-omap3pandora.c | 16 + arch/arm/mach-omap2/hsmmc.c |1 + arch/arm/mach-omap2/hsmmc.h |4 +++ arch/arm/plat-omap/include/plat/mmc.h|2 + drivers/mmc/core/sdio.c | 36 +- drivers/mmc/host/omap_hsmmc.c| 10 include/linux/mmc/card.h |2 + 7 files changed, 65 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] sdio: allow non-standard SDIO cards
There are some chips (like TI WL12xx series) that can be interfaced
over SDIO but don't support the SDIO specification, meaning that they
are missing CIA (Common I/O Area) with all it's registers. Current
Linux SDIO implementation relies on those registers to identify and
configure the card, so non-standard cards can not function and cause
lots of warnings from the core when it reads invalid data from
non-existent registers.
After this patch, init_card() host callback can now set new quirk
MMC_QUIRK_NONSTD_SDIO, which means that SDIO core should not try to
access any standard SDIO registers and rely on init_card() to fill all
SDIO structures instead. As those cards are usually embedded chips,
all the required information can be obtained from machine board files
by the host driver when it's called through init_card() callback.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/mmc/core/sdio.c | 36 ++--
include/linux/mmc/card.h |2 ++
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index b9dee28..cb66833 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -62,13 +62,19 @@ static int sdio_init_func(struct mmc_card *card, unsigned
int fn)
func-num = fn;
- ret = sdio_read_fbr(func);
- if (ret)
- goto fail;
+ if (!(card-quirks MMC_QUIRK_NONSTD_SDIO)) {
+ ret = sdio_read_fbr(func);
+ if (ret)
+ goto fail;
- ret = sdio_read_func_cis(func);
- if (ret)
- goto fail;
+ ret = sdio_read_func_cis(func);
+ if (ret)
+ goto fail;
+ } else {
+ func-vendor = func-card-cis.vendor;
+ func-device = func-card-cis.device;
+ func-max_blksize = func-card-cis.blksize;
+ }
card-sdio_func[fn - 1] = func;
@@ -321,6 +327,23 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32
ocr,
goto remove;
}
+ if (card-quirks MMC_QUIRK_NONSTD_SDIO) {
+ /*
+* This is non-standard SDIO device, meaning it doesn't
+* have any CIA (Common I/O area) registers present.
+* It's host's responsibility to fill cccr and cis
+* structures in init_card().
+*/
+ mmc_set_clock(host, card-cis.max_dtr);
+
+ if (card-cccr.high_speed) {
+ mmc_card_set_highspeed(card);
+ mmc_set_timing(card-host, MMC_TIMING_SD_HS);
+ }
+
+ goto finish;
+ }
+
/*
* Read the common registers.
*/
@@ -376,6 +399,7 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32
ocr,
if (err)
goto remove;
+finish:
if (!oldcard)
host-card = card;
return 0;
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index d02d2c6..cbc745c 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -101,6 +101,8 @@ struct mmc_card {
#define MMC_QUIRK_LENIENT_FN0 (10) /* allow SDIO FN0 writes
outside of the VS CCCR range */
#define MMC_QUIRK_BLKSZ_FOR_BYTE_MODE (11) /* use func-cur_blksize */
/* for byte mode */
+#define MMC_QUIRK_NONSTD_SDIO (12) /* non-standard SDIO card
attached */
+ /* (missing CIA registers) */
u32 raw_cid[4]; /* raw card CID */
u32 raw_csd[4]; /* raw card CSD */
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] omap_hsmmc: add init_card pass-through callback
This will allow us to set up special cards in machine drivers just
after they are detected by MMC core.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
arch/arm/plat-omap/include/plat/mmc.h |2 ++
drivers/mmc/host/omap_hsmmc.c | 10 ++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index c835f1e..9b89ec6 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -122,6 +122,8 @@ struct omap_mmc_platform_data {
/* Call back after enabling / disabling regulators */
void (*after_set_reg)(struct device *dev, int slot,
int power_on, int vdd);
+ /* if we have special card, init it using this callback */
+ void (*init_card)(struct mmc_card *card);
/* return MMC cover switch state, can be NULL if not supported.
*
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b032828..e8eb39e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1598,6 +1598,14 @@ static int omap_hsmmc_get_ro(struct mmc_host *mmc)
return mmc_slot(host).get_ro(host-dev, 0);
}
+static void omap_hsmmc_init_card(struct mmc_host *mmc, struct mmc_card *card)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+
+ if (mmc_slot(host).init_card)
+ mmc_slot(host).init_card(card);
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1869,6 +1877,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
+ .init_card = omap_hsmmc_init_card,
/* NYET -- enable_sdio_irq */
};
@@ -1879,6 +1888,7 @@ static const struct mmc_host_ops omap_hsmmc_ps_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
+ .init_card = omap_hsmmc_init_card,
/* NYET -- enable_sdio_irq */
};
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] omap: pandora: pass wl1251 information to SDIO core
Pandora has TI WL1251 attached on MMC3, which is non-standard SDIO chip.
Make use MMC_QUIRK_NONSTD_SDIO to tell SDIO core about it.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
arch/arm/mach-omap2/board-omap3pandora.c | 16
arch/arm/mach-omap2/hsmmc.c |1 +
arch/arm/mach-omap2/hsmmc.h |4
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index db06dc9..ebbfb49 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -29,6 +29,7 @@
#include linux/input.h
#include linux/input/matrix_keypad.h
#include linux/gpio_keys.h
+#include linux/mmc/card.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -227,6 +228,20 @@ static struct platform_device pandora_dss_device = {
},
};
+static void pandora_wl1251_init_card(struct mmc_card *card)
+{
+ /*
+* We have TI wl1251 attached to MMC3. Pass this information to
+* SDIO core because it can't be probed by normal methods.
+*/
+ card-quirks |= MMC_QUIRK_NONSTD_SDIO;
+ card-cccr.wide_bus = 1;
+ card-cis.vendor = 0x104c;
+ card-cis.device = 0x9066;
+ card-cis.blksize = 512;
+ card-cis.max_dtr = 2000;
+}
+
static struct omap2_hsmmc_info omap3pandora_mmc[] = {
{
.mmc= 1,
@@ -248,6 +263,7 @@ static struct omap2_hsmmc_info omap3pandora_mmc[] = {
.wires = 4,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+ .init_card = pandora_wl1251_init_card,
},
{} /* Terminator */
};
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 1ef54b0..c8f647b 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -268,6 +268,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
mmc-slots[0].gpio_wp = c-gpio_wp;
mmc-slots[0].remux = c-remux;
+ mmc-slots[0].init_card = c-init_card;
if (c-cover_only)
mmc-slots[0].cover = 1;
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 36f0ba8..1fe6f01 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -6,6 +6,8 @@
* published by the Free Software Foundation.
*/
+struct mmc_card;
+
struct omap2_hsmmc_info {
u8 mmc;/* controller 1/2/3 */
u8 wires; /* 1/4/8 wires */
@@ -23,6 +25,8 @@ struct omap2_hsmmc_info {
int ocr_mask; /* temporary HACK */
/* Remux (pad configuation) when powering on/off */
void (*remux)(struct device *dev, int slot, int power_on);
+ /* init some special card */
+ void (*init_card)(struct mmc_card *card);
};
#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
+ sdhci-8-bit-data-transfer-width-support.patch added to -mm tree
The patch titled sdhci: 8-bit data transfer width support has been added to the -mm tree. Its filename is sdhci-8-bit-data-transfer-width-support.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: sdhci: 8-bit data transfer width support From: Kyungmin Park kyungmin.p...@samsung.com Some host controllers such as s5pc110 support the WIDE8 feature. Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: linux-mmc@vger.kernel.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/mmc/host/sdhci.c |5 + drivers/mmc/host/sdhci.h |1 + 2 files changed, 6 insertions(+) diff -puN drivers/mmc/host/sdhci.c~sdhci-8-bit-data-transfer-width-support drivers/mmc/host/sdhci.c --- a/drivers/mmc/host/sdhci.c~sdhci-8-bit-data-transfer-width-support +++ a/drivers/mmc/host/sdhci.c @@ -1159,6 +1159,11 @@ static void sdhci_set_ios(struct mmc_hos ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL); + if (ios-bus_width == MMC_BUS_WIDTH_8) + ctrl |= SDHCI_CTRL_8BITBUS; + else + ctrl = ~SDHCI_CTRL_8BITBUS; + if (ios-bus_width == MMC_BUS_WIDTH_4) ctrl |= SDHCI_CTRL_4BITBUS; else diff -puN drivers/mmc/host/sdhci.h~sdhci-8-bit-data-transfer-width-support drivers/mmc/host/sdhci.h --- a/drivers/mmc/host/sdhci.h~sdhci-8-bit-data-transfer-width-support +++ a/drivers/mmc/host/sdhci.h @@ -72,6 +72,7 @@ #define SDHCI_CTRL_ADMA1 0x08 #define SDHCI_CTRL_ADMA320x10 #define SDHCI_CTRL_ADMA640x18 +#define SDHCI_CTRL_8BITBUS0x20 #define SDHCI_POWER_CONTROL0x29 #define SDHCI_POWER_ON0x01 _ Patches currently in -mm which might be from kyungmin.p...@samsung.com are linux-next.patch mmc-recognize-csd-structure.patch mmc-recognize-csd-structure-fix.patch s5pc110-sdhci-s3c-can-override-host-capabilities.patch s5pc110-sdhci-s3c-support-on-s5pc110.patch sdhci-add-no-hi-speed-bit-quirk-support.patch sdhci-remove-useless-set_clock-check.patch sdhci-8-bit-data-transfer-width-support.patch sdhci-dont-assign-mmc-caps-at-sdhci-directly.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 3/3] SDHCI: 8-bit data transfer width support
On Mon, 28 Jun 2010 12:48:29 -0700 Grant Likely grant.lik...@secretlab.ca wrote: On Mon, Jun 28, 2010 at 12:33 PM, Olof Johansson o...@lixom.net wrote: On Mon, Jun 28, 2010 at 11:56:26AM -0700, Colin Cross wrote: These patches are not coming from the tegra/for-next branch, they are coming from Grant's devicetree-next branch. __Grant, why are these patches in your tree, and why is tegra/for-next in your tree? __It's going to cause conflicts when we rebase our for-next branch. __Please remove tegra and this sdhci patch from your tree. Yeah, this seems to be a mixup by Grant. I gave him a few patches I had picked up locally to work with, and he seems to have published the work accidentally. Hi Colin, I've fixed it now. Profuse apologies, sorry for the noise, and I owe you a beer or 3. Thanks, guys - I resurrected sdhci-8-bit-data-transfer-width-support.patch and sdhci-dont-assign-mmc-caps-at-sdhci-directly.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 v3] MMC: Add JZ4740 mmc driver
On Mon, 28 Jun 2010 03:20:41 +0200, Lars-Peter Clausen l...@metafoo.de wrote: This patch adds support for the mmc controller on JZ4740 SoCs. Signed-off-by: Lars-Peter Clausen l...@metafoo.de Cc: Andrew Morton a...@linux-foundation.org Cc: Matt Fleming m...@console-pimps.org Cc: linux-mmc@vger.kernel.org --- Changes since v1 - Do not request IRQ with IRQF_DISABLED since it is a noop now - Use a generous slack for the timeout timer. It does not need to be accurate. Changes since v2 - Use sg_mapping_to iterate over sg elements in mmc read and write functions - Use bitops instead of a spinlock and a variable for testing whether a request has been finished. - Rework irq and timeout handling in order to get rid of locking in hot paths Acked-by: Matt Fleming m...@console-pimps.org Are you planning on maintaining this driver? If so, it'd be a good idea to update MAINTAINERS. -- 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
Request for SPI testing
I've pushed out Ernst's spi bus locking API patches to the following branch. Before I push them into linux-next, I'd like to get some testing. Can I have some volunteers please to pull this branch and give it a spin? Bonus points for people who have mmc cards multiplexed with other devices on their SPI bus. Cheers, g. The following changes since commit 5904b3b81d25166e5e39b9727645bb47937618e3: Linus Torvalds (1): Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 spi/test Cory Maccarrone (1): SPI100k: Fix 8-bit and RX-only transfers Ernst Schwab (2): spi/mmc_spi: SPI bus locking API, using mutex spi/mmc_spi: mmc_spi adaptations for SPI bus locking API drivers/mmc/host/mmc_spi.c | 59 ++- drivers/spi/omap_spi_100k.c | 23 +++-- drivers/spi/spi.c | 225 --- include/linux/spi/spi.h | 12 +++ 4 files changed, 227 insertions(+), 92 deletions(-) -- 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
