| Message ID | 20200204085449.32585-1-ulf.hansson@linaro.org |
|---|---|
| Headers | show |
| Series | mmc: core: Improve code for polling and HW busy detect | expand |
Hi Ulf, On Tue, Feb 4, 2020 at 4:55 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > There exists several separate variants of polling loops, used to detect when > the card stop signals busy for various operations, in the mmc core. All of them > have different issues that needs to be fixed. > > The intent with this series, is to address some of these problems, via first > improving the mmc_poll_for_busy() function, then consolidate code by moving > more users to it. > > While I was working on this, I stumbled over some code here and there, that > deserved some cleanup, hence I also folded in a couple of patches for this. > > So far, I have only managed to extensively test the updated mmc_poll_for_busy() > function for CMD6 commands. Some tests for erase/trim/discard and for > HPI+sanitize are needed. > > Note that, there are still separate polling loops in the mmc block layer, but > moving that to mmc_poll_for_busy() involves some additional work. I am looking > into that as a next step. > > Please help review and test! That will be help if you can supply one git branch to fetch these patches :), and I will help to do some testing on my platform. > Ulf Hansson (12): > mmc: core: Throttle polling rate for CMD6 > mmc: core: Drop unused define > mmc: core: Extend mmc_switch_status() to rid of __mmc_switch_status() > mmc: core: Drop redundant in-parameter to __mmc_switch() > mmc: core: Split up mmc_poll_for_busy() > mmc: core: Enable re-use of mmc_blk_in_tran_state() > mmc: core: Update CMD13 busy check for CMD6 commands > mmc: core: Convert to mmc_poll_for_busy() for erase/trim/discard > mmc: core: Drop redundant out-parameter to mmc_send_hpi_cmd() > mmc: core: Convert to mmc_poll_for_busy() for HPI commands > mmc: core: Fixup support for HW busy detection for HPI commands > mmc: core: Re-work the error path for the eMMC sanitize command > > drivers/mmc/core/block.c | 55 +++++-------- > drivers/mmc/core/core.c | 53 +------------ > drivers/mmc/core/mmc.c | 38 ++++----- > drivers/mmc/core/mmc_ops.c | 159 ++++++++++++++++++++++--------------- > drivers/mmc/core/mmc_ops.h | 13 ++- > include/linux/mmc/core.h | 3 - > include/linux/mmc/mmc.h | 10 +++ > 7 files changed, 157 insertions(+), 174 deletions(-) > > -- > 2.17.1 >
On Tue, Feb 11, 2020 at 9:17 PM Baolin Wang <baolin.wang7@gmail.com> wrote: > > Hi Ulf, > > On Tue, Feb 4, 2020 at 4:55 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > There exists several separate variants of polling loops, used to detect when > > the card stop signals busy for various operations, in the mmc core. All of them > > have different issues that needs to be fixed. > > > > The intent with this series, is to address some of these problems, via first > > improving the mmc_poll_for_busy() function, then consolidate code by moving > > more users to it. > > > > While I was working on this, I stumbled over some code here and there, that > > deserved some cleanup, hence I also folded in a couple of patches for this. > > > > So far, I have only managed to extensively test the updated mmc_poll_for_busy() > > function for CMD6 commands. Some tests for erase/trim/discard and for > > HPI+sanitize are needed. > > > > Note that, there are still separate polling loops in the mmc block layer, but > > moving that to mmc_poll_for_busy() involves some additional work. I am looking > > into that as a next step. > > > > Please help review and test! > > That will be help if you can supply one git branch to fetch these > patches :), and I will help to do some testing on my platform. I've tested on my platform, incuding reading, writing, mounting and running all cases in mmc_test.c, and I did not find any problem. So please feel free to add my test tag. Thanks. Tested-by: Baolin Wang <baolin.wang7@gmail.com> > > Ulf Hansson (12): > > mmc: core: Throttle polling rate for CMD6 > > mmc: core: Drop unused define > > mmc: core: Extend mmc_switch_status() to rid of __mmc_switch_status() > > mmc: core: Drop redundant in-parameter to __mmc_switch() > > mmc: core: Split up mmc_poll_for_busy() > > mmc: core: Enable re-use of mmc_blk_in_tran_state() > > mmc: core: Update CMD13 busy check for CMD6 commands > > mmc: core: Convert to mmc_poll_for_busy() for erase/trim/discard > > mmc: core: Drop redundant out-parameter to mmc_send_hpi_cmd() > > mmc: core: Convert to mmc_poll_for_busy() for HPI commands > > mmc: core: Fixup support for HW busy detection for HPI commands > > mmc: core: Re-work the error path for the eMMC sanitize command > > > > drivers/mmc/core/block.c | 55 +++++-------- > > drivers/mmc/core/core.c | 53 +------------ > > drivers/mmc/core/mmc.c | 38 ++++----- > > drivers/mmc/core/mmc_ops.c | 159 ++++++++++++++++++++++--------------- > > drivers/mmc/core/mmc_ops.h | 13 ++- > > include/linux/mmc/core.h | 3 - > > include/linux/mmc/mmc.h | 10 +++ > > 7 files changed, 157 insertions(+), 174 deletions(-) > > > > -- > > 2.17.1 > >
Hi Ulf Le 2/13/20 à 7:23 AM, Baolin Wang a écrit : > On Tue, Feb 11, 2020 at 9:17 PM Baolin Wang <baolin.wang7@gmail.com> wrote: >> >> Hi Ulf, >> >> On Tue, Feb 4, 2020 at 4:55 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: >>> >>> There exists several separate variants of polling loops, used to detect when >>> the card stop signals busy for various operations, in the mmc core. All of them >>> have different issues that needs to be fixed. >>> >>> The intent with this series, is to address some of these problems, via first >>> improving the mmc_poll_for_busy() function, then consolidate code by moving >>> more users to it. >>> >>> While I was working on this, I stumbled over some code here and there, that >>> deserved some cleanup, hence I also folded in a couple of patches for this. >>> >>> So far, I have only managed to extensively test the updated mmc_poll_for_busy() >>> function for CMD6 commands. Some tests for erase/trim/discard and for >>> HPI+sanitize are needed. >>> >>> Note that, there are still separate polling loops in the mmc block layer, but >>> moving that to mmc_poll_for_busy() involves some additional work. I am looking >>> into that as a next step. >>> >>> Please help review and test! >> >> That will be help if you can supply one git branch to fetch these >> patches :), and I will help to do some testing on my platform. > > I've tested on my platform, incuding reading, writing, mounting and > running all cases in mmc_test.c, and I did not find any problem. So > please feel free to add my test tag. Thanks. > Tested on mmci: sdmmc variant with/out MMC_CAP_WAIT_WHILE_BUSY and I see no regression. After series review, I've just a comment on patch 01/12 (code/comment alignment 32-64) Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Ludovic Barre <ludovic.barre@st.com> > Tested-by: Baolin Wang <baolin.wang7@gmail.com> > >>> Ulf Hansson (12): >>> mmc: core: Throttle polling rate for CMD6 >>> mmc: core: Drop unused define >>> mmc: core: Extend mmc_switch_status() to rid of __mmc_switch_status() >>> mmc: core: Drop redundant in-parameter to __mmc_switch() >>> mmc: core: Split up mmc_poll_for_busy() >>> mmc: core: Enable re-use of mmc_blk_in_tran_state() >>> mmc: core: Update CMD13 busy check for CMD6 commands >>> mmc: core: Convert to mmc_poll_for_busy() for erase/trim/discard >>> mmc: core: Drop redundant out-parameter to mmc_send_hpi_cmd() >>> mmc: core: Convert to mmc_poll_for_busy() for HPI commands >>> mmc: core: Fixup support for HW busy detection for HPI commands >>> mmc: core: Re-work the error path for the eMMC sanitize command >>> >>> drivers/mmc/core/block.c | 55 +++++-------- >>> drivers/mmc/core/core.c | 53 +------------ >>> drivers/mmc/core/mmc.c | 38 ++++----- >>> drivers/mmc/core/mmc_ops.c | 159 ++++++++++++++++++++++--------------- >>> drivers/mmc/core/mmc_ops.h | 13 ++- >>> include/linux/mmc/core.h | 3 - >>> include/linux/mmc/mmc.h | 10 +++ >>> 7 files changed, 157 insertions(+), 174 deletions(-) >>> >>> -- >>> 2.17.1 >>>
On Thu, 13 Feb 2020 at 15:42, Ludovic BARRE <ludovic.barre@st.com> wrote: > > Hi Ulf > > Le 2/13/20 à 7:23 AM, Baolin Wang a écrit : > > On Tue, Feb 11, 2020 at 9:17 PM Baolin Wang <baolin.wang7@gmail.com> wrote: > >> > >> Hi Ulf, > >> > >> On Tue, Feb 4, 2020 at 4:55 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > >>> > >>> There exists several separate variants of polling loops, used to detect when > >>> the card stop signals busy for various operations, in the mmc core. All of them > >>> have different issues that needs to be fixed. > >>> > >>> The intent with this series, is to address some of these problems, via first > >>> improving the mmc_poll_for_busy() function, then consolidate code by moving > >>> more users to it. > >>> > >>> While I was working on this, I stumbled over some code here and there, that > >>> deserved some cleanup, hence I also folded in a couple of patches for this. > >>> > >>> So far, I have only managed to extensively test the updated mmc_poll_for_busy() > >>> function for CMD6 commands. Some tests for erase/trim/discard and for > >>> HPI+sanitize are needed. > >>> > >>> Note that, there are still separate polling loops in the mmc block layer, but > >>> moving that to mmc_poll_for_busy() involves some additional work. I am looking > >>> into that as a next step. > >>> > >>> Please help review and test! > >> > >> That will be help if you can supply one git branch to fetch these > >> patches :), and I will help to do some testing on my platform. > > > > I've tested on my platform, incuding reading, writing, mounting and > > running all cases in mmc_test.c, and I did not find any problem. So > > please feel free to add my test tag. Thanks. > > > > Tested on mmci: sdmmc variant with/out MMC_CAP_WAIT_WHILE_BUSY > and I see no regression. > After series review, I've just a comment on patch 01/12 > (code/comment alignment 32-64) > > Tested-by: Ludovic Barre <ludovic.barre@st.com> > Reviewed-by: Ludovic Barre <ludovic.barre@st.com> Thanks a lot, much appreciated! [...] Kind regards Uffe
On Tue, 4 Feb 2020 at 09:55, Ulf Hansson <ulf.hansson@linaro.org> wrote: > > There exists several separate variants of polling loops, used to detect when > the card stop signals busy for various operations, in the mmc core. All of them > have different issues that needs to be fixed. > > The intent with this series, is to address some of these problems, via first > improving the mmc_poll_for_busy() function, then consolidate code by moving > more users to it. > > While I was working on this, I stumbled over some code here and there, that > deserved some cleanup, hence I also folded in a couple of patches for this. > > So far, I have only managed to extensively test the updated mmc_poll_for_busy() > function for CMD6 commands. Some tests for erase/trim/discard and for > HPI+sanitize are needed. > > Note that, there are still separate polling loops in the mmc block layer, but > moving that to mmc_poll_for_busy() involves some additional work. I am looking > into that as a next step. > > Please help review and test! > > Kind regards > Ulf Hansson > > > Ulf Hansson (12): > mmc: core: Throttle polling rate for CMD6 > mmc: core: Drop unused define > mmc: core: Extend mmc_switch_status() to rid of __mmc_switch_status() > mmc: core: Drop redundant in-parameter to __mmc_switch() > mmc: core: Split up mmc_poll_for_busy() > mmc: core: Enable re-use of mmc_blk_in_tran_state() > mmc: core: Update CMD13 busy check for CMD6 commands > mmc: core: Convert to mmc_poll_for_busy() for erase/trim/discard > mmc: core: Drop redundant out-parameter to mmc_send_hpi_cmd() > mmc: core: Convert to mmc_poll_for_busy() for HPI commands > mmc: core: Fixup support for HW busy detection for HPI commands > mmc: core: Re-work the error path for the eMMC sanitize command > > drivers/mmc/core/block.c | 55 +++++-------- > drivers/mmc/core/core.c | 53 +------------ > drivers/mmc/core/mmc.c | 38 ++++----- > drivers/mmc/core/mmc_ops.c | 159 ++++++++++++++++++++++--------------- > drivers/mmc/core/mmc_ops.h | 13 ++- > include/linux/mmc/core.h | 3 - > include/linux/mmc/mmc.h | 10 +++ > 7 files changed, 157 insertions(+), 174 deletions(-) > > -- > 2.17.1 > FYI, I have queued up this series for next (except patch12 that deserves another re-spin). I also amended the changelog for patch1, according the comment from Ludovic. Feel free to provide additional feedback and test-reports, while we monitor how this cook in linux-next. Kind regards Uffe