Bartlomiej Zolnierkiewicz escreveu:
On Thursday 07 May 2009 17:33:20 João Ramos wrote:
Alan Cox escreveu:
So you're saying I should support all PIO modes? If so, I would have to
make conditional code, checking perhaps a module param to sort which PIO
mode to use.
If you advertise PIO0-PIO4 as supported the core IDE code will do all the
work on figuring which modes are supported by the attached devices. You
just need to be able to set them.
Alan
Ok, so I've been studying that (I was quite lost for a time, I confess,
I'm not that much familiar with the IDE subsystem, so please bear with
me ;-) ).
So I need to set up a hook for 'set_pio_mode()', so that when the IDE
subsystem detects a device and figures the most suitable PIO mode for
the device, it will call the 'set_pio_mode' routine provided by the
driver in order to configure the host controller for that PIO mode.
This also means that my host controller driver should always default to
PIO Mode 0, as the initial host controller setup that is carried out by
the 'init_hwif' routine, allowing devices to be detected. Afterwards,
the IDE subsystem detects the most suitable PIO mode and calls
'set_pio_mode' to change that configuration.
Am I correct on this?
Yes! :)
There is still a room for improvement though -- it would be better to fix
IDE core to set PIO0 before probing devices for all host controllers.
Moreover it seems that doing it this way would allow us to remove ->init_hwif
method from this driver and do all necessary setup in ep93xx_ide_probe()
(this controller is a single port one so theoretically there shouldn't be
a need for having per-port ->init_hwif implementation).
So, I should remove the 'init_hwif' hook, and all the host controller
setup would be made in the driver's probe method, correct?
There's just only one issue; normally, I would setup the specific
timings (t0, t1, t2, t2i, etc) in the 'pio_set_mode' hook. However, if
you look further in the driver, those timings aren't defined through a
memory controller but instead manually enforced by 'ndelay' calls (arghhh).
This means that in my low-level procedures for reading and writing, I
need to have access to the timings (or the struct ide_timing)
corresponding to the PIO mode selected, in order to use the correct delays.
My question is: which is the best way to accomplish this? Declaring a
global struct ide_timing variable pointer that always holds the correct
ide_timing struct to the selected PIO mode? Or should I always check (in
some manner) what is the current PIO mode and then select the adequate
delays?
I think that the setting variable pointer in ->set_pio_mode method would
work best. Seems like the existing drive_data field of ide_drive_t is well
suited for this purpose (however it may be worth to convert it to 'void *'
type while we are it).
Ok, so I will set an struct ide_timing pointer in the 'set_pio_mode'
method, which will later be used by my low-level read/write procedures
to check the adequate IDE timings.
Thanks,
Bart
Best regards,
João Ramos
--
************************************************************************
João Ramos <joao.ramos@xxxxxxx>
INOV INESC Inovação - ESTG Leiria
Escola Superior de Tecnologia e Gestão de Leiria
Edíficio C1, Campus 2
Morro do Lena, Alto do Vieiro
Leiria
2411-901 Leiria
Portugal
Tel: +351244843424
Fax: +351244843424
************************************************************************
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
