Re: [PATCH RFC] [media] blackfin: add video display driver
Hi Sylwester ,
@@ -9,7 +9,18 @@ config VIDEO_BLACKFIN_CAPTURE
To compile this driver as a module, choose M here: the
module will be called bfin_capture.
+config VIDEO_BLACKFIN_DISPLAY
+ tristate Blackfin Video Display Driver
+ depends on VIDEO_V4L2 BLACKFIN I2C
+ select VIDEOBUF2_DMA_CONTIG
+ help
+ V4L2 bridge driver for Blackfin video display device.
Shouldn't it just be V4L2 output driver, why are you calling it bridge ?
Hmm, capture-display, input-output, right?
The kernel docs called it bridge, may host sounds better.
+/*
+ * Analog Devices video display driver
Sounds a bit too generic.
+ *
+ * Copyright (c) 2011 Analog Devices Inc.
2011 - 2013 ?
Written in 2011.
+struct disp_fh {
+ struct v4l2_fh fh;
+ /* indicates whether this file handle is doing IO */
+ bool io_allowed;
+};
This structure should not be needed when you use the vb2 helpers. Please see
below for more details.
The only question is how the core deal with the permission that which
file handle can
stream off the output. I want to impose a rule that only IO handle can stop IO.
I refer to priority, but current kernel driver export this to user
space and let user decide it.
--
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
[REVIEW PATCH for v3.10] mem2mem_testdev: set timestamp_type and add debug param
While testing v4l2-ctl I noticed that this m2m driver didn't set timestamp_type
and that it spammed the kernel log with debug messages. Set timestamp_type
correctly and add debug module option to enable debug messages.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/platform/mem2mem_testdev.c
b/drivers/media/platform/mem2mem_testdev.c
index 7487d72..4cc7f65d 100644
--- a/drivers/media/platform/mem2mem_testdev.c
+++ b/drivers/media/platform/mem2mem_testdev.c
@@ -38,6 +38,10 @@ MODULE_AUTHOR(Pawel Osciak, pa...@osciak.com);
MODULE_LICENSE(GPL);
MODULE_VERSION(0.1.1);
+static unsigned debug;
+module_param(debug, uint, 0644);
+MODULE_PARM_DESC(debug, activates debug info);
+
#define MIN_W 32
#define MIN_H 32
#define MAX_W 640
@@ -67,7 +71,7 @@ MODULE_VERSION(0.1.1);
#define MEM2MEM_VFLIP (1 1)
#define dprintk(dev, fmt, arg...) \
- v4l2_dbg(1, 1, dev-v4l2_dev, %s: fmt, __func__, ## arg)
+ v4l2_dbg(1, debug, dev-v4l2_dev, %s: fmt, __func__, ## arg)
static void m2mtest_dev_release(struct device *dev)
@@ -234,6 +238,10 @@ static int device_process(struct m2mtest_ctx *ctx,
bytes_left = bytesperline - tile_w * MEM2MEM_NUM_TILES;
w = 0;
+ memcpy(out_vb-v4l2_buf.timestamp,
+ in_vb-v4l2_buf.timestamp,
+ sizeof(struct timeval));
+
switch (ctx-mode) {
case MEM2MEM_HFLIP | MEM2MEM_VFLIP:
p_out += bytesperline * height - bytes_left;
@@ -844,6 +852,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
struct vb2_queue *ds
src_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer);
src_vq-ops = m2mtest_qops;
src_vq-mem_ops = vb2_vmalloc_memops;
+ src_vq-timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_COPY;
ret = vb2_queue_init(src_vq);
if (ret)
@@ -855,6 +864,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
struct vb2_queue *ds
dst_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer);
dst_vq-ops = m2mtest_qops;
dst_vq-mem_ops = vb2_vmalloc_memops;
+ dst_vq-timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_COPY;
return vb2_queue_init(dst_vq);
}
--
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 v4 1/2] v4l2-ctl: add is_compressed_format() helper
On Thu April 11 2013 21:46:54 Tzu-Jung Lee wrote:
To bypass precalculate_bars() for OUTPUT device
that takes encoded bitstreams.
I haven't forgotten your patches, but I want to clean up the streaming code
some more first. I hope to have finished with that this weekend.
Regards,
Hans
Signed-off-by: Tzu-Jung Lee tj...@ambarella.com
---
utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 40
++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
index 9e361af..035c3c7 100644
--- a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
@@ -115,6 +115,23 @@ static const flag_def tc_flags_def[] = {
{ 0, NULL }
};
+static bool is_compressed_format(int fd, struct v4l2_format *f)
+{
+ struct v4l2_fmtdesc fmt;
+
+ memset(fmt, 0, sizeof(fmt));
+ fmt.type = f-type;
+
+ while (test_ioctl(fd, VIDIOC_ENUM_FMT, fmt) = 0) {
+ if (fmt.pixelformat == f-fmt.pix.pixelformat)
+ return fmt.flags V4L2_FMT_FLAG_COMPRESSED;
+
+ fmt.index++;
+ }
+
+ return false;
+}
+
static void print_buffer(FILE *f, struct v4l2_buffer buf)
{
fprintf(f, \tIndex: %d\n, buf.index);
@@ -312,12 +329,16 @@ static void do_setup_out_buffers(int fd, struct
v4l2_requestbuffers *reqbufs,
bool is_mplane, unsigned num_planes, bool
is_mmap,
void *buffers[], unsigned buffer_lengths[],
FILE *fin)
{
+ bool is_compressed;
+
struct v4l2_format fmt;
memset(fmt, 0, sizeof(fmt));
fmt.type = reqbufs-type;
doioctl(fd, VIDIOC_G_FMT, fmt);
- if (!precalculate_bars(fmt.fmt.pix.pixelformat, stream_pat)) {
+ is_compressed = is_compressed_format(fd, fmt);
+ if (!is_compressed
+ !precalculate_bars(fmt.fmt.pix.pixelformat, stream_pat)) {
fprintf(stderr, unsupported pixelformat\n);
return;
}
@@ -688,7 +709,9 @@ static void streaming_set_cap(int fd)
static void streaming_set_out(int fd)
{
struct v4l2_requestbuffers reqbufs;
+ struct v4l2_format fmt;
int fd_flags = fcntl(fd, F_GETFL);
+ bool is_compressed;
bool is_mplane = capabilities
(V4L2_CAP_VIDEO_OUTPUT_MPLANE |
V4L2_CAP_VIDEO_M2M_MPLANE);
@@ -710,6 +733,12 @@ static void streaming_set_out(int fd)
reqbufs.type = type;
reqbufs.memory = is_mmap ? V4L2_MEMORY_MMAP : V4L2_MEMORY_USERPTR;
+ memset(fmt, 0, sizeof(fmt));
+ fmt.type = reqbufs.type;
+ doioctl(fd, VIDIOC_G_FMT, fmt);
+
+ is_compressed = is_compressed_format(fd, fmt);
+
if (file_out) {
if (!strcmp(file_out, -))
fin = stdin;
@@ -795,6 +824,9 @@ enum stream_type {
static void streaming_set_m2m(int fd)
{
+ struct v4l2_format fmt;
+ bool is_compressed;
+
int fd_flags = fcntl(fd, F_GETFL);
bool use_poll = options[OptStreamPoll];
@@ -864,6 +896,12 @@ static void streaming_set_m2m(int fd)
is_mmap, buffers_out, buffer_lengths_out,
file[OUT]);
+ memset(fmt, 0, sizeof(fmt));
+ fmt.type = reqbufs[OUT].type;
+ doioctl(fd, VIDIOC_G_FMT, fmt);
+
+ is_compressed = is_compressed_format(fd, fmt);
+
if (doioctl(fd, VIDIOC_STREAMON, type[CAP]) ||
doioctl(fd, VIDIOC_STREAMON, type[OUT]))
return;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] [media] dvb-frontends: lg2160: dubious one-bit signed bitfield
Sparse complains that these are dubious one-bit signed bitfields and
the comment says it was intended to be 1 and 0 instead of -1 and 0.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/media/dvb-frontends/lg2160.h
b/drivers/media/dvb-frontends/lg2160.h
index a5f0368..194a07a 100644
--- a/drivers/media/dvb-frontends/lg2160.h
+++ b/drivers/media/dvb-frontends/lg2160.h
@@ -57,10 +57,10 @@ struct lg2160_config {
u16 if_khz;
/* disable i2c repeater - 0:repeater enabled 1:repeater disabled */
- int deny_i2c_rptr:1;
+ unsigned int deny_i2c_rptr:1;
/* spectral inversion - 0:disabled 1:enabled */
- int spectral_inversion:1;
+ unsigned int spectral_inversion:1;
unsigned int output_if;
enum lg2160_spi_clock spi_clock;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] [media] go7007: dubious one-bit signed bitfields
Because they're signed, is_video and is_audio can be 0 and -1
instead of 0 and 1 as intended. It doesn't cause a bug, but it makes
Sparse complain:
drivers/staging/media/go7007/go7007-priv.h:94:31: error: dubious one-bit signed
bitfield
drivers/staging/media/go7007/go7007-priv.h:95:31: error: dubious one-bit signed
bitfield
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/staging/media/go7007/go7007-priv.h
b/drivers/staging/media/go7007/go7007-priv.h
index 8bde187..6e16af7 100644
--- a/drivers/staging/media/go7007/go7007-priv.h
+++ b/drivers/staging/media/go7007/go7007-priv.h
@@ -91,8 +91,8 @@ struct go7007_board_info {
int num_i2c_devs;
struct go_i2c {
const char *type;
- int is_video:1;
- int is_audio:1;
+ unsigned int is_video:1;
+ unsigned int is_audio:1;
int addr;
u32 flags;
} i2c_devs[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: [PATCH v4 1/2] v4l2-ctl: add is_compressed_format() helper
On Wed, Apr 17, 2013 at 3:09 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On Thu April 11 2013 21:46:54 Tzu-Jung Lee wrote:
To bypass precalculate_bars() for OUTPUT device
that takes encoded bitstreams.
I haven't forgotten your patches, but I want to clean up the streaming code
some more first. I hope to have finished with that this weekend.
One more thing about streaming code:
I just realized that the non-polling case for M2M isn't working, at
least for bitstreams to bitstreams case.
Without timeout, it can be blocked indefinitely by DQBUF of either
CAPTURE or OUTPUT queues.
QUERYBUF for any available buffers before issuing DQBUF might work,
but it seems to be overkill.
And it just degenerates to another form of polling mode...
Thanks.
Roy
Signed-off-by: Tzu-Jung Lee tj...@ambarella.com
---
utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 40
++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
index 9e361af..035c3c7 100644
--- a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
@@ -115,6 +115,23 @@ static const flag_def tc_flags_def[] = {
{ 0, NULL }
};
+static bool is_compressed_format(int fd, struct v4l2_format *f)
+{
+ struct v4l2_fmtdesc fmt;
+
+ memset(fmt, 0, sizeof(fmt));
+ fmt.type = f-type;
+
+ while (test_ioctl(fd, VIDIOC_ENUM_FMT, fmt) = 0) {
+ if (fmt.pixelformat == f-fmt.pix.pixelformat)
+ return fmt.flags V4L2_FMT_FLAG_COMPRESSED;
+
+ fmt.index++;
+ }
+
+ return false;
+}
+
static void print_buffer(FILE *f, struct v4l2_buffer buf)
{
fprintf(f, \tIndex: %d\n, buf.index);
@@ -312,12 +329,16 @@ static void do_setup_out_buffers(int fd, struct
v4l2_requestbuffers *reqbufs,
bool is_mplane, unsigned num_planes, bool
is_mmap,
void *buffers[], unsigned buffer_lengths[],
FILE *fin)
{
+ bool is_compressed;
+
struct v4l2_format fmt;
memset(fmt, 0, sizeof(fmt));
fmt.type = reqbufs-type;
doioctl(fd, VIDIOC_G_FMT, fmt);
- if (!precalculate_bars(fmt.fmt.pix.pixelformat, stream_pat)) {
+ is_compressed = is_compressed_format(fd, fmt);
+ if (!is_compressed
+ !precalculate_bars(fmt.fmt.pix.pixelformat, stream_pat)) {
fprintf(stderr, unsupported pixelformat\n);
return;
}
@@ -688,7 +709,9 @@ static void streaming_set_cap(int fd)
static void streaming_set_out(int fd)
{
struct v4l2_requestbuffers reqbufs;
+ struct v4l2_format fmt;
int fd_flags = fcntl(fd, F_GETFL);
+ bool is_compressed;
bool is_mplane = capabilities
(V4L2_CAP_VIDEO_OUTPUT_MPLANE |
V4L2_CAP_VIDEO_M2M_MPLANE);
@@ -710,6 +733,12 @@ static void streaming_set_out(int fd)
reqbufs.type = type;
reqbufs.memory = is_mmap ? V4L2_MEMORY_MMAP : V4L2_MEMORY_USERPTR;
+ memset(fmt, 0, sizeof(fmt));
+ fmt.type = reqbufs.type;
+ doioctl(fd, VIDIOC_G_FMT, fmt);
+
+ is_compressed = is_compressed_format(fd, fmt);
+
if (file_out) {
if (!strcmp(file_out, -))
fin = stdin;
@@ -795,6 +824,9 @@ enum stream_type {
static void streaming_set_m2m(int fd)
{
+ struct v4l2_format fmt;
+ bool is_compressed;
+
int fd_flags = fcntl(fd, F_GETFL);
bool use_poll = options[OptStreamPoll];
@@ -864,6 +896,12 @@ static void streaming_set_m2m(int fd)
is_mmap, buffers_out, buffer_lengths_out,
file[OUT]);
+ memset(fmt, 0, sizeof(fmt));
+ fmt.type = reqbufs[OUT].type;
+ doioctl(fd, VIDIOC_G_FMT, fmt);
+
+ is_compressed = is_compressed_format(fd, fmt);
+
if (doioctl(fd, VIDIOC_STREAMON, type[CAP]) ||
doioctl(fd, VIDIOC_STREAMON, type[OUT]))
return;
--
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] go7007: dubious one-bit signed bitfields
On Wed 17 April 2013 09:20:30 Dan Carpenter wrote:
Because they're signed, is_video and is_audio can be 0 and -1
instead of 0 and 1 as intended. It doesn't cause a bug, but it makes
Sparse complain:
drivers/staging/media/go7007/go7007-priv.h:94:31: error: dubious one-bit
signed bitfield
drivers/staging/media/go7007/go7007-priv.h:95:31: error: dubious one-bit
signed bitfield
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Thanks!
Hans
diff --git a/drivers/staging/media/go7007/go7007-priv.h
b/drivers/staging/media/go7007/go7007-priv.h
index 8bde187..6e16af7 100644
--- a/drivers/staging/media/go7007/go7007-priv.h
+++ b/drivers/staging/media/go7007/go7007-priv.h
@@ -91,8 +91,8 @@ struct go7007_board_info {
int num_i2c_devs;
struct go_i2c {
const char *type;
- int is_video:1;
- int is_audio:1;
+ unsigned int is_video:1;
+ unsigned int is_audio:1;
int addr;
u32 flags;
} i2c_devs[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
--
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
Anyone working on supporting sdio cams under Linux
Hi, Yes I mean camaras which connect to the computer / tablet through an sdio connector, ie the hp one shown here: http://en.wikipedia.org/wiki/Secure_Digital#SDIO A college asked me if I wanted one for the webcam driver work I do, but since it does not have a usb plug I'm not interested. But if anyone else is working on this and wants one, I can put you in touch. 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
Re: Device driver memory 'mmap()' function helper cleanup
Em Tue, 16 Apr 2013 20:12:32 -0700 Linus Torvalds torva...@linux-foundation.org escreveu: Guys, I just pushed out a new helper function intended for cleaning up various device driver mmap functions, because they are rather messy, and at least part of the problem was the bad impedance between what a driver author would want to have, and the VM interfaces to map a memory range into user space with mmap. Some drivers would end up doing extensive checks on the length of the mappings and the page offset within the mapping, while other drivers would end up doing no checks at all. The new helper is in commit b4cbb197c7e7 (vm: add vm_iomap_memory() helper function), but I didn't actually commit any *users* of it, because I just have this untested patch-collection for a few random drivers (picked across a few different driver subsystems, just to make it interesting). I did that largely just to check the different use cases, but I don't actually tend to *use* all that many fancy drivers, so I don't have much of a way of testing it. The media layer has a few users of [io_]remap_pfn_range() that look like they could do with some tender loving too, but they don't match this particular pattern of allow users to map a part of a fixed range of memory. In fact, the media pattern seems to be single-page mappings, which probably should use vm_insert_page() instead, but that's a whole separate thing. But I didn't check all the media cases (and there's a lot of remap_pfn_range use outside of media drivers I didn't check either), so there might be code that could use the new helper. I think that [io_]remap_pfn_range() calls are used by the oldest drivers and a few newer ones that based on some old cut-and-paste code. Let me see what drivers use it on media... $ git grep -l remap_pfn_range drivers/media/ drivers/media/pci/meye/meye.c drivers/media/pci/zoran/zoran_driver.c drivers/media/platform/omap/omap_vout.c drivers/media/platform/omap24xxcam.c drivers/media/platform/vino.c drivers/media/usb/cpia2/cpia2_core.c drivers/media/v4l2-core/videobuf-dma-contig.c Yes, meye, vino, cpia2 and zoran are very old drivers. I only have here somewhere zoran cards. I'll see if they still work, and write a patch for it. The platform drivers that use remap_pfn_range() are omap2 and vino. Vino is for SGI Indy machines. I dunno anyone with those hardware and a camera anymore. The OMAP2 were used on some Nokia phones. They used to maintain that code, but now that they moved to the dark side of the moon, they lost their interests on it. So, it may not be easily find testers for patches there. The videobuf-dma-contig code actually uses two implementations there: one using vm_insert_page() for cached memory, and another one using remap_pfn_range() for uncached memory. All places where cached memory is used got already moved to videobuf2-dma-contig. We can simply drop that unused code from it, and remap_pfn_range() by vm_iomap_memory(). I can write the patches doing it, but I don't any hardware here using videobuf-dma-contig for testing. So, I'll post it asking people to test. Anyway, I'm attaching the *untested* patch to several drivers. Guys, mind taking a look? The point here is to simplify the interface, avoiding bugs, but also: 5 files changed, 21 insertions(+), 87 deletions(-) it needs current -git for the new helper function. NOTE! The driver subsystem .mmap functions seem to almost universally do if (io_remap_pfn_range(..)) return -EAGAIN; return 0; and I didn't make the new helper function do that turn all remap_pfn_range errors into EAGAIN. My *suspicion* is that this is just really old copy-pasta and makes no sense, but maybe there is some actual reasoning behind EAGAIN vs ENOMEM, for example. EAGAIN is documented to be about file/memory locking, which means that it really doesn't make any sense, but obviously there might be some binary that actally depends on this, so I'm perfectly willing to make the helper do that odd error case, I'd just like to know (and a add a comment) WHY. My personal guess is that nobody actually cares (we return other error codes for other cases, notably EINVAL for various out-of-mapping-range issues), and the whole EAGAIN return value is just a completely historical oddity. (And yes, I know the mtdchar code is actually disabled right now. But that was a good example of a driver that had a bug in this area and that I touched myself not too long ago, and recent stable noise reminded me of it, so I did that one despite it not being active). Linus 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: [PATCH 1/1] [media] exynos4-is: Fix potential null pointer dereferencing
Hi Sachin,
On 04/16/2013 08:16 AM, Sachin Kamat wrote:
Hi Sylwester,
On 15 April 2013 20:51, Sylwester Nawrocki s.nawro...@samsung.com wrote:
- if (!fimc-drv_data || fimc-id = fimc-drv_data-num_entities ||
- fimc-id 0) {
- dev_err(dev, Invalid driver data or device id (%d/%d)\n,
- fimc-id, fimc-drv_data-num_entities);
+ if (!fimc-drv_data || fimc-id = fimc-drv_data-num_entities) {
+ dev_err(dev, Invalid driver data or device id (%d)\n,
+ fimc-id);
return -EINVAL;
Thanks for the patch. To make it more explicit I would prefer to change
id type to 'int', and to leave the check for negative value. There is
a similar issue in fimc-lite.c that could be addressed in same patch.
Could you also fix this and resend ?
Sure.
I also found a few more things to fix and sent a 5 patch fix series
including the above changes.
Thanks a lot for your review and patches. I'll apply patches 1..2/5 for
3.10-rc, and patch 3/5 for 3.11.
Regarding patch 4/5, as can be seen I didn't test the driver as a module
before pushing upstream, my bad! :( So I had a look at it and found a few
more issues. _Almost_ everything is fine now :-) after I fixed those,
I'm going to post related patch set soon. Your patch 4/5 is not applicable
any more unfortunately.
Regarding patch 5/5, I would prefer to keep that code, if you and others
don't mind. Sorry, I'm a bit tied to it ;) Seriously, I hope to have more
V4L2 controls supported for 3.11, so removing and re-adding that chunks
would be a useless churn IMHO.
Regards,
--
Sylwester Nawrocki
Samsung Poland RD Center
--
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: Patchwork and em28xx delegates
I see this https://patchwork.linuxtv.org/patch/17834/ is delegated to me. If I took ownership myself then it may have been a mistake. Either way, the patch looks good to me and makes sense, but I am not maintaining em28xx. Mauro, if you want to go ahead and merge his patch then it's fine with me. Since this was a mistake, I don't plan to push it from my own repository. Reviewed-by: Michael Krufky mkru...@linuxtv.org -- 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 1/1] [media] exynos4-is: Fix potential null pointer dereferencing
Hi Sylwester,
On 17 April 2013 16:33, Sylwester Nawrocki s.nawro...@samsung.com wrote:
Hi Sachin,
On 04/16/2013 08:16 AM, Sachin Kamat wrote:
Hi Sylwester,
On 15 April 2013 20:51, Sylwester Nawrocki s.nawro...@samsung.com wrote:
- if (!fimc-drv_data || fimc-id = fimc-drv_data-num_entities ||
- fimc-id 0) {
- dev_err(dev, Invalid driver data or device id (%d/%d)\n,
- fimc-id, fimc-drv_data-num_entities);
+ if (!fimc-drv_data || fimc-id = fimc-drv_data-num_entities) {
+ dev_err(dev, Invalid driver data or device id (%d)\n,
+ fimc-id);
return -EINVAL;
Thanks for the patch. To make it more explicit I would prefer to change
id type to 'int', and to leave the check for negative value. There is
a similar issue in fimc-lite.c that could be addressed in same patch.
Could you also fix this and resend ?
Sure.
I also found a few more things to fix and sent a 5 patch fix series
including the above changes.
Thanks a lot for your review and patches. I'll apply patches 1..2/5 for
3.10-rc, and patch 3/5 for 3.11.
OK. No problem.
Regarding patch 4/5, as can be seen I didn't test the driver as a module
before pushing upstream, my bad! :( So I had a look at it and found a few
more issues. _Almost_ everything is fine now :-) after I fixed those,
I'm going to post related patch set soon. Your patch 4/5 is not applicable
any more unfortunately.
Not a problem as long as the issue is handled or fixed :).
Regarding patch 5/5, I would prefer to keep that code, if you and others
don't mind. Sorry, I'm a bit tied to it ;) Seriously, I hope to have more
V4L2 controls supported for 3.11, so removing and re-adding that chunks
would be a useless churn IMHO.
Right. That is the reason I kept this patch at the end of the series
so that you may decide as appropriate.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT-PULL] lg2160: dubious one-bit signed bitfield
The following changes since commit 33a31edd4a4b7d26b962b32decfd8ea2377eaa0d: Revert [media] mfd: Add header files and Kbuild plumbing for SI476x MFD core (2013-04-17 06:08:00 -0300) are available in the git repository at: git://linuxtv.org/mkrufky/dvb demods for you to fetch changes up to 79c9a899d199fba3505b1d76325c97a7a00b3686: lg2160: dubious one-bit signed bitfield (2013-04-17 07:18:40 -0400) Dan Carpenter (1): lg2160: dubious one-bit signed bitfield drivers/media/dvb-frontends/lg2160.h |4 ++-- 1 file changed, 2 insertions(+), 2 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: [RFC] [media] dvb-core: check -msg_len for diseqc_send_master_cmd()
Any feedback on this?
I forgot to CC Steven Toth last time because he would know about the
cx24116 driver. I've looked at it again and it still looks like
cx24116_send_diseqc_msg() is copying garbage into the
state-dsec_cmd.args[] array.
regards,
dan carpenter
On Tue, Apr 02, 2013 at 10:51:02AM +0300, Dan Carpenter wrote:
I'd like to send this patch except that it breaks
cx24116_send_diseqc_msg(). The cx24116 driver accepts -msg_len values
up to 24 but it looks like it's just copying 16 bytes past the end of
the -msg[] array so it's already broken.
cmd-msg_len is an unsigned char. The comment next to the struct
declaration says that valid values are are 3-6. Some of the drivers
check that this is true, but most don't and it could cause memory
corruption.
Some examples of functions which don't check are:
ttusbdecfe_dvbs_diseqc_send_master_cmd()
cx24123_send_diseqc_msg()
ds3000_send_diseqc_msg()
etc.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 57601c0..3d1eee6 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2265,7 +2265,13 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
case FE_DISEQC_SEND_MASTER_CMD:
if (fe-ops.diseqc_send_master_cmd) {
- err = fe-ops.diseqc_send_master_cmd(fe, (struct
dvb_diseqc_master_cmd*) parg);
+ struct dvb_diseqc_master_cmd *cmd = parg;
+
+ if (cmd-msg_len = 3 cmd-msg_len = 6)
+ err = fe-ops.diseqc_send_master_cmd(fe, cmd);
+ else
+ err = -EINVAL;
+
fepriv-state = FESTATE_DISEQC;
fepriv-status = 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] videobuf-dma-contig: use vm_iomap_memory()
vm_iomap_memory() provides a better end user interface than
remap_pfn_range(), as it does the needed tests before doing
mmap.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/v4l2-core/videobuf-dma-contig.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index 67f572c..7e6b209 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -303,14 +303,9 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
goto error;
/* Try to remap memory */
-
size = vma-vm_end - vma-vm_start;
- size = (size mem-size) ? size : mem-size;
-
vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
- retval = remap_pfn_range(vma, vma-vm_start,
-mem-dma_handle PAGE_SHIFT,
-size, vma-vm_page_prot);
+ retval = vm_iomap_memory(vma, vma-vm_start, size);
if (retval) {
dev_err(q-dev, mmap: remap failed with error %d. ,
retval);
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] videobuf-dma-contig: remove support for cached mem
videobuf_queue_dma_contig_init_cached() is not used anywhere.
Drop support for it, cleaning up the code a little bit.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/v4l2-core/videobuf-dma-contig.c | 130 +++---
include/media/videobuf-dma-contig.h | 10 --
2 files changed, 14 insertions(+), 126 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index 3a43ba0..67f572c 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -27,7 +27,6 @@ struct videobuf_dma_contig_memory {
u32 magic;
void *vaddr;
dma_addr_t dma_handle;
- bool cached;
unsigned long size;
};
@@ -43,26 +42,8 @@ static int __videobuf_dc_alloc(struct device *dev,
unsigned long size, gfp_t flags)
{
mem-size = size;
- if (mem-cached) {
- mem-vaddr = alloc_pages_exact(mem-size, flags | GFP_DMA);
- if (mem-vaddr) {
- int err;
-
- mem-dma_handle = dma_map_single(dev, mem-vaddr,
-mem-size,
-DMA_FROM_DEVICE);
- err = dma_mapping_error(dev, mem-dma_handle);
- if (err) {
- dev_err(dev, dma_map_single failed\n);
-
- free_pages_exact(mem-vaddr, mem-size);
- mem-vaddr = NULL;
- return err;
- }
- }
- } else
- mem-vaddr = dma_alloc_coherent(dev, mem-size,
- mem-dma_handle, flags);
+ mem-vaddr = dma_alloc_coherent(dev, mem-size,
+ mem-dma_handle, flags);
if (!mem-vaddr) {
dev_err(dev, memory alloc size %ld failed\n, mem-size);
@@ -77,14 +58,7 @@ static int __videobuf_dc_alloc(struct device *dev,
static void __videobuf_dc_free(struct device *dev,
struct videobuf_dma_contig_memory *mem)
{
- if (mem-cached) {
- if (!mem-vaddr)
- return;
- dma_unmap_single(dev, mem-dma_handle, mem-size,
-DMA_FROM_DEVICE);
- free_pages_exact(mem-vaddr, mem-size);
- } else
- dma_free_coherent(dev, mem-size, mem-vaddr, mem-dma_handle);
+ dma_free_coherent(dev, mem-size, mem-vaddr, mem-dma_handle);
mem-vaddr = NULL;
}
@@ -234,7 +208,7 @@ out_up:
return ret;
}
-static struct videobuf_buffer *__videobuf_alloc_vb(size_t size, bool cached)
+static struct videobuf_buffer *__videobuf_alloc(size_t size)
{
struct videobuf_dma_contig_memory *mem;
struct videobuf_buffer *vb;
@@ -244,22 +218,11 @@ static struct videobuf_buffer *__videobuf_alloc_vb(size_t
size, bool cached)
vb-priv = ((char *)vb) + size;
mem = vb-priv;
mem-magic = MAGIC_DC_MEM;
- mem-cached = cached;
}
return vb;
}
-static struct videobuf_buffer *__videobuf_alloc_uncached(size_t size)
-{
- return __videobuf_alloc_vb(size, false);
-}
-
-static struct videobuf_buffer *__videobuf_alloc_cached(size_t size)
-{
- return __videobuf_alloc_vb(size, true);
-}
-
static void *__videobuf_to_vaddr(struct videobuf_buffer *buf)
{
struct videobuf_dma_contig_memory *mem = buf-priv;
@@ -310,19 +273,6 @@ static int __videobuf_iolock(struct videobuf_queue *q,
return 0;
}
-static int __videobuf_sync(struct videobuf_queue *q,
- struct videobuf_buffer *buf)
-{
- struct videobuf_dma_contig_memory *mem = buf-priv;
- BUG_ON(!mem);
- MAGIC_CHECK(mem-magic, MAGIC_DC_MEM);
-
- dma_sync_single_for_cpu(q-dev, mem-dma_handle, mem-size,
- DMA_FROM_DEVICE);
-
- return 0;
-}
-
static int __videobuf_mmap_mapper(struct videobuf_queue *q,
struct videobuf_buffer *buf,
struct vm_area_struct *vma)
@@ -331,8 +281,6 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
struct videobuf_mapping *map;
int retval;
unsigned long size;
- unsigned long pos, start = vma-vm_start;
- struct page *page;
dev_dbg(q-dev, %s\n, __func__);
@@ -359,43 +307,16 @@ static int __videobuf_mmap_mapper(struct videobuf_queue
*q,
size = vma-vm_end - vma-vm_start;
size = (size mem-size) ? size : mem-size;
- if (!mem-cached) {
- vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
- retval = remap_pfn_range(vma, vma-vm_start,
-
[PATCH] soc_camera: Add V4L2_MBUS_FMT_YUYV10_2X10 format
The V4L2_MBUS_FMT_YUYV10_2X10 format has already been added to mediabus, so
this patch just adds SoC camera support.
Signed-off-by: Phil Edworthy phil.edwor...@renesas.com
---
drivers/media/platform/soc_camera/soc_mediabus.c | 15 +++
include/media/soc_mediabus.h |3 +++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_mediabus.c
b/drivers/media/platform/soc_camera/soc_mediabus.c
index 7569e77..be47d41 100644
--- a/drivers/media/platform/soc_camera/soc_mediabus.c
+++ b/drivers/media/platform/soc_camera/soc_mediabus.c
@@ -57,6 +57,15 @@ static const struct soc_mbus_lookup mbus_fmt[] = {
.layout = SOC_MBUS_LAYOUT_PACKED,
},
}, {
+ .code = V4L2_MBUS_FMT_YUYV10_2X10,
+ .fmt = {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .name = YUYV,
+ .bits_per_sample= 10,
+ .packing= SOC_MBUS_PACKING_2X10_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+}, {
.code = V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
.fmt = {
.fourcc = V4L2_PIX_FMT_RGB555,
@@ -403,6 +412,10 @@ int soc_mbus_samples_per_pixel(const struct
soc_mbus_pixelfmt *mf,
*numerator = 2;
*denominator = 1;
return 0;
+ case SOC_MBUS_PACKING_2X10_PADHI:
+ *numerator = 3;
+ *denominator = 1;
+ return 0;
case SOC_MBUS_PACKING_1_5X8:
*numerator = 3;
*denominator = 2;
@@ -428,6 +441,8 @@ s32 soc_mbus_bytes_per_line(u32 width, const struct
soc_mbus_pixelfmt *mf)
case SOC_MBUS_PACKING_2X8_PADLO:
case SOC_MBUS_PACKING_EXTEND16:
return width * 2;
+ case SOC_MBUS_PACKING_2X10_PADHI:
+ return width * 3;
case SOC_MBUS_PACKING_1_5X8:
return width * 3 / 2;
case SOC_MBUS_PACKING_VARIABLE:
diff --git a/include/media/soc_mediabus.h b/include/media/soc_mediabus.h
index d33f6d0..b131a47 100644
--- a/include/media/soc_mediabus.h
+++ b/include/media/soc_mediabus.h
@@ -21,6 +21,8 @@
* @SOC_MBUS_PACKING_2X8_PADHI:16 bits transferred in 2 8-bit samples,
in the
* possibly incomplete byte high bits are padding
* @SOC_MBUS_PACKING_2X8_PADLO:as above, but low bits are padding
+ * @SOC_MBUS_PACKING_2X10_PADHI:20 bits transferred in 2 10-bit samples. The
+ * high bits are padding
* @SOC_MBUS_PACKING_EXTEND16: sample width (e.g., 10 bits) has to be extended
* to 16 bits
* @SOC_MBUS_PACKING_VARIABLE: compressed formats with variable packing
@@ -33,6 +35,7 @@ enum soc_mbus_packing {
SOC_MBUS_PACKING_NONE,
SOC_MBUS_PACKING_2X8_PADHI,
SOC_MBUS_PACKING_2X8_PADLO,
+ SOC_MBUS_PACKING_2X10_PADHI,
SOC_MBUS_PACKING_EXTEND16,
SOC_MBUS_PACKING_VARIABLE,
SOC_MBUS_PACKING_1_5X8,
--
1.7.5.4
--
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 1/2] [media] videobuf-dma-contig: remove support for cached mem
On Wed 17 April 2013 14:22:15 Mauro Carvalho Chehab wrote:
videobuf_queue_dma_contig_init_cached() is not used anywhere.
Drop support for it, cleaning up the code a little bit.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Nice!
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf-dma-contig.c | 130
+++---
include/media/videobuf-dma-contig.h | 10 --
2 files changed, 14 insertions(+), 126 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index 3a43ba0..67f572c 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -27,7 +27,6 @@ struct videobuf_dma_contig_memory {
u32 magic;
void *vaddr;
dma_addr_t dma_handle;
- bool cached;
unsigned long size;
};
@@ -43,26 +42,8 @@ static int __videobuf_dc_alloc(struct device *dev,
unsigned long size, gfp_t flags)
{
mem-size = size;
- if (mem-cached) {
- mem-vaddr = alloc_pages_exact(mem-size, flags | GFP_DMA);
- if (mem-vaddr) {
- int err;
-
- mem-dma_handle = dma_map_single(dev, mem-vaddr,
- mem-size,
- DMA_FROM_DEVICE);
- err = dma_mapping_error(dev, mem-dma_handle);
- if (err) {
- dev_err(dev, dma_map_single failed\n);
-
- free_pages_exact(mem-vaddr, mem-size);
- mem-vaddr = NULL;
- return err;
- }
- }
- } else
- mem-vaddr = dma_alloc_coherent(dev, mem-size,
- mem-dma_handle, flags);
+ mem-vaddr = dma_alloc_coherent(dev, mem-size,
+ mem-dma_handle, flags);
if (!mem-vaddr) {
dev_err(dev, memory alloc size %ld failed\n, mem-size);
@@ -77,14 +58,7 @@ static int __videobuf_dc_alloc(struct device *dev,
static void __videobuf_dc_free(struct device *dev,
struct videobuf_dma_contig_memory *mem)
{
- if (mem-cached) {
- if (!mem-vaddr)
- return;
- dma_unmap_single(dev, mem-dma_handle, mem-size,
- DMA_FROM_DEVICE);
- free_pages_exact(mem-vaddr, mem-size);
- } else
- dma_free_coherent(dev, mem-size, mem-vaddr, mem-dma_handle);
+ dma_free_coherent(dev, mem-size, mem-vaddr, mem-dma_handle);
mem-vaddr = NULL;
}
@@ -234,7 +208,7 @@ out_up:
return ret;
}
-static struct videobuf_buffer *__videobuf_alloc_vb(size_t size, bool cached)
+static struct videobuf_buffer *__videobuf_alloc(size_t size)
{
struct videobuf_dma_contig_memory *mem;
struct videobuf_buffer *vb;
@@ -244,22 +218,11 @@ static struct videobuf_buffer
*__videobuf_alloc_vb(size_t size, bool cached)
vb-priv = ((char *)vb) + size;
mem = vb-priv;
mem-magic = MAGIC_DC_MEM;
- mem-cached = cached;
}
return vb;
}
-static struct videobuf_buffer *__videobuf_alloc_uncached(size_t size)
-{
- return __videobuf_alloc_vb(size, false);
-}
-
-static struct videobuf_buffer *__videobuf_alloc_cached(size_t size)
-{
- return __videobuf_alloc_vb(size, true);
-}
-
static void *__videobuf_to_vaddr(struct videobuf_buffer *buf)
{
struct videobuf_dma_contig_memory *mem = buf-priv;
@@ -310,19 +273,6 @@ static int __videobuf_iolock(struct videobuf_queue *q,
return 0;
}
-static int __videobuf_sync(struct videobuf_queue *q,
-struct videobuf_buffer *buf)
-{
- struct videobuf_dma_contig_memory *mem = buf-priv;
- BUG_ON(!mem);
- MAGIC_CHECK(mem-magic, MAGIC_DC_MEM);
-
- dma_sync_single_for_cpu(q-dev, mem-dma_handle, mem-size,
- DMA_FROM_DEVICE);
-
- return 0;
-}
-
static int __videobuf_mmap_mapper(struct videobuf_queue *q,
struct videobuf_buffer *buf,
struct vm_area_struct *vma)
@@ -331,8 +281,6 @@ static int __videobuf_mmap_mapper(struct videobuf_queue
*q,
struct videobuf_mapping *map;
int retval;
unsigned long size;
- unsigned long pos, start = vma-vm_start;
- struct page *page;
dev_dbg(q-dev, %s\n, __func__);
@@ -359,43 +307,16 @@ static int __videobuf_mmap_mapper(struct videobuf_queue
*q,
size = vma-vm_end - vma-vm_start;
size = (size mem-size) ? size : mem-size;
- if (!mem-cached) {
- vma-vm_page_prot =
Re: [PATCH 2/2] [media] videobuf-dma-contig: use vm_iomap_memory()
Em Wed, 17 Apr 2013 09:22:16 -0300 Mauro Carvalho Chehab mche...@redhat.com escreveu: vm_iomap_memory() provides a better end user interface than remap_pfn_range(), as it does the needed tests before doing mmap. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/v4l2-core/videobuf-dma-contig.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c b/drivers/media/v4l2-core/videobuf-dma-contig.c index 67f572c..7e6b209 100644 --- a/drivers/media/v4l2-core/videobuf-dma-contig.c +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c @@ -303,14 +303,9 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q, goto error; /* Try to remap memory */ - size = vma-vm_end - vma-vm_start; - size = (size mem-size) ? size : mem-size; - vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); - retval = remap_pfn_range(vma, vma-vm_start, - mem-dma_handle PAGE_SHIFT, - size, vma-vm_page_prot); + retval = vm_iomap_memory(vma, vma-vm_start, size); Just to be sure, that changing from remap_pfn_range() to io_remap_pfn_range() won't cause any side-effects, I double-checked that, for all drivers using this code, that remap_pfn_range is equal to io_remap_pfn_range. The Timberdale driver was a little trickier to check, as VIDEO_TIMBERDALE doesn't depend on any architecture. However, this driver was submitted and was known to work only on the Intel in-Vehicle Infotainment reference board russelville. According with http://wiki.meego.com/In-vehicle, the architecture for it is x86 (Intel Atom Z5xx). In summary, those are the archs where this core driver is used, with the corresponding drivers that make such usage: powerpc: drivers/media/platform/fsl-viu.c arm: drivers/media/platform/omap/omap_vout.c drivers/media/platform/omap/omap_vout_vrfb.c drivers/media/platform/soc_camera/mx1_camera.c drivers/media/platform/soc_camera/omap1_camera.c sh: drivers/media/platform/sh_vou.c x86: drivers/media/platform/timblogiw.c -- 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
Re: [PATCH RFC] s5k5baf: add camera sensor driver
Hi Andrzej,
On 04/16/2013 03:38 PM, Andrzej Hajda wrote:
Driver for Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor
with embedded SoC ISP.
The driver exposes the sensor as two V4L2 subdevices:
- S5K5BAF-CIS - pure CMOS Image Sensor, fixed 1600x1200 format,
no controls.
- S5K5BAF-ISP - Image Signal Processor, formats up to 1600x1200,
pre/post ISP cropping, downscaling via selection API, controls.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
It's worth to note that this driver currently doesn't use the asynchronous
sub-device probing API [1] but the intention is to switch to it once it's
settled.
[1] http://www.spinics.net/lists/linux-sh/msg18565.html
A few more comments below...
.../devicetree/bindings/media/samsung-s5k5baf.txt | 50 +
MAINTAINERS|8 +
drivers/media/i2c/Kconfig |7 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/s5k5baf.c| 1962
include/media/s5k5baf.h| 48 +
6 files changed, 2076 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
create mode 100644 drivers/media/i2c/s5k5baf.c
create mode 100644 include/media/s5k5baf.h
diff --git a/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
new file mode 100644
index 000..1099c1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
@@ -0,0 +1,50 @@
+Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor with embedded SoC ISP
+-
+
+Required properties:
+
+- compatible : samsung,s5k5baf;
+- reg : i2c slave address of the sensor;
+- vdda-supply : analog power supply 2.8V (2.6V to 3.0V);
+- vdd_reg-supply : regulator input power 1.8V (1.7V to 1.9V)
s/power/power supply ?
Underscores should be avoided in the regulator supply names AFAIK, so
s/vdd_reg/vddreg
+or 2.8V (2.6V to 3.0);
+- vddio-supply : I/O supply 1.8V (1.65V to 1.95V)
s/supply/power supply ?
+or 2.8V (2.5V to 3.1V);
+- gpios: standby and reset gpios;
You are not clear about the order, how about
- gpios : GPIOs connected to STDBYN and RSTN pins, in order: STBYN, RSTN;
?
+- clock-frequency : master clock frequency in Hz;
+
+Optional properties:
+
+- samsung,hflip: horizontal image flip
+- samsung,vflip: vertical image flip
Optional clock properties are missing:
clocks : contains the sensor's master clock specifier;
clock-names : contains mclk entry;
MCLK happens to be the clock input pin name in the datasheet.
+The device node should contain one 'port' child node with one child
'endpoint'
+node, according to the bindings defined in Documentation/devicetree/bindings/
+media/video-interfaces.txt. The following are properties specific to those
nodes.
+
+endpoint node
+-
+
+- data-lanes : (optional) an array specifying active physical MIPI-CSI2
+ data output lanes and their mapping to logical lanes; the
+ array's content is unused, only its length is meaningful;
+
+Example:
+
+s5k5bafx@2d {
+ compatible = samsung,s5k5baf;
+ reg = 0x2d;
+ vdda-supply = cam_io_en_reg;
+ vdd_reg-supply = vt_core_15v_reg;
+ vddio-supply = vtcam_reg;
+ gpios = gpl2 0 1,
+ gpl2 1 1;
+ clock-frequency = 2400;
+
+ port {
+ s5k5bafx_ep: endpoint {
+ remote-endpoint = csis1_ep;
+ data-lanes = 1;
+ };
+ };
+};
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9e7ce8b..e487f7d 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -553,6 +553,13 @@ config VIDEO_S5K4ECGX
This is a V4L2 sensor-level driver for Samsung S5K4ECGX 5M
camera sensor with an embedded SoC image signal processor.
+config VIDEO_S5K5BAF
+ tristate Samsung S5K5BAF sensor support
+ depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API
+ ---help---
+ This is a V4L2 sensor-level driver for Samsung S5K5BAF 2M
+ camera sensor with an embedded SoC image signal processor.
+
source drivers/media/i2c/smiapp/Kconfig
config VIDEO_S5C73M3
diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
new file mode 100644
index 000..0bae2d3
--- /dev/null
+++ b/drivers/media/i2c/s5k5baf.c
@@ -0,0 +1,1962 @@
+/*
+ * Driver for Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor
+ * with embedded SoC ISP.
+ *
+ * Copyright (C) 2013, Samsung Electronics Co., Ltd.
+ * Andrzej
Re: [GIT PULL FOR v3.10] Camera sensors patches
On Tue, Apr 16, 2013 at 08:04:52PM +0200, Sylwester Nawrocki wrote: It's probably more clean to provide a dummy clock/regulator in a host driver (platform) than to add something in a sub-device drivers that would resolve which resources should be requested and which not. Yes, that's the general theory for regulators at least - it allows the device driver to just trundle along and not worry about how the board is hooked up. The other issue it resolves that you didn't mention is that it avoids just ignoring errors which isn't terribly clever. signature.asc Description: Digital signature
Re: [PATCH] DT: export of_get_next_parent() for use by modules: fix modular V4L2
Hi all On Tue, 2 Apr 2013, Guennadi Liakhovetski wrote: On Tue, 2 Apr 2013, Arnd Bergmann wrote: On Tuesday 02 April 2013, Guennadi Liakhovetski wrote: Currently modular V4L2 build with enabled OF is broken dur to the of_get_next_parent() function being unavailable to modules. Export it to fix the build. Cc: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Looks good to me, but shouldn't this be EXPORT_SYMBOL_GPL? grep EXPORT_SYMBOL drivers/of/base.c doesn't give a certain answer, but it seems to fit other of_get_* functions pretty well: Ping, could this patch be pushed to -next asap, please? Without it the current V4L2 -next doesn't compile. Also, I think, ro avoid breaking the mainline, we should try to have this patch pulled in before the media tree, could that be done? Thanks Guennadi EXPORT_SYMBOL(of_get_parent); +EXPORT_SYMBOL(of_get_next_parent); EXPORT_SYMBOL(of_get_next_child); EXPORT_SYMBOL(of_get_next_available_child); EXPORT_SYMBOL(of_get_child_by_name); --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: mt9v034 driver
Hi Igor (forwarding to the real media Mailing List) On Wed, 17 Apr 2013, Igor Kugasyan wrote: Dear Mr. Guennadi, Please tell me can I use the soc_camera_ (soc_camera.h, soc_camera.c) interface for a mt9v034 driver as a mt9v022 driver or not? I don't know anything about mt9v034. It might or might not be compatible with one of supported cameras. If it isn't, a new driver has to be developed. I've read your Video4Linux soc-camera subsystem document and not found a mt9v034 among client drivers. I have the Leopard Board 368 (LI-TB02) with the WVGA camera No, you cannot use soc-camera with Leopard Board. Its camera interface might be supported by some other driver, but I'm not sure about that. LI-VM34LP but I haven't a mt9v034 driver for my camera for the linux-2.6.32 kernel with RidgeRun Don't think there's anything that can be done with any kernel apart from the current -next, i.e. the forthcoming 3.10. 2011Q2 SDK for LeopardBoardDM365 and dvsdk_dm365-evm_4_02_00_06. I haven't sufficient experience for comprehension but I learn... The only possibility I see is to use a current kernel, adapt an existing or write a new camera sensor driver for mt9v034 and use it with the appropriate SoC camera interface driver. Thanks Guennadi Please, please, help me to solve this problem. Thanks in advance. Best regards, Sincerely yours Igor Kugasyan CONECS SSRE Lviv 79060 Naukova 7 Ukraine T +38 032 2952597 F +38 032 2954879 E d...@conecs.lviv.ua --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.10] Camera sensors patches
Em Wed, 17 Apr 2013 14:55:03 +0100 Mark Brown broo...@kernel.org escreveu: On Tue, Apr 16, 2013 at 08:04:52PM +0200, Sylwester Nawrocki wrote: It's probably more clean to provide a dummy clock/regulator in a host driver (platform) than to add something in a sub-device drivers that would resolve which resources should be requested and which not. Yes, that's the general theory for regulators at least - it allows the device driver to just trundle along and not worry about how the board is hooked up. The other issue it resolves that you didn't mention is that it avoids just ignoring errors which isn't terribly clever. I agree. Adding dummy clock/regulator at the host platform driver makes sense, as the platform driver knows how the board is hooked up; keeping it at the I2C driver doesn't make sense, so the code needs to be moved away from it. Laurent, Could you please work on a patch moving that code to the host platform driver? Thanks! 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
Compilation breakage on drivers/media due to OF patches - was: Re: [PATCH] DT: export of_get_next_parent() for use by modules: fix modular V4L2
Hi Grant/Rob, Our tree is currently _broken_ with OT, because of the lack of exporting of_get_next_parent. The developer that submitted the patches that added V4L2 OF support forgot to test to compilation with MODULES support enabled. So, we're now having: ERROR: of_get_next_parent [drivers/media/v4l2-core/videodev.ko] undefined! if compiled with OF enabled and media as module. As those patches were applied at my master branch and there are lots of other patches on the top of the patches that added V4L2 OF support, I prefer to avoid reverting those patches. On the other hand, I can't send the patches upstream next week (assuming that -rc7 is the final one), without having this patch applying before the media tree. So, please help me solving this issue as soon as possible. Thank you! Mauro Em Wed, 17 Apr 2013 16:07:49 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: Hi all On Tue, 2 Apr 2013, Guennadi Liakhovetski wrote: On Tue, 2 Apr 2013, Arnd Bergmann wrote: On Tuesday 02 April 2013, Guennadi Liakhovetski wrote: Currently modular V4L2 build with enabled OF is broken dur to the of_get_next_parent() function being unavailable to modules. Export it to fix the build. Cc: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Looks good to me, but shouldn't this be EXPORT_SYMBOL_GPL? grep EXPORT_SYMBOL drivers/of/base.c doesn't give a certain answer, but it seems to fit other of_get_* functions pretty well: Ping, could this patch be pushed to -next asap, please? Without it the current V4L2 -next doesn't compile. Also, I think, ro avoid breaking the mainline, we should try to have this patch pulled in before the media tree, could that be done? Thanks Guennadi EXPORT_SYMBOL(of_get_parent); +EXPORT_SYMBOL(of_get_next_parent); EXPORT_SYMBOL(of_get_next_child); EXPORT_SYMBOL(of_get_next_available_child); EXPORT_SYMBOL(of_get_child_by_name); --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 -- 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
Re: Compilation breakage on drivers/media due to OF patches - was: Re: [PATCH] DT: export of_get_next_parent() for use by modules: fix modular V4L2
On Wed, 17 Apr 2013 11:53:57 -0300, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi Grant/Rob, Our tree is currently _broken_ with OT, because of the lack of exporting of_get_next_parent. The developer that submitted the patches that added V4L2 OF support forgot to test to compilation with MODULES support enabled. So, we're now having: ERROR: of_get_next_parent [drivers/media/v4l2-core/videodev.ko] undefined! if compiled with OF enabled and media as module. As those patches were applied at my master branch and there are lots of other patches on the top of the patches that added V4L2 OF support, I prefer to avoid reverting those patches. On the other hand, I can't send the patches upstream next week (assuming that -rc7 is the final one), without having this patch applying before the media tree. The fix needs to be applied to your tree then. Go ahead and apply it with my ack: Acked-by: Grant Likely grant.lik...@linaro.org It is no good to apply it to the devicetree -next branch because that will still leave your branch broken, even if device tree gets merged first. g. -- 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 00/10] Versatile Express CLCD DVI output support
Hello All, This series implements support for the Versatile Express video output pipeline, which is not the simplest one available... It is meant as a RFC only and I'm hoping to attract all possible feedback (*including* naming ;-). The VE's MultiMedia Bus [1] comprises three video signal sources (motherboard's CLCD cell and a implementation-specific driver on each of the daugtherboards) and a FPGA multiplexer routing data from one of the sources to DVI/HDMI formatter chip (Sii9022). +-+ | DB1 |--+ DVI connector +-+ | +--+ +--+ +--| | |oo| +-+ | mux |+-+|oo| | DB2 |-| |--| sii9022 |--|oo| +-+ | FPGA |+-+|oo| +--| | |oo| +-+ | +--+ +--+ | MB |--+ +-+ The series is based on Laurent Pinchart's Common Display Framework patch (not in mainline yet, v2 discussed here: [2]) and extends it by adding DT bindings and basic support for TFT panels. The CLCD driver has been adapted to work with the framework and the Device Tree information. Also a set of drivers for the VE-specific components is included (note that the sii9022 is now driven via the moterboard firmware; this is intended to be replaced by a proper I2C driver for the chip). It is worth mentioning that the CDF caters for both fbdev and DRM so the solution should be suitable for all potential DRM-driven display controllers. [1] http://infocenter.arm.com/help/topic/com.arm.doc.dui0447h/CHDEHEAA.html#CACGIGGC [2] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/57298 Laurent Pinchart (1): video: Add generic display entity core Pawel Moll (9): video: display: Update the display with the video mode data video: display: Add Device Tree bindings video: display: Add generic TFT display type fbmon: Add extra video helper video: ARM CLCD: Add DT CDF support mfd: vexpress: Allow external drivers to parse site ids video: Versatile Express MUXFPGA driver video: Versatile Express DVI mode driver ARM: vexpress: Add CLCD Device Tree properties .../testing/sysfs-driver-video-vexpress-muxfpga|5 + .../devicetree/bindings/video/arm,pl11x.txt| 35 ++ .../devicetree/bindings/video/display-bindings.txt | 75 arch/arm/boot/dts/vexpress-v2m-rs1.dtsi| 17 +- arch/arm/boot/dts/vexpress-v2m.dtsi| 17 +- arch/arm/boot/dts/vexpress-v2p-ca9.dts |5 + drivers/mfd/vexpress-sysreg.c |5 + drivers/video/Kconfig |2 + drivers/video/Makefile |5 + drivers/video/amba-clcd.c | 244 +++ drivers/video/display/Kconfig |4 + drivers/video/display/Makefile |1 + drivers/video/display/display-core.c | 447 drivers/video/fbmon.c | 29 ++ drivers/video/vexpress-dvimode.c | 158 +++ drivers/video/vexpress-muxfpga.c | 228 ++ include/linux/amba/clcd.h |2 + include/linux/fb.h |3 + include/linux/vexpress.h |2 + include/video/display.h| 172 20 files changed, 1448 insertions(+), 8 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-driver-video-vexpress-muxfpga create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt create mode 100644 Documentation/devicetree/bindings/video/display-bindings.txt create mode 100644 drivers/video/display/Kconfig create mode 100644 drivers/video/display/Makefile create mode 100644 drivers/video/display/display-core.c create mode 100644 drivers/video/vexpress-dvimode.c create mode 100644 drivers/video/vexpress-muxfpga.c create mode 100644 include/video/display.h -- 1.7.10.4 -- 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 01/10] video: Add generic display entity core
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/Kconfig|1 +
drivers/video/Makefile |1 +
drivers/video/display/Kconfig|4 +
drivers/video/display/Makefile |1 +
drivers/video/display/display-core.c | 362 ++
include/video/display.h | 150 ++
6 files changed, 519 insertions(+)
create mode 100644 drivers/video/display/Kconfig
create mode 100644 drivers/video/display/Makefile
create mode 100644 drivers/video/display/display-core.c
create mode 100644 include/video/display.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c1546f..281e548 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2456,6 +2456,7 @@ source drivers/video/omap2/Kconfig
source drivers/video/exynos/Kconfig
source drivers/video/mmp/Kconfig
source drivers/video/backlight/Kconfig
+source drivers/video/display/Kconfig
if VT
source drivers/video/console/Kconfig
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9df3873..b989e8e 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -15,6 +15,7 @@ fb-objs := $(fb-y)
obj-$(CONFIG_VT) += console/
obj-$(CONFIG_LOGO) += logo/
obj-y+= backlight/
+obj-y+= display/
obj-$(CONFIG_EXYNOS_VIDEO) += exynos/
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
new file mode 100644
index 000..1d533e7
--- /dev/null
+++ b/drivers/video/display/Kconfig
@@ -0,0 +1,4 @@
+menuconfig DISPLAY_CORE
+ tristate Display Core
+ ---help---
+ Support common display framework for graphics devices.
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
new file mode 100644
index 000..bd93496
--- /dev/null
+++ b/drivers/video/display/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DISPLAY_CORE) += display-core.o
diff --git a/drivers/video/display/display-core.c
b/drivers/video/display/display-core.c
new file mode 100644
index 000..d2daa15
--- /dev/null
+++ b/drivers/video/display/display-core.c
@@ -0,0 +1,362 @@
+/*
+ * Display Core
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/export.h
+#include linux/kernel.h
+#include linux/list.h
+#include linux/module.h
+#include linux/mutex.h
+
+#include video/display.h
+#include video/videomode.h
+
+static LIST_HEAD(display_entity_list);
+static LIST_HEAD(display_entity_notifiers);
+static DEFINE_MUTEX(display_entity_mutex);
+
+/*
-
+ * Control operations
+ */
+
+/**
+ * display_entity_set_state - Set the display entity operation state
+ * @entity: The display entity
+ * @state: Display entity operation state
+ *
+ * See enum display_entity_state for information regarding the entity states.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_set_state(struct display_entity *entity,
+enum display_entity_state state)
+{
+ int ret;
+
+ if (entity-state == state)
+ return 0;
+
+ if (!entity-ops.ctrl || !entity-ops.ctrl-set_state)
+ return 0;
+
+ ret = entity-ops.ctrl-set_state(entity, state);
+ if (ret 0)
+ return ret;
+
+ entity-state = state;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(display_entity_set_state);
+
+/**
+ * display_entity_update - Update the display
+ * @entity: The display entity
+ *
+ * Make the display entity ready to receive pixel data and start frame
transfer.
+ * This operation can only be called if the display entity is in STANDBY or ON
+ * state.
+ *
+ * The display entity will call the upstream entity in the video chain to start
+ * the video stream.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_update(struct display_entity *entity)
+{
+ if (!entity-ops.ctrl || !entity-ops.ctrl-update)
+ return 0;
+
+ return entity-ops.ctrl-update(entity);
+}
+EXPORT_SYMBOL_GPL(display_entity_update);
+
+/**
+ * display_entity_get_modes - Get video modes supported by the display entity
+ * @entity The display entity
+ * @modes: Pointer to an array of modes
+ *
+ * Fill the modes argument with a pointer to an array of video modes. The array
+ * is owned by the display entity.
+ *
+ * Return the number of supported modes on success (including 0 if no mode is
+ * supported) or a negative error code otherwise.
+ */
+int
[RFC 03/10] video: display: Add Device Tree bindings
Modelled after the common clock solution, the bindings
are based on the idea of display entity providers and
consumers.
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
.../devicetree/bindings/video/display-bindings.txt | 75 +
drivers/video/display/display-core.c | 84
include/video/display.h| 11 +++
3 files changed, 170 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/display-bindings.txt
diff --git a/Documentation/devicetree/bindings/video/display-bindings.txt
b/Documentation/devicetree/bindings/video/display-bindings.txt
new file mode 100644
index 000..6d8b888
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-bindings.txt
@@ -0,0 +1,75 @@
+[this is an RFC]
+
+Common Display Framework define a display entity (eg. LCD panel),
+being a sink for video data generated by a video signal generator
+(eg. LCD controller/driver).
+
+This set of bindings allow to represent connections between them
+in the Device Tree.
+
+Devices nodes representing display sinks are called display
+providers and nodes representing display sources are called
+display consumers.
+
+Notice that in both cases a device represented by a node can
+provide or consume more than one display entity. For example
+a LCD controller can be able to driver more than one LCD
+panel at the same time, while a panel (or a special signal
+multiplexer) may have more than one input (sink) and switch
+between them.
+
+== Display provider ==
+
+Required properties:
+
+* #clock-cells:Number of cells in the display specifier. Typically
+ 0 for nodes providing single display entity and 1
+ for nodes providing multiple displays.
+
+Example:
+ dvi-output: dvi-output@0 {
+ #display-cells = 0;
+ };
+
+== Display consumer ==
+
+Required properties:
+
+* display: List of phandle and clock specifier pairs, one pair
+ for each display (sink). Note: if the display provider
+ specifies '0' for #display-cells, then only the phandle
+ portion of the pair will appear.
+
+Example:
+
+ display-driver {
+ display = dvi-output;
+ };
+
+== Larger example ==
+
+ clcd@1002 {
+ compatible = arm,pl111, arm,primecell;
+ reg = 0x1002 0x1000;
+ interrupts = 0 44 4;
+ clocks = oscclk1, oscclk2;
+ clock-names = clcdclk, apb_pclk;
+ label = V2P-CA9 CLCD;
+ display = v2m_muxfpga 0xf;
+ max-hactive = 1024;
+ max-vactive = 768;
+ max-bpp = 16;
+ };
+
+ v2m_muxfpga: muxfpga@0 {
+ compatible = arm,vexpress-muxfpga;
+ arm,vexpress-sysreg,func = 7 0;
+ #display-cells = 1;
+ display = v2m_dvimode;
+ };
+
+ v2m_dvimode: dvimode@0 {
+ compatible = arm,vexpress-dvimode;
+ arm,vexpress-sysreg,func = 11 0;
+ #display-cells = 0;
+ };
diff --git a/drivers/video/display/display-core.c
b/drivers/video/display/display-core.c
index 4b8e45a..9827a5d 100644
--- a/drivers/video/display/display-core.c
+++ b/drivers/video/display/display-core.c
@@ -15,6 +15,7 @@
#include linux/list.h
#include linux/module.h
#include linux/mutex.h
+#include linux/slab.h
#include video/display.h
#include video/videomode.h
@@ -230,6 +231,89 @@ void display_entity_put(struct display_entity *entity)
}
EXPORT_SYMBOL_GPL(display_entity_put);
+#if defined(CONFIG_OF)
+struct of_display_entity_provider {
+ struct list_head list;
+ struct device_node *node;
+ struct display_entity *(*get)(struct of_phandle_args *spec, void *data);
+ void *data;
+};
+
+static LIST_HEAD(of_display_entity_providers);
+static DEFINE_MUTEX(of_display_entity_providers_lock);
+
+int of_display_entity_add_provider(struct device_node *node,
+ struct display_entity *(*get)(struct of_phandle_args *spec,
+ void *data), void *data)
+{
+ struct of_display_entity_provider *provider =
+ kzalloc(sizeof(*provider), GFP_KERNEL);
+
+ if (!provider)
+ return -ENOMEM;
+
+ provider-node = of_node_get(node);
+ provider-get = get;
+ provider-data = data;
+
+ mutex_lock(of_display_entity_providers_lock);
+ list_add(provider-list,
[RFC 05/10] fbmon: Add extra video helper
This function converts the fb_var_screeninfo to the videomode
structure, to be used in fbdev drivers working with the
Common Display Framework.
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
drivers/video/fbmon.c | 29 +
include/linux/fb.h|3 +++
2 files changed, 32 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 7f67099..f0ff2bf 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1424,6 +1424,35 @@ int fb_videomode_from_videomode(const struct videomode
*vm,
return 0;
}
EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+
+void videomode_from_fb_var_screeninfo(const struct fb_var_screeninfo *var,
+ struct videomode *vm)
+{
+ vm-pixelclock = PICOS2KHZ(var-pixclock) * 1000;
+
+ vm-hactive = var-xres;
+ vm-hfront_porch = var-right_margin;
+ vm-hback_porch = var-left_margin;
+ vm-hsync_len = var-hsync_len;
+
+ vm-vactive = var-yres;
+ vm-vfront_porch = var-lower_margin;
+ vm-vback_porch = var-upper_margin;
+ vm-vsync_len = var-vsync_len;
+
+ vm-dmt_flags = 0;
+ if (var-sync FB_SYNC_HOR_HIGH_ACT)
+ vm-dmt_flags |= VESA_DMT_HSYNC_HIGH;
+ if (var-sync FB_SYNC_VERT_HIGH_ACT)
+ vm-dmt_flags |= VESA_DMT_VSYNC_HIGH;
+
+ vm-data_flags = 0;
+ if (var-vmode FB_VMODE_INTERLACED)
+ vm-data_flags |= DISPLAY_FLAGS_INTERLACED;
+ if (var-vmode FB_VMODE_DOUBLE)
+ vm-data_flags |= DISPLAY_FLAGS_DOUBLESCAN;
+}
+EXPORT_SYMBOL_GPL(videomode_from_fb_var_screeninfo);
#endif
#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 58b9860..aae2ed3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -721,6 +721,9 @@ extern int of_get_fb_videomode(struct device_node *np,
int index);
extern int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode);
+extern void videomode_from_fb_var_screeninfo(
+ const struct fb_var_screeninfo *var,
+ struct videomode *vm);
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 34
--
1.7.10.4
--
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 02/10] video: display: Update the display with the video mode data
The display entity (sink) may need to know about the mode being
changed, eg. to update timings.
Alternatively there could be a separate set_mode() operation...
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
drivers/video/display/display-core.c |5 +++--
include/video/display.h |6 --
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/video/display/display-core.c
b/drivers/video/display/display-core.c
index d2daa15..4b8e45a 100644
--- a/drivers/video/display/display-core.c
+++ b/drivers/video/display/display-core.c
@@ -69,12 +69,13 @@ EXPORT_SYMBOL_GPL(display_entity_set_state);
*
* Return 0 on success or a negative error code otherwise.
*/
-int display_entity_update(struct display_entity *entity)
+int display_entity_update(struct display_entity *entity,
+const struct videomode *mode)
{
if (!entity-ops.ctrl || !entity-ops.ctrl-update)
return 0;
- return entity-ops.ctrl-update(entity);
+ return entity-ops.ctrl-update(entity, mode);
}
EXPORT_SYMBOL_GPL(display_entity_update);
diff --git a/include/video/display.h b/include/video/display.h
index 90d18ca..64f84d5 100644
--- a/include/video/display.h
+++ b/include/video/display.h
@@ -77,7 +77,8 @@ struct display_entity_interface_params {
struct display_entity_control_ops {
int (*set_state)(struct display_entity *ent,
enum display_entity_state state);
- int (*update)(struct display_entity *ent);
+ int (*update)(struct display_entity *ent,
+const struct videomode *mode);
int (*get_modes)(struct display_entity *ent,
const struct videomode **modes);
int (*get_params)(struct display_entity *ent,
@@ -111,7 +112,8 @@ struct display_entity {
int display_entity_set_state(struct display_entity *entity,
enum display_entity_state state);
-int display_entity_update(struct display_entity *entity);
+int display_entity_update(struct display_entity *entity,
+const struct videomode *mode);
int display_entity_get_modes(struct display_entity *entity,
const struct videomode **modes);
int display_entity_get_params(struct display_entity *entity,
--
1.7.10.4
--
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 10/10] ARM: vexpress: Add CLCD Device Tree properties
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 17 +
arch/arm/boot/dts/vexpress-v2m.dtsi | 17 +
arch/arm/boot/dts/vexpress-v2p-ca9.dts |5 +
3 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index ac870fb..aac9459 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -41,7 +41,7 @@
bank-width = 4;
};
- vram@2, {
+ v2m_vram: vram@2, {
compatible = arm,vexpress-vram;
reg = 2 0x 0x0080;
};
@@ -233,6 +233,12 @@
interrupts = 14;
clocks = v2m_oscclk1, smbclk;
clock-names = clcdclk, apb_pclk;
+ label = IOFPGA CLCD;
+ video-ram = v2m_vram;
+ display = v2m_muxfpga 0;
+ max-hactive = 640;
+ max-vactive = 480;
+ max-bpp = 16;
};
};
@@ -282,7 +288,7 @@
/* CLCD clock */
compatible = arm,vexpress-osc;
arm,vexpress-sysreg,func = 1 1;
- freq-range = 2375 6350;
+ freq-range = 2375 6500;
#clock-cells = 0;
clock-output-names = v2m:oscclk1;
};
@@ -317,9 +323,11 @@
arm,vexpress-sysreg,func = 5 0;
};
- muxfpga@0 {
+ v2m_muxfpga: muxfpga@0 {
compatible = arm,vexpress-muxfpga;
arm,vexpress-sysreg,func = 7 0;
+ #display-cells = 1;
+ display = v2m_dvimode;
};
shutdown@0 {
@@ -332,9 +340,10 @@
arm,vexpress-sysreg,func = 9 0;
};
- dvimode@0 {
+ v2m_dvimode: dvimode@0 {
compatible = arm,vexpress-dvimode;
arm,vexpress-sysreg,func = 11 0;
+ #display-cells = 0;
};
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi
b/arch/arm/boot/dts/vexpress-v2m.dtsi
index f142036..4d080d0 100644
--- a/arch/arm/boot/dts/vexpress-v2m.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
@@ -40,7 +40,7 @@
bank-width = 4;
};
- vram@3, {
+ v2m_vram: vram@3, {
compatible = arm,vexpress-vram;
reg = 3 0x 0x0080;
};
@@ -232,6 +232,12 @@
interrupts = 14;
clocks = v2m_oscclk1, smbclk;
clock-names = clcdclk, apb_pclk;
+ label = IOFPGA CLCD;
+ video-ram = v2m_vram;
+ display = v2m_muxfpga 0;
+ max-hactive = 640;
+ max-vactive = 480;
+ max-bpp = 16;
};
};
@@ -281,7 +287,7 @@
/* CLCD clock */
compatible = arm,vexpress-osc;
arm,vexpress-sysreg,func = 1 1;
- freq-range = 2375 6350;
+ freq-range = 2375 6500;
#clock-cells = 0;
clock-output-names = v2m:oscclk1;
};
@@ -316,9 +322,11 @@
arm,vexpress-sysreg,func = 5 0;
};
- muxfpga@0 {
+ v2m_muxfpga: muxfpga@0 {
compatible = arm,vexpress-muxfpga;
arm,vexpress-sysreg,func = 7 0;
+ #display-cells = 1;
+ display = v2m_dvimode;
};
shutdown@0 {
@@ -331,9 +339,10 @@
arm,vexpress-sysreg,func = 9 0;
};
- dvimode@0 {
+ v2m_dvimode: dvimode@0 {
[RFC 09/10] video: Versatile Express DVI mode driver
Versatile Express DVI output is driven by a Sii9022 chip. It can be
controller to a limited extend by the Motherboard Config Controller,
and that's what the driver is doing now. It is a temporary measure
till there's a full I2C driver for the chip.
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
drivers/video/Makefile |1 +
drivers/video/vexpress-dvimode.c | 158 ++
2 files changed, 159 insertions(+)
create mode 100644 drivers/video/vexpress-dvimode.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 84c6083..9347e00 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -179,3 +179,4 @@ obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
# platform specific output drivers
obj-$(CONFIG_VEXPRESS_CONFIG)+= vexpress-muxfpga.o
+obj-$(CONFIG_VEXPRESS_CONFIG)+= vexpress-dvimode.o
diff --git a/drivers/video/vexpress-dvimode.c b/drivers/video/vexpress-dvimode.c
new file mode 100644
index 000..85d5608
--- /dev/null
+++ b/drivers/video/vexpress-dvimode.c
@@ -0,0 +1,158 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2013 ARM Limited
+ */
+
+#define pr_fmt(fmt) vexpress-dvimode: fmt
+
+#include linux/fb.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/vexpress.h
+#include video/display.h
+#include video/videomode.h
+
+
+static struct vexpress_config_func *vexpress_dvimode_func;
+
+
+static int vexpress_dvimode_display_update(struct display_entity *display,
+ const struct videomode *mode)
+{
+ static const struct {
+ u32 hactive, vactive, dvimode;
+ } dvimodes[] = {
+ { 640, 480, 0 }, /* VGA */
+ { 800, 600, 1 }, /* SVGA */
+ { 1024, 768, 2 }, /* XGA */
+ { 1280, 1024, 3 }, /* SXGA */
+ { 1600, 1200, 4 }, /* UXGA */
+ { 1920, 1080, 5 }, /* HD1080 */
+ };
+ int err = -ENOENT;
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(dvimodes); i++) {
+ if (dvimodes[i].hactive == mode-hactive
+ dvimodes[i].vactive == mode-vactive) {
+ pr_debug(mode: %ux%u = %d\n, mode-hactive,
+ mode-vactive, dvimodes[i].dvimode);
+ err = vexpress_config_write(vexpress_dvimode_func, 0,
+ dvimodes[i].dvimode);
+ break;
+ }
+ }
+
+ if (err)
+ pr_warn(Failed to set %ux%u mode! (%d)\n, mode-hactive,
+ mode-vactive, err);
+
+ return err;
+}
+
+static int vexpress_dvimode_display_get_modes(struct display_entity *display,
+ const struct videomode **modes)
+{
+ static const struct videomode m[] = {
+ {
+ /* VGA */
+ .pixelclock = 25175000,
+ .hactive= 640,
+ .hback_porch= 40,
+ .hfront_porch = 24,
+ .vfront_porch = 11,
+ .hsync_len = 96,
+ .vactive= 480,
+ .vback_porch= 32,
+ .vsync_len = 2,
+ }, {
+ /* XGA */
+ .pixelclock = 63500127,
+ .hactive= 1024,
+ .hback_porch= 152,
+ .hfront_porch = 48,
+ .hsync_len = 104,
+ .vactive= 768,
+ .vback_porch= 23,
+ .vfront_porch = 3,
+ .vsync_len = 4,
+ }, {
+ /* SXGA */
+ .pixelclock = 10800,
+ .hactive= 1280,
+ .hback_porch= 248,
+ .hfront_porch = 48,
+ .hsync_len = 112,
+ .vactive= 1024,
+ .vback_porch= 38,
+ .vfront_porch = 1,
+ .vsync_len = 3,
+ },
+ };
+
+ *modes = m;
+
+ return ARRAY_SIZE(m);
+}
+
+static int vexpress_dvimode_display_get_params(struct display_entity *display,
+ struct display_entity_interface_params *params)
+{
+ params-type = DISPLAY_ENTITY_INTERFACE_TFT_PARALLEL;
+
[RFC 04/10] video: display: Add generic TFT display type
TFT panels may be interfaced via a simple parallel interface
carrying RGB data, pixel clock and synchronisation signals.
From the video generator point of view the width of the data
channels (number of bits per R/G/B components) may be an
important factor in setting up the display model.
Above information is based on the presentations by Dave Anders
available here: http://elinux.org/Elc-lcd
This patch adds the parallel TFT display type and basic parameters
structure. Maybe it should be split into a separate header, eg.
include/video/tft.h? Or maybe it's just the INTERFACE_DPI I'm
talking about?
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
include/video/display.h |9 +
1 file changed, 9 insertions(+)
diff --git a/include/video/display.h b/include/video/display.h
index 7fe8b2f..875e230 100644
--- a/include/video/display.h
+++ b/include/video/display.h
@@ -69,10 +69,19 @@ enum display_entity_stream_state {
enum display_entity_interface_type {
DISPLAY_ENTITY_INTERFACE_DPI,
+ DISPLAY_ENTITY_INTERFACE_TFT_PARALLEL,
+};
+
+struct tft_parallel_interface_params {
+ int r_bits, g_bits, b_bits;
+ int r_b_swapped;
};
struct display_entity_interface_params {
enum display_entity_interface_type type;
+ union {
+ struct tft_parallel_interface_params tft_parallel;
+ } p;
};
struct display_entity_control_ops {
--
1.7.10.4
--
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 06/10] video: ARM CLCD: Add DT CDF support
This patch adds basic DT bindings for the PL11x CLCD cells
and make their fbdev driver use them, together with the
Common Display Framework.
The DT provides information about the hardware configuration
and limitations (eg. the largest supported resolution)
but the video modes come exclusively from the Common
Display Framework drivers, referenced to by the standard CDF
binding.
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
.../devicetree/bindings/video/arm,pl11x.txt| 35 +++
drivers/video/Kconfig |1 +
drivers/video/amba-clcd.c | 244
include/linux/amba/clcd.h |2 +
4 files changed, 282 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt
b/Documentation/devicetree/bindings/video/arm,pl11x.txt
new file mode 100644
index 000..ee9534a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -0,0 +1,35 @@
+* ARM PrimeCell Color LCD Controller (CLCD) PL110/PL111
+
+Required properties:
+
+- compatible : must be one of:
+ arm,pl110, arm,primecell
+ arm,pl111, arm,primecell
+- reg : base address and size of the control registers block
+- interrupts : the combined interrupt
+- clocks : phandles to the CLCD (pixel) clock and the APB clocks
+- clock-names : clcdclk, apb_pclk
+- display : phandle to the display entity connected to the controller
+
+Optional properties:
+
+- label : string describing the controller location and/or usage
+- video-ram : phandle to DT node of the specialized video RAM to be used
+- max-hactive : maximum frame buffer width in pixels
+- max-vactive : maximum frame buffer height in pixels
+- max-bpp : maximum number of bits per pixel
+- big-endian-pixels : defining this property makes the pixel bytes being
+ accessed in Big Endian organization
+
+Example:
+
+ clcd@1f {
+ compatible = arm,pl111, arm,primecell;
+ reg = 0x1f 0x1000;
+ interrupts = 14;
+ clocks = v2m_oscclk1, smbclk;
+ clock-names = clcdclk, apb_pclk;
+ label = IOFPGA CLCD;
+ video-ram = v2m_vram;
+ display = v2m_muxfpga;
+ };
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 281e548..bad8166 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -340,6 +340,7 @@ config FB_ARMCLCD
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select FB_MODE_HELPERS if OF
help
This framebuffer device driver is for the ARM PrimeCell PL110
Colour LCD controller. ARM PrimeCells provide the building
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..778dc03 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -25,6 +25,11 @@
#include linux/amba/clcd.h
#include linux/clk.h
#include linux/hardirq.h
+#include linux/dma-mapping.h
+#include linux/of.h
+#include linux/of_address.h
+#include video/display.h
+#include video/videomode.h
#include asm/sizes.h
@@ -62,6 +67,10 @@ static void clcdfb_disable(struct clcd_fb *fb)
{
u32 val;
+ if (fb-panel-display)
+ display_entity_set_state(fb-panel-display,
+ DISPLAY_ENTITY_STATE_OFF);
+
if (fb-board-disable)
fb-board-disable(fb);
@@ -115,6 +124,11 @@ static void clcdfb_enable(struct clcd_fb *fb, u32 cntl)
*/
if (fb-board-enable)
fb-board-enable(fb);
+
+ if (fb-panel-display)
+ display_entity_set_state(fb-panel-display,
+ DISPLAY_ENTITY_STATE_ON);
+
}
static int
@@ -304,6 +318,13 @@ static int clcdfb_set_par(struct fb_info *info)
clcdfb_enable(fb, regs.cntl);
+ if (fb-panel-display) {
+ struct videomode mode;
+
+ videomode_from_fb_var_screeninfo(fb-fb.var, mode);
+ display_entity_update(fb-panel-display, mode);
+ }
+
#ifdef DEBUG
printk(KERN_INFO
CLCD: Registers set to\n
@@ -542,6 +563,226 @@ static int clcdfb_register(struct clcd_fb *fb)
return ret;
}
+#if defined(CONFIG_OF)
+static int clcdfb_of_get_tft_parallel_panel(struct clcd_panel *panel,
+ struct display_entity_interface_params *params)
+{
+ int r = params-p.tft_parallel.r_bits;
+ int g = params-p.tft_parallel.g_bits;
+ int b = params-p.tft_parallel.b_bits;
+
+ /* Bypass pixel clock divider, data output on the falling edge */
+ panel-tim2 = TIM2_BCD | TIM2_IPC;
+
+ /*
[RFC 07/10] mfd: vexpress: Allow external drivers to parse site ids
... by providing a function translating the MASTER
value into the currently valid site number and
a _LAST constant providing all possible site id values.
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
drivers/mfd/vexpress-sysreg.c |5 +
include/linux/vexpress.h |2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c
index bf75e96..4158e26 100644
--- a/drivers/mfd/vexpress-sysreg.c
+++ b/drivers/mfd/vexpress-sysreg.c
@@ -81,6 +81,11 @@ void vexpress_flags_set(u32 data)
writel(data, vexpress_sysreg_base + SYS_FLAGSSET);
}
+u32 vexpress_get_site(int site)
+{
+ return site == VEXPRESS_SITE_MASTER ? vexpress_master_site : site;
+}
+
u32 vexpress_get_procid(int site)
{
if (site == VEXPRESS_SITE_MASTER)
diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h
index 7581874..1ebbcf5 100644
--- a/include/linux/vexpress.h
+++ b/include/linux/vexpress.h
@@ -19,6 +19,7 @@
#define VEXPRESS_SITE_MB 0
#define VEXPRESS_SITE_DB1 1
#define VEXPRESS_SITE_DB2 2
+#define __VEXPRESS_SITE_LAST 3
#define VEXPRESS_SITE_MASTER 0xf
#define VEXPRESS_CONFIG_STATUS_DONE0
@@ -103,6 +104,7 @@ int vexpress_config_write(struct vexpress_config_func
*func, int offset,
/* Platform control */
+u32 vexpress_get_site(int site);
u32 vexpress_get_procid(int site);
u32 vexpress_get_hbi(int site);
void *vexpress_get_24mhz_clock_base(void);
--
1.7.10.4
--
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 08/10] video: Versatile Express MUXFPGA driver
Versatile Express' DVI video output can be connected to one the three
sources - motherboard's CLCD controller or a video signal generated
by one of the daughterboards.
This driver provides a Common Display Framework driver for the
muxer FPGA, which acts as a switch selecting one of the video data
sources. The default source is selected basing on the priority
list (which itself can be modified via module paramter), but
the user can make his own decision about it using the device's
sysfs source attribute.
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
.../testing/sysfs-driver-video-vexpress-muxfpga|5 +
drivers/video/Makefile |3 +
drivers/video/vexpress-muxfpga.c | 228
3 files changed, 236 insertions(+)
create mode 100644
Documentation/ABI/testing/sysfs-driver-video-vexpress-muxfpga
create mode 100644 drivers/video/vexpress-muxfpga.c
diff --git a/Documentation/ABI/testing/sysfs-driver-video-vexpress-muxfpga
b/Documentation/ABI/testing/sysfs-driver-video-vexpress-muxfpga
new file mode 100644
index 000..bfd568d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-video-vexpress-muxfpga
@@ -0,0 +1,5 @@
+What: /sys/bus/platform/drivers/vexpress-muxfpga/muxfpga
device/source
+Date: April 2013
+Contant: Pawel Moll pawel.m...@arm.com
+Description: This file stores the id of the video signal source
+ supposed to be routed to the board's DVI output.
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index b989e8e..84c6083 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -176,3 +176,6 @@ obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
obj-$(CONFIG_OF_DISPLAY_TIMING) += of_display_timing.o
obj-$(CONFIG_VIDEOMODE) += videomode.o
obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
+
+# platform specific output drivers
+obj-$(CONFIG_VEXPRESS_CONFIG)+= vexpress-muxfpga.o
diff --git a/drivers/video/vexpress-muxfpga.c b/drivers/video/vexpress-muxfpga.c
new file mode 100644
index 000..1731ad0
--- /dev/null
+++ b/drivers/video/vexpress-muxfpga.c
@@ -0,0 +1,228 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2013 ARM Limited
+ */
+
+#define pr_fmt(fmt) vexpress-muxfpga: fmt
+
+#include linux/fb.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/vexpress.h
+#include video/display.h
+#include video/videomode.h
+
+
+static struct vexpress_config_func *vexpress_muxfpga_func;
+static struct display_entity *vexpress_muxfpga_output;
+
+
+static struct vexpress_muxfpga_source {
+ struct display_entity display;
+ struct videomode mode;
+ bool updated;
+} vexpress_muxfpga_sources[__VEXPRESS_SITE_LAST];
+static u32 vexpress_muxfpga_source_site = VEXPRESS_SITE_MB;
+static bool vexpress_muxfpga_source_stored;
+
+
+static int vexpress_muxfpga_set_site(u32 site)
+{
+ int err;
+
+ if (site = ARRAY_SIZE(vexpress_muxfpga_sources))
+ return -EINVAL;
+
+ err = vexpress_config_write(vexpress_muxfpga_func, 0, site);
+ if (!err) {
+ pr_debug(Selected site %d as source\n, site);
+ vexpress_muxfpga_source_site = site;
+ } else {
+ pr_warn(Failed to select site %d as source! (%d)\n,
+ site, err);
+ }
+
+ return err;
+}
+
+static unsigned int vexpress_muxfpga_preferred_sites[] = {
+ VEXPRESS_SITE_MASTER,
+ VEXPRESS_SITE_DB1,
+ VEXPRESS_SITE_DB2,
+ VEXPRESS_SITE_MB,
+};
+static unsigned int vexpress_muxfpga_preferred_sites_num =
+ ARRAY_SIZE(vexpress_muxfpga_preferred_sites);
+module_param_array_named(preferred_sites, vexpress_muxfpga_preferred_sites,
+ uint, vexpress_muxfpga_preferred_sites_num, S_IRUGO);
+MODULE_PARM_DESC(preferred_sites, Preferred order of MUXFPGA (DVI output)
+ sources; values can be a daughterboard site ID (1-2), the
+ motherboard ID (0) or a value describing the master site
+ (0xf).);
+
+static int vexpress_muxfpga_get_priority(u32 site)
+{
+ int i;
+
+ for (i = 0; i vexpress_muxfpga_preferred_sites_num; i++) {
+ u32 preference = vexpress_muxfpga_preferred_sites[i];
+
+ if (site == vexpress_get_site(preference))
+ return i;
+ }
+
+ return INT_MAX;
+}
+
+static void vexpress_muxfpga_set_preffered_site(u32 site)
+{
+ int current_priority = vexpress_muxfpga_get_priority(
+
Re: Compilation breakage on drivers/media due to OF patches - was: Re: [PATCH] DT: export of_get_next_parent() for use by modules: fix modular V4L2
Em Wed, 17 Apr 2013 16:08:43 +0100 Grant Likely grant.lik...@secretlab.ca escreveu: On Wed, 17 Apr 2013 11:53:57 -0300, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi Grant/Rob, Our tree is currently _broken_ with OT, because of the lack of exporting of_get_next_parent. The developer that submitted the patches that added V4L2 OF support forgot to test to compilation with MODULES support enabled. So, we're now having: ERROR: of_get_next_parent [drivers/media/v4l2-core/videodev.ko] undefined! if compiled with OF enabled and media as module. As those patches were applied at my master branch and there are lots of other patches on the top of the patches that added V4L2 OF support, I prefer to avoid reverting those patches. On the other hand, I can't send the patches upstream next week (assuming that -rc7 is the final one), without having this patch applying before the media tree. The fix needs to be applied to your tree then. Go ahead and apply it with my ack: Acked-by: Grant Likely grant.lik...@linaro.org Thank you! It is no good to apply it to the devicetree -next branch because that will still leave your branch broken, even if device tree gets merged first. True. Thanks, 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: [PATCH] [media] uvcvideo: quirk PROBE_DEF for Dell Studio / OmniVision webcam
On Wed, 2013-04-17 at 01:05 +0200, Laurent Pinchart wrote: Hi Kamal, On Monday 15 April 2013 12:01:51 Kamal Mostafa wrote: BugLink: https://bugs.launchpad.net/bugs/1168430 OminiVision webcam 0x05a9:0x264a (in Dell Studio Hybrid 140g) needs the same UVC_QUIRK_PROBE_DEF as other OmniVision model to be recognized consistently. Signed-off-by: Kamal Mostafa ka...@canonical.com Thank you for the patch. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I've taken the patch in my tree and will submit it upstream for v3.11. Could you please try to get the full 'lsusb -v -d 05a9:264a' output from the bug reporter ? Thanks Laurent. The requested lsusb dump is now available at https://launchpadlibrarian.net/137633994/lsusb-omnivision-264a.txt -Kamal signature.asc Description: This is a digitally signed message part
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: Wed Apr 17 19:00:22 CEST 2013 git branch: test git hash: 6695be6863b75620ffa6d422965680ce785cb7c8 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8-3.slh.2-amd64 linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS 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: ERRORS 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: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-3.9-rc1-i686: OK linux-2.6.31.14-x86_64: 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: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: OK linux-3.9-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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 v2 2/3] mutex: add support for reservation style locks, v2
On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt rost...@goodmis.org wrote: On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote: On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: The thing is now that you're not expected to hold these locks for a long time - if you need to synchronously stall while holding a lock performance will go down the gutters anyway. And since most current gpus/co-processors still can't really preempt fairness isn't that high a priority, either. So we didn't think too much about that. Yeah but you're proposing a new synchronization primitive for the core kernel.. all such 'fun' details need to be considered, not only those few that bear on the one usecase. Which bares the question, what other use cases are there? Just stumbled over one I think: If we have a big graph of connected things (happens really often for video pipelines). And we want multiple users to use them in parallel. But sometimes a configuration change could take way too long and so would unduly stall a 2nd thread with just a global mutex, then per-object ww_mutexes would be a fit: You'd start with grabbing all the locks for the objects you want to change anything with, then grab anything in the graph that you also need to check. Thanks to loop detection and self-recursion this would all nicely work out, even for cyclic graphs of objects. -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: [RFC] [media] dvb-core: check -msg_len for diseqc_send_master_cmd()
On 04/17/2013 03:03 PM, Dan Carpenter wrote:
Any feedback on this?
I forgot to CC Steven Toth last time because he would know about the
cx24116 driver. I've looked at it again and it still looks like
cx24116_send_diseqc_msg() is copying garbage into the
state-dsec_cmd.args[] array.
It looks fine. I have thought that same few times earlier too. Thank you.
Reviewed-by: Antti Palosaari cr...@iki.fi
regards,
dan carpenter
On Tue, Apr 02, 2013 at 10:51:02AM +0300, Dan Carpenter wrote:
I'd like to send this patch except that it breaks
cx24116_send_diseqc_msg(). The cx24116 driver accepts -msg_len values
up to 24 but it looks like it's just copying 16 bytes past the end of
the -msg[] array so it's already broken.
cmd-msg_len is an unsigned char. The comment next to the struct
declaration says that valid values are are 3-6. Some of the drivers
check that this is true, but most don't and it could cause memory
corruption.
Some examples of functions which don't check are:
ttusbdecfe_dvbs_diseqc_send_master_cmd()
cx24123_send_diseqc_msg()
ds3000_send_diseqc_msg()
etc.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 57601c0..3d1eee6 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2265,7 +2265,13 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
case FE_DISEQC_SEND_MASTER_CMD:
if (fe-ops.diseqc_send_master_cmd) {
- err = fe-ops.diseqc_send_master_cmd(fe, (struct
dvb_diseqc_master_cmd*) parg);
+ struct dvb_diseqc_master_cmd *cmd = parg;
+
+ if (cmd-msg_len = 3 cmd-msg_len = 6)
+ err = fe-ops.diseqc_send_master_cmd(fe, cmd);
+ else
+ err = -EINVAL;
+
fepriv-state = FESTATE_DISEQC;
fepriv-status = 0;
}
--
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: Keene
On 04/15/2013 09:55 AM, Hans Verkuil wrote:
On Fri April 12 2013 02:11:41 Antti Palosaari wrote:
Hello Hans,
That device is working very, thank you for it. Anyhow, I noticed two things.
1) it does not start transmitting just after I plug it - I have to
retune it!
Output says it is tuned to 95.16 MHz by default, but it is not.
After I issue retune, just to same channel it starts working.
$ v4l2-ctl -d /dev/radio0 --set-freq=95.16
Can you try this patch:
It does not resolve the problem. It is quite strange behavior. After I
install modules, and modules are unload, plug stick in first time, it
usually (not every-time) starts TX. But when I replug it without
unloading modules, it will never start TX. Tx is started always when I
set freq using v4l2-ctl.
Possible timing issue?
Is there some flag API flag to tell start / stop device? For my mind
correct behavior is to stop TX and sleep when device is plugged/module
load. Something like set freq 0 when device is not active to tell user
it is not sending/receiving and must be tuned in order to operate.
regards
Antti
diff --git a/drivers/media/radio/radio-keene.c
b/drivers/media/radio/radio-keene.c
index 4c9ae76..99da3d4 100644
--- a/drivers/media/radio/radio-keene.c
+++ b/drivers/media/radio/radio-keene.c
@@ -93,7 +93,7 @@ static int keene_cmd_main(struct keene_device *radio,
unsigned freq, bool play)
/* If bit 4 is set, then tune to the frequency.
If bit 3 is set, then unmute; if bit 2 is set, then mute.
If bit 1 is set, then enter idle mode; if bit 0 is set,
- then enter transit mode.
+ then enter transmit mode.
*/
radio-buffer[5] = (radio-muted ? 4 : 8) | (play ? 1 : 2) |
(freq ? 0x10 : 0);
@@ -350,7 +350,6 @@ static int usb_keene_probe(struct usb_interface *intf,
radio-pa = 118;
radio-tx = 0x32;
radio-stereo = true;
- radio-curfreq = 95.16 * FREQ_MUL;
if (hdl-error) {
retval = hdl-error;
@@ -383,6 +382,8 @@ static int usb_keene_probe(struct usb_interface *intf,
video_set_drvdata(radio-vdev, radio);
set_bit(V4L2_FL_USE_FH_PRIO, radio-vdev.flags);
+ keene_cmd_main(radio, 95.16 * FREQ_MUL, false);
+
retval = video_register_device(radio-vdev, VFL_TYPE_RADIO, -1);
if (retval 0) {
dev_err(intf-dev, could not register video device\n);
2) What is that log printing?
ALSA sound/usb/mixer.c:932 13:0: cannot get min/max values for control 2
(id 13)
usb 5-2: new full-speed USB device number 3 using ohci_hcd
usb 5-2: New USB device found, idVendor=046d, idProduct=0a0e
usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 5-2: Product: B-LINK USB Audio
usb 5-2: Manufacturer: HOLTEK
ALSA sound/usb/mixer.c:932 13:0: cannot get min/max values for control 2
(id 13)
radio-keene 5-2:1.2: V4L2 device registered as radio0
No idea, and I don't get that message either.
Regards,
Hans
$ v4l2-ctl -d /dev/radio0 --all -L
Driver Info (not using libv4l2):
Driver name : radio-keene
Card type : Keene FM Transmitter
Bus info : usb-:00:13.0-2
Driver version: 3.9.0
Capabilities : 0x800C
Modulator
Radio
Frequency: 1522560 (95.16 MHz)
Modulator:
Name : FM
Capabilities : 62.5 Hz stereo
Frequency range : 76.0 MHz - 108.0 MHz
Subchannel modulation: stereo
Priority: 2
User Controls
mute (bool) : default=0 value=0
FM Radio Modulator Controls
audio_compression_gain (int): min=-15 max=18 step=3
default=0 value=0 flags=slider
pre_emphasis (menu) : min=0 max=2 default=1 value=1
1: 50 Microseconds
2: 75 Microseconds
tune_power_level (int): min=84 max=118 step=1
default=118 value=118 flags=slider
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] media: ir-rc5-decoder: improve responsiveness by 100ms to 250ms
Hello,
Here is a patch to improve the responsiveness of the rc5 decoder when
using the ite-cir driver. Most of the information below should also be
applicable to other decoders and ir drivers (e.g. rc6 for sure). The
problem is that the current decoder is subject to a double timeout:
(a) 200ms in ite-cir (see ITE_IDLE_TIMEOUT)
(b) 250ms in rc-main (see IR_KEYPRESS_TIMEOUT)
The timeout (a) is causing a delay of up to 200ms on the keypress events
because STATE_FINISHED is not processed until a blank is received.
The timeout (b) is causing an additional delay of 250ms on the final keyup.
My patch is reducing those delays using two techniques:
(1) The keypress is sent as soon as the 1st half of the last bit is
received. This is a bi-phase encoding so the second part is not strictly
needed to figure out the value of that last bit.
(2) An explicit keyup in produced when the 200ms blank caused by
timeout (a) is detected. In practice, timeout (b) never occurs.
reminder: The RC5 protocol specifies that messages shall be be repeated
every 113ms as long as the key remains pressed.
Here are some real timings measured by adding a few printk:
For a single RC5 message the KEYDOWN and the KEYUP respectively occur
20ms and 220ms after receiving the first pulse (versus 220ms and 470ms
with the original decoder)
For a double RC5 message the 2 KEYDOWNs and the KEYUP events
respectively occur 21ms, 134ms and 334ms after the first pulse (versus
111ms, 335ms and 584ms)
For a triple RC5 message the 3 KEYDOWNs and the KEYUP events 21ms,
134ms, 247 and 447ms after the first pulse (versus 111ms, 335ms, 448ms
and 697ms)
Unfortunately, triple RC5 messages are quite common when using the
remote in a nomal way and, without my patch, the delay between the first
keydown and the final keyup is about 590ms. This is enough to cause a
key-repeat on most systems. For instance, XBMC has an hard-coded
key-repeat delay of 500ms and so is almost unusable without my patch.
Even with a key repeat delay set to 600ms or above, the original decoder
feels sluggish and unreliable.
I did not try but in theory the timeout (a) could be reduced to any
value above 134ms to make the decoder even more responsive.
Stephane.
--- ir-rc5-decoder.c.orig2013-04-17 20:40:41.939326236 +0200
+++ ir-rc5-decoder.c2013-04-17 21:51:40.368925128 +0200
@@ -30,11 +30,14 @@
#define RC5_BIT_START(1 * RC5_UNIT)
#define RC5_BIT_END(1 * RC5_UNIT)
#define RC5X_SPACE(4 * RC5_UNIT)
+#define RC5_UP_DELAY11400 /* ns */
enum rc5_state {
STATE_INACTIVE,
STATE_BIT_START,
STATE_BIT_END,
+STATE_LAST_START,
+STATE_LAST_END,
STATE_CHECK_RC5X,
STATE_FINISHED,
};
@@ -99,8 +102,8 @@ again:
if (!is_transition(ev, dev-raw-prev_ev))
break;
-if (data-count == data-wanted_bits)
-data-state = STATE_FINISHED;
+if (data-count == data-wanted_bits-1)
+data-state = STATE_LAST_START;
else if (data-count == CHECK_RC5X_NBITS)
data-state = STATE_CHECK_RC5X;
else
@@ -109,22 +112,16 @@ again:
decrease_duration(ev, RC5_BIT_END);
goto again;
-case STATE_CHECK_RC5X:
-if (!ev.pulse geq_margin(ev.duration, RC5X_SPACE, RC5_UNIT /
2)) {
-/* RC5X */
-data-wanted_bits = RC5X_NBITS;
-decrease_duration(ev, RC5X_SPACE);
-} else {
-/* RC5 */
-data-wanted_bits = RC5_NBITS;
-}
-data-state = STATE_BIT_START;
-goto again;
-
-case STATE_FINISHED:
-if (ev.pulse)
+case STATE_LAST_START:
+if (!eq_margin(ev.duration, RC5_BIT_START, RC5_UNIT / 2))
break;
+data-bits = 1;
+if (!ev.pulse)
+data-bits |= 1;
+data-count++;
+data-state = STATE_LAST_END;
+
if (data-wanted_bits == RC5X_NBITS) {
/* RC5X */
u8 xdata, command, system;
@@ -160,6 +157,42 @@ again:
}
rc_keydown(dev, scancode, toggle);
+
+return 0;
+
+case STATE_LAST_END:
+if (!is_transition(ev, dev-raw-prev_ev))
+break;
+
+data-state = STATE_FINISHED;
+
+decrease_duration(ev, RC5_BIT_END);
+goto again;
+
+case STATE_CHECK_RC5X:
+if (!ev.pulse
+ geq_margin(ev.duration, RC5X_SPACE, RC5_UNIT/2)) {
+/* RC5X */
+data-wanted_bits = RC5X_NBITS;
+decrease_duration(ev, RC5X_SPACE);
+} else {
+/* RC5 */
+data-wanted_bits = RC5_NBITS;
+}
+data-state = STATE_BIT_START;
+goto again;
+
+case STATE_FINISHED:
+if (ev.pulse)
+break;
+
+/* The message is repeated RC5_UP_DELAY ns after the 1st pulse
+ * so a blank of RC5_UP_DELAY ns after the last pulse shall be
+ * enough to assume that the message
[PATCH 0/4] R-Car VIN driver with R8A7779/Marzen support
Hello. Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130417' tag and my recent yet unapplied patches. Here we add the VIN (Video In) driver and its platform code working on the R8A7779/ Marzen with ADV7180 I2C camera sensor. The driver patch also applies without issues to Mauro's 'media_tree.git'... [1/4] V4L2: soc_camera: Renesas R-Car VIN driver [2/4] ARM: shmobile: r8a7779: add VIN support [3/4] ARM: shmobile: Marzen: add VIN and ADV7180 support [4/4] ARM: shmobile: Marzen: enable VIN and ADV7180 in defconfig WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] V4L2: soc_camera: Renesas R-Car VIN driver
From: Vladimir Barinov vladimir.bari...@cogentembedded.com Add Renesas R-Car VIN (Video In) V4L2 driver. Based on the patch by Phil Edworthy phil.edwor...@renesas.com. Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com [Sergei: some formatting cleanup] Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- drivers/media/platform/soc_camera/Kconfig|7 drivers/media/platform/soc_camera/Makefile |1 drivers/media/platform/soc_camera/rcar_vin.c | 1784 +++ include/linux/platform_data/camera-rcar.h| 25 4 files changed, 1817 insertions(+) Index: renesas/drivers/media/platform/soc_camera/Kconfig === --- renesas.orig/drivers/media/platform/soc_camera/Kconfig +++ renesas/drivers/media/platform/soc_camera/Kconfig @@ -45,6 +45,13 @@ config VIDEO_PXA27x ---help--- This is a v4l2 driver for the PXA27x Quick Capture Interface +config VIDEO_RCAR_VIN + tristate R-Car Video Input (VIN) support + depends on VIDEO_DEV SOC_CAMERA (ARCH_R8A7778 || ARCH_R8A7779) + select VIDEOBUF2_DMA_CONTIG + ---help--- + This is a v4l2 driver for the R-Car VIN Interface + config VIDEO_SH_MOBILE_CSI2 tristate SuperH Mobile MIPI CSI-2 Interface driver depends on VIDEO_DEV SOC_CAMERA HAVE_CLK Index: renesas/drivers/media/platform/soc_camera/Makefile === --- renesas.orig/drivers/media/platform/soc_camera/Makefile +++ renesas/drivers/media/platform/soc_camera/Makefile @@ -10,5 +10,6 @@ obj-$(CONFIG_VIDEO_OMAP1) += omap1_came obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o +obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar_vin.o ccflags-y += -I$(srctree)/drivers/media/i2c/soc_camera Index: renesas/drivers/media/platform/soc_camera/rcar_vin.c === --- /dev/null +++ renesas/drivers/media/platform/soc_camera/rcar_vin.c @@ -0,0 +1,1784 @@ +/* + * SoC-camera host driver for Renesas R-Car VIN unit + * + * Copyright (C) 2011-2013 Renesas Solutions Corp. + * Copyright (C) 2013 Cogent Embedded, Inc., sou...@cogentembedded.com + * + * Based on V4L2 Driver for SuperH Mobile CEU interface sh_mobile_ceu_camera.c + * + * Copyright (C) 2008 Magnus Damm + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/interrupt.h +#include linux/slab.h +#include linux/delay.h +#include linux/platform_device.h +#include linux/pm_runtime.h +#include linux/platform_data/camera-rcar.h + +#include media/videobuf2-dma-contig.h +#include media/soc_camera.h +#include media/soc_mediabus.h + +#define DRV_NAME rcar_vin + +/* Register offsets for R-Сar VIN */ +#define VNMC_REG 0x00/* Video n Main Control Register */ +#define VNMS_REG 0x04/* Video n Module Status Register */ +#define VNFC_REG 0x08/* Video n Frame Capture Register */ +#define VNSLPRC_REG0x0C/* Video n Start Line Pre-Clip Register */ +#define VNELPRC_REG0x10/* Video n End Line Pre-Clip Register */ +#define VNSPPRC_REG0x14/* Video n Start Pixel Pre-Clip Register */ +#define VNEPPRC_REG0x18/* Video n End Pixel Pre-Clip Register */ +#define VNSLPOC_REG0x1C/* Video n Start Line Post-Clip Register */ +#define VNELPOC_REG0x20/* Video n End Line Post-Clip Register */ +#define VNSPPOC_REG0x24/* Video n Start Pixel Post-Clip Register */ +#define VNEPPOC_REG0x28/* Video n End Pixel Post-Clip Register */ +#define VNIS_REG 0x2C/* Video n Image Stride Register */ +#define VNMB_REG(m)(0x30 + ((m) 2)) /* Video n Memory Base m Register */ +#define VNIE_REG 0x40/* Video n Interrupt Enable Register */ +#define VNINTS_REG 0x44/* Video n Interrupt Status Register */ +#define VNSI_REG 0x48/* Video n Scanline Interrupt Register */ +#define VNMTC_REG 0x4C/* Video n Memory Transfer Control Register */ +#define VNYS_REG 0x50/* Video n Y Scale Register */ +#define VNXS_REG 0x54/* Video n X Scale Register */ +#define VNDMR_REG 0x58/* Video n Data Mode Register */ +#define VNDMR2_REG 0x5C/* Video n Data Mode Register 2 */ +#define VNUVAOF_REG0x60/* Video n UV Address Offset Register */ + +/* Register bit fields for R-Сar VIN */ +/* Video n Main Control Register bits */ +#define VNMC_FOC (1 21) +#define VNMC_YCAL (1 19) +#define VNMC_INF_YUV8_BT656(0 16) +#define
[PATCH 2/4] ARM: shmobile: r8a7779: add VIN support
From: Vladimir Barinov vladimir.bari...@cogentembedded.com
Add VIN clocks and platform devices for R8A7779 SoC; add function to register
the VIN platform devices.
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
[Sergei: renamed some variables]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
arch/arm/mach-shmobile/clock-r8a7779.c| 10 +++
arch/arm/mach-shmobile/include/mach/r8a7779.h |3 ++
arch/arm/mach-shmobile/setup-r8a7779.c| 36 ++
3 files changed, 49 insertions(+)
Index: renesas/arch/arm/mach-shmobile/clock-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -112,7 +112,9 @@ static struct clk *main_clks[] = {
};
enum { MSTP323, MSTP322, MSTP321, MSTP320,
+ MSTP120,
MSTP116, MSTP115, MSTP114,
+ MSTP110, MSTP109, MSTP108,
MSTP103, MSTP101, MSTP100,
MSTP030,
MSTP029, MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022,
MSTP021,
@@ -125,9 +127,13 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP322] = SH_CLK_MSTP32(clkp_clk, MSTPCR3, 22, 0), /* SDHI1 */
[MSTP321] = SH_CLK_MSTP32(clkp_clk, MSTPCR3, 21, 0), /* SDHI2 */
[MSTP320] = SH_CLK_MSTP32(clkp_clk, MSTPCR3, 20, 0), /* SDHI3 */
+ [MSTP120] = SH_CLK_MSTP32(clks_clk, MSTPCR1, 20, 0), /* VIN3 */
[MSTP116] = SH_CLK_MSTP32(clkp_clk, MSTPCR1, 16, 0), /* PCIe */
[MSTP115] = SH_CLK_MSTP32(clkp_clk, MSTPCR1, 15, 0), /* SATA */
[MSTP114] = SH_CLK_MSTP32(clkp_clk, MSTPCR1, 14, 0), /* Ether */
+ [MSTP110] = SH_CLK_MSTP32(clks_clk, MSTPCR1, 10, 0), /* VIN0 */
+ [MSTP109] = SH_CLK_MSTP32(clks_clk, MSTPCR1, 9, 0), /* VIN1 */
+ [MSTP108] = SH_CLK_MSTP32(clks_clk, MSTPCR1, 8, 0), /* VIN2 */
[MSTP103] = SH_CLK_MSTP32(clks_clk, MSTPCR1, 3, 0), /* DU */
[MSTP101] = SH_CLK_MSTP32(clkp_clk, MSTPCR1, 1, 0), /* USB2 */
[MSTP100] = SH_CLK_MSTP32(clkp_clk, MSTPCR1, 0, 0), /* USB0/1 */
@@ -162,10 +168,14 @@ static struct clk_lookup lookups[] = {
CLKDEV_CON_ID(peripheral_clk, clkp_clk),
/* MSTP32 clocks */
+ CLKDEV_DEV_ID(rcar_vin.3, mstp_clks[MSTP120]), /* VIN3 */
CLKDEV_DEV_ID(rcar-pcie, mstp_clks[MSTP116]), /* PCIe */
CLKDEV_DEV_ID(sata_rcar, mstp_clks[MSTP115]), /* SATA */
CLKDEV_DEV_ID(fc60.sata, mstp_clks[MSTP115]), /* SATA w/DT */
CLKDEV_DEV_ID(sh-eth, mstp_clks[MSTP114]), /* Ether */
+ CLKDEV_DEV_ID(rcar_vin.0, mstp_clks[MSTP110]), /* VIN0 */
+ CLKDEV_DEV_ID(rcar_vin.1, mstp_clks[MSTP109]), /* VIN1 */
+ CLKDEV_DEV_ID(rcar_vin.2, mstp_clks[MSTP108]), /* VIN2 */
CLKDEV_DEV_ID(ehci-platform.1, mstp_clks[MSTP101]), /* USB EHCI
port2 */
CLKDEV_DEV_ID(ohci-platform.1, mstp_clks[MSTP101]), /* USB OHCI
port2 */
CLKDEV_DEV_ID(ehci-platform.0, mstp_clks[MSTP100]), /* USB EHCI
port0/1 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -5,6 +5,7 @@
#include linux/pm_domain.h
#include linux/sh_eth.h
#include linux/usb/rcar-phy.h
+#include linux/platform_data/camera-rcar.h
struct platform_device;
@@ -35,6 +36,8 @@ extern void r8a7779_add_standard_devices
extern void r8a7779_add_standard_devices_dt(void);
extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7779_add_vin_device(int idx,
+ struct rcar_vin_platform_data *pdata);
extern void r8a7779_init_late(void);
extern void r8a7779_clock_init(void);
extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -559,6 +559,33 @@ static struct resource ether_resources[]
},
};
+#define R8A7779_VIN(idx) \
+static struct resource vin##idx##_resources[] = { \
+ DEFINE_RES_MEM(0xffc5 + 0x1000 * (idx), 0x1000),\
+ DEFINE_RES_IRQ(gic_iid(0x5f + (idx))), \
+}; \
+ \
+static struct platform_device_info vin##idx##_info = { \
+ .parent = platform_bus,\
+ .name = rcar_vin, \
+ .id = idx, \
+ .res= vin##idx##_resources, \
+ .num_res=
[PATCH 3/4] ARM: shmobile: Marzen: add VIN and ADV7180 support
From: Vladimir Barinov vladimir.bari...@cogentembedded.com
Add ADV7180 platform devices on the Marzen board, configure VIN1/3 pins, and
register VIN1/3 devices with the ADV7180 specific platform data.
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
arch/arm/mach-shmobile/board-marzen.c | 55 ++
1 file changed, 55 insertions(+)
Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -37,6 +37,7 @@
#include linux/mmc/host.h
#include linux/mmc/sh_mobile_sdhi.h
#include linux/mfd/tmio.h
+#include media/soc_camera.h
#include mach/hardware.h
#include mach/r8a7779.h
#include mach/common.h
@@ -178,12 +179,54 @@ static struct platform_device leds_devic
},
};
+static struct rcar_vin_platform_data vin_platform_data = {
+ .flags = RCAR_VIN_BT656,
+};
+
+static struct i2c_board_info i2c_camera[] = {
+ {
+ I2C_BOARD_INFO(adv7180, 0x20),
+ }, {
+ I2C_BOARD_INFO(adv7180, 0x21),
+ },
+};
+
+static struct soc_camera_link iclink_adv7180[] = {
+ {
+ .bus_id = 1,
+ .i2c_adapter_id = 0,
+ .board_info = i2c_camera[0],
+ }, {
+ .bus_id = 3,
+ .i2c_adapter_id = 0,
+ .board_info = i2c_camera[1],
+ }
+};
+
+static struct platform_device camera0_device = {
+ .name = soc-camera-pdrv,
+ .id = 0,
+ .dev= {
+ .platform_data = iclink_adv7180[0],
+ },
+};
+
+static struct platform_device camera1_device = {
+ .name = soc-camera-pdrv,
+ .id = 1,
+ .dev= {
+ .platform_data = iclink_adv7180[1],
+ },
+};
+
static struct platform_device *marzen_devices[] __initdata = {
eth_device,
sdhi0_device,
thermal_device,
hspi_device,
leds_device,
+ camera0_device,
+ camera1_device,
};
static const struct pinctrl_map marzen_pinctrl_map[] = {
@@ -219,6 +262,16 @@ static const struct pinctrl_map marzen_p
/* USB2 */
PIN_MAP_MUX_GROUP_DEFAULT(ehci-platform.1, pfc-r8a7779,
usb2, usb2),
+ /* VIN1 */
+ PIN_MAP_MUX_GROUP_DEFAULT(rcar_vin.1, pfc-r8a7779,
+ vin1_clk, vin1),
+ PIN_MAP_MUX_GROUP_DEFAULT(rcar_vin.1, pfc-r8a7779,
+ vin1_data8, vin1),
+ /* VIN3 */
+ PIN_MAP_MUX_GROUP_DEFAULT(rcar_vin.3, pfc-r8a7779,
+ vin3_clk, vin3),
+ PIN_MAP_MUX_GROUP_DEFAULT(rcar_vin.3, pfc-r8a7779,
+ vin3_data8, vin3),
};
static void __init marzen_init(void)
@@ -234,6 +287,8 @@ static void __init marzen_init(void)
r8a7779_add_standard_devices();
r8a7779_add_usb_phy_device(usb_phy_platform_data);
+ r8a7779_add_vin_device(1, vin_platform_data);
+ r8a7779_add_vin_device(3, vin_platform_data);
platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
}
--
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] ARM: shmobile: Marzen: enable VIN and ADV7180 in defconfig
From: Vladimir Barinov vladimir.bari...@cogentembedded.com Add the VIN and ADV7180 drivers to 'marzen_defconfig'. Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- arch/arm/configs/marzen_defconfig |7 +++ 1 file changed, 7 insertions(+) Index: renesas/arch/arm/configs/marzen_defconfig === --- renesas.orig/arch/arm/configs/marzen_defconfig +++ renesas/arch/arm/configs/marzen_defconfig @@ -84,6 +84,13 @@ CONFIG_GPIO_RCAR=y CONFIG_THERMAL=y CONFIG_RCAR_THERMAL=y CONFIG_SSB=y +CONFIG_MEDIA_SUPPORT=y +CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_V4L_PLATFORM_DRIVERS=y +CONFIG_SOC_CAMERA=y +CONFIG_VIDEO_RCAR_VIN=y +# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set +CONFIG_VIDEO_ADV7180=y CONFIG_USB=y CONFIG_USB_RCAR_PHY=y CONFIG_MMC=y -- 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: ir-rc5-decoder: improve responsiveness by 100ms to 250ms
Here is a more detailed analysis of the problems my patch is supposed to solve. I added a few printk in the module to obtain some detailed timings. - DECODE is emited once at the begining of each call of ir_rc5_decode() to describe the blank or pulse event reported by ite_cir - FINISHED is emited during the last STATE_BIT_END when executing state=STATE_FINISHED - KEYDOWN is emited just before calling rc_keydown() - KEYUP is emited by ir_do_keyup() in rc-main.c The value following DECODE is the length of the pulse (+) or blank (-) as multiples of RC5_UNIT/10 (e.g. +20 means a pulse of 2*RC5_UNIT while -9 means a blank of 1*RC5_UNIT). The next value is that same length in microseconds. Here are the timings for a single 'even' RC-5 message (last bit is 0 so a blank followed by a pulse) using the original module: [507703.409737] DECODE +20 (1788us) [507703.412097] DECODE -19 (1762us) [507703.413282] DECODE +20 (1788us) [507703.415622] DECODE -19 (1762us) [507703.416822] DECODE +19 (1762us) [507703.419159] DECODE -20 (1788us) [507703.420357] DECODE +20 (1779us) [507703.421523] DECODE -9 (885us) [507703.422691] DECODE +10 (894us) [507703.423869] DECODE -19 (1771us) [507703.426239] DECODE +20 (1788us) [507703.427406] DECODE -19 (1762us) [507703.428639] DECODE +10 (894us) [507703.429772] DECODE -9 (877us) [507703.429779] DECODE +10 (894us) [507703.430946] DECODE -9 (885us) [507703.432131] DECODE +10 (894us) [507703.432138] FINISHED [507703.631331] DECODE -2255 (200317us) [507703.631338] KEYDOWN [507703.880020] KEYUP The last DECODE of 200ms is caused the timeout in the IR driver (see ITE_IDLE_TIMEOUT in ite_cir.h). The final STATE_BIT_END is processed before that long event is received but, because of the test after the 'goto again', the final STATE_FINISHED is delayed until the 200ms blank is received. It is important to notice that the KEYDOWN occurs 220ms after the first pulse and the keyup about 450ms after that the last pulse. The timings are similar for an odd RC-5 code (last bit is 1 so a pulse followed by a blank) [508157.054735] DECODE +19 (1762us) [508157.055906] DECODE -10 (929us) [508157.057098] DECODE +9 (868us) [508157.057107] DECODE -10 (911us) [508157.058259] DECODE +9 (842us) [508157.060730] DECODE -20 (1823us) [508157.061800] DECODE +19 (1762us) [508157.064167] DECODE -20 (1788us) [508157.065341] DECODE +19 (1727us) [508157.066507] DECODE -10 (937us) [508157.067686] DECODE +9 (868us) [508157.068932] DECODE -19 (1771us) [508157.071227] DECODE +20 (1779us) [508157.072423] DECODE -20 (1797us) [508157.073588] DECODE +9 (842us) [508157.074759] DECODE -10 (929us) [508157.075937] DECODE +19 (1736us) [508157.275149] DECODE -2252 (200039us) [508157.275156] FINISHED [508157.275159] KEYDOWN [508157.524021] KEYUP Here, the final STATE_BIT_END is a blank so it is processed as part of the final timeout. In any cases, the KEYDOWN in STATE_FINISHED occurs after the 200ms timeout so about 220ms after the first pulse. Finally, the KEYUP occurs 250ms after the KEYDOWN because of the timeout in rc-main.c (see IR_KEYPRESS_TIMEOUT) The situation is slightly different when the button remains pressed because the remote repeats the message after 113ms as required by the RC-5 protocol: [507866.803970] DECODE +20 (1831us) [507866.805169] DECODE -9 (825us) [507866.806330] DECODE +10 (894us) [507866.806339] DECODE -10 (911us) [507866.807511] DECODE +10 (955us) [507866.809874] DECODE -19 (1736us) [507866.811043] DECODE +19 (1701us) [507866.813413] DECODE -21 (1875us) [507866.814893] DECODE +18 (1675us) [507866.815758] DECODE -10 (937us) [507866.817038] DECODE +9 (868us) [507866.818110] DECODE -20 (1823us) [507866.820479] DECODE +20 (1788us) [507866.821646] DECODE -19 (1762us) [507866.822818] DECODE +9 (816us) [507866.823989] DECODE -10 (937us) [507866.823994] DECODE +9 (842us) [507866.825244] DECODE -10 (963us) [507866.826358] DECODE +9 (868us) [507866.826364] FINISHED [507866.915932] DECODE -1009 (89664us) [507866.915938] KEYDOWN [507866.917121] DECODE +19 (1753us) [507866.918286] DECODE -10 (963us) [507866.919463] DECODE +9 (842us) [507866.920685] DECODE -10 (911us) [507866.920696] DECODE +10 (894us) [507866.922999] DECODE -20 (1797us) [507866.924181] DECODE +19 (1727us) [507866.926530] DECODE -20 (1797us) [507866.927705] DECODE +20 (1840us) [507866.928912] DECODE -9 (825us) [507866.930067] DECODE +9 (842us) [507866.931238] DECODE -20 (1823us) [507866.933611] DECODE +20 (1788us) [507866.934778] DECODE -19 (1762us) [507866.935954] DECODE +9 (868us) [507866.937150] DECODE -10 (937us) [507866.938305] DECODE +9 (816us) [507866.938310] DECODE -10 (963us) [507866.939484] DECODE +10 (894us) [507866.939488] FINISHED [507867.139873] DECODE -2264 (201081us) [507867.139880] KEYDOWN [507867.388021] KEYUP The
Re: [PATCH 3/4] ARM: shmobile: Marzen: add VIN and ADV7180 support
Hello. On 04/18/2013 02:15 AM, Sergei Shtylyov wrote: From: Vladimir Barinov vladimir.bari...@cogentembedded.com Add ADV7180 platform devices on the Marzen board, configure VIN1/3 pins, and register VIN1/3 devices with the ADV7180 specific platform data. Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- arch/arm/mach-shmobile/board-marzen.c | 55 ++ 1 file changed, 55 insertions(+) Oops, should have updated copyrights on this file. :-/ Well, this is probably not the last version of the patchset anyway... :-) WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: ir-rc5-decoder: improve responsiveness by 100ms to 250ms
And here are two small patches to obtain timings on the original decoder. --- linux/drivers/media/rc/ir-rc5-decoder.c.orig2013-04-17 20:40:41.939326236 +0200 +++ linux/drivers/media/rc/ir-rc5-decoder.c2013-04-18 00:42:11.386539568 +0200 @@ -64,6 +64,8 @@ static int ir_rc5_decode(struct rc_dev * if (!geq_margin(ev.duration, RC5_UNIT, RC5_UNIT / 2)) goto out; +printk( KERN_INFO DECODE %c%02d (%dus)\n, (ev.pulse)?'+':'-',(ev.duration*10)/RC5_UNIT, TO_US(ev.duration)) ; + again: IR_dprintk(2, RC5(x) decode started at state %i (%uus %s)\n, data-state, TO_US(ev.duration), TO_STR(ev.pulse)); @@ -99,13 +101,14 @@ again: if (!is_transition(ev, dev-raw-prev_ev)) break; -if (data-count == data-wanted_bits) +if (data-count == data-wanted_bits) data-state = STATE_FINISHED; else if (data-count == CHECK_RC5X_NBITS) data-state = STATE_CHECK_RC5X; else data-state = STATE_BIT_START; - +if (data-state == STATE_FINISHED) +printk( KERN_INFO FINISHED\n); decrease_duration(ev, RC5_BIT_END); goto again; @@ -158,7 +161,7 @@ again: IR_dprintk(1, RC5 scancode 0x%04x (toggle: %u)\n, scancode, toggle); } - +printk( KERN_INFO KEYDOWN\n); rc_keydown(dev, scancode, toggle); data-state = STATE_INACTIVE; return 0; --- linux/drivers/media/rc/rc-main.c.orig2013-04-18 00:41:44.546364678 +0200 +++ linux/drivers/media/rc/rc-main.c2013-04-18 00:42:49.122785516 +0200 @@ -533,6 +533,7 @@ static void ir_do_keyup(struct rc_dev *d if (!dev-keypressed) return; +printk( KERN_INFO KEYUP\n); IR_dprintk(1, keyup key 0x%04x\n, dev-last_keycode); input_report_key(dev-input_dev, dev-last_keycode, 0); if (sync) On 04/18/2013 12:18 AM, Stephane Chauveau wrote: Here is a more detailed analysis of the problems my patch is supposed to solve. I added a few printk in the module to obtain some detailed timings. - DECODE is emited once at the begining of each call of ir_rc5_decode() to describe the blank or pulse event reported by ite_cir - FINISHED is emited during the last STATE_BIT_END when executing state=STATE_FINISHED - KEYDOWN is emited just before calling rc_keydown() - KEYUP is emited by ir_do_keyup() in rc-main.c The value following DECODE is the length of the pulse (+) or blank (-) as multiples of RC5_UNIT/10 (e.g. +20 means a pulse of 2*RC5_UNIT while -9 means a blank of 1*RC5_UNIT). The next value is that same length in microseconds. Here are the timings for a single 'even' RC-5 message (last bit is 0 so a blank followed by a pulse) using the original module: [507703.409737] DECODE +20 (1788us) [507703.412097] DECODE -19 (1762us) [507703.413282] DECODE +20 (1788us) [507703.415622] DECODE -19 (1762us) [507703.416822] DECODE +19 (1762us) [507703.419159] DECODE -20 (1788us) [507703.420357] DECODE +20 (1779us) [507703.421523] DECODE -9 (885us) [507703.422691] DECODE +10 (894us) [507703.423869] DECODE -19 (1771us) [507703.426239] DECODE +20 (1788us) [507703.427406] DECODE -19 (1762us) [507703.428639] DECODE +10 (894us) [507703.429772] DECODE -9 (877us) [507703.429779] DECODE +10 (894us) [507703.430946] DECODE -9 (885us) [507703.432131] DECODE +10 (894us) [507703.432138] FINISHED [507703.631331] DECODE -2255 (200317us) [507703.631338] KEYDOWN [507703.880020] KEYUP The last DECODE of 200ms is caused the timeout in the IR driver (see ITE_IDLE_TIMEOUT in ite_cir.h). The final STATE_BIT_END is processed before that long event is received but, because of the test after the 'goto again', the final STATE_FINISHED is delayed until the 200ms blank is received. It is important to notice that the KEYDOWN occurs 220ms after the first pulse and the keyup about 450ms after that the last pulse. The timings are similar for an odd RC-5 code (last bit is 1 so a pulse followed by a blank) [508157.054735] DECODE +19 (1762us) [508157.055906] DECODE -10 (929us) [508157.057098] DECODE +9 (868us) [508157.057107] DECODE -10 (911us) [508157.058259] DECODE +9 (842us) [508157.060730] DECODE -20 (1823us) [508157.061800] DECODE +19 (1762us) [508157.064167] DECODE -20 (1788us) [508157.065341] DECODE +19 (1727us) [508157.066507] DECODE -10 (937us) [508157.067686] DECODE +9 (868us) [508157.068932] DECODE -19 (1771us) [508157.071227] DECODE +20 (1779us) [508157.072423] DECODE -20 (1797us) [508157.073588] DECODE +9 (842us) [508157.074759] DECODE -10 (929us) [508157.075937] DECODE +19 (1736us) [508157.275149] DECODE -2252 (200039us) [508157.275156] FINISHED [508157.275159] KEYDOWN [508157.524021] KEYUP Here, the final STATE_BIT_END is a blank so it is processed as part of the final timeout. In any cases, the KEYDOWN in STATE_FINISHED occurs after the 200ms
Re: [PATCH 2/4] ARM: shmobile: r8a7779: add VIN support
Hi Sergei
From: Vladimir Barinov vladimir.bari...@cogentembedded.com
Add VIN clocks and platform devices for R8A7779 SoC; add function to register
the VIN platform devices.
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
[Sergei: renamed some variables]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
(snip)
+void __init r8a7779_add_vin_device(int id,
+struct rcar_vin_platform_data *pdata)
+{
+ vin_info_table[id]-data = pdata;
+ vin_info_table[id]-size_data = sizeof(struct rcar_vin_platform_data);
+
+ platform_device_register_full(vin_info_table[id]);
+}
Can you add id check here ?
BUG_ON(id 0 || id = ARRAY_SIZE(vin_info_table));
or similar
Best regards
---
Kuninori Morimoto
--
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: vb2: add length check for mmap
Oops, there is a issue.
vb2-core does not PAGE_ALIGN to length of buffer, but mmap() always do
PAGE_ALIGN to its length.
So non PAGE_ALIGN length of buffer from driver side can not mmaped with
this patch.
On 2013년 04월 12일 15:03, Marek Szyprowski wrote:
On 4/12/2013 5:57 AM, Seung-Woo Kim wrote:
The length of mmap() can be bigger than length of vb2 buffer, so
it should be checked.
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index db1235d..2c6ff2d 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1886,6 +1886,11 @@ int vb2_mmap(struct vb2_queue *q, struct
vm_area_struct *vma)
vb = q-bufs[buffer];
+if (vb-v4l2_planes[plane].length (vma-vm_end -
vma-vm_start)) {
+dprintk(1, Invalid length\n);
+return -EINVAL;
+}
+
ret = call_memop(q, mmap, vb-planes[plane].mem_priv, vma);
if (ret)
return ret;
Best regards
--
Seung-Woo Kim
Samsung Software RD Center
--
--
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 -next] [media] s5p-mfc: fix error return code in s5p_mfc_probe()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index e810b1a..a5853fa 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1110,7 +1110,8 @@ static int s5p_mfc_probe(struct platform_device *pdev)
}
if (pdev-dev.of_node) {
- if (s5p_mfc_alloc_memdevs(dev) 0)
+ ret = s5p_mfc_alloc_memdevs(dev);
+ if (ret 0)
goto err_res;
} else {
dev-mem_dev_l = device_find_child(dev-plat_dev-dev,
--
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] media: davinci: vpif: align the buffers size to page page size boundary
Hi Marek, On Tue, Apr 16, 2013 at 4:48 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Prabhakar, (CC'ing Marek) On Tuesday 16 April 2013 16:24:30 Prabhakar lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com with recent commit with id 068a0df76023926af958a336a78bef60468d2033 which adds add length check for mmap, the application were failing to mmap the buffers. This patch aligns the the buffer size to page size boundary for both capture and display driver so the it pass the check. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Hans Verkuil hans.verk...@cisco.com Cc: Mauro Carvalho Chehab mche...@redhat.com --- Changes for v2: 1: Fixed a typo in commit message. drivers/media/platform/davinci/vpif_capture.c |1 + drivers/media/platform/davinci/vpif_display.c |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c index 5f98df1..25981d6 100644 --- a/drivers/media/platform/davinci/vpif_capture.c +++ b/drivers/media/platform/davinci/vpif_capture.c @@ -183,6 +183,7 @@ static int vpif_buffer_queue_setup(struct vb2_queue *vq, *nbuffers = config_params.min_numbuffers; *nplanes = 1; + size = PAGE_ALIGN(size); I wonder if that's the best fix. The queue_setup operation is supposed to return the size required by the driver for each plane. Depending on the hardware requirements, that size might not be a multiple of the page size. As we can't mmap() a fraction of a page, the allocated plane size needs to be rounded up to the next page boundary to allow mmap() support. The dma-contig and dma-sg allocators already do so in their alloc operation, but the vmalloc allocator doesn't. The recent media: vb2: add length check for mmap patch verifies that the mmap() size requested by userspace doesn't exceed the buffer size. As the mmap() size is rounded up to the next page boundary the check will fail for buffer sizes that are not multiple of the page size. Your fix will not result in overallocation (as the allocator already rounds the size up), but will prevent the driver from importing a buffer large enough for the hardware but not rounded up to the page size. A better fix might be to round up the buffer size in the buffer size check at mmap() time, and fix the vmalloc allocator to round up the size. That the allocator, not drivers, is responsible for buffer size alignment should be documented in videobuf2-core.h. Do you plan to post a patch fixing it as per Laurent's suggestion ? Regards, --Prabhakar sizes[0] = size; alloc_ctxs[0] = common-alloc_ctx; diff --git a/drivers/media/platform/davinci/vpif_display.c b/drivers/media/platform/davinci/vpif_display.c index 1b3fb5c..3414715 100644 --- a/drivers/media/platform/davinci/vpif_display.c +++ b/drivers/media/platform/davinci/vpif_display.c @@ -162,6 +162,7 @@ static int vpif_buffer_queue_setup(struct vb2_queue *vq, *nbuffers = config_params.min_numbuffers; *nplanes = 1; + size = PAGE_ALIGN(size); sizes[0] = size; alloc_ctxs[0] = common-alloc_ctx; return 0; -- 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
