All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hideki EIRAKU <hdk@igel.co.jp>
To: m.szyprowski@samsung.com
Cc: laurent.pinchart@ideasonboard.com, linux@arm.linux.org.uk,
	pawel@osciak.com, kyungmin.park@samsung.com,
	mchehab@infradead.org, FlorianSchandinat@gmx.de, perex@perex.cz,
	tiwai@suse.de, t.stanislaws@samsung.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linux-fbdev@vger.kernel.org, alsa-devel@alsa-project.org,
	matsu@igel.co.jp, dhobsong@igel.co.jp
Subject: Re: [PATCH v3 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available
Date: Thu, 16 Aug 2012 19:13:58 +0900 (JST)	[thread overview]
Message-ID: <20120816.191358.127675610.hdk@igel.co.jp> (raw)
In-Reply-To: <012701cd74ac$6a617060$3f245120$%szyprowski@samsung.com>

Hello,

From: Marek Szyprowski <m.szyprowski@samsung.com>
Subject: RE: [PATCH v3 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available
Date: Tue, 07 Aug 2012 16:53:25 +0200

> I'm sorry for bringing this issue now, once you have already created v3 of your
> patches, but similar patch has been already proposed some time ago. It is already
> processed together with general videobuf2-dma-contig redesign and dma-buf extensions
> by Tomasz Stanislawski.
> 
> See post http://thread.gmane.org/gmane.comp.video.dri.devel/70402/focus=49461 and
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49438 
> 
> It doesn't use conditional code inside videobuf2 allocator and rely entirely on 
> dma-mapping subsystem to provide a working dma_mmap_coherent/writecombine/attrs() 
> function. When it was posted, it relied on the dma-mapping extensions, which now
> have been finally merged to v3.6-rc1. Now I wonder if there are any architectures, 
> which don't use dma_map_ops based dma-mapping framework, which might use 
> videobuf2-dma-conting module. 

Thank you for telling me about videobuf2-dma-contig and v3.6-rc1.  The
videobuf2-dma-contig patch I sent is now unnecessary.  So I will
remove the patch.  I will remove the patch defining
ARCH_HAS_DMA_MMAP_COHERENT too because the v3.6-rc1 kernel has generic
dma_mmap_coherent() API for every architecture.

I will also remove the Laurent's patch I sent because it was related
to ARCH_HAS_DMA_MMAP_COHERENT.

The remaining patch is sh_mobile_lcdc.  I will remove ifdefs from the
patch and re-post it as a patch v4.

-- 
Hideki EIRAKU <hdk@igel.co.jp>

WARNING: multiple messages have this Message-ID (diff)
From: Hideki EIRAKU <hdk@igel.co.jp>
To: m.szyprowski@samsung.com
Cc: laurent.pinchart@ideasonboard.com, linux@arm.linux.org.uk,
	pawel@osciak.com, kyungmin.park@samsung.com,
	mchehab@infradead.org, FlorianSchandinat@gmx.de, perex@perex.cz,
	tiwai@suse.de, t.stanislaws@samsung.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linux-fbdev@vger.kernel.org, alsa-devel@alsa-project.org,
	matsu@igel.co.jp, dhobsong@igel.co.jp
Subject: Re: [PATCH v3 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available
Date: Thu, 16 Aug 2012 10:13:58 +0000	[thread overview]
Message-ID: <20120816.191358.127675610.hdk@igel.co.jp> (raw)
In-Reply-To: <012701cd74ac$6a617060$3f245120$%szyprowski@samsung.com>

Hello,

From: Marek Szyprowski <m.szyprowski@samsung.com>
Subject: RE: [PATCH v3 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available
Date: Tue, 07 Aug 2012 16:53:25 +0200

> I'm sorry for bringing this issue now, once you have already created v3 of your
> patches, but similar patch has been already proposed some time ago. It is already
> processed together with general videobuf2-dma-contig redesign and dma-buf extensions
> by Tomasz Stanislawski.
> 
> See post http://thread.gmane.org/gmane.comp.video.dri.devel/70402/focusI461 and
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49438 
> 
> It doesn't use conditional code inside videobuf2 allocator and rely entirely on 
> dma-mapping subsystem to provide a working dma_mmap_coherent/writecombine/attrs() 
> function. When it was posted, it relied on the dma-mapping extensions, which now
> have been finally merged to v3.6-rc1. Now I wonder if there are any architectures, 
> which don't use dma_map_ops based dma-mapping framework, which might use 
> videobuf2-dma-conting module. 

Thank you for telling me about videobuf2-dma-contig and v3.6-rc1.  The
videobuf2-dma-contig patch I sent is now unnecessary.  So I will
remove the patch.  I will remove the patch defining
ARCH_HAS_DMA_MMAP_COHERENT too because the v3.6-rc1 kernel has generic
dma_mmap_coherent() API for every architecture.

I will also remove the Laurent's patch I sent because it was related
to ARCH_HAS_DMA_MMAP_COHERENT.

The remaining patch is sh_mobile_lcdc.  I will remove ifdefs from the
patch and re-post it as a patch v4.

-- 
Hideki EIRAKU <hdk@igel.co.jp>

WARNING: multiple messages have this Message-ID (diff)
From: hdk@igel.co.jp (Hideki EIRAKU)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available
Date: Thu, 16 Aug 2012 19:13:58 +0900 (JST)	[thread overview]
Message-ID: <20120816.191358.127675610.hdk@igel.co.jp> (raw)
In-Reply-To: <012701cd74ac$6a617060$3f245120$%szyprowski@samsung.com>

Hello,

From: Marek Szyprowski <m.szyprowski@samsung.com>
Subject: RE: [PATCH v3 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available
Date: Tue, 07 Aug 2012 16:53:25 +0200

> I'm sorry for bringing this issue now, once you have already created v3 of your
> patches, but similar patch has been already proposed some time ago. It is already
> processed together with general videobuf2-dma-contig redesign and dma-buf extensions
> by Tomasz Stanislawski.
> 
> See post http://thread.gmane.org/gmane.comp.video.dri.devel/70402/focus=49461 and
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49438 
> 
> It doesn't use conditional code inside videobuf2 allocator and rely entirely on 
> dma-mapping subsystem to provide a working dma_mmap_coherent/writecombine/attrs() 
> function. When it was posted, it relied on the dma-mapping extensions, which now
> have been finally merged to v3.6-rc1. Now I wonder if there are any architectures, 
> which don't use dma_map_ops based dma-mapping framework, which might use 
> videobuf2-dma-conting module. 

Thank you for telling me about videobuf2-dma-contig and v3.6-rc1.  The
videobuf2-dma-contig patch I sent is now unnecessary.  So I will
remove the patch.  I will remove the patch defining
ARCH_HAS_DMA_MMAP_COHERENT too because the v3.6-rc1 kernel has generic
dma_mmap_coherent() API for every architecture.

I will also remove the Laurent's patch I sent because it was related
to ARCH_HAS_DMA_MMAP_COHERENT.

The remaining patch is sh_mobile_lcdc.  I will remove ifdefs from the
patch and re-post it as a patch v4.

-- 
Hideki EIRAKU <hdk@igel.co.jp>

  reply	other threads:[~2012-08-16 10:13 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-06  9:55 [PATCH v3 0/4] Use dma_mmap_coherent to support IOMMU mapper Hideki EIRAKU
2012-08-06  9:55 ` Hideki EIRAKU
2012-08-06  9:55 ` Hideki EIRAKU
2012-08-06  9:55 ` [PATCH v3 1/4] ARM: dma-mapping: define ARCH_HAS_DMA_MMAP_COHERENT Hideki EIRAKU
2012-08-06  9:55   ` Hideki EIRAKU
2012-08-06  9:55   ` Hideki EIRAKU
2012-08-07 15:22   ` Marek Szyprowski
2012-08-07 15:22     ` Marek Szyprowski
2012-08-07 15:22     ` Marek Szyprowski
2012-08-06  9:55 ` [PATCH v3 2/4] ALSA: pcm - Don't define ARCH_HAS_DMA_MMAP_COHERENT privately for ARM Hideki EIRAKU
2012-08-06  9:55   ` Hideki EIRAKU
2012-08-06  9:55   ` Hideki EIRAKU
2012-08-06  9:55   ` Hideki EIRAKU
2012-08-06  9:55 ` [PATCH v3 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available Hideki EIRAKU
2012-08-06  9:55   ` Hideki EIRAKU
2012-08-06  9:55   ` Hideki EIRAKU
2012-08-06  9:55   ` Hideki EIRAKU
2012-08-07 14:53   ` Marek Szyprowski
2012-08-07 14:53     ` Marek Szyprowski
2012-08-07 14:53     ` Marek Szyprowski
2012-08-16 10:13     ` Hideki EIRAKU [this message]
2012-08-16 10:13       ` Hideki EIRAKU
2012-08-16 10:13       ` Hideki EIRAKU
2012-08-16 10:39       ` Marek Szyprowski
2012-08-16 10:39         ` Marek Szyprowski
2012-08-16 10:39         ` Marek Szyprowski
2012-08-06  9:55 ` [PATCH v3 4/4] fbdev: sh_mobile_lcdc: " Hideki EIRAKU
2012-08-06  9:55   ` Hideki EIRAKU
2012-08-06  9:55   ` Hideki EIRAKU
2012-08-07 12:01   ` Laurent Pinchart
2012-08-07 12:01     ` Laurent Pinchart
2012-08-07 12:01     ` Laurent Pinchart
2012-08-07 12:01     ` Laurent Pinchart
2012-08-07 12:15     ` Laurent Pinchart
2012-08-07 12:15       ` Laurent Pinchart
2012-08-07 12:15       ` Laurent Pinchart
2012-08-07 12:15       ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120816.191358.127675610.hdk@igel.co.jp \
    --to=hdk@igel.co.jp \
    --cc=FlorianSchandinat@gmx.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=dhobsong@igel.co.jp \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=matsu@igel.co.jp \
    --cc=mchehab@infradead.org \
    --cc=pawel@osciak.com \
    --cc=perex@perex.cz \
    --cc=t.stanislaws@samsung.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.