Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [RFC V2 08/11] dt-bindings: interconnect: add MT8183 interconnect dt-bindings
From: Henry Chen @ 2019-08-19  1:39 UTC (permalink / raw)
  To: Rob Herring
  Cc: Nicolas Boichat, Weiyi Lu, James Liao, Viresh Kumar, linux-kernel,
	Stephen Boyd, Fan Chen, devicetree, linux-mediatek,
	Matthias Brugger, Georgi Djakov, linux-arm-kernel
In-Reply-To: <20190501202753.GA2862@bogus>

Hi Rob,

Sorry for late reply.

On Wed, 2019-05-01 at 15:27 -0500, Rob Herring wrote:
> On Tue, Apr 30, 2019 at 04:51:02PM +0800, Henry Chen wrote:
> > Add interconnect provider dt-bindings for MT8183.
> > 
> > Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
> > ---
> >  .../bindings/interconnect/mtk,mt8183.txt           | 24 ++++++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/interconnect/mtk,mt8183.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/interconnect/mtk,mt8183.txt b/Documentation/devicetree/bindings/interconnect/mtk,mt8183.txt
> > new file mode 100644
> > index 0000000..1cf1841
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/interconnect/mtk,mt8183.txt
> > @@ -0,0 +1,24 @@
> > +Mediatek MT8183 interconnect binding
> 
> This should be part of the dvfsrc binding.
ok, will add these into dvfsrc binding.
> 
> > +
> > +MT8183 interconnect providers support dram bandwidth requirements. The provider
> > +is able to communicate with the DVFSRC and send the dram bandwidth to it.
> > +Provider nodes must reside within an DVFSRC device node.
> > +
> > +Required properties :
> > +- compatible : shall contain only one of the following:
> > +			"mediatek,mt8183-emi-icc"
> > +- #interconnect-cells : should contain 1
> > +
> > +Examples:
> > +
> > +dvfsrc@10012000 {
> > +	compatible = "mediatek,mt8183-dvfsrc";
> > +	reg = <0 0x10012000 0 0x1000>;
> > +	clocks = <&infracfg CLK_INFRA_DVFSRC>;
> > +	clock-names = "dvfsrc";
> > +	ddr_emi: interconnect {
> > +		compatible = "mediatek,mt8183-emi-icc";
> > +		#interconnect-cells = <1>;
> 
> No need for a child node here. Just move #interconnect-cells to the 
> parent.
Ihave tried and it cannot work if move "#interconnect-cells" to the
parent.
The provider nodes must reside within an DVFSRC device node.
> 
> Rob



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC V2 06/11] soc: mediatek: add MT8183 dvfsrc support
From: Henry Chen @ 2019-08-19  1:35 UTC (permalink / raw)
  To: Ryan Case
  Cc: Nicolas Boichat, Weiyi Lu, James Liao, Viresh Kumar, linux-kernel,
	Stephen Boyd, Fan Chen, devicetree, Rob Herring, linux-mediatek,
	Matthias Brugger, Georgi Djakov, linux-arm-kernel
In-Reply-To: <CACjz--=OPx06-pLdoKv_h+y=4nSW0O7zrHM5=hPqTBvMAfmpWA@mail.gmail.com>

On Mon, 2019-06-10 at 14:00 -0700, Ryan Case wrote:
Hi Ryan,

Sorry for late reply.

> Hi Henry,
> 
> On Tue, Apr 30, 2019 at 2:45 AM Henry Chen <henryc.chen@mediatek.com> wrote:
> >
> > Add dvfsrc driver for MT8183
> >
> > Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
> > ---
> >  drivers/soc/mediatek/Kconfig      |  15 ++
> >  drivers/soc/mediatek/Makefile     |   1 +
> >  drivers/soc/mediatek/mtk-dvfsrc.c | 347 ++++++++++++++++++++++++++++++++++++++
> >  include/soc/mediatek/mtk_dvfsrc.h |  22 +++
> >  4 files changed, 385 insertions(+)
> >  create mode 100644 drivers/soc/mediatek/mtk-dvfsrc.c
> >  create mode 100644 include/soc/mediatek/mtk_dvfsrc.h
> >
> > diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> > index 17bd759..2721fd6 100644
> > --- a/drivers/soc/mediatek/Kconfig
> > +++ b/drivers/soc/mediatek/Kconfig
> > @@ -24,6 +24,21 @@ config MTK_INFRACFG
> >           INFRACFG controller contains various infrastructure registers not
> >           directly associated to any device.
> >
> > +config MTK_DVFSRC
> > +       bool "MediaTek DVFSRC Support"
> > +       depends on ARCH_MEDIATEK
> > +       default ARCH_MEDIATEK
> > +       select MTK_INFRACFG
> > +       select PM_GENERIC_DOMAINS if PM
> > +       depends on MTK_SCPSYS
> > +       help
> > +         Say yes here to add support for the MediaTek DVFSRC (dynamic voltage
> > +         and frequency scaling resource collector) found
> > +         on different MediaTek SoCs. The DVFSRC is a proprietary
> > +         hardware which is used to collect all the requests from
> > +         system and turn into the decision of minimum Vcore voltage
> > +         and minimum DRAM frequency to fulfill those requests.
> > +
> >  config MTK_PMIC_WRAP
> >         tristate "MediaTek PMIC Wrapper Support"
> >         depends on RESET_CONTROLLER
> > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> > index b9dbad6..cd9d63f 100644
> > --- a/drivers/soc/mediatek/Makefile
> > +++ b/drivers/soc/mediatek/Makefile
> > @@ -1,4 +1,5 @@
> >  obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
> > +obj-$(CONFIG_MTK_DVFSRC) += mtk-dvfsrc.o
> >  obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o mtk-scpsys-ext.o
> >  obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> >  obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> > diff --git a/drivers/soc/mediatek/mtk-dvfsrc.c b/drivers/soc/mediatek/mtk-dvfsrc.c
> > new file mode 100644
> > index 0000000..e54a654
> > --- /dev/null
> > +++ b/drivers/soc/mediatek/mtk-dvfsrc.c
> > @@ -0,0 +1,347 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018 MediaTek Inc.
> > + */
> > +#include <linux/arm-smccc.h>
> > +#include <linux/clk.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/notifier.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <soc/mediatek/mtk_dvfsrc.h>
> > +#include <soc/mediatek/mtk_sip.h>
> > +#include <dt-bindings/power/mt8183-power.h>
> > +#include <dt-bindings/soc/mtk,dvfsrc.h>
> > +#include <dt-bindings/soc/mtk,dvfsrc.h>
> > +#include "mtk-scpsys.h"
> > +
> > +#define DVFSRC_IDLE            0x00
> > +#define DVFSRC_GET_TARGET_LEVEL(x)     (((x) >> 0) & 0x0000ffff)
> > +#define DVFSRC_GET_CURRENT_LEVEL(x)    (((x) >> 16) & 0x0000ffff)
> > +
> > +#define MT8183_DVFSRC_OPP_LP4  0
> > +#define MT8183_DVFSRC_OPP_LP4X 1
> > +#define MT8183_DVFSRC_OPP_LP3  2
> > +
> > +struct dvfsrc_opp {
> > +       u32 vcore_opp;
> > +       u32 dram_opp;
> > +};
> > +
> > +struct dvfsrc_domain {
> > +       u32 id;
> > +       u32 state;
> > +};
> > +
> > +struct mtk_dvfsrc;
> > +struct dvfsrc_soc_data {
> > +       const int *regs;
> > +       u32 num_opp;
> > +       u32 num_domains;
> > +       const struct dvfsrc_opp **opps;
> > +       struct dvfsrc_domain *domains;
> > +       int (*get_target_level)(struct mtk_dvfsrc *dvfsrc);
> > +       int (*get_current_level)(struct mtk_dvfsrc *dvfsrc);
> > +       void (*set_dram_bw)(struct mtk_dvfsrc *dvfsrc, u64 bw);
> > +       void (*set_opp_level)(struct mtk_dvfsrc *dvfsrc, u32 level);
> > +};
> > +
> > +struct mtk_dvfsrc {
> > +       struct device *dev;
> > +       struct clk *clk_dvfsrc;
> > +       const struct dvfsrc_soc_data *dvd;
> > +       int dram_type;
> > +       void __iomem *regs;
> > +       struct mutex lock;
> > +       struct notifier_block scpsys_notifier;
> > +};
> > +
> > +static u32 dvfsrc_read(struct mtk_dvfsrc *dvfs, u32 offset)
> > +{
> > +       return readl(dvfs->regs + dvfs->dvd->regs[offset]);
> > +}
> > +
> > +static void dvfsrc_write(struct mtk_dvfsrc *dvfs, u32 offset, u32 val)
> > +{
> > +       writel(val, dvfs->regs + dvfs->dvd->regs[offset]);
> > +}
> > +
> > +enum dvfsrc_regs {
> > +       DVFSRC_SW_REQ,
> > +       DVFSRC_LEVEL,
> > +       DVFSRC_SW_BW_0,
> > +       DVFSRC_LAST,
> > +};
> > +
> > +static const int mt8183_regs[] = {
> > +       [DVFSRC_SW_REQ] =       0x4,
> > +       [DVFSRC_LEVEL] =        0xDC,
> > +       [DVFSRC_SW_BW_0] =      0x160,
> > +       [DVFSRC_LAST] =         0x308,
> > +};
> > +
> > +static bool dvfsrc_is_idle(struct mtk_dvfsrc *dvfsrc)
> > +{
> > +       if (!dvfsrc->dvd->get_target_level)
> > +               return true;
> > +
> > +       return dvfsrc->dvd->get_target_level(dvfsrc) == DVFSRC_IDLE;
> > +}
> > +
> > +static int dvfsrc_wait_for_idle(struct mtk_dvfsrc *dvfsrc)
> > +{
> > +       unsigned long timeout;
> > +
> > +       timeout = jiffies + usecs_to_jiffies(1000);
> > +
> > +       do {
> > +               if (dvfsrc_is_idle(dvfsrc))
> > +                       return 0;
> > +       } while (!time_after(jiffies, timeout));
> 
> This all seems like it would be better handled by readx_poll_timeout
> rather than rolling your own.
It's great suggestion, thanks.
> 
> > +
> > +       return -ETIMEDOUT;
> > +}
> > +
> > +static int mt8183_get_target_level(struct mtk_dvfsrc *dvfsrc)
> > +{
> > +       return DVFSRC_GET_TARGET_LEVEL(dvfsrc_read(dvfsrc, DVFSRC_LEVEL));
> > +}
> > +
> > +static int mt8183_get_current_level(struct mtk_dvfsrc *dvfsrc)
> > +{
> > +       return ffs(DVFSRC_GET_CURRENT_LEVEL(dvfsrc_read(dvfsrc, DVFSRC_LEVEL)));
> > +}
> > +
> > +static void mt8183_set_dram_bw(struct mtk_dvfsrc *dvfsrc, u64 bw)
> > +{
> > +       dvfsrc_write(dvfsrc, DVFSRC_SW_BW_0, bw);
> > +}
> > +
> > +static void mt8183_set_opp_level(struct mtk_dvfsrc *dvfsrc, u32 level)
> > +{
> > +       int vcore_opp, dram_opp;
> > +       const struct dvfsrc_opp *opp;
> > +
> > +       /* translate pstate to dvfsrc level, and set it to DVFSRC HW */
> > +       opp = &dvfsrc->dvd->opps[dvfsrc->dram_type][level - 1];
> > +       vcore_opp = opp->vcore_opp;
> > +       dram_opp = opp->dram_opp;
> > +
> > +       dev_dbg(dvfsrc->dev, "vcore_opp: %d, dram_opp: %d\n",
> > +               vcore_opp, dram_opp);
> > +       dvfsrc_write(dvfsrc, DVFSRC_SW_REQ, dram_opp | vcore_opp << 2);
> > +}
> > +
> > +void mtk_dvfsrc_send_request(const struct device *dev, u32 cmd, u64 data)
> > +{
> > +       struct mtk_dvfsrc *dvfsrc = dev_get_drvdata(dev);
> > +
> > +       dev_dbg(dvfsrc->dev, "cmd: %d, data: %llu\n", cmd, data);
> > +
> > +       mutex_lock(&dvfsrc->lock);
> > +
> > +       if (dvfsrc_wait_for_idle(dvfsrc)) {
> > +               dev_warn(dvfsrc->dev, "[%s] wait idle, last: %d -> %d\n",
> > +                        __func__, dvfsrc_read(dvfsrc, DVFSRC_LEVEL),
> > +               dvfsrc_read(dvfsrc, DVFSRC_LAST));
> > +               goto out;
> > +       }
> > +
> > +       switch (cmd) {
> > +       case MTK_DVFSRC_CMD_BW_REQUEST:
> > +               dvfsrc->dvd->set_dram_bw(dvfsrc, data);
> > +               goto out;
> > +       case MTK_DVFSRC_CMD_OPP_REQUEST:
> > +               dvfsrc->dvd->set_opp_level(dvfsrc, data);
> > +               break;
> > +       default:
> > +               dev_err(dvfsrc->dev, "unknown command: %d\n", cmd);
> > +               break;
> > +       }
> > +
> > +       if (dvfsrc_wait_for_idle(dvfsrc)) {
> > +               dev_warn(dvfsrc->dev, "[%s] wait idle, last: %d -> %d\n",
> > +                        __func__, dvfsrc_read(dvfsrc, DVFSRC_LEVEL),
> > +                        dvfsrc_read(dvfsrc, DVFSRC_LAST));
> > +               goto out;
> > +       }
> > +
> > +out:
> > +       mutex_unlock(&dvfsrc->lock);
> > +}
> > +EXPORT_SYMBOL(mtk_dvfsrc_send_request);
> > +
> > +static int dvfsrc_set_performance(struct notifier_block *b,
> > +                                 unsigned long l, void *v)
> > +{
> > +       int i, val, highest;
> 
> Variable names could be improved. "val" is only ever used to store the
> current level, would be nice to make the name more specific. Similarly
> "l" looks like it would be better as something state related.
> 
> val and highest at least should be u32.
ok, about naming, I will correct and make it more clearly.
> 
> > +       struct mtk_dvfsrc *dvfsrc;
> > +       struct scp_event_data *sc = v;
> > +       struct dvfsrc_domain *d;
> > +
> > +       if (sc->event_type != MTK_SCPSYS_PSTATE)
> > +               return 0;
> > +
> > +       dvfsrc = container_of(b, struct mtk_dvfsrc, scpsys_notifier);
> > +
> > +       d = dvfsrc->dvd->domains;
> > +
> > +       if (l > dvfsrc->dvd->num_opp) {
> > +               dev_err(dvfsrc->dev, "pstate out of range = %ld\n", l);
> > +               goto out;
> 
> Can just return 0;
ok.
> 
> > +       }
> > +
> > +       for (i = 0, highest = 0; i < dvfsrc->dvd->num_domains - 1; i++, d++) {
> 
> It's not immediately clear to me why a domain is skipped (the -1).
> This is either worth a comment or it may be a bug?
Indeed, it no need, I will check and re-test again, thanks.
> 
> > +               if (sc->domain_id == d->id)
> > +                       d->state = l;
> > +               if (d->state > highest)
> > +                       highest = d->state;
> > +       }
> > +
> > +       if (highest == 0) {
> > +               dev_err(dvfsrc->dev, "domain not match\n");
> 
> This text is incorrect. You're checking whether all domains had a
> state of zero, not whether you found a domain match. Is this check
> actually needed?
I intend to check if the domain match or no. To avoid confusing, I will
re-write it and used flag to check it.
> 
> > +               goto out;
> 
> return 0;
ok.
> 
> > +       }
> > +
> > +       mtk_dvfsrc_send_request(dvfsrc->dev, MTK_DVFSRC_CMD_OPP_REQUEST,
> > +                               highest);
> > +
> > +       val = dvfsrc->dvd->get_current_level(dvfsrc);
> > +
> > +       dev_dbg(dvfsrc->dev, "DVFSRC_LEVEL: %x, val: %x, DVFSRC_SW_REQ: %x\n",
> > +               dvfsrc_read(dvfsrc, DVFSRC_LEVEL), val,
> > +               dvfsrc_read(dvfsrc, DVFSRC_SW_REQ));
> 
> "val:" to "current level:" or something similarly descriptive.
ok.
> 
> > +
> > +       if (val < highest) {
> > +               dev_err(dvfsrc->dev, "current: %d < highest: %x\n",
> > +                       val, highest);
> 
> This message isn't clear and should be more explicit. Something like
> "Current level %d < highest requested %d"
> 
> > +               goto out;
> 
> return 0;
ok.
> 
> > +       }
> > +
> > +out:
> 
> Out label no longer needed.
ok.
> 
> > +       return 0;
> > +}
> > +
> > +static void pstate_notifier_register(struct mtk_dvfsrc *dvfsrc)
> > +{
> > +       dvfsrc->scpsys_notifier.notifier_call = dvfsrc_set_performance;
> > +       register_scpsys_notifier(&dvfsrc->scpsys_notifier);
> > +}
> > +
> > +static int mtk_dvfsrc_probe(struct platform_device *pdev)
> > +{
> > +       struct arm_smccc_res ares;
> > +       struct resource *res;
> > +       struct mtk_dvfsrc *dvfsrc;
> > +       int ret;
> > +
> > +       dvfsrc = devm_kzalloc(&pdev->dev, sizeof(*dvfsrc), GFP_KERNEL);
> > +       if (!dvfsrc)
> > +               return -ENOMEM;
> > +
> > +       dvfsrc->dvd = of_device_get_match_data(&pdev->dev);
> > +       dvfsrc->dev = &pdev->dev;
> > +
> > +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +       dvfsrc->regs = devm_ioremap_resource(&pdev->dev, res);
> > +       if (IS_ERR(dvfsrc->regs))
> > +               return PTR_ERR(dvfsrc->regs);
> > +
> > +       dvfsrc->clk_dvfsrc = devm_clk_get(dvfsrc->dev, "dvfsrc");
> > +       if (IS_ERR(dvfsrc->clk_dvfsrc)) {
> > +               dev_err(dvfsrc->dev, "failed to get clock: %ld\n",
> > +                       PTR_ERR(dvfsrc->clk_dvfsrc));
> > +               return PTR_ERR(dvfsrc->clk_dvfsrc);
> > +       }
> > +
> > +       ret = clk_prepare_enable(dvfsrc->clk_dvfsrc);
> > +       if (ret)
> > +               return ret;
> > +
> > +       mutex_init(&dvfsrc->lock);
> > +
> > +       arm_smccc_smc(MTK_SIP_SPM, MTK_SIP_SPM_DVFSRC_INIT, 0, 0, 0, 0, 0, 0,
> > +                     &ares);
> > +
> > +       if (!ares.a0) {
> > +               dvfsrc->dram_type = ares.a1;
> > +       } else {
> > +               dev_err(dvfsrc->dev, "init fails: %lu\n", ares.a0);
> > +               clk_disable_unprepare(dvfsrc->clk_dvfsrc);
> > +               return ares.a0;
> > +       }
> > +
> > +       platform_set_drvdata(pdev, dvfsrc);
> > +       pstate_notifier_register(dvfsrc);
> > +
> > +       return devm_of_platform_populate(&pdev->dev);
> > +}
> > +
> > +static const struct dvfsrc_opp dvfsrc_opp_mt8183_lp4[] = {
> > +       {0, 0}, {0, 1}, {0, 2}, {1, 2},
> > +};
> > +
> > +static const struct dvfsrc_opp dvfsrc_opp_mt8183_lp3[] = {
> > +       {0, 0}, {0, 1}, {1, 1}, {1, 2},
> > +};
> > +
> > +static const struct dvfsrc_opp *dvfsrc_opp_mt8183[] = {
> > +       [MT8183_DVFSRC_OPP_LP4] = dvfsrc_opp_mt8183_lp4,
> > +       [MT8183_DVFSRC_OPP_LP4X] = dvfsrc_opp_mt8183_lp3,
> > +       [MT8183_DVFSRC_OPP_LP3] = dvfsrc_opp_mt8183_lp3,
> > +};
> > +
> > +static struct dvfsrc_domain dvfsrc_domains_mt8183[] = {
> > +       { MT8183_POWER_DOMAIN_MFG_ASYNC, 0 },
> > +       { MT8183_POWER_DOMAIN_MFG, 0 },
> > +       { MT8183_POWER_DOMAIN_CAM, 0 },
> > +       { MT8183_POWER_DOMAIN_DISP, 0 },
> > +       { MT8183_POWER_DOMAIN_ISP, 0 },
> > +       { MT8183_POWER_DOMAIN_VDEC, 0 },
> > +       { MT8183_POWER_DOMAIN_VENC, 0 },
> > +};
> > +
> > +static const struct dvfsrc_soc_data mt8183_data = {
> > +       .opps = dvfsrc_opp_mt8183,
> > +       .num_opp = ARRAY_SIZE(dvfsrc_opp_mt8183_lp4),
> > +       .regs = mt8183_regs,
> > +       .domains = dvfsrc_domains_mt8183,
> > +       .num_domains = ARRAY_SIZE(dvfsrc_domains_mt8183),
> > +       .get_target_level = mt8183_get_target_level,
> > +       .get_current_level = mt8183_get_current_level,
> > +       .set_dram_bw = mt8183_set_dram_bw,
> > +       .set_opp_level = mt8183_set_opp_level,
> > +};
> > +
> > +static int mtk_dvfsrc_remove(struct platform_device *pdev)
> > +{
> > +       struct mtk_dvfsrc *dvfsrc = platform_get_drvdata(pdev);
> > +
> > +       clk_disable_unprepare(dvfsrc->clk_dvfsrc);
> > +
> > +       return 0;
> > +}
> > +
> > +static const struct of_device_id mtk_dvfsrc_of_match[] = {
> > +       {
> > +               .compatible = "mediatek,mt8183-dvfsrc",
> > +               .data = &mt8183_data,
> > +       }, {
> > +               /* sentinel */
> > +       },
> > +};
> > +
> > +static struct platform_driver mtk_dvfsrc_driver = {
> > +       .probe  = mtk_dvfsrc_probe,
> > +       .remove = mtk_dvfsrc_remove,
> > +       .driver = {
> > +               .name = "mtk-dvfsrc",
> > +               .of_match_table = of_match_ptr(mtk_dvfsrc_of_match),
> > +       },
> > +};
> > +
> > +builtin_platform_driver(mtk_dvfsrc_driver);
> > +
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_DESCRIPTION("MTK DVFSRC driver");
> > diff --git a/include/soc/mediatek/mtk_dvfsrc.h b/include/soc/mediatek/mtk_dvfsrc.h
> > new file mode 100644
> > index 0000000..e759a65
> > --- /dev/null
> > +++ b/include/soc/mediatek/mtk_dvfsrc.h
> > @@ -0,0 +1,22 @@
> > +/* SPDX-License-Identifier: GPL-2.0
> > + *
> > + * Copyright (c) 2018 MediaTek Inc.
> > + */
> > +#ifndef __SOC_MTK_DVFSRC_H
> > +#define __SOC_MTK_DVFSRC_H
> > +
> > +#define MTK_DVFSRC_CMD_BW_REQUEST      0
> > +#define MTK_DVFSRC_CMD_OPP_REQUEST     1
> > +
> > +#if IS_ENABLED(CONFIG_MTK_DVFSRC)
> > +void mtk_dvfsrc_send_request(const struct device *dev, u32 cmd, u64 data);
> > +
> > +#else
> > +
> > +static inline void mtk_dvfsrc_send_request(const struct device *dev, u32 cmd,
> > +                                          u64 data)
> > +{ return -ENODEV; }
> > +
> > +#endif /* CONFIG_MTK_DVFSRC */
> > +
> > +#endif
> > --
> > 1.9.1
> >



_______________________________________________
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] gpu: drm: mediatek: mtk_drm_drv.c: Add of_node_put() before goto
From: CK Hu @ 2019-08-19  1:30 UTC (permalink / raw)
  To: Nishka Dasgupta
  Cc: p.zabel, airlie, dri-devel, linux-mediatek, daniel, matthias.bgg,
	linux-arm-kernel
