Re: [PATCH v2 9/9] rtc: Add support for the MediaTek MT6358 RTC
On Mon, 2019-03-11 at 11:46 +0800, Hsin-Hsiung Wang wrote: > From: Ran Bi > > This add support for the MediaTek MT6358 RTC. MT6397 mfd will pass > RTC_WRTGR address offset to RTC driver. > > Signed-off-by: Ran Bi > --- > drivers/rtc/rtc-mt6397.c | 16 ++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c > index f85f1fc..c8a0090 100644 > --- a/drivers/rtc/rtc-mt6397.c > +++ b/drivers/rtc/rtc-mt6397.c > @@ -27,7 +27,7 @@ > #define RTC_BBPU 0x > #define RTC_BBPU_CBUSY BIT(6) > > -#define RTC_WRTGR0x003c > +#define RTC_WRTGR_DEFAULT0x003c > > #define RTC_IRQ_STA 0x0002 > #define RTC_IRQ_STA_AL BIT(0) > @@ -78,6 +78,7 @@ struct mt6397_rtc { > struct regmap *regmap; > int irq; > u32 addr_base; > + u32 wrtgr_offset; It is strange that hardware change trigger register offset, I think we have no choice to add a field to describe it. > }; > > static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc) > @@ -86,7 +87,8 @@ static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc) > int ret; > u32 data; > > - ret = regmap_write(rtc->regmap, rtc->addr_base + RTC_WRTGR, 1); > + ret = regmap_write(rtc->regmap, > +rtc->addr_base + rtc->wrtgr_offset, 1); > if (ret < 0) > return ret; > > @@ -341,6 +343,15 @@ static int mtk_rtc_probe(struct platform_device *pdev) > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > rtc->addr_base = res->start; > > + res = platform_get_resource(pdev, IORESOURCE_REG, 0); > + if (res) { > + rtc->wrtgr_offset = res->start; > + dev_info(>dev, "register offset:%d\n", rtc->wrtgr_offset); Nit: useless log > + } else { > + rtc->wrtgr_offset = RTC_WRTGR_DEFAULT; > + dev_err(>dev, "Failed to get register offset\n"); > + } > + > rtc->irq = platform_get_irq(pdev, 0); > if (rtc->irq < 0) > return rtc->irq; > @@ -420,6 +431,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,mt6358-rtc", }, > { .compatible = "mediatek,mt6397-rtc", }, > { } > }; Without the log, you can my get Acked-by: Eddie Huang
Re: [PATCH v2 8/9] rtc: mt6397: fix alarm register overwrite
On Mon, 2019-03-11 at 11:46 +0800, Hsin-Hsiung Wang wrote: > From: Ran Bi > > Alarm registers high byte was reserved for other functions. > This add mask in alarm registers operation functions. > This also fix error condition in interrupt handler. > > Fixes: fc2979118f3f ("rtc: mediatek: Add MT6397 RTC driver") > > Signed-off-by: Ran Bi > --- > drivers/rtc/rtc-mt6397.c | 47 +-- > 1 file changed, 33 insertions(+), 14 deletions(-) > Thanks your interrupt and race condition fix Acked-by: Eddie Huang
Re: [PATCH 1/3] rtc: mt6397: fix possible race condition
On Sun, 2018-09-09 at 22:38 +0200, Alexandre Belloni wrote: > The IRQ is requested before the struct rtc is allocated and registered, but > this struct is used in the IRQ handler. This may lead to a NULL pointer > dereference. > > Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc > before requesting the IRQ. > > Cc: Eddie Huang > Cc: Sean Wang > Signed-off-by: Alexandre Belloni > --- > drivers/rtc/rtc-mt6397.c | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c > index 385f8303bb41..e9a25ec4d434 100644 > --- a/drivers/rtc/rtc-mt6397.c > +++ b/drivers/rtc/rtc-mt6397.c > @@ -332,6 +332,10 @@ static int mtk_rtc_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, rtc); > > + rtc->rtc_dev = devm_rtc_allocate_device(rtc->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, > @@ -344,11 +348,11 @@ static int mtk_rtc_probe(struct platform_device *pdev) > > device_init_wakeup(>dev, 1); > > - rtc->rtc_dev = rtc_device_register("mt6397-rtc", >dev, > -_rtc_ops, THIS_MODULE); > - if (IS_ERR(rtc->rtc_dev)) { > + rtc->rtc_dev->ops = _rtc_ops; > + > + ret = rtc_register_device(rtc->rtc_dev); > + if (ret) { > dev_err(>dev, "register rtc device failed\n"); > - ret = PTR_ERR(rtc->rtc_dev); > goto out_free_irq; > } > > @@ -365,7 +369,6 @@ static int mtk_rtc_remove(struct platform_device *pdev) > { > struct mt6397_rtc *rtc = platform_get_drvdata(pdev); > > - rtc_device_unregister(rtc->rtc_dev); > free_irq(rtc->irq, rtc->rtc_dev); > irq_dispose_mapping(rtc->irq); > Thanks Acked-by: Eddie Huang
Re: [PATCH 1/3] rtc: mt6397: fix possible race condition
On Sun, 2018-09-09 at 22:38 +0200, Alexandre Belloni wrote: > The IRQ is requested before the struct rtc is allocated and registered, but > this struct is used in the IRQ handler. This may lead to a NULL pointer > dereference. > > Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc > before requesting the IRQ. > > Cc: Eddie Huang > Cc: Sean Wang > Signed-off-by: Alexandre Belloni > --- > drivers/rtc/rtc-mt6397.c | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c > index 385f8303bb41..e9a25ec4d434 100644 > --- a/drivers/rtc/rtc-mt6397.c > +++ b/drivers/rtc/rtc-mt6397.c > @@ -332,6 +332,10 @@ static int mtk_rtc_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, rtc); > > + rtc->rtc_dev = devm_rtc_allocate_device(rtc->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, > @@ -344,11 +348,11 @@ static int mtk_rtc_probe(struct platform_device *pdev) > > device_init_wakeup(>dev, 1); > > - rtc->rtc_dev = rtc_device_register("mt6397-rtc", >dev, > -_rtc_ops, THIS_MODULE); > - if (IS_ERR(rtc->rtc_dev)) { > + rtc->rtc_dev->ops = _rtc_ops; > + > + ret = rtc_register_device(rtc->rtc_dev); > + if (ret) { > dev_err(>dev, "register rtc device failed\n"); > - ret = PTR_ERR(rtc->rtc_dev); > goto out_free_irq; > } > > @@ -365,7 +369,6 @@ static int mtk_rtc_remove(struct platform_device *pdev) > { > struct mt6397_rtc *rtc = platform_get_drvdata(pdev); > > - rtc_device_unregister(rtc->rtc_dev); > free_irq(rtc->irq, rtc->rtc_dev); > irq_dispose_mapping(rtc->irq); > Thanks Acked-by: Eddie Huang
Re: [PATCH 3/4] rtc: mediatek: enhance the description for MediaTek PMIC based RTC
Hi Sean, On Fri, 2017-09-22 at 11:33 +0800, sean.w...@mediatek.com wrote: > From: Sean Wang <sean.w...@mediatek.com> > > Give a better description for original MediaTek RTC driver as PMIC based > RTC in order to distinguish SoC based RTC. Also turning all words with > Mediatek to MediaTek here. > > Cc: Eddie Huang <eddie.hu...@mediatek.com> > Signed-off-by: Sean Wang <sean.w...@mediatek.com> > --- > drivers/rtc/Kconfig | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig > index 4226295..4500f77 100644 > --- a/drivers/rtc/Kconfig > +++ b/drivers/rtc/Kconfig > @@ -1716,14 +1716,14 @@ config RTC_DRV_MEDIATEK > will be called rtc-mediatek. > > config RTC_DRV_MT6397 > - tristate "Mediatek Real Time Clock driver" > + tristate "MediaTek PMIC based RTC" > depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN) > help > - This selects the Mediatek(R) RTC driver. RTC is part of Mediatek > + This selects the MediaTek(R) RTC driver. RTC is part of MediaTek > MT6397 PMIC. You should enable MT6397 PMIC MFD before select > - Mediatek(R) RTC driver. > + MediaTek(R) RTC driver. > > - If you want to use Mediatek(R) RTC interface, select Y or M here. > + If you want to use MediaTek(R) RTC interface, select Y or M here. > > config RTC_DRV_XGENE > tristate "APM X-Gene RTC" Thanks your correction. Acked-by: Eddie Huang <eddie.hu...@mediatek.com> Regards,
Re: [PATCH 3/4] rtc: mediatek: enhance the description for MediaTek PMIC based RTC
Hi Sean, On Fri, 2017-09-22 at 11:33 +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > Give a better description for original MediaTek RTC driver as PMIC based > RTC in order to distinguish SoC based RTC. Also turning all words with > Mediatek to MediaTek here. > > Cc: Eddie Huang > Signed-off-by: Sean Wang > --- > drivers/rtc/Kconfig | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig > index 4226295..4500f77 100644 > --- a/drivers/rtc/Kconfig > +++ b/drivers/rtc/Kconfig > @@ -1716,14 +1716,14 @@ config RTC_DRV_MEDIATEK > will be called rtc-mediatek. > > config RTC_DRV_MT6397 > - tristate "Mediatek Real Time Clock driver" > + tristate "MediaTek PMIC based RTC" > depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN) > help > - This selects the Mediatek(R) RTC driver. RTC is part of Mediatek > + This selects the MediaTek(R) RTC driver. RTC is part of MediaTek > MT6397 PMIC. You should enable MT6397 PMIC MFD before select > - Mediatek(R) RTC driver. > + MediaTek(R) RTC driver. > > - If you want to use Mediatek(R) RTC interface, select Y or M here. > + If you want to use MediaTek(R) RTC interface, select Y or M here. > > config RTC_DRV_XGENE > tristate "APM X-Gene RTC" Thanks your correction. Acked-by: Eddie Huang Regards,
Re: [PATCH v4 1/3] cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC
On Thu, 2017-07-13 at 08:46 +0530, Viresh Kumar wrote: > On 12-07-17, 16:50, Matthias Brugger wrote: > > Hi Eddie, > > > > On 07/11/2017 04:49 AM, Eddie Huang wrote: > > >Hi Sean, > > > > > >On Mon, 2017-07-10 at 22:23 +0800, sean.w...@mediatek.com wrote: > > >>From: Sean Wang <sean.w...@mediatek.com> > > >> > > >>MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with > > >>single cluster and this hardware is also compatible with the existing > > >>driver through enabling CPU frequency feature with operating-points-v2 > > >>bindings. Also, this driver actually supports all MediaTek SoCs, the > > >>Kconfig menu entry and file name itself should be updated with more > > >>generic name to drop "MT8173" > > >> > > >>Signed-off-by: Sean Wang <sean.w...@mediatek.com> > > >>Acked-by: Viresh Kumar <viresh.ku...@linaro.org> > > >>Reviewed-by: Jean Delvare <jdelv...@suse.de> > > >>--- > > >> drivers/cpufreq/Kconfig.arm | 7 +++ > > >> drivers/cpufreq/Makefile | 2 +- > > >> drivers/cpufreq/{mt8173-cpufreq.c => mediatek-cpufreq.c} | 2 ++ > > >> 3 files changed, 6 insertions(+), 5 deletions(-) > > >> rename drivers/cpufreq/{mt8173-cpufreq.c => mediatek-cpufreq.c} (99%) > > >> > > > > > >As Viresh mentioned, there are already many drivers use "mtk" as > > Do you have a link to when I mentioned this? > > /me suffering from Amnesia ? :) Sorry, my fault. It's from Jean. The link is http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/517782.html > > > >filename prefix or postfix.To align with those files, I suggest use > > >mtk-cpufreq.c.I think there are not too many values to change all "mtk-" > > >to "mediatek-", but it is worth to have the same naming rule for > > >mediatek upstream driver. > > > > > > > In the last submission Jean proposed to change all file names from > > mtk-*.[ch] to mediatek-*.[ch] as this will cause less confusion. > > > > Viresh are you OK with that approach or do you prefer that we stay with mtk > > prefix? I think it makes sense to have a unique prefix and resolve the > > situation we now have with source files and Kconfig options. > > But TBH I have no strong feeling for any of the two prefixes. > > I am fine with both. Maybe don't resend for just that, mediatek > doesn't sound any bad. I am also fine with both. I think most people won't confuse about mtk and mediatek. I don't like send patches to just only change filenames and kconfig, especially kconfig modification will affect project defconfigs. My point is we shouldn't spend much time on this topic, and revisit filename when that driver need support new SoC, like this case. Regards, Eddie
Re: [PATCH v4 1/3] cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC
On Thu, 2017-07-13 at 08:46 +0530, Viresh Kumar wrote: > On 12-07-17, 16:50, Matthias Brugger wrote: > > Hi Eddie, > > > > On 07/11/2017 04:49 AM, Eddie Huang wrote: > > >Hi Sean, > > > > > >On Mon, 2017-07-10 at 22:23 +0800, sean.w...@mediatek.com wrote: > > >>From: Sean Wang > > >> > > >>MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with > > >>single cluster and this hardware is also compatible with the existing > > >>driver through enabling CPU frequency feature with operating-points-v2 > > >>bindings. Also, this driver actually supports all MediaTek SoCs, the > > >>Kconfig menu entry and file name itself should be updated with more > > >>generic name to drop "MT8173" > > >> > > >>Signed-off-by: Sean Wang > > >>Acked-by: Viresh Kumar > > >>Reviewed-by: Jean Delvare > > >>--- > > >> drivers/cpufreq/Kconfig.arm | 7 +++ > > >> drivers/cpufreq/Makefile | 2 +- > > >> drivers/cpufreq/{mt8173-cpufreq.c => mediatek-cpufreq.c} | 2 ++ > > >> 3 files changed, 6 insertions(+), 5 deletions(-) > > >> rename drivers/cpufreq/{mt8173-cpufreq.c => mediatek-cpufreq.c} (99%) > > >> > > > > > >As Viresh mentioned, there are already many drivers use "mtk" as > > Do you have a link to when I mentioned this? > > /me suffering from Amnesia ? :) Sorry, my fault. It's from Jean. The link is http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/517782.html > > > >filename prefix or postfix.To align with those files, I suggest use > > >mtk-cpufreq.c.I think there are not too many values to change all "mtk-" > > >to "mediatek-", but it is worth to have the same naming rule for > > >mediatek upstream driver. > > > > > > > In the last submission Jean proposed to change all file names from > > mtk-*.[ch] to mediatek-*.[ch] as this will cause less confusion. > > > > Viresh are you OK with that approach or do you prefer that we stay with mtk > > prefix? I think it makes sense to have a unique prefix and resolve the > > situation we now have with source files and Kconfig options. > > But TBH I have no strong feeling for any of the two prefixes. > > I am fine with both. Maybe don't resend for just that, mediatek > doesn't sound any bad. I am also fine with both. I think most people won't confuse about mtk and mediatek. I don't like send patches to just only change filenames and kconfig, especially kconfig modification will affect project defconfigs. My point is we shouldn't spend much time on this topic, and revisit filename when that driver need support new SoC, like this case. Regards, Eddie
Re: [PATCH v4 1/3] cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC
Hi Sean, On Mon, 2017-07-10 at 22:23 +0800, sean.w...@mediatek.com wrote: > From: Sean Wang> > MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with > single cluster and this hardware is also compatible with the existing > driver through enabling CPU frequency feature with operating-points-v2 > bindings. Also, this driver actually supports all MediaTek SoCs, the > Kconfig menu entry and file name itself should be updated with more > generic name to drop "MT8173" > > Signed-off-by: Sean Wang > Acked-by: Viresh Kumar > Reviewed-by: Jean Delvare > --- > drivers/cpufreq/Kconfig.arm | 7 +++ > drivers/cpufreq/Makefile | 2 +- > drivers/cpufreq/{mt8173-cpufreq.c => mediatek-cpufreq.c} | 2 ++ > 3 files changed, 6 insertions(+), 5 deletions(-) > rename drivers/cpufreq/{mt8173-cpufreq.c => mediatek-cpufreq.c} (99%) > As Viresh mentioned, there are already many drivers use "mtk" as filename prefix or postfix.To align with those files, I suggest use mtk-cpufreq.c.I think there are not too many values to change all "mtk-" to "mediatek-", but it is worth to have the same naming rule for mediatek upstream driver. Regards, Eddie.
Re: [PATCH v4 1/3] cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC
Hi Sean, On Mon, 2017-07-10 at 22:23 +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with > single cluster and this hardware is also compatible with the existing > driver through enabling CPU frequency feature with operating-points-v2 > bindings. Also, this driver actually supports all MediaTek SoCs, the > Kconfig menu entry and file name itself should be updated with more > generic name to drop "MT8173" > > Signed-off-by: Sean Wang > Acked-by: Viresh Kumar > Reviewed-by: Jean Delvare > --- > drivers/cpufreq/Kconfig.arm | 7 +++ > drivers/cpufreq/Makefile | 2 +- > drivers/cpufreq/{mt8173-cpufreq.c => mediatek-cpufreq.c} | 2 ++ > 3 files changed, 6 insertions(+), 5 deletions(-) > rename drivers/cpufreq/{mt8173-cpufreq.c => mediatek-cpufreq.c} (99%) > As Viresh mentioned, there are already many drivers use "mtk" as filename prefix or postfix.To align with those files, I suggest use mtk-cpufreq.c.I think there are not too many values to change all "mtk-" to "mediatek-", but it is worth to have the same naming rule for mediatek upstream driver. Regards, Eddie.
Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
Hi Matthias, On Mon, 2017-01-09 at 19:45 +0100, Matthias Brugger wrote: > > On 09/01/17 12:29, Hans Verkuil wrote: > > Hi Rick, > > > > On 01/06/2017 03:34 AM, Rick Chang wrote: > >> Hi Hans, > >> > >> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have > >> any idea about this patch series? Should we wait for [2] or we could merge > >> the source code and dt-binding first? > > > > Looking at [2] I noticed that the last comment was July 4th. What is the > > reason > > it hasn't been merged yet? > > > > If I know [2] will be merged for 4.11, then I am fine with merging this > > media > > patch series. The dependency of this patch on [2] is something Mauro can > > handle. > > > > If [2] is not merged for 4.11, then I think it is better to wait until it is > > merged. > > > > I can't take [2] because there is no scpsys in the dts present. It seems > that it got never posted. > > Rick can you please follow-up with James and provide a patch which adds > a scpsys node to the mt2701.dtsi? > James sent three MT2701 dts patches [1] two weeks ago, these three patches include scpsys node. Please take a reference. And We will send new MT2701 ionmmu/smi dtsi node patch base on [1] later, thus you can accept and merge to 4.11. [1] https://patchwork.kernel.org/patch/9489991/ https://patchwork.kernel.org/patch/9489985/ https://patchwork.kernel.org/patch/9489989/ Thanks, Eddie
Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
Hi Matthias, On Mon, 2017-01-09 at 19:45 +0100, Matthias Brugger wrote: > > On 09/01/17 12:29, Hans Verkuil wrote: > > Hi Rick, > > > > On 01/06/2017 03:34 AM, Rick Chang wrote: > >> Hi Hans, > >> > >> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have > >> any idea about this patch series? Should we wait for [2] or we could merge > >> the source code and dt-binding first? > > > > Looking at [2] I noticed that the last comment was July 4th. What is the > > reason > > it hasn't been merged yet? > > > > If I know [2] will be merged for 4.11, then I am fine with merging this > > media > > patch series. The dependency of this patch on [2] is something Mauro can > > handle. > > > > If [2] is not merged for 4.11, then I think it is better to wait until it is > > merged. > > > > I can't take [2] because there is no scpsys in the dts present. It seems > that it got never posted. > > Rick can you please follow-up with James and provide a patch which adds > a scpsys node to the mt2701.dtsi? > James sent three MT2701 dts patches [1] two weeks ago, these three patches include scpsys node. Please take a reference. And We will send new MT2701 ionmmu/smi dtsi node patch base on [1] later, thus you can accept and merge to 4.11. [1] https://patchwork.kernel.org/patch/9489991/ https://patchwork.kernel.org/patch/9489985/ https://patchwork.kernel.org/patch/9489989/ Thanks, Eddie
Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701
On Tue, 2016-06-21 at 17:57 +0800, Joerg Roedel wrote: > On Wed, Jun 08, 2016 at 05:51:01PM +0800, honghui.zh...@mediatek.com wrote: > > From: Honghui Zhang> > > > Add the dtsi node of iommu and smi for mt2701. > > > > Signed-off-by: Honghui Zhang > > --- > > arch/arm/boot/dts/mt2701.dtsi | 51 > > +++ > > 1 file changed, 51 insertions(+) > > Okay, I pushed my arm/mediatek branch to my tree at > > git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git > > Please base the patch on that branch and re-send. > I think it is better let Mediatek SoC maintainer Matthias to accept dtsi patch like other drivers. This can avoid dtsi conflict. As I remember,last time MT8173 IOMMU dtsi patch accepted in iommu tree and mt8173.dtsi had conflict with arm soc tree at the merge window. Honghui should resend this patch to Matthias, and elaborate your dependency with clock and power domain dtsi, then Matthias know the merge sequence. Eddie Thanks
Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701
On Tue, 2016-06-21 at 17:57 +0800, Joerg Roedel wrote: > On Wed, Jun 08, 2016 at 05:51:01PM +0800, honghui.zh...@mediatek.com wrote: > > From: Honghui Zhang > > > > Add the dtsi node of iommu and smi for mt2701. > > > > Signed-off-by: Honghui Zhang > > --- > > arch/arm/boot/dts/mt2701.dtsi | 51 > > +++ > > 1 file changed, 51 insertions(+) > > Okay, I pushed my arm/mediatek branch to my tree at > > git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git > > Please base the patch on that branch and re-send. > I think it is better let Mediatek SoC maintainer Matthias to accept dtsi patch like other drivers. This can avoid dtsi conflict. As I remember,last time MT8173 IOMMU dtsi patch accepted in iommu tree and mt8173.dtsi had conflict with arm soc tree at the merge window. Honghui should resend this patch to Matthias, and elaborate your dependency with clock and power domain dtsi, then Matthias know the merge sequence. Eddie Thanks
Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver
Hi Matthias, On Thu, 2016-04-21 at 12:58 +0200, Matthias Brugger wrote: > > On 21/04/16 12:26, Matthias Brugger wrote: > > > > > > On 02/09/15 19:23, Matthias Brugger wrote: > >> > >> > >> On 02/09/15 08:45, Daniel Kurtz wrote: > >>> Matthias, > >>> > >>> On Fri, Aug 28, 2015 at 10:06 PM, Rafael J. Wysocki > >>>wrote: > On Wednesday, August 26, 2015 02:53:39 PM Pi-Cheng Chen wrote: > > On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar > > wrote: > >> On 26-08-15, 09:25, Pi-Cheng Chen wrote: > >>> The [3/3] is based on Mediatek SoC maintainer tree[1] and the > >>> patch which > >>> introduce a new clock type[2] consumed by MT8173 cpufreq driver. > >>> So it will > >>> cause some conflicts if it goes through your tree. I am not sure > >>> how this > >>> should be handled, but should it be merged through Mediatek SoC > >>> maintainer > >>> tree? > >> > >> Just get that applied to MTK tree, it doesn't have any dependency on > >> rest of the patches for build/boot. The only thing is that cpufreq > >> wouldn't work and it will work as soon as Rafael's and MTK's trees > >> are > >> merged by Linus. > > > > Thanks for your explanation. > > > > @Rafael, Would you please apply [1,2] to your tree? > > Applied, thanks! > >>> > >>> Can you please apply [3] from this set to your dts tree? > >>> > >> > >> I will as soon as v4.3-rc1 shows up. > > > > I somehow forgot this patch. Sorry for that. > > Applied for v4.6-next/dts64 right now. > > > > I just realized that CLK_INFRA_CA53SEL and CLK_APMIXED_MAINPLL are not > part of the clk driver. > > Pi-Cheng, can you check if they got renamed in the meanwhile? Or do we > need some clock driver patches that enable this clocks for the series? > Thanks your notice. Unfortunately, we still have no chance let patch with these two clock merged. The last version is [1]. This clock patch will block cpufreq dts [2] and dynamic power dts [3]. Clock maintainer is working on new architecture [4], hopefully we can send new clock patch soon. After that, we will send new cpufreq and dynamic power dts. So please ignore [2] [3] at this moment. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/369737.html [2] https://lkml.org/lkml/2015/7/9/206 [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-April/423899.html [4] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/418796.html Eddie Thanks
Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver
Hi Matthias, On Thu, 2016-04-21 at 12:58 +0200, Matthias Brugger wrote: > > On 21/04/16 12:26, Matthias Brugger wrote: > > > > > > On 02/09/15 19:23, Matthias Brugger wrote: > >> > >> > >> On 02/09/15 08:45, Daniel Kurtz wrote: > >>> Matthias, > >>> > >>> On Fri, Aug 28, 2015 at 10:06 PM, Rafael J. Wysocki > >>> wrote: > On Wednesday, August 26, 2015 02:53:39 PM Pi-Cheng Chen wrote: > > On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar > > wrote: > >> On 26-08-15, 09:25, Pi-Cheng Chen wrote: > >>> The [3/3] is based on Mediatek SoC maintainer tree[1] and the > >>> patch which > >>> introduce a new clock type[2] consumed by MT8173 cpufreq driver. > >>> So it will > >>> cause some conflicts if it goes through your tree. I am not sure > >>> how this > >>> should be handled, but should it be merged through Mediatek SoC > >>> maintainer > >>> tree? > >> > >> Just get that applied to MTK tree, it doesn't have any dependency on > >> rest of the patches for build/boot. The only thing is that cpufreq > >> wouldn't work and it will work as soon as Rafael's and MTK's trees > >> are > >> merged by Linus. > > > > Thanks for your explanation. > > > > @Rafael, Would you please apply [1,2] to your tree? > > Applied, thanks! > >>> > >>> Can you please apply [3] from this set to your dts tree? > >>> > >> > >> I will as soon as v4.3-rc1 shows up. > > > > I somehow forgot this patch. Sorry for that. > > Applied for v4.6-next/dts64 right now. > > > > I just realized that CLK_INFRA_CA53SEL and CLK_APMIXED_MAINPLL are not > part of the clk driver. > > Pi-Cheng, can you check if they got renamed in the meanwhile? Or do we > need some clock driver patches that enable this clocks for the series? > Thanks your notice. Unfortunately, we still have no chance let patch with these two clock merged. The last version is [1]. This clock patch will block cpufreq dts [2] and dynamic power dts [3]. Clock maintainer is working on new architecture [4], hopefully we can send new clock patch soon. After that, we will send new cpufreq and dynamic power dts. So please ignore [2] [3] at this moment. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/369737.html [2] https://lkml.org/lkml/2015/7/9/206 [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-April/423899.html [4] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/418796.html Eddie Thanks
NVMEM usage question
Hi, Mediatek PMIC chip have some spare registers used to store information. The value of these registers will exist until user unplug battery or battery depletion. One of our usage example is store battery utilization in these spare registers. We want to implement NVMEM driver to read/write sparse registers, but binding document describe NVMEM is for "Non-volatile memory", and for hardware like eeprom, efuse. Since the usage here is some kind of "battery backup memory", but not real non-volatile memory, is NVMEM driver suitable for this case ? Eddie
NVMEM usage question
Hi, Mediatek PMIC chip have some spare registers used to store information. The value of these registers will exist until user unplug battery or battery depletion. One of our usage example is store battery utilization in these spare registers. We want to implement NVMEM driver to read/write sparse registers, but binding document describe NVMEM is for "Non-volatile memory", and for hardware like eeprom, efuse. Since the usage here is some kind of "battery backup memory", but not real non-volatile memory, is NVMEM driver suitable for this case ? Eddie
[PATCH] ARM64: dts: Mediatek: mt8173-evb: fix access MMC fail issue
MT8173 E1 chip has one bug that if turn off USB power domain, vcore power will also be off, thus cause modules using vcore power domain fail, like MMC. The E1 chip only found on MT8173-evb board and this board only has E1 chip, so implement this as a board specific workaround. Pwrapper use vcore power, so add pwrapper using USB power domain to keep USB power domain not to zero and disabled. Signed-off-by: Eddie Huang <eddie.hu...@mediatek.com> --- Sascha sent similar patch before[0], but MMC support runtime-pm, vcore power domain still be disabled after MMC and USB suspend. This silicon bug already fix in MT8173 MP chip. [0]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358065.html --- arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts index e427f04..7453a47 100644 --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts @@ -214,6 +214,9 @@ }; { + /* Only MT8173 E1 needs USB power domain */ + power-domains = < MT8173_POWER_DOMAIN_USB>; + pmic: mt6397 { compatible = "mediatek,mt6397"; interrupt-parent = <>; -- 1.9.1
[PATCH] ARM64: dts: Mediatek: mt8173-evb: fix access MMC fail issue
MT8173 E1 chip has one bug that if turn off USB power domain, vcore power will also be off, thus cause modules using vcore power domain fail, like MMC. The E1 chip only found on MT8173-evb board and this board only has E1 chip, so implement this as a board specific workaround. Pwrapper use vcore power, so add pwrapper using USB power domain to keep USB power domain not to zero and disabled. Signed-off-by: Eddie Huang --- Sascha sent similar patch before[0], but MMC support runtime-pm, vcore power domain still be disabled after MMC and USB suspend. This silicon bug already fix in MT8173 MP chip. [0]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358065.html --- arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts index e427f04..7453a47 100644 --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts @@ -214,6 +214,9 @@ }; { + /* Only MT8173 E1 needs USB power domain */ + power-domains = < MT8173_POWER_DOMAIN_USB>; + pmic: mt6397 { compatible = "mediatek,mt6397"; interrupt-parent = <>; -- 1.9.1
Re: [PATCH] rtc: mt6397: Add platform device ID table
On Tue, 2016-02-16 at 12:37 +0100, Arnd Bergmann wrote: > On Monday 15 February 2016 11:50:48 Javier Martinez Canillas wrote: > > > > On 02/14/2016 10:58 PM, Eddie Huang wrote: > > > > [snip] > > > > >> @@ -412,6 +418,7 @@ static struct platform_driver mtk_rtc_driver = { > > >> }, > > >> .probe = mtk_rtc_probe, > > >> .remove = mtk_rtc_remove, > > >> +.id_table = mt6397_rtc_id, > > >> }; > > >> > > >> module_platform_driver(mtk_rtc_driver); > > >> @@ -419,4 +426,3 @@ module_platform_driver(mtk_rtc_driver); > > >> MODULE_LICENSE("GPL v2"); > > >> MODULE_AUTHOR("Tianping Fang <tianping.f...@mediatek.com>"); > > >> MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC"); > > >> -MODULE_ALIAS("platform:mt6397-rtc"); > > > > > > This patch looks good to me, but I am wondering, since we tend to use > > > device tree method to match driver, do we still need support platform > > > device ID ? > > > > > > > I'm not familiar with neither this IP block nor the SoC so it is up to > > you. I just noticed this issue when reviewing a regulator driver for a > > similar PMIC posted by someone from mediatek. > > > > I thought platform device was needed since the driver has a MODULE_ALIAS() > > but please let me know what you prefer and I can re-spin the patch and > > just remove the MODULE_ALIAS() if that makes more sense for this platform. > > > > > > I agree. We can alway add a MODULE_DEVICE_TABLE() if we get multiple > users of this driver on architectures that don't use devicetree yet. > Sure. Thanks the patch to add expandability to this driver. Acked-by: Eddie Huang <eddie.hu...@mediatek.com> Eddie
Re: [PATCH] rtc: mt6397: Add platform device ID table
On Tue, 2016-02-16 at 12:37 +0100, Arnd Bergmann wrote: > On Monday 15 February 2016 11:50:48 Javier Martinez Canillas wrote: > > > > On 02/14/2016 10:58 PM, Eddie Huang wrote: > > > > [snip] > > > > >> @@ -412,6 +418,7 @@ static struct platform_driver mtk_rtc_driver = { > > >> }, > > >> .probe = mtk_rtc_probe, > > >> .remove = mtk_rtc_remove, > > >> +.id_table = mt6397_rtc_id, > > >> }; > > >> > > >> module_platform_driver(mtk_rtc_driver); > > >> @@ -419,4 +426,3 @@ module_platform_driver(mtk_rtc_driver); > > >> MODULE_LICENSE("GPL v2"); > > >> MODULE_AUTHOR("Tianping Fang "); > > >> MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC"); > > >> -MODULE_ALIAS("platform:mt6397-rtc"); > > > > > > This patch looks good to me, but I am wondering, since we tend to use > > > device tree method to match driver, do we still need support platform > > > device ID ? > > > > > > > I'm not familiar with neither this IP block nor the SoC so it is up to > > you. I just noticed this issue when reviewing a regulator driver for a > > similar PMIC posted by someone from mediatek. > > > > I thought platform device was needed since the driver has a MODULE_ALIAS() > > but please let me know what you prefer and I can re-spin the patch and > > just remove the MODULE_ALIAS() if that makes more sense for this platform. > > > > > > I agree. We can alway add a MODULE_DEVICE_TABLE() if we get multiple > users of this driver on architectures that don't use devicetree yet. > Sure. Thanks the patch to add expandability to this driver. Acked-by: Eddie Huang Eddie
Re: [PATCH] rtc: mt6397: Add platform device ID table
On Tue, 2016-02-09 at 08:08 -0300, Javier Martinez Canillas wrote: > The platform bus_type .match callback attempts to match the platform device > name with an entry on the .id_table if provided and fallbacks to match with > the driver's name if a table is not provided. > > Using a platform device ID to match is more explicit, allows the driver to > support more than one device and also the MODULE_DEVICE_TABLE macro can be > used to export the module aliases information instead of the MODULE_ALIAS. > > Signed-off-by: Javier Martinez Canillas> > --- > > drivers/rtc/rtc-mt6397.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c > index 06a5c52b292f..46533f11f7fc 100644 > --- a/drivers/rtc/rtc-mt6397.c > +++ b/drivers/rtc/rtc-mt6397.c > @@ -404,6 +404,12 @@ static const struct of_device_id mt6397_rtc_of_match[] = > { > }; > MODULE_DEVICE_TABLE(of, mt6397_rtc_of_match); > > +static const struct platform_device_id mt6397_rtc_id[] = { > + {"mt6397-rtc", 0}, > + { /* sentinel */ }, > +}; > +MODULE_DEVICE_TABLE(platform, mt6397_rtc_id); > + > static struct platform_driver mtk_rtc_driver = { > .driver = { > .name = "mt6397-rtc", > @@ -412,6 +418,7 @@ static struct platform_driver mtk_rtc_driver = { > }, > .probe = mtk_rtc_probe, > .remove = mtk_rtc_remove, > + .id_table = mt6397_rtc_id, > }; > > module_platform_driver(mtk_rtc_driver); > @@ -419,4 +426,3 @@ module_platform_driver(mtk_rtc_driver); > MODULE_LICENSE("GPL v2"); > MODULE_AUTHOR("Tianping Fang "); > MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC"); > -MODULE_ALIAS("platform:mt6397-rtc"); This patch looks good to me, but I am wondering, since we tend to use device tree method to match driver, do we still need support platform device ID ? Eddie
Re: [PATCH] rtc: mt6397: Add platform device ID table
On Tue, 2016-02-09 at 08:08 -0300, Javier Martinez Canillas wrote: > The platform bus_type .match callback attempts to match the platform device > name with an entry on the .id_table if provided and fallbacks to match with > the driver's name if a table is not provided. > > Using a platform device ID to match is more explicit, allows the driver to > support more than one device and also the MODULE_DEVICE_TABLE macro can be > used to export the module aliases information instead of the MODULE_ALIAS. > > Signed-off-by: Javier Martinez Canillas > > --- > > drivers/rtc/rtc-mt6397.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c > index 06a5c52b292f..46533f11f7fc 100644 > --- a/drivers/rtc/rtc-mt6397.c > +++ b/drivers/rtc/rtc-mt6397.c > @@ -404,6 +404,12 @@ static const struct of_device_id mt6397_rtc_of_match[] = > { > }; > MODULE_DEVICE_TABLE(of, mt6397_rtc_of_match); > > +static const struct platform_device_id mt6397_rtc_id[] = { > + {"mt6397-rtc", 0}, > + { /* sentinel */ }, > +}; > +MODULE_DEVICE_TABLE(platform, mt6397_rtc_id); > + > static struct platform_driver mtk_rtc_driver = { > .driver = { > .name = "mt6397-rtc", > @@ -412,6 +418,7 @@ static struct platform_driver mtk_rtc_driver = { > }, > .probe = mtk_rtc_probe, > .remove = mtk_rtc_remove, > + .id_table = mt6397_rtc_id, > }; > > module_platform_driver(mtk_rtc_driver); > @@ -419,4 +426,3 @@ module_platform_driver(mtk_rtc_driver); > MODULE_LICENSE("GPL v2"); > MODULE_AUTHOR("Tianping Fang "); > MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC"); > -MODULE_ALIAS("platform:mt6397-rtc"); This patch looks good to me, but I am wondering, since we tend to use device tree method to match driver, do we still need support platform device ID ? Eddie
Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support
On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote: > Eduardo, > > On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote: > > Hi Eduardo, > > > > > > > > That should remove the policy of computing the maximum from this driver. > > > Please have a look on the work being done [1] to add grouping and > > > aggregation of thermal zones. With that in place, you should be a matter > > > of configuring the grouping and selecting max as the aggregation function, > > > from the thermal core, instead in the driver. Which should give the > > > system engineer, more flexibility to compose whatever policy based on > > > the exposed sensors. > > > > I think the aggregation of thermal zones is quite useful when it comes > > to putting different chips together to a system. I am not so sure how > > useful it is to expose different thermal zones of a single SoC to the > > device tree. > > Currently the only control knob we have is the CPU frequency. When any > > of the sensors on the SoC gets too hot then the only thing we can do is > > to decrease the CPU frequency. This does not leave much space for > > configuration in the device tree. > > What I need to be able is to attach multiple sensors to one thermal > > zone. The aggregation patch series only partly solves that and I think > > is inconsistent, but I commented on the series directly. > > Any input on this? I really like to get this driver upstream as it is > currently blocking other Mediatek drivers. > Hi Eduardo, Do you have any comment about Sascha's response ? We really hope get your comment since Mediatek thermal driver already reviewed in public over half years, and we have other patches [0] [1] depend on thermal driver. [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html Regards, Eddie
Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support
On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote: > Eduardo, > > On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote: > > Hi Eduardo, > > > > > > > > That should remove the policy of computing the maximum from this driver. > > > Please have a look on the work being done [1] to add grouping and > > > aggregation of thermal zones. With that in place, you should be a matter > > > of configuring the grouping and selecting max as the aggregation function, > > > from the thermal core, instead in the driver. Which should give the > > > system engineer, more flexibility to compose whatever policy based on > > > the exposed sensors. > > > > I think the aggregation of thermal zones is quite useful when it comes > > to putting different chips together to a system. I am not so sure how > > useful it is to expose different thermal zones of a single SoC to the > > device tree. > > Currently the only control knob we have is the CPU frequency. When any > > of the sensors on the SoC gets too hot then the only thing we can do is > > to decrease the CPU frequency. This does not leave much space for > > configuration in the device tree. > > What I need to be able is to attach multiple sensors to one thermal > > zone. The aggregation patch series only partly solves that and I think > > is inconsistent, but I commented on the series directly. > > Any input on this? I really like to get this driver upstream as it is > currently blocking other Mediatek drivers. > Hi Eduardo, Do you have any comment about Sascha's response ? We really hope get your comment since Mediatek thermal driver already reviewed in public over half years, and we have other patches [0] [1] depend on thermal driver. [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html Regards, Eddie
Re: [PATCH] rtc: mt6397: add IRQ domain dependency
On Mon, 2016-01-25 at 17:04 +0100, Arnd Bergmann wrote: > The mt6397 RTC driver can be built either when the MFD_MT6397 driver > is enabled (which selects IRQ_DOMAIN), or when compile testing. > The latter however fails without IRQ domains: > > drivers/rtc/rtc-mt6397.c: In function 'mtk_rtc_probe': > drivers/rtc/rtc-mt6397.c:326:13: error: implicit declaration of function > 'irq_create_mapping' [-Werror=implicit-function-declaration] > rtc->irq = irq_create_mapping(mt6397_chip->irq_domain, res->start); > > This adds an explicit dependency for the COMPILE_TEST case. > > Signed-off-by: Arnd Bergmann > --- > drivers/rtc/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig > index 376322f71fd5..4395608bf7fc 100644 > --- a/drivers/rtc/Kconfig > +++ b/drivers/rtc/Kconfig > @@ -1603,7 +1603,7 @@ config RTC_DRV_MOXART > > config RTC_DRV_MT6397 > tristate "Mediatek Real Time Clock driver" > - depends on MFD_MT6397 || COMPILE_TEST > + depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN) > help > This selects the Mediatek(R) RTC driver. RTC is part of Mediatek > MT6397 PMIC. You should enable MT6397 PMIC MFD before select Hi Arnd, Thanks your correction. Acked-by: Eddie Huang Regards, Eddie
Re: [PATCH] rtc: mt6397: add IRQ domain dependency
On Mon, 2016-01-25 at 17:04 +0100, Arnd Bergmann wrote: > The mt6397 RTC driver can be built either when the MFD_MT6397 driver > is enabled (which selects IRQ_DOMAIN), or when compile testing. > The latter however fails without IRQ domains: > > drivers/rtc/rtc-mt6397.c: In function 'mtk_rtc_probe': > drivers/rtc/rtc-mt6397.c:326:13: error: implicit declaration of function > 'irq_create_mapping' [-Werror=implicit-function-declaration] > rtc->irq = irq_create_mapping(mt6397_chip->irq_domain, res->start); > > This adds an explicit dependency for the COMPILE_TEST case. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> > --- > drivers/rtc/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig > index 376322f71fd5..4395608bf7fc 100644 > --- a/drivers/rtc/Kconfig > +++ b/drivers/rtc/Kconfig > @@ -1603,7 +1603,7 @@ config RTC_DRV_MOXART > > config RTC_DRV_MT6397 > tristate "Mediatek Real Time Clock driver" > - depends on MFD_MT6397 || COMPILE_TEST > + depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN) > help > This selects the Mediatek(R) RTC driver. RTC is part of Mediatek > MT6397 PMIC. You should enable MT6397 PMIC MFD before select Hi Arnd, Thanks your correction. Acked-by: Eddie Huang <eddie.hu...@mediatek.com> Regards, Eddie
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
On Thu, 2015-11-12 at 15:56 -0800, Kevin Hilman wrote: > Eddie Huang writes: > > > On Wed, 2015-11-11 at 20:54 -0800, Kevin Hilman wrote: > >> Hi Eddie, > >> > >> Kevin Hilman writes: > >> > >> > Eddie Huang writes: > >> > > >> >> On Tue, 2015-11-10 at 17:16 -0800, Kevin Hilman wrote: > >> >>> Hi Eddie, > >> >>> > >> >>> [...] > >> >>> > >> >>> > I check the log [0], > >> >>> > >> >>> Thanks for checking into this boot failure. > >> >>> > >> >>> > it seems first time mt8135-evbp1 boot to kernel > >> >>> > shell successfully, then boot again. In the second time, mt8135 stay > >> >>> > in > >> >>> > fastboot mode, waiting host send boot image, then timeout. > >> >>> > >> >>> Actually, it never gets to a shell the first time. If you look > >> >>> closely, > >> >>> the target reboots as soon as userspace starts. Look for the PYBOOT > >> >>> line which says "finished booting, starting userspace" > >> >>> > >> >>> Later on, pyboot thinks it finds a root shell due to finding '#' > >> >>> characters, but clearly it never got to a shell. > >> >>> > >> >>> > I download zImage and dtb in [1], and kernel run to shell > >> >>> > successfully > >> >>> > on my platform. > >> >>> > >> >>> Are you can you try using a ramdisk as well? You can use the pre-built > >> >>> one here: > >> >>> http://storage.kernelci.org/images/rootfs/buildroot/armel/rootfs.cpio.gz > >> >>> > >> >> > >> >> Yes, I tried this ramdisk, and I can reproduce fail issue. > >> >> > >> > > >> > OK, good. Thanks for looking into it. > >> > > >> >>> Please check my boot logs to see how I'm generating the boot.img file > >> >>> (search for mkbootimg) with a kernel/dtb/ramdisk. It may be possible > >> >>> that the kernel image size with a ramdisk is breaking some of the > >> >>> assumptions in the fastboot mode. I've seen problems like this on > >> >>> other > >> >>> platforms due to hard-coded sizes/addresses in the boot firmware. > >> >>> > >> >> > >> >> MT8135 allocate 10MB for BOOT partition, but the test boot.img is 11MB, > >> >> thus cause user space fail. > >> > > >> > Aha, I was right! ;) > >> > >> Also notice in kernelci.org that the mt8173 board has also been failing > >> to boot in mainline[1]. I wonder if this same limitation exists in the > >> mt8173 boot firmware? > >> > > > > MT8173 is another case, the failure is due to following commit: > > 67e56c5 arm64: dts: mt8173: Add subsystem clock controller device nodes > > > > It is because this commit register MM subsystem clock, but kernel don't > > use MM clock yet, then CCF disable it. (My internal platform kernel > > command include clk_ignore_unused parameter, so don't have this > > problem).I will do further checking and release solution later. Thanks > > your testing. > > OK, thanks for looking into it. > > However, since the merge window is very close to closing, unless you can > git a fix out soon (and one that doesn't introduce other bugs), > probablly the right solution is to just revert the above patch so things > are fixed for mainline ASAP. > I send one patch to fix this problem. Hope this patch can apply to 4.4. http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/384800.html Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] soc: Mediatek: Enable SCPSYS power domain driver by default
If enable Mediatek 8173 SoC, it should also enable power domain driver. Otherwise access clk subsystem register will fail. Signed-off-by: Eddie Huang --- MT8173 clk driver is enabled by default, but power domain driver is not. If MM subsystem power on, mm_sel topckgen mux is off, then access any MM subsystem register will cause system hang. Enable SCPSYS driver to make sure both MM subsystem power and mm_sel to on/off together to avoid system hang. This patch fix current linux-next mt8173-evb boot to shell fail problem. --- drivers/soc/mediatek/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig index 9d50682..0a4ea80 100644 --- a/drivers/soc/mediatek/Kconfig +++ b/drivers/soc/mediatek/Kconfig @@ -23,6 +23,7 @@ config MTK_PMIC_WRAP config MTK_SCPSYS bool "MediaTek SCPSYS Support" depends on ARCH_MEDIATEK || COMPILE_TEST + default ARM64 && ARCH_MEDIATEK select REGMAP select MTK_INFRACFG select PM_GENERIC_DOMAINS if PM -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
On Thu, 2015-11-12 at 15:56 -0800, Kevin Hilman wrote: > Eddie Huang <eddie.hu...@mediatek.com> writes: > > > On Wed, 2015-11-11 at 20:54 -0800, Kevin Hilman wrote: > >> Hi Eddie, > >> > >> Kevin Hilman <khil...@kernel.org> writes: > >> > >> > Eddie Huang <eddie.hu...@mediatek.com> writes: > >> > > >> >> On Tue, 2015-11-10 at 17:16 -0800, Kevin Hilman wrote: > >> >>> Hi Eddie, > >> >>> > >> >>> [...] > >> >>> > >> >>> > I check the log [0], > >> >>> > >> >>> Thanks for checking into this boot failure. > >> >>> > >> >>> > it seems first time mt8135-evbp1 boot to kernel > >> >>> > shell successfully, then boot again. In the second time, mt8135 stay > >> >>> > in > >> >>> > fastboot mode, waiting host send boot image, then timeout. > >> >>> > >> >>> Actually, it never gets to a shell the first time. If you look > >> >>> closely, > >> >>> the target reboots as soon as userspace starts. Look for the PYBOOT > >> >>> line which says "finished booting, starting userspace" > >> >>> > >> >>> Later on, pyboot thinks it finds a root shell due to finding '#' > >> >>> characters, but clearly it never got to a shell. > >> >>> > >> >>> > I download zImage and dtb in [1], and kernel run to shell > >> >>> > successfully > >> >>> > on my platform. > >> >>> > >> >>> Are you can you try using a ramdisk as well? You can use the pre-built > >> >>> one here: > >> >>> http://storage.kernelci.org/images/rootfs/buildroot/armel/rootfs.cpio.gz > >> >>> > >> >> > >> >> Yes, I tried this ramdisk, and I can reproduce fail issue. > >> >> > >> > > >> > OK, good. Thanks for looking into it. > >> > > >> >>> Please check my boot logs to see how I'm generating the boot.img file > >> >>> (search for mkbootimg) with a kernel/dtb/ramdisk. It may be possible > >> >>> that the kernel image size with a ramdisk is breaking some of the > >> >>> assumptions in the fastboot mode. I've seen problems like this on > >> >>> other > >> >>> platforms due to hard-coded sizes/addresses in the boot firmware. > >> >>> > >> >> > >> >> MT8135 allocate 10MB for BOOT partition, but the test boot.img is 11MB, > >> >> thus cause user space fail. > >> > > >> > Aha, I was right! ;) > >> > >> Also notice in kernelci.org that the mt8173 board has also been failing > >> to boot in mainline[1]. I wonder if this same limitation exists in the > >> mt8173 boot firmware? > >> > > > > MT8173 is another case, the failure is due to following commit: > > 67e56c5 arm64: dts: mt8173: Add subsystem clock controller device nodes > > > > It is because this commit register MM subsystem clock, but kernel don't > > use MM clock yet, then CCF disable it. (My internal platform kernel > > command include clk_ignore_unused parameter, so don't have this > > problem).I will do further checking and release solution later. Thanks > > your testing. > > OK, thanks for looking into it. > > However, since the merge window is very close to closing, unless you can > git a fix out soon (and one that doesn't introduce other bugs), > probablly the right solution is to just revert the above patch so things > are fixed for mainline ASAP. > I send one patch to fix this problem. Hope this patch can apply to 4.4. http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/384800.html Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] soc: Mediatek: Enable SCPSYS power domain driver by default
If enable Mediatek 8173 SoC, it should also enable power domain driver. Otherwise access clk subsystem register will fail. Signed-off-by: Eddie Huang <eddie.hu...@mediatek.com> --- MT8173 clk driver is enabled by default, but power domain driver is not. If MM subsystem power on, mm_sel topckgen mux is off, then access any MM subsystem register will cause system hang. Enable SCPSYS driver to make sure both MM subsystem power and mm_sel to on/off together to avoid system hang. This patch fix current linux-next mt8173-evb boot to shell fail problem. --- drivers/soc/mediatek/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig index 9d50682..0a4ea80 100644 --- a/drivers/soc/mediatek/Kconfig +++ b/drivers/soc/mediatek/Kconfig @@ -23,6 +23,7 @@ config MTK_PMIC_WRAP config MTK_SCPSYS bool "MediaTek SCPSYS Support" depends on ARCH_MEDIATEK || COMPILE_TEST + default ARM64 && ARCH_MEDIATEK select REGMAP select MTK_INFRACFG select PM_GENERIC_DOMAINS if PM -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
On Wed, 2015-11-11 at 20:54 -0800, Kevin Hilman wrote: > Hi Eddie, > > Kevin Hilman writes: > > > Eddie Huang writes: > > > >> On Tue, 2015-11-10 at 17:16 -0800, Kevin Hilman wrote: > >>> Hi Eddie, > >>> > >>> [...] > >>> > >>> > I check the log [0], > >>> > >>> Thanks for checking into this boot failure. > >>> > >>> > it seems first time mt8135-evbp1 boot to kernel > >>> > shell successfully, then boot again. In the second time, mt8135 stay in > >>> > fastboot mode, waiting host send boot image, then timeout. > >>> > >>> Actually, it never gets to a shell the first time. If you look closely, > >>> the target reboots as soon as userspace starts. Look for the PYBOOT > >>> line which says "finished booting, starting userspace" > >>> > >>> Later on, pyboot thinks it finds a root shell due to finding '#' > >>> characters, but clearly it never got to a shell. > >>> > >>> > I download zImage and dtb in [1], and kernel run to shell successfully > >>> > on my platform. > >>> > >>> Are you can you try using a ramdisk as well? You can use the pre-built > >>> one here: > >>> http://storage.kernelci.org/images/rootfs/buildroot/armel/rootfs.cpio.gz > >>> > >> > >> Yes, I tried this ramdisk, and I can reproduce fail issue. > >> > > > > OK, good. Thanks for looking into it. > > > >>> Please check my boot logs to see how I'm generating the boot.img file > >>> (search for mkbootimg) with a kernel/dtb/ramdisk. It may be possible > >>> that the kernel image size with a ramdisk is breaking some of the > >>> assumptions in the fastboot mode. I've seen problems like this on other > >>> platforms due to hard-coded sizes/addresses in the boot firmware. > >>> > >> > >> MT8135 allocate 10MB for BOOT partition, but the test boot.img is 11MB, > >> thus cause user space fail. > > > > Aha, I was right! ;) > > Also notice in kernelci.org that the mt8173 board has also been failing > to boot in mainline[1]. I wonder if this same limitation exists in the > mt8173 boot firmware? > MT8173 is another case, the failure is due to following commit: 67e56c5 arm64: dts: mt8173: Add subsystem clock controller device nodes It is because this commit register MM subsystem clock, but kernel don't use MM clock yet, then CCF disable it. (My internal platform kernel command include clk_ignore_unused parameter, so don't have this problem).I will do further checking and release solution later. Thanks your testing. Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
On Wed, 2015-11-11 at 20:54 -0800, Kevin Hilman wrote: > Hi Eddie, > > Kevin Hilman <khil...@kernel.org> writes: > > > Eddie Huang <eddie.hu...@mediatek.com> writes: > > > >> On Tue, 2015-11-10 at 17:16 -0800, Kevin Hilman wrote: > >>> Hi Eddie, > >>> > >>> [...] > >>> > >>> > I check the log [0], > >>> > >>> Thanks for checking into this boot failure. > >>> > >>> > it seems first time mt8135-evbp1 boot to kernel > >>> > shell successfully, then boot again. In the second time, mt8135 stay in > >>> > fastboot mode, waiting host send boot image, then timeout. > >>> > >>> Actually, it never gets to a shell the first time. If you look closely, > >>> the target reboots as soon as userspace starts. Look for the PYBOOT > >>> line which says "finished booting, starting userspace" > >>> > >>> Later on, pyboot thinks it finds a root shell due to finding '#' > >>> characters, but clearly it never got to a shell. > >>> > >>> > I download zImage and dtb in [1], and kernel run to shell successfully > >>> > on my platform. > >>> > >>> Are you can you try using a ramdisk as well? You can use the pre-built > >>> one here: > >>> http://storage.kernelci.org/images/rootfs/buildroot/armel/rootfs.cpio.gz > >>> > >> > >> Yes, I tried this ramdisk, and I can reproduce fail issue. > >> > > > > OK, good. Thanks for looking into it. > > > >>> Please check my boot logs to see how I'm generating the boot.img file > >>> (search for mkbootimg) with a kernel/dtb/ramdisk. It may be possible > >>> that the kernel image size with a ramdisk is breaking some of the > >>> assumptions in the fastboot mode. I've seen problems like this on other > >>> platforms due to hard-coded sizes/addresses in the boot firmware. > >>> > >> > >> MT8135 allocate 10MB for BOOT partition, but the test boot.img is 11MB, > >> thus cause user space fail. > > > > Aha, I was right! ;) > > Also notice in kernelci.org that the mt8173 board has also been failing > to boot in mainline[1]. I wonder if this same limitation exists in the > mt8173 boot firmware? > MT8173 is another case, the failure is due to following commit: 67e56c5 arm64: dts: mt8173: Add subsystem clock controller device nodes It is because this commit register MM subsystem clock, but kernel don't use MM clock yet, then CCF disable it. (My internal platform kernel command include clk_ignore_unused parameter, so don't have this problem).I will do further checking and release solution later. Thanks your testing. Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
Hi Kevin, On Tue, 2015-11-10 at 17:16 -0800, Kevin Hilman wrote: > Hi Eddie, > > [...] > > > I check the log [0], > > Thanks for checking into this boot failure. > > > it seems first time mt8135-evbp1 boot to kernel > > shell successfully, then boot again. In the second time, mt8135 stay in > > fastboot mode, waiting host send boot image, then timeout. > > Actually, it never gets to a shell the first time. If you look closely, > the target reboots as soon as userspace starts. Look for the PYBOOT > line which says "finished booting, starting userspace" > > Later on, pyboot thinks it finds a root shell due to finding '#' > characters, but clearly it never got to a shell. > > > I download zImage and dtb in [1], and kernel run to shell successfully > > on my platform. > > Are you can you try using a ramdisk as well? You can use the pre-built > one here: > http://storage.kernelci.org/images/rootfs/buildroot/armel/rootfs.cpio.gz > Yes, I tried this ramdisk, and I can reproduce fail issue. > Please check my boot logs to see how I'm generating the boot.img file > (search for mkbootimg) with a kernel/dtb/ramdisk. It may be possible > that the kernel image size with a ramdisk is breaking some of the > assumptions in the fastboot mode. I've seen problems like this on other > platforms due to hard-coded sizes/addresses in the boot firmware. > MT8135 allocate 10MB for BOOT partition, but the test boot.img is 11MB, thus cause user space fail. I will prepare new firmware that extend BOOT partition to 16MB. and put new firmware on Howard's github. I will mail to you when I am ready.. Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
Hi Kevin, On Tue, 2015-11-10 at 17:16 -0800, Kevin Hilman wrote: > Hi Eddie, > > [...] > > > I check the log [0], > > Thanks for checking into this boot failure. > > > it seems first time mt8135-evbp1 boot to kernel > > shell successfully, then boot again. In the second time, mt8135 stay in > > fastboot mode, waiting host send boot image, then timeout. > > Actually, it never gets to a shell the first time. If you look closely, > the target reboots as soon as userspace starts. Look for the PYBOOT > line which says "finished booting, starting userspace" > > Later on, pyboot thinks it finds a root shell due to finding '#' > characters, but clearly it never got to a shell. > > > I download zImage and dtb in [1], and kernel run to shell successfully > > on my platform. > > Are you can you try using a ramdisk as well? You can use the pre-built > one here: > http://storage.kernelci.org/images/rootfs/buildroot/armel/rootfs.cpio.gz > Yes, I tried this ramdisk, and I can reproduce fail issue. > Please check my boot logs to see how I'm generating the boot.img file > (search for mkbootimg) with a kernel/dtb/ramdisk. It may be possible > that the kernel image size with a ramdisk is breaking some of the > assumptions in the fastboot mode. I've seen problems like this on other > platforms due to hard-coded sizes/addresses in the boot firmware. > MT8135 allocate 10MB for BOOT partition, but the test boot.img is 11MB, thus cause user space fail. I will prepare new firmware that extend BOOT partition to 16MB. and put new firmware on Howard's github. I will mail to you when I am ready.. Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
On Mon, 2015-11-09 at 09:59 -0800, Kevin Hilman wrote: > On Mon, Oct 26, 2015 at 4:40 AM, Eddie Huang wrote: > > Hi Kevin, > > > > On Mon, 2015-10-26 at 17:06 +0900, Kevin Hilman wrote: > >> On Mon, Oct 26, 2015 at 4:15 PM, Yingjoe Chen > >> wrote: > >> > On Mon, 2015-10-26 at 09:56 +0900, Kevin Hilman wrote: > >> >> Hello, > >> >> > >> >> On Sat, Oct 3, 2015 at 12:19 AM, Yingjoe Chen > >> >> wrote: > >> >> > Add arch timer node to enable arch-timer support. MT8135 firmware > >> >> > doesn't correctly setup arch-timer frequency and CNTVOFF, add > >> >> > properties to workaround this. > >> >> > > >> >> > This also set cpu enable-method to enable SMP. > >> >> > > >> >> > Signed-off-by: Yingjoe Chen > >> >> > >> >> kernelci.org started detecting new boot failures for the mt8135-evb in > >> >> the arm-soc tree[1], and the boot failures were bisected down to this > >> >> patch, which landed upstream in the form of commit d186a394bb98 (ARM: > >> >> dts: mt8135: enable basic SMP bringup for mt8135) > >> >> > >> >> Maybe this new SMP support requires updating the firmware on the board > >> >> as well? If so, the changelog should've been a bit more explicit > >> >> about firmware dependencies. > >> > > >> > Kevin, > >> > > >> > Thanks for testing. > >> > > >> > No, it doesn't need new firmware. Will test to see what's going wrong. > >> > >> Thanks for following up. I'll be glad to test any patches if you have > >> anything you'd like me to test. > > > > You need "clockevents/drivers/mtk: Fix spurious interrupt leading to > > crash" (https://lkml.org/lkml/2015/8/24/803) > > > > Daniel Lezcano already applied this patch in his tree for 4.4. > > (https://git.linaro.org/people/daniel.lezcano/linux.git) > > The mt8135-evp board is still failing to boot in linux-next[1] (and > has been since next-20151022.) It appears the dependencies are not > quite correct in linux-next either. > > Kevin > > [1] > http://kernelci.org/boot/mt8135-evbp1/job/next/kernel/next-20151109/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=564037fe59b514b2f6091909 Hi Kevin, I check the log [0], it seems first time mt8135-evbp1 boot to kernel shell successfully, then boot again. In the second time, mt8135 stay in fastboot mode, waiting host send boot image, then timeout. I download zImage and dtb in [1], and kernel run to shell successfully on my platform. I don't know whether this issue caused by test environment or not. [0] http://storage.kernelci.org/next/next-20151109/arm-multi_v7_defconfig/lab-khilman/boot-mt8135-evbp1.txt [1] http://kernelci.org/boot/mt8135-evbp1/job/next/kernel/next-20151109/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=564037fe59b514b2f6091909#bisect-content -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
On Mon, 2015-11-09 at 09:59 -0800, Kevin Hilman wrote: > On Mon, Oct 26, 2015 at 4:40 AM, Eddie Huang <eddie.hu...@mediatek.com> wrote: > > Hi Kevin, > > > > On Mon, 2015-10-26 at 17:06 +0900, Kevin Hilman wrote: > >> On Mon, Oct 26, 2015 at 4:15 PM, Yingjoe Chen <yingjoe.c...@mediatek.com> > >> wrote: > >> > On Mon, 2015-10-26 at 09:56 +0900, Kevin Hilman wrote: > >> >> Hello, > >> >> > >> >> On Sat, Oct 3, 2015 at 12:19 AM, Yingjoe Chen > >> >> <yingjoe.c...@mediatek.com> wrote: > >> >> > Add arch timer node to enable arch-timer support. MT8135 firmware > >> >> > doesn't correctly setup arch-timer frequency and CNTVOFF, add > >> >> > properties to workaround this. > >> >> > > >> >> > This also set cpu enable-method to enable SMP. > >> >> > > >> >> > Signed-off-by: Yingjoe Chen <yingjoe.c...@mediatek.com> > >> >> > >> >> kernelci.org started detecting new boot failures for the mt8135-evb in > >> >> the arm-soc tree[1], and the boot failures were bisected down to this > >> >> patch, which landed upstream in the form of commit d186a394bb98 (ARM: > >> >> dts: mt8135: enable basic SMP bringup for mt8135) > >> >> > >> >> Maybe this new SMP support requires updating the firmware on the board > >> >> as well? If so, the changelog should've been a bit more explicit > >> >> about firmware dependencies. > >> > > >> > Kevin, > >> > > >> > Thanks for testing. > >> > > >> > No, it doesn't need new firmware. Will test to see what's going wrong. > >> > >> Thanks for following up. I'll be glad to test any patches if you have > >> anything you'd like me to test. > > > > You need "clockevents/drivers/mtk: Fix spurious interrupt leading to > > crash" (https://lkml.org/lkml/2015/8/24/803) > > > > Daniel Lezcano already applied this patch in his tree for 4.4. > > (https://git.linaro.org/people/daniel.lezcano/linux.git) > > The mt8135-evp board is still failing to boot in linux-next[1] (and > has been since next-20151022.) It appears the dependencies are not > quite correct in linux-next either. > > Kevin > > [1] > http://kernelci.org/boot/mt8135-evbp1/job/next/kernel/next-20151109/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=564037fe59b514b2f6091909 Hi Kevin, I check the log [0], it seems first time mt8135-evbp1 boot to kernel shell successfully, then boot again. In the second time, mt8135 stay in fastboot mode, waiting host send boot image, then timeout. I download zImage and dtb in [1], and kernel run to shell successfully on my platform. I don't know whether this issue caused by test environment or not. [0] http://storage.kernelci.org/next/next-20151109/arm-multi_v7_defconfig/lab-khilman/boot-mt8135-evbp1.txt [1] http://kernelci.org/boot/mt8135-evbp1/job/next/kernel/next-20151109/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=564037fe59b514b2f6091909#bisect-content -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Mediatek I2C driver fixup
On Tue, 2015-10-27 at 16:59 +0800, Liguo Zhang wrote: > This series contain two patches, first is to optimize Mediatek I2C driver to > use WRRD > if hardware support auto restart. Because auto restart will issue auto restart > interrupt, change to use WRRD can reduce interrupt latency. The second is to > fix > multi transfer error in high speed mode. If hardware support auto restart, > need driver > to send master code first. Please fix checkpatch warning in 2/2, then you get my reviewed-by for this series: Reviewed-by:Eddie Huang > > Liguo Zhang (2): > i2c: mediatek: add i2c first write then read optimization > i2c: mediatek: fix i2c multi transfer issue in high speed mode > > drivers/i2c/busses/i2c-mt65xx.c | 77 > + > 1 file changed, 71 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Mediatek I2C driver fixup
On Tue, 2015-10-27 at 16:59 +0800, Liguo Zhang wrote: > This series contain two patches, first is to optimize Mediatek I2C driver to > use WRRD > if hardware support auto restart. Because auto restart will issue auto restart > interrupt, change to use WRRD can reduce interrupt latency. The second is to > fix > multi transfer error in high speed mode. If hardware support auto restart, > need driver > to send master code first. Please fix checkpatch warning in 2/2, then you get my reviewed-by for this series: Reviewed-by:Eddie Huang> > Liguo Zhang (2): > i2c: mediatek: add i2c first write then read optimization > i2c: mediatek: fix i2c multi transfer issue in high speed mode > > drivers/i2c/busses/i2c-mt65xx.c | 77 > + > 1 file changed, 71 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
On Thu, 2015-10-29 at 02:12 -0700, Kevin Hilman wrote: > Eddie Huang writes: > > > Hi Kevin, > > > > On Mon, 2015-10-26 at 17:06 +0900, Kevin Hilman wrote: > >> On Mon, Oct 26, 2015 at 4:15 PM, Yingjoe Chen > >> wrote: > >> > On Mon, 2015-10-26 at 09:56 +0900, Kevin Hilman wrote: > >> >> Hello, > >> >> > >> >> On Sat, Oct 3, 2015 at 12:19 AM, Yingjoe Chen > >> >> wrote: > >> >> > Add arch timer node to enable arch-timer support. MT8135 firmware > >> >> > doesn't correctly setup arch-timer frequency and CNTVOFF, add > >> >> > properties to workaround this. > >> >> > > >> >> > This also set cpu enable-method to enable SMP. > >> >> > > >> >> > Signed-off-by: Yingjoe Chen > >> >> > >> >> kernelci.org started detecting new boot failures for the mt8135-evb in > >> >> the arm-soc tree[1], and the boot failures were bisected down to this > >> >> patch, which landed upstream in the form of commit d186a394bb98 (ARM: > >> >> dts: mt8135: enable basic SMP bringup for mt8135) > >> >> > >> >> Maybe this new SMP support requires updating the firmware on the board > >> >> as well? If so, the changelog should've been a bit more explicit > >> >> about firmware dependencies. > >> > > >> > Kevin, > >> > > >> > Thanks for testing. > >> > > >> > No, it doesn't need new firmware. Will test to see what's going wrong. > >> > >> Thanks for following up. I'll be glad to test any patches if you have > >> anything you'd like me to test. > > > > You need "clockevents/drivers/mtk: Fix spurious interrupt leading to > > crash" (https://lkml.org/lkml/2015/8/24/803) > > > > Daniel Lezcano already applied this patch in his tree for 4.4. > > (https://git.linaro.org/people/daniel.lezcano/linux.git) > > > > Thanks for letting us know. > > In the future, these kinds of cross-tree dependencies are important to > mention in the cover letter of the pull request so we can setup > dependency branches and keep arm-soc/for-next building and booting. > sorry, we will be more careful in the future Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
On Thu, 2015-10-29 at 02:12 -0700, Kevin Hilman wrote: > Eddie Huang <eddie.hu...@mediatek.com> writes: > > > Hi Kevin, > > > > On Mon, 2015-10-26 at 17:06 +0900, Kevin Hilman wrote: > >> On Mon, Oct 26, 2015 at 4:15 PM, Yingjoe Chen <yingjoe.c...@mediatek.com> > >> wrote: > >> > On Mon, 2015-10-26 at 09:56 +0900, Kevin Hilman wrote: > >> >> Hello, > >> >> > >> >> On Sat, Oct 3, 2015 at 12:19 AM, Yingjoe Chen > >> >> <yingjoe.c...@mediatek.com> wrote: > >> >> > Add arch timer node to enable arch-timer support. MT8135 firmware > >> >> > doesn't correctly setup arch-timer frequency and CNTVOFF, add > >> >> > properties to workaround this. > >> >> > > >> >> > This also set cpu enable-method to enable SMP. > >> >> > > >> >> > Signed-off-by: Yingjoe Chen <yingjoe.c...@mediatek.com> > >> >> > >> >> kernelci.org started detecting new boot failures for the mt8135-evb in > >> >> the arm-soc tree[1], and the boot failures were bisected down to this > >> >> patch, which landed upstream in the form of commit d186a394bb98 (ARM: > >> >> dts: mt8135: enable basic SMP bringup for mt8135) > >> >> > >> >> Maybe this new SMP support requires updating the firmware on the board > >> >> as well? If so, the changelog should've been a bit more explicit > >> >> about firmware dependencies. > >> > > >> > Kevin, > >> > > >> > Thanks for testing. > >> > > >> > No, it doesn't need new firmware. Will test to see what's going wrong. > >> > >> Thanks for following up. I'll be glad to test any patches if you have > >> anything you'd like me to test. > > > > You need "clockevents/drivers/mtk: Fix spurious interrupt leading to > > crash" (https://lkml.org/lkml/2015/8/24/803) > > > > Daniel Lezcano already applied this patch in his tree for 4.4. > > (https://git.linaro.org/people/daniel.lezcano/linux.git) > > > > Thanks for letting us know. > > In the future, these kinds of cross-tree dependencies are important to > mention in the cover letter of the pull request so we can setup > dependency branches and keep arm-soc/for-next building and booting. > sorry, we will be more careful in the future Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
Hi Kevin, On Mon, 2015-10-26 at 17:06 +0900, Kevin Hilman wrote: > On Mon, Oct 26, 2015 at 4:15 PM, Yingjoe Chen > wrote: > > On Mon, 2015-10-26 at 09:56 +0900, Kevin Hilman wrote: > >> Hello, > >> > >> On Sat, Oct 3, 2015 at 12:19 AM, Yingjoe Chen > >> wrote: > >> > Add arch timer node to enable arch-timer support. MT8135 firmware > >> > doesn't correctly setup arch-timer frequency and CNTVOFF, add > >> > properties to workaround this. > >> > > >> > This also set cpu enable-method to enable SMP. > >> > > >> > Signed-off-by: Yingjoe Chen > >> > >> kernelci.org started detecting new boot failures for the mt8135-evb in > >> the arm-soc tree[1], and the boot failures were bisected down to this > >> patch, which landed upstream in the form of commit d186a394bb98 (ARM: > >> dts: mt8135: enable basic SMP bringup for mt8135) > >> > >> Maybe this new SMP support requires updating the firmware on the board > >> as well? If so, the changelog should've been a bit more explicit > >> about firmware dependencies. > > > > Kevin, > > > > Thanks for testing. > > > > No, it doesn't need new firmware. Will test to see what's going wrong. > > Thanks for following up. I'll be glad to test any patches if you have > anything you'd like me to test. You need "clockevents/drivers/mtk: Fix spurious interrupt leading to crash" (https://lkml.org/lkml/2015/8/24/803) Daniel Lezcano already applied this patch in his tree for 4.4. (https://git.linaro.org/people/daniel.lezcano/linux.git) Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
Hi Kevin, On Mon, 2015-10-26 at 17:06 +0900, Kevin Hilman wrote: > On Mon, Oct 26, 2015 at 4:15 PM, Yingjoe Chen> wrote: > > On Mon, 2015-10-26 at 09:56 +0900, Kevin Hilman wrote: > >> Hello, > >> > >> On Sat, Oct 3, 2015 at 12:19 AM, Yingjoe Chen > >> wrote: > >> > Add arch timer node to enable arch-timer support. MT8135 firmware > >> > doesn't correctly setup arch-timer frequency and CNTVOFF, add > >> > properties to workaround this. > >> > > >> > This also set cpu enable-method to enable SMP. > >> > > >> > Signed-off-by: Yingjoe Chen > >> > >> kernelci.org started detecting new boot failures for the mt8135-evb in > >> the arm-soc tree[1], and the boot failures were bisected down to this > >> patch, which landed upstream in the form of commit d186a394bb98 (ARM: > >> dts: mt8135: enable basic SMP bringup for mt8135) > >> > >> Maybe this new SMP support requires updating the firmware on the board > >> as well? If so, the changelog should've been a bit more explicit > >> about firmware dependencies. > > > > Kevin, > > > > Thanks for testing. > > > > No, it doesn't need new firmware. Will test to see what's going wrong. > > Thanks for following up. I'll be glad to test any patches if you have > anything you'd like me to test. You need "clockevents/drivers/mtk: Fix spurious interrupt leading to crash" (https://lkml.org/lkml/2015/8/24/803) Daniel Lezcano already applied this patch in his tree for 4.4. (https://git.linaro.org/people/daniel.lezcano/linux.git) Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: mediatek: add i2c resume support
From: Liguo Zhang mt65xx i2c controller initial setting will be cleared after system suspend, so we should init mt65xx i2c controller again when system resume. Signed-off-by: Liguo Zhang Signed-off-by: Eddie Huang --- drivers/i2c/busses/i2c-mt65xx.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index c02e6c0..9b86716 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -728,11 +728,27 @@ static int mtk_i2c_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM_SLEEP +static int mtk_i2c_resume(struct device *dev) +{ + struct mtk_i2c *i2c = dev_get_drvdata(dev); + + mtk_i2c_init_hw(i2c); + + return 0; +} +#endif + +static const struct dev_pm_ops mtk_i2c_pm = { + SET_SYSTEM_SLEEP_PM_OPS(NULL, mtk_i2c_resume) +}; + static struct platform_driver mtk_i2c_driver = { .probe = mtk_i2c_probe, .remove = mtk_i2c_remove, .driver = { .name = I2C_DRV_NAME, + .pm = _i2c_pm, .of_match_table = of_match_ptr(mtk_i2c_of_match), }, }; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: mediatek: add i2c resume support
From: Liguo Zhang <liguo.zh...@mediatek.com> mt65xx i2c controller initial setting will be cleared after system suspend, so we should init mt65xx i2c controller again when system resume. Signed-off-by: Liguo Zhang <liguo.zh...@mediatek.com> Signed-off-by: Eddie Huang <eddie.hu...@mediatek.com> --- drivers/i2c/busses/i2c-mt65xx.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index c02e6c0..9b86716 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -728,11 +728,27 @@ static int mtk_i2c_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM_SLEEP +static int mtk_i2c_resume(struct device *dev) +{ + struct mtk_i2c *i2c = dev_get_drvdata(dev); + + mtk_i2c_init_hw(i2c); + + return 0; +} +#endif + +static const struct dev_pm_ops mtk_i2c_pm = { + SET_SYSTEM_SLEEP_PM_OPS(NULL, mtk_i2c_resume) +}; + static struct platform_driver mtk_i2c_driver = { .probe = mtk_i2c_probe, .remove = mtk_i2c_remove, .driver = { .name = I2C_DRV_NAME, + .pm = _i2c_pm, .of_match_table = of_match_ptr(mtk_i2c_of_match), }, }; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] clk: mediatek: New clocks support and fixes
On Thu, 2015-10-01 at 12:29 -0700, Stephen Boyd wrote: > On 09/30, Daniel Kurtz wrote: > > Hi Mike, > > > > On Tue, Sep 22, 2015 at 5:53 PM, James Liao > > wrote: > > > This is a collection of new Mediatek clocks support and fixes. These > > > patches come from Joe [1], Pi-cheng [2] and me [3], including clock > > > support for subsystems, CPU, GPT and some minor fixes. > > > > > > [1] https://patchwork.kernel.org/patch/6777041/ > > > [2] https://patchwork.kernel.org/patch/7174721/ > > > [3] https://lkml.org/lkml/2015/8/10/194 > > > > > > > > > > > > The following changes since commit > > > 1f93e4a96c9109378204c147b3eec0d0e8100fde: > > > > > > Linux 4.3-rc2 (2015-09-20 14:32:34 -0700) > > > > > > are available in the git repository at: > > > > > > https://github.com/jamesjjliao/linux.git v4.3-rc2-clk > > > > > > for you to fetch changes up to 74219612bb7e25e64409171acada05d9949228f2: > > > > > > arm64: dts: mt8173: Add subsystem clock controller device nodes > > > (2015-07-09 12:58:14 +0800) > > > > > > > Will this be pulled for 4.3, or is it now destined for 4.4? > > (sorry if you are receiving a duplicate email, the previous had HTML > > and was rejected by the lists) > > This won't make v4.3. I see that there's a third pull request > now, with slightly different contents. Why? > Sorry not explain in pull request mail. Third pull request remove two patches: 1. arm64: dts: mt8173: Add subsystem clock controller device nodes I think this should pull by Matthias, so I suggest James remove this patch. 2. clk: mediatek: Export CPU mux clocks for CPU frequency control Mike said this patch is ok before (http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/364886.html) But he told Pi-cheng recently he is working on coordinate clock rate, he suggest Pi-cheng change this patch, other patches are ok. So James remove this patch. Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] clk: mediatek: New clocks support and fixes
On Thu, 2015-10-01 at 12:29 -0700, Stephen Boyd wrote: > On 09/30, Daniel Kurtz wrote: > > Hi Mike, > > > > On Tue, Sep 22, 2015 at 5:53 PM, James Liao> > wrote: > > > This is a collection of new Mediatek clocks support and fixes. These > > > patches come from Joe [1], Pi-cheng [2] and me [3], including clock > > > support for subsystems, CPU, GPT and some minor fixes. > > > > > > [1] https://patchwork.kernel.org/patch/6777041/ > > > [2] https://patchwork.kernel.org/patch/7174721/ > > > [3] https://lkml.org/lkml/2015/8/10/194 > > > > > > > > > > > > The following changes since commit > > > 1f93e4a96c9109378204c147b3eec0d0e8100fde: > > > > > > Linux 4.3-rc2 (2015-09-20 14:32:34 -0700) > > > > > > are available in the git repository at: > > > > > > https://github.com/jamesjjliao/linux.git v4.3-rc2-clk > > > > > > for you to fetch changes up to 74219612bb7e25e64409171acada05d9949228f2: > > > > > > arm64: dts: mt8173: Add subsystem clock controller device nodes > > > (2015-07-09 12:58:14 +0800) > > > > > > > Will this be pulled for 4.3, or is it now destined for 4.4? > > (sorry if you are receiving a duplicate email, the previous had HTML > > and was rejected by the lists) > > This won't make v4.3. I see that there's a third pull request > now, with slightly different contents. Why? > Sorry not explain in pull request mail. Third pull request remove two patches: 1. arm64: dts: mt8173: Add subsystem clock controller device nodes I think this should pull by Matthias, so I suggest James remove this patch. 2. clk: mediatek: Export CPU mux clocks for CPU frequency control Mike said this patch is ok before (http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/364886.html) But he told Pi-cheng recently he is working on coordinate clock rate, he suggest Pi-cheng change this patch, other patches are ok. So James remove this patch. Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] soc: mediatek: add scpsys support active_wakeup
Register gpd_dev_ops.active_wakeup function to support keep power during suspend state. And add flag to each power domain to decide whether keep power during suspend or not. Signed-off-by: Chunfeng Yun Signed-off-by: Eddie Huang Acked-by: Sascha Hauer Reviewed-by: Daniel Kurtz --- Change in v3: Remove check dev->power_domain NULL or ERR. This will not happen when call scpsys_active_wakeup function Change in v2: Drop .active_wakeup = false lines in scp_domain_data[] array --- drivers/soc/mediatek/mtk-scpsys.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c index 43a79ed..3a00975 100644 --- a/drivers/soc/mediatek/mtk-scpsys.c +++ b/drivers/soc/mediatek/mtk-scpsys.c @@ -67,6 +67,7 @@ struct scp_domain_data { u32 sram_pdn_ack_bits; u32 bus_prot_mask; enum clk_id clk_id; + bool active_wakeup; }; static const struct scp_domain_data scp_domain_data[] __initconst = { @@ -127,6 +128,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = true, }, [MT8173_POWER_DOMAIN_MFG_ASYNC] = { .name = "mfg_async", @@ -171,6 +173,7 @@ struct scp_domain { u32 sram_pdn_bits; u32 sram_pdn_ack_bits; u32 bus_prot_mask; + bool active_wakeup; }; struct scp { @@ -370,6 +373,17 @@ out: return ret; } +static bool scpsys_active_wakeup(struct device *dev) +{ + struct generic_pm_domain *genpd; + struct scp_domain *scpd; + + genpd = pd_to_genpd(dev->pm_domain); + scpd = container_of(genpd, struct scp_domain, genpd); + + return scpd->active_wakeup; +} + static int __init scpsys_probe(struct platform_device *pdev) { struct genpd_onecell_data *pd_data; @@ -427,12 +441,14 @@ static int __init scpsys_probe(struct platform_device *pdev) scpd->sram_pdn_bits = data->sram_pdn_bits; scpd->sram_pdn_ack_bits = data->sram_pdn_ack_bits; scpd->bus_prot_mask = data->bus_prot_mask; + scpd->active_wakeup = data->active_wakeup; if (data->clk_id != MT8173_CLK_NONE) scpd->clk = clk[data->clk_id]; genpd->name = data->name; genpd->power_off = scpsys_power_off; genpd->power_on = scpsys_power_on; + genpd->dev_ops.active_wakeup = scpsys_active_wakeup; /* * Initially turn on all domains to make the domains usable -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] soc: mediatek: add scpsys support active_wakeup
On Wed, 2015-08-26 at 05:11 +0800, Daniel Kurtz wrote: > Hi Eddie, > > On Tue, Aug 25, 2015 at 2:00 PM, Eddie Huang wrote: > > Register gpd_dev_ops.active_wakeup function to support keep power > > during suspend state. And add flag to each power domain to > > decide whether keep power during suspend or not. > > > > Signed-off-by: Chunfeng Yun > > Signed-off-by: Eddie Huang > > Acked-by: Sascha Hauer > > > > --- > > Change in v2: > > Drop .active_wakeup = false lines in scp_domain_data[] array > > > > --- > > drivers/soc/mediatek/mtk-scpsys.c | 19 +++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/drivers/soc/mediatek/mtk-scpsys.c > > b/drivers/soc/mediatek/mtk-scpsys.c > > index 43a79ed..df2f288 100644 > > --- a/drivers/soc/mediatek/mtk-scpsys.c > > +++ b/drivers/soc/mediatek/mtk-scpsys.c > > @@ -67,6 +67,7 @@ struct scp_domain_data { > > u32 sram_pdn_ack_bits; > > u32 bus_prot_mask; > > enum clk_id clk_id; > > + bool active_wakeup; > > }; > > > > static const struct scp_domain_data scp_domain_data[] __initconst = { > > @@ -127,6 +128,7 @@ static const struct scp_domain_data scp_domain_data[] > > __initconst = { > > .sram_pdn_bits = GENMASK(11, 8), > > .sram_pdn_ack_bits = GENMASK(15, 12), > > .clk_id = MT8173_CLK_NONE, > > + .active_wakeup = true, > > }, > > [MT8173_POWER_DOMAIN_MFG_ASYNC] = { > > .name = "mfg_async", > > @@ -171,6 +173,7 @@ struct scp_domain { > > u32 sram_pdn_bits; > > u32 sram_pdn_ack_bits; > > u32 bus_prot_mask; > > + bool active_wakeup; > > }; > > > > struct scp { > > @@ -370,6 +373,20 @@ out: > > return ret; > > } > > > > +static bool scpsys_active_wakeup(struct device *dev) > > +{ > > + struct generic_pm_domain *genpd; > > + struct scp_domain *scpd; > > + > > + if (IS_ERR_OR_NULL(dev->pm_domain)) > > + return false; > > Is it really possible to get here w/ pm_domain as an ERR or NULL? > If the power core can ensure this cannot happen, then this function > could be a bit simpler. > > Other than that, this patch is: > Reviewed-by: Daniel Kurtz > > -Dan > After checking drivers/base/power/domain.c, I believe check dev->pm_domain here is redundant, I will remove it. Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] soc: mediatek: add scpsys support active_wakeup
On Wed, 2015-08-26 at 05:11 +0800, Daniel Kurtz wrote: Hi Eddie, On Tue, Aug 25, 2015 at 2:00 PM, Eddie Huang eddie.hu...@mediatek.com wrote: Register gpd_dev_ops.active_wakeup function to support keep power during suspend state. And add flag to each power domain to decide whether keep power during suspend or not. Signed-off-by: Chunfeng Yun chunfeng@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com Acked-by: Sascha Hauer s.ha...@pengutronix.de --- Change in v2: Drop .active_wakeup = false lines in scp_domain_data[] array --- drivers/soc/mediatek/mtk-scpsys.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c index 43a79ed..df2f288 100644 --- a/drivers/soc/mediatek/mtk-scpsys.c +++ b/drivers/soc/mediatek/mtk-scpsys.c @@ -67,6 +67,7 @@ struct scp_domain_data { u32 sram_pdn_ack_bits; u32 bus_prot_mask; enum clk_id clk_id; + bool active_wakeup; }; static const struct scp_domain_data scp_domain_data[] __initconst = { @@ -127,6 +128,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = true, }, [MT8173_POWER_DOMAIN_MFG_ASYNC] = { .name = mfg_async, @@ -171,6 +173,7 @@ struct scp_domain { u32 sram_pdn_bits; u32 sram_pdn_ack_bits; u32 bus_prot_mask; + bool active_wakeup; }; struct scp { @@ -370,6 +373,20 @@ out: return ret; } +static bool scpsys_active_wakeup(struct device *dev) +{ + struct generic_pm_domain *genpd; + struct scp_domain *scpd; + + if (IS_ERR_OR_NULL(dev-pm_domain)) + return false; Is it really possible to get here w/ pm_domain as an ERR or NULL? If the power core can ensure this cannot happen, then this function could be a bit simpler. Other than that, this patch is: Reviewed-by: Daniel Kurtz djku...@chromium.org -Dan After checking drivers/base/power/domain.c, I believe check dev-pm_domain here is redundant, I will remove it. Eddie Thanks -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] soc: mediatek: add scpsys support active_wakeup
Register gpd_dev_ops.active_wakeup function to support keep power during suspend state. And add flag to each power domain to decide whether keep power during suspend or not. Signed-off-by: Chunfeng Yun chunfeng@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com Acked-by: Sascha Hauer s.ha...@pengutronix.de Reviewed-by: Daniel Kurtz djku...@chromium.org --- Change in v3: Remove check dev-power_domain NULL or ERR. This will not happen when call scpsys_active_wakeup function Change in v2: Drop .active_wakeup = false lines in scp_domain_data[] array --- drivers/soc/mediatek/mtk-scpsys.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c index 43a79ed..3a00975 100644 --- a/drivers/soc/mediatek/mtk-scpsys.c +++ b/drivers/soc/mediatek/mtk-scpsys.c @@ -67,6 +67,7 @@ struct scp_domain_data { u32 sram_pdn_ack_bits; u32 bus_prot_mask; enum clk_id clk_id; + bool active_wakeup; }; static const struct scp_domain_data scp_domain_data[] __initconst = { @@ -127,6 +128,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = true, }, [MT8173_POWER_DOMAIN_MFG_ASYNC] = { .name = mfg_async, @@ -171,6 +173,7 @@ struct scp_domain { u32 sram_pdn_bits; u32 sram_pdn_ack_bits; u32 bus_prot_mask; + bool active_wakeup; }; struct scp { @@ -370,6 +373,17 @@ out: return ret; } +static bool scpsys_active_wakeup(struct device *dev) +{ + struct generic_pm_domain *genpd; + struct scp_domain *scpd; + + genpd = pd_to_genpd(dev-pm_domain); + scpd = container_of(genpd, struct scp_domain, genpd); + + return scpd-active_wakeup; +} + static int __init scpsys_probe(struct platform_device *pdev) { struct genpd_onecell_data *pd_data; @@ -427,12 +441,14 @@ static int __init scpsys_probe(struct platform_device *pdev) scpd-sram_pdn_bits = data-sram_pdn_bits; scpd-sram_pdn_ack_bits = data-sram_pdn_ack_bits; scpd-bus_prot_mask = data-bus_prot_mask; + scpd-active_wakeup = data-active_wakeup; if (data-clk_id != MT8173_CLK_NONE) scpd-clk = clk[data-clk_id]; genpd-name = data-name; genpd-power_off = scpsys_power_off; genpd-power_on = scpsys_power_on; + genpd-dev_ops.active_wakeup = scpsys_active_wakeup; /* * Initially turn on all domains to make the domains usable -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] soc: mediatek: add scpsys support active_wakeup
Register gpd_dev_ops.active_wakeup function to support keep power during suspend state. And add flag to each power domain to decide whether keep power during suspend or not. Signed-off-by: Chunfeng Yun Signed-off-by: Eddie Huang Acked-by: Sascha Hauer --- Change in v2: Drop .active_wakeup = false lines in scp_domain_data[] array --- drivers/soc/mediatek/mtk-scpsys.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c index 43a79ed..df2f288 100644 --- a/drivers/soc/mediatek/mtk-scpsys.c +++ b/drivers/soc/mediatek/mtk-scpsys.c @@ -67,6 +67,7 @@ struct scp_domain_data { u32 sram_pdn_ack_bits; u32 bus_prot_mask; enum clk_id clk_id; + bool active_wakeup; }; static const struct scp_domain_data scp_domain_data[] __initconst = { @@ -127,6 +128,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = true, }, [MT8173_POWER_DOMAIN_MFG_ASYNC] = { .name = "mfg_async", @@ -171,6 +173,7 @@ struct scp_domain { u32 sram_pdn_bits; u32 sram_pdn_ack_bits; u32 bus_prot_mask; + bool active_wakeup; }; struct scp { @@ -370,6 +373,20 @@ out: return ret; } +static bool scpsys_active_wakeup(struct device *dev) +{ + struct generic_pm_domain *genpd; + struct scp_domain *scpd; + + if (IS_ERR_OR_NULL(dev->pm_domain)) + return false; + + genpd = pd_to_genpd(dev->pm_domain); + scpd = container_of(genpd, struct scp_domain, genpd); + + return scpd->active_wakeup; +} + static int __init scpsys_probe(struct platform_device *pdev) { struct genpd_onecell_data *pd_data; @@ -427,12 +444,14 @@ static int __init scpsys_probe(struct platform_device *pdev) scpd->sram_pdn_bits = data->sram_pdn_bits; scpd->sram_pdn_ack_bits = data->sram_pdn_ack_bits; scpd->bus_prot_mask = data->bus_prot_mask; + scpd->active_wakeup = data->active_wakeup; if (data->clk_id != MT8173_CLK_NONE) scpd->clk = clk[data->clk_id]; genpd->name = data->name; genpd->power_off = scpsys_power_off; genpd->power_on = scpsys_power_on; + genpd->dev_ops.active_wakeup = scpsys_active_wakeup; /* * Initially turn on all domains to make the domains usable -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] soc: mediatek: add scpsys support active_wakeup
Register gpd_dev_ops.active_wakeup function to support keep power during suspend state. And add flag to each power domain to decide whether keep power during suspend or not. Signed-off-by: Chunfeng Yun chunfeng@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com Acked-by: Sascha Hauer s.ha...@pengutronix.de --- Change in v2: Drop .active_wakeup = false lines in scp_domain_data[] array --- drivers/soc/mediatek/mtk-scpsys.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c index 43a79ed..df2f288 100644 --- a/drivers/soc/mediatek/mtk-scpsys.c +++ b/drivers/soc/mediatek/mtk-scpsys.c @@ -67,6 +67,7 @@ struct scp_domain_data { u32 sram_pdn_ack_bits; u32 bus_prot_mask; enum clk_id clk_id; + bool active_wakeup; }; static const struct scp_domain_data scp_domain_data[] __initconst = { @@ -127,6 +128,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = true, }, [MT8173_POWER_DOMAIN_MFG_ASYNC] = { .name = mfg_async, @@ -171,6 +173,7 @@ struct scp_domain { u32 sram_pdn_bits; u32 sram_pdn_ack_bits; u32 bus_prot_mask; + bool active_wakeup; }; struct scp { @@ -370,6 +373,20 @@ out: return ret; } +static bool scpsys_active_wakeup(struct device *dev) +{ + struct generic_pm_domain *genpd; + struct scp_domain *scpd; + + if (IS_ERR_OR_NULL(dev-pm_domain)) + return false; + + genpd = pd_to_genpd(dev-pm_domain); + scpd = container_of(genpd, struct scp_domain, genpd); + + return scpd-active_wakeup; +} + static int __init scpsys_probe(struct platform_device *pdev) { struct genpd_onecell_data *pd_data; @@ -427,12 +444,14 @@ static int __init scpsys_probe(struct platform_device *pdev) scpd-sram_pdn_bits = data-sram_pdn_bits; scpd-sram_pdn_ack_bits = data-sram_pdn_ack_bits; scpd-bus_prot_mask = data-bus_prot_mask; + scpd-active_wakeup = data-active_wakeup; if (data-clk_id != MT8173_CLK_NONE) scpd-clk = clk[data-clk_id]; genpd-name = data-name; genpd-power_off = scpsys_power_off; genpd-power_on = scpsys_power_on; + genpd-dev_ops.active_wakeup = scpsys_active_wakeup; /* * Initially turn on all domains to make the domains usable -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] soc: mediatek: add scpsys support active_wakeup
On Thu, 2015-07-23 at 14:00 +0800, Eddie Huang wrote: > Register gpd_dev_ops.active_wakeup function to support keep power > during suspend state. And add flag to each power domain to > decide whether keep power during suspend or not. > > Signed-off-by: Chunfeng Yun > Signed-off-by: Eddie Huang > --- > drivers/soc/mediatek/mtk-scpsys.c | 28 > 1 file changed, 28 insertions(+) > > diff --git a/drivers/soc/mediatek/mtk-scpsys.c > b/drivers/soc/mediatek/mtk-scpsys.c > index 43a79ed..fc78b70 100644 > --- a/drivers/soc/mediatek/mtk-scpsys.c > +++ b/drivers/soc/mediatek/mtk-scpsys.c > @@ -67,6 +67,7 @@ struct scp_domain_data { > u32 sram_pdn_ack_bits; > u32 bus_prot_mask; > enum clk_id clk_id; > + bool active_wakeup; > }; > > static const struct scp_domain_data scp_domain_data[] __initconst = { > @@ -77,6 +78,7 @@ static const struct scp_domain_data scp_domain_data[] > __initconst = { > .sram_pdn_bits = GENMASK(11, 8), > .sram_pdn_ack_bits = GENMASK(12, 12), > .clk_id = MT8173_CLK_MM, > + .active_wakeup = false, > }, > [MT8173_POWER_DOMAIN_VENC] = { > .name = "venc", > @@ -85,6 +87,7 @@ static const struct scp_domain_data scp_domain_data[] > __initconst = { > .sram_pdn_bits = GENMASK(11, 8), > .sram_pdn_ack_bits = GENMASK(15, 12), > .clk_id = MT8173_CLK_MM, > + .active_wakeup = false, > }, > [MT8173_POWER_DOMAIN_ISP] = { > .name = "isp", > @@ -93,6 +96,7 @@ static const struct scp_domain_data scp_domain_data[] > __initconst = { > .sram_pdn_bits = GENMASK(11, 8), > .sram_pdn_ack_bits = GENMASK(13, 12), > .clk_id = MT8173_CLK_MM, > + .active_wakeup = false, > }, > [MT8173_POWER_DOMAIN_MM] = { > .name = "mm", > @@ -101,6 +105,7 @@ static const struct scp_domain_data scp_domain_data[] > __initconst = { > .sram_pdn_bits = GENMASK(11, 8), > .sram_pdn_ack_bits = GENMASK(12, 12), > .clk_id = MT8173_CLK_MM, > + .active_wakeup = false, > .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 | > MT8173_TOP_AXI_PROT_EN_MM_M1, > }, > @@ -111,6 +116,7 @@ static const struct scp_domain_data scp_domain_data[] > __initconst = { > .sram_pdn_bits = GENMASK(11, 8), > .sram_pdn_ack_bits = GENMASK(15, 12), > .clk_id = MT8173_CLK_MM, > + .active_wakeup = false, > }, > [MT8173_POWER_DOMAIN_AUDIO] = { > .name = "audio", > @@ -119,6 +125,7 @@ static const struct scp_domain_data scp_domain_data[] > __initconst = { > .sram_pdn_bits = GENMASK(11, 8), > .sram_pdn_ack_bits = GENMASK(15, 12), > .clk_id = MT8173_CLK_NONE, > + .active_wakeup = false, > }, > [MT8173_POWER_DOMAIN_USB] = { > .name = "usb", > @@ -127,6 +134,7 @@ static const struct scp_domain_data scp_domain_data[] > __initconst = { > .sram_pdn_bits = GENMASK(11, 8), > .sram_pdn_ack_bits = GENMASK(15, 12), > .clk_id = MT8173_CLK_NONE, > + .active_wakeup = true, > }, > [MT8173_POWER_DOMAIN_MFG_ASYNC] = { > .name = "mfg_async", > @@ -135,6 +143,7 @@ static const struct scp_domain_data scp_domain_data[] > __initconst = { > .sram_pdn_bits = GENMASK(11, 8), > .sram_pdn_ack_bits = 0, > .clk_id = MT8173_CLK_MFG, > + .active_wakeup = false, > }, > [MT8173_POWER_DOMAIN_MFG_2D] = { > .name = "mfg_2d", > @@ -143,6 +152,7 @@ static const struct scp_domain_data scp_domain_data[] > __initconst = { > .sram_pdn_bits = GENMASK(11, 8), > .sram_pdn_ack_bits = GENMASK(13, 12), > .clk_id = MT8173_CLK_NONE, > + .active_wakeup = false, > }, > [MT8173_POWER_DOMAIN_MFG] = { > .name = "mfg", > @@ -151,6 +161,7 @@ static const struct scp_domain_data scp_domain_data[] > __initconst = { > .sram_pdn_bits = GENMASK(13, 8), > .sram_pdn_ack_bits = GENMASK(21, 16), > .clk_id = MT8173_CLK_NONE, > + .active_wakeup = false, >
Re: [PATCH] soc: mediatek: add scpsys support active_wakeup
On Thu, 2015-07-23 at 14:00 +0800, Eddie Huang wrote: Register gpd_dev_ops.active_wakeup function to support keep power during suspend state. And add flag to each power domain to decide whether keep power during suspend or not. Signed-off-by: Chunfeng Yun chunfeng@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- drivers/soc/mediatek/mtk-scpsys.c | 28 1 file changed, 28 insertions(+) diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c index 43a79ed..fc78b70 100644 --- a/drivers/soc/mediatek/mtk-scpsys.c +++ b/drivers/soc/mediatek/mtk-scpsys.c @@ -67,6 +67,7 @@ struct scp_domain_data { u32 sram_pdn_ack_bits; u32 bus_prot_mask; enum clk_id clk_id; + bool active_wakeup; }; static const struct scp_domain_data scp_domain_data[] __initconst = { @@ -77,6 +78,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(12, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_VENC] = { .name = venc, @@ -85,6 +87,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_ISP] = { .name = isp, @@ -93,6 +96,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(13, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_MM] = { .name = mm, @@ -101,6 +105,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(12, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 | MT8173_TOP_AXI_PROT_EN_MM_M1, }, @@ -111,6 +116,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_AUDIO] = { .name = audio, @@ -119,6 +125,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_USB] = { .name = usb, @@ -127,6 +134,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = true, }, [MT8173_POWER_DOMAIN_MFG_ASYNC] = { .name = mfg_async, @@ -135,6 +143,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = 0, .clk_id = MT8173_CLK_MFG, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_MFG_2D] = { .name = mfg_2d, @@ -143,6 +152,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(13, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_MFG] = { .name = mfg, @@ -151,6 +161,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(13, 8), .sram_pdn_ack_bits = GENMASK(21, 16), .clk_id = MT8173_CLK_NONE, + .active_wakeup = false, .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S | MT8173_TOP_AXI_PROT_EN_MFG_M0 | MT8173_TOP_AXI_PROT_EN_MFG_M1 | @@ -171,6 +182,7 @@ struct scp_domain { u32 sram_pdn_bits; u32 sram_pdn_ack_bits; u32 bus_prot_mask; + bool active_wakeup; }; struct scp { @@ -370,6 +382,20 @@ out: return ret; } +static bool scpsys_active_wakeup(struct device *dev) +{ + struct generic_pm_domain
[PATCH v2 2/2] i2c: mediatek: Fixup i2c ack error interrupt handling
When occur i2c ack error, i2c controller generate two interrupts, first is the ack error interrupt, then the complete interrupt. i2c interrupt handler should keep the two interrupt value, and only call complete() for the complete interrupt. Signed-off-by: Liguo Zhang Signed-off-by: Eddie Huang --- drivers/i2c/busses/i2c-mt65xx.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index e28ad4c..c02e6c0 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -557,15 +557,22 @@ static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id) { struct mtk_i2c *i2c = dev_id; u16 restart_flag = 0; + u16 intr_stat; if (i2c->dev_comp->auto_restart) restart_flag = I2C_RS_TRANSFER; - i2c->irq_stat = readw(i2c->base + OFFSET_INTR_STAT); - writew(restart_flag | I2C_HS_NACKERR | I2C_ACKERR - | I2C_TRANSAC_COMP, i2c->base + OFFSET_INTR_STAT); + intr_stat = readw(i2c->base + OFFSET_INTR_STAT); + writew(intr_stat, i2c->base + OFFSET_INTR_STAT); - complete(>msg_complete); + /* +* when occurs ack error, i2c controller generate two interrupts +* first is the ack error interrupt, then the complete interrupt +* i2c->irq_stat need keep the two interrupt value. +*/ + i2c->irq_stat |= intr_stat; + if (i2c->irq_stat & (I2C_TRANSAC_COMP | restart_flag)) + complete(>msg_complete); return IRQ_HANDLED; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] i2c: mediatek: Reset DMA engine in hardware init function
Reset DMA in hardware init function to avoid unknown hardware state before do any I2C operation. Signed-off-by: Liguo Zhang Signed-off-by: Eddie Huang --- drivers/i2c/busses/i2c-mt65xx.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index 9920eef..e28ad4c 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -59,6 +59,7 @@ #define I2C_DMA_START_EN 0x0001 #define I2C_DMA_INT_FLAG_NONE 0x #define I2C_DMA_CLR_FLAG 0x +#define I2C_DMA_HARD_RST 0x0002 #define I2C_DEFAULT_SPEED 10 /* hz */ #define MAX_FS_MODE_SPEED 40 @@ -81,6 +82,7 @@ enum DMA_REGS_OFFSET { OFFSET_INT_FLAG = 0x0, OFFSET_INT_EN = 0x04, OFFSET_EN = 0x08, + OFFSET_RST = 0x0c, OFFSET_CON = 0x18, OFFSET_TX_MEM_ADDR = 0x1c, OFFSET_RX_MEM_ADDR = 0x20, @@ -262,6 +264,10 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c) I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN; writew(control_reg, i2c->base + OFFSET_CONTROL); writew(I2C_DELAY_LEN, i2c->base + OFFSET_DELAY_LEN); + + writel(I2C_DMA_HARD_RST, i2c->pdmabase + OFFSET_RST); + udelay(50); + writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_RST); } /* -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] Mediatek I2C fixup
This series provide two patches to optimize mediatek i2c driver. The first patch will reset dma hardware in init function to make sure hardware work in good state. The second patch fix i2c interrupt handling for ACK error. All these patches base on 4.2-rc1. Change in v2: Fix multi-transfer fail bug - in mtk_i2c_irq(), call complete() if get I2C_RS_TRANSFER interrupt Eddie Huang (2): i2c: mediatek: Reset DMA engine in hardware init function i2c: mediatek: Fixup i2c ack error interrupt handling drivers/i2c/busses/i2c-mt65xx.c | 21 + 1 file changed, 17 insertions(+), 4 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] i2c: mediatek: Reset DMA engine in hardware init function
Reset DMA in hardware init function to avoid unknown hardware state before do any I2C operation. Signed-off-by: Liguo Zhang liguo.zh...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- drivers/i2c/busses/i2c-mt65xx.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index 9920eef..e28ad4c 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -59,6 +59,7 @@ #define I2C_DMA_START_EN 0x0001 #define I2C_DMA_INT_FLAG_NONE 0x #define I2C_DMA_CLR_FLAG 0x +#define I2C_DMA_HARD_RST 0x0002 #define I2C_DEFAULT_SPEED 10 /* hz */ #define MAX_FS_MODE_SPEED 40 @@ -81,6 +82,7 @@ enum DMA_REGS_OFFSET { OFFSET_INT_FLAG = 0x0, OFFSET_INT_EN = 0x04, OFFSET_EN = 0x08, + OFFSET_RST = 0x0c, OFFSET_CON = 0x18, OFFSET_TX_MEM_ADDR = 0x1c, OFFSET_RX_MEM_ADDR = 0x20, @@ -262,6 +264,10 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c) I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN; writew(control_reg, i2c-base + OFFSET_CONTROL); writew(I2C_DELAY_LEN, i2c-base + OFFSET_DELAY_LEN); + + writel(I2C_DMA_HARD_RST, i2c-pdmabase + OFFSET_RST); + udelay(50); + writel(I2C_DMA_CLR_FLAG, i2c-pdmabase + OFFSET_RST); } /* -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] i2c: mediatek: Fixup i2c ack error interrupt handling
When occur i2c ack error, i2c controller generate two interrupts, first is the ack error interrupt, then the complete interrupt. i2c interrupt handler should keep the two interrupt value, and only call complete() for the complete interrupt. Signed-off-by: Liguo Zhang liguo.zh...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- drivers/i2c/busses/i2c-mt65xx.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index e28ad4c..c02e6c0 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -557,15 +557,22 @@ static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id) { struct mtk_i2c *i2c = dev_id; u16 restart_flag = 0; + u16 intr_stat; if (i2c-dev_comp-auto_restart) restart_flag = I2C_RS_TRANSFER; - i2c-irq_stat = readw(i2c-base + OFFSET_INTR_STAT); - writew(restart_flag | I2C_HS_NACKERR | I2C_ACKERR - | I2C_TRANSAC_COMP, i2c-base + OFFSET_INTR_STAT); + intr_stat = readw(i2c-base + OFFSET_INTR_STAT); + writew(intr_stat, i2c-base + OFFSET_INTR_STAT); - complete(i2c-msg_complete); + /* +* when occurs ack error, i2c controller generate two interrupts +* first is the ack error interrupt, then the complete interrupt +* i2c-irq_stat need keep the two interrupt value. +*/ + i2c-irq_stat |= intr_stat; + if (i2c-irq_stat (I2C_TRANSAC_COMP | restart_flag)) + complete(i2c-msg_complete); return IRQ_HANDLED; } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] Mediatek I2C fixup
This series provide two patches to optimize mediatek i2c driver. The first patch will reset dma hardware in init function to make sure hardware work in good state. The second patch fix i2c interrupt handling for ACK error. All these patches base on 4.2-rc1. Change in v2: Fix multi-transfer fail bug - in mtk_i2c_irq(), call complete() if get I2C_RS_TRANSFER interrupt Eddie Huang (2): i2c: mediatek: Reset DMA engine in hardware init function i2c: mediatek: Fixup i2c ack error interrupt handling drivers/i2c/busses/i2c-mt65xx.c | 21 + 1 file changed, 17 insertions(+), 4 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] i2c: mediatek: Reset DMA engine in hardware init function
Reset DMA in hardware init function to avoid unknown hardware state before do any I2C operation. Signed-off-by: Liguo Zhang Signed-off-by: Eddie Huang --- drivers/i2c/busses/i2c-mt65xx.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index 9920eef..055159d 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -1,6 +1,8 @@ /* * Copyright (c) 2014 MediaTek Inc. - * Author: Xudong Chen + * Author: + * Xudong Chen + * Liguo Zhang * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -59,6 +61,7 @@ #define I2C_DMA_START_EN 0x0001 #define I2C_DMA_INT_FLAG_NONE 0x #define I2C_DMA_CLR_FLAG 0x +#define I2C_DMA_HARD_RST 0x0002 #define I2C_DEFAULT_SPEED 10 /* hz */ #define MAX_FS_MODE_SPEED 40 @@ -81,6 +84,7 @@ enum DMA_REGS_OFFSET { OFFSET_INT_FLAG = 0x0, OFFSET_INT_EN = 0x04, OFFSET_EN = 0x08, + OFFSET_RST = 0x0c, OFFSET_CON = 0x18, OFFSET_TX_MEM_ADDR = 0x1c, OFFSET_RX_MEM_ADDR = 0x20, @@ -262,6 +266,10 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c) I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN; writew(control_reg, i2c->base + OFFSET_CONTROL); writew(I2C_DELAY_LEN, i2c->base + OFFSET_DELAY_LEN); + + writel(I2C_DMA_HARD_RST, i2c->pdmabase + OFFSET_RST); + udelay(50); + writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_RST); } /* -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] i2c: mediatek: Fixup i2c ack error interrupt handling
When occur i2c ack error, mtk_i2c_irq is called twice, first is the ack error interrupt, then the complete interrupt. i2c interrupt handler should keep the two interrupt value, and only call complete() for the complete interrupt. Signed-off-by: Liguo Zhang Signed-off-by: Eddie Huang --- drivers/i2c/busses/i2c-mt65xx.c | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index 055159d..12ce7f8 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -558,16 +558,20 @@ err_exit: static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id) { struct mtk_i2c *i2c = dev_id; - u16 restart_flag = 0; + u16 intr_stat = 0; - if (i2c->dev_comp->auto_restart) - restart_flag = I2C_RS_TRANSFER; + intr_stat = readw(i2c->base + OFFSET_INTR_STAT); + writew(intr_stat, i2c->base + OFFSET_INTR_STAT); - i2c->irq_stat = readw(i2c->base + OFFSET_INTR_STAT); - writew(restart_flag | I2C_HS_NACKERR | I2C_ACKERR - | I2C_TRANSAC_COMP, i2c->base + OFFSET_INTR_STAT); + /* +* when occurs i2c ack error, mtk_i2c_irq is called twice, +* first is the ack error interrupt, then the complete interrupt, +* i2c->irq_stat need keep the two interrupt value. +*/ + i2c->irq_stat |= intr_stat; - complete(>msg_complete); + if (i2c->irq_stat & I2C_TRANSAC_COMP) + complete(>msg_complete); return IRQ_HANDLED; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Mediatek I2C fixup
This series provide two patches to optimize mediatek i2c driver. The first patch will reset dma hardware in init function to make sure hardware work in good state. The second patch fix i2c interrupt handling for ACK error. All these patches base on v4.2-rc1. Eddie Huang (2): i2c: mediatek: Reset DMA engine in hardware init function i2c: mediatek: Fixup i2c ack error interrupt handling drivers/i2c/busses/i2c-mt65xx.c | 28 1 file changed, 20 insertions(+), 8 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: mediatek: fix transfer error handling
On Fri, 2015-07-31 at 13:00 +0200, Wolfram Sang wrote: > On Tue, Jul 28, 2015 at 11:38:05AM +0800, Eddie Huang wrote: > > From: Liguo Zhang > > > > Reset i2c dma engine in hw init function. > > When occur i2c ack error, mtk_i2c_irq may is twice, > > first is the ack error interrupt, then the complete interrupt, > > so i2c->irq_stat need keep the two interrupt value, and only > > call complete() for the complete interrupt. > > > > Signed-off-by: Liguo Zhang > > Signed-off-by: Eddie Huang > > Looks to me this patch needs to be split up into one patch per issue? OK, I can split > And doesn't it kill the auto_restart functionality? Sascha? No. restart_flag already set in mtk_i2c_do_transfer() function.It is not necessary check restart_flag again in mtk_i2c_irq(). It is simpler to just read status bit and write back to clear interrupt status. Eddie Thanks > > > --- > > drivers/i2c/busses/i2c-mt65xx.c | 25 ++--- > > 1 file changed, 18 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/i2c/busses/i2c-mt65xx.c > > b/drivers/i2c/busses/i2c-mt65xx.c > > index 9920eef..57d11b7 100644 > > --- a/drivers/i2c/busses/i2c-mt65xx.c > > +++ b/drivers/i2c/busses/i2c-mt65xx.c > > @@ -59,6 +59,7 @@ > > #define I2C_DMA_START_EN 0x0001 > > #define I2C_DMA_INT_FLAG_NONE 0x > > #define I2C_DMA_CLR_FLAG 0x > > +#define I2C_DMA_HARD_RST 0x0002 > > > > #define I2C_DEFAULT_SPEED 10 /* hz */ > > #define MAX_FS_MODE_SPEED 40 > > @@ -81,6 +82,7 @@ enum DMA_REGS_OFFSET { > > OFFSET_INT_FLAG = 0x0, > > OFFSET_INT_EN = 0x04, > > OFFSET_EN = 0x08, > > + OFFSET_RST = 0x0c, > > OFFSET_CON = 0x18, > > OFFSET_TX_MEM_ADDR = 0x1c, > > OFFSET_RX_MEM_ADDR = 0x20, > > @@ -262,6 +264,10 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c) > > I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN; > > writew(control_reg, i2c->base + OFFSET_CONTROL); > > writew(I2C_DELAY_LEN, i2c->base + OFFSET_DELAY_LEN); > > + > > + writel(I2C_DMA_HARD_RST, i2c->pdmabase + OFFSET_RST); > > + udelay(50); > > + writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_RST); > > } > > > > /* > > @@ -550,16 +556,20 @@ err_exit: > > static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id) > > { > > struct mtk_i2c *i2c = dev_id; > > - u16 restart_flag = 0; > > + u16 intr_stat = 0; > > > > - if (i2c->dev_comp->auto_restart) > > - restart_flag = I2C_RS_TRANSFER; > > + intr_stat = readw(i2c->base + OFFSET_INTR_STAT); > > + writew(intr_stat, i2c->base + OFFSET_INTR_STAT); > > > > - i2c->irq_stat = readw(i2c->base + OFFSET_INTR_STAT); > > - writew(restart_flag | I2C_HS_NACKERR | I2C_ACKERR > > - | I2C_TRANSAC_COMP, i2c->base + OFFSET_INTR_STAT); > > + /* > > +* when occurs i2c ack error, mtk_i2c_irq is called twice, > > +* first is the ack error interrupt, then the complete interrupt, > > +* i2c->irq_stat need keep the two interrupt value. > > +*/ > > + i2c->irq_stat |= intr_stat; > > > > - complete(>msg_complete); > > + if (i2c->irq_stat & I2C_TRANSAC_COMP) > > + complete(>msg_complete); > > > > return IRQ_HANDLED; > > } > > @@ -729,3 +739,4 @@ module_platform_driver(mtk_i2c_driver); > > MODULE_LICENSE("GPL v2"); > > MODULE_DESCRIPTION("MediaTek I2C Bus Driver"); > > MODULE_AUTHOR("Xudong Chen "); > > +MODULE_AUTHOR("Liguo Zhang "); > > -- > > 1.7.9.5 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: mediatek: fix transfer error handling
On Fri, 2015-07-31 at 13:00 +0200, Wolfram Sang wrote: On Tue, Jul 28, 2015 at 11:38:05AM +0800, Eddie Huang wrote: From: Liguo Zhang liguo.zh...@mediatek.com Reset i2c dma engine in hw init function. When occur i2c ack error, mtk_i2c_irq may is twice, first is the ack error interrupt, then the complete interrupt, so i2c-irq_stat need keep the two interrupt value, and only call complete() for the complete interrupt. Signed-off-by: Liguo Zhang liguo.zh...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com Looks to me this patch needs to be split up into one patch per issue? OK, I can split And doesn't it kill the auto_restart functionality? Sascha? No. restart_flag already set in mtk_i2c_do_transfer() function.It is not necessary check restart_flag again in mtk_i2c_irq(). It is simpler to just read status bit and write back to clear interrupt status. Eddie Thanks --- drivers/i2c/busses/i2c-mt65xx.c | 25 ++--- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index 9920eef..57d11b7 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -59,6 +59,7 @@ #define I2C_DMA_START_EN 0x0001 #define I2C_DMA_INT_FLAG_NONE 0x #define I2C_DMA_CLR_FLAG 0x +#define I2C_DMA_HARD_RST 0x0002 #define I2C_DEFAULT_SPEED 10 /* hz */ #define MAX_FS_MODE_SPEED 40 @@ -81,6 +82,7 @@ enum DMA_REGS_OFFSET { OFFSET_INT_FLAG = 0x0, OFFSET_INT_EN = 0x04, OFFSET_EN = 0x08, + OFFSET_RST = 0x0c, OFFSET_CON = 0x18, OFFSET_TX_MEM_ADDR = 0x1c, OFFSET_RX_MEM_ADDR = 0x20, @@ -262,6 +264,10 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c) I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN; writew(control_reg, i2c-base + OFFSET_CONTROL); writew(I2C_DELAY_LEN, i2c-base + OFFSET_DELAY_LEN); + + writel(I2C_DMA_HARD_RST, i2c-pdmabase + OFFSET_RST); + udelay(50); + writel(I2C_DMA_CLR_FLAG, i2c-pdmabase + OFFSET_RST); } /* @@ -550,16 +556,20 @@ err_exit: static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id) { struct mtk_i2c *i2c = dev_id; - u16 restart_flag = 0; + u16 intr_stat = 0; - if (i2c-dev_comp-auto_restart) - restart_flag = I2C_RS_TRANSFER; + intr_stat = readw(i2c-base + OFFSET_INTR_STAT); + writew(intr_stat, i2c-base + OFFSET_INTR_STAT); - i2c-irq_stat = readw(i2c-base + OFFSET_INTR_STAT); - writew(restart_flag | I2C_HS_NACKERR | I2C_ACKERR - | I2C_TRANSAC_COMP, i2c-base + OFFSET_INTR_STAT); + /* +* when occurs i2c ack error, mtk_i2c_irq is called twice, +* first is the ack error interrupt, then the complete interrupt, +* i2c-irq_stat need keep the two interrupt value. +*/ + i2c-irq_stat |= intr_stat; - complete(i2c-msg_complete); + if (i2c-irq_stat I2C_TRANSAC_COMP) + complete(i2c-msg_complete); return IRQ_HANDLED; } @@ -729,3 +739,4 @@ module_platform_driver(mtk_i2c_driver); MODULE_LICENSE(GPL v2); MODULE_DESCRIPTION(MediaTek I2C Bus Driver); MODULE_AUTHOR(Xudong Chen xudong.c...@mediatek.com); +MODULE_AUTHOR(Liguo Zhang liguo.zh...@mediatek.com); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] i2c: mediatek: Fixup i2c ack error interrupt handling
When occur i2c ack error, mtk_i2c_irq is called twice, first is the ack error interrupt, then the complete interrupt. i2c interrupt handler should keep the two interrupt value, and only call complete() for the complete interrupt. Signed-off-by: Liguo Zhang liguo.zh...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- drivers/i2c/busses/i2c-mt65xx.c | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index 055159d..12ce7f8 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -558,16 +558,20 @@ err_exit: static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id) { struct mtk_i2c *i2c = dev_id; - u16 restart_flag = 0; + u16 intr_stat = 0; - if (i2c-dev_comp-auto_restart) - restart_flag = I2C_RS_TRANSFER; + intr_stat = readw(i2c-base + OFFSET_INTR_STAT); + writew(intr_stat, i2c-base + OFFSET_INTR_STAT); - i2c-irq_stat = readw(i2c-base + OFFSET_INTR_STAT); - writew(restart_flag | I2C_HS_NACKERR | I2C_ACKERR - | I2C_TRANSAC_COMP, i2c-base + OFFSET_INTR_STAT); + /* +* when occurs i2c ack error, mtk_i2c_irq is called twice, +* first is the ack error interrupt, then the complete interrupt, +* i2c-irq_stat need keep the two interrupt value. +*/ + i2c-irq_stat |= intr_stat; - complete(i2c-msg_complete); + if (i2c-irq_stat I2C_TRANSAC_COMP) + complete(i2c-msg_complete); return IRQ_HANDLED; } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Mediatek I2C fixup
This series provide two patches to optimize mediatek i2c driver. The first patch will reset dma hardware in init function to make sure hardware work in good state. The second patch fix i2c interrupt handling for ACK error. All these patches base on v4.2-rc1. Eddie Huang (2): i2c: mediatek: Reset DMA engine in hardware init function i2c: mediatek: Fixup i2c ack error interrupt handling drivers/i2c/busses/i2c-mt65xx.c | 28 1 file changed, 20 insertions(+), 8 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] i2c: mediatek: Reset DMA engine in hardware init function
Reset DMA in hardware init function to avoid unknown hardware state before do any I2C operation. Signed-off-by: Liguo Zhang liguo.zh...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- drivers/i2c/busses/i2c-mt65xx.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index 9920eef..055159d 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -1,6 +1,8 @@ /* * Copyright (c) 2014 MediaTek Inc. - * Author: Xudong Chen xudong.c...@mediatek.com + * Author: + * Xudong Chen xudong.c...@mediatek.com + * Liguo Zhang liguo.zh...@mediatek.com * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -59,6 +61,7 @@ #define I2C_DMA_START_EN 0x0001 #define I2C_DMA_INT_FLAG_NONE 0x #define I2C_DMA_CLR_FLAG 0x +#define I2C_DMA_HARD_RST 0x0002 #define I2C_DEFAULT_SPEED 10 /* hz */ #define MAX_FS_MODE_SPEED 40 @@ -81,6 +84,7 @@ enum DMA_REGS_OFFSET { OFFSET_INT_FLAG = 0x0, OFFSET_INT_EN = 0x04, OFFSET_EN = 0x08, + OFFSET_RST = 0x0c, OFFSET_CON = 0x18, OFFSET_TX_MEM_ADDR = 0x1c, OFFSET_RX_MEM_ADDR = 0x20, @@ -262,6 +266,10 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c) I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN; writew(control_reg, i2c-base + OFFSET_CONTROL); writew(I2C_DELAY_LEN, i2c-base + OFFSET_DELAY_LEN); + + writel(I2C_DMA_HARD_RST, i2c-pdmabase + OFFSET_RST); + udelay(50); + writel(I2C_DMA_CLR_FLAG, i2c-pdmabase + OFFSET_RST); } /* -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: mt6397: implement suspend/resume function in rtc-mt6397 driver
On Thu, 2015-07-30 at 22:53 +0800, Henry Chen wrote: > Implement the suspend/resume function in order to control rtc's irq_wake flag > and handle as wakeup source. > > Signed-off-by: Henry Chen > --- > drivers/rtc/rtc-mt6397.c | 26 ++ > 1 file changed, 26 insertions(+) > > diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c > index c0090b6..9f6c9f8 100644 > --- a/drivers/rtc/rtc-mt6397.c > +++ b/drivers/rtc/rtc-mt6397.c > @@ -373,6 +373,31 @@ static int mtk_rtc_remove(struct platform_device *pdev) > return 0; > } > > +#ifdef CONFIG_PM_SLEEP > +static int mt6397_rtc_suspend(struct device *dev) > +{ > + struct mt6397_rtc *rtc = dev_get_drvdata(dev); > + > + if (device_may_wakeup(dev)) > + enable_irq_wake(rtc->irq); > + > + return 0; > +} > + > +static int mt6397_rtc_resume(struct device *dev) > +{ > + struct mt6397_rtc *rtc = dev_get_drvdata(dev); > + > + if (device_may_wakeup(dev)) > + disable_irq_wake(rtc->irq); > + > + return 0; > +} > +#endif > + > +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,mt6397-rtc", }, > { } > @@ -382,6 +407,7 @@ static struct platform_driver mtk_rtc_driver = { > .driver = { > .name = "mt6397-rtc", > .of_match_table = mt6397_rtc_of_match, > + .pm = _pm_ops, > }, > .probe = mtk_rtc_probe, > .remove = mtk_rtc_remove, It looks good to me. Acked-by: Eddie Huang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: mt6397: implement suspend/resume function in rtc-mt6397 driver
On Thu, 2015-07-30 at 22:53 +0800, Henry Chen wrote: Implement the suspend/resume function in order to control rtc's irq_wake flag and handle as wakeup source. Signed-off-by: Henry Chen henryc.c...@mediatek.com --- drivers/rtc/rtc-mt6397.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c index c0090b6..9f6c9f8 100644 --- a/drivers/rtc/rtc-mt6397.c +++ b/drivers/rtc/rtc-mt6397.c @@ -373,6 +373,31 @@ static int mtk_rtc_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM_SLEEP +static int mt6397_rtc_suspend(struct device *dev) +{ + struct mt6397_rtc *rtc = dev_get_drvdata(dev); + + if (device_may_wakeup(dev)) + enable_irq_wake(rtc-irq); + + return 0; +} + +static int mt6397_rtc_resume(struct device *dev) +{ + struct mt6397_rtc *rtc = dev_get_drvdata(dev); + + if (device_may_wakeup(dev)) + disable_irq_wake(rtc-irq); + + return 0; +} +#endif + +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,mt6397-rtc, }, { } @@ -382,6 +407,7 @@ static struct platform_driver mtk_rtc_driver = { .driver = { .name = mt6397-rtc, .of_match_table = mt6397_rtc_of_match, + .pm = mt6397_pm_ops, }, .probe = mtk_rtc_probe, .remove = mtk_rtc_remove, It looks good to me. Acked-by: Eddie Huang eddie.hu...@mediatek.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: mediatek: fix transfer error handling
From: Liguo Zhang Reset i2c dma engine in hw init function. When occur i2c ack error, mtk_i2c_irq may is twice, first is the ack error interrupt, then the complete interrupt, so i2c->irq_stat need keep the two interrupt value, and only call complete() for the complete interrupt. Signed-off-by: Liguo Zhang Signed-off-by: Eddie Huang --- drivers/i2c/busses/i2c-mt65xx.c | 25 ++--- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index 9920eef..57d11b7 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -59,6 +59,7 @@ #define I2C_DMA_START_EN 0x0001 #define I2C_DMA_INT_FLAG_NONE 0x #define I2C_DMA_CLR_FLAG 0x +#define I2C_DMA_HARD_RST 0x0002 #define I2C_DEFAULT_SPEED 10 /* hz */ #define MAX_FS_MODE_SPEED 40 @@ -81,6 +82,7 @@ enum DMA_REGS_OFFSET { OFFSET_INT_FLAG = 0x0, OFFSET_INT_EN = 0x04, OFFSET_EN = 0x08, + OFFSET_RST = 0x0c, OFFSET_CON = 0x18, OFFSET_TX_MEM_ADDR = 0x1c, OFFSET_RX_MEM_ADDR = 0x20, @@ -262,6 +264,10 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c) I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN; writew(control_reg, i2c->base + OFFSET_CONTROL); writew(I2C_DELAY_LEN, i2c->base + OFFSET_DELAY_LEN); + + writel(I2C_DMA_HARD_RST, i2c->pdmabase + OFFSET_RST); + udelay(50); + writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_RST); } /* @@ -550,16 +556,20 @@ err_exit: static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id) { struct mtk_i2c *i2c = dev_id; - u16 restart_flag = 0; + u16 intr_stat = 0; - if (i2c->dev_comp->auto_restart) - restart_flag = I2C_RS_TRANSFER; + intr_stat = readw(i2c->base + OFFSET_INTR_STAT); + writew(intr_stat, i2c->base + OFFSET_INTR_STAT); - i2c->irq_stat = readw(i2c->base + OFFSET_INTR_STAT); - writew(restart_flag | I2C_HS_NACKERR | I2C_ACKERR - | I2C_TRANSAC_COMP, i2c->base + OFFSET_INTR_STAT); + /* +* when occurs i2c ack error, mtk_i2c_irq is called twice, +* first is the ack error interrupt, then the complete interrupt, +* i2c->irq_stat need keep the two interrupt value. +*/ + i2c->irq_stat |= intr_stat; - complete(>msg_complete); + if (i2c->irq_stat & I2C_TRANSAC_COMP) + complete(>msg_complete); return IRQ_HANDLED; } @@ -729,3 +739,4 @@ module_platform_driver(mtk_i2c_driver); MODULE_LICENSE("GPL v2"); MODULE_DESCRIPTION("MediaTek I2C Bus Driver"); MODULE_AUTHOR("Xudong Chen "); +MODULE_AUTHOR("Liguo Zhang "); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: mediatek: fix transfer error handling
From: Liguo Zhang liguo.zh...@mediatek.com Reset i2c dma engine in hw init function. When occur i2c ack error, mtk_i2c_irq may is twice, first is the ack error interrupt, then the complete interrupt, so i2c-irq_stat need keep the two interrupt value, and only call complete() for the complete interrupt. Signed-off-by: Liguo Zhang liguo.zh...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- drivers/i2c/busses/i2c-mt65xx.c | 25 ++--- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index 9920eef..57d11b7 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -59,6 +59,7 @@ #define I2C_DMA_START_EN 0x0001 #define I2C_DMA_INT_FLAG_NONE 0x #define I2C_DMA_CLR_FLAG 0x +#define I2C_DMA_HARD_RST 0x0002 #define I2C_DEFAULT_SPEED 10 /* hz */ #define MAX_FS_MODE_SPEED 40 @@ -81,6 +82,7 @@ enum DMA_REGS_OFFSET { OFFSET_INT_FLAG = 0x0, OFFSET_INT_EN = 0x04, OFFSET_EN = 0x08, + OFFSET_RST = 0x0c, OFFSET_CON = 0x18, OFFSET_TX_MEM_ADDR = 0x1c, OFFSET_RX_MEM_ADDR = 0x20, @@ -262,6 +264,10 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c) I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN; writew(control_reg, i2c-base + OFFSET_CONTROL); writew(I2C_DELAY_LEN, i2c-base + OFFSET_DELAY_LEN); + + writel(I2C_DMA_HARD_RST, i2c-pdmabase + OFFSET_RST); + udelay(50); + writel(I2C_DMA_CLR_FLAG, i2c-pdmabase + OFFSET_RST); } /* @@ -550,16 +556,20 @@ err_exit: static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id) { struct mtk_i2c *i2c = dev_id; - u16 restart_flag = 0; + u16 intr_stat = 0; - if (i2c-dev_comp-auto_restart) - restart_flag = I2C_RS_TRANSFER; + intr_stat = readw(i2c-base + OFFSET_INTR_STAT); + writew(intr_stat, i2c-base + OFFSET_INTR_STAT); - i2c-irq_stat = readw(i2c-base + OFFSET_INTR_STAT); - writew(restart_flag | I2C_HS_NACKERR | I2C_ACKERR - | I2C_TRANSAC_COMP, i2c-base + OFFSET_INTR_STAT); + /* +* when occurs i2c ack error, mtk_i2c_irq is called twice, +* first is the ack error interrupt, then the complete interrupt, +* i2c-irq_stat need keep the two interrupt value. +*/ + i2c-irq_stat |= intr_stat; - complete(i2c-msg_complete); + if (i2c-irq_stat I2C_TRANSAC_COMP) + complete(i2c-msg_complete); return IRQ_HANDLED; } @@ -729,3 +739,4 @@ module_platform_driver(mtk_i2c_driver); MODULE_LICENSE(GPL v2); MODULE_DESCRIPTION(MediaTek I2C Bus Driver); MODULE_AUTHOR(Xudong Chen xudong.c...@mediatek.com); +MODULE_AUTHOR(Liguo Zhang liguo.zh...@mediatek.com); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] watchdog: mtk_wdt: add wdt shutdown callback to disable wdt if enabled
From: Greta Zhang Without .shutdown(), watchdog might reset the system during power off. For example, if watchdog's timeout is set to 30s, then it is reset to zero by mtk_wdt_ping(). During power off, no app will ping watchdog, but watchdog is still running and may trigger reset. Signed-off-by: Greta Zhang Signed-off-by: Eddie Huang Acked-by: Matthias Brugger Reviewed-by: Guenter Roeck --- drivers/watchdog/mtk_wdt.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 056412c..6ad9df9 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -210,6 +210,14 @@ static int mtk_wdt_probe(struct platform_device *pdev) return 0; } +static void mtk_wdt_shutdown(struct platform_device *pdev) +{ + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); + + if (watchdog_active(_wdt->wdt_dev)) + mtk_wdt_stop(_wdt->wdt_dev); +} + static int mtk_wdt_remove(struct platform_device *pdev) { struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); @@ -259,6 +267,7 @@ static const struct dev_pm_ops mtk_wdt_pm_ops = { static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, + .shutdown = mtk_wdt_shutdown, .driver = { .name = DRV_NAME, .pm = _wdt_pm_ops, -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] watchdog: mtk_wdt: add suspend/resume support
From: Greta Zhang add mediatek watchdog driver suspend/resume support Signed-off-by: Greta Zhang Signed-off-by: Roger Lu Signed-off-by: Eddie Huang Acked-by: Matthias Brugger Reviewed-by: Guenter Roeck --- drivers/watchdog/mtk_wdt.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 938b987..056412c 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -221,17 +221,47 @@ static int mtk_wdt_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM_SLEEP +static int mtk_wdt_suspend(struct device *dev) +{ + struct mtk_wdt_dev *mtk_wdt = dev_get_drvdata(dev); + + if (watchdog_active(_wdt->wdt_dev)) + mtk_wdt_stop(_wdt->wdt_dev); + + return 0; +} + +static int mtk_wdt_resume(struct device *dev) +{ + struct mtk_wdt_dev *mtk_wdt = dev_get_drvdata(dev); + + if (watchdog_active(_wdt->wdt_dev)) { + mtk_wdt_start(_wdt->wdt_dev); + mtk_wdt_ping(_wdt->wdt_dev); + } + + return 0; +} +#endif + static const struct of_device_id mtk_wdt_dt_ids[] = { { .compatible = "mediatek,mt6589-wdt" }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids); +static const struct dev_pm_ops mtk_wdt_pm_ops = { + SET_SYSTEM_SLEEP_PM_OPS(mtk_wdt_suspend, + mtk_wdt_resume) +}; + static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, .driver = { .name = DRV_NAME, + .pm = _wdt_pm_ops, .of_match_table = mtk_wdt_dt_ids, }, }; -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/2] Add Mediatek watchdog suspend resume and shutdown
This series add Mediatek watchdog suspend, resume and shutdown support. These patches are based on v4.2-rc1 Change in v3: Add mtk_wdt in subject line Change in v2: Use watchdog_active() to check whether watchdog been active. Change to register suspend,resume function to dev_pm_ops -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/2] Add Mediatek watchdog suspend resume and shutdown
This series add Mediatek watchdog suspend, resume and shutdown support. These patches are based on v4.2-rc1 Change in v3: Add mtk_wdt in subject line Change in v2: Use watchdog_active() to check whether watchdog been active. Change to register suspend,resume function to dev_pm_ops -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] watchdog: mtk_wdt: add wdt shutdown callback to disable wdt if enabled
From: Greta Zhang greta.zh...@mediatek.com Without .shutdown(), watchdog might reset the system during power off. For example, if watchdog's timeout is set to 30s, then it is reset to zero by mtk_wdt_ping(). During power off, no app will ping watchdog, but watchdog is still running and may trigger reset. Signed-off-by: Greta Zhang greta.zh...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com Acked-by: Matthias Brugger matthias@gmail.com Reviewed-by: Guenter Roeck li...@roeck-us.net --- drivers/watchdog/mtk_wdt.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 056412c..6ad9df9 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -210,6 +210,14 @@ static int mtk_wdt_probe(struct platform_device *pdev) return 0; } +static void mtk_wdt_shutdown(struct platform_device *pdev) +{ + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); + + if (watchdog_active(mtk_wdt-wdt_dev)) + mtk_wdt_stop(mtk_wdt-wdt_dev); +} + static int mtk_wdt_remove(struct platform_device *pdev) { struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); @@ -259,6 +267,7 @@ static const struct dev_pm_ops mtk_wdt_pm_ops = { static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, + .shutdown = mtk_wdt_shutdown, .driver = { .name = DRV_NAME, .pm = mtk_wdt_pm_ops, -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] watchdog: mtk_wdt: add suspend/resume support
From: Greta Zhang greta.zh...@mediatek.com add mediatek watchdog driver suspend/resume support Signed-off-by: Greta Zhang greta.zh...@mediatek.com Signed-off-by: Roger Lu roger...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com Acked-by: Matthias Brugger matthias@gmail.com Reviewed-by: Guenter Roeck li...@roeck-us.net --- drivers/watchdog/mtk_wdt.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 938b987..056412c 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -221,17 +221,47 @@ static int mtk_wdt_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM_SLEEP +static int mtk_wdt_suspend(struct device *dev) +{ + struct mtk_wdt_dev *mtk_wdt = dev_get_drvdata(dev); + + if (watchdog_active(mtk_wdt-wdt_dev)) + mtk_wdt_stop(mtk_wdt-wdt_dev); + + return 0; +} + +static int mtk_wdt_resume(struct device *dev) +{ + struct mtk_wdt_dev *mtk_wdt = dev_get_drvdata(dev); + + if (watchdog_active(mtk_wdt-wdt_dev)) { + mtk_wdt_start(mtk_wdt-wdt_dev); + mtk_wdt_ping(mtk_wdt-wdt_dev); + } + + return 0; +} +#endif + static const struct of_device_id mtk_wdt_dt_ids[] = { { .compatible = mediatek,mt6589-wdt }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids); +static const struct dev_pm_ops mtk_wdt_pm_ops = { + SET_SYSTEM_SLEEP_PM_OPS(mtk_wdt_suspend, + mtk_wdt_resume) +}; + static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, .driver = { .name = DRV_NAME, + .pm = mtk_wdt_pm_ops, .of_match_table = mtk_wdt_dt_ids, }, }; -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] soc: mediatek: add scpsys support active_wakeup
Register gpd_dev_ops.active_wakeup function to support keep power during suspend state. And add flag to each power domain to decide whether keep power during suspend or not. Signed-off-by: Chunfeng Yun Signed-off-by: Eddie Huang --- drivers/soc/mediatek/mtk-scpsys.c | 28 1 file changed, 28 insertions(+) diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c index 43a79ed..fc78b70 100644 --- a/drivers/soc/mediatek/mtk-scpsys.c +++ b/drivers/soc/mediatek/mtk-scpsys.c @@ -67,6 +67,7 @@ struct scp_domain_data { u32 sram_pdn_ack_bits; u32 bus_prot_mask; enum clk_id clk_id; + bool active_wakeup; }; static const struct scp_domain_data scp_domain_data[] __initconst = { @@ -77,6 +78,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(12, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_VENC] = { .name = "venc", @@ -85,6 +87,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_ISP] = { .name = "isp", @@ -93,6 +96,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(13, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_MM] = { .name = "mm", @@ -101,6 +105,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(12, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 | MT8173_TOP_AXI_PROT_EN_MM_M1, }, @@ -111,6 +116,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_AUDIO] = { .name = "audio", @@ -119,6 +125,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_USB] = { .name = "usb", @@ -127,6 +134,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = true, }, [MT8173_POWER_DOMAIN_MFG_ASYNC] = { .name = "mfg_async", @@ -135,6 +143,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = 0, .clk_id = MT8173_CLK_MFG, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_MFG_2D] = { .name = "mfg_2d", @@ -143,6 +152,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(13, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_MFG] = { .name = "mfg", @@ -151,6 +161,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(13, 8), .sram_pdn_ack_bits = GENMASK(21, 16), .clk_id = MT8173_CLK_NONE, + .active_wakeup = false, .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S | MT8173_TOP_AXI_PROT_EN_MFG_M0 | MT8173_TOP_AXI_PROT_EN_MFG_M1 | @@ -171,6 +182,7 @@ struct scp_domain { u32 sram_pdn_bits; u32 sram_pdn_ack_bits; u32 bus_prot_mask; + bool active_wakeup; }; struct scp { @@ -370,6 +382,20 @@ out: return ret; } +static bool scpsys_active_wakeup(struct device *dev) +{ + struct generic_pm_domain *genpd; + struct scp_domain *scpd; + + if (IS_ERR_OR_NULL(dev->pm_domain)) + return false; + +
[PATCH] soc: mediatek: add scpsys support active_wakeup
Register gpd_dev_ops.active_wakeup function to support keep power during suspend state. And add flag to each power domain to decide whether keep power during suspend or not. Signed-off-by: Chunfeng Yun chunfeng@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- drivers/soc/mediatek/mtk-scpsys.c | 28 1 file changed, 28 insertions(+) diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c index 43a79ed..fc78b70 100644 --- a/drivers/soc/mediatek/mtk-scpsys.c +++ b/drivers/soc/mediatek/mtk-scpsys.c @@ -67,6 +67,7 @@ struct scp_domain_data { u32 sram_pdn_ack_bits; u32 bus_prot_mask; enum clk_id clk_id; + bool active_wakeup; }; static const struct scp_domain_data scp_domain_data[] __initconst = { @@ -77,6 +78,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(12, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_VENC] = { .name = venc, @@ -85,6 +87,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_ISP] = { .name = isp, @@ -93,6 +96,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(13, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_MM] = { .name = mm, @@ -101,6 +105,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(12, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 | MT8173_TOP_AXI_PROT_EN_MM_M1, }, @@ -111,6 +116,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_MM, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_AUDIO] = { .name = audio, @@ -119,6 +125,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_USB] = { .name = usb, @@ -127,6 +134,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = true, }, [MT8173_POWER_DOMAIN_MFG_ASYNC] = { .name = mfg_async, @@ -135,6 +143,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = 0, .clk_id = MT8173_CLK_MFG, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_MFG_2D] = { .name = mfg_2d, @@ -143,6 +152,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(13, 12), .clk_id = MT8173_CLK_NONE, + .active_wakeup = false, }, [MT8173_POWER_DOMAIN_MFG] = { .name = mfg, @@ -151,6 +161,7 @@ static const struct scp_domain_data scp_domain_data[] __initconst = { .sram_pdn_bits = GENMASK(13, 8), .sram_pdn_ack_bits = GENMASK(21, 16), .clk_id = MT8173_CLK_NONE, + .active_wakeup = false, .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S | MT8173_TOP_AXI_PROT_EN_MFG_M0 | MT8173_TOP_AXI_PROT_EN_MFG_M1 | @@ -171,6 +182,7 @@ struct scp_domain { u32 sram_pdn_bits; u32 sram_pdn_ack_bits; u32 bus_prot_mask; + bool active_wakeup; }; struct scp { @@ -370,6 +382,20 @@ out: return ret; } +static bool scpsys_active_wakeup(struct device *dev) +{ + struct generic_pm_domain *genpd; + struct scp_domain *scpd; + + if (IS_ERR_OR_NULL(dev-pm_domain)) + return false; + + genpd = pd_to_genpd(dev-pm_domain); + scpd
[PATCH v2 0/2] Add Mediatek watchdog suspend resume and shutdown
This series add Mediatek watchdog suspend, resume and shutdown support. These patches are based on v4.2-rc1 Change in v2: Use watchdog_active() to check whether watchdog been active. Change to register suspend,resume function to dev_pm_ops Greta Zhang (2): watchdog: add wdt suspend/resume support watchdog: add wdt shutdown callback to disable wdt if enabled drivers/watchdog/mtk_wdt.c | 39 +++ 1 file changed, 39 insertions(+) -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] watchdog: add wdt shutdown callback to disable wdt if enabled
From: Greta Zhang Without .shutdown(), watchdog might reset the system during power off. For example, if watchdog's timeout is set to 30s, then it is reset to zero by mtk_wdt_ping(). During power off, no app will ping watchdog, but watchdog is still running and may trigger reset. Signed-off-by: Greta Zhang Signed-off-by: Eddie Huang --- drivers/watchdog/mtk_wdt.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 056412c..6ad9df9 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -210,6 +210,14 @@ static int mtk_wdt_probe(struct platform_device *pdev) return 0; } +static void mtk_wdt_shutdown(struct platform_device *pdev) +{ + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); + + if (watchdog_active(_wdt->wdt_dev)) + mtk_wdt_stop(_wdt->wdt_dev); +} + static int mtk_wdt_remove(struct platform_device *pdev) { struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); @@ -259,6 +267,7 @@ static const struct dev_pm_ops mtk_wdt_pm_ops = { static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, + .shutdown = mtk_wdt_shutdown, .driver = { .name = DRV_NAME, .pm = _wdt_pm_ops, -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] watchdog: add wdt suspend/resume support
From: Greta Zhang add wdt driver suspend/resume support Signed-off-by: Greta Zhang Signed-off-by: Roger Lu Signed-off-by: Eddie Huang --- drivers/watchdog/mtk_wdt.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 938b987..056412c 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -221,17 +221,47 @@ static int mtk_wdt_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM_SLEEP +static int mtk_wdt_suspend(struct device *dev) +{ + struct mtk_wdt_dev *mtk_wdt = dev_get_drvdata(dev); + + if (watchdog_active(_wdt->wdt_dev)) + mtk_wdt_stop(_wdt->wdt_dev); + + return 0; +} + +static int mtk_wdt_resume(struct device *dev) +{ + struct mtk_wdt_dev *mtk_wdt = dev_get_drvdata(dev); + + if (watchdog_active(_wdt->wdt_dev)) { + mtk_wdt_start(_wdt->wdt_dev); + mtk_wdt_ping(_wdt->wdt_dev); + } + + return 0; +} +#endif + static const struct of_device_id mtk_wdt_dt_ids[] = { { .compatible = "mediatek,mt6589-wdt" }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids); +static const struct dev_pm_ops mtk_wdt_pm_ops = { + SET_SYSTEM_SLEEP_PM_OPS(mtk_wdt_suspend, + mtk_wdt_resume) +}; + static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, .driver = { .name = DRV_NAME, + .pm = _wdt_pm_ops, .of_match_table = mtk_wdt_dt_ids, }, }; -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] watchdog: add wdt suspend/resume support
On Tue, 2015-07-21 at 20:45 -0700, Guenter Roeck wrote: > On 07/21/2015 08:26 PM, Eddie Huang wrote: > > From: Greta Zhang > > > > add wdt driver suspend/resume support > > > > Signed-off-by: Greta Zhang > > Signed-off-by: Roger Lu > > Signed-off-by: Eddie Huang > > --- > > drivers/watchdog/mtk_wdt.c | 38 ++ > > 1 file changed, 38 insertions(+) > > > > diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c > > index 938b987..5ef3910 100644 > > --- a/drivers/watchdog/mtk_wdt.c > > +++ b/drivers/watchdog/mtk_wdt.c > > @@ -65,6 +65,7 @@ struct mtk_wdt_dev { > > struct watchdog_device wdt_dev; > > void __iomem *wdt_base; > > struct notifier_block restart_handler; > > + bool started; > > Any reason why you can not use watchdog_active() ? Will change to use watchdog_active() > > > }; > > > > static int mtk_reset_handler(struct notifier_block *this, unsigned long > > mode, > > @@ -125,6 +126,8 @@ static int mtk_wdt_stop(struct watchdog_device *wdt_dev) > > reg &= ~WDT_MODE_EN; > > iowrite32(reg, wdt_base + WDT_MODE); > > > > + mtk_wdt->started = false; > > + > > return 0; > > } > > > > @@ -135,6 +138,8 @@ static int mtk_wdt_start(struct watchdog_device > > *wdt_dev) > > void __iomem *wdt_base = mtk_wdt->wdt_base; > > int ret; > > > > + mtk_wdt->started = true; > > + > > ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout); > > if (ret < 0) > > return ret; > > @@ -174,6 +179,8 @@ static int mtk_wdt_probe(struct platform_device *pdev) > > > > platform_set_drvdata(pdev, mtk_wdt); > > > > + mtk_wdt->started = false; > > + > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > mtk_wdt->wdt_base = devm_ioremap_resource(>dev, res); > > if (IS_ERR(mtk_wdt->wdt_base)) > > @@ -221,6 +228,35 @@ static int mtk_wdt_remove(struct platform_device *pdev) > > return 0; > > } > > > > +#ifdef CONFIG_PM > > +static int mtk_wdt_suspend(struct platform_device *pdev, pm_message_t > > state) > > +{ > > + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); > > + > > + if (mtk_wdt->started) { > > + mtk_wdt_stop(_wdt->wdt_dev); > > + mtk_wdt->started = true; > > ? > Because mtk_wdt_stop() change mtk_wdt->started to false, so set mtk_wdt->started back to true here. This code is not necessary if use watchdog_active() > > + } > > + > > + return 0; > > +} > > + > > +static int mtk_wdt_resume(struct platform_device *pdev) > > +{ > > + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); > > + > > + if (mtk_wdt->started) { > > + mtk_wdt_start(_wdt->wdt_dev); > > + mtk_wdt_ping(_wdt->wdt_dev); > > + } > > + > > + return 0; > > +} > > +#else > > +#definemtk_wdt_suspend NULL > > +#definemtk_wdt_resume NULL > > +#endif > > + > > static const struct of_device_id mtk_wdt_dt_ids[] = { > > { .compatible = "mediatek,mt6589-wdt" }, > > { /* sentinel */ } > > @@ -230,6 +266,8 @@ MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids); > > static struct platform_driver mtk_wdt_driver = { > > .probe = mtk_wdt_probe, > > .remove = mtk_wdt_remove, > > + .suspend= mtk_wdt_suspend, > > + .resume = mtk_wdt_resume, > > .driver = { > > .name = DRV_NAME, > > .of_match_table = mtk_wdt_dt_ids, > > Typically drivers would use struct dev_pm_ops and > .pm = _wdt_pm_ops, > > Any reason for not using the same mechanism ? > Will change to use dev_pm_ops Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] watchdog: add wdt suspend/resume support
On Tue, 2015-07-21 at 20:45 -0700, Guenter Roeck wrote: On 07/21/2015 08:26 PM, Eddie Huang wrote: From: Greta Zhang greta.zh...@mediatek.com add wdt driver suspend/resume support Signed-off-by: Greta Zhang greta.zh...@mediatek.com Signed-off-by: Roger Lu roger...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- drivers/watchdog/mtk_wdt.c | 38 ++ 1 file changed, 38 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 938b987..5ef3910 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -65,6 +65,7 @@ struct mtk_wdt_dev { struct watchdog_device wdt_dev; void __iomem *wdt_base; struct notifier_block restart_handler; + bool started; Any reason why you can not use watchdog_active() ? Will change to use watchdog_active() }; static int mtk_reset_handler(struct notifier_block *this, unsigned long mode, @@ -125,6 +126,8 @@ static int mtk_wdt_stop(struct watchdog_device *wdt_dev) reg = ~WDT_MODE_EN; iowrite32(reg, wdt_base + WDT_MODE); + mtk_wdt-started = false; + return 0; } @@ -135,6 +138,8 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev) void __iomem *wdt_base = mtk_wdt-wdt_base; int ret; + mtk_wdt-started = true; + ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev-timeout); if (ret 0) return ret; @@ -174,6 +179,8 @@ static int mtk_wdt_probe(struct platform_device *pdev) platform_set_drvdata(pdev, mtk_wdt); + mtk_wdt-started = false; + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); mtk_wdt-wdt_base = devm_ioremap_resource(pdev-dev, res); if (IS_ERR(mtk_wdt-wdt_base)) @@ -221,6 +228,35 @@ static int mtk_wdt_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM +static int mtk_wdt_suspend(struct platform_device *pdev, pm_message_t state) +{ + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); + + if (mtk_wdt-started) { + mtk_wdt_stop(mtk_wdt-wdt_dev); + mtk_wdt-started = true; ? Because mtk_wdt_stop() change mtk_wdt-started to false, so set mtk_wdt-started back to true here. This code is not necessary if use watchdog_active() + } + + return 0; +} + +static int mtk_wdt_resume(struct platform_device *pdev) +{ + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); + + if (mtk_wdt-started) { + mtk_wdt_start(mtk_wdt-wdt_dev); + mtk_wdt_ping(mtk_wdt-wdt_dev); + } + + return 0; +} +#else +#definemtk_wdt_suspend NULL +#definemtk_wdt_resume NULL +#endif + static const struct of_device_id mtk_wdt_dt_ids[] = { { .compatible = mediatek,mt6589-wdt }, { /* sentinel */ } @@ -230,6 +266,8 @@ MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids); static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, + .suspend= mtk_wdt_suspend, + .resume = mtk_wdt_resume, .driver = { .name = DRV_NAME, .of_match_table = mtk_wdt_dt_ids, Typically drivers would use struct dev_pm_ops and .pm = mtk_wdt_pm_ops, Any reason for not using the same mechanism ? Will change to use dev_pm_ops Eddie Thanks -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] watchdog: add wdt suspend/resume support
From: Greta Zhang greta.zh...@mediatek.com add wdt driver suspend/resume support Signed-off-by: Greta Zhang greta.zh...@mediatek.com Signed-off-by: Roger Lu roger...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- drivers/watchdog/mtk_wdt.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 938b987..056412c 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -221,17 +221,47 @@ static int mtk_wdt_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM_SLEEP +static int mtk_wdt_suspend(struct device *dev) +{ + struct mtk_wdt_dev *mtk_wdt = dev_get_drvdata(dev); + + if (watchdog_active(mtk_wdt-wdt_dev)) + mtk_wdt_stop(mtk_wdt-wdt_dev); + + return 0; +} + +static int mtk_wdt_resume(struct device *dev) +{ + struct mtk_wdt_dev *mtk_wdt = dev_get_drvdata(dev); + + if (watchdog_active(mtk_wdt-wdt_dev)) { + mtk_wdt_start(mtk_wdt-wdt_dev); + mtk_wdt_ping(mtk_wdt-wdt_dev); + } + + return 0; +} +#endif + static const struct of_device_id mtk_wdt_dt_ids[] = { { .compatible = mediatek,mt6589-wdt }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids); +static const struct dev_pm_ops mtk_wdt_pm_ops = { + SET_SYSTEM_SLEEP_PM_OPS(mtk_wdt_suspend, + mtk_wdt_resume) +}; + static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, .driver = { .name = DRV_NAME, + .pm = mtk_wdt_pm_ops, .of_match_table = mtk_wdt_dt_ids, }, }; -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] Add Mediatek watchdog suspend resume and shutdown
This series add Mediatek watchdog suspend, resume and shutdown support. These patches are based on v4.2-rc1 Change in v2: Use watchdog_active() to check whether watchdog been active. Change to register suspend,resume function to dev_pm_ops Greta Zhang (2): watchdog: add wdt suspend/resume support watchdog: add wdt shutdown callback to disable wdt if enabled drivers/watchdog/mtk_wdt.c | 39 +++ 1 file changed, 39 insertions(+) -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] watchdog: add wdt shutdown callback to disable wdt if enabled
From: Greta Zhang greta.zh...@mediatek.com Without .shutdown(), watchdog might reset the system during power off. For example, if watchdog's timeout is set to 30s, then it is reset to zero by mtk_wdt_ping(). During power off, no app will ping watchdog, but watchdog is still running and may trigger reset. Signed-off-by: Greta Zhang greta.zh...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- drivers/watchdog/mtk_wdt.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 056412c..6ad9df9 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -210,6 +210,14 @@ static int mtk_wdt_probe(struct platform_device *pdev) return 0; } +static void mtk_wdt_shutdown(struct platform_device *pdev) +{ + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); + + if (watchdog_active(mtk_wdt-wdt_dev)) + mtk_wdt_stop(mtk_wdt-wdt_dev); +} + static int mtk_wdt_remove(struct platform_device *pdev) { struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); @@ -259,6 +267,7 @@ static const struct dev_pm_ops mtk_wdt_pm_ops = { static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, + .shutdown = mtk_wdt_shutdown, .driver = { .name = DRV_NAME, .pm = mtk_wdt_pm_ops, -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] watchdog: add wdt suspend/resume support
From: Greta Zhang add wdt driver suspend/resume support Signed-off-by: Greta Zhang Signed-off-by: Roger Lu Signed-off-by: Eddie Huang --- drivers/watchdog/mtk_wdt.c | 38 ++ 1 file changed, 38 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 938b987..5ef3910 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -65,6 +65,7 @@ struct mtk_wdt_dev { struct watchdog_device wdt_dev; void __iomem *wdt_base; struct notifier_block restart_handler; + bool started; }; static int mtk_reset_handler(struct notifier_block *this, unsigned long mode, @@ -125,6 +126,8 @@ static int mtk_wdt_stop(struct watchdog_device *wdt_dev) reg &= ~WDT_MODE_EN; iowrite32(reg, wdt_base + WDT_MODE); + mtk_wdt->started = false; + return 0; } @@ -135,6 +138,8 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev) void __iomem *wdt_base = mtk_wdt->wdt_base; int ret; + mtk_wdt->started = true; + ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout); if (ret < 0) return ret; @@ -174,6 +179,8 @@ static int mtk_wdt_probe(struct platform_device *pdev) platform_set_drvdata(pdev, mtk_wdt); + mtk_wdt->started = false; + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); mtk_wdt->wdt_base = devm_ioremap_resource(>dev, res); if (IS_ERR(mtk_wdt->wdt_base)) @@ -221,6 +228,35 @@ static int mtk_wdt_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM +static int mtk_wdt_suspend(struct platform_device *pdev, pm_message_t state) +{ + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); + + if (mtk_wdt->started) { + mtk_wdt_stop(_wdt->wdt_dev); + mtk_wdt->started = true; + } + + return 0; +} + +static int mtk_wdt_resume(struct platform_device *pdev) +{ + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); + + if (mtk_wdt->started) { + mtk_wdt_start(_wdt->wdt_dev); + mtk_wdt_ping(_wdt->wdt_dev); + } + + return 0; +} +#else +#definemtk_wdt_suspend NULL +#definemtk_wdt_resume NULL +#endif + static const struct of_device_id mtk_wdt_dt_ids[] = { { .compatible = "mediatek,mt6589-wdt" }, { /* sentinel */ } @@ -230,6 +266,8 @@ MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids); static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, + .suspend= mtk_wdt_suspend, + .resume = mtk_wdt_resume, .driver = { .name = DRV_NAME, .of_match_table = mtk_wdt_dt_ids, -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] watchdog: add wdt shutdown callback to disable wdt if enabled
From: Greta Zhang Without .shutdown(), watchdog might reset the system during power off. For example, if watchdog's timeout is set to 30s, then it is reset to zero by mtk_wdt_ping(). During power off, no app will ping watchdog, but watchdog is still running and may trigger reset. Signed-off-by: Greta Zhang Signed-off-by: Eddie Huang --- drivers/watchdog/mtk_wdt.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 5ef3910..c6741a5 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -217,6 +217,14 @@ static int mtk_wdt_probe(struct platform_device *pdev) return 0; } +static void mtk_wdt_shutdown(struct platform_device *pdev) +{ + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); + + if (mtk_wdt->started) + mtk_wdt_stop(_wdt->wdt_dev); +} + static int mtk_wdt_remove(struct platform_device *pdev) { struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); @@ -266,6 +274,7 @@ MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids); static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, + .shutdown = mtk_wdt_shutdown, .suspend= mtk_wdt_suspend, .resume = mtk_wdt_resume, .driver = { -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Add Mediatek watchdog suspend resume and shutdown
This series add Mediatek watchdog suspend, resume and shutdown support. These patches are based on v4.2-rc1 Greta Zhang (2): watchdog: add wdt suspend/resume support watchdog: add wdt shutdown callback to disable wdt if enabled drivers/watchdog/mtk_wdt.c | 47 ++ 1 file changed, 47 insertions(+) -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Add Mediatek watchdog suspend resume and shutdown
This series add Mediatek watchdog suspend, resume and shutdown support. These patches are based on v4.2-rc1 Greta Zhang (2): watchdog: add wdt suspend/resume support watchdog: add wdt shutdown callback to disable wdt if enabled drivers/watchdog/mtk_wdt.c | 47 ++ 1 file changed, 47 insertions(+) -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] watchdog: add wdt shutdown callback to disable wdt if enabled
From: Greta Zhang greta.zh...@mediatek.com Without .shutdown(), watchdog might reset the system during power off. For example, if watchdog's timeout is set to 30s, then it is reset to zero by mtk_wdt_ping(). During power off, no app will ping watchdog, but watchdog is still running and may trigger reset. Signed-off-by: Greta Zhang greta.zh...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- drivers/watchdog/mtk_wdt.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 5ef3910..c6741a5 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -217,6 +217,14 @@ static int mtk_wdt_probe(struct platform_device *pdev) return 0; } +static void mtk_wdt_shutdown(struct platform_device *pdev) +{ + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); + + if (mtk_wdt-started) + mtk_wdt_stop(mtk_wdt-wdt_dev); +} + static int mtk_wdt_remove(struct platform_device *pdev) { struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); @@ -266,6 +274,7 @@ MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids); static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, + .shutdown = mtk_wdt_shutdown, .suspend= mtk_wdt_suspend, .resume = mtk_wdt_resume, .driver = { -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] watchdog: add wdt suspend/resume support
From: Greta Zhang greta.zh...@mediatek.com add wdt driver suspend/resume support Signed-off-by: Greta Zhang greta.zh...@mediatek.com Signed-off-by: Roger Lu roger...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- drivers/watchdog/mtk_wdt.c | 38 ++ 1 file changed, 38 insertions(+) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 938b987..5ef3910 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -65,6 +65,7 @@ struct mtk_wdt_dev { struct watchdog_device wdt_dev; void __iomem *wdt_base; struct notifier_block restart_handler; + bool started; }; static int mtk_reset_handler(struct notifier_block *this, unsigned long mode, @@ -125,6 +126,8 @@ static int mtk_wdt_stop(struct watchdog_device *wdt_dev) reg = ~WDT_MODE_EN; iowrite32(reg, wdt_base + WDT_MODE); + mtk_wdt-started = false; + return 0; } @@ -135,6 +138,8 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev) void __iomem *wdt_base = mtk_wdt-wdt_base; int ret; + mtk_wdt-started = true; + ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev-timeout); if (ret 0) return ret; @@ -174,6 +179,8 @@ static int mtk_wdt_probe(struct platform_device *pdev) platform_set_drvdata(pdev, mtk_wdt); + mtk_wdt-started = false; + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); mtk_wdt-wdt_base = devm_ioremap_resource(pdev-dev, res); if (IS_ERR(mtk_wdt-wdt_base)) @@ -221,6 +228,35 @@ static int mtk_wdt_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM +static int mtk_wdt_suspend(struct platform_device *pdev, pm_message_t state) +{ + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); + + if (mtk_wdt-started) { + mtk_wdt_stop(mtk_wdt-wdt_dev); + mtk_wdt-started = true; + } + + return 0; +} + +static int mtk_wdt_resume(struct platform_device *pdev) +{ + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev); + + if (mtk_wdt-started) { + mtk_wdt_start(mtk_wdt-wdt_dev); + mtk_wdt_ping(mtk_wdt-wdt_dev); + } + + return 0; +} +#else +#definemtk_wdt_suspend NULL +#definemtk_wdt_resume NULL +#endif + static const struct of_device_id mtk_wdt_dt_ids[] = { { .compatible = mediatek,mt6589-wdt }, { /* sentinel */ } @@ -230,6 +266,8 @@ MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids); static struct platform_driver mtk_wdt_driver = { .probe = mtk_wdt_probe, .remove = mtk_wdt_remove, + .suspend= mtk_wdt_suspend, + .resume = mtk_wdt_resume, .driver = { .name = DRV_NAME, .of_match_table = mtk_wdt_dt_ids, -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Fri, 2015-07-10 at 16:11 +0800, Daniel Kurtz wrote: > On Fri, Jul 10, 2015 at 3:27 PM, Eddie Huang wrote: > > Hi all, > > > > On Wed, 2015-07-08 at 13:44 +0800, Sascha Hauer wrote: > >> On Wed, Jul 08, 2015 at 10:37:21AM +0800, Eddie Huang wrote: > >> > On Tue, 2015-07-07 at 23:10 +0800, Daniel Kurtz wrote: > >> > > On Tue, Jul 7, 2015 at 10:36 PM, Sascha Hauer > >> > > wrote: > >> > > > On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote: > >> > > >> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer > >> > > >> wrote: > >> > > >> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote: > >> > > >> >> Add clk_null, which represents clocks that can not / need not > >> > > >> >> controlled by software. > >> > > >> >> There are many clocks' parent set to clk_null. > >> > > >> >> > >> > > >> >> Signed-off-by: James Liao > >> > > >> >> Signed-off-by: Eddie Huang > >> > > >> >> --- > >> > > >> >> Base on 4.1-rc1 > >> > > >> >> > >> > > >> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124 > >> > > >> >> --- > >> > > >> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++ > >> > > >> >> 1 file changed, 6 insertions(+) > >> > > >> >> > >> > > >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi > >> > > >> >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi > >> > > >> >> index 924fdb6..4798f44 100644 > >> > > >> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi > >> > > >> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi > >> > > >> >> @@ -81,6 +81,12 @@ > >> > > >> >> cpu_on= <0x8403>; > >> > > >> >> }; > >> > > >> >> > >> > > >> >> + clk_null: clk_null { > >> > > >> >> + compatible = "fixed-clock"; > >> > > >> >> + clock-frequency = <0>; > >> > > >> >> + #clock-cells = <0>; > >> > > >> >> + }; > >> > > >> > > >> > > >> > The discussion around this patch shows that we don't want to have > >> > > >> > this > >> > > >> > clock in the device tree as it is not a hardware description. > >> > > >> > > >> > > >> > Ok, fine. Eddie, you told us that the rate of the current > >> > > >> > clk_null children > >> > > >> > is not interesting. What's the motivation to send this patch > >> > > >> > anyway > >> > > >> > then? Why can't you keep its children on the orphan list where > >> > > >> > they are > >> > > >> > already now? > >> > > >> > > >> > > >> > Another possibility would be to instantiate the clk_null clock > >> > > >> > from C > >> > > >> > code rather than from the device tree. This way we wouldn't put > >> > > >> > any > >> > > >> > wrong descriptions into the device tree and still can implement > >> > > >> > the > >> > > >> > support for the real parent clocks when we actually need them. > >> > > >> > >> > > >> Some device nodes, like mmc, use a clk_null phandle as one of their > >> > > >> clocks: > >> > > >> > >> > > >> mmc1: mmc@1124 { > >> > > >> compatible = "mediatek,mt8173-mmc", > >> > > >> "mediatek,mt8135-mmc"; > >> > > >> reg = <0 0x1124 0 0x1000>; > >> > > >> interrupts = ; > >> > > >> clocks = < CLK_PERI_MSDC30_1>, > >> > > >> <_null>; > >> > > >> clock-names = "source", "hclk"; > >> > > >
Re: [PATCH] arm64: dts: mt8173: add clock_null
Hi all, On Wed, 2015-07-08 at 13:44 +0800, Sascha Hauer wrote: > On Wed, Jul 08, 2015 at 10:37:21AM +0800, Eddie Huang wrote: > > On Tue, 2015-07-07 at 23:10 +0800, Daniel Kurtz wrote: > > > On Tue, Jul 7, 2015 at 10:36 PM, Sascha Hauer > > > wrote: > > > > On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote: > > > >> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer > > > >> wrote: > > > >> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote: > > > >> >> Add clk_null, which represents clocks that can not / need not > > > >> >> controlled by software. > > > >> >> There are many clocks' parent set to clk_null. > > > >> >> > > > >> >> Signed-off-by: James Liao > > > >> >> Signed-off-by: Eddie Huang > > > >> >> --- > > > >> >> Base on 4.1-rc1 > > > >> >> > > > >> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124 > > > >> >> --- > > > >> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++ > > > >> >> 1 file changed, 6 insertions(+) > > > >> >> > > > >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi > > > >> >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi > > > >> >> index 924fdb6..4798f44 100644 > > > >> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi > > > >> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi > > > >> >> @@ -81,6 +81,12 @@ > > > >> >> cpu_on= <0x8403>; > > > >> >> }; > > > >> >> > > > >> >> + clk_null: clk_null { > > > >> >> + compatible = "fixed-clock"; > > > >> >> + clock-frequency = <0>; > > > >> >> + #clock-cells = <0>; > > > >> >> + }; > > > >> > > > > >> > The discussion around this patch shows that we don't want to have > > > >> > this > > > >> > clock in the device tree as it is not a hardware description. > > > >> > > > > >> > Ok, fine. Eddie, you told us that the rate of the current clk_null > > > >> > children > > > >> > is not interesting. What's the motivation to send this patch anyway > > > >> > then? Why can't you keep its children on the orphan list where they > > > >> > are > > > >> > already now? > > > >> > > > > >> > Another possibility would be to instantiate the clk_null clock from C > > > >> > code rather than from the device tree. This way we wouldn't put any > > > >> > wrong descriptions into the device tree and still can implement the > > > >> > support for the real parent clocks when we actually need them. > > > >> > > > >> Some device nodes, like mmc, use a clk_null phandle as one of their > > > >> clocks: > > > >> > > > >> mmc1: mmc@1124 { > > > >> compatible = "mediatek,mt8173-mmc", > > > >> "mediatek,mt8135-mmc"; > > > >> reg = <0 0x1124 0 0x1000>; > > > >> interrupts = ; > > > >> clocks = < CLK_PERI_MSDC30_1>, > > > >> <_null>; > > > >> clock-names = "source", "hclk"; > > > >> status = "disabled"; > > > >> }; > > > > > > > > This is another case than the one we discussed about. In the case above > > > > I motivated using a dummy clock since the clock exists in the system, > > > > but is not software controllable. To abstract this from the driver > > > > (which needs this clock since it exists) we here have the dummy clock. > > > > However, of course I can't prove the clock is indeed not software > > > > controllable; that's only the information I have. > > > > > > I was trying to answer your question "What's the motivation to send > > > this patch anyway?". > > > The motivation is to send follow on patches that use the clk_null > > > phandle. We need to provide
Re: [PATCH] arm64: dts: mt8173: add clock_null
Hi all, On Wed, 2015-07-08 at 13:44 +0800, Sascha Hauer wrote: On Wed, Jul 08, 2015 at 10:37:21AM +0800, Eddie Huang wrote: On Tue, 2015-07-07 at 23:10 +0800, Daniel Kurtz wrote: On Tue, Jul 7, 2015 at 10:36 PM, Sascha Hauer s.ha...@pengutronix.de wrote: On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote: On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer s.ha...@pengutronix.de wrote: On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote: Add clk_null, which represents clocks that can not / need not controlled by software. There are many clocks' parent set to clk_null. Signed-off-by: James Liao jamesjj.l...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- Base on 4.1-rc1 Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124 --- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi index 924fdb6..4798f44 100644 --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi @@ -81,6 +81,12 @@ cpu_on= 0x8403; }; + clk_null: clk_null { + compatible = fixed-clock; + clock-frequency = 0; + #clock-cells = 0; + }; The discussion around this patch shows that we don't want to have this clock in the device tree as it is not a hardware description. Ok, fine. Eddie, you told us that the rate of the current clk_null children is not interesting. What's the motivation to send this patch anyway then? Why can't you keep its children on the orphan list where they are already now? Another possibility would be to instantiate the clk_null clock from C code rather than from the device tree. This way we wouldn't put any wrong descriptions into the device tree and still can implement the support for the real parent clocks when we actually need them. Some device nodes, like mmc, use a clk_null phandle as one of their clocks: mmc1: mmc@1124 { compatible = mediatek,mt8173-mmc, mediatek,mt8135-mmc; reg = 0 0x1124 0 0x1000; interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_LOW; clocks = pericfg CLK_PERI_MSDC30_1, clk_null; clock-names = source, hclk; status = disabled; }; This is another case than the one we discussed about. In the case above I motivated using a dummy clock since the clock exists in the system, but is not software controllable. To abstract this from the driver (which needs this clock since it exists) we here have the dummy clock. However, of course I can't prove the clock is indeed not software controllable; that's only the information I have. I was trying to answer your question What's the motivation to send this patch anyway?. The motivation is to send follow on patches that use the clk_null phandle. We need to provide some clock as the mmc1's hclk. I do not understand why this has to be clk_null, though. It seems like this should be a real clock coming from one of the real clock_controller nodes. After all, the mmc driver is going to be enabling/disabling this clock for power savings at runtime. What does that even mean for clk_null ? The original purpose of this patch is to provide a common dummy clock for both software don't care clock and clock that is not software controllable.I got comments that device tree should describe hardware and should put exact clock in device tree. I think this is true. So we will remove this clock_null patch, and: 1. For Mediatek SoC CCF driver, James will clarify clock usage further. Actually, we still think it's not necessary to describe whole tree that software don't care, James will deal this in clock driver. I think that aswell since the device tree is not affected in this case. Should we realize later that we indeed need the missing clocks we can still implement them without modifying the device tree. 2. For other module that use SW not controllable clock (mmc case mentioned by Dan), because this is a real clock, we will put a dummy clock in device tree, like clk_mmchclk: dummyhclk { compatible = fixed-clock; clock-frequency = 0; #clock-cells = 0; }; How about this modification ? I wouldn't name it 'dummy', this will again raise some eyebrows. I got mmc hclk from our designer. HCLK is from AXI Bus directly (sorry, I gave wrong information to Dan and Sascha yesterday). Because there is no any mux or gate register to control this HCLK, so current clk-mt8173.c didn't model it. Since I know where
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Fri, 2015-07-10 at 16:11 +0800, Daniel Kurtz wrote: On Fri, Jul 10, 2015 at 3:27 PM, Eddie Huang eddie.hu...@mediatek.com wrote: Hi all, On Wed, 2015-07-08 at 13:44 +0800, Sascha Hauer wrote: On Wed, Jul 08, 2015 at 10:37:21AM +0800, Eddie Huang wrote: On Tue, 2015-07-07 at 23:10 +0800, Daniel Kurtz wrote: On Tue, Jul 7, 2015 at 10:36 PM, Sascha Hauer s.ha...@pengutronix.de wrote: On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote: On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer s.ha...@pengutronix.de wrote: On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote: Add clk_null, which represents clocks that can not / need not controlled by software. There are many clocks' parent set to clk_null. Signed-off-by: James Liao jamesjj.l...@mediatek.com Signed-off-by: Eddie Huang eddie.hu...@mediatek.com --- Base on 4.1-rc1 Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124 --- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi index 924fdb6..4798f44 100644 --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi @@ -81,6 +81,12 @@ cpu_on= 0x8403; }; + clk_null: clk_null { + compatible = fixed-clock; + clock-frequency = 0; + #clock-cells = 0; + }; The discussion around this patch shows that we don't want to have this clock in the device tree as it is not a hardware description. Ok, fine. Eddie, you told us that the rate of the current clk_null children is not interesting. What's the motivation to send this patch anyway then? Why can't you keep its children on the orphan list where they are already now? Another possibility would be to instantiate the clk_null clock from C code rather than from the device tree. This way we wouldn't put any wrong descriptions into the device tree and still can implement the support for the real parent clocks when we actually need them. Some device nodes, like mmc, use a clk_null phandle as one of their clocks: mmc1: mmc@1124 { compatible = mediatek,mt8173-mmc, mediatek,mt8135-mmc; reg = 0 0x1124 0 0x1000; interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_LOW; clocks = pericfg CLK_PERI_MSDC30_1, clk_null; clock-names = source, hclk; status = disabled; }; This is another case than the one we discussed about. In the case above I motivated using a dummy clock since the clock exists in the system, but is not software controllable. To abstract this from the driver (which needs this clock since it exists) we here have the dummy clock. However, of course I can't prove the clock is indeed not software controllable; that's only the information I have. I was trying to answer your question What's the motivation to send this patch anyway?. The motivation is to send follow on patches that use the clk_null phandle. We need to provide some clock as the mmc1's hclk. I do not understand why this has to be clk_null, though. It seems like this should be a real clock coming from one of the real clock_controller nodes. After all, the mmc driver is going to be enabling/disabling this clock for power savings at runtime. What does that even mean for clk_null ? The original purpose of this patch is to provide a common dummy clock for both software don't care clock and clock that is not software controllable.I got comments that device tree should describe hardware and should put exact clock in device tree. I think this is true. So we will remove this clock_null patch, and: 1. For Mediatek SoC CCF driver, James will clarify clock usage further. Actually, we still think it's not necessary to describe whole tree that software don't care, James will deal this in clock driver. I think that aswell since the device tree is not affected in this case. Should we realize later that we indeed need the missing clocks we can still implement them without modifying the device tree. 2. For other module that use SW not controllable clock (mmc case mentioned by Dan), because this is a real clock, we will put a dummy clock in device tree, like clk_mmchclk: dummyhclk { compatible = fixed-clock; clock-frequency = 0; #clock-cells = 0; }; How about this modification ? I wouldn't name it 'dummy', this will again