Re: [PATCH v2 9/9] rtc: Add support for the MediaTek MT6358 RTC

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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

[Eddie Huang]

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