In-Reply-To: <20190706133021.3308-1-nishkadg.linux@gmail.com>

Hi, Nishka:

On Sat, 2019-07-06 at 19:00 +0530, Nishka Dasgupta wrote:
> Each iteration of for_each_child_of_node puts the previous
> node, but in the case of a goto from the middle of the loop, there is
> no put, thus causing a memory leak. Hence add an of_node_put before the
> goto in two places.
> Issue found with Coccinelle.

Applied to mediatek-drm-fixes-5.3 [1], thanks.

[1]
https://github.com/ckhu-mediatek/linux.git-tags/tree/mediatek-drm-fixes-5.3

Regards,
CK

> 
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 95fdbd0fbcac..2dffbc8c6d73 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -524,12 +524,15 @@ static int mtk_drm_probe(struct platform_device *pdev)
>  			comp = devm_kzalloc(dev, sizeof(*comp), GFP_KERNEL);
>  			if (!comp) {
>  				ret = -ENOMEM;
> +				of_node_put(node);
>  				goto err_node;
>  			}
>  
>  			ret = mtk_ddp_comp_init(dev, node, comp, comp_id, NULL);
> -			if (ret)
> +			if (ret) {
> +				of_node_put(node);
>  				goto err_node;
> +			}
>  
>  			private->ddp_comp[comp_id] = comp;
>  		}



