All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Alan Cox <alan@linux.intel.com>,
	linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH 4/5] pata: Update experimental tags
Date: Wed, 18 Nov 2009 20:07:07 +0100	[thread overview]
Message-ID: <200911182007.07405.bzolnier@gmail.com> (raw)
In-Reply-To: <20091118184125.623e063d@lxorguk.ukuu.org.uk>

On Wednesday 18 November 2009 19:41:25 Alan Cox wrote:
> > Maybe they are 'stable' but when it comes to features they are behind hpt366
> > (i.e. they lack PCI PM), which is also much cleaner than your drivers, easier
> > to understand and much smaller..
> 
> 37x and 3xn lack PCI PM.  Added to the TODO list.
> 
> The smaller size is a bit questionable given its mostly comments, and
> three drivers versus one.

I wonder what you find 'questionable' in the numbers given..

> > Having separate drivers wasn't the best decisions from the maintainability
> > point-of-view.   It added needless complexity (different chips share the same
> 
> It was most definitely a good decision, having maintained both sets of
> drivers at different times. It also makes it possible to do things the
> > way highpoint does rather than trying to make stuff common which HPT

Interesting, because all other people involved in HPT PATA support
seem to disagree with you and they certainly wouldn't say that doing
all things the way HPT did is a good thing..

> themselves don't keep common. Even more importantly we get to break *one*
> type of device at a time.

I prefer to not break anything, but hey my way of doing things is not
very much welcomed here..

I also like to think that by sharing code we get better testing coverage
and are in reality able to fix problems much faster because of this..

> > PCI IDs which make detection across multiple drivers extremely painful) and
> > confusion (i.e. would you have guessed that HPT302 is supported by pata_hpt37x
> > while HPT302N by pata_hpt3x2n?).
> 
> I love highpoint too for their ever weirder and more confusingly labelled
> and identified chips. I still think the split is worth it, and the 'wtf
> device am I' logic is needed in both cases - either to pick a driver or
> pick a set of methods.
> 
> We have the it821x driver for it8211/2 but not 8213 ..

it821x and it8213 share absolutely no common logic (the first chip
has ITE logic and the second one is based on Intel ICH) while in case
of HPT family there are sometimes large similarities..

pata_hpt37x.c:

...
static struct hpt_clock hpt37x_timings_66[] = {
	{ XFER_UDMA_6,		0x1c869c62 },
	{ XFER_UDMA_5,		0x1cae9c62 },	/* 0x1c8a9c62 */
	{ XFER_UDMA_4,		0x1c8a9c62 },
	{ XFER_UDMA_3,		0x1c8e9c62 },
	{ XFER_UDMA_2,		0x1c929c62 },
	{ XFER_UDMA_1,		0x1c9a9c62 },
	{ XFER_UDMA_0,		0x1c829c62 },

	{ XFER_MW_DMA_2,	0x2c829c62 },
	{ XFER_MW_DMA_1,	0x2c829c66 },
	{ 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 }
};
...
/**
 *	hpt372_set_piomode		-	PIO setup
 *	@ap: ATA interface
 *	@adev: device on the interface
 *
 *	Perform PIO mode setup.
 */

static void hpt372_set_piomode(struct ata_port *ap, struct ata_device *adev)
{
	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
	u32 addr1, addr2;
	u32 reg;
	u32 mode;
	u8 fast;

	addr1 = 0x40 + 4 * (adev->devno + 2 * ap->port_no);
	addr2 = 0x51 + 4 * ap->port_no;

	/* Fast interrupt prediction disable, hold off interrupt disable */
	pci_read_config_byte(pdev, addr2, &fast);
	fast &= ~0x07;
	pci_write_config_byte(pdev, addr2, fast);

	pci_read_config_dword(pdev, addr1, &reg);
	mode = hpt37x_find_mode(ap, adev->pio_mode);

	printk("Find mode for %d reports %X\n", adev->pio_mode, mode);
	mode &= ~0x80000000;	/* No FIFO in PIO */
	mode &= ~0x30070000;	/* Leave config bits alone */
	reg &= 0x30070000;	/* Strip timing bits */
	pci_write_config_dword(pdev, addr1, reg | mode);
}

/**
 *	hpt372_set_dmamode		-	DMA timing setup
 *	@ap: ATA interface
 *	@adev: Device being configured
 *
 *	Set up the channel for MWDMA or UDMA modes. Much the same as with
 *	PIO, load the mode number and then set MWDMA or UDMA flag.
 */

