[PATCH 4/5] video:omap3isp:fix up ENOIOCTLCMD error handling
At commit 07d106d0, Linus pointed out that ENOIOCTLCMD should be translated as ENOTTY to user mode. Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: linux-media@vger.kernel.org Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com --- drivers/media/video/omap3isp/ispvideo.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/media/video/omap3isp/ispvideo.c b/drivers/media/video/omap3isp/ispvideo.c index b37379d..2dd982e 100644 --- a/drivers/media/video/omap3isp/ispvideo.c +++ b/drivers/media/video/omap3isp/ispvideo.c @@ -337,7 +337,7 @@ __isp_video_get_format(struct isp_video *video, struct v4l2_format *format) fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE; ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, fmt); if (ret == -ENOIOCTLCMD) - ret = -EINVAL; + ret = -ENOTTY; mutex_unlock(video-mutex); @@ -723,7 +723,7 @@ isp_video_try_format(struct file *file, void *fh, struct v4l2_format *format) fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE; ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, fmt); if (ret) - return ret == -ENOIOCTLCMD ? -EINVAL : ret; + return ret == -ENOIOCTLCMD ? -ENOTTY : ret; isp_video_mbus_to_pix(video, fmt.format, format-fmt.pix); return 0; @@ -744,7 +744,7 @@ isp_video_cropcap(struct file *file, void *fh, struct v4l2_cropcap *cropcap) ret = v4l2_subdev_call(subdev, video, cropcap, cropcap); mutex_unlock(video-mutex); - return ret == -ENOIOCTLCMD ? -EINVAL : ret; + return ret == -ENOIOCTLCMD ? -ENOTTY : ret; } static int @@ -771,7 +771,7 @@ isp_video_get_crop(struct file *file, void *fh, struct v4l2_crop *crop) format.which = V4L2_SUBDEV_FORMAT_ACTIVE; ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, format); if (ret 0) - return ret == -ENOIOCTLCMD ? -EINVAL : ret; + return ret == -ENOIOCTLCMD ? -ENOTTY : ret; crop-c.left = 0; crop-c.top = 0; @@ -796,7 +796,7 @@ isp_video_set_crop(struct file *file, void *fh, struct v4l2_crop *crop) ret = v4l2_subdev_call(subdev, video, s_crop, crop); mutex_unlock(video-mutex); - return ret == -ENOIOCTLCMD ? -EINVAL : ret; + return ret == -ENOIOCTLCMD ? -ENOTTY : ret; } static int -- 1.7.12 -- 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/5] media:dvb:fix up ENOIOCTLCMD error handling
At commit 07d106d0, Linus pointed out that ENOIOCTLCMD should be translated as ENOTTY to user mode. Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: linux-media@vger.kernel.org Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com --- drivers/media/dvb/dvb-core/dvbdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb/dvb-core/dvbdev.c b/drivers/media/dvb/dvb-core/dvbdev.c index 39eab73..d33101a 100644 --- a/drivers/media/dvb/dvb-core/dvbdev.c +++ b/drivers/media/dvb/dvb-core/dvbdev.c @@ -420,7 +420,7 @@ int dvb_usercopy(struct file *file, /* call driver */ mutex_lock(dvbdev_mutex); if ((err = func(file, cmd, parg)) == -ENOIOCTLCMD) - err = -EINVAL; + err = -ENOTTY; mutex_unlock(dvbdev_mutex); if (err 0) -- 1.7.12 -- 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: [Bug] gspca_zc3xx v.2.14.0 Auto Gain is OFF
Hi Sam, Thanks for the detailed bug report. Unfortunately I don't have time to look into this atm. Perhaps someone else reading the list has time to look into this ? Regards, Hans On 08/26/2012 02:13 PM, Sam Bulka wrote: Hello, This is a bug report for gspca_zc3xx v.2.14.0 webcam driver installed as a module on ArchLinux plug computer, kernel 3.5.2-1-ARCH [root@alarm ~]# dmesg [ 15.271381] gspca_main: v2.14.0 registered [ 15.303224] gspca_main: gspca_zc3xx-2.14.0 probing 046d:08d7 [ 16.211715] fuse init (API version 7.19) [ 16.461436] input: gspca_zc3xx as /devices/platform/orion-ehci.0/usb1/1-1/1-1.4/input/input0 [ 16.469635] usbcore: registered new interface driver snd-usb-audio [ 16.470642] usbcore: registered new interface driver gspca_zc3xx [root@alarm ~]# lsusb Bus 001 Device 004: ID 046d:08d7 Logitech, Inc. QuickCam Communicate STX [root@alarm ~]# v4lctl list attribute | type | current | default | comment ---++-+-+- norm | choice | (null) | (null) | input | choice | gspca_z | gspca_z | gspca_zc3xx bright | int| 128 | 128 | range is 0 = 255 contrast | int| 128 | 128 | range is 0 = 255 Gamma | int| 4 | 4 | range is 1 = 6 Exposure | int|2343 |2343 | range is 781 = 18750 Gain, Auto | bool | on | on | Power Line | choice | Disable | Disable | Disabled 50 Hz 60 Hz Sharpness | int| 2 | 2 | range is 0 = 3 The above output is complete, there is nothing else coming from dmesg. In Windows 7 64-bit with the webcam connected, while running Logitech Webcam Software, shows some extra info: Logitech QuickCam Communicate STX Hardware IDUSB\VID_046DPID_08D7REV_0100MI_00 Procmon output for LWS.exe (from Registry): ZC0302 chipset, Image Sensor HV7131B Attached to this message are exported webcam Registry settings (default and factual), and controls available for the webcam and optimally set by LWS. Also attached are datasheets for the webcam chipset and image sensor. The main problems now are: - Image Sensor can't be identified by gspca_zc3xx driver or verified since not shown in dmesg - Auto Gain is switched off permanently (despite shown On), and its choice range is missing - Color Saturation and White Balance controls are absent - Changes in image are unnoticed when adjusting Brightness and Contrast within their full range The webcam works with exposure and other adjustments manually changed over the day, but very difficult to get quality image in evening low light. See also the discussion (https://bbs.archlinux.org/viewtopic.php?pid=879810#p879810) on how varying the driver's settings (quality and other) affects controls responsiveness (brightness and contrast) and perceived image quality. Thanks, Sam -- 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 03/12] coda: fix IRAM/AXI handling for i.MX53
Hi Philipp,
thank you for your patch. Please, find some comments below.
On 24 August 2012 18:17, Philipp Zabel p.za...@pengutronix.de wrote:
This uses the genalloc API to allocate a work buffer in the SoC's
on-chip SRAM and sets up the AXI_SRAM_USE register.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/video/Kconfig |3 ++-
drivers/media/video/coda.c | 61
---
drivers/media/video/coda.h | 21 ---
3 files changed, 76 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9cebf7b..1c40b1b 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1181,9 +1181,10 @@ config VIDEO_MEM2MEM_TESTDEV
config VIDEO_CODA
tristate ChipsMedia Coda multi-standard codec IP
- depends on VIDEO_DEV VIDEO_V4L2
+ depends on VIDEO_DEV VIDEO_V4L2 ARCH_MXC
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
+ select IRAM_ALLOC if SOC_IMX53
---help---
Coda is a range of video codec IPs that supports
H.264, MPEG-4, and other video formats.
diff --git a/drivers/media/video/coda.c b/drivers/media/video/coda.c
index aa12b7b..2e2e8c5 100644
--- a/drivers/media/video/coda.c
+++ b/drivers/media/video/coda.c
@@ -14,6 +14,7 @@
#include linux/clk.h
#include linux/delay.h
#include linux/firmware.h
+#include linux/genalloc.h
#include linux/interrupt.h
#include linux/io.h
#include linux/irq.h
@@ -24,6 +25,7 @@
#include linux/videodev2.h
#include linux/of.h
+#include mach/iram.h
#include media/v4l2-ctrls.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
@@ -42,6 +44,7 @@
#define CODA7_WORK_BUF_SIZE(512 * 1024 + CODA_FMO_BUF_SIZE * 8 * 1024)
#define CODA_PARA_BUF_SIZE (10 * 1024)
#define CODA_ISRAM_SIZE(2048 * 2)
+#define CODA7_IRAM_SIZE0x14000 /* 81920 bytes */
#define CODA_OUTPUT_BUFS 4
#define CODA_CAPTURE_BUFS 2
@@ -127,6 +130,9 @@ struct coda_dev {
struct coda_aux_buf codebuf;
struct coda_aux_buf workbuf;
+ struct gen_pool *iram_pool;
+ long unsigned int iram_vaddr;
+ long unsigned int iram_paddr;
spinlock_t irqlock;
struct mutexdev_mutex;
@@ -715,6 +721,13 @@ static void coda_device_run(void *m2m_priv)
coda_write(dev, pic_stream_buffer_addr, CODA_CMD_ENC_PIC_BB_START);
coda_write(dev, pic_stream_buffer_size / 1024,
CODA_CMD_ENC_PIC_BB_SIZE);
+
+ if (dev-devtype-product == CODA_7541) {
+ coda_write(dev, CODA7_USE_BIT_ENABLE |
CODA7_USE_HOST_BIT_ENABLE |
+ CODA7_USE_ME_ENABLE |
CODA7_USE_HOST_ME_ENABLE,
+ CODA7_REG_BIT_AXI_SRAM_USE);
+ }
+
coda_command_async(ctx, CODA_COMMAND_PIC_RUN);
}
@@ -946,8 +959,10 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
CODA7_STREAM_BUF_PIC_RESET, CODA_REG_BIT_STREAM_CTRL);
}
- /* Configure the coda */
- coda_write(dev, 0x4c00, CODA_REG_BIT_SEARCH_RAM_BASE_ADDR);
+ if (dev-devtype-product == CODA_DX6) {
+ /* Configure the coda */
+ coda_write(dev, dev-iram_paddr,
CODADX6_REG_BIT_SEARCH_RAM_BASE_ADDR);
+ }
/* Could set rotation here if needed */
switch (dev-devtype-product) {
@@ -1022,7 +1037,12 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
value = (FMO_SLICE_SAVE_BUF_SIZE 7);
value |= (0 CODA_FMOPARAM_TYPE_MASK)
CODA_FMOPARAM_TYPE_OFFSET;
value |= 0 CODA_FMOPARAM_SLICENUM_MASK;
- coda_write(dev, value, CODA_CMD_ENC_SEQ_FMO);
+ if (dev-devtype-product == CODA_DX6) {
+ coda_write(dev, value, CODADX6_CMD_ENC_SEQ_FMO);
+ } else {
+ coda_write(dev, dev-iram_paddr,
CODA7_CMD_ENC_SEQ_SEARCH_BASE);
+ coda_write(dev, 48 * 1024,
CODA7_CMD_ENC_SEQ_SEARCH_SIZE);
+ }
}
if (coda_command_sync(ctx, CODA_COMMAND_SEQ_INIT)) {
@@ -1052,7 +1072,15 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
}
coda_write(dev, src_vq-num_buffers, CODA_CMD_SET_FRAME_BUF_NUM);
- coda_write(dev, q_data_src-width, CODA_CMD_SET_FRAME_BUF_STRIDE);
+ coda_write(dev, round_up(q_data_src-width, 8),
CODA_CMD_SET_FRAME_BUF_STRIDE);
+ if (dev-devtype-product != CODA_DX6) {
+ coda_write(dev, round_up(q_data_src-width, 8),
CODA7_CMD_SET_FRAME_SOURCE_BUF_STRIDE);
+ coda_write(dev, dev-iram_paddr + 48 * 1024,
CODA7_CMD_SET_FRAME_AXI_DBKY_ADDR);
+
[PATCH v5 0/4] Update MFC v4l2 driver to support MFC6.x
The patchset adds support for MFCv6 firmware in s5p-mfc driver. The first two patches will update the existing MFCv5 driver framework for making it suitable for supporting co-existence with a newer hardware version. The last two patches add support for MFCv6 firmware. This patchset have to be applied on patches [1] and [2] posted earlier which adds the required v4l2 controls. Changelog: - Modified ops mechanism for macro based function call - Addressed all other review comments on Patch v4 [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg48972.html [2] http://www.mail-archive.com/linux-media@vger.kernel.org/msg48973.html Arun Kumar K (1): [media] s5p-mfc: Update MFCv5 driver for callback based architecture Jeongtae Park (3): [media] s5p-mfc: Add MFC variant data to device context [media] s5p-mfc: MFCv6 register definitions [media] s5p-mfc: Update MFC v4l2 driver to support MFC6.x drivers/media/video/Kconfig |4 +- drivers/media/video/s5p-mfc/Makefile |7 +- drivers/media/video/s5p-mfc/regs-mfc-v6.h| 440 ++ drivers/media/video/s5p-mfc/regs-mfc.h | 49 + drivers/media/video/s5p-mfc/s5p_mfc.c| 229 ++-- drivers/media/video/s5p-mfc/s5p_mfc_cmd.c| 98 +- drivers/media/video/s5p-mfc/s5p_mfc_cmd.h| 13 + drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.c | 164 +++ drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.h | 20 + drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c | 155 ++ drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.h | 20 + drivers/media/video/s5p-mfc/s5p_mfc_common.h | 174 ++- drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 188 ++- drivers/media/video/s5p-mfc/s5p_mfc_ctrl.h |1 + drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 226 ++- drivers/media/video/s5p-mfc/s5p_mfc_dec.h|1 + drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 208 ++-- drivers/media/video/s5p-mfc/s5p_mfc_enc.h|1 + drivers/media/video/s5p-mfc/s5p_mfc_intr.c | 11 +- drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 1407 ++- drivers/media/video/s5p-mfc/s5p_mfc_opr.h| 178 ++- drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.c | 1759 +++ drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.h | 85 ++ drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c | 1945 ++ drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h | 50 + drivers/media/video/s5p-mfc/s5p_mfc_pm.c |3 +- drivers/media/video/s5p-mfc/s5p_mfc_shm.c| 47 - drivers/media/video/s5p-mfc/s5p_mfc_shm.h| 90 -- 28 files changed, 5700 insertions(+), 1873 deletions(-) create mode 100644 drivers/media/video/s5p-mfc/regs-mfc-v6.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h delete mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_shm.c delete mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_shm.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 v5 2/4] [media] s5p-mfc: Add MFC variant data to device context
From: Jeongtae Park jtp.p...@samsung.com
MFC variant data replaces various macros used in the driver
which will change in a different version of MFC hardware.
Also does a cleanup of MFC context structure and common files.
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
Signed-off-by: Janghyuck Kim janghyuck@samsung.com
Signed-off-by: Jaeryul Oh jaeryul...@samsung.com
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/video/s5p-mfc/regs-mfc.h | 17 ++
drivers/media/video/s5p-mfc/s5p_mfc.c| 78 +-
drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.c |4 +-
drivers/media/video/s5p-mfc/s5p_mfc_common.h | 72 ++---
drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c |7 +-
drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 44 +-
drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.c | 213 +-
7 files changed, 258 insertions(+), 177 deletions(-)
diff --git a/drivers/media/video/s5p-mfc/regs-mfc.h
b/drivers/media/video/s5p-mfc/regs-mfc.h
index a19bece..3e2fce0 100644
--- a/drivers/media/video/s5p-mfc/regs-mfc.h
+++ b/drivers/media/video/s5p-mfc/regs-mfc.h
@@ -414,5 +414,22 @@
#define S5P_FIMV_SHARED_EXTENDED_SAR 0x0078
#define S5P_FIMV_SHARED_H264_I_PERIOD 0x009C
#define S5P_FIMV_SHARED_RC_CONTROL_CONFIG 0x00A0
+#define S5P_FIMV_SHARED_DISP_FRAME_TYPE_SHIFT 2
+
+/* Offset used by the hardware to store addresses */
+#define MFC_OFFSET_SHIFT 11
+
+#define FIRMWARE_ALIGN 0x2 /* 128KB */
+#define MFC_H264_CTX_BUF_SIZE 0x96000 /* 600KB per H264 instance */
+#define MFC_CTX_BUF_SIZE 0x2800 /* 10KB per instance */
+#define DESC_BUF_SIZE 0x2 /* 128KB for DESC buffer */
+#define SHARED_BUF_SIZE0x2000 /* 8KB for shared
buffer */
+
+#define DEF_CPB_SIZE 0x4 /* 512KB */
+#define MAX_CPB_SIZE 0x40/* 4MB */
+#define MAX_FW_SIZE0x6
+
+#define MFC_VERSION0x51
+#define MFC_NUM_PORTS 2
#endif /* _REGS_FIMV_H */
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc.c
b/drivers/media/video/s5p-mfc/s5p_mfc.c
index ab66680..1ca377e 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc.c
@@ -421,7 +421,6 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx *ctx,
unsigned int reason, unsigned int err)
{
struct s5p_mfc_dev *dev;
- unsigned int guard_width, guard_height;
if (ctx == NULL)
return;
@@ -433,40 +432,8 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx
*ctx,
ctx-img_width = s5p_mfc_get_img_width(dev);
ctx-img_height = s5p_mfc_get_img_height(dev);
- ctx-buf_width = ALIGN(ctx-img_width,
- S5P_FIMV_NV12MT_HALIGN);
- ctx-buf_height = ALIGN(ctx-img_height,
- S5P_FIMV_NV12MT_VALIGN);
- mfc_debug(2, SEQ Done: Movie dimensions %dx%d,
- buffer dimensions: %dx%d\n, ctx-img_width,
- ctx-img_height, ctx-buf_width,
- ctx-buf_height);
- if (ctx-codec_mode == S5P_FIMV_CODEC_H264_DEC) {
- ctx-luma_size = ALIGN(ctx-buf_width *
- ctx-buf_height, S5P_FIMV_DEC_BUF_ALIGN);
- ctx-chroma_size = ALIGN(ctx-buf_width *
-ALIGN((ctx-img_height 1),
- S5P_FIMV_NV12MT_VALIGN),
- S5P_FIMV_DEC_BUF_ALIGN);
- ctx-mv_size = ALIGN(ctx-buf_width *
- ALIGN((ctx-buf_height 2),
- S5P_FIMV_NV12MT_VALIGN),
- S5P_FIMV_DEC_BUF_ALIGN);
- } else {
- guard_width = ALIGN(ctx-img_width + 24,
- S5P_FIMV_NV12MT_HALIGN);
- guard_height = ALIGN(ctx-img_height + 16,
- S5P_FIMV_NV12MT_VALIGN);
- ctx-luma_size = ALIGN(guard_width *
- guard_height, S5P_FIMV_DEC_BUF_ALIGN);
- guard_width = ALIGN(ctx-img_width + 16,
- S5P_FIMV_NV12MT_HALIGN);
- guard_height = ALIGN((ctx-img_height 1) + 4,
- S5P_FIMV_NV12MT_VALIGN);
- ctx-chroma_size = ALIGN(guard_width *
- guard_height, S5P_FIMV_DEC_BUF_ALIGN);
- ctx-mv_size = 0;
-
[PATCH v5 3/4] [media] s5p-mfc: MFCv6 register definitions
From: Jeongtae Park jtp.p...@samsung.com Adds register definitions for MFC v6.x firmware Signed-off-by: Jeongtae Park jtp.p...@samsung.com Signed-off-by: Janghyuck Kim janghyuck@samsung.com Signed-off-by: Jaeryul Oh jaeryul...@samsung.com Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Signed-off-by: Arun Kumar K arun...@samsung.com --- drivers/media/video/s5p-mfc/regs-mfc-v6.h | 440 + 1 files changed, 440 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/s5p-mfc/regs-mfc-v6.h diff --git a/drivers/media/video/s5p-mfc/regs-mfc-v6.h b/drivers/media/video/s5p-mfc/regs-mfc-v6.h new file mode 100644 index 000..84ce1d8 --- /dev/null +++ b/drivers/media/video/s5p-mfc/regs-mfc-v6.h @@ -0,0 +1,440 @@ +/* + * Register definition file for Samsung MFC V6.x Interface (FIMV) driver + * + * Copyright (c) 2012 Samsung Electronics + * http://www.samsung.com/ + * + * 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 _REGS_FIMV_V6_H +#define _REGS_FIMV_V6_H + +#define S5P_FIMV_REG_SIZE_V6 (S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR) +#define S5P_FIMV_REG_COUNT_V6 ((S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR) / 4) + +/* Number of bits that the buffer address should be shifted for particular + * MFC buffers. */ +#define S5P_FIMV_MEM_OFFSET_V6 0 + +#define S5P_FIMV_START_ADDR_V6 0x +#define S5P_FIMV_END_ADDR_V6 0xfd80 + +#define S5P_FIMV_REG_CLEAR_BEGIN_V60xf000 +#define S5P_FIMV_REG_CLEAR_COUNT_V61024 + +/* Codec Common Registers */ +#define S5P_FIMV_RISC_ON_V60x +#define S5P_FIMV_RISC2HOST_INT_V6 0x003C +#define S5P_FIMV_HOST2RISC_INT_V6 0x0044 +#define S5P_FIMV_RISC_BASE_ADDRESS_V6 0x0054 + +#define S5P_FIMV_MFC_RESET_V6 0x1070 + +#define S5P_FIMV_HOST2RISC_CMD_V6 0x1100 +#define S5P_FIMV_H2R_CMD_EMPTY_V6 0 +#define S5P_FIMV_H2R_CMD_SYS_INIT_V6 1 +#define S5P_FIMV_H2R_CMD_OPEN_INSTANCE_V6 2 +#define S5P_FIMV_CH_SEQ_HEADER_V6 3 +#define S5P_FIMV_CH_INIT_BUFS_V6 4 +#define S5P_FIMV_CH_FRAME_START_V6 5 +#define S5P_FIMV_H2R_CMD_CLOSE_INSTANCE_V6 6 +#define S5P_FIMV_H2R_CMD_SLEEP_V6 7 +#define S5P_FIMV_H2R_CMD_WAKEUP_V6 8 +#define S5P_FIMV_CH_LAST_FRAME_V6 9 +#define S5P_FIMV_H2R_CMD_FLUSH_V6 10 +/* RMVME: REALLOC used? */ +#define S5P_FIMV_CH_FRAME_START_REALLOC_V6 5 + +#define S5P_FIMV_RISC2HOST_CMD_V6 0x1104 +#define S5P_FIMV_R2H_CMD_EMPTY_V6 0 +#define S5P_FIMV_R2H_CMD_SYS_INIT_RET_V6 1 +#define S5P_FIMV_R2H_CMD_OPEN_INSTANCE_RET_V6 2 +#define S5P_FIMV_R2H_CMD_SEQ_DONE_RET_V6 3 +#define S5P_FIMV_R2H_CMD_INIT_BUFFERS_RET_V6 4 + +#define S5P_FIMV_R2H_CMD_CLOSE_INSTANCE_RET_V6 6 +#define S5P_FIMV_R2H_CMD_SLEEP_RET_V6 7 +#define S5P_FIMV_R2H_CMD_WAKEUP_RET_V6 8 +#define S5P_FIMV_R2H_CMD_COMPLETE_SEQ_RET_V6 9 +#define S5P_FIMV_R2H_CMD_DPB_FLUSH_RET_V6 10 +#define S5P_FIMV_R2H_CMD_NAL_ABORT_RET_V6 11 +#define S5P_FIMV_R2H_CMD_FW_STATUS_RET_V6 12 +#define S5P_FIMV_R2H_CMD_FRAME_DONE_RET_V6 13 +#define S5P_FIMV_R2H_CMD_FIELD_DONE_RET_V6 14 +#define S5P_FIMV_R2H_CMD_SLICE_DONE_RET_V6 15 +#define S5P_FIMV_R2H_CMD_ENC_BUFFER_FUL_RET_V6 16 +#define S5P_FIMV_R2H_CMD_ERR_RET_V632 + +#define S5P_FIMV_FW_VERSION_V6 0xF000 + +#define S5P_FIMV_INSTANCE_ID_V60xF008 +#define S5P_FIMV_CODEC_TYPE_V6 0xF00C +#define S5P_FIMV_CONTEXT_MEM_ADDR_V6 0xF014 +#define S5P_FIMV_CONTEXT_MEM_SIZE_V6 0xF018 +#define S5P_FIMV_PIXEL_FORMAT_V6 0xF020 + +#define S5P_FIMV_METADATA_ENABLE_V60xF024 +#define S5P_FIMV_DBG_BUFFER_ADDR_V60xF030 +#define S5P_FIMV_DBG_BUFFER_SIZE_V60xF034 +#define S5P_FIMV_RET_INSTANCE_ID_V60xF070 + +#define S5P_FIMV_ERROR_CODE_V6 0xF074 +#define S5P_FIMV_ERR_WARNINGS_START_V6 160 +#define S5P_FIMV_ERR_DEC_MASK_V6 0x +#define S5P_FIMV_ERR_DEC_SHIFT_V6 0 +#define S5P_FIMV_ERR_DSPL_MASK_V6 0x +#define S5P_FIMV_ERR_DSPL_SHIFT_V6 16 + +#define S5P_FIMV_DBG_BUFFER_OUTPUT_SIZE_V6 0xF078 +#define S5P_FIMV_METADATA_STATUS_V60xF07C +#define S5P_FIMV_METADATA_ADDR_MB_INFO_V6 0xF080 +#define S5P_FIMV_METADATA_SIZE_MB_INFO_V6 0xF084 + +/* Decoder Registers */ +#define S5P_FIMV_D_CRC_CTRL_V6 0xF0B0 +#define S5P_FIMV_D_DEC_OPTIONS_V6 0xF0B4 +#define S5P_FIMV_D_OPT_FMO_ASO_CTRL_MASK_V64 +#define S5P_FIMV_D_OPT_DDELAY_EN_SHIFT_V6 3 +#define S5P_FIMV_D_OPT_LF_CTRL_SHIFT_V61
Re: [PATCHv2 7/8] ir-rx51: Convert latency constraints to PM QoS API
Hi Timo, On Fri, Aug 24, 2012 at 10:39 PM, Tony Lindgren t...@atomide.com wrote: * Timo Kokkonen timo.t.kokko...@iki.fi [120824 08:11]: Convert the driver from the obsolete omap_pm_set_max_mpu_wakeup_lat API to the new PM QoS API. This allows the callback to be removed from the platform data structure. The latency requirements are also adjusted to prevent the MPU from going into sleep mode. This is needed as the GP timers have no means to wake up the MPU once it has gone into sleep. The side effect is that from now on the driver actually works even if there is no background load keeping the MPU awake. Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi This should get acked by Kevin ideally. Other than that: Acked-by: Tony Lindgren t...@atomide.com ... @@ -268,10 +270,14 @@ static ssize_t lirc_rx51_write(struct file *file, const char *buf, lirc_rx51-wbuf[count] = -1; /* Insert termination mark */ /* -* Adjust latency requirements so the device doesn't go in too -* deep sleep states +* If the MPU is going into too deep sleep state while we are +* transmitting the IR code, timers will not be able to wake +* up the MPU. Thus, we need to set a strict enough latency +* requirement in order to ensure the interrupts come though +* properly. */ - lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, 50); + pm_qos_add_request(lirc_rx51-pm_qos_request, + PM_QOS_CPU_DMA_LATENCY, 10); Minor remark: it would be nice to have more detail on where the latency number 10 comes from. Is it fixed, is it linked to the baud rate etc? Here is my ack for the PM QoS API part: Acked-by: Jean Pihet j-pi...@ti.com Regards, Jean -- 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 v5 0/4] Update MFC v4l2 driver to support MFC6.x
Hi Arun, The media tree has been re-organized recently. It would be useful to re-base your patches against the latest media tree (or linux-next). MFC driver is now located at drivers/media/platform/s5p-mfc/ On 27 August 2012 17:27, Arun Kumar K arun...@samsung.com wrote: The patchset adds support for MFCv6 firmware in s5p-mfc driver. The first two patches will update the existing MFCv5 driver framework for making it suitable for supporting co-existence with a newer hardware version. The last two patches add support for MFCv6 firmware. This patchset have to be applied on patches [1] and [2] posted earlier which adds the required v4l2 controls. Changelog: - Modified ops mechanism for macro based function call - Addressed all other review comments on Patch v4 [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg48972.html [2] http://www.mail-archive.com/linux-media@vger.kernel.org/msg48973.html Arun Kumar K (1): [media] s5p-mfc: Update MFCv5 driver for callback based architecture Jeongtae Park (3): [media] s5p-mfc: Add MFC variant data to device context [media] s5p-mfc: MFCv6 register definitions [media] s5p-mfc: Update MFC v4l2 driver to support MFC6.x drivers/media/video/Kconfig |4 +- drivers/media/video/s5p-mfc/Makefile |7 +- drivers/media/video/s5p-mfc/regs-mfc-v6.h| 440 ++ drivers/media/video/s5p-mfc/regs-mfc.h | 49 + drivers/media/video/s5p-mfc/s5p_mfc.c| 229 ++-- drivers/media/video/s5p-mfc/s5p_mfc_cmd.c| 98 +- drivers/media/video/s5p-mfc/s5p_mfc_cmd.h| 13 + drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.c | 164 +++ drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.h | 20 + drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c | 155 ++ drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.h | 20 + drivers/media/video/s5p-mfc/s5p_mfc_common.h | 174 ++- drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 188 ++- drivers/media/video/s5p-mfc/s5p_mfc_ctrl.h |1 + drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 226 ++- drivers/media/video/s5p-mfc/s5p_mfc_dec.h|1 + drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 208 ++-- drivers/media/video/s5p-mfc/s5p_mfc_enc.h|1 + drivers/media/video/s5p-mfc/s5p_mfc_intr.c | 11 +- drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 1407 ++- drivers/media/video/s5p-mfc/s5p_mfc_opr.h| 178 ++- drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.c | 1759 +++ drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.h | 85 ++ drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c | 1945 ++ drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h | 50 + drivers/media/video/s5p-mfc/s5p_mfc_pm.c |3 +- drivers/media/video/s5p-mfc/s5p_mfc_shm.c| 47 - drivers/media/video/s5p-mfc/s5p_mfc_shm.h| 90 -- 28 files changed, 5700 insertions(+), 1873 deletions(-) create mode 100644 drivers/media/video/s5p-mfc/regs-mfc-v6.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h delete mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_shm.c delete mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_shm.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 -- With warm regards, Sachin -- 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: Terratec H7 aka az6007 with CI
On 08/26/2012 10:52 PM, Roger Mårtensson wrote: Hello! Just a reminder that az6007 with CI still isn't working 100% with Kaffeine. But since I use my device with MythTV that uses the same usage pattern as my workaround for Kaffeine it works like a charm. The pattern are: * Open up device / Start Kaffeine * Tune to encrypted channel / Choose channel in Kaffeine * Close Device / Close Kaffeine * Open device / Start Kaffeine * Watch channel The exact procedure that MythTV uses when tuning to a channel. Not exactly sure if this is a driver bug or a Kaffeine bug since I'm just a user. It is likely driver bug. You could take sniffs from windows and do some hacking. It should not be very hard to fix. The normal way that do not work in Kaffeine are: * Start Kaffeine * Tune to an encrypted channel * If that works tune to another encrypted channel which will not work. Since it is working with my main application I'm satisfied but look at this as a formal bug report. If you need any help or testing I'm willing to help time permitting. I know that some of you doing the actual work doesn't have access to a CAM but if you need debugging information or any output just notify me directly. I'm am running a relativly new media_build. Haven't been able to test the latest media_build since it is stopping on a compile error. (As of 25 of August 2012) I don't see that, but it is not surprise as I use latest Kernel. Also latest build test logs shows all builds are working http://hverkuil.home.xs4all.nl/logs/Sunday.log Thanks again for the hard work with the driver (Mauro for the inclusion and Jose for the CI. Hopefully I got the names right). It is much appreciated by me and my better half. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 7/8] ir-rx51: Convert latency constraints to PM QoS API
On 08/27/12 12:25, Jean Pihet wrote: Hi Timo, On Fri, Aug 24, 2012 at 10:39 PM, Tony Lindgren t...@atomide.com wrote: * Timo Kokkonen timo.t.kokko...@iki.fi [120824 08:11]: Convert the driver from the obsolete omap_pm_set_max_mpu_wakeup_lat API to the new PM QoS API. This allows the callback to be removed from the platform data structure. The latency requirements are also adjusted to prevent the MPU from going into sleep mode. This is needed as the GP timers have no means to wake up the MPU once it has gone into sleep. The side effect is that from now on the driver actually works even if there is no background load keeping the MPU awake. Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi This should get acked by Kevin ideally. Other than that: Acked-by: Tony Lindgren t...@atomide.com ... @@ -268,10 +270,14 @@ static ssize_t lirc_rx51_write(struct file *file, const char *buf, lirc_rx51-wbuf[count] = -1; /* Insert termination mark */ /* -* Adjust latency requirements so the device doesn't go in too -* deep sleep states +* If the MPU is going into too deep sleep state while we are +* transmitting the IR code, timers will not be able to wake +* up the MPU. Thus, we need to set a strict enough latency +* requirement in order to ensure the interrupts come though +* properly. */ - lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, 50); + pm_qos_add_request(lirc_rx51-pm_qos_request, + PM_QOS_CPU_DMA_LATENCY, 10); Minor remark: it would be nice to have more detail on where the latency number 10 comes from. Is it fixed, is it linked to the baud rate etc? Yeah, it was chosen to be low enough for the MPU to receive the IRQ from the timers. 50us was good enough back then with the original n900 kernel, but nowadays it is not good enough from preventing the MPU from going to sleep where the timer interrupts don't come through. Yes, I should probably have stated that in the comment to make it clear. Can I re-send just this one patch or should I send the entire set again? I'm assuming these go in through Mauro's media tree as these depend on stuff that's already there. So, which ever is easier for him I guess :) Thanks! -Timo Here is my ack for the PM QoS API part: Acked-by: Jean Pihet j-pi...@ti.com Regards, Jean -- 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 RFC 0/4] V4L2: Vendor specific media bus formats/ frame size control
Hello, On 2012-08-23 11:51, Sylwester Nawrocki wrote: This patch series introduces new image source class control - V4L2_CID_FRAMESIZE and vendor or device specific media bus format section. There was already a discussion WRT handling interleaved image data [1]. I'm not terribly happy with those vendor specific media bus formats but I couldn't find better solution that would comply with the V4L2 API concepts and would work reliably. What about Sakari's Frame format descriptors RFC[1] that would allow to describe arbitrary pixel code combinations and provide required information (virtual channel and data type) to the CSI receiver driver for configuring the hardware? Thanks in advance. Best regards, Nicolas [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg43530.html-- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/4] Update MFC v4l2 driver to support MFC6.x
On 08/27/2012 11:31 AM, Sachin Kamat wrote: Hi Arun, The media tree has been re-organized recently. It would be useful to re-base your patches against the latest media tree (or linux-next). MFC driver is now located at drivers/media/platform/s5p-mfc/ And you can find some guidelines in this post: http://www.mail-archive.com/linux-media@vger.kernel.org/msg50498.html -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/4] V4L: Add V4L2_CID_FRAMESIZE image source class control
Hi Sylwester, On Sun, Aug 26, 2012 at 09:22:12PM +0200, Sylwester Nawrocki wrote: On 08/25/2012 12:51 AM, Sakari Ailus wrote: --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -727,6 +727,7 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_VBLANK: return Vertical Blanking; case V4L2_CID_HBLANK: return Horizontal Blanking; case V4L2_CID_ANALOGUE_GAIN:return Analogue Gain; + case V4L2_CID_FRAMESIZE:return Maximum Frame Size; I would put this to the image processing class, as the control isn't related to image capture. Jpeg encoding (or image compression in general) after all is related to image processing rather than capturing it. All right, might make more sense that way. Let me move it to the image processing class then. It probably also makes sense to name it V4L2_CID_FRAME_SIZE, rather than V4L2_CID_FRAMESIZE. Hmm. While we're at it, as the size is maximum --- it can be lower --- how about V4L2_CID_MAX_FRAME_SIZE or V4L2_CID_MAX_FRAME_SAMPLES, as the unit is samples? Does sample in this context mean pixels for uncompressed formats and bytes (octets) for compressed formats? It's important to define it as we're also using the term sample to refer to data units transferred over a parallel bus per a clock cycle. I agree with Sakari here, I find the documentation quite vague, I wouldn't understand what the control is meant for from the documentation only. I thought it was clear enough: Maximum size of a data frame in media bus sample units. ^ Oops. I somehow managed to miss that. My mistake. So that means the unit is a number of bits clocked by a single clock pulse on parallel video bus... :) But how is media bus sample defined in case of CSI bus ? Looks like media bus sample is a useless term for our purpose. The CSI2 transmitters and receivers, as far as I understand, want to know a lot more about the data that I think would be necessary. This doesn't only involve the bits per sample (e.g. pixel for raw bayer formats) but some information on the media bus code, too. I.e. if you're transferring 11 bit pixels the bus has to know that. I think it would have been better to use different media bus codes for serial busses than on parallel busses that transfer the sample on a single clock cycle. But that's out of the scope of this patch. In respect to this the CCP2 AFAIR works mostly the same way. I thought it was better than just 8-bit byte, because the data receiver (bridge) could layout data received from video bus in various ways in memory, e.g. add some padding. OTOH, would any padding make sense for compressed streams ? It would break the content, wouldn't it ? I guess it't break if the padding is applied anywhere else than the end, where I hope it's ok. I'm not that familiar with compressed formats, though. The hardware typically has limitations on the DMA transaction width and that can easily be e.g. 32 or 64 bytes, so some padding may easily be introduced at the end of the compressed image. The padding at the frame end is not a problem, since it would be a property of a bridge. So the reported sizeimage value with VIDIOC_G_FMT, for example, could be easily adjusted a a bridge driver to account any padding. So I would propose to use 8-bit byte as a unit for this control and name it V4L2_CID_MAX_FRAME_SIZE. All in all it's not really tied to the media bus. It took me quite a while toe remember what the control really was for. ;) :-) Yeah, looks like I have been going in circles with this issue.. ;) How about using bytes on video nodes and bus and media bus code specific extended samples (or how we should call pixels in uncompressed formats and units of data in compressed formats?) on subdevs? The information how the former is derived from the latter resides in the driver controlling the DMA anyway. As you proposed originally, this control is more relevant to subdevs so we could also not define it for video nodes at all. Especially if the control isn't needed: the information should be available from VIDIOC_TRY_FMT. Yeah, I seem to have forgotten to add a note that this control would be valid only on subdev nodes :/ OTOH, how do we handle cases where subdev's controls are inherited by a video node ? Referring to an media bus pixel code seems wrong in that cases. I don't think this control ever should be visible on a video device if we define it's only valid for subdevs. Even then, if it's implemented by a subdev driver, its value refers to samples rather than bytes which would make more sense on a video node (in case we'd define it there). AFAIR Hans once suggested a flag to hide low-level controls from video nodes and inherit
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Mon Aug 27 19:00:21 CEST 2012 git hash:79e8c7bebb467bbc3f2514d75bba669a3f354324 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v2 Add support to Avermedia Twinstar double tuner in af9035
Hello
this is not final review, as there was more things to check I was first
thinking. I have to look it tomorrow too. But few comments still.
On 08/27/2012 01:25 AM, Jose Alberto Reguero wrote:
This patch add support to the Avermedia Twinstar double tuner in the af9035
driver. Version 2 of the patch with suggestions of Antti.
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Jose Alberto
diff -upr linux/drivers/media/dvb-frontends/af9033.c
linux.new/drivers/media/dvb-frontends/af9033.c
--- linux/drivers/media/dvb-frontends/af9033.c 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/dvb-frontends/af9033.c 2012-08-26
23:38:10.527070150 +0200
@@ -51,6 +51,8 @@ static int af9033_wr_regs(struct af9033_
};
buf[0] = (reg 16) 0xff;
+ if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL)
+ buf[0] |= 0x10;
buf[1] = (reg 8) 0xff;
buf[2] = (reg 0) 0xff;
memcpy(buf[3], val, len);
@@ -87,6 +89,9 @@ static int af9033_rd_regs(struct af9033_
}
};
+ if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL)
+ buf[0] |= 0x10;
+
I don't like that if TS mode serial then tweak address bytes.
I looked those from the sniff and it looks like that bit is used as a
mail box pointing out if chip is on secondary bus. Imagine it as a
situation there is two I2C bus, 1st demod is on bus#0 and 2nd demod is
on bus#1. Such kind of info does not belong here - correct place is
I2C-adapter or even register multiple adapters.
ret = i2c_transfer(state-i2c, msg, 2);
if (ret == 2) {
ret = 0;
@@ -325,6 +330,18 @@ static int af9033_init(struct dvb_fronte
if (ret 0)
goto err;
}
+
+ if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL) {
+ ret = af9033_wr_reg_mask(state, 0x00d91c, 0x01, 0x01);
+ if (ret 0)
+ goto err;
+ ret = af9033_wr_reg_mask(state, 0x00d917, 0x00, 0x01);
+ if (ret 0)
+ goto err;
+ ret = af9033_wr_reg_mask(state, 0x00d916, 0x00, 0x01);
+ if (ret 0)
+ goto err;
+ }
Haven't looked these yet.
state-bandwidth_hz = 0; /* force to program all parameters */
diff -upr linux/drivers/media/tuners/mxl5007t.c
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.c 2012-08-25 19:36:44.689924518
+0200
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, cfg-invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
- set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable 3);
set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
@@ -531,9 +530,11 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
- ret = mxl5007t_soft_reset(state);
- if (mxl_fail(ret))
- goto fail;
+ if (!state-config-no_reset) {
+ ret = mxl5007t_soft_reset(state);
+ if (mxl_fail(ret))
+ goto fail;
+ }
What happens if you do soft reset as normally?
I would like to mention that AF9035/AF9033/MXL5007T was supported even
earlier that given patch in question and I can guess it has been
working. So why you are changing it now ?
If you do these changes because what you see is different compared to
windows sniff then you are on wrong way. Windows and Linux drivers are
not needed to do 100% similar USB commands.
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +888,10 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
- ret = mxl5007t_get_chip_id(state);
+ if (!state-config-no_probe)
+ ret = mxl5007t_get_chip_id(state);
Same here. AF9015 firmware does not support reading for MXL5007T. Due to
that, it outputs something like unknown chip revision detected but works
as it should. Similar case here as AF9015 ?
+
+ ret = mxl5007t_write_reg(state, 0x04,
state-config-loop_thru_enable);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.h 2012-08-25 19:38:19.990920623
+0200
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
Re: [PATCH v5 0/4] Update MFC v4l2 driver to support MFC6.x
Hi,
Thank you Sylvester and Sachin for pointing it out.
Will rebase the patches on media tree along with other comments
if any from Kamil.
Regards
Arun
--- Original Message ---
Sender : Sylwester Nawrockisylvester.nawro...@gmail.com
Date : Aug 28, 2012 00:20 (GMT+05:30)
Title : Re: [PATCH v5 0/4] Update MFC v4l2 driver to support MFC6.x
On 08/27/2012 11:31 AM, Sachin Kamat wrote:
Hi Arun,
The media tree has been re-organized recently.
It would be useful to re-base your patches against the latest media
tree (or linux-next).
MFC driver is now located at drivers/media/platform/s5p-mfc/
And you can find some guidelines in this post:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg50498.html
--
Regards,
Sylwester
pnbsp;/ppnbsp;/pN‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±™çbj)í…æèw* jg¬±¨ ¶‰šŽŠÝ¢j/�êäz¹Þ–Šà2ŠÞ™¨èÚ¢)ß¡«a¶Úþø ®G«�éh®æj:+v‰¨Šwè†Ù¥
