Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1431832 > unrolled thread
| Started by | Ulf Hansson <ulf.hansson@linaro.org> |
|---|---|
| First post | 2016-06-27 11:10 +0200 |
| Last post | 2016-06-27 13:50 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH] mmc: core: add auto bkops support Ulf Hansson <ulf.hansson@linaro.org> - 2016-06-27 11:10 +0200
Re: [PATCH] mmc: core: add auto bkops support Alex Lemberg <Alex.Lemberg@sandisk.com> - 2016-06-27 13:50 +0200
| From | Ulf Hansson <ulf.hansson@linaro.org> |
|---|---|
| Date | 2016-06-27 11:10 +0200 |
| Subject | Re: [PATCH] mmc: core: add auto bkops support |
| Message-ID | <rOAIi-6Df-7@gated-at.bofh.it> |
[...] >>> If I am not wrong, in current implementation of runtime suspend, >>> the driver stops BKOPS (send HPI) just before sending sleep command, >>> see _mmc_suspend(), depends on “MMC_CAP_AGGRESSIVE_PM” flag. >>> In this case, the eMMC device will not have enough time to perform internal >>> BKOPS in both – Manual and Auto BKOPS configurations. >>> >> >> ye, so it seems a pre-exiting issue before introducing auto bkops? >> I think we can push another patch to improve it but not handling >> it for this $SUBJECT, does it sound ok to you? > > Runtime suspend for eMMC has a default auto-suspend delay of 3 seconds > (refer mmc_blk_probe()). Isn't that when auto bkops would happen? That's correct. So perhaps we should extend the default auto-suspend delay? The SD case actually have the same issue, as I some background operations exists there as well. [...] Kind regards Uffe
[toc] | [next] | [standalone]
| From | Alex Lemberg <Alex.Lemberg@sandisk.com> |
|---|---|
| Date | 2016-06-27 13:50 +0200 |
| Message-ID | <rODd7-86Z-5@gated-at.bofh.it> |
| In reply to | #1431832 |
Hi Ulf and Adrian, On 6/27/16, 12:08 PM, "Ulf Hansson" <ulf.hansson@linaro.org> wrote: >[...] > >>>> If I am not wrong, in current implementation of runtime suspend, >>>> the driver stops BKOPS (send HPI) just before sending sleep command, >>>> see _mmc_suspend(), depends on “MMC_CAP_AGGRESSIVE_PM” flag. >>>> In this case, the eMMC device will not have enough time to perform internal >>>> BKOPS in both – Manual and Auto BKOPS configurations. >>>> >>> >>> ye, so it seems a pre-exiting issue before introducing auto bkops? >>> I think we can push another patch to improve it but not handling >>> it for this $SUBJECT, does it sound ok to you? >> >> Runtime suspend for eMMC has a default auto-suspend delay of 3 seconds >> (refer mmc_blk_probe()). Isn't that when auto bkops would happen? > >That's correct. > >So perhaps we should extend the default auto-suspend delay? Due to the differences in flash management and technologies, I suggest to make this value configurable, and not hard coded. I believe it should be configured per vendor BKOPS needs. The default value still can be set to 3 seconds, as done today… > >The SD case actually have the same issue, as I some background >operations exists there as well. > >[...] > >Kind regards >Uffe
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web