[PATCH 1/1 v2] media/video: vpif: fixing function name start to vpif_config_params
diff --git a/drivers/media/video/davinci/vpif.c
b/drivers/media/video/davinci/vpif.c
index af96802..04dd8fa 100644
--- a/drivers/media/video/davinci/vpif.c
+++ b/drivers/media/video/davinci/vpif.c
@@ -301,12 +301,12 @@ static void vpif_set_mode_info(const struct
vpif_channel_config_params *config,
regw(value, vpifregs[channel_id].v_cfg);
}
-/* config_vpif_params
+/* vpif_config_params
* Function to set the parameters of a channel
* Mainly modifies the channel ciontrol register
* It sets frame format, yc mux mode
*/
-static void config_vpif_params(struct vpif_params *vpifparams,
+static void vpif_config_params(struct vpif_params *vpifparams,
u8 channel_id, u8 found)
{
const struct vpif_channel_config_params *config = &vpifparams->std_info;
@@ -374,7 +374,7 @@ int vpif_set_video_params(struct vpif_params *vpifparams,
u8 channel_id)
found = 2;
}
- config_vpif_params(vpifparams, channel_id, found);
+ vpif_config_params(vpifparams, channel_id, found);
regw(0x80, VPIF_REQ_SIZE);
regw(0x01, VPIF_EMULATION_CTRL);
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index 9604695..59104e6 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -67,7 +67,7 @@ MODULE_PARM_DESC(ch3_numbuffers, "Channel1 buffer count
(default:3)");
MODULE_PARM_DESC(ch2_bufsize, "Channel0 buffer size (default:1920 x 1080 x
2)");
MODULE_PARM_DESC(ch3_bufsize, "Channel1 buffer size (default:720 x 576 x 2)");
-static struct vpif_config_params config_params = {
+static struct config_vpif_params config_params = {
.min_numbuffers = 3,
.numbuffers[0] = 3,
.numbuffers[1] = 3,
diff --git a/drivers/media/video/davinci/vpif_capture.h
b/drivers/media/video/davinci/vpif_capture.h
index a693d4e..8863de1 100644
--- a/drivers/media/video/davinci/vpif_capture.h
+++ b/drivers/media/video/davinci/vpif_capture.h
@@ -144,7 +144,7 @@ struct vpif_device {
struct v4l2_subdev **sd;
};
-struct vpif_config_params {
+struct config_vpif_params {
u8 min_numbuffers;
u8 numbuffers[VPIF_CAPTURE_NUM_CHANNELS];
s8 device_type;
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index e6488ee..652440d 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -70,7 +70,7 @@ MODULE_PARM_DESC(ch3_numbuffers, "Channel3 buffer count
(default:3)");
MODULE_PARM_DESC(ch2_bufsize, "Channel2 buffer size (default:1920 x 1080 x
2)");
MODULE_PARM_DESC(ch3_bufsize, "Channel3 buffer size (default:720 x 576 x 2)");
-static struct vpif_config_params config_params = {
+static struct config_vpif_params config_params = {
.min_numbuffers = 3,
.numbuffers[0] = 3,
.numbuffers[1] = 3,
diff --git a/drivers/media/video/davinci/vpif_display.h
b/drivers/media/video/davinci/vpif_display.h
index 56879d1..3e14807 100644
--- a/drivers/media/video/davinci/vpif_display.h
+++ b/drivers/media/video/davinci/vpif_display.h
@@ -154,7 +154,7 @@ struct vpif_device {
};
-struct vpif_config_params {
+struct config_vpif_params {
u32 min_bufsize[VPIF_DISPLAY_NUM_CHANNELS];
u32 channel_bufsize[VPIF_DISPLAY_NUM_CHANNELS];
u8 numbuffers[VPIF_DISPLAY_NUM_CHANNELS];
--
1.7.5.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
[PATCH 0/1 v2] media/video: vpif: fixing function name start to vpif_config_params
This patch address the issue that a function named config_vpif_params should be vpif_config_params. However this name is shared with two structures defined already. So I changed the structures to config_vpif_params (origin was vpif_config_params) v2 changes: softer wording in description and the structs are now defined without _t Dror Cohen (1): fixing function name start to vpif_config_params drivers/media/video/davinci/vpif.c |6 +++--- drivers/media/video/davinci/vpif_capture.c |2 +- drivers/media/video/davinci/vpif_capture.h |2 +- drivers/media/video/davinci/vpif_display.c |2 +- drivers/media/video/davinci/vpif_display.h |2 +- 5 files changed, 7 insertions(+), 7 deletions(-) -- 1.7.5.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] dma-buf: add reference counting for exporter module
Hi Tomasz, On 8 August 2012 19:36, Daniel Vetter wrote: > On Wed, Aug 08, 2012 at 03:53:10PM +0200, Tomasz Stanislawski wrote: >> Hi Laurent, >> >> On 08/08/2012 03:35 PM, Laurent Pinchart wrote: >> > Hi Tomasz, >> > >> > Thanks for the patch. Thanks for the patch; may I ask you to split it into 2 patches (1 dma-buf and 1 drm) and submit? That ways, either Dave or I can take the patches for either pull request. With that, please feel free to add my Acked-by as well. >> > >> > On Wednesday 08 August 2012 12:17:41 Tomasz Stanislawski wrote: >> >> This patch adds reference counting on a module that exports dma-buf and >> >> implements its operations. This prevents the module from being unloaded >> >> while DMABUF file is in use. >> >> >> >> Signed-off-by: Tomasz Stanislawski >> >> --- >> >> Documentation/dma-buf-sharing.txt |3 ++- >> >> drivers/base/dma-buf.c | 10 +- >> >> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 + >> >> drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 + >> >> drivers/gpu/drm/nouveau/nouveau_prime.c|1 + >> >> drivers/gpu/drm/radeon/radeon_prime.c |1 + >> >> drivers/staging/omapdrm/omap_gem_dmabuf.c |1 + >> >> include/linux/dma-buf.h|2 ++ >> >> 8 files changed, 18 insertions(+), 2 deletions(-) >> >> >> [snip] >> >> >> @@ -96,6 +98,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct >> >> dma_buf_ops *ops, struct file *file; >> >> >> >>if (WARN_ON(!priv || !ops >> >> +|| !ops->owner >> >> Thank you for spotting this. >> I didn'y know that try_get_module returned true is module was NULL. >> >> BTW. Is it worth to add ".owner = THIS_MODULE," to all dma_buf >> exporters in this patch? > > Yeah, I think that makes sense. Otherwise it might get lost somewhere, > i.e. you can smash my Ack on this. > -Daniel > -- > Daniel Vetter > Mail: dan...@ffwll.ch > Mobile: +41 (0)79 365 57 48 -- Thanks and regards, Sumit Semwal. -- 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] [media] davinci: vpfe: Add documentation
Hi Sakari,
Thank you for the comments.
On Thursday 02 August 2012 05:37 AM, Sakari Ailus wrote:
> Hi Manju,
>
> Thanks for the patch.
>
> Please make sure these patches reach linux-media next time. If they do
> not,
> it severely limits the number of potential reviewers. I don't know
> why, but
> the original patch isn't on linux-media even if the list was cc'd.
>
> Dropping linux-kernel from cc.
>
> Manjunath Hadli wrote:
>> Add documentation on the Davinci VPFE driver. Document the subdevs,
>> and private IOTCLs the driver implements
>>
>> Signed-off-by: Manjunath Hadli
>> Signed-off-by: Lad, Prabhakar
>> ---
>> Documentation/video4linux/davinci-vpfe-mc.txt | 263
>> +
>> 1 files changed, 263 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/video4linux/davinci-vpfe-mc.txt
>>
>> diff --git a/Documentation/video4linux/davinci-vpfe-mc.txt
>> b/Documentation/video4linux/davinci-vpfe-mc.txt
>> new file mode 100644
>> index 000..968194f
>> --- /dev/null
>> +++ b/Documentation/video4linux/davinci-vpfe-mc.txt
>> @@ -0,0 +1,263 @@
>> +Davinci Video processing Front End (VPFE) driver
>> +
>> +Copyright (C) 2012 Texas Instruments Inc
>> +
>> +Contacts: Manjunath Hadli
>> +
>> +Introduction
>> +
>> +
>> +This file documents the Texas Instruments Davinci Video processing
>> Front End
>> +(VPFE) driver located under drivers/media/video/davinci. The
>> original driver
>> +exists for Davinci VPFE, which is now being changed to Media Controller
>> +Framework.
>> +
>> +Currently the driver has been successfully used on the following
>> version of Davinci:
>> +
>> +DM365/DM368
>> +
>> +The driver implements V4L2, Media controller and v4l2_subdev
>> interfaces.
>> +Sensor, lens and flash drivers using the v4l2_subdev interface in
>> the kernel
>> +are supported.
>> +
>> +
>> +Split to subdevs
>> +
>> +
>> +The Davinic VPFE is split into V4L2 subdevs, each of the blocks
>> inside the VPFE
>> +having one subdev to represent it. Each of the subdevs provide a
>> V4L2 subdev
>> +interface to userspace.
>> +
>> +DAVINCI CCDC
>> +DAVINCI PREVIEWER
>> +DAVINCI RESIZER
>> +DAVINCI AEW
>> +DAVINCI AF
>> +
>> +Each possible link in the VPFE is modeled by a link in the Media
>> controller
>> +interface. For an example program see [1].
>> +
>> +
>> +Private IOCTLs
>> +==
>> +
>> +The Davinci Video processing Front End (VPFE) driver supports
>> standard V4L2
>> +IOCTLs and controls where possible and practical. Much of the
>> functions provided
>> +by the VPFE, however, does not fall under the standard IOCTLs.
>> +
>> +In general, there is a private ioctl for configuring each of the blocks
>> +containing hardware-dependent functions.
>> +
>> +The following private IOCTLs are supported:
>> +
>> +1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
>> +Description:
>> +Sets/Gets the parameters required by the previewer module
>> +Parameter:
>> +/**
>> + * struct prev_module_param- structure to configure preview modules
>> + * @version: Version of the preview module
>> + * @len: Length of the module config structure
>> + * @module_id: Module id
>> + * @param: pointer to module config parameter.
>> + */
>> +struct prev_module_param {
>> +char version[IMP_MAX_NAME_SIZE];
>> +unsigned short len;
>> +unsigned short module_id;
>> +void *param;
>> +};
>
> In addition to what Laurent commented on this, could the version
> information be passed in struct media_entity_desc instead?
I plan to leave out the version.
>
> As a general comment, it's a bad idea to design an API that allows
> passing
> blobs, especially when the expected size of the blobs isn't known. That
> really equals to asking for trouble.
>
> That said, I know this is an area where complete documentation is acarce,
> but I think that at least the memory layout of the current blob pointers
> should be visible in the struct definitions whenever possible. See
> e.g. the
> OMAP 3 ISP driver.
I have proposed using a union of structures instead of the void blob.
I also saw the OMAP implementation, and they are pointers (but not void).
To me the union approach looks better as it keeps the architecture
intact and does not necessitate an
explicit copy_from_user. Which of these ways do you suggest?
>
>> +2: IOCTL: PREV_S_CONFIG/PREV_G_CONFIG
>> +Description:
>> +Sets/Gets the configuration required by the previewer channel
>> +Parameter:
>> +/**
>> + * struct prev_channel_config - structure for configuring the
>> previewer channel
>> + * @len: Length of the user configuration
>> + * @config: pointer to either single shot config or continuous
>> + */
>> +struct prev_channel_config {
>> +unsigned short len;
>> +void *config;
>> +};
>> +
>> +3: IOCTL: PREV_ENUM_CAP
>> +Description:
>> +Queries the modules available in the image processor for preview
>> the
>> +inpu
[Fwd: Patch update notification: 23 patches updated]
Is there anything that I need to do for this? The patches were the older versions, if I remember correctly, and Mauro has moved them to a branch on his tree (but I haven't checked lately to see if there has been any work done on that branch). Thanks, and have a great day:) Patrick. --- Begin Message --- Hello, The following patches (submitted by you) have been updated in patchwork: * [08/25] added drx39_dummy for pctv80e support - http://patchwork.linuxtv.org/patch/8387/ was: New now: RFC * [02/25] added bsp_host for pctv80e support - http://patchwork.linuxtv.org/patch/8368/ was: New now: RFC * [2/2] import-pctv-80e-from-devin-heitmueller-hg-repository # HG changeset patch # User Devin Heitmueller # Date 1278279731 14400 # Node ID 30c6512030acb8dea04c653b40340f6038d57367 # Parent c119f08c4dd266f6024cde6b5e660c7d32a0 - http://patchwork.linuxtv.org/patch/9586/ was: New now: Under Review * [25/25] modified em28xx header for pctv80e support - http://patchwork.linuxtv.org/patch/8381/ was: New now: RFC * [03/25] added bsp_i2c for pctv80e support - http://patchwork.linuxtv.org/patch/8375/ was: New now: RFC * [05/25] added bsp_types for pctv80e support - http://patchwork.linuxtv.org/patch/8388/ was: New now: RFC * [01/25] added PCTV80e information to cardlist file - http://patchwork.linuxtv.org/patch/8369/ was: New now: RFC * [24/25] modified em28xx-dvb for pctv80e support - http://patchwork.linuxtv.org/patch/8382/ was: New now: RFC * [07/25] added drx39xxj header for pctv80e support - http://patchwork.linuxtv.org/patch/8376/ was: New now: RFC * [10/25] added drx_dap_fasi header for pctv80e support - http://patchwork.linuxtv.org/patch/8389/ was: New now: RFC * [09/25] added drx_dap_fasi for pctv80e support - http://patchwork.linuxtv.org/patch/8370/ was: New now: RFC * [20/25] added drxj_options header for pctv80e support - http://patchwork.linuxtv.org/patch/8383/ was: New now: RFC * [04/25] added bsp_tuner for pctv80e support - http://patchwork.linuxtv.org/patch/8377/ was: New now: RFC * [06/25] added drx39xxj for pctv80e support - http://patchwork.linuxtv.org/patch/8371/ was: New now: RFC * [23/25] modified em28xx-cards for pctv80e support - http://patchwork.linuxtv.org/patch/8384/ was: New now: RFC * [22/25] modified Makefile for pctv80e support - http://patchwork.linuxtv.org/patch/8378/ was: New now: RFC * [11/25] added drx_driver for pctv80e support - http://patchwork.linuxtv.org/patch/8372/ was: New now: RFC * [19/25] added drxj_mc_vsbqam header for pctv80e support - http://patchwork.linuxtv.org/patch/8385/ was: New now: RFC * [18/25] added drxj_mc_vsb header for pctv80e support - http://patchwork.linuxtv.org/patch/8379/ was: New now: RFC * [13/25] added drx_driver_version header for pctv80e support - http://patchwork.linuxtv.org/patch/8373/ was: New now: RFC * [15/25] added drxj header for pctv80e support - http://patchwork.linuxtv.org/patch/8386/ was: New now: RFC * [21/25] modified Kconfig to include pctv80e support - http://patchwork.linuxtv.org/patch/8380/ was: New now: RFC * [12/25] added drx_driver header for pctv80e support - http://patchwork.linuxtv.org/patch/8374/ was: New now: RFC This email is a notification only - you do not need to respond. Happy patchworking. -- This is an automated mail sent by the patchwork system at patchwork.linuxtv.org. To stop receiving these notifications, edit your mail settings at: http://patchwork.linuxtv.org/mail/ --- End Message ---
build docs fails: parser error : Failure to process entity sub-enum-freq-bands
That is from current "staging/for_v3.7" [crope@localhost linux]$ make htmldocs HTMLDocumentation/DocBook/media_api.html warning: failed to load external entity "/home/crope/linuxtv/code/linux/Documentation/DocBook/vidioc-enum-freq-bands.xml" /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:542: parser error : Failure to process entity sub-enum-freq-bands &sub-enum-freq-bands; ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:542: parser error : Entity 'sub-enum-freq-bands' not defined &sub-enum-freq-bands; ^ warning: failed to load external entity "/home/crope/linuxtv/code/linux/Documentation/DocBook/selections-common.xml" /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:600: parser error : Failure to process entity sub-selections-common &sub-selections-common; ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:600: parser error : Entity 'sub-selections-common' not defined &sub-selections-common; ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:625: parser error : chunk is not well balanced ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/media_api.xml:73: parser error : Failure to process entity sub-v4l2 &sub-v4l2; ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/media_api.xml:73: parser error : Entity 'sub-v4l2' not defined &sub-v4l2; ^ unable to parse /home/crope/linuxtv/code/linux/Documentation/DocBook/media_api.xml /usr/bin/cp: cannot stat `*.*htm*': No such file or directory make[1]: *** [Documentation/DocBook/media_api.html] Error 1 make: *** [htmldocs] Error 2 [crope@localhost linux]$ regards Antti -- http://palosaari.fi/ -- 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
About switching between V4L2_BUF_TYPE_VIDEO_CAPTURE and V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE capture buffers in v4l2-mem2mem, across instances
Hi, I'm using the v4l2-mem2mem infrastructure for a driver I'm writing and I'm looking if it's possible to have the capture vb2_queue to take both V4L2_BUF_TYPE_VIDEO_CAPTURE and V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE buffers, across instances. The IP I'm writing the driver for, handles V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE natively (NV1xM buffers), but I'd also need to support V4L2_BUF_TYPE_VIDEO_CAPTURE as this type is also standard and more application friendly (NV12 and NV16 buffers). In v4l2-mem2mem, v4l2_m2m_ctx_init(), usually called in the device driver's v4l2_file_operations::open() handler, is used to setup (statically) both the output and capture queues of a v4l2-mem2mem device. Setting up the queues types (output and capture) in open() isn't practical for my case, as we can't signal yet the desired type of the capture buffer at that stage. The only way I could find is to call v4l2_m2m_ctx_init() during v4l2_ioctl_ops::vidioc_reqbufs() instead; where depending on the v4l2_requestbuffers::type, I could initialize a mem2mem context with a V4L2_BUF_TYPE_VIDEO_CAPTURE or a V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE capture buffer. The problem is that for the context to be correctly created, userspace has to issue a reqbufs() for the capture buffers first, and then for the output buffers. Doing it for the output buffers first, would yield a call to v4l2_m2m_ctx_init() with an incomplete information about the capture buffers type. Once buffers are requested for a certain type, they remain of that type until the instance is closed, or vidioc_reqbufs() is called w/ v4l2_requestbuffers::count == 0. I could get vidioc_reqbufs() to enforce this logic and only succeed if capture buffers are requested before output buffers; but still this limitation sounds like an artificial and unnecessary. Do you guys think that this is worth fixing in v4l2-mem2mem? If not, is there another proper way to handle both V4L2_BUF_TYPE_VIDEO_CAPTURE and V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE capture buffers in capable v4l2-mem2mem devices? Regards, -Ilyes -- 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: [GIT PULL for 3.6-rc1] media updates part 2
On Tue, 31 Jul 2012, Mauro Carvalho Chehab wrote: > [media] radio-shark: New driver for the Griffin radioSHARK USB radio > receiver This one gives me a build warning if CONFIG_LEDS_CLASS is disabled: ERROR: "led_classdev_register" [drivers/media/radio/shark2.ko] undefined! ERROR: "led_classdev_unregister" [drivers/media/radio/shark2.ko] undefined! -- 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: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Aug 8 19:00:24 CEST 2012 git hash:c3707357c6c651652a87a05eabd7582f90a4 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-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.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: 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.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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
[GIT PULL FOR v3.7] OMAP ISP patches
Hi Mauro, The following changes since commit c3707357c6c651652a87a05eabd7582f90a4: [media] az6007: Update copyright (2012-08-06 09:25:12 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap3isp-omap3isp-next Ivaylo Petrov (1): omap3isp: csi2: Add V4L2_MBUS_FMT_YUYV8_2X8 support Laurent Pinchart (13): omap3isp: Don't access ISP_CTRL directly in the statistics modules omap3isp: Configure HS/VS interrupt source before enabling interrupts omap3isp: preview: Remove lens shading compensation support omap3isp: preview: Pass a prev_params pointer to configuration functions omap3isp: preview: Reorder configuration functions omap3isp: preview: Merge gamma correction and gamma bypass omap3isp: preview: Add support for non-GRBG Bayer patterns omap3isp: video: Split format info bpp field into width and bpp omap3isp: video: Add YUYV8_2X8 and UYVY8_2X8 support omap3isp: ccdc: Remove support for interlaced data and master HS/VS mode omap3isp: ccdc: Remove ispccdc_syncif structure omap3isp: ccdc: Add YUV input formats support omap3isp: Mark the resizer output video node as the default video node Michael Jones (1): omap3isp: queue: Fix omap3isp_video_queue_dqbuf() description comment Peter Meerwald (1): omap3isp: ccdc: No semicolon is needed after switch statement drivers/media/video/omap3isp/cfa_coef_table.h | 16 +- drivers/media/video/omap3isp/isp.c| 51 ++- drivers/media/video/omap3isp/isp.h| 11 +- drivers/media/video/omap3isp/ispccdc.c| 234 + drivers/media/video/omap3isp/ispccdc.h| 37 -- drivers/media/video/omap3isp/ispcsi2.c| 27 +- drivers/media/video/omap3isp/isph3a_aewb.c| 10 +- drivers/media/video/omap3isp/isph3a_af.c | 10 +- drivers/media/video/omap3isp/isphist.c|6 +- drivers/media/video/omap3isp/isppreview.c | 707 drivers/media/video/omap3isp/isppreview.h |1 + drivers/media/video/omap3isp/ispqueue.c | 13 +- drivers/media/video/omap3isp/ispresizer.c |2 + drivers/media/video/omap3isp/ispvideo.c | 57 ++- drivers/media/video/omap3isp/ispvideo.h |6 +- include/linux/omap3isp.h |5 +- include/media/omap3isp.h | 14 +- 17 files changed, 614 insertions(+), 593 deletions(-) -- 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: boot slow down
How hard would it be to get an official kernel option not to load firmware OR be able to set the timeout? -- 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] omap3isp: Mark the resizer output video node as the default video node
On Wed, Aug 08, 2012 at 05:30:57PM +0200, Laurent Pinchart wrote: > The resizer can output YUYV and UYVY in a wide range of sizes, making it > the best video node for regular V4L2 applications. > > Signed-off-by: Laurent Pinchart Thanks! Acked-by: Sakari Ailus -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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] omap3isp: Mark the resizer output video node as the default video node
The resizer can output YUYV and UYVY in a wide range of sizes, making it the best video node for regular V4L2 applications. Signed-off-by: Laurent Pinchart --- drivers/media/video/omap3isp/ispresizer.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap3isp/ispresizer.c b/drivers/media/video/omap3isp/ispresizer.c index ae17d91..a9bfd0a 100644 --- a/drivers/media/video/omap3isp/ispresizer.c +++ b/drivers/media/video/omap3isp/ispresizer.c @@ -1730,6 +1730,8 @@ static int resizer_init_entities(struct isp_res_device *res) if (ret < 0) goto error_video_out; + res->video_out.video.entity.flags |= MEDIA_ENT_FL_DEFAULT; + /* Connect the video nodes to the resizer subdev. */ ret = media_entity_create_link(&res->video_in.video.entity, 0, &res->subdev.entity, RESZ_PAD_SINK, 0); -- 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: [PATCH] dma-buf: add reference counting for exporter module
On Wed, Aug 08, 2012 at 03:53:10PM +0200, Tomasz Stanislawski wrote: > Hi Laurent, > > On 08/08/2012 03:35 PM, Laurent Pinchart wrote: > > Hi Tomasz, > > > > Thanks for the patch. > > > > On Wednesday 08 August 2012 12:17:41 Tomasz Stanislawski wrote: > >> This patch adds reference counting on a module that exports dma-buf and > >> implements its operations. This prevents the module from being unloaded > >> while DMABUF file is in use. > >> > >> Signed-off-by: Tomasz Stanislawski > >> --- > >> Documentation/dma-buf-sharing.txt |3 ++- > >> drivers/base/dma-buf.c | 10 +- > >> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 + > >> drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 + > >> drivers/gpu/drm/nouveau/nouveau_prime.c|1 + > >> drivers/gpu/drm/radeon/radeon_prime.c |1 + > >> drivers/staging/omapdrm/omap_gem_dmabuf.c |1 + > >> include/linux/dma-buf.h|2 ++ > >> 8 files changed, 18 insertions(+), 2 deletions(-) > >> > [snip] > > >> @@ -96,6 +98,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct > >> dma_buf_ops *ops, struct file *file; > >> > >>if (WARN_ON(!priv || !ops > >> +|| !ops->owner > > Thank you for spotting this. > I didn'y know that try_get_module returned true is module was NULL. > > BTW. Is it worth to add ".owner = THIS_MODULE," to all dma_buf > exporters in this patch? Yeah, I think that makes sense. Otherwise it might get lost somewhere, i.e. you can smash my Ack on this. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- 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 7/8] libdvbv5: renamed registration descriptor
Signed-off-by: André Roth
---
lib/include/descriptors.h |2 +-
lib/libdvbv5/descriptors.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/include/descriptors.h b/lib/include/descriptors.h
index 9e3d49b..b1a8e84 100644
--- a/lib/include/descriptors.h
+++ b/lib/include/descriptors.h
@@ -109,7 +109,7 @@ enum descriptors {
video_stream_descriptor = 0x02,
audio_stream_descriptor = 0x03,
hierarchy_descriptor= 0x04,
- dvbpsi_registration_descriptor = 0x05,
+ registration_descriptor = 0x05,
ds_alignment_descriptor = 0x06,
target_background_grid_descriptor = 0x07,
video_window_descriptor = 0x08,
diff --git a/lib/libdvbv5/descriptors.c b/lib/libdvbv5/descriptors.c
index d4fab9a..10a61a3 100644
--- a/lib/libdvbv5/descriptors.c
+++ b/lib/libdvbv5/descriptors.c
@@ -137,7 +137,7 @@ const struct dvb_descriptor dvb_descriptors[] = {
[video_stream_descriptor] = { "video_stream_descriptor", NULL, NULL,
NULL },
[audio_stream_descriptor] = { "audio_stream_descriptor", NULL, NULL,
NULL },
[hierarchy_descriptor] = { "hierarchy_descriptor", NULL, NULL, NULL },
- [dvbpsi_registration_descriptor] = { "dvbpsi_registration_descriptor",
NULL, NULL, NULL },
+ [registration_descriptor] = { "registration_descriptor", NULL, NULL,
NULL },
[ds_alignment_descriptor] = { "ds_alignment_descriptor", NULL, NULL,
NULL },
[target_background_grid_descriptor] = {
"target_background_grid_descriptor", NULL, NULL, NULL },
[video_window_descriptor] = { "video_window_descriptor", NULL, NULL,
NULL },
@@ -1041,7 +1041,7 @@ void hexdump(struct dvb_v5_fe_parms *parms, const char
*prefix, const unsigned c
/* TODO: remove those stuff */
case ds_alignment_descriptor:
-case dvbpsi_registration_descriptor:
+case registration_descriptor:
case service_list_descriptor:
case stuffing_descriptor:
case VBI_data_descriptor:
--
1.7.2.5
--
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] dma-buf: add reference counting for exporter module
Hi Laurent, On 08/08/2012 03:35 PM, Laurent Pinchart wrote: > Hi Tomasz, > > Thanks for the patch. > > On Wednesday 08 August 2012 12:17:41 Tomasz Stanislawski wrote: >> This patch adds reference counting on a module that exports dma-buf and >> implements its operations. This prevents the module from being unloaded >> while DMABUF file is in use. >> >> Signed-off-by: Tomasz Stanislawski >> --- >> Documentation/dma-buf-sharing.txt |3 ++- >> drivers/base/dma-buf.c | 10 +- >> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 + >> drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 + >> drivers/gpu/drm/nouveau/nouveau_prime.c|1 + >> drivers/gpu/drm/radeon/radeon_prime.c |1 + >> drivers/staging/omapdrm/omap_gem_dmabuf.c |1 + >> include/linux/dma-buf.h|2 ++ >> 8 files changed, 18 insertions(+), 2 deletions(-) >> [snip] >> @@ -96,6 +98,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct >> dma_buf_ops *ops, struct file *file; >> >> if (WARN_ON(!priv || !ops >> + || !ops->owner Thank you for spotting this. I didn'y know that try_get_module returned true is module was NULL. BTW. Is it worth to add ".owner = THIS_MODULE," to all dma_buf exporters in this patch? Regards, Tomasz Stanislawski > > THIS_MODULE is defined as ((struct module *)0) when the driver is built-in, > this check should thus be removed. > >>|| !ops->map_dma_buf >>|| !ops->unmap_dma_buf >>|| !ops->release >> -- 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] dma-buf: add reference counting for exporter module
Hi Tomasz,
Thanks for the patch.
On Wednesday 08 August 2012 12:17:41 Tomasz Stanislawski wrote:
> This patch adds reference counting on a module that exports dma-buf and
> implements its operations. This prevents the module from being unloaded
> while DMABUF file is in use.
>
> Signed-off-by: Tomasz Stanislawski
> ---
> Documentation/dma-buf-sharing.txt |3 ++-
> drivers/base/dma-buf.c | 10 +-
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
> drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
> drivers/gpu/drm/nouveau/nouveau_prime.c|1 +
> drivers/gpu/drm/radeon/radeon_prime.c |1 +
> drivers/staging/omapdrm/omap_gem_dmabuf.c |1 +
> include/linux/dma-buf.h|2 ++
> 8 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/dma-buf-sharing.txt
> b/Documentation/dma-buf-sharing.txt index ad86fb8..2613057 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -49,7 +49,8 @@ The dma_buf buffer sharing API usage contains the
> following steps: The buffer exporter announces its wish to export a buffer.
> In this, it connects its own private buffer data, provides implementation
> for operations that can be performed on the exported dma_buf, and flags for
> the file
> - associated with this buffer.
> + associated with this buffer. The operations structure has owner field.
> + You should initialize this to THIS_MODULE in most cases.
>
> Interface:
>struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index c30f3e1..d14b2f5 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> static inline int is_dma_buf_file(struct file *);
>
> @@ -40,6 +41,7 @@ static int dma_buf_release(struct inode *inode, struct
> file *file) dmabuf = file->private_data;
>
> dmabuf->ops->release(dmabuf);
> + module_put(dmabuf->ops->owner);
> kfree(dmabuf);
> return 0;
> }
> @@ -96,6 +98,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct
> dma_buf_ops *ops, struct file *file;
>
> if (WARN_ON(!priv || !ops
> + || !ops->owner
THIS_MODULE is defined as ((struct module *)0) when the driver is built-in,
this check should thus be removed.
> || !ops->map_dma_buf
> || !ops->unmap_dma_buf
> || !ops->release
>
> @@ -105,9 +108,14 @@ struct dma_buf *dma_buf_export(void *priv, const struct
> dma_buf_ops *ops, return ERR_PTR(-EINVAL);
> }
>
> + if (!try_module_get(ops->owner))
> + return ERR_PTR(-ENOENT);
> +
> dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
> - if (dmabuf == NULL)
> + if (dmabuf == NULL) {
> + module_put(ops->owner);
> return ERR_PTR(-ENOMEM);
> + }
>
> dmabuf->priv = priv;
> dmabuf->ops = ops;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c index 613bf8a..cf3bc6d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> @@ -164,6 +164,7 @@ static void exynos_gem_dmabuf_kunmap(struct dma_buf
> *dma_buf, }
>
> static struct dma_buf_ops exynos_dmabuf_ops = {
> + .owner = THIS_MODULE,
> .map_dma_buf= exynos_gem_map_dma_buf,
> .unmap_dma_buf = exynos_gem_unmap_dma_buf,
> .kmap = exynos_gem_dmabuf_kmap,
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c index aa308e1..07ff03b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -152,6 +152,7 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
> struct vm_area_struct * }
>
> static const struct dma_buf_ops i915_dmabuf_ops = {
> + .owner = THIS_MODULE,
> .map_dma_buf = i915_gem_map_dma_buf,
> .unmap_dma_buf = i915_gem_unmap_dma_buf,
> .release = i915_gem_dmabuf_release,
> diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
> b/drivers/gpu/drm/nouveau/nouveau_prime.c index a25cf2c..8605033 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_prime.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
> @@ -127,6 +127,7 @@ static void nouveau_gem_prime_vunmap(struct dma_buf
> *dma_buf, void *vaddr) }
>
> static const struct dma_buf_ops nouveau_dmabuf_ops = {
> + .owner = THIS_MODULE,
> .map_dma_buf = nouveau_gem_map_dma_buf,
> .unmap_dma_buf = nouveau_gem_unmap_dma_buf,
> .release = nouveau_gem_dmabuf_release,
> diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
> b/drivers/gpu/drm/radeon/radeon_prime.c index 6bef46a..4061fd3 100644
> --- a/drivers/gpu/drm/radeon/radeon_prime.c
> +++ b/driv
[PATCH 2/2] ths7303: enable THS7303 for HD modes
From: Manjunath Hadli
add filter settings for high def modes like 1080i,
1080p,720p and others and implementing dv_timings.
Signed-off-by: Manjunath Hadli
Signed-off-by: Lad, Prabhakar
---
drivers/media/video/ths7303.c | 107 ++--
1 files changed, 91 insertions(+), 16 deletions(-)
diff --git a/drivers/media/video/ths7303.c b/drivers/media/video/ths7303.c
index e5c0eed..d997583 100644
--- a/drivers/media/video/ths7303.c
+++ b/drivers/media/video/ths7303.c
@@ -28,6 +28,18 @@
#include
#include
+#define THS7303_CHANNEL_1 1
+#define THS7303_CHANNEL_2 2
+#define THS7303_CHANNEL_3 3
+
+enum ths7303_filter_mode {
+ THS7303_FILTER_MODE_480I_576I,
+ THS7303_FILTER_MODE_480P_576P,
+ THS7303_FILTER_MODE_720P_1080I,
+ THS7303_FILTER_MODE_1080P,
+ THS7303_FILTER_MODE_DISABLE
+};
+
MODULE_DESCRIPTION("TI THS7303 video amplifier driver");
MODULE_AUTHOR("Chaithrika U S");
MODULE_LICENSE("GPL");
@@ -37,35 +49,97 @@ module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Debug level 0-1");
/* following function is used to set ths7303 */
-static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id std)
+int ths7303_setval(struct v4l2_subdev *sd, enum ths7303_filter_mode mode)
{
+ u8 input_bias_chroma = 3;
+ u8 input_bias_luma = 3;
+ int disable = 0;
int err = 0;
- u8 val;
- struct i2c_client *client;
+ u8 val = 0;
+ u8 temp;
- client = v4l2_get_subdevdata(sd);
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (std & (V4L2_STD_ALL & ~V4L2_STD_SECAM)) {
- val = 0x02;
- v4l2_dbg(1, debug, sd, "setting value for SDTV format\n");
- } else {
- val = 0x00;
- v4l2_dbg(1, debug, sd, "disabling all channels\n");
+ if (!client)
+ return -EINVAL;
+
+
+ switch (mode) {
+ case THS7303_FILTER_MODE_1080P:
+ val = (3 << 6);
+ val |= (3 << 3);
+ break;
+ case THS7303_FILTER_MODE_720P_1080I:
+ val = (2 << 6);
+ val |= (2 << 3);
+ break;
+ case THS7303_FILTER_MODE_480P_576P:
+ val = (1 << 6);
+ val |= (1 << 3);
+ break;
+ case THS7303_FILTER_MODE_480I_576I:
+ break;
+ case THS7303_FILTER_MODE_DISABLE:
+ pr_info("mode disabled\n");
+ /* disable all channels */
+ disable = 1;
+ default:
+ /* disable all channels */
+ disable = 1;
}
+ /* Setup channel 2 - Luma - Green */
+ temp = val;
+ if (!disable)
+ val |= input_bias_luma;
+ err = i2c_smbus_write_byte_data(client, THS7303_CHANNEL_2, val);
+ if (err)
+ goto out;
- err |= i2c_smbus_write_byte_data(client, 0x01, val);
- err |= i2c_smbus_write_byte_data(client, 0x02, val);
- err |= i2c_smbus_write_byte_data(client, 0x03, val);
+ /* setup two chroma channels */
+ if (!disable)
+ temp |= input_bias_chroma;
+ err = i2c_smbus_write_byte_data(client, THS7303_CHANNEL_1, temp);
if (err)
- v4l2_err(sd, "write failed\n");
+ goto out;
+ err = i2c_smbus_write_byte_data(client, THS7303_CHANNEL_3, temp);
+ if (err)
+ goto out;
+ return err;
+out:
+ pr_info("write byte data failed\n");
return err;
}
static int ths7303_s_std_output(struct v4l2_subdev *sd, v4l2_std_id norm)
{
- return ths7303_setvalue(sd, norm);
+ if (norm & (V4L2_STD_ALL & ~V4L2_STD_SECAM))
+ return ths7303_setval(sd, THS7303_FILTER_MODE_480I_576I);
+ else
+ return ths7303_setval(sd, THS7303_FILTER_MODE_DISABLE);
+}
+
+/* for setting filter for HD output */
+static int ths7303_s_dv_timings(struct v4l2_subdev *sd,
+ struct v4l2_dv_timings *dv_timings)
+{
+ u32 height = dv_timings->bt.height;
+ int interlaced = dv_timings->bt.interlaced;
+ int res = 0;
+
+ if (height == 1080 && !interlaced)
+ res = ths7303_setval(sd, THS7303_FILTER_MODE_1080P);
+ else if ((height == 720 && !interlaced) ||
+ (height == 1080 && interlaced))
+ res = ths7303_setval(sd, THS7303_FILTER_MODE_720P_1080I);
+ else if ((height == 480 || height == 576) && !interlaced)
+ res = ths7303_setval(sd, THS7303_FILTER_MODE_480P_576P);
+ else
+ /* disable all channels */
+ res = ths7303_setval(sd, THS7303_FILTER_MODE_DISABLE);
+
+ return res;
}
static int ths7303_g_chip_ident(struct v4l2_subdev *sd,
@@ -78,6 +152,7 @@ static int ths7303_g_chip_ident(struct v4l2_subdev *sd,
static const struct v4l2_subdev_video_ops ths7303_video_ops = {
.s_std_
[PATCH 1/2] dm644x: replace the obsolete preset API by the timings API.
From: Hans Verkuil
Signed-off-by: Hans Verkuil
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
---
arch/arm/mach-davinci/board-dm644x-evm.c | 15 ++--
arch/arm/mach-davinci/dm644x.c | 17 +---
drivers/media/video/davinci/vpbe.c | 110
drivers/media/video/davinci/vpbe_display.c | 60 +++
drivers/media/video/davinci/vpbe_venc.c| 25 +++---
include/media/davinci/vpbe.h | 14 ++--
include/media/davinci/vpbe_types.h |8 +--
include/media/davinci/vpbe_venc.h |2 +-
8 files changed, 111 insertions(+), 140 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index d34ed55..3baf56d 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -620,7 +621,7 @@ static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[]
= {
{
.name = "ntsc",
.timings_type = VPBE_ENC_STD,
- .timings= {V4L2_STD_525_60},
+ .std_id = V4L2_STD_525_60,
.interlaced = 1,
.xres = 720,
.yres = 480,
@@ -632,7 +633,7 @@ static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[]
= {
{
.name = "pal",
.timings_type = VPBE_ENC_STD,
- .timings= {V4L2_STD_625_50},
+ .std_id = V4L2_STD_625_50,
.interlaced = 1,
.xres = 720,
.yres = 576,
@@ -647,8 +648,8 @@ static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[]
= {
static struct vpbe_enc_mode_info dm644xevm_enc_preset_timing[] = {
{
.name = "480p59_94",
- .timings_type = VPBE_ENC_DV_PRESET,
- .timings= {V4L2_DV_480P59_94},
+ .timings_type = VPBE_ENC_CUSTOM_TIMINGS,
+ .dv_timings = V4L2_DV_BT_CEA_720X480P59_94,
.interlaced = 0,
.xres = 720,
.yres = 480,
@@ -659,8 +660,8 @@ static struct vpbe_enc_mode_info
dm644xevm_enc_preset_timing[] = {
},
{
.name = "576p50",
- .timings_type = VPBE_ENC_DV_PRESET,
- .timings= {V4L2_DV_576P50},
+ .timings_type = VPBE_ENC_CUSTOM_TIMINGS,
+ .dv_timings = V4L2_DV_BT_CEA_720X576P50,
.interlaced = 0,
.xres = 720,
.yres = 576,
@@ -698,7 +699,7 @@ static struct vpbe_output dm644xevm_vpbe_outputs[] = {
.index = 1,
.name = "Component",
.type = V4L2_OUTPUT_TYPE_ANALOG,
- .capabilities = V4L2_OUT_CAP_PRESETS,
+ .capabilities = V4L2_OUT_CAP_CUSTOM_TIMINGS,
},
.subdev_name= VPBE_VENC_SUBDEV_NAME,
.default_mode = "480p59_94",
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index c8b8666..79d2880 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -701,7 +701,7 @@ static struct resource dm644x_venc_resources[] = {
#define DM644X_VPSS_DACCLKEN BIT(4)
static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type,
- unsigned int mode)
+ unsigned int pclock)
{
int ret = 0;
u32 v = DM644X_VPSS_VENCLKEN;
@@ -711,27 +711,18 @@ static int dm644x_venc_setup_clock(enum
vpbe_enc_timings_type type,
v |= DM644X_VPSS_DACCLKEN;
writel(v, DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL));
break;
- case VPBE_ENC_DV_PRESET:
- switch (mode) {
- case V4L2_DV_480P59_94:
- case V4L2_DV_576P50:
+ case VPBE_ENC_CUSTOM_TIMINGS:
+ if (pclock <= 2700) {
v |= DM644X_VPSS_MUXSEL_PLL2_MODE |
DM644X_VPSS_DACCLKEN;
writel(v, DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL));
- break;
- case V4L2_DV_720P60:
- case V4L2_DV_1080I60:
- case V4L2_DV_1080P30:
+ } else {
/*
* For HD, use external clock source since
* HD requires higher clock rate
*/
v |= DM644X_VPSS_MUXSEL_VPBECLK_MODE;
writel(v, DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL));
-
[PATCH 0/2] Replace the obsolete preset API by timings API
This first patch replaces the obsolete preset API by timings API for davinci VPBE, appropriate chnages in machine file for dm644x in which VPBE is enabled. And the second patch adds support for timings API for ths7303 driver. Sending them as s series since VPBE uses the ths7303 driver. Hans Verkuil (1): dm644x: replace the obsolete preset API by the timings API. Manjunath Hadli (1): ths7303: enable THS7303 for HD modes arch/arm/mach-davinci/board-dm644x-evm.c | 15 ++-- arch/arm/mach-davinci/dm644x.c | 17 +--- drivers/media/video/davinci/vpbe.c | 110 drivers/media/video/davinci/vpbe_display.c | 60 +++ drivers/media/video/davinci/vpbe_venc.c| 25 +++--- drivers/media/video/ths7303.c | 107 +++ include/media/davinci/vpbe.h | 14 ++-- include/media/davinci/vpbe_types.h |8 +-- include/media/davinci/vpbe_venc.h |2 +- 9 files changed, 202 insertions(+), 156 deletions(-) -- 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] vpif: replace preset with the timings API.
From: Hans Verkuil
Signed-off-by: Hans Verkuil
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
---
drivers/media/video/davinci/vpif.c | 16 ++--
drivers/media/video/davinci/vpif.h |4 +-
drivers/media/video/davinci/vpif_capture.c | 114 +---
drivers/media/video/davinci/vpif_capture.h |3 +-
drivers/media/video/davinci/vpif_display.c | 102 +++--
drivers/media/video/davinci/vpif_display.h |3 +-
6 files changed, 43 insertions(+), 199 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.c
b/drivers/media/video/davinci/vpif.c
index b3637af..b95bff7 100644
--- a/drivers/media/video/davinci/vpif.c
+++ b/drivers/media/video/davinci/vpif.c
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+
#include
#include "vpif.h"
@@ -65,7 +67,7 @@ const struct vpif_channel_config_params ch_params[] = {
.capture_format = 0,
.vbi_supported = 0,
.hd_sd = 1,
- .dv_preset = V4L2_DV_480P59_94,
+ .dv_timings = V4L2_DV_BT_CEA_720X480P59_94,
},
{
.name = "576p50",
@@ -82,7 +84,7 @@ const struct vpif_channel_config_params ch_params[] = {
.capture_format = 0,
.vbi_supported = 0,
.hd_sd = 1,
- .dv_preset = V4L2_DV_576P50,
+ .dv_timings = V4L2_DV_BT_CEA_720X576P50,
},
{
.name = "720p50",
@@ -99,7 +101,7 @@ const struct vpif_channel_config_params ch_params[] = {
.capture_format = 0,
.vbi_supported = 0,
.hd_sd = 1,
- .dv_preset = V4L2_DV_720P50,
+ .dv_timings = V4L2_DV_BT_CEA_1280X720P50,
},
{
.name = "720p60",
@@ -116,7 +118,7 @@ const struct vpif_channel_config_params ch_params[] = {
.capture_format = 0,
.vbi_supported = 0,
.hd_sd = 1,
- .dv_preset = V4L2_DV_720P60,
+ .dv_timings = V4L2_DV_BT_CEA_1280X720P60,
},
{
.name = "1080I50",
@@ -136,7 +138,7 @@ const struct vpif_channel_config_params ch_params[] = {
.capture_format = 0,
.vbi_supported = 0,
.hd_sd = 1,
- .dv_preset = V4L2_DV_1080I50,
+ .dv_timings = V4L2_DV_BT_CEA_1920X1080I50,
},
{
.name = "1080I60",
@@ -156,7 +158,7 @@ const struct vpif_channel_config_params ch_params[] = {
.capture_format = 0,
.vbi_supported = 0,
.hd_sd = 1,
- .dv_preset = V4L2_DV_1080I60,
+ .dv_timings = V4L2_DV_BT_CEA_1920X1080I60,
},
{
.name = "1080p60",
@@ -173,7 +175,7 @@ const struct vpif_channel_config_params ch_params[] = {
.capture_format = 0,
.vbi_supported = 0,
.hd_sd = 1,
- .dv_preset = V4L2_DV_1080P60,
+ .dv_timings = V4L2_DV_BT_CEA_1920X1080P60,
},
/* SDTV formats */
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index c2ce4d9..a1ab6a0 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -533,7 +533,7 @@ static inline void channel2_clipping_enable(int enable)
}
}
-/* function to enable clipping (for both active and blanking regions) on ch 2
*/
+/* function to enable clipping (for both active and blanking regions) on ch 3
*/
static inline void channel3_clipping_enable(int enable)
{
if (enable) {
@@ -634,7 +634,7 @@ struct vpif_channel_config_params {
* supports capturing vbi or not */
u8 hd_sd; /* HDTV (1) or SDTV (0) format */
v4l2_std_id stdid; /* SDTV format */
- u32 dv_preset; /* HDTV format */
+ struct v4l2_dv_timings dv_timings; /* HDTV format */
};
extern const unsigned int vpif_ch_params_count;
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index 266025e..e684c48 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -551,7 +551,8 @@ static int vpif_update_std_info(struct channel_obj *ch)
}
} else {
vpif_dbg(2, debug, "HD format\n");
- if (config->dv_preset == vid_ch->dv_preset) {
+ if (!memcmp(&config->dv_timings, &vid_ch->dv_timings,
+ sizeof(vid_ch->dv_timings))) {
memcpy(std_info, config, sizeof(*config));
break;
}
@@ -1368,8 +1369,7 @@ static int vpif_s_std(struct file *f
Re: [RFC PATCH 0/2] Add support for RDS decoding (updated)
just for the record, these patches are: Signed-off-by: Konke Radlow Regards, Konke On Tue, Aug 7, 2012 at 3:11 PM, Konke Radlow wrote: > Hello, > first of all: thank you for the comments to my previous RFC for the > libv4l2rds library and the rds-ctl control & testing tool. > The proposed changes have been implemented, and the code has been > further improved after a thorough code review by Hans Verkuil. > > Changes: > -the code is rebased on the latest v4l-utils code (as of today 07.08) > -added feature: time/date decoding > -implementing proposed changes > -code cleanup > -extended comments > > Status: > From my point of view the RDS decoding is now almost feature complete. > There are some obscure RDS features like paging that are not supported, > but they do not seem to used anywhere. > So in the near future no features will be added and the goal is to get > the library and control tool merged into the v4l-utils codebase. > > Upcoming: > Work on RDS-TMC decoding is going well and is being done in a seperate > branch. It will be the subject of a future RFC, once it has reached a > mature stage. But TMC is not a core feature of RDS but an addition. > > Regards, > Konke > -- 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] dma-buf: add reference counting for exporter module
This patch adds reference counting on a module that exports dma-buf and
implements its operations. This prevents the module from being unloaded while
DMABUF file is in use.
Signed-off-by: Tomasz Stanislawski
---
Documentation/dma-buf-sharing.txt |3 ++-
drivers/base/dma-buf.c | 10 +-
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
drivers/gpu/drm/nouveau/nouveau_prime.c|1 +
drivers/gpu/drm/radeon/radeon_prime.c |1 +
drivers/staging/omapdrm/omap_gem_dmabuf.c |1 +
include/linux/dma-buf.h|2 ++
8 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index ad86fb8..2613057 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -49,7 +49,8 @@ The dma_buf buffer sharing API usage contains the following
steps:
The buffer exporter announces its wish to export a buffer. In this, it
connects its own private buffer data, provides implementation for operations
that can be performed on the exported dma_buf, and flags for the file
- associated with this buffer.
+ associated with this buffer. The operations structure has owner field.
+ You should initialize this to THIS_MODULE in most cases.
Interface:
struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index c30f3e1..d14b2f5 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
static inline int is_dma_buf_file(struct file *);
@@ -40,6 +41,7 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
dmabuf = file->private_data;
dmabuf->ops->release(dmabuf);
+ module_put(dmabuf->ops->owner);
kfree(dmabuf);
return 0;
}
@@ -96,6 +98,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct
dma_buf_ops *ops,
struct file *file;
if (WARN_ON(!priv || !ops
+ || !ops->owner
|| !ops->map_dma_buf
|| !ops->unmap_dma_buf
|| !ops->release
@@ -105,9 +108,14 @@ struct dma_buf *dma_buf_export(void *priv, const struct
dma_buf_ops *ops,
return ERR_PTR(-EINVAL);
}
+ if (!try_module_get(ops->owner))
+ return ERR_PTR(-ENOENT);
+
dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
- if (dmabuf == NULL)
+ if (dmabuf == NULL) {
+ module_put(ops->owner);
return ERR_PTR(-ENOMEM);
+ }
dmabuf->priv = priv;
dmabuf->ops = ops;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 613bf8a..cf3bc6d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -164,6 +164,7 @@ static void exynos_gem_dmabuf_kunmap(struct dma_buf
*dma_buf,
}
static struct dma_buf_ops exynos_dmabuf_ops = {
+ .owner = THIS_MODULE,
.map_dma_buf= exynos_gem_map_dma_buf,
.unmap_dma_buf = exynos_gem_unmap_dma_buf,
.kmap = exynos_gem_dmabuf_kmap,
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index aa308e1..07ff03b 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -152,6 +152,7 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
struct vm_area_struct *
}
static const struct dma_buf_ops i915_dmabuf_ops = {
+ .owner = THIS_MODULE,
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
.release = i915_gem_dmabuf_release,
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index a25cf2c..8605033 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -127,6 +127,7 @@ static void nouveau_gem_prime_vunmap(struct dma_buf
*dma_buf, void *vaddr)
}
static const struct dma_buf_ops nouveau_dmabuf_ops = {
+ .owner = THIS_MODULE,
.map_dma_buf = nouveau_gem_map_dma_buf,
.unmap_dma_buf = nouveau_gem_unmap_dma_buf,
.release = nouveau_gem_dmabuf_release,
diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
b/drivers/gpu/drm/radeon/radeon_prime.c
index 6bef46a..4061fd3 100644
--- a/drivers/gpu/drm/radeon/radeon_prime.c
+++ b/drivers/gpu/drm/radeon/radeon_prime.c
@@ -127,6 +127,7 @@ static void radeon_gem_prime_vunmap(struct dma_buf
*dma_buf, void *vaddr)
mutex_unlock(&dev->struct_mutex);
}
const static struct dma_buf_ops radeon_dmabuf_ops = {
+ .owner = THIS_MODULE,
.map_dma_buf = radeon_gem_map_dma_buf,
.unmap_d
[PATCH,RESEND] v4l/s5p-mfc: added support for end of stream handling in MFC encoder
s5p-mfc encoder after receiving V4L2_ENC_CMD_STOP command
will instruct MFC device to release all encoded frames.
After dequeuing last encoded frame driver will generate
V4L2_EVENT_EOS event.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-mfc/s5p_mfc.c| 43 +++
drivers/media/video/s5p-mfc/s5p_mfc_common.h |5 +-
drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c |8 ++-
drivers/media/video/s5p-mfc/s5p_mfc_dec.c|4 +-
drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 106 +-
drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 48 +---
6 files changed, 178 insertions(+), 36 deletions(-)
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc.c
b/drivers/media/video/s5p-mfc/s5p_mfc.c
index 9bb68e7..dc9355c 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include "regs-mfc.h"
@@ -539,6 +540,40 @@ static void s5p_mfc_handle_init_buffers(struct s5p_mfc_ctx
*ctx,
}
}
+static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx,
+unsigned int reason, unsigned int err)
+{
+ struct s5p_mfc_dev *dev = ctx->dev;
+ struct s5p_mfc_buf *mb_entry;
+
+ mfc_debug(2, "Stream completed");
+
+ s5p_mfc_clear_int_flags(dev);
+ ctx->int_type = reason;
+ ctx->int_err = err;
+ ctx->state = MFCINST_FINISHED;
+
+ spin_lock(&dev->irqlock);
+ if (!list_empty(&ctx->dst_queue)) {
+ mb_entry = list_entry(ctx->dst_queue.next, struct s5p_mfc_buf,
+ list);
+ list_del(&mb_entry->list);
+ ctx->dst_queue_cnt--;
+ vb2_set_plane_payload(mb_entry->b, 0, 0);
+ vb2_buffer_done(mb_entry->b, VB2_BUF_STATE_DONE);
+ }
+ spin_unlock(&dev->irqlock);
+
+ clear_work_bit(ctx);
+
+ if (test_and_clear_bit(0, &dev->hw_lock) == 0)
+ WARN_ON(1);
+
+ s5p_mfc_clock_off();
+ wake_up(&ctx->queue);
+ s5p_mfc_try_run(dev);
+}
+
/* Interrupt processing */
static irqreturn_t s5p_mfc_irq(int irq, void *priv)
{
@@ -614,6 +649,11 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
case S5P_FIMV_R2H_CMD_INIT_BUFFERS_RET:
s5p_mfc_handle_init_buffers(ctx, reason, err);
break;
+
+ case S5P_FIMV_R2H_CMD_ENC_COMPLETE_RET:
+ s5p_mfc_handle_stream_complete(ctx, reason, err);
+ break;
+
default:
mfc_debug(2, "Unknown int reason\n");
s5p_mfc_clear_int_flags(dev);
@@ -882,9 +922,12 @@ static unsigned int s5p_mfc_poll(struct file *file,
goto end;
}
mutex_unlock(&dev->mfc_mutex);
+ poll_wait(file, &ctx->fh.wait, wait);
poll_wait(file, &src_q->done_wq, wait);
poll_wait(file, &dst_q->done_wq, wait);
mutex_lock(&dev->mfc_mutex);
+ if (v4l2_event_pending(&ctx->fh))
+ rc |= POLLPRI;
spin_lock_irqsave(&src_q->done_lock, flags);
if (!list_empty(&src_q->done_list))
src_vb = list_first_entry(&src_q->done_list, struct vb2_buffer,
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_common.h
b/drivers/media/video/s5p-mfc/s5p_mfc_common.h
index bd5706a..8871f0d 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_common.h
@@ -146,6 +146,9 @@ enum s5p_mfc_decode_arg {
MFC_DEC_RES_CHANGE,
};
+#define MFC_BUF_FLAG_USED (1 << 0)
+#define MFC_BUF_FLAG_EOS (1 << 1)
+
struct s5p_mfc_ctx;
/**
@@ -161,7 +164,7 @@ struct s5p_mfc_buf {
} raw;
size_t stream;
} cookie;
- int used;
+ int flags;
};
/**
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
index 08a5cfe..84c5b8f 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
@@ -78,7 +78,7 @@ int s5p_mfc_alloc_and_load_firmware(struct s5p_mfc_dev *dev)
}
dev->bank1 = s5p_mfc_bitproc_phys;
b_base = vb2_dma_contig_memops.alloc(
- dev->alloc_ctx[MFC_BANK2_ALLOC_CTX], 1 <<
MFC_BANK2_ALIGN_ORDER);
+ dev->alloc_ctx[MFC_BANK2_ALLOC_CTX], 1 << MFC_BASE_ALIGN_ORDER);
if (IS_ERR(b_base)) {
vb2_dma_contig_memops.put(s5p_mfc_bitproc_buf);
s5p_mfc_bitproc_phys = 0;
@@ -98,7 +98,11 @@ int s5p_mfc_alloc_and_load_firmware(struct s5p_mfc_dev *dev)
release_firmware(fw_blob);
return -EIO;
}
- dev->bank2 = bank2_base_phys;
+ /* Valid buffers passed to MFC encoder with LAST_FRAME command
+* should not have address of bank2 - MFC will treat it as a null frame.
+
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
On Wed 8 August 2012 11:35:38 Sakari Ailus wrote: > Hi Hans and Rémi, > > On Thu, Aug 02, 2012 at 08:35:58AM +0200, Hans Verkuil wrote: > ... > > Minimum or maximum? The maximum is 32, that's hardcoded in the V4L2 core. > > As far as I understand, V4L1 did have that limitation, as well as videobuf1 > and 2 and a number of other drivers, but it's not found in the V4L2 core > itself. While I'm not aware of a driver that'd allow creating more buffers > than that the changes required to support more would be likely limited to > videobuf2. You are correct. It does not touch the v4l2 core, just videobuf and videobuf2. Although the define is in videodev2.h as well, so it's something that apps might use as well. But frankly, 32 is a very generous maximum anyway. Only in special cases can I imagine needing more buffers (frame slicing, high-speed capture). Regards, Hans -- 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 2/2] dvb_usb_v2: use %*ph to dump usb xfer debugs
On 08/08/2012 07:16 AM, Andy Shevchenko wrote: On Wed, Aug 8, 2012 at 1:56 AM, Antti Palosaari wrote: diff --git a/drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c b/drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c index 5f5bdd0..0431bee 100644 --- a/drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c +++ b/drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c @@ -37,10 +36,8 @@ int dvb_usbv2_generic_rw(struct dvb_usb_device *d, u8 *wbuf, u16 wlen, u8 *rbuf, if (ret < 0) return ret; -#ifdef DVB_USB_XFER_DEBUG - print_hex_dump(KERN_DEBUG, KBUILD_MODNAME ": >>> ", DUMP_PREFIX_NONE, - 32, 1, wbuf, wlen, 0); -#endif + dev_dbg(&d->udev->dev, "%s: >>> %*ph\n", __func__, wlen, wbuf); + ret = usb_bulk_msg(d->udev, usb_sndbulkpipe(d->udev, d->props->generic_bulk_ctrl_endpoint), wbuf, wlen, &actual_length, 2000); @@ -64,11 +61,8 @@ int dvb_usbv2_generic_rw(struct dvb_usb_device *d, u8 *wbuf, u16 wlen, u8 *rbuf, dev_err(&d->udev->dev, "%s: 2nd usb_bulk_msg() " \ "failed=%d\n", KBUILD_MODNAME, ret); -#ifdef DVB_USB_XFER_DEBUG - print_hex_dump(KERN_DEBUG, KBUILD_MODNAME ": <<< ", - DUMP_PREFIX_NONE, 32, 1, rbuf, actual_length, - 0); -#endif + dev_dbg(&d->udev->dev, "%s: <<< %*ph\n", __func__, + actual_length, rbuf); } Antti, I didn't check how long buffer could be in above cases, but be aware that %*ph prints up to 64 bytes only. Is it enough here? It is correct behavior. I saw from the LKML patch limit was selected using min_t() not causing any other side effect than cut print length. For some cases it could be more than 64 here, likely for the firmware download packed. I suspect, situation where control message is longer than 64 byte does not exist in real life as USB1.1 BULK max is 64. And even such case exists, we are not interested those not printed bytes. regards Antti -- http://palosaari.fi/ -- 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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Hans and Rémi, On Thu, Aug 02, 2012 at 08:35:58AM +0200, Hans Verkuil wrote: ... > Minimum or maximum? The maximum is 32, that's hardcoded in the V4L2 core. As far as I understand, V4L1 did have that limitation, as well as videobuf1 and 2 and a number of other drivers, but it's not found in the V4L2 core itself. While I'm not aware of a driver that'd allow creating more buffers than that the changes required to support more would be likely limited to videobuf2. Regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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: boot slow down
Hi James, On Tue, Aug 07, 2012 at 05:42:48PM -0400, James wrote: ... > This is what I tried before. > It implies that I shouldn't need user space. > > Include in-kernel firmware blobs in > kernel binary > ??? CONFIG_FIRMWARE_IN_KERNEL: > ??? > ??? > ??? > ??? The kernel source tree includes a number of firmware 'blobs' > ??? > ??? that are used by various drivers. The recommended way to > ??? > ??? use these is to run "make firmware_install", which, after > ??? > ??? converting ihex files to binary, copies all of the needed > ??? > ??? binary files in firmware/ to /lib/firmware/ on your system so > ??? > ??? that they can be loaded by userspace helpers on request. > ??? > ??? > ??? > ??? Enabling this option will build each required firmware blob > ??? > ??? into the kernel directly, where request_firmware() will find > ??? > ??? them without having to call out to userspace. This may be > ??? > ??? useful if your root file system requires a device that uses > ??? > ??? such firmware and do not wish to use an initrd. > ??? > ??? > ??? > ??? This single option controls the inclusion of firmware for > ??? > ??? every driver that uses request_firmware() and ships its > ??? > ??? firmware in the kernel source tree, which avoids a > ??? > ??? proliferation of 'Include firmware for xxx device' options. > ??? > ??? > ??? > ??? Say 'N' and let firmware be loaded from userspace. I guess this only applies to firmware blobs which are part of the kernel. Not all of them are. Regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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
