* Arnd Bergmann wrote:
> On Wednesday 11 April 2012, Thierry Reding wrote:
> > Daniel Vetter wrote:
> > > Well, you use the iommu api to map/unmap memory into the iommu for tegra,
> > > whereas usually device drivers just use the dma api to do that. The usual
> > > interface is dma_map_sg/dma_unmap
* Stephen Warren wrote:
> 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 RG
* Stephen Warren wrote:
> 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.
I can do that. Though I'll have
* Stephen Warren wrote:
> 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
> > ---
> > arch/arm/boot/dts/tegra20.dtsi |6 ++
> > arch/arm/mach-
On Wed, Apr 11, 2012 at 11:34 PM, Marek Szyprowski
wrote:
> 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.
>
Thanks, Marek.
Your wa
Hi Thierry,
On Thursday, April 12, 2012 9:18 AM Thierry Reding wrote:
> * Arnd Bergmann wrote:
> > On Wednesday 11 April 2012, Thierry Reding wrote:
> > > Daniel Vetter wrote:
> > > > Well, you use the iommu api to map/unmap memory into the iommu for
> > > > tegra,
> > > > whereas usually device
Hello Marek,
On 04/11/2012 08:06 PM, Marek Szyprowski wrote:
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 t
Hi Subash,
On Thursday, April 12, 2012 11:06 AM Subash Patel wrote:
> On 04/11/2012 08:06 PM, Marek Szyprowski wrote:
> > 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
Hi Arnd,
On Tuesday, April 10, 2012 1:58 PM Arnd Bergmann wrote:
> On Tuesday 10 April 2012, Marek Szyprowski wrote:
> > +/**
> > + * arm_iommu_create_mapping
> > + * @bus: pointer to the bus holding the client device (for IOMMU calls)
> > + * @base: start address of the valid IO address space
>
* Sascha Hauer wrote:
> You might want to have a look at the sdrm patches I recently posted to
> dri-devel and arm Linux Kernel. Among other things they allow to
> register crtcs/connectors/encoders seperately so that each of them can
> have its own representation in the devicetree. I haven't looke
On Fri, Mar 30, 2012 at 11:03:49AM -0500, Omar Ramirez Luna wrote:
> 'domain_destroy with devices attached' case isn't yet handled, instead
> code assumes that the device was already detached.
>
> If the domain is destroyed the hardware still has access to invalid
> pointers to its page table and
On Thursday 12 April 2012, Marek Szyprowski wrote:
> +
> > > +/*
> > > + * s5p_sysmmu_late_init
> > > + * Create DMA-mapping IOMMU context for specified devices. This function
> > > must
> > > + * be called later, once SYSMMU driver gets registered and probed.
> > > + */
> > > +static int __init s
On Thursday 12 April 2012, Marek Szyprowski wrote:
> Scatter lists were initially designed for the disk based block io operations,
> hence the presence of the in-page offsets and lengths for each chunk. For
> multimedia use cases providing an array of struct pages and asking
> dma-mapping
> to
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Thursday, April 12, 2012 1:09 PM
> To: Marek Szyprowski
> Cc: 'Subash Patel'; linux-arm-ker...@lists.infradead.org;
> linaro-mm-...@lists.linaro.org;
> linux...@kvack.org; linux-a...@vger.kernel.org;
> iommu@lis
From: Marek Szyprowski
Subject: RE: [PATCH] ARM: Exynos4: integrate SYSMMU driver with DMA-mapping
interface
Date: Thu, 12 Apr 2012 14:13:37 +0200
Message-ID: <028f01cd18a5$b0721770$11564650$%szyprow...@samsung.com>
>
>
>
>
> > -Original Message-
> > From: Arnd Bergmann [mailto:a...@arnd
* Alex Deucher wrote:
> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
> wrote:
> > In other words I would like to use the Tegra hardware to render content into
> > a framebuffer (using potentially the 3D engine or HW accelerated video
> > decoding blocks) but display that framebuffer with a CRTC
Hi Arnd,
On Thursday, April 12, 2012 1:18 PM Arnd Bergmann wrote:
> On Thursday 12 April 2012, Marek Szyprowski wrote:
> > Scatter lists were initially designed for the disk based block io
> > operations,
> > hence the presence of the in-page offsets and lengths for each chunk. For
> > multimedi
* Marek Szyprowski wrote:
[...]
> We already have dma_map_page() and dma_map_single() which are very similar.
> Maybe adding dma_map_pages() won't be such a bad idea?
>
> If not maybe we should provide some kind of helper functions which converts
> page array to scatterlist and then maps them.
* Marek Szyprowski wrote:
> Hi Thierry,
>
> On Thursday, April 12, 2012 9:18 AM Thierry Reding wrote:
> > Also this doesn't yet solve the vmap() problem that is needed for the kernel
> > virtual mapping. I did try using dma_alloc_writecombine(), but that only
> > works for chunks of 2 MB or smalle
Hi Thierry,
On Thursday, April 12, 2012 3:42 PM Thierry Reding wrote:
> > > Also this doesn't yet solve the vmap() problem that is needed for the
> > > kernel
> > > virtual mapping. I did try using dma_alloc_writecombine(), but that only
> > > works for chunks of 2 MB or smaller, unless I use
>
On Wed, Apr 11, 2012 at 12:12:14PM -0600, Stephen Warren wrote:
> 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-v
On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
wrote:
> * Sascha Hauer wrote:
>> You might want to have a look at the sdrm patches I recently posted to
>> dri-devel and arm Linux Kernel. Among other things they allow to
>> register crtcs/connectors/encoders seperately so that each of them can
>>
On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
wrote:
> * Alex Deucher wrote:
>> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
>> wrote:
>> > In other words I would like to use the Tegra hardware to render content
>> > into
>> > a framebuffer (using potentially the 3D engine or HW accelerated
On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher wrote:
> On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
> wrote:
>> * Alex Deucher wrote:
>>> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
>>> wrote:
>>> > In other words I would like to use the Tegra hardware to render content
>>> > into
>>> >
On 04/12/2012 12:50 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> 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 t
* Alex Deucher wrote:
> On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher wrote:
> > On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
> >> Then again, having user-space control this may be more flexible.
> >> Performance-
> >> wise both should be about the same, right? What I don't quite understand
* Stephen Warren wrote:
> On 04/12/2012 12:50 AM, Thierry Reding wrote:
> > drm {
> > compatible = "nvidia,tegra20-drm";
>
> I'm don't think having an explicit "drm" node is the right approach; drm
> is after all a SW term and the DT should be describing HW. Having some
> kind of t
On 04/12/2012 11:44 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/12/2012 12:50 AM, Thierry Reding wrote:
>>> drm {
>>> compatible = "nvidia,tegra20-drm";
>>
>> I'm don't think having an explicit "drm" node is the right approach; drm
>> is after all a SW term and the
Am Mittwoch, den 11.04.2012, 15:18 + schrieb Arnd Bergmann:
> 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, T
29 matches
Mail list logo
