PalmLD IDE
Here it is, I hope it's not too rotten yet.
From 8881f9cbf66a3050de328f6c020f864ca04c1e9b Mon Sep 17 00:00:00 2001
From: Marek <[email protected]>
Date: Sat, 16 Aug 2008 16:25:34 +0200
Subject: [PATCH] PalmLD: IDE support
Support for Palm LifeDrive's internal harddrive
--- drivers/ata/Kconfig | 9 +++ drivers/ata/Makefile | 1 + drivers/ata/pata_palmld.c | 145 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 155 insertions(+), 0 deletions(-) create mode 100644 drivers/ata/pata_palmld.c
drivers/ata/Kconfig +9 -0
@@ -533,6 +533,15 @@ config PATA_OPTIDMA If unsure, say N. +config PATA_PALMLD + tristate "Palm LifeDrive PATA support" + depends on MACH_PALMLD + help + This option enables support for Palm LifeDrive's internal ATA + port via the new ATA layer. + + If unsure, say N. + config PATA_PCMCIA tristate "PCMCIA PATA support" depends on PCMCIA
drivers/ata/Makefile +1 -0
@@ -50,6 +50,7 @@ obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o obj-$(CONFIG_PATA_MARVELL) += pata_marvell.o obj-$(CONFIG_PATA_MPIIX) += pata_mpiix.o obj-$(CONFIG_PATA_OLDPIIX) += pata_oldpiix.o +obj-$(CONFIG_PATA_PALMLD) += pata_palmld.o obj-$(CONFIG_PATA_PCMCIA) += pata_pcmcia.o obj-$(CONFIG_PATA_PDC2027X) += pata_pdc2027x.o obj-$(CONFIG_PATA_PDC_OLD) += pata_pdc202xx_old.o
drivers/ata/pata_palmld.c new file +145 -0
145 lines not on this page · raw message
Signature · 1 line
1.5.6
Questions:
+ ATA_FLAG_NO_ATAPI
Is this a case of the controller cannot handle ATAPI in which case the flag is correct, or you can't conceive of a user finding a way to add an ATAPI device (but it would work as usually happens with basic PIO hardware) in which case it isn't.
+ /* we'd better wait for drive's ready signal here
+ (if we knew where it will come from) */
+ msleep(300);
Our probe code should already be waiting for ready signals ?
The only other question is a general architectural one as to whether it would be better to set up the GPIO etc and create a pata_platform platform device (possibly tweaking pata_platform flags to allow the caller to indicate generic pio with mode setting by set features command)
Alan
Quoted 8 lines · On Tuesday 21 of April 2009 16:27:35 Alan Cox wrote:
Questions:
+
ATA_FLAG_NO_ATAPIIs this a case of the controller cannot handle ATAPI in which case the flag is correct, or you can't conceive of a user finding a way to add an ATAPI device (but it would work as usually happens with basic PIO hardware) in which case it isn't.
http://www.palm.com/us/support/contact/environment/disassem_inst_Lifedrive.pdf , see slide 10 and 15 for yourself, I think noone would want to solder anything into that device ;-)
Quoted 6 lines
drivers/ata/pata_palmld.c new file +3
-0+/* we'd better wait for drive's ready signal here +(if we knew where it will come from) */ +msleep (300 );Our probe code should already be waiting for ready signals ?
The drive asserts some GPIO when it becomes ready, dunno which one though so we just wait here.
Quoted 6 lines
The only other question is a general architectural one as to whether it would be better to set up the GPIO etc and create a
pata_platformplatform device (possibly tweakingpata_platformflags to allow the caller to indicate generic pio with mode setting by set features command)
I already explained this to Eric, there isn't any other obscure hardware I think. Or if this is concerning something else, I'll recheck later.
Quoted 2 lines
Alan
Thanks
Marek
Quoted 3 lines
http://www.palm.com/us/support/contact/environment/disassem_inst_Lifedrive.pdf , see slide 10 and 15 for yourself, I think noone would want to solder anything into that device ;-)
Agreed but if the hardware can do it you don't need the flag. Obviously not very important in this case.
Quoted 9 lines
Quoted 6 lines
drivers/ata/pata_palmld.c new file +3
-0+/* we'd better wait for drive's ready signal here +(if we knew where it will come from) */ +msleep (300 );Our probe code should already be waiting for ready signals ?
The drive asserts some GPIO when it becomes ready, dunno which one though so we just wait here.
Ok so the ATA bus side ready isn't sufficient for your hardware ?
Quoted 7 lines
Quoted 4 lines
The only other question is a general architectural one as to whether it would be better to set up the GPIO etc and create a
pata_platformplatform device (possibly tweakingpata_platformflags to allow the caller to indicate generic pio with mode setting by set features command)I already explained this to Eric, there isn't any other obscure hardware I think. Or if this is concerning something else, I'll recheck later.
Quoted 6 lines · On Tuesday 21 of April 2009 17:19:33 Alan Cox wrote:
Quoted 3 lines
http://www.palm.com/us/support/contact/environment/disassem_inst_Lifedriv
e.pdf , see slide 10 and 15 for yourself, I think noone would want to solder anything into that device ;-)Agreed but if the hardware can do it you don't need the flag. Obviously not very important in this case.
OK, we can remove that, I'll resend the patch.
Quoted 11 lines
Quoted 9 lines
Quoted 6 lines
drivers/ata/pata_palmld.c new file +3
-0+/* we'd better wait for drive's ready signal here +(if we knew where it will come from) */ +msleep (300 );Our probe code should already be waiting for ready signals ?
The drive asserts some GPIO when it becomes ready, dunno which one though so we just wait here.
Ok so the ATA bus side ready isn't sufficient for your hardware ?
I can retry without the delay, but I'm quite afraid I ran into problems without it. Btw. I rewrote that driver more than half year ago, so I don't really recall the details, sorry, I don't want to misinform you here.
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
The only other question is a general architectural one as to whether it would be better to set up the GPIO etc and create a
pata_platformplatform device (possibly tweakingpata_platformflags to allow the caller to indicate generic pio with mode setting by set features command)I already explained this to Eric, there isn't any other obscure hardware I think. Or if this is concerning something else, I'll recheck later.
Quoted 5 lines
Quoted 1 line
Ok so the ATA bus side ready isn't sufficient for your hardware ?
I can retry without the delay, but I'm quite afraid I ran into problems without it. Btw. I rewrote that driver more than half year ago, so I don't really recall the details, sorry, I don't want to misinform you here.
No problem... its not as if it slows down anyone elses hardware.
Ok looks fine for merging - via the ARM tree seems best ?
Quoted 6 lines · Alan Cox
Quoted 2 lines
Quoted 1 line
Ok so the ATA bus side ready isn't sufficient for your hardware ?
I can retry without the delay, but I'm quite afraid I ran into problems without it. Btw. I rewrote that driver more than half year ago, so I don't really recall the details, sorry, I don't want to misinform you here.
No problem... its not as if it slows down anyone elses hardware.
Ok looks fine for merging - via the ARM tree seems best ?
ARM tree is fine, as long as there's an Acked-by from a libata person -- I nominate you, in this case :)
The version posted on 4/20 seemed fine to me (taking into account the ensuing thread, of course).
Jeff