Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2418646imm; Mon, 24 Sep 2018 04:08:44 -0700 (PDT) X-Google-Smtp-Source: ACcGV61iFXWAdf2CmiGVmGxTA62kwFsTtG8MsQNQNYrwEkHfEVKG4MFA5OoirYYFbYvoJBbQLkSa X-Received: by 2002:a17:902:bd87:: with SMTP id q7-v6mr2709658pls.85.1537787324553; Mon, 24 Sep 2018 04:08:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537787324; cv=none; d=google.com; s=arc-20160816; b=M8NCSNFtHdY8LiGLRKKCAENGaR2v+SCOtntDrwutGeQQ47aEQXM8PQ1pJ7iXALDoYh QqjGuPyZlWMugz00ryj5RcCfnh9W2CQ99g3KBEkQlMzadYKiP2Lon1Wc0Albd6pBJq6w 4t6+E1+V0e1otB+WgtcvexMePetZd8KHOopN6wV0DvSwr0DvNG2VE+0DGdqRGT0GRNbP RabS4Z4p0j2qczCW/1UpwJ5K0J0oxDJ8DI5oydJB/+gwIRYL44UT+4eLvoiYaHbZMFly sFGs1IQnBU119jcIkMYHlADpK7wOnc83rleMfDF5hLdY1V/D/jgHZKBZPadnmIvRZL5j l40Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=1p534W35sqCWplCn+Y6xqzi2jcGhSQqylEiQ9nfK2Pk=; b=aI62jmzsV+e4BBqF1nozEybJTOGE/HbdR7vW01tBZBPzXsjFZ2PfTuNpupOX5DXApW VyeUmHxYtgzYdglT/hJIdNOsWTHQhfSa5FZpjkbWjbsQ8vgrst1tEZmsPlZNdOFPQ6IM 7oauvJfdSKbRC7CtIec9z9ltpDzEa2AAMMa4HvrWXiPuy5L+EdEgV+sRObTTu2cRnyd4 MQ+x2XQzjMGx+LeHgIJgY8YvBeZB1il+gKuKHZrSH4CJv0oevWStPp6hhF59Gw+/7kZV uESFx8dM4OR6ycIJXaocjAup7upbHgxI6oDrvgp5A9hAjo7eTpT5UBbKU+LWNBMj4StO onjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HCvMIt3Y; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s25-v6si34791525pgd.539.2018.09.24.04.08.28; Mon, 24 Sep 2018 04:08:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HCvMIt3Y; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728764AbeIXRJr (ORCPT + 99 others); Mon, 24 Sep 2018 13:09:47 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:40551 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725982AbeIXRJq (ORCPT ); Mon, 24 Sep 2018 13:09:46 -0400 Received: by mail-oi0-f67.google.com with SMTP id j68-v6so568839oib.7; Mon, 24 Sep 2018 04:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1p534W35sqCWplCn+Y6xqzi2jcGhSQqylEiQ9nfK2Pk=; b=HCvMIt3YT78N2Oxx2VcMJ7CtI1Dj4WP0OEjzsb8YYhKjt/n2ob1o7mVkYRDxebSyXD +zqUyXU6uZKmiT4ciRWzgdZ6C8q1tJ3PUAo8ywi/DcDisDSGvZ22JFKaMA0dXDmnFSO7 yMw4w+NZkc5afa0qUmMf1pdaYMp43g/JOdR5pecrBVw+v+4CivO+EQ+18+35Iv1QbzlO VFtPNZI/Zd/9cpdpxA9BjSTcy79SRxfB/gQckys1TpYaTl/fvTuu4OVjxvyBYc6z+Jqm Z4iPx/Kf9qsWJMyxiaTgrq2GuA7Y+GDIUgY/ABTvwyMshQKYuqYtSZ8Xl08ZHIOWMyJT d6zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1p534W35sqCWplCn+Y6xqzi2jcGhSQqylEiQ9nfK2Pk=; b=erzZ+KFkLInEnMN7QRdfK0nhsAPX8r55TkNHq83zoXHWdVQ8C9r2fXi8nAzy2qPcUF aOj0O05QWUqsXYo/FqW43shRssgON1p/13jursJAH/B4kkHFl5SLB5Too47ACCLzhtnb OriJ5TJmScqldhDS2vm3HDeXfy4mHxY+Z6Pc2CXxArkoQpdH4k1+9w1Kn/o8AoSRUK2Z ti9k5OhIAcQZg7pANqwrZi5RkYd1hD/9C0Ab8PeN1Lpz7euhdtFkAl0Bog6PS+N1O2ac w673s+oGsmDTI8VP6rtc29Dpekce98HY7hJMEdiaqSc7n0pXet5gI5Yc4YoffeNnsdmn CUFg== X-Gm-Message-State: APzg51CCMnzzX1S6DtM1Bnnj9UV2WiclqiC+8VhZMusymFk2rLyhuKDJ bLhnwsVaYfGvxZlEGAD7tx8DdCLwBx0m7mjS9Og= X-Received: by 2002:aca:6898:: with SMTP id o24-v6mr4895085oik.44.1537787291681; Mon, 24 Sep 2018 04:08:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:326:0:0:0:0:0 with HTTP; Mon, 24 Sep 2018 04:08:10 -0700 (PDT) In-Reply-To: <20180924094339eucas1p282f2f7cb627c183fe87da044edb90fa5~XTMgQ4GFs1339913399eucas1p2N@eucas1p2.samsung.com> References: <2785169.v6aIfS3K2k@z50> <20180923235336.22148-1-jmkrzyszt@gmail.com> <20180924094339eucas1p282f2f7cb627c183fe87da044edb90fa5~XTMgQ4GFs1339913399eucas1p2N@eucas1p2.samsung.com> From: Janusz Krzysztofik Date: Mon, 24 Sep 2018 13:08:11 +0200 Message-ID: Subject: Re: [PATCH 0/2] gpiolib: Fix issues introduced by fast bitmap processing path To: Marek Szyprowski Cc: Linus Walleij , Jonathan Corbet , Miguel Ojeda Sandonis , Peter Korsgaard , Peter Rosin , Ulf Hansson , Andrew Lunn , Florian Fainelli , "David S. Miller" , Dominik Brodowski , Greg Kroah-Hartman , Kishon Vijay Abraham I , Lars-Peter Clausen , Michael Hennerich , Jonathan Cameron , Hartmut Knaack , Peter Meerwald-Stadler , Jiri Slaby , Willy Tarreau , Geert Uytterhoeven , Sebastien Bourdelin , Lukas Wunner , Rojhalat Ibrahim , Russell King , Tony Lindgren , Yegor Yefremov , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , linux-doc@vger.kernel.org, linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org, netdev@vger.kernel.org, linux-iio@vger.kernel.org, devel@driverdev.osuosl.org, linux-serial@vger.kernel.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, Krzysztof Kozlowski , Linux Samsung SOC Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marek, 2018-09-24 11:43 GMT+02:00, Marek Szyprowski : > Hi Janusz, > > On 2018-09-24 01:53, Janusz Krzysztofik wrote: >> While investigating possible reasons of GPIO fast bitmap processing >> related boot hang on Samsung Snow Chromebook, reported by Marek >> Szyprowski (thanks!), I've discovered one coding bug, addressed by >> PATCH 1/2 of this series, and one potential regression introduced at >> design level of the solution, hopefully fixed by PATCH 2/2. See >> commit messages for details. >> >> Janusz Krzysztofik (2): >> gpiolib: Fix missing updates of bitmap index >> gpiolib: Fix array members of same chip processed separately >> >> The fixes should resolve the boot hang observed by Marek, however the >> second change excludes that particular case from fast bitmap processing >> and restores the old behaviour. > > I confirm, that the above 2 patches fixes boot issue on Samsung Snow > Chromebook with next-20180920. > > Tested-by: Marek Szyprowski > >> Hence, it is possible still another >> issue which have had an influence on that boot hang exists in the code. >> In order to fully verify the fix, it would have to be tested on a >> platform where an array of GPIO descriptors is used which starts from >> at least two consecutive pins of one GPIO chip in hardware order, >> starting ftom 0, followed by one or more pins belonging to other >> chip(s). >> >> In order to verify if separate calls to .set() chip callback for each >> pin instead of one call to .set_multiple() is actually the reason of >> boot hang on Samsung Snow Chromebook, the affected driver - >> drivers/mmc/core/pwrseq_simple.c - would have to be temporarily >> modified for testing purposes so it calls gpiod_set_value() for each >> pin instead of gpiod_set_array_value() for all of them. If that would >> also result in boot hang, we could be sure the issue was really the >> one addressed by the second fix. Marek, could you please try to >> perform such test? > > Yes, I've just tested next-20180920 only with the first patch from this > patchset and the mentioned change to drivers/mmc/core/pwrseq_simple.c. > It boots fine, so indeed the issue is in handling of arrays of gpios. > > Just to be sure I did it right, this is my change to the mentioned file: Yeah, that's what I had on mind. However, I'd be more lucky if it didn't work for you. Setting the pins sequentially, not simultaneously as before, was exactly what I hoped was the reason of the hang. > diff --git a/drivers/mmc/core/pwrseq_simple.c > b/drivers/mmc/core/pwrseq_simple.c > index 7f882a2bb872..9397dc1f2e38 100644 > --- a/drivers/mmc/core/pwrseq_simple.c > +++ b/drivers/mmc/core/pwrseq_simple.c > @@ -38,16 +38,11 @@ static void mmc_pwrseq_simple_set_gpios_value(struct > mmc_pwrseq_simple *pwrseq, > int value) > { > struct gpio_descs *reset_gpios = pwrseq->reset_gpios; > + int i; > > - if (!IS_ERR(reset_gpios)) { > - DECLARE_BITMAP(values, BITS_PER_TYPE(value)); > - int nvalues = reset_gpios->ndescs; > - > - values[0] = value; > - > - gpiod_set_array_value_cansleep(nvalues, reset_gpios->desc, > - reset_gpios->info, values); > - } > + if (!IS_ERR(reset_gpios)) > + for (i = 0; i < reset_gpios->ndescs; i++) The only difference from the behaviour when the hang was occurring is now the order the pins are manipulated. Maybe that matters? Could you please retry the same with the order of pins reversed, either in the .dts file or here inside this for loop? Thanks, Janusz > + gpiod_set_value_cansleep(reset_gpios->desc[i], value); > } > > static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host) > > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > >