From patchwork Fri Jul 14 21:35:14 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 9841707 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 81ED460381 for ; Fri, 14 Jul 2017 21:35:18 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 72040287C0 for ; Fri, 14 Jul 2017 21:35:18 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 64E95287C7; Fri, 14 Jul 2017 21:35:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id E7D1C287C0 for ; Fri, 14 Jul 2017 21:35:17 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 805976E7F5; Fri, 14 Jul 2017 21:35:16 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) by gabe.freedesktop.org (Postfix) with ESMTPS id A94DB6E826 for ; Fri, 14 Jul 2017 21:35:15 +0000 (UTC) Received: by mail-io0-x244.google.com with SMTP id h134so3271904iof.3 for ; Fri, 14 Jul 2017 14:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=RhR39RaLi+aBEIEezDb0JMdQMMKj7w/Qb6g2b9Tmp0g=; b=IyFWloTJQYvLY7YA35/Fn/v9vIlU/uuMlWC5Tx/axPile+0O7UMFn24lAcbiYXj9eF moK9FEypOXaIw81E2+94CUYReKDk7C1d78N5bgRu4C3hwhBfMcUnMEg1YjVgegCgrIjJ nFQRqSu5c/Ipf5otseljac4nEYAIEVnzVbByk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=RhR39RaLi+aBEIEezDb0JMdQMMKj7w/Qb6g2b9Tmp0g=; b=Q/VAo+WjaeH5IzbDseS0QHshC/AzIGv5LwV1jI8hlfSdgE6Uieqsfbt32SDzw6Y0c7 ot00ozwgK9syK2zTGs4dqUSlcNjvQBWVX/RZKONDMDoJz8ZQS6WUD6xc7/zHiiQAqc9q N24Py60dkUACehhG/Rw7rAE4usnITZPJ1uN2L572JHaCXivp5UQXDiVih+/tnDemiiC6 ArtHnyV5uAAMjwZc7upcLeH3jOnjTpnkNM/xYYoCqQSfbPOiqJda2aQVrBtbGuNYfyrD XAZ6pspwhZGbeT1zWNDa4JpRxS7T1gaC67HIb5YUuRO1NCt3ZFeIPVhZ2O0H0ow1186J 4SjA== X-Gm-Message-State: AIVw113k3o7LWX++mV/M30qqkfAB0Y0RVx2sB2Viav1TbxJ+gJSBRgYp G+oNw8y9PSl75gdZr+A6RJpk6W/9oix7 X-Received: by 10.107.6.23 with SMTP id 23mr9915810iog.122.1500068114900; Fri, 14 Jul 2017 14:35:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.7.20 with HTTP; Fri, 14 Jul 2017 14:35:14 -0700 (PDT) X-Originating-IP: [2a02:168:5640:0:960b:2678:e223:c1c6] In-Reply-To: References: <20170420215605.176722-1-mka@chromium.org> <20170505172636.GA128305@google.com> <20170505174043.GK12629@intel.com> <20170713101351.GS12629@intel.com> <20170713174232.GK12629@intel.com> <87eftjl6xg.fsf@nikula.org> From: Daniel Vetter Date: Fri, 14 Jul 2017 23:35:14 +0200 X-Google-Sender-Auth: NoHNnpPWZruAeKG6sWiFmUM91-Y Message-ID: To: Grant Grundler Cc: intel-gfx , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" , Michael Davidson , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Matthias Kaehlcke , Daniel Vetter Subject: Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler wrote: > On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula > wrote: >> On Thu, 13 Jul 2017, Stéphane Marchesin wrote: >>> So, if you think this is wrong, can you fix this warning in a way that >>> you'd like? >> >> As I replied previously [1], with more background, fixing the warnings >> properly, in a way that actually improves the code instead of making it >> worse, would mean a bunch of churn that's not just purely mechanical >> conversion. > > That's fair. > >> Unless you can point out a bug which is actually caused by mixing the >> types (which is mostly intentional, see the background) I have a hard >> time telling people this should be a priority. > > This feels like "can't see the forest because of the trees". > > The original patch was submitted in order to compile cleanly using > clang and the above suggests using clang is not important. Using > clang is important to Matthias and the Chrome OS organization for many > good reasons - including better warnings. > > The original patch message was clear that clang was generating the > warning. This isn't the only patch mka has sent to kernel devs. What > one can infer is Chrome OS is trying to move to clang (like other > Google products _already_ have.) My impression is all these products > are a priority to Intel - but it would be good to know otherwise. > >> Definitely something we'd >> like to do in the long run and pedantically correct (and I tend to >> prefer code that way) but we certainly have more important things to do. > > The long run is now. Everyone agrees the code should change and you > don't have to do it. Matthias submitted an unacceptable patch and > giving him some concrete guidance on what would be acceptable would > enable him to implement/test it (or anyone else could for that > matter). Can you do that? > > Just give an example of what the "right" API looks like and see where it goes. We've replied and discussed on May 5th what that roughly should be, right when Matthias pinged us. The original submission unfortunately fell through the cracks (it happens, not much we can do with this flood). Matthias didn't seem to have any questions about the proposed solutions (we laid out both the minimal short-term fix to unconfuse things, and what might be done on top), I think a reasonable assumption was that it's all clear. Otherwise he should have asked. Now, over 2 months later (and complete silence from your side) there's suddenly mass panic and multiple escalations on all available channels, which feels like a rather decent overreaction and not a terrible constructive way to collaborate on the upstream codebase. Anyway, I've done the quick draft for the function declaration changes that would clear up the confusion, just needs a clang run to update all the parameters to match, and passed that on to Stéphane Marchesin. I expect you to follow up with the corresponding patch right away. Thanks a lot. Yours, Daniel For reference the diff, but probably whitespace mangled because the real machine is down already: struct intel_crtc *crtc = @@ -390,7 +390,7 @@ void intel_cpu_fifo_underrun_irq_handler(struct drm_i915_private *dev_priv, * interrupt to avoid an irq storm. */ void intel_pch_fifo_underrun_irq_handler(struct drm_i915_private *dev_priv, - enum transcoder pch_transcoder) + enum pipe pch_transcoder) { if (intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder, false)) { diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c b/drivers/gpu/drm/i915/intel_fifo_underrun.c index d484862cc7df..21c221b4ae57 100644 --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c @@ -313,7 +313,7 @@ bool intel_set_cpu_fifo_underrun_reporting(struct drm_i915_private *dev_priv, * Returns the previous state of underrun reporting. */ bool intel_set_pch_fifo_underrun_reporting(struct drm_i915_private *dev_priv, - enum transcoder pch_transcoder, + enum pipe pch_transcoder, bool enable) {