[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1197332844.9071.19.camel@pasglop>
Date: Tue, 11 Dec 2007 11:27:24 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Ralf Baechle <ralf@...ux-mips.org>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Yoichi Yuasa <yoichi_yuasa@...peaks.co.jp>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Greg KH <gregkh@...e.de>,
Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Subject: Re: Please revert: PCI: fix IDE legacy mode resources
> The GT-64111 system controller doesn't provide any kind of mapping
> functionality that would help here. So legacy port addressing can only
> work by exploiting aliases due to incomplete decoding of legacy ioport
> addreses by the VT82C586 - but direct addressing is impossible.
Ok, that explains how the "fix" that we reverted worked. It caused crap
to be added to the top bits of the address :-)
So here, what you really want to do is not a call to
pcibios_resource_to_bus(), but you actually want to use a different bus
address in the first place, that you know the HW will decode the same
way.
The best way to achieve that imho, is to do a header quirk that is run
just after the generic probe code, which offsets the fixed legacy
resources by 0x10000000 since that's really the bus address you are
going to emit.
Later on, your pcibios_fixup code should take that remove 0x10000000
from all IO resources, since your 0xd0000000 mapping already maps
0x10000000 as you probably already do.
The trick is, you don't want to convert a "resource" into a "bus
address" here, but really issue a different bus address.
Cheers,
Ben.
--
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