_______________________________________________
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] clk: imx8mn: fix int pll clk gate
From: Peng Fan @ 2019-08-19  1:05 UTC (permalink / raw)
  To: Stephen Boyd, mturquette@baylibre.com, s.hauer@pengutronix.de,
	shawnguo@kernel.org
  Cc: Jacky Bai, Anson Huang, linux-kernel@vger.kernel.org,
	dl-linux-imx, kernel@pengutronix.de, festevam@gmail.com,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Abel Vesa
In-Reply-To: <20190816180246.D37BD20665@mail.kernel.org>

Hi Stephen,

> Subject: Re: [PATCH] clk: imx8mn: fix int pll clk gate
> 
> Quoting peng.fan@nxp.com (2019-08-13 18:53:12)
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > To Frac pll, the gate shift is 13, however to Int PLL the gate shift
> > is 11.
> >
> > Cc: <stable@vger.kernel.org>
> > Fixes: 96d6392b54db ("clk: imx: Add support for i.MX8MN clock driver")
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > Reviewed-by: Jacky Bai <ping.bai@nxp.com>
> > ---
> 
> This is a fix for a change in -next. Why is stable Cced?

Sorry, that was added by mistaken. Should I resend v2 to drop it?

Thanks,
Peng.

_______________________________________________
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 v2] arm: dts: rockchip: fix vcc_host_5v regulator for usb3 host
From: Kever Yang @ 2019-08-19  0:29 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: Mark Rutland, devicetree, Jonas Karlman, Katsuhiro Suzuki,
	linux-kernel, linux-rockchip, Chen-Yu Tsai, Rob Herring,
	Tomohiro Mayama, linux-arm-kernel
In-Reply-To: <2932927.UJgUFA1Pmh@phil>

Hi Heiko,

On 2019/8/16 下午8:24, Heiko Stuebner wrote:
> Hi Kever, TL,
>
> [added TL Lim for clarification]
>
> Am Donnerstag, 15. August 2019, 10:12:52 CEST schrieb Kever Yang:
>> According to rock64 schemetic V2 and V3, the VCC_HOST_5V output is
>> controlled by USB_20_HOST_DRV, which is the same as VCC_HOST1_5V.
> The v1 schematics I have do reference the GPIO0_A0 as controlling this
> supply, so the big question would be how to handle the different versions.
>
> Because adding this would probably break v1 boards in this function.
>
> @TL: where v1 boards also sold or were they only used during development?


I have check this with TL when I make this patch, the V1 hardware was 
never sold and only V2/V3

are available on the market.


Thanks,

- Kever

> If this were the case, we could just apply the patch, not caring about
> v1 boards, but if v1 boards were also sold to customers there would be
> more of a problem.
>
> Thanks
> Heiko
>
>
>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
>> ---
>>
>> Changes in v2:
>> - remove enable-active-high property
>>
>>   arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 11 ++---------
>>   1 file changed, 2 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
>> index 7cfd5ca6cc85..62936b432f9a 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
>> @@ -34,10 +34,9 @@
>>   
>>   	vcc_host_5v: vcc-host-5v-regulator {
>>   		compatible = "regulator-fixed";
>> -		enable-active-high;
>> -		gpio = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
>> +		gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
>>   		pinctrl-names = "default";
>> -		pinctrl-0 = <&usb30_host_drv>;
>> +		pinctrl-0 = <&usb20_host_drv>;
>>   		regulator-name = "vcc_host_5v";
>>   		regulator-always-on;
>>   		regulator-boot-on;
>> @@ -320,12 +319,6 @@
>>   			rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
>>   		};
>>   	};
>> -
>> -	usb3 {
>> -		usb30_host_drv: usb30-host-drv {
>> -			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
>> -		};
>> -	};
>>   };
>>   
>>   &sdmmc {
>>
>
>
>
>



_______________________________________________
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 1/2] dt-bindings: watchdog: Add ast2600 compatible
From: Andrew Jeffery @ 2019-08-19  0:16 UTC (permalink / raw)
  To: Joel Stanley, Wim Van Sebroeck, Guenter Roeck, Rob Herring
  Cc: devicetree, linux-aspeed, Ryan Chen, linux-watchdog,
	linux-arm-kernel
In-Reply-To: <20190816160347.23393-2-joel@jms.id.au>



On Sat, 17 Aug 2019, at 01:34, Joel Stanley wrote:
> This adds a compatible for the ast2600, a new ASPEED SoC.
> 
> Signed-off-by: Joel Stanley <joel@jms.id.au>

Reviewed-by: Andrew Jeffery <andrew@aj.id.au>

> ---
>  Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> index c5077a1f5cb3..d78d4a8fb868 100644
> --- a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> @@ -4,6 +4,7 @@ Required properties:
>   - compatible: must be one of:
>  	- "aspeed,ast2400-wdt"
>  	- "aspeed,ast2500-wdt"
> +	- "aspeed,ast2600-wdt"
>  
>   - reg: physical base address of the controller and length of memory mapped
>     region
> -- 
> 2.23.0.rc1
> 
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [BUG] removing and reinserting imx-media causes kernel to explode
From: Steve Longerbeam @ 2019-08-18 22:41 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: open list:STAGING SUBSYSTEM, Philipp Zabel, Ezequiel Garcia,
	Greg Kroah-Hartman, Sascha Hauer, open list, Sakari Ailus,
	NXP Linux Team, Pengutronix Kernel Team, Shawn Guo,
	Mauro Carvalho Chehab, Fabio Estevam,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	linux-media
In-Reply-To: <20190814092506.GH13294@shell.armlinux.org.uk>



On 8/14/19 2:25 AM, Russell King - ARM Linux admin wrote:
> I just did this:
>
> rmmod imx-media
> modprobe imx-media
>
> and was greeted by the below kernel messages.

