Re: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?
2010-12-15 오후 4:57, Hans Verkuil 쓴 글:
On Wednesday, December 15, 2010 01:19:43 Laurent Pinchart wrote:
Hi,
(CC'ing linux-media this time, please discard the previous mail)
On Tuesday 14 December 2010 12:27:32 Kim, HeungJun wrote:
Hi Laurent and Hans,
I am working on V4L2 subdev for M5MOLS by Fujitsu.
and I wanna listen your comments about Auto Focus mode of my ideas.
the details is in the following link discussed at the past.
Although the situation(adding the more various functions at the M5MOLS
or any other MEGA camera sensor, I worked.)is changed,
so I wanna continue this threads for now.
http://www.mail-archive.com/linux-media@vger.kernel.org/msg03543.html
First of all, the at least two more mode of auto-focus exists in the
M5MOLS camera sensor. So, considering defined V4L2 controls and the
controls in the M5MOLS, I suggest like this:
+enum v4l2_focus_auto_type {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_POSITION = 2,
+};
+#define V4L2_CID_FOCUS_POSITION
(V4L2_CID_CAMERA_CLASS_BASE+13)
-#define V4L2_CID_ZOOM_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+13)
-#define V4L2_CID_ZOOM_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+14)
+#define V4L2_CID_ZOOM_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+14)
+#define V4L2_CID_ZOOM_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+15)
The M5MOLS(or other recent camera sensor) can have at least 2 mode although
in any cases : *MACRO* and *NORMAL* mode. plus, M5MOLS supports
positioning focus mode, AKA. POSITION AF mode.
The MACRO mode scan short range, and this mode can be used at the
circumstance in the short distance with object and camera lens. So, It has
fast lens movement, but the command FOCUSING dosen't works well at the
long distance object.
On the other hand, NORMAL mode can this. As the words, It's general and
normal focus mode. The M5MOLS scan fully in the mode.
In the Position AF mode, the position(expressed x,y) is given at the
M5MOLS, and then the M5MOLS focus this area. But, the time given the
position, is normally touch the lcd screen at the mobile device, in my
case. If the time is given from button, it's no big problem *when*. But,
in touch-lcd screen case, the position is read at the touch screen driver,
before command FOCUS to camera sensor. It's the why I add another
CID(V4L2_CID_FOCUS_POSITION).
I'm pretty sure that some devices would require a rectangle instead of
coordinates to define the focus point. Even a rectangle might not be enough.
It would help if we could get feedback from camera designers here.
Hans, should we add a new control type to pass coordinates/rectangles ? :-)
It's a bit tricky actually since QUERYCTRL can return only one set of min/max
values. For coordinates/rectangles we need two sets (horizontal and vertical).
And I think it is important to know the min/max values.
Regards,
Hans
I agree with that.
So, IMHO, my real ideas is that:
1. It aparts two cid for focus POSITIONING.
(e.g., V4L2_CID_FOCUS_POSX, V4L2_CID_FOCUS_POSY. )
2. The min/max is changed, responsible for current camera sensor operating mode
size.
The rectangle case is possible for focus mode. But, It can be dealt with this in
the subdev driver, although the camera sensor support rectangle focus.
Thanks.
Regards,
HeungJun Kim
--
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: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?
Hi Laurent,
2010-12-15 ¿ÀÀü 9:19, Laurent Pinchart ¾´ ±Û:
Hi,
(CC'ing linux-media this time, please discard the previous mail)
On Tuesday 14 December 2010 12:27:32 Kim, HeungJun wrote:
Hi Laurent and Hans,
I am working on V4L2 subdev for M5MOLS by Fujitsu.
and I wanna listen your comments about Auto Focus mode of my ideas.
the details is in the following link discussed at the past.
Although the situation(adding the more various functions at the M5MOLS
or any other MEGA camera sensor, I worked.)is changed,
so I wanna continue this threads for now.
http://www.mail-archive.com/linux-media@vger.kernel.org/msg03543.html
First of all, the at least two more mode of auto-focus exists in the
M5MOLS camera sensor. So, considering defined V4L2 controls and the
controls in the M5MOLS, I suggest like this:
+enum v4l2_focus_auto_type {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_POSITION = 2,
+};
+#define V4L2_CID_FOCUS_POSITION
(V4L2_CID_CAMERA_CLASS_BASE+13)
Something I forgot to mention before: new controls should be added at the
end of the control class. These IDs can be used directly in applications,
so if you shift them, then apps will start to fail.
-#define V4L2_CID_ZOOM_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+13)
-#define V4L2_CID_ZOOM_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+14)
+#define V4L2_CID_ZOOM_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+14)
+#define V4L2_CID_ZOOM_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+15)
The M5MOLS(or other recent camera sensor) can have at least 2 mode
although
in any cases : *MACRO* and *NORMAL* mode. plus, M5MOLS supports
positioning focus mode, AKA. POSITION AF mode.
The MACRO mode scan short range, and this mode can be used at the
circumstance in the short distance with object and camera lens. So, It
has
fast lens movement, but the command FOCUSING dosen't works well at the
long distance object.
On the other hand, NORMAL mode can this. As the words, It's general and
normal focus mode. The M5MOLS scan fully in the mode.
In the Position AF mode, the position(expressed x,y) is given at the
M5MOLS, and then the M5MOLS focus this area. But, the time given the
position, is normally touch the lcd screen at the mobile device, in my
case. If the time is given from button, it's no big problem *when*.
But,
in touch-lcd screen case, the position is read at the touch screen
driver,
before command FOCUS to camera sensor. It's the why I add another
CID(V4L2_CID_FOCUS_POSITION).
I'm pretty sure that some devices would require a rectangle instead of
coordinates to define the focus point. Even a rectangle might not be
enough.
It would help if we could get feedback from camera designers here.
Hans, should we add a new control type to pass coordinates/rectangles ?
:-)
Very glad to be sure that.
As you know, the recent camera sensor embedded in mobile devices has
evoluted
rapidly in a decade. It's not digital camera, but it operates like digital
camera. Actually, the camera sensor module with ISP in the recent mobile
device
use the same one in the digital camera. And I can let you know this newer
control types, like in a uppper FOCUS case.(e.g.,iso, exposure, wb,
wdr(wide
dynamic range), effects, the method to get jpeg bulk streams with sync,
even
face detections.)
So, I'll make general patch or RFC patch about new control types which is
needed at
the the mobile device, based on M5MOLS and some sensors else, for
generality.
(considering another ISP like a NEC, Samsung sensor modules. It is
available for me.)
Good plan.
After that, I'm glad with being reviewed it to Hans and Laurent.
(Actually, I don't know who is the maintainer of CID of camera. Let me
know, plz. :-) )
You have the right people :-)
If Laurent and Hans agree with that, I'll prepare patch works.
Thanks for reading.
ps. I wanna know where the recent v4l2 control is described, as already
told
at the previous my mail.
The latest spec build from the git tree is always available here:
www.xs4all.nl/~hverkuil/spec/media.html
And of course in the media_tree git repository itself.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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 v6 0/7] davinci vpbe: dm6446 v4l2 driver
version6 : addressed Sergei's and Murali's comments on: 1. Fixed Murali's comments on moving README.davinci-vpbe to Documentation directory. 2. Fixed Sergei's comments on indentation. Manjunath Hadli (7): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: platform specific additions davinci vpbe: Build infrastructure for VPBE driver davinci vpbe: Readme text for Dm6446 vpbe Documentation/video4linux/README.davinci-vpbe | 100 ++ arch/arm/mach-davinci/board-dm644x-evm.c | 79 +- arch/arm/mach-davinci/dm644x.c| 164 ++- arch/arm/mach-davinci/include/mach/dm644x.h |4 + drivers/media/video/davinci/Kconfig | 22 + drivers/media/video/davinci/Makefile |2 + drivers/media/video/davinci/vpbe.c| 837 ++ drivers/media/video/davinci/vpbe_display.c| 2099 + drivers/media/video/davinci/vpbe_osd.c| 1211 ++ drivers/media/video/davinci/vpbe_osd_regs.h | 389 + drivers/media/video/davinci/vpbe_venc.c | 574 +++ drivers/media/video/davinci/vpbe_venc_regs.h | 189 +++ include/media/davinci/vpbe.h | 186 +++ include/media/davinci/vpbe_display.h | 146 ++ include/media/davinci/vpbe_osd.h | 397 + include/media/davinci/vpbe_types.h| 93 ++ include/media/davinci/vpbe_venc.h | 38 + 17 files changed, 6511 insertions(+), 19 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.h -- 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 v6 2/7] davinci vpbe: VPBE display driver
This patch implements the coe functionality of the dislay driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the man V4L2 driver.This implements
the cre of each of the V4L2 IOCTLs.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/davinci/vpbe.c | 837
include/media/davinci/vpbe.h | 186
2 files changed, 1023 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe.c
create mode 100644 include/media/davinci/vpbe.h
diff --git a/drivers/media/video/davinci/vpbe.c
b/drivers/media/video/davinci/vpbe.c
new file mode 100644
index 000..751370f
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe.c
@@ -0,0 +1,837 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/wait.h
+#include linux/time.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+#include linux/err.h
+
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe.h
+#include media/davinci/vpss.h
+
+
+#define VPBE_DEFAULT_OUTPUTComposite
+#define VPBE_DEFAULT_MODE ntsc
+
+static char *def_output = VPBE_DEFAULT_OUTPUT;
+static char *def_mode = VPBE_DEFAULT_MODE;
+static struct osd_state *osd_device;
+static struct venc_platform_data *venc_device;
+static int debug;
+
+module_param(def_output, charp, S_IRUGO);
+module_param(def_mode, charp, S_IRUGO);
+module_param(debug, int, 0644);
+
+MODULE_PARM_DESC(def_output, vpbe output name (default:Composite));
+MODULE_PARM_DESC(ef_mode, vpbe output mode name (default:ntsc);
+MODULE_PARM_DESC(debug, Debug level 0-1);
+
+MODULE_DESCRIPTION(TI DMXXX VPBE Display controller);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Texas Instruments);
+
+/**
+ * vpbe_current_encoder_info - Get config info for current encoder
+ * @vpbe_dev - vpbe device ptr
+ *
+ * Return ptr to current encoder config info
+ */
+static struct encoder_config_info*
+vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
+{
+ struct vpbe_display_config *vpbe_config = vpbe_dev-cfg;
+ int index = vpbe_dev-current_sd_index;
+
+ return ((index == 0) ? vpbe_config-venc :
+ vpbe_config-ext_encoders[index-1]);
+}
+
+/**
+ * vpbe_find_encoder_sd_index - Given a name find encoder sd index
+ *
+ * @vpbe_config - ptr to vpbe cfg
+ * @output_index - index used by application
+ *
+ * Return sd index of the encoder
+ */
+static int vpbe_find_encoder_sd_index(struct vpbe_display_config *vpbe_config,
+int index)
+{
+ char *encoder_name = vpbe_config-outputs[index].subdev_name;
+ int i;
+
+ /* Venc is always first */
+ if (!strcmp(encoder_name, vpbe_config-venc.module_name))
+ return 0;
+
+ for (i = 0; i vpbe_config-num_ext_encoders; i++) {
+ if (!strcmp(encoder_name,
+vpbe_config-ext_encoders[i].module_name))
+ return i+1;
+ }
+ return -EINVAL;
+}
+
+/**
+ * vpbe_g_cropcap - Get crop capabilities of the display
+ * @vpbe_dev - vpbe device ptr
+ * @cropcap - cropcap is a ptr to struct v4l2_cropcap
+ *
+ * Update the crop capabilities in crop cap for current
+ * mode
+ */
+static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
+ struct v4l2_cropcap *cropcap)
+{
+ if (NULL == cropcap)
+ return -EINVAL;
+ cropcap-bounds.left = 0;
+ cropcap-bounds.top = 0;
+ cropcap-bounds.width = vpbe_dev-current_timings.xres;
+ cropcap-bounds.height = vpbe_dev-current_timings.yres;
+ cropcap-defrect = cropcap-bounds;
+ return 0;
+}
+
+/**
+ * vpbe_enum_outputs - enumerate outputs
+ * @vpbe_dev - vpbe device ptr
+ * @output - ptr to v4l2_output structure
+ *
+ * Enumerates the outputs available at the vpbe display
+ * returns the status, -EINVAL if end of output list
+ */
+static int vpbe_enum_outputs(struct vpbe_device *vpbe_dev,
+
[PATCH v6 5/7] davinci vpbe: platform specific additions
This patch implements the overall device creation for the Video
display driver, and addition of tables for the mode and output list.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
arch/arm/mach-davinci/board-dm644x-evm.c| 79 +++--
arch/arm/mach-davinci/dm644x.c | 164 ++-
arch/arm/mach-davinci/include/mach/dm644x.h |4 +
3 files changed, 228 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 34c8b41..e9b1243 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -166,18 +166,6 @@ static struct platform_device davinci_evm_nandflash_device
= {
.resource = davinci_evm_nandflash_resource,
};
-static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
-
-static struct platform_device davinci_fb_device = {
- .name = davincifb,
- .id = -1,
- .dev = {
- .dma_mask = davinci_fb_dma_mask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- },
- .num_resources = 0,
-};
-
static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -606,8 +594,71 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
}
+#define VENC_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* venc standards timings */
+static struct vpbe_enc_mode_info vbpe_enc_std_timings[] = {
+ {ntsc, VPBE_ENC_STD, {V4L2_STD_525_60}, 1, 720, 480,
+ {11, 10}, {3, 1001}, 0x79, 0, 0x10, 0, 0, 0, 0},
+ {pal, VPBE_ENC_STD, {V4L2_STD_625_50}, 1, 720, 576,
+ {54, 59}, {25, 1}, 0x7E, 0, 0x16, 0, 0, 0, 0},
+};
+
+/* venc dv preset timings */
+static struct vpbe_enc_mode_info vbpe_enc_preset_timings[] = {
+ {480p59_94, VPBE_ENC_DV_PRESET, {V4L2_DV_480P59_94}, 0, 720, 480,
+ {1, 1}, {5994, 100}, 0x80, 0, 0x20, 0, 0, 0, 0},
+ {576p50, VPBE_ENC_DV_PRESET, {V4L2_DV_576P50}, 0, 720, 576,
+ {1, 1}, {50, 1}, 0x7E, 0, 0x30, 0, 0, 0, 0},
+};
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * the order same as that of encoders. First that from venc followed by that
+ * from encoders. Index in the output refers to index on a particular encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm644x_vpbe_outputs[] = {
+ {
+ .output = {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .std = VENC_STD_ALL,
+ .capabilities = V4L2_OUT_CAP_STD,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = ntsc,
+ .num_modes = ARRAY_SIZE(vbpe_enc_std_timings),
+ .modes = vbpe_enc_std_timings,
+ },
+ {
+ .output = {
+ .index = 1,
+ .name = Component,
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .capabilities = V4L2_OUT_CAP_PRESETS,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = 480p59_94,
+ .num_modes = ARRAY_SIZE(vbpe_enc_preset_timings),
+ .modes = vbpe_enc_preset_timings,
+ },
+};
+
+static struct vpbe_display_config vpbe_display_cfg = {
+ .module_name = dm644x-vpbe-display,
+ .i2c_adapter_id = 1,
+ .osd = {
+ .module_name = VPBE_OSD_SUBDEV_NAME,
+ },
+ .venc = {
+ .module_name = VPBE_VENC_SUBDEV_NAME,
+ },
+ .num_outputs = ARRAY_SIZE(dm644x_vpbe_outputs),
+ .outputs = dm644x_vpbe_outputs,
+};
static struct platform_device *davinci_evm_devices[] __initdata = {
- davinci_fb_device,
rtc_dev,
};
@@ -620,6 +671,8 @@ davinci_evm_map_io(void)
{
/* setup input configuration for VPFE input devices */
dm644x_set_vpfe_config(vpfe_cfg);
+ /* setup configuration for vpbe devices */
+ dm644x_set_vpbe_display_config(vpbe_display_cfg);
dm644x_init();
}
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 5e5b0a7..e8b8e94 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -640,6 +640,142 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
}
+static struct resource dm644x_osd_resources[] = {
+ {
+ .start = 0x01C72600,
+ .end= 0x01C72600 + 0x200,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64
[PATCH v6 4/7] davinci vpbe: VENC( Video Encoder) implementation
This patch adds the VENC or the Video encoder, whichis responsible
for the blending of al source planes and timing generation for Video
modes like NTSC, PAL and other digital outputs. the VENC implementation
currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL
resolutions through the analog DACs. The venc block is implemented
as a subdevice, allowing for additional extenal and internal encoders
of other kind to plug-in.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/davinci/vpbe_venc.c | 574 ++
drivers/media/video/davinci/vpbe_venc_regs.h | 189 +
include/media/davinci/vpbe_venc.h| 38 ++
3 files changed, 801 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe_venc.c
create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
create mode 100644 include/media/davinci/vpbe_venc.h
diff --git a/drivers/media/video/davinci/vpbe_venc.c
b/drivers/media/video/davinci/vpbe_venc.c
new file mode 100644
index 000..fafb41a
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_venc.c
@@ -0,0 +1,574 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/ctype.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+#include linux/slab.h
+
+#include mach/hardware.h
+#include mach/mux.h
+#include mach/io.h
+#include mach/i2c.h
+
+#include linux/io.h
+
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe_venc.h
+#include media/davinci/vpss.h
+#include media/v4l2-device.h
+
+#include vpbe_venc_regs.h
+
+#define MODULE_NAMEVPBE_VENC_SUBDEV_NAME
+
+static int debug = 2;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, Debug level 0-2);
+
+struct venc_state {
+ struct v4l2_subdev sd;
+ struct venc_callback *callback;
+ struct venc_platform_data *pdata;
+ struct device *pdev;
+ u32 output;
+ v4l2_std_id std;
+ spinlock_t lock;
+ void __iomem *venc_base;
+ void __iomem *vdaccfg_reg;
+};
+
+static inline struct venc_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct venc_state, sd);
+}
+
+static inline u32 venc_read(struct v4l2_subdev *sd, u32 offset)
+{
+ struct venc_state *venc = to_state(sd);
+
+ return __raw_readl(venc-venc_base + offset);
+}
+
+static inline u32 venc_write(struct v4l2_subdev *sd, u32 offset, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+ __raw_writel(val, (venc-venc_base + offset));
+ return val;
+}
+
+static inline u32 venc_modify(struct v4l2_subdev *sd, u32 offset,
+u32 val, u32 mask)
+{
+ u32 new_val = (venc_read(sd, offset) ~mask) | (val mask);
+
+ venc_write(sd, offset, new_val);
+ return new_val;
+}
+
+static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+
+ __raw_writel(val, venc-vdaccfg_reg);
+
+ val = __raw_readl(venc-vdaccfg_reg);
+ return val;
+}
+
+/* This function sets the dac of the VPBE for various outputs
+ */
+static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index)
+{
+ int ret = 0;
+
+ switch (out_index) {
+ case 0:
+ v4l2_dbg(debug, 1, sd, Setting output to Composite\n);
+ venc_write(sd, VENC_DACSEL, 0);
+ break;
+ case 1:
+ v4l2_dbg(debug, 1, sd, Setting output to S-Video\n);
+ venc_write(sd, VENC_DACSEL, 0x210);
+ break;
+ case 2:
+ venc_write(sd, VENC_DACSEL, 0x543);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
+static void enabledigitaloutput(struct v4l2_subdev *sd, int benable)
+{
+ v4l2_dbg(debug, 2, sd, enabledigitaloutput\n);
+
+ if (benable) {
+ venc_write(sd, VENC_VMOD, 0);
+ venc_write(sd, VENC_CVBS, 0);
+ venc_write(sd,
[PATCH v6 6/7] davinci vpbe: Build infrastructure for VPBE driver
This patch adds the build infra-structure for Davinci VPBE dislay driver Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Muralidharan Karicheri m-kariche...@ti.com Acked-by: Hans Verkuil hverk...@xs4all.nl --- drivers/media/video/davinci/Kconfig | 22 ++ drivers/media/video/davinci/Makefile |2 ++ 2 files changed, 24 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..a7f11e7 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -91,3 +91,25 @@ config VIDEO_ISIF To compile this driver as a module, choose M here: the module will be called vpfe. + +config VIDEO_DM644X_VPBE + tristate DM644X VPBE HW module + select VIDEO_VPSS_SYSTEM + select VIDEOBUF_DMA_CONTIG + help + Enables VPBE modules used for display on a DM644x + SoC. + + To compile this driver as a module, choose M here: the + module will be called vpbe. + + +config VIDEO_VPBE_DISPLAY + tristate VPBE V4L2 Display driver + select VIDEO_DM644X_VPBE + default y + help + Enables VPBE V4L2 Display driver on a DMXXX device + + To compile this driver as a module, choose M here: the + module will be called vpbe_display. diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index a379557..ae7dafb 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -16,3 +16,5 @@ obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o obj-$(CONFIG_VIDEO_ISIF) += isif.o +obj-$(CONFIG_VIDEO_DM644X_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o +obj-$(CONFIG_VIDEO_VPBE_DISPLAY) += vpbe_display.o -- 1.6.2.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 5/7] davinci vpbe: platform specific additions KHilman
This patch implements the overall device creation for the Video
display driver, and addition of tables for the mode and output list.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
arch/arm/mach-davinci/board-dm644x-evm.c| 79 +++--
arch/arm/mach-davinci/dm644x.c | 165 +-
arch/arm/mach-davinci/include/mach/dm644x.h |4 +
3 files changed, 228 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 0ca90b8..81d52c1 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -176,18 +176,6 @@ static struct platform_device davinci_evm_nandflash_device
= {
.resource = davinci_evm_nandflash_resource,
};
-static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
-
-static struct platform_device davinci_fb_device = {
- .name = davincifb,
- .id = -1,
- .dev = {
- .dma_mask = davinci_fb_dma_mask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- },
- .num_resources = 0,
-};
-
static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -616,8 +604,71 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
}
+#define VENC_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* venc standards timings */
+static struct vpbe_enc_mode_info vbpe_enc_std_timings[] = {
+ {ntsc, VPBE_ENC_STD, {V4L2_STD_525_60}, 1, 720, 480,
+ {11, 10}, {3, 1001}, 0x79, 0, 0x10, 0, 0, 0, 0},
+ {pal, VPBE_ENC_STD, {V4L2_STD_625_50}, 1, 720, 576,
+ {54, 59}, {25, 1}, 0x7E, 0, 0x16, 0, 0, 0, 0},
+};
+
+/* venc dv preset timings */
+static struct vpbe_enc_mode_info vbpe_enc_preset_timings[] = {
+ {480p59_94, VPBE_ENC_DV_PRESET, {V4L2_DV_480P59_94}, 0, 720, 480,
+ {1, 1}, {5994, 100}, 0x80, 0, 0x20, 0, 0, 0, 0},
+ {576p50, VPBE_ENC_DV_PRESET, {V4L2_DV_576P50}, 0, 720, 576,
+ {1, 1}, {50, 1}, 0x7E, 0, 0x30, 0, 0, 0, 0},
+};
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * the order same as that of encoders. First that from venc followed by that
+ * from encoders. Index in the output refers to index on a particular encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm644x_vpbe_outputs[] = {
+ {
+ .output = {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .std = VENC_STD_ALL,
+ .capabilities = V4L2_OUT_CAP_STD,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = ntsc,
+ .num_modes = ARRAY_SIZE(vbpe_enc_std_timings),
+ .modes = vbpe_enc_std_timings,
+ },
+ {
+ .output = {
+ .index = 1,
+ .name = Component,
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .capabilities = V4L2_OUT_CAP_PRESETS,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = 480p59_94,
+ .num_modes = ARRAY_SIZE(vbpe_enc_preset_timings),
+ .modes = vbpe_enc_preset_timings,
+ },
+};
+
+static struct vpbe_display_config vpbe_display_cfg = {
+ .module_name = dm644x-vpbe-display,
+ .i2c_adapter_id = 1,
+ .osd = {
+ .module_name = VPBE_OSD_SUBDEV_NAME,
+ },
+ .venc = {
+ .module_name = VPBE_VENC_SUBDEV_NAME,
+ },
+ .num_outputs = ARRAY_SIZE(dm644x_vpbe_outputs),
+ .outputs = dm644x_vpbe_outputs,
+};
static struct platform_device *davinci_evm_devices[] __initdata = {
- davinci_fb_device,
rtc_dev,
};
@@ -630,6 +681,8 @@ davinci_evm_map_io(void)
{
/* setup input configuration for VPFE input devices */
dm644x_set_vpfe_config(vpfe_cfg);
+ /* setup configuration for vpbe devices */
+ dm644x_set_vpbe_display_config(vpbe_display_cfg);
dm644x_init();
}
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..9db2b53 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -654,8 +654,165 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
}
+static struct resource dm644x_osd_resources[] = {
+ {
+ .start = 0x01C72600,
+ .end= 0x01C72600 + 0x200,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64
technisat cablestar hd2, cinergy C pci hd, 2.6.35, no remote (VP2040)
This is with reference to: http://www.spinics.net/lists/linux-media/msg15042.html It looks to me that the IR interface related stuff is not in the 2.6.35 kernel either. Since I need it for a set-top box that I building, I was looking for the canonical source for that code so that I can package it separately. Till now I have only found the bits in Igor's s2-liplianin tree. However it looks to me that the code did not originate there because the RC keymap file (linux/drivers/media/IR/keymaps/rc-vp2040.c) was created by a commit marked merge http://linuxtv.org/hg/v4l-dvb; (hg export 15052). I am confused because the v4l-dvb tree does not have the VP2040 IR bits, and my limited knowledge of Mercurial is hindering me from figuring out the origins of the code. Could you kindly point me to the correct direction? Thanks, Debarshi -- The camera is to the brush what Java is to assembly. -- Sougata Santra -- 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 v2] [media] s5p-fimc: fix the value of YUV422 1-plane formats
Hi HyunWoong,
thanks for the patch.
On 12/15/2010 03:18 AM, Hyunwoong Kim wrote:
Some color formats are mismatched in s5p-fimc driver.
CICICTRL[1:0], order422_out, should be set 2b'00 not 2b'11
Should be CIOCTRL instead of CICICTRL.
to use V4L2_PIX_FMT_YUYV. Because in V4L2 standard V4L2_PIX_FMT_YUYV means
start + 0: Y'00 Cb00 Y'01 Cr00 Y'02 Cb01 Y'03 Cr01. According to datasheet
2b'00 is right value for V4L2_PIX_FMT_YUYV.
-
bit |MSBLSB
-
00 | Cr1Y3Cb1Y2Cr0Y1Cb0Y0
-
01 | Cb1Y3Cr1Y2Cb0Y1Cr0Y0
-
10 | Y3Cr1Y2Cb1Y1Cr0Y0Cb0
-
11 | Y3Cb1Y2Cr1Y1Cb0Y0Cr0
-
V4L2_PIX_FMT_YVYU, V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_VYUY are also mismatched
with datasheet. MSCTRL[17:16], order2p_in, is also mismatched
in V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YVYU.
Signed-off-by: Hyunwoong Kim khw0178@samsung.com
Reviewed-by: Jonghun han jonghun@samsung.com
---
Changes since V1:
=
- make corrections directly in function fimc_set_yuv_order
commented by Sylwester Nawrocki.
- remove S5P_FIMC_IN_* and S5P_FIMC_OUT_* definitions from fimc-core.h
drivers/media/video/s5p-fimc/fimc-core.c | 16
drivers/media/video/s5p-fimc/fimc-core.h | 12
2 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 7f56987..71e1536 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -448,34 +448,34 @@ static void fimc_set_yuv_order(struct fimc_ctx *ctx)
/* Set order for 1 plane input formats. */
switch (ctx-s_frame.fmt-color) {
case S5P_FIMC_YCRYCB422:
- ctx-in_order_1p = S5P_FIMC_IN_YCRYCB;
+ ctx-in_order_1p = S5P_MSCTRL_ORDER422_YCRYCB;
break;
case S5P_FIMC_CBYCRY422:
- ctx-in_order_1p = S5P_FIMC_IN_CBYCRY;
+ ctx-in_order_1p = S5P_MSCTRL_ORDER422_CBYCRY;
break;
case S5P_FIMC_CRYCBY422:
- ctx-in_order_1p = S5P_FIMC_IN_CRYCBY;
+ ctx-in_order_1p = S5P_MSCTRL_ORDER422_CRYCBY;
break;
case S5P_FIMC_YCBYCR422:
default:
- ctx-in_order_1p = S5P_FIMC_IN_YCBYCR;
+ ctx-in_order_1p = S5P_MSCTRL_ORDER422_YCBYCR;
break;
}
dbg(ctx-in_order_1p= %d, ctx-in_order_1p);
switch (ctx-d_frame.fmt-color) {
case S5P_FIMC_YCRYCB422:
- ctx-out_order_1p = S5P_FIMC_OUT_YCRYCB;
+ ctx-out_order_1p = S5P_CIOCTRL_ORDER422_YCRYCB;
break;
case S5P_FIMC_CBYCRY422:
- ctx-out_order_1p = S5P_FIMC_OUT_CBYCRY;
+ ctx-out_order_1p = S5P_CIOCTRL_ORDER422_CBYCRY;
break;
case S5P_FIMC_CRYCBY422:
- ctx-out_order_1p = S5P_FIMC_OUT_CRYCBY;
+ ctx-out_order_1p = S5P_CIOCTRL_ORDER422_YCBYCR;
We could avoid a bit confusing assignment:
S5P_FIMC_CRYCBY422 - S5P_CIOCTRL_ORDER422_YCBYCR
break;
case S5P_FIMC_YCBYCR422:
default:
- ctx-out_order_1p = S5P_FIMC_OUT_YCBYCR;
+ ctx-out_order_1p = S5P_CIOCTRL_ORDER422_CRYCBY;
...and S5P_FIMC_YCBYCR422 - S5P_CIOCTRL_ORDER422_CRYCBY
by a correction in file regs-fimc.h. No we have:
#define S5P_CIOCTRL_ORDER422_CRYCBY (0 0)
#define S5P_CIOCTRL_ORDER422_YCRYCB (1 0)
#define S5P_CIOCTRL_ORDER422_CBYCRY (2 0)
#define S5P_CIOCTRL_ORDER422_YCBYCR (3 0)
and it should be:
#define S5P_CIOCTRL_ORDER422_CRYCBY (0 0)
#define S5P_CIOCTRL_ORDER422_CBYCRY (1 0)
#define S5P_CIOCTRL_ORDER422_YCRYCB (2 0)
#define S5P_CIOCTRL_ORDER422_YCBYCR (3 0)
I think this is where the root cause is. Can you please make a change
in regs-fimc.h and modify the above case lines I have commented?
I hope this time we get it all right. Sorry for troubling.
Regards,
Sylwester
break;
}
dbg(ctx-out_order_1p= %d, ctx-out_order_1p);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 4efc1a1..92cca62 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -95,18 +95,6 @@ enum fimc_color_fmt {
#define fimc_fmt_is_rgb(x) ((x) 0x10)
-/* Y/Cb/Cr components order at DMA output for 1 plane YCbCr 4:2:2 formats. */
-#define S5P_FIMC_OUT_CRYCBY S5P_CIOCTRL_ORDER422_YCBYCR
-#define
Re: [PATCH] v4l: OMAP3 ISP CCDC: Add support for 8bit greyscale sensors
On Wed, Dec 15, 2010 at 02:01:31AM +0100, Laurent Pinchart wrote: Hi Martin, Thanks for the patch. On Tuesday 14 December 2010 15:43:43 Martin Hostettler wrote: Adds support for V4L2_MBUS_FMT_Y8_1X8 format and 8bit data width in syncronous interface. [...] I got a similar patch for 12bit support. I'll try to push a new version of the ISP driver with that patch included in the next few days (it needs to go through internal review first), could you then rebase your patch on top of it ? The core infrastructure will be set up, you will just have to add 8-bit support. Will do, i'll have a look at it when the new version is out. - Martin Hostettler -- 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: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?
Hi Hans,
On Wednesday 15 December 2010 08:57:29 Hans Verkuil wrote:
On Wednesday, December 15, 2010 01:19:43 Laurent Pinchart wrote:
On Tuesday 14 December 2010 12:27:32 Kim, HeungJun wrote:
Hi Laurent and Hans,
I am working on V4L2 subdev for M5MOLS by Fujitsu.
and I wanna listen your comments about Auto Focus mode of my ideas.
the details is in the following link discussed at the past.
Although the situation(adding the more various functions at the
M5MOLS
or any other MEGA camera sensor, I worked.)is changed,
so I wanna continue this threads for now.
http://www.mail-archive.com/linux-media@vger.kernel.org/msg03543.html
First of all, the at least two more mode of auto-focus exists in the
M5MOLS camera sensor. So, considering defined V4L2 controls and the
controls in the M5MOLS, I suggest like this:
+enum v4l2_focus_auto_type {
+V4L2_FOCUS_AUTO_NORMAL = 0,
+V4L2_FOCUS_AUTO_MACRO = 1,
+V4L2_FOCUS_AUTO_POSITION = 2,
+};
+#define V4L2_CID_FOCUS_POSITION
(V4L2_CID_CAMERA_CLASS_BASE+13)
-#define V4L2_CID_ZOOM_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+13)
-#define V4L2_CID_ZOOM_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+14)
+#define V4L2_CID_ZOOM_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+14)
+#define V4L2_CID_ZOOM_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+15)
The M5MOLS(or other recent camera sensor) can have at least 2 mode
although in any cases : *MACRO* and *NORMAL* mode. plus, M5MOLS
supports positioning focus mode, AKA. POSITION AF mode.
The MACRO mode scan short range, and this mode can be used at the
circumstance in the short distance with object and camera lens. So,
It
has fast lens movement, but the command FOCUSING dosen't works well
at
the long distance object.
On the other hand, NORMAL mode can this. As the words, It's general
and
normal focus mode. The M5MOLS scan fully in the mode.
In the Position AF mode, the position(expressed x,y) is given at the
M5MOLS, and then the M5MOLS focus this area. But, the time given the
position, is normally touch the lcd screen at the mobile device, in
my
case. If the time is given from button, it's no big problem *when*.
But, in touch-lcd screen case, the position is read at the touch
screen driver, before command FOCUS to camera sensor. It's the why I
add another CID(V4L2_CID_FOCUS_POSITION).
I'm pretty sure that some devices would require a rectangle instead of
coordinates to define the focus point. Even a rectangle might not be
enough. It would help if we could get feedback from camera designers
here.
Hans, should we add a new control type to pass coordinates/rectangles
?
:-)
It's a bit tricky actually since QUERYCTRL can return only one set of
min/max values. For coordinates/rectangles we need two sets (horizontal
and vertical).
And I think it is important to know the min/max values.
Hence my question, should we add a way to pass rectangles (basically a
struct
v4l2_rect) through the control ioctls ? It would make sense.
I thought it over and came to the conclusion that we should not do that.
Instead we can create four separate controls.
The problem we run into when adding more complex types is that we can no
longer communicate min and max values (something that we definitely want
when dealing with coordinates).
Another reason is how the control mechanism is designed: they only support
the basic types (int, bool, string, enum, int64 and a 'button' aka
action). And the controls are grouped into classes which are named through
the 'ctrl_class' control.
So effectively controls represent a field in a class (or struct) and each
class can be presented as a tab page in a control panel.
Simple and straightforward.
If we start to add complex types, then it becomes really hard to define
the meta data of the control since you are really defining a 'mini-class'.
It sounds nice initially, but we really should not do this since I believe
it will lead to chaos later on. You want complex types, then use ioctls,
not controls. Or split up the complex type into multiple simple types.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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: technisat cablestar hd2, cinergy C pci hd, 2.6.35, no remote (VP2040)
AFAIR, the code originated from these changesets: http://jusst.de/hg/mantis-v4l-dvb.old/rev/9cb8ffc573a2 http://jusst.de/hg/mantis-v4l-dvb.old/rev/c2391fa88112 later on, it was moved to another repository http://jusst.de/hg/mantis-v4l-dvb/rev/ad8b00c9edc2 But the code in Igor's s2-liplianin tree has evolved further than the one in the mantis-v4l-dvb tree. eg., the keymaps are now split into separate files in drivers/media/IR/keymaps. Is there any Git tree with the latest state of the code or is the s2-liplianin tree the one I am looking for? Thanks, Debarshi -- The camera is to the brush what Java is to assembly. -- Sougata Santra -- 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 v6 5/7] davinci vpbe: platform specific additions
Hello. On 15-12-2010 12:11, Manjunath Hadli wrote: This patch implements the overall device creation for the Video display driver, and addition of tables for the mode and output list. Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com Acked-by: Muralidharan Karicherim-kariche...@ti.com Acked-by: Hans Verkuilhverk...@xs4all.nl [...] diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 34c8b41..e9b1243 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c I think the DM644x EVM board changes should be in a separate patch. WBR, Sergei -- 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: technisat cablestar hd2, cinergy C pci hd, 2.6.35, no remote (VP2040)
On Wed, Dec 15, 2010 at 4:15 PM, Debarshi Ray debarshi@gmail.com wrote: AFAIR, the code originated from these changesets: http://jusst.de/hg/mantis-v4l-dvb.old/rev/9cb8ffc573a2 http://jusst.de/hg/mantis-v4l-dvb.old/rev/c2391fa88112 later on, it was moved to another repository http://jusst.de/hg/mantis-v4l-dvb/rev/ad8b00c9edc2 But the code in Igor's s2-liplianin tree has evolved further than the one in the mantis-v4l-dvb tree. eg., the keymaps are now split into separate files in drivers/media/IR/keymaps. Is there any Git tree with the latest state of the code or is the s2-liplianin tree the one I am looking for? The latest changes are in here http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/ the IR related changes are not yet there, after the IR rework. Regards, Manu -- 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: budget_av and high load
On Fri, Dec 10, 2010 at 01:15:14PM +0100, Schubert Andreas wrote: Hello everybody on the list, I have a KNC-1 DVB-S card running under kernel 2.6.36 and mythtv. I experience high load values in top like mentioned ages ago in this thread: http://www.linuxtv.org/pipermail/linux-dvb/2008-June/026509.html. My card has no CI-Module installed and the high load was CI-Module related, so I decided to give it a try and completely disable ciintf_init() in the kernel module which helped a lot. Load decreased by 50-80%. So I decided to add a module parameter to disable ciintf_init() on demand. Here is the diff: 65,69d64 int budget_init_ci=1; module_param_named(init_ci, budget_init_ci, int, 0644); MODULE_PARM_DESC(init_ci, Turn on(1)/off(0) ci initializing (default:on).); 1519,1520c1514 if (budget_init_ci) ciintf_init(budget_av); --- ciintf_init(budget_av); I don't know if this is useful at all so please be patient with me. It's useful as bug report. I don't think the module parameter makes sense we should simply fix the bug. I'll look if I can reproduce this with one of my budget_av DVB-C cards. Janne -- 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: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
On 13 December 2010 16:29, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Dec 13, 2010 at 03:52:20PM +, Catalin Marinas wrote:
On 10 December 2010 17:03, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
void __init omap1_camera_init(void *info)
{
struct platform_device *dev = omap1_camera_device;
+ dma_addr_t paddr = omap1_camera_phys_mempool_base;
+ dma_addr_t size = omap1_camera_phys_mempool_size;
int ret;
dev-dev.platform_data = info;
+ if (paddr) {
+ if (dma_declare_coherent_memory(dev-dev, paddr, paddr,
size,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))
Although this works, you're ending up with SDRAM being mapped via
ioremap, which uses MT_DEVICE - so what is SDRAM ends up being
mapped as if it were a device.
BTW, does the generic dma_declare_coherent_memory() does the correct
thing in using ioremap()?
I argue it doesn't, as I said above. It means we map SDRAM as device
memory, and as I understand the way interconnects work, it's entirely
possible that this may not result in the SDRAM being accessible.
[...]
So, not only does this fail the kernel's own rules, but as we already know,
it fails the architecture's restrictions with multiple mappings of memory
when used with SDRAM, and it also maps main memory as a device. I wonder
how many more things this broken API needs to do wrong before it's current
implementation is consigned to the circular filing cabinet.
Should we not try to fix the generic code and still allow platforms to
use dma_declare_coherent_memory() in a safer way? I guess it may need
some arguing/explanation on linux-arch.
--
Catalin
--
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 v6 7/7] davinci vpbe: Readme text for Dm6446 vpbe
Manju, Could you review the Document? I think it is not updated to reflect the latest status: + Current status:- + + A build tested version of vpbe controller is available. I guess you have already tested this using the v4l2 driver. + v4l2 driver +- A version is already developed which is to be cleaned up and unit tested Ditto. v4l2 driver is already tested, right? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Manjunath Hadli Sent: Wednesday, December 15, 2010 4:12 AM To: LMML Cc: dlos; Mauro Carvalho Chehab; Hans Verkuil; Hadli, Manjunath Subject: [PATCH v6 7/7] davinci vpbe: Readme text for Dm6446 vpbe Please refer to this file for detailed documentation of davinci vpbe v4l2 driver Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Muralidharan Karicheri m-kariche...@ti.com Acked-by: Hans Verkuil hverk...@xs4all.nl --- Documentation/video4linux/README.davinci-vpbe | 100 + 1 files changed, 100 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe diff --git a/Documentation/video4linux/README.davinci-vpbe b/Documentation/video4linux/README.davinci-vpbe new file mode 100644 index 000..3ff2dc3 --- /dev/null +++ b/Documentation/video4linux/README.davinci-vpbe @@ -0,0 +1,100 @@ + +VPBE V4L2 driver design + == + + File partitioning + - + V4L2 display device driver + drivers/media/video/davinci/vpbe_display.c + drivers/media/video/davinci/vpbe_display.h + + VPBE display controller + drivers/media/video/davinci/vpbe.c + drivers/media/video/davinci/vpbe.h + + VPBE venc sub device driver + drivers/media/video/davinci/vpbe_venc.c + drivers/media/video/davinci/vpbe_venc.h + drivers/media/video/davinci/vpbe_venc_regs.h + + VPBE osd driver + drivers/media/video/davinci/vpbe_osd.c + drivers/media/video/davinci/vpbe_osd.h + drivers/media/video/davinci/vpbe_osd_regs.h + + Functional partitioning + --- + + Consists of the following (in the same order as the list under file + partitioning):- + + 1. V4L2 display driver +Implements video2 and video3 device nodes and +provides v4l2 device interface to manage VID0 and VID1 layers. + + 2. Display controller +Loads up venc, osd and external encoders such as ths8200. It provides +a set of API calls to V4L2 drivers to set the output/standards +in the venc or external sub devices. It also provides +a device object to access the services from osd sub device +using sub device ops. The connection of external encoders to venc LCD +controller port is done at init time based on default output and standard +selection or at run time when application change the output through +V4L2 IOCTLs. + +When connetected to an external encoder, vpbe controller is also responsible +for setting up the interface between venc and external encoders based on +board specific settings (specified in board-xxx-evm.c). This allows +interfacing external encoders such as ths8200. The setup_if_config() +is implemented for this as well as configure_venc() (part of the next patch) +API to set timings in venc for a specific display resolution. As of this +patch series, the interconnection and enabling ans setting of the external +encoders is not present, and would be a part of the next patch series. + + 3. Venc subdevice +Responsible for setting outputs provided through internal dacs and also +setting timings at LCD controller port when external encoders are connected +at the port or LCD panel timings required. When external encoder/LCD panel +is connected, the timings for a specific standard/preset is retrieved from +the board specific table and the values are used to set the timings in +venc using non-standard timing mode. + +Support LCD Panel displays using the venc. For example to support a Logic +PD display, it requires setting up the LCD controller port with a set of +timings for the resolution supported and setting the dot clock. So we could +add the available outputs as a board specific entry (i.e add the LogicPD +output name to board-xxx-evm.c). A table of timings for various LCDs +supported can be maintained in the board specific setup file to support +various LCD displays. + + 4. osd subdevice +Osd subdevice implements all osd layer management and hardware specific +features. In the legacfy drivers (LSPxxx), the hardware specific features +are configured through proprietary IOCTLs at the fb device interface. Since +subdevices are going to support device nodes, application will be able +to configure the hardware
Re: tm6000 and IR
Am 15.12.2010 08:46, schrieb Dmitri Belimov: Hi Stefan Am 14.12.2010 04:23, schrieb Dmitri Belimov: Hi What about my last patch?? This is OK or bad? Our customers kick me every day with IR remotes. With my best regards, Dmitry. I think, you use the second variant, Dmitry. Why you doesn't use this key map - RCMAP_BEHOLD. No this remotes is different. RCMAP_BEHOLD has more buttons and some other scancodes. People from linux community who was made this keymap and function for reading data from IR decoder has error with scancode. Our true address of scancode is 0x86 0x6B They wrote 0x6B 0x86 Need fix some code of the saa7134-input and RCMAP_BEHOLD keytable. RCMAP_BEHOLD_WANDER same as RCMAP_BEHOLD_COLUMBUS but from IR decoder the saa7134 received only one byte of scancode. Need rework saa7134-input too for get address and restore full scancodes for extended NEC full scancodes. I'll make it after some time. The power led we can change to a separate function, right. Ok The nec initiation looks right and must adding code for tm5600/6000 (going over message pipe). I haven't USB stick with tm5600/6000 for test. Need people with this TV cards. then add a todo line. rc5 need some code for tm6010 (for tm5600/6000 are the hack). I didn't touch this code because I haven't RC5 remotes and tm5600/6000 And the logic for your remote control is unused for the second variant, but ir-rc_type = rc_type are o.k. but the line ir-rc_type = rc_type; are o.k. I think your mean is wrong. Our IR remotes send extended NEC it is 4 bytes. We removed inverted 4 byte and now we have 3 bytes from remotes. I think we must have full RCMAP with this 3 bytes from remotes. And use this remotes with some different IR recievers like some TV cards and LIRC-hardware and other. No need different RCMAP for the same remotes to different IR recievers like now. Your change doesn't work with my terratec remote control !! If we use second variant I can't use RCMAP_BEHOLD because it has full 3 bytes scancodes. As you wrote. And if you use two bytes rc map table. We have add filter for address and commands to pass all. With an external tool can change the map ( ir_keytable). Why you will use more than two bytes. Then the function call usb_set_interface in tm6000_video, can write for example: stop_ir_pipe usb_set_interface start_ir_pipe Ok, I'll try. I will adding vbi_buffer and device in the next, and isoc calculating without video_buffer size. I try add radio. With my best regards, Dmitry. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 5/7] davinci vpbe: platform specific additions
Sergei, I think the DM644x EVM board changes should be in a separate patch. Any reason? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sergei Shtylyov Sent: Wednesday, December 15, 2010 6:20 AM To: Hadli, Manjunath Cc: dlos; Mauro Carvalho Chehab; LMML Subject: Re: [PATCH v6 5/7] davinci vpbe: platform specific additions Hello. On 15-12-2010 12:11, Manjunath Hadli wrote: This patch implements the overall device creation for the Video display driver, and addition of tables for the mode and output list. Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com Acked-by: Muralidharan Karicherim-kariche...@ti.com Acked-by: Hans Verkuilhverk...@xs4all.nl [...] diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach- davinci/board-dm644x-evm.c index 34c8b41..e9b1243 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c I think the DM644x EVM board changes should be in a separate patch. WBR, Sergei ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- 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
Question about libv4lconvert.
Hi,
I am taking a look at libv4lconvert, and I have a question about the
logic in v4lconvert_convert_pixfmt(), in some conversion switches there
is code like this:
case V4L2_PIX_FMT_GREY:
switch (dest_pix_fmt) {
case V4L2_PIX_FMT_RGB24:
case V4L2_PIX_FMT_BGR24:
v4lconvert_grey_to_rgb24(src, dest, width, height);
break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
v4lconvert_grey_to_yuv420(src, dest, fmt);
break;
}
if (src_size (width * height)) {
V4LCONVERT_ERR(short grey data frame\n);
errno = EPIPE;
result = -1;
}
break;
However the conversion routines which are going to be called seem to
assume that the buffers, in particular the source buffer, are of the
correct full frame size when looping over them.
My question is: shouldn't the size check now at the end of the case
block be at the _beginning_ of it instead, so to detect a short frame
before conversion and avoid a possible out of bound access inside the
conversion routine?
Some patches to show what I am saying:
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index 26a0978..46e6500 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -854,7 +854,7 @@ static int v4lconvert_convert_pixfmt(struct v4lconvert_data
*data,
if (src_size (width * height)) {
V4LCONVERT_ERR(short grey data frame\n);
errno = EPIPE;
- result = -1;
+ return -1;
}
break;
case V4L2_PIX_FMT_RGB565:
And:
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index 46e6500..a1a4858 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -841,6 +841,11 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
break;
case V4L2_PIX_FMT_GREY:
+ if (src_size (width * height)) {
+ V4LCONVERT_ERR(short grey data frame\n);
+ errno = EPIPE;
+ return -1;
+ }
switch (dest_pix_fmt) {
case V4L2_PIX_FMT_RGB24:
case V4L2_PIX_FMT_BGR24:
@@ -851,11 +856,6 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
v4lconvert_grey_to_yuv420(src, dest, fmt);
break;
}
- if (src_size (width * height)) {
- V4LCONVERT_ERR(short grey data frame\n);
- errno = EPIPE;
- return -1;
- }
break;
case V4L2_PIX_FMT_RGB565:
switch (dest_pix_fmt) {
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
pgpQd3nhxFG9M.pgp
Description: PGP signature
Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
On Wed, Dec 15, 2010 at 12:39:20PM +, Catalin Marinas wrote:
On 13 December 2010 16:29, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Dec 13, 2010 at 03:52:20PM +, Catalin Marinas wrote:
On 10 December 2010 17:03, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
void __init omap1_camera_init(void *info)
{
struct platform_device *dev = omap1_camera_device;
+ dma_addr_t paddr = omap1_camera_phys_mempool_base;
+ dma_addr_t size = omap1_camera_phys_mempool_size;
int ret;
dev-dev.platform_data = info;
+ if (paddr) {
+ if (dma_declare_coherent_memory(dev-dev, paddr, paddr,
size,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))
Although this works, you're ending up with SDRAM being mapped via
ioremap, which uses MT_DEVICE - so what is SDRAM ends up being
mapped as if it were a device.
BTW, does the generic dma_declare_coherent_memory() does the correct
thing in using ioremap()?
I argue it doesn't, as I said above. It means we map SDRAM as device
memory, and as I understand the way interconnects work, it's entirely
possible that this may not result in the SDRAM being accessible.
[...]
So, not only does this fail the kernel's own rules, but as we already know,
it fails the architecture's restrictions with multiple mappings of memory
when used with SDRAM, and it also maps main memory as a device. I wonder
how many more things this broken API needs to do wrong before it's current
implementation is consigned to the circular filing cabinet.
Should we not try to fix the generic code and still allow platforms to
use dma_declare_coherent_memory() in a safer way? I guess it may need
some arguing/explanation on linux-arch.
I think so - one of the issues with dma_declare_coherent_memory() is that
it's original intention (as I understand it) was to allow drivers to use
on-device dma coherent memory.
Eg, a network controller with its own local SRAM which it can fetch DMA
descriptors from, which tells it where in the bus address space to fetch
packets from. This SRAM is not part of the hosts memory, but is on the
peripheral's bus, and so ioremap() (or maybe ioremap_wc()) would be
appropriate for it.
However, ioremap() on system RAM (even that which has been taken out on
the memory map) may be problematical.
I think the correct solution would be to revise the interface so it takes
a void * pointer, which can be handed out by dma_alloc_coherent() directly
without the API having to worry about how to map the memory. IOW, push
the mapping of that memory up a level to the caller of
dma_declare_coherent_memory().
We can then sanely do preallocations via dma_coherent_alloc() and caching
them back into dma_declare_coherent_memory() without creating additional
mappings which cause architectural violations.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Dec 15 19:00:20 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK 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
Re: [PATCH] bttv: fix mutex use before init
On Tuesday 14 December 2010, Brandon Philips wrote:
On 17:13 Sun 12 Dec 2010, Torsten Kaiser wrote:
* change fh-cap.vb_lock in bttv_open() AND radio_open() to
btv-init.cap.vb_lock
* add a mutex_init(btv-init.cap.vb_lock) to the setup of init in
bttv_probe()
That seems like a reasonable suggestion. An openSUSE user submitted this
bug to our tracker too. Here is the patch I am having him test.
Would you mind testing it?
From 456dc0ce36db523c4c0c8a269f4eec43a72de1dc Mon Sep 17 00:00:00 2001
From: Brandon Philips bphil...@suse.de
Date: Mon, 13 Dec 2010 16:21:55 -0800
Subject: [PATCH] bttv: fix locking for btv-init
Fix locking for the btv-init by using btv-init.cap.vb_lock and in the
process fix uninitialized deref introduced in c37db91fd0d.
Signed-off-by: Brandon Philips bphil...@suse.de
---
drivers/media/video/bt8xx/bttv-driver.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c index a529619..e656424 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -2391,16 +2391,11 @@ static int setup_window_lock(struct bttv_fh *fh,
struct bttv *btv, fh-ov.field= win-field;
fh-ov.setup_ok = 1;
- /*
- * FIXME: btv is protected by btv-lock mutex, while btv-init
- *is protected by fh-cap.vb_lock. This seems to open the
- *possibility for some race situations. Maybe the better would
- *be to unify those locks or to use another way to store the
- *init values that will be consumed by videobuf callbacks
- */
+ mutex_lock(btv-init.cap.vb_lock);
btv-init.ov.w.width = win-w.width;
btv-init.ov.w.height = win-w.height;
btv-init.ov.field = win-field;
+ mutex_unlock(btv-init.cap.vb_lock);
/* update overlay if needed */
retval = 0;
@@ -2620,9 +2615,11 @@ static int bttv_s_fmt_vid_cap(struct file *file,
void *priv, fh-cap.last = V4L2_FIELD_NONE;
fh-width= f-fmt.pix.width;
fh-height = f-fmt.pix.height;
+ mutex_lock(btv-init.cap.vb_lock);
btv-init.fmt= fmt;
btv-init.width = f-fmt.pix.width;
btv-init.height = f-fmt.pix.height;
+ mutex_unlock(btv-init.cap.vb_lock);
mutex_unlock(fh-cap.vb_lock);
return 0;
@@ -2855,6 +2852,7 @@ static int bttv_s_fbuf(struct file *file, void *f,
retval = 0;
fh-ovfmt = fmt;
+ mutex_lock(btv-init.cap.vb_lock);
btv-init.ovfmt = fmt;
if (fb-flags V4L2_FBUF_FLAG_OVERLAY) {
fh-ov.w.left = 0;
@@ -2876,6 +2874,7 @@ static int bttv_s_fbuf(struct file *file, void *f,
retval = bttv_switch_overlay(btv, fh, new);
}
}
+ mutex_unlock(btv-init.cap.vb_lock);
mutex_unlock(fh-cap.vb_lock);
return retval;
}
@@ -3141,6 +3140,7 @@ static int bttv_s_crop(struct file *file, void *f,
struct v4l2_crop *crop) fh-do_crop = 1;
mutex_lock(fh-cap.vb_lock);
+ mutex_lock(btv-init.cap.vb_lock);
if (fh-width c.min_scaled_width) {
fh-width = c.min_scaled_width;
@@ -3158,6 +3158,7 @@ static int bttv_s_crop(struct file *file, void *f,
struct v4l2_crop *crop) btv-init.height = c.max_scaled_height;
}
+ mutex_unlock(btv-init.cap.vb_lock);
mutex_unlock(fh-cap.vb_lock);
return 0;
@@ -3302,9 +3303,9 @@ static int bttv_open(struct file *file)
* Let's first copy btv-init at fh, holding cap.vb_lock, and then work
* with the rest of init, holding btv-lock.
*/
- mutex_lock(fh-cap.vb_lock);
+ mutex_lock(btv-init.cap.vb_lock);
*fh = btv-init;
- mutex_unlock(fh-cap.vb_lock);
+ mutex_unlock(btv-init.cap.vb_lock);
fh-type = type;
fh-ov.setup_ok = 0;
@@ -3502,9 +3503,9 @@ static int radio_open(struct file *file)
if (unlikely(!fh))
return -ENOMEM;
file-private_data = fh;
- mutex_lock(fh-cap.vb_lock);
+ mutex_lock(btv-init.cap.vb_lock);
*fh = btv-init;
- mutex_unlock(fh-cap.vb_lock);
+ mutex_unlock(btv-init.cap.vb_lock);
mutex_lock(btv-lock);
v4l2_prio_open(btv-prio, fh-prio);
@@ -4489,6 +4490,7 @@ static int __devinit bttv_probe(struct pci_dev *dev,
btv-opt_coring = coring;
/* fill struct bttv with some useful defaults */
+ mutex_init(btv-init.cap.vb_lock);
btv-init.btv = btv;
btv-init.ov.w.width = 320;
btv-init.ov.w.height = 240;
The patch is good here too. Thanks.
Tested-by: Chris Clayton chris2...@googlemail.com
--
The more I see, the more I know. The more I know, the less I understand.
Changing Man - Paul Weller
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
Re: Question about libv4lconvert.
Hi,
On 12/15/2010 05:11 PM, Antonio Ospite wrote:
Hi,
I am taking a look at libv4lconvert, and I have a question about the
logic in v4lconvert_convert_pixfmt(), in some conversion switches there
is code like this:
case V4L2_PIX_FMT_GREY:
switch (dest_pix_fmt) {
case V4L2_PIX_FMT_RGB24:
case V4L2_PIX_FMT_BGR24:
v4lconvert_grey_to_rgb24(src, dest, width, height);
break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
v4lconvert_grey_to_yuv420(src, dest, fmt);
break;
}
if (src_size (width * height)) {
V4LCONVERT_ERR(short grey data frame\n);
errno = EPIPE;
result = -1;
}
break;
However the conversion routines which are going to be called seem to
assume that the buffers, in particular the source buffer, are of the
correct full frame size when looping over them.
Correct, because they trust that the kernel drivers have allocated large
enough buffers to hold a valid frame which is a safe assumption.
My question is: shouldn't the size check now at the end of the case
block be at the _beginning_ of it instead, so to detect a short frame
before conversion and avoid a possible out of bound access inside the
conversion routine?
This is done this way deliberately, this has to do with how the EPIPE
errno variable is used in a special way.
An error return from v4lconvert_convert with an errno of EPIPE means
I managed to get some data for you but not an entire frame. The upper
layers of libv4l will respond to this by retrying (getting another frame),
but only a limited number of times. Once the retries are exceeded they
will simply pass along whatever they did manage to get.
The reason for this is that there can be bus errors or vsync issues (*),
which lead to a short frame, which are intermittent errors. So detecting
them and getting another frame is a good thing to do because usually the
next frame will be fine. However sometimes there are cases where every
single frame is a short frame, for example the zc3xx driver used to
deliver jpeg's with only 224 lines of data when running at 320x240 with
some sensors. Now one can argue that this is a driver issue, and it is
but it still happens in this case it is much better to pass along
the 224 lines which we did get, then to make this a fatal error.
Note that due to the retries the user will get a much lower framerate,
which together with the missing lines at the bottom + printing
of error messages will hopefully be enough for the user to report
a bug to us, despite him/her getting some picture.
I hope this explains.
Regards,
Hans
*) While starting the stream it may take several frames for vsync to
properly lock in some cases.
--
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: Hauppauge USB Live 2
On 12/14/10 18:23, Gerd Hoffmann wrote: $ git log --oneline --no-merges 4270c3ca.. drivers/media/video/cx231xx f5db33f [media] cx231xx: stray unlock on error path Using that commit directly looks better. I still see the UsbInterface::sendCommand failures, but the driver seems to finish the initialization and looks for the firmware. So it seems something between -rc2 and -rc5 in mainline made it regress ... Uhm, no. Looks like the difference is actually the .config No, isn't. Running vanilla 2.6.37-rc5 now, seeing both success and failure with the very same kernel. The driver is compiled statically into the kernel now. Booting with the device plugged works, it seems to initialize the device largely sucessfully, although some errors are sprinkled in. The firmware one is probably just a matter of making sure the firmware is in the initramfs, didn't look at that yet. Trying to fix the firmware issue by just unplugging and re-plugging the device once the system is fully up'n'running (and thus /lib/firmware available) results in a failure which looks pretty much like the original report. Any idea? Initialization order issue? Timing issue? cheers, Gerd PS: attached log was created using dmesg | egrep '(cx|usb 1-2)'. [1.954715] cx231xx v4l2 driver loaded. [1.954741] usbcore: registered new interface driver cx231xx [2.171811] usb 1-2: new high speed USB device using ehci_hcd and address 2 [2.291875] usb 1-2: New USB device found, idVendor=2040, idProduct=c200 [2.293621] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [2.297065] usb 1-2: Product: Hauppauge Device [2.298805] usb 1-2: Manufacturer: Hauppauge [2.298807] usb 1-2: SerialNumber: 0013566174 [2.305647] cx231xx #0: New device Hauppauge Hauppauge Device @ 480 Mbps (2040:c200) with 5 interfaces [2.307548] cx231xx #0: registering interface 1 [2.309498] cx231xx #0: can't change interface 3 alt no. to 3: Max. Pkt size = 0 [2.311374] cx231xx #0: can't change interface 4 alt no. to 1: Max. Pkt size = 0 [2.313248] cx231xx #0: Identified as Hauppauge USB Live 2 (card=9) [2.337247] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [2.339250] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [2.342754] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [2.373011] cx231xx #0: cx231xx_dif_set_standard: setStandard to [2.382006] cx231xx #0: Changing the i2c master port to 3 [2.386252] cx25840 15-0044: cx23102 A/V decoder found @ 0x88 (cx231xx #0) [2.412085] cx25840 15-0044: Firmware download size changed to 16 bytes max length [2.415597] cx25840 15-0044: unable to open firmware v4l-cx231xx-avcore-01.fw [2.448841] cx231xx #0: cx231xx #0: v4l2 driver version 0.0.1 [2.468502] cx231xx #0: cx231xx_dif_set_standard: setStandard to [2.516996] cx231xx #0: video_mux : 0 [2.518927] cx231xx #0: do_mode_ctrl_overrides : 0xb000 [2.521745] cx231xx #0: do_mode_ctrl_overrides NTSC [2.530728] cx231xx #0: cx231xx #0/0: registered device video0 [v4l2] [2.532972] cx231xx #0: cx231xx #0/0: registered device vbi0 [2.534857] cx231xx #0: V4L2 device registered as video0 and vbi0 [2.537056] cx231xx #0: EndPoint Addr 0x84, Alternate settings: 5 [2.549992] cx231xx #0: Alternate setting 0, max size= 512 [2.552147] cx231xx #0: Alternate setting 1, max size= 184 [2.554244] cx231xx #0: Alternate setting 2, max size= 728 [2.556181] cx231xx #0: Alternate setting 3, max size= 2892 [2.558023] cx231xx #0: Alternate setting 4, max size= 1800 [2.559827] cx231xx #0: EndPoint Addr 0x85, Alternate settings: 2 [2.583025] cx231xx #0: Alternate setting 0, max size= 512 [2.584811] cx231xx #0: Alternate setting 1, max size= 512 [2.586602] cx231xx #0: EndPoint Addr 0x86, Alternate settings: 2 [2.598406] cx231xx #0: Alternate setting 0, max size= 512 [2.600058] cx231xx #0: Alternate setting 1, max size= 576 [ 13.304543] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8 [ 13.314640] cx231xx #0: can't change interface 3 alt no. to 0 (err=-71) [ 29.289535] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8 [ 29.299602] cx231xx #0: can't change interface 3 alt no. to 0 (err=-71) [ 180.241409] usb 1-2: USB disconnect, address 2 [ 184.261061] usb 1-2: new high speed USB device using ehci_hcd and address 6 [ 184.377920] usb 1-2: New USB device found, idVendor=2040, idProduct=c200 [ 184.377928] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 184.377934] usb 1-2: Product: Hauppauge Device [ 184.377939] usb 1-2: Manufacturer: Hauppauge [ 184.377944] usb 1-2: SerialNumber: 0013566174 [ 184.381595] cx231xx #1: New device Hauppauge Hauppauge Device @ 480 Mbps (2040:c200) with 5 interfaces [ 184.381603] cx231xx #1: registering interface 1 [ 184.381784] cx231xx #1: can't change interface 3 alt no. to 3: Max. Pkt size = 0 [
[PATCHv8 01/12] mm: migrate.c: fix compilation error
GCC complained about update_mmu_cache() not being defined in migrate.c. Including asm/tlbflush.h seems to solve the problem. Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com --- mm/migrate.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/mm/migrate.c b/mm/migrate.c index fe5a3c6..6ae8a66 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -35,6 +35,8 @@ #include linux/hugetlb.h #include linux/gfp.h +#include asm/tlbflush.h + #include internal.h #define lru_to_page(_head) (list_entry((_head)-prev, struct page, lru)) -- 1.7.2.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
[PATCHv8 02/12] lib: bitmap: Added alignment offset for bitmap_find_next_zero_area()
From: Michal Nazarewicz min...@mina86.com
This commit adds a bitmap_find_next_zero_area_off() function which
works like bitmap_find_next_zero_area() function expect it allows an
offset to be specified when alignment is checked. This lets caller
request a bit such that its number plus the offset is aligned
according to the mask.
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
include/linux/bitmap.h | 24 +++-
lib/bitmap.c | 22 --
2 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index daf8c48..c0528d1 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -45,6 +45,7 @@
* bitmap_set(dst, pos, nbits) Set specified bit area
* bitmap_clear(dst, pos, nbits) Clear specified bit area
* bitmap_find_next_zero_area(buf, len, pos, n, mask) Find bit free area
+ * bitmap_find_next_zero_area_off(buf, len, pos, n, mask) as above
* bitmap_shift_right(dst, src, n, nbits) *dst = *src n
* bitmap_shift_left(dst, src, n, nbits) *dst = *src n
* bitmap_remap(dst, src, old, new, nbits) *dst = map(old, new)(src)
@@ -113,11 +114,24 @@ extern int __bitmap_weight(const unsigned long *bitmap,
int bits);
extern void bitmap_set(unsigned long *map, int i, int len);
extern void bitmap_clear(unsigned long *map, int start, int nr);
-extern unsigned long bitmap_find_next_zero_area(unsigned long *map,
-unsigned long size,
-unsigned long start,
-unsigned int nr,
-unsigned long align_mask);
+
+extern unsigned long bitmap_find_next_zero_area_off(unsigned long *map,
+ unsigned long size,
+ unsigned long start,
+ unsigned int nr,
+ unsigned long align_mask,
+ unsigned long align_offset);
+
+static inline unsigned long
+bitmap_find_next_zero_area(unsigned long *map,
+ unsigned long size,
+ unsigned long start,
+ unsigned int nr,
+ unsigned long align_mask)
+{
+ return bitmap_find_next_zero_area_off(map, size, start, nr,
+ align_mask, 0);
+}
extern int bitmap_scnprintf(char *buf, unsigned int len,
const unsigned long *src, int nbits);
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 741fae9..8e75a6f 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -315,30 +315,32 @@ void bitmap_clear(unsigned long *map, int start, int nr)
}
EXPORT_SYMBOL(bitmap_clear);
-/*
+/**
* bitmap_find_next_zero_area - find a contiguous aligned zero area
* @map: The address to base the search on
* @size: The bitmap size in bits
* @start: The bitnumber to start searching at
* @nr: The number of zeroed bits we're looking for
* @align_mask: Alignment mask for zero area
+ * @align_offset: Alignment offset for zero area.
*
* The @align_mask should be one less than a power of 2; the effect is that
- * the bit offset of all zero areas this function finds is multiples of that
- * power of 2. A @align_mask of 0 means no alignment is required.
+ * the bit offset of all zero areas this function finds plus @align_offset
+ * is multiple of that power of 2.
*/
-unsigned long bitmap_find_next_zero_area(unsigned long *map,
-unsigned long size,
-unsigned long start,
-unsigned int nr,
-unsigned long align_mask)
+unsigned long bitmap_find_next_zero_area_off(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr,
+unsigned long align_mask,
+unsigned long align_offset)
{
unsigned long index, end, i;
again:
index = find_next_zero_bit(map, size, start);
/* Align allocation */
- index = __ALIGN_MASK(index, align_mask);
+ index = __ALIGN_MASK(index + align_offset, align_mask) - align_offset;
end = index + nr;
if (end size)
@@ -350,7 +352,7 @@ again:
}
return index;
}
-EXPORT_SYMBOL(bitmap_find_next_zero_area);
+EXPORT_SYMBOL(bitmap_find_next_zero_area_off);
/*
* Bitmap printing parsing functions: first version by Bill Irwin,
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body
[PATCHv8 05/12] mm: alloc_contig_freed_pages() added
From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
This commit introduces alloc_contig_freed_pages() function
which allocates (ie. removes from buddy system) free pages
in range. Caller has to guarantee that all pages in range
are in buddy system.
Along with this function, a free_contig_pages() function is
provided which frees all (or a subset of) pages allocated
with alloc_contig_free_pages().
Michal Nazarewicz has modified the function to make it easier
to allocate not MAX_ORDER_NR_PAGES aligned pages by making it
return pfn of one-past-the-last allocated page.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
---
include/linux/page-isolation.h |3 ++
mm/page_alloc.c| 44
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 58cdbac..f1417ed 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -32,6 +32,9 @@ test_pages_isolated(unsigned long start_pfn, unsigned long
end_pfn);
*/
extern int set_migratetype_isolate(struct page *page);
extern void unset_migratetype_isolate(struct page *page);
+extern unsigned long alloc_contig_freed_pages(unsigned long start,
+ unsigned long end, gfp_t flag);
+extern void free_contig_pages(struct page *page, int nr_pages);
/*
* For migration.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 826ba69..be240a3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5425,6 +5425,50 @@ out:
spin_unlock_irqrestore(zone-lock, flags);
}
+unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end,
+ gfp_t flag)
+{
+ unsigned long pfn = start, count;
+ struct page *page;
+ struct zone *zone;
+ int order;
+
+ VM_BUG_ON(!pfn_valid(start));
+ zone = page_zone(pfn_to_page(start));
+
+ spin_lock_irq(zone-lock);
+
+ page = pfn_to_page(pfn);
+ for (;;) {
+ VM_BUG_ON(page_count(page) || !PageBuddy(page));
+ list_del(page-lru);
+ order = page_order(page);
+ zone-free_area[order].nr_free--;
+ rmv_page_order(page);
+ __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL order));
+ pfn += 1 order;
+ if (pfn = end)
+ break;
+ VM_BUG_ON(!pfn_valid(pfn));
+ page += 1 order;
+ }
+
+ spin_unlock_irq(zone-lock);
+
+ /* After this, pages in the range can be freed one be one */
+ page = pfn_to_page(start);
+ for (count = pfn - start; count; --count, ++page)
+ prep_new_page(page, 0, flag);
+
+ return pfn;
+}
+
+void free_contig_pages(struct page *page, int nr_pages)
+{
+ for (; nr_pages; --nr_pages, ++page)
+ __free_page(page);
+}
+
#ifdef CONFIG_MEMORY_HOTREMOVE
/*
* All pages in the range must be isolated before calling this.
--
1.7.2.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
[PATCHv8 04/12] mm: move some functions from memory_hotplug.c to page_isolation.c
From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Memory hotplug is a logic for making pages unused in the specified
range of pfn. So, some of core logics can be used for other purpose
as allocating a very large contigous memory block.
This patch moves some functions from mm/memory_hotplug.c to
mm/page_isolation.c. This helps adding a function for large-alloc in
page_isolation.c with memory-unplug technique.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
[mina86: reworded commit message]
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
---
include/linux/page-isolation.h |7 +++
mm/memory_hotplug.c| 108 --
mm/page_isolation.c| 111
3 files changed, 118 insertions(+), 108 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 051c1b1..58cdbac 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -33,5 +33,12 @@ test_pages_isolated(unsigned long start_pfn, unsigned long
end_pfn);
extern int set_migratetype_isolate(struct page *page);
extern void unset_migratetype_isolate(struct page *page);
+/*
+ * For migration.
+ */
+
+int test_pages_in_a_zone(unsigned long start_pfn, unsigned long end_pfn);
+unsigned long scan_lru_pages(unsigned long start, unsigned long end);
+int do_migrate_range(unsigned long start_pfn, unsigned long end_pfn);
#endif
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 2c6523a..2b18cb5 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -634,114 +634,6 @@ int is_mem_section_removable(unsigned long start_pfn,
unsigned long nr_pages)
}
/*
- * Confirm all pages in a range [start, end) is belongs to the same zone.
- */
-static int test_pages_in_a_zone(unsigned long start_pfn, unsigned long end_pfn)
-{
- unsigned long pfn;
- struct zone *zone = NULL;
- struct page *page;
- int i;
- for (pfn = start_pfn;
-pfn end_pfn;
-pfn += MAX_ORDER_NR_PAGES) {
- i = 0;
- /* This is just a CONFIG_HOLES_IN_ZONE check.*/
- while ((i MAX_ORDER_NR_PAGES) !pfn_valid_within(pfn + i))
- i++;
- if (i == MAX_ORDER_NR_PAGES)
- continue;
- page = pfn_to_page(pfn + i);
- if (zone page_zone(page) != zone)
- return 0;
- zone = page_zone(page);
- }
- return 1;
-}
-
-/*
- * Scanning pfn is much easier than scanning lru list.
- * Scan pfn from start to end and Find LRU page.
- */
-static unsigned long scan_lru_pages(unsigned long start, unsigned long end)
-{
- unsigned long pfn;
- struct page *page;
- for (pfn = start; pfn end; pfn++) {
- if (pfn_valid(pfn)) {
- page = pfn_to_page(pfn);
- if (PageLRU(page))
- return pfn;
- }
- }
- return 0;
-}
-
-static struct page *
-hotremove_migrate_alloc(struct page *page, unsigned long private, int **x)
-{
- /* This should be improved!! */
- return alloc_page(GFP_HIGHUSER_MOVABLE);
-}
-
-#define NR_OFFLINE_AT_ONCE_PAGES (256)
-static int
-do_migrate_range(unsigned long start_pfn, unsigned long end_pfn)
-{
- unsigned long pfn;
- struct page *page;
- int move_pages = NR_OFFLINE_AT_ONCE_PAGES;
- int not_managed = 0;
- int ret = 0;
- LIST_HEAD(source);
-
- for (pfn = start_pfn; pfn end_pfn move_pages 0; pfn++) {
- if (!pfn_valid(pfn))
- continue;
- page = pfn_to_page(pfn);
- if (!page_count(page))
- continue;
- /*
-* We can skip free pages. And we can only deal with pages on
-* LRU.
-*/
- ret = isolate_lru_page(page);
- if (!ret) { /* Success */
- list_add_tail(page-lru, source);
- move_pages--;
- inc_zone_page_state(page, NR_ISOLATED_ANON +
- page_is_file_cache(page));
-
- } else {
-#ifdef CONFIG_DEBUG_VM
- printk(KERN_ALERT removing pfn %lx from LRU failed\n,
- pfn);
- dump_page(page);
-#endif
- /* Becasue we don't have big zone-lock. we should
- check this again here. */
- if (page_count(page)) {
- not_managed++;
- ret = -EBUSY;
- break;
- }
- }
- }
- if (!list_empty(source)) {
- if (not_managed) {
-
[PATCHv8 12/12] ARM: cma: Added CMA to Aquila, Goni and c210 universal boards
This commit adds CMA memory reservation code to Aquila, Goni and c210 universal boards. Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-s5pv210/Kconfig |2 + arch/arm/mach-s5pv210/mach-aquila.c |2 + arch/arm/mach-s5pv210/mach-goni.c |2 + arch/arm/mach-s5pv310/Kconfig |1 + arch/arm/mach-s5pv310/mach-universal_c210.c |2 + arch/arm/plat-s5p/Makefile |2 + arch/arm/plat-s5p/cma-stub.c| 49 +++ arch/arm/plat-s5p/include/plat/cma-stub.h | 21 +++ 8 files changed, 81 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-s5p/cma-stub.c create mode 100644 arch/arm/plat-s5p/include/plat/cma-stub.h diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig index 53aabef..b395a16 100644 --- a/arch/arm/mach-s5pv210/Kconfig +++ b/arch/arm/mach-s5pv210/Kconfig @@ -68,6 +68,7 @@ config MACH_AQUILA select S5P_DEV_ONENAND select S5PV210_SETUP_FB_24BPP select S5PV210_SETUP_SDHCI + select CMA_DEVICE_POSSIBLE help Machine support for the Samsung Aquila target based on S5PC110 SoC @@ -92,6 +93,7 @@ config MACH_GONI select S5PV210_SETUP_I2C2 select S5PV210_SETUP_KEYPAD select S5PV210_SETUP_SDHCI + select CMA_DEVICE_POSSIBLE help Machine support for Samsung GONI board S5PC110(MCP) is one of package option of S5PV210 diff --git a/arch/arm/mach-s5pv210/mach-aquila.c b/arch/arm/mach-s5pv210/mach-aquila.c index 28677ca..8608a16 100644 --- a/arch/arm/mach-s5pv210/mach-aquila.c +++ b/arch/arm/mach-s5pv210/mach-aquila.c @@ -39,6 +39,7 @@ #include plat/fb.h #include plat/fimc-core.h #include plat/sdhci.h +#include plat/cma-stub.h /* Following are default values for UCON, ULCON and UFCON UART registers */ #define AQUILA_UCON_DEFAULT(S3C2410_UCON_TXILEVEL |\ @@ -690,4 +691,5 @@ MACHINE_START(AQUILA, Aquila) .map_io = aquila_map_io, .init_machine = aquila_machine_init, .timer = s3c24xx_timer, + .reserve= cma_mach_reserve, MACHINE_END diff --git a/arch/arm/mach-s5pv210/mach-goni.c b/arch/arm/mach-s5pv210/mach-goni.c index b1dcf96..b1bf079 100644 --- a/arch/arm/mach-s5pv210/mach-goni.c +++ b/arch/arm/mach-s5pv210/mach-goni.c @@ -45,6 +45,7 @@ #include plat/keypad.h #include plat/sdhci.h #include plat/clock.h +#include plat/cma-stub.h /* Following are default values for UCON, ULCON and UFCON UART registers */ #define GONI_UCON_DEFAULT (S3C2410_UCON_TXILEVEL |\ @@ -865,4 +866,5 @@ MACHINE_START(GONI, GONI) .map_io = goni_map_io, .init_machine = goni_machine_init, .timer = s3c24xx_timer, + .reserve= cma_mach_reserve, MACHINE_END diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig index d64efe0..ae4e0da 100644 --- a/arch/arm/mach-s5pv310/Kconfig +++ b/arch/arm/mach-s5pv310/Kconfig @@ -85,6 +85,7 @@ config MACH_UNIVERSAL_C210 select S5P_DEV_ONENAND select S3C_DEV_I2C1 select S5PV310_SETUP_I2C1 + select CMA_DEVICE_POSSIBLE help Machine support for Samsung Mobile Universal S5PC210 Reference Board. S5PC210(MCP) is one of package option of S5PV310 diff --git a/arch/arm/mach-s5pv310/mach-universal_c210.c b/arch/arm/mach-s5pv310/mach-universal_c210.c index 16d8fc0..d65703a 100644 --- a/arch/arm/mach-s5pv310/mach-universal_c210.c +++ b/arch/arm/mach-s5pv310/mach-universal_c210.c @@ -21,6 +21,7 @@ #include plat/s5pv310.h #include plat/cpu.h #include plat/devs.h +#include plat/cma-stub.h #include mach/map.h @@ -152,6 +153,7 @@ MACHINE_START(UNIVERSAL_C210, UNIVERSAL_C210) .boot_params= S5P_PA_SDRAM + 0x100, .init_irq = s5pv310_init_irq, .map_io = universal_map_io, + .reserve= cma_mach_reserve, .init_machine = universal_machine_init, .timer = s5pv310_timer, MACHINE_END diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile index de65238..6fdb6ce 100644 --- a/arch/arm/plat-s5p/Makefile +++ b/arch/arm/plat-s5p/Makefile @@ -28,3 +28,5 @@ obj-$(CONFIG_S5P_DEV_FIMC0) += dev-fimc0.o obj-$(CONFIG_S5P_DEV_FIMC1)+= dev-fimc1.o obj-$(CONFIG_S5P_DEV_FIMC2)+= dev-fimc2.o obj-$(CONFIG_S5P_DEV_ONENAND) += dev-onenand.o + +obj-$(CONFIG_CMA) += cma-stub.o diff --git a/arch/arm/plat-s5p/cma-stub.c b/arch/arm/plat-s5p/cma-stub.c new file mode 100644 index 000..c175ba8 --- /dev/null +++ b/arch/arm/plat-s5p/cma-stub.c @@ -0,0 +1,49 @@ +/* + * This file is just a quick and dirty hack to get CMA testing device + * working. The cma_mach_reserve() should be called as mach's reserve + * callback. CMA testing device will use cma_ctx for allocations. + */ +
[PATCHv8 07/12] mm: cma: Contiguous Memory Allocator added
The Contiguous Memory Allocator is a set of functions that lets one initialise a region of memory which then can be used to perform allocations of contiguous memory chunks from. CMA allows for creation of private and non-private contexts. The former is reserved for CMA and no other kernel subsystem can use it. The latter allows for movable pages to be allocated within CMA's managed memory so that it can be used for page cache when CMA devices do not use it. Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- include/linux/cma.h | 219 ++ mm/Kconfig | 22 mm/Makefile |1 + mm/cma.c| 328 +++ 4 files changed, 570 insertions(+), 0 deletions(-) create mode 100644 include/linux/cma.h create mode 100644 mm/cma.c diff --git a/include/linux/cma.h b/include/linux/cma.h new file mode 100644 index 000..e9575fd --- /dev/null +++ b/include/linux/cma.h @@ -0,0 +1,219 @@ +#ifndef __LINUX_CMA_H +#define __LINUX_CMA_H + +/* + * Contiguous Memory Allocator + * Copyright (c) 2010 by Samsung Electronics. + * Written by Michal Nazarewicz (m.nazarew...@samsung.com) + */ + +/* + * Contiguous Memory Allocator + * + * The Contiguous Memory Allocator (CMA) makes it possible for + * device drivers to allocate big contiguous chunks of memory after + * the system has booted. + * + * It requires some machine- and/or platform-specific initialisation + * code which prepares memory ranges to be used with CMA and later, + * device drivers can allocate memory from those ranges. + * + * Why is it needed? + * + * Various devices on embedded systems have no scatter-getter and/or + * IO map support and require contiguous blocks of memory to + * operate. They include devices such as cameras, hardware video + * coders, etc. + * + * Such devices often require big memory buffers (a full HD frame + * is, for instance, more then 2 mega pixels large, i.e. more than 6 + * MB of memory), which makes mechanisms such as kmalloc() or + * alloc_page() ineffective. + * + * At the same time, a solution where a big memory region is + * reserved for a device is suboptimal since often more memory is + * reserved then strictly required and, moreover, the memory is + * inaccessible to page system even if device drivers don't use it. + * + * CMA tries to solve this issue by operating on memory regions + * where only movable pages can be allocated from. This way, kernel + * can use the memory for pagecache and when device driver requests + * it, allocated pages can be migrated. + * + * Driver usage + * + * For device driver to use CMA it needs to have a pointer to a CMA + * context represented by a struct cma (which is an opaque data + * type). + * + * Once such pointer is obtained, device driver may allocate + * contiguous memory chunk using the following function: + * + * cm_alloc() + * + * This function returns a pointer to struct cm (another opaque data + * type) which represent a contiguous memory chunk. This pointer + * may be used with the following functions: + * + * cm_free()-- frees allocated contiguous memory + * cm_pin() -- pins memory + * cm_unpin() -- unpins memory + * cm_vmap()-- maps memory in kernel space + * cm_vunmap() -- unmaps memory from kernel space + * + * See the respective functions for more information. + * + * Platform/machine integration + * + * For device drivers to be able to use CMA platform or machine + * initialisation code must create a CMA context and pass it to + * device drivers. The latter may be done by a global variable or + * a platform/machine specific function. For the former CMA + * provides the following functions: + * + * cma_reserve() + * cma_create() + * + * The cma_reserve() function must be called when memblock is still + * operational and reserving memory with it is still possible. On + * ARM platform the reserve machine callback is a perfect place to + * call it. + * + * The last function creates a CMA context on a range of previously + * initialised memory addresses. Because it uses kmalloc() it needs + * to be called after SLAB is initialised. + */ + +/* Kernel level API */ + +#if defined __KERNEL__ defined CONFIG_CMA + +/* CMA context */ +struct cma; +/* Contiguous Memory chunk */ +struct cm; + +/** + * cma_reserve() - reserves memory. + * @start: start address of the memory range in bytes hint; if unsure + * pass zero. + * @size: size of the memory to reserve in bytes. + * @alignment: desired alignment in bytes (must be power of two or zero). + * + * It will use memblock to allocate memory. @start and @size will be + * aligned to PAGE_SIZE. + * + * Returns reserved's area physical address or value
[PATCHv8 10/12] mm: MIGRATE_CMA support added to CMA
This commit adds MIGRATE_CMA migratetype support to the CMA.
The advantage is that an (almost) arbitrary memory range can
be marked as MIGRATE_CMA which may not be the case with
ZONE_MOVABLE.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/cma.h | 58 ---
mm/cma.c| 161 +--
2 files changed, 194 insertions(+), 25 deletions(-)
diff --git a/include/linux/cma.h b/include/linux/cma.h
index e9575fd..8952531 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -71,9 +71,14 @@
* a platform/machine specific function. For the former CMA
* provides the following functions:
*
+ * cma_init_migratetype()
* cma_reserve()
* cma_create()
*
+ * The first one initialises a portion of reserved memory so that it
+ * can be used with CMA. The second first tries to reserve memory
+ * (using memblock) and then initialise it.
+ *
* The cma_reserve() function must be called when memblock is still
* operational and reserving memory with it is still possible. On
* ARM platform the reserve machine callback is a perfect place to
@@ -93,21 +98,56 @@ struct cma;
/* Contiguous Memory chunk */
struct cm;
+#ifdef CONFIG_MIGRATE_CMA
+
+/**
+ * cma_init_migratetype() - initialises range of physical memory to be used
+ * with CMA context.
+ * @start: start address of the memory range in bytes.
+ * @size: size of the memory range in bytes.
+ *
+ * The range must be MAX_ORDER_NR_PAGES aligned and it must have been
+ * already reserved (eg. with memblock).
+ *
+ * The actual initialisation is deferred until subsys initcalls are
+ * evaluated (unless this has already happened).
+ *
+ * Returns zero on success or negative error.
+ */
+int cma_init_migratetype(unsigned long start, unsigned long end);
+
+#else
+
+static inline int cma_init_migratetype(unsigned long start, unsigned long end)
+{
+ (void)start; (void)end;
+ return -EOPNOTSUPP;
+}
+
+#endif
+
/**
* cma_reserve() - reserves memory.
* @start: start address of the memory range in bytes hint; if unsure
* pass zero.
* @size: size of the memory to reserve in bytes.
* @alignment: desired alignment in bytes (must be power of two or zero).
+ * @init_migratetype: whether to initialise pageblocks.
+ *
+ * It will use memblock to allocate memory. If @init_migratetype is
+ * true, the function will also call cma_init_migratetype() on
+ * reserved region so that a non-private CMA context can be created on
+ * given range.
*
- * It will use memblock to allocate memory. @start and @size will be
- * aligned to PAGE_SIZE.
+ * @start and @size will be aligned to PAGE_SIZE if @init_migratetype
+ * is false or to (MAX_ORDER_NR_PAGES PAGE_SHIFT) if
+ * @init_migratetype is true.
*
* Returns reserved's area physical address or value that yields true
* when checked with IS_ERR_VALUE().
*/
unsigned long cma_reserve(unsigned long start, unsigned long size,
- unsigned long alignment);
+ unsigned long alignment, _Bool init_migratetype);
/**
* cma_create() - creates a CMA context.
@@ -118,12 +158,14 @@ unsigned long cma_reserve(unsigned long start, unsigned
long size,
*
* The range must be page aligned. Different contexts cannot overlap.
*
- * Unless @private is true the memory range must lay in ZONE_MOVABLE.
- * If @private is true no underlaying memory checking is done and
- * during allocation no pages migration will be performed - it is
- * assumed that the memory is reserved and only CMA manages it.
+ * Unless @private is true the memory range must either lay in
+ * ZONE_MOVABLE or must have been initialised with
+ * cma_init_migratetype() function. If @private is true no
+ * underlaying memory checking is done and during allocation no pages
+ * migration will be performed - it is assumed that the memory is
+ * reserved and only CMA manages it.
*
- * @start and @size must be page and @min_alignment alignment.
+ * @start and @size must be page and @min_alignment aligned.
* @min_alignment specifies the minimal alignment that user will be
* able to request through cm_alloc() function. In most cases one
* will probably pass zero as @min_alignment but if the CMA context
diff --git a/mm/cma.c b/mm/cma.c
index d82361b..4017dee 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -57,21 +57,130 @@ static unsigned long phys_to_pfn(phys_addr_t phys)
/* Initialise CMA */
+#ifdef CONFIG_MIGRATE_CMA
+
+static struct cma_grabbed {
+ unsigned long start;
+ unsigned long size;
+} cma_grabbed[8] __initdata;
+static unsigned cma_grabbed_count __initdata;
+
+#ifdef CONFIG_DEBUG_VM
+
+static int __cma_give_back(unsigned long start, unsigned long size)
+{
+ unsigned long pfn = phys_to_pfn(start);
+
[PATCHv8 11/12] mm: cma: Test device and application added
This patch adds a cma misc device which lets user space use the
CMA API. This device is meant for testing. A testing application
is also provided.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/misc/Kconfig | 28 +++
drivers/misc/Makefile |1 +
drivers/misc/cma-dev.c | 238 +
include/linux/cma.h| 29 +++
tools/cma/cma-test.c | 457
5 files changed, 753 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/cma-dev.c
create mode 100644 tools/cma/cma-test.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 1e1a4be..b90e36b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -458,4 +458,32 @@ source drivers/misc/cb710/Kconfig
source drivers/misc/iwmc3200top/Kconfig
source drivers/misc/ti-st/Kconfig
+# Selet this for platforms/machines that implemented code making
+# the CMA test device usable.
+config CMA_DEVICE_POSSIBLE
+ bool
+
+config CMA_DEVICE
+ tristate CMA test device (DEVELOPEMENT)
+ depends on CMA CMA_DEVICE_POSSIBLE
+ help
+ The CMA misc device allows allocating contiguous memory areas
+ from user space. This is for testing of the CMA framework.
+
+ If unsure, say n
+
+# Selet this for platforms/machines that implemented code making
+# the CMA test device usable.
+config CMA_DEVICE_POSSIBLE
+ bool
+
+config CMA_DEVICE
+ tristate CMA test device (DEVELOPEMENT)
+ depends on CMA CMA_DEVICE_POSSIBLE
+ help
+ The CMA misc device allows allocating contiguous memory areas
+ from user space. This is for testing of the CMA framework.
+
+ If unsure, say n
+
endif # MISC_DEVICES
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 98009cc..f8eadd4 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -42,3 +42,4 @@ obj-$(CONFIG_ARM_CHARLCD) += arm-charlcd.o
obj-$(CONFIG_PCH_PHUB) += pch_phub.o
obj-y += ti-st/
obj-$(CONFIG_AB8500_PWM) += ab8500-pwm.o
+obj-$(CONFIG_CMA_DEVICE) += cma-dev.o
diff --git a/drivers/misc/cma-dev.c b/drivers/misc/cma-dev.c
new file mode 100644
index 000..6c36064
--- /dev/null
+++ b/drivers/misc/cma-dev.c
@@ -0,0 +1,238 @@
+/*
+ * Contiguous Memory Allocator userspace driver
+ * Copyright (c) 2010 by Samsung Electronics.
+ * Written by Michal Nazarewicz (m.nazarew...@samsung.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License or (at your optional) any later version of the license.
+ */
+
+#define pr_fmt(fmt) cma: fmt
+
+#ifdef CONFIG_CMA_DEBUG
+# define DEBUG
+#endif
+
+#include linux/errno.h /* Error numbers */
+#include linux/err.h /* IS_ERR_VALUE() */
+#include linux/fs.h /* struct file */
+#include linux/mm.h /* Memory stuff */
+#include linux/mman.h
+#include linux/slab.h
+#include linux/module.h /* Standard module stuff */
+#include linux/device.h /* struct device, dev_dbg() */
+#include linux/types.h /* Just to be safe ;) */
+#include linux/uaccess.h /* __copy_{to,from}_user */
+#include linux/miscdevice.h /* misc_register() and company */
+
+#include linux/cma.h
+
+#include plat/cma-stub.h
+
+static int cma_file_open(struct inode *inode, struct file *file);
+static int cma_file_release(struct inode *inode, struct file *file);
+static long cma_file_ioctl(struct file *file, unsigned cmd, unsigned long arg);
+static int cma_file_mmap(struct file *file, struct vm_area_struct *vma);
+
+static struct miscdevice cma_miscdev = {
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = cma,
+ .fops = (const struct file_operations) {
+ .owner = THIS_MODULE,
+ .open = cma_file_open,
+ .release= cma_file_release,
+ .unlocked_ioctl = cma_file_ioctl,
+ .mmap = cma_file_mmap,
+ },
+};
+#define cma_dev (cma_miscdev.this_device)
+
+struct cma_private_data {
+ struct cm *cm;
+ unsigned long size;
+ unsigned long phys;
+};
+
+static int cma_file_open(struct inode *inode, struct file *file)
+{
+ struct cma_private_data *prv;
+
+ dev_dbg(cma_dev, %s(%p)\n, __func__, (void *)file);
+
+ if (!cma_ctx)
+ return -EOPNOTSUPP;
+
+ prv = kzalloc(sizeof *prv, GFP_KERNEL);
+ if (!prv)
+ return -ENOMEM;
+
+ file-private_data = prv;
+
+ return 0;
+}
+
+static int cma_file_release(struct inode *inode, struct file *file)
+{
+ struct cma_private_data *prv = file-private_data;
+
+ dev_dbg(cma_dev, %s(%p)\n, __func__, (void *)file);
+
+ if (prv-cm) {
+
[PATCHv8 08/12] mm: MIGRATE_CMA migration type added
The MIGRATE_CMA migration type has two main characteristics:
(i) only movable pages can be allocated from MIGRATE_CMA
pageblocks and (ii) page allocator will never change migration
type of MIGRATE_CMA pageblocks.
This guarantees that page in a MIGRATE_CMA page block can
always be migrated somewhere else (unless there's no memory left
in the system).
It is designed to be used with Contiguous Memory Allocator
(CMA) for allocating big chunks (eg. 10MiB) of physically
contiguous memory. Once driver requests contiguous memory,
CMA will migrate pages from MIGRATE_CMA pageblocks.
To minimise number of migrations, MIGRATE_CMA migration type
is the last type tried when page allocator falls back to other
migration types then requested.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/mmzone.h | 43
mm/Kconfig | 14
mm/compaction.c| 10 +
mm/internal.h |3 ++
mm/page_alloc.c| 87 +--
5 files changed, 131 insertions(+), 26 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 39c24eb..cc798b1 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -35,13 +35,37 @@
*/
#define PAGE_ALLOC_COSTLY_ORDER 3
-#define MIGRATE_UNMOVABLE 0
-#define MIGRATE_RECLAIMABLE 1
-#define MIGRATE_MOVABLE 2
-#define MIGRATE_PCPTYPES 3 /* the number of types on the pcp lists */
-#define MIGRATE_RESERVE 3
-#define MIGRATE_ISOLATE 4 /* can't allocate from here */
-#define MIGRATE_TYPES 5
+enum {
+ MIGRATE_UNMOVABLE,
+ MIGRATE_RECLAIMABLE,
+ MIGRATE_MOVABLE,
+ MIGRATE_PCPTYPES, /* the number of types on the pcp lists */
+ MIGRATE_RESERVE = MIGRATE_PCPTYPES,
+#ifdef CONFIG_MIGRATE_CMA
+ /*
+* MIGRATE_CMA migration type is designed to mimic the way
+* ZONE_MOVABLE works. Only movable pages can be allocated
+* from MIGRATE_CMA pageblocks and page allocator never
+* implicitly change migration type of MIGRATE_CMA pageblock.
+*
+* The way to use it is to change migratetype of a range of
+* pageblocks to MIGRATE_CMA which can be done by
+* __free_pageblock_cma() function. What is important though
+* is that a range of pageblocks must be aligned to
+* MAX_ORDER_NR_PAGES should biggest page be bigger then
+* a single pageblock.
+*/
+ MIGRATE_CMA,
+#endif
+ MIGRATE_ISOLATE,/* can't allocate from here */
+ MIGRATE_TYPES
+};
+
+#ifdef CONFIG_MIGRATE_CMA
+# define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+#else
+# define is_migrate_cma(migratetype) false
+#endif
#define for_each_migratetype_order(order, type) \
for (order = 0; order MAX_ORDER; order++) \
@@ -54,6 +78,11 @@ static inline int get_pageblock_migratetype(struct page
*page)
return get_pageblock_flags_group(page, PB_migrate, PB_migrate_end);
}
+static inline bool is_pageblock_cma(struct page *page)
+{
+ return is_migrate_cma(get_pageblock_migratetype(page));
+}
+
struct free_area {
struct list_headfree_list[MIGRATE_TYPES];
unsigned long nr_free;
diff --git a/mm/Kconfig b/mm/Kconfig
index 2beab4d..32fb085 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -343,6 +343,20 @@ config CMA
For more information see include/linux/cma.h. If unsure, say n.
+config MIGRATE_CMA
+ bool Use MIGRATE_CMA migratetype
+ depends on CMA
+ default y
+ help
+ This enables the use the MIGRATE_CMA migrate type in the CMA.
+ MIGRATE_CMA lets CMA work on almost arbitrary memory range and
+ not only inside ZONE_MOVABLE.
+
+ This option can also be selected by code that uses MIGRATE_CMA
+ even if CMA is not present.
+
+ If unsure, say y.
+
config CMA_DEBUG
bool CMA debug messages (DEVELOPEMENT)
depends on CMA
diff --git a/mm/compaction.c b/mm/compaction.c
index 4d709ee..c5e404b 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -113,6 +113,16 @@ static bool suitable_migration_target(struct page *page)
if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE)
return false;
+ /* Keep MIGRATE_CMA alone as well. */
+ /*
+* XXX Revisit. We currently cannot let compaction touch CMA
+* pages since compaction insists on changing their migration
+* type to MIGRATE_MOVABLE (see split_free_page() called from
+* isolate_freepages_block() above).
+*/
+ if (is_migrate_cma(migratetype))
+ return false;
+
/* If the page is a large free page, then allow migration */
if (PageBuddy(page) page_order(page) = pageblock_order)
return true;
diff --git
[PATCHv8 09/12] mm: MIGRATE_CMA isolation functions added
This commit changes various functions that change pages and
pageblocks migrate type between MIGRATE_ISOLATE and
MIGRATE_MOVABLE in such a way as to allow to work with
MIGRATE_CMA migrate type.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/page-isolation.h | 40 +++-
mm/page_alloc.c| 19 ---
mm/page_isolation.c| 15 ---
3 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index c5d1a7c..177b307 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -3,39 +3,53 @@
/*
* Changes migrate type in [start_pfn, end_pfn) to be MIGRATE_ISOLATE.
- * If specified range includes migrate types other than MOVABLE,
+ * If specified range includes migrate types other than MOVABLE or CMA,
* this will fail with -EBUSY.
*
* For isolating all pages in the range finally, the caller have to
* free all pages in the range. test_page_isolated() can be used for
* test it.
*/
-extern int
-start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn);
+int __start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
+ unsigned migratetype);
+
+static inline int
+start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn)
+{
+ return __start_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
+}
+
+int __undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
+ unsigned migratetype);
/*
* Changes MIGRATE_ISOLATE to MIGRATE_MOVABLE.
* target range is [start_pfn, end_pfn)
*/
-extern int
-undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn);
+static inline int
+undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn)
+{
+ return __undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
+}
/*
- * test all pages in [start_pfn, end_pfn)are isolated or not.
+ * Test all pages in [start_pfn, end_pfn) are isolated or not.
*/
-extern int
-test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
+int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
/*
- * Internal funcs.Changes pageblock's migrate type.
- * Please use make_pagetype_isolated()/make_pagetype_movable().
+ * Internal functions. Changes pageblock's migrate type.
*/
-extern int set_migratetype_isolate(struct page *page);
-extern void unset_migratetype_isolate(struct page *page);
+int set_migratetype_isolate(struct page *page);
+void __unset_migratetype_isolate(struct page *page, unsigned migratetype);
+static inline void unset_migratetype_isolate(struct page *page)
+{
+ __unset_migratetype_isolate(page, MIGRATE_MOVABLE);
+}
extern unsigned long alloc_contig_freed_pages(unsigned long start,
unsigned long end, gfp_t flag);
extern int alloc_contig_range(unsigned long start, unsigned long end,
- gfp_t flags);
+ gfp_t flags, unsigned migratetype);
extern void free_contig_pages(struct page *page, int nr_pages);
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e706282..7f913d1 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5460,7 +5460,7 @@ out:
return ret;
}
-void unset_migratetype_isolate(struct page *page)
+void __unset_migratetype_isolate(struct page *page, unsigned migratetype)
{
struct zone *zone;
unsigned long flags;
@@ -5468,8 +5468,8 @@ void unset_migratetype_isolate(struct page *page)
spin_lock_irqsave(zone-lock, flags);
if (get_pageblock_migratetype(page) != MIGRATE_ISOLATE)
goto out;
- set_pageblock_migratetype(page, MIGRATE_MOVABLE);
- move_freepages_block(zone, page, MIGRATE_MOVABLE);
+ set_pageblock_migratetype(page, migratetype);
+ move_freepages_block(zone, page, migratetype);
out:
spin_unlock_irqrestore(zone-lock, flags);
}
@@ -5574,6 +5574,10 @@ static int __alloc_contig_migrate_range(unsigned long
start, unsigned long end)
* @start: start PFN to allocate
* @end: one-past-the-last PFN to allocate
* @flags: flags passed to alloc_contig_freed_pages().
+ * @migratetype: migratetype of the underlaying pageblocks (either
+ * #MIGRATE_MOVABLE or #MIGRATE_CMA). All pageblocks
+ * in range must have the same migratetype and it must
+ * be either of the two.
*
* The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
* aligned, hovewer it's callers responsibility to guarantee that we
@@ -5585,7 +5589,7 @@ static int __alloc_contig_migrate_range(unsigned long
start, unsigned long end)
* need to be freed with free_contig_pages().
*/
int
[PATCHv8 06/12] mm: alloc_contig_range() added
This commit adds the alloc_contig_range() function which tries
to allecate given range of pages. It tries to migrate all
already allocated pages that fall in the range thus freeing them.
Once all pages in the range are freed they are removed from the
buddy system thus allocated for the caller to use.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/page-isolation.h |2 +
mm/page_alloc.c| 144
2 files changed, 146 insertions(+), 0 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index f1417ed..c5d1a7c 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -34,6 +34,8 @@ extern int set_migratetype_isolate(struct page *page);
extern void unset_migratetype_isolate(struct page *page);
extern unsigned long alloc_contig_freed_pages(unsigned long start,
unsigned long end, gfp_t flag);
+extern int alloc_contig_range(unsigned long start, unsigned long end,
+ gfp_t flags);
extern void free_contig_pages(struct page *page, int nr_pages);
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index be240a3..008a6e8 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5463,6 +5463,150 @@ unsigned long alloc_contig_freed_pages(unsigned long
start, unsigned long end,
return pfn;
}
+static unsigned long pfn_to_maxpage(unsigned long pfn)
+{
+ return pfn ~(MAX_ORDER_NR_PAGES - 1);
+}
+
+static unsigned long pfn_to_maxpage_up(unsigned long pfn)
+{
+ return ALIGN(pfn, MAX_ORDER_NR_PAGES);
+}
+
+#define MIGRATION_RETRY5
+static int __alloc_contig_migrate_range(unsigned long start, unsigned long end)
+{
+ int migration_failed = 0, ret;
+ unsigned long pfn = start;
+
+ /*
+* Some code borrowed from KAMEZAWA Hiroyuki's
+* __alloc_contig_pages().
+*/
+
+ for (;;) {
+ pfn = scan_lru_pages(pfn, end);
+ if (!pfn || pfn = end)
+ break;
+
+ ret = do_migrate_range(pfn, end);
+ if (!ret) {
+ migration_failed = 0;
+ } else if (ret != -EBUSY
+ || ++migration_failed = MIGRATION_RETRY) {
+ return ret;
+ } else {
+ /* There are unstable pages.on pagevec. */
+ lru_add_drain_all();
+ /*
+* there may be pages on pcplist before
+* we mark the range as ISOLATED.
+*/
+ drain_all_pages();
+ }
+ cond_resched();
+ }
+
+ if (!migration_failed) {
+ /* drop all pages in pagevec and pcp list */
+ lru_add_drain_all();
+ drain_all_pages();
+ }
+
+ /* Make sure all pages are isolated */
+ if (WARN_ON(test_pages_isolated(start, end)))
+ return -EBUSY;
+
+ return 0;
+}
+
+/**
+ * alloc_contig_range() -- tries to allocate given range of pages
+ * @start: start PFN to allocate
+ * @end: one-past-the-last PFN to allocate
+ * @flags: flags passed to alloc_contig_freed_pages().
+ *
+ * The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
+ * aligned, hovewer it's callers responsibility to guarantee that we
+ * are the only thread that changes migrate type of pageblocks the
+ * pages fall in.
+ *
+ * Returns zero on success or negative error code. On success all
+ * pages which PFN is in (start, end) are allocated for the caller and
+ * need to be freed with free_contig_pages().
+ */
+int alloc_contig_range(unsigned long start, unsigned long end,
+ gfp_t flags)
+{
+ unsigned long _start, _end;
+ int ret;
+
+ /*
+* What we do here is we mark all pageblocks in range as
+* MIGRATE_ISOLATE. Because of the way page allocator work, we
+* align the range to MAX_ORDER pages so that page allocator
+* won't try to merge buddies from different pageblocks and
+* change MIGRATE_ISOLATE to some other migration type.
+*
+* Once the pageblocks are marked as MIGRATE_ISOLATE, we
+* migrate the pages from an unaligned range (ie. pages that
+* we are interested in). This will put all the pages in
+* range back to page allocator as MIGRATE_ISOLATE.
+*
+* When this is done, we take the pages in range from page
+* allocator removing them from the buddy system. This way
+* page allocator will never consider using them.
+*
+* This lets us mark the pageblocks back as
+* MIGRATE_CMA/MIGRATE_MOVABLE so that free pages in the
+* MAX_ORDER aligned range but not in the
[PATCHv8 03/12] lib: genalloc: Generic allocator improvements
This commit adds a gen_pool_alloc_aligned() function to the
generic allocator API. It allows specifying alignment for the
allocated block. This feature uses
the bitmap_find_next_zero_area_off() function.
It also fixes possible issue with bitmap's last element being
not fully allocated (ie. space allocated for chunk-bits is
not a multiple of sizeof(long)).
It also makes some other smaller changes:
- moves structure definitions out of the header file,
- adds __must_check to functions returning value,
- makes gen_pool_add() return -ENOMEM rater than -1 on error,
- changes list_for_each to list_for_each_entry, and
- makes use of bitmap_clear().
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
include/linux/genalloc.h | 46 ++--
lib/genalloc.c | 182 ++---
2 files changed, 129 insertions(+), 99 deletions(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 9869ef3..8ac7337 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -8,29 +8,31 @@
* Version 2. See the file COPYING for more details.
*/
+struct gen_pool;
-/*
- * General purpose special memory pool descriptor.
- */
-struct gen_pool {
- rwlock_t lock;
- struct list_head chunks;/* list of chunks in this pool */
- int min_alloc_order;/* minimum allocation order */
-};
+struct gen_pool *__must_check gen_pool_create(unsigned order, int nid);
-/*
- * General purpose special memory pool chunk descriptor.
+int __must_check gen_pool_add(struct gen_pool *pool, unsigned long addr,
+ size_t size, int nid);
+
+void gen_pool_destroy(struct gen_pool *pool);
+
+unsigned long __must_check
+gen_pool_alloc_aligned(struct gen_pool *pool, size_t size,
+ unsigned alignment_order);
+
+/**
+ * gen_pool_alloc() - allocate special memory from the pool
+ * @pool: Pool to allocate from.
+ * @size: Number of bytes to allocate from the pool.
+ *
+ * Allocate the requested number of bytes from the specified pool.
+ * Uses a first-fit algorithm.
*/
-struct gen_pool_chunk {
- spinlock_t lock;
- struct list_head next_chunk;/* next chunk in pool */
- unsigned long start_addr; /* starting address of memory chunk */
- unsigned long end_addr; /* ending address of memory chunk */
- unsigned long bits[0]; /* bitmap for allocating memory chunk */
-};
+static inline unsigned long __must_check
+gen_pool_alloc(struct gen_pool *pool, size_t size)
+{
+ return gen_pool_alloc_aligned(pool, size, 0);
+}
-extern struct gen_pool *gen_pool_create(int, int);
-extern int gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
-extern void gen_pool_destroy(struct gen_pool *);
-extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
-extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
+void gen_pool_free(struct gen_pool *pool, unsigned long addr, size_t size);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 1923f14..0761079 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -16,53 +16,80 @@
#include linux/genalloc.h
+/* General purpose special memory pool descriptor. */
+struct gen_pool {
+ rwlock_t lock; /* protects chunks list */
+ struct list_head chunks;/* list of chunks in this pool */
+ unsigned order; /* minimum allocation order */
+};
+
+/* General purpose special memory pool chunk descriptor. */
+struct gen_pool_chunk {
+ spinlock_t lock;/* protects bits */
+ struct list_head next_chunk;/* next chunk in pool */
+ unsigned long start;/* start of memory chunk */
+ unsigned long size; /* number of bits */
+ unsigned long bits[0]; /* bitmap for allocating memory chunk */
+};
+
+
/**
- * gen_pool_create - create a new special memory pool
- * @min_alloc_order: log base 2 of number of bytes each bitmap bit represents
- * @nid: node id of the node the pool structure should be allocated on, or -1
+ * gen_pool_create() - create a new special memory pool
+ * @order: Log base 2 of number of bytes each bitmap bit
+ * represents.
+ * @nid: Node id of the node the pool structure should be allocated
+ * on, or -1. This will be also used for other allocations.
*
* Create a new special memory pool that can be used to manage special purpose
* memory not managed by the regular kmalloc/kfree interface.
*/
-struct gen_pool *gen_pool_create(int min_alloc_order, int nid)
+struct gen_pool *__must_check gen_pool_create(unsigned order, int nid)
{
struct gen_pool *pool;
- pool = kmalloc_node(sizeof(struct gen_pool), GFP_KERNEL, nid);
- if (pool != NULL) {
+ if (WARN_ON(order = BITS_PER_LONG))
+ return NULL;
+
+ pool = kmalloc_node(sizeof *pool, GFP_KERNEL, nid);
+ if
[PATCHv8 00/12] Contiguous Memory Allocator
Hello everyone, This is yet another version of CMA this time stripped from a lot of code and with working migration implementation. The Contiguous Memory Allocator (CMA) makes it possible for device drivers to allocate big contiguous chunks of memory after the system has booted. For more information see 7th patch in the set. This version fixes some things Kamezawa suggested plus it separates code that uses MIGRATE_CMA from the rest of the code. This I hope will help to grasp the overall idea of CMA. The current version is just an allocator that handles allocation of contiguous memory blocks. The difference between this patchset and Kamezawa's alloc_contig_pages() are: 1. alloc_contig_pages() requires MAX_ORDER alignment of allocations which may be unsuitable for embeded systems where a few MiBs are required. Lack of the requirement on the alignment means that several threads might try to access the same pageblock/page. To prevent this from happening CMA uses a mutex so that only one cm_alloc()/cm_free() function may run at one point. 2. CMA may use its own migratetype (MIGRATE_CMA) which behaves similarly to ZONE_MOVABLE but can be put in arbitrary places. This is required for us since we need to define two disjoint memory ranges inside system RAM. (ie. in two memory banks (do not confuse with nodes)). 3. alloc_contig_pages() scans memory in search for range that could be migrated. CMA on the other hand maintains its own allocator to decide where to allocate memory for device drivers and then tries to migrate pages from that part if needed. This is not strictly required but I somehow feel it might be faster. Links to previous versions of the patchset: v7: http://article.gmane.org/gmane.linux.kernel.mm/55626 v6: http://article.gmane.org/gmane.linux.kernel.mm/55626 v5: (intentionally left out as CMA v5 was identical to CMA v4) v4: http://article.gmane.org/gmane.linux.kernel.mm/52010 v3: http://article.gmane.org/gmane.linux.kernel.mm/51573 v2: http://article.gmane.org/gmane.linux.kernel.mm/50986 v1: http://article.gmane.org/gmane.linux.kernel.mm/50669 Changelog: v8: 1. The alloc_contig_range() function has now been separated from CMA and put in page_allocator.c. This function tries to migrate all LRU pages in specified range and then allocate the range using alloc_contig_freed_pages(). 2. Support for MIGRATE_CMA has been separated from the CMA code. I have not tested if CMA works with ZONE_MOVABLE but I see no reasons why it shouldn't. 3. I have added a @private argument when creating CMA contexts so that one can reserve memory and not share it with the rest of the system. This way, CMA acts only as allocation algorithm. v7: 1. A lot of functionality that handled driver-allocator_context mapping has been removed from the patchset. This is not to say that this code is not needed, it's just not worth posting everything in one patchset. Currently, CMA is just an allocator. It uses it's own migratetype (MIGRATE_CMA) for defining ranges of pageblokcs which behave just like ZONE_MOVABLE but dispite the latter can be put in arbitrary places. 2. The migration code that was introduced in the previous version actually started working. v6: 1. Most importantly, v6 introduces support for memory migration. The implementation is not yet complete though. Migration support means that when CMA is not using memory reserved for it, page allocator can allocate pages from it. When CMA wants to use the memory, the pages have to be moved and/or evicted as to make room for CMA. To make it possible it must be guaranteed that only movable and reclaimable pages are allocated in CMA controlled regions. This is done by introducing a MIGRATE_CMA migrate type that guarantees exactly that. Some of the migration code is borrowed from Kamezawa Hiroyuki's alloc_contig_pages() implementation. The main difference is that thanks to MIGRATE_CMA migrate type CMA assumes that memory controlled by CMA are is always movable or reclaimable so that it makes allocation decisions regardless of the whether some pages are actually allocated and migrates them if needed. The most interesting patches from the patchset that implement the functionality are: 09/13: mm: alloc_contig_free_pages() added 10/13: mm: MIGRATE_CMA migration type added 11/13: mm: MIGRATE_CMA isolation functions added 12/13: mm: cma: Migration support added [wip] Currently, kernel panics in some situations which I am trying to investigate. 2. cma_pin() and cma_unpin() functions has been added (after a conversation with Johan Mossberg). The idea is that whenever hardware does not use the
Re: [PATCH] bttv: fix mutex use before init
Em 15-12-2010 16:44, Chris Clayton escreveu:
On Tuesday 14 December 2010, Brandon Philips wrote:
On 17:13 Sun 12 Dec 2010, Torsten Kaiser wrote:
* change fh-cap.vb_lock in bttv_open() AND radio_open() to
btv-init.cap.vb_lock
* add a mutex_init(btv-init.cap.vb_lock) to the setup of init in
bttv_probe()
That seems like a reasonable suggestion. An openSUSE user submitted this
bug to our tracker too. Here is the patch I am having him test.
Would you mind testing it?
From 456dc0ce36db523c4c0c8a269f4eec43a72de1dc Mon Sep 17 00:00:00 2001
From: Brandon Philips bphil...@suse.de
Date: Mon, 13 Dec 2010 16:21:55 -0800
Subject: [PATCH] bttv: fix locking for btv-init
Fix locking for the btv-init by using btv-init.cap.vb_lock and in the
process fix uninitialized deref introduced in c37db91fd0d.
Signed-off-by: Brandon Philips bphil...@suse.de
Hi Brandon all,
While your patch fixes the issue, it has some other troubles, like to the
presence of
lock code at free_btres_lock(). It is possible to fix, but the better is to just
use the core-assisted locking schema. This way, V4L2 core will serialize access
to all
ioctl's/open/close/mmap/read/poll operations, avoiding to have two processes
accessing
the hardware at the same time. Also, as there's just one lock, instead of 3,
there's no
risk of dead locks.
The net result is a cleaner code, with just one lock.
I tested the patch here with an bttv-based STB board (card=3, tuner=6), and it
worked fine for me.
Could you please test if this fixes the issue?
PS.: The patch is based against the bkl_removal patches, at my linux-next tree:
http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=commit;h=673eb9ff33e26ee6f4278cdab06749aef1bbef5b
(I just created the bkl_removal branch, so, it may take some time for you to
see at the kernel.org
mirrors, but it is basically changeset 673eb9ff. You may also just apply it on
the top of the master
branch of my linux-next tree).
---
[media] bttv: Fix locking issues due to BKL removal code
The BKL removal patch added a condition where the code would try to use a
non-initialized
lock. While a patch just addressing the issue is possible, there are some other
troubles,
like to the presence of lock code at free_btres_lock(), called on some places
with the lock
already taken. It is possible to fix, but the better is to just use the
core-assisted
locking schema.
This way, V4L2 core will serialize access to all
ioctl's/open/close/mmap/read/poll
operations, avoiding to have two processes accessing the hardware at the same
time.
Also, as there's just one lock, instead of 3, there's no risk of dead locks.
Tested with bttv STB, Gateway P/N 6000699 (card 3, tuner 6).
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c
index a529619..25e1ca0 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -854,7 +854,6 @@ int check_alloc_btres_lock(struct bttv *btv, struct bttv_fh
*fh, int bit)
xbits |= RESOURCE_VIDEO_READ | RESOURCE_VIDEO_STREAM;
/* is it free? */
- mutex_lock(btv-lock);
if (btv-resources xbits) {
/* no, someone else uses it */
goto fail;
@@ -884,11 +883,9 @@ int check_alloc_btres_lock(struct bttv *btv, struct
bttv_fh *fh, int bit)
/* it's free, grab it */
fh-resources |= bit;
btv-resources |= bit;
- mutex_unlock(btv-lock);
return 1;
fail:
- mutex_unlock(btv-lock);
return 0;
}
@@ -940,7 +937,6 @@ void free_btres_lock(struct bttv *btv, struct bttv_fh *fh,
int bits)
/* trying to free ressources not allocated by us ... */
printk(bttv: BUG! (btres)\n);
}
- mutex_lock(btv-lock);
fh-resources = ~bits;
btv-resources = ~bits;
@@ -951,8 +947,6 @@ void free_btres_lock(struct bttv *btv, struct bttv_fh *fh,
int bits)
if (0 == (bits VBI_RESOURCES))
disclaim_vbi_lines(btv);
-
- mutex_unlock(btv-lock);
}
/* --- */
@@ -1713,28 +1707,20 @@ static int bttv_prepare_buffer(struct videobuf_queue
*q,struct bttv *btv,
/* Make sure tvnorm and vbi_end remain consistent
until we're done. */
- mutex_lock(btv-lock);
norm = btv-tvnorm;
/* In this mode capturing always starts at defrect.top
(default VDELAY), ignoring cropping parameters. */
if (btv-vbi_end bttv_tvnorms[norm].cropcap.defrect.top) {
- mutex_unlock(btv-lock);
return -EINVAL;
}
- mutex_unlock(btv-lock);
-
c.rect = bttv_tvnorms[norm].cropcap.defrect;
} else {
-
Re: Question about libv4lconvert.
On Wed, 15 Dec 2010 21:10:52 +0100
Hans de Goede hdego...@redhat.com wrote:
Hi,
Hi Hans, thanks for the quick reply.
On 12/15/2010 05:11 PM, Antonio Ospite wrote:
Hi,
I am taking a look at libv4lconvert, and I have a question about the
logic in v4lconvert_convert_pixfmt(), in some conversion switches there
is code like this:
case V4L2_PIX_FMT_GREY:
switch (dest_pix_fmt) {
case V4L2_PIX_FMT_RGB24:
case V4L2_PIX_FMT_BGR24:
v4lconvert_grey_to_rgb24(src, dest, width, height);
break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
v4lconvert_grey_to_yuv420(src, dest, fmt);
break;
}
if (src_size (width * height)) {
V4LCONVERT_ERR(short grey data frame\n);
errno = EPIPE;
result = -1;
}
break;
However the conversion routines which are going to be called seem to
assume that the buffers, in particular the source buffer, are of the
correct full frame size when looping over them.
Correct, because they trust that the kernel drivers have allocated large
enough buffers to hold a valid frame which is a safe assumption.
Maybe this was the piece I was missing: even a partial (useful) frame
comes in a full size buffer, right? If so then the current logic is sane
indeed; and if the current assumption in conversion routines is
contradicted then it must be due to a defect related to the kernel
driver.
My question is: shouldn't the size check now at the end of the case
block be at the _beginning_ of it instead, so to detect a short frame
before conversion and avoid a possible out of bound access inside the
conversion routine?
This is done this way deliberately, this has to do with how the EPIPE
errno variable is used in a special way.
An error return from v4lconvert_convert with an errno of EPIPE means
I managed to get some data for you but not an entire frame. The upper
layers of libv4l will respond to this by retrying (getting another frame),
but only a limited number of times. Once the retries are exceeded they
will simply pass along whatever they did manage to get.
Ah, that's why you do the conversion even on partial frames, I think I
see now.
The reason for this is that there can be bus errors or vsync issues (*),
which lead to a short frame, which are intermittent errors. So detecting
them and getting another frame is a good thing to do because usually the
next frame will be fine. However sometimes there are cases where every
single frame is a short frame, for example the zc3xx driver used to
deliver jpeg's with only 224 lines of data when running at 320x240 with
some sensors. Now one can argue that this is a driver issue, and it is
but it still happens in this case it is much better to pass along
the 224 lines which we did get, then to make this a fatal error.
Note that due to the retries the user will get a much lower framerate,
which together with the missing lines at the bottom + printing
of error messages will hopefully be enough for the user to report
a bug to us, despite him/her getting some picture.
I hope this explains.
It does, thanks a lot.
Regards,
Hans
*) While starting the stream it may take several frames for vsync to
properly lock in some cases.
Regards,
Antonio.
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
pgpD6KnjG9Md8.pgp
Description: PGP signature
Re: tm6000 and IR
Hi Stefan The nec initiation looks right and must adding code for tm5600/6000 (going over message pipe). I haven't USB stick with tm5600/6000 for test. Need people with this TV cards. then add a todo line. I'll do it. rc5 need some code for tm6010 (for tm5600/6000 are the hack). I didn't touch this code because I haven't RC5 remotes and tm5600/6000 And the logic for your remote control is unused for the second variant, but ir-rc_type = rc_type are o.k. but the line ir-rc_type = rc_type; are o.k. I think your mean is wrong. Our IR remotes send extended NEC it is 4 bytes. We removed inverted 4 byte and now we have 3 bytes from remotes. I think we must have full RCMAP with this 3 bytes from remotes. And use this remotes with some different IR recievers like some TV cards and LIRC-hardware and other. No need different RCMAP for the same remotes to different IR recievers like now. Your change doesn't work with my terratec remote control !! I'll try solve this problem don't worry. If we use second variant I can't use RCMAP_BEHOLD because it has full 3 bytes scancodes. As you wrote. And if you use two bytes rc map table. We have add filter for address and commands to pass all. With an external tool can change the map ( ir_keytable). Why you will use more than two bytes. With my last code this tool is working. When you call change_protocol new value of address stored. But if a keytable of remotes hasn't full scancodes it doesn't work How to main IR core search scancodes in RCMAP keytable? I think it search full equal scancode value with returned from tm6000. Example: defined keytable: 0x86 0x6B 0x00 tm6000 read IR data 0x86 0x00 When return 0x86 0x00 to IR core a key is unknown because 0x86 0x6B 0x00 != 0x86 0x00 I think we can have two different solutions: 1. My variant. When init IR tm6000, get full address from a keytable, store it. After key filtering restore full scancode and return it to IR core - 0x86 0x6B 0x00. A keytable must has really full scancodes. 2. More simple. A keytable has only data byte. Get IR data and return only data byte without filtering because a keytable hasn't this information. This is bad the TV card can do some task by other IR remotes. Or add some place where stored filter information and update filter when keytable replaced. With my best regards, Dmitry. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L/DVB: Add support for M5MOLS Mega Pixel camera
Hi Hans,
Any comments? Just ping.
Thanks.
Regards,
HeungJun Kim
2010-12-10 오후 4:40, Kim, HeungJun 쓴 글:
This patch adds support for M5MOLS Mega Pixel Fujitsu camera sensor.
--
Hello,
This is an initial version of I2C/V4L2 subdev driver for M5MOLS camera
sensor using MIPI interface from Fujitsu. This sensor supports various
resolution at various fps on Monitoring(as we know preview),
Preview(camcording), Capture(JPEG) mode. And, each mode supports
different resolution range. Moreover, there are many image processing
controls(flip, rotation, focus, zoom) and effects(even like a face
recognitions). It has been tested with samsung/fimc and s5p-fimc driver
on Aquila board. And this driver changed until now.
This version supports just Monitoring mode at it's own many resolutions.
But, there are many features in this sensor, and it's so hard to express
all this features using a current CID or something else. so, I hope
this initial version is merged soon in v4l/dvb, and then I wish the
new needed CID is being added for this, and any other devices in addition.
Any ideas are appreciated, Let me know.
Thanks.
Regards,
HeungJun Kim
Signed-off-by: Heungjun Kim riverful@samsung.com
Signed-off-by: Kyungmin Part kyungmin.p...@samsung.com
---
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile |1 +
drivers/media/video/m5mols.c | 1410
++
include/media/m5mols.h | 31 +
4 files changed, 1448 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/m5mols.c
create mode 100644 include/media/m5mols.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 6830d28..f2e6080 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -712,6 +712,12 @@ config VIDEO_SR030PC30
---help---
This driver supports SR030PC30 VGA camera from Siliconfile
+config VIDEO_M5MOLS
+ tristate Fujitsu M5MOLS 8M Pixel sensor support
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This driver supports M5MOLS 8 MEGA Pixel camera from Fujitsu
+
config VIDEO_VIA_CAMERA
tristate VIAFB camera controller support
depends on FB_VIA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index af79d47..c76e44f 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30)+= sr030pc30.o
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o
obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074.o
obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o
diff --git a/drivers/media/video/m5mols.c b/drivers/media/video/m5mols.c
new file mode 100644
index 000..9f5c445
--- /dev/null
+++ b/drivers/media/video/m5mols.c
@@ -0,0 +1,1410 @@
+/*
+ * Driver for M5MOLS 8M Pixel camera sensor with ISP
+ *
+ * Copyright (C) 2010 Samsung Electronics Co., Ltd
+ * Author: HeungJun Kim, riverful@samsung.com
+ *
+ * Copyright (C) 2009 Samsung Electronics Co., Ltd
+ * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/slab.h
+#include linux/regulator/consumer.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+#include media/m5mols.h
+
+static int debug;
+module_param(debug, int, 0644);
+
+/* MACRO */
+#define e_check_w(fn, cat, byte, val, bitwidth) do {\
+ int ret;\
+ ret = (int)(fn);\
+ if ((ret) 0) {\
+ dev_err(client-dev, fail i2c WRITE [%s] - \
+ category:0x%02x, \
+ bytes:0x%02x, \
+ value:0x%02x\n, \
+ (bitwidth), \
+ (cat), (byte), (u32)val); \
+ return ret; \
+ } \
+} while (0)
+
+#define e_check_r(fn, cat, byte, val, bitwidth) do {\
+ int ret;\
+ ret = (int)(fn);\
+ if ((ret) 0) {\
+ dev_err(client-dev, fail i2c READ [%s] -\
+ category:0x%02x,
Re: [PATCH] V4L/DVB: Add support for M5MOLS Mega Pixel camera
Thanks for the reminder, I missed this patch.
Review comments are below.
On Friday, December 10, 2010 08:40:27 Kim, HeungJun wrote:
This patch adds support for M5MOLS Mega Pixel Fujitsu camera sensor.
--
Hello,
This is an initial version of I2C/V4L2 subdev driver for M5MOLS camera
sensor using MIPI interface from Fujitsu. This sensor supports various
resolution at various fps on Monitoring(as we know preview),
Preview(camcording), Capture(JPEG) mode. And, each mode supports
different resolution range. Moreover, there are many image processing
controls(flip, rotation, focus, zoom) and effects(even like a face
recognitions). It has been tested with samsung/fimc and s5p-fimc driver
on Aquila board. And this driver changed until now.
This version supports just Monitoring mode at it's own many resolutions.
But, there are many features in this sensor, and it's so hard to express
all this features using a current CID or something else. so, I hope
this initial version is merged soon in v4l/dvb, and then I wish the
new needed CID is being added for this, and any other devices in addition.
Any ideas are appreciated, Let me know.
Thanks.
Regards,
HeungJun Kim
Signed-off-by: Heungjun Kim riverful@samsung.com
Signed-off-by: Kyungmin Part kyungmin.p...@samsung.com
---
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile |1 +
drivers/media/video/m5mols.c | 1410
++
include/media/m5mols.h | 31 +
4 files changed, 1448 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/m5mols.c
create mode 100644 include/media/m5mols.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 6830d28..f2e6080 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -712,6 +712,12 @@ config VIDEO_SR030PC30
---help---
This driver supports SR030PC30 VGA camera from Siliconfile
+config VIDEO_M5MOLS
+ tristate Fujitsu M5MOLS 8M Pixel sensor support
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This driver supports M5MOLS 8 MEGA Pixel camera from Fujitsu
+
config VIDEO_VIA_CAMERA
tristate VIAFB camera controller support
depends on FB_VIA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index af79d47..c76e44f 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30)+= sr030pc30.o
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o
obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074.o
obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o
diff --git a/drivers/media/video/m5mols.c b/drivers/media/video/m5mols.c
new file mode 100644
index 000..9f5c445
--- /dev/null
+++ b/drivers/media/video/m5mols.c
@@ -0,0 +1,1410 @@
+/*
+ * Driver for M5MOLS 8M Pixel camera sensor with ISP
+ *
+ * Copyright (C) 2010 Samsung Electronics Co., Ltd
+ * Author: HeungJun Kim, riverful@samsung.com
+ *
+ * Copyright (C) 2009 Samsung Electronics Co., Ltd
+ * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/slab.h
+#include linux/regulator/consumer.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+#include media/m5mols.h
+
+static int debug;
+module_param(debug, int, 0644);
+
+/* MACRO */
+#define e_check_w(fn, cat, byte, val, bitwidth) do {\
+ int ret;\
+ ret = (int)(fn);\
+ if ((ret) 0) {\
+ dev_err(client-dev, fail i2c WRITE [%s] - \
+ category:0x%02x, \
+ bytes:0x%02x, \
+ value:0x%02x\n, \
+ (bitwidth), \
+ (cat), (byte), (u32)val); \
+ return ret; \
+ } \
+} while (0)
+
+#define e_check_r(fn, cat, byte, val, bitwidth) do {\
+ int ret;\
+ ret = (int)(fn);\
+ if ((ret) 0) {\
+ dev_err(client-dev, fail i2c READ [%s] -\
+
Re: Question about libv4lconvert.
Hi,
On 12/16/2010 12:49 AM, Antonio Ospite wrote:
On Wed, 15 Dec 2010 21:10:52 +0100
Hans de Goedehdego...@redhat.com wrote:
Hi,
Hi Hans, thanks for the quick reply.
On 12/15/2010 05:11 PM, Antonio Ospite wrote:
Hi,
I am taking a look at libv4lconvert, and I have a question about the
logic in v4lconvert_convert_pixfmt(), in some conversion switches there
is code like this:
case V4L2_PIX_FMT_GREY:
switch (dest_pix_fmt) {
case V4L2_PIX_FMT_RGB24:
case V4L2_PIX_FMT_BGR24:
v4lconvert_grey_to_rgb24(src, dest, width, height);
break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
v4lconvert_grey_to_yuv420(src, dest, fmt);
break;
}
if (src_size (width * height)) {
V4LCONVERT_ERR(short grey data frame\n);
errno = EPIPE;
result = -1;
}
break;
However the conversion routines which are going to be called seem to
assume that the buffers, in particular the source buffer, are of the
correct full frame size when looping over them.
Correct, because they trust that the kernel drivers have allocated large
enough buffers to hold a valid frame which is a safe assumption.
Maybe this was the piece I was missing: even a partial (useful) frame
comes in a full size buffer, right?
Right.
If so then the current logic is sane
indeed; and if the current assumption in conversion routines is
contradicted then it must be due to a defect related to the kernel
driver.
Correct, if the kernel allocates (and thus we mmap) too small buffers for
the current video fmt + dimensions then that is a kernel bug.
snip
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
