cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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:   Sat Oct 29 05:00:15 CEST 2016
media-tree git hash:bd676c0c04ec94bd830b9192e2c33f2c4532278d
media_build git hash:   dac8db4dd7fa3cc87715cb19ace554e080690b39
v4l-utils git hash: 4ad7174b908a36c4f315e3fe2efa7e2f8a6f375a
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.7.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
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: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: WARNINGS
linux-4.9-rc1-i686: WARNINGS
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: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
smatch: ERRORS
ABI WARNING: change for arm-davinci
ABI WARNING: change for arm-multi
ABI WARNING: change for blackfin-bf561
ABI WARNING: change for mips
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.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: [RFC] v4l2 support for thermopile devices

[Matt Ranostay]

On Fri, Oct 28, 2016 at 2:53 PM, Hans Verkuil  wrote:
> Hi Matt,
>
> On 28/10/16 22:14, Matt Ranostay wrote:
>>
>> So want to toss a few thoughts on adding support for thermopile
>> devices (could be used for FLIR Lepton as well) that output pixel
>> data.
>> These typically aren't DMA'able devices since they are low speed
>> (partly to limiting the functionality to be in compliance with ITAR)
>> and data is piped over i2c/spi.
>>
>> My question is that there doesn't seem to be an other driver that
>> polls frames off of a device and pushes it to the video buffer, and
>> wanted to be sure that this doesn't currently exist somewhere.
>
>
> Not anymore, but if you go back to kernel 3.6 then you'll find this driver:
>
> drivers/media/video/bw-qcam.c
>
> It was for a grayscale parallel port webcam (which explains why it was
> removed in 3.7 :-) ), and it used polling to get the pixels.

Yikes parallel port, but I'll take a look at that for some reference :)

>
>> Also more importantly does the mailing list thinks it belongs in v4l2?
>
>
> I think it fits. It's a sensor, just with a very small resolution and
> infrared
> instead of visible light.
>
>> We already came up the opinion on the IIO list that it doesn't belong
>> in that subsystem since pushing raw pixel data to a buffer is a bit
>> hacky. Also could be generically written with regmap so other devices
>> (namely FLIR Lepton) could be easily supported.
>>
>> Need some input for the video pixel data types, which the device we
>> are using (see datasheet links below) is outputting pixel data in
>> little endian 16-bit of which a 12-bits signed value is used.  Does it
>> make sense to do some basic processing on the data since greyscale is
>> going to look weird with temperatures under 0C degrees? Namely a cold
>> object is going to be brighter than the hottest object it could read.
>
>
>> Or should a new V4L2_PIX_FMT_* be defined and processing done in
>> software?
>
>
> I would recommend that. It's no big deal, as long as the new format is
> documented.
>
>> Another issue is how to report the scaling value of 0.25 C
>> for each LSB of the pixels to the respecting recording application.
>
>
> Probably through a read-only control, but I'm not sure.
>
> Regards,
>
> Hans
>
>>
>> Datasheet:
>> http://media.digikey.com/pdf/Data%20Sheets/Panasonic%20Sensors%20PDFs/Grid-EYE_AMG88.pdf
>> Datasheet:
>> https://eewiki.net/download/attachments/13599167/Grid-EYE%20SPECIFICATIONS%28Reference%29.pdf?version=1=1380660426690=v2
>>
>> Thanks,
>>
>> Matt
>> --
>> 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

Re: [RFC] v4l2 support for thermopile devices

[Matt Ranostay]

On Fri, Oct 28, 2016 at 1:30 PM, Devin Heitmueller
 wrote:
> Hi Matt,
>
>> Need some input for the video pixel data types, which the device we
>> are using (see datasheet links below) is outputting pixel data in
>> little endian 16-bit of which a 12-bits signed value is used.  Does it
>> make sense to do some basic processing on the data since greyscale is
>> going to look weird with temperatures under 0C degrees? Namely a cold
>> object is going to be brighter than the hottest object it could read.
>> Or should a new V4L2_PIX_FMT_* be defined and processing done in
>> software?  Another issue is how to report the scaling value of 0.25 C
>> for each LSB of the pixels to the respecting recording application.
>
> Regarding the format for the pixel data:  I did some research into
> this when doing some driver work for the Seek Thermal (a product
> similar to the FLIR Lepton).  While it would be nice to be able to use
> an existing application like VLC or gStreamer to just take the video
> and capture from the V4L2 interface with no additional userland code,
> the reality is that how you colorize the data is going to be highly
> user specific (e.g. what thermal ranges to show with what colors,
> etc).  If your goal is really to do a V4L2 driver which returns the
> raw data, then you're probably best returning it in the native
> greyscale format (whether that be an existing V4L2 PIX_FMT or a new
> one needs to be defined), and then in software you can figure out how
> to colorize it.
>

Good point I was leaning to having userspace do it. But didn't think
of the color mapping part though so even more reason.

> Just my opinion though
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
--
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] v4l2 support for thermopile devices

[Matt Ranostay]