Yes this needs fixing, the CSI needs to check first that it is already 
registered before going through the ->registered() steps. Posting a patch.

>    I don't think this has
> been the first issue I found with the iMX media stuff involving a module
> unload/reload cycle - may I suggest that this is added to the testing
> regime for this code?  Thanks.

I do test module unload/reload cycles, but v4l2-async does not support 
re-registering subdevices unless the subdevice is basically completely 
removed and re-probed, so there won't be a working media device if only 
imx-media is reloaded. So I have always unloaded/reloaded all modules 
for every entity in the graph, i.e.:

rmmod imx6_media imx6_media_csi imx6_mipi_csi2 ov5640 video_mux 
imx_media_common

(replace ov5640 with your imx219 sensor).

But I'll make sure to test single module unload/reload cycles in the future.

But note after applying the patch mentioned above to CSI ->registered() 
callback, there are list corruption backtraces, see [1]. The root cause 
is that both media_device_register_entity() and media_entity_pads_init() 
add the same graph objects for the entity's pads, so duplicate pad 
objects are added to the media device pads list. Removing the pad object 
creation in media_device_register_entity() fixes the list corruption. 
Sending a patch for that also.

This is a problem for any entity that sets its ->num_pads to a non-zero 
value before media_device_register_entity() is called. For example, the 
following will produce the same list corruption backtrace:

rmmod video-mux
modprobe video-mux
rmmod video-mux

Steve

[1]
rmmod imx6-media
modprobe imx6-media
rmmod imx6-media

[  249.387953] WARNING: CPU: 2 PID: 843 at lib/list_debug.c:53 
__list_del_entry_valid+0xa0/0xdc
[  249.396442] list_del corruption. prev->next should be e8fb0510, but 
was e93b5914
[  249.404076] Modules linked in: imx6_media_csi(C) imx6_media(C-) 
imx6_mipi_csi2(C) bnep dw_hdmi_ahb_audio dw_hdmi_cec ov5640 mux_mmio 
video_mux mux_core dw_hdmi_imx dw_hdmi coda_vpu cec imx_vdoa 
videobuf2_vmalloc imx_media_common(C) v4l2_fwnode imx_ldb imxdrm 
imx_ipu_v3 [last unloaded: imx6_media_csi]
[  249.430956] CPU: 2 PID: 843 Comm: rmmod Tainted: G C        
5.3.0-rc4-01115-g62119fd20fda #5
[  249.440115] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  249.446689] [<c0113a58>] (unwind_backtrace) from [<c010de5c>] 
(show_stack+0x10/0x14)
[  249.454462] [<c010de5c>] (show_stack) from [<c0bdfdcc>] 
(dump_stack+0xd8/0x110)
[  249.461804] [<c0bdfdcc>] (dump_stack) from [<c0128c28>] 
(__warn+0xe0/0x10c)
[  249.468789] [<c0128c28>] (__warn) from [<c0128c98>] 
(warn_slowpath_fmt+0x44/0x6c)
[  249.476301] [<c0128c98>] (warn_slowpath_fmt) from [<c04e8e00>] 
(__list_del_entry_valid+0xa0/0xdc)
[  249.485207] [<c04e8e00>] (__list_del_entry_valid) from [<c07e2b8c>] 
(media_gobj_destroy.part.4+0x30/0x64)
[  249.494802] [<c07e2b8c>] (media_gobj_destroy.part.4) from 
[<c07e01d4>] (__media_device_unregister_entity+0xa8/0xcc)
[  249.505259] [<c07e01d4>] (__media_device_unregister_entity) from 
[<c07e0224>] (media_device_unregister_entity+0x2c/0x38)
[  249.516157] [<c07e0224>] (media_device_unregister_entity) from 
[<c07ece34>] (v4l2_device_unregister_subdev+0x90/0xb4)
[  249.526793] [<c07ece34>] (v4l2_device_unregister_subdev) from 
[<c07f9668>] (v4l2_async_cleanup+0x10/0x3c)
[  249.536382] [<c07f9668>] (v4l2_async_cleanup) from [<c07f9730>] 
(v4l2_async_notifier_unbind_all_subdevs+0x9c/0x10c)
[  249.546840] [<c07f9730>] (v4l2_async_notifier_unbind_all_subdevs) 
from [<c07f9700>] (v4l2_async_notifier_unbind_all_subdevs+0x6c/0x10c)
[  249.559035] [<c07f9700>] (v4l2_async_notifier_unbind_all_subdevs) 
from [<c07fa3a0>] (__v4l2_async_notifier_unregister.part.4+0xc/0x44)
[  249.571140] [<c07fa3a0>] (__v4l2_async_notifier_unregister.part.4) 
from [<c07fa408>] (v4l2_async_notifier_unregister+0x30/0x50)
[  249.582665] [<c07fa408>] (v4l2_async_notifier_unregister) from 
[<bf03e020>] (imx_media_remove+0x20/0x54 [imx6_media])
[  249.593389] [<bf03e020>] (imx_media_remove [imx6_media]) from 
[<c064a684>] (platform_drv_remove+0x20/0x40)
[  249.603068] [<c064a684>] (platform_drv_remove) from [<c0648b50>] 
(device_release_driver_internal+0xdc/0x1ac)
[  249.612917] [<c0648b50>] (device_release_driver_internal) from 
[<c0648c7c>] (driver_detach+0x44/0x80)
[  249.622164] [<c0648c7c>] (driver_detach) from [<c0647404>] 
(bus_remove_driver+0x5c/0xd8)
[  249.630287] [<c0647404>] (bus_remove_driver) from [<c01d305c>] 
(sys_delete_module+0x17c/0x20c)
[  249.638926] [<c01d305c>] (sys_delete_module) from [<c0101000>] 
(ret_fast_syscall+0x0/0x28)
[  249.647205] Exception stack(0xe90d5fa8 to 0xe90d5ff0)
[  249.652278] 5fa0:                   beed5d6c 00000003 01401134 
00000800 4f13b6f4 00002002
[  249.660475] 5fc0: beed5d6c 00000003 beed5b80 00000081 beed5e78 
00000001 00000000 014010f8
[  249.668669] 5fe0: 0003b2c4 beed5b4c 0001f248 4f1012dc
[  249.673859] irq event stamp: 4113
[  249.677267] hardirqs last  enabled at (4131): [<c018d810>] 
console_unlock+0x408/0x5f8
[  249.685125] hardirqs last disabled at (4138): [<c018d490>] 
console_unlock+0x88/0x5f8
[  249.692970] softirqs last  enabled at (4154): [<c0102580>] 
__do_softirq+0x360/0x524
[  249.700735] softirqs last disabled at (4165): [<c01306ec>] 
irq_exit+0x12c/0x17c
[  249.708134] ---[ end trace 6fde63f19c7b10b8 ]---


Steve


_______________________________________________
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 2/2] arm64: dts: allwinner: h6: Introduce Tanix TX6 board
From: Clément Péron @ 2019-08-18 22:18 UTC (permalink / raw)
  To: Jernej Škrabec
  Cc: Mark Rutland, devicetree, kbuild test robot, linux-kernel,
	Maxime Ripard, Chen-Yu Tsai, Rob Herring, kbuild-all,
	linux-arm-kernel
In-Reply-To: <7640522.c0V0aH5rf2@jernej-laptop>

Hi,

On Sun, 18 Aug 2019 at 21:00, Jernej Škrabec <jernej.skrabec@siol.net> wrote:
>
> Dne nedelja, 18. avgust 2019 ob 20:42:49 CEST je kbuild test robot napisal(a):
> > Hi Jernej,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on linus/master]
> > [cannot apply to v5.3-rc4 next-20190816]
> > [if your patch is applied to the wrong git tree, please drop us a note to
> > help improve the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Jernej-Skrabec/dt-bindings-arm-sun
> > xi-Add-compatible-for-Tanix-TX6-board/20190819-002034 config:
> > arm64-defconfig (attached as .config)
> > compiler: aarch64-linux-gcc (GCC) 7.4.0
> > reproduce:
> >         wget
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> > ~/bin/make.cross chmod +x ~/bin/make.cross
> >         # save the attached .config to linux build tree
> >         GCC_VERSION=7.4.0 make.cross ARCH=arm64
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kbuild test robot <lkp@intel.com>
> >
> > All errors (new ones prefixed by >>):
> > >> Error: arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts:83.1-6 Label
> > >> or path r_ir not found FATAL ERROR: Syntax error parsing input tree
>
> Strange, Allwinner tree has commit, which introduces r_ir node:
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?
> h=sunxi/dt-for-5.4&id=9267811aad3524c857cf2e16bbadd8c569e15ab9
>
> Maybe kbuild test robot tree doesn't have it?
Yes Kbuild is on v5.3-rc4 vs the IR patch is planned for 5.4.

Regards,
Clément

>
> Best regards,
> Jernej
>
> >
> > ---
> > 0-DAY kernel test infrastructure                Open Source Technology
> > Center https://lists.01.org/pipermail/kbuild-all                   Intel
> > Corporation
>
>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
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 2/2] arm64: dts: allwinner: h6: Introduce Tanix TX6 board
From: Jernej Škrabec @ 2019-08-18 18:59 UTC (permalink / raw)
  To: kbuild test robot
  Cc: mark.rutland, devicetree, linux-kernel, mripard, wens, robh+dt,
	kbuild-all, linux-arm-kernel
In-Reply-To: <201908190222.ZdIp2gT1%lkp@intel.com>

Dne nedelja, 18. avgust 2019 ob 20:42:49 CEST je kbuild test robot napisal(a):
> Hi Jernej,
> 
> Thank you for the patch! Yet something to improve:
> 
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3-rc4 next-20190816]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
> 
> url:   
> https://github.com/0day-ci/linux/commits/Jernej-Skrabec/dt-bindings-arm-sun
> xi-Add-compatible-for-Tanix-TX6-board/20190819-002034 config:
> arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gcc (GCC) 7.4.0
> reproduce:
>         wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         GCC_VERSION=7.4.0 make.cross ARCH=arm64
> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
> 
> All errors (new ones prefixed by >>):
> >> Error: arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts:83.1-6 Label
> >> or path r_ir not found FATAL ERROR: Syntax error parsing input tree

Strange, Allwinner tree has commit, which introduces r_ir node:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?
h=sunxi/dt-for-5.4&id=9267811aad3524c857cf2e16bbadd8c569e15ab9

Maybe kbuild test robot tree doesn't have it?

Best regards,
Jernej

> 
> ---
> 0-DAY kernel test infrastructure                Open Source Technology
> Center https://lists.01.org/pipermail/kbuild-all                   Intel
> Corporation





_______________________________________________
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 2/2] arm64: dts: allwinner: h6: Introduce Tanix TX6 board
From: kbuild test robot @ 2019-08-18 18:42 UTC (permalink / raw)
  To: Jernej Skrabec
  Cc: mark.rutland, devicetree, jernej.skrabec, linux-kernel, mripard,
	wens, robh+dt, kbuild-all, linux-arm-kernel
In-Reply-To: <20190816205342.29552-3-jernej.skrabec@siol.net>

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

Hi Jernej,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc4 next-20190816]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Jernej-Skrabec/dt-bindings-arm-sunxi-Add-compatible-for-Tanix-TX6-board/20190819-002034
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=arm64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> Error: arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts:83.1-6 Label or path r_ir not found
>> FATAL ERROR: Syntax error parsing input tree

---
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: 45357 bytes --]

[-- Attachment #3: Type: text/plain, Size: 176 bytes --]

_______________________________________________
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 00/10] KVM: arm/arm64: vgic: ITS translation cache
From: Marc Zyngier @ 2019-08-18 17:55 UTC (permalink / raw)
  To: linux-arm-kernel, kvmarm, kvm
  Cc: Suzuki K Poulose, Raslan, KarimAllah, Andre Przywara,
	Christoffer Dall, Eric Auger, James Morse, Saidi, Ali, Zenghui Yu,
	Julien Thierry
In-Reply-To: <20190725153543.24386-1-maz@kernel.org>

On Thu, 25 Jul 2019 16:35:33 +0100
Marc Zyngier <maz@kernel.org> wrote:

> From: Marc Zyngier <marc.zyngier@arm.com>
> 
> It recently became apparent[1] that our LPI injection path is not as
> efficient as it could be when injecting interrupts coming from a VFIO
> assigned device.
> 
> Although the proposed patch wasn't 100% correct, it outlined at least
> two issues:
> 
> (1) Injecting an LPI from VFIO always results in a context switch to a
>     worker thread: no good
> 
> (2) We have no way of amortising the cost of translating a DID+EID pair
>     to an LPI number
> 
> The reason for (1) is that we may sleep when translating an LPI, so we
> do need a context process. A way to fix that is to implement a small
> LPI translation cache that could be looked up from an atomic
> context. It would also solve (2).
> 
> This is what this small series proposes. It implements a very basic
> LRU cache of pre-translated LPIs, which gets used to implement
> kvm_arch_set_irq_inatomic. The size of the cache is currently
> hard-coded at 16 times the number of vcpus, a number I have picked
> under the influence of Ali Saidi. If that's not enough for you, blame
> me, though.
> 
> Does it work? well, it doesn't crash, and is thus perfect. More
> seriously, I don't really have a way to benchmark it directly, so my
> observations are only indirect:
> 
> On a TX2 system, I run a 4 vcpu VM with an Ethernet interface passed
> to it directly. From the host, I inject interrupts using debugfs. In
> parallel, I look at the number of context switch, and the number of
> interrupts on the host. Without this series, I get the same number for
> both IRQ and CS (about half a million of each per second is pretty
> easy to reach). With this series, the number of context switches drops
> to something pretty small (in the low 2k), while the number of
> interrupts stays the same.
> 
> Yes, this is a pretty rubbish benchmark, what did you expect? ;-)
> 
> Andre did run some benchmarks of his own, with some rather positive
> results[2]. So I'm putting this out for people with real workloads to
> try out and report what they see.
> 
> [1] https://lore.kernel.org/lkml/1552833373-19828-1-git-send-email-yuzenghui@huawei.com/
> [2] https://www.spinics.net/lists/arm-kernel/msg742655.html
> 
> * From v2:
> 
>   - Added invalidation on turning the ITS off
>   - Added invalidation on MAPC with V=0
>   - Added Rb's from Eric
> 
> * From v1:
> 
>   - Fixed race on allocation, where the same LPI could be cached multiple times
>   - Now invalidate the cache on vgic teardown, avoiding memory leaks
>   - Change patch split slightly, general reshuffling
>   - Small cleanups here and there
>   - Rebased on 5.2-rc4
> 
> Marc Zyngier (10):
>   KVM: arm/arm64: vgic: Add LPI translation cache definition
>   KVM: arm/arm64: vgic: Add __vgic_put_lpi_locked primitive
>   KVM: arm/arm64: vgic-its: Add MSI-LPI translation cache invalidation
>   KVM: arm/arm64: vgic-its: Invalidate MSI-LPI translation cache on
>     specific commands
>   KVM: arm/arm64: vgic-its: Invalidate MSI-LPI translation cache on
>     disabling LPIs
>   KVM: arm/arm64: vgic-its: Invalidate MSI-LPI translation cache on ITS
>     disable
>   KVM: arm/arm64: vgic-its: Invalidate MSI-LPI translation cache on vgic
>     teardown
>   KVM: arm/arm64: vgic-its: Cache successful MSI->LPI translation
>   KVM: arm/arm64: vgic-its: Check the LPI translation cache on MSI
>     injection
>   KVM: arm/arm64: vgic-irqfd: Implement kvm_arch_set_irq_inatomic
> 
>  include/kvm/arm_vgic.h           |   3 +
>  virt/kvm/arm/vgic/vgic-init.c    |   5 +
>  virt/kvm/arm/vgic/vgic-irqfd.c   |  36 +++++-
>  virt/kvm/arm/vgic/vgic-its.c     | 207 +++++++++++++++++++++++++++++++
>  virt/kvm/arm/vgic/vgic-mmio-v3.c |   4 +-
>  virt/kvm/arm/vgic/vgic.c         |  26 ++--
>  virt/kvm/arm/vgic/vgic.h         |   5 +
>  7 files changed, 270 insertions(+), 16 deletions(-)
> 

FWIW, I've now queued this for 5.4, with Eric's RBs and Andre's TBs.

Thanks,

	M.
-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
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] KVM: arm/arm64: vgic: Make function comments match function declarations
From: Marc Zyngier @ 2019-08-18 17:44 UTC (permalink / raw)
  To: Alexandru Elisei
  Cc: kvm, suzuki.poulose, andre.przywara, eric.auger, julien.grall,
	james.morse, linux-arm-kernel, kvmarm, julien.thierry.kdev
In-Reply-To: <1565862982-9787-1-git-send-email-alexandru.elisei@arm.com>

On Thu, 15 Aug 2019 10:56:22 +0100
Alexandru Elisei <alexandru.elisei@arm.com> wrote:

