On 04/10/2014 02:46 AM, Pawel Osciak wrote:
Looks good to me, just a small nit below.
On Mon, Apr 7, 2014 at 10:11 PM, Hans Verkuil hverk...@xs4all.nl wrote:
From: Hans Verkuil hans.verk...@cisco.com
The videobuf2-core did not zero the 'planes' array in __qbuf_userptr()
and
This patch fixes jpeg sysmmu page fault on Exynos4x12 SoCs.
During encoding Exynos4x12 SoCs access wider memory area
than it results from Image_x and Image_y values written to
the JPEG_IMAGE_SIZE register. In order to avoid sysmmu page
fault apply proper output buffer size alignment.
Remove erroneous guard preventing successful execution of
g_selection callback in case the driver variant is different
from SJPEG_S5P.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-jpeg/jpeg-core.c |
Prevent decompression of a JPEG 4:2:0 with odd width to
the YUV 4:2:0 compliant formats for Exynos4x12 SoCs and
adjust capture format to RGB565 in such a case. This is
required because the configuration would produce a raw
image with broken luma component.
Signed-off-by: Jacek Anaszewski
Change the driver variant check from is not S5PC210
to is Exynos4 while checking whether YUV format needs
to be downgraded in order to prevent upsampling which
is not supported by Exynos4 SoCs family.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park
Simplify the code by adding m2m_ops field to the
s5p_jpeg_variant structure which allows to avoid
if statement in the s5p_jpeg_probe function.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Simplify the code by adding fmt_ver_flag field
to the s5p_jpeg_variant structure which allows
to avoid if statement in the s5p_jpeg_find_format
function.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
This patch fixes build break occurring when
there is no support for Device Tree turned on
in the kernel configuration. In such a case only
the driver variant for S5PC210 SoC will be available.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park
S5PC210 SoC doesn't support encoding NV12 raw images. Remove
the relavant flag from the respective entry in the sjpeg_formats
array.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-jpeg/jpeg-core.c |
On Thu, Apr 10, 2014 at 01:30:06AM +0200, Javier Martinez Canillas wrote:
commit c0b00a5 (dma-buf: update debugfs output) modified the
default exporter name to be the KBUILD_MODNAME pre-processor
macro instead of __FILE__ but the documentation was not updated.
Also the Supporting existing
Hi!
Ugh. This became more complicated than I thought, but I'm OK with moving
TTM over to fence while we sort out
how / if we're going to use this.
While reviewing, it struck me that this is kind of error-prone, and hard
to follow since we're operating on a structure that may be
continually
tcm825x.c and tcm825x.h:
fixing ERROR: Macros with complex values should be enclosed in parenthesis
Signed-off-by: Vitaly Osipov vitaly.osi...@gmail.com
---
drivers/staging/media/omap24xx/tcm825x.c |8
drivers/staging/media/omap24xx/tcm825x.h |4 ++--
2 files changed, 6
tcm825x.c:
changed printk to pr_info
Signed-off-by: Vitaly Osipov vitaly.osi...@gmail.com
---
drivers/staging/media/omap24xx/tcm825x.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/omap24xx/tcm825x.c
b/drivers/staging/media/omap24xx/tcm825x.c
The two subjects are really close to being the same. You should choose
better subjects. Like:
[PATCH 2/2] staging: media: omap24xx: use pr_info() instead of KERN_INFO
(All the checkpatch.pl people use the exact same subject for everything
though, so you're not alone in this).
regards,
dan
Hello,
On 2014-03-17 20:49, Jan Kara wrote:
The following patch series is my first stab at abstracting vma handling
from the various media drivers. After this patch set drivers have to know
much less details about vmas, their types, and locking. My motivation for
the series is that I want to
Hey,
op 10-04-14 10:46, Thomas Hellstrom schreef:
Hi!
Ugh. This became more complicated than I thought, but I'm OK with moving
TTM over to fence while we sort out
how / if we're going to use this.
While reviewing, it struck me that this is kind of error-prone, and hard
to follow since we're
Hello,
On Thu 10-04-14 12:02:50, Marek Szyprowski wrote:
On 2014-03-17 20:49, Jan Kara wrote:
The following patch series is my first stab at abstracting vma handling
from the various media drivers. After this patch set drivers have to know
much less details about vmas, their types, and
Hi Guys,
Sorry to go on about the Hauppauge ImpactVCB-e 01385, but it's a couple
of years and version 12.04, since I last asked.
This page:
http://linuxtv.org/wiki/index.php/Hauppauge
Now shows:
Table of analog-only devices sold by Hauppauge Model Standard Interface
Supported Comments
- Construct string with (dev is struct em28xx *dev)
format: tuner:%s-%s-%d
with the following:
dev_name(dev-udev-dev)
dev-udev-bus-bus_name
dev-tuner_addr
What guarantees this won't get confused by hot
On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
Hey,
op 10-04-14 10:46, Thomas Hellstrom schreef:
Hi!
Ugh. This became more complicated than I thought, but I'm OK with moving
TTM over to fence while we sort out
how / if we're going to use this.
While reviewing, it struck me that this is
On 04/10/14 12:32, Jan Kara wrote:
Hello,
On Thu 10-04-14 12:02:50, Marek Szyprowski wrote:
On 2014-03-17 20:49, Jan Kara wrote:
The following patch series is my first stab at abstracting vma handling
from the various media drivers. After this patch set drivers have to know
much less
On 04/10/2014 01:08 PM, Thomas Hellstrom wrote:
On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
Hey,
op 10-04-14 10:46, Thomas Hellstrom schreef:
Hi!
Ugh. This became more complicated than I thought, but I'm OK with moving
TTM over to fence while we sort out
how / if we're going to use
Hi Alan,
Em Thu, 10 Apr 2014 12:04:35 +0100
One Thousand Gnomes gno...@lxorguk.ukuu.org.uk escreveu:
- Construct string with (dev is struct em28xx *dev)
format: tuner:%s-%s-%d
with the following:
dev_name(dev-udev-dev)
For example, some devices provide standard USB Audio Class, handled by
snd-usb-audio for the audio stream, while the video stream is handled
via a separate driver, like some em28xx devices.
Which is what mfd is designed to handle.
There are even more complex devices that provide 3G modem,
Thanks, that's helpful - I for some reason thought that multi-part
patch had to have more or less uniform subject. We the checkpatch.pl
people come from http://www.eudyptula-challenge.org/, where at some
stage we are told to submit a patch for a single style issue in the
staging tree. All
The following changes since commit a83b93a7480441a47856dc9104bea970e84cda87:
[media] em28xx-dvb: fix PCTV 461e tuner I2C binding (2014-03-31
08:02:16 -0300)
are available in the git repository at:
git://linuxtv.org/anttip/media_tree.git fixes3.15_rtl2832_sdr_attach
for you to fetch
On Thu 10-04-14 13:07:42, Hans Verkuil wrote:
On 04/10/14 12:32, Jan Kara wrote:
Hello,
On Thu 10-04-14 12:02:50, Marek Szyprowski wrote:
On 2014-03-17 20:49, Jan Kara wrote:
The following patch series is my first stab at abstracting vma handling
from the various media drivers.
On 04/10/14 14:15, Jan Kara wrote:
On Thu 10-04-14 13:07:42, Hans Verkuil wrote:
On 04/10/14 12:32, Jan Kara wrote:
Hello,
On Thu 10-04-14 12:02:50, Marek Szyprowski wrote:
On 2014-03-17 20:49, Jan Kara wrote:
The following patch series is my first stab at abstracting vma handling
from
On Thu, Apr 10, 2014 at 09:57:23PM +1000, Vitaly Osipov wrote:
Thanks, that's helpful - I for some reason thought that multi-part
patch had to have more or less uniform subject. We the checkpatch.pl
people come from http://www.eudyptula-challenge.org/, where at some
stage we are told to submit
On 04/10/2014 05:38 AM, Mauro Carvalho Chehab wrote:
Hi Alan,
Em Thu, 10 Apr 2014 12:04:35 +0100
One Thousand Gnomes gno...@lxorguk.ukuu.org.uk escreveu:
- Construct string with (dev is struct em28xx *dev)
format: tuner:%s-%s-%d
with the following:
Em Thu, 10 Apr 2014 12:46:53 +0100
One Thousand Gnomes gno...@lxorguk.ukuu.org.uk escreveu:
For example, some devices provide standard USB Audio Class, handled by
snd-usb-audio for the audio stream, while the video stream is handled
via a separate driver, like some em28xx devices.
Which
op 10-04-14 13:08, Thomas Hellstrom schreef:
On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
Hey,
op 10-04-14 10:46, Thomas Hellstrom schreef:
Hi!
Ugh. This became more complicated than I thought, but I'm OK with moving
TTM over to fence while we sort out
how / if we're going to use this.
When I plug in my 01385 I get the same old stuff in dmseg, ie:
cx23885 driver version 0.0.3 loaded
[ 8.921390] cx23885[0]: Your board isn't known (yet) to the driver.
[ 8.921390] cx23885[0]: Try to pick one of the existing card configs via
[ 8.921390] cx23885[0]: card=n insmod option.
The issue is nobody cares enough to
update the driver to support
your card and make it work out of the box.
Hi Steve,
Thanks for your response.
Well not nobody because I do. How do I do it? If you would guide me through, I
will happily update it.
Regards
Steve.
Steven Toth
Hi Steve,
Well not nobody because I do. How do I do it? If you would guide me through,
I will happily update it.
I seem to recall Kernel Labs offered you some commercial help with
this product in the past and you declined, you apparently wanted to
tackle it on your own. How's it coming
Laurent Pinchart wrote:
On Saturday 01 March 2014 18:18:04 Sakari Ailus wrote:
The option is --output, or -o.
Wouldn't it make sense to have an option to force the device type to a user-
specified value instead of just an option for the output type ? -o is also
usually used to select an
Hi Laurent,
Thanks for the comments.
Laurent Pinchart wrote:
...
@@ -196,6 +192,16 @@ static int video_open(struct device *dev, const char
*devname, int no_query)
printf(Device %s opened.\n, devname);
+ dev-opened = 1;
+
+ return 0;
+}
+
+static int video_querycap(struct
Hi Mauro,
The following changes since commit a83b93a7480441a47856dc9104bea970e84cda87:
[media] em28xx-dvb: fix PCTV 461e tuner I2C binding (2014-03-31 08:02:16
-0300)
are available in the git repository at:
git://linuxtv.org/pinchartl/media.git vsp1/next
for you to fetch changes up to
Hi Laurent,
Laurent Pinchart wrote:
...
@@ -1298,7 +1302,8 @@ static struct option opts[] = {
{sleep-forever, 0, 0, OPT_SLEEP_FOREVER},
{stride, 1, 0, OPT_STRIDE},
{time-per-frame, 1, 0, 't'},
- {userptr, 0, 0, 'u'},
+ {timestamp-source, 1, 0,
Hi Laurent,
Laurent Pinchart wrote:
Hi Sakari,
Thank you for the patch.
Given that the timestamp type and source are not supposed to change during
streaming, do we really need to print them for every frame ?
When processing frames from memory to memory (COPY timestamp type), the
it is
Hi Bryan,
On Tue, 8 Apr 2014, Bryan Wu wrote:
Thanks Josh, I think I will take you point and rework my patch again.
But I need Guennadi's review firstly, Guennadi, could you please help
to review it?
Ok, let me double check the situation:
1. We've got this patch from you, aiming at adding
On Friday 04 April 2014 01:34:43 David Härdeman wrote:
Having a mutex named lock is a bit misleading.
Why? A mutex is a type of lock so what's the problem?
A little grep'ing and sed'ing reveals that out of the 1578 unique mutex names
in the kernel source I have to hand, 540 contain lock, and
On Thu 10-04-14 14:22:20, Hans Verkuil wrote:
On 04/10/14 14:15, Jan Kara wrote:
On Thu 10-04-14 13:07:42, Hans Verkuil wrote:
On 04/10/14 12:32, Jan Kara wrote:
Hello,
On Thu 10-04-14 12:02:50, Marek Szyprowski wrote:
On 2014-03-17 20:49, Jan Kara wrote:
The following patch
Instead of guessing the queue type, allow setting it explicitly.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
yavta.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/yavta.c b/yavta.c
index 739463d..d7bccfd 100644
--- a/yavta.c
+++ b/yavta.c
@@
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
yavta.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/yavta.c b/yavta.c
index 6f80311..a2e0666 100644
--- a/yavta.c
+++ b/yavta.c
@@ -72,6 +72,7 @@ struct device
unsigned int width;
unsigned int
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
yavta.c | 78 ++-
1 file changed, 42 insertions(+), 36 deletions(-)
diff --git a/yavta.c b/yavta.c
index 5a35bab..12a6719 100644
--- a/yavta.c
+++ b/yavta.c
@@ -220,12 +220,8 @@
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
yavta.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/yavta.c b/yavta.c
index 9810dcf..124dd1d 100644
--- a/yavta.c
+++ b/yavta.c
@@ -668,6 +668,9 @@ static void get_ts_flags(uint32_t flags, const char
**ts_type, const char **ts_s
Copy timestamp type will mean the timestamp is be copied from the source to
the destination buffer on mem-to-mem devices.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
yavta.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/yavta.c b/yavta.c
index
This makes comparisons nicer.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
yavta.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/yavta.c b/yavta.c
index 18e1709..5a35bab 100644
--- a/yavta.c
+++ b/yavta.c
@@ -64,7 +64,7 @@ struct device
{
int fd;
-
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
yavta.c | 46 +++---
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/yavta.c b/yavta.c
index 12a6719..6f80311 100644
--- a/yavta.c
+++ b/yavta.c
@@ -63,6 +63,7 @@ struct buffer
struct
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
yavta.c | 52 ++--
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/yavta.c b/yavta.c
index a2e0666..9810dcf 100644
--- a/yavta.c
+++ b/yavta.c
@@ -659,6 +659,30 @@ static void
This is necessary since video_open() may not be always called soon
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
yavta.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/yavta.c b/yavta.c
index d7bccfd..18e1709 100644
--- a/yavta.c
+++ b/yavta.c
@@ -226,7 +226,6 @@
Hi Sakari,
On Thursday 10 April 2014 21:48:55 Sakari Ailus wrote:
Hi Laurent,
Thanks for the comments.
Laurent Pinchart wrote:
...
@@ -196,6 +192,16 @@ static int video_open(struct device *dev, const char
*devname, int no_query)
printf(Device %s opened.\n, devname);
+
On Thu 10-04-14 23:57:38, Jan Kara wrote:
On Thu 10-04-14 14:22:20, Hans Verkuil wrote:
On 04/10/14 14:15, Jan Kara wrote:
On Thu 10-04-14 13:07:42, Hans Verkuil wrote:
On 04/10/14 12:32, Jan Kara wrote:
Hello,
On Thu 10-04-14 12:02:50, Marek Szyprowski wrote:
On 2014-03-17
Hi,
Sakari Ailus wrote:
Instead of guessing the queue type, allow setting it explicitly.
These got out a little bit too fast... what would you expect git
send-email to do if you press ^C?
Changes since v1:
- Replace --output (-o, for which getopt handling was actually missing)
option
On Thursday 10 April 2014 21:58:41 Sakari Ailus wrote:
Laurent Pinchart wrote:
Hi Sakari,
Thank you for the patch.
Given that the timestamp type and source are not supposed to change during
streaming, do we really need to print them for every frame ?
When processing frames from
Hi Laurent,
Laurent Pinchart wrote:
Just thinking out loud, we need to
- initialize the device structure,
- open the device or use an externally provided fd,
- optionally query the device capabilities,
- optionally override the queue type.
Initializing the device structure must be performed
Laurent Pinchart wrote:
On Thursday 10 April 2014 21:58:41 Sakari Ailus wrote:
Laurent Pinchart wrote:
Hi Sakari,
Thank you for the patch.
Given that the timestamp type and source are not supposed to change during
streaming, do we really need to print them for every frame ?
When processing
On Tue, Mar 25, 2014 at 01:18:22PM +0100, Laurent Pinchart wrote:
Hello,
Gentle ping. I'll send a pull request in a week if I don't receive any
comment
on the DT bindings in the meantime.
Hi Laurent,
one way or another can you let me know if/when the bindings are
accepted and I'll
Hi Simon,
On Friday 11 April 2014 08:04:18 Simon Horman wrote:
On Tue, Mar 25, 2014 at 01:18:22PM +0100, Laurent Pinchart wrote:
Hello,
Gentle ping. I'll send a pull request in a week if I don't receive any
comment on the DT bindings in the meantime.
Hi Laurent,
one way or another
On Fri, Apr 11, 2014 at 01:37:11AM +0200, Laurent Pinchart wrote:
Hi Simon,
On Friday 11 April 2014 08:04:18 Simon Horman wrote:
On Tue, Mar 25, 2014 at 01:18:22PM +0100, Laurent Pinchart wrote:
Hello,
Gentle ping. I'll send a pull request in a week if I don't receive any
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: Fri Apr 11 04:00:16 CEST 2014
git branch: test
git hash: a83b93a7480441a47856dc9104bea970e84cda87
gcc
Hi, Guennadi
On 4/11/2014 5:18 AM, Guennadi Liakhovetski wrote:
Hi Bryan,
On Tue, 8 Apr 2014, Bryan Wu wrote:
Thanks Josh, I think I will take you point and rework my patch again.
But I need Guennadi's review firstly, Guennadi, could you please help
to review it?
Ok, let me double check the
63 matches
Mail list logo
