lwn.git/drivers/ata/pata_pdc202xx_old.c, branch v4.1-rc1

ata: use CONFIG_PM_SLEEP instead of CONFIG_PM where applicable in host drivers

2014-05-10T02:37:49+00:00

This patch fixes host drivers to use CONFIG_PM_SLEEP instead of CONFIG_PM where applicable. Benefits of this change: * unused code is not being compiled in for CONFIG_PM=y, CONFIG_PM_SLEEP=n and CONFIG_PM_RUNTIME=y configurations * easier transition to use struct dev_pm_ops and SIMPLE_DEV_PM_OPS() in the future * more consistent code (there are host drivers which are using the correct CONFIG_PM_SLEEP checks already) The patch leaves the core libata code and ->port_[suspend,resume] support in sata_[inic162x,nv,sil24].c alone for now. Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Tejun Heo

ata: delete non-required instances of include

2014-02-13T21:40:56+00:00

None of these files are actually using any __init type directives and hence don't need to include . Most are just a left over from __devinit and __cpuinit removal, or simply due to code getting copied from one driver to the next. Cc: linux-ide@vger.kernel.org Signed-off-by: Paul Gortmaker Signed-off-by: Tejun Heo

ata: use module_pci_driver

2012-07-25T19:12:11+00:00

This patch converts the drivers in drivers/ata/* to use module_pci_driver() macro which makes the code smaller and a bit simpler. Signed-off-by: Axel Lin Cc: Alan Cox Cc: Jeff Garzik Cc: Mikael Pettersson Cc: Mark Lord Cc: Jeremy Higdon Cc: Benjamin Herrenschmidt Signed-off-by: Jeff Garzik

pata_pdc202xx_old: implement sff_irq_check() method

2010-10-22T00:21:06+00:00

Signed-off-by: Sergei Shtylyov Signed-off-by: Jeff Garzik

libata-sff: separate out BMDMA init

2010-05-25T23:40:30+00:00

Separate out ata_pci_bmdma_prepare_host() and ata_pci_bmdma_init_one() from their SFF counterparts. SFF ones no longer try to initialize BMDMA or set PCI master. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik

libata-sff: clean up BMDMA initialization

2010-05-19T17:32:19+00:00

When BMDMA initialization failed or BMDMA was not available for whatever reason, bmdma_addr was left at zero and used as an indication that BMDMA shouldn't be used. This leads to the following problems. p1. For BMDMA drivers which don't use traditional BMDMA register, ata_bmdma_mode_filter() incorrectly inhibits DMA modes. Those drivers either have to inherit from ata_sff_port_ops or clear ->mode_filter explicitly. p2. non-BMDMA drivers call into BMDMA PRD table allocation. It doesn't actually allocate PRD table if bmdma_addr is not initialized but is still confusing. p3. For BMDMA drivers which don't use traditional BMDMA register, some methods might not be invoked as expected (e.g. bmdma_stop from ata_sff_post_internal_cmd()). p4. SFF drivers w/ custom DMA interface implement noop BMDMA ops worrying libata core might call into one of them. These problems are caused by the muddy line between SFF and BMDMA and the assumption that all BMDMA controllers initialize bmdma_addr. This patch fixes p1 and p2 by removing the bmdma_addr assumption and moving prd allocation to BMDMA port start. Later patches will fix the remaining issues. This patch improves BMDMA initialization such that * When BMDMA register initialization fails, falls back to PIO instead of failing. ata_pci_bmdma_init() never fails now. * When ata_pci_bmdma_init() falls back to PIO, it clears ap->mwdma_mask and udma_mask instead of depending on ata_bmdma_mode_filter(). This makes ata_bmdma_mode_filter() unnecessary thus resolving p1. * ata_port_start() which actually is BMDMA specific is moved to ata_bmdma_port_start(). ata_port_start() and ata_sff_port_start() are killed. * ata_sff_port_start32() is moved and renamed to ata_bmdma_port_start32(). Drivers which no longer call into PRD table allocation are... pdc_adma, sata_inic162x, sata_qstor, sata_sx4, pata_cmd640 and all drivers which inherit from ata_sff_port_ops. pata_icside sets ->port_start to ATA_OP_NULL as it doesn't need PRD but is a BMDMA controller and doesn't have custom port_start like other such controllers. Note that with the previous patch which makes all and only BMDMA drivers inherit from ata_bmdma_port_ops, this change doesn't break drivers which need PRD table. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik

libata: Pass host flags into the pci helper

2010-03-01T19:58:46+00:00

This allows parallel scan and the like to be set without having to stop using the existing full helper functions. This patch merely adds the argument and fixes up the callers. It doesn't undo the special cases already in the tree or add any new parallel callers. Signed-off-by: Alan Cox Signed-off-by: Jeff Garzik

pata_pdc202xx_old: fix UDMA mode for PDC2026x chipsets

2010-03-01T19:58:46+00:00

PDC2026x chipsets need the same treatment as PDC20246 one. This is completely untested but will hopefully fix UDMA issues that people have been reporting against pata_pdc202xx_old for the last couple of years. Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Jeff Garzik

pata_pdc202xx_old: fix UDMA mode for Promise UDMA33 cards

2010-03-01T19:58:46+00:00

On Monday 04 January 2010 02:30:24 pm Russell King wrote: > Found the problem - getting rid of the read of the alt status register > after the command has been written fixes the UDMA CRC errors on write: > > @@ -676,7 +676,8 @@ void ata_sff_exec_command(struct ata_port *ap, const struct > ata_taskfile *tf) > DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command); > > iowrite8(tf->command, ap->ioaddr.command_addr); > - ata_sff_pause(ap); > + ndelay(400); > +// ata_sff_pause(ap); > } > EXPORT_SYMBOL_GPL(ata_sff_exec_command); > > > This rather makes sense. The PDC20247 handles the UDMA part of the > protocol. It has no way to tell the PDC20246 to wait while it suspends > UDMA, so that a normal register access can take place - the 246 ploughs > on with the register access without any regard to the state of the 247. > > If the drive immediately starts the UDMA protocol after a write to the > command register (as it probably will for the DMA WRITE command), then > we'll be accessing the taskfile in the middle of the UDMA setup, which > can't be good. It's certainly a violation of the ATA specs. Fix it by adding custom ->sff_exec_command method for UDMA33 chipsets. Debugged-by: Russell King Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Jeff Garzik

pata_pdc202xx_old: fix UDMA33 handling

2009-05-11T18:30:07+00:00

The original driver doesn't use 66 MHz clock for UDMA33. [ The alternative solution would be to adjust UDMA33 timings for 66 MHz clock but I think that it is safer to stick with old & tested behavior for now. ] Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Jeff Garzik