Re: SATA open bugs
Tejun Heo wrote: Hello, Natalie. http://bugzilla.kernel.org/show_bug.cgi?id=8649 This one is chrp specific. The native mode fix didn't work. I'll follow up later. Following up in private with original porter now. I really think this is a combination of a chip bug and firmware configuration being futzed. We might have to leave IRQ steering at 14/15 even in PCI mode, because the ISA bridge isn't so smart as the docs imply it is. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
> > http://bugzilla.kernel.org/show_bug.cgi?id=8424 - patch review > This one is on Alan. I think not - something horrible is happening in dma_alloc_coherent when called from dmam_* with a non PCI device Seems to be some kind of AMD64 specific DMA mapping bug ? - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
Hi! > >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether > >> it spins down the disk correctly. Does emergency unload count increase > >> after each power down? Also, please post the result of 'dmidecode'. > > > > I know that my Compaq X1000-series laptop does do some kind of ACPI > > games with the disk on ACPI power off (I assume it is putting the disk > > in standby before power-off at least). It also does this if you boot > > into DOS, GRUB, etc. and then hit the power button. Could be if the disk > > is dumb enough to spin up for sync cache and standby when there is > > nothing to flush, and the kernel does its own standby, this could cause > > an extra spinup/down.. > > Yeah, that seems to be what's going on. I don't think we have any other > choice than blacklisting those notebooks. This is a mess. How does the > other OS cope with this? > > I'm thinking about using DMI vendor/product match to detect the affected > systems but I think it would be better to match the ACPI implementation > directly. Is there a way to match specific ACPI implementation? Well.. unless they use some SMM trick, it is ACPI AML code telling kernel to spin the disk down. I guess we could detect that, and simply ignore the request. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
Hi! > > firmwarekit-discuss <[EMAIL PROTECTED]> (added to CC list) > > see: http://linuxfirmwarekit.org/ > > > > But if I understand this problem right, this won't be easy. > > The ACPI tables are just parsed with system ("iasl ...") and syntactical > > errors/warnings are printed out. > > I also thought about a test, interpreting the DSDT and read out values > > of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is > > not designed for that atm. You need to compile in most parts of the > > acpica code and parse and interpret DSDT/SSDT code yourself in the > > firmwarekit core or inside a plugin, then do a walk_namespace call or > > whatever to find the functions/parts you like to examine. This is a lot > > work and needs a proper design (providing an interface to plugins to let > > them easily check specific AML/ASL code). > > Furthermore, we don't really know what we're looking for. How can you > tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or > trying to power the machine off? Adding to the fun, many modern ATA > controller have more than one way to issue a command. Maybe we can > match accesses inside regions specified by PCI BARs :-( Hmmm... perhaps we should do it the other way. ACPI is allowed to touch the embedded controller, what else? Maybe we should warn as soon as API touches non-EC I/O port? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Thu, 2007-08-09 at 15:16 +, Pavel Machek wrote: > Hi! > > > > firmwarekit-discuss <[EMAIL PROTECTED]> (added to CC list) > > > see: http://linuxfirmwarekit.org/ > > > > > > But if I understand this problem right, this won't be easy. > > > The ACPI tables are just parsed with system ("iasl ...") and syntactical > > > errors/warnings are printed out. > > > I also thought about a test, interpreting the DSDT and read out values > > > of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is > > > not designed for that atm. You need to compile in most parts of the > > > acpica code and parse and interpret DSDT/SSDT code yourself in the > > > firmwarekit core or inside a plugin, then do a walk_namespace call or > > > whatever to find the functions/parts you like to examine. This is a lot > > > work and needs a proper design (providing an interface to plugins to let > > > them easily check specific AML/ASL code). > > > > Furthermore, we don't really know what we're looking for. How can you > > tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or > > trying to power the machine off? Adding to the fun, many modern ATA > > controller have more than one way to issue a command. Maybe we can > > match accesses inside regions specified by PCI BARs :-( > > Hmmm... perhaps we should do it the other way. ACPI is allowed to > touch the embedded controller, what else? Maybe we should warn as soon > as API touches non-EC I/O port? This is not working... ACPI can and does access all kind of other I/O ports and other resources. Hmm, are the disk accesses done by ACPI via OperationRegion/Field declared variables? I try to get a check for those clashing with native drivers (hopefully this approach is successful for 2.6.24, can't say for sure yet), I wonder whether this one would give a warning like "Libata driver is using the same SystemIO/SystemMem resources than ACPI OperationRegion declaration XY". This would not solve the problem, but at least show the need of such a test. Such ACPI vs native driver interference problems are very hard nuts (in identifying and solving). Can someone post an ASL code snippet how ACPI actually access the disk and in which parts/functions, pls. Thanks, Thomas - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
pata error messages?
I'm trying to figure out what could cause the following error messages. This is on a PPC host using a ULI 1575 southbridge: - k ata5: PATA max UDMA/133 cmd 0xfdfee300 ctl 0xfdfee30a bmdma 0xfdfee320 irq 6 ata6: PATA max UDMA/133 cmd 0xfdfee310 ctl 0xfdfee31a bmdma 0xfdfee328 irq 6 ata5.00: ATAPI: SONYDVD RW AW-Q170A, 1.72, max UDMA/66 ata5.00: configured for UDMA/66 ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/66 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/66 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/66 ata5: EH complete ata5.00: limiting speed to UDMA/44:PIO4 ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/44 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/44 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/44 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/44 ata5: EH complete ata5.00: limiting speed to UDMA/33:PIO4 ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/33 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/33 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/33 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/33 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/33 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/33 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/33 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/33 ata5: EH complete ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata
Re: [patch 2/4] Expose Power Management Policy option to users
On Wed, 1 Aug 2007 14:16:51 -0700 Kristen Carlson Accardi <[EMAIL PROTECTED]> wrote: > I was able to duplicate Tejun's problem on an ATAPI device I had here. > this updated patch fixed my problem. These devices are just setting > PhyReady (N) and CommWake (W) in Serror on power state changes, ignoring > them seems to be fine, and fixed the problem for me. Hi Tejun, Were you able to test out this patch and see if it solved your ATAPI device/ALPM issues? Thanks, Kristen > > > Enable Aggressive Link Power management for AHCI controllers. > > This patch will set the correct bits to turn on Aggressive > Link Power Management (ALPM) for the ahci driver. This > will cause the controller and disk to negotiate a lower > power state for the link when there is no activity (see > the AHCI 1.x spec for details). This feature is mutually > exclusive with Hot Plug, so when ALPM is enabled, Hot Plug > is disabled. ALPM will be enabled by default, but it is > settable via the scsi host syfs interface. Possible > settings for this feature are: > > Setting Effect > -- > min_power ALPM is enabled, and link set to enter > lowest power state (SLUMBER) when idle > Hot plug not allowed. > > max_performance ALPM is disabled, Hot Plug is allowed > > medium_power ALPM is enabled, and link set to enter > second lowest power state (PARTIAL) when > idle. Hot plug not allowed. > > Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> > > Index: 2.6-git/drivers/ata/ahci.c > === > --- 2.6-git.orig/drivers/ata/ahci.c > +++ 2.6-git/drivers/ata/ahci.c > @@ -48,6 +48,9 @@ > #define DRV_NAME "ahci" > #define DRV_VERSION "2.3" > > +static int ahci_enable_alpm(struct ata_port *ap, > + enum link_pm policy); > +static int ahci_disable_alpm(struct ata_port *ap); > > enum { > AHCI_PCI_BAR= 5, > @@ -98,6 +101,7 @@ enum { > /* HOST_CAP bits */ > HOST_CAP_SSC= (1 << 14), /* Slumber capable */ > HOST_CAP_CLO= (1 << 24), /* Command List Override support */ > + HOST_CAP_ALPM = (1 << 26), /* Aggressive Link PM support */ > HOST_CAP_SSS= (1 << 27), /* Staggered Spin-up */ > HOST_CAP_SNTF = (1 << 29), /* SNotification register */ > HOST_CAP_NCQ= (1 << 30), /* Native Command Queueing */ > @@ -153,6 +157,8 @@ enum { > PORT_IRQ_PIOS_FIS | PORT_IRQ_D2H_REG_FIS, > > /* PORT_CMD bits */ > + PORT_CMD_ASP= (1 << 27), /* Aggressive Slumber/Partial */ > + PORT_CMD_ALPE = (1 << 26), /* Aggressive Link PM enable */ > PORT_CMD_ATAPI = (1 << 24), /* Device is ATAPI */ > PORT_CMD_LIST_ON= (1 << 15), /* cmd list DMA engine running */ > PORT_CMD_FIS_ON = (1 << 14), /* FIS DMA engine running */ > @@ -244,6 +250,11 @@ static int ahci_pci_device_suspend(struc > static int ahci_pci_device_resume(struct pci_dev *pdev); > #endif > > +static struct class_device_attribute *ahci_shost_attrs[] = { > + &class_device_attr_link_power_management_policy, > + NULL > +}; > + > static struct scsi_host_template ahci_sht = { > .module = THIS_MODULE, > .name = DRV_NAME, > @@ -261,6 +272,7 @@ static struct scsi_host_template ahci_sh > .slave_configure= ata_scsi_slave_config, > .slave_destroy = ata_scsi_slave_destroy, > .bios_param = ata_std_bios_param, > + .shost_attrs= ahci_shost_attrs, > }; > > static const struct ata_port_operations ahci_ops = { > @@ -292,6 +304,8 @@ static const struct ata_port_operations > .port_suspend = ahci_port_suspend, > .port_resume= ahci_port_resume, > #endif > + .enable_pm = ahci_enable_alpm, > + .disable_pm = ahci_disable_alpm, > > .port_start = ahci_port_start, > .port_stop = ahci_port_stop, > @@ -778,6 +792,156 @@ static void ahci_power_up(struct ata_por > writel(cmd | PORT_CMD_ICC_ACTIVE, port_mmio + PORT_CMD); > } > > +static int ahci_disable_alpm(struct ata_port *ap) > +{ > + void __iomem *port_mmio = ahci_port_base(ap); > + u32 cmd, scontrol; > + struct ahci_port_priv *pp = ap->private_data; > + > + /* > + * disable Interface Power Management State Transitions > + * This is accomplished by setting bits 8:11 of the > + * SATA Control register > + */ > + scontrol = readl(port_mmio + PORT_SCR_CTL); > + scontrol |= (0x3 << 8); > + writel(scontrol, port_mmio + PORT_SCR_CTL); > + > + /* get the existing command bits */ > + cmd = readl(port_mmio + PORT_CMD); > + > + /* disable ALPM and A
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
On Thu, Aug 09, 2007 at 02:53:36PM +0100, Alan Cox wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=8424 - patch review > > This one is on Alan. > > I think not - something horrible is happening in dma_alloc_coherent when > called from dmam_* with a non PCI device > > > Seems to be some kind of AMD64 specific DMA mapping bug ? I think it's dev->dma_mask == NULL. Clearly you're passing a non DMA able device to dma_alloc_coherent(). Which seems like a caller bug. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pata error messages?
On Thu, 9 Aug 2007 10:59:12 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote: > I'm trying to figure out what could cause the following error > messages. This is on a PPC host using a ULI 1575 southbridge: I'm still chasing problems with ATAPI DMA on some ALi host bridges. I'd like to say I knew what was going on but the truth is I'm currently diffing lspci out and staring at spec sheets with little result. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
> > Seems to be some kind of AMD64 specific DMA mapping bug ? > > I think it's dev->dma_mask == NULL. Clearly you're passing a non DMA > able device to dma_alloc_coherent(). Which seems like a caller bug. Ok - other archs seem to just return NULL in this case. If its your view that dma_alloc_coherent(dev) should explode not return NULL then we can wrap dma_alloc_coherent but I'm not sure the caller library has any business knowing whether a specific class of device is DMA capable on a specific platform ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pata error messages?
On Aug 9, 2007, at 12:17 PM, Alan Cox wrote: On Thu, 9 Aug 2007 10:59:12 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote: I'm trying to figure out what could cause the following error messages. This is on a PPC host using a ULI 1575 southbridge: I'm still chasing problems with ATAPI DMA on some ALi host bridges. I'd like to say I knew what was going on but the truth is I'm currently diffing lspci out and staring at spec sheets with little result. yeah, the ALi spec I have for 1575 is terse at best. I'd be interested in possible register dumps, I'm not sure if we are even setting up the controllers properly or not. - k - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
On Thu, Aug 09, 2007 at 06:21:01PM +0100, Alan Cox wrote: > > > Seems to be some kind of AMD64 specific DMA mapping bug ? > > > > I think it's dev->dma_mask == NULL. Clearly you're passing a non DMA > > able device to dma_alloc_coherent(). Which seems like a caller bug. > > Ok - other archs seem to just return NULL in this case. If its your view Ok then the initialization would fail. I could do that, but clearly there must be some other bug in the process that tries to do DMA on such random devices in the first place. > that dma_alloc_coherent(dev) should explode not return NULL then we can > wrap dma_alloc_coherent but I'm not sure the caller library has any > business knowing whether a specific class of device is DMA capable on a > specific platform ? Someone must ask that caller library to DMA to/from that device in the first place. Whoever it is it is wrong. Or perhaps you got the wrong device here? For ISA devices we traditionally used NULL. Or if you set up your own ISA devices (which I can't see a reason for but there might be one I'm missing) at least give them a dma mask. Then it should probably work on x86-64. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
> Someone must ask that caller library to DMA to/from that device > in the first place. Whoever it is it is wrong. No I disagree. > Or perhaps you got the wrong device here? For ISA devices we > traditionally used NULL. Or if you set up your own ISA devices > (which I can't see a reason for but there might be one I'm missing) > at least give them a dma mask. Then it should probably work on x86-64. The libata code currently (and this seems to work for all but x86-64) does the following if it is setting up a potentially DMA capable device - Allocate a dma_coherent buffer - If it is refused then turn off DMA and use PIO It has no idea whether a pcmcia, isa, platform or even PCI device happens to be DMA capable, and there are platforms with PCI but very limited DMA for example in the embedded space. In fact it has no idea this level whether it is working a PCI, ISA, PCMCIA, SBUS or some other bus device. It's supposed to be generic code. Obviously doing anything other than dma_alloc_coherent if the allocation fails is stupid but trying to allocate dma memory to find out if the device can be used with DMA on a given platform is quite logical and sensible in some cases. Thus I think dma_alloc_coherent() for an ISA, PCMCIA or other class (platform particularly) shouldn't explode on AMD64 but simply return NULL. Its a sane request to make when you don't in your library know what dev is. Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Thursday, 9 August 2007 17:06, Pavel Machek wrote: > Hi! > > > >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether > > >> it spins down the disk correctly. Does emergency unload count increase > > >> after each power down? Also, please post the result of 'dmidecode'. > > > > > > I know that my Compaq X1000-series laptop does do some kind of ACPI > > > games with the disk on ACPI power off (I assume it is putting the disk > > > in standby before power-off at least). It also does this if you boot > > > into DOS, GRUB, etc. and then hit the power button. Could be if the disk > > > is dumb enough to spin up for sync cache and standby when there is > > > nothing to flush, and the kernel does its own standby, this could cause > > > an extra spinup/down.. > > > > Yeah, that seems to be what's going on. I don't think we have any other > > choice than blacklisting those notebooks. This is a mess. How does the > > other OS cope with this? > > > > I'm thinking about using DMI vendor/product match to detect the affected > > systems but I think it would be better to match the ACPI implementation > > directly. Is there a way to match specific ACPI implementation? > > Well.. unless they use some SMM trick, it is ACPI AML code telling > kernel to spin the disk down. I guess we could detect that, and simply > ignore the request. Please see: http://lkml.org/lkml/2007/8/8/187 Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
On Thu, Aug 09, 2007 at 06:53:10PM +0100, Alan Cox wrote: > > Or perhaps you got the wrong device here? For ISA devices we > > traditionally used NULL. Or if you set up your own ISA devices > > (which I can't see a reason for but there might be one I'm missing) > > at least give them a dma mask. Then it should probably work on x86-64. > > The libata code currently (and this seems to work for all but x86-64) > does the following if it is setting up a potentially DMA capable device Where does the device come from? What device is it? Is that known already? > Thus I think dma_alloc_coherent() for an ISA, PCMCIA or other class > (platform particularly) shouldn't explode on AMD64 but simply return > NULL. Its a sane request to make when you don't in your library know what > dev is. But at least on x86-64 the device is likely DMA capable. At least PCMCIA usually is. Near all devices are DMA capable, except perhaps SMBus and some real oddballs. So the device should not have a NULL dma_mask in the first place. Or it is the wrong device. e.g. we have platform devices for things like timers etc. which are really not DMA capable because it doesn't make much sense to DMA your timer; but there should be really no reason to use such a device in a libata driver. If it's some kind of PCMCIA device like implied by pata_pcmcia then it's likely DMA capable. So if I return NULL then either a really DMA capable device will not work. Or you got a real oddball device that you shouldn't have gotten in the first place. Perhaps the PCMCIA code sets up some of its devices wrong? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.22.2 review 06/84] Add a PCI ID for santa rosas PATA controller.
On Wed, 8 Aug 2007 01:39:12 +0200 Chr <[EMAIL PROTECTED]> wrote: > On Tuesday, 7. August 2007, Greg KH wrote: > > > > From: Christian Lamparter <[EMAIL PROTECTED]> > > > > This is commit c1e6f28cc5de37dcd113b9668a185c0b9334ba8a which is > > merged during 23-rc1 window. Considering the popularity of these > > chips, I think including it in -stable release would be good idea. > > > > Signed-off-by: Christian Lamparter <[EMAIL PROTECTED]> > > Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> > > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > > > I did not receive any complains. I guess it's stable enough for -stable ;-) > ... > > --- > > Not OT: > > There is another outstanding issue with ata_piix.c. > Intel has never officially supported anything faster than PATA 100MB/s. > > But, the ata_piix.c driver "define" the ICH5 & ICH7 as UDMA6 (aka 133MB/s) > capable. > [ Well, no one has probably noticed it before, because there is bug in > do_pata_set_dmamode... > Just look at libata_atapiix_enable_real_udma133.patch and you'll see what > wrong with it. ] > > Here are Intel's datasheets for the affected chipsets: > ICH5 Datasheet: http://www.intel.com/design/chipsets/datashts/252516.htm > (See note on page 183: "... the ICH5 supports reads at the maximum rate of > 100MB/s.") > > ICH7 Datasheet: http://www.intel.com/design/chipsets/datashts/307013.htm > (See first note on page 190: "... the ICH7 supports reads at the maximum rate > of 100MB/s.") > > - > > They are two different ways to deal with it: > > - Either - > > 1. replace all ich_pata_133 with ich_pata_100. >(libata_atapiix_disable_udma6.diff - diff from 2.6.22 ) > > - Or - > > 2. keep all ich_pata_133 and fix the bug in "do_pata_set_dmamode". >(libata_atapiix_enable_real_udma133.patch - diff from 2.6.22) >If there are any concerns about the safety of the patch patch: >http://lkml.org/lkml/2007/7/6/292 (It was already tested by an Intel > employee, >but I guess a bit more user input is necessary here... ) > > Both ways have their pros and cons. Unfortunately, I don't have the time to > follow this > discussion right now, so here's a: > > Signed-off-by: Christian Lamparter <[EMAIL PROTECTED]> > (Just in case, if one of the patches really gets merged!) > You kinda hid these patches rather well. I chose option 1. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/11] it8213/piix/slc90e66: remove {it8213,piix,slc90e66}_dma_2_pio()
On Sunday 05 August 2007, Sergei Shtylyov wrote: > Hello. > > Bartlomiej Zolnierkiewicz wrote: > > > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> > > Sigh... when I was talking about getting rid of that function, I meant > that we need to also decouple UltraDMA from PIO -- which is what this patch > misses... Addressed in the follow-up patch. > Actually, I intended to decouple DMA form PIO in this drivers completely > but that would be a next step... DMA and PIO timings are shared on these controllers (except when DTE bit is set, then PIO0 timings are always used and DMA timings are independent)...? Bart - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ide: fix hidden dependencies on CONFIG_IDE_GENERIC
Some host drivers depend on CONFIG_IDE_GENERIC to do the probing but their config options lack explicit dependencies on IDE_GENERIC. In the long-term these host drivers should be fixed to do the probing themselves but for now fix them by making their config options select CONFIG_IDE_GENERIC. Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- arch/cris/arch-v10/drivers/Kconfig |1 + arch/cris/arch-v32/drivers/Kconfig |1 + drivers/ide/Kconfig|9 + 3 files changed, 11 insertions(+) Index: b/arch/cris/arch-v10/drivers/Kconfig === --- a/arch/cris/arch-v10/drivers/Kconfig +++ b/arch/cris/arch-v10/drivers/Kconfig @@ -548,6 +548,7 @@ config ETRAX_IDE select BLK_DEV_IDEDISK select BLK_DEV_IDECD select BLK_DEV_IDEDMA + select IDE_GENERIC help Enable this to get support for ATA/IDE. You can't use parallel ports or SCSI ports Index: b/arch/cris/arch-v32/drivers/Kconfig === --- a/arch/cris/arch-v32/drivers/Kconfig +++ b/arch/cris/arch-v32/drivers/Kconfig @@ -592,6 +592,7 @@ config ETRAX_IDE select BLK_DEV_IDEDISK select BLK_DEV_IDECD select BLK_DEV_IDEDMA + select IDE_GENERIC help Enables the ETRAX IDE driver. Index: b/drivers/ide/Kconfig === --- a/drivers/ide/Kconfig +++ b/drivers/ide/Kconfig @@ -304,6 +304,7 @@ comment "IDE chipset support/bugfixes" config IDE_GENERIC tristate "generic/default IDE chipset support" + default H8300 help If unsure, say N. @@ -352,6 +353,7 @@ config BLK_DEV_CMD640_ENHANCED config BLK_DEV_IDEPNP bool "PNP EIDE support" depends on PNP + select IDE_GENERIC help If you have a PnP (Plug and Play) compatible EIDE card and would like the kernel to automatically detect and activate @@ -858,6 +860,7 @@ config BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ config IDE_ARM def_bool ARM && (ARCH_CLPS7500 || ARCH_RPC || ARCH_SHARK) + select IDE_GENERIC config BLK_DEV_IDE_ICSIDE tristate "ICS IDE interface support" @@ -891,6 +894,7 @@ config BLK_DEV_IDE_BAST config BLK_DEV_GAYLE bool "Amiga Gayle IDE interface support" depends on AMIGA + select IDE_GENERIC help This is the IDE driver for the Amiga Gayle IDE interface. It supports both the `A1200 style' and `A4000 style' of the Gayle IDE interface, @@ -922,6 +926,7 @@ config BLK_DEV_IDEDOUBLER config BLK_DEV_BUDDHA bool "Buddha/Catweasel/X-Surf IDE interface support (EXPERIMENTAL)" depends on ZORRO && EXPERIMENTAL + select IDE_GENERIC help This is the IDE driver for the IDE interfaces on the Buddha, Catweasel and X-Surf expansion boards. It supports up to two interfaces @@ -934,6 +939,7 @@ config BLK_DEV_BUDDHA config BLK_DEV_FALCON_IDE bool "Falcon IDE interface support" depends on ATARI + select IDE_GENERIC help This is the IDE driver for the builtin IDE interface on the Atari Falcon. Say Y if you have a Falcon and want to use IDE devices (hard @@ -943,6 +949,7 @@ config BLK_DEV_FALCON_IDE config BLK_DEV_MAC_IDE bool "Macintosh Quadra/Powerbook IDE interface support" depends on MAC + select IDE_GENERIC help This is the IDE driver for the builtin IDE interface on some m68k Macintosh models. It supports both the `Quadra style' (used in @@ -956,6 +963,7 @@ config BLK_DEV_MAC_IDE config BLK_DEV_Q40IDE bool "Q40/Q60 IDE interface support" depends on Q40 + select IDE_GENERIC help Enable the on-board IDE controller in the Q40/Q60. This should normally be on; disable it only if you are running a custom hard @@ -964,6 +972,7 @@ config BLK_DEV_Q40IDE config BLK_DEV_MPC8xx_IDE bool "MPC8xx IDE support" depends on 8xx && IDE=y && BLK_DEV_IDE=y + select IDE_GENERIC help This option provides support for IDE on Motorola MPC8xx Systems. Please see 'Type of MPC8xx IDE interface' for details. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] it8213/piix/slc90e66: "de-couple" PIO and UDMA modes
Don't force PIO4 when programming UDMA mode (suggested by Sergei). Cc: Sergei Shtylyov <[EMAIL PROTECTED]> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- drivers/ide/pci/it8213.c |9 - drivers/ide/pci/piix.c | 11 +-- drivers/ide/pci/slc90e66.c | 10 -- 3 files changed, 13 insertions(+), 17 deletions(-) Index: b/drivers/ide/pci/it8213.c === --- a/drivers/ide/pci/it8213.c +++ b/drivers/ide/pci/it8213.c @@ -93,7 +93,7 @@ static void it8213_set_dma_mode(ide_driv int w_flag = 0x10 << drive->dn; int u_speed = 0; u16 reg4042, reg4a; - u8 reg48, reg54, reg55, pio; + u8 reg48, reg54, reg55; pci_read_config_word(dev, maslave, ®4042); pci_read_config_byte(dev, 0x48, ®48); @@ -134,10 +134,9 @@ static void it8213_set_dma_mode(ide_driv pci_write_config_byte(dev, 0x54, reg54 | v_flag); } else pci_write_config_byte(dev, 0x54, reg54 & ~v_flag); - - pio = 4; } else { const u8 mwdma_to_pio[] = { 0, 3, 4 }; + u8 pio; if (reg48 & u_flag) pci_write_config_byte(dev, 0x48, reg48 & ~u_flag); @@ -152,9 +151,9 @@ static void it8213_set_dma_mode(ide_driv pio = mwdma_to_pio[speed - XFER_MW_DMA_0]; else pio = 2; /* only SWDMA2 is allowed */ - } - it8213_set_pio_mode(drive, pio); + it8213_set_pio_mode(drive, pio); + } } /** Index: b/drivers/ide/pci/piix.c === --- a/drivers/ide/pci/piix.c +++ b/drivers/ide/pci/piix.c @@ -1,5 +1,5 @@ /* - * linux/drivers/ide/pci/piix.c Version 0.52Jul 14, 2007 + * linux/drivers/ide/pci/piix.c Version 0.53Aug 9, 2007 * * Copyright (C) 1998-1999 Andrzej Krzysztofowicz, Author and Maintainer * Copyright (C) 1998-2000 Andre Hedrick <[EMAIL PROTECTED]> @@ -194,7 +194,7 @@ static void piix_set_dma_mode(ide_drive_ int u_speed = 0; int sitre; u16 reg4042, reg4a; - u8 reg48, reg54, reg55, pio; + u8 reg48, reg54, reg55; pci_read_config_word(dev, maslave, ®4042); sitre = (reg4042 & 0x4000) ? 1 : 0; @@ -231,10 +231,9 @@ static void piix_set_dma_mode(ide_drive_ pci_write_config_byte(dev, 0x54, reg54 | v_flag); } else pci_write_config_byte(dev, 0x54, reg54 & ~v_flag); - - pio = 4; } else { const u8 mwdma_to_pio[] = { 0, 3, 4 }; + u8 pio; if (reg48 & u_flag) pci_write_config_byte(dev, 0x48, reg48 & ~u_flag); @@ -249,9 +248,9 @@ static void piix_set_dma_mode(ide_drive_ pio = mwdma_to_pio[speed - XFER_MW_DMA_0]; else pio = 2; /* only SWDMA2 is allowed */ - } - piix_set_pio_mode(drive, pio); + piix_set_pio_mode(drive, pio); + } } /** Index: b/drivers/ide/pci/slc90e66.c === --- a/drivers/ide/pci/slc90e66.c +++ b/drivers/ide/pci/slc90e66.c @@ -1,5 +1,5 @@ /* - * linux/drivers/ide/pci/slc90e66.c Version 0.17Aug 2, 2007 + * linux/drivers/ide/pci/slc90e66.c Version 0.18Aug 9, 2007 * * Copyright (C) 2000-2002 Andre Hedrick <[EMAIL PROTECTED]> * Copyright (C) 2006-2007 MontaVista Software, Inc. <[EMAIL PROTECTED]> @@ -82,7 +82,6 @@ static void slc90e66_set_dma_mode(ide_dr int sitre = 0, a_speed = 7 << (drive->dn * 4); int u_speed = 0, u_flag = 1 << drive->dn; u16 reg4042, reg44, reg48, reg4a; - u8 pio; pci_read_config_word(dev, maslave, ®4042); sitre = (reg4042 & 0x4000) ? 1 : 0; @@ -111,10 +110,9 @@ static void slc90e66_set_dma_mode(ide_dr pci_read_config_word(dev, 0x4a, ®4a); pci_write_config_word(dev, 0x4a, reg4a|u_speed); } - - pio = 4; } else { const u8 mwdma_to_pio[] = { 0, 3, 4 }; + u8 pio; if (reg48 & u_flag) pci_write_config_word(dev, 0x48, reg48 & ~u_flag); @@ -125,9 +123,9 @@ static void slc90e66_set_dma_mode(ide_dr pio = mwdma_to_pio[speed - XFER_MW_DMA_0]; else pio = 2; /* only SWDMA2 is allowed */ - } - slc90e66_set_pio_mode(drive, pio); + slc90e66_set_pio_mode(drive, pi
[PATCH 3/4] sis5513: clear prefetch and postwrite for ATAPI devices
Clear prefetch and postwrite for ATAPI devices instead of depending on BIOS. Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- drivers/ide/pci/sis5513.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) Index: b/drivers/ide/pci/sis5513.c === --- a/drivers/ide/pci/sis5513.c +++ b/drivers/ide/pci/sis5513.c @@ -1,5 +1,5 @@ /* - * linux/drivers/ide/pci/sis5513.c Version 0.29Aug 1, 2007 + * linux/drivers/ide/pci/sis5513.c Version 0.30Aug 9, 2007 * * Copyright (C) 1999-2000 Andre Hedrick <[EMAIL PROTECTED]> * Copyright (C) 2002 Lionel Bouton <[EMAIL PROTECTED]>, Maintainer @@ -522,20 +522,19 @@ static void sis_program_timings(ide_driv sis_ata133_program_timings(drive, mode); } -/* Enables per-drive prefetch and postwrite */ static void config_drive_art_rwp (ide_drive_t *drive) { ide_hwif_t *hwif= HWIF(drive); struct pci_dev *dev = hwif->pci_dev; - u8 reg4bh = 0; - u8 rw_prefetch = (0x11 << drive->dn); + u8 rw_prefetch = 0; - if (drive->media != ide_disk) - return; pci_read_config_byte(dev, 0x4b, ®4bh); - if ((reg4bh & rw_prefetch) != rw_prefetch) + if (drive->media == ide_disk) + rw_prefetch = 0x11 << drive->dn; + + if ((reg4bh & (0x11 << drive->dn)) != rw_prefetch) pci_write_config_byte(dev, 0x4b, reg4bh|rw_prefetch); } - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] sis5513: remove /proc/ide/sis
This belongs to user-space (and only if really needed). textdata bss dec hex filename 7129 404 875411d75 drivers/ide/pci/sis5513.o.before 3916 404 1432110e1 drivers/ide/pci/sis5513.o.after Additionaly to being bloat the code contained two bugs: - wrong cable bit was checked (0x0001 instead of 0x8000) on ATA_133 chipsets - incorrect UDMA cycle time was reported on ATA_100a/ATA_133 chipsets Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- drivers/ide/pci/sis5513.c | 249 -- 1 file changed, 1 insertion(+), 248 deletions(-) Index: b/drivers/ide/pci/sis5513.c === --- a/drivers/ide/pci/sis5513.c +++ b/drivers/ide/pci/sis5513.c @@ -1,5 +1,5 @@ /* - * linux/drivers/ide/pci/sis5513.c Version 0.30Aug 9, 2007 + * linux/drivers/ide/pci/sis5513.c Version 0.31Aug 9, 2007 * * Copyright (C) 1999-2000 Andre Hedrick <[EMAIL PROTECTED]> * Copyright (C) 2002 Lionel Bouton <[EMAIL PROTECTED]>, Maintainer @@ -65,8 +65,6 @@ #include "ide-timing.h" -#define DISPLAY_SIS_TIMINGS - /* registers layout and init values are chipset family dependant */ #define ATA_16 0x01 @@ -193,243 +191,6 @@ static char* chipset_capability[] = { "ATA 133 (1st gen)", "ATA 133 (2nd gen)" }; -#if defined(DISPLAY_SIS_TIMINGS) && defined(CONFIG_IDE_PROC_FS) -#include -#include - -static u8 sis_proc = 0; - -static struct pci_dev *bmide_dev; - -static char* cable_type[] = { - "80 pins", - "40 pins" -}; - -static char* recovery_time[] ={ - "12 PCICLK", "1 PCICLK", - "2 PCICLK", "3 PCICLK", - "4 PCICLK", "5 PCICLCK", - "6 PCICLK", "7 PCICLCK", - "8 PCICLK", "9 PCICLCK", - "10 PCICLK", "11 PCICLK", - "13 PCICLK", "14 PCICLK", - "15 PCICLK", "15 PCICLK" -}; - -static char* active_time[] = { - "8 PCICLK", "1 PCICLCK", - "2 PCICLK", "3 PCICLK", - "4 PCICLK", "5 PCICLK", - "6 PCICLK", "12 PCICLK" -}; - -static char* cycle_time[] = { - "Reserved", "2 CLK", - "3 CLK", "4 CLK", - "5 CLK", "6 CLK", - "7 CLK", "8 CLK", - "9 CLK", "10 CLK", - "11 CLK", "12 CLK", - "13 CLK", "14 CLK", - "15 CLK", "16 CLK" -}; - -/* Generic add master or slave info function */ -static char* get_drives_info (char *buffer, u8 pos) -{ - u8 reg00, reg01, reg10, reg11; /* timing registers */ - u32 regdw0, regdw1; - char* p = buffer; - -/* Postwrite/Prefetch */ - if (chipset_family < ATA_133) { - pci_read_config_byte(bmide_dev, 0x4b, ®00); - p += sprintf(p, "Drive %d:Postwrite %s \t \t Postwrite %s\n", -pos, (reg00 & (0x10 << pos)) ? "Enabled" : "Disabled", -(reg00 & (0x40 << pos)) ? "Enabled" : "Disabled"); - p += sprintf(p, "Prefetch %s \t \t Prefetch %s\n", -(reg00 & (0x01 << pos)) ? "Enabled" : "Disabled", -(reg00 & (0x04 << pos)) ? "Enabled" : "Disabled"); - pci_read_config_byte(bmide_dev, 0x40+2*pos, ®00); - pci_read_config_byte(bmide_dev, 0x41+2*pos, ®01); - pci_read_config_byte(bmide_dev, 0x44+2*pos, ®10); - pci_read_config_byte(bmide_dev, 0x45+2*pos, ®11); - } else { - u32 reg54h; - u8 drive_pci = 0x40; - pci_read_config_dword(bmide_dev, 0x54, ®54h); - if (reg54h & 0x4000) { - // Configuration space remapped to 0x70 - drive_pci = 0x70; - } - pci_read_config_dword(bmide_dev, (unsigned long)drive_pci+4*pos, ®dw0); - pci_read_config_dword(bmide_dev, (unsigned long)drive_pci+4*pos+8, ®dw1); - - p += sprintf(p, "Drive %d:\n", pos); - } - - -/* UDMA */ - if (chipset_family >= ATA_133) { - p += sprintf(p, "UDMA %s \t \t \t UDMA %s\n", -(regdw0 & 0x04) ? "Enabled" : "Disabled", -(regdw1 & 0x04) ? "Enabled" : "Disabled"); - p += sprintf(p, "UDMA Cycle Time%s \t UDMA Cycle Time%s\n", -cycle_time[(regdw0 & 0xF0) >> 4], -cycle_time[(regdw1 & 0xF0) >> 4]); - } else if (chipset_family >= ATA_33) { - p += sprintf(p, "UDMA %s \t \t \t UDMA %s\n", -(reg01 & 0x80) ? "Enabled" : "Disabled", -(reg11 & 0x80) ? "Enabled" : "Disabled"); - - p += sprintf(p, "UDMA Cycle Time"); - switch(chipset_family) { - case ATA_33:p += sprintf(p, cycle_time[(reg01 &
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
On Thu, 2007-08-09 at 18:53 +0100, Alan Cox wrote: > > Someone must ask that caller library to DMA to/from that device > > in the first place. Whoever it is it is wrong. > > No I disagree. I'm with Andi here ... you're fortunate that parisc has no working IDE/SATA interface (or rather we have so few running boxes with PCMCIA), but if it did this call sequence would explode on that platform for a different reason. > > Or perhaps you got the wrong device here? For ISA devices we > > traditionally used NULL. Or if you set up your own ISA devices > > (which I can't see a reason for but there might be one I'm missing) > > at least give them a dma mask. Then it should probably work on x86-64. > > The libata code currently (and this seems to work for all but x86-64) > does the following if it is setting up a potentially DMA capable device > > - Allocate a dma_coherent buffer You cannot allocate a dma_coherent buffer without passing in the correct underlying device ... on parisc we'd explode trying to find the iommu to map through (some of our hw has more than one). > - If it is refused then turn off DMA and use PIO > > It has no idea whether a pcmcia, isa, platform or even PCI device happens > to be DMA capable, and there are platforms with PCI but very limited DMA > for example in the embedded space. In fact it has no idea this level > whether it is working a PCI, ISA, PCMCIA, SBUS or some other bus device. > It's supposed to be generic code. > > Obviously doing anything other than dma_alloc_coherent if the allocation > fails is stupid but trying to allocate dma memory to find out if the > device can be used with DMA on a given platform is quite logical and > sensible in some cases. > > Thus I think dma_alloc_coherent() for an ISA, PCMCIA or other class > (platform particularly) shouldn't explode on AMD64 but simply return > NULL. Its a sane request to make when you don't in your library know what > dev is. PCMCIA should be correctly plumbed into the generic model. It's really just a bridge ... how that bridge is wired critically affects how coherent memory is allocated. James - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pata_hpt37x: actually clock HPT374 by 50 MHz DPLL
While at it: On Sunday 05 August 2007, Sergei Shtylyov wrote: > Index: linux-2.6/drivers/ata/pata_hpt37x.c > === > --- linux-2.6.orig/drivers/ata/pata_hpt37x.c > +++ linux-2.6/drivers/ata/pata_hpt37x.c > @@ -8,12 +8,10 @@ this driver is lacking author/maintainer info: /* * Libata driver for the highpoint 37x and 30x UDMA66 ATA controllers. * * This driver is heavily based upon: * * linux/drivers/ide/pci/hpt366.c Version 0.36April 25, 2003 * > * Copyright (C) 1999-2003 Andre Hedrick <[EMAIL PROTECTED]> > * Portions Copyright (C) 2001 Sun Microsystems, Inc. > * Portions Copyright (C) 2003 Red Hat Inc > - * Portions Copyright (C) 2005-2006 MontaVista Software, Inc. > + * Portions Copyright (C) 2005-2007 MontaVista Software, Inc. reference to hpt366 version should also be updated (or removed) > * > * TODO > - * PLL mode > - * Look into engine reset on timeout errors. Should not be > - * required. > + * Look into engine reset on timeout errors. Should not be required. > */ > > #include - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] libata-core: support wildcard matching in ata_blacklist_entry
Support the use of '*' in model_num and model_rev entries in ata_device_blacklist[]. Signed-off-by: Alan Cox <[EMAIL PROTECTED]> Signed-off-by: David Milburn <[EMAIL PROTECTED]> --- libata-core.c | 16 ++-- 1 files changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 60e78be..4603bd9 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -3796,6 +3796,18 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { { } }; +int strn_pattern_cmp(const char *patt, const char *name, int c) +{ + const char *p = strchr(patt, c); + int len; + + if (p == NULL) + len = strlen(name); + else + len = p-patt; + return strncmp(patt, name, len); +} + static unsigned long ata_dev_blacklisted(const struct ata_device *dev) { unsigned char model_num[ATA_ID_PROD_LEN + 1]; @@ -3806,10 +3818,10 @@ static unsigned long ata_dev_blacklisted(const struct ata_device *dev) ata_id_c_string(dev->id, model_rev, ATA_ID_FW_REV, sizeof(model_rev)); while (ad->model_num) { - if (!strcmp(ad->model_num, model_num)) { + if (!strn_pattern_cmp(ad->model_num, model_num, '*')) { if (ad->model_rev == NULL) return ad->horkage; - if (!strcmp(ad->model_rev, model_rev)) + if (!strn_pattern_cmp(ad->model_rev, model_rev, '*')) return ad->horkage; } ad++; - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
sata_promise: Warning/Errors with SATA300 TX4 and SAMSUNG HD501LJ
Hello, I'm using a Promise SATA300 TX4 with SAMSUNG HD501LJ harddisks on kernel 2.6.21. On high disk load sometimes warning/error messages are printed out: ... ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata4.00: cmd c8/00:08:8f:7f:85/00:00:00:00:00/ef tag 0 cdb 0x0 data 4096 in res 50/00:00:96:7f:85/00:00:11:00:00/ef Emask 0x1 (device error) ata4.00: configured for UDMA/133 ata4: EH complete ... They are not happening very often (three in the last few days) and also no other problems occured (filesystem/data ok). dmesg: ... scsi0 : sata_promise ata1: SATA link down (SStatus 0 SControl 300) scsi1 : sata_promise ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-8: SAMSUNG HD501LJ, CR100-10, max UDMA7 ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32) ata2.00: configured for UDMA/133 scsi2 : sata_promise ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.00: ATA-8: SAMSUNG HD501LJ, CR100-10, max UDMA7 ata3.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32) ata3.00: configured for UDMA/133 scsi3 : sata_promise ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.00: ATA-8: SAMSUNG HD501LJ, CR100-10, max UDMA7 ata4.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32) ata4.00: configured for UDMA/133 scsi 1:0:0:0: Direct-Access ATA SAMSUNG HD501LJ CR10 PQ: 0 ANSI: 5 sd 1:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB) sd 1:0:0:0: [sda] Write Protect is off sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB) sd 1:0:0:0: [sda] Write Protect is off sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sd 1:0:0:0: [sda] Attached SCSI disk sd 1:0:0:0: Attached scsi generic sg0 type 0 scsi 2:0:0:0: Direct-Access ATA SAMSUNG HD501LJ CR10 PQ: 0 ANSI: 5 sd 2:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 2:0:0:0: [sdb] Attached SCSI disk sd 2:0:0:0: Attached scsi generic sg1 type 0 scsi 3:0:0:0: Direct-Access ATA SAMSUNG HD501LJ CR10 PQ: 0 ANSI: 5 sd 3:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB) sd 3:0:0:0: [sdc] Write Protect is off sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB) sd 3:0:0:0: [sdc] Write Protect is off sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sd 3:0:0:0: [sdc] Attached SCSI disk sd 3:0:0:0: Attached scsi generic sg2 type 0 ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata4.00: cmd 25/00:28:d7:51:a5/00:00:11:00:00/e0 tag 0 cdb 0x0 data 20480 in res 50/00:00:fe:51:a5/00:00:11:00:00/e0 Emask 0x1 (device error) ata4.00: configured for UDMA/133 ata4: EH complete sd 3:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB) sd 3:0:0:0: [sdc] Write Protect is off sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata4.00: cmd c8/00:08:8f:7f:85/00:00:00:00:00/ef tag 0 cdb 0x0 data 4096 in res 50/00:00:96:7f:85/00:00:11:00:00/ef Emask 0x1 (device error) ata4.00: configured for UDMA/133 ata4: EH complete sd 3:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB) sd 3:0:0:0: [sdc] Write Protect is off sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: cmd 25/00:80:2f:fd:c2/00:00:1a:00:00/e0 tag 0 cdb 0x0 data 65536 in res 50/00:00:ae:fd:c2/00:00:1a:00:00/e0 Emask 0x1 (device error) ata3.00: configured for UDMA/133 ata3: EH complete sd 2:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Some ideas? Not optimal/not good/bad/very bad? Regards, Sebastian - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pata_artop: fix UDMA5 for AEC6280[R] and UDMA6 for AEC6880[R]
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4) and for AEC6880[R] it is UDMA6 (not UDMA5): * Fix the problem by adding missing struct ata_port_info to artop_init_one(). * Use the right naming (s/626/628/). * Bump driver version. Fixes IDE->libata regression, problem was never present in IDE aec62xx driver. Cc: Alan Cox <[EMAIL PROTECTED]> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- drivers/ata/pata_artop.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) Index: b/drivers/ata/pata_artop.c === --- a/drivers/ata/pata_artop.c +++ b/drivers/ata/pata_artop.c @@ -2,6 +2,7 @@ *pata_artop.c - ARTOP ATA controller driver * * (C) 2006 Red Hat <[EMAIL PROTECTED]> + * (C) 2007 Bartlomiej Zolnierkiewicz * *Based in part on drivers/ide/pci/aec62xx.c * Copyright (C) 1999-2002 Andre Hedrick <[EMAIL PROTECTED]> @@ -28,7 +29,7 @@ #include #define DRV_NAME "pata_artop" -#define DRV_VERSION"0.4.3" +#define DRV_VERSION"0.4.4" /* * The ARTOP has 33 Mhz and "over clocked" timing tables. Until we @@ -430,7 +431,7 @@ static int artop_init_one (struct pci_de .udma_mask = ATA_UDMA4, .port_ops = &artop6260_ops, }; - static const struct ata_port_info info_626x_fast = { + static const struct ata_port_info info_628x = { .sht= &artop_sht, .flags = ATA_FLAG_SLAVE_POSS, .pio_mask = 0x1f, /* pio0-4 */ @@ -438,6 +439,14 @@ static int artop_init_one (struct pci_de .udma_mask = ATA_UDMA5, .port_ops = &artop6260_ops, }; + static const struct ata_port_info info_628x_fast = { + .sht= &artop_sht, + .flags = ATA_FLAG_SLAVE_POSS, + .pio_mask = 0x1f, /* pio0-4 */ + .mwdma_mask = 0x07, /* mwdma0-2 */ + .udma_mask = ATA_UDMA6, + .port_ops = &artop6260_ops, + }; const struct ata_port_info *ppi[] = { NULL, NULL }; if (!printed_version++) @@ -455,13 +464,13 @@ static int artop_init_one (struct pci_de } else if (id->driver_data == 1) /* 6260 */ ppi[0] = &info_626x; - else if (id->driver_data == 2) { /* 6260 or 6260 + fast */ + else if (id->driver_data == 2) { /* 6280 or 6280 + fast */ unsigned long io = pci_resource_start(pdev, 4); u8 reg; - ppi[0] = &info_626x; + ppi[0] = &info_628x; if (inb(io) & 0x10) - ppi[0] = &info_626x_fast; + ppi[0] = &info_628x_fast; /* Mac systems come up with some registers not set as we will need them */ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 0/4] Updated SATA Link Power Management patches
Hello, Here are some updated ALPM patches. These patches are different from the last version in that they now use the error handler to enable link power management. Please review and let me know what you think. Kristen -- - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/4] Store interrupt value
Use a stored value for which interrupts to enable. Changing this allows us to selectively turn off certain interrupts later and have them stay off. Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> Index: 2.6-git/drivers/ata/ahci.c === --- 2.6-git.orig/drivers/ata/ahci.c +++ 2.6-git/drivers/ata/ahci.c @@ -175,6 +175,7 @@ enum { AHCI_FLAG_32BIT_ONLY= (1 << 28), /* force 32bit */ AHCI_FLAG_MV_PATA = (1 << 29), /* PATA port */ AHCI_FLAG_NO_MSI= (1 << 30), /* no PCI MSI */ + AHCI_FLAG_NO_HOTPLUG= (1 << 31), /* ignore PxSERR.DIAG.N */ AHCI_FLAG_COMMON= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY | ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA | @@ -215,6 +216,7 @@ struct ahci_port_priv { unsigned intncq_saw_d2h:1; unsigned intncq_saw_dmas:1; unsigned intncq_saw_sdb:1; + u32 intr_mask; /* interrupts to enable */ }; static int ahci_scr_read(struct ata_port *ap, unsigned int sc_reg, u32 *val); @@ -1518,6 +1520,7 @@ static void ahci_thaw(struct ata_port *a void __iomem *mmio = ap->host->iomap[AHCI_PCI_BAR]; void __iomem *port_mmio = ahci_port_base(ap); u32 tmp; + struct ahci_port_priv *pp = ap->private_data; /* clear IRQ */ tmp = readl(port_mmio + PORT_IRQ_STAT); @@ -1525,7 +1528,7 @@ static void ahci_thaw(struct ata_port *a writel(1 << ap->port_no, mmio + HOST_IRQ_STAT); /* turn IRQ back on */ - writel(DEF_PORT_IRQ, port_mmio + PORT_IRQ_MASK); + writel(pp->intr_mask, port_mmio + PORT_IRQ_MASK); } static void ahci_error_handler(struct ata_port *ap) @@ -1679,6 +1682,12 @@ static int ahci_port_start(struct ata_po pp->cmd_tbl = mem; pp->cmd_tbl_dma = mem_dma; + /* +* Save off initial list of interrupts to be enabled. +* This could be changed later +*/ + pp->intr_mask = DEF_PORT_IRQ; + ap->private_data = pp; /* engage engines, captain */ -- - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/4] increase number of allowable device flags
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> Index: 2.6-git/include/linux/libata.h === --- 2.6-git.orig/include/linux/libata.h +++ 2.6-git/include/linux/libata.h @@ -139,7 +139,7 @@ enum { ATA_DFLAG_FLUSH_EXT = (1 << 4), /* do FLUSH_EXT instead of FLUSH */ ATA_DFLAG_ACPI_PENDING = (1 << 5), /* ACPI resume action pending */ ATA_DFLAG_ACPI_FAILED = (1 << 6), /* ACPI on devcfg has failed */ - ATA_DFLAG_CFG_MASK = (1 << 8) - 1, + ATA_DFLAG_CFG_MASK = (1 << 12) - 1, ATA_DFLAG_PIO = (1 << 8), /* device limited to PIO mode */ ATA_DFLAG_NCQ_OFF = (1 << 9), /* device limited to non-NCQ mode */ -- - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/4] Enable link power management for ata drivers
libata drivers can define a function (enable_pm) that will perform hardware specific actions to enable whatever power management policy the user set up from the scsi sysfs interface if the driver supports it. This power management policy will be activated after all disks have been enumerated and intialized. Drivers should also define disable_pm, which will turn off link power management, but not change link power management policy. Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> Index: 2.6-git/drivers/ata/libata-scsi.c === --- 2.6-git.orig/drivers/ata/libata-scsi.c +++ 2.6-git/drivers/ata/libata-scsi.c @@ -110,6 +110,78 @@ static struct scsi_transport_template at .user_scan = ata_scsi_user_scan, }; +static const struct { + enum link_pmvalue; + char*name; +} link_pm_policy[] = { + { NOT_AVAILABLE, "max_performance" }, + { MIN_POWER, "min_power" }, + { MAX_PERFORMANCE, "max_performance" }, + { MEDIUM_POWER, "medium_power" }, +}; + +const char *ata_scsi_link_pm_policy(enum link_pm policy) +{ + int i; + char *name = NULL; + + for (i = 0; i < ARRAY_SIZE(link_pm_policy); i++) { + if (link_pm_policy[i].value == policy) { + name = link_pm_policy[i].name; + break; + } + } + return name; +} + +static ssize_t store_link_pm_policy(struct class_device *class_dev, + const char *buf, size_t count) +{ + struct Scsi_Host *shost = class_to_shost(class_dev); + struct ata_port *ap = ata_shost_to_port(shost); + enum link_pm policy = 0; + int i; + + /* +* we are skipping array location 0 on purpose - this +* is because a value of NOT_AVAILABLE is displayed +* to the user as max_performance, but when the user +* writes "max_performance", they actually want the +* value to match MAX_PERFORMANCE. +*/ + for (i = 1; i < ARRAY_SIZE(link_pm_policy); i++) { + const int len = strlen(link_pm_policy[i].name); + if (strncmp(link_pm_policy[i].name, buf, len) == 0 && + buf[len] == '\n') { + policy = link_pm_policy[i].value; + break; + } + } + if (!policy) + return -EINVAL; + + if (ata_scsi_set_link_pm_policy(ap, policy)) + return -EINVAL; + return count; +} + +static ssize_t +show_link_pm_policy(struct class_device *class_dev, char *buf) +{ + struct Scsi_Host *shost = class_to_shost(class_dev); + struct ata_port *ap = ata_shost_to_port(shost); + const char *policy = + ata_scsi_link_pm_policy(ap->pm_policy); + + if (!policy) + return -EINVAL; + + return snprintf(buf, 23, "%s\n", policy); +} +CLASS_DEVICE_ATTR(link_power_management_policy, S_IRUGO | S_IWUSR, + show_link_pm_policy, store_link_pm_policy); +EXPORT_SYMBOL_GPL(class_device_attr_link_power_management_policy); + static void ata_scsi_invalid_field(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *)) { @@ -2904,6 +2976,52 @@ void ata_scsi_simulate(struct ata_device } } +int ata_scsi_set_link_pm_policy(struct ata_port *ap, + enum link_pm policy) +{ + int rc = -EINVAL; + int i; + + /* +* make sure no broken devices are on this port, +* and that all devices support interface power +* management +*/ + for (i = 0; i < ATA_MAX_DEVICES; i++) { + struct ata_device *dev = &ap->device[i]; + + /* only check drives which exist */ + if (!ata_dev_enabled(dev)) + continue; + + /* +* do we need to handle the case where we've hotplugged +* a broken drive (since hotplug and ALPM are mutually +* exclusive) ? +* +* If so, if we detect a broken drive on a port with +* alpm already enabled, then we should reset the policy +* to off for the entire port. +*/ + if ((dev->horkage & ATA_HORKAGE_IPM) || + !(dev->flags & ATA_DFLAG_IPM)) { + ata_dev_printk(dev, KERN_ERR, + "Unable to set Link PM policy\n"); + ap->pm_policy = MAX_PERFORMANCE; + } + } + + if (ap->ops->enable_pm) { + ap->pm_policy = policy; + ap->eh_info.action |= ATA_EHI_LPM; + ap->eh_info.flags |= ATA_EHI_NO_AUTOPSY; + ata_port_schedule_eh(ap); + rc = 0; + } + return rc; +} +EXPORT_SYMBOL_GPL(ata_scsi_set_link_pm_policy); + int ata_scsi_add_hosts(
[patch 4/4] Enable Aggressive Link Power management for AHCI controllers.
This patch will set the correct bits to turn on Aggressive Link Power Management (ALPM) for the ahci driver. This will cause the controller and disk to negotiate a lower power state for the link when there is no activity (see the AHCI 1.x spec for details). This feature is mutually exclusive with Hot Plug, so when ALPM is enabled, Hot Plug is disabled. ALPM will be enabled by default, but it is settable via the scsi host syfs interface. Possible settings for this feature are: Setting Effect -- min_power ALPM is enabled, and link set to enter lowest power state (SLUMBER) when idle Hot plug not allowed. max_performance ALPM is disabled, Hot Plug is allowed medium_powerALPM is enabled, and link set to enter second lowest power state (PARTIAL) when idle. Hot plug not allowed. Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> Index: 2.6-git/drivers/ata/ahci.c === --- 2.6-git.orig/drivers/ata/ahci.c +++ 2.6-git/drivers/ata/ahci.c @@ -48,6 +48,9 @@ #define DRV_NAME "ahci" #define DRV_VERSION"2.3" +static int ahci_enable_alpm(struct ata_port *ap, + enum link_pm policy); +static int ahci_disable_alpm(struct ata_port *ap); enum { AHCI_PCI_BAR= 5, @@ -98,6 +101,7 @@ enum { /* HOST_CAP bits */ HOST_CAP_SSC= (1 << 14), /* Slumber capable */ HOST_CAP_CLO= (1 << 24), /* Command List Override support */ + HOST_CAP_ALPM = (1 << 26), /* Aggressive Link PM support */ HOST_CAP_SSS= (1 << 27), /* Staggered Spin-up */ HOST_CAP_SNTF = (1 << 29), /* SNotification register */ HOST_CAP_NCQ= (1 << 30), /* Native Command Queueing */ @@ -153,6 +157,8 @@ enum { PORT_IRQ_PIOS_FIS | PORT_IRQ_D2H_REG_FIS, /* PORT_CMD bits */ + PORT_CMD_ASP= (1 << 27), /* Aggressive Slumber/Partial */ + PORT_CMD_ALPE = (1 << 26), /* Aggressive Link PM enable */ PORT_CMD_ATAPI = (1 << 24), /* Device is ATAPI */ PORT_CMD_LIST_ON= (1 << 15), /* cmd list DMA engine running */ PORT_CMD_FIS_ON = (1 << 14), /* FIS DMA engine running */ @@ -244,6 +250,11 @@ static int ahci_pci_device_suspend(struc static int ahci_pci_device_resume(struct pci_dev *pdev); #endif +static struct class_device_attribute *ahci_shost_attrs[] = { + &class_device_attr_link_power_management_policy, + NULL +}; + static struct scsi_host_template ahci_sht = { .module = THIS_MODULE, .name = DRV_NAME, @@ -261,6 +272,7 @@ static struct scsi_host_template ahci_sh .slave_configure= ata_scsi_slave_config, .slave_destroy = ata_scsi_slave_destroy, .bios_param = ata_std_bios_param, + .shost_attrs= ahci_shost_attrs, }; static const struct ata_port_operations ahci_ops = { @@ -292,6 +304,8 @@ static const struct ata_port_operations .port_suspend = ahci_port_suspend, .port_resume= ahci_port_resume, #endif + .enable_pm = ahci_enable_alpm, + .disable_pm = ahci_disable_alpm, .port_start = ahci_port_start, .port_stop = ahci_port_stop, @@ -778,6 +792,156 @@ static void ahci_power_up(struct ata_por writel(cmd | PORT_CMD_ICC_ACTIVE, port_mmio + PORT_CMD); } +static int ahci_disable_alpm(struct ata_port *ap) +{ + void __iomem *port_mmio = ahci_port_base(ap); + u32 cmd, scontrol; + struct ahci_port_priv *pp = ap->private_data; + + /* +* disable Interface Power Management State Transitions +* This is accomplished by setting bits 8:11 of the +* SATA Control register +*/ + scontrol = readl(port_mmio + PORT_SCR_CTL); + scontrol |= (0x3 << 8); + writel(scontrol, port_mmio + PORT_SCR_CTL); + + /* get the existing command bits */ + cmd = readl(port_mmio + PORT_CMD); + + /* disable ALPM and ASP */ + cmd &= ~PORT_CMD_ASP; + cmd &= ~PORT_CMD_ALPE; + + /* force the interface back to active */ + cmd |= PORT_CMD_ICC_ACTIVE; + + /* write out new cmd value */ + writel(cmd, port_mmio + PORT_CMD); + cmd = readl(port_mmio + PORT_CMD); + + /* wait 10ms to be sure we've come out of any low power state */ + msleep(10); + + /* clear out any PhyRdy stuff from interrupt status */ + writel(PORT_IRQ_PHYRDY, port_mmio + PORT_IRQ_STAT); + + /* go ahead and clean out PhyRdy Change from Serror too */ + ahci_scr_write(ap, SCR_ERROR, ((1 << 16) | (1 << 18))); + + /* +* Clear flag to in
Re: Disk spin down issue on shut down/suspend to disk
On Wednesday, 8 August 2007 14:24, Rafael J. Wysocki wrote: > On Wednesday, 8 August 2007 04:56, Tejun Heo wrote: > > Rafael J. Wysocki wrote: > > > Well, on my box (nx6325) with the appended (experimental) patch applied > > > on top of 2.6.23-rc1 with the patchset from > > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , > > > the > > > double spin down doesn't occur during hibernation and the system is shut > > > down > > > notceably faster. > > > > Can you please explain what the patch does? > > It replaces the shutting down of devices done by kernel_shutdown_prepare() > with the suspending of the (just like before entering S3, but the target state > is now S4) and the shutting down of sysdevs with suspending them. > > It also disables the nonboot CPUs before entering the sleep state (S4), which > generally always is a good idea. > > In short, it makes hibernation_platform_enter() execute the > enter-a-sleep-state > sequence instead of the mixed shutdown-with-entering-S4 thing. > > > So, I take it that entering S4 also spins down the disk. > > Yes. > > > Does the patch remove the ACPI spin down or libata one? > > I _think_ that it removes the ACPI one, although I'll need to do some more > testing to confirm that. OK I can confirm that the patch removes the ACPI spin down (ie. the one that happens in the power down phase without the patch). Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
> Where does the device come from? What device is it? At the higher level someone passed us a device and some mappings and function methods and said "this is an IDE controller" > Is that known already? The core code has no idea or interest in where it came from. > But at least on x86-64 the device is likely DMA capable. At least > PCMCIA usually is. Near all devices are DMA capable, except perhaps PCMCIA usally isn't. > So if I return NULL then either a really DMA capable device will > not work. Or you got a real oddball device that you shouldn't have gotten > in the first place. What about other platforms ? I don't want libata to have #ifdef CONFIG_X86_64 /* this platform is different) if (hack-around-in-dev-struct()) return NULL; #endif All I want is This is a device, the caller has said it may be DMA capable dma_alloc_coherent NULL. ok in this situation it isn't I don't want to know about arch internals. I don't want to know about platform specific DMA rules. I just want to be able to ask for DMA and get told yes or no. Oops is not a useful error return. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
> You cannot allocate a dma_coherent buffer without passing in the correct > underlying device ... on parisc we'd explode trying to find the iommu to > map through (some of our hw has more than one). We do pass the correct underlying device. Then dma_alloc_coherent oopses on x86_64 if you pass some valid devices (eg pcmcia). - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_artop: fix UDMA5 for AEC6280[R] and UDMA6 for AEC6880[R]
On Thu, 9 Aug 2007 23:19:34 +0200 Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > > Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4) > and for AEC6880[R] it is UDMA6 (not UDMA5): > > * Fix the problem by adding missing struct ata_port_info to artop_init_one(). > > * Use the right naming (s/626/628/). > > * Bump driver version. > > Fixes IDE->libata regression, problem was never present in IDE aec62xx driver. Have you tested this ?? - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
On Thu, 2007-08-09 at 23:37 +0100, Alan Cox wrote: > > You cannot allocate a dma_coherent buffer without passing in the correct > > underlying device ... on parisc we'd explode trying to find the iommu to > > map through (some of our hw has more than one). > > We do pass the correct underlying device. Then dma_alloc_coherent oopses > on x86_64 if you pass some valid devices (eg pcmcia). If the device you're passing has a NULL dma_mask pointer that means the platform hasn't set it up correctly for dma ... and that's the underlying problem (although it's not necessarily a libata problem): you can't call dma_ operations on a device that hasn't been set up in the platform for it. James - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
On Thu, Aug 09, 2007 at 11:34:58PM +0100, Alan Cox wrote: > > Where does the device come from? What device is it? > > At the higher level someone passed us a device and some mappings and > function methods and said "this is an IDE controller" Ok you're stabbing in the dark. I guess more debugging is needed. > > But at least on x86-64 the device is likely DMA capable. At least > > PCMCIA usually is. Near all devices are DMA capable, except perhaps > > PCMCIA usally isn't. Hmm? > I don't want to know about arch internals. I don't want to know about > platform specific DMA rules. I just want to be able to ask for DMA and > get told yes or no. Oops is not a useful error return. I'm not blaming libata here, just whoever gave that bogus device to it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pata_hpt37x: actually clock HPT374 by 50 MHz DPLL
> * This driver is heavily based upon: > * > * linux/drivers/ide/pci/hpt366.c Version 0.36April 25, 2003 > * > reference to hpt366 version should also be updated (or removed) Disagree - its not based on the newer hpt366 driver. Its based on the old one. Actually by now it bears almost no resemblence any of them - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
On Fri, 2007-08-10 at 00:17 +0100, Alan Cox wrote: > > If the device you're passing has a NULL dma_mask pointer that means the > > platform hasn't set it up correctly for dma ... and that's the > > Well it may not do DMA. Unfortunately, I don't think we've considered that possibility in the integration of the dma API and generic devices. > > underlying problem (although it's not necessarily a libata problem): you > > can't call dma_ operations on a device that hasn't been set up in the > > platform for it. > > Right. > > Ok so what is the right way given a random *correctly* set up device that > may or may not be DMA capable to determine this. Its an arbitary device > pointer for an arbitary device class on an arbitary platform which may or > may not support DMA for this device class ? > > Can I called dma_alloc_coherent and get a NULL back or do we need a > device_can_dma() check in each platform ? Fundamentally it's a different question. The dma_alloc is just saying can you set up a coherent memory area that this device can reach. Often the platform cannot necessarily discover this. I'd say the best signal is that the driver has called dma_set_mask(dev, DMA_MASK_NONE) (which isn't defined yet). So the platform has a signal that the device isn't DMA capable. James - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II
> BTW unless I'm misreading the i386 code it'll not fail here, but > allocate memory. Surely that will cause failures later if you > rely on it failing? If you don't rely on it then changing x86-64 > will also not help you. Eww that'll do strange things. Ok so we do in fact need some kind of proper way to ask if a device is DMA capable ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_cmd64x: Set up MWDMA modes properly
On Fri, 10 Aug 2007 01:09:13 +0200 (MEST) Mikael Pettersson <[EMAIL PROTECTED]> wrote: > On Wed, 8 Aug 2007 14:33:20 +0100, Alan Cox wrote: > > Set the MWDMA timing by updating the correct registers. Split the PIO > > path as this is mostly shared code. Wants testing. > > Works fine on my CMD646 SPARC Ultra5. Thanks - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
> If the device you're passing has a NULL dma_mask pointer that means the > platform hasn't set it up correctly for dma ... and that's the Well it may not do DMA. > underlying problem (although it's not necessarily a libata problem): you > can't call dma_ operations on a device that hasn't been set up in the > platform for it. Right. Ok so what is the right way given a random *correctly* set up device that may or may not be DMA capable to determine this. Its an arbitary device pointer for an arbitary device class on an arbitary platform which may or may not support DMA for this device class ? Can I called dma_alloc_coherent and get a NULL back or do we need a device_can_dma() check in each platform ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_cmd64x: Set up MWDMA modes properly
On Wed, 8 Aug 2007 14:33:20 +0100, Alan Cox wrote: > Set the MWDMA timing by updating the correct registers. Split the PIO > path as this is mostly shared code. Wants testing. Works fine on my CMD646 SPARC Ultra5. /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
I'll submit a patch to check this in my next batch. But as James pointed out you'll likely need similar patches on other architectures. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)
> > At the higher level someone passed us a device and some mappings and > > function methods and said "this is an IDE controller" > > Ok you're stabbing in the dark. I guess more debugging is needed. Huh ? > > > But at least on x86-64 the device is likely DMA capable. At least > > > PCMCIA usually is. Near all devices are DMA capable, except perhaps > > > > PCMCIA usally isn't. > > Hmm? PCMCIA is not DMA capable, and indeed passing a pcmcia device to AMD64 boxes dma_alloc_ functions causes an Oops. > I'm not blaming libata here, just whoever gave that bogus device to it. For the simple example the PCMCIA layer. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pata_hpt37x: actually clock HPT374 by 50 MHz DPLL
On Friday 10 August 2007, Alan Cox wrote: > > * This driver is heavily based upon: > > * > > * linux/drivers/ide/pci/hpt366.c Version 0.36April 25, > > 2003 > > * > > reference to hpt366 version should also be updated (or removed) > > > Disagree - its not based on the newer hpt366 driver. Its based on the old But this patch has just updated copyright references to match with the new driver while the version still matches the old one! > one. Actually by now it bears almost no resemblence any of them Indeed, unfortunately... Bart - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problems while mounting /boot partition
On Aug 8 2007 18:28, Michal Piotrowski wrote: > >Hi Brian, > >Brian J. Murrell pisze: >> I am using Ubuntu Gutsy, which is the in-development branch heading for >> their next stable release. > >You forgot about message subject, so no one has read this report. Actually, given the volume on LKML, a line without a subject is making the most attention since all others do have one. :) Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_artop: fix UDMA5 for AEC6280[R] and UDMA6 for AEC6880[R]
On Friday 10 August 2007, Alan Cox wrote: > On Thu, 9 Aug 2007 23:19:34 +0200 > Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > > > > > Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4) > > and for AEC6880[R] it is UDMA6 (not UDMA5): > > > > * Fix the problem by adding missing struct ata_port_info to > > artop_init_one(). > > > > * Use the right naming (s/626/628/). > > > > * Bump driver version. > > > > Fixes IDE->libata regression, problem was never present in IDE aec62xx > > driver. > > Have you tested this ?? -ENODEV so no and testing is welcomed. However I went over both drivers to make sure that this change is safe and correct. BTW presence of the above bugs would strongly indicate that pata_artop has never been tested (properly) with AEC6x80[R], otherwise these bugs should have been noticed and fixed much earlier. Thanks, Bart - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II
BTW unless I'm misreading the i386 code it'll not fail here, but allocate memory. Surely that will cause failures later if you rely on it failing? If you don't rely on it then changing x86-64 will also not help you. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html