2010-12-10 20:04:08

by Igor Plyatov

[permalink] [raw]
Subject: [PATCH] ata: pata_at91.c bugfix for high master clock

The AT91SAM9 microcontrollers with master clock higher then 105 MHz
and PIO0, have overflow of the NCS_RD_PULSE value in the MSB. This
lead to "NCS_RD_PULSE" pulse longer then "NRD_CYCLE" pulse and pata_at91
driver does detect ATA device.

Signed-off-by: Igor Plyatov <[email protected]>
---
drivers/ata/pata_at91.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/pata_at91.c b/drivers/ata/pata_at91.c
index 0da0dcc..2e189be 100644
--- a/drivers/ata/pata_at91.c
+++ b/drivers/ata/pata_at91.c
@@ -33,12 +33,14 @@


#define DRV_NAME "pata_at91"
-#define DRV_VERSION "0.1"
+#define DRV_VERSION "0.2"

#define CF_IDE_OFFSET 0x00c00000
#define CF_ALT_IDE_OFFSET 0x00e00000
#define CF_IDE_RES_SIZE 0x08

+#define NCS_RD_PULSE_LIMIT 0x3f /* maximal value for pulse bitfields */
+
struct at91_ide_info {
unsigned long mode;
unsigned int cs;
@@ -50,7 +52,7 @@ struct at91_ide_info {
};

static const struct ata_timing initial_timing =
- {XFER_PIO_0, 70, 290, 240, 600, 165, 150, 600, 0};
+ {XFER_PIO_0, 70, 290, 240, 600, 165, 150, 0, 600, 0};

static unsigned long calc_mck_cycles(unsigned long ns, unsigned long mck_hz)
{
@@ -109,6 +111,11 @@ static void set_smc_timing(struct device *dev,
/* (CS0, CS1, DIR, OE) <= (CFCE1, CFCE2, CFRNW, NCSX) timings */
ncs_read_setup = 1;
ncs_read_pulse = read_cycle - 2;
+ if (ncs_read_pulse > NCS_RD_PULSE_LIMIT) {
+ ncs_read_pulse = NCS_RD_PULSE_LIMIT;
+ dev_dbg(dev, "ncs_read_pulse limited to maximal value %lu\n",
+ ncs_read_pulse);
+ }

/* Write timings same as read timings */
write_cycle = read_cycle;
--
1.7.0.4


2010-12-11 03:40:52

by Igor Plyatov

[permalink] [raw]
Subject: Re: [PATCH] ata: pata_at91.c bugfix for high master clock

Here is a typo in the patch description:
> The AT91SAM9 microcontrollers with master clock higher then 105 MHz
> and PIO0, have overflow of the NCS_RD_PULSE value in the MSB. This
> lead to "NCS_RD_PULSE" pulse longer then "NRD_CYCLE" pulse and pata_at91
> driver does detect ATA device.

"...driver DOES NOT detect ATA device."

2010-12-11 19:43:38

by Igor Plyatov

[permalink] [raw]
Subject: Re: [PATCH] ata: pata_at91.c bugfix for high master clock

Dear Sergei,

> > I do not test this driver, but I think it have the same problem, because
> > it have the same algorithm for timings calculation.
>
> I quickly looked thru both drivers and the algorithm seemed different. :-)

I don't think so...

> > If you will see "cycle" value greater then 63, then problem exists.
>
> I thought the problem was with active pulse width, not total cycle time...

The problem was - the same "cycle" variable used to set up NRD_CYCLE
(max value = 127) and NCS_RD_PULSE (max value = 63).
Where NRD_CYCLE, NCS_RD_PULSE names from datasheet for AT91SAM9.
If NCS_RD_PULSE > 63, then overflow occur and pulse is much longer then
required.

For the 132 MHz, driver use NCS_RD_PULSE = 80 at device detection moment
on my board.
Calculated cycle in at91_ide is the same as for pata_at91 driver.

> > Generally, I does not see any reasons to use at91_ide, because ATA
> > drivers subsystem going to replace IDE drivers.
>
> There may be reasons -- like larger thruput in PIO mode (you have to check
> this though -- but generally libata seems very slow in PIO). Anyway, it
> doesn't mean that the bugs in IDE drivers should be ignored, and the
> replacemtn will not happen anytime soon (not all IDE drivers are ported to
> libata yet).

I will send next patch where this driver corrected and tested.

Best regards!
--
Igor Plyatov

2010-12-12 13:47:05

by Sergei Shtylyov

[permalink] [raw]
Subject: Re: [PATCH] ata: pata_at91.c bugfix for high master clock

Hello.

On 11-12-2010 22:43, Igor Plyatov wrote:

>>> I do not test this driver, but I think it have the same problem, because
>>> it have the same algorithm for timings calculation.

>> I quickly looked thru both drivers and the algorithm seemed different. :-)

> I don't think so...

In fact, the algorithm is slightly different.

>>> If you will see "cycle" value greater then 63, then problem exists.

>> I thought the problem was with active pulse width, not total cycle time...

> The problem was - the same "cycle" variable used to set up NRD_CYCLE
> (max value = 127) and NCS_RD_PULSE (max value = 63).
> Where NRD_CYCLE, NCS_RD_PULSE names from datasheet for AT91SAM9.
> If NCS_RD_PULSE > 63, then overflow occur and pulse is much longer then
> required.

Ah, NCS_RD_PULSE is different from active pulse time which is in the
variable 'nrd_pulse'.

> For the 132 MHz, driver use NCS_RD_PULSE = 80 at device detection moment
> on my board.
> Calculated cycle in at91_ide is the same as for pata_at91 driver.

Yes, but NCS_RD_PULSE is different in these drivers, it's cycle_time in
at91_ide.c and (cycle time - 2) in the pata_at91.c... Then there should indeed
be an error in at91_ide.c as well.

>>> Generally, I does not see any reasons to use at91_ide, because ATA
>>> drivers subsystem going to replace IDE drivers.

>> There may be reasons -- like larger thruput in PIO mode (you have to check
>> this though -- but generally libata seems very slow in PIO). Anyway, it
>> doesn't mean that the bugs in IDE drivers should be ignored, and the
>> replacemtn will not happen anytime soon (not all IDE drivers are ported to
>> libata yet).

> I will send next patch where this driver corrected and tested.

Thanks. :-)

> Best regards!
> --
> Igor Plyatov

WBR, Sergei