On 3/9/2017 18:57, Hans Verkuil wrote:
Hi Songjun,
On 08/03/17 03:25, Wu, Songjun wrote:
Hi Colin,
Thank you for your comment.
It is a bug, will be fixed in the next patch.
Do you mean that you will provide a new patch for this? Is there anything
wrong with this patch? It seems reasonable
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: Mon Mar 13 05:00:14 CET 2017
media-tree git hash:700ea5e0e0dd70420a04e703ff264cc133834cba
media_build git
On 03/12/2017 01:22 PM, Russell King - ARM Linux wrote:
On Sun, Mar 12, 2017 at 01:05:06PM -0700, Steve Longerbeam wrote:
On 03/12/2017 12:57 PM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 04:30:53PM -0800, Steve Longerbeam wrote:
If it's too difficult to get the imx219 csi-2
On Sun, 2017-03-12 at 16:13 -0400, Jérémy Lefaure wrote:
> The driver uses kzalloc and kfree functions. So it should include
> linux/slab.h. This header file is implicitly included by v4l2-common.h
> if CONFIG_SPI is enabled. But when it is disabled, slab.h is not
> included. In this case, the driv
On 3/9/2017 19:50, Colin Ian King wrote:
On 09/03/17 11:49, walter harms wrote:
Am 09.03.2017 11:57, schrieb Hans Verkuil:
Hi Songjun,
On 08/03/17 03:25, Wu, Songjun wrote:
Hi Colin,
Thank you for your comment.
It is a bug, will be fixed in the next patch.
Do you mean that you will pro
Em Sun, 12 Mar 2017 14:16:56 +0100
Geert Uytterhoeven escreveu:
> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Javier Martinez Canillas
> Cc: Mauro Carvalho Chehab
As the T
Em Sun, 12 Mar 2017 22:29:04 +0100
Pavel Machek escreveu:
> Mid-layer is difficult... there are _hundreds_ of possible
> pipeline setups. If it should live in kernel or in userspace is a
> question... but I don't think having it in kernel helps in any way.
Mid-layer is difficult, because we eith
Em Sun, 12 Mar 2017 21:13:24 +
Russell King - ARM Linux escreveu:
> On Sun, Mar 12, 2017 at 05:59:28PM -0300, Mauro Carvalho Chehab wrote:
> > Yet, udev/systemd has some rules that provide an unique name for V4L
> > devices at /lib/udev/rules.d/60-persistent-v4l.rules. Basically, it
> > runs
Em Sun, 12 Mar 2017 10:56:53 -0700
Steve Longerbeam escreveu:
> On 03/11/2017 11:37 PM, Russell King - ARM Linux wrote:
> > On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote:
> > Given what Mauro has said, I'm convinced that the media controller stuff
> > is a complete failure f
On Sat 2017-03-11 23:14:56, Russell King - ARM Linux wrote:
> On Sat, Mar 11, 2017 at 08:25:49AM -0300, Mauro Carvalho Chehab wrote:
> > This situation is there since 2009. If I remember well, you tried to write
> > such generic plugin in the past, but never finished it, apparently because
> > it i
On Sun, Mar 12, 2017 at 05:59:28PM -0300, Mauro Carvalho Chehab wrote:
> Yet, udev/systemd has some rules that provide an unique name for V4L
> devices at /lib/udev/rules.d/60-persistent-v4l.rules. Basically, it
> runs a small application (v4l_id) with creates a persistent symling
> using rules lik
On Sun, Mar 12, 2017 at 08:40:37PM +, Russell King - ARM Linux wrote:
> On Sun, Mar 12, 2017 at 01:36:32PM -0700, Steve Longerbeam wrote:
> > But hold on, if my logic is correct, then why did the CSI power-off
> > get reached in your case, multiple times? Yes I think there is a bug,
> > link_no
Em Sun, 12 Mar 2017 19:47:00 +
Russell King - ARM Linux escreveu:
> Another issue.
>
> The "reboot and the /dev/video* devices come up in a completely
> different order" problem seems to exist with this version.
>
> The dot graph I supplied previously had "ipu1_csi0 capture" on
> /dev/video
On Sun, Mar 12, 2017 at 01:36:32PM -0700, Steve Longerbeam wrote:
> But hold on, if my logic is correct, then why did the CSI power-off
> get reached in your case, multiple times? Yes I think there is a bug,
> link_notify() is not checking if the link has already been disabled.
> I will fix this. B
On 03/12/2017 01:36 PM, Steve Longerbeam wrote:
On 03/12/2017 01:16 PM, Steve Longerbeam wrote:
On 03/12/2017 12:44 PM, Steve Longerbeam wrote:
On 03/12/2017 12:29 PM, Russell King - ARM Linux wrote:
On Sun, Mar 12, 2017 at 12:21:45PM -0700, Steve Longerbeam wrote:
There's actually no
On 03/12/2017 01:16 PM, Steve Longerbeam wrote:
On 03/12/2017 12:44 PM, Steve Longerbeam wrote:
On 03/12/2017 12:29 PM, Russell King - ARM Linux wrote:
On Sun, Mar 12, 2017 at 12:21:45PM -0700, Steve Longerbeam wrote:
There's actually nothing preventing userland from disabling a link
mul
On Sun, Mar 12, 2017 at 01:05:06PM -0700, Steve Longerbeam wrote:
>
>
> On 03/12/2017 12:57 PM, Russell King - ARM Linux wrote:
> >On Sat, Mar 11, 2017 at 04:30:53PM -0800, Steve Longerbeam wrote:
> >>If it's too difficult to get the imx219 csi-2 transmitter into the
> >>LP-11 state on power on,
The driver uses kzalloc and kfree functions. So it should include
linux/slab.h. This header file is implicitly included by v4l2-common.h
if CONFIG_SPI is enabled. But when it is disabled, slab.h is not
included. In this case, the driver does not compile:
drivers/media/platform/mtk-jpeg/mtk_jpeg_co
On 03/12/2017 12:44 PM, Steve Longerbeam wrote:
On 03/12/2017 12:29 PM, Russell King - ARM Linux wrote:
On Sun, Mar 12, 2017 at 12:21:45PM -0700, Steve Longerbeam wrote:
There's actually nothing preventing userland from disabling a link
multiple times, and imx_media_link_notify() complies,
On 03/12/2017 12:57 PM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 04:30:53PM -0800, Steve Longerbeam wrote:
If it's too difficult to get the imx219 csi-2 transmitter into the
LP-11 state on power on, perhaps the csi-2 receiver can be a little
more lenient on the transmitter and m
On 03/12/2017 12:47 PM, Russell King - ARM Linux wrote:
Another issue.
The "reboot and the /dev/video* devices come up in a completely
different order" problem seems to exist with this version.
The dot graph I supplied previously had "ipu1_csi0 capture" on
/dev/video4. I've just rebooted, an
On Sat, Mar 11, 2017 at 04:30:53PM -0800, Steve Longerbeam wrote:
> If it's too difficult to get the imx219 csi-2 transmitter into the
> LP-11 state on power on, perhaps the csi-2 receiver can be a little
> more lenient on the transmitter and make the LP-11 timeout a warning
> instead of error-out.
Another issue.
The "reboot and the /dev/video* devices come up in a completely
different order" problem seems to exist with this version.
The dot graph I supplied previously had "ipu1_csi0 capture" on
/dev/video4. I've just rebooted, and now I find it's on
/dev/video2 instead.
Here's the extrac
On 03/12/2017 12:29 PM, Russell King - ARM Linux wrote:
On Sun, Mar 12, 2017 at 12:21:45PM -0700, Steve Longerbeam wrote:
There's actually nothing preventing userland from disabling a link
multiple times, and imx_media_link_notify() complies, and so
csi_s_power(OFF) gets called multiple times,
On Sun, Mar 12, 2017 at 12:21:45PM -0700, Steve Longerbeam wrote:
> There's actually nothing preventing userland from disabling a link
> multiple times, and imx_media_link_notify() complies, and so
> csi_s_power(OFF) gets called multiple times, and so that WARN_ON()
> in there is silly, I borrowed
On 03/12/2017 10:51 AM, Russell King - ARM Linux wrote:
I've just looked at my test system's dmesg, and spotted this in the log.
It's been a while since these popped out of the kernel, so I don't know
what caused them (other than the obvious, a media-ctl command.)
My script which sets this up
On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard
wrote:
> 2017-03-09 18:38 GMT+01:00 Laura Abbott :
>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter :
On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
> On Mon, Mar 06, 2017 at 11
On Sun 2017-03-12 07:37:45, Russell King - ARM Linux wrote:
> On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote:
> >
> >
> > On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
> > >On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
> > >>
> > >>
> > >>On 03/11/2
On 03/11/2017 11:37 PM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote:
On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
On 03/11/2017 10:45 AM, Russell King - ARM L
I've just looked at my test system's dmesg, and spotted this in the log.
It's been a while since these popped out of the kernel, so I don't know
what caused them (other than the obvious, a media-ctl command.)
My script which sets this up only enables links, and then configures the
formats etc, and
On Fri, Mar 10, 2017 at 03:20:34PM -0800, Steve Longerbeam wrote:
>
>
> On 03/10/2017 12:13 PM, Russell King - ARM Linux wrote:
> >Version 5 gives me no v4l2 controls exposed through the video device
> >interface.
> >
> >Just like with version 4, version 5 is completely useless with IMX219:
> >
>
The function atomisp_set_stop_timeout on being called, simply returns
back. The function hasn't been mentioned in the TODO and doesn't have
FIXME code around. Hence, atomisp_set_stop_timeout and its calls have been
removed.
This was done using Coccinelle.
@@
identifier f;
@@
void f(...) {
-retu
Hi Mauro,
The following changes since commit 700ea5e0e0dd70420a04e703ff264cc133834cba:
Merge tag 'v4.11-rc1' into patchwork (2017-03-06 06:49:34 -0300)
are available in the git repository at:
git://linuxtv.org/gliakhovetski/v4l-dvb.git for-4.12-1
for you to fetch changes up to c259da29a447
Hi Hans,
Thanks for the patch. Why hasn't this patch been CCed to Josh Wu? Is he
still at Atmel? Adding to CC to check.
A general comment: this patch doesn't only remove soc-camera dependencies,
it also changes the code and the behaviour. I would prefer to break that
down in multiple patches,
On Sun, 12 Mar 2017, SIMRAN SINGHAL wrote:
> On Sun, Mar 12, 2017 at 7:24 PM, Greg KH wrote:
> > On Fri, Mar 10, 2017 at 07:05:05PM +0530, simran singhal wrote:
> >> The function atomisp_set_stop_timeout on being called, simply returns
> >> back. The function hasn't been mentioned in the TODO a
On Sun, Mar 12, 2017 at 7:24 PM, Greg KH wrote:
> On Fri, Mar 10, 2017 at 07:05:05PM +0530, simran singhal wrote:
>> The function atomisp_set_stop_timeout on being called, simply returns
>> back. The function hasn't been mentioned in the TODO and doesn't have
>> FIXME code around. Hence, atomisp_s
On Sun, 12 Mar 2017, walter harms wrote:
>
>
> Am 11.03.2017 20:32, schrieb Colin King:
> > From: Colin Ian King
> >
> > There is no need to check if ret is non-zero, remove this
> > redundant check and just return the error status from the call
> > to mt9m114_write_reg_array.
> >
> > Detected
Am 11.03.2017 20:32, schrieb Colin King:
> From: Colin Ian King
>
> There is no need to check if ret is non-zero, remove this
> redundant check and just return the error status from the call
> to mt9m114_write_reg_array.
>
> Detected by CoverityScan, CID#1416577 ("Identical code for
> differen
On Fri, Mar 10, 2017 at 04:20:23AM +0530, simran singhal wrote:
> This patch removes unnecessary typecast of c90 int constant.
>
> WARNING: Unnecessary typecast of c90 int constant
>
> Signed-off-by: simran singhal
> ---
> drivers/staging/media/atomisp/i2c/gc2235.c | 6 +++---
> 1 file changed,
On Fri, Mar 10, 2017 at 07:05:05PM +0530, simran singhal wrote:
> The function atomisp_set_stop_timeout on being called, simply returns
> back. The function hasn't been mentioned in the TODO and doesn't have
> FIXME code around. Hence, atomisp_set_stop_timeout and its calls have been
> removed.
>
2017-03-09 18:38 GMT+01:00 Laura Abbott :
> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter :
>>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
> No one gave a thi
Submitters of device tree binding documentation may forget to CC
the subsystem maintainer if this is missing.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Javier Martinez Canillas
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
Please apply this patch directly if you want to be
On Sat, 11 Mar 2017, Hans Verkuil wrote:
> From: Hans Verkuil
>
> The colorspace is independent of whether YUV or RGB is sent to the SoC.
> Fix this.
>
> Signed-off-by: Hans Verkuil
I'm not sure why the first hunk is needed and how it is related :-) But it
doesn't break anything. I understan
Hi Laurent,
Thanks for the patch. I just checked in the current media/master, there
are still 2 users of vb1: sh_mobile_ceu_camera.c and atmel-isi.c. I
understand, that they are about to be removed either completely or out of
soc-camera, maybe patches for that have already beed submitted, but t
44 matches
Mail list logo
