* Re: [PATCH v8 11/21] clk: tegra: clk-dfll: Add suspend and resume support
From: Sowjanya Komatineni @ 2019-08-09 18:33 UTC (permalink / raw)
To: Dmitry Osipenko, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree, rjw, viresh.kumar, linux-pm
In-Reply-To: <84a0d46a-bca2-1000-a2a6-8890ee702dd3@gmail.com>
On 8/9/19 11:00 AM, Dmitry Osipenko wrote:
> 09.08.2019 19:39, Sowjanya Komatineni пишет:
>> On 8/9/19 5:23 AM, Dmitry Osipenko wrote:
>>> 09.08.2019 2:46, Sowjanya Komatineni пишет:
>>>> This patch implements DFLL suspend and resume operation.
>>>>
>>>> During system suspend entry, CPU clock will switch CPU to safe
>>>> clock source of PLLP and disables DFLL clock output.
>>>>
>>>> DFLL driver suspend confirms DFLL disable state and errors out on
>>>> being active.
>>>>
>>>> DFLL is re-initialized during the DFLL driver resume as it goes
>>>> through complete reset during suspend entry.
>>>>
>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>> ---
>>>> drivers/clk/tegra/clk-dfll.c | 56 ++++++++++++++++++++++++++++++
>>>> drivers/clk/tegra/clk-dfll.h | 2 ++
>>>> drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 1 +
>>>> 3 files changed, 59 insertions(+)
>>>>
>>>> diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
>>>> index f8688c2ddf1a..eb298a5d7be9 100644
>>>> --- a/drivers/clk/tegra/clk-dfll.c
>>>> +++ b/drivers/clk/tegra/clk-dfll.c
>>>> @@ -1487,6 +1487,7 @@ static int dfll_init(struct tegra_dfll *td)
>>>> td->last_unrounded_rate = 0;
>>>> pm_runtime_enable(td->dev);
>>>> + pm_runtime_irq_safe(td->dev);
>>>> pm_runtime_get_sync(td->dev);
>>>> dfll_set_mode(td, DFLL_DISABLED);
>>>> @@ -1513,6 +1514,61 @@ static int dfll_init(struct tegra_dfll *td)
>>>> return ret;
>>>> }
>>>> +/**
>>>> + * tegra_dfll_suspend - check DFLL is disabled
>>>> + * @dev: DFLL device *
>>>> + *
>>>> + * DFLL clock should be disabled by the CPUFreq driver. So, make
>>>> + * sure it is disabled and disable all clocks needed by the DFLL.
>>>> + */
>>>> +int tegra_dfll_suspend(struct device *dev)
>>>> +{
>>>> + struct tegra_dfll *td = dev_get_drvdata(dev);
>>>> +
>>>> + if (dfll_is_running(td)) {
>>>> + dev_err(td->dev, "dfll is enabled while shouldn't be\n");
>>>> + return -EBUSY;
>>>> + }
>>>> +
>>>> + reset_control_assert(td->dvco_rst);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +EXPORT_SYMBOL(tegra_dfll_suspend);
>>>> +
>>>> +/**
>>>> + * tegra_dfll_resume - reinitialize DFLL on resume
>>>> + * @dev: DFLL instance
>>>> + *
>>>> + * DFLL is disabled and reset during suspend and resume.
>>>> + * So, reinitialize the DFLL IP block back for use.
>>>> + * DFLL clock is enabled later in closed loop mode by CPUFreq
>>>> + * driver before switching its clock source to DFLL output.
>>>> + */
>>>> +int tegra_dfll_resume(struct device *dev)
>>>> +{
>>>> + struct tegra_dfll *td = dev_get_drvdata(dev);
>>>> +
>>>> + reset_control_deassert(td->dvco_rst);
>>> This doesn't look right because I assume that DFLL resetting is
>>> synchronous and thus clk should be enabled in order for reset to
>>> propagate inside hardware.
>>>
>>>> + pm_runtime_get_sync(td->dev);
>>> Hence it will be better to remove the above reset_control_deassert() and
>>> add here:
>>>
>>> reset_control_reset(td->dvco_rst);
>> By the time dfll resume happens, dfll controller clock will already be enabled.
>>
>> so doing reset de-assert before pm_runtime seems ok.
> I don't see what enables the DFLL clock because it should be enabled by the CPUFreq driver
> on resume from suspend and resume happens after resuming of the DFLL driver.
dvco_rst is part of peripheral clocks and all peripheral clocks are
restored by clk-tegra210 driver which happens before dfll driver resume.
So dfll rst thru part of peripheral clock enable is set prior to dfll
reset deassertion
^ permalink raw reply
* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
From: Dan Williams @ 2019-08-09 18:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: soc, Russell King, Vinod Koul, Linus Walleij, Bartosz Golaszewski,
linux-arm-kernel, Linux Kernel Mailing List, dmaengine,
linux-gpio, linux-i2c, Martin Michlmayr
In-Reply-To: <20190809163334.489360-1-arnd@arndb.de>
[ add Martin (if cyrius.com address is still valid) ]
On Fri, Aug 9, 2019 at 9:35 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> There are three families of IOP machines we support in Linux: iop32x
> (which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x).
>
> All products we support in the kernel are based on the first of these,
> iop32x, the other families only ever supported the Intel reference
> boards but no actual machine anyone could ever buy.
>
> While one could clearly make them all three work in a single kernel
> with some work, this takes the easy way out, removing the later two
> platforms entirely, under the assumption that there are no remaining
> users.
>
> Earlier versions of OpenWRT and Debian both had support for iop32x
> but not the others, and they both dropped iop32x as well in their 2015
> releases.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> I'm just guessing that iop32x is still needed, and the other two are
> not. If anyone disagrees with that assessment, let me know so we
> can come up with an alternative approach.
I'm not sure who would scream if iop32x support went away as well, but
I have not followed this space in years hence copying Martin.
In any event:
Acked-by: Dan Williams <dan.j.williams@intel.com>
^ permalink raw reply
* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
From: Russell King - ARM Linux admin @ 2019-08-09 18:36 UTC (permalink / raw)
To: Dan Williams
Cc: Arnd Bergmann, soc, Vinod Koul, Linus Walleij,
Bartosz Golaszewski, linux-arm-kernel, Linux Kernel Mailing List,
dmaengine, linux-gpio, linux-i2c, Martin Michlmayr
In-Reply-To: <CAA9_cmdDbBm0ookyqGJMcyLVFHkYHuR3mEeawQKS2UqYJoWWaQ@mail.gmail.com>
On Fri, Aug 09, 2019 at 11:34:12AM -0700, Dan Williams wrote:
> [ add Martin (if cyrius.com address is still valid) ]
>
> On Fri, Aug 9, 2019 at 9:35 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > There are three families of IOP machines we support in Linux: iop32x
> > (which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x).
> >
> > All products we support in the kernel are based on the first of these,
> > iop32x, the other families only ever supported the Intel reference
> > boards but no actual machine anyone could ever buy.
> >
> > While one could clearly make them all three work in a single kernel
> > with some work, this takes the easy way out, removing the later two
> > platforms entirely, under the assumption that there are no remaining
> > users.
> >
> > Earlier versions of OpenWRT and Debian both had support for iop32x
> > but not the others, and they both dropped iop32x as well in their 2015
> > releases.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > I'm just guessing that iop32x is still needed, and the other two are
> > not. If anyone disagrees with that assessment, let me know so we
> > can come up with an alternative approach.
>
> I'm not sure who would scream if iop32x support went away as well, but
> I have not followed this space in years hence copying Martin.
>
> In any event:
>
> Acked-by: Dan Williams <dan.j.williams@intel.com>
Those of us who have and still run Thecus N2100's, for example?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH v8 05/21] clk: tegra: pll: Save and restore pll context
From: Sowjanya Komatineni @ 2019-08-09 18:50 UTC (permalink / raw)
To: Dmitry Osipenko, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree, rjw, viresh.kumar, linux-pm
In-Reply-To: <2eecf4ff-802d-7e0e-d971-0257fae4e3a2@gmail.com>
On 8/9/19 10:50 AM, Dmitry Osipenko wrote:
> 09.08.2019 20:39, Sowjanya Komatineni пишет:
>> On 8/9/19 4:33 AM, Dmitry Osipenko wrote:
>>> 09.08.2019 2:46, Sowjanya Komatineni пишет:
>>>> This patch implements save and restore of PLL context.
>>>>
>>>> During system suspend, core power goes off and looses the settings
>>>> of the Tegra CAR controller registers.
>>>>
>>>> So during suspend entry pll context is stored and on resume it is
>>>> restored back along with its state.
>>>>
>>>> Acked-by: Thierry Reding <treding@nvidia.com>
>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>> ---
>>>> drivers/clk/tegra/clk-pll.c | 88 ++++++++++++++++++++++++++++-----------------
>>>> drivers/clk/tegra/clk.h | 2 ++
>>>> 2 files changed, 58 insertions(+), 32 deletions(-)
>>>>
>>>> diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
>>>> index 1583f5fc992f..e52add2bbdbb 100644
>>>> --- a/drivers/clk/tegra/clk-pll.c
>>>> +++ b/drivers/clk/tegra/clk-pll.c
>>>> @@ -1008,6 +1008,28 @@ static unsigned long clk_plle_recalc_rate(struct clk_hw *hw,
>>>> return rate;
>>>> }
>>>> +static void tegra_clk_pll_restore_context(struct clk_hw *hw)
>>>> +{
>>>> + struct tegra_clk_pll *pll = to_clk_pll(hw);
>>>> + struct clk_hw *parent = clk_hw_get_parent(hw);
>>>> + unsigned long parent_rate = clk_hw_get_rate(parent);
>>>> + unsigned long rate = clk_hw_get_rate(hw);
>>>> + u32 val;
>>>> +
>>>> + if (clk_pll_is_enabled(hw))
>>>> + return;
>>>> +
>>>> + if (pll->params->set_defaults)
>>>> + pll->params->set_defaults(pll);
>>>> +
>>>> + clk_pll_set_rate(hw, rate, parent_rate);
>>>> +
>>>> + if (!__clk_get_enable_count(hw->clk))
>>> What about orphaned clocks? Is enable_count > 0 for them?
>> There are no orphaned pll clocks.
> Sorry, I meant the "clk_ignore_unused".
clocks with CLK_IGNORE_UNUSED are taken care by clk driver.
clk_disable_unused checks for clocks with this flag and if they are not
enabled it will enable them.
So by the time suspend happens enable_count is > 0
^ permalink raw reply
* Re: [PATCH v8 11/21] clk: tegra: clk-dfll: Add suspend and resume support
From: Dmitry Osipenko @ 2019-08-09 18:52 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree, rjw, viresh.kumar, linux-pm
In-Reply-To: <9902aa72-3f18-9840-35ad-137293d2e26c@nvidia.com>
09.08.2019 21:33, Sowjanya Komatineni пишет:
>
> On 8/9/19 11:00 AM, Dmitry Osipenko wrote:
>> 09.08.2019 19:39, Sowjanya Komatineni пишет:
>>> On 8/9/19 5:23 AM, Dmitry Osipenko wrote:
>>>> 09.08.2019 2:46, Sowjanya Komatineni пишет:
>>>>> This patch implements DFLL suspend and resume operation.
>>>>>
>>>>> During system suspend entry, CPU clock will switch CPU to safe
>>>>> clock source of PLLP and disables DFLL clock output.
>>>>>
>>>>> DFLL driver suspend confirms DFLL disable state and errors out on
>>>>> being active.
>>>>>
>>>>> DFLL is re-initialized during the DFLL driver resume as it goes
>>>>> through complete reset during suspend entry.
>>>>>
>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>>> ---
>>>>> drivers/clk/tegra/clk-dfll.c | 56 ++++++++++++++++++++++++++++++
>>>>> drivers/clk/tegra/clk-dfll.h | 2 ++
>>>>> drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 1 +
>>>>> 3 files changed, 59 insertions(+)
>>>>>
>>>>> diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
>>>>> index f8688c2ddf1a..eb298a5d7be9 100644
>>>>> --- a/drivers/clk/tegra/clk-dfll.c
>>>>> +++ b/drivers/clk/tegra/clk-dfll.c
>>>>> @@ -1487,6 +1487,7 @@ static int dfll_init(struct tegra_dfll *td)
>>>>> td->last_unrounded_rate = 0;
>>>>> pm_runtime_enable(td->dev);
>>>>> + pm_runtime_irq_safe(td->dev);
>>>>> pm_runtime_get_sync(td->dev);
>>>>> dfll_set_mode(td, DFLL_DISABLED);
>>>>> @@ -1513,6 +1514,61 @@ static int dfll_init(struct tegra_dfll *td)
>>>>> return ret;
>>>>> }
>>>>> +/**
>>>>> + * tegra_dfll_suspend - check DFLL is disabled
>>>>> + * @dev: DFLL device *
>>>>> + *
>>>>> + * DFLL clock should be disabled by the CPUFreq driver. So, make
>>>>> + * sure it is disabled and disable all clocks needed by the DFLL.
>>>>> + */
>>>>> +int tegra_dfll_suspend(struct device *dev)
>>>>> +{
>>>>> + struct tegra_dfll *td = dev_get_drvdata(dev);
>>>>> +
>>>>> + if (dfll_is_running(td)) {
>>>>> + dev_err(td->dev, "dfll is enabled while shouldn't be\n");
>>>>> + return -EBUSY;
>>>>> + }
>>>>> +
>>>>> + reset_control_assert(td->dvco_rst);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +EXPORT_SYMBOL(tegra_dfll_suspend);
>>>>> +
>>>>> +/**
>>>>> + * tegra_dfll_resume - reinitialize DFLL on resume
>>>>> + * @dev: DFLL instance
>>>>> + *
>>>>> + * DFLL is disabled and reset during suspend and resume.
>>>>> + * So, reinitialize the DFLL IP block back for use.
>>>>> + * DFLL clock is enabled later in closed loop mode by CPUFreq
>>>>> + * driver before switching its clock source to DFLL output.
>>>>> + */
>>>>> +int tegra_dfll_resume(struct device *dev)
>>>>> +{
>>>>> + struct tegra_dfll *td = dev_get_drvdata(dev);
>>>>> +
>>>>> + reset_control_deassert(td->dvco_rst);
>>>> This doesn't look right because I assume that DFLL resetting is
>>>> synchronous and thus clk should be enabled in order for reset to
>>>> propagate inside hardware.
>>>>
>>>>> + pm_runtime_get_sync(td->dev);
>>>> Hence it will be better to remove the above reset_control_deassert() and
>>>> add here:
>>>>
>>>> reset_control_reset(td->dvco_rst);
>>> By the time dfll resume happens, dfll controller clock will already be enabled.
>>>
>>> so doing reset de-assert before pm_runtime seems ok.
>> I don't see what enables the DFLL clock because it should be enabled by the CPUFreq driver
>> on resume from suspend and resume happens after resuming of the DFLL driver.
>
> dvco_rst is part of peripheral clocks and all peripheral clocks are restored by clk-tegra210
> driver which happens before dfll driver resume.
>
> So dfll rst thru part of peripheral clock enable is set prior to dfll reset deassertion
Ah, so that is DVCO resetting and not DFLL, which are different blocks. Looks correct then.
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 1/3] pinctrl: sh-pfc: add new flags into struct sh_pfc_pin_config
From: Simon Horman @ 2019-08-09 18:52 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: linus.walleij, geert+renesas, linux-gpio, linux-renesas-soc
In-Reply-To: <1565245143-15018-2-git-send-email-yoshihiro.shimoda.uh@renesas.com>
On Thu, Aug 08, 2019 at 03:19:01PM +0900, Yoshihiro Shimoda wrote:
> To clean/modify the code up later, this patch just adds new flags
> "mux_set" and "gpio_enabled" into the struct sh_pfc_pin_config.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v2 2/3] pinctrl: sh-pfc: remove incomplete flag "cfg->type"
From: Simon Horman @ 2019-08-09 18:52 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: linus.walleij, geert+renesas, linux-gpio, linux-renesas-soc
In-Reply-To: <1565245143-15018-3-git-send-email-yoshihiro.shimoda.uh@renesas.com>
On Thu, Aug 08, 2019 at 03:19:02PM +0900, Yoshihiro Shimoda wrote:
> The old commit c58d9c1b26e3 ("sh-pfc: Implement generic pinconf
> support") broke the cfg->type flag to PINMUX_TYPE_FUNCTION because
> sh_pfc_pinconf_set() didn't call sh_pfc_reconfig_pin().
> Now if we fix the cfg->type condition, it gets worse because:
> - Some drivers might be deferred so that .set_mux() will be called
> multiple times.
> - In such the case, the sh-pfc driver returns -EBUSY even if
> the group is the same, and then that driver fails to probe.
>
> Since the pinctrl subsystem already has such conditions according
> to @set_mux and @gpio_request_enable, this patch just remove
> the incomplete flag from sh-pfc/pinctrl.c.
>
> Fixes: c58d9c1b26e3 ("sh-pfc: Implement generic pinconf support")
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v2 3/3] pinctrl: sh-pfc: Rollback to mux if requires when the gpio is freed
From: Simon Horman @ 2019-08-09 18:52 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: linus.walleij, geert+renesas, linux-gpio, linux-renesas-soc
In-Reply-To: <1565245143-15018-4-git-send-email-yoshihiro.shimoda.uh@renesas.com>
On Thu, Aug 08, 2019 at 03:19:03PM +0900, Yoshihiro Shimoda wrote:
> R-Car PWM controller requires the gpio to output zero duty,
> this patch allows to roll it back from gpio to mux when the gpio
> is freed.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
From: Dan Williams @ 2019-08-09 19:43 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Arnd Bergmann, soc, Vinod Koul, Linus Walleij,
Bartosz Golaszewski, Linux ARM, Linux Kernel Mailing List,
dmaengine, linux-gpio, linux-i2c, Martin Michlmayr
In-Reply-To: <20190809183658.GA13294@shell.armlinux.org.uk>
On Fri, Aug 9, 2019 at 11:37 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Fri, Aug 09, 2019 at 11:34:12AM -0700, Dan Williams wrote:
> > [ add Martin (if cyrius.com address is still valid) ]
> >
> > On Fri, Aug 9, 2019 at 9:35 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > There are three families of IOP machines we support in Linux: iop32x
> > > (which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x).
> > >
> > > All products we support in the kernel are based on the first of these,
> > > iop32x, the other families only ever supported the Intel reference
> > > boards but no actual machine anyone could ever buy.
> > >
> > > While one could clearly make them all three work in a single kernel
> > > with some work, this takes the easy way out, removing the later two
> > > platforms entirely, under the assumption that there are no remaining
> > > users.
> > >
> > > Earlier versions of OpenWRT and Debian both had support for iop32x
> > > but not the others, and they both dropped iop32x as well in their 2015
> > > releases.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > I'm just guessing that iop32x is still needed, and the other two are
> > > not. If anyone disagrees with that assessment, let me know so we
> > > can come up with an alternative approach.
> >
> > I'm not sure who would scream if iop32x support went away as well, but
> > I have not followed this space in years hence copying Martin.
> >
> > In any event:
> >
> > Acked-by: Dan Williams <dan.j.williams@intel.com>
>
> Those of us who have and still run Thecus N2100's, for example?
Nice! Good to hear.
^ permalink raw reply
* [PATCH 03/16] gpio: remove ks8695 driver
From: Arnd Bergmann @ 2019-08-09 20:27 UTC (permalink / raw)
To: soc
Cc: Arnd Bergmann, Linus Walleij, Bartosz Golaszewski, linux-kernel,
linux-gpio
In-Reply-To: <20190809202749.742267-1-arnd@arndb.de>
The platform is getting removed, so there are no remaining
users of this driver.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/gpio/Makefile | 1 -
drivers/gpio/gpio-ks8695.c | 284 -------------------------------------
2 files changed, 285 deletions(-)
delete mode 100644 drivers/gpio/gpio-ks8695.c
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a4e91175c708..65d74084c9b2 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -67,7 +67,6 @@ obj-$(CONFIG_GPIO_IT87) += gpio-it87.o
obj-$(CONFIG_GPIO_IXP4XX) += gpio-ixp4xx.o
obj-$(CONFIG_GPIO_JANZ_TTL) += gpio-janz-ttl.o
obj-$(CONFIG_GPIO_KEMPLD) += gpio-kempld.o
-obj-$(CONFIG_ARCH_KS8695) += gpio-ks8695.o
obj-$(CONFIG_GPIO_LOONGSON1) += gpio-loongson1.o
obj-$(CONFIG_GPIO_LOONGSON) += gpio-loongson.o
obj-$(CONFIG_GPIO_LP3943) += gpio-lp3943.o
diff --git a/drivers/gpio/gpio-ks8695.c b/drivers/gpio/gpio-ks8695.c
deleted file mode 100644
index a0f87c124894..000000000000
--- a/drivers/gpio/gpio-ks8695.c
+++ /dev/null
@@ -1,284 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * arch/arm/mach-ks8695/gpio.c
- *
- * Copyright (C) 2006 Andrew Victor
- * Updated to GPIOLIB, Copyright 2008 Simtec Electronics
- * Daniel Silverstone <dsilvers@simtec.co.uk>
- */
-#include <linux/gpio/driver.h>
-#include <linux/kernel.h>
-#include <linux/mm.h>
-#include <linux/init.h>
-#include <linux/debugfs.h>
-#include <linux/seq_file.h>
-#include <linux/module.h>
-#include <linux/io.h>
-
-#include <mach/hardware.h>
-#include <asm/mach/irq.h>
-
-#include <mach/regs-gpio.h>
-#include <mach/gpio-ks8695.h>
-
-/*
- * Configure a GPIO line for either GPIO function, or its internal
- * function (Interrupt, Timer, etc).
- */
-static void ks8695_gpio_mode(unsigned int pin, short gpio)
-{
- unsigned int enable[] = { IOPC_IOEINT0EN, IOPC_IOEINT1EN, IOPC_IOEINT2EN, IOPC_IOEINT3EN, IOPC_IOTIM0EN, IOPC_IOTIM1EN };
- unsigned long x, flags;
-
- if (pin > KS8695_GPIO_5) /* only GPIO 0..5 have internal functions */
- return;
-
- local_irq_save(flags);
-
- x = __raw_readl(KS8695_GPIO_VA + KS8695_IOPC);
- if (gpio) /* GPIO: set bit to 0 */
- x &= ~enable[pin];
- else /* Internal function: set bit to 1 */
- x |= enable[pin];
- __raw_writel(x, KS8695_GPIO_VA + KS8695_IOPC);
-
- local_irq_restore(flags);
-}
-
-
-static unsigned short gpio_irq[] = { KS8695_IRQ_EXTERN0, KS8695_IRQ_EXTERN1, KS8695_IRQ_EXTERN2, KS8695_IRQ_EXTERN3 };
-
-/*
- * Configure GPIO pin as external interrupt source.
- */
-int ks8695_gpio_interrupt(unsigned int pin, unsigned int type)
-{
- unsigned long x, flags;
-
- if (pin > KS8695_GPIO_3) /* only GPIO 0..3 can generate IRQ */
- return -EINVAL;
-
- local_irq_save(flags);
-
- /* set pin as input */
- x = __raw_readl(KS8695_GPIO_VA + KS8695_IOPM);
- x &= ~IOPM(pin);
- __raw_writel(x, KS8695_GPIO_VA + KS8695_IOPM);
-
- local_irq_restore(flags);
-
- /* Set IRQ triggering type */
- irq_set_irq_type(gpio_irq[pin], type);
-
- /* enable interrupt mode */
- ks8695_gpio_mode(pin, 0);
-
- return 0;
-}
-EXPORT_SYMBOL(ks8695_gpio_interrupt);
-
-
-
-/* .... Generic GPIO interface .............................................. */
-
-/*
- * Configure the GPIO line as an input.
- */
-static int ks8695_gpio_direction_input(struct gpio_chip *gc, unsigned int pin)
-{
- unsigned long x, flags;
-
- if (pin > KS8695_GPIO_15)
- return -EINVAL;
-
- /* set pin to GPIO mode */
- ks8695_gpio_mode(pin, 1);
-
- local_irq_save(flags);
-
- /* set pin as input */
- x = __raw_readl(KS8695_GPIO_VA + KS8695_IOPM);
- x &= ~IOPM(pin);
- __raw_writel(x, KS8695_GPIO_VA + KS8695_IOPM);
-
- local_irq_restore(flags);
-
- return 0;
-}
-
-
-/*
- * Configure the GPIO line as an output, with default state.
- */
-static int ks8695_gpio_direction_output(struct gpio_chip *gc,
- unsigned int pin, int state)
-{
- unsigned long x, flags;
-
- if (pin > KS8695_GPIO_15)
- return -EINVAL;
-
- /* set pin to GPIO mode */
- ks8695_gpio_mode(pin, 1);
-
- local_irq_save(flags);
-
- /* set line state */
- x = __raw_readl(KS8695_GPIO_VA + KS8695_IOPD);
- if (state)
- x |= IOPD(pin);
- else
- x &= ~IOPD(pin);
- __raw_writel(x, KS8695_GPIO_VA + KS8695_IOPD);
-
- /* set pin as output */
- x = __raw_readl(KS8695_GPIO_VA + KS8695_IOPM);
- x |= IOPM(pin);
- __raw_writel(x, KS8695_GPIO_VA + KS8695_IOPM);
-
- local_irq_restore(flags);
-
- return 0;
-}
-
-
-/*
- * Set the state of an output GPIO line.
- */
-static void ks8695_gpio_set_value(struct gpio_chip *gc,
- unsigned int pin, int state)
-{
- unsigned long x, flags;
-
- if (pin > KS8695_GPIO_15)
- return;
-
- local_irq_save(flags);
-
- /* set output line state */
- x = __raw_readl(KS8695_GPIO_VA + KS8695_IOPD);
- if (state)
- x |= IOPD(pin);
- else
- x &= ~IOPD(pin);
- __raw_writel(x, KS8695_GPIO_VA + KS8695_IOPD);
-
- local_irq_restore(flags);
-}
-
-
-/*
- * Read the state of a GPIO line.
- */
-static int ks8695_gpio_get_value(struct gpio_chip *gc, unsigned int pin)
-{
- unsigned long x;
-
- if (pin > KS8695_GPIO_15)
- return -EINVAL;
-
- x = __raw_readl(KS8695_GPIO_VA + KS8695_IOPD);
- return (x & IOPD(pin)) != 0;
-}
-
-
-/*
- * Map GPIO line to IRQ number.
- */
-static int ks8695_gpio_to_irq(struct gpio_chip *gc, unsigned int pin)
-{
- if (pin > KS8695_GPIO_3) /* only GPIO 0..3 can generate IRQ */
- return -EINVAL;
-
- return gpio_irq[pin];
-}
-
-/* GPIOLIB interface */
-
-static struct gpio_chip ks8695_gpio_chip = {
- .label = "KS8695",
- .direction_input = ks8695_gpio_direction_input,
- .direction_output = ks8695_gpio_direction_output,
- .get = ks8695_gpio_get_value,
- .set = ks8695_gpio_set_value,
- .to_irq = ks8695_gpio_to_irq,
- .base = 0,
- .ngpio = 16,
- .can_sleep = false,
-};
-
-/* Register the GPIOs */
-void ks8695_register_gpios(void)
-{
- if (gpiochip_add_data(&ks8695_gpio_chip, NULL))
- printk(KERN_ERR "Unable to register core GPIOs\n");
-}
-
-/* .... Debug interface ..................................................... */
-
-#ifdef CONFIG_DEBUG_FS
-
-static int ks8695_gpio_show(struct seq_file *s, void *unused)
-{
- unsigned int enable[] = { IOPC_IOEINT0EN, IOPC_IOEINT1EN, IOPC_IOEINT2EN, IOPC_IOEINT3EN, IOPC_IOTIM0EN, IOPC_IOTIM1EN };
- unsigned int intmask[] = { IOPC_IOEINT0TM, IOPC_IOEINT1TM, IOPC_IOEINT2TM, IOPC_IOEINT3TM };
- unsigned long mode, ctrl, data;
- int i;
-
- mode = __raw_readl(KS8695_GPIO_VA + KS8695_IOPM);
- ctrl = __raw_readl(KS8695_GPIO_VA + KS8695_IOPC);
- data = __raw_readl(KS8695_GPIO_VA + KS8695_IOPD);
-
- seq_printf(s, "Pin\tI/O\tFunction\tState\n\n");
-
- for (i = KS8695_GPIO_0; i <= KS8695_GPIO_15 ; i++) {
- seq_printf(s, "%i:\t", i);
-
- seq_printf(s, "%s\t", (mode & IOPM(i)) ? "Output" : "Input");
-
- if (i <= KS8695_GPIO_3) {
- if (ctrl & enable[i]) {
- seq_printf(s, "EXT%i ", i);
-
- switch ((ctrl & intmask[i]) >> (4 * i)) {
- case IOPC_TM_LOW:
- seq_printf(s, "(Low)"); break;
- case IOPC_TM_HIGH:
- seq_printf(s, "(High)"); break;
- case IOPC_TM_RISING:
- seq_printf(s, "(Rising)"); break;
- case IOPC_TM_FALLING:
- seq_printf(s, "(Falling)"); break;
- case IOPC_TM_EDGE:
- seq_printf(s, "(Edges)"); break;
- }
- } else
- seq_printf(s, "GPIO\t");
- } else if (i <= KS8695_GPIO_5) {
- if (ctrl & enable[i])
- seq_printf(s, "TOUT%i\t", i - KS8695_GPIO_4);
- else
- seq_printf(s, "GPIO\t");
- } else {
- seq_printf(s, "GPIO\t");
- }
-
- seq_printf(s, "\t");
-
- seq_printf(s, "%i\n", (data & IOPD(i)) ? 1 : 0);
- }
- return 0;
-}
-
-DEFINE_SHOW_ATTRIBUTE(ks8695_gpio);
-
-static int __init ks8695_gpio_debugfs_init(void)
-{
- /* /sys/kernel/debug/ks8695_gpio */
- debugfs_create_file("ks8695_gpio", S_IFREG | S_IRUGO, NULL, NULL,
- &ks8695_gpio_fops);
- return 0;
-}
-postcore_initcall(ks8695_gpio_debugfs_init);
-
-#endif
--
2.20.0
^ permalink raw reply related
* [PATCH 00/16] ARM: remove ks8695 and w90x900 platforms
From: Arnd Bergmann @ 2019-08-09 20:27 UTC (permalink / raw)
To: soc
Cc: Arnd Bergmann, Wanzongshun (Vincent), Greg Ungerer,
Greg Kroah-Hartman, linux-serial, Dmitry Torokhov, linux-input,
Linus Walleij, linux-gpio, David S. Miller, netdev, Guenter Roeck,
Mark Brown, alsa-devel, linux-spi, Bartlomiej Zolnierkiewicz,
linux-fbdev, Miquel Raynal, linux-mtd, linux-arm-kernel,
linux-kernel
As discussed previously, these two ARM platforms have no
known remaining users, let's remove them completely.
Subsystem maintainers: feel free to take the driver removals
through your respective trees, they are all independent of
one another. We can merge any remaining patches through the
soc tree.
Arnd
Arnd Bergmann (16):
ARM: remove ks8695 platform
serial: remove ks8695 driver
gpio: remove ks8695 driver
watchdog: remove ks8695 driver
net: remove ks8695 driver
watchdog: remove w90x900 driver
spi: remove w90x900 driver
ASoC: remove w90x900/nuc900 platform drivers
fbdev: remove w90x900/nuc900 platform drivers
Input: remove w90x900 keyboard driver
Input: remove w90x900 touchscreen driver
mtd: rawnand: remove w90x900 driver
net: remove w90p910-ether driver
rtc: remove w90x900/nuc900 driver
usb: remove ehci-w90x900 driver
ARM: remove w90x900 platform
Cc: "Wanzongshun (Vincent)" <wanzongshun@huawei.com>
Cc: Greg Ungerer <gerg@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-serial@vger.kernel.org
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
Cc: linux-spi@vger.kernel.org
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: linux-fbdev@vger.kernel.org
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: linux-mtd@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
.../watchdog/watchdog-parameters.rst | 19 -
MAINTAINERS | 22 -
arch/arm/Kconfig | 34 +-
arch/arm/Kconfig.debug | 8 -
arch/arm/Makefile | 2 -
arch/arm/configs/acs5k_defconfig | 77 -
arch/arm/configs/acs5k_tiny_defconfig | 69 -
arch/arm/configs/ks8695_defconfig | 67 -
arch/arm/configs/nuc910_defconfig | 51 -
arch/arm/configs/nuc950_defconfig | 67 -
arch/arm/configs/nuc960_defconfig | 57 -
arch/arm/include/debug/ks8695.S | 37 -
arch/arm/mach-ks8695/Kconfig | 88 -
arch/arm/mach-ks8695/Makefile | 23 -
arch/arm/mach-ks8695/Makefile.boot | 9 -
arch/arm/mach-ks8695/board-acs5k.c | 238 ---
arch/arm/mach-ks8695/board-dsm320.c | 127 --
arch/arm/mach-ks8695/board-micrel.c | 59 -
arch/arm/mach-ks8695/board-og.c | 197 --
arch/arm/mach-ks8695/board-sg.c | 118 --
arch/arm/mach-ks8695/cpu.c | 60 -
arch/arm/mach-ks8695/devices.c | 197 --
arch/arm/mach-ks8695/devices.h | 29 -
arch/arm/mach-ks8695/generic.h | 12 -
.../mach-ks8695/include/mach/entry-macro.S | 47 -
.../mach-ks8695/include/mach/gpio-ks8695.h | 36 -
arch/arm/mach-ks8695/include/mach/hardware.h | 42 -
arch/arm/mach-ks8695/include/mach/irqs.h | 51 -
arch/arm/mach-ks8695/include/mach/memory.h | 51 -
arch/arm/mach-ks8695/include/mach/regs-gpio.h | 55 -
arch/arm/mach-ks8695/include/mach/regs-irq.h | 41 -
arch/arm/mach-ks8695/include/mach/regs-misc.h | 97 -
.../mach-ks8695/include/mach/regs-switch.h | 66 -
arch/arm/mach-ks8695/include/mach/regs-uart.h | 89 -
.../arm/mach-ks8695/include/mach/uncompress.h | 33 -
arch/arm/mach-ks8695/irq.c | 164 --
arch/arm/mach-ks8695/pci.c | 247 ---
arch/arm/mach-ks8695/regs-hpna.h | 25 -
arch/arm/mach-ks8695/regs-lan.h | 65 -
arch/arm/mach-ks8695/regs-mem.h | 89 -
arch/arm/mach-ks8695/regs-pci.h | 53 -
arch/arm/mach-ks8695/regs-sys.h | 34 -
arch/arm/mach-ks8695/regs-wan.h | 65 -
arch/arm/mach-ks8695/time.c | 159 --
arch/arm/mach-w90x900/Kconfig | 50 -
arch/arm/mach-w90x900/Makefile | 20 -
arch/arm/mach-w90x900/Makefile.boot | 4 -
arch/arm/mach-w90x900/clksel.c | 88 -
arch/arm/mach-w90x900/clock.c | 121 --
arch/arm/mach-w90x900/clock.h | 40 -
arch/arm/mach-w90x900/cpu.c | 238 ---
arch/arm/mach-w90x900/cpu.h | 56 -
arch/arm/mach-w90x900/dev.c | 537 ------
arch/arm/mach-w90x900/gpio.c | 150 --
.../mach-w90x900/include/mach/entry-macro.S | 26 -
arch/arm/mach-w90x900/include/mach/hardware.h | 19 -
arch/arm/mach-w90x900/include/mach/irqs.h | 82 -
arch/arm/mach-w90x900/include/mach/map.h | 153 --
arch/arm/mach-w90x900/include/mach/mfp.h | 21 -
.../mach-w90x900/include/mach/regs-clock.h | 49 -
arch/arm/mach-w90x900/include/mach/regs-irq.h | 46 -
arch/arm/mach-w90x900/include/mach/regs-ldm.h | 248 ---
.../mach-w90x900/include/mach/regs-serial.h | 54 -
.../mach-w90x900/include/mach/uncompress.h | 43 -
arch/arm/mach-w90x900/irq.c | 212 ---
arch/arm/mach-w90x900/mach-nuc910evb.c | 38 -
arch/arm/mach-w90x900/mach-nuc950evb.c | 42 -
arch/arm/mach-w90x900/mach-nuc960evb.c | 38 -
arch/arm/mach-w90x900/mfp.c | 197 --
arch/arm/mach-w90x900/nuc910.c | 58 -
arch/arm/mach-w90x900/nuc910.h | 17 -
arch/arm/mach-w90x900/nuc950.c | 52 -
arch/arm/mach-w90x900/nuc950.h | 17 -
arch/arm/mach-w90x900/nuc960.c | 50 -
arch/arm/mach-w90x900/nuc960.h | 17 -
arch/arm/mach-w90x900/nuc9xx.h | 22 -
arch/arm/mach-w90x900/regs-ebi.h | 29 -
arch/arm/mach-w90x900/regs-gcr.h | 34 -
arch/arm/mach-w90x900/regs-timer.h | 37 -
arch/arm/mach-w90x900/regs-usb.h | 31 -
arch/arm/mach-w90x900/time.c | 168 --
arch/arm/mm/Kconfig | 2 +-
drivers/gpio/Makefile | 1 -
drivers/gpio/gpio-ks8695.c | 284 ---
drivers/input/keyboard/Kconfig | 11 -
drivers/input/keyboard/Makefile | 1 -
drivers/input/keyboard/w90p910_keypad.c | 264 ---
drivers/input/touchscreen/Kconfig | 9 -
drivers/input/touchscreen/Makefile | 1 -
drivers/input/touchscreen/w90p910_ts.c | 331 ----
drivers/mtd/nand/raw/Kconfig | 8 -
drivers/mtd/nand/raw/Makefile | 1 -
drivers/mtd/nand/raw/nuc900_nand.c | 304 ---
drivers/net/ethernet/Kconfig | 1 -
drivers/net/ethernet/Makefile | 1 -
drivers/net/ethernet/micrel/Kconfig | 11 +-
drivers/net/ethernet/micrel/Makefile | 1 -
drivers/net/ethernet/micrel/ks8695net.c | 1632 -----------------
drivers/net/ethernet/micrel/ks8695net.h | 108 --
drivers/net/ethernet/nuvoton/Kconfig | 29 -
drivers/net/ethernet/nuvoton/Makefile | 6 -
drivers/net/ethernet/nuvoton/w90p910_ether.c | 1082 -----------
drivers/rtc/Kconfig | 7 -
drivers/rtc/Makefile | 1 -
drivers/rtc/rtc-nuc900.c | 271 ---
drivers/spi/Kconfig | 7 -
drivers/spi/Makefile | 1 -
drivers/spi/spi-nuc900.c | 429 -----
drivers/tty/serial/Kconfig | 17 -
drivers/tty/serial/Makefile | 1 -
drivers/tty/serial/serial_ks8695.c | 698 -------
drivers/usb/host/Kconfig | 6 -
drivers/usb/host/Makefile | 1 -
drivers/usb/host/ehci-w90x900.c | 130 --
drivers/video/fbdev/Kconfig | 14 -
drivers/video/fbdev/Makefile | 1 -
drivers/video/fbdev/nuc900fb.c | 760 --------
drivers/video/fbdev/nuc900fb.h | 51 -
drivers/watchdog/Kconfig | 16 -
drivers/watchdog/Makefile | 2 -
drivers/watchdog/ks8695_wdt.c | 319 ----
drivers/watchdog/nuc900_wdt.c | 302 ---
include/Kbuild | 2 -
include/linux/platform_data/keypad-w90p910.h | 16 -
include/linux/platform_data/spi-nuc900.h | 29 -
include/linux/platform_data/video-nuc900fb.h | 79 -
include/uapi/linux/serial_core.h | 3 -
sound/soc/Kconfig | 1 -
sound/soc/Makefile | 1 -
sound/soc/nuc900/Kconfig | 29 -
sound/soc/nuc900/Makefile | 12 -
sound/soc/nuc900/nuc900-ac97.c | 391 ----
sound/soc/nuc900/nuc900-audio.c | 73 -
sound/soc/nuc900/nuc900-audio.h | 108 --
sound/soc/nuc900/nuc900-pcm.c | 321 ----
135 files changed, 6 insertions(+), 14461 deletions(-)
delete mode 100644 arch/arm/configs/acs5k_defconfig
delete mode 100644 arch/arm/configs/acs5k_tiny_defconfig
delete mode 100644 arch/arm/configs/ks8695_defconfig
delete mode 100644 arch/arm/configs/nuc910_defconfig
delete mode 100644 arch/arm/configs/nuc950_defconfig
delete mode 100644 arch/arm/configs/nuc960_defconfig
delete mode 100644 arch/arm/include/debug/ks8695.S
delete mode 100644 arch/arm/mach-ks8695/Kconfig
delete mode 100644 arch/arm/mach-ks8695/Makefile
delete mode 100644 arch/arm/mach-ks8695/Makefile.boot
delete mode 100644 arch/arm/mach-ks8695/board-acs5k.c
delete mode 100644 arch/arm/mach-ks8695/board-dsm320.c
delete mode 100644 arch/arm/mach-ks8695/board-micrel.c
delete mode 100644 arch/arm/mach-ks8695/board-og.c
delete mode 100644 arch/arm/mach-ks8695/board-sg.c
delete mode 100644 arch/arm/mach-ks8695/cpu.c
delete mode 100644 arch/arm/mach-ks8695/devices.c
delete mode 100644 arch/arm/mach-ks8695/devices.h
delete mode 100644 arch/arm/mach-ks8695/generic.h
delete mode 100644 arch/arm/mach-ks8695/include/mach/entry-macro.S
delete mode 100644 arch/arm/mach-ks8695/include/mach/gpio-ks8695.h
delete mode 100644 arch/arm/mach-ks8695/include/mach/hardware.h
delete mode 100644 arch/arm/mach-ks8695/include/mach/irqs.h
delete mode 100644 arch/arm/mach-ks8695/include/mach/memory.h
delete mode 100644 arch/arm/mach-ks8695/include/mach/regs-gpio.h
delete mode 100644 arch/arm/mach-ks8695/include/mach/regs-irq.h
delete mode 100644 arch/arm/mach-ks8695/include/mach/regs-misc.h
delete mode 100644 arch/arm/mach-ks8695/include/mach/regs-switch.h
delete mode 100644 arch/arm/mach-ks8695/include/mach/regs-uart.h
delete mode 100644 arch/arm/mach-ks8695/include/mach/uncompress.h
delete mode 100644 arch/arm/mach-ks8695/irq.c
delete mode 100644 arch/arm/mach-ks8695/pci.c
delete mode 100644 arch/arm/mach-ks8695/regs-hpna.h
delete mode 100644 arch/arm/mach-ks8695/regs-lan.h
delete mode 100644 arch/arm/mach-ks8695/regs-mem.h
delete mode 100644 arch/arm/mach-ks8695/regs-pci.h
delete mode 100644 arch/arm/mach-ks8695/regs-sys.h
delete mode 100644 arch/arm/mach-ks8695/regs-wan.h
delete mode 100644 arch/arm/mach-ks8695/time.c
delete mode 100644 arch/arm/mach-w90x900/Kconfig
delete mode 100644 arch/arm/mach-w90x900/Makefile
delete mode 100644 arch/arm/mach-w90x900/Makefile.boot
delete mode 100644 arch/arm/mach-w90x900/clksel.c
delete mode 100644 arch/arm/mach-w90x900/clock.c
delete mode 100644 arch/arm/mach-w90x900/clock.h
delete mode 100644 arch/arm/mach-w90x900/cpu.c
delete mode 100644 arch/arm/mach-w90x900/cpu.h
delete mode 100644 arch/arm/mach-w90x900/dev.c
delete mode 100644 arch/arm/mach-w90x900/gpio.c
delete mode 100644 arch/arm/mach-w90x900/include/mach/entry-macro.S
delete mode 100644 arch/arm/mach-w90x900/include/mach/hardware.h
delete mode 100644 arch/arm/mach-w90x900/include/mach/irqs.h
delete mode 100644 arch/arm/mach-w90x900/include/mach/map.h
delete mode 100644 arch/arm/mach-w90x900/include/mach/mfp.h
delete mode 100644 arch/arm/mach-w90x900/include/mach/regs-clock.h
delete mode 100644 arch/arm/mach-w90x900/include/mach/regs-irq.h
delete mode 100644 arch/arm/mach-w90x900/include/mach/regs-ldm.h
delete mode 100644 arch/arm/mach-w90x900/include/mach/regs-serial.h
delete mode 100644 arch/arm/mach-w90x900/include/mach/uncompress.h
delete mode 100644 arch/arm/mach-w90x900/irq.c
delete mode 100644 arch/arm/mach-w90x900/mach-nuc910evb.c
delete mode 100644 arch/arm/mach-w90x900/mach-nuc950evb.c
delete mode 100644 arch/arm/mach-w90x900/mach-nuc960evb.c
delete mode 100644 arch/arm/mach-w90x900/mfp.c
delete mode 100644 arch/arm/mach-w90x900/nuc910.c
delete mode 100644 arch/arm/mach-w90x900/nuc910.h
delete mode 100644 arch/arm/mach-w90x900/nuc950.c
delete mode 100644 arch/arm/mach-w90x900/nuc950.h
delete mode 100644 arch/arm/mach-w90x900/nuc960.c
delete mode 100644 arch/arm/mach-w90x900/nuc960.h
delete mode 100644 arch/arm/mach-w90x900/nuc9xx.h
delete mode 100644 arch/arm/mach-w90x900/regs-ebi.h
delete mode 100644 arch/arm/mach-w90x900/regs-gcr.h
delete mode 100644 arch/arm/mach-w90x900/regs-timer.h
delete mode 100644 arch/arm/mach-w90x900/regs-usb.h
delete mode 100644 arch/arm/mach-w90x900/time.c
delete mode 100644 drivers/gpio/gpio-ks8695.c
delete mode 100644 drivers/input/keyboard/w90p910_keypad.c
delete mode 100644 drivers/input/touchscreen/w90p910_ts.c
delete mode 100644 drivers/mtd/nand/raw/nuc900_nand.c
delete mode 100644 drivers/net/ethernet/micrel/ks8695net.c
delete mode 100644 drivers/net/ethernet/micrel/ks8695net.h
delete mode 100644 drivers/net/ethernet/nuvoton/Kconfig
delete mode 100644 drivers/net/ethernet/nuvoton/Makefile
delete mode 100644 drivers/net/ethernet/nuvoton/w90p910_ether.c
delete mode 100644 drivers/rtc/rtc-nuc900.c
delete mode 100644 drivers/spi/spi-nuc900.c
delete mode 100644 drivers/tty/serial/serial_ks8695.c
delete mode 100644 drivers/usb/host/ehci-w90x900.c
delete mode 100644 drivers/video/fbdev/nuc900fb.c
delete mode 100644 drivers/video/fbdev/nuc900fb.h
delete mode 100644 drivers/watchdog/ks8695_wdt.c
delete mode 100644 drivers/watchdog/nuc900_wdt.c
delete mode 100644 include/linux/platform_data/keypad-w90p910.h
delete mode 100644 include/linux/platform_data/spi-nuc900.h
delete mode 100644 include/linux/platform_data/video-nuc900fb.h
delete mode 100644 sound/soc/nuc900/Kconfig
delete mode 100644 sound/soc/nuc900/Makefile
delete mode 100644 sound/soc/nuc900/nuc900-ac97.c
delete mode 100644 sound/soc/nuc900/nuc900-audio.c
delete mode 100644 sound/soc/nuc900/nuc900-audio.h
delete mode 100644 sound/soc/nuc900/nuc900-pcm.c
--
2.20.0
^ permalink raw reply
* Re: [PATCH 00/16] ARM: remove ks8695 and w90x900 platforms
From: Greg Kroah-Hartman @ 2019-08-10 7:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: soc, Wanzongshun (Vincent), Greg Ungerer, linux-serial,
Dmitry Torokhov, linux-input, Linus Walleij, linux-gpio,
David S. Miller, netdev, Guenter Roeck, Mark Brown, alsa-devel,
linux-spi, Bartlomiej Zolnierkiewicz, linux-fbdev, Miquel Raynal,
linux-mtd, linux-arm-kernel, linux-kernel
In-Reply-To: <20190809202749.742267-1-arnd@arndb.de>
On Fri, Aug 09, 2019 at 10:27:28PM +0200, Arnd Bergmann wrote:
> As discussed previously, these two ARM platforms have no
> known remaining users, let's remove them completely.
>
> Subsystem maintainers: feel free to take the driver removals
> through your respective trees, they are all independent of
> one another. We can merge any remaining patches through the
> soc tree.
Serial and USB host controller driver patches applied, thanks!
greg k-h
^ permalink raw reply
* Re: [PATCH] pinctrl: aspeed: g6: Remove const specifier from aspeed_g6_sig_expr_set's ctx parameter
From: Linus Walleij @ 2019-08-10 8:12 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Andrew Jeffery, Joel Stanley, linux-aspeed, OpenBMC Maillist,
open list:GPIO SUBSYSTEM, Linux ARM, linux-kernel@vger.kernel.org,
clang-built-linux
In-Reply-To: <20190807003037.48457-1-natechancellor@gmail.com>
On Wed, Aug 7, 2019 at 2:32 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
> clang errors:
>
> drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c:2325:9: error: incompatible
> pointer types initializing 'int (*)(struct aspeed_pinmux_data *, const
> struct aspeed_sig_expr *, bool)' with an expression of type 'int (const
> struct aspeed_pinmux_data *, const struct aspeed_sig_expr *, bool)'
> [-Werror,-Wincompatible-pointer-types]
> .set = aspeed_g6_sig_expr_set,
> ^~~~~~~~~~~~~~~~~~~~~~
> 1 error generated.
>
> Commit 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
> changed the set function pointer declaration and the g6 one wasn't
> updated (I assume because it wasn't merged yet).
>
> Fixes: 2eda1cdec49f ("pinctrl: aspeed: Add AST2600 pinmux support")
> Link: https://github.com/ClangBuiltLinux/linux/issues/632
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Patch applied with Andrew's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: stm32: stm32: Add of_node_put() before return
From: Linus Walleij @ 2019-08-10 8:22 UTC (permalink / raw)
To: Nishka Dasgupta
Cc: Maxime Coquelin, Alexandre TORGUE, open list:GPIO SUBSYSTEM,
linux-stm32, Linux ARM
In-Reply-To: <20190808075457.16109-1-nishkadg.linux@gmail.com>
On Thu, Aug 8, 2019 at 9:55 AM Nishka Dasgupta <nishkadg.linux@gmail.com> wrote:
> Each iteration of for_each_child_of_node and
> for_each_available_child_of_node puts the previous node, but in
> the case of a return from the middle of the loop, there is no put, thus
> causing a memory leak. Hence add an of_node_put before the return in
> two places.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: sprd: Add of_node_put() before return to prevent memory leak
From: Linus Walleij @ 2019-08-10 8:23 UTC (permalink / raw)
To: Nishka Dasgupta
Cc: Orson Zhai, Baolin Wang, Lyra Zhang, open list:GPIO SUBSYSTEM
In-Reply-To: <20190808074329.15579-1-nishkadg.linux@gmail.com>
On Thu, Aug 8, 2019 at 9:43 AM Nishka Dasgupta <nishkadg.linux@gmail.com> wrote:
> Each iteration of for_each_child_of_node puts the previous node, but in
> the case of a return from the middle of the loop, there is no put, thus
> causing a memory leak. Hence add an of_node_put before the return in
> two places.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Patch applied with Baolin's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] gpiolib: Add for_each_gpio_suffix() helper
From: Linus Walleij @ 2019-08-10 8:27 UTC (permalink / raw)
To: Stefan Roese
Cc: linux-serial, open list:GPIO SUBSYSTEM, Andy Shevchenko,
Geert Uytterhoeven, Pavel Machek, Greg Kroah-Hartman
In-Reply-To: <20190808132543.26274-1-sr@denx.de>
On Thu, Aug 8, 2019 at 3:25 PM Stefan Roese <sr@denx.de> wrote:
> Add a helper macro to enable the interation over all supported GPIO
> suffixes (currently "gpios" & "gpio"). This will be used by the serial
> mctrl code to check, if a GPIO property exists before requesting it.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Pavel Machek <pavel@denx.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I really like this patch, it makes things so much more readable.
Do you want me to apply both patches to the GPIO tree when
we agreed on the final version? I need some ACK from some
serial maintainer.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: freescale: imx: Add of_node_put() before return
From: Linus Walleij @ 2019-08-10 8:30 UTC (permalink / raw)
To: Nishka Dasgupta
Cc: Dong Aisheng, Fabio Estevam, Shawn Guo, Stefan Agner,
Sascha Hauer, Sascha Hauer, NXP Linux Team,
open list:GPIO SUBSYSTEM, Linux ARM
In-Reply-To: <20190808074720.15754-1-nishkadg.linux@gmail.com>
On Thu, Aug 8, 2019 at 9:47 AM Nishka Dasgupta <nishkadg.linux@gmail.com> wrote:
> Each iteration of for_each_child_of_node() puts the previous node;
> however, in the case of a return from the middle of the loop, there is no
> put, thus causing a memory leak. Hence put of_node_put() statements as
> required before two mid-loop return statements.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Patch applied with Philipp's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [git pull] pinctrl: sh-pfc: Updates for v5.4
From: Linus Walleij @ 2019-08-10 8:31 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: open list:GPIO SUBSYSTEM, Linux-Renesas
In-Reply-To: <20190809074420.27006-1-geert+renesas@glider.be>
On Fri, Aug 9, 2019 at 9:44 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git tags/sh-pfc-for-v5.4-tag1
>
> for you to fetch changes up to 625efea83a7c37d281c6a90526813a1366929d24:
>
> pinctrl: rza1: Use devm_platform_ioremap_resource() helper (2019-08-09 09:34:45 +0200)
Pulled into my "devel" branch, thanks!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] gpiolib: Add for_each_gpio_suffix() helper
From: Greg Kroah-Hartman @ 2019-08-10 8:48 UTC (permalink / raw)
To: Linus Walleij
Cc: Stefan Roese, linux-serial, open list:GPIO SUBSYSTEM,
Andy Shevchenko, Geert Uytterhoeven, Pavel Machek
In-Reply-To: <CACRpkdYzg0At4qf1Nv5_+SzgqQ-iLU1ND9Svhj47=pXJf9E7Mg@mail.gmail.com>
On Sat, Aug 10, 2019 at 10:27:27AM +0200, Linus Walleij wrote:
> On Thu, Aug 8, 2019 at 3:25 PM Stefan Roese <sr@denx.de> wrote:
>
> > Add a helper macro to enable the interation over all supported GPIO
> > suffixes (currently "gpios" & "gpio"). This will be used by the serial
> > mctrl code to check, if a GPIO property exists before requesting it.
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Pavel Machek <pavel@denx.de>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> I really like this patch, it makes things so much more readable.
>
> Do you want me to apply both patches to the GPIO tree when
> we agreed on the final version? I need some ACK from some
> serial maintainer.
When you all can agree on the final version, I'll be glad to give my ack
for you to take these :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings
From: Linus Walleij @ 2019-08-10 8:51 UTC (permalink / raw)
To: Rob Herring
Cc: Harish Jenny K N, Bartosz Golaszewski, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Balasubramani Vivekanandan
In-Reply-To: <CAL_JsqLp___2O-naU+2PPQy0QmJX6+aN3hByz-OB9+qFvWgN9Q@mail.gmail.com>
On Fri, Aug 9, 2019 at 4:08 PM Rob Herring <robh+dt@kernel.org> wrote:
> On Mon, Aug 5, 2019 at 5:15 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > There is some level of ambition here which is inherently a bit fuzzy
> > around the edges. ("How long is the coast of Britain?" comes to mind.)
> >
> > Surely the intention of device tree is not to recreate the schematic
> > in all detail. What we want is a model of the hardware that will
> > suffice for the operating system usecases.
> >
> > But sometimes the DTS files will become confusing: why is this
> > component using GPIO_ACTIVE_LOW when another system
> > doesn't have that flag? If there is an explicit inverter, the
> > DTS gets more readable for a human.
> >
> > But arguable that is case for adding inverters as syntactic
> > sugar in the DTS compiler instead...
>
> If you really want something more explicit, then add a new GPIO
> 'inverted' flag. Then a device can always have the same HIGH/LOW flag.
> That also solves the abstract it for userspace problem.
I think there are some intricate ontologies at work here.
Consider this example: a GPIO is controlling a chip select
regulator, say Acme Foo. The chip select
has a pin named CSN. We know from convention that the
"N" at the end of that pin name means "negative" i.e. active
low, and that is how the electronics engineers think about
that chip select line: it activates the IC when
the line goes low.
The regulator subsystem and I think all subsystems in the
Linux kernel say the consumer pin should be named and
tagged after the datsheet of the regulator.
So it has for example:
foo {
compatible = "acme,foo";
cs-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
};
(It would be inappropriate to name it "csn-gpios" since
we have an established flag for active low. But it is another
of these syntactic choices where people likely do mistakes.)
I think it would be appropriate for the DT binding to say
that this flag must always be GPIO_ACTIVE_LOW since
the bindings are seen from the component point of view,
and thus this is always active low.
It would even be reasonable for a yaml schema to enfore
this, if it could. It is defined as active low after all.
Now if someone adds an inverter on that line between
gpio0 and Acme Foo it looks like this:
foo {
compatible = "acme,foo";
cs-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
};
And now we get cognitive dissonance or whatever I should
call it: someone reading this DTS sheet and the data
sheet for the component Acme Foo to troubleshoot
this will be confused: this component has CS active
low and still it is specified as active high? Unless they
also look at the schematic or the board and find the
inverter things are pretty muddy and they will likely curse
and solve the situation with the usual trial-and-error,
inserting some random cursewords as a comment.
With an intermediate inverter node, the cs-gpios
can go back to GPIO_ACTIVE_LOW and follow
the bindings:
inv0: inverter {
compatible = "gpio-inverter";
gpio-controller;
#gpio-cells = <1>;
inverted-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
};
foo {
compatible = "acme,foo";
cs-gpios = <&inv0 0 GPIO_ACTIVE_LOW>;
};
And now Acme Foo bindings can keep enforcing cs-gpios
to always be tagged GPIO_ACTIVE_LOW.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] pin control fixes for v5.3
From: Linus Walleij @ 2019-08-10 9:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, open list:GPIO SUBSYSTEM, Andrew Jeffery,
YueHaibing
Hi Linus,
here are some pin control fixes for the v5.3 development.
I should have sent earlier, vacation interfered. Thus there
is a syntax fix I would normally not put in as fix at this point in
this set, but I think it is no big deal.
Please pull it in!
Yours,
Linus Walleij
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
tags/pinctrl-v5.3-2
for you to fetch changes up to 8c4407de3be44c2a0ec3e316cd3e4a711bc2aaba:
pinctrl: aspeed: Make aspeed_pinmux_ips static (2019-07-29 23:35:31 +0200)
----------------------------------------------------------------
Some pin control fixes for the v5.4 series:
- Delay acquisition of regmaps in the Aspeed G5 driver.
- Make a symbol static to reduce compiler noise.
----------------------------------------------------------------
Andrew Jeffery (1):
pinctrl: aspeed-g5: Delay acquisition of regmaps
YueHaibing (1):
pinctrl: aspeed: Make aspeed_pinmux_ips static
drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 2 +-
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 92 +++++++++++++++++++++---------
drivers/pinctrl/aspeed/pinctrl-aspeed.c | 12 ++--
drivers/pinctrl/aspeed/pinmux-aspeed.c | 2 +-
drivers/pinctrl/aspeed/pinmux-aspeed.h | 5 +-
5 files changed, 75 insertions(+), 38 deletions(-)
^ permalink raw reply
* Re: [PATCH 03/16] gpio: remove ks8695 driver
From: Linus Walleij @ 2019-08-10 9:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: soc, Bartosz Golaszewski, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM
In-Reply-To: <20190809202749.742267-4-arnd@arndb.de>
On Fri, Aug 9, 2019 at 10:28 PM Arnd Bergmann <arnd@arndb.de> wrote:
> The platform is getting removed, so there are no remaining
> users of this driver.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied. Thanks for cleaning out this old cruft.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: hlwd: Pass irqchip when adding gpiochip
From: Jonathan Neuschäfer @ 2019-08-10 10:35 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-gpio, Bartosz Golaszewski, Jonathan Neuschäfer,
Thierry Reding
In-Reply-To: <20190809140005.11654-1-linus.walleij@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
On Fri, Aug 09, 2019 at 04:00:05PM +0200, Linus Walleij wrote:
> We need to convert all old gpio irqchips to pass the irqchip
> setup along when adding the gpio_chip. For more info see
> drivers/gpio/TODO.
>
> For chained irqchips this is a pretty straight-forward
> conversion.
>
> Cc: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
Unfortunately, there seems to have been an unrelated regression between
5.0 and now affecting the Wii, so I can't easily test this patch right
now. But it looks good (esp. with git show -b).
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [GIT PULL] pin control fixes for v5.3
From: pr-tracker-bot @ 2019-08-10 19:30 UTC (permalink / raw)
To: Linus Walleij
Cc: Linus Torvalds, linux-kernel, open list:GPIO SUBSYSTEM,
Andrew Jeffery, YueHaibing
In-Reply-To: <CACRpkdaMp16=-NGxOhe_Gz-vvoZrN7S+CE6zVmD+erVU051kmQ@mail.gmail.com>
The pull request you sent on Sat, 10 Aug 2019 11:01:00 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git tags/pinctrl-v5.3-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/97946f59fe7fecff44032f8e775975991a612d18
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* [PATCH] gpio: intel-mid: Pass irqchip when adding gpiochip
From: Linus Walleij @ 2019-08-11 8:05 UTC (permalink / raw)
To: linux-gpio
Cc: Bartosz Golaszewski, Linus Walleij, Andy Shevchenko,
Mika Westerberg, David Cohen, Thierry Reding
We need to convert all old gpio irqchips to pass the irqchip
setup along when adding the gpio_chip. For more info see
drivers/gpio/TODO.
For chained irqchips this is a pretty straight-forward
conversion.
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: David Cohen <david.a.cohen@linux.intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Andy: when you're happy with this you can either supply an
ACK and I will merge it or you can merge it into your tree
for a later pull request, just tell me what you prefer.
---
drivers/gpio/gpio-intel-mid.c | 35 +++++++++++++++++------------------
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpio-intel-mid.c b/drivers/gpio/gpio-intel-mid.c
index 4e803baf980e..1f5c9d21db0b 100644
--- a/drivers/gpio/gpio-intel-mid.c
+++ b/drivers/gpio/gpio-intel-mid.c
@@ -329,6 +329,7 @@ static int intel_gpio_probe(struct pci_dev *pdev,
u32 gpio_base;
u32 irq_base;
int retval;
+ struct gpio_irq_chip *girq;
struct intel_mid_gpio_ddata *ddata =
(struct intel_mid_gpio_ddata *)id->driver_data;
@@ -369,6 +370,22 @@ static int intel_gpio_probe(struct pci_dev *pdev,
spin_lock_init(&priv->lock);
+ girq = &priv->chip.irq;
+ girq->chip = &intel_mid_irqchip;
+ girq->parent_handler = intel_mid_irq_handler;
+ girq->num_parents = 1;
+ girq->parents = devm_kcalloc(&pdev->dev, 1,
+ sizeof(*girq->parents),
+ GFP_KERNEL);
+ if (!girq->parents)
+ return -ENOMEM;
+ girq->parents[0] = pdev->irq;
+ girq->first = irq_base;
+ girq->default_type = IRQ_TYPE_NONE;
+ girq->handler = handle_simple_irq;
+
+ intel_mid_irq_init_hw(priv);
+
pci_set_drvdata(pdev, priv);
retval = devm_gpiochip_add_data(&pdev->dev, &priv->chip, priv);
if (retval) {
@@ -376,24 +393,6 @@ static int intel_gpio_probe(struct pci_dev *pdev,
return retval;
}
- retval = gpiochip_irqchip_add(&priv->chip,
- &intel_mid_irqchip,
- irq_base,
- handle_simple_irq,
- IRQ_TYPE_NONE);
- if (retval) {
- dev_err(&pdev->dev,
- "could not connect irqchip to gpiochip\n");
- return retval;
- }
-
- intel_mid_irq_init_hw(priv);
-
- gpiochip_set_chained_irqchip(&priv->chip,
- &intel_mid_irqchip,
- pdev->irq,
- intel_mid_irq_handler);
-
pm_runtime_put_noidle(&pdev->dev);
pm_runtime_allow(&pdev->dev);
--
2.21.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox