Re: [PATCH 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
From: Tony Lindgren <tony@atomide.com>
Date: 2019-08-14 13:40:12
Also in:
linux-omap, lkml
* Arnd Bergmann [off-list ref] [190814 10:37]:
On Wed, Aug 14, 2019 at 9:49 AM Tony Lindgren [off-list ref] wrote:quoted
* Arnd Bergmann [off-list ref] [190813 19:34]:quoted
On Tue, Aug 13, 2019 at 8:12 PM Aaro Koskinen [off-list ref] wrote:diff --git a/arch/arm/mach-omap1/hardware.h b/arch/arm/mach-omap1/hardware.h index 232b8deef907..9fc76a3c9e57 100644 --- a/arch/arm/mach-omap1/hardware.h +++ b/arch/arm/mach-omap1/hardware.h@@ -61,7 +61,7 @@ static inline u32 omap_cs3_phys(void) #endif /* ifndef __ASSEMBLER__ */ -#define OMAP1_IO_OFFSET 0x01000000 /* Virtual IO= 0xfefb0000 */ +#define OMAP1_IO_OFFSET 0x00fb0000 /* Virtual IO = 0xff000000 */ #define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET) #include "serial.h"Oh OK yeah sounds like that's the issue.quoted
There may be additional locations that hardcode the virtual address.Those should be in mach-omap1/io.c, and I recall innovator had some hardcoded fpga address that should also be checked.I see four boards with hardcoded I/O addresses, but they are all below the PCI I/O virtual address range, and are not affected by that change. For the innovator FPGA access, this was ok, it uses the correct address in the OMAP1_IO_OFFSET range.
OK thanks for checking. I tried to apply your virtual address patch to test boot it, but could not get it to apply. What tree is it against? Regards, Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel