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>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.60.0704132018100.5919@poirot.grange>
Date:	Fri, 13 Apr 2007 21:19:04 +0200 (CEST)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	linux-kernel@...r.kernel.org
cc:	James Bottomley <James.Bottomley@...elEye.com>,
	Greg KH <greg@...ah.com>, Eric Miao <eric.y.miao@...il.com>
Subject: dma_declare_coherent_memory() for accessing platform-wide memory

Hi

On a PXA270 based system I modified the framebuffer driver to use SRAM on 
the SoC to reduce bus load caused by DMA transfers. For this I just 
assigned the entire SRAM to the fb driver. It works.

Then Eric Miao (CCed) rightfully noticed, that other devices might also 
benefit from using SRAM. So, I started thinking about creating a special 
(platform) device owning that SRAM block and making all its potential 
users its children. The device-local memory API even has provisional 
support for this with the DMA_MEMORY_INCLUDES_CHILDREN flag.

But there are problems with this approach too. For example, some PXA 
machines already occupy framebuffer's parent. I think, they are fixing 
power up/down sequence problems in this way, but I am not sure that's a 
good idea from the point of view of the bus locality.

Otherwise, maybe the best way would be assigning that SRAM block to the 
struct device platform_bus directly? But that way all platform devices 
would get their DMA buffers from that (rather small) block on the "first 
come first served" basis.

What would be the best way to solve this?

Thanks
Guennadi
---
Guennadi Liakhovetski
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