From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6827FC433F5 for ; Fri, 22 Oct 2021 17:00:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4B17E611CB for ; Fri, 22 Oct 2021 17:00:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233634AbhJVRCY (ORCPT ); Fri, 22 Oct 2021 13:02:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233413AbhJVRCT (ORCPT ); Fri, 22 Oct 2021 13:02:19 -0400 Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD1F1C061766 for ; Fri, 22 Oct 2021 10:00:01 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id o184so6245235iof.6 for ; Fri, 22 Oct 2021 10:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kTen2SJ5OXpwrB3GYaVSgs5PSr8Wl3SgV5Rb/nQHzy4=; b=OfBpCJAzSU6W7PZkLXvnp5uTA+iDkXVIdjqAMBeIpoljCUIE4H16rweL/sbBvPgjOz a7XnxBwIYdIryHPaHA7ppp+xRkuJ8ZkGtFQ917cYf6DXBKPw/S1sutxiZQufEACp4UpT PLnHHSzn4hQ4AhSAlnXGb0jGqcXGqNTs1nU6fnOh+AIxI5Q8oMN4iE7Fya+Xc4OOZBym rRn0MMZj1yiUeB/E8pchAg4wkBwHmXHOyXkKHbDeAue4CSfMCyDa4KbzZTr3JaR9+GBS VNmBEefGtXM9NaGbU0Rp/mPohCP047tLX02ikVEAVBUzcMC6NEhoorwouURdd7M5e8d/ nviw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kTen2SJ5OXpwrB3GYaVSgs5PSr8Wl3SgV5Rb/nQHzy4=; b=y98KaqOYghNFj6HsK52S+cFu473N6fhv5bpF8M9k9neFjpUHj9hBpqdXPh6plR+29B OguNlN1uu+nKuA3dJhH6G1K5olOE8THJn4D90Kzsc0M5rV+cX75bIN1x1xCXBitz5OAC 0XvASl1dP6Km6otVqV99aG/REweA/xYiNoJF9DAoHF1IgSxctLBzRDVWqAkIeX0fhrS+ Pq0YxHBOnJoV/M9RlTHaM6Lb9b31HKXTcxDq6S/wCacQcbSDv1noaAPXw7XlpbkXQIBA f+QNvkoqrbA9pLtd0f9QdsA5MfGW2tcrltqkAfwYoy0mM0pHIZBWJxMkq4ChYYl21Oqx CCQA== X-Gm-Message-State: AOAM531Q4+XS8XW2wYU/qDMTXmtJyIsAa257DEjK/quDre6/qUxFsr6p h/k1yN3j5lq9kZ9uOxUduEF7LvXIMzB6PnuhgoQey5ZOsSiW9A== X-Google-Smtp-Source: ABdhPJzxQ0fZin7R9PkqV1UP1dkqBLaE11BhnPXYcqoa5W2nV/HynKJCgyp+2iBylPP9BT6beLI8s2+3hLU0rL6J7ec= X-Received: by 2002:a05:6602:168f:: with SMTP id s15mr547913iow.178.1634922001157; Fri, 22 Oct 2021 10:00:01 -0700 (PDT) MIME-Version: 1.0 References: <20210929000735.585237-1-saravanak@google.com> <20210929000735.585237-3-saravanak@google.com> In-Reply-To: From: Amit Pundir Date: Fri, 22 Oct 2021 22:29:24 +0530 Message-ID: Subject: Re: [PATCH v4 2/2] drivers: bus: Delete CONFIG_SIMPLE_PM_BUS To: Saravana Kannan Cc: Russell King , Neil Armstrong , Geert Uytterhoeven , Magnus Damm , Tony Lindgren , Catalin Marinas , Will Deacon , Damien Le Moal , Greg Kroah-Hartman , Ulf Hansson , Rob Herring , Android Kernel Team , linux-arm-kernel@lists.infradead.org, lkml , linux-oxnas@groups.io, linux-renesas-soc@vger.kernel.org, linux-omap@vger.kernel.org, linux-riscv@lists.infradead.org, Dmitry Baryshkov , John Stultz Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 22 Oct 2021 at 05:13, Saravana Kannan wrote: > > On Thu, Oct 21, 2021 at 4:21 AM Amit Pundir wrote: > > > > Hi Saravana, > > > > This patch broke v5.15-rc6 on RB5 (sm8250 | qcom/qrb5165-rb5.dts). > > I can't boot past this point https://www.irccloud.com/pastebin/raw/Nv6ZwHmW. > > Amit top posting? How did that happen? :) > > The fact you are seeing this issue is super strange though. The driver > literally does nothing other than allowing some sync_state() callbacks > to happen. I also grepped for the occurence of "simple-bus" in > arch/arm64/boot/dts/qcom/ and the only instance for 8250 is for the > soc node. > > The only thing I can think of is that without my patch some > sync_state() callbacks weren't getting called and maybe it was masking > some other issue. > > Can you try to boot with this log (see log patch below) and see if the > device hangs right after a sync_state() callback? Also, looking at the > different sync_state() implementations in upstream, I'm guessing one > of the devices isn't voting for interconnect bandwidth when it should > have. > > Another thing you could do is boot without the simple-bus changes and > then look for all instances of "state_synced" in /sys/devices and then > see if any of them has the value "0" after boot up is complete. Turned out RB5 is not even reaching up to device_links_flush_sync_list() and seem to be stuck somewhere in device_links_driver_bound(). So I added more print logs to narrow down to any specific lock state but those additional prints seem to have added enough delay to unblock that particular driver (Serial: 8250/16550 driver if I understood the logs correctly) and I eventually booted to UI. On the booted RB5 *with* and *without* the simple-bus changes, I see 4 instances of "0" state_synced nodes at: /sys/devices/platform/soc@0/9100000.interconnect/state_synced /sys/devices/platform/soc@0/1500000.interconnect/state_synced /sys/devices/platform/soc@0/1740000.interconnect/state_synced /sys/devices/platform/soc@0/163d000.interconnect/state_synced Regards, Amit Pundir > > -Saravana > > -- a/drivers/base/core.c > +++ b/drivers/base/core.c > @@ -1099,6 +1099,7 @@ static void device_links_flush_sync_list(struct > list_head *list, > if (dev != dont_lock_dev) > device_lock(dev); > > + dev_info(dev, "Calling sync_state()\n"); > if (dev->bus->sync_state) > dev->bus->sync_state(dev); > else if (dev->driver && dev->driver->sync_state)