[ragnatech:media-tree] BUILD SUCCESS 4158757395b300b6eb308fc20b96d1d231484413
tree/branch: git://git.ragnatech.se/linux media-tree branch HEAD: 4158757395b300b6eb308fc20b96d1d231484413 media: davinci: Fix implicit enum conversion warning elapsed time: 228m configs tested: 87 The following configs have been built successfully. More configs may be tested in the coming days. x86_64 acpi-redef x86_64 allyesdebian x86_64nfsroot i386 randconfig-x010-201838 i386 randconfig-x011-201838 i386 randconfig-x012-201838 i386 randconfig-x013-201838 i386 randconfig-x014-201838 i386 randconfig-x015-201838 i386 randconfig-x016-201838 i386 randconfig-x017-201838 i386 randconfig-x018-201838 i386 randconfig-x019-201838 microblaze mmu_defconfig microblazenommu_defconfig x86_64 randconfig-x000-201838 x86_64 randconfig-x001-201838 x86_64 randconfig-x002-201838 x86_64 randconfig-x003-201838 x86_64 randconfig-x004-201838 x86_64 randconfig-x005-201838 x86_64 randconfig-x006-201838 x86_64 randconfig-x007-201838 x86_64 randconfig-x008-201838 x86_64 randconfig-x009-201838 i386 allmodconfig i386 randconfig-x000-201838 i386 randconfig-x001-201838 i386 randconfig-x002-201838 i386 randconfig-x003-201838 i386 randconfig-x004-201838 i386 randconfig-x005-201838 i386 randconfig-x006-201838 i386 randconfig-x007-201838 i386 randconfig-x008-201838 i386 randconfig-x009-201838 x86_64 randconfig-x010-201838 x86_64 randconfig-x011-201838 x86_64 randconfig-x012-201838 x86_64 randconfig-x013-201838 x86_64 randconfig-x014-201838 x86_64 randconfig-x015-201838 x86_64 randconfig-x016-201838 x86_64 randconfig-x017-201838 x86_64 randconfig-x018-201838 x86_64 randconfig-x019-201838 ia64 alldefconfig ia64 allnoconfig ia64defconfig shallnoconfig sh rsk7269_defconfig sh sh7785lcr_32bit_defconfig shtitan_defconfig openriscor1ksim_defconfig um i386_defconfig um x86_64_defconfig c6xevmc6678_defconfig h8300h8300h-sim_defconfig nios2 10m50_defconfig xtensa common_defconfig xtensa iss_defconfig arm nuc960_defconfig powerpc eiger_defconfig powerpc sbc8548_defconfig sh sh7724_generic_defconfig m68k m5475evb_defconfig m68k multi_defconfig m68k sun3_defconfig i386 randconfig-s0-201838 i386 randconfig-s1-201838 i386 randconfig-s2-201838 i386 randconfig-s3-201838 x86_64 randconfig-s3-09251250 x86_64 randconfig-s4-09251250 x86_64 randconfig-s5-09251250 sparc defconfig sparc64 allnoconfig sparc64 defconfig powerpc ebony_defconfig x86_64 randconfig-h0-09251147 mips 32r2_defconfig mips 64r6el_defconfig mips allnoconfig mips fuloong2e_defconfig mips jz4740 mips malta_kvm_defconfig mips txx9 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH v6] media: add imx319 camera sensor driver
On 09/21/2018 08:06 PM, Sakari Ailus wrote: > Hi Bingbu, > > On Fri, Sep 21, 2018 at 05:41:55PM +0800, bingbu@intel.com wrote: >> From: Bingbu Cao >> >> Add a v4l2 sub-device driver for the Sony imx319 image sensor. >> This is a camera sensor using the i2c bus for control and the >> csi-2 bus for data. >> >> This driver supports following features: >> - manual exposure and analog/digital gain control support >> - vblank/hblank control support >> - 4 test patterns control support >> - vflip/hflip control support (will impact the output bayer order) >> - support following resolutions: >> - 3264x2448, 3280x2464 @ 30fps >> - 1936x1096, 1920x1080 @ 60fps >> - 1640x1232, 1640x922, 1296x736, 1280x720 @ 120fps >> - support 4 bayer orders output (via change v/hflip) >> - SRGGB10(default), SGRBG10, SGBRG10, SBGGR10 >> >> Cc: Tomasz Figa >> Cc: Sakari Ailus >> Signed-off-by: Bingbu Cao >> Signed-off-by: Tianshu Qiu >> >> --- >> >> This patch is based on sakari's media-tree git: >> https://git.linuxtv.org/sailus/media_tree.git/log/?h=for-4.20-1 >> >> Changes from v5: >> - add some comments for gain calculation >> - use lock to protect the format >> >> Changes from v4 to v5: >> - use single PLL for all internal clocks >> - change link frequency to 482.4MHz >> - adjust frame timing for 2x2 binning modes >>and enlarge frame readout time >> - get CSI-2 link frequencies and external clock >>from firmware >> - use unlocked __v4l2_ctrl_grab() with change from: >>https://git.linuxtv.org/sailus/media_tree.git/commit/?h=unlocked-ctrl-grab >> >> Changes since v1: >> - fix some coding style issues - line breaks >> - add v4l2_ctrl_grab() to prevent v/hflip change >>during streaming >> - add v4l2 ctrl event (un)subscribe support >> - add more info into commit message >> >> --- >> --- >> MAINTAINERS|7 + >> drivers/media/i2c/Kconfig | 11 + >> drivers/media/i2c/Makefile |1 + >> drivers/media/i2c/imx319.c | 2545 >> >> 4 files changed, 2564 insertions(+) >> create mode 100644 drivers/media/i2c/imx319.c >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index a5b256b25905..abc4abb6f83c 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -13530,6 +13530,13 @@ S: Maintained >> F: drivers/media/i2c/imx274.c >> F: Documentation/devicetree/bindings/media/i2c/imx274.txt >> >> +SONY IMX319 SENSOR DRIVER >> +M: Bingbu Cao >> +L: linux-media@vger.kernel.org >> +T: git git://linuxtv.org/media_tree.git >> +S: Maintained >> +F: drivers/media/i2c/imx319.c >> + >> SONY MEMORYSTICK CARD SUPPORT >> M: Alex Dubov >> W: http://tifmxx.berlios.de/ >> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig >> index bfdb494686bf..603ac087975b 100644 >> --- a/drivers/media/i2c/Kconfig >> +++ b/drivers/media/i2c/Kconfig >> @@ -614,6 +614,17 @@ config VIDEO_IMX274 >>This is a V4L2 sensor driver for the Sony IMX274 >>CMOS image sensor. >> >> +config VIDEO_IMX319 >> +tristate "Sony IMX319 sensor support" >> +depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API >> +depends on MEDIA_CAMERA_SUPPORT >> +help >> + This is a Video4Linux2 sensor driver for the Sony >> + IMX319 camera. >> + >> + To compile this driver as a module, choose M here: the >> + module will be called imx319. >> + >> config VIDEO_OV2640 >> tristate "OmniVision OV2640 sensor support" >> depends on VIDEO_V4L2 && I2C >> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile >> index a94eb03d10d4..d10b438577be 100644 >> --- a/drivers/media/i2c/Makefile >> +++ b/drivers/media/i2c/Makefile >> @@ -108,5 +108,6 @@ obj-$(CONFIG_VIDEO_OV2659) += ov2659.o >> obj-$(CONFIG_VIDEO_TC358743)+= tc358743.o >> obj-$(CONFIG_VIDEO_IMX258) += imx258.o >> obj-$(CONFIG_VIDEO_IMX274) += imx274.o >> +obj-$(CONFIG_VIDEO_IMX319) += imx319.o >> >> obj-$(CONFIG_SDR_MAX2175) += max2175.o >> diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c >> new file mode 100644 >> index ..5e80b113c386 >> --- /dev/null >> +++ b/drivers/media/i2c/imx319.c >> @@ -0,0 +1,2545 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +// Copyright (C) 2018 Intel Corporation >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define IMX319_REG_MODE_SELECT 0x0100 >> +#define IMX319_MODE_STANDBY 0x00 >> +#define IMX319_MODE_STREAMING 0x01 >> + >> +/* Chip ID */ >> +#define IMX319_REG_CHIP_ID 0x0016 >> +#define IMX319_CHIP_ID 0x0319 >> + >> +/* V_TIMING internal */ >> +#define IMX319_REG_FLL 0x0340 >> +#define IMX319_FLL_MAX 0x >> + >> +/* Exposure control */ >> +#define IMX319_REG_EXPOSURE 0x0202 >> +#define IMX319_EXPOSURE_MIN 1 >> +#define
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Sep 25 05:00:38 CEST 2018 media-tree git hash:4158757395b300b6eb308fc20b96d1d231484413 media_build git hash: 44385b9c61ecc27059a651885895c8ea09cd4179 v4l-utils git hash: 4890391b5d9e25ddd933e29c8f812a138e77919b edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.1.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-1-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: WARNINGS 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.119-i686: OK linux-3.18.119-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.152-i686: OK linux-4.4.152-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.124-i686: OK linux-4.9.124-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.67-i686: OK linux-4.14.67-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.5-i686: OK linux-4.18.5-x86_64: OK linux-4.19-rc1-i686: OK linux-4.19-rc1-x86_64: OK apps: OK spec-git: ERRORS sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [PATCH] am335x-boneblack-common.dtsi: add cec support
* Hans Verkuil [180924 04:06]: > Add CEC support to the tda998x. > > Signed-off-by: Hans Verkuil > --- > Note: this relies on this gpio patch series: > > https://www.spinics.net/lists/linux-gpio/msg32401.html > > and this follow-up gpio patch: > > https://www.spinics.net/lists/linux-gpio/msg32551.html > > that will appear in 4.20. > > Tested with my BeagleBone Black board. OK great applying into omap-for-v4.20/dt thanks. Tony
DVBSky S960CI hard broken in 4.18
Dear DVB experts, commit: 7d95fb7 - media: dvbsky: use just one mutex for serializing device R/W ops hard breaks DVBSky cards. Also the previous locking commits have caused several runtime issues. Since the bug tracker is not regularly checked, I'd love to make everybody aware of the corresponding issue with much more detail: https://bugzilla.kernel.org/show_bug.cgi?id=199323 which has gotten large attention from several users. >From my side, I can confirm that reverting 7d95fb7 makes the card work again >for me. on 4.18. With 7d95fb7 applied, the card tunes fine, but does not deliver any data. Please include me in any replies, I am not subscribed to the list. Cheers and all the best, Oliver
[RFP] Media Summit: rc-core status update
A 10 minute status update on rc-core, present and future. I'll give a brief presentation and leave some time for discussion. Thanks Sean
Re: [ANN] Draft Agenda for the media summit on Thursday Oct 25th in Edinburgh
Em Mon, 24 Sep 2018 19:41:13 +0200 Hans Verkuil escreveu: > On 09/24/2018 07:12 PM, Mauro Carvalho Chehab wrote: > > Em Mon, 24 Sep 2018 16:42:13 +0200 > > Hans Verkuil escreveu: > > > >> Hi all, > >> > >> We are organizing a media mini-summit on Thursday October 25th in > >> Edinburgh, Edinburgh International Conference Centre. > >> > >> If you plan to attend, please let Mauro know. It is open for all, but > >> we have a limited number of seats. > > > > No need to let me explicitly know in advance, but be sure to register for > > it at the ELCE/OSS register site. I'll use their tracking system to > > know who will be there. We have a limited number of seats there, and > > I'm relying on their system to control the number of attendees for > > us. > > Do you have a link of where to register? It is listed at the ELCE/OSS EU website: https://events.linuxfoundation.org/events/elc-openiot-europe-2018/register/ It is the same place where you register for the ELCE itself: https://www.regonline.com/registration/login.aspx If you registered before the addition of the Media Summit there, you will need to change the registration to add yourself. At the confirmation email, there's a link to access your registration. Once you click on it, it will open a page that will have a button. There, you can edit your subscription and add the Media Summit. > How many registrations do we have now? I'll ask. Thanks, Mauro
Re: [ANN] Draft Agenda for the media summit on Thursday Oct 25th in Edinburgh
Em Mon, 24 Sep 2018 14:12:36 -0300 Mauro Carvalho Chehab escreveu: > Em Mon, 24 Sep 2018 16:42:13 +0200 > Hans Verkuil escreveu: > > > Hi all, > > > > We are organizing a media mini-summit on Thursday October 25th in > > Edinburgh, Edinburgh International Conference Centre. > > > > If you plan to attend, please let Mauro know. It is open for all, but > > we have a limited number of seats. > > No need to let me explicitly know in advance, but be sure to register for > it at the ELCE/OSS register site. I'll use their tracking system to > know who will be there. We have a limited number of seats there, and > I'm relying on their system to control the number of attendees for > us. > > > > > Name of the room for the summit: TBD > > I'll get the room name with the event organizers and post it later > on this thread. The room will be Tinto, Level 0 of the EICC. Thanks, Mauro
Re: [ANN] Draft Agenda for the media summit on Thursday Oct 25th in Edinburgh
On 09/24/2018 07:12 PM, Mauro Carvalho Chehab wrote: > Em Mon, 24 Sep 2018 16:42:13 +0200 > Hans Verkuil escreveu: > >> Hi all, >> >> We are organizing a media mini-summit on Thursday October 25th in >> Edinburgh, Edinburgh International Conference Centre. >> >> If you plan to attend, please let Mauro know. It is open for all, but >> we have a limited number of seats. > > No need to let me explicitly know in advance, but be sure to register for > it at the ELCE/OSS register site. I'll use their tracking system to > know who will be there. We have a limited number of seats there, and > I'm relying on their system to control the number of attendees for > us. Do you have a link of where to register? How many registrations do we have now? Regards, Hans > >> >> Name of the room for the summit: TBD > > I'll get the room name with the event organizers and post it later > on this thread. > >> >> Currently known attendees (please add/remove names as needed): >> >> Sakari Ailus >> Mauro Carvalho Chehab >> Ezequiel Garcia >> Michael Ira Krufky >> Laurent Pinchart >> Ricardo Ribalda Delgado >> Hans Verkuil >> Sean Young >> >> Agenda (First draft!) >> = >> >> General remarks: the given start/end times for the various topics are >> approximate since it is always hard to predict how long a discussion will >> take. >> If people are attending other summits and those conflict with specific media >> topics they want to be part of, then let me know and we can rearrange the >> schedule to (hopefully) accommodate that. >> >> 9:00-9:15: Introduction (Hans Verkuil) >> >> 9:15-9:30: Status of the HDMI CEC kernel support (Hans Verkuil) >> Give a quick overview of the status: what has been merged, what is >> still pending, what is under development. >> >> 9:30-9:45: Save/restore controls from MTD (Ricardo Ribalda Delgado) >> Industrial/Scientific sensors usually come with very extensive >> calibration information such as: per column gain, list of dead >> pixels, temperature sensor offset... etc >> >> We are saving that information on an flash device that is located >> by the sensor. >> >> Show how we are integrating that calibration flash with v4l2-ctrl. >> And if this feature is useful for someone else and upstream it. >> >> 9:45-11:00: Complex Cameras (Mauro Carvalho Chehab) >> I expect that we could have something to discuss there about complex >> cameras. So, I'd reserve a 50 mins slot for it. >> >> The idea is to discuss about the undergoing work with complex camera >> development is happening. >> >> As we're working to merge request API, another topic for discussion >> is how to add support for requests on it (or on a separate but related >> library). >> >> 11:00-11:15: Break >> >> 11:15-12:00: Automated Testing (Ezequiel Garcia) >> There is a lot of discussion going on around testing, >> so it's a good opportunity for us to talk about our >> current testing infrastructure. >> >> We are already doing a good job with v4l2-compliance. >> Can we do more? >> >> Lunch >> >> 13:30-14:30: Stateless Codec userspace (Hans Verkuil) >> Support for stateless codecs and Request API should be merged for >> 4.20, and the next step is to discuss how to organize the userspace >> support. >> >> Hopefully by the time the media summit starts we'll have some better >> ideas of what we want in this area. >> >> 14:30-15:15: Which ioctls should be replaced with better versions? (Hans >> Verkuil) >> Some parts of the V4L2 API are awkward to use and I think it would be >> a good idea to look at possible candidates for that. >> >> Examples are the ioctls that use struct v4l2_buffer: the multiplanar >> support is >> really horrible, and writing code to support both single and >> multiplanar is hard. >> We are also running out of fields and the timeval isn't y2038 compliant. >> >> A proof-of-concept is here: >> >> >> https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=v4l2-buffer=a95549df06d9900f3559afdbb9da06bd4b22d1f3 >> >> It's a bit old, but it gives a good impression of what I have in mind. >> >> Another candidate is >> VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL/VIDIOC_ENUM_FRAMEINTERVALS: >> expressing frame intervals as a fraction is really awkward and so is >> the fact >> that the subdev and 'normal' ioctls are not the same. >> >> Discuss what possible other ioctls are candidates for a refresh. >> >> 15:15-15:30: Break >> >> 15:30-16:00: Discuss the media development process >> Since we are all here, discuss any issues there may be with the media >> subsystem development process. Anything to improve? >> >> 16:00-16:15: Wrap up >> Create action items (and who will take care of them) if needed. >> Summarize and conclude the day. >> >> End of the day: Key Signing Party >> >> Regards, >> >>
RE: [PATCH v6 12/12] intel-ipu3: Add imgu top level pci device driver
Hi, Tomasz,
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Tomasz Figa
> Sent: Tuesday, September 18, 2018 10:23 AM
> To: Zhi, Yong
> Cc: Linux Media Mailing List ; Sakari Ailus
> ; Mani, Rajmohan
> ; Toivonen, Tuukka
> ; Hu, Jerry W ; Zheng,
> Jian Xu
> Subject: Re: [PATCH v6 12/12] intel-ipu3: Add imgu top level pci device
> driver
>
> On Mon, Sep 17, 2018 at 5:20 AM Zhi, Yong wrote:
> >
> > Hi, Tomasz,
> >
> > Thanks for the code review.
> >
> > > -Original Message-
> > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> > > ow...@vger.kernel.org] On Behalf Of Tomasz Figa
> > > Sent: Monday, July 2, 2018 3:08 AM
> > > To: Zhi, Yong
> > > Cc: Linux Media Mailing List ; Sakari
> > > Ailus ; Mani, Rajmohan
> > > ; Toivonen, Tuukka
> > > ; Hu, Jerry W ;
> > > Zheng, Jian Xu
> > > Subject: Re: [PATCH v6 12/12] intel-ipu3: Add imgu top level pci
> > > device driver
> > >
> > > Hi Yong,
> > >
> > > On Fri, Mar 30, 2018 at 11:15 AM Yong Zhi
> wrote:
> > > > +/*
> > > > + * Queue as many buffers to CSS as possible. If all buffers don't
> > > > +fit into
> > > > + * CSS buffer queues, they remain unqueued and will be queued later.
> > > > + */
> > > > +int imgu_queue_buffers(struct imgu_device *imgu, bool initial) {
> > > > + unsigned int node;
> > > > + int r = 0;
> > > > + struct imgu_buffer *ibuf;
> > > > +
> > > > + if (!ipu3_css_is_streaming(>css))
> > > > + return 0;
> > > > +
> > > > + mutex_lock(>lock);
> > > > +
> > > > + /* Buffer set is queued to FW only when input buffer is ready */
> > > > + if (!imgu_queue_getbuf(imgu, IMGU_NODE_IN)) {
> > > > + mutex_unlock(>lock);
> > > > + return 0;
> > > > + }
> > > > + for (node = IMGU_NODE_IN + 1; 1; node = (node + 1) %
> > > > + IMGU_NODE_NUM) {
> > >
> > > Shouldn't we make (node != IMGU_NODE_IN ||
> imgu_queue_getbuf(imgu,
> > > IMGU_NODE_IN)) the condition here, rather than 1?
> > >
> > > This would also let us remove the explicit call to
> > > imgu_queue_getbuf() above the loop.
> > >
> >
> > Ack, will make the suggested changes regarding the loop condition
> evaluation.
>
> Just to make sure, the suggestion also includes starting from
> IMGU_NODE_IN (not + 1), i.e.
>
> for (node = IMGU_NODE_IN;
> node != IMGU_NODE_IN || imgu_queue_getbuf(imgu, IMGU_NODE_IN);
> node = (node + 1) % IMGU_NODE_NUM) {
> // ...
> }
>
Thanks for the clarification.
> > > > +static int __maybe_unused imgu_suspend(struct device *dev) {
> > > > + struct pci_dev *pci_dev = to_pci_dev(dev);
> > > > + struct imgu_device *imgu = pci_get_drvdata(pci_dev);
> > > > + unsigned long expire;
> > > > +
> > > > + dev_dbg(dev, "enter %s\n", __func__);
> > > > + imgu->suspend_in_stream = ipu3_css_is_streaming(
> >css);
> > > > + if (!imgu->suspend_in_stream)
> > > > + goto out;
> > > > + /* Block new buffers to be queued to CSS. */
> > > > + atomic_set(>qbuf_barrier, 1);
> > > > + /*
> > > > +* Wait for currently running irq handler to be done so that
> > > > +* no new buffers will be queued to fw later.
> > > > +*/
> > > > + synchronize_irq(pci_dev->irq);
> > > > + /* Wait until all buffers in CSS are done. */
> > > > + expire = jiffies + msecs_to_jiffies(1000);
> > > > + while (!ipu3_css_queue_empty(>css)) {
> > > > + if (time_is_before_jiffies(expire)) {
> > > > + dev_err(dev, "wait buffer drain timeout.\n");
> > > > + break;
> > > > + }
> > > > + }
> > >
> > > Uhm. We struggle to save some power by suspending the device only to
> > > end up with an ugly busy wait that could take even a second here.
> > > This doesn't make any sense.
> > >
> > > We had a working solution using a wait queue in previous revision [1].
> > > What happened to it?
> > >
> > > [1] https://chromium-
> > >
> review.googlesource.com/c/chromiumos/third_party/kernel/+/1029594/2
> > > /drivers/media/pci/intel/ipu3/ipu3.c#b913
> > > (see the left side)
> > >
> >
> > The code here was based on an old version of patch "ipu3-imgu: Avoid
> might sleep operations in suspend callback" at submission, so it did have
> buf_drain_wq, sorry for the confusion.
> >
>
> I guess that means that v7 is going to have the workqueue back? :)
>
Yes, that's the plan.
> Best regards,
> Tomasz
Re: [ANN] Draft Agenda for the media summit on Thursday Oct 25th in Edinburgh
Em Mon, 24 Sep 2018 16:42:13 +0200 Hans Verkuil escreveu: > Hi all, > > We are organizing a media mini-summit on Thursday October 25th in > Edinburgh, Edinburgh International Conference Centre. > > If you plan to attend, please let Mauro know. It is open for all, but > we have a limited number of seats. No need to let me explicitly know in advance, but be sure to register for it at the ELCE/OSS register site. I'll use their tracking system to know who will be there. We have a limited number of seats there, and I'm relying on their system to control the number of attendees for us. > > Name of the room for the summit: TBD I'll get the room name with the event organizers and post it later on this thread. > > Currently known attendees (please add/remove names as needed): > > Sakari Ailus > Mauro Carvalho Chehab > Ezequiel Garcia > Michael Ira Krufky > Laurent Pinchart > Ricardo Ribalda Delgado > Hans Verkuil > Sean Young > > Agenda (First draft!) > = > > General remarks: the given start/end times for the various topics are > approximate since it is always hard to predict how long a discussion will > take. > If people are attending other summits and those conflict with specific media > topics they want to be part of, then let me know and we can rearrange the > schedule to (hopefully) accommodate that. > > 9:00-9:15: Introduction (Hans Verkuil) > > 9:15-9:30: Status of the HDMI CEC kernel support (Hans Verkuil) > Give a quick overview of the status: what has been merged, what is > still pending, what is under development. > > 9:30-9:45: Save/restore controls from MTD (Ricardo Ribalda Delgado) > Industrial/Scientific sensors usually come with very extensive > calibration information such as: per column gain, list of dead > pixels, temperature sensor offset... etc > > We are saving that information on an flash device that is located > by the sensor. > > Show how we are integrating that calibration flash with v4l2-ctrl. > And if this feature is useful for someone else and upstream it. > > 9:45-11:00: Complex Cameras (Mauro Carvalho Chehab) > I expect that we could have something to discuss there about complex > cameras. So, I'd reserve a 50 mins slot for it. > > The idea is to discuss about the undergoing work with complex camera > development is happening. > > As we're working to merge request API, another topic for discussion > is how to add support for requests on it (or on a separate but related > library). > > 11:00-11:15: Break > > 11:15-12:00: Automated Testing (Ezequiel Garcia) > There is a lot of discussion going on around testing, > so it's a good opportunity for us to talk about our > current testing infrastructure. > > We are already doing a good job with v4l2-compliance. > Can we do more? > > Lunch > > 13:30-14:30: Stateless Codec userspace (Hans Verkuil) > Support for stateless codecs and Request API should be merged for > 4.20, and the next step is to discuss how to organize the userspace > support. > > Hopefully by the time the media summit starts we'll have some better > ideas of what we want in this area. > > 14:30-15:15: Which ioctls should be replaced with better versions? (Hans > Verkuil) > Some parts of the V4L2 API are awkward to use and I think it would be > a good idea to look at possible candidates for that. > > Examples are the ioctls that use struct v4l2_buffer: the multiplanar > support is > really horrible, and writing code to support both single and > multiplanar is hard. > We are also running out of fields and the timeval isn't y2038 compliant. > > A proof-of-concept is here: > > > https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=v4l2-buffer=a95549df06d9900f3559afdbb9da06bd4b22d1f3 > > It's a bit old, but it gives a good impression of what I have in mind. > > Another candidate is > VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL/VIDIOC_ENUM_FRAMEINTERVALS: > expressing frame intervals as a fraction is really awkward and so is > the fact > that the subdev and 'normal' ioctls are not the same. > > Discuss what possible other ioctls are candidates for a refresh. > > 15:15-15:30: Break > > 15:30-16:00: Discuss the media development process > Since we are all here, discuss any issues there may be with the media > subsystem development process. Anything to improve? > > 16:00-16:15: Wrap up > Create action items (and who will take care of them) if needed. > Summarize and conclude the day. > > End of the day: Key Signing Party > > Regards, > > Hans Thanks, Mauro
Re: [ANN] Draft Agenda for the media summit on Thursday Oct 25th in Edinburgh
Hi Hans, Mauro, I believe I selected attendance when registering for the conference, but please add my name to the list here as well. I have a small topic which might start off in the hallway track before hand that I'd like to kick off too. "Fault tolerant V4L2" ... In other words, how should we handle complex devices which do not 'fully probe'. In our instance, with our GMSL driver implementation - we have an 8 camera system, described as such in DT. If one of the cameras is disconnected, or does not fully probe - then all of the remaining cameras are unavailable, as they are all subdevices from the MAX9286 => CSI2 => VIN chain. Originally we had async subdevice registration at probe time so that they appear as they are ready - but I believe earlier review comments determined that this goes against the V4L2 spec, and if the system state is not correct - then it's just a flat out failure. I'd like to discuss (or start to discuss) how we should handle cases such as a missing *non-essential* subdevice in a safety critical system. For instance, imagine here that two cameras are digital wing mirrors, and one gets knocked off by a lorry ... I'd like to know that all the remaining 'digital eyes' can still function :) I had hoped to send a more clear proposal on this topic with patch examples based on our driver - but I'm afraid my talk didn't get accepted for ELCE and so I haven't had chance (/been forced) to spend time on this topic yet :-) Further discussion on this could be how to get devices to re-probe at runtime too - or retry their probe sequences at least, which might perhaps even be a higher level than linux-media. Regards Kieran On 24/09/18 15:42, Hans Verkuil wrote: > Hi all, > > We are organizing a media mini-summit on Thursday October 25th in > Edinburgh, Edinburgh International Conference Centre. > > If you plan to attend, please let Mauro know. It is open for all, but > we have a limited number of seats. > > Name of the room for the summit: TBD > > Currently known attendees (please add/remove names as needed): > > Sakari Ailus > Mauro Carvalho Chehab > Ezequiel Garcia > Michael Ira Krufky > Laurent Pinchart > Ricardo Ribalda Delgado > Hans Verkuil > Sean Young > > Agenda (First draft!) > = > > General remarks: the given start/end times for the various topics are > approximate since it is always hard to predict how long a discussion will > take. > If people are attending other summits and those conflict with specific media > topics they want to be part of, then let me know and we can rearrange the > schedule to (hopefully) accommodate that. > > 9:00-9:15: Introduction (Hans Verkuil) > > 9:15-9:30: Status of the HDMI CEC kernel support (Hans Verkuil) > Give a quick overview of the status: what has been merged, what is > still pending, what is under development. > > 9:30-9:45: Save/restore controls from MTD (Ricardo Ribalda Delgado) > Industrial/Scientific sensors usually come with very extensive > calibration information such as: per column gain, list of dead > pixels, temperature sensor offset... etc > > We are saving that information on an flash device that is located > by the sensor. > > Show how we are integrating that calibration flash with v4l2-ctrl. > And if this feature is useful for someone else and upstream it. > > 9:45-11:00: Complex Cameras (Mauro Carvalho Chehab) > I expect that we could have something to discuss there about complex > cameras. So, I'd reserve a 50 mins slot for it. > > The idea is to discuss about the undergoing work with complex camera > development is happening. > > As we're working to merge request API, another topic for discussion > is how to add support for requests on it (or on a separate but related > library). > > 11:00-11:15: Break > > 11:15-12:00: Automated Testing (Ezequiel Garcia) > There is a lot of discussion going on around testing, > so it's a good opportunity for us to talk about our > current testing infrastructure. > > We are already doing a good job with v4l2-compliance. > Can we do more? > > Lunch > > 13:30-14:30: Stateless Codec userspace (Hans Verkuil) > Support for stateless codecs and Request API should be merged for > 4.20, and the next step is to discuss how to organize the userspace > support. > > Hopefully by the time the media summit starts we'll have some better > ideas of what we want in this area. > > 14:30-15:15: Which ioctls should be replaced with better versions? (Hans > Verkuil) > Some parts of the V4L2 API are awkward to use and I think it would be > a good idea to look at possible candidates for that. > > Examples are the ioctls that use struct v4l2_buffer: the multiplanar > support is > really horrible, and writing code to support both single and > multiplanar is hard. > We are
Re: [PATCH 1/1] v4l: Remove support for crop default target in subdev drivers
On Mon, Sep 24, 2018 at 04:47:07PM +0200, Hans Verkuil wrote: > On 09/24/2018 04:42 PM, Sakari Ailus wrote: > > The V4L2 sub-device API does not support the crop default target. A number > > of drivers apparently still did support this, likely as it was needed by > > the SoC camera framework. Drop support for the default crop rectaingle in > > sub-device drivers, and use the bround in SoC camera instead. ^ This was intended to be "bounds rectangle" instead. I'll fix that to the pull request. > > > > Reported-by: Helmut Grohne > > Suggested-by: Hans Verkuil > > Acked-by: Hans Verkuil Thanks! -- Sakari Ailus e-mail: sakari.ai...@iki.fi
Re: [PATCH 1/1] v4l: Remove support for crop default target in subdev drivers
On 09/24/2018 04:42 PM, Sakari Ailus wrote:
> The V4L2 sub-device API does not support the crop default target. A number
> of drivers apparently still did support this, likely as it was needed by
> the SoC camera framework. Drop support for the default crop rectaingle in
> sub-device drivers, and use the bround in SoC camera instead.
>
> Reported-by: Helmut Grohne
> Suggested-by: Hans Verkuil
Acked-by: Hans Verkuil
Thanks!
Hans
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/i2c/ak881x.c | 1 -
> drivers/media/i2c/mt9m111.c| 1 -
> drivers/media/i2c/mt9t112.c| 6 --
> drivers/media/i2c/ov2640.c | 1 -
> drivers/media/i2c/ov6650.c | 1 -
> drivers/media/i2c/ov772x.c | 1 -
> drivers/media/i2c/rj54n1cb0c.c | 1 -
> drivers/media/i2c/soc_camera/mt9m001.c | 1 -
> drivers/media/i2c/soc_camera/mt9t112.c | 6 --
> drivers/media/i2c/soc_camera/mt9v022.c | 1 -
> drivers/media/i2c/soc_camera/ov5642.c | 1 -
> drivers/media/i2c/soc_camera/ov772x.c | 1 -
> drivers/media/i2c/soc_camera/ov9640.c | 1 -
> drivers/media/i2c/soc_camera/ov9740.c | 1 -
> drivers/media/i2c/soc_camera/rj54n1cb0c.c | 1 -
> drivers/media/i2c/tvp5150.c| 1 -
> drivers/media/platform/soc_camera/soc_scale_crop.c | 2 +-
> drivers/staging/media/imx074/imx074.c | 1 -
> drivers/staging/media/mt9t031/mt9t031.c| 1 -
> 19 files changed, 1 insertion(+), 29 deletions(-)
>
> diff --git a/drivers/media/i2c/ak881x.c b/drivers/media/i2c/ak881x.c
> index 16682c8477d1..30f9db1351b9 100644
> --- a/drivers/media/i2c/ak881x.c
> +++ b/drivers/media/i2c/ak881x.c
> @@ -136,7 +136,6 @@ static int ak881x_get_selection(struct v4l2_subdev *sd,
>
> switch (sel->target) {
> case V4L2_SEL_TGT_CROP_BOUNDS:
> - case V4L2_SEL_TGT_CROP_DEFAULT:
> sel->r.left = 0;
> sel->r.top = 0;
> sel->r.width = 720;
> diff --git a/drivers/media/i2c/mt9m111.c b/drivers/media/i2c/mt9m111.c
> index efda1aa95ca0..1395986a07bb 100644
> --- a/drivers/media/i2c/mt9m111.c
> +++ b/drivers/media/i2c/mt9m111.c
> @@ -445,7 +445,6 @@ static int mt9m111_get_selection(struct v4l2_subdev *sd,
>
> switch (sel->target) {
> case V4L2_SEL_TGT_CROP_BOUNDS:
> - case V4L2_SEL_TGT_CROP_DEFAULT:
> sel->r.left = MT9M111_MIN_DARK_COLS;
> sel->r.top = MT9M111_MIN_DARK_ROWS;
> sel->r.width = MT9M111_MAX_WIDTH;
> diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
> index af8cca984215..ef353a244e33 100644
> --- a/drivers/media/i2c/mt9t112.c
> +++ b/drivers/media/i2c/mt9t112.c
> @@ -888,12 +888,6 @@ static int mt9t112_get_selection(struct v4l2_subdev *sd,
> sel->r.width = MAX_WIDTH;
> sel->r.height = MAX_HEIGHT;
> return 0;
> - case V4L2_SEL_TGT_CROP_DEFAULT:
> - sel->r.left = 0;
> - sel->r.top = 0;
> - sel->r.width = VGA_WIDTH;
> - sel->r.height = VGA_HEIGHT;
> - return 0;
> case V4L2_SEL_TGT_CROP:
> sel->r = priv->frame;
> return 0;
> diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
> index beb722065152..20a8853ba1e2 100644
> --- a/drivers/media/i2c/ov2640.c
> +++ b/drivers/media/i2c/ov2640.c
> @@ -1010,7 +1010,6 @@ static int ov2640_get_selection(struct v4l2_subdev *sd,
>
> switch (sel->target) {
> case V4L2_SEL_TGT_CROP_BOUNDS:
> - case V4L2_SEL_TGT_CROP_DEFAULT:
> case V4L2_SEL_TGT_CROP:
> sel->r.left = 0;
> sel->r.top = 0;
> diff --git a/drivers/media/i2c/ov6650.c b/drivers/media/i2c/ov6650.c
> index 17a34b4a819d..5d1b218bb7f0 100644
> --- a/drivers/media/i2c/ov6650.c
> +++ b/drivers/media/i2c/ov6650.c
> @@ -449,7 +449,6 @@ static int ov6650_get_selection(struct v4l2_subdev *sd,
>
> switch (sel->target) {
> case V4L2_SEL_TGT_CROP_BOUNDS:
> - case V4L2_SEL_TGT_CROP_DEFAULT:
> sel->r.left = DEF_HSTRT << 1;
> sel->r.top = DEF_VSTRT << 1;
> sel->r.width = W_CIF;
> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> index 161bc7c8535d..fefff7fd7d68 100644
> --- a/drivers/media/i2c/ov772x.c
> +++ b/drivers/media/i2c/ov772x.c
> @@ -1147,7 +1147,6 @@ static int ov772x_get_selection(struct v4l2_subdev *sd,
> sel->r.top = 0;
> switch (sel->target) {
> case V4L2_SEL_TGT_CROP_BOUNDS:
> - case V4L2_SEL_TGT_CROP_DEFAULT:
> case V4L2_SEL_TGT_CROP:
> sel->r.width = priv->win->rect.width;
> sel->r.height = priv->win->rect.height;
> diff --git a/drivers/media/i2c/rj54n1cb0c.c b/drivers/media/i2c/rj54n1cb0c.c
> index
[ANN] Draft Agenda for the media summit on Thursday Oct 25th in Edinburgh
Hi all, We are organizing a media mini-summit on Thursday October 25th in Edinburgh, Edinburgh International Conference Centre. If you plan to attend, please let Mauro know. It is open for all, but we have a limited number of seats. Name of the room for the summit: TBD Currently known attendees (please add/remove names as needed): Sakari Ailus Mauro Carvalho Chehab Ezequiel Garcia Michael Ira Krufky Laurent Pinchart Ricardo Ribalda Delgado Hans Verkuil Sean Young Agenda (First draft!) = General remarks: the given start/end times for the various topics are approximate since it is always hard to predict how long a discussion will take. If people are attending other summits and those conflict with specific media topics they want to be part of, then let me know and we can rearrange the schedule to (hopefully) accommodate that. 9:00-9:15: Introduction (Hans Verkuil) 9:15-9:30: Status of the HDMI CEC kernel support (Hans Verkuil) Give a quick overview of the status: what has been merged, what is still pending, what is under development. 9:30-9:45: Save/restore controls from MTD (Ricardo Ribalda Delgado) Industrial/Scientific sensors usually come with very extensive calibration information such as: per column gain, list of dead pixels, temperature sensor offset... etc We are saving that information on an flash device that is located by the sensor. Show how we are integrating that calibration flash with v4l2-ctrl. And if this feature is useful for someone else and upstream it. 9:45-11:00: Complex Cameras (Mauro Carvalho Chehab) I expect that we could have something to discuss there about complex cameras. So, I'd reserve a 50 mins slot for it. The idea is to discuss about the undergoing work with complex camera development is happening. As we're working to merge request API, another topic for discussion is how to add support for requests on it (or on a separate but related library). 11:00-11:15: Break 11:15-12:00: Automated Testing (Ezequiel Garcia) There is a lot of discussion going on around testing, so it's a good opportunity for us to talk about our current testing infrastructure. We are already doing a good job with v4l2-compliance. Can we do more? Lunch 13:30-14:30: Stateless Codec userspace (Hans Verkuil) Support for stateless codecs and Request API should be merged for 4.20, and the next step is to discuss how to organize the userspace support. Hopefully by the time the media summit starts we'll have some better ideas of what we want in this area. 14:30-15:15: Which ioctls should be replaced with better versions? (Hans Verkuil) Some parts of the V4L2 API are awkward to use and I think it would be a good idea to look at possible candidates for that. Examples are the ioctls that use struct v4l2_buffer: the multiplanar support is really horrible, and writing code to support both single and multiplanar is hard. We are also running out of fields and the timeval isn't y2038 compliant. A proof-of-concept is here: https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=v4l2-buffer=a95549df06d9900f3559afdbb9da06bd4b22d1f3 It's a bit old, but it gives a good impression of what I have in mind. Another candidate is VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL/VIDIOC_ENUM_FRAMEINTERVALS: expressing frame intervals as a fraction is really awkward and so is the fact that the subdev and 'normal' ioctls are not the same. Discuss what possible other ioctls are candidates for a refresh. 15:15-15:30: Break 15:30-16:00: Discuss the media development process Since we are all here, discuss any issues there may be with the media subsystem development process. Anything to improve? 16:00-16:15: Wrap up Create action items (and who will take care of them) if needed. Summarize and conclude the day. End of the day: Key Signing Party Regards, Hans
[PATCH 1/1] v4l: Remove support for crop default target in subdev drivers
The V4L2 sub-device API does not support the crop default target. A number
of drivers apparently still did support this, likely as it was needed by
the SoC camera framework. Drop support for the default crop rectaingle in
sub-device drivers, and use the bround in SoC camera instead.
Reported-by: Helmut Grohne
Suggested-by: Hans Verkuil
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/ak881x.c | 1 -
drivers/media/i2c/mt9m111.c| 1 -
drivers/media/i2c/mt9t112.c| 6 --
drivers/media/i2c/ov2640.c | 1 -
drivers/media/i2c/ov6650.c | 1 -
drivers/media/i2c/ov772x.c | 1 -
drivers/media/i2c/rj54n1cb0c.c | 1 -
drivers/media/i2c/soc_camera/mt9m001.c | 1 -
drivers/media/i2c/soc_camera/mt9t112.c | 6 --
drivers/media/i2c/soc_camera/mt9v022.c | 1 -
drivers/media/i2c/soc_camera/ov5642.c | 1 -
drivers/media/i2c/soc_camera/ov772x.c | 1 -
drivers/media/i2c/soc_camera/ov9640.c | 1 -
drivers/media/i2c/soc_camera/ov9740.c | 1 -
drivers/media/i2c/soc_camera/rj54n1cb0c.c | 1 -
drivers/media/i2c/tvp5150.c| 1 -
drivers/media/platform/soc_camera/soc_scale_crop.c | 2 +-
drivers/staging/media/imx074/imx074.c | 1 -
drivers/staging/media/mt9t031/mt9t031.c| 1 -
19 files changed, 1 insertion(+), 29 deletions(-)
diff --git a/drivers/media/i2c/ak881x.c b/drivers/media/i2c/ak881x.c
index 16682c8477d1..30f9db1351b9 100644
--- a/drivers/media/i2c/ak881x.c
+++ b/drivers/media/i2c/ak881x.c
@@ -136,7 +136,6 @@ static int ak881x_get_selection(struct v4l2_subdev *sd,
switch (sel->target) {
case V4L2_SEL_TGT_CROP_BOUNDS:
- case V4L2_SEL_TGT_CROP_DEFAULT:
sel->r.left = 0;
sel->r.top = 0;
sel->r.width = 720;
diff --git a/drivers/media/i2c/mt9m111.c b/drivers/media/i2c/mt9m111.c
index efda1aa95ca0..1395986a07bb 100644
--- a/drivers/media/i2c/mt9m111.c
+++ b/drivers/media/i2c/mt9m111.c
@@ -445,7 +445,6 @@ static int mt9m111_get_selection(struct v4l2_subdev *sd,
switch (sel->target) {
case V4L2_SEL_TGT_CROP_BOUNDS:
- case V4L2_SEL_TGT_CROP_DEFAULT:
sel->r.left = MT9M111_MIN_DARK_COLS;
sel->r.top = MT9M111_MIN_DARK_ROWS;
sel->r.width = MT9M111_MAX_WIDTH;
diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
index af8cca984215..ef353a244e33 100644
--- a/drivers/media/i2c/mt9t112.c
+++ b/drivers/media/i2c/mt9t112.c
@@ -888,12 +888,6 @@ static int mt9t112_get_selection(struct v4l2_subdev *sd,
sel->r.width = MAX_WIDTH;
sel->r.height = MAX_HEIGHT;
return 0;
- case V4L2_SEL_TGT_CROP_DEFAULT:
- sel->r.left = 0;
- sel->r.top = 0;
- sel->r.width = VGA_WIDTH;
- sel->r.height = VGA_HEIGHT;
- return 0;
case V4L2_SEL_TGT_CROP:
sel->r = priv->frame;
return 0;
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index beb722065152..20a8853ba1e2 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -1010,7 +1010,6 @@ static int ov2640_get_selection(struct v4l2_subdev *sd,
switch (sel->target) {
case V4L2_SEL_TGT_CROP_BOUNDS:
- case V4L2_SEL_TGT_CROP_DEFAULT:
case V4L2_SEL_TGT_CROP:
sel->r.left = 0;
sel->r.top = 0;
diff --git a/drivers/media/i2c/ov6650.c b/drivers/media/i2c/ov6650.c
index 17a34b4a819d..5d1b218bb7f0 100644
--- a/drivers/media/i2c/ov6650.c
+++ b/drivers/media/i2c/ov6650.c
@@ -449,7 +449,6 @@ static int ov6650_get_selection(struct v4l2_subdev *sd,
switch (sel->target) {
case V4L2_SEL_TGT_CROP_BOUNDS:
- case V4L2_SEL_TGT_CROP_DEFAULT:
sel->r.left = DEF_HSTRT << 1;
sel->r.top = DEF_VSTRT << 1;
sel->r.width = W_CIF;
diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 161bc7c8535d..fefff7fd7d68 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -1147,7 +1147,6 @@ static int ov772x_get_selection(struct v4l2_subdev *sd,
sel->r.top = 0;
switch (sel->target) {
case V4L2_SEL_TGT_CROP_BOUNDS:
- case V4L2_SEL_TGT_CROP_DEFAULT:
case V4L2_SEL_TGT_CROP:
sel->r.width = priv->win->rect.width;
sel->r.height = priv->win->rect.height;
diff --git a/drivers/media/i2c/rj54n1cb0c.c b/drivers/media/i2c/rj54n1cb0c.c
index 6ad998ad1b16..4cc51e001874 100644
--- a/drivers/media/i2c/rj54n1cb0c.c
+++ b/drivers/media/i2c/rj54n1cb0c.c
@@ -589,7 +589,6 @@ static int rj54n1_get_selection(struct v4l2_subdev *sd,
switch (sel->target) {
[PATCH 1/1] v4l: i2c: Add a comment not to use static sub-device names in the future
A number of sub-device drivers used a static name for the sub-device, and thus the media entity. As the entity name must be unique within a media device, this makes it impossible to have more than one instance of each device in a media device. This is a rather severe limitation. Instead of fixing these drivers, add a comment to the drivers noting that such static names may not be used in the future. The alternative of fixing the drivers is troublesome as the entity (as well as sub-device) name is part of the uAPI. Changing that is almost certain to break something. As these devices are old but no-one has encountered a problem with the static names, leave it as-is. Signed-off-by: Sakari Ailus --- drivers/media/i2c/m5mols/m5mols_core.c | 1 + drivers/media/i2c/noon010pc30.c | 1 + drivers/media/i2c/s5c73m3/s5c73m3-core.c | 1 + drivers/media/i2c/s5k4ecgx.c | 1 + drivers/media/i2c/s5k6aa.c | 1 + 5 files changed, 5 insertions(+) diff --git a/drivers/media/i2c/m5mols/m5mols_core.c b/drivers/media/i2c/m5mols/m5mols_core.c index 155424a43d4c..b8b2bf4cbfb2 100644 --- a/drivers/media/i2c/m5mols/m5mols_core.c +++ b/drivers/media/i2c/m5mols/m5mols_core.c @@ -987,6 +987,7 @@ static int m5mols_probe(struct i2c_client *client, sd = >sd; v4l2_i2c_subdev_init(sd, client, _ops); + /* Static name; NEVER use in new drivers! */ strscpy(sd->name, MODULE_NAME, sizeof(sd->name)); sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; diff --git a/drivers/media/i2c/noon010pc30.c b/drivers/media/i2c/noon010pc30.c index 4698e40fedd2..11479e65a9ae 100644 --- a/drivers/media/i2c/noon010pc30.c +++ b/drivers/media/i2c/noon010pc30.c @@ -720,6 +720,7 @@ static int noon010_probe(struct i2c_client *client, mutex_init(>lock); sd = >sd; v4l2_i2c_subdev_init(sd, client, _ops); + /* Static name; NEVER use in new drivers! */ strscpy(sd->name, MODULE_NAME, sizeof(sd->name)); sd->internal_ops = _subdev_internal_ops; diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c b/drivers/media/i2c/s5c73m3/s5c73m3-core.c index 21ca5186f9ed..c4145194251f 100644 --- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c +++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c @@ -1698,6 +1698,7 @@ static int s5c73m3_probe(struct i2c_client *client, return ret; v4l2_i2c_subdev_init(oif_sd, client, _subdev_ops); + /* Static name; NEVER use in new drivers! */ strscpy(oif_sd->name, "S5C73M3-OIF", sizeof(oif_sd->name)); oif_sd->internal_ops = _internal_ops; diff --git a/drivers/media/i2c/s5k4ecgx.c b/drivers/media/i2c/s5k4ecgx.c index 8c0dca6cb20c..79aa2740edc4 100644 --- a/drivers/media/i2c/s5k4ecgx.c +++ b/drivers/media/i2c/s5k4ecgx.c @@ -954,6 +954,7 @@ static int s5k4ecgx_probe(struct i2c_client *client, sd = >sd; /* Registering subdev */ v4l2_i2c_subdev_init(sd, client, _ops); + /* Static name; NEVER use in new drivers! */ strscpy(sd->name, S5K4ECGX_DRIVER_NAME, sizeof(sd->name)); sd->internal_ops = _subdev_internal_ops; diff --git a/drivers/media/i2c/s5k6aa.c b/drivers/media/i2c/s5k6aa.c index 52ca033f7069..63cf8db82e7d 100644 --- a/drivers/media/i2c/s5k6aa.c +++ b/drivers/media/i2c/s5k6aa.c @@ -1576,6 +1576,7 @@ static int s5k6aa_probe(struct i2c_client *client, sd = >sd; v4l2_i2c_subdev_init(sd, client, _subdev_ops); + /* Static name; NEVER use in new drivers! */ strscpy(sd->name, DRIVER_NAME, sizeof(sd->name)); sd->internal_ops = _subdev_internal_ops; -- 2.11.0
[PATCH] media: ov5640: use JPEG mode 3 for 720p
Change 720p JPEG mode to mode 3 as per other resolutions.
Signed-off-by: Hugues Fruchet
---
drivers/media/i2c/ov5640.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 30b15e9..664ffac 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -608,7 +608,7 @@ static const struct reg_value
ov5640_setting_15fps_720P_1280_720[] = {
{0x3a03, 0xe4, 0, 0}, {0x3a08, 0x01, 0, 0}, {0x3a09, 0xbc, 0, 0},
{0x3a0a, 0x01, 0, 0}, {0x3a0b, 0x72, 0, 0}, {0x3a0e, 0x01, 0, 0},
{0x3a0d, 0x02, 0, 0}, {0x3a14, 0x02, 0, 0}, {0x3a15, 0xe4, 0, 0},
- {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x02, 0, 0},
+ {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0},
{0x4407, 0x04, 0, 0}, {0x460b, 0x37, 0, 0}, {0x460c, 0x20, 0, 0},
{0x3824, 0x04, 0, 0}, {0x5001, 0x83, 0, 0},
};
--
2.7.4
OFFICE
[PATCH] am335x-boneblack-common.dtsi: add cec support
Add CEC support to the tda998x.
Signed-off-by: Hans Verkuil
---
Note: this relies on this gpio patch series:
https://www.spinics.net/lists/linux-gpio/msg32401.html
and this follow-up gpio patch:
https://www.spinics.net/lists/linux-gpio/msg32551.html
that will appear in 4.20.
Tested with my BeagleBone Black board.
Regards,
Hans
---
arch/arm/boot/dts/am335x-boneblack-common.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack-common.dtsi
b/arch/arm/boot/dts/am335x-boneblack-common.dtsi
index 325daae40278..07e6b36d17c4 100644
--- a/arch/arm/boot/dts/am335x-boneblack-common.dtsi
+++ b/arch/arm/boot/dts/am335x-boneblack-common.dtsi
@@ -7,6 +7,7 @@
*/
#include
+#include
_reg {
regulator-min-microvolt = <180>;
@@ -91,6 +92,8 @@
tda19988: tda19988 {
compatible = "nxp,tda998x";
reg = <0x70>;
+ nxp,calib-gpios = < 25 0>;
+ interrupts-extended = < 25 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default", "off";
pinctrl-0 = <_hdmi_bonelt_pins>;
--
2.19.0
Use of V4L2_SEL_TGT_CROP_DEFAULT in i2c subdev drivers
Hi, Documentation/media/uapi/v4l/v4l2-selection-targets.rst says that V4L2_SEL_TGT_CROP_DEFAULT is not valid for subdev drivers. Looking into drivers/media/i2c (which contains only subdev drivers except for video-i2c.c), the following drivers implement V4L2_SEL_TGT_CROP_DEFAULT: ak881x.c mt9m111.c mt9t112.c ov2640.c ov6650.c ov772x.c rj54n1cb0c.c soc_camera/mt9m001.c soc_camera/mt9t112.c soc_camera/mt9v022.c soc_camera/ov5642.c soc_camera/ov772x.c soc_camera/ov9640.c soc_camera/ov9740.c soc_camera/rj54n1cb0c.c tvp5150.c The majority of drivers behave equally for V4L2_SEL_TGT_CROP_DEFAULT and V4L2_SEL_TGT_CROP_BOUNDS. The only exceptions are mt9t112.c and soc_camera/mt9t112.c. Actually these two look very similar. A significant fraction of differences is white space, case and operand order. Is this a bug in 16 drivers? Is this a documentation bug? Am I getting something wrong? Helmut
Re: [PATCH v3 0/5] Fix OV5640 exposure & gain
Many thanks for this work Jacopo and Sakari, On my side I've made some other improvements/fixes on OV5640 that I will push in the coming days. BR, Hugues. On 09/17/2018 01:40 PM, Sakari Ailus wrote: > On Mon, Sep 17, 2018 at 09:47:19AM +0200, jacopo mondi wrote: >> Hi Sakari, >> thanks for handling this >> >> On Sun, Sep 16, 2018 at 02:02:30AM +0300, Sakari Ailus wrote: >>> Hi Jacopo, Hugues, >>> >>> On Fri, Sep 14, 2018 at 06:07:12PM +0200, jacopo mondi wrote: Hi Sakari, On Tue, Sep 11, 2018 at 03:48:16PM +0200, Hugues Fruchet wrote: > This patch serie fixes some problems around exposure & gain in OV5640 > driver. As you offered to collect this series and my CSI-2 fixes I have just re-sent, you might be interested in this branch: git://jmondi.org/linux engicam-imx6q/media-master/ov5640/csi2_init_v4_exposure_v3 I have there re-based this series on top of mine, which is in turn based on latest media master, where this series do not apply as-is afaict. I have added to Hugues' patches my reviewed-by and tested-by tags. If you prefer to I can send you a pull request, or if you want to have a chance to review the whole patch list please refer to the above branch. Let me know if I can help speeding up the inclusion of these two series as they fix two real issues of MIPI CSI-2 capture operations for this sensor. >>> >>> I've pushed the patches here: >>> >>> https://git.linuxtv.org/sailus/media_tree.git/log/?h=for-4.20-5> >>> >>> There was a merge commit and a few extra patches in your tree; I threw them >>> out. :-) >> >> Yeah, those are a few patches I need for my testing platform... Forgot to >> remove them, hope you didn't spend too much time on this. > > No, it was rather easy to remove them. I've sent a pull request on these: > > https://patchwork.linuxtv.org/patch/52091/> >
