From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752619AbbC3Azi (ORCPT ); Sun, 29 Mar 2015 20:55:38 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:61320 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751936AbbC3Azf (ORCPT ); Sun, 29 Mar 2015 20:55:35 -0400 X-AuditID: cbfee691-f79b86d000004a5a-82-55189f05f03a Message-id: <55189F04.8000404@samsung.com> Date: Mon, 30 Mar 2015 09:55:32 +0900 From: Jaehoon Chung User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-version: 1.0 To: Jaehoon Chung , Doug Anderson Cc: Seungwon Jeon , Ulf Hansson , Alim Akhtar , Sonny Rao , Andrew Bresticker , Heiko Stuebner , Addy Ke , Alexandru Stan , Javier Martinez Canillas , "open list:ARM/Rockchip SoC..." , "linux-arm-kernel@lists.infradead.org" , Chris Ball , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors References: <1426002490-2014-1-git-send-email-dianders@chromium.org> <5502CA4E.9060401@samsung.com> <5506707D.40708@samsung.com> In-reply-to: <5506707D.40708@samsung.com> Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsWyRsSkSJd1vkSowck/yhYr3/9ltFj2/zuT xYN529gsGl5MYrWYcHk7o8XZZQfZLP4/es1qcfR3gcWNX22sFpseX2O1uLxrDpvFkf/9jBaf HvxntnhyZiajxYf7F5ktjq8NdxDwmN1wkcXj7/PrLB53ru1h89i8pN7jxquFTB5/Z+1n8ejb sorRY/u1ecwenzfJBXBGcdmkpOZklqUW6dslcGU82XqYseCVTMXVF9vZGhg/iHUxcnJICJhI 3Ng0iR3CFpO4cG89G4gtJLCUUWLnEmmYmrvTZjNDxBcxSrw+V97FyAVkP2CU+Hr0GStIgldA S6J131KwZhYBVYmegw0sIDabgI7E9m/HmUBsUYEwiYk3H0PVC0r8mHwPrEZEIFjiZetxNpCh zALLWSWaDhwFSwgLhEq0/Ohgg9h2mlFi76SbYBs4BTQluu+fATqbA6hDXWLKlFyQMLOAvMTm NW+ZQeolBFZySLz90c8IcZGAxLfJh1hA6iUEZCU2HWCG+ExS4uCKGywTGMVmIblpFsLUWUim LmBkXsUomlqQXFCclF5kqlecmFtcmpeul5yfu4kRGPGn/z2buIPx/gHrQ4wCHIxKPLyO9RKh QqyJZcWVuYcYTYGOmMgsJZqcD0wreSXxhsZmRhamJqbGRuaWZkrivDrSP4OFBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MPbunr3hf17vnNXe2R/t2K+lTymIYZbv4Up6pLXrQEz1vVml6iv5 vjHM1Ml1WLDP+1PrxNKF3+1375orZxh16b6RzK/DZcw8OS/vXHl75GIRJ8/VY5mX52n2nV7C /En+oc++50ZbtofPMqnYorek6OSOJ/6txQybt9vdkL7Ou3HGO4cWRXv71ulKLMUZiYZazEXF iQBZKc0W8wIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsVy+t9jAV3W+RKhBitXSVmsfP+X0WLZ/+9M Fg/mbWOzaHgxidViwuXtjBZnlx1ks/j/6DWrxdHfBRY3frWxWmx6fI3V4vKuOWwWR/73M1p8 evCf2eLJmZmMFh/uX2S2OL423EHAY3bDRRaPv8+vs3jcubaHzWPzknqPG68WMnn8nbWfxaNv yypGj+3X5jF7fN4kF8AZ1cBok5GamJJapJCal5yfkpmXbqvkHRzvHG9qZmCoa2hpYa6kkJeY m2qr5OIToOuWmQP0hZJCWWJOKVAoILG4WEnfDtOE0BA3XQuYxghd35AguB4jAzSQsIYx48nW w4wFr2Qqrr7YztbA+EGsi5GTQ0LAROLutNnMELaYxIV769lAbCGBRYwSr8+VdzFyAdkPGCW+ Hn3GCpLgFdCSaN23FKyIRUBVoudgAwuIzSagI7H923EmEFtUIExi4s3HUPWCEj8m3wOrEREI lnjZepwNZCizwHJWiaYDR8ESwgKhEi0/Otggtp1mlNg76SbYBk4BTYnu+2fYuxg5gDrUJaZM yQUJMwvIS2xe85Z5AqPALCQ7ZiFUzUJStYCReRWjaGpBckFxUnquoV5xYm5xaV66XnJ+7iZG cEJ5JrWDcWWDxSFGAQ5GJR5ex3qJUCHWxLLiytxDjBIczEoivLdLgEK8KYmVValF+fFFpTmp xYcYTYEhMJFZSjQ5H5js8kriDY1NzIwsjcwNLYyMzZXEeZXs20KEBNITS1KzU1MLUotg+pg4 OKUaGCtXrOm3f8x2rOH16vTwCzJLw24zuh+686twGve/9YuufdXa02SbbsdmWCq/aEWW6CKX f9sqV+VvfVQ/V+yWXVLJau73n3cbLr6wmsXhhFpH4aIdljq2n88ZlAa2qd+WXyr/N/JzM7d8 d5JJbKztBeOoshL2VSU/EyWcDUzCVnctCrgpbR6tr8RSnJFoqMVcVJwIAH14pCo+AwAA 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 Dear Doug, I'm considering to control HLE error..So holding this patch. If this is absolutely necessary patch, let me know, plz. Best Regards, Jaehoon Chung On 03/16/2015 02:56 PM, Jaehoon Chung wrote: > Hi, Doug. > > On 03/14/2015 05:27 AM, Doug Anderson wrote: >> Hi, >> >> On Fri, Mar 13, 2015 at 4:30 AM, Jaehoon Chung wrote: >>> Hi, Doug. >>> >>> On 03/11/2015 12:48 AM, Doug Anderson wrote: >>>> The dw_mmc driver enables HLE errors as part of DW_MCI_ERROR_FLAGS but >>>> nothing in the interrupt handler actually handles them and ACKs them. >>>> That means that if we ever get an HLE error we'll just keep getting >>>> interrupts and we'll wedge things. >>>> >>>> We really don't expect HLE errors but if we ever get them we shouldn't >>>> silently ignore them. >>>> >>>> Note that I have seen HLE errors while constantly ejecting and >>>> inserting cards (ejecting while inserting, etc). >>> >>> Right, It is occurred when card inserting/ejecting.(This case is the case of removable card.) >>> Did you test with eMMC? We needs to consider how control HLE error. >> >> I'm running it on systems with eMMC, SD Cards, and SDIO WiFi. HLE >> doesn't show up in normal circumstances, only in ejecting the SD card >> at the wrong time. ...since you can't eject eMMC, I didn't see >> problems there. > > When card is inserting/removing, HLE is often occurred. > Since there is some request into queue when card is removed.(in my understanding.) > It's also related with controlling clock. > >> >>> But I think this patch can't solve all of HLE problem. >> >> Agreed. HLE means that the controller is pretty wedged and (as I >> understand it) means that there's something else we're doing wrong >> elsewhere in the dw_mmc driver (like writing more data to an already >> busy controller). We should probably track down and find those cases, >> too. >> >> I agree also that this code probably won't fix the controller in all >> cases of HLE errors. ...but I'm not 100% certain of the best way to >> really do that, do you know? >> >> ...but in any case the absolute worst thing to do is what the driver >> is already doing: unmask the HLE interrupt but never handle it >> anywhere... My patch is at least better than that... > > Agreed, your patch should be at least better than now. > But if pending is set HLE error bit, > it should hit the cases of DW_MCI_DATA_ERROR_FLAGS & DW_MCI_CMD_ERROR_FLAGS. > and i think send_stop_abort() can't run, doesn't? > (If HLE is occurred at non-removable card, controller can't do anything.) > > If i can reproduce HLE error, i can check more detailedly.(Trying to reproduce it.) > I don't find fully solution yet. But finding the solution is my or our(?) part/role in future. > Actually, i'm using the ctrl reset at my local tree, when HLE error is occurred. > (Also it's not solution..) > According to TRM, "HLE is raised, software then has to reload the command." > We needs to consider how reload the command without lost previous request. > >> >> If you have another suggested way to make HLE error handling better >> (or avoid them to begin with) I'm happy to test! :) > > I will try to find HLE error handling..if you also have other opinion, let me know, plz. > I needs to listen other opinion, it's great helpful to me.. :) > > Thank you a lot! > > Best Regards, > Jaehoon Chung > >> >> >> -Doug >> > > -- > 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 >