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
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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/ata_piix.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: b/drivers/ata/ata_piix.c
===================================================================
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -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)
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/ata_piix.c | 112 ++++++++++++++++---------------------------------
1 file changed, 37 insertions(+), 75 deletions(-)
Index: b/drivers/ata/ata_piix.c
===================================================================
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -666,22 +666,11 @@ static int piix_pata_prereset(struct ata
static 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 a
performance (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);
}
/**
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_artop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/ata/pata_artop.c
===================================================================
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -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,
From: 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
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_artop.c | 111 +++++++++++++++++++++++------------------------
1 file changed, 55 insertions(+), 56 deletions(-)
Index: b/drivers/ata/pata_artop.c
===================================================================
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -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 artop6
static 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_de
if (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);
From: 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.
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
===================================================================
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -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_de
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) { /* 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)
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_artop: unify ->prereset methods
We can use the same ->prereset method for ATP850 and ATP86xR chipsets.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_artop.c | 28 +++++++---------------------
1 file changed, 7 insertions(+), 21 deletions(-)
Index: b/drivers/ata/pata_artop.c
===================================================================
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -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_l
struct 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)
From: 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).
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
===================================================================
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -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 at
pci_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));
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_atiixp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_atiixp.c
===================================================================
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_atiixp.c | 15 ---------------
1 file changed, 15 deletions(-)
Index: b/drivers/ata/pata_atiixp.c
===================================================================
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -107,7 +107,6 @@ static void atiixp_set_dmamode(struct at
struct 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 at
pci_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);
}
/**
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_atiixp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_atiixp.c
===================================================================
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -207,7 +207,7 @@ static int atiixp_init_one(struct pci_de
static 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
};
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_atiixp.c | 58 ++++------------------------------------------
1 file changed, 6 insertions(+), 52 deletions(-)
Index: b/drivers/ata/pata_atiixp.c
===================================================================
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -107,6 +107,9 @@ static void atiixp_set_dmamode(struct at
struct 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,
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_atiixp: add proper ->prereset method
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_atiixp.c | 35 ++++++++++++++++++++++++++---------
1 file changed, 26 insertions(+), 9 deletions(-)
Index: b/drivers/ata/pata_atiixp.c
===================================================================
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -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);
}
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_efar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_efar.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -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
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);
}
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_efar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -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);
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_efar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -252,7 +252,7 @@ static int efar_init_one (struct pci_dev
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,
};
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_efar.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -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 ata
if (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 ata
pci_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);
}
/**
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_efar.c | 88 +++++++++++++++---------------------------------
1 file changed, 29 insertions(+), 59 deletions(-)
Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -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 ata
static 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);
}
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/Kconfig | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Index: b/drivers/ata/Kconfig
===================================================================
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -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.
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_cmd64x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_cmd64x.c
===================================================================
--- a/drivers/ata/pata_cmd64x.c
+++ b/drivers/ata/pata_cmd64x.c
@@ -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,
};
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_cmd64x.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
Index: b/drivers/ata/pata_cmd64x.c
===================================================================
--- a/drivers/ata/pata_cmd64x.c
+++ b/drivers/ata/pata_cmd64x.c
@@ -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_operations
static 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 = {
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_cmd64x.c | 41 +++++++++++++++++++----------------------
1 file changed, 19 insertions(+), 22 deletions(-)
Index: b/drivers/ata/pata_cmd64x.c
===================================================================
--- a/drivers/ata/pata_cmd64x.c
+++ b/drivers/ata/pata_cmd64x.c
@@ -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_de
static 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;
}
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_cs5520.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_cs5520.c
===================================================================
--- a/drivers/ata/pata_cs5520.c
+++ b/drivers/ata/pata_cs5520.c
@@ -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,
From: 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).
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_cs5520.c | 39 +--------------------------------------
1 file changed, 1 insertion(+), 38 deletions(-)
Index: b/drivers/ata/pata_cs5520.c
===================================================================
--- a/drivers/ata/pata_cs5520.c
+++ b/drivers/ata/pata_cs5520.c
@@ -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)
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_cs5530.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_cs5530.c
===================================================================
--- a/drivers/ata/pata_cs5530.c
+++ b/drivers/ata/pata_cs5530.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_cs5535.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_cs5535.c
===================================================================
--- a/drivers/ata/pata_cs5535.c
+++ b/drivers/ata/pata_cs5535.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_cs5535.c | 12 ------------
1 file changed, 12 deletions(-)
Index: b/drivers/ata/pata_cs5535.c
===================================================================
--- a/drivers/ata/pata_cs5535.c
+++ b/drivers/ata/pata_cs5535.c
@@ -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);
}
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_cypress.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_cypress.c
===================================================================
--- a/drivers/ata/pata_cypress.c
+++ b/drivers/ata/pata_cypress.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/Kconfig | 3 +++
1 file changed, 3 insertions(+)
Index: b/drivers/ata/Kconfig
===================================================================
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -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
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_hpt366.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_hpt366.c
===================================================================
--- a/drivers/ata/pata_hpt366.c
+++ b/drivers/ata/pata_hpt366.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_hpt37x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/ata/pata_hpt37x.c
===================================================================
--- a/drivers/ata/pata_hpt37x.c
+++ b/drivers/ata/pata_hpt37x.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_hpt3x2n.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_hpt3x2n.c
===================================================================
--- a/drivers/ata/pata_hpt3x2n.c
+++ b/drivers/ata/pata_hpt3x2n.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_hpt3x3.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
Index: b/drivers/ata/pata_hpt3x3.c
===================================================================
--- a/drivers/ata/pata_hpt3x3.c
+++ b/drivers/ata/pata_hpt3x3.c
@@ -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
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_it8213.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_it8213.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -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 */
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_it8213.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -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 */
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_it8213.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -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);
}
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_it8213.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -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 a
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);
}
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_it8213.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -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);
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_it8213.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -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 a
if (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 a
pci_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);
}
/**
From: 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).
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
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -61,20 +61,9 @@ static int it8213_cable_detect(struct at
return 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 a
static 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);
}
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_it8213: fix it8213_pre_reset() documentation
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_it8213.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -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
*
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_it821x.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Index: b/drivers/ata/pata_it821x.c
===================================================================
--- a/drivers/ata/pata_it821x.c
+++ b/drivers/ata/pata_it821x.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_jmicron.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_jmicron.c
===================================================================
--- a/drivers/ata/pata_jmicron.c
+++ b/drivers/ata/pata_jmicron.c
@@ -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,
};
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_legacy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -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);
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_legacy.c | 1 +
1 file changed, 1 insertion(+)
Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -787,6 +787,7 @@ static struct ata_port_operations qdi658
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,
};
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_legacy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -672,7 +672,7 @@ static void qdi6580dp_set_piomode(struct
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 +707,7 @@ static void qdi6580_set_piomode(struct a
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);
}
/**
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_legacy: add pointers to QDI65x0 documentation
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_legacy.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -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.
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_legacy.c | 98 ++++++++++------------------------------------
1 file changed, 23 insertions(+), 75 deletions(-)
Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -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_devi
static 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;
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_legacy: use PIO mask defines
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_legacy.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -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 }
};
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
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(-)
Index: b/drivers/ata/Kconfig
===================================================================
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -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.
Index: b/drivers/ata/Makefile
===================================================================
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -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
Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -133,7 +133,12 @@ static int ht6560a; /* HT 6560A on prim
static 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);
Index: b/drivers/ata/pata_qdi.c
===================================================================
--- a/drivers/ata/pata_qdi.c
+++ /dev/null
@@ -1,366 +0,0 @@
-/*
- * pata_qdi.c - QDI VLB ATA controllers
- * (C) 2006 Red Hat
- *
- * This driver mostly exists as a proof of concept for non PCI devices under
- * libata. While the QDI6580 was 'neat' in 1993 it is no longer terribly
- * useful.
- *
- * Tuning code written from the documentation at
- * http://www.ryston.cz/petr/vlb/qd6500.html
- * http://www.ryston.cz/petr/vlb/qd6580.html
- *
- * Probe code based on drivers/ide/legacy/qd65xx.c
- * Rewritten from the work of Colten Edwards <[email protected]> by
- * Samuel Thibault <[email protected]>
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/pci.h>
-#include <linux/init.h>
-#include <linux/blkdev.h>
-#include <linux/delay.h>
-#include <scsi/scsi_host.h>
-#include <linux/libata.h>
-#include <linux/platform_device.h>
-
-#define DRV_NAME "pata_qdi"
-#define DRV_VERSION "0.3.1"
-
-#define NR_HOST 4 /* Two 6580s */
-
-struct qdi_data {
- unsigned long timing;
- u8 clock[2];
- u8 last;
- int fast;
- struct platform_device *platform_dev;
-
-};
-
-static struct ata_host *qdi_host[NR_HOST];
-static struct qdi_data qdi_data[NR_HOST];
-static int nr_qdi_host;
-
-#ifdef MODULE
-static int probe_qdi = 1;
-#else
-static int probe_qdi;
-#endif
-
-static void qdi6500_set_piomode(struct ata_port *ap, struct ata_device *adev)
-{
- struct ata_timing t;
- struct qdi_data *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 (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;
-
- qdi->clock[adev->devno] = timing;
-
- outb(timing, qdi->timing);
-}
-
-static void qdi6580_set_piomode(struct ata_port *ap, struct ata_device *adev)
-{
- struct ata_timing t;
- struct qdi_data *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 (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;
-
- qdi->clock[adev->devno] = timing;
-
- outb(timing, qdi->timing);
-
- /* Clear the FIFO */
- if (adev->class != ATA_DEV_ATA)
- outb(0x5F, (qdi->timing & 0xFFF0) + 3);
-}
-
-/**
- * qdi_qc_issue - command issue
- * @qc: command pending
- *
- * Called when the libata layer is about to issue a command. We wrap
- * this interface so that we can load the correct ATA timings.
- */
-
-static unsigned int qdi_qc_issue(struct ata_queued_cmd *qc)
-{
- struct ata_port *ap = qc->ap;
- struct ata_device *adev = qc->dev;
- struct qdi_data *qdi = ap->host->private_data;
-
- if (qdi->clock[adev->devno] != qdi->last) {
- if (adev->pio_mode) {
- qdi->last = qdi->clock[adev->devno];
- outb(qdi->clock[adev->devno], qdi->timing);
- }
- }
- return ata_sff_qc_issue(qc);
-}
-
-static unsigned int qdi_data_xfer(struct ata_device *dev, unsigned char *buf,
- unsigned int buflen, int rw)
-{
- if (ata_id_has_dword_io(dev->id)) {
- struct ata_port *ap = dev->link->ap;
- int slop = buflen & 3;
-
- if (rw == READ)
- ioread32_rep(ap->ioaddr.data_addr, buf, buflen >> 2);
- else
- iowrite32_rep(ap->ioaddr.data_addr, buf, buflen >> 2);
-
- if (unlikely(slop)) {
- __le32 pad;
- if (rw == READ) {
- pad = cpu_to_le32(ioread32(ap->ioaddr.data_addr));
- memcpy(buf + buflen - slop, &pad, slop);
- } else {
- memcpy(&pad, buf + buflen - slop, slop);
- iowrite32(le32_to_cpu(pad), ap->ioaddr.data_addr);
- }
- buflen += 4 - slop;
- }
- } else
- buflen = ata_sff_data_xfer(dev, buf, buflen, rw);
-
- return buflen;
-}
-
-static struct scsi_host_template qdi_sht = {
- ATA_PIO_SHT(DRV_NAME),
-};
-
-static struct ata_port_operations qdi6500_port_ops = {
- .inherits = &ata_sff_port_ops,
- .qc_issue = qdi_qc_issue,
- .sff_data_xfer = qdi_data_xfer,
- .cable_detect = ata_cable_40wire,
- .set_piomode = qdi6500_set_piomode,
-};
-
-static struct ata_port_operations qdi6580_port_ops = {
- .inherits = &qdi6500_port_ops,
- .set_piomode = qdi6580_set_piomode,
-};
-
-/**
- * qdi_init_one - attach a qdi interface
- * @type: Type to display
- * @io: I/O port start
- * @irq: interrupt line
- * @fast: True if on a > 33Mhz VLB
- *
- * Register an ISA bus IDE interface. Such interfaces are PIO and we
- * assume do not support IRQ sharing.
- */
-
-static __init int qdi_init_one(unsigned long port, int type, unsigned long io, int irq, int fast)
-{
- unsigned long ctl = io + 0x206;
- struct platform_device *pdev;
- struct ata_host *host;
- struct ata_port *ap;
- void __iomem *io_addr, *ctl_addr;
- int ret;
-
- /*
- * Fill in a probe structure first of all
- */
-
- pdev = platform_device_register_simple(DRV_NAME, nr_qdi_host, NULL, 0);
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
-
- ret = -ENOMEM;
- io_addr = devm_ioport_map(&pdev->dev, io, 8);
- ctl_addr = devm_ioport_map(&pdev->dev, ctl, 1);
- if (!io_addr || !ctl_addr)
- goto fail;
-
- ret = -ENOMEM;
- host = ata_host_alloc(&pdev->dev, 1);
- if (!host)
- goto fail;
- ap = host->ports[0];
-
- if (type == 6580) {
- ap->ops = &qdi6580_port_ops;
- ap->pio_mask = ATA_PIO4;
- ap->flags |= ATA_FLAG_SLAVE_POSS;
- } else {
- ap->ops = &qdi6500_port_ops;
- ap->pio_mask = ATA_PIO2; /* Actually PIO3 !IORDY is possible */
- ap->flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_NO_IORDY;
- }
-
- ap->ioaddr.cmd_addr = io_addr;
- ap->ioaddr.altstatus_addr = ctl_addr;
- ap->ioaddr.ctl_addr = ctl_addr;
- ata_sff_std_ports(&ap->ioaddr);
-
- ata_port_desc(ap, "cmd %lx ctl %lx", io, ctl);
-
- /*
- * Hook in a private data structure per channel
- */
- ap->private_data = &qdi_data[nr_qdi_host];
-
- qdi_data[nr_qdi_host].timing = port;
- qdi_data[nr_qdi_host].fast = fast;
- qdi_data[nr_qdi_host].platform_dev = pdev;
-
- printk(KERN_INFO DRV_NAME": qd%d at 0x%lx.\n", type, io);
-
- /* activate */
- ret = ata_host_activate(host, irq, ata_sff_interrupt, 0, &qdi_sht);
- if (ret)
- goto fail;
-
- qdi_host[nr_qdi_host++] = dev_get_drvdata(&pdev->dev);
- return 0;
-
- fail:
- platform_device_unregister(pdev);
- return ret;
-}
-
-/**
- * qdi_init - attach qdi interfaces
- *
- * Attach qdi IDE interfaces by scanning the ports it may occupy.
- */
-
-static __init int qdi_init(void)
-{
- unsigned long flags;
- static const unsigned long qd_port[2] = { 0x30, 0xB0 };
- static const unsigned long ide_port[2] = { 0x170, 0x1F0 };
- static const int ide_irq[2] = { 14, 15 };
-
- int ct = 0;
- int i;
-
- if (probe_qdi == 0)
- return -ENODEV;
-
- /*
- * Check each possible QD65xx base address
- */
-
- for (i = 0; i < 2; i++) {
- unsigned long port = qd_port[i];
- u8 r, res;
-
-
- if (request_region(port, 2, "pata_qdi")) {
- /* Check for a card */
- local_irq_save(flags);
- r = inb_p(port);
- outb_p(0x19, port);
- res = inb_p(port);
- outb_p(r, port);
- local_irq_restore(flags);
-
- /* Fail */
- if (res == 0x19)
- {
- release_region(port, 2);
- continue;
- }
-
- /* Passes the presence test */
- r = inb_p(port + 1); /* Check port agrees with port set */
- if ((r & 2) >> 1 != i) {
- release_region(port, 2);
- continue;
- }
-
- /* Check card type */
- if ((r & 0xF0) == 0xC0) {
- /* QD6500: single channel */
- if (r & 8) {
- /* Disabled ? */
- release_region(port, 2);
- continue;
- }
- if (qdi_init_one(port, 6500, ide_port[r & 0x01], ide_irq[r & 0x01], r & 0x04) == 0)
- ct++;
- }
- if (((r & 0xF0) == 0xA0) || (r & 0xF0) == 0x50) {
- /* QD6580: dual channel */
- if (!request_region(port + 2 , 2, "pata_qdi"))
- {
- release_region(port, 2);
- continue;
- }
- res = inb(port + 3);
- if (res & 1) {
- /* Single channel mode */
- if (qdi_init_one(port, 6580, ide_port[r & 0x01], ide_irq[r & 0x01], r & 0x04) == 0)
- ct++;
- } else {
- /* Dual channel mode */
- if (qdi_init_one(port, 6580, 0x1F0, 14, r & 0x04) == 0)
- ct++;
- if (qdi_init_one(port + 2, 6580, 0x170, 15, r & 0x04) == 0)
- ct++;
- }
- }
- }
- }
- if (ct != 0)
- return 0;
- return -ENODEV;
-}
-
-static __exit void qdi_exit(void)
-{
- int i;
-
- for (i = 0; i < nr_qdi_host; i++) {
- ata_host_detach(qdi_host[i]);
- /* Free the control resource. The 6580 dual channel has the resources
- * claimed as a pair of 2 byte resources so we need no special cases...
- */
- release_region(qdi_data[i].timing, 2);
- platform_device_unregister(qdi_data[i].platform_dev);
- }
-}
-
-MODULE_AUTHOR("Alan Cox");
-MODULE_DESCRIPTION("low-level driver for qdi ATA");
-MODULE_LICENSE("GPL");
-MODULE_VERSION(DRV_VERSION);
-
-module_init(qdi_init);
-module_exit(qdi_exit);
-
-module_param(probe_qdi, int, 0);
-
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
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(-)
Index: b/drivers/ata/Kconfig
===================================================================
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -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.
Index: b/drivers/ata/Makefile
===================================================================
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -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
Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -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 for
MODULE_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);
Index: b/drivers/ata/pata_winbond.c
===================================================================
--- a/drivers/ata/pata_winbond.c
+++ /dev/null
@@ -1,282 +0,0 @@
-/*
- * pata_winbond.c - Winbond VLB ATA controllers
- * (C) 2006 Red Hat
- *
- * Support for the Winbond 83759A when operating in advanced mode.
- * Multichip mode is not currently supported.
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/blkdev.h>
-#include <linux/delay.h>
-#include <scsi/scsi_host.h>
-#include <linux/libata.h>
-#include <linux/platform_device.h>
-
-#define DRV_NAME "pata_winbond"
-#define DRV_VERSION "0.0.3"
-
-#define NR_HOST 4 /* Two winbond controllers, two channels each */
-
-struct winbond_data {
- unsigned long config;
- struct platform_device *platform_dev;
-};
-
-static struct ata_host *winbond_host[NR_HOST];
-static struct winbond_data winbond_data[NR_HOST];
-static int nr_winbond_host;
-
-#ifdef MODULE
-static int probe_winbond = 1;
-#else
-static int probe_winbond;
-#endif
-
-static DEFINE_SPINLOCK(winbond_lock);
-
-static void winbond_writecfg(unsigned long port, u8 reg, u8 val)
-{
- unsigned long flags;
- spin_lock_irqsave(&winbond_lock, flags);
- outb(reg, port + 0x01);
- outb(val, port + 0x02);
- spin_unlock_irqrestore(&winbond_lock, flags);
-}
-
-static u8 winbond_readcfg(unsigned long port, u8 reg)
-{
- u8 val;
-
- unsigned long flags;
- spin_lock_irqsave(&winbond_lock, flags);
- outb(reg, port + 0x01);
- val = inb(port + 0x02);
- spin_unlock_irqrestore(&winbond_lock, flags);
-
- return val;
-}
-
-static void winbond_set_piomode(struct ata_port *ap, struct ata_device *adev)
-{
- struct ata_timing t;
- struct winbond_data *winbond = ap->host->private_data;
- int active, recovery;
- u8 reg;
- int timing = 0x88 + (ap->port_no * 4) + (adev->devno * 2);
-
- reg = winbond_readcfg(winbond->config, 0x81);
-
- /* Get the timing data in cycles */
- if (reg & 0x40) /* Fast VLB bus, assume 50MHz */
- ata_timing_compute(adev, adev->pio_mode, &t, 20000, 1000);
- else
- ata_timing_compute(adev, adev->pio_mode, &t, 30303, 1000);
-
- active = (clamp_val(t.active, 3, 17) - 1) & 0x0F;
- recovery = (clamp_val(t.recover, 1, 15) + 1) & 0x0F;
- timing = (active << 4) | recovery;
- winbond_writecfg(winbond->config, timing, reg);
-
- /* Load the setup timing */
-
- reg = 0x35;
- if (adev->class != ATA_DEV_ATA)
- reg |= 0x08; /* FIFO off */
- if (!ata_pio_need_iordy(adev))
- reg |= 0x02; /* IORDY off */
- reg |= (clamp_val(t.setup, 0, 3) << 6);
- winbond_writecfg(winbond->config, timing + 1, reg);
-}
-
-
-static unsigned int winbond_data_xfer(struct ata_device *dev,
- unsigned char *buf, unsigned int buflen, int rw)
-{
- struct ata_port *ap = dev->link->ap;
- int slop = buflen & 3;
-
- if (ata_id_has_dword_io(dev->id)) {
- if (rw == READ)
- ioread32_rep(ap->ioaddr.data_addr, buf, buflen >> 2);
- else
- iowrite32_rep(ap->ioaddr.data_addr, buf, buflen >> 2);
-
- if (unlikely(slop)) {
- __le32 pad;
- if (rw == READ) {
- pad = cpu_to_le32(ioread32(ap->ioaddr.data_addr));
- memcpy(buf + buflen - slop, &pad, slop);
- } else {
- memcpy(&pad, buf + buflen - slop, slop);
- iowrite32(le32_to_cpu(pad), ap->ioaddr.data_addr);
- }
- buflen += 4 - slop;
- }
- } else
- buflen = ata_sff_data_xfer(dev, buf, buflen, rw);
-
- return buflen;
-}
-
-static struct scsi_host_template winbond_sht = {
- ATA_PIO_SHT(DRV_NAME),
-};
-
-static struct ata_port_operations winbond_port_ops = {
- .inherits = &ata_sff_port_ops,
- .sff_data_xfer = winbond_data_xfer,
- .cable_detect = ata_cable_40wire,
- .set_piomode = winbond_set_piomode,
-};
-
-/**
- * winbond_init_one - attach a winbond interface
- * @type: Type to display
- * @io: I/O port start
- * @irq: interrupt line
- * @fast: True if on a > 33Mhz VLB
- *
- * Register a VLB bus IDE interface. Such interfaces are PIO and we
- * assume do not support IRQ sharing.
- */
-
-static __init int winbond_init_one(unsigned long port)
-{
- struct platform_device *pdev;
- u8 reg;
- int i, rc;
-
- reg = winbond_readcfg(port, 0x81);
- reg |= 0x80; /* jumpered mode off */
- winbond_writecfg(port, 0x81, reg);
- reg = winbond_readcfg(port, 0x83);
- reg |= 0xF0; /* local control */
- winbond_writecfg(port, 0x83, reg);
- reg = winbond_readcfg(port, 0x85);
- reg |= 0xF0; /* programmable timing */
- winbond_writecfg(port, 0x85, reg);
-
- reg = winbond_readcfg(port, 0x81);
-
- if (!(reg & 0x03)) /* Disabled */
- return -ENODEV;
-
- for (i = 0; i < 2 ; i ++) {
- unsigned long cmd_port = 0x1F0 - (0x80 * i);
- unsigned long ctl_port = cmd_port + 0x206;
- struct ata_host *host;
- struct ata_port *ap;
- void __iomem *cmd_addr, *ctl_addr;
-
- if (!(reg & (1 << i)))
- continue;
-
- pdev = platform_device_register_simple(DRV_NAME, nr_winbond_host, NULL, 0);
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
-
- rc = -ENOMEM;
- host = ata_host_alloc(&pdev->dev, 1);
- if (!host)
- goto err_unregister;
- ap = host->ports[0];
-
- rc = -ENOMEM;
- cmd_addr = devm_ioport_map(&pdev->dev, cmd_port, 8);
- ctl_addr = devm_ioport_map(&pdev->dev, ctl_port, 1);
- if (!cmd_addr || !ctl_addr)
- goto err_unregister;
-
- ata_port_desc(ap, "cmd 0x%lx ctl 0x%lx", cmd_port, ctl_port);
-
- ap->ops = &winbond_port_ops;
- ap->pio_mask = ATA_PIO4;
- ap->flags |= ATA_FLAG_SLAVE_POSS;
- ap->ioaddr.cmd_addr = cmd_addr;
- ap->ioaddr.altstatus_addr = ctl_addr;
- ap->ioaddr.ctl_addr = ctl_addr;
- ata_sff_std_ports(&ap->ioaddr);
-
- /* hook in a private data structure per channel */
- host->private_data = &winbond_data[nr_winbond_host];
- winbond_data[nr_winbond_host].config = port;
- winbond_data[nr_winbond_host].platform_dev = pdev;
-
- /* activate */
- rc = ata_host_activate(host, 14 + i, ata_sff_interrupt, 0,
- &winbond_sht);
- if (rc)
- goto err_unregister;
-
- winbond_host[nr_winbond_host++] = dev_get_drvdata(&pdev->dev);
- }
-
- return 0;
-
- err_unregister:
- platform_device_unregister(pdev);
- return rc;
-}
-
-/**
- * winbond_init - attach winbond interfaces
- *
- * Attach winbond IDE interfaces by scanning the ports it may occupy.
- */
-
-static __init int winbond_init(void)
-{
- static const unsigned long config[2] = { 0x130, 0x1B0 };
-
- int ct = 0;
- int i;
-
- if (probe_winbond == 0)
- return -ENODEV;
-
- /*
- * Check both base addresses
- */
-
- for (i = 0; i < 2; i++) {
- if (probe_winbond & (1<<i)) {
- int ret = 0;
- unsigned long port = config[i];
-
- if (request_region(port, 2, "pata_winbond")) {
- ret = winbond_init_one(port);
- if (ret <= 0)
- release_region(port, 2);
- else ct+= ret;
- }
- }
- }
- if (ct != 0)
- return 0;
- return -ENODEV;
-}
-
-static __exit void winbond_exit(void)
-{
- int i;
-
- for (i = 0; i < nr_winbond_host; i++) {
- ata_host_detach(winbond_host[i]);
- release_region(winbond_data[i].config, 2);
- platform_device_unregister(winbond_data[i].platform_dev);
- }
-}
-
-MODULE_AUTHOR("Alan Cox");
-MODULE_DESCRIPTION("low-level driver for Winbond VL ATA");
-MODULE_LICENSE("GPL");
-MODULE_VERSION(DRV_VERSION);
-
-module_init(winbond_init);
-module_exit(winbond_exit);
-
-module_param(probe_winbond, int, 0);
-
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_marvell: fix marvell_pre_reset() documentation
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_marvell.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_marvell.c
===================================================================
--- a/drivers/ata/pata_marvell.c
+++ b/drivers/ata/pata_marvell.c
@@ -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
*
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_ns87415.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_ns87415.c
===================================================================
--- a/drivers/ata/pata_ns87415.c
+++ b/drivers/ata/pata_ns87415.c
@@ -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,
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_ns87415: Power Management fix
Fix ->resume method to do chipset specific setup.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_ns87415.c | 32 +++++++++++++++++++++++++++-----
1 file changed, 27 insertions(+), 5 deletions(-)
Index: b/drivers/ata/pata_ns87415.c
===================================================================
--- a/drivers/ata/pata_ns87415.c
+++ b/drivers/ata/pata_ns87415.c
@@ -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
};
From: 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).
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_oldpiix.c | 88 +++++++++++++--------------------------------
1 file changed, 27 insertions(+), 61 deletions(-)
Index: b/drivers/ata/pata_oldpiix.c
===================================================================
--- a/drivers/ata/pata_oldpiix.c
+++ b/drivers/ata/pata_oldpiix.c
@@ -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 (struct
static 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);
}
/**
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_opti.c | 2 ++
1 file changed, 2 insertions(+)
Index: b/drivers/ata/pata_opti.c
===================================================================
--- a/drivers/ata/pata_opti.c
+++ b/drivers/ata/pata_opti.c
@@ -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)
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_pdc2027x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_pdc2027x.c
===================================================================
--- a/drivers/ata/pata_pdc2027x.c
+++ b/drivers/ata/pata_pdc2027x.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_pdc2027x.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
Index: b/drivers/ata/pata_pdc2027x.c
===================================================================
--- a/drivers/ata/pata_pdc2027x.c
+++ b/drivers/ata/pata_pdc2027x.c
@@ -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.
*/
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_pdc202xx_old.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/ata/pata_pdc202xx_old.c
===================================================================
--- a/drivers/ata/pata_pdc202xx_old.c
+++ b/drivers/ata/pata_pdc202xx_old.c
@@ -240,7 +240,7 @@ static int pdc2026x_port_start(struct at
u8 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,
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_pdc202xx_old: Power Management fix
Enable burst mode on resume for PDC2026x controllers.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_pdc202xx_old.c | 33 +++++++++++++++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)
Index: b/drivers/ata/pata_pdc202xx_old.c
===================================================================
--- a/drivers/ata/pata_pdc202xx_old.c
+++ b/drivers/ata/pata_pdc202xx_old.c
@@ -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
};
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
Index: b/drivers/ata/Kconfig
===================================================================
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -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
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_radisys: fix UDMA handling
Set correct bits to switch between UDMA2 and UDMA4.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_radisys.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/ata/pata_radisys.c
===================================================================
--- a/drivers/ata/pata_radisys.c
+++ b/drivers/ata/pata_radisys.c
@@ -139,9 +139,9 @@ static void radisys_set_dmamode (struct
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);
From: 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).
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
===================================================================
--- a/drivers/ata/pata_radisys.c
+++ b/drivers/ata/pata_radisys.c
@@ -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 (struct
static 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 */
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_rdc.c | 99 ++++++++++++++++---------------------------------
1 file changed, 33 insertions(+), 66 deletions(-)
Index: b/drivers/ata/pata_rdc.c
===================================================================
--- a/drivers/ata/pata_rdc.c
+++ b/drivers/ata/pata_rdc.c
@@ -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_p
static 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 = {
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_rz1000.c | 2 ++
1 file changed, 2 insertions(+)
Index: b/drivers/ata/pata_rz1000.c
===================================================================
--- a/drivers/ata/pata_rz1000.c
+++ b/drivers/ata/pata_rz1000.c
@@ -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)
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_rz1000.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
Index: b/drivers/ata/pata_rz1000.c
===================================================================
--- a/drivers/ata/pata_rz1000.c
+++ b/drivers/ata/pata_rz1000.c
@@ -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
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_sc1200.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_sc1200.c
===================================================================
--- a/drivers/ata/pata_sc1200.c
+++ b/drivers/ata/pata_sc1200.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_scc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_scc.c
===================================================================
--- a/drivers/ata/pata_scc.c
+++ b/drivers/ata/pata_scc.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_scc.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
Index: b/drivers/ata/pata_scc.c
===================================================================
--- a/drivers/ata/pata_scc.c
+++ b/drivers/ata/pata_scc.c
@@ -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,
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_sch: add 32-bit PIO support
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_sch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_sch.c
===================================================================
--- a/drivers/ata/pata_sch.c
+++ b/drivers/ata/pata_sch.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_serverworks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_serverworks.c
===================================================================
--- a/drivers/ata/pata_serverworks.c
+++ b/drivers/ata/pata_serverworks.c
@@ -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,
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_serverworks: use standard cable detection methods
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_serverworks.c | 45 ++++++++++-------------------------------
1 file changed, 12 insertions(+), 33 deletions(-)
Index: b/drivers/ata/pata_serverworks.c
===================================================================
--- a/drivers/ata/pata_serverworks.c
+++ b/drivers/ata/pata_serverworks.c
@@ -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 *ap
return 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 },
{ }
};
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_serverworks: add serverworks_fixup()
Factor out common code from serverworks_[re]init_one() to
serverworks_fixup().
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_serverworks.c | 57 ++++++++++++++++++++---------------------
1 file changed, 29 insertions(+), 28 deletions(-)
Index: b/drivers/ata/pata_serverworks.c
===================================================================
--- a/drivers/ata/pata_serverworks.c
+++ b/drivers/ata/pata_serverworks.c
@@ -371,6 +371,31 @@ static void serverworks_fixup_ht1000(str
pci_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 p
if (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(struct
if (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;
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_sl82c105.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_sl82c105.c
===================================================================
--- a/drivers/ata/pata_sl82c105.c
+++ b/drivers/ata/pata_sl82c105.c
@@ -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,
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_sl82c105.c | 37 ++++++++++++++++++++++++++++++++-----
1 file changed, 32 insertions(+), 5 deletions(-)
Index: b/drivers/ata/pata_sl82c105.c
===================================================================
--- a/drivers/ata/pata_sl82c105.c
+++ b/drivers/ata/pata_sl82c105.c
@@ -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(stru
return 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)
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_sis.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/ata/pata_sis.c
===================================================================
--- a/drivers/ata/pata_sis.c
+++ b/drivers/ata/pata_sis.c
@@ -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,
};
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_sis: Power Management fix
Call sis_fixup() on resume.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_sis.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
Index: b/drivers/ata/pata_sis.c
===================================================================
--- a/drivers/ata/pata_sis.c
+++ b/drivers/ata/pata_sis.c
@@ -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_dev
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 */
@@ -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
};
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_triflex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_triflex.c
===================================================================
--- a/drivers/ata/pata_triflex.c
+++ b/drivers/ata/pata_triflex.c
@@ -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,
From: 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. ]
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/libata-sff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/libata-sff.c
===================================================================
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -838,7 +838,7 @@ unsigned int ata_sff_data_xfer_noirq(str
unsigned 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;
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_via.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ata/pata_via.c
===================================================================
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -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,
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_via: clear UDMA transfer mode bit for PIO and MWDMA
Fix register naming while at it.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_via.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
Index: b/drivers/ata/pata_via.c
===================================================================
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -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);
}
}
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] pata_via: add via_fixup()
Factor out common code from via_[re]init_one() to via_fixup().
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_via.c | 53 +++++++++++++++++++++----------------------------
1 file changed, 23 insertions(+), 30 deletions(-)
Index: b/drivers/ata/pata_via.c
===================================================================
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -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;
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] libata: add ata_mwdma_to_pio() inline helper
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
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(-)
Index: b/drivers/ata/ata_piix.c
===================================================================
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -831,16 +831,9 @@ static void do_pata_set_dmamode(struct a
pci_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);
}
/**
Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -176,13 +176,7 @@ static void efar_set_dmamode (struct ata
pci_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);
}
Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -186,13 +186,7 @@ static void it8213_set_dmamode (struct a
pci_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);
}
Index: b/drivers/ata/pata_oldpiix.c
===================================================================
--- a/drivers/ata/pata_oldpiix.c
+++ b/drivers/ata/pata_oldpiix.c
@@ -135,14 +135,7 @@ static void oldpiix_set_piomode(struct a
static 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);
}
/**
Index: b/drivers/ata/pata_radisys.c
===================================================================
--- a/drivers/ata/pata_radisys.c
+++ b/drivers/ata/pata_radisys.c
@@ -102,18 +102,12 @@ static void radisys_set_dmamode (struct
struct 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 {
Index: b/drivers/ata/pata_rdc.c
===================================================================
--- a/drivers/ata/pata_rdc.c
+++ b/drivers/ata/pata_rdc.c
@@ -227,16 +227,9 @@ static void rdc_set_dmamode(struct ata_p
pci_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 = {
Index: b/include/linux/ata.h
===================================================================
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -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__ */
From: 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
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(-)
Index: b/drivers/ata/libata-core.c
===================================================================
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6426,9 +6426,17 @@ int ata_pci_device_resume(struct pci_dev
int 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 */
Index: b/drivers/ata/libata-sff.c
===================================================================
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -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);
Index: b/drivers/ata/pata_ali.c
===================================================================
--- a/drivers/ata/pata_ali.c
+++ b/drivers/ata/pata_ali.c
@@ -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
};
Index: b/drivers/ata/pata_amd.c
===================================================================
--- a/drivers/ata/pata_amd.c
+++ b/drivers/ata/pata_amd.c
@@ -455,6 +455,20 @@ static void amd_clear_fifo(struct pci_de
pci_write_config_byte(pdev, 0x41, fifo);
}
+static int amd_fixup(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ if (pdev->vendor == PCI_VENDOR_ID_AMD) {
+ amd_clear_fifo(pdev);
+ if (pdev->device == PCI_DEVICE_ID_AMD_VIPER_7409 ||
+ pdev->device == PCI_DEVICE_ID_AMD_COBRA_7401)
+ ata_pci_bmdma_clear_simplex(pdev);
+ }
+
+ return 0;
+}
+
static int amd_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
{
static const struct ata_port_info info[10] = {
@@ -559,10 +573,8 @@ static int amd_init_one(struct pci_dev *
*/
ppi[0] = &info[type];
- if (type < 3)
- ata_pci_bmdma_clear_simplex(pdev);
- if (pdev->vendor == PCI_VENDOR_ID_AMD)
- amd_clear_fifo(pdev);
+ amd_fixup(&pdev->dev);
+
/* Cable detection on Nvidia chips doesn't work too well,
* cache BIOS programmed UDMA mode.
*/
@@ -574,30 +586,9 @@ static int amd_init_one(struct pci_dev *
}
/* And fire it up */
- return ata_pci_sff_init_one(pdev, ppi, &amd_sht, hpriv);
+ return __ata_pci_sff_init_one(pdev, ppi, &amd_sht, hpriv, amd_fixup);
}
-#ifdef CONFIG_PM
-static int amd_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 (pdev->vendor == PCI_VENDOR_ID_AMD) {
- amd_clear_fifo(pdev);
- if (pdev->device == PCI_DEVICE_ID_AMD_VIPER_7409 ||
- pdev->device == PCI_DEVICE_ID_AMD_COBRA_7401)
- ata_pci_bmdma_clear_simplex(pdev);
- }
- ata_host_resume(host);
- return 0;
-}
-#endif
-
static const struct pci_device_id amd[] = {
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_COBRA_7401), 0 },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_VIPER_7409), 1 },
@@ -630,7 +621,7 @@ static struct pci_driver amd_pci_driver
.remove = ata_pci_remove_one,
#ifdef CONFIG_PM
.suspend = ata_pci_device_suspend,
- .resume = amd_reinit_one,
+ .resume = ata_pci_device_resume,
#endif
};
Index: b/drivers/ata/pata_artop.c
===================================================================
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -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_dev
pci_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_de
BUG_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
};
Index: b/drivers/ata/pata_cmd640.c
===================================================================
--- a/drivers/ata/pata_cmd640.c
+++ b/drivers/ata/pata_cmd640.c
@@ -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(struct
pci_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_de
if (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
};
Index: b/drivers/ata/pata_cmd64x.c
===================================================================
--- a/drivers/ata/pata_cmd64x.c
+++ b/drivers/ata/pata_cmd64x.c
@@ -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
};
Index: b/drivers/ata/pata_cs5530.c
===================================================================
--- a/drivers/ata/pata_cs5530.c
+++ b/drivers/ata/pata_cs5530.c
@@ -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_de
return 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
};
Index: b/drivers/ata/pata_hpt366.c
===================================================================
--- a/drivers/ata/pata_hpt366.c
+++ b/drivers/ata/pata_hpt366.c
@@ -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 p
pci_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_de
if (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_de
break;
}
/* 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
};
Index: b/drivers/ata/pata_hpt3x3.c
===================================================================
--- a/drivers/ata/pata_hpt3x3.c
+++ b/drivers/ata/pata_hpt3x3.c
@@ -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 p
pci_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_de
int 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
};
Index: b/drivers/ata/pata_it821x.c
===================================================================
--- a/drivers/ata/pata_it821x.c
+++ b/drivers/ata/pata_it821x.c
@@ -868,6 +868,15 @@ static void it821x_disable_raid(struct p
pci_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_de
else
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
};
Index: b/drivers/ata/pata_ninja32.c
===================================================================
--- a/drivers/ata/pata_ninja32.c
+++ b/drivers/ata/pata_ninja32.c
@@ -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 __iomem
iowrite8(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_d
ata_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
};
Index: b/drivers/ata/pata_ns87415.c
===================================================================
--- a/drivers/ata/pata_ns87415.c
+++ b/drivers/ata/pata_ns87415.c
@@ -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
};
Index: b/drivers/ata/pata_pdc2027x.c
===================================================================
--- a/drivers/ata/pata_pdc2027x.c
+++ b/drivers/ata/pata_pdc2027x.c
@@ -63,7 +63,6 @@ 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);
@@ -129,7 +128,7 @@ static struct pci_driver pdc2027x_pci_dr
.remove = ata_pci_remove_one,
#ifdef CONFIG_PM
.suspend = ata_pci_device_suspend,
- .resume = pdc2027x_reinit_one,
+ .resume = ata_pci_device_resume,
#endif
};
@@ -647,13 +646,21 @@ static long pdc_detect_pll_input_clock(s
/**
* pdc_hardware_init - Initialize the hardware.
- * @host: target ATA host
- * @board_idx: board identifier
+ * @dev: device
*/
-static int pdc_hardware_init(struct ata_host *host, unsigned int board_idx)
+static int pdc_hardware_init(struct device *dev)
{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct ata_host *host = dev_get_drvdata(dev);
+ unsigned int board_idx;
long pll_clock;
+ 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;
+
/*
* Detect PLL input clock rate.
* On some system, where PCI bus is running at non-standard clock rate.
@@ -722,6 +729,8 @@ static int __devinit pdc2027x_init_one(s
if (!host)
return -ENOMEM;
+ host->init_host = pdc_hardware_init;
+
/* acquire resources and fill host */
rc = pcim_enable_device(pdev);
if (rc)
@@ -755,7 +764,7 @@ static int __devinit pdc2027x_init_one(s
//pci_enable_intx(pdev);
/* initialize adapter */
- if (pdc_hardware_init(host, board_idx) != 0)
+ if (pdc_hardware_init(&pdev->dev))
return -EIO;
pci_set_master(pdev);
@@ -763,31 +772,6 @@ 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.
*/
Index: b/drivers/ata/pata_sl82c105.c
===================================================================
--- a/drivers/ata/pata_sl82c105.c
+++ b/drivers/ata/pata_sl82c105.c
@@ -279,13 +279,16 @@ static int sl82c105_bridge_revision(stru
return 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
};
Index: b/drivers/ata/sata_sil.c
===================================================================
--- a/drivers/ata/sata_sil.c
+++ b/drivers/ata/sata_sil.c
@@ -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 a
writel(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);
Index: b/include/linux/libata.h
===================================================================
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -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(stru
extern 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 */
/**
On Wed, 25 Nov 2009 18:02:39 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: 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.
Allowing or defaulting too ?
From: 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}.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
include/linux/libata.h | 1 +
1 file changed, 1 insertion(+)
Index: b/include/linux/libata.h
===================================================================
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -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;
On Wed, 25 Nov 2009 18:03:44 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Subject: [PATCH] pata_atiixp: add proper ->prereset method
>
The original seems cleaner here.
On Wednesday 25 November 2009 06:12:42 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:02:39 +0100
> Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > From: 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.
>
> 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
On 11/25/2009 12:02 PM, Bartlomiej Zolnierkiewicz wrote:
> 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!
> - 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...
> - 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
On Wednesday 25 November 2009 06:19:49 pm Jeff Garzik wrote:
> On 11/25/2009 12:02 PM, Bartlomiej Zolnierkiewicz wrote:
> > 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!
>
> > - 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.
For review & testing purposes it is better do it this way, I can merge
individual patches easily later if desirable.
> I'll let the comments from Alan and others trickle in before applying...
See comment above.
> > - 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
> 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.
Probably better to do the reverse to match the docs ?
> - 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
On Wed, 25 Nov 2009 18:04:15 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Subject: [PATCH] pata_efar: MWDMA0 is unsupported
>
> 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.
On Wed, 25 Nov 2009 18:03:23 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: 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.
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.
On Wed, 25 Nov 2009 18:04:36 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: 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.
Umm. its a) under CONFIG_PCI, and b) says CMD640 PCI IDE...
On Wed, 25 Nov 2009 18:05:11 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: 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.
Agreed entirely. SIL680 VDMA might be worth doing and in turn CS5520 in
passing but CS5520 is mostly an ex-chip
On Wed, 25 Nov 2009 18:07:40 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: 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.
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.
> This is a forward port of bugfix from IDE ide-generic host driver.
Of a bug.
Alan
On Wednesday 25 November 2009 06:25:41 pm Alan Cox wrote:
> > 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.
>
> Probably better to do the reverse to match the docs ?
It just matches ata_piix.c code currently.
> > - 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. ]
> 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).
> 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
On Wednesday 25 November 2009 06:26:33 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:04:36 +0100
> Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > From: 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.
>
> 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
On Wed, 25 Nov 2009 18:03:37 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: 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.
This comes from the original ATI code so should be double checked with
ATI but seems reasonable if it works.
On 11/25/2009 12:26 PM, Alan Cox wrote:
> On Wed, 25 Nov 2009 18:04:36 +0100
> Bartlomiej Zolnierkiewicz<[email protected]> wrote:
>
>> From: 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.
>
> 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
> + * 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.
On Wed, 25 Nov 2009 18:08:23 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: 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.
Just delete it nobody will care. I sent Jeff patches to delete it a
couple of times before but they got dropped
On Wednesday 25 November 2009 06:37:19 pm Jeff Garzik wrote:
> On 11/25/2009 12:26 PM, Alan Cox wrote:
> > On Wed, 25 Nov 2009 18:04:36 +0100
> > Bartlomiej Zolnierkiewicz<[email protected]> wrote:
> >
> >> From: 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.
> >
> > 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
On Wednesday 25 November 2009 06:38:52 pm Alan Cox wrote:
> > + * 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
On Wednesday 25 November 2009 06:32:15 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:07:40 +0100
> Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > From: 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.
>
> 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.
> 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.
OTOH We had. :)
--
Bartlomiej Zolnierkiewicz
On Wed, 25 Nov 2009 18:09:48 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: 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.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
> ---
> drivers/ata/Kconfig | 4 ++++
> 1 file changed, 4 insertions(+)
>
> Index: b/drivers/ata/Kconfig
> ===================================================================
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -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.
On Wed, 25 Nov 2009 18:10:39 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: 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.
NAK; Read the code - it uses its own private data_xfer handler anyway
On Wednesday 25 November 2009 06:48:44 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:10:39 +0100
> Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > From: 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.
>
> NAK; Read the code - it uses its own private data_xfer handler anyway
Ah, this one can be indeed dropped.
--
Bartlomiej Zolnierkiewicz
On 11/25/2009 12:46 PM, Alan Cox wrote:
> On Wed, 25 Nov 2009 18:09:48 +0100
> Bartlomiej Zolnierkiewicz<[email protected]> wrote:
>
>> From: 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.
>>
>> Signed-off-by: Bartlomiej Zolnierkiewicz<[email protected]>
>> ---
>> drivers/ata/Kconfig | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> Index: b/drivers/ata/Kconfig
>> ===================================================================
>> --- a/drivers/ata/Kconfig
>> +++ b/drivers/ata/Kconfig
>> @@ -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 ?
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
On Wednesday 25 November 2009 06:50:26 pm Jeff Garzik wrote:
> On 11/25/2009 12:46 PM, Alan Cox wrote:
> > On Wed, 25 Nov 2009 18:09:48 +0100
> > Bartlomiej Zolnierkiewicz<[email protected]> wrote:
> >
> >> From: 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.
> >>
> >> Signed-off-by: Bartlomiej Zolnierkiewicz<[email protected]>
> >> ---
> >> drivers/ata/Kconfig | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >>
> >> Index: b/drivers/ata/Kconfig
> >> ===================================================================
> >> --- a/drivers/ata/Kconfig
> >> +++ b/drivers/ata/Kconfig
> >> @@ -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 ?
>
> 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
> /* 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.
On Wed, 25 Nov 2009 18:12:40 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: 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().
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
On Wed, 25 Nov 2009 18:12:48 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> From: 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}.
Do we need it for anything yet - whoever first needs it can add it,
otherwise its just waste.
On Wednesday 25 November 2009 06:52:57 pm Alan Cox wrote:
> > /* 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.
> 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.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ata/pata_via.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
Index: b/drivers/ata/pata_via.c
===================================================================
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -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
On Wed, 25 Nov 2009 18:18:18 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> On Wednesday 25 November 2009 06:12:42 pm Alan Cox wrote:
> > On Wed, 25 Nov 2009 18:02:39 +0100
> > Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> >
> > > From: 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.
> >
> > 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
Summary would be lots of really good stuff and review.
> 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.
On Wednesday 25 November 2009 06:56:50 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:12:48 +0100
> Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > From: 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}.
>
> 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
On 11/25/2009 12:52 PM, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 25 November 2009 06:50:26 pm Jeff Garzik wrote:
>> On 11/25/2009 12:46 PM, Alan Cox wrote:
>>> On Wed, 25 Nov 2009 18:09:48 +0100
>>> Bartlomiej Zolnierkiewicz<[email protected]> wrote:
>>>
>>>> From: 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.
>>>>
>>>> Signed-off-by: Bartlomiej Zolnierkiewicz<[email protected]>
>>>> ---
>>>> drivers/ata/Kconfig | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> Index: b/drivers/ata/Kconfig
>>>> ===================================================================
>>>> --- a/drivers/ata/Kconfig
>>>> +++ b/drivers/ata/Kconfig
>>>> @@ -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 ?
>>
>> 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.
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
> Do you really find such tidy patch hard to review?
When doing it at speed - yes.
> /* 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.
> 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
On Wednesday 25 November 2009 07:06:48 pm Alan Cox wrote:
> > 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
> > 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
> 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.
On Wed, 25 Nov 2009 18:44:59 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> On Wednesday 25 November 2009 06:38:52 pm Alan Cox wrote:
> > > + * 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.
On Wed, 25 Nov 2009 18:34:04 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> On Wednesday 25 November 2009 06:26:33 pm Alan Cox wrote:
> > On Wed, 25 Nov 2009 18:04:36 +0100
> > Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> >
> > > From: 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.
> >
> > 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?
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 !
On Wed, 25 Nov 2009 19:02:44 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> On Wednesday 25 November 2009 06:56:50 pm Alan Cox wrote:
> > On Wed, 25 Nov 2009 18:12:48 +0100
> > Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> >
> > > From: 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}.
> >
> > 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
On Wednesday 25 November 2009 07:12:05 pm Alan Cox wrote:
> > > 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.
> > 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).
> 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.
> - 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.
> 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.
Agreed on this one.
--
Bartlomiej Zolnierkiewicz
On Wednesday 25 November 2009 07:12:53 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:44:59 +0100
> Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > On Wednesday 25 November 2009 06:38:52 pm Alan Cox wrote:
> > > > + * 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.
I disagree. The code from back then is not the same code as today and we
have git log --follow for this.
--
Bartlomiej Zolnierkiewicz
On Wednesday 25 November 2009 07:04:20 pm Jeff Garzik wrote:
> On 11/25/2009 12:52 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 25 November 2009 06:50:26 pm Jeff Garzik wrote:
> >> On 11/25/2009 12:46 PM, Alan Cox wrote:
> >>> On Wed, 25 Nov 2009 18:09:48 +0100
> >>> Bartlomiej Zolnierkiewicz<[email protected]> wrote:
> >>>
> >>>> From: 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.
> >>>>
> >>>> Signed-off-by: Bartlomiej Zolnierkiewicz<[email protected]>
> >>>> ---
> >>>> drivers/ata/Kconfig | 4 ++++
> >>>> 1 file changed, 4 insertions(+)
> >>>>
> >>>> Index: b/drivers/ata/Kconfig
> >>>> ===================================================================
> >>>> --- a/drivers/ata/Kconfig
> >>>> +++ b/drivers/ata/Kconfig
> >>>> @@ -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 ?
> >>
> >> 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.
>
> 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
On Wed, 25 Nov 2009 19:10:06 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> On Wednesday 25 November 2009 07:06:48 pm Alan Cox wrote:
> > > 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...
On Wednesday 25 November 2009 08:34:19 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 19:10:06 +0100
> Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > On Wednesday 25 November 2009 07:06:48 pm Alan Cox wrote:
> > > > 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...
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
On 11/25/2009 01:29 PM, Bartlomiej Zolnierkiewicz wrote:
> 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).
The important thing is taking two minutes to write a relevant comment,
not determining who is wearing a crown on his head.
Jeff
On Wednesday 25 November 2009 09:38:27 pm Jeff Garzik wrote:
> On 11/25/2009 01:29 PM, Bartlomiej Zolnierkiewicz wrote:
> > 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).
>
>
> 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.
> 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
On 11/25/2009 05:02 PM, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 25 November 2009 09:38:27 pm Jeff Garzik wrote:
>> On 11/25/2009 01:29 PM, Bartlomiej Zolnierkiewicz wrote:
>>> 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).
>>
>>
>> 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.
You don't need to be the author or maintainer of a driver to submit changes.
Jeff
On Thursday 26 November 2009 04:14:58 am Jeff Garzik wrote:
> On 11/25/2009 05:02 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 25 November 2009 09:38:27 pm Jeff Garzik wrote:
> >> On 11/25/2009 01:29 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> 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).
> >>
> >>
> >> 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.
>
> 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
On Wednesday 25 November 2009 06:25:52 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:04:15 +0100
> Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > From: Bartlomiej Zolnierkiewicz <[email protected]>
> > Subject: [PATCH] pata_efar: MWDMA0 is unsupported
> >
> > 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.
--
Bartlomiej Zolnierkiewicz
Hello.
Bartlomiej Zolnierkiewicz wrote:
> 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
> ===================================================================
> --- a/drivers/ata/pata_it8213.c
> +++ b/drivers/ata/pata_it8213.c
> @@ -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 */
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
On Thu, 26 Nov 2009 15:53:58 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> On Wednesday 25 November 2009 06:25:52 pm Alan Cox wrote:
> > On Wed, 25 Nov 2009 18:04:15 +0100
> > Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> >
> > > From: Bartlomiej Zolnierkiewicz <[email protected]>
> > > Subject: [PATCH] pata_efar: MWDMA0 is unsupported
> > >
> > > 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.
Cool - I only have the original docs.
Hello, I wrote:
>> 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
>> ===================================================================
>> --- a/drivers/ata/pata_it8213.c
>> +++ b/drivers/ata/pata_it8213.c
>> @@ -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 */
> 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).
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
Hello.
Alan Cox wrote:
>>On Wednesday 25 November 2009 06:25:52 pm Alan Cox wrote:
>>>On Wed, 25 Nov 2009 18:04:15 +0100
>>>Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>>>>From: Bartlomiej Zolnierkiewicz <[email protected]>
>>>>Subject: [PATCH] pata_efar: MWDMA0 is unsupported
>>>>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.
> Cool - I only have the original docs.
Hm, me too... perhaps worth putting in Jeff's documentation archive?
MBR, Sergei
On Thursday 26 November 2009 04:17:51 pm Sergei Shtylyov wrote:
> Hello, I wrote:
>
> >> 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
> >> ===================================================================
> >> --- a/drivers/ata/pata_it8213.c
> >> +++ b/drivers/ata/pata_it8213.c
> >> @@ -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 */
>
> > 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).
>
> 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).
> 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
On Thursday 26 November 2009 04:33:13 pm Sergei Shtylyov wrote:
> Hello.
>
> Alan Cox wrote:
>
> >>On Wednesday 25 November 2009 06:25:52 pm Alan Cox wrote:
>
> >>>On Wed, 25 Nov 2009 18:04:15 +0100
> >>>Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> >>>>From: Bartlomiej Zolnierkiewicz <[email protected]>
> >>>>Subject: [PATCH] pata_efar: MWDMA0 is unsupported
>
> >>>>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.
>
> > 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
Hello.
Bartlomiej Zolnierkiewicz wrote:
>>>>>>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.
>>>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...
> --
> Bartlomiej Zolnierkiewicz
MBR, Sergei
On Thursday 26 November 2009 05:17:00 pm Sergei Shtylyov wrote:
> Hello.
>
> Bartlomiej Zolnierkiewicz wrote:
>
> >>>>>>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.
>
> >>>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
Bartlomiej Zolnierkiewicz wrote:
>>>>>>>>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.
>>>>>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
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. :-)
> --
> Bartlomiej Zolnierkiewicz
WBR, Sergei
Hello.
Bartlomiej Zolnierkiewicz wrote:
>>Hello, I wrote:
>>>>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
>>>>===================================================================
>>>>--- a/drivers/ata/pata_it8213.c
>>>>+++ b/drivers/ata/pata_it8213.c
>>>>@@ -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 */
>>> 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).
>> 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... :-)
> 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...
> 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)?
>> 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! :-)
> officially claims to support UDMA6) and pata_it8213 behavior now matches
> the behavior of it8213 host driver.
OK, fine then...
> 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... :-)
> --
> Bartlomiej Zolnierkiewicz
MBR, Sergei
Bartlomiej Zolnierkiewicz wrote:
> 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
> ===================================================================
> --- a/drivers/ata/pata_it8213.c
> +++ b/drivers/ata/pata_it8213.c
> @@ -61,20 +61,9 @@ static int it8213_cable_detect(struct at
> return 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)
Perhaps 'set_mwdma' would be a better name...
> {
> - 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)
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.
> 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))
Parens not needed...
> + /* Enable DMA timing only */
> + control |= 8; /* PIO cycles in PIO0 */
>
> pci_read_config_word(dev, master_port, &master_data);
MBR, Sergei
Bartlomiej Zolnierkiewicz wrote:
> 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
> ===================================================================
> --- a/drivers/ata/pata_radisys.c
> +++ b/drivers/ata/pata_radisys.c
> @@ -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. */
Multi-line comment style should preferrably be:
/*
* blah
* blah
*/
> + if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio))
> + control = 1;
Hm, shouldn't that be 8?
> @@ -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
Hello.
Bartlomiej Zolnierkiewicz wrote:
> 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
> ===================================================================
> --- a/drivers/ata/pata_artop.c
> +++ b/drivers/ata/pata_artop.c
> @@ -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
[...]
> @@ -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.
> ultra |= (mode << (2 * dn));
> @@ -261,7 +248,7 @@ static void atp86x_set_dmamode(struct at
> pci_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
Bartlomiej Zolnierkiewicz wrote:
> 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
> ===================================================================
> --- a/drivers/ata/pata_artop.c
> +++ b/drivers/ata/pata_artop.c
[...]
> @@ -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);
Space not needed between ~ and 0x30...
MBR, Sergei
On 11/25/2009 12:12 PM, Bartlomiej Zolnierkiewicz wrote:
> From: 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}.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz<[email protected]>
> ---
> include/linux/libata.h | 1 +
> 1 file changed, 1 insertion(+)
>
> Index: b/include/linux/libata.h
> ===================================================================
> --- a/include/linux/libata.h
> +++ b/include/linux/libata.h
> @@ -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.
On 11/25/2009 12:02 PM, Bartlomiej Zolnierkiewicz wrote:
> 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
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
On Thursday 03 December 2009 09:04:40 am Jeff Garzik wrote:
> On 11/25/2009 12:12 PM, Bartlomiej Zolnierkiewicz wrote:
> > From: 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}.
> >
> > Signed-off-by: Bartlomiej Zolnierkiewicz<[email protected]>
> > ---
> > include/linux/libata.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > Index: b/include/linux/libata.h
> > ===================================================================
> > --- a/include/linux/libata.h
> > +++ b/include/linux/libata.h
> > @@ -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.
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
On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> On 11/25/2009 12:02 PM, Bartlomiej Zolnierkiewicz wrote:
> > 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
>
> 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.
> 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
> 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"
> 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
On 12/03/2009 11:59 AM, Alan Cox wrote:
>> 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).
> 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.
Agreed mostly... I still want to push fixes even if for obscure hardware.
Jeff
On 11/25/2009 12:12 PM, Bartlomiej Zolnierkiewicz wrote:
> From: 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}.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz<[email protected]>
> ---
> include/linux/libata.h | 1 +
> 1 file changed, 1 insertion(+)
>
> Index: b/include/linux/libata.h
> ===================================================================
> --- a/include/linux/libata.h
> +++ b/include/linux/libata.h
> @@ -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
On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>> 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.
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
On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> >> 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.
>
> 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):
> 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(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 676f08b..25cb4e7 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -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
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 9ac4e37..0c6155f 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -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)
diff --git a/drivers/ata/pata_cs5520.c b/drivers/ata/pata_cs5520.c
index 0df83cf..95ebdac 100644
--- a/drivers/ata/pata_cs5520.c
+++ b/drivers/ata/pata_cs5520.c
@@ -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)
diff --git a/drivers/ata/pata_efar.c b/drivers/ata/pata_efar.c
index 2a6412f..b2e71e6 100644
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -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,
};
diff --git a/drivers/ata/pata_hpt3x2n.c b/drivers/ata/pata_hpt3x2n.c
index d30da80..9a09a1b 100644
--- a/drivers/ata/pata_hpt3x2n.c
+++ b/drivers/ata/pata_hpt3x2n.c
@@ -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 }
};
/**
diff --git a/drivers/ata/pata_hpt3x3.c b/drivers/ata/pata_hpt3x3.c
index 7e31025..c86c716 100644
--- a/drivers/ata/pata_hpt3x3.c
+++ b/drivers/ata/pata_hpt3x3.c
@@ -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
diff --git a/drivers/ata/pata_it8213.c b/drivers/ata/pata_it8213.c
index f156da8..8f3325a 100644
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -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 *en
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, /* FIXME: want UDMA 100? */
.port_ops = &it8213_ops,
};
diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index 6932e56..9df1ff7 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -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,
};
diff --git a/drivers/ata/pata_marvell.c b/drivers/ata/pata_marvell.c
index 2096fb7..950da39 100644
--- a/drivers/ata/pata_marvell.c
+++ b/drivers/ata/pata_marvell.c
@@ -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
*
diff --git a/drivers/ata/pata_ns87415.c b/drivers/ata/pata_ns87415.c
index 773b159..061aa1c 100644
--- a/drivers/ata/pata_ns87415.c
+++ b/drivers/ata/pata_ns87415.c
@@ -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 *e
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 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
};
diff --git a/drivers/ata/pata_oldpiix.c b/drivers/ata/pata_oldpiix.c
index 84ac503..9a8687d 100644
--- a/drivers/ata/pata_oldpiix.c
+++ b/drivers/ata/pata_oldpiix.c
@@ -239,7 +239,7 @@ static int oldpiix_init_one (struct pci_dev *pdev, const struct pci_device_id *e
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,
.port_ops = &oldpiix_pata_ops,
};
const struct ata_port_info *ppi[] = { &info, NULL };
diff --git a/drivers/ata/pata_radisys.c b/drivers/ata/pata_radisys.c
index 4401b33..4fd25e7 100644
--- a/drivers/ata/pata_radisys.c
+++ b/drivers/ata/pata_radisys.c
@@ -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);
diff --git a/drivers/ata/pata_rdc.c b/drivers/ata/pata_rdc.c
index c843a1e..237a24d 100644
--- a/drivers/ata/pata_rdc.c
+++ b/drivers/ata/pata_rdc.c
@@ -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,
};
diff --git a/drivers/ata/pata_rz1000.c b/drivers/ata/pata_rz1000.c
index a5e4dfe..2932998 100644
--- a/drivers/ata/pata_rz1000.c
+++ b/drivers/ata/pata_rz1000.c
@@ -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
diff --git a/drivers/ata/pata_sis.c b/drivers/ata/pata_sis.c
index d70ecec..8af0dc8 100644
--- a/drivers/ata/pata_sis.c
+++ b/drivers/ata/pata_sis.c
@@ -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
};
diff --git a/drivers/ata/pata_via.c b/drivers/ata/pata_via.c
index 78eac27..0d97890 100644
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -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);
}
}
diff --git a/drivers/ide/ide-pci-generic.c b/drivers/ide/ide-pci-generic.c
index 3f0bc42..a743e68 100644
--- a/drivers/ide/ide-pci-generic.c
+++ b/drivers/ide/ide-pci-generic.c
@@ -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
On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>>>> 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.
>>
>> 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):
>
>> 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.
> 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
On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
> >> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> >>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> >>>> 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.
> >>
> >> 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):
> >
> >> 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.
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.
> > 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
On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>>>>>> 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.
>>>>
>>>> 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):
>>>
>>>> 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.
>
> 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.
>>> 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..
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
From: Jeff Garzik <[email protected]>
Date: Thu, 03 Dec 2009 12:39:48 -0500
> On 12/03/2009 11:59 AM, Alan Cox wrote:
>>> 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.
On 11/26/2009 10:15 AM, Alan Cox wrote:
> On Thu, 26 Nov 2009 15:53:58 +0100
> Bartlomiej Zolnierkiewicz<[email protected]> wrote:
>
>> On Wednesday 25 November 2009 06:25:52 pm Alan Cox wrote:
>>> On Wed, 25 Nov 2009 18:04:15 +0100
>>> Bartlomiej Zolnierkiewicz<[email protected]> wrote:
>>>
>>>> From: Bartlomiej Zolnierkiewicz<[email protected]>
>>>> Subject: [PATCH] pata_efar: MWDMA0 is unsupported
>>>>
>>>> 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.
>
> 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
On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote:
> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
> >> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
> >>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> >>>>>> 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.
> >>>>
> >>>> 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):
> >>>
> >>>> 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.
> >
> > 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.
> 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?
> 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.
> >>> 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..
>
> At the time you built atang-2.6.33, you were aware that those Kconfig
> changes were not wanted -at all-.
Why should I remember/care/worry about such details?
> 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
Alan,
Can you sanity check me on these?
> Bartlomiej Zolnierkiewicz (28):
> ide-pci-generic: build fix
ACK but skipped -- already applied myself
> ata_piix: fix MWDMA handling on PIIX3
applied
> pata_efar: fix wrong PIO timings being programmed
applied
> pata_efar: fix wrong MWDMA timings being programmed
applied
> pata_efar: MWDMA0 is unsupported
skipped, pending discussion (just sent email)
> pata_cmd640: document known issues
rejected, for reasons already explained
> pata_cs5520: remove dead VDMA support
applied
> pata_cypress: document known issues
rejected, for reasons already explained
> pata_hpt3x2n: fix overclocked MWDMA0 timing
skipped, pending discussion (just sent email)
> 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.
> pata_it8213: fix UDMA handling
applied
> pata_it8213: fix wrong PIO timings being programmed
applied
> pata_it8213: fix PIO2 underclocking
applied
> pata_it8213: fix wrong MWDMA timings being programmed
applied
> pata_it8213: fix it8213_pre_reset() documentation
applied
> pata_it8213: MWDMA0 is unsupported
skipped, pending discussion (just sent email)
> pata_legacy: fix QDI6580DP support
applied
> pata_legacy: fix access to control register for QDI6580
applied
> pata_legacy: add pointers to QDI65x0 documentation
applied. I did not think the file path issue raised was important
enough to warrant patch rejection.
> pata_marvell: fix marvell_pre_reset() documentation
applied
> pata_ns87415: Power Management fix
applied
> pata_oldpiix: MWDMA0 is unsupported
skipped -- Alan, Sergey, comments?
> pata_pdc202xx_old: document known issues
rejected, for reasons already explained
> pata_radisys: fix UDMA handling
applied
> pata_rdc: MWDMA0 is unsupported
skipped -- Alan, Sergey, comments?
> pata_rz1000: Power Management fix
applied
> pata_sis: Power Management fix
applied
> 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.
On 12/03/2009 04:01 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote:
>> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
>>>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
>>>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>>>>>>>> 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.
>>>>>>
>>>>>> 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):
>>>>>
>>>>>> 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.
>>>
>>> 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.
uhwhu? You brought up distributions.
>> 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?
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
On 12/03/2009 03:48 PM, David Miller wrote:
> From: Jeff Garzik<[email protected]>
> Date: Thu, 03 Dec 2009 12:39:48 -0500
>
>> On 12/03/2009 11:59 AM, Alan Cox wrote:
>>>> 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.
<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
> 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.
On Thursday 03 December 2009 10:16:15 pm Jeff Garzik wrote:
> > pata_efar: MWDMA0 is unsupported
>
> skipped, pending discussion (just sent email)
The discussion was there, you were not especially interested
(http://lkml.org/lkml/2009/11/26/343).
> > pata_hpt3x2n: fix overclocked MWDMA0 timing
>
> skipped, 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.
> > 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.
I prefer sticking to technical facts. ;)
Patch was posted to both mailing lists: http://lkml.org/lkml/2009/11/25/321
> > 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.
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
On 12/03/2009 04:42 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 10:16:15 pm Jeff Garzik wrote:
>
>>> pata_efar: MWDMA0 is unsupported
>>
>> skipped, 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.
>>> pata_hpt3x2n: fix overclocked MWDMA0 timing
>>
>> skipped, 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.
> There were no complains so I'm pretty sure Sergei was fine with it.
It was unclear, hence I sent email for clarification.
>>> 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.
>
> 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.
>>> 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.
>
> 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?
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
On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:
> >>> 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.
> >
> > 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?
>
> 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.
Indeed.
>From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon 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.
Acked-by: James Bottomley <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
---
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(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 71218d7..552ecae 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -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);
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 9e92107..a1a6e62 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -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
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index 841f460..0782900 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -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;
diff --git a/drivers/scsi/libsas/sas_scsi_host.c b/drivers/scsi/libsas/sas_scsi_host.c
index 7448387..1c558d3 100644
--- a/drivers/scsi/libsas/sas_scsi_host.c
+++ b/drivers/scsi/libsas/sas_scsi_host.c
@@ -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;
}
diff --git a/include/linux/libata.h b/include/linux/libata.h
index b6b8a7f..73b69c7 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -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 *);
--
1.6.4.2
--
Bartlomiej Zolnierkiewicz
On 12/03/2009 04:56 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:
>
>>>>> 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.
>>>
>>> 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?
>>
>> 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.
>
> Indeed.
>
> From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon 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.
>
> 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
Hello.
Jeff Garzik wrote:
>> pata_efar: MWDMA0 is unsupported
>
> skipped, 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.
>
>> pata_hpt3x2n: fix overclocked MWDMA0 timing
>
> skipped, pending discussion (just sent email)
Nothing to discuss either, this looks like a single digit typo to me...
>
>> pata_hpt3x3: Power Management fix
>
> applied, on a hope and a prayer (did not see this posted to mailing
> list?).
http://marc.info/?l=linux-ide&m=125916980522990
>
>> pata_it8213: MWDMA0 is unsupported
>
> skipped, pending discussion (just sent email)
Nothing to discuss...
> pata_oldpiix: MWDMA0 is unsupported
>
> skipped -- Alan, Sergey, comments?
Acked-by: Sergei Shtylyov <[email protected]>
>
>> pata_rdc: MWDMA0 is unsupported
>
> skipped -- Alan, Sergey, comments?
Acked-by: Sergei Shtylyov <[email protected]>
MBR, Sergei
On Thursday 03 December 2009 11:02:36 pm Jeff Garzik wrote:
> On 12/03/2009 04:56 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:
> >
> >>>>> 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.
> >>>
> >>> 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?
> >>
> >> 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.
> >
> > Indeed.
> >
> > From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon 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.
> >
> > 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().
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
On 12/03/2009 05:02 PM, Sergei Shtylyov wrote:
> Hello.
>
> Jeff Garzik wrote:
>
>>> pata_efar: MWDMA0 is unsupported
>>
>> skipped, 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.
>
>>
>>> pata_hpt3x2n: fix overclocked MWDMA0 timing
>>
>> skipped, pending discussion (just sent email)
>
>
> Nothing to discuss either, this looks like a single digit typo to me...
>
>>
>>> pata_hpt3x3: Power Management fix
>>
>> applied, on a hope and a prayer (did not see this posted to mailing
>> list?).
>
> http://marc.info/?l=linux-ide&m=125916980522990
Yeah, missed that. Bart provided a link, too.
>>> pata_it8213: MWDMA0 is unsupported
>>
>> skipped, 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
On 12/03/2009 05:06 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 11:02:36 pm Jeff Garzik wrote:
>> On 12/03/2009 04:56 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:
>>>
>>>>>>> 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.
>>>>>
>>>>> 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?
>>>>
>>>> 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.
>>>
>>> Indeed.
>>>
>>> From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon 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.
>>>
>>> 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().
>
> 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
On 12/03/2009 05:10 PM, Jeff Garzik wrote:
> 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
On Thursday 03 December 2009 11:10:51 pm Jeff Garzik wrote:
> On 12/03/2009 05:06 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 11:02:36 pm Jeff Garzik wrote:
> >> On 12/03/2009 04:56 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:
> >>>
> >>>>>>> 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.
> >>>>>
> >>>>> 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?
> >>>>
> >>>> 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.
> >>>
> >>> Indeed.
> >>>
> >>> From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon 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.
> >>>
> >>> 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().
> >
> > 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. ;)
> 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
>From ee9ccdf70163ca6408f6965e0fbc65baeac7312c Mon 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.
Signed-off-by: Jeff Garzik <[email protected]>
---
drivers/ata/sata_mv.c | 29 ++++++++++++++---------------
1 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index d40c41c..8a77a0a 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -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);
--
1.6.4.2
On 12/03/2009 05:23 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 11:10:51 pm Jeff Garzik wrote:
>> 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
On Thursday 03 December 2009 11:30:50 pm Jeff Garzik wrote:
> On 12/03/2009 05:23 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 11:10:51 pm Jeff Garzik wrote:
> >> 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.
> 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
On 12/03/2009 04:16 PM, Jeff Garzik wrote:
>> pata_efar: MWDMA0 is unsupported
>
> skipped, pending discussion (just sent email)
applied, after merging into a single "PIIX no MWDMA0" patch
>> pata_hpt3x2n: fix overclocked MWDMA0 timing
>
> skipped, pending discussion (just sent email)
applied
>> pata_it8213: MWDMA0 is unsupported
>
> skipped, pending discussion (just sent email)
applied
>> pata_oldpiix: MWDMA0 is unsupported
>
> skipped -- Alan, Sergey, comments?
applied, after merging into a single "PIIX no MWDMA0" patch
>> pata_rdc: MWDMA0 is unsupported
>
> skipped -- Alan, Sergey, comments?
applied, after merging into a single "PIIX no MWDMA0" patch
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.
> > pata_oldpiix: MWDMA0 is unsupported
>
> skipped -- 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.
Hello.
Bartlomiej Zolnierkiewicz wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Subject: [PATCH] libata: add ata_mwdma_to_pio() inline helper
> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
[...]
> static struct ata_port_operations rdc_pata_ops = {
> Index: b/include/linux/ata.h
> ===================================================================
> --- a/include/linux/ata.h
> +++ b/include/linux/ata.h
> @@ -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.
> + 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}?
> +
> + return needed_pio[mwdma] - XFER_PIO_0;
> +}
> +
> #endif /* __LINUX_ATA_H__ */
MBR, Sergei
On Thu, 3 Dec 2009, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote:
>> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
>>>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
>>>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>>>>>>>> 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.
>>>>>>
>>>>>> 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):
>>>>>
>>>>>> 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.
>>>
>>> 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.
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
On Saturday 12 December 2009 03:02:43 am [email protected] wrote:
> On Thu, 3 Dec 2009, Bartlomiej Zolnierkiewicz wrote:
>
> > On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote:
> >> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
> >>>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
> >>>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
> >>>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> >>>>>>>> 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.
> >>>>>>
> >>>>>> 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):
> >>>>>
> >>>>>> 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.
> >>>
> >>> 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.
>
> 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? ;) ]
> 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