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=-0.8 required=3.0 tests=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 01593C2D0CD for ; Tue, 17 Dec 2019 16:06:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D45AD2465E for ; Tue, 17 Dec 2019 16:06:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728120AbfLQQG0 (ORCPT ); Tue, 17 Dec 2019 11:06:26 -0500 Received: from mga12.intel.com ([192.55.52.136]:46895 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727737AbfLQQGZ (ORCPT ); Tue, 17 Dec 2019 11:06:25 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 08:06:25 -0800 X-IronPort-AV: E=Sophos;i="5.69,326,1571727600"; d="scan'208";a="209748794" Received: from jnikula-mobl3.fi.intel.com (HELO localhost) ([10.237.66.161]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 08:06:21 -0800 From: Jani Nikula To: Andy Shevchenko Cc: Steven Price , Stephen Rothwell , intel-gfx , Randy Dunlap , Linux Kernel Mailing List , dri-devel , Linux Next Mailing List , Sam Ravnborg , Lee Jones , Daniel Thompson , Jingoo Han Subject: Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel) In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20191216162209.5b5256dd@canb.auug.org.au> <20191217054255.GA26868@ravnborg.org> <65c9dc7b-3c61-8204-07da-212632732791@infradead.org> <87d0cnynst.fsf@intel.com> Date: Tue, 17 Dec 2019 18:06:18 +0200 Message-ID: <87a77rym11.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 17 Dec 2019, Andy Shevchenko wrote: > On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula wrote: >> On Tue, 17 Dec 2019, Andy Shevchenko wrote: >> > On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote: > >> > I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/. >> > It fixes issue for me. >> >> As discussed off-line, this will allow silently building and linking a >> configuration that's actually broken. (No backlight support despite >> expectations.) > > In my case I have deliberately compile backlight as a module to be > used exclusively with backlight-gpio which has nothing to do with > i915. I dunno if backlight is a MUST dependency for i915. It's not a required dependency, all combinations of i915 and backlight are fine, *except* i915=y, backlight=m. This can be achieved with: depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n BR, Jani. > > From my perspective the original commit, with all good that it > provides, should not break previously working configurations. Though > we might argue if my "working" kernel configuration had been broken in > the first place... > > Just my 2 cents, though. > >> IMO deep down the problem is that we "select" BACKLIGHT_CLASS_DEVICE all >> over the place, while we should "depends on" it. Everything else is just >> duct tape that allows configurations where built-in code calls backlight >> symbols in modules. It used to be more about an interaction with ACPI, >> now we've added DRM_PANEL to the mix. >> >> I've proposed a fix five years ago [1]. That's what it takes to fix >> these recurring failures for good. I'm not really all that interested in >> the whack-a-mole with the hacks. > > Agree with this. The root cause must be fixed once and for all. > I guess it should be a logical continuation of Sam's series. > >> [1] http://lore.kernel.org/r/1413580403-16225-1-git-send-email-jani.nikula@intel.com -- Jani Nikula, Intel Open Source Graphics Center 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=-0.8 required=3.0 tests=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 C615FC3F68F for ; Tue, 17 Dec 2019 16:06:26 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 93AE524676 for ; Tue, 17 Dec 2019 16:06:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 93AE524676 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 299E86E148; Tue, 17 Dec 2019 16:06:26 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 77CCF6E148; Tue, 17 Dec 2019 16:06:25 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 08:06:24 -0800 X-IronPort-AV: E=Sophos;i="5.69,326,1571727600"; d="scan'208";a="209748794" Received: from jnikula-mobl3.fi.intel.com (HELO localhost) ([10.237.66.161]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 08:06:21 -0800 From: Jani Nikula To: Andy Shevchenko Subject: Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel) In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20191216162209.5b5256dd@canb.auug.org.au> <20191217054255.GA26868@ravnborg.org> <65c9dc7b-3c61-8204-07da-212632732791@infradead.org> <87d0cnynst.fsf@intel.com> Date: Tue, 17 Dec 2019 18:06:18 +0200 Message-ID: <87a77rym11.fsf@intel.com> MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Stephen Rothwell , Daniel Thompson , Lee Jones , intel-gfx , Randy Dunlap , Linux Kernel Mailing List , dri-devel , Steven Price , Linux Next Mailing List , Jingoo Han , Sam Ravnborg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, 17 Dec 2019, Andy Shevchenko wrote: > On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula wrote: >> On Tue, 17 Dec 2019, Andy Shevchenko wrote: >> > On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote: > >> > I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/. >> > It fixes issue for me. >> >> As discussed off-line, this will allow silently building and linking a >> configuration that's actually broken. (No backlight support despite >> expectations.) > > In my case I have deliberately compile backlight as a module to be > used exclusively with backlight-gpio which has nothing to do with > i915. I dunno if backlight is a MUST dependency for i915. It's not a required dependency, all combinations of i915 and backlight are fine, *except* i915=y, backlight=m. This can be achieved with: depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n BR, Jani. > > From my perspective the original commit, with all good that it > provides, should not break previously working configurations. Though > we might argue if my "working" kernel configuration had been broken in > the first place... > > Just my 2 cents, though. > >> IMO deep down the problem is that we "select" BACKLIGHT_CLASS_DEVICE all >> over the place, while we should "depends on" it. Everything else is just >> duct tape that allows configurations where built-in code calls backlight >> symbols in modules. It used to be more about an interaction with ACPI, >> now we've added DRM_PANEL to the mix. >> >> I've proposed a fix five years ago [1]. That's what it takes to fix >> these recurring failures for good. I'm not really all that interested in >> the whack-a-mole with the hacks. > > Agree with this. The root cause must be fixed once and for all. > I guess it should be a logical continuation of Sam's series. > >> [1] http://lore.kernel.org/r/1413580403-16225-1-git-send-email-jani.nikula@intel.com -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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=-0.8 required=3.0 tests=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 01610C43603 for ; Tue, 17 Dec 2019 16:06:31 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D60A524672 for ; Tue, 17 Dec 2019 16:06:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D60A524672 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9655B6E180; Tue, 17 Dec 2019 16:06:26 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 77CCF6E148; Tue, 17 Dec 2019 16:06:25 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 08:06:24 -0800 X-IronPort-AV: E=Sophos;i="5.69,326,1571727600"; d="scan'208";a="209748794" Received: from jnikula-mobl3.fi.intel.com (HELO localhost) ([10.237.66.161]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 08:06:21 -0800 From: Jani Nikula To: Andy Shevchenko In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20191216162209.5b5256dd@canb.auug.org.au> <20191217054255.GA26868@ravnborg.org> <65c9dc7b-3c61-8204-07da-212632732791@infradead.org> <87d0cnynst.fsf@intel.com> Date: Tue, 17 Dec 2019 18:06:18 +0200 Message-ID: <87a77rym11.fsf@intel.com> MIME-Version: 1.0 Subject: Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel) X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Stephen Rothwell , Daniel Thompson , Lee Jones , intel-gfx , Randy Dunlap , Linux Kernel Mailing List , dri-devel , Steven Price , Linux Next Mailing List , Jingoo Han , Sam Ravnborg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, 17 Dec 2019, Andy Shevchenko wrote: > On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula wrote: >> On Tue, 17 Dec 2019, Andy Shevchenko wrote: >> > On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote: > >> > I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/. >> > It fixes issue for me. >> >> As discussed off-line, this will allow silently building and linking a >> configuration that's actually broken. (No backlight support despite >> expectations.) > > In my case I have deliberately compile backlight as a module to be > used exclusively with backlight-gpio which has nothing to do with > i915. I dunno if backlight is a MUST dependency for i915. It's not a required dependency, all combinations of i915 and backlight are fine, *except* i915=y, backlight=m. This can be achieved with: depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n BR, Jani. > > From my perspective the original commit, with all good that it > provides, should not break previously working configurations. Though > we might argue if my "working" kernel configuration had been broken in > the first place... > > Just my 2 cents, though. > >> IMO deep down the problem is that we "select" BACKLIGHT_CLASS_DEVICE all >> over the place, while we should "depends on" it. Everything else is just >> duct tape that allows configurations where built-in code calls backlight >> symbols in modules. It used to be more about an interaction with ACPI, >> now we've added DRM_PANEL to the mix. >> >> I've proposed a fix five years ago [1]. That's what it takes to fix >> these recurring failures for good. I'm not really all that interested in >> the whack-a-mole with the hacks. > > Agree with this. The root cause must be fixed once and for all. > I guess it should be a logical continuation of Sam's series. > >> [1] http://lore.kernel.org/r/1413580403-16225-1-git-send-email-jani.nikula@intel.com -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx