RE: vb2_reqbufs() is not allowing more than VIDEO_MAX_FRAME
Hi Hans,
include/media/davinci/vpfe_capture.h
It uses videobuf-dma-contig.h, so, I left it out.
drivers/media/platform/vivi-core.c
Cannot find this one. Checked with find, in case it changed location, but
couldn't.
drivers/media/pci/saa7134/*
Updated.
Please find below the patch. I am hoping it's good to go.
Regards,
Divneil
From 1792d75dc0f893a181d991a0b238bbd0ead945c1 Mon Sep 17 00:00:00 2001
From: Divneil Wadhawan divneil.wadha...@st.com
Date: Mon, 7 Jul 2014 12:38:06 +0530
Subject: [PATCH] v4l2: vb2: replace VIDEO_MAX_FRAME with VB2_MAX_FRAME
- vb2 drivers to rely on VB2_MAX_FRAME.
- VB2_MAX_FRAME bumps the value to 64 from current 32
Change-Id: I3d7998898df43553486166c44b54524aac449deb
Signed-off-by: Divneil Wadhawan divneil.wadha...@st.com
---
drivers/media/pci/saa7134/saa7134-ts.c|4 ++--
drivers/media/pci/saa7134/saa7134-vbi.c |4 ++--
drivers/media/pci/saa7134/saa7134-video.c |2 +-
drivers/media/platform/mem2mem_testdev.c |2 +-
drivers/media/platform/ti-vpe/vpe.c |2 +-
drivers/media/v4l2-core/videobuf2-core.c |8
include/media/videobuf2-core.h|4 +++-
7 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-ts.c
b/drivers/media/pci/saa7134/saa7134-ts.c
index bd25323..0d04995 100644
--- a/drivers/media/pci/saa7134/saa7134-ts.c
+++ b/drivers/media/pci/saa7134/saa7134-ts.c
@@ -227,8 +227,8 @@ int saa7134_ts_init1(struct saa7134_dev *dev)
/* sanitycheck insmod options */
if (tsbufs 2)
tsbufs = 2;
- if (tsbufs VIDEO_MAX_FRAME)
- tsbufs = VIDEO_MAX_FRAME;
+ if (tsbufs VB2_MAX_FRAME)
+ tsbufs = VB2_MAX_FRAME;
if (ts_nr_packets 4)
ts_nr_packets = 4;
if (ts_nr_packets 312)
diff --git a/drivers/media/pci/saa7134/saa7134-vbi.c
b/drivers/media/pci/saa7134/saa7134-vbi.c
index c06dbe1..15b5860 100644
--- a/drivers/media/pci/saa7134/saa7134-vbi.c
+++ b/drivers/media/pci/saa7134/saa7134-vbi.c
@@ -203,8 +203,8 @@ int saa7134_vbi_init1(struct saa7134_dev *dev)
if (vbibufs 2)
vbibufs = 2;
- if (vbibufs VIDEO_MAX_FRAME)
- vbibufs = VIDEO_MAX_FRAME;
+ if (vbibufs VB2_MAX_FRAME)
+ vbibufs = VB2_MAX_FRAME;
return 0;
}
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index d375999..47dda6c 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -2032,7 +2032,7 @@ int saa7134_video_init1(struct saa7134_dev *dev)
int ret;
/* sanitycheck insmod options */
- if (gbuffers 2 || gbuffers VIDEO_MAX_FRAME)
+ if (gbuffers 2 || gbuffers VB2_MAX_FRAME)
gbuffers = 2;
if (gbufsize gbufsize_max)
gbufsize = gbufsize_max;
diff --git a/drivers/media/platform/mem2mem_testdev.c
b/drivers/media/platform/mem2mem_testdev.c
index 0714070..fe3235d 100644
--- a/drivers/media/platform/mem2mem_testdev.c
+++ b/drivers/media/platform/mem2mem_testdev.c
@@ -55,7 +55,7 @@ MODULE_PARM_DESC(debug, activates debug info);
#define MEM2MEM_NAME m2m-testdev
/* Per queue */
-#define MEM2MEM_DEF_NUM_BUFS VIDEO_MAX_FRAME
+#define MEM2MEM_DEF_NUM_BUFS VB2_MAX_FRAME
/* In bytes, per queue */
#define MEM2MEM_VID_MEM_LIMIT (16 * 1024 * 1024)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 972f43f..6b370ed 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1970,7 +1970,7 @@ static const struct v4l2_ctrl_config vpe_bufs_per_job = {
.type = V4L2_CTRL_TYPE_INTEGER,
.def = VPE_DEF_BUFS_PER_JOB,
.min = 1,
- .max = VIDEO_MAX_FRAME,
+ .max = VB2_MAX_FRAME,
.step = 1,
};
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 7c4489c..09bc9bb 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -904,7 +904,7 @@ static int __reqbufs(struct vb2_queue *q, struct
v4l2_requestbuffers *req)
/*
* Make sure the requested values and current defaults are sane.
*/
- num_buffers = min_t(unsigned int, req-count, VIDEO_MAX_FRAME);
+ num_buffers = min_t(unsigned int, req-count, VB2_MAX_FRAME);
num_buffers = max_t(unsigned int, num_buffers, q-min_buffers_needed);
memset(q-plane_sizes, 0, sizeof(q-plane_sizes));
memset(q-alloc_ctx, 0, sizeof(q-alloc_ctx));
@@ -1005,7 +1005,7 @@ static int __create_bufs(struct vb2_queue *q, struct
v4l2_create_buffers *create
unsigned int num_planes = 0, num_buffers, allocated_buffers;
int ret;
- if (q-num_buffers == VIDEO_MAX_FRAME) {
+ if (q-num_buffers == VB2_MAX_FRAME) {
dprintk(1, maximum number of buffers already allocated\n);
return -ENOBUFS;
}
@@ -1016,7 +1016,7 @@ static int __create_bufs(struct vb2_queue *q, struct
v4l2_create_buffers *create
q-memory = create-memory;
}
- num_buffers = min(create-count, VIDEO_MAX_FRAME - q-num_buffers);
+ num_buffers = min(create-count, VB2_MAX_FRAME - q-num_buffers);
/*
* Ask the driver,
Re: [[PATCH v2] 00/14] Fix ISDB-T tuning issues
Hi Mauro, I like all of your changes. Acked-By: Patrick Boettcher pboettc...@kernellabs.com regards, Patrick. On Fri, 4 Jul 2014 14:15:26 -0300 Mauro Carvalho Chehab m.che...@samsung.com wrote: While testing two dvb devices: - Mygica S870 (dib8096 based); - Pixelview PV-D231U (RN-F) I noticed several bugs: - It doesn't lock on any layer with Interleave 2; - It doesn't lock in mode 2 (4 K FFT); - ADC OFF settings is wrong, with causes wrong ADC adjustments and cause locking issues; - the ADC gain table was not right; - There are some troubles when used with CONFIG_HZ = 1000. This patch series addresses the above bugs. While here, it also improves some debug messages and ad a few other improvements. For the patches that change the sleep time, I opted to be conservative, e. g. to reproduce the worse case (e. g. CONFIG_HZ = 100), so enforcing that the minimal state machine delays to be 10ms. That assures that no regression will be introduced, and that machines configured with HZ equal to 250, 300 or 1000 will work just like the ones configured with HZ equal to 100. Please notice that the Windows driver for Mygica S870 does a different setup than what's there at the Linux driver. While I have a patch changing it, I opted to remove it from this patch series, as I didn't notice any improvements with the patch here. Such patch is already in patchwork: https://patchwork.linuxtv.org/patch/24586/ and we might resurrect it latter if needed. Mauro Carvalho Chehab (14): dib8000: Fix handling of interleave bigger than 2 dib8000: Fix ADC OFF settings dib8000: Fix alignments at dib8000_tune() dib8000: Fix: add missing 4K mode dib8000: remove a double call for dib8000_get_symbol_duration() dib8000: In auto-search, try first with partial reception enabled dib8000: Restart sad during dib8000_reset dib0700: better document struct init dib8000: Fix the sleep time at the state machine dib0090: Fix the sleep time at the state machine dib8000: use jifies instead of current_kernel_time() dib8000: Update the ADC gain table dib8000: improve debug messages dib8000: improve the message that reports per-layer locks drivers/media/dvb-frontends/dib0090.c | 15 +- drivers/media/dvb-frontends/dib8000.c | 645 +++- drivers/media/usb/dvb-usb/dib0700_devices.c | 148 --- 3 files changed, 436 insertions(+), 372 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vb2_reqbufs() is not allowing more than VIDEO_MAX_FRAME
On 07/07/2014 09:27 AM, Divneil Wadhawan wrote:
Hi Hans,
include/media/davinci/vpfe_capture.h
It uses videobuf-dma-contig.h, so, I left it out.
Ah, you are right. I thought that one was converted to vb2, but it isn't.
drivers/media/platform/vivi-core.c
Cannot find this one. Checked with find, in case it changed location, but
couldn't.
Sorry, my mistake. I'm working on the vivi driver and I'm actually the one
who introduced VIDEO_MAX_FRAME there. But since that isn't committed yet
you can't find it either :-)
drivers/media/pci/saa7134/*
Updated.
Please find below the patch. I am hoping it's good to go.
I'll take a look at it.
Regards,
Hans
Regards,
Divneil
From 1792d75dc0f893a181d991a0b238bbd0ead945c1 Mon Sep 17 00:00:00 2001
From: Divneil Wadhawan divneil.wadha...@st.com
Date: Mon, 7 Jul 2014 12:38:06 +0530
Subject: [PATCH] v4l2: vb2: replace VIDEO_MAX_FRAME with VB2_MAX_FRAME
- vb2 drivers to rely on VB2_MAX_FRAME.
- VB2_MAX_FRAME bumps the value to 64 from current 32
Change-Id: I3d7998898df43553486166c44b54524aac449deb
Signed-off-by: Divneil Wadhawan divneil.wadha...@st.com
---
drivers/media/pci/saa7134/saa7134-ts.c|4 ++--
drivers/media/pci/saa7134/saa7134-vbi.c |4 ++--
drivers/media/pci/saa7134/saa7134-video.c |2 +-
drivers/media/platform/mem2mem_testdev.c |2 +-
drivers/media/platform/ti-vpe/vpe.c |2 +-
drivers/media/v4l2-core/videobuf2-core.c |8
include/media/videobuf2-core.h|4 +++-
7 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-ts.c
b/drivers/media/pci/saa7134/saa7134-ts.c
index bd25323..0d04995 100644
--- a/drivers/media/pci/saa7134/saa7134-ts.c
+++ b/drivers/media/pci/saa7134/saa7134-ts.c
@@ -227,8 +227,8 @@ int saa7134_ts_init1(struct saa7134_dev *dev)
/* sanitycheck insmod options */
if (tsbufs 2)
tsbufs = 2;
- if (tsbufs VIDEO_MAX_FRAME)
- tsbufs = VIDEO_MAX_FRAME;
+ if (tsbufs VB2_MAX_FRAME)
+ tsbufs = VB2_MAX_FRAME;
if (ts_nr_packets 4)
ts_nr_packets = 4;
if (ts_nr_packets 312)
diff --git a/drivers/media/pci/saa7134/saa7134-vbi.c
b/drivers/media/pci/saa7134/saa7134-vbi.c
index c06dbe1..15b5860 100644
--- a/drivers/media/pci/saa7134/saa7134-vbi.c
+++ b/drivers/media/pci/saa7134/saa7134-vbi.c
@@ -203,8 +203,8 @@ int saa7134_vbi_init1(struct saa7134_dev *dev)
if (vbibufs 2)
vbibufs = 2;
- if (vbibufs VIDEO_MAX_FRAME)
- vbibufs = VIDEO_MAX_FRAME;
+ if (vbibufs VB2_MAX_FRAME)
+ vbibufs = VB2_MAX_FRAME;
return 0;
}
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index d375999..47dda6c 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -2032,7 +2032,7 @@ int saa7134_video_init1(struct saa7134_dev *dev)
int ret;
/* sanitycheck insmod options */
- if (gbuffers 2 || gbuffers VIDEO_MAX_FRAME)
+ if (gbuffers 2 || gbuffers VB2_MAX_FRAME)
gbuffers = 2;
if (gbufsize gbufsize_max)
gbufsize = gbufsize_max;
diff --git a/drivers/media/platform/mem2mem_testdev.c
b/drivers/media/platform/mem2mem_testdev.c
index 0714070..fe3235d 100644
--- a/drivers/media/platform/mem2mem_testdev.c
+++ b/drivers/media/platform/mem2mem_testdev.c
@@ -55,7 +55,7 @@ MODULE_PARM_DESC(debug, activates debug info);
#define MEM2MEM_NAME m2m-testdev
/* Per queue */
-#define MEM2MEM_DEF_NUM_BUFS VIDEO_MAX_FRAME
+#define MEM2MEM_DEF_NUM_BUFS VB2_MAX_FRAME
/* In bytes, per queue */
#define MEM2MEM_VID_MEM_LIMIT (16 * 1024 * 1024)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 972f43f..6b370ed 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1970,7 +1970,7 @@ static const struct v4l2_ctrl_config vpe_bufs_per_job =
{
.type = V4L2_CTRL_TYPE_INTEGER,
.def = VPE_DEF_BUFS_PER_JOB,
.min = 1,
- .max = VIDEO_MAX_FRAME,
+ .max = VB2_MAX_FRAME,
.step = 1,
};
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 7c4489c..09bc9bb 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -904,7 +904,7 @@ static int __reqbufs(struct vb2_queue *q, struct
v4l2_requestbuffers *req)
/*
* Make sure the requested values and current defaults are sane.
*/
- num_buffers = min_t(unsigned int, req-count, VIDEO_MAX_FRAME);
+ num_buffers = min_t(unsigned int, req-count, VB2_MAX_FRAME);
num_buffers = max_t(unsigned int, num_buffers, q-min_buffers_needed);
memset(q-plane_sizes, 0, sizeof(q-plane_sizes));
memset(q-alloc_ctx, 0, sizeof(q-alloc_ctx));
@@ -1005,7 +1005,7 @@ static int __create_bufs(struct vb2_queue *q, struct
v4l2_create_buffers *create
unsigned int num_planes = 0, num_buffers,
my love
prosím, můj drahý, budu rád, kdybyste mě kontaktovat na (mirianandrevv@yahoo. in) Můj nejdražší Jak se dnes máte a vaše rodina doufám, že je vše v pořádku s tebou Já jsem volal Mirian viděl jsem váš profil dnes (facebook) a zjistíte, že jste hoden být moje jako někoho, koho můžu ležel na jeho airms tak dlouho, jak láska je znepokojení, péči a teassing vám celou noc dlouho, Pokud máte zájem o dozvědět se více o, a pro mě ti poslat nějaké fotky z dolu můj kontakt tak: (mirianandr...@yahoo.in) Čeká se na slyším od vás Navždy milovat Mirian .. please my dear i will like you to contact me at (mirianandr...@yahoo.in) My dearest How are you today and your family i hope all is well with you I am called Mirian i saw your profile today (facebook) and found you worthy to be mine as some one whom i can lay on his airms as long as love is concern, caring and teassing you all the night long, If you are interested in knowing more about and for me to send you some pictures of mine my contact thus: (mirianandr...@yahoo.in) a waiting to hear from you Loving you forever Mirian -- 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 0/9] Updated fence patch series
On Wed, Jul 2, 2014 at 7:37 AM, Greg KH gre...@linuxfoundation.org wrote: Android can expose fences to userspace. It's possible to make the new fence mechanism expose the same fences to userspace by changing sync_fence_create to take a struct fence instead of a struct sync_pt. No other change is needed, because only the fence parts of struct sync_pt are used. But because the userspace fences are a separate problem and I haven't really looked at it yet I feel it should stay in staging, for now. Ok, that's reasonable. At first glance, this all looks sane to me, any objection from anyone if I merge this through my driver-core tree for 3.17? Ack from my side fwiw. Just for the record (again) about android syncpts. I think using android syncpts stuff as the official userspace interfaces for fences for userspace that wants to do explicit syncing is the sane approach - after all the (only) big platform using explicit fencing is Android since opencl is kinda not yet there really on linux (which would be the other guy really interested in explicit fencing). But before we de-stage android syncpts (and so bake in the userspace abi forever) I really want to see a full upstream gpu driver implementation using fences and running on both X+DRI userspace (implicit syncing) and android (expclicit syncing), including good test coverage for corner-cases to make sure we've addressed all warts and hidden dragons. i915 looks like the most likely candidate to get there first (we have the code for both use-cases out-of-tree after all) so I'll keep on pestering people. No promises though ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: [REPOST PATCH 4/8] android: convert sync to fence api, v5
On Mon, Jun 23, 2014 at 10:45 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: But in drivers/drm I can encounter a similar issue, people expect to be able to overwrite the contents of the currently displayed buffer, so I 'solved' it by not adding a fence on the buffer, only by waiting for buffer idle before page flipping. The rationale is that the buffer is pinned internally, and the backing storage cannot go away until dma_buf_unmap_attachment is called. So when you render to the current front buffer without queuing a page flip you get exactly what you expect. ;-) Yeah, scanout buffers are special and imo we should only uses fences as barriers just around the flip, but _not_ to prevent frontbuffer in general. Userspace is after all allowed to do that (e.g. with the dumb bo ioctls). If we'd premanently lock scanout buffers that would indeed result in hilarity all over the place, no surprises there. And all current drivers with dynamic memory management solve this through pinning, but not by restricting write access at all. So I think we can shrug this scenario off as a non-issue of the don't do this kind ;-) Thierry, is there anything else you've stumbled over in the tegra k1 enabling work? I still get the impression that there's an awful lot of misunderstandings between the explicit and implicit syncing camps and that we need to do a lot more talking for a better understanding ... Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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] Update sync-with-kernel to use installed kernel headers
On Tue, Jul 01, 2014 at 06:24:26PM +0200, Laurent Pinchart wrote: Hi Sakari, Thank you for the review. On Tuesday 01 July 2014 17:30:38 Sakari Ailus wrote: On Tue, Jun 03, 2014 at 12:40:19PM +0200, Laurent Pinchart wrote: diff --git a/Makefile.am b/Makefile.am index 11baed1..35d0030 100644 --- a/Makefile.am +++ b/Makefile.am @@ -12,31 +12,32 @@ EXTRA_DIST = include COPYING.libv4l README.libv4l README.lib-multi-threading # custom targets sync-with-kernel: - @if [ ! -f $(KERNEL_DIR)/include/uapi/linux/videodev2.h -o \ - ! -f $(KERNEL_DIR)/include/uapi/linux/fb.h -o \ - ! -f $(KERNEL_DIR)/include/uapi/linux/v4l2-controls.h -o \ - ! -f $(KERNEL_DIR)/include/uapi/linux/v4l2-common.h -o \ - ! -f $(KERNEL_DIR)/include/uapi/linux/v4l2-subdev.h -o \ - ! -f $(KERNEL_DIR)/include/uapi/linux/v4l2-mediabus.h -o \ - ! -f $(KERNEL_DIR)/include/uapi/linux/ivtv.h -o \ - ! -f $(KERNEL_DIR)/include/uapi/linux/dvb/frontend.h -o \ - ! -f $(KERNEL_DIR)/include/uapi/linux/dvb/dmx.h -o \ - ! -f $(KERNEL_DIR)/include/uapi/linux/dvb/audio.h -o \ - ! -f $(KERNEL_DIR)/include/uapi/linux/dvb/video.h ]; then \ + @if [ ! -f $(KERNEL_DIR)/usr/include/linux/videodev2.h -o \ Shouldn't you use $(INSTALL_HDR_PATH) instead of $(KERNEL_DIR)/usr? If the user sets that, the headers won't be installed under usr. INSTALL_HDR_PATH is only set when running make headers_install in the kernel tree, not when running make sync-with-kernel in the media built tree. If we want to support syncing with kernel headers installed elsewhere we should add a new option to this Makefile. I haven't done so as the need isn't clear to me. Ok. Please then ignore my comment. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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] DocBook media: fix number of bits filled with zeros for SRGBB12
From 4e0d586d6ff8019032d1c6771428ee25c4bbb755 Mon Sep 17 00:00:00 2001 From: Andreas Weber andy.weber...@gmail.com Date: Mon, 7 Jul 2014 16:00:05 +0200 Subject: [PATCH] DocBook media: fix number of bits filled with zeros for SRGBB12 Signed-off-by: Andreas Weber andy.weber...@gmail.com --- Documentation/DocBook/media/v4l/pixfmt-srggb12.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml index 9ba4fb6..96947f1 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml @@ -18,7 +18,7 @@ titleDescription/title paraThe following four pixel formats are raw sRGB / Bayer formats with -12 bits per colour. Each colour component is stored in a 16-bit word, with 6 +12 bits per colour. Each colour component is stored in a 16-bit word, with 4 unused high bits filled with zeros. Each n-pixel row contains n/2 green samples and n/2 blue or red samples, with alternating red and blue rows. Bytes are stored in memory in little endian order. They are conventionally described -- 2.0.0
Re: LED / flash API integration related improvements
Hi Jacek, I'll promise to reply sooner the next time. Just back from holidays. :-) On Mon, Jun 16, 2014 at 01:34:40PM +0200, Jacek Anaszewski wrote: On 06/16/2014 10:53 AM, Sakari Ailus wrote: Hi Jacek and others, Comments from the LED API folks would be highly appreciated. (Cc linux-media as well.) My comments below. On Fri, May 09, 2014 at 04:28:44PM +0200, Jacek Anaszewski wrote: During review of LED / flash API integration patch sets two issues requiring modifications in the LED subsystem core emerged. I would like to consult possible ways of solving them: 1. == Some LED devices allow to control multiple LEDs independently. Currently there is no direct support for this in the LED subsystem and existing drivers register separate devices for each LED. LED / flash API integration effort is a good opportunity to provide support for exposing multiple LEDs by a single LED class device. I would like to add following API: /** * led_get_sub_leds_number - get the number of exposed LEDs * @led_cdev: the LED to query * @num_leds: number of exposed leds * * Get the number of leds exposed by the device. * * Returns: 0 on success or negative error value on failure */ int led_get_sub_leds_number(struct led_classdev *led_cdev, int *num_leds); /** * led_select_sub_led - select sub led to control * @led_cdev: the LED to set * @led_id: id of the sub led to control * * Set the sub led to be the target of the LED class API calls. * Maximum led_id equals num_leds - 1. * * Returns: 0 on success or negative error value on failure */ int led_select_sub_led(struct led_classdev *led_cdev, int led_id); Instead of this, how about using an array indexed by LED for the other functions? The problem with this is that often the registers to control LED specific properties contain the same configuration for another LED. The driver should thus cache the information until it needs to be applied, and I don't think configuring everything for every LED separately makes sense for either the user nor the driver. The max77693-flash is an example of such a design. It has one register for setting flash timeout and it affects timeout for both leds. The register would have to be written right before strobing the flash, in case the cached timeout value is different from the one in the register (cached on last write operation). The device has also common flash status register. I don't have good idea how to proceed in this case. After strobing the flash for any of the sub-leds the remaining ones will also report that they are strobing at the moment. That's a good point; it's in the end hardware dependent whether a particular property is specific to a controller or a led. It should be possible to find that out by using the interface. If we keep things simple, this would mean three functions per parameters, set, get and get_n to return the number of properties (in this very case probably either 1 or the number of LEDs). Alternatively, as all the interface functions either set or get an integer, you could access the properties (timeout, intensity etc.) by an ID. You'd need three interface functions in total, not per property. Caching the configuration before applying it should still be done since this way extra register accesses can be avoided: registers often share different kind of configurations such as timeout and current as well. The configuration should be applied once an apply fonction is called. /** * led_get_sub_led - get currently selected sub led * @led_cdev: the LED to set * @led_id: id of currently selected sub led * * Get id of the sub led chosen as the target of LED class * API calls. Maximum led_id equals num_leds - 1. * * Returns: 0 on success or negative error value on failure */ int led_get_target_led(struct led_classdev *led_cdev, int* led_id); The functions functions would be mapped on the sysfs attributes: - available_leds - RO - sub_led_id - RW This kind of interface isn't going to be compatible with existing applications. If you want to keep the compatibility, the LEDs would probably need to be exposed as separate devices. If that's not a requirement, I'd use an array here as well. I started to implement the interface I proposed but encountered several issues related to led-triggers and led_blink feature. They would require significant modifications, I'd rather avoid. Instead I decided to register separate led class device in the driver for the max77693-flash device, similarly as it is accomplished in the led drivers of the other compound led devices. The V4L2 driver would still expose the device as a single sub-device. Controls that apply to individual LEDs would be array controls. Have those array controls been
[PATCH 0/9] Add support for Exynos3250 SoC to the s5p-jpeg driver
This patch series adds support for jpeg codec on Exynos3250 SoC to the s5p-jpeg driver. Supported raw formats are: YUYV, YVYU, UYVY, VYUY, RGB565, RGB565X, RGB32, NV12, NV21. The support includes also scaling and cropping features. Thanks, Jacek Anaszewski Jacek Anaszewski (9): s5p-jpeg: Add support for Exynos3250 SoC s5p-jpeg: return error immediately after get_byte fails s5p-jpeg: Adjust jpeg_bound_align_image to Exynos3250 needs s5p-jpeg: fix g_selection op s5p-jpeg: Assure proper crop rectangle initialization s5p-jpeg: Prevent erroneous downscaling for Exynos3250 SoC s5p-jpeg: add chroma subsampling adjustment for Exynos3250 Documentation: devicetree: Document sclk-jpeg clock for exynos3250 SoC ARM: dts: exynos3250: add JPEG codec device node .../bindings/media/exynos-jpeg-codec.txt |9 +- arch/arm/boot/dts/exynos3250.dtsi | 12 + drivers/media/platform/s5p-jpeg/Makefile |2 +- drivers/media/platform/s5p-jpeg/jpeg-core.c| 666 ++-- drivers/media/platform/s5p-jpeg/jpeg-core.h| 33 +- .../media/platform/s5p-jpeg/jpeg-hw-exynos3250.c | 486 ++ .../media/platform/s5p-jpeg/jpeg-hw-exynos3250.h | 60 ++ drivers/media/platform/s5p-jpeg/jpeg-regs.h| 247 +++- 8 files changed, 1459 insertions(+), 56 deletions(-) create mode 100644 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c create mode 100644 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] s5p-jpeg: Add support for Exynos3250 SoC
This patch adds support for jpeg codec on Exynos3250 SoC to
the s5p-jpeg driver. Supported raw formats are: YUYV, YVYU, UYVY,
VYUY, RGB565, RGB565X, RGB32, NV12, NV21. The support includes
also scaling and cropping features.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-jpeg/Makefile |2 +-
drivers/media/platform/s5p-jpeg/jpeg-core.c| 533 +++-
drivers/media/platform/s5p-jpeg/jpeg-core.h| 33 +-
.../media/platform/s5p-jpeg/jpeg-hw-exynos3250.c | 486 ++
.../media/platform/s5p-jpeg/jpeg-hw-exynos3250.h | 60 +++
drivers/media/platform/s5p-jpeg/jpeg-regs.h| 247 -
6 files changed, 1341 insertions(+), 20 deletions(-)
create mode 100644 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
create mode 100644 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.h
diff --git a/drivers/media/platform/s5p-jpeg/Makefile
b/drivers/media/platform/s5p-jpeg/Makefile
index a1a9169..9e5f214 100644
--- a/drivers/media/platform/s5p-jpeg/Makefile
+++ b/drivers/media/platform/s5p-jpeg/Makefile
@@ -1,2 +1,2 @@
-s5p-jpeg-objs := jpeg-core.o jpeg-hw-exynos4.o jpeg-hw-s5p.o
+s5p-jpeg-objs := jpeg-core.o jpeg-hw-exynos3250.o jpeg-hw-exynos4.o
jpeg-hw-s5p.o
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg.o
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 0dcb796..7d604f2 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1,6 +1,6 @@
/* linux/drivers/media/platform/s5p-jpeg/jpeg-core.c
*
- * Copyright (c) 2011-2013 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2011-2014 Samsung Electronics Co., Ltd.
* http://www.samsung.com
*
* Author: Andrzej Pietrasiewicz andrze...@samsung.com
@@ -32,6 +32,7 @@
#include jpeg-core.h
#include jpeg-hw-s5p.h
#include jpeg-hw-exynos4.h
+#include jpeg-hw-exynos3250.h
#include jpeg-regs.h
static struct s5p_jpeg_fmt sjpeg_formats[] = {
@@ -41,6 +42,7 @@ static struct s5p_jpeg_fmt sjpeg_formats[] = {
.flags = SJPEG_FMT_FLAG_ENC_CAPTURE |
SJPEG_FMT_FLAG_DEC_OUTPUT |
SJPEG_FMT_FLAG_S5P |
+ SJPEG_FMT_FLAG_EXYNOS3250 |
SJPEG_FMT_FLAG_EXYNOS4,
},
{
@@ -70,6 +72,19 @@ static struct s5p_jpeg_fmt sjpeg_formats[] = {
.subsampling= V4L2_JPEG_CHROMA_SUBSAMPLING_422,
},
{
+ .name = YUV 4:2:2 packed, YCbYCr,
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .depth = 16,
+ .colplanes = 1,
+ .h_align= 2,
+ .v_align= 0,
+ .flags = SJPEG_FMT_FLAG_ENC_OUTPUT |
+ SJPEG_FMT_FLAG_DEC_CAPTURE |
+ SJPEG_FMT_FLAG_EXYNOS3250 |
+ SJPEG_FMT_NON_RGB,
+ .subsampling= V4L2_JPEG_CHROMA_SUBSAMPLING_422,
+ },
+ {
.name = YUV 4:2:2 packed, YCrYCb,
.fourcc = V4L2_PIX_FMT_YVYU,
.depth = 16,
@@ -83,6 +98,45 @@ static struct s5p_jpeg_fmt sjpeg_formats[] = {
.subsampling= V4L2_JPEG_CHROMA_SUBSAMPLING_422,
},
{
+ .name = YUV 4:2:2 packed, YCrYCb,
+ .fourcc = V4L2_PIX_FMT_YVYU,
+ .depth = 16,
+ .colplanes = 1,
+ .h_align= 2,
+ .v_align= 0,
+ .flags = SJPEG_FMT_FLAG_ENC_OUTPUT |
+ SJPEG_FMT_FLAG_DEC_CAPTURE |
+ SJPEG_FMT_FLAG_EXYNOS3250 |
+ SJPEG_FMT_NON_RGB,
+ .subsampling= V4L2_JPEG_CHROMA_SUBSAMPLING_422,
+ },
+ {
+ .name = YUV 4:2:2 packed, YCrYCb,
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .depth = 16,
+ .colplanes = 1,
+ .h_align= 2,
+ .v_align= 0,
+ .flags = SJPEG_FMT_FLAG_ENC_OUTPUT |
+ SJPEG_FMT_FLAG_DEC_CAPTURE |
+ SJPEG_FMT_FLAG_EXYNOS3250 |
+ SJPEG_FMT_NON_RGB,
+ .subsampling= V4L2_JPEG_CHROMA_SUBSAMPLING_422,
+ },
+ {
+ .name = YUV 4:2:2 packed, YCrYCb,
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .depth = 16,
+ .colplanes = 1,
+ .h_align= 2,
+ .v_align= 0,
+
[PATCH 2/9] s5p-jpeg: return error immediately after get_byte fails
When parsing JPEG header s5p_jpeg_parse_hdr function
should return immediately in case there was an error
while reading a byte.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-jpeg/jpeg-core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 7d604f2..df3aaa9 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -906,14 +906,14 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data
*result,
while (notfound) {
c = get_byte(jpeg_buffer);
if (c == -1)
- break;
+ return false;
if (c != 0xff)
continue;
do
c = get_byte(jpeg_buffer);
while (c == 0xff);
if (c == -1)
- break;
+ return false;
if (c == 0)
continue;
length = 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] s5p-jpeg: Adjust jpeg_bound_align_image to Exynos3250 needs
The jpeg_bound_align_image function needs to know the context
in which it is called, as it needs to align image dimensions in
a slight different manner for Exynos3250, which crops pixels for
specific values in case the format is RGB.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index df3aaa9..0854f37 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1133,7 +1133,8 @@ static struct s5p_jpeg_fmt *s5p_jpeg_find_format(struct
s5p_jpeg_ctx *ctx,
return NULL;
}
-static void jpeg_bound_align_image(u32 *w, unsigned int wmin, unsigned int
wmax,
+static void jpeg_bound_align_image(struct s5p_jpeg_ctx *ctx,
+ u32 *w, unsigned int wmin, unsigned int wmax,
unsigned int walign,
u32 *h, unsigned int hmin, unsigned int hmax,
unsigned int halign)
@@ -1145,13 +1146,27 @@ static void jpeg_bound_align_image(u32 *w, unsigned int
wmin, unsigned int wmax,
w_step = 1 walign;
h_step = 1 halign;
+
+ if (ctx-jpeg-variant-version == SJPEG_EXYNOS3250) {
+ /*
+* Rightmost and bottommost pixels are cropped by the
+* Exynos3250 JPEG IP for RGB formats, for the specific
+* width and height values respectively. This assignment
+* will result in v4l_bound_align_image returning dimensions
+* reduced by 1 for the aforementioned cases.
+*/
+ if (w_step == 4 ((width 3) == 1)) {
+ wmax = width;
+ hmax = height;
+ }
+ }
+
v4l_bound_align_image(w, wmin, wmax, walign, h, hmin, hmax, halign, 0);
if (*w width (*w + w_step) wmax)
*w += w_step;
if (*h height (*h + h_step) hmax)
*h += h_step;
-
}
static int vidioc_try_fmt(struct v4l2_format *f, struct s5p_jpeg_fmt *fmt,
@@ -1167,12 +1182,12 @@ static int vidioc_try_fmt(struct v4l2_format *f, struct
s5p_jpeg_fmt *fmt,
/* V4L2 specification suggests the driver corrects the format struct
* if any of the dimensions is unsupported */
if (q_type == FMT_TYPE_OUTPUT)
- jpeg_bound_align_image(pix-width, S5P_JPEG_MIN_WIDTH,
+ jpeg_bound_align_image(ctx, pix-width, S5P_JPEG_MIN_WIDTH,
S5P_JPEG_MAX_WIDTH, 0,
pix-height, S5P_JPEG_MIN_HEIGHT,
S5P_JPEG_MAX_HEIGHT, 0);
else
- jpeg_bound_align_image(pix-width, S5P_JPEG_MIN_WIDTH,
+ jpeg_bound_align_image(ctx, pix-width, S5P_JPEG_MIN_WIDTH,
S5P_JPEG_MAX_WIDTH, fmt-h_align,
pix-height, S5P_JPEG_MIN_HEIGHT,
S5P_JPEG_MAX_HEIGHT, fmt-v_align);
@@ -1294,7 +1309,7 @@ static int exynos4_jpeg_get_output_buffer_size(struct
s5p_jpeg_ctx *ctx,
else
wh_align = 1;
- jpeg_bound_align_image(w, S5P_JPEG_MIN_WIDTH,
+ jpeg_bound_align_image(ctx, w, S5P_JPEG_MIN_WIDTH,
S5P_JPEG_MAX_WIDTH, wh_align,
h, S5P_JPEG_MIN_HEIGHT,
S5P_JPEG_MAX_HEIGHT, wh_align);
--
1.7.9.5
--
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 5/9] s5p-jpeg: Assure proper crop rectangle initialization
Assure proper crop_rect initialization in case
the user space doesn't call S_SELECTION ioctl.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 09b59d3..2491ef8 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1367,6 +1367,21 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct,
struct v4l2_format *f)
V4L2_CID_JPEG_CHROMA_SUBSAMPLING);
if (ctrl_subs)
v4l2_ctrl_s_ctrl(ctrl_subs, q_data-fmt-subsampling);
+ ct-crop_altered = false;
+ }
+
+ /*
+* For decoding init crop_rect with capture buffer dimmensions which
+* contain aligned dimensions of the input JPEG image and do it only
+* if crop rectangle hasn't been altered by the user space e.g. with
+* S_SELECTION ioctl. For encoding assign output buffer dimensions.
+*/
+ if (!ct-crop_altered
+ ((ct-mode == S5P_JPEG_DECODE f_type == FMT_TYPE_CAPTURE) ||
+(ct-mode == S5P_JPEG_ENCODE f_type == FMT_TYPE_OUTPUT))) {
+ ct-crop_rect.width = pix-width;
+ ct-crop_rect.height = pix-height;
+ }
}
return 0;
--
1.7.9.5
--
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 4/9] s5p-jpeg: fix g_selection op
V4L2_SEL_TGT_COMPOSE_DEFAULT switch case should select whole available area of the image and V4L2_SEL_TGT_COMPOSE should apply user settings. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/platform/s5p-jpeg/jpeg-core.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c index 0854f37..09b59d3 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c @@ -1505,21 +1505,23 @@ static int s5p_jpeg_g_selection(struct file *file, void *priv, case V4L2_SEL_TGT_CROP: case V4L2_SEL_TGT_CROP_BOUNDS: case V4L2_SEL_TGT_CROP_DEFAULT: - case V4L2_SEL_TGT_COMPOSE: case V4L2_SEL_TGT_COMPOSE_DEFAULT: s-r.width = ctx-out_q.w; s-r.height = ctx-out_q.h; + s-r.left = 0; + s-r.top = 0; break; + case V4L2_SEL_TGT_COMPOSE: case V4L2_SEL_TGT_COMPOSE_BOUNDS: case V4L2_SEL_TGT_COMPOSE_PADDED: - s-r.width = ctx-cap_q.w; - s-r.height = ctx-cap_q.h; + s-r.width = ctx-crop_rect.width; + s-r.height = ctx-crop_rect.height; + s-r.left = ctx-crop_rect.left; + s-r.top = ctx-crop_rect.top; break; default: return -EINVAL; } - s-r.left = 0; - s-r.top = 0; return 0; } -- 1.7.9.5 -- 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 8/9] Documentation: devicetree: Document sclk-jpeg clock for exynos3250 SoC
JPEG IP on Exynos3250 SoC requires enabling two clock gates for its operation. This patch documents this requirement. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org --- .../bindings/media/exynos-jpeg-codec.txt |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt index 937b755..20cd150 100644 --- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt +++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt @@ -3,9 +3,12 @@ Samsung S5P/EXYNOS SoC series JPEG codec Required properties: - compatible : should be one of: - samsung,s5pv210-jpeg, samsung,exynos4210-jpeg; + samsung,s5pv210-jpeg, samsung,exynos4210-jpeg, + samsung,exynos3250-jpeg; - reg : address and length of the JPEG codec IP register set; - interrupts : specifies the JPEG codec IP interrupt; - clocks : should contain the JPEG codec IP gate clock specifier, from the - common clock bindings; -- clock-names : should contain jpeg entry. + common clock bindings; for Exynos3250 SoC special clock gate + should be defined as the second element of the clocks array +- clock-names : should contain jpeg entry and additionally sclk-jpeg entry + for Exynos3250 SoC -- 1.7.9.5 -- 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 7/9] s5p-jpeg: add chroma subsampling adjustment for Exynos3250
Take into account limitations specific to the Exynos3250 SoC,
regarding setting chroma subsampling control value.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 59 +--
1 file changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 1ef004b..283249d 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1603,36 +1603,53 @@ static int s5p_jpeg_g_volatile_ctrl(struct v4l2_ctrl
*ctrl)
return 0;
}
-static int s5p_jpeg_try_ctrl(struct v4l2_ctrl *ctrl)
+static int s5p_jpeg_adjust_subs_ctrl(struct s5p_jpeg_ctx *ctx, int *ctrl_val)
{
- struct s5p_jpeg_ctx *ctx = ctrl_to_ctx(ctrl);
- unsigned long flags;
- int ret = 0;
-
- spin_lock_irqsave(ctx-jpeg-slock, flags);
-
- if (ctrl-id == V4L2_CID_JPEG_CHROMA_SUBSAMPLING) {
- if (ctx-jpeg-variant-version == SJPEG_S5P)
- goto error_free;
+ switch (ctx-jpeg-variant-version) {
+ case SJPEG_S5P:
+ return 0;
+ case SJPEG_EXYNOS3250:
+ /*
+* The exynos3250 device can produce JPEG image only
+* of 4:4:4 subsampling when given RGB32 source image.
+*/
+ if (ctx-out_q.fmt-fourcc == V4L2_PIX_FMT_RGB32)
+ *ctrl_val = 0;
+ break;
+ case SJPEG_EXYNOS4:
/*
* The exynos4x12 device requires input raw image fourcc
* to be V4L2_PIX_FMT_GREY if gray jpeg format
* is to be set.
*/
if (ctx-out_q.fmt-fourcc != V4L2_PIX_FMT_GREY
- ctrl-val == V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY) {
- ret = -EINVAL;
- goto error_free;
- }
- /*
-* The exynos4x12 device requires resulting jpeg subsampling
-* not to be lower than the input raw image subsampling.
-*/
- if (ctx-out_q.fmt-subsampling ctrl-val)
- ctrl-val = ctx-out_q.fmt-subsampling;
+ *ctrl_val == V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY)
+ return -EINVAL;
+ break;
}
-error_free:
+ /*
+* The exynos4x12 and exynos3250 devices require resulting
+* jpeg subsampling not to be lower than the input raw image
+* subsampling.
+*/
+ if (ctx-out_q.fmt-subsampling *ctrl_val)
+ *ctrl_val = ctx-out_q.fmt-subsampling;
+
+ return 0;
+}
+
+static int s5p_jpeg_try_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct s5p_jpeg_ctx *ctx = ctrl_to_ctx(ctrl);
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(ctx-jpeg-slock, flags);
+
+ if (ctrl-id == V4L2_CID_JPEG_CHROMA_SUBSAMPLING)
+ ret = s5p_jpeg_adjust_subs_ctrl(ctx, ctrl-val);
+
spin_unlock_irqrestore(ctx-jpeg-slock, flags);
return ret;
}
--
1.7.9.5
--
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 6/9] s5p-jpeg: Prevent erroneous downscaling for Exynos3250 SoC
JPEG codec on Exynos3250 SoC produces broken raw image if
a JPEG is decoded to YUV420 format and downscaling by
more then 2 is applied. Prevent this by asserting downscale
ratio to 2.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 2491ef8..1ef004b 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1317,12 +1317,16 @@ static int exynos4_jpeg_get_output_buffer_size(struct
s5p_jpeg_ctx *ctx,
return w * h * fmt_depth 3;
}
+static int exynos3250_jpeg_try_downscale(struct s5p_jpeg_ctx *ctx,
+ struct v4l2_rect *r);
+
static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct, struct v4l2_format *f)
{
struct vb2_queue *vq;
struct s5p_jpeg_q_data *q_data = NULL;
struct v4l2_pix_format *pix = f-fmt.pix;
struct v4l2_ctrl *ctrl_subs;
+ struct v4l2_rect scale_rect;
unsigned int f_type;
vq = v4l2_m2m_get_vq(ct-fh.m2m_ctx, f-type);
@@ -1382,6 +1386,20 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct,
struct v4l2_format *f)
ct-crop_rect.width = pix-width;
ct-crop_rect.height = pix-height;
}
+
+ /*
+* Prevent downscaling to YUV420 format by more than 2
+* for Exynos3250 SoC as it produces broken raw image
+* in such cases.
+*/
+ if (ct-mode == S5P_JPEG_DECODE
+ f_type == FMT_TYPE_CAPTURE
+ ct-jpeg-variant-version == SJPEG_EXYNOS3250
+ pix-pixelformat == V4L2_PIX_FMT_YUV420
+ ct-scale_factor 2) {
+ scale_rect.width = ct-out_q.w / 2;
+ scale_rect.height = ct-out_q.h / 2;
+ exynos3250_jpeg_try_downscale(ct, scale_rect);
}
return 0;
--
1.7.9.5
--
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 9/9] ARM: dts: exynos3250: add JPEG codec device node
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/exynos3250.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 3e678fa..351871a 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -206,6 +206,18 @@
interrupts = 0 240 0;
};
+ jpeg-codec@1183 {
+ compatible = samsung,exynos3250-jpeg;
+ reg = 0x1183 0x1000;
+ interrupts = 0 171 0;
+ clocks = cmu CLK_JPEG, cmu CLK_SCLK_JPEG;
+ clock-names = jpeg, sclk-jpeg;
+ samsung,power-domain = pd_cam;
+ assigned-clock-parents = cmu CLK_MOUT_CAM_BLK cmu
CLK_DIV_MPLL_PRE,
+cmu CLK_SCLK_JPEG cmu;
+ assigned-clock-rates = cmu CLK_SCLK_JPEG 15000;
+ };
+
mshc_0: mshc@1251 {
compatible = samsung,exynos5250-dw-mshc;
reg = 0x1251 0x1000;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] media: rcar_vin: Fix race condition terminating stream
This patch fixes a race condition whereby a frame being captured may generate an
interrupt between requesting capture to halt and freeing buffers.
This condition is exposed by the earlier patch that explicitly calls
vb2_buffer_done() during stop streaming.
The solution is to wait for capture to finish prior to finalising these buffers.
Signed-off-by: Ian Molton ian.mol...@codethink.co.uk
Signed-off-by: William Towle william.to...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 43 ++--
1 file changed, 28 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 06ce705..aeda4e2 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -455,6 +455,29 @@ error:
vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
}
+/*
+ * Wait for capture to stop and all in-flight buffers to be finished with by
+ * the video hardware. This must be called under priv-lock
+ *
+ */
+static void rcar_vin_wait_stop_streaming(struct rcar_vin_priv *priv)
+{
+ while (priv-state != STOPPED) {
+
+ /* issue stop if running */
+ if (priv-state == RUNNING)
+ rcar_vin_request_capture_stop(priv);
+
+ /* wait until capturing has been stopped */
+ if (priv-state == STOPPING) {
+ priv-request_to_stop = true;
+ spin_unlock_irq(priv-lock);
+ wait_for_completion(priv-capture_stop);
+ spin_lock_irq(priv-lock);
+ }
+ }
+}
+
static void rcar_vin_videobuf_release(struct vb2_buffer *vb)
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vb-vb2_queue);
@@ -462,7 +485,6 @@ static void rcar_vin_videobuf_release(struct vb2_buffer *vb)
struct rcar_vin_priv *priv = ici-priv;
unsigned int i;
int buf_in_use = 0;
-
spin_lock_irq(priv-lock);
/* Is the buffer in use by the VIN hardware? */
@@ -474,20 +496,8 @@ static void rcar_vin_videobuf_release(struct vb2_buffer
*vb)
}
if (buf_in_use) {
- while (priv-state != STOPPED) {
-
- /* issue stop if running */
- if (priv-state == RUNNING)
- rcar_vin_request_capture_stop(priv);
-
- /* wait until capturing has been stopped */
- if (priv-state == STOPPING) {
- priv-request_to_stop = true;
- spin_unlock_irq(priv-lock);
- wait_for_completion(priv-capture_stop);
- spin_lock_irq(priv-lock);
- }
- }
+ rcar_vin_wait_stop_streaming(priv);
+
/*
* Capturing has now stopped. The buffer we have been asked
* to release could be any of the current buffers in use, so
@@ -517,12 +527,15 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq)
spin_lock_irq(priv-lock);
+ rcar_vin_wait_stop_streaming(priv);
+
for (i = 0; i vq-num_buffers; ++i)
if (vq-bufs[i]-state == VB2_BUF_STATE_ACTIVE)
vb2_buffer_done(vq-bufs[i], VB2_BUF_STATE_ERROR);
list_for_each_safe(buf_head, tmp, priv-capture)
list_del_init(buf_head);
+
spin_unlock_irq(priv-lock);
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] media: rcar_vin: Clean up rcar_vin_irq
This patch makes the rcar_vin IRQ handler a little more readable.
Removes an else clause, and simplifies the buffer handling.
Signed-off-by: Ian Molton ian.mol...@codethink.co.uk
Reviewed-by: William Towle william.to...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index aeda4e2..a8d2785 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -554,7 +554,6 @@ static irqreturn_t rcar_vin_irq(int irq, void *data)
struct rcar_vin_priv *priv = data;
u32 int_status;
bool can_run = false, hw_stopped;
- int slot;
unsigned int handled = 0;
spin_lock(priv-lock);
@@ -573,17 +572,22 @@ static irqreturn_t rcar_vin_irq(int irq, void *data)
hw_stopped = !(ioread32(priv-base + VNMS_REG) VNMS_CA);
if (!priv-request_to_stop) {
+ struct vb2_buffer **q_entry = priv-queue_buf;
+ struct vb2_buffer *vb;
+
if (is_continuous_transfer(priv))
- slot = (ioread32(priv-base + VNMS_REG)
- VNMS_FBS_MASK) VNMS_FBS_SHIFT;
- else
- slot = 0;
+ q_entry += (ioread32(priv-base + VNMS_REG)
+ VNMS_FBS_MASK) VNMS_FBS_SHIFT;
+
+ vb = *q_entry;
+
+ vb-v4l2_buf.field = priv-field;
+ vb-v4l2_buf.sequence = priv-sequence++;
+ do_gettimeofday(vb-v4l2_buf.timestamp);
+
+ vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
- priv-queue_buf[slot]-v4l2_buf.field = priv-field;
- priv-queue_buf[slot]-v4l2_buf.sequence = priv-sequence++;
- do_gettimeofday(priv-queue_buf[slot]-v4l2_buf.timestamp);
- vb2_buffer_done(priv-queue_buf[slot], VB2_BUF_STATE_DONE);
- priv-queue_buf[slot] = NULL;
+ *q_entry = NULL;
if (priv-state != STOPPING)
can_run = rcar_vin_fill_hw_slot(priv);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] media: rcar_vin: Ensure all in-flight buffers are returned to error state before stopping.
Videobuf2 complains about buffers that are still marked ACTIVE (in use by the driver) following a call to stop_streaming(). This patch returns all active buffers to state ERROR prior to stopping. Note: this introduces a (non fatal) race condition as the stream is not guaranteed to be stopped at this point. Signed-off-by: Ian Molton ian.mol...@codethink.co.uk Signed-off-by: William Towle william.to...@codethink.co.uk --- drivers/media/platform/soc_camera/rcar_vin.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 7154500..06ce705 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -513,8 +513,14 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq) struct soc_camera_host *ici = to_soc_camera_host(icd-parent); struct rcar_vin_priv *priv = ici-priv; struct list_head *buf_head, *tmp; + int i; spin_lock_irq(priv-lock); + + for (i = 0; i vq-num_buffers; ++i) + if (vq-bufs[i]-state == VB2_BUF_STATE_ACTIVE) + vb2_buffer_done(vq-bufs[i], VB2_BUF_STATE_ERROR); + list_for_each_safe(buf_head, tmp, priv-capture) list_del_init(buf_head); spin_unlock_irq(priv-lock); -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] rcar_vin: fix soc_camera WARN_ON() issues.
This patch series provides fixes that allow the rcar_vin driver to function without triggering dozens of warnings from the videobuf2 and soc_camera layers. Patches 2/3 should probably be merged into a single, atomic change, although patch 2 does not make the existing situation /worse/ in and of itself. Patch 4 does not change the code logic, but is cleaner and less prone to breakage caused by furtutre modification. Also, more consistent with the use of vb pointers elsewhere in the driver. Comments welcome! -Ian -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] media: rcar_vin: Dont aggressively retire buffers
rcar_vin_videobuf_release() is called once per buffer from the buf_cleanup hook.
There is no need to look up the queue and free all buffers at this point.
Signed-off-by: Ian Molton ian.mol...@codethink.co.uk
Signed-off-by: William Towle william.to...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index e594230..7154500 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -493,17 +493,11 @@ static void rcar_vin_videobuf_release(struct vb2_buffer
*vb)
* to release could be any of the current buffers in use, so
* release all buffers that are in use by HW
*/
- for (i = 0; i MAX_BUFFER_NUM; i++) {
- if (priv-queue_buf[i]) {
- vb2_buffer_done(priv-queue_buf[i],
- VB2_BUF_STATE_ERROR);
- priv-queue_buf[i] = NULL;
- }
- }
- } else {
- list_del_init(to_buf_list(vb));
+ priv-queue_buf[i] = NULL;
}
+ list_del_init(to_buf_list(vb));
+
spin_unlock_irq(priv-lock);
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linux-kernel] [PATCH 0/4] rcar_vin: fix soc_camera WARN_ON() issues.
On 07/07/14 17:37, Ian Molton wrote: This patch series provides fixes that allow the rcar_vin driver to function without triggering dozens of warnings from the videobuf2 and soc_camera layers. Patches 2/3 should probably be merged into a single, atomic change, although patch 2 does not make the existing situation /worse/ in and of itself. Patch 4 does not change the code logic, but is cleaner and less prone to breakage caused by furtutre modification. Also, more consistent with the use of vb pointers elsewhere in the driver. Comments welcome! You should have probably CC:d the original authors as well as the linux-sh list and possibly Magnus and Horms. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- 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 0/9] Updated fence patch series
On Mon, Jul 07, 2014 at 03:23:17PM +0200, Daniel Vetter wrote: On Wed, Jul 2, 2014 at 7:37 AM, Greg KH gre...@linuxfoundation.org wrote: Android can expose fences to userspace. It's possible to make the new fence mechanism expose the same fences to userspace by changing sync_fence_create to take a struct fence instead of a struct sync_pt. No other change is needed, because only the fence parts of struct sync_pt are used. But because the userspace fences are a separate problem and I haven't really looked at it yet I feel it should stay in staging, for now. Ok, that's reasonable. At first glance, this all looks sane to me, any objection from anyone if I merge this through my driver-core tree for 3.17? Ack from my side fwiw. Thanks, I'll queue it up later today. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] Updated fence patch series
Hi Greg, On 2 July 2014 11:07, Greg KH gre...@linuxfoundation.org wrote: On Tue, Jul 01, 2014 at 12:57:02PM +0200, Maarten Lankhorst wrote: So after some more hacking I've moved dma-buf to its own subdirectory, drivers/dma-buf and applied the fence patches to its new place. I believe that the first patch should be applied regardless, and the rest should be ready now. :-) Changes to the fence api: - release_fence - fence_release etc. - __fence_init - fence_init - __fence_signal - fence_signal_locked - __fence_is_signaled - fence_is_signaled_locked - Changing BUG_ON to WARN_ON in fence_later, and return NULL if it triggers. Android can expose fences to userspace. It's possible to make the new fence mechanism expose the same fences to userspace by changing sync_fence_create to take a struct fence instead of a struct sync_pt. No other change is needed, because only the fence parts of struct sync_pt are used. But because the userspace fences are a separate problem and I haven't really looked at it yet I feel it should stay in staging, for now. Ok, that's reasonable. At first glance, this all looks sane to me, any objection from anyone if I merge this through my driver-core tree for 3.17? Fwiw, Ack from me as well! thanks, greg k-h Best regards, ~Sumit. -- 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
New v4l2 driver does not allow brightness/contrast control
I have a v4l2 video capture board that using kernel 2.6 with v4l2 em28xx driver 3.0.36 allows me to control brightness, contrast etc... However in kernel 3.2 with v4l2 em28xx driver version 3.2.0 it does not. This is what I get from the latest driver: root@android:/ # v4l2-ctl --info Driver Info (not using libv4l2): Driver name : em28xx Card type : EM2860/SAA711X Reference Design Bus info : usb-musb-hdrc.1-1 Driver version: 3.2.0 Capabilities : 0x05020051 Video Capture VBI Capture Sliced VBI Capture Audio Read/Write Streaming root@android:/ # v4l2-ctl -d 0 -l volume (int): min=0 max=31 step=1 default=31 value=31 flags=slider mute (bool) : default=1 value=1 What could be wrong? -- Atenciosamente, Coutinho -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/1] em28xx: fix configuration warning
This patch tries to solve a problem detected with random configuration. warning: (VIDEO_EM28XX_V4L2) selects VIDEO_MT9V011 which has unmet direct dependencies (MEDIA_SUPPORT I2C VIDEO_V4L2 MEDIA_CAMERA_SUPPORT) Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: linux-media@vger.kernel.org Signed-off-by: Fabian Frederick f...@skynet.be --- drivers/media/usb/em28xx/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/usb/em28xx/Kconfig b/drivers/media/usb/em28xx/Kconfig index f5d7198..d42e1de 100644 --- a/drivers/media/usb/em28xx/Kconfig +++ b/drivers/media/usb/em28xx/Kconfig @@ -7,6 +7,7 @@ config VIDEO_EM28XX config VIDEO_EM28XX_V4L2 tristate Empia EM28xx analog TV, video capture and/or webcam support depends on VIDEO_EM28XX + depends on MEDIA_CAMERA_SUPPORT select VIDEOBUF2_VMALLOC select VIDEO_SAA711X if MEDIA_SUBDRV_AUTOSELECT select VIDEO_TVP5150 if MEDIA_SUBDRV_AUTOSELECT -- 1.8.4.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/1] em28xx: fix configuration warning
Hi Fabian, Em Mon, 07 Jul 2014 20:51:55 +0200 Fabian Frederick f...@skynet.be escreveu: This patch tries to solve a problem detected with random configuration. warning: (VIDEO_EM28XX_V4L2) selects VIDEO_MT9V011 which has unmet direct dependencies (MEDIA_SUPPORT I2C VIDEO_V4L2 MEDIA_CAMERA_SUPPORT) The above warning is bogus. The thing is that em28xx driver can be used by webcams, analog TV and/or digital TV. No idea how to prevent Kbuild to complain about that. Perhaps something like that will shut it up depends on MEDIA_CAMERA_SUPPORT if MEDIA_CAMERA_SUPPORT Regards, Mauro Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: linux-media@vger.kernel.org Signed-off-by: Fabian Frederick f...@skynet.be --- drivers/media/usb/em28xx/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/usb/em28xx/Kconfig b/drivers/media/usb/em28xx/Kconfig index f5d7198..d42e1de 100644 --- a/drivers/media/usb/em28xx/Kconfig +++ b/drivers/media/usb/em28xx/Kconfig @@ -7,6 +7,7 @@ config VIDEO_EM28XX config VIDEO_EM28XX_V4L2 tristate Empia EM28xx analog TV, video capture and/or webcam support depends on VIDEO_EM28XX + depends on MEDIA_CAMERA_SUPPORT select VIDEOBUF2_VMALLOC select VIDEO_SAA711X if MEDIA_SUBDRV_AUTOSELECT select VIDEO_TVP5150 if MEDIA_SUBDRV_AUTOSELECT -- 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
Few questions about dibusb i2c over usb protocol
Hello. 1) As I understand format of i2c read command is following: 2, (dev_i2c_addr1)|1, addr_hi, addr_lo, size_hi, size_lo but in debug output I saw following commands: 02 a3 00 01 55 02 a3 00 04 55 00 53 00 This commands are shorter then command described above. Meaning of bytes 1, 2 and 4 is clear, but what mean third byte: if it is size_hi, then where is address? if it is addr_lo, then it is not clear why answer's first byte is 55 according to Cypress documentation first byte of program eeprom should be C2 2) What is format for i2c write command? 3, dev_i2c_addr1, addr_hi, addr_lo, data... ? 3) what mean following command 03 a2 51 3f 80 write byte 80 at address 513f? 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
Status of the ddbridge driver update
Hi Maik, What is the current status of the ddbridge driver update ? Are you still working on it ? I'm not seeing any update since November 2013. Do you have an updated version of what you sent last ? I'd like to continue your work if you cannot work on this anymore. Regards, Guy -- 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
fix PCTV 461e tuner I2C binding
Mauro/Antti,
I have been looking at the following commit to
drivers/media/usb/em28xx/em28xx-dvb.c
a83b93a7480441a47856dc9104bea970e84cda87
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1630,6 +1630,7 @@ static int em28xx_dvb_resume(struct em28xx *dev)
em28xx_info(Resuming DVB extension);
if (dev-dvb) {
struct em28xx_dvb *dvb = dev-dvb;
+ struct i2c_client *client = dvb-i2c_client_tuner;
if (dvb-fe[0]) {
ret = dvb_frontend_resume(dvb-fe[0]);
@@ -1640,6 +1641,15 @@ static int em28xx_dvb_resume(struct em28xx *dev)
ret = dvb_frontend_resume(dvb-fe[1]);
em28xx_info(fe1 resume %d, ret);
}
+ /* remove I2C tuner */
+ if (client) {
+ module_put(client-dev.driver-owner);
+ i2c_unregister_device(client);
+ }
+
+ em28xx_unregister_dvb(dvb);
+ kfree(dvb);
+ dev-dvb = NULL;
}
Why are we unregistering i2c devices and dvb in this resume path?
Looks incorrect to me.
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
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: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Jul 8 04:00:21 CEST 2014 git branch: test git hash: 3c0d394ea7022bb9666d9df97a5776c4bcc3045c gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-14-gf11dd94 host hardware: x86_64 host os:3.14-5.slh.5-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.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fix PCTV 461e tuner I2C binding
Moikka Shuah
On 07/08/2014 02:34 AM, Shuah Khan wrote:
Mauro/Antti,
I have been looking at the following commit to
drivers/media/usb/em28xx/em28xx-dvb.c
a83b93a7480441a47856dc9104bea970e84cda87
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1630,6 +1630,7 @@ static int em28xx_dvb_resume(struct em28xx *dev)
em28xx_info(Resuming DVB extension);
if (dev-dvb) {
struct em28xx_dvb *dvb = dev-dvb;
+ struct i2c_client *client = dvb-i2c_client_tuner;
if (dvb-fe[0]) {
ret = dvb_frontend_resume(dvb-fe[0]);
@@ -1640,6 +1641,15 @@ static int em28xx_dvb_resume(struct em28xx *dev)
ret = dvb_frontend_resume(dvb-fe[1]);
em28xx_info(fe1 resume %d, ret);
}
+ /* remove I2C tuner */
+ if (client) {
+ module_put(client-dev.driver-owner);
+ i2c_unregister_device(client);
+ }
+
+ em28xx_unregister_dvb(dvb);
+ kfree(dvb);
+ dev-dvb = NULL;
}
Why are we unregistering i2c devices and dvb in this resume path?
Looks incorrect to me.
I don't know. Original patch I send was a bit different and tuner was
removed only during em28xx_dvb_fini()
https://patchwork.linuxtv.org/patch/22275/
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] tda10071: fix returned symbol rate calculation
Detected symbol rate value was returned too small. Signed-off-by: Antti Palosaari cr...@iki.fi --- drivers/media/dvb-frontends/tda10071.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/tda10071.c b/drivers/media/dvb-frontends/tda10071.c index d590798..9619be5 100644 --- a/drivers/media/dvb-frontends/tda10071.c +++ b/drivers/media/dvb-frontends/tda10071.c @@ -860,7 +860,7 @@ static int tda10071_get_frontend(struct dvb_frontend *fe) if (ret) goto error; - c-symbol_rate = (buf[0] 16) | (buf[1] 8) | (buf[2] 0); + c-symbol_rate = ((buf[0] 16) | (buf[1] 8) | (buf[2] 0)) * 1000; return ret; error: -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] tda10071: fix spec inversion reporting
Inversion ON was reported as inversion OFF and vice versa.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/tda10071.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-frontends/tda10071.c
b/drivers/media/dvb-frontends/tda10071.c
index 49874e7..d590798 100644
--- a/drivers/media/dvb-frontends/tda10071.c
+++ b/drivers/media/dvb-frontends/tda10071.c
@@ -838,10 +838,10 @@ static int tda10071_get_frontend(struct dvb_frontend *fe)
switch ((buf[1] 0) 0x01) {
case 0:
- c-inversion = INVERSION_OFF;
+ c-inversion = INVERSION_ON;
break;
case 1:
- c-inversion = INVERSION_ON;
+ c-inversion = INVERSION_OFF;
break;
}
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] tda10071: add missing DVB-S2/PSK-8 FEC AUTO
FEC AUTO is valid for PSK-8 modulation too. Add it.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/tda10071_priv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/dvb-frontends/tda10071_priv.h
b/drivers/media/dvb-frontends/tda10071_priv.h
index 4baf14b..4204861 100644
--- a/drivers/media/dvb-frontends/tda10071_priv.h
+++ b/drivers/media/dvb-frontends/tda10071_priv.h
@@ -55,6 +55,7 @@ static struct tda10071_modcod {
{ SYS_DVBS2, QPSK, FEC_8_9, 0x0a },
{ SYS_DVBS2, QPSK, FEC_9_10, 0x0b },
/* 8PSK */
+ { SYS_DVBS2, PSK_8, FEC_AUTO, 0x00 },
{ SYS_DVBS2, PSK_8, FEC_3_5, 0x0c },
{ SYS_DVBS2, PSK_8, FEC_2_3, 0x0d },
{ SYS_DVBS2, PSK_8, FEC_3_4, 0x0e },
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] tda10071: force modulation to QPSK on DVB-S
Only supported modulation for DVB-S is QPSK. Modulation parameter
contains invalid value for DVB-S on some cases, which leads driver
refusing tuning attempt. Due to that, hard code modulation to QPSK
in case of DVB-S.
Cc: sta...@vger.kernel.org
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/tda10071.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/tda10071.c
b/drivers/media/dvb-frontends/tda10071.c
index 522fe00..49874e7 100644
--- a/drivers/media/dvb-frontends/tda10071.c
+++ b/drivers/media/dvb-frontends/tda10071.c
@@ -668,6 +668,7 @@ static int tda10071_set_frontend(struct dvb_frontend *fe)
struct dtv_frontend_properties *c = fe-dtv_property_cache;
int ret, i;
u8 mode, rolloff, pilot, inversion, div;
+ fe_modulation_t modulation;
dev_dbg(priv-i2c-dev,
%s: delivery_system=%d modulation=%d frequency=%d
symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n,
@@ -702,10 +703,13 @@ static int tda10071_set_frontend(struct dvb_frontend *fe)
switch (c-delivery_system) {
case SYS_DVBS:
+ modulation = QPSK;
rolloff = 0;
pilot = 2;
break;
case SYS_DVBS2:
+ modulation = c-modulation;
+
switch (c-rolloff) {
case ROLLOFF_20:
rolloff = 2;
@@ -750,7 +754,7 @@ static int tda10071_set_frontend(struct dvb_frontend *fe)
for (i = 0, mode = 0xff; i ARRAY_SIZE(TDA10071_MODCOD); i++) {
if (c-delivery_system == TDA10071_MODCOD[i].delivery_system
- c-modulation == TDA10071_MODCOD[i].modulation
+ modulation == TDA10071_MODCOD[i].modulation
c-fec_inner == TDA10071_MODCOD[i].fec) {
mode = TDA10071_MODCOD[i].val;
dev_dbg(priv-i2c-dev, %s: mode found=%02x\n,
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 3.16] tda10071 fixes
The following changes since commit 13936af3d2f04f173a83cc050dbc4b20d8562b81: [media] saa7134: use unlocked_ioctl instead of ioctl (2014-06-19 13:14:51 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git tda10071 for you to fetch changes up to c1154dfb51a9628cc52ece398343ca775d9e0c43: tda10071: fix returned symbol rate calculation (2014-07-08 08:51:47 +0300) Antti Palosaari (4): tda10071: force modulation to QPSK on DVB-S tda10071: add missing DVB-S2/PSK-8 FEC AUTO tda10071: fix spec inversion reporting tda10071: fix returned symbol rate calculation drivers/media/dvb-frontends/tda10071.c | 12 drivers/media/dvb-frontends/tda10071_priv.h | 1 + 2 files changed, 9 insertions(+), 4 deletions(-) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 3.16] tda10071 fixes
These are not very critical and all are old, so better to pull for 3.17 as it is now 3.16-rc4... regards Antti On 07/08/2014 08:55 AM, Antti Palosaari wrote: The following changes since commit 13936af3d2f04f173a83cc050dbc4b20d8562b81: [media] saa7134: use unlocked_ioctl instead of ioctl (2014-06-19 13:14:51 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git tda10071 for you to fetch changes up to c1154dfb51a9628cc52ece398343ca775d9e0c43: tda10071: fix returned symbol rate calculation (2014-07-08 08:51:47 +0300) Antti Palosaari (4): tda10071: force modulation to QPSK on DVB-S tda10071: add missing DVB-S2/PSK-8 FEC AUTO tda10071: fix spec inversion reporting tda10071: fix returned symbol rate calculation drivers/media/dvb-frontends/tda10071.c | 12 drivers/media/dvb-frontends/tda10071_priv.h | 1 + 2 files changed, 9 insertions(+), 4 deletions(-) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
