Re: [PATCH] [media] s5p-jpeg: Adding Exynos7 Jpeg variant support
Hi Tony,
Sorry for late response, just got back from vacation.
On 12/19/2014 04:37 AM, Tony K Nadackal wrote:
Hi Jacek,
On Wednesday, December 17, 2014 7:46 PM Jacek Anaszewski wrote,
Hi Tony,
Thanks for the patches.
Thanks for the review.
Please process them with scripts/checkpatch.pl as you will be submitting the
next
version - they contain many coding style related issues.
I ran checkpatch before posting. Do you find any checkpatch related issues in
the patch?
There was a problem on my side, sorry for making confusion.
My remaining comments below.
[snip]
+ if (ctx-jpeg-variant-version == SJPEG_EXYNOS7) {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS7);
+ exynos4_jpeg_set_enc_out_fmt(jpeg-regs,
+ ctx-subsampling,
EXYNOS7_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg-regs,
+ ctx-out_q.fmt-fourcc,
+ EXYNOS7_SWAP_CHROMA_SHIFT);
+ } else {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS4);
+ exynos4_jpeg_set_enc_out_fmt(jpeg-regs,
+ ctx-subsampling,
EXYNOS4_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg-regs,
+ ctx-out_q.fmt-fourcc,
+ EXYNOS4_SWAP_CHROMA_SHIFT);
+ }
+
I'd implement it this way:
exynos4_jpeg_set_interrupt(jpeg-regs, ctx-jpeg-variant-version);
exynos4_jpeg_set_enc_out_fmt(jpeg-regs, ctx-subsampling,
(ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
EXYNOS4_ENC_FMT_MASK :
EXYNOS7_ENC_FMT_MASK);
exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-out_q.fmt-fourcc,
(ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
EXYNOS4_SWAP_CHROMA_SHIFT :
EXYNOS7_SWAP_CHROMA_SHIFT);
OK. Looks goods to me. Thanks for the suggestion.
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
exynos4_jpeg_set_encode_hoff_cnt(jpeg-regs,
ctx-out_q.fmt-fourcc);
} else {
exynos4_jpeg_sw_reset(jpeg-regs);
- exynos4_jpeg_set_interrupt(jpeg-regs);
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
- exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-cap_q.fmt-
fourcc);
- bitstream_size = DIV_ROUND_UP(ctx-out_q.size, 32);
+ if (ctx-jpeg-variant-version == SJPEG_EXYNOS7) {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS7);
+ exynos4_jpeg_set_huff_tbl(jpeg-regs);
+ exynos4_jpeg_set_huf_table_enable(jpeg-regs, 1);
+
+ /*
+* JPEG IP allows storing 4 quantization tables
+* We fill table 0 for luma and table 1 for chroma
+*/
+ exynos4_jpeg_set_qtbl_lum(jpeg-regs,
+ ctx-compr_quality);
+ exynos4_jpeg_set_qtbl_chr(jpeg-regs,
+ ctx-compr_quality);
Is it really required to setup quantization tables for encoding?
Without setting up the quantization tables, encoder is working fine.
But, as per Exynos7 User Manual setting up the quantization tables are required
for encoding also.
Actually I intended to ask if setting the quantization tables is
required for *decoding*, as you set it also in decoding path, whereas
for Exynos4 it is not required. I looks strange for me as quantization
tables are usually required only for encoding raw images.
The same is related to huffman tables.
+ exynos4_jpeg_set_stream_size(jpeg-regs, ctx-
cap_q.w,
+ ctx-cap_q.h);
For exynos4 this function writes the number of samples per line and number
lines of the resulting JPEG image and is used only during encoding. Is the
semantics of the related register different in case of Exynos7?
Yes. In case of Exynos7 Encoding, This step is required.
Ack.
[snip]
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.h
@@ -71,6 +71,7 @@
#define SJPEG_S5P1
#define SJPEG_EXYNOS3250 2
#define SJPEG_EXYNOS43
+#define SJPEG_EXYNOS7 4
As you adding a new variant I propose to turn these macros into enum.
Ok. I will make this change in my next version.
Thanks.
[snip]
-void exynos4_jpeg_set_interrupt(void __iomem *base)
+void exynos4_jpeg_set_interrupt(void
Re: [PATCH v2 1/2] [media] s5p-jpeg: Fix modification sequence of interrupt enable register
Hi Tony,
On 12/19/2014 08:37 AM, Tony K Nadackal wrote:
Fix the bug in modifying the interrupt enable register.
For Exynos4 this was not a bug as there are only five bit fields
used in the EXYNOS4_INT_EN_REG - all of them enable related
interrupt signal and EXYNOS4_INT_EN_ALL value is 0x1f which
just sets these bit fields to 1.
If for Exynos7 there are other bit fields in this register
and it has to be read prior setting to find out current
state then I'd parametrize this function with version argument
as you do it in the patch adding support for Exynos7, but
for Exynos4 case I'd left the behaviour as it is currenlty, i.e.
avoid reading the register and do it only for Exynos7 case.
Effectively, this patch is not required, as it doesn't fix
anything but adds redundant call to readl.
Signed-off-by: Tony K Nadackal tony...@samsung.com
---
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
index e53f13a..a61ff7e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -155,7 +155,10 @@ void exynos4_jpeg_set_enc_out_fmt(void __iomem *base,
unsigned int out_fmt)
void exynos4_jpeg_set_interrupt(void __iomem *base)
{
- writel(EXYNOS4_INT_EN_ALL, base + EXYNOS4_INT_EN_REG);
+ unsigned int reg;
+
+ reg = readl(base + EXYNOS4_INT_EN_REG) ~EXYNOS4_INT_EN_MASK;
+ writel(reg | EXYNOS4_INT_EN_ALL, base + EXYNOS4_INT_EN_REG);
}
unsigned int exynos4_jpeg_get_int_status(void __iomem *base)
--
Best Regards,
Jacek Anaszewski
--
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
tuners/mxl5005s.c: 2 * ternary operator problems ?
Hello there, [linux-3.19-rc3/drivers/media/tuners/mxl5005s.c:1817]: (style) Same expression in both branches of ternary operator. [linux-3.19-rc3/drivers/media/tuners/mxl5005s.c:1818]: (style) Same expression in both branches of ternary operator. Source code is status += MXL_ControlWrite(fe, RFSYN_EN_CHP_HIGAIN, state-Mode ? 1 : 1); status += MXL_ControlWrite(fe, EN_CHP_LIN_B, state-Mode ? 0 : 0); Suggest code rework. Regards David Binderman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] [media] s5p-jpeg: Adding Exynos7 JPEG variant
Hi Tony,
On 12/19/2014 08:38 AM, Tony K Nadackal wrote:
Fimp_jpeg used in Exynos7 is a revised version. Some register
configurations are slightly different from JPEG in Exynos4.
Added one more variant SJPEG_EXYNOS7 to handle these differences.
Signed-off-by: Tony K Nadackal tony...@samsung.com
---
.../bindings/media/exynos-jpeg-codec.txt | 2 +-
drivers/media/platform/s5p-jpeg/jpeg-core.c| 61 ++
drivers/media/platform/s5p-jpeg/jpeg-core.h| 10 ++--
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 32 ++--
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h | 8 +--
drivers/media/platform/s5p-jpeg/jpeg-regs.h| 17 --
6 files changed, 93 insertions(+), 37 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
index bf52ed4..cd19417 100644
--- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
+++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible : should be one of:
samsung,s5pv210-jpeg, samsung,exynos4210-jpeg,
- samsung,exynos3250-jpeg;
+ samsung,exynos3250-jpeg, samsung,exynos7-jpeg;
- reg : address and length of the JPEG codec IP register set;
- interrupts : specifies the JPEG codec IP interrupt;
- clock-names : should contain:
This should be put in a separate patch.
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 54fa5d9..204013e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1225,8 +1225,9 @@ static int s5p_jpeg_try_fmt_vid_cap(struct file *file,
void *priv,
return -EINVAL;
}
- if ((ctx-jpeg-variant-version != SJPEG_EXYNOS4) ||
- (ctx-mode != S5P_JPEG_DECODE))
+ if (((ctx-jpeg-variant-version != SJPEG_EXYNOS4)
+ (ctx-jpeg-variant-version != SJPEG_EXYNOS7)) ||
+ (ctx-mode != S5P_JPEG_DECODE))
goto exit;
/*
@@ -1349,7 +1350,8 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct, struct
v4l2_format *f)
* the JPEG_IMAGE_SIZE register. In order to avoid sysmmu
* page fault calculate proper buffer size in such a case.
*/
- if (ct-jpeg-variant-version == SJPEG_EXYNOS4
+ if (((ct-jpeg-variant-version == SJPEG_EXYNOS4) ||
+ (ct-jpeg-variant-version == SJPEG_EXYNOS7))
f_type == FMT_TYPE_OUTPUT ct-mode == S5P_JPEG_ENCODE)
q_data-size = exynos4_jpeg_get_output_buffer_size(ct,
f,
@@ -1901,7 +1903,8 @@ static void exynos4_jpeg_device_run(void *priv)
if (ctx-mode == S5P_JPEG_ENCODE) {
exynos4_jpeg_sw_reset(jpeg-regs);
- exynos4_jpeg_set_interrupt(jpeg-regs);
+ exynos4_jpeg_set_interrupt(jpeg-regs,
+ ctx-jpeg-variant-version);
exynos4_jpeg_set_huf_table_enable(jpeg-regs, 1);
exynos4_jpeg_set_huff_tbl(jpeg-regs);
@@ -1918,20 +1921,50 @@ static void exynos4_jpeg_device_run(void *priv)
exynos4_jpeg_set_stream_size(jpeg-regs, ctx-cap_q.w,
ctx-cap_q.h);
- exynos4_jpeg_set_enc_out_fmt(jpeg-regs, ctx-subsampling);
- exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-out_q.fmt-fourcc);
+ exynos4_jpeg_set_enc_out_fmt(jpeg-regs, ctx-subsampling,
+ (ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
+ EXYNOS4_ENC_FMT_MASK :
+ EXYNOS7_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-out_q.fmt-fourcc,
+ (ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
+ EXYNOS4_SWAP_CHROMA_SHIFT :
+ EXYNOS7_SWAP_CHROMA_SHIFT);
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
exynos4_jpeg_set_encode_hoff_cnt(jpeg-regs,
ctx-out_q.fmt-fourcc);
} else {
exynos4_jpeg_sw_reset(jpeg-regs);
- exynos4_jpeg_set_interrupt(jpeg-regs);
+ exynos4_jpeg_set_interrupt(jpeg-regs,
+ ctx-jpeg-variant-version);
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
- exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-cap_q.fmt-fourcc);
- bitstream_size = DIV_ROUND_UP(ctx-out_q.size, 32);
+
[PATCH] add raw video support for Samsung SUR40 touchscreen
This patch add support for the raw video stream from the Samsung SUR40
touchscreen device. Existing input device support is not affected by this
patch and can be used concurrently. videobuf2-dma-contig is used for buffer
management. All tests from current v4l2-compliance -s run pass (see
http://floe.butterbrot.org/external/results.txt for details).
Note: I'm intentionally using dma-contig instead of vmalloc, as the USB
core apparently _will_ try to use DMA for larger bulk transfers.
Signed-off-by: Florian Echtler f...@butterbrot.org
---
drivers/input/touchscreen/sur40.c | 423 --
1 file changed, 411 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f1cb051..bcd9ee2 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1,7 +1,7 @@
/*
* Surface2.0/SUR40/PixelSense input driver
*
- * Copyright (c) 2013 by Florian 'floe' Echtler f...@butterbrot.org
+ * Copyright (c) 2014 by Florian 'floe' Echtler f...@butterbrot.org
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
@@ -12,6 +12,9 @@
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty cha...@enac.fr
*
+ * and from the v4l2-pci-skeleton driver,
+ * Copyright (c) Copyright 2014 Cisco Systems, Inc.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -31,6 +34,11 @@
#include linux/input-polldev.h
#include linux/input/mt.h
#include linux/usb/input.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-dev.h
+#include media/v4l2-ioctl.h
+#include media/videobuf2-dma-contig.h
/* read 512 bytes from endpoint 0x86 - get header + blobs */
struct sur40_header {
@@ -82,9 +90,19 @@ struct sur40_data {
struct sur40_blob blobs[];
} __packed;
+/* read 512 bytes from endpoint 0x82 - get header below
+ * continue reading 16k blocks until header.size bytes read */
+struct sur40_image_header {
+ __le32 magic; /* SUBF */
+ __le32 packet_id;
+ __le32 size; /* always 0x0007e900 = 960x540 */
+ __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
+ __le32 unknown; /* epoch? always 02/03 00 00 00 */
+} __packed;
/* version information */
#define DRIVER_SHORT sur40
+#define DRIVER_LONGSamsung SUR40
#define DRIVER_AUTHOR Florian 'floe' Echtler f...@butterbrot.org
#define DRIVER_DESCSurface2.0/SUR40/PixelSense input driver
@@ -99,6 +117,13 @@ struct sur40_data {
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
+/* video data endpoint */
+#define VIDEO_ENDPOINT 0x82
+
+/* video header fields */
+#define VIDEO_HEADER_MAGIC 0x46425553
+#define VIDEO_PACKET_SIZE 16384
+
/* polling interval (ms) */
#define POLL_INTERVAL 10
@@ -113,21 +138,23 @@ struct sur40_data {
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
-/*
- * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
- * here by mistake which is very likely to have corrupted the firmware EEPROM
- * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
- * Should you ever run into a similar problem, the background story to this
- * incident and instructions on how to fix the corrupted EEPROM are available
- * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
-*/
-
+/* master device state */
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
+ struct v4l2_device v4l2;
+ struct video_device vdev;
+ struct mutex lock;
+
+ struct vb2_queue queue;
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct list_head buf_list;
+ spinlock_t qlock;
+ int sequence;
+
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
@@ -135,6 +162,27 @@ struct sur40_state {
char phys[64];
};
+struct sur40_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+/* forward declarations */
+static struct video_device sur40_video_device;
+static struct v4l2_pix_format sur40_video_format;
+static struct vb2_queue sur40_queue;
+static void sur40_process_video(struct sur40_state *sur40);
+
+/*
+ * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
+ * here by mistake which is very likely to have corrupted the firmware EEPROM
+ * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
+ * Should you ever run into a similar problem, the background story to this
+ * incident and instructions on how to fix the corrupted EEPROM are available
+ * at
[patch] [media] gspca: underflow in vidioc_s_parm()
n is a user controlled integer. The code here doesn't handle the case where n is negative and this causes a static checker warning. drivers/media/usb/gspca/gspca.c:1571 vidioc_s_parm() warn: no lower bound on 'n' Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- I haven't followed through to see if this is a real problem. diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c index 43d6505..27f7da1 100644 --- a/drivers/media/usb/gspca/gspca.c +++ b/drivers/media/usb/gspca/gspca.c @@ -1565,6 +1565,8 @@ static int vidioc_s_parm(struct file *filp, void *priv, int n; n = parm-parm.capture.readbuffers; + if (n 0) + return -EINVAL; if (n == 0 || n = GSPCA_MAX_FRAMES) parm-parm.capture.readbuffers = gspca_dev-nbufread; else -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 2/2] [media] s5p-jpeg: Adding Exynos7 JPEG variant
Hi Jacek, On Wednesday, January 07, 2015 3:43 PM : Jacek Anaszewski wrote, Hi Tony, On 12/19/2014 08:38 AM, Tony K Nadackal wrote: Fimp_jpeg used in Exynos7 is a revised version. Some register configurations are slightly different from JPEG in Exynos4. Added one more variant SJPEG_EXYNOS7 to handle these differences. Signed-off-by: Tony K Nadackal tony...@samsung.com --- .../bindings/media/exynos-jpeg-codec.txt | 2 +- drivers/media/platform/s5p-jpeg/jpeg-core.c| 61 ++- --- drivers/media/platform/s5p-jpeg/jpeg-core.h| 10 ++-- drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 32 ++-- drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h | 8 +-- drivers/media/platform/s5p-jpeg/jpeg-regs.h| 17 -- 6 files changed, 93 insertions(+), 37 deletions(-) diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt index bf52ed4..cd19417 100644 --- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt +++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt @@ -4,7 +4,7 @@ Required properties: - compatible : should be one of: samsung,s5pv210-jpeg, samsung,exynos4210-jpeg, - samsung,exynos3250-jpeg; + samsung,exynos3250-jpeg, samsung,exynos7-jpeg; - reg : address and length of the JPEG codec IP register set; - interrupts : specifies the JPEG codec IP interrupt; - clock-names : should contain: This should be put in a separate patch. Checkpatch gives warning if this change is not there. If that is ok with you, I will make this change a separate patch. [snip] -- Best Regards, Jacek Anaszewski Thanks and Regards, Tony -- 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: [PATCHv3 10/20] cx25840: fill the media controller entity
Hi Mauro,
Thanks for the patch.
On Tue, Jan 6, 2015 at 9:08 PM, Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:
Instead of keeping the media controller entity not initialized,
fill it and create the pads for cx25840.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/i2c/cx25840/cx25840-core.c
b/drivers/media/i2c/cx25840/cx25840-core.c
index 573e08826b9b..bdb5bb6b58da 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -5137,6 +5137,9 @@ static int cx25840_probe(struct i2c_client *client,
int default_volume;
u32 id;
u16 device_id;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ int ret;
+#endif
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(client-adapter,
I2C_FUNC_SMBUS_BYTE_DATA))
@@ -5178,6 +5181,21 @@ static int cx25840_probe(struct i2c_client *client,
sd = state-sd;
v4l2_i2c_subdev_init(sd, client, cx25840_ops);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ /* TODO: need to represent analog inputs too */
+ state-pads[0].flags = MEDIA_PAD_FL_SINK; /* Tuner or input */
| MEDIA_PAD_FL_MUST_CONNECT ?
+ state-pads[1].flags = MEDIA_PAD_FL_SOURCE; /* Video */
+ state-pads[2].flags = MEDIA_PAD_FL_SOURCE; /* VBI */
Macros for 0,1,2, and 3 would make it more readable.
+ sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+
+ ret = media_entity_init(sd-entity, ARRAY_SIZE(state-pads),
+ state-pads, 0);
+ if (ret 0) {
+ v4l_info(client, failed to initialize media entity!\n);
+ kfree(state);
Not required.
+ return -ENODEV;
return ret; instead ?
Thanks,
--Prabhakar Lad
--
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: [PATCHv3 10/20] cx25840: fill the media controller entity
Hi Prabhakar,
Em Wed, 7 Jan 2015 11:44:08 +
Prabhakar Lad prabhakar.cse...@gmail.com escreveu:
Hi Mauro,
Thanks for the patch.
Thanks for review.
On Tue, Jan 6, 2015 at 9:08 PM, Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:
Instead of keeping the media controller entity not initialized,
fill it and create the pads for cx25840.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/i2c/cx25840/cx25840-core.c
b/drivers/media/i2c/cx25840/cx25840-core.c
index 573e08826b9b..bdb5bb6b58da 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -5137,6 +5137,9 @@ static int cx25840_probe(struct i2c_client *client,
int default_volume;
u32 id;
u16 device_id;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ int ret;
+#endif
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(client-adapter,
I2C_FUNC_SMBUS_BYTE_DATA))
@@ -5178,6 +5181,21 @@ static int cx25840_probe(struct i2c_client *client,
sd = state-sd;
v4l2_i2c_subdev_init(sd, client, cx25840_ops);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ /* TODO: need to represent analog inputs too */
+ state-pads[0].flags = MEDIA_PAD_FL_SINK; /* Tuner or input */
| MEDIA_PAD_FL_MUST_CONNECT ?
Maybe. Currently, only omap3 uses this flag. Not sure what difference
it will make.
+ state-pads[1].flags = MEDIA_PAD_FL_SOURCE; /* Video */
+ state-pads[2].flags = MEDIA_PAD_FL_SOURCE; /* VBI */
Macros for 0,1,2, and 3 would make it more readable.
Yes, but IMHO the best would be to add those macros on some global place,
as all analog demod PADs will look the same: one sync to connect to the
tuner and two PADs, one for video stream and another one for VBI.
A few decoders may have an additional PAD for sliced-VBI.
Doing such definition globally helps to support drivers like em28xx,
where, depending on the board, there are several different alternatives
for the demod, all providing the very same 3 pads.
+ sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+
+ ret = media_entity_init(sd-entity, ARRAY_SIZE(state-pads),
+ state-pads, 0);
+ if (ret 0) {
+ v4l_info(client, failed to initialize media entity!\n);
+ kfree(state);
Not required.
Why not? state were allocated previously in this function. If we don't free
it, it will have a memory leak.
+ return -ENODEV;
return ret; instead ?
Yeah, makes sense. I'll fix that on a next spin of the patch.
Thanks,
--Prabhakar Lad
--
Cheers,
Mauro
--
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] dvb-usb-friio: split and merge into dvb-usbv2-gl861
From: Akihiro Tsukada tsk...@gmail.com
A Friio device consists of a GL861 adapter/bridge chip,
a TC90522 demod chip and a TUA6034 tuner chip, but
the friio driver was implemented as one combined driver.
This patch separates off the each chip drivers and
re-uses the existing modules: dvb-usbv2-gl861,tc90522.
It also adds some modifications to gl861,
to support the black-boxed init/config of friio devices and
implement an usb vendor request that is used for
relay'ed i2c communications to a tuner via a demod.
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
drivers/media/usb/dvb-usb-v2/Kconfig | 5 +-
drivers/media/usb/dvb-usb-v2/Makefile | 2 +-
drivers/media/usb/dvb-usb-v2/gl861-friio.c | 318 ++
drivers/media/usb/dvb-usb-v2/gl861.c | 125 ++-
drivers/media/usb/dvb-usb-v2/gl861.h | 11 +
drivers/media/usb/dvb-usb/Kconfig | 6 -
drivers/media/usb/dvb-usb/Makefile | 3 -
drivers/media/usb/dvb-usb/friio-fe.c | 472 --
drivers/media/usb/dvb-usb/friio.c | 522 -
drivers/media/usb/dvb-usb/friio.h | 99 --
10 files changed, 445 insertions(+), 1118 deletions(-)
create mode 100644 drivers/media/usb/dvb-usb-v2/gl861-friio.c
delete mode 100644 drivers/media/usb/dvb-usb/friio-fe.c
delete mode 100644 drivers/media/usb/dvb-usb/friio.c
delete mode 100644 drivers/media/usb/dvb-usb/friio.h
diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
b/drivers/media/usb/dvb-usb-v2/Kconfig
index 7423033..79694d3 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@@ -95,10 +95,13 @@ config DVB_USB_GL861
tristate Genesys Logic GL861 USB2.0 support
depends on DVB_USB_V2
select DVB_ZL10353 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
+ select MEDIA_TUNER_TUA6034 if MEDIA_SUBDRV_AUTOSELECT
help
Say Y here to support the MSI Megasky 580 (55801) DVB-T USB2.0
- receiver with USB ID 0db0:5581.
+ receiver with USB ID 0db0:5581, or 774 Friio White ISDB-T
+ USB2.0 receiver with USB ID 7a69:0001.
config DVB_USB_LME2510
tristate LME DM04/QQBOX DVB-S USB2.0 support
diff --git a/drivers/media/usb/dvb-usb-v2/Makefile
b/drivers/media/usb/dvb-usb-v2/Makefile
index f10d4df..70c0c9f 100644
--- a/drivers/media/usb/dvb-usb-v2/Makefile
+++ b/drivers/media/usb/dvb-usb-v2/Makefile
@@ -25,7 +25,7 @@ obj-$(CONFIG_DVB_USB_EC168) += dvb-usb-ec168.o
dvb-usb-lmedm04-objs := lmedm04.o
obj-$(CONFIG_DVB_USB_LME2510) += dvb-usb-lmedm04.o
-dvb-usb-gl861-objs := gl861.o
+dvb-usb-gl861-objs := gl861.o gl861-friio.o
obj-$(CONFIG_DVB_USB_GL861) += dvb-usb-gl861.o
dvb-usb-mxl111sf-objs += mxl111sf.o mxl111sf-phy.o mxl111sf-i2c.o
diff --git a/drivers/media/usb/dvb-usb-v2/gl861-friio.c
b/drivers/media/usb/dvb-usb-v2/gl861-friio.c
new file mode 100644
index 000..b1942d2
--- /dev/null
+++ b/drivers/media/usb/dvb-usb-v2/gl861-friio.c
@@ -0,0 +1,318 @@
+/*
+ * GL861 DTV USB bridge driver
+ * Friio White specific part
+ * Copyright (C) 2014 Akihiro Tsukada tsk...@gmail.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 version 2.
+ *
+ *
+ * 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.
+ */
+
+#include dvb_i2c.h
+#include dvb_frontend.h
+
+#include gl861.h
+#include tc90522.h
+#include tua6034.h
+
+struct friio_priv {
+ struct i2c_adapter *demod_sub_i2c;
+};
+
+struct friio_config {
+ struct i2c_board_info demod_info;
+ struct tc90522_config demod_cfg;
+
+ struct i2c_board_info tuner_info;
+ struct tua6034_config tuner_cfg;
+};
+
+static const struct friio_config friio_config = {
+ .demod_info = { I2C_BOARD_INFO(TC90522_I2C_DEV_TER, 0x18), },
+ .tuner_info = { I2C_BOARD_INFO(tua6034, 0x60), },
+ .tuner_cfg = {
+ .agc_tkov = TUA6034_AGC_103dBuV,
+ .ports = TUA6034_PORT4_ON,
+ .cp_cur = TUA6034_CP_50uA,
+ },
+};
+
+
+#define FRIIO_CTL_LNB (1 0)
+#define FRIIO_CTL_STROBE (1 1)
+#define FRIIO_CTL_CLK (1 2)
+#define FRIIO_CTL_LED (1 3)
+
+#define FRIIO_LED_RUNNING 0x6400ff64
+#define FRIIO_LED_STOPPED 0x96ff00ff
+
+/* control PIC16F676 attached to this chip */
+static int friio_ext_ctl(struct dvb_usb_device *d,
+ u32 sat_color, int power_on)
+{
+ int i, ret;
+ struct i2c_msg msg;
+ u8 *buf;
+ u32 mask;
+ u8 power = (power_on) ? FRIIO_CTL_LNB : 0;
+
+ buf = kmalloc(2, GFP_KERNEL);
+ if (!buf)
+
[PATCH 1/2] dvb: tua6034: add a new driver for Infineon tua6034 tuner
From: Akihiro Tsukada tsk...@gmail.com
this digital tuner chip is used in Friio (dvb-usb-friio),
and its driver code was buried in friio-fe.c.
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
drivers/media/tuners/Kconfig | 7 +
drivers/media/tuners/Makefile | 1 +
drivers/media/tuners/tua6034.c | 464 +
drivers/media/tuners/tua6034.h | 113 ++
4 files changed, 585 insertions(+)
create mode 100644 drivers/media/tuners/tua6034.c
create mode 100644 drivers/media/tuners/tua6034.h
diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
index 42e5a01..6c15d28 100644
--- a/drivers/media/tuners/Kconfig
+++ b/drivers/media/tuners/Kconfig
@@ -282,4 +282,11 @@ config MEDIA_TUNER_QM1D1C0042
default m if !MEDIA_SUBDRV_AUTOSELECT
help
Sharp QM1D1C0042 trellis coded 8PSK tuner driver.
+
+config MEDIA_TUNER_TUA6034
+ tristate Infineon TUA6034 tuner
+ depends on MEDIA_SUPPORT I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ Infineon TUA6034 3-band ditigal TV tuner driver.
endmenu
diff --git a/drivers/media/tuners/Makefile b/drivers/media/tuners/Makefile
index da4fe6e..8c95c08 100644
--- a/drivers/media/tuners/Makefile
+++ b/drivers/media/tuners/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_MEDIA_TUNER_R820T) += r820t.o
obj-$(CONFIG_MEDIA_TUNER_MXL301RF) += mxl301rf.o
obj-$(CONFIG_MEDIA_TUNER_QM1D1C0042) += qm1d1c0042.o
obj-$(CONFIG_MEDIA_TUNER_M88RS6000T) += m88rs6000t.o
+obj-$(CONFIG_MEDIA_TUNER_TUA6034) += tua6034.o
ccflags-y += -I$(srctree)/drivers/media/dvb-core
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
diff --git a/drivers/media/tuners/tua6034.c b/drivers/media/tuners/tua6034.c
new file mode 100644
index 000..7cbc185
--- /dev/null
+++ b/drivers/media/tuners/tua6034.c
@@ -0,0 +1,464 @@
+/*
+ * Infineon TUA6034 terrestial tuner driver
+ *
+ * Copyright (C) 2014 Akihiro Tsukada tsk...@gmail.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 version 2.
+ *
+ *
+ * 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.
+ */
+
+#include linux/kernel.h
+#include dvb_i2c.h
+#include tua6034.h
+
+#define TUA6034_XTL_FREQ 400
+
+struct tua6034_state {
+ struct tua6034_config cfg;
+ struct i2c_client *i2c;
+
+ /* current parameters (except frequency divider) */
+ u8 ctrl_byte;
+ u8 band_sw_byte;
+ u8 aux_byte;
+};
+
+struct def_param {
+ /* for auto band selection */
+ u32 band_sw_freq[4]; /* fmin, flow_mid, fmid_high, fmax */
+
+ /* for auto CP current selection */
+ /* band:[low, mid, high] x cp:[50uA/125uA,125uA/250uA,250uA/650uA] */
+ u32 cp_sw_freq[3][3];
+ u32 if_freq;
+ u32 if_bw;
+ enum tua6034_ref_div ref_div;
+};
+
+/* per-DELSYS default configuration */
+static const struct def_param def_cfgs[] = {
+ /* ISDB-T */
+ {
+ .band_sw_freq = {9000, 17000, 47000, 9},
+ .cp_sw_freq = {
+ {0, 0, 17000},
+ {0, 27000, 37000},
+ {0, 0, 67000}
+ },
+
+ .if_freq = 5700,
+ .if_bw = 600,
+ .ref_div = TUA6034_REF_DIV_1_28,
+ },
+
+ /* DVB-T */
+ {
+ .band_sw_freq = {4425, 15750, 44300, 9},
+ .cp_sw_freq = {
+ {0, 14050, 15750},
+ {0, 44300, 0},
+ {0, 80200, 9}
+ },
+
+ .if_freq = 36125000,
+ .if_bw = 800,
+ .ref_div = TUA6034_REF_DIV_1_24,
+ },
+
+ /* ATSC */
+ {
+ .band_sw_freq = {5000, 16000, 45400, 9},
+ .cp_sw_freq = {
+ {0, 16000, 0},
+ {0, 45400, 0},
+ {0, 9, 0}
+ },
+
+ .if_freq = 4400,
+ .if_bw = 600,
+ .ref_div = TUA6034_REF_DIV_1_64,
+ },
+};
+
+
+static int raw_write(struct tua6034_state *state, const u8 *buf, int len)
+{
+ int ret;
+
+ ret = i2c_master_send(state-i2c, buf, len);
+ if (ret = 0 ret len)
+ ret = -EIO;
+ return (ret == len) ? 0 : ret;
+}
+
+static int raw_read(struct tua6034_state *state, u8 *val)
+{
+ int ret;
+
+ ret = i2c_master_recv(state-i2c, val, 1);
+ if (ret = 0 ret 1)
+ ret = -EIO;
+ return (ret == 1) ? 0 : ret;
+}
+
+static int
[PATCH 0/2] split dvb-usb-friio into parts
From: Akihiro Tsukada tsk...@gmail.coma This patch series decomposes the friio driver which was monolithic into adapter,demod,tuner modules. Akihiro Tsukada (2): dvb: tua6034: add a new driver for Infineon tua6034 tuner dvb-usb-friio: split and merge into dvb-usbv2-gl861 drivers/media/tuners/Kconfig | 7 + drivers/media/tuners/Makefile | 1 + drivers/media/tuners/tua6034.c | 464 + drivers/media/tuners/tua6034.h | 113 +++ drivers/media/usb/dvb-usb-v2/Kconfig | 5 +- drivers/media/usb/dvb-usb-v2/Makefile | 2 +- drivers/media/usb/dvb-usb-v2/gl861-friio.c | 318 ++ drivers/media/usb/dvb-usb-v2/gl861.c | 125 ++- drivers/media/usb/dvb-usb-v2/gl861.h | 11 + drivers/media/usb/dvb-usb/Kconfig | 6 - drivers/media/usb/dvb-usb/Makefile | 3 - drivers/media/usb/dvb-usb/friio-fe.c | 472 -- drivers/media/usb/dvb-usb/friio.c | 522 - drivers/media/usb/dvb-usb/friio.h | 99 -- 14 files changed, 1030 insertions(+), 1118 deletions(-) create mode 100644 drivers/media/tuners/tua6034.c create mode 100644 drivers/media/tuners/tua6034.h create mode 100644 drivers/media/usb/dvb-usb-v2/gl861-friio.c delete mode 100644 drivers/media/usb/dvb-usb/friio-fe.c delete mode 100644 drivers/media/usb/dvb-usb/friio.c delete mode 100644 drivers/media/usb/dvb-usb/friio.h -- 2.2.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: [PATCH] media: Pinnacle 73e infrared control stopped working since kernel 3.17
No one is interested? I'd like to get this patch to kernel to fix the
issue. Can someone here do it please?
2014-12-20 14:36 GMT+01:00 David Cimbůrek david.cimbu...@gmail.com:
Hi,
with kernel 3.17 remote control for Pinnacle 73e (ID 2304:0237
Pinnacle Systems, Inc. PCTV 73e [DiBcom DiB7000PC]) does not work
anymore.
I checked the changes and found out the problem in commit
af3a4a9bbeb00df3e42e77240b4cdac5479812f9.
In dib0700_core.c in struct dib0700_rc_response the following union:
union {
u16 system16;
struct {
u8 not_system;
u8 system;
};
};
has been replaced by simple variables:
u8 system;
u8 not_system;
But these variables are in reverse order! When I switch the order
back, the remote works fine again! Here is the patch:
--- a/drivers/media/usb/dvb-usr/dib0700_core.c2014-12-20
14:27:15.0 +0100
+++ b/drivers/media/usb/dvb-usr/dib0700_core.c2014-12-20
14:27:36.0 +0100
@@ -658,8 +658,8 @@
struct dib0700_rc_response {
u8 report_id;
u8 data_state;
-u8 system;
u8 not_system;
+u8 system;
u8 data;
u8 not_data;
};
Regards,
David
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] [media] s5p-jpeg: Adding Exynos7 JPEG variant
Hi Tony, On 01/07/2015 12:22 PM, Tony K Nadackal wrote: Hi Jacek, On Wednesday, January 07, 2015 3:43 PM : Jacek Anaszewski wrote, Hi Tony, On 12/19/2014 08:38 AM, Tony K Nadackal wrote: Fimp_jpeg used in Exynos7 is a revised version. Some register configurations are slightly different from JPEG in Exynos4. Added one more variant SJPEG_EXYNOS7 to handle these differences. Signed-off-by: Tony K Nadackal tony...@samsung.com --- .../bindings/media/exynos-jpeg-codec.txt | 2 +- drivers/media/platform/s5p-jpeg/jpeg-core.c| 61 ++- --- drivers/media/platform/s5p-jpeg/jpeg-core.h| 10 ++-- drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 32 ++-- drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h | 8 +-- drivers/media/platform/s5p-jpeg/jpeg-regs.h| 17 -- 6 files changed, 93 insertions(+), 37 deletions(-) diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt index bf52ed4..cd19417 100644 --- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt +++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt @@ -4,7 +4,7 @@ Required properties: - compatible : should be one of: samsung,s5pv210-jpeg, samsung,exynos4210-jpeg, - samsung,exynos3250-jpeg; + samsung,exynos3250-jpeg, samsung,exynos7-jpeg; - reg: address and length of the JPEG codec IP register set; - interrupts : specifies the JPEG codec IP interrupt; - clock-names : should contain: This should be put in a separate patch. Checkpatch gives warning if this change is not there. If that is ok with you, I will make this change a separate patch. If the patch updating the DT documentation will go first, then checkpatch shouldn't raise a warning. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] dvb: tc90522: use dvb-core i2c binding model template
From: Akihiro Tsukada tsk...@gmail.com
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
drivers/media/dvb-frontends/tc90522.c | 143 ++
drivers/media/dvb-frontends/tc90522.h | 8 +-
2 files changed, 63 insertions(+), 88 deletions(-)
diff --git a/drivers/media/dvb-frontends/tc90522.c
b/drivers/media/dvb-frontends/tc90522.c
index b35d65c..7d9c9cd 100644
--- a/drivers/media/dvb-frontends/tc90522.c
+++ b/drivers/media/dvb-frontends/tc90522.c
@@ -30,6 +30,7 @@
#include linux/kernel.h
#include linux/math64.h
#include linux/dvb/frontend.h
+#include dvb_i2c.h
#include dvb_math.h
#include tc90522.h
@@ -39,8 +40,6 @@
struct tc90522_state {
struct tc90522_config cfg;
- struct dvb_frontend fe;
- struct i2c_client *i2c_client;
struct i2c_adapter tuner_i2c;
bool lna;
@@ -52,18 +51,18 @@ struct reg_val {
};
static int
-reg_write(struct tc90522_state *state, const struct reg_val *regs, int num)
+reg_write(struct dvb_frontend *fe, const struct reg_val *regs, int num)
{
int i, ret;
struct i2c_msg msg;
ret = 0;
- msg.addr = state-i2c_client-addr;
+ msg.addr = fe-fe_i2c_client-addr;
msg.flags = 0;
msg.len = 2;
for (i = 0; i num; i++) {
msg.buf = (u8 *)regs[i];
- ret = i2c_transfer(state-i2c_client-adapter, msg, 1);
+ ret = i2c_transfer(fe-fe_i2c_client-adapter, msg, 1);
if (ret == 0)
ret = -EIO;
if (ret 0)
@@ -72,17 +71,17 @@ reg_write(struct tc90522_state *state, const struct reg_val
*regs, int num)
return 0;
}
-static int reg_read(struct tc90522_state *state, u8 reg, u8 *val, u8 len)
+static int reg_read(struct dvb_frontend *fe, u8 reg, u8 *val, u8 len)
{
struct i2c_msg msgs[2] = {
{
- .addr = state-i2c_client-addr,
+ .addr = fe-fe_i2c_client-addr,
.flags = 0,
.buf = reg,
.len = 1,
},
{
- .addr = state-i2c_client-addr,
+ .addr = fe-fe_i2c_client-addr,
.flags = I2C_M_RD,
.buf = val,
.len = len,
@@ -90,7 +89,7 @@ static int reg_read(struct tc90522_state *state, u8 reg, u8
*val, u8 len)
};
int ret;
- ret = i2c_transfer(state-i2c_client-adapter, msgs, ARRAY_SIZE(msgs));
+ ret = i2c_transfer(fe-fe_i2c_client-adapter, msgs, ARRAY_SIZE(msgs));
if (ret == ARRAY_SIZE(msgs))
ret = 0;
else if (ret = 0)
@@ -98,11 +97,6 @@ static int reg_read(struct tc90522_state *state, u8 reg, u8
*val, u8 len)
return ret;
}
-static struct tc90522_state *cfg_to_state(struct tc90522_config *c)
-{
- return container_of(c, struct tc90522_state, cfg);
-}
-
static int tc90522s_set_tsid(struct dvb_frontend *fe)
{
@@ -113,7 +107,7 @@ static int tc90522s_set_tsid(struct dvb_frontend *fe)
set_tsid[0].val = (fe-dtv_property_cache.stream_id 0xff00) 8;
set_tsid[1].val = fe-dtv_property_cache.stream_id 0xff;
- return reg_write(fe-demodulator_priv, set_tsid, ARRAY_SIZE(set_tsid));
+ return reg_write(fe, set_tsid, ARRAY_SIZE(set_tsid));
}
static int tc90522t_set_layers(struct dvb_frontend *fe)
@@ -125,19 +119,17 @@ static int tc90522t_set_layers(struct dvb_frontend *fe)
laysel = (laysel 0x01) 2 | (laysel 0x02) | (laysel 0x04) 2;
rv.reg = 0x71;
rv.val = laysel;
- return reg_write(fe-demodulator_priv, rv, 1);
+ return reg_write(fe, rv, 1);
}
/* frontend ops */
static int tc90522s_read_status(struct dvb_frontend *fe, fe_status_t *status)
{
- struct tc90522_state *state;
int ret;
u8 reg;
- state = fe-demodulator_priv;
- ret = reg_read(state, 0xc3, reg, 1);
+ ret = reg_read(fe, 0xc3, reg, 1);
if (ret 0)
return ret;
@@ -152,7 +144,7 @@ static int tc90522s_read_status(struct dvb_frontend *fe,
fe_status_t *status)
if (reg 0x10)
return 0;
- if (reg_read(state, 0xc5, reg, 1) 0 || !(reg 0x03))
+ if (reg_read(fe, 0xc5, reg, 1) 0 || !(reg 0x03))
return 0;
*status |= FE_HAS_LOCK;
return 0;
@@ -160,12 +152,10 @@ static int tc90522s_read_status(struct dvb_frontend *fe,
fe_status_t *status)
static int tc90522t_read_status(struct dvb_frontend *fe, fe_status_t *status)
{
- struct tc90522_state *state;
int ret;
u8 reg;
- state = fe-demodulator_priv;
- ret = reg_read(state, 0x96, reg, 1);
+ ret = reg_read(fe, 0x96, reg, 1);
if (ret 0)
return ret;
@@ -176,7 +166,7 @@ static int tc90522t_read_status(struct dvb_frontend *fe,
fe_status_t *status)
[PATCH v2 4/4] dvb: earth-pt3: use dvb-core i2c binding model template
From: Akihiro Tsukada tsk...@gmail.com
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
drivers/media/pci/pt3/pt3.c | 89 ++---
drivers/media/pci/pt3/pt3.h | 12 +++---
2 files changed, 33 insertions(+), 68 deletions(-)
diff --git a/drivers/media/pci/pt3/pt3.c b/drivers/media/pci/pt3/pt3.c
index 7a37e8f..31ffe83 100644
--- a/drivers/media/pci/pt3/pt3.c
+++ b/drivers/media/pci/pt3/pt3.c
@@ -26,6 +26,7 @@
#include dvbdev.h
#include dvb_demux.h
#include dvb_frontend.h
+#include dvb_i2c.h
#include pt3.h
@@ -103,12 +104,12 @@ pt3_demod_write(struct pt3_adapter *adap, const struct
reg_val *data, int num)
int i, ret;
ret = 0;
- msg.addr = adap-i2c_demod-addr;
+ msg.addr = adap-fe-fe_i2c_client-addr;
msg.flags = 0;
msg.len = 2;
for (i = 0; i num; i++) {
msg.buf = (u8 *)data[i];
- ret = i2c_transfer(adap-i2c_demod-adapter, msg, 1);
+ ret = i2c_transfer(adap-fe-fe_i2c_client-adapter, msg, 1);
if (ret == 0)
ret = -EREMOTE;
if (ret 0)
@@ -375,67 +376,38 @@ static int pt3_fe_init(struct pt3_board *pt3)
static int pt3_attach_fe(struct pt3_board *pt3, int i)
{
- struct i2c_board_info info;
- struct tc90522_config cfg;
- struct i2c_client *cl;
+ struct dvb_frontend *fe;
+ struct tc90522_out *out;
+ struct i2c_client *tuner_cl;
struct dvb_adapter *dvb_adap;
int ret;
- info = adap_conf[i].demod_info;
- cfg = adap_conf[i].demod_cfg;
- cfg.tuner_i2c = NULL;
- info.platform_data = cfg;
+ out = NULL;
+ fe = dvb_i2c_attach_fe(pt3-i2c_adap, adap_conf[i].demod_info,
+ adap_conf[i].demod_cfg, (void **)out);
+ if (!fe)
+ return -ENODEV;
ret = -ENODEV;
- request_module(tc90522);
- cl = i2c_new_device(pt3-i2c_adap, info);
- if (!cl || !cl-dev.driver)
- return -ENODEV;
- pt3-adaps[i]-i2c_demod = cl;
- if (!try_module_get(cl-dev.driver-owner))
- goto err_demod_i2c_unregister_device;
-
- if (!strncmp(cl-name, TC90522_I2C_DEV_SAT, sizeof(cl-name))) {
- struct qm1d1c0042_config tcfg;
-
- tcfg = adap_conf[i].tuner_cfg.qm1d1c0042;
- tcfg.fe = cfg.fe;
- info = adap_conf[i].tuner_info;
- info.platform_data = tcfg;
- request_module(qm1d1c0042);
- cl = i2c_new_device(cfg.tuner_i2c, info);
- } else {
- struct mxl301rf_config tcfg;
-
- tcfg = adap_conf[i].tuner_cfg.mxl301rf;
- tcfg.fe = cfg.fe;
- info = adap_conf[i].tuner_info;
- info.platform_data = tcfg;
- request_module(mxl301rf);
- cl = i2c_new_device(cfg.tuner_i2c, info);
- }
- if (!cl || !cl-dev.driver)
- goto err_demod_module_put;
- pt3-adaps[i]-i2c_tuner = cl;
- if (!try_module_get(cl-dev.driver-owner))
- goto err_tuner_i2c_unregister_device;
+ if (!out)
+ goto err;
+ tuner_cl = dvb_i2c_attach_tuner((out-demod_bus),
+ adap_conf[i].tuner_info, fe,
+ adap_conf[i].tuner_cfg, NULL);
+ if (!tuner_cl)
+ goto err;
dvb_adap = pt3-adaps[one_adapter ? 0 : i]-dvb_adap;
- ret = dvb_register_frontend(dvb_adap, cfg.fe);
+ ret = dvb_register_frontend(dvb_adap, fe);
if (ret 0)
- goto err_tuner_module_put;
- pt3-adaps[i]-fe = cfg.fe;
+ goto err;
+ pt3-adaps[i]-fe = fe;
return 0;
-err_tuner_module_put:
- module_put(pt3-adaps[i]-i2c_tuner-dev.driver-owner);
-err_tuner_i2c_unregister_device:
- i2c_unregister_device(pt3-adaps[i]-i2c_tuner);
-err_demod_module_put:
- module_put(pt3-adaps[i]-i2c_demod-dev.driver-owner);
-err_demod_i2c_unregister_device:
- i2c_unregister_device(pt3-adaps[i]-i2c_demod);
-
+err:
+ /* tuner i2c_client is unregister'ed as well, */
+ /* because it is a (grand) child of the demod i2c_client device */
+ i2c_unregister_device(fe-fe_i2c_client);
return ret;
}
@@ -630,17 +602,10 @@ static void pt3_cleanup_adapter(struct pt3_board *pt3,
int index)
dmx = adap-demux.dmx;
dmx-close(dmx);
if (adap-fe) {
- adap-fe-callback = NULL;
if (adap-fe-frontend_priv)
dvb_unregister_frontend(adap-fe);
- if (adap-i2c_tuner) {
- module_put(adap-i2c_tuner-dev.driver-owner);
- i2c_unregister_device(adap-i2c_tuner);
- }
- if (adap-i2c_demod) {
- module_put(adap-i2c_demod-dev.driver-owner);
-
Re: [PATCHv3 03/20] cx231xx: add media controller support
Hi Shuah, Em Wed, 7 Jan 2015 18:44:26 -0700 Shuah Khan shuahk...@gmail.com escreveu: + /* Create v4l2 device */ + dev-v4l2_dev.mdev = dev-media_dev; When media_device_register(mdev) fails in cx231xx_media_device_register(), media_dev is null? The above will simply assign null to dev-v4l2_dev.mdev Is that correct? Yes, this is intentional. If the media controls fail to register, everything will keep working, except for the media controller itself. That sounds better, IMHO, than to have a complete failure. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Jan 8 04:00:07 CET 2015 git branch: test git hash: 99f3cd52aee21091ce62442285a68873e3be833f gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16-i686: ERRORS linux-3.17-i686: ERRORS linux-3.18-i686: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16-x86_64: ERRORS linux-3.17-x86_64: ERRORS linux-3.18-x86_64: ERRORS apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Various fixes for s5p-mfc driver
Just a friendly reminder that this patch is pending review ;-P cheers, Nicolas Le 2014-12-15 16:10, Nicolas Dufresne a écrit : This patchset fixes ability to drain the decoder due to use of wrong enumeration name and fixes implementation of display delay controls for MFC firmware v6 and higher. Note that there is no need in the display delay fix for trying to be backward compatible with what the comment was saying since the control properties was preventing it. There was basically no way other then setting a large delay value to get the frames in display order. Nicolas Dufresne (3): s5p-mfc-v6+: Use display_delay_enable CID s5p-mfc-dec: Don't use encoder stop command media-doc: Fix MFC display delay control doc Documentation/DocBook/media/v4l/controls.xml| 11 +-- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 2 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 6 +- 3 files changed, 7 insertions(+), 12 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
[WISHLIST] Volume in tvtime not equal to alsamixer (logarithmic scale / mapped volume should be used)
It adjusts the volume linearly, while the correct behaviour is to adjust it logarithmically (in dB...). So the volume scale is incorrect, and the volume level isn't equal to alsamixer's. I use plain ALSA. VOLUME MAPPING: In alsamixer, the volume is mapped to a value that is more natural for a human ear. The mapping is designed so that the position in the interval is proportional to the volume as a human ear would perceive it, i.e. the position is the cubic root of the linear sample multiplication factor. For controls with a small range (24 dB or less), the mapping is linear in the dB values so that each step has the same size visually. Only for controls without dB information, a linear mapping of the hardware volume register values is used (this is the same algorithm as used in the old alsamixer). (I'm talking about http://git.alsa-project.org/?p=alsa-utils.git;a=blob;f=alsamixer/volume_mapping.c;h=1c0d7c45e6686239464e1b0bbc8983ea57f3914f;hb=HEAD ) -- 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] soc_camera: avoid potential null-dereference
On Wed, Jan 7, 2015 at 9:44 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Hi Andy,
Thanks for the patch. Will queue for the next pull request.
If you didn't do that please wait. It seems it has one more place with
similar issue. Moreover, I would like to add a person's name who
reported this.
Regards
Guennadi
On Wed, 7 Jan 2015, Andy Shevchenko wrote:
We have to check the pointer before dereferencing it.
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
---
drivers/media/platform/soc_camera/soc_camera.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index b3db51c..8c665c4 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -2166,7 +2166,7 @@ static int soc_camera_video_start(struct
soc_camera_device *icd)
static int soc_camera_pdrv_probe(struct platform_device *pdev)
{
struct soc_camera_desc *sdesc = pdev-dev.platform_data;
- struct soc_camera_subdev_desc *ssdd = sdesc-subdev_desc;
+ struct soc_camera_subdev_desc *ssdd;
struct soc_camera_device *icd;
int ret;
@@ -2177,6 +2177,8 @@ static int soc_camera_pdrv_probe(struct
platform_device *pdev)
if (!icd)
return -ENOMEM;
+ ssdd = sdesc-subdev_desc;
+
/*
* In the asynchronous case ssdd-num_regulators == 0 yet, so, the
below
* regulator allocation is a dummy. They are actually requested by the
--
1.8.3.101.g727a46b
--
With Best Regards,
Andy Shevchenko
--
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] soc_camera: avoid potential null-dereference
On Wed, Jan 7, 2015 at 10:05 PM, Andy Shevchenko
andy.shevche...@gmail.com wrote:
On Wed, Jan 7, 2015 at 9:44 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Hi Andy,
Thanks for the patch. Will queue for the next pull request.
If you didn't do that please wait. It seems it has one more place with
similar issue. Moreover, I would like to add a person's name who
reported this.
Okay, the second one is false positive.
And
Reported-by: Andrey Karpov kar...@viva64.com
Regards
Guennadi
On Wed, 7 Jan 2015, Andy Shevchenko wrote:
We have to check the pointer before dereferencing it.
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
---
drivers/media/platform/soc_camera/soc_camera.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index b3db51c..8c665c4 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -2166,7 +2166,7 @@ static int soc_camera_video_start(struct
soc_camera_device *icd)
static int soc_camera_pdrv_probe(struct platform_device *pdev)
{
struct soc_camera_desc *sdesc = pdev-dev.platform_data;
- struct soc_camera_subdev_desc *ssdd = sdesc-subdev_desc;
+ struct soc_camera_subdev_desc *ssdd;
struct soc_camera_device *icd;
int ret;
@@ -2177,6 +2177,8 @@ static int soc_camera_pdrv_probe(struct
platform_device *pdev)
if (!icd)
return -ENOMEM;
+ ssdd = sdesc-subdev_desc;
+
/*
* In the asynchronous case ssdd-num_regulators == 0 yet, so, the
below
* regulator allocation is a dummy. They are actually requested by the
--
1.8.3.101.g727a46b
--
With Best Regards,
Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
--
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
TBS 6981 IOMMU problems
Hello. After kernel upgrade 3.13 = 3.19 I started to receive different IOMMU related problems: Problem #1: AMD-Vi: Event logged [IO_PAGE_FAULT device=08:00.0 domain=0x001c address=0x004b5000 flags=0x] Problem #2: [ cut here ] WARNING: CPU: 0 PID: 6588 at drivers/iommu/amd_iommu.c:2637 dma_ops_domain_unmap.part.12+0x4d/0x56() Modules linked in: ip6table_filter ip6_tables act_police cls_basic cls_flow cls_fw cls_u32 sch_fq_codel sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_CHECKSUM ipt_rpfilter xt_statistic xt_CT xt_realm xt_addrtype xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 ipt_ECN ipt_CLUSTERIP ipt_ah xt_set nf_nat_ftp xt_time xt_TCPMSS xt_tcpmss xt_policy xt_pkttype xt_physdev br_netfilter xt_NFQUEUE xt_NFLOG xt_mark xt_mac xt_length xt_helper xt_hashlimit xt_DSCP xt_dscp xt_CLASSIFY xt_AUDIT iptable_raw iptable_nat nf_nat_ipv4 nf_nat iptable_mangle hwmon_vid bridge stp llc ipv6 cx24117 cx25840 uvcvideo snd_usb_audio videobuf2_vmalloc snd_hwdep snd_usbmidi_lib snd_rawmidi snd_hda_codec_hdmi ir_xmp_decoder ir_lirc_codec lirc_dev ir_mce_kbd_decoder ir_sharp_decoder ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_nec_decoder ir_rc5_decoder rc_rc6_mce microcode k10temp mceusb uas usb_storage usblp si2157 si2168 saa716x_budget saa716x_core sp5100_tco i2c_piix4 nouveau cx23885 i2c_algo_bit ttm tda18271 altera_stapl videobuf2_dvb videobuf2_core videobuf2_dma_sg videobuf2_memops drm_kms_helper tveeprom cx2341x dvb_core snd_hda_intel rc_core drm v4l2_common snd_hda_controller videodev snd_hda_codec r8169 mii CPU: 0 PID: 6588 Comm: w_scan Tainted: GW 3.19.0-rc3-myrc00 #1 Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 LE R2.0, BIOS 2501 04/09/2014 0009 ab636bd8 ab0bcd91 880099d4a300 ab4e282b 0046 8800b87ccd88 023b1000 0001 01f8 Call Trace: [ab636bd8] ? dump_stack+0x40/0x50 [ab0bcd91] ? warn_slowpath_common+0x93/0xab [ab4e282b] ? dma_ops_domain_unmap.part.12+0x4d/0x56 [ab4e282b] ? dma_ops_domain_unmap.part.12+0x4d/0x56 [ab4e41d5] ? __unmap_single.isra.15+0x7b/0xcf [ab4e4983] ? free_coherent+0x46/0x7e [c046a2e7] ? __vb2_queue_cancel+0x11b/0x12d [videobuf2_core] [c046c0a2] ? __reqbufs+0xf2/0x29d [videobuf2_core] [c046c345] ? vb2_thread_stop+0x6b/0xb1 [videobuf2_core] [c04760ce] ? vb2_dvb_stop_feed+0x41/0x58 [videobuf2_dvb] [ab16b1bc] ? poll_select_copy_remaining+0xf4/0xf4 [c041e066] ? dmx_section_feed_stop_filtering+0x40/0x7b [dvb_core] [c041cb0b] ? dvb_dmxdev_ts_callback+0xc2/0xc2 [dvb_core] [c041c2bb] ? dvb_dmxdev_feed_stop+0x5d/0x89 [dvb_core] [c041cb0b] ? dvb_dmxdev_ts_callback+0xc2/0xc2 [dvb_core] [c041c401] ? dvb_dmxdev_filter_stop+0x4e/0xb6 [dvb_core] [c041cb0b] ? dvb_dmxdev_ts_callback+0xc2/0xc2 [dvb_core] [c041cc29] ? dvb_demux_do_ioctl+0x11e/0x4d8 [dvb_core] [c041cb0b] ? dvb_dmxdev_ts_callback+0xc2/0xc2 [dvb_core] [c041b66d] ? dvb_usercopy+0xa7/0x127 [dvb_core] [c0423797] ? dvb_ringbuffer_read_user+0x6d/0x8e [dvb_core] [c041bf97] ? dvb_dmxdev_buffer_read.isra.2+0x5c/0x156 [dvb_core] [ab0e0c59] ? __wake_up+0x33/0x44 [c041b9f3] ? dvb_demux_ioctl+0xd/0x11 [dvb_core] [c041b9e6] ? dvb_dvr_ioctl+0x11/0x11 [dvb_core] [ab16a8fb] ? do_vfs_ioctl+0x360/0x424 [ab0ef6fb] ? timespec_add_safe+0x1c/0x48 [ab16a9f2] ? SyS_ioctl+0x33/0x58 [ab63be92] ? system_call_fastpath+0x12/0x17 ---[ end trace a7dc5ffa658175f6 ]--- Thoughts about above problems: Hardware: AMD Athlon(tm) II X2 240e Processor on Asus M5A97 LE R2.0 motherboard This bugs cause random consequences: nothing bad happens stop working one front end stop working both front ends This bugs are easily triggered if I run /w_scan/ on both front ends simultaneously Theoretically it is possible to disable IOMMU but: it will just hide problem, not solve it some devices on my system do not work without IOMMU Theoretically it is possible that there is bug in IOMMU code itself, because I had IOMMU related regression in kernels 3.14-3.17 which was solved in 3.17.7 Raimonds Cicans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/2] [media] s5p-jpeg: Fix modification sequence of interrupt enable register
Hi Jacek,
On Wednesday, January 07, 2015 3:38 PM Jacek Anaszewski wrote,
Hi Tony,
On 12/19/2014 08:37 AM, Tony K Nadackal wrote:
Fix the bug in modifying the interrupt enable register.
For Exynos4 this was not a bug as there are only five bit fields used in the
EXYNOS4_INT_EN_REG - all of them enable related interrupt signal and
EXYNOS4_INT_EN_ALL value is 0x1f which just sets these bit fields to 1.
I agree that it is not a bug.
I added the register read before modifying it to avoid any potential bugs in the
future.
If for Exynos7 there are other bit fields in this register and it has to be
read prior
setting to find out current state then I'd parametrize this function with
version
argument as you do it in the patch adding support for Exynos7, but for Exynos4
case I'd left the behaviour as it is currenlty, i.e.
avoid reading the register and do it only for Exynos7 case.
Directly writing the value EXYNOS4_INT_EN_ALL (0x1B6 in Exynos7) to
EXYNOS4_INT_EN_REG works in case of Exynos7 too.
I will parametrize this function with version to take care of the Exynos7 bit
fields.
Effectively, this patch is not required, as it doesn't fix anything but adds
redundant call to readl.
Signed-off-by: Tony K Nadackal tony...@samsung.com
---
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
index e53f13a..a61ff7e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -155,7 +155,10 @@ void exynos4_jpeg_set_enc_out_fmt(void __iomem
*base, unsigned int out_fmt)
void exynos4_jpeg_set_interrupt(void __iomem *base)
{
- writel(EXYNOS4_INT_EN_ALL, base + EXYNOS4_INT_EN_REG);
+ unsigned int reg;
+
+ reg = readl(base + EXYNOS4_INT_EN_REG) ~EXYNOS4_INT_EN_MASK;
+ writel(reg | EXYNOS4_INT_EN_ALL, base + EXYNOS4_INT_EN_REG);
}
unsigned int exynos4_jpeg_get_int_status(void __iomem *base)
--
Best Regards,
Jacek Anaszewski
Thanks and Regards,
Tony
--
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: [PATCHv3 03/20] cx231xx: add media controller support
On Tue, Jan 6, 2015 at 2:08 PM, Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:
Let's add media controller support for this driver and register it
for both V4L and DVB.
The media controller on this driver is not mandatory, as it can fully
work without it. So, if the media controller register fails, just print
an error message, but proceed with device registering.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index ae05d591f228..7e1c73a5172d 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -912,9 +912,6 @@ static inline void cx231xx_set_model(struct cx231xx *dev)
*/
void cx231xx_pre_card_setup(struct cx231xx *dev)
{
-
- cx231xx_set_model(dev);
-
dev_info(dev-dev, Identified as %s (card=%d)\n,
dev-board.name, dev-model);
@@ -1092,6 +1089,17 @@ void cx231xx_config_i2c(struct cx231xx *dev)
call_all(dev, video, s_stream, 1);
}
+static void cx231xx_unregister_media_device(struct cx231xx *dev)
+{
+#ifdef CONFIG_MEDIA_CONTROLLER
+ if (dev-media_dev) {
+ media_device_unregister(dev-media_dev);
+ kfree(dev-media_dev);
+ dev-media_dev = NULL;
+ }
+#endif
+}
+
/*
* cx231xx_realease_resources()
* unregisters the v4l2,i2c and usb devices
@@ -1099,6 +1107,8 @@ void cx231xx_config_i2c(struct cx231xx *dev)
*/
void cx231xx_release_resources(struct cx231xx *dev)
{
+ cx231xx_unregister_media_device(dev);
+
cx231xx_release_analog_resources(dev);
cx231xx_remove_from_devlist(dev);
@@ -1117,6 +1127,38 @@ void cx231xx_release_resources(struct cx231xx *dev)
clear_bit(dev-devno, cx231xx_devused);
}
+static void cx231xx_media_device_register(struct cx231xx *dev,
+ struct usb_device *udev)
+{
+#ifdef CONFIG_MEDIA_CONTROLLER
+ struct media_device *mdev;
+ int ret;
+
+ mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
+ if (!mdev)
+ return;
+
+ mdev-dev = dev-dev;
+ strlcpy(mdev-model, dev-board.name, sizeof(mdev-model));
+ if (udev-serial)
+ strlcpy(mdev-serial, udev-serial, sizeof(mdev-serial));
+ strcpy(mdev-bus_info, udev-devpath);
+ mdev-hw_revision = le16_to_cpu(udev-descriptor.bcdDevice);
+ mdev-driver_version = LINUX_VERSION_CODE;
+
+ ret = media_device_register(mdev);
+ if (ret) {
+ dev_err(dev-dev,
+ Couldn't create a media device. Error: %d\n,
+ ret);
+ kfree(mdev);
+ return;
+ }
+
+ dev-media_dev = mdev;
+#endif
+}
+
/*
* cx231xx_init_dev()
* allocates and inits the device structs, registers i2c bus and v4l device
@@ -1225,10 +1267,8 @@ static int cx231xx_init_dev(struct cx231xx *dev,
struct usb_device *udev,
}
retval = cx231xx_register_analog_devices(dev);
- if (retval) {
- cx231xx_release_analog_resources(dev);
+ if (retval)
goto err_analog;
- }
cx231xx_ir_init(dev);
@@ -1236,6 +1276,8 @@ static int cx231xx_init_dev(struct cx231xx *dev, struct
usb_device *udev,
return 0;
err_analog:
+ cx231xx_unregister_media_device(dev);
+ cx231xx_release_analog_resources(dev);
cx231xx_remove_from_devlist(dev);
err_dev_init:
cx231xx_dev_uninit(dev);
@@ -1437,6 +1479,8 @@ static int cx231xx_usb_probe(struct usb_interface
*interface,
dev-video_mode.alt = -1;
dev-dev = d;
+ cx231xx_set_model(dev);
+
dev-interface_count++;
/* reset gpio dir and value */
dev-gpio_dir = 0;
@@ -1501,7 +1545,11 @@ static int cx231xx_usb_probe(struct usb_interface
*interface,
/* save our data pointer in this interface device */
usb_set_intfdata(interface, dev);
+ /* Register the media controller */
+ cx231xx_media_device_register(dev, udev);
+
/* Create v4l2 device */
+ dev-v4l2_dev.mdev = dev-media_dev;
When media_device_register(mdev) fails in cx231xx_media_device_register(),
media_dev is null? The above will simply assign null to dev-v4l2_dev.mdev
Is that correct?
retval = v4l2_device_register(interface-dev, dev-v4l2_dev);
if (retval) {
dev_err(d, v4l2_device_register failed\n);
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index dd600b994e69..05d21b9f30d8 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -455,6 +455,7 @@ static int register_dvb(struct cx231xx_dvb *dvb,
mutex_init(dvb-lock);
+
/* register adapter */
ELC 2015 - March - San Jose
Is anyone planning to attend this year? - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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: ELC 2015 - March - San Jose
On 01/07/2015 05:20 PM, Steven Toth wrote: Is anyone planning to attend this year? I'm planning to attend. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Greetings From China
Good day and how do you do? I'm Mr.Chiang, and I work with Bank of China. I need your assistance in moving a sum of $28 Million USDollars. Kindly get back if interested. -- 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] soc_camera: avoid potential null-dereference
Hi Andy,
Thanks for the patch. Will queue for the next pull request.
Regards
Guennadi
On Wed, 7 Jan 2015, Andy Shevchenko wrote:
We have to check the pointer before dereferencing it.
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
---
drivers/media/platform/soc_camera/soc_camera.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index b3db51c..8c665c4 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -2166,7 +2166,7 @@ static int soc_camera_video_start(struct
soc_camera_device *icd)
static int soc_camera_pdrv_probe(struct platform_device *pdev)
{
struct soc_camera_desc *sdesc = pdev-dev.platform_data;
- struct soc_camera_subdev_desc *ssdd = sdesc-subdev_desc;
+ struct soc_camera_subdev_desc *ssdd;
struct soc_camera_device *icd;
int ret;
@@ -2177,6 +2177,8 @@ static int soc_camera_pdrv_probe(struct platform_device
*pdev)
if (!icd)
return -ENOMEM;
+ ssdd = sdesc-subdev_desc;
+
/*
* In the asynchronous case ssdd-num_regulators == 0 yet, so, the below
* regulator allocation is a dummy. They are actually requested by the
--
1.8.3.101.g727a46b
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] dvb-core: add template code for i2c binding model
From: Akihiro Tsukada tsk...@gmail.com
Changes in v2:
- rename some varibles for consistency and readability
- (registering of tuner subdev media_entity is NOT implemented yet).
Define a standard interface for demod/tuner i2c driver modules.
A module client calls dvb_i2c_attach_{fe,tuner}(),
and a module driver defines struct dvb_i2c_module_param and
calls DEFINE_DVB_I2C_MODULE() macro.
This template provides implicit module requests and ref-counting,
alloc/free's private data structures,
fixes the usage of clientdata of i2c devices,
and defines the platformdata structures for passing around
device specific config/output parameters between drivers and clients.
These kinds of code are common to (almost) all dvb i2c drivers/client,
but they were scattered over adapter modules and demod/tuner modules.
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
drivers/media/dvb-core/Makefile | 4 +
drivers/media/dvb-core/dvb_frontend.h | 1 +
drivers/media/dvb-core/dvb_i2c.c | 219 ++
drivers/media/dvb-core/dvb_i2c.h | 110 +
4 files changed, 334 insertions(+)
create mode 100644 drivers/media/dvb-core/dvb_i2c.c
create mode 100644 drivers/media/dvb-core/dvb_i2c.h
diff --git a/drivers/media/dvb-core/Makefile b/drivers/media/dvb-core/Makefile
index 8f22bcd..271648d 100644
--- a/drivers/media/dvb-core/Makefile
+++ b/drivers/media/dvb-core/Makefile
@@ -8,4 +8,8 @@ dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o dvb_filter.o
\
dvb_ca_en50221.o dvb_frontend.o\
$(dvb-net-y) dvb_ringbuffer.o dvb_math.o
+ifneq ($(CONFIG_I2C)$(CONFIG_I2C_MODULE),)
+dvb-core-objs += dvb_i2c.o
+endif
+
obj-$(CONFIG_DVB_CORE) += dvb-core.o
diff --git a/drivers/media/dvb-core/dvb_frontend.h
b/drivers/media/dvb-core/dvb_frontend.h
index 816269e..903719a 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -415,6 +415,7 @@ struct dtv_frontend_properties {
struct dvb_frontend {
struct dvb_frontend_ops ops;
struct dvb_adapter *dvb;
+ struct i2c_client *fe_i2c_client;
void *demodulator_priv;
void *tuner_priv;
void *frontend_priv;
diff --git a/drivers/media/dvb-core/dvb_i2c.c b/drivers/media/dvb-core/dvb_i2c.c
new file mode 100644
index 000..09c3078
--- /dev/null
+++ b/drivers/media/dvb-core/dvb_i2c.c
@@ -0,0 +1,219 @@
+/*
+ * dvb_i2c.c
+ *
+ * Copyright 2014 Akihiro Tsukada tskd08 AT gmail DOT 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.
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ *
+ */
+
+#include dvb_i2c.h
+
+static struct i2c_client *
+dvb_i2c_new_subdev(struct i2c_adapter *adap, struct i2c_board_info *info,
+ const unsigned short *probe_addrs)
+{
+ struct i2c_client *cl;
+
+ request_module(I2C_MODULE_PREFIX %s, info-type);
+ /* Create the i2c client */
+ if (info-addr == 0 probe_addrs)
+ cl = i2c_new_probed_device(adap, info, probe_addrs, NULL);
+ else
+ cl = i2c_new_device(adap, info);
+ if (!cl || !cl-dev.driver)
+ return NULL;
+ return cl;
+}
+
+struct dvb_frontend *
+dvb_i2c_attach_fe(struct i2c_adapter *adap, const struct i2c_board_info *info,
+ const void *cfg_template, void **out)
+{
+ struct i2c_client *cl;
+ struct i2c_board_info tmp_info;
+ struct dvb_i2c_dev_config cfg;
+
+ cfg.priv_cfg = cfg_template;
+ cfg.out = out;
+ tmp_info = *info;
+ tmp_info.platform_data = cfg;
+
+ cl = dvb_i2c_new_subdev(adap, tmp_info, NULL);
+ if (!cl)
+ return NULL;
+ return i2c_get_clientdata(cl);
+}
+EXPORT_SYMBOL(dvb_i2c_attach_fe);
+
+struct i2c_client *
+dvb_i2c_attach_tuner(struct i2c_adapter *adap,
+const struct i2c_board_info *info,
+struct dvb_frontend *fe,
+const void *cfg_template, void **out)
+{
+ struct i2c_board_info tmp_info;
+ struct dvb_i2c_tuner_config cfg;
+
+ cfg.fe = fe;
+ cfg.devcfg.priv_cfg = cfg_template;
+ cfg.devcfg.out = out;
+ tmp_info = *info;
+ tmp_info.platform_data = cfg;
+
+ return dvb_i2c_new_subdev(adap, tmp_info, NULL);
+}
+EXPORT_SYMBOL(dvb_i2c_attach_tuner);
+
+
+static int
+probe_tuner(struct i2c_client *client, const struct
Re: [PATCHv3 01/20] media: add new types for DVB devnodes
Em Wed, 07 Jan 2015 16:09:04 +0200
Sakari Ailus sakari.ai...@linux.intel.com escreveu:
Hi Mauro,
Mauro Carvalho Chehab wrote:
Most of the DVB subdevs have already their own devnode.
Add support for them at the media controller API.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 7902e800f019..707db275f92b 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -50,7 +50,14 @@ struct media_device_info {
#define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE + 1)
#define MEDIA_ENT_T_DEVNODE_FB(MEDIA_ENT_T_DEVNODE + 2)
#define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB(MEDIA_ENT_T_DEVNODE + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_DEVNODE + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX (MEDIA_ENT_T_DEVNODE + 5)
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR(MEDIA_ENT_T_DEVNODE + 6)
+#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_DEVNODE + 7)
+#define MEDIA_ENT_T_DEVNODE_DVB_NET(MEDIA_ENT_T_DEVNODE + 8)
I'd create another type for the DVB sub-type devices, as there is for
V4L2 sub-devices. I wonder what Laurent thinks.
I discussed this quickly with Laurent on IRC.
There are some concept differences between V4L2 and DVB.
At v4l2:
- the spec is one monolitic header (videodev2.h);
- one devnode is used to control everyhing (/dev/video?)
- there is one v4l core for all types of devices
At DVB:
- each different DVB API has its own header;
- each DVB device type has its own core (ok, they're
linked into one module, but internally they're almost independent);
- each different DVB API has its own devnode.
So, using SUBDEV for DVB (or at least for the devnodes) don't
make much sense.
Ok, there are still some things at DVB side that could be mapped as
subdev. The clear example is the tuner. However, in this case, the
same tuner can be either V4L, DVB or both. So, we need to define just
one subdev type for the tuner.
Also, each DVB device can be identified via major/minor pairs.
I wrote already (and submitted upstream) the patches for media-ctl to
recognize them. They're also on my experimental v4l-utils tree:
http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-utils.git/log/?h=dvb-media-ctl
Regards,
Mauro
--
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: [yavta PATCH 0/2] Data prefix writing fixes
Hi Sakari, On Tuesday 06 January 2015 01:50:13 Sakari Ailus wrote: Hi Laurent, Just a small fix (and a better name) for the --buffer-prefix option implementation. The original patch didn't quite work as intended. Thank you for the patches. I've applied them. -- 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] [media] s5p-jpeg: Adding Exynos7 Jpeg variant support
Dear Jacek,
On Wednesday, January 07, 2015 3:15 PM Jacek Anaszewski wrote,
Hi Tony,
Sorry for late response, just got back from vacation.
On 12/19/2014 04:37 AM, Tony K Nadackal wrote:
Hi Jacek,
On Wednesday, December 17, 2014 7:46 PM Jacek Anaszewski wrote,
Hi Tony,
Thanks for the patches.
Thanks for the review.
Please process them with scripts/checkpatch.pl as you will be
submitting the
next
version - they contain many coding style related issues.
I ran checkpatch before posting. Do you find any checkpatch related
issues in the patch?
There was a problem on my side, sorry for making confusion.
My remaining comments below.
[snip]
+ if (ctx-jpeg-variant-version == SJPEG_EXYNOS7) {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS7);
+ exynos4_jpeg_set_enc_out_fmt(jpeg-regs,
+ ctx-subsampling,
EXYNOS7_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg-regs,
+ ctx-out_q.fmt-fourcc,
+ EXYNOS7_SWAP_CHROMA_SHIFT);
+ } else {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS4);
+ exynos4_jpeg_set_enc_out_fmt(jpeg-regs,
+ ctx-subsampling,
EXYNOS4_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg-regs,
+ ctx-out_q.fmt-fourcc,
+ EXYNOS4_SWAP_CHROMA_SHIFT);
+ }
+
I'd implement it this way:
exynos4_jpeg_set_interrupt(jpeg-regs, ctx-jpeg-variant-version);
exynos4_jpeg_set_enc_out_fmt(jpeg-regs, ctx-subsampling,
(ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
EXYNOS4_ENC_FMT_MASK :
EXYNOS7_ENC_FMT_MASK);
exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-out_q.fmt-fourcc,
(ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
EXYNOS4_SWAP_CHROMA_SHIFT :
EXYNOS7_SWAP_CHROMA_SHIFT);
OK. Looks goods to me. Thanks for the suggestion.
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
exynos4_jpeg_set_encode_hoff_cnt(jpeg-regs,
ctx-out_q.fmt-fourcc);
} else {
exynos4_jpeg_sw_reset(jpeg-regs);
- exynos4_jpeg_set_interrupt(jpeg-regs);
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
- exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-cap_q.fmt-
fourcc);
- bitstream_size = DIV_ROUND_UP(ctx-out_q.size, 32);
+ if (ctx-jpeg-variant-version == SJPEG_EXYNOS7) {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS7);
+ exynos4_jpeg_set_huff_tbl(jpeg-regs);
+ exynos4_jpeg_set_huf_table_enable(jpeg-regs, 1);
+
+ /*
+ * JPEG IP allows storing 4 quantization tables
+ * We fill table 0 for luma and table 1 for chroma
+ */
+ exynos4_jpeg_set_qtbl_lum(jpeg-regs,
+ ctx-compr_quality);
+ exynos4_jpeg_set_qtbl_chr(jpeg-regs,
+ ctx-compr_quality);
Is it really required to setup quantization tables for encoding?
Without setting up the quantization tables, encoder is working fine.
But, as per Exynos7 User Manual setting up the quantization tables are
required for encoding also.
Sorry I also got it mixed up.
*Decoder* works fine without setting up the quantization tables. But this step
is mentioned in User Manual.
Actually I intended to ask if setting the quantization tables is required for
*decoding*, as you set it also in decoding path, whereas for Exynos4 it is not
required. I looks strange for me as quantization tables are usually required
only
for encoding raw images.
The same is related to huffman tables.
Huffman table is required for Exynos7 decoding.
User Manual says about Update_Huf_Tbl [bit 19 of PEG_CNTL], User/Host should
mandatory program this Bit as 1 for every decoder operation. SFR
HUFF_TBL_ENT and SFR HUFF_CNT should be programmed accordingly for every
encoder/decoder operation.
+ exynos4_jpeg_set_stream_size(jpeg-regs, ctx-
cap_q.w,
+ ctx-cap_q.h);
For exynos4 this function writes the number of samples per line and
number lines of the resulting JPEG image and is used only during
encoding. Is the semantics of the related register different in case of
Exynos7?
Yes. In case of Exynos7 Encoding, This step is required.
Ack.
I will request Kukjin or any Samsung colleagues who has access to Exynos7 Manual
to give ack or
Re: [PATCH] [media] s5p-jpeg: Adding Exynos7 Jpeg variant support
Hi Tony,
On 01/07/2015 01:08 PM, Tony K Nadackal wrote:
Dear Jacek,
On Wednesday, January 07, 2015 3:15 PM Jacek Anaszewski wrote,
Hi Tony,
Sorry for late response, just got back from vacation.
On 12/19/2014 04:37 AM, Tony K Nadackal wrote:
Hi Jacek,
On Wednesday, December 17, 2014 7:46 PM Jacek Anaszewski wrote,
Hi Tony,
Thanks for the patches.
Thanks for the review.
Please process them with scripts/checkpatch.pl as you will be
submitting the
next
version - they contain many coding style related issues.
I ran checkpatch before posting. Do you find any checkpatch related
issues in the patch?
There was a problem on my side, sorry for making confusion.
My remaining comments below.
[snip]
+ if (ctx-jpeg-variant-version == SJPEG_EXYNOS7) {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS7);
+ exynos4_jpeg_set_enc_out_fmt(jpeg-regs,
+ ctx-subsampling,
EXYNOS7_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg-regs,
+ ctx-out_q.fmt-fourcc,
+ EXYNOS7_SWAP_CHROMA_SHIFT);
+ } else {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS4);
+ exynos4_jpeg_set_enc_out_fmt(jpeg-regs,
+ ctx-subsampling,
EXYNOS4_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg-regs,
+ ctx-out_q.fmt-fourcc,
+ EXYNOS4_SWAP_CHROMA_SHIFT);
+ }
+
I'd implement it this way:
exynos4_jpeg_set_interrupt(jpeg-regs, ctx-jpeg-variant-version);
exynos4_jpeg_set_enc_out_fmt(jpeg-regs, ctx-subsampling,
(ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
EXYNOS4_ENC_FMT_MASK :
EXYNOS7_ENC_FMT_MASK);
exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-out_q.fmt-fourcc,
(ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
EXYNOS4_SWAP_CHROMA_SHIFT :
EXYNOS7_SWAP_CHROMA_SHIFT);
OK. Looks goods to me. Thanks for the suggestion.
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
exynos4_jpeg_set_encode_hoff_cnt(jpeg-regs,
ctx-out_q.fmt-fourcc);
} else {
exynos4_jpeg_sw_reset(jpeg-regs);
- exynos4_jpeg_set_interrupt(jpeg-regs);
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
- exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-cap_q.fmt-
fourcc);
- bitstream_size = DIV_ROUND_UP(ctx-out_q.size, 32);
+ if (ctx-jpeg-variant-version == SJPEG_EXYNOS7) {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS7);
+ exynos4_jpeg_set_huff_tbl(jpeg-regs);
+ exynos4_jpeg_set_huf_table_enable(jpeg-regs, 1);
+
+ /*
+* JPEG IP allows storing 4 quantization tables
+* We fill table 0 for luma and table 1 for chroma
+*/
+ exynos4_jpeg_set_qtbl_lum(jpeg-regs,
+ ctx-compr_quality);
+ exynos4_jpeg_set_qtbl_chr(jpeg-regs,
+ ctx-compr_quality);
Is it really required to setup quantization tables for encoding?
Without setting up the quantization tables, encoder is working fine.
But, as per Exynos7 User Manual setting up the quantization tables are
required for encoding also.
Sorry I also got it mixed up.
*Decoder* works fine without setting up the quantization tables. But this step
is mentioned in User Manual.
I'm ok with it provided that you will get an ack from Samsung SOCs
maintainer.
Actually I intended to ask if setting the quantization tables is required for
*decoding*, as you set it also in decoding path, whereas for Exynos4 it is not
required. I looks strange for me as quantization tables are usually required
only
for encoding raw images.
The same is related to huffman tables.
Huffman table is required for Exynos7 decoding.
User Manual says about Update_Huf_Tbl [bit 19 of PEG_CNTL], User/Host should
mandatory program this Bit as 1 for every decoder operation. SFR
HUFF_TBL_ENT and SFR HUFF_CNT should be programmed accordingly for every
encoder/decoder operation.
Same situation as above.
+ exynos4_jpeg_set_stream_size(jpeg-regs, ctx-
cap_q.w,
+ ctx-cap_q.h);
For exynos4 this function writes the number of samples per line and
number lines of the resulting JPEG image and is used only during
encoding. Is the semantics of
[PATCH v2 0/4] modify earth-pt3 and its dependees to use i2c template
From: Akihiro Tsukada tsk...@gmail.com This patch series depends on the previous patch: [PATCH v2]dvb-core: add template code for i2c binding model 1420635900-32221-1-git-send-email-tsk...@gmail.com The adapter(earth-pt3), its demod (tc90522) and tuners (mxl301rf, qm1d1c0042) are ported to dvb-core i2c template. Akihiro Tsukada (4): dvb: qm1d1c0042: use dvb-core i2c binding model template dvb: mxl301rf: use dvb-core i2c binding model template dvb: tc90522: use dvb-core i2c binding model template dvb: earth-pt3: use dvb-core i2c binding model template drivers/media/dvb-frontends/tc90522.c | 143 ++ drivers/media/dvb-frontends/tc90522.h | 8 +- drivers/media/pci/pt3/pt3.c | 89 +++-- drivers/media/pci/pt3/pt3.h | 12 +-- drivers/media/tuners/mxl301rf.c | 50 drivers/media/tuners/mxl301rf.h | 2 +- drivers/media/tuners/qm1d1c0042.c | 60 +- drivers/media/tuners/qm1d1c0042.h | 2 - 8 files changed, 129 insertions(+), 237 deletions(-) -- 2.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] dvb: qm1d1c0042: use dvb-core i2c binding model template
From: Akihiro Tsukada tsk...@gmail.com
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
drivers/media/tuners/qm1d1c0042.c | 60 +--
drivers/media/tuners/qm1d1c0042.h | 2 --
2 files changed, 19 insertions(+), 43 deletions(-)
diff --git a/drivers/media/tuners/qm1d1c0042.c
b/drivers/media/tuners/qm1d1c0042.c
index 18bc745..b6d637d 100644
--- a/drivers/media/tuners/qm1d1c0042.c
+++ b/drivers/media/tuners/qm1d1c0042.c
@@ -29,6 +29,7 @@
#include linux/kernel.h
#include linux/math64.h
+#include dvb_i2c.h
#include qm1d1c0042.h
#define QM1D1C0042_NUM_REGS 0x20
@@ -55,11 +56,6 @@ struct qm1d1c0042_state {
u8 regs[QM1D1C0042_NUM_REGS];
};
-static struct qm1d1c0042_state *cfg_to_state(struct qm1d1c0042_config *c)
-{
- return container_of(c, struct qm1d1c0042_state, cfg);
-}
-
static int reg_write(struct qm1d1c0042_state *state, u8 reg, u8 val)
{
u8 wbuf[2] = { reg, val };
@@ -106,10 +102,12 @@ static int qm1d1c0042_set_srch_mode(struct
qm1d1c0042_state *state, bool fast)
return reg_write(state, 0x03, state-regs[0x03]);
}
-static int qm1d1c0042_wakeup(struct qm1d1c0042_state *state)
+static int qm1d1c0042_wakeup(struct dvb_frontend *fe)
{
+ struct qm1d1c0042_state *state;
int ret;
+ state = fe-tuner_priv;
state-regs[0x01] |= 1 3; /* BB_Reg_enable */
state-regs[0x01] = (~(1 0)) 0xff; /* NORMAL (wake-up) */
state-regs[0x05] = (~(1 3)) 0xff; /* pfd_rst NORMAL */
@@ -119,7 +117,7 @@ static int qm1d1c0042_wakeup(struct qm1d1c0042_state *state)
if (ret 0)
dev_warn(state-i2c-dev, (%s) failed. [adap%d-fe%d]\n,
- __func__, state-cfg.fe-dvb-num, state-cfg.fe-id);
+ __func__, fe-dvb-num, fe-id);
return ret;
}
@@ -133,9 +131,6 @@ static int qm1d1c0042_set_config(struct dvb_frontend *fe,
void *priv_cfg)
state = fe-tuner_priv;
cfg = priv_cfg;
- if (cfg-fe)
- state-cfg.fe = cfg-fe;
-
if (cfg-xtal_freq != QM1D1C0042_CFG_XTAL_DFLT)
dev_warn(state-i2c-dev,
(%s) changing xtal_freq not supported. , __func__);
@@ -359,7 +354,7 @@ static int qm1d1c0042_init(struct dvb_frontend *fe)
goto failed;
}
- ret = qm1d1c0042_wakeup(state);
+ ret = qm1d1c0042_wakeup(fe);
if (ret 0)
goto failed;
@@ -395,33 +390,18 @@ static const struct dvb_tuner_ops qm1d1c0042_ops = {
static int qm1d1c0042_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct qm1d1c0042_state *state;
- struct qm1d1c0042_config *cfg;
+ struct dvb_i2c_tuner_config *cfg;
struct dvb_frontend *fe;
-
- state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (!state)
- return -ENOMEM;
- state-i2c = client;
+ struct qm1d1c0042_state *state;
cfg = client-dev.platform_data;
fe = cfg-fe;
- fe-tuner_priv = state;
- qm1d1c0042_set_config(fe, cfg);
- memcpy(fe-ops.tuner_ops, qm1d1c0042_ops, sizeof(qm1d1c0042_ops));
+ state = fe-tuner_priv;
+ state-i2c = client;
- i2c_set_clientdata(client, state-cfg);
- dev_info(client-dev, Sharp QM1D1C0042 attached.\n);
- return 0;
-}
+ qm1d1c0042_set_config(fe, (void *)cfg-devcfg.priv_cfg);
-static int qm1d1c0042_remove(struct i2c_client *client)
-{
- struct qm1d1c0042_state *state;
-
- state = cfg_to_state(i2c_get_clientdata(client));
- state-cfg.fe-tuner_priv = NULL;
- kfree(state);
+ dev_info(client-dev, Sharp QM1D1C0042 attached.\n);
return 0;
}
@@ -430,18 +410,16 @@ static const struct i2c_device_id qm1d1c0042_id[] = {
{qm1d1c0042, 0},
{}
};
-MODULE_DEVICE_TABLE(i2c, qm1d1c0042_id);
-static struct i2c_driver qm1d1c0042_driver = {
- .driver = {
- .name = qm1d1c0042,
- },
- .probe = qm1d1c0042_probe,
- .remove = qm1d1c0042_remove,
- .id_table = qm1d1c0042_id,
+static const struct dvb_i2c_module_param qm1d1c0042_param = {
+ .ops.tuner_ops = qm1d1c0042_ops,
+ .priv_probe = qm1d1c0042_probe,
+
+ .priv_size = sizeof(struct qm1d1c0042_state),
+ .is_tuner = true,
};
-module_i2c_driver(qm1d1c0042_driver);
+DEFINE_DVB_I2C_MODULE(qm1d1c0042, qm1d1c0042_id, qm1d1c0042_param);
MODULE_DESCRIPTION(Sharp QM1D1C0042 tuner);
MODULE_AUTHOR(Akihiro TSUKADA);
diff --git a/drivers/media/tuners/qm1d1c0042.h
b/drivers/media/tuners/qm1d1c0042.h
index 4f5c188..043787e 100644
--- a/drivers/media/tuners/qm1d1c0042.h
+++ b/drivers/media/tuners/qm1d1c0042.h
@@ -21,8 +21,6 @@
struct qm1d1c0042_config {
- struct dvb_frontend *fe;
-
u32 xtal_freq;/* [kHz] */ /* currently ignored */
bool lpf; /* enable LPF */
[PATCH v2 2/4] dvb: mxl301rf: use dvb-core i2c binding model template
From: Akihiro Tsukada tsk...@gmail.com
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
drivers/media/tuners/mxl301rf.c | 50 +++--
drivers/media/tuners/mxl301rf.h | 2 +-
2 files changed, 14 insertions(+), 38 deletions(-)
diff --git a/drivers/media/tuners/mxl301rf.c b/drivers/media/tuners/mxl301rf.c
index 1575a5d..d94a692 100644
--- a/drivers/media/tuners/mxl301rf.c
+++ b/drivers/media/tuners/mxl301rf.c
@@ -29,6 +29,8 @@
*/
#include linux/kernel.h
+#include dvb_i2c.h
+
#include mxl301rf.h
struct mxl301rf_state {
@@ -36,11 +38,6 @@ struct mxl301rf_state {
struct i2c_client *i2c;
};
-static struct mxl301rf_state *cfg_to_state(struct mxl301rf_config *c)
-{
- return container_of(c, struct mxl301rf_state, cfg);
-}
-
static int raw_write(struct mxl301rf_state *state, const u8 *buf, int len)
{
int ret;
@@ -295,54 +292,33 @@ static const struct dvb_tuner_ops mxl301rf_ops = {
static int mxl301rf_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+ struct dvb_i2c_tuner_config *cfg;
struct mxl301rf_state *state;
- struct mxl301rf_config *cfg;
- struct dvb_frontend *fe;
- state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (!state)
- return -ENOMEM;
-
- state-i2c = client;
cfg = client-dev.platform_data;
+ state = cfg-fe-tuner_priv;
+ state-i2c = client;
- memcpy(state-cfg, cfg, sizeof(state-cfg));
- fe = cfg-fe;
- fe-tuner_priv = state;
- memcpy(fe-ops.tuner_ops, mxl301rf_ops, sizeof(mxl301rf_ops));
+ memcpy(state-cfg, cfg-devcfg.priv_cfg, sizeof(state-cfg));
- i2c_set_clientdata(client, state-cfg);
dev_info(client-dev, MaxLinear MxL301RF attached.\n);
return 0;
}
-static int mxl301rf_remove(struct i2c_client *client)
-{
- struct mxl301rf_state *state;
-
- state = cfg_to_state(i2c_get_clientdata(client));
- state-cfg.fe-tuner_priv = NULL;
- kfree(state);
- return 0;
-}
-
-
static const struct i2c_device_id mxl301rf_id[] = {
{mxl301rf, 0},
{}
};
-MODULE_DEVICE_TABLE(i2c, mxl301rf_id);
-static struct i2c_driver mxl301rf_driver = {
- .driver = {
- .name = mxl301rf,
- },
- .probe = mxl301rf_probe,
- .remove = mxl301rf_remove,
- .id_table = mxl301rf_id,
+static const struct dvb_i2c_module_param mxl301rf_param = {
+ .ops.tuner_ops = mxl301rf_ops,
+ .priv_probe = mxl301rf_probe,
+
+ .priv_size = sizeof(struct mxl301rf_state),
+ .is_tuner = true,
};
-module_i2c_driver(mxl301rf_driver);
+DEFINE_DVB_I2C_MODULE(mxl301rf, mxl301rf_id, mxl301rf_param);
MODULE_DESCRIPTION(MaxLinear MXL301RF tuner);
MODULE_AUTHOR(Akihiro TSUKADA);
diff --git a/drivers/media/tuners/mxl301rf.h b/drivers/media/tuners/mxl301rf.h
index 19e6840..069a6a0 100644
--- a/drivers/media/tuners/mxl301rf.h
+++ b/drivers/media/tuners/mxl301rf.h
@@ -20,7 +20,7 @@
#include dvb_frontend.h
struct mxl301rf_config {
- struct dvb_frontend *fe;
+ /* none now */
};
#endif /* MXL301RF_H */
--
2.2.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: [PATCHv3 01/20] media: add new types for DVB devnodes
Hi Mauro,
Mauro Carvalho Chehab wrote:
Most of the DVB subdevs have already their own devnode.
Add support for them at the media controller API.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 7902e800f019..707db275f92b 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -50,7 +50,14 @@ struct media_device_info {
#define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE + 1)
#define MEDIA_ENT_T_DEVNODE_FB(MEDIA_ENT_T_DEVNODE + 2)
#define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB(MEDIA_ENT_T_DEVNODE + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_DEVNODE + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX (MEDIA_ENT_T_DEVNODE + 5)
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR(MEDIA_ENT_T_DEVNODE + 6)
+#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_DEVNODE + 7)
+#define MEDIA_ENT_T_DEVNODE_DVB_NET(MEDIA_ENT_T_DEVNODE + 8)
I'd create another type for the DVB sub-type devices, as there is for
V4L2 sub-devices. I wonder what Laurent thinks.
+
+/* Legacy symbol. Use it to avoid userspace compilation breakages */
+#define MEDIA_ENT_T_DEVNODE_DVBMEDIA_ENT_T_DEVNODE_DVB_FE
#define MEDIA_ENT_T_V4L2_SUBDEV (2 MEDIA_ENT_TYPE_SHIFT)
#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR(MEDIA_ENT_T_V4L2_SUBDEV + 1)
--
Kind regards,
Sakari Ailus
sakari.ai...@linux.intel.com
--
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
