Re: [PATCH V3 03/15] [media] marvell-ccic: add clock tree support for marvell-ccic driver
On 2012-12-16 22:51, Albert Wang wrote:
[...]
+static void mcam_clk_set(struct mcam_camera *mcam, int on)
+{
+ unsigned int i;
+
+ if (on) {
+ for (i = 0; i mcam-clk_num; i++) {
+ if (mcam-clk[i])
+ clk_enable(mcam-clk[i]);
+ }
+ } else {
+ for (i = mcam-clk_num; i 0; i--) {
+ if (mcam-clk[i - 1])
+ clk_disable(mcam-clk[i - 1]);
+ }
+ }
+}
A couple of minor comments:
- This function is always called with a constant value for on. It would
be easier to read (and less prone to unfortunate brace errors) if it
were just two functions: mcam_clk_enable() and mcam_clk_disable().
[Albert Wang] OK, that's fine to split it to 2 functions. :)
- I'd write the second for loop as:
for (i = mcal-clk_num - 1; i = 0; i==) {
just to match the values used in the other direction and avoid the
subscript arithmetic.
[Albert Wang] Yes, we can improve it. :)
Bewar: i is unsigned so testing i = 0 will loop forever.
[...]--
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 TRIVIAL for 3.7] Documentation: fix outdated statement re. v4l2
Fix tense used for describing struct v4l2_fh as it has been added a while ago. Signed-off-by: Nicolas Thery nicolas.th...@st.com --- Documentation/video4linux/v4l2-framework.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 32bfe92..0a1ef67 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -68,8 +68,7 @@ Structure of the framework The framework closely resembles the driver structure: it has a v4l2_device struct for the device instance data, a v4l2_subdev struct to refer to sub-device instances, the video_device struct stores V4L2 device node data -and in the future a v4l2_fh struct will keep track of filehandle instances -(this is not yet implemented). +and the v4l2_fh struct keeps track of filehandle instances. The V4L2 framework also optionally integrates with the media framework. If a driver sets the struct v4l2_device mdev field, sub-devices and video nodes -- 1.7.11.3-- 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 TRIVIAL for 3.7] mem2mem: replace BUG_ON with WARN_ON
See following thread for rationale:
http://www.spinics.net/lists/linux-media/msg52462.html
Tested by compilation only.
Signed-off-by: Nicolas Thery nicolas.th...@st.com
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 3ac8358..017fed8 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -510,12 +510,10 @@ struct v4l2_m2m_dev *v4l2_m2m_init(struct v4l2_m2m_ops
*m2m_ops)
{
struct v4l2_m2m_dev *m2m_dev;
- if (!m2m_ops)
+ if (!m2m_ops || WARN_ON(!m2m_ops-device_run) ||
+ WARN_ON(!m2m_ops-job_abort))
return ERR_PTR(-EINVAL);
- BUG_ON(!m2m_ops-device_run);
- BUG_ON(!m2m_ops-job_abort);
-
m2m_dev = kzalloc(sizeof *m2m_dev, GFP_KERNEL);
if (!m2m_dev)
return ERR_PTR(-ENOMEM);
--
1.7.11.3
--
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
how to crop/scale in mono-subdev camera sensor driver?
Hello, I'm studying how to support cropping and scaling (binning, skipping, digital scaling if any) for different models for camera sensor drivers. There seems to be (at least) two kinds of sensor drivers: 1) The smiapp driver has 2 or 3 subdevs: pixel array - binning (- scaling). It gives clients full control over the various ways of cropping and scaling thanks to the selection API. 2) The mt9p031 driver (and maybe others) has a single subdev. Clients use the obsolete SUBDEV_S_CROP ioctl for selecting a region of interest in the pixel array and SUBDEV_S_FMT for setting the source pad mbus size. If the mbus size differs from the cropping rectangle size, scaling is enabled and the driver decides internally how to combine skipping and binning to achieve the requested scaling factors. As SUBDEV_S_CROP is obsolete, I wonder whether it is okay to support cropping and scaling in a mono-subdev sensor driver by (a) setting the cropping rectangle with SUBDEV_S_SELECTION on the source pad, and (b) setting the scaling factors via the source pad mbus size as in the mt9p031 driver? Thanks in advance. Best regards, Nicolas-- 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] drivers: media: video: Add support for Aptina ar0130 sensor
Hello,
I've spotted a minor issue while glancing through the code.
Cheers,
Nicolas
On 2012-09-07 11:30, Prashanth Subramanya wrote:
This driver adds basic support for Aptina ar0130 1.2M sensor.
Signed-off-by: Prashanth Subramanya sprasha...@aptina.com
---
[snip]
+/***
+ v4l2_subdev_video_ops
+/
+static int ar0130_s_stream(struct v4l2_subdev *sd, int enable)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ar0130_priv *ar0130 = container_of(sd,
+ struct ar0130_priv, subdev);
+ int ret;
+
+ if (!enable) {
+ ret = ar0130_write(client, AR0130_RESET_REG,
AR0130_STREAM_OFF);
+ return 0;
+ }
+
+ ret = ar0130_linear_mode_setup(client);
+ if (ret 0) {
+ dev_err(ar0130-subdev.v4l2_dev-dev,
+ Failed to setup linear mode: %d\n, ret);
+ return ret;
+ }
+
+ ret = ar0130_set_resolution(client, ar0130-res_index);
+ if (ret 0) {
+ dev_err(ar0130-subdev.v4l2_dev-dev,
+ Failed to setup resolution: %d\n, ret);
+ return ret;
+ }
+
+ ret |= ar0130_write(client, AR0130_RESET_REG, AR0130_STREAM_OFF);
+ ret |= ar0130_write(client, AR0130_HDR_COMP, 0x0001);
+
+ ret = ar0130_pll_enable(ar0130);
The previous value of ret is overwritten here.
+ if (ret 0) {
+ dev_err(ar0130-subdev.v4l2_dev-dev,
+ Failed to enable pll: %d\n, ret);
+ return ret;
+ }
+
+ ret = ar0130_set_autoexposure(client, AR0130_ENABLE);
+ ret |= ar0130_write(client, AR0130_RESET_REG, AR0130_STREAM_ON);
+
+ return ret;
+}
Re: [RFC v4] V4L DT bindings
Hello, Thanks for the feedback. On 2012-08-30 22:21, Sylwester Nawrocki wrote: On 08/30/2012 05:19 PM, Nicolas THERY wrote: [snip] In imx074@0x1a above, the data-lanes property is1,2. Is it reversed here to show that lanes are swapped between the sensor and the CSI rx? If not, how to express lane swapping? Yes, this indicates lanes remapping at the receiver. Probably we could make it a single value with length determined by 'bus-width', since we're going to use 'bus-width' for CSI buses as well, (optionally) in addition to 'clock-lanes' and 'data-lanes' ? Looks good to me. [snip] How to express that the positive and negative signals of a given clock/data lane are inversed? Is it somehow with the hsync-active property? Hmm, I don't think this is covered in this RFC. hsync-active is mostly intended for the parallel buses. We need to come up with new properties to handle CSI data/clock lane polarity swapping. There was a short discussion about that already: http://www.mail-archive.com/linux-media@vger.kernel.org/msg41724.html Actually there may be two positive/negative inversion cases to consider: - the positive/negative signals are inversed both in low-power and high-speed modes (e.g. physical lines between sensor module and SoC are swapped on the PCB); - the positive/negative signals are inversed in high-speed mode only (the sensor and CSI rx use opposite polarities in high-speed mode). Then is this positive/negative LVDS lines swapping separately configurable in hardware for low-power and high-speed mode ? Yes. What is an advantage of it ? I suspect our hardware people after years of experience with not-so-compliant sensors and weird PCBs have adopted a belt-and-suspenders approach and made configurable everything they thought could go wrong. In the inversion in high-speed mode only case, that could be because the sensor does not use the standard-specified polarity. One possible solution would be to have a one to two elements array property, e.g. lanes-polarity = 0 0 0 0 0, 1 1 1 1 1; where the first entry would indicate lanes polarity for high speed mode and the second one for low power mode. For receivers/transmitters that don't allow to configure the polarities separately for different bus states there could be just one entry. The width of each element could be determined by value of the 'bus-width' property + 1. Would it make sense ? Yes, that looks fine. Incidentally is it okay to extend DT nodes with manufacturer-specific properties? I'm asking because our CSI rx supports other esoteric lane-related configuration knobs, e.g. for impedance tuning. We'd like to put them in the DT but they probably don't warrant an official property. Thanks a lot again. Best regards, Nicolas-- 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 v4] V4L DT bindings
Hello,
On 2012-08-25 01:27, Guennadi Liakhovetski wrote:
[snip]
csi2: csi2@0xffc9 {
compatible = renesas,sh-mobile-csi2;
reg = 0xffc9 0x1000;
interrupts = 0x17a0;
#address-cells = 1;
#size-cells = 0;
/* Ok to have them global? */
clock-lanes = 0;
data-lanes = 2, 1;
...
imx074_1: videolink@1 {
reg = 1;
client = imx074 0;
bus-width = 2;
csi2-ecc;
csi2-crc;
renesas,csi2-phy = 0;
};
ceu0: videolink@0 {
reg = 0;
immutable;
};
};
videolink@1 makes the description of the CSI-2 rx board-specific. Would it be
possible to keep the description of the SoC nodes board-agnostic to ease reuse
of the SoC description in multiple board DTs?
Would this be as simple as replacing imx074 with a generic well-known name
defined in the board part of the DT?
Best regards,
Nicolas--
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 RFC 0/4] V4L2: Vendor specific media bus formats/ frame size control
Hello, Thanks for your reply. It's good to know your proposal is simply on the back-burner. Best regards, Nicolas On 2012-08-29 20:41, sakari.ai...@iki.fi wrote: Hi Nicolas, On Mon, Aug 27, 2012 at 05:48:43PM +0200, Nicolas THERY wrote: Hello, On 2012-08-23 11:51, Sylwester Nawrocki wrote: This patch series introduces new image source class control - V4L2_CID_FRAMESIZE and vendor or device specific media bus format section. There was already a discussion WRT handling interleaved image data [1]. I'm not terribly happy with those vendor specific media bus formats but I couldn't find better solution that would comply with the V4L2 API concepts and would work reliably. What about Sakari's Frame format descriptors RFC[1] that would allow to describe arbitrary pixel code combinations and provide required information (virtual channel and data type) to the CSI receiver driver for configuring the hardware? I we'll need to continue that work as well, unfortunately I've had higher priority things to do. Still, getting that right is complex and will take time. The V4L2 pixel format for this sensor will likely be a hardware-specific one for quite a while: this sensor in question sends several frames in different formats of a single image at once which doesn't match to V4L2's pixel format configuration that assumes a single format. Kind regards, -- 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 RFC 0/4] V4L2: Vendor specific media bus formats/ frame size control
Hello, Thanks for your reply. I overlooked this sensor packages multiple streams in a single DT. It seems indeed that Sakari's RFC would not help. Best regards, On 2012-08-29 23:51, Sylwester Nawrocki wrote: Hi Nicolas, On 08/27/2012 05:48 PM, Nicolas THERY wrote: Hello, On 2012-08-23 11:51, Sylwester Nawrocki wrote: This patch series introduces new image source class control - V4L2_CID_FRAMESIZE and vendor or device specific media bus format section. There was already a discussion WRT handling interleaved image data [1]. I'm not terribly happy with those vendor specific media bus formats but I couldn't find better solution that would comply with the V4L2 API concepts and would work reliably. What about Sakari's Frame format descriptors RFC[1] that would allow to describe arbitrary pixel code combinations and provide required information (virtual channel and data type) to the CSI receiver driver for configuring the hardware? Thanks for reminding about this. The Frame format descriptors would not necessarily solve the main problem which I tried to address in this RFC. The sensor in question uses single MIPI-CSI data type frame as a container for multiple data planes, e.g. JPEG compressed stream interleaved with YUV image data, some optional padding and a specific metadata describing the interleaved image data. There is no MIPI-CSI2 virtual channel or data type interleaving. Everything is transferred on single VC and single DT. Such a frames need sensor specific S/W algorithm do extract each component. So it didn't look like the frame descriptors would be helpful here, since all this needs to be mapped to a single fourcc. Not sure if defining a binary blob fourcc and retrieving frame format information by some other means would have been a way to go. I also had some patches adopting design from Sakari's RFC, for the case where in addition to the above frame format there was captured a copy of meta-data, (as in the frame footer) send on separate DT (Embedded Data). And this was mapped to 2-planar V4L2 pixel format. Even then I used a sensor specific media bus code. In the end of the day I switched to a single-planar format as it had all what's needed to decode the data. And the were some H/W limitations on using additional DT. The frame format descriptors might be worth to work on, but this doesn't look like a solution to my problem and it is going to take some time to get it right, as Sakari pointed out. -- Regards, Sylwester -- 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 v4] V4L DT bindings
Hello, I've got a couple of questions regarding lane swapping and polarity inversion. On 2012-08-25 01:27, Guennadi Liakhovetski wrote: Hi all After an initial RFC [1] and taking into consideration an even earlier patch-set [2], Sylwester and I have spent some time discussing V4L DT bindings, below is a result of those discussions. We have chosen to try to design a DT example, documentation and implementation should follow. I'll try to bring together just several most important points, that might not be immediately obvious from the example. 1. Sylwester has initially designed his patches around a concept of a central video node, that contains (references to) all video devices on the system. This might make finding all relevant components easier and should make power management more readily available. In the below example such a node is missing. For now we decided not to require one, but systems may choose to use them. Support for them might be added to the V4L DT subsystem later. 2. The below example contains the following 4 components: (a) an SoC bridge (CEU node ceu0@0xfe91), note, that the bridge is also providing a master clock mclk: master_clock to sensors (b) a CSI-2 interface csi2: csi2@0xffc9, that can be used with the above bridge (c) an I2C parallel camera sensor ov772x_1: ov772x@0x21 (d) an I2C serial (MIPI CSI-2) camera sensor imx074: imx074@0x1a 3. Linking of various components follows the V4L2 MC concept: each video node can contain xxx: videolink@x child nodes. These nodes specify the opposite end of the link and a local pad configuration. This is required, because two linked pads might require different configuration. E.g., if the board contains an inverter in the camera vertical sync line, respective pads have to be configured with opposite vsync polarities. 4. In the below example the following links are defined: (a) ov772x_1_1: videolink@1 is a child of the CEU node, it links the CEU with the ov772x sensor. (b) csi2_0: videolink@0 is also child of the CEU node, it links the CEU with the CSI-2 module. Note, that this link might not be necessary, since this is an SoC internal connection and drivers will know themselves how to configure it (c) ceu0_1: videolink@0 is a chile of the OV772x node (d) csi2_0_1: videolink@0 is a child of the IMX074 camera sensor node (e) imx074_1: videolink@1 is a child of the CSI-2 node (f) ceu0: videolink@0 is a child of the CSI-2 node - also might not be required 5. Remote node references in videolinks are unidirectional. I.e., videolink nodes on downstream devices (e.g., the bridge) reference phandles of upstream nodes (e.g., sensors), but not the other way round. This should be sufficient for the proposed probing method: (a) external subdevices like sensors are children on their respective busses (e.g., I2C) and can be probed before the bridge. In this case probing can fail, because the master clock is not supplied yet. Therefore the sensor driver will have to request deferred probing. (b) the bridge device is probed, the driver instantiates the clock, before returning the driver registers a notifier (in this case on the I2C bus) (c) sensor .probe() is tried again, this time the clock is available, so, this time probing succeeds (d) the bridge driver notifier is called, it scans videolink child nodes, finds a match, gets a link to the subdevice 6. In the below example we are using the reg property to enumerate videolink child nodes. Doubts have been expressed previous in thread [1] about validity of such use. If it's proven, that reg shouldn't be used in this case, a new property shall be introduced. 7. Concerning data lines. We have chosen to use bus-width and data-shift for parallel busses and new properties data-lanes and clock-lanes to describe pin assignment on MIPI CSI-2 devices and additionally a bus-width property per videolink child of CSI-2 controllers to specify how many data lanes are actually used for this link. Any comments welcome. It's been a pleasure working on this together with Sylwester, it is a pity he won't be coming to the KS this time, hopefully, we'll continue this cooperation during upcoming discussion and implementation phases. [1] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/50755 [2] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/11143 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ // Describe an imaginary configuration: a CEU serving either a parallel ov7725 // sensor, or a serial imx074 sensor, connected over a CSI-2 SoC interface // // Any vendor-specific properties here are only provided as examples. The //
Re: [PATCH] [media] atmel_isi: allocate memory to store the isi platform data.
Hello,
On 2012-08-29 12:11, Josh Wu wrote:
This patch fix the bug: ISI driver's platform data became invalid when isi
platform data's attribution is __initdata.
If the isi platform data is passed as __initdata. Then we need store it in
driver allocated memory. otherwise when we use it out of the probe()
function, then the isi platform data is invalid.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/platform/soc_camera/atmel-isi.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index ec3f6a0..dc0fdec 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -926,6 +926,7 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
clk_put(isi-mck);
clk_unprepare(isi-pclk);
clk_put(isi-pclk);
+ kfree(isi-pdata);
Not needed if you use devm_kzalloc(). See below.
kfree(isi);
return 0;
@@ -968,8 +969,15 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
goto err_alloc_isi;
}
+ isi-pdata = kzalloc(sizeof(struct isi_platform_data), GFP_KERNEL);
+ if (!isi-pdata) {
+ ret = -ENOMEM;
+ dev_err(pdev-dev, Can't allocate isi platform data!\n);
+ goto err_alloc_isi_pdata;
+ }
+ memcpy(isi-pdata, pdata, sizeof(struct isi_platform_data));
+
It is more idiomatic to use sizeof(*isi-pdata) in kzalloc() and memcpy() calls
to be resilient to future type changes.
You may also want to use dev_kzalloc() which frees memory automagically on
driver detach.
isi-pclk = pclk;
- isi-pdata = pdata;
isi-active = NULL;
spin_lock_init(isi-lock);
init_waitqueue_head(isi-vsync_wq);
@@ -1073,6 +1081,8 @@ err_set_mck_rate:
err_clk_prepare_mck:
clk_put(isi-mck);
err_clk_get:
+ kfree(isi-pdata);
+err_alloc_isi_pdata:
kfree(isi);
err_alloc_isi:
clk_unprepare(pclk);
Best regards,
Nicolas--
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 RFC 0/4] V4L2: Vendor specific media bus formats/ frame size control
Hello, On 2012-08-23 11:51, Sylwester Nawrocki wrote: This patch series introduces new image source class control - V4L2_CID_FRAMESIZE and vendor or device specific media bus format section. There was already a discussion WRT handling interleaved image data [1]. I'm not terribly happy with those vendor specific media bus formats but I couldn't find better solution that would comply with the V4L2 API concepts and would work reliably. What about Sakari's Frame format descriptors RFC[1] that would allow to describe arbitrary pixel code combinations and provide required information (virtual channel and data type) to the CSI receiver driver for configuring the hardware? Thanks in advance. Best regards, Nicolas [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg43530.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] media: fix MEDIA_IOC_DEVICE_INFO return code
The MEDIA_IOC_DEVICE_INFO ioctl was returning a positive value rather than a negative error code when failing to copy output parameter to user-space. Tested by compilation only. Signed-off-by: Nicolas Thery nicolas.th...@st.com --- drivers/media/media-device.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c index 6f9eb94..d01fcb7 100644 --- a/drivers/media/media-device.c +++ b/drivers/media/media-device.c @@ -59,7 +59,9 @@ static int media_device_get_info(struct media_device *dev, info.hw_revision = dev-hw_revision; info.driver_version = dev-driver_version; - return copy_to_user(__info, info, sizeof(*__info)); + if (copy_to_user(__info, info, sizeof(*__info))) + return -EFAULT; + return 0; } static struct media_entity *find_entity(struct media_device *mdev, u32 id) -- 1.7.11.3 -- 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 for 3.6] videobuf2: fix sparse warning
Fix symbol 'vb2_vmalloc_memops' was not declared. Should it be static?
sparse warning.
Signed-off-by: Nicolas Thery nicolas.th...@st.com
---
drivers/media/video/videobuf2-vmalloc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index 6b5ca6c..94efa04 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -18,6 +18,7 @@
#include linux/vmalloc.h
#include media/videobuf2-core.h
+#include media/videobuf2-vmalloc.h
#include media/videobuf2-memops.h
struct vb2_vmalloc_buf {
--
1.7.11.3
--
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 for 3.6] v4l: fix copy/paste typo in vb2_reqbufs comment
Signed-off-by: Nicolas Thery nicolas.th...@st.com --- diff --git a/drivers/media/video/videobuf2-core.c b/drivers/media/video/videobuf2-core.c index 4e0290a..268c7dd 100644 --- a/drivers/media/video/videobuf2-core.c +++ b/drivers/media/video/videobuf2-core.c @@ -715,8 +715,8 @@ static int __create_bufs(struct vb2_queue *q, struct v4l2_create_buffers *create } /** - * vb2_reqbufs() - Wrapper for __reqbufs() that also verifies the memory and - * type values. + * vb2_create_bufs() - Wrapper for __create_bufs() that also verifies the + * memory and type values. * @q: videobuf2 queue * @create:creation parameters, passed from userspace to vidioc_create_bufs * handler in driver-- 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 for 3.6] v4l: DocBook: VIDIOC_CREATE_BUFS: add hyperlink
Signed-off-by: Nicolas Thery nicolas.th...@st.com --- diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml index 5e73b1c..a8cda1a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml @@ -64,7 +64,7 @@ different sizes./para paraTo allocate device buffers applications initialize relevant fields of the structnamev4l2_create_buffers/structname structure. They set the structfieldtype/structfield field in the -structnamev4l2_format/structname structure, embedded in this +v4l2-format; structure, embedded in this structure, to the respective stream or buffer type. structfieldcount/structfield must be set to the number of required buffers. structfieldmemory/structfield specifies the required I/O method. The @@ -114,7 +114,7 @@ information./para //entry /row row - entrystructnbsp;v4l2_format/entry + entryv4l2-format;/entry entrystructfieldformat/structfield/entry entryFilled in by the application, preserved by the driver./entry /row-- 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 for 3.6] v4l: DocBook: fix version number typo
Signed-off-by: Nicolas Thery nicolas.th...@st.com --- Documentation/DocBook/media/v4l/compat.xml |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 97b8951..e519ce6 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2460,7 +2460,7 @@ that used it. It was originally scheduled for removal in 2.6.35. /section section - titleV4L2 in Linux 3.5/title + titleV4L2 in Linux 3.6/title orderedlist listitem paraReplaced structfieldinput/structfield in -- 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
