From: Jani Nikula <jani.nikula@linux.intel.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Steven Price <steven.price@arm.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
Randy Dunlap <rdunlap@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Sam Ravnborg <sam@ravnborg.org>, Lee Jones <lee.jones@linaro.org>,
Daniel Thompson <daniel.thompson@linaro.org>,
Jingoo Han <jingoohan1@gmail.com>
Subject: Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel)
Date: Tue, 17 Dec 2019 18:06:18 +0200 [thread overview]
Message-ID: <87a77rym11.fsf@intel.com> (raw)
In-Reply-To: <CAHp75Vd28j5_xexHyXacRaSv=VRkmBLrSh=w2FE8nmAGWdAo6A@mail.gmail.com>
On Tue, 17 Dec 2019, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>> On Tue, 17 Dec 2019, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>> > On Tue, Dec 17, 2019 at 1:56 PM Steven Price <steven.price@arm.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Daniel Thompson <daniel.thompson@linaro.org>,
Lee Jones <lee.jones@linaro.org>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
Randy Dunlap <rdunlap@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Steven Price <steven.price@arm.com>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Jingoo Han <jingoohan1@gmail.com>,
Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel)
Date: Tue, 17 Dec 2019 18:06:18 +0200 [thread overview]
Message-ID: <87a77rym11.fsf@intel.com> (raw)
In-Reply-To: <CAHp75Vd28j5_xexHyXacRaSv=VRkmBLrSh=w2FE8nmAGWdAo6A@mail.gmail.com>
On Tue, 17 Dec 2019, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>> On Tue, 17 Dec 2019, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>> > On Tue, Dec 17, 2019 at 1:56 PM Steven Price <steven.price@arm.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Daniel Thompson <daniel.thompson@linaro.org>,
Lee Jones <lee.jones@linaro.org>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
Randy Dunlap <rdunlap@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Steven Price <steven.price@arm.com>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Jingoo Han <jingoohan1@gmail.com>,
Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel)
Date: Tue, 17 Dec 2019 18:06:18 +0200 [thread overview]
Message-ID: <87a77rym11.fsf@intel.com> (raw)
In-Reply-To: <CAHp75Vd28j5_xexHyXacRaSv=VRkmBLrSh=w2FE8nmAGWdAo6A@mail.gmail.com>
On Tue, 17 Dec 2019, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>> On Tue, 17 Dec 2019, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>> > On Tue, Dec 17, 2019 at 1:56 PM Steven Price <steven.price@arm.com> 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
next prev parent reply other threads:[~2019-12-17 16:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-16 5:22 linux-next: Tree for Dec 16 Stephen Rothwell
2019-12-16 16:25 ` linux-next: Tree for Dec 16 (drm_panel & intel_panel) Randy Dunlap
2019-12-16 16:25 ` [Intel-gfx] " Randy Dunlap
2019-12-16 16:25 ` Randy Dunlap
2019-12-17 5:42 ` Sam Ravnborg
2019-12-17 5:42 ` [Intel-gfx] " Sam Ravnborg
2019-12-17 5:42 ` Sam Ravnborg
2019-12-17 6:37 ` Randy Dunlap
2019-12-17 6:37 ` [Intel-gfx] " Randy Dunlap
2019-12-17 6:37 ` Randy Dunlap
2019-12-17 11:52 ` Steven Price
2019-12-17 11:52 ` [Intel-gfx] " Steven Price
2019-12-17 11:52 ` Steven Price
2019-12-17 14:02 ` Andy Shevchenko
2019-12-17 14:02 ` [Intel-gfx] " Andy Shevchenko
2019-12-17 14:02 ` Andy Shevchenko
2019-12-17 15:28 ` [Intel-gfx] " Jani Nikula
2019-12-17 15:28 ` Jani Nikula
2019-12-17 15:28 ` Jani Nikula
2019-12-17 15:49 ` Andy Shevchenko
2019-12-17 15:49 ` Andy Shevchenko
2019-12-17 15:49 ` Andy Shevchenko
2019-12-17 16:06 ` Jani Nikula [this message]
2019-12-17 16:06 ` Jani Nikula
2019-12-17 16:06 ` Jani Nikula
2019-12-17 13:03 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2019-12-17 13:33 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2019-12-17 21:52 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a77rym11.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=daniel.thompson@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jingoohan1@gmail.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=sam@ravnborg.org \
--cc=sfr@canb.auug.org.au \
--cc=steven.price@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.