All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Small <tim@buttersideup.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Robert Hancock" <hancockrwd@gmail.com>,
	"Dâniel Fraga" <fragabr@gmail.com>,
	linux-ide@vger.kernel.org
Subject: Re: ICH10 not working with AHCI kernel option
Date: Fri, 09 Apr 2010 17:37:44 +0100	[thread overview]
Message-ID: <4BBF57D8.6040800@buttersideup.com> (raw)
In-Reply-To: <20100409160707.6116965e@lxorguk.ukuu.org.uk>

Alan Cox wrote:
>> Some laptop BIOSes do try to access the controller at certain points,
>> like suspend or powerdown (presumably to make sure the drive heads are
>> unloaded or something) - we've run into problems in the past when the
>> controller was disabled at points where the BIOS didn't expect it to
>> be and it was trying to poke at it, causing a big delay until it
>> finally gave up.
>>     
>
>
> Suspend/powerdown are less of a problem because any patch to put it into
> AHCI mode should put it back as it was before during suspend/poweroff.
>   

Using DECLARE_PCI_FIXUP_SUSPEND etc?  I'll see if I can get some time to
have a go at this.  The hardware I have access to without AHCI BIOS
options are Dell Poweredge R200s and R300s.

As far as I can workout, from my experiments using setpci+fakehp two of
the port IO regions get coalesced, and an additional memory IO BAR gets
set up on the ICH9R when in AHCI mode, so I'll have to try and work out
how to handle this properly in the quirk.

As Robert said, the "off-by-default + if it breaks, you get to keep both
pieces" policy is what I had in mind, and I think this should go into
arch/x86/pci/fixup.c ?  Any obvious pit-falls to avoid?


Cheers,

Tim.

  reply	other threads:[~2010-04-09 16:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-08 13:36 ICH10 not working with AHCI kernel option Dâniel Fraga
2010-04-08 13:45 ` Alan Cox
2010-04-08 13:46   ` Dâniel Fraga
2010-04-08 13:59     ` Alan Cox
2010-04-08 14:02       ` Dâniel Fraga
2010-04-08 14:09         ` Alan Cox
2010-04-08 14:15           ` Dâniel Fraga
2010-04-08 23:54             ` Robert Hancock
2010-04-09  2:00               ` Dâniel Fraga
2010-04-09  2:09                 ` Robert Hancock
2010-04-09  2:22                   ` Dâniel Fraga
2010-04-09  2:52                     ` Robert Hancock
2010-04-09  3:16                       ` Dâniel Fraga
2010-04-09 10:12                       ` Tim Small
2010-04-09 14:47                         ` Robert Hancock
2010-04-09 15:07                           ` Alan Cox
2010-04-09 16:37                             ` Tim Small [this message]
2010-04-09 18:53                               ` Alan Cox
2010-04-09 23:04                               ` Robert Hancock
2010-04-09  4:28                 ` Jeff Garzik
2010-04-09  9:16                 ` Alan Cox
2010-04-09  9:08               ` Alan Cox
2010-04-09  9:12                 ` Dâniel Fraga

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=4BBF57D8.6040800@buttersideup.com \
    --to=tim@buttersideup.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=fragabr@gmail.com \
    --cc=hancockrwd@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    /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.