Re: [PATCH] Generic platform device IDE driver

Paul Mundt wrote:
On Fri, Oct 13, 2006 at 08:52:19AM +0100, Russell King wrote:
On Thu, Oct 12, 2006 at 03:13:48PM +0900, Paul Mundt wrote:
Yes, that's one thing I was thinking of as well.. Here's a patch that
makes an attempt at that, can you give it a try and see if it works for
you? This applies on top of the earlier patch. None of the ARM, SH, or
H8300 cases need to do the remapping at least.
It's likely that ARM will switch over to using the MMIO resources if
this patch makes it in. There's certain ARM platforms which would
benefit from this change (since inb() and friends are more complex
than they necessarily need to be.)

However, one issue needs to be solved before we could do that - how do
we handle the case where the IDE registers are on a 4 byte spacing
interval instead of the usual 1 byte?

We could solve this in the driver, but it sounds like this is something
that libata should have some visibility of directly.

I notice that this driver is calling ata_std_ports() which handles
the standard setup. Maybe that needs to become a little more inteligent?

If we go this route, I suppose the easiest option will be simply to have
a private structure with a few function pointers for these sorts of
things, or we can simply have an element for the spacing interval if you
don't forsee needing to change the ioaddrs in any fashion beyond the
register spacing.. Which approach would you be more comfortable with?
Are there any other items that you're concerned with in the current
driver?


Here's the decision matrix for libata: Will the hardware use the standard taskfile push/pull functions like ata_tf_load(), ata_tf_read(), ata_exec_command(), etc.? If yes, simply replace ata_std_ports() call with a call to your own function, written similarly to pdc_ata_setup_port() in sata_promise.c.

If the hardware requires non-standard I/O accessors, or the register sizes themselves changed, then you must implement your own taskfile I/O functions, similar to k2_sata_tf_load(), k2_sata_tf_read(), and k2_bmdma_setup_mmio() in sata_svw.c. For this case, data in struct ata_ioports is largely up to you to manage, or ignore.

If there are special command setup or teardown operations, there are other standard hooks to override as well.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • VMI Interface Proposal Documentation for I386, Part 5
    ... to three register arguments. ... of the native instruction set. ... Most of these calls behave as standard C functions, and as such, may ... clobber registers EAX, EDX, ECX, flags. ...
    (Linux-Kernel)
  • Re: Major shortcoming in Paradox new panel lineup
    ... let me see if I have this straight Reg. ... This same senior tech also added that while arming or disarming ... the inability to arm with a simple ... against that standard is not something that we will enter into without ...
    (alt.security.alarms)
  • Re: Recursive Call
    ... On IBM mainframes there was/is a standard linkage convention to be followed ... Register 15 contains the "branch to" address and Register ... this save area at entry to the subroutine. ...
    (comp.lang.cobol)
  • Re: multiple threads and volatile
    ... Yet the standard tries to guarantee that your code will work. ... ensured to be copied from memory to register, ... threads conceptual machine nor the POSIX threads conceptual machine ...
    (comp.programming.threads)
  • Announcement: MyARM Release 1.0.0 Application Response Measurement tools
    ... MyARM: New ARM library released ... The version 4.0 of the Application Response Measurement (ARM) standard ...
    (comp.os.linux.announce)