date:20111225

Re: [PATCH] mmc: sdhci-s3c: Remove old and misprototyped suspend operations

2011-12-25 Thread Tushar Behera


Hi Jaehoon,

On 12/26/2011 10:53 AM, Jaehoon Chung wrote:

Hi Tushar.

Did you test with linux-3.2-rc6?
I checked the linux-3.2-rc6..that version may be missed the dev_pm_ops patch..
(Manuel's patch [PATCH v4] mmc: sdhci: remove "state" argument from 
sdhci_suspend_host)

I didn't understand this condition.

That patch is include in linux-3.2-rc7.



Thanks for the information. I ran the tests with linux-3.2-rc7 and 
everything seems great.



To Chris.
If adopt "sdhci-s3c: remove Old and misprototyped suspend operation"
I think that Manuel's patch must be include in liux-3.2-rc6

Thanks,
Jaehoon Chung



--
Tushar Behera
--
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: sdhci-s3c: Remove old and misprototyped suspend operations

2011-12-25 Thread Jaehoon Chung

Hi Tushar.

Did you test with linux-3.2-rc6?
I checked the linux-3.2-rc6..that version may be missed the dev_pm_ops patch..
(Manuel's patch [PATCH v4] mmc: sdhci: remove "state" argument from 
sdhci_suspend_host)

I didn't understand this condition.

That patch is include in linux-3.2-rc7.

To Chris.
If adopt "sdhci-s3c: remove Old and misprototyped suspend operation"
I think that Manuel's patch must be include in liux-3.2-rc6 

Thanks,
Jaehoon Chung

On 12/26/2011 02:05 PM, Tushar Behera wrote:

> Hi Jaehoon,
> 
> On 12/26/2011 07:24 AM, Jaehoon Chung wrote:
>> Hi Tushar.
>>
>> I also tested this patch with Samsung-SoC.
>> But i didn't find the below message
>> "mmc0: Timeout waiting for hardware interrupt."
>>
> When the primary filesystem is on SD/MMC card, I need to select following 
> config options for the system to go to sleep. Is it in anyway the reason of 
> conflict?
> 
> CONFIG_MMC_UNSAFE_RESUME=y
> 
> I modified my test-case to use a ramdisk instead and use a script to 
> mount/unmount the filesystem on MMC card. In that case also I get the above 
> error for some time - around 30s. After that, it behaves normally 
> (mounting/unmounting etc.)
> 
> $ echo mem > /sys/power/state
> [   18.825000] PM: Syncing filesystems ... done.
> [   18.83] Freezing user space processes ... (elapsed 0.00 seconds) done.
> [   18.835000] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) 
> done.
> [   18.855000] Suspending console(s) (use no_console_suspend to debug)
> [   18.865000] wake enabled for irq 292
> [   18.865000] wake enabled for irq 301
> [   18.865000] wake enabled for irq 302
> [   18.865000] wake enabled for irq 303
> [   18.865000] wake enabled for irq 304
> [   18.865000] wake enabled for irq 305
> [   18.89] PM: suspend of devices complete after 26.491 msecs
> [   18.89] PM: late suspend of devices complete after 0.829 msecs
> [   18.89] Disabling non-boot CPUs ...
> [   18.895000] IRQ80 no longer affine to CPU1
> [   18.895000] CPU1: shutdown
> [   18.895000] Enabling non-boot CPUs ...
> [   18.905000] CPU1: Booted secondary processor
> [   18.905000] Calibrating delay loop (skipped) already calibrated this CPU
> [   18.905000] CPU1: Unknown IPI message 0x1
> [   18.905000] CPU1 is up
> [   18.905000] PM: early resume of devices complete after 0.745 msecs
> [   18.91] s3c-i2c s3c2440-i2c.0: slave address 0x10
> [   18.91] s3c-i2c s3c2440-i2c.0: bus frequency set to 97 KHz
> [   18.91] usb usb1: root hub lost power or was reset
> [   18.935000] wake disabled for irq 301
> [   18.935000] wake disabled for irq 302
> [   18.935000] wake disabled for irq 303
> [   18.935000] wake disabled for irq 304
> [   18.935000] wake disabled for irq 305
> [   18.935000] wake disabled for irq 292
> [   19.07] PM: resume of devices complete after 160.084 msecs
> [   19.18] Restarting tasks ... done.
> / $ [   29.20] mmc0: Timeout waiting for hardware interrupt.
> [   39.22] mmc0: Timeout waiting for hardware interrupt.
> [   49.24] mmc0: Timeout waiting for hardware interrupt.
> [   59.26] mmc0: Timeout waiting for hardware interrupt.
> [   59.26] mmc0: card e624 removed
> [   59.33] mmc0: new SDHC card at address e624
> [   59.335000] mmcblk0: mmc0:e624 SD04G 3.69 GiB
> [   59.34]  mmcblk0: p1
> 
>> I didn't understand what is that differ with previously code?
>> (just using dev_pm_ops..)
>>
> 
> I could not find any dev_pm_ops related implementation in sdhci-s3c.c. Are 
> there some other patches that I am missing on v3.2-rc6? Or any specific 
> config settings that I need for this to be working?
> 
>> Thanks,
>> Jaehoon Chung
>>
>> On 12/25/2011 11:29 AM, Chris Ball wrote:
>>
>>> Hi,
>>>
>>> On Mon, Dec 19 2011, Tushar Behera wrote:
>>> Now that the driver is using dev_pm_ops the suspend operations in the
>>> platform_driver structure won't get called so don't need to be there,
>>> and certainly shouldn't be the same function as dev_pm_ops since the
>>> signatures are different.
>>>
>>> Signed-off-by: Mark Brown  opensource.wolfsonmicro.com>

 On Origen board (based on EXYNOS4210), the primary filesystem is on a
 SD/MMC card. When tested with v3.2-rc6 kernel, the system doesn't resume
 properly.

 After resume, it keeps printing following message and the filesystem never
 comes up.

 mmc0: Timeout waiting for hardware interrupt.

 If this patch is reverted, the system is able to mount the filesystem
 successfully.

 Am I missing something?
