From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-media@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
devicetree@vger.kernel.org,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Kamil Debski <k.debski@samsung.com>,
Andrzej Hajda <a.hajda@samsung.com>,
Kukjin Kim <kgene@kernel.org>,
Krzysztof Kozlowski <k.kozlowski@samsung.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [PATCH v2 4/7] media: vb2-dma-contig: add helper for setting dma max seg size
Date: Mon, 14 Dec 2015 17:50:50 +0200 [thread overview]
Message-ID: <1604824.dB2dzDMl5I@avalon> (raw)
In-Reply-To: <566E89D6.40603@samsung.com>
Hi Marek,
On Monday 14 December 2015 10:20:22 Marek Szyprowski wrote:
> On 2015-12-13 20:57, Laurent Pinchart wrote:
> > On Wednesday 09 December 2015 14:58:19 Marek Szyprowski wrote:
> >> Add a helper function for device drivers to set DMA's max_seg_size.
> >> Setting it to largest possible value lets DMA-mapping API always create
> >> contiguous mappings in DMA address space. This is essential for all
> >> devices, which use dma-contig videobuf2 memory allocator and shared
> >> buffers.
> >>
> >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >> ---
> >>
> >> drivers/media/v4l2-core/videobuf2-dma-contig.c | 15 +++++++++++++++
> >> include/media/videobuf2-dma-contig.h | 1 +
> >> 2 files changed, 16 insertions(+)
> >>
> >> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >> b/drivers/media/v4l2-core/videobuf2-dma-contig.c index c331272..628518d
> >> 100644
> >> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >> @@ -742,6 +742,21 @@ void vb2_dma_contig_cleanup_ctx(void *alloc_ctx)
> >>
> >> }
> >> EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx);
> >>
> >> +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int
> >> size)
> >> +{
> >> + if (!dev->dma_parms) {
> >
> > When can this function be called with dev->dma_parms not NULL ?
>
> When one loads a module with multimedia driver (which calls this
> function), then unloads and loads it again. It is rather safe to have this
> check.
Don't you have a much bigger problem in that case ? When you unload the module
the device will be unbound from the driver, causing the memory allocated by
devm_kzalloc to be freed. dev->dma_parms will then point to freed memory,
which will get reused by all subsequent calls to dma_get_max_seg_size(),
dma_get_max_seg_size() & co (including the ones in this function).
> >> + dev->dma_parms = devm_kzalloc(dev, sizeof(dev->dma_parms),
> >> + GFP_KERNEL);
> >> + if (!dev->dma_parms)
> >> + return -ENOMEM;
> >> + }
> >> + if (dma_get_max_seg_size(dev) < size)
> >> + return dma_set_max_seg_size(dev, size);
> >> +
> >> + return 0;
> >> +}
> >> +EXPORT_SYMBOL_GPL(vb2_dma_contig_set_max_seg_size);
> >> +
> >> MODULE_DESCRIPTION("DMA-contig memory handling routines for
> >> videobuf2");
> >> MODULE_AUTHOR("Pawel Osciak <pawel@osciak.com>");
> >> MODULE_LICENSE("GPL");
> >> diff --git a/include/media/videobuf2-dma-contig.h
> >> b/include/media/videobuf2-dma-contig.h index c33dfa6..0e6ba64 100644
> >> --- a/include/media/videobuf2-dma-contig.h
> >> +++ b/include/media/videobuf2-dma-contig.h
> >> @@ -26,6 +26,7 @@ vb2_dma_contig_plane_dma_addr(struct vb2_buffer *vb,
> >> unsigned int plane_no)
> >> void *vb2_dma_contig_init_ctx(struct device *dev);
> >> void vb2_dma_contig_cleanup_ctx(void *alloc_ctx);
> >> +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int
> >> size);
> >> extern const struct vb2_mem_ops vb2_dma_contig_memops;
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2015-12-14 15:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-09 13:58 [PATCH v2 0/7] Exynos: MFC driver: reserved memory cleanup and IOMMU support Marek Szyprowski
[not found] ` <1449669502-24601-1-git-send-email-m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-12-09 13:58 ` [PATCH v2 1/7] ARM: Exynos: convert MFC device to generic reserved memory bindings Marek Szyprowski
2015-12-09 13:58 ` Marek Szyprowski
2015-12-09 13:58 ` [PATCH v2 2/7] ARM: dts: exynos4412-odroid*: enable MFC device Marek Szyprowski
2015-12-10 7:44 ` Krzysztof Kozlowski
2015-12-10 7:45 ` Krzysztof Kozlowski
2015-12-09 13:58 ` [PATCH v2 3/7] of: reserved_mem: add support for named reserved mem nodes Marek Szyprowski
2015-12-09 13:58 ` [PATCH v2 4/7] media: vb2-dma-contig: add helper for setting dma max seg size Marek Szyprowski
2015-12-13 19:57 ` Laurent Pinchart
2015-12-14 9:20 ` Marek Szyprowski
2015-12-14 15:50 ` Laurent Pinchart [this message]
2015-12-15 8:40 ` Marek Szyprowski
2015-12-15 8:40 ` Marek Szyprowski
2015-12-09 13:58 ` [PATCH v2 5/7] media: set proper max seg size for devices on Exynos SoCs Marek Szyprowski
2015-12-09 13:58 ` [PATCH v2 6/7] media: s5p-mfc: replace custom reserved memory init code with generic one Marek Szyprowski
2015-12-09 13:58 ` [PATCH v2 7/7] media: s5p-mfc: add iommu support Marek Szyprowski
2015-12-13 19:52 ` [PATCH v2 0/7] Exynos: MFC driver: reserved memory cleanup and IOMMU support Laurent Pinchart
2015-12-14 9:42 ` Marek Szyprowski
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=1604824.dB2dzDMl5I@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=b.zolnierkie@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=k.debski@samsung.com \
--cc=k.kozlowski@samsung.com \
--cc=kgene@kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=s.nawrocki@samsung.com \
/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.