From: Shawn Lin <shawn.lin@rock-chips.com>
To: Jaehoon Chung <jh80.chung@samsung.com>,
Guodong Xu <guodong.xu@linaro.org>
Cc: shawn.lin@rock-chips.com, robh+dt@kernel.org,
"Paweł Moll" <pawel.moll@arm.com>,
"Mark Rutland" <mark.rutland@arm.com>,
ijc+devicetree@hellion.org.uk,
"Kumar Gala" <galak@codeaurora.org>,
"Ulf Hansson" <ulf.hansson@linaro.org>,
devicetree@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-mmc@vger.kernel.org,
"Xinwei Kong" <kong.kongxinwei@hisilicon.com>,
"Zhangfei Gao" <zhangfei.gao@linaro.org>
Subject: Re: [PATCH 2/2] mmc: dw_mmc: add resets support to dw_mmc
Date: Tue, 29 Mar 2016 14:09:32 +0800 [thread overview]
Message-ID: <56FA1C1C.4090008@rock-chips.com> (raw)
In-Reply-To: <56FA192A.9030209@samsung.com>
在 2016/3/29 13:56, Jaehoon Chung 写道:
> On 03/29/2016 11:22 AM, Shawn Lin wrote:
>> 在 2016/3/25 13:35, Guodong Xu 写道:
>>> Hi, Shawn
>>>
>>> Sorry I replied late. I added comments below.
>>>
>>> On 6 March 2016 at 22:16, Shawn Lin <shawn.lin@rock-chips.com
>>> <mailto:shawn.lin@rock-chips.com>> wrote:
>>>
>>> On 2016/3/6 16:47, Guodong Xu wrote:
>>>
>>> mmc registers may in abnormal state if mmc is used in bootloader,
>>> eg. to support booting from eMMC. So we need reset mmc registers
>>> when kernel boots up, instead of assuming mmc is in clean state.
>>>
>>> With this patch, user can add a 'resets' property into dw_mmc dts
>>> node. When driver parse_dt and probe, it calls reset API to
>>> deassert the 'reset' of dw_mmc host controller. When probe error or
>>> remove, it calls reset API to assert it.
>>>
>>> Please also refer to
>>> Documentation/devicetree/bindings/reset/reset.txt
>>>
>>> Signed-off-by: Guodong Xu <guodong.xu@linaro.org
>>> <mailto:guodong.xu@linaro.org>>
>>> Signed-off-by: Xinwei Kong <kong.kongxinwei@hisilicon.com
>>> <mailto:kong.kongxinwei@hisilicon.com>>
>>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org
>>> <mailto:zhangfei.gao@linaro.org>>
>>>
>>>
>>> Really should V2 and add the changelog.
>>>
>>>
>>> Yes, will do. next version I sent will be labelled as V3.
>>>
>>>
>>>
>>> ---
>>> drivers/mmc/host/dw_mmc.c | 22 +++++++++++++++++++++-
>>> 1 file changed, 21 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index 242f9a0..281ea9c 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -2878,6 +2878,14 @@ static struct dw_mci_board
>>> *dw_mci_parse_dt(struct dw_mci *host)
>>> if (!pdata)
>>> return ERR_PTR(-ENOMEM);
>>>
>>> + /* find reset controller when exist */
>>> + pdata->rstc = devm_reset_control_get_optional(dev, NULL);
>>> + if (IS_ERR(pdata->rstc)) {
>>> + if (PTR_ERR(pdata->rstc) == -EPROBE_DEFER)
>>> + return ERR_PTR(-EPROBE_DEFER);
>>> + pdata->rstc = NULL;
>>>
>>>
>>> maybe we can remove "pdata->rstc = NULL", and directly
>>> use IS_ERR(..) for the following "if (host->pdata->rstc != NULL)"
>>> statement
>>>
>>>
>>> Yes, will do.
>>> I see your point, other lines in this file are using IS_ERR(!..), I will
>>> use this style too.
>>>
>>> + }
>>> +
>>> /* find out number of slots supported */
>>> of_property_read_u32(np, "num-slots", &pdata->num_slots);
>>>
>>> @@ -2949,7 +2957,9 @@ int dw_mci_probe(struct dw_mci *host)
>>>
>>> if (!host->pdata) {
>>> host->pdata = dw_mci_parse_dt(host);
>>> - if (IS_ERR(host->pdata)) {
>>> + if (PTR_ERR(host->pdata) == -EPROBE_DEFER)
>>> + return -EPROBE_DEFER;
>>>
>>>
>>> please fix the coding style here.
>>>
>>>
>>> Do you mean to add additional {} for this 'if' , like this?
>>>
>>> + if (PTR_ERR(host->pdata) == -EPROBE_DEFER) {
>>> + return -EPROBE_DEFER;
>>>
>>> + }
>>>
>>> I will add {}.
>>>
>>>
>>>
>>> + else if (IS_ERR(host->pdata)) {
>>> dev_err(host->dev, "platform data not
>>> available\n");
>>> return -EINVAL;
>>> }
>>> @@ -3012,6 +3022,9 @@ int dw_mci_probe(struct dw_mci *host)
>>> }
>>> }
>>>
>>> + if (host->pdata->rstc != NULL)
>>> + reset_control_deassert(host->pdata->rstc);
>>> +
>>>
>>>
>>> sorry, I can't follow your intention here. Shouldn't it be something
>>> like "assert mmc -> may need delay -> deassert mmc". As your current
>>> code, nothing happend right?
>>>
>>>
>>> The chip exits from bootloader with this bit asserted. And when entering
>>> kernel, we only need to deassert.
>>>
>>> In my current code, the driver deassert mmc in _probe(), and assert mmc
>>> in _remove().
>>
>> I catch your point. From the previous discussion, we add it to make sure
>> dw_mmc in good state after leaving bootloader to kernel. But My real question is that you can assert it in bootloader, so you can also
>> dessert it in bootloaer to make sure dw_mmc work fine when probing
>> in kernel. In that way, we don't need this patch?
>
> Doesn't dw_mci_hw_reset work fine? I think that card should be reset with MMC_CAP_HW_RESET.
> Could you check this?
>
MMC_CAP_HW_RESET actually reset the mmc card, but Guodong means to
reset the controller rather than mmc card :)
> Best Regards,
> Jaehoon Chung
>
>>
>> More to think, Is it ok to match the behaviour of bootloader stage?
>> My bootloader doesn't assert the reset pin of dw_mmc, so it seams if
>> I want to fix you issue on kernel stage, I need a new round of
>> assert->delay->deassert.
>>
>>
>>>
>>>
>>>
>>> setup_timer(&host->cmd11_timer,
>>> dw_mci_cmd11_timer, (unsigned long)host);
>>>
>>> @@ -3164,6 +3177,9 @@ err_dmaunmap:
>>> if (host->use_dma && host->dma_ops->exit)
>>> host->dma_ops->exit(host);
>>>
>>> + if (host->pdata->rstc != NULL)
>>> + reset_control_assert(host->pdata->rstc);
>>> +
>>> err_clk_ciu:
>>> if (!IS_ERR(host->ciu_clk))
>>> clk_disable_unprepare(host->ciu_clk);
>>> @@ -3196,11 +3212,15 @@ void dw_mci_remove(struct dw_mci *host)
>>> if (host->use_dma && host->dma_ops->exit)
>>> host->dma_ops->exit(host);
>>>
>>> + if (host->pdata->rstc != NULL)
>>> + reset_control_assert(host->pdata->rstc);
>>> +
>>> if (!IS_ERR(host->ciu_clk))
>>> clk_disable_unprepare(host->ciu_clk);
>>>
>>> if (!IS_ERR(host->biu_clk))
>>> clk_disable_unprepare(host->biu_clk);
>>> +
>>> }
>>>
>>>
>>> unnecessary new line here.
>>>
>>>
>>> Will fix.
>>>
>>> -Guodong
>>>
>>>
>>> EXPORT_SYMBOL(dw_mci_remove);
>>>
>>>
>>>
>>>
>>> --
>>> Best Regards
>>> Shawn Lin
>>>
>>>
>>
>>
>>
>
>
>
>
--
Best Regards
Shawn Lin
next prev parent reply other threads:[~2016-03-29 6:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-06 8:47 [PATCH 1/2] Documentation: synopsys-dw-mshc: add binding for resets Guodong Xu
2016-03-06 8:47 ` [PATCH 2/2] mmc: dw_mmc: add resets support to dw_mmc Guodong Xu
2016-03-06 9:11 ` kbuild test robot
2016-03-06 14:16 ` Shawn Lin
[not found] ` <CAFGCpxz3GfFeduaz1Dkg0WvRJWs+GHdVu8uY0-wV=RGyRfBE=A@mail.gmail.com>
[not found] ` <56F9E6E5.9000100@kernel-upstream.org>
2016-03-29 5:56 ` Jaehoon Chung
2016-03-29 6:09 ` Shawn Lin [this message]
2016-03-29 6:15 ` Jaehoon Chung
2016-03-29 8:23 ` zhangfei
2016-03-29 8:30 ` Jaehoon Chung
2016-03-30 0:46 ` Shawn Lin
2016-03-30 1:18 ` zhangfei
2016-03-07 0:53 ` [PATCH 1/2] Documentation: synopsys-dw-mshc: add binding for resets Jaehoon Chung
2016-03-07 9:35 ` Shawn Lin
2016-03-07 9:51 ` Jaehoon Chung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56FA1C1C.4090008@rock-chips.com \
--to=shawn.lin@rock-chips.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=guodong.xu@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jh80.chung@samsung.com \
--cc=kong.kongxinwei@hisilicon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=zhangfei.gao@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox