From: Jani Nikula <jani.nikula@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org, rodrigo.vivi@intel.com
Subject: Re: [Intel-xe] [PATCH 08/10] fixup! drm/xe/display: Implement display support
Date: Wed, 04 Oct 2023 20:11:18 +0300 [thread overview]
Message-ID: <87zg0ycnyh.fsf@intel.com> (raw)
In-Reply-To: <diaa7nf3l6b5qsczyxto5ftyrcdrx2l3kec7wauoen57hy7dus@bxvldjcc5yyr>
On Wed, 04 Oct 2023, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> On Tue, Oct 03, 2023 at 05:34:55PM +0300, Jani Nikula wrote:
>>Turn the enable_display module parameter to the same thing as it is for
>>i915: assuming you have display hardware, take over it, put it to sleep,
>>and keep connectors disconnected.
>
> that was not what it was created for and it was on purpose. That is not
> what we need when enabling a platform. The argument that *users* would
> then be left in a situation that the display hardware is still consuming
> power is IMO wrong as those *users* are not supposed to be using module
> parameters and if they do, it's their only responsibility.
>
> The module parameter here is for kernel developers and CI/validation,
> particularly when enabling a new platform, to decide if the display side
> should be enabled or not.
If you have a module param without the _unsafe annotation, and the only
documentation is "enable display", it *is* for users.
If you want to have a module param that's for development or debugging
only, make it _unsafe, and add documentation to that effect.
In any case, what's currently in the tree is conflated and broken, and
this is/was an attempt to fix it. It's impossible to integrate xe with
i915 display if the xe has different notions on the basic idea of what
having or enabling display means.
BR,
Jani.
--
Jani Nikula, Intel
next prev parent reply other threads:[~2023-10-04 17:11 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-03 14:34 [Intel-xe] [PATCH 00/10] xe/display: clarify display configuration Jani Nikula
2023-10-03 14:34 ` [Intel-xe] [PATCH 01/10] fixup! drm/xe/display: Implement display support Jani Nikula
2023-10-04 14:02 ` Rodrigo Vivi
2023-10-04 14:23 ` Jani Nikula
2023-10-04 14:41 ` Rodrigo Vivi
2023-10-04 14:25 ` Jani Nikula
2023-10-03 14:34 ` [Intel-xe] [PATCH 02/10] " Jani Nikula
2023-10-04 14:04 ` Rodrigo Vivi
2023-10-03 14:34 ` [Intel-xe] [PATCH 03/10] " Jani Nikula
2023-10-04 14:04 ` Rodrigo Vivi
2023-10-03 14:34 ` [Intel-xe] [PATCH 04/10] fixup! drm/xe: Introduce Xe assert macros Jani Nikula
2023-10-04 14:05 ` Rodrigo Vivi
2023-10-03 14:34 ` [Intel-xe] [PATCH 05/10] fixup! drm/xe/display: Implement display support Jani Nikula
2023-10-04 14:05 ` Rodrigo Vivi
2023-10-03 14:34 ` [Intel-xe] [PATCH 06/10] " Jani Nikula
2023-10-04 14:05 ` Rodrigo Vivi
2023-10-04 16:19 ` Lucas De Marchi
2023-10-04 16:31 ` Jani Nikula
2023-10-03 14:34 ` [Intel-xe] [PATCH 07/10] " Jani Nikula
2023-10-04 14:06 ` Rodrigo Vivi
2023-10-03 14:34 ` [Intel-xe] [PATCH 08/10] " Jani Nikula
2023-10-04 14:23 ` Rodrigo Vivi
2023-10-04 14:37 ` Jani Nikula
2023-10-04 16:14 ` Rodrigo Vivi
2023-10-04 16:41 ` Lucas De Marchi
2023-10-04 17:11 ` Jani Nikula [this message]
2023-10-04 18:03 ` Lucas De Marchi
2023-10-03 14:34 ` [Intel-xe] [PATCH 09/10] " Jani Nikula
2023-10-04 14:21 ` Rodrigo Vivi
2023-10-04 16:28 ` Lucas De Marchi
2023-10-04 17:32 ` Jani Nikula
2023-10-03 14:34 ` [Intel-xe] [PATCH 10/10] " Jani Nikula
2023-10-04 14:09 ` Rodrigo Vivi
2023-10-03 14:48 ` [Intel-xe] ✓ CI.Patch_applied: success for xe/display: clarify display configuration Patchwork
2023-10-03 14:48 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-10-03 14:49 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-10-03 14:56 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-10-03 14:57 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-10-03 14:58 ` [Intel-xe] ✓ CI.checksparse: " Patchwork
2023-10-03 15:35 ` [Intel-xe] ✓ CI.BAT: " 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=87zg0ycnyh.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=rodrigo.vivi@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox