Re: [PATCH] Add hook for custom xfer function in PATA Platform driver

[Sergei Shtylyov <sshtylyov@mvista.com>]

Hello.

Graeme Russ wrote:

    Sorry for the belated reply, I've been somewhat busy.

>>  If it ends up using it. I tend to think about it as a truly new hardware
>> needing a separate driver, so IDE support would really be out of question.

>>> Correct - it is a direct attachment of a CF card onto an 8-bit data bus

>>  And we have several *separate* drivers for the alike CF cases.

> Can you elaborate - I thought the PATA Platform driver was designed to
> unify the very discontguous approaches that have previously been taken
> in the embedded designs. As such, the need for these various drivers
> should diminished.

    Look at pata_ixp4xx_cf as an example. Part of what it does is 
override the sff_data_xfer() method to temporarily switch the bus from 
8-bit to 16-bit mode (i.e. *almost* the same thing as you're going to do 
in your override). Other CF drivers (like pata_octeon_cf) have DMA 
support though...

> [snip]

>>>>  Besides, Graeme, for what arch is your hardware? If it's PowerPC, you
>>>> should be using pata_of_platform -- but as I said you can't really do it.

>>> This is for an embedded x86 solutions (AMD SC520). Note: By embedded I
>>> really do mean embedded, not mini-PC or the like (i.e. no BIOS)

>>  Ah, I saw your initial request on u-boot maling list which mentioned OF
>> platfrom driver and assumed you might be on a PowerPC machine...

> Pardon my ignorance but when I asked that question I did not realise that
> 'OF' was 'Open Firmware' and, ergo, PPC

    Oh, there are ongoing efforts to port the most used concept of OF, 
i.e. device tree to ARM and MIPS... Hence, pata_of_platform would be 
able to run on these archs as well...

> [snip]

>>> if a driver has override hooks for over 50% of its functions and you are
>>> using all of those hooks then perhaps a dedicated driver is the way to go,
>>> but adding a 8-bit versus 16-bit access hook is probably the most trivial
>>> and fundamental hook you could add to a device driver (even more
>>> fundamental than the existing byte stuffing hook IMHO)

>>  What byte stuffing do you mean?

> Sorry, I meant the 'Port Shifting' (I/O port shift, for platforms with ports
> that are constantly spaced and need larger than the 1-byte spacing used by
> ata_std_ports())

> So yes, in theory, your original idea of adding an '8-bit flag' would be
> more in keeping with Port Shift (i.e. tell the driver to use a specifically
> non-standard function which *is* implemented in the driver core). But this
> goes back to my prior arguments - why pollute the driver core with non-
> standard functions

    8-bit I/O is pretty standard, just rarely used method of transfer in 
the ATA world. The PCMCIA ATA driver, pata_pcmcia implements it, for 
example.

> when a simple hook which is ignored if NULL will do.
> Now if we then find that many different developers are using a particular
> hook to do the same thing, that 'thing' becomes 'common' and gets merged
> into the driver core later.

>>> CF card. It is not a really high speed CPU (486 DX4100 equivalent) so
>>> supporting high speed data transfers without DMA is a bit pointless. The

>>  People wrote a lot of VLB drivers in order to get high PIO speeds on i486.
>> And PIO4 gives *significant* speed increase over PIO0. Although I suspect
>> libata's PIO speeds are still painfully low compared to IDE core -- need to

    I still really need to measure this another time...

>> re-check this with the recent kernel. So, chosing libata over IDE might not
>> be so obvious advantage as it seems...

> You will have tp pardon my ignorance - Until a few weeks ago I knew nothing
> about CF / IDE / ATA / PIO etc. I do not fully understand how the various
> PIO modes are implemented.

    The most important thing is that the higher is the PIO mode is, the 
lower is the transfer cycle time, and hence the transfer speed.

>>> only timing switch I care for is 'Accessing CF / Not Accessing CF' which
>>> has a timing difference of 5 or so bus cycles.

>>  There could be *negative* difference with high PIO modes -- PIO4-to-PIO0
>> cycle ratio is 5 (600:120).

> Sorry, I do not understand.

    PIO mode 0 (PIO0), the most compatible mode that should be 
implemented by default, has 600 ns transfer cycle; the highest standard 
PIO mode 4 (PIO4) has 120 ns cycle, so is (theoretically) 5 times faster 
than PIO0.

> Regards,

> Graeme

MBR, Sergei