On Fri, Oct 28, 2016 at 1:40 PM, Marek Vasut  wrote:
> On 10/28/2016 10:30 PM, Devin Heitmueller wrote:
>> Hi Matt,
>>
>>> Need some input for the video pixel data types, which the device we
>>> are using (see datasheet links below) is outputting pixel data in
>>> little endian 16-bit of which a 12-bits signed value is used.  Does it
>>> make sense to do some basic processing on the data since greyscale is
>>> going to look weird with temperatures under 0C degrees? Namely a cold
>>> object is going to be brighter than the hottest object it could read.
>>> Or should a new V4L2_PIX_FMT_* be defined and processing done in
>>> software?  Another issue is how to report the scaling value of 0.25 C
>>> for each LSB of the pixels to the respecting recording application.
>>
>> Regarding the format for the pixel data:  I did some research into
>> this when doing some driver work for the Seek Thermal (a product
>> similar to the FLIR Lepton).  While it would be nice to be able to use
>> an existing application like VLC or gStreamer to just take the video
>> and capture from the V4L2 interface with no additional userland code,
>> the reality is that how you colorize the data is going to be highly
>> user specific (e.g. what thermal ranges to show with what colors,
>> etc).  If your goal is really to do a V4L2 driver which returns the
>> raw data, then you're probably best returning it in the native
>> greyscale format (whether that be an existing V4L2 PIX_FMT or a new
>> one needs to be defined), and then in software you can figure out how
>> to colorize it.
>
> All true, I also did my share of poking into SEEK Thermal USB and it is
> an excellent candidate for a V4L2 driver, that one. But I think this
> device here is producing much smaller images, something like 8x8 pixels.

Yes this is only 64 pixel (8x8 grid) but it is video still. Does have
some major pluses over a FLIR camera though, mainly power usage is
really low, and cost is lower (although that reason is decreasing
everyday).

>
> --
> Best regards,
> Marek Vasut
--
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] v4l2 support for thermopile devices

[Hans Verkuil]

Hi Matt,

On 28/10/16 22:14, Matt Ranostay wrote:

So want to toss a few thoughts on adding support for thermopile
devices (could be used for FLIR Lepton as well) that output pixel
data.
These typically aren't DMA'able devices since they are low speed
(partly to limiting the functionality to be in compliance with ITAR)
and data is piped over i2c/spi.

My question is that there doesn't seem to be an other driver that
polls frames off of a device and pushes it to the video buffer, and
wanted to be sure that this doesn't currently exist somewhere.


Not anymore, but if you go back to kernel 3.6 then you'll find this driver:

drivers/media/video/bw-qcam.c

It was for a grayscale parallel port webcam (which explains why it was
removed in 3.7 :-) ), and it used polling to get the pixels.


Also more importantly does the mailing list thinks it belongs in v4l2?


I think it fits. It's a sensor, just with a very small resolution and 
infrared

instead of visible light.


We already came up the opinion on the IIO list that it doesn't belong
in that subsystem since pushing raw pixel data to a buffer is a bit
hacky. Also could be generically written with regmap so other devices
(namely FLIR Lepton) could be easily supported.

Need some input for the video pixel data types, which the device we
are using (see datasheet links below) is outputting pixel data in
little endian 16-bit of which a 12-bits signed value is used.  Does it
make sense to do some basic processing on the data since greyscale is
going to look weird with temperatures under 0C degrees? Namely a cold
object is going to be brighter than the hottest object it could read.



Or should a new V4L2_PIX_FMT_* be defined and processing done in
software?


I would recommend that. It's no big deal, as long as the new format is
documented.


Another issue is how to report the scaling value of 0.25 C
for each LSB of the pixels to the respecting recording application.


Probably through a read-only control, but I'm not sure.

Regards,

Hans



Datasheet: 
http://media.digikey.com/pdf/Data%20Sheets/Panasonic%20Sensors%20PDFs/Grid-EYE_AMG88.pdf
Datasheet: 
https://eewiki.net/download/attachments/13599167/Grid-EYE%20SPECIFICATIONS%28Reference%29.pdf?version=1=1380660426690=v2

Thanks,

Matt
--
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

Re: [RFC] v4l2 support for thermopile devices

[Marek Vasut]

On 10/28/2016 10:30 PM, Devin Heitmueller wrote:
> Hi Matt,
> 
>> Need some input for the video pixel data types, which the device we
>> are using (see datasheet links below) is outputting pixel data in
>> little endian 16-bit of which a 12-bits signed value is used.  Does it
>> make sense to do some basic processing on the data since greyscale is
>> going to look weird with temperatures under 0C degrees? Namely a cold
>> object is going to be brighter than the hottest object it could read.
>> Or should a new V4L2_PIX_FMT_* be defined and processing done in
>> software?  Another issue is how to report the scaling value of 0.25 C
>> for each LSB of the pixels to the respecting recording application.
> 
> Regarding the format for the pixel data:  I did some research into
> this when doing some driver work for the Seek Thermal (a product
> similar to the FLIR Lepton).  While it would be nice to be able to use
> an existing application like VLC or gStreamer to just take the video
> and capture from the V4L2 interface with no additional userland code,
> the reality is that how you colorize the data is going to be highly
> user specific (e.g. what thermal ranges to show with what colors,
> etc).  If your goal is really to do a V4L2 driver which returns the
> raw data, then you're probably best returning it in the native
> greyscale format (whether that be an existing V4L2 PIX_FMT or a new
> one needs to be defined), and then in software you can figure out how
> to colorize it.

All true, I also did my share of poking into SEEK Thermal USB and it is
an excellent candidate for a V4L2 driver, that one. But I think this
device here is producing much smaller images, something like 8x8 pixels.

-- 
Best regards,
Marek Vasut
--
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] v4l2 support for thermopile devices

[Devin Heitmueller]

Hi Matt,

