libata: Cavium OCTEON SOC Compact Flash driver (v2)
cover libata: Cavium OCTEON SOC Compact Flash driver (v2)
As part of our efforts to get the Cavium OCTEON processor support merged (see: http://marc.info/?l=linux-mips&m=122704699515601), I have a new version of our CF driver for your consideration.
This second version I split into two separate patches. The first adds some entries to the ata_timing table in libata-core. The second is the driver proper.
I will reply with the two patches.
David Daney (2):
libata: Add three more columns to the ata_timing table.
libata: New driver for OCTEON SOC Compact Flash interface (v2).
drivers/ata/Kconfig | 9 + drivers/ata/Makefile | 1 + drivers/ata/libata-core.c | 76 ++-- drivers/ata/pata_octeon_cf.c | 904 ++++++++++++++++++++++++++++++++++++++++++ include/linux/libata.h | 14 +- 5 files changed, 966 insertions(+), 38 deletions(-) create mode 100644 drivers/ata/pata_octeon_cf.c
PATCH 1/2 libata: Add three more columns to the ata_timing table.
The forthcoming OCTEON SOC Compact Flash driver needs a few more timing values than were available in the ata_timing table. I add new columns for write_hold, read_hold, and read_holdz times. The values were obtained from the Compact Flash specification Rev 4.1.
--- drivers/ata/libata-core.c | 76 ++++++++++++++++++++++++-------------------- include/linux/libata.h | 14 ++++++-- 2 files changed, 52 insertions(+), 38 deletions(-)
drivers/ata/libata-core.c +41 -35
@@ -2946,33 +2946,33 @@ int sata_set_spd(struct ata_link *link)*/ static const struct ata_timing ata_timing[] = { -/* { XFER_PIO_SLOW, 120, 290, 240, 960, 290, 240, 960, 0 }, */ - {XFER_PIO_0 ,70 ,290 ,240 ,600 ,165 ,150 ,600 ,0 }, - {XFER_PIO_1 ,50 ,290 ,93 ,383 ,125 ,100 ,383 ,0 }, - {XFER_PIO_2 ,30 ,290 ,40 ,330 ,100 ,90 ,240 ,0 }, - {XFER_PIO_3 ,30 ,80 ,70 ,180 ,80 ,70 ,180 ,0 }, - {XFER_PIO_4 ,25 ,70 ,25 ,120 ,70 ,25 ,120 ,0 }, - {XFER_PIO_5 ,15 ,65 ,25 ,100 ,65 ,25 ,100 ,0 }, - {XFER_PIO_6 ,10 ,55 ,20 ,80 ,55 ,20 ,80 ,0 }, - - {XFER_SW_DMA_0 ,120 ,0 ,0 ,0 ,480 ,480 ,960 ,0 }, - {XFER_SW_DMA_1 ,90 ,0 ,0 ,0 ,240 ,240 ,480 ,0 }, - {XFER_SW_DMA_2 ,60 ,0 ,0 ,0 ,120 ,120 ,240 ,0 }, - - {XFER_MW_DMA_0 ,60 ,0 ,0 ,0 ,215 ,215 ,480 ,0 }, - {XFER_MW_DMA_1 ,45 ,0 ,0 ,0 ,80 ,50 ,150 ,0 }, - {XFER_MW_DMA_2 ,25 ,0 ,0 ,0 ,70 ,25 ,120 ,0 }, - {XFER_MW_DMA_3 ,25 ,0 ,0 ,0 ,65 ,25 ,100 ,0 }, - {XFER_MW_DMA_4 ,25 ,0 ,0 ,0 ,55 ,20 ,80 ,0 }, - -/* { XFER_UDMA_SLOW, 0, 0, 0, 0, 0, 0, 0, 150 }, */ - {XFER_UDMA_0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,120 }, - {XFER_UDMA_1 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,80 }, - {XFER_UDMA_2 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,60 }, - {XFER_UDMA_3 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,45 }, - {XFER_UDMA_4 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,30 }, - {XFER_UDMA_5 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,20 }, - {XFER_UDMA_6 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,15 }, +/* { XFER_PIO_SLOW, 120, 290, 240, 960, 290, 240, 30, 5, 30, 960, 0 }, */ + {XFER_PIO_0 ,70 ,290 ,240 ,600 ,165 ,150 ,30 ,5 ,30 ,600 ,0 }, + {XFER_PIO_1 ,50 ,290 ,93 ,383 ,125 ,100 ,20 ,5 ,30 ,383 ,0 }, + {XFER_PIO_2 ,30 ,290 ,40 ,330 ,100 ,90 ,15 ,5 ,30 ,240 ,0 }, + {XFER_PIO_3 ,30 ,80 ,70 ,180 ,80 ,70 ,10 ,5 ,30 ,180 ,0 }, + {XFER_PIO_4 ,25 ,70 ,25 ,120 ,70 ,25 ,10 ,5 ,30 ,120 ,0 }, + {XFER_PIO_5 ,15 ,65 ,25 ,100 ,65 ,25 ,5 ,5 ,20 ,100 ,0 }, + {XFER_PIO_6 ,10 ,55 ,20 ,80 ,55 ,20 ,5 ,5 ,20 ,80 ,0 }, + + {XFER_SW_DMA_0 ,120 ,0 ,0 ,0 ,480 ,480 ,30 ,5 ,0 ,960 ,0 }, + {XFER_SW_DMA_1 ,90 ,0 ,0 ,0 ,240 ,240 ,30 ,5 ,0 ,480 ,0 }, + {XFER_SW_DMA_2 ,60 ,0 ,0 ,0 ,120 ,120 ,15 ,5 ,0 ,240 ,0 }, + + {XFER_MW_DMA_0 ,60 ,0 ,0 ,0 ,215 ,215 ,20 ,20 ,0 ,480 ,0 }, + {XFER_MW_DMA_1 ,45 ,0 ,0 ,0 ,80 ,50 ,15 ,5 ,0 ,150 ,0 }, + {XFER_MW_DMA_2 ,25 ,0 ,0 ,0 ,70 ,25 ,10 ,5 ,0 ,120 ,0 }, + {XFER_MW_DMA_3 ,25 ,0 ,0 ,0 ,65 ,25 ,5 ,5 ,0 ,100 ,0 }, + {XFER_MW_DMA_4 ,25 ,0 ,0 ,0 ,55 ,20 ,5 ,5 ,0 ,80 ,0 }, + +/* { XFER_UDMA_SLOW, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 150 }, */ + {XFER_UDMA_0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,120 }, + {XFER_UDMA_1 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,80 }, + {XFER_UDMA_2 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,60 }, + {XFER_UDMA_3 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,45 }, + {XFER_UDMA_4 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,30 }, + {XFER_UDMA_5 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,20 }, + {XFER_UDMA_6 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,15 }, {0xFF } };
@@ -2982,14 +2982,17 @@ static const struct ata_timing ata_timing[] = {static void ata_timing_quantize (const struct ata_timing *t,struct ata_timing *q,int T ,int UT ) { - q->setup =EZ (t->setup *1000 ,T ); - q->act8b =EZ (t->act8b *1000 ,T ); - q->rec8b =EZ (t->rec8b *1000 ,T ); - q->cyc8b =EZ (t->cyc8b *1000 ,T ); - q->active =EZ (t->active *1000 ,T ); - q->recover =EZ (t->recover *1000 ,T ); - q->cycle =EZ (t->cycle *1000 ,T ); - q->udma =EZ (t->udma *1000 ,UT ); + q->setup =EZ (t->setup *1000 ,T ); + q->act8b =EZ (t->act8b *1000 ,T ); + q->rec8b =EZ (t->rec8b *1000 ,T ); + q->cyc8b =EZ (t->cyc8b *1000 ,T ); + q->active =EZ (t->active *1000 ,T ); + q->recover =EZ (t->recover *1000 ,T ); + q->write_hold =EZ (t->write_hold *1000 ,T ); + q->read_hold =EZ (t->read_hold *1000 ,T ); + q->read_holdz =EZ (t->read_holdz *1000 ,T ); + q->cycle =EZ (t->cycle *1000 ,T ); + q->udma =EZ (t->udma *1000 ,UT ); } void ata_timing_merge(const struct ata_timing *a, const struct ata_timing *b,
@@ -3001,6 +3004,9 @@ void ata_timing_merge(const struct ata_timing *a, const struct ata_timing *b,if (what &ATA_TIMING_CYC8B ) m->cyc8b =max (a->cyc8b, b->cyc8b);if (what &ATA_TIMING_ACTIVE ) m->active =max (a->active, b->active);if (what &ATA_TIMING_RECOVER ) m->recover =max (a->recover, b->recover); +if (what &ATA_TIMING_WRITE_HOLD ) m->write_hold =max (a->write_hold, b->write_hold); +if (what &ATA_TIMING_READ_HOLD ) m->read_hold =max (a->read_hold, b->read_hold); +if (what &ATA_TIMING_READ_HOLDZ ) m->read_holdz =max (a->read_holdz, b->read_holdz);if (what &ATA_TIMING_CYCLE ) m->cycle =max (a->cycle, b->cycle);if (what &ATA_TIMING_UDMA ) m->udma =max (a->udma, b->udma); }
include/linux/libata.h +11 -3
@@ -398,12 +398,17 @@ enum {ATA_TIMING_CYC8B ,ATA_TIMING_ACTIVE = (1 <<4 ),ATA_TIMING_RECOVER = (1 <<5 ), -ATA_TIMING_CYCLE = (1 <<6 ), -ATA_TIMING_UDMA = (1 <<7 ), +ATA_TIMING_WRITE_HOLD = (1 <<6 ), +ATA_TIMING_READ_HOLD = (1 <<7 ), +ATA_TIMING_READ_HOLDZ = (1 <<8 ), +ATA_TIMING_CYCLE = (1 <<9 ), +ATA_TIMING_UDMA = (1 <<10 ),ATA_TIMING_ALL =ATA_TIMING_SETUP |ATA_TIMING_ACT8B |ATA_TIMING_REC8B |ATA_TIMING_CYC8B |ATA_TIMING_ACTIVE |ATA_TIMING_RECOVER | - ATA_TIMING_CYCLE | ATA_TIMING_UDMA, +ATA_TIMING_WRITE_HOLD |ATA_TIMING_READ_HOLD | +ATA_TIMING_READ_HOLDZ |ATA_TIMING_CYCLE | + ATA_TIMING_UDMA, }; enum ata_xfer_mask {
@@ -863,6 +868,9 @@ struct ata_timing {unsigned short cyc8b;/* t0 for 8-bit I/O */ unsigned short active;/* t2 or tD */ unsigned short recover;/* t2i or tK */ +unsigned short write_hold;/* t4 */ +unsigned short read_hold;/* t6 */ +unsigned short read_holdz;/* t6z or tj */ unsigned short cycle;/* t0 */ unsigned short udma;/* t2CYCTYP/2 */ };
Signature · 1 line
1.5.6.5
Re: [PATCH 1/2] libata: Add three more columns to the ata_timing table.
Hello.
Quoted 7 lines · David Daney
The forthcoming OCTEON SOC Compact Flash driver needs a few more timing values than were available in the
ata_timingtable. I add new columns forwrite_hold,read_hold, andread_holdztimes. The values were obtained from the Compact Flash specification Rev 4.1.Signed-off-by David Daney <[email protected]>
Not quite correct...
Quoted 9 lines
drivers/ata/libata-core.c +0
-0@@ -2946,33 +2946,33 @@ int sata_set_spd(struct ata_link *link)*/ static const struct ata_timing ata_timing[] = {
[...]
Quoted 5 lines
drivers/ata/libata-core.c +4
-0+/* { XFER_PIO_SLOW, 120, 290, 240, 960, 290, 240, 30, 5, 30, 960, 0 }, */ + { XFER_PIO_0, 70, 290, 240, 600, 165, 150, 30, 5, 30, 600, 0 }, + { XFER_PIO_1, 50, 290, 93, 383, 125, 100, 20, 5, 30, 383, 0 }, + { XFER_PIO_2, 30, 290, 40, 330, 100, 90, 15, 5, 30, 240, 0 },
drivers/ata/libata-core.c int sata_set_spd(struct ata_link *link) · line 2962
Quoted 10 lines
drivers/ata/libata-core.c +10
-0+ { XFER_PIO_3, 30, 80, 70, 180, 80, 70, 10, 5, 30, 180, 0 }, + { XFER_PIO_4, 25, 70, 25, 120, 70, 25, 10, 5, 30, 120, 0 }, + { XFER_PIO_5, 15, 65, 25, 100, 65, 25, 5, 5, 20, 100, 0 }, + { XFER_PIO_6, 10, 55, 20, 80, 55, 20, 5, 5, 20, 80, 0 }, + + { XFER_SW_DMA_0, 120, 0, 0, 0, 480, 480, 30, 5, 0, 960, 0 }, + { XFER_SW_DMA_1, 90, 0, 0, 0, 240, 240, 30, 5, 0, 480, 0 }, + { XFER_SW_DMA_2, 60, 0, 0, 0, 120, 120, 15, 5, 0, 240, 0 }, + + { XFER_MW_DMA_0, 60, 0, 0, 0, 215, 215, 20, 20, 0, 480, 0 },
Wrong, -DIOR hold time is 5 ns for MWDMA0 as well as for all other modes.
Quoted 5 lines
include/linux/libata.h +0
-0
[...]
include/linux/libata.h struct ata_timing { · line 873
Quoted 7 lines
include/linux/libata.h +2
-0@@ -863,6 +868,9 @@ struct ata_timing {unsigned short cyc8b;/* t0 for 8-bit I/O */ unsigned short active;/* t2 or tD */ unsigned short recover;/* t2i or tK */ +unsigned short write_hold;/* t4 */ +unsigned short read_hold;/* t6 */
-DIOR hold time is 5 ns for all PIO and MWDMA modes -- there's no
sense in storing it here.
include/linux/libata.h struct ata_timing { · line 875
Quoted 2 lines
include/linux/libata.h +1
-0+unsigned short read_holdz;/* t6z or tj */
T6z and Tj are not the same timing. Well, you specify it as 0 for
DMA modes anyway...
MBR, Sergei
Re: [PATCH 1/2] libata: Add three more columns to the ata_timing table.
Quoted 45 lines · Sergei Shtylyov
Hello.
Quoted 7 lines · David Daney
The forthcoming OCTEON SOC Compact Flash driver needs a few more timing values than were available in the
ata_timingtable. I add new columns forwrite_hold,read_hold, andread_holdztimes. The values were obtained from the Compact Flash specification Rev 4.1.Signed-off-by David Daney <[email protected]>Not quite correct...
Quoted 9 lines
drivers/ata/libata-core.c +0
-0@@ -2946,33 +2946,33 @@ int sata_set_spd(struct ata_link *link)*/ static const struct ata_timing ata_timing[] = {[...]
Quoted 21 lines
+/* {
XFER_PIO_SLOW, 120, 290, 240, 960, 290, 240, 30, 5, 30,
960, 0 }, */
+ {XFER_PIO_0, 70, 290, 240, 600, 165, 150, 30, 5, 30, 600,
0 },
+ {XFER_PIO_1, 50, 290, 93, 383, 125, 100, 20, 5, 30, 383,
0 },
+ {XFER_PIO_2, 30, 290, 40, 330, 100, 90, 15, 5, 30, 240,
0 },
+ {XFER_PIO_3, 30, 80, 70, 180, 80, 70, 10, 5, 30, 180,
0 },
+ {XFER_PIO_4, 25, 70, 25, 120, 70, 25, 10, 5, 30, 120,
0 },
+ {XFER_PIO_5, 15, 65, 25, 100, 65, 25, 5, 5, 20, 100,
0 },
+ {XFER_PIO_6, 10, 55, 20, 80, 55, 20, 5, 5, 20, 80,
0 },drivers/ata/libata-core.c +2
-0+ + { XFER_SW_DMA_0, 120, 0, 0, 0, 480, 480, 30, 5, 0, 960,0 },
+ {XFER_SW_DMA_1, 90, 0, 0, 0, 240, 240, 30, 5, 0, 480,
0 },
Quoted 8 lines
Quoted 6 lines
+ {
XFER_SW_DMA_2, 60, 0, 0, 0, 120, 120, 15, 5, 0, 240,
0 },drivers/ata/libata-core.c +2
-0+ + { XFER_MW_DMA_0, 60, 0, 0, 0, 215, 215, 20, 20, 0, 480,0 },
Wrong, -DIOR hold time is 5 ns for MWDMA0 as well as for all other modes.
Point taken.
Quoted 7 lines
Quoted 6 lines
include/linux/libata.h +0
-0[...]
Quoted 11 lines
include/linux/libata.h struct ata_timing { · line 873
Quoted 7 lines
include/linux/libata.h +2
-0@@ -863,6 +868,9 @@ struct ata_timing {unsigned short cyc8b;/* t0 for 8-bit I/O */ unsigned short active;/* t2 or tD */ unsigned short recover;/* t2i or tK */ +unsigned short write_hold;/* t4 */ +unsigned short read_hold;/* t6 */ -DIOR hold time is 5 ns for all PIO and MWDMA modes -- there's no
sense in storing it here.
By storing it here, ata_timing_compute() will compute the bus clock counts for me. Makes perfect sense to me.
Quoted 6 lines
include/linux/libata.h struct ata_timing { · line 875
Quoted 2 lines
include/linux/libata.h +1
-0+unsigned short read_holdz;/* t6z or tj */ T6z and Tj are not the same timing. Well, you specify it as 0 for DMA
modes anyway...
I had intended to overload this column for DMA, but somehow screwed it up. For my next patch I plan to populate this column for DMA modes.
David Daney
Re: [PATCH 1/2] libata: Add three more columns to the ata_timing table.
Quoted 7 lines · David Daney
Quoted 6 lines
Quoted 4 lines
include/linux/libata.h +0
-0[...]
Quoted 9 lines
Quoted 9 lines
include/linux/libata.h struct ata_timing { · line 872
Quoted 6 lines
include/linux/libata.h +2
-0@@ -863,6 +868,9 @@ struct ata_timing {unsigned short cyc8b;/* t0 for 8-bit I/O */ unsigned short active;/* t2 or tD */ unsigned short recover;/* t2i or tK */ +unsigned short write_hold;/* t4 */ +unsigned short read_hold;/* t6 */ -DIOR hold time is 5 ns for all PIO and MWDMA modes -- there's no
sense in storing it here.
Oops, that doesn't follow indeed...
Quoted 1 line
By storing it here,
ata_timing_compute()will compute the bus clock counts for me. Makes perfect sense to me.
Then let's just put *every* timing specified by the ATA standard there.
That would be consistent at least. :-)
Quoted 6 lines
Quoted 4 lines
include/linux/libata.h struct ata_timing { · line 873
Quoted 1 line
include/linux/libata.h +1
-0+unsigned short read_holdz;/* t6z or tj */ T6z and Tj are not the same timing. Well, you specify it as 0 for
DMA modes anyway...I had intended to overload this column for DMA, but somehow screwed it up. For my next patch I plan to populate this column for DMA modes.
There seems to be no timing "parallel" for T6z in the DMA transfers, so
you'll need another field then. Remember, the PIO and DMA timings are also "mergeable" -- by selecting the maximum field value of 2 'struct ata_timing' instances, so there should be no arbitrary field overloading.
Quoted 1 line
David Daney
WBR, Sergei
Re: [PATCH 1/2] libata: Add three more columns to the ata_timing table.
In reply to David DaneyQuoted 4 lines · David Daney
Quoted 2 lines
Wrong, -DIOR hold time is 5 ns for MWDMA0 as well as for all other
modes.Point taken.
Besides, I'm not sure how useful that timing could be for the host
controller since it's apparently not determined by the host side -- it's for how long the device holds valid data after -DIOR is released IIRC.
WBR, Sergei
Re: [PATCH 1/2] libata: Add three more columns to the ata_timing table.
Quoted 10 lines · Sergei Shtylyov
Quoted 4 lines · David Daney
Quoted 2 lines
Wrong, -DIOR hold time is 5 ns for MWDMA0 as well as for all other
modes.Point taken.
Besides, I'm not sure how useful that timing could be for the host
controller since it's apparently not determined by the host side -- it's for how long the device holds valid data after -DIOR is released IIRC.
Yes, I think you are correct. This is a property of the device and cannot be controlled by the driver, so I will just remove this column in the next version of the patch.
David Daney
Re: [PATCH 1/2] libata: Add three more columns to the ata_timing table.
In reply to David DaneyQuoted 10 lines · David Daney
The forthcoming OCTEON SOC Compact Flash driver needs a few more timing values than were available in the
ata_timingtable. I add new columns forwrite_hold,read_hold, andread_holdztimes. The values were obtained from the Compact Flash specification Rev 4.1.Signed-off-by David Daney <[email protected]>--- drivers/ata/libata-core.c | 76 ++++++++++++++++++++++++-------------------- include/linux/libata.h | 14 ++++++-- 2 files changed, 52 insertions(+), 38 deletions(-)
I would be happy to go ahead and apply this... Alan, any last minute objections?
Re: [PATCH 1/2] libata: Add three more columns to the ata_timing table.
Quoted 6 lines · Jeff Garzik
Quoted 5 lines · David Daney
The forthcoming OCTEON SOC Compact Flash driver needs a few more timing values than were available in the
ata_timingtable. I add new columns forwrite_hold,read_hold, andread_holdztimes. The values were obtained from the Compact Flash specification Rev 4.1.
Quoted 9 lines
Quoted 6 lines
Signed-off-by David Daney <[email protected]>--- drivers/ata/libata-core.c | 76 ++++++++++++++++++++++++-------------------- include/linux/libata.h | 14 ++++++-- 2 files changed, 52 insertions(+), 38 deletions(-)I would be happy to go ahead and apply this... Alan, any last minute objections?
Sergei had some comments that I am trying to address. Perhaps we should hold off a little, while I figure out how what to do WRT those comments.
David Daney
Re: [PATCH 1/2] libata: Add three more columns to the ata_timing table.
In reply to Jeff GarzikQuoted 6 lines · On Tue, 25 Nov 2008 12:00:19 -0500 Jeff Garzik <[email protected]> wrote:
Quoted 5 lines · David Daney
The forthcoming OCTEON SOC Compact Flash driver needs a few more timing values than were available in the
ata_timingtable. I add new columns forwrite_hold,read_hold, andread_holdztimes. The values were obtained from the Compact Flash specification Rev 4.1.
Quoted 8 lines
Quoted 5 lines
Signed-off-by David Daney <[email protected]>--- drivers/ata/libata-core.c | 76 ++++++++++++++++++++++++-------------------- include/linux/libata.h | 14 ++++++-- 2 files changed, 52 insertions(+), 38 deletions(-)I would be happy to go ahead and apply this... Alan, any last minute objections?
Its close but I think Sergei is right about columns with all the same value - they can be constants and just computed into the final timing data in terms of clocks.
Re: [PATCH 1/2] libata: Add three more columns to the ata_timing table.
Hello.
Quoted 11 lines · Alan Cox
Quoted 10 lines
Quoted 10 lines
The forthcoming OCTEON SOC Compact Flash driver needs a few more timing values than were available in the
ata_timingtable. I add new columns forwrite_hold,read_hold, andread_holdztimes. The values were obtained from the Compact Flash specification Rev 4.1.Signed-off-by David Daney <[email protected]>---
drivers/ata/libata-core.c | 76 ++++++++++++++++++++++++-------------------- include/linux/libata.h | 14 ++++++-- 2 files changed, 52 insertions(+), 38 deletions(-)
Quoted 5 lines
Quoted 1 line
I would be happy to go ahead and apply this... Alan, any last minute objections?
Its close but I think Sergei is right about columns with all the same value - they can be constants and just computed into the final timing data in terms of clocks.
The problem is that there's no exported libata API to compute just one
arbitrary timing.
WBR, Sergei
Re: [PATCH 1/2] libata: Add three more columns to the ata_timing table.
Quoted 6 lines
Quoted 3 lines
Its close but I think Sergei is right about columns with all the same value - they can be constants and just computed into the final timing data in terms of clocks.
The problem is that there's no exported libata API to compute just one
arbitrary timing.
To be clear: I agree entirely about adding those fields to the returned timing structure. I just don't think adding a field that says 5 in each entry of the internal table in the helper function is also useful.
Alan
PATCH 2/2 libata: New driver for OCTEON SOC Compact Flash interface (v2).
In reply to David DaneyAs part of our efforts to get the Cavium OCTEON processor support merged (see: http://marc.info/?l=linux-mips&m=122704699515601), we have this CF driver for your consideration.
Most OCTEON variants have *no* DMA or interrupt support on the CF interface so for these, only PIO is supported. Although if DMA is available, we do take advantage of it.
The register definitions are part of the chip support patch set mentioned above, and are not included here.
In this second version, I think I have addressed all the issued raised by Alan Cox and Sergei Shtylyov.
Thanks,
--- drivers/ata/Kconfig | 9 + drivers/ata/Makefile | 1 + drivers/ata/pata_octeon_cf.c | 904 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 914 insertions(+), 0 deletions(-) create mode 100644 drivers/ata/pata_octeon_cf.c
drivers/ata/Kconfig +9 -0
@@ -697,6 +697,15 @@ config PATA_IXP4XX_CF If unsure, say N. +config PATA_OCTEON_CF + tristate "OCTEON Boot Bus Compact Flash support" + depends on CPU_CAVIUM_OCTEON + help + This option enables a polled compact flash driver for use with + compact flash cards attached to the OCTEON boot bus. + + If unsure, say N. + config PATA_SCC tristate "Toshiba's Cell Reference Set IDE support" depends on PCI && PPC_CELLEB
drivers/ata/Makefile +1 -0
@@ -69,6 +69,7 @@ obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o obj-$(CONFIG_PATA_SCC) += pata_scc.o obj-$(CONFIG_PATA_SCH) += pata_sch.o obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o +obj-$(CONFIG_PATA_OCTEON_CF) += pata_octeon_cf.o obj-$(CONFIG_PATA_PLATFORM) += pata_platform.o obj-$(CONFIG_PATA_OF_PLATFORM) += pata_of_platform.o obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o
drivers/ata/pata_octeon_cf.c new file +904 -0
904 lines not on this page · raw message
Signature · 1 line
1.5.6.5
Re: [PATCH 2/2] libata: New driver for OCTEON SOC Compact Flash interface (v2).
Quoted 93 lines · David Daney
As part of our efforts to get the Cavium OCTEON processor support merged (see: http://marc.info/?l=linux-mips&m=122704699515601), we have this CF driver for your consideration.
Most OCTEON variants have *no* DMA or interrupt support on the CF interface so for these, only PIO is supported. Although if DMA is available, we do take advantage of it.
The register definitions are part of the chip support patch set mentioned above, and are not included here.
In this second version, I think I have addressed all the issued raised by Alan Cox and Sergei Shtylyov.
Thanks,
Signed-off-by David Daney <[email protected]>--- drivers/ata/Kconfig | 9 + drivers/ata/Makefile | 1 + drivers/ata/pata_octeon_cf.c | 904 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 914 insertions(+), 0 deletions(-) create mode 100644 drivers/ata/pata_octeon_cf.cdrivers/ata/Kconfig +9
-0@@ -697,6 +697,15 @@ config PATA_IXP4XX_CF If unsure, say N. +config PATA_OCTEON_CF + tristate "OCTEON Boot Bus Compact Flash support" + depends on CPU_CAVIUM_OCTEON + help + This option enables a polled compact flash driver for use with + compact flash cards attached to the OCTEON boot bus. + + If unsure, say N. + config PATA_SCC tristate "Toshiba's Cell Reference Set IDE support" depends on PCI && PPC_CELLEBdrivers/ata/Makefile +1
-0@@ -69,6 +69,7 @@ obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o obj-$(CONFIG_PATA_SCC) += pata_scc.o obj-$(CONFIG_PATA_SCH) += pata_sch.o obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o +obj-$(CONFIG_PATA_OCTEON_CF) += pata_octeon_cf.o obj-$(CONFIG_PATA_PLATFORM) += pata_platform.o obj-$(CONFIG_PATA_OF_PLATFORM) += pata_of_platform.o obj-$(CONFIG_PATA_ICSIDE) += pata_icside.odrivers/ata/pata_octeon_cf.c new file +31
-0@@ -0,0 +1,904 @@ +/* +* Driver for the Octeon bootbus compact flash. +* +* This file is subject to the terms and conditions of the GNU General Public +* License. See the file "COPYING" in the main directory of this archive +* for more details. +* +* Copyright (C) 2005-2008 Cavium Networks +* Copyright (C) 2008 Wind River Systems +*/ + +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/libata.h> +#include <linux/irq.h> +#include <linux/platform_device.h> +#include <scsi/scsi_host.h> + +#include <asm/octeon/octeon.h> + +#define DRV_NAME "pata_octeon_cf" +#define DRV_VERSION "2.1" + + +struct octeon_cf_port { +struct tasklet_struct delayed_irq_tasklet; +int dma_finished; +}; + +/* Timing multiple used for configuring the boot bus DMA engine */ +#define CF_DMA_TIMING_MULT 4
drivers/ata/pata_octeon_cf.c line 41
Quoted 10 lines
drivers/ata/pata_octeon_cf.c new file +10
-0+ +static struct scsi_host_template octeon_cf_sht = { +ATA_PIO_SHT (DRV_NAME ), +}; + +static int mwdmamodes =0x1f ;/* Support Multiword DMA 0-4 */ +module_param (mwdmamodes, int,0444 ); +MODULE_PARM_DESC (mwdmamodes, +"Bitmask controlling which MWDMA modes are supported. " +"Default is 0x1f for MWDMA 0-4." );
Two comments:
* perhaps I missed this, but why is this module param necessary? In general we avoid things like this.
* I would avoid pretending to be an SFF DMA engine, and just code it in the style of a custom DMA engine with SFF registers/mode, such as sata_mv or sata_promise.
Jeff
Re: [PATCH 2/2] libata: New driver for OCTEON SOC Compact Flash interface (v2).
Quoted 17 lines · Jeff Garzik
drivers/ata/pata_octeon_cf.c line 41
Quoted 13 lines · David Daney
drivers/ata/pata_octeon_cf.c new file +13
-0+ +/* Timing multiple used for configuring the boot bus DMA engine */ +#define CF_DMA_TIMING_MULT 4 + +static struct scsi_host_template octeon_cf_sht = { +ATA_PIO_SHT (DRV_NAME ), +}; + +static int mwdmamodes =0x1f ;/* Support Multiword DMA 0-4 */ +module_param (mwdmamodes, int,0444 ); +MODULE_PARM_DESC (mwdmamodes, +"Bitmask controlling which MWDMA modes are supported. " +"Default is 0x1f for MWDMA 0-4." );Two comments:
Quoted 2 lines
* perhaps I missed this, but why is this module param necessary? In general we avoid things like this.
The CF interface is on the SOC's Boot Bus. Under some circumstances a
board wide hardware reset can occur while DMA is in progress, this
results in the CF driving the Boot Bus while the processor is trying to read the boot code from the boot ROM which results in an unbootable system. The only recourse is to cycle power to the board. By allowing DMA to be disabled, we eliminate this problem.
Quoted 2 lines
* I would avoid pretending to be an SFF DMA engine, and just code it in the style of a custom DMA engine with SFF registers/mode, such as
sata_mvorsata_promise.
It is certainly possible to do that, however I think it will result in a much larger driver. If you strongly object, we would have to bite the bullet and do as you suggest.
David Daney
Re: [PATCH 2/2] libata: New driver for OCTEON SOC Compact Flash interface (v2).
Quoted 2 lines
system. The only recourse is to cycle power to the board. By allowing DMA to be disabled, we eliminate this problem.
You can already do this via the existing libata option functions that Tejun added a while back, or there is libata.dma=0 which is applied to all interfaces.
Re: [PATCH 2/2] libata: New driver for OCTEON SOC Compact Flash interface (v2).
Quoted 6 lines · Alan Cox
Quoted 1 line
system. The only recourse is to cycle power to the board. By allowing DMA to be disabled, we eliminate this problem.
You can already do this via the existing libata option functions that Tejun added a while back, or there is libata.dma=0 which is applied to all interfaces.
Great, I will remove our driver's option.
David Daney