>>>
>>> Mark/Jaehoon?  This looks very bad.
>>
>>>
>>> - Chris.
>>
>>
> 
> 


--
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: sdhci-s3c: Remove old and misprototyped suspend operations

2011-12-25 Thread Tushar Behera


Hi Jaehoon,

On 12/26/2011 07:24 AM, Jaehoon Chung wrote:

Hi Tushar.

I also tested this patch with Samsung-SoC.
But i didn't find the below message
"mmc0: Timeout waiting for hardware interrupt."

When the primary filesystem is on SD/MMC card, I need to select 
following config options for the system to go to sleep. Is it in anyway 
the reason of conflict?


CONFIG_MMC_UNSAFE_RESUME=y

I modified my test-case to use a ramdisk instead and use a script to 
mount/unmount the filesystem on MMC card. In that case also I get the 
above error for some time - around 30s. After that, it behaves normally 
(mounting/unmounting etc.)


$ echo mem > /sys/power/state
[   18.825000] PM: Syncing filesystems ... done.
[   18.83] Freezing user space processes ... (elapsed 0.00 seconds) 
done.
[   18.835000] Freezing remaining freezable tasks ... (elapsed 0.01 
seconds) done.

[   18.855000] Suspending console(s) (use no_console_suspend to debug)
[   18.865000] wake enabled for irq 292
[   18.865000] wake enabled for irq 301
[   18.865000] wake enabled for irq 302
[   18.865000] wake enabled for irq 303
[   18.865000] wake enabled for irq 304
[   18.865000] wake enabled for irq 305
[   18.89] PM: suspend of devices complete after 26.491 msecs
[   18.89] PM: late suspend of devices complete after 0.829 msecs
[   18.89] Disabling non-boot CPUs ...
[   18.895000] IRQ80 no longer affine to CPU1
[   18.895000] CPU1: shutdown
[   18.895000] Enabling non-boot CPUs ...
[   18.905000] CPU1: Booted secondary processor
[   18.905000] Calibrating delay loop (skipped) already calibrated this CPU
[   18.905000] CPU1: Unknown IPI message 0x1
[   18.905000] CPU1 is up
[   18.905000] PM: early resume of devices complete after 0.745 msecs
[   18.91] s3c-i2c s3c2440-i2c.0: slave address 0x10
[   18.91] s3c-i2c s3c2440-i2c.0: bus frequency set to 97 KHz
[   18.91] usb usb1: root hub lost power or was reset
[   18.935000] wake disabled for irq 301
[   18.935000] wake disabled for irq 302
[   18.935000] wake disabled for irq 303
[   18.935000] wake disabled for irq 304
[   18.935000] wake disabled for irq 305
[   18.935000] wake disabled for irq 292
[   19.07] PM: resume of devices complete after 160.084 msecs
[   19.18] Restarting tasks ... done.
/ $ [   29.20] mmc0: Timeout waiting for hardware interrupt.
[   39.22] mmc0: Timeout waiting for hardware interrupt.
[   49.24] mmc0: Timeout waiting for hardware interrupt.
[   59.26] mmc0: Timeout waiting for hardware interrupt.
[   59.26] mmc0: card e624 removed
[   59.33] mmc0: new SDHC card at address e624
[   59.335000] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[   59.34]  mmcblk0: p1