> Need some input for the video pixel data types, which the device we
> are using (see datasheet links below) is outputting pixel data in
> little endian 16-bit of which a 12-bits signed value is used.  Does it
> make sense to do some basic processing on the data since greyscale is
> going to look weird with temperatures under 0C degrees? Namely a cold
> object is going to be brighter than the hottest object it could read.
> Or should a new V4L2_PIX_FMT_* be defined and processing done in
> software?  Another issue is how to report the scaling value of 0.25 C
> for each LSB of the pixels to the respecting recording application.

Regarding the format for the pixel data:  I did some research into
this when doing some driver work for the Seek Thermal (a product
similar to the FLIR Lepton).  While it would be nice to be able to use
an existing application like VLC or gStreamer to just take the video
and capture from the V4L2 interface with no additional userland code,
the reality is that how you colorize the data is going to be highly
user specific (e.g. what thermal ranges to show with what colors,
etc).  If your goal is really to do a V4L2 driver which returns the
raw data, then you're probably best returning it in the native
greyscale format (whether that be an existing V4L2 PIX_FMT or a new
one needs to be defined), and then in software you can figure out how
to colorize it.

Just my opinion though

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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] v4l2 support for thermopile devices

[Matt Ranostay]

So want to toss a few thoughts on adding support for thermopile
devices (could be used for FLIR Lepton as well) that output pixel
data.
These typically aren't DMA'able devices since they are low speed
(partly to limiting the functionality to be in compliance with ITAR)
and data is piped over i2c/spi.

My question is that there doesn't seem to be an other driver that
polls frames off of a device and pushes it to the video buffer, and
wanted to be sure that this doesn't currently exist somewhere.

Also more importantly does the mailing list thinks it belongs in v4l2?
We already came up the opinion on the IIO list that it doesn't belong
in that subsystem since pushing raw pixel data to a buffer is a bit
hacky. Also could be generically written with regmap so other devices
(namely FLIR Lepton) could be easily supported.

Need some input for the video pixel data types, which the device we
are using (see datasheet links below) is outputting pixel data in
little endian 16-bit of which a 12-bits signed value is used.  Does it
make sense to do some basic processing on the data since greyscale is
going to look weird with temperatures under 0C degrees? Namely a cold
object is going to be brighter than the hottest object it could read.
Or should a new V4L2_PIX_FMT_* be defined and processing done in
software?  Another issue is how to report the scaling value of 0.25 C
for each LSB of the pixels to the respecting recording application.

Datasheet: 
http://media.digikey.com/pdf/Data%20Sheets/Panasonic%20Sensors%20PDFs/Grid-EYE_AMG88.pdf
Datasheet: 
https://eewiki.net/download/attachments/13599167/Grid-EYE%20SPECIFICATIONS%28Reference%29.pdf?version=1=1380660426690=v2

Thanks,

Matt
--
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: Still images and v4l2?

[Nicolas Dufresne]

Le vendredi 28 octobre 2016 à 14:14 +0200, Michael Haardt a écrit :
> I am currently developing a new image v4l2 sensor driver to acquire
> sequences of still images and wonder how to interface that to the
> v4l2 API.
> 
> Currently, cameras are assumed to deliver an endless stream of images
> after being triggered internally with VIDIOC_STREAMON.  If supported
> by
> the driver, a certain frame rate is used.
> 
> For precise image capturing, I need two additional features:
> 
> Limiting the number of captured images: It is desirable not having to
> stop
> streaming from user space for camera latency.  A typical application
> are single shots at random times, and possibly with little time in
> between the end of one image and start of a new one, so an image that
> could not be stopped in time would be a problem.  A video camera
> would
> only support the limit value "unlimited" as possible capturing limit.
> Scientific cameras may offer more, or possibly only limited
> capturing.
> 
> Configuring the capture trigger: Right now sensors are implicitly
> triggered internally from the driver.  Being able to configure
> external
> triggers, which many sensors support, is needed to start capturing at
> exactly the right time.  Again, video cameras may only offer
> "internal"
> as trigger type.
> 
> Perhaps v4l2 already offers something that I overlooked.  If not,
> what
> would be good ways to extend it?

In order to support the new Android Camera HAL (and other use cases),
there is work in progress to introduce some new API, they call it the
Request API.

https://lwn.net/Articles/641204/

> 
> Regards,
> 
> Michael
> --
> 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

Re: [RFC PATCH 0/6] media: davinci: VPIF: add DT support

[Kevin Hilman]

Kevin Hilman  writes:

> This series attempts to add DT support to the davinci VPIF capture
> driver.
>
> I'm not sure I've completely grasped the proper use of the ports and
> endpoints stuff, so this RFC is primarily to get input on whether I'm
> on the right track.
>
> The last patch is the one where all my questions are, the rest are
> just prep work to ge there.
>
> Tested on da850-lcdk and was able to do basic frame capture from the
> composite input.
>
> Series applies on v4.9-rc1

And FYI for anyone wanting to test, it needs a few config options
enabled[1] that are not (yet) part of davinci_all_defconfig.  I'll
update the defconfig when I'm ready to send non-RFC patches.

Kevin

[1]
CONFIG_MEDIA_SUPPORT=y
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_VIDEO_DEV=y

CONFIG_VIDEO_V4L2=y
CONFIG_VIDEO_V4L2_SUBDEV_API=y

CONFIG_V4L_PLATFORM_DRIVERS=y
CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE=y

# manually select codecs
CONFIG_MEDIA_SUBDRV_AUTOSELECT=n

