linux-kernel - Re: [linux-pm Query] Power Management Device Suspend/ Resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 Sep 2011 12:15:40 +0530
From:	Viresh Kumar <viresh.kumar@...com>
To:	Vinod Koul <vinod.koul@...el.com>
Cc:	"linux-pm@...ts.linux-foundation.org" 
	<linux-pm@...ts.linux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Linus Walleij <linus.walleij@...aro.org>,
	Deepak Sikri <deepak.sikri79@...il.com>,
	Shiraz HASHIM <shiraz.hashim@...com>,
	Deepak SIKRI <deepak.sikri@...com>,
	Vipin KUMAR <vipin.kumar@...com>,
	Vipul Kumar SAMAR <vipulkumar.samar@...com>,
	Pratyush ANAND <pratyush.anand@...com>,
	Rajeev KUMAR <rajeev-dlh.kumar@...com>,
	Armando VISCONTI <armando.visconti@...com>,
	Bhupesh SHARMA <bhupesh.sharma@...com>,
	Amit VIRDI <Amit.VIRDI@...com>,
	Vincenzo FRASCINO <Vincenzo.FRASCINO@...com>
Subject: Re: [linux-pm Query] Power Management Device Suspend/ Resume

Vinod,

Thanks for mailing us back.

On 9/28/2011 9:12 AM, Vinod Koul wrote:
> On Wed, 2011-09-28 at 08:55 +0530, Viresh Kumar wrote:
>> On 9/22/2011 4:19 PM, Deepak Sikri wrote:
> are you trying to do runtime power management or traditional suspend and
> resume? IMO both should be done...

We will first be testing traditional suspend/resume, but obviously we would
try to design drivers in order to support runtime PM too.

>>> *Query- 1*. Suppose my platform has a ADC driver under char framework, which internally uses the
>>> DMA driver (channels). Now, ADC driver can be used by other kernel drivers or directly from user application.
>>>  
>>> *1. a.* What are the expectations from the suspend and resume routines of both the devices, DMA & ADC ?
>>>  
>>> */-- Given that few of the options are/*
>>> */1.a.1. On suspend,/*
>>> In ADC suspend function: ADC releases all the DMA channels, latches its registers; and
>>> DMA suspend function: DMA does nothing except for lataching of registers if required.
>>>  
>>> */1.a.2. On suspend, /*
>>> ADC suspend function: ADC just latches its registers and stops R/W through DMA, no DMA channel release;
>>> DMA suspend function: DMA halts its operating channels, and latches its registers if required.
> Well channel release/alloc is not really required. You can goto suspend
> in between as well. if you have queued but not active descriptors on all
> channels then dmac is idle and you can use this time to goto suspend.

But the time suspend is called for DMA, we may in middle of DMA transfers
on few channels. So should we wait for them to finish or simply disable
channel transfer? And in case of resume what will happen to transfers that
were active during suspend?

>>> *1.b* Will the suspend resume for the dependent drivers follow sequencing, i.e. Suspend of ADC followed by
>>> Suspend of DMA? (Assume both of these devices are hooked on to Platform bus, given that ADC uses DMA)
> why do you care?

Suppose suspend of DMA occurs first and we disable its clock in the suspend
routine. Now before the suspend of ADC is called, ADC requests for DMA
transfers and because not every routine of DMA keeps track of clk is on/off,
it may try to access DMA register.

So, we must ensure that all children are suspended before the parent is
requested to suspend. And probably this is the correct way.
So, here we need ADC to suspend before DMA. How is this sequencing ensured?

>>> 2.1 The user space threads freeze first followed by kernel space.  In case the user space process issues a a system
>>> call (lets assume an ioctl system call), how will the user space thread respond in case of suspend to ram?
> all user space processes are frozen on STR

Yes, but what will be its state. Will the system calls complete? Will it
close all devices opened by it before freezing?

Suppose a user applications is accessing few ADC channels. ADC controller
and its channel are all configured. Now, suspend is requested. What should
ADC driver do? As power will be turned off, its register will loose their
value.

Should ADC reconfigure all its channel registers by keeping their state?
Also it is not very straight forward to reconfigure channels directly, as
registers are required to be programmed in certain sequence, so there
needs to be good amount of intelligence put into driver for that.

IIRC, i couldn't find any such stuff in other mainline drivers. And that's
why we are confused on this topic.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/