New IDE/block driver for OCTEON SOC Compact Flash interface.
PATCH 1/1 New IDE/block driver for OCTEON SOC Compact Flash interface.
As part of our efforts to get the Cavium OCTEON processor support merged (see: http://marc.info/?l=linux-mips&m=122600487218824), we have this CF driver for your consideration.
Most OCTEON variants have *no* DMA or interrupt support on the CF interface so a simple bit-banging approach is taken. 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.
At this point I would like to get feedback as to whether this is a good approach for the CF driver, or perhaps generate ideas about other possible approaches.
Thanks,
---
drivers/ide/Kconfig | 8 + drivers/ide/Makefile | 1 + drivers/ide/octeon-cf.c | 1102 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 1111 insertions(+), 0 deletions(-)
drivers/ide/Kconfig +8 -0
@@ -720,6 +720,14 @@ config BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ default "128" depends on BLK_DEV_IDE_AU1XXX +config BLK_DEV_OCTEON_BOOTBUS_CF + tristate "Support for OCTEON Boot Bus Compact Flash" + depends on CPU_CAVIUM_OCTEON + default "y" + help + This option enables a polled compact flash driver for use with + compact flash cards attached to the OCTEON boot bus. +
config BLK_DEV_IDE_TX4938
tristate "TX4938 internal IDE support"
depends on SOC_TX4938
drivers/ide/Makefile +0 -0
@@ -113,3 +113,4 @@ obj-$(CONFIG_BLK_DEV_IDE_AU1XXX) += au1xxx-ide.o
obj-$(CONFIG_BLK_DEV_IDE_TX4938) += tx4938ide.o
obj-$(CONFIG_BLK_DEV_IDE_TX4939) += tx4939ide.o
+obj-$(CONFIG_BLK_DEV_OCTEON_BOOTBUS_CF) += octeon-cf.o
drivers/ide/octeon-cf.c new file +1102 -0
1,102 lines not on this page · raw message
Hello.
Quoted 8 lines · David Daney
As part of our efforts to get the Cavium OCTEON processor support merged (see: http://marc.info/?l=linux-mips&m=122600487218824), we have this CF driver for your consideration.
Most OCTEON variants have *no* DMA or interrupt support on the CF interface so a simple bit-banging approach is taken. Although if DMA is available, we do take advantage of it.
Quoted 6 lines
The register definitions are part of the chip support patch set mentioned above, and are not included here.
At this point I would like to get feedback as to whether this is a good approach for the CF driver, or perhaps generate ideas about other possible approaches.
It's totally unacceptable for drivers/ide/ as this is self-containeed
driver no using IDE core for anything, so this can only fit well to drivers/block/.
OTOH, CF support via self-contained driver is certainly a waste of code since IDE core and (libata) are here to drive the CF devices as well. What we need is a "normal" IDE or libata (at your option) driver.
WBR, Sergei
Quoted 11 lines · Hello, I wrote:
Quoted 11 lines
As part of our efforts to get the Cavium OCTEON processor support merged (see: http://marc.info/?l=linux-mips&m=122600487218824), we have this CF driver for your consideration.
Most OCTEON variants have *no* DMA or interrupt support on the CF interface so a simple bit-banging approach is taken. 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.
Quoted 6 lines
Quoted 3 lines
At this point I would like to get feedback as to whether this is a good approach for the CF driver, or perhaps generate ideas about other possible approaches.
It's totally unacceptable for
drivers/ide/as this is
self-containeed driver no using IDE core for anything, so this can only fit well todrivers/block/.
I probably need to clarify that it will hardly be accepted intodrivers/block/ as well, being a mere CF driver.
MBR, Sergei
Quoted 15 lines · Sergei Shtylyov
Hello.
Quoted 11 lines · David Daney
As part of our efforts to get the Cavium OCTEON processor support merged (see: http://marc.info/?l=linux-mips&m=122600487218824), we have this CF driver for your consideration.
Most OCTEON variants have *no* DMA or interrupt support on the CF interface so a simple bit-banging approach is taken. 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.
Quoted 6 lines
Quoted 3 lines
At this point I would like to get feedback as to whether this is a good approach for the CF driver, or perhaps generate ideas about other possible approaches.
It's totally unacceptable for
drivers/ide/as this is self-containeed
driver no using IDE core for anything, so this can only fit well todrivers/block/.
Not quite true, it is using ide_fix_driveid() and ide_fixstring(), but I get your point.
Quoted 1 line
OTOH, CF support via self-contained driver is certainly a waste of code since IDE core and (libata) are here to drive the CF devices as well. What we need is a "normal" IDE or libata (at your option) driver.
I will have to try it to see if the hardware has the necessary support.
Thanks,
David Daney
Hello
Quoted 11 lines · David Daney
Quoted 11 lines
Quoted 11 lines
As part of our efforts to get the Cavium OCTEON processor support merged (see: http://marc.info/?l=linux-mips&m=122600487218824), we have this CF driver for your consideration.
Most OCTEON variants have *no* DMA or interrupt support on the CF interface so a simple bit-banging approach is taken. 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.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
At this point I would like to get feedback as to whether this is a good approach for the CF driver, or perhaps generate ideas about other possible approaches.
It's totally unacceptable for
drivers/ide/as this is
self-containeed driver no using IDE core for anything, so this can only fit well todrivers/block/.Not quite true, it is using
ide_fix_driveid()andide_fixstring(), but I get your point.
Overlooked those. I just saw that it looked very alike the version
that I've seen -- hidden deep inside arch/mips/ at that time. :-)
Quoted 3 lines
OTOH, CF support via self-contained driver is certainly a waste of code since IDE core and (libata) are here to drive the CF devices as well. What we need is a "normal" IDE or libata (at your option) driver.
I will have to try it to see if the hardware has the necessary support.
It sure does have the necessary support -- this is a part of CF spec.
Quoted 2 lines
Thanks,
David Daney
WBR, Sergei
Quoted 3 lines
OTOH, CF support via self-contained driver is certainly a waste of code since IDE core and (libata) are here to drive the CF devices as well. What we need is a "normal" IDE or libata (at your option) driver.
A libata driver would be nice and probably easiest to do as you don't have to pretend to be close to old style taskfile IDE for a PC.
I am not convinced there is no case for a 'dumb' small CF driver, but if so the chipset code and the core code need to be separated as the other requests I see for this are different embedded boxes wanting to keep codesize down.
Alan
Hello.
Quoted 6 lines · Alan Cox
Quoted 2 lines
OTOH, CF support via self-contained driver is certainly a waste of code since IDE core and (libata) are here to drive the CF devices as well. What we need is a "normal" IDE or libata (at your option) driver.
A libata driver would be nice and probably easiest to do as you don't have to pretend to be close to old style taskfile IDE for a PC.
AFAIU you don't need to pretend that with IDE as well now.
Quoted 5 lines
I am not convinced there is no case for a 'dumb' small CF driver, but if so the chipset code and the core code need to be separated as the other requests I see for this are different embedded boxes wanting to keep codesize down.
Yeah, that might be worth considering...
Quoted 2 lines
Alan
WBR, Sergei