I didn't understand what is that differ with previously code?
(just using dev_pm_ops..)



I could not find any dev_pm_ops related implementation in sdhci-s3c.c. 
Are there some other patches that I am missing on v3.2-rc6? Or any 
specific config settings that I need for this to be working?



Thanks,
Jaehoon Chung

On 12/25/2011 11:29 AM, Chris Ball wrote:


Hi,

On Mon, Dec 19 2011, Tushar Behera wrote:

Now that the driver is using dev_pm_ops the suspend operations in the
platform_driver structure won't get called so don't need to be there,
and certainly shouldn't be the same function as dev_pm_ops since the
signatures are different.

Signed-off-by: Mark Brown  opensource.wolfsonmicro.com>


On Origen board (based on EXYNOS4210), the primary filesystem is on a
SD/MMC card. When tested with v3.2-rc6 kernel, the system doesn't resume
properly.

After resume, it keeps printing following message and the filesystem never
comes up.

mmc0: Timeout waiting for hardware interrupt.

If this patch is reverted, the system is able to mount the filesystem
successfully.

Am I missing something?


Mark/Jaehoon?  This looks very bad.




- Chris.






--
Tushar Behera
--
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 1/2] SD/MMC: add an interface to re-initialize bounce buffer

2011-12-25 Thread Liu Qiang-B32616

Hi Chris,

Happy holidays!
How about this patch? And "[PATCH V2 2/2] mmc/doc: feature description of
runtime bounce buffer size adjustment"? I add the description in 
Documents/mmc/mmc-dev-attrs.txt
according to your suggestion.

Thanks for your reply.



-Original Message-
From: Liu Qiang-B32616 
Sent: Wednesday, December 21, 2011 3:10 PM
To: c...@laptop.org; linux-mmc@vger.kernel.org
Cc: Li Yang-R58472; Liu Qiang-B32616; Liu Qiang-B32616
Subject: [PATCH V2 1/2] SD/MMC: add an interface to re-initialize bounce buffer

Add bounce_size under /sys/block/mmcblk0/bouncesz.
Support dynamic adjustment of bounce buffer in run-time (include mounted or 
unmounted filesystem).

/sys/block/mmcblk0/bouncesz should be integer multiple of 512, the value should 
be range from 4096 to 4194304.

1. use variable instead of MMC_QUEUE_BOUNCESZ; 2. Re-initialize bounce buffer 
accorinding to new bounce size at run-time;

Signed-off-by: Qiang Liu 
---
changes for V2
merge former 2 patches to 1

Here is the test results with different mmc bounce size, IOzone is used to test 
performance of mass data transmission.
Environment:
PowerPC P1022DS platform, Sandisk Class 10, 4G memory card, EXT4 filesystem
[root@p2020ds root]# cat /sys/fs/   block/mmcblk0/bouncesz
65536
[root@p2020ds root]# mount /dev/mmcblk0p1 /mnt/ EXT4-fs (mmcblk0p1): mounted 
filesystem without journal. Opts:
[root@p2020ds root]# iozone -Rab result -i0 -i1 -r64 =-  -n1g -g4g -f /mnt/ff 

  KB  reclen   write rewritereadreread
 1048576  64   14229   13286   662028   663372
 2097152  64   13758   126054954947443
 4194304  64   13435   122152197422096

