All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Abhilash Kesavan <kesavan.abhilash@gmail.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	Vikas Sajjan <vikas.sajjan@samsung.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Pankaj Dubey <pankaj.dubey@samsung.com>
Subject: Re: exynos5800-peach-pi: suspend/resume (still) broken
Date: Fri, 20 Mar 2015 18:52:48 +0100	[thread overview]
Message-ID: <550C5E70.30009@collabora.co.uk> (raw)
In-Reply-To: <CAM4voanUg87=Ya6azGCRz8r2=WJ0wi4ktqdn6GD6ULJsnLUMmw@mail.gmail.com>

Hello Abhilash,

On 03/20/2015 06:40 PM, Abhilash Kesavan wrote:
>>
>> I have made some progress on this. This is the current state:
>>
>> If I use next-20141114 (which was when the S2R code first appeared in
>> linux-next), then all is good. next-20141117 is fine too but things
>> are broken in next-20141118.
>> I have narrowed it down to the commit: "ae43b32 ARM: 8202/1:
>> dmaengine: pl330: Add runtime Power Management support v12". The only
>> way I see this impacting s2r is because it disables the dma pclk while
>> suspending or before.
>>
>> Checking further, will update in a bit.
> 
> OK, so disabling the mdma0 node in "arch/arm/boot/dts/exynos5420.dtsi"
> gets things working. Like Kevin mentioned in the initial report, I
> need to disable DRM else there is a crash while suspending. With these
> two changes, on linus' tree and kgene's for-next s2r works fine.
>

Awesome, thanks a lot for digging this out!
 
> On linux-next, I need to disable CONFIG_MWIFIEX too.
> 

Yes, I also saw that issue with mwfiex when suspend-to-idle (which works
in -next) due the MMC_PM_KEEP_POWER flag being set in the host pm caps.
But I don't see that being set in the host driver.

> Also, I observe cros-ec-spi transfer failures during resume and
> sometimes it is unable to re-enable the tps fets causing a crash.
> However, that would be a driver specific issue.
> 

Indeed, I can take a look to that issue as well.

> Regarding the mdma0 disablement, it looks like for the system to
> suspend properly the mdma0 pclk needs to stay on.
>

It seems so, I remember we had other issues with the mentioned commit
due clocks being gated. For example the mau_epll clock that was needed
to access the audss block registers and caused a boot hang on Exyos5420.

That specific issue was fixed by f1e9203e2366 ("clk: samsung: Fix Exynos
5420 pinctrl setup and clock disable failure due to domain being gated")
which solves it by enabling the mau_epll on probe.
 
> Regards,
> Abhilash
>>>

Best regards,
Javier

WARNING: multiple messages have this Message-ID (diff)
From: javier.martinez@collabora.co.uk (Javier Martinez Canillas)
To: linux-arm-kernel@lists.infradead.org
Subject: exynos5800-peach-pi: suspend/resume (still) broken
Date: Fri, 20 Mar 2015 18:52:48 +0100	[thread overview]
Message-ID: <550C5E70.30009@collabora.co.uk> (raw)
In-Reply-To: <CAM4voanUg87=Ya6azGCRz8r2=WJ0wi4ktqdn6GD6ULJsnLUMmw@mail.gmail.com>

Hello Abhilash,

On 03/20/2015 06:40 PM, Abhilash Kesavan wrote:
>>
>> I have made some progress on this. This is the current state:
>>
>> If I use next-20141114 (which was when the S2R code first appeared in
>> linux-next), then all is good. next-20141117 is fine too but things
>> are broken in next-20141118.
>> I have narrowed it down to the commit: "ae43b32 ARM: 8202/1:
>> dmaengine: pl330: Add runtime Power Management support v12". The only
>> way I see this impacting s2r is because it disables the dma pclk while
>> suspending or before.
>>
>> Checking further, will update in a bit.
> 
> OK, so disabling the mdma0 node in "arch/arm/boot/dts/exynos5420.dtsi"
> gets things working. Like Kevin mentioned in the initial report, I
> need to disable DRM else there is a crash while suspending. With these
> two changes, on linus' tree and kgene's for-next s2r works fine.
>

Awesome, thanks a lot for digging this out!
 
> On linux-next, I need to disable CONFIG_MWIFIEX too.
> 

Yes, I also saw that issue with mwfiex when suspend-to-idle (which works
in -next) due the MMC_PM_KEEP_POWER flag being set in the host pm caps.
But I don't see that being set in the host driver.

> Also, I observe cros-ec-spi transfer failures during resume and
> sometimes it is unable to re-enable the tps fets causing a crash.
> However, that would be a driver specific issue.
> 

Indeed, I can take a look to that issue as well.

> Regarding the mdma0 disablement, it looks like for the system to
> suspend properly the mdma0 pclk needs to stay on.
>

It seems so, I remember we had other issues with the mentioned commit
due clocks being gated. For example the mau_epll clock that was needed
to access the audss block registers and caused a boot hang on Exyos5420.

That specific issue was fixed by f1e9203e2366 ("clk: samsung: Fix Exynos
5420 pinctrl setup and clock disable failure due to domain being gated")
which solves it by enabling the mau_epll on probe.
 
> Regards,
> Abhilash
>>>

Best regards,
Javier

  reply	other threads:[~2015-03-20 17:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-17 17:35 exynos5800-peach-pi: suspend/resume (still) broken Kevin Hilman
2015-03-17 17:35 ` Kevin Hilman
2015-03-18 10:31 ` Javier Martinez Canillas
2015-03-18 10:31   ` Javier Martinez Canillas
2015-03-20 14:23   ` Abhilash Kesavan
2015-03-20 14:23     ` Abhilash Kesavan
2015-03-20 16:16     ` Javier Martinez Canillas
2015-03-20 16:16       ` Javier Martinez Canillas
2015-03-20 16:29       ` Abhilash Kesavan
2015-03-20 16:29         ` Abhilash Kesavan
2015-03-20 17:40         ` Abhilash Kesavan
2015-03-20 17:40           ` Abhilash Kesavan
2015-03-20 17:52           ` Javier Martinez Canillas [this message]
2015-03-20 17:52             ` Javier Martinez Canillas
2015-03-27 13:29           ` Javier Martinez Canillas
2015-03-27 13:29             ` Javier Martinez Canillas
2015-03-27 14:06             ` Abhilash Kesavan
2015-03-27 14:06               ` Abhilash Kesavan
2015-03-27 14:30               ` Javier Martinez Canillas
2015-03-27 14:30                 ` Javier Martinez Canillas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550C5E70.30009@collabora.co.uk \
    --to=javier.martinez@collabora.co.uk \
    --cc=kesavan.abhilash@gmail.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=pankaj.dubey@samsung.com \
    --cc=vikas.sajjan@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.