# da850-lcdk
CONFIG_VIDEO_TVP514X=y
CONFIG_VIDEO_ADV7343=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 1/1] media: Drop FSF's postal address from the source code files

[Sakari Ailus]

Hi Felipe,

On Fri, Oct 28, 2016 at 11:47:02AM -0200, Felipe Sanches wrote:
> but why?

Much of this information is outdated. There's some reasoning behind this in
the patch adding the check in scripts/checkpatch.pl:

commit 4783f894d0f3bfb107cf3b1d9aed1f1a0672ee1d
Author: Josh Triplett 
Date:   Tue Nov 12 15:10:12 2013 -0800

checkpatch.pl: check for the FSF mailing address

Kernel maintainers reject new instances of the GPL boilerplate paragraph
directing people to write to the FSF for a copy of the GPL, since the FSF
has moved in the past and may do so again.

Make this an error for new code, but just a --strict CHK in --file mode;
anyone interested in doing tree-wide cleanups of this form can enable this
test explicitly.

Signed-off-by: Josh Triplett 
Acked-by: Greg Kroah-Hartman 
Acked-by: Joe Perches 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 

The address can be found in COPYING in the root of the kernel tree.

> 
> 2016-10-28 10:43 GMT-02:00 Sakari Ailus :
> > Drop the FSF's postal address from the source code files that typically
> > contain mostly the license text. The patch has been created with the
> > following command without manual edits:
> >
> > git grep -l "675 Mass Ave\|59 Temple Place\|51 Franklin St" -- \
> > drivers/media/ include/media|while read i; do i=$i perl -e '
> > open(F,"< $ENV{i}");
> > $a=join("", );
> > $a =~ s/[ \t]*\*\n.*You should.*\n.*along with.*\n.*(\n.*USA.*$)?\n//m
> > && $a =~ s/(^.*)Or, (point your browser to) /$1To obtain the 
> > license, $2\n$1/m;
> > close(F);
> > open(F, "> $ENV{i}");
> > print F $a;
> > close(F);'; done
> >
> > Signed-off-by: Sakari Ailus 
> > ---
> > Hi,
> >
> > I found this in a few places and decided to remove them all. The script
> > could be useful elsewhere, too.
> >
> > The actual patch can be found here, it appears to be too large to be
> > accepted by vger:
> >
> > 

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] media: Drop FSF's postal address from the source code files

[Felipe Sanches]

but why?

2016-10-28 10:43 GMT-02:00 Sakari Ailus :
> Drop the FSF's postal address from the source code files that typically
> contain mostly the license text. The patch has been created with the
> following command without manual edits:
>
> git grep -l "675 Mass Ave\|59 Temple Place\|51 Franklin St" -- \
> drivers/media/ include/media|while read i; do i=$i perl -e '
> open(F,"< $ENV{i}");
> $a=join("", );
> $a =~ s/[ \t]*\*\n.*You should.*\n.*along with.*\n.*(\n.*USA.*$)?\n//m
> && $a =~ s/(^.*)Or, (point your browser to) /$1To obtain the license, 
> $2\n$1/m;
> close(F);
> open(F, "> $ENV{i}");
> print F $a;
> close(F);'; done
>
> Signed-off-by: Sakari Ailus 
> ---
> Hi,
>
> I found this in a few places and decided to remove them all. The script
> could be useful elsewhere, too.
>
> The actual patch can be found here, it appears to be too large to be
> accepted by vger:
>
> 
>
>  drivers/media/common/b2c2/flexcop.c| 4 
>  drivers/media/common/cx2341x.c | 4 
>  drivers/media/common/siano/sms-cards.c | 4 
>  drivers/media/common/siano/sms-cards.h | 4 
>  drivers/media/common/siano/smscoreapi.c| 4 
>  drivers/media/common/tveeprom.c| 4 
>  drivers/media/dvb-core/demux.h | 4 
>  drivers/media/dvb-core/dmxdev.c| 4 
>  drivers/media/dvb-core/dmxdev.h| 4 
>  drivers/media/dvb-core/dvb_ca_en50221.c| 7 ++-
>  drivers/media/dvb-core/dvb_demux.c | 4 
>  drivers/media/dvb-core/dvb_demux.h | 4 
>  drivers/media/dvb-core/dvb_frontend.c  | 7 ++-
>  drivers/media/dvb-core/dvb_math.c  | 4 
>  drivers/media/dvb-core/dvb_math.h  | 4 
>  drivers/media/dvb-core/dvb_net.c   | 7 ++-
>  drivers/media/dvb-core/dvb_net.h   | 4 
>  drivers/media/dvb-core/dvb_ringbuffer.c| 4 
>  drivers/media/dvb-core/dvbdev.c| 4 
>  drivers/media/dvb-core/dvbdev.h| 4 
>  drivers/media/dvb-frontends/af9013.c   | 4 
>  drivers/media/dvb-frontends/af9013.h   | 4 
>  drivers/media/dvb-frontends/af9013_priv.h  | 4 
>  drivers/media/dvb-frontends/atbm8830.c | 4 
>  drivers/media/dvb-frontends/atbm8830.h | 4 
>  drivers/media/dvb-frontends/atbm8830_priv.h| 4 
>  drivers/media/dvb-frontends/au8522_decoder.c   | 5 -
>  drivers/media/dvb-frontends/bcm3510.h  | 4 
>  drivers/media/dvb-frontends/bcm3510_priv.h | 4 
>  drivers/media/dvb-frontends/bsbe1-d01a.h   | 7 ++-
>  drivers/media/dvb-frontends/bsbe1.h| 7 ++-
>  drivers/media/dvb-frontends/bsru6.h| 7 ++-
>  drivers/media/dvb-frontends/cx24113.c  | 4 
>  drivers/media/dvb-frontends/cx24113.h  | 4 
>  drivers/media/dvb-frontends/cx24123.c  | 4 
>  drivers/media/dvb-frontends/dib0070.c  | 4 
>  drivers/media/dvb-frontends/dib0090.c  | 4 
>  drivers/media/dvb-frontends/drx39xyj/drx39xxj.h| 4 
>  drivers/media/dvb-frontends/drxd.h | 8 ++--
>  drivers/media/dvb-frontends/drxd_firm.c| 8 ++--
>  drivers/media/dvb-frontends/drxd_firm.h| 8 ++--
>  drivers/media/dvb-frontends/drxd_hard.c| 8 ++--
>  drivers/media/dvb-frontends/drxd_map_firm.h| 8 ++--
>  drivers/media/dvb-frontends/drxk_hard.c| 8 ++--
>  drivers/media/dvb-frontends/dvb-pll.c  | 4 
>  drivers/media/dvb-frontends/dvb_dummy_fe.c | 4 
>  drivers/media/dvb-frontends/dvb_dummy_fe.h | 4 
>  drivers/media/dvb-frontends/ec100.c| 4 
>  drivers/media/dvb-frontends/ec100.h| 4 
>  drivers/media/dvb-frontends/hd29l2.c   | 4 
>  drivers/media/dvb-frontends/hd29l2.h   | 4 
>  drivers/media/dvb-frontends/hd29l2_priv.h  | 4 
>  drivers/media/dvb-frontends/isl6405.c  | 7 ++-
>  drivers/media/dvb-frontends/isl6405.h  | 7 ++-
>  drivers/media/dvb-frontends/isl6421.c  | 7 ++-
>  drivers/media/dvb-frontends/isl6421.h  | 7 ++-
>  drivers/media/dvb-frontends/itd1000.c  | 4 
>  drivers/media/dvb-frontends/itd1000.h  | 4 
>  drivers/media/dvb-frontends/itd1000_priv.h | 4 
>  drivers/media/dvb-frontends/ix2505v.c  | 4 
>  drivers/media/dvb-frontends/ix2505v.h  | 4 
>  drivers/media/dvb-frontends/lg2160.c   

[PATCH 1/1] media: Drop FSF's postal address from the source code files

[Sakari Ailus]

Drop the FSF's postal address from the source code files that typically
contain mostly the license text. The patch has been created with the
following command without manual edits:

git grep -l "675 Mass Ave\|59 Temple Place\|51 Franklin St" -- \
drivers/media/ include/media|while read i; do i=$i perl -e '
open(F,"< $ENV{i}");
$a=join("", );
$a =~ s/[ \t]*\*\n.*You should.*\n.*along with.*\n.*(\n.*USA.*$)?\n//m
&& $a =~ s/(^.*)Or, (point your browser to) /$1To obtain the license, 
$2\n$1/m;
close(F);
open(F, "> $ENV{i}");
print F $a;
close(F);'; done

Signed-off-by: Sakari Ailus 
---
Hi,

I found this in a few places and decided to remove them all. The script
could be useful elsewhere, too.

The actual patch can be found here, it appears to be too large to be
accepted by vger:



 drivers/media/common/b2c2/flexcop.c| 4 
 drivers/media/common/cx2341x.c | 4 
 drivers/media/common/siano/sms-cards.c | 4 
 drivers/media/common/siano/sms-cards.h | 4 
 drivers/media/common/siano/smscoreapi.c| 4 
 drivers/media/common/tveeprom.c| 4 
 drivers/media/dvb-core/demux.h | 4 
 drivers/media/dvb-core/dmxdev.c| 4 
 drivers/media/dvb-core/dmxdev.h| 4 
 drivers/media/dvb-core/dvb_ca_en50221.c| 7 ++-
 drivers/media/dvb-core/dvb_demux.c | 4 
 drivers/media/dvb-core/dvb_demux.h | 4 
 drivers/media/dvb-core/dvb_frontend.c  | 7 ++-
 drivers/media/dvb-core/dvb_math.c  | 4 
 drivers/media/dvb-core/dvb_math.h  | 4 
 drivers/media/dvb-core/dvb_net.c   | 7 ++-
 drivers/media/dvb-core/dvb_net.h   | 4 
 drivers/media/dvb-core/dvb_ringbuffer.c| 4 
 drivers/media/dvb-core/dvbdev.c| 4 
 drivers/media/dvb-core/dvbdev.h| 4 
 drivers/media/dvb-frontends/af9013.c   | 4 
 drivers/media/dvb-frontends/af9013.h   | 4 
 drivers/media/dvb-frontends/af9013_priv.h  | 4 
 drivers/media/dvb-frontends/atbm8830.c | 4 
 drivers/media/dvb-frontends/atbm8830.h | 4 
 drivers/media/dvb-frontends/atbm8830_priv.h| 4 
 drivers/media/dvb-frontends/au8522_decoder.c   | 5 -
 drivers/media/dvb-frontends/bcm3510.h  | 4 
 drivers/media/dvb-frontends/bcm3510_priv.h | 4 
 drivers/media/dvb-frontends/bsbe1-d01a.h   | 7 ++-
 drivers/media/dvb-frontends/bsbe1.h| 7 ++-
 drivers/media/dvb-frontends/bsru6.h| 7 ++-
 drivers/media/dvb-frontends/cx24113.c  | 4 
 drivers/media/dvb-frontends/cx24113.h  | 4 
 drivers/media/dvb-frontends/cx24123.c  | 4 
 drivers/media/dvb-frontends/dib0070.c  | 4 
 drivers/media/dvb-frontends/dib0090.c  | 4 
 drivers/media/dvb-frontends/drx39xyj/drx39xxj.h| 4 
 drivers/media/dvb-frontends/drxd.h | 8 ++--
 drivers/media/dvb-frontends/drxd_firm.c| 8 ++--
 drivers/media/dvb-frontends/drxd_firm.h| 8 ++--
 drivers/media/dvb-frontends/drxd_hard.c| 8 ++--
 drivers/media/dvb-frontends/drxd_map_firm.h| 8 ++--
 drivers/media/dvb-frontends/drxk_hard.c| 8 ++--
 drivers/media/dvb-frontends/dvb-pll.c  | 4 
 drivers/media/dvb-frontends/dvb_dummy_fe.c | 4 
 drivers/media/dvb-frontends/dvb_dummy_fe.h | 4 
 drivers/media/dvb-frontends/ec100.c| 4 
 drivers/media/dvb-frontends/ec100.h| 4 
 drivers/media/dvb-frontends/hd29l2.c   | 4 
 drivers/media/dvb-frontends/hd29l2.h   | 4 
 drivers/media/dvb-frontends/hd29l2_priv.h  | 4 
 drivers/media/dvb-frontends/isl6405.c  | 7 ++-
 drivers/media/dvb-frontends/isl6405.h  | 7 ++-
 drivers/media/dvb-frontends/isl6421.c  | 7 ++-
 drivers/media/dvb-frontends/isl6421.h  | 7 ++-
 drivers/media/dvb-frontends/itd1000.c  | 4 
 drivers/media/dvb-frontends/itd1000.h  | 4 
 drivers/media/dvb-frontends/itd1000_priv.h | 4 
 drivers/media/dvb-frontends/ix2505v.c  | 4 
 drivers/media/dvb-frontends/ix2505v.h  | 4 
 drivers/media/dvb-frontends/lg2160.c   | 4 
 drivers/media/dvb-frontends/lg2160.h   | 4 
 drivers/media/dvb-frontends/lgdt3305.c | 4 
 drivers/media/dvb-frontends/lgdt3305.h | 4 
 drivers/media/dvb-frontends/lgdt330x.c 

