On Tue January 22 2013 22:02:08 Hans Verkuil wrote:
> This message is generated daily by a cron job that builds media_tree for
> the kernels and architectures in the list below.
>
> Results of the daily build of media_tree:
>
> date:Tue Jan 22 19:00:19 CET 2013
> git hash:f66d81b54dac
On Tue January 22 2013 20:46:21 Frank Schäfer wrote:
> tuner_g_tuner() is supposed to fill struct v4l2_tuner passed by ioctl
> VIDIOC_G_TUNER, but misses setting the name field.
>
> Signed-off-by: Frank Schäfer
> Cc: sta...@kernel.org
> ---
> drivers/media/v4l2-core/tuner-core.c |1 +
> 1 Da
On Tue January 22 2013 23:14:50 Mauro Carvalho Chehab wrote:
> Em Tue, 22 Jan 2013 20:51:55 +0100
> Frank Schäfer escreveu:
>
> > The buffer ioctls (VIDIOC_REQBUFS, VIDIOC_QUERYBUF, VIDIOC_QBUF,
> > VIDIOC_DQBUF,
> > VIDIOC_EXPBUF, VIDIOC_CREATE_BUFS, VIDIOC_PREPARE_BUF) are not applicable
> >
Hi Kamil,
On Tuesday 22 January 2013 11:24:09 Kamil Debski wrote:
> On Tuesday, January 22, 2013 11:03 AM Sakari Ailus wrote:
> > On Mon, Jan 21, 2013 at 03:07:55PM +0100, Kamil Debski wrote:
> > > On Saturday, January 19, 2013 6:43 PM Sakari Ailus wrote:
> > > > On Mon, Jan 14, 2013 at 10:36:04AM
Hi Paul,
On Tuesday 22 January 2013 02:57:22 Paul Walmsley wrote:
> On Mon, 21 Jan 2013, Laurent Pinchart wrote:
> > OK. The omap3isp patch can go through Paul's tree as well, it won't
> > conflict with other changes to the driver in this merge window.
> >
> > Paul, can you take both patches toge
Hi Adriano,
On Tuesday 22 January 2013 13:48:40 Adriano Martins wrote:
> 2013/1/22 Laurent Pinchart :
> > On Tuesday 22 January 2013 09:31:58 Adriano Martins wrote:
> >> Hello Laurent and all.
> >>
> >> Can you explain me what means the message in yavta output:
> >>
> >> "Unable to start streami
Em Tue, 22 Jan 2013 20:51:55 +0100
Frank Schäfer escreveu:
> The buffer ioctls (VIDIOC_REQBUFS, VIDIOC_QUERYBUF, VIDIOC_QBUF, VIDIOC_DQBUF,
> VIDIOC_EXPBUF, VIDIOC_CREATE_BUFS, VIDIOC_PREPARE_BUF) are not applicable for
> radio devices. Hence, they should be set valid only for non-radio devices i
On 01/21/2013 10:34 AM, Hans Verkuil wrote:
On Sat January 19 2013 22:27:22 Sylwester Nawrocki wrote:
This patch adds V4L2 sub-device driver for OV9650/OV9652 image sensors.
The driver exposes following V4L2 controls:
- auto/manual exposure,
- auto/manual white balance,
- auto/manual gain,
- br
On Mon, Jan 21, 2013 at 5:07 AM, Steffen Trumtrar
wrote:
> Hi!
>
> There was still no maintainer, that commented, ack'd, nack'd, apply'd the
> series. So, this is just a resend.
> The patches were tested with:
>
> - v15 on Tegra by Thierry
> - sh-mobile-lcdcfb by Laurent
>
On 01/21/2013 10:01 AM, Hans Verkuil wrote:
On Sat January 19 2013 22:27:20 Sylwester Nawrocki wrote:
Add common header file defining standard image sizes, so we can
avoid redefining those in each driver.
Signed-off-by: Sylwester Nawrocki
---
include/media/image-sizes.h | 34 +++
Hi Hans,
On 01/21/2013 09:25 AM, Hans Verkuil wrote:
Hi Sylwester!
On Sat January 19 2013 22:27:21 Sylwester Nawrocki wrote:
This patch adds a helper function that allows to modify range,
i.e. minimum, maximum, step and default value of a v4l2 control,
after the control has been created and in
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date:Tue Jan 22 19:00:19 CET 2013
git hash:f66d81b54dac26d4e601d4d7faca53f3bdc98427
gcc version: i686-linux-gcc (GCC
The buffer ioctls (VIDIOC_REQBUFS, VIDIOC_QUERYBUF, VIDIOC_QBUF, VIDIOC_DQBUF,
VIDIOC_EXPBUF, VIDIOC_CREATE_BUFS, VIDIOC_PREPARE_BUF) are not applicable for
radio devices. Hence, they should be set valid only for non-radio devices in
determine_valid_ioctls().
Signed-off-by: Frank Schäfer
---
dri
tuner_g_tuner() is supposed to fill struct v4l2_tuner passed by ioctl
VIDIOC_G_TUNER, but misses setting the name field.
Signed-off-by: Frank Schäfer
Cc: sta...@kernel.org
---
drivers/media/v4l2-core/tuner-core.c |1 +
1 Datei geändert, 1 Zeile hinzugefügt(+)
diff --git a/drivers/media/v4l2
Hi Hans,
Thanks for the comments!
On Tue, Jan 22, 2013 at 08:03:01PM +0100, Hans Verkuil wrote:
> On Tue January 22 2013 17:27:56 Sakari Ailus wrote:
> > Use the same handlers where the structs are the same. Implement a new
> > handler for link enumeration since struct media_links_enum is differe
On Tue January 22 2013 17:27:56 Sakari Ailus wrote:
> Use the same handlers where the structs are the same. Implement a new
> handler for link enumeration since struct media_links_enum is different on
> 32-bit and 64-bit systems.
I think I would prefer to have the compat handling split off into a
Am 22.01.2013 11:08, schrieb Mauro Carvalho Chehab:
> Em Mon, 21 Jan 2013 22:26:34 +0100
> Frank Schäfer escreveu:
>
>> Am 21.01.2013 14:51, schrieb Mauro Carvalho Chehab:
>> ,,,
The following kernel bugs can be closed as "resolved - fixed":
- bug 26572 "rmmod em28xx or unplugging em28xx
Am 21.01.2013 22:39, schrieb Hans Verkuil:
> On Mon January 21 2013 22:25:37 Frank Schäfer wrote:
>> Hi Hans,
>>
>> Am 21.01.2013 09:59, schrieb Hans Verkuil:
>>> On Sun January 20 2013 22:15:51 Frank Schäfer wrote:
Hi Hans,
I noticed that there's code in the v4l2 core that enables/d
Hi Kamil,
On Tue, Jan 22, 2013 at 06:58:09PM +0100, Kamil Debski wrote:
...
> > OTOH I'm not certain what's the main purpose of such copied timestamps,
> > is it to identify which CAPTURE buffer comes from which OUTPUT buffer ?
> >
>
> Yes, indeed. This is especially useful when the CAPTURE buff
Hi,
> From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com]
> Sent: Tuesday, January 22, 2013 11:38 AM
>
> Hi,
>
> On 01/21/2013 03:07 PM, Kamil Debski wrote:
> >> How about making MONOTONIC timestamps default instead, or at least
> >> assigning all drivers something else than UNKNOWN?
> >
> >
Hi Hans,
Thank you for your comments.
> From: Hans Verkuil [mailto:hansv...@cisco.com]
> Sent: Tuesday, January 22, 2013 11:35 AM
>
> On Tue 22 January 2013 11:03:03 'Sakari Ailus' wrote:
> > Hi Kamil,
> >
> > (Cc'ing Pawel and Marek as well.)
> >
> > On Mon, Jan 21, 2013 at 03:07:55PM +0100, Ka
Op 22-01-13 17:47, Francesco Lavra schreef:
> On 01/15/2013 01:34 PM, Maarten Lankhorst wrote:
>> This adds support for a generic reservations framework that can be
>> hooked up to ttm and dma-buf and allows easy sharing of reservations
>> across devices.
>>
>> The idea is that a dma-buf and ttm ob
New architectures such as 64-Bit arm build kernels without legacy
system calls - Such as the the no-at system calls. Thus, use
SYS_openat whenever it is available.
Signed-off-by: Riku Voipio
---
lib/libv4lconvert/libv4lsyscall-priv.h |5 +
1 file changed, 5 insertions(+)
diff --git a/li
On 01/15/2013 01:34 PM, Maarten Lankhorst wrote:
> This adds support for a generic reservations framework that can be
> hooked up to ttm and dma-buf and allows easy sharing of reservations
> across devices.
>
> The idea is that a dma-buf and ttm object both will get a pointer
> to a struct reserva
Add the logic to poll, reset counters and report the QoS stats
to the end user.
The idea is that the core will periodically poll the frontend for
the stats. The frontend may return -EBUSY, if the previous collect
didn't finish, or it may fill the cached data.
The value returned to the end user is a
Add Signal/Noise ratio measurement. On this device, a global measure
is taken by the demod. It also provides per-layer CNR measurements,
based on Modulation Error measures (MER).
Signed-off-by: Mauro Carvalho Chehab
---
v12: patch rebased and cleaned.
drivers/media/dvb-frontends/mb86a20s.c | 3
Add the methods to read bit error/bit count measurements from
mb86a20s. On ISDB-T devices, those reads are done per layer.
However, as userspace applications may not be aware of that,
add a global measure that will sum the bit errors and bit
counts for each layer, storing them into a global value.
The DVBv3 statistics parameters are limited on several ways:
- Doesn't provide any way to indicate the used measure,
so userspace need to guess how to calculate the measure;
- Only a limited set of stats are supported;
- Can't be called in a way to require them to
Do a better job on setting the bit error counters, in order to
have all layer measures to happen in a little less than one
second.
Signed-off-by: Mauro Carvalho Chehab
---
v12: some improvements:
- Add a macro that defines the desired time for the bit count registers;
- Don't divide the counter
Instead of providing separate callbacks to read the several FE
stats properties, the better seems to use just one method that will:
- Read lock status;
- Read signal strength;
- if locked, get TMCC data;
- if locked, get DVB statistics.
As the DVB frontend thread will call this
Thanks, Andrzej!
On Tue, Jan 22, 2013 at 09:24:55AM +0100, Andrzej Hajda wrote:
> Function media_entity_remote_source actually returns the remote pad to
> the given one, regardless if this is the source or the sink pad.
> Name media_entity_remote_pad is more adequate for this function.
>
> Signed
Use the same handlers where the structs are the same. Implement a new
handler for link enumeration since struct media_links_enum is different on
32-bit and 64-bit systems.
Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
Tested-by: Laurent Pinchart
---
drivers/media/media-device.c | 102
Provide an ioctl handler for 32-bit binaries on 64-bit systems.
Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
Tested-by: Laurent Pinchart
---
drivers/media/media-devnode.c | 31 ---
include/media/media-devnode.h |1 +
2 files changed, 29 insertions(+)
Hi,
I noticed recently that we're missing the compat IOCTL handling in Media
controller API to support 32-bit binaries on 64-bit systems. I guess the
issue hasn't bitten anyone too badly since this hasn't been noticed earlier.
I can think of the reasons, too: Media controller is primarily used on
Hi Laurent,
2013/1/22 Laurent Pinchart :
> Hi Adriano,
>
> On Tuesday 22 January 2013 09:31:58 Adriano Martins wrote:
>> Hello Laurent and all.
>>
>> Can you explain me what means the message in yavta output:
>>
>> "Unable to start streaming: Broken pipe (32)."
>
> This means that the ISP hardware
On Tuesday 22 January 2013, Sascha Hauer wrote:
> On Mon, Jan 21, 2013 at 05:16:02PM +, Arnd Bergmann wrote:
> > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > header file "mach/iram.h". This is not available when building for
> > multiplatform, so let us disable thi
Hi Adriano,
On Tuesday 22 January 2013 09:31:58 Adriano Martins wrote:
> Hello Laurent and all.
>
> Can you explain me what means the message in yavta output:
>
> "Unable to start streaming: Broken pipe (32)."
This means that the ISP hardware pipeline hasn't been properly configured.
Unlike mo
Hi,
On 01/15/2013 01:34 PM, Maarten Lankhorst wrote:
[...]
> diff --git a/include/linux/fence.h b/include/linux/fence.h
> new file mode 100644
> index 000..d9f091d
> --- /dev/null
> +++ b/include/linux/fence.h
> @@ -0,0 +1,347 @@
> +/*
> + * Fence mechanism for dma-buf to allow for asynchronou
Devin Heitmueller wrote:
On Tue, Jan 22, 2013 at 4:38 AM, Jan Stumpf wrote:
Thanks!
I will try it with your patches!
Regards
Jan
FYI: the cx231xx driver has worked in the past on ARM platforms,
although I haven't tried the USBLive2 on OMAP specifically. In fact,
I merged the origi
On Sat, 19 Jan 2013 14:33:07 -0200
Peter Senna Tschudin wrote:
> replace:
> #if defined(CONFIG_VIDEOBUF2_VMALLOC) || \
> defined(CONFIG_VIDEOBUF2_VMALLOC_MODULE)
> with:
> #if IS_ENABLED(CONFIG_VIDEOBUF2_VMALLOC)
>
> This change was made for: CONFIG_VIDEOBUF2_VMALLOC,
> CONFIG_VIDEOBUF2_D
On Tue, Jan 22, 2013 at 4:38 AM, Jan Stumpf wrote:
> Thanks!
>
> I will try it with your patches!
>
> Regards
> Jan
FYI: the cx231xx driver has worked in the past on ARM platforms,
although I haven't tried the USBLive2 on OMAP specifically. In fact,
I merged the original driver support upstream
Em Tue, 22 Jan 2013 10:32:07 +
James Bottomley escreveu:
> On Tue, 2013-01-22 at 10:16 +, James Bottomley wrote:
> > [adding Mauro and v4l since they're the only non-arm consumers]
> > On Tue, 2013-01-22 at 10:13 +, James Bottomley wrote:
> > > On Mon, 2013-01-21 at 22:59 +, James
On 21/01/2013, Mauro Carvalho Chehab wrote:
> Em Mon, 21 Jan 2013 15:47:49 +
> Mike Martin escreveu:
>
>> After updating the kernel on Fedora 18 module dvb-usb-it913x seems to
>> have dissapeared.
>>
>> This has meant my dvb stick ( ID 1b80:e409 Afatech IT9137FN Dual DVB-T
>> [KWorld UB499-2T
Hi James,
Em Tue, 22 Jan 2013 10:16:48 +
James Bottomley escreveu:
> [adding Mauro and v4l since they're the only non-arm consumers]
> On Tue, 2013-01-22 at 10:13 +, James Bottomley wrote:
> > On Mon, 2013-01-21 at 22:59 +, James Bottomley wrote:
> > > On Mon, 2013-01-21 at 21:00 +01
Em Tue, 22 Jan 2013 10:32:22 -0200
Mauro Carvalho Chehab escreveu:
> Em Tue, 22 Jan 2013 11:54:04 +0800
> Shawn Guo escreveu:
>
> > On Mon, Jan 21, 2013 at 05:16:02PM +, Arnd Bergmann wrote:
> > > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > > header file "mach
Em Tue, 22 Jan 2013 11:54:04 +0800
Shawn Guo escreveu:
> On Mon, Jan 21, 2013 at 05:16:02PM +, Arnd Bergmann wrote:
> > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > header file "mach/iram.h". This is not available when building for
> > multiplatform, so let us di
Em Thu, 17 Jan 2013 21:11:08 +0200
Antti Palosaari escreveu:
> On 01/17/2013 08:50 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 18 Jan 2013 00:07:17 +0530
> > Manu Abraham escreveu:
> >
> >> On Thu, Jan 17, 2013 at 11:57 PM, Antti Palosaari wrote:
> >>
> >>>
> >>>
> >>> Resetting counters when
On Tue 22 January 2013 06:19:50 Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> The current code was implemented with some default configurations,
> this default configuration works on board and doesn't work on other.
>
> This patch accepts the configuration through platform data and configures
Instead of having its own set of macros, use the Kernel default
ones for debug, error and info.
While here, do some cleanup on the debug printk's.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 96 ++
1 file changed, 52 insertio
Split the logic that reads the status from the DVB callback. That
helps to properly return an error code, if status read fails.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
Get the proper bits from the TMCC table registers.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb8
It is recommented to change register 0x0440 value to 0, in order
to fix some AGC bug.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-
Reorder functions to have everything related to stats/status read
close. That will make the file more organized as other stats
routines will be added.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 215 +
The read/write errors are not handled well on get_frontend. Fix it,
by letting the frontend cached values to represent the DVB properties
that were successfully retrieved.
While here, use "c" for dtv_frontend_properties cache, instead of
"p", as this is more common.
Signed-off-by: Mauro Carvalho C
If an error happens, restore tuner I2C gate to the right
value.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb86a20s.
Hi,
On 01/21/2013 11:09 AM, Thierry Reding wrote:
> Convert all uses of devm_request_and_ioremap() to the newly introduced
> devm_ioremap_resource() which provides more consistent error handling.
>
> devm_ioremap_resource() provides its own error messages so all explicit
> error messages can be r
Hi,
On 01/21/2013 03:07 PM, Kamil Debski wrote:
>> How about making MONOTONIC timestamps default instead, or at least
>> assigning all drivers something else than UNKNOWN?
>
> So why did you add the UNKNOWN flag?
>
> The way I see it - UNKNOWN is the default and the one who coded the driver
> wi
On Tue 22 January 2013 11:03:03 'Sakari Ailus' wrote:
> Hi Kamil,
>
> (Cc'ing Pawel and Marek as well.)
>
> On Mon, Jan 21, 2013 at 03:07:55PM +0100, Kamil Debski wrote:
> > Hi,
> >
> > > From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
> > > Sent: Saturday, January 19, 2013 6:43 PM
> > > Hi Kami
On Tue, 2013-01-22 at 10:16 +, James Bottomley wrote:
> [adding Mauro and v4l since they're the only non-arm consumers]
> On Tue, 2013-01-22 at 10:13 +, James Bottomley wrote:
> > On Mon, 2013-01-21 at 22:59 +, James Bottomley wrote:
> > > On Mon, 2013-01-21 at 21:00 +0100, Geert Uytter
Hi Sakari,
Thank you for your quick reply.
> From: 'Sakari Ailus' [mailto:sakari.ai...@iki.fi]
> Sent: Tuesday, January 22, 2013 11:03 AM
> Hi Kamil,
>
> (Cc'ing Pawel and Marek as well.)
>
> On Mon, Jan 21, 2013 at 03:07:55PM +0100, Kamil Debski wrote:
> > Hi,
> >
> > > From: Sakari Ailus [mai
[adding Mauro and v4l since they're the only non-arm consumers]
On Tue, 2013-01-22 at 10:13 +, James Bottomley wrote:
> On Mon, 2013-01-21 at 22:59 +, James Bottomley wrote:
> > On Mon, 2013-01-21 at 21:00 +0100, Geert Uytterhoeven wrote:
> > > On Tue, Jan 15, 2013 at 5:56 PM, James Bottoml
Em Mon, 21 Jan 2013 22:26:34 +0100
Frank Schäfer escreveu:
> Am 21.01.2013 14:51, schrieb Mauro Carvalho Chehab:
> ,,,
> >> The following kernel bugs can be closed as "resolved - fixed":
> >> - bug 26572 "rmmod em28xx or unplugging em28xx tv adapter problem"
> >> => resolved with commit 05fe217
Hi Kamil,
(Cc'ing Pawel and Marek as well.)
On Mon, Jan 21, 2013 at 03:07:55PM +0100, Kamil Debski wrote:
> Hi,
>
> > From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
> > Sent: Saturday, January 19, 2013 6:43 PM
> > Hi Kamil,
> >
> > Thanks for the patch.
> >
> > On Mon, Jan 14, 2013 at 10:36:0
Hi,
On 01/21/2013 01:51 PM, Peter Senna Tschudin wrote:
On Mon, Jan 21, 2013 at 10:47 AM, Hans de Goede wrote:
Hi,
Thanks for the patches I'll pick up 5 - 21 and add them to
my tree for Mauro.
I have sent V2 of this patches with another subject and with fixed
commit message for two patches.
Hi,
One more comment. Also adding videobuf2 maintainers to CC, as they were not
added in the patch "v4l: Tell user space we're using monotonic timestamps".
> From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
> Sent: Saturday, January 19, 2013 6:43 PM
>
> Hi Kamil,
>
> Thanks for the patch.
>
> O
Thanks!
I will try it with your patches!
Regards
Jan
-Ursprüngliche Nachricht-
Von: linux-media-ow...@vger.kernel.org
[mailto:linux-media-ow...@vger.kernel.org] Im Auftrag von Hans Verkuil
Gesendet: Montag, 21. Januar 2013 10:54
An: Jan Stumpf
Cc: linux-media@vger.kernel.org
Betreff: Re
Hi,
Thanks for the patch.
Best wishes,
--
Kamil Debski
Linux Platform Group
Samsung Poland R&D Center
> -Original Message-
> From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
> Sent: Tuesday, January 22, 2013 6:00 AM
> To: linux-media@vger.kernel.org
> Cc: k.deb...@samsung.com; s.na
Function media_entity_remote_source actually returns the remote pad to
the given one, regardless if this is the source or the sink pad.
Name media_entity_remote_pad is more adequate for this function.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
Documentation/media-framework.tx
On Mon, Jan 21, 2013 at 05:16:02PM +, Arnd Bergmann wrote:
> The coda video codec driver depends on a mach-imx or mach-mxs specific
> header file "mach/iram.h". This is not available when building for
> multiplatform, so let us disable this driver for v3.8 when building
> multiplatform, and hop
69 matches
Mail list logo
