From patchwork Fri Jun 9 09:18:08 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andy Shevchenko X-Patchwork-Id: 773743 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3wkcJk4h8mz9s8N for ; Fri, 9 Jun 2017 19:22:46 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751543AbdFIJWp (ORCPT ); Fri, 9 Jun 2017 05:22:45 -0400 Received: from mga11.intel.com ([192.55.52.93]:40039 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751528AbdFIJWn (ORCPT ); Fri, 9 Jun 2017 05:22:43 -0400 Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2017 02:22:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,317,1493708400"; d="scan'208";a="978725003" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by orsmga003.jf.intel.com with ESMTP; 09 Jun 2017 02:22:39 -0700 Message-ID: <1496999888.22624.75.camel@linux.intel.com> Subject: Re: [PATCH v6] platform/x86: Add driver for ACPI INT0002 Virtual GPIO device From: Andy Shevchenko To: Linus Walleij , Hans de Goede Cc: "Rafael J . Wysocki" , Darren Hart , Alexandre Courbot , ACPI Devel Maling List , platform-driver-x86 , "linux-gpio@vger.kernel.org" , joeyli , Takashi Iwai Date: Fri, 09 Jun 2017 12:18:08 +0300 In-Reply-To: References: <20170602151507.22391-1-hdegoede@redhat.com> <20170602151507.22391-2-hdegoede@redhat.com> Organization: Intel Finland Oy X-Mailer: Evolution 3.22.6-1 Mime-Version: 1.0 Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Fri, 2017-06-09 at 11:02 +0200, Linus Walleij wrote: > On Fri, Jun 2, 2017 at 5:15 PM, Hans de Goede > wrote: > > > Some peripherals on Bay Trail and Cherry Trail platforms signal a > > Power Management Event (PME) to the Power Management Controller > > (PMC) > > to wakeup the system. When this happens software needs to explicitly > > clear the PME bus 0 status bit in the GPE0a_STS register to avoid an > > IRQ storm on IRQ 9. > > > > This is modelled in ACPI through the INT0002 ACPI device, which is > > called a "Virtual GPIO controller" in ACPI because it defines the > > event handler to call when the PME triggers through _AEI and _L02 > > methods as would be done for a real GPIO interrupt in ACPI. > > > > This commit adds a driver which registers the Virtual GPIOs expected > > by the DSDT on these devices, letting gpiolib-acpi claim the > > virtual GPIO and install a GPIO-interrupt handler which call the > > _L02 > > handler as it would for a real GPIO controller. > > > > Cc: joeyli > > Cc: Takashi Iwai > > Signed-off-by: Hans de Goede > > Reviewed-by: Andy Shevchenko > > Acked-by: Rafael J. Wysocki > > --- > > Changes in v2: > > -Remove dev_err after malloc failure > > -Remove unused empty runtime pm callbacks > > -s/GPE0A_PME_/GPE0A_PME_B0_/ > > -Fixed some checkpatch warnings (I forgot to run checkpatch on v1) > > Changes in v3: > > -Rewrite as gpiochip driver letting gpiolib-acpi deal with claiming > > the pin > >  0x0002 and calling the _L02 event handler when the virtual gpio-irq > > triggers > > -Rebase on 4.12-rc1 > > Changes in v4: > > -Drop device_init_wakeup() from _probe(), use pm_system_wakeup() > > instead > >  of pm_wakeup_hard_event(chip->parent) > > -Improve commit message > > Changes in v5: > > -Use BIT() macro for FOO_BIT defines > > -Drop unneeded ACPI_PTR macro usage > > Changes in v6: > > -Move back to drivers/platform/x86 > > -Expand certain acronyms (PME, PMC) > > -Use linux/gpio/driver.h include instead of linux/gpio.h > > -Document why the get / set / direction_output functions are dummys > > -No functional changes > > Reviewed-by: Linus Walleij > > With Andy's changes. Oops, when I removed this from PDx86 testing branch I removed my changes together. Here they are (Hans, perhaps you may resend with them included) 2 */ @@ -66,7 +68,7 @@ static const struct x86_cpu_id int0002_cpu_ids[] = {  /*   * As this is not a real GPIO at all, but just a hack to model an event in - * APCI the get / set functions are dummy functions. + * ACPI the get / set functions are dummy functions.   */  static int int0002_gpio_get(struct gpio_chip *chip, unsigned int offset) @@ -137,7 +139,7 @@ static int int0002_probe(struct platform_device *pdev)         struct device *dev = &pdev->dev;         const struct x86_cpu_id *cpu_id;         struct gpio_chip *chip; -       int i, irq, ret; +       int irq, ret;         /* Menlow has a different INT0002 device? */         cpu_id = x86_match_cpu(int0002_cpu_ids); @@ -171,8 +173,7 @@ static int int0002_probe(struct platform_device *pdev)                 return ret;         } -       for (i = 0; i < GPE0A_PME_B0_VIRT_GPIO_PIN; i++) -               clear_bit(i, chip->irq_valid_mask); +       bitmap_clear(chip->irq_valid_mask, 0, GPE0A_PME_B0_VIRT_GPIO_PIN);         /*          * We manually request the irq here instead of passing a flow- handler > > Please feel free to push this upstream through the platform tree > or similar. > > Yours, > Linus Walleij --- a/drivers/platform/x86/intel_int0002_vgpio.c +++ b/drivers/platform/x86/intel_int0002_vgpio.c @@ -30,9 +30,8 @@   * for a real GPIO controller.   */ -#include -#include  #include +#include  #include  #include  #include @@ -42,6 +41,9 @@  #include  #include    +#include +#include +  #define DRV_NAME                       "INT0002 Virtual GPIO"  /* For some reason the virtual GPIO pin tied to the GPE is numbered pin