[root@p2020ds root]# echo 262144 > /sys/block/mmcblk0/bouncesz [root@p2020ds 
root]# cat /sys/block/mmcblk0/bouncesz
262144
[root@p2020ds root]# iozone -Rab result -i0 -i1 -r64 -n1g -g4g -f /mnt/ff 

  KB  reclen   write rewritereadreread
 1048576  64   19228   19416   676659   677785
 2097152  64   18512   184992697827055
 4194304  64   17932   181852194521805

[root@p2020ds root]# echo 8192 > /sys/block/mmcblk0/bouncesz [root@p2020ds 
root]# cat /sys/block/mmcblk0/bouncesz
8192
[root@p2020ds root]# iozone -Rab result -i0 -i1 -r64 -n1g -g1g -f /mnt/ff
  KB  reclen   write rewritereadreread
 1048576  6450683324   640266   641609
---
 drivers/mmc/card/block.c |   43 +++
 drivers/mmc/card/queue.c |  102 +-
 drivers/mmc/card/queue.h |6 +++
 3 files changed, 149 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index 
0c959c9..790abe2 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -59,6 +59,9 @@ MODULE_ALIAS("mmc:block");  #define INAND_CMD38_ARG_SECTRIM1 
0x81  #define INAND_CMD38_ARG_SECTRIM2 0x88

+#define MMC_MIN_QUEUE_BOUNCESZ 4096
+#define MMC_MAX_QUEUE_BOUNCESZ 4194304
+
 static DEFINE_MUTEX(block_mutex);

 /*
@@ -108,6 +111,7 @@ struct mmc_blk_data {
unsigned intpart_curr;
struct device_attribute force_ro;
struct device_attribute power_ro_lock;
+   struct device_attribute bouncesz;
int area_type;
 };

@@ -1633,6 +1637,7 @@ static void mmc_blk_remove_req(struct mmc_blk_data *md)
del_gendisk(md->disk);
}

+   device_remove_file(disk_to_dev(md->disk), &md->bouncesz);
/* Then flush out any already in there */
mmc_cleanup_queue(&md->queue);
mmc_blk_put(md);
@@ -1739,6 +1744,33 @@ static const struct mmc_fixup blk_fixups[] =
END_FIXUP
 };

+#ifdef CONFIG_MMC_BLOCK_BOUNCE
+static ssize_t mmc_bouncesz_show(struct device *dev,
+   struct device_attribute *attr, char *buf) {
+return sprintf(buf, "%u\n", mmc_queue_bouncesz); }
+
+static ssize_t mmc_bouncesz_store(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   unsigned int bouncesz;
+   struct mmc_blk_data *md;
+
+   if ((sscanf(buf, "%d", &bouncesz) != 1) ||
+   (bouncesz < MMC_MIN_QUEUE_BOUNCESZ) ||
+   (bouncesz > MMC_MAX_QUEUE_BOUNCESZ) ||
+   (bouncesz % 512 != 0))
+   return -EINVAL;
+
+   md = mmc_blk_get(dev_to_disk(dev));
+   mmc_reinit_bounce_queue(&md->queue, md->queue.card, bouncesz);
+   mmc_blk_put(md);
+   return mmc_queue_bouncesz;
+}
+#endif
+
 static int mmc_blk_probe(struct mmc_card *card)  {
struct mmc_blk_data *md, *part_md;
@@ -1771,6 +1803,17 @@ static int mmc_blk_probe(struct mmc_card *card)
mmc_set_drvdata(card, md);
mmc_fixup_device(card, blk_fixups);

+

Re: [PATCH] mmc: sdhci-s3c: Remove old and misprototyped suspend operations

2011-12-25 Thread Jaehoon Chung

Hi Tushar.

I also tested this patch with Samsung-SoC.
But i didn't find the below message 
"mmc0: Timeout waiting for hardware interrupt."

I didn't understand what is that differ with previously code?
(just using dev_pm_ops..)

Thanks,
Jaehoon Chung

On 12/25/2011 11:29 AM, Chris Ball wrote:

> Hi,
> 
> On Mon, Dec 19 2011, Tushar Behera wrote:
> Now that the driver is using dev_pm_ops the suspend operations in the
> platform_driver structure won't get called so don't need to be there,
> and certainly shouldn't be the same function as dev_pm_ops since the
> signatures are different.
>
> Signed-off-by: Mark Brown  opensource.wolfsonmicro.com>
>>
>> On Origen board (based on EXYNOS4210), the primary filesystem is on a
>> SD/MMC card. When tested with v3.2-rc6 kernel, the system doesn't resume
>> properly.
>>
>> After resume, it keeps printing following message and the filesystem never
>> comes up.
>>
>> mmc0: Timeout waiting for hardware interrupt.
>>
>> If this patch is reverted, the system is able to mount the filesystem 
>> successfully.
>>
>> Am I missing something?
> 
> Mark/Jaehoon?  This looks very bad.

> 
> - Chris.


--
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 v3] mmc: sh_mmcif: process requests asynchronously