static void hpt372_set_dmamode(struct ata_port *ap, struct ata_device *adev)
{
	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
	u32 addr1, addr2;
	u32 reg;
	u32 mode;
	u8 fast;

	addr1 = 0x40 + 4 * (adev->devno + 2 * ap->port_no);
	addr2 = 0x51 + 4 * ap->port_no;

	/* Fast interrupt prediction disable, hold off interrupt disable */
	pci_read_config_byte(pdev, addr2, &fast);
	fast &= ~0x07;
	pci_write_config_byte(pdev, addr2, fast);

	pci_read_config_dword(pdev, addr1, &reg);
	mode = hpt37x_find_mode(ap, adev->dma_mode);
	printk("Find mode for DMA %d reports %X\n", adev->dma_mode, mode);
	mode &= ~0xC0000000;	/* Leave config bits alone */
	mode |= 0x80000000;	/* FIFO in MWDMA or UDMA */
	reg &= 0xC0000000;	/* Strip timing bits */
	pci_write_config_dword(pdev, addr1, reg | mode);
}

/**
 *	hpt37x_bmdma_end		-	DMA engine stop
 *	@qc: ATA command
 *
 *	Clean up after the HPT372 and later DMA engine
 */

static void hpt37x_bmdma_stop(struct ata_queued_cmd *qc)
{
	struct ata_port *ap = qc->ap;
	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
	int mscreg = 0x50 + 4 * ap->port_no;
	u8 bwsr_stat, msc_stat;

	pci_read_config_byte(pdev, 0x6A, &bwsr_stat);
	pci_read_config_byte(pdev, mscreg, &msc_stat);
	if (bwsr_stat & (1 << ap->port_no))
		pci_write_config_byte(pdev, mscreg, msc_stat | 0x30);
	ata_bmdma_stop(qc);
}
...
/**
 *	hpt37x_calibrate_dpll		-	Calibrate the DPLL loop
 *	@dev: PCI device
 *
 *	Perform a calibration cycle on the HPT37x DPLL. Returns 1 if this
 *	succeeds
 */

static int hpt37x_calibrate_dpll(struct pci_dev *dev)
{
	u8 reg5b;
	u32 reg5c;
	int tries;

	for(tries = 0; tries < 0x5000; tries++) {
		udelay(50);
		pci_read_config_byte(dev, 0x5b, &reg5b);
		if (reg5b & 0x80) {
			/* See if it stays set */
			for(tries = 0; tries < 0x1000; tries ++) {
				pci_read_config_byte(dev, 0x5b, &reg5b);
				/* Failed ? */
				if ((reg5b & 0x80) == 0)
					return 0;
			}
			/* Turn off tuning, we have the DPLL set */
			pci_read_config_dword(dev, 0x5c, &reg5c);
			pci_write_config_dword(dev, 0x5c, reg5c & ~ 0x100);
			return 1;
		}
	}
	/* Never went stable */
	return 0;
}
...


pata_hpt3x2n.c:

...
/* 66MHz DPLL clocks */

static struct hpt_clock hpt3x2n_clocks[] = {
	{	XFER_UDMA_7,	0x1c869c62	},
	{	XFER_UDMA_6,	0x1c869c62	},
	{	XFER_UDMA_5,	0x1c8a9c62	},
	{	XFER_UDMA_4,	0x1c8a9c62	},
	{	XFER_UDMA_3,	0x1c8e9c62	},
	{	XFER_UDMA_2,	0x1c929c62	},
	{	XFER_UDMA_1,	0x1c9a9c62	},
	{	XFER_UDMA_0,	0x1c829c62	},

	{	XFER_MW_DMA_2,	0x2c829c62	},
	{	XFER_MW_DMA_1,	0x2c829c66	},
	{	XFER_MW_DMA_0,	0x2c829d2c	},

	{	XFER_PIO_4,	0x0c829c62	},
	{	XFER_PIO_3,	0x0c829c84	},
	{	XFER_PIO_2,	0x0c829ca6	},
	{	XFER_PIO_1,	0x0d029d26	},
	{	XFER_PIO_0,	0x0d029d5e	},
	{	0,		0x0d029d5e	}
};
...
/**
 *	hpt3x2n_set_piomode		-	PIO setup
 *	@ap: ATA interface
 *	@adev: device on the interface
 *
 *	Perform PIO mode setup.
 */

