public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4] ata: ahci_platform: Add ACPI support for AMD Seattle SATA controller
Date: Thu, 02 Oct 2014 10:39:18 +0200	[thread overview]
Message-ID: <4872185.h11DQxW6kP@wuerfel> (raw)
In-Reply-To: <542C6FE9.10903@amd.com>

On Wednesday 01 October 2014 16:19:37 Suravee Suthikulanit wrote:
> On 9/16/2014 8:26 PM, Matthew Garrett wrote:
> > On Mon, Sep 15, 2014 at 07:47:23PM -0500, suravee.suthikulpanit at amd.com wrote:
> >> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> >>
> >> This patch adds ACPI match table in ahci_platform. The table includes
> >> the acpi_device_id to match AMD Seattle SATA controller with following
> >> asl structure in DSDT:
> >>
> >>      Device (SATA0)
> >>      {
> >>        Name(_HID, "AMDI0600")        // Seattle AHSATA
> >
> > There really ought to be a well-defined PNPID for AHCI, so you can _HID
> > to AMD and _CID to something generic. That way we won't have:
> >
> >> +#ifdef CONFIG_ATA_ACPI
> >> +static const struct acpi_device_id ahci_acpi_match[] = {
> >> +    { "AMDI0600", 0 }, /* AMD Seattle AHCI */
> >> +    { },
> >> +};
> >
> > utter sadness here. Really, please don't end up in a situation where we
> > need to add device-specific IDs to a generic driver.
> >
> Matthew,
> 
> Currently, there is no _CID defined for generic AHCI. We will work on 
> proposing one, and provide update patches for including the new ID.
> 

I think part of the problem is that there is no specification for what
an AHCI device should look like when it's not connected to a PCI
bus, the AHCI document published by Intel just states:

"AHCI is a PCI class device that acts as a data movement engine
between system memory and Serial ATA devices."

It also requires the PCI config space to have the PM capability
registers and (optionally) the MSI capability registers.
There are lots of chips we support in Linux with the ahci-platform
driver, but they are not actually compliant because they cannot
use the pmcap registers but instead typically rely on setting
external clock/phy/regulator/pinctrl registers.

The ARM SBSA document just requires any SATA controller to be AHCI
compliant but does not explain what that means in the case where
it's not a PCI device.

	Arnd

  reply	other threads:[~2014-10-02  8:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-16  0:47 [RFC PATCH for AMD Seattle 0/4] Drivers for AMD-Seatlle to boot from ACPI suravee.suthikulpanit at amd.com
2014-09-16  0:47 ` [PATCH 1/4] ata: ahci_platform: Add ACPI support for AMD Seattle SATA controller suravee.suthikulpanit at amd.com
2014-09-17  1:26   ` Matthew Garrett
2014-10-01 21:19     ` Suravee Suthikulanit
2014-10-02  8:39       ` Arnd Bergmann [this message]
2014-10-06 16:31         ` Matthew Garrett
2014-10-06 18:19           ` Arnd Bergmann
2014-10-06 18:21             ` Matthew Garrett
2014-10-06 18:44               ` Arnd Bergmann
2014-10-06 18:47                 ` Matthew Garrett
2014-09-16  0:47 ` [PATCH 2/4] arm64/efi: efistub: don't abort if base of DRAM is occupied suravee.suthikulpanit at amd.com
2014-09-16  0:47 ` [PATCH 3/4] efi/arm64: fix fdt-related memory reservation suravee.suthikulpanit at amd.com
2014-09-16  0:47 ` [PATCH 4/4] [RFC PATCH for Juno 2/2] tty: SBSA compatible UART suravee.suthikulpanit at amd.com
2014-09-17 10:40   ` One Thousand Gnomes
2014-09-17 17:01     ` Graeme Gregory
2014-09-16  4:28 ` [RFC PATCH for AMD Seattle 0/4] Drivers for AMD-Seatlle to boot from ACPI Suravee Suthikulpanit
2014-09-16 22:56   ` Jon Masters

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=4872185.h11DQxW6kP@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox