[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061013075219.GA28654@flint.arm.linux.org.uk>
Date: Fri, 13 Oct 2006 08:52:19 +0100
From: Russell King <rmk+lkml@....linux.org.uk>
To: Paul Mundt <lethal@...ux-sh.org>
Cc: Matthias Fuchs <matthias.fuchs@...-electronics.com>,
linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Jeff Garzik <jgarzik@...ox.com>
Subject: Re: [PATCH] Generic platform device IDE driver
On Thu, Oct 12, 2006 at 03:13:48PM +0900, Paul Mundt wrote:
> On Wed, Oct 11, 2006 at 02:50:41PM +0200, Matthias Fuchs wrote:
> > Perhaps it is a good idea to update the pata platform driver to be able to
> > handle both _IO and _MEM resources. The _IO resources be be handled
> > as it is already done by your code and for _MEM resources the pata platform
> > driver can do the ioremapping as I currently do in my board setup.
>
> 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?
I notice that this driver is calling ata_std_ports() which handles
the standard setup. Maybe that needs to become a little more inteligent?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists