[PATCH v2] media: ov6650: convert to standalone v4l2 subdevice
Remove the soc_camera dependencies and move the diver to i2c
Lost features, fortunately not used or not critical on test platform:
- soc_camera power on/off callback - replaced with clock enable/disable
only, no support for platform provided regulators nor power callback,
- soc_camera sense request - replaced with arbitrarily selected default
master clock rate and pixel clock limit, no support for platform
requested values,
- soc_camera board flags - no support for platform requested mbus config
tweaks.
Created against linux-4.12-rc2.
Tested on Amstrad Delta with now out of tree but still locally
maintained omap1_camera host driver.
Signed-off-by: Janusz Krzysztofik <jmkrzy...@gmail.com>
---
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/{soc_camera => }/ov6650.c | 77 +
drivers/media/i2c/soc_camera/Kconfig| 6 ---
drivers/media/i2c/soc_camera/Makefile | 1 -
5 files changed, 35 insertions(+), 61 deletions(-)
rename drivers/media/i2c/{soc_camera => }/ov6650.c (92%)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index fd181c9..a3c1dff 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -562,6 +562,17 @@ config VIDEO_OV5647
To compile this driver as a module, choose M here: the
module will be called ov5647.
+config VIDEO_OV6650
+ tristate "OmniVision OV6650 sensor support"
+ depends on I2C && VIDEO_V4L2
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV6650 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov6650.
+
config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 62323ec..be58ac0 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
+obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/soc_camera/ov6650.c b/drivers/media/i2c/ov6650.c
similarity index 92%
rename from drivers/media/i2c/soc_camera/ov6650.c
rename to drivers/media/i2c/ov6650.c
index dbd6d92..2f7b7a7 100644
--- a/drivers/media/i2c/soc_camera/ov6650.c
+++ b/drivers/media/i2c/ov6650.c
@@ -1,5 +1,5 @@
/*
- * V4L2 SoC Camera driver for OmniVision OV6650 Camera Sensor
+ * V4L2 subdevice driver for OmniVision OV6650 Camera Sensor
*
* Copyright (C) 2010 Janusz Krzysztofik <jkrzy...@tis.icnet.pl>
*
@@ -31,9 +31,9 @@
#include
#include
-#include
#include
#include
+#include
/* Register definitions */
#define REG_GAIN 0x00/* range 00 - 3F */
@@ -426,10 +426,15 @@ static int ov6650_set_register(struct v4l2_subdev *sd,
static int ov6650_s_power(struct v4l2_subdev *sd, int on)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
- struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov6650 *priv = to_ov6650(client);
+ int ret = 0;
- return soc_camera_set_power(>dev, ssdd, priv->clk, on);
+ if (on)
+ ret = v4l2_clk_enable(priv->clk);
+ else
+ v4l2_clk_disable(priv->clk);
+
+ return ret;
}
static int ov6650_get_selection(struct v4l2_subdev *sd,
@@ -471,14 +476,13 @@ static int ov6650_set_selection(struct v4l2_subdev *sd,
sel->target != V4L2_SEL_TGT_CROP)
return -EINVAL;
- rect.left = ALIGN(rect.left, 2);
- rect.width = ALIGN(rect.width, 2);
- rect.top= ALIGN(rect.top,2);
- rect.height = ALIGN(rect.height, 2);
- soc_camera_limit_side(, ,
- DEF_HSTRT << 1, 2, W_CIF);
- soc_camera_limit_side(, ,
- DEF_VSTRT << 1, 2, H_CIF);
+ v4l_bound_align_image(, 2, W_CIF, 1,
+ , 2, H_CIF, 1, 0);
+ v4l_bound_align_image(, DEF_HSTRT << 1,
+ (DEF_HSTRT << 1) + W_CIF - (__s32)rect.width, 1,
+ , DEF_VSTRT << 1,
+ (DEF_VSTRT << 1) + H_CIF - (__s32)rect.height, 1,
+ 0);
ret = ov6650_reg_write(client, REG_HSTRT, rect.left >> 1);
if (!ret) {
@@ -547,8 +551,6 @@ static u8 to_clkrc(struct v4l2_fract *timeperframe,
static int ov6650_s_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt *mf)
{
struct i2
Re: [PATCH] [media] ov6650: convert to standalone v4l2 subdevice
On Friday 16 June 2017 12:16:21 Sakari Ailus wrote: > Hi Janusz, > > Thanks for the patch. A few comments below. > > On Fri, Jun 16, 2017 at 12:52:43AM +0200, Janusz Krzysztofik wrote: > > Remove the soc_camera dependencies. > > > > Lost features, fortunately not used or not critical on test platform: > > - soc_camera power on/off callback - replaced with clock enable/disable > > only, no support for platform provided regulators nor power callback, ... > > - return soc_camera_set_power(>dev, ssdd, priv->clk, on); > > + if (on) > > + ret = v4l2_clk_enable(priv->clk); > > + else > > + v4l2_clk_disable(priv->clk); > > It'd be nicer to use the clock framework. Although I'm certainly fine with > v4l2_clk for now, one thing at a time... I have that in my queue, but the test platform I'm using does not support CCF yet so there is no easy way for the host camera interface driver to provide a compatible clock other than v4l2_clk based. Thanks, Janusz
[PATCH] [media] ov6650: convert to standalone v4l2 subdevice
Remove the soc_camera dependencies.
Lost features, fortunately not used or not critical on test platform:
- soc_camera power on/off callback - replaced with clock enable/disable
only, no support for platform provided regulators nor power callback,
- soc_camera sense request - replaced with arbitrarily selected default
master clock rate and pixel clock limit, no support for platform
requested values,
- soc_camera board flags - no support for platform requested mbus config
tweaks.
Created against linux-4.12-rc2.
Tested on Amstrad Delta with now out of tree but still locally
maintained omap1_camera host driver.
Signed-off-by: Janusz Krzysztofik <jmkrzy...@gmail.com>
---
drivers/media/i2c/soc_camera/ov6650.c | 75 ++-
1 file changed, 22 insertions(+), 53 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov6650.c
b/drivers/media/i2c/soc_camera/ov6650.c
index dbd6d92..20defcb88 100644
--- a/drivers/media/i2c/soc_camera/ov6650.c
+++ b/drivers/media/i2c/soc_camera/ov6650.c
@@ -31,9 +31,9 @@
#include
#include
-#include
#include
#include
+#include
/* Register definitions */
#define REG_GAIN 0x00/* range 00 - 3F */
@@ -426,10 +426,15 @@ static int ov6650_set_register(struct v4l2_subdev *sd,
static int ov6650_s_power(struct v4l2_subdev *sd, int on)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
- struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov6650 *priv = to_ov6650(client);
+ int ret = 0;
- return soc_camera_set_power(>dev, ssdd, priv->clk, on);
+ if (on)
+ ret = v4l2_clk_enable(priv->clk);
+ else
+ v4l2_clk_disable(priv->clk);
+
+ return ret;
}
static int ov6650_get_selection(struct v4l2_subdev *sd,
@@ -471,14 +476,13 @@ static int ov6650_set_selection(struct v4l2_subdev *sd,
sel->target != V4L2_SEL_TGT_CROP)
return -EINVAL;
- rect.left = ALIGN(rect.left, 2);
- rect.width = ALIGN(rect.width, 2);
- rect.top= ALIGN(rect.top,2);
- rect.height = ALIGN(rect.height, 2);
- soc_camera_limit_side(, ,
- DEF_HSTRT << 1, 2, W_CIF);
- soc_camera_limit_side(, ,
- DEF_VSTRT << 1, 2, H_CIF);
+ v4l_bound_align_image(, 2, W_CIF, 1,
+ , 2, H_CIF, 1, 0);
+ v4l_bound_align_image(, DEF_HSTRT << 1,
+ (DEF_HSTRT << 1) + W_CIF - (__s32)rect.width, 1,
+ , DEF_VSTRT << 1,
+ (DEF_VSTRT << 1) + H_CIF - (__s32)rect.height, 1,
+ 0);
ret = ov6650_reg_write(client, REG_HSTRT, rect.left >> 1);
if (!ret) {
@@ -547,8 +551,6 @@ static u8 to_clkrc(struct v4l2_fract *timeperframe,
static int ov6650_s_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt *mf)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
- struct soc_camera_device *icd = v4l2_get_subdev_hostdata(sd);
- struct soc_camera_sense *sense = icd->sense;
struct ov6650 *priv = to_ov6650(client);
bool half_scale = !is_unscaled_ok(mf->width, mf->height, >rect);
struct v4l2_subdev_selection sel = {
@@ -640,32 +642,10 @@ static int ov6650_s_fmt(struct v4l2_subdev *sd, struct
v4l2_mbus_framefmt *mf)
}
priv->half_scale = half_scale;
- if (sense) {
- if (sense->master_clock == 800) {
- dev_dbg(>dev, "8MHz input clock\n");
- clkrc = CLKRC_6MHz;
- } else if (sense->master_clock == 1200) {
- dev_dbg(>dev, "12MHz input clock\n");
- clkrc = CLKRC_12MHz;
- } else if (sense->master_clock == 1600) {
- dev_dbg(>dev, "16MHz input clock\n");
- clkrc = CLKRC_16MHz;
- } else if (sense->master_clock == 2400) {
- dev_dbg(>dev, "24MHz input clock\n");
- clkrc = CLKRC_24MHz;
- } else {
- dev_err(>dev,
- "unsupported input clock, check platform
data\n");
- return -EINVAL;
- }
- mclk = sense->master_clock;
- priv->pclk_limit = sense->pixel_clock_max;
- } else {
- clkrc = CLKRC_24MHz;
- mclk = 2400;
- priv->pclk_limit = 0;
- dev_dbg(>dev, "using default 24MHz input clock\n");
- }
+ clkrc = CLKRC_12MHz;
+ mclk = 1200;
+ priv->pclk_limit = 1334000;
+ dev_dbg(>dev, "using 12MHz input cloc
[RFC] [PATCH 0/3] media: an attempt to refresh omap1_camera driver
As requested by media subsystem maintainers, here is an attempt to convert the omap1_camera driver to the vb2 framework. Also, conversion to the dmaengine framework, long awaited by ARM/OMAP maintainers, is done. Next, I'm going to approach removal of soc-camera dependency. Please let me know how much time I have for that, i.e., when the soc-camera framework is going to be depreciated. Thanks, Janusz Janusz Krzysztofik (3): staging: media: omap1: drop videobuf-dma-sg mode staging: media: omap1: convert to videobuf2 staging: media: omap1: use dmaengine drivers/staging/media/omap1/Kconfig | 5 +- drivers/staging/media/omap1/omap1_camera.c | 948 +-- include/linux/platform_data/media/omap1_camera.h | 9 - 3 files changed, 217 insertions(+), 745 deletions(-) -- 2.7.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
[RFC] [PATCH 1/3] staging: media: omap1: drop videobuf-dma-sg mode
For over 20 last kernel versions the driver has been able to allocate
DMA buffers in videobuf-dma-contig mode without any issues. Drop the
no longer needed sg mode in preparation for conversion to videobuf2.
Created and tested on Amstrad Delta against Linux-4.7-rc3 with
omap1_camera and ov6650 fixes applied.
Signed-off-by: Janusz Krzysztofik <jmkrzy...@gmail.com>
---
drivers/staging/media/omap1/Kconfig | 1 -
drivers/staging/media/omap1/omap1_camera.c | 445 ---
include/linux/platform_data/media/omap1_camera.h | 9 -
3 files changed, 77 insertions(+), 378 deletions(-)
diff --git a/drivers/staging/media/omap1/Kconfig
b/drivers/staging/media/omap1/Kconfig
index 6cfab3a..e2a39f5 100644
--- a/drivers/staging/media/omap1/Kconfig
+++ b/drivers/staging/media/omap1/Kconfig
@@ -4,7 +4,6 @@ config VIDEO_OMAP1
depends on ARCH_OMAP1
depends on HAS_DMA
select VIDEOBUF_DMA_CONTIG
- select VIDEOBUF_DMA_SG
---help---
This is a v4l2 driver for the TI OMAP1 camera interface
diff --git a/drivers/staging/media/omap1/omap1_camera.c
b/drivers/staging/media/omap1/omap1_camera.c
index 9b6140a..37ef4da 100644
--- a/drivers/staging/media/omap1/omap1_camera.c
+++ b/drivers/staging/media/omap1/omap1_camera.c
@@ -32,13 +32,12 @@
#include
#include
#include
-#include
#include
#define DRIVER_NAME"omap1-camera"
-#define DRIVER_VERSION "0.0.2"
+#define DRIVER_VERSION "0.0.3"
#define OMAP_DMA_CAMERA_IF_RX 20
@@ -114,22 +113,18 @@
#define FIFO_SHIFT __fls(FIFO_SIZE)
#define DMA_BURST_SHIFT(1 + OMAP_DMA_DATA_BURST_4)
-#define DMA_BURST_SIZE (1 << DMA_BURST_SHIFT)
+#define DMA_BURST_SIZE BIT(DMA_BURST_SHIFT)
#define DMA_ELEMENT_SHIFT OMAP_DMA_DATA_TYPE_S32
-#define DMA_ELEMENT_SIZE (1 << DMA_ELEMENT_SHIFT)
+#define DMA_ELEMENT_SIZE BIT(DMA_ELEMENT_SHIFT)
-#define DMA_FRAME_SHIFT_CONTIG (FIFO_SHIFT - 1)
-#define DMA_FRAME_SHIFT_SG DMA_BURST_SHIFT
-
-#define DMA_FRAME_SHIFT(x) ((x) == OMAP1_CAM_DMA_CONTIG ? \
- DMA_FRAME_SHIFT_CONTIG : \
- DMA_FRAME_SHIFT_SG)
-#define DMA_FRAME_SIZE(x) (1 << DMA_FRAME_SHIFT(x))
+#define DMA_FRAME_SHIFT(FIFO_SHIFT - 1)
+#define DMA_FRAME_SIZE BIT(DMA_FRAME_SHIFT)
#define DMA_SYNC OMAP_DMA_SYNC_FRAME
#define THRESHOLD_LEVELDMA_FRAME_SIZE
-
+#define OMAP1_CAMERA_MIN_BUF_COUNT \
+ 3
#define MAX_VIDEO_MEM 4 /* arbitrary video memory limit in MB */
@@ -140,12 +135,8 @@
/* buffer for one video frame */
struct omap1_cam_buf {
struct videobuf_buffer vb;
- u32 code;
+ u32 code;
int inwork;
- struct scatterlist *sgbuf;
- int sgcount;
- int bytes_left;
- enum videobuf_state result;
};
struct omap1_cam_dev {
@@ -170,11 +161,6 @@ struct omap1_cam_dev {
struct omap1_cam_buf*active;
struct omap1_cam_buf*ready;
- enum omap1_cam_vb_mode vb_mode;
- int (*mmap_mapper)(struct videobuf_queue *q,
- struct videobuf_buffer *buf,
- struct vm_area_struct *vma);
-
u32 reg_cache[0];
};
@@ -205,13 +191,11 @@ static int omap1_videobuf_setup(struct videobuf_queue
*vq, unsigned int *count,
unsigned int *size)
{
struct soc_camera_device *icd = vq->priv_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
- struct omap1_cam_dev *pcdev = ici->priv;
*size = icd->sizeimage;
- if (!*count || *count < OMAP1_CAMERA_MIN_BUF_COUNT(pcdev->vb_mode))
- *count = OMAP1_CAMERA_MIN_BUF_COUNT(pcdev->vb_mode);
+ if (!*count || *count < OMAP1_CAMERA_MIN_BUF_COUNT)
+ *count = OMAP1_CAMERA_MIN_BUF_COUNT;
if (*size * *count > MAX_VIDEO_MEM * 1024 * 1024)
*count = (MAX_VIDEO_MEM * 1024 * 1024) / *size;
@@ -222,8 +206,7 @@ static int omap1_videobuf_setup(struct videobuf_queue *vq,
unsigned int *count,
return 0;
}
-static void free_buffer(struct videobuf_queue *vq, struct omap1_cam_buf *buf,
- enum omap1_cam_vb_mode vb_mode)
+static void free_buffer(struct videobuf_queue *vq, struct omap1_cam_buf *buf)
{
struct videobuf_buffer *vb = >vb;
@@ -231,16 +214,7 @@ static void free_buffer(struct videobuf_queue *vq, struct
omap1_cam_buf *buf,
[RFC] [PATCH 3/3] staging: media: omap1: use dmaengine
Created and tested on Amstrad Delta on top of Linux-4.7-rc3 with
"staging: media: omap1: convert to videobuf2" applied.
Signed-off-by: Janusz Krzysztofik <jmkrzy...@gmail.com>
---
drivers/staging/media/omap1/Kconfig| 2 +-
drivers/staging/media/omap1/omap1_camera.c | 432 +
2 files changed, 135 insertions(+), 299 deletions(-)
diff --git a/drivers/staging/media/omap1/Kconfig
b/drivers/staging/media/omap1/Kconfig
index 12f1d7a..0b8456d 100644
--- a/drivers/staging/media/omap1/Kconfig
+++ b/drivers/staging/media/omap1/Kconfig
@@ -1,7 +1,7 @@
config VIDEO_OMAP1
tristate "OMAP1 Camera Interface driver"
depends on VIDEO_DEV && SOC_CAMERA
- depends on ARCH_OMAP1
+ depends on ARCH_OMAP1 && DMA_OMAP
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
---help---
diff --git a/drivers/staging/media/omap1/omap1_camera.c
b/drivers/staging/media/omap1/omap1_camera.c
index 3761660..e22ba8a 100644
--- a/drivers/staging/media/omap1/omap1_camera.c
+++ b/drivers/staging/media/omap1/omap1_camera.c
@@ -33,11 +33,12 @@
#include
#include
-#include
+#include
+#include
#define DRIVER_NAME"omap1-camera"
-#define DRIVER_VERSION "0.0.4"
+#define DRIVER_VERSION "0.0.5"
#define OMAP_DMA_CAMERA_IF_RX 20
@@ -115,8 +116,8 @@
#define DMA_BURST_SHIFT(1 + OMAP_DMA_DATA_BURST_4)
#define DMA_BURST_SIZE BIT(DMA_BURST_SHIFT)
-#define DMA_ELEMENT_SHIFT OMAP_DMA_DATA_TYPE_S32
-#define DMA_ELEMENT_SIZE BIT(DMA_ELEMENT_SHIFT)
+#define DMA_ELEMENT_SIZE DMA_SLAVE_BUSWIDTH_4_BYTES
+#define DMA_ELEMENT_SHIFT __fls(DMA_ELEMENT_SIZE)
#define DMA_FRAME_SHIFT(FIFO_SHIFT - 1)
#define DMA_FRAME_SIZE BIT(DMA_FRAME_SHIFT)
@@ -124,7 +125,7 @@
#define THRESHOLD_LEVELDMA_FRAME_SIZE
#define OMAP1_CAMERA_MIN_BUF_COUNT \
- 3
+ 2
#define MAX_VIDEO_MEM 4 /* arbitrary video memory limit in MB */
@@ -145,7 +146,8 @@ struct omap1_cam_dev {
unsigned intirq;
void __iomem*base;
- int dma_ch;
+ struct dma_chan *dma_chan;
+ unsigned intdma_rq;
struct omap1_cam_platform_data *pdata;
unsigned long pflags;
@@ -156,10 +158,6 @@ struct omap1_cam_dev {
/* lock used to protect videobuf */
spinlock_t lock;
- /* Pointers to DMA buffers */
- struct omap1_cam_buf*active;
- struct omap1_cam_buf*ready;
-
struct vb2_alloc_ctx*alloc_ctx;
int sequence;
@@ -222,6 +220,16 @@ static int omap1_videobuf_setup(struct vb2_queue *vq,
unsigned int *count,
return 0;
}
+static int omap1_videobuf_init(struct vb2_buffer *vb)
+{
+ struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
+ struct omap1_cam_buf *buf = vb2_to_omap1_cam_buf(vbuf);
+
+ INIT_LIST_HEAD(>queue);
+
+ return 0;
+}
+
static int omap1_videobuf_prepare(struct vb2_buffer *vb)
{
struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
@@ -236,96 +244,27 @@ static int omap1_videobuf_prepare(struct vb2_buffer *vb)
vb2_plane_size(vb, 0), size);
return -ENOBUFS;
}
-
vb2_set_plane_payload(vb, 0, size);
return 0;
}
-static void set_dma_dest_params(int dma_ch, struct omap1_cam_buf *buf)
-{
- dma_addr_t dma_addr =
- vb2_dma_contig_plane_dma_addr(>vb.vb2_buf, 0);
- unsigned int block_size = vb2_plane_size(>vb.vb2_buf, 0);
-
- omap_set_dma_dest_params(dma_ch,
- OMAP_DMA_PORT_EMIFF, OMAP_DMA_AMODE_POST_INC, dma_addr, 0, 0);
- omap_set_dma_transfer_params(dma_ch,
- OMAP_DMA_DATA_TYPE_S32, DMA_FRAME_SIZE,
- block_size >> (DMA_FRAME_SHIFT + DMA_ELEMENT_SHIFT),
- DMA_SYNC, 0, 0);
-}
-
-static struct omap1_cam_buf *prepare_next_vb(struct omap1_cam_dev *pcdev)
-{
- struct omap1_cam_buf *buf;
-
- /*
-* If there is already a buffer pointed out by the pcdev->ready,
-* (re)use it, otherwise try to fetch and configure a new one.
-*/
- buf = pcdev->ready;
- if (!buf) {
- if (list_empty(>capture))
- return buf;
- buf = list_entry(pcdev->capture.next,
- struct omap1_cam_buf, queue);
- pcdev->ready = buf;
- list_del_init(>queue);
- }
-
- /*
-* In CONTIG mode, we can safely enter next buffer parameters
-* into th
[RFC] [PATCH 2/3] staging: media: omap1: convert to videobuf2
Created and tested on Amstrad Delta on top of Linux-4.7-rc3 with
"staging: media: omap1: drop videobuf-dma-sg mode" applied.
Signed-off-by: Janusz Krzysztofik <jmkrzy...@gmail.com>
---
drivers/staging/media/omap1/Kconfig| 2 +-
drivers/staging/media/omap1/omap1_camera.c | 363 -
2 files changed, 151 insertions(+), 214 deletions(-)
diff --git a/drivers/staging/media/omap1/Kconfig
b/drivers/staging/media/omap1/Kconfig
index e2a39f5..12f1d7a 100644
--- a/drivers/staging/media/omap1/Kconfig
+++ b/drivers/staging/media/omap1/Kconfig
@@ -3,7 +3,7 @@ config VIDEO_OMAP1
depends on VIDEO_DEV && SOC_CAMERA
depends on ARCH_OMAP1
depends on HAS_DMA
- select VIDEOBUF_DMA_CONTIG
+ select VIDEOBUF2_DMA_CONTIG
---help---
This is a v4l2 driver for the TI OMAP1 camera interface
diff --git a/drivers/staging/media/omap1/omap1_camera.c
b/drivers/staging/media/omap1/omap1_camera.c
index 37ef4da..3761660 100644
--- a/drivers/staging/media/omap1/omap1_camera.c
+++ b/drivers/staging/media/omap1/omap1_camera.c
@@ -1,7 +1,7 @@
/*
* V4L2 SoC Camera driver for OMAP1 Camera Interface
*
- * Copyright (C) 2010, Janusz Krzysztofik <jkrzy...@tis.icnet.pl>
+ * Copyright (C) 2010, 2016 Janusz Krzysztofik <jmkrzy...@gmail.com>
*
* Based on V4L2 Driver for i.MXL/i.MXL camera (CSI) host
* Copyright (C) 2008, Paulius Zaleckas <paulius.zalec...@teltonika.lt>
@@ -31,13 +31,13 @@
#include
#include
#include
-#include
+#include
#include
#define DRIVER_NAME"omap1-camera"
-#define DRIVER_VERSION "0.0.3"
+#define DRIVER_VERSION "0.0.4"
#define OMAP_DMA_CAMERA_IF_RX 20
@@ -134,9 +134,8 @@
/* buffer for one video frame */
struct omap1_cam_buf {
- struct videobuf_buffer vb;
- u32 code;
- int inwork;
+ struct vb2_v4l2_buffer vb;
+ struct list_headqueue;
};
struct omap1_cam_dev {
@@ -161,10 +160,18 @@ struct omap1_cam_dev {
struct omap1_cam_buf*active;
struct omap1_cam_buf*ready;
+ struct vb2_alloc_ctx*alloc_ctx;
+ int sequence;
+
u32 reg_cache[0];
};
+static struct omap1_cam_buf *vb2_to_omap1_cam_buf(struct vb2_v4l2_buffer *vbuf)
+{
+ return container_of(vbuf, struct omap1_cam_buf, vb);
+}
+
static void cam_write(struct omap1_cam_dev *pcdev, u16 reg, u32 val)
{
pcdev->reg_cache[reg / sizeof(u32)] = val;
@@ -187,92 +194,59 @@ static u32 cam_read(struct omap1_cam_dev *pcdev, u16 reg,
bool from_cache)
/*
* Videobuf operations
*/
-static int omap1_videobuf_setup(struct videobuf_queue *vq, unsigned int *count,
- unsigned int *size)
+
+static int omap1_videobuf_setup(struct vb2_queue *vq, unsigned int *count,
+ unsigned int *num_planes, unsigned int sizes[],
+ void *alloc_ctxs[])
{
- struct soc_camera_device *icd = vq->priv_data;
+ struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
+ struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
+ struct omap1_cam_dev *pcdev = ici->priv;
+ unsigned int size = icd->sizeimage;
+
+ pcdev->sequence = 0;
- *size = icd->sizeimage;
+ *num_planes = 1;
+ sizes[0] = size;
+ alloc_ctxs[0] = pcdev->alloc_ctx;
if (!*count || *count < OMAP1_CAMERA_MIN_BUF_COUNT)
*count = OMAP1_CAMERA_MIN_BUF_COUNT;
- if (*size * *count > MAX_VIDEO_MEM * 1024 * 1024)
- *count = (MAX_VIDEO_MEM * 1024 * 1024) / *size;
+ if (size * *count > MAX_VIDEO_MEM * 1024 * 1024)
+ *count = (MAX_VIDEO_MEM * 1024 * 1024) / size;
dev_dbg(icd->parent,
- "%s: count=%d, size=%d\n", __func__, *count, *size);
+ "%s: count=%u, size=%u\n", __func__, *count, size);
return 0;
}
-static void free_buffer(struct videobuf_queue *vq, struct omap1_cam_buf *buf)
-{
- struct videobuf_buffer *vb = >vb;
-
- BUG_ON(in_interrupt());
-
- videobuf_waiton(vq, vb, 0, 0);
-
- videobuf_dma_contig_free(vq, vb);
-
- vb->state = VIDEOBUF_NEEDS_INIT;
-}
-
-static int omap1_videobuf_prepare(struct videobuf_queue *vq,
- struct videobuf_buffer *vb, enum v4l2_field field)
+static int omap1_videobuf_prepare(struct vb2_buffer *vb)
{
- struct soc_camera_device *icd = vq->priv_data;
- struct omap1_cam_buf *buf = container_of(vb, struct omap1_cam_buf, vb);
- int ret;
-
- WARN_ON(!list_empty(>queue));
+ struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb)
[PATCH 3/3] media: i2c/soc_camera: fix ov6650 sensor getting wrong clock
After changes to v4l2_clk API introduced in v4.1 by commits a37462b919
'[media] V4L: remove clock name from v4l2_clk API' and 4f528afcfb
'[media] V4L: add CCF support to the v4l2_clk API', ov6650 sensor
stopped responding because v4l2_clk_get(), still called with
depreciated V4L2 clock name "mclk", started to return respective CCF
clock instead of the V4l2 one registered by soc_camera. Fix it by
calling v4l2_clk_get() with NULL clock name.
Created and tested on Amstrad Delta against Linux-4.7-rc3 with
omap1_camera fixes.
Signed-off-by: Janusz Krzysztofik <jmkrzy...@gmail.com>
---
drivers/media/i2c/soc_camera/ov6650.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/soc_camera/ov6650.c
b/drivers/media/i2c/soc_camera/ov6650.c
index 1f8af1e..1e4783b 100644
--- a/drivers/media/i2c/soc_camera/ov6650.c
+++ b/drivers/media/i2c/soc_camera/ov6650.c
@@ -1033,7 +1033,7 @@ static int ov6650_probe(struct i2c_client *client,
priv->code= MEDIA_BUS_FMT_YUYV8_2X8;
priv->colorspace = V4L2_COLORSPACE_JPEG;
- priv->clk = v4l2_clk_get(>dev, "mclk");
+ priv->clk = v4l2_clk_get(>dev, NULL);
if (IS_ERR(priv->clk)) {
ret = PTR_ERR(priv->clk);
goto eclkget;
--
2.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] staging: media: omap1: fix sensor probe not working anymore
After clock_start() removal from from soc_camera_probe() (commit
9aea470b39 '[media] soc-camera: switch I2C subdevice drivers to use
v4l2-clk', introduced in v3.11), it occurred omap1_camera's sensor
can't be probed successfully without its clock being turned on in
advance. Fix that by surrounding soc_camera_host_register() invocation
with clock_start() / clock_stop().
Created and tested on Amstrad Delta against Linux-4.7-rc3 with
'staging: media: omap1: fix null pointer dereference in
omap1_cam_probe()' applied.
Signed-off-by: Janusz Krzysztofik <jmkrzy...@gmail.com>
---
drivers/staging/media/omap1/omap1_camera.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/omap1/omap1_camera.c
b/drivers/staging/media/omap1/omap1_camera.c
index dc35d30..9b6140a 100644
--- a/drivers/staging/media/omap1/omap1_camera.c
+++ b/drivers/staging/media/omap1/omap1_camera.c
@@ -1650,7 +1650,11 @@ static int omap1_cam_probe(struct platform_device *pdev)
pcdev->soc_host.v4l2_dev.dev= >dev;
pcdev->soc_host.nr = pdev->id;
- err = soc_camera_host_register(>soc_host);
+ err = omap1_cam_clock_start(>soc_host);
+ if (!err) {
+ err = soc_camera_host_register(>soc_host);
+ omap1_cam_clock_stop(>soc_host);
+ }
if (err)
return err;
--
2.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] staging: media: omap1: fix null pointer dereference in omap1_cam_probe()
Commit 76e543382bd4 ("staging: media: omap1: Switch to
devm_ioremap_resource") moved assignment of struct resource *res =
platform_get_resource() several lines down. That resulted in the
following error:
[3.793237] Unable to handle kernel NULL pointer dereference at virtual
address 0004
[3.802198] pgd = c0004000
[3.805202] [0004] *pgd=
[3.809373] Internal error: Oops: c5 [#1] ARM
[3.814070] CPU: 0 PID: 1 Comm: swapper Not tainted 4.6.0-rc1+ #70
[3.820570] Hardware name: Amstrad E3 (Delta)
[3.825232] task: c1819440 ti: c181e000 task.ti: c181e000
[3.830973] PC is at omap1_cam_probe+0x48/0x2d4
[3.835873] LR is at devres_add+0x20/0x28
Move the assignment back up where it was before - it is used to build
an argument for a subsequent devm_kzalloc(). Also, restore the check
for null value of res - it shouldn't hurt.
While being at it:
- follow the recently introduced convention of direct return
instead of jump to return with err value assigned,
- drop no longer needed res member from the definition of struct
omap1_cam_dev.
Created and tested on Amstrad Delta aginst Linux-4.7-rc3
Signed-off-by: Janusz Krzysztofik <jmkrzy...@gmail.com>
---
drivers/staging/media/omap1/omap1_camera.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/media/omap1/omap1_camera.c
b/drivers/staging/media/omap1/omap1_camera.c
index 54b8dd2..dc35d30 100644
--- a/drivers/staging/media/omap1/omap1_camera.c
+++ b/drivers/staging/media/omap1/omap1_camera.c
@@ -158,7 +158,6 @@ struct omap1_cam_dev {
int dma_ch;
struct omap1_cam_platform_data *pdata;
- struct resource *res;
unsigned long pflags;
unsigned long camexclk;
@@ -1569,11 +1568,10 @@ static int omap1_cam_probe(struct platform_device *pdev)
unsigned int irq;
int err = 0;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
irq = platform_get_irq(pdev, 0);
- if ((int)irq <= 0) {
- err = -ENODEV;
- goto exit;
- }
+ if (!res || (int)irq <= 0)
+ return -ENODEV;
clk = devm_clk_get(>dev, "armper_ck");
if (IS_ERR(clk))
@@ -1614,7 +1612,6 @@ static int omap1_cam_probe(struct platform_device *pdev)
INIT_LIST_HEAD(>capture);
spin_lock_init(>lock);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(>dev, res);
if (IS_ERR(base))
return PTR_ERR(base);
@@ -1663,7 +1660,6 @@ static int omap1_cam_probe(struct platform_device *pdev)
exit_free_dma:
omap_free_dma(pcdev->dma_ch);
-exit:
return err;
}
--
2.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] media: fixes for Amstrad Delta camera
Janusz Krzysztofik (3): staging: media: omap1: fix null pointer dereference in omap1_cam_probe() staging: media: omap1: fix sensor probe not working anymore media: i2c/soc_camera: fix ov6650 sensor getting wrong clock drivers/media/i2c/soc_camera/ov6650.c | 2 +- drivers/staging/media/omap1/omap1_camera.c | 16 2 files changed, 9 insertions(+), 9 deletions(-) -- 2.7.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
Re: [PATCH] V4L: soc-camera: fix compiler warnings on 64-bit platforms
On Monday 05 of December 2011 at 16:15:28, Guennadi Liakhovetski wrote:
On 64-bit platforms assigning a pointer to a 32-bit variable causes a
compiler warning and cannot actually work. Soc-camera currently doesn't
support any 64-bit systems, but such platforms can be added in the
and in any case compiler warnings should be avoided.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
This is a long-standing warning in the 3.2 kernel. The fix should only
affect sh-mobile platforms, of which I tested some, and the ov6650 camera
sensor driver.
drivers/media/video/ov6650.c |2 +-
drivers/media/video/sh_mobile_ceu_camera.c | 34 +--
drivers/media/video/sh_mobile_csi2.c |4 +-
drivers/media/video/soc_camera.c |2 +-
include/media/soc_camera.h |7 +-
5 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/drivers/media/video/ov6650.c b/drivers/media/video/ov6650.c
index 9f2d26b..6806345 100644
--- a/drivers/media/video/ov6650.c
+++ b/drivers/media/video/ov6650.c
@@ -540,7 +540,7 @@ static u8 to_clkrc(struct v4l2_fract *timeperframe,
static int ov6650_s_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt
*mf)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
- struct soc_camera_device *icd = (struct soc_camera_device *)sd-grp_id;
+ struct soc_camera_device *icd = v4l2_get_subdev_hostdata(sd);
Hi Guennadi,
Where is the v4l2_set_subdev_hostdata() supposed to be called from? I
can find it called only from drivers/media/video/s5p-fimc/fimc-mdevice.c
for now, and introduced with your patch into sh_mobile_ceu_camera.c
only. What about other soc_camera host interfaces? Are those supposed to
call v4l2_set_subdev_hostdata() themselves if a sensor is expected to be
calling v4l2_set_subdev_hostdata()? Perhaps the soc_camera framework
should take care of this?
struct soc_camera_sense *sense = icd-sense;
Don't we risk a NULL pointer dereference here in case
v4l2_set_subdev_hostdata() was not called?
Thanks,
Janusz
struct ov6650 *priv = to_ov6650(client);
bool half_scale = !is_unscaled_ok(mf-width, mf-height, priv-rect);
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index f390682..c51decf 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -566,8 +566,10 @@ static int sh_mobile_ceu_add_device(struct
soc_camera_device *icd)
ret = sh_mobile_ceu_soft_reset(pcdev);
csi2_sd = find_csi2(pcdev);
- if (csi2_sd)
- csi2_sd-grp_id = (long)icd;
+ if (csi2_sd) {
+ csi2_sd-grp_id = soc_camera_grp_id(icd);
+ v4l2_set_subdev_hostdata(csi2_sd, icd);
+ }
ret = v4l2_subdev_call(csi2_sd, core, s_power, 1);
if (ret 0 ret != -ENOIOCTLCMD ret != -ENODEV) {
@@ -768,7 +770,7 @@ static struct v4l2_subdev *find_bus_subdev(struct
sh_mobile_ceu_dev *pcdev,
{
if (pcdev-csi2_pdev) {
struct v4l2_subdev *csi2_sd = find_csi2(pcdev);
- if (csi2_sd csi2_sd-grp_id == (u32)icd)
+ if (csi2_sd csi2_sd-grp_id == soc_camera_grp_id(icd))
return csi2_sd;
}
@@ -1089,8 +1091,9 @@ static int sh_mobile_ceu_get_formats(struct
soc_camera_device *icd, unsigned int
/* Try 2560x1920, 1280x960, 640x480, 320x240 */
mf.width= 2560 shift;
mf.height = 1920 shift;
- ret = v4l2_device_call_until_err(sd-v4l2_dev,
(long)icd, video,
- s_mbus_fmt, mf);
+ ret = v4l2_device_call_until_err(sd-v4l2_dev,
+ soc_camera_grp_id(icd), video,
+ s_mbus_fmt, mf);
if (ret 0)
return ret;
shift++;
@@ -1389,7 +1392,8 @@ static int client_s_fmt(struct soc_camera_device *icd,
bool ceu_1to1;
int ret;
- ret = v4l2_device_call_until_err(sd-v4l2_dev, (long)icd, video,
+ ret = v4l2_device_call_until_err(sd-v4l2_dev,
+ soc_camera_grp_id(icd), video,
s_mbus_fmt, mf);
if (ret 0)
return ret;
@@ -1426,8 +1430,9 @@ static int client_s_fmt(struct soc_camera_device *icd,
tmp_h = min(2 * tmp_h, max_height);
mf-width = tmp_w;
mf-height = tmp_h;
- ret = v4l2_device_call_until_err(sd-v4l2_dev, (long)icd, video,
- s_mbus_fmt, mf);
+ ret = v4l2_device_call_until_err(sd-v4l2_dev,
+ soc_camera_grp_id(icd), video,
+
Re: [PATCH] V4L: soc-camera: fix compiler warnings on 64-bit platforms
On Monday 05 of December 2011 at 18:23:44, Janusz Krzysztofik wrote:
On Monday 05 of December 2011 at 16:15:28, Guennadi Liakhovetski wrote:
On 64-bit platforms assigning a pointer to a 32-bit variable causes a
compiler warning and cannot actually work. Soc-camera currently doesn't
support any 64-bit systems, but such platforms can be added in the
and in any case compiler warnings should be avoided.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
This is a long-standing warning in the 3.2 kernel. The fix should only
affect sh-mobile platforms, of which I tested some, and the ov6650 camera
sensor driver.
drivers/media/video/ov6650.c |2 +-
drivers/media/video/sh_mobile_ceu_camera.c | 34
+--
drivers/media/video/sh_mobile_csi2.c |4 +-
drivers/media/video/soc_camera.c |2 +-
include/media/soc_camera.h |7 +-
5 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/drivers/media/video/ov6650.c b/drivers/media/video/ov6650.c
index 9f2d26b..6806345 100644
--- a/drivers/media/video/ov6650.c
+++ b/drivers/media/video/ov6650.c
@@ -540,7 +540,7 @@ static u8 to_clkrc(struct v4l2_fract *timeperframe,
static int ov6650_s_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt
*mf)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
- struct soc_camera_device *icd = (struct soc_camera_device *)sd-grp_id;
+ struct soc_camera_device *icd = v4l2_get_subdev_hostdata(sd);
Hi Guennadi,
Where is the v4l2_set_subdev_hostdata() supposed to be called from? I
can find it called only from drivers/media/video/s5p-fimc/fimc-mdevice.c
for now, and introduced with your patch into sh_mobile_ceu_camera.c
only. What about other soc_camera host interfaces? Are those supposed to
call v4l2_set_subdev_hostdata() themselves if a sensor is expected to be
calling v4l2_set_subdev_hostdata()? Perhaps the soc_camera framework
^
s/set/get/, sorry.
should take care of this?
struct soc_camera_sense *sense = icd-sense;
Don't we risk a NULL pointer dereference here in case
v4l2_set_subdev_hostdata() was not called?
Thanks,
Janusz
struct ov6650 *priv = to_ov6650(client);
bool half_scale = !is_unscaled_ok(mf-width, mf-height, priv-rect);
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index f390682..c51decf 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -566,8 +566,10 @@ static int sh_mobile_ceu_add_device(struct
soc_camera_device *icd)
ret = sh_mobile_ceu_soft_reset(pcdev);
csi2_sd = find_csi2(pcdev);
- if (csi2_sd)
- csi2_sd-grp_id = (long)icd;
+ if (csi2_sd) {
+ csi2_sd-grp_id = soc_camera_grp_id(icd);
+ v4l2_set_subdev_hostdata(csi2_sd, icd);
+ }
ret = v4l2_subdev_call(csi2_sd, core, s_power, 1);
if (ret 0 ret != -ENOIOCTLCMD ret != -ENODEV) {
@@ -768,7 +770,7 @@ static struct v4l2_subdev *find_bus_subdev(struct
sh_mobile_ceu_dev *pcdev,
{
if (pcdev-csi2_pdev) {
struct v4l2_subdev *csi2_sd = find_csi2(pcdev);
- if (csi2_sd csi2_sd-grp_id == (u32)icd)
+ if (csi2_sd csi2_sd-grp_id == soc_camera_grp_id(icd))
return csi2_sd;
}
@@ -1089,8 +1091,9 @@ static int sh_mobile_ceu_get_formats(struct
soc_camera_device *icd, unsigned int
/* Try 2560x1920, 1280x960, 640x480, 320x240 */
mf.width= 2560 shift;
mf.height = 1920 shift;
- ret = v4l2_device_call_until_err(sd-v4l2_dev,
(long)icd, video,
-s_mbus_fmt, mf);
+ ret = v4l2_device_call_until_err(sd-v4l2_dev,
+ soc_camera_grp_id(icd), video,
+ s_mbus_fmt, mf);
if (ret 0)
return ret;
shift++;
@@ -1389,7 +1392,8 @@ static int client_s_fmt(struct soc_camera_device *icd,
bool ceu_1to1;
int ret;
- ret = v4l2_device_call_until_err(sd-v4l2_dev, (long)icd, video,
+ ret = v4l2_device_call_until_err(sd-v4l2_dev,
+soc_camera_grp_id(icd), video,
s_mbus_fmt, mf);
if (ret 0)
return ret;
@@ -1426,8 +1430,9 @@ static int client_s_fmt(struct soc_camera_device *icd,
tmp_h = min(2 * tmp_h, max_height);
mf-width = tmp_w;
mf-height = tmp_h;
- ret = v4l2_device_call_until_err(sd-v4l2_dev, (long)icd, video,
-s_mbus_fmt, mf
Re: [PATCH v2] V4L: soc-camera: fix compiler warnings on 64-bit platforms
On Monday 05 of December 2011 at 21:01:13, Guennadi Liakhovetski wrote:
On 64-bit platforms assigning a pointer to a 32-bit variable causes a
compiler warning and cannot actually work. Soc-camera currently doesn't
support any 64-bit systems, but such platforms can be added in the
and in any case compiler warnings should be avoided.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v2:
On Mon, 5 Dec 2011, Janusz Krzysztofik wrote:
Hi Guennadi,
Where is the v4l2_set_subdev_hostdata() supposed to be called from? I
can find it called only from drivers/media/video/s5p-fimc/fimc-mdevice.c
for now, and introduced with your patch into sh_mobile_ceu_camera.c
only. What about other soc_camera host interfaces? Are those supposed to
call v4l2_set_subdev_hostdata() themselves if a sensor is expected to be
calling v4l2_set_subdev_hostdata()? Perhaps the soc_camera framework
^
s/set/get/, sorry.
should take care of this?
Bugger, of course you're right. Thanks for catching! This one should be
better.
struct soc_camera_sense *sense = icd-sense;
Don't we risk a NULL pointer dereference here in case
v4l2_set_subdev_hostdata() was not called?
Now it should never be NULL, if it is, this is a well-deserved Oops.
drivers/media/video/ov6650.c |2 +-
For the one above,
Acked-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Thanks,
Janusz
drivers/media/video/sh_mobile_ceu_camera.c | 34 +--
drivers/media/video/sh_mobile_csi2.c |4 +-
drivers/media/video/soc_camera.c |3 +-
include/media/soc_camera.h |7 +-
5 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/drivers/media/video/ov6650.c b/drivers/media/video/ov6650.c
index 9f2d26b..6806345 100644
--- a/drivers/media/video/ov6650.c
+++ b/drivers/media/video/ov6650.c
@@ -540,7 +540,7 @@ static u8 to_clkrc(struct v4l2_fract *timeperframe,
static int ov6650_s_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt
*mf)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
- struct soc_camera_device *icd = (struct soc_camera_device *)sd-grp_id;
+ struct soc_camera_device *icd = v4l2_get_subdev_hostdata(sd);
struct soc_camera_sense *sense = icd-sense;
struct ov6650 *priv = to_ov6650(client);
bool half_scale = !is_unscaled_ok(mf-width, mf-height, priv-rect);
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index f390682..c51decf 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -566,8 +566,10 @@ static int sh_mobile_ceu_add_device(struct
soc_camera_device *icd)
ret = sh_mobile_ceu_soft_reset(pcdev);
csi2_sd = find_csi2(pcdev);
- if (csi2_sd)
- csi2_sd-grp_id = (long)icd;
+ if (csi2_sd) {
+ csi2_sd-grp_id = soc_camera_grp_id(icd);
+ v4l2_set_subdev_hostdata(csi2_sd, icd);
+ }
ret = v4l2_subdev_call(csi2_sd, core, s_power, 1);
if (ret 0 ret != -ENOIOCTLCMD ret != -ENODEV) {
@@ -768,7 +770,7 @@ static struct v4l2_subdev *find_bus_subdev(struct
sh_mobile_ceu_dev *pcdev,
{
if (pcdev-csi2_pdev) {
struct v4l2_subdev *csi2_sd = find_csi2(pcdev);
- if (csi2_sd csi2_sd-grp_id == (u32)icd)
+ if (csi2_sd csi2_sd-grp_id == soc_camera_grp_id(icd))
return csi2_sd;
}
@@ -1089,8 +1091,9 @@ static int sh_mobile_ceu_get_formats(struct
soc_camera_device *icd, unsigned int
/* Try 2560x1920, 1280x960, 640x480, 320x240 */
mf.width= 2560 shift;
mf.height = 1920 shift;
- ret = v4l2_device_call_until_err(sd-v4l2_dev,
(long)icd, video,
- s_mbus_fmt, mf);
+ ret = v4l2_device_call_until_err(sd-v4l2_dev,
+ soc_camera_grp_id(icd), video,
+ s_mbus_fmt, mf);
if (ret 0)
return ret;
shift++;
@@ -1389,7 +1392,8 @@ static int client_s_fmt(struct soc_camera_device *icd,
bool ceu_1to1;
int ret;
- ret = v4l2_device_call_until_err(sd-v4l2_dev, (long)icd, video,
+ ret = v4l2_device_call_until_err(sd-v4l2_dev,
+ soc_camera_grp_id(icd), video,
s_mbus_fmt, mf);
if (ret 0)
return ret;
@@ -1426,8 +1430,9 @@ static int client_s_fmt(struct soc_camera_device *icd,
tmp_h = min(2 * tmp_h, max_height);
mf-width = tmp_w;
mf-height = tmp_h;
- ret
[PATCH] V4L: omap1_camera: fix missing linux/module.h include
Otherwise compilation breaks with: drivers/media/video/omap1_camera.c:1535: error: 'THIS_MODULE' undeclared here (not in a function) ... after apparently no longer included recursively from other header files. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- drivers/media/video/omap1_camera.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap1_camera.c b/drivers/media/video/omap1_camera.c index e87ae2f..6a6cf38 100644 --- a/drivers/media/video/omap1_camera.c +++ b/drivers/media/video/omap1_camera.c @@ -24,6 +24,7 @@ #include linux/clk.h #include linux/dma-mapping.h #include linux/interrupt.h +#include linux/module.h #include linux/platform_device.h #include linux/slab.h -- 1.7.3.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] media: ov6650: Fix wrong register used for red control
REG_BLUE has been used by mistake instead of REG_RED. Fix it.
While being at it, fix a few minor issues:
* with no retrun ret; at the end, there is no need to initialize ret
any longer,
* consequently use conditional expressions, not if...else constructs,
throughout ov6650_s_ctrl(),
* v4l2_ctrl_new_std_menu() max value of V4L2_EXPOSURE_MANUAL instead of
equivalent 1 looks more clear.
Created on top of Converting soc_camera to the control framework
series.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/media/video/ov6650.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/ov6650.c b/drivers/media/video/ov6650.c
index 089a4aa..c0709ee 100644
--- a/drivers/media/video/ov6650.c
+++ b/drivers/media/video/ov6650.c
@@ -310,7 +310,7 @@ static int ov6550_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
struct v4l2_subdev *sd = priv-subdev;
struct i2c_client *client = v4l2_get_subdevdata(sd);
uint8_t reg, reg2;
- int ret = 0;
+ int ret;
switch (ctrl-id) {
case V4L2_CID_AUTOGAIN:
@@ -342,7 +342,7 @@ static int ov6550_s_ctrl(struct v4l2_ctrl *ctrl)
struct ov6650 *priv = container_of(ctrl-handler, struct ov6650, hdl);
struct v4l2_subdev *sd = priv-subdev;
struct i2c_client *client = v4l2_get_subdevdata(sd);
- int ret = 0;
+ int ret;
switch (ctrl-id) {
case V4L2_CID_AUTOGAIN:
@@ -357,7 +357,7 @@ static int ov6550_s_ctrl(struct v4l2_ctrl *ctrl)
if (!ret !ctrl-val) {
ret = ov6650_reg_write(client, REG_BLUE,
priv-blue-val);
if (!ret)
- ret = ov6650_reg_write(client, REG_BLUE,
+ ret = ov6650_reg_write(client, REG_RED,
priv-red-val);
}
return ret;
@@ -370,10 +370,8 @@ static int ov6550_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_BRIGHTNESS:
return ov6650_reg_write(client, REG_BRT, ctrl-val);
case V4L2_CID_EXPOSURE_AUTO:
- if (ctrl-val == V4L2_EXPOSURE_AUTO)
- ret = ov6650_reg_rmw(client, REG_COMB, COMB_AEC, 0);
- else
- ret = ov6650_reg_rmw(client, REG_COMB, 0, COMB_AEC);
+ ret = ov6650_reg_rmw(client, REG_COMB, ctrl-val ==
+ V4L2_EXPOSURE_AUTO ? COMB_AEC : 0, COMB_AEC);
if (!ret ctrl-val == V4L2_EXPOSURE_MANUAL)
ret = ov6650_reg_write(client, REG_AECH,
priv-exposure-val);
@@ -993,8 +991,8 @@ static int ov6650_probe(struct i2c_client *client,
v4l2_ctrl_new_std(priv-hdl, ov6550_ctrl_ops,
V4L2_CID_BRIGHTNESS, 0, 0xff, 1, 0x80);
priv-autoexposure = v4l2_ctrl_new_std_menu(priv-hdl,
- ov6550_ctrl_ops, V4L2_CID_EXPOSURE_AUTO, 1, 0,
- V4L2_EXPOSURE_AUTO);
+ ov6550_ctrl_ops, V4L2_CID_EXPOSURE_AUTO,
+ V4L2_EXPOSURE_MANUAL, 0, V4L2_EXPOSURE_AUTO);
priv-exposure = v4l2_ctrl_new_std(priv-hdl, ov6550_ctrl_ops,
V4L2_CID_EXPOSURE, 0, 0xff, 1, DEF_AECH);
v4l2_ctrl_new_std(priv-hdl, ov6550_ctrl_ops,
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: ov6650: Fix wrong register used for red control
Guennadi Liakhovetski wrote:
Hi Janusz
Thanks for the patch, but, since I anyway will have to re-roll my branch
on linuxtv, maybe I'll roll in your s/BLUE/RED/ hunk into the original
patch from Hans with a suitable
[jkrzy...@tis.icnet.pl: fix a typo in the register name]
comment, and then add this your patch without that hunk and with an
amended description on top, would that be ok with you?
Yeah, that's exactly what I thought could be more appropriate.
Thanks,
Janusz
Thanks
Guennadi
On Mon, 12 Sep 2011, Janusz Krzysztofik wrote:
REG_BLUE has been used by mistake instead of REG_RED. Fix it.
While being at it, fix a few minor issues:
* with no retrun ret; at the end, there is no need to initialize ret
any longer,
* consequently use conditional expressions, not if...else constructs,
throughout ov6650_s_ctrl(),
* v4l2_ctrl_new_std_menu() max value of V4L2_EXPOSURE_MANUAL instead of
equivalent 1 looks more clear.
Created on top of Converting soc_camera to the control framework
series.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/media/video/ov6650.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/ov6650.c b/drivers/media/video/ov6650.c
index 089a4aa..c0709ee 100644
--- a/drivers/media/video/ov6650.c
+++ b/drivers/media/video/ov6650.c
@@ -310,7 +310,7 @@ static int ov6550_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
struct v4l2_subdev *sd = priv-subdev;
struct i2c_client *client = v4l2_get_subdevdata(sd);
uint8_t reg, reg2;
- int ret = 0;
+ int ret;
switch (ctrl-id) {
case V4L2_CID_AUTOGAIN:
@@ -342,7 +342,7 @@ static int ov6550_s_ctrl(struct v4l2_ctrl *ctrl)
struct ov6650 *priv = container_of(ctrl-handler, struct ov6650, hdl);
struct v4l2_subdev *sd = priv-subdev;
struct i2c_client *client = v4l2_get_subdevdata(sd);
- int ret = 0;
+ int ret;
switch (ctrl-id) {
case V4L2_CID_AUTOGAIN:
@@ -357,7 +357,7 @@ static int ov6550_s_ctrl(struct v4l2_ctrl *ctrl)
if (!ret !ctrl-val) {
ret = ov6650_reg_write(client, REG_BLUE,
priv-blue-val);
if (!ret)
- ret = ov6650_reg_write(client, REG_BLUE,
+ ret = ov6650_reg_write(client, REG_RED,
priv-red-val);
}
return ret;
@@ -370,10 +370,8 @@ static int ov6550_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_BRIGHTNESS:
return ov6650_reg_write(client, REG_BRT, ctrl-val);
case V4L2_CID_EXPOSURE_AUTO:
- if (ctrl-val == V4L2_EXPOSURE_AUTO)
- ret = ov6650_reg_rmw(client, REG_COMB, COMB_AEC, 0);
- else
- ret = ov6650_reg_rmw(client, REG_COMB, 0, COMB_AEC);
+ ret = ov6650_reg_rmw(client, REG_COMB, ctrl-val ==
+ V4L2_EXPOSURE_AUTO ? COMB_AEC : 0, COMB_AEC);
if (!ret ctrl-val == V4L2_EXPOSURE_MANUAL)
ret = ov6650_reg_write(client, REG_AECH,
priv-exposure-val);
@@ -993,8 +991,8 @@ static int ov6650_probe(struct i2c_client *client,
v4l2_ctrl_new_std(priv-hdl, ov6550_ctrl_ops,
V4L2_CID_BRIGHTNESS, 0, 0xff, 1, 0x80);
priv-autoexposure = v4l2_ctrl_new_std_menu(priv-hdl,
- ov6550_ctrl_ops, V4L2_CID_EXPOSURE_AUTO, 1, 0,
- V4L2_EXPOSURE_AUTO);
+ ov6550_ctrl_ops, V4L2_CID_EXPOSURE_AUTO,
+ V4L2_EXPOSURE_MANUAL, 0, V4L2_EXPOSURE_AUTO);
priv-exposure = v4l2_ctrl_new_std(priv-hdl, ov6550_ctrl_ops,
V4L2_CID_EXPOSURE, 0, 0xff, 1, DEF_AECH);
v4l2_ctrl_new_std(priv-hdl, ov6550_ctrl_ops,
--
1.7.3.4
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 08/13 v3] ov6650: convert to the control framework.
On Thu, 8 Sep 2011 at 10:44:01 Guennadi Liakhovetski wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
[g.liakhovet...@gmx.de: simplified pointer arithmetic]
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Hi,
I've successfully tested this one for you, to the extent possible using
mplayer, i.e., only saturation, hue and brightness controls, and an
overall functionality.
Modifications to other (not runtime tested) controls look good to me,
except for one copy-paste mistake, see below. With that erratic REG_BLUE
corrected:
Acked-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
There are also a few minor comments for you to consider.
Thanks,
Janusz
---
drivers/media/video/ov6650.c | 381
+-
1 files changed, 115 insertions(+), 266 deletions(-)
diff --git a/drivers/media/video/ov6650.c b/drivers/media/video/ov6650.c
index 654b2f5..089a4aa 100644
--- a/drivers/media/video/ov6650.c
+++ b/drivers/media/video/ov6650.c
@@ -32,6 +32,7 @@
#include media/soc_camera.h
#include media/soc_mediabus.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
/* Register definitions */
#define REG_GAIN 0x00/* range 00 - 3F */
@@ -177,20 +178,23 @@ struct ov6650_reg {
struct ov6650 {
struct v4l2_subdev subdev;
-
- int gain;
- int blue;
- int red;
- int saturation;
- int hue;
- int brightness;
- int exposure;
- int gamma;
- int aec;
- boolvflip;
- boolhflip;
- boolawb;
- boolagc;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* exposure/autoexposure cluster */
+ struct v4l2_ctrl *autoexposure;
+ struct v4l2_ctrl *exposure;
+ };
+ struct {
+ /* gain/autogain cluster */
+ struct v4l2_ctrl *autogain;
+ struct v4l2_ctrl *gain;
+ };
+ struct {
+ /* blue/red/autowhitebalance cluster */
+ struct v4l2_ctrl *autowb;
+ struct v4l2_ctrl *blue;
+ struct v4l2_ctrl *red;
+ };
boolhalf_scale; /* scale down output by 2 */
struct v4l2_rectrect; /* sensor cropping window */
unsigned long pclk_limit; /* from host */
@@ -210,126 +214,6 @@ static enum v4l2_mbus_pixelcode ov6650_codes[] = {
V4L2_MBUS_FMT_Y8_1X8,
};
-static const struct v4l2_queryctrl ov6650_controls[] = {
- {
- .id = V4L2_CID_AUTOGAIN,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .name = AGC,
- .minimum= 0,
- .maximum= 1,
- .step = 1,
- .default_value = 1,
- },
- {
- .id = V4L2_CID_GAIN,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = Gain,
- .minimum= 0,
- .maximum= 0x3f,
- .step = 1,
- .default_value = DEF_GAIN,
- },
- {
- .id = V4L2_CID_AUTO_WHITE_BALANCE,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .name = AWB,
- .minimum= 0,
- .maximum= 1,
- .step = 1,
- .default_value = 1,
- },
- {
- .id = V4L2_CID_BLUE_BALANCE,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = Blue,
- .minimum= 0,
- .maximum= 0xff,
- .step = 1,
- .default_value = DEF_BLUE,
- },
- {
- .id = V4L2_CID_RED_BALANCE,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = Red,
- .minimum= 0,
- .maximum= 0xff,
- .step = 1,
- .default_value = DEF_RED,
- },
- {
- .id = V4L2_CID_SATURATION,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = Saturation,
- .minimum= 0,
- .maximum= 0xf,
- .step = 1,
- .default_value = 0x8,
- },
- {
- .id = V4L2_CID_HUE,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = Hue,
- .minimum= 0,
- .maximum= HUE_MASK,
- .step
Re: [PATCH 08/13 v3] ov6650: convert to the control framework.
On Fri, 9 Sep 2011 at 20:01:14 Guennadi Liakhovetski wrote: Hi Janusz On Fri, 9 Sep 2011, Janusz Krzysztofik wrote: On Thu, 8 Sep 2011 at 10:44:01 Guennadi Liakhovetski wrote: From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com [g.liakhovet...@gmx.de: simplified pointer arithmetic] Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Hi, I've successfully tested this one for you, to the extent possible using mplayer, i.e., only saturation, hue and brightness controls, and an overall functionality. Thanks for testing and reviewing! Modifications to other (not runtime tested) controls look good to me, except for one copy-paste mistake, see below. With that erratic REG_BLUE corrected: Acked-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl There are also a few minor comments for you to consider. Well, some of them are not so minor, I would say;-) But I personally would be happy to have this just as an incremental patch. Would you like to prepare one or should I do it? OK, I can do it. Do you want them all (except the one below) go into the incremental patch, or would you rather fix that REG_RED bug still before applying? Thanks, Janusz I basically agree with all your comments apart from maybe [snip] @@ -1176,9 +1021,11 @@ static int ov6650_probe(struct i2c_client *client, priv-colorspace = V4L2_COLORSPACE_JPEG; ret = ov6650_video_probe(icd, client); + if (!ret) + ret = v4l2_ctrl_handler_setup(priv-hdl); Are you sure the probe function should fail if v4l2_ctrl_handler_setup() fails? Its usage is documented as optional. Not sure what the standard really meant, but it looks like this is done in all patches in this series. So, we'd have to change this everywhere. Most other drivers indeed do not care. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: omap1-camera: fix Oops with NULL platform data
On Wed, 7 Sep 2011 at 15:49:15 Guennadi Liakhovetski wrote:
Consistently check for platform data != NULL before dereferencing.
Sure, thanks for taking care of this.
Janusz
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/media/video/omap1_camera.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/omap1_camera.c
b/drivers/media/video/omap1_camera.c index f24bcaf..e87ae2f 100644
--- a/drivers/media/video/omap1_camera.c
+++ b/drivers/media/video/omap1_camera.c
@@ -1579,10 +1579,10 @@ static int __init omap1_cam_probe(struct
platform_device *pdev) pcdev-clk = clk;
pcdev-pdata = pdev-dev.platform_data;
- pcdev-pflags = pcdev-pdata-flags;
-
- if (pcdev-pdata)
+ if (pcdev-pdata) {
+ pcdev-pflags = pcdev-pdata-flags;
pcdev-camexclk = pcdev-pdata-camexclk_khz * 1000;
+ }
switch (pcdev-camexclk) {
case 600:
@@ -1592,6 +1592,7 @@ static int __init omap1_cam_probe(struct
platform_device *pdev) case 2400:
break;
default:
+ /* pcdev-camexclk != 0 = pcdev-pdata != NULL */
dev_warn(pdev-dev,
Incorrect sensor clock frequency %ld kHz,
should be one of 0, 6, 8, 9.6, 12 or 24 MHz,
@@ -1599,8 +1600,7 @@ static int __init omap1_cam_probe(struct
platform_device *pdev) pcdev-pdata-camexclk_khz);
pcdev-camexclk = 0;
case 0:
- dev_info(pdev-dev,
- Not providing sensor clock\n);
+ dev_info(pdev-dev, Not providing sensor clock\n);
}
INIT_LIST_HEAD(pcdev-capture);
--
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 00/59] Convert soc-camera to .[gs]_mbus_config() subdev operations
Dnia piątek, 29 lipca 2011 o 12:56:00 Guennadi Liakhovetski napisał(a):
This patch-series converts all soc-camera client and host drivers and
the core from soc-camera specific .{query,set}_bus_param()
operations to the new .[gs]_mbus_config() subdev operations. In
order to prevent bisect breakage we first have to only add new
methods to client drivers, then convert all host drivers, taking
care to preserve platform compatibility, and only then soc-camera
methods can be removed. These patches are also available as a git
branch:
git://linuxtv.org/gliakhovetski/v4l-dvb.git mbus-config
Tested on i.MX31, PXA270, SuperH, mach-shmobile. Compile-tested on
many others. Reviews and tests welcome!:-)
Tested on Amstrad Delta - omap1_camera + ov6650.
Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
On Thu, 9 Jun 2011 at 00:13:30 Russell King - ARM Linux wrote:
On Wed, Jun 08, 2011 at 11:53:49PM +0200, Janusz Krzysztofik wrote:
On Fri 10 Dec 2010 at 22:03:52 Janusz Krzysztofik wrote:
Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
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.
For OMAP1, which is ARMv5 or lower, device memory becomes
'uncacheable, unbufferable' which is luckily what is used for
the DMA coherent memory on those platforms - so no technical
problem here.
However, on ARMv6 and later, ioremapped memory is device
memory, which has different ordering wrt normal memory
mappings, and may appear on different busses on the CPU's
interface. So, this is something I don't encourage as it's
unclear that the hardware will work.
Essentially, dma_declare_coherent_memory() on ARM with main
SDRAM should be viewed as a 'it might work, it might not, and
it might stop working in the future' kind of interface. In
other words, there is no guarantee that this kind of thing
will be supported in the future.
Russell, Tony,
Sorry for getting back to this old thread, but since my previous
attempts to provide[1] or support[2] a possibly better solution to
the problem all failed on one hand, and I can see patches not very
different from mine[3] being accepted for arch/arm/mach-{mx3,imx}
during this and previous merge windows[4][5][6] on the other, is
there any chance for the 'dma_declare_coherent_memory() over a
memblock_alloc()-free()-remove() obtained area' based solution
being accepted for omap1_camera as well if I resend it refreshed?
I stand by my answer to your patches quoted above from a technical
point of view; we should not be mapping SDRAM using device mappings.
Russell,
Would it change anything here if we define ARCH_HAS_HOLES_MEMORYMODEL,
as suggested by Marek Szyprowski recently[*], when configuring for
ARCH_OMAP1 with VIDEO_OMAP1 (camera) selected?
[*] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/057447.html
Certainly the memblock_alloc()+free()+remove() is the right way to
reserve the memory, but as it stands dma_declare_coherent_memory()
should not be used on ARMv6 or higher CPUs to pass that memory to the
device driver.
Tony,
With full respect to all Russell's reservations about incorrectness of
ioremapping SDRAM in general, would you be willing to accept this
solution in the OMAP1 camera case, taking into account that, quoting
Russell, there is no technical problem here, and similiar solutions
had been accepted recently with other ARM platforms?
Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 6/8] drivers: add Contiguous Memory Allocator
Dnia poniedziałek, 11 lipca 2011 o 15:47:32 Marek Szyprowski napisał(a): Hello, On Saturday, July 09, 2011 4:57 PM Janusz Krzysztofik wrote: On Wed, 6 Jul 2011 at 16:59:45 Arnd Bergmann wrote: On Wednesday 06 July 2011, Nicolas Pitre wrote: On Wed, 6 Jul 2011, Russell King - ARM Linux wrote: Another issue is that when a platform has restricted DMA regions, they typically don't fall into the highmem zone. As the dmabounce code allocates from the DMA coherent allocator to provide it with guaranteed DMA-able memory, that would be rather inconvenient. Do we encounter this in practice i.e. do those platforms requiring large contiguous allocations motivating this work have such DMA restrictions? You can probably find one or two of those, but we don't have to optimize for that case. I would at least expect the maximum size of the allocation to be smaller than the DMA limit for these, and consequently mandate that they define a sufficiently large CONSISTENT_DMA_SIZE for the crazy devices, or possibly add a hack to unmap some low memory and call dma_declare_coherent_memory() for the device. Once found that Russell has dropped his ARM: DMA: steal memory for DMA coherent mappings for now, let me get back to this idea of a hack that would allow for safely calling dma_declare_coherent_memory() in order to assign a device with a block of contiguous memory for exclusive use. We tested such approach and finally with 3.0-rc1 it works fine. You can find an example for dma_declare_coherent() together with required memblock_remove() calls in the following patch series: http://www.spinics.net/lists/linux-samsung-soc/msg05026.html [PATCH 0/3 v2] ARM: S5P: Add support for MFC device on S5PV210 and EXYNOS4 Assuming there should be no problem with successfully allocating a large continuous block of coherent memory at boot time with dma_alloc_coherent(), this block could be reserved for the device. The only problem is with the dma_declare_coherent_memory() calling ioremap(), which was designed with a device's dedicated physical memory in mind, but shouldn't be called on a memory already mapped. All these issues with ioremap has been finally resolved in 3.0-rc1. Like Russell pointed me in http://www.spinics.net/lists/arm-kernel/msg127644.html, ioremap can be fixed to work on early reserved memory areas by selecting ARCH_HAS_HOLES_MEMORYMODEL Kconfig option. I'm not sure. Recently I tried to refresh my now 7 months old patch in which I used that 'memblock_remove() then dma_declare_coherent_memery()' method[1]. It was different from your S5P MFC example in that it didn't punch any holes in the system memory, only stole a block of SDRAM from its tail. But Russell reminded me again: we should not be mapping SDRAM using device mappings.[2]. Would defining ARCH_HAS_HOLES_MEMORYMODEL (even if it was justified) make any diference in my case? I don't think so. Wnat I think, after Russell, is that we still need that obligatory ioremap() removed from dma_declare_coherent_memory(), or made it optional, or a separate dma_declare_coherent_memory()-like function without (obligatory) ioremap() provided by the DMA API, in order to get the dma_declare_coherent_memery() method being accepted without any reservations when used inside arch/arm, I'm afraid. Thanks, Janusz [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/034644.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/052488.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: [Linaro-mm-sig] [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wed, 6 Jul 2011 at 16:59:45 Arnd Bergmann wrote: On Wednesday 06 July 2011, Nicolas Pitre wrote: On Wed, 6 Jul 2011, Russell King - ARM Linux wrote: Another issue is that when a platform has restricted DMA regions, they typically don't fall into the highmem zone. As the dmabounce code allocates from the DMA coherent allocator to provide it with guaranteed DMA-able memory, that would be rather inconvenient. Do we encounter this in practice i.e. do those platforms requiring large contiguous allocations motivating this work have such DMA restrictions? You can probably find one or two of those, but we don't have to optimize for that case. I would at least expect the maximum size of the allocation to be smaller than the DMA limit for these, and consequently mandate that they define a sufficiently large CONSISTENT_DMA_SIZE for the crazy devices, or possibly add a hack to unmap some low memory and call dma_declare_coherent_memory() for the device. Once found that Russell has dropped his ARM: DMA: steal memory for DMA coherent mappings for now, let me get back to this idea of a hack that would allow for safely calling dma_declare_coherent_memory() in order to assign a device with a block of contiguous memory for exclusive use. Assuming there should be no problem with successfully allocating a large continuous block of coherent memory at boot time with dma_alloc_coherent(), this block could be reserved for the device. The only problem is with the dma_declare_coherent_memory() calling ioremap(), which was designed with a device's dedicated physical memory in mind, but shouldn't be called on a memory already mapped. There were three approaches proposed, two of them in August 2010: http://www.spinics.net/lists/linux-media/msg22179.html, http://www.spinics.net/lists/arm-kernel/msg96318.html, and a third one in January 2011: http://www.spinics.net/lists/linux-arch/msg12637.html. As far as I can understand the reason why both of the first two were NAKed, it was suggested that videobuf-dma-contig shouldn't use coherent if all it requires is a contiguous memory, and a new API should be invented, or dma_pool API extended, for providing contiguous memory. The CMA was pointed out as a new work in progress contiguous memory API. Now it turns out it's not, it's only a helper to ensure that dma_alloc_coherent() always succeeds, and videobuf2-dma-contig is still going to allocate buffers from coherent memory. (CCing both authors, Marin Mitov and Guennadi Liakhovetski, and their main opponent, FUJITA Tomonori) The third solution was not discussed much after it was pointed out as being not very different from those two in terms of the above mentioned rationale. All three solutions was different from now suggested method of unmapping some low memory and then calling dma_declare_coherent_memory() which ioremaps it in that those tried to reserve some boot time allocated coherent memory, already mapped correctly, without (io)remapping it. If there are still problems with the CMA on one hand, and a need for a hack to handle crazy devices is still seen, regardless of CMA available and working or not, on the other, maybe we should get back to the idea of adopting coherent API to new requirements, review those three proposals again and select one which seems most acceptable to everyone? Being a submitter of the third, I'll be happy to refresh it if selected. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.0] soc_camera: OMAP1: stop falling back to dma-sg on single -ENOMEM
Since commit 6d3163ce86dd386b4f7bda80241d7fea2bc0bb1d, mm: check if any
page in a pageblock is reserved before marking it MIGRATE_RESERVE, the
OMAP1 camera driver behaviour while in videobuf-dma-contig mode can be
observed as much more stable than before. Once all application programs
are started up and nothing unexpected happens in the system, consecutive
device open()s tend to succeed with almost 100% reliability.
While the result is still not perfect, still prone to occasional -ENOMEM
failures, I think there is no longer a need to fall back to more
reliable but less effective, more resource hungry videobuf-dma-sg mode
if a single open() fails, as long as users are still able to switch
DMA modes from user space over the driver provided sysfs interface,
should videobuf-dma-contig mode still happen to keep failing for them.
Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Hi,
While this patch is not a classic fix, not correcting anything that
could be considered as a bug or regression, it is a simple consequence
of unexpected but very welcome enhancement introduced during this merge
window, so I hope it can be accepted in the rc cycle for that reason.
Moreover, it provides no new, but simplifies existing code by removing
no longer needed bits.
Thanks,
Janusz
drivers/media/video/omap1_camera.c | 37 +
1 file changed, 1 insertion(+), 36 deletions(-)
--- git/drivers/media/video/omap1_camera.c.orig 2011-06-06 18:07:54.0
+0200
+++ git/drivers/media/video/omap1_camera.c 2011-06-09 12:04:09.0
+0200
@@ -172,9 +172,6 @@ struct omap1_cam_dev {
struct omap1_cam_buf*ready;
enum omap1_cam_vb_mode vb_mode;
- int (*mmap_mapper)(struct videobuf_queue *q,
- struct videobuf_buffer *buf,
- struct vm_area_struct *vma);
u32 reg_cache[0];
};
@@ -1352,28 +1349,6 @@ static int omap1_cam_try_fmt(struct soc_
static bool sg_mode;
-/*
- * Local mmap_mapper wrapper,
- * used for detecting videobuf-dma-contig buffer allocation failures
- * and switching to videobuf-dma-sg automatically for future attempts.
- */
-static int omap1_cam_mmap_mapper(struct videobuf_queue *q,
- struct videobuf_buffer *buf,
- struct vm_area_struct *vma)
-{
- struct soc_camera_device *icd = q-priv_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
- struct omap1_cam_dev *pcdev = ici-priv;
- int ret;
-
- ret = pcdev-mmap_mapper(q, buf, vma);
-
- if (ret == -ENOMEM)
- sg_mode = true;
-
- return ret;
-}
-
static void omap1_cam_init_videobuf(struct videobuf_queue *q,
struct soc_camera_device *icd)
{
@@ -1391,18 +1366,8 @@ static void omap1_cam_init_videobuf(stru
V4L2_BUF_TYPE_VIDEO_CAPTURE, V4L2_FIELD_NONE,
sizeof(struct omap1_cam_buf), icd,
icd-video_lock);
- /* use videobuf mode (auto)selected with the module parameter */
+ /* use videobuf mode selected with the module parameter */
pcdev-vb_mode = sg_mode ? OMAP1_CAM_DMA_SG : OMAP1_CAM_DMA_CONTIG;
-
- /*
-* Ensure we substitute the videobuf-dma-contig version of the
-* mmap_mapper() callback with our own wrapper, used for switching
-* automatically to videobuf-dma-sg on buffer allocation failure.
-*/
- if (!sg_mode q-int_ops-mmap_mapper != omap1_cam_mmap_mapper) {
- pcdev-mmap_mapper = q-int_ops-mmap_mapper;
- q-int_ops-mmap_mapper = omap1_cam_mmap_mapper;
- }
}
static int omap1_cam_reqbufs(struct soc_camera_device *icd,
--
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 3.0] soc_camera: OMAP1: stop falling back to dma-sg on single -ENOMEM
On Thu 09 Jun 2011 at 14:07:22 Guennadi Liakhovetski wrote: Hi Janusz On Thu, 9 Jun 2011, Janusz Krzysztofik wrote: Since commit 6d3163ce86dd386b4f7bda80241d7fea2bc0bb1d, mm: check if any page in a pageblock is reserved before marking it MIGRATE_RESERVE, the OMAP1 camera driver behaviour while in videobuf-dma-contig mode can be observed as much more stable than before. Once all application programs are started up and nothing unexpected happens in the system, consecutive device open()s tend to succeed with almost 100% reliability. While the result is still not perfect, still prone to occasional -ENOMEM failures, I think there is no longer a need to fall back to more reliable but less effective, more resource hungry videobuf-dma-sg mode if a single open() fails, as long as users are still able to switch DMA modes from user space over the driver provided sysfs interface, should videobuf-dma-contig mode still happen to keep failing for them. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- Hi, While this patch is not a classic fix, not correcting anything that could be considered as a bug or regression, it is a simple consequence of unexpected but very welcome enhancement introduced during this merge window, so I hope it can be accepted in the rc cycle for that reason. Moreover, it provides no new, but simplifies existing code by removing no longer needed bits. Thanks for the patch. Hm... First of all, I'm not sure I'd try to push this after the -rc2. No problem. Secondly, I'm having a hard time seeing this as an improvement at all... Your driver is capable to work in two modes: contiguous and sg, right? Fortunately also, you are able to automatically switch to the less efficient, but easier to obtain mode at open() time No, not at the just failing open() time, but only on next open(). While developing this feature, I didn't find a better way of implementing it, and I'm probably still not able to, without replicating parts of videobuf-dma-contig layer with custom modifications, because of different pre-open() videobuf setup steps required. - I see this as an advantage. You say, after the quoted commit the contig DMA almost never fails. I believe, it almost never fails in your configuration. But if you put your system under a higher memory pressure, it still will fail repeatedly, right? And I'm not sure, it is always intuitive to the user, that they have to retry starting an application, after it fails with -ENOMEM. They do now, once on first fault, and based on my test results I could expect they might still have to do it only once from 3.0 on, even without auto fall back. If you really want to be able to prohibit falling back to SG, maybe you can add one more module parameter to enforce dma-contig? Is the reason, why you want to do this, because for your situation you'd prefer open() to fail rather to switch to SG? The reason was simple: after system start-up, open() usually fails for me only once, then keeps working quite reliably. But you are right saying that my test results may be not reproducible in a different environment. So, maybe let's forgot about this patch and wait until dma_alloc_coherent() starts working 100% reliably on OMAP1, or a different, more reliable than dma-contig videobuf/videobuf2 option is available. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
On Fri 10 Dec 2010 at 22:03:52 Janusz Krzysztofik wrote:
Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
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.
For OMAP1, which is ARMv5 or lower, device memory becomes
'uncacheable, unbufferable' which is luckily what is used for the
DMA coherent memory on those platforms - so no technical problem
here.
However, on ARMv6 and later, ioremapped memory is device memory,
which has different ordering wrt normal memory mappings, and may
appear on different busses on the CPU's interface. So, this is
something I don't encourage as it's unclear that the hardware will
work.
Essentially, dma_declare_coherent_memory() on ARM with main SDRAM
should be viewed as a 'it might work, it might not, and it might
stop working in the future' kind of interface. In other words,
there is no guarantee that this kind of thing will be supported in
the future.
I was affraid of an unswer of this kind. I'm not capable of comming
out with any better, alternative solutions. Any hints other than
giving up with that old videobuf-contig, coherent memory based
interface? Or can we agree on that 'luckily uncacheable,
unbufferable, SDRAM based DMA coherent memory' solution for now?
Russell, Tony,
Sorry for getting back to this old thread, but since my previous
attempts to provide[1] or support[2] a possibly better solution to the
problem all failed on one hand, and I can see patches not very different
from mine[3] being accepted for arch/arm/mach-{mx3,imx} during this and
previous merge windows[4][5][6] on the other, is there any chance for the
'dma_declare_coherent_memory() over a memblock_alloc()-free()-remove()
obtained area' based solution being accepted for omap1_camera as well if
I resend it refreshed?
BTW, commit 6d3163ce86dd386b4f7bda80241d7fea2bc0bb1d, mm: check if any
page in a pageblock is reserved before marking it MIGRATE_RESERVE,
almost corrected the problem for me, allowing for very stable device
operation in videobuf_dma_contig mode once all resident programs get
settled up and no unusual activity happens, but this is still not 100%
reliable, so I think that only using a kind of memory area reservered
during boot for the purpose can be considered as free of transient
-ENOMEM issues.
Thanks,
Janusz
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036419.html
[2]
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036551.html
[3]
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/034643.html
[4]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;h=164f7b5237cca2701dd2943928ec8d078877a28d
[5]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;h=031e912741746e4350204bb0436590ca0e993a7d
[6]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;h=dca7c0b4293a06d1ed9387e729a4882896abccc2
--
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 Thu 09 Jun 2011 at 00:13:30 Russell King - ARM Linux wrote: I stand by my answer to your patches quoted above from a technical point of view; we should not be mapping SDRAM using device mappings. That ioremap() inside dma_declare_coherent_memory() needs to die, Then how about your alternative, ARM specific solution, Avoid aliasing mappings in DMA coherent allocator? There was a series of initially two, then three patches, of which the two others (459c1517f987 ARM: DMA: Replace page_to_dma()/dma_to_page() with pfn_to_dma()/dma_to_pfn() and 9eedd96301ca ARM: DMA: top-down allocation in DMA coherent region) are already in the mainline tree. I'm still porting a copy of that third one from kernel version to version to have my device working 100% reliably, in hope you finally push it into the mainline. No plans against it? Or is there something about it I could help with? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] V4L: omap1-camera: fix huge lookup array
Dnia środa 18 maj 2011 o 16:11:30 Guennadi Liakhovetski napisał(a):
Since V4L2_MBUS_FMT_* codes have become large and sparse, they cannot
be used as array indices anymore.
Hi Guennadi,
Thanks for taking care of this.
Regards,
Janusz
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/omap1_camera.c | 41
++- 1 files changed, 30
insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/omap1_camera.c
b/drivers/media/video/omap1_camera.c
index 5954b93..fe577a9 100644
--- a/drivers/media/video/omap1_camera.c
+++ b/drivers/media/video/omap1_camera.c
@@ -990,63 +990,80 @@ static void omap1_cam_remove_device(struct
soc_camera_device *icd) }
/* Duplicate standard formats based on host capability of byte swapping */
-static const struct soc_mbus_pixelfmt omap1_cam_formats[] = {
- [V4L2_MBUS_FMT_UYVY8_2X8] = {
+static const struct soc_mbus_lookup omap1_cam_formats[] = {
+{
+ .code = V4L2_MBUS_FMT_UYVY8_2X8,
+ .fmt = {
.fourcc = V4L2_PIX_FMT_YUYV,
.name = YUYV,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_BE,
},
- [V4L2_MBUS_FMT_VYUY8_2X8] = {
+}, {
+ .code = V4L2_MBUS_FMT_VYUY8_2X8,
+ .fmt = {
.fourcc = V4L2_PIX_FMT_YVYU,
.name = YVYU,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_BE,
},
- [V4L2_MBUS_FMT_YUYV8_2X8] = {
+}, {
+ .code = V4L2_MBUS_FMT_YUYV8_2X8,
+ .fmt = {
.fourcc = V4L2_PIX_FMT_UYVY,
.name = UYVY,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_BE,
},
- [V4L2_MBUS_FMT_YVYU8_2X8] = {
+}, {
+ .code = V4L2_MBUS_FMT_YVYU8_2X8,
+ .fmt = {
.fourcc = V4L2_PIX_FMT_VYUY,
.name = VYUY,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_BE,
},
- [V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE] = {
+}, {
+ .code = V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
+ .fmt = {
.fourcc = V4L2_PIX_FMT_RGB555,
.name = RGB555,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_BE,
},
- [V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE] = {
+}, {
+ .code = V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
+ .fmt = {
.fourcc = V4L2_PIX_FMT_RGB555X,
.name = RGB555X,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_BE,
},
- [V4L2_MBUS_FMT_RGB565_2X8_BE] = {
+}, {
+ .code = V4L2_MBUS_FMT_RGB565_2X8_BE,
+ .fmt = {
.fourcc = V4L2_PIX_FMT_RGB565,
.name = RGB565,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_BE,
},
- [V4L2_MBUS_FMT_RGB565_2X8_LE] = {
+}, {
+ .code = V4L2_MBUS_FMT_RGB565_2X8_LE,
+ .fmt = {
.fourcc = V4L2_PIX_FMT_RGB565X,
.name = RGB565X,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_BE,
},
+},
};
static int omap1_cam_get_formats(struct soc_camera_device *icd,
@@ -1085,12 +1102,14 @@ static int omap1_cam_get_formats(struct
soc_camera_device *icd, case V4L2_MBUS_FMT_RGB565_2X8_LE:
formats++;
if (xlate) {
- xlate-host_fmt = omap1_cam_formats[code];
+ xlate-host_fmt = soc_mbus_find_fmtdesc(code,
+ omap1_cam_formats,
+ ARRAY_SIZE(omap1_cam_formats));
xlate-code = code;
xlate++;
dev_dbg(dev,
%s: providing format %s as byte swapped code
#%d\n,
- __func__, omap1_cam_formats[code].name, code);
+ __func__,
Re: V4L/ARM: videobuf-dma-contig no longer works on my ARM machine
Dnia sobota 09 kwiecień 2011 o 18:42:40 Jiri Slaby napisał(a): On 04/09/2011 05:10 PM, Janusz Krzysztofik wrote: (CC: Jiri Slaby, the author of the problematic change; truncate subject) On Sat, 09 Apr 2011, at 09:16:24, Russell King - ARM Linux wrote: On Sat, Apr 09, 2011 at 03:33:39AM +0200, Janusz Krzysztofik wrote: Since there were no actual problems reported before, I suppose the old code, which was passing to remap_pfn_range() a physical page number calculated from dma_alloc_coherent() privided dma_handle, worked correctly on all platforms actually using videobud-dma-config. No, it didn't when IOMMU was used. Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name a board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf-dma-config susbsystem, c) uses IOMMU? If there is one, than I agree that reverting the patch is not a good option. Because remap_pfn_range didn't get a physical page address. If I didn't understand it, I wouldn't try to find a solution other than reverting your patch. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Tue 12 Apr 2011 at 23:40:11 Russell King - ARM Linux wrote: On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote: The patch tries to solve this regression by using virt_to_phys(bus_to_virt(mem-dma_handle)) instead of problematic virt_to_phys(mem-vaddr). Who says that DMA handles are bus addresses in the strictest sense? DMA handles on ARM are the bus address to program 'dev' with in order for it to access the memory mapped by dma_alloc_coherent(). On some ARM platforms, this bus address is dependent on 'dev' - such as platforms with more than one root PCI bus, and so bus_to_virt() just doesn't hack it. Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? If there is one, then I agree that my short-term fix is wrong. What is really needed is for this problem - the mapping of DMA coherent memory into userspace - to be solved with a proper arch API rather than all these horrible hacks which subsystems instead invent. That's something I tried to do with the dma_mmap_coherent() stuff but it was shot down by linux-arch as (iirc) PA-RISC objected to it. Hence why ARM only implements it. I thought so too, but missed the fact that PowerPC implements it actually, even defining the ARCH_HAS_DMA_MMAP_COHERENT symbol, which ARM doesn't so far. Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide dma_mmap_coherent(). AFAICT, ARM implementation of dma_mmap_coherent() is not compatible with dma_declare_coherent_memory(), is it? If I'm wrong, please correct me, I'll get back to the idea presented in v1 of the fix. Otherwise, I think that switching to dma_mmap_coherent() is not an option for the videobuf-dma-contig subsystem as long as there is no good solution to the problem of dma_alloc_coherent() not guaranteed to succeed with high-order allocations at any time. Any chance for your already proposed (http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036463.html, http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/036809.html), or perhaps a new, better solution ever finding its way to the mainline tree? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia środa 13 kwiecień 2011 o 14:03:44 Sergei Shtylyov napisał(a): Hello. On 13-04-2011 1:06, Janusz Krzysztofik wrote: After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig Please specify the commit summary -- for the human readers. Hi, OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux napisał(a): On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote: Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong? Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed. In theory - of course. In practice - couldn't we now, close to -rc3, relax the rules a little bit and stop bothering with something that may break in the future if it doesn't break on any board supported so far (I hope)? I thought so too, but missed the fact that PowerPC implements it actually, even defining the ARCH_HAS_DMA_MMAP_COHERENT symbol, which ARM doesn't so far. So, there's no problem adding that symbol to ARM. OK, I can provide a patch as soon as dma_mmap_coherent() really works for me. Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide dma_mmap_coherent(). AFAICT, ARM implementation of dma_mmap_coherent() is not compatible with dma_declare_coherent_memory(), is it? If I'm wrong, please correct me, I'll get back to the idea presented in v1 of the fix. 1. dma_declare_coherent_memory() doesn't work on ARM for memory which already exists (its not permitted to ioremap() the kernel direct-mapped memory due to attribute aliasing issues.) But you had once inspired (http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/034879.html), then was supporting my attempts towards pushing ioremap() out of this function up to the caller (http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036419.html), which would allow for doing sane preallocations via dma_coherent_alloc() and caching them back into dma_declare_coherent_memory() at boot time for later reuse mempry from that pool as DMA coherent. Now, should my attepmts succeded, we would still end up with the following: 2. dma_declare_coherent_memory() totally bypasses the DMA allocator, Would it still, under your terms, if it could accept dma_alloc_coherent() obtained cpu addresses, not trying to ioremap() them? and so dma_mmap_coherent() has no knowledge of how to map the memory. I think it _could_ have a good knowledge if that memory was first preallocated with dma_alloc_coherent() at boot time, unless that memory was then fetched from that pool in smaller chunks. I think this is the reason it didn't work for me when I tried using this method with dma_mmap_coherent(). Am I missing something? If we had a proper way to map DMA memory into userspace, then we wouldn't have these issues as the dma_declare_coherent_memory() would already support that. And actually, talking about dma_declare_coherent_memory(), you've just provided a reason why virt_to_phys(bus_to_virt(dma_handle)) won't work - dma_declare_coherent_memory() can be used to provide on-device memory where the virt/handle may not be mappable with bus_to_virt(). While I have no problems to agree with the principles, I can confirm that this _hack_ does coexist nicely with dma_declare_coherent_memory(), at least on my OMAP1 based board. It also coexists nicely with your WiP patches I mentioned before and you didn't quote here, so I provide the links again: http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036461.html, http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/036809.html. OTOH, dma_mmap_coherent() didn't work for me when I tried using it on top of those patches. This doesn't mean I'm against a dma_mmap_coherent() based solution. I just think we can't afford switching to it _now_. Otherwise, I think that switching to dma_mmap_coherent() is not an option for the videobuf-dma-contig subsystem as long as there is no good solution to the problem of dma_alloc_coherent() not guaranteed to succeed with high-order allocations at any time. Let me repeat: there is no official API or way to map DMA memory into userspace. Doesn't dma_mmap_coherent(), already available on 2 architectures, ARM and PPC, aim to provide the correct API? From the fact you didn't dispute v1 of my patch, which provided a dma_mmap_coherent() based code path for architectures supporting it, I would conclude this is a solution which might get your support, isn't it? However, I think that even if it was a _proper_ solution to the problem, it couldn't be accepted as a fix during the rc cycle
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia środa 13 kwiecień 2011 o 19:36:30 Sergei Shtylyov napisał(a): Hello. Janusz Krzysztofik wrote: After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig Please specify the commit summary -- for the human readers. Hi, OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code. I wasn't asking you to rework your summary but to specify the summary of the commit you've mentioned (in parens). Ah, I see. How about just reordered wording: After commit 35d9f510b67b10338161aba6229d4f55b4000f5b (switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range()), Do you think this would be clear enough? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia środa 13 kwiecień 2011 o 23:01:55 Janusz Krzysztofik napisał(a): Dnia środa 13 kwiecień 2011 o 19:36:30 Sergei Shtylyov napisał(a): Hello. Janusz Krzysztofik wrote: After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig Please specify the commit summary -- for the human readers. Hi, OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code. I wasn't asking you to rework your summary but to specify the summary of the commit you've mentioned (in parens). Ah, I see. How about just reordered wording: After commit 35d9f510b67b10338161aba6229d4f55b4000f5b (switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range()), Do you think this would be clear enough? Oh no, I probably missed your point again. You meant just quoting the commit original summary line, didn't you? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia czwartek 14 kwiecień 2011 o 00:00:08 Russell King - ARM Linux napisał(a): On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote: Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux napisał(a): On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote: Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong? Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed. In theory - of course. In practice - couldn't we now, close to -rc3, relax the rules a little bit and stop bothering with something that may break in the future if it doesn't break on any board supported so far (I hope)? If we are worried about closeness to -final, then what should happen is that the original commit is reverted; the fix for IOMMUs resulted in a regression for existing users which isn't trivial to resolve without risking possible breakage of other users. Do we even know whether bus_to_virt(iommu_bus_address) works? I suspect it doesn't, so by doing so you're already re-breaking the IOMMU case. Hard to deny with only me having actually tested this dirty hack on one single board :) Thanks for your support, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
Dnia wtorek 12 kwiecień 2011 o 17:39:35 Aguirre, Sergio napisał(a): On Mon, Apr 11, 2011 at 4:52 PM, Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: Dnia poniedziałek 11 kwiecień 2011 o 22:05:35 Aguirre, Sergio napisał(a): Please find below a refreshed patch, which should be based on mainline commit: Hi, This version works for me, and fixes the regression. Ok, Thanks for testing. I forgot to mention: the patch didn't apply cleanly, I had to unwrap a few lines manually, so you may want to resend it unwrapped. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used
for obtaining page frame number passed to remap_pfn_range()
(commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig
stopped working on my ARM based board. The ARM architecture maintainer,
Russell King, confirmed that using something like
virt_to_phys(dma_alloc_coherent()) is not supported on ARM, and can be
broken on other architectures as well. The author of the change, Jiri
Slaby, also confirmed that his code may not work on all architectures.
The patch tries to solve this regression by using
virt_to_phys(bus_to_virt(mem-dma_handle)) instead of problematic
virt_to_phys(mem-vaddr). I think this should work even if those
translations would occure inaccurate for DMA addresses, since possible
errors introduced by both translations, performed in opposite
directions, should compensate.
Tested on ARM OMAP1 based Amstrad Delta board.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
v1 - v2 changes:
- drop dma_mmap_coherent() path, it may not work correctly for device
memory preallocated with dma_declare_coherent_memory().
drivers/media/video/videobuf-dma-contig.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- git/drivers/media/video/videobuf-dma-contig.c.orig 2011-04-09
00:38:45.0 +0200
+++ git/drivers/media/video/videobuf-dma-contig.c 2011-04-12
22:36:44.0 +0200
@@ -300,8 +300,8 @@ static int __videobuf_mmap_mapper(struct
vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
retval = remap_pfn_range(vma, vma-vm_start,
-PFN_DOWN(virt_to_phys(mem-vaddr)),
-size, vma-vm_page_prot);
+ PFN_DOWN(virt_to_phys(bus_to_virt(mem-dma_handle))),
+ size, vma-vm_page_prot);
if (retval) {
dev_err(q-dev, mmap: remap failed with error %d. , retval);
dma_free_coherent(q-dev, mem-size,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Mon 11 Apr 2011 at 02:42:13 Mauro Carvalho Chehab wrote:
Em 10-04-2011 19:47, Janusz Krzysztofik escreveu:
After switching from mem-dma_handle to virt_to_phys(mem-vaddr)
used for obtaining page frame number passed to remap_pfn_range()
(commit 35d9f510b67b10338161aba6229d4f55b4000f5b),
videobuf-dma-contig stopped working on my ARM based board. The ARM
architecture maintainer, Russell King, confirmed that using
something like
virt_to_phys(dma_alloc_coherent()) is not supported on ARM, and can
be broken on other architectures as well. The author of the
change, Jiri Slaby, also confirmed that his code may not work on
all architectures.
The patch takes two different countermeasures against this
regression:
1. On architectures which provide dma_mmap_coherent() function (ARM for
now), use it instead of just remap_pfn_range(). The code is
stollen from sound/core/pcm_native.c:snd_pcm_default_mmap().
Set vma-vm_pgoff to 0 before calling dma_mmap_coherent(), or it
fails.
2. On other architectures, use virt_to_phys(bus_to_virt(mem-dma_handle))
instead of problematic virt_to_phys(mem-vaddr). This should
work even if those translations would occure inaccurate for DMA
addresses, since possible errors introduced by both
calculations, performed in opposite directions, should
compensate.
...
+#ifndef ARCH_HAS_DMA_MMAP_COHERENT
+/* This should be defined / handled globally! */
+#ifdef CONFIG_ARM
+#define ARCH_HAS_DMA_MMAP_COHERENT
+#endif
+#endif
+
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
Hmm... IMHO, this seems too confusing. Why not use just something
like:
#if defined(CONFIG_ARM) || defined(ARCH_HAS_DMA_MMAP_COHERENT)
Better yet: why should CONFIG_ARM should explicitly be checked here?
Is it the only architecture where this would fail?dma_mmap_coherent
Hmm...
$ git grep ARCH_HAS_DMA_MMAP_COHERENT arch
arch/powerpc/include/asm/dma-mapping.h:#define ARCH_HAS_DMA_MMAP_COHERENT
My fault, I've just missed the fact that PPC also provides
dma_mmap_coherent() AND, unlike ARM, defines ARCH_HAS_DMA_MMAP_COHERENT
as well. Then, I would drop all above ifdefery except the last '#ifdef
ARCH_HAS_DMA_MMAP_COHERENT', and also submit a separate patch against
arch/arm/include/asm/dma-mapping.h for it to define
ARCH_HAS_DMA_MMAP_COHERENT, OK?
The code is saying that dma_mmap_coherent should be used only on ARM
and PPC architectures, and remap_pfn_range should be used otherwise.
Yes, because only these two architectures provide this function:
$ grep -r EXPORT_SYMBOL.*(dma_mmap_coherent) arch
arch/powerpc/kernel/dma.c:EXPORT_SYMBOL_GPL(dma_mmap_coherent);
arch/arm/mm/dma-mapping.c:EXPORT_SYMBOL(dma_mmap_coherent);
Other must keep using remap_pfn_range(), as they used to before.
Are you sure that this will work on the other architectures?
If you mean using virt_to_phys(bus_to_virt(mem-dma_handle)) instead of
that problematic virt_to_phys(mem-vaddr) - yes, I think this should
work not any worth than before, and shouldn't break anything on any
architecture, including those not suffering from the problem.
What I'm not sure about is if this really helps on all those affected
architectures (if still any) which don't provide their
dma_mmap_coherent() implementation yet. I can only confirm this helps on
my ARM.
I've already asked for testing to get an idea which architectures those
could be
(http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/047701.html),
but haven't received any response yet.
I really prefer to have one standard way for doing it, that would
be architecture-independent. Media drivers or core should not have
arch-dependent code inside.
Sure, but here we have a choice between the still working but
depreciated usage of bus_to_virt() for tranlating a DMA bus address, and
a new way of doing things with dma_mmap_coherent(), which is not (yet)
widely supported. If you think we should limit our choice to the
depreciated way, please tell me, I'll modify the patch the way you like
it.
Thanks,
Janusz
+ vma-vm_pgoff = 0;
+ retval = dma_mmap_coherent(q-dev, vma, mem-vaddr, mem-dma_handle,
+ mem-size);
+#else
size = vma-vm_end - vma-vm_start;
size = (size mem-size) ? size : mem-size;
vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
retval = remap_pfn_range(vma, vma-vm_start,
-PFN_DOWN(virt_to_phys(mem-vaddr)),
-size, vma-vm_page_prot);
+ PFN_DOWN(virt_to_phys(bus_to_virt(mem-dma_handle))),
+ size, vma-vm_page_prot);
+#endif
if (retval) {
dev_err(q-dev, mmap: remap failed with error %d. , retval);
dma_free_coherent(q-dev, mem-size,
--
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
Re: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
Dnia poniedziałek 11 kwiecień 2011 o 10:58:26 Guennadi Liakhovetski napisał(a): A recent patch has given individual soc-camera host drivers a possibility to calculate .sizeimage and .bytesperline pixel format fields internally, however, some drivers relied on the core calculating these values for them, following a default algorithm. This patch restores the default calculation for such drivers. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Hi Guennadi, Works for me on my OMAP1 camera (Amstrad Delta, 2.6.39-rc2). You can add my Tested-by: if you like. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Mon 11 Apr 2011 at 02:42:13 Mauro Carvalho Chehab wrote: Em 10-04-2011 19:47, Janusz Krzysztofik escreveu: After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig stopped working on my ARM based board. The ARM architecture maintainer, Russell King, confirmed that using something like virt_to_phys(dma_alloc_coherent()) is not supported on ARM, and can be broken on other architectures as well. The author of the change, Jiri Slaby, also confirmed that his code may not work on all architectures. The patch takes two different countermeasures against this regression: 1. On architectures which provide dma_mmap_coherent() function (ARM for now), use it instead of just remap_pfn_range(). The code is stollen from sound/core/pcm_native.c:snd_pcm_default_mmap(). Set vma-vm_pgoff to 0 before calling dma_mmap_coherent(), or it fails. 2. On other architectures, use virt_to_phys(bus_to_virt(mem-dma_handle)) instead of problematic virt_to_phys(mem-vaddr). This should work even if those translations would occure inaccurate for DMA addresses, since possible errors introduced by both calculations, performed in opposite directions, should compensate. Both solutions tested on ARM OMAP1 based Amstrad Delta board. ... The code is saying that dma_mmap_coherent should be used only on ARM and PPC architectures, and remap_pfn_range should be used otherwise. Are you sure that this will work on the other architectures? I really prefer to have one standard way for doing it, that would be architecture-independent. Media drivers or core should not have arch-dependent code inside. More looking at this and making more tests, I found that the dma_mmap_coherent() method, working correctly on OMAP1 which has no countermeasures against unpredictable dma_alloc_coherent() runtime behaviour implemented, may not be compatible with all those dma_declare_coherent_memory() and alike workarounds, still being used, more or less successfully, on other ARM platforms/machines/boards. Under such circumstances, I'd opt for choosing the depreciated, but hopefully working, bi-directional translation method, ie. virt_to_phys(bus_to_virt(mem-dma_handle)), as the regression fix. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
Dnia poniedziałek 11 kwiecień 2011 o 18:58:51 Guennadi Liakhovetski napisał(a): On Mon, 11 Apr 2011, Aguirre, Sergio wrote: Ok. And how about the attached patch? Would that work? Yes, I think, ot would work too, only the call to soc_camera_xlate_by_fourcc() in the S_FMT case is superfluous, after ici-ops-set_fmt() we already have it in icd-current_fmt-host_fmt. Otherwise - yes, we could do it this way too. Janusz, could you test, please? Looks like not based on the current mainline (-rc2) tree: CHECK drivers/media/video/soc_camera.c drivers/media/video/soc_camera.c:146:9: error: undefined identifier 'pixfmtstr' CC drivers/media/video/soc_camera.o drivers/media/video/soc_camera.c: In function 'soc_camera_try_fmt': drivers/media/video/soc_camera.c:146: error: implicit declaration of function 'pixfmtstr' drivers/media/video/soc_camera.c:146: warning: too few arguments for format drivers/media/video/soc_camera.c: In function 'soc_camera_try_fmt_vid_cap': drivers/media/video/soc_camera.c:180: warning: unused variable 'ici' Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
Dnia poniedziałek 11 kwiecień 2011 o 22:05:35 Aguirre, Sergio
napisał(a):
Please find below a refreshed patch, which should be based on
mainline commit:
Hi,
This version works for me, and fixes the regression.
Thanks,
Janusz
From f767059c12c755ebe79c4b74de17c23a257007c7 Mon Sep 17 00:00:00
2001
From: Sergio Aguirre saagui...@ti.com
Date: Mon, 11 Apr 2011 11:14:33 -0500
Subject: [PATCH] V4L: soc-camera: regression fix: calculate
.sizeimage in soc_camera.c
A recent patch has given individual soc-camera host drivers a
possibility to calculate .sizeimage and .bytesperline pixel format
fields internally, however, some drivers relied on the core
calculating these values for them, following a default algorithm.
This patch restores the default calculation for such drivers.
Based on initial patch by Guennadi Liakhovetski, found here:
http://www.spinics.net/lists/linux-media/msg31282.html
Except that this covers try_fmt aswell.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/soc_camera.c | 48
+ 1 files changed, 42
insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c index 4628448..dcc6623 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -136,11 +136,50 @@ unsigned long
soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
}
EXPORT_SYMBOL(soc_camera_apply_sensor_flags);
+#define pixfmtstr(x) (x) 0xff, ((x) 8) 0xff, ((x) 16)
0xff, \ + ((x) 24) 0xff
+
+static int soc_camera_try_fmt(struct soc_camera_device *icd,
+ struct v4l2_format *f)
+{
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+ struct v4l2_pix_format *pix = f-fmt.pix;
+ int ret;
+
+ dev_dbg(icd-dev, TRY_FMT(%c%c%c%c, %ux%u)\n,
+ pixfmtstr(pix-pixelformat), pix-width, pix-height);
+
+ pix-bytesperline = 0;
+ pix-sizeimage = 0;
+
+ ret = ici-ops-try_fmt(icd, f);
+ if (ret 0)
+ return ret;
+
+ if (!pix-sizeimage) {
+ if (!pix-bytesperline) {
+ const struct soc_camera_format_xlate *xlate;
+
+ xlate = soc_camera_xlate_by_fourcc(icd,
pix-pixelformat);
+ if (!xlate)
+ return -EINVAL;
+
+ ret = soc_mbus_bytes_per_line(pix-width,
+ xlate-host_fmt);
+ if (ret 0)
+ pix-bytesperline = ret;
+ }
+ if (pix-bytesperline)
+ pix-sizeimage = pix-bytesperline * pix-height;
+ }
+
+ return 0;
+}
+
static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *f)
{
struct soc_camera_device *icd = file-private_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
WARN_ON(priv != file-private_data);
@@ -149,7 +188,7 @@ static int soc_camera_try_fmt_vid_cap(struct file
*file, void *priv,
return -EINVAL;
/* limit format to hardware capabilities */
- return ici-ops-try_fmt(icd, f);
+ return soc_camera_try_fmt(icd, f);
}
static int soc_camera_enum_input(struct file *file, void *priv,
@@ -362,9 +401,6 @@ static void soc_camera_free_user_formats(struct
soc_camera_device *icd)
icd-user_formats = NULL;
}
-#define pixfmtstr(x) (x) 0xff, ((x) 8) 0xff, ((x) 16)
0xff, \ - ((x) 24) 0xff
-
/* Called with .vb_lock held, or from the first open(2), see comment
there */ static int soc_camera_set_fmt(struct soc_camera_device
*icd, struct v4l2_format *f)
@@ -377,7 +413,7 @@ static int soc_camera_set_fmt(struct
soc_camera_device *icd, pixfmtstr(pix-pixelformat), pix-width,
pix-height);
/* We always call try_fmt() before set_fmt() or set_crop() */
- ret = ici-ops-try_fmt(icd, f);
+ ret = soc_camera_try_fmt(icd, f);
if (ret 0)
return ret;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization
Dnia niedziela 10 kwiecień 2011 o 18:00:14 Guennadi Liakhovetski napisał(a): Hi Janusz On Sat, 9 Apr 2011, Janusz Krzysztofik wrote: Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline and sizeimage memebers of v4l2_pix_format structure have no longer been calculated inside soc_camera_g_fmt_vid_cap(), but rather passed via soc_camera_device structure from a host driver callback invoked by soc_camera_set_fmt(). OMAP1 camera host driver has never been providing these parameters, so it no longer works correctly. Fix it by adding suitable assignments to omap1_cam_set_fmt(). Thanks for the patch, but now it looks like many soc-camera host drivers are re-implementing this very same calculation in different parts of their code - in try_fmt, set_fmt, get_fmt. Why don't we unify them all, implement this centrally in soc_camera.c and remove all those calculations? Wasn't it already unified before commit in question? Could you cook up a patch or maybe several patches - for soc_camera.c and all drivers? Perhaps I could, as soon as I found some spare time, but first I'd have to really understand why we need bytesperline or sizeimage handling being changed from how they worked before commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a was introduced. I never had a need to customize bytesperline or sizeimage calculations in my driver. But even then, I think these new patches would rather qualify for next merge window, while the OMAP1 driver case is just a regression, caused by an alredy applied, unrelated change to the underlying framework, and requires a fix if that change is not going to be reverted. Maybe the author of the change, Sergio Aguirre form TI (CCing him), could rework his patch in a way which wouldn't impose, as a side effect, the new requirement of those structure members being passed from host drivers? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.39] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used
for obtaining page frame number passed to remap_pfn_range()
(commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig
stopped working on my ARM based board. The ARM architecture maintainer,
Russell King, confirmed that using something like
virt_to_phys(dma_alloc_coherent()) is not supported on ARM, and can be
broken on other architectures as well. The author of the change, Jiri
Slaby, also confirmed that his code may not work on all architectures.
The patch takes two different countermeasures against this regression:
1. On architectures which provide dma_mmap_coherent() function (ARM for
now), use it instead of just remap_pfn_range(). The code is stollen
from sound/core/pcm_native.c:snd_pcm_default_mmap().
Set vma-vm_pgoff to 0 before calling dma_mmap_coherent(), or it
fails.
2. On other architectures, use virt_to_phys(bus_to_virt(mem-dma_handle))
instead of problematic virt_to_phys(mem-vaddr). This should work
even if those translations would occure inaccurate for DMA addresses,
since possible errors introduced by both calculations, performed in
opposite directions, should compensate.
Both solutions tested on ARM OMAP1 based Amstrad Delta board.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/media/video/videobuf-dma-contig.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
--- linux-2.6.39-rc2/drivers/media/video/videobuf-dma-contig.c.orig
2011-04-09 00:38:45.0 +0200
+++ linux-2.6.39-rc2/drivers/media/video/videobuf-dma-contig.c 2011-04-10
15:00:23.0 +0200
@@ -295,13 +295,26 @@ static int __videobuf_mmap_mapper(struct
/* Try to remap memory */
+#ifndef ARCH_HAS_DMA_MMAP_COHERENT
+/* This should be defined / handled globally! */
+#ifdef CONFIG_ARM
+#define ARCH_HAS_DMA_MMAP_COHERENT
+#endif
+#endif
+
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ vma-vm_pgoff = 0;
+ retval = dma_mmap_coherent(q-dev, vma, mem-vaddr, mem-dma_handle,
+ mem-size);
+#else
size = vma-vm_end - vma-vm_start;
size = (size mem-size) ? size : mem-size;
vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
retval = remap_pfn_range(vma, vma-vm_start,
-PFN_DOWN(virt_to_phys(mem-vaddr)),
-size, vma-vm_page_prot);
+ PFN_DOWN(virt_to_phys(bus_to_virt(mem-dma_handle))),
+ size, vma-vm_page_prot);
+#endif
if (retval) {
dev_err(q-dev, mmap: remap failed with error %d. , retval);
dma_free_coherent(q-dev, mem-size,
--
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: V4L/ARM: videobuf-dma-contig no longer works on my ARM machine
(CC: Jiri Slaby, the author of the problematic change; truncate subject) On Sat, 09 Apr 2011, at 09:16:24, Russell King - ARM Linux wrote: On Sat, Apr 09, 2011 at 03:33:39AM +0200, Janusz Krzysztofik wrote: Since there were no actual problems reported before, I suppose the old code, which was passing to remap_pfn_range() a physical page number calculated from dma_alloc_coherent() privided dma_handle, worked correctly on all platforms actually using videobud-dma-config. Now, on my ARM machine, a completely different, then completely wrong physical address, calculated as virt_to_phys(dma_alloc_coherent()), is used instead of the dma_handle, which causes the machine to hang. virt_to_phys(dma_alloc_coherent()) is and always has been invalid, and will break on several architectures apart from ARM. Hi Russell, Thanks for confirmation. For now, I have two working, but not very elegant, solutions: 1. For architectures which provide dma_mmap_coherent() (only ARM for now), use it instead of remap_pfn_range(). However, this requires setting vma-vm_pgoff to 0 before calling dma_mmap_coherent(). I don't really understand what this vma-vm_pgoff business is all about, I've only verified that: a) a non-zero value, comming with any but the first buffer, for a reason not quite clear to me, breaks comparison of the requested vma size, calculated as: (vma-vm_end - vma-vm_start) PAGE_SHIFT with the just allocated arm_vmregion avaliable space, calculated as: ((c-vm-end - c-vm_start) PAGE_SHIFT) - vma-vm_pgoff b) vma-vm_pgoff is overwriten, for a reason not quite clear to me, by remap_pfn_range() called from dma_mmap_coherent(), so first resetting its value to 0 should not affect anything else but dma_mmap_coherent(). If someone can explain me how this vm_pgoff handling inconsistency should be fixed without dirty hacks, I can try to implement it. 2. Use depreciated bus_to_virt(dma_handle) instead of mem-vaddr, like this: remap_pfn_range(..., PFN_DOWN(virt_to_phys(bus_to_virt(dma_handle))), ...) If 1. is acceppted, then 2. may still be considered for architectures which neither support virt_to_phys(dma_alloc_coherent()) nor provide their own dma_mmap_coherent() implementation. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization
Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline and sizeimage memebers of v4l2_pix_format structure have no longer been calculated inside soc_camera_g_fmt_vid_cap(), but rather passed via soc_camera_device structure from a host driver callback invoked by soc_camera_set_fmt(). OMAP1 camera host driver has never been providing these parameters, so it no longer works correctly. Fix it by adding suitable assignments to omap1_cam_set_fmt(). Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- drivers/media/video/omap1_camera.c |6 ++ 1 file changed, 6 insertions(+) --- linux-2.6.39-rc2/drivers/media/video/omap1_camera.c.orig2011-04-06 14:30:37.0 +0200 +++ linux-2.6.39-rc2/drivers/media/video/omap1_camera.c 2011-04-09 00:16:36.0 +0200 @@ -1292,6 +1292,12 @@ static int omap1_cam_set_fmt(struct soc_ pix-colorspace = mf.colorspace; icd-current_fmt = xlate; + pix-bytesperline = soc_mbus_bytes_per_line(pix-width, + xlate-host_fmt); + if (pix-bytesperline 0) + return pix-bytesperline; + pix-sizeimage = pix-height * pix-bytesperline; + return 0; } -- 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
V4L/ARM: videobuf-dma-contig no longer works on my ARM machine (was: [PATCH v3] SoC Camera: add driver for OMAP1 camera interface)
On Wendesday, 23 March 2011, at 11:00:06, Guennadi Liakhovetski wrote: You might want to retest ams-delta with the camera on the current (next or git://linuxtv.org/media_tree.git staging/for_v2.6.39) kernel ... Hi Guennadi, With the patch I've just submitted to the linux-media list (http://www.spinics.net/lists/linux-media/msg31255.html), the 2.6.39-rc2 OMAP1 camera driver still works for me as before, but only in SG mode. I'm no longer able to use it in CONTIG mode after videobuf-dma-contig.c has been changed with commit 35d9f510b67b10338161aba6229d4f55b4000f5b, V4L: videobuf, don't use dma addr as physical, supposed to correct potential issues on IOMMU euqipped machines. Since there were no actual problems reported before, I suppose the old code, which was passing to remap_pfn_range() a physical page number calculated from dma_alloc_coherent() privided dma_handle, worked correctly on all platforms actually using videobud-dma-config. Now, on my ARM machine, a completely different, then completely wrong physical address, calculated as virt_to_phys(dma_alloc_coherent()), is used instead of the dma_handle, which causes the machine to hang. AFAICS, incompatibility of the new code with the ARM architecture has been already pointed out as a potential issue by Lauent Pinchart (http://www.spinics.net/lists/linux-media/msg29544.html), but the patch has been accepted regardless. I suspect the problem may affect other ARM subarchitectures, not only OMAP1, but have no way to verify this. Anyone with a suitable hardware, can you please verify and report if your machine is affected or not? I've tried to resolve the problem by conditionally (#ifdef CONFIG_ARM) replacing remap_pfn_range() with ARM specific dma_mmap_coherent(), but with not much success so far. While this still seems a possibly correct solution to me (see sound/core/pcm_native.c for an example, architecture independent driver code which already implements a similiar method), I found that the dma_mmap_coherent() does its job for me only with the first buffer, failing with the second one because of negative buffer size vs. available vma space comparison. It seems to me that there may be something wrong with vma-vm_pgoff handling, but I'm not sure if in the V4L videobuf, or in the ARM DMA, or in a yet another piece of code. Not being able to work out a solution myself, other than reverting back to the old code for ARM, I hope someone can come out with a better idea. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] SoC Camera: add driver for OMAP1 camera interface
On Wednesday, 23 March 2011, at 11:00:06, Guennadi Liakhovetski wrote:
Hi Janusz
You might want to retest ams-delta with the camera on the current
(next or
git://linuxtv.org/media_tree.git staging/for_v2.6.39
) kernel - I suspect, you'll need something similar to
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructu
re/30728
Hi Guennadi,
Thanks for bringing this issue to my attention. However, we alread have
something like
.dev= {
...
.coherent_dma_mask = DMA_BIT_MASK(32),
},
defined inside the platform_device structure registered for our OMAP1
camera device, so shouldn't be affected.
Anyway, I have the camera driver review/upgrade task already sitting in
my todo list for a few weeks, and hope to find some spare time to deal
with it soon, so will verify that as well.
Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma_declare_coherent_memory: push ioremap() up to caller
Sunday 26 December 2010 18:45:00 Guennadi Liakhovetski wrote: On Sat, 25 Dec 2010, Janusz Krzysztofik wrote: [snip] Passing the virtual address allows the API to become much more flexible. Not only that, it allows it to be used on ARM, rather than becoming (as it currently stands) prohibited on ARM. I believe that putting ioremap() inside this API was the wrong thing to do, and moving it outside makes the API much more flexible and usable. It's something I still fully support. Thanks, this is what I was missing, having my point of view rather my machine centric, with not much wider experience. I'll quote your argumentation in next iteration of this patch if required. AFAIU, this patch is similar to the previous two attempts: http://www.spinics.net/lists/linux-sh/msg05482.html and http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructur e/22271 but is even more intrusive, because those two previous attempts added new functions, whereas this one is modifying an existing one. Both those two attempts have been NACKed by FUJITA Tomonori, btw, he is not on the otherwise extensive CC list for this patch. Hi Guennadi, I composed that extensive CC list based on what I was able to find in MAINTAINERS for any files being modified, additionally adding Catalin Marinas as one of the idea promoters. FUJITA Tomonori's name was not specified there, nor was he mentioned as an author of any of those files. Adding him per your advice. NB, the rationale quoted above is provided by courtesy of Russell King, and not of my authoriship, as it may look like at a first glance from your snip result. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma_declare_coherent_memory: push ioremap() up to caller
Friday 24 December 2010 14:02:00 Russell King - ARM Linux wrote: On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote: The patch tries to implement a solution suggested by Russell King, http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December /035264.html. It is expected to solve video buffer allocation issues for at least a few soc_camera I/O memory less host interface drivers, designed around the videobuf_dma_contig layer, which allocates video buffers using dma_alloc_coherent(). Created against linux-2.6.37-rc5. Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch, patterned upon two mach-mx3 machine types which already try to use the dma_declare_coherent_memory() method for reserving a region of system RAM preallocated with another dma_alloc_coherent(). Compile tested for all modified files except arch/sh/drivers/pci/fixups-dreamcast.c. Another note: with the pair of patches I've sent to the linux-arm-kernel list earlier today changing the DMA coherent allocator to steal memory from the system at boot. This means there's less need to pre-allocate DMA memory - if there's sufficient contiguous space in the DMA region to satisfy the allocation, then the allocation will succeed. It's also independent of the maximum page size from the kernel's memory allocators too. So I suspect that mach-mx3 (and others) no longer need to do their own pre-allocation anymore if both of these patches go in. Then, my rationale will no longer be valid. So, either drop my patch if you think you have finally come out with a better solution which doesn't touch any system-wide API, or suggest a new justification for use in the commit log if you think still the patch solves something important. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma_declare_coherent_memory: push ioremap() up to caller
Friday 24 December 2010 16:41:20 Russell King - ARM Linux napisał(a): On Fri, Dec 24, 2010 at 02:55:25PM +0100, Janusz Krzysztofik wrote: Friday 24 December 2010 14:02:00 Russell King - ARM Linux wrote: On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote: The patch tries to implement a solution suggested by Russell King, http://lists.infradead.org/pipermail/linux-arm-kernel/2010-Dece mber /035264.html. It is expected to solve video buffer allocation issues for at least a few soc_camera I/O memory less host interface drivers, designed around the videobuf_dma_contig layer, which allocates video buffers using dma_alloc_coherent(). Created against linux-2.6.37-rc5. Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch, patterned upon two mach-mx3 machine types which already try to use the dma_declare_coherent_memory() method for reserving a region of system RAM preallocated with another dma_alloc_coherent(). Compile tested for all modified files except arch/sh/drivers/pci/fixups-dreamcast.c. Another note: with the pair of patches I've sent to the linux-arm-kernel list earlier today changing the DMA coherent allocator to steal memory from the system at boot. This means there's less need to pre-allocate DMA memory - if there's sufficient contiguous space in the DMA region to satisfy the allocation, then the allocation will succeed. It's also independent of the maximum page size from the kernel's memory allocators too. So I suspect that mach-mx3 (and others) no longer need to do their own pre-allocation anymore if both of these patches go in. Then, my rationale will no longer be valid. So, either drop my patch if you think you have finally come out with a better solution which doesn't touch any system-wide API, or suggest a new justification for use in the commit log if you think still the patch solves something important. No. It's not clear whether my pair of patches are both going to make it into the kernel, or even what timeframe they're going to make it in. Irrespective of that, we do need a solution to this problem so that this stuff starts working again. In any case, your patch makes complete sense through and through: 1. if other architecture/machine wants to reserve a chunk of DMA-able memory for a specific device (eg, because of a restriction on the number of DMA address bits available) and it's completely DMA coherent, it shouldn't have to go through the pains of having that memory unconditionally ioremap'd. 2. What if the memory being provided from some source where you already have the mapping setup in a specific way for a reason? For example, say I have an ARM design, and all peripherals are in a single 256MB memory region, which includes a chunk of SRAM set aside for DMA purposes. Let's say I can map that really efficiently by a few page table entries, which means relatively little TLB usage for accessing this region. With the current API, it becomes difficult to pass that mapping through the dma_declare_coherent_memory() because the physical address goes through ioremap(), which obfuscates what's going on. However, if I could pass the bus and virtual address, then there's no ambiguity over what I want to do. What if I want to declare memory to the DMA coherent allocator with attributes different from what ioremap() gives me, maybe with write combining properties (because it happens to be safe for the specific device) ? Passing the virtual address allows the API to become much more flexible. Not only that, it allows it to be used on ARM, rather than becoming (as it currently stands) prohibited on ARM. I believe that putting ioremap() inside this API was the wrong thing to do, and moving it outside makes the API much more flexible and usable. It's something I still fully support. Thanks, this is what I was missing, having my point of view rather my machine centric, with not much wider experience. I'll quote your argumentation in next iteration of this patch if required. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dma_declare_coherent_memory: push ioremap() up to caller
The patch tries to implement a solution suggested by Russell King,
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/035264.html.
It is expected to solve video buffer allocation issues for at least a
few soc_camera I/O memory less host interface drivers, designed around
the videobuf_dma_contig layer, which allocates video buffers using
dma_alloc_coherent().
Created against linux-2.6.37-rc5.
Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch,
patterned upon two mach-mx3 machine types which already try to use the
dma_declare_coherent_memory() method for reserving a region of system
RAM preallocated with another dma_alloc_coherent(). Compile tested for
all modified files except arch/sh/drivers/pci/fixups-dreamcast.c.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
I intended to quote Russell in my commit message and even asked him for
his permission, but since he didn't respond, I decided to include a link
to his original message only.
Documentation/DMA-API.txt | 18 +++
arch/arm/mach-mx3/mach-mx31moboard.c |2 -
arch/arm/mach-mx3/mach-pcm037.c|2 -
arch/sh/drivers/pci/fixups-dreamcast.c |6 +++
drivers/base/dma-coherent.c| 12 +--
drivers/base/dma-mapping.c |4 +-
drivers/media/video/sh_mobile_ceu_camera.c | 20 +++-
drivers/scsi/NCR_Q720.c| 15 +++--
drivers/usb/gadget/langwell_udc.c | 25
drivers/usb/gadget/langwell_udc.h |1
drivers/usb/host/ohci-sm501.c | 45 -
drivers/usb/host/ohci-tmio.c | 14 -
include/asm-generic/dma-coherent.h |2 -
include/linux/dma-mapping.h|6 +--
14 files changed, 122 insertions(+), 50 deletions(-)
--- linux-2.6.37-rc5/include/linux/dma-mapping.h.orig 2010-12-09
23:09:05.0 +0100
+++ linux-2.6.37-rc5/include/linux/dma-mapping.h2010-12-23
18:32:24.0 +0100
@@ -164,7 +164,7 @@ static inline int dma_get_cache_alignmen
#ifndef ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY
static inline int
-dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
+dma_declare_coherent_memory(struct device *dev, void *virt_addr,
dma_addr_t device_addr, size_t size, int flags)
{
return 0;
@@ -195,13 +195,13 @@ extern void *dmam_alloc_noncoherent(stru
extern void dmam_free_noncoherent(struct device *dev, size_t size, void *vaddr,
dma_addr_t dma_handle);
#ifdef ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY
-extern int dmam_declare_coherent_memory(struct device *dev, dma_addr_t
bus_addr,
+extern int dmam_declare_coherent_memory(struct device *dev, void *virt_addr,
dma_addr_t device_addr, size_t size,
int flags);
extern void dmam_release_declared_memory(struct device *dev);
#else /* ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY */
static inline int dmam_declare_coherent_memory(struct device *dev,
- dma_addr_t bus_addr, dma_addr_t device_addr,
+ void *virt_addr, dma_addr_t device_addr,
size_t size, gfp_t gfp)
{
return 0;
--- linux-2.6.37-rc5/include/asm-generic/dma-coherent.h.orig2010-12-09
23:09:04.0 +0100
+++ linux-2.6.37-rc5/include/asm-generic/dma-coherent.h 2010-12-23
18:32:24.0 +0100
@@ -15,7 +15,7 @@ int dma_release_from_coherent(struct dev
*/
#define ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY
extern int
-dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
+dma_declare_coherent_memory(struct device *dev, void *virt_addr,
dma_addr_t device_addr, size_t size, int flags);
extern void
--- linux-2.6.37-rc5/Documentation/DMA-API.txt.orig 2010-12-09
23:07:27.0 +0100
+++ linux-2.6.37-rc5/Documentation/DMA-API.txt 2010-12-23 18:32:24.0
+0100
@@ -477,20 +477,25 @@ continuing on for size. Again, you *mus
boundaries when doing this.
int
-dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
+dma_declare_coherent_memory(struct device *dev, void *virt_addr,
dma_addr_t device_addr, size_t size, int
flags)
Declare region of memory to be handed out by dma_alloc_coherent when
it's asked for coherent memory for this device.
-bus_addr is the physical address to which the memory is currently
-assigned in the bus responding region (this will be used by the
-platform to perform the mapping).
+virt_addr is the virtual address to which the pysical memory in the bus
+responding region is currently mapped (this will be handed out by
+dma_alloc_coherent() directly as its return value). Both a pointer to
+the ioremaped memory on the peripheral's bus
Re: [PATCH] dma_declare_coherent_memory: push ioremap() up to caller
Friday 24 December 2010 00:54:34 Russell King - ARM Linux napisał(a):
On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote:
The patch tries to implement a solution suggested by Russell King,
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December
/035264.html. It is expected to solve video buffer allocation issues
for at least a few soc_camera I/O memory less host interface
drivers, designed around the videobuf_dma_contig layer, which
allocates video buffers using dma_alloc_coherent().
Created against linux-2.6.37-rc5.
Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera
patch, patterned upon two mach-mx3 machine types which already try
to use the dma_declare_coherent_memory() method for reserving a
region of system RAM preallocated with another
dma_alloc_coherent(). Compile tested for all modified files except
arch/sh/drivers/pci/fixups-dreamcast.c.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
I intended to quote Russell in my commit message and even asked him
for his permission, but since he didn't respond, I decided to
include a link to his original message only.
There's no problem quoting messages which were sent to public mailing
lists, especially when there's a record of what was said in public
archives too.
I think this is definitely a step forward.
---
linux-2.6.37-rc5/arch/arm/mach-mx3/mach-pcm037.c.orig 2010-12-09
23:07:34.0 +0100 +++
linux-2.6.37-rc5/arch/arm/mach-mx3/mach-pcm037.c2010-12-23
18:32:24.0 +0100 @@ -431,7 +431,7 @@ static int __init
pcm037_camera_alloc_dm memset(buf, 0, buf_size);
dma = dma_declare_coherent_memory(mx3_camera.dev,
- dma_handle, dma_handle, buf_size,
+ buf, dma_handle, buf_size,
DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
/* The way we call dma_declare_coherent_memory only a malloc can
fail */ ---
linux-2.6.37-rc5/arch/arm/mach-mx3/mach-mx31moboard.c.orig 2010-12-
09 23:07:34.0 +0100 +++
linux-2.6.37-rc5/arch/arm/mach-mx3/mach-mx31moboard.c 2010-12-23
18:32:24.0 +0100 @@ -486,7 +486,7 @@ static int __init
mx31moboard_cam_alloc_ memset(buf, 0, buf_size);
dma = dma_declare_coherent_memory(mx3_camera.dev,
- dma_handle, dma_handle, buf_size,
+ buf, dma_handle, buf_size,
DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
/* The way we call dma_declare_coherent_memory only a malloc can
fail */
A side note for the mx3 folk: although it's not specified in DMA-API,
memory allocated from dma_alloc_coherent() on ARM is already memset
to zero by the allocation function.
--- linux-2.6.37-rc5/drivers/base/dma-coherent.c.orig 2010-12-09
23:08:03.0 +0100 +++
linux-2.6.37-rc5/drivers/base/dma-coherent.c2010-12-23
18:32:24.0 +0100 @@ -14,10 +14,9 @@ struct dma_coherent_mem
{
unsigned long *bitmap;
};
-int dma_declare_coherent_memory(struct device *dev, dma_addr_t
bus_addr, +int dma_declare_coherent_memory(struct device *dev, void
*virt_addr, dma_addr_t device_addr, size_t size, int flags)
{
- void __iomem *mem_base = NULL;
int pages = size PAGE_SHIFT;
int bitmap_size = BITS_TO_LONGS(pages) * sizeof(long);
@@ -30,10 +29,6 @@ int dma_declare_coherent_memory(struct d
/* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN
*/
- mem_base = ioremap(bus_addr, size);
- if (!mem_base)
- goto out;
-
dev-dma_mem = kzalloc(sizeof(struct dma_coherent_mem),
GFP_KERNEL); if (!dev-dma_mem)
goto out;
@@ -41,7 +36,7 @@ int dma_declare_coherent_memory(struct d
if (!dev-dma_mem-bitmap)
goto free1_out;
- dev-dma_mem-virt_base = mem_base;
+ dev-dma_mem-virt_base = virt_addr;
I didn't see anything changing the dev-dma_mem-virt_base type to
drop the __iomem attribute (which I suspect shouldn't be there -
we're returning it via a void pointer anyway, so I think the whole
coherent part of the DMA API should be __iomem-less.
There was no __iomem attribute specified for the .virt_base member of
the struct dma_coherent_mem, pure (void *), so nothing to be changed
there.
Thanks,
Janusz
It also pushes the sparse address space warnings to the right place
IMHO too.
--
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: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
Wednesday 15 December 2010 18:01:42 Russell King - ARM Linux wrote: On Wed, Dec 15, 2010 at 12:39:20PM +, Catalin Marinas wrote: 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 - Hi Russel, I've already started implementing what you've suggested, with an already working result, but have two questions: 1. Is it save to leave iounmap() being called on virtual addresses not obtained with ioremap()? This would make things less complicated. 2. Can I quote your full explanation, just like it looks below, in my commit message? Thanks, Janusz Wednesday 15 December 2010 18:01:42 Russell King - ARM Linux wrote: ... 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
Re: [PATCH 0/2] OMAP1: amsdelta: reserve memory for videobuf_contig
Friday 10 December 2010 02:29:09 Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [101205 10:19]: Latest developements seem to allow for reserving a block of memory on boot to be used as a device dedicated dma coherent memory. This may be required for videobuf_config based video drivers avoid problems with allocating dma coherent memory after system memory gets fragmented. This set extends the OMAP1 camera resource initialization code with a function that can be used for reserving a block of memory early, then declared as the camera device dedicated dma coherent memory. An example use case is provided for Amstrad Delta camera. These look good to me, however, can you please also Cc linux-arm-kernel list as otherwise I will need to repost these before merging. Sure. Perhaps that first submission should rather go as an RFC, now that there are no requests for changes, I'll repost with Cc linux-arm-kernel. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND] [PATCH 0/2] OMAP1: amsdelta: reserve memory for videobuf_contig
Since there were no request for changes, I'm resending the set, this time Cc linux-arm-kernel. Sunday 05 December 2010 19:29:05 Janusz Krzysztofik wrote: Latest developements seem to allow for reserving a block of memory on boot to be used as a device dedicated dma coherent memory. This may be required for videobuf_config based video drivers avoid problems with allocating dma coherent memory after system memory gets fragmented. This set extends the OMAP1 camera resource initialization code with a function that can be used for reserving a block of memory early, then declared as the camera device dedicated dma coherent memory. An example use case is provided for Amstrad Delta camera. arch/arm/mach-omap1/board-ams-delta.c | 12 +- arch/arm/mach-omap1/devices.c | 36 ++ arch/arm/mach-omap1/include/mach/camera.h |1 3 files changed, 48 insertions(+), 1 deletion(-) Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
OMAP1 camera driver, when starting up in its videobuf_contig mode, may have
problems with allocating dma coherent memory after system memory gets
fragmented if there is no dedicated memory declared as a dma coherent memory
block associated with the device. To solve this issue, allow for removing a
block of memory from system memory early on boot, then, if reserved this way,
declare it as the device dedicated dma coherent memory.
An example use case on Amstrad Delta will be provided with patch 2/2.
Created and tested against linux-2.6.37-rc4.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/devices.c | 36 ++
arch/arm/mach-omap1/include/mach/camera.h |1
2 files changed, 37 insertions(+)
--- linux-2.6.37-rc4/arch/arm/mach-omap1/devices.c.orig 2010-12-04
18:00:39.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/devices.c 2010-12-04
22:22:13.0 +0100
@@ -16,6 +16,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/spi/spi.h
+#include linux/memblock.h
#include mach/hardware.h
#include asm/mach/map.h
@@ -222,13 +223,48 @@ static struct platform_device omap1_came
.resource = omap1_camera_resources,
};
+static phys_addr_t omap1_camera_phys_mempool_base;
+static phys_addr_t omap1_camera_phys_mempool_size;
+
+void __init omap1_camera_reserve(phys_addr_t size)
+{
+ phys_addr_t paddr;
+
+ if (!size)
+ return;
+
+ paddr = memblock_alloc(size, SZ_1M);
+
+ if (!paddr) {
+ pr_err(%s: failed to reserve %x bytes\n, __func__, size);
+ return;
+ }
+ memblock_free(paddr, size);
+ memblock_remove(paddr, size);
+
+ omap1_camera_phys_mempool_base = paddr;
+ omap1_camera_phys_mempool_size = size;
+}
+
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))
+ pr_info(%s: reserved %d bytes camera buffer memory\n,
+ __func__, size);
+ else
+ pr_warn(%s: cannot reserve camera buffer memory\n,
+ __func__);
+ }
+
ret = platform_device_register(dev);
if (ret)
dev_err(dev-dev, unable to register device: %d\n, ret);
--- linux-2.6.37-rc4/arch/arm/mach-omap1/include/mach/camera.h.orig
2010-12-04 18:00:39.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/include/mach/camera.h 2010-12-04
22:26:23.0 +0100
@@ -3,6 +3,7 @@
#include media/omap1_camera.h
+void omap1_camera_reserve(phys_addr_t);
void omap1_camera_init(void *);
static inline void omap1_set_camera_info(struct omap1_cam_platform_data *info)
--
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 2/2] OMAP1: Amstrad Delta: reserve memory for camera
Patch 1/2 from this set provides a possibility to reserve a block of memory
for use as the OMAP1 camera dedicated dma coherent memory. Use this
functionality to avoid the camera driver switching form videobuf_contig mode
to less efficient videobuf_sg mode in case of dma coherent memory allocation
failure after system memory gets fragmented.
Created and tested against linux-2.6.27-rc4 on top of patch 1/2.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- linux-2.6.37-rc4/arch/arm/mach-omap1/board-ams-delta.c.orig 2010-12-04
18:05:25.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/board-ams-delta.c 2010-12-04
22:19:39.0 +0100
@@ -262,6 +262,16 @@ static struct omap1_cam_platform_data am
.lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
};
+void __init amsdelta_reserve(void)
+{
+#if defined(CONFIG_VIDEO_OMAP1) || defined(CONFIG_VIDEO_OMAP1_MODULE)
+ omap1_camera_reserve(PAGE_SIZE get_order(352 * 288 * 2 *
+ OMAP1_CAMERA_MIN_BUF_COUNT(OMAP1_CAM_DMA_CONTIG)));
+#endif
+
+ omap_reserve();
+}
+
static struct platform_device *ams_delta_devices[] __initdata = {
ams_delta_kp_device,
ams_delta_lcd_device,
@@ -366,7 +376,7 @@ MACHINE_START(AMS_DELTA, Amstrad E3 (De
/* Maintainer: Jonathan McDowell nood...@earth.li */
.boot_params= 0x1100,
.map_io = ams_delta_map_io,
- .reserve= omap_reserve,
+ .reserve= amsdelta_reserve,
.init_irq = ams_delta_init_irq,
.init_machine = ams_delta_init,
.timer = omap_timer,
--
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
Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
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.
For OMAP1, which is ARMv5 or lower, device memory becomes 'uncacheable,
unbufferable' which is luckily what is used for the DMA coherent
memory on those platforms - so no technical problem here.
However, on ARMv6 and later, ioremapped memory is device memory, which
has different ordering wrt normal memory mappings, and may appear on
different busses on the CPU's interface. So, this is something I don't
encourage as it's unclear that the hardware will work.
Essentially, dma_declare_coherent_memory() on ARM with main SDRAM should
be viewed as a 'it might work, it might not, and it might stop working
in the future' kind of interface. In other words, there is no guarantee
that this kind of thing will be supported in the future.
I was affraid of an unswer of this kind. I'm not capable of comming out with
any better, alternative solutions. Any hints other than giving up with that
old videobuf-contig, coherent memory based interface? Or can we agree on
that 'luckily uncacheable, unbufferable, SDRAM based DMA coherent memory'
solution for now?
Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP1: amsdelta: reserve memory for videobuf_contig
Latest developements seem to allow for reserving a block of memory on boot to be used as a device dedicated dma coherent memory. This may be required for videobuf_config based video drivers avoid problems with allocating dma coherent memory after system memory gets fragmented. This set extends the OMAP1 camera resource initialization code with a function that can be used for reserving a block of memory early, then declared as the camera device dedicated dma coherent memory. An example use case is provided for Amstrad Delta camera. arch/arm/mach-omap1/board-ams-delta.c | 12 +- arch/arm/mach-omap1/devices.c | 36 ++ arch/arm/mach-omap1/include/mach/camera.h |1 3 files changed, 48 insertions(+), 1 deletion(-) Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP1: allow reserving memory for camera
OMAP1 camera driver, when starting up in its videobuf_contig mode, may have
problems with allocating dma coherent memory after system memory gets
fragmented if there is no dedicated memory declared as a dma coherent memory
block associated with the device. To solve this issue, allow for removing a
block of memory from system memory early on boot, then, if reserved this way,
declare it as the device dedicated dma coherent memory.
An example use case on Amstrad Delta will be provided with patch 2/2.
Created and tested against linux-2.6.37-rc4.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/devices.c | 36 ++
arch/arm/mach-omap1/include/mach/camera.h |1
2 files changed, 37 insertions(+)
--- linux-2.6.37-rc4/arch/arm/mach-omap1/devices.c.orig 2010-12-04
18:00:39.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/devices.c 2010-12-04
22:22:13.0 +0100
@@ -16,6 +16,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/spi/spi.h
+#include linux/memblock.h
#include mach/hardware.h
#include asm/mach/map.h
@@ -222,13 +223,48 @@ static struct platform_device omap1_came
.resource = omap1_camera_resources,
};
+static phys_addr_t omap1_camera_phys_mempool_base;
+static phys_addr_t omap1_camera_phys_mempool_size;
+
+void __init omap1_camera_reserve(phys_addr_t size)
+{
+ phys_addr_t paddr;
+
+ if (!size)
+ return;
+
+ paddr = memblock_alloc(size, SZ_1M);
+
+ if (!paddr) {
+ pr_err(%s: failed to reserve %x bytes\n, __func__, size);
+ return;
+ }
+ memblock_free(paddr, size);
+ memblock_remove(paddr, size);
+
+ omap1_camera_phys_mempool_base = paddr;
+ omap1_camera_phys_mempool_size = size;
+}
+
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))
+ pr_info(%s: reserved %d bytes camera buffer memory\n,
+ __func__, size);
+ else
+ pr_warn(%s: cannot reserve camera buffer memory\n,
+ __func__);
+ }
+
ret = platform_device_register(dev);
if (ret)
dev_err(dev-dev, unable to register device: %d\n, ret);
--- linux-2.6.37-rc4/arch/arm/mach-omap1/include/mach/camera.h.orig
2010-12-04 18:00:39.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/include/mach/camera.h 2010-12-04
22:26:23.0 +0100
@@ -3,6 +3,7 @@
#include media/omap1_camera.h
+void omap1_camera_reserve(phys_addr_t);
void omap1_camera_init(void *);
static inline void omap1_set_camera_info(struct omap1_cam_platform_data *info)
--
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 2/2] OMAP1: Amstrad Delta: reserve memory for camera
Patch 1/2 from this set provides a possibility to reserve a block of memory
for use as the OMAP1 camera dedicated dma coherent memory. Use this
functionality to avoid the camera driver switching form videobuf_contig mode
to less efficient videobuf_sg mode in case of dma coherent memory allocation
failure after system memory gets fragmented.
Created and tested against linux-2.6.27-rc4 on top of patch 1/2.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- linux-2.6.37-rc4/arch/arm/mach-omap1/board-ams-delta.c.orig 2010-12-04
18:05:25.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/board-ams-delta.c 2010-12-04
22:19:39.0 +0100
@@ -262,6 +262,16 @@ static struct omap1_cam_platform_data am
.lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
};
+void __init amsdelta_reserve(void)
+{
+#if defined(CONFIG_VIDEO_OMAP1) || defined(CONFIG_VIDEO_OMAP1_MODULE)
+ omap1_camera_reserve(PAGE_SIZE get_order(352 * 288 * 2 *
+ OMAP1_CAMERA_MIN_BUF_COUNT(OMAP1_CAM_DMA_CONTIG)));
+#endif
+
+ omap_reserve();
+}
+
static struct platform_device *ams_delta_devices[] __initdata = {
ams_delta_kp_device,
ams_delta_lcd_device,
@@ -366,7 +376,7 @@ MACHINE_START(AMS_DELTA, Amstrad E3 (De
/* Maintainer: Jonathan McDowell nood...@earth.li */
.boot_params= 0x1100,
.map_io = ams_delta_map_io,
- .reserve= omap_reserve,
+ .reserve= amsdelta_reserve,
.init_irq = ams_delta_init_irq,
.init_machine = ams_delta_init,
.timer = omap_timer,
--
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] SoC Camera: ov6650: minor cleanups
Monday 08 November 2010 22:20:33 Guennadi Liakhovetski wrote: On Tue, 2 Nov 2010, Janusz Krzysztofik wrote: This is a followup patch that addresses two minor issues left in the recently added ov6650 sensor driver, as I've promised to the subsystem maintainer: - remove a pair of extra brackets, - drop useless case for not possible v4l2_mbus_pixelcode enum value of 0. Created against linux-2.6.37-rc1. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Applied together with other your 3 patches and pushed for 2.6.37-rc2. Hi Guennadi, Thanks for taking my fixes. Thursday 30 September 2010 13:35:49 Janusz Krzysztofik wrote: There are still two SG mode specific corner cases to be corrected, previously not detected because of poor sensor driver functionality: 1) frame size not exceeding one page, resulting in unexpected end of frame message and capture restart every frame, and 2) last sgbuf lenght less than bytes_per_line, resulting in unstable picture. I'm going to address those two with fixes. Since both issues don't affect typical usage (one of standard resolutions) and both are videobuf-sg related, I'm wondering if I should better wait for videobuf2 and try to port my driver instead of making things still more complicated than they already are. What do you think? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.37-rc1] SoC Camera: OMAP1: update for recent framework changes
The recently added OMAP1 camera driver was not ready for one video queue per
device framework changes. Fix it.
Created and tested against linux-2.6.37-rc1.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/media/video/omap1_camera.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.37-rc1/drivers/media/video/omap1_camera.c.orig2010-11-01
22:41:59.0 +0100
+++ linux-2.6.37-rc1/drivers/media/video/omap1_camera.c 2010-11-01
23:55:26.0 +0100
@@ -1386,7 +1386,7 @@ static void omap1_cam_init_videobuf(stru
}
}
-static int omap1_cam_reqbufs(struct soc_camera_file *icf,
+static int omap1_cam_reqbufs(struct soc_camera_device *icd,
struct v4l2_requestbuffers *p)
{
int i;
@@ -1398,7 +1398,7 @@ static int omap1_cam_reqbufs(struct soc_
* it hadn't triggered
*/
for (i = 0; i p-count; i++) {
- struct omap1_cam_buf *buf = container_of(icf-vb_vidq.bufs[i],
+ struct omap1_cam_buf *buf = container_of(icd-vb_vidq.bufs[i],
struct omap1_cam_buf, vb);
buf-inwork = 0;
INIT_LIST_HEAD(buf-vb.queue);
@@ -1485,10 +1485,10 @@ static int omap1_cam_set_bus_param(struc
static unsigned int omap1_cam_poll(struct file *file, poll_table *pt)
{
- struct soc_camera_file *icf = file-private_data;
+ struct soc_camera_device *icd = file-private_data;
struct omap1_cam_buf *buf;
- buf = list_entry(icf-vb_vidq.stream.next, struct omap1_cam_buf,
+ buf = list_entry(icd-vb_vidq.stream.next, struct omap1_cam_buf,
vb.stream);
poll_wait(file, buf-vb.done, pt);
--
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 2.6.37-rc1] SoC Camera: OMAP1: update for recent videobuf changes
Recent locking related videobuf changes has not been incorporated into the new
OMAP1 camera driver. Fix it.
Created and tested against linux-2.6.37-rc1.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/media/video/omap1_camera.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.37-rc1/drivers/media/video/omap1_camera.c.orig2010-11-01
22:41:59.0 +0100
+++ linux-2.6.37-rc1/drivers/media/video/omap1_camera.c 2010-11-01
23:55:26.0 +0100
@@ -235,7 +235,7 @@ static void free_buffer(struct videobuf_
BUG_ON(in_interrupt());
- videobuf_waiton(vb, 0, 0);
+ videobuf_waiton(vq, vb, 0, 0);
if (vb_mode == OMAP1_CAM_DMA_CONTIG) {
videobuf_dma_contig_free(vq, vb);
@@ -1365,12 +1365,12 @@ static void omap1_cam_init_videobuf(stru
videobuf_queue_dma_contig_init(q, omap1_videobuf_ops,
icd-dev.parent, pcdev-lock,
V4L2_BUF_TYPE_VIDEO_CAPTURE, V4L2_FIELD_NONE,
- sizeof(struct omap1_cam_buf), icd);
+ sizeof(struct omap1_cam_buf), icd, NULL);
else
videobuf_queue_sg_init(q, omap1_videobuf_ops,
icd-dev.parent, pcdev-lock,
V4L2_BUF_TYPE_VIDEO_CAPTURE, V4L2_FIELD_NONE,
- sizeof(struct omap1_cam_buf), icd);
+ sizeof(struct omap1_cam_buf), icd, NULL);
/* use videobuf mode (auto)selected with the module parameter */
pcdev-vb_mode = sg_mode ? OMAP1_CAM_DMA_SG : OMAP1_CAM_DMA_CONTIG;
--
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] SOC Camera: OMAP1: typo fix
Fix an outstanding typo in the recently added driver, as requested by the subsystem maintainer. Created against linux-2.6.37-rc1. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- drivers/media/video/omap1_camera.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.37-rc1/drivers/media/video/omap1_camera.c.orig2010-11-01 23:55:26.0 +0100 +++ linux-2.6.37-rc1/drivers/media/video/omap1_camera.c 2010-11-02 01:48:55.0 +0100 @@ -504,7 +504,7 @@ static void omap1_videobuf_queue(struct * empty. Since the transfer of the DMA programming register set * content to the DMA working register set is done automatically * by the DMA hardware, this can pretty well happen while we -* are keeping the lock here. Levae fetching it from the queue +* are keeping the lock here. Leave fetching it from the queue * to be done when a next DMA interrupt occures instead. */ return; -- 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] SoC Camera: ov6650: minor cleanups
This is a followup patch that addresses two minor issues left in the recently
added ov6650 sensor driver, as I've promised to the subsystem maintainer:
- remove a pair of extra brackets,
- drop useless case for not possible v4l2_mbus_pixelcode enum value of 0.
Created against linux-2.6.37-rc1.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/media/video/ov6650.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- linux-2.6.37-rc1/drivers/media/video/ov6650.c.orig 2010-11-01
22:41:59.0 +0100
+++ linux-2.6.37-rc1/drivers/media/video/ov6650.c 2010-11-02
16:56:49.0 +0100
@@ -754,7 +754,7 @@ static int ov6650_g_fmt(struct v4l2_subd
static bool is_unscaled_ok(int width, int height, struct v4l2_rect *rect)
{
- return (width rect-width 1 || height rect-height 1);
+ return width rect-width 1 || height rect-height 1;
}
static u8 to_clkrc(struct v4l2_fract *timeperframe,
@@ -840,8 +840,6 @@ static int ov6650_s_fmt(struct v4l2_subd
coma_mask |= COMA_BW | COMA_BYTE_SWAP | COMA_WORD_SWAP;
coma_set |= COMA_RAW_RGB | COMA_RGB;
break;
- case 0:
- break;
default:
dev_err(client-dev, Pixel format not handled: 0x%x\n, code);
return -EINVAL;
--
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 v3] SoC Camera: add driver for OMAP1 camera interface
Sunday 03 October 2010 04:42:53 Guennadi Liakhovetski napisał(a): On Sat, 2 Oct 2010, Janusz Krzysztofik wrote: Saturday 02 October 2010 08:07:28 Guennadi Liakhovetski napisał(a): Same with this one - let's take it as is and address a couple of clean-ups later. Guennadi, Thanks for taking them both. BTW, what are your intentions about the last patch from my series still left not commented, SoC Camera: add support for g_parm / s_parm operations, http://www.spinics.net/lists/linux-media/msg22887.html ? Yes, taking that one too, thanks. I see it right, that I have to apply 3 of your patches: omap1 camera driver, ov6650 and default .[gs]_fmt for soc_camera, the rest will go via the OMAP / ARM tree, right? Right. Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] SoC Camera: add driver for OV6650 sensor
Saturday 02 October 2010 07:47:47 Guennadi Liakhovetski napisał(a):
Ok, let's take this one, but, please, address the below couple of minor
issues in an incremental patch.
On Mon, 27 Sep 2010, Janusz Krzysztofik wrote:
+/* write a register */
+static int ov6650_reg_write(struct i2c_client *client, u8 reg, u8 val)
+{
+ int ret;
+ unsigned char data[2] = { reg, val };
+ struct i2c_msg msg = {
+ .addr = client-addr,
+ .flags = 0,
+ .len= 2,
+ .buf= data,
+ };
+
+ ret = i2c_transfer(client-adapter, msg, 1);
+ usleep_range(100, 1000);
So, 100us are enough? Then I'd just go with udelay(100).
Guennadi,
I already tried with udelay(100), as you had suggested before, and it worked,
but then checkpatch.pl --sctirct told me:
CHECK: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.txt
+ udelay(100);
So, I had read Documentation/timers/timers-howto.txt again and switched to
usleep_range, as it suggested.
Please confirm if you still prefere udelay(100) over usleep_range(), and I'll
change it back.
static bool is_unscaled_ok(int width, int height, struct v4l2_rect *rect)
+{
+ return (width rect-width 1 || height rect-height 1);
+}
Ok, just one more pair of brackets to remove;)
OK.
+
+static u8 to_clkrc(struct v4l2_fract *timeperframe,
+ unsigned long pclk_limit, unsigned long pclk_max)
+{
+ unsigned long pclk;
+
+ if (timeperframe-numerator timeperframe-denominator)
+ pclk = pclk_max * timeperframe-denominator /
+ (FRAME_RATE_MAX * timeperframe-numerator);
+ else
+ pclk = pclk_max;
+
+ if (pclk_limit pclk_limit pclk)
+ pclk = pclk_limit;
+
+ return (pclk_max - 1) / pclk;
+}
+
+/* set the format we will capture in */
+static int ov6650_s_fmt(struct v4l2_subdev *sd, struct
v4l2_mbus_framefmt *mf) +{
+ struct i2c_client *client = sd-priv;
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_sense *sense = icd-sense;
+ struct ov6650 *priv = to_ov6650(client);
+ bool half_scale = !is_unscaled_ok(mf-width, mf-height, priv-rect);
+ struct v4l2_crop a = {
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .c = {
+ .left = priv-rect.left + (priv-rect.width 1) -
+ (mf-width (1 - half_scale)),
+ .top= priv-rect.top + (priv-rect.height 1) -
+ (mf-height (1 - half_scale)),
+ .width = mf-width half_scale,
+ .height = mf-height half_scale,
+ },
+ };
Hm, this seems wrong to me... You calculate left and top to preserve the
center, right?
Exactly.
This is good, but: if output is unscaled, you want
.left = priv-rect.left + (priv-rect.width - mf-width) / 2;
== priv-rect.left + priv-rect.width / 2 - mf-width/ 2
== priv-rect.left + (priv-rect.width 1) - ( mf-width 1)
== priv-rect.left + (priv-rect.width 1) - ( mf-width(1
- 0))
in this case half_scale = 0 and the above is correct. Now, is the output
is scaled, you want
.left = priv-rect.left + (priv-rect.width - mf-width * 2) / 2;
== priv-rect.left + priv-rect.width / 2 - mf-width * 2 / 2
== priv-rect.left + (priv-rect.width 1) - ((mf-width 1) 1)
== priv-rect.left + (priv-rect.width 1) - ( mf-width(1
- 1))
which is not, what you have above. Am I missing anything?
One of us must be ;).
+ case V4L2_MBUS_FMT_UYVY8_2X8:
+ dev_dbg(client-dev, pixel format YUYV8_2X8_BE\n);
+ if (half_scale) {
+ coma_mask |= COMA_RGB | COMA_BW | COMA_WORD_SWAP;
+ coma_set |= COMA_BYTE_SWAP;
+ } else {
+ coma_mask |= COMA_RGB | COMA_BW;
+ coma_set |= COMA_BYTE_SWAP | COMA_WORD_SWAP;
+ }
+ break;
+ case V4L2_MBUS_FMT_VYUY8_2X8:
+ dev_dbg(client-dev, pixel format YVYU8_2X8_BE (untested)\n);
+ if (half_scale) {
+ coma_mask |= COMA_RGB | COMA_BW;
+ coma_set |= COMA_BYTE_SWAP | COMA_WORD_SWAP;
+ } else {
+ coma_mask |= COMA_RGB | COMA_BW | COMA_WORD_SWAP;
+ coma_set |= COMA_BYTE_SWAP;
+ }
+ break;
...since there anyway will be an incremental patch . what does
word-swapping have to do with scaling?...
A hardware (firmware) bug perhaps? All I can say is that I had found out it
worked like this for me before, and I've just ensured it still does.
+ case V4L2_MBUS_FMT_SBGGR8_1X8:
+ dev_dbg(client-dev, pixel format SBGGR8_1X8 (untested)\n);
+ coma_mask |= COMA_BW
Re: [PATCH v3] SoC Camera: add driver for OMAP1 camera interface
Saturday 02 October 2010 08:07:28 Guennadi Liakhovetski napisał(a):
Same with this one - let's take it as is and address a couple of clean-ups
later.
Guennadi,
Thanks for taking them both.
BTW, what are your intentions about the last patch from my series still left
not commented, SoC Camera: add support for g_parm / s_parm operations,
http://www.spinics.net/lists/linux-media/msg22887.html ?
On Thu, 30 Sep 2010, Janusz Krzysztofik wrote:
+static void omap1_videobuf_queue(struct videobuf_queue *vq,
+ struct videobuf_buffer *vb)
+{
+ struct soc_camera_device *icd = vq-priv_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+ struct omap1_cam_dev *pcdev = ici-priv;
+ struct omap1_cam_buf *buf;
+ u32 mode;
+
+ list_add_tail(vb-queue, pcdev-capture);
+ vb-state = VIDEOBUF_QUEUED;
+
+ if (pcdev-active) {
+ /*
+* Capture in progress, so don't touch pcdev-ready even if
+* empty. Since the transfer of the DMA programming register set
+* content to the DMA working register set is done automatically
+* by the DMA hardware, this can pretty well happen while we
+* are keeping the lock here. Levae fetching it from the queue
Leave
Yes, sorry.
+* to be done when a next DMA interrupt occures instead.
+*/
+ return;
+ }
superfluous braces
I was instructed once to do a reverse in a patch against ASoC subtree (see
http://www.mail-archive.com/linux-o...@vger.kernel.org/msg14863.html), but
TBH, I can't find a clear enough requirement specified in the
Documentation/CodingStyle, so I probably change my habits, at least for you
subtree ;).
+static void videobuf_done(struct omap1_cam_dev *pcdev,
+ enum videobuf_state result)
+{
+ struct omap1_cam_buf *buf = pcdev-active;
+ struct videobuf_buffer *vb;
+ struct device *dev = pcdev-icd-dev.parent;
+
+ if (WARN_ON(!buf)) {
+ suspend_capture(pcdev);
+ disable_capture(pcdev);
+ return;
+ }
+
+ if (result == VIDEOBUF_ERROR)
+ suspend_capture(pcdev);
+
+ vb = buf-vb;
+ if (waitqueue_active(vb-done)) {
+ if (!pcdev-ready result != VIDEOBUF_ERROR) {
+ /*
+* No next buffer has been entered into the DMA
+* programming register set on time (could be done only
+* while the previous DMA interurpt was processed, not
+* later), so the last DMA block, be it a whole buffer
+* if in CONTIG or its last sgbuf if in SG mode, is
+* about to be reused by the just autoreinitialized DMA
+* engine, and overwritten with next frame data. Best we
+* can do is stopping the capture as soon as possible,
+* hopefully before the next frame start.
+*/
+ suspend_capture(pcdev);
+ }
superfluous braces
ditto.
I'll address the issues when ready with my forementioned corner case fixes.
Thanks,
Janusz
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 v3] SoC Camera: add driver for OMAP1 camera interface
This is a V4L2 driver for TI OMAP1 SoC camera interface. Both videobuf-dma versions are supported, contig and sg, selectable with a module option. The former uses less processing power, but often fails to allocate contignuous buffer memory. The latter is free of this problem, but generates tens of DMA interrupts per frame. If contig memory allocation ever fails, the driver falls back to sg automatically on next open, but still can be switched back to contig manually. Both paths work stable for me, even under heavy load, on my OMAP1510 based Amstrad Delta videophone, that is the oldest, least powerfull OMAP1 implementation. The interface generally works in pass-through mode. Since input data byte endianess can be swapped, it provides up to two v4l2 pixel formats per each of several soc_mbus formats that have their swapped endian counterparts. Boards using this driver can provide it with the following platform data: - if and what freqency clock is expected by an on-board camera sensor, - what is the maximum pixel clock that should be accepted from the sensor, - what is the polarity of the sensor provided pixel clock, - if the interface GPIO line is connected to a sensor reset/powerdown input and what is the input polarity. Created and tested against linux-2.6.36-rc5 on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- Guennadi, Since 2.6.36-rc6 is out, I've decided to submit the driver, no longer trying to make it still better or waiting for more comments, in hope it's still not too late for it to be merged during the upcomming window. The redefined set_fmt and set_crop operations work for me as expected with the last version (v3) of my ov6650 sensor driver. There are still two SG mode specific corner cases to be corrected, previously not detected because of poor sensor driver functionality: 1) frame size not exceeding one page, resulting in unexpected end of frame message and capture restart every frame, and 2) last sgbuf lenght less than bytes_per_line, resulting in unstable picture. I'm going to address those two with fixes. Thanks, Janusz v2-v3 changes: requested, suggested or inspired by Guennadi Liakhovetski (thanks again!): - compare enum variable against one of enum values instead of relaying on the fact that a possible value can be either 0 or not 0, - put an argument inside parenthesis in a macro definition, - CONTIG and SG are not good enough names to be defined in a header under include/..., - still better explain why suspend capture if pcdev-ready is NULL on buffer completion, - ephasize the fact and explain why not fetch new buffer from the queue immediately, rather do it only when a next DMA interrupt occures, - use more correct English wording in a few cases, - explain why not yet call videobuf_done() right after the end of current sglist is detected, but only on next DMA interrupt, - don't split strings, even on print format specifier boudries, - v2 updated subdev_call_with_sense() macro return value was no longer stored in a variable which was still examined next, - don't store 1 in a bool variable, use true instead, - allocate register cache dynamically based on platform resource size instead of sizing it staticaly with a predefined OMAP1_CAMERA_IOSIZE macro; move this macro out of the media/omap1_camera.h, suggested by Ralph Corderoy (thanks again!): - a few hex print formats still not optimal, other: - correct a few typos still found, - if a block consisting of a single command contains a comment as well, it should be enclosed in braces, - make the driver less noisy by lowering down levels of a fwe more messages, - is_dma_aligned() and dma_align() results can depend on vb_mode istead of always assuming CONTIG mode as a worth case, - redefine set_crop and set_fmt algorithms to better follow the v4l2 model, drop a few no longer used helper functions, create a new one, set_mbus_format(), from the new code common to both operations. v1-v2 changes: requested by Guennadi Liakhovetski (thanks!): - first try contig, and if it fails - fall back to sg; invalidates next two, - invalidated: Kconfig: VIDEO_OMAP1_SG: not need if, the depends on should suffice, - invalidated: include both media/videobuf-dma-contig.h and media/videobuf-dma-sg.h headers, - extensively document buffer manipulations, better yet clean it up, - a copyright / licence header was missing form a header file, - need to #include linux/bitops.h if using BIT() macro, - don't need macros representing frequencies - use numbers directly, - add a few missing static qualifiers, - use u32 type for register content handling, - some cached registers were unnecessarily read from the hardware directly, - use true/false constants instead of 0/1 for booleans, - avoid assigning variables inside other constructs, - don't need to test if RAZ_FIFO is cleared, - no need to split \n to a new line, don't worry about 80 characters, - don't increment
[PATCH v3] OMAP1: Add support for SoC camera interface
This patch adds a definition of the OMAP1 camera interface platform device,
and a function that allows for providing a board specific platform data.
The device will be used with the upcoming OMAP1 SoC camera interface driver.
Created and tested against linux-2.6.36-rc5 on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Tony,
I hope this now satisfies your requirements.
I resubmit only this updated patch, not the other two, Amstrad Delta specific,
which you have alredy applied. Those are still valid (work for me), only the
not yet merged include/media/omap1_camera.h header file is required for
successfull compilation of board-ams-delta.c. I hope this is not a problem.
I'll submit the driver for Guennadi to push it via the media tree soon.
v2-v3 changes:
requested or inspired by Tony Lindgren (thanks!):
- don't #include mach/camera.h into devices.c in order to allow for
successfull compilation while the camera.h still includes a not yet merged
media/omap1_camera.h,
- move the OMAP1_CAMERA_IOSIZE macro defintion from camera.h to devices.c,
- to remove any remaining mach/camera.h or media/omap1_camera.h
dependencies from devices.c, replace the struct omap1_cam_platform_data *
argument type with a void *, and provide an inline wrapper function in
camera.h that converts back from void * to struct omap1_cam_platform_data *,
suggested by Guennadi Liakhovetski (thanks!):
- try groupping headers according to their location and keeping them sorted
alphabeticaly,
- drop extern qualifier from fuction declaration,
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/devices.c | 43 ++
arch/arm/mach-omap1/include/mach/camera.h | 13 +
2 files changed, 56 insertions(+)
diff -upr linux-2.6.36-rc5.orig/arch/arm/mach-omap1/devices.c
linux-2.6.36-rc5/arch/arm/mach-omap1/devices.c
--- linux-2.6.36-rc5.orig/arch/arm/mach-omap1/devices.c 2010-09-24
15:34:27.0 +0200
+++ linux-2.6.36-rc5/arch/arm/mach-omap1/devices.c 2010-09-25
03:47:55.0 +0200
@@ -9,6 +9,7 @@
* (at your option) any later version.
*/
+#include linux/dma-mapping.h
#include linux/module.h
#include linux/kernel.h
#include linux/init.h
@@ -191,6 +192,48 @@ static inline void omap_init_spi100k(voi
}
#endif
+
+#define OMAP1_CAMERA_BASE 0xfffb6800
+#define OMAP1_CAMERA_IOSIZE0x1c
+
+static struct resource omap1_camera_resources[] = {
+ [0] = {
+ .start = OMAP1_CAMERA_BASE,
+ .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = INT_CAMERA,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device omap1_camera_device = {
+ .name = omap1-camera,
+ .id = 0, /* This is used to put cameras on this interface */
+ .dev= {
+ .dma_mask = omap1_camera_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .num_resources = ARRAY_SIZE(omap1_camera_resources),
+ .resource = omap1_camera_resources,
+};
+
+void __init omap1_camera_init(void *info)
+{
+ struct platform_device *dev = omap1_camera_device;
+ int ret;
+
+ dev-dev.platform_data = info;
+
+ ret = platform_device_register(dev);
+ if (ret)
+ dev_err(dev-dev, unable to register device: %d\n, ret);
+}
+
+
/*-*/
static inline void omap_init_sti(void) {}
diff -upr linux-2.6.36-rc5.orig/arch/arm/mach-omap1/include/mach/camera.h
linux-2.6.36-rc5/arch/arm/mach-omap1/include/mach/camera.h
--- linux-2.6.36-rc5.orig/arch/arm/mach-omap1/include/mach/camera.h
2010-09-24 15:39:07.0 +0200
+++ linux-2.6.36-rc5/arch/arm/mach-omap1/include/mach/camera.h 2010-09-25
03:19:12.0 +0200
@@ -0,0 +1,13 @@
+#ifndef __ASM_ARCH_CAMERA_H_
+#define __ASM_ARCH_CAMERA_H_
+
+#include media/omap1_camera.h
+
+void omap1_camera_init(void *);
+
+static inline void omap1_set_camera_info(struct omap1_cam_platform_data *info)
+{
+ omap1_camera_init(info);
+}
+
+#endif /* __ASM_ARCH_CAMERA_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 v3 3/6] SoC Camera: add driver for OV6650 sensor
This patch provides a V4L2 SoC Camera driver for OV6650 camera sensor, found on OMAP1 SoC based Amstrad Delta videophone. Since I have no experience with camera sensors, and the sensor documentation I was able to find was not very comprehensive, I left most settings at their default (reset) values, except for: - those required for proper mediabus parameters and picture geometry and format setup, - those used by controls. Resulting picture quality may be far from perfect, but better than nothing. In order to be able to get / set the sensor frame rate from userspace, I decided to provide two not yet SoC camera supported operations, g_parm and s_parm. These can be used after applying patch 4/6 from this series, SoC Camera: add support for g_parm / s_parm operations. Created and tested against linux-2.6.36-rc5 on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- Guennadi, I decided to submit the updated version of the sensor driver first to ensure it is OK before I submit the host interface driver, which I've been able to simplify a lot now when I think I better understand how v4l2 sensors work. Moreover, the OMAP bits are already applied in part by Tony, so there is no need to resubmit the whole set. Thanks, Janusz v2 - v3 changes: requested, suggested or inspired by Guennadi Liakhovetski (thanks again!): - no reason to use msleep_interruptible(1), use a udelay(1000) or even try whether a udelay(100) suffices too (it does); ended up with usleep_range() to better satisfy checkpatch, - drop superfluous parenthesis, - coml_mask and coml_set are only set here and only used once below, so, dropping initialisation to 0 in variable definitions and use a more readable code pattern, - cropcap shouldn't depend on any dynamic (configured by S_FMT) setting, put the full sensor resolution in cropcap, - in struct ov6650 definition, select a better name for the .qcif member, like .half_scale, add comments to both .rect and .half_scale memeber declrations, - use false/true, not 0/1, in boolean asignments, - drop ov6650_reset() and ov6650_prog_dflt() calls from the s_fmt completely, move them over into the ov6650_video_probe(), - in s_crop, also ensure that rect-left and rect-top are within limits, - in s_mbus_fmt, select an input rectangle _closest_ to the currently configured one that would allow to possibly exactly configure the requested output format, then set -rect and -half_scale with new values, - in g_fmt, return -rect scaled with -half_scale other: - in unscaled mode, align all rect members by 2, - don't fail if requested rectangle is out of limits, adjust it instead, - add support for geometry only change to s_fmt, - don't overwrite s_parm requested timeperframe value with the one calculated from platform requested pixel clock limit, use it as another limit, - convert reusable code used for clock divisor calculation into a helper funtion, use it also in g_parm instead of reading the CLKRC register, - no need to copy rect members one by one, use a single assignment of the whole structure, - still a few cosmetic changes. v1 - v2 changes: requested by Guennadi Liakhovetski (thanks!): - include linux/bitops.h if using BIT() macro, - sort headers alphabetically, - don't mix tabs with spaces (preferred) when separating symbols from #define keywords, - drop unused NUM_REGS definition, - optimize SET_SAT() and SAT_MASK macros, - reuse no longer needed function argument instead of declaring a new local variable, - don't touch auto controls when changing their correspondig manual settings, and vice versa, - drop probably unsupported auto-hue control, - initialize sensor by writing registers explicitly instead of using a magic initialization array, - avoid gotos, don't use them other than in failure cases, - make pclk computation more readable, - implement g_mbus_fmt() callback, - correct a few obvious mistakes, - remove a few extra whitespaces, suggested by Ralph Corderoy (thanks!): - use one common format when hex printing register addresses and values, - optimize if(ret) vs. if(!ret) constructs usage, - replace a few if-else constructs with more compact, conditional expression based, when translating controls to register bits, - optimize ov6650_res_roundup(), - drop redundant cast of index from ov6650_enum_fmt(), - use variable identifiers rather than their types as sizeof() arguments, other: - disable band filter, auto exposure control seems working more effectively without it, - refresh against linux-2.6.36-rc3. drivers/media/video/Kconfig |6 drivers/media/video/Makefile|1 drivers/media/video/ov6650.c| 1224 include/media/v4l2-chip-ident.h |1 4 files changed, 1232 insertions(+) diff -upr linux-2.6.36-rc5.orig/drivers/media/video/Kconfig linux-2.6.36-rc5/drivers/media/video/Kconfig --- linux-2.6.36-rc5.orig/drivers/media/video/Kconfig 2010
Re: [RESEND][PATCH v2 2/6] OMAP1: Add support for SoC camera interface
Friday 24 September 2010 08:54:20 Guennadi Liakhovetski napisał(a): On Thu, 23 Sep 2010, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [100923 16:37]: Friday 24 September 2010 01:23:10 Tony Lindgren napisał(a): I think you can just move the OMAP1_CAMERA_IOSIZE to the devices.c or someplace like that? Tony, Not exactly. I use the OMAP1_CAMERA_IOSIZE inside the driver when reserving space for register cache. I think that I could just duplicate its definition in the devices.c for now, than clean things up with a folloup patch when both parts already get merged. Would this be acceptable? Yeah, that sounds good to me. ...better yet put a zero-length cache array at the end of your struct omap1_cam_dev and allocate it dynamically, calculated from the resource size. Guennadi, Yes, this seems the best solution, thank you. Tony, You'll soon get it as you ask: media/camera.h no longer included from mach/camera.h. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/6] OMAP1: Amstrad Delta: add support for camera
Friday 24 September 2010 08:57:06 Guennadi Liakhovetski napisał(a): On Thu, 23 Sep 2010, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [100923 16:52]: Friday 24 September 2010 01:26:17 Tony Lindgren napisał(a): * Tony Lindgren t...@atomide.com [100923 16:06]: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [100910 18:20]: This patch adds configuration data and initialization code required for camera support to the Amstrad Delta board. Three devices are declared: SoC camera, OMAP1 camera interface and OV6650 sensor. Default 12MHz clock has been selected for driving the sensor. Pixel clock has been limited to get reasonable frame rates, not exceeding the board capabilities. Since both devices (interface and sensor) support both pixel clock polarities, decision on polarity selection has been left to drivers. Interface GPIO line has been found not functional, thus not configured. Created and tested against linux-2.6.36-rc3. Works on top of previous patches from the series, at least 1/6, 2/6 and 3/6. Queuing these last two patches of the series (5/6 and 6/6) for the upcoming merge window. BTW, these still depend on updated 2/6 to make compile happy. Not so simple: still depends on struct omap1_cam_platform_data definition from media/omap1_camera.h, included from mach/camera.h. Are you ready to accept another temporary workaround? Heh I guess so. Or do you want to queue everything via linux-media? AFAIK we can expect my arch/arm/mach-omap1/devices.c changes already resulting in a confilct with some ASoC OMAP related changes going via the sound tree, so the 2/6 should be better queued via the OMAP tree for Tony to keep control over it, with the rest of the seriers going either way. Yes, we often have to select via which tree to go, then the maintainer of the other tree just acks the patches. Sometimes we push them via different trees and try to enforce a specific merge order... What about + void omap1_set_camera_info(struct omap1_cam_platform_data *); put temporarily into to the arch/arm/mach-omap1/board-ams-delta.c instead of including mach/camera.h, that could be replaced with media/omap1_camera.h then? May sound better than redefining struct omap1_cam_platform_data there, and should be safe to push everything except 2/6 via the media tree. Then, replace the above hack back with #include mach/camera.h as a fix after both are merged. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/6] SoC Camera: add driver for OV6650 sensor
Friday 24 September 2010 08:52:32 Guennadi Liakhovetski napisał(a):
On Fri, 24 Sep 2010, Janusz Krzysztofik wrote:
Thursday 23 September 2010 18:06:15 Guennadi Liakhovetski napisał(a):
On Wed, 22 Sep 2010, Janusz Krzysztofik wrote:
Wednesday 22 September 2010 11:12:46 Guennadi Liakhovetski napisaÅ
(a):
On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
...
whereas COMA and COML select
whether to scale it to a CIF or to a QCIF output.
I think the answer is: not exactly. AFAICT, the COMA_QCIF bit selects
whether to scale it down by 2 (QCIF selection) or not (CIF selection).
Ah! Ok, that it would be better to select different names for those bits.
I was trying to keep all names more or less consistent with the wording used
in the sensor documentation (which doesn't follow the v4l2 specification
unfortunately :). In this case we have:
COMA Common Control A
...
Bit[5]: Output format – resolution
0: CIF (352 x 288)
1: QCIF (176 x 144)
So I could rename it to something like COMA_OUTFMT or COMA_RESOLUTION. Which
one sounds better for you?
...
But I think your driver might have a problem with its cropping /
scaling handling. Let's see if I understand it right:
1. as cropcap you currently return QCIF or CIF, depending on the last
S_FMT,
Yes.
BTW, my S_FMT always calls ov6650_reset(), which resets the current crop
to defaults.
Oh, does it mean all registers are reset to their defaults? That'd be not
good - no v4l(2) ioctl, AFAIK, should affect parameters, not directly
related to it. Even closing and reopening the video device node shouldn't
reset values. So, maybe you should drop that reset completely.
Shouldn't I rather move it over into the ov6650_video_probe()?
...
2. in your s_fmt you accept only two output sizes: CIF or QCIF, that's
ok, if that's all you can configure with your driver.
Not any longer :). I'm able to configure using current crop geometry
only, either unscaled or scaled down by 2. I'm not able to configure
neither exact CIF nor QCIF if my current crop window doesn't match,
unless I'm allowed to change the crop from here.
Hm, but in your s_fmt you do:
+ switch (mf-width) {
+ case W_QCIF:
+ dev_dbg(client-dev, resolution QCIF\n);
+ priv-qcif = 1;
+ coma_set |= COMA_QCIF;
+ priv-pclk_max /= 2;
+ break;
+ case W_CIF:
+ dev_dbg(client-dev, resolution CIF\n);
+ priv-qcif = 0;
+ coma_mask |= COMA_QCIF;
+ break;
+ default:
+ dev_err(client-dev, unspported resolution!\n);
+ return -EINVAL;
+ }
So, you accept only CIF or QCIF as your output window. Or do you mean a v3
by your not any longer?
Exactly!
And yes, you are allowed to change your input
sensor window, if that lets you configure your output format more
precisely. And v.v. The rule is - the most recent command wins.
I see.
...
No, there's nothing wrong with your sensor:) So, what I would do is:
1. in your struct ov6650:
+ struct v4l2_rectrect; /* sensor cropping window */
+ boolhalf_scale; /* scale down output by 2 */
2. in s_crop verify left, width, top, height, program them into the chip
and store in -rect
3. in g_crop just return values from -rect
4. in s_fmt you have to select an input rectangle, that would allow you to
possibly exactly configure the requested output format. Say, if you have a
320x240 cropping configured and you get an s_fmt request for 120x90. You
can either set your input rectangle to 240x180 and scale it down by 2, or
set the rectangle directly to 120x90. Obviously, it's better to use
240x180 and scale down, because that's closer to the current cropping of
320x240. So, in s_fmt you select a new input rectangle _closest_ to the
currently configured one, that would allow you to configure the correct
output format. Then you set your -rect with the new values and your
-half_scale
5. in g_fmt you return -rect scaled with -half_scale
Makes sense?
Absolutely. Hope to submit v3 soon.
Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] SoC Camera: add driver for OMAP1 camera interface
Thursday 23 September 2010 15:33:54 Guennadi Liakhovetski napisał(a):
On Wed, 22 Sep 2010, Janusz Krzysztofik wrote:
Wednesday 22 September 2010 01:23:22 Guennadi Liakhovetski napisał(a):
On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
+
+ vb = buf-vb;
+ if (waitqueue_active(vb-done)) {
+ if (!pcdev-ready result != VIDEOBUF_ERROR)
+ /*
+* No next buffer has been entered into the DMA
+* programming register set on time, so best we
can do
+* is stopping the capture before last DMA
block,
+* whether our CONTIG mode whole buffer or its
last
+* sgbuf in SG mode, gets overwritten by next
frame.
+*/
Hm, why do you think it's a good idea? This specific buffer completed
successfully, but you want to fail it just because the next buffer is
missing? Any specific reason for this?
Maybe my comment is not clear enough, but the below suspend_capture()
doesn't indicate any failure on a frame just captured. It only prevents
the frame from being overwritten by the already autoreinitialized DMA
engine, pointing back to the same buffer once again.
Besides, you seem to also be
considering the possibility of your -ready == NULL, but the queue
non-empty, in which case you just take the next buffer from the queue
and continue with it. Why error out in this case?
pcdev-ready == NULL means no buffer was available when it was time to
put it into the DMA programming register set.
But how? Buffers are added onto the list in omap1_videobuf_queue() under
spin_lock_irqsave(); and there you also check -ready and fill it in.
Guennadi,
Yes, but only if pcdev-active is NULL, ie. both DMA and FIFO are idle, never
if active:
+ list_add_tail(vb-queue, pcdev-capture);
+ vb-state = VIDEOBUF_QUEUED;
+
+ if (pcdev-active)
+ return;
Since the transfer of the DMA programming register set content to the DMA
working register set is done automatically by the DMA hardware, this can
pretty well happen while I keep the lock here, so I can't be sure if it's not
too late for entering new data into the programming register set. Then, I
decided that this operation should be done only just after the DMA interrupt
occured, ie. the current DMA programming register set content has just been
used and can be overwriten.
I'll emphasize the above return; with a comment.
In
your completion you set -ready = NULL, but then also call
prepare_next_vb() to get the next buffer from the list - if there are any,
so, how can it be NULL with a non-empty list?
It happens after the above mentioned prepare_next_vb() gets nothing from an
empty queue, so nothing is entered into the DMA programming register set,
only the last, just activated, buffer is processed, then
omap1_videobuf_queue() puts a new buffer into the queue while the active
buffer is still filled in, and finally the DMA ISR is called on this last
active buffer completion.
I hope this helps.
As a result, a next DMA transfer has
just been autoreinitialized with the same buffer parameters as before. To
protect the buffer from being overwriten unintentionally, we have to stop
the DMA transfer as soon as possible, hopefully before the sensor starts
sending out next frame data.
If a new buffer has been queued meanwhile, best we can do is stopping
everything, programming the DMA with the new buffer, and setting up for a
new transfer hardware auto startup on nearest frame start, be it the next
one if we are lucky enough, or one after the next if we are too slow.
And even if also the queue
is empty - still not sure, why.
I hope the above explanation clarifies why.
I'll try to rework the above comment to be more clear, OK? Any hints?
linux-2.6.36-rc3.orig/include/media/omap1_camera.h 2010-09-03
22:34:02.0 +0200 +++
linux-2.6.36-rc3/include/media/omap1_camera.h 2010-09-08
23:41:12.0 +0200 @@ -0,0 +1,35 @@
+/*
+ * Header for V4L2 SoC Camera driver for OMAP1 Camera Interface
+ *
+ * Copyright (C) 2010, Janusz Krzysztofik jkrzy...@tis.icnet.pl
+ *
+ * This program is free software; you can redistribute it and/or
modify + * it under the terms of the GNU General Public License
version 2 as + * published by the Free Software Foundation.
+ */
+
+#ifndef __MEDIA_OMAP1_CAMERA_H_
+#define __MEDIA_OMAP1_CAMERA_H_
+
+#include linux/bitops.h
+
+#define OMAP1_CAMERA_IOSIZE0x1c
+
+enum omap1_cam_vb_mode {
+ CONTIG = 0,
+ SG,
+};
See above - are these needed here?
+
+#define OMAP1_CAMERA_MIN_BUF_COUNT(x) ((x) == CONTIG ? 3 : 2)
ditto
I moved them both over to the header file
Re: [PATCH v2 3/6] SoC Camera: add driver for OV6650 sensor
Thursday 23 September 2010 18:06:15 Guennadi Liakhovetski napisał(a):
On Wed, 22 Sep 2010, Janusz Krzysztofik wrote:
Wednesday 22 September 2010 11:12:46 Guennadi Liakhovetski napisaÅ(a):
Ok, just a couple more comments, all looking quite good so far, if we
get a new version soon enough, we still might manage it for 2.6.37
On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
[snip]
+/* write a register */
+static int ov6650_reg_write(struct i2c_client *client, u8 reg, u8
val) +{
+ int ret;
+ unsigned char data[2] = { reg, val };
+ struct i2c_msg msg = {
+ .addr = client-addr,
+ .flags = 0,
+ .len= 2,
+ .buf= data,
+ };
+
+ ret = i2c_transfer(client-adapter, msg, 1);
+ msleep_interruptible(1);
Why do you want _interruptible here? Firstly it's just 1ms, secondly -
why?...
My bad. I didn't verified what a real difference between msleep() and
msleep_interruptible() is, only found that msleep_interruptible(1) makes
checkpatch.pl more happy than msleep(1), sorry.
What I can be sure is that a short delay is required here, otherwise the
driver doesn't work correctly. To prevent the checkpatch.pl from
complying against msleep(1), I think I could just replace it with
msleep(20). What do you think?
oh, no, don't think replacing msleep(1) with msleep(20) just to silence a
compiler warning is a god idea...;) Well, use a udelay(1000). Or maybe
try, whether a udelay(100) suffices too.
OK. Thanks for the hints.
+ priv-rect.left = DEF_HSTRT !priv-qcif;
+ priv-rect.top= DEF_VSTRT !priv-qcif;
+ priv-rect.width = mf-width;
+ priv-rect.height = mf-height;
Sorry, don't understand. The sensor can do both - cropping per HSTRT,
HSTOP, VSTRT and VSTOP and scaling per COMA_CIF / COMA_QCIF, right?
Right.
But
which of them is stored in your priv-rect? Is this the input window
(cropping) or the output one (scaling)?
I'm not sure how I can follow your input/output concept here.
Default (reset) values of HSTRT, HSTOP, VSTRT and VSTOP registers are the
same for both CIF and QCIF, giving a 176x144 picture area in both cases.
Than, when in CIF (reset default) mode, which actual size is double of
that (352x288), I scale them by 2 when converting to priv-rect elements.
You overwrite it in .s_fmt and
.s_crop...
I added the priv-rect to be returned by g_crop() instead of
recalculating it from the register values. Then, I think I have to
overwrite it on every geometry change, whether s_crop or s_fmt caused. Am
I missing something?
If I understand your sensor correctly, HSTRT etc. registers configure
pretty much any (input) sensor window,
Let's say, not exceeding CIF geometry (352x288).
whereas COMA and COML select
whether to scale it to a CIF or to a QCIF output.
I think the answer is: not exactly. AFAICT, the COMA_QCIF bit selects whether
to scale it down by 2 (QCIF selection) or not (CIF selection).
So, these are two
different things. Hence your -rect can hold only one of the two - the
sensor window or the output image. Since output image has only two options
- CIF or QCIF, you don't need to store it in rect, you already have
priv-qcif.
With the above reservation - yes, I could use priv-qcif to scale priv-rect
down by 2 or not in g_fmt.
Oh, and one more thing - didn't notice before: in your cropcap you do
+ int shift = !priv-qcif;
...
+ a-bounds.left = DEF_HSTRT shift;
+ a-bounds.top = DEF_VSTRT shift;
+ a-bounds.width = W_QCIF shift;
+ a-bounds.height= H_QCIF shift;
Don't think this is right. cropcap shouldn't depend on any dynamic
(configured by S_FMT) setting, it contains absolute limits of your
hardware. I know I might have produced a couple of bad examples in the
past - before I eventually settled with this definition... So, I think,
it's best to put the full sensor resolution in cropcap.
OK.
...and, please, replace
+ priv-qcif = 1;
with
+ priv-qcif = true;
and
+ priv-qcif = 0;
with
+ priv-qcif = false;
in ov6650_s_fmt().
Sure.
But I think your driver might have a problem with its cropping / scaling
handling. Let's see if I understand it right:
1. as cropcap you currently return QCIF or CIF, depending on the last
S_FMT,
Yes.
BTW, my S_FMT always calls ov6650_reset(), which resets the current crop to
defaults. This behaviour doesn't follow the requirement of this operation
being done only once, when the driver is first loaded, but not later. Should
I restore the last crop after every reset? If yes, what is the purpose of
defrect if applied only at driver first load?
but let's say, you fix it to always return CIF.
OK.
2. in your
Re: [RESEND][PATCH v2 2/6] OMAP1: Add support for SoC camera interface
Friday 24 September 2010 01:23:10 Tony Lindgren napisał(a): * Janusz Krzysztofik jkrzy...@tis.icnet.pl [100910 18:26]: This patch adds support for SoC camera interface to OMAP1 devices. Created and tested against linux-2.6.36-rc3 on Amstrad Delta. For successfull compilation, requires a header file provided by PATCH 1/6 from this series, SoC Camera: add driver for OMAP1 camera interface. snip diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h --- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h 2010-09-0 3 22:34:03.0 +0200 +++ linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h 2010-09-09 18:42:30.0 +0200 @@ -0,0 +1,8 @@ +#ifndef __ASM_ARCH_CAMERA_H_ +#define __ASM_ARCH_CAMERA_H_ + +#include media/omap1_camera.h + +extern void omap1_set_camera_info(struct omap1_cam_platform_data *); + +#endif /* __ASM_ARCH_CAMERA_H_ */ Care to refresh this patch so it does not include media/omap1_camera.h? That way things keep building if I merge this one along with the omap patches and the drivers/media patches can get merged their via media. I think you can just move the OMAP1_CAMERA_IOSIZE to the devices.c or someplace like that? Tony, Not exactly. I use the OMAP1_CAMERA_IOSIZE inside the driver when reserving space for register cache. I think that I could just duplicate its definition in the devices.c for now, than clean things up with a folloup patch when both parts already get merged. Would this be acceptable? Thanks, Janusz Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 v2 5/6] OMAP1: Amstrad Delta: add support for camera
Friday 24 September 2010 01:26:17 Tony Lindgren napisał(a): * Tony Lindgren t...@atomide.com [100923 16:06]: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [100910 18:20]: This patch adds configuration data and initialization code required for camera support to the Amstrad Delta board. Three devices are declared: SoC camera, OMAP1 camera interface and OV6650 sensor. Default 12MHz clock has been selected for driving the sensor. Pixel clock has been limited to get reasonable frame rates, not exceeding the board capabilities. Since both devices (interface and sensor) support both pixel clock polarities, decision on polarity selection has been left to drivers. Interface GPIO line has been found not functional, thus not configured. Created and tested against linux-2.6.36-rc3. Works on top of previous patches from the series, at least 1/6, 2/6 and 3/6. Queuing these last two patches of the series (5/6 and 6/6) for the upcoming merge window. BTW, these still depend on updated 2/6 to make compile happy. Not so simple: still depends on struct omap1_cam_platform_data definition from media/omap1_camera.h, included from mach/camera.h. Are you ready to accept another temporary workaround? Thanks, Janusz Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 v2 1/6] SoC Camera: add driver for OMAP1 camera interface
Wednesday 22 September 2010 01:23:22 Guennadi Liakhovetski napisał(a):
On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
This is a V4L2 driver for TI OMAP1 SoC camera interface.
Both videobuf-dma versions are supported, contig and sg, selectable with
a module option. The former uses less processing power, but often fails
to allocate contignuous buffer memory. The latter is free of this
problem, but generates tens of DMA interrupts per frame. If contig memory
allocation ever fails, the driver falls back to sg automatically on next
open, but still can be switched back to contig manually. Both paths work
stable for me, even under heavy load, on my OMAP1510 based Amstrad Delta
videophone, that is the oldest, least powerfull OMAP1 implementation.
The interface generally works in pass-through mode. Since input data byte
endianess can be swapped, it provides up to two v4l2 pixel formats per
each of several soc_mbus formats that have their swapped endian
counterparts.
Boards using this driver can provide it with the followning information:
- if and what freqency clock is expected by an on-board camera sensor,
- what is the maximum pixel clock that should be accepted from the
sensor, - what is the polarity of the sensor provided pixel clock,
- if the interface GPIO line is connected to a sensor reset/powerdown
input and what is the input polarity.
Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Friday 30 July 2010 13:07:42 Guennadi Liakhovetski wrote:
So, I think, a very welcome improvement to the driver would be a
cleaner separation between the two cases. Don't try that much to reuse
the code as much as possible. Would be much better to have clean
separation between the two implementations - whether dynamically
switchable at runtime or at config time - would be best to separate the
two
implementations to the point, where each of them becomes understandable
and maintainable.
Guennadi,
I've tried to rearrange them spearated, as you requested, but finally
decided to keep them together, as before, only better documented and
cleaned up as much as possible. I'm rather satisfied with the result, but
if you think it is still not enough understandable and maintainable, I'll
take one more iteration and split both paths.
Well, I think, I'll move a bit towards the if it breaks - someone gets to
fix it, or it gets dropped policy, i.e., I'll give you more freedom
(don't know what's wrong with me today;))
Hi Guennadi,
Thanks!
...
+#define DMA_FRAME_SHIFT(x) (x ? DMA_FRAME_SHIFT_SG : \
+ DMA_FRAME_SHIFT_CONTIG)
Don't you want to compare (x) against CONTIG and you want to put x in
parenthesis in the DMA_FRAME_SHIFT macro.
Sure.
Besides, CONTIG and SG are not
good enough names to be defined in a header under include/... Looks like
you don't need them at all in the header? You only use them in this file,
so, just move them inside.
Please see my very last comment below.
...
+static void videobuf_done(struct omap1_cam_dev *pcdev,
+ enum videobuf_state result)
+{
+ struct omap1_cam_buf *buf = pcdev-active;
+ struct videobuf_buffer *vb;
+ struct device *dev = pcdev-icd-dev.parent;
+
+ if (WARN_ON(!buf)) {
+ suspend_capture(pcdev);
+ disable_capture(pcdev);
+ return;
+ }
+
+ if (result == VIDEOBUF_ERROR)
+ suspend_capture(pcdev);
+
+ vb = buf-vb;
+ if (waitqueue_active(vb-done)) {
+ if (!pcdev-ready result != VIDEOBUF_ERROR)
+ /*
+* No next buffer has been entered into the DMA
+* programming register set on time, so best we can do
+* is stopping the capture before last DMA block,
+* whether our CONTIG mode whole buffer or its last
+* sgbuf in SG mode, gets overwritten by next frame.
+*/
Hm, why do you think it's a good idea? This specific buffer completed
successfully, but you want to fail it just because the next buffer is
missing? Any specific reason for this?
Maybe my comment is not clear enough, but the below suspend_capture() doesn't
indicate any failure on a frame just captured. It only prevents the frame
from being overwritten by the already autoreinitialized DMA engine, pointing
back to the same buffer once again.
Besides, you seem to also be
considering the possibility of your -ready == NULL, but the queue
non-empty, in which case you just take the next buffer from the queue and
continue with it. Why error out in this case?
pcdev-ready == NULL means no buffer was available when it was time to put it
into the DMA programming register set. As a result, a next DMA transfer has
just been autoreinitialized with the same
Re: [PATCH v2 2/6] OMAP1: Add support for SoC camera interface
Wednesday 22 September 2010 08:53:19 Guennadi Liakhovetski napisał(a):
That's up to the platform maintainer to review / apply this one, but if
you like, a couple of nit-picks from me:
Guennadi,
Thanks for also looking at this!
On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
This patch adds support for SoC camera interface to OMAP1 devices.
Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
For successfull compilation, requires a header file provided by PATCH 1/6
from this series, SoC Camera: add driver for OMAP1 camera interface.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/devices.c | 43
++
arch/arm/mach-omap1/include/mach/camera.h |8 +
2 files changed, 51 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c
linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c 2010-09-03
22:29:00.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c 2010-09-09
18:42:30.0 +0200
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/spi/spi.h
+#include linux/dma-mapping.h
#include mach/hardware.h
#include asm/mach/map.h
@@ -25,6 +26,7 @@
#include mach/gpio.h
#include plat/mmc.h
#include plat/omap7xx.h
+#include mach/camera.h
You might want to try to group headers according to their location, i.e.,
put mach/... higher - together with mach/gpio.h, also it helps to have
headers alphabetically ordered.
Yes, I will, thank you.
/*---
--*/
@@ -191,6 +193,47 @@ static inline void omap_init_spi100k(voi
}
#endif
+
+#define OMAP1_CAMERA_BASE 0xfffb6800
+
+static struct resource omap1_camera_resources[] = {
+ [0] = {
+ .start = OMAP1_CAMERA_BASE,
+ .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = INT_CAMERA,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device omap1_camera_device = {
+ .name = omap1-camera,
+ .id = 0, /* This is used to put cameras on this interface */
+ .dev= {
+ .dma_mask = omap1_camera_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .num_resources = ARRAY_SIZE(omap1_camera_resources),
+ .resource = omap1_camera_resources,
+};
+
+void __init omap1_set_camera_info(struct omap1_cam_platform_data *info)
+{
+ struct platform_device *dev = omap1_camera_device;
+ int ret;
+
+ dev-dev.platform_data = info;
+
+ ret = platform_device_register(dev);
+ if (ret)
+ dev_err(dev-dev, unable to register device: %d\n, ret);
+}
+
+
/*---
--*/
static inline void omap_init_sti(void) {}
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
---
linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
2010-09-0
3 22:34:03.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
2010-09-09
18:42:30.0 +0200
@@ -0,0 +1,8 @@
+#ifndef __ASM_ARCH_CAMERA_H_
+#define __ASM_ARCH_CAMERA_H_
+
+#include media/omap1_camera.h
+
+extern void omap1_set_camera_info(struct omap1_cam_platform_data *);
function declarations don't need an extern - something I've also been
doing needlessly for a few years...
Good to know. I'll drop it.
Tony,
Any comments from you before I submit a hopefully final version?
Thanks,
Janusz
+
+#endif /* __ASM_ARCH_CAMERA_H_ */
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 3/6] SoC Camera: add driver for OV6650 sensor
Wednesday 22 September 2010 11:12:46 Guennadi Liakhovetski napisał(a):
Ok, just a couple more comments, all looking quite good so far, if we get
a new version soon enough, we still might manage it for 2.6.37
On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
[snip]
+/* write a register */
+static int ov6650_reg_write(struct i2c_client *client, u8 reg, u8 val)
+{
+ int ret;
+ unsigned char data[2] = { reg, val };
+ struct i2c_msg msg = {
+ .addr = client-addr,
+ .flags = 0,
+ .len= 2,
+ .buf= data,
+ };
+
+ ret = i2c_transfer(client-adapter, msg, 1);
+ msleep_interruptible(1);
Why do you want _interruptible here? Firstly it's just 1ms, secondly -
why?...
My bad. I didn't verified what a real difference between msleep() and
msleep_interruptible() is, only found that msleep_interruptible(1) makes
checkpatch.pl more happy than msleep(1), sorry.
What I can be sure is that a short delay is required here, otherwise the
driver doesn't work correctly. To prevent the checkpatch.pl from complying
against msleep(1), I think I could just replace it with msleep(20). What do
you think?
+
+ if (ret 0) {
+ dev_err(client-dev, Failed writing register 0x%02x!\n, reg);
+ return ret;
+ }
+ return 0;
+}
...
+/* set the format we will capture in */
+static int ov6650_s_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *mf)
+{
+ struct i2c_client *client = sd-priv;
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_sense *sense = icd-sense;
+ struct ov6650 *priv = to_ov6650(client);
+ enum v4l2_mbus_pixelcode code = mf-code;
+ unsigned long pclk;
+ u8 coma_set = 0, coma_mask = 0, coml_set = 0, coml_mask = 0;
+ u8 clkrc, clkrc_div;
+ int ret;
+
+ /* select color matrix configuration for given color encoding */
+ switch (code) {
+ case V4L2_MBUS_FMT_GREY8_1X8:
+ dev_dbg(client-dev, pixel format GREY8_1X8\n);
+ coma_set |= COMA_BW;
+ coma_mask |= COMA_RGB | COMA_WORD_SWAP | COMA_BYTE_SWAP;
+ break;
+ case V4L2_MBUS_FMT_YUYV8_2X8:
+ dev_dbg(client-dev, pixel format YUYV8_2X8_LE\n);
+ coma_set |= COMA_WORD_SWAP;
+ coma_mask |= COMA_RGB | COMA_BW | COMA_BYTE_SWAP;
+ break;
+ case V4L2_MBUS_FMT_YVYU8_2X8:
+ dev_dbg(client-dev, pixel format YVYU8_2X8_LE (untested)\n);
+ coma_mask |= COMA_RGB | COMA_BW | COMA_WORD_SWAP |
+ COMA_BYTE_SWAP;
+ break;
+ case V4L2_MBUS_FMT_UYVY8_2X8:
+ dev_dbg(client-dev, pixel format YUYV8_2X8_BE\n);
+ if (mf-width == W_CIF) {
+ coma_set |= COMA_BYTE_SWAP | COMA_WORD_SWAP;
+ coma_mask |= COMA_RGB | COMA_BW;
+ } else {
+ coma_set |= COMA_BYTE_SWAP;
+ coma_mask |= COMA_RGB | COMA_BW | COMA_WORD_SWAP;
+ }
+ break;
+ case V4L2_MBUS_FMT_VYUY8_2X8:
+ dev_dbg(client-dev, pixel format YVYU8_2X8_BE (untested)\n);
+ if (mf-width == W_CIF) {
+ coma_set |= COMA_BYTE_SWAP;
+ coma_mask |= COMA_RGB | COMA_BW | COMA_WORD_SWAP;
+ } else {
+ coma_set |= COMA_BYTE_SWAP | COMA_WORD_SWAP;
+ coma_mask |= COMA_RGB | COMA_BW;
+ }
+ break;
+ case V4L2_MBUS_FMT_SBGGR8_1X8:
+ dev_dbg(client-dev, pixel format SBGGR8_1X8 (untested)\n);
+ coma_set |= COMA_RAW_RGB | COMA_RGB;
+ coma_mask |= COMA_BW | COMA_BYTE_SWAP | COMA_WORD_SWAP;
+ break;
+ default:
+ dev_err(client-dev, Pixel format not handled: 0x%x\n, code);
+ return -EINVAL;
+ }
+ priv-code = code;
+
+ if ((code == V4L2_MBUS_FMT_GREY8_1X8) ||
+ (code == V4L2_MBUS_FMT_SBGGR8_1X8)) {
Superfluous parenthesis
Will be dropped.
+ coml_mask |= COML_ONE_CHANNEL;
+ priv-pclk_max = 400;
+ } else {
+ coml_set |= COML_ONE_CHANNEL;
+ priv-pclk_max = 800;
+ }
coml_mask and coml_set are only set here and only used once below, so,
dropping initialisation to 0 in variable definitions and just doing
+ if (code == V4L2_MBUS_FMT_GREY8_1X8 ||
+ code == V4L2_MBUS_FMT_SBGGR8_1X8) {
+ coml_mask = COML_ONE_CHANNEL;
+ coml_set = 0;
+ priv-pclk_max = 400;
+ } else {
+ coml_mask = 0;
+ coml_set = COML_ONE_CHANNEL;
+ priv-pclk_max = 800;
+ }
would work too.
OK, I'll use your prefered pattern.
+
+ if (code == V4L2_MBUS_FMT_SBGGR8_1X8)
+ priv-colorspace = V4L2_COLORSPACE_SRGB
[PATCH v2 4/6] SoC Camera: add support for g_parm / s_parm operations
This patch adds support for g_parm / s_parm operations to the SoC Camera
framework. It is usefull for checking/setting camera frame rate.
Example usage can be found in the previous patch from this series,
SoC Camera: add driver for OV6650 sensor.
Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3.
drivers/media/video/soc_camera.c | 18 ++
1 file changed, 18 insertions(+)
diff -upr linux-2.6.36-rc3.orig/drivers/media/video/soc_camera.c
linux-2.6.36-rc3/drivers/media/video/soc_camera.c
--- linux-2.6.36-rc3.orig/drivers/media/video/soc_camera.c 2010-09-03
22:29:44.0 +0200
+++ linux-2.6.36-rc3/drivers/media/video/soc_camera.c 2010-09-03
22:34:03.0 +0200
@@ -1148,6 +1148,20 @@ static int default_s_crop(struct soc_cam
return v4l2_subdev_call(sd, video, s_crop, a);
}
+static int default_g_parm(struct soc_camera_device *icd,
+ struct v4l2_streamparm *parm)
+{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ return v4l2_subdev_call(sd, video, g_parm, parm);
+}
+
+static int default_s_parm(struct soc_camera_device *icd,
+ struct v4l2_streamparm *parm)
+{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ return v4l2_subdev_call(sd, video, s_parm, parm);
+}
+
static void soc_camera_device_init(struct device *dev, void *pdata)
{
dev-platform_data = pdata;
@@ -1179,6 +1193,10 @@ int soc_camera_host_register(struct soc_
ici-ops-get_crop = default_g_crop;
if (!ici-ops-cropcap)
ici-ops-cropcap = default_cropcap;
+ if (!ici-ops-set_parm)
+ ici-ops-set_parm = default_s_parm;
+ if (!ici-ops-get_parm)
+ ici-ops-get_parm = default_g_parm;
mutex_lock(list_lock);
list_for_each_entry(ix, hosts, list) {
--
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 v2 5/6] OMAP1: Amstrad Delta: add support for camera
This patch adds configuration data and initialization code required for camera
support to the Amstrad Delta board.
Three devices are declared: SoC camera, OMAP1 camera interface and OV6650
sensor.
Default 12MHz clock has been selected for driving the sensor. Pixel clock has
been limited to get reasonable frame rates, not exceeding the board
capabilities. Since both devices (interface and sensor) support both pixel
clock polarities, decision on polarity selection has been left to drivers.
Interface GPIO line has been found not functional, thus not configured.
Created and tested against linux-2.6.36-rc3.
Works on top of previous patches from the series, at least 1/6, 2/6 and 3/6.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/board-ams-delta.c | 45 ++
1 file changed, 45 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c
linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c 2010-09-03
22:29:00.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c 2010-09-10
22:01:24.0 +0200
@@ -19,6 +19,8 @@
#include linux/platform_device.h
#include linux/serial_8250.h
+#include media/soc_camera.h
+
#include asm/serial.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -32,6 +34,7 @@
#include plat/usb.h
#include plat/board.h
#include plat/common.h
+#include mach/camera.h
#include mach/ams-delta-fiq.h
@@ -213,10 +216,37 @@ static struct platform_device ams_delta_
.id = -1
};
+static struct i2c_board_info ams_delta_camera_board_info[] = {
+ {
+ I2C_BOARD_INFO(ov6650, 0x60),
+ },
+};
+
+static struct soc_camera_link __initdata ams_delta_iclink = {
+ .bus_id = 0,/* OMAP1 SoC camera bus */
+ .i2c_adapter_id = 1,
+ .board_info = ams_delta_camera_board_info[0],
+ .module_name= ov6650,
+};
+
+static struct platform_device ams_delta_camera_device = {
+ .name = soc-camera-pdrv,
+ .id = 0,
+ .dev= {
+ .platform_data = ams_delta_iclink,
+ },
+};
+
+static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
+ .camexclk_khz = 12000,/* default 12MHz clock, no extra DPLL */
+ .lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
+};
+
static struct platform_device *ams_delta_devices[] __initdata = {
ams_delta_kp_device,
ams_delta_lcd_device,
ams_delta_led_device,
+ ams_delta_camera_device,
};
static void __init ams_delta_init(void)
@@ -225,6 +255,20 @@ static void __init ams_delta_init(void)
omap_cfg_reg(UART1_TX);
omap_cfg_reg(UART1_RTS);
+ /* parallel camera interface */
+ omap_cfg_reg(H19_1610_CAM_EXCLK);
+ omap_cfg_reg(J15_1610_CAM_LCLK);
+ omap_cfg_reg(L18_1610_CAM_VS);
+ omap_cfg_reg(L15_1610_CAM_HS);
+ omap_cfg_reg(L19_1610_CAM_D0);
+ omap_cfg_reg(K14_1610_CAM_D1);
+ omap_cfg_reg(K15_1610_CAM_D2);
+ omap_cfg_reg(K19_1610_CAM_D3);
+ omap_cfg_reg(K18_1610_CAM_D4);
+ omap_cfg_reg(J14_1610_CAM_D5);
+ omap_cfg_reg(J19_1610_CAM_D6);
+ omap_cfg_reg(J18_1610_CAM_D7);
+
iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc));
omap_board_config = ams_delta_config;
@@ -236,6 +280,7 @@ static void __init ams_delta_init(void)
ams_delta_latch2_write(~0, 0);
omap1_usb_init(ams_delta_usb_config);
+ omap1_set_camera_info(ams_delta_camera_platform_data);
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
#ifdef CONFIG_AMS_DELTA_FIQ
--
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 v2 6/6] OMAP1: Amstrad Delta: add camera controlled LEDS trigger
This patch extends the Amstrad Delta camera support with LEDS trigger that can
be used for automatic control of the on-board camera LED. The led turns on
automatically on camera device open and turns off on camera device close.
Created and tested against linux-2.6.36-rc3.
Works on top of patch 5/6, OMAP1: Amstrad Delta: add support for on-board
camera
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Having no comments received on v1 of this patch, I assume nobody could see any
benefit if I implemented this idea at the SoC camera or OMAP1 camera level,
so I'm leaveing it as an Amstrad Delta only feature, as it originally was for
v1.
Thanks,
Janusz
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3.
arch/arm/mach-omap1/board-ams-delta.c | 24
1 file changed, 24 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c
linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c 2010-09-10
22:01:24.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c 2010-09-10
22:08:29.0 +0200
@@ -16,6 +16,7 @@
#include linux/init.h
#include linux/input.h
#include linux/interrupt.h
+#include linux/leds.h
#include linux/platform_device.h
#include linux/serial_8250.h
@@ -222,11 +223,30 @@ static struct i2c_board_info ams_delta_c
},
};
+#ifdef CONFIG_LEDS_TRIGGERS
+DEFINE_LED_TRIGGER(ams_delta_camera_led_trigger);
+
+static int ams_delta_camera_power(struct device *dev, int power)
+{
+ /*
+* turn on camera LED
+*/
+ if (power)
+ led_trigger_event(ams_delta_camera_led_trigger, LED_FULL);
+ else
+ led_trigger_event(ams_delta_camera_led_trigger, LED_OFF);
+ return 0;
+}
+#else
+#define ams_delta_camera_power NULL
+#endif
+
static struct soc_camera_link __initdata ams_delta_iclink = {
.bus_id = 0,/* OMAP1 SoC camera bus */
.i2c_adapter_id = 1,
.board_info = ams_delta_camera_board_info[0],
.module_name= ov6650,
+ .power = ams_delta_camera_power,
};
static struct platform_device ams_delta_camera_device = {
@@ -281,6 +301,10 @@ static void __init ams_delta_init(void)
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
+#ifdef CONFIG_LEDS_TRIGGERS
+ led_trigger_register_simple(ams_delta_camera,
+ ams_delta_camera_led_trigger);
+#endif
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
#ifdef CONFIG_AMS_DELTA_FIQ
--
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
[RESEND][PATCH v2 2/6] OMAP1: Add support for SoC camera interface
This patch adds support for SoC camera interface to OMAP1 devices.
Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
For successfull compilation, requires a header file provided by PATCH 1/6 from
this series, SoC Camera: add driver for OMAP1 camera interface.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Resend because of wrapped lines, sorry.
Janusz
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/devices.c | 43 ++
arch/arm/mach-omap1/include/mach/camera.h |8 +
2 files changed, 51 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c
linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c 2010-09-03
22:29:00.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c 2010-09-09
18:42:30.0 +0200
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/spi/spi.h
+#include linux/dma-mapping.h
#include mach/hardware.h
#include asm/mach/map.h
@@ -25,6 +26,7 @@
#include mach/gpio.h
#include plat/mmc.h
#include plat/omap7xx.h
+#include mach/camera.h
/*-*/
@@ -191,6 +193,47 @@ static inline void omap_init_spi100k(voi
}
#endif
+
+#define OMAP1_CAMERA_BASE 0xfffb6800
+
+static struct resource omap1_camera_resources[] = {
+ [0] = {
+ .start = OMAP1_CAMERA_BASE,
+ .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = INT_CAMERA,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device omap1_camera_device = {
+ .name = omap1-camera,
+ .id = 0, /* This is used to put cameras on this interface */
+ .dev= {
+ .dma_mask = omap1_camera_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .num_resources = ARRAY_SIZE(omap1_camera_resources),
+ .resource = omap1_camera_resources,
+};
+
+void __init omap1_set_camera_info(struct omap1_cam_platform_data *info)
+{
+ struct platform_device *dev = omap1_camera_device;
+ int ret;
+
+ dev-dev.platform_data = info;
+
+ ret = platform_device_register(dev);
+ if (ret)
+ dev_err(dev-dev, unable to register device: %d\n, ret);
+}
+
+
/*-*/
static inline void omap_init_sti(void) {}
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
2010-09-03 22:34:03.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h 2010-09-09
18:42:30.0 +0200
@@ -0,0 +1,8 @@
+#ifndef __ASM_ARCH_CAMERA_H_
+#define __ASM_ARCH_CAMERA_H_
+
+#include media/omap1_camera.h
+
+extern void omap1_set_camera_info(struct omap1_cam_platform_data *);
+
+#endif /* __ASM_ARCH_CAMERA_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
Re: [RFC] [PATCH 3/6] SoC Camera: add driver for OV6650 sensor
Hi Guennadi,
Thanks for your review time.
Sunday 22 August 2010 18:40:13 Guennadi Liakhovetski wrote:
On Sun, 18 Jul 2010, Janusz Krzysztofik wrote:
This patch provides a V4L2 SoC Camera driver for OV6650 camera sensor,
found on OMAP1 SoC based Amstrad Delta videophone.
Have you also had a look at drivers/media/video/gspca/sonixb.c - in also
supports ov6650 among other sensors.
Yes, I have, but given up for now since:
1. the gspca seems using the sensor in Bayer 8 BGGR mode only, which I was
not even able to select using mplayer to test my drivers with,
2. not all settings used there are clear for me, so I've decided to revisit
them later, when I first get a stable, even if not perfect, working driver
version accepted, instead of following them blindly.
Since I have no experience with camera sensors, and the sensor
documentation I was able to find was not very comprehensive, I left most
settings at their default (reset) values, except for:
- those required for proper mediabus parameters and picture format setup,
- those used by controls.
Resulting picture quality is far from perfect, but better than nothing.
...
--- linux-2.6.35-rc3.orig/drivers/media/video/ov6650.c 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.35-rc3/drivers/media/video/ov6650.c 2010-07-18
02:06:22.0 +0200
@@ -0,0 +1,1336 @@
+/*
+ * V4L2 SoC Camera driver for OmniVision OV6650 Camera Sensor
+ *
+ * Copyright (C) 2010 Janusz Krzysztofik jkrzy...@tis.icnet.pl
+ *
+ * Based on OmniVision OV96xx Camera Driver
+ * Copyright (C) 2009 Marek Vasut marek.va...@gmail.com
+ *
+ * Based on ov772x camera driver:
+ * Copyright (C) 2008 Renesas Solutions Corp.
+ * Kuninori Morimoto morimoto.kunin...@renesas.com
+ *
+ * Based on ov7670 and soc_camera_platform driver,
+ * Copyright 2006-7 Jonathan Corbet cor...@lwn.net
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski ker...@pengutronix.de
+ *
+ * Hardware specific bits initialy based on former work by Matt Callow
+ * drivers/media/video/omap/sensor_ov6650.c
+ * Copyright (C) 2006 Matt Callow
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/delay.h
+#include media/v4l2-chip-ident.h
+#include media/soc_camera.h
Please, sort headers alphabetically (media/ and linux/ separately, of
course).
OK.
+
+
+/* Register definitions */
+#defineREG_GAIN0x00/* range 00 - 3F */
+#defineREG_BLUE0x01
+#defineREG_RED 0x02
+#defineREG_SAT 0x03/* [7:4] saturation [0:3]
reserved */
+#defineREG_HUE 0x04/* [7:6] rsrvd [5] hue en [4:0]
hue */
+
+#defineREG_BRT 0x06
+
+#defineREG_PIDH0x0a
+#defineREG_PIDL0x0b
+
+#defineREG_AECH0x10
+#defineREG_CLKRC 0x11/* Data Format and Internal
Clock */
+ /* [7:6] Input system clock (MHz)*/
+ /* 00=8, 01=12, 10=16, 11=24 */
+ /* [5:0]: Internal Clock Pre-Scaler */
+#defineREG_COMA0x12/* [7] Reset */
+#defineREG_COMB0x13
+#defineREG_COMC0x14
+#defineREG_COMD0x15
+#define REG_COML 0x16
You used TAB in most defines and a space in this one and a few ones below.
Please, use the same for all (I personally would just use a space).
Agree.
...
+
+#define NUM_REGS (REG_BMCO + 1)
NUM_REGS is unused, don't need to define it.
OK.
...
+#define SAT_SHIFT 4
+#define SAT_MASK 0xf
+#define SET_SAT(x) (((x) SAT_MASK) SAT_SHIFT)
Nitpicking, but I would
+#define SAT_SHIFT4
+#define SAT_MASK 0xf0
+#define SET_SAT(x) (((x) SAT_SHIFT) SAT_MASK)
Advantage: your SAT_MASK is already correctly shifted, so, you don't have
to you SET_SAT(SAT_MASK) to get to the register value.
You're right.
+
+#define HUE_EN BIT(5)
You have to #include linux/bitops.h for the BIT() macro
OK.
...
+/* write a register */
+static int ov6650_reg_write(struct i2c_client *client, u8 reg, u8 val)
+{
+ int ret;
+ u8 _val;
+ unsigned char data[2] = { reg, val };
+ struct i2c_msg msg = {
+ .addr = client-addr,
+ .flags = 0,
+ .len= 2,
+ .buf= data,
+ };
+
+ ret = i2c_transfer(client-adapter, msg, 1);
+ if (ret 0) {
+ dev_err(client-dev, Failed writing register 0x%02x!\n, reg
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
Monday 16 August 2010 12:17:36 Marin Mitov wrote: On Saturday, August 14, 2010 08:33:09 pm Guennadi Liakhovetski wrote: On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Friday 13 August 2010 11:11:52 Marin Mitov napisał(a): On Friday, August 13, 2010 11:52:41 am Guennadi Liakhovetski wrote: On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. I already tried before to find out how I could allocate memory at init without reinventing a new videobuf-dma-contig implementation. Since in the Documentation/video4linux/videobuf I've read that videobuf does not currently play well with drivers that play tricks by allocating DMA space at system boot time, I've implemented the alternate sg path. If it's not quite true what the documentation says and you can give me a hint how this could be done, I might try again. For an example look at arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma(). Yes, this is the solution that suffers from the already discussed limitation of not being able to remap a memory with different attributes, which affects OMAP1 as well. For preallocating dma-coherent memory for device personal use during device probe() time (when the memory is less fragmented compared to open() time) see also dt3155_alloc_coherent/dt3155_free_coherent in drivers/staging/dt3155v4l/dt3155vfl.c (for x86 arch, I do not know if it works for arm arch) With this workaround applied, I get much better results, thank you Marin. However, it seems not bullet proof, since mmap still happens to fail for a reason not quite clear to me: What exactly does this mean - happens to fail - you mean starting and stopping mplayer several times? Can you verify, that you're not leaking memory? That you're freeing all allocated DMA memory again? Are you using the same parameters to mplayer, right? As for the work-around - can you not do this in your board late-initcall function? Not sure whether and how one can get this in the mainline. This is in principle the same, as in the above dma_declare_coherent_memory() example, only open-coded without the ioremap. My believe is that dma_declare_coherent_memory() could be used if your frame grabber has local RAM buffer (like video buffer if the graphic adapters) defined by BAR - that is why you need ioremap(). If this RAM turns out to be coherent you use dma_declare_coherent_memory() and any further invocation of dma_alloc_coherent() will allocate from it (till it is exosted). My use of dt3155_alloc_coherent()/dt3155_free_coherent() is to allocate a block of coherent 4MB memory during driver probe() method and use it latter (via videobuff_dma_contig framework)). Maybe we can add a suitable function to the dma-alloc API... Could be of general use, I am thinking about this. This could be done by just renaming dt3155_alloc_coherent()/dt3155_free_coherent() to something acceptable (dma_reserve_coherent_memory()/dma_release_reserved_memory(), I am open for suggestions) and export them. Should be added to drivers/base/dma-coherent.c. Hi Marin, Since I've finaly managed to make use of your method without any previously observerd limitations (see below), I'm interested in it being implemented system-wide. Are you going to submit a patch? I would suggest creating one common function that allocates and fills the dev-dma_mem structure, and two wrappers that call it: a dma_declare_coherent_memory() replacement, that passes an ioremapped device memory address to the common fuction, and your proposed dma_reserve_coherent_memory(), that passes a pointer returned by the dma_alloc_coherent() instead. [ 6067.22] omap1-camera omap1-camera.0: OMAP1 Camera driver attached to camera 0 [ 6067.65] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315659 not found [ 6067.68] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315559 not found [ 6068.48] mplayer: page allocation failure. order:6, mode:0xd0 [ 6068.50] Backtrace: [ 6068.52] [c0028950] (dump_backtrace+0x0/0x110) from [c0028ea8] (dump_stack+0x18/0x1c) [ 6068.56] r6:0006 r5:00d0 r4:c1bcf000 [ 6068.59] [c0028e90] (dump_stack+0x0/0x1c) from [c0074e24] (__alloc_pages_nodemask+0x504/0x560) [ 6068.62] [c0074920] (__alloc_pages_nodemask+0x0/0x560) from [c002ae14] (__dma_alloc+0x108/0x354) [ 6068.66] [c002ad0c] (__dma_alloc+0x0/0x354) from [c002b0ec] (dma_alloc_coherent+0x58/0x64
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
Thursday 19 August 2010 14:16:21 Marin Mitov napisał(a):
On Thursday, August 19, 2010 02:39:47 pm Guennadi Liakhovetski wrote:
No, I don't think you should go to the next power of 2 - that's too
crude. Try rounding your buffer size to the page size, that should
suffice.
Guennadi,
If you have a look at how a device reserved memory is next allocated to a
driver with drivers/base/dma-coherent.c::dma_alloc_from_coherent(), then than
you may find my conclusion on a power of 2 as true:
int dma_alloc_from_coherent(struct device *dev, ssize_t size,
dma_addr_t *dma_handle, void **ret)
{
...
int order = get_order(size);
...
pageno = bitmap_find_free_region(mem-bitmap, mem-size, order);
...
}
Allocated coherent memory is always a power of 2.
Marin,
For ARM, this seems true as long as allocated with the above from a device
assigned pool, but not true for a (pre)allocation from a generic system RAM.
See arch/arm/mm/dma-mapping.c::__dma_alloc_buffer(), where it looks like extra
pages are freed:
static struct page *__dma_alloc_buffer(struct device *dev, size_t size, gfp_t
gfp)
{
unsigned long order = get_order(size);
...
page = alloc_pages(gfp, order);
...
split_page(page, order);
for (p = page + (size PAGE_SHIFT), e = page + (1 order); p e;
p++)
__free_page(p);
...
}
Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
Saturday 14 August 2010 19:33:09 Guennadi Liakhovetski napisał(a): On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Friday 13 August 2010 11:11:52 Marin Mitov napisał(a): On Friday, August 13, 2010 11:52:41 am Guennadi Liakhovetski wrote: On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. I already tried before to find out how I could allocate memory at init without reinventing a new videobuf-dma-contig implementation. Since in the Documentation/video4linux/videobuf I've read that videobuf does not currently play well with drivers that play tricks by allocating DMA space at system boot time, I've implemented the alternate sg path. If it's not quite true what the documentation says and you can give me a hint how this could be done, I might try again. For an example look at arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma(). Yes, this is the solution that suffers from the already discussed limitation of not being able to remap a memory with different attributes, which affects OMAP1 as well. For preallocating dma-coherent memory for device personal use during device probe() time (when the memory is less fragmented compared to open() time) see also dt3155_alloc_coherent/dt3155_free_coherent in drivers/staging/dt3155v4l/dt3155vfl.c (for x86 arch, I do not know if it works for arm arch) With this workaround applied, I get much better results, thank you Marin. However, it seems not bullet proof, since mmap still happens to fail for a reason not quite clear to me: What exactly does this mean - happens to fail - you mean starting and stopping mplayer several times? What I am able to reproduce is a failure on very first camera access after boot. Then, it seems working as expected for subsequent accesses, as long as there is no other activity (VoIP or video over bluetooth PAN in my case). Then, it usualy fails once, and starts working back againg. However, it happened once that it broke permanently after a bluetooth related error. Without the work-around, it works after boot for ca. 50% tries, then, after some VoIP or video over PAN activity, refuses to allocate memory for DMA any longer. IOW, the work-around helps, but doesn't provide a 100% guarrantee. Can you verify, that you're not leaking memory? That you're freeing all allocated DMA memory again? Are you using the same parameters to mplayer, right? I've been using the same testing procedure for the last 2-3 months, since I started the driver development. It never failed to allocate DMA memory for SG mode. As for the work-around - can you not do this in your board late-initcall function? One of the arguments of this custom fuction is the camera interface device structre pointer. I don't know how I could get access to this pointer from my board code. Not sure whether and how one can get this in the mainline. This is in principle the same, as in the above dma_declare_coherent_memory() example, only open-coded without the ioremap. Maybe we can add a suitable function to the dma-alloc API... With my limited skills, I'd rather wait for a solution promissed by RMK for next merge window ;). Thanks, Janusz Thanks Guennadi [ 6067.22] omap1-camera omap1-camera.0: OMAP1 Camera driver attached to camera 0 [ 6067.65] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315659 not found [ 6067.68] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315559 not found [ 6068.48] mplayer: page allocation failure. order:6, mode:0xd0 [ 6068.50] Backtrace: [ 6068.52] [c0028950] (dump_backtrace+0x0/0x110) from [c0028ea8] (dump_stack+0x18/0x1c) [ 6068.56] r6:0006 r5:00d0 r4:c1bcf000 [ 6068.59] [c0028e90] (dump_stack+0x0/0x1c) from [c0074e24] (__alloc_pages_nodemask+0x504/0x560) [ 6068.62] [c0074920] (__alloc_pages_nodemask+0x0/0x560) from [c002ae14] (__dma_alloc+0x108/0x354) [ 6068.66] [c002ad0c] (__dma_alloc+0x0/0x354) from [c002b0ec] (dma_alloc_coherent+0x58/0x64) [ 6068.70] [c002b094] (dma_alloc_coherent+0x0/0x64) from [bf000a44] (__videobuf_mmap_mapper+0x10c/0x374 [videobuf_dma_contig]) [ 6068.74] r7:c16934c0 r6: r5:c171baec r4: [ 6068.77] [bf000938] (__videobuf_mmap_mapper+0x0/0x374 [videobuf_dma_contig]) from [c01f9a78] (videobuf_mmap_mapper+0xc4/0x108) [ 6068.81] [c01f99b4] (videobuf_mmap_mapper+0x0/0x108) from [c01fc1ac] (soc_camera_mmap+0x80/0x140) [ 6068.84] r5:c1a3b4e0 r4: [ 6068.87] [c01fc12c] (soc_camera_mmap
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
Saturday 14 August 2010 06:47:56 Marin Mitov napisał(a): On Friday, August 13, 2010 10:13:08 pm Janusz Krzysztofik wrote: Friday 13 August 2010 11:11:52 Marin Mitov napisał(a): On Friday, August 13, 2010 11:52:41 am Guennadi Liakhovetski wrote: On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. I already tried before to find out how I could allocate memory at init without reinventing a new videobuf-dma-contig implementation. Since in the Documentation/video4linux/videobuf I've read that videobuf does not currently play well with drivers that play tricks by allocating DMA space at system boot time, I've implemented the alternate sg path. If it's not quite true what the documentation says and you can give me a hint how this could be done, I might try again. For an example look at arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma(). Yes, this is the solution that suffers from the already discussed limitation of not being able to remap a memory with different attributes, which affects OMAP1 as well. For preallocating dma-coherent memory for device personal use during device probe() time (when the memory is less fragmented compared to open() time) see also dt3155_alloc_coherent/dt3155_free_coherent in drivers/staging/dt3155v4l/dt3155vfl.c (for x86 arch, I do not know if it works for arm arch) With this workaround applied, I get much better results, thank you Marin. However, it seems not bullet proof, since mmap still happens to fail for a reason not quite clear to me: This is just a preallocation of coherent memory kept for further private driver use, should not be connected to mmap problem. I'm not sure if it is related or not. This mmap problem exhibits ultimately when my driver is trying to allocate a piece of memory that has been preallocated that custom way. Maybe I should preallocate a few more pages than will be actually used by the driver? Anyways, I'm not sure if this piece of code could be accepted for inclusion into the mainline tree, perhaps only under drivers/staging. The idea for the piece of code I have proposed to you is taken from the functions dma_declare_coherent_memory()/dma_release_declared_memory() in mainline drivers/base/dma-coherent.c Then why not using the dma_declare_coherent_memory(), possibly after providing a patch that corrects a problem with it if there is one, instead of reimplementing it inside a driver? If I understood what a difference it could make if we put a dma_alloc_coherent() returned virtual address space pointer to the allocated region, instead of the ioremapped physical address base of this region, to the dev-dma_mem-virt_base, then maybe I could say something more on this. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): On Sun, 1 Aug 2010, Janusz Krzysztofik wrote: Friday 30 July 2010 20:49:05 Janusz Krzysztofik napisaÅ(a): I think the right way would be if implemented at the videobuf-core level. Then, drivers should be able to initialize both paths, providing queue callbacks for both sets of methods, contig and sg, for videobuf sole use. Ok, here're my thoughts about this: 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. I already tried before to find out how I could allocate memory at init without reinventing a new videobuf-dma-contig implementation. Since in the Documentation/video4linux/videobuf I've read that videobuf does not currently play well with drivers that play tricks by allocating DMA space at system boot time, I've implemented the alternate sg path. If it's not quite true what the documentation says and you can give me a hint how this could be done, I might try again. But given problems with this aproach in the current ARM tree [1], this might be a bit difficult. Still, those problems have to be and will be fixed somehow eventually, so, you might prefer to still just go that route. My board uses two drivers that allocate dma memory at boot time: drivers/video/omap/lcdc.c and sounc/soc/omap/omap-pcm.c. Both use alloc_dma_writecombine() for this and work without problems. 2. If you do want to do the switching - we also discussed, how forthcoming changes to the videobuf subsystem will affest this work. I do not think it would be possible to implement this switching in the videobuf core. OK, I should have probably said that it looked not possible for me to do it without any additional support implemented at videobuf-core (or soc_camera) level. Remember, with the videobuf API you first call the respective implementation init method, which doesn't fail. Then, in REQBUFS ioctl you call videobuf_reqbufs(), which might already fail but normally doesn't. The biggest problem is the mmap call with the contig videobuf implementation. This one is likely to fail. So, you would have to catch the failing mmap, call videobuf_mmap_free(), then init the SG videobuf, request buffers and mmap them... That's what I've already discovered, but failed to identify a place in my code where I could intercept this failing mmap without replacing parts of the videobuf code. With my 2 patches from today, there is only one process (file descriptor, to be precise), that manages the videobuf queue. So, this all can only be implemented in your driver. The only way I'm yet able to invent is replacing the videobuf_queue-int_ops-mmap_mapper() callback with my own wrapper that would intercept a failing videobuf-dma-contig version of mmap_mapper(). This could be done in my soc_camera_host-ops-init_videobuf() after the videobuf-dma-contig.c version of the videobuf_queue-int_ops-mmap_mapper() is installed with the videobuf_queue_dma_contig_init(). Is this method close to what you have on mind? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
Friday 13 August 2010 11:11:52 Marin Mitov napisał(a): On Friday, August 13, 2010 11:52:41 am Guennadi Liakhovetski wrote: On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. I already tried before to find out how I could allocate memory at init without reinventing a new videobuf-dma-contig implementation. Since in the Documentation/video4linux/videobuf I've read that videobuf does not currently play well with drivers that play tricks by allocating DMA space at system boot time, I've implemented the alternate sg path. If it's not quite true what the documentation says and you can give me a hint how this could be done, I might try again. For an example look at arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma(). Yes, this is the solution that suffers from the already discussed limitation of not being able to remap a memory with different attributes, which affects OMAP1 as well. For preallocating dma-coherent memory for device personal use during device probe() time (when the memory is less fragmented compared to open() time) see also dt3155_alloc_coherent/dt3155_free_coherent in drivers/staging/dt3155v4l/dt3155vfl.c (for x86 arch, I do not know if it works for arm arch) With this workaround applied, I get much better results, thank you Marin. However, it seems not bullet proof, since mmap still happens to fail for a reason not quite clear to me: [ 6067.22] omap1-camera omap1-camera.0: OMAP1 Camera driver attached to camera 0 [ 6067.65] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315659 not found [ 6067.68] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315559 not found [ 6068.48] mplayer: page allocation failure. order:6, mode:0xd0 [ 6068.50] Backtrace: [ 6068.52] [c0028950] (dump_backtrace+0x0/0x110) from [c0028ea8] (dump_stack+0x18/0x1c) [ 6068.56] r6:0006 r5:00d0 r4:c1bcf000 [ 6068.59] [c0028e90] (dump_stack+0x0/0x1c) from [c0074e24] (__alloc_pages_nodemask+0x504/0x560) [ 6068.62] [c0074920] (__alloc_pages_nodemask+0x0/0x560) from [c002ae14] (__dma_alloc+0x108/0x354) [ 6068.66] [c002ad0c] (__dma_alloc+0x0/0x354) from [c002b0ec] (dma_alloc_coherent+0x58/0x64) [ 6068.70] [c002b094] (dma_alloc_coherent+0x0/0x64) from [bf000a44] (__videobuf_mmap_mapper+0x10c/0x374 [videobuf_dma_contig]) [ 6068.74] r7:c16934c0 r6: r5:c171baec r4: [ 6068.77] [bf000938] (__videobuf_mmap_mapper+0x0/0x374 [videobuf_dma_contig]) from [c01f9a78] (videobuf_mmap_mapper+0xc4/0x108) [ 6068.81] [c01f99b4] (videobuf_mmap_mapper+0x0/0x108) from [c01fc1ac] (soc_camera_mmap+0x80/0x140) [ 6068.84] r5:c1a3b4e0 r4: [ 6068.87] [c01fc12c] (soc_camera_mmap+0x0/0x140) from [c01eeba8] (v4l2_mmap+0x4c/0x5c) [ 6068.90] r7:c145c000 r6:00ff r5:c16934c0 r4: [ 6068.93] [c01eeb5c] (v4l2_mmap+0x0/0x5c) from [c0085de4] (mmap_region+0x238/0x458) [ 6068.97] [c0085bac] (mmap_region+0x0/0x458) from [c00862c0] (do_mmap_pgoff+0x2bc/0x320) [ 6069.00] [c0086004] (do_mmap_pgoff+0x0/0x320) from [c00863c0] (sys_mmap_pgoff+0x9c/0xc8) [ 6069.04] [c0086324] (sys_mmap_pgoff+0x0/0xc8) from [c0024f00] (ret_fast_syscall+0x0/0x2c) [ 6069.20] Mem-info: [ 6069.22] Normal per-cpu: [ 6069.24] CPU0: hi:0, btch: 1 usd: 0 [ 6069.26] active_anon:676 inactive_anon:682 isolated_anon:0 [ 6069.26] active_file:422 inactive_file:2348 isolated_file:0 [ 6069.26] unevictable:177 dirty:0 writeback:0 unstable:0 [ 6069.26] free:1166 slab_reclaimable:0 slab_unreclaimable:0 [ 6069.26] mapped:1120 shmem:0 pagetables:121 bounce:0 [ 6069.35] Normal free:4664kB min:720kB low:900kB high:1080kB active_anon:2704kB inactive_anon:2728kB active_file:1688kB inactive_file:9392kB unevictable:708kB isolated(anon):0kB isolated(file):0kB present:32512kB mlocked:0kB dirty:0kB writeback:0kB mapped:4480kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:552kB pagetables:484kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 6069.46] lowmem_reserve[]: 0 0 [ 6069.47] Normal: 6*4kB 20*8kB 14*16kB 29*32kB 26*64kB 9*128kB 2*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4664kB [ 6069.53] 2960 total pagecache pages [ 6069.55] 8192 pages of RAM [ 6069.56] 1322 free pages [ 6069.58] 1114 reserved pages [ 6069.59] 750 slab pages [ 6069.61] 2476 pages shared [ 6069.63] 0 pages swap cached [ 6069.64] omap1-camera omap1-camera.0: dma_alloc_coherent size 204800 failed [ 6069.68] omap1-camera omap1-camera.0: OMAP1
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
Friday 30 July 2010 20:49:05 Janusz Krzysztofik napisał(a): Friday 30 July 2010 13:07:42 Guennadi Liakhovetski napisał(a): On Sun, 18 Jul 2010, Janusz Krzysztofik wrote: This is a V4L2 driver for TI OMAP1 SoC camera interface. Two versions of the driver are provided, using either videobuf-dma-contig or videobuf-dma-sg. The former uses less processing power, but often fails to allocate contignuous buffer memory. The latter is free of this problem, but generates tens of DMA interrupts per frame. Hm, would it be difficult to first try contig, and if it fails - fall back to sg? Hmm, let me think about it. Hi Gennadi, For me, your idea of frist trying contig and then falling back to sg if it fails, sounds great. However, I'm not sure if implementing it at a specific hardware driver level is a good solution. Nor soc_camera framework seems the right place for it either. I think the right way would be if implemented at the videobuf-core level. Then, drivers should be able to initialize both paths, providing queue callbacks for both sets of methods, contig and sg, for videobuf sole use. I'm not sure if I have enough skills to implement this idea. However, if there is a consensus on its general usfullness as a videobuf extension, I can have a look at it in my spare time. For now, I'd propose limiting my changes for v2 to splitting both methods into separate sections, not interleaved with #ifdefs like they are now, as you've already suggested. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
Friday 30 July 2010 13:07:42 Guennadi Liakhovetski napisał(a):
Hi Janusz
Thanks once more for the patches, from your patches it is obvious, that
you've spent quite a bit of time on them and you have not just copy-pasted
various bits and pieces from other drivers, just filling your hardware
details, but you also actually understand a lot of what is actually going
on in there. So, I think, fixing remaining mostly minor issues shouldn't
be too difficult for you either.
Hi Guennadi,
Thanks for your review time.
I only tried to get the driver really working, not only looking good ;).
On Sun, 18 Jul 2010, Janusz Krzysztofik wrote:
This is a V4L2 driver for TI OMAP1 SoC camera interface.
Two versions of the driver are provided, using either videobuf-dma-contig
or videobuf-dma-sg. The former uses less processing power, but often
fails to allocate contignuous buffer memory. The latter is free of this
problem, but generates tens of DMA interrupts per frame.
Hm, would it be difficult to first try contig, and if it fails - fall back
to sg?
Hmm, let me think about it.
In its present state buffer management in your driver is pretty difficult
to follow. At the VERY least you have to extensively document your buffer
manipulations. Better yet clean it up. AFAIU, your ready pointer is
pretty much unused in the contiguous case. Or you can easily get rid of
it.
I was sure the ready pointer was essential for both paths. However, things
tend to change as more and more optimizations / cleanups are applied, so I
have to verify it again.
So, I think, a very welcome improvement to the driver would be a
cleaner separation between the two cases. Don't try that much to reuse the
code as much as possible. Would be much better to have clean separation
between the two implementations - whether dynamically switchable at
runtime or at config time - would be best to separate the two
implementations to the point, where each of them becomes understandable
and maintainable.
You are right. My approach was probably more adequate at development time,
when I was trying to aviod error-prone code duplication. As soon as both
paths get stable, they can be split for better readability. I'll take care of
this.
So, I will do a pretty formal review this time and wait for v2. And in v2
I'd like to at the very least see detailed buffer-management
documentation, or - better yet - a rework with a clean separation.
OK.
...
--- linux-2.6.35-rc3.orig/include/media/omap1_camera.h 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.35-rc3/include/media/omap1_camera.h 2010-07-18
01:31:57.0 +0200
@@ -0,0 +1,16 @@
A copyright / licence header here, please
OK.
+#ifndef __MEDIA_OMAP1_CAMERA_H_
+#define __MEDIA_OMAP1_CAMERA_H_
+
+#define OMAP1_CAMERA_IOSIZE0x1c
+
+struct omap1_cam_platform_data {
+ unsigned long camexclk_khz;
+ unsigned long lclk_khz_max;
+ unsigned long flags;
+};
+
+#define OMAP1_CAMERA_LCLK_RISING BIT(0)
+#define OMAP1_CAMERA_RST_LOW BIT(1)
+#define OMAP1_CAMERA_RST_HIGH BIT(2)
Then you need to #include linux/bitops.h
OK.
Since I always tend to optimise out redundant includes of header files that
are otherwise included indirectly, please verify if there are more of them
that you would prefere included explicitly.
+
+#endif /* __MEDIA_OMAP1_CAMERA_H_ */
--- linux-2.6.35-rc3.orig/drivers/media/video/Kconfig 2010-06-26
15:55:29.0 +0200 +++
linux-2.6.35-rc3/drivers/media/video/Kconfig2010-07-02
04:12:02.0 +0200 @@ -962,6 +962,20 @@ config VIDEO_SH_MOBILE_CEU
---help---
This is a v4l2 driver for the SuperH Mobile CEU Interface
+config VIDEO_OMAP1
+ tristate OMAP1 Camera Interface driver
+ depends on VIDEO_DEV ARCH_OMAP1 SOC_CAMERA
+ select VIDEOBUF_DMA_CONTIG if !VIDEO_OMAP1_SG
+ ---help---
+ This is a v4l2 driver for the TI OMAP1 camera interface
+
+if VIDEO_OMAP1
Don't think you need this if, the depends on below should suffice.
OK.
My intention was to get it indented, and now I see it works like this even if
not enclosed with if-endif.
Will drop the if-endif if the compile time SG option survives.
+config VIDEO_OMAP1_SG
+ bool Scatter-gather mode
+ depends on VIDEO_OMAP1 EXPERIMENTAL
+ select VIDEOBUF_DMA_SG
+endif
+
...
+#ifndef CONFIG_VIDEO_OMAP1_SG
+#include media/videobuf-dma-contig.h
+#else
+#include media/videobuf-dma-sg.h
+#endif
I think, you can just include both headers.
OK.
...
+#define CAM_EXCLK_6MHz 600
+#define CAM_EXCLK_8MHz 800
+#define CAM_EXCLK_9_6MHz960
+#define CAM_EXCLK_12MHz1200
+#define CAM_EXCLK_24MHz2400
Why do you need this? Your platform specifies the EXCLK frequency directly
in kHz, then you multiplly it by 1000 to get pcdev-camexclk in Hz
Re: [RFC] [PATCH 0/6] Add camera support to the OMAP1 Amstrad Delta videophone
Tuesday 20 July 2010 11:49:54 Guennadi Liakhovetski wrote: Hi Janusz Hi Guennadi, Thanks for your answer. On Sun, 18 Jul 2010, Janusz Krzysztofik wrote: This series consists of the following patches: 1/6 SoC Camera: add driver for OMAP1 camera interface 2/6 OMAP1: Add support for SoC camera interface 3/6 SoC Camera: add driver for OV6650 sensor 4/6 SoC Camera: add support for g_parm / s_parm operations 5/6 OMAP1: Amstrad Delta: add support for on-board camera 6/6 OMAP1: Amstrad Delta: add camera controlled LEDS trigger It is an interesting decision to use soc-camera for an OMAP SoC, as you most probably know OMAP3 and OMAP2 camera drivers do not use soc-camera. I certainly do not want to discourage you from using soc-camera, just don't want you to go the wrong way and then regret it or spend time re-designing your driver. If this way occures wrong, then it's only my fault, since I've taken it myself, without consulting it neither on omap nor media list, so I'm not going to blame anyone except myself. Have you had specific reasons for this design? It looked like the most simple way for me. And while implementing it, I haven't faced any restrictions that would lead me to changing my mind and doing it another way. Is OMAP1 so different from 2 (and 3)? I think so, but let's see what OMAP guys have to say. In any case - thanks for the patches, if you do insist on going this path (;)) I'll review them and get back to you after that. Beware, it might be difficult to finish the review process in time for 2.6.36... Since not all patches from the series are OMAP related, and those that are not, don't depend on others, I think you could have a look at 4/6 and see if it makes sense or not. You could also examine 6/6 and see if you would like the idea of a camera LED trigger implemented, this way or another, at the soc_camera framework level rather than specific machine or platform. Last, the sensor driver (3/6), even if soc_camera specific, could be considered, if accepted, for adopting it as a regular v4l2-subdev, if required by a different implementation of OMAP part choosen. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH 0/6] Add camera support to the OMAP1 Amstrad Delta videophone
This series consists of the following patches: 1/6 SoC Camera: add driver for OMAP1 camera interface 2/6 OMAP1: Add support for SoC camera interface 3/6 SoC Camera: add driver for OV6650 sensor 4/6 SoC Camera: add support for g_parm / s_parm operations 5/6 OMAP1: Amstrad Delta: add support for on-board camera 6/6 OMAP1: Amstrad Delta: add camera controlled LEDS trigger arch/arm/mach-omap1/board-ams-delta.c | 69 + arch/arm/mach-omap1/devices.c | 43 arch/arm/mach-omap1/include/mach/camera.h |8 drivers/media/video/Kconfig | 20 drivers/media/video/Makefile |2 drivers/media/video/omap1_camera.c| 1656 ++ drivers/media/video/ov6650.c | 1336 drivers/media/video/soc_camera.c | 18 include/media/omap1_camera.h | 16 include/media/v4l2-chip-ident.h |1 10 files changed, 3169 insertions(+) Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
This is a V4L2 driver for TI OMAP1 SoC camera interface.
Two versions of the driver are provided, using either videobuf-dma-contig or
videobuf-dma-sg. The former uses less processing power, but often fails to
allocate contignuous buffer memory. The latter is free of this problem, but
generates tens of DMA interrupts per frame. Both versions work stable for me,
even under heavy load, on my OMAP1510 based Amstrad Delta videophone, that is
the oldest, least powerfull OMAP1 implementation.
The interface generally works in pass-through mode. Since input data byte
endianess can be swapped, it provides up to two v4l2 pixel formats per each of
several soc_mbus formats that have their swapped endian counterparts.
Boards using this driver can provide it with the followning information:
- if and what freqency clock is expected by an on-board camera sensor,
- what is the maximum pixel clock that should be accepted from the sensor,
- what is the polarity of the sensor provided pixel clock,
- if the interface GPIO line is connected to a sensor reset/powerdown input
and what is the input polarity.
Created and tested against linux-2.6.35-rc3 on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/media/video/Kconfig| 14
drivers/media/video/Makefile |1
drivers/media/video/omap1_camera.c | 1656 +
include/media/omap1_camera.h | 16
4 files changed, 1687 insertions(+)
--- linux-2.6.35-rc3.orig/include/media/omap1_camera.h 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.35-rc3/include/media/omap1_camera.h 2010-07-18
01:31:57.0 +0200
@@ -0,0 +1,16 @@
+#ifndef __MEDIA_OMAP1_CAMERA_H_
+#define __MEDIA_OMAP1_CAMERA_H_
+
+#define OMAP1_CAMERA_IOSIZE0x1c
+
+struct omap1_cam_platform_data {
+ unsigned long camexclk_khz;
+ unsigned long lclk_khz_max;
+ unsigned long flags;
+};
+
+#define OMAP1_CAMERA_LCLK_RISING BIT(0)
+#define OMAP1_CAMERA_RST_LOW BIT(1)
+#define OMAP1_CAMERA_RST_HIGH BIT(2)
+
+#endif /* __MEDIA_OMAP1_CAMERA_H_ */
--- linux-2.6.35-rc3.orig/drivers/media/video/Kconfig 2010-06-26
15:55:29.0 +0200
+++ linux-2.6.35-rc3/drivers/media/video/Kconfig2010-07-02
04:12:02.0 +0200
@@ -962,6 +962,20 @@ config VIDEO_SH_MOBILE_CEU
---help---
This is a v4l2 driver for the SuperH Mobile CEU Interface
+config VIDEO_OMAP1
+ tristate OMAP1 Camera Interface driver
+ depends on VIDEO_DEV ARCH_OMAP1 SOC_CAMERA
+ select VIDEOBUF_DMA_CONTIG if !VIDEO_OMAP1_SG
+ ---help---
+ This is a v4l2 driver for the TI OMAP1 camera interface
+
+if VIDEO_OMAP1
+config VIDEO_OMAP1_SG
+ bool Scatter-gather mode
+ depends on VIDEO_OMAP1 EXPERIMENTAL
+ select VIDEOBUF_DMA_SG
+endif
+
config VIDEO_OMAP2
tristate OMAP2 Camera Capture Interface driver
depends on VIDEO_DEV ARCH_OMAP2
--- linux-2.6.35-rc3.orig/drivers/media/video/Makefile 2010-06-26
15:55:29.0 +0200
+++ linux-2.6.35-rc3/drivers/media/video/Makefile 2010-06-26
17:28:09.0 +0200
@@ -165,6 +165,7 @@ obj-$(CONFIG_VIDEO_MX1) += mx1_camera.
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
+obj-$(CONFIG_VIDEO_OMAP1) += omap1_camera.o
obj-$(CONFIG_ARCH_DAVINCI) += davinci/
--- linux-2.6.35-rc3.orig/drivers/media/video/omap1_camera.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.35-rc3/drivers/media/video/omap1_camera.c 2010-07-18
01:32:48.0 +0200
@@ -0,0 +1,1656 @@
+/*
+ * V4L2 SoC Camera driver for OMAP1 Camera Interface
+ *
+ * Copyright (C) 2010, Janusz Krzysztofik jkrzy...@tis.icnet.pl
+ *
+ * Based on V4L2 Driver for i.MXL/i.MXL camera (CSI) host
+ * Copyright (C) 2008, Paulius Zaleckas paulius.zalec...@teltonika.lt
+ * Copyright (C) 2009, Darius Augulis augulis.dar...@gmail.com
+ *
+ * Based on PXA SoC camera driver
+ * Copyright (C) 2006, Sascha Hauer, Pengutronix
+ * Copyright (C) 2008, Guennadi Liakhovetski ker...@pengutronix.de
+ *
+ * Hardware specific bits initialy based on former work by Matt Callow
+ * drivers/media/video/omap/omap1510cam.c
+ * Copyright (C) 2006 Matt Callow
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+
+#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/version.h
+
+#include media/omap1_camera.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#ifndef CONFIG_VIDEO_OMAP1_SG
+#include media/videobuf-dma-contig.h
+#else
+#include media/videobuf-dma-sg.h
+#endif
+
+#include plat/dma.h
