* [gpio:devel-cleanup-irqchip 47/47] drivers/pinctrl/intel/pinctrl-cherryview.c:1632:8: error: 'struct gpio_irq_chip' has no member named 'default_handler'; did you mean 'default_type'?
From: kbuild test robot @ 2019-08-20 10:37 UTC (permalink / raw)
To: Linus Walleij; +Cc: kbuild-all, linux-gpio
[-- Attachment #1: Type: text/plain, Size: 5257 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/linusw/linux-gpio.git devel-cleanup-irqchip
head: cbf47c505ab7882591e402576063e8b1600978ed
commit: cbf47c505ab7882591e402576063e8b1600978ed [47/47] RFC: pinctrl: cherryview: Pass irqchip when adding gpiochip
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
git checkout cbf47c505ab7882591e402576063e8b1600978ed
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/pinctrl/intel/pinctrl-cherryview.c: In function 'chv_gpio_probe':
>> drivers/pinctrl/intel/pinctrl-cherryview.c:1632:8: error: 'struct gpio_irq_chip' has no member named 'default_handler'; did you mean 'default_type'?
girq->default_handler = IRQ_TYPE_NONE;
^~~~~~~~~~~~~~~
default_type
vim +1632 drivers/pinctrl/intel/pinctrl-cherryview.c
1545
1546 static int chv_gpio_probe(struct chv_pinctrl *pctrl, int irq)
1547 {
1548 const struct chv_gpio_pinrange *range;
1549 struct gpio_chip *chip = &pctrl->chip;
1550 struct gpio_irq_chip *girq;
1551 bool need_valid_mask = !dmi_check_system(chv_no_valid_mask);
1552 const struct chv_community *community = pctrl->community;
1553 int ret, i, irq_base;
1554
1555 *chip = chv_gpio_chip;
1556
1557 chip->ngpio = community->pins[community->npins - 1].number + 1;
1558 chip->label = dev_name(pctrl->dev);
1559 chip->parent = pctrl->dev;
1560 chip->base = -1;
1561 chip->irq.need_valid_mask = need_valid_mask;
1562
1563 for (i = 0; i < community->ngpio_ranges; i++) {
1564 range = &community->gpio_ranges[i];
1565 ret = gpiochip_add_pin_range(chip, dev_name(pctrl->dev),
1566 range->base, range->base,
1567 range->npins);
1568 if (ret) {
1569 dev_err(pctrl->dev, "failed to add GPIO pin range\n");
1570 return ret;
1571 }
1572 }
1573
1574 /* Do not add GPIOs that can only generate GPEs to the IRQ domain */
1575 for (i = 0; i < community->npins; i++) {
1576 const struct pinctrl_pin_desc *desc;
1577 u32 intsel;
1578
1579 desc = &community->pins[i];
1580
1581 intsel = readl(chv_padreg(pctrl, desc->number, CHV_PADCTRL0));
1582 intsel &= CHV_PADCTRL0_INTSEL_MASK;
1583 intsel >>= CHV_PADCTRL0_INTSEL_SHIFT;
1584
1585 if (need_valid_mask && intsel >= community->nirqs)
1586 clear_bit(i, chip->irq.valid_mask);
1587 }
1588
1589 /*
1590 * The same set of machines in chv_no_valid_mask[] have incorrectly
1591 * configured GPIOs that generate spurious interrupts so we use
1592 * this same list to apply another quirk for them.
1593 *
1594 * See also https://bugzilla.kernel.org/show_bug.cgi?id=197953.
1595 */
1596 if (!need_valid_mask) {
1597 /*
1598 * Mask all interrupts the community is able to generate
1599 * but leave the ones that can only generate GPEs unmasked.
1600 */
1601 chv_writel(GENMASK(31, pctrl->community->nirqs),
1602 pctrl->regs + CHV_INTMASK);
1603 }
1604
1605 /* Clear all interrupts */
1606 chv_writel(0xffff, pctrl->regs + CHV_INTSTAT);
1607
1608 /*
1609 * FIXME: this picks as many IRQs as there are lines in the
1610 * "community", which is then later associated per-range below
1611 * registering the gpio_chip. This is actually hierarchical IRQ.
1612 */
1613 if (!need_valid_mask) {
1614 irq_base = devm_irq_alloc_descs(pctrl->dev, -1, 0,
1615 community->npins, NUMA_NO_NODE);
1616 if (irq_base < 0) {
1617 dev_err(pctrl->dev, "Failed to allocate IRQ numbers\n");
1618 return irq_base;
1619 }
1620 }
1621
1622 girq = &chip->irq;
1623 girq->chip = &chv_gpio_irqchip;
1624 girq->parent_handler = chv_gpio_irq_handler;
1625 girq->num_parents = 1;
1626 girq->parents = devm_kcalloc(pctrl->dev, 1,
1627 sizeof(*girq->parents),
1628 GFP_KERNEL);
1629 if (!girq->parents)
1630 return -ENOMEM;
1631 girq->parents[0] = irq;
> 1632 girq->default_handler = IRQ_TYPE_NONE;
1633 girq->handler = handle_bad_irq;
1634
1635 ret = devm_gpiochip_add_data(pctrl->dev, chip, pctrl);
1636 if (ret) {
1637 dev_err(pctrl->dev, "Failed to register gpiochip\n");
1638 return ret;
1639 }
1640
1641 /*
1642 * FIXME: this associates a different IRQ with each discrete range
1643 * inside the community. If we use the hierarchical irq support,
1644 * the .translate() function can do this translation for each IRQ.
1645 */
1646 if (!need_valid_mask) {
1647 for (i = 0; i < community->ngpio_ranges; i++) {
1648 range = &community->gpio_ranges[i];
1649
1650 irq_domain_associate_many(chip->irq.domain, irq_base,
1651 range->base, range->npins);
1652 irq_base += range->npins;
1653 }
1654 }
1655
1656 return 0;
1657 }
1658
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 69532 bytes --]
^ permalink raw reply
* Re: [PATCH] pinctrl: rk805: Make structures constant
From: Linus Walleij @ 2019-08-20 10:28 UTC (permalink / raw)
To: Nishka Dasgupta; +Cc: open list:GPIO SUBSYSTEM
In-Reply-To: <20190819075757.1753-1-nishkadg.linux@gmail.com>
On Mon, Aug 19, 2019 at 9:58 AM Nishka Dasgupta
<nishkadg.linux@gmail.com> wrote:
> Static structures rk805_pinctrl_desc and rk805_gpio_chip, of types
> gpio_chip and pinctrl_desc respectively, are not used except to be
> copied into the fields of a different variable. Hence make
> rk805_pinctrl_desc and rk805_gpio_chip both constant to protect them
> from unintended modification.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Patch applied!
Thanks
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Linus Walleij @ 2019-08-20 10:26 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Thierry Reding, Wei Xu, open list:GPIO SUBSYSTEM,
Linux Kernel Mailing List, linux-arm Mailing List,
Rafael J. Wysocki, Len Brown, Mika Westerberg, Linuxarm,
Shameerali Kolothum Thodi, Jonathan Cameron, John Garry,
Salil Mehta, Shiju Jose, jinying, Zhangyi ac, Liguozhu (Kenneth),
Tangkunshan, huangdaode
In-Reply-To: <CAHp75VcwDZdOwFsT4Gf-1a4tNGQdowK-RKRvSif2m7oTsVQNbw@mail.gmail.com>
On Tue, Aug 20, 2019 at 10:51 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Tue, Aug 20, 2019 at 10:12 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > Exactly what do you refer to when you want me to
> > "re-do the approach for IRQ handling"? Do you mean
> > this driver or are you referring to:
> >
> > commit e0d89728981393b7d694bd3419b7794b9882c92d
> > Author: Thierry Reding <treding@nvidia.com>
> > Date: Tue Nov 7 19:15:54 2017 +0100
> >
> > gpio: Implement tighter IRQ chip integration
> >
> > Currently GPIO drivers are required to add the GPIO chip and its
> > corresponding IRQ chip separately, which can result in a lot of
> > boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in
> > struct gpio_chip, that drivers can fill in if they want the GPIO core
> > to automatically register the IRQ chip associated with a GPIO chip.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> Yes.
OK let's fix this mess, it shouldn't be too hard, I've sent a first
few patches.
> > The problem comes from the problem/mess I am trying to
> > clean up in the first place. So if the new way of registering GPIO
> > irqchips is not working for ACPI, then we have to fix that instead
> > of reverting all attempts to use the new API IMO.
>
> Sorry for me being impatient and asking for a groundless requests.
> I'll help you with cleaning this.
Sorry if I sounded harsh :( I just have a bit of panic.
I am sure we can fix this, I only recently realized what a headache
the new API is going to be if I can't straighten it out and have to
keep the old stuff around forever in parallel.
Yours,
Linus Walleij
^ permalink raw reply
* RFC: is SIM connector switch a case for pinmux ?
From: Enrico Weigelt, metux IT consult @ 2019-08-20 10:17 UTC (permalink / raw)
To: open list:GPIO SUBSYSTEM, LKML
Hello folks,
I'm currently thinking about what would be the best fit for the
APU board's sim-switch functionality.
The boards have two sim sockets, where only one can be active at
a time (the lines are routed to mpcie slot), which can be controlled
via a gpio line.
Extconn doesn't seem to fit, as it IMHO only does the exact opposite
direction - detect what external connector is currently active (eg.
on slots that support multiple conntor types and switch automatically)
Pinmux might be an option, as this HW is some pin multiplexer, but in
this case it's not related SoC pins and doesn't control which internal
devices are connected to the outside.
I've already thought about introducing a new class for the pretty much
the opposite of extconn (maybe call it extswitch ?). There also might
be an semantic overlap w/ other subsystems, eg. kvm's connector
switching. Not sure whether yet another subsystem is the optimal
solution here.
What's your oppinion on that ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* linusw/fixes build: 6 builds: 0 failed, 6 passed, 34 warnings (v5.3-rc4-4-g607ff4deb08f)
From: kernelci.org bot @ 2019-08-20 10:01 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/fixes build: 6 builds: 0 failed, 6 passed, 34 warnings (v5.3-rc4-4-g607ff4deb08f)
Full Build Summary: https://kernelci.org/build/linusw/branch/fixes/kernel/v5.3-rc4-4-g607ff4deb08f/
Tree: linusw
Branch: fixes
Git Describe: v5.3-rc4-4-g607ff4deb08f
Git Commit: 607ff4deb08f986753f0b40e2d7840b61e11a46d
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Built: 6 unique architectures
Warnings Detected:
arc:
nsim_hs_defconfig (gcc-8): 5 warnings
arm64:
defconfig (gcc-8): 5 warnings
arm:
multi_v7_defconfig (gcc-8): 21 warnings
mips:
32r2el_defconfig (gcc-8): 3 warnings
riscv:
x86_64:
Warnings summary:
5 <stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
2 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:820:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
2 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:815:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
2 drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
2 drivers/gpu/drm/sun4i/sun4i_tcon.c:316:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 include/linux/compiler.h:328:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:459:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:440:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:424:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:370:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:352:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:332:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/sdhci-s3c.c:613:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/atmel-mci.c:2426:40: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/atmel-mci.c:2422:28: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/atmel-mci.c:2415:30: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/iommu/arm-smmu-v3.c:1189:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:992:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sti/sti_hdmi.c:855:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sti/sti_hdmi.c:853:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sti/sti_hdmi.c:851:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/dma/imx-dma.c:542:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 arch/arc/kernel/unwind.c:836:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 arch/arc/kernel/unwind.c:827:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-8) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
defconfig (riscv, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) — PASS, 0 errors, 5 warnings, 0 section mismatches
Warnings:
drivers/iommu/arm-smmu-v3.c:1189:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:815:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:820:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sun4i/sun4i_tcon.c:316:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 21 warnings, 0 section mismatches
Warnings:
drivers/dma/imx-dma.c:542:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/sdhci-s3c.c:613:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/atmel-mci.c:2415:30: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/atmel-mci.c:2422:28: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/atmel-mci.c:2426:40: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:815:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:820:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:424:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:440:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:459:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:332:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:352:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:370:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sti/sti_hdmi.c:851:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sti/sti_hdmi.c:853:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sti/sti_hdmi.c:855:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sun4i/sun4i_tcon.c:316:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:992:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-8) — PASS, 0 errors, 5 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
include/linux/compiler.h:328:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arc/kernel/unwind.c:827:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arc/kernel/unwind.c:836:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* linusw/for-next build: 6 builds: 0 failed, 6 passed, 34 warnings (v5.3-rc4-40-g67d5826a3303)
From: kernelci.org bot @ 2019-08-20 10:01 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/for-next build: 6 builds: 0 failed, 6 passed, 34 warnings (v5.3-rc4-40-g67d5826a3303)
Full Build Summary: https://kernelci.org/build/linusw/branch/for-next/kernel/v5.3-rc4-40-g67d5826a3303/
Tree: linusw
Branch: for-next
Git Describe: v5.3-rc4-40-g67d5826a3303
Git Commit: 67d5826a3303594c16292293ffe7b180f8a87352
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Built: 6 unique architectures
Warnings Detected:
arc:
nsim_hs_defconfig (gcc-8): 5 warnings
arm64:
defconfig (gcc-8): 5 warnings
arm:
multi_v7_defconfig (gcc-8): 21 warnings
mips:
32r2el_defconfig (gcc-8): 3 warnings
riscv:
x86_64:
Warnings summary:
5 <stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
2 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:800:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
2 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:795:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
2 drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
2 drivers/gpu/drm/sun4i/sun4i_tcon.c:316:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 include/linux/compiler.h:328:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:459:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:440:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:424:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:370:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:352:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:332:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/sdhci-s3c.c:613:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/atmel-mci.c:2426:40: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/atmel-mci.c:2422:28: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/atmel-mci.c:2415:30: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/iommu/arm-smmu-v3.c:1189:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:992:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sti/sti_hdmi.c:855:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sti/sti_hdmi.c:853:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sti/sti_hdmi.c:851:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/dma/imx-dma.c:542:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 arch/arc/kernel/unwind.c:836:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 arch/arc/kernel/unwind.c:827:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-8) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
defconfig (riscv, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) — PASS, 0 errors, 5 warnings, 0 section mismatches
Warnings:
drivers/iommu/arm-smmu-v3.c:1189:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:795:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:800:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sun4i/sun4i_tcon.c:316:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 21 warnings, 0 section mismatches
Warnings:
drivers/dma/imx-dma.c:542:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/sdhci-s3c.c:613:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/atmel-mci.c:2415:30: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/atmel-mci.c:2422:28: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/atmel-mci.c:2426:40: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:795:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:800:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:424:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:440:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:459:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:332:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:352:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:370:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sti/sti_hdmi.c:851:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sti/sti_hdmi.c:853:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sti/sti_hdmi.c:855:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sun4i/sun4i_tcon.c:316:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:992:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-8) — PASS, 0 errors, 5 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
include/linux/compiler.h:328:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arc/kernel/unwind.c:827:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arc/kernel/unwind.c:836:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* linusw/devel build: 6 builds: 0 failed, 6 passed, 13 warnings (v5.3-rc1-35-ga7e42142926f)
From: kernelci.org bot @ 2019-08-20 9:57 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/devel build: 6 builds: 0 failed, 6 passed, 13 warnings (v5.3-rc1-35-ga7e42142926f)
Full Build Summary: https://kernelci.org/build/linusw/branch/devel/kernel/v5.3-rc1-35-ga7e42142926f/
Tree: linusw
Branch: devel
Git Describe: v5.3-rc1-35-ga7e42142926f
Git Commit: a7e42142926f815c776f745d027f69a53415d99c
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Built: 6 unique architectures
Warnings Detected:
arc:
nsim_hs_defconfig (gcc-8): 2 warnings
arm64:
arm:
multi_v7_defconfig (gcc-8): 6 warnings
mips:
32r2el_defconfig (gcc-8): 3 warnings
riscv:
defconfig (gcc-8): 2 warnings
x86_64:
Warnings summary:
7 <stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dts:129.4-18: Warning (reg_format): /mdio-bus-mux/mdio@200:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #size-cells value
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #address-cells value
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-8) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
defconfig (riscv, gcc-8) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 6 warnings, 0 section mismatches
Warnings:
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:129.4-18: Warning (reg_format): /mdio-bus-mux/mdio@200:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #address-cells value
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #size-cells value
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-8) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Wei Xu @ 2019-08-20 9:27 UTC (permalink / raw)
To: Linus Walleij
Cc: Salil Mehta, jinying, Tangkunshan, Liguozhu (Kenneth), John Garry,
Rafael J. Wysocki, linux-kernel@vger.kernel.org,
Shameerali Kolothum Thodi, Linuxarm, open list:GPIO SUBSYSTEM,
Andy Shevchenko, huangdaode, Jonathan Cameron, Shiju Jose,
Mika Westerberg, Zhangyi ac, Linux ARM, Len Brown
In-Reply-To: <CACRpkdZFwANp-+fSmPPENLoh2Za2-fyf+aZ0VK79AnyRJs1H3A@mail.gmail.com>
Hi Linus,
On 2019/8/20 16:01, Linus Walleij wrote:
> On Mon, Aug 19, 2019 at 3:29 PM Wei Xu <xuwei5@hisilicon.com> wrote:
>
>> Invoke acpi_gpiochip_request_interrupts after the acpi data has been
>> attached to the pl061 acpi node to register interruption.
>>
>> Otherwise it will be failed to register interruption for the ACPI case.
>> Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
>> after gpiochip_add_irqchip but at that time the acpi data has not been
>> attached yet.
> We need to fix this problem in gpiochip_add_data_with_key() instead.
Thanks!
Best Regards,
Wei
> Yours,
> Linus Walleij
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
^ permalink raw reply
* Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Andy Shevchenko @ 2019-08-20 8:51 UTC (permalink / raw)
To: Linus Walleij
Cc: Thierry Reding, Wei Xu, open list:GPIO SUBSYSTEM,
Linux Kernel Mailing List, linux-arm Mailing List,
Rafael J. Wysocki, Len Brown, Mika Westerberg, Linuxarm,
Shameerali Kolothum Thodi, Jonathan Cameron, John Garry,
Salil Mehta, Shiju Jose, jinying, Zhangyi ac, Liguozhu (Kenneth),
Tangkunshan, huangdaode
In-Reply-To: <CACRpkdbRZ=88+ooW5jb5vu4Dwsaj7Ce+V5Ked2-bGn0JWpTHfQ@mail.gmail.com>
On Tue, Aug 20, 2019 at 10:12 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>
> > The proper fix is to revert the culprit since we call
> > acpi_gpiochip_request_interrupts() for all controllers.
> > Linus, please re-do the approach with IRQ handling,
>
> Exactly what do you refer to when you want me to
> "re-do the approach for IRQ handling"? Do you mean
> this driver or are you referring to:
>
> commit e0d89728981393b7d694bd3419b7794b9882c92d
> Author: Thierry Reding <treding@nvidia.com>
> Date: Tue Nov 7 19:15:54 2017 +0100
>
> gpio: Implement tighter IRQ chip integration
>
> Currently GPIO drivers are required to add the GPIO chip and its
> corresponding IRQ chip separately, which can result in a lot of
> boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in
> struct gpio_chip, that drivers can fill in if they want the GPIO core
> to automatically register the IRQ chip associated with a GPIO chip.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Yes.
> The new API introduced by this patch is what I am trying to switch
> everything over to, because the forked paths inside of gpiolib
> is causing me a maintenance headache and also increasing
> the footprint of the library.
Yes, I understand.
> > it seems broadly
> > regress with ACPI enabled platforms.
>
> It only becomes a problem if the platform uses ACPI right?
Unfortunately yes. Though in this case it was working and stopped working.
> But it's a problem if I can't really tell if a driver is using
> ACPI or not, there is no sign in the pl061 driver that it would
> be used on ACPI systems until now, so how do I design
> for it?
It's hidden under amba_driver_register() which works for all
registered thru drivers/acpi/acpi_amba.c.
I agree this is not straightforward.
> The problem comes from the problem/mess I am trying to
> clean up in the first place. So if the new way of registering GPIO
> irqchips is not working for ACPI, then we have to fix that instead
> of reverting all attempts to use the new API IMO.
Sorry for me being impatient and asking for a groundless requests.
I'll help you with cleaning this.
--
With Best Regards,
Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] gpio: mockup: don't depend twice on GPIOLIB
From: Linus Walleij @ 2019-08-20 8:42 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Bartosz Golaszewski, open list:GPIO SUBSYSTEM
In-Reply-To: <76951bc1-24a2-0d90-c977-55dfeb71d056@kleine-koenig.org>
On Mon, Aug 19, 2019 at 7:49 AM Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
> On 8/15/19 10:15 AM, Linus Walleij wrote:
> > I downloaded from lore.kernel.org and applied, thanks!
>
> Thanks for that. Though I'm not entirely happy with that as this
> procedure messed up my name in my S-o-b. Would you mind to fix that?
Grrr lore.kernel.org can't be trusted to handle UTF-8 right...
OK fixed it by hand, thanks for pointing it out.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Andy Shevchenko @ 2019-08-20 8:29 UTC (permalink / raw)
To: Linus Walleij
Cc: Thierry Reding, Wei Xu, open list:GPIO SUBSYSTEM,
Linux Kernel Mailing List, linux-arm Mailing List,
Rafael J. Wysocki, Len Brown, Mika Westerberg, Linuxarm,
Shameerali Kolothum Thodi, Jonathan Cameron, John Garry,
Salil Mehta, Shiju Jose, jinying, Zhangyi ac, Liguozhu (Kenneth),
Tangkunshan, huangdaode
In-Reply-To: <CACRpkdbRZ=88+ooW5jb5vu4Dwsaj7Ce+V5Ked2-bGn0JWpTHfQ@mail.gmail.com>
On Tue, Aug 20, 2019 at 10:12 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>
> > The proper fix is to revert the culprit since we call
> > acpi_gpiochip_request_interrupts() for all controllers.
> > Linus, please re-do the approach with IRQ handling,
>
> Exactly what do you refer to when you want me to
> "re-do the approach for IRQ handling"? Do you mean
> this driver or are you referring to:
>
> commit e0d89728981393b7d694bd3419b7794b9882c92d
> Author: Thierry Reding <treding@nvidia.com>
> Date: Tue Nov 7 19:15:54 2017 +0100
>
> gpio: Implement tighter IRQ chip integration
>
> Currently GPIO drivers are required to add the GPIO chip and its
> corresponding IRQ chip separately, which can result in a lot of
> boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in
> struct gpio_chip, that drivers can fill in if they want the GPIO core
> to automatically register the IRQ chip associated with a GPIO chip.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> The new API introduced by this patch is what I am trying to switch
> everything over to, because the forked paths inside of gpiolib
> is causing me a maintenance headache and also increasing
> the footprint of the library.
>
> > it seems broadly
> > regress with ACPI enabled platforms.
>
> It only becomes a problem if the platform uses ACPI right?
> But it's a problem if I can't really tell if a driver is using
> ACPI or not, there is no sign in the pl061 driver that it would
> be used on ACPI systems until now, so how do I design
> for it?
>
> The problem comes from the problem/mess I am trying to
> clean up in the first place. So if the new way of registering GPIO
> irqchips is not working for ACPI, then we have to fix that instead
> of reverting all attempts to use the new API IMO.
>
> Yours,
> Linus Walleij
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] gpio: Fix irqchip initialization order
From: Linus Walleij @ 2019-08-20 8:05 UTC (permalink / raw)
To: linux-gpio
Cc: Bartosz Golaszewski, Linus Walleij, Thierry Reding,
Grygorii Strashko, Wei Xu, Andy Shevchenko
The new API for registering a gpio_irq_chip along with a
gpio_chip has a different semantic ordering than the old
API which added the irqchip explicitly after registering
the gpio_chip.
Move the calls to add the gpio_irq_chip *last* in the
function, so that the different hooks setting up OF and
ACPI and machine gpio_chips are called *before* we try
to register the interrupts, preserving the elder semantic
order.
This cropped up in the PL061 driver which used to work
fine with no special ACPI quirks, but started to misbehave
using the new API.
Fixes: e0d897289813 ("gpio: Implement tighter IRQ chip integration")
Cc: Thierry Reding <treding@nvidia.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Wei Xu <xuwei5@hisilicon.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Reported-by: Wei Xu <xuwei5@hisilicon.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Wei: it would be great if you could test this and
confirm if it solves your problem, so I can apply this
for fixes.
---
drivers/gpio/gpiolib.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 80a2a2cb673b..cca749010cd0 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1373,21 +1373,13 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data,
if (status)
goto err_remove_from_list;
- status = gpiochip_irqchip_init_valid_mask(chip);
- if (status)
- goto err_remove_from_list;
-
status = gpiochip_alloc_valid_mask(chip);
if (status)
- goto err_remove_irqchip_mask;
-
- status = gpiochip_add_irqchip(chip, lock_key, request_key);
- if (status)
- goto err_free_gpiochip_mask;
+ goto err_remove_from_list;
status = of_gpiochip_add(chip);
if (status)
- goto err_remove_chip;
+ goto err_free_gpiochip_mask;
status = gpiochip_init_valid_mask(chip);
if (status)
@@ -1413,6 +1405,14 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data,
machine_gpiochip_add(chip);
+ status = gpiochip_irqchip_init_valid_mask(chip);
+ if (status)
+ goto err_remove_acpi_chip;
+
+ status = gpiochip_add_irqchip(chip, lock_key, request_key);
+ if (status)
+ goto err_remove_irqchip_mask;
+
/*
* By first adding the chardev, and then adding the device,
* we get a device node entry in sysfs under
@@ -1424,21 +1424,21 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data,
if (gpiolib_initialized) {
status = gpiochip_setup_dev(gdev);
if (status)
- goto err_remove_acpi_chip;
+ goto err_remove_irqchip;
}
return 0;
+err_remove_irqchip:
+ gpiochip_irqchip_remove(chip);
+err_remove_irqchip_mask:
+ gpiochip_irqchip_free_valid_mask(chip);
err_remove_acpi_chip:
acpi_gpiochip_remove(chip);
err_remove_of_chip:
gpiochip_free_hogs(chip);
of_gpiochip_remove(chip);
-err_remove_chip:
- gpiochip_irqchip_remove(chip);
err_free_gpiochip_mask:
gpiochip_free_valid_mask(chip);
-err_remove_irqchip_mask:
- gpiochip_irqchip_free_valid_mask(chip);
err_remove_from_list:
spin_lock_irqsave(&gpio_lock, flags);
list_del(&gdev->list);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Linus Walleij @ 2019-08-20 8:01 UTC (permalink / raw)
To: Wei Xu
Cc: open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org, Linux ARM,
Rafael J. Wysocki, Len Brown, Mika Westerberg, Andy Shevchenko,
Linuxarm, Shameerali Kolothum Thodi, Jonathan Cameron, John Garry,
Salil Mehta, Shiju Jose, jinying, Zhangyi ac, Liguozhu (Kenneth),
Tangkunshan, huangdaode
In-Reply-To: <1566221225-5170-1-git-send-email-xuwei5@hisilicon.com>
On Mon, Aug 19, 2019 at 3:29 PM Wei Xu <xuwei5@hisilicon.com> wrote:
> Invoke acpi_gpiochip_request_interrupts after the acpi data has been
> attached to the pl061 acpi node to register interruption.
>
> Otherwise it will be failed to register interruption for the ACPI case.
> Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
> after gpiochip_add_irqchip but at that time the acpi data has not been
> attached yet.
We need to fix this problem in gpiochip_add_data_with_key() instead.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Linus Walleij @ 2019-08-20 7:12 UTC (permalink / raw)
To: Andy Shevchenko, Thierry Reding
Cc: Wei Xu, open list:GPIO SUBSYSTEM, Linux Kernel Mailing List,
linux-arm Mailing List, Rafael J. Wysocki, Len Brown,
Mika Westerberg, Linuxarm, Shameerali Kolothum Thodi,
Jonathan Cameron, John Garry, Salil Mehta, Shiju Jose, jinying,
Zhangyi ac, Liguozhu (Kenneth), Tangkunshan, huangdaode
In-Reply-To: <CAHp75Vct3qtR5bDF6iALmduKEEq+gNL-btmzQVuWq_hYsmxKhw@mail.gmail.com>
On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> The proper fix is to revert the culprit since we call
> acpi_gpiochip_request_interrupts() for all controllers.
> Linus, please re-do the approach with IRQ handling,
Exactly what do you refer to when you want me to
"re-do the approach for IRQ handling"? Do you mean
this driver or are you referring to:
commit e0d89728981393b7d694bd3419b7794b9882c92d
Author: Thierry Reding <treding@nvidia.com>
Date: Tue Nov 7 19:15:54 2017 +0100
gpio: Implement tighter IRQ chip integration
Currently GPIO drivers are required to add the GPIO chip and its
corresponding IRQ chip separately, which can result in a lot of
boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in
struct gpio_chip, that drivers can fill in if they want the GPIO core
to automatically register the IRQ chip associated with a GPIO chip.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The new API introduced by this patch is what I am trying to switch
everything over to, because the forked paths inside of gpiolib
is causing me a maintenance headache and also increasing
the footprint of the library.
> it seems broadly
> regress with ACPI enabled platforms.
It only becomes a problem if the platform uses ACPI right?
But it's a problem if I can't really tell if a driver is using
ACPI or not, there is no sign in the pl061 driver that it would
be used on ACPI systems until now, so how do I design
for it?
The problem comes from the problem/mess I am trying to
clean up in the first place. So if the new way of registering GPIO
irqchips is not working for ACPI, then we have to fix that instead
of reverting all attempts to use the new API IMO.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4] arm64: dts: ls1088a: fix gpio node
From: Hui Song @ 2019-08-20 5:54 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Mark Rutland, Linus Walleij,
Bartosz Golaszewski
Cc: linux-arm-kernel, devicetree, linux-kernel, linux-gpio, Song Hui
From: Song Hui <hui.song_1@nxp.com>
add ls1088a gpio specify compatible.
Signed-off-by: Song Hui <hui.song_1@nxp.com>
---
Changes in v4:
- update the patch description.
Changes in v3:
- delete the attribute of little-endian.
Changes in v2:
- update the subject.
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index dfbead4..ff669c8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -269,7 +269,7 @@
};
gpio0: gpio@2300000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2300000 0x0 0x10000>;
interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
little-endian;
@@ -280,7 +280,7 @@
};
gpio1: gpio@2310000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2310000 0x0 0x10000>;
interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
little-endian;
@@ -291,7 +291,7 @@
};
gpio2: gpio@2320000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2320000 0x0 0x10000>;
interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
little-endian;
@@ -302,7 +302,7 @@
};
gpio3: gpio@2330000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2330000 0x0 0x10000>;
interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
little-endian;
--
2.9.5
^ permalink raw reply related
* Re: [PATCH v9 20/22] soc/tegra: pmc: Configure deep sleep control settings
From: Dmitry Osipenko @ 2019-08-19 19:33 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: <a8d65dbc-6924-c972-06e9-5bc47d66e94f@nvidia.com>
19.08.2019 22:07, Sowjanya Komatineni пишет:
>
> On 8/19/19 11:20 AM, Sowjanya Komatineni wrote:
>>
>> On 8/19/19 9:48 AM, Dmitry Osipenko wrote:
>>> 16.08.2019 22:42, Sowjanya Komatineni пишет:
>>>> Tegra210 and prior Tegra chips have deep sleep entry and wakeup related
>>>> timings which are platform specific that should be configured before
>>>> entering into deep sleep.
>>>>
>>>> Below are the timing specific configurations for deep sleep entry and
>>>> wakeup.
>>>> - Core rail power-on stabilization timer
>>>> - OSC clock stabilization timer after SOC rail power is stabilized.
>>>> - Core power off time is the minimum wake delay to keep the system
>>>> in deep sleep state irrespective of any quick wake event.
>>>>
>>>> These values depends on the discharge time of regulators and turn OFF
>>>> time of the PMIC to allow the complete system to finish entering into
>>>> deep sleep state.
>>>>
>>>> These values vary based on the platform design and are specified
>>>> through the device tree.
>>>>
>>>> This patch has implementation to configure these timings which are must
>>>> to have for proper deep sleep and wakeup operations.
>>>>
>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>> ---
>>>> drivers/soc/tegra/pmc.c | 14 +++++++++++++-
>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>>>> index 53ed70773872..710969043668 100644
>>>> --- a/drivers/soc/tegra/pmc.c
>>>> +++ b/drivers/soc/tegra/pmc.c
>>>> @@ -88,6 +88,8 @@
>>>> #define PMC_CPUPWRGOOD_TIMER 0xc8
>>>> #define PMC_CPUPWROFF_TIMER 0xcc
>>>> +#define PMC_COREPWRGOOD_TIMER 0x3c
>>>> +#define PMC_COREPWROFF_TIMER 0xe0
>>>> #define PMC_PWR_DET_VALUE 0xe4
>>>> @@ -2277,7 +2279,7 @@ static const struct tegra_pmc_regs
>>>> tegra20_pmc_regs = {
>>>> static void tegra20_pmc_init(struct tegra_pmc *pmc)
>>>> {
>>>> - u32 value;
>>>> + u32 value, osc, pmu, off;
>>>> /* Always enable CPU power request */
>>>> value = tegra_pmc_readl(pmc, PMC_CNTRL);
>>>> @@ -2303,6 +2305,16 @@ static void tegra20_pmc_init(struct tegra_pmc
>>>> *pmc)
>>>> value = tegra_pmc_readl(pmc, PMC_CNTRL);
>>>> value |= PMC_CNTRL_SYSCLK_OE;
>>>> tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>> +
>>>> + /* program core timings which are applicable only for suspend
>>>> state */
>>>> + if (pmc->suspend_mode != TEGRA_SUSPEND_NONE) {
>>>> + osc = DIV_ROUND_UP(pmc->core_osc_time * 8192, 1000000);
>>>> + pmu = DIV_ROUND_UP(pmc->core_pmu_time * 32768, 1000000);
>>>> + off = DIV_ROUND_UP(pmc->core_off_time * 32768, 1000000);
>>>> + tegra_pmc_writel(pmc, ((osc << 8) & 0xff00) | (pmu & 0xff),
>>>> + PMC_COREPWRGOOD_TIMER);
>>>> + tegra_pmc_writel(pmc, off, PMC_COREPWROFF_TIMER);
>>>> + }
>>>> }
>>>> static void tegra20_pmc_setup_irq_polarity(struct tegra_pmc *pmc,
>>>>
>>> In the previous version of this patch there were checks for zero values
>>> of the timers with intention to skip programming of the timers if value
>>> is zero. I'm a bit puzzled by the new version, given that SUSPEND_NONE
>>> means that suspending isn't available at all and thus PMC timers won't
>>> be utilized, hence it shouldn't matter what values are programmed for
>>> the counters, isn't it?
>>
>> Yes, as I see in documentation we already specify all these timings
>> are required properties when suspend mode is used, I updated in this
>> version to program core timings only when suspend mode is enabled.
>>
> In other words, core timings are for SC7 entry only. So when SC7/suspend
> mode is not used, these timings doesn't matter.
In this case, it should be a bit more straightforward to always program
the timers unconditionally. But since device-tree binding requires all
the properties to be specified when suspend mode isn't NONE, then the
new variant also makes sense. Either way is good to me, thanks.
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
^ permalink raw reply
* Re: [PATCH v3] gpiolib: Take MUX usage into account
From: Stefan Wahren @ 2019-08-19 19:27 UTC (permalink / raw)
To: Ramon Fried, linus.walleij, bgolaszewski; +Cc: linux-gpio, linux-kernel
In-Reply-To: <20190814110035.13451-1-ramon.fried@linux.intel.com>
Am 14.08.19 um 13:00 schrieb Ramon Fried:
> From: Stefan Wahren <stefan.wahren@i2se.com>
>
> The user space like gpioinfo only see the GPIO usage but not the
> MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to know which
> pin is free/safe to use. So take the MUX usage of strict pinmux controllers
> into account to get a more realistic view for ioctl GPIO_GET_LINEINFO_IOCTL.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Tested-by: Ramon Fried <rfried.dev@gmail.com>
> Signed-off-by: Ramon Fried <rfried.dev@gmail.com>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
^ permalink raw reply
* Re: [PATCH v9 20/22] soc/tegra: pmc: Configure deep sleep control settings
From: Sowjanya Komatineni @ 2019-08-19 19:07 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: <2092e557-06cb-4a74-fe40-1d83bf67ccca@nvidia.com>
On 8/19/19 11:20 AM, Sowjanya Komatineni wrote:
>
> On 8/19/19 9:48 AM, Dmitry Osipenko wrote:
>> 16.08.2019 22:42, Sowjanya Komatineni пишет:
>>> Tegra210 and prior Tegra chips have deep sleep entry and wakeup related
>>> timings which are platform specific that should be configured before
>>> entering into deep sleep.
>>>
>>> Below are the timing specific configurations for deep sleep entry and
>>> wakeup.
>>> - Core rail power-on stabilization timer
>>> - OSC clock stabilization timer after SOC rail power is stabilized.
>>> - Core power off time is the minimum wake delay to keep the system
>>> in deep sleep state irrespective of any quick wake event.
>>>
>>> These values depends on the discharge time of regulators and turn OFF
>>> time of the PMIC to allow the complete system to finish entering into
>>> deep sleep state.
>>>
>>> These values vary based on the platform design and are specified
>>> through the device tree.
>>>
>>> This patch has implementation to configure these timings which are must
>>> to have for proper deep sleep and wakeup operations.
>>>
>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>> ---
>>> drivers/soc/tegra/pmc.c | 14 +++++++++++++-
>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>>> index 53ed70773872..710969043668 100644
>>> --- a/drivers/soc/tegra/pmc.c
>>> +++ b/drivers/soc/tegra/pmc.c
>>> @@ -88,6 +88,8 @@
>>> #define PMC_CPUPWRGOOD_TIMER 0xc8
>>> #define PMC_CPUPWROFF_TIMER 0xcc
>>> +#define PMC_COREPWRGOOD_TIMER 0x3c
>>> +#define PMC_COREPWROFF_TIMER 0xe0
>>> #define PMC_PWR_DET_VALUE 0xe4
>>> @@ -2277,7 +2279,7 @@ static const struct tegra_pmc_regs
>>> tegra20_pmc_regs = {
>>> static void tegra20_pmc_init(struct tegra_pmc *pmc)
>>> {
>>> - u32 value;
>>> + u32 value, osc, pmu, off;
>>> /* Always enable CPU power request */
>>> value = tegra_pmc_readl(pmc, PMC_CNTRL);
>>> @@ -2303,6 +2305,16 @@ static void tegra20_pmc_init(struct tegra_pmc
>>> *pmc)
>>> value = tegra_pmc_readl(pmc, PMC_CNTRL);
>>> value |= PMC_CNTRL_SYSCLK_OE;
>>> tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>> +
>>> + /* program core timings which are applicable only for suspend
>>> state */
>>> + if (pmc->suspend_mode != TEGRA_SUSPEND_NONE) {
>>> + osc = DIV_ROUND_UP(pmc->core_osc_time * 8192, 1000000);
>>> + pmu = DIV_ROUND_UP(pmc->core_pmu_time * 32768, 1000000);
>>> + off = DIV_ROUND_UP(pmc->core_off_time * 32768, 1000000);
>>> + tegra_pmc_writel(pmc, ((osc << 8) & 0xff00) | (pmu & 0xff),
>>> + PMC_COREPWRGOOD_TIMER);
>>> + tegra_pmc_writel(pmc, off, PMC_COREPWROFF_TIMER);
>>> + }
>>> }
>>> static void tegra20_pmc_setup_irq_polarity(struct tegra_pmc *pmc,
>>>
>> In the previous version of this patch there were checks for zero values
>> of the timers with intention to skip programming of the timers if value
>> is zero. I'm a bit puzzled by the new version, given that SUSPEND_NONE
>> means that suspending isn't available at all and thus PMC timers won't
>> be utilized, hence it shouldn't matter what values are programmed for
>> the counters, isn't it?
>
> Yes, as I see in documentation we already specify all these timings
> are required properties when suspend mode is used, I updated in this
> version to program core timings only when suspend mode is enabled.
>
In other words, core timings are for SC7 entry only. So when SC7/suspend
mode is not used, these timings doesn't matter.
^ permalink raw reply
* Re: [PATCH v9 20/22] soc/tegra: pmc: Configure deep sleep control settings
From: Sowjanya Komatineni @ 2019-08-19 18:20 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: <bf5541d2-1bad-8a8c-fd9d-821b55861136@gmail.com>
On 8/19/19 9:48 AM, Dmitry Osipenko wrote:
> 16.08.2019 22:42, Sowjanya Komatineni пишет:
>> Tegra210 and prior Tegra chips have deep sleep entry and wakeup related
>> timings which are platform specific that should be configured before
>> entering into deep sleep.
>>
>> Below are the timing specific configurations for deep sleep entry and
>> wakeup.
>> - Core rail power-on stabilization timer
>> - OSC clock stabilization timer after SOC rail power is stabilized.
>> - Core power off time is the minimum wake delay to keep the system
>> in deep sleep state irrespective of any quick wake event.
>>
>> These values depends on the discharge time of regulators and turn OFF
>> time of the PMIC to allow the complete system to finish entering into
>> deep sleep state.
>>
>> These values vary based on the platform design and are specified
>> through the device tree.
>>
>> This patch has implementation to configure these timings which are must
>> to have for proper deep sleep and wakeup operations.
>>
>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>> ---
>> drivers/soc/tegra/pmc.c | 14 +++++++++++++-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>> index 53ed70773872..710969043668 100644
>> --- a/drivers/soc/tegra/pmc.c
>> +++ b/drivers/soc/tegra/pmc.c
>> @@ -88,6 +88,8 @@
>>
>> #define PMC_CPUPWRGOOD_TIMER 0xc8
>> #define PMC_CPUPWROFF_TIMER 0xcc
>> +#define PMC_COREPWRGOOD_TIMER 0x3c
>> +#define PMC_COREPWROFF_TIMER 0xe0
>>
>> #define PMC_PWR_DET_VALUE 0xe4
>>
>> @@ -2277,7 +2279,7 @@ static const struct tegra_pmc_regs tegra20_pmc_regs = {
>>
>> static void tegra20_pmc_init(struct tegra_pmc *pmc)
>> {
>> - u32 value;
>> + u32 value, osc, pmu, off;
>>
>> /* Always enable CPU power request */
>> value = tegra_pmc_readl(pmc, PMC_CNTRL);
>> @@ -2303,6 +2305,16 @@ static void tegra20_pmc_init(struct tegra_pmc *pmc)
>> value = tegra_pmc_readl(pmc, PMC_CNTRL);
>> value |= PMC_CNTRL_SYSCLK_OE;
>> tegra_pmc_writel(pmc, value, PMC_CNTRL);
>> +
>> + /* program core timings which are applicable only for suspend state */
>> + if (pmc->suspend_mode != TEGRA_SUSPEND_NONE) {
>> + osc = DIV_ROUND_UP(pmc->core_osc_time * 8192, 1000000);
>> + pmu = DIV_ROUND_UP(pmc->core_pmu_time * 32768, 1000000);
>> + off = DIV_ROUND_UP(pmc->core_off_time * 32768, 1000000);
>> + tegra_pmc_writel(pmc, ((osc << 8) & 0xff00) | (pmu & 0xff),
>> + PMC_COREPWRGOOD_TIMER);
>> + tegra_pmc_writel(pmc, off, PMC_COREPWROFF_TIMER);
>> + }
>> }
>>
>> static void tegra20_pmc_setup_irq_polarity(struct tegra_pmc *pmc,
>>
> In the previous version of this patch there were checks for zero values
> of the timers with intention to skip programming of the timers if value
> is zero. I'm a bit puzzled by the new version, given that SUSPEND_NONE
> means that suspending isn't available at all and thus PMC timers won't
> be utilized, hence it shouldn't matter what values are programmed for
> the counters, isn't it?
Yes, as I see in documentation we already specify all these timings are
required properties when suspend mode is used, I updated in this version
to program core timings only when suspend mode is enabled.
^ permalink raw reply
* Re: [PATCH v9 20/22] soc/tegra: pmc: Configure deep sleep control settings
From: Dmitry Osipenko @ 2019-08-19 16:48 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: <1565984527-5272-21-git-send-email-skomatineni@nvidia.com>
16.08.2019 22:42, Sowjanya Komatineni пишет:
> Tegra210 and prior Tegra chips have deep sleep entry and wakeup related
> timings which are platform specific that should be configured before
> entering into deep sleep.
>
> Below are the timing specific configurations for deep sleep entry and
> wakeup.
> - Core rail power-on stabilization timer
> - OSC clock stabilization timer after SOC rail power is stabilized.
> - Core power off time is the minimum wake delay to keep the system
> in deep sleep state irrespective of any quick wake event.
>
> These values depends on the discharge time of regulators and turn OFF
> time of the PMIC to allow the complete system to finish entering into
> deep sleep state.
>
> These values vary based on the platform design and are specified
> through the device tree.
>
> This patch has implementation to configure these timings which are must
> to have for proper deep sleep and wakeup operations.
>
> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
> ---
> drivers/soc/tegra/pmc.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
> index 53ed70773872..710969043668 100644
> --- a/drivers/soc/tegra/pmc.c
> +++ b/drivers/soc/tegra/pmc.c
> @@ -88,6 +88,8 @@
>
> #define PMC_CPUPWRGOOD_TIMER 0xc8
> #define PMC_CPUPWROFF_TIMER 0xcc
> +#define PMC_COREPWRGOOD_TIMER 0x3c
> +#define PMC_COREPWROFF_TIMER 0xe0
>
> #define PMC_PWR_DET_VALUE 0xe4
>
> @@ -2277,7 +2279,7 @@ static const struct tegra_pmc_regs tegra20_pmc_regs = {
>
> static void tegra20_pmc_init(struct tegra_pmc *pmc)
> {
> - u32 value;
> + u32 value, osc, pmu, off;
>
> /* Always enable CPU power request */
> value = tegra_pmc_readl(pmc, PMC_CNTRL);
> @@ -2303,6 +2305,16 @@ static void tegra20_pmc_init(struct tegra_pmc *pmc)
> value = tegra_pmc_readl(pmc, PMC_CNTRL);
> value |= PMC_CNTRL_SYSCLK_OE;
> tegra_pmc_writel(pmc, value, PMC_CNTRL);
> +
> + /* program core timings which are applicable only for suspend state */
> + if (pmc->suspend_mode != TEGRA_SUSPEND_NONE) {
> + osc = DIV_ROUND_UP(pmc->core_osc_time * 8192, 1000000);
> + pmu = DIV_ROUND_UP(pmc->core_pmu_time * 32768, 1000000);
> + off = DIV_ROUND_UP(pmc->core_off_time * 32768, 1000000);
> + tegra_pmc_writel(pmc, ((osc << 8) & 0xff00) | (pmu & 0xff),
> + PMC_COREPWRGOOD_TIMER);
> + tegra_pmc_writel(pmc, off, PMC_COREPWROFF_TIMER);
> + }
> }
>
> static void tegra20_pmc_setup_irq_polarity(struct tegra_pmc *pmc,
>
In the previous version of this patch there were checks for zero values
of the timers with intention to skip programming of the timers if value
is zero. I'm a bit puzzled by the new version, given that SUSPEND_NONE
means that suspending isn't available at all and thus PMC timers won't
be utilized, hence it shouldn't matter what values are programmed for
the counters, isn't it?
^ permalink raw reply
* Re: [PATCH v9 15/22] clk: tegra210: Add suspend and resume support
From: Dmitry Osipenko @ 2019-08-19 16:47 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: <1565984527-5272-16-git-send-email-skomatineni@nvidia.com>
16.08.2019 22:42, Sowjanya Komatineni пишет:
> This patch adds support for clk: tegra210: suspend-resume.
>
> All the CAR controller settings are lost on suspend when core
> power goes off.
>
> This patch has implementation for saving and restoring all PLLs
> and clocks context during system suspend and resume to have the
> clocks back to same state for normal operation.
>
> Clock driver suspend and resume are registered as syscore_ops as clocks
> restore need to happen before the other drivers resume to have all their
> clocks back to the same state as before suspend.
>
> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Looks good, thanks!
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
^ permalink raw reply
* Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Andy Shevchenko @ 2019-08-19 15:07 UTC (permalink / raw)
To: Wei Xu
Cc: open list:GPIO SUBSYSTEM, Linux Kernel Mailing List,
linux-arm Mailing List, Linus Walleij, Rafael J. Wysocki,
Len Brown, Mika Westerberg, Linuxarm, Shameerali Kolothum Thodi,
Jonathan Cameron, John Garry, Salil Mehta, Shiju Jose, jinying,
Zhangyi ac, Liguozhu (Kenneth), Tangkunshan, huangdaode
In-Reply-To: <1566221225-5170-1-git-send-email-xuwei5@hisilicon.com>
On Mon, Aug 19, 2019 at 4:29 PM Wei Xu <xuwei5@hisilicon.com> wrote:
>
> Invoke acpi_gpiochip_request_interrupts after the acpi data has been
> attached to the pl061 acpi node to register interruption.
>
> Otherwise it will be failed to register interruption for the ACPI case.
> Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
> after gpiochip_add_irqchip but at that time the acpi data has not been
> attached yet.
>
> Tested with below steps:
>
> qemu-system-aarch64 \
> -machine virt,gic-version=3 -cpu cortex-a57 \
> -m 1G,maxmem=4G,slots=4 \
> -kernel Image -initrd rootfs.cpio.gz \
> -net none -nographic \
> -bios QEMU_EFI.fd \
> -append "console=ttyAMA0 acpi=force earlycon=pl011,0x9000000"
>
> The pl061 interruption is missed and the following output is not in the
> /proc/interrupts on the v5.3-rc4 compared with the v5.2.0-rc7.
>
> 43: 0 ARMH0061:00 3 Edge ACPI:Event
The proper fix is to revert the culprit since we call
acpi_gpiochip_request_interrupts() for all controllers.
Linus, please re-do the approach with IRQ handling, it seems broadly
regress with ACPI enabled platforms.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] gpio: Use callback presence to determine need of valid_mask
From: Stephen Boyd @ 2019-08-19 14:06 UTC (permalink / raw)
To: Linus Walleij, linux-gpio
Cc: Bartosz Golaszewski, Linus Walleij, Benjamin Gaignard,
Amelie Delaunay, Bjorn Andersson
In-Reply-To: <20190819093058.10863-1-linus.walleij@linaro.org>
Quoting Linus Walleij (2019-08-19 02:30:58)
> After we switched the two drivers that have .need_valid_mask
> set to use the callback for setting up the .valid_mask,
> we can just use the presence of the .init_valid_mask()
> callback (or the OF reserved ranges, nota bene) to determine
> whether to allocate the mask or not and we can drop the
> .need_valid_mask field altogether.
>
> Cc: Benjamin Gaignard <benjamin.gaignard@st.com>
> Cc: Amelie Delaunay <amelie.delaunay@st.com>
> Cc: Stephen Boyd <swboyd@chromium.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
^ permalink raw reply
* Re: [PATCH] gpio: Pass mask and size with the init_valid_mask()
From: Stephen Boyd @ 2019-08-19 14:01 UTC (permalink / raw)
To: Linus Walleij, linux-gpio
Cc: Bartosz Golaszewski, Linus Walleij, Bjorn Andersson
In-Reply-To: <20190819084904.30027-1-linus.walleij@linaro.org>
Quoting Linus Walleij (2019-08-19 01:49:04)
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 7f35c196bb3e..a5d8f75da4a7 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -593,24 +593,25 @@ static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
> #define msm_gpio_dbg_show NULL
> #endif
>
> -static int msm_gpio_init_valid_mask(struct gpio_chip *chip)
> +static int msm_gpio_init_valid_mask(struct gpio_chip *gc,
Please leave the name as 'chip' like the other ops in this file. The
other uses of 'gc' in gpiolib are fine though.
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
^ permalink raw reply
* [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Wei Xu @ 2019-08-19 13:27 UTC (permalink / raw)
To: xuwei5, linux-gpio, linux-kernel, linux-arm-kernel, linus.walleij,
rjw, lenb, mika.westerberg, andy.shevchenko
Cc: linuxarm, shameerali.kolothum.thodi, jonathan.cameron, john.garry,
salil.mehta, shiju.jose, jinying, zhangyi.ac, liguozhu,
tangkunshan, huangdaode
Invoke acpi_gpiochip_request_interrupts after the acpi data has been
attached to the pl061 acpi node to register interruption.
Otherwise it will be failed to register interruption for the ACPI case.
Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
after gpiochip_add_irqchip but at that time the acpi data has not been
attached yet.
Tested with below steps:
qemu-system-aarch64 \
-machine virt,gic-version=3 -cpu cortex-a57 \
-m 1G,maxmem=4G,slots=4 \
-kernel Image -initrd rootfs.cpio.gz \
-net none -nographic \
-bios QEMU_EFI.fd \
-append "console=ttyAMA0 acpi=force earlycon=pl011,0x9000000"
The pl061 interruption is missed and the following output is not in the
/proc/interrupts on the v5.3-rc4 compared with the v5.2.0-rc7.
43: 0 ARMH0061:00 3 Edge ACPI:Event
Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
v2 -> v3:
* addressed the comments of Andy to show only affected output of
/proc/interrupts and drop the whole log of v5.2.0-rc7
v1- > v2:
* rebased on https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
* attached the log based on QEMU v3.0.0 and Linux kernel v5.2.0-rc7
---
drivers/gpio/gpio-pl061.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 722ce5c..e1a434e 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -8,6 +8,7 @@
*
* Data sheet: ARM DDI 0190B, September 2000
*/
+#include <linux/acpi.h>
#include <linux/spinlock.h>
#include <linux/errno.h>
#include <linux/init.h>
@@ -24,6 +25,9 @@
#include <linux/pinctrl/consumer.h>
#include <linux/pm.h>
+#include "gpiolib.h"
+#include "gpiolib-acpi.h"
+
#define GPIODIR 0x400
#define GPIOIS 0x404
#define GPIOIBE 0x408
@@ -345,6 +349,9 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
if (ret)
return ret;
+ if (has_acpi_companion(dev))
+ acpi_gpiochip_request_interrupts(&pl061->gc);
+
amba_set_drvdata(adev, pl061);
dev_info(dev, "PL061 GPIO chip registered\n");
--
2.8.1
^ 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