Hi Arnd,
On Tuesday, April 10, 2012 1:43 PM Arnd Bergmann wrote:
On Tuesday 10 April 2012, Marek Szyprowski wrote:
This patch removes the need for offset parameter in dma bounce
functions. This is required to let dma-mapping framework on ARM
architecture use common, generic dma-mapping
Hi Arnd,
On Tuesday, April 10, 2012 1:47 PM Arnd Bergmann wrote:
On Tuesday 10 April 2012, Marek Szyprowski wrote:
This patch modifies dma-mapping implementation on ARM architecture to
use common dma_map_ops structure and asm-generic/dma-mapping-common.h
helpers.
Signed-off-by: Marek
This commit is taken from the Chromium tree and was originally written
by Robert Morell.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
include/drm/drm_fixed.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index
This commit adds device tree support for the GART hardware available on
NVIDIA Tegra 20 SoCs.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
arch/arm/boot/dts/tegra20.dtsi |6 ++
arch/arm/mach-tegra/board-dt-tegra20.c |1 +
drivers/iommu/tegra-gart.c
From: Vandana Salve vsa...@nvidia.com
Pass the correct gart device pointer.
Reviewed-by: Vandana Salve vsa...@nvidia.com
Tested-by: Vandana Salve vsa...@nvidia.com
Reviewed-by: Hiroshi Doyu hd...@nvidia.com
Reviewed-by: Bharat Nihalani bnihal...@nvidia.com
Signed-off-by: Hiroshi DOYU
Hi Arnd,
On Wednesday, April 11, 2012 2:19 PM Arnd Bergmann wrote:
On Wednesday 11 April 2012, Marek Szyprowski wrote:
Well, range sync functions are available from the early days of the dma
mapping api (at least that's what I've found reading the change log and
old patches). They are the
* Hiroshi Doyu wrote:
From: Thierry Reding thierry.red...@avionic-design.de
[...]
Thierry Reding (3):
iommu: tegra/gart: Add device tree support
drm: fixed: Add dfixed_frac() macro
drm: Add NVIDIA Tegra support
Vandana Salve (1):
iommu: tegra/gart: use correct gart_device
* Alan Cox wrote:
On Wed, 11 Apr 2012 14:10:26 +0200
Thierry Reding thierry.red...@avionic-design.de wrote:
This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It
currently only supports the RGB output and I've successfully tested it
against the fbcon kernel module and the
Hi!
These two patches fixes operation of the SYSMMU driver (v12 version [1])
with the new power domain driver based on generic power domains and
runtime pw, which has been merged to Linux kernel v3.4-rc1.
[1] https://lkml.org/lkml/2012/3/15/51
Best regards
Marek Szyprowski
Samsung Poland RD
Fix registration to runtime pw and add missing resume callback.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iommu/exynos-iommu.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git
SYSMMU platform devices must be registered before setting up power
domains to let power domain driver to correctly register also SYSMMU
controller devices. This patch also registers SYSMMU controller devices
to respective power domains.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Hi!
This is an example of the IOMMU aware DMA-mapping implementation usage
on a Samsung Exynos4 based NURI board. The ARM DMA-mapping IOMMU aware
implementation is available in the [1] thread:
This patch essentially registers DMA-mmaping/IOMMU support for FIMC and
MFC devices and performs some
This patch provides an provides setup code which assigns IOMMU controllers
to FIMC and MFC devices and enables IOMMU aware DMA-mapping for them.
It has been tested on Samsung Exynos4 platform, NURI board.
Most of the work is done in the s5p_sysmmu_late_init() function, which
first assigns SYSMMU
Hm, in that case it looks like your iommu works more like the gtt on intel
chips
Don't overgeneralize there - on the GMA500/600 the GTT doesn't allow CPU
side access of the GTT map (ie you can't use it to linearise pages for
CPU view) and the 3600 is even stranger
Alan
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 04:11:08PM +0200, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
This commit adds
* Alan Cox wrote:
Maybe your question is answered by my reply to Alan's comment. The mapping
is actually done to get a linear view for the display controller which
doesn't support SG transfers. The kernel and user-space already have virtual
linear buffers.
The framebuffer currently
Heh, vmap() is exactly what I do. =) Would you mind explaining why exactly it
is hideous?
On x86 we don't have a vast amount of address space available for virtual
remappings and the framebuffer then eats over 8MB of it.
The ideal case is that the fb layer can be taught to do page/offset
On Wednesday 11 April 2012, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra
Has this patch has been accepted? Is there anything else we must do?
Thanks and regards
Tony Camuso
--
Message: 1
Date: Thu, 29 Mar 2012 13:19:58 +
From: Mingarelli, Thomas thomas.mingare...@hp.com
To:
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the xf86-video-modesetting driver.
Only the RGB output is
On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
On Wed, Apr 11, 2012 at 04:11:08PM +0200, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
This commit adds a very basic DRM driver for
On Wed, Apr 11, 2012 at 03:43:09PM +0100, Alan Cox wrote:
Hm, in that case it looks like your iommu works more like the gtt on intel
chips
Don't overgeneralize there - on the GMA500/600 the GTT doesn't allow CPU
side access of the GTT map (ie you can't use it to linearise pages for
CPU
Hello.
Marek Szyprowski wrote:
Fix registration to runtime pw and add missing resume callback.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iommu/exynos-iommu.c | 20 ++--
1 files changed, 18
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds device tree support for the GART hardware available on
NVIDIA Tegra 20 SoCs.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
arch/arm/boot/dts/tegra20.dtsi |6 ++
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit is taken from the Chromium tree and was originally written
by Robert Morell.
Maybe just cherry-pick it from there? That way, the git authorship will
show up as Robert.
___
iommu mailing list
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the xf86-video-modesetting driver.
Only the RGB output is supported. Quite a lot of
27 matches
Mail list logo
