summaryrefslogtreecommitdiff
path: root/arch/arm/mach-iop13xx/setup.c
AgeCommit message (Collapse)Author
2019-05-08ARM: iop: don't use using 64-bit DMA masksArnd Bergmann
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ] clang warns about statically defined DMA masks from the DMA_BIT_MASK macro with length 64: arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type [-Werror,-Wshift-count-overflow] static u64 iop13xx_adma_dmamask = DMA_BIT_MASK(64); ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK' #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) ^ ~~~ The ones in iop shouldn't really be 64 bit masks, so changing them to what the driver can support avoids the warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2014-07-18ARM: 8101/1: mach-iop13xx: fix possible build failureArnd Bergmann
After applying patch: "ARM: 8078/1: get rid of hardcoded assumptions about kernel stack size" following build failure happens on iop13xx platform: In file included from include/linux/srcu.h:33:0, from include/linux/notifier.h:15, from include/linux/reboot.h:5, from arch/arm/mach-iop13xx/include/mach/iop13xx.h:6, from arch/arm/mach-iop13xx/include/mach/hardware.h:14, from arch/arm/mach-iop13xx/include/mach/memory.h:4, from arch/arm/include/asm/memory.h:24, from arch/arm/include/asm/page.h:163, from arch/arm/include/asm/thread_info.h:17, from include/linux/thread_info.h:54, from include/asm-generic/preempt.h:4, from arch/arm/include/generated/asm/preempt.h:1, from include/linux/preempt.h:18, from include/linux/spinlock.h:50, from include/linux/seqlock.h:35, from include/linux/time.h:5, from include/uapi/linux/timex.h:56, from include/linux/timex.h:56, from include/linux/sched.h:19, from arch/arm/kernel/asm-offsets.c:13: include/linux/rcupdate.h: In function '__rcu_read_lock': >> include/linux/rcupdate.h:220:2: error: implicit declaration of function 'preempt_disable' [-Werror=implicit-function-declaration] preempt_disable(); The problem here is recursive header inclusion which could be avoided by removing linux/reboot.h from mach/iop13xxx.h. linux/reboot.h in include/mach/iop13xx.h is needed only for enum reboot_mode, so header it could be replaced with a enum declaration. Whatever patch "ARM: 8078/1: get rid of hardcoded assumptions about kernel stack size" does, I think it's good to avoid unnecessary header inclusion here in any case. Reported-by: kbuild test robot <fengguang.wu@intel.com> Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-05-16arm: iop13xx: Use sparse irqs for MSIThomas Gleixner
No need for a private allocator. The core code handles it already. Allocate the non MSI irqs right at boot time via machine_desc->nr_irqs and let the sparse core handle the MSI space. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Grant Likely <grant.likely@linaro.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20140507154333.809210026@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2013-07-09reboot: arm: change reboot_mode to use enum reboot_modeRobin Holt
Preparing to move the parsing of reboot= to generic kernel code forces the change in reboot_mode handling to use the enum. [akpm@linux-foundation.org: fix arch/arm/mach-socfpga/socfpga.c] Signed-off-by: Robin Holt <holt@sgi.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Russ Anderson <rja@sgi.com> Cc: Robin Holt <holt@sgi.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-07-03drivers/dma: remove unused support for MEMSET operationsBartlomiej Zolnierkiewicz
There have never been any real users of MEMSET operations since they have been introduced in January 2007 by commit 7405f74badf4 ("dmaengine: refactor dmaengine around dma_async_tx_descriptor"). Therefore remove support for them for now, it can be always brought back when needed. [sebastian.hesselbarth@gmail.com: fix drivers/dma/mv_xor] Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Vinod Koul <vinod.koul@intel.com> Acked-by: Dan Williams <djbw@fb.com> Cc: Tomasz Figa <t.figa@samsung.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Olof Johansson <olof@lixom.net> Cc: Kevin Hilman <khilman@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-09-22Merge branch 'cleanup/__iomem' into next/cleanupOlof Johansson
__iomem annotation cleanup branch from Arnd. * cleanup/__iomem: (21 commits) net: seeq: use __iomem pointers for MMIO video: da8xx-fb: use __iomem pointers for MMIO scsi: eesox: use __iomem pointers for MMIO serial: ks8695: use __iomem pointers for MMIO input: rpcmouse: use __iomem pointers for MMIO ARM: samsung: use __iomem pointers for MMIO ARM: spear13xx: use __iomem pointers for MMIO ARM: sa1100: use __iomem pointers for MMIO ARM: prima2: use __iomem pointers for MMIO ARM: nomadik: use __iomem pointers for MMIO ARM: msm: use __iomem pointers for MMIO ARM: lpc32xx: use __iomem pointers for MMIO ARM: ks8695: use __iomem pointers for MMIO ARM: ixp4xx: use __iomem pointers for MMIO ARM: iop32x: use __iomem pointers for MMIO ARM: iop13xx: use __iomem pointers for MMIO ARM: integrator: use __iomem pointers for MMIO ARM: imx: use __iomem pointers for MMIO ARM: ebsa110: use __iomem pointers for MMIO ARM: at91: use __iomem pointers for MMIO ... Signed-off-by: Olof Johansson <olof@lixom.net>
2012-09-19ARM: iop13xx: use __iomem pointers for MMIOArnd Bergmann
ARM is moving to stricter checks on readl/write functions, so we need to use the correct types everywhere. Cc: Rob Herring <rob.herring@calxeda.com> Cc: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2012-07-26ARM: iop13xx: use fixed PCI i/o mappingRob Herring
Move iop13xx PCI to fixed i/o mapping and remove io.h. This changes the PCIe bus address to start at 0x10000. Let's hope this works. If it does not, the alternative would be to revert the value we write into OIOTVR to zero and set sys->io_offset to 64K. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
2012-01-05ARM: restart: iop13xx: use new restart hookRussell King
Hook these platforms restart code into the new restart hook rather than using arch_reset(). Acked-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-06-21net: remove mm.h inclusion from netdevice.hAlexey Dobriyan
Remove linux/mm.h inclusion from netdevice.h -- it's unused (I've checked manually). To prevent mm.h inclusion via other channels also extract "enum dma_data_direction" definition into separate header. This tiny piece is what gluing netdevice.h with mm.h via "netdevice.h => dmaengine.h => dma-mapping.h => scatterlist.h => mm.h". Removal of mm.h from scatterlist.h was tried and was found not feasible on most archs, so the link was cutoff earlier. Hope people are OK with tiny include file. Note, that mm_types.h is still dragged in, but it is a separate story. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-09-08dmaengine: cleanup unused transaction typesDan Williams
No drivers currently implement these operation types, so they can be deleted. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2009-09-08Merge branch 'md-raid6-accel' into ioat3.2Dan Williams
Conflicts: include/linux/dmaengine.h
2009-08-29async_tx: add support for asynchronous GF multiplicationDan Williams
[ Based on an original patch by Yuri Tikhonov ] This adds support for doing asynchronous GF multiplication by adding two additional functions to the async_tx API: async_gen_syndrome() does simultaneous XOR and Galois field multiplication of sources. async_syndrome_val() validates the given source buffers against known P and Q values. When a request is made to run async_pq against more than the hardware maximum number of supported sources we need to reuse the previous generated P and Q values as sources into the next operation. Care must be taken to remove Q from P' and P from Q'. For example to perform a 5 source pq op with hardware that only supports 4 sources at a time the following approach is taken: p, q = PQ(src0, src1, src2, src3, COEF({01}, {02}, {04}, {08})) p', q' = PQ(p, q, q, src4, COEF({00}, {01}, {00}, {10})) p' = p + q + q + src4 = p + src4 q' = {00}*p + {01}*q + {00}*q + {10}*src4 = q + {10}*src4 Note: 4 is the minimum acceptable maxpq otherwise we punt to synchronous-software path. The DMA_PREP_CONTINUE flag indicates to the driver to reuse p and q as sources (in the above manner) and fill the remaining slots up to maxpq with the new sources/coefficients. Note1: Some devices have native support for P+Q continuation and can skip this extra work. Devices with this capability can advertise it with dma_set_maxpq. It is up to each driver how to handle the DMA_PREP_CONTINUE flag. Note2: The api supports disabling the generation of P when generating Q, this is ignored by the synchronous path but is implemented by some dma devices to save unnecessary writes. In this case the continuation algorithm is simplified to only reuse Q as a source. Cc: H. Peter Anvin <hpa@zytor.com> Cc: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Yuri Tikhonov <yur@emcraft.com> Signed-off-by: Ilya Yanok <yanok@emcraft.com> Reviewed-by: Andre Noll <maan@systemlinux.org> Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2009-04-08async_tx: rename zero_sum to valDan Williams
'zero_sum' does not properly describe the operation of generating parity and checking that it validates against an existing buffer. Change the name of the operation to 'val' (for 'validate'). This is in anticipation of the p+q case where it is a requirement to identify the target parity buffers separately from the source buffers, because the target parity buffers will not have corresponding pq coefficients. Reviewed-by: Andre Noll <maan@systemlinux.org> Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2009-04-07dma-mapping: replace all DMA_64BIT_MASK macro with DMA_BIT_MASK(64)Yang Hongyang
Replace all DMA_64BIT_MASK macro with DMA_BIT_MASK(64) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-09-06[ARM] Convert asm/io.h to linux/io.hRussell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-08-07[ARM] Move include/asm-arm/arch-* to arch/arm/*/include/machRussell King
This just leaves include/asm-arm/plat-* to deal with. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-08-07[ARM] Remove asm/hardware.h, use asm/arch/hardware.h insteadRussell King
Remove includes of asm/hardware.h in addition to asm/arch/hardware.h. Then, since asm/hardware.h only exists to include asm/arch/hardware.h, update everything to directly include asm/arch/hardware.h and remove asm/hardware.h. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-03-06[ARM] replace remaining __FUNCTION__ occurrencesHarvey Harrison
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-07-13iop13xx: surface the iop13xx adma units to the iop-adma driverDan Williams
Adds the platform device definitions and the architecture specific support routines (i.e. register initialization and descriptor formats) for the iop-adma driver. Changelog: * added 'descriptor pool size' to the platform data * add base support for buffer sizes larger than 16MB (hw max) * build error fix from Kirill A. Shutemov * rebase for async_tx changes * add interrupt support * do not call platform register macros in driver code * remove unnecessary ARM assembly statement * checkpatch.pl fixes * gpl v2 only correction Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2007-04-30[ARM] 4344/1: iop13xx: do not claim both uarts by default on iop342Dan Williams
Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-20[ARM] Fix iop13xx build errorRussell King
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>
2006-12-18[ARM] 4056/1: iop13xx: fix resource.end off-by-one in flash setupLennert Buytenhek
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>
2006-12-07[ARM] 3995/1: iop13xx: add iop13xx supportDan Williams
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>