[PATCH] [media] s5p-fimc: fix main scaler SFRs depends on FIMC version
The main scaler has four SFRs for main scaler ratio depends on FIMC version.
FIMC 4.x has only two SFRs and FIMC 5.x has four SFRs for main scaler.
Those are MainHorRatio, MainHorRatio_ext, MainVerRatio and MainverRatio_ext.
The FIMC 5.x has 15 bit resolution for scaling ratio as below.
{MainHorRatio,MainHorRatio_ext} = {[14:6],[5:0]}.
{MainVerRatio,MainVerRatio_ext} = {[14:6],[5:0]}.
MainHorRatio = CISCCTRL[24:16], MainHorRatio_ext = CIEXTEN[15:10]
MainVerRatio = CISCCTRL[8:0], MainVerRatio_ext = CIEXTEN[5:0]
This patch supports FIMC 4.x and FIMC 5.x using platform_device_id::driver_data.
Signed-off-by: Hyunwoong Kim khw0178@samsung.com
Reviewed-by: Jonghun Han jonghun@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |7 +++-
drivers/media/video/s5p-fimc/fimc-core.c| 21 ++--
drivers/media/video/s5p-fimc/fimc-core.h|5 ++-
drivers/media/video/s5p-fimc/fimc-reg.c | 48 --
drivers/media/video/s5p-fimc/regs-fimc.h| 10 +-
5 files changed, 81 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index b216530..ca48e02 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -208,6 +208,7 @@ static int start_streaming(struct vb2_queue *q)
struct fimc_ctx *ctx = q-drv_priv;
struct fimc_dev *fimc = ctx-fimc_dev;
struct s3c_fimc_isp_info *isp_info;
+ struct samsung_fimc_variant *variant = ctx-fimc_dev-variant;
int ret;
ret = v4l2_subdev_call(fimc-vid_cap.sd, video, s_stream, 1);
@@ -230,7 +231,11 @@ static int start_streaming(struct vb2_queue *q)
return ret;
}
fimc_hw_set_input_path(ctx);
- fimc_hw_set_scaler(ctx);
+ fimc_hw_set_prescaler(ctx);
+ if (!variant-has_mainscaler_ext)
+ fimc_hw_set_mainscaler(ctx);
+ else
+ fimc_hw_set_mainscaler_ext(ctx);
fimc_hw_set_target_format(ctx);
fimc_hw_set_rotation(ctx);
fimc_hw_set_effect(ctx);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 7f56987..3cfa4b6 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -246,6 +246,7 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx)
struct fimc_scaler *sc = ctx-scaler;
struct fimc_frame *s_frame = ctx-s_frame;
struct fimc_frame *d_frame = ctx-d_frame;
+ struct samsung_fimc_variant *variant = ctx-fimc_dev-variant;
int tx, ty, sx, sy;
int ret;
@@ -284,8 +285,13 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx)
sc-pre_dst_width = sx / sc-pre_hratio;
sc-pre_dst_height = sy / sc-pre_vratio;
- sc-main_hratio = (sx 8) / (tx sc-hfactor);
- sc-main_vratio = (sy 8) / (ty sc-vfactor);
+ if (!variant-has_mainscaler_ext) {
+ sc-main_hratio = (sx 8) / (tx sc-hfactor);
+ sc-main_vratio = (sy 8) / (ty sc-vfactor);
+ } else {
+ sc-main_hratio = (sx 14) / (tx sc-hfactor);
+ sc-main_vratio = (sy 14) / (ty sc-vfactor);
+ }
sc-scaleup_h = (tx = sx) ? 1 : 0;
sc-scaleup_v = (ty = sy) ? 1 : 0;
@@ -569,6 +575,7 @@ static void fimc_dma_run(void *priv)
{
struct fimc_ctx *ctx = priv;
struct fimc_dev *fimc;
+ struct samsung_fimc_variant *variant = ctx-fimc_dev-variant;
unsigned long flags;
u32 ret;
@@ -601,7 +608,12 @@ static void fimc_dma_run(void *priv)
err(Scaler setup error);
goto dma_unlock;
}
- fimc_hw_set_scaler(ctx);
+
+ fimc_hw_set_prescaler(ctx);
+ if (!variant-has_mainscaler_ext)
+ fimc_hw_set_mainscaler(ctx);
+ else
+ fimc_hw_set_mainscaler_ext(ctx);
fimc_hw_set_target_format(ctx);
fimc_hw_set_rotation(ctx);
fimc_hw_set_effect(ctx);
@@ -1722,6 +1734,7 @@ static struct samsung_fimc_variant fimc1_variant_s5pv210
= {
.pix_hoff= 1,
.has_inp_rot = 1,
.has_out_rot = 1,
+ .has_mainscaler_ext = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
.hor_offs_align = 1,
@@ -1743,6 +1756,7 @@ static struct samsung_fimc_variant fimc0_variant_s5pv310
= {
.has_inp_rot = 1,
.has_out_rot = 1,
.has_cistatus2 = 1,
+ .has_mainscaler_ext = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
.hor_offs_align = 1,
@@ -1753,6 +1767,7 @@ static struct samsung_fimc_variant fimc0_variant_s5pv310
= {
static struct samsung_fimc_variant
RE: [PATCH v4 1/2] OMAP_VOUT: CLEANUP: Move some functions and macros from omap_vout
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Taneja, Archit
Sent: Friday, December 17, 2010 12:13 PM
To: linux-media@vger.kernel.org
Cc: linux-o...@vger.kernel.org; Taneja, Archit
Subject: [PATCH v4 1/2] OMAP_VOUT: CLEANUP: Move some functions and macros
from omap_vout
Move some inline functions from omap_vout.c to omap_voutdef.h and
independent
functions like omap_vout_alloc_buffer/omap_vout_free_buffer to
omap_voutlib.c.
[Hiremath, Vaibhav] Thanks, Archit.
Tested-By Vaibhav Hiremath hvaib...@ti.com
Acked-By Vaibhav Hiremath hvaib...@ti.com
Thanks,
Vaibhav
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c| 109 --
-
drivers/media/video/omap/omap_voutdef.h | 62 +
drivers/media/video/omap/omap_voutlib.c | 44
drivers/media/video/omap/omap_voutlib.h |2 +
4 files changed, 108 insertions(+), 109 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 15f8793..e1df01c 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -35,17 +35,14 @@
#include linux/sched.h
#include linux/types.h
#include linux/platform_device.h
-#include linux/dma-mapping.h
#include linux/irq.h
#include linux/videodev2.h
-#include linux/slab.h
#include media/videobuf-dma-contig.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include plat/dma.h
-#include plat/vram.h
#include plat/vrfb.h
#include plat/display.h
@@ -56,7 +53,6 @@ MODULE_AUTHOR(Texas Instruments);
MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
MODULE_LICENSE(GPL);
-
/* Driver Configuration macros */
#define VOUT_NAMEomap_vout
@@ -65,31 +61,6 @@ enum omap_vout_channels {
OMAP_VIDEO2,
};
-enum dma_channel_state {
- DMA_CHAN_NOT_ALLOTED,
- DMA_CHAN_ALLOTED,
-};
-
-#define QQVGA_WIDTH 160
-#define QQVGA_HEIGHT 120
-
-/* Max Resolution supported by the driver */
-#define VID_MAX_WIDTH1280/* Largest width */
-#define VID_MAX_HEIGHT 720 /* Largest height */
-
-/* Mimimum requirement is 2x2 for DSS */
-#define VID_MIN_WIDTH2
-#define VID_MIN_HEIGHT 2
-
-/* 2048 x 2048 is max res supported by OMAP display controller */
-#define MAX_PIXELS_PER_LINE 2048
-
-#define VRFB_TX_TIMEOUT 1000
-#define VRFB_NUM_BUFS4
-
-/* Max buffer size tobe allocated during init */
-#define OMAP_VOUT_MAX_BUF_SIZE (VID_MAX_WIDTH*VID_MAX_HEIGHT*4)
-
static struct videobuf_queue_ops video_vbq_ops;
/* Variables configurable through module params*/
static u32 video1_numbuffers = 3;
@@ -172,49 +143,6 @@ const static struct v4l2_fmtdesc omap_formats[] = {
#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
/*
- * Allocate buffers
- */
-static unsigned long omap_vout_alloc_buffer(u32 buf_size, u32 *phys_addr)
-{
- u32 order, size;
- unsigned long virt_addr, addr;
-
- size = PAGE_ALIGN(buf_size);
- order = get_order(size);
- virt_addr = __get_free_pages(GFP_KERNEL | GFP_DMA, order);
- addr = virt_addr;
-
- if (virt_addr) {
- while (size 0) {
- SetPageReserved(virt_to_page(addr));
- addr += PAGE_SIZE;
- size -= PAGE_SIZE;
- }
- }
- *phys_addr = (u32) virt_to_phys((void *) virt_addr);
- return virt_addr;
-}
-
-/*
- * Free buffers
- */
-static void omap_vout_free_buffer(unsigned long virtaddr, u32 buf_size)
-{
- u32 order, size;
- unsigned long addr = virtaddr;
-
- size = PAGE_ALIGN(buf_size);
- order = get_order(size);
-
- while (size 0) {
- ClearPageReserved(virt_to_page(addr));
- addr += PAGE_SIZE;
- size -= PAGE_SIZE;
- }
- free_pages((unsigned long) virtaddr, order);
-}
-
-/*
* Function for allocating video buffers
*/
static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
@@ -369,43 +297,6 @@ static void omap_vout_release_vrfb(struct
omap_vout_device *vout)
}
/*
- * Return true if rotation is 90 or 270
- */
-static inline int rotate_90_or_270(const struct omap_vout_device *vout)
-{
- return (vout-rotation == dss_rotation_90_degree ||
- vout-rotation == dss_rotation_270_degree);
-}
-
-/*
- * Return true if rotation is enabled
- */
-static inline int rotation_enabled(const struct omap_vout_device *vout)
-{
- return vout-rotation || vout-mirror;
-}
-
-/*
- * Reverse the rotation degree if mirroring is enabled
- */
-static inline int calc_rotation(const struct omap_vout_device *vout)
-{
- if
RE: [PATCH v4 2/2] OMAP_VOUT: Create separate file for VRFB related API's
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Taneja, Archit
Sent: Friday, December 17, 2010 12:13 PM
To: linux-media@vger.kernel.org
Cc: linux-o...@vger.kernel.org; Taneja, Archit
Subject: [PATCH v4 2/2] OMAP_VOUT: Create separate file for VRFB related
API's
[Hiremath, Vaibhav] [Hiremath, Vaibhav] Thanks, Archit.
Tested-By Vaibhav Hiremath hvaib...@ti.com
Acked-By Vaibhav Hiremath hvaib...@ti.com
I will merge to my Arago repository and give pull request to Mauro.
Thanks,
Vaibhav
Introduce omap_vout_vrfb.c and omap_vout_vrfb.h, for all VRFB related
API's,
making OMAP_VOUT driver independent from VRFB. This is required for OMAP4
DSS,
since OMAP4 doesn't have VRFB block.
Added new enum vout_rotation_type and rotation_type member to
omapvideo_info,
this is initialized based on the arch type in omap_vout_probe. The
rotation_type
var is now used to choose between vrfb and non-vrfb calls.
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/Kconfig |2 +-
drivers/media/video/omap/Makefile |1 +
drivers/media/video/omap/omap_vout.c | 457 ++--
-
drivers/media/video/omap/omap_vout_vrfb.c | 390
drivers/media/video/omap/omap_vout_vrfb.h | 40 +++
drivers/media/video/omap/omap_voutdef.h | 16 +
6 files changed, 532 insertions(+), 374 deletions(-)
create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c
create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h
diff --git a/drivers/media/video/omap/Kconfig
b/drivers/media/video/omap/Kconfig
index e63233f..5f8abea 100644
--- a/drivers/media/video/omap/Kconfig
+++ b/drivers/media/video/omap/Kconfig
@@ -5,7 +5,7 @@ config VIDEO_OMAP2_VOUT
select VIDEOBUF_DMA_CONTIG
select OMAP2_DSS
select OMAP2_VRAM
- select OMAP2_VRFB
+ select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
default n
---help---
V4L2 Display driver support for OMAP2/3 based boards.
diff --git a/drivers/media/video/omap/Makefile
b/drivers/media/video/omap/Makefile
index b287880..bc47569 100644
--- a/drivers/media/video/omap/Makefile
+++ b/drivers/media/video/omap/Makefile
@@ -5,3 +5,4 @@
# OMAP2/3 Display driver
omap-vout-y := omap_vout.o omap_voutlib.o
obj-$(CONFIG_VIDEO_OMAP2_VOUT) += omap-vout.o
+obj-$(CONFIG_OMAP2_VRFB) += omap_vout_vrfb.o
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index e1df01c..e6c0fde 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -42,12 +42,9 @@
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
-#include plat/dma.h
-#include plat/vrfb.h
-#include plat/display.h
-
#include omap_voutlib.h
#include omap_voutdef.h
+#include omap_vout_vrfb.h
MODULE_AUTHOR(Texas Instruments);
MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
@@ -143,41 +140,6 @@ const static struct v4l2_fmtdesc omap_formats[] = {
#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
/*
- * Function for allocating video buffers
- */
-static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
- unsigned int *count, int startindex)
-{
- int i, j;
-
- for (i = 0; i *count; i++) {
- if (!vout-smsshado_virt_addr[i]) {
- vout-smsshado_virt_addr[i] =
- omap_vout_alloc_buffer(vout-smsshado_size,
- vout-smsshado_phy_addr[i]);
- }
- if (!vout-smsshado_virt_addr[i] startindex != -1) {
- if (V4L2_MEMORY_MMAP == vout-memory i = startindex)
- break;
- }
- if (!vout-smsshado_virt_addr[i]) {
- for (j = 0; j i; j++) {
- omap_vout_free_buffer(
- vout-smsshado_virt_addr[j],
- vout-smsshado_size);
- vout-smsshado_virt_addr[j] = 0;
- vout-smsshado_phy_addr[j] = 0;
- }
- *count = 0;
- return -ENOMEM;
- }
- memset((void *) vout-smsshado_virt_addr[i], 0,
- vout-smsshado_size);
- }
- return 0;
-}
-
-/*
* Try format
*/
static int omap_vout_try_format(struct v4l2_pix_format *pix)
@@ -270,36 +232,9 @@ static u32 omap_vout_uservirt_to_phys(u32 virtp)
}
/*
- * Wakes up the application once the DMA transfer to VRFB space is
completed.
- */
-static void omap_vout_vrfb_dma_tx_callback(int lch, u16 ch_status, void
*data)
-{
- struct vid_vrfb_dma *t = (struct vid_vrfb_dma *)
[PATCH] media: fsl-viu: fix support for streaming with mmap method
Streaming using mmap didn't work in the VIU driver. We need to start/stop DMA in streamon/streamoff and free the buffers on release. Add appropriate driver extension now. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/media/video/fsl-viu.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/fsl-viu.c b/drivers/media/video/fsl-viu.c index c9eb161..483a5ed 100644 --- a/drivers/media/video/fsl-viu.c +++ b/drivers/media/video/fsl-viu.c @@ -917,6 +917,8 @@ static int vidioc_streamon(struct file *file, void *priv, enum v4l2_buf_type i) if (fh-type != i) return -EINVAL; + viu_start_dma(fh-dev); + return videobuf_streamon(fh-vb_vidq); } @@ -929,6 +931,8 @@ static int vidioc_streamoff(struct file *file, void *priv, enum v4l2_buf_type i) if (fh-type != i) return -EINVAL; + viu_stop_dma(fh-dev); + return videobuf_streamoff(fh-vb_vidq); } @@ -1350,6 +1354,7 @@ static int viu_release(struct file *file) viu_stop_dma(dev); videobuf_stop(fh-vb_vidq); + videobuf_mmap_free(fh-vb_vidq); kfree(fh); -- 1.7.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 v7 0/7] FM V4L2 drivers for WL128x
From: Manjunatha Halli manjunatha_ha...@ti.com Mauro and the list, This is the v7 version of the TI WL128x FM V4L2 drivers patchset. This introduces wl128x folder under the drivers/media/radio which cater to FM core on Texas Instrument's WL128x (also compatible with WL127x) WiLink chipsets. WL128x's FM can work in either Rx or Tx mode, and V4L2 interfaces are provided for both. ** patch description ** Texas Instrument's WL128x chipset packs BT, FM, GPS and WLAN in a single die with BT, FM and GPS being interfaced over a single UART. This driver works on top of the shared transport line discipline driver. This driver can also be made use for the WL127x version of the chip which packs BT, FM and WLAN only. Comments on the last version of the patches have been taken care, such as, - Now using the v4l2 control framework to support all the v4l2 controls. - re-arranged the error handling in IRQ handlers. Thanks Regards, Manjunatha Halli Manjunatha Halli (7): drivers:media:radio: wl128x: fmdrv common header file drivers:media:radio: wl128x: fmdrv_v4l2 sources drivers:media:radio: wl128x: fmdrv_common sources drivers:media:radio: wl128x: FM driver RX sources drivers:media:radio: wl128x: FM driver TX sources drivers:media:radio: wl128x: Kconfig Makefile added for wl128x driver drivers:media:radio: Update Kconfig and Makefile for supporting wl128x drivers/media/radio/Kconfig |3 + drivers/media/radio/Makefile |1 + drivers/media/radio/wl128x/Kconfig| 17 + drivers/media/radio/wl128x/Makefile |6 + drivers/media/radio/wl128x/fmdrv.h| 245 drivers/media/radio/wl128x/fmdrv_common.c | 1970 + drivers/media/radio/wl128x/fmdrv_common.h | 402 ++ drivers/media/radio/wl128x/fmdrv_rx.c | 904 + drivers/media/radio/wl128x/fmdrv_rx.h | 59 + drivers/media/radio/wl128x/fmdrv_tx.c | 438 +++ drivers/media/radio/wl128x/fmdrv_tx.h | 37 + drivers/media/radio/wl128x/fmdrv_v4l2.c | 588 + drivers/media/radio/wl128x/fmdrv_v4l2.h | 33 + 13 files changed, 4703 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/wl128x/Kconfig create mode 100644 drivers/media/radio/wl128x/Makefile create mode 100644 drivers/media/radio/wl128x/fmdrv.h create mode 100644 drivers/media/radio/wl128x/fmdrv_common.c create mode 100644 drivers/media/radio/wl128x/fmdrv_common.h create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.c create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.h create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.c create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.h create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.c create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.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 v7 7/7] drivers:media:radio: Update Kconfig and Makefile for supporting wl128x
From: Manjunatha Halli manjunatha_ha...@ti.com Signed-off-by: Manjunatha Halli manjunatha_ha...@ti.com --- drivers/media/radio/Kconfig |3 +++ drivers/media/radio/Makefile |1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 83567b8..4529bc7 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -452,4 +452,7 @@ config RADIO_TIMBERDALE found behind the Timberdale FPGA on the Russellville board. Enabling this driver will automatically select the DSP and tuner. +# TI's ST based wl128x FM radio +source drivers/media/radio/wl128x/Kconfig + endif # RADIO_ADAPTERS diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile index f615583..b71f448 100644 --- a/drivers/media/radio/Makefile +++ b/drivers/media/radio/Makefile @@ -26,5 +26,6 @@ obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o obj-$(CONFIG_RADIO_TEF6862) += tef6862.o obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o +obj-$(CONFIG_RADIO_WL128X) += wl128x/ EXTRA_CFLAGS += -Isound -- 1.5.6.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 v7 4/7] drivers:media:radio: wl128x: FM driver RX sources
From: Manjunatha Halli manjunatha_ha...@ti.com
This has implementation for FM RX functionality.
It communicates with FM V4l2 module and FM common module.
Signed-off-by: Manjunatha Halli manjunatha_ha...@ti.com
---
drivers/media/radio/wl128x/fmdrv_rx.c | 904 +
drivers/media/radio/wl128x/fmdrv_rx.h | 59 +++
2 files changed, 963 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.c
create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.h
diff --git a/drivers/media/radio/wl128x/fmdrv_rx.c
b/drivers/media/radio/wl128x/fmdrv_rx.c
new file mode 100644
index 000..c0a29e7
--- /dev/null
+++ b/drivers/media/radio/wl128x/fmdrv_rx.c
@@ -0,0 +1,904 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ * This sub-module of FM driver implements FM RX functionality.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Raja Mani raja_m...@ti.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include fmdrv.h
+#include fmdrv_common.h
+#include fmdrv_rx.h
+
+void fm_rx_reset_rds_cache(struct fmdrv_ops *fmdev)
+{
+ fmdev-rx.rds.flag = FM_RDS_DISABLE;
+ fmdev-rx.rds.last_block_index = 0;
+ fmdev-rx.rds.wr_index = 0;
+ fmdev-rx.rds.rd_index = 0;
+
+ if (fmdev-rx.af_mode == FM_RX_RDS_AF_SWITCH_MODE_ON)
+ fmdev-irq_info.mask |= FM_LEV_EVENT;
+}
+
+void fm_rx_reset_curr_station_info(struct fmdrv_ops *fmdev)
+{
+ fmdev-rx.cur_station_info.picode = FM_NO_PI_CODE;
+ fmdev-rx.cur_station_info.no_of_items_in_afcache = 0;
+ fmdev-rx.cur_station_info.af_list_max = 0;
+}
+
+int fm_rx_set_frequency(struct fmdrv_ops *fmdev, unsigned int freq_to_set)
+{
+ unsigned long timeleft;
+ unsigned short payload, curr_frq, frq_index, intr_flag;
+ unsigned int curr_frq_in_khz;
+ int ret, resp_len;
+
+ if (fmdev-curr_fmmode != FM_MODE_RX)
+ return -EPERM;
+
+ if (freq_to_set fmdev-rx.region.bottom_frequency ||
+ freq_to_set fmdev-rx.region.top_frequency) {
+ pr_err((fmdrv): Invalid frequency %d\n, freq_to_set);
+ return -EINVAL;
+ }
+
+ /* Set audio enable */
+ payload = FM_RX_FM_AUDIO_ENABLE_I2S_AND_ANALOG;
+
+ ret = fmc_send_cmd(fmdev, AUDIO_ENABLE_SET, REG_WR, payload,
+ sizeof(payload), NULL, NULL);
+ if (ret 0)
+ return ret;
+
+ /* Set hilo to automatic selection */
+ payload = FM_RX_IFFREQ_HILO_AUTOMATIC;
+ ret = fmc_send_cmd(fmdev, HILO_SET, REG_WR, payload,
+ sizeof(payload), NULL, NULL);
+ if (ret 0)
+ return ret;
+
+ /* Calculate frequency index to write */
+ frq_index = (freq_to_set - fmdev-rx.region.bottom_frequency) /
+ FM_FREQ_MUL;
+
+ /* Set frequency index */
+ payload = frq_index;
+ ret = fmc_send_cmd(fmdev, FREQ_SET, REG_WR, payload,
+ sizeof(payload), NULL, NULL);
+ if (ret 0)
+ return ret;
+
+ /* Read flags - just to clear any pending interrupts if we had */
+ ret = fmc_send_cmd(fmdev, FLAG_GET, REG_RD, NULL, 2,
+ NULL, NULL);
+ if (ret 0)
+ return ret;
+
+ /* Enable FR, BL interrupts */
+ intr_flag = fmdev-irq_info.mask;
+ fmdev-irq_info.mask = (FM_FR_EVENT | FM_BL_EVENT);
+ payload = fmdev-irq_info.mask;
+ ret = fmc_send_cmd(fmdev, INT_MASK_SET, REG_WR, payload,
+ sizeof(payload), NULL, NULL);
+ if (ret 0)
+ return ret;
+
+ /* Start tune */
+ payload = FM_TUNER_PRESET_MODE;
+ ret = fmc_send_cmd(fmdev, TUNER_MODE_SET, REG_WR, payload,
+ sizeof(payload), NULL, NULL);
+ if (ret 0)
+ return ret;
+
+ /* Wait for tune ended interrupt */
+ init_completion(fmdev-maintask_completion);
+ timeleft = wait_for_completion_timeout(fmdev-maintask_completion,
+ FM_DRV_TX_TIMEOUT);
+ if (!timeleft) {
+ pr_err((fmdrv): Timeout(%d sec),didn't get tune ended int\n,
+ jiffies_to_msecs(FM_DRV_TX_TIMEOUT) / 1000);
+ return -ETIMEDOUT;
+
[PATCH v7 5/7] drivers:media:radio: wl128x: FM driver TX sources
From: Manjunatha Halli manjunatha_ha...@ti.com
This has implementation for FM TX functionality.
It communicates with FM V4l2 module and FM common module.
Signed-off-by: Manjunatha Halli manjunatha_ha...@ti.com
---
drivers/media/radio/wl128x/fmdrv_tx.c | 438 +
drivers/media/radio/wl128x/fmdrv_tx.h | 37 +++
2 files changed, 475 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.c
create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.h
diff --git a/drivers/media/radio/wl128x/fmdrv_tx.c
b/drivers/media/radio/wl128x/fmdrv_tx.c
new file mode 100644
index 000..ca8769d
--- /dev/null
+++ b/drivers/media/radio/wl128x/fmdrv_tx.c
@@ -0,0 +1,438 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ * This sub-module of FM driver implements FM TX functionality.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include linux/delay.h
+#include fmdrv.h
+#include fmdrv_common.h
+#include fmdrv_tx.h
+
+int fm_tx_set_stereo_mono(struct fmdrv_ops *fmdev, unsigned short mode)
+{
+ unsigned short payload;
+ int ret = 0;
+
+ if (fmdev-curr_fmmode != FM_MODE_TX)
+ return -EPERM;
+
+ if (fmdev-tx_data.aud_mode == mode)
+ return ret;
+
+ pr_debug(stereo mode: %d\n, mode);
+
+ /* Set Stereo/Mono mode */
+ payload = (1 - mode);
+ ret = fmc_send_cmd(fmdev, MONO_SET, REG_WR, payload,
+ sizeof(payload), NULL, NULL);
+ if (ret 0)
+ return ret;
+
+ fmdev-tx_data.aud_mode = mode;
+
+ return ret;
+}
+
+static int __set_rds_text(struct fmdrv_ops *fmdev, unsigned char *rds_text)
+{
+ unsigned short payload;
+ int ret;
+
+ ret = fmc_send_cmd(fmdev, RDS_DATA_SET, REG_WR, rds_text,
+ strlen(rds_text), NULL, NULL);
+ if (ret 0)
+ return ret;
+
+ /* Scroll mode */
+ payload = (unsigned short)0x1;
+ ret = fmc_send_cmd(fmdev, DISPLAY_MODE, REG_WR, payload,
+ sizeof(payload), NULL, NULL);
+ if (ret 0)
+ return ret;
+
+ return 0;
+}
+
+static int __set_rds_data_mode(struct fmdrv_ops *fmdev, unsigned char mode)
+{
+ unsigned short payload;
+ int ret;
+
+ /* Setting unique PI TODO: how unique? */
+ payload = (unsigned short)0xcafe;
+ ret = fmc_send_cmd(fmdev, PI_SET, REG_WR, payload,
+ sizeof(payload), NULL, NULL);
+ if (ret 0)
+ return ret;
+
+ /* Set decoder id */
+ payload = (unsigned short)0xa;
+ ret = fmc_send_cmd(fmdev, DI_SET, REG_WR, payload,
+ sizeof(payload), NULL, NULL);
+ if (ret 0)
+ return ret;
+
+ /* TODO: RDS_MODE_GET? */
+ return 0;
+}
+
+static int __set_rds_len(struct fmdrv_ops *fmdev, unsigned char type,
+ unsigned short len)
+{
+ unsigned short payload;
+ int ret;
+
+ len |= type 8;
+ payload = len;
+ ret = fmc_send_cmd(fmdev, RDS_CONFIG_DATA_SET, REG_WR, payload,
+ sizeof(payload), NULL, NULL);
+ if (ret 0)
+ return ret;
+
+ /* TODO: LENGTH_GET? */
+ return 0;
+}
+
+int fm_tx_set_rds_mode(struct fmdrv_ops *fmdev, unsigned char rds_en_dis)
+{
+ unsigned short payload;
+ int ret;
+ unsigned char rds_text[] = Zoom2\n;
+
+ if (fmdev-curr_fmmode != FM_MODE_TX)
+ return -EPERM;
+
+ pr_debug(rds_en_dis:%d(E:%d, D:%d)\n, rds_en_dis,
+ FM_RDS_ENABLE, FM_RDS_DISABLE);
+
+ if (rds_en_dis == FM_RDS_ENABLE) {
+ /* Set RDS length */
+ __set_rds_len(fmdev, 0, strlen(rds_text));
+
+ /* Set RDS text */
+ __set_rds_text(fmdev, rds_text);
+
+ /* Set RDS mode */
+ __set_rds_data_mode(fmdev, 0x0);
+ }
+
+ /* Send command to enable RDS */
+ if (rds_en_dis == FM_RDS_ENABLE)
+ payload = 0x01;
+ else
+ payload = 0x00;
+
+ ret = fmc_send_cmd(fmdev, RDS_DATA_ENB, REG_WR, payload,
+ sizeof(payload), NULL, NULL);
+ if (ret 0)
+ return
[PATCH v7 1/7] drivers:media:radio: wl128x: fmdrv common header file
From: Manjunatha Halli manjunatha_ha...@ti.com
These are common headers used in FM submodules (FM V4L2,
FM common, FM Rx,and FM TX).
Signed-off-by: Manjunatha Halli manjunatha_ha...@ti.com
---
drivers/media/radio/wl128x/fmdrv.h | 245
1 files changed, 245 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/wl128x/fmdrv.h
diff --git a/drivers/media/radio/wl128x/fmdrv.h
b/drivers/media/radio/wl128x/fmdrv.h
new file mode 100644
index 000..96106b1
--- /dev/null
+++ b/drivers/media/radio/wl128x/fmdrv.h
@@ -0,0 +1,245 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ *
+ * Common header for all FM driver sub-modules.
+ *
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef _FM_DRV_H
+#define _FM_DRV_H
+
+#include linux/skbuff.h
+#include linux/interrupt.h
+#include sound/core.h
+#include sound/initval.h
+#include linux/timer.h
+#include linux/version.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
+
+#define FM_DRV_VERSION0.01
+/* Should match with FM_DRV_VERSION */
+#define FM_DRV_RADIO_VERSION KERNEL_VERSION(0, 0, 1)
+#define FM_DRV_NAME ti_fmdrv
+#define FM_DRV_CARD_SHORT_NAMETI FM Radio
+#define FM_DRV_CARD_LONG_NAME Texas Instruments FM Radio
+
+/* Flag info */
+#define FM_INTTASK_RUNNING0
+#define FM_INTTASK_SCHEDULE_PENDING 1
+#define FM_FIRMWARE_DW_INPROGRESS 2
+#define FM_CORE_READY 3
+#define FM_CORE_TRANSPORT_READY 4
+#define FM_AF_SWITCH_INPROGRESS 5
+#define FM_CORE_TX_XMITING 6
+
+#define FM_TUNE_COMPLETE 0x1
+#define FM_BAND_LIMIT0x2
+
+#define FM_DRV_TX_TIMEOUT (5*HZ) /* 5 seconds */
+#define FM_DRV_RX_SEEK_TIMEOUT (20*HZ) /* 20 seconds */
+
+#define NO_OF_ENTRIES_IN_ARRAY(array) (sizeof(array) / sizeof(array[0]))
+
+enum {
+ FM_MODE_OFF,
+ FM_MODE_TX,
+ FM_MODE_RX,
+ FM_MODE_ENTRY_MAX
+};
+
+#define FM_RX_RDS_INFO_FIELD_MAX 8 /* 4 Group * 2 Bytes */
+
+/*
+ * define private CIDs for V4L2
+ */
+#define V4L2_CID_CHANNEL_SPACING (V4L2_CID_PRIVATE_BASE + 0)
+
+/* RX RDS data format */
+struct fm_rdsdata_format {
+ union {
+ struct {
+ unsigned char rdsbuff[FM_RX_RDS_INFO_FIELD_MAX];
+ } groupdatabuff;
+ struct {
+ unsigned short pidata;
+ unsigned char block_b_byte1;
+ unsigned char block_b_byte2;
+ unsigned char block_c_byte1;
+ unsigned char block_c_byte2;
+ unsigned char block_d_byte1;
+ unsigned char block_d_byte2;
+ } groupgeneral;
+ struct {
+ unsigned short pidata;
+ unsigned char block_b_byte1;
+ unsigned char block_b_byte2;
+ unsigned char firstaf;
+ unsigned char secondaf;
+ unsigned char firstpsbyte;
+ unsigned char secondpsbyte;
+ } group0A;
+
+ struct {
+ unsigned short pidata;
+ unsigned char block_b_byte1;
+ unsigned char block_b_byte2;
+ unsigned short pidata2;
+ unsigned char firstpsbyte;
+ unsigned char secondpsbyte;
+ } group0B;
+ } rdsdata;
+};
+
+/* FM region (Europe/US, Japan) info */
+struct region_info {
+ unsigned int channel_spacing;
+ unsigned int bottom_frequency;
+ unsigned int top_frequency;
+ unsigned char region_index;
+};
+
+typedef void (*int_handler_prototype) (void *);
+
+/* FM Interrupt processing related info */
+struct fm_irq {
+ unsigned char stage_index;
+ unsigned short flag;/* FM interrupt flag */
+ unsigned short mask;/* FM interrupt mask */
+ /* Interrupt process timeout handler */
+ struct timer_list int_timeout_timer;
+ unsigned char irq_service_timeout_retry;
+ int_handler_prototype *fm_int_handlers;
+};
+
+/* RDS info */
+struct fm_rds {
+
[PATCH v7 2/7] drivers:media:radio: wl128x: fmdrv_v4l2 sources
From: Manjunatha Halli manjunatha_ha...@ti.com
This module interfaces V4L2 subsystem and FM common module.
It registers itself with V4L2 as Radio module.
Signed-off-by: Manjunatha Halli manjunatha_ha...@ti.com
---
drivers/media/radio/wl128x/fmdrv_v4l2.c | 588 +++
drivers/media/radio/wl128x/fmdrv_v4l2.h | 33 ++
2 files changed, 621 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.c
create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.h
diff --git a/drivers/media/radio/wl128x/fmdrv_v4l2.c
b/drivers/media/radio/wl128x/fmdrv_v4l2.c
new file mode 100644
index 000..623102f
--- /dev/null
+++ b/drivers/media/radio/wl128x/fmdrv_v4l2.c
@@ -0,0 +1,588 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ * This file provides interfaces to V4L2 subsystem.
+ *
+ * This module registers with V4L2 subsystem as Radio
+ * data system interface (/dev/radio). During the registration,
+ * it will expose two set of function pointers.
+ *
+ *1) File operation related API (open, close, read, write, poll...etc).
+ *2) Set of V4L2 IOCTL complaint API.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Raja Mani raja_m...@ti.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include fmdrv.h
+#include fmdrv_v4l2.h
+#include fmdrv_common.h
+#include fmdrv_rx.h
+#include fmdrv_tx.h
+
+static struct video_device *gradio_dev;
+static unsigned char radio_disconnected;
+
+/* -- V4L2 RADIO (/dev/radioX) device file operation interfaces --- */
+
+/* Read RX RDS data */
+static ssize_t fm_v4l2_fops_read(struct file *file, char __user * buf,
+ size_t count, loff_t *ppos)
+{
+ unsigned char rds_mode;
+ int ret;
+ struct fmdrv_ops *fmdev;
+
+ fmdev = video_drvdata(file);
+
+ if (!radio_disconnected) {
+ pr_err((fmdrv): FM device is already disconnected\n);
+ return -EIO;
+ }
+
+ /* Turn on RDS mode , if it is disabled */
+ ret = fm_rx_get_rds_mode(fmdev, rds_mode);
+ if (ret 0) {
+ pr_err((fmdrv): Unable to read current rds mode\n);
+ return ret;
+ }
+
+ if (rds_mode == FM_RDS_DISABLE) {
+ ret = fmc_set_rds_mode(fmdev, FM_RDS_ENABLE);
+ if (ret 0) {
+ pr_err((fmdrv): Failed to enable rds mode\n);
+ return ret;
+ }
+ }
+
+ /* Copy RDS data from internal buffer to user buffer */
+ ret = fmc_transfer_rds_from_internal_buff(fmdev, file, buf, count);
+
+ return ret;
+}
+
+/* Write TX RDS data */
+static ssize_t fm_v4l2_fops_write(struct file *file, const char __user * buf,
+ size_t count, loff_t *ppos)
+{
+ struct tx_rds rds;
+ int ret;
+ struct fmdrv_ops *fmdev;
+
+ ret = copy_from_user(rds, buf, sizeof(rds));
+ pr_debug((fmdrv): (%d)type: %d, text %s, af %d\n,
+ ret, rds.text_type, rds.text, rds.af_freq);
+
+ fmdev = video_drvdata(file);
+ fm_tx_set_radio_text(fmdev, rds.text, rds.text_type);
+ fm_tx_set_af(fmdev, rds.af_freq);
+
+ return 0;
+}
+
+static unsigned int fm_v4l2_fops_poll(struct file *file,
+ struct poll_table_struct *pts)
+{
+ int ret;
+ struct fmdrv_ops *fmdev;
+
+ fmdev = video_drvdata(file);
+ ret = fmc_is_rds_data_available(fmdev, file, pts);
+ if (ret 0)
+ return POLLIN | POLLRDNORM;
+
+ return 0;
+}
+
+/*
+ * Handle open request for /dev/radioX device.
+ * Start with FM RX mode as default.
+ */
+static int fm_v4l2_fops_open(struct file *file)
+{
+ int ret;
+ struct fmdrv_ops *fmdev = NULL;
+
+ /* Don't allow multiple open */
+ if (radio_disconnected) {
+ pr_err((fmdrv): FM device is already opened\n);
+ return -EBUSY;
+ }
+
+ fmdev = video_drvdata(file);
+
+ ret = fmc_prepare(fmdev);
+ if (ret 0) {
+ pr_err((fmdrv): Unable to prepare FM CORE\n);
+ return ret;
+ }
+
+ pr_debug((fmdrv): Load FM RX firmware..\n);
+
+ ret = fmc_set_mode(fmdev, FM_MODE_RX);
+ if (ret 0) {
+
[PATCH v7 6/7] drivers:media:radio: wl128x: Kconfig Makefile added for wl128x driver
From: Manjunatha Halli manjunatha_ha...@ti.com Signed-off-by: Manjunatha Halli manjunatha_ha...@ti.com --- drivers/media/radio/wl128x/Kconfig | 17 + drivers/media/radio/wl128x/Makefile |6 ++ 2 files changed, 23 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/wl128x/Kconfig create mode 100644 drivers/media/radio/wl128x/Makefile diff --git a/drivers/media/radio/wl128x/Kconfig b/drivers/media/radio/wl128x/Kconfig new file mode 100644 index 000..749f67b --- /dev/null +++ b/drivers/media/radio/wl128x/Kconfig @@ -0,0 +1,17 @@ +# +# TI's wl128x FM driver based on TI's ST driver. +# +menu Texas Instruments WL128x FM driver (ST based) +config RADIO_WL128X + tristate Texas Instruments WL128x FM Radio + depends on VIDEO_V4L2 RFKILL + select TI_ST + help + Choose Y here if you have this FM radio chip. + + In order to control your radio card, you will need to use programs + that are compatible with the Video For Linux 2 API. Information on + this API and pointers to v4l2 programs may be found at + file:Documentation/video4linux/API.html. + +endmenu diff --git a/drivers/media/radio/wl128x/Makefile b/drivers/media/radio/wl128x/Makefile new file mode 100644 index 000..32a0ead --- /dev/null +++ b/drivers/media/radio/wl128x/Makefile @@ -0,0 +1,6 @@ +# +# Makefile for TI's shared transport driver based wl128x +# FM radio. +# +obj-$(CONFIG_RADIO_WL128X) += fm_drv.o +fm_drv-objs:= fmdrv_common.o fmdrv_rx.o fmdrv_tx.o fmdrv_v4l2.o -- 1.5.6.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
TeVii S470 dvb-s2 issues - 2nd try ,)
Hello linux-media people! I have to problems with my dvb card (TeVii S470). I already filed 2 bug reports some time ago, but no one seems to have noticed/read them, so i'm trying it here now. If you need a full dmesg, then please take a look at https://bugzilla.kernel.org/attachment.cgi?id=40552 1) TeVii S470 dvbs-2 card (cx23885) is not usable after pm-suspend/resume https://bugzilla.kernel.org/show_bug.cgi?id=16467 [dmesg output] [4.581930] IR NEC protocol handler initialized [4.623358] cx23885 driver version 0.0.2 loaded [4.623391] cx23885 :04:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [4.623802] CORE cx23885[0]: subsystem: d470:9022, board: TeVii S470 [card=15,autodetected] [4.653935] IR RC5(x) protocol handler initialized [4.751392] cx23885_dvb_register() allocating 1 frontend(s) [4.751395] cx23885[0]: cx23885 based dvb card [4.828732] IR RC6 protocol handler initialized [4.864909] DS3000 chip version: 0.192 attached. [4.864912] DVB: registering new adapter (cx23885[0]) [4.864915] DVB: registering adapter 0 frontend 0 (Montage Technology DS3000/TS2020)... [4.875357] IR JVC protocol handler initialized [4.892265] TeVii S470 MAC= 00:18:bd:5b:2d:bc [4.892270] cx23885_dev_checkrevision() Hardware revision = 0xb0 [4.892276] cx23885[0]/0: found at :04:00.0, rev: 2, irq: 16, latency: 0, mmio: 0xfea0 [4.892282] cx23885 :04:00.0: setting latency timer to 64 [4.892353] cx23885 :04:00.0: irq 42 for MSI/MSI-X [5.108173] IR Sony protocol handler initialized [5.145513] lirc_dev: IR Remote Control driver registered, major 251 [5.155400] IR LIRC bridge handler initialized [5.584627] vboxdrv: Found 4 processor cores. [5.584882] VBoxDrv: dbg - g_abExecMemory=a0093480 [5.584929] vboxdrv: fAsync=0 offMin=0x40b offMax=0x1c28 [5.584985] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'. [5.584987] vboxdrv: Successfully loaded version 3.2.12 (interface 0x00140001). [6.259015] EXT4-fs (sdc1): mounted filesystem without journal. Opts: (null) [ 14.791291] EXT4-fs (sdc1): mounted filesystem without journal. Opts: (null) [ 22.876565] EXT4-fs (sda5): re-mounted. Opts: (null) [ 23.324249] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null) [ 23.436401] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) [ 25.240374] Adding 4000148k swap on /dev/mapper/crypto_swap20xx. Priority:-1 extents:1 across:4000148k [ 25.519058] atl1 :02:00.0: irq 43 for MSI/MSI-X [ 25.519163] atl1 :02:00.0: eth0 link is up 100 Mbps full duplex [ 43.110030] start_kdeinit (1551): /proc/1551/oom_adj is deprecated, please use /proc/1551/oom_score_adj instead. [/dmesg output] [dmesg after suspend/resume with cx23885.debug=1] [ 239.053885] ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)... [ 239.053890] ds3000_firmware_ondemand: Waiting for firmware upload(2)... [ 240.901976] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) [ 240.914973] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) [ 248.242966] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) [ 248.255975] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) [ 256.403969] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) [ 256.416980] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) [ 263.563968] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) [ 263.576977] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) [ 278.125971] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) [ 278.138974] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) [ 278.440704] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x12) [ 305.437940] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) [ 305.451975] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) [ 305.758569] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x12) [ 881.880964] cx23885 driver version 0.0.2 loaded [ 881.880997] cx23885 :04:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 881.881218] cx23885[0]/0: cx23885_dev_setup() Memory configured for PCIe bridge type 885 [ 881.881220] cx23885[0]/0: cx23885_init_tsport(portno=1) [ 881.881892] CORE cx23885[0]: subsystem: d470:9022, board: TeVii S470 [card=15,autodetected] [ 881.881893] cx23885[0]/0: cx23885_pci_quirks() [ 881.881897] cx23885[0]/0: cx23885_dev_setup() tuner_type = 0x0 tuner_addr = 0x0 [ 881.881899] cx23885[0]/0: cx23885_dev_setup() radio_type = 0x0 radio_addr = 0x0 [ 881.881900] cx23885[0]/0: cx23885_reset() [ 881.981923] cx23885[0]/0: cx23885_sram_channel_setup() Configuring channel [VID A] [ 881.981935] cx23885[0]/0: cx23885_sram_channel_setup() Erasing
Re: [PATCH 09/10] MCDE: Add build files and bus
On 12/17/2010 12:22 PM, Arnd Bergmann wrote: * When I talk about a bus, I mean 'struct bus_type', which identifies all devices with a uniform bus interface to their parent device (think: PCI, USB, I2C). You seem to think of a bus as a specific instance of that bus type, i.e. the device that is the parent of all the connected devices. If you have only one instance of a bus in any system, and they are all using the same driver, do not add a bus_type for it. A good reason to add a bus_type would be e.g. if the display driver uses interfaces to the dss that are common among multiple dss drivers from different vendors, but the actual display drivers are identical. This does not seem to be the case. Correct, I refer to the device, not type or driver. I used a bus type since it allowed me to setup a default implementation for each driver callback. So all drivers get generic implementation by default, and override when that is not enough. Meybe you have a better way of getting the same behavior. One solution that I like is to write a module with the common code as a library, exporting all the default actions. The specific drivers can then fill their operations structure by listing the defaults or by providing their own functions to replace them, which in turn can call the default functions. This is e.g. what libata does. Will do. We are now taking a step back and start all over. We were almost as fresh on this HW block as you are now when we started implementing the driver earlier this year. I think all of us benefit from now having a better understanding of customer requirements and the HW itself, there are some nice quirks ;). Anyway, we will restart the patches and RFC only the MCDE HW part of the driver, implementing basic fb support for one display board as you suggested initially. It's a nice step towards making the patches easier to review and give us some time to prepare the DSS stuff. That remake was done today, so I think the patch will be sent out soon. (I'm going on vacation for 3 weeks btw). Ok, sounds great! I'm also starting a 3 week vacation, but will be at the Linaro sprint in Dallas. My feeling now, after understanding about it some more, is that it would actually be better to start with a KMS implementation instead of a classic frame buffer. Ideally you wouldn't even need the frame buffer driver or the multiplexing between the two then, but still get all the benefits from the new KMS infrastructure. I will look at it, we might still post a fb-mcde_hw first though, since it's so little work. DSS give access to all display devices probed on the virtual mcde dss bus, or platform bus with specific type of devices if you like. All calls to DSS operate on a display device, like create an overlay(=framebuffer), request an update, set power mode, etc. All calls to DSS related to display itself and not only framebuffer scanout, will be passed on to the display driver of the display device in question. All calls DSS only related to overlays, like buffer pointers, position, rotation etc is handled directly by DSS calling mcde_hw. You could see mcde_hw as a physical level driver and mcde_dss closer to a logical driver, delegating display specific decisions to the display driver. Another analogy is mcde_hw is host driver and display drivers are client device drivers. And DSS is a collection of logic to manage the interaction between host and client devices. The way you describe it, I would picture it differently: +--+ ++-+-+ +---+ | mcde_hw | | fb | kms | v4l | | displ | ++--+ | HW |mcde_dss | ++--+ In this model, the dss is the core module that everything else links to. The hw driver talks to the actual hardware and to the dss. The three front-ends only talk to the dss, but not to the individual display drivers or to the hw code directly (i.e. they don't use their exported symbols or internal data structures. The display drivers only talk to the dss, but not to the front-ends or the hw drivers. Would this be a correct representation of your modules? Hmm, mcde_hw does not link to dss. It should be FB-DSS-Display driver-MCDE_HW-HW IO (+ DSS-MCDE_HW). My picture is how code should be used. Anything else you find in code is a violation of that layering. I don't think it makes any sense to have the DSS sit on top of the display drivers, since that means it has to know about all of them and loading the DSS module would implicitly have to load all the display modules below it, even for the displays that are not present. DSS does not have a static dependency on display drivers. DSS is just a convenience library for handling the correct display driver call sequences, instead of each user (fbdev/KMS/V4L2) having to duplicate this code. Moreover, I don't yet see the
Re: [PATCH] [media] s5p-fimc: fix main scaler SFRs depends on FIMC version
On Fri, Dec 17, 2010 at 4:43 PM, Hyunwoong Kim khw0178@samsung.com wrote:
The main scaler has four SFRs for main scaler ratio depends on FIMC version.
FIMC 4.x has only two SFRs and FIMC 5.x has four SFRs for main scaler.
Those are MainHorRatio, MainHorRatio_ext, MainVerRatio and MainverRatio_ext.
The FIMC 5.x has 15 bit resolution for scaling ratio as below.
{MainHorRatio,MainHorRatio_ext} = {[14:6],[5:0]}.
{MainVerRatio,MainVerRatio_ext} = {[14:6],[5:0]}.
MainHorRatio = CISCCTRL[24:16], MainHorRatio_ext = CIEXTEN[15:10]
MainVerRatio = CISCCTRL[8:0], MainVerRatio_ext = CIEXTEN[5:0]
This patch supports FIMC 4.x and FIMC 5.x using
platform_device_id::driver_data.
Signed-off-by: Hyunwoong Kim khw0178@samsung.com
Reviewed-by: Jonghun Han jonghun@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 7 +++-
drivers/media/video/s5p-fimc/fimc-core.c | 21 ++--
drivers/media/video/s5p-fimc/fimc-core.h | 5 ++-
drivers/media/video/s5p-fimc/fimc-reg.c | 48 --
drivers/media/video/s5p-fimc/regs-fimc.h | 10 +-
5 files changed, 81 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index b216530..ca48e02 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -208,6 +208,7 @@ static int start_streaming(struct vb2_queue *q)
struct fimc_ctx *ctx = q-drv_priv;
struct fimc_dev *fimc = ctx-fimc_dev;
struct s3c_fimc_isp_info *isp_info;
+ struct samsung_fimc_variant *variant = ctx-fimc_dev-variant;
int ret;
ret = v4l2_subdev_call(fimc-vid_cap.sd, video, s_stream, 1);
@@ -230,7 +231,11 @@ static int start_streaming(struct vb2_queue *q)
return ret;
}
fimc_hw_set_input_path(ctx);
- fimc_hw_set_scaler(ctx);
+ fimc_hw_set_prescaler(ctx);
+ if (!variant-has_mainscaler_ext)
+ fimc_hw_set_mainscaler(ctx);
+ else
+ fimc_hw_set_mainscaler_ext(ctx);
It's just personal preference, I don't like the negative variable check,
how about this?
if (variant-has_mainscaler_ext)
fimc_hw_set_mainscaler_ext(ctx);
else
fimc_hw_set_mainscaler(ctx);
fimc_hw_set_target_format(ctx);
fimc_hw_set_rotation(ctx);
fimc_hw_set_effect(ctx);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 7f56987..3cfa4b6 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -246,6 +246,7 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx)
struct fimc_scaler *sc = ctx-scaler;
struct fimc_frame *s_frame = ctx-s_frame;
struct fimc_frame *d_frame = ctx-d_frame;
+ struct samsung_fimc_variant *variant = ctx-fimc_dev-variant;
int tx, ty, sx, sy;
int ret;
@@ -284,8 +285,13 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx)
sc-pre_dst_width = sx / sc-pre_hratio;
sc-pre_dst_height = sy / sc-pre_vratio;
- sc-main_hratio = (sx 8) / (tx sc-hfactor);
- sc-main_vratio = (sy 8) / (ty sc-vfactor);
+ if (!variant-has_mainscaler_ext) {
+ sc-main_hratio = (sx 8) / (tx sc-hfactor);
+ sc-main_vratio = (sy 8) / (ty sc-vfactor);
+ } else {
+ sc-main_hratio = (sx 14) / (tx sc-hfactor);
+ sc-main_vratio = (sy 14) / (ty sc-vfactor);
+ }
Ditto
sc-scaleup_h = (tx = sx) ? 1 : 0;
sc-scaleup_v = (ty = sy) ? 1 : 0;
@@ -569,6 +575,7 @@ static void fimc_dma_run(void *priv)
{
struct fimc_ctx *ctx = priv;
struct fimc_dev *fimc;
+ struct samsung_fimc_variant *variant = ctx-fimc_dev-variant;
unsigned long flags;
u32 ret;
@@ -601,7 +608,12 @@ static void fimc_dma_run(void *priv)
err(Scaler setup error);
goto dma_unlock;
}
- fimc_hw_set_scaler(ctx);
+
+ fimc_hw_set_prescaler(ctx);
+ if (!variant-has_mainscaler_ext)
+ fimc_hw_set_mainscaler(ctx);
+ else
+ fimc_hw_set_mainscaler_ext(ctx);
ditto
fimc_hw_set_target_format(ctx);
fimc_hw_set_rotation(ctx);
fimc_hw_set_effect(ctx);
@@ -1722,6 +1734,7 @@ static struct samsung_fimc_variant
fimc1_variant_s5pv210 = {
.pix_hoff = 1,
.has_inp_rot = 1,
.has_out_rot = 1,
+ .has_mainscaler_ext = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
.hor_offs_align =
Re: TeVii S470 dvb-s2 issues - 2nd try ,)
On Fri, 2010-12-17 at 12:19 +0100, Boris Cuber wrote: Hello linux-media people! I have to problems with my dvb card (TeVii S470). I already filed 2 bug reports some time ago, but no one seems to have noticed/read them, so i'm trying it here now. If you need a full dmesg, then please take a look at https://bugzilla.kernel.org/attachment.cgi?id=40552 1) TeVii S470 dvbs-2 card (cx23885) is not usable after pm-suspend/resume https://bugzilla.kernel.org/show_bug.cgi?id=16467 The cx23885 driver does not implement power management. It would likely take many, many hours of coding and testing to implement it properly. If you need resume/suspend, use the power management scripts on your machine to kill all the applications using the TeVii S470, and then unload the cx23885 module just before suspend. On resume, have the power management scripts reload the cx23885 module. 2) cx23885: ds3000_writereg: writereg error on =kernel-2.6.36-rc with TeVii S470 dvb-s2 card - https://bugzilla.kernel.org/show_bug.cgi?id=18832 These error messages show up in dmesg while switching channels in mplayer/kaffeine. [dmesg output] [ 919.789976] ds3000_writereg: writereg error(err == -6, reg == 0x03, value == 0x11) They look like I2C bus errors; error -6 is ENXIO, which is probably coming from cx23885-i2c.c. The device handled by the ds3000 driver is not responding properly to the CX23885. It could be that some other device on that I2C bus is hung up or the ds3000 device itself. Maybe some GPIO settings are set wrong? The cx23885 module supports an i2c_probe and i2c_debug module option that will turn on some messages related to i2c. I really have no other advice, except that if you do a git bisect process, you may find the commit(s) that caused the problem. Regards, Andy Are these issues known? If so, are there any fixes yet? When will these get into mainline? Could somebody point me into the right direction. Can i help somehow to debug these problems? Thank you in advance. Regards, Boris Cuber PS: Thank Emanuel for helping me out with this mail ,) -- 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] s5p-fimc: fix main scaler SFRs depends on FIMC version
Hello,
On 12/17/2010 08:43 AM, Hyunwoong Kim wrote:
The main scaler has four SFRs for main scaler ratio depends on FIMC version.
FIMC 4.x has only two SFRs and FIMC 5.x has four SFRs for main scaler.
Those are MainHorRatio, MainHorRatio_ext, MainVerRatio and MainverRatio_ext.
The FIMC 5.x has 15 bit resolution for scaling ratio as below.
{MainHorRatio,MainHorRatio_ext} = {[14:6],[5:0]}.
{MainVerRatio,MainVerRatio_ext} = {[14:6],[5:0]}.
MainHorRatio = CISCCTRL[24:16], MainHorRatio_ext = CIEXTEN[15:10]
MainVerRatio = CISCCTRL[8:0], MainVerRatio_ext = CIEXTEN[5:0]
This patch supports FIMC 4.x and FIMC 5.x using
platform_device_id::driver_data.
Signed-off-by: Hyunwoong Kim khw0178@samsung.com
Reviewed-by: Jonghun Han jonghun@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |7 +++-
drivers/media/video/s5p-fimc/fimc-core.c| 21 ++--
drivers/media/video/s5p-fimc/fimc-core.h|5 ++-
drivers/media/video/s5p-fimc/fimc-reg.c | 48 --
drivers/media/video/s5p-fimc/regs-fimc.h| 10 +-
5 files changed, 81 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index b216530..ca48e02 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -208,6 +208,7 @@ static int start_streaming(struct vb2_queue *q)
struct fimc_ctx *ctx = q-drv_priv;
struct fimc_dev *fimc = ctx-fimc_dev;
struct s3c_fimc_isp_info *isp_info;
+ struct samsung_fimc_variant *variant = ctx-fimc_dev-variant;
int ret;
ret = v4l2_subdev_call(fimc-vid_cap.sd, video, s_stream, 1);
@@ -230,7 +231,11 @@ static int start_streaming(struct vb2_queue *q)
return ret;
}
fimc_hw_set_input_path(ctx);
- fimc_hw_set_scaler(ctx);
+ fimc_hw_set_prescaler(ctx);
+ if (!variant-has_mainscaler_ext)
+ fimc_hw_set_mainscaler(ctx);
+ else
+ fimc_hw_set_mainscaler_ext(ctx);
fimc_hw_set_target_format(ctx);
fimc_hw_set_rotation(ctx);
fimc_hw_set_effect(ctx);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 7f56987..3cfa4b6 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -246,6 +246,7 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx)
struct fimc_scaler *sc = ctx-scaler;
struct fimc_frame *s_frame = ctx-s_frame;
struct fimc_frame *d_frame = ctx-d_frame;
+ struct samsung_fimc_variant *variant = ctx-fimc_dev-variant;
int tx, ty, sx, sy;
int ret;
@@ -284,8 +285,13 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx)
sc-pre_dst_width = sx / sc-pre_hratio;
sc-pre_dst_height = sy / sc-pre_vratio;
- sc-main_hratio = (sx 8) / (tx sc-hfactor);
- sc-main_vratio = (sy 8) / (ty sc-vfactor);
+ if (!variant-has_mainscaler_ext) {
+ sc-main_hratio = (sx 8) / (tx sc-hfactor);
+ sc-main_vratio = (sy 8) / (ty sc-vfactor);
+ } else {
+ sc-main_hratio = (sx 14) / (tx sc-hfactor);
+ sc-main_vratio = (sy 14) / (ty sc-vfactor);
+ }
sc-scaleup_h = (tx = sx) ? 1 : 0;
sc-scaleup_v = (ty = sy) ? 1 : 0;
@@ -569,6 +575,7 @@ static void fimc_dma_run(void *priv)
{
struct fimc_ctx *ctx = priv;
struct fimc_dev *fimc;
+ struct samsung_fimc_variant *variant = ctx-fimc_dev-variant;
unsigned long flags;
u32 ret;
@@ -601,7 +608,12 @@ static void fimc_dma_run(void *priv)
err(Scaler setup error);
goto dma_unlock;
}
- fimc_hw_set_scaler(ctx);
+
+ fimc_hw_set_prescaler(ctx);
+ if (!variant-has_mainscaler_ext)
+ fimc_hw_set_mainscaler(ctx);
+ else
+ fimc_hw_set_mainscaler_ext(ctx);
fimc_hw_set_target_format(ctx);
fimc_hw_set_rotation(ctx);
fimc_hw_set_effect(ctx);
@@ -1722,6 +1734,7 @@ static struct samsung_fimc_variant
fimc1_variant_s5pv210 = {
.pix_hoff= 1,
.has_inp_rot = 1,
.has_out_rot = 1,
+ .has_mainscaler_ext = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
.hor_offs_align = 1,
@@ -1743,6 +1756,7 @@ static struct samsung_fimc_variant
fimc0_variant_s5pv310 = {
.has_inp_rot = 1,
.has_out_rot = 1,
.has_cistatus2 = 1,
+ .has_mainscaler_ext = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
.hor_offs_align = 1,
@@ -1753,6 +1767,7 @@ static struct samsung_fimc_variant
fimc0_variant_s5pv310 = {
static
Re: [PATCH] bttv: fix mutex use before init
On Wed, Dec 15, 2010 at 10:45 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
While your patch fixes the issue, it has some other troubles, like to the
presence of
lock code at free_btres_lock(). It is possible to fix, but the better is to
just
use the core-assisted locking schema. This way, V4L2 core will serialize
access to all
ioctl's/open/close/mmap/read/poll operations, avoiding to have two processes
accessing
the hardware at the same time. Also, as there's just one lock, instead of 3,
there's no
risk of dead locks.
The net result is a cleaner code, with just one lock.
I tested the patch here with an bttv-based STB board (card=3, tuner=6), and
it worked fine for me.
Could you please test if this fixes the issue?
I tested your patch against 2.6.37-rc6 and it fixed both problems I was seeing.
Restarting hald 100 times did not oops and tvtime now again quits cleanly.
So as it WorksForMe, you can add my Tested-By, if you want.
Thanks,
Torsten
PS.: The patch is based against the bkl_removal patches, at my linux-next
tree:
http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=commit;h=673eb9ff33e26ee6f4278cdab06749aef1bbef5b
(I just created the bkl_removal branch, so, it may take some time for you to
see at the kernel.org
mirrors, but it is basically changeset 673eb9ff. You may also just apply it
on the top of the master
branch of my linux-next tree).
---
[media] bttv: Fix locking issues due to BKL removal code
The BKL removal patch added a condition where the code would try to use a
non-initialized
lock. While a patch just addressing the issue is possible, there are some
other troubles,
like to the presence of lock code at free_btres_lock(), called on some places
with the lock
already taken. It is possible to fix, but the better is to just use the
core-assisted
locking schema.
This way, V4L2 core will serialize access to all
ioctl's/open/close/mmap/read/poll
operations, avoiding to have two processes accessing the hardware at the same
time.
Also, as there's just one lock, instead of 3, there's no risk of dead locks.
Tested with bttv STB, Gateway P/N 6000699 (card 3, tuner 6).
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c
index a529619..25e1ca0 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -854,7 +854,6 @@ int check_alloc_btres_lock(struct bttv *btv, struct
bttv_fh *fh, int bit)
xbits |= RESOURCE_VIDEO_READ | RESOURCE_VIDEO_STREAM;
/* is it free? */
- mutex_lock(btv-lock);
if (btv-resources xbits) {
/* no, someone else uses it */
goto fail;
@@ -884,11 +883,9 @@ int check_alloc_btres_lock(struct bttv *btv, struct
bttv_fh *fh, int bit)
/* it's free, grab it */
fh-resources |= bit;
btv-resources |= bit;
- mutex_unlock(btv-lock);
return 1;
fail:
- mutex_unlock(btv-lock);
return 0;
}
@@ -940,7 +937,6 @@ void free_btres_lock(struct bttv *btv, struct bttv_fh
*fh, int bits)
/* trying to free ressources not allocated by us ... */
printk(bttv: BUG! (btres)\n);
}
- mutex_lock(btv-lock);
fh-resources = ~bits;
btv-resources = ~bits;
@@ -951,8 +947,6 @@ void free_btres_lock(struct bttv *btv, struct bttv_fh
*fh, int bits)
if (0 == (bits VBI_RESOURCES))
disclaim_vbi_lines(btv);
-
- mutex_unlock(btv-lock);
}
/* --- */
@@ -1713,28 +1707,20 @@ static int bttv_prepare_buffer(struct videobuf_queue
*q,struct bttv *btv,
/* Make sure tvnorm and vbi_end remain consistent
until we're done. */
- mutex_lock(btv-lock);
norm = btv-tvnorm;
/* In this mode capturing always starts at defrect.top
(default VDELAY), ignoring cropping parameters. */
if (btv-vbi_end bttv_tvnorms[norm].cropcap.defrect.top) {
- mutex_unlock(btv-lock);
return -EINVAL;
}
- mutex_unlock(btv-lock);
-
c.rect = bttv_tvnorms[norm].cropcap.defrect;
} else {
- mutex_lock(btv-lock);
-
norm = btv-tvnorm;
c = btv-crop[!!fh-do_crop];
- mutex_unlock(btv-lock);
-
if (width c.min_scaled_width ||
width c.max_scaled_width ||
height c.min_scaled_height)
@@ -1858,7 +1844,6 @@ static int bttv_s_std(struct file *file, void *priv,
v4l2_std_id *id)
unsigned int i;
int err;
- mutex_lock(btv-lock);
err = v4l2_prio_check(btv-prio, fh-prio);
Re: [RFC][media] s5p-fimc : Need to modify for s5pv310
Hi Sungchun, On 12/14/2010 10:52 AM, Sungchun Kang wrote: Hi Sylwester, Thanks for your reply. I almost agree with your opinion. On 12/13/2010 07:46 PM, Sylwester Nawrocki wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Sylwester Nawrocki Sent: Monday, December 13, 2010 7:46 PM To: sungchun.k...@samsung.com Cc: linux-media@vger.kernel.org Subject: Re: [RFC][media] s5p-fimc : Need to modify for s5pv310 Hi Sungchun, On 12/10/2010 03:21 AM, Sungchun Kang wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Sylwester Nawrocki Sent: Monday, December 06, 2010 6:46 PM To: sungchun.k...@samsung.com Cc: linux-media@vger.kernel.org Subject: Re: [RFC][media] s5p-fimc : Need to modify for s5pv310 Hi Sungchun, thanks for your suggestions. I am planning to improve output DMA handling in the fimc camera capture driver, what is done already is only a minimal adaptation to make driver work on S5PV310 SoC. We don't even have a platform support (resource and platform device definitions) for f...@s5pv310 yet though. I think it needs to be done first. Your proposed scheme of presetting output DMA buffer adresses before streaming is enabled and then using the CIFCNTSEQ register to mask out buffers passed to user space looks reasonable to me. I could imagine adopting such a method for buffer of V4L2_MEMORY_MMAP memory type. But do you think it is going to work for V4L2_MEMORY_USERPTR? There is no confidence that USERPTR addresses passed by applications in subsequent VIDIOC_QBUF calls will not be changing, right? Like V4L2_MEMORY_MMAP, it is possible to use V4L2_MEMORY_USERPTR for memory type. Surely, in case of V4L2_MEMORY_USERPTR, output buffer SFR could be changed. But, it is possible to adjust my concept too. When the VIDIOC_QBUF called, user can set m.userptr field to the address of the buffer, length to its size, and index field. For example QBUF Output DMASFR index m.userptr CIFCNTSEQ[bit] CIOYSA1 0 0x4000 [0] - enable CIOYSA2 1 0x40001000 [1] - enable CIOYSA3 2 0x40002000 [2] - enable CIOYSA4 3 0x40003000 [3] - enable CIOYSA5 4 0x40004000 [4] - enable CIOYSA6 5 0x40005000 [5] - enable CIOYSA1 0 0x40006000 [0] - enable (SFR value change for output buffer) Because it is possible to regard a index as output DMA SFR, there's no need to use pending queue concept. I do not really see much gain in that approach, we still need to obtain physical address from video buffer, read the address from registers, compare both and then perform write if necessary. First of all, I wonder V4L2 standard as below. Index field of v4l2_buffer is used not only V4L2_MEMORY_MMAP but also V4L2_MEMORY_USERPTR of vb2_qbuf. But it is not described at V4L2 standard. What is right thing? As already pointed out by Laurent the index field should be used with either V4L2_MEMORY_MMAP or V4L2_MEMORY_USERPTR. The specification will be soon corrected. And in V4L2_MEMORY_USERPTR case, you're right. But I doubt such case(change CIOYSAn's value)is existed. Although such a use case might be rare, it still needs to be handled properly by the driver. The code would be different among various SoC revisions and it would increase interrupt service routine size. I would see CIFCNTSEQ as a means of additional protection preventing the DMA engine from writing to a buffer which has been passed to user land. CIFCNTSEQ is for maximum 32 buffer count to user. User can select buffer count easier. Please note that if user does not queue the buffers in an ascending buffer index order, the buffers are going to be dequeued out of order. Since we cannot change the order of processing the buffers in hardware, we are only able to mask/unmask specific buffer in the DMA engine. The processing sequence is always fixed and the buffers would be dequeued in an ascending video buffer index order. However this kind of operation is possible with videobuf2. The modification for s5pv310 is rather straightforward. I am more concerned at the moment with the fact that in s5pv210 output frame index register seem to be changing in a non deterministic way when the CIOYSAn address registers are being updated in the interrupt handler. So it looks like there is no reliable status register in HW to determine which DMA buffer is currently being used. This causes trouble when streaming is stopped in the camera capture driver
DuoFlex CT PCIe
Dear all, I recently found the DuoFlex CT PCIe TV-card. Finally a dual tuner DVB-C card. However, thusfar I haven't found any reference to a linux driver for this device. Is anyone working on this? Or do you know what is blocking it. Regards, Bert Haverkamp -- 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
Reading/writing controls from different classes in a single VIDIOC_[GS]_EXT_CTRLS call
Hi Hans, I've recently run into an issue when porting a sensor driver to the control framework. A userspace application using that driver using VIDIOC_G_EXT_CTRLS to retrieve the value of a bunch of controls in a single call. Those controls don't belong to the same class, and the application started failing. What's the rationale behind forbidding that ? -- Regards, Laurent Pinchart -- 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 v7 5/8] davinci vpbe: board specific additions
Hello.
Manjunath Hadli wrote:
This patch implements tables for display timings,outputs and
other board related functionalities.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
[...]
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 34c8b41..e9b1243 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
[...]
@@ -620,6 +671,8 @@ davinci_evm_map_io(void)
{
/* setup input configuration for VPFE input devices */
dm644x_set_vpfe_config(vpfe_cfg);
+ /* setup configuration for vpbe devices */
+ dm644x_set_vpbe_display_config(vpbe_display_cfg);
dm644x_init();
}
This patch should *follow* the platform patch (where
dm644x_set_vpbe_display_config() is defined), not precede it.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L/DVB: Add support for M5MOLS Mega Pixel camera
Hi HeungJun,
On 12/17/2010 07:42 AM, Kim, HeungJun wrote:
Hi Sylwester,
Thanks for some comments. I'll reflects this comments for the next version
patch. It's clear that there is a few things I missed. It's better to let's
talk about this rest things, as Mr. Park said.
But, I wanna remind one thing, and know your exact thiking. about MACROs.
I re-comments of that. look around and re-re-comments it, plz.
+
+/* MACRO */
+#define e_check_w(fn, cat, byte, val, bitwidth)do {\
+int ret;\
+ret = (int)(fn);\
+if ((ret) 0) {\
+dev_err(client-dev, fail i2c WRITE [%s] - \
+category:0x%02x, \
+bytes:0x%02x, \
+value:0x%02x\n,\
+(bitwidth),\
+(cat), (byte), (u32)val);\
+return ret;\
+}\
+} while (0)
+
+#define e_check_r(fn, cat, byte, val, bitwidth)do {\
+int ret;\
+ret = (int)(fn);\
+if ((ret) 0) {\
+dev_err(client-dev, fail i2c READ [%s] - \
+category:0x%02x, \
+bytes:0x%02x, \
+value:0x%02x\n,\
+(bitwidth),\
+(cat), (byte), (u32)(*val));\
+return ret;\
+}\
+} while (0)
+
+#define REG_W_8(cat, byte, value)\
+e_check_w(m5mols_write_reg(sd, M5MOLS_8BIT, cat, byte, value),\
+cat, byte, value, 8bit)
+#define REG_R_8(cat, byte, value)\
+e_check_r(m5mols_read_reg(sd, M5MOLS_8BIT, cat, byte, value),\
+cat, byte, value, 8bit)
+
+#define e_check_mode(fn, mode)do {\
+int ret;\
+ret = (int)(fn);\
+if (ret 0) {\
+dev_err(client-dev, Failed to %s mode\n,\
+(mode));\
+return ret;\
+}\
+} while (0)
These macros really do not look good. Moreover they all change
the control flow, i.e. return a value. From Documentation/CodingStyle:
Things to avoid when using macros:
1) macros that affect control flow:
#define FOO(x) \
do {\
if (blah(x) 0)\
return -EBUGGERED; \
} while(0)
is a _very_ bad idea. It looks like a function call but exits the
calling function; don't break the internal parsers of those who will
read the code.
I know about Documentation/CodingStyle and absolutely know about
the risks of MACRO like upper case. I even know the _very_'s meanings.
But, I think this case is different any other MACRO cases to be concrete
whether use or not. Actually, I've not even found address symbol using T32
debuggers cause of MACROs. I have realized danger before long time.
I know Documentation/CodingStyle is very strong recommandation.
And must keep this style but, it seems to happen the specific case.
The specific means, not general and only used in the M5MOLS code.
The following is my thinking at past.
1. There are a lot of I2C communication is in M5MOLS driver code.
The M5MOLS has 16 category, and about 50 commands in the each category.
If each command need 1 line on the code, the amount to be charged I2C
communication only is 800 lines. What if each command be plused 3~4
error checking code? The code amount is 3200 lines at least. Moreover,
No guarantiee 1 command only 1 time excuetion. So, 3200 more lines
would be added at the future. (The m5mo driver you've seen and used before,
is not yet inserted all controls.)
Then this sensor needs careful design and function partitioning.
Single *.c file should not exceed 1000 lines.
I think we need a separate directory for it, like media/drivers/m5mols/.
Hans already pointed out a few ways around macros. I just didn't want to repeat
that.
For now, this driver supports only small function. But, If any all other
controls inserted this code, I can guarantee. it seems so hard to catch
the flow of code and operation. And, it seems to cause more problems for
functionalities and hiding bugs, rather than keep using CodingStyle.
2. m5mols I2C communications, namely m5mols_read_reg/write_reg is needed
many arguments. It violates to do checkpatch.pl 80 characters frequently.
So, I inserted next lines the rest of m5mols_read_reg(), it effects more
line added, consequently it looks like upper case.
3. Any other reason is discussed with Hans. And he explained alternative
Re: [PATCH] bttv: fix mutex use before init
On 19:45 Wed 15 Dec 2010, Mauro Carvalho Chehab wrote: Em 15-12-2010 16:44, Chris Clayton escreveu: On Tuesday 14 December 2010, Brandon Philips wrote: On 17:13 Sun 12 Dec 2010, Torsten Kaiser wrote: * change fh-cap.vb_lock in bttv_open() AND radio_open() to btv-init.cap.vb_lock * add a mutex_init(btv-init.cap.vb_lock) to the setup of init in bttv_probe() That seems like a reasonable suggestion. An openSUSE user submitted this bug to our tracker too. Here is the patch I am having him test. Would you mind testing it? From 456dc0ce36db523c4c0c8a269f4eec43a72de1dc Mon Sep 17 00:00:00 2001 From: Brandon Philips bphil...@suse.de Date: Mon, 13 Dec 2010 16:21:55 -0800 Subject: [PATCH] bttv: fix locking for btv-init Fix locking for the btv-init by using btv-init.cap.vb_lock and in the process fix uninitialized deref introduced in c37db91fd0d. Signed-off-by: Brandon Philips bphil...@suse.de While your patch fixes the issue, it has some other troubles, like to the presence of lock code at free_btres_lock(). It is possible to fix, but the better is to just use the core-assisted locking schema. This way, V4L2 core will serialize access to all ioctl's/open/close/mmap/read/poll operations, avoiding to have two processes accessing the hardware at the same time. Also, as there's just one lock, instead of 3, there's no risk of dead locks. Thanks, but, why wasn't this done instead of c37db91f? Will this make it in before 2.6.37 is released? Otherwise 2.6.37 will need to be fixed in -stable immediatly after release. The net result is a cleaner code, with just one lock. Could you take this patch to remove all of the comments about locking order with btv-lock since it doesn't seem to matter any longer. Cheers, Brandon P.S. Your mail client creates really long lines- somewhere around 90 characters. Could you fix that? From 7643db7bf5e9e557a27e3783786a1abecbdf82a7 Mon Sep 17 00:00:00 2001 From: Brandon Philips bran...@ifup.org Date: Fri, 17 Dec 2010 07:58:22 -0800 Subject: [PATCH] bttv: remove unneeded locking comments After Mauro's bttv: Fix locking issues due to BKL removal code there are a number of comments that are no longer needed about lock ordering. Remove them. Signed-off-by: Brandon Philips bphil...@suse.de --- drivers/media/video/bt8xx/bttv-driver.c | 20 1 files changed, 0 insertions(+), 20 deletions(-) diff --git a/drivers/media/video/bt8xx/bttv-driver.c b/drivers/media/video/bt8xx/bttv-driver.c index 25e1ca0..0902ec0 100644 --- a/drivers/media/video/bt8xx/bttv-driver.c +++ b/drivers/media/video/bt8xx/bttv-driver.c @@ -2358,13 +2358,6 @@ static int setup_window_lock(struct bttv_fh *fh, struct bttv *btv, fh-ov.field= win-field; fh-ov.setup_ok = 1; - /* -* FIXME: btv is protected by btv-lock mutex, while btv-init -*is protected by fh-cap.vb_lock. This seems to open the -*possibility for some race situations. Maybe the better would -*be to unify those locks or to use another way to store the -*init values that will be consumed by videobuf callbacks -*/ btv-init.ov.w.width = win-w.width; btv-init.ov.w.height = win-w.height; btv-init.ov.field = win-field; @@ -3219,15 +3212,6 @@ static int bttv_open(struct file *file) return -ENOMEM; file-private_data = fh; - /* -* btv is protected by btv-lock mutex, while btv-init and other -* streaming vars are protected by fh-cap.vb_lock. We need to take -* care of both locks to avoid troubles. However, vb_lock is used also -* inside videobuf, without calling buf-lock. So, it is a very bad -* idea to hold both locks at the same time. -* Let's first copy btv-init at fh, holding cap.vb_lock, and then work -* with the rest of init, holding btv-lock. -*/ *fh = btv-init; fh-type = type; @@ -3302,10 +3286,6 @@ static int bttv_release(struct file *file) /* free stuff */ - /* -* videobuf uses cap.vb_lock - we should avoid holding btv-lock, -* otherwise we may have dead lock conditions -*/ videobuf_mmap_free(fh-cap); videobuf_mmap_free(fh-vbi); v4l2_prio_close(btv-prio, fh-prio); -- 1.7.3.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
[GIT PULL for v2.6.37-rc6] V4L/DVB BKL fixes
Hi Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git bkl_removal For a series of BKL removal fixes that are needed in order to allow making V4L core non-dependent of CONFIG_BKL. Several patches on this series are trivial. There's still one bug left with bttv driver. I have a patch for it already. I'll be adding it at -next and let it cook there for a couple days before sending you a pull request. Cheers, Mauro. --- The following changes since commit e53beacd23d9cb47590da6a7a7f6d417b941a994: Linux 2.6.37-rc2 (2010-11-15 18:31:02 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git bkl_removal Hans Verkuil (15): [media] BKL: trivial BKL removal from V4L2 radio drivers [media] cadet: use unlocked_ioctl [media] tea5764: convert to unlocked_ioctl [media] si4713: convert to unlocked_ioctl [media] typhoon: convert to unlocked_ioctl [media] BKL: trivial ioctl - unlocked_ioctl video driver conversions [media] sn9c102: convert to unlocked_ioctl [media] et61x251_core: trivial conversion to unlocked_ioctl [media] cafe_ccic: replace ioctl by unlocked_ioctl [media] sh_vou: convert to unlocked_ioctl [media] radio-timb: convert to unlocked_ioctl [media] cx18: convert to unlocked_ioctl [media] v4l2-dev: use mutex_lock_interruptible instead of plain mutex_lock [media] V4L: improve the BKL replacement heuristic [media] v4l2-dev: fix race condition Laurent Pinchart (5): [media] uvcvideo: Lock controls mutex when querying menus [media] uvcvideo: Move mutex lock/unlock inside uvc_free_buffers [media] uvcvideo: Move mmap() handler to uvc_queue.c [media] uvcvideo: Lock stream mutex when accessing format-related information [media] uvcvideo: Convert to unlocked_ioctl drivers/media/radio/radio-aimslab.c | 16 +- drivers/media/radio/radio-aztech.c |6 +- drivers/media/radio/radio-cadet.c| 12 ++- drivers/media/radio/radio-gemtek-pci.c |6 +- drivers/media/radio/radio-gemtek.c | 14 +- drivers/media/radio/radio-maestro.c | 14 +- drivers/media/radio/radio-maxiradio.c|2 +- drivers/media/radio/radio-miropcm20.c|6 +- drivers/media/radio/radio-rtrack2.c | 10 +- drivers/media/radio/radio-sf16fmi.c |7 +- drivers/media/radio/radio-sf16fmr2.c | 11 +- drivers/media/radio/radio-si4713.c |3 +- drivers/media/radio/radio-tea5764.c | 49 ++-- drivers/media/radio/radio-terratec.c |8 +- drivers/media/radio/radio-timb.c |5 +- drivers/media/radio/radio-trust.c| 18 ++-- drivers/media/radio/radio-typhoon.c | 16 +- drivers/media/radio/radio-zoltrix.c | 30 ++-- drivers/media/video/arv.c|2 +- drivers/media/video/bw-qcam.c|2 +- drivers/media/video/c-qcam.c |2 +- drivers/media/video/cafe_ccic.c |2 +- drivers/media/video/cx18/cx18-alsa-pcm.c |8 +- drivers/media/video/cx18/cx18-streams.c |2 +- drivers/media/video/et61x251/et61x251_core.c |2 +- drivers/media/video/meye.c | 14 +- drivers/media/video/pms.c|2 +- drivers/media/video/sh_vou.c | 13 +- drivers/media/video/sn9c102/sn9c102_core.c |2 +- drivers/media/video/uvc/uvc_ctrl.c | 48 +++- drivers/media/video/uvc/uvc_queue.c | 133 +++--- drivers/media/video/uvc/uvc_v4l2.c | 185 -- drivers/media/video/uvc/uvc_video.c |3 - drivers/media/video/uvc/uvcvideo.h | 10 +- drivers/media/video/v4l2-dev.c | 69 +++--- drivers/media/video/v4l2-device.c|1 + drivers/media/video/w9966.c |2 +- include/media/v4l2-device.h |2 + 38 files changed, 413 insertions(+), 324 deletions(-) -- 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: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal
Laurent, Em 14-12-2010 08:55, Laurent Pinchart escreveu: Hi Mauro, Please don't forget this pull request for 2.6.37. Pull request for upstream sent today. I didn't find any regressions at the BKL removal patches, but I noticed a few issues with qv4l2, not all related to uvcvideo. The remaining of this email is an attempt to document them for later fixes. They don't seem to be regressions caused by BKL removal, but the better would be to fix them later. - with uvcvideo and two video apps, if qv4l2 is started first, the second application doesn't start/capture. I suspect that REQBUFS (used by qv4l2 to probe mmap/userptr capabilities) create some resource locking at uvcvideo. The proper way is to lock the resources only if the driver is streaming, as other drivers and videobuf do. - with saa7134 and qv4l2 (and after a fix for input capabilities): saa7134 and/or qv4l2 doesn't seem to work fine if video format is changed to a 60HZ format (NTSC or PAL/M). It keeps trying to use 576 lines, but the driver only works with 480 lines for those formats. So, if qv4l2 tries to capture with STD/M, it fails, except if the number of lines is manually fixed by the user. - at least with the saa7134 board I used for test, video capture fails on some conditions. This is not related to BKL patches. I suspect it may be some initialization failure with the tuner (tda8275/tda8290), but I didn't have time to dig into it, nor to test with a simpler saa7134 device. The device I used was an Avermedia m135. On Monday 29 November 2010 11:15:10 Laurent Pinchart wrote: Hi Mauro, The following changes since commit c796e203229c8c08250f9d372ae4e10c466b1787: [media] kconfig: add an option to determine a menu's visibility (2010-11-22 10:37:56 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-stable They complete the BKL removal from the uvcvideo driver. Feedback received from Hans during review has been integrated. Laurent Pinchart (5): uvcvideo: Lock controls mutex when querying menus uvcvideo: Move mutex lock/unlock inside uvc_free_buffers uvcvideo: Move mmap() handler to uvc_queue.c uvcvideo: Lock stream mutex when accessing format-related information uvcvideo: Convert to unlocked_ioctl drivers/media/video/uvc/uvc_ctrl.c | 48 +- drivers/media/video/uvc/uvc_queue.c | 133 +- drivers/media/video/uvc/uvc_v4l2.c | 185 +++--- drivers/media/video/uvc/uvc_video.c | 3 - drivers/media/video/uvc/uvcvideo.h | 10 ++- 5 files changed, 222 insertions(+), 157 deletions(-) -- 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] cx231xx: Fix inverted bits for RC on PV Hybrid
At Pixelview SBTVD Hybrid, the bits sent by the IR are inverted. Due to that,
the existing keytables produce wrong codes.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx231xx/cx231xx-input.c
b/drivers/media/video/cx231xx/cx231xx-input.c
index c236a4e..45e14ca 100644
--- a/drivers/media/video/cx231xx/cx231xx-input.c
+++ b/drivers/media/video/cx231xx/cx231xx-input.c
@@ -27,7 +27,7 @@
static int get_key_isdbt(struct IR_i2c *ir, u32 *ir_key,
u32 *ir_raw)
{
- u8 cmd;
+ u8 cmd, scancode;
dev_dbg(ir-rc-input_dev-dev, %s\n, __func__);
@@ -42,10 +42,21 @@ static int get_key_isdbt(struct IR_i2c *ir, u32 *ir_key,
if (cmd == 0xff)
return 0;
- dev_dbg(ir-rc-input_dev-dev, scancode = %02x\n, cmd);
-
- *ir_key = cmd;
- *ir_raw = cmd;
+ scancode =
+((cmd 0x01) ? 0x80 : 0) |
+((cmd 0x02) ? 0x40 : 0) |
+((cmd 0x04) ? 0x20 : 0) |
+((cmd 0x08) ? 0x10 : 0) |
+((cmd 0x10) ? 0x08 : 0) |
+((cmd 0x20) ? 0x04 : 0) |
+((cmd 0x40) ? 0x02 : 0) |
+((cmd 0x80) ? 0x01 : 0);
+
+ dev_dbg(ir-rc-input_dev-dev, cmd %02x, scan = %02x\n,
+ cmd, scancode);
+
+ *ir_key = scancode;
+ *ir_raw = scancode;
return 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
RE: DuoFlex CT PCIe
Hello Bert I raised the same question two weeks ago, I only got an offline answer, see below.$ I hope to get some more replies too. -- I wanted to know if the Digital Devices DuoFlex CT PCIe TWIN Combo DVB-C DVB-T card is supported. This card has 2 Ports, using one PCIe slot. Additionally it can be extended by 2 tuners to a total of 4 tuners, still using only one PCIe slot. There is also a Octopus version who is able to run 8 tuners using only one PCIe slot. Is this card supported, is it performing well with 2/4 tuners ? Will it be able to stream 4 HD channels at once via one PCIe slot ? currently there is no support for it, might not sound too popular but we have USB based DVB-C tuners which can be used with PCIe based USB extenders. So far we tested 3 tuners on a Notebook with 1.3 ghz streaming the entire bouquet (each around 50 Mbit). HDTV usually requires 15 Mbit SDTV 4-8 Mbit. So this is not only related to 4 HD channels but to the entire Bouquet (which could be up to 3 HD Streams for DVB-C). Additionally those devices support Hardware PID filtering in order to lower the bandwidth, virtually any amount of devices can be attached until the USB Bandwidth for one controller let's say 300-400 mbit is fully utilized. The software is hotplug aware and well tested on x86, ARM, MIPS, PPC (some architectures support little/big endian). The drivers are in userspace, although there's an opensource kernel acceleration module available which can lower the cpu usage (this one only has around 500 lines of clean written code which is also very stable, it's mostly used with low powered embedded devices). If you have any further question about this just let me know. This mail is not intended to be on the mailinglist since it's slightly offtopic of your initial mail request. Best Regards, I hope to get some replies from people using this card. Thanks Eckhard http://shop.digital-devices.de/epages/62357162.sf/de_DE/?ObjectPath=/Shops/62357162/Categories/8 http://shop.digital-devices.de/epages/62357162.sf/de_DE/?ObjectPath=/Shops/62357162/Products/091005 http://shop.digital-devices.de/epages/62357162.sf/de_DE/?ObjectPath=/Shops/62357162/Products/091007 http://shop.digital-devices.de/epages/62357162.sf/de_DE/?ObjectPath=/Shops/62357162/Products/092014 -- -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Bert Haverkamp Sent: 17 December 2010 16:22 To: linux-media@vger.kernel.org Subject: DuoFlex CT PCIe Dear all, I recently found the DuoFlex CT PCIe TV-card. Finally a dual tuner DVB-C card. However, thusfar I haven't found any reference to a linux driver for this device. Is anyone working on this? Or do you know what is blocking it. Regards, Bert Haverkamp -- 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 2/2] [media] cx231xx: Fix IR keymap for Pixelview SBTVD Hybrid
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 6175650..6905607 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -412,7 +412,7 @@ struct cx231xx_board cx231xx_boards[] = {
.tuner_i2c_master = 2,
.demod_i2c_master = 1,
.ir_i2c_master = 2,
- .rc_map_name = RC_MAP_PIXELVIEW_NEW,
+ .rc_map_name = RC_MAP_PIXELVIEW_002T,
.has_dvb = 1,
.demod_addr = 0x10,
.norm = V4L2_STD_PAL_M,
--
1.7.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 1/2] [media] Add a keymap for Pixelview 002-T remote
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
create mode 100644 drivers/media/rc/keymaps/rc-pixelview-002t.c
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index 3194d39..148900f 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-pinnacle-pctv-hd.o \
rc-pixelview.o \
rc-pixelview-mk12.o \
+ rc-pixelview-002t.o \
rc-pixelview-new.o \
rc-powercolor-real-angel.o \
rc-proteus-2309.o \
diff --git a/drivers/media/rc/keymaps/rc-pixelview-002t.c
b/drivers/media/rc/keymaps/rc-pixelview-002t.c
new file mode 100644
index 000..e5ab071
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-pixelview-002t.c
@@ -0,0 +1,77 @@
+/* rc-pixelview-mk12.h - Keytable for pixelview Remote Controller
+ *
+ * keymap imported from ir-keymaps.c
+ *
+ * Copyright (c) 2010 by Mauro Carvalho Chehab mche...@redhat.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include media/rc-map.h
+
+/*
+ * Keytable for 002-T IR remote provided together with Pixelview
+ * SBTVD Hybrid Remote Controller. Uses NEC extended format.
+ */
+static struct rc_map_table pixelview_002t[] = {
+ { 0x866b13, KEY_MUTE },
+ { 0x866b12, KEY_POWER2 }, /* power */
+
+ { 0x866b01, KEY_1 },
+ { 0x866b02, KEY_2 },
+ { 0x866b03, KEY_3 },
+ { 0x866b04, KEY_4 },
+ { 0x866b05, KEY_5 },
+ { 0x866b06, KEY_6 },
+ { 0x866b07, KEY_7 },
+ { 0x866b08, KEY_8 },
+ { 0x866b09, KEY_9 },
+ { 0x866b00, KEY_0 },
+
+ { 0x866b0d, KEY_CHANNELUP },
+ { 0x866b19, KEY_CHANNELDOWN },
+ { 0x866b10, KEY_VOLUMEUP }, /* vol + */
+ { 0x866b0c, KEY_VOLUMEDOWN }, /* vol - */
+
+ { 0x866b0a, KEY_CAMERA }, /* snapshot */
+ { 0x866b0b, KEY_ZOOM }, /* zoom */
+
+ { 0x866b1b, KEY_BACKSPACE },
+ { 0x866b15, KEY_ENTER },
+
+ { 0x866b1d, KEY_UP },
+ { 0x866b1e, KEY_DOWN },
+ { 0x866b0e, KEY_LEFT },
+ { 0x866b0f, KEY_RIGHT },
+
+ { 0x866b18, KEY_RECORD },
+ { 0x866b1a, KEY_STOP },
+};
+
+static struct rc_map_list pixelview_map = {
+ .map = {
+ .scan= pixelview_002t,
+ .size= ARRAY_SIZE(pixelview_002t),
+ .rc_type = RC_TYPE_NEC,
+ .name= RC_MAP_PIXELVIEW_002T,
+ }
+};
+
+static int __init init_rc_map_pixelview(void)
+{
+ return rc_map_register(pixelview_map);
+}
+
+static void __exit exit_rc_map_pixelview(void)
+{
+ rc_map_unregister(pixelview_map);
+}
+
+module_init(init_rc_map_pixelview)
+module_exit(exit_rc_map_pixelview)
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Mauro Carvalho Chehab mche...@redhat.com);
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index 1a3d51d..5d3a457 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -119,6 +119,7 @@ void rc_map_init(void);
#define RC_MAP_PINNACLE_PCTV_HD rc-pinnacle-pctv-hd
#define RC_MAP_PIXELVIEW_NEW rc-pixelview-new
#define RC_MAP_PIXELVIEW rc-pixelview
+#define RC_MAP_PIXELVIEW_002T rc-pixelview-002t
#define RC_MAP_PIXELVIEW_MK12rc-pixelview-mk12
#define RC_MAP_POWERCOLOR_REAL_ANGEL rc-powercolor-real-angel
#define RC_MAP_PROTEUS_2309 rc-proteus-2309
--
1.7.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] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Dec 17 19:00:24 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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: Reading/writing controls from different classes in a single VIDIOC_[GS]_EXT_CTRLS call
On Friday, December 17, 2010 17:17:05 Laurent Pinchart wrote: Hi Hans, I've recently run into an issue when porting a sensor driver to the control framework. A userspace application using that driver using VIDIOC_G_EXT_CTRLS to retrieve the value of a bunch of controls in a single call. Those controls don't belong to the same class, and the application started failing. What's the rationale behind forbidding that ? Which driver? The control framework doesn't have that limitation anymore. Originally the API had that limitation, mostly to reduce driver complexity, but that limitation is lifted in the control framework. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reading/writing controls from different classes in a single VIDIOC_[GS]_EXT_CTRLS call
On Friday, December 17, 2010 20:52:25 Hans Verkuil wrote: On Friday, December 17, 2010 17:17:05 Laurent Pinchart wrote: Hi Hans, I've recently run into an issue when porting a sensor driver to the control framework. A userspace application using that driver using VIDIOC_G_EXT_CTRLS to retrieve the value of a bunch of controls in a single call. Those controls don't belong to the same class, and the application started failing. What's the rationale behind forbidding that ? Which driver? The control framework doesn't have that limitation anymore. Originally the API had that limitation, mostly to reduce driver complexity, but that limitation is lifted in the control framework. A follow-up: if the ctrl_class field of v4l2_ext_controls is set to a specific control class by the application, then all controls in the list must belong to that control class. This is checked by the control framework. This matches the behavior as defined in the spec. If ctrl_class is 0, then the control framework allows controls from any class. This doesn't seem to be documented yet. I thought I did :-( Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bttv: fix mutex use before init
Em 17-12-2010 14:07, Brandon Philips escreveu: On 19:45 Wed 15 Dec 2010, Mauro Carvalho Chehab wrote: Em 15-12-2010 16:44, Chris Clayton escreveu: On Tuesday 14 December 2010, Brandon Philips wrote: On 17:13 Sun 12 Dec 2010, Torsten Kaiser wrote: * change fh-cap.vb_lock in bttv_open() AND radio_open() to btv-init.cap.vb_lock * add a mutex_init(btv-init.cap.vb_lock) to the setup of init in bttv_probe() That seems like a reasonable suggestion. An openSUSE user submitted this bug to our tracker too. Here is the patch I am having him test. Would you mind testing it? From 456dc0ce36db523c4c0c8a269f4eec43a72de1dc Mon Sep 17 00:00:00 2001 From: Brandon Philips bphil...@suse.de Date: Mon, 13 Dec 2010 16:21:55 -0800 Subject: [PATCH] bttv: fix locking for btv-init Fix locking for the btv-init by using btv-init.cap.vb_lock and in the process fix uninitialized deref introduced in c37db91fd0d. Signed-off-by: Brandon Philips bphil...@suse.de While your patch fixes the issue, it has some other troubles, like to the presence of lock code at free_btres_lock(). It is possible to fix, but the better is to just use the core-assisted locking schema. This way, V4L2 core will serialize access to all ioctl's/open/close/mmap/read/poll operations, avoiding to have two processes accessing the hardware at the same time. Also, as there's just one lock, instead of 3, there's no risk of dead locks. Thanks, but, why wasn't this done instead of c37db91f? Because c37db91f were a first attempt. I was expecting that it would be enough, but, after some discussions at the ML, it seemed to be better to use a different approach. As you probably noticed, the locking schema at bttv driver were very complex, and it were likely to ask for problems. The new schema is simpler. The principle is to serialize the access to the hardware or to the hardware-mirrored data. It does that by serializing the access to all file operations for a given bttv device. While this is a little overkill (as there are a very few set of operations that won't require locking, like retrieving some static read-only data), there's no performance impact at the critical path, as such ioctl's typically happen only during hardware discovery phase at the userspace apps. Will this make it in before 2.6.37 is released? Otherwise 2.6.37 will need to be fixed in -stable immediatly after release. I'll intend to add it today for -next, and send upstream by Sunday, hopefully in time for .37. The net result is a cleaner code, with just one lock. Could you take this patch to remove all of the comments about locking order with btv-lock since it doesn't seem to matter any longer. Yes, sure. Thanks for the patch. Cheers, Brandon P.S. Your mail client creates really long lines- somewhere around 90 characters. Could you fix that? From 7643db7bf5e9e557a27e3783786a1abecbdf82a7 Mon Sep 17 00:00:00 2001 From: Brandon Philips bran...@ifup.org Date: Fri, 17 Dec 2010 07:58:22 -0800 Subject: [PATCH] bttv: remove unneeded locking comments After Mauro's bttv: Fix locking issues due to BKL removal code there are a number of comments that are no longer needed about lock ordering. Remove them. Signed-off-by: Brandon Philips bphil...@suse.de --- drivers/media/video/bt8xx/bttv-driver.c | 20 1 files changed, 0 insertions(+), 20 deletions(-) diff --git a/drivers/media/video/bt8xx/bttv-driver.c b/drivers/media/video/bt8xx/bttv-driver.c index 25e1ca0..0902ec0 100644 --- a/drivers/media/video/bt8xx/bttv-driver.c +++ b/drivers/media/video/bt8xx/bttv-driver.c @@ -2358,13 +2358,6 @@ static int setup_window_lock(struct bttv_fh *fh, struct bttv *btv, fh-ov.field= win-field; fh-ov.setup_ok = 1; - /* - * FIXME: btv is protected by btv-lock mutex, while btv-init - *is protected by fh-cap.vb_lock. This seems to open the - *possibility for some race situations. Maybe the better would - *be to unify those locks or to use another way to store the - *init values that will be consumed by videobuf callbacks - */ btv-init.ov.w.width = win-w.width; btv-init.ov.w.height = win-w.height; btv-init.ov.field = win-field; @@ -3219,15 +3212,6 @@ static int bttv_open(struct file *file) return -ENOMEM; file-private_data = fh; - /* - * btv is protected by btv-lock mutex, while btv-init and other - * streaming vars are protected by fh-cap.vb_lock. We need to take - * care of both locks to avoid troubles. However, vb_lock is used also - * inside videobuf, without calling buf-lock. So, it is a very bad - * idea to hold both locks at the same time. - * Let's first copy btv-init at fh, holding cap.vb_lock, and then work - * with the rest of init, holding btv-lock. - */ *fh = btv-init; fh-type = type; @@ -3302,10
Problem with sound on SAA7134 TV card
Hi, I hope someone can help me.
Firstly, please cc me on any reply because I'm not subscribed.
I have a Hauppauge HVR-1120 card (I thought I was buying an HVR-1100, but 1120
is what was in the box).
Both video and audio for DVB-T work fine but for analogue TV, although the
video
is good, the audio is very poor indeed. By very poor, I mean that although the
sound is in sync and I can tell that words are being spoken, it is very crackly
and I have to listen really carefully to make out an odd word ort two of what
is being said. The analogue signal I am trying to watch is from the RF2 output
on my Sky satellite box. It is piped round the house (and boosted in the loft)
and reception if very good on the TV's in the adjacent rooms. Indeed, I get
good sound and video on my PC through the Pinnacle PCTV Pro that I also have
installed (bttv driver). The bttv card is taking up the other PCI slot that I
need it for something else.
I am using mplayer to watch and I call it like this:
mplayer tv:// -tv
driver=v4l2:device=/dev/wintvvideo:buffersize=32:channel=38:alsa:adevice=hw.2,0:amode=1:audiorate=32000:immediatemode=0:forceaudio:norm=PAL
-aspect
16:9
/dev/wintvvideo is a symlink to /dev/v4l/video1, set up via udev
The output from 'arecord -l' is:
List of CAPTURE Hardware Devices
card 0: Intel [HDA Intel], device 0: ALC888 Analog [ALC888 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: ALC888 Digital [ALC888 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 2: ALC888 Analog [ALC888 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Bt878 [Brooktree Bt878], device 0: Bt87x Digital [Bt87x Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Bt878 [Brooktree Bt878], device 1: Bt87x Analog [Bt87x Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: SAA7134 [SAA7134], device 0: SAA7134 PCM [SAA7134 PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
amixer reports:
[chris:~]$ amixer -c 2 scontrols
Simple mixer control 'Line',1
Simple mixer control 'Line',2
Simple mixer control 'Video',0
and:
[chris:~]$ amixer -c 2 scontents
Simple mixer control 'Line',1
Capabilities: volume cswitch penum
Playback channels: Front Left - Front Right
Capture channels: Front Left - Front Right
Limits: 0 - 20
Front Left: 20 [100%] Capture [off]
Front Right: 20 [100%] Capture [off]
Simple mixer control 'Line',2
Capabilities: volume cswitch penum
Playback channels: Front Left - Front Right
Capture channels: Front Left - Front Right
Limits: 0 - 20
Front Left: 20 [100%] Capture [off]
Front Right: 20 [100%] Capture [off]
Simple mixer control 'Video',0
Capabilities: volume cswitch penum
Playback channels: Front Left - Front Right
Capture channels: Front Left - Front Right
Limits: 0 - 20
Front Left: 20 [100%] Capture [on]
Front Right: 20 [100%] Capture [on]
I've also tried redirecting the audio using sox, but I get the same poor quality
sox --buffer 65536 -c 2 -s -r 32000 -t alsa hw:2,0 -r 32000 -t alsa hw:0,0
I've also read dozens of articles and posts that google turns up, but found
nothing that works. A couple of postings mentioned using regspy to get some
gpio data, so I've done that and the results are:
DVB-T:
SAA7134_GPIO_GPMODE 06800101
SAA7134_GPIO_GPSTATUS 06040001
Analogue:
SAA7134_GPIO_GPMODE 06800101
SAA7134_GPIO_GPSTATUS 02040001
Radio:
SAA7134_GPIO_GPMODE 06800101
SAA7134_GPIO_GPSTATUS 02840001
Although I'm my no means certain that I was doing the right thing, I changed
the
HVR1120 entry in saa7134-card.c as shown in this patch:
--- linux-2.6/drivers/media/video/saa7134/saa7134-cards.c~ 2010-12-17
19:31:24.0 +
+++ linux-2.6/drivers/media/video/saa7134/saa7134-cards.c 2010-12-17
19:33:31.0 +
@@ -3461,13 +3461,13 @@ struct saa7134_board saa7134_boards[] =
.tuner_config = 3,
.mpeg = SAA7134_MPEG_DVB,
.ts_type= SAA7134_MPEG_TS_SERIAL,
- .gpiomask = 0x0800100, /* GPIO 21 is an INPUT */
+ .gpiomask = 0x6800101, /* GPIO 21 is an INPUT */
.inputs = {{
.name = name_tv,
.vmux = 1,
.amux = TV,
.tv = 1,
- .gpio = 0x100,
+ .gpio = 0x2040001,
}, {
.name = name_comp1,
.vmux = 3,
@@ -3480,7 +3480,7 @@ struct saa7134_board saa7134_boards[] =
.radio = {
.name = name_radio,
.amux = TV,
- .gpio = 0x0800100, /* GPIO 23 HI for FM */
+ .gpio = 0x2840001, /* GPIO 23 HI for FM */
},
},
Re: [PATCH] [media] cx231xx: Fix inverted bits for RC on PV Hybrid
On Fri, 2010-12-17 at 15:22 -0200, Mauro Carvalho Chehab wrote:
At Pixelview SBTVD Hybrid, the bits sent by the IR are inverted. Due to that,
the existing keytables produce wrong codes.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx231xx/cx231xx-input.c
b/drivers/media/video/cx231xx/cx231xx-input.c
index c236a4e..45e14ca 100644
--- a/drivers/media/video/cx231xx/cx231xx-input.c
+++ b/drivers/media/video/cx231xx/cx231xx-input.c
@@ -27,7 +27,7 @@
static int get_key_isdbt(struct IR_i2c *ir, u32 *ir_key,
u32 *ir_raw)
{
- u8 cmd;
+ u8 cmd, scancode;
dev_dbg(ir-rc-input_dev-dev, %s\n, __func__);
@@ -42,10 +42,21 @@ static int get_key_isdbt(struct IR_i2c *ir, u32 *ir_key,
if (cmd == 0xff)
return 0;
- dev_dbg(ir-rc-input_dev-dev, scancode = %02x\n, cmd);
-
- *ir_key = cmd;
- *ir_raw = cmd;
+ scancode =
+ ((cmd 0x01) ? 0x80 : 0) |
+ ((cmd 0x02) ? 0x40 : 0) |
+ ((cmd 0x04) ? 0x20 : 0) |
+ ((cmd 0x08) ? 0x10 : 0) |
+ ((cmd 0x10) ? 0x08 : 0) |
+ ((cmd 0x20) ? 0x04 : 0) |
+ ((cmd 0x40) ? 0x02 : 0) |
+ ((cmd 0x80) ? 0x01 : 0);
I have to point out this alternate method just for fun:
http://www-graphics.stanford.edu/~seander/bithacks.html#ReverseByteWith32Bits
:D
Regards,
Andy
+ dev_dbg(ir-rc-input_dev-dev, cmd %02x, scan = %02x\n,
+ cmd, scancode);
+
+ *ir_key = scancode;
+ *ir_raw = scancode;
return 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
Re: tm6000 and IR
Hi Dmitri/Stefan, Em 17-12-2010 05:08, Dmitri Belimov escreveu: On Fri, 17 Dec 2010 06:18:31 +0100 Stefan Ringel stefan.rin...@arcor.de wrote: Am 17.12.2010 02:46, schrieb Dmitri Belimov: Hi Stefan Am 16.12.2010 10:38, schrieb Dmitri Belimov: Hi I think your mean is wrong. Our IR remotes send extended NEC it is 4 bytes. We removed inverted 4 byte and now we have 3 bytes from remotes. I think we must have full RCMAP with this 3 bytes from remotes. And use this remotes with some different IR recievers like some TV cards and LIRC-hardware and other. No need different RCMAP for the same remotes to different IR recievers like now. Your change doesn't work with my terratec remote control !! I found what happens. Try my new patch. What about NEC. Original NEC send address (inverted address) key (inverted key) this is realy old standart now all remotes use extended NEC (adress high) (address low) key (inverted key) The trident 5600/6000/6010 use old protocol but didn't test inverted address byte. I think much better discover really address value and write it to keytable. For your remotes I add low address byte. This value is incorrent but usefull for tm6000. When you found correct value update keytable. That is not acceptable. Have you forgotten what Mauro have written? The Terratec rc map are use from other devices. NO The RC_MAP_NEC_TERRATEC_CINERGY_XS used only in tm6000 module. My patch didn't kill support any other devices. That is not true. I search RC_MAP_NEC_TERRATEC_CINERGY_XS on FULL linux kernel sources. And found this string in: include/media/rc-map.h drivers/staging//tm6000/tm6000-cards.c drivers/media/rc/keymaps/rc-nec-terratec-cinergy-xs.c No any other devices didn't use this keymap. The best are only the received data without additional data. And I think the Trident chip send only compatibly data (send all extended data like standard data). The device decoded the protocols not the driver. You can't use this remotes with normal working IR receivers because this receivers returned FULL scancodes. Need add one more keytable. 1. With my variant we have one keytable of remote and some workaround in device drivers. And can switch keytable and remotes on the fly (of course when keytable has really value and device driver has workaround) 2. With your variant we have some keytables for one remote for different IR recevers. Can't use incompatible keytable with other IR recievers. It is black magic for understanding what remotes is working with this hardware. I think my variant much better. With my best regards, Dmitry. I think your variant is bad. Mauro we need your opinion about this question. I'm c/c Jarod, as he has a similar issue with some NEC-based boards (Apple variant). I also have experienced some cases where the NEC protocol in-hardware decoder can provide only part of the NEC extended range. I don't have a clear opinion about this issue, but I think that putting all our brains to think about that, we may have a solution for it. Let me summarize the issues. Please complete/correct me if is there anything else. 1) NEC original format is 16 bits. However, some variants use 24 bits for it (it is called, currently, NEC extended). A few other manufacturers, like Apple, defines NEC protocol with 32 bits, removing both address and command checksums. 2) NEC raw decoder is capable of decoding the entire NEC code, but it only accepts 16 or 24 bits, returning the scan code as: scancode = address 8 | command; for 16 bits, and: scancode = address 16 | not_address 8 | command; for 24 bits. There were some proposals to extend it to something like: scancode = address 24 | not_address 16 | not_command 8 | command; (or some other bit order) Or just return the complete 32 bits even for the original NEC protocol. However, changing it will break the existing userspace decoding tables. Another way would be to store the length of the scancode, using it as well during the scancode-keycode translation. But no patches were merged yet. 3) Some hardware decoders can't return the complete NEC address. There are variants that returns 8 bits, others that returns 16 bits, and others that return the complete code. For hardware that returns only 8 bits, we currently address the issue by using a scancode mask. When scanmask is set at the rc structs, the scancode-keycode logic will consider only the bits that are in the mask. 4) Some hardware filters the NEC address, returning only the codes for some specific vendors. Despite all discussions, we didn't reach an agreement yet. There are some points to consider whatever solution we do: 1) A keycode table should be able to work with a generic raw decoder. So, on all drivers, the bit order and the number of bits for a given protocol should be the same; 2) we should avoid to cause regressions on the existing definitions. That's said, suggestions
Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal
Hi Mauro, On Friday 17 December 2010 18:09:39 Mauro Carvalho Chehab wrote: Em 14-12-2010 08:55, Laurent Pinchart escreveu: Hi Mauro, Please don't forget this pull request for 2.6.37. Pull request for upstream sent today. Thank you. I didn't find any regressions at the BKL removal patches, but I noticed a few issues with qv4l2, not all related to uvcvideo. The remaining of this email is an attempt to document them for later fixes. They don't seem to be regressions caused by BKL removal, but the better would be to fix them later. - with uvcvideo and two video apps, if qv4l2 is started first, the second application doesn't start/capture. I suspect that REQBUFS (used by qv4l2 to probe mmap/userptr capabilities) create some resource locking at uvcvideo. The proper way is to lock the resources only if the driver is streaming, as other drivers and videobuf do. I don't agree with that. The uvcvideo driver has one buffer queue per device, so if an application requests buffers on one file handle it will lock other applications out. If the driver didn't it would be subject to race conditions. - with saa7134 and qv4l2 (and after a fix for input capabilities): saa7134 and/or qv4l2 doesn't seem to work fine if video format is changed to a 60HZ format (NTSC or PAL/M). It keeps trying to use 576 lines, but the driver only works with 480 lines for those formats. So, if qv4l2 tries to capture with STD/M, it fails, except if the number of lines is manually fixed by the user. - at least with the saa7134 board I used for test, video capture fails on some conditions. This is not related to BKL patches. I suspect it may be some initialization failure with the tuner (tda8275/tda8290), but I didn't have time to dig into it, nor to test with a simpler saa7134 device. The device I used was an Avermedia m135. -- Regards, Laurent Pinchart -- 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
