From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 13:02:08 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98C181065673; Mon, 21 Jul 2008 13:02:08 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp10.yandex.ru (smtp10.yandex.ru [213.180.223.92]) by mx1.freebsd.org (Postfix) with ESMTP id 975A28FC0C; Mon, 21 Jul 2008 13:02:07 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([77.72.136.145]:33263 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S5867044AbYGUNCA (ORCPT + 1 other); Mon, 21 Jul 2008 17:02:00 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp10 X-Yandex-TimeMark: 1216645320 X-MsgDayCount: 9 X-Comment: RFC 2476 MSA function at smtp10.yandex.ru logged sender identity as: bu7cher Message-ID: <48848887.6020201@yandex.ru> Date: Mon, 21 Jul 2008 17:00:55 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: =?UTF-8?B?U8O4cmVuIFNjaG1pZHQ=?= References: <200807151124.36621.snasonov@bcc.ru> <4884668C.5060606@yandex.ru> <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> In-Reply-To: <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.ORG, Sergey G Nasonov Subject: Re: RFC, RFT: AHCI driver reorganization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 13:02:08 -0000 Søren Schmidt wrote: > This does massive changes to the way AHCI devices are treated, so it > will need testing on all the AHCI platforms currently supported to make > sure nothing breaks. The adding of PM learned me this is a critical part > to touch, ouch :) Yes, I agree. I think 2 weeks is good time to test :) > At any rate, fixing the suspend / resume problems should be dealt with > in a more generic manner, not just for AHCI, by splitting the work done > by the _chipinit and _allocate functions so that just the chipset > specifics can be restored on resume, not the allocations etc. No, splitting was made before.. It targeted to be more conform to AHCI spec. I think after vacation you will have much more time to review. Currently I replaced bus_generic_suspend/bus_generic_resume to: int ata_pci_suspend(device_t dev) { struct ata_pci_controller *ctlr = device_get_softc(dev); int error = 0; bus_generic_suspend(dev); if (ctlr->suspend) error = ctlr->suspend(dev); return error; } int ata_pci_resume(device_t dev) { struct ata_pci_controller *ctlr = device_get_softc(dev); int error = 0; if (ctlr->resume) error = ctlr->resume(dev); bus_generic_resume(dev); return error; } So, I think it's easy to implement ctlr->suspend/resume for each specific controller.. > I'm in doubt as to what makes most sense todo, I'm spare time limitted > still, so progress here is slow, heck my WIP on NCQ support is still > just that and touches the same code parts in ACHI so they willl get even > more behind, oh well... > > I'm starting to wonder if I should just let it go and leave ATA to its > own faith, and get on with other things... What about merging some parts of your WIP (which may be published) to perforce repository, it may take some time for you, but after that some people can help to do some work with your review. ATA is a big subsystem and it isn't easy to maintain it alone. I think.. -- WBR, Andrey V. Elsukov