2011-12-25 Thread Chris Ball

Hi,

On Sun, Dec 25 2011, Guennadi Liakhovetski wrote:
> Hmmm, that's very weird - I rebased my patch series on top of your 
> mmc-next from a couple of hours ago. Sorry for asking, but you've also 
> applied the leading two patches from this series, right? This is what my 
> log of this driver looks like now:

Oops, that's it, thanks.

Now I have:

13cb975 (HEAD, mmc-next) mmc: sh_mmcif: cosmetic clean up
9e66e1c mmc: sh_mmcif: process error interrupts first
9092a17 mmc: convert drivers/mmc/host/* to use module_platform_driver()
2736566 mmc: sh_mmcif: simplify clock divisor calculation
58f1934 mmc: sh_mmcif: fix clock gating on platforms with a .down_pwr() method
88b4767 mmc: Add module.h to drivers/mmc users assuming implicit presence.
714c4a6 mmc: sh_mmcif: simplify platform data
c9b0cef mmc: sh_mmcif: maximize power saving

But 4/4 ("mmc: sh_mmcif: remove now superfluous sh_mmcif_host::data
member") isn't applying without fuzz (offset 13 lines).  Any ideas/want
to resend it?

Thanks,

- Chris.
-- 
Chris Ball  
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: [PATCH 3/4 v3] mmc: sh_mmcif: process requests asynchronously

2011-12-25 Thread Guennadi Liakhovetski

Hi Chris

On Sun, 25 Dec 2011, Chris Ball wrote:

> Hi Guennadi,
> 
> On Sun, Dec 25 2011, Guennadi Liakhovetski wrote:
> >> This patch (3/4) no longer applies to mmc-next -- mind resending?
> >
> > This one should be ok.
> 
> Seems to be worse, for some reason:
> 
> patching file drivers/mmc/host/sh_mmcif.c
> Hunk #2 succeeded at 189 (offset -5 lines).
> Hunk #3 FAILED at 217.
> Hunk #4 succeeded at 503 (offset -4 lines).
> Hunk #5 FAILED at 780.
> Hunk #6 FAILED at 802.
> Hunk #7 FAILED at 835.
> Hunk #8 succeeded at 908 (offset 6 lines).
> Hunk #9 FAILED at 942.
> Hunk #10 succeeded at 1044 with fuzz 2 (offset 11 lines).
> Hunk #11 succeeded at 1246 (offset 11 lines).
> Hunk #12 succeeded at 1351 (offset 11 lines).
> Hunk #13 FAILED at 1376.
> Hunk #14 succeeded at 1425 (offset 11 lines).
> 6 out of 14 hunks FAILED -- saving rejects to file 
> drivers/mmc/host/sh_mmcif.c.rej

Hmmm, that's very weird - I rebased my patch series on top of your 
mmc-next from a couple of hours ago. Sorry for asking, but you've also 
applied the leading two patches from this series, right? This is what my 
log of this driver looks like now:

6bf5ca1 mmc: sh_mmcif: remove now superfluous sh_mmcif_host::data member
8777cc4 mmc: sh_mmcif: process requests asynchronously
0295d69 mmc: sh_mmcif: cosmetic clean up
74dfec8 mmc: sh_mmcif: process error interrupts first
9092a17 mmc: convert drivers/mmc/host/* to use module_platform_driver()

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/2 v2] mmc: add a generic GPIO card-detect helper

2011-12-25 Thread Chris Ball

Hi,

On Sun, Dec 25 2011, Guennadi Liakhovetski wrote:
> This patch adds a primitive helper to support card hotplug detection on
> platforms, where a GPIO, capable of producing interrupts, is used for
> detection of card-insertion and -removal events.
>
> Signed-off-by: Guennadi Liakhovetski 
> ---
>
> v2: switch to use snprintf()

Thanks, pushed to mmc-next for 3.3.  I agree the change was only
necessarily to make life easier for humans.  :-)

- Chris.
-- 
Chris Ball  
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: [PATCH 3/4 v3] mmc: sh_mmcif: process requests asynchronously

2011-12-25 Thread Chris Ball

Hi Guennadi,

On Sun, Dec 25 2011, Guennadi Liakhovetski wrote:
>> This patch (3/4) no longer applies to mmc-next -- mind resending?
>
> This one should be ok.

Seems to be worse, for some reason:

patching file drivers/mmc/host/sh_mmcif.c
Hunk #2 succeeded at 189 (offset -5 lines).
Hunk #3 FAILED at 217.
Hunk #4 succeeded at 503 (offset -4 lines).
Hunk #5 FAILED at 780.
Hunk #6 FAILED at 802.
Hunk #7 FAILED at 835.
Hunk #8 succeeded at 908 (offset 6 lines).
Hunk #9 FAILED at 942.
Hunk #10 succeeded at 1044 with fuzz 2 (offset 11 lines).
Hunk #11 succeeded at 1246 (offset 11 lines).
Hunk #12 succeeded at 1351 (offset 11 lines).
Hunk #13 FAILED at 1376.
Hunk #14 succeeded at 1425 (offset 11 lines).
6 out of 14 hunks FAILED -- saving rejects to file 
drivers/mmc/host/sh_mmcif.c.rej

- Chris.
-- 
Chris Ball  
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 2/2 v2] mmc: add a generic GPIO card-detect helper

2011-12-25 Thread Guennadi Liakhovetski

This patch adds a primitive helper to support card hotplug detection on
platforms, where a GPIO, capable of producing interrupts, is used for
detection of card-insertion and -removal events.

Signed-off-by: Guennadi Liakhovetski 
---

v2: switch to use snprintf()

Hi Chris

On Sat, 24 Dec 2011, Chris Ball wrote:

> > +int mmc_cd_gpio_request(struct mmc_host *host, unsigned int gpio,
> > +   unsigned int irq, unsigned long flags)
> > +{
> > +   size_t len = strlen(dev_name(host->parent)) + 4;
> > +   struct mmc_cd_gpio *cd = kmalloc(sizeof(*cd) + len, GFP_KERNEL);
> > +   int ret;
> > +
> > +   if (!cd)
> > +   return -ENOMEM;
> > +
> > +   sprintf(cd->label, "%s cd", dev_name(host->parent));
> 
> Mind using snprintf() instead?  I prefer it for new uses, it leaves
> fewer uses of sprintf to audit for correctness.

I don't think it's needed here - I allocate exactly the required number of 
bytes, but, as you mention, it should help us, humans, feel more secure 
about it:-)

 drivers/mmc/core/Makefile   |2 +-
 drivers/mmc/core/cd-gpio.c  |   74 +++
 include/linux/mmc/cd-gpio.h |   19 +++
 3 files changed, 94 insertions(+), 1 deletions(-)
 create mode 100644 drivers/mmc/core/cd-gpio.c
 create mode 100644 include/linux/mmc/cd-gpio.h

diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index 6395019..dca4428 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -7,6 +7,6 @@ mmc_core-y  := core.o bus.o host.o \
   mmc.o mmc_ops.o sd.o sd_ops.o \
   sdio.o sdio_ops.o sdio_bus.o \
   sdio_cis.o sdio_io.o sdio_irq.o \
-  quirks.o
+  quirks.o cd-gpio.o
 
 mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
diff --git a/drivers/mmc/core/cd-gpio.c b/drivers/mmc/core/cd-gpio.c
new file mode 100644
index 000..4c79f0c
--- /dev/null
+++ b/drivers/mmc/core/cd-gpio.c
@@ -0,0 +1,74 @@
+/*
+ * Generic GPIO card-detect helper
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct mmc_cd_gpio {
+   unsigned int gpio;
+   char label[0];
+};
+
+static irqreturn_t mmc_cd_gpio_irqt(int irq, void *dev_id)
+{
+   /* Schedule a card detection after a debounce timeout */
+   mmc_detect_change(dev_id, msecs_to_jiffies(100));
+   return IRQ_HANDLED;
+}
+
+int mmc_cd_gpio_request(struct mmc_host *host, unsigned int gpio,
+   unsigned int irq, unsigned long flags)
+{
+   size_t len = strlen(dev_name(host->parent)) + 4;
+   struct mmc_cd_gpio *cd = kmalloc(sizeof(*cd) + len, GFP_KERNEL);
+   int ret;
+
+   if (!cd)
+   return -ENOMEM;
+
+   snprintf(cd->label, len, "%s cd", dev_name(host->parent));
+
+   ret = gpio_request_one(gpio, GPIOF_DIR_IN, cd->label);
+   if (ret < 0)
+   goto egpioreq;
+
+   ret = request_threaded_irq(irq, NULL, mmc_cd_gpio_irqt,
+  flags, cd->label, host);
+   if (ret < 0)
+   goto eirqreq;
+
+   cd->gpio = gpio;
+   host->hotplug.irq = irq;
+   host->hotplug.handler_priv = cd;
+
+   return 0;
+
+eirqreq:
+   gpio_free(gpio);
+egpioreq:
+   kfree(cd);
+   return ret;
+}
+EXPORT_SYMBOL(mmc_cd_gpio_request);
+
+void mmc_cd_gpio_free(struct mmc_host *host)
+{
+   struct mmc_cd_gpio *cd = host->hotplug.handler_priv;
+
+   free_irq(host->hotplug.irq, host);
+   gpio_free(cd->gpio);
+   kfree(cd);
+}
+EXPORT_SYMBOL(mmc_cd_gpio_free);
diff --git a/include/linux/mmc/cd-gpio.h b/include/linux/mmc/cd-gpio.h
new file mode 100644
index 000..a8e4697
--- /dev/null
+++ b/include/linux/mmc/cd-gpio.h
@@ -0,0 +1,19 @@
+/*
+ * Generic GPIO card-detect helper header
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef MMC_CD_GPIO_H
+#define MMC_CD_GPIO_H
+
+struct mmc_host;
+int mmc_cd_gpio_request(struct mmc_host *host, unsigned int gpio,
+   unsigned int irq, unsigned long flags);
+void mmc_cd_gpio_free(struct mmc_host *host);
+
+#endif
-- 
1.7.2.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 3/4 v3] mmc: sh_mmcif: process requests asynchronously

2011-12-25 Thread Guennadi Liakhovetski

This patch converts the sh_mmcif MMC host driver to process requests
asynchronously instead of waiting in its .request() method for completion.
This is achieved by using threaded IRQs.

Signed-off-by: Guennadi Liakhovetski 
---

v3: updated on top of current mmc-next

Hi Chris

On Sat, 24 Dec 2011, Chris Ball wrote:

> Hi Guennadi,
> 
> On Wed, Dec 14 2011, Guennadi Liakhovetski wrote:
> > This patch converts the sh_mmcif MMC host driver to process requests
> > asynchronously instead of waiting in its .request() method for completion.
> > This is achieved by using threaded IRQs.
> >
> > Signed-off-by: Guennadi Liakhovetski 
> 
> This patch (3/4) no longer applies to mmc-next -- mind resending?

This one should be ok.

 drivers/mmc/host/sh_mmcif.c |  588 ++-
 1 files changed, 416 insertions(+), 172 deletions(-)

diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 6da03c5..df76ac1 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -16,6 +16,32 @@
  *
  */
 