static void hpt3x2n_set_piomode(struct ata_port *ap, struct ata_device *adev)
{
	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
	u32 addr1, addr2;
	u32 reg;
	u32 mode;
	u8 fast;

	addr1 = 0x40 + 4 * (adev->devno + 2 * ap->port_no);
	addr2 = 0x51 + 4 * ap->port_no;

	/* Fast interrupt prediction disable, hold off interrupt disable */
	pci_read_config_byte(pdev, addr2, &fast);
	fast &= ~0x07;
	pci_write_config_byte(pdev, addr2, fast);

	pci_read_config_dword(pdev, addr1, &reg);
	mode = hpt3x2n_find_mode(ap, adev->pio_mode);
	mode &= ~0x8000000;	/* No FIFO in PIO */
	mode &= ~0x30070000;	/* Leave config bits alone */
	reg &= 0x30070000;	/* Strip timing bits */
	pci_write_config_dword(pdev, addr1, reg | mode);
}

/**
 *	hpt3x2n_set_dmamode		-	DMA timing setup
 *	@ap: ATA interface
 *	@adev: Device being configured
 *
 *	Set up the channel for MWDMA or UDMA modes. Much the same as with
 *	PIO, load the mode number and then set MWDMA or UDMA flag.
 */

static void hpt3x2n_set_dmamode(struct ata_port *ap, struct ata_device *adev)
{
	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
	u32 addr1, addr2;
	u32 reg;
	u32 mode;
	u8 fast;

	addr1 = 0x40 + 4 * (adev->devno + 2 * ap->port_no);
	addr2 = 0x51 + 4 * ap->port_no;

	/* Fast interrupt prediction disable, hold off interrupt disable */
	pci_read_config_byte(pdev, addr2, &fast);
	fast &= ~0x07;
	pci_write_config_byte(pdev, addr2, fast);

	pci_read_config_dword(pdev, addr1, &reg);
	mode = hpt3x2n_find_mode(ap, adev->dma_mode);
	mode |= 0x8000000;	/* FIFO in MWDMA or UDMA */
	mode &= ~0xC0000000;	/* Leave config bits alone */
	reg &= 0xC0000000;	/* Strip timing bits */
	pci_write_config_dword(pdev, addr1, reg | mode);
}

/**
 *	hpt3x2n_bmdma_end		-	DMA engine stop
 *	@qc: ATA command
 *
 *	Clean up after the HPT3x2n and later DMA engine
 */

static void hpt3x2n_bmdma_stop(struct ata_queued_cmd *qc)
{
	struct ata_port *ap = qc->ap;
	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
	int mscreg = 0x50 + 2 * ap->port_no;
	u8 bwsr_stat, msc_stat;

	pci_read_config_byte(pdev, 0x6A, &bwsr_stat);
	pci_read_config_byte(pdev, mscreg, &msc_stat);
	if (bwsr_stat & (1 << ap->port_no))
		pci_write_config_byte(pdev, mscreg, msc_stat | 0x30);
	ata_bmdma_stop(qc);
}
...
/**
 *	hpt3xn_calibrate_dpll		-	Calibrate the DPLL loop
 *	@dev: PCI device
 *
 *	Perform a calibration cycle on the HPT3xN DPLL. Returns 1 if this
 *	succeeds
 */

static int hpt3xn_calibrate_dpll(struct pci_dev *dev)
{
	u8 reg5b;
	u32 reg5c;
	int tries;

	for(tries = 0; tries < 0x5000; tries++) {
		udelay(50);
		pci_read_config_byte(dev, 0x5b, &reg5b);
		if (reg5b & 0x80) {
			/* See if it stays set */
			for(tries = 0; tries < 0x1000; tries ++) {
				pci_read_config_byte(dev, 0x5b, &reg5b);
				/* Failed ? */
				if ((reg5b & 0x80) == 0)
					return 0;
			}
			/* Turn off tuning, we have the DPLL set */
			pci_read_config_dword(dev, 0x5c, &reg5c);
			pci_write_config_dword(dev, 0x5c, reg5c & ~ 0x100);
			return 1;
		}
	}
	/* Never went stable */
	return 0;
}
...

etc.

