public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>,
	Tomi Sarvela <tomi.p.sarvela@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Remove support for legacy debugfs crc interface
Date: Tue, 21 Nov 2017 16:07:43 +0200	[thread overview]
Message-ID: <20171121140743.GA10981@intel.com> (raw)
In-Reply-To: <f9e136d3-006b-ef34-4d9b-bb39944712c8@linux.intel.com>

On Tue, Nov 21, 2017 at 11:39:01AM +0100, Maarten Lankhorst wrote:
> Op 08-11-17 om 12:25 schreef Ville Syrjälä:
> > On Wed, Nov 08, 2017 at 11:40:19AM +0100, Maarten Lankhorst wrote:
> >> Op 02-11-17 om 17:11 schreef Ville Syrjälä:
> >>> On Thu, Nov 02, 2017 at 05:19:07PM +0200, Jani Nikula wrote:
> >>>> On Thu, 02 Nov 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >>>>> On Thu, Nov 02, 2017 at 02:56:51PM +0100, Maarten Lankhorst wrote:
> >>>>>> This interface is deprecated, and has been replaced by the upstream
> >>>>>> drm crc interface.
> >>>>> Before we nuke this I would like to see an option in the new interface
> >>>>> to not filter out the "bad" CRCs. When analyzing how the hardware
> >>>>> behaves seeing every CRC can be valuable. And I'm not at all convinced
> >>>>> we should be dropping as many CRCs as we are currently.
> >>>> I'm not against it, but do you have a concrete proposal on how that
> >>>> option would look like?
> >>> Some kind of of filter_bad_crcs file with a bool value perhaps?
> >> You can set sources, might as well add a nofilter option.. But I don't see what it has to do
> >> with this patch? This problem existed since before the api was introduced.. Only difference
> >> is kernel eats possibly corrupt CRCs now instead of IGT.
> > I don't use igt for this.
> >
> If it's not in IGT then I'm not sure we should hold upthis patch for it tbh. You can
> always change skipped = 0 to skipped = 2 for the new debugfs interface to find bugs
> with garbage CRC values, or add a flag to pipe source parsing for not skipping
> garbage CRC's.

Why do you want to intentionally generate more pointless work for me?

If you don't want to fix the new interface to have feature parity
with the old one then just don't remove the old one. It's not
hurting anyone AFAICS.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-11-21 14:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-02 13:56 [PATCH] drm/i915: Remove support for legacy debugfs crc interface Maarten Lankhorst
2017-11-02 14:27 ` Ville Syrjälä
2017-11-02 15:19   ` Jani Nikula
2017-11-02 16:11     ` Ville Syrjälä
2017-11-08 10:40       ` Maarten Lankhorst
2017-11-08 11:25         ` Ville Syrjälä
2017-11-21 10:39           ` Maarten Lankhorst
2017-11-21 14:07             ` Ville Syrjälä [this message]
2017-11-02 14:46 ` ✗ Fi.CI.BAT: warning for " Patchwork
2017-11-21 11:51 ` Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2018-03-08 18:34 [PATCH] " Maarten Lankhorst

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=20171121140743.GA10981@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=tomi.p.sarvela@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