Re: [PATCH] lirc.4: remove ioctls and feature bits which were never implemented
Hello Sean, On 4/23/18 12:26 PM, Sean Young wrote:> The lirc header file included ioctls and feature bits which were never > implemented by any driver. They were removed in commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d55f09abe24b4dfadab246b6f217da547361cdb6 > > Signed-off-by: Sean Young Thanks for your persistence. Mauro, Alec, thanks for your input. Patch Applied. Thanks! Michael > --- > man4/lirc.4 | 92 > ++--- > 1 file changed, 2 insertions(+), 90 deletions(-) > > diff --git a/man4/lirc.4 b/man4/lirc.4 > index 1e94a7163..3adff55f1 100644 > --- a/man4/lirc.4 > +++ b/man4/lirc.4 > @@ -78,9 +78,7 @@ The package reflects a timeout; see the > .B LIRC_SET_REC_TIMEOUT_REPORTS > ioctl. > .\" > -.SS Reading input with the > -.B LIRC_MODE_LIRCCODE > -drivers > +.SS Reading input with the LIRC_MODE_LIRCCODE drivers > .PP > In the \fBLIRC_MODE_LIRCCODE\fR > mode, the data returned by > @@ -204,17 +202,11 @@ Currently serves no purpose since only > .BR LIRC_MODE_PULSE > is supported. > .TP > -.BR LIRC_GET_SEND_CARRIER " (\fIvoid\fP)" > -Get the modulation frequency (Hz). > -.TP > .BR LIRC_SET_SEND_CARRIER " (\fIint\fP)" > Set the modulation frequency. > The argument is the frequency (Hz). > .TP > -.BR LIRC_GET_SEND_CARRIER " (\fIvoid\fP)" > -Get the modulation frequency used when decoding (Hz). > -.TP > -.BR SET_SEND_DUTY_CYCLE " (\fIint\fP)" > +.BR LIRC_SET_SEND_DUTY_CYCLE " (\fIint\fP)" > Set the carrier duty cycle. > .I val > is a number in the range [0,100] which > @@ -284,36 +276,6 @@ By default this should be turned off. > .BR LIRC_GET_REC_RESOLUTION " (\fIvoid\fP)" > Return the driver resolution (microseconds). > .TP > -.BR LIRC_GET_MIN_FILTER_PULSE " (\fIvoid\fP)", " " \ > -LIRC_GET_MAX_FILTER_PULSE " (\fIvoid\fP)" > -Some devices are able to filter out spikes in the incoming signal > -using given filter rules. > -These ioctls return the hardware capabilities that describe the bounds > -of the possible filters. > -Filter settings depend on the IR protocols that are expected. > -.BR lircd (8) > -derives the settings from all protocols definitions found in its > -.BR lircd.conf (5) > -config file. > -.TP > -.BR LIRC_GET_MIN_FILTER_SPACE " (\fIvoid\fP)", " " \ > -LIRC_GET_MAX_FILTER_SPACE " (\fIvoid\fP)" > -See > -.BR LIRC_GET_MIN_FILTER_PULSE . > -.TP > -.BR LIRC_SET_REC_FILTER " (\fIint\fP)" > -Pulses/spaces shorter than this (microseconds) are filtered out by > -hardware. > -.TP > -.BR LIRC_SET_REC_FILTER_PULSE " (\fIint\fP)", " " \ > -LIRC_SET_REC_FILTER_SPACE " (\fIint\fP)" > -Pulses/spaces shorter than this (microseconds) are filtered out by > -hardware. > -If filters cannot be set independently for pulse/space, the > -corresponding ioctls must return an error and > -.BR LIRC_SET_REC_FILTER > -should be used instead. > -.TP > .BR LIRC_SET_TRANSMITTER_MASK > Enable the set of transmitters specified in > .IR val , > @@ -343,32 +305,6 @@ carrier reports. > In that case, it will be disabled as soon as you disable carrier reports. > Trying to disable a wide band receiver while carrier reports are active > will do nothing. > -.TP > -.BR LIRC_SETUP_START " (\fIvoid\fP), " LIRC_SETUP_END " (\fIvoid\fP)" > -Setting of several driver parameters can be optimized by bracketing > -the actual ioctl calls > -.BR LIRC_SETUP_START > -and > -.BR LIRC_SETUP_END . > -When a driver receives a > -.BR LIRC_SETUP_START > -ioctl, it can choose to not commit further setting changes to the > -hardware until a > -.BR LIRC_SETUP_END > -is received. > -But this is open to the driver implementation and every driver > -must also handle parameter changes which are not encapsulated by > -.BR LIRC_SETUP_START > -and > -.BR LIRC_SETUP_END . > -Drivers can also choose to ignore these ioctls. > -.TP > -.BR LIRC_NOTIFY_DECODE " (\fIvoid\fP)" > -This ioctl is called by > -.BR lircd (8) > -whenever a successful decoding of an incoming IR signal is possible. > -This can be used by supporting hardware to give visual user > -feedback, for example by flashing an LED. > .\" > .SH FEATURES > .PP > @@ -378,14 +314,6 @@ The > ioctl returns a bit mask describing features of the driver. > The following bits may be returned in the mask: > .TP > -.BR LIRC_CAN_REC_RAW > -The driver is capable of receiving using > -.BR LIRC_MODE_RAW . > -.TP > -.BR LIRC_CAN_REC_PULSE > -The driver is capable of receiving using > -.BR LIRC_MODE_PULSE . > -.TP > .BR LIRC_CAN_REC_MODE2 > The driver is capable of receiving using > .BR LIRC_MODE_MODE2 . > @@ -426,10 +354,6 @@ The driver supports > The driver supports > .BR LIRC_SET_REC_TIMEOUT . > .TP > -.BR LIRC_CAN_SET_REC_FILTER > -The driver supports > -.BR LIRC_SET_REC_FILTER . > -.TP > .BR LIRC_CAN_MEASURE_CARRIER > The driver supports measuring of the modulation frequency using > .BR LIRC_SET_MEASURE_CARRIER_MODE . > @@ -438,22 +362,10 @@ The driver supports measuring of
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Oct 31 05:00:10 CET 2018 media-tree git hash:3b796aa60af087f5fec75aee9b17f2130f2b9adc media_build git hash: 0c8bb27f3aaa682b9548b656f77505c3d1f11e71 v4l-utils git hash: c36dbbdfa8b30b2badd4f893b59d0bd4f0bd12aa edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.123-i686: OK linux-3.18.123-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.159-i686: OK linux-4.4.159-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.131-i686: OK linux-4.9.131-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.74-i686: OK linux-4.14.74-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19-i686: OK linux-4.19-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [PATCH v3 2/9] media: tvp5150: fix irq_request error path during probe
Hi Marco,
Thank you for the patch.
On Tuesday, 18 September 2018 16:14:46 EEST Marco Felsch wrote:
> Commit 37c65802e76a ("media: tvp5150: Add sync lock interrupt handling")
> introduced the interrupt handling. But we have to free the
> v4l2_ctrl_handler before we can return the error code.
>
> Fixes: 37c65802e76a ("media: tvp5150: Add sync lock interrupt handling")
> Signed-off-by: Marco Felsch
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/i2c/tvp5150.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index 133073518744..40aaa8ca0b63 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -1650,7 +1650,7 @@ static int tvp5150_probe(struct i2c_client *c,
> tvp5150_isr, IRQF_TRIGGER_HIGH |
> IRQF_ONESHOT, "tvp5150", core);
> if (res)
> - return res;
> + goto err;
> }
>
> res = v4l2_async_register_subdev(sd);
--
Regards,
Laurent Pinchart
Re: [PATCH v2 6/6] dt-bindings: media: mt9m111: add pclk-sample property
On Mon, 29 Oct 2018 19:24:10 +0100, Marco Felsch wrote: > Add the pclk-sample property to the list of optional properties > for the mt9m111 camera sensor. > > Signed-off-by: Marco Felsch > --- > Documentation/devicetree/bindings/media/i2c/mt9m111.txt | 5 + > 1 file changed, 5 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH v2 5/6] dt-bindings: media: mt9m111: adapt documentation to be more clear
On Mon, Oct 29, 2018 at 07:24:09PM +0100, Marco Felsch wrote: > Replace the vague binding by a more verbose. Remove the remote property > from the example since the driver don't support such a property. Also > remove the bus-width property from the endpoint since the driver don't > take care of it. > > Signed-off-by: Marco Felsch > --- > .../devicetree/bindings/media/i2c/mt9m111.txt | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/media/i2c/mt9m111.txt > b/Documentation/devicetree/bindings/media/i2c/mt9m111.txt > index 6b910036b57e..921cc48c488b 100644 > --- a/Documentation/devicetree/bindings/media/i2c/mt9m111.txt > +++ b/Documentation/devicetree/bindings/media/i2c/mt9m111.txt > @@ -9,8 +9,13 @@ Required Properties: > - clocks: reference to the master clock. > - clock-names: shall be "mclk". > > -For further reading on port node refer to > -Documentation/devicetree/bindings/media/video-interfaces.txt. > +The device node must contain one 'port' child node with one 'endpoint' child > +sub-node for its digital output video port, in accordance with the video > +interface bindings defined in: > +Documentation/devicetree/bindings/media/video-interfaces.txt > + > +Required endpoint properties: > +- remote-endpoint: For information see ../video-interfaces.txt. You don't need to explicitly document this. Otherwise, Reviewed-by: Rob Herring
Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers
On Tue, Oct 30, 2018 at 05:35:23PM -0300, Mauro Carvalho Chehab wrote: > Em Tue, 30 Oct 2018 21:28:57 +0100 > jacopo mondi escreveu: > > > Hi Mauro, > > > > On Tue, Oct 30, 2018 at 09:14:09AM -0300, Mauro Carvalho Chehab wrote: > > > Em Tue, 30 Oct 2018 01:21:34 +0200 > > > Sakari Ailus escreveu: > > > > > > > The SoC camera framework has been obsolete for some time and it is no > > > > longer functional. A few drivers have been converted to the V4L2 > > > > sub-device API but for the rest the conversion has not taken place yet. > > > > > > > > In order to keep the tree clean and to avoid keep maintaining > > > > non-functional and obsolete code, remove the SoC camera framework as > > > > well > > > > as the drivers that depend on it. > > > > > > > > Signed-off-by: Sakari Ailus > > > > --- > > > > Resending, this time with git format-patch -D . > > > > > > > > MAINTAINERS|8 - > > > > drivers/media/i2c/Kconfig |8 - > > > > drivers/media/i2c/Makefile |1 - > > > > drivers/media/i2c/soc_camera/Kconfig | 66 - > > > > drivers/media/i2c/soc_camera/Makefile | 10 - > > > > drivers/media/i2c/soc_camera/ov9640.h | 208 -- > > > > drivers/media/i2c/soc_camera/soc_mt9m001.c | 757 --- > > > > drivers/media/i2c/soc_camera/soc_mt9t112.c | 1157 --- > > > > drivers/media/i2c/soc_camera/soc_mt9v022.c | 1012 - > > > > drivers/media/i2c/soc_camera/soc_ov5642.c | 1087 -- > > > > drivers/media/i2c/soc_camera/soc_ov772x.c | 1123 -- > > > > drivers/media/i2c/soc_camera/soc_ov9640.c | 738 --- > > > > drivers/media/i2c/soc_camera/soc_ov9740.c | 996 - > > > > drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c | 1415 - > > > > drivers/media/i2c/soc_camera/soc_tw9910.c | 999 - > > > > > > I don't see why we should remove those. I mean, Jacopo is > > > actually converting those drivers to not depend on soc_camera, > > > and it is a way better to review those patches with the old > > > code in place. > > > > I have converted a few drivers used by some SH boards where I dropped > > dependencies on soc_camera, not to remove camera support from those. For > > others I don't have cameras to test with, nor I know about boards in > > mainline using them. > > > > From my side, driver conversion is done. > > > > > > > > So, at least while Jacopo is keep doing this work, I would keep > > > at Kernel tree, as it helps to see a diff when the driver changes > > > when getting rid of soc_camera dependencies. > > > > > > So, IMO, the best would be to move those to /staging, eventually > > > depending on BROKEN. > > > > However, somebody with a (rather old) development setup using those camera > > sensor may wants to see if mainline supports them. We actually had a > > few patches coming lately (for ov. I understand Sakari's argument that those > > could be retrieved from git history, but a few people will notice imo. > > I also understand the additional maintainership burden of keeping them > > around, so I'm fine with either ways ;) > > > > This is a list of the current situation in mainline, to have a better > > idea: > > > > $for i in `seq 1 9`; do CAM=$(head -n $i /tmp/soc_cams | tail -n 1); echo > > $CAM; find drivers/media/ -name $CAM; done > > t9m001.c > > drivers/media/i2c/soc_camera/mt9m001.c > > mt9t112.c > > drivers/media/i2c/mt9t112.c > > drivers/media/i2c/soc_camera/mt9t112.c > > mt9v022.c > > drivers/media/i2c/soc_camera/mt9v022.c > > ov5642.c > > drivers/media/i2c/soc_camera/ov5642.c > > ov772x.c > > drivers/media/i2c/ov772x.c > > drivers/media/i2c/soc_camera/ov772x.c > > ov9640.c > > drivers/media/i2c/soc_camera/ov9640.c > > ov9740.c > > drivers/media/i2c/soc_camera/ov9740.c > > rj54n1cb0c.c > > drivers/media/i2c/rj54n1cb0c.c > > drivers/media/i2c/soc_camera/rj54n1cb0c.c > > tw9910.c > > drivers/media/i2c/tw9910.c > > drivers/media/i2c/soc_camera/tw9910.c > > > > So it seems to me only the following sensor do not have a > > non-soc_camera driver at the moment: > > > > mt9m001.c > > mt9v022.c > > ov5642.c > > ov9640.c > > ov9740.c For a few of them (mt9m001, ov5642) there are cheap modules available online. The others ones have public documentation. I know they are old and dusty, supporting only parallel video interface. > > Ok. So, what about keeping just those 5 drivers at staging? If, after an > year, people won't do conversions, we can just drop them. > Let's see what Sakari and Hans think. Again, I'm fine with both ways ;) Thanks j > In any case, if we're ripping off soc_camera from the main tree, > moving to staging, no dependencies for soc_camera.h should be > kept at main tree. If any driver requires it, it should also be > moved to staging. > > Thanks, > Mauro signature.asc Description: PGP signature
Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers
Hi Mauro, On Tue, Oct 30, 2018 at 09:14:09AM -0300, Mauro Carvalho Chehab wrote: > Em Tue, 30 Oct 2018 01:21:34 +0200 > Sakari Ailus escreveu: > > > The SoC camera framework has been obsolete for some time and it is no > > longer functional. A few drivers have been converted to the V4L2 > > sub-device API but for the rest the conversion has not taken place yet. > > > > In order to keep the tree clean and to avoid keep maintaining > > non-functional and obsolete code, remove the SoC camera framework as well > > as the drivers that depend on it. > > > > Signed-off-by: Sakari Ailus > > --- > > Resending, this time with git format-patch -D . > > > > MAINTAINERS|8 - > > drivers/media/i2c/Kconfig |8 - > > drivers/media/i2c/Makefile |1 - > > drivers/media/i2c/soc_camera/Kconfig | 66 - > > drivers/media/i2c/soc_camera/Makefile | 10 - > > drivers/media/i2c/soc_camera/ov9640.h | 208 -- > > drivers/media/i2c/soc_camera/soc_mt9m001.c | 757 --- > > drivers/media/i2c/soc_camera/soc_mt9t112.c | 1157 --- > > drivers/media/i2c/soc_camera/soc_mt9v022.c | 1012 - > > drivers/media/i2c/soc_camera/soc_ov5642.c | 1087 -- > > drivers/media/i2c/soc_camera/soc_ov772x.c | 1123 -- > > drivers/media/i2c/soc_camera/soc_ov9640.c | 738 --- > > drivers/media/i2c/soc_camera/soc_ov9740.c | 996 - > > drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c | 1415 - > > drivers/media/i2c/soc_camera/soc_tw9910.c | 999 - > > I don't see why we should remove those. I mean, Jacopo is > actually converting those drivers to not depend on soc_camera, > and it is a way better to review those patches with the old > code in place. I have converted a few drivers used by some SH boards where I dropped dependencies on soc_camera, not to remove camera support from those. For others I don't have cameras to test with, nor I know about boards in mainline using them. From my side, driver conversion is done. > > So, at least while Jacopo is keep doing this work, I would keep > at Kernel tree, as it helps to see a diff when the driver changes > when getting rid of soc_camera dependencies. > > So, IMO, the best would be to move those to /staging, eventually > depending on BROKEN. However, somebody with a (rather old) development setup using those camera sensor may wants to see if mainline supports them. We actually had a few patches coming lately (for ov. I understand Sakari's argument that those could be retrieved from git history, but a few people will notice imo. I also understand the additional maintainership burden of keeping them around, so I'm fine with either ways ;) This is a list of the current situation in mainline, to have a better idea: $for i in `seq 1 9`; do CAM=$(head -n $i /tmp/soc_cams | tail -n 1); echo $CAM; find drivers/media/ -name $CAM; done t9m001.c drivers/media/i2c/soc_camera/mt9m001.c mt9t112.c drivers/media/i2c/mt9t112.c drivers/media/i2c/soc_camera/mt9t112.c mt9v022.c drivers/media/i2c/soc_camera/mt9v022.c ov5642.c drivers/media/i2c/soc_camera/ov5642.c ov772x.c drivers/media/i2c/ov772x.c drivers/media/i2c/soc_camera/ov772x.c ov9640.c drivers/media/i2c/soc_camera/ov9640.c ov9740.c drivers/media/i2c/soc_camera/ov9740.c rj54n1cb0c.c drivers/media/i2c/rj54n1cb0c.c drivers/media/i2c/soc_camera/rj54n1cb0c.c tw9910.c drivers/media/i2c/tw9910.c drivers/media/i2c/soc_camera/tw9910.c So it seems to me only the following sensor do not have a non-soc_camera driver at the moment: mt9m001.c mt9v022.c ov5642.c ov9640.c ov9740.c Thanks j > > Thanks, > Mauro signature.asc Description: PGP signature
Re: uvcvideo: IR camera lights only every second frame
Hello,
On Tuesday, 30 October 2018 17:48:12 EET Kieran Bingham wrote:
> On 30/10/2018 14:36, Jiri Slaby wrote:
> > Hi,
> >
> > I have a Dell Lattitude 7280 with two webcams. The standard one works
> > fine (/dev/video0). The other one is an IR camera (/dev/video1). The
> > camera proper works fine and produces 340x374 frames. But there is an IR
> > led supposed to light the object. The video is 30fps, but the LED seems
> > to emit light only on half of the frames, i.e. on every second frame (15
> > fps). This makes the video blink a lot. The two consecutive frames look
> > like:
> > https://www.fi.muni.cz/~xslaby/sklad/mpv-shot0002.jpg
> > https://www.fi.muni.cz/~xslaby/sklad/mpv-shot0003.jpg
> >
> > Do you have any ideas what to check/test?
>
> I have an HP Spectre with IR camera, and it also 'flashes' alternate frames.
>
> I assumed this was something to do with controlling the lighting for
> face recognition some how.
>
> I'm fairly sure we don't control the 'IR flash' from the UVC.
>
> I wonder if there is a control parameter for the IR led in the
> extension-units?
[snip]
> > VideoControl Interface Descriptor:
> > bLength18
> > bDescriptorType36
> > bDescriptorSubtype 2 (INPUT_TERMINAL)
> > bTerminalID11
> > wTerminalType 0x0201 Camera Sensor
> > bAssocTerminal 0
> > iTerminal 0
> > wObjectiveFocalLengthMin 0
> > wObjectiveFocalLengthMax 0
> > wOcularFocalLength0
> > bControlSize 3
> > bmControls 0x
> > VideoControl Interface Descriptor:
> > bLength11
> > bDescriptorType36
> > bDescriptorSubtype 5 (PROCESSING_UNIT)
> > Warning: Descriptor too short
> > bUnitID 9
> > bSourceID 11
> > wMaxMultiplier 0
> > bControlSize2
> > bmControls 0x
> > iProcessing 0
> > bmVideoStandards 0x09
> > None
> > SECAM - 625/50
> > VideoControl Interface Descriptor:
> > bLength 9
> > bDescriptorType36
> > bDescriptorSubtype 3 (OUTPUT_TERMINAL)
> > bTerminalID 8
> > wTerminalType 0x0101 USB Streaming
> > bAssocTerminal 0
> > bSourceID 10
> > iTerminal 0
> > VideoControl Interface Descriptor:
> > bLength25
> > bDescriptorType36
> > bDescriptorSubtype 6 (EXTENSION_UNIT)
> > bUnitID12
> > guidExtensionCode {45b5da73-23c1-4a3d-a368-610f078c4397}
> > bNumControl 0
> > bNrPins 1
> > baSourceID( 0) 9
> > bControlSize0
> > iExtension 0
This extension unit is strange, it exposes no control.
> > VideoControl Interface Descriptor:
> > bLength27
> > bDescriptorType36
> > bDescriptorSubtype 6 (EXTENSION_UNIT)
> > bUnitID10
> > guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
> > bNumControl 2
> > bNrPins 1
> > baSourceID( 0) 12
> > bControlSize2
> > bmControls( 0) 0x00
> > bmControls( 1) 0x06
> > iExtension 0
This one exposes two controls, which are likely used to control the IR light.
I however suspect that the controls merely expose an indirect way to read/
write internal registers, so we would really need to capture a USB trace when
using the device in Windows (assuming that the machine is shipped with
software that can control the IR light).
[snip]
--
Regards,
Laurent Pinchart
i.MX6: can't capture on MIPI-CSI2 with DS90UB954
Hi there,
I am using the i.MX6D from Digi (connect core 6 sbc) with a mailine
kernel (well, 4.14 right now) and have an issue with mipi-csi2
capture.
First I will give brief explanation of my setup, and then I will
detail the issue.
I have a camera sensor (OV2732, but could be any other sensor)
connected on a DS90UB953 FPD-Link III serializer.
Then a coax cable propagates the signal to a DS90UB954 FPD-Link III
deserializer.
The DS90UB954 has the ability to work in a pattern generation mode,
and I will use it for the rest of the discussion.
It is an I²C device, and I have written a basic driver (for the moment
;)) in order to make it visible on the imx6-mipi-csi2 bus as a camera
sensor.
I can give an access to the driver if necessary.
I then program the MC pipeline :
media-ctl -l "'ds90ub954 2-0034':0 -> 'imx6-mipi-csi2':0[1]" -v
media-ctl -l "'imx6-mipi-csi2':1 -> 'ipu1_csi0_mux':0[1]" -v
media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" -v
media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
media-ctl -V "'ds90ub954 2-0034':0 [fmt:RGB888_1X24/1280x720 field:none]"
media-ctl -V "'imx6-mipi-csi2':1 [fmt:RGB888_1X24/1280x720 field:none]"
media-ctl -V "'ipu1_csi0_mux':2 [fmt:RGB888_1X24/1280x720 field:none]"
media-ctl -V "'ipu1_csi0':2 [fmt:RGB888_1X24/1280x720 field:none]"
Everything works fine, all nodes are correctly configured, and the
DS90UB954 is normaly sending data on 2 lanes, with VC-ID=0.
The pattern is 1280x720@30 RGB888.
Then, I start a Gstreamer pipeline (I tried with v4l2-ctl and have the
same issue though) :
GST_DEBUG="v4l2:5" gst-launch-1.0 v4l2src device=/dev/video4 !
video/x-raw, width=1280, height=720, format=RGB ! fakesink
And... well, I had to use this patch
https://lkml.org/lkml/2017/3/11/270 in order to go further, but I am
finishing into :
[ 164.077302] imx-ipuv3-csi imx-ipuv3-csi.0: stream ON
[ 164.097955] imx-ipuv3-csi imx-ipuv3-csi.0: FI=3 usec
[ 165.129424] ipu1_csi0: EOF timeout
[ 165.142395] imx-ipuv3-csi imx-ipuv3-csi.0: stream OFF
[ 166.169299] ipu1_csi0: wait last EOF timeout
Sounds like a recurrent issue on this ML :).
I can think of several things which could explain this, but I tried a
lot and am a bit stuck.
The clock is set to 800MHz on DS90UB954 side.
=> Should CSI2_PHY_TST_CTRL1 be 0x32 ? 0x12 ? or 0x4a (ie 400MHz) ?
I think I have tried all but still the same issue.
Maybe this could be a hint, when booting, the first stream-on leads to:
imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200 => just a warning now
imx6-mipi-csi2: clock lane timeout, phy_state = 0x0230
The next one leads to the EOF timeout.
Here is the dts part BTW :
{
status = "okay";
ds90ub954: camera@34 {
compatible = "ti,ds90ub954";
status = "okay";
reg = <0x34>;
clocks = < IMX6QDL_CLK_CKO>;
clock-names = "xclk";
port {
#address-cells = <1>;
#size-cells = <0>;
ds90ub954_out0: endpoint {
remote-endpoint = <_csi2_in>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
};
};
};
_csi {
status = "okay";
port@0 {
reg = <0>;
mipi_csi2_in: endpoint {
remote-endpoint = <_out0>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
};
};
If ayone has a suggestion...
Thanks a lot !
Regards,
JM
[PATCH dvb v1 4/4] media: dvb_frontend: remove __func__ from dev_dbg()
From: Victor Toso
As dynamic debug can be instructed to add the function name to the
debug output using +f switch, we can remove __func__ from all
dev_dbg() calls. If not, a user that sets +f in dynamic debug would
get duplicated function name.
Signed-off-by: Victor Toso
---
drivers/media/dvb-core/dvb_frontend.c | 142 +-
1 file changed, 69 insertions(+), 73 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 961207cf09eb..ab6d778aa641 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -251,7 +251,7 @@ static void dvb_frontend_add_event(struct dvb_frontend *fe,
struct dvb_frontend_event *e;
int wp;
- dev_dbg(fe->dvb->device, "%s:\n", __func__);
+ dev_dbg(fe->dvb->device, "\n");
if ((status & FE_HAS_LOCK) && has_get_frontend(fe))
dtv_get_frontend(fe, c, >parameters_out);
@@ -293,7 +293,7 @@ static int dvb_frontend_get_event(struct dvb_frontend *fe,
struct dvb_frontend_private *fepriv = fe->frontend_priv;
struct dvb_fe_events *events = >events;
- dev_dbg(fe->dvb->device, "%s:\n", __func__);
+ dev_dbg(fe->dvb->device, "\n");
if (events->overflow) {
events->overflow = 0;
@@ -334,8 +334,8 @@ static void dvb_frontend_clear_events(struct dvb_frontend
*fe)
static void dvb_frontend_init(struct dvb_frontend *fe)
{
dev_dbg(fe->dvb->device,
- "%s: initialising adapter %i frontend %i (%s)...\n",
- __func__, fe->dvb->num, fe->id, fe->ops.info.name);
+ "initialising adapter %i frontend %i (%s)...\n",
+ fe->dvb->num, fe->id, fe->ops.info.name);
if (fe->ops.init)
fe->ops.init(fe);
@@ -362,7 +362,7 @@ static void dvb_frontend_swzigzag_update_delay(struct
dvb_frontend_private *fepr
int q2;
struct dvb_frontend *fe = fepriv->dvbdev->priv;
- dev_dbg(fe->dvb->device, "%s:\n", __func__);
+ dev_dbg(fe->dvb->device, "\n");
if (locked)
(fepriv->quality) = (fepriv->quality * 220 + 36 * 256) / 256;
@@ -458,8 +458,8 @@ static int dvb_frontend_swzigzag_autotune(struct
dvb_frontend *fe, int check_wra
}
dev_dbg(fe->dvb->device,
- "%s: drift:%i inversion:%i auto_step:%i auto_sub_step:%i
started_auto_step:%i\n",
- __func__, fepriv->lnb_drift, fepriv->inversion,
+ "drift:%i inversion:%i auto_step:%i auto_sub_step:%i
started_auto_step:%i\n",
+ fepriv->lnb_drift, fepriv->inversion,
fepriv->auto_step, fepriv->auto_sub_step,
fepriv->started_auto_step);
@@ -661,7 +661,7 @@ static int dvb_frontend_thread(void *data)
bool re_tune = false;
bool semheld = false;
- dev_dbg(fe->dvb->device, "%s:\n", __func__);
+ dev_dbg(fe->dvb->device, "\n");
fepriv->check_wrapped = 0;
fepriv->quality = 0;
@@ -710,10 +710,10 @@ static int dvb_frontend_thread(void *data)
algo = fe->ops.get_frontend_algo(fe);
switch (algo) {
case DVBFE_ALGO_HW:
- dev_dbg(fe->dvb->device, "%s: Frontend ALGO =
DVBFE_ALGO_HW\n", __func__);
+ dev_dbg(fe->dvb->device, "Frontend ALGO =
DVBFE_ALGO_HW\n");
if (fepriv->state & FESTATE_RETUNE) {
- dev_dbg(fe->dvb->device, "%s: Retune
requested, FESTATE_RETUNE\n", __func__);
+ dev_dbg(fe->dvb->device, "Retune
requested, FESTATE_RETUNE\n");
re_tune = true;
fepriv->state = FESTATE_TUNED;
} else {
@@ -724,19 +724,21 @@ static int dvb_frontend_thread(void *data)
fe->ops.tune(fe, re_tune,
fepriv->tune_mode_flags, >delay, );
if (s != fepriv->status &&
!(fepriv->tune_mode_flags & FE_TUNE_MODE_ONESHOT)) {
- dev_dbg(fe->dvb->device, "%s: state
changed, adding current state\n", __func__);
+ dev_dbg(fe->dvb->device, "state
changed, adding current state\n");
dvb_frontend_add_event(fe, s);
fepriv->status = s;
}
break;
case DVBFE_ALGO_SW:
- dev_dbg(fe->dvb->device, "%s: Frontend ALGO =
DVBFE_ALGO_SW\n", __func__);
+ dev_dbg(fe->dvb->device, "Frontend ALGO =
DVBFE_ALGO_SW\n");
dvb_frontend_swzigzag(fe);
break;
[PATCH dvb v1 3/4] media: dvb-usb-v2: remove __func__ from dev_dbg()
From: Victor Toso
As dynamic debug can be instructed to add the function name to the
debug output using +f switch, we can remove __func__ from all
dev_dbg() calls. If not, a user that sets +f in dynamic debug would
get duplicated function name.
Signed-off-by: Victor Toso
---
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 105 ++--
drivers/media/usb/dvb-usb-v2/dvb_usb_urb.c | 7 +-
2 files changed, 55 insertions(+), 57 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
index d55ef016d418..ad554668cc86 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -37,7 +37,7 @@ static int dvb_usbv2_download_firmware(struct dvb_usb_device
*d,
{
int ret;
const struct firmware *fw;
- dev_dbg(>udev->dev, "%s:\n", __func__);
+ dev_dbg(>udev->dev, "\n");
if (!d->props->download_firmware) {
ret = -EINVAL;
@@ -62,14 +62,14 @@ static int dvb_usbv2_download_firmware(struct
dvb_usb_device *d,
return ret;
err:
- dev_dbg(>udev->dev, "%s: failed=%d\n", __func__, ret);
+ dev_dbg(>udev->dev, "failed=%d\n", ret);
return ret;
}
static int dvb_usbv2_i2c_init(struct dvb_usb_device *d)
{
int ret;
- dev_dbg(>udev->dev, "%s:\n", __func__);
+ dev_dbg(>udev->dev, "\n");
if (!d->props->i2c_algo)
return 0;
@@ -87,13 +87,13 @@ static int dvb_usbv2_i2c_init(struct dvb_usb_device *d)
return 0;
err:
- dev_dbg(>udev->dev, "%s: failed=%d\n", __func__, ret);
+ dev_dbg(>udev->dev, "failed=%d\n", ret);
return ret;
}
static int dvb_usbv2_i2c_exit(struct dvb_usb_device *d)
{
- dev_dbg(>udev->dev, "%s:\n", __func__);
+ dev_dbg(>udev->dev, "\n");
if (d->i2c_adap.algo)
i2c_del_adapter(>i2c_adap);
@@ -133,7 +133,7 @@ static int dvb_usbv2_remote_init(struct dvb_usb_device *d)
{
int ret;
struct rc_dev *dev;
- dev_dbg(>udev->dev, "%s:\n", __func__);
+ dev_dbg(>udev->dev, "\n");
if (dvb_usbv2_disable_rc_polling || !d->props->get_rc_config)
return 0;
@@ -188,13 +188,13 @@ static int dvb_usbv2_remote_init(struct dvb_usb_device *d)
return 0;
err:
- dev_dbg(>udev->dev, "%s: failed=%d\n", __func__, ret);
+ dev_dbg(>udev->dev, "failed=%d\n", ret);
return ret;
}
static int dvb_usbv2_remote_exit(struct dvb_usb_device *d)
{
- dev_dbg(>udev->dev, "%s:\n", __func__);
+ dev_dbg(>udev->dev, "\n");
if (d->rc_dev) {
cancel_delayed_work_sync(>rc_query_work);
@@ -232,7 +232,7 @@ static void dvb_usb_data_complete_raw(struct
usb_data_stream *stream, u8 *buf,
static int dvb_usbv2_adapter_stream_init(struct dvb_usb_adapter *adap)
{
- dev_dbg(_to_d(adap)->udev->dev, "%s: adap=%d\n", __func__,
+ dev_dbg(_to_d(adap)->udev->dev, "adap=%d\n",
adap->id);
adap->stream.udev = adap_to_d(adap)->udev;
@@ -244,7 +244,7 @@ static int dvb_usbv2_adapter_stream_init(struct
dvb_usb_adapter *adap)
static int dvb_usbv2_adapter_stream_exit(struct dvb_usb_adapter *adap)
{
- dev_dbg(_to_d(adap)->udev->dev, "%s: adap=%d\n", __func__,
+ dev_dbg(_to_d(adap)->udev->dev, "adap=%d\n",
adap->id);
return usb_urb_exitv2(>stream);
@@ -257,8 +257,8 @@ static int dvb_usb_start_feed(struct dvb_demux_feed
*dvbdmxfeed)
int ret = 0;
struct usb_data_stream_properties stream_props;
dev_dbg(>udev->dev,
- "%s: adap=%d active_fe=%d feed_type=%d setting pid
[%s]: %04x (%04d) at index %d\n",
- __func__, adap->id, adap->active_fe, dvbdmxfeed->type,
+ "adap=%d active_fe=%d feed_type=%d setting pid [%s]:
%04x (%04d) at index %d\n",
+ adap->id, adap->active_fe, dvbdmxfeed->type,
adap->pid_filtering ? "yes" : "no", dvbdmxfeed->pid,
dvbdmxfeed->pid, dvbdmxfeed->index);
@@ -334,7 +334,7 @@ static int dvb_usb_start_feed(struct dvb_demux_feed
*dvbdmxfeed)
}
if (ret)
- dev_dbg(>udev->dev, "%s: failed=%d\n", __func__, ret);
+ dev_dbg(>udev->dev, "failed=%d\n", ret);
return ret;
}
@@ -344,8 +344,8 @@ static int dvb_usb_stop_feed(struct dvb_demux_feed
*dvbdmxfeed)
struct dvb_usb_device *d = adap_to_d(adap);
int ret = 0;
dev_dbg(>udev->dev,
- "%s: adap=%d active_fe=%d feed_type=%d setting pid
[%s]: %04x (%04d) at index %d\n",
- __func__, adap->id, adap->active_fe, dvbdmxfeed->type,
+ "adap=%d active_fe=%d feed_type=%d setting pid [%s]:
%04x (%04d) at index %d\n",
+ adap->id, adap->active_fe, dvbdmxfeed->type,
[PATCH dvb v1 2/4] media: dvb: Use WARM definition from identify_state()
From: Victor Toso
Device should be either COLD or WARM.
This change only make usage of the existing definition.
Signed-off-by: Victor Toso
---
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
index 3b8f7931b730..d55ef016d418 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -957,9 +957,7 @@ int dvb_usbv2_probe(struct usb_interface *intf,
if (d->props->identify_state) {
const char *name = NULL;
ret = d->props->identify_state(d, );
- if (ret == 0) {
- ;
- } else if (ret == COLD) {
+ if (ret == COLD) {
dev_info(>udev->dev,
"%s: found a '%s' in cold state\n",
KBUILD_MODNAME, d->name);
@@ -984,7 +982,7 @@ int dvb_usbv2_probe(struct usb_interface *intf,
} else {
goto err_free_all;
}
- } else {
+ } else if (ret != WARM) {
goto err_free_all;
}
}
--
2.17.2
[PATCH dvb v1 1/4] af9033: Remove duplicated switch statement
From: Victor Toso
The switch before set is_af9035 or is_it9135 which makes the second
switch redundant. Keeping the comment as to avoid sleep on IT9135.
Signed-off-by: Victor Toso
---
drivers/media/dvb-frontends/af9033.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index 0cd57013ea25..23b831ce3439 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -1137,16 +1137,8 @@ static int af9033_probe(struct i2c_client *client,
buf[4], buf[5], buf[6], buf[7]);
/* Sleep as chip seems to be partly active by default */
- switch (dev->cfg.tuner) {
- case AF9033_TUNER_IT9135_38:
- case AF9033_TUNER_IT9135_51:
- case AF9033_TUNER_IT9135_52:
- case AF9033_TUNER_IT9135_60:
- case AF9033_TUNER_IT9135_61:
- case AF9033_TUNER_IT9135_62:
- /* IT9135 did not like to sleep at that early */
- break;
- default:
+ /* IT9135 did not like to sleep at that early */
+ if (dev->is_af9035) {
ret = regmap_write(dev->regmap, 0x80004c, 0x01);
if (ret)
goto err_regmap_exit;
--
2.17.2
[PATCH dvb v1 0/4] miscellaneous changes
From: Victor Toso Hi, As mentioned on IRC earlier [0], I'm trying to learn a bit about Kernel and I'm using a usb dongle for dvb-t, which seems to work fine, for that. Two patches are related to dynamic debug that I have enabled and it ends up printing doubled function name. The other two patches are minor code changes that I did while reading code path related to the device I own. Let me know if those make sense to you or not. For now, I have also two questions, both made on IRC #linuxtv but got no replies so I hope it is fine to ask here too (otherwise, let me know where I can ask!) 1) If I do remove my usb device, I see that several modules are kept loaded. I'm wondering if this is intentional or a bug. I can modprobe -r all of them just fine, no one is using them. 2) What is the correct way to verify with v4l2-compliance tool, the /dev/dvb/adapater#/* devices? I tried a few combinations but I'm not trusting the results so far. [0] https://linuxtv.org/irc/irclogger_log/linuxtv?date=2018-10-25,Thu=6#l2 Ah, yes, this is my first contribution to the kernel, I checked with scripts/checkpatch.pl but I'm welcome to advices if you see the need! Cheers, Victor Toso (4): af9033: Remove duplicated switch statement media: dvb: Use WARM definition from identify_state() media: dvb-usb-v2: remove __func__ from dev_dbg() media: dvb_frontend: remove __func__ from dev_dbg() drivers/media/dvb-core/dvb_frontend.c | 142 ++-- drivers/media/dvb-frontends/af9033.c| 12 +- drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 111 --- drivers/media/usb/dvb-usb-v2/dvb_usb_urb.c | 7 +- 4 files changed, 128 insertions(+), 144 deletions(-) -- 2.17.2
Re: uvcvideo: IR camera lights only every second frame
Hi Jiri, On 30/10/2018 14:36, Jiri Slaby wrote: > Hi, > > I have a Dell Lattitude 7280 with two webcams. The standard one works > fine (/dev/video0). The other one is an IR camera (/dev/video1). The > camera proper works fine and produces 340x374 frames. But there is an IR > led supposed to light the object. The video is 30fps, but the LED seems > to emit light only on half of the frames, i.e. on every second frame (15 > fps). This makes the video blink a lot. The two consecutive frames look > like: > https://www.fi.muni.cz/~xslaby/sklad/mpv-shot0002.jpg > https://www.fi.muni.cz/~xslaby/sklad/mpv-shot0003.jpg > > Do you have any ideas what to check/test? I have an HP Spectre with IR camera, and it also 'flashes' alternate frames. I assumed this was something to do with controlling the lighting for face recognition some how. I'm fairly sure we don't control the 'IR flash' from the UVC. I wonder if there is a control parameter for the IR led in the extension-units? -- Regards Kieran > $ v4l2-ctl --all -d /dev/video2 > Driver Info (not using libv4l2): > Driver name : uvcvideo > Card type : Integrated_Webcam_HD: Integrate > Bus info : usb-:00:14.0-5 > Driver version: 4.18.15 > Capabilities : 0x84A1 > Video Capture > Metadata Capture > Streaming > Extended Pix Format > Device Capabilities > Device Caps : 0x0421 > Video Capture > Streaming > Extended Pix Format > Priority: 2 > Video input : 0 (Camera 11: ok) > Format Video Capture: > Width/Height : 340/374 > Pixel Format : 'YUYV' > Field : None > Bytes per Line: 680 > Size Image: 254320 > Colorspace: sRGB > Transfer Function : Default (maps to sRGB) > YCbCr/HSV Encoding: Default (maps to ITU-R 601) > Quantization : Default (maps to Limited Range) > Flags : > Crop Capability Video Capture: > Bounds : Left 0, Top 0, Width 340, Height 374 > Default : Left 0, Top 0, Width 340, Height 374 > Pixel Aspect: 1/1 > Selection: crop_default, Left 0, Top 0, Width 340, Height 374 > Selection: crop_bounds, Left 0, Top 0, Width 340, Height 374 > Streaming Parameters Video Capture: > Capabilities : timeperframe > Frames per second: 30.000 (30/1) > Read buffers : 0 > > > > > > $ lsusb -vs 1:3 > Bus 001 Device 003: ID 0bda:5691 Realtek Semiconductor Corp. > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 239 Miscellaneous Device > bDeviceSubClass 2 > bDeviceProtocol 1 Interface Association > bMaxPacketSize064 > idVendor 0x0bda Realtek Semiconductor Corp. > idProduct 0x5691 > bcdDevice 60.12 > iManufacturer 3 CNFGE16N5214300025C2 > iProduct1 Integrated_Webcam_HD > iSerial 2 0001 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 1041 > bNumInterfaces 4 > bConfigurationValue 1 > iConfiguration 4 USB Camera > bmAttributes 0x80 > (Bus Powered) > MaxPower 500mA > ** UNRECOGNIZED: 28 ff 42 49 53 54 00 01 06 06 10 00 00 00 00 00 01 > 07 f4 01 02 08 f4 01 03 09 f4 01 04 0a f4 01 05 0b f4 01 06 0c e8 03 > Interface Association: > bLength 8 > bDescriptorType11 > bFirstInterface 0 > bInterfaceCount 2 > bFunctionClass 14 Video > bFunctionSubClass 3 Video Interface Collection > bFunctionProtocol 0 > iFunction 5 Integrated Webcam > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass14 Video > bInterfaceSubClass 1 Video Control > bInterfaceProtocol 0 > iInterface 5 Integrated Webcam > VideoControl Interface Descriptor: > bLength13 > bDescriptorType36 > bDescriptorSubtype 1 (HEADER) > bcdUVC 1.00 > wTotalLength 107 > dwClockFrequency 15.00MHz > bInCollection 1 > baInterfaceNr( 0) 1 > VideoControl Interface Descriptor: > bLength18 > bDescriptorType36 > bDescriptorSubtype 2 (INPUT_TERMINAL) > bTerminalID 1 > wTerminalType 0x0201 Camera Sensor
Re: [PATCH 4/4] SoC camera: Tidy the header
Em Tue, 30 Oct 2018 01:00:29 +0200
Sakari Ailus escreveu:
> Clean up the SoC camera framework header. It only exists now to keep board
> code compiling. The header can be removed once the board code dependencies
> to it has been removed.
>
> Signed-off-by: Sakari Ailus
> ---
> include/media/soc_camera.h | 335
> -
> 1 file changed, 335 deletions(-)
>
> diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
> index b7e42a1b0910..14d19da6052a 100644
> --- a/include/media/soc_camera.h
> +++ b/include/media/soc_camera.h
> @@ -22,172 +22,6 @@
> #include
> #include
That doesn't make any sense. soc_camera.h should have the same fate
as the entire soc_camera infrastructure: either be removed or moved
to staging, and everything else that doesn't have the same fate
should get rid of this header.
Regards,
Mauro
>
> -struct file;
> -struct soc_camera_desc;
> -struct soc_camera_async_client;
> -
> -struct soc_camera_device {
> - struct list_head list; /* list of all registered devices */
> - struct soc_camera_desc *sdesc;
> - struct device *pdev;/* Platform device */
> - struct device *parent; /* Camera host device */
> - struct device *control; /* E.g., the i2c client */
> - s32 user_width;
> - s32 user_height;
> - u32 bytesperline; /* for padding, zero if unused */
> - u32 sizeimage;
> - enum v4l2_colorspace colorspace;
> - unsigned char iface;/* Host number */
> - unsigned char devnum; /* Device number per host */
> - struct soc_camera_sense *sense; /* See comment in struct definition */
> - struct video_device *vdev;
> - struct v4l2_ctrl_handler ctrl_handler;
> - const struct soc_camera_format_xlate *current_fmt;
> - struct soc_camera_format_xlate *user_formats;
> - int num_user_formats;
> - enum v4l2_field field; /* Preserve field over close() */
> - void *host_priv;/* Per-device host private data */
> - /* soc_camera.c private count. Only accessed with .host_lock held */
> - int use_count;
> - struct file *streamer; /* stream owner */
> - struct v4l2_clk *clk;
> - /* Asynchronous subdevice management */
> - struct soc_camera_async_client *sasc;
> - /* video buffer queue */
> - struct vb2_queue vb2_vidq;
> -};
> -
> -/* Host supports programmable stride */
> -#define SOCAM_HOST_CAP_STRIDE(1 << 0)
> -
> -enum soc_camera_subdev_role {
> - SOCAM_SUBDEV_DATA_SOURCE = 1,
> - SOCAM_SUBDEV_DATA_SINK,
> - SOCAM_SUBDEV_DATA_PROCESSOR,
> -};
> -
> -struct soc_camera_async_subdev {
> - struct v4l2_async_subdev asd;
> - enum soc_camera_subdev_role role;
> -};
> -
> -struct soc_camera_host {
> - struct v4l2_device v4l2_dev;
> - struct list_head list;
> - struct mutex host_lock; /* Main synchronisation lock */
> - struct mutex clk_lock; /* Protect pipeline modifications */
> - unsigned char nr; /* Host number */
> - u32 capabilities;
> - struct soc_camera_device *icd; /* Currently attached client */
> - void *priv;
> - const char *drv_name;
> - struct soc_camera_host_ops *ops;
> - struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
> - unsigned int *asd_sizes;/* 0-terminated array of asd group
> sizes */
> -};
> -
> -struct soc_camera_host_ops {
> - struct module *owner;
> - int (*add)(struct soc_camera_device *);
> - void (*remove)(struct soc_camera_device *);
> - int (*clock_start)(struct soc_camera_host *);
> - void (*clock_stop)(struct soc_camera_host *);
> - /*
> - * .get_formats() is called for each client device format, but
> - * .put_formats() is only called once. Further, if any of the calls to
> - * .get_formats() fail, .put_formats() will not be called at all, the
> - * failing .get_formats() must then clean up internally.
> - */
> - int (*get_formats)(struct soc_camera_device *, unsigned int,
> -struct soc_camera_format_xlate *);
> - void (*put_formats)(struct soc_camera_device *);
> - int (*get_selection)(struct soc_camera_device *, struct v4l2_selection
> *);
> - int (*set_selection)(struct soc_camera_device *, struct v4l2_selection
> *);
> - /*
> - * The difference to .set_selection() is, that .set_liveselection is
> not allowed
> - * to change the output sizes
> - */
> - int (*set_liveselection)(struct soc_camera_device *, struct
> v4l2_selection *);
> - int (*set_fmt)(struct soc_camera_device *, struct v4l2_format *);
> - int (*try_fmt)(struct soc_camera_device *, struct v4l2_format *);
> - int (*init_videobuf2)(struct vb2_queue *,
> - struct soc_camera_device *);
> - int (*querycap)(struct soc_camera_host *, struct
Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers
Em Tue, 30 Oct 2018 01:21:34 +0200 Sakari Ailus escreveu: > The SoC camera framework has been obsolete for some time and it is no > longer functional. A few drivers have been converted to the V4L2 > sub-device API but for the rest the conversion has not taken place yet. > > In order to keep the tree clean and to avoid keep maintaining > non-functional and obsolete code, remove the SoC camera framework as well > as the drivers that depend on it. > > Signed-off-by: Sakari Ailus > --- > Resending, this time with git format-patch -D . > > MAINTAINERS|8 - > drivers/media/i2c/Kconfig |8 - > drivers/media/i2c/Makefile |1 - > drivers/media/i2c/soc_camera/Kconfig | 66 - > drivers/media/i2c/soc_camera/Makefile | 10 - > drivers/media/i2c/soc_camera/ov9640.h | 208 -- > drivers/media/i2c/soc_camera/soc_mt9m001.c | 757 --- > drivers/media/i2c/soc_camera/soc_mt9t112.c | 1157 --- > drivers/media/i2c/soc_camera/soc_mt9v022.c | 1012 - > drivers/media/i2c/soc_camera/soc_ov5642.c | 1087 -- > drivers/media/i2c/soc_camera/soc_ov772x.c | 1123 -- > drivers/media/i2c/soc_camera/soc_ov9640.c | 738 --- > drivers/media/i2c/soc_camera/soc_ov9740.c | 996 - > drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c | 1415 - > drivers/media/i2c/soc_camera/soc_tw9910.c | 999 - I don't see why we should remove those. I mean, Jacopo is actually converting those drivers to not depend on soc_camera, and it is a way better to review those patches with the old code in place. IMHO, the best would be to move those to /staging, eventually depending on BROKEN. > drivers/media/platform/Kconfig |1 - > drivers/media/platform/Makefile|2 - > drivers/media/platform/soc_camera/Kconfig | 26 - > drivers/media/platform/soc_camera/Makefile |9 - > .../platform/soc_camera/sh_mobile_ceu_camera.c | 1810 > drivers/media/platform/soc_camera/soc_camera.c | 2169 > > .../platform/soc_camera/soc_camera_platform.c | 188 -- > drivers/media/platform/soc_camera/soc_mediabus.c | 533 - > drivers/media/platform/soc_camera/soc_scale_crop.c | 426 > drivers/media/platform/soc_camera/soc_scale_crop.h | 47 - > drivers/staging/media/Kconfig |4 - > drivers/staging/media/Makefile |2 - > drivers/staging/media/imx074/Kconfig |5 - > drivers/staging/media/imx074/Makefile |1 - > drivers/staging/media/imx074/TODO |5 - > drivers/staging/media/imx074/imx074.c | 496 - > drivers/staging/media/mt9t031/Kconfig |5 - > drivers/staging/media/mt9t031/Makefile |1 - > drivers/staging/media/mt9t031/TODO |5 - > drivers/staging/media/mt9t031/mt9t031.c| 857 > 35 files changed, 16177 deletions(-) > delete mode 100644 drivers/media/i2c/soc_camera/Kconfig > delete mode 100644 drivers/media/i2c/soc_camera/Makefile > delete mode 100644 drivers/media/i2c/soc_camera/ov9640.h > delete mode 100644 drivers/media/i2c/soc_camera/soc_mt9m001.c > delete mode 100644 drivers/media/i2c/soc_camera/soc_mt9t112.c > delete mode 100644 drivers/media/i2c/soc_camera/soc_mt9v022.c > delete mode 100644 drivers/media/i2c/soc_camera/soc_ov5642.c > delete mode 100644 drivers/media/i2c/soc_camera/soc_ov772x.c > delete mode 100644 drivers/media/i2c/soc_camera/soc_ov9640.c > delete mode 100644 drivers/media/i2c/soc_camera/soc_ov9740.c > delete mode 100644 drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c > delete mode 100644 drivers/media/i2c/soc_camera/soc_tw9910.c > delete mode 100644 drivers/media/platform/soc_camera/Kconfig > delete mode 100644 drivers/media/platform/soc_camera/Makefile > delete mode 100644 drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c > delete mode 100644 drivers/media/platform/soc_camera/soc_camera.c > delete mode 100644 drivers/media/platform/soc_camera/soc_camera_platform.c > delete mode 100644 drivers/media/platform/soc_camera/soc_mediabus.c > delete mode 100644 drivers/media/platform/soc_camera/soc_scale_crop.c > delete mode 100644 drivers/media/platform/soc_camera/soc_scale_crop.h > delete mode 100644 drivers/staging/media/imx074/Kconfig > delete mode 100644 drivers/staging/media/imx074/Makefile > delete mode 100644 drivers/staging/media/imx074/TODO > delete mode 100644 drivers/staging/media/imx074/imx074.c > delete mode 100644 drivers/staging/media/mt9t031/Kconfig > delete mode 100644 drivers/staging/media/mt9t031/Makefile > delete mode 100644 drivers/staging/media/mt9t031/TODO > delete mode 100644
Re: Adding to input-event-codes.h - feedback welcome
Em Tue, 23 Oct 2018 06:55:13 -0700 VDR User escreveu: > Hi, > > I've noticed a lot of common & useful remote control buttons are > missing. I'd like to suggest or submit patches to add some of them > since Linux is so wildly used for media playback (via remote > controls). I've spoken to Sean Young (and cc'ed him here), who does a > ton with Linux rc, and he agrees it would be good to add them. Once > added to input-event-codes.h, we could then start adding/updating rc > keymaps accordingly. As those keys are related to remote controllers, better to c/c the Linux Media mailing list. Btw, I agree with you here with regards to the idea: there are several keys that are commonly found on remote controllers and are not easy to map into the ones defined by input-event-codes.h. We even had to add a table at media documentation, in order to describe how each key should be mapped: Documentation/media/uapi/rc/rc-tables.rst IMHO, nowadays I would actually try to review such documentation and eventually move it to Documentation/input, as there are several cases where it is not trivial to map an specific key to the Linux key code. Still, I think that this discussion could be more productive if you submit it as a patch (or a patch series). > > The following is a list of (common) keys I'd like to propose be added. Please > let us know what you think. > > KEY_LIVE_TV: Jump directly to live tv view (from watching recordings, > menus, VOD, etc). KEY_TV exists but only to select a "TV" input device > but not related to the actual content being watched. > > KEY_PIP: Toggle Picture-In-Picture on/off. > > KEY_PIP_POSITION: Used to change PIP window position (typically upper left, > lower left, lower right, upper right) > > KEY_PIP_SWAP: Used to swap the main & PIP windows contents. (KEY_AB > exists but is broad and could already be used for another function > such as swapping audio outputs.) Yeah, those seem to be missing. > > KEY_USER1...KEY_USER16: Provide user-defined keys for special buttons > that a remote control may have that are usable but may not be labeled > to a specific common action. For example, we use Dish Network remote > controls with our Linux-based htpc's - There's "DISH" and "Dish On > Demand" buttons that are usable but not related to a common action. > With KEY_USER* they could be mapped and used however the user wants. > 16 user keys may be a lot, and 8 could be a better number, but any > less than that is too limiting. There are actually KEY_RED & friends that are normally used for user-defined keys. Not sure if I like the idea of a KEY_USER?, as it may mean that the same key would be mapped different on different remote controllers. We might be using KEY_FN?? or BTN_* for those, but I guess that this is also not a good idea. > > Any feedback or suggestions is appreciated. > > Best regards, > Derek Thanks, Mauro
Re: [PATCH] dvb: Allow MAC addresses to be mapped to stable device names with udev
Em Mon, 24 Sep 2018 11:10:31 +0100
David Howells escreveu:
> Some devices, such as the DVBSky S952 and T982 cards, are dual port cards
> that provide two cx23885 devices on the same PCI device, which means the
> attributes available for writing udev rules are exactly the same, apart
> from the adapter number. Unfortunately, the adapter numbers are dependent
> on the order in which things are initialised, so this can change over
> different releases of the kernel.
>
> Devices have a MAC address available, which is printed during boot:
>
> [ 10.951517] DVBSky T982 port 1 MAC address: 00:11:22:33:44:55
> ...
> [ 10.984875] DVBSky T982 port 2 MAC address: 00:11:22:33:44:56
>
> To make it possible to distinguish these in udev, provide sysfs attributes
> to make the MAC address, adapter number and type available. There are
> other fields that could perhaps be exported also. In particular, it would
> be nice to provide the port number, but somehow that doesn't manage to
> propagate through the labyrinthine initialisation process.
>
> The new sysfs attributes can be seen from userspace as:
>
> [root@deneb ~]# ls /sys/class/dvb/dvb0.frontend0/
> dev device dvb_adapter dvb_mac dvb_type
> power subsystem uevent
> [root@deneb ~]# cat /sys/class/dvb/dvb0.frontend0/dvb_*
> 0
> 00:11:22:33:44:55
> frontend
>
> They can be used in udev rules:
>
> SUBSYSTEM=="dvb", ATTRS{vendor}=="0x14f1", ATTRS{device}=="0x8852",
> ATTRS{subsystem_device}=="0x0982", ATTR{dvb_mac}=="00:11:22:33:44:55",
> PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter9820/%%s
> $${K#*.}'", SYMLINK+="%c"
> SUBSYSTEM=="dvb", ATTRS{vendor}=="0x14f1", ATTRS{device}=="0x8852",
> ATTRS{subsystem_device}=="0x0982", ATTR{dvb_mac}=="00:11.22.33.44.56",
> PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter9821/%%s
> $${K#*.}'", SYMLINK+="%c"
>
> where the match is made with ATTR{dvb_mac} or similar. The rules above
> make symlinks from /dev/dvb/adapter982/* to /dev/dvb/adapterXX/*.
>
> Note that binding the dvb-net device to a network interface and changing it
> there does not reflect back into the the dvb_adapter struct and doesn't
> change the MAC address here. This means that a system with two identical
> cards in it may need to distinguish them by some other means than MAC
> address.
>
> Signed-off-by: David Howells
Looks OK to me.
Michael/Sean/Brad,
Any comments? If not, I'll probably submit it this week upstream.
> ---
>
> Documentation/ABI/testing/sysfs-class-dvb | 29 +++
> Documentation/media/dvb-drivers/udev.rst | 29 +++
> Documentation/media/uapi/dvb/intro.rst|7 +++
> Documentation/media/uapi/dvb/stable_names.rst | 66
> +
> drivers/media/dvb-core/dvbdev.c | 36 ++
> 5 files changed, 167 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-class-dvb
> create mode 100644 Documentation/media/uapi/dvb/stable_names.rst
>
> diff --git a/Documentation/ABI/testing/sysfs-class-dvb
> b/Documentation/ABI/testing/sysfs-class-dvb
> new file mode 100644
> index ..09e3be329c92
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-dvb
> @@ -0,0 +1,29 @@
> +What:/sys/class/dvb/.../dvb_adapter
> +Date:September 2018
> +KernelVersion: 4.20
> +Contact: David Howells
> +Description:
> + This displays the assigned adapter number of a DVB device.
> +
> +What:/sys/class/dvb/.../dvb_mac
> +Date:September 2018
> +KernelVersion: 4.20
> +Contact: David Howells
> +Description:
> + This displays the mac address of a DVB device. This can be
> + used by udev to name stable device files for DVB devices and
> + avoid problems with changes in the order of device
> + initialisation changing the assigned device numbers. See:
> +
> + Documentation/media/dvb-drivers/udev.rst
> + Documentation/media/uapi/dvb/stable_names.rst
> +
> + for information on how to actually do this.
> +
> +What:/sys/class/dvb/.../dvb_type
> +Date:September 2018
> +KernelVersion: 4.20
> +Contact: David Howells
> +Description:
> + This displays the object type of a DVB device interface, such
> + as "frontend" or "demux".
> diff --git a/Documentation/media/dvb-drivers/udev.rst
> b/Documentation/media/dvb-drivers/udev.rst
> index 7d7d5d82108a..df754312f1f4 100644
> --- a/Documentation/media/dvb-drivers/udev.rst
> +++ b/Documentation/media/dvb-drivers/udev.rst
> @@ -59,3 +59,32 @@ have a look at "man udev".
> For every device that registers to the sysfs subsystem with a "dvb" prefix,
> the helper script /etc/udev/scripts/dvb.sh is invoked, which will then
> create the proper device node in
VIVID/VIMC and media fuzzing
Hello Helen and linux-media, I've attended your talk "Shifting Media App Development into High Gear" on OSS Summit last week and approached you with some questions if/how this can be used for kernel testing. Thanks, turn out to be a very useful talk! I am working on syzkaller/syzbot, continuous kernel fuzzing system: https://github.com/google/syzkaller https://github.com/google/syzkaller/blob/master/docs/syzbot.md https://syzkaller.appspot.com After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M, CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in media subsystem in just 24 hours: KASAN: use-after-free Read in vb2_mmap https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ KASAN: use-after-free Write in __vb2_cleanup_fileio https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ WARNING in __vb2_queue_cancel https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ divide error in vivid_vid_cap_s_dv_timings https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ KASAN: use-after-free Read in wake_up_if_idle https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ KASAN: use-after-free Read in __vb2_perform_fileio https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ INFO: task hung in vivid_stop_generating_vid_cap https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ KASAN: null-ptr-deref Write in kthread_stop https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ Based on this I think if we put more effort into media fuzzing, it will be able to find dozens more. syzkaller needs descriptions of kernel interfaces to efficiently cover a subsystem. For example, see: https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt Hopefully you can read it without much explanation, it basically states that there is that node in /dev and here are ioctls and other syscalls that are relevant for this device and here are types of arguments and layout of involved data structures. Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*: https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt But we don't have anything for /dev/media*, fuzzer merely knows that it can open the device: https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479 and then it will just blindly execute completely random workload on it, e.g. most likely it won't be able to come up with a proper complex structure layout for some ioctls. And I am actually not completely sure about completeness and coverage of video4linux.txt descriptions too as they were contributed by somebody interested in android testing. I wonder if somebody knowledgeable in /dev/media interface be willing to contribute additional descriptions? We also have code coverage reports with the coverage fuzzer achieved so far. Here in the Cover column: https://syzkaller.appspot.com/#managers e.g. this one (but note this is a ~80MB html file): https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html This can be used to assess e.g. v4l coverage. But I don't know what's coverable in general from syscalls and what's coverable via the stub drivers in particular. So some expertise from media developers would be helpful too. Do I understand it correctly that when a process opens /dev/video* or /dev/media* it gets a private instance of the device? In particular, if several processes test this in parallel, will they collide? Or they will stress separate objects? You also mentioned that one of the devices requires some complex setup via configfs. Is this interface described somewhere? Do you think it's more profitable to pre-setup some fixed configuration for each test process? Or just give the setup interface to fuzzer and let it do random setup? Or both? Thanks in advance
Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers
Em Tue, 30 Oct 2018 09:06:08 -0300 Mauro Carvalho Chehab escreveu: > Em Tue, 30 Oct 2018 06:43:41 -0300 > Mauro Carvalho Chehab escreveu: Please ignore this e-mail. I'm experiencing some e-mail troubles today. Will resend it properly. Regards, Mauro
Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers
Em Tue, 30 Oct 2018 06:43:41 -0300 Mauro Carvalho Chehab escreveu: > Em Tue, 30 Oct 2018 01:21:34 +0200 > Sakari Ailus escreveu: > > > The SoC camera framework has been obsolete for some time and it is no > > longer functional. A few drivers have been converted to the V4L2 > > sub-device API but for the rest the conversion has not taken place yet. > > > > In order to keep the tree clean and to avoid keep maintaining > > non-functional and obsolete code, remove the SoC camera framework as well > > as the drivers that depend on it. > > > > Signed-off-by: Sakari Ailus > > --- > > Resending, this time with git format-patch -D . > > > > MAINTAINERS|8 - > > drivers/media/i2c/Kconfig |8 - > > drivers/media/i2c/Makefile |1 - > > drivers/media/i2c/soc_camera/Kconfig | 66 - > > drivers/media/i2c/soc_camera/Makefile | 10 - > > drivers/media/i2c/soc_camera/ov9640.h | 208 -- > > drivers/media/i2c/soc_camera/soc_mt9m001.c | 757 --- > > drivers/media/i2c/soc_camera/soc_mt9t112.c | 1157 --- > > drivers/media/i2c/soc_camera/soc_mt9v022.c | 1012 - > > drivers/media/i2c/soc_camera/soc_ov5642.c | 1087 -- > > drivers/media/i2c/soc_camera/soc_ov772x.c | 1123 -- > > drivers/media/i2c/soc_camera/soc_ov9640.c | 738 --- > > drivers/media/i2c/soc_camera/soc_ov9740.c | 996 - > > drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c | 1415 - > > drivers/media/i2c/soc_camera/soc_tw9910.c | 999 - > > I don't see why we should remove those. I mean, Jacopo is > actually converting those drivers to not depend on soc_camera, > and it is a way better to review those patches with the old > code in place. > > IMHO, the best would be to move those to /staging, eventually > depending on BROKEN. > > > drivers/media/platform/Kconfig |1 - > > drivers/media/platform/Makefile|2 - > > drivers/media/platform/soc_camera/Kconfig | 26 - > > drivers/media/platform/soc_camera/Makefile |9 - > > .../platform/soc_camera/sh_mobile_ceu_camera.c | 1810 > > drivers/media/platform/soc_camera/soc_camera.c | 2169 > > > > .../platform/soc_camera/soc_camera_platform.c | 188 -- > > drivers/media/platform/soc_camera/soc_mediabus.c | 533 - > > drivers/media/platform/soc_camera/soc_scale_crop.c | 426 > > drivers/media/platform/soc_camera/soc_scale_crop.h | 47 - > > drivers/staging/media/Kconfig |4 - > > drivers/staging/media/Makefile |2 - > > drivers/staging/media/imx074/Kconfig |5 - > > drivers/staging/media/imx074/Makefile |1 - > > drivers/staging/media/imx074/TODO |5 - > > drivers/staging/media/imx074/imx074.c | 496 - > > drivers/staging/media/mt9t031/Kconfig |5 - > > drivers/staging/media/mt9t031/Makefile |1 - > > drivers/staging/media/mt9t031/TODO |5 - > > drivers/staging/media/mt9t031/mt9t031.c| 857 > > 35 files changed, 16177 deletions(-) > > delete mode 100644 drivers/media/i2c/soc_camera/Kconfig > > delete mode 100644 drivers/media/i2c/soc_camera/Makefile > > delete mode 100644 drivers/media/i2c/soc_camera/ov9640.h > > delete mode 100644 drivers/media/i2c/soc_camera/soc_mt9m001.c > > delete mode 100644 drivers/media/i2c/soc_camera/soc_mt9t112.c > > delete mode 100644 drivers/media/i2c/soc_camera/soc_mt9v022.c > > delete mode 100644 drivers/media/i2c/soc_camera/soc_ov5642.c > > delete mode 100644 drivers/media/i2c/soc_camera/soc_ov772x.c > > delete mode 100644 drivers/media/i2c/soc_camera/soc_ov9640.c > > delete mode 100644 drivers/media/i2c/soc_camera/soc_ov9740.c > > delete mode 100644 drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c > > delete mode 100644 drivers/media/i2c/soc_camera/soc_tw9910.c > > delete mode 100644 drivers/media/platform/soc_camera/Kconfig > > delete mode 100644 drivers/media/platform/soc_camera/Makefile > > delete mode 100644 drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c > > delete mode 100644 drivers/media/platform/soc_camera/soc_camera.c > > delete mode 100644 drivers/media/platform/soc_camera/soc_camera_platform.c > > delete mode 100644 drivers/media/platform/soc_camera/soc_mediabus.c > > delete mode 100644 drivers/media/platform/soc_camera/soc_scale_crop.c > > delete mode 100644 drivers/media/platform/soc_camera/soc_scale_crop.h > > delete mode 100644 drivers/staging/media/imx074/Kconfig > > delete mode 100644 drivers/staging/media/imx074/Makefile > > delete mode 100644 drivers/staging/media/imx074/TODO > > delete mode 100644
Re: [PATCH 4/4] SoC camera: Tidy the header
Em Tue, 30 Oct 2018 01:00:29 +0200
Sakari Ailus escreveu:
> Clean up the SoC camera framework header. It only exists now to keep board
> code compiling. The header can be removed once the board code dependencies
> to it has been removed.
>
> Signed-off-by: Sakari Ailus
> ---
> include/media/soc_camera.h | 335
> -
> 1 file changed, 335 deletions(-)
>
> diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
> index b7e42a1b0910..14d19da6052a 100644
> --- a/include/media/soc_camera.h
> +++ b/include/media/soc_camera.h
> @@ -22,172 +22,6 @@
> #include
> #include
That doesn't make any sense. soc_camera.h should have the same fate
as the entire soc_camera infrastructure: either be removed or moved
to staging, and everything else that doesn't have the same fate
should get rid of this header.
Regards,
Mauro
>
> -struct file;
> -struct soc_camera_desc;
> -struct soc_camera_async_client;
> -
> -struct soc_camera_device {
> - struct list_head list; /* list of all registered devices */
> - struct soc_camera_desc *sdesc;
> - struct device *pdev;/* Platform device */
> - struct device *parent; /* Camera host device */
> - struct device *control; /* E.g., the i2c client */
> - s32 user_width;
> - s32 user_height;
> - u32 bytesperline; /* for padding, zero if unused */
> - u32 sizeimage;
> - enum v4l2_colorspace colorspace;
> - unsigned char iface;/* Host number */
> - unsigned char devnum; /* Device number per host */
> - struct soc_camera_sense *sense; /* See comment in struct definition */
> - struct video_device *vdev;
> - struct v4l2_ctrl_handler ctrl_handler;
> - const struct soc_camera_format_xlate *current_fmt;
> - struct soc_camera_format_xlate *user_formats;
> - int num_user_formats;
> - enum v4l2_field field; /* Preserve field over close() */
> - void *host_priv;/* Per-device host private data */
> - /* soc_camera.c private count. Only accessed with .host_lock held */
> - int use_count;
> - struct file *streamer; /* stream owner */
> - struct v4l2_clk *clk;
> - /* Asynchronous subdevice management */
> - struct soc_camera_async_client *sasc;
> - /* video buffer queue */
> - struct vb2_queue vb2_vidq;
> -};
> -
> -/* Host supports programmable stride */
> -#define SOCAM_HOST_CAP_STRIDE(1 << 0)
> -
> -enum soc_camera_subdev_role {
> - SOCAM_SUBDEV_DATA_SOURCE = 1,
> - SOCAM_SUBDEV_DATA_SINK,
> - SOCAM_SUBDEV_DATA_PROCESSOR,
> -};
> -
> -struct soc_camera_async_subdev {
> - struct v4l2_async_subdev asd;
> - enum soc_camera_subdev_role role;
> -};
> -
> -struct soc_camera_host {
> - struct v4l2_device v4l2_dev;
> - struct list_head list;
> - struct mutex host_lock; /* Main synchronisation lock */
> - struct mutex clk_lock; /* Protect pipeline modifications */
> - unsigned char nr; /* Host number */
> - u32 capabilities;
> - struct soc_camera_device *icd; /* Currently attached client */
> - void *priv;
> - const char *drv_name;
> - struct soc_camera_host_ops *ops;
> - struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
> - unsigned int *asd_sizes;/* 0-terminated array of asd group
> sizes */
> -};
> -
> -struct soc_camera_host_ops {
> - struct module *owner;
> - int (*add)(struct soc_camera_device *);
> - void (*remove)(struct soc_camera_device *);
> - int (*clock_start)(struct soc_camera_host *);
> - void (*clock_stop)(struct soc_camera_host *);
> - /*
> - * .get_formats() is called for each client device format, but
> - * .put_formats() is only called once. Further, if any of the calls to
> - * .get_formats() fail, .put_formats() will not be called at all, the
> - * failing .get_formats() must then clean up internally.
> - */
> - int (*get_formats)(struct soc_camera_device *, unsigned int,
> -struct soc_camera_format_xlate *);
> - void (*put_formats)(struct soc_camera_device *);
> - int (*get_selection)(struct soc_camera_device *, struct v4l2_selection
> *);
> - int (*set_selection)(struct soc_camera_device *, struct v4l2_selection
> *);
> - /*
> - * The difference to .set_selection() is, that .set_liveselection is
> not allowed
> - * to change the output sizes
> - */
> - int (*set_liveselection)(struct soc_camera_device *, struct
> v4l2_selection *);
> - int (*set_fmt)(struct soc_camera_device *, struct v4l2_format *);
> - int (*try_fmt)(struct soc_camera_device *, struct v4l2_format *);
> - int (*init_videobuf2)(struct vb2_queue *,
> - struct soc_camera_device *);
> - int (*querycap)(struct soc_camera_host *, struct
Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers
Em Tue, 30 Oct 2018 01:21:34 +0200 Sakari Ailus escreveu: > The SoC camera framework has been obsolete for some time and it is no > longer functional. A few drivers have been converted to the V4L2 > sub-device API but for the rest the conversion has not taken place yet. > > In order to keep the tree clean and to avoid keep maintaining > non-functional and obsolete code, remove the SoC camera framework as well > as the drivers that depend on it. > > Signed-off-by: Sakari Ailus > --- > Resending, this time with git format-patch -D . > > MAINTAINERS|8 - > drivers/media/i2c/Kconfig |8 - > drivers/media/i2c/Makefile |1 - > drivers/media/i2c/soc_camera/Kconfig | 66 - > drivers/media/i2c/soc_camera/Makefile | 10 - > drivers/media/i2c/soc_camera/ov9640.h | 208 -- > drivers/media/i2c/soc_camera/soc_mt9m001.c | 757 --- > drivers/media/i2c/soc_camera/soc_mt9t112.c | 1157 --- > drivers/media/i2c/soc_camera/soc_mt9v022.c | 1012 - > drivers/media/i2c/soc_camera/soc_ov5642.c | 1087 -- > drivers/media/i2c/soc_camera/soc_ov772x.c | 1123 -- > drivers/media/i2c/soc_camera/soc_ov9640.c | 738 --- > drivers/media/i2c/soc_camera/soc_ov9740.c | 996 - > drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c | 1415 - > drivers/media/i2c/soc_camera/soc_tw9910.c | 999 - I don't see why we should remove those. I mean, Jacopo is actually converting those drivers to not depend on soc_camera, and it is a way better to review those patches with the old code in place. So, at least while Jacopo is keep doing this work, I would keep at Kernel tree, as it helps to see a diff when the driver changes when getting rid of soc_camera dependencies. So, IMO, the best would be to move those to /staging, eventually depending on BROKEN. Thanks, Mauro
Re: [PATCH 2/4] tw9910: No SoC camera dependency
On 10/30/2018 12:00 AM, Sakari Ailus wrote: > The tw9910 driver does not depend on SoC camera framework. Don't include > the header, but instead include media/v4l2-async.h which the driver really > needs. You might want to make a note of the fact that soc_camera.h includes v4l2-async.h, so removing soc_camera.h requires adding v4l2-async.h. I couldn't understand how it compiled before without the v4l2-async.h header until I saw that soc_camera.h includes it. Regards, Hans > > Signed-off-by: Sakari Ailus > --- > drivers/media/i2c/tw9910.c | 1 + > include/media/i2c/tw9910.h | 2 -- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c > index 7087ce946af1..6478bd41afb8 100644 > --- a/drivers/media/i2c/tw9910.c > +++ b/drivers/media/i2c/tw9910.c > @@ -27,6 +27,7 @@ > #include > > #include > +#include > #include > > #define GET_ID(val) ((val & 0xF8) >> 3) > diff --git a/include/media/i2c/tw9910.h b/include/media/i2c/tw9910.h > index bec8f7bce745..2f93799d5a21 100644 > --- a/include/media/i2c/tw9910.h > +++ b/include/media/i2c/tw9910.h > @@ -16,8 +16,6 @@ > #ifndef __TW9910_H__ > #define __TW9910_H__ > > -#include > - > /** > * tw9910_mpout_pin - MPOUT (multi-purpose output) pin functions > */ >
Reply me urgent for more details
-- Dear Assalamu Alaikum, I came across your contact during my private search Mrs Aisha Al-Qaddafi is my name, the only daughter of late Libyan president, I have funds the sum of $27.5 million USD for investment, I am interested in you for investment project assistance in your country, i shall compensate you 30% of the total sum after the funds are transfer into your account, Reply me urgent for more details Mrs Aisha Al-Qaddafi --
Re: [PATCH v4 00/22] i.MX media mem2mem scaler
Hi Steve, On Fri, 2018-10-19 at 11:51 -0700, Steve Longerbeam wrote: > Awesome, thanks Philipp. > > For the whole series: > > Acked-by: Steve Longerbeam > Tested-by: Steve Longerbeam > on i.MX6q SabreSD. Thank you. I have added the tags where it made sense to me and applied the ipu-v3 patches (all except 1/22) to imx-drm/next. regards Philipp