+/*
+ * The MMCIF driver is now processing MMC requests asynchronously, according
+ * to the Linux MMC API requirement.
+ *
+ * The MMCIF driver processes MMC requests in up to 3 stages: command, optional
+ * data, and optional stop. To achieve asynchronous processing each of these
+ * stages is split into two halves: a top and a bottom half. The top half
+ * initialises the hardware, installs a timeout handler to handle completion
+ * timeouts, and returns. In case of the command stage this immediately returns
+ * control to the caller, leaving all further processing to run asynchronously.
+ * All further request processing is performed by the bottom halves.
+ *
+ * The bottom half further consists of a "hard" IRQ handler, an IRQ handler
+ * thread, a DMA completion callback, if DMA is used, a timeout work, and
+ * request- and stage-specific handler methods.
+ *
+ * Each bottom half run begins with either a hardware interrupt, a DMA callback
+ * invocation, or a timeout work run. In case of an error or a successful
+ * processing completion, the MMC core is informed and the request processing 
is
+ * finished. In case processing has to continue, i.e., if data has to be read
+ * from or written to the card, or if a stop command has to be sent, the next
+ * top half is called, which performs the necessary hardware handling and
+ * reschedules the timeout work. This returns the driver state machine into the
+ * bottom half waiting state.
+ */
+
 #include 
 #include 
 #include 