-- 
Bartlomiej Zolnierkiewicz

  parent reply	other threads:[~2009-11-18 19:08 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-17 14:50 [PATCH 0/5] Series short description Alan Cox
2009-11-17 14:51 ` [PATCH 1/5] pata_via: Blacklist some combinations of Transcend Flash and via Alan Cox
2009-11-17 14:51 ` [PATCH 2/5] pata_sis: Implement MWDMA for the UDMA 133 capable chips Alan Cox
2009-11-17 17:27   ` Bartlomiej Zolnierkiewicz
2009-11-17 17:38     ` Alan Cox
2009-11-17 17:57       ` Bartlomiej Zolnierkiewicz
2009-11-17 18:21         ` Alan Cox
2009-11-17 19:33           ` Bartlomiej Zolnierkiewicz
2009-11-17 14:51 ` [PATCH 3/5] cmd64x: implement serialization as per notes Alan Cox
2009-11-17 17:35   ` Bartlomiej Zolnierkiewicz
2009-11-17 18:08     ` Alan Cox
2009-11-17 14:51 ` [PATCH 4/5] pata: Update experimental tags Alan Cox
2009-11-17 22:36   ` Jeff Garzik
2009-11-18 18:19   ` Bartlomiej Zolnierkiewicz
2009-11-18 18:41     ` Alan Cox
2009-11-18 18:47       ` Sergei Shtylyov
2009-11-18 19:16         ` Bartlomiej Zolnierkiewicz
2009-11-18 19:07       ` Bartlomiej Zolnierkiewicz [this message]
2009-11-18 19:56         ` Bartlomiej Zolnierkiewicz
2009-11-19 13:16           ` Alan Cox
2009-11-19 14:17             ` Bartlomiej Zolnierkiewicz
2009-11-19 14:33               ` Alan Cox
2009-11-19 14:50                 ` Bartlomiej Zolnierkiewicz
2009-11-19 15:16                   ` Bartlomiej Zolnierkiewicz
2009-11-19 15:24                     ` Alan Cox
2009-11-19 15:22                   ` Alan Cox
2009-11-19 15:45                     ` Bartlomiej Zolnierkiewicz
2009-11-19 16:27                       ` Alan Cox
2009-11-19 17:10                         ` Bartlomiej Zolnierkiewicz
2009-11-19 17:38                         ` Bartlomiej Zolnierkiewicz
2009-11-19 17:50                           ` Alan Cox
2009-11-19 17:52                             ` Bartlomiej Zolnierkiewicz
2009-11-19 18:21                               ` Alan Cox
2009-11-19 18:38                                 ` Sergei Shtylyov
2009-11-19 19:03                                   ` Bartlomiej Zolnierkiewicz
2009-11-19 19:31                                     ` Bartlomiej Zolnierkiewicz
2009-11-19 19:42                                       ` Alan Cox
2009-11-19 19:54                                         ` Bartlomiej Zolnierkiewicz
2009-11-19 21:34                                       ` Jeff Garzik
2009-11-19 21:49                                       ` Jeff Garzik
2009-11-19 19:40                                   ` Alan Cox
2009-11-19 21:21                                     ` Sergei Shtylyov
2009-11-20 18:20                                       ` Sergei Shtylyov
2009-11-19 18:58                                 ` Bartlomiej Zolnierkiewicz
2009-11-19 21:48                           ` Jeff Garzik
2009-11-19 14:02           ` Alan Cox
2009-11-19 14:16             ` Sergei Shtylyov
2009-11-19 14:31               ` Alan Cox
2009-11-19 14:38                 ` Sergei Shtylyov
2009-11-19 14:22             ` Bartlomiej Zolnierkiewicz
2009-11-19 21:38           ` Jeff Garzik
2009-11-19 21:49             ` Bartlomiej Zolnierkiewicz
2009-11-19 22:03               ` Jeff Garzik
2009-11-20 21:17                 ` Bartlomiej Zolnierkiewicz
2009-11-19 23:42               ` Alan Cox
2009-11-18 19:34       ` Bartlomiej Zolnierkiewicz
2009-11-18 19:59         ` Bartlomiej Zolnierkiewicz
2009-11-19 21:36     ` Jeff Garzik
2009-11-19 21:42       ` Bartlomiej Zolnierkiewicz
2009-11-19 21:57         ` Jeff Garzik
2009-11-19 23:38           ` Alan Cox
2009-11-17 14:52 ` [PATCH 5/5] pata_piccolo: Driver for old Toshiba chipsets Alan Cox
2009-11-27 14:28   ` Bartlomiej Zolnierkiewicz
2009-11-27 15:34     ` Alan Cox
2009-11-19 21:41 ` [PATCH 0/5] Series short description Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200911182007.07405.bzolnier@gmail.com \
    --to=bzolnier@gmail.com \
    --cc=alan@linux.intel.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.