CC arch/arm/mach-iop13xx/setup.o
arch/arm/mach-iop13xx/setup.c: In function 'iq8134x_probe_flash_size':
arch/arm/mach-iop13xx/setup.c:210: warning: implicit declaration of function 'ioremap'
arch/arm/mach-iop13xx/setup.c:210: warning: initialization makes pointer from integer without a cast
arch/arm/mach-iop13xx/setup.c:218: warning: implicit declaration of function 'writew'
arch/arm/mach-iop13xx/setup.c:222: warning: implicit declaration of function 'readb'
arch/arm/mach-iop13xx/setup.c:231: warning: implicit declaration of function 'iounmap'
LD .tmp_vmlinux1
arch/arm/mach-iop13xx/built-in.o: In function `iop13xx_platform_init':
iq81340mc.c:(.init.text+0x150): undefined reference to `ioremap'
iq81340mc.c:(.init.text+0x21c): undefined reference to `writew'
iq81340mc.c:(.init.text+0x24c): undefined reference to `writew'
iq81340mc.c:(.init.text+0x254): undefined reference to `iounmap'
iq81340mc.c:(.init.text+0x2c4): undefined reference to `readb'
iq81340mc.c:(.init.text+0x2e8): undefined reference to `readb'
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* architecture specific details are handled in asm/arch/time.h
* ARCH_IOP13XX now selects PLAT_IOP
* as suggested by Lennert use ifdef CONFIG_XSCALE to skip the cp_wait on
XSC3
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This functionality is replaced by cp6_trap
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Enable svc access to cp6 via an undefined instruction hook. Do not enable
access for usr code.
This patch also makes iop13xx select PLAT_IOP, this requires a small change
to drivers/i2c/busses/i2c-iop3xx.c.
Per Lennert Buytenhek's note, the cp6 trap routine is moved to arch/arm/plat-iop
Per Nicolas Pitre's note, the cp_wait is skipped since the latency to
return to the faulting function is longer than cp_wait.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Since iop13xx defines the PCI I/O spaces with physical resource addresses
the __io macro needs to perform the physical to virtual conversion. I
incorrectly assumed that this would be handled by ioremap, but drivers
(like e1000) directly dereference the address returned from __io.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* use irq_chip
* use handle_level_irq
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The struct resource 'end' field is inclusive, the iop13xx flash
setup code got this wrong.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The phys_io/io_pg_offst machine record variables were being set
to bogus values, causing problems when enabling DEBUG_LL.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The iop348 processor integrates an Xscale (XSC3 512KB L2 Cache) core with a
Serial Attached SCSI (SAS) controller, multi-ported DDR2 memory
controller, 3 Application Direct Memory Access (DMA) controllers, a 133Mhz
PCI-X interface, a x8 PCI-Express interface, and other peripherals to form
a system-on-a-chip RAID subsystem engine.
The iop342 processor replaces the SAS controller with a second Xscale core
for dual core embedded applications.
The iop341 processor is the single core version of iop342.
This patch supports the two Intel customer reference platforms iq81340mc
for external storage and iq81340sc for direct attach (HBA) development.
The developer's manual is available here:
ftp://download.intel.com/design/iio/docs/31503701.pdf
Changelog:
* removed virtual addresses from resource definitions
* cleaned up some unnecessary #include's
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