> Since commit 503a62862e8f ("KVM: arm/arm64: vgic: Rely on the GIC driver to
> parse the firmware tables"), the vgic_v{2,3}_probe functions stopped using
> a DT node. Commit 909777324588 ("KVM: arm/arm64: vgic-new: vgic_init:
> implement kvm_vgic_hyp_init") changed the functions again, and now they
> require exactly one argument, a struct gic_kvm_info populated by the GIC
> driver. Unfortunately the comments regressed and state that a DT node is
> used instead. Change the function comments to reflect the current
> prototypes.
> 
> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> ---
>  virt/kvm/arm/vgic/vgic-v2.c | 7 ++++---
>  virt/kvm/arm/vgic/vgic-v3.c | 7 ++++---
>  2 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
> index 96aab77d0471..27b1ddf71aa0 100644
> --- a/virt/kvm/arm/vgic/vgic-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-v2.c
> @@ -354,10 +354,11 @@ int vgic_v2_map_resources(struct kvm *kvm)
>  DEFINE_STATIC_KEY_FALSE(vgic_v2_cpuif_trap);
>  
>  /**
> - * vgic_v2_probe - probe for a GICv2 compatible interrupt controller in DT
> - * @node:	pointer to the DT node
> + * vgic_v2_probe - probe for a VGICv2 compatible interrupt controller
> + * @info:	pointer to the GIC description
>   *
> - * Returns 0 if a GICv2 has been found, returns an error code otherwise
> + * Returns 0 if the VGICv2 has been probed successfully, returns an error code
> + * otherwise
>   */
>  int vgic_v2_probe(const struct gic_kvm_info *info)
>  {
> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
> index 0c653a1e5215..4874f3266bea 100644
> --- a/virt/kvm/arm/vgic/vgic-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-v3.c
> @@ -570,10 +570,11 @@ static int __init early_gicv4_enable(char *buf)
>  early_param("kvm-arm.vgic_v4_enable", early_gicv4_enable);
>  
>  /**
> - * vgic_v3_probe - probe for a GICv3 compatible interrupt controller in DT
> - * @node:	pointer to the DT node
> + * vgic_v3_probe - probe for a VGICv3 compatible interrupt controller
> + * @info:	pointer to the GIC description
>   *
> - * Returns 0 if a GICv3 has been found, returns an error code otherwise
> + * Returns 0 if the VGICv3 has been probed successfully, returns an error code
> + * otherwise
>   */
>  int vgic_v3_probe(const struct gic_kvm_info *info)
>  {


Queued, thanks.

	M.
-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
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] arm64/kvm: remove VMID rollover I-cache maintenance
From: Marc Zyngier @ 2019-08-18 17:42 UTC (permalink / raw)
  To: James Morse
  Cc: Mark Rutland, Suzuki K Poulose, Christoffer Dall,
	linux-arm-kernel, kvmarm, Julien Thierry
In-Reply-To: <1dca0489-9e85-cb8f-b846-b6da65f41773@arm.com>

On Fri, 16 Aug 2019 14:39:31 +0100
James Morse <james.morse@arm.com> wrote:

> Hi Mark,
> 
> On 06/08/2019 16:57, Mark Rutland wrote:
> > For VPIPT I-caches, we need I-cache maintenance on VMID rollover to
> > avoid an ABA problem. Consider a single vCPU VM, with a pinned stage-2,
> > running with an idmap VA->IPA and idmap IPA->PA. If we don't do
> > maintenance on rollover:
> > 
> >         // VMID A
> >         Writes insn X to PA 0xF
> >         Invalidates PA 0xF (for VMID A)
> > 
> >         I$ contains [{A,F}->X]
> > 
> >         [VMID ROLLOVER]
> > 
> >         // VMID B
> >         Writes insn Y to PA 0xF
> >         Invalidates PA 0xF (for VMID B)
> > 
> >         I$ contains [{A,F}->X, {B,F}->Y]
> > 
> >         [VMID ROLLOVER]
> > 
> >         // VMID A
> >         I$ contains [{A,F}->X, {B,F}->Y]
> > 
> >         Unexpectedly hits stale I$ line {A,F}->X.
> > 
> > However, for PIPT and VIPT I-caches, the VMID doesn't affect lookup or
> > constrain maintenance. Given the VMID doesn't affect PIPT and VIPT
> > I-caches, and given VMID rollover is independent of changes to stage-2
> > mappings, I-cache maintenance cannot be necessary on VMID rollover for
> > PIPT or VIPT I-caches.
> > 
> > This patch removes the maintenance on rollover for VIPT and PIPT
> > I-caches. At the same time, the unnecessary colons are removed from the
> > asm statement to make it more legible.  
> 
> Makes sense!
> 
> Reviewed-by: James Morse <james.morse@arm.com>

Queued for 5.4. Thanks both.

	M.
-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers
From: Krzysztof Kozlowski @ 2019-08-18 17:27 UTC (permalink / raw)
  To: Kukjin Kim, Krzysztof Kozlowski, Vladimir Zapolskiy,
	Kamil Konieczny, Herbert Xu, David S. Miller, Sylwester Nawrocki,
	Tomasz Figa, Chanwoo Choi, Michael Turquette, Stephen Boyd,
	linux-arm-kernel, linux-samsung-soc, linux-kernel, linux-crypto,
	linux-clk

Extend the patterns to cover all related files in respective
categories:
1. Samsung Exynos ARM architecture: add soc drivers headers and make
   directory matches consistent,
2. Samsung Security SubSystem driver (crypto): add bindings,
3. Samsung SoC clock drivers: add S3C24xx, S3C64xx and S5Pv210 bindings.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Vladimir Zapolskiy <vz@mleia.com>
Cc: Kamil Konieczny <k.konieczny@partner.samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

---

Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-clk@vger.kernel.org
---
 MAINTAINERS | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 420567d1519a..35a4002ac58b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2199,8 +2199,9 @@ F:	drivers/*/*s3c24*
 F:	drivers/*/*/*s3c24*
 F:	drivers/*/*s3c64xx*
 F:	drivers/*/*s5pv210*
-F:	drivers/memory/samsung/*
-F:	drivers/soc/samsung/*
+F:	drivers/memory/samsung/
+F:	drivers/soc/samsung/
+F:	include/linux/soc/samsung/
 F:	Documentation/arm/samsung/
 F:	Documentation/devicetree/bindings/arm/samsung/
 F:	Documentation/devicetree/bindings/sram/samsung-sram.txt
@@ -14174,6 +14175,8 @@ M:	Kamil Konieczny <k.konieczny@partner.samsung.com>
 L:	linux-crypto@vger.kernel.org
 L:	linux-samsung-soc@vger.kernel.org
 S:	Maintained
+F:	Documentation/devicetree/bindings/crypto/samsung-slimsss.txt
+F:	Documentation/devicetree/bindings/crypto/samsung-sss.txt
 F:	drivers/crypto/s5p-sss.c
 
 SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS
@@ -14194,6 +14197,8 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/snawrocki/clk.git
 F:	drivers/clk/samsung/
 F:	include/dt-bindings/clock/exynos*.h
 F:	Documentation/devicetree/bindings/clock/exynos*.txt
+F:	Documentation/devicetree/bindings/clock/samsung,s3c*
+F:	Documentation/devicetree/bindings/clock/samsung,s5p*
 
 SAMSUNG SPI DRIVERS
 M:	Kukjin Kim <kgene@kernel.org>
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v6 13/13] arm: dts: mt6323: add keys, power-controller, rtc and codec
From: Frank Wunderlich @ 2019-08-18 16:07 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190818160757.8206-1-frank-w@public-files.de>

From: Josef Friedl <josef.friedl@speed.at>

support poweroff and power-related keys on bpi-r2

Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v5: none
changes since v4: none
changes since v3: none
changes since v2: none (=v2 part 7)
---
 arch/arm/boot/dts/mt6323.dtsi | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/mt6323.dtsi b/arch/arm/boot/dts/mt6323.dtsi
index ba397407c1dd..7fda40ab5fe8 100644
--- a/arch/arm/boot/dts/mt6323.dtsi
+++ b/arch/arm/boot/dts/mt6323.dtsi
@@ -238,5 +238,32 @@
 				regulator-enable-ramp-delay = <216>;
 			};
 		};
+
+		mt6323keys: mt6323keys {
+			compatible = "mediatek,mt6323-keys";
+			mediatek,long-press-mode = <1>;
+			power-off-time-sec = <0>;
+
+			power {
+				linux,keycodes = <116>;
+				wakeup-source;
+			};
+
+			home {
+				linux,keycodes = <114>;
+			};
+		};
+
+		codec: mt6397codec {
+			compatible = "mediatek,mt6397-codec";
+		};
+
+		power-controller {
+			compatible = "mediatek,mt6323-pwrc";
+		};
+
+		rtc {
+			compatible = "mediatek,mt6323-rtc";
+		};
 	};
 };
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v6 12/13] MAINTAINERS: add Mediatek shutdown drivers
From: Frank Wunderlich @ 2019-08-18 16:07 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190818160757.8206-1-frank-w@public-files.de>

From: Josef Friedl <josef.friedl@speed.at>

add Section in MAINTAINERS file for poweroff driver

Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v5: none
changes since v4: none
changes since v3: moved SOB
changes since v2: none (=v2 part 6)
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6426db5198f0..4172a3177633 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10128,6 +10128,13 @@ S:	Maintained
 F:	drivers/net/dsa/mt7530.*
 F:	net/dsa/tag_mtk.c
 
+MEDIATEK BOARD LEVEL SHUTDOWN DRIVERS
+M:	Sean Wang <sean.wang@mediatek.com>
+L:	linux-pm@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
+F:	drivers/power/reset/mt6323-poweroff.c
+
 MEDIATEK JPEG DRIVER
 M:	Rick Chang <rick.chang@mediatek.com>
 M:	Bin Liu <bin.liu@mediatek.com>
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v6 11/13] power: reset: add driver for mt6323 poweroff
From: Frank Wunderlich @ 2019-08-18 16:07 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190818160757.8206-1-frank-w@public-files.de>

From: Josef Friedl <josef.friedl@speed.at>

add poweroff driver for mt6323 and make Makefile and Kconfig-Entries

Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v5: split out mfd/mt6397/core.h
changes since v4: none
changes since v3: none
changes since v2: none (=v2 part 5)
---
 drivers/power/reset/Kconfig           | 10 +++
 drivers/power/reset/Makefile          |  1 +
 drivers/power/reset/mt6323-poweroff.c | 97 +++++++++++++++++++++++++++
 3 files changed, 108 insertions(+)
 create mode 100644 drivers/power/reset/mt6323-poweroff.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index a564237278ff..c721939767eb 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -140,6 +140,16 @@ config POWER_RESET_LTC2952
 	  This driver supports an external powerdown trigger and board power
 	  down via the LTC2952. Bindings are made in the device tree.
 
+config POWER_RESET_MT6323
+       bool "MediaTek MT6323 power-off driver"
+       depends on MFD_MT6397
+       help
+         The power-off driver is responsible for externally shutdown down
+         the power of a remote MediaTek SoC MT6323 is connected to through
+         controlling a tiny circuit BBPU inside MT6323 RTC.
+
+         Say Y if you have a board where MT6323 could be found.
+
 config POWER_RESET_QNAP
 	bool "QNAP power-off driver"
 	depends on OF_GPIO && PLAT_ORION
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 85da3198e4e0..da37f8b851dc 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
 obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
 obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
 obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
+obj-$(CONFIG_POWER_RESET_MT6323) += mt6323-poweroff.o
 obj-$(CONFIG_POWER_RESET_QCOM_PON) += qcom-pon.o
 obj-$(CONFIG_POWER_RESET_OCELOT_RESET) += ocelot-reset.o
 obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
diff --git a/drivers/power/reset/mt6323-poweroff.c b/drivers/power/reset/mt6323-poweroff.c
new file mode 100644
index 000000000000..1caf43d9e46d
--- /dev/null
+++ b/drivers/power/reset/mt6323-poweroff.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Power off through MediaTek PMIC
+ *
+ * Copyright (C) 2018 MediaTek Inc.
+ *
+ * Author: Sean Wang <sean.wang@mediatek.com>
+ *
+ */
+
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/mt6397/core.h>
+#include <linux/mfd/mt6397/rtc.h>
+
+struct mt6323_pwrc {
+	struct device *dev;
+	struct regmap *regmap;
+	u32 base;
+};
+
+static struct mt6323_pwrc *mt_pwrc;
+
+static void mt6323_do_pwroff(void)
+{
+	struct mt6323_pwrc *pwrc = mt_pwrc;
+	unsigned int val;
+	int ret;
+
+	regmap_write(pwrc->regmap, pwrc->base + RTC_BBPU, RTC_BBPU_KEY);
+	regmap_write(pwrc->regmap, pwrc->base + RTC_WRTGR, 1);
+
+	ret = regmap_read_poll_timeout(pwrc->regmap,
+					pwrc->base + RTC_BBPU, val,
+					!(val & RTC_BBPU_CBUSY),
+					MTK_RTC_POLL_DELAY_US,
+					MTK_RTC_POLL_TIMEOUT);
+	if (ret)
+		dev_err(pwrc->dev, "failed to write BBPU: %d\n", ret);
+
+	/* Wait some time until system down, otherwise, notice with a warn */
+	mdelay(1000);
+
+	WARN_ONCE(1, "Unable to power off system\n");
+}
+
+static int mt6323_pwrc_probe(struct platform_device *pdev)
+{
+	struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
+	struct mt6323_pwrc *pwrc;
+	struct resource *res;
+
+	pwrc = devm_kzalloc(&pdev->dev, sizeof(*pwrc), GFP_KERNEL);
+	if (!pwrc)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	pwrc->base = res->start;
+	pwrc->regmap = mt6397_chip->regmap;
+	pwrc->dev = &pdev->dev;
+	mt_pwrc = pwrc;
+
+	pm_power_off = &mt6323_do_pwroff;
+
+	return 0;
+}
+
+static int mt6323_pwrc_remove(struct platform_device *pdev)
+{
+	if (pm_power_off == &mt6323_do_pwroff)
+		pm_power_off = NULL;
+
+	return 0;
+}
+
+static const struct of_device_id mt6323_pwrc_dt_match[] = {
+	{ .compatible = "mediatek,mt6323-pwrc" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mt6323_pwrc_dt_match);
+
+static struct platform_driver mt6323_pwrc_driver = {
+	.probe          = mt6323_pwrc_probe,
+	.remove         = mt6323_pwrc_remove,
+	.driver         = {
+		.name   = "mt6323-pwrc",
+		.of_match_table = mt6323_pwrc_dt_match,
+	},
+};
+
+module_platform_driver(mt6323_pwrc_driver);
+
+MODULE_DESCRIPTION("Poweroff driver for MT6323 PMIC");
+MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_LICENSE("GPL v2");
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v6 07/13] rtc: mt6397: improvements of rtc driver
From: Frank Wunderlich @ 2019-08-18 16:07 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190818160757.8206-1-frank-w@public-files.de>

From: Josef Friedl <josef.friedl@speed.at>

- use regmap_read_poll_timeout to drop while-loop
- use devm-api to drop remove-callback

Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v5: none
changes since v4: none
changes since v3: none
changes since v2:
- fix allocation after irq-request
- compatible for mt6323 in separate commit => part 5
---
 drivers/rtc/rtc-mt6397.c | 51 +++++++++++++++-------------------------
 1 file changed, 19 insertions(+), 32 deletions(-)

diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index c08ee5edf865..9370b7fc9f81 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -4,16 +4,19 @@
 * Author: Tianping.Fang <tianping.fang@mediatek.com>
 */
 
-#include <linux/delay.h>
-#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/mfd/mt6397/core.h>
 #include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
 #include <linux/regmap.h>
 #include <linux/rtc.h>
 #include <linux/mfd/mt6397/rtc.h>
+#include <linux/mod_devicetable.h>
 
 static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
 {
-	unsigned long timeout = jiffies + HZ;
 	int ret;
 	u32 data;
 
@@ -21,19 +24,13 @@ static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
 	if (ret < 0)
 		return ret;
 
-	while (1) {
-		ret = regmap_read(rtc->regmap, rtc->addr_base + RTC_BBPU,
-				  &data);
-		if (ret < 0)
-			break;
-		if (!(data & RTC_BBPU_CBUSY))
-			break;
-		if (time_after(jiffies, timeout)) {
-			ret = -ETIMEDOUT;
-			break;
-		}
-		cpu_relax();
-	}
+	ret = regmap_read_poll_timeout(rtc->regmap,
+					rtc->addr_base + RTC_BBPU, data,
+					!(data & RTC_BBPU_CBUSY),
+					MTK_RTC_POLL_DELAY_US,
+					MTK_RTC_POLL_TIMEOUT);
+	if (ret < 0)
+		dev_err(rtc->dev, "failed to write WRTGE: %d\n", ret);
 
 	return ret;
 }
@@ -266,19 +263,19 @@ static int mtk_rtc_probe(struct platform_device *pdev)
 		return rtc->irq;
 
 	rtc->regmap = mt6397_chip->regmap;
-	rtc->dev = &pdev->dev;
 	mutex_init(&rtc->lock);
 
 	platform_set_drvdata(pdev, rtc);
 
-	rtc->rtc_dev = devm_rtc_allocate_device(rtc->dev);
+	rtc->rtc_dev = devm_rtc_allocate_device(&pdev->dev);
 	if (IS_ERR(rtc->rtc_dev))
 		return PTR_ERR(rtc->rtc_dev);
 
-	ret = request_threaded_irq(rtc->irq, NULL,
-				   mtk_rtc_irq_handler_thread,
-				   IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
-				   "mt6397-rtc", rtc);
+	ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
+					mtk_rtc_irq_handler_thread,
+					IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
+					"mt6397-rtc", rtc);
+
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to request alarm IRQ: %d: %d\n",
 			rtc->irq, ret);
@@ -302,15 +299,6 @@ static int mtk_rtc_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int mtk_rtc_remove(struct platform_device *pdev)
-{
-	struct mt6397_rtc *rtc = platform_get_drvdata(pdev);
-
-	free_irq(rtc->irq, rtc);
-
-	return 0;
-}
-
 #ifdef CONFIG_PM_SLEEP
 static int mt6397_rtc_suspend(struct device *dev)
 {
@@ -349,7 +337,6 @@ static struct platform_driver mtk_rtc_driver = {
 		.pm = &mt6397_pm_ops,
 	},
 	.probe	= mtk_rtc_probe,
-	.remove = mtk_rtc_remove,
 };
 
 module_platform_driver(mtk_rtc_driver);
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v6 08/13] mfd: mt6323: some improvements of mt6397-core
From: Frank Wunderlich @ 2019-08-18 16:07 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190818160757.8206-1-frank-w@public-files.de>

From: Josef Friedl <josef.friedl@speed.at>

simplyfications (resource definitions my DEFINE_RES_* macros)

Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
---
changes since v5: none
changes since v4: do not touch year of copyright
changes since v3: moved part 6 forward to let compatible and driver be together
changes since v2: splitted v2 part 4 into 6+7
---
 drivers/mfd/mt6397-core.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 337bcccdb914..c9a81087fa55 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -5,6 +5,7 @@
  */
 
 #include <linux/interrupt.h>
+#include <linux/ioport.h>
 #include <linux/module.h>
 #include <linux/of_device.h>
 #include <linux/of_irq.h>
@@ -23,16 +24,8 @@
 #define MT6397_CID_CODE		0x97
 
 static const struct resource mt6397_rtc_resources[] = {
-	{
-		.start = MT6397_RTC_BASE,
-		.end   = MT6397_RTC_BASE + MT6397_RTC_SIZE,
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.start = MT6397_IRQ_RTC,
-		.end   = MT6397_IRQ_RTC,
-		.flags = IORESOURCE_IRQ,
-	},
+	DEFINE_RES_MEM(MT6397_RTC_BASE, MT6397_RTC_SIZE),
+	DEFINE_RES_IRQ(MT6397_IRQ_RTC),
 };
 
 static const struct resource mt6323_keys_resources[] = {
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v6 10/13] mfd: mt6323: add mt6323 rtc+pwrc
From: Frank Wunderlich @ 2019-08-18 16:07 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190818160757.8206-1-frank-w@public-files.de>

From: Josef Friedl <josef.friedl@speed.at>

add entry for rtc and power-controller to mt6323

Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
---
changes since v5: none
changes since v4: none
changes since v3: none
changes since v2: only splitting, second part of v2 part 4
---
 drivers/mfd/mt6397-core.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index c9a81087fa55..5916978a8feb 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -16,13 +16,24 @@
 #include <linux/mfd/mt6397/registers.h>
 #include <linux/mfd/mt6323/registers.h>
 
+#define MT6323_RTC_BASE		0x8000
+#define MT6323_RTC_SIZE		0x40
+
 #define MT6397_RTC_BASE		0xe000
 #define MT6397_RTC_SIZE		0x3e
 
+#define MT6323_PWRC_BASE	0x8000
+#define MT6323_PWRC_SIZE	0x40
+
 #define MT6323_CID_CODE		0x23
 #define MT6391_CID_CODE		0x91
 #define MT6397_CID_CODE		0x97
 
+static const struct resource mt6323_rtc_resources[] = {
+	DEFINE_RES_MEM(MT6323_RTC_BASE, MT6323_RTC_SIZE),
+	DEFINE_RES_IRQ(MT6323_IRQ_STATUS_RTC),
+};
+
 static const struct resource mt6397_rtc_resources[] = {
 	DEFINE_RES_MEM(MT6397_RTC_BASE, MT6397_RTC_SIZE),
 	DEFINE_RES_IRQ(MT6397_IRQ_RTC),
@@ -38,8 +49,17 @@ static const struct resource mt6397_keys_resources[] = {
 	DEFINE_RES_IRQ(MT6397_IRQ_HOMEKEY),
 };
 
+static const struct resource mt6323_pwrc_resources[] = {
+	DEFINE_RES_MEM(MT6323_PWRC_BASE, MT6323_PWRC_SIZE),
+};
+
 static const struct mfd_cell mt6323_devs[] = {
 	{
+		.name = "mt6323-rtc",
+		.num_resources = ARRAY_SIZE(mt6323_rtc_resources),
+		.resources = mt6323_rtc_resources,
+		.of_compatible = "mediatek,mt6323-rtc",
+	}, {
 		.name = "mt6323-regulator",
 		.of_compatible = "mediatek,mt6323-regulator"
 	}, {
@@ -50,6 +70,11 @@ static const struct mfd_cell mt6323_devs[] = {
 		.num_resources = ARRAY_SIZE(mt6323_keys_resources),
 		.resources = mt6323_keys_resources,
 		.of_compatible = "mediatek,mt6323-keys"
+	}, {
+		.name = "mt6323-pwrc",
+		.num_resources = ARRAY_SIZE(mt6323_pwrc_resources),
+		.resources = mt6323_pwrc_resources,
+		.of_compatible = "mediatek,mt6323-pwrc"
 	},
 };
 
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v6 09/13] rtc: mt6397: add compatible for mt6323
From: Frank Wunderlich @ 2019-08-18 16:07 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190818160757.8206-1-frank-w@public-files.de>

From: Josef Friedl <josef.friedl@speed.at>

use mt6397 rtc driver also for mt6323 but with different
base/size see "mfd: mt6323: add mt6323 rtc+pwrc"

Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v5: none
changes since v4: none
changes since v3: moved (was part 5)
changes since v2: splitted this from v2.3 suggested-by Alexandre Belloni
---
 drivers/rtc/rtc-mt6397.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index 9370b7fc9f81..21cd9cc8b4c7 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -325,6 +325,7 @@ static SIMPLE_DEV_PM_OPS(mt6397_pm_ops, mt6397_rtc_suspend,
 			mt6397_rtc_resume);
 
 static const struct of_device_id mt6397_rtc_of_match[] = {
+	{ .compatible = "mediatek,mt6323-rtc", },
 	{ .compatible = "mediatek,mt6397-rtc", },
 	{ }
 };
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v6 05/13] rtc: mt6397: move some common definitions into rtc.h
From: Frank Wunderlich @ 2019-08-18 16:07 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190818160757.8206-1-frank-w@public-files.de>

From: Josef Friedl <josef.friedl@speed.at>

move code to separate header-file to reuse definitions later
in poweroff-driver (drivers/power/reset/mt6323-poweroff.c)

Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v5: none
changes since v4: none
changes since v3: none
changes since v2: add missing commit-message
---
 drivers/rtc/rtc-mt6397.c       | 55 +-------------------------
 include/linux/mfd/mt6397/rtc.h | 71 ++++++++++++++++++++++++++++++++++
 2 files changed, 72 insertions(+), 54 deletions(-)
 create mode 100644 include/linux/mfd/mt6397/rtc.h

diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index b46ed4dc7015..c08ee5edf865 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -9,60 +9,7 @@
 #include <linux/module.h>
 #include <linux/regmap.h>
 #include <linux/rtc.h>
-#include <linux/irqdomain.h>
-#include <linux/platform_device.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
-#include <linux/io.h>
-#include <linux/mfd/mt6397/core.h>
-
-#define RTC_BBPU		0x0000
-#define RTC_BBPU_CBUSY		BIT(6)
-
-#define RTC_WRTGR		0x003c
-
-#define RTC_IRQ_STA		0x0002
-#define RTC_IRQ_STA_AL		BIT(0)
-#define RTC_IRQ_STA_LP		BIT(3)
-
-#define RTC_IRQ_EN		0x0004
-#define RTC_IRQ_EN_AL		BIT(0)
-#define RTC_IRQ_EN_ONESHOT	BIT(2)
-#define RTC_IRQ_EN_LP		BIT(3)
-#define RTC_IRQ_EN_ONESHOT_AL	(RTC_IRQ_EN_ONESHOT | RTC_IRQ_EN_AL)
-
-#define RTC_AL_MASK		0x0008
-#define RTC_AL_MASK_DOW		BIT(4)
-
-#define RTC_TC_SEC		0x000a
-/* Min, Hour, Dom... register offset to RTC_TC_SEC */
-#define RTC_OFFSET_SEC		0
-#define RTC_OFFSET_MIN		1
-#define RTC_OFFSET_HOUR		2
-#define RTC_OFFSET_DOM		3
-#define RTC_OFFSET_DOW		4
-#define RTC_OFFSET_MTH		5
-#define RTC_OFFSET_YEAR		6
-#define RTC_OFFSET_COUNT	7
-
-#define RTC_AL_SEC		0x0018
-
-#define RTC_PDN2		0x002e
-#define RTC_PDN2_PWRON_ALARM	BIT(4)
-
-#define RTC_MIN_YEAR		1968
-#define RTC_BASE_YEAR		1900
-#define RTC_NUM_YEARS		128
-#define RTC_MIN_YEAR_OFFSET	(RTC_MIN_YEAR - RTC_BASE_YEAR)
-
-struct mt6397_rtc {
-	struct device		*dev;
-	struct rtc_device	*rtc_dev;
-	struct mutex		lock;
-	struct regmap		*regmap;
-	int			irq;
-	u32			addr_base;
-};
+#include <linux/mfd/mt6397/rtc.h>
 
 static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
 {
diff --git a/include/linux/mfd/mt6397/rtc.h b/include/linux/mfd/mt6397/rtc.h
new file mode 100644
index 000000000000..b702c29e8c74
--- /dev/null
+++ b/include/linux/mfd/mt6397/rtc.h
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2014-2018 MediaTek Inc.
+ *
+ * Author: Tianping.Fang <tianping.fang@mediatek.com>
+ *        Sean Wang <sean.wang@mediatek.com>
+ */
+
+#ifndef _LINUX_MFD_MT6397_RTC_H_
+#define _LINUX_MFD_MT6397_RTC_H_
+
+#include <linux/jiffies.h>
+#include <linux/mutex.h>
+#include <linux/regmap.h>
+#include <linux/rtc.h>
+
+#define RTC_BBPU               0x0000
+#define RTC_BBPU_CBUSY         BIT(6)
+#define RTC_BBPU_KEY            (0x43 << 8)
+
+#define RTC_WRTGR              0x003c
+
+#define RTC_IRQ_STA            0x0002
+#define RTC_IRQ_STA_AL         BIT(0)
+#define RTC_IRQ_STA_LP         BIT(3)
+
+#define RTC_IRQ_EN             0x0004
+#define RTC_IRQ_EN_AL          BIT(0)
+#define RTC_IRQ_EN_ONESHOT     BIT(2)
+#define RTC_IRQ_EN_LP          BIT(3)
+#define RTC_IRQ_EN_ONESHOT_AL  (RTC_IRQ_EN_ONESHOT | RTC_IRQ_EN_AL)
+
+#define RTC_AL_MASK            0x0008
+#define RTC_AL_MASK_DOW                BIT(4)
+
+#define RTC_TC_SEC             0x000a
+/* Min, Hour, Dom... register offset to RTC_TC_SEC */
+#define RTC_OFFSET_SEC         0
+#define RTC_OFFSET_MIN         1
+#define RTC_OFFSET_HOUR                2
+#define RTC_OFFSET_DOM         3
+#define RTC_OFFSET_DOW         4
+#define RTC_OFFSET_MTH         5
+#define RTC_OFFSET_YEAR                6
+#define RTC_OFFSET_COUNT       7
+
+#define RTC_AL_SEC             0x0018
+
+#define RTC_PDN2               0x002e
+#define RTC_PDN2_PWRON_ALARM   BIT(4)
+
+#define RTC_MIN_YEAR           1968
+#define RTC_BASE_YEAR          1900
+#define RTC_NUM_YEARS          128
+#define RTC_MIN_YEAR_OFFSET    (RTC_MIN_YEAR - RTC_BASE_YEAR)
+
+#define MTK_RTC_POLL_DELAY_US  10
+#define MTK_RTC_POLL_TIMEOUT   (jiffies_to_usecs(HZ))
+
+struct mt6397_rtc {
+	struct device           *dev;
+	struct rtc_device       *rtc_dev;
+
+	/* Protect register access from multiple tasks */
+	struct mutex            lock;
+	struct regmap           *regmap;
+	int                     irq;
+	u32                     addr_base;
+};
+
+#endif /* _LINUX_MFD_MT6397_RTC_H_ */
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v6 06/13] mfd: mt6397: add mutex include
From: Frank Wunderlich @ 2019-08-18 16:07 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190818160757.8206-1-frank-w@public-files.de>

From: Josef Friedl <josef.friedl@speed.at>

add missing mutex.h

Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v5: separated from "power: reset: add driver for mt6323 poweroff"
---
 include/linux/mfd/mt6397/core.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/mfd/mt6397/core.h b/include/linux/mfd/mt6397/core.h
index 25a95e72179b..652da61e3711 100644
--- a/include/linux/mfd/mt6397/core.h
+++ b/include/linux/mfd/mt6397/core.h
@@ -7,6 +7,8 @@
 #ifndef __MFD_MT6397_CORE_H__
 #define __MFD_MT6397_CORE_H__
 
+#include <linux/mutex.h>
+
 enum mt6397_irq_numbers {
 	MT6397_IRQ_SPKL_AB = 0,
 	MT6397_IRQ_SPKR_AB,
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v6 04/13] dt-bindings: rtc: mediatek: add missing mt6397 rtc
From: Frank Wunderlich @ 2019-08-18 16:07 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190818160757.8206-1-frank-w@public-files.de>

From: Josef Friedl <josef.friedl@speed.at>

add missing devicetree-binding document for mt6397 rtc
in later patch driver is extended with mt6323 chip

Suggested-By: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v5: none
changes since v4: use relative path
changes since v3: moved SOB
changes since v2: splitted rtc-mt6397.txt from first patch
---
 .../devicetree/bindings/rtc/rtc-mt6397.txt    | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt6397.txt

diff --git a/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
new file mode 100644
index 000000000000..55a0c8874c03
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
@@ -0,0 +1,29 @@
+Device-Tree bindings for MediaTek PMIC based RTC
+
+MediaTek PMIC based RTC is an independent function of MediaTek PMIC that works
+as a type of multi-function device (MFD). The RTC can be configured and set up
+with PMIC wrapper bus which is a common resource shared with the other
+functions found on the same PMIC.
+
+For MediaTek PMIC MFD bindings, see:
+../mfd/mt6397.txt
+
+For MediaTek PMIC wrapper bus bindings, see:
+../soc/mediatek/pwrap.txt
+
+Required properties:
+- compatible: Should be one of follows
+       "mediatek,mt6323-rtc": for MT6323 PMIC
+       "mediatek,mt6397-rtc": for MT6397 PMIC
+
+Example:
+
+       pmic {
+               compatible = "mediatek,mt6323";
+
+               ...
+
+               rtc {
+                       compatible = "mediatek,mt6323-rtc";
+               };
+       };
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v6 03/13] dt-bindings: mfd: mediatek: add mt6323 power-controller
From: Frank Wunderlich @ 2019-08-18 16:07 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190818160757.8206-1-frank-w@public-files.de>

From: Josef Friedl <josef.friedl@speed.at>

- add powercontroller-section to existing binding-document
- add mt6323-pwrc bindings-document with example

Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
---
changes since v5: split out non-pwrc related changes
changes since v4: none
changes since v3: none
changes since v2: none (=v2 part 7)
---
 .../devicetree/bindings/mfd/mt6397.txt        |  6 ++++++
 .../bindings/power/reset/mt6323-poweroff.txt  | 20 +++++++++++++++++++
 2 files changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt

diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
index 5fccf987865b..a9b105ac00a8 100644
--- a/Documentation/devicetree/bindings/mfd/mt6397.txt
+++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
@@ -8,6 +8,7 @@ MT6397/MT6323 is a multifunction device with the following sub modules:
 - Clock
 - LED
 - Keys
+- Power controller
 
 It is interfaced to host controller using SPI interface by a proprietary hardware
 called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
@@ -48,6 +49,11 @@ Optional subnodes:
 		- compatible: "mediatek,mt6397-keys" or "mediatek,mt6323-keys"
 	see ../input/mtk-pmic-keys.txt
 
+- power-controller
+	Required properties:
+		- compatible: "mediatek,mt6323-pwrc"
+	For details, see ../power/reset/mt6323-poweroff.txt
+
 Example:
 	pwrap: pwrap@1000f000 {
 		compatible = "mediatek,mt8135-pwrap";
diff --git a/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt b/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
new file mode 100644
index 000000000000..933f0c48e887
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
@@ -0,0 +1,20 @@
+Device Tree Bindings for Power Controller on MediaTek PMIC
+
+The power controller which could be found on PMIC is responsible for externally
+powering off or on the remote MediaTek SoC through the circuit BBPU.
+
+Required properties:
+- compatible: Should be one of follows
+       "mediatek,mt6323-pwrc": for MT6323 PMIC
+
+Example:
+
+       pmic {
+               compatible = "mediatek,mt6323";
+
+               ...
+
+               power-controller {
+                       compatible = "mediatek,mt6323-pwrc";
+               };
+       }
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox