linux-kernel - Re: ioremap on system memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EBC4C27.3070400@gmail.com>
Date:	Fri, 11 Nov 2011 09:11:51 +1100
From:	Ryan Mallon <rmallon@...il.com>
To:	Marcus Folkesson <marcus.folkesson@...il.com>
CC:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	m.szyprowski@...sung.com
Subject: Re: ioremap on system memory

On 10/11/11 19:06, Marcus Folkesson wrote:

> Hi,
> 
> I'm working with a custom based platform based on OMAP-L138.
> A driver we are using is ioremapping system memory. It does this to
> share data between the GPP and DSP core.
> This is not allowed in later kernel versions since ARMv6+ does not support this.
> 
> Is there any good(and easy) way to get around this or is it so
> fundamentally wrong that the driver should be written from scratch?

Cc'ed the ARM kernel list and Marek Szyprowski (CMA developer). The CMA
patches I think do what you want, but I am not sure if they are merged
yet. The other solution (again, I'm not an expert on this area) is to
not pass the region of memory you want to manage as part of Linux's
normal system memory. See how the OMAP framebuffer driver reserves a
region of SDRAM (arch/arm/plat-omap/fb.c).

Some one else on the ARM list can probably explain in more detail.

~Ryan

--
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/