Still images and v4l2?

[Michael Haardt]

I am currently developing a new image v4l2 sensor driver to acquire
sequences of still images and wonder how to interface that to the
v4l2 API.

Currently, cameras are assumed to deliver an endless stream of images
after being triggered internally with VIDIOC_STREAMON.  If supported by
the driver, a certain frame rate is used.

For precise image capturing, I need two additional features:

Limiting the number of captured images: It is desirable not having to stop
streaming from user space for camera latency.  A typical application
are single shots at random times, and possibly with little time in
between the end of one image and start of a new one, so an image that
could not be stopped in time would be a problem.  A video camera would
only support the limit value "unlimited" as possible capturing limit.
Scientific cameras may offer more, or possibly only limited capturing.

Configuring the capture trigger: Right now sensors are implicitly
triggered internally from the driver.  Being able to configure external
triggers, which many sensors support, is needed to start capturing at
exactly the right time.  Again, video cameras may only offer "internal"
as trigger type.

Perhaps v4l2 already offers something that I overlooked.  If not, what
would be good ways to extend it?

Regards,

Michael
--
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

Fwd: [PATCH] stk1160: Give the chip some time to retrieve data from AC97 codec.

[Marcel Hasler]

This patch might need some explaining. I actually noticed this problem
early on while trying to fix the sound problem, but it was only this
morning that I realized the (trivial) cause of it.

I first noticed something strange going on when I read the AC97
registers from /proc/asound/cardX/codec97#0/ac97#0-0+regs using the
current version of the driver. Every time I read that file I would get
slightly different values, not only for one register but for several
of them. Also, every time I plugged in the device and opened alsamixer
I would be presented with a different set of mixer controls. So
obviously something was going wrong while talking to the AC97 chip.

When analyzing the USB trace I took from Windows (on VirtualBox) I
found long delays (2 ms) between control packets and wondered whether
those might be set by the driver on purpose. So I tried adding delays
in stk1160_[read|write]_reg, and sure enough, the problem disappeared.

In retrospective I suspect those long delays to really be the result
of virtualization overhead. I actually tried getting a native trace
using USBpcap, but unfortunately its timer resolution is so low that
it's impossible to get any useful data.

Once I realized what the actual problem was I removed the delays in
stk1160_[read|write]_reg and instead experimented with different
delays in stk1160_read_ac97 and found 20 us to be perfectly sufficient
to get reliable reads.

Now the strange thing about this problem is that it occurs on both of
my notebooks, but not on my desktop computer. I can only speculate
about the reason for this. My theory is that is has something to do
with the way different USB host controllers handle/buffer outgoing
control packets. Both of my notebooks are recent models by Acer (a
normal notebook and a cloudbook) and most likely use the same host
controller. My desktop motherboard on the other hand is a bit older.

