[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1111101028250.2338-100000@iolanthe.rowland.org>
Date: Thu, 10 Nov 2011 10:30:53 -0500 (EST)
From: Alan Stern <stern@...land.harvard.edu>
To: Lin Ming <ming.m.lin@...el.com>
cc: linux-kernel@...r.kernel.org, <linux-ide@...r.kernel.org>,
<linux-scsi@...r.kernel.org>, <linux-pm@...r.kernel.org>,
Jeff Garzik <jgarzik@...ox.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
James Bottomley <JBottomley@...allels.com>,
Tejun Heo <tj@...nel.org>, Huang Ying <ying.huang@...el.com>,
Zhang Rui <rui.zhang@...el.com>
Subject: Re: [PATCH v2 0/4] ata port runtime power management support
On Thu, 10 Nov 2011, Lin Ming wrote:
> Hi, all
>
> These 4 patches add ata port runtime pm support.
>
> v1:
> https://lkml.org/lkml/2011/11/2/23
>
> v2 is totally different than v1.
>
> v1 performed ata port runtime pm through scsi layer.
> Added hook to scsi host runtime suspend/resume code.
>
> I realized that this is not the natural way to do ata port runtime pm.
> It does not deal with the races with ata port system suspend/resume.
>
> With v2, ata port is made to be parent device of scsi host.
>
> Currently, the device tree of ata port and scsi host looks as below,
>
> /sys/devices/pci0000:00/0000:00:1f.2 (ahci controller)
> |-- ata1 (ata port)
> |-- host0 (scsi host)
> |-- target0:0:0 (scsi target)
> |-- 0:0:0:0 (disk)
>
> v2 changes it to:
>
> /sys/devices/pci0000:00/0000:00:1f.2 (ahci controller)
> |-- ata1 (ata port)
> |-- host0 (scsi host)
> |-- target0:0:0 (scsi target)
> |-- 0:0:0:0 (disk)
>
> So ata port runtime PM will happen as:
>
> disk suspend --> scsi target suspend --> scsi host suspend --> ata port
> suspend.
>
> This is much cleaner and natural.
Have you observed any real benefit from this feature?
Currently, disks will not be runtime-suspended unless (1) the user
requests it by setting the appropriate power/control attribute, and (2)
the device file is closed (in particular, the disk has no mounted
filesystems or swap partitions). I don't imagine this combination of
events is very common for disks using libata.
Alan Stern
--
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/
Powered by blists - more mailing lists