intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 08/11] drm/i915/dsb: Add i915.enable_dsb module parameter
Date: Wed, 19 Jun 2024 20:24:01 +0300	[thread overview]
Message-ID: <87v824ethq.fsf@intel.com> (raw)
In-Reply-To: <ZnLxT9oesCkk_NGS@intel.com>

On Wed, 19 Jun 2024, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Wed, Jun 19, 2024 at 05:44:08PM +0300, Ville Syrjälä wrote:
>> On Wed, Jun 19, 2024 at 04:24:16PM +0300, Ville Syrjälä wrote:
>> > On Wed, Jun 19, 2024 at 04:11:08PM +0300, Jani Nikula wrote:
>> > > On Wed, 19 Jun 2024, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>> > > > On Tue, Jun 18, 2024 at 02:07:56PM +0300, Jani Nikula wrote:
>> > > >> On Tue, 11 Jun 2024, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
>> > > >> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > > >> >
>> > > >> > As we extend the use of DSB for critical pipe/plane register
>> > > >> > programming, it'll be nice to have an escape valve at hand,
>> > > >> > in case things go very poorly. To that end, add a i915.enable_dsb
>> > > >> > modparam by which we can force the driver to take the pure mmio
>> > > >> > path instead.
>> > > >> >
>> > > >> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > > >> > ---
>> > > >> >  drivers/gpu/drm/i915/display/intel_display_params.c | 3 +++
>> > > >> >  drivers/gpu/drm/i915/display/intel_display_params.h | 1 +
>> > > >> >  drivers/gpu/drm/i915/display/intel_dsb.c            | 3 +++
>> > > >> >  3 files changed, 7 insertions(+)
>> > > >> >
>> > > >> > diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c b/drivers/gpu/drm/i915/display/intel_display_params.c
>> > > >> > index aebdb7b59dbf..449a31767791 100644
>> > > >> > --- a/drivers/gpu/drm/i915/display/intel_display_params.c
>> > > >> > +++ b/drivers/gpu/drm/i915/display/intel_display_params.c
>> > > >> > @@ -54,6 +54,9 @@ intel_display_param_named_unsafe(enable_dc, int, 0400,
>> > > >> >  intel_display_param_named_unsafe(enable_dpt, bool, 0400,
>> > > >> >  	"Enable display page table (DPT) (default: true)");
>> > > >> >  
>> > > >> > +intel_display_param_named_unsafe(enable_dsb, bool, 0600,
>> > > >> > +	"Enable display state buffer (DSB) (default: true)");
>> > > >> 
>> > > >> Not much point in leaving the module param 0600, is there?
>> > > >
>> > > > It'll let you try both dsb and mmio paths at runtime without
>> > > > having to do a full reboot/reload.
>> > > 
>> > > I mean does any code actually look at the *module* parameter runtime?
>> > > It's only the initial value for the device param?
>> > 
>> > You can change it via the debugfs i915_params/* thing.
>> 
>> Apparently the modparam vs. debugfs permissions are specified in two
>> different places. This is rather confusing.
>> 
>> Is there no way to put them in the same place? Or can we just nuke
>> the permission stuff from the modparam macro entirely so it won't
>> end up confusing me again? Looks like there is exactly one (gem related)
>> modparam that uses 0600, everything else seems to be 0400.
>
> And even that seems to use the per-device copy in the actual code.
> So looks to me like we can just rip out the macro argument and
> make it 0400 always.

Yeah, it's not great.

I guess the only reason the modparams would need to be writable is to be
able to use different values for different devices when the modparam
values are needed at probe, before they can be changed via device param
debugfs:

- set modparam to x
- probe device 1
- set modparam to y
- probe device 2

I don't know if anyone really uses that. There are really no good
solutions to this. :(

BR,
Jani.


-- 
Jani Nikula, Intel

  reply	other threads:[~2024-06-19 17:24 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-11 13:33 [PATCH 00/11] drm/i915/dsb: DSB prep stuff Ville Syrjala
2024-06-11 13:33 ` [PATCH 01/11] drm/i915: Extract intel_crtc_arm_vblank_event() Ville Syrjala
2024-06-11 13:33 ` [PATCH 02/11] drm/i915: Add async flip tracepoint Ville Syrjala
2024-06-11 13:33 ` [PATCH 03/11] drm/i915: Add flip done tracepoint Ville Syrjala
2024-06-11 13:33 ` [PATCH 04/11] drm/i915: Introduce intel_mode_vdisplay() Ville Syrjala
2024-06-11 13:33 ` [PATCH 05/11] drm/i915: Pass the whole atomic state to intel_color_prepare_commit() Ville Syrjala
2024-06-11 13:33 ` [PATCH 06/11] drm/i915/dsb: Plumb the whole atomic state into intel_dsb_prepare() Ville Syrjala
2024-06-11 13:33 ` [PATCH 07/11] drm/i915/dsb: Convert the DSB code to use intel_display rather than i915 Ville Syrjala
2024-06-18 11:08   ` Jani Nikula
2024-06-11 13:33 ` [PATCH 08/11] drm/i915/dsb: Add i915.enable_dsb module parameter Ville Syrjala
2024-06-18 11:07   ` Jani Nikula
2024-06-19 11:29     ` Ville Syrjälä
2024-06-19 13:11       ` Jani Nikula
2024-06-19 13:24         ` Ville Syrjälä
2024-06-19 14:44           ` Ville Syrjälä
2024-06-19 14:55             ` Ville Syrjälä
2024-06-19 17:24               ` Jani Nikula [this message]
2024-06-11 13:33 ` [PATCH 09/11] drm/i915: Drop useless intel_dsb.h include Ville Syrjala
2024-06-11 13:33 ` [PATCH 10/11] drm/i915/dsb: Document that the ATS fault bits are for mtl+ Ville Syrjala
2024-06-11 13:33 ` [PATCH 11/11] drm/i915/dsb: Try to document that DSB_STATUS bit 16 is level triggered Ville Syrjala
2024-06-11 14:21 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dsb: DSB prep stuff Patchwork
2024-06-11 14:21 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-06-11 14:42 ` ✓ Fi.CI.BAT: success " Patchwork
2024-06-12  5:32 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-06-18 11:09 ` [PATCH 00/11] " Jani Nikula

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=87v824ethq.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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;
as well as URLs for NNTP newsgroup(s).