PATA fixes
Subsystems (4)
cover PATA fixes
Hi,
I've been going through PATA drivers for the last few days to make sure that we offer similar level of hardware support in the new PATA drivers as with the old IDE subsystem and the following patchset is the end result of said audit.
Inside:
- many bugfixes
( ata_piix, pata_artop, pata_atiixp, pata_efar, pata_cmd64x,
pata_hpt3x3, pata_it8213, pata_legacy, pata_ns87415, pata_sis,
pata_radisys, pata_rz1000 & pata_via )- add Power Management support for more controllers
( pata_artop, pata_pdc2027x, pata_sl82c105 )
- add 32-bit PIO support for more controllers
( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520,
pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x,
pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415,
pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000,
pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105,
pata_sis, pata_triflex & pata_via )- fix QDI65x0 support in pata_legacy driver so pata_qdi driver can be finally removed
- remove pata_qdi and pata_winbond drivers resulting in 600 LOC gone
(affected hardware is fully supported by pata_legacy driver now)
- unify code for programming PIO and MWDMA timings for 'PIIX-like' controllers resulting in 200 LOC gone
( ata_piix, pata_efar, pata_it8213, pata_oldpiix, pata_radisys &
pata_rdc )
- add ->init_host method for abstracting host specific controller initialization and then use it to cleanup Power Managment code resulting in over 100 LOC gone
( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x,
pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32,
pata_ns87415, pata_pdc2027x & sata_sil )- misc fixes and cleanups
The following changes since commit 5c0e519edce8aa5c517e3b3e9a1fdf6fa0f3cf83:
Christoph Hellwig (1):
libata: add translation for SCSI WRITE SAME (aka TRIM support)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git atang-v1
Bartlomiej Zolnierkiewicz (86):
ata_piix: fix MWDMA handling on PIIX3
ata_piix: unify code for programming PIO and MWDMA timings
pata_artop: add 32-bit PIO support
pata_artop: fix chipsets naming
pata_artop: add Power Management support
pata_artop: unify ->prereset methods
pata_artop: remove dead 34MHz PCI clock support
pata_atiixp: add 32-bit PIO support
pata_atiixp: no need to program PIO timings for MWDMA
pata_atiixp: add MWDMA0 support
pata_atiixp: remove custom BMDMA methods
pata_atiixp: add proper ->prereset method
pata_efar: add 32-bit PIO support
pata_efar: fix wrong PIO timings being programmed
pata_efar: fix wrong MWDMA timings being programmed
pata_efar: MWDMA0 is unsupported
pata_efar: fix register naming used in efar_set_piomode()
pata_efar: unify code for programming PIO and MWDMA timings
pata_cmd640: document known issues
pata_cmd64x: add 32-bit PIO support
pata_cmd64x: add enablebits checking
pata_cmd64x: add cmd64x_fixup()
pata_cs5520: add 32-bit PIO support
pata_cs5520: remove dead VDMA support
pata_cs5530: add 32-bit PIO support
pata_cs5535: add 32-bit PIO support
pata_cs5535: no need to program PIO0 timings during device init
pata_cypress: add 32-bit PIO support
pata_cypress: document known issues
pata_hpt366: add 32-bit PIO support
pata_hpt37x: add 32-bit PIO support
pata_hpt3x2n: add 32-bit PIO support
pata_hpt3x3: Power Management fix
pata_it8213: add 32-bit PIO support
pata_it8213: fix UDMA handling
pata_it8213: add UDMA100 and UDMA133 support
pata_it8213: fix wrong PIO timings being programmed
pata_it8213: fix PIO2 underclocking
pata_it8213: fix wrong MWDMA timings being programmed
pata_it8213: fix register naming used in it8213_set_piomode()
pata_efar: unify code for programming PIO and MWDMA timings
pata_it8213: fix it8213_pre_reset() documentation
pata_it821x: add 32-bit PIO support
pata_jmicron: add 32-bit PIO support
pata_legacy: do not probe extra ports automatically if PCI is not present
pata_legacy: fix QDI6580DP support
pata_legacy: fix access to control register for QDI6580
pata_legacy: add pointers to QDI65x0 documentation
pata_legacy: unify QDI ->set_piomode methods
pata_legacy: use PIO mask defines
libata: remove no longer needed pata_qdi driver
libata: remove no longer needed pata_winbond driver
pata_marvell: fix marvell_pre_reset() documentation
pata_ns87415: add 32-bit PIO support
pata_ns87415: Power Management fix
pata_oldpiix: unify code for programming PIO and MWDMA timings
pata_opti: add 32-bit PIO support
pata_pdc2027x: add 32-bit PIO support
pata_pdc2027x: add Power Management support
pata_pdc202xx_old: add 32-bit PIO support
pata_sis: Power Management fix
pata_pdc202xx_old: document known issues
pata_radisys: fix UDMA handling
pata_radisys: unify code for programming PIO and MWDMA timings
pata_rdc: unify code for programming PIO and MWDMA timings
pata_rz1000: add 32-bit PIO support
pata_rz1000: Power Management fix
pata_sc1200: add 32-bit PIO support
pata_scc: add 32-bit PIO support
pata_scc: add proper cable detection method
pata_sch: add 32-bit PIO support
pata_serverworks: add 32-bit PIO support
pata_serverworks: use standard cable detection methods
pata_serverworks: add serverworks_fixup()
pata_sl82c105: add 32-bit PIO support
pata_sl82c105: add Power Management support
pata_sis: add 32-bit PIO support
pata_sis: Power Management fix
pata_triflex: add 32-bit PIO support
libata: make ata_sff_data_xfer_noirq() work with 32-bit PIO
pata_via: add 32-bit PIO support
pata_via: clear UDMA transfer mode bit for PIO and MWDMA
pata_via: add via_fixup()
libata: add ata_mwdma_to_pio() inline helper
libata: add ->init_host method
libata: add private driver field to struct ata_device
drivers/ata/Kconfig | 16 ++- drivers/ata/Makefile | 2 - drivers/ata/ata_piix.c | 113 ++++--------- drivers/ata/libata-core.c | 14 ++- drivers/ata/libata-sff.c | 12 +- drivers/ata/pata_ali.c | 29 +-- drivers/ata/pata_amd.c | 45 ++--- drivers/ata/pata_artop.c | 224 ++++++++++++------------- drivers/ata/pata_atiixp.c | 112 ++++--------- drivers/ata/pata_cmd640.c | 27 +-- drivers/ata/pata_cmd64x.c | 100 +++++++----- drivers/ata/pata_cs5520.c | 41 +---- drivers/ata/pata_cs5530.c | 33 +--- drivers/ata/pata_cs5535.c | 14 +-- drivers/ata/pata_cypress.c | 2 +- drivers/ata/pata_efar.c | 121 +++++--------- drivers/ata/pata_hpt366.c | 32 ++--- drivers/ata/pata_hpt37x.c | 4 +- drivers/ata/pata_hpt3x2n.c | 2 +- drivers/ata/pata_hpt3x3.c | 23 ++-- drivers/ata/pata_it8213.c | 136 ++++++--------- drivers/ata/pata_it821x.c | 39 ++--- drivers/ata/pata_jmicron.c | 2 +- drivers/ata/pata_legacy.c | 156 +++++++---------- drivers/ata/pata_marvell.c | 2 +- drivers/ata/pata_ninja32.c | 30 ++-- drivers/ata/pata_ns87415.c | 22 ++- drivers/ata/pata_oldpiix.c | 95 +++------- drivers/ata/pata_opti.c | 2 + drivers/ata/pata_pdc2027x.c | 24 ++- drivers/ata/pata_pdc202xx_old.c | 37 ++++- drivers/ata/pata_qdi.c | 366 --------------------------------------- drivers/ata/pata_radisys.c | 78 +++------ drivers/ata/pata_rdc.c | 106 ++++-------- drivers/ata/pata_rz1000.c | 13 ++- drivers/ata/pata_sc1200.c | 2 +- drivers/ata/pata_scc.c | 16 +-- drivers/ata/pata_sch.c | 2 +- drivers/ata/pata_serverworks.c | 104 +++++------- drivers/ata/pata_sis.c | 25 +++- drivers/ata/pata_sl82c105.c | 28 +++- drivers/ata/pata_triflex.c | 2 +- drivers/ata/pata_via.c | 74 ++++---- drivers/ata/pata_winbond.c | 282 ------------------------------ drivers/ata/sata_sil.c | 33 +--- include/linux/ata.h | 11 ++ include/linux/libata.h | 15 ++- 47 files changed, 854 insertions(+), 1814 deletions(-) delete mode 100644 drivers/ata/pata_qdi.c delete mode 100644 drivers/ata/pata_winbond.c
PATCH 1/86 ata_piix: fix MWDMA handling on PIIX3
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] ata_piix: fix MWDMA handling on PIIX3
Fix erroneous check for ap->udma_mask in do_pata_set_dmamode() resulting in controller not being programmed properly for MWDMA.
--- drivers/ata/ata_piix.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/ata/ata_piix.c +3 -3
@@ -869,10 +869,10 @@ static void do_pata_set_dmamode(struct a (timings[pio][1 ] <<8 ); } -if (ap->udma_mask) { +if (ap->udma_mask) udma_enable &= ~(1 << devid); -pci_write_config_word (dev, master_port, master_data); - } + +pci_write_config_word (dev, master_port, master_data); }/* Don't scribble on 0x48 if the controller does not support UDMA */ if (ap->udma_mask)
PATCH 2/86 ata_piix: unify code for programming PIO and MWDMA timings
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] ata_piix: unify code for programming PIO and MWDMA timings
It results in ~2% decrease in the driver LOC count and also ~2% decrease in the driver binary size (as measured on x86-32).
This change should be safe as this is how we have been doing things in IDE piix host driver for years.
Fix piix_set_piomode() documentation while at it.
--- drivers/ata/ata_piix.c | 112 ++++++++++++++++--------------------------------- 1 file changed, 37 insertions(+), 75 deletions(-)
drivers/ata/ata_piix.c +37 -75
@@ -666,22 +666,11 @@ static int piix_pata_prereset(struct atastatic DEFINE_SPINLOCK (piix_lock); -/** -* piix_set_piomode - Initialize host controller PATA PIO timings -* @ap: Port whose timings we are configuring -* @adev: um -* -* Set PIO mode for device, in host controller PCI config space. -* -* LOCKING: -* None (inherited from caller). -*/ - -static void piix_set_piomode (struct ata_port *ap,struct ata_device *adev) +static void piix_set_timings (struct ata_port *ap,struct ata_device *adev, +u8 pio,bool use_mwdma) {struct pci_dev *dev =to_pci_dev (ap->host->dev);unsigned long flags; -unsigned int pio = adev->pio_mode -XFER_PIO_0 ;unsigned int is_slave = (adev->devno !=0 );unsigned int master_port= ap->port_no ?0x42 :0x40 ;unsigned int slave_port =0x44 ;
@@ -702,14 +691,18 @@ static void piix_set_piomode(struct ata_ { 2, 1 }, { 2, 3 }, }; -if (pio >=2 ) +if (pio >=2 || use_mwdma) control |=1 ;/* TIME1 enable */ -if (ata_pio_need_iordy (adev)) +if (ata_pio_need_iordy (adev) || use_mwdma) control |=2 ;/* IE enable */ -/* Intel specifies that the PPE functionality is for disk only */ if (adev->class ==ATA_DEV_ATA ) control |=4 ;/* PPE enable */ +/* If the drive MWDMA is faster than it can do PIO then +we must force PIO into PIO0 */ +if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio)) +/* Enable DMA timing only */ + control |=8 ;/* PIO cycles in PIO0 */ spin_lock_irqsave (&piix_lock, flags);
@@ -757,6 +750,22 @@ static void piix_set_piomode(struct ata_ }/** +* piix_set_piomode - Initialize host controller PATA PIO timings +* @ap: Port whose timings we are configuring +* @adev: Drive in question +* +* Set PIO mode for device, in host controller PCI config space. +* +* LOCKING: +* None (inherited from caller). +*/ + +static void piix_set_piomode (struct ata_port *ap,struct ata_device *adev) +{ +piix_set_timings (ap, adev, adev->pio_mode -XFER_PIO_0 ,0 ); +} + +/** * do_pata_set_dmamode - Initialize host controller PATA PIO timings * @ap: Port whose timings we are configuring * @adev: Drive in question
@@ -772,31 +781,20 @@ static void do_pata_set_dmamode(struct a {struct pci_dev *dev =to_pci_dev (ap->host->dev);unsigned long flags; -u8 master_port = ap->port_no ?0x42 :0x40 ; -u16 master_data;u8 speed = adev->dma_mode;int devid = adev->devno +2 * ap->port_no;u8 udma_enable =0 ; -static const /* ISP RTC */ -u8 timings[][2 ] = { {0 ,0 }, - {0 ,0 }, - {1 ,0 }, - {2 ,1 }, - {2 ,3 }, }; - -spin_lock_irqsave (&piix_lock, flags); - -pci_read_config_word (dev, master_port, &master_data); -if (ap->udma_mask) -pci_read_config_byte (dev,0x48 , &udma_enable); -if (speed >=XFER_UDMA_0 ) { -unsigned int udma = adev->dma_mode -XFER_UDMA_0 ; +unsigned int udma = speed -XFER_UDMA_0 ;u16 udma_timing;u16 ideconf;int u_clock, u_speed; +spin_lock_irqsave (&piix_lock, flags); + +pci_read_config_byte (dev,0x48 , &udma_enable); +/* * UDMA is handled by a combination of clock switching and * selection of dividers
@@ -829,56 +827,20 @@ static void do_pata_set_dmamode(struct aperformance (WR_PingPong_En) */ pci_write_config_word (dev,0x54 , ideconf); } + +pci_write_config_byte (dev,0x48 , udma_enable); + +spin_unlock_irqrestore (&piix_lock, flags); }else { -/* -* MWDMA is driven by the PIO timings. We must also enable -* IORDY unconditionally along with TIME1. PPE has already -* been set when the PIO timing was set. -*/ -unsigned int mwdma = adev->dma_mode -XFER_MW_DMA_0 ; -unsigned int control; -u8 slave_data; +/* MWDMA is driven by the PIO timings. */ +unsigned int mwdma = speed -XFER_MW_DMA_0 ;const unsigned int needed_pio[3 ] = {XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 };int pio = needed_pio[mwdma] -XFER_PIO_0 ; - control =3 ;/* IORDY|TIME1 */ - -/* If the drive MWDMA is faster than it can do PIO then -we must force PIO into PIO0 */ - -if (adev->pio_mode < needed_pio[mwdma]) -/* Enable DMA timing only */ - control |=8 ;/* PIO cycles in PIO0 */ - -if (adev->devno) {/* Slave */ - master_data &=0xFF4F ;/* Mask out IORDY|TIME1|DMAONLY */ - master_data |= control <<4 ; -pci_read_config_byte (dev,0x44 , &slave_data); - slave_data &= (ap->port_no ?0x0f :0xf0 ); -/* Load the matching timing */ - slave_data |= ((timings[pio][0 ] <<2 ) | timings[pio][1 ]) << (ap->port_no ?4 :0 ); -pci_write_config_byte (dev,0x44 , slave_data); - }else {/* Master */ - master_data &=0xCCF4 ;/* Mask out IORDY|TIME1|DMAONLY -and master timing bits */ - master_data |= control; - master_data |= - (timings[pio][0 ] <<12 ) | - (timings[pio][1 ] <<8 ); - } - -if (ap->udma_mask) - udma_enable &= ~(1 << devid); - -pci_write_config_word (dev, master_port, master_data); +piix_set_timings (ap, adev, pio,1 ); } -/* Don't scribble on 0x48 if the controller does not support UDMA */ -if (ap->udma_mask) -pci_write_config_byte (dev,0x48 , udma_enable); - -spin_unlock_irqrestore (&piix_lock, flags); }/**
PATCH 3/86 pata_artop: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_artop: add 32-bit PIO support
There shouldn't be any problems with it as IDE aec62xx host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_artop.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ata/pata_artop.c +2 -2
@@ -312,7 +312,7 @@ static struct scsi_host_template artop_s };static struct ata_port_operations artop6210_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .cable_detect = ata_cable_40wire, .set_piomode = artop6210_set_piomode, .set_dmamode = artop6210_set_dmamode,
@@ -321,7 +321,7 @@ static struct ata_port_operations artop6 };static struct ata_port_operations artop6260_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .cable_detect = artop6260_cable_detect, .set_piomode = artop6260_set_piomode, .set_dmamode = artop6260_set_dmamode,
Re: [PATCH 03/86] pata_artop: add 32-bit PIO support
Quoted 5 lines · On Wed, 25 Nov 2009 18:02:39 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_artop: add 32-bit PIO supportThere shouldn't be any problems with it as IDE aec62xx host driver has been allowing 32-bit PIO operations for years.
Allowing or defaulting too ?
Re: [PATCH 03/86] pata_artop: add 32-bit PIO support
Quoted 10 lines · Alan Cox
Quoted 5 lines · On Wed, 25 Nov 2009 18:02:39 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_artop: add 32-bit PIO supportThere shouldn't be any problems with it as IDE aec62xx host driver has been allowing 32-bit PIO operations for years.
Allowing or defaulting too ?
For aec62xx: allowing, for some other drivers: defaulting ('using' in the patch description instead of 'allowing'). However some popular distributions have been defaulting to always enabling it if was supported by the driver.
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 03/86] pata_artop: add 32-bit PIO support
Quoted 10 lines · On Wed, 25 Nov 2009 18:18:18 +0100 Bartlomiej Zolnierkiewicz…
Quoted 9 lines · Alan Cox
Quoted 5 lines · On Wed, 25 Nov 2009 18:02:39 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_artop: add 32-bit PIO supportThere shouldn't be any problems with it as IDE aec62xx host driver has been allowing 32-bit PIO operations for years.
Quoted 6 lines
Quoted 1 line
Allowing or defaulting too ?
For aec62xx: allowing, for some other drivers: defaulting ('using' in the patch description instead of 'allowing'). However some popular distributions have been defaulting to always enabling it if was supported by the driver.
I wonder what their coverage of old devices is like though and what they enabled. No problem with those that defaulted, would be nice to get the rest tested more systematically
PATCH 4/86 pata_artop: fix chipsets naming
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_artop: fix chipsets naming
6210, 6260[R] and 6280[R] are names used for AEC cards while ARTOP chipset names are: 850, 860[R] and 865[R] respectively.
Fix the naming used in the driver to avoid confusion and make it more consistent with pata_atp87x.c.
While at it:
- use atp86x_ prefix for functions used by all ATP86x chipsets (previously they were erroneously prefixed with artop6260_)
- use '133' instead of 'fast' to denote UDMA133 support
- use '6880' instead of '6280 + fast' to denote AEC6880 card
- fix documentation of ->prereset method
- fix typo in the documentation of ->qc_defer method
- fix few CodingStyle issues
--- drivers/ata/pata_artop.c | 111 +++++++++++++++++++++++------------------------ 1 file changed, 55 insertions(+), 56 deletions(-)
drivers/ata/pata_artop.c +55 -56
@@ -39,7 +39,7 @@static int clock =0 ; -static int artop6210_pre_reset (struct ata_link *link,unsigned long deadline) +static int atp850_pre_reset (struct ata_link *link,unsigned long deadline) {struct ata_port *ap = link->ap;struct pci_dev *pdev =to_pci_dev (ap->host->dev);
@@ -55,15 +55,14 @@ static int artop6210_pre_reset(struct at }/** -* artop6260_pre_reset - check for 40/80 pin +* atp86x_pre_reset - probe begin * @link: link * @deadline: deadline jiffies for the operation * -* The ARTOP hardware reports the cable detect bits in register 0x49. * Nothing complicated needed here. */ -static int artop6260_pre_reset (struct ata_link *link,unsigned long deadline) +static int atp86x_pre_reset (struct ata_link *link,unsigned long deadline) {static const struct pci_bits artop_enable_bits[] = { {0x4AU ,1U ,0x02UL ,0x02UL },/* port 0 */
@@ -81,13 +80,13 @@ static int artop6260_pre_reset(struct at }/** -* artop6260_cable_detect - identify cable type +* atp86x_cable_detect - identify cable type * @ap: Port * * Identify the cable type for the ARTOP interface in question */ -static int artop6260_cable_detect (struct ata_port *ap) +static int atp86x_cable_detect (struct ata_port *ap) {struct pci_dev *pdev =to_pci_dev (ap->host->dev);u8 tmp;
@@ -98,7 +97,7 @@ static int artop6260_cable_detect(struct }/** -* artop6210_load_piomode - Load a set of PATA PIO timings +* atp850_load_piomode - Load a set of PATA PIO timings * @ap: Port whose timings we are configuring * @adev: Device * @pio: PIO mode
@@ -111,7 +110,8 @@ static int artop6260_cable_detect(struct* None (inherited from caller). */ -static void artop6210_load_piomode (struct ata_port *ap,struct ata_device *adev,unsigned int pio) +static void atp850_load_piomode (struct ata_port *ap,struct ata_device *adev, +unsigned int pio) {struct pci_dev *pdev =to_pci_dev (ap->host->dev);int dn = adev->devno +2 * ap->port_no;
@@ -125,7 +125,7 @@ static void artop6210_load_piomode(struc }/** -* artop6210_set_piomode - Initialize host controller PATA PIO timings +* atp850_set_piomode - Initialize host controller PATA PIO timings * @ap: Port whose timings we are configuring * @adev: Device we are configuring *
@@ -138,13 +138,13 @@ static void artop6210_load_piomode(struc* None (inherited from caller). */ -static void artop6210_set_piomode (struct ata_port *ap,struct ata_device *adev) +static void atp850_set_piomode (struct ata_port *ap,struct ata_device *adev) {struct pci_dev *pdev =to_pci_dev (ap->host->dev);int dn = adev->devno +2 * ap->port_no;u8 ultra; -artop6210_load_piomode (ap, adev, adev->pio_mode -XFER_PIO_0 ); +atp850_load_piomode (ap, adev, adev->pio_mode -XFER_PIO_0 );/* Clear the UDMA mode bits (set_dmamode will redo this if needed) */ pci_read_config_byte (pdev,0x54 , &ultra);
@@ -153,19 +153,20 @@ static void artop6210_set_piomode(struct }/** -* artop6260_load_piomode - Initialize host controller PATA PIO timings +* atp86x_load_piomode - Initialize host controller PATA PIO timings * @ap: Port whose timings we are configuring * @adev: Device we are configuring * @pio: PIO mode * -* Set PIO mode for device, in host controller PCI config space. The -* ARTOP6260 and relatives store the timing data differently. +* Set PIO mode for device, in host controller PCI config space. +* The ATP860 and relatives store the timing data differently. * * LOCKING: * None (inherited from caller). */ -static void artop6260_load_piomode (struct ata_port *ap,struct ata_device *adev,unsigned int pio) +static void atp86x_load_piomode (struct ata_port *ap,struct ata_device *adev, +unsigned int pio) {struct pci_dev *pdev =to_pci_dev (ap->host->dev);int dn = adev->devno +2 * ap->port_no;
@@ -179,7 +180,7 @@ static void artop6260_load_piomode (stru }/** -* artop6260_set_piomode - Initialize host controller PATA PIO timings +* atp86x_set_piomode - Initialize host controller PATA PIO timings * @ap: Port whose timings we are configuring * @adev: Device we are configuring *
@@ -192,12 +193,12 @@ static void artop6260_load_piomode (stru* None (inherited from caller). */ -static void artop6260_set_piomode (struct ata_port *ap,struct ata_device *adev) +static void atp86x_set_piomode (struct ata_port *ap,struct ata_device *adev) {struct pci_dev *pdev =to_pci_dev (ap->host->dev);u8 ultra; -artop6260_load_piomode (ap, adev, adev->pio_mode -XFER_PIO_0 ); +atp86x_load_piomode (ap, adev, adev->pio_mode -XFER_PIO_0 );/* Clear the UDMA mode bits (set_dmamode will redo this if needed) */ pci_read_config_byte (pdev,0x44 + ap->port_no, &ultra);
@@ -206,7 +207,7 @@ static void artop6260_set_piomode(struct }/** -* artop6210_set_dmamode - Initialize host controller PATA PIO timings +* atp850_set_dmamode - Initialize host controller PATA PIO timings * @ap: Port whose timings we are configuring * @adev: Device whose timings we are configuring *
@@ -216,7 +217,7 @@ static void artop6260_set_piomode(struct* None (inherited from caller). */ -static void artop6210_set_dmamode (struct ata_port *ap,struct ata_device *adev) +static void atp850_set_dmamode (struct ata_port *ap,struct ata_device *adev) {unsigned int pio;struct pci_dev *pdev =to_pci_dev (ap->host->dev);
@@ -229,7 +230,7 @@ static void artop6210_set_dmamode (struc pio =4 ;/* Load the PIO timing active/recovery bits */ -artop6210_load_piomode (ap, adev, pio); +atp850_load_piomode (ap, adev, pio);pci_read_config_byte (pdev,0x54 , &ultra); ultra &= ~(3 << (2 * dn));
@@ -245,18 +246,18 @@ static void artop6210_set_dmamode (struc }/** -* artop6260_set_dmamode - Initialize host controller PATA PIO timings +* atp86x_set_dmamode - Initialize host controller PATA PIO timings * @ap: Port whose timings we are configuring * @adev: Device we are configuring * -* Set DMA mode for device, in host controller PCI config space. The -* ARTOP6260 and relatives store the timing data differently. +* Set DMA mode for device, in host controller PCI config space. +* The ATP860 and relatives store the timing data differently. * * LOCKING: * None (inherited from caller). */ -static void artop6260_set_dmamode (struct ata_port *ap,struct ata_device *adev) +static void atp86x_set_dmamode (struct ata_port *ap,struct ata_device *adev) {unsigned int pio = adev->pio_mode -XFER_PIO_0 ;struct pci_dev *pdev =to_pci_dev (ap->host->dev);
@@ -268,7 +269,7 @@ static void artop6260_set_dmamode (struc pio =4 ;/* Load the PIO timing active/recovery bits */ -artop6260_load_piomode (ap, adev, pio); +atp86x_load_piomode (ap, adev, pio);/* Add ultra DMA bits if in UDMA mode */ pci_read_config_byte (pdev,0x44 + ap->port_no, &ultra);
@@ -283,13 +284,13 @@ static void artop6260_set_dmamode (struc }/** -* artop_6210_qc_defer - implement serialization +* atp850_qc_defer - implement serialization * @qc: command * * Issue commands per host on this chip. */ -static int artop6210_qc_defer (struct ata_queued_cmd *qc) +static int atp850_qc_defer (struct ata_queued_cmd *qc) {struct ata_host *host = qc->ap->host;struct ata_port *alt = host->ports[1 ^ qc->ap->port_no];
@@ -311,21 +312,21 @@ static struct scsi_host_template artop_s ATA_BMDMA_SHT(DRV_NAME), }; -static struct ata_port_operations artop6210_ops = { +static struct ata_port_operations atp850_ops = { .inherits = &ata_bmdma32_port_ops, .cable_detect = ata_cable_40wire, - .set_piomode = artop6210_set_piomode, - .set_dmamode = artop6210_set_dmamode, - .prereset = artop6210_pre_reset, - .qc_defer = artop6210_qc_defer, + .set_piomode = atp850_set_piomode, + .set_dmamode = atp850_set_dmamode, + .prereset = atp850_pre_reset, + .qc_defer = atp850_qc_defer, }; -static struct ata_port_operations artop6260_ops = { +static struct ata_port_operations atp86x_ops = { .inherits = &ata_bmdma32_port_ops, - .cable_detect = artop6260_cable_detect, - .set_piomode = artop6260_set_piomode, - .set_dmamode = artop6260_set_dmamode, - .prereset = artop6260_pre_reset, + .cable_detect = atp86x_cable_detect, + .set_piomode = atp86x_set_piomode, + .set_dmamode = atp86x_set_dmamode, + .prereset = atp86x_pre_reset, };
@@ -346,33 +347,33 @@ static struct ata_port_operations artop6static int artop_init_one (struct pci_dev *pdev,const struct pci_device_id *id) {static int printed_version; -static const struct ata_port_info info_6210 = { +static const struct ata_port_info atp850_info = { .flags =ATA_FLAG_SLAVE_POSS , .pio_mask =ATA_PIO4 , .mwdma_mask =ATA_MWDMA2 , .udma_mask =ATA_UDMA2 , - .port_ops = &artop6210_ops, + .port_ops = &atp850_ops, }; -static const struct ata_port_info info_626x = { +static const struct ata_port_info atp860_info = { .flags =ATA_FLAG_SLAVE_POSS , .pio_mask =ATA_PIO4 , .mwdma_mask =ATA_MWDMA2 , .udma_mask =ATA_UDMA4 , - .port_ops = &artop6260_ops, + .port_ops = &atp86x_ops, }; -static const struct ata_port_info info_628x = { +static const struct ata_port_info atp865_info = { .flags =ATA_FLAG_SLAVE_POSS , .pio_mask =ATA_PIO4 , .mwdma_mask =ATA_MWDMA2 , .udma_mask =ATA_UDMA5 , - .port_ops = &artop6260_ops, + .port_ops = &atp86x_ops, }; -static const struct ata_port_info info_628x_fast = { +static const struct ata_port_info atp865_133_info = { .flags =ATA_FLAG_SLAVE_POSS , .pio_mask =ATA_PIO4 , .mwdma_mask =ATA_MWDMA2 , .udma_mask =ATA_UDMA6 , - .port_ops = &artop6260_ops, + .port_ops = &atp86x_ops, };const struct ata_port_info *ppi[] = {NULL ,NULL };int rc;
@@ -385,20 +386,19 @@ static int artop_init_one (struct pci_deif (rc)return rc; -if (id->driver_data ==0 ) {/* 6210 variant */ - ppi[0 ] = &info_6210; +if (id->driver_data ==0 ) {/* AEC6210 */ + ppi[0 ] = &atp850_info;/* BIOS may have left us in UDMA, clear it before libata probe */ pci_write_config_byte (pdev,0x54 ,0 ); - } -else if (id->driver_data ==1 )/* 6260 */ - ppi[0 ] = &info_626x; -else if (id->driver_data ==2 ) {/* 6280 or 6280 + fast */ + }else if (id->driver_data ==1 ) {/* AEC6260[R] */ + ppi[0 ] = &atp860_info; + }else if (id->driver_data ==2 ) {/* AEC6280[R] */ unsigned long io =pci_resource_start (pdev,4 );u8 reg; - ppi[0 ] = &info_628x; -if (inb (io) &0x10 ) - ppi[0 ] = &info_628x_fast; + ppi[0 ] = &atp865_info; +if (inb (io) &0x10 )/* AEC6880[R] */ + ppi[0 ] = &atp865_133_info;/* Mac systems come up with some registers not set as we will need them */
@@ -416,7 +416,6 @@ static int artop_init_one (struct pci_de/* Enable IRQ output and burst mode */ pci_read_config_byte (pdev,0x4a , ®);pci_write_config_byte (pdev,0x4a , (reg & ~0x01 ) |0x80 ); - }BUG_ON (ppi[0 ] ==NULL );
PATCH 5/86 pata_artop: add Power Management support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_artop: add Power Management support
There shouldn't be any problems with it as IDE aec62xx host driver has been supporting Power Management for over year now.
--- drivers/ata/pata_artop.c | 72 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 51 insertions(+), 21 deletions(-)
drivers/ata/pata_artop.c +51 -21
@@ -2,7 +2,7 @@* pata_artop.c - ARTOP ATA controller driver * * (C) 2006 Red Hat -* (C) 2007 Bartlomiej Zolnierkiewicz +* (C) 2007,2009 Bartlomiej Zolnierkiewicz * * Based in part on drivers/ide/pci/aec62xx.c * Copyright (C) 1999-2002 Andre Hedrick <[email protected]>
@@ -330,6 +330,33 @@ static struct ata_port_operations atp86x .prereset = atp86x_pre_reset, }; +static void atp8xx_fixup (struct pci_dev *pdev) +{ +if (pdev->device ==0x0005 ) +/* BIOS may have left us in UDMA, clear it before probe */ +pci_write_config_byte (pdev,0x54 ,0 ); +else if (pdev->device ==0x0008 || pdev->device ==0x0009 ) { +u8 reg; + +/* Mac systems come up with some registers not set as we +will need them */ + +/* Clear reset & test bits */ +pci_read_config_byte (pdev,0x49 , ®); +pci_write_config_byte (pdev,0x49 , reg & ~0x30 ); + +/* PCI latency must be > 0x80 for burst mode, tweak it +* if required. +*/ +pci_read_config_byte (pdev,PCI_LATENCY_TIMER , ®); +if (reg <=0x80 ) +pci_write_config_byte (pdev,PCI_LATENCY_TIMER ,0x90 ); + +/* Enable IRQ output and burst mode */ +pci_read_config_byte (pdev,0x4a , ®); +pci_write_config_byte (pdev,0x4a , (reg & ~0x01 ) |0x80 ); + } +}/** * artop_init_one - Register ARTOP ATA PCI device with kernel services
@@ -389,41 +416,40 @@ static int artop_init_one (struct pci_deif (id->driver_data ==0 ) {/* AEC6210 */ ppi[0 ] = &atp850_info; -/* BIOS may have left us in UDMA, clear it before libata probe */ -pci_write_config_byte (pdev,0x54 ,0 ); }else if (id->driver_data ==1 ) {/* AEC6260[R] */ ppi[0 ] = &atp860_info; }else if (id->driver_data ==2 ) {/* AEC6280[R] */ unsigned long io =pci_resource_start (pdev,4 ); -u8 reg; ppi[0 ] = &atp865_info;if (inb (io) &0x10 )/* AEC6880[R] */ ppi[0 ] = &atp865_133_info; -/* Mac systems come up with some registers not set as we -will need them */ - -/* Clear reset & test bits */ -pci_read_config_byte (pdev,0x49 , ®); -pci_write_config_byte (pdev,0x49 , reg & ~0x30 ); - -/* PCI latency must be > 0x80 for burst mode, tweak it -* if required. -*/ -pci_read_config_byte (pdev,PCI_LATENCY_TIMER , ®); -if (reg <=0x80 ) -pci_write_config_byte (pdev,PCI_LATENCY_TIMER ,0x90 ); - -/* Enable IRQ output and burst mode */ -pci_read_config_byte (pdev,0x4a , ®); -pci_write_config_byte (pdev,0x4a , (reg & ~0x01 ) |0x80 ); }BUG_ON (ppi[0 ] ==NULL ); +atp8xx_fixup (pdev); +return ata_pci_sff_init_one (pdev, ppi, &artop_sht,NULL ); } +#ifdef CONFIG_PM +static int atp8xx_reinit_one (struct pci_dev *pdev) +{ +struct ata_host *host =dev_get_drvdata (&pdev->dev); +int rc; + + rc =ata_pci_device_do_resume (pdev); +if (rc) +return rc; + +atp8xx_fixup (pdev); + +ata_host_resume (host); +return 0 ; +} +#endif +static const struct pci_device_id artop_pci_tbl[] = { {PCI_VDEVICE (ARTOP ,0x0005 ),0 }, {PCI_VDEVICE (ARTOP ,0x0006 ),1 },
@@ -439,6 +465,10 @@ static struct pci_driver artop_pci_drive .id_table = artop_pci_tbl, .probe = artop_init_one, .remove = ata_pci_remove_one, +#ifdef CONFIG_PM + .suspend = ata_pci_device_suspend, + .resume = atp8xx_reinit_one, +#endif };static int __init artop_init (void )
Re: [PATCH 05/86] pata_artop: add Power Management support
Quoted 12 lines · Bartlomiej Zolnierkiewicz
There shouldn't be any problems with it as IDE aec62xx host driver has been supporting Power Management for over year now.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/ata/pata_artop.c | 72 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 51 insertions(+), 21 deletions(-)Index:
b/drivers/ata/pata_artop.c
===================================================================drivers/ata/pata_artop.c +0
-0
[...]
Quoted 8 lines
drivers/ata/pata_artop.c +4
-0@@ -330,6 +330,33 @@ static struct ata_port_operations atp86x .prereset = atp86x_pre_reset, }; +static void atp8xx_fixup (struct pci_dev *pdev) +{ +if (pdev->device ==0x0005 ) +/* BIOS may have left us in UDMA, clear it before probe */
drivers/ata/pata_artop.c static struct ata_port_operations atp86x · line 346
Quoted 10 lines
drivers/ata/pata_artop.c +10
-0+pci_write_config_byte (pdev,0x54 ,0 ); + else if (pdev->device == 0x0008 || pdev->device == 0x0009) { +u8 reg; + +/* Mac systems come up with some registers not set as we +will need them */ + +/* Clear reset & test bits */ +pci_read_config_byte (pdev,0x49 , ®); +pci_write_config_byte (pdev,0x49 , reg & ~0x30 );
Space not needed between ~ and 0x30...
MBR, Sergei
PATCH 6/86 pata_artop: unify ->prereset methods
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_artop: unify ->prereset methods
We can use the same ->prereset method for ATP850 and ATP86xR chipsets.
--- drivers/ata/pata_artop.c | 28 +++++++--------------------- 1 file changed, 7 insertions(+), 21 deletions(-)
drivers/ata/pata_artop.c +7 -21
@@ -39,30 +39,15 @@static int clock =0 ; -static int atp850_pre_reset (struct ata_link *link,unsigned long deadline) -{ -struct ata_port *ap = link->ap; -struct pci_dev *pdev =to_pci_dev (ap->host->dev); -const struct pci_bits artop_enable_bits[] = { - {0x4AU ,1U ,0x02UL ,0x02UL },/* port 0 */ - {0x4AU ,1U ,0x04UL ,0x04UL },/* port 1 */ - }; - -if (!pci_test_config_bits (pdev, &artop_enable_bits[ap->port_no])) -return -ENOENT ; - -return ata_sff_prereset (link, deadline); -} -/** -* atp86x_pre_reset - probe begin +* atp8xx_prereset - probe begin * @link: link * @deadline: deadline jiffies for the operation * * Nothing complicated needed here. */ -static int atp86x_pre_reset (struct ata_link *link,unsigned long deadline) +static int atp8xx_prereset (struct ata_link *link,unsigned long deadline) {static const struct pci_bits artop_enable_bits[] = { {0x4AU ,1U ,0x02UL ,0x02UL },/* port 0 */
@@ -72,8 +57,9 @@ static int atp86x_pre_reset(struct ata_lstruct ata_port *ap = link->ap;struct pci_dev *pdev =to_pci_dev (ap->host->dev); -/* Odd numbered device ids are the units with enable bits (the -R cards) */ -if (pdev->device %1 && !pci_test_config_bits (pdev, &artop_enable_bits[ap->port_no])) +/* Odd numbered device ids are the units with enable bits. */ +if (pdev->device %1 && + !pci_test_config_bits (pdev, &artop_enable_bits[ap->port_no]))return -ENOENT ;return ata_sff_prereset (link, deadline);
@@ -317,7 +303,7 @@ static struct ata_port_operations atp850 .cable_detect = ata_cable_40wire, .set_piomode = atp850_set_piomode, .set_dmamode = atp850_set_dmamode, - .prereset = atp850_pre_reset, + .prereset = atp8xx_prereset, .qc_defer = atp850_qc_defer, };
@@ -326,7 +312,7 @@ static struct ata_port_operations atp86x .cable_detect = atp86x_cable_detect, .set_piomode = atp86x_set_piomode, .set_dmamode = atp86x_set_dmamode, - .prereset = atp86x_pre_reset, + .prereset = atp8xx_prereset, };static void atp8xx_fixup (struct pci_dev *pdev)
PATCH 7/86 pata_artop: remove dead 34MHz PCI clock support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_artop: remove dead 34MHz PCI clock support
It has been dead for the last three years (== since the initial driver merge) and probability that it will ever get fixed is quite low.
Since there is no reason to keep this dead code around any longer just remove it (it can still be retrieved from the git history if necessary).
--- drivers/ata/pata_artop.c | 29 ++++++++--------------------- 1 file changed, 8 insertions(+), 21 deletions(-)
drivers/ata/pata_artop.c +8 -21
@@ -30,15 +30,6 @@#define DRV_NAME "pata_artop"#define DRV_VERSION "0.4.5" -/* -* The ARTOP has 33 Mhz and "over clocked" timing tables. Until we -* get PCI bus speed functionality we leave this as 0. Its a variable -* for when we get the functionality and also for folks wanting to -* test stuff. -*/ - -static int clock =0 ; -/** * atp8xx_prereset - probe begin * @link: link
@@ -101,13 +92,11 @@ static void atp850_load_piomode(struct a {struct pci_dev *pdev =to_pci_dev (ap->host->dev);int dn = adev->devno +2 * ap->port_no; -const u16 timing[2 ][5 ] = { - {0x0000 ,0x000A ,0x0008 ,0x0303 ,0x0301 }, - {0x0700 ,0x070A ,0x0708 ,0x0403 ,0x0401 } +const u16 timing[5 ] = + {0x0000 ,0x000A ,0x0008 ,0x0303 ,0x0301 }; - };/* Load the PIO timing active/recovery bits */ -pci_write_config_word (pdev,0x40 +2 * dn, timing[clock][pio]); +pci_write_config_word (pdev,0x40 +2 * dn, timing[pio]); }/**
@@ -156,13 +145,11 @@ static void atp86x_load_piomode(struct a {struct pci_dev *pdev =to_pci_dev (ap->host->dev);int dn = adev->devno +2 * ap->port_no; -const u8 timing[2 ][5 ] = { - {0x00 ,0x0A ,0x08 ,0x33 ,0x31 }, - {0x70 ,0x7A ,0x78 ,0x43 ,0x41 } +const u8 timing[5 ] = + {0x00 ,0x0A ,0x08 ,0x33 ,0x31 }; - };/* Load the PIO timing active/recovery bits */ -pci_write_config_byte (pdev,0x40 + dn, timing[clock][pio]); +pci_write_config_byte (pdev,0x40 + dn, timing[pio]); }/**
@@ -223,7 +210,7 @@ static void atp850_set_dmamode(struct at/* Add ultra DMA bits if in UDMA mode */ if (adev->dma_mode >=XFER_UDMA_0 ) { -u8 mode = (adev->dma_mode -XFER_UDMA_0 ) +1 - clock; +u8 mode = (adev->dma_mode -XFER_UDMA_0 ) +1 ;if (mode ==0 ) mode =1 ; ultra |= (mode << (2 * dn));
@@ -261,7 +248,7 @@ static void atp86x_set_dmamode(struct atpci_read_config_byte (pdev,0x44 + ap->port_no, &ultra); ultra &= ~(7 << (4 * adev->devno));/* One nibble per drive */ if (adev->dma_mode >=XFER_UDMA_0 ) { -u8 mode = adev->dma_mode -XFER_UDMA_0 +1 - clock; +u8 mode = adev->dma_mode -XFER_UDMA_0 +1 ;if (mode ==0 ) mode =1 ; ultra |= (mode << (4 * adev->devno));
Re: [PATCH 07/86] pata_artop: remove dead 34MHz PCI clock support
Hello.
Quoted 31 lines · Bartlomiej Zolnierkiewicz
It has been dead for the last three years (== since the initial driver merge) and probability that it will ever get fixed is quite low.
Since there is no reason to keep this dead code around any longer just remove it (it can still be retrieved from the git history if necessary).
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/ata/pata_artop.c | 29 ++++++++--------------------- 1 file changed, 8 insertions(+), 21 deletions(-)Index:
b/drivers/ata/pata_artop.c
===================================================================drivers/ata/pata_artop.c +0
-9@@ -30,15 +30,6 @@#define DRV_NAME "pata_artop"#define DRV_VERSION "0.4.5" -/* -* The ARTOP has 33 Mhz and "over clocked" timing tables. Until we -* get PCI bus speed functionality we leave this as 0. Its a variable -* for when we get the functionality and also for folks wanting to -* test stuff. -*/ - -static int clock =0 ; -/** * atp8xx_prereset - probe begin * @link: link
[...]
drivers/ata/pata_artop.c static void atp850_set_dmamode(struct at · line 215
Quoted 8 lines
drivers/ata/pata_artop.c +1
-1@@ -223,7 +210,7 @@ static void atp850_set_dmamode(struct at/* Add ultra DMA bits if in UDMA mode */ if (adev->dma_mode >=XFER_UDMA_0 ) { -u8 mode = (adev->dma_mode -XFER_UDMA_0 ) +1 - clock; +u8 mode = (adev->dma_mode -XFER_UDMA_0 ) +1 ;if (mode ==0 ) mode =1 ;
Note that 'mode' can't be 0 anymore, so this check can be removed.
drivers/ata/pata_artop.c static void atp86x_set_dmamode(struct at · line 253
Quoted 9 lines
drivers/ata/pata_artop.c +1
-1ultra |= (mode << (2 * dn));@@ -261,7 +248,7 @@ static void atp86x_set_dmamode(struct atpci_read_config_byte (pdev,0x44 + ap->port_no, &ultra); ultra &= ~(7 << (4 * adev->devno));/* One nibble per drive */ if (adev->dma_mode >=XFER_UDMA_0 ) { -u8 mode = adev->dma_mode -XFER_UDMA_0 +1 - clock; +u8 mode = adev->dma_mode -XFER_UDMA_0 +1 ;if (mode ==0 ) mode =1 ;
Same here...
MBR, Sergei
PATCH 8/86 pata_atiixp: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_atiixp: add 32-bit PIO support
There shouldn't be any problems with it as IDE atiixp host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_atiixp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_atiixp.c +1 -1
@@ -206,7 +206,7 @@ static struct scsi_host_template atiixp_ };static struct ata_port_operations atiixp_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .qc_prep = ata_sff_dumb_qc_prep, .bmdma_start = atiixp_bmdma_start,
PATCH 9/86 pata_atiixp: no need to program PIO timings for MWDMA
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_atiixp: no need to program PIO timings for MWDMA
Moreover the code to do it was buggy and programmed PIO timings even if they were already set to a desired values.
There shouldn't be any problems with it as IDE atiixp host driver has been allowing separate PIO/MWDMA timings for last two years.
--- drivers/ata/pata_atiixp.c | 15 --------------- 1 file changed, 15 deletions(-)
drivers/ata/pata_atiixp.c +0 -15
@@ -107,7 +107,6 @@ static void atiixp_set_dmamode(struct atstruct pci_dev *pdev =to_pci_dev (ap->host->dev);int dma = adev->dma_mode;int dn =2 * ap->port_no + adev->devno; -int wanted_pio;if (adev->dma_mode >=XFER_UDMA_0 ) {u16 udma_mode_data;
@@ -131,20 +130,6 @@ static void atiixp_set_dmamode(struct atpci_write_config_dword (pdev,ATIIXP_IDE_MWDMA_TIMING , mwdma_timing_data); } -/* -* We must now look at the PIO mode situation. We may need to -* adjust the PIO mode to keep the timings acceptable -*/ -if (adev->dma_mode >=XFER_MW_DMA_2 ) - wanted_pio =4 ; -else if (adev->dma_mode ==XFER_MW_DMA_1 ) - wanted_pio =3 ; -else if (adev->dma_mode ==XFER_MW_DMA_0 ) - wanted_pio =0 ; -else BUG (); - -if (adev->pio_mode != wanted_pio) -atiixp_set_pio_timing (ap, adev, wanted_pio); }/**
Re: [PATCH 09/86] pata_atiixp: no need to program PIO timings for MWDMA
Quoted 8 lines · On Wed, 25 Nov 2009 18:03:23 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_atiixp: no need to program PIO timings for MWDMAMoreover the code to do it was buggy and programmed PIO timings even if they were already set to a desired values.
There shouldn't be any problems with it as IDE atiixp host driver has been allowing separate PIO/MWDMA timings for last two years.
I need to take a look at the history of this - it got put there for a reason I am sure. Whether a right one I don't know. Needs running past AMD/ATI's maintainer anyway who should know.
PATCH 10/86 pata_atiixp: add MWDMA0 support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_atiixp: add MWDMA0 support
There shouldn't be any problems with it as IDE atiixp host driver has been allowing MWDMA0 mode for last two years.
--- drivers/ata/pata_atiixp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_atiixp.c +1 -1
@@ -207,7 +207,7 @@ static int atiixp_init_one(struct pci_destatic const struct ata_port_info info = { .flags =ATA_FLAG_SLAVE_POSS , .pio_mask =ATA_PIO4 , - .mwdma_mask =ATA_MWDMA12_ONLY , + .mwdma_mask =ATA_MWDMA2 , .udma_mask =ATA_UDMA5 , .port_ops = &atiixp_port_ops };
PATCH 11/86 pata_atiixp: remove custom BMDMA methods
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_atiixp: remove custom BMDMA methods
Enable/disable UDMA bit only once in ->set_dmamode method and then remove custom ->bmdma_[start,stop] methods.
There shouldn't be any problems with it as IDE atiixp host driver has been doing it this way for last two years.
--- drivers/ata/pata_atiixp.c | 58 ++++------------------------------------------ 1 file changed, 6 insertions(+), 52 deletions(-)
drivers/ata/pata_atiixp.c +6 -52
@@ -107,6 +107,9 @@ static void atiixp_set_dmamode(struct atstruct pci_dev *pdev =to_pci_dev (ap->host->dev);int dma = adev->dma_mode;int dn =2 * ap->port_no + adev->devno; +u16 tmp16; + +pci_read_config_word (pdev,ATIIXP_IDE_UDMA_CONTROL , &tmp16);if (adev->dma_mode >=XFER_UDMA_0 ) {u16 udma_mode_data;
@@ -117,6 +120,8 @@ static void atiixp_set_dmamode(struct at udma_mode_data &= ~(0x7 << (4 * dn)); udma_mode_data |= dma << (4 * dn);pci_write_config_word (pdev,ATIIXP_IDE_UDMA_MODE , udma_mode_data); + + tmp16 |= (1 << dn); }else {int timing_shift = (16 * ap->port_no) +8 * (adev->devno ^1 );u32 mwdma_timing_data;
@@ -129,60 +134,11 @@ static void atiixp_set_dmamode(struct at mwdma_timing_data |= (mwdma_timings[dma] << timing_shift);pci_write_config_dword (pdev,ATIIXP_IDE_MWDMA_TIMING , mwdma_timing_data); - } -} - -/** -* atiixp_bmdma_start - DMA start callback -* @qc: Command in progress -* -* When DMA begins we need to ensure that the UDMA control -* register for the channel is correctly set. -* -* Note: The host lock held by the libata layer protects -* us from two channels both trying to set DMA bits at once -*/ - -static void atiixp_bmdma_start (struct ata_queued_cmd *qc) -{ -struct ata_port *ap = qc->ap; -struct ata_device *adev = qc->dev; - -struct pci_dev *pdev =to_pci_dev (ap->host->dev); -int dn = (2 * ap->port_no) + adev->devno; -u16 tmp16; -pci_read_config_word (pdev,ATIIXP_IDE_UDMA_CONTROL , &tmp16); -if (ata_using_udma (adev)) - tmp16 |= (1 << dn); -else tmp16 &= ~(1 << dn); -pci_write_config_word (pdev,ATIIXP_IDE_UDMA_CONTROL , tmp16); -ata_bmdma_start (qc); -} - -/** -* atiixp_dma_stop - DMA stop callback -* @qc: Command in progress -* -* DMA has completed. Clear the UDMA flag as the next operations will -* be PIO ones not UDMA data transfer. -* -* Note: The host lock held by the libata layer protects -* us from two channels both trying to set DMA bits at once -*/ - -static void atiixp_bmdma_stop (struct ata_queued_cmd *qc) -{ -struct ata_port *ap = qc->ap; -struct pci_dev *pdev =to_pci_dev (ap->host->dev); -int dn = (2 * ap->port_no) + qc->dev->devno; -u16 tmp16; + } -pci_read_config_word (pdev,ATIIXP_IDE_UDMA_CONTROL , &tmp16); - tmp16 &= ~(1 << dn);pci_write_config_word (pdev,ATIIXP_IDE_UDMA_CONTROL , tmp16); -ata_bmdma_stop (qc); }static struct scsi_host_template atiixp_sht = {
@@ -194,8 +150,6 @@ static struct ata_port_operations atiixp .inherits = &ata_bmdma32_port_ops, .qc_prep = ata_sff_dumb_qc_prep, - .bmdma_start = atiixp_bmdma_start, - .bmdma_stop = atiixp_bmdma_stop, .cable_detect = atiixp_cable_detect, .set_piomode = atiixp_set_piomode,
Re: [PATCH 11/86] pata_atiixp: remove custom BMDMA methods
Quoted 8 lines · On Wed, 25 Nov 2009 18:03:37 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_atiixp: remove custom BMDMA methodsEnable/disable UDMA bit only once in ->set_dmamode method and then remove custom ->bmdma_[start,stop] methods.
There shouldn't be any problems with it as IDE atiixp host driver has been doing it this way for last two years.
This comes from the original ATI code so should be double checked with ATI but seems reasonable if it works.
PATCH 12/86 pata_atiixp: add proper ->prereset method
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_atiixp: add proper ->prereset method
--- drivers/ata/pata_atiixp.c | 35 ++++++++++++++++++++++++++--------- 1 file changed, 26 insertions(+), 9 deletions(-)
drivers/ata/pata_atiixp.c +26 -9
@@ -47,6 +47,31 @@ static int atiixp_cable_detect(struct at }/** +* atiixp_prereset - perform reset handling +* @link: ATA link +* @deadline: deadline jiffies for the operation +* +* Reset sequence checking enable bits to see which ports are +* active. +*/ + +static int atiixp_prereset (struct ata_link *link,unsigned long deadline) +{ +static const struct pci_bits atiixp_enable_bits[] = { + {0x48 ,1 ,0x01 ,0x00 }, + {0x48 ,1 ,0x08 ,0x00 } + }; + +struct ata_port *ap = link->ap; +struct pci_dev *pdev =to_pci_dev (ap->host->dev); + +if (!pci_test_config_bits (pdev, &atiixp_enable_bits[ap->port_no])) +return -ENOENT ; + +return ata_sff_prereset (link, deadline); +} + +/** * atiixp_set_pio_timing - set initial PIO mode data * @ap: ATA interface * @adev: ATA device
@@ -151,6 +176,7 @@ static struct ata_port_operations atiixp .qc_prep = ata_sff_dumb_qc_prep, + .prereset = atiixp_prereset, .cable_detect = atiixp_cable_detect, .set_piomode = atiixp_set_piomode, .set_dmamode = atiixp_set_dmamode,
@@ -165,16 +191,7 @@ static int atiixp_init_one(struct pci_de .udma_mask = ATA_UDMA5, .port_ops = &atiixp_port_ops }; -static const struct pci_bits atiixp_enable_bits[] = { - {0x48 ,1 ,0x01 ,0x00 }, - {0x48 ,1 ,0x08 ,0x00 } - };const struct ata_port_info *ppi[] = { &info, &info }; -int i; - -for (i =0 ; i <2 ; i++) -if (!pci_test_config_bits (pdev, &atiixp_enable_bits[i])) - ppi[i] = &ata_dummy_port_info;return ata_pci_sff_init_one (pdev, ppi, &atiixp_sht,NULL ); }
Re: [PATCH 12/86] pata_atiixp: add proper ->prereset method
Quoted 3 lines · On Wed, 25 Nov 2009 18:03:44 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_atiixp: add proper ->prereset method
The original seems cleaner here.
PATCH 13/86 pata_efar: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_efar: add 32-bit PIO support
There shouldn't be any problems with it as IDE slc90e66 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_efar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_efar.c +1 -1
@@ -223,7 +223,7 @@ static struct scsi_host_template efar_sh };static struct ata_port_operations efar_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .cable_detect = efar_cable_detect, .set_piomode = efar_set_piomode, .set_dmamode = efar_set_dmamode,
PATCH 14/86 pata_efar: fix wrong PIO timings being programmed
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_efar: fix wrong PIO timings being programmed
* do not clear PIO timings for master when programming slave
* do not clear PIO timings for device on the other port when programming slave device
Both changes should be safe as this is how we have been doing things in IDE slc90e66 host driver for years.
--- drivers/ata/pata_efar.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/ata/pata_efar.c +3 -2
@@ -2,6 +2,7 @@* pata_efar.c - EFAR PIIX clone controller driver * * (C) 2005 Red Hat +* (C) 2009 Bartlomiej Zolnierkiewicz * * Some parts based on ata_piix.c by Jeff Garzik and others. *
@@ -118,12 +119,12 @@ static void efar_set_piomode (struct ataint shift =4 * ap->port_no;u8 slave_data; - idetm_data &=0xCC0F ; + idetm_data &=0xFF0F ; idetm_data |= (control <<4 );/* Slave timing in separate register */ pci_read_config_byte (dev,0x44 , &slave_data); - slave_data &=0x0F << shift; + slave_data &= ap->port_no ?0x0F :0xF0 ; slave_data |= ((timings[pio][0 ] <<2 ) | timings[pio][1 ]) << shift;pci_write_config_byte (dev,0x44 , slave_data); }
PATCH 15/86 pata_efar: fix wrong MWDMA timings being programmed
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_efar: fix wrong MWDMA timings being programmed
Do not clear MWDMA timings for device on the other port when programming slave device.
This change should be safe as this is how we have been doing things in IDE slc90e66 host driver for years.
--- drivers/ata/pata_efar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_efar.c +1 -1
@@ -201,7 +201,7 @@ static void efar_set_dmamode (struct ata master_data &=0xFF4F ;/* Mask out IORDY|TIME1|DMAONLY */ master_data |= control <<4 ;pci_read_config_byte (dev,0x44 , &slave_data); - slave_data &= (0x0F +0xE1 * ap->port_no); + slave_data &= ap->port_no ?0x0F :0xF0 ;/* Load the matching timing */ slave_data |= ((timings[pio][0 ] <<2 ) | timings[pio][1 ]) << (ap->port_no ?4 :0 );pci_write_config_byte (dev,0x44 , slave_data);
PATCH 16/86 pata_efar: MWDMA0 is unsupported
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_efar: MWDMA0 is unsupported
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
This change should be safe as this is how we have been doing things in IDE slc90e66 host driver for years.
--- drivers/ata/pata_efar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_efar.c +1 -1
@@ -252,7 +252,7 @@ static int efar_init_one (struct pci_devstatic const struct ata_port_info info = { .flags =ATA_FLAG_SLAVE_POSS , .pio_mask =ATA_PIO4 , - .mwdma_mask =ATA_MWDMA2 , + .mwdma_mask =ATA_MWDMA12_ONLY , .udma_mask =ATA_UDMA4 , .port_ops = &efar_ops, };
Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported
Quoted 5 lines · On Wed, 25 Nov 2009 18:04:15 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_efar: MWDMA0 is unsupportedMWDMA0 timings cannot be met with the PIIX based controller programming interface.
The efar documentation makes no reference to not being capable of MWDMA0, so where does this come from ? No MWDMA0 is an Intel erratum it appears.
Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported
Quoted 11 lines · Alan Cox
Quoted 5 lines · On Wed, 25 Nov 2009 18:04:15 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_efar: MWDMA0 is unsupportedMWDMA0 timings cannot be met with the PIIX based controller programming interface.
The efar documentation makes no reference to not being capable of MWDMA0, so where does this come from ? No MWDMA0 is an Intel erratum it appears.
No MWDMA0 support is a common issue on all 'PIIX-like' controllers.
In case of this chipset while the (preliminary) documentation claims MWDMA0 support on the 'FEATURES' page the later 'programming guide' part describes only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported
Quoted 10 lines · On Thu, 26 Nov 2009 15:53:58 +0100 Bartlomiej Zolnierkiewicz…
Quoted 9 lines · Alan Cox
Quoted 5 lines · On Wed, 25 Nov 2009 18:04:15 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_efar: MWDMA0 is unsupportedMWDMA0 timings cannot be met with the PIIX based controller programming interface.
Quoted 8 lines
Quoted 2 lines
The efar documentation makes no reference to not being capable of MWDMA0, so where does this come from ? No MWDMA0 is an Intel erratum it appears.
No MWDMA0 support is a common issue on all 'PIIX-like' controllers.
In case of this chipset while the (preliminary) documentation claims MWDMA0 support on the 'FEATURES' page the later 'programming guide' part describes only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.
Cool - I only have the original docs.
Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported
Hello.
Quoted 14 lines · Alan Cox
Quoted 13 lines · Alan Cox
Quoted 12 lines
Quoted 5 lines · On Wed, 25 Nov 2009 18:04:15 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_efar: MWDMA0 is unsupportedMWDMA0 timings cannot be met with the PIIX based controller programming interface.
The efar documentation makes no reference to not being capable of MWDMA0, so where does this come from ? No MWDMA0 is an Intel erratum it appears.
Quoted 7 lines
Quoted 5 lines
No MWDMA0 support is a common issue on all 'PIIX-like' controllers.
In case of this chipset while the (preliminary) documentation claims MWDMA0 support on the 'FEATURES' page the later 'programming guide' part describes only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.
Cool - I only have the original docs.
Hm, me too... perhaps worth putting in Jeff's documentation archive?
MBR, Sergei
Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported
Quoted 20 lines · Sergei Shtylyov
Hello.
Quoted 15 lines · Alan Cox
Quoted 15 lines · Alan Cox
Quoted 4 lines
On Wed, 25 Nov 2009 18:04:15 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:Quoted 8 lines
Quoted 5 lines
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_efar: MWDMA0 is unsupportedMWDMA0 timings cannot be met with the PIIX based controller programming interface.
The efar documentation makes no reference to not being capable of MWDMA0, so where does this come from ? No MWDMA0 is an Intel erratum it appears.
No MWDMA0 support is a common issue on all 'PIIX-like' controllers.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
In case of this chipset while the (preliminary) documentation claims MWDMA0 support on the 'FEATURES' page the later 'programming guide' part describes only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.
Cool - I only have the original docs.
Hm, me too... perhaps worth putting in Jeff's documentation archive?
Me too? I just have what 'The Good Uncle Google' has..
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported
Hello.
Quoted 12 lines · Bartlomiej Zolnierkiewicz
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 5 lines
Quoted 2 lines
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
The efar documentation makes no reference to not being capable of MWDMA0, so where does this come from ? No MWDMA0 is an Intel erratum it appears.
No MWDMA0 support is a common issue on all 'PIIX-like' controllers.
In case of this chipset while the (preliminary) documentation claims MWDMA0 support on the 'FEATURES' page the later 'programming guide' part describes only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Cool - I only have the original docs.
Hm, me too... perhaps worth putting in Jeff's documentation archive?
Me too? I just have what 'The Good Uncle Google' has..
Well, I've googled for it and was unable to find any valid links even to
my preliminary version anymore. Perhaps I haven't looked hard enough...
Quoted 2 lines
--
Bartlomiej Zolnierkiewicz
MBR, Sergei
Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported
Quoted 16 lines · Sergei Shtylyov
Hello.
Quoted 11 lines · Bartlomiej Zolnierkiewicz
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 5 lines
Quoted 2 lines
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
The efar documentation makes no reference to not being capable of MWDMA0, so where does this come from ? No MWDMA0 is an Intel erratum it appears.
No MWDMA0 support is a common issue on all 'PIIX-like' controllers.
In case of this chipset while the (preliminary) documentation claims MWDMA0 support on the 'FEATURES' page the later 'programming guide' part describes only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Cool - I only have the original docs.
Hm, me too... perhaps worth putting in Jeff's documentation archive?
Me too? I just have what 'The Good Uncle Google' has..
Well, I've googled for it and was unable to find any valid links even to
my preliminary version anymore. Perhaps I haven't looked hard enough...
Maybe... ;)
FWIW my file is called 38384_SMSC_SLC90E66.pdf
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported
Quoted 16 lines · Bartlomiej Zolnierkiewicz
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
The efar documentation makes no reference to not being capable of MWDMA0, so where does this come from ? No MWDMA0 is an Intel erratum it appears.
Quoted 7 lines
Quoted 5 lines
No MWDMA0 support is a common issue on all 'PIIX-like' controllers.
In case of this chipset while the (preliminary) documentation claims MWDMA0 support on the 'FEATURES' page the later 'programming guide' part describes only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.
Cool - I only have the original docs.
Hm, me too... perhaps worth putting in Jeff's documentation archive?
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Me too? I just have what 'The Good Uncle Google' has..
Well, I've googled for it and was unable to find any valid links even to
my preliminary version anymore. Perhaps I haven't looked hard enough...Maybe... ;)
FWIW my file is called 38384_SMSC_SLC90E66.pdf
Well, that brought me to some Chinese site with 07/10/2002 version
(which I've already found minutes before that). But it still claims support for MWDMA0 under the features... ah, I need to look further down... no "programming guide" part, hm... but thanks anyway. :-)
Quoted 2 lines
--
Bartlomiej Zolnierkiewicz
WBR, Sergei
Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported
In reply to Alan CoxQuoted 16 lines · Alan Cox
Quoted 13 lines · On Thu, 26 Nov 2009 15:53:58 +0100 Bartlomiej…
Quoted 11 lines · Alan Cox
Quoted 5 lines · On Wed, 25 Nov 2009 18:04:15 +0100 Bartlomiej…
From: Bartlomiej Zolnierkiewicz<[email protected]>
Subject: [PATCH]pata_efar: MWDMA0 is unsupportedMWDMA0 timings cannot be met with the PIIX based controller programming interface.
The efar documentation makes no reference to not being capable of MWDMA0, so where does this come from ? No MWDMA0 is an Intel erratum it appears.
Quoted 7 lines
Quoted 5 lines
No MWDMA0 support is a common issue on all 'PIIX-like' controllers.
In case of this chipset while the (preliminary) documentation claims MWDMA0 support on the 'FEATURES' page the later 'programming guide' part describes only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.
Cool - I only have the original docs.
ACK Bart's patch, then?
This thread was a bit unclear, and I want to be certain (well, as certain as we can be :))
Jeff
PATCH 17/86 pata_efar: fix register naming used in efar_set_piomode()
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_efar: fix register naming used in efar_set_piomode()
Rename 'idetm_port' and 'idetm_data' variables to 'master_port' and 'master_data' respectively to match register naming used in efar_set_dma_mode() and in ata_piix.c.
Fix efar_set_piomode() documentation and 'master_port' type while at it.
--- drivers/ata/pata_efar.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
drivers/ata/pata_efar.c +11 -11
@@ -71,7 +71,7 @@ static int efar_cable_detect(struct ata_/** * efar_set_piomode - Initialize host controller PATA PIO timings * @ap: Port whose timings we are configuring -* @adev: um +* @adev: Device to program * * Set PIO mode for device, in host controller PCI config space. *
@@ -83,8 +83,8 @@ static void efar_set_piomode (struct ata {unsigned int pio = adev->pio_mode -XFER_PIO_0 ;struct pci_dev *dev =to_pci_dev (ap->host->dev); -unsigned int idetm_port= ap->port_no ?0x42 :0x40 ; -u16 idetm_data; +u8 master_port = ap->port_no ?0x42 :0x40 ; +u16 master_data;int control =0 ;/*
@@ -107,20 +107,20 @@ static void efar_set_piomode (struct ataif (adev->class ==ATA_DEV_ATA ) control |=4 ;/* PPE */ -pci_read_config_word (dev, idetm_port, &idetm_data); +pci_read_config_word (dev, master_port, &master_data);/* Set PPE, IE, and TIME as appropriate */ if (adev->devno ==0 ) { - idetm_data &=0xCCF0 ; - idetm_data |= control; - idetm_data |= (timings[pio][0 ] <<12 ) | + master_data &=0xCCF0 ; + master_data |= control; + master_data |= (timings[pio][0 ] <<12 ) | (timings[pio][1 ] <<8 ); }else {int shift =4 * ap->port_no;u8 slave_data; - idetm_data &=0xFF0F ; - idetm_data |= (control <<4 ); + master_data &=0xFF0F ; + master_data |= (control <<4 );/* Slave timing in separate register */ pci_read_config_byte (dev,0x44 , &slave_data);
@@ -129,8 +129,8 @@ static void efar_set_piomode (struct atapci_write_config_byte (dev,0x44 , slave_data); } - idetm_data |=0x4000 ;/* Ensure SITRE is set */ -pci_write_config_word (dev, idetm_port, idetm_data); + master_data |=0x4000 ;/* Ensure SITRE is set */ +pci_write_config_word (dev, master_port, master_data); }/**
Re: [PATCH 17/86] pata_efar: fix register naming used in efar_set_piomode()
Quoted 3 lines
Rename '
idetm_port' and 'idetm_data' variables to 'master_port' and 'master_data' respectively to match register naming used inefar_set_dma_mode()and inata_piix.c.
Probably better to do the reverse to match the docs ?
drivers/ata/pata_efar.c static void efar_set_piomode (struct ata · line 87
Quoted 3 lines
drivers/ata/pata_efar.c +2
-1-u16 idetm_data; +u8 master_port = ap->port_no ?0x42 :0x40 ; +u16 master_data;
Please don't drop undocumented type changes in. And btw it uses unsigned int here as all over the kernel because it produced better code in many cases
These patches seem to spend a lot of time renaming everything in drivers which is usually pointless churn (eg the atp grand renaming), but the bug fixes all look good
Re: [PATCH 17/86] pata_efar: fix register naming used in efar_set_piomode()
Quoted 5 lines · Alan Cox
Quoted 3 lines
Rename '
idetm_port' and 'idetm_data' variables to 'master_port' and 'master_data' respectively to match register naming used inefar_set_dma_mode()and inata_piix.c.Probably better to do the reverse to match the docs ?
It just matches ata_piix.c code currently.
Quoted 5 lines
drivers/ata/pata_efar.c static void efar_set_piomode (struct ata · line 87
Quoted 3 lines
drivers/ata/pata_efar.c +2
-1-u16 idetm_data; +u8 master_port = ap->port_no ?0x42 :0x40 ; +u16 master_data;Please don't drop undocumented type changes in. And btw it uses unsigned
Oh, I forgot to document it in this patch. Others should have it documented.
[ Will fix later. ]
Quoted 2 lines
int here as all over the kernel because it produced better code in many cases
Better code is smaller code in this situation and this is clearly minor issue anyway (since the code is not performance critical having cleaner code wins over).
Quoted 1 line
These patches seem to spend a lot of time renaming everything in drivers
It just prepares the code for unification of code programming PIO and MWDMA methods, see patch #18.
--
Bartlomiej Zolnierkiewicz
PATCH 18/86 pata_efar: unify code for programming PIO and MWDMA timings
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_efar: unify code for programming PIO and MWDMA timings
It results in ~10% decrease in the driver LOC count and also ~8% decrease in the driver binary size (as measured on x86-32).
This change should be safe as this is how we have been doing things in IDE slc90e66 host driver for years.
--- drivers/ata/pata_efar.c | 88 +++++++++++++++--------------------------------- 1 file changed, 29 insertions(+), 59 deletions(-)
drivers/ata/pata_efar.c +29 -59
@@ -68,20 +68,9 @@ static int efar_cable_detect(struct ata_return ATA_CBL_PATA80 ; } -/** -* efar_set_piomode - Initialize host controller PATA PIO timings -* @ap: Port whose timings we are configuring -* @adev: Device to program -* -* Set PIO mode for device, in host controller PCI config space. -* -* LOCKING: -* None (inherited from caller). -*/ - -static void efar_set_piomode (struct ata_port *ap,struct ata_device *adev) +static void efar_set_timings (struct ata_port *ap,struct ata_device *adev, +u8 pio,bool use_mwdma) { -unsigned int pio = adev->pio_mode -XFER_PIO_0 ;struct pci_dev *dev =to_pci_dev (ap->host->dev);u8 master_port = ap->port_no ?0x42 :0x40 ;u16 master_data;
@@ -99,13 +88,18 @@ static void efar_set_piomode (struct ata { 2, 1 }, { 2, 3 }, }; -if (pio >1 ) +if (pio >1 || use_mwdma) control |=1 ;/* TIME */ -if (ata_pio_need_iordy (adev))/* PIO 3/4 require IORDY */ +if (ata_pio_need_iordy (adev) || use_mwdma) control |=2 ;/* IE */ /* Intel specifies that the prefetch/posting is for disk only */ if (adev->class ==ATA_DEV_ATA ) control |=4 ;/* PPE */ +/* If the drive MWDMA is faster than it can do PIO then +we must force PIO into PIO0 */ +if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio)) +/* Enable DMA timing only */ + control |=8 ;/* PIO cycles in PIO0 */ pci_read_config_word (dev, master_port, &master_data);
@@ -134,6 +128,22 @@ static void efar_set_piomode (struct ata }/** +* efar_set_piomode - Initialize host controller PATA PIO timings +* @ap: Port whose timings we are configuring +* @adev: Device to program +* +* Set PIO mode for device, in host controller PCI config space. +* +* LOCKING: +* None (inherited from caller). +*/ + +static void efar_set_piomode (struct ata_port *ap,struct ata_device *adev) +{ +efar_set_timings (ap, adev, adev->pio_mode -XFER_PIO_0 ,0 ); +} + +/** * efar_set_dmamode - Initialize host controller PATA DMA timings * @ap: Port whose timings we are configuring * @adev: Device to program
@@ -147,24 +157,14 @@ static void efar_set_piomode (struct atastatic void efar_set_dmamode (struct ata_port *ap,struct ata_device *adev) {struct pci_dev *dev =to_pci_dev (ap->host->dev); -u8 master_port = ap->port_no ?0x42 :0x40 ; -u16 master_data;u8 speed = adev->dma_mode;int devid = adev->devno +2 * ap->port_no;u8 udma_enable; -static const /* ISP RTC */ -u8 timings[][2 ] = { {0 ,0 }, - {0 ,0 }, - {1 ,0 }, - {2 ,1 }, - {2 ,3 }, }; - -pci_read_config_word (dev, master_port, &master_data);pci_read_config_byte (dev,0x48 , &udma_enable);if (speed >=XFER_UDMA_0 ) { -unsigned int udma = adev->dma_mode -XFER_UDMA_0 ; +unsigned int udma = speed -XFER_UDMA_0 ;u16 udma_timing; udma_enable |= (1 << devid);
@@ -175,46 +175,16 @@ static void efar_set_dmamode (struct ata udma_timing |= udma << (4 * devid);pci_write_config_word (dev,0x4A , udma_timing); }else { -/* -* MWDMA is driven by the PIO timings. We must also enable -* IORDY unconditionally along with TIME1. PPE has already -* been set when the PIO timing was set. -*/ -unsigned int mwdma = adev->dma_mode -XFER_MW_DMA_0 ; -unsigned int control; -u8 slave_data; +/* MWDMA is driven by the PIO timings. */ +unsigned int mwdma = speed -XFER_MW_DMA_0 ;const unsigned int needed_pio[3 ] = {XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 };int pio = needed_pio[mwdma] -XFER_PIO_0 ; - control =3 ;/* IORDY|TIME1 */ - -/* If the drive MWDMA is faster than it can do PIO then -we must force PIO into PIO0 */ +efar_set_timings (ap, adev, pio,1 ); -if (adev->pio_mode < needed_pio[mwdma]) -/* Enable DMA timing only */ - control |=8 ;/* PIO cycles in PIO0 */ - -if (adev->devno) {/* Slave */ - master_data &=0xFF4F ;/* Mask out IORDY|TIME1|DMAONLY */ - master_data |= control <<4 ; -pci_read_config_byte (dev,0x44 , &slave_data); - slave_data &= ap->port_no ?0x0F :0xF0 ; -/* Load the matching timing */ - slave_data |= ((timings[pio][0 ] <<2 ) | timings[pio][1 ]) << (ap->port_no ?4 :0 ); -pci_write_config_byte (dev,0x44 , slave_data); - }else {/* Master */ - master_data &=0xCCF4 ;/* Mask out IORDY|TIME1|DMAONLY -and master timing bits */ - master_data |= control; - master_data |= - (timings[pio][0 ] <<12 ) | - (timings[pio][1 ] <<8 ); - } udma_enable &= ~(1 << devid); -pci_write_config_word (dev, master_port, master_data); }pci_write_config_byte (dev,0x48 , udma_enable); }
PATCH 19/86 pata_cmd640: document known issues
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_cmd640: document known issues
Document known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
--- drivers/ata/Kconfig | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/ata/Kconfig +5 -2
@@ -287,8 +287,11 @@ config PATA_CMD640_PCI depends on PCI && EXPERIMENTAL help This option enables support for the CMD640 PCI IDE - interface chip. Only the primary channel is currently - supported. + interface chip. + + Known issues: + - only the primary channel is currently supported + - only the PCI chip interface is currently supported If unsure, say N.
Re: [PATCH 19/86] pata_cmd640: document known issues
Quoted 6 lines · On Wed, 25 Nov 2009 18:04:36 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_cmd640: document known issuesDocument known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
Umm. its a) under CONFIG_PCI, and b) says CMD640 PCI IDE...
Re: [PATCH 19/86] pata_cmd640: document known issues
Quoted 11 lines · Alan Cox
Quoted 6 lines · On Wed, 25 Nov 2009 18:04:36 +0100 Bartlomiej…
From: Bartlomiej Zolnierkiewicz<[email protected]>
Subject: [PATCH]pata_cmd640: document known issuesDocument known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
Umm. its a) under
CONFIG_PCI, and b) says CMD640 PCI IDE...
Agreed, that's a bit redundant.
Also, as I noted in another email, known issues should be listed in the driver source code at the top of the file, not in Kconfig.
That way the list of known issues actually follows the implementation, as the source code is copied around various kernel trees.
Jeff
Re: [PATCH 19/86] pata_cmd640: document known issues
Quoted 11 lines · Jeff Garzik
Quoted 10 lines · Alan Cox
Quoted 6 lines · On Wed, 25 Nov 2009 18:04:36 +0100 Bartlomiej…
From: Bartlomiej Zolnierkiewicz<[email protected]>
Subject: [PATCH]pata_cmd640: document known issuesDocument known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
Quoted 6 lines
Quoted 1 line
Umm. its a) under
CONFIG_PCI, and b) says CMD640 PCI IDE...Agreed, that's a bit redundant.
Also, as I noted in another email, known issues should be listed in the driver source code at the top of the file, not in
Kconfig.
Agreed, since virtually everybody should be looking into source code of each single driver before compiling kernel and/or deciding to include it into distribution kernel.
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 19/86] pata_cmd640: document known issues
In reply to Alan CoxQuoted 11 lines · Alan Cox
Quoted 6 lines · On Wed, 25 Nov 2009 18:04:36 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_cmd640: document known issuesDocument known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
Umm. its a) under
CONFIG_PCI, and b) says CMD640 PCI IDE...
c)
* This drives only the PCI version of the controller. If you have a * VLB one then we have enough docs to support it but you can write * your own code.
Then what has happened to CMD640 VLB IDE support in libata?
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 19/86] pata_cmd640: document known issues
Quoted 13 lines · On Wed, 25 Nov 2009 18:34:04 +0100 Bartlomiej Zolnierkiewicz…
Quoted 11 lines · Alan Cox
Quoted 6 lines · On Wed, 25 Nov 2009 18:04:36 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_cmd640: document known issuesDocument known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
Umm. its a) under
CONFIG_PCI, and b) says CMD640 PCI IDE...
Quoted 7 lines
c)
* This drives only the PCI version of the controller. If you have a * VLB one then we have enough docs to support it but you can write * your own code.Then what has happened to CMD640 VLB IDE support in libata?
There is none. Nobody has complained about that either, and in fact I've not even been able to find a board on ebay to test either driver with VLB !
PATCH 20/86 pata_cmd64x: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_cmd64x: add 32-bit PIO support
There shouldn't be any problems with it as IDE cmd64x host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_cmd64x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_cmd64x.c +1 -1
@@ -270,7 +270,7 @@ static struct scsi_host_template cmd64x_ };static const struct ata_port_operations cmd64x_base_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .set_piomode = cmd64x_set_piomode, .set_dmamode = cmd64x_set_dmamode, };
PATCH 21/86 pata_cmd64x: add enablebits checking
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_cmd64x: add enablebits checking
There shouldn't be any problems with it as IDE cmd64x host driver has been supporting enablebits checking for years.
--- drivers/ata/pata_cmd64x.c | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+)
drivers/ata/pata_cmd64x.c +36 -0
@@ -2,6 +2,7 @@* pata_cmd64x.c - CMD64x PATA for new ATA layer * (C) 2005 Red Hat Inc * Alan Cox <[email protected]> +* (C) 2009 Bartlomiej Zolnierkiewicz * * Based upon * linux/drivers/ide/pci/cmd64x.c Version 1.30 Sept 10, 2002
@@ -88,6 +89,40 @@ static int cmd648_cable_detect(struct at }/** +* cmd64x_prereset - perform reset handling +* @link: ATA link +* @deadline: deadline jiffies for the operation +* +* Reset sequence checking enable bits to see which ports are +* active. +*/ + +static int cmd64x_prereset (struct ata_link *link,unsigned long deadline) +{ +static const struct pci_bits cmd64x_enable_bits[] = { + {0x51 ,1 ,0x04 ,0x04 }, + {0x51 ,1 ,0x08 ,0x08 } + }; + +struct ata_port *ap = link->ap; +struct pci_dev *pdev =to_pci_dev (ap->host->dev); + +/* +* The original PCI0643 and PCI0646 didn't have the primary +* channel enable bit, it appeared starting with PCI0646U +* (i.e. revision ID 3). +*/ +if (pdev->device ==PCI_DEVICE_ID_CMD_643 || + (pdev->device ==PCI_DEVICE_ID_CMD_646 && pdev->revision <3 )) + goto out; + +if (!pci_test_config_bits (pdev, &cmd64x_enable_bits[ap->port_no])) +return -ENOENT ; +out: +return ata_sff_prereset (link, deadline); +} + +/** * cmd64x_set_piomode - set PIO and MWDMA timing * @ap: ATA interface * @adev: ATA device
@@ -278,6 +313,7 @@ static const struct ata_port_operationsstatic struct ata_port_operations cmd64x_port_ops = { .inherits = &cmd64x_base_ops, .cable_detect = ata_cable_40wire, + .prereset = cmd64x_prereset, };static struct ata_port_operations cmd646r1_port_ops = {
PATCH 22/86 pata_cmd64x: add cmd64x_fixup()
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_cmd64x: add cmd64x_fixup()
Factor out common code from cmd64x_[re]init_one() to cmd64x_fixup().
Remove stale comment and fix CodingStyle issue while at it.
--- drivers/ata/pata_cmd64x.c | 41 +++++++++++++++++++---------------------- 1 file changed, 19 insertions(+), 22 deletions(-)
drivers/ata/pata_cmd64x.c +19 -22
@@ -292,6 +292,22 @@ static struct ata_port_operations cmd648 .cable_detect = cmd648_cable_detect, }; +static void cmd64x_fixup (struct pci_dev *pdev) +{ +u8 mrdmode; + +pci_write_config_byte (pdev,PCI_LATENCY_TIMER ,64 ); +pci_read_config_byte (pdev,MRDMODE , &mrdmode); + mrdmode &= ~0x30 ;/* IRQ set up */ + mrdmode |=0x02 ;/* Memory read line enable */ +pci_write_config_byte (pdev,MRDMODE , mrdmode); + +/* PPC specific fixup copied from old driver */ +#ifdef CONFIG_PPC +pci_write_config_byte (pdev,UDIDETCR0 ,0xF0 ); +#endif +} +static int cmd64x_init_one (struct pci_dev *pdev,const struct pci_device_id *id) {u32 class_rev;
@@ -338,7 +354,6 @@ static int cmd64x_init_one(struct pci_de } };const struct ata_port_info *ppi[] = { &cmd_info[id->driver_data],NULL }; -u8 mrdmode;int rc; rc =pcim_enable_device (pdev);
@@ -360,18 +375,7 @@ static int cmd64x_init_one(struct pci_de ppi[0 ] = &cmd_info[3 ]; } -pci_write_config_byte (pdev,PCI_LATENCY_TIMER ,64 ); -pci_read_config_byte (pdev,MRDMODE , &mrdmode); - mrdmode &= ~0x30 ;/* IRQ set up */ - mrdmode |=0x02 ;/* Memory read line enable */ -pci_write_config_byte (pdev,MRDMODE , mrdmode); - -/* Force PIO 0 here.. */ - -/* PPC specific fixup copied from old driver */ -#ifdef CONFIG_PPC -pci_write_config_byte (pdev,UDIDETCR0 ,0xF0 ); -#endif +cmd64x_fixup (pdev);return ata_pci_sff_init_one (pdev, ppi, &cmd64x_sht,NULL ); }
@@ -380,21 +384,14 @@ static int cmd64x_init_one(struct pci_destatic int cmd64x_reinit_one (struct pci_dev *pdev) {struct ata_host *host =dev_get_drvdata (&pdev->dev); -u8 mrdmode;int rc; rc =ata_pci_device_do_resume (pdev);if (rc)return rc; -pci_write_config_byte (pdev,PCI_LATENCY_TIMER ,64 ); -pci_read_config_byte (pdev,MRDMODE , &mrdmode); - mrdmode &= ~0x30 ;/* IRQ set up */ - mrdmode |=0x02 ;/* Memory read line enable */ -pci_write_config_byte (pdev,MRDMODE , mrdmode); -#ifdef CONFIG_PPC -pci_write_config_byte (pdev,UDIDETCR0 ,0xF0 ); -#endif +cmd64x_fixup (pdev); +ata_host_resume (host);return 0 ; }
PATCH 23/86 pata_cs5520: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_cs5520: add 32-bit PIO support
There shouldn't be any problems with it as IDE cs5520 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_cs5520.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_cs5520.c +1 -1
@@ -145,7 +145,7 @@ static struct scsi_host_template cs5520_ };static struct ata_port_operations cs5520_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .qc_prep = ata_sff_dumb_qc_prep, .cable_detect = ata_cable_40wire, .set_piomode = cs5520_set_piomode,
PATCH 24/86 pata_cs5520: remove dead VDMA support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_cs5520: remove dead VDMA support
It has been dead for the last three years (== since the initial driver merge) and probability that it will ever get fixed is quite low.
Since there is no reason to keep this dead code around any longer just remove it (it can still be retrieved from the git history if necessary).
--- drivers/ata/pata_cs5520.c | 39 +-------------------------------------- 1 file changed, 1 insertion(+), 38 deletions(-)
drivers/ata/pata_cs5520.c +1 -38
@@ -90,48 +90,12 @@ static void cs5520_set_timings(struct at }/** -* cs5520_enable_dma - turn on DMA bits -* -* Turn on the DMA bits for this disk. Needed because the BIOS probably -* has not done the work for us. Belongs in the core SATA code. -*/ - -static void cs5520_enable_dma (struct ata_port *ap,struct ata_device *adev) -{ -/* Set the DMA enable/disable flag */ -u8 reg =ioread8 (ap->ioaddr.bmdma_addr +0x02 ); - reg |=1 <<(adev->devno +5 ); -iowrite8 (reg, ap->ioaddr.bmdma_addr +0x02 ); -} - -/** -* cs5520_set_dmamode - program DMA timings -* @ap: ATA port -* @adev: ATA device -* -* Program the DMA mode timings for the controller according to the pio -* clocking table. Note that this device sets the DMA timings to PIO -* mode values. This may seem bizarre but the 5520 architecture talks -* PIO mode to the disk and DMA mode to the controller so the underlying -* transfers are PIO timed. -*/ - -static void cs5520_set_dmamode (struct ata_port *ap,struct ata_device *adev) -{ -static const int dma_xlate[3 ] = {XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 }; -cs5520_set_timings (ap, adev, dma_xlate[adev->dma_mode]); -cs5520_enable_dma (ap, adev); -} - -/** * cs5520_set_piomode - program PIO timings * @ap: ATA port * @adev: ATA device * * Program the PIO mode timings for the controller according to the pio -* clocking table. We know pio_mode will equal dma_mode because of the -* CS5520 architecture. At least once we turned DMA on and wrote a -* mode setter. +* clocking table. */ static void cs5520_set_piomode (struct ata_port *ap,struct ata_device *adev)
@@ -149,7 +113,6 @@ static struct ata_port_operations cs5520 .qc_prep = ata_sff_dumb_qc_prep, .cable_detect = ata_cable_40wire, .set_piomode = cs5520_set_piomode, - .set_dmamode = cs5520_set_dmamode, };static int __devinit cs5520_init_one (struct pci_dev *pdev,const struct pci_device_id *id)
Re: [PATCH 24/86] pata_cs5520: remove dead VDMA support
Quoted 5 lines · On Wed, 25 Nov 2009 18:05:11 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_cs5520: remove dead VDMA supportIt has been dead for the last three years (== since the initial driver merge) and probability that it will ever get fixed is quite low.
Agreed entirely. SIL680 VDMA might be worth doing and in turn CS5520 in passing but CS5520 is mostly an ex-chip
PATCH 25/86 pata_cs5530: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_cs5530: add 32-bit PIO support
There shouldn't be any problems with it as IDE cs5530 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_cs5530.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_cs5530.c +1 -1
@@ -165,7 +165,7 @@ static struct scsi_host_template cs5530_ };static struct ata_port_operations cs5530_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .qc_prep = ata_sff_dumb_qc_prep, .qc_issue = cs5530_qc_issue,
PATCH 26/86 pata_cs5535: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_cs5535: add 32-bit PIO support
There shouldn't be any problems with it as IDE cs5535 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_cs5535.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_cs5535.c +1 -1
@@ -161,7 +161,7 @@ static struct scsi_host_template cs5535_ };static struct ata_port_operations cs5535_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .cable_detect = cs5535_cable_detect, .set_piomode = cs5535_set_piomode, .set_dmamode = cs5535_set_dmamode,
PATCH 27/86 pata_cs5535: no need to program PIO0 timings during device init
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_cs5535: no need to program PIO0 timings during device init
Core libata code takes care of it nowadays.
--- drivers/ata/pata_cs5535.c | 12 ------------ 1 file changed, 12 deletions(-)
drivers/ata/pata_cs5535.c +0 -12
@@ -67,8 +67,6 @@#define CS5535_CABLE_DETECT 0x48 -#define CS5535_BAD_PIO (timings) ( (timings&~0x80000000UL)==0x00009172 ) -/** * cs5535_cable_detect - detect cable type * @ap: Port to detect on
@@ -188,16 +186,6 @@ static int cs5535_init_one(struct pci_de };const struct ata_port_info *ppi[] = { &info, &ata_dummy_port_info }; -u32 timings, dummy; - -/* Check the BIOS set the initial timing clock. If not set the -timings for PIO0 */ -rdmsr (ATAC_CH0D0_PIO , timings, dummy); -if (CS5535_BAD_PIO (timings)) -wrmsr (ATAC_CH0D0_PIO ,0xF7F4F7F4UL ,0 ); -rdmsr (ATAC_CH0D1_PIO , timings, dummy); -if (CS5535_BAD_PIO (timings)) -wrmsr (ATAC_CH0D1_PIO ,0xF7F4F7F4UL ,0 );return ata_pci_sff_init_one (dev, ppi, &cs5535_sht,NULL ); }
PATCH 28/86 pata_cypress: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_cypress: add 32-bit PIO support
There shouldn't be any problems with it as IDE cy82c693 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_cypress.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_cypress.c +1 -1
@@ -114,7 +114,7 @@ static struct scsi_host_template cy82c69 };static struct ata_port_operations cy82c693_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .cable_detect = ata_cable_40wire, .set_piomode = cy82c693_set_piomode, .set_dmamode = cy82c693_set_dmamode,
PATCH 29/86 pata_cypress: document known issues
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_cypress: document known issues
Document known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
--- drivers/ata/Kconfig | 3 +++ 1 file changed, 3 insertions(+)
drivers/ata/Kconfig +3 -0
@@ -344,6 +344,9 @@ config PATA_CYPRESS This option enables support for the Cypress/Contaq CY82C693 chipset found in some Alpha systems + Known issues: + - only the primary channel is currently supported + If unsure, say N. config PATA_EFAR
PATCH 30/86 pata_hpt366: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_hpt366: add 32-bit PIO support
There shouldn't be any problems with it as IDE hpt366 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_hpt366.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_hpt366.c +1 -1
@@ -283,7 +283,7 @@ static struct scsi_host_template hpt36x_*/ static struct ata_port_operations hpt366_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .cable_detect = hpt36x_cable_detect, .mode_filter = hpt366_filter, .set_piomode = hpt366_set_piomode,
PATCH 31/86 pata_hpt37x: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_hpt37x: add 32-bit PIO support
There shouldn't be any problems with it as IDE hpt366 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_hpt37x.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ata/pata_hpt37x.c +2 -2
@@ -579,7 +579,7 @@ static struct scsi_host_template hpt37x_*/ static struct ata_port_operations hpt370_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .bmdma_stop = hpt370_bmdma_stop,
@@ -604,7 +604,7 @@ static struct ata_port_operations hpt370*/ static struct ata_port_operations hpt372_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .bmdma_stop = hpt37x_bmdma_stop,
PATCH 32/86 pata_hpt3x2n: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_hpt3x2n: add 32-bit PIO support
There shouldn't be any problems with it as IDE hpt366 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_hpt3x2n.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_hpt3x2n.c +1 -1
@@ -335,7 +335,7 @@ static struct scsi_host_template hpt3x2n*/ static struct ata_port_operations hpt3x2n_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .bmdma_stop = hpt3x2n_bmdma_stop, .qc_issue = hpt3x2n_qc_issue,
PATCH 33/86 pata_hpt3x3: Power Management fix
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_hpt3x3: Power Management fix
Fix ->resume method to re-enable & re-init PCI device properly before doing chipset specific setup.
--- drivers/ata/pata_hpt3x3.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/ata/pata_hpt3x3.c +10 -1
@@ -255,8 +255,17 @@ static int hpt3x3_init_one(struct pci_de#ifdef CONFIG_PM static int hpt3x3_reinit_one (struct pci_dev *dev) { +struct ata_host *host =dev_get_drvdata (&dev->dev); +int rc; + + rc =ata_pci_device_do_resume (dev); +if (rc) +return rc; +hpt3x3_init_chipset (dev); -return ata_pci_device_resume (dev); + +ata_host_resume (host); +return 0 ; }#endif
PATCH 34/86 pata_it8213: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_it8213: add 32-bit PIO support
There shouldn't be any problems with it as IDE it8213 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_it8213.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_it8213.c +1 -1
@@ -235,7 +235,7 @@ static struct scsi_host_template it8213_static struct ata_port_operations it8213_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .cable_detect = it8213_cable_detect, .set_piomode = it8213_set_piomode, .set_dmamode = it8213_set_dmamode,
PATCH 35/86 pata_it8213: fix UDMA handling
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_it8213: fix UDMA handling
Driver should program the cycle timing not the mode number (doing the latter results in wrong timings being used).
There shouldn't be any problems with it as IDE it8213 host driver has been doing it this way for years.
--- drivers/ata/pata_it8213.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ata/pata_it8213.c +2 -2
@@ -173,10 +173,10 @@ static void it8213_set_dmamode (struct a udma_enable |= (1 << devid); -/* Load the UDMA mode number */ +/* Load the UDMA cycle time */ pci_read_config_word (dev,0x4A , &udma_timing); udma_timing &= ~(3 << (4 * devid)); - udma_timing |= (udma &3 ) << (4 * devid); + udma_timing |= u_speed << (4 * devid);pci_write_config_word (dev,0x4A , udma_timing);/* Load the clock selection */
PATCH 36/86 pata_it8213: add UDMA100 and UDMA133 support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_it8213: add UDMA100 and UDMA133 support
There shouldn't be any problems with it as IDE it8213 host driver has been supporting UDMA100 and UDMA133 for years.
--- drivers/ata/pata_it8213.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ata/pata_it8213.c +2 -2
@@ -164,7 +164,7 @@ static void it8213_set_dmamode (struct a/* Clocks follow the PIIX style */ u_speed =min (2 - (udma &1 ), udma); -if (udma ==5 ) +if (udma >4 ) u_clock =0x1000 ;/* 100Mhz */ else if (udma >2 ) u_clock =1 ;/* 66Mhz */
@@ -264,7 +264,7 @@ static int it8213_init_one (struct pci_d .flags = ATA_FLAG_SLAVE_POSS, .pio_mask = ATA_PIO4, .mwdma_mask = ATA_MWDMA2, - .udma_mask = ATA_UDMA4, /* FIXME: want UDMA 100? */ + .udma_mask = ATA_UDMA6, .port_ops = &it8213_ops, };/* Current IT8213 stuff is single port */
Re: [PATCH 36/86] pata_it8213: add UDMA100 and UDMA133 support
Hello.
Quoted 19 lines · Bartlomiej Zolnierkiewicz
There shouldn't be any problems with it as IDE it8213 host driver has been supporting UDMA100 and UDMA133 for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Index:
b/drivers/ata/pata_it8213.c
===================================================================drivers/ata/pata_it8213.c +1
-1@@ -164,7 +164,7 @@ static void it8213_set_dmamode (struct a/* Clocks follow the PIIX style */ u_speed =min (2 - (udma &1 ), udma); -if (udma ==5 ) +if (udma >4 ) u_clock =0x1000 ;/* 100Mhz */ else if (udma >2 ) u_clock =1 ;/* 66Mhz */
drivers/ata/pata_it8213.c static int it8213_init_one (struct pci_d · line 270
Quoted 8 lines
drivers/ata/pata_it8213.c +1
-1@@ -264,7 +264,7 @@ static int it8213_init_one (struct pci_d .flags = ATA_FLAG_SLAVE_POSS, .pio_mask = ATA_PIO4, .mwdma_mask = ATA_MWDMA2, - .udma_mask = ATA_UDMA4, /* FIXME: want UDMA 100? */ + .udma_mask = ATA_UDMA6, .port_ops = &it8213_ops, };/* Current IT8213 stuff is single port */
Well, at 100 MHz it's probably not really UDMA6 but UDMA5 in disguise...
though u_speed would be 2 instead of 1 which should correspond to either 3 clocks or 1 clock according to Intel's documentation (different Intel docs give different figures and even ICH PRM gives *both* clocks).
IOW, I doubt that 'it8213' is correct. Anybody has the datasheet?
MBR, Sergei
Re: [PATCH 36/86] pata_it8213: add UDMA100 and UDMA133 support
Quoted 22 lines · Hello, I wrote:
Quoted 22 lines
There shouldn't be any problems with it as IDE it8213 host driver has been supporting UDMA100 and UDMA133 for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Index:
b/drivers/ata/pata_it8213.c
===================================================================drivers/ata/pata_it8213.c +1
-1@@ -164,7 +164,7 @@ static void it8213_set_dmamode (struct a/* Clocks follow the PIIX style */ u_speed =min (2 - (udma &1 ), udma); -if (udma ==5 ) +if (udma >4 ) u_clock =0x1000 ;/* 100Mhz */ else if (udma >2 ) u_clock =1 ;/* 66Mhz */ @@ -264,7 +264,7 @@ static int it8213_init_one (struct pci_d .flags = ATA_FLAG_SLAVE_POSS, .pio_mask = ATA_PIO4, .mwdma_mask = ATA_MWDMA2,
Quoted 8 lines
drivers/ata/pata_it8213.c static int it8213_init_one (struct pci_d · line 270
Quoted 5 lines
drivers/ata/pata_it8213.c +1
-1- .udma_mask = ATA_UDMA4, /* FIXME: want UDMA 100? */ + .udma_mask = ATA_UDMA6, .port_ops = &it8213_ops, };/* Current IT8213 stuff is single port */ Well, at 100 MHz it's probably not really UDMA6 but UDMA5 in
disguise... thoughu_speedwould be 2 instead of 1 which should correspond to either 3 clocks or 1 clock according to Intel's documentation (different Intel docs give different figures and even ICH PRM gives *both* clocks).
If we take 3 clocks as correct (1 clock doesn't seem correct anyways, as
with UDMA mode 5 UDMA cycle must be 20 ns and 1 clock gives only 10 ns). Well, then UDMA5 doesn't seem different from UDMA4 with ICH controllers and it's not clear why all the fuss about 100 MHz bit was necessary... :-/
Returning to IT8213, with UDMA6 we have 'u_speed' of 2 that should
correspond to 2 clocks which is 20 ns at 100 MHz and really is an UDMA5 speed. Well, given UDMA5's slowness, that's definitely a gain. The question remains however, isn't this value reserved like on original ICH?
MBR, Sergei
Re: [PATCH 36/86] pata_it8213: add UDMA100 and UDMA133 support
Quoted 36 lines · Sergei Shtylyov
Quoted 25 lines · Hello, I wrote:
Quoted 25 lines
There shouldn't be any problems with it as IDE it8213 host driver has been supporting UDMA100 and UDMA133 for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Index:
b/drivers/ata/pata_it8213.c
===================================================================drivers/ata/pata_it8213.c +2
-2@@ -164,7 +164,7 @@ static void it8213_set_dmamode (struct a/* Clocks follow the PIIX style */ u_speed =min (2 - (udma &1 ), udma); -if (udma ==5 ) +if (udma >4 ) u_clock =0x1000 ;/* 100Mhz */ else if (udma >2 ) u_clock =1 ;/* 66Mhz */ @@ -264,7 +264,7 @@ static int it8213_init_one (struct pci_d .flags = ATA_FLAG_SLAVE_POSS, .pio_mask = ATA_PIO4, .mwdma_mask = ATA_MWDMA2, - .udma_mask = ATA_UDMA4, /* FIXME: want UDMA 100? */ + .udma_mask = ATA_UDMA6, .port_ops = &it8213_ops,Quoted 8 lines
drivers/ata/pata_it8213.c static int it8213_init_one (struct pci_d · line 270
Quoted 2 lines
drivers/ata/pata_it8213.c +0
-0};/* Current IT8213 stuff is single port */ Well, at 100 MHz it's probably not really UDMA6 but UDMA5 in
disguise... thoughu_speedwould be 2 instead of 1 which should correspond to either 3 clocks or 1 clock according to Intel's documentation (different Intel docs give different figures and even ICH PRM gives *both* clocks).
Quoted 4 lines
If we take 3 clocks as correct (1 clock doesn't seem correct anyways, as
with UDMA mode 5 UDMA cycle must be 20 ns and 1 clock gives only 10 ns). Well, then UDMA5 doesn't seem different from UDMA4 with ICH controllers and it's not clear why all the fuss about 100 MHz bit was necessary... :-/
Sergei, please remember that IT8213 is a _custom_ spin-off from ICH chipset and it gets some things in rather radically different way (i.e. value of PPE bit is reversed on IT8213).
Quoted 4 lines
Returning to IT8213, with UDMA6 we have '
u_speed' of 2 that should
correspond to 2 clocks which is 20 ns at 100 MHz and really is an UDMA5 speed. Well, given UDMA5's slowness, that's definitely a gain. The question remains however, isn't this value reserved like on original ICH?
It is not according to the official documentation for IT8213 (+ the chip officially claims to support UDMA6) and pata_it8213 behavior now matches the behavior of it8213 host driver.
I would love to be able to explain IT8213 chip internals in more detail but unfortunately the documentation is rather cryptic in this regard as it only gives you specific values that you should program into specific registers to get chip properly configured for specific transfer modes...
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 36/86] pata_it8213: add UDMA100 and UDMA133 support
Hello.
Quoted 33 lines · Bartlomiej Zolnierkiewicz
Quoted 32 lines
Quoted 30 lines · Hello, I wrote:
Quoted 19 lines
There shouldn't be any problems with it as IDE it8213 host driver has been supporting UDMA100 and UDMA133 for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Index:
b/drivers/ata/pata_it8213.c
===================================================================drivers/ata/pata_it8213.c +1
-1@@ -164,7 +164,7 @@ static void it8213_set_dmamode (struct a/* Clocks follow the PIIX style */ u_speed =min (2 - (udma &1 ), udma); -if (udma ==5 ) +if (udma >4 ) u_clock =0x1000 ;/* 100Mhz */ else if (udma >2 ) u_clock =1 ;/* 66Mhz */ drivers/ata/pata_it8213.c static int it8213_init_one (struct pci_d · line 270
Quoted 8 lines
drivers/ata/pata_it8213.c +1
-1@@ -264,7 +264,7 @@ static int it8213_init_one (struct pci_d .flags = ATA_FLAG_SLAVE_POSS, .pio_mask = ATA_PIO4, .mwdma_mask = ATA_MWDMA2, - .udma_mask = ATA_UDMA4, /* FIXME: want UDMA 100? */ + .udma_mask = ATA_UDMA6, .port_ops = &it8213_ops, };/* Current IT8213 stuff is single port */ Well, at 100 MHz it's probably not really UDMA6 but UDMA5 in
disguise... thoughu_speedwould be 2 instead of 1 which should correspond to either 3 clocks or 1 clock according to Intel's documentation (different Intel docs give different figures and even ICH PRM gives *both* clocks).
Quoted 2 lines
Quoted 2 lines
If we take 3 clocks as correct (1 clock doesn't seem correct anyways, as
with UDMA mode 5 UDMA cycle must be 20 ns and 1 clock gives only 10 ns). Well, then UDMA5 doesn't seem different from UDMA4 with ICH controllers and it's not clear why all the fuss about 100 MHz bit was necessary... :-/
Unless it's 133 MHz bit in reality... :-)
Quoted 1 line
Sergei, please remember that IT8213 is a _custom_ spin-off from ICH chipset
Well, I don't have IT8213 docs, so have to interpolate from PIIX/ICH
documentation...
Quoted 2 lines
and it gets some things in rather radically different way (i.e. value of PPE bit is reversed on IT8213).
Perhaps then this bit shouldn't be called PPE (concerning your outher
patch)?
Quoted 4 lines
Quoted 2 lines
Returning to IT8213, with UDMA6 we have '
u_speed' of 2 that should
correspond to 2 clocks which is 20 ns at 100 MHz and really is an UDMA5 speed. Well, given UDMA5's slowness, that's definitely a gain. The question remains however, isn't this value reserved like on original ICH?It is not according to the official documentation for IT8213 (+ the chip
Ah, good to know at least soembody has the damn datasheet! :-)
Quoted 2 lines
officially claims to support UDMA6) and
pata_it8213behavior now matches the behavior of it8213 host driver.
OK, fine then...
Quoted 4 lines
I would love to be able to explain IT8213 chip internals in more detail but unfortunately the documentation is rather cryptic in this regard as it only gives you specific values that you should program into specific registers to get chip properly configured for specific transfer modes...
At least something... :-)
Quoted 2 lines
--
Bartlomiej Zolnierkiewicz
MBR, Sergei
PATCH 37/86 pata_it8213: fix wrong PIO timings being programmed
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_it8213: fix wrong PIO timings being programmed
* do not clear PIO timings for master when programming slave
* program new PIO timings in the correct register nibble
Both changes should be safe as this is how we have been doing things in IDE it8213 host driver for years.
--- drivers/ata/pata_it8213.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ata/pata_it8213.c +2 -2
@@ -112,13 +112,13 @@ static void it8213_set_piomode (struct a }else {u8 slave_data; - idetm_data &=0xCC0F ; + idetm_data &=0xFF0F ; idetm_data |= (control <<4 );/* Slave timing in separate register */ pci_read_config_byte (dev,0x44 , &slave_data); slave_data &=0xF0 ; - slave_data |= ((timings[pio][0 ] <<2 ) | timings[pio][1 ]) <<4 ; + slave_data |= (timings[pio][0 ] <<2 ) | timings[pio][1 ];pci_write_config_byte (dev,0x44 , slave_data); }
PATCH 38/86 pata_it8213: fix PIO2 underclocking
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_it8213: fix PIO2 underclocking
[ port of Sergei's fixes for pata_efar from commit 5f33b3b ]
Fix the PIO mode 2 using mode 0 timings -- this driver should enable the fast timing bank starting with PIO2, just like the PIIX/ICH drivers do. Also, fix/rephrase some comments while at it.
--- drivers/ata/pata_it8213.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-)
drivers/ata/pata_it8213.c +6 -7
@@ -92,18 +92,17 @@ static void it8213_set_piomode (struct a { 2, 1 }, { 2, 3 }, }; -if (pio >2 ) - control |=1 ;/* TIME1 enable */ +if (pio >1 ) + control |=1 ;/* TIME */ if (ata_pio_need_iordy (adev))/* PIO 3/4 require IORDY */ - control |=2 ;/* IORDY enable */ + control |=2 ;/* IE */ /* Bit 2 is set for ATAPI on the IT8213 - reverse of ICH/PIIX */ if (adev->class !=ATA_DEV_ATA ) - control |=4 ; + control |=4 ;/* PPE */ pci_read_config_word (dev, idetm_port, &idetm_data); -/* Enable PPE, IE and TIME as appropriate */ - +/* Set PPE, IE, and TIME as appropriate */ if (adev->devno ==0 ) { idetm_data &=0xCCF0 ; idetm_data |= control;
@@ -122,7 +121,7 @@ static void it8213_set_piomode (struct apci_write_config_byte (dev,0x44 , slave_data); } - idetm_data |=0x4000 ;/* Ensure SITRE is enabled */ + idetm_data |=0x4000 ;/* Ensure SITRE is set */ pci_write_config_word (dev, idetm_port, idetm_data); }
PATCH 39/86 pata_it8213: fix wrong MWDMA timings being programmed
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_it8213: fix wrong MWDMA timings being programmed
Clear old MWDMA timings before programming new ones (IT8213 is a single port host so there is no need to check ap->port_no).
This change should be safe as this is how we have been doing things in IDE it8213 host driver for years.
--- drivers/ata/pata_it8213.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_it8213.c +1 -1
@@ -211,7 +211,7 @@ static void it8213_set_dmamode (struct a master_data &=0xFF4F ;/* Mask out IORDY|TIME1|DMAONLY */ master_data |= control <<4 ;pci_read_config_byte (dev,0x44 , &slave_data); - slave_data &= (0x0F +0xE1 * ap->port_no); + slave_data &=0xF0 ;/* Load the matching timing */ slave_data |= ((timings[pio][0 ] <<2 ) | timings[pio][1 ]) << (ap->port_no ?4 :0 );pci_write_config_byte (dev,0x44 , slave_data);
PATCH 40/86 pata_it8213: fix register naming used in it8213_set_piomode()
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_it8213: fix register naming used in it8213_set_piomode()
Rename 'idetm_port' and 'idetm_data' variables to 'master_port' and 'master_data' respectively to match register naming used in it8213_set_dma_mode() and in ata_piix.c.
Fix 'master_port' type while at it.
--- drivers/ata/pata_it8213.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
drivers/ata/pata_it8213.c +10 -10
@@ -76,8 +76,8 @@ static void it8213_set_piomode (struct a {unsigned int pio = adev->pio_mode -XFER_PIO_0 ;struct pci_dev *dev =to_pci_dev (ap->host->dev); -unsigned int idetm_port= ap->port_no ?0x42 :0x40 ; -u16 idetm_data; +u8 master_port = ap->port_no ?0x42 :0x40 ; +u16 master_data;int control =0 ;/*
@@ -100,19 +100,19 @@ static void it8213_set_piomode (struct aif (adev->class !=ATA_DEV_ATA ) control |=4 ;/* PPE */ -pci_read_config_word (dev, idetm_port, &idetm_data); +pci_read_config_word (dev, master_port, &master_data);/* Set PPE, IE, and TIME as appropriate */ if (adev->devno ==0 ) { - idetm_data &=0xCCF0 ; - idetm_data |= control; - idetm_data |= (timings[pio][0 ] <<12 ) | + master_data &=0xCCF0 ; + master_data |= control; + master_data |= (timings[pio][0 ] <<12 ) | (timings[pio][1 ] <<8 ); }else {u8 slave_data; - idetm_data &=0xFF0F ; - idetm_data |= (control <<4 ); + master_data &=0xFF0F ; + master_data |= (control <<4 );/* Slave timing in separate register */ pci_read_config_byte (dev,0x44 , &slave_data);
@@ -121,8 +121,8 @@ static void it8213_set_piomode (struct apci_write_config_byte (dev,0x44 , slave_data); } - idetm_data |=0x4000 ;/* Ensure SITRE is set */ -pci_write_config_word (dev, idetm_port, idetm_data); + master_data |=0x4000 ;/* Ensure SITRE is set */ +pci_write_config_word (dev, master_port, master_data); }/**
PATCH 41/86 pata_efar: unify code for programming PIO and MWDMA timings
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_it8213: unify code for programming PIO and MWDMA timings
It results in ~9% decrease in the driver LOC count and also ~6% decrease in the driver binary size (as measured on x86-32).
--- drivers/ata/pata_it8213.c | 87 +++++++++++++++------------------------------- 1 file changed, 29 insertions(+), 58 deletions(-)
drivers/ata/pata_it8213.c +29 -58
@@ -61,20 +61,9 @@ static int it8213_cable_detect(struct atreturn ATA_CBL_PATA80 ; } -/** -* it8213_set_piomode - Initialize host controller PATA PIO timings -* @ap: Port whose timings we are configuring -* @adev: Device whose timings we are configuring -* -* Set PIO mode for device, in host controller PCI config space. -* -* LOCKING: -* None (inherited from caller). -*/ - -static void it8213_set_piomode (struct ata_port *ap,struct ata_device *adev) +static void it8213_set_timings (struct ata_port *ap,struct ata_device *adev, +u8 pio,bool use_mwdma) { -unsigned int pio = adev->pio_mode -XFER_PIO_0 ;struct pci_dev *dev =to_pci_dev (ap->host->dev);u8 master_port = ap->port_no ?0x42 :0x40 ;u16 master_data;
@@ -92,13 +81,18 @@ static void it8213_set_piomode (struct a { 2, 1 }, { 2, 3 }, }; -if (pio >1 ) +if (pio >1 || use_mwdma) control |=1 ;/* TIME */ -if (ata_pio_need_iordy (adev))/* PIO 3/4 require IORDY */ +if (ata_pio_need_iordy (adev) || use_mwdma) control |=2 ;/* IE */ /* Bit 2 is set for ATAPI on the IT8213 - reverse of ICH/PIIX */ if (adev->class !=ATA_DEV_ATA ) control |=4 ;/* PPE */ +/* If the drive MWDMA is faster than it can do PIO then +we must force PIO into PIO0 */ +if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio)) +/* Enable DMA timing only */ + control |=8 ;/* PIO cycles in PIO0 */ pci_read_config_word (dev, master_port, &master_data);
@@ -127,6 +121,22 @@ static void it8213_set_piomode (struct a }/** +* it8213_set_piomode - Initialize host controller PATA PIO timings +* @ap: Port whose timings we are configuring +* @adev: Device whose timings we are configuring +* +* Set PIO mode for device, in host controller PCI config space. +* +* LOCKING: +* None (inherited from caller). +*/ + +static void it8213_set_piomode (struct ata_port *ap,struct ata_device *adev) +{ +it8213_set_timings (ap, adev, adev->pio_mode -XFER_PIO_0 ,0 ); +} + +/** * it8213_set_dmamode - Initialize host controller PATA DMA timings * @ap: Port whose timings we are configuring * @adev: Device to program
@@ -141,23 +151,14 @@ static void it8213_set_piomode (struct astatic void it8213_set_dmamode (struct ata_port *ap,struct ata_device *adev) {struct pci_dev *dev =to_pci_dev (ap->host->dev); -u16 master_data;u8 speed = adev->dma_mode;int devid = adev->devno;u8 udma_enable; -static const /* ISP RTC */ -u8 timings[][2 ] = { {0 ,0 }, - {0 ,0 }, - {1 ,0 }, - {2 ,1 }, - {2 ,3 }, }; - -pci_read_config_word (dev,0x40 , &master_data);pci_read_config_byte (dev,0x48 , &udma_enable);if (speed >=XFER_UDMA_0 ) { -unsigned int udma = adev->dma_mode -XFER_UDMA_0 ; +unsigned int udma = speed -XFER_UDMA_0 ;u16 udma_timing;u16 ideconf;int u_clock, u_speed;
@@ -185,46 +186,16 @@ static void it8213_set_dmamode (struct a ideconf |= u_clock << devid;pci_write_config_word (dev,0x54 , ideconf); }else { -/* -* MWDMA is driven by the PIO timings. We must also enable -* IORDY unconditionally along with TIME1. PPE has already -* been set when the PIO timing was set. -*/ -unsigned int mwdma = adev->dma_mode -XFER_MW_DMA_0 ; -unsigned int control; -u8 slave_data; +/* MWDMA is driven by the PIO timings. */ +unsigned int mwdma = speed -XFER_MW_DMA_0 ;static const unsigned int needed_pio[3 ] = {XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 };int pio = needed_pio[mwdma] -XFER_PIO_0 ; - control =3 ;/* IORDY|TIME1 */ - -/* If the drive MWDMA is faster than it can do PIO then -we must force PIO into PIO0 */ +it8213_set_timings (ap, adev, pio,1 ); -if (adev->pio_mode < needed_pio[mwdma]) -/* Enable DMA timing only */ - control |=8 ;/* PIO cycles in PIO0 */ - -if (devid) {/* Slave */ - master_data &=0xFF4F ;/* Mask out IORDY|TIME1|DMAONLY */ - master_data |= control <<4 ; -pci_read_config_byte (dev,0x44 , &slave_data); - slave_data &=0xF0 ; -/* Load the matching timing */ - slave_data |= ((timings[pio][0 ] <<2 ) | timings[pio][1 ]) << (ap->port_no ?4 :0 ); -pci_write_config_byte (dev,0x44 , slave_data); - }else {/* Master */ - master_data &=0xCCF4 ;/* Mask out IORDY|TIME1|DMAONLY -and master timing bits */ - master_data |= control; - master_data |= - (timings[pio][0 ] <<12 ) | - (timings[pio][1 ] <<8 ); - } udma_enable &= ~(1 << devid); -pci_write_config_word (dev,0x40 , master_data); }pci_write_config_byte (dev,0x48 , udma_enable); }
Re: [PATCH 41/86] pata_efar: unify code for programming PIO and MWDMA timings
Quoted 20 lines · Bartlomiej Zolnierkiewicz
It results in ~9% decrease in the driver LOC count and also ~6% decrease in the driver binary size (as measured on x86-32).
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/ata/pata_it8213.c | 87 +++++++++++++++------------------------------- 1 file changed, 29 insertions(+), 58 deletions(-)Index:
b/drivers/ata/pata_it8213.c
===================================================================drivers/ata/pata_it8213.c +0
-4@@ -61,20 +61,9 @@ static int it8213_cable_detect(struct atreturn ATA_CBL_PATA80 ; } -/** -* it8213_set_piomode - Initialize host controller PATA PIO timings -* @ap: Port whose timings we are configuring -* @adev: Device whose timings we are configuring
drivers/ata/pata_it8213.c static int it8213_cable_detect(struct at · line 65
Quoted 10 lines
drivers/ata/pata_it8213.c +2
-8-* -* Set PIO mode for device, in host controller PCI config space. -* -* LOCKING: -* None (inherited from caller). -*/ - -static void it8213_set_piomode (struct ata_port *ap,struct ata_device *adev) +static void it8213_set_timings (struct ata_port *ap,struct ata_device *adev, +u8 pio,bool use_mwdma)
Perhaps 'set_mwdma' would be a better name...
Quoted 6 lines
drivers/ata/pata_it8213.c +0
-1{ -unsigned int pio = adev->pio_mode -XFER_PIO_0 ;struct pci_dev *dev =to_pci_dev (ap->host->dev);u8 master_port = ap->port_no ?0x42 :0x40 ;u16 master_data;
drivers/ata/pata_it8213.c static void it8213_set_piomode (struct a · line 86
Quoted 8 lines
drivers/ata/pata_it8213.c +2
-2@@ -92,13 +81,18 @@ static void it8213_set_piomode (struct a { 2, 1 }, { 2, 3 }, }; -if (pio >1 ) +if (pio >1 || use_mwdma) control |=1 ;/* TIME */ -if (ata_pio_need_iordy (adev))/* PIO 3/4 require IORDY */ +if (ata_pio_need_iordy (adev) || use_mwdma)
I believe this "IORDY for MWDMA" stupidity results from the table 35 in
ICH PRD which for some reason insists on setting IE bit with DMA, and I believe this is wrong -- IORDY shouldn't have anything to with DMA.
drivers/ata/pata_it8213.c static void it8213_set_piomode (struct a · line 93
Quoted 7 lines
drivers/ata/pata_it8213.c +3
-0control |=2 ;/* IE */ /* Bit 2 is set for ATAPI on the IT8213 - reverse of ICH/PIIX */ if (adev->class !=ATA_DEV_ATA ) control |=4 ;/* PPE */ +/* If the drive MWDMA is faster than it can do PIO then +we must force PIO into PIO0 */ +if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio))
Parens not needed...
drivers/ata/pata_it8213.c static void it8213_set_piomode (struct a · line 97
Quoted 4 lines
drivers/ata/pata_it8213.c +2
-0+/* Enable DMA timing only */ + control |=8 ;/* PIO cycles in PIO0 */ pci_read_config_word (dev, master_port, &master_data);
MBR, Sergei
PATCH 42/86 pata_it8213: fix it8213_pre_reset() documentation
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_it8213: fix it8213_pre_reset() documentation
--- drivers/ata/pata_it8213.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_it8213.c +1 -1
@@ -22,7 +22,7 @@#define DRV_VERSION "0.0.3"/** -* it8213_pre_reset - check for 40/80 pin +* it8213_pre_reset - probe begin * @link: link * @deadline: deadline jiffies for the operation *
PATCH 43/86 pata_it821x: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_it821x: add 32-bit PIO support
There shouldn't be any problems with it as IDE it821x host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_it821x.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/ata/pata_it821x.c +4 -4
@@ -738,7 +738,7 @@ static int it821x_port_start(struct ata_struct it821x_dev *itdev;u8 conf; -int ret =ata_sff_port_start (ap); +int ret =ata_sff_port_start32 (ap);if (ret <0 )return ret;
@@ -801,7 +801,7 @@ static struct scsi_host_template it821x_ };static struct ata_port_operations it821x_smart_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .check_atapi_dma= it821x_check_atapi_dma, .qc_issue = it821x_smart_qc_issue,
@@ -815,7 +815,7 @@ static struct ata_port_operations it821x };static struct ata_port_operations it821x_passthru_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .check_atapi_dma= it821x_check_atapi_dma, .sff_dev_select = it821x_passthru_dev_select,
@@ -831,7 +831,7 @@ static struct ata_port_operations it821x };static struct ata_port_operations it821x_rdc_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .check_atapi_dma= it821x_check_atapi_dma, .sff_dev_select = it821x_passthru_dev_select,
PATCH 44/86 pata_jmicron: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_jmicron: add 32-bit PIO support
There shouldn't be any problems with it as IDE jmicron host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_jmicron.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_jmicron.c +1 -1
@@ -112,7 +112,7 @@ static struct scsi_host_template jmicron };static struct ata_port_operations jmicron_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .prereset = jmicron_pre_reset, };
PATCH 45/86 pata_legacy: do not probe extra ports automatically if PCI is not present
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_legacy: do not probe extra ports automatically if PCI is not present
It can be problematic if there are other ISA/VLB devices using those ports.
This is a forward port of bugfix from IDE ide-generic host driver.
--- drivers/ata/pata_legacy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_legacy.c +1 -1
@@ -1241,7 +1241,7 @@ static __init int legacy_init(void)if (secondary ==0 || all)legacy_probe_add (0x170 ,15 ,UNKNOWN ,0 ); -if (probe_all || !pci_present) { +if (probe_all) {/* ISA/VLB extra ports */ legacy_probe_add (0x1E8 ,11 ,UNKNOWN ,0 );legacy_probe_add (0x168 ,10 ,UNKNOWN ,0 );
Re: [PATCH 45/86] pata_legacy: do not probe extra ports automatically if PCI is not present
Quoted 5 lines · On Wed, 25 Nov 2009 18:07:40 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_legacy: do not probe extra ports automatically if PCI is not presentIt can be problematic if there are other ISA/VLB devices using those ports.
NAK. You made a rather peculiar set of changes in the IDE layer but the PCI handling in pata_legacy includes knowledge of the various half-pci devices and on a non PCI system 0x1E8/0x168 are reserved for extra IDE.
We've had no complaints at all, ever about this.
Quoted 1 line
This is a forward port of bugfix from IDE ide-generic host driver.
Of a bug.
Alan
Re: [PATCH 45/86] pata_legacy: do not probe extra ports automatically if PCI is not present
Quoted 10 lines · Alan Cox
Quoted 5 lines · On Wed, 25 Nov 2009 18:07:40 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_legacy: do not probe extra ports automatically if PCI is not presentIt can be problematic if there are other ISA/VLB devices using those ports.
NAK. You made a rather peculiar set of changes in the IDE layer but the
Please give commit numbers and describe such 'peculiar set of changes in the IDE layer' in more details or skip such baseless, unjust and pointless comments from your mails.
Quoted 4 lines
PCI handling in
pata_legacyincludes knowledge of the various half-pci devices and on a non PCI system 0x1E8/0x168 are reserved for extra IDE.We've had no complaints at all, ever about this.
OTOH We had. :)
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 45/86] pata_legacy: do not probe extra ports automatically if PCI is not present
Quoted 4 lines
Quoted 1 line
NAK. You made a rather peculiar set of changes in the IDE layer but the
Please give commit numbers and describe such 'peculiar set of changes in the IDE layer' in more details or skip such baseless, unjust and pointless
Disabling what can be a safe probe
Quoted 1 line
comments from your mails.
The old IDE code didn't do the full PCI check that libata did at the time there were public complaints. Libata legacy also doesn't fall for the bug where legacy loads and blocks PCI adapters as it has a smart check in it, including for weirdness like the CS55x0 and the MPIIX.
So I'm firmly of the opinion that
- We should leave it as is
- If it causes a problem we should look at the exact case involved. Possibly it would need a CONFIG_X86 but thats sort of implied as embedded use pata_platform in preference.
The fact it just works by default is very very important.
Re: [PATCH 45/86] pata_legacy: do not probe extra ports automatically if PCI is not present
Quoted 6 lines · Alan Cox
Quoted 4 lines
Quoted 1 line
NAK. You made a rather peculiar set of changes in the IDE layer but the
Please give commit numbers and describe such 'peculiar set of changes in the IDE layer' in more details or skip such baseless, unjust and pointless
Disabling what can be a safe probe
In many of your comments recent you're referring to IDE state from five or more years ago.
Quoted 6 lines
Quoted 1 line
comments from your mails.
The old IDE code didn't do the full PCI check that libata did at the time there were public complaints. Libata legacy also doesn't fall for the bug where legacy loads and blocks PCI adapters as it has a smart check in it, including for weirdness like the CS55x0 and the MPIIX.
This was fixed long time ago and the needed checks were added (despite complete lack of code input from you).
Quoted 2 lines
So I'm firmly of the opinion that
- We should leave it as is
We may as well decide to do it before we have more data or more recent bug-report at hand. No big deal.
Quoted 1 line
- If it causes a problem we should look at the exact case involved.
While it was being fixed a year or two ago you were on cc: for original patch (+ asked whether the same should be needed for pata_legacy) and the bug-report from mikpe was on linux-ide ML.
IOW You were not interested into it the issue back when it was reported.
Quoted 4 lines
Possibly it would need a
CONFIG_X86but thats sort of implied as embedded usepata_platformin preference.The fact it just works by default is very very important.
Agreed on this one.
--
Bartlomiej Zolnierkiewicz
PATCH 46/86 pata_legacy: fix QDI6580DP support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_legacy: fix QDI6580DP support
Dual port QDI6580 has shared PIO timings for master/slave devices so it needs to use custom ->qc_issue method.
--- drivers/ata/pata_legacy.c | 1 + 1 file changed, 1 insertion(+)
drivers/ata/pata_legacy.c +1 -0
@@ -787,6 +787,7 @@ static struct ata_port_operations qdi658static struct ata_port_operations qdi6580dp_port_ops = { .inherits = &legacy_base_port_ops, .set_piomode = qdi6580dp_set_piomode, + .qc_issue = qdi_qc_issue, .sff_data_xfer = vlb32_data_xfer, };
PATCH 47/86 pata_legacy: fix access to control register for QDI6580
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_legacy: fix access to control register for QDI6580
We need to mask out the port offset from the port number cached in ld_qdi->timing.
--- drivers/ata/pata_legacy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ata/pata_legacy.c +2 -2
@@ -672,7 +672,7 @@ static void qdi6580dp_set_piomode(structoutb (timing, ld_qdi->timing +2 * ap->port_no);/* Clear the FIFO */ if (adev->class !=ATA_DEV_ATA ) -outb (0x5F , ld_qdi->timing +3 ); +outb (0x5F , (ld_qdi->timing &0xFFF0 ) +3 ); }/**
@@ -707,7 +707,7 @@ static void qdi6580_set_piomode(struct aoutb (timing, ld_qdi->timing +2 * adev->devno);/* Clear the FIFO */ if (adev->class !=ATA_DEV_ATA ) -outb (0x5F , ld_qdi->timing +3 ); +outb (0x5F , (ld_qdi->timing &0xFFF0 ) +3 ); }/**
PATCH 48/86 pata_legacy: add pointers to QDI65x0 documentation
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_legacy: add pointers to QDI65x0 documentation
--- drivers/ata/pata_legacy.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/ata/pata_legacy.c +8 -1
@@ -25,6 +25,13 @@* http://www.ryston.cz/petr/vlb/pdc20230b.html * http://www.ryston.cz/petr/vlb/pdc20230c.html * http://www.ryston.cz/petr/vlb/pdc20630.html +* QDI65x0: +* http://www.ryston.cz/petr/vlb/qd6500.html +* http://www.ryston.cz/petr/vlb/qd6580.html +* +* QDI65x0 probe code based on drivers/ide/legacy/qd65xx.c +* Rewritten from the work of Colten Edwards <[email protected]> by +* Samuel Thibault <[email protected]> * * Unsupported but docs exist: * Appian/Adaptec AIC25VL01/Cirrus Logic PD7220
@@ -35,7 +42,7 @@* the MPIIX where the tuning is PCI side but the IDE is "ISA side". * * Specific support is included for the ht6560a/ht6560b/opti82c611a/ -* opti82c465mv/promise 20230c/20630/winbond83759A +* opti82c465mv/promise 20230c/20630/qdi65x0/winbond83759A * * Use the autospeed and pio_mask options with: * Appian ADI/2 aka CLPD7220 or AIC25VL01.
Re: [PATCH 48/86] pata_legacy: add pointers to QDI65x0 documentation
Quoted 3 lines
+ * QDI65x0 probe code based on
drivers/ide/legacy/qd65xx.c
+ * Rewritten from the work of Colten Edwards <[email protected]> by
+ * Samuel Thibault <[email protected]>
It's not drivers/ide/legacy/qd65xx.c - because you moved it back in the old IDE code.
Re: [PATCH 48/86] pata_legacy: add pointers to QDI65x0 documentation
Quoted 6 lines · Alan Cox
Quoted 3 lines
+ * QDI65x0 probe code based on
drivers/ide/legacy/qd65xx.c
+ * Rewritten from the work of Colten Edwards <[email protected]> by
+ * Samuel Thibault <[email protected]>It's not
drivers/ide/legacy/qd65xx.c- because you moved it back in the old IDE code.
It was the correct path/driver when the aforementioned code was added.
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 48/86] pata_legacy: add pointers to QDI65x0 documentation
Quoted 9 lines · On Wed, 25 Nov 2009 18:44:59 +0100 Bartlomiej Zolnierkiewicz…
Quoted 6 lines · Alan Cox
Quoted 3 lines
+ * QDI65x0 probe code based on
drivers/ide/legacy/qd65xx.c
+ * Rewritten from the work of Colten Edwards <[email protected]> by
+ * Samuel Thibault <[email protected]>It's not
drivers/ide/legacy/qd65xx.c- because you moved it back in the old IDE code.It was the correct path/driver when the aforementioned code was added.
Sure but the path has changed so its more helpful for anyone looking back to have the right path.
Re: [PATCH 48/86] pata_legacy: add pointers to QDI65x0 documentation
Quoted 8 lines · Alan Cox
Quoted 5 lines · On Wed, 25 Nov 2009 18:44:59 +0100 Bartlomiej Zolnierkiewicz…
Quoted 4 lines · Alan Cox
Quoted 3 lines
+ * QDI65x0 probe code based on
drivers/ide/legacy/qd65xx.c
+ * Rewritten from the work of Colten Edwards <[email protected]> by
+ * Samuel Thibault <[email protected]>
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
It's not
drivers/ide/legacy/qd65xx.c- because you moved it back in the old IDE code.It was the correct path/driver when the aforementioned code was added.
Sure but the path has changed so its more helpful for anyone looking back to have the right path.
I disagree. The code from back then is not the same code as today and we have git log --follow for this.
--
Bartlomiej Zolnierkiewicz
PATCH 49/86 pata_legacy: unify QDI ->set_piomode methods
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_legacy: unify QDI ->set_piomode methods
Add controller type field to struct legacy_data and then use it to merge together all ->set_piomode methods for QDI controllers.
--- drivers/ata/pata_legacy.c | 98 ++++++++++------------------------------------ 1 file changed, 23 insertions(+), 75 deletions(-)
drivers/ata/pata_legacy.c +23 -75
@@ -76,15 +76,6 @@ static int all;module_param (all, int,0444 );MODULE_PARM_DESC (all,"Grab all legacy port devices, even if PCI(0=off, 1=on)" ); -struct legacy_data { -unsigned long timing; -u8 clock[2 ]; -u8 last; -int fast; -struct platform_device *platform_dev; - -}; -enum controller {BIOS =0 ,SNOOP =1 ,
@@ -101,6 +92,14 @@ enum controller {UNKNOWN =-1 }; +struct legacy_data { +unsigned long timing; +u8 clock[2 ]; +u8 last; +int fast; +enum controller type; +struct platform_device *platform_dev; +};struct legacy_probe {unsigned char *name;
@@ -622,40 +621,20 @@ static struct ata_port_operations opti82 .qc_issue = opti82c46x_qc_issue, }; -static void qdi6500_set_piomode (struct ata_port *ap,struct ata_device *adev) -{ -struct ata_timing t; -struct legacy_data *ld_qdi = ap->host->private_data; -int active, recovery; -u8 timing; - -/* Get the timing data in cycles */ -ata_timing_compute (adev, adev->pio_mode, &t,30303 ,1000 ); - -if (ld_qdi->fast) { - active =8 -clamp_val (t.active,1 ,8 ); - recovery =18 -clamp_val (t.recover,3 ,18 ); - }else { - active =9 -clamp_val (t.active,2 ,9 ); - recovery =15 -clamp_val (t.recover,0 ,15 ); - } - timing = (recovery <<4 ) | active |0x08 ; - - ld_qdi->clock[adev->devno] = timing; - -outb (timing, ld_qdi->timing); -} -/** -* qdi6580dp_set_piomode - PIO setup for dual channel +* qdi65x0_set_piomode - PIO setup for QDI65x0 * @ap: Port * @adev: Device * +* In single channel mode the 6580 has one clock per device and we can +* avoid the requirement to clock switch. We also have to load the timing +* into the right clock according to whether we are master or slave. +* * In dual channel mode the 6580 has one clock per channel and we have * to software clockswitch in qc_issue. */ -static void qdi6580dp_set_piomode (struct ata_port *ap,struct ata_device *adev) +static void qdi65x0_set_piomode (struct ata_port *ap,struct ata_device *adev) {struct ata_timing t;struct legacy_data *ld_qdi = ap->host->private_data;
@@ -673,47 +652,15 @@ static void qdi6580dp_set_piomode(struct recovery =15 -clamp_val (t.recover,0 ,15 ); } timing = (recovery <<4 ) | active |0x08 ; - ld_qdi->clock[adev->devno] = timing; -outb (timing, ld_qdi->timing +2 * ap->port_no); -/* Clear the FIFO */ -if (adev->class !=ATA_DEV_ATA ) -outb (0x5F , (ld_qdi->timing &0xFFF0 ) +3 ); -} - -/** -* qdi6580_set_piomode - PIO setup for single channel -* @ap: Port -* @adev: Device -* -* In single channel mode the 6580 has one clock per device and we can -* avoid the requirement to clock switch. We also have to load the timing -* into the right clock according to whether we are master or slave. -*/ - -static void qdi6580_set_piomode (struct ata_port *ap,struct ata_device *adev) -{ -struct ata_timing t; -struct legacy_data *ld_qdi = ap->host->private_data; -int active, recovery; -u8 timing; - -/* Get the timing data in cycles */ -ata_timing_compute (adev, adev->pio_mode, &t,30303 ,1000 ); +if (ld_qdi->type ==QDI6580 ) +outb (timing, ld_qdi->timing +2 * adev->devno); +else +outb (timing, ld_qdi->timing +2 * ap->port_no); -if (ld_qdi->fast) { - active =8 -clamp_val (t.active,1 ,8 ); - recovery =18 -clamp_val (t.recover,3 ,18 ); - }else { - active =9 -clamp_val (t.active,2 ,9 ); - recovery =15 -clamp_val (t.recover,0 ,15 ); - } - timing = (recovery <<4 ) | active |0x08 ; - ld_qdi->clock[adev->devno] = timing; -outb (timing, ld_qdi->timing +2 * adev->devno);/* Clear the FIFO */ -if (adev->class !=ATA_DEV_ATA ) +if (ld_qdi->type !=QDI6500 && adev->class !=ATA_DEV_ATA )outb (0x5F , (ld_qdi->timing &0xFFF0 ) +3 ); }
@@ -780,20 +727,20 @@ static int qdi_port(struct platform_devistatic struct ata_port_operations qdi6500_port_ops = { .inherits = &legacy_base_port_ops, - .set_piomode = qdi6500_set_piomode, + .set_piomode = qdi65x0_set_piomode, .qc_issue = qdi_qc_issue, .sff_data_xfer = vlb32_data_xfer, };static struct ata_port_operations qdi6580_port_ops = { .inherits = &legacy_base_port_ops, - .set_piomode = qdi6580_set_piomode, + .set_piomode = qdi65x0_set_piomode, .sff_data_xfer = vlb32_data_xfer, };static struct ata_port_operations qdi6580dp_port_ops = { .inherits = &legacy_base_port_ops, - .set_piomode = qdi6580dp_set_piomode, + .set_piomode = qdi65x0_set_piomode, .qc_issue = qdi_qc_issue, .sff_data_xfer = vlb32_data_xfer, };
@@ -1013,6 +960,7 @@ static __init int legacy_init_one(struct ctrl_addr =devm_ioport_map (&pdev->dev, io +0x0206 ,1 );if (!io_addr || !ctrl_addr) goto fail; + ld->type = probe->type;if (controller->setup)if (controller->setup (pdev, probe, ld) <0 ) goto fail;
PATCH 50/86 pata_legacy: use PIO mask defines
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_legacy: use PIO mask defines
--- drivers/ata/pata_legacy.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
drivers/ata/pata_legacy.c +11 -11
@@ -817,29 +817,29 @@ static struct ata_port_operations winbon };static struct legacy_controller controllers[] = { - {"BIOS" , &legacy_port_ops,0x1F , + {"BIOS" , &legacy_port_ops,ATA_PIO4 ,ATA_FLAG_NO_IORDY ,0 ,NULL }, - {"Snooping" , &simple_port_ops,0x1F , + {"Snooping" , &simple_port_ops,ATA_PIO4 ,0 ,0 ,NULL }, - {"PDC20230" , &pdc20230_port_ops,0x7 , + {"PDC20230" , &pdc20230_port_ops,ATA_PIO2 ,ATA_FLAG_NO_IORDY ,ATA_PFLAG_PIO32 |ATA_PFLAG_PIO32CHANGE ,NULL }, - {"HT6560A" , &ht6560a_port_ops,0x07 , + {"HT6560A" , &ht6560a_port_ops,ATA_PIO2 ,ATA_FLAG_NO_IORDY ,0 ,NULL }, - {"HT6560B" , &ht6560b_port_ops,0x1F , + {"HT6560B" , &ht6560b_port_ops,ATA_PIO4 ,ATA_FLAG_NO_IORDY ,0 ,NULL }, - {"OPTI82C611A" , &opti82c611a_port_ops,0x0F , + {"OPTI82C611A" , &opti82c611a_port_ops,ATA_PIO3 ,0 ,0 ,NULL }, - {"OPTI82C46X" , &opti82c46x_port_ops,0x0F , + {"OPTI82C46X" , &opti82c46x_port_ops,ATA_PIO3 ,0 ,0 ,NULL }, - {"QDI6500" , &qdi6500_port_ops,0x07 , + {"QDI6500" , &qdi6500_port_ops,ATA_PIO2 ,ATA_FLAG_NO_IORDY ,ATA_PFLAG_PIO32 |ATA_PFLAG_PIO32CHANGE , qdi_port }, - {"QDI6580" , &qdi6580_port_ops,0x1F , + {"QDI6580" , &qdi6580_port_ops,ATA_PIO4 ,0 ,ATA_PFLAG_PIO32 |ATA_PFLAG_PIO32CHANGE , qdi_port }, - {"QDI6580DP" , &qdi6580dp_port_ops,0x1F , + {"QDI6580DP" , &qdi6580dp_port_ops,ATA_PIO4 ,0 ,ATA_PFLAG_PIO32 |ATA_PFLAG_PIO32CHANGE , qdi_port }, - {"W83759A" , &winbond_port_ops,0x1F , + {"W83759A" , &winbond_port_ops,ATA_PIO4 ,0 ,ATA_PFLAG_PIO32 |ATA_PFLAG_PIO32CHANGE , winbond_port } };
PATCH 51/86 libata: remove no longer needed pata_qdi driver
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: remove no longer needed pata_qdi driver
QDI65x0 controllers are fully supported by pata_legacy driver so remove no longer needed pata_qdi driver.
Leave PATA_QDI config option for compatibility reasons and teach pata_legacy to preserve the old behavior of pata_qdi driver.
--- drivers/ata/Kconfig | 1 drivers/ata/Makefile | 1 drivers/ata/pata_legacy.c | 9 + drivers/ata/pata_qdi.c | 366 ---------------------------------------------- 4 files changed, 9 insertions(+), 368 deletions(-)
drivers/ata/Kconfig +1 -0
@@ -591,6 +591,7 @@ config PATA_PDC_OLD config PATA_QDI tristate "QDI VLB PATA support" depends on ISA + select PATA_LEGACY help Support for QDI 6500 and 6580 PATA controllers on VESA local bus.
drivers/ata/Makefile +0 -1
@@ -55,7 +55,6 @@ obj-$(CONFIG_PATA_PALMLD) += pata_palmld obj-$(CONFIG_PATA_PCMCIA) += pata_pcmcia.o obj-$(CONFIG_PATA_PDC2027X) += pata_pdc2027x.o obj-$(CONFIG_PATA_PDC_OLD) += pata_pdc202xx_old.o -obj-$(CONFIG_PATA_QDI) += pata_qdi.o obj-$(CONFIG_PATA_RADISYS) += pata_radisys.o obj-$(CONFIG_PATA_RB532) += pata_rb532_cf.o obj-$(CONFIG_PATA_RDC) += pata_rdc.o
drivers/ata/pata_legacy.c +8 -1
@@ -133,7 +133,12 @@ static int ht6560a; /* HT 6560A on primstatic int ht6560b;/* HT 6560A on primary 1, second 2, both 3 */ static int opti82c611a;/* Opti82c611A on primary 1, sec 2, both 3 */ static int opti82c46x;/* Opti 82c465MV present(pri/sec autodetect) */ -static int qdi;/* Set to probe QDI controllers */ +/* Set to probe QDI controllers */ +#ifdef PATA_QDI_MODULE +static int qdi =1 ; +#else +static int qdi; +#endif static int winbond;/* Set to probe Winbond controllers, give I/O port if non standard */ static int autospeed;/* Chip present which snoops speed changes */
@@ -1245,6 +1250,7 @@ MODULE_AUTHOR("Alan Cox");MODULE_DESCRIPTION ("low-level driver for legacy ATA" );MODULE_LICENSE ("GPL" );MODULE_VERSION (DRV_VERSION ); +MODULE_ALIAS ("pata_qdi" );module_param (probe_all, int,0 );module_param (autospeed, int,0 );
@@ -1253,6 +1259,7 @@ module_param(ht6560b, int, 0);module_param (opti82c611a, int,0 );module_param (opti82c46x, int,0 );module_param (qdi, int,0 ); +module_param_named (probe_qdi, qdi, int,0 );module_param (pio_mask, int,0 );module_param (iordy_mask, int,0 );
drivers/ata/pata_qdi.c deleted +0 -366
366 lines not on this page · raw message
Re: [PATCH 51/86] libata: remove no longer needed pata_qdi driver
Quoted 8 lines · On Wed, 25 Nov 2009 18:08:23 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: remove no longer neededpata_qdidriverQDI65x0 controllers are fully supported by
pata_legacydriver so remove no longer neededpata_qdidriver.Leave
PATA_QDIconfig option for compatibility reasons and teachpata_legacyto preserve the old behavior ofpata_qdidriver.
Just delete it nobody will care. I sent Jeff patches to delete it a couple of times before but they got dropped
PATCH 52/86 libata: remove no longer needed pata_winbond driver
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: remove no longer needed pata_winbond driver
Winbond W83759A controller is fully supported by pata_legacy driver so remove no longer needed pata_winbond driver.
Leave PATA_WINBOND_VLB config option for compatibility reasons and teach pata_legacy to preserve the old behavior of pata_winbond driver.
--- drivers/ata/Kconfig | 1 drivers/ata/Makefile | 1 drivers/ata/pata_legacy.c | 13 +- drivers/ata/pata_winbond.c | 282 --------------------------------------------- 4 files changed, 12 insertions(+), 285 deletions(-)
drivers/ata/Kconfig +1 -0
@@ -695,6 +695,7 @@ config PATA_WINBOND config PATA_WINBOND_VLB tristate "Winbond W83759A VLB PATA support (Experimental)" depends on ISA && EXPERIMENTAL + select PATA_LEGACY help Support for the Winbond W83759A controller on Vesa Local Bus systems.
drivers/ata/Makefile +0 -1
@@ -64,7 +64,6 @@ obj-$(CONFIG_PATA_SERVERWORKS) += pata_s obj-$(CONFIG_PATA_SIL680) += pata_sil680.o obj-$(CONFIG_PATA_VIA) += pata_via.o obj-$(CONFIG_PATA_WINBOND) += pata_sl82c105.o -obj-$(CONFIG_PATA_WINBOND_VLB) += pata_winbond.o obj-$(CONFIG_PATA_SIS) += pata_sis.o obj-$(CONFIG_PATA_TRIFLEX) += pata_triflex.o obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o
drivers/ata/pata_legacy.c +11 -2
@@ -44,6 +44,9 @@* Specific support is included for the ht6560a/ht6560b/opti82c611a/ * opti82c465mv/promise 20230c/20630/qdi65x0/winbond83759A * +* Support for the Winbond 83759A when operating in advanced mode. +* Multichip mode is not currently supported. +* * Use the autospeed and pio_mask options with: * Appian ADI/2 aka CLPD7220 or AIC25VL01. * Use the jumpers, autospeed and set pio_mask to the mode on the jumpers with
@@ -139,8 +142,12 @@ static int qdi = 1;#else static int qdi;#endif -static int winbond;/* Set to probe Winbond controllers, -give I/O port if non standard */ +/* Set to probe Winbond controllers, give I/O port if non standard */ +#ifdef PATA_WINBOND_VLB_MODULE +static int winbond =1 ; +#else +static int winbond; +#endif static int autospeed;/* Chip present which snoops speed changes */ static int pio_mask =ATA_PIO4 ;/* PIO range for autospeed devices */ static int iordy_mask =0xFFFFFFFF ;/* Use iordy if available */
@@ -1251,6 +1258,7 @@ MODULE_DESCRIPTION("low-level driver forMODULE_LICENSE ("GPL" );MODULE_VERSION (DRV_VERSION );MODULE_ALIAS ("pata_qdi" ); +MODULE_ALIAS ("pata_winbond" );module_param (probe_all, int,0 );module_param (autospeed, int,0 );
@@ -1260,6 +1268,7 @@ module_param(opti82c611a, int, 0);module_param (opti82c46x, int,0 );module_param (qdi, int,0 );module_param_named (probe_qdi, qdi, int,0 ); +module_param_named (probe_winbond, winbond, int,0 );module_param (pio_mask, int,0 );module_param (iordy_mask, int,0 );
drivers/ata/pata_winbond.c deleted +0 -282
282 lines not on this page · raw message
PATCH 53/86 pata_marvell: fix marvell_pre_reset() documentation
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_marvell: fix marvell_pre_reset() documentation
--- drivers/ata/pata_marvell.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_marvell.c +1 -1
@@ -58,7 +58,7 @@ static int marvell_pata_active(struct pc }/** -* marvell_pre_reset - check for 40/80 pin +* marvell_pre_reset - probe begin * @link: link * @deadline: deadline jiffies for the operation *
PATCH 54/86 pata_ns87415: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_ns87415: add 32-bit PIO support
There shouldn't be any problems with it as IDE ns87415 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_ns87415.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_ns87415.c +1 -1
@@ -300,7 +300,7 @@ static u8 ns87560_bmdma_status(struct at#endif /* 87560 SuperIO Support */ static struct ata_port_operations ns87415_pata_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .check_atapi_dma = ns87415_check_atapi_dma, .bmdma_setup = ns87415_bmdma_setup,
PATCH 55/86 pata_ns87415: Power Management fix
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_ns87415: Power Management fix
Fix ->resume method to do chipset specific setup.
--- drivers/ata/pata_ns87415.c | 32 +++++++++++++++++++++++++++----- 1 file changed, 27 insertions(+), 5 deletions(-)
drivers/ata/pata_ns87415.c +27 -5
@@ -325,6 +325,13 @@ static struct scsi_host_template ns87415 ATA_BMDMA_SHT(DRV_NAME), }; +static void ns87415_fixup (struct pci_dev *pdev) +{ +/* Select 512 byte sectors */ +pci_write_config_byte (pdev,0x55 ,0xEE ); +/* Select PIO0 8bit clocking */ +pci_write_config_byte (pdev,0x54 ,0xB7 ); +}/** * ns87415_init_one - Register 87415 ATA PCI device with kernel services
@@ -371,10 +378,8 @@ static int ns87415_init_one (struct pci_if (rc)return rc; -/* Select 512 byte sectors */ -pci_write_config_byte (pdev,0x55 ,0xEE ); -/* Select PIO0 8bit clocking */ -pci_write_config_byte (pdev,0x54 ,0xB7 ); +ns87415_fixup (pdev); +return ata_pci_sff_init_one (pdev, ppi, &ns87415_sht,NULL ); }
@@ -384,6 +389,23 @@ static const struct pci_device_id ns8741 { }/* terminate list */ }; +#ifdef CONFIG_PM +static int ns87415_reinit_one (struct pci_dev *pdev) +{ +struct ata_host *host =dev_get_drvdata (&pdev->dev); +int rc; + + rc =ata_pci_device_do_resume (pdev); +if (rc) +return rc; + +ns87415_fixup (pdev); + +ata_host_resume (host); +return 0 ; +} +#endif +static struct pci_driver ns87415_pci_driver = { .name =DRV_NAME , .id_table = ns87415_pci_tbl,
@@ -391,7 +413,7 @@ static struct pci_driver ns87415_pci_dri .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = ata_pci_device_resume, + .resume = ns87415_reinit_one,#endif };
PATCH 56/86 pata_oldpiix: unify code for programming PIO and MWDMA timings
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_oldpiix: unify code for programming PIO and MWDMA timings
It results in ~12% decrease in the driver LOC count and also ~5% decrease in the driver binary size (as measured on x86-32).
--- drivers/ata/pata_oldpiix.c | 88 +++++++++++++-------------------------------- 1 file changed, 27 insertions(+), 61 deletions(-)
drivers/ata/pata_oldpiix.c +27 -61
@@ -50,20 +50,9 @@ static int oldpiix_pre_reset(struct ata_return ata_sff_prereset (link, deadline); } -/** -* oldpiix_set_piomode - Initialize host controller PATA PIO timings -* @ap: Port whose timings we are configuring -* @adev: Device whose timings we are configuring -* -* Set PIO mode for device, in host controller PCI config space. -* -* LOCKING: -* None (inherited from caller). -*/ - -static void oldpiix_set_piomode (struct ata_port *ap,struct ata_device *adev) +static void oldpiix_set_timings (struct ata_port *ap,struct ata_device *adev, +u8 pio,bool use_mwdma) { -unsigned int pio = adev->pio_mode -XFER_PIO_0 ;struct pci_dev *dev =to_pci_dev (ap->host->dev);unsigned int idetm_port= ap->port_no ?0x42 :0x40 ;u16 idetm_data;
@@ -82,14 +71,18 @@ static void oldpiix_set_piomode (struct { 2, 1 }, { 2, 3 }, }; -if (pio >1 ) +if (pio >1 || use_mwdma) control |=1 ;/* TIME */ -if (ata_pio_need_iordy (adev)) +if (ata_pio_need_iordy (adev) || use_mwdma) control |=2 ;/* IE */ -/* Intel specifies that the prefetch/posting is for disk only */ if (adev->class ==ATA_DEV_ATA ) control |=4 ;/* PPE */ +/* If the drive MWDMA is faster than it can do PIO then +we must force PIO into PIO0 */ +if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio)) +/* Enable DMA timing only */ + control |=8 ;/* PIO cycles in PIO0 */ pci_read_config_word (dev, idetm_port, &idetm_data);
@@ -113,6 +106,22 @@ static void oldpiix_set_piomode (struct }/** +* oldpiix_set_piomode - Initialize host controller PATA PIO timings +* @ap: Port whose timings we are configuring +* @adev: Device whose timings we are configuring +* +* Set PIO mode for device, in host controller PCI config space. +* +* LOCKING: +* None (inherited from caller). +*/ + +static void oldpiix_set_piomode (struct ata_port *ap,struct ata_device *adev) +{ +oldpiix_set_timings (ap, adev, adev->pio_mode -XFER_PIO_0 ,0 ); +} + +/** * oldpiix_set_dmamode - Initialize host controller PATA DMA timings * @ap: Port whose timings we are configuring * @adev: Device to program
@@ -125,58 +134,15 @@ static void oldpiix_set_piomode (structstatic void oldpiix_set_dmamode (struct ata_port *ap,struct ata_device *adev) { -struct pci_dev *dev =to_pci_dev (ap->host->dev); -u8 idetm_port = ap->port_no ?0x42 :0x40 ; -u16 idetm_data; - -static const /* ISP RTC */ -u8 timings[][2 ] = { {0 ,0 }, - {0 ,0 }, - {1 ,0 }, - {2 ,1 }, - {2 ,3 }, }; - -/* -* MWDMA is driven by the PIO timings. We must also enable -* IORDY unconditionally along with TIME1. PPE has already -* been set when the PIO timing was set. -*/ +/* MWDMA is driven by the PIO timings. */ unsigned int mwdma = adev->dma_mode -XFER_MW_DMA_0 ; -unsigned int control;const unsigned int needed_pio[3 ] = {XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 };int pio = needed_pio[mwdma] -XFER_PIO_0 ; -pci_read_config_word (dev, idetm_port, &idetm_data); - - control =3 ;/* IORDY|TIME0 */ -/* Intel specifies that the PPE functionality is for disk only */ -if (adev->class ==ATA_DEV_ATA ) - control |=4 ;/* PPE enable */ - -/* If the drive MWDMA is faster than it can do PIO then -we must force PIO into PIO0 */ - -if (adev->pio_mode < needed_pio[mwdma]) -/* Enable DMA timing only */ - control |=8 ;/* PIO cycles in PIO0 */ - -/* Mask out the relevant control and timing bits we will load. Also -clear the other drive TIME register as a precaution */ -if (adev->devno ==0 ) { - idetm_data &=0xCCE0 ; - idetm_data |= control; - }else { - idetm_data &=0xCC0E ; - idetm_data |= (control <<4 ); - } - idetm_data |= (timings[pio][0 ] <<12 ) | (timings[pio][1 ] <<8 ); -pci_write_config_word (dev, idetm_port, idetm_data); - -/* Track which port is configured */ - ap->private_data = adev; +oldpiix_set_timings (ap, adev, pio,1 ); }/**
PATCH 57/86 pata_opti: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_opti: add 32-bit PIO support
There shouldn't be any problems with it as IDE opti621 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_opti.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/ata/pata_opti.c +2 -0
@@ -157,6 +157,8 @@ static struct ata_port_operations opti_p .cable_detect = ata_cable_40wire, .set_piomode = opti_set_piomode, .prereset = opti_pre_reset, + .sff_data_xfer = ata_sff_data_xfer32, + .port_start = ata_sff_port_start32, };static int opti_init_one (struct pci_dev *dev,const struct pci_device_id *id)
PATCH 58/86 pata_pdc2027x: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_pdc2027x: add 32-bit PIO support
There shouldn't be any problems with it as IDE pdc202xx_new host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_pdc2027x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_pdc2027x.c +1 -1
@@ -133,7 +133,7 @@ static struct scsi_host_template pdc2027 };static struct ata_port_operations pdc2027x_pata100_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .check_atapi_dma = pdc2027x_check_atapi_dma, .cable_detect = pdc2027x_cable_detect, .prereset = pdc2027x_prereset,
PATCH 59/86 pata_pdc2027x: add Power Management support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_pdc2027x: add Power Management support
There shouldn't be any problems with it as IDE pdc202xx_new host driver has been supporting Power Management for over year now.
--- drivers/ata/pata_pdc2027x.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
drivers/ata/pata_pdc2027x.c +30 -0
@@ -63,6 +63,7 @@ enum { };static int pdc2027x_init_one (struct pci_dev *pdev,const struct pci_device_id *ent); +static int pdc2027x_reinit_one (struct pci_dev *pdev);static int pdc2027x_prereset (struct ata_link *link,unsigned long deadline);static void pdc2027x_set_piomode (struct ata_port *ap,struct ata_device *adev);static void pdc2027x_set_dmamode (struct ata_port *ap,struct ata_device *adev);
@@ -126,6 +127,10 @@ static struct pci_driver pdc2027x_pci_dr .id_table = pdc2027x_pci_tbl, .probe = pdc2027x_init_one, .remove = ata_pci_remove_one, +#ifdef CONFIG_PM + .suspend = ata_pci_device_suspend, + .resume = pdc2027x_reinit_one, +#endif }; static struct scsi_host_template pdc2027x_sht = {
@@ -758,6 +763,31 @@ static int __devinit pdc2027x_init_one(s IRQF_SHARED, &pdc2027x_sht); } +#ifdef CONFIG_PM +static int pdc2027x_reinit_one (struct pci_dev *pdev) +{ +struct ata_host *host =dev_get_drvdata (&pdev->dev); +unsigned int board_idx; +int rc; + + rc =ata_pci_device_do_resume (pdev); +if (rc) +return rc; + +if (pdev->device ==PCI_DEVICE_ID_PROMISE_20268 || + pdev->device ==PCI_DEVICE_ID_PROMISE_20270 ) + board_idx =PDC_UDMA_100 ; +else + board_idx =PDC_UDMA_133 ; + +if (pdc_hardware_init (host, board_idx)) +return -EIO ; + +ata_host_resume (host); +return 0 ; +} +#endif +/** * pdc2027x_init - Called after this module is loaded into the kernel. */
PATCH 60/86 pata_pdc202xx_old: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_pdc202xx_old: add 32-bit PIO support
There shouldn't be any problems with it as IDE pdc202xx_old host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_pdc202xx_old.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ata/pata_pdc202xx_old.c +2 -2
@@ -240,7 +240,7 @@ static int pdc2026x_port_start(struct atu8 burst =ioread8 (bmdma +0x1f );iowrite8 (burst |0x01 , bmdma +0x1f ); } -return ata_sff_port_start (ap); +return ata_sff_port_start32 (ap); }/**
@@ -266,7 +266,7 @@ static struct scsi_host_template pdc202x };static struct ata_port_operations pdc2024x_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .cable_detect = ata_cable_40wire, .set_piomode = pdc202xx_set_piomode,
PATCH 61/86 pata_sis: Power Management fix
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_pdc202xx_old: Power Management fix
Enable burst mode on resume for PDC2026x controllers.
--- drivers/ata/pata_pdc202xx_old.c | 33 +++++++++++++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-)
drivers/ata/pata_pdc202xx_old.c +31 -2
@@ -232,14 +232,21 @@ static void pdc2026x_dev_config(struct a adev->max_sectors =256 ; } -static int pdc2026x_port_start (struct ata_port *ap) +static void pdc2026x_bmdma_enable_burst (struct ata_port *ap) {void __iomem *bmdma = ap->ioaddr.bmdma_addr; +if (bmdma) {/* Enable burst mode */ u8 burst =ioread8 (bmdma +0x1f );iowrite8 (burst |0x01 , bmdma +0x1f ); } +} + +static int pdc2026x_port_start (struct ata_port *ap) +{ +pdc2026x_bmdma_enable_burst (ap); +return ata_sff_port_start32 (ap); }
@@ -327,6 +334,28 @@ static int pdc202xx_init_one(struct pci_return ata_pci_sff_init_one (dev, ppi, &pdc202xx_sht,NULL ); } +#ifdef CONFIG_PM +static int pdc202xx_reinit_one (struct pci_dev *pdev) +{ +struct ata_host *host =dev_get_drvdata (&pdev->dev); +int rc, i; + + rc =ata_pci_device_do_resume (pdev); +if (rc) +return rc; + +for (i =0 ; i < host->n_ports; i++) { +struct ata_port *ap = host->ports[i]; + +if (ap->udma_mask >ATA_UDMA2 ) +pdc2026x_bmdma_enable_burst (ap); + } + +ata_host_resume (host); +return 0 ; +} +#endif +static const struct pci_device_id pdc202xx[] = { {PCI_VDEVICE (PROMISE ,PCI_DEVICE_ID_PROMISE_20246 ),0 }, {PCI_VDEVICE (PROMISE ,PCI_DEVICE_ID_PROMISE_20262 ),1 },
@@ -344,7 +373,7 @@ static struct pci_driver pdc202xx_pci_dr .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = ata_pci_device_resume, + .resume = pdc202xx_reinit_one,#endif };
PATCH 62/86 pata_pdc202xx_old: document known issues
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_pdc202xx_old: document known issues
Document known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
--- drivers/ata/Kconfig | 4 ++++ 1 file changed, 4 insertions(+)
drivers/ata/Kconfig +4 -0
@@ -583,6 +583,10 @@ config PATA_PDC_OLD This option enables support for the Promise 20246, 20262, 20263, 20265 and 20267 adapters. + Known issues: + - UDMA transfers fail mysteriously on some chipsets + - ATAPI DMA is unsupported currently + If unsure, say N. config PATA_QDI
Re: [PATCH 62/86] pata_pdc202xx_old: document known issues
Quoted 17 lines · On Wed, 25 Nov 2009 18:09:48 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_pdc202xx_old: document known issuesDocument known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/ata/Kconfig | 4 ++++ 1 file changed, 4 insertions(+)Index: b/drivers/ata/Kconfig
===================================================================
drivers/ata/Kconfig config PATA_PDC_OLD · line 588
Quoted 6 lines
drivers/ata/Kconfig +3
-0@@ -583,6 +583,10 @@ config PATA_PDC_OLD This option enables support for the Promise 20246, 20262, 20263, 20265 and 20267 adapters. + Known issues: + - UDMA transfers fail mysteriously on some chipsets + - ATAPI DMA is unsupported currently
Not sure this is useful, because the reports of UDMA failures are lower than most other reports. Should IPV6 have "known issues, mysterious timer list corruption" for example which occurs far more. Not do we list 'no atapi dma' in the help for the IDE SII driver ?
Would be useful to fix (may actually just work now) but comments belong in the driver code.
Re: [PATCH 62/86] pata_pdc202xx_old: document known issues
Quoted 23 lines · Alan Cox
Quoted 20 lines · On Wed, 25 Nov 2009 18:09:48 +0100 Bartlomiej…
From: Bartlomiej Zolnierkiewicz<[email protected]>
Subject: [PATCH]pata_pdc202xx_old: document known issuesDocument known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
Signed-off-by Bartlomiej Zolnierkiewicz<[email protected]>--- drivers/ata/Kconfig | 4 ++++ 1 file changed, 4 insertions(+)Index: b/drivers/ata/Kconfig
===================================================================drivers/ata/Kconfig +0
-0@@ -583,6 +583,10 @@ config PATA_PDC_OLD This option enables support for the Promise 20246, 20262, 20263, 20265 and 20267 adapters.
Quoted 8 lines
drivers/ata/Kconfig config PATA_PDC_OLD · line 588
Quoted 3 lines
drivers/ata/Kconfig +3
-0+ Known issues: + - UDMA transfers fail mysteriously on some chipsets + - ATAPI DMA is unsupported currentlyNot sure this is useful, because the reports of UDMA failures are lower than most other reports. Should IPV6 have "known issues, mysterious timer list corruption" for example which occurs far more. Not do we list 'no atapi dma' in the help for the IDE SII driver ?
If the chip can support ATAPI DMI, but the driver does not, that deserves a comment, even if it's "hardware bugs prevent ATAPI DMA" or "ATAPI DMA would require much more code to support, so we did not bother for now"
Ditto for things like useful ideas ("consider PIO-over-DMA in SiI 311x") and other would-be-nice-to-have ideas. These can serve as projects for newbies, or reminders for old-timers.
Space in the driver source code comment header is cheap. Use liberally :) Write a Shakespearean soliloquy on a chip's hardware bugs, if you'd like.
Jeff
Re: [PATCH 62/86] pata_pdc202xx_old: document known issues
Quoted 33 lines · Jeff Garzik
Quoted 23 lines · Alan Cox
Quoted 20 lines · On Wed, 25 Nov 2009 18:09:48 +0100 Bartlomiej…
From: Bartlomiej Zolnierkiewicz<[email protected]>
Subject: [PATCH]pata_pdc202xx_old: document known issuesDocument known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
Signed-off-by Bartlomiej Zolnierkiewicz<[email protected]>--- drivers/ata/Kconfig | 4 ++++ 1 file changed, 4 insertions(+)Index: b/drivers/ata/Kconfig
===================================================================drivers/ata/Kconfig +0
-0@@ -583,6 +583,10 @@ config PATA_PDC_OLD This option enables support for the Promise 20246, 20262, 20263, 20265 and 20267 adapters.Quoted 8 lines
drivers/ata/Kconfig config PATA_PDC_OLD · line 588
Quoted 3 lines
drivers/ata/Kconfig +3
-0+ Known issues: + - UDMA transfers fail mysteriously on some chipsets + - ATAPI DMA is unsupported currentlyNot sure this is useful, because the reports of UDMA failures are lower than most other reports. Should IPV6 have "known issues, mysterious timer list corruption" for example which occurs far more. Not do we list 'no atapi dma' in the help for the IDE SII driver ?
Quoted 8 lines
If the chip can support ATAPI DMI, but the driver does not, that deserves a comment, even if it's "hardware bugs prevent ATAPI DMA" or "ATAPI DMA would require much more code to support, so we did not bother for now"
Ditto for things like useful ideas ("consider PIO-over-DMA in SiI 311x") and other would-be-nice-to-have ideas. These can serve as projects for newbies, or reminders for old-timers.
The problem is that the old driver supported ATAPI DMA so people may have quite different expectations than in case of never-ever-implemented-ideas.
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 62/86] pata_pdc202xx_old: document known issues
Quoted 39 lines · Bartlomiej Zolnierkiewicz
Quoted 38 lines · Jeff Garzik
Quoted 23 lines · Alan Cox
Quoted 20 lines · On Wed, 25 Nov 2009 18:09:48 +0100 Bartlomiej…
From: Bartlomiej Zolnierkiewicz<[email protected]>
Subject: [PATCH]pata_pdc202xx_old: document known issuesDocument known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
Signed-off-by Bartlomiej Zolnierkiewicz<[email protected]>--- drivers/ata/Kconfig | 4 ++++ 1 file changed, 4 insertions(+)Index: b/drivers/ata/Kconfig
===================================================================drivers/ata/Kconfig +0
-0@@ -583,6 +583,10 @@ config PATA_PDC_OLD This option enables support for the Promise 20246, 20262, 20263, 20265 and 20267 adapters.Quoted 8 lines
drivers/ata/Kconfig config PATA_PDC_OLD · line 588
Quoted 3 lines
drivers/ata/Kconfig +3
-0+ Known issues: + - UDMA transfers fail mysteriously on some chipsets + - ATAPI DMA is unsupported currentlyNot sure this is useful, because the reports of UDMA failures are lower than most other reports. Should IPV6 have "known issues, mysterious timer list corruption" for example which occurs far more. Not do we list 'no atapi dma' in the help for the IDE SII driver ?
If the chip can support ATAPI DMI, but the driver does not, that deserves a comment, even if it's "hardware bugs prevent ATAPI DMA" or "ATAPI DMA would require much more code to support, so we did not bother for now"
Quoted 6 lines
Quoted 3 lines
Ditto for things like useful ideas ("consider PIO-over-DMA in SiI 311x") and other would-be-nice-to-have ideas. These can serve as projects for newbies, or reminders for old-timers.
The problem is that the old driver supported ATAPI DMA so people may have quite different expectations than in case of never-ever-implemented-ideas.
This is not rocket science :) Have one section "known issues" and another section "fun ideas to explore." This is English code comments, you may set any level of expectations.
Jeff
Re: [PATCH 62/86] pata_pdc202xx_old: document known issues
Quoted 44 lines · Jeff Garzik
Quoted 43 lines · Bartlomiej Zolnierkiewicz
Quoted 41 lines · Jeff Garzik
Quoted 23 lines · Alan Cox
Quoted 20 lines · On Wed, 25 Nov 2009 18:09:48 +0100 Bartlomiej…
From: Bartlomiej Zolnierkiewicz<[email protected]>
Subject: [PATCH]pata_pdc202xx_old: document known issuesDocument known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly.
Signed-off-by Bartlomiej Zolnierkiewicz<[email protected]>--- drivers/ata/Kconfig | 4 ++++ 1 file changed, 4 insertions(+)Index: b/drivers/ata/Kconfig
===================================================================drivers/ata/Kconfig +0
-0@@ -583,6 +583,10 @@ config PATA_PDC_OLD This option enables support for the Promise 20246, 20262, 20263, 20265 and 20267 adapters.Quoted 8 lines
drivers/ata/Kconfig config PATA_PDC_OLD · line 588
Quoted 3 lines
drivers/ata/Kconfig +3
-0+ Known issues: + - UDMA transfers fail mysteriously on some chipsets + - ATAPI DMA is unsupported currentlyNot sure this is useful, because the reports of UDMA failures are lower than most other reports. Should IPV6 have "known issues, mysterious timer list corruption" for example which occurs far more. Not do we list 'no atapi dma' in the help for the IDE SII driver ?
If the chip can support ATAPI DMI, but the driver does not, that deserves a comment, even if it's "hardware bugs prevent ATAPI DMA" or "ATAPI DMA would require much more code to support, so we did not bother for now"
Ditto for things like useful ideas ("consider PIO-over-DMA in SiI 311x") and other would-be-nice-to-have ideas. These can serve as projects for newbies, or reminders for old-timers.
Quoted 6 lines
Quoted 2 lines
The problem is that the old driver supported ATAPI DMA so people may have quite different expectations than in case of never-ever-implemented-ideas.
This is not rocket science :) Have one section "known issues" and another section "fun ideas to explore." This is English code comments, you may set any level of expectations.
I think it is the best to leave up to the driver maintainer (once we find out who this person is, MAINTAINERS file still lacks info about PATA drivers in -rc8).
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 62/86] pata_pdc202xx_old: document known issues
Quoted 3 lines · Bartlomiej Zolnierkiewicz
I think it is the best to leave up to the driver maintainer (once we find out who this person is,
MAINTAINERSfile still lacks info about PATA drivers in -rc8).
The important thing is taking two minutes to write a relevant comment, not determining who is wearing a crown on his head.
Jeff
Re: [PATCH 62/86] pata_pdc202xx_old: document known issues
Quoted 7 lines · Jeff Garzik
Quoted 3 lines · Bartlomiej Zolnierkiewicz
I think it is the best to leave up to the driver maintainer (once we find out who this person is,
MAINTAINERSfile still lacks info about PATA drivers in -rc8).The important thing is taking two minutes to write a relevant comment,
If you want something changed in the code of pata_pdc202xx_old feel free to make said changes. I'm neither the author nor the maintainer of this driver.
It will only take two minutes of your time anyway.
Quoted 3 lines
not determining who is wearing a crown on his head.
From the fact that it takes years to make a tiny clarification for PATA
support maintainer I'm guessing that by "a crown" you've actually meant "a crown of thorns"..
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 62/86] pata_pdc202xx_old: document known issues
Quoted 11 lines · Bartlomiej Zolnierkiewicz
Quoted 7 lines · Jeff Garzik
Quoted 3 lines · Bartlomiej Zolnierkiewicz
I think it is the best to leave up to the driver maintainer (once we find out who this person is,
MAINTAINERSfile still lacks info about PATA drivers in -rc8).The important thing is taking two minutes to write a relevant comment,
If you want something changed in the code of
pata_pdc202xx_oldfeel free to make said changes. I'm neither the author nor the maintainer of this driver.
You don't need to be the author or maintainer of a driver to submit changes.
Jeff
Re: [PATCH 62/86] pata_pdc202xx_old: document known issues
Quoted 8 lines · Jeff Garzik
Quoted 7 lines · Bartlomiej Zolnierkiewicz
Quoted 6 lines · Jeff Garzik
Quoted 3 lines · Bartlomiej Zolnierkiewicz
I think it is the best to leave up to the driver maintainer (once we find out who this person is,
MAINTAINERSfile still lacks info about PATA drivers in -rc8).
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
The important thing is taking two minutes to write a relevant comment,
If you want something changed in the code of
pata_pdc202xx_oldfeel free to make said changes. I'm neither the author nor the maintainer of this driver.You don't need to be the author or maintainer of a driver to submit changes.
I have neither any obligation nor any motivation to do it and you've already wasted much more than said two minutes for everybody.
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 62/86] pata_pdc202xx_old: document known issues
In reply to Jeff GarzikQuoted 3 lines
Space in the driver source code comment header is cheap. Use liberally :) Write a Shakespearean soliloquy on a chip's hardware bugs, if you'd like.
[Don't tempt me, I've sneaked other little ditties and bits of filk into
the kernel before now, but "Lost Andre" is probably a bit too long and lost on non-Hawkwind fans]
This isnt the driver source code comment at the moment.
Alan
PATCH 63/86 pata_radisys: fix UDMA handling
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_radisys: fix UDMA handling
Set correct bits to switch between UDMA2 and UDMA4.
--- drivers/ata/pata_radisys.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ata/pata_radisys.c +2 -2
@@ -139,9 +139,9 @@ static void radisys_set_dmamode (structpci_read_config_byte (dev,0x4A , &udma_mode);if (adev->xfer_mode ==XFER_UDMA_2 ) - udma_mode &= ~ (1 << adev->devno); + udma_mode &= ~(2 << (adev->devno *4 ));else /* UDMA 4 */ - udma_mode |= (1 << adev->devno); + udma_mode |= (2 << (adev->devno *4 ));pci_write_config_byte (dev,0x4A , udma_mode);
PATCH 64/86 pata_radisys: unify code for programming PIO and MWDMA timings
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_radisys: unify code for programming PIO and MWDMA timings
It results in ~6% decrease in the driver LOC count and also ~1% decrease in the driver binary size (as measured on x86-32).
--- drivers/ata/pata_radisys.c | 66 +++++++++++++++++---------------------------- 1 file changed, 25 insertions(+), 41 deletions(-)
drivers/ata/pata_radisys.c +25 -41
@@ -26,20 +26,9 @@#define DRV_NAME "pata_radisys"#define DRV_VERSION "0.4.4" -/** -* radisys_set_piomode - Initialize host controller PATA PIO timings -* @ap: ATA port -* @adev: Device whose timings we are configuring -* -* Set PIO mode for device, in host controller PCI config space. -* -* LOCKING: -* None (inherited from caller). -*/ - -static void radisys_set_piomode (struct ata_port *ap,struct ata_device *adev) +static void radisys_set_timings (struct ata_port *ap,struct ata_device *adev, +u8 pio,bool use_mwdma) { -unsigned int pio = adev->pio_mode -XFER_PIO_0 ;struct pci_dev *dev =to_pci_dev (ap->host->dev);u16 idetm_data;int control =0 ;
@@ -52,7 +41,7 @@ static void radisys_set_piomode (struct*/ static const /* ISP RTC */ -u8 timings[][2 ] = { {0 ,0 },/* Check me */ +u8 timings[][2 ] = { {0 ,0 }, {0 ,0 }, {1 ,1 }, {2 ,2 },
@@ -62,6 +51,10 @@ static void radisys_set_piomode (struct control |=1 ;/* TIME1 enable */ if (ata_pio_need_iordy (adev)) control |=2 ;/* IE IORDY */ +/* If the drive MWDMA is faster than it can do PIO then +we must force PIO0 for PIO cycles. */ +if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio)) + control =1 ;pci_read_config_word (dev,0x40 , &idetm_data);
@@ -78,6 +71,22 @@ static void radisys_set_piomode (struct }/** +* radisys_set_piomode - Initialize host controller PATA PIO timings +* @ap: ATA port +* @adev: Device whose timings we are configuring +* +* Set PIO mode for device, in host controller PCI config space. +* +* LOCKING: +* None (inherited from caller). +*/ + +static void radisys_set_piomode (struct ata_port *ap,struct ata_device *adev) +{ +radisys_set_timings (ap, adev, adev->pio_mode -XFER_PIO_0 ,0 ); +} + +/** * radisys_set_dmamode - Initialize host controller PATA DMA timings * @ap: Port whose timings we are configuring * @adev: Device to program
@@ -91,22 +100,10 @@ static void radisys_set_piomode (structstatic void radisys_set_dmamode (struct ata_port *ap,struct ata_device *adev) {struct pci_dev *dev =to_pci_dev (ap->host->dev); -u16 idetm_data;u8 udma_enable; -static const /* ISP RTC */ -u8 timings[][2 ] = { {0 ,0 }, - {0 ,0 }, - {1 ,1 }, - {2 ,2 }, - {3 ,3 }, }; - -/* -* MWDMA is driven by the PIO timings. We must also enable -* IORDY unconditionally. -*/ +/* MWDMA is driven by the PIO timings. */ -pci_read_config_word (dev,0x40 , &idetm_data);pci_read_config_byte (dev,0x48 , &udma_enable);if (adev->dma_mode <XFER_UDMA_0 ) {
@@ -115,20 +112,8 @@ static void radisys_set_dmamode (struct XFER_PIO_0, XFER_PIO_3, XFER_PIO_4 };int pio = needed_pio[mwdma] -XFER_PIO_0 ; -int control =3 ;/* IORDY|TIME0 */ - -/* If the drive MWDMA is faster than it can do PIO then -we must force PIO0 for PIO cycles. */ - -if (adev->pio_mode < needed_pio[mwdma]) - control =1 ; -/* Mask out the relevant control and timing bits we will load. Also -clear the other drive TIME register as a precaution */ - - idetm_data &=0xCCCC ; - idetm_data |= control << (4 * adev->devno); - idetm_data |= (timings[pio][0 ] <<12 ) | (timings[pio][1 ] <<8 ); +radisys_set_timings (ap, adev, pio,1 ); udma_enable &= ~(1 << adev->devno); }else {
@@ -147,7 +132,6 @@ static void radisys_set_dmamode (struct udma_enable |= (1 << adev->devno); } -pci_write_config_word (dev,0x40 , idetm_data);pci_write_config_byte (dev,0x48 , udma_enable);/* Track which port is configured */
Re: [PATCH 64/86] pata_radisys: unify code for programming PIO and MWDMA timings
Quoted 45 lines · Bartlomiej Zolnierkiewicz
It results in ~6% decrease in the driver LOC count and also ~1% decrease in the driver binary size (as measured on x86-32).
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/ata/pata_radisys.c | 66 +++++++++++++++++---------------------------- 1 file changed, 25 insertions(+), 41 deletions(-)Index:
b/drivers/ata/pata_radisys.c
===================================================================drivers/ata/pata_radisys.c +3
-14@@ -26,20 +26,9 @@#define DRV_NAME "pata_radisys"#define DRV_VERSION "0.4.4" -/** -* radisys_set_piomode - Initialize host controller PATA PIO timings -* @ap: ATA port -* @adev: Device whose timings we are configuring -* -* Set PIO mode for device, in host controller PCI config space. -* -* LOCKING: -* None (inherited from caller). -*/ - -static void radisys_set_piomode (struct ata_port *ap,struct ata_device *adev) +static void radisys_set_timings (struct ata_port *ap,struct ata_device *adev, +u8 pio,bool use_mwdma) { -unsigned int pio = adev->pio_mode -XFER_PIO_0 ;struct pci_dev *dev =to_pci_dev (ap->host->dev);u16 idetm_data;int control =0 ;@@ -52,7 +41,7 @@ static void radisys_set_piomode (struct*/ static const /* ISP RTC */ -u8 timings[][2 ] = { {0 ,0 },/* Check me */ +u8 timings[][2 ] = { {0 ,0 }, {0 ,0 }, {1 ,1 }, {2 ,2 },
drivers/ata/pata_radisys.c static void radisys_set_piomode (struct · line 55
Quoted 5 lines
drivers/ata/pata_radisys.c +2
-0@@ -62,6 +51,10 @@ static void radisys_set_piomode (struct control |=1 ;/* TIME1 enable */ if (ata_pio_need_iordy (adev)) control |=2 ;/* IE IORDY */ +/* If the drive MWDMA is faster than it can do PIO then +we must force PIO0 for PIO cycles. */
Multi-line comment style should preferrably be:
/* * blah * blah */
drivers/ata/pata_radisys.c static void radisys_set_piomode (struct · line 57
Quoted 2 lines
drivers/ata/pata_radisys.c +2
-0+if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio)) + control =1 ;
Hm, shouldn't that be 8?
drivers/ata/pata_radisys.c static void radisys_set_dmamode (struct · line 124
Quoted 11 lines
drivers/ata/pata_radisys.c +0
-7@@ -115,20 +112,8 @@ static void radisys_set_dmamode (struct XFER_PIO_0, XFER_PIO_3, XFER_PIO_4 };int pio = needed_pio[mwdma] -XFER_PIO_0 ; -int control =3 ;/* IORDY|TIME0 */ - -/* If the drive MWDMA is faster than it can do PIO then -we must force PIO0 for PIO cycles. */ - -if (adev->pio_mode < needed_pio[mwdma]) - control =1 ;
Perhaps there's a bug here?
MBR, Sergei
PATCH 65/86 pata_rdc: unify code for programming PIO and MWDMA timings
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_rdc: unify code for programming PIO and MWDMA timings
It results in ~8% decrease in the driver LOC count and also ~8% decrease in the driver binary size (as measured on x86-32).
Fix rdc_set_piomode() documentation while at it.
--- drivers/ata/pata_rdc.c | 99 ++++++++++++++++--------------------------------- 1 file changed, 33 insertions(+), 66 deletions(-)
drivers/ata/pata_rdc.c +33 -66
@@ -85,20 +85,9 @@ static int rdc_pata_prereset(struct ata_return ata_sff_prereset (link, deadline); } -/** -* rdc_set_piomode - Initialize host controller PATA PIO timings -* @ap: Port whose timings we are configuring -* @adev: um -* -* Set PIO mode for device, in host controller PCI config space. -* -* LOCKING: -* None (inherited from caller). -*/ - -static void rdc_set_piomode (struct ata_port *ap,struct ata_device *adev) +static void rdc_set_timings (struct ata_port *ap,struct ata_device *adev, +u8 pio,bool use_mwdma) { -unsigned int pio = adev->pio_mode -XFER_PIO_0 ;struct pci_dev *dev =to_pci_dev (ap->host->dev);unsigned int is_slave = (adev->devno !=0 );unsigned int master_port= ap->port_no ?0x42 :0x40 ;
@@ -115,13 +104,17 @@ static void rdc_set_piomode(struct ata_p { 2, 1 }, { 2, 3 }, }; -if (pio >=2 ) +if (pio >=2 || use_mwdma) control |=1 ;/* TIME1 enable */ -if (ata_pio_need_iordy (adev)) +if (ata_pio_need_iordy (adev) || use_mwdma) control |=2 ;/* IE enable */ -if (adev->class ==ATA_DEV_ATA ) control |=4 ;/* PPE enable */ +/* If the drive MWDMA is faster than it can do PIO then +we must force PIO into PIO0 */ +if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio)) +/* Enable DMA timing only */ + control |=8 ;/* PIO cycles in PIO0 */ /* PIO configuration clears DTE unconditionally. It will be * programmed in set_dmamode which is guaranteed to be called
@@ -163,6 +156,22 @@ static void rdc_set_piomode(struct ata_p }/** +* rdc_set_piomode - Initialize host controller PATA PIO timings +* @ap: Port whose timings we are configuring +* @adev: Drive in question +* +* Set PIO mode for device, in host controller PCI config space. +* +* LOCKING: +* None (inherited from caller). +*/ + +static void rdc_set_piomode (struct ata_port *ap,struct ata_device *adev) +{ +rdc_set_timings (ap, adev, adev->pio_mode -XFER_PIO_0 ,0 ); +} + +/** * rdc_set_dmamode - Initialize host controller PATA PIO timings * @ap: Port whose timings we are configuring * @adev: Drive in question
@@ -176,28 +185,18 @@ static void rdc_set_piomode(struct ata_pstatic void rdc_set_dmamode (struct ata_port *ap,struct ata_device *adev) {struct pci_dev *dev =to_pci_dev (ap->host->dev); -u8 master_port = ap->port_no ?0x42 :0x40 ; -u16 master_data;u8 speed = adev->dma_mode;int devid = adev->devno +2 * ap->port_no;u8 udma_enable =0 ; -static const /* ISP RTC */ -u8 timings[][2 ] = { {0 ,0 }, - {0 ,0 }, - {1 ,0 }, - {2 ,1 }, - {2 ,3 }, }; - -pci_read_config_word (dev, master_port, &master_data); -pci_read_config_byte (dev,0x48 , &udma_enable); -if (speed >=XFER_UDMA_0 ) { -unsigned int udma = adev->dma_mode -XFER_UDMA_0 ; +unsigned int udma = speed -XFER_UDMA_0 ;u16 udma_timing;u16 ideconf;int u_clock, u_speed; +pci_read_config_byte (dev,0x48 , &udma_enable); +/* * UDMA is handled by a combination of clock switching and * selection of dividers
@@ -226,50 +225,18 @@ static void rdc_set_dmamode(struct ata_p ideconf &= ~(0x1001 << devid); ideconf |= u_clock << devid;pci_write_config_word (dev,0x54 , ideconf); + +pci_write_config_byte (dev,0x48 , udma_enable); }else { -/* -* MWDMA is driven by the PIO timings. We must also enable -* IORDY unconditionally along with TIME1. PPE has already -* been set when the PIO timing was set. -*/ -unsigned int mwdma = adev->dma_mode -XFER_MW_DMA_0 ; -unsigned int control; -u8 slave_data; +/* MWDMA is driven by the PIO timings. */ +unsigned int mwdma = speed -XFER_MW_DMA_0 ;const unsigned int needed_pio[3 ] = {XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 };int pio = needed_pio[mwdma] -XFER_PIO_0 ; - control =3 ;/* IORDY|TIME1 */ - -/* If the drive MWDMA is faster than it can do PIO then -we must force PIO into PIO0 */ - -if (adev->pio_mode < needed_pio[mwdma]) -/* Enable DMA timing only */ - control |=8 ;/* PIO cycles in PIO0 */ - -if (adev->devno) {/* Slave */ - master_data &=0xFF4F ;/* Mask out IORDY|TIME1|DMAONLY */ - master_data |= control <<4 ; -pci_read_config_byte (dev,0x44 , &slave_data); - slave_data &= (ap->port_no ?0x0f :0xf0 ); -/* Load the matching timing */ - slave_data |= ((timings[pio][0 ] <<2 ) | timings[pio][1 ]) << (ap->port_no ?4 :0 ); -pci_write_config_byte (dev,0x44 , slave_data); - }else {/* Master */ - master_data &=0xCCF4 ;/* Mask out IORDY|TIME1|DMAONLY -and master timing bits */ - master_data |= control; - master_data |= - (timings[pio][0 ] <<12 ) | - (timings[pio][1 ] <<8 ); - } - - udma_enable &= ~(1 << devid); -pci_write_config_word (dev, master_port, master_data); +rdc_set_timings (ap, adev, pio,1 ); } -pci_write_config_byte (dev,0x48 , udma_enable); }static struct ata_port_operations rdc_pata_ops = {
PATCH 66/86 pata_rz1000: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_rz1000: add 32-bit PIO support
There shouldn't be any problems with it as IDE rz1000 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_rz1000.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/ata/pata_rz1000.c +2 -0
@@ -58,6 +58,8 @@ static struct ata_port_operations rz1000 .inherits = &ata_sff_port_ops, .cable_detect = ata_cable_40wire, .set_mode = rz1000_set_mode, + .sff_data_xfer = ata_sff_data_xfer32, + .port_start = ata_sff_port_start32, };static int rz1000_fifo_disable (struct pci_dev *pdev)
PATCH 67/86 pata_rz1000: Power Management fix
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_rz1000: Power Management fix
Fix ->resume method to re-enable & re-init PCI device properly before doing chipset specific setup.
--- drivers/ata/pata_rz1000.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/ata/pata_rz1000.c +10 -1
@@ -107,11 +107,20 @@ static int rz1000_init_one (struct pci_d#ifdef CONFIG_PM static int rz1000_reinit_one (struct pci_dev *pdev) { +struct ata_host *host =dev_get_drvdata (&pdev->dev); +int rc; + + rc =ata_pci_device_do_resume (pdev); +if (rc) +return rc; +/* If this fails on resume (which is a "cant happen" case), we must stop as any progress risks data loss */ if (rz1000_fifo_disable (pdev))panic ("rz1000 fifo" ); -return ata_pci_device_resume (pdev); + +ata_host_resume (host); +return 0 ; }#endif
PATCH 68/86 pata_sc1200: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_sc1200: add 32-bit PIO support
There shouldn't be any problems with it as IDE sc1200 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_sc1200.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_sc1200.c +1 -1
@@ -208,7 +208,7 @@ static struct scsi_host_template sc1200_ };static struct ata_port_operations sc1200_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .qc_prep = ata_sff_dumb_qc_prep, .qc_issue = sc1200_qc_issue, .qc_defer = sc1200_qc_defer,
PATCH 69/86 pata_scc: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_scc: add 32-bit PIO support
There shouldn't be any problems with it as IDE scc_pata host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_scc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_scc.c +1 -1
@@ -966,7 +966,7 @@ static struct scsi_host_template scc_sht };static struct ata_port_operations scc_pata_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .set_piomode = scc_set_piomode, .set_dmamode = scc_set_dmamode,
Re: [PATCH 69/86] pata_scc: add 32-bit PIO support
Quoted 5 lines · On Wed, 25 Nov 2009 18:10:39 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_scc: add 32-bit PIO supportThere shouldn't be any problems with it as IDE
scc_patahost driver has been allowing 32-bit PIO operations for years.
NAK; Read the code - it uses its own private data_xfer handler anyway
Re: [PATCH 69/86] pata_scc: add 32-bit PIO support
Quoted 10 lines · Alan Cox
Quoted 5 lines · On Wed, 25 Nov 2009 18:10:39 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH]pata_scc: add 32-bit PIO supportThere shouldn't be any problems with it as IDE
scc_patahost driver has been allowing 32-bit PIO operations for years.NAK; Read the code - it uses its own private
data_xferhandler anyway
Ah, this one can be indeed dropped.
--
Bartlomiej Zolnierkiewicz
PATCH 70/86 pata_scc: add proper cable detection method
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_scc: add proper cable detection method
Use standard ata_cable_80wire() method for the cable detection, as a bonus this allows us to use the default ->prereset method.
--- drivers/ata/pata_scc.c | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-)
drivers/ata/pata_scc.c +1 -13
@@ -865,18 +865,6 @@ static void scc_freeze (struct ata_port }/** -* scc_pata_prereset - prepare for reset -* @ap: ATA port to be reset -* @deadline: deadline jiffies for the operation -*/ - -static int scc_pata_prereset (struct ata_link *link,unsigned long deadline) -{ - link->ap->cbl =ATA_CBL_PATA80 ; -return ata_sff_prereset (link, deadline); -} - -/** * scc_postreset - standard postreset callback * @ap: the target ata_port * @classes: classes of attached devices
@@ -986,7 +974,7 @@ static struct ata_port_operations scc_pa .sff_data_xfer = scc_data_xfer, .freeze = scc_freeze, - .prereset = scc_pata_prereset, + .cable_detect = ata_cable_80wire, .softreset = scc_softreset, .postreset = scc_postreset, .post_internal_cmd = scc_bmdma_stop,
PATCH 71/86 pata_sch: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_sch: add 32-bit PIO support
--- drivers/ata/pata_sch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_sch.c +1 -1
@@ -76,7 +76,7 @@ static struct scsi_host_template sch_sht };static struct ata_port_operations sch_pata_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .cable_detect = ata_cable_unknown, .set_piomode = sch_set_piomode, .set_dmamode = sch_set_dmamode,
PATCH 72/86 pata_serverworks: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_serverworks: add 32-bit PIO support
There shouldn't be any problems with it as IDE serverworks host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_serverworks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_serverworks.c +1 -1
@@ -300,7 +300,7 @@ static struct scsi_host_template serverw };static struct ata_port_operations serverworks_osb4_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .cable_detect = serverworks_cable_detect, .mode_filter = serverworks_osb4_filter, .set_piomode = serverworks_set_piomode,
PATCH 73/86 pata_serverworks: use standard cable detection methods
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_serverworks: use standard cable detection methods
--- drivers/ata/pata_serverworks.c | 45 ++++++++++------------------------------- 1 file changed, 12 insertions(+), 33 deletions(-)
drivers/ata/pata_serverworks.c +12 -33
@@ -64,7 +64,8 @@ static const char *csb_bad_ata100[] = {* bits of the subsystem ID. */ -static int dell_cable (struct ata_port *ap) { +static int dell_cable (struct ata_port *ap) +{struct pci_dev *pdev =to_pci_dev (ap->host->dev);if (pdev->subsystem_device & (1 << (ap->port_no +14 )))
@@ -81,7 +82,8 @@ static int dell_cable(struct ata_port *a* need to extend the Dell one in future */ -static int sun_cable (struct ata_port *ap) { +static int sun_cable (struct ata_port *ap) +{struct pci_dev *pdev =to_pci_dev (ap->host->dev);if (pdev->subsystem_device & (1 << (ap->port_no +14 )))
@@ -89,29 +91,6 @@ static int sun_cable(struct ata_port *apreturn ATA_CBL_PATA40 ; } -/** -* osb4_cable - OSB4 cable detect -* @ap: ATA port to check -* -* The OSB4 isn't UDMA66 capable so this is easy -*/ - -static int osb4_cable (struct ata_port *ap) { -return ATA_CBL_PATA40 ; -} - -/** -* csb_cable - CSB5/6 cable detect -* @ap: ATA port to check -* -* Serverworks default arrangement is to use the drive side detection -* only. -*/ - -static int csb_cable (struct ata_port *ap) { -return ATA_CBL_PATA_UNK ; -} -struct sv_cable_table {int device;int subvendor;
@@ -124,14 +103,14 @@ struct sv_cable_table {*/ static struct sv_cable_table cable_detect[] = { - {PCI_DEVICE_ID_SERVERWORKS_CSB5IDE ,PCI_VENDOR_ID_DELL , dell_cable }, - {PCI_DEVICE_ID_SERVERWORKS_CSB6IDE ,PCI_VENDOR_ID_DELL , dell_cable }, - {PCI_DEVICE_ID_SERVERWORKS_CSB5IDE ,PCI_VENDOR_ID_SUN , sun_cable }, - {PCI_DEVICE_ID_SERVERWORKS_OSB4IDE ,PCI_ANY_ID , osb4_cable }, - {PCI_DEVICE_ID_SERVERWORKS_CSB5IDE ,PCI_ANY_ID , csb_cable }, - {PCI_DEVICE_ID_SERVERWORKS_CSB6IDE ,PCI_ANY_ID , csb_cable }, - {PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2 ,PCI_ANY_ID , csb_cable }, - {PCI_DEVICE_ID_SERVERWORKS_HT1000IDE ,PCI_ANY_ID , csb_cable }, + {PCI_DEVICE_ID_SERVERWORKS_CSB5IDE ,PCI_VENDOR_ID_DELL , dell_cable }, + {PCI_DEVICE_ID_SERVERWORKS_CSB6IDE ,PCI_VENDOR_ID_DELL , dell_cable }, + {PCI_DEVICE_ID_SERVERWORKS_CSB5IDE ,PCI_VENDOR_ID_SUN , sun_cable }, + {PCI_DEVICE_ID_SERVERWORKS_OSB4IDE ,PCI_ANY_ID , ata_cable_40wire }, + {PCI_DEVICE_ID_SERVERWORKS_CSB5IDE ,PCI_ANY_ID , ata_cable_unknown }, + {PCI_DEVICE_ID_SERVERWORKS_CSB6IDE ,PCI_ANY_ID , ata_cable_unknown }, + {PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2 ,PCI_ANY_ID , ata_cable_unknown }, + {PCI_DEVICE_ID_SERVERWORKS_HT1000IDE ,PCI_ANY_ID , ata_cable_unknown }, { } };
PATCH 74/86 pata_serverworks: add serverworks_fixup()
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_serverworks: add serverworks_fixup()
Factor out common code from serverworks_[re]init_one() to serverworks_fixup().
--- drivers/ata/pata_serverworks.c | 57 ++++++++++++++++++++--------------------- 1 file changed, 29 insertions(+), 28 deletions(-)
drivers/ata/pata_serverworks.c +29 -28
@@ -371,6 +371,31 @@ static void serverworks_fixup_ht1000(strpci_write_config_byte (pdev,0x5A , btr); } +static int serverworks_fixup (struct pci_dev *pdev) +{ +int rc =0 ; + +/* Force master latency timer to 64 PCI clocks */ +pci_write_config_byte (pdev,PCI_LATENCY_TIMER ,0x40 ); + +switch (pdev->device) { +case PCI_DEVICE_ID_SERVERWORKS_OSB4IDE : + rc =serverworks_fixup_osb4 (pdev); +break ; +case PCI_DEVICE_ID_SERVERWORKS_CSB5IDE : +ata_pci_bmdma_clear_simplex (pdev); +/* fall through */ +case PCI_DEVICE_ID_SERVERWORKS_CSB6IDE : +case PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2 : + rc =serverworks_fixup_csb (pdev); +break ; +case PCI_DEVICE_ID_SERVERWORKS_HT1000IDE : +serverworks_fixup_ht1000 (pdev); +break ; + } + +return rc; +}static int serverworks_init_one (struct pci_dev *pdev,const struct pci_device_id *id) {
@@ -408,13 +433,12 @@ static int serverworks_init_one(struct pif (rc)return rc; -/* Force master latency timer to 64 PCI clocks */ -pci_write_config_byte (pdev,PCI_LATENCY_TIMER ,0x40 ); + rc =serverworks_fixup (pdev);/* OSB4 : South Bridge and IDE */ if (pdev->device ==PCI_DEVICE_ID_SERVERWORKS_OSB4IDE ) {/* Select non UDMA capable OSB4 if we can't do fixups */ -if (serverworks_fixup_osb4 (pdev) <0 ) +if (rc <0 ) ppi[0 ] = &info[1 ]; }/* setup CSB5/CSB6 : South Bridge and IDE option RAID */
@@ -424,19 +448,13 @@ static int serverworks_init_one(struct p/* If the returned btr is the newer revision then select the right info block */ -if (serverworks_fixup_csb (pdev) ==3 ) +if (rc ==3 ) ppi[0 ] = &info[3 ];/* Is this the 3rd channel CSB6 IDE ? */ if (pdev->device ==PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2 ) ppi[1 ] = &ata_dummy_port_info; } -/* setup HT1000E */ -else if (pdev->device ==PCI_DEVICE_ID_SERVERWORKS_HT1000IDE ) -serverworks_fixup_ht1000 (pdev); - -if (pdev->device ==PCI_DEVICE_ID_SERVERWORKS_CSB5IDE ) -ata_pci_bmdma_clear_simplex (pdev);return ata_pci_sff_init_one (pdev, ppi, &serverworks_sht,NULL ); }
@@ -451,24 +469,7 @@ static int serverworks_reinit_one(structif (rc)return rc; -/* Force master latency timer to 64 PCI clocks */ -pci_write_config_byte (pdev,PCI_LATENCY_TIMER ,0x40 ); - -switch (pdev->device) { -case PCI_DEVICE_ID_SERVERWORKS_OSB4IDE : -serverworks_fixup_osb4 (pdev); -break ; -case PCI_DEVICE_ID_SERVERWORKS_CSB5IDE : -ata_pci_bmdma_clear_simplex (pdev); -/* fall through */ -case PCI_DEVICE_ID_SERVERWORKS_CSB6IDE : -case PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2 : -serverworks_fixup_csb (pdev); -break ; -case PCI_DEVICE_ID_SERVERWORKS_HT1000IDE : -serverworks_fixup_ht1000 (pdev); -break ; - } + (void )serverworks_fixup (pdev);ata_host_resume (host);return 0 ;
PATCH 75/86 pata_sl82c105: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_sl82c105: add 32-bit PIO support
There shouldn't be any problems with it as IDE sl82c105 host driver has been using 32-bit PIO operations for years.
--- drivers/ata/pata_sl82c105.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_sl82c105.c +1 -1
@@ -232,7 +232,7 @@ static struct scsi_host_template sl82c10 };static struct ata_port_operations sl82c105_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .qc_defer = sl82c105_qc_defer, .bmdma_start = sl82c105_bmdma_start, .bmdma_stop = sl82c105_bmdma_stop,
PATCH 76/86 pata_sl82c105: add Power Management support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_sl82c105: add Power Management support
There shouldn't be any problems with it as IDE sl82c105 host driver has been supporting Power Management for over year now.
--- drivers/ata/pata_sl82c105.c | 37 ++++++++++++++++++++++++++++++++----- 1 file changed, 32 insertions(+), 5 deletions(-)
drivers/ata/pata_sl82c105.c +32 -5
@@ -1,6 +1,7 @@/* * pata_sl82c105.c - SL82C105 PATA for new ATA layer * (C) 2005 Red Hat Inc +* (C) 2009 Bartlomiej Zolnierkiewicz * * Based in part on linux/drivers/ide/pci/sl82c105.c * SL82C105/Winbond 553 IDE driver
@@ -278,6 +279,14 @@ static int sl82c105_bridge_revision(strureturn bridge->revision; } +static void sl82c105_fixup (struct pci_dev *pdev) +{ +u32 val; + +pci_read_config_dword (pdev,0x40 , &val); + val |=CTRL_P0EN |CTRL_P0F16 |CTRL_P1F16 ; +pci_write_config_dword (pdev,0x40 , val); +}static int sl82c105_init_one (struct pci_dev *dev,const struct pci_device_id *id) {
@@ -295,7 +304,6 @@ static int sl82c105_init_one(struct pci_/* for now use only the first port */ const struct ata_port_info *ppi[] = { &info_early,NULL }; -u32 val;int rev;int rc;
@@ -312,13 +320,28 @@ static int sl82c105_init_one(struct pci_else ppi[0 ] = &info_dma; -pci_read_config_dword (dev,0x40 , &val); - val |=CTRL_P0EN |CTRL_P0F16 |CTRL_P1F16 ; -pci_write_config_dword (dev,0x40 , val); +sl82c105_fixup (dev);return ata_pci_sff_init_one (dev, ppi, &sl82c105_sht,NULL ); } +#ifdef CONFIG_PM +static int sl82c105_reinit_one (struct pci_dev *pdev) +{ +struct ata_host *host =dev_get_drvdata (&pdev->dev); +int rc; + + rc =ata_pci_device_do_resume (pdev); +if (rc) +return rc; + +sl82c105_fixup (pdev); + +ata_host_resume (host); +return 0 ; +} +#endif +static const struct pci_device_id sl82c105[] = { {PCI_VDEVICE (WINBOND ,PCI_DEVICE_ID_WINBOND_82C105 ), },
@@ -329,7 +352,11 @@ static struct pci_driver sl82c105_pci_dr .name = DRV_NAME, .id_table = sl82c105, .probe = sl82c105_init_one, - .remove = ata_pci_remove_one + .remove = ata_pci_remove_one, +#ifdef CONFIG_PM + .suspend = ata_pci_device_suspend, + .resume = sl82c105_reinit_one, +#endif };static int __init sl82c105_init (void )
PATCH 77/86 pata_sis: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_sis: add 32-bit PIO support
There shouldn't be any problems with it as IDE sis5513 host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_sis.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ata/pata_sis.c +2 -2
@@ -504,14 +504,14 @@ static struct scsi_host_template sis_sht };static struct ata_port_operations sis_133_for_sata_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .set_piomode = sis_133_set_piomode, .set_dmamode = sis_133_set_dmamode, .cable_detect = sis_133_cable_detect, };static struct ata_port_operations sis_base_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .prereset = sis_pre_reset, };
PATCH 78/86 pata_sis: Power Management fix
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_sis: Power Management fix
Call sis_fixup() on resume.
--- drivers/ata/pata_sis.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-)
drivers/ata/pata_sis.c +19 -2
@@ -2,7 +2,7 @@* pata_sis.c - SiS ATA driver * * (C) 2005 Red Hat -* (C) 2007 Bartlomiej Zolnierkiewicz +* (C) 2007,2009 Bartlomiej Zolnierkiewicz * * Based upon linux/drivers/ide/pci/sis5513.c * Copyright (C) 1999-2000 Andre Hedrick <[email protected]>
@@ -829,6 +829,23 @@ static int sis_init_one (struct pci_devreturn ata_pci_sff_init_one (pdev, ppi, &sis_sht, chipset); } +#ifdef CONFIG_PM +static int sis_reinit_one (struct pci_dev *pdev) +{ +struct ata_host *host =dev_get_drvdata (&pdev->dev); +int rc; + + rc =ata_pci_device_do_resume (pdev); +if (rc) +return rc; + +sis_fixup (pdev, host->private_data); + +ata_host_resume (host); +return 0 ; +} +#endif +static const struct pci_device_id sis_pci_tbl[] = { {PCI_VDEVICE (SI ,0x5513 ), },/* SiS 5513 */ {PCI_VDEVICE (SI ,0x5518 ), },/* SiS 5518 */
@@ -844,7 +861,7 @@ static struct pci_driver sis_pci_driver .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = ata_pci_device_resume, + .resume = sis_reinit_one,#endif };
PATCH 79/86 pata_triflex: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_triflex: add 32-bit PIO support
There shouldn't be any problems with it as IDE triflex host driver has been allowing 32-bit PIO operations for years.
--- drivers/ata/pata_triflex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_triflex.c +1 -1
@@ -179,7 +179,7 @@ static struct scsi_host_template triflex };static struct ata_port_operations triflex_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .bmdma_start = triflex_bmdma_start, .bmdma_stop = triflex_bmdma_stop, .cable_detect = ata_cable_40wire,
PATCH 80/86 libata: make ata_sff_data_xfer_noirq() work with 32-bit PIO
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: make ata_sff_data_xfer_noirq() work with 32-bit PIO
Always use ata_sff_data_xfer32() in ata_sff_data_xfer_noirq() so the latter can be also used for host controllers supporting 32-bit PIO operations.
[ It is safe since if 32-bit PIO is not supported or enabled
ata_sff_data_xfer32() will fallback to a standard method. ]
--- drivers/ata/libata-sff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/libata-sff.c +1 -1
@@ -838,7 +838,7 @@ unsigned int ata_sff_data_xfer_noirq(strunsigned int consumed;local_irq_save (flags); - consumed =ata_sff_data_xfer (dev, buf, buflen, rw); + consumed =ata_sff_data_xfer32 (dev, buf, buflen, rw);local_irq_restore (flags);return consumed;
PATCH 81/86 pata_via: add 32-bit PIO support
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_via: add 32-bit PIO support
There shouldn't be any problems with it as IDE via82cxxx host driver has been using 32-bit PIO operations for years.
--- drivers/ata/pata_via.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/pata_via.c +1 -1
@@ -420,7 +420,7 @@ static struct scsi_host_template via_sht };static struct ata_port_operations via_port_ops = { - .inherits = &ata_bmdma_port_ops, + .inherits = &ata_bmdma32_port_ops, .cable_detect = via_cable_detect, .set_piomode = via_set_piomode, .set_dmamode = via_set_dmamode,
PATCH 82/86 pata_via: clear UDMA transfer mode bit for PIO and MWDMA
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_via: clear UDMA transfer mode bit for PIO and MWDMA
Fix register naming while at it.
--- drivers/ata/pata_via.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-)
drivers/ata/pata_via.c +13 -6
@@ -296,14 +296,21 @@ static void via_do_set_mode(struct ata_p }/* Set UDMA unless device is not UDMA capable */ -if (udma_type && t.udma) { -u8 cable80_status; +if (udma_type) { +u8 udma_etc; -/* Get 80-wire cable detection bit */ -pci_read_config_byte (pdev,0x50 + offset, &cable80_status); - cable80_status &=0x10 ; +pci_read_config_byte (pdev,0x50 + offset, &udma_etc); -pci_write_config_byte (pdev,0x50 + offset, ut | cable80_status); +/* clear transfer mode bit */ + udma_etc &= ~0x20 ; + +if (t.udma) { +/* preserve 80-wire cable detection bit */ + udma_etc &=0x10 ; + udma_etc |= ut; + } + +pci_write_config_byte (pdev,0x50 + offset, udma_etc); } }
Re: [PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA
drivers/ata/pata_via.c static void via_do_set_mode(struct ata_p · line 300
Quoted 5 lines
drivers/ata/pata_via.c +2
-2/* Set UDMA unless device is not UDMA capable */ -if (udma_type && t.udma) { -u8 cable80_status; +if (udma_type) { +u8 udma_etc;
This seems odd the original test is that we are a udma controller and have a udma timing specified. Otherwise there is no point doing any work.
The rest seems to be gratuitious register renaming and makes the patches hard to review. Please split this sort of stuff up.
Re: [PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA
Quoted 8 lines · Alan Cox
Review
Quoted 5 lines
(quoted diff) +2
-2/* Set UDMA unless device is not UDMA capable */ - if (udma_type && t.udma) { - u8 cable80_status; + if (udma_type) { + u8 udma_etc;This seems odd the original test is that we are a udma controller and have a udma timing specified. Otherwise there is no point doing any work.
The patch is based on the data sheet and is needed.
We may not hit the problem with the current chipset tuning model but things are not set in the stone and one day we may pay a price for embedding such undocumented assumptions into our drivers.
Quoted 2 lines
The rest seems to be gratuitious register renaming and makes the patches hard to review. Please split this sort of stuff up.
The name now matches documentation.
Do you really find such tidy patch hard to review?
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_via: clear UDMA transfer mode bit for PIO and MWDMA
Fix register naming while at it.
--- drivers/ata/pata_via.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-)
drivers/ata/pata_via.c +13 -6
@@ -296,14 +296,21 @@ static void via_do_set_mode(struct ata_p }/* Set UDMA unless device is not UDMA capable */ -if (udma_type && t.udma) { -u8 cable80_status; +if (udma_type) { +u8 udma_etc; -/* Get 80-wire cable detection bit */ -pci_read_config_byte (pdev,0x50 + offset, &cable80_status); - cable80_status &=0x10 ; +pci_read_config_byte (pdev,0x50 + offset, &udma_etc); -pci_write_config_byte (pdev,0x50 + offset, ut | cable80_status); +/* clear transfer mode bit */ + udma_etc &= ~0x20 ; + +if (t.udma) { +/* preserve 80-wire cable detection bit */ + udma_etc &=0x10 ; + udma_etc |= ut; + } + +pci_write_config_byte (pdev,0x50 + offset, udma_etc); } }
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA
Quoted 1 line
Do you really find such tidy patch hard to review?
When doing it at speed - yes.
drivers/ata/pata_via.c static void via_do_set_mode(struct ata_p · line 300
Quoted 5 lines
drivers/ata/pata_via.c +2
-2/* Set UDMA unless device is not UDMA capable */ -if (udma_type && t.udma) { -u8 cable80_status; +if (udma_type) { +u8 udma_etc;
Ok that makes sense - we in fact could hit this case on a failure changedown from UDMA to PIO.
Re: [PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA
Quoted 3 lines · Alan Cox
Quoted 1 line
Do you really find such tidy patch hard to review?
When doing it at speed - yes.
Do you review everybody else patches 'at speed' or only mine?
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA
Quoted 6 lines · On Wed, 25 Nov 2009 19:10:06 +0100 Bartlomiej Zolnierkiewicz…
Quoted 3 lines · Alan Cox
Quoted 1 line
Do you really find such tidy patch hard to review?
When doing it at speed - yes.
Do you review everybody else patches 'at speed' or only mine?
All of them when I've got a lot of stuff to do. Owing to a lack of time machine and 500 hour days it's neccessary.
Also btw take it is a compliment - there are some people's patches I always review in detail and it isn't the patches you expect to be *right* that you spend the time on...
Re: [PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA
Quoted 8 lines · Alan Cox
Quoted 5 lines · On Wed, 25 Nov 2009 19:10:06 +0100 Bartlomiej Zolnierkiewicz…
Quoted 3 lines · Alan Cox
Quoted 1 line
Do you really find such tidy patch hard to review?
When doing it at speed - yes.
Quoted 8 lines
Quoted 1 line
Do you review everybody else patches 'at speed' or only mine?
All of them when I've got a lot of stuff to do. Owing to a lack of time machine and 500 hour days it's neccessary.
Also btw take it is a compliment - there are some people's patches I always review in detail and it isn't the patches you expect to be *right* that you spend the time on...
Well, you don't really have to review every single patch touching areas that you're just interested in (and if you're maintaining those drivers please document it in MAINTAINERS file, thanks).
The problem is that in case you're not entirely correct, which is much more likely when doing things 'at speed', you're will be wasting time for everybody (not that I really care that much about others' time but I do care about mine).
--
Bartlomiej Zolnierkiewicz
PATCH 83/86 pata_via: add via_fixup()
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_via: add via_fixup()
Factor out common code from via_[re]init_one() to via_fixup().
--- drivers/ata/pata_via.c | 53 +++++++++++++++++++++---------------------------- 1 file changed, 23 insertions(+), 30 deletions(-)
drivers/ata/pata_via.c +23 -30
@@ -468,6 +468,27 @@ static void via_config_fifo(struct pci_d } } +static void via_fixup (struct pci_dev *pdev,const struct via_isa_bridge *config) +{ +u32 timing; + +/* Initialise the FIFO for the enabled channels. */ +via_config_fifo (pdev, config->flags); + +if ((config->flags &VIA_UDMA ) ==VIA_UDMA_66 ) { +/* The 66 MHz devices require we enable the clock */ +pci_read_config_dword (pdev,0x50 , &timing); + timing |=0x80008 ; +pci_write_config_dword (pdev,0x50 , timing); + } +if (config->flags &VIA_BAD_CLK66 ) { +/* Disable the 66MHz clock on problem devices */ +pci_read_config_dword (pdev,0x50 , &timing); + timing &= ~0x80008 ; +pci_write_config_dword (pdev,0x50 , timing); + } +} +/** * via_init_one - discovery callback * @pdev: PCI device
@@ -530,7 +551,6 @@ static int via_init_one(struct pci_dev *const struct via_isa_bridge *config;static int printed_version;u8 enable; -u32 timing;unsigned long flags = id->driver_data;int rc;
@@ -568,9 +588,6 @@ static int via_init_one(struct pci_dev *return -ENODEV ; } -/* Initialise the FIFO for the enabled channels. */ -via_config_fifo (pdev, config->flags); -/* Clock set up */ switch (config->flags &VIA_UDMA ) {case VIA_UDMA_NONE :
@@ -584,10 +601,6 @@ static int via_init_one(struct pci_dev *break ;case VIA_UDMA_66 : ppi[0 ] = &via_udma66_info; -/* The 66 MHz devices require we enable the clock */ -pci_read_config_dword (pdev,0x50 , &timing); - timing |=0x80008 ; -pci_write_config_dword (pdev,0x50 , timing);break ;case VIA_UDMA_100 : ppi[0 ] = &via_udma100_info;
@@ -600,12 +613,7 @@ static int via_init_one(struct pci_dev *return -ENODEV ; } -if (config->flags &VIA_BAD_CLK66 ) { -/* Disable the 66MHz clock on problem devices */ -pci_read_config_dword (pdev,0x50 , &timing); - timing &= ~0x80008 ; -pci_write_config_dword (pdev,0x50 , timing); - } +via_fixup (pdev, config);/* We have established the device type, now fire it up */ return ata_pci_sff_init_one (pdev, ppi, &via_sht, (void *)config);
@@ -624,29 +632,14 @@ static int via_init_one(struct pci_dev *static int via_reinit_one (struct pci_dev *pdev) { -u32 timing;struct ata_host *host =dev_get_drvdata (&pdev->dev); -const struct via_isa_bridge *config = host->private_data;int rc; rc =ata_pci_device_do_resume (pdev);if (rc)return rc; -via_config_fifo (pdev, config->flags); - -if ((config->flags &VIA_UDMA ) ==VIA_UDMA_66 ) { -/* The 66 MHz devices require we enable the clock */ -pci_read_config_dword (pdev,0x50 , &timing); - timing |=0x80008 ; -pci_write_config_dword (pdev,0x50 , timing); - } -if (config->flags &VIA_BAD_CLK66 ) { -/* Disable the 66MHz clock on problem devices */ -pci_read_config_dword (pdev,0x50 , &timing); - timing &= ~0x80008 ; -pci_write_config_dword (pdev,0x50 , timing); - } +via_fixup (pdev, host->private_data);ata_host_resume (host);return 0 ;
PATCH 84/86 libata: add ata_mwdma_to_pio() inline helper
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: add ata_mwdma_to_pio() inline helper
--- drivers/ata/ata_piix.c | 11 ++--------- drivers/ata/pata_efar.c | 8 +------- drivers/ata/pata_it8213.c | 8 +------- drivers/ata/pata_oldpiix.c | 9 +-------- drivers/ata/pata_radisys.c | 12 +++--------- drivers/ata/pata_rdc.c | 11 ++--------- include/linux/ata.h | 11 +++++++++++ 7 files changed, 21 insertions(+), 49 deletions(-)
drivers/ata/ata_piix.c +2 -9
@@ -831,16 +831,9 @@ static void do_pata_set_dmamode(struct apci_write_config_byte (dev,0x48 , udma_enable);spin_unlock_irqrestore (&piix_lock, flags); - }else { + }else /* MWDMA is driven by the PIO timings. */ -unsigned int mwdma = speed -XFER_MW_DMA_0 ; -const unsigned int needed_pio[3 ] = { -XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 - }; -int pio = needed_pio[mwdma] -XFER_PIO_0 ; - -piix_set_timings (ap, adev, pio,1 ); - } +piix_set_timings (ap, adev,ata_mwdma_to_pio (speed),1 ); }/**
drivers/ata/pata_efar.c +1 -7
@@ -176,13 +176,7 @@ static void efar_set_dmamode (struct atapci_write_config_word (dev,0x4A , udma_timing); }else {/* MWDMA is driven by the PIO timings. */ -unsigned int mwdma = speed -XFER_MW_DMA_0 ; -const unsigned int needed_pio[3 ] = { -XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 - }; -int pio = needed_pio[mwdma] -XFER_PIO_0 ; - -efar_set_timings (ap, adev, pio,1 ); +efar_set_timings (ap, adev,ata_mwdma_to_pio (speed),1 ); udma_enable &= ~(1 << devid); }
drivers/ata/pata_it8213.c +1 -7
@@ -186,13 +186,7 @@ static void it8213_set_dmamode (struct apci_write_config_word (dev,0x54 , ideconf); }else {/* MWDMA is driven by the PIO timings. */ -unsigned int mwdma = speed -XFER_MW_DMA_0 ; -static const unsigned int needed_pio[3 ] = { -XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 - }; -int pio = needed_pio[mwdma] -XFER_PIO_0 ; - -it8213_set_timings (ap, adev, pio,1 ); +it8213_set_timings (ap, adev,ata_mwdma_to_pio (speed),1 ); udma_enable &= ~(1 << devid); }
drivers/ata/pata_oldpiix.c +1 -8
@@ -135,14 +135,7 @@ static void oldpiix_set_piomode(struct astatic void oldpiix_set_dmamode (struct ata_port *ap,struct ata_device *adev) {/* MWDMA is driven by the PIO timings. */ - -unsigned int mwdma = adev->dma_mode -XFER_MW_DMA_0 ; -const unsigned int needed_pio[3 ] = { -XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 - }; -int pio = needed_pio[mwdma] -XFER_PIO_0 ; - -oldpiix_set_timings (ap, adev, pio,1 ); +oldpiix_set_timings (ap, adev,ata_mwdma_to_pio (adev->dma_mode),1 ); }/**
drivers/ata/pata_radisys.c +3 -9
@@ -102,18 +102,12 @@ static void radisys_set_dmamode (structstruct pci_dev *dev =to_pci_dev (ap->host->dev);u8 udma_enable; -/* MWDMA is driven by the PIO timings. */ -pci_read_config_byte (dev,0x48 , &udma_enable);if (adev->dma_mode <XFER_UDMA_0 ) { -unsigned int mwdma = adev->dma_mode -XFER_MW_DMA_0 ; -const unsigned int needed_pio[3 ] = { -XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 - }; -int pio = needed_pio[mwdma] -XFER_PIO_0 ; - -radisys_set_timings (ap, adev, pio,1 ); +/* MWDMA is driven by the PIO timings. */ +radisys_set_timings (ap, adev, +ata_mwdma_to_pio (adev->dma_mode),1 ); udma_enable &= ~(1 << adev->devno); }else {
drivers/ata/pata_rdc.c +2 -9
@@ -227,16 +227,9 @@ static void rdc_set_dmamode(struct ata_ppci_write_config_word (dev,0x54 , ideconf);pci_write_config_byte (dev,0x48 , udma_enable); - }else { + }else /* MWDMA is driven by the PIO timings. */ -unsigned int mwdma = speed -XFER_MW_DMA_0 ; -const unsigned int needed_pio[3 ] = { -XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 - }; -int pio = needed_pio[mwdma] -XFER_PIO_0 ; - -rdc_set_timings (ap, adev, pio,1 ); - } +rdc_set_timings (ap, adev,ata_mwdma_to_pio (speed),1 ); }static struct ata_port_operations rdc_pata_ops = {
include/linux/ata.h +11 -0
@@ -1012,4 +1012,15 @@ static inline int lba_48_ok(u64 block, u#define sata_pmp_gscr_rev (gscr) (((gscr)[SATA_PMP_GSCR_REV] >> 8) & 0xff)#define sata_pmp_gscr_ports (gscr) ((gscr)[SATA_PMP_GSCR_PORT_INFO] & 0xf) +/* returns PIO number matching given MWDMA mode */ +static inline u8 ata_mwdma_to_pio (u8 mwdma_mode) +{ +unsigned int mwdma = mwdma_mode -XFER_MW_DMA_0 ; +const unsigned int needed_pio[3 ] = { +XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 + }; + +return needed_pio[mwdma] -XFER_PIO_0 ; +} +#endif /* __LINUX_ATA_H__ */
Re: [PATCH 84/86] libata: add ata_mwdma_to_pio() inline helper
Hello.
Quoted 4 lines · Bartlomiej Zolnierkiewicz
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: addata_mwdma_to_pio()inline helperSigned-off-by Bartlomiej Zolnierkiewicz <[email protected]>
[...]
Quoted 6 lines
static struct
ata_port_operationsrdc_pata_ops= {
Index:b/include/linux/ata.h
===================================================================
include/linux/ata.h static inline int lba_48_ok(u64 block, u · line 1019
Quoted 8 lines
include/linux/ata.h +5
-0@@ -1012,4 +1012,15 @@ static inline int lba_48_ok(u64 block, u#define sata_pmp_gscr_rev (gscr) (((gscr)[SATA_PMP_GSCR_REV] >> 8) & 0xff)#define sata_pmp_gscr_ports (gscr) ((gscr)[SATA_PMP_GSCR_PORT_INFO] & 0xf) +/* returns PIO number matching given MWDMA mode */ +static inline u8 ata_mwdma_to_pio (u8 mwdma_mode) +{ +unsigned int mwdma = mwdma_mode -XFER_MW_DMA_0 ; +const unsigned int needed_pio[3 ] = {
'u8' would have been enough.
include/linux/ata.h static inline int lba_48_ok(u64 block, u · line 1021
Quoted 2 lines
include/linux/ata.h +2
-0+ XFER_PIO_0, XFER_PIO_3, XFER_PIO_4 + };
Er, perhaps this should be 'static' array?.. Intialization *auto* class
arrays produces some real code... Also, why not simply {0, 3, 4}?
include/linux/ata.h static inline int lba_48_ok(u64 block, u · line 1026
Quoted 5 lines
include/linux/ata.h +4
-0+ + return needed_pio[mwdma] - XFER_PIO_0; +} +#endif /* __LINUX_ATA_H__ */
MBR, Sergei
PATCH 85/86 libata: add ->init_host method
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: add ->init_host method
Add ->init_host method for re-initialization of the controller in ata_pci_device_resume().
Then teach ata_pci_sff_init_one() and host drivers about it.
--- drivers/ata/libata-core.c | 14 ++++++++++--- drivers/ata/libata-sff.c | 10 ++++++--- drivers/ata/pata_ali.c | 29 ++++++++------------------- drivers/ata/pata_amd.c | 45 +++++++++++++++++-------------------------- drivers/ata/pata_artop.c | 30 ++++++++-------------------- drivers/ata/pata_cmd640.c | 27 +++++++------------------ drivers/ata/pata_cmd64x.c | 29 +++++++-------------------- drivers/ata/pata_cs5530.c | 31 ++++++----------------------- drivers/ata/pata_hpt366.c | 30 +++++++++------------------- drivers/ata/pata_hpt3x3.c | 32 ++++++++++-------------------- drivers/ata/pata_it821x.c | 31 +++++++++++------------------ drivers/ata/pata_ninja32.c | 30 ++++++++++------------------ drivers/ata/pata_ns87415.c | 30 ++++++++-------------------- drivers/ata/pata_pdc2027x.c | 46 ++++++++++++++------------------------------ drivers/ata/pata_sl82c105.c | 29 +++++++-------------------- drivers/ata/sata_sil.c | 33 ++++++++----------------------- include/linux/libata.h | 14 ++++++++++--- 17 files changed, 173 insertions(+), 317 deletions(-)
drivers/ata/libata-core.c +11 -3
@@ -6426,9 +6426,17 @@ int ata_pci_device_resume(struct pci_devint rc; rc =ata_pci_device_do_resume (pdev); -if (rc ==0 ) -ata_host_resume (host); - return rc; +if (rc) +return rc; + +if (host->init_host) { + rc = host->init_host (&pdev->dev); +if (rc) +return rc; + } + +ata_host_resume (host); + return 0; }#endif /* CONFIG_PM */
drivers/ata/libata-sff.c +7 -3
@@ -3003,11 +3003,12 @@ out:EXPORT_SYMBOL_GPL (ata_pci_sff_activate_host);/** -* ata_pci_sff_init_one - Initialize/register PCI IDE host controller +* __ata_pci_sff_init_one - Initialize/register PCI IDE host controller * @pdev: Controller to be initialized * @ppi: array of port_info, must be enough for two ports * @sht: scsi_host_template to use when registering the host * @host_priv: host private_data +* @init_host: host initialization method (optional) * * This is a helper function which can be called from a driver's * xxx_init_one() probe function if the hardware uses traditional
@@ -3027,9 +3028,10 @@ EXPORT_SYMBOL_GPL(ata_pci_sff_activate_h* RETURNS: * Zero on success, negative on errno-based value on error. */ -int ata_pci_sff_init_one (struct pci_dev *pdev, +int __ata_pci_sff_init_one (struct pci_dev *pdev,const struct ata_port_info *const *ppi, -struct scsi_host_template *sht,void *host_priv) +struct scsi_host_template *sht,void *host_priv, +int (*init_host)(struct device *dev)) {struct device *dev = &pdev->dev;const struct ata_port_info *pi =NULL ;
@@ -3063,7 +3065,9 @@ int ata_pci_sff_init_one(struct pci_dev rc =ata_pci_sff_prepare_host (pdev, ppi, &host);if (rc) goto out; + host->private_data = host_priv; + host->init_host = init_host;pci_set_master (pdev); rc =ata_pci_sff_activate_host (host, ata_sff_interrupt, sht);
drivers/ata/pata_ali.c +9 -20
@@ -424,14 +424,15 @@ static struct ata_port_operations ali_c5/** * ali_init_chipset - chip setup function -* @pdev: PCI device of ATA controller +* @dev: device of ATA controller * * Perform the setup on the device that must be done both at boot * and at resume time. */ -static void ali_init_chipset (struct pci_dev *pdev) +static int ali_init_chipset (struct device *dev) { +struct pci_dev *pdev =to_pci_dev (dev);u8 tmp;struct pci_dev *north;
@@ -478,7 +479,9 @@ static void ali_init_chipset(struct pci_ }pci_dev_put (north);ata_pci_bmdma_clear_simplex (pdev); +return 0 ; } +/** * ali_init_one - discovery callback * @pdev: PCI device ID
@@ -574,7 +577,7 @@ static int ali_init_one(struct pci_dev * }else ppi[0 ] = &info_c5; -ali_init_chipset (pdev); +ali_init_chipset (&pdev->dev);if (ali_isa_bridge && pdev->revision >=0x20 && pdev->revision <0xC2 ) {/* Are we paired with a UDMA capable chip */
@@ -583,23 +586,9 @@ static int ali_init_one(struct pci_dev * ppi[0 ] = &info_20_udma; } -return ata_pci_sff_init_one (pdev, ppi, &ali_sht,NULL ); -} - -#ifdef CONFIG_PM -static int ali_reinit_one (struct pci_dev *pdev) -{ -struct ata_host *host =dev_get_drvdata (&pdev->dev); -int rc; - - rc =ata_pci_device_do_resume (pdev); -if (rc) -return rc; -ali_init_chipset (pdev); -ata_host_resume (host); -return 0 ; +return __ata_pci_sff_init_one (pdev, ppi, &ali_sht,NULL , + ali_init_chipset); } -#endif static const struct pci_device_id ali[] = { {PCI_VDEVICE (AL ,PCI_DEVICE_ID_AL_M5228 ), },
@@ -615,7 +604,7 @@ static struct pci_driver ali_pci_driver .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = ali_reinit_one, + .resume = ata_pci_device_resume,#endif };
drivers/ata/pata_amd.c +18 -27
71 lines not on this page · raw message
drivers/ata/pata_artop.c +9 -21
@@ -302,8 +302,10 @@ static struct ata_port_operations atp86x .prereset = atp8xx_prereset, }; -static void atp8xx_fixup (struct pci_dev *pdev) +static int atp8xx_fixup (struct device *dev) { +struct pci_dev *pdev =to_pci_dev (dev); +if (pdev->device ==0x0005 )/* BIOS may have left us in UDMA, clear it before probe */ pci_write_config_byte (pdev,0x54 ,0 );
@@ -328,6 +330,8 @@ static void atp8xx_fixup(struct pci_devpci_read_config_byte (pdev,0x4a , ®);pci_write_config_byte (pdev,0x4a , (reg & ~0x01 ) |0x80 ); } + +return 0 ; }/**
@@ -400,28 +404,12 @@ static int artop_init_one (struct pci_deBUG_ON (ppi[0 ] ==NULL ); -atp8xx_fixup (pdev); +atp8xx_fixup (&pdev->dev); -return ata_pci_sff_init_one (pdev, ppi, &artop_sht,NULL ); +return __ata_pci_sff_init_one (pdev, ppi, &artop_sht,NULL , + atp8xx_fixup); } -#ifdef CONFIG_PM -static int atp8xx_reinit_one (struct pci_dev *pdev) -{ -struct ata_host *host =dev_get_drvdata (&pdev->dev); -int rc; - - rc =ata_pci_device_do_resume (pdev); -if (rc) -return rc; - -atp8xx_fixup (pdev); - -ata_host_resume (host); -return 0 ; -} -#endif -static const struct pci_device_id artop_pci_tbl[] = { {PCI_VDEVICE (ARTOP ,0x0005 ),0 }, {PCI_VDEVICE (ARTOP ,0x0006 ),1 },
@@ -439,7 +427,7 @@ static struct pci_driver artop_pci_drive .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = atp8xx_reinit_one, + .resume = ata_pci_device_resume,#endif };
drivers/ata/pata_cmd640.c +8 -19
@@ -178,8 +178,9 @@ static struct ata_port_operations cmd640 .port_start = cmd640_port_start, }; -static void cmd640_hardware_init (struct pci_dev *pdev) +static int cmd640_hardware_init (struct device *dev) { +struct pci_dev *pdev =to_pci_dev (dev);u8 r;u8 ctrl;
@@ -205,6 +206,8 @@ static void cmd640_hardware_init(structpci_read_config_byte (pdev,ARTIM23 , &ctrl); ctrl |=0x0C ;pci_write_config_byte (pdev,ARTIM23 , ctrl); + +return 0 ; }static int cmd640_init_one (struct pci_dev *pdev,const struct pci_device_id *id)
@@ -221,25 +224,11 @@ static int cmd640_init_one(struct pci_deif (rc)return rc; -cmd640_hardware_init (pdev); - -return ata_pci_sff_init_one (pdev, ppi, &cmd640_sht,NULL ); -} - -#ifdef CONFIG_PM -static int cmd640_reinit_one (struct pci_dev *pdev) -{ -struct ata_host *host =dev_get_drvdata (&pdev->dev); -int rc; +cmd640_hardware_init (&pdev->dev); - rc =ata_pci_device_do_resume (pdev); -if (rc) -return rc; -cmd640_hardware_init (pdev); -ata_host_resume (host); -return 0 ; +return __ata_pci_sff_init_one (pdev, ppi, &cmd640_sht,NULL , + cmd640_hardware_init); } -#endif static const struct pci_device_id cmd640[] = { {PCI_VDEVICE (CMD ,0x640 ),0 },
@@ -253,7 +242,7 @@ static struct pci_driver cmd640_pci_driv .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = cmd640_reinit_one, + .resume = ata_pci_device_resume,#endif };
drivers/ata/pata_cmd64x.c +8 -21
@@ -328,8 +328,9 @@ static struct ata_port_operations cmd648 .cable_detect = cmd648_cable_detect, }; -static void cmd64x_fixup (struct pci_dev *pdev) +static int cmd64x_fixup (struct device *dev) { +struct pci_dev *pdev =to_pci_dev (dev);u8 mrdmode;pci_write_config_byte (pdev,PCI_LATENCY_TIMER ,64 );
@@ -342,6 +343,8 @@ static void cmd64x_fixup(struct pci_dev#ifdef CONFIG_PPC pci_write_config_byte (pdev,UDIDETCR0 ,0xF0 );#endif + +return 0 ; }static int cmd64x_init_one (struct pci_dev *pdev,const struct pci_device_id *id)
@@ -411,27 +414,11 @@ static int cmd64x_init_one(struct pci_de ppi[0 ] = &cmd_info[3 ]; } -cmd64x_fixup (pdev); - -return ata_pci_sff_init_one (pdev, ppi, &cmd64x_sht,NULL ); -} - -#ifdef CONFIG_PM -static int cmd64x_reinit_one (struct pci_dev *pdev) -{ -struct ata_host *host =dev_get_drvdata (&pdev->dev); -int rc; - - rc =ata_pci_device_do_resume (pdev); -if (rc) -return rc; +cmd64x_fixup (&pdev->dev); -cmd64x_fixup (pdev); - -ata_host_resume (host); -return 0 ; +return __ata_pci_sff_init_one (pdev, ppi, &cmd64x_sht,NULL , + cmd64x_fixup); } -#endif static const struct pci_device_id cmd64x[] = { {PCI_VDEVICE (CMD ,PCI_DEVICE_ID_CMD_643 ),0 },
@@ -449,7 +436,7 @@ static struct pci_driver cmd64x_pci_driv .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = cmd64x_reinit_one, + .resume = ata_pci_device_resume,#endif };
drivers/ata/pata_cs5530.c +7 -24
@@ -198,12 +198,13 @@ static int cs5530_is_palmax(void)/** * cs5530_init_chip - Chipset init +* @gendev: device * * Perform the chip initialisation work that is shared between both * setup and resume paths */ -static int cs5530_init_chip (void ) +static int cs5530_init_chip (struct device *gendev) {struct pci_dev *master_0 =NULL , *cs5530_0 =NULL , *dev =NULL ;
@@ -281,7 +282,7 @@ fail_put:pci_dev_put (master_0);if (cs5530_0)pci_dev_put (cs5530_0); -return -ENODEV ; +return -EIO ; }/**
@@ -317,35 +318,17 @@ static int cs5530_init_one(struct pci_dereturn rc;/* Chip initialisation */ -if (cs5530_init_chip ()) +if (cs5530_init_chip (NULL ))return -ENODEV ;if (cs5530_is_palmax ()) ppi[1 ] = &info_palmax_secondary;/* Now kick off ATA set up */ -return ata_pci_sff_init_one (pdev, ppi, &cs5530_sht,NULL ); +return __ata_pci_sff_init_one (pdev, ppi, &cs5530_sht,NULL , + cs5530_init_chip); } -#ifdef CONFIG_PM -static int cs5530_reinit_one (struct pci_dev *pdev) -{ -struct ata_host *host =dev_get_drvdata (&pdev->dev); -int rc; - - rc =ata_pci_device_do_resume (pdev); -if (rc) -return rc; - -/* If we fail on resume we are doomed */ -if (cs5530_init_chip ()) -return -EIO ; - -ata_host_resume (host); -return 0 ; -} -#endif /* CONFIG_PM */ -static const struct pci_device_id cs5530[] = { {PCI_VDEVICE (CYRIX ,PCI_DEVICE_ID_CYRIX_5530_IDE ), },
@@ -359,7 +342,7 @@ static struct pci_driver cs5530_pci_driv .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = cs5530_reinit_one, + .resume = ata_pci_device_resume,#endif };
drivers/ata/pata_hpt366.c +10 -20
@@ -292,15 +292,17 @@ static struct ata_port_operations hpt366/** * hpt36x_init_chipset - common chip setup -* @dev: PCI device +* @gendev: device * * Perform the chip setup work that must be done at both init and * resume time */ -static void hpt36x_init_chipset (struct pci_dev *dev) +static int hpt36x_init_chipset (struct device *gendev) { +struct pci_dev *dev =to_pci_dev (gendev);u8 drive_fast; +pci_write_config_byte (dev,PCI_CACHE_LINE_SIZE , (L1_CACHE_BYTES /4 ));pci_write_config_byte (dev,PCI_LATENCY_TIMER ,0x78 );pci_write_config_byte (dev,PCI_MIN_GNT ,0x08 );
@@ -309,6 +311,8 @@ static void hpt36x_init_chipset(struct ppci_read_config_byte (dev,0x51 , &drive_fast);if (drive_fast &0x80 )pci_write_config_byte (dev,0x51 , drive_fast & ~0x80 ); + +return 0 ; }/**
@@ -360,7 +364,7 @@ static int hpt36x_init_one(struct pci_deif (class_rev >2 )return -ENODEV ; -hpt36x_init_chipset (dev); +hpt36x_init_chipset (&dev->dev);pci_read_config_dword (dev,0x40 , ®1);
@@ -378,23 +382,9 @@ static int hpt36x_init_one(struct pci_debreak ; }/* Now kick off ATA set up */ -return ata_pci_sff_init_one (dev, ppi, &hpt36x_sht, hpriv); -} - -#ifdef CONFIG_PM -static int hpt36x_reinit_one (struct pci_dev *dev) -{ -struct ata_host *host =dev_get_drvdata (&dev->dev); -int rc; - - rc =ata_pci_device_do_resume (dev); -if (rc) -return rc; -hpt36x_init_chipset (dev); -ata_host_resume (host); -return 0 ; +return __ata_pci_sff_init_one (dev, ppi, &hpt36x_sht, hpriv, + hpt36x_init_chipset); } -#endif static const struct pci_device_id hpt36x[] = { {PCI_VDEVICE (TTI ,PCI_DEVICE_ID_TTI_HPT366 ), },
@@ -408,7 +398,7 @@ static struct pci_driver hpt36x_pci_driv .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = hpt36x_reinit_one, + .resume = ata_pci_device_resume,#endif };
drivers/ata/pata_hpt3x3.c +11 -21
@@ -156,14 +156,16 @@ static struct ata_port_operations hpt3x3/** * hpt3x3_init_chipset - chip setup -* @dev: PCI device +* @gendev: device * * Perform the setup required at boot and on resume. */ -static void hpt3x3_init_chipset (struct pci_dev *dev) +static int hpt3x3_init_chipset (struct device *gendev) { +struct pci_dev *dev =to_pci_dev (gendev);u16 cmd; +/* Initialize the board */ pci_write_config_word (dev,0x80 ,0x00 );/* Check if it is a 343 or a 363. 363 has COMMAND_MEMORY set */
@@ -172,6 +174,8 @@ static void hpt3x3_init_chipset(struct ppci_write_config_byte (dev,PCI_LATENCY_TIMER ,0xF0 ); else pci_write_config_byte(dev, PCI_LATENCY_TIMER, 0x20); + +return 0 ; }/**
@@ -204,7 +208,7 @@ static int hpt3x3_init_one(struct pci_deint i, rc;void __iomem *base; -hpt3x3_init_chipset (pdev); +hpt3x3_init_chipset (&pdev->dev);if (!printed_version++)dev_printk (KERN_DEBUG , &pdev->dev,"version " DRV_VERSION "\n" );
@@ -212,6 +216,9 @@ static int hpt3x3_init_one(struct pci_de host =ata_host_alloc_pinfo (&pdev->dev, ppi,2 );if (!host)return -ENOMEM ; + + host->init_host = hpt3x3_init_chipset; +/* acquire resources and fill host */ rc =pcim_enable_device (pdev);if (rc)
@@ -252,23 +259,6 @@ static int hpt3x3_init_one(struct pci_de IRQF_SHARED, &hpt3x3_sht); } -#ifdef CONFIG_PM -static int hpt3x3_reinit_one (struct pci_dev *dev) -{ -struct ata_host *host =dev_get_drvdata (&dev->dev); -int rc; - - rc =ata_pci_device_do_resume (dev); -if (rc) -return rc; - -hpt3x3_init_chipset (dev); - -ata_host_resume (host); -return 0 ; -} -#endif -static const struct pci_device_id hpt3x3[] = { {PCI_VDEVICE (TTI ,PCI_DEVICE_ID_TTI_HPT343 ), },
@@ -282,7 +272,7 @@ static struct pci_driver hpt3x3_pci_driv .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = hpt3x3_reinit_one, + .resume = ata_pci_device_resume,#endif };
drivers/ata/pata_it821x.c +12 -19
@@ -868,6 +868,15 @@ static void it821x_disable_raid(struct ppci_write_config_byte (pdev,PCI_LATENCY_TIMER ,0x20 ); } +static int it821x_fixup (struct device *dev) +{ +struct pci_dev *pdev =to_pci_dev (dev); + +if (pdev->vendor !=PCI_VENDOR_ID_RDC && it8212_noraid) +it821x_disable_raid (pdev); + +return 0 ; +}static int it821x_init_one (struct pci_dev *pdev,const struct pci_device_id *id) {
@@ -932,26 +941,10 @@ static int it821x_init_one(struct pci_deelse ppi[0 ] = &info_smart; } -return ata_pci_sff_init_one (pdev, ppi, &it821x_sht,NULL ); +return __ata_pci_sff_init_one (pdev, ppi, &it821x_sht,NULL , + it821x_fixup); } -#ifdef CONFIG_PM -static int it821x_reinit_one (struct pci_dev *pdev) -{ -struct ata_host *host =dev_get_drvdata (&pdev->dev); -int rc; - - rc =ata_pci_device_do_resume (pdev); -if (rc) -return rc; -/* Resume - turn raid back off if need be */ -if (it8212_noraid) -it821x_disable_raid (pdev); -ata_host_resume (host); -return rc; -} -#endif -static const struct pci_device_id it821x[] = { {PCI_VDEVICE (ITE ,PCI_DEVICE_ID_ITE_8211 ), }, {PCI_VDEVICE (ITE ,PCI_DEVICE_ID_ITE_8212 ), },
@@ -967,7 +960,7 @@ static struct pci_driver it821x_pci_driv .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = it821x_reinit_one, + .resume = ata_pci_device_resume,#endif };
drivers/ata/pata_ninja32.c +11 -19
@@ -89,8 +89,11 @@ static struct ata_port_operations ninja3 .sff_data_xfer = ata_sff_data_xfer32 }; -static void ninja32_program (void __iomem *base) +static int ninja32_program (struct device *dev) { +struct ata_host *host =dev_get_drvdata (dev); +void __iomem *base = host->iomap[0 ]; +iowrite8 (0x05 , base +0x01 );/* Enable interrupt lines */ iowrite8 (0xBE , base +0x02 );/* Burst, ?? setup */ iowrite8 (0x01 , base +0x03 );/* Unknown */
@@ -98,6 +101,8 @@ static void ninja32_program(void __iomemiowrite8 (0x8f , base +0x05 );/* Unknown */ iowrite8 (0xa4 , base +0x1c );/* Unknown */ iowrite8 (0x83 , base +0x1d );/* BMDMA control: WAIT0 */ + +return 0 ; }static int ninja32_init_one (struct pci_dev *dev,const struct pci_device_id *id)
@@ -110,6 +115,8 @@ static int ninja32_init_one(struct pci_d host =ata_host_alloc (&dev->dev,1 );if (!host)return -ENOMEM ; + + host->init_host = ninja32_program; ap = host->ports[0 ];/* Set up the PCI device */
@@ -147,28 +154,13 @@ static int ninja32_init_one(struct pci_data_sff_std_ports (&ap->ioaddr); ap->pflags =ATA_PFLAG_PIO32 |ATA_PFLAG_PIO32CHANGE ; -ninja32_program (base); +ninja32_program (&dev->dev); +/* FIXME: Should we disable them at remove ? */ return ata_host_activate (host, dev->irq, ata_sff_interrupt,IRQF_SHARED , &ninja32_sht); } -#ifdef CONFIG_PM - -static int ninja32_reinit_one (struct pci_dev *pdev) -{ -struct ata_host *host =dev_get_drvdata (&pdev->dev); -int rc; - - rc =ata_pci_device_do_resume (pdev); -if (rc) -return rc; -ninja32_program (host->iomap[0 ]); -ata_host_resume (host); -return 0 ; -} -#endif -static const struct pci_device_id ninja32[] = { {0x10FC ,0x0003 ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 ,0 }, {0x1145 ,0x8008 ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 ,0 },
@@ -186,7 +178,7 @@ static struct pci_driver ninja32_pci_dri .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = ninja32_reinit_one, + .resume = ata_pci_device_resume,#endif };
drivers/ata/pata_ns87415.c +9 -21
@@ -325,12 +325,16 @@ static struct scsi_host_template ns87415 ATA_BMDMA_SHT(DRV_NAME), }; -static void ns87415_fixup (struct pci_dev *pdev) +static int ns87415_fixup (struct device *dev) { +struct pci_dev *pdev =to_pci_dev (dev); +/* Select 512 byte sectors */ pci_write_config_byte (pdev,0x55 ,0xEE );/* Select PIO0 8bit clocking */ pci_write_config_byte (pdev,0x54 ,0xB7 ); + +return 0 ; }/**
@@ -378,9 +382,10 @@ static int ns87415_init_one (struct pci_if (rc)return rc; -ns87415_fixup (pdev); +ns87415_fixup (&pdev->dev); -return ata_pci_sff_init_one (pdev, ppi, &ns87415_sht,NULL ); +return __ata_pci_sff_init_one (pdev, ppi, &ns87415_sht,NULL , + ns87415_fixup); }static const struct pci_device_id ns87415_pci_tbl[] = {
@@ -389,23 +394,6 @@ static const struct pci_device_id ns8741 { }/* terminate list */ }; -#ifdef CONFIG_PM -static int ns87415_reinit_one (struct pci_dev *pdev) -{ -struct ata_host *host =dev_get_drvdata (&pdev->dev); -int rc; - - rc =ata_pci_device_do_resume (pdev); -if (rc) -return rc; - -ns87415_fixup (pdev); - -ata_host_resume (host); -return 0 ; -} -#endif -static struct pci_driver ns87415_pci_driver = { .name =DRV_NAME , .id_table = ns87415_pci_tbl,
@@ -413,7 +401,7 @@ static struct pci_driver ns87415_pci_dri .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = ns87415_reinit_one, + .resume = ata_pci_device_resume,#endif };
drivers/ata/pata_pdc2027x.c +15 -31
86 lines not on this page · raw message
drivers/ata/pata_sl82c105.c +8 -21
@@ -279,13 +279,16 @@ static int sl82c105_bridge_revision(strureturn bridge->revision; } -static void sl82c105_fixup (struct pci_dev *pdev) +static int sl82c105_fixup (struct device *dev) { +struct pci_dev *pdev =to_pci_dev (dev);u32 val;pci_read_config_dword (pdev,0x40 , &val); val |=CTRL_P0EN |CTRL_P0F16 |CTRL_P1F16 ;pci_write_config_dword (pdev,0x40 , val); + +return 0 ; }static int sl82c105_init_one (struct pci_dev *dev,const struct pci_device_id *id)
@@ -320,27 +323,11 @@ static int sl82c105_init_one(struct pci_else ppi[0 ] = &info_dma; -sl82c105_fixup (dev); - -return ata_pci_sff_init_one (dev, ppi, &sl82c105_sht,NULL ); -} - -#ifdef CONFIG_PM -static int sl82c105_reinit_one (struct pci_dev *pdev) -{ -struct ata_host *host =dev_get_drvdata (&pdev->dev); -int rc; - - rc =ata_pci_device_do_resume (pdev); -if (rc) -return rc; +sl82c105_fixup (&dev->dev); -sl82c105_fixup (pdev); - -ata_host_resume (host); -return 0 ; +return __ata_pci_sff_init_one (dev, ppi, &sl82c105_sht,NULL , + sl82c105_fixup); } -#endif static const struct pci_device_id sl82c105[] = { {PCI_VDEVICE (WINBOND ,PCI_DEVICE_ID_WINBOND_82C105 ), },
@@ -355,7 +342,7 @@ static struct pci_driver sl82c105_pci_dr .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = sl82c105_reinit_one, + .resume = ata_pci_device_resume,#endif };
drivers/ata/sata_sil.c +9 -24
@@ -114,9 +114,6 @@ enum { };static int sil_init_one (struct pci_dev *pdev,const struct pci_device_id *ent); -#ifdef CONFIG_PM -static int sil_pci_device_resume (struct pci_dev *pdev); -#endif static void sil_dev_config (struct ata_device *dev);static int sil_scr_read (struct ata_link *link,unsigned int sc_reg,u32 *val);static int sil_scr_write (struct ata_link *link,unsigned int sc_reg,u32 val);
@@ -169,7 +166,7 @@ static struct pci_driver sil_pci_driver .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = sil_pci_device_resume, + .resume = ata_pci_device_resume,#endif };
@@ -663,9 +660,10 @@ static void sil_dev_config(struct ata_de } } -static void sil_init_controller (struct ata_host *host) +static int sil_init_controller (struct device *dev) { -struct pci_dev *pdev =to_pci_dev (host->dev); +struct ata_host *host =dev_get_drvdata (dev); +struct pci_dev *pdev =to_pci_dev (dev);void __iomem *mmio_base = host->iomap[SIL_MMIO_BAR ];u8 cls;u32 tmp;
@@ -707,6 +705,8 @@ static void sil_init_controller(struct awritel (tmp |SIL_INTR_STEERING , mmio_base + sil_port[2 ].bmdma); } + +return 0 ; }static bool sil_broken_system_poweroff (struct pci_dev *pdev)
@@ -765,6 +765,8 @@ static int sil_init_one(struct pci_dev *if (!host)return -ENOMEM ; + host->init_host = sil_init_controller; +/* acquire resources and fill host */ rc =pcim_enable_device (pdev);if (rc)
@@ -802,30 +804,13 @@ static int sil_init_one(struct pci_dev * }/* initialize and activate */ -sil_init_controller (host); +sil_init_controller (&pdev->dev);pci_set_master (pdev);return ata_host_activate (host, pdev->irq, sil_interrupt,IRQF_SHARED , &sil_sht); } -#ifdef CONFIG_PM -static int sil_pci_device_resume (struct pci_dev *pdev) -{ -struct ata_host *host =dev_get_drvdata (&pdev->dev); -int rc; - - rc =ata_pci_device_do_resume (pdev); -if (rc) -return rc; - -sil_init_controller (host); -ata_host_resume (host); - -return 0 ; -} -#endif -static int __init sil_init (void ) {return pci_register_driver (&sil_pci_driver);
include/linux/libata.h +11 -3
@@ -526,6 +526,7 @@ struct ata_host {unsigned int n_ports;void *private_data;struct ata_port_operations *ops; +int (*init_host)(struct device *dev);unsigned long flags;#ifdef CONFIG_ATA_ACPI acpi_handle acpi_handle;
@@ -1637,9 +1638,16 @@ extern int ata_pci_sff_prepare_host(struextern int ata_pci_sff_activate_host (struct ata_host *host,irq_handler_t irq_handler,struct scsi_host_template *sht); -extern int ata_pci_sff_init_one (struct pci_dev *pdev, -const struct ata_port_info *const * ppi, -struct scsi_host_template *sht,void *host_priv); +extern int __ata_pci_sff_init_one (struct pci_dev *pdev, +const struct ata_port_info *const *ppi, +struct scsi_host_template *sht,void *host_priv, +int (*init_host)(struct device *dev)); +static inline int ata_pci_sff_init_one (struct pci_dev *pdev, +const struct ata_port_info *const *ppi, +struct scsi_host_template *sht,void *host_priv) +{ +return __ata_pci_sff_init_one (pdev, ppi, sht, host_priv,NULL ); +}#endif /* CONFIG_PCI */ /**
Re: [PATCH 85/86] libata: add ->init_host method
Quoted 5 lines · On Wed, 25 Nov 2009 18:12:40 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: add ->init_host methodAdd ->init_host method for re-initialization of the controller in
ata_pci_device_resume().
Would be much cleaner if the init_host method was in the ops stuff somewhere rather than assigned all over the place separately - because then folks forget and its not part of the inheriting.
Definitely a good thing though
PATCH 86/86 libata: add private driver field to struct ata_device
In reply to Bartlomiej ZolnierkiewiczFrom: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: add private driver field to struct ata_device
This brings struct ata_device in-line with struct ata_{port,host}.
--- include/linux/libata.h | 1 + 1 file changed, 1 insertion(+)
include/linux/libata.h +1 -0
@@ -585,6 +585,7 @@ struct ata_device {unsigned int horkage;/* List of broken features */ unsigned long flags;/* ATA_DFLAG_xxx */ struct scsi_device *sdev;/* attached SCSI device */ +void *private_data;#ifdef CONFIG_ATA_ACPI acpi_handle acpi_handle;union acpi_object *gtf_cache;
Re: [PATCH 86/86] libata: add private driver field to struct ata_device
Quoted 4 lines · On Wed, 25 Nov 2009 18:12:48 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: add private driver field to structata_deviceThis brings struct
ata_devicein-line with struct ata_{port,host}.
Do we need it for anything yet - whoever first needs it can add it, otherwise its just waste.
Re: [PATCH 86/86] libata: add private driver field to struct ata_device
Quoted 10 lines · Alan Cox
Quoted 4 lines · On Wed, 25 Nov 2009 18:12:48 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: add private driver field to structata_deviceThis brings struct
ata_devicein-line with struct ata_{port,host}.Do we need it for anything yet - whoever first needs it can add it, otherwise its just waste.
There is a new driver using it (to be posted later) and it makes libata API more coherent for driver developers..
--
Bartlomiej Zolnierkiewicz
Re: [PATCH 86/86] libata: add private driver field to struct ata_device
Quoted 7 lines · On Wed, 25 Nov 2009 19:02:44 +0100 Bartlomiej Zolnierkiewicz…
Quoted 6 lines · Alan Cox
Quoted 3 lines · On Wed, 25 Nov 2009 18:12:48 +0100 Bartlomiej Zolnierkiewicz…
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: add private driver field to structata_device
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
This brings struct
ata_devicein-line with struct ata_{port,host}.Do we need it for anything yet - whoever first needs it can add it, otherwise its just waste.
There is a new driver using it (to be posted later) and it makes libata API more coherent for driver developers..
Ok by me
Re: [PATCH 86/86] libata: add private driver field to struct ata_device
In reply to Bartlomiej ZolnierkiewiczQuoted 15 lines · Bartlomiej Zolnierkiewicz
From: Bartlomiej Zolnierkiewicz<[email protected]>
Subject: [PATCH] libata: add private driver field to structata_deviceThis brings struct
ata_devicein-line with struct ata_{port,host}.Signed-off-by Bartlomiej Zolnierkiewicz<[email protected]>--- include/linux/libata.h | 1 + 1 file changed, 1 insertion(+)Index:
b/include/linux/libata.h
===================================================================
include/linux/libata.h struct ata_device { · line 591
Quoted 7 lines
include/linux/libata.h +1
-0@@ -585,6 +585,7 @@ struct ata_device {unsigned int horkage;/* List of broken features */ unsigned long flags;/* ATA_DFLAG_xxx */ struct scsi_device *sdev;/* attached SCSI device */ +void *private_data;#ifdef CONFIG_ATA_ACPI acpi_handle acpi_handle;union acpi_object *gtf_cache;
I'm fine with this, and would like to merge this sooner rather than later.
However, BIG FAT WARNING: you must take special care to be sure you don't leak as devices appear and disappear, etc. IOW, watch your object lifetimes carefully. Object lifetime was the reason this was not added until now.
Re: [PATCH 86/86] libata: add private driver field to struct ata_device
Quoted 26 lines · Jeff Garzik
Quoted 15 lines · Bartlomiej Zolnierkiewicz
From: Bartlomiej Zolnierkiewicz<[email protected]>
Subject: [PATCH] libata: add private driver field to structata_deviceThis brings struct
ata_devicein-line with struct ata_{port,host}.Signed-off-by Bartlomiej Zolnierkiewicz<[email protected]>--- include/linux/libata.h | 1 + 1 file changed, 1 insertion(+)Index:
b/include/linux/libata.h
===================================================================include/linux/libata.h struct ata_device { · line 591
Quoted 7 lines
include/linux/libata.h +1
-0@@ -585,6 +585,7 @@ struct ata_device {unsigned int horkage;/* List of broken features */ unsigned long flags;/* ATA_DFLAG_xxx */ struct scsi_device *sdev;/* attached SCSI device */ +void *private_data;#ifdef CONFIG_ATA_ACPI acpi_handle acpi_handle;union acpi_object *gtf_cache;I'm fine with this, and would like to merge this sooner rather than later.
Quoted 4 lines
However, BIG FAT WARNING: you must take special care to be sure you don't leak as devices appear and disappear, etc. IOW, watch your object lifetimes carefully. Object lifetime was the reason this was not added until now.
It should be fine for now as the only user is pata_ep93xx and it gets it right. Though it would definitely be nice to see the underlying issue (which is the lack of dynamic allocation for struct ata_device objects) fixed one day in libata.
--
Bartlomiej Zolnierkiewicz
Jeff Garzik
AppliedRe: [PATCH 86/86] libata: add private driver field to struct ata_device
In reply to Bartlomiej ZolnierkiewiczQuoted 15 lines · Bartlomiej Zolnierkiewicz
From: Bartlomiej Zolnierkiewicz<[email protected]>
Subject: [PATCH] libata: add private driver field to structata_deviceThis brings struct
ata_devicein-line with struct ata_{port,host}.Signed-off-by Bartlomiej Zolnierkiewicz<[email protected]>--- include/linux/libata.h | 1 + 1 file changed, 1 insertion(+)Index:
b/include/linux/libata.h
===================================================================
include/linux/libata.h struct ata_device { · line 591
Quoted 7 lines
include/linux/libata.h +1
-0@@ -585,6 +585,7 @@ struct ata_device {unsigned int horkage;/* List of broken features */ unsigned long flags;/* ATA_DFLAG_xxx */ struct scsi_device *sdev;/* attached SCSI device */ +void *private_data;#ifdef CONFIG_ATA_ACPI acpi_handle acpi_handle;union acpi_object *gtf_cache;
applied
Quoted 4 lines · Bartlomiej Zolnierkiewicz
I've been going through PATA drivers for the last few days to make sure that we offer similar level of hardware support in the new PATA drivers as with the old IDE subsystem and the following patchset is the end result of said audit.
Thanks!
Quoted 8 lines
- add 32-bit PIO support for more controllers
( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520, pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x, pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415, pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000, pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105, pata_sis, pata_triflex& pata_via )
This should be all in one patch.
I'll let the comments from Alan and others trickle in before applying...
Quoted 7 lines
- add ->init_host method for abstracting host specific controller initialization and then use it to cleanup Power Managment code resulting in over 100 LOC gone
(
pata_ali,pata_amd,pata_artop,pata_cmd640,pata_cmd64x,pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32, pata_ns87415, pata_pdc2027x & sata_sil )
hmmmm.... will reserve comment until I review it thoroughly, but I am a bit reluctant to move away from the current struct-driver style driver init/setup model.
Jeff
Quoted 10 lines · Jeff Garzik
Quoted 4 lines · Bartlomiej Zolnierkiewicz
I've been going through PATA drivers for the last few days to make sure that we offer similar level of hardware support in the new PATA drivers as with the old IDE subsystem and the following patchset is the end result of said audit.
Thanks!
Quoted 2 lines
- add 32-bit PIO support for more controllers
Quoted 8 lines
Quoted 6 lines
( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520, pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x, pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415, pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000, pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105, pata_sis, pata_triflex& pata_via )This should be all in one patch.
For review & testing purposes it is better do it this way, I can merge individual patches easily later if desirable.
Quoted 1 line
I'll let the comments from Alan and others trickle in before applying...
See comment above.
Quoted 11 lines
Quoted 7 lines
- add ->init_host method for abstracting host specific controller initialization and then use it to cleanup Power Managment code resulting in over 100 LOC gone
(
pata_ali,pata_amd,pata_artop,pata_cmd640,pata_cmd64x,pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32, pata_ns87415, pata_pdc2027x & sata_sil )hmmmm.... will reserve comment until I review it thoroughly, but I am a bit reluctant to move away from the current struct-driver style driver init/setup model.
This change is not moving away from it. On the contrary -- it enhances the current model by adding another possibility of doing things as the new ->init_host method is completely optional.
--
Bartlomiej Zolnierkiewicz
Summary would be lots of really good stuff and review.
Quoted 3 lines
hmmmm.... will reserve comment until I review it thoroughly, but I am a bit reluctant to move away from the current struct-driver style driver init/setup model.
I think the model is right - I'd prefer it to be in the driver structs somewhere but the basic point that init and resume often do the same job is a very sound one.
Quoted 46 lines · Bartlomiej Zolnierkiewicz
Hi,
I've been going through PATA drivers for the last few days to make sure that we offer similar level of hardware support in the new PATA drivers as with the old IDE subsystem and the following patchset is the end result of said audit.
Inside:
- many bugfixes
( ata_piix, pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_hpt3x3, pata_it8213, pata_legacy, pata_ns87415, pata_sis, pata_radisys, pata_rz1000& pata_via )- add Power Management support for more controllers
( pata_artop, pata_pdc2027x, pata_sl82c105 )- add 32-bit PIO support for more controllers
( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520, pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x, pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415, pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000, pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105, pata_sis, pata_triflex& pata_via )- fix QDI65x0 support in
pata_legacydriver sopata_qdidriver can be finally removed- remove
pata_qdiandpata_winbonddrivers resulting in 600 LOC gone(affected hardware is fully supported by
pata_legacydriver now)- unify code for programming PIO and MWDMA timings for 'PIIX-like' controllers resulting in 200 LOC gone
(
ata_piix,pata_efar,pata_it8213,pata_oldpiix, pata_radisys&
pata_rdc)- add ->init_host method for abstracting host specific controller initialization and then use it to cleanup Power Managment code resulting in over 100 LOC gone
Quoted 5 lines
( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x, pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32, pata_ns87415, pata_pdc2027x& sata_sil )- misc fixes and cleanups
What are your plans for 2.6.33?
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
However, bug fixes and the like should definitely be in 2.6.33. ->init_host is definitely 2.6.34 material. Some of the other stuff could go either way.
Jeff
Quoted 47 lines · Jeff Garzik
Quoted 46 lines · Bartlomiej Zolnierkiewicz
Hi,
I've been going through PATA drivers for the last few days to make sure that we offer similar level of hardware support in the new PATA drivers as with the old IDE subsystem and the following patchset is the end result of said audit.
Inside:
- many bugfixes
( ata_piix, pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_hpt3x3, pata_it8213, pata_legacy, pata_ns87415, pata_sis, pata_radisys, pata_rz1000& pata_via )- add Power Management support for more controllers
( pata_artop, pata_pdc2027x, pata_sl82c105 )- add 32-bit PIO support for more controllers
( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520, pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x, pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415, pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000, pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105, pata_sis, pata_triflex& pata_via )- fix QDI65x0 support in
pata_legacydriver sopata_qdidriver can be finally removed- remove
pata_qdiandpata_winbonddrivers resulting in 600 LOC gone(affected hardware is fully supported by
pata_legacydriver now)- unify code for programming PIO and MWDMA timings for 'PIIX-like' controllers resulting in 200 LOC gone
(
ata_piix,pata_efar,pata_it8213,pata_oldpiix, pata_radisys&
pata_rdc)- add ->init_host method for abstracting host specific controller initialization and then use it to cleanup Power Managment code resulting in over 100 LOC gone
Quoted 7 lines
Quoted 5 lines
( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x, pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32, pata_ns87415, pata_pdc2027x& sata_sil )- misc fixes and cleanups
What are your plans for 2.6.33?
All past patches have been posted for review and have review issues addressed already so right now I'm all busy with working on future patches.
Quoted 6 lines
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
However, bug fixes and the like should definitely be in 2.6.33. ->init_host is definitely 2.6.34 material. Some of the other stuff could go either way.
If you would like to apply some of my patches to 2.6.33 you are more than welcome to do it. I can even prepare separate git tree with specific changes to make it easier for you once you tell me which changes you would like to see in it.
--
Bartlomiej Zolnierkiewicz
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Quoted 3 lines · Jeff Garzik
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Quoted 8 lines
Quoted 3 lines
However, bug fixes and the like should definitely be in 2.6.33. ->init_host is definitely 2.6.34 material. Some of the other stuff could go either way.
If you would like to apply some of my patches to 2.6.33 you are more than welcome to do it. I can even prepare separate git tree with specific changes to make it easier for you once you tell me which changes you would like to see in it.
OK, great.
Can you prepare a patchset containing only fixes? Comment-only changes are acceptable too. Trivial changes too, if they are extremely trivial :)
Include nothing that adds features, removes or unifies drivers, etc.
Please do it in standard kernel submit form, which is either
(a) repost the patches (yes, again) being submitted for 2.6.33, or
(b) a standard git pull request, which includes shortlog, diffstat, and all-in-one diff.
Jeff
Quoted 14 lines · Jeff Garzik
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Quoted 3 lines · Jeff Garzik
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Quoted 8 lines
Quoted 3 lines
However, bug fixes and the like should definitely be in 2.6.33. ->init_host is definitely 2.6.34 material. Some of the other stuff could go either way.
If you would like to apply some of my patches to 2.6.33 you are more than welcome to do it. I can even prepare separate git tree with specific changes to make it easier for you once you tell me which changes you would like to see in it.
Quoted 6 lines
OK, great.
Can you prepare a patchset containing only fixes? Comment-only changes are acceptable too. Trivial changes too, if they are extremely trivial :)
Include nothing that adds features, removes or unifies drivers, etc.
Since this is pretty high-level description and some changes fall into many categories at once (i.e. addition of proper PCI Power Management handling could be considered both as a fix and as a feature) I prepared a rather conservative set of changes (which means that unfortunately it misses many enhancements available in my tree):
Quoted 4 lines
Please do it in standard kernel submit form, which is either
(a) repost the patches (yes, again) being submitted for 2.6.33, or
(b) a standard git pull request, which includes shortlog, diffstat, and all-in-one diff.
Thank you for the detailed explanation of the standard kernel submit form (I wonder how would I know this otherwise :) but the thing is that at the current moment I'm not submitting anything to the upstream.
That's it. While this may sound strange to some people it turns out that in practice it is much less hassle for me personally to keep some of trees outside of the (sometimes greatly overrated) upstream.
If knowing the above you still would like to include the aforementioned set of changes in your libata-dev tree they are at kernel.org now.
The following changes since commit 184b8405d5d3e8510163d66efbac99d351faba2e:
Bartlomiej Zolnierkiewicz (1):
libata: add private driver field to struct ata_device
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git atang-for-2.6.33
Bartlomiej Zolnierkiewicz (28):
ide-pci-generic: build fix
ata_piix: fix MWDMA handling on PIIX3
pata_efar: fix wrong PIO timings being programmed
pata_efar: fix wrong MWDMA timings being programmed
pata_efar: MWDMA0 is unsupported
pata_cmd640: document known issues
pata_cs5520: remove dead VDMA support
pata_cypress: document known issues
pata_hpt3x2n: fix overclocked MWDMA0 timing
pata_hpt3x3: Power Management fix
pata_it8213: fix UDMA handling
pata_it8213: fix wrong PIO timings being programmed
pata_it8213: fix PIO2 underclocking
pata_it8213: fix wrong MWDMA timings being programmed
pata_it8213: fix it8213_pre_reset() documentation
pata_it8213: MWDMA0 is unsupported
pata_legacy: fix QDI6580DP support
pata_legacy: fix access to control register for QDI6580
pata_legacy: add pointers to QDI65x0 documentation
pata_marvell: fix marvell_pre_reset() documentation
pata_ns87415: Power Management fix
pata_oldpiix: MWDMA0 is unsupported
pata_pdc202xx_old: document known issues
pata_radisys: fix UDMA handling
pata_rdc: MWDMA0 is unsupported
pata_rz1000: Power Management fix
pata_sis: Power Management fix
pata_via: clear UDMA transfer mode bit for PIO and MWDMA
drivers/ata/Kconfig | 14 ++++++++++++-- drivers/ata/ata_piix.c | 6 +++--- drivers/ata/pata_cs5520.c | 39 +-------------------------------------- drivers/ata/pata_efar.c | 9 +++++---- drivers/ata/pata_hpt3x2n.c | 3 +-- drivers/ata/pata_hpt3x3.c | 11 ++++++++++- drivers/ata/pata_it8213.c | 27 +++++++++++++-------------- drivers/ata/pata_legacy.c | 14 +++++++++++--- drivers/ata/pata_marvell.c | 2 +- drivers/ata/pata_ns87415.c | 32 +++++++++++++++++++++++++++----- drivers/ata/pata_oldpiix.c | 2 +- drivers/ata/pata_radisys.c | 4 ++-- drivers/ata/pata_rdc.c | 2 +- drivers/ata/pata_rz1000.c | 11 ++++++++++- drivers/ata/pata_sis.c | 21 +++++++++++++++++++-- drivers/ata/pata_via.c | 19 +++++++++++++------ drivers/ide/ide-pci-generic.c | 2 +- 17 files changed, 131 insertions(+), 87 deletions(-)
drivers/ata/Kconfig +12 -2
@@ -287,8 +287,11 @@ config PATA_CMD640_PCI depends on PCI && EXPERIMENTAL help This option enables support for the CMD640 PCI IDE - interface chip. Only the primary channel is currently - supported. + interface chip. + + Known issues: + - only the primary channel is currently supported + - only the PCI chip interface is currently supported If unsure, say N.
@@ -344,6 +347,9 @@ config PATA_CYPRESS This option enables support for the Cypress/Contaq CY82C693 chipset found in some Alpha systems + Known issues: + - only the primary channel is currently supported + If unsure, say N. config PATA_EFAR
@@ -588,6 +594,10 @@ config PATA_PDC_OLD This option enables support for the Promise 20246, 20262, 20263, 20265 and 20267 adapters. + Known issues: + - UDMA transfers fail mysteriously on some chipsets + - ATAPI DMA is unsupported currently + If unsure, say N. config PATA_QDI
drivers/ata/ata_piix.c +3 -3
@@ -869,10 +869,10 @@ static void do_pata_set_dmamode(struct ata_port *ap, struct ata_device *adev, in (timings[pio][1 ] <<8 ); } -if (ap->udma_mask) { +if (ap->udma_mask) udma_enable &= ~(1 << devid); -pci_write_config_word (dev, master_port, master_data); - } + +pci_write_config_word (dev, master_port, master_data); }/* Don't scribble on 0x48 if the controller does not support UDMA */ if (ap->udma_mask)
drivers/ata/pata_cs5520.c +1 -38
@@ -90,48 +90,12 @@ static void cs5520_set_timings(struct ata_port *ap, struct ata_device *adev, int }/** -* cs5520_enable_dma - turn on DMA bits -* -* Turn on the DMA bits for this disk. Needed because the BIOS probably -* has not done the work for us. Belongs in the core SATA code. -*/ - -static void cs5520_enable_dma (struct ata_port *ap,struct ata_device *adev) -{ -/* Set the DMA enable/disable flag */ -u8 reg =ioread8 (ap->ioaddr.bmdma_addr +0x02 ); - reg |=1 <<(adev->devno +5 ); -iowrite8 (reg, ap->ioaddr.bmdma_addr +0x02 ); -} - -/** -* cs5520_set_dmamode - program DMA timings -* @ap: ATA port -* @adev: ATA device -* -* Program the DMA mode timings for the controller according to the pio -* clocking table. Note that this device sets the DMA timings to PIO -* mode values. This may seem bizarre but the 5520 architecture talks -* PIO mode to the disk and DMA mode to the controller so the underlying -* transfers are PIO timed. -*/ - -static void cs5520_set_dmamode (struct ata_port *ap,struct ata_device *adev) -{ -static const int dma_xlate[3 ] = {XFER_PIO_0 ,XFER_PIO_3 ,XFER_PIO_4 }; -cs5520_set_timings (ap, adev, dma_xlate[adev->dma_mode]); -cs5520_enable_dma (ap, adev); -} - -/** * cs5520_set_piomode - program PIO timings * @ap: ATA port * @adev: ATA device * * Program the PIO mode timings for the controller according to the pio -* clocking table. We know pio_mode will equal dma_mode because of the -* CS5520 architecture. At least once we turned DMA on and wrote a -* mode setter. +* clocking table. */ static void cs5520_set_piomode (struct ata_port *ap,struct ata_device *adev)
@@ -149,7 +113,6 @@ static struct ata_port_operations cs5520_port_ops = { .qc_prep = ata_sff_dumb_qc_prep, .cable_detect = ata_cable_40wire, .set_piomode = cs5520_set_piomode, - .set_dmamode = cs5520_set_dmamode, };static int __devinit cs5520_init_one (struct pci_dev *pdev,const struct pci_device_id *id)
drivers/ata/pata_efar.c +5 -4
@@ -2,6 +2,7 @@* pata_efar.c - EFAR PIIX clone controller driver * * (C) 2005 Red Hat +* (C) 2009 Bartlomiej Zolnierkiewicz * * Some parts based on ata_piix.c by Jeff Garzik and others. *
@@ -118,12 +119,12 @@ static void efar_set_piomode (struct ata_port *ap, struct ata_device *adev)int shift =4 * ap->port_no;u8 slave_data; - idetm_data &=0xCC0F ; + idetm_data &=0xFF0F ; idetm_data |= (control <<4 );/* Slave timing in separate register */ pci_read_config_byte (dev,0x44 , &slave_data); - slave_data &=0x0F << shift; + slave_data &= ap->port_no ?0x0F :0xF0 ; slave_data |= ((timings[pio][0 ] <<2 ) | timings[pio][1 ]) << shift;pci_write_config_byte (dev,0x44 , slave_data); }
@@ -200,7 +201,7 @@ static void efar_set_dmamode (struct ata_port *ap, struct ata_device *adev) master_data &=0xFF4F ;/* Mask out IORDY|TIME1|DMAONLY */ master_data |= control <<4 ;pci_read_config_byte (dev,0x44 , &slave_data); - slave_data &= (0x0F +0xE1 * ap->port_no); + slave_data &= ap->port_no ?0x0F :0xF0 ;/* Load the matching timing */ slave_data |= ((timings[pio][0 ] <<2 ) | timings[pio][1 ]) << (ap->port_no ?4 :0 );pci_write_config_byte (dev,0x44 , slave_data);
@@ -251,7 +252,7 @@ static int efar_init_one (struct pci_dev *pdev, const struct pci_device_id *ent)static const struct ata_port_info info = { .flags =ATA_FLAG_SLAVE_POSS , .pio_mask =ATA_PIO4 , - .mwdma_mask =ATA_MWDMA2 , + .mwdma_mask =ATA_MWDMA12_ONLY , .udma_mask =ATA_UDMA4 , .port_ops = &efar_ops, };
drivers/ata/pata_hpt3x2n.c +1 -2
@@ -80,14 +80,13 @@ static struct hpt_clock hpt3x2n_clocks[] = { { XFER_MW_DMA_2, 0x2c829c62 }, { XFER_MW_DMA_1, 0x2c829c66 }, - { XFER_MW_DMA_0, 0x2c829d2c }, + { XFER_MW_DMA_0, 0x2c829d2e }, { XFER_PIO_4, 0x0c829c62 }, { XFER_PIO_3, 0x0c829c84 }, { XFER_PIO_2, 0x0c829ca6 }, { XFER_PIO_1, 0x0d029d26 }, { XFER_PIO_0, 0x0d029d5e }, - { 0, 0x0d029d5e } };/**
drivers/ata/pata_hpt3x3.c +10 -1
@@ -255,8 +255,17 @@ static int hpt3x3_init_one(struct pci_dev *pdev, const struct pci_device_id *id)#ifdef CONFIG_PM static int hpt3x3_reinit_one (struct pci_dev *dev) { +struct ata_host *host =dev_get_drvdata (&dev->dev); +int rc; + + rc =ata_pci_device_do_resume (dev); +if (rc) +return rc; +hpt3x3_init_chipset (dev); -return ata_pci_device_resume (dev); + +ata_host_resume (host); +return 0 ; }#endif
drivers/ata/pata_it8213.c +13 -14
@@ -22,7 +22,7 @@#define DRV_VERSION "0.0.3"/** -* it8213_pre_reset - check for 40/80 pin +* it8213_pre_reset - probe begin * @link: link * @deadline: deadline jiffies for the operation *
@@ -92,18 +92,17 @@ static void it8213_set_piomode (struct ata_port *ap, struct ata_device *adev) { 2, 1 }, { 2, 3 }, }; -if (pio >2 ) - control |=1 ;/* TIME1 enable */ +if (pio >1 ) + control |=1 ;/* TIME */ if (ata_pio_need_iordy (adev))/* PIO 3/4 require IORDY */ - control |=2 ;/* IORDY enable */ + control |=2 ;/* IE */ /* Bit 2 is set for ATAPI on the IT8213 - reverse of ICH/PIIX */ if (adev->class !=ATA_DEV_ATA ) - control |=4 ; + control |=4 ;/* PPE */ pci_read_config_word (dev, idetm_port, &idetm_data); -/* Enable PPE, IE and TIME as appropriate */ - +/* Set PPE, IE, and TIME as appropriate */ if (adev->devno ==0 ) { idetm_data &=0xCCF0 ; idetm_data |= control;
@@ -112,17 +111,17 @@ static void it8213_set_piomode (struct ata_port *ap, struct ata_device *adev) }else {u8 slave_data; - idetm_data &=0xCC0F ; + idetm_data &=0xFF0F ; idetm_data |= (control <<4 );/* Slave timing in separate register */ pci_read_config_byte (dev,0x44 , &slave_data); slave_data &=0xF0 ; - slave_data |= ((timings[pio][0 ] <<2 ) | timings[pio][1 ]) <<4 ; + slave_data |= (timings[pio][0 ] <<2 ) | timings[pio][1 ];pci_write_config_byte (dev,0x44 , slave_data); } - idetm_data |=0x4000 ;/* Ensure SITRE is enabled */ + idetm_data |=0x4000 ;/* Ensure SITRE is set */ pci_write_config_word (dev, idetm_port, idetm_data); }
@@ -173,10 +172,10 @@ static void it8213_set_dmamode (struct ata_port *ap, struct ata_device *adev) udma_enable |= (1 << devid); -/* Load the UDMA mode number */ +/* Load the UDMA cycle time */ pci_read_config_word (dev,0x4A , &udma_timing); udma_timing &= ~(3 << (4 * devid)); - udma_timing |= (udma &3 ) << (4 * devid); + udma_timing |= u_speed << (4 * devid);pci_write_config_word (dev,0x4A , udma_timing);/* Load the clock selection */
@@ -211,7 +210,7 @@ static void it8213_set_dmamode (struct ata_port *ap, struct ata_device *adev) master_data &=0xFF4F ;/* Mask out IORDY|TIME1|DMAONLY */ master_data |= control <<4 ;pci_read_config_byte (dev,0x44 , &slave_data); - slave_data &= (0x0F +0xE1 * ap->port_no); + slave_data &=0xF0 ;/* Load the matching timing */ slave_data |= ((timings[pio][0 ] <<2 ) | timings[pio][1 ]) << (ap->port_no ?4 :0 );pci_write_config_byte (dev,0x44 , slave_data);
@@ -263,7 +262,7 @@ static int it8213_init_one (struct pci_dev *pdev, const struct pci_device_id *enstatic const struct ata_port_info info = { .flags =ATA_FLAG_SLAVE_POSS , .pio_mask =ATA_PIO4 , - .mwdma_mask =ATA_MWDMA2 , + .mwdma_mask =ATA_MWDMA12_ONLY , .udma_mask =ATA_UDMA4 ,/* FIXME: want UDMA 100? */ .port_ops = &it8213_ops, };
drivers/ata/pata_legacy.c +11 -3
@@ -25,6 +25,13 @@* http://www.ryston.cz/petr/vlb/pdc20230b.html * http://www.ryston.cz/petr/vlb/pdc20230c.html * http://www.ryston.cz/petr/vlb/pdc20630.html +* QDI65x0: +* http://www.ryston.cz/petr/vlb/qd6500.html +* http://www.ryston.cz/petr/vlb/qd6580.html +* +* QDI65x0 probe code based on drivers/ide/legacy/qd65xx.c +* Rewritten from the work of Colten Edwards <[email protected]> by +* Samuel Thibault <[email protected]> * * Unsupported but docs exist: * Appian/Adaptec AIC25VL01/Cirrus Logic PD7220
@@ -35,7 +42,7 @@* the MPIIX where the tuning is PCI side but the IDE is "ISA side". * * Specific support is included for the ht6560a/ht6560b/opti82c611a/ -* opti82c465mv/promise 20230c/20630/winbond83759A +* opti82c465mv/promise 20230c/20630/qdi65x0/winbond83759A * * Use the autospeed and pio_mask options with: * Appian ADI/2 aka CLPD7220 or AIC25VL01.
@@ -672,7 +679,7 @@ static void qdi6580dp_set_piomode(struct ata_port *ap, struct ata_device *adev)outb (timing, ld_qdi->timing +2 * ap->port_no);/* Clear the FIFO */ if (adev->class !=ATA_DEV_ATA ) -outb (0x5F , ld_qdi->timing +3 ); +outb (0x5F , (ld_qdi->timing &0xFFF0 ) +3 ); }/**
@@ -707,7 +714,7 @@ static void qdi6580_set_piomode(struct ata_port *ap, struct ata_device *adev)outb (timing, ld_qdi->timing +2 * adev->devno);/* Clear the FIFO */ if (adev->class !=ATA_DEV_ATA ) -outb (0x5F , ld_qdi->timing +3 ); +outb (0x5F , (ld_qdi->timing &0xFFF0 ) +3 ); }/**
@@ -787,6 +794,7 @@ static struct ata_port_operations qdi6580_port_ops = {static struct ata_port_operations qdi6580dp_port_ops = { .inherits = &legacy_base_port_ops, .set_piomode = qdi6580dp_set_piomode, + .qc_issue = qdi_qc_issue, .sff_data_xfer = vlb32_data_xfer, };
drivers/ata/pata_marvell.c +1 -1
@@ -58,7 +58,7 @@ static int marvell_pata_active(struct pci_dev *pdev) }/** -* marvell_pre_reset - check for 40/80 pin +* marvell_pre_reset - probe begin * @link: link * @deadline: deadline jiffies for the operation *
drivers/ata/pata_ns87415.c +27 -5
@@ -325,6 +325,13 @@ static struct scsi_host_template ns87415_sht = { ATA_BMDMA_SHT(DRV_NAME), }; +static void ns87415_fixup (struct pci_dev *pdev) +{ +/* Select 512 byte sectors */ +pci_write_config_byte (pdev,0x55 ,0xEE ); +/* Select PIO0 8bit clocking */ +pci_write_config_byte (pdev,0x54 ,0xB7 ); +}/** * ns87415_init_one - Register 87415 ATA PCI device with kernel services
@@ -371,10 +378,8 @@ static int ns87415_init_one (struct pci_dev *pdev, const struct pci_device_id *eif (rc)return rc; -/* Select 512 byte sectors */ -pci_write_config_byte (pdev,0x55 ,0xEE ); -/* Select PIO0 8bit clocking */ -pci_write_config_byte (pdev,0x54 ,0xB7 ); +ns87415_fixup (pdev); +return ata_pci_sff_init_one (pdev, ppi, &ns87415_sht,NULL ); }
@@ -384,6 +389,23 @@ static const struct pci_device_id ns87415_pci_tbl[] = { { }/* terminate list */ }; +#ifdef CONFIG_PM +static int ns87415_reinit_one (struct pci_dev *pdev) +{ +struct ata_host *host =dev_get_drvdata (&pdev->dev); +int rc; + + rc =ata_pci_device_do_resume (pdev); +if (rc) +return rc; + +ns87415_fixup (pdev); + +ata_host_resume (host); +return 0 ; +} +#endif +static struct pci_driver ns87415_pci_driver = { .name =DRV_NAME , .id_table = ns87415_pci_tbl,
@@ -391,7 +413,7 @@ static struct pci_driver ns87415_pci_driver = { .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = ata_pci_device_resume, + .resume = ns87415_reinit_one,#endif };
drivers/ata/pata_oldpiix.c +1 -1
@@ -239,7 +239,7 @@ static int oldpiix_init_one (struct pci_dev *pdev, const struct pci_device_id *estatic const struct ata_port_info info = { .flags =ATA_FLAG_SLAVE_POSS , .pio_mask =ATA_PIO4 , - .mwdma_mask =ATA_MWDMA2 , + .mwdma_mask =ATA_MWDMA12_ONLY , .port_ops = &oldpiix_pata_ops, };const struct ata_port_info *ppi[] = { &info,NULL };
drivers/ata/pata_radisys.c +2 -2
@@ -139,9 +139,9 @@ static void radisys_set_dmamode (struct ata_port *ap, struct ata_device *adev)pci_read_config_byte (dev,0x4A , &udma_mode);if (adev->xfer_mode ==XFER_UDMA_2 ) - udma_mode &= ~ (1 << adev->devno); + udma_mode &= ~(2 << (adev->devno *4 ));else /* UDMA 4 */ - udma_mode |= (1 << adev->devno); + udma_mode |= (2 << (adev->devno *4 ));pci_write_config_byte (dev,0x4A , udma_mode);
drivers/ata/pata_rdc.c +1 -1
@@ -284,7 +284,7 @@ static struct ata_port_info rdc_port_info = { .flags = ATA_FLAG_SLAVE_POSS, .pio_mask = ATA_PIO4, - .mwdma_mask = ATA_MWDMA2, + .mwdma_mask = ATA_MWDMA12_ONLY, .udma_mask = ATA_UDMA5, .port_ops = &rdc_pata_ops, };
drivers/ata/pata_rz1000.c +10 -1
@@ -105,11 +105,20 @@ static int rz1000_init_one (struct pci_dev *pdev, const struct pci_device_id *en#ifdef CONFIG_PM static int rz1000_reinit_one (struct pci_dev *pdev) { +struct ata_host *host =dev_get_drvdata (&pdev->dev); +int rc; + + rc =ata_pci_device_do_resume (pdev); +if (rc) +return rc; +/* If this fails on resume (which is a "cant happen" case), we must stop as any progress risks data loss */ if (rz1000_fifo_disable (pdev))panic ("rz1000 fifo" ); -return ata_pci_device_resume (pdev); + +ata_host_resume (host); +return 0 ; }#endif
drivers/ata/pata_sis.c +19 -2
@@ -2,7 +2,7 @@* pata_sis.c - SiS ATA driver * * (C) 2005 Red Hat -* (C) 2007 Bartlomiej Zolnierkiewicz +* (C) 2007,2009 Bartlomiej Zolnierkiewicz * * Based upon linux/drivers/ide/pci/sis5513.c * Copyright (C) 1999-2000 Andre Hedrick <[email protected]>
@@ -876,6 +876,23 @@ static int sis_init_one (struct pci_dev *pdev, const struct pci_device_id *ent)return ata_pci_sff_init_one (pdev, ppi, &sis_sht, chipset); } +#ifdef CONFIG_PM +static int sis_reinit_one (struct pci_dev *pdev) +{ +struct ata_host *host =dev_get_drvdata (&pdev->dev); +int rc; + + rc =ata_pci_device_do_resume (pdev); +if (rc) +return rc; + +sis_fixup (pdev, host->private_data); + +ata_host_resume (host); +return 0 ; +} +#endif +static const struct pci_device_id sis_pci_tbl[] = { {PCI_VDEVICE (SI ,0x5513 ), },/* SiS 5513 */ {PCI_VDEVICE (SI ,0x5518 ), },/* SiS 5518 */
@@ -891,7 +908,7 @@ static struct pci_driver sis_pci_driver = { .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = ata_pci_device_resume, + .resume = sis_reinit_one,#endif };
drivers/ata/pata_via.c +13 -6
@@ -303,14 +303,21 @@ static void via_do_set_mode(struct ata_port *ap, struct ata_device *adev, int mo }/* Set UDMA unless device is not UDMA capable */ -if (udma_type && t.udma) { -u8 cable80_status; +if (udma_type) { +u8 udma_etc; -/* Get 80-wire cable detection bit */ -pci_read_config_byte (pdev,0x50 + offset, &cable80_status); - cable80_status &=0x10 ; +pci_read_config_byte (pdev,0x50 + offset, &udma_etc); -pci_write_config_byte (pdev,0x50 + offset, ut | cable80_status); +/* clear transfer mode bit */ + udma_etc &= ~0x20 ; + +if (t.udma) { +/* preserve 80-wire cable detection bit */ + udma_etc &=0x10 ; + udma_etc |= ut; + } + +pci_write_config_byte (pdev,0x50 + offset, udma_etc); } }
drivers/ide/ide-pci-generic.c +1 -1
@@ -165,7 +165,7 @@ static const struct pci_device_id generic_pci_tbl[] = { { PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_1), 4 }, { PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_2), 4 }, { PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_3), 4 }, - { PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_5) 4 }, + { PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_5), 4 }, { PCI_VDEVICE(NETCELL, PCI_DEVICE_ID_REVOLUTION), 6 },/* * Must come last. If you add entries adjust
Quoted 28 lines · Bartlomiej Zolnierkiewicz
Quoted 14 lines · Jeff Garzik
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Quoted 3 lines · Jeff Garzik
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Quoted 8 lines
Quoted 3 lines
However, bug fixes and the like should definitely be in 2.6.33. ->init_host is definitely 2.6.34 material. Some of the other stuff could go either way.
If you would like to apply some of my patches to 2.6.33 you are more than welcome to do it. I can even prepare separate git tree with specific changes to make it easier for you once you tell me which changes you would like to see in it.
Quoted 6 lines
OK, great.
Can you prepare a patchset containing only fixes? Comment-only changes are acceptable too. Trivial changes too, if they are extremely trivial :)
Include nothing that adds features, removes or unifies drivers, etc.
Since this is pretty high-level description and some changes fall into many categories at once (i.e. addition of proper PCI Power Management handling could be considered both as a fix and as a feature) I prepared a rather conservative set of changes (which means that unfortunately it misses many enhancements available in my tree):
Quoted 8 lines
Quoted 4 lines
Please do it in standard kernel submit form, which is either
(a) repost the patches (yes, again) being submitted for 2.6.33, or
(b) a standard git pull request, which includes shortlog, diffstat, and all-in-one diff.Thank you for the detailed explanation of the standard kernel submit form (I wonder how would I know this otherwise :) but the thing is that at the current moment I'm not submitting anything to the upstream.
Ok, that explains my confusion, then. I had thought you intended to get this stuff upstream, and into users' hands.
Quoted 6 lines
That's it. While this may sound strange to some people it turns out that in practice it is much less hassle for me personally to keep some of trees outside of the (sometimes greatly overrated) upstream.
If knowing the above you still would like to include the aforementioned set of changes in your libata-dev tree they are at kernel.org now.
I will go through this batch and cherry-pick. The build fix is already in my tree. Existing kernel practice (and previous comments) indicate that lists of known issues do not belong in Kconfig. Will take a look at the other stuff...
Thanks,
Jeff
Quoted 34 lines · Jeff Garzik
Quoted 33 lines · Bartlomiej Zolnierkiewicz
Quoted 14 lines · Jeff Garzik
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Quoted 3 lines · Jeff Garzik
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Quoted 8 lines
Quoted 3 lines
However, bug fixes and the like should definitely be in 2.6.33. ->init_host is definitely 2.6.34 material. Some of the other stuff could go either way.
If you would like to apply some of my patches to 2.6.33 you are more than welcome to do it. I can even prepare separate git tree with specific changes to make it easier for you once you tell me which changes you would like to see in it.
Quoted 6 lines
OK, great.
Can you prepare a patchset containing only fixes? Comment-only changes are acceptable too. Trivial changes too, if they are extremely trivial :)
Include nothing that adds features, removes or unifies drivers, etc.
Since this is pretty high-level description and some changes fall into many categories at once (i.e. addition of proper PCI Power Management handling could be considered both as a fix and as a feature) I prepared a rather conservative set of changes (which means that unfortunately it misses many enhancements available in my tree):
Quoted 4 lines
Please do it in standard kernel submit form, which is either
(a) repost the patches (yes, again) being submitted for 2.6.33, or
(b) a standard git pull request, which includes shortlog, diffstat, and all-in-one diff.
Quoted 6 lines
Quoted 3 lines
Thank you for the detailed explanation of the standard kernel submit form (I wonder how would I know this otherwise :) but the thing is that at the current moment I'm not submitting anything to the upstream.
Ok, that explains my confusion, then. I had thought you intended to get this stuff upstream, and into users' hands.
Interesting argument but the vast majority of users use distribution kernels which are not upstream and I doubt that any self-respecting distribution would miss such amount of fixes.
The rest can easily use my tree which follows upstream closely and can be obtained using a single line git command.
Quoted 11 lines
Quoted 6 lines
That's it. While this may sound strange to some people it turns out that in practice it is much less hassle for me personally to keep some of trees outside of the (sometimes greatly overrated) upstream.
If knowing the above you still would like to include the aforementioned set of changes in your libata-dev tree they are at kernel.org now.
I will go through this batch and cherry-pick. The build fix is already in my tree. Existing kernel practice (and previous comments) indicate that lists of known issues do not belong in
Kconfig. Will take a look at the other stuff...
Well, you were aware that they were not dropped so you could have easily told me that you specifically don't want this patches in the for-2.6.33 tree..
--
Bartlomiej Zolnierkiewicz
Quoted 39 lines · Bartlomiej Zolnierkiewicz
Quoted 38 lines · Jeff Garzik
Quoted 36 lines · Bartlomiej Zolnierkiewicz
Quoted 14 lines · Jeff Garzik
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Quoted 3 lines · Jeff Garzik
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Quoted 8 lines
Quoted 3 lines
However, bug fixes and the like should definitely be in 2.6.33. ->init_host is definitely 2.6.34 material. Some of the other stuff could go either way.
If you would like to apply some of my patches to 2.6.33 you are more than welcome to do it. I can even prepare separate git tree with specific changes to make it easier for you once you tell me which changes you would like to see in it.
Quoted 6 lines
OK, great.
Can you prepare a patchset containing only fixes? Comment-only changes are acceptable too. Trivial changes too, if they are extremely trivial :)
Include nothing that adds features, removes or unifies drivers, etc.
Since this is pretty high-level description and some changes fall into many categories at once (i.e. addition of proper PCI Power Management handling could be considered both as a fix and as a feature) I prepared a rather conservative set of changes (which means that unfortunately it misses many enhancements available in my tree):
Quoted 4 lines
Please do it in standard kernel submit form, which is either
(a) repost the patches (yes, again) being submitted for 2.6.33, or
(b) a standard git pull request, which includes shortlog, diffstat, and all-in-one diff.Thank you for the detailed explanation of the standard kernel submit form (I wonder how would I know this otherwise :) but the thing is that at the current moment I'm not submitting anything to the upstream.
Quoted 6 lines
Quoted 2 lines
Ok, that explains my confusion, then. I had thought you intended to get this stuff upstream, and into users' hands.
Interesting argument but the vast majority of users use distribution kernels which are not upstream and I doubt that any self-respecting distribution would miss such amount of fixes.
Interesting argument, but applied across 1000+ developers this is clearly an unscalable development model for distributions. Thus, patches go upstream, and are then distributed widely, to eliminate massive amounts of duplicated work across distributions.
You are essentially implying that each distribution must
- discover your tree
- look through the mailing list to figure out why each of ~80 changes are not upstream
- individually make a decision on each of ~80 changes
- actively track your tree for updates, repeating this process over and over again
Talk about a lot of unwanted work pushed upon OTHER people, all because you choose to avoid the standard upstream development process.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
That's it. While this may sound strange to some people it turns out that in practice it is much less hassle for me personally to keep some of trees outside of the (sometimes greatly overrated) upstream.
If knowing the above you still would like to include the aforementioned set of changes in your libata-dev tree they are at kernel.org now.
Quoted 7 lines
Quoted 4 lines
I will go through this batch and cherry-pick. The build fix is already in my tree. Existing kernel practice (and previous comments) indicate that lists of known issues do not belong in
Kconfig. Will take a look at the other stuff...Well, you were aware that they were not dropped so you could have easily told me that you specifically don't want this patches in the for-2.6.33 tree..
At the time you built atang-2.6.33, you were aware that those Kconfig changes were not wanted -at all-.
You tell others "I think that there were enough hints in my mail already" then fail to apply this logic to yourself.
Jeff
Quoted 43 lines · Jeff Garzik
Quoted 42 lines · Bartlomiej Zolnierkiewicz
Quoted 40 lines · Jeff Garzik
Quoted 28 lines · Bartlomiej Zolnierkiewicz
Quoted 14 lines · Jeff Garzik
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Quoted 3 lines · Jeff Garzik
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Quoted 8 lines
Quoted 3 lines
However, bug fixes and the like should definitely be in 2.6.33. ->init_host is definitely 2.6.34 material. Some of the other stuff could go either way.
If you would like to apply some of my patches to 2.6.33 you are more than welcome to do it. I can even prepare separate git tree with specific changes to make it easier for you once you tell me which changes you would like to see in it.
Quoted 6 lines
OK, great.
Can you prepare a patchset containing only fixes? Comment-only changes are acceptable too. Trivial changes too, if they are extremely trivial :)
Include nothing that adds features, removes or unifies drivers, etc.
Since this is pretty high-level description and some changes fall into many categories at once (i.e. addition of proper PCI Power Management handling could be considered both as a fix and as a feature) I prepared a rather conservative set of changes (which means that unfortunately it misses many enhancements available in my tree):
Quoted 8 lines
Quoted 4 lines
Please do it in standard kernel submit form, which is either
(a) repost the patches (yes, again) being submitted for 2.6.33, or
(b) a standard git pull request, which includes shortlog, diffstat, and all-in-one diff.Thank you for the detailed explanation of the standard kernel submit form (I wonder how would I know this otherwise :) but the thing is that at the current moment I'm not submitting anything to the upstream.
Ok, that explains my confusion, then. I had thought you intended to get this stuff upstream, and into users' hands.
Quoted 6 lines
Quoted 3 lines
Interesting argument but the vast majority of users use distribution kernels which are not upstream and I doubt that any self-respecting distribution would miss such amount of fixes.
Interesting argument, but applied across 1000+ developers this is clearly an unscalable development model for distributions. Thus,
Interesting that you have brought distributions' convenience before non-distribution developers' one.
Quoted 11 lines
patches go upstream, and are then distributed widely, to eliminate massive amounts of duplicated work across distributions.
You are essentially implying that each distribution must
- discover your tree
- look through the mailing list to figure out why each of ~80 changes are not upstream
- individually make a decision on each of ~80 changes
- actively track your tree for updates, repeating this process over and over again
Not really.
I'm only saying that the upstream is so much hassle to deal with it that it is up to people wanting to see my changes upstream to do the work on integrating them upstream if they want to see them in upstream faster.
Fair enough?
Quoted 2 lines
Talk about a lot of unwanted work pushed upon OTHER people, all because you choose to avoid the standard upstream development process.
I'm not forcing any work on anybody and I'm not avoiding the standard process. I just find other things to have higher priority than pushing these changes upstream right now.
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
Quoted 6 lines
That's it. While this may sound strange to some people it turns out that in practice it is much less hassle for me personally to keep some of trees outside of the (sometimes greatly overrated) upstream.
If knowing the above you still would like to include the aforementioned set of changes in your libata-dev tree they are at kernel.org now.
I will go through this batch and cherry-pick. The build fix is already in my tree. Existing kernel practice (and previous comments) indicate that lists of known issues do not belong in
Kconfig. Will take a look at the other stuff...
Quoted 5 lines
Quoted 2 lines
Well, you were aware that they were not dropped so you could have easily told me that you specifically don't want this patches in the for-2.6.33 tree..
At the time you built atang-2.6.33, you were aware that those
Kconfigchanges were not wanted -at all-.
Why should I remember/care/worry about such details?
Quoted 2 lines
You tell others "I think that there were enough hints in my mail already" then fail to apply this logic to yourself.
You forgot that it was you who have asked me to prepare this tree to enhance your tree.
--
Bartlomiej Zolnierkiewicz
Quoted 48 lines · Bartlomiej Zolnierkiewicz
Quoted 47 lines · Jeff Garzik
Quoted 45 lines · Bartlomiej Zolnierkiewicz
Quoted 34 lines · Jeff Garzik
Quoted 33 lines · Bartlomiej Zolnierkiewicz
Quoted 14 lines · Jeff Garzik
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Quoted 3 lines · Jeff Garzik
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Quoted 8 lines
Quoted 3 lines
However, bug fixes and the like should definitely be in 2.6.33. ->init_host is definitely 2.6.34 material. Some of the other stuff could go either way.
If you would like to apply some of my patches to 2.6.33 you are more than welcome to do it. I can even prepare separate git tree with specific changes to make it easier for you once you tell me which changes you would like to see in it.
Quoted 6 lines
OK, great.
Can you prepare a patchset containing only fixes? Comment-only changes are acceptable too. Trivial changes too, if they are extremely trivial :)
Include nothing that adds features, removes or unifies drivers, etc.
Since this is pretty high-level description and some changes fall into many categories at once (i.e. addition of proper PCI Power Management handling could be considered both as a fix and as a feature) I prepared a rather conservative set of changes (which means that unfortunately it misses many enhancements available in my tree):
Quoted 4 lines
Please do it in standard kernel submit form, which is either
(a) repost the patches (yes, again) being submitted for 2.6.33, or
(b) a standard git pull request, which includes shortlog, diffstat, and all-in-one diff.Quoted 6 lines
Quoted 3 lines
Thank you for the detailed explanation of the standard kernel submit form (I wonder how would I know this otherwise :) but the thing is that at the current moment I'm not submitting anything to the upstream.
Ok, that explains my confusion, then. I had thought you intended to get this stuff upstream, and into users' hands.
Interesting argument but the vast majority of users use distribution kernels which are not upstream and I doubt that any self-respecting distribution would miss such amount of fixes.
Quoted 5 lines
Quoted 2 lines
Interesting argument, but applied across 1000+ developers this is clearly an unscalable development model for distributions. Thus,
Interesting that you have brought distributions' convenience before non-distribution developers' one.
uhwhu? You brought up distributions.
Quoted 12 lines
Quoted 11 lines
patches go upstream, and are then distributed widely, to eliminate massive amounts of duplicated work across distributions.
You are essentially implying that each distribution must
- discover your tree
- look through the mailing list to figure out why each of ~80 changes are not upstream
- individually make a decision on each of ~80 changes
- actively track your tree for updates, repeating this process over and over again
Quoted 7 lines
Not really.
I'm only saying that the upstream is so much hassle to deal with it that it is up to people wanting to see my changes upstream to do the work on integrating them upstream if they want to see them in upstream faster.
Fair enough?
I respect your opinion, sure. And respect that your time is your own. And appreciate you spending that time to batch together some patches.
But it is simple logic that a non-standard distribution method for your changes implies a self-imposed limited distribution, with possibly useful fixes and changes not getting into the hands of users that can use them.
That's your choice -- but it surprised me, is all. Usually developers are more eager to get their changes into wide distribution, because that benefits the most Linux users.
If you fail to send changes upstream, most people will assume that you do not consider your changes "ready" for users, "ready" for wide distribution and use. Because that is the common practice for nearly all other Linux kernel developers in all subsystems.
Jeff
Quoted 48 lines · Bartlomiej Zolnierkiewicz
Quoted 47 lines · Jeff Garzik
Quoted 45 lines · Bartlomiej Zolnierkiewicz
Quoted 34 lines · Jeff Garzik
Quoted 33 lines · Bartlomiej Zolnierkiewicz
Quoted 14 lines · Jeff Garzik
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Quoted 3 lines · Jeff Garzik
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Quoted 8 lines
Quoted 3 lines
However, bug fixes and the like should definitely be in 2.6.33. ->init_host is definitely 2.6.34 material. Some of the other stuff could go either way.
If you would like to apply some of my patches to 2.6.33 you are more than welcome to do it. I can even prepare separate git tree with specific changes to make it easier for you once you tell me which changes you would like to see in it.
Quoted 6 lines
OK, great.
Can you prepare a patchset containing only fixes? Comment-only changes are acceptable too. Trivial changes too, if they are extremely trivial :)
Include nothing that adds features, removes or unifies drivers, etc.
Since this is pretty high-level description and some changes fall into many categories at once (i.e. addition of proper PCI Power Management handling could be considered both as a fix and as a feature) I prepared a rather conservative set of changes (which means that unfortunately it misses many enhancements available in my tree):
Quoted 4 lines
Please do it in standard kernel submit form, which is either
(a) repost the patches (yes, again) being submitted for 2.6.33, or
(b) a standard git pull request, which includes shortlog, diffstat, and all-in-one diff.Quoted 6 lines
Quoted 3 lines
Thank you for the detailed explanation of the standard kernel submit form (I wonder how would I know this otherwise :) but the thing is that at the current moment I'm not submitting anything to the upstream.
Ok, that explains my confusion, then. I had thought you intended to get this stuff upstream, and into users' hands.
Interesting argument but the vast majority of users use distribution kernels which are not upstream and I doubt that any self-respecting distribution would miss such amount of fixes.
Quoted 5 lines
Quoted 2 lines
Interesting argument, but applied across 1000+ developers this is clearly an unscalable development model for distributions. Thus,
Interesting that you have brought distributions' convenience before non-distribution developers' one.
and you are leaving those of us who use kernel.org out in the cold (forcing all non-distribution users to go through all the work that Jeff described)
I'm not sure who you see as benifiting from this approach.
David Lang
Quoted 53 lines · On Saturday 12 December 2009 03:02:43 am [email protected] wrote:
Quoted 51 lines · Bartlomiej Zolnierkiewicz
Quoted 49 lines · Jeff Garzik
Quoted 39 lines · Bartlomiej Zolnierkiewicz
Quoted 38 lines · Jeff Garzik
Quoted 36 lines · Bartlomiej Zolnierkiewicz
Quoted 14 lines · Jeff Garzik
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Quoted 3 lines · Jeff Garzik
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Quoted 8 lines
Quoted 3 lines
However, bug fixes and the like should definitely be in 2.6.33. ->init_host is definitely 2.6.34 material. Some of the other stuff could go either way.
If you would like to apply some of my patches to 2.6.33 you are more than welcome to do it. I can even prepare separate git tree with specific changes to make it easier for you once you tell me which changes you would like to see in it.
Quoted 6 lines
OK, great.
Can you prepare a patchset containing only fixes? Comment-only changes are acceptable too. Trivial changes too, if they are extremely trivial :)
Include nothing that adds features, removes or unifies drivers, etc.
Since this is pretty high-level description and some changes fall into many categories at once (i.e. addition of proper PCI Power Management handling could be considered both as a fix and as a feature) I prepared a rather conservative set of changes (which means that unfortunately it misses many enhancements available in my tree):
Quoted 4 lines
Please do it in standard kernel submit form, which is either
(a) repost the patches (yes, again) being submitted for 2.6.33, or
(b) a standard git pull request, which includes shortlog, diffstat, and all-in-one diff.Thank you for the detailed explanation of the standard kernel submit form (I wonder how would I know this otherwise :) but the thing is that at the current moment I'm not submitting anything to the upstream.
Quoted 6 lines
Quoted 2 lines
Ok, that explains my confusion, then. I had thought you intended to get this stuff upstream, and into users' hands.
Interesting argument but the vast majority of users use distribution kernels which are not upstream and I doubt that any self-respecting distribution would miss such amount of fixes.
Interesting argument, but applied across 1000+ developers this is clearly an unscalable development model for distributions. Thus,
Quoted 6 lines
Quoted 2 lines
Interesting that you have brought distributions' convenience before non-distribution developers' one.
and you are leaving those of us who use kernel.org out in the cold (forcing all non-distribution users to go through all the work that Jeff described)
[ ..and you believed it? ;) ]
Quoted 1 line
I'm not sure who you see as benifiting from this approach.
I'm not the maintainer of the affected code (according to MAINTAINERS at least PATA code is unmaintained and to add more confusion it has been in such state forever despite numerous claims of said code being the 'official' one ) so I think that you are barking at the wrong tree here..
Moreover the claim of forcing people to do the work was completely ridiculous (BTW all the changes happen in my own time) since I did/do a lot to make review/merge easier for people:
- My tree is based on top of libata tree and stays up-to-date with it.
- All changes have been posted to linux-ide and linux-kernel, and they had review concerns addressed already (there was only one real issue, Alan has noticed that scc_pata change is unnecessary).
- I'm OK with providing additional branches with only selected changes to ease the merging process.
--
Bartlomiej Zolnierkiewicz
Jeff Garzik
AppliedAlan,
Can you sanity check me on these?
Quoted 2 lines
Bartlomiej Zolnierkiewicz (28):
ide-pci-generic: build fix
ACK but skipped -- already applied myself
Quoted 1 line
ata_piix: fix MWDMA handling on PIIX3
applied
Quoted 1 line
pata_efar: fix wrong PIO timings being programmed
applied
Quoted 1 line
pata_efar: fix wrong MWDMA timings being programmed
applied
Quoted 1 line
pata_efar: MWDMA0 is unsupported
skipped, pending discussion (just sent email)
Quoted 1 line
pata_cmd640: document known issues
rejected, for reasons already explained
Quoted 1 line
pata_cs5520: remove dead VDMA support
applied
Quoted 1 line
pata_cypress: document known issues
rejected, for reasons already explained
Quoted 1 line
pata_hpt3x2n: fix overclocked MWDMA0 timing
skipped, pending discussion (just sent email)
Quoted 1 line
pata_hpt3x3: Power Management fix
applied, on a hope and a prayer (did not see this posted to mailing list?). It looks correct to me.
Quoted 1 line
pata_it8213: fix UDMA handling
applied
Quoted 1 line
pata_it8213: fix wrong PIO timings being programmed
applied
Quoted 1 line
pata_it8213: fix PIO2 underclocking
applied
Quoted 1 line
pata_it8213: fix wrong MWDMA timings being programmed
applied
Quoted 1 line
pata_it8213: fix it8213_pre_reset() documentation
applied
Quoted 1 line
pata_it8213: MWDMA0 is unsupported
skipped, pending discussion (just sent email)
Quoted 1 line
pata_legacy: fix QDI6580DP support
applied
Quoted 1 line
pata_legacy: fix access to control register for QDI6580
applied
Quoted 1 line
pata_legacy: add pointers to QDI65x0 documentation
applied. I did not think the file path issue raised was important enough to warrant patch rejection.
Quoted 1 line
pata_marvell: fixmarvell_pre_reset()documentation
applied
Quoted 1 line
pata_ns87415: Power Management fix
applied
Quoted 1 line
pata_oldpiix: MWDMA0 is unsupported
skipped -- Alan, Sergey, comments?
Quoted 1 line
pata_pdc202xx_old: document known issues
rejected, for reasons already explained
Quoted 1 line
pata_radisys: fix UDMA handling
applied
Quoted 1 line
pata_rdc: MWDMA0 is unsupported
skipped -- Alan, Sergey, comments?
Quoted 1 line
pata_rz1000: Power Management fix
applied
Quoted 1 line
pata_sis: Power Management fix
applied
Quoted 1 line
pata_via: clear UDMA transfer mode bit for PIO and MWDMA
applied -- even though Alan's comment was correct. It is standard kernel practice to place cosmetic changes into their own patches, because it is standard kernel practice to break up logically distinct changes.
Quoted 3 lines · Jeff Garzik
Quoted 1 line
pata_efar: MWDMA0 is unsupportedskipped, pending discussion (just sent email)
The discussion was there, you were not especially interested
(http://lkml.org/lkml/2009/11/26/343).
Quoted 3 lines
Quoted 1 line
pata_hpt3x2n: fix overclocked MWDMA0 timingskipped, pending discussion (just sent email)
ditto (http://lkml.org/lkml/2009/11/27/257).
There were no complains so I'm pretty sure Sergei was fine with it.
Quoted 4 lines
Quoted 1 line
pata_hpt3x3: Power Management fixapplied, on a hope and a prayer (did not see this posted to mailing list?). It looks correct to me.
I prefer sticking to technical facts. ;)
Patch was posted to both mailing lists: http://lkml.org/lkml/2009/11/25/321
Quoted 6 lines
Quoted 1 line
pata_via: clear UDMA transfer mode bit for PIO and MWDMAapplied -- even though Alan's comment was correct. It is standard kernel practice to place cosmetic changes into their own patches, because it is standard kernel practice to break up logically distinct changes.
We are talking about:
pata_via.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-)
patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change is clearly documented in the patch description.
Do people really wonder why I find upstream to be too much hassle to deal with?
--
Bartlomiej Zolnierkiewicz
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Quoted 3 lines · Jeff Garzik
Quoted 1 line
pata_efar: MWDMA0 is unsupportedskipped, pending discussion (just sent email)
The discussion was there, you were not especially interested
(http://lkml.org/lkml/2009/11/26/343).
I reviewed the discussion before adding an email to that thread.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
pata_hpt3x2n: fix overclocked MWDMA0 timingskipped, pending discussion (just sent email)
ditto (http://lkml.org/lkml/2009/11/27/257).
I reviewed the discussion before adding an email to that thread.
Quoted 1 line
There were no complains so I'm pretty sure Sergei was fine with it.
It was unclear, hence I sent email for clarification.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
pata_hpt3x3: Power Management fixapplied, on a hope and a prayer (did not see this posted to mailing list?). It looks correct to me.
I prefer sticking to technical facts. ;)
Patch was posted to both mailing lists: http://lkml.org/lkml/2009/11/25/321
Whoops, I indeed missed this one.
Quoted 12 lines
Quoted 6 lines
Quoted 1 line
pata_via: clear UDMA transfer mode bit for PIO and MWDMAapplied -- even though Alan's comment was correct. It is standard kernel practice to place cosmetic changes into their own patches, because it is standard kernel practice to break up logically distinct changes.
We are talking about:
pata_via.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-)
Quoted 6 lines
patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change is clearly documented in the patch description.
Do people really wonder why I find upstream to be too much hassle to deal with?
The thousand other kernel developers seem to be able to split up their patches, separating out cosmetic changes from functional ones. It has clear engineering benefits, and has been standard practice for a decade or more.
Why is it such an imposition for your patches to look like everyone else's? And by "everyone", I mean all other kernel developers, not just other ATA developers.
You seem to consider standard kernel practice a hassle. Separating out cosmetic changes is not only a libata practice, it is the norm for the entire kernel.
Jeff
Bartlomiej Zolnierkiewicz
Acked-by James BottomleyQuoted 24 lines · Jeff Garzik
Quoted 12 lines
Quoted 6 lines
Quoted 1 line
pata_via: clear UDMA transfer mode bit for PIO and MWDMAapplied -- even though Alan's comment was correct. It is standard kernel practice to place cosmetic changes into their own patches, because it is standard kernel practice to break up logically distinct changes.
We are talking about:
pata_via.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-)Quoted 6 lines
patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change is clearly documented in the patch description.
Do people really wonder why I find upstream to be too much hassle to deal with?
The thousand other kernel developers seem to be able to split up their patches, separating out cosmetic changes from functional ones. It has clear engineering benefits, and has been standard practice for a decade or more.
Quoted 7 lines
Why is it such an imposition for your patches to look like everyone else's? And by "everyone", I mean all other kernel developers, not just other ATA developers.
You seem to consider standard kernel practice a hassle. Separating out cosmetic changes is not only a libata practice, it is the norm for the entire kernel.
Indeed.
Quoted 1 line
From
94be9a58d7e683ac3c1df1858a17f09ebade8da0Mon Sep 17 00:00:00 2001
From: Jeff Garzik <[email protected]>
Date: Fri, 16 Jan 2009 10:17:09 -0500
Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
for SAS drivers.
Caught by Ke Wei (and team?) at Marvell.
Also, move the ata_scsi_ioctl export to libata-scsi.c, as that seems to be the general trend.
--- drivers/ata/libata-core.c | 1 - drivers/ata/libata-scsi.c | 17 +++++++++++++---- drivers/scsi/ipr.c | 2 +- drivers/scsi/libsas/sas_scsi_host.c | 2 +- include/linux/libata.h | 2 ++ 5 files changed, 17 insertions(+), 7 deletions(-)
drivers/ata/libata-core.c +0 -1
@@ -6638,7 +6638,6 @@ EXPORT_SYMBOL_GPL(ata_dev_pair);EXPORT_SYMBOL_GPL (ata_port_disable);EXPORT_SYMBOL_GPL (ata_ratelimit);EXPORT_SYMBOL_GPL (ata_wait_register); -EXPORT_SYMBOL_GPL (ata_scsi_ioctl);EXPORT_SYMBOL_GPL (ata_scsi_queuecmd);EXPORT_SYMBOL_GPL (ata_scsi_slave_config);EXPORT_SYMBOL_GPL (ata_scsi_slave_destroy);
drivers/ata/libata-scsi.c +13 -4
@@ -423,9 +423,9 @@ int ata_std_bios_param(struct scsi_device *sdev, struct block_device *bdev,* RETURNS: * Zero on success, negative errno on error. */ -static int ata_get_identity (struct scsi_device *sdev,void __user *arg) +static int ata_get_identity (struct ata_port *ap,struct scsi_device *sdev, +void __user *arg) { -struct ata_port *ap =ata_shost_to_port (sdev->host);struct ata_device *dev =ata_scsi_find_dev (ap, sdev);u16 __user *dst = arg;char buf[40 ];
@@ -645,7 +645,8 @@ int ata_task_ioctl(struct scsi_device *scsidev, void __user *arg)return rc; } -int ata_scsi_ioctl (struct scsi_device *scsidev,int cmd,void __user *arg) +int ata_sas_scsi_ioctl (struct ata_port *ap,struct scsi_device *scsidev, +int cmd,void __user *arg) {int val = -EINVAL , rc = -EINVAL ;
@@ -663,7 +664,7 @@ int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)return 0 ;case HDIO_GET_IDENTITY : -return ata_get_identity (scsidev, arg); +return ata_get_identity (ap, scsidev, arg);case HDIO_DRIVE_CMD :if (!capable (CAP_SYS_ADMIN ) || !capable (CAP_SYS_RAWIO ))
@@ -682,6 +683,14 @@ int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)return rc; } +EXPORT_SYMBOL_GPL (ata_sas_scsi_ioctl); + +int ata_scsi_ioctl (struct scsi_device *scsidev,int cmd,void __user *arg) +{ +return ata_sas_scsi_ioctl (ata_shost_to_port (scsidev->host), + scsidev, cmd, arg); +} +EXPORT_SYMBOL_GPL (ata_scsi_ioctl);/** * ata_scsi_qc_new - acquire new ata_queued_cmd reference
drivers/scsi/ipr.c +1 -1
@@ -4912,7 +4912,7 @@ static int ipr_ioctl(struct scsi_device *sdev, int cmd, void __user *arg)if (res &&ipr_is_gata (res)) {if (cmd ==HDIO_GET_IDENTITY )return -ENOTTY ; -return ata_scsi_ioctl (sdev, cmd, arg); +return ata_sas_scsi_ioctl (res->sata_port->ap, sdev, cmd, arg); }return -EINVAL ;
drivers/scsi/libsas/sas_scsi_host.c +1 -1
@@ -717,7 +717,7 @@ int sas_ioctl(struct scsi_device *sdev, int cmd, void __user *arg)struct domain_device *dev =sdev_to_domain_dev (sdev);if (dev_is_sata (dev)) -return ata_scsi_ioctl (sdev, cmd, arg); +return ata_sas_scsi_ioctl (dev->sata_dev.ap, sdev, cmd, arg);return -EINVAL ; }
include/linux/libata.h +2 -0
@@ -927,6 +927,8 @@ extern void ata_host_init(struct ata_host *, struct device *,extern int ata_scsi_detect (struct scsi_host_template *sht);extern int ata_scsi_ioctl (struct scsi_device *dev,int cmd,void __user *arg);extern int ata_scsi_queuecmd (struct scsi_cmnd *cmd,void (*done)(struct scsi_cmnd *)); +extern int ata_sas_scsi_ioctl (struct ata_port *ap,struct scsi_device *dev, +int cmd,void __user *arg);extern void ata_sas_port_destroy (struct ata_port *);extern struct ata_port *ata_sas_port_alloc (struct ata_host *,struct ata_port_info *,struct Scsi_Host *);
Signature · 6 lines
1.6.4.2 -- Bartlomiej Zolnierkiewicz
Quoted 42 lines · Bartlomiej Zolnierkiewicz
Quoted 24 lines · Jeff Garzik
Quoted 12 lines
Quoted 6 lines
Quoted 1 line
pata_via: clear UDMA transfer mode bit for PIO and MWDMAapplied -- even though Alan's comment was correct. It is standard kernel practice to place cosmetic changes into their own patches, because it is standard kernel practice to break up logically distinct changes.
We are talking about:
pata_via.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-)Quoted 6 lines
patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change is clearly documented in the patch description.
Do people really wonder why I find upstream to be too much hassle to deal with?
The thousand other kernel developers seem to be able to split up their patches, separating out cosmetic changes from functional ones. It has clear engineering benefits, and has been standard practice for a decade or more.
Quoted 7 lines
Why is it such an imposition for your patches to look like everyone else's? And by "everyone", I mean all other kernel developers, not just other ATA developers.
You seem to consider standard kernel practice a hassle. Separating out cosmetic changes is not only a libata practice, it is the norm for the entire kernel.
Indeed.
From
94be9a58d7e683ac3c1df1858a17f09ebade8da0Mon Sep 17 00:00:00 2001
From: Jeff Garzik<[email protected]>
Date: Fri, 16 Jan 2009 10:17:09 -0500
Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
for SAS drivers.
Quoted 7 lines
Caught by Ke Wei (and team?) at Marvell.
Also, move the
ata_scsi_ioctlexport tolibata-scsi.c, as that seems to be the general trend.Acked-by James Bottomley<[email protected]>Signed-off-by Jeff Garzik<[email protected]>
If your point, by posting this patch, is that it includes a ton of gratuitous cosmetic changes, you misread the patch.
ata_scsi_ioctl() remains in existence; only the callers need to use the new SAS-related ioctl function were updated. The remainder continued to use ata_scsi_ioctl().
Jeff
Quoted 51 lines · Jeff Garzik
Quoted 42 lines · Bartlomiej Zolnierkiewicz
Quoted 24 lines · Jeff Garzik
Quoted 12 lines
Quoted 6 lines
Quoted 1 line
pata_via: clear UDMA transfer mode bit for PIO and MWDMAapplied -- even though Alan's comment was correct. It is standard kernel practice to place cosmetic changes into their own patches, because it is standard kernel practice to break up logically distinct changes.
We are talking about:
pata_via.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-)Quoted 6 lines
patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change is clearly documented in the patch description.
Do people really wonder why I find upstream to be too much hassle to deal with?
The thousand other kernel developers seem to be able to split up their patches, separating out cosmetic changes from functional ones. It has clear engineering benefits, and has been standard practice for a decade or more.
Quoted 7 lines
Why is it such an imposition for your patches to look like everyone else's? And by "everyone", I mean all other kernel developers, not just other ATA developers.
You seem to consider standard kernel practice a hassle. Separating out cosmetic changes is not only a libata practice, it is the norm for the entire kernel.
Indeed.
From
94be9a58d7e683ac3c1df1858a17f09ebade8da0Mon Sep 17 00:00:00 2001
From: Jeff Garzik<[email protected]>
Date: Fri, 16 Jan 2009 10:17:09 -0500
Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
for SAS drivers.Quoted 7 lines
Caught by Ke Wei (and team?) at Marvell.
Also, move the
ata_scsi_ioctlexport tolibata-scsi.c, as that seems to be the general trend.Acked-by James Bottomley<[email protected]>Signed-off-by Jeff Garzik<[email protected]>
Quoted 6 lines
If your point, by posting this patch, is that it includes a ton of gratuitous cosmetic changes, you misread the patch.
ata_scsi_ioctl()remains in existence; only the callers need to use the new SAS-related ioctl function were updated. The remainder continued to useata_scsi_ioctl().
Moving kernel exports around is completely unrelated to a bug fix.
Yes, it is convenient to do it in the same patch and OK with me.
--
Bartlomiej Zolnierkiewicz
Quoted 52 lines · Bartlomiej Zolnierkiewicz
Quoted 51 lines · Jeff Garzik
Quoted 49 lines · Bartlomiej Zolnierkiewicz
Quoted 24 lines · Jeff Garzik
Quoted 12 lines
Quoted 6 lines
Quoted 1 line
pata_via: clear UDMA transfer mode bit for PIO and MWDMAapplied -- even though Alan's comment was correct. It is standard kernel practice to place cosmetic changes into their own patches, because it is standard kernel practice to break up logically distinct changes.
We are talking about:
pata_via.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-)Quoted 6 lines
patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change is clearly documented in the patch description.
Do people really wonder why I find upstream to be too much hassle to deal with?
The thousand other kernel developers seem to be able to split up their patches, separating out cosmetic changes from functional ones. It has clear engineering benefits, and has been standard practice for a decade or more.
Quoted 7 lines
Why is it such an imposition for your patches to look like everyone else's? And by "everyone", I mean all other kernel developers, not just other ATA developers.
You seem to consider standard kernel practice a hassle. Separating out cosmetic changes is not only a libata practice, it is the norm for the entire kernel.
Indeed.
From
94be9a58d7e683ac3c1df1858a17f09ebade8da0Mon Sep 17 00:00:00 2001
From: Jeff Garzik<[email protected]>
Date: Fri, 16 Jan 2009 10:17:09 -0500
Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
for SAS drivers.Caught by Ke Wei (and team?) at Marvell.
Also, move the
ata_scsi_ioctlexport tolibata-scsi.c, as that seems to be the general trend.Acked-by James Bottomley<[email protected]>Signed-off-by Jeff Garzik<[email protected]>
Quoted 8 lines
Quoted 6 lines
If your point, by posting this patch, is that it includes a ton of gratuitous cosmetic changes, you misread the patch.
ata_scsi_ioctl()remains in existence; only the callers need to use the new SAS-related ioctl function were updated. The remainder continued to useata_scsi_ioctl().Moving kernel exports around is completely unrelated to a bug fix.
Did the patch contain -cosmetic- changes intermingled with code changes, in the same code lines? No.
Is it good kernel practice to intermingle cosmetic changes with functional ones, in the same code lines? Also, no.
Jeff
Quoted 5 lines · Jeff Garzik
Did the patch contain -cosmetic- changes intermingled with code changes, in the same code lines? No.
Is it good kernel practice to intermingle cosmetic changes with functional ones, in the same code lines? Also, no.
In fact, I recall one case where a certain developer on this list used cosmetic code changes (Lindent, IIRC) to hide functional, security-related code changes.
Mixing cosmetic and function changes is simply bad engineering practice, _especially_ when they occur in the same lines of code.
Jeff
Quoted 56 lines · Jeff Garzik
Quoted 55 lines · Bartlomiej Zolnierkiewicz
Quoted 54 lines · Jeff Garzik
Quoted 42 lines · Bartlomiej Zolnierkiewicz
Quoted 24 lines · Jeff Garzik
Quoted 12 lines
Quoted 6 lines
Quoted 1 line
pata_via: clear UDMA transfer mode bit for PIO and MWDMAapplied -- even though Alan's comment was correct. It is standard kernel practice to place cosmetic changes into their own patches, because it is standard kernel practice to break up logically distinct changes.
We are talking about:
pata_via.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-)Quoted 6 lines
patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change is clearly documented in the patch description.
Do people really wonder why I find upstream to be too much hassle to deal with?
The thousand other kernel developers seem to be able to split up their patches, separating out cosmetic changes from functional ones. It has clear engineering benefits, and has been standard practice for a decade or more.
Quoted 7 lines
Why is it such an imposition for your patches to look like everyone else's? And by "everyone", I mean all other kernel developers, not just other ATA developers.
You seem to consider standard kernel practice a hassle. Separating out cosmetic changes is not only a libata practice, it is the norm for the entire kernel.
Indeed.
From
94be9a58d7e683ac3c1df1858a17f09ebade8da0Mon Sep 17 00:00:00 2001
From: Jeff Garzik<[email protected]>
Date: Fri, 16 Jan 2009 10:17:09 -0500
Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
for SAS drivers.Quoted 7 lines
Caught by Ke Wei (and team?) at Marvell.
Also, move the
ata_scsi_ioctlexport tolibata-scsi.c, as that seems to be the general trend.Acked-by James Bottomley<[email protected]>Signed-off-by Jeff Garzik<[email protected]>If your point, by posting this patch, is that it includes a ton of gratuitous cosmetic changes, you misread the patch.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
ata_scsi_ioctl()remains in existence; only the callers need to use the new SAS-related ioctl function were updated. The remainder continued to useata_scsi_ioctl().Moving kernel exports around is completely unrelated to a bug fix.
Did the patch contain -cosmetic- changes intermingled with code changes, in the same code lines? No.
Took me a bit longer to find such one since you are not doing much patches any longer. ;)
Quoted 2 lines
Is it good kernel practice to intermingle cosmetic changes with functional ones, in the same code lines? Also, no.
I prefer using common sense over black-and-white rules.
If patch is a _really_ tiny one (< 20 LOC changed) it sometimes makes sense to save the time on handling separate patches.
--
Bartlomiej Zolnierkiewicz
Quoted 1 line
From
ee9ccdf70163ca6408f6965e0fbc65baeac7312cMon Sep 17 00:00:00 2001
From: Jeff Garzik <[email protected]>
Date: Thu, 12 Jul 2007 15:51:22 -0400
Subject: [PATCH] [libata] sata_mv: Fix and clean up per-chip-generation tests
Due to a mistake in test logic, Gen-IIE chips were being treated as Gen-II chips in some cases. Fix this, and in the process, clean up IS_50XX/IS_60XX tests to the more uniform IS_GEN_{I,II,IIE} tests.
--- drivers/ata/sata_mv.c | 29 ++++++++++++++--------------- 1 files changed, 14 insertions(+), 15 deletions(-)
drivers/ata/sata_mv.c +14 -15
@@ -301,8 +301,9 @@ enum {MV_HP_ERRATA_60X1B2 = (1 <<3 ),MV_HP_ERRATA_60X1C0 = (1 <<4 ),MV_HP_ERRATA_XX42A0 = (1 <<5 ), -MV_HP_50XX = (1 <<6 ), -MV_HP_GEN_IIE = (1 <<7 ), +MV_HP_GEN_I = (1 <<6 ), +MV_HP_GEN_II = (1 <<7 ), +MV_HP_GEN_IIE = (1 <<8 ),/* Port private flags (pp_flags) */ MV_PP_FLAG_EDMA_EN = (1 << 0),
@@ -310,10 +311,8 @@ enum { MV_PP_FLAG_HAD_A_RESET = (1 << 2), }; -#define IS_50XX (hpriv) ((hpriv)->hp_flags & MV_HP_50XX) -#define IS_60XX (hpriv) (((hpriv)->hp_flags & MV_HP_50XX) == 0) -#define IS_GEN_I (hpriv) IS_50XX(hpriv) -#define IS_GEN_II (hpriv) IS_60XX(hpriv) +#define IS_GEN_I (hpriv) ((hpriv)->hp_flags & MV_HP_GEN_I) +#define IS_GEN_II (hpriv) ((hpriv)->hp_flags & MV_HP_GEN_II)#define IS_GEN_IIE (hpriv) ((hpriv)->hp_flags & MV_HP_GEN_IIE)enum {
@@ -1406,7 +1405,7 @@ static void mv_err_intr(struct ata_port *ap, struct ata_queued_cmd *qc) ", dev disconnect" : ", dev connect"); } -if (IS_50XX (hpriv)) { +if (IS_GEN_I (hpriv)) { eh_freeze_mask =EDMA_EH_FREEZE_5 ;if (edma_err_cause &EDMA_ERR_SELF_DIS_5 ) {
@@ -2100,7 +2099,7 @@ static void mv_channel_reset(struct mv_host_priv *hpriv, void __iomem *mmio,writelfl (ATA_RST , port_mmio +EDMA_CMD_OFS ); -if (IS_60XX (hpriv)) { +if (IS_GEN_II (hpriv)) {u32 ifctl =readl (port_mmio +SATA_INTERFACE_CTL ); ifctl |= (1 <<7 );/* enable gen2i speed */ ifctl = (ifctl &0xfff ) |0x9b1000 ;/* from chip spec */
@@ -2116,7 +2115,7 @@ static void mv_channel_reset(struct mv_host_priv *hpriv, void __iomem *mmio, hpriv->ops->phy_errata (hpriv, mmio, port_no); -if (IS_50XX (hpriv)) +if (IS_GEN_I (hpriv))mdelay (1 ); }
@@ -2163,7 +2162,7 @@ comreset_retry: }while (time_before (jiffies, deadline));/* work around errata */ -if (IS_60XX (hpriv) && +if (IS_GEN_II (hpriv) && (sstatus !=0x0 ) && (sstatus !=0x113 ) && (sstatus !=0x123 ) && (retry-- >0 )) goto comreset_retry;
@@ -2396,7 +2395,7 @@ static int mv_chip_id(struct ata_host *host, unsigned int board_idx)switch (board_idx) {case chip_5080: hpriv->ops = &mv5xxx_ops; - hp_flags |=MV_HP_50XX ; + hp_flags |=MV_HP_GEN_I ;switch (rev_id) {case 0x1 :
@@ -2416,7 +2415,7 @@ static int mv_chip_id(struct ata_host *host, unsigned int board_idx)case chip_504x:case chip_508x: hpriv->ops = &mv5xxx_ops; - hp_flags |=MV_HP_50XX ; + hp_flags |=MV_HP_GEN_I ;switch (rev_id) {case 0x0 :
@@ -2436,6 +2435,7 @@ static int mv_chip_id(struct ata_host *host, unsigned int board_idx)case chip_604x:case chip_608x: hpriv->ops = &mv6xxx_ops; + hp_flags |=MV_HP_GEN_II ;switch (rev_id) {case 0x7 :
@@ -2455,7 +2455,6 @@ static int mv_chip_id(struct ata_host *host, unsigned int board_idx)case chip_7042:case chip_6042: hpriv->ops = &mv6xxx_ops; - hp_flags |=MV_HP_GEN_IIE ;switch (rev_id) {
@@ -2522,7 +2521,7 @@ static int mv_init_host(struct ata_host *host, unsigned int board_idx) hpriv->ops->enable_leds (hpriv, mmio);for (port =0 ; port < host->n_ports; port++) { -if (IS_60XX (hpriv)) { +if (IS_GEN_II (hpriv)) {void __iomem *port_mmio =mv_port_base (mmio, port);u32 ifctl =readl (port_mmio +SATA_INTERFACE_CTL );
@@ -2557,7 +2556,7 @@ static int mv_init_host(struct ata_host *host, unsigned int board_idx)/* and unmask interrupt generation for host regs */ writelfl (PCI_UNMASK_ALL_IRQS , mmio +PCI_IRQ_MASK_OFS ); -if (IS_50XX (hpriv)) +if (IS_GEN_I (hpriv))writelfl (~HC_MAIN_MASKED_IRQS_5 , mmio +HC_MAIN_IRQ_MASK_OFS );else writelfl (~HC_MAIN_MASKED_IRQS , mmio +HC_MAIN_IRQ_MASK_OFS );
Signature · 1 line
1.6.4.2
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Quoted 2 lines · Jeff Garzik
Is it good kernel practice to intermingle cosmetic changes with functional ones, in the same code lines? Also, no.
I prefer using common sense over black-and-white rules.
If patch is a _really_ tiny one (< 20 LOC changed) it sometimes makes sense to save the time on handling separate patches.
This is open source -- you have to consider the time saved by reviewers too.
But I doubt you have saved time on all your motivated commit searches, so...
Jeff
Quoted 11 lines · Jeff Garzik
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Quoted 2 lines · Jeff Garzik
Is it good kernel practice to intermingle cosmetic changes with functional ones, in the same code lines? Also, no.
I prefer using common sense over black-and-white rules.
If patch is a _really_ tiny one (< 20 LOC changed) it sometimes makes sense to save the time on handling separate patches.
This is open source -- you have to consider the time saved by reviewers too.
Like I said previously this is best done on per-case basis and because it is open source eventually people will come up with an alternative patch if they find the current one too bothersome to review, merge etc.
Quoted 1 line
But I doubt you have saved time on all your motivated commit searches, so...
Well, just two basic searches limited to one contributor and one directory..
--
Bartlomiej Zolnierkiewicz
Hello.
Quoted 3 lines · Jeff Garzik
Quoted 1 line
pata_efar: MWDMA0 is unsupportedskipped, pending discussion (just sent email)
There's basically nothing to discuss -- the PIIX like chips don't
support MWDMA0 (with an acceptable cycle length, if at all, anyway). The way the driver is written, MWDMA0 is simply programmed overclocked.
Quoted 4 lines
Quoted 2 lines
pata_hpt3x2n: fix overclocked MWDMA0 timingskipped, pending discussion (just sent email)
Nothing to discuss either, this looks like a single digit typo to me...
Quoted 4 lines
Quoted 2 lines
pata_hpt3x3: Power Management fixapplied, on a hope and a prayer (did not see this posted to mailing list?).
http://marc.info/?l=linux-ide&m=125916980522990
Quoted 4 lines
Quoted 2 lines
pata_it8213: MWDMA0 is unsupportedskipped, pending discussion (just sent email)
Nothing to discuss...
Quoted 3 lines
pata_oldpiix: MWDMA0 is unsupportedskipped -- Alan, Sergey, comments?
Quoted 4 lines
Quoted 2 lines
pata_rdc: MWDMA0 is unsupportedskipped -- Alan, Sergey, comments?
MBR, Sergei
Quoted 21 lines · Sergei Shtylyov
Hello.
Quoted 3 lines · Jeff Garzik
Quoted 1 line
pata_efar: MWDMA0 is unsupportedskipped, pending discussion (just sent email)
There's basically nothing to discuss -- the PIIX like chips don't support MWDMA0 (with an acceptable cycle length, if at all, anyway). The way the driver is written, MWDMA0 is simply programmed overclocked.
Quoted 4 lines
Quoted 2 lines
pata_hpt3x2n: fix overclocked MWDMA0 timingskipped, pending discussion (just sent email)
Nothing to discuss either, this looks like a single digit typo to me...
Quoted 1 line
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
pata_hpt3x3: Power Management fixapplied, on a hope and a prayer (did not see this posted to mailing list?).
Yeah, missed that. Bart provided a link, too.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
pata_it8213: MWDMA0 is unsupportedskipped, pending discussion (just sent email)
Nothing to discuss...
Perhaps discuss was the wrong word. After reviewing each thread, in each case, it remained unclear whether the original patch was correct or not, especially since the docs seemed to list MWDMA0 as supported on PIIX-like chips.
Thanks for going over these, that should clear up my confusion.
Jeff
Likewise I'm happy with all of this stuff. My worry is the turn 32bit on for hardware without real testing/docs checking except where it was on by default bits.
The rest is good stuff. The 32bit stuff for the unproven cards could do longer in -next as its only a performance boost for PIO.
Jeff Garzik
AppliedQuoted 3 lines · Jeff Garzik
Quoted 1 line
pata_efar: MWDMA0 is unsupportedskipped, pending discussion (just sent email)
applied, after merging into a single "PIIX no MWDMA0" patch
Quoted 3 lines
Quoted 1 line
pata_hpt3x2n: fix overclocked MWDMA0 timingskipped, pending discussion (just sent email)
applied
Quoted 3 lines
Quoted 1 line
pata_it8213: MWDMA0 is unsupportedskipped, pending discussion (just sent email)
applied
Quoted 3 lines
Quoted 1 line
pata_oldpiix: MWDMA0 is unsupportedskipped -- Alan, Sergey, comments?
applied, after merging into a single "PIIX no MWDMA0" patch
Quoted 3 lines
Quoted 1 line
pata_rdc: MWDMA0 is unsupportedskipped -- Alan, Sergey, comments?
applied, after merging into a single "PIIX no MWDMA0" patch
Quoted 3 lines
Quoted 1 line
pata_oldpiix: MWDMA0 is unsupportedskipped -- Alan, Sergey, comments?
Would need to look at the chip docs again. Certainly the ICH documents the lack of MWDMA. Dunno about the original PIIX.
Rest looks sane, and that one probably is as the only way to to DMA0 appears to be with TIME0 clear. Unfortunately I can't lay my hands on a PIIX errata sheet right now. The PIIX4 programming tables don't list MWDMA0.
The original PIIX datasheet clarifies one other point too
For 32bit PIO it seems you must have bit 4 and 0 of IDETIM set for 32bit data port access. That is you cannot use 32bit PIO when TIME0/TIME1 are not set for that device.
MPIIX fixes that restriction (no DMA but does have 32bit PIO for all modes) by inserting the needed mode 0 two clocks of CS deselect even if not visible on the ISA bus. The restriction is also not mentioned on PIIX4+ so presumably is specific to the original chip.
Quoted 2 lines
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Not quite yet - Linus hasn't said "go"
Quoted 3 lines
However, bug fixes and the like should definitely be in 2.6.33. ->init_host is definitely 2.6.34 material. Some of the other stuff could go either way.
The bits that probably should be delayed a bit more (if any) IMHO are the 32bit enables for hardware that doesn't use 32bit by default on the drivers/ide stack, and tweaks for obscure old hardware that won't get much testing.
The sooner it's all upstream the better.
Alan
Quoted 4 lines · Alan Cox
Quoted 2 lines
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Not quite yet - Linus hasn't said "go"
He rarely if ever says "go." The kernel X is released, and people send pull requests to Linus for X+1. He typically merges immediately, but does not push out the first set of merges for a few days.
The stuff pushed to Linus for kernel X+1 should have already been living in linux-next (libata-dev.git#NEXT, to us).
Quoted 4 lines
The bits that probably should be delayed a bit more (if any) IMHO are the 32bit enables for hardware that doesn't use 32bit by default on the
drivers/idestack, and tweaks for obscure old hardware that won't get much testing.
Agreed mostly... I still want to push fixes even if for obscure hardware.
Jeff
From: Jeff Garzik <[email protected]>
Date: Thu, 03 Dec 2009 12:39:48 -0500
Quoted 9 lines · Alan Cox
Quoted 4 lines
Quoted 2 lines
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Not quite yet - Linus hasn't said "go"
He rarely if ever says "go." The kernel X is released, and people send pull requests to Linus for X+1. He typically merges immediately, but does not push out the first set of merges for a few days.
I don't think he even starts pulling until 1 or 2 days later.
I personally never send him a pull request until a day or two in.
Quoted 9 lines · David Miller
From: Jeff Garzik<[email protected]>
Date: Thu, 03 Dec 2009 12:39:48 -0500Quoted 6 lines · Alan Cox
Quoted 4 lines
Quoted 2 lines
The merge window is upon us, which by strict rules means that anything not already in libata-dev.git#upstream needs to wait until 2.6.34.
Not quite yet - Linus hasn't said "go"
Quoted 7 lines
Quoted 3 lines
He rarely if ever says "go." The kernel X is released, and people send pull requests to Linus for X+1. He typically merges immediately, but does not push out the first set of merges for a few days.
I don't think he even starts pulling until 1 or 2 days later.
I personally never send him a pull request until a day or two in.
<shrug> In the past he has commented on pulls, indicating some sort of immediate action, yet not pushed for a few days.
Not a big deal. Plenty of other people send pull requests immediately, even if you ignore the high-volume Ingo special case <chuckle>
In any case, the basic point is that Linus does not say "go" for merge windows. People send, he pulls when he chooses, and pushes when he chooses. It's all very zen ;-)
Jeff
From: Jeff Garzik <[email protected]>
Date: Thu, 03 Dec 2009 16:32:13 -0500
Quoted 3 lines
In any case, the basic point is that Linus does not say "go" for merge windows. People send, he pulls when he chooses, and pushes when he chooses. It's all very zen ;-)
True.
But I also want to mention that I wait 2 days for another reason, so that whatever I do toss to him gets full exposure in -next at least one time.