Re: [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO
On Wed, Oct 10, 2012 at 06:03:19PM +0200, Ulf Hansson wrote: From: Ulf Hansson ulf.hans...@linaro.org For data writes = 8 bytes, HW flow control was disabled but never re-enabled when the transfer was completed. This meant that a following read request would give buffer overrun errors. Signed-off-by: Ulf Hansson ulf.hans...@linaro.org Both look fine to me too. Linus' has already said what needs to happen with these two. Thanks. -- 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: [RFC PATCH v2 08/16] ARM: omap: add hsmmc am33xx specific init
Matt On Fri, Oct 12, 2012 at 00:34:33, Porter, Matt wrote: AM33xx requires special handling in hsmmc initialization platform glue. Since AM335x boots mainly through DT, do we still need this patch. This function will be called in case of initializing hsmmc with Platform data. Signed-off-by: Matt Porter mpor...@ti.com --- arch/arm/mach-omap2/hsmmc.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) ..snip.. ..snip.. name = omap_hsmmc; res = snprintf(oh_name, MAX_OMAP_MMC_HWMOD_NAME_LEN, -- 1.7.9.5 ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source Regards, Gururaja -- 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/4] MMC: some omap_hsmmc fixes
Here are some assorted patches for the omap_hsmmc driver that I need on top Linus' current development branch to make it work on a AM33xx board. 1/4 and 2/4 qualify as bug fixes and I'm puzzled that these didn't hit anyone else yet. Daniel Mack (4): MMC: omap_hsmmc: set platform data after probe from DT node MMC: omap_hsmmc: fix DMA config block MMC: omap_hsmmc: claim pinctrl at probe time MMC: omap_hsmmc: add DT property for max bus frequency drivers/mmc/host/omap_hsmmc.c | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) -- 1.7.11.4 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] MMC: omap_hsmmc: set platform data after probe from DT node
When probed from DT, the self-allocated platform data has to be attached
to the actual device. Otherwise a NULL pointer will be dereferenced from
omap_hsmmc_card_detect if a gpio handle for card-detect has been passed.
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Venkatraman S svenk...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: linux-o...@vger.kernel.org
---
drivers/mmc/host/omap_hsmmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 19ccb59..4b70823 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1728,6 +1728,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
const u16 *offsetp = match-data;
pdata-reg_offset = *offsetp;
}
+ pdev-dev.platform_data = pdata;
}
if (pdata == NULL) {
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] MMC: omap_hsmmc: fix DMA config block
The .direction field of the config passed to dmaengine_slave_config()
must be set in order to make the generic code store the configured bus
width.
Without this patch, I keep getting the following error on a AM33xx
board:
[1.963144] edma-dma-engine edma-dma-engine.0: Undefined slave buswidth
[1.970158] omap_hsmmc mmc.4: prep_slave_sg() failed
[1.975454] mmc1: error -1 whilst initialising SD card
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Venkatraman S svenk...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: linux-o...@vger.kernel.org
Cc: Matt Porter mpor...@ti.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/mmc/host/omap_hsmmc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b70823..2c57b0d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1260,6 +1260,8 @@ static int omap_hsmmc_start_dma_transfer(struct
omap_hsmmc_host *host,
cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
cfg.src_maxburst = data-blksz / 4;
cfg.dst_maxburst = data-blksz / 4;
+ cfg.direction = data-flags MMC_DATA_WRITE ?
+ DMA_MEM_TO_DEV : DMA_DEV_TO_MEM;
ret = dmaengine_slave_config(chan, cfg);
if (ret)
@@ -1270,8 +1272,8 @@ static int omap_hsmmc_start_dma_transfer(struct
omap_hsmmc_host *host,
return ret;
tx = dmaengine_prep_slave_sg(chan, data-sg, data-sg_len,
- data-flags MMC_DATA_WRITE ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+cfg.direction,
+DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!tx) {
dev_err(mmc_dev(host-mmc), prep_slave_sg() failed\n);
/* FIXME: cleanup */
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] MMC: omap_hsmmc: add DT property for max bus frequency
Maximum bus frequency can be limited by external circuitry like level
shifters etc. Allow passing this value from DT.
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Venkatraman S svenk...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: linux-o...@vger.kernel.org
---
drivers/mmc/host/omap_hsmmc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 86f0759..4650ef7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1676,7 +1676,7 @@ static struct omap_mmc_platform_data
*of_get_hsmmc_pdata(struct device *dev)
{
struct omap_mmc_platform_data *pdata;
struct device_node *np = dev-of_node;
- u32 bus_width;
+ u32 bus_width, max_freq;
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -1703,6 +1703,9 @@ static struct omap_mmc_platform_data
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, ti,needs-special-reset, NULL))
pdata-slots[0].features |= HSMMC_HAS_UPDATED_RESET;
+ if (!of_property_read_u32(np, max-frequency, max_freq))
+ pdata-max_freq = max_freq;
+
return pdata;
}
#else
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] MMC: omap_hsmmc: fix DMA config block
On Oct 12, 2012, at 6:58 AM, Daniel Mack wrote:
The .direction field of the config passed to dmaengine_slave_config()
must be set in order to make the generic code store the configured bus
width.
Without this patch, I keep getting the following error on a AM33xx
board:
[1.963144] edma-dma-engine edma-dma-engine.0: Undefined slave buswidth
[1.970158] omap_hsmmc mmc.4: prep_slave_sg() failed
[1.975454] mmc1: error -1 whilst initialising SD card
Hi Daniel,
I posted a patch to fix the slave config handling in the EDMA DMA Engine
driver here: https://patchwork.kernel.org/patch/1474411/
Vinod didn't pick that up for 3.7, probably because it's not triggered by
any of the in-tree davinci drivers that are converted. However, I am
carrying the same patch in the am335x edma dmaengine v2 series
(https://lkml.org/lkml/2012/10/11/345) so there's no need to change this
driver.
-Matt
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Venkatraman S svenk...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: linux-o...@vger.kernel.org
Cc: Matt Porter mpor...@ti.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/mmc/host/omap_hsmmc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b70823..2c57b0d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1260,6 +1260,8 @@ static int omap_hsmmc_start_dma_transfer(struct
omap_hsmmc_host *host,
cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
cfg.src_maxburst = data-blksz / 4;
cfg.dst_maxburst = data-blksz / 4;
+ cfg.direction = data-flags MMC_DATA_WRITE ?
+ DMA_MEM_TO_DEV : DMA_DEV_TO_MEM;
ret = dmaengine_slave_config(chan, cfg);
if (ret)
@@ -1270,8 +1272,8 @@ static int omap_hsmmc_start_dma_transfer(struct
omap_hsmmc_host *host,
return ret;
tx = dmaengine_prep_slave_sg(chan, data-sg, data-sg_len,
- data-flags MMC_DATA_WRITE ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ cfg.direction,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!tx) {
dev_err(mmc_dev(host-mmc), prep_slave_sg() failed\n);
/* FIXME: cleanup */
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] MMC: omap_hsmmc: claim pinctrl at probe time
On Fri, Oct 12, 2012 at 12:58 PM, Daniel Mack zon...@gmail.com wrote: This allows DT-driven board to set up the pin mux only when the driver is in use. Signed-off-by: Daniel Mack zon...@gmail.com Cc: Venkatraman S svenk...@ti.com Cc: Chris Ball c...@laptop.org Cc: Grant Likely grant.lik...@secretlab.ca Cc: Rob Herring rob.herr...@calxeda.com Cc: Linus Walleij linus.wall...@linaro.org Cc: linux-o...@vger.kernel.org Looks nice! Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] MMC: omap_hsmmc: fix DMA config block
On Fri, Oct 12, 2012 at 12:58:13PM +0200, Daniel Mack wrote: The .direction field of the config passed to dmaengine_slave_config() must be set in order to make the generic code store the configured bus width. NAK. The direction field is deprecated, and should not be used anymore. -- 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: [RFC PATCH v2 08/16] ARM: omap: add hsmmc am33xx specific init
On Fri, Oct 12, 2012 at 09:17:53AM +, Hebbar, Gururaja wrote: Matt On Fri, Oct 12, 2012 at 00:34:33, Porter, Matt wrote: AM33xx requires special handling in hsmmc initialization platform glue. Since AM335x boots mainly through DT, do we still need this patch. This function will be called in case of initializing hsmmc with Platform data. Yes, thanks, will drop in v3. -Matt -- 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: [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO
On Fri, Oct 12, 2012 at 10:13:22AM +0100, Russell King - ARM Linux wrote: On Wed, Oct 10, 2012 at 06:03:19PM +0200, Ulf Hansson wrote: From: Ulf Hansson ulf.hans...@linaro.org For data writes = 8 bytes, HW flow control was disabled but never re-enabled when the transfer was completed. This meant that a following read request would give buffer overrun errors. Signed-off-by: Ulf Hansson ulf.hans...@linaro.org Both look fine to me too. Linus' has already said what needs to happen with these two. Thanks. Ulf, I see you've tried three times to get a replacement password for the patch system today. If it's not getting through, you need to complain to your IT department, and get them to complain to Google: 2012-10-12 11:09:21 1TMcBE-0005ED-VS = apa...@arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:55740 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=e1tmcbd-00061o...@n2100.arm.linux.org.uk T=Your new password for ulf.hans...@stericsson.com 2012-10-12 11:09:24 1TMcBE-0005ED-VS = ulf.hans...@stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com C=250 Thanks 2012-10-12 11:25:13 1TMcQb-0005EY-8d = apa...@arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:37918 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=e1tmcqz-00066s...@n2100.arm.linux.org.uk T=Your new password for ulf.hans...@stericsson.com 2012-10-12 11:25:17 1TMcQb-0005EY-8d = ulf.hans...@stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com C=250 Thanks 2012-10-12 12:25:56 1TMdNM-0005IG-8u = apa...@arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:57521 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=e1tmdnk-0006xu...@n2100.arm.linux.org.uk T=Your new password for ulf.hans...@stericsson.com 2012-10-12 12:25:59 1TMdNM-0005IG-8u = ulf.hans...@stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com C=250 Thanks You are not the first to encounter this problem. psmtp.com seems to put the password reminders into a big black hole, and this is inspite of them trying to follow every possible RFC concerning auto-generated mail, and being DKIM signed too. Unfortunately, what this means is that effectively the spammers have won the arms race: it is becoming increasingly difficult to get email through to the intended destination due to all the filtering that people now impose (not that it ever has been guaranteed.) -- 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
[GIT PULL] MMC merge for 3.7-rc1, part 2
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
tags/mmc-merge-for-3.7-rc1-part2
to receive two more changes for 3.7. There are no conflicts. Thanks.
The following changes since commit 12250d843e8489ee00b5b7726da855e51694e792:
Merge branch 'i2c-embedded/for-next' of
git://git.pengutronix.de/git/wsa/linux (2012-10-11 10:27:51 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
tags/mmc-merge-for-3.7-rc1-part2
for you to fetch changes up to 60fe5771be6aa3f37d5887aa01c04f733130a559:
UAPI: (Scripted) Disintegrate include/linux/mmc (2012-10-11 17:27:54 -0400)
- Disintegrate UAPI, fix a mismerge that caused a build error.
David Howells (1):
UAPI: (Scripted) Disintegrate include/linux/mmc
Marek Vasut (1):
mmc: mxs-mmc: Fix merge issue causing build error
drivers/mmc/host/mxs-mmc.c | 2 +-
include/linux/mmc/Kbuild | 1 -
include/uapi/linux/mmc/Kbuild| 1 +
include/{ = uapi}/linux/mmc/ioctl.h | 0
4 files changed, 2 insertions(+), 2 deletions(-)
rename include/{ = uapi}/linux/mmc/ioctl.h (100%)
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO
On 10/12/2012 01:54 PM, Russell King - ARM Linux wrote: On Fri, Oct 12, 2012 at 10:13:22AM +0100, Russell King - ARM Linux wrote: On Wed, Oct 10, 2012 at 06:03:19PM +0200, Ulf Hansson wrote: From: Ulf Hanssonulf.hans...@linaro.org For data writes= 8 bytes, HW flow control was disabled but never re-enabled when the transfer was completed. This meant that a following read request would give buffer overrun errors. Signed-off-by: Ulf Hanssonulf.hans...@linaro.org Both look fine to me too. Linus' has already said what needs to happen with these two. Thanks. Ulf, I see you've tried three times to get a replacement password for the patch system today. If it's not getting through, you need to complain to your IT department, and get them to complain to Google: 2012-10-12 11:09:21 1TMcBE-0005ED-VS= apa...@arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:55740 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=e1tmcbd-00061o...@n2100.arm.linux.org.uk T=Your new password for ulf.hans...@stericsson.com 2012-10-12 11:09:24 1TMcBE-0005ED-VS = ulf.hans...@stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com C=250 Thanks 2012-10-12 11:25:13 1TMcQb-0005EY-8d= apa...@arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:37918 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=e1tmcqz-00066s...@n2100.arm.linux.org.uk T=Your new password for ulf.hans...@stericsson.com 2012-10-12 11:25:17 1TMcQb-0005EY-8d = ulf.hans...@stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com C=250 Thanks 2012-10-12 12:25:56 1TMdNM-0005IG-8u= apa...@arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:57521 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=e1tmdnk-0006xu...@n2100.arm.linux.org.uk T=Your new password for ulf.hans...@stericsson.com 2012-10-12 12:25:59 1TMdNM-0005IG-8u = ulf.hans...@stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com C=250 Thanks You are not the first to encounter this problem. psmtp.com seems to put the password reminders into a big black hole, and this is inspite of them trying to follow every possible RFC concerning auto-generated mail, and being DKIM signed too. Unfortunately, what this means is that effectively the spammers have won the arms race: it is becoming increasingly difficult to get email through to the intended destination due to all the filtering that people now impose (not that it ever has been guaranteed.) Hi Russell, Our IT department is slow, too slow. :-) As an option, would it be possible for you to manually send me a new password? Another option would be to change the mail for my account to ulf.hans...@linaro.org Any help appreciated! Kind regards Ulf Hansson -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO
On Fri, Oct 12, 2012 at 02:24:16PM +0200, Ulf Hansson wrote: Hi Russell, Our IT department is slow, too slow. :-) As an option, would it be possible for you to manually send me a new password? Another option would be to change the mail for my account to ulf.hans...@linaro.org Updated the email address; that's easier than trying to generate a new password manually. Please ask the site for a replacement password using your linaro address and hopefully you should get it. -- 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: [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO
On 12 October 2012 14:35, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Oct 12, 2012 at 02:24:16PM +0200, Ulf Hansson wrote: Hi Russell, Our IT department is slow, too slow. :-) As an option, would it be possible for you to manually send me a new password? Another option would be to change the mail for my account to ulf.hans...@linaro.org Updated the email address; that's easier than trying to generate a new password manually. Please ask the site for a replacement password using your linaro address and hopefully you should get it. Thanks a lot for helping out. I got a new pwd now! Kind regards Ulf Hansson -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Disintegrate UAPI for mmc
Hi David, On Tue, Oct 09 2012, David Howells wrote: Can you merge the following branch into the mmc tree please. This is to complete part of the Userspace API (UAPI) disintegration for which the preparatory patches were pulled recently. After these patches, userspace headers will be segregated into: include/uapi/linux/.../foo.h for the userspace interface stuff, and: include/linux/.../foo.h for the strictly kernel internal stuff. --- The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-mmc-20121009 for you to fetch changes up to ad1cfdcef1378adc7215a74772f7d06c4cc6ef50: UAPI: (Scripted) Disintegrate include/linux/mmc (2012-10-09 09:48:45 +0100) Thanks, I've sent this to Linus now. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant
From: Ulf Hansson ulf.hans...@linaro.org
For the ux500v2 variant non power of two block sizes are supported.
This will make it possible to decrease data overhead for SDIO
transfers. Although we need to put some constraints to the alignment
of the buffers when enabling this feature.
Buffers must be 4 bytes aligned due to restrictions that the PL18x
FIFO accesses must be done in a 4 byte aligned manner. Moreover we
need to enable DMA_REQCTL for SDIO to support write of non 32 bytes
aligned sg element lengths. In PIO mode any buffer length can be
handled as long as the buffer address is 4 byte aligned.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Signed-off-by: Per Forlin per.for...@stericsson.com
---
drivers/mmc/host/mmci.c | 56 +--
drivers/mmc/host/mmci.h |7 ++
2 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index edc3e9b..ca6d128 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -48,6 +48,7 @@ static unsigned int fmax = 515633;
* struct variant_data - MMCI variant-specific quirks
* @clkreg: default value for MCICLOCK register
* @clkreg_enable: enable value for MMCICLOCK register
+ * @dma_sdio_req_ctrl: enable value for DMAREQCTL register for SDIO write
* @datalength_bits: number of bits in the MMCIDATALENGTH register
* @fifosize: number of bytes that can be written when MMCI_TXFIFOEMPTY
* is asserted (likewise for RX)
@@ -58,10 +59,12 @@ static unsigned int fmax = 515633;
* @blksz_datactrl16: true if Block size is at b16..b30 position in datactrl
register
* @pwrreg_powerup: power up value for MMCIPOWER register
* @signal_direction: input/out direction of bus signals can be indicated
+ * @non_power_of_2_blksize: true if block sizes can be other than power of two
*/
struct variant_data {
unsigned intclkreg;
unsigned intclkreg_enable;
+ unsigned intdma_sdio_req_ctrl;
unsigned intdatalength_bits;
unsigned intfifosize;
unsigned intfifohalfsize;
@@ -70,6 +73,7 @@ struct variant_data {
boolblksz_datactrl16;
u32 pwrreg_powerup;
boolsignal_direction;
+ boolnon_power_of_2_blksize;
};
static struct variant_data variant_arm = {
@@ -112,6 +116,7 @@ static struct variant_data variant_ux500 = {
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
.clkreg_enable = MCI_ST_UX500_HWFCEN,
+ .dma_sdio_req_ctrl = MCI_ST_DPSM_DMAREQCTL,
.datalength_bits= 24,
.sdio = true,
.st_clkdiv = true,
@@ -124,15 +129,42 @@ static struct variant_data variant_ux500v2 = {
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
.clkreg_enable = MCI_ST_UX500_HWFCEN,
+ .dma_sdio_req_ctrl = MCI_ST_DPSM_DMAREQCTL,
.datalength_bits= 24,
.sdio = true,
.st_clkdiv = true,
.blksz_datactrl16 = true,
.pwrreg_powerup = MCI_PWR_ON,
.signal_direction = true,
+ .non_power_of_2_blksize = true,
};
/*
+ * Validate mmc prerequisites
+ */
+static int mmci_validate_data(struct mmci_host *host,
+ struct mmc_data *data)
+{
+ if (!data)
+ return 0;
+
+ if (!host-variant-non_power_of_2_blksize
+ !is_power_of_2(data-blksz)) {
+ dev_err(mmc_dev(host-mmc),
+ unsupported block size (%d bytes)\n, data-blksz);
+ return -EINVAL;
+ }
+
+ if (data-sg-offset 3) {
+ dev_err(mmc_dev(host-mmc),
+ unsupported alginment (0x%x)\n, data-sg-offset);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/*
* This must be called with host-lock held
*/
static void mmci_write_clkreg(struct mmci_host *host, u32 clk)
@@ -446,8 +478,12 @@ static int mmci_dma_prep_data(struct mmci_host *host,
struct mmc_data *data,
if (!chan)
return -EINVAL;
- /* If less than or equal to the fifo size, don't bother with DMA */
- if (data-blksz * data-blocks = variant-fifosize)
+ /*
+* If less than or equal to the fifo size, don't bother with DMA
+* SDIO transfers may not be 4 bytes aligned, fall back to PIO
+*/
+ if (data-blksz * data-blocks = variant-fifosize ||
+ (data-blksz * data-blocks) 3)
return -EINVAL;
device = chan-device;
@@ -482,6 +518,7 @@ static int mmci_dma_start_data(struct mmci_host *host,
unsigned int datactrl)
{
int ret;
struct mmc_data *data = host-data;
+ struct
Re: [PATCH 1/4] MMC: omap_hsmmc: set platform data after probe from DT node
On 12.10.2012 12:58, Daniel Mack wrote:
When probed from DT, the self-allocated platform data has to be attached
to the actual device. Otherwise a NULL pointer will be dereferenced from
omap_hsmmc_card_detect if a gpio handle for card-detect has been passed.
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Venkatraman S svenk...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: linux-o...@vger.kernel.org
---
drivers/mmc/host/omap_hsmmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 19ccb59..4b70823 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1728,6 +1728,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
const u16 *offsetp = match-data;
pdata-reg_offset = *offsetp;
}
+ pdev-dev.platform_data = pdata;
}
if (pdata == NULL) {
FWIW, this is the Oops I see without this patch:
[1.492727] Unable to handle kernel NULL pointer dereference at
virtual address 0040
[1.501327] pgd = c0004000
[1.504166] [0040] *pgd=
[1.507993] Internal error: Oops: 5 [#1] SMP THUMB2
[1.513100] Modules linked in:
[1.516315] CPU: 0Not tainted (3.6.0-10656-g4bc7e4d-dirty #75)
[1.522890] PC is at omap_hsmmc_card_detect+0x6/0x18
[1.528090] LR is at omap_hsmmc_get_cd+0x1d/0x24
[1.532929] pc : [c025a3ee]lr : [c0259fed]psr: 4133
[1.532929] sp : cf1b5e78 ip : 0c288145 fp : 0002
[1.544939] r10: cf1b4000 r9 : cf1b5eb8 r8 :
[1.550408] r7 : cf1a4600 r6 : 6113 r5 : cf33ba98 r4 : cf33b800
[1.557240] r3 : r2 : r1 : r0 : cf0d1c10
[1.564075] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA Thumb
Segment kernel
[1.571906] Control: 50c5387d Table: 80004019 DAC: 0015
[1.577921] Process kworker/u:1 (pid: 19, stack limit = 0xcf1b4240)
[1.584480] Stack: (0xcf1b5e78 to 0xcf1b6000)
[1.589045] 5e60:
c025a3e9 c0259fed
[1.597611] 5e80: c0259fd1 c024f959 cf33bb0c cf1a5dc0 c05c87c0
c003a42f 0002
[1.606176] 5ea0: c003a3d8 c005e181 cf1b35c0
c024f829 c0adfe68 c0687048
[1.614741] 5ec0: c0494f78 c05c8780 cf1a5dc0 c05c88e8
cf1b4000 c05c88f0 cf1a5dd0
[1.623306] 5ee0: c0531f40 c053d678 c05c8780 c003c2ab cf1b5f18
c005e935 c05c87c0 c0531f40
[1.631872] 5f00: c0531f40 c7e3f1f9 cf1b5f34 cf069e20 cf1b5f34
cf1a5dc0 c003c191
[1.640436] 5f20: c003f809
cf1a5dc0
[1.649001] 5f40: dead4ead
c05c8ef8
[1.657565] 5f60: c0455c08 cf1b5f64 cf1b5f64
dead4ead
[1.666130] 5f80: c05c8ef8 c0455c08 cf1b5f90
cf1b5f90 cf069e20 c003f791
[1.674694] 5fa0: c000d1e1 aaa3aaab
b1ba aae3ea32 aba2a3aa
[1.683260] 5fc0: baaababe bbbaaaba aa2b bb2e2aba aabaa2bb
aaabb2bb aaabbaf3 f3bb2aaa
[1.691824] 5fe0: aabaabba 23ae2beb a2afab2a b2a2ab2a 0013
aaabaaab bfaf a0a2
[1.700399] [c025a3ee] (omap_hsmmc_card_detect+0x6/0x18) from
[c0259fed] (omap_hsmmc_get_cd+0x1d/0x24)
[1.710528] [c0259fed] (omap_hsmmc_get_cd+0x1d/0x24) from
[c024f959] (mmc_rescan+0x131/0x1e4)
[1.719842] [c024f959] (mmc_rescan+0x131/0x1e4) from [c003a42f]
(process_one_work+0x137/0x37c)
[1.729234] [c003a42f] (process_one_work+0x137/0x37c) from
[c003c2ab] (worker_thread+0x11b/0x364)
[1.738899] [c003c2ab] (worker_thread+0x11b/0x364) from
[c003f809] (kthread+0x79/0x84)
[1.747572] [c003f809] (kthread+0x79/0x84) from [c000d1e1]
(ret_from_kernel_thread+0xd/0x14)
[1.756773] Code: bf00 b508 f8d0 3084 (6c18) f75f
[1.761943] ---[ end trace b94c447c4835422d ]---
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] MMC: omap_hsmmc: set platform data after probe from DT node
On Friday 12 October 2012 07:59 PM, Daniel Mack wrote:
On 12.10.2012 12:58, Daniel Mack wrote:
When probed from DT, the self-allocated platform data has to be attached
to the actual device. Otherwise a NULL pointer will be dereferenced from
omap_hsmmc_card_detect if a gpio handle for card-detect has been passed.
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Venkatraman S svenk...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: linux-o...@vger.kernel.org
---
drivers/mmc/host/omap_hsmmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 19ccb59..4b70823 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1728,6 +1728,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
const u16 *offsetp = match-data;
pdata-reg_offset = *offsetp;
}
+ pdev-dev.platform_data = pdata;
}
if (pdata == NULL) {
FWIW, this is the Oops I see without this patch:
Hi,
Shouldn't pdev-dev.platform_data be set to NULL on _remove ?
BTW, I posted a patch for the same by accessing saved version from
host-pdata
http://permalink.gmane.org/gmane.linux.kernel.mmc/16996
[1.492727] Unable to handle kernel NULL pointer dereference at
virtual address 0040
[1.501327] pgd = c0004000
[1.504166] [0040] *pgd=
[1.507993] Internal error: Oops: 5 [#1] SMP THUMB2
[1.513100] Modules linked in:
[1.516315] CPU: 0Not tainted (3.6.0-10656-g4bc7e4d-dirty #75)
[1.522890] PC is at omap_hsmmc_card_detect+0x6/0x18
[1.528090] LR is at omap_hsmmc_get_cd+0x1d/0x24
[1.532929] pc : [c025a3ee]lr : [c0259fed]psr: 4133
[1.532929] sp : cf1b5e78 ip : 0c288145 fp : 0002
[1.544939] r10: cf1b4000 r9 : cf1b5eb8 r8 :
[1.550408] r7 : cf1a4600 r6 : 6113 r5 : cf33ba98 r4 : cf33b800
[1.557240] r3 : r2 : r1 : r0 : cf0d1c10
[1.564075] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA Thumb
Segment kernel
[1.571906] Control: 50c5387d Table: 80004019 DAC: 0015
[1.577921] Process kworker/u:1 (pid: 19, stack limit = 0xcf1b4240)
[1.584480] Stack: (0xcf1b5e78 to 0xcf1b6000)
[1.589045] 5e60:
c025a3e9 c0259fed
[1.597611] 5e80: c0259fd1 c024f959 cf33bb0c cf1a5dc0 c05c87c0
c003a42f 0002
[1.606176] 5ea0: c003a3d8 c005e181 cf1b35c0
c024f829 c0adfe68 c0687048
[1.614741] 5ec0: c0494f78 c05c8780 cf1a5dc0 c05c88e8
cf1b4000 c05c88f0 cf1a5dd0
[1.623306] 5ee0: c0531f40 c053d678 c05c8780 c003c2ab cf1b5f18
c005e935 c05c87c0 c0531f40
[1.631872] 5f00: c0531f40 c7e3f1f9 cf1b5f34 cf069e20 cf1b5f34
cf1a5dc0 c003c191
[1.640436] 5f20: c003f809
cf1a5dc0
[1.649001] 5f40: dead4ead
c05c8ef8
[1.657565] 5f60: c0455c08 cf1b5f64 cf1b5f64
dead4ead
[1.666130] 5f80: c05c8ef8 c0455c08 cf1b5f90
cf1b5f90 cf069e20 c003f791
[1.674694] 5fa0: c000d1e1 aaa3aaab
b1ba aae3ea32 aba2a3aa
[1.683260] 5fc0: baaababe bbbaaaba aa2b bb2e2aba aabaa2bb
aaabb2bb aaabbaf3 f3bb2aaa
[1.691824] 5fe0: aabaabba 23ae2beb a2afab2a b2a2ab2a 0013
aaabaaab bfaf a0a2
[1.700399] [c025a3ee] (omap_hsmmc_card_detect+0x6/0x18) from
[c0259fed] (omap_hsmmc_get_cd+0x1d/0x24)
[1.710528] [c0259fed] (omap_hsmmc_get_cd+0x1d/0x24) from
[c024f959] (mmc_rescan+0x131/0x1e4)
[1.719842] [c024f959] (mmc_rescan+0x131/0x1e4) from [c003a42f]
(process_one_work+0x137/0x37c)
[1.729234] [c003a42f] (process_one_work+0x137/0x37c) from
[c003c2ab] (worker_thread+0x11b/0x364)
[1.738899] [c003c2ab] (worker_thread+0x11b/0x364) from
[c003f809] (kthread+0x79/0x84)
[1.747572] [c003f809] (kthread+0x79/0x84) from [c000d1e1]
(ret_from_kernel_thread+0xd/0x14)
[1.756773] Code: bf00 b508 f8d0 3084 (6c18) f75f
[1.761943] ---[ end trace b94c447c4835422d ]---
--
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 1/4] MMC: omap_hsmmc: set platform data after probe from DT node
On 12.10.2012 16:56, Balaji T K wrote:
On Friday 12 October 2012 07:59 PM, Daniel Mack wrote:
On 12.10.2012 12:58, Daniel Mack wrote:
When probed from DT, the self-allocated platform data has to be attached
to the actual device. Otherwise a NULL pointer will be dereferenced from
omap_hsmmc_card_detect if a gpio handle for card-detect has been passed.
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Venkatraman S svenk...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: linux-o...@vger.kernel.org
---
drivers/mmc/host/omap_hsmmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 19ccb59..4b70823 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1728,6 +1728,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
const u16 *offsetp = match-data;
pdata-reg_offset = *offsetp;
}
+ pdev-dev.platform_data = pdata;
}
if (pdata == NULL) {
FWIW, this is the Oops I see without this patch:
Hi,
Shouldn't pdev-dev.platform_data be set to NULL on _remove ?
Why?
BTW, I posted a patch for the same by accessing saved version from
host-pdata
http://permalink.gmane.org/gmane.linux.kernel.mmc/16996
Ok, that's another solution. I thought about this too, but then chose
the easier way :) I don't care which patch is taken, as long as we have
a fix in mainline.
Thanks,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] MMC: omap_hsmmc: set platform data after probe from DT node
On Friday 12 October 2012 08:44 PM, Daniel Mack wrote:
On 12.10.2012 16:56, Balaji T K wrote:
On Friday 12 October 2012 07:59 PM, Daniel Mack wrote:
On 12.10.2012 12:58, Daniel Mack wrote:
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 19ccb59..4b70823 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1728,6 +1728,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
const u16 *offsetp = match-data;
pdata-reg_offset = *offsetp;
}
+ pdev-dev.platform_data = pdata;
}
if (pdata == NULL) {
FWIW, this is the Oops I see without this patch:
Hi,
Shouldn't pdev-dev.platform_data be set to NULL on _remove ?
Why?
To make sure on second insmod it is NULL, When built as module,
So that of_get_hsmmc_pdata is called to create pdata.
BTW, I posted a patch for the same by accessing saved version from
host-pdata
http://permalink.gmane.org/gmane.linux.kernel.mmc/16996
Ok, that's another solution. I thought about this too, but then chose
the easier way :) I don't care which patch is taken, as long as we have
a fix in mainline.
Agree this patch is easiest :-)
Thanks,
Daniel
--
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/4] MMC: omap_hsmmc: add DT property for max bus frequency
On 10/12/2012 05:58 AM, Daniel Mack wrote:
Maximum bus frequency can be limited by external circuitry like level
shifters etc. Allow passing this value from DT.
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Venkatraman S svenk...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: linux-o...@vger.kernel.org
---
drivers/mmc/host/omap_hsmmc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 86f0759..4650ef7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1676,7 +1676,7 @@ static struct omap_mmc_platform_data
*of_get_hsmmc_pdata(struct device *dev)
{
struct omap_mmc_platform_data *pdata;
struct device_node *np = dev-of_node;
- u32 bus_width;
+ u32 bus_width, max_freq;
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -1703,6 +1703,9 @@ static struct omap_mmc_platform_data
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, ti,needs-special-reset, NULL))
pdata-slots[0].features |= HSMMC_HAS_UPDATED_RESET;
+ if (!of_property_read_u32(np, max-frequency, max_freq))
+ pdata-max_freq = max_freq;
+
Is this property documented?
Rob
return pdata;
}
#else
--
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/4] MMC: omap_hsmmc: add DT property for max bus frequency
On 12.10.2012 17:25, Rob Herring wrote:
On 10/12/2012 05:58 AM, Daniel Mack wrote:
Maximum bus frequency can be limited by external circuitry like level
shifters etc. Allow passing this value from DT.
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Venkatraman S svenk...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: linux-o...@vger.kernel.org
---
drivers/mmc/host/omap_hsmmc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 86f0759..4650ef7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1676,7 +1676,7 @@ static struct omap_mmc_platform_data
*of_get_hsmmc_pdata(struct device *dev)
{
struct omap_mmc_platform_data *pdata;
struct device_node *np = dev-of_node;
-u32 bus_width;
+u32 bus_width, max_freq;
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -1703,6 +1703,9 @@ static struct omap_mmc_platform_data
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, ti,needs-special-reset, NULL))
pdata-slots[0].features |= HSMMC_HAS_UPDATED_RESET;
+if (!of_property_read_u32(np, max-frequency, max_freq))
+pdata-max_freq = max_freq;
+
Is this property documented?
Yes, in the generic part. Forgot to mention that.
Documentation/devicetree/bindings/mmc/mmc.txt
--
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: mmci: Fixup and cleanup code for DMA handling
From: Ulf Hansson ulf.hans...@linaro.org
The cookie is now used to indicate if dma_unmap_sg shall be
done in post_request. At DMA errors, the DMA job is immediately
not only terminated but also unmapped. To indicate that this
has been done the cookie is reset to zero. post_request will
thus only do dma_umap_sg for requests which has a cookie not set
to zero.
Some corresponding duplicated code could then be removed and
moreover some corrections at DMA errors for terminating the same
DMA job twice has also been fixed.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Signed-off-by: Per Forlin per.for...@stericsson.com
---
I realize that this patch is quite extensive to review, but I could not
manage to simplify it further than this. Sorry for that.
Moreover you require the below patch, recently sent to the mmc-list as well,
be able to apply it.
mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant
---
drivers/mmc/host/mmci.c | 167 ---
1 file changed, 85 insertions(+), 82 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index ca6d128..3165808 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -383,10 +383,33 @@ static inline void mmci_dma_release(struct mmci_host
*host)
host-dma_rx_channel = host-dma_tx_channel = NULL;
}
+static void mmci_dma_data_error(struct mmci_host *host)
+{
+ dev_err(mmc_dev(host-mmc), error during DMA transfer!\n);
+ dmaengine_terminate_all(host-dma_current);
+ host-dma_current = NULL;
+ host-dma_desc_current = NULL;
+ host-data-host_cookie = 0;
+}
+
static void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
{
- struct dma_chan *chan = host-dma_current;
+ struct dma_chan *chan;
enum dma_data_direction dir;
+
+ if (data-flags MMC_DATA_READ) {
+ dir = DMA_FROM_DEVICE;
+ chan = host-dma_rx_channel;
+ } else {
+ dir = DMA_TO_DEVICE;
+ chan = host-dma_tx_channel;
+ }
+
+ dma_unmap_sg(chan-device-dev, data-sg, data-sg_len, dir);
+}
+
+static void mmci_dma_finalize(struct mmci_host *host, struct mmc_data *data)
+{
u32 status;
int i;
@@ -405,19 +428,12 @@ static void mmci_dma_unmap(struct mmci_host *host, struct
mmc_data *data)
* contiguous buffers. On TX, we'll get a FIFO underrun error.
*/
if (status MCI_RXDATAAVLBLMASK) {
- dmaengine_terminate_all(chan);
- if (!data-error)
- data-error = -EIO;
- }
-
- if (data-flags MMC_DATA_WRITE) {
- dir = DMA_TO_DEVICE;
- } else {
- dir = DMA_FROM_DEVICE;
+ data-error = -EIO;
+ mmci_dma_data_error(host);
}
if (!data-host_cookie)
- dma_unmap_sg(chan-device-dev, data-sg, data-sg_len, dir);
+ mmci_dma_unmap(host, data);
/*
* Use of DMA with scatter-gather is impossible.
@@ -427,16 +443,15 @@ static void mmci_dma_unmap(struct mmci_host *host, struct
mmc_data *data)
dev_err(mmc_dev(host-mmc), buggy DMA detected. Taking evasive
action.\n);
mmci_dma_release(host);
}
-}
-static void mmci_dma_data_error(struct mmci_host *host)
-{
- dev_err(mmc_dev(host-mmc), error during DMA transfer!\n);
- dmaengine_terminate_all(host-dma_current);
+ host-dma_current = NULL;
+ host-dma_desc_current = NULL;
}
-static int mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
- struct mmci_host_next *next)
+/* prepares DMA channel and DMA descriptor, returns non-zero on failure */
+static int __mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
+ struct dma_chan **dma_chan,
+ struct dma_async_tx_descriptor **dma_desc)
{
struct variant_data *variant = host-variant;
struct dma_slave_config conf = {
@@ -454,16 +469,6 @@ static int mmci_dma_prep_data(struct mmci_host *host,
struct mmc_data *data,
enum dma_data_direction buffer_dirn;
int nr_sg;
- /* Check if next job is already prepared */
- if (data-host_cookie !next
- host-dma_current host-dma_desc_current)
- return 0;
-
- if (!next) {
- host-dma_current = NULL;
- host-dma_desc_current = NULL;
- }
-
if (data-flags MMC_DATA_READ) {
conf.direction = DMA_DEV_TO_MEM;
buffer_dirn = DMA_FROM_DEVICE;
@@ -497,30 +502,42 @@ static int mmci_dma_prep_data(struct mmci_host *host,
struct mmc_data *data,
if (!desc)
goto unmap_exit;
- if (next) {
- next-dma_chan = chan;
- next-dma_desc = desc;
- } else {
- host-dma_current = chan;
Re: [PATCH] mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant
On Fri, Oct 12, 2012 at 4:02 PM, Ulf Hansson ulf.hans...@stericsson.com wrote: From: Ulf Hansson ulf.hans...@linaro.org For the ux500v2 variant non power of two block sizes are supported. This will make it possible to decrease data overhead for SDIO transfers. Although we need to put some constraints to the alignment of the buffers when enabling this feature. Buffers must be 4 bytes aligned due to restrictions that the PL18x FIFO accesses must be done in a 4 byte aligned manner. Moreover we need to enable DMA_REQCTL for SDIO to support write of non 32 bytes aligned sg element lengths. In PIO mode any buffer length can be handled as long as the buffer address is 4 byte aligned. Signed-off-by: Ulf Hansson ulf.hans...@linaro.org Signed-off-by: Per Forlin per.for...@stericsson.com Reviewed-by: Linus Walleij linus.wall...@linaro.org I finally understand how this works now. Bonus for comments like this: +/* + * DMA request control is required for write + * if transfer size is not 32 byte aligned. + * DMA request control is also needed if the total + * transfer size is 32 byte aligned but any of the + * sg element lengths are not aligned with 32 byte. + */ #define MCI_ST_DPSM_DMAREQCTL (1 12) Which make you understand what is actually happening. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: mmci: Fixup and cleanup code for DMA handling
On Fri, Oct 12, 2012 at 5:33 PM, Ulf Hansson ulf.hans...@stericsson.com wrote: From: Ulf Hansson ulf.hans...@linaro.org The cookie is now used to indicate if dma_unmap_sg shall be done in post_request. At DMA errors, the DMA job is immediately not only terminated but also unmapped. To indicate that this has been done the cookie is reset to zero. post_request will thus only do dma_umap_sg for requests which has a cookie not set to zero. Some corresponding duplicated code could then be removed and moreover some corrections at DMA errors for terminating the same DMA job twice has also been fixed. Signed-off-by: Ulf Hansson ulf.hans...@linaro.org Signed-off-by: Per Forlin per.for...@stericsson.com It looks like it's both factoring out code and also adding some unmapping in hithereto unhandled cases, correct? It looks OK to me now atleast so Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] MMC: omap_hsmmc: set platform data after probe from DT node
Balaji T K balaj...@ti.com wrote:
On Friday 12 October 2012 08:44 PM, Daniel Mack wrote:
On 12.10.2012 16:56, Balaji T K wrote:
On Friday 12 October 2012 07:59 PM, Daniel Mack wrote:
On 12.10.2012 12:58, Daniel Mack wrote:
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index 19ccb59..4b70823 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1728,6 +1728,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
const u16 *offsetp = match-data;
pdata-reg_offset = *offsetp;
}
+ pdev-dev.platform_data = pdata;
}
if (pdata == NULL) {
FWIW, this is the Oops I see without this patch:
Hi,
Shouldn't pdev-dev.platform_data be set to NULL on _remove ?
Why?
To make sure on second insmod it is NULL, When built as module,
So that of_get_hsmmc_pdata is called to create pdata.
Actually the driver should *never* modify the value of dev-platform_data.
Ever. Make a copy instead.
g.
--
Grant Likely, P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] sdhci: put regulator if probe fails
When using the dummy regulator, SDHCI may fail its probing because the
regulator does not support any voltages.
When reloading the driver, you will get a warning about a duplicate
sysfs link.
[72211.963386] :03:00.0 supply vmmc not found, using dummy regulator
[72211.963409] [ cut here ]
[72211.963420] WARNING: at fs/sysfs/dir.c:536 sysfs_add_one+0x99/0xad()
[72211.963424] Hardware name:
[72211.963429] sysfs: cannot create duplicate filename
'/devices/platform/reg-dummy/regulator/regulator.0/:03:00.0-vmmc'
Avoid this by properly cleaning up when the probe fails calling
regulator_put. Other fail paths get fixed as well.
Signed-off-by: Thadeu Lima de Souza Cascardo casca...@holoscopio.com
---
drivers/mmc/host/sdhci.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7922adb..dd6bc26 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2992,7 +2992,8 @@ int sdhci_add_host(struct sdhci_host *host)
if (mmc-ocr_avail == 0) {
pr_err(%s: Hardware doesn't report any
support voltages.\n, mmc_hostname(mmc));
- return -ENODEV;
+ ret = -ENODEV;
+ goto out_vmmc;
}
spin_lock_init(host-lock);
@@ -3121,6 +3122,9 @@ reset:
untasklet:
tasklet_kill(host-card_tasklet);
tasklet_kill(host-finish_tasklet);
+out_vmmc:
+ if (host-vmmc)
+ regulator_put(host-vmmc);
return ret;
}
--
1.7.10
--
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
