Re: SATA powersave patches

[Tejun Heo <htejun@gmail.com>]

Pavel Machek wrote:
> I'm probably doing something wrong, but...
>
> I'm on commit 
>
> commit 9a7b050525f7d70d2ed62affb691b9d4ca2b82d2
> tree b8195e5625dc5bad6757b0dddec0dacf416a0779
> parent 50c3086de212ce56eaa2bf284586fb021615b5e1
> author Tejun Heo <htejun@gmail.com> Mon, 16 Oct 2006 07:24:57 +0900
> committer Tejun Heo <htejun@gmail.com> Mon, 16 Oct 2006 07:24:57 +0900
>
>     [PATCH] sata_sil24: implement PORT_RST
>
>     As DEV_RST (hardreset) sometimes fail to recover the controller
>     (especially after PMP DMA CS errata).  In such cases, perform
> PORT_RST
>     prior to DEV_RST.
>
>     Signed-off-by: Tejun Heo <htejun@gmail.com>
>
> (2.6.19-rc1)
>
> and I do not see powersave tunable:
>
> root@amd:/sys/module# ls libata/parameters/
> ata_probe_timeout         atapi_enabled hotplug_polling_interval
> atapi_dmadir              fua
>
> ...how do I pull working version?

I haven't updated link powersave patch yet.  Core implementation was 
agreed on but interface hasn't been decided yet.  Maybe it's about time 
to add /sys/class/ata_{host|device}/.  So, the patchset is pushed back 
for the time being.

> > > > So, I think option #1 is the way to go - implementing leveled dynamic 
> > > > power management infrastructure and adding support in the block layer. 
> > > > What do you think?
> > > Would be nice :-).
> > So, do you think we're ready for another PM infrastructure update?  :-P
>
> Well... things are pretty quiet in that area just now... So yes.

If I understood correctly, the high power consumption of ahci controller 
can be solved by dynamically turning off command processing while the 
controller is idle, which fits nicely into link powersaving, right?  So, 
I think full-fledged leveled dynamic PM would be an overkill for this 
particular problem, but then again, maybe the correct way to implement 
link powersaving is via leveled dynamic PM.  I'll give it more thoughts.

Thanks.

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