Message ID | 20231103201831.1037416-1-andriy.shevchenko@linux.intel.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:8f47:0:b0:403:3b70:6f57 with SMTP id j7csp1291878vqu; Fri, 3 Nov 2023 13:19:05 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEyYnvNwDVAcrHK7I2UxFOIaNjlJY9/kB05eNttZgP5wscG7xgMxgYhJQSIv6Z6I+D6G57f X-Received: by 2002:a17:902:e549:b0:1cc:6308:9262 with SMTP id n9-20020a170902e54900b001cc63089262mr14745067plf.15.1699042745528; Fri, 03 Nov 2023 13:19:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1699042745; cv=none; d=google.com; s=arc-20160816; b=DQR8I9qJkKhHhnG/fBU0tdBMKgru+8LLgXzdZ8KVnQd2bCngVwPAiFkUDeb9Iy7ddb gyJ6rHO46SwZod2EvNAW+/rzV6DMgv2/ZR/wnbRz1KYzpHZIgJdFWs2Jag8iYrQnBayw UYxlndieheDa143XmTt/44jySnlszU8gcMepwjWA8b8q4DQydQYlH2WXi3V8Awn46TJp qSUu7x3Fyhhr2vDaiwaXZ+yD0wkPWu+YrL4s/E+vuA/DrmnU1Dv1niwSPq6+mnAVE0Ww XChEtEnOnJ5DoQ1S5En59n0PY7wuXmvG7RXLeqEsuj7/x93SLDy4oyjhw284zblTxf7j S56w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=ZuwgrvzZD2/zoO/0mgMSXrkAtz95FbBJfhn1obQqbLU=; fh=W9Apx1mxfI4Sn4Tfu/ApINr5FKslMaF8Hy7vCgvNWsQ=; b=S9kZFfUUR2aEs1HtDpFklV8uS4Es+rAbXDmpsIW/cXCdHEJqaRw6gkXQTIMSVumih0 a+ONnUBixBQwZ/F3eWG5lGm1Pym+4y0ZD2VUY+jnxxo/K7LmQ7DHincz+DuN7RRFHavV 46HG/uBvEvQT3wWx6DYp5sesXYxix8oLNR4KVSXfbJq1CnkhGVVANeFvkC0v+38DSlz6 756GLQnkFL2PKq/hrKw2+022HMDdq/GiKac/QDrudF5u6YWsGKJ5k6ZZ3nnB3CTBu16P FtjxTN13WEYi7uuouQ87OoxzwFzYWUZcuxQuU/ZYAoazQAMNnW0uCpzp9+fnowQHbpgJ DS/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=QqJ5NcbF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id n1-20020a170903404100b001bdd0d0530dsi2103674pla.129.2023.11.03.13.19.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Nov 2023 13:19:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=QqJ5NcbF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 42A65802C591; Fri, 3 Nov 2023 13:18:56 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378207AbjKCUSv (ORCPT <rfc822;heyuhang3455@gmail.com> + 35 others); Fri, 3 Nov 2023 16:18:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378015AbjKCUSo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 3 Nov 2023 16:18:44 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8B92D63 for <linux-kernel@vger.kernel.org>; Fri, 3 Nov 2023 13:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699042721; x=1730578721; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=SsqYwVa3nj+KQxx6klaIUKyb/YVe7UbmMNumzB/z7A8=; b=QqJ5NcbFNLVQi57O5tc2vcAWGE/fqTRq8N5kVDAKPTTF4GmThOgf6x4w N5gjcxcvskOgUX+AAXovO80DSiRLaz46Ts5d/sdZ/2mYy6mmRq8Ax422Z Ng8fteM7mYfn66devWSrDdbDBB6YbPgA3D7P72Z6iHk5SeMhVLerZV3Ul KVDPEVE5k5yPyqZYkI3WVWdAPNStU12rOeFMdUB3n9xikLHjmOn06in4X 3FFgKFWG4OjdhtiauJ2J/RoiI2Ku3NkD+x/yLGQ5E5NOUsYNRCBC++SnJ hJ/dJQ2VKNb/oBlibaLqGLgoZwU0HdSR6OHYONZaRYaER6ZTVuk362kGd A==; X-IronPort-AV: E=McAfee;i="6600,9927,10883"; a="387904504" X-IronPort-AV: E=Sophos;i="6.03,275,1694761200"; d="scan'208";a="387904504" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2023 13:18:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10883"; a="885303649" X-IronPort-AV: E=Sophos;i="6.03,275,1694761200"; d="scan'208";a="885303649" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga004.jf.intel.com with ESMTP; 03 Nov 2023 13:18:34 -0700 Received: by black.fi.intel.com (Postfix, from userid 1003) id 8B4795E2; Fri, 3 Nov 2023 22:18:33 +0200 (EET) From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Jani Nikula <jani.nikula@intel.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Jani Nikula <jani.nikula@linux.intel.com>, Joonas Lahtinen <joonas.lahtinen@linux.intel.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Hans de Goede <hdegoede@redhat.com> Subject: [rft, PATCH v4 00/16] drm/i915/dsi: 4th attempt to get rid of IOSF GPIO Date: Fri, 3 Nov 2023 22:18:15 +0200 Message-Id: <20231103201831.1037416-1-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.40.0.1.gaa8946217a0b MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Fri, 03 Nov 2023 13:19:04 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781575445759447420 X-GMAIL-MSGID: 1781575445759447420 |
Series |
drm/i915/dsi: 4th attempt to get rid of IOSF GPIO
|
|
Message
Andy Shevchenko
Nov. 3, 2023, 8:18 p.m. UTC
DSI code for VBT has a set of ugly GPIO hacks, one of which is direct talking to GPIO IP behind the actual driver's back. A second attempt to fix that is here. If I understood correctly, my approach should work in the similar way as the current IOSF GPIO. Hans, I believe you have some devices that use this piece of code, is it possible to give a test run on (one of) them? In v4: - fixed compile time errors in patch 14 (Hans, LKP) - fixed cover letter Subject - added patch 15 (as suggested by Ville) - added Ack tag (Jani) In v3: - incorporated series by Jani - incorporated couple of precursor patches by Hans - added Rb tag for used to be first three patches (Andi) - rebased on top of the above changes - fixed indexing for multi-community devices, such as Cherry View In v2: - added a few cleanup patches - reworked to use dynamic GPIO lookup tables - converted CHV as well Andy Shevchenko (9): drm/i915/dsi: Replace while(1) with one with clear exit condition drm/i915/dsi: Get rid of redundant 'else' drm/i915/dsi: Replace check with a (missing) MIPI sequence name drm/i915/dsi: Extract common soc_gpio_set_value() helper drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back drm/i915/dsi: Prepare soc_gpio_set_value() to distinguish GPIO communities drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back drm/i915/dsi: Combine checks in mipi_exec_gpio() drm/i915/iosf: Drop unused APIs Hans de Goede (2): drm/i915/dsi: Remove GPIO lookup table at the end of intel_dsi_vbt_gpio_init() drm/i915/dsi: Fix wrong initial value for GPIOs in bxt_gpio_set_value() Jani Nikula (5): drm/i915/dsi: assume BXT gpio works for non-native GPIO drm/i915/dsi: switch mipi_exec_gpio() from dev_priv to i915 drm/i915/dsi: clarify GPIO exec sequence drm/i915/dsi: rename platform specific *_exec_gpio() to *_gpio_set_value() drm/i915/dsi: bxt/icl GPIO set value do not need gpio source drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 355 +++++++------------ drivers/gpu/drm/i915/vlv_sideband.c | 17 - drivers/gpu/drm/i915/vlv_sideband.h | 3 - 3 files changed, 136 insertions(+), 239 deletions(-)
Comments
Hi, On 11/3/23 21:18, Andy Shevchenko wrote: > DSI code for VBT has a set of ugly GPIO hacks, one of which is direct > talking to GPIO IP behind the actual driver's back. A second attempt > to fix that is here. > > If I understood correctly, my approach should work in the similar way as > the current IOSF GPIO. > > Hans, I believe you have some devices that use this piece of code, > is it possible to give a test run on (one of) them? Ok, this now has been testen on both a BYT and a CHT device which actually use GPIO controls in their MIPI sequences so this series is: Tested-by: Hans de Goede <hdegoede@redhat.com> And the code of the entire series also looks good to me: Reviewed-by: Hans de Goede <hdegoede@redhat.com> for the series. Regards, Hans > In v4: > - fixed compile time errors in patch 14 (Hans, LKP) > - fixed cover letter Subject > - added patch 15 (as suggested by Ville) > - added Ack tag (Jani) > > In v3: > - incorporated series by Jani > - incorporated couple of precursor patches by Hans > - added Rb tag for used to be first three patches (Andi) > - rebased on top of the above changes > - fixed indexing for multi-community devices, such as Cherry View > > In v2: > - added a few cleanup patches > - reworked to use dynamic GPIO lookup tables > - converted CHV as well > > Andy Shevchenko (9): > drm/i915/dsi: Replace while(1) with one with clear exit condition > drm/i915/dsi: Get rid of redundant 'else' > drm/i915/dsi: Replace check with a (missing) MIPI sequence name > drm/i915/dsi: Extract common soc_gpio_set_value() helper > drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back > drm/i915/dsi: Prepare soc_gpio_set_value() to distinguish GPIO > communities > drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back > drm/i915/dsi: Combine checks in mipi_exec_gpio() > drm/i915/iosf: Drop unused APIs > > Hans de Goede (2): > drm/i915/dsi: Remove GPIO lookup table at the end of > intel_dsi_vbt_gpio_init() > drm/i915/dsi: Fix wrong initial value for GPIOs in > bxt_gpio_set_value() > > Jani Nikula (5): > drm/i915/dsi: assume BXT gpio works for non-native GPIO > drm/i915/dsi: switch mipi_exec_gpio() from dev_priv to i915 > drm/i915/dsi: clarify GPIO exec sequence > drm/i915/dsi: rename platform specific *_exec_gpio() to > *_gpio_set_value() > drm/i915/dsi: bxt/icl GPIO set value do not need gpio source > > drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 355 +++++++------------ > drivers/gpu/drm/i915/vlv_sideband.c | 17 - > drivers/gpu/drm/i915/vlv_sideband.h | 3 - > 3 files changed, 136 insertions(+), 239 deletions(-) >
On Thu, 16 Nov 2023, Hans de Goede <hdegoede@redhat.com> wrote: > Ok, this now has been testen on both a BYT and a CHT device which > actually use GPIO controls in their MIPI sequences so this > series is: > > Tested-by: Hans de Goede <hdegoede@redhat.com> > > And the code of the entire series also looks good to me: > > Reviewed-by: Hans de Goede <hdegoede@redhat.com> > > for the series. Thanks Andy & Hans! I'll merge this once the test results are in. The BAT results have been a bit flaky recently, so needed to do a rerun. That said, I'm not sure if we have any hardware in CI that would actually exercise the modifications, so in that sense I trust Hans' testing much more. BR, Jani.
On Thu, Nov 16, 2023 at 12:15:03PM +0200, Jani Nikula wrote: > On Thu, 16 Nov 2023, Hans de Goede <hdegoede@redhat.com> wrote: > > Ok, this now has been testen on both a BYT and a CHT device which > > actually use GPIO controls in their MIPI sequences so this > > series is: > > > > Tested-by: Hans de Goede <hdegoede@redhat.com> > > > > And the code of the entire series also looks good to me: > > > > Reviewed-by: Hans de Goede <hdegoede@redhat.com> > > > > for the series. > > Thanks Andy & Hans! > > I'll merge this once the test results are in. The BAT results have been > a bit flaky recently, so needed to do a rerun. > > That said, I'm not sure if we have any hardware in CI that would > actually exercise the modifications, so in that sense I trust Hans' > testing much more. Thank you! Should I fix checkpatch warnings CI reported about?
On Thu, Nov 16, 2023 at 09:58:06AM +0100, Hans de Goede wrote: > On 11/3/23 21:18, Andy Shevchenko wrote: > > DSI code for VBT has a set of ugly GPIO hacks, one of which is direct > > talking to GPIO IP behind the actual driver's back. A second attempt > > to fix that is here. > > > > If I understood correctly, my approach should work in the similar way as > > the current IOSF GPIO. > > > > Hans, I believe you have some devices that use this piece of code, > > is it possible to give a test run on (one of) them? > > Ok, this now has been testen on both a BYT and a CHT device which > actually use GPIO controls in their MIPI sequences so this > series is: > > Tested-by: Hans de Goede <hdegoede@redhat.com> > > And the code of the entire series also looks good to me: > > Reviewed-by: Hans de Goede <hdegoede@redhat.com> > > for the series. Good news so far, thank you!
On Fri, 17 Nov 2023, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Thu, Nov 16, 2023 at 12:15:03PM +0200, Jani Nikula wrote: >> On Thu, 16 Nov 2023, Hans de Goede <hdegoede@redhat.com> wrote: >> > Ok, this now has been testen on both a BYT and a CHT device which >> > actually use GPIO controls in their MIPI sequences so this >> > series is: >> > >> > Tested-by: Hans de Goede <hdegoede@redhat.com> >> > >> > And the code of the entire series also looks good to me: >> > >> > Reviewed-by: Hans de Goede <hdegoede@redhat.com> >> > >> > for the series. >> >> Thanks Andy & Hans! >> >> I'll merge this once the test results are in. The BAT results have been >> a bit flaky recently, so needed to do a rerun. >> >> That said, I'm not sure if we have any hardware in CI that would >> actually exercise the modifications, so in that sense I trust Hans' >> testing much more. > > Thank you! > Should I fix checkpatch warnings CI reported about? Nah, they're benign. BR, Jani.