Menu
▾
▴
acpi-devel
|
From: Jeff G. <jg...@po...> - 2005-12-10 00:40:31
|
Matthew Garrett wrote: > On Fri, Dec 09, 2005 at 07:16:43AM -0500, Jeff Garzik wrote: > > >>libata will immediately notice the ejection without ACPI's help. > > > http://linux.yyz.us/sata/sata-status.html claims that ICH6 doesn't > support hotswap. The Intel docs seem to say the same thing. Pulling the > drive out generates an ACPI interrupt but not a PCI one. I'm really > happy to be wrong here, it's just that everything I've been able to find > so far suggests that ACPI is the only way to get a notification that the > drive has gone missing :) ICH6 and ICH7 support it just fine, through the normal SATA PHY registers. ICH5 only support it if you are clever :) Further, although one can detect hot-unplug on ICH5, hotplug is probably not detectable without polling or SMI. Jeff |
|
From: Matthew G. <mj...@sr...> - 2005-12-10 02:35:03
|
On Fri, Dec 09, 2005 at 07:40:08PM -0500, Jeff Garzik wrote: > ICH6 and ICH7 support it just fine, through the normal SATA PHY > registers. ICH5 only support it if you are clever :) ICH6 supports it even in non-AHCI mode? You may want to update the website, then :) > Further, although one can detect hot-unplug on ICH5, hotplug is probably > not detectable without polling or SMI. ACPI allows us to detect hotplug on ICH5, which sounds like a good argument for its inclusion. -- Matthew Garrett | mj...@sr... |
|
From: Jeff G. <jg...@po...> - 2005-12-10 02:39:47
|
Matthew Garrett wrote: > On Fri, Dec 09, 2005 at 07:40:08PM -0500, Jeff Garzik wrote: > > >>ICH6 and ICH7 support it just fine, through the normal SATA PHY >>registers. ICH5 only support it if you are clever :) > > > ICH6 supports it even in non-AHCI mode? You may want to update the > website, then :) Yes, its a bit outdated. I just found out that ICH6/7 supports access to SATA PHY registers even in non-AHCI mode. >>Further, although one can detect hot-unplug on ICH5, hotplug is probably >>not detectable without polling or SMI. > > > ACPI allows us to detect hotplug on ICH5, which sounds like a good > argument for its inclusion. One special case (ICH5 hotplug, but not ICH5 hot unplug), when all other cases are handled in the normal way? That's not a good argument at all. Jeff |
|
From: Matthew G. <mj...@sr...> - 2005-12-10 02:48:29
|
On Fri, Dec 09, 2005 at 09:39:21PM -0500, Jeff Garzik wrote: > Matthew Garrett wrote: > >On Fri, Dec 09, 2005 at 07:40:08PM -0500, Jeff Garzik wrote: > > > > > >>ICH6 and ICH7 support it just fine, through the normal SATA PHY > >>registers. ICH5 only support it if you are clever :) > > > > > >ICH6 supports it even in non-AHCI mode? You may want to update the > >website, then :) > > Yes, its a bit outdated. I just found out that ICH6/7 supports access > to SATA PHY registers even in non-AHCI mode. Oh, cool. That makes life a /lot/ easier - most laptops I've seen using SATA are ICH6, so excellent! > >>Further, although one can detect hot-unplug on ICH5, hotplug is probably > >>not detectable without polling or SMI. > > > > > >ACPI allows us to detect hotplug on ICH5, which sounds like a good > >argument for its inclusion. > > One special case (ICH5 hotplug, but not ICH5 hot unplug), when all other > cases are handled in the normal way? > > That's not a good argument at all. Well, we could always just add it to ata_piix and leave it out of the acpi and scsi layers. I've no great atachment to ACPI - I just want this stuff to work :) Basically, ACPI gives us the possibility of making hotplug/unplug work on hosts that don't otherwise support it under a limited set of conditions. I think that's worthwhile, especially if it can be done in a way that doesn't introduce hugely ugly stuff to the rest of the kernel. -- Matthew Garrett | mj...@sr... |
|
From: Jeff G. <jg...@po...> - 2005-12-10 02:57:52
|
Matthew Garrett wrote: > On Fri, Dec 09, 2005 at 09:41:52PM -0500, Jeff Garzik wrote: > > >>Do you even know if this special case is applicable outside of Dell ICH5 >>boxes? And I thought your previous messages were referring to ICH6? > > > Every laptop I have access to, whether it's SATA or PATA, fires an ACPI > notification when a drive is removed from a bay. The ICH5 case is > probably somewhat special-cased, but when we move over to driving PATA > with libata it's going to be a lot more useful. If ICH6 can be managed > without resorting to ACPI, it's less necessary in the short term, but I > think PATA support is going to require it in the end anyway (especially > since we probably want to call the _GTM and _STM methods on PATA > devices) Yes, I do agree with this WRT PATA. Randy Dunlap's ACPI stuff is particularly interesting for this, though I haven't had time to review it in depth. I'm a bit more reluctant WRT SATA. Jeff |
|
From: Andrew G. <and...@gm...> - 2005-12-10 03:47:51
|
On 12/9/05, Jeff Garzik <jg...@po...> wrote: > Yes, I do agree with this WRT PATA. Randy Dunlap's ACPI stuff is > particularly interesting for this, though I haven't had time to review > it in depth. > > I'm a bit more reluctant WRT SATA. (side note: Shaohua's patch added ACPI support to PATA. Randy's was the SATA ACPI support.) ACPI 3.0 specifically mentions SATA and the control methods that it expects the OS to make use of: _SDD and _GTF. This is needed for things like HD password unlocking. So, someone needs to be handling this whenever the SATA drive is reinitialized, such as on resume. So there's gotta be some SATA ACPI code, somewhere. (And if there is, then handling the ICH5 ACPI hotplug interrupt seems like maybe something it should handle, too.) I'm sure it's possible to properly abstract things so that arch-neutral code can remain ACPI-unaware -- I just wanted to make it clear that even if you don't support ICH5 hotplug there are still ACPI requirements for SATA. Regards -- Andy |
|
From: Jeff G. <jg...@po...> - 2005-12-10 02:42:41
|
Matthew Garrett wrote: > ACPI allows us to detect hotplug on ICH5, which sounds like a good > argument for its inclusion. Do you even know if this special case is applicable outside of Dell ICH5 boxes? And I thought your previous messages were referring to ICH6? This is sounding more and more like a special-case-of-a-special-case. Jeff |
|
From: Matthew G. <mj...@sr...> - 2005-12-10 02:50:40
|
On Fri, Dec 09, 2005 at 09:41:52PM -0500, Jeff Garzik wrote: > Do you even know if this special case is applicable outside of Dell ICH5 > boxes? And I thought your previous messages were referring to ICH6? Every laptop I have access to, whether it's SATA or PATA, fires an ACPI notification when a drive is removed from a bay. The ICH5 case is probably somewhat special-cased, but when we move over to driving PATA with libata it's going to be a lot more useful. If ICH6 can be managed without resorting to ACPI, it's less necessary in the short term, but I think PATA support is going to require it in the end anyway (especially since we probably want to call the _GTM and _STM methods on PATA devices) -- Matthew Garrett | mj...@sr... |
|
From: Alan C. <al...@lx...> - 2005-12-11 23:37:45
|
On Gwe, 2005-12-09 at 21:41 -0500, Jeff Garzik wrote: > Do you even know if this special case is applicable outside of Dell ICH5 > boxes? And I thought your previous messages were referring to ICH6? Some older thinkpads seem to support this. Also some laptops generate pnpbios changes. The different methods alone argue for a generic interface h |
|
From: Matthew G. <mj...@sr...> - 2005-12-08 14:43:49
|
On Thu, Dec 08, 2005 at 02:30:57PM +0000, Alan Cox wrote: > SCSI/libata can go easily from ata channel to pci device to device. The > rest of the logic belongs outside of scsi/libata. ACPI methods belong to SATA/PATA targets, not PCI devices. The notification you get is something of the form \SB.PCI.IDE0.SEC.MASTER on sensible devices, and \SB.C043.C438.C222.C223 on anything from HP[1]. Somehow, you have to get from there to a specific SCSI host and target. By far the easiest way of doing that is to register them at device add time, which needs a small amount of cooperation from the SCSI or libata layers. And to register the notifications in the first place, you need to know the ACPI handles. [1] Thanks, HP -- Matthew Garrett | mj...@sr... |
|
From: Alan C. <al...@lx...> - 2005-12-08 14:53:57
|
On Iau, 2005-12-08 at 14:43 +0000, Matthew Garrett wrote: > ACPI methods belong to SATA/PATA targets, not PCI devices. The > notification you get is something of the form > > \SB.PCI.IDE0.SEC.MASTER That is fine. Given struct ata_port * you can get channel = ap->hard_port_no pci device ptr = to_pci(ap->host_set->dev) And from the struct ata_device * slave = (adev->devno == 1) |
|
From: Randy D. <ran...@li...> - 2005-12-13 18:10:53
|
Hi Matthew,
I have a few comments and a question on this patch, please.
(Yes, I know it won't be merged.)
Most of these are general patch process comments.
However, the last comment is the important one.
1. I had problems applying it. What tree is it against?
Say so in the description.
2. use diff -p (in SubmittingPatches)
3. use diffstat
4. Why 2 diffs against include/linux/libata.h ?
I was hoping that diffstat would show this, but it just merges
the 2 libata.h patches together. 'lsdiff' does show this,
however.
5. #includes in alpha order as much as possible.
6. Patch had some trailing whitespace (usually tabs).
Some tools detect this and warn about it.
7. Most important: What good does the ACPI interface do/add?
What I mean is that acpi_get_child() in scsi_acpi_find_channel()
always returns a handle value of 0, so it doesn't get us
any closer to determining the ACPI address (_ADR) of the SATA
devices. The acpi_get_devices() technique in my patch (basically
walking the ACPI namespace, looking at all "devices") is the
only way that I know of doing this, but I would certainly
like to find a better way.
On Thu, 8 Dec 2005 03:02:42 +0000
Matthew Garrett <mj...@sr...> wrote:
> Hi!
>
> The included patch does three things:
>
> 1) It adds basic support for binding SCSI and SATA devices to ACPI
> device handles. At the moment this is limited to hosts, and in practice
> it's probably limited to SATA ones (ACPI doesn't spec how SCSI devices
> should appear in the DSDT, so I'm guessing that in general they don't).
> Given a host, you can DEVICE_ACPI_HANDLE(dev) it to get the handle to
> the ACPI device - this should be handy for implementing suspend
> functions, since the methods should be in a standard location underneath
> this.
[snip]
Thanks,
---
~Randy
|
|
From: Matthew G. <mj...@sr...> - 2005-12-13 18:27:24
|
On Tue, Dec 13, 2005 at 10:14:17AM -0800, Randy Dunlap wrote: > 1. I had problems applying it. What tree is it against? > Say so in the description. It was against 2.6.15-git at the time, but I accidently left a hunk of stuff from the hotplug patch in there which probably confused things. I'll try to rediff it by the end of the week (and do other tidying) > 7. Most important: What good does the ACPI interface do/add? > What I mean is that acpi_get_child() in scsi_acpi_find_channel() > always returns a handle value of 0, so it doesn't get us > any closer to determining the ACPI address (_ADR) of the SATA > devices. The acpi_get_devices() technique in my patch (basically > walking the ACPI namespace, looking at all "devices") is the > only way that I know of doing this, but I would certainly > like to find a better way. When the PCI bus is registered, acpi walks it and finds the appropriate acpi handle for each PCI device. This is shoved in the firmware_data field of the device structure. Later on, we register the scsi bus. As each item on the bus is added, the acpi callback gets called. If it's not an endpoint, scsi_acpi_find_channel gets called. We're worried about the host case. The host number will correspond to the appropriate _ADR underneath the PCI device that the host is on, so we simply get the handle of the PCI device and then ask for the child with the appropriate _ADR. That gives us the handle for the device, and returning that sticks it back in the child's firmware_data field. At least, that's how it works here. If acpi_get_child always returns 0 for you, then it sounds like something's going horribly wrong. Do you have a copy of the DSDT? -- Matthew Garrett | mj...@sr... |
|
From: Randy D. <ran...@li...> - 2005-12-13 19:04:06
|
On Tue, 13 Dec 2005 18:26:51 +0000 Matthew Garrett <mj...@sr...> wrote: > On Tue, Dec 13, 2005 at 10:14:17AM -0800, Randy Dunlap wrote: > > > 7. Most important: What good does the ACPI interface do/add? > > What I mean is that acpi_get_child() in scsi_acpi_find_channel() > > always returns a handle value of 0, so it doesn't get us > > any closer to determining the ACPI address (_ADR) of the SATA > > devices. The acpi_get_devices() technique in my patch (basically > > walking the ACPI namespace, looking at all "devices") is the > > only way that I know of doing this, but I would certainly > > like to find a better way. > > When the PCI bus is registered, acpi walks it and finds the appropriate > acpi handle for each PCI device. This is shoved in the > firmware_data field of the device structure. Later on, we register the > scsi bus. As each item on the bus is added, the acpi callback gets > called. If it's not an endpoint, scsi_acpi_find_channel gets called. > We're worried about the host case. The host number will correspond to > the appropriate _ADR underneath the PCI device that the host is on, so > we simply get the handle of the PCI device and then ask for the child > with the appropriate _ADR. That gives us the handle for the device, and > returning that sticks it back in the child's firmware_data field. > > At least, that's how it works here. If acpi_get_child always returns 0 > for you, then it sounds like something's going horribly wrong. Do you > have a copy of the DSDT? Thanks for the explanation. The 136 KB DSDT is at: http://www.xenotime.net/linux/SATA/acpitbl.out . --- ~Randy |
Thanks for helping keep SourceForge clean.
X