So I wonder, have you experienced this problem on your own systems?

Best regards
Marcel

2016-10-28 10:52 GMT+02:00 Marcel Hasler :
> The STK1160 needs some time to transfer data from the AC97 registers into its 
> own. On some
> systems reading the chip's own registers to soon will return wrong values. 
> The "proper" way to
> handle this would be to poll STK1160_AC97CTL_0 after every read or write 
> command until the
> command bit has been cleared, but this may not be worth the hassle.
>
> Signed-off-by: Marcel Hasler 
> ---
>  drivers/media/usb/stk1160/stk1160-ac97.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/media/usb/stk1160/stk1160-ac97.c 
> b/drivers/media/usb/stk1160/stk1160-ac97.c
> index 31bdd60d..caa65a8 100644
> --- a/drivers/media/usb/stk1160/stk1160-ac97.c
> +++ b/drivers/media/usb/stk1160/stk1160-ac97.c
> @@ -20,6 +20,7 @@
>   *
>   */
>
> +#include 
>  #include 
>
>  #include "stk1160.h"
> @@ -61,6 +62,9 @@ static u16 stk1160_read_ac97(struct stk1160 *dev, u16 reg)
>  */
> stk1160_write_reg(dev, STK1160_AC97CTL_0, 0x8b);
>
> +   /* Give the chip some time to transfer data */
> +   usleep_range(20, 40);
> +
> /* Retrieve register value */
> stk1160_read_reg(dev, STK1160_AC97_CMD, );
> stk1160_read_reg(dev, STK1160_AC97_CMD + 1, );
> --
> 2.10.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] lirc: introduce LIRC_SET_TRANSMITTER_WAIT ioctl

[Sean Young]

Hi Andi,

On Fri, Oct 28, 2016 at 04:38:39PM +0900, Andi Shyti wrote:
> Hi Sean,
> 
> > ret *= sizeof(unsigned int);
> >  
> > -   /*
> > -* The lircd gap calculation expects the write function to
> > -* wait for the actual IR signal to be transmitted before
> > -* returning.
> > -*/
> > -   towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get());
> > -   if (towait > 0) {
> > -   set_current_state(TASK_INTERRUPTIBLE);
> > -   schedule_timeout(usecs_to_jiffies(towait));
> > +   if (!lirc->tx_no_wait) {
> > +   /*
> > +* The lircd gap calculation expects the write function to
> > +* wait for the actual IR signal to be transmitted before
> > +* returning.
> > +*/
> > +   towait = ktime_us_delta(ktime_add_us(start, duration),
> > +   ktime_get());
> > +   if (towait > 0) {
> > +   set_current_state(TASK_INTERRUPTIBLE);
> > +   schedule_timeout(usecs_to_jiffies(towait));
> > +   }
> > }
> > -
> 
> this doesn't fix my problem, though.
> 
> This approach gives the userspace the possibility to choose to
> either sync or not. In my case the sync happens, but in a
> different level and it's not up to the userspace to make the
> decision.

What problem are you trying to solve?

I wrote this patch as a response to this patch:

https://lkml.org/lkml/2016/9/1/653

In the spi case, the driver already waits for the IR to complete so the 
wait in ir_lirc_transmit_ir() is unnecessary. However it does not end up
waiting. There are other drivers like yours that wait for the IR to 
complete (ene_ir, ite-cir). Since towait in ir_lirc_transmit_ir is the 
delta between before and after the driver transmits, it will be 0 and 
will never goto into schedule_timeout(), barring some very minor rounding 
differences.

> Besides, I see here a security issue: what happens if userspace
> does something like
> 
>  fd = open("/dev/lirc0", O_RDWR);
> 
>  ioctl(fd, LIRC_SET_TRANSMITTER_WAIT, 0);
> 
>  while(1)
> write(fd, buffer, ENORMOUS_BUFFER_SIZE);

I don't understand what problem this would introduce.

You can't write more than 512 pulse/spaces and each write cannot
have more than 500ms in IR (so adding up the pulses and spaces). The driver
should only send once the previous send completed.

> >  
> > +   case LIRC_SET_TRANSMITTER_WAIT:
> > +   if (!dev->tx_ir)
> > +   return -ENOTTY;
> > +
> > +   lirc->tx_no_wait = !val;
> > +   break;
> > +
> 
> Here I see an innocuous bug. Depending on the hardware (for
> example ir-spi) it might happen that the device waits in any
> case (in ir-spi the sync is done by the spi). This means that if
> userspace sets 'tx_no_wait = true', the device/driver doesn't
> care and waits anyway, doing the opposite from what is described
> in the ABI.
> 
> Here we could call a dev->tx_set_transmitter_wait(...) function
> that sets the value or returns error in case the wait is not
> feasable, something like:
> 
>   case LIRC_SET_TRANSMITTER_WAIT:
>   if (!dev->tx_ir)
>   return -ENOTTY;
> 
>   if (dev->tx_set_transmitter_wait)
>   return dev->tx_set_transmitter_wait(lirc, val);
> 
>   lirc->tx_no_wait = !val;
>   break;

That is true. Do you want the ir-spi driver to be able to send without
waiting?

> > --- a/drivers/media/rc/rc-core-priv.h
> > +++ b/drivers/media/rc/rc-core-priv.h
> > @@ -112,7 +112,7 @@ struct ir_raw_event_ctrl {
> > u64 gap_duration;
> > bool gap;
> > bool send_timeout_reports;
> > -
> > +   bool tx_no_wait;
> > } lirc;
> 
> this to me looks confusing, it has a negative meaning in kernel
> space and a positive meaning in userspace. Can't we call it
> lirc->tx_wait instead of lirc->tx_no_wait, so that we keep the
> same meaning and we don't need to negate val?

This was just done to avoid having to initialise to true (non-zero).


Thanks,
Sean
--
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] stk1160: Give the chip some time to retrieve data from AC97 codec.

[Marcel Hasler]

The STK1160 needs some time to transfer data from the AC97 registers into its 
own. On some
systems reading the chip's own registers to soon will return wrong values. The 
"proper" way to
handle this would be to poll STK1160_AC97CTL_0 after every read or write 
command until the
command bit has been cleared, but this may not be worth the hassle.

Signed-off-by: Marcel Hasler 
---
 drivers/media/usb/stk1160/stk1160-ac97.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/usb/stk1160/stk1160-ac97.c 
b/drivers/media/usb/stk1160/stk1160-ac97.c
index 31bdd60d..caa65a8 100644
--- a/drivers/media/usb/stk1160/stk1160-ac97.c
+++ b/drivers/media/usb/stk1160/stk1160-ac97.c
@@ -20,6 +20,7 @@
  *
  */
 
+#include 
 #include 
 
 #include "stk1160.h"
@@ -61,6 +62,9 @@ static u16 stk1160_read_ac97(struct stk1160 *dev, u16 reg)
 */
stk1160_write_reg(dev, STK1160_AC97CTL_0, 0x8b);
 
+   /* Give the chip some time to transfer data */
+   usleep_range(20, 40);
+
/* Retrieve register value */
stk1160_read_reg(dev, STK1160_AC97_CMD, );
stk1160_read_reg(dev, STK1160_AC97_CMD + 1, );
-- 
2.10.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] lirc: introduce LIRC_SET_TRANSMITTER_WAIT ioctl

[Andi Shyti]

Hi Sean,

>   ret *= sizeof(unsigned int);
>  
> - /*
> -  * The lircd gap calculation expects the write function to
> -  * wait for the actual IR signal to be transmitted before
> -  * returning.
> -  */
> - towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get());
> - if (towait > 0) {
> - set_current_state(TASK_INTERRUPTIBLE);
> - schedule_timeout(usecs_to_jiffies(towait));
> + if (!lirc->tx_no_wait) {
> + /*
> +  * The lircd gap calculation expects the write function to
> +  * wait for the actual IR signal to be transmitted before
> +  * returning.
> +  */
> + towait = ktime_us_delta(ktime_add_us(start, duration),
> + ktime_get());
> + if (towait > 0) {
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(usecs_to_jiffies(towait));
> + }
>   }
> -

this doesn't fix my problem, though.

This approach gives the userspace the possibility to choose to
either sync or not. In my case the sync happens, but in a
different level and it's not up to the userspace to make the
decision.

Besides, I see here a security issue: what happens if userspace
does something like

 fd = open("/dev/lirc0", O_RDWR);

 ioctl(fd, LIRC_SET_TRANSMITTER_WAIT, 0);

 while(1)
write(fd, buffer, ENORMOUS_BUFFER_SIZE);

>  
> + case LIRC_SET_TRANSMITTER_WAIT:
> + if (!dev->tx_ir)
> + return -ENOTTY;
> +
> + lirc->tx_no_wait = !val;
> + break;
> +

Here I see an innocuous bug. Depending on the hardware (for
example ir-spi) it might happen that the device waits in any
case (in ir-spi the sync is done by the spi). This means that if
userspace sets 'tx_no_wait = true', the device/driver doesn't
care and waits anyway, doing the opposite from what is described
in the ABI.

Here we could call a dev->tx_set_transmitter_wait(...) function
that sets the value or returns error in case the wait is not
feasable, something like:

case LIRC_SET_TRANSMITTER_WAIT:
if (!dev->tx_ir)
return -ENOTTY;

if (dev->tx_set_transmitter_wait)
return dev->tx_set_transmitter_wait(lirc, val);

lirc->tx_no_wait = !val;
break;

> --- a/drivers/media/rc/rc-core-priv.h
> +++ b/drivers/media/rc/rc-core-priv.h
> @@ -112,7 +112,7 @@ struct ir_raw_event_ctrl {
>   u64 gap_duration;
>   bool gap;
>   bool send_timeout_reports;
> -
> + bool tx_no_wait;
>   } lirc;

this to me looks confusing, it has a negative meaning in kernel
space and a positive meaning in userspace. Can't we call it
lirc->tx_wait instead of lirc->tx_no_wait, so that we keep the
same meaning and we don't need to negate val?

Thanks,
Andi
--
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 next 1/2] media: mtk-mdp: fix video_device_release argument

[Vincent Stehlé]

On Thu, Oct 27, 2016 at 10:23:24PM +0200, Vincent Stehlé wrote:
> video_device_release() takes a pointer to struct video_device as argument.
> Fix two call sites where the address of the pointer is passed instead.

Sorry, I messed up: please ignore that "fix". The 0day robot made me
realize this is indeed not a proper fix.

The issue remains, though: we cannot call video_device_release() on the
vdev structure member, as this will in turn call kfree(). Most probably,
vdev needs to be dynamically allocated, or the call to
video_device_release() dropped completely.

Sorry for the bad patch.

Best regards,

Vincent.
--
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