[PATCH v2 1/5] media: atmel-isi: correct yuv swap according to different sensor outputs
we need to configure the YCC_SWAP bits in ISI_CFG2 according to current
sensor output and Atmel ISI output format.
Current there are two cases Atmel ISI supported:
1. Atmel ISI outputs YUYV format.
This case we need to setup YCC_SWAP according to sensor output
format.
2. Atmel ISI output a pass-through formats, which means no swap.
Just setup YCC_SWAP as default with no swap.
Signed-off-by: Josh Wu
---
Changes in v2:
- remove the duplicated variable: cfg2_yuv_swap.
drivers/media/platform/soc_camera/atmel-isi.c | 39 ---
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 45e304a..ce87a16 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -103,13 +103,37 @@ static u32 isi_readl(struct atmel_isi *isi, u32 reg)
return readl(isi->regs + reg);
}
+static u32 setup_cfg2_yuv_swap(struct atmel_isi *isi,
+ const struct soc_camera_format_xlate *xlate)
+{
+ if (xlate->host_fmt->fourcc == V4L2_PIX_FMT_YUYV) {
+ /* all convert to YUYV */
+ switch (xlate->code) {
+ case MEDIA_BUS_FMT_VYUY8_2X8:
+ return ISI_CFG2_YCC_SWAP_MODE_3;
+ case MEDIA_BUS_FMT_UYVY8_2X8:
+ return ISI_CFG2_YCC_SWAP_MODE_2;
+ case MEDIA_BUS_FMT_YVYU8_2X8:
+ return ISI_CFG2_YCC_SWAP_MODE_1;
+ }
+ }
+
+ /*
+* By default, no swap for the codec path of Atmel ISI. So codec
+* output is same as sensor's output.
+* For instance, if sensor's output is YUYV, then codec outputs YUYV.
+* And if sensor's output is UYVY, then codec outputs UYVY.
+*/
+ return ISI_CFG2_YCC_SWAP_DEFAULT;
+}
+
static void configure_geometry(struct atmel_isi *isi, u32 width,
- u32 height, u32 code)
+ u32 height, const struct soc_camera_format_xlate *xlate)
{
u32 cfg2;
/* According to sensor's output format to set cfg2 */
- switch (code) {
+ switch (xlate->code) {
default:
/* Grey */
case MEDIA_BUS_FMT_Y8_1X8:
@@ -117,16 +141,11 @@ static void configure_geometry(struct atmel_isi *isi, u32
width,
break;
/* YUV */
case MEDIA_BUS_FMT_VYUY8_2X8:
- cfg2 = ISI_CFG2_YCC_SWAP_MODE_3 | ISI_CFG2_COL_SPACE_YCbCr;
- break;
case MEDIA_BUS_FMT_UYVY8_2X8:
- cfg2 = ISI_CFG2_YCC_SWAP_MODE_2 | ISI_CFG2_COL_SPACE_YCbCr;
- break;
case MEDIA_BUS_FMT_YVYU8_2X8:
- cfg2 = ISI_CFG2_YCC_SWAP_MODE_1 | ISI_CFG2_COL_SPACE_YCbCr;
- break;
case MEDIA_BUS_FMT_YUYV8_2X8:
- cfg2 = ISI_CFG2_YCC_SWAP_DEFAULT | ISI_CFG2_COL_SPACE_YCbCr;
+ cfg2 = ISI_CFG2_COL_SPACE_YCbCr |
+ setup_cfg2_yuv_swap(isi, xlate);
break;
/* RGB, TODO */
}
@@ -407,7 +426,7 @@ static int start_streaming(struct vb2_queue *vq, unsigned
int count)
isi_writel(isi, ISI_INTDIS, (u32)~0UL);
configure_geometry(isi, icd->user_width, icd->user_height,
- icd->current_fmt->code);
+ icd->current_fmt);
spin_lock_irq(&isi->lock);
/* Clear any pending interrupt */
--
1.9.1
--
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 2/5] media: atmel-isi: prepare for the support of preview path
Atmel ISI support a preview path which can output RGB data.
So this patch introduces a bool variable to choose which path is
enabled currently. And also we need setup corresponding path registers.
By default the preview path is disabled. We only use Codec path.
Signed-off-by: Josh Wu
---
Changes in v2: None
drivers/media/platform/soc_camera/atmel-isi.c | 72 ++-
1 file changed, 49 insertions(+), 23 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index ce87a16..24501a4 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -79,6 +79,7 @@ struct atmel_isi {
dma_addr_t fb_descriptors_phys;
struct list_head dma_desc_head;
struct isi_dma_desc dma_desc[MAX_BUFFER_NUM];
+ boolenable_preview_path;
struct completion complete;
/* ISI peripherial clock */
@@ -195,11 +196,19 @@ static irqreturn_t atmel_isi_handle_streaming(struct
atmel_isi *isi)
/* start next dma frame. */
isi->active = list_entry(isi->video_buffer_list.next,
struct frame_buffer, list);
- isi_writel(isi, ISI_DMA_C_DSCR,
- (u32)isi->active->p_dma_desc->fbd_phys);
- isi_writel(isi, ISI_DMA_C_CTRL,
- ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
- isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_C_CH);
+ if (!isi->enable_preview_path) {
+ isi_writel(isi, ISI_DMA_C_DSCR,
+ (u32)isi->active->p_dma_desc->fbd_phys);
+ isi_writel(isi, ISI_DMA_C_CTRL,
+ ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
+ isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_C_CH);
+ } else {
+ isi_writel(isi, ISI_DMA_P_DSCR,
+ (u32)isi->active->p_dma_desc->fbd_phys);
+ isi_writel(isi, ISI_DMA_P_CTRL,
+ ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
+ isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_P_CH);
+ }
}
return IRQ_HANDLED;
}
@@ -226,7 +235,8 @@ static irqreturn_t isi_interrupt(int irq, void *dev_id)
isi_writel(isi, ISI_INTDIS, ISI_CTRL_DIS);
ret = IRQ_HANDLED;
} else {
- if (likely(pending & ISI_SR_CXFR_DONE))
+ if (likely(pending & ISI_SR_CXFR_DONE) ||
+ likely(pending & ISI_SR_PXFR_DONE))
ret = atmel_isi_handle_streaming(isi);
}
@@ -368,21 +378,35 @@ static void start_dma(struct atmel_isi *isi, struct
frame_buffer *buffer)
ISI_SR_CXFR_DONE | ISI_SR_PXFR_DONE);
/* Check if already in a frame */
- if (isi_readl(isi, ISI_STATUS) & ISI_CTRL_CDC) {
- dev_err(isi->soc_host.icd->parent, "Already in frame
handling.\n");
- return;
- }
+ if (!isi->enable_preview_path) {
+ if (isi_readl(isi, ISI_STATUS) & ISI_CTRL_CDC) {
+ dev_err(isi->soc_host.icd->parent, "Already in frame
handling.\n");
+ return;
+ }
- isi_writel(isi, ISI_DMA_C_DSCR, (u32)buffer->p_dma_desc->fbd_phys);
- isi_writel(isi, ISI_DMA_C_CTRL, ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
- isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_C_CH);
+ isi_writel(isi, ISI_DMA_C_DSCR,
+ (u32)buffer->p_dma_desc->fbd_phys);
+ isi_writel(isi, ISI_DMA_C_CTRL,
+ ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
+ isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_C_CH);
+ } else {
+ isi_writel(isi, ISI_DMA_P_DSCR,
+ (u32)buffer->p_dma_desc->fbd_phys);
+ isi_writel(isi, ISI_DMA_P_CTRL,
+ ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
+ isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_P_CH);
+ }
cfg1 &= ~ISI_CFG1_FRATE_DIV_MASK;
/* Enable linked list */
cfg1 |= isi->pdata.frate | ISI_CFG1_DISCR;
- /* Enable codec path and ISI */
- ctrl = ISI_CTRL_CDC | ISI_CTRL_EN;
+ /* Enable ISI */
+ ctrl = ISI_CTRL_EN;
+
+ if (!isi->enable_preview_path)
+ ctrl |= ISI_CTRL_CDC;
+
isi_writel(isi, ISI_CTRL, ctrl);
isi_writel(isi, ISI_CFG1, cfg1);
}
@@ -458,15 +482,17 @@ static void stop_streaming(struct vb2_queue *vq)
}
spin_unlock_irq(&isi->lock);
- timeout = jiffies + FRAME_INTERVAL_MILLI_SEC * HZ;
- /* Wait until the end of the
[PATCH v2 0/5] media: atmel-isi: enable preview path to output RGB565 format
This series will enable preview path support in atmel-isi. Which can make atmel-isi convert the YUV format (from sensor) to RGB565 format. Changes in v2: - remove the duplicated variable: cfg2_yuv_swap. - correct the comment style - According to Guennadi's suggestion, remove the is_output_rgb() function which only used once. Also move the code into the for loop. Josh Wu (5): media: atmel-isi: correct yuv swap according to different sensor outputs media: atmel-isi: prepare for the support of preview path media: atmel-isi: add code to setup correct resolution for preview path media: atmel-isi: setup YCC_SWAP correctly when using preview path media: atmel-isi: support RGB565 output when sensor output YUV formats drivers/media/platform/soc_camera/atmel-isi.c | 162 +++--- drivers/media/platform/soc_camera/atmel-isi.h | 10 ++ 2 files changed, 132 insertions(+), 40 deletions(-) -- 1.9.1 -- 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 4/5] media: atmel-isi: setup YCC_SWAP correctly when using preview path
The preview path only can convert UYVY format to RGB data.
To make preview path work correctly, we need to set up YCC_SWAP
according to sensor output and convert them to UYVY.
Signed-off-by: Josh Wu
---
Changes in v2:
- remove cfg2_yuv_swap for rgb format
- correct the comment style
drivers/media/platform/soc_camera/atmel-isi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index ae82068..826d04e 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -117,6 +117,20 @@ static u32 setup_cfg2_yuv_swap(struct atmel_isi *isi,
case MEDIA_BUS_FMT_YVYU8_2X8:
return ISI_CFG2_YCC_SWAP_MODE_1;
}
+ } else if (xlate->host_fmt->fourcc == V4L2_PIX_FMT_RGB565) {
+ /*
+* Preview path is enabled, it will convert UYVY to RGB format.
+* But if sensor output format is not UYVY, we need to set
+* YCC_SWAP_MODE to convert it as UYVY.
+*/
+ switch (xlate->code) {
+ case MEDIA_BUS_FMT_VYUY8_2X8:
+ return ISI_CFG2_YCC_SWAP_MODE_1;
+ case MEDIA_BUS_FMT_YUYV8_2X8:
+ return ISI_CFG2_YCC_SWAP_MODE_2;
+ case MEDIA_BUS_FMT_YVYU8_2X8:
+ return ISI_CFG2_YCC_SWAP_MODE_3;
+ }
}
/*
--
1.9.1
--
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 3/5] media: atmel-isi: add code to setup correct resolution for preview path
Not like codec path, preview path can do downsampling, so we should setup
a extra preview width, height for it.
This patch add preview resolution setup without down sampling. So currently
preview path will output same size as sensor output size.
Signed-off-by: Josh Wu
---
Changes in v2: None
drivers/media/platform/soc_camera/atmel-isi.c | 12 +++-
drivers/media/platform/soc_camera/atmel-isi.h | 10 ++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 24501a4..ae82068 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -131,7 +131,7 @@ static u32 setup_cfg2_yuv_swap(struct atmel_isi *isi,
static void configure_geometry(struct atmel_isi *isi, u32 width,
u32 height, const struct soc_camera_format_xlate *xlate)
{
- u32 cfg2;
+ u32 cfg2, psize;
/* According to sensor's output format to set cfg2 */
switch (xlate->code) {
@@ -159,6 +159,16 @@ static void configure_geometry(struct atmel_isi *isi, u32
width,
cfg2 |= ((height - 1) << ISI_CFG2_IM_VSIZE_OFFSET)
& ISI_CFG2_IM_VSIZE_MASK;
isi_writel(isi, ISI_CFG2, cfg2);
+
+ /* No down sampling, preview size equal to sensor output size */
+ psize = ((width - 1) << ISI_PSIZE_PREV_HSIZE_OFFSET) &
+ ISI_PSIZE_PREV_HSIZE_MASK;
+ psize |= ((height - 1) << ISI_PSIZE_PREV_VSIZE_OFFSET) &
+ ISI_PSIZE_PREV_VSIZE_MASK;
+ isi_writel(isi, ISI_PSIZE, psize);
+ isi_writel(isi, ISI_PDECF, ISI_PDECF_NO_SAMPLING);
+
+ return;
}
static bool is_supported(struct soc_camera_device *icd,
diff --git a/drivers/media/platform/soc_camera/atmel-isi.h
b/drivers/media/platform/soc_camera/atmel-isi.h
index 5acc771..0acb32a 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.h
+++ b/drivers/media/platform/soc_camera/atmel-isi.h
@@ -79,6 +79,16 @@
#define ISI_CFG2_IM_VSIZE_MASK (0x7FF << ISI_CFG2_IM_VSIZE_OFFSET)
#define ISI_CFG2_IM_HSIZE_MASK (0x7FF << ISI_CFG2_IM_HSIZE_OFFSET)
+/* Bitfields in PSIZE */
+#define ISI_PSIZE_PREV_VSIZE_OFFSET0
+#define ISI_PSIZE_PREV_HSIZE_OFFSET16
+#define ISI_PSIZE_PREV_VSIZE_MASK (0x3FF << ISI_PSIZE_PREV_VSIZE_OFFSET)
+#define ISI_PSIZE_PREV_HSIZE_MASK (0x3FF << ISI_PSIZE_PREV_HSIZE_OFFSET)
+
+/* Bitfields in PDECF */
+#define ISI_PDECF_DEC_FACTOR_MASK (0xFF << 0)
+#defineISI_PDECF_NO_SAMPLING (16)
+
/* Bitfields in CTRL */
/* Also using in SR(ISI_V2) */
#define ISI_CTRL_EN(1 << 0)
--
1.9.1
--
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/5] media: atmel-isi: support RGB565 output when sensor output YUV formats
This patch enable Atmel ISI preview path to convert the YUV to RGB format.
Signed-off-by: Josh Wu
---
Changes in v2:
- According to Guennadi's suggestion, remove the is_output_rgb() function
which only used once. Also move the code into the for loop.
drivers/media/platform/soc_camera/atmel-isi.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 826d04e..8abeeeb 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -146,6 +146,10 @@ static void configure_geometry(struct atmel_isi *isi, u32
width,
u32 height, const struct soc_camera_format_xlate *xlate)
{
u32 cfg2, psize;
+ u32 fourcc = xlate->host_fmt->fourcc;
+
+ isi->enable_preview_path = (fourcc == V4L2_PIX_FMT_RGB565 ||
+ fourcc == V4L2_PIX_FMT_RGB32);
/* According to sensor's output format to set cfg2 */
switch (xlate->code) {
@@ -195,8 +199,9 @@ static bool is_supported(struct soc_camera_device *icd,
case V4L2_PIX_FMT_UYVY:
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_VYUY:
+ /* RGB */
+ case V4L2_PIX_FMT_RGB565:
return true;
- /* RGB, TODO */
default:
return false;
}
@@ -682,6 +687,14 @@ static const struct soc_mbus_pixelfmt isi_camera_formats[]
= {
.order = SOC_MBUS_ORDER_LE,
.layout = SOC_MBUS_LAYOUT_PACKED,
},
+ {
+ .fourcc = V4L2_PIX_FMT_RGB565,
+ .name = "RGB565",
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ .layout = SOC_MBUS_LAYOUT_PACKED,
+ },
};
/* This will be corrected as we get more formats */
@@ -738,7 +751,7 @@ static int isi_camera_get_formats(struct soc_camera_device
*icd,
struct soc_camera_format_xlate *xlate)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- int formats = 0, ret;
+ int formats = 0, ret, i, n;
/* sensor format */
struct v4l2_subdev_mbus_code_enum code = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
@@ -772,11 +785,11 @@ static int isi_camera_get_formats(struct
soc_camera_device *icd,
case MEDIA_BUS_FMT_VYUY8_2X8:
case MEDIA_BUS_FMT_YUYV8_2X8:
case MEDIA_BUS_FMT_YVYU8_2X8:
- formats++;
- if (xlate) {
- xlate->host_fmt = &isi_camera_formats[0];
+ n = ARRAY_SIZE(isi_camera_formats);
+ formats += n;
+ for (i = 0; xlate && i < n; i++, xlate++) {
+ xlate->host_fmt = &isi_camera_formats[i];
xlate->code = code.code;
- xlate++;
dev_dbg(icd->parent, "Providing format %s using code
%d\n",
isi_camera_formats[0].name, code.code);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Nov 3 04:00:28 CET 2015 git branch: test git hash: 79f5b6ae960d380c829fb67d5dadcd1d025d2775 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-51-ga53cea2 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-i686: OK linux-4.3-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-x86_64: OK linux-4.3-x86_64: ERRORS apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: au0828: start_urb_transfer: failed big buffer allocation, err = -12
Ken, You could set the module parameter preallocate_big_buffers=1 when you insmod the au8028 kernel module. When this parameter is set, the driver will allocate the big buffers once when the module is loaded instead of every time the device is opened for streaming. Thanks, Tim On Fri, Oct 30, 2015 at 12:07 PM, Ken Harris wrote: > Greetings > > Dunno if this is the right place to post this. Let me know if there > is a better place. > > I'm recording with a "DViCO FusionHDTV USB" gadget. > > It records for an hour or so just fine, but when it starts up the > second time, it doesn't work and I get a lot of kernel messages that > seem to trace back to : > > au0828: start_urb_transfer: failed big buffer allocation, err = -12 > > This is a Fedora 22 system ( Linux 4.2.3-200.fc22.i686+PAE ) > > Attached is dmesg output. > > Any tips are appreciated. > > Thanks, > Ken -- 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 4/4] v4l2-mem2mem: allow reqbufs(0) with "in use" MMAP buffers
Le mardi 08 avril 2014 à 12:51 +0200, Marek Szyprowski a écrit : > Hello, > > On 2014-04-07 16:41, Kamil Debski wrote: > > Pawel, Marek, > > > > Before taking this to my tree I wanted to get an ACK from one of > > the > > videobuf2 maintainers. Could you spare a moment to look through > > this > > patch? > > It's not a bug, it is a feature. This was one of the fundamental > design > requirements to allow applications to track if the memory is used or > not. I still have the impression it is not fully correct for the case buffers are exported using DMABUF. Like if the dmabuf was owning the vb2 buffer instead of the opposite ... Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH v6 1/3] iommu: Implement common IOMMU ops for DMA mapping
On Mon, Nov 2, 2015 at 10:11 PM, Daniel Kurtz wrote:
>
> +Tomasz, so he can reply to the thread
> +Marek and Russell as recommended by Tomasz
>
> On Oct 30, 2015 22:27, "Robin Murphy" wrote:
> >
> > Hi Dan,
> >
> > On 30/10/15 01:17, Daniel Kurtz wrote:
> >>
> >> +linux-media & VIDEOBUF2 FRAMEWORK maintainers since this is about the
> >> v4l2-contig's usage of the DMA API.
> >>
> >> Hi Robin,
> >>
> >> On Tue, Oct 27, 2015 at 12:55 AM, Robin Murphy
> >> wrote:
> >>>
> >>> On 26/10/15 13:44, Yong Wu wrote:
>
>
> On Thu, 2015-10-01 at 20:13 +0100, Robin Murphy wrote:
> [...]
> >
> >
> > +/*
> > + * The DMA API client is passing in a scatterlist which could describe
> > + * any old buffer layout, but the IOMMU API requires everything to be
> > + * aligned to IOMMU pages. Hence the need for this complicated bit of
> > + * impedance-matching, to be able to hand off a suitably-aligned list,
> > + * but still preserve the original offsets and sizes for the caller.
> > + */
> > +int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg,
> > + int nents, int prot)
> > +{
> > + struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> > + struct iova_domain *iovad = domain->iova_cookie;
> > + struct iova *iova;
> > + struct scatterlist *s, *prev = NULL;
> > + dma_addr_t dma_addr;
> > + size_t iova_len = 0;
> > + int i;
> > +
> > + /*
> > +* Work out how much IOVA space we need, and align the segments
> > to
> > +* IOVA granules for the IOMMU driver to handle. With some
> > clever
> > +* trickery we can modify the list in-place, but reversibly, by
> > +* hiding the original data in the as-yet-unused DMA fields.
> > +*/
> > + for_each_sg(sg, s, nents, i) {
> > + size_t s_offset = iova_offset(iovad, s->offset);
> > + size_t s_length = s->length;
> > +
> > + sg_dma_address(s) = s->offset;
> > + sg_dma_len(s) = s_length;
> > + s->offset -= s_offset;
> > + s_length = iova_align(iovad, s_length + s_offset);
> > + s->length = s_length;
> > +
> > + /*
> > +* The simple way to avoid the rare case of a segment
> > +* crossing the boundary mask is to pad the previous one
> > +* to end at a naturally-aligned IOVA for this one's
> > size,
> > +* at the cost of potentially over-allocating a little.
I'd like to know what is the boundary mask and what hardware imposes
requirements like this. The cost here is not only over-allocating a
little, but making many, many buffers contiguously mappable on the
CPU, unmappable contiguously in IOMMU, which just defeats the purpose
of having an IOMMU, which I believe should be there for simple IP
blocks taking one DMA address to be able to view the buffer the same
way as the CPU.
> > +*/
> > + if (prev) {
> > + size_t pad_len = roundup_pow_of_two(s_length);
> > +
> > + pad_len = (pad_len - iova_len) & (pad_len - 1);
> > + prev->length += pad_len;
>
>
>
> Hi Robin,
> While our v4l2 testing, It seems that we met a problem here.
> Here we update prev->length again, Do we need update
> sg_dma_len(prev) again too?
>
> Some function like vb2_dc_get_contiguous_size[1] always get
> sg_dma_len(s) to compare instead of s->length. so it may break
> unexpectedly while sg_dma_len(s) is not same with s->length.
> >>>
> >>>
> >>>
> >>> This is just tweaking the faked-up length that we hand off to
> >>> iommu_map_sg()
> >>> (see also the iova_align() above), to trick it into bumping this segment
> >>> up
> >>> to a suitable starting IOVA. The real length at this point is stashed in
> >>> sg_dma_len(s), and will be copied back into s->length in __finalise_sg(),
> >>> so
> >>> both will hold the same true length once we return to the caller.
> >>>
> >>> Yes, it does mean that if you have a list where the segment lengths are
> >>> page
> >>> aligned but not monotonically decreasing, e.g. {64k, 16k, 64k}, then
> >>> you'll
> >>> still end up with a gap between the second and third segments, but that's
> >>> fine because the DMA API offers no guarantees about what the resulting DMA
> >>> addresses will be (consider the no-IOMMU case where they would each just
> >>> be
> >>> "mapped" to their physical address). If that breaks v4l, then it's
> >>> probably
> >>> v4l's DMA API use that needs looking at (again).
> >>
> >>
> >> Hmm, I thought the DMA API maps a (possibly) non-contiguous set of
> >> memory pages into a contiguous b
Re: [PATCH v6 1/3] iommu: Implement common IOMMU ops for DMA mapping
+Tomasz, so he can reply to the thread
+Marek and Russell as recommended by Tomasz
On Oct 30, 2015 22:27, "Robin Murphy" wrote:
>
> Hi Dan,
>
> On 30/10/15 01:17, Daniel Kurtz wrote:
>>
>> +linux-media & VIDEOBUF2 FRAMEWORK maintainers since this is about the
>> v4l2-contig's usage of the DMA API.
>>
>> Hi Robin,
>>
>> On Tue, Oct 27, 2015 at 12:55 AM, Robin Murphy wrote:
>>>
>>> On 26/10/15 13:44, Yong Wu wrote:
On Thu, 2015-10-01 at 20:13 +0100, Robin Murphy wrote:
[...]
>
>
> +/*
> + * The DMA API client is passing in a scatterlist which could describe
> + * any old buffer layout, but the IOMMU API requires everything to be
> + * aligned to IOMMU pages. Hence the need for this complicated bit of
> + * impedance-matching, to be able to hand off a suitably-aligned list,
> + * but still preserve the original offsets and sizes for the caller.
> + */
> +int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg,
> + int nents, int prot)
> +{
> + struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> + struct iova_domain *iovad = domain->iova_cookie;
> + struct iova *iova;
> + struct scatterlist *s, *prev = NULL;
> + dma_addr_t dma_addr;
> + size_t iova_len = 0;
> + int i;
> +
> + /*
> +* Work out how much IOVA space we need, and align the segments
> to
> +* IOVA granules for the IOMMU driver to handle. With some clever
> +* trickery we can modify the list in-place, but reversibly, by
> +* hiding the original data in the as-yet-unused DMA fields.
> +*/
> + for_each_sg(sg, s, nents, i) {
> + size_t s_offset = iova_offset(iovad, s->offset);
> + size_t s_length = s->length;
> +
> + sg_dma_address(s) = s->offset;
> + sg_dma_len(s) = s_length;
> + s->offset -= s_offset;
> + s_length = iova_align(iovad, s_length + s_offset);
> + s->length = s_length;
> +
> + /*
> +* The simple way to avoid the rare case of a segment
> +* crossing the boundary mask is to pad the previous one
> +* to end at a naturally-aligned IOVA for this one's
> size,
> +* at the cost of potentially over-allocating a little.
> +*/
> + if (prev) {
> + size_t pad_len = roundup_pow_of_two(s_length);
> +
> + pad_len = (pad_len - iova_len) & (pad_len - 1);
> + prev->length += pad_len;
Hi Robin,
While our v4l2 testing, It seems that we met a problem here.
Here we update prev->length again, Do we need update
sg_dma_len(prev) again too?
Some function like vb2_dc_get_contiguous_size[1] always get
sg_dma_len(s) to compare instead of s->length. so it may break
unexpectedly while sg_dma_len(s) is not same with s->length.
>>>
>>>
>>>
>>> This is just tweaking the faked-up length that we hand off to iommu_map_sg()
>>> (see also the iova_align() above), to trick it into bumping this segment up
>>> to a suitable starting IOVA. The real length at this point is stashed in
>>> sg_dma_len(s), and will be copied back into s->length in __finalise_sg(), so
>>> both will hold the same true length once we return to the caller.
>>>
>>> Yes, it does mean that if you have a list where the segment lengths are page
>>> aligned but not monotonically decreasing, e.g. {64k, 16k, 64k}, then you'll
>>> still end up with a gap between the second and third segments, but that's
>>> fine because the DMA API offers no guarantees about what the resulting DMA
>>> addresses will be (consider the no-IOMMU case where they would each just be
>>> "mapped" to their physical address). If that breaks v4l, then it's probably
>>> v4l's DMA API use that needs looking at (again).
>>
>>
>> Hmm, I thought the DMA API maps a (possibly) non-contiguous set of
>> memory pages into a contiguous block in device memory address space.
>> This would allow passing a dma mapped buffer to device dma using just
>> a device address and length.
>
>
> Not at all. The streaming DMA API (dma_map_* and friends) has two
> responsibilities: performing any necessary cache maintenance to ensure the
> device will correctly see data from the CPU, and the CPU will correctly see
> data from the device; and working out an address for that buffer from the
> device's point of view to actually hand off to the hardware (which is
> perfectly well allowed to fail).
>
> Consider SWIOTLB's implementation - segments which already lie at physical
> addresses within the device's DMA mask just get passed through, while those
> that lie outside it get mapped
Re: [RFC PATCH v8 1/6] media: videobuf2: Move timestamp to vb2_buffer
On 11/02/2015 05:43 AM, Junghak Sung wrote:
> Move timestamp from struct vb2_v4l2_buffer to struct vb2_buffer
> for common use, and change its type to struct timespec in order to handling
> y2038 problem. This patch also includes all device drivers' changes related to
> this restructuring.
>
> Signed-off-by: Junghak Sung
> Signed-off-by: Geunyoung Kim
> Acked-by: Seung-Woo Kim
> Acked-by: Inki Dae
> ---
> diff --git a/drivers/usb/gadget/function/uvc_queue.c
> b/drivers/usb/gadget/function/uvc_queue.c
> index 51d4a17..34525dc 100644
> --- a/drivers/usb/gadget/function/uvc_queue.c
> +++ b/drivers/usb/gadget/function/uvc_queue.c
> @@ -329,7 +329,7 @@ struct uvc_buffer *uvcg_queue_next_buffer(struct
> uvc_video_queue *queue,
>
> buf->buf.field = V4L2_FIELD_NONE;
> buf->buf.sequence = queue->sequence++;
> - v4l2_get_timestamp(&buf->buf.timestamp);
> + ktime_get_ts(&buf->buf.vb2_buf.timestamp);
>
> vb2_set_plane_payload(&buf->buf.vb2_buf, 0, buf->bytesused);
> vb2_buffer_done(&buf->buf.vb2_buf, VB2_BUF_STATE_DONE);
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index 647ebfe..3fe6600 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -211,6 +211,7 @@ struct vb2_queue;
> * @num_planes: number of planes in the buffer
> * on an internal driver queue
> * @planes: private per-plane information; do not change
> + * @timestamp: frame timestamp
> */
> struct vb2_buffer {
> struct vb2_queue*vb2_queue;
> @@ -219,6 +220,7 @@ struct vb2_buffer {
> unsigned intmemory;
> unsigned intnum_planes;
> struct vb2_planeplanes[VB2_MAX_PLANES];
> + struct timespec timestamp;
This should be a __u64 containing nanoseconds. That is the recommended way of
storing timestamps according to the y2038 team. The timespec struct is not
y2038 safe, whereas using __u64 is OK.
Please change!
And instead of using ktime_get_ts() in drivers use ktime_get_ns().
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
dog harness, dog leash, dog clothes and dog carrier
Hi, this is Jeff Wu from China. We are a factory which produces pet clothes, pet harness, pet leash. Please let me know if you are interested to buy from us, thanks! I will send the price lists and website to you then. Best regards, Jeff Wu -- 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
