From: Jeff Garzik <jeff@garzik.org>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: linux-ide@vger.kernel.org, alan@lxorguk.ukuu.org.uk, albertl@mail.com
Subject: Re: [PATCH 2.6.23-rc3] pata_pdc2027x: PLL detection fixes
Date: Sat, 18 Aug 2007 17:25:37 -0400 [thread overview]
Message-ID: <46C763D1.7060801@garzik.org> (raw)
In-Reply-To: <200708182058.l7IKwrcJ016820@harpo.it.uu.se>
Mikael Pettersson wrote:
> Previously I reported that the pata_pdc2027x PLL detection changes
> in kernel 2.6.22 broke the driver on my PowerMac:
>
>> pata_pdc2027x: Invalid PLL input clock 1691742kHz, give up!
>
> This is followed by a number of errors and speed reduction
> steps on the affected ports.
>
> There are two bugs in pata_pdc2027x's PLL detection code:
>
> 1. The PLL counter's start value is read before the chip is
> put in "test mode". Outside of test mode the counter is
> halted, and on the PowerMac the counter is zero because
> the chip hasn't been initialised by its BIOS.
>
> The fix is to move the read of the start value to after
> test mode is started, but before the mdelay() in test mode.
> This also improves the precision of the PLL detection.
>
> 2. The code to compute the number of PLL decrements during the
> mdelay() in test mode fails to consider that the PLL counter
> only is 30 bits wide. If there is a wraparound, it will compute
> an incorrect and much too large value. On the PowerMac, the
> start count is zero, the end count is a large 30-bit value, so
> wraparound occurs and an out of bounds PLL clock is detected.
>
> The fix is to mask the (start - end) computation to 30 bits.
>
> While debugging this I also noticed that pdc_read_counter()
> reads the two halves of the 30-bit PLL counter as 16-bit values,
> and then combines them as if the halves only are 15 bits wide.
> To avoid confusion, the halves should be read as 15-bit values.
>
> This patch implements all three changes. It fixes the PLL detection
> failure on my PowerMac, and doesn't cause any regressions on an x86
> with an identical card.
>
> Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Fantastic! Thanks for putting in a great effort to track these down.
I'll queue it up [unless someone responds with a problem requiring
revision, of course]
> diff -rupN linux-2.6.23-rc3/drivers/ata/pata_pdc2027x.c linux-2.6.23-rc3.pata_pdc2027x-pll-detection-fixes/drivers/ata/pata_pdc2027x.c
> --- linux-2.6.23-rc3/drivers/ata/pata_pdc2027x.c 2007-07-09 22:01:31.000000000 +0200
> +++ linux-2.6.23-rc3.pata_pdc2027x-pll-detection-fixes/drivers/ata/pata_pdc2027x.c 2007-08-18 21:53:40.000000000 +0200
> @@ -563,13 +563,13 @@ static long pdc_read_counter(struct ata_
> u32 bccrl, bccrh, bccrlv, bccrhv;
>
> retry:
> - bccrl = readl(mmio_base + PDC_BYTE_COUNT) & 0xffff;
> - bccrh = readl(mmio_base + PDC_BYTE_COUNT + 0x100) & 0xffff;
> + bccrl = readl(mmio_base + PDC_BYTE_COUNT) & 0x7fff;
> + bccrh = readl(mmio_base + PDC_BYTE_COUNT + 0x100) & 0x7fff;
> rmb();
>
> /* Read the counter values again for verification */
> - bccrlv = readl(mmio_base + PDC_BYTE_COUNT) & 0xffff;
> - bccrhv = readl(mmio_base + PDC_BYTE_COUNT + 0x100) & 0xffff;
> + bccrlv = readl(mmio_base + PDC_BYTE_COUNT) & 0x7fff;
> + bccrhv = readl(mmio_base + PDC_BYTE_COUNT + 0x100) & 0x7fff;
> rmb();
>
> counter = (bccrh << 15) | bccrl;
Unrelated to your changes, but, I wonder why those rmb() are there at
all...?
Jeff
next prev parent reply other threads:[~2007-08-18 21:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-18 20:58 [PATCH 2.6.23-rc3] pata_pdc2027x: PLL detection fixes Mikael Pettersson
2007-08-18 21:25 ` Jeff Garzik [this message]
2007-08-19 0:14 ` Albert Lee
2007-08-19 0:53 ` Jeff Garzik
2007-08-19 1:03 ` Albert Lee
2007-08-20 8:56 ` [PATCH 2.6.23-rc3] libata: pata_pdc2027x PLL detection minor cleanup Albert Lee
2007-08-31 9:35 ` Jeff Garzik
2007-08-19 0:01 ` [PATCH 2.6.23-rc3] pata_pdc2027x: PLL detection fixes Albert Lee
2007-08-19 16:13 ` Sergei Shtylyov
2007-08-23 9:32 ` Jeff Garzik
-- strict thread matches above, loose matches on Subject: below --
2007-08-19 17:17 Mikael Pettersson
2007-08-19 17:51 ` Sergei Shtylyov
2007-08-19 19:47 ` Jeff Garzik
2007-08-24 16:29 ` Sergei Shtylyov
2007-08-21 10:30 ` Albert Lee
2007-08-24 16:24 ` Sergei Shtylyov
2007-08-24 18:31 ` Bartlomiej Zolnierkiewicz
2007-08-24 18:44 ` Sergei Shtylyov
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=46C763D1.7060801@garzik.org \
--to=jeff@garzik.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=albertl@mail.com \
--cc=linux-ide@vger.kernel.org \
--cc=mikpe@it.uu.se \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).