Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756222AbcC2Iaa (ORCPT ); Tue, 29 Mar 2016 04:30:30 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:51561 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751358AbcC2IaU (ORCPT ); Tue, 29 Mar 2016 04:30:20 -0400 X-AuditID: cbfee68d-f79e86d0000012da-25-56fa3d18fdbe Message-id: <56FA3D18.9070600@samsung.com> Date: Tue, 29 Mar 2016 17:30:16 +0900 From: Jaehoon Chung User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-version: 1.0 To: zhangfei , Shawn Lin , Guodong Xu , Shawn Lin Cc: robh+dt@kernel.org, =?UTF-8?B?UGF3ZcWCIE1vbGw=?= , Mark Rutland , ijc+devicetree@hellion.org.uk, Kumar Gala , Ulf Hansson , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , linux-mmc@vger.kernel.org, Xinwei Kong Subject: Re: [PATCH 2/2] mmc: dw_mmc: add resets support to dw_mmc References: <1457254062-22677-1-git-send-email-guodong.xu@linaro.org> <1457254062-22677-2-git-send-email-guodong.xu@linaro.org> <56DC3BAD.8020107@rock-chips.com> <56F9E6E5.9000100@kernel-upstream.org> <56FA3B70.2090902@linaro.org> In-reply-to: <56FA3B70.2090902@linaro.org> Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFIsWRmVeSWpSXmKPExsWyRsSkQFfC9leYwcbpQhbzj5xjteh/s5DV 4v+dHlaLc69WMlr8+LuP1eLyrjlsFkf+9zNaLL1+kcliwvS1LBate4+wW9zbfIzJ4s6T9awW x9eGW9xcc4Hdgc9jzbw1jB6X+3qZPFYu/8Lm8XjuRnaPF/NfM3tsWtXJ5nHn2h42j7+z9rN4 fN4kF8AZxWWTkpqTWZZapG+XwJVxb815loLlEhUT7l5lbWBsF+pi5OSQEDCRuPHiAjOELSZx 4d56ti5GLg4hgRWMEv3bXjLBFLWtaGGGSMxilDi4dRkrhPOAUaJ571lWkCpeAS2Jd8t6gKo4 OFgEVCVW/PIHCbMJ6Ehs/3YcbJCoQJjEg3V7ocoFJX5MvscCMkdEYD6jxL3nL8E2MAs0M0us m/2GBaRKWMBJYtP084wQ2zYzSZyd9xhsFCfQtk3Pd7GAbGMWUJeYMiUXJMwsIC+xec1bsEES Ais5JC6vvgy2jkVAQOLb5ENg9RICshKbDkD9LClxcMUNlgmMYrOQHDULYeosJFMXMDKvYhRN LUguKE5KLzLUK07MLS7NS9dLzs/dxAiM8tP/nvXuYLx9wPoQowAHoxIPL8OCn2FCrIllxZW5 hxhNgY6YyCwlmpwPTCV5JfGGxmZGFqYmpsZG5pZmSuK8ilI/g4UE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUwOgkt+dJpXjt7yqSC8Gn3/X9oGymlf1jqc/bIrXuu/zrmnF+8iL9yk/Jtnss/ 9z2KjnASPqZ9WWzbpzhW41NS3XyXLlqufeUqLHZ+h7aSzzMpscgdm7Vzpu4/6cvbvLz7Ylu5 p3p0+xcz7g43md53cY7H+atnFnB88/y4PL1xptC/LE22BPEjSizFGYmGWsxFxYkAPGdHMe0C AAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsVy+t9jQV0J219hBkdauS3mHznHatH/ZiGr xf87PawW516tZLT48Xcfq8XlXXPYLI7872e0WHr9IpPFhOlrWSxa9x5ht7i3+RiTxZ0n61kt jq8Nt7i55gK7A5/HmnlrGD0u9/Uyeaxc/oXN4/HcjeweL+a/ZvbYtKqTzePOtT1sHn9n7Wfx +LxJLoAzqoHRJiM1MSW1SCE1Lzk/JTMv3VbJOzjeOd7UzMBQ19DSwlxJIS8xN9VWycUnQNct MwfoeiWFssScUqBQQGJxsZK+HaYJoSFuuhYwjRG6viFBcD1GBmggYQ1jxr0151kKlktUTLh7 lbWBsV2oi5GTQ0LARKJtRQszhC0mceHeerYuRi4OIYFZjBIHty5jhXAeMEo07z3LClLFK6Al 8W5ZD1AHBweLgKrEil/+IGE2AR2J7d+OM4HYogJhEg/W7YUqF5T4MfkeC8gcEYH5jBL3nr9k BnGYBZqZJdbNfsMCUiUs4CSxafp5Rohtm5kkzs57DDaKE2jbpue7WEC2MQuoS0yZkgsSZhaQ l9i85i3zBEagOxGWzEKomoWkagEj8ypGidSC5ILipPRco7zUcr3ixNzi0rx0veT83E2M4ETy THoH4+Fd7ocYBTgYlXh4GRb8DBNiTSwrrsw9xCjBwawkwttg8StMiDclsbIqtSg/vqg0J7X4 EKMpMBAmMkuJJucDk1xeSbyhsYmZkaWRuaGFkbG5kjjv4//rwoQE0hNLUrNTUwtSi2D6mDg4 pRoYnT5dYfS5IjvV3i3t35Mk5ausLzrueU9Tz3LY6xL7yY617usrq+UyYs0Hm3h/OZb/Tlik smLyyqjUN7q3BFfWdpjObL4526IjWFgtPTLVYkLL9j3HJJNmnp/15Zvvzuv7/O9cKHG7579a X976v8fB1+++8W1c4dPDcVLLZN5iYenjc3Q4p+o6K7EUZyQaajEXFScCAKI0VGs6AwAA DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3025 Lines: 84 On 03/29/2016 05:23 PM, zhangfei wrote: > > > On 03/29/2016 10:22 AM, Shawn Lin wrote: > >>> >>> >>> >>> + 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? > Should be abstracted in reset driver. > >>> >>> >>> 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? > > uefi does not have exit point, and kernel may not assume mmc controller state is always correct when boot. > If Uefi need copy Image from mmc, mmc controller is in working state. > When jump to kernel, uefi mmc driver can not recover itself. > If kernel assume mmc controller state is clean, mmc will be in abnormal state. > Some controller will clear itself when set clock, however, hip660 does not, it need special register to access. > > >> >> 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. > > The process like delay (if required) should be abstracted in reset driver. > reset framework just export reset_control_assert/reset_control_deassert API. > Unfortunately not find clear description in Documentation/. > Suppose deassert is like start, while assert is like stop. First, this patch need to resend after fixing. Could you or Guodong resend these patches as V2 or V3? Best Regards, Jaehoon Chung > > drivers/reset/core.c > reset_control_deassert - deasserts the reset line > reset_control_assert - asserts the reset line > > More example: > drivers/mmc/host/sdhci-st.c > drivers/mmc/host/sunxi-mmc.c > drivers/usb/host/ohci-platform.c > drivers/i2c/busses/i2c-mv64xxx.c > > Thanks > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > >