From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754254AbdEHBwT (ORCPT ); Sun, 7 May 2017 21:52:19 -0400 Received: from mail-pf0-f180.google.com ([209.85.192.180]:34339 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751185AbdEHBwR (ORCPT ); Sun, 7 May 2017 21:52:17 -0400 Subject: Re: [PATCH] drm/i915: Make vblank evade warnings optional To: Daniel Vetter References: <20170507171252.5149-1-ville.syrjala@linux.intel.com> <3c44fef6-751a-b322-3b84-eef192012606@kernel.dk> Cc: "Syrjala, Ville" , intel-gfx , dri-devel , Linux Kernel Mailing List , Jani Nikula , Dave Airlie , Linus Torvalds , Maarten Lankhorst From: Jens Axboe Message-ID: Date: Sun, 7 May 2017 19:52:14 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/07/2017 11:56 AM, Daniel Vetter wrote: > On Sun, May 7, 2017 at 7:46 PM, Jens Axboe wrote: >> On 05/07/2017 11:12 AM, ville.syrjala@linux.intel.com wrote: >>> From: Ville Syrjälä >>> >>> Add a new Kconfig option to enable/disable the extra warnings >>> from the vblank evade code. For now we'll keep the warning >>> about an actually missed vblank always enabled as that can have >>> an actual user visible impact. But if we miss the deadline >>> othrwise there's no real need to bother the user with that. >>> We'll want these warnings enabled during development however >>> so that we can catch regressions. >>> >>> Based on the reports it looks like this is still very easy >>> to hit on SKL, so we have more work ahead of us to optimize >>> the crtiical section further. >> >> Shouldn't it just be a debug printk or something instead, so that normal >> people don't see it, but the folks that turn on debugging can get the >> info they need? Seems silly to add a kconfig option for this. > > I guess we could keep it as debug for users, but we want to make this > a hard failure on our CI machines. Kconfig knob is the easiest to roll > out to all machines. Wouldn't a module parameter be more useful then, as an opt-in to catch these violations. Nobody is going to know wtf to set this kconfig option to. -- Jens Axboe