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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2ADABC433FE for ; Wed, 22 Sep 2021 20:25:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0718E61100 for ; Wed, 22 Sep 2021 20:25:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237550AbhIVU1M (ORCPT ); Wed, 22 Sep 2021 16:27:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232274AbhIVU1K (ORCPT ); Wed, 22 Sep 2021 16:27:10 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61408C061574 for ; Wed, 22 Sep 2021 13:25:40 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id u8so16313290lff.9 for ; Wed, 22 Sep 2021 13:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=32+aYzuaFD1O1viEyMAbzrc37otijziLTHIx/x5GVqU=; b=bglC1jKwLFWblaCzoqFGj2TZxYkx2+0o4kjbG7EFOH/ZWj79L+2XA4WbYVlaiZPaaF p3XlKpu+DswBZY+rQXxwpEf8QQCUMLJZxPq8D1nboHRcPpi+Dl/IeuEPE+NsF0BJNo9k fnz0WVF9fzqBHN0ReOA/z8WWB2VX+cNiaifZI= 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=32+aYzuaFD1O1viEyMAbzrc37otijziLTHIx/x5GVqU=; b=DZPWOjAM6Xugr9x1y/H96CJBa7xd4gYiWhbMnC94G/A+Pj0VV4bb1D64DudaLruqb4 evwNurgTQsqJhZVsN6D4Rpbx6AOPZf73IJuQZnRHv7SGgnnF9K+4sYBtj37kVywa1vNB vGMemOyV/1ou2vszKY69EVonnn7oDXHEPoQHwGUBqVJOpw9f7FAOSrJsYFbQK9tsNbD3 P6/CAtJh7smiw/7v8X7VcGILTIYADn36xKF+gP8lD6RTg97TxQuBWAr5+vecXSrCD1YO B2bFmk5LhTmfxuJfx/kSPPIPSuQeVa5AitYocTNKqO3Kh6Dv2eyIs0WNs6D4FroMWsdD jq6Q== X-Gm-Message-State: AOAM533Zo9UrP4JcrRyv7dNy2uchBDT9tINa2Ncv9V9x2O7pjyAOpD2t KmIVciqpUYTpV0ta5M9OQqu7aLFoZji22eWo60k= X-Google-Smtp-Source: ABdhPJw7+hm3iNWIZ5nMalh2Bdcw4DtGr+h8XPSlCFaClSGkhTUcZsVbXmkDZVlGaY0Tv/2StyxP7A== X-Received: by 2002:a2e:a4ba:: with SMTP id g26mr1298046ljm.254.1632342338450; Wed, 22 Sep 2021 13:25:38 -0700 (PDT) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com. [209.85.167.52]) by smtp.gmail.com with ESMTPSA id bd9sm361956ljb.29.2021.09.22.13.25.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Sep 2021 13:25:37 -0700 (PDT) Received: by mail-lf1-f52.google.com with SMTP id x27so16955376lfu.5 for ; Wed, 22 Sep 2021 13:25:37 -0700 (PDT) X-Received: by 2002:a05:651c:1250:: with SMTP id h16mr1357916ljh.68.1632342337491; Wed, 22 Sep 2021 13:25:37 -0700 (PDT) MIME-Version: 1.0 References: <20210903160302.yh42vpkuob45dbpb@gilmour> <20210904091050.g5axxctgelciihjn@gilmour> <20210920144730.d7oabqfbx7pmyyfb@gilmour> <20210920154333.vunyxeshdb7jt5ka@gilmour> <20210920155350.h6624mt65vwg72p2@gilmour> <20210920171042.oq3ndp3ox4xv5odh@gilmour> <20210922095725.dk4vk42zb3kh7y6s@gilmour> In-Reply-To: From: Linus Torvalds Date: Wed, 22 Sep 2021 13:25:21 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Regression with mainline kernel on rpi4 To: Sudip Mukherjee Cc: Maxime Ripard , Emma Anholt , David Airlie , Daniel Vetter , Philipp Zabel , dri-devel , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 22, 2021 at 1:19 PM Sudip Mukherjee wrote: > > I added some debugs to print the addresses, and I am getting: > [ 38.813809] sudip crtc 0000000000000000 > > This is from struct drm_crtc *crtc = connector->state->crtc; Yeah, that was my personal suspicion, because while the line number implied "crtc->state" being NULL, the drm data structure documentation and other drivers both imply that "crtc" was the more likely one. I suspect a simple if (!crtc) return; in vc4_hdmi_set_n_cts() is at least part of the fix for this all, but I didn't check if there is possibly something else that needs to be done too. Linus