Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework
On Fri, 20 Aug 2010 08:38:10 +0200 **UNKNOWN CHARSET** wrote: > On Fri, 20 Aug 2010 05:12:50 +0200, FUJITA Tomonori > wrote: > >> 1. Integration on API level meaning that some kind of existing API is used > >> instead of new cma_*() calls. CMA adds notion of devices and memory > >> types which is new to all the other APIs (coherent has notion of > >> devices > >> but that's not enough). This basically means that no existing API can > >> be > >> used for CMA. On the other hand, removing notion of devices and memory > >> types would defeat the whole purpose of CMA thus destroying the > >> solution > >> that CMA provides. > > > > You can create something similar to the existing API for memory > > allocator. > > That may be tricky. cma_alloc() takes four parameters each of which is > required for CMA. No other existing set of API uses all those arguments. > This means, CMA needs it's own, somehow unique API. I don't quite see > how the APIs may be unified or "made similar". Of course, I'm gladly > accepting suggestions. Have you even tried to search 'blk_kmalloc' on google? I wrote "similar to the existing API', not "reuse the existing API". > >> 2. Reuse of memory pools meaning that memory reserved by CMA can then be > >> used by other allocation mechanisms. This is of course possible. For > >> instance coherent could easily be implemented as a wrapper to CMA. > >> This is doable and can be done in the future after CMA gets more > >> recognition. > >> > >> 3. Reuse of algorithms meaning that allocation algorithms used by other > >> allocators will be used with CMA regions. This is doable as well and > >> can be done in the future. > > > > Well, why can't we do the above before the inclusion? > > Because it's quite a bit of work and instead of diverting my attention I'd > prefer to make CMA as good as possible and then integrate it with other > subsystems. Also, adding the integration would change the patch from being > 4k lines to being like 40k lines. 4k to 40k? I'm not sure. But If I see something like the following, I suspect that there is a better way to integrate this into the existing infrastructure. mm/cma-best-fit.c | 407 +++ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework
On Fri, 20 Aug 2010 05:12:50 +0200, FUJITA Tomonori wrote: 1. Integration on API level meaning that some kind of existing API is used instead of new cma_*() calls. CMA adds notion of devices and memory types which is new to all the other APIs (coherent has notion of devices but that's not enough). This basically means that no existing API can be used for CMA. On the other hand, removing notion of devices and memory types would defeat the whole purpose of CMA thus destroying the solution that CMA provides. You can create something similar to the existing API for memory allocator. That may be tricky. cma_alloc() takes four parameters each of which is required for CMA. No other existing set of API uses all those arguments. This means, CMA needs it's own, somehow unique API. I don't quite see how the APIs may be unified or "made similar". Of course, I'm gladly accepting suggestions. 2. Reuse of memory pools meaning that memory reserved by CMA can then be used by other allocation mechanisms. This is of course possible. For instance coherent could easily be implemented as a wrapper to CMA. This is doable and can be done in the future after CMA gets more recognition. 3. Reuse of algorithms meaning that allocation algorithms used by other allocators will be used with CMA regions. This is doable as well and can be done in the future. Well, why can't we do the above before the inclusion? Because it's quite a bit of work and instead of diverting my attention I'd prefer to make CMA as good as possible and then integrate it with other subsystems. Also, adding the integration would change the patch from being 4k lines to being like 40k lines. What I'm trying to say is that I don't consider that a work for now but rather a further enchantments. Anyway, I think that comments from mm people would be helpful to merge this. Yes, I agree. -- Best regards,_ _ | Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o | Computer Science, Michał "mina86" Nazarewicz (o o) +[mina86*mina86.com]---[mina86*jabber.org]ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework
> >> We hope this method included at mainline kernel if possible. > >> It's really needed feature for our multimedia frameworks. > > > > You got any comments from mm people? > > > > Virtually, this adds a new memory allocator implementation that steals > > some memory from memory allocator during boot process. Its API looks > > completely different from the API for memory allocator. That doesn't > > sound appealing to me much. This stuff couldn't be integrated well > > into memory allocator? > > What kind of integration do you mean? I see three levels: > > 1. Integration on API level meaning that some kind of existing API is used > instead of new cma_*() calls. CMA adds notion of devices and memory > types which is new to all the other APIs (coherent has notion of devices > but that's not enough). This basically means that no existing API can be > used for CMA. On the other hand, removing notion of devices and memory > types would defeat the whole purpose of CMA thus destroying the solution > that CMA provides. You can create something similar to the existing API for memory allocator. For example, blk_kmalloc/blk_alloc_pages was proposed as memory allocator API with notion of an address range for allocated memory. It wasn't merged for other reasons though. I don't mean that this is necessary for the inclusion (I'm not the person to ack or nack this). I just expect the similarity of memory allocator API. > 2. Reuse of memory pools meaning that memory reserved by CMA can then be > used by other allocation mechanisms. This is of course possible. For > instance coherent could easily be implemented as a wrapper to CMA. > This is doable and can be done in the future after CMA gets more > recognition. > > 3. Reuse of algorithms meaning that allocation algorithms used by other > allocators will be used with CMA regions. This is doable as well and > can be done in the future. Well, why can't we do the above before the inclusion? Anyway, I think that comments from mm people would be helpful to merge this. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework
On Thu, 19 Aug 2010 17:15:12 +0200, FUJITA Tomonori wrote: On Wed, 18 Aug 2010 12:01:35 +0900 Kyungmin Park wrote: Are there any comments or ack? We hope this method included at mainline kernel if possible. It's really needed feature for our multimedia frameworks. You got any comments from mm people? Virtually, this adds a new memory allocator implementation that steals some memory from memory allocator during boot process. Its API looks completely different from the API for memory allocator. That doesn't sound appealing to me much. This stuff couldn't be integrated well into memory allocator? What kind of integration do you mean? I see three levels: 1. Integration on API level meaning that some kind of existing API is used instead of new cma_*() calls. CMA adds notion of devices and memory types which is new to all the other APIs (coherent has notion of devices but that's not enough). This basically means that no existing API can be used for CMA. On the other hand, removing notion of devices and memory types would defeat the whole purpose of CMA thus destroying the solution that CMA provides. 2. Reuse of memory pools meaning that memory reserved by CMA can then be used by other allocation mechanisms. This is of course possible. For instance coherent could easily be implemented as a wrapper to CMA. This is doable and can be done in the future after CMA gets more recognition. 3. Reuse of algorithms meaning that allocation algorithms used by other allocators will be used with CMA regions. This is doable as well and can be done in the future. -- Best regards,_ _ | Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o | Computer Science, Michał "mina86" Nazarewicz (o o) +[mina86*mina86.com]---[mina86*jabber.org]ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework
On Thu, 19 Aug 2010 16:47:56 +0200, Konrad Rzeszutek Wilk wrote: Is there a git tree and/or link to the latest version that is based on top 2.6.36-rc1?? I somehow seem to have lost the v3 of these patches. I'm currently working on a v4 of the patchset after some comments from Hans Verkuil on the #v4l. I should manage to post it today (Korean time). -- Best regards,_ _ | Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o | Computer Science, Michał "mina86" Nazarewicz (o o) +[mina86*mina86.com]---[mina86*jabber.org]ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Aug 19 19:00:19 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15074:eff98a88caf3 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: WARNINGS linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.20-i686: ERRORS linux-2.6.26.8-i686: ERRORS linux-2.6.27.44-i686: ERRORS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: WARNINGS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.20-x86_64: ERRORS linux-2.6.26.8-x86_64: ERRORS linux-2.6.27.44-x86_64: ERRORS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: WARNINGS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH v3 00/10] Media controller (core and V4L2)
> -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Thursday, August 19, 2010 2:12 PM > To: Aguirre, Sergio > Cc: linux-media@vger.kernel.org; sakari.ai...@maxwell.research.nokia.com > Subject: Re: [RFC/PATCH v3 00/10] Media controller (core and V4L2) > > Hi Sergio, > > On Thursday 19 August 2010 21:09:30 Aguirre, Sergio wrote: > > > -Original Message- > > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart > > > Sent: Thursday, July 29, 2010 11:07 AM > > > To: linux-media@vger.kernel.org > > > Cc: sakari.ai...@maxwell.research.nokia.com > > > Subject: [RFC/PATCH v3 00/10] Media controller (core and V4L2) > > > > > > Hi everybody, > > > > > > Here's the third version of the media controller patches. All comments > > > received on the first and second versions have (hopefully) been > > > incorporated. > > > > > > The rebased V4L2 API additions and OMAP3 ISP patches will follow. Once > > > again please consider them as sample code only. > > > > > > Laurent Pinchart (8): > > > media: Media device node support > > > media: Media device > > > media: Entities, pads and links > > > media: Entities, pads and links enumeration > > > media: Links setup > > > v4l: Add a media_device pointer to the v4l2_device structure > > > v4l: Make video_device inherit from media_entity > > > v4l: Make v4l2_subdev inherit from media_entity > > > > This patch (#0010) doesn't apply to mainline, after this commit: > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux- > 2.6.git;a=commit;h > > =b74c0aac357e5c71ee6de98b9887fe478bc73cf4 > > > > Am I missing something here? > > Yes, you're missing the next version of the patches :-) I'll probably send > them tomorrow. Ohh ok, :) Thanks! Regards, Sergio > > -- > Regards, > > Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v3 00/10] Media controller (core and V4L2)
Hi Sergio, On Thursday 19 August 2010 21:09:30 Aguirre, Sergio wrote: > > -Original Message- > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart > > Sent: Thursday, July 29, 2010 11:07 AM > > To: linux-media@vger.kernel.org > > Cc: sakari.ai...@maxwell.research.nokia.com > > Subject: [RFC/PATCH v3 00/10] Media controller (core and V4L2) > > > > Hi everybody, > > > > Here's the third version of the media controller patches. All comments > > received on the first and second versions have (hopefully) been > > incorporated. > > > > The rebased V4L2 API additions and OMAP3 ISP patches will follow. Once > > again please consider them as sample code only. > > > > Laurent Pinchart (8): > > media: Media device node support > > media: Media device > > media: Entities, pads and links > > media: Entities, pads and links enumeration > > media: Links setup > > v4l: Add a media_device pointer to the v4l2_device structure > > v4l: Make video_device inherit from media_entity > > v4l: Make v4l2_subdev inherit from media_entity > > This patch (#0010) doesn't apply to mainline, after this commit: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h > =b74c0aac357e5c71ee6de98b9887fe478bc73cf4 > > Am I missing something here? Yes, you're missing the next version of the patches :-) I'll probably send them tomorrow. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH v3 00/10] Media controller (core and V4L2)
Hi Laurent, > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart > Sent: Thursday, July 29, 2010 11:07 AM > To: linux-media@vger.kernel.org > Cc: sakari.ai...@maxwell.research.nokia.com > Subject: [RFC/PATCH v3 00/10] Media controller (core and V4L2) > > Hi everybody, > > Here's the third version of the media controller patches. All comments > received > on the first and second versions have (hopefully) been incorporated. > > The rebased V4L2 API additions and OMAP3 ISP patches will follow. Once > again > please consider them as sample code only. > > Laurent Pinchart (8): > media: Media device node support > media: Media device > media: Entities, pads and links > media: Entities, pads and links enumeration > media: Links setup > v4l: Add a media_device pointer to the v4l2_device structure > v4l: Make video_device inherit from media_entity > v4l: Make v4l2_subdev inherit from media_entity This patch (#0010) doesn't apply to mainline, after this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b74c0aac357e5c71ee6de98b9887fe478bc73cf4 Am I missing something here? Regards, Sergio > > Sakari Ailus (2): > media: Entity graph traversal > media: Reference count and power handling > > Documentation/media-framework.txt| 481 > Documentation/video4linux/v4l2-framework.txt | 71 +++- > drivers/media/Makefile |8 +- > drivers/media/media-device.c | 327 ++ > drivers/media/media-devnode.c| 326 ++ > drivers/media/media-entity.c | 613 > ++ > drivers/media/video/v4l2-dev.c | 35 ++- > drivers/media/video/v4l2-device.c| 45 ++- > drivers/media/video/v4l2-subdev.c| 27 ++- > include/linux/media.h| 78 > include/media/media-device.h | 70 +++ > include/media/media-devnode.h| 84 > include/media/media-entity.h | 107 + > include/media/v4l2-dev.h |6 + > include/media/v4l2-device.h |2 + > include/media/v4l2-subdev.h |7 + > 16 files changed, 2265 insertions(+), 22 deletions(-) > create mode 100644 Documentation/media-framework.txt > create mode 100644 drivers/media/media-device.c > create mode 100644 drivers/media/media-devnode.c > create mode 100644 drivers/media/media-entity.c > create mode 100644 include/linux/media.h > create mode 100644 include/media/media-device.h > create mode 100644 include/media/media-devnode.h > create mode 100644 include/media/media-entity.h > > -- > Regards, > > Laurent Pinchart > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mt9t031: Fixes field names that changed
If CONFIG_VIDEO_ADV_DEBUG was set, the driver failed to compile
because the fields get_register and set_register changed names to
g_register and s_register in the struct v4l2_subdev_core_ops.
Signed-off-by: Henrique Camargo
---
drivers/media/video/mt9t031.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index 716fea6..f3d1995 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -499,8 +499,8 @@ static const struct v4l2_subdev_core_ops mt9t031_core_ops =
{
.g_ctrl = mt9t031_get_control,
.s_ctrl = mt9t031_set_control,
#ifdef CONFIG_VIDEO_ADV_DEBUG
- .get_register = mt9t031_get_register,
- .set_register = mt9t031_set_register,
+ .g_register = mt9t031_get_register,
+ .s_register = mt9t031_set_register,
#endif
};
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixes field names that changed
Thank you Sergio for your help, I resent the patch a couple of minutes
ago taking your changes into account.
Best Regards,
Henrique Camargo
On Wed, 2010-08-18 at 19:18 -0500, Aguirre, Sergio wrote:
> Oops, fixing my own typo below:
>
> > -Original Message-
> > From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> > ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
> > Sent: Wednesday, August 18, 2010 7:16 PM
> > To: henri...@henriquecamargo.com; Mauro Carvalho Chehab
> > Cc: Guennadi Liakhovetski; Karicheri, Muralidharan; linux-
> > me...@vger.kernel.org; linux-ker...@vger.kernel.org
> > Subject: RE: [PATCH] Fixes field names that changed
> >
> > Hi Henrique,
> >
> > Just some minor comments about the patch description below:
> >
> > > -Original Message-
> > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> > > ow...@vger.kernel.org] On Behalf Of Henrique Camargo
> > > Sent: Tuesday, August 17, 2010 9:35 AM
> > > To: Mauro Carvalho Chehab
> > > Cc: Guennadi Liakhovetski; Karicheri, Muralidharan; linux-
> > > me...@vger.kernel.org; linux-ker...@vger.kernel.org
> > > Subject: [PATCH] Fixes field names that changed
> >
> > Add missing subject prefix to quickly describe the affected driver:
> >
> > Subject: [PATCH] mt9t032: Fixes field names that changed
>
> mt9t032 -> mt9t031.
>
> Sorry...
>
> Regards,
> Sergio
> >
> > >
> > > If CONFIG_VIDEO_ADV_DEBUG was set, the driver failed to compile because
> > > the fields get_register and set_register changed names to s_register and
> > > s_register in the struct v4l2_subdev_core_ops.
> >
> > Please break down this comment to 70 chars max.
> >
> > Also, you said "s_register" twice.
> >
> > Regards,
> > Sergio
> >
> > >
> > > Signed-off-by: Henrique Camargo
> > > ---
> > > drivers/media/video/mt9t031.c |4 ++--
> > > 1 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/media/video/mt9t031.c
> > b/drivers/media/video/mt9t031.c
> > > index 716fea6..f3d1995 100644
> > > --- a/drivers/media/video/mt9t031.c
> > > +++ b/drivers/media/video/mt9t031.c
> > > @@ -499,8 +499,8 @@ static const struct v4l2_subdev_core_ops
> > > mt9t031_core_ops = {
> > > .g_ctrl = mt9t031_get_control,
> > > .s_ctrl = mt9t031_set_control,
> > > #ifdef CONFIG_VIDEO_ADV_DEBUG
> > > - .get_register = mt9t031_get_register,
> > > - .set_register = mt9t031_set_register,
> > > + .g_register = mt9t031_get_register,
> > > + .s_register = mt9t031_set_register,
> > > #endif
> > > };
> > >
> > > --
> > > 1.7.0.4
> > >
> > >
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-media"
> > in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] tm6000: depends on IR_CORE
From: Randy Dunlap tm6000 uses IR interfaces, so it should depend on IR_CORE. ERROR: "get_rc_map" [drivers/staging/tm6000/tm6000.ko] undefined! ERROR: "ir_input_unregister" [drivers/staging/tm6000/tm6000.ko] undefined! ERROR: "__ir_input_register" [drivers/staging/tm6000/tm6000.ko] undefined! Signed-off-by: Randy Dunlap --- drivers/staging/tm6000/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20100819.orig/drivers/staging/tm6000/Kconfig +++ linux-next-20100819/drivers/staging/tm6000/Kconfig @@ -1,6 +1,6 @@ config VIDEO_TM6000 tristate "TV Master TM5600/6000/6010 driver" - depends on VIDEO_DEV && I2C && INPUT && USB && EXPERIMENTAL + depends on VIDEO_DEV && I2C && INPUT && IR_CORE && USB && EXPERIMENTAL select VIDEO_TUNER select MEDIA_TUNER_XC2028 select MEDIA_TUNER_XC5000 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Thursday, August 19, 2010 08:09:27 pm Janusz Krzysztofik wrote:
> Thursday 19 August 2010 14:16:21 Marin Mitov napisał(a):
> > On Thursday, August 19, 2010 02:39:47 pm Guennadi Liakhovetski wrote:
> > >
> > > No, I don't think you should go to the next power of 2 - that's too
> > > crude. Try rounding your buffer size to the page size, that should
> > > suffice.
>
> Guennadi,
> If you have a look at how a device reserved memory is next allocated to a
> driver with drivers/base/dma-coherent.c::dma_alloc_from_coherent(), then than
> you may find my conclusion on a power of 2 as true:
>
> int dma_alloc_from_coherent(struct device *dev, ssize_t size,
> dma_addr_t *dma_handle, void **ret)
> {
> ...
> int order = get_order(size);
> ...
> pageno = bitmap_find_free_region(mem->bitmap, mem->size, order);
> ...
> }
>
>
> > Allocated coherent memory is always a power of 2.
>
> Marin,
> For ARM, this seems true as long as allocated with the above from a device
> assigned pool, but not true for a (pre)allocation from a generic system RAM.
> See arch/arm/mm/dma-mapping.c::__dma_alloc_buffer(), where it looks like
> extra
> pages are freed:
>
> static struct page *__dma_alloc_buffer(struct device *dev, size_t size, gfp_t
> gfp)
> {
> unsigned long order = get_order(size);
> ...
> page = alloc_pages(gfp, order);
> ...
> split_page(page, order);
> for (p = page + (size >> PAGE_SHIFT), e = page + (1 << order); p < e;
> p++)
> __free_page(p);
> ...
> }
Thanks for the clarification.
Marin Mitov
>
>
> Thanks,
> Janusz
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
Thursday 19 August 2010 14:16:21 Marin Mitov napisał(a):
> On Thursday, August 19, 2010 02:39:47 pm Guennadi Liakhovetski wrote:
> >
> > No, I don't think you should go to the next power of 2 - that's too
> > crude. Try rounding your buffer size to the page size, that should
> > suffice.
Guennadi,
If you have a look at how a device reserved memory is next allocated to a
driver with drivers/base/dma-coherent.c::dma_alloc_from_coherent(), then than
you may find my conclusion on a power of 2 as true:
int dma_alloc_from_coherent(struct device *dev, ssize_t size,
dma_addr_t *dma_handle, void **ret)
{
...
int order = get_order(size);
...
pageno = bitmap_find_free_region(mem->bitmap, mem->size, order);
...
}
> Allocated coherent memory is always a power of 2.
Marin,
For ARM, this seems true as long as allocated with the above from a device
assigned pool, but not true for a (pre)allocation from a generic system RAM.
See arch/arm/mm/dma-mapping.c::__dma_alloc_buffer(), where it looks like extra
pages are freed:
static struct page *__dma_alloc_buffer(struct device *dev, size_t size, gfp_t
gfp)
{
unsigned long order = get_order(size);
...
page = alloc_pages(gfp, order);
...
split_page(page, order);
for (p = page + (size >> PAGE_SHIFT), e = page + (1 << order); p < e;
p++)
__free_page(p);
...
}
Thanks,
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Plumber's Conference: Call for Working Session Submissions
Em 24-07-2010 17:43, Mauro Carvalho Chehab escreveu: > CFP dead line for submitting proposals to LPC/2010 is approaching. > For those that intends to submit proposals for it, please do it quickly, > as the official dead line is July, 26. Guys, We're trying to close the track definitions and start organizing it, but, so far, we received very few proposals for the media track. So, if you're interested on speaking there, please send a proposal at the Plumbers site and ping me urgently. Thanks! Mauro > > > --- > > The Planning Committee for the Linux Plumbers Conference (LPC) is happy > to announce that submissions to the "micro-conferences" portion of the > conference is now open. The micro-conferences are working session > focused on specific infrastructural "plumbing" in the Linux system -- > kernel subsystems, core libraries, windowing system, etc. -- which are > half-day in length. > > The potential topics for the working sessions can be found at the Topics > page[1] of the LPC wiki and include: > > * Power Management > * Virtualization > * Mono > * Desktop > * Tracing > * Real-time response for full FOSS/Linux stack > * User-visible Problems in Networking > * Media Infrastructure > * Audio > * HA Clustering > * Legal Hygiene > * Embedded Topics > * Boot/init > > [1] http://wiki.linuxplumbersconf.org/2010:topics > > The topics that will actually have working sessions scheduled at the LPC > will depend on the submissions to the microconference and on the ability > of its respective community to organize a successful working session; > see "Responsibility of a working session leader"[2] page on the LPC > wiki for more details. > > [2] > http://wiki.linuxplumbersconf.org/2010:responsibilities_of_a_working_session_leader > > Microconference submissions do not have to reflect finished work. In > fact, proposals or proof-of-concepts of potential solutions to important > problems are encouraged, so they can be discussed and debated during the > microconference. Proposals for presentations at a microconference may > be submitted here [3]: > > [3] http://www.linuxplumbersconf.org/2010/ocw/events/LPC2010MC/proposals > > In addition to the micro conference, the Linux Plumbers Conference has > open calls for papers[4] and BOF's[5]. > > [4] http://www.linuxplumbersconf.org/2010/ocw/events/LPC2010/proposals > [5] http://www.linuxplumbersconf.org/2010/ocw/events/LPC2010BOFS/proposals > > For further announcements about LPC, please watch our blog[6] or > subscribe to our LPC announcements mailing list[7]. > > [6] http://www.linuxplumbersconf.org/2010/feed/rss > [7] http://lists.linuxplumbersconf.org/mailman/listinfo/lpc-announce > > ___ > Lpc-session-leads mailing list > lpc-session-le...@lists.linuxplumbersconf.org > http://lists.linuxplumbersconf.org/mailman/listinfo/lpc-session-leads > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] V4L/DVB: unlock on error path
Thank you for catching this up. I had this fixed already, but due to hassle
caused by having multiple versions of the driver this bug somehow made it
unnoticed to mainline.
Acked-by: Sylwester Nawrocki
> -Original Message-
> From: Dan Carpenter [mailto:erro...@gmail.com]
> Sent: Thursday, August 12, 2010 9:42 AM
> To: Mauro Carvalho Chehab
> Cc: Pawel Osciak; Kyungmin Park; Sylwester Nawrocki; linux-
> me...@vger.kernel.org; kernel-janit...@vger.kernel.org
> Subject: [patch] V4L/DVB: unlock on error path
>
> If we return directly here then we miss out on some mutex_unlock()s
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
> b/drivers/media/video/s5p-fimc/fimc-core.c
> index b151c7b..1beb226 100644
> --- a/drivers/media/video/s5p-fimc/fimc-core.c
> +++ b/drivers/media/video/s5p-fimc/fimc-core.c
> @@ -822,7 +822,8 @@ static int fimc_m2m_s_fmt(struct file *file, void
> *priv, struct v4l2_format *f)
> } else {
> v4l2_err(&ctx->fimc_dev->m2m.v4l2_dev,
>"Wrong buffer/video queue type (%d)\n", f->type);
> - return -EINVAL;
> + ret = -EINVAL;
> + goto s_fmt_out;
> }
>
> pix = &f->fmt.pix;
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
Hi all,
struct device contains a member: struct dma_coherent_mem *dma_mem;
to hold information for a piece of memory declared dma-coherent.
Alternatively the same member could also be used to hold preallocated
dma-coherent memory for latter per-device use.
This tric is already used in drivers/staging/dt3155v4l.c
dt3155_alloc_coherent()/dt3155_free_coherent()
Here proposed for general use by popular demand from video4linux folks.
Helps for videobuf-dma-contig framework.
Signed-off-by: Marin Mitov
==
--- a/drivers/base/dma-coherent.c 2010-08-19 15:50:42.0 +0300
+++ b/drivers/base/dma-coherent.c 2010-08-19 17:27:56.0 +0300
@@ -93,6 +93,83 @@ void *dma_mark_declared_memory_occupied(
EXPORT_SYMBOL(dma_mark_declared_memory_occupied);
/**
+ * dma_reserve_coherent_memory() - reserve coherent memory for per-device use
+ *
+ * @dev: device from which we allocate memory
+ * @size: size of requested memory area in bytes
+ * @flags: same as in dma_declare_coherent_memory()
+ *
+ * This function reserves coherent memory allocating it early (during probe())
+ * to support latter allocations from per-device coherent memory pools.
+ * For a given device one could use either dma_declare_coherent_memory() or
+ * dma_reserve_coherent_memory(), but not both, becase the result of these
+ * functions is stored in a single struct device member - dma_mem
+ *
+ * Returns DMA_MEMORY_MAP on success, or 0 if failed.
+ * (same as dma_declare_coherent_memory()
+ */
+int dma_reserve_coherent_memory(struct device *dev, size_t size, int flags)
+{
+ struct dma_coherent_mem *mem;
+ dma_addr_t dev_base;
+ int pages = size >> PAGE_SHIFT;
+ int bitmap_size = BITS_TO_LONGS(pages) * sizeof(long);
+
+ if ((flags & DMA_MEMORY_MAP) == 0)
+ goto out;
+ if (!size)
+ goto out;
+ if (dev->dma_mem)
+ goto out;
+
+ mem = kzalloc(sizeof(*mem), GFP_KERNEL);
+ if (!mem)
+ goto out;
+ mem->virt_base = dma_alloc_coherent(dev, size, &dev_base,
+ DT3155_COH_FLAGS);
+ if (!mem->virt_base)
+ goto err_alloc_coherent;
+ mem->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+ if (!mem->bitmap)
+ goto err_bitmap;
+
+ mem->device_base = dev_base;
+ mem->size = pages;
+ mem->flags = flags;
+ dev->dma_mem = mem;
+ return DMA_MEMORY_MAP;
+
+err_bitmap:
+ dma_free_coherent(dev, size, mem->virt_base, dev_base);
+err_alloc_coherent:
+ kfree(mem);
+out:
+ return 0;
+}
+EXPORT_SYMBOL(dma_reserve_coherent_memory);
+
+/**
+ * dma_free_reserved_memory() - free the reserved dma-coherent memoty
+ *
+ * @dev: device for which we free the dma-coherent memory
+ *
+ * same as dma_release_declared_memory()
+ */
+void dma_free_reserved_memory(struct device *dev)
+{
+ struct dma_coherent_mem *mem = dev->dma_mem;
+
+ if (!mem)
+ return;
+ dev->dma_mem = NULL;
+ dma_free_coherent(dev, mem->size << PAGE_SHIFT,
+ mem->virt_base, mem->device_base);
+ kfree(mem->bitmap);
+ kfree(mem);
+}
+EXPORT_SYMBOL(dma_free_reserved_memory);
+
+/**
* dma_alloc_from_coherent() - try to allocate memory from the per-device
coherent area
*
* @dev: device from which we allocate memory
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework
On Wed, 18 Aug 2010 12:01:35 +0900 Kyungmin Park wrote: > Are there any comments or ack? > > We hope this method included at mainline kernel if possible. > It's really needed feature for our multimedia frameworks. You got any comments from mm people? Virtually, this adds a new memory allocator implementation that steals some memory from memory allocator during boot process. Its API looks completely different from the API for memory allocator. That doesn't sound appealing to me much. This stuff couldn't be integrated well into memory allocator? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework
On Wed, Aug 18, 2010 at 12:01:35PM +0900, Kyungmin Park wrote: > Are there any comments or ack? > Is there a git tree and/or link to the latest version that is based on top 2.6.36-rc1?? I somehow seem to have lost the v3 of these patches. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] V4L/DVB: pvrusb2: remove unneeded NULL checks
Based on the surrounding code (the unconditional dereference), I agree
that this particular bit of coding paranoia is not doing much good.
Acked-by: Mike Isely
On Thu, 19 Aug 2010, Dan Carpenter wrote:
> We dereference "maskptr" unconditionally at the start of the function
> and also inside the call to parse_tlist() towards the end of the
> function. This function is called from store_val_any() and it always
> passes a non-NULL pointer.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-ctrl.c
> b/drivers/media/video/pvrusb2/pvrusb2-ctrl.c
> index 1b992b8..55ea914 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-ctrl.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-ctrl.c
> @@ -513,7 +513,7 @@ int pvr2_ctrl_sym_to_value(struct pvr2_ctrl *cptr,
> if (ret >= 0) {
> ret = pvr2_ctrl_range_check(cptr,*valptr);
> }
> - if (maskptr) *maskptr = ~0;
> + *maskptr = ~0;
> } else if (cptr->info->type == pvr2_ctl_bool) {
> ret = parse_token(ptr,len,valptr,boolNames,
> ARRAY_SIZE(boolNames));
> @@ -522,7 +522,7 @@ int pvr2_ctrl_sym_to_value(struct pvr2_ctrl *cptr,
> } else if (ret == 0) {
> *valptr = (*valptr & 1) ? !0 : 0;
> }
> - if (maskptr) *maskptr = 1;
> + *maskptr = 1;
> } else if (cptr->info->type == pvr2_ctl_enum) {
> ret = parse_token(
> ptr,len,valptr,
> @@ -531,7 +531,7 @@ int pvr2_ctrl_sym_to_value(struct pvr2_ctrl *cptr,
> if (ret >= 0) {
> ret = pvr2_ctrl_range_check(cptr,*valptr);
> }
> - if (maskptr) *maskptr = ~0;
> + *maskptr = ~0;
> } else if (cptr->info->type == pvr2_ctl_bitmask) {
> ret = parse_tlist(
> ptr,len,maskptr,valptr,
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Thursday, August 19, 2010 02:39:47 pm Guennadi Liakhovetski wrote: > On Thu, 19 Aug 2010, Janusz Krzysztofik wrote: > > > Hi Marin, > > Since I've finaly managed to make use of your method without any previously > > observerd limitations (see below), I'm interested in it being implemented > > system-wide. Are you going to submit a patch? It is ready, I just wait for the invitation. Marin Mitov > > I'm about to submit a patch, which you'll be most welcome to test. Just > give me a couple more hours. > > > I would suggest creating one common function that allocates and fills the > > dev->dma_mem structure, and two wrappers that call it: a > > dma_declare_coherent_memory() replacement, that passes an ioremapped device > > memory address to the common fuction, and your proposed > > dma_reserve_coherent_memory(), that passes a pointer returned by the > > dma_alloc_coherent() instead. > No, I don't think you should go to the next power of 2 - that's too crude. > Try rounding your buffer size to the page size, that should suffice. Allocated coherent memory is always a power of 2. Thanks. Marin Mitov > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Thu, 19 Aug 2010, Janusz Krzysztofik wrote: > Hi Marin, > Since I've finaly managed to make use of your method without any previously > observerd limitations (see below), I'm interested in it being implemented > system-wide. Are you going to submit a patch? I'm about to submit a patch, which you'll be most welcome to test. Just give me a couple more hours. > I would suggest creating one common function that allocates and fills the > dev->dma_mem structure, and two wrappers that call it: a > dma_declare_coherent_memory() replacement, that passes an ioremapped device > memory address to the common fuction, and your proposed > dma_reserve_coherent_memory(), that passes a pointer returned by the > dma_alloc_coherent() instead. > > > > > [ 6067.22] omap1-camera omap1-camera.0: OMAP1 Camera driver > > > > attached to camera 0 > > > > [ 6067.65] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format > > > > 32315659 not found > > > > [ 6067.68] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format > > > > 32315559 not found > > > > [ 6068.48] mplayer: page allocation failure. order:6, mode:0xd0 > > > > [ 6068.50] Backtrace: > > > > [ 6068.52] [] (dump_backtrace+0x0/0x110) from > > > > [] (dump_stack+0x18/0x1c) > > > > [ 6068.56] r6:0006 r5:00d0 r4:c1bcf000 > > > > [ 6068.59] [] (dump_stack+0x0/0x1c) from [] > > > > (__alloc_pages_nodemask+0x504/0x560) > > > > [ 6068.62] [] (__alloc_pages_nodemask+0x0/0x560) from > > > > [] (__dma_alloc+0x108/0x354) > > > > [ 6068.66] [] (__dma_alloc+0x0/0x354) from [] > > > > (dma_alloc_coherent+0x58/0x64) > > > > [ 6068.70] [] (dma_alloc_coherent+0x0/0x64) from > > > > [] (__videobuf_mmap_mapper+0x10c/0x374 [videobuf_dma_contig]) > > > > [ 6068.74] r7:c16934c0 r6: r5:c171baec r4: > > > > [ 6068.77] [] (__videobuf_mmap_mapper+0x0/0x374 > > > > [videobuf_dma_contig]) from [] > > > > (videobuf_mmap_mapper+0xc4/0x108) > > > > [ 6068.81] [] (videobuf_mmap_mapper+0x0/0x108) from > > > > [] (soc_camera_mmap+0x80/0x140) > > > > [ 6068.84] r5:c1a3b4e0 r4: > > > > [ 6068.87] [] (soc_camera_mmap+0x0/0x140) from > > > > [] (v4l2_mmap+0x4c/0x5c) > > > > [ 6068.90] r7:c145c000 r6:00ff r5:c16934c0 r4: > > > > [ 6068.93] [] (v4l2_mmap+0x0/0x5c) from [] > > > > (mmap_region+0x238/0x458) > > > > [ 6068.97] [] (mmap_region+0x0/0x458) from [] > > > > (do_mmap_pgoff+0x2bc/0x320) > > > > [ 6069.00] [] (do_mmap_pgoff+0x0/0x320) from [] > > > > (sys_mmap_pgoff+0x9c/0xc8) > > > > [ 6069.04] [] (sys_mmap_pgoff+0x0/0xc8) from [] > > > > (ret_fast_syscall+0x0/0x2c) > > > > [ 6069.20] Mem-info: > > > > [ 6069.22] Normal per-cpu: > > > > [ 6069.24] CPU0: hi:0, btch: 1 usd: 0 > > > > [ 6069.26] active_anon:676 inactive_anon:682 isolated_anon:0 > > > > [ 6069.26] active_file:422 inactive_file:2348 isolated_file:0 > > > > [ 6069.26] unevictable:177 dirty:0 writeback:0 unstable:0 > > > > [ 6069.26] free:1166 slab_reclaimable:0 slab_unreclaimable:0 > > > > [ 6069.26] mapped:1120 shmem:0 pagetables:121 bounce:0 > > > > [ 6069.35] Normal free:4664kB min:720kB low:900kB high:1080kB > > > > active_anon:2704kB inactive_anon:2728kB active_file:1688kB > > > > inactive_file:9392kB unevictable:708kB isolated(anon):0kB > > > > isolated(file):0kB present:32512kB mlocked:0kB > dirty:0kB writeback:0kB mapped:4480kB shmem:0kB slab_reclaimable:0kB > slab_unreclaimable:0kB kernel_stack:552kB pagetables:484kB unstable:0kB > bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no > > > > [ 6069.46] lowmem_reserve[]: 0 0 > > > > [ 6069.47] Normal: 6*4kB 20*8kB 14*16kB 29*32kB 26*64kB 9*128kB > > > > 2*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4664kB [ 6069.53] 2960 > > > > total pagecache pages > > > > [ 6069.55] 8192 pages of RAM > > > > [ 6069.56] 1322 free pages > > > > [ 6069.58] 1114 reserved pages > > > > [ 6069.59] 750 slab pages > > > > [ 6069.61] 2476 pages shared > > > > [ 6069.63] 0 pages swap cached > > > > [ 6069.64] omap1-camera omap1-camera.0: dma_alloc_coherent size > > > > 204800 failed > > > > [ 6069.68] omap1-camera omap1-camera.0: OMAP1 Camera driver > > > > detached from camera 0 > > > > > > > > Maybe I should preallocate a few more pages than will be actually used > > > > by the driver? > > That was it. I was trying to reserve exact frame size, times number of > buffers. > Apparently, the frame size should be rounded up to the nearest power of 2 > first for it to work as expected. No, I don't think you should go to the next power of 2 - that's too crude. Try rounding your buffer size to the page size, that should suffice. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe li
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
Monday 16 August 2010 12:17:36 Marin Mitov wrote: > On Saturday, August 14, 2010 08:33:09 pm Guennadi Liakhovetski wrote: > > On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: > > > Friday 13 August 2010 11:11:52 Marin Mitov napisał(a): > > > > On Friday, August 13, 2010 11:52:41 am Guennadi Liakhovetski wrote: > > > > > On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: > > > > > > Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): > > > > > > > 1. We've discussed this dynamic switching a bit on IRC today. > > > > > > > The first reaction was - you probably should concentrate on > > > > > > > getting the contiguous version to work reliably. I.e., to > > > > > > > reserve the memory in the board init code similar, how other > > > > > > > contig users currently do it. > > > > > > > > > > > > I already tried before to find out how I could allocate memory at > > > > > > init without reinventing a new videobuf-dma-contig > > > > > > implementation. Since in the Documentation/video4linux/videobuf > > > > > > I've read that videobuf does not currently play well with drivers > > > > > > that play tricks by allocating DMA space at system boot time, > > > > > > I've implemented the alternate sg path. > > > > > > > > > > > > If it's not quite true what the documentation says and you can > > > > > > give me a hint how this could be done, I might try again. > > > > > > > > > > For an example look at > > > > > arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma(). > > > > > > Yes, this is the solution that suffers from the already discussed > > > limitation of not being able to remap a memory with different > > > attributes, which affects OMAP1 as well. > > > > > > > For preallocating dma-coherent memory for device personal use during > > > > device probe() time (when the memory is less fragmented compared to > > > > open() time) see also dt3155_alloc_coherent/dt3155_free_coherent in > > > > drivers/staging/dt3155v4l/dt3155vfl.c (for x86 arch, I do not know if > > > > it works for arm arch) > > > > > > With this workaround applied, I get much better results, thank you > > > Marin. However, it seems not bullet proof, since mmap still happens to > > > fail for a reason not quite clear to me: > > > > What exactly does this mean - happens to fail - you mean starting and > > stopping mplayer several times? Can you verify, that you're not leaking > > memory? That you're freeing all allocated DMA memory again? Are you using > > the same parameters to mplayer, right? > > > > As for the work-around - can you not do this in your board late-initcall > > function? > > > > Not sure whether and how one can get this in the mainline. This is in > > principle the same, as in the above dma_declare_coherent_memory() > > example, only open-coded without the ioremap. > > My believe is that dma_declare_coherent_memory() could be used if your > frame grabber has local RAM buffer (like video buffer if the graphic > adapters) defined by BAR - that is why you need ioremap(). If this RAM > turns out to be coherent you use dma_declare_coherent_memory() and any > further invocation of dma_alloc_coherent() will allocate from it (till it > is exosted). My use of dt3155_alloc_coherent()/dt3155_free_coherent() is to > allocate a block of coherent 4MB memory during driver probe() method and > use it latter (via videobuff_dma_contig framework)). > > > Maybe we can add a suitable function > > to the dma-alloc API... > > Could be of general use, I am thinking about this. This could be done by > just renaming dt3155_alloc_coherent()/dt3155_free_coherent() to something > acceptable (dma_reserve_coherent_memory()/dma_release_reserved_memory(), I > am open for suggestions) and export them. Should be added to > drivers/base/dma-coherent.c. Hi Marin, Since I've finaly managed to make use of your method without any previously observerd limitations (see below), I'm interested in it being implemented system-wide. Are you going to submit a patch? I would suggest creating one common function that allocates and fills the dev->dma_mem structure, and two wrappers that call it: a dma_declare_coherent_memory() replacement, that passes an ioremapped device memory address to the common fuction, and your proposed dma_reserve_coherent_memory(), that passes a pointer returned by the dma_alloc_coherent() instead. > > > [ 6067.22] omap1-camera omap1-camera.0: OMAP1 Camera driver attached > > > to camera 0 > > > [ 6067.65] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format > > > 32315659 not found > > > [ 6067.68] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format > > > 32315559 not found > > > [ 6068.48] mplayer: page allocation failure. order:6, mode:0xd0 > > > [ 6068.50] Backtrace: > > > [ 6068.52] [] (dump_backtrace+0x0/0x110) from [] > > > (dump_stack+0x18/0x1c) > > > [ 6068.56] r6:0006 r5:00d0 r4:c1bcf000 > > > [ 6068.59] [] (dump_stack+0x0/0x1c) from [] > > > (__alloc_pages_nodemask+0x504/
[patch] V4L/DVB: saa7164: move dereference under NULL check
The original code dereferenced "port" before checking it for NULL. I
moved the test down below the check. Also I changed the comparisons a
little so people wouldn't get confused and think "port" and "buf" were
ints instead of pointers. (Probably that's what lead to this issue in
the first place.)
There is only one caller for this function and it passes non-NULL
pointers, so this is essentially a cleanup rather than a bugfix.
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/video/saa7164/saa7164-buffer.c
b/drivers/media/video/saa7164/saa7164-buffer.c
index 5713f3a..ddd25d3 100644
--- a/drivers/media/video/saa7164/saa7164-buffer.c
+++ b/drivers/media/video/saa7164/saa7164-buffer.c
@@ -136,10 +136,11 @@ ret:
int saa7164_buffer_dealloc(struct saa7164_tsport *port,
struct saa7164_buffer *buf)
{
- struct saa7164_dev *dev = port->dev;
+ struct saa7164_dev *dev;
- if ((buf == 0) || (port == 0))
+ if (!buf || !port)
return SAA_ERR_BAD_PARAMETER;
+ dev = port->dev;
dprintk(DBGLVL_BUF, "%s() deallocating buffer @ 0x%p\n", __func__, buf);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] V4L/DVB: pvrusb2: remove unneeded NULL checks
We dereference "maskptr" unconditionally at the start of the function
and also inside the call to parse_tlist() towards the end of the
function. This function is called from store_val_any() and it always
passes a non-NULL pointer.
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/video/pvrusb2/pvrusb2-ctrl.c
b/drivers/media/video/pvrusb2/pvrusb2-ctrl.c
index 1b992b8..55ea914 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-ctrl.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-ctrl.c
@@ -513,7 +513,7 @@ int pvr2_ctrl_sym_to_value(struct pvr2_ctrl *cptr,
if (ret >= 0) {
ret = pvr2_ctrl_range_check(cptr,*valptr);
}
- if (maskptr) *maskptr = ~0;
+ *maskptr = ~0;
} else if (cptr->info->type == pvr2_ctl_bool) {
ret = parse_token(ptr,len,valptr,boolNames,
ARRAY_SIZE(boolNames));
@@ -522,7 +522,7 @@ int pvr2_ctrl_sym_to_value(struct pvr2_ctrl *cptr,
} else if (ret == 0) {
*valptr = (*valptr & 1) ? !0 : 0;
}
- if (maskptr) *maskptr = 1;
+ *maskptr = 1;
} else if (cptr->info->type == pvr2_ctl_enum) {
ret = parse_token(
ptr,len,valptr,
@@ -531,7 +531,7 @@ int pvr2_ctrl_sym_to_value(struct pvr2_ctrl *cptr,
if (ret >= 0) {
ret = pvr2_ctrl_range_check(cptr,*valptr);
}
- if (maskptr) *maskptr = ~0;
+ *maskptr = ~0;
} else if (cptr->info->type == pvr2_ctl_bitmask) {
ret = parse_tlist(
ptr,len,maskptr,valptr,
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] V4L/DVB: opera1: remove unneeded NULL check
"fw" is always a non-NULL pointer at this point, and anyway
release_firmware() accepts NULL pointers.
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/dvb/dvb-usb/opera1.c
b/drivers/media/dvb/dvb-usb/opera1.c
index 6b22ec6..f896337 100644
--- a/drivers/media/dvb/dvb-usb/opera1.c
+++ b/drivers/media/dvb/dvb-usb/opera1.c
@@ -483,9 +483,7 @@ static int opera1_xilinx_load_firmware(struct usb_device
*dev,
}
}
kfree(p);
- if (fw) {
- release_firmware(fw);
- }
+ release_firmware(fw);
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Media controller addition: MEDIA_IOC_ENTITY_INFO
Hi all, Following some discussion with Laurent Pinchart I'd like to suggest the addition of a new ioctl to the media controller API: MEDIA_IOC_ENTITY_INFO. The purpose of the ioctl is to allow applications to retrieve advanced information on a given entity. There are two parts: a generic one and a driver-specific one. The latter allows drivers to make driver-specific entity information available to applications. To mention one example: The UVC driver exposes a device's units/terminals as entities. Each of these entities has a unit ID and some particular units (extension units for vendor-specific controls) have a GUID that uniquely identifies their interface. These two pieces of information are very interesting for apps because it allows them to generically access all these controls. At the moment there isn't a lot of generic information in the media_entity_info struct. Only a generic bus ID that can e.g. be used to differentiate I2C chips. Suggestions for further generic fields are welcome, and so is more general feedback. Cheers, Martin MEDIA_IOC_ENTITY_INFO - Obtain detailed information on a given entity - ioctl(int fd, int request, struct media_entity_info *argp); Applications can retrieve detailed information about a given entity using this ioctl. This entity information contains both, a generic part, as well as a driver specific part. While the size, fields, and format of the former one are defined by the media kernel API the latter one is defined by the driver behind the entity's device and can be of arbitrary size. Querying the driver specific entity information is optional. To only query the generic part the application sets drvinfo_size to 0 and drvinfo to NULL. The function returns either success (if no driver specific information is available) or ENOBUFS (if driver specific information would be available). In both cases the generic entity information is properly returned. In order to query the driver specific part the application sets drvinfo_size to the correct size of the driver specific structure, and points drvinfo to a pre-allocated structure of the same size. To maintain maximum flexibility a method to query the size of the driver specific entity information is provided. If the number provided in drvinfo_size is smaller than the size of the driver specific structure the correct size is stored in the drvinfo_size field and the function returns with ENOBUFS. The drvinfo pointer is ignored in that case. Therefore the suggested way to query all available entity information is as follows: 1. Call the function with drvinfo_size set to 0 and drvinfo to NULL. 2. Verify that the error code is ENOBUFS. In case of success, no driver specific information is available and the remaining steps can be skipped. 3. Allocate a buffer of size drvinfo_size and point drvinfo to it. 4. Call the function again. 5. Verify that the return value indicates success. Note for driver developers: Driver specific entity information structures are to start with a header field of type media_entity_drvinfo. The media_entity_info and related structures are defined as - struct media_entity_drvinfo __u32 magic A magic number identifying the type of the structure. __u8data[0] Driver specific data of arbitrary size. The magic number allows for an application to verify that the type of the obtained driver specific information indeed corresponds to what it expects to process. Newer versions of a driver can use different magic numbers to indicate that the data structure has changed. Drivers are free to choose the format of the magic number. - struct media_entity_info __u32 entity Entity id, set by the application. charbus_id[32] A bus ID of undefined format. __u32 reserved[8] Reserved for future extensions. __u32 drvinfo_sizeSize of the data pointed to by 'drvinfo', set by both application and driver. struct media_entity_drvinfo *drvinfoA pointer to a pre-allocated structure of driver specific format, set by the application. Return values: EINVALA parameter is invalid. This can indicate that the entity id is invalid or that the drvinfo pointer is NULL despite a correct drvinfo_size value. EFAULTA pointer is invalid, either argp itself or the drvinfo field. ENOENTThere is no information available about the given entity. ENOBUFS The buffer size specified in drvinfo_size is not big enough to hold the driver specific entity information structure. The correct size is being returned in drvinfo_size. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a
Re: [PATCH v4 2/5] MFD: WL1273 FM Radio: MFD driver for the FM radio.
Hello. On Wed, 2010-08-18 at 20:14 +0200, ext Pavan Savoy wrote: > --- On Wed, 7/7/10, Pavan Savoy wrote: > > > > From: Pavan Savoy > > Subject: Re: [PATCH v4 2/5] MFD: WL1273 FM Radio: MFD driver for the FM > > radio. > > To: "Matti J. Aaltonen" , "Mauro Carvalho > > Chehab" > > Cc: linux-media@vger.kernel.org, hverk...@xs4all.nl, > > eduardo.valen...@nokia.com, "pavan savoy" > > Date: Wednesday, 7 July, 2010, 10:51 AM > > > > --- On Tue, 6/7/10, Mauro Carvalho Chehab > > wrote: > > > > > From: Mauro Carvalho Chehab > > > Subject: Re: [PATCH v4 2/5] MFD: WL1273 FM Radio: MFD > > driver for the FM radio. > > > To: "Matti J. Aaltonen" > > > Cc: linux-media@vger.kernel.org, > > hverk...@xs4all.nl, > > eduardo.valen...@nokia.com > > > Date: Tuesday, 6 July, 2010, 8:04 AM > > > Em 04-06-2010 07:34, Matti J. > > > Aaltonen escreveu: > > > > This is a parent driver for two child drivers: > > the > > > V4L2 driver and > > > > the ALSA codec driver. The MFD part provides the > > I2C > > > communication > > > > to the device and a couple of functions that are > > > called from both > > > > children. > > > > Where can I have a look at the whole code ? As in some > > local tree, where all codes are put up ? > > Basically, we have a V4L2 driver for WL128x (using TTY as > > transport) and plan to push them soon ... > > > > This would be a nice input ... > > Anywhere I can have a look at the whole code? > We are trying to push out V4L2 drivers for FM on 128x, and intend to use > several V4L2 new ioctls which you have defined (_BAND_) being one of them. > > Also we plan to push FM Tx of it too.. TX_CLASS from V4L2 has most of the > ioctls and plan to introduce the rest. I'm sorry for not answering to you earlier. But I don't have my own public repository. But to create the whole thing is extremely simple: just take the current mainline tree and apply my patches on top of it... Best Regards, Matti > > > > > > > Signed-off-by: Matti J. Aaltonen > > > > --- > > > > drivers/mfd/Kconfig > > > |6 + > > > > drivers/mfd/Makefile > > > |2 + > > > > drivers/mfd/wl1273-core.c > > >| 616 > > > +++ > > > > include/linux/mfd/wl1273-core.h | 326 > > > + > > > > 4 files changed, 950 insertions(+), 0 > > > deletions(-) > > > > create mode 100644 drivers/mfd/wl1273-core.c > > > > create mode 100644 > > > include/linux/mfd/wl1273-core.h > > > > > > > > diff --git a/drivers/mfd/Kconfig > > > b/drivers/mfd/Kconfig > > > > index 413576a..5998a94 100644 > > > > --- a/drivers/mfd/Kconfig > > > > +++ b/drivers/mfd/Kconfig > > > > @@ -135,6 +135,12 @@ config TWL4030_CODEC > > > > select MFD_CORE > > > > default n > > > > > > > > +config WL1273_CORE > > > > +bool > > > > +depends on I2C > > > > +select MFD_CORE > > > > +default n > > > > + > > > > config MFD_TMIO > > > > bool > > > > default n > > > > diff --git a/drivers/mfd/Makefile > > > b/drivers/mfd/Makefile > > > > index 78295d6..46e611d 100644 > > > > --- a/drivers/mfd/Makefile > > > > +++ b/drivers/mfd/Makefile > > > > @@ -30,6 +30,8 @@ > > > obj-$(CONFIG_TWL4030_CORE)+= twl-core.o > > > twl4030-irq.o twl6030-irq.o > > > > obj-$(CONFIG_TWL4030_POWER)+= > > > twl4030-power.o > > > > obj-$(CONFIG_TWL4030_CODEC)+= > > > twl4030-codec.o > > > > > > > > +obj-$(CONFIG_WL1273_CORE)+= > > > wl1273-core.o > > > > + > > > > obj-$(CONFIG_MFD_MC13783)+= > > > mc13783-core.o > > > > > > > > obj-$(CONFIG_MFD_CORE) > > > += mfd-core.o > > > > diff --git a/drivers/mfd/wl1273-core.c > > > b/drivers/mfd/wl1273-core.c > > > > new file mode 100644 > > > > index 000..6c7dbba > > > > --- /dev/null > > > > +++ b/drivers/mfd/wl1273-core.c > > > > @@ -0,0 +1,616 @@ > > > > +/* > > > > + * MFD driver for wl1273 FM radio and audio > > codec > > > submodules. > > > > + * > > > > + * Author:Matti Aaltonen > > > > + * > > > > + * Copyright: (C) 2010 Nokia > > > Corporation > > > > + * > > > > + * This program is free software; you can > > > redistribute it and/or modify > > > > + * it under the terms of the GNU General Public > > > License version 2 as > > > > + * published by the Free Software Foundation. > > > > + * > > > > + * This program is distributed in the hope that > > it > > > will be useful, but > > > > + * WITHOUT ANY WARRANTY; without even the > > implied > > > warranty of > > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR > > > PURPOSE. See the GNU > > > > + * General Public License for more details. > > > > + * > > > > + * You should have received a copy of the GNU > > General > > > Public License > > > > + * along with this program; if not, write to the > > Free > > > Software > > > > + * Foundation, Inc., 51 Franklin St, Fifth > > Floor, > > > Boston, MA > > > > + * 02110-1301 USA > > > > + * > > > > + */ > > > > + > > > > +#undef DEBUG > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > +#inc