@@ -168,9 +194,22 @@ enum mmcif_state {
STATE_IOS,
 };
 
+enum mmcif_wait_for {
+   MMCIF_WAIT_FOR_REQUEST,
+   MMCIF_WAIT_FOR_CMD,
+   MMCIF_WAIT_FOR_MREAD,
+   MMCIF_WAIT_FOR_MWRITE,
+   MMCIF_WAIT_FOR_READ,
+   MMCIF_WAIT_FOR_WRITE,
+   MMCIF_WAIT_FOR_READ_END,
+   MMCIF_WAIT_FOR_WRITE_END,
+   MMCIF_WAIT_FOR_STOP,
+};
+
 struct sh_mmcif_host {
struct mmc_host *mmc;
struct mmc_data *data;
+   struct mmc_request *mrq;
struct platform_device *pd;
struct sh_dmae_slave dma_slave_tx;
struct sh_dmae_slave dma_slave_rx;
@@ -178,11 +217,17 @@ struct sh_mmcif_host {
unsigned int clk;
int bus_width;
bool sd_error;
+   bool dying;
long timeout;
void __iomem *addr;
-   struct completion intr_wait;
+   u32 *pio_ptr;
spinlock_t lock;/* protect sh_mmcif_host::state */
enum mmcif_state state;
+   enum mmcif_wait_for wait_for;
+   struct delayed_work timeout_work;
+   size_t blocksize;
+   int sg_idx;
+   int sg_blkidx;
bool power;
bool card_present;
 
@@ -468,125 +513,183 @@ static int sh_mmcif_error_manage(struct sh_mmcif_host 
*host)
return ret;
 }
 
-static int sh_mmcif_single_read(struct sh_mmcif_host *host,
-   struct mmc_request *mrq)
+static bool sh_mmcif_next_block(struct sh_mmcif_host *host, u32 *p)
 {
-   struct mmc_data *data = mrq->data;
-   long time;
-   u32 blocksize, i, *p = sg_virt(data->sg);
+   struct mmc_data *data = host->mrq->data;
+
+   host->sg_blkidx += host->blocksize;
+
+   /* data->sg->length must be a multiple of host->blocksize? */
+   BUG_ON(host->sg_blkidx > data->sg->length);
+
+   if (host->sg_blkidx == data->sg->length) {
+   host->sg_blkidx = 0;
+   if (++host->sg_idx < data->sg_len)
+   host->pio_ptr = sg_virt(++data->sg);
+   } else {
+   host->pio_ptr = p;
+   }
+
+   if (host->sg_idx == data->sg_len)
+   return false;
+
+   return true;
+}
+
+static void sh_mmcif_single_read(struct sh_mmcif_host *host,
+struct mmc_request *mrq)
+{
+   host->blocksize = (sh_mmcif_readl(host->addr, MMCIF_CE_BLOCK_SET) &
+  BLOCK_SIZE_MASK) + 3;
+
+   host->wait_

Re: [PATCH] mmc: sdhci-s3c: Remove old and misprototyped suspend operations

Re: [PATCH] mmc: sdhci-s3c: Remove old and misprototyped suspend operations

Re: [PATCH] mmc: sdhci-s3c: Remove old and misprototyped suspend operations

RE: [PATCH V2 1/2] SD/MMC: add an interface to re-initialize bounce buffer

Re: [PATCH] mmc: sdhci-s3c: Remove old and misprototyped suspend operations

Re: [PATCH 3/4 v3] mmc: sh_mmcif: process requests asynchronously

Re: [PATCH 3/4 v3] mmc: sh_mmcif: process requests asynchronously

Re: [PATCH 2/2 v2] mmc: add a generic GPIO card-detect helper

Re: [PATCH 3/4 v3] mmc: sh_mmcif: process requests asynchronously

[PATCH 2/2 v2] mmc: add a generic GPIO card-detect helper

[PATCH 3/4 v3] mmc: sh_mmcif: process requests asynchronously

11 matches

Site Navigation

Mail list logo

Footer information