From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753196AbbDGCA2 (ORCPT ); Mon, 6 Apr 2015 22:00:28 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:35679 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752947AbbDGCAH (ORCPT ); Mon, 6 Apr 2015 22:00:07 -0400 X-AuditID: cbfee68e-f79c56d000006efb-c9-55233a246112 Message-id: <55233A24.1000803@samsung.com> Date: Tue, 07 Apr 2015 11:00:04 +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: Doug Anderson , Jaehoon Chung 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-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 1/3] mmc: dw_mmc: Increase cmd11 timeout to 500ms References: <1428084787-8710-1-git-send-email-dianders@chromium.org> <55226411.2060806@samsung.com> In-reply-to: Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsWyRsSkQFfVSjnUoPEMm8XK938ZLZb9/85k 8WDeNjaLhheTWC3OLjvIZvH/0WtWi6O/Cyxu/Gpjtbi8aw6bxZH//YwWnx78Z7Z4cmYmo8WH +xeZLY6vDXfg85jdcJHF4+/z6ywed67tYfPYvKTe4++s/SwefVtWMXpsvzaP2ePzJrkAjigu m5TUnMyy1CJ9uwSujB1Xv7IWHBaqOLuvia2B8RRfFyMnh4SAiUTzv7vsELaYxIV769lAbCGB pYwS36cVwNQ8XribsYuRCyg+nVFi3YZtzBDOA0aJi98OsYJU8QpoSUx/ewism0VAVWLSho1g NpuAjsT2b8eZQGxRgTCJiTcfQ9ULSvyYfI8FxBYRCJaY3j0VbCizwFYWiec/GsCKhAVcJZ4D gwdi2xpGiW3vdoBN5QTq6Fy7HcjmAOpQl5gyJRckzCwgL7F5zVuwQRICEzkkls67yQhxkYDE t8mHWEDqJQRkJTYdYIZ4TVLi4IobLBMYxWYhuWkWwtRZSKYuYGRexSiaWpBcUJyUXmSkV5yY W1yal66XnJ+7iREY1af/PevbwXjzgPUhRgEORiUeXgY55VAh1sSy4srcQ4ymQEdMZJYSTc4H po68knhDYzMjC1MTU2Mjc0szJXHeBKmfwUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYJflu 3OEyefky4j9zybnXsnpZ8T9uBV1MDk6se+d2d9vaxY52pXsmeEtqV5TP5e3Wlm7Q+Oi7uVn+ wRcGcwFR+4Cf3/c5sx97WvKA9Z1dkcDHyLQavzuXXtf/yFkvlGt0xcWj+bG+odJ306kT72S2 uIt+MvfJ+6/PuqSu1/XbRMdHs30CXdYosRRnJBpqMRcVJwIAqgC0feUCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsVy+t9jQV0VK+VQgxezrSxWvv/LaLHs/3cm iwfztrFZNLyYxGpxdtlBNov/j16zWhz9XWBx41cbq8XlXXPYLI7872e0+PTgP7PFkzMzGS0+ 3L/IbHF8bbgDn8fshossHn+fX2fxuHNtD5vH5iX1Hn9n7Wfx6NuyitFj+7V5zB6fN8kFcEQ1 MNpkpCampBYppOYl56dk5qXbKnkHxzvHm5oZGOoaWlqYKynkJeam2iq5+AToumXmAJ2tpFCW mFMKFApILC5W0rfDNCE0xE3XAqYxQtc3JAiux8gADSSsYczYcfUra8FhoYqz+5rYGhhP8XUx cnJICJhIPF64mxHCFpO4cG89WxcjF4eQwHRGiXUbtjFDOA8YJS5+O8QKUsUroCUx/e0hNhCb RUBVYtKGjWA2m4COxPZvx5lAbFGBMImJNx9D1QtK/Jh8jwXEFhEIlpjePRVsKLPAVhaJ5z8a wIqEBVwlngODH2LbGkaJbe92gE3lBOroXLsdyOYA6lCXmDIlFyTMLCAvsXnNW+YJjAKzkOyY hVA1C0nVAkbmVYyiqQXJBcVJ6bmGesWJucWleel6yfm5mxjBSeOZ1A7GlQ0WhxgFOBiVeHgZ 5JRDhVgTy4orcw8xSnAwK4nw5t1RChXiTUmsrEotyo8vKs1JLT7EaAoMgYnMUqLJ+cCEllcS b2hsYmZkaWRuaGFkbK4kzjtHVy5USCA9sSQ1OzW1ILUIpo+Jg1OqgVFB+ehij0kHdeQOynJ6 8789nhJWf+Z72QrXqpOK56TsfEUmOt8R/LZdbK/wDcaWoqnGCtEx7RGlm0NzHF8nWZ3Zkb3u n4Tgk9nmEXwSMuXbr0x35RQWul55zKajfVWRk213QtyKV42/bjZWe9u9/ixk/VuW1UWrZJ/g E6dGfaN7anJ3Vp2/q8RSnJFoqMVcVJwIALjgdXQwAwAA 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 Hi, Doug. On 04/07/2015 04:32 AM, Doug Anderson wrote: > Jaehoon, > > On Mon, Apr 6, 2015 at 3:46 AM, Jaehoon Chung wrote: >> Hi, Doug. >> >> On 04/04/2015 03:13 AM, Doug Anderson wrote: >>> The Designware databook claims that cmd11 should be finished in 2ms, >>> but my testing showed that not to be the case in some situations. >>> I've seen cmd11 timeouts of up to 130ms (!) during reboot tests. >>> Let's bump the timeout way up so that we're absolutely sure. CMD11 is >>> only sent during card insertion, so this extra timeout shouldn't be >>> terrible. >> >> Is it h/w problem? Could you explain to me about "some situations"? >> As you said, this timeout only used during card inserting. So, it's not critical.. >> But there is much different between 2ms and 500ms(or 130ms). > > Very good question, and it makes sense to dig into this... > > OK, I think I've got it. Dang printk bites me again. I have serial > console enabled and my printouts were actually causing these delays. > With serial console turned off I reliably get ~280us for the interrupt > to fire (tested across SD and WiFi across 137 + 128 + 111 + 127 = 503 > reboots) Oh..agreed. I also think printouts can be caused the delay. Thanks for your explanation. > > I think it makes sense to land this patch anyway, but with an updated > description. I'm happy to repost this or happy if you just want to > update the description when applying. To save your time, when applying, i will do the updating description. Best Regards, Jaehoon Chung > > --- > > Although the cmd11 interrupt should come within 2ms, that's a very > short time. Let's increase the timeout to be really sure that we > don't get an accidnetal timeout. One case in particular this is > useful is if you've got a serial console and printk in just the right > places. Under that scenario I've seen delays of up to 130ms before > the interrupt fired. > > CMD11 is only sent during card insertion, so this extra timeout > shouldn't be terrible. > > --- > > -Doug > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >