From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Fri, 28 Sep 2012 11:42:16 +0100 Subject: [PATCH] ARM: optimize memset_io()/memcpy_fromio()/memcpy_toio() In-Reply-To: <20120928103109.GD7916@n2100.arm.linux.org.uk> References: <20120928095808.GB18125@mudshark.cambridge.arm.com> <20120928103109.GD7916@n2100.arm.linux.org.uk> Message-ID: <20120928104216.GC18125@mudshark.cambridge.arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Sep 28, 2012 at 11:31:10AM +0100, Russell King - ARM Linux wrote: > On Fri, Sep 28, 2012 at 10:58:08AM +0100, Will Deacon wrote: > > 1. If an access other the first one generated by the instruction > > causes an abort, the CPU will ultimately re-execute the earlier > > accesses, which could be problematic to a device. > > I don't think that's a problem for these. They're used on RAM like > regions. [...] > > So, unless we can guarantee that our accesses are all aligned, will never > > fault, do not cross a page boundary and we are not running as a guest then > > I'd be inclined to stick with byte-by-byte implementations for these > > functions. > > Well, that rather sucks if you're memset_io'ing various sizes (in > megabytes - up to 8MB) of video memory. We desperately need these > functions optimized. How are these regions mapped? If it's something like ioremap_wc, then this gives us normal non-cacheable memory on ARMv7, which wouldn't be subject to the restrictions that you have with device memory. > Either that or we allow DRM to be a security hole by omitting any kind > of buffer clearing, because using the existing memset_io() is just far > too expensive to clear 8MB a byte at a time. If DRM is using normal memory, it sounds like the *_io string functions need to be made to work with different memory types. Will