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: Fri Apr 17 04:00:17 CEST 2015 git branch: test git hash: e183201b9e917daf2530b637b2f34f1d5afb934d gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.19.0-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16.7-x86_64: ERRORS linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v4.2] Improved V4L2 of endpoint interface with link-frequencies
Hi Mauro, Here are patches to - add a new interface for parsing variable sized property arrays (the old v4l2_of_parse_endpoint() could be removed later on), - parse the link-frequencies endpoint property and - use the above in the smiapp driver. Please pull. The following changes since commit e183201b9e917daf2530b637b2f34f1d5afb934d: [media] uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL (2015-04-10 10:29:27 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git v4l2-of-array for you to fetch changes up to 4df51de61c33aa3e739230704d18eb08415b739e: smiapp: Use v4l2_of_alloc_parse_endpoint() (2015-04-17 00:36:27 +0300) Sakari Ailus (4): v4l: of: Remove the head field in struct v4l2_of_endpoint v4l: of: Instead of zeroing bus_type and bus field separately, unify this v4l: of: Parse variable length properties --- link-frequencies smiapp: Use v4l2_of_alloc_parse_endpoint() drivers/media/i2c/smiapp/smiapp-core.c | 38 +++-- drivers/media/v4l2-core/v4l2-of.c | 92 +++- include/media/v4l2-of.h| 20 ++- 3 files changed, 126 insertions(+), 24 deletions(-) -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] v4l2: replace s_mbus_fmt by set_fmt in bridge drivers
Hi Hans, Thanks for the patch. On Thu, Apr 9, 2015 at 11:21 AM, Hans Verkuil wrote: > From: Hans Verkuil > > Replace all calls to s_mbus_fmt in bridge drivers by calls to the > set_fmt pad op. > > Remove the old try/s_mbus_fmt video ops since they are now no longer used. > > Signed-off-by: Hans Verkuil > Cc: Guennadi Liakhovetski > Cc: Prabhakar Lad > Cc: Scott Jiang > Cc: Jonathan Corbet > --- > drivers/media/pci/cx18/cx18-controls.c | 13 +++-- > drivers/media/pci/cx18/cx18-ioctl.c| 12 +++-- > drivers/media/pci/cx23885/cx23885-video.c | 12 +++-- > drivers/media/pci/ivtv/ivtv-controls.c | 12 +++-- > drivers/media/pci/ivtv/ivtv-ioctl.c| 12 +++-- > drivers/media/pci/saa7134/saa7134-empress.c| 10 ++-- > drivers/media/platform/am437x/am437x-vpfe.c| 19 ++- > drivers/media/platform/blackfin/bfin_capture.c | 8 +-- > drivers/media/platform/marvell-ccic/mcam-core.c| 8 +-- > drivers/media/platform/sh_vou.c| 61 > -- > drivers/media/platform/soc_camera/atmel-isi.c | 27 +- > drivers/media/platform/soc_camera/mx2_camera.c | 35 +++-- > drivers/media/platform/soc_camera/mx3_camera.c | 31 ++- > drivers/media/platform/soc_camera/omap1_camera.c | 44 +--- > drivers/media/platform/soc_camera/pxa_camera.c | 33 ++-- > drivers/media/platform/soc_camera/rcar_vin.c | 4 +- > .../platform/soc_camera/sh_mobile_ceu_camera.c | 8 +-- > drivers/media/platform/soc_camera/soc_scale_crop.c | 37 +++-- > drivers/media/platform/via-camera.c| 8 +-- > drivers/media/usb/cx231xx/cx231xx-417.c| 12 +++-- > drivers/media/usb/cx231xx/cx231xx-video.c | 23 > drivers/media/usb/em28xx/em28xx-camera.c | 12 +++-- > drivers/media/usb/go7007/go7007-v4l2.c | 12 +++-- > drivers/media/usb/pvrusb2/pvrusb2-hdw.c| 17 +++--- > include/media/v4l2-subdev.h| 8 --- > 25 files changed, 256 insertions(+), 222 deletions(-) > for am437x Acked-by: Lad, Prabhakar Tested-by: Lad, Prabhakar Cheers, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] v4l2: replace video op g_mbus_fmt by pad op get_fmt
Hi Hans, Thanks for the patch. On Thu, Apr 9, 2015 at 11:21 AM, Hans Verkuil wrote: > From: Hans Verkuil > > The g_mbus_fmt video op is a duplicate of the pad op. Replace all uses > by the get_fmt pad op and remove the video op. > > Signed-off-by: Hans Verkuil > Cc: Guennadi Liakhovetski > Cc: Prabhakar Lad > Cc: Kamil Debski > --- [Snip] > drivers/media/i2c/tvp514x.c| 35 ++ > drivers/media/i2c/tvp7002.c| 28 --- > drivers/media/platform/am437x/am437x-vpfe.c| 6 +-- > drivers/media/platform/davinci/vpfe_capture.c | 19 For the above, Acked-by: Lad, Prabhakar Cheers, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] v4l2: replace enum_mbus_fmt by enum_mbus_code
Hi Hans,
Thanks for the patch.
On Thu, Apr 9, 2015 at 11:21 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Replace all calls to the enum_mbus_fmt video op by the pad
> enum_mbus_code op and remove the duplicate video op.
>
> Signed-off-by: Hans Verkuil
> Cc: Guennadi Liakhovetski
> Cc: Scott Jiang
> Cc: Jonathan Corbet
> Cc: Kamil Debski
> ---
> drivers/media/i2c/adv7170.c| 15
> drivers/media/i2c/adv7175.c| 15
> drivers/media/i2c/adv7183.c| 15
> drivers/media/i2c/adv7842.c| 11 +
> drivers/media/i2c/ak881x.c | 15
> drivers/media/i2c/ml86v7667.c | 15
> drivers/media/i2c/mt9v011.c| 15
> drivers/media/i2c/ov7670.c | 11 +
> drivers/media/i2c/soc_camera/imx074.c | 16 +
> drivers/media/i2c/soc_camera/mt9m001.c | 15
> drivers/media/i2c/soc_camera/mt9m111.c | 15
> drivers/media/i2c/soc_camera/mt9t031.c | 15
> drivers/media/i2c/soc_camera/mt9t112.c | 15
> drivers/media/i2c/soc_camera/mt9v022.c | 15
> drivers/media/i2c/soc_camera/ov2640.c | 15
> drivers/media/i2c/soc_camera/ov5642.c | 15
> drivers/media/i2c/soc_camera/ov6650.c | 15
> drivers/media/i2c/soc_camera/ov772x.c | 15
> drivers/media/i2c/soc_camera/ov9640.c | 15
> drivers/media/i2c/soc_camera/ov9740.c | 19 +--
> drivers/media/i2c/soc_camera/rj54n1cb0c.c | 15
> drivers/media/i2c/soc_camera/tw9910.c | 15
> drivers/media/i2c/sr030pc30.c | 16 +
> drivers/media/i2c/tvp514x.c| 20
> drivers/media/i2c/tvp7002.c| 20
For the above 2,
Acked-by: Lad, Prabhakar
Cheers,
--Prabhakar Lad
> drivers/media/i2c/vs6624.c | 15
> drivers/media/platform/blackfin/bfin_capture.c | 17 +-
> drivers/media/platform/soc_camera/atmel-isi.c | 19 ---
> drivers/media/platform/soc_camera/mx2_camera.c | 27
> --
> drivers/media/platform/soc_camera/mx3_camera.c | 23 ++
> drivers/media/platform/soc_camera/omap1_camera.c | 21 +
> drivers/media/platform/soc_camera/pxa_camera.c | 19 ---
> drivers/media/platform/soc_camera/rcar_vin.c | 19 ---
> .../platform/soc_camera/sh_mobile_ceu_camera.c | 19 ---
> drivers/media/platform/soc_camera/soc_camera.c | 15
> .../platform/soc_camera/soc_camera_platform.c | 15
> include/media/v4l2-subdev.h| 4
> 38 files changed, 361 insertions(+), 250 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7170.c b/drivers/media/i2c/adv7170.c
> index 40a1a95..cfe963b 100644
> --- a/drivers/media/i2c/adv7170.c
> +++ b/drivers/media/i2c/adv7170.c
> @@ -262,13 +262,14 @@ static int adv7170_s_routing(struct v4l2_subdev *sd,
> return 0;
> }
>
> -static int adv7170_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
> - u32 *code)
> +static int adv7170_enum_mbus_code(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_mbus_code_enum *code)
> {
> - if (index >= ARRAY_SIZE(adv7170_codes))
> + if (code->pad || code->index >= ARRAY_SIZE(adv7170_codes))
> return -EINVAL;
>
> - *code = adv7170_codes[index];
> + code->code = adv7170_codes[code->index];
> return 0;
> }
>
> @@ -323,11 +324,15 @@ static const struct v4l2_subdev_video_ops
> adv7170_video_ops = {
> .s_routing = adv7170_s_routing,
> .s_mbus_fmt = adv7170_s_fmt,
> .g_mbus_fmt = adv7170_g_fmt,
> - .enum_mbus_fmt = adv7170_enum_fmt,
> +};
> +
> +static const struct v4l2_subdev_pad_ops adv7170_pad_ops = {
> + .enum_mbus_code = adv7170_enum_mbus_code,
> };
>
> static const struct v4l2_subdev_ops adv7170_ops = {
> .video = &adv7170_video_ops,
> + .pad = &adv7170_pad_ops,
> };
>
> /* --- */
> diff --git a/drivers/media/i2c/adv7175.c b/drivers/media/i2c/adv7175.c
> index d220af5..3f40304 100644
> --- a/drivers/media/i2c/adv7175.c
> +++ b/drivers/media/i2c/adv7175.c
> @@ -300,13 +300,14 @@ static int adv7175_s_routing(struct v4l2_subdev *sd,
> return 0;
> }
>
> -static int adv7175_enum_fmt(struct v4l2_subdev *sd, unsigned int i
Re: [PATCH v8 1/1] media: i2c/adp1653: Devicetree support for adp1653
Hi Sebastian,
On Thu, Apr 16, 2015 at 07:24:42AM +0200, Sebastian Reichel wrote:
> Hi Sakari,
>
> Since this driver won't make it into 4.1 anyways, I have one more
> comment:
>
> On Thu, Apr 16, 2015 at 02:37:13AM +0300, Sakari Ailus wrote:
...
> > @@ -308,16 +311,28 @@ __adp1653_set_power(struct adp1653_flash *flash, int
> > on)
> > {
> > int ret;
> >
> > - ret = flash->platform_data->power(&flash->subdev, on);
> > - if (ret < 0)
> > - return ret;
> > + if (flash->platform_data->power) {
> > + ret = flash->platform_data->power(&flash->subdev, on);
> > + if (ret < 0)
> > + return ret;
> > + } else {
> > + gpiod_set_value(flash->platform_data->enable_gpio, on);
> > + if (on)
> > + /* Some delay is apparently required. */
> > + udelay(20);
> > + }
>
> I suggest to remove the power callback from platform data. Instead
> you can require to setup a gpiod lookup table in the boardcode, if
> platform data based initialization is used (see for example si4713
> initialization in board-rx51-periphals.c).
>
> This will reduce complexity in the driver and should be fairly easy
> to implement, since there is no adp1653 platform code user in the
> mainline kernel anyways.
There are a couple of out-of-tree users perhaps. I think that I'd rather
remove platform data support altogether than trying to polish it.
The timeline could be about the same than with the omap3isp driver, that
shouldn't be too many minor kernel versions either.
What do you think?
...
> > diff --git a/include/media/adp1653.h b/include/media/adp1653.h
> > index 1d9b48a..9779c85 100644
> > --- a/include/media/adp1653.h
> > +++ b/include/media/adp1653.h
> > @@ -100,9 +100,11 @@ struct adp1653_platform_data {
> > int (*power)(struct v4l2_subdev *sd, int on);
> >
> > u32 max_flash_timeout; /* flash light timeout in us */
> > - u32 max_flash_intensity;/* led intensity, flash mode */
> > - u32 max_torch_intensity;/* led intensity, torch mode */
> > - u32 max_indicator_intensity;/* indicator led intensity */
> > + u32 max_flash_intensity;/* led intensity, flash mode, mA */
> > + u32 max_torch_intensity;/* led intensity, torch mode, mA */
> > + u32 max_indicator_intensity;/* indicator led intensity, uA */
> > +
> > + struct gpio_desc *enable_gpio; /* for device-tree based boot */
>
> IMHO this should become part of "struct adp1653_flash", so that
> adp1653_platform_data only contains variables, which should be
> filled by boardcode / manual DT parsing code.
We'll get rid of the whole header with platform data support removal. :-)
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rc-core: use an IDA rather than a bitmap
Hi On 2015-04-02, David Härdeman wrote: > This patch changes rc-core to use the kernel facilities that are already > available for handling unique numbers instead of rolling its own bitmap > stuff. > > Stefan, this should apply cleanly to the media git tree...could you test it? > --- > drivers/media/rc/rc-ir-raw.c |2 +- > drivers/media/rc/rc-main.c | 40 > include/media/rc-core.h |4 ++-- > 3 files changed, 23 insertions(+), 23 deletions(-) Just some preliminary feedback after two weeks of testing. So far the problem with multiple rc_core devices fighting over the same sysfs file hasn't occured again, but it's a bit too early to be completely sure about it (probably 4-5 more weeks before I can be (relatively) confident that the problem is really gone). With this patch applied, everything continues to work fine for me; I haven't noticed any problems. Thanks a lot Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 1/1] media: i2c/adp1653: Devicetree support for adp1653
Hi! > > > This will reduce complexity in the driver and should be fairly easy > > > to implement, since there is no adp1653 platform code user in the > > > mainline kernel anyways. > > > > I'd hate to break out of tree users for very little gain. ... > So let's have a look at the advantages of removing the power gpio: One change per patch. My change did what it said, "add a device tree support", if you want to do second change "break existing interface", feel free doing it as a separate patch. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR
On Apr 15, 2015 6:54 PM, "Andy Walls" wrote: > > On Wed, 2015-04-15 at 17:58 -0700, Andy Lutomirski wrote: > > On Wed, Apr 15, 2015 at 4:59 PM, Andy Walls wrote: > > > On Wed, 2015-04-15 at 16:42 -0700, Andy Lutomirski wrote: > > >> On Wed, Apr 15, 2015 at 3:38 PM, Andy Walls > > >> wrote: > > > > > >> > > > >> > > >> IMO the right solution would be to avoid ioremapping the whole bar at > > >> startup. Instead ioremap pieces once the driver learns what they are. > > >> This wouldn't have any of these problems -- you'd ioremap() register > > >> regions and you'd ioremap_wc() the framebuffer once you find it. If > > >> there are regions of unknown purpose, just don't map them all. > > >> > > >> Would this be feasible? > > > > > > Feasible? Maybe. > > > > > > Worth the time and effort for end-of-life, convential PCI hardware so I > > > can have an optimally performing X display on a Standard Def Analog TV > > > screen? Nope. I don't have that level of nostalgia. > > > > > > > The point is actually to let us unexport or delete mtrr_add. > > Understood. > > > > We can > > either severely regress performance on ivtv on PAT-capable hardware if > > we naively switch it to arch_phys_wc_add or we can do something else. > > The something else remains to be determined. > > Maybe ioremap the decoder register area as UC, and ioremap the rest of > the decoder region to WC. (Does that suck up too many PAT resources? PAT resources are unlimited. > Then add PCI reads following any sort of singleton PCI writes in the WC > region. I assume PCI rules about write postings before reads still > apply when WC is set. > I think we need sfence, too, but that's easy. We also lose the write sizes. That is, adjacent writes get combined. Maybe that's okay. > > > > > > We sort of know where some things are in the MMIO space due to > > > experimentation and past efforts examining the firmware binary. > > > > > > Documentation/video4linux/cx2341x/fw-*.txt documents some things. The > > > driver code actually codifies a little bit more knowledge. > > > > > > The driver code for doing transfers between host and card is complex and > > > fragile with some streams that use DMA, other streams that use PIO, > > > digging VBI data straight out of card memory, and scatter-gather being > > > broken on newer firmwares. Playing around with ioremapping will be hard > > > to get right and likely cause something in the code to break for the > > > primary use case of the ivtv supported cards. > > > > Ick. > > Yeah. > > > If the only thing that really wants WC is the esoteric framebuffer > > thing, > > That appears to be it. > > > could we just switch to arch_phys_wc_add and assume that no one > > will care about the regression on new CPUs with ivtv cards? > > That's on the table in my mind. Not sure if it is the friendliest thing > to do to users. Quite honestly though, modern graphics cards have much > better ouput resolution and performance. Anyone with a modern system > really should be using one. (i.e. MythTV gave up on support for PVR-350 > output for video playback years ago in May 2010.) > > > BTW, my 2005 system with multiple conventional PCI slots in it shows a > 'pat' flag in /proc/cpuinfo. (AMD Athlon(tm) 64 X2 Dual Core Processor > 4200+) I didn't know it was considered "new". :) Tons of CPUs have that ability, but we often turn it off due to errata on older CPUs. --Andy > > Regards, > Andy > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR
On Thu, Apr 16, 2015 at 01:18:37PM +0900, Hyong-Youb Kim wrote: > On Thu, Apr 16, 2015 at 01:58:16AM +0200, Luis R. Rodriguez wrote: > > > > An alternative... is to just ioremap_wc() the entire region, including > > MMIO registers for these old devices. I see one ethernet driver that does > > this, myri10ge, and am curious how and why they ended up deciding this > > and if they have run into any issues. I wonder if this is a reasonable > > comrpomise for these 2 remaining corner cases. > > > > For myri10ge, it a performance thing. Descriptor rings are in NIC > memory BAR0, not in host memory. Say, to send a packet, the driver > writes the send descriptor to the ioremap'd NIC memory. It is a > multi-word descriptor. So, to send it as one PCIE MWr transaction, > the driver maps the whole BAR0 as WC and does "copy descriptor; wmb". Interesting, so you burst write multi-word descriptor writes using write-combining here for the Ethernet device. > Without WC, descriptors would end up as multiple 4B or 8B MWr packets > to the NIC, which has a pretty big performance impact on this > particular NIC. How big are the descriptors? > Most registers that do not want WC are actually in BAR2, which is not > mapped as WC. For registers that are in BAR0, we do "write to the > register; wmb". If we want to wait till the NIC has seen the write, > we do "write; wmb; read". Interesting, thanks, yeah using this as a work around to the problem sounds plausible however it still would require likely making just as many changes to the ivtv and ipath driver as to just do a proper split. I do wonder however if this sort of work around can be generalized somehow though so that others could use, if this sort of thing is going to become prevalent. If so then this would serve two purposes: work around for the corner cases of MTRR use on Linux and also these sorts of device constraints. In order to determine if this is likely to be generally useful could you elaborate a bit more about the detals of the performance issues of not bursting writes for the descriptor on this device. Even if that is done a conversion over to this work around seems it may require device specific nitpicks. For instance I note in myri10ge_submit_req() for small writes you just do a reverse write and do the first set last, then finally the last 32 bits are rewritten, I guess to trigger something? > This approach has worked for this device for many years. I cannot say > whether it works for other devices, though. I think it should but the more interesting question would be exactly *why* it was needed for this device, who determined that, and why? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP previewer Y10 to UYVY conversion
On Tue, Apr 7, 2015 at 10:51 AM, Laurent Pinchart
wrote:
> Black level compensation is applied by the CCDC before writing raw frames to
> memory. If your raw frames are correct BLC is probably not to blame.
>
> The default contrast is x1.0 and the default brightness is +0.0, so I don't
> think those should be blame either.
>
> I suspect the RGB2RGB conversion matrix to be wrong. The default setting is
> supposed to handle fluorescent lighting. You could try setting the RGB2RGB
> matrix to the identity matrix and see if this helps. See
> http://git.ideasonboard.org/omap3-isp-live.git/blob/HEAD:/isp/controls.c#l184
> for sample code.
>
> Another matrix that could be worth being reprogrammed is the RGB2YUV matrix,
> which also defaults to fluorescent lighting. Sample code to reprogram it is
> available in the same location.
I tried changing the rgb2rgb matrx to the identity matrix:
{0x0100, 0x, 0x},
{0x, 0x0100, 0x},
{0x, 0x, 0x0100}
And the csc (rgb2yuv) to this:
{256, 0, 0},
{0, 0, 0},
{0, 0, 0}
But I couldn't see much, if any, difference.
However, when I forced the gamma correction to be bypassed, it seemed to fix it.
Does that make sense? I guess I don't understand it enough to
understand if gamma correction would have compressed all my luma
values.
Thanks,
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 1/1] media: i2c/adp1653: Devicetree support for adp1653
Hi Pavel,
On Thu, Apr 16, 2015 at 07:58:18AM +0200, Pavel Machek wrote:
> On Thu 2015-04-16 07:24:42, Sebastian Reichel wrote:
> > Hi Sakari,
> >
> > Since this driver won't make it into 4.1 anyways, I have one more
> > comment:
>
> Like this driver did not receive enough bikesheding.
You should become more restrained with this argument if
you want it to be taken seriously by me in the future...
> > > + } else {
> > > + gpiod_set_value(flash->platform_data->enable_gpio, on);
> > > + if (on)
> > > + /* Some delay is apparently required. */
> > > + udelay(20);
> > > + }
> >
> > I suggest to remove the power callback from platform data. Instead
> > you can require to setup a gpiod lookup table in the boardcode, if
> > platform data based initialization is used (see for example si4713
> > initialization in board-rx51-periphals.c).
> >
> > This will reduce complexity in the driver and should be fairly easy
> > to implement, since there is no adp1653 platform code user in the
> > mainline kernel anyways.
>
> I'd hate to break out of tree users for very little gain.
This normally happens as the kernel progresses. If you want your
driver not to break, you should sent it upstream and maintain it.
Also the only out-of-tree user I know is the Nokia N900 (which has
already broken camera subsystem). Note that the required out of tree
changes to use the platform code with gpiod interface are actually
quite small and if you really care about it, they could actually be
done *in kernel*.
Note that many drivers are updated to use new kernel APIs together
with the DT changes - especially those, which haven't been updated
for quite some time.
So let's have a look at the advantages of removing the power gpio:
+ gpio handling is always done in the driver, making code
easier to read
+ less loc in the driver, making it easier to read
+ less loc in the boardcode (no gpio requesting/releasing)
+ less branching in driver code - easier testing coverage
- out of tree users will break
So basically its code quality vs minor out-of-tree breakage.
-- Sebastian
signature.asc
Description: Digital signature
Re: [media] i2c: ov2659: signedness bug inov2659_set_fmt()
Dan Carpenter wrote on Wed [2015-Apr-15 22:12:18
+0300]:
> This needs to be signed or there is a risk of hitting a forever loop.
>
> Fixes: c4c0283ab3cd ('[media] media: i2c: add support for omnivision's ov2659
> sensor')
> Signed-off-by: Dan Carpenter
>
Acked-by: Benoit Parrot
> diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
> index edebd11..d700a1d 100644
> --- a/drivers/media/i2c/ov2659.c
> +++ b/drivers/media/i2c/ov2659.c
> @@ -1102,7 +1102,7 @@ static int ov2659_set_fmt(struct v4l2_subdev *sd,
> struct v4l2_subdev_format *fmt)
> {
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> - unsigned int index = ARRAY_SIZE(ov2659_formats);
> + int index = ARRAY_SIZE(ov2659_formats);
> struct v4l2_mbus_framefmt *mf = &fmt->format;
> const struct ov2659_framesize *size = NULL;
> struct ov2659 *ov2659 = to_ov2659(sd);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] si2165 - Add DVB-C Support
From: beta990
Subject: [PATCH] si2165 - Add DVB-C Support
This patch is based of the work of ZZram.
I clean-up his patch and removed double code (e.g. double resets,
actions, etc.):
// -- init?
ret = si2165_readreg8(state, 0x00e0, val); /* returned 0x00 */
if (ret < 0)
return ret;
ret = si2165_writereg32(state, 0x00e8, 0x02db6db6);
if (ret < 0)
return ret;
-- //
Remember this is the first time I submit a patch, please be gentle. ;P
Patch contents:
diff --git a/drivers/media/dvb-frontends/si2165.c
b/drivers/media/dvb-frontends/si2165.c
index 4cc5d10..d283d68 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -704,7 +704,7 @@ static int si2165_read_status(struct dvb_frontend
*fe, fe_status_t *status)
u8 fec_lock = 0;
struct si2165_state *state = fe->demodulator_priv;
- if (!state->has_dvbt)
+ if (!state->has_dvbt || !state->has_dvbc)
return -EINVAL;
/* check fec_lock */
@@ -777,131 +777,272 @@ static int si2165_set_parameters(struct
dvb_frontend *fe)
return -EINVAL;
}
- if (!state->has_dvbt)
+ if (!state->has_dvbt || !state->has_dvbc)
return -EINVAL;
- if (p->bandwidth_hz > 0) {
- dvb_rate = p->bandwidth_hz * 8 / 7;
- bw10k = p->bandwidth_hz / 1;
- } else {
- dvb_rate = 8 * 8 / 7;
- bw10k = 800;
- }
+ if (p->delivery_system == SYS_DVBT) {
+ if (p->bandwidth_hz > 0) {
+ dvb_rate = p->bandwidth_hz * 8 / 7;
+ bw10k = p->bandwidth_hz / 1;
+ } else {
+ dvb_rate = 8 * 8 / 7;
+ bw10k = 800;
+ }
- /* standard = DVB-T */
- ret = si2165_writereg8(state, 0x00ec, 0x01);
- if (ret < 0)
- return ret;
- ret = si2165_adjust_pll_divl(state, 12);
- if (ret < 0)
- return ret;
+ /* DVB-T */
+ ret = si2165_writereg8(state, 0x00ec, 0x01);
+ if (ret < 0)
+ return ret;
+ ret = si2165_adjust_pll_divl(state, 12);
+ if (ret < 0)
+ return ret;
- fe->ops.tuner_ops.get_if_frequency(fe, &IF);
- ret = si2165_set_if_freq_shift(state, IF);
- if (ret < 0)
- return ret;
- ret = si2165_writereg8(state, 0x08f8, 0x00);
- if (ret < 0)
- return ret;
- /* ts output config */
- ret = si2165_writereg8(state, 0x04e4, 0x20);
- if (ret < 0)
- return ret;
- ret = si2165_writereg16(state, 0x04ef, 0x00fe);
- if (ret < 0)
- return ret;
- ret = si2165_writereg24(state, 0x04f4, 0x55);
- if (ret < 0)
- return ret;
- ret = si2165_writereg8(state, 0x04e5, 0x01);
- if (ret < 0)
- return ret;
- /* bandwidth in 10KHz steps */
- ret = si2165_writereg16(state, 0x0308, bw10k);
- if (ret < 0)
- return ret;
- ret = si2165_set_oversamp(state, dvb_rate);
- if (ret < 0)
- return ret;
- /* impulsive_noise_remover */
- ret = si2165_writereg8(state, 0x031c, 0x01);
- if (ret < 0)
- return ret;
- ret = si2165_writereg8(state, 0x00cb, 0x00);
- if (ret < 0)
- return ret;
- /* agc2 */
- ret = si2165_writereg8(state, 0x016e, 0x41);
- if (ret < 0)
- return ret;
- ret = si2165_writereg8(state, 0x016c, 0x0e);
- if (ret < 0)
- return ret;
- ret = si2165_writereg8(state, 0x016d, 0x10);
- if (ret < 0)
- return ret;
- /* agc */
- ret = si2165_writereg8(state, 0x015b, 0x03);
- if (ret < 0)
- return ret;
- ret = si2165_writereg8(state, 0x0150, 0x78);
- if (ret < 0)
- return ret;
- /* agc */
- ret = si2165_writereg8(state, 0x01a0, 0x78);
- if (ret < 0)
- return ret;
- ret = si2165_writereg8(state, 0x01c8, 0x68);
- if (ret < 0)
- return ret;
- /* freq_sync_range */
- ret = si2165_writereg16(state, 0x030c, 0x0064);
- if (ret < 0)
- return ret;
- /* gp_reg0 */
- ret = si2165_readreg8(state, 0x0387, val);
- if (ret < 0)
- return ret;
- ret = si2165_writereg8(state, 0x0387, 0x00);
- if (ret < 0)
- return ret;
- /* dsp_addr_jump */
- ret = si2165_writereg32(state, 0x0348, 0xf400);
- if (ret < 0)
- return ret;
+ fe->ops.tuner_ops.get_if_frequency(fe, &IF);
+ ret = si2165_set_if_freq_shift(state, IF);
+ if (ret < 0)
+ return ret;
+ ret = si2165_writereg8(state, 0x08f8, 0x00);
+ if (ret < 0)
+ return ret;
+ /* ts output config */
+ ret = si2165_writereg8(state, 0x04e4, 0x20);
+ if (ret < 0)
+ return ret;
+ ret = si2165_writereg16(state, 0x04ef, 0x00fe);
+ if (ret < 0)
+ return ret;
+ ret = si2165_writereg24(state, 0x04f4, 0x55);
+ if (ret < 0)
+ return ret;
+ ret = si2165_writereg8(state, 0x04e5, 0x01);
+ if (ret < 0)
+ return ret;
+ /* bandwidth in 10KHz steps */
+ ret = si2165_writereg16(state, 0x0308, bw10k);
+ if (ret < 0)
+ return ret;
+ ret = si2165_set_oversamp(state, dvb_rate);
+ if (ret < 0)
+ return ret;
+ /* impulsive_noise_remover */
+ ret = si2165_writereg8(state, 0x031c, 0x01);
+ if (ret < 0)
+ return ret;
+ ret = si2165_writereg8(state, 0x00cb, 0x00);
+ if (ret < 0)
+ return ret;
+ /* agc2 */
+ ret = si2165_writereg8(state, 0x016e, 0x41);
+ if (ret < 0)
+ return ret;
+ ret = si2165_writereg8(state, 0x016c, 0x0e);
+ if (ret < 0)
+ return ret;
+ ret = si2165_writereg8(state, 0x016d, 0x10);
+ if (ret < 0)
+ return ret;
+ /* agc */
+ ret = si2165_writereg8(state, 0x015b, 0x03);
+ if (ret < 0)
+ return ret;
+ ret = si2165_writereg8(state, 0x0150, 0x78);
+ if (ret < 0)
+ return ret;
+ /* agc */
+ ret = s
[PATCH -next] staging: dt3155v4l: remove unused including
From: Wei Yongjun Remove including that don't need it. Signed-off-by: Wei Yongjun --- drivers/staging/media/dt3155v4l/dt3155v4l.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c b/drivers/staging/media/dt3155v4l/dt3155v4l.c index e60a53e..7946ee0 100644 --- a/drivers/staging/media/dt3155v4l/dt3155v4l.c +++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c @@ -19,7 +19,6 @@ ***/ #include -#include #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] rtl28xxu: fix return value check in rtl2832u_tuner_attach()
From: Wei Yongjun In case of error, the function platform_device_register_data() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun --- drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c index 87fc0fe..1723407 100644 --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c @@ -1176,7 +1176,7 @@ static int rtl2832u_tuner_attach(struct dvb_usb_adapter *adap) "rtl2832_sdr", PLATFORM_DEVID_AUTO, &pdata, sizeof(pdata)); - if (pdev == NULL || pdev->dev.driver == NULL) + if (IS_ERR(pdev) || pdev->dev.driver == NULL) break; dev->platform_device_sdr = pdev; break; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] v4l2: replace enum_mbus_fmt by enum_mbus_code
2015-04-09 18:21 GMT+08:00 Hans Verkuil : > From: Hans Verkuil > > Replace all calls to the enum_mbus_fmt video op by the pad > enum_mbus_code op and remove the duplicate video op. > > Signed-off-by: Hans Verkuil > Cc: Guennadi Liakhovetski > Cc: Scott Jiang > Cc: Jonathan Corbet > Cc: Kamil Debski > --- > drivers/media/i2c/adv7183.c| 15 > drivers/media/i2c/vs6624.c | 15 > drivers/media/platform/blackfin/bfin_capture.c | 17 +- For these patches, Acked-by: Scott Jiang -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media] i2c: ov2659: signedness bug inov2659_set_fmt()
On Wed, Apr 15, 2015 at 8:12 PM, Dan Carpenter wrote:
> This needs to be signed or there is a risk of hitting a forever loop.
>
> Fixes: c4c0283ab3cd ('[media] media: i2c: add support for omnivision's ov2659
> sensor')
> Signed-off-by: Dan Carpenter
>
Acked-by: Lad, Prabhakar
Cheers,
--Prabhakar Lad
> diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
> index edebd11..d700a1d 100644
> --- a/drivers/media/i2c/ov2659.c
> +++ b/drivers/media/i2c/ov2659.c
> @@ -1102,7 +1102,7 @@ static int ov2659_set_fmt(struct v4l2_subdev *sd,
> struct v4l2_subdev_format *fmt)
> {
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> - unsigned int index = ARRAY_SIZE(ov2659_formats);
> + int index = ARRAY_SIZE(ov2659_formats);
> struct v4l2_mbus_framefmt *mf = &fmt->format;
> const struct ov2659_framesize *size = NULL;
> struct ov2659 *ov2659 = to_ov2659(sd);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
honestech VIDBOX NW07 (eMPIA EM28284)
I've recently bought an "honestech VIDBOX for Mac pack" which contains an "honestech VIDBOX NW07" analog video to USB grabber device based on the eMPIA EM28284 chip. The only other chip on the PCB is a 24C32WP 4 kB serial EEPROM. USB ID = eb1a:5188 What is the status of Linux support for this device? I've written up all information that I have about it so far at http://linuxtv.org/wiki/index.php/Honestech_Vidbox_NW07 including a PCB photo and lsusb -v output. What can I do to help getting a Linux driver for it working? Markus http://www.honestech.com/main/DriverUpdates.asp#VIDBOXdrivers http://www.honestech.com/main/VIDBOXforMac.asp -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] v4l2: replace try_mbus_fmt by set_fmt in bridge drivers
2015-04-09 18:21 GMT+08:00 Hans Verkuil : > From: Hans Verkuil > > Replace all calls to try_mbus_fmt in bridge drivers by calls to the > set_fmt pad op. > > Signed-off-by: Hans Verkuil > Cc: Guennadi Liakhovetski > Cc: Scott Jiang > Cc: Jonathan Corbet > --- > drivers/media/pci/saa7134/saa7134-empress.c| 11 +++--- > drivers/media/platform/blackfin/bfin_capture.c | 15 Acked-by: Scott Jiang -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] v4l2: replace s_mbus_fmt by set_fmt in bridge drivers
2015-04-09 18:21 GMT+08:00 Hans Verkuil : > From: Hans Verkuil > > Replace all calls to s_mbus_fmt in bridge drivers by calls to the > set_fmt pad op. > > Remove the old try/s_mbus_fmt video ops since they are now no longer used. > > Signed-off-by: Hans Verkuil > Cc: Guennadi Liakhovetski > Cc: Prabhakar Lad > Cc: Scott Jiang > Cc: Jonathan Corbet > --- > drivers/media/platform/blackfin/bfin_capture.c | 8 +-- Acked-by: Scott Jiang -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
Hi,
> From: Philipp Zabel [mailto:p.za...@pengutronix.de]
> Sent: Monday, April 13, 2015 6:15 PM
> To: Pawel Osciak
> Cc: LMML; Hans Verkuil; Kamil Debski; Laurent Pinchart; Nicolas
> Dufresne; Sakari Ailus; ker...@pengutronix.de
> Subject: Re: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF
> after the last buffer
>
> Hi Pawel,
>
> thanks for the review!
>
> Am Montag, den 13.04.2015, 15:30 +0900 schrieb Pawel Osciak:
> > Hi,
> >
> > On Wed, Mar 25, 2015 at 2:46 AM, Philipp Zabel
> wrote:
> > > If the last buffer was dequeued from a capture queue, let poll
> > > return immediately and let DQBUF return -EPIPE to signal there will
> > > no more buffers to dequeue until STREAMOFF.
> > > The driver signals the last buffer by setting the
> V4L2_BUF_FLAG_LAST.
> > > To reenable dequeuing on the capture queue, the driver must
> > > explicitly call vb2_clear_last_buffer_queued. The last buffer
> queued
> > > flag is cleared automatically during STREAMOFF.
> > >
> > > Signed-off-by: Philipp Zabel
> > > ---
> > > Changes since v3:
> > > - Added DocBook update mentioning DQBUF returning -EPIPE in the
> encoder/decoder
> > >stop command documentation.
> > > ---
> > > Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 4 +++-
> > > Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml | 4 +++-
> > > Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 8
>
> > > drivers/media/v4l2-core/v4l2-mem2mem.c | 10
> +-
> > > drivers/media/v4l2-core/videobuf2-core.c | 18
> +-
> > > include/media/videobuf2-core.h | 10
> ++
> > > 6 files changed, 50 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
> > > b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
> >
> > Would it make sense to perhaps split this patch into docbook and vb2
> > changes please?
>
> Alright, I'll split DocBook from vb2 changes, with the documentation
> patches first.
>
> > > diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
> > > b/drivers/media/v4l2-core/v4l2-mem2mem.c
> > > index 80c588f..1b5b432 100644
> > > --- a/drivers/media/v4l2-core/v4l2-mem2mem.c
> > > +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
> > > @@ -564,8 +564,16 @@ unsigned int v4l2_m2m_poll(struct file *file,
> > > struct v4l2_m2m_ctx *m2m_ctx,
> > >
> > > if (list_empty(&src_q->done_list))
> > > poll_wait(file, &src_q->done_wq, wait);
> > > - if (list_empty(&dst_q->done_list))
> > > + if (list_empty(&dst_q->done_list)) {
> > > + /*
> > > +* If the last buffer was dequeued from the capture
> queue,
> > > +* return immediately. DQBUF will return -EPIPE.
> > > +*/
> > > + if (dst_q->last_buffer_dequeued)
> > > + return rc | POLLIN | POLLRDNORM;
> >
> > These indicate there is data to be read. Is there something else we
> > could return? Maybe POLLHUP?
>
> This is a good point, but I'm not sure. POLLHUP seems to mean a similar
> thing, yet not quite the same. The documentation explicitly mentions
> disconnected devices or FIFOs without writers, neither of which applies.
> Also a FIFO signals POLLHUP when the last writer leaves, so we would
> probably have to signal POLLHUP|POLLIN after the last buffer was
> decoded for consistency, and keep that until the last buffer is
> dequeued. Then we could signal POLLHUP alone here.
>
> I didn't want to risk redefining/misinterpreting any poll(2) behavior,
> so my interpretation was that POLLIN signals userspace to try a DQBUF,
> as usual.
>
> > > +
> > > poll_wait(file, &dst_q->done_wq, wait);
> > > + }
> > >
> > > if (m2m_ctx->m2m_dev->m2m_ops->lock)
> > > m2m_ctx->m2m_dev->m2m_ops->lock(m2m_ctx->priv);
> > > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> > > b/drivers/media/v4l2-core/videobuf2-core.c
> > > index bc08a82..a0b9946 100644
> > > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > > @@ -2046,6 +2046,10 @@ static int vb2_internal_dqbuf(struct
> vb2_queue *q, struct v4l2_buffer *b, bool n
> > > struct vb2_buffer *vb = NULL;
> > > int ret;
> > >
> > > + if (q->last_buffer_dequeued) {
> > > + dprintk(3, "last buffer dequeued already\n");
> > > + return -EPIPE;
> > > + }
> >
> > This should go after the check for queue type at least. However, best
> > probably to __vb2_wait_for_done_vb(), where we already have the
> checks
> > for q->streaming and q->error.
>
> Yes, that'll be better.
>
> > > if (b->type != q->type) {
> > > dprintk(1, "invalid buffer type\n");
> > > return -EINVAL;
> [...]
> > > @@ -2628,8 +2636,16 @@ unsigned int vb2_poll(struct vb2_queue *q,
> struct file *file, poll_table *wait)
> > >
[PATCH 2/2] media-ctl: libv4l2subdev: Add missing formats
Add support for the RGB888_1X24, RGB888_1X32_PADHI and VUY8_1X24
formats.
Signed-off-by: Laurent Pinchart
---
utils/media-ctl/libv4l2subdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
index 6ea6648..16aa530 100644
--- a/utils/media-ctl/libv4l2subdev.c
+++ b/utils/media-ctl/libv4l2subdev.c
@@ -708,6 +708,7 @@ static struct {
{ "UYVY", MEDIA_BUS_FMT_UYVY8_1X16 },
{ "UYVY1_5X8", MEDIA_BUS_FMT_UYVY8_1_5X8 },
{ "UYVY2X8", MEDIA_BUS_FMT_UYVY8_2X8 },
+ { "VUY24", MEDIA_BUS_FMT_VUY8_1X24 },
{ "SBGGR8", MEDIA_BUS_FMT_SBGGR8_1X8 },
{ "SGBRG8", MEDIA_BUS_FMT_SGBRG8_1X8 },
{ "SGRBG8", MEDIA_BUS_FMT_SGRBG8_1X8 },
@@ -725,6 +726,8 @@ static struct {
{ "SGRBG12", MEDIA_BUS_FMT_SGRBG12_1X12 },
{ "SRGGB12", MEDIA_BUS_FMT_SRGGB12_1X12 },
{ "AYUV32", MEDIA_BUS_FMT_AYUV8_1X32 },
+ { "RBG24", MEDIA_BUS_FMT_RBG888_1X24 },
+ { "RGB32", MEDIA_BUS_FMT_RGB888_1X32_PADHI },
{ "ARGB32", MEDIA_BUS_FMT_ARGB_1X32 },
};
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] media-ctl: libv4l2subdev: Switch to MEDIA_BUS_FMT_*
The V4L2_MBUS_FMT_* macros have been replaced by corresponding
MEDIA_BUS_FMT_* macros. The old names have been preserved for
compatibility reasons, but new formats will use MEDIA_BUS_FMT_* only.
Switch to the new name.
Signed-off-by: Laurent Pinchart
---
utils/media-ctl/libv4l2subdev.c | 54 -
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
index 8015330..6ea6648 100644
--- a/utils/media-ctl/libv4l2subdev.c
+++ b/utils/media-ctl/libv4l2subdev.c
@@ -699,33 +699,33 @@ static struct {
const char *name;
enum v4l2_mbus_pixelcode code;
} mbus_formats[] = {
- { "Y8", V4L2_MBUS_FMT_Y8_1X8},
- { "Y10", V4L2_MBUS_FMT_Y10_1X10 },
- { "Y12", V4L2_MBUS_FMT_Y12_1X12 },
- { "YUYV", V4L2_MBUS_FMT_YUYV8_1X16 },
- { "YUYV1_5X8", V4L2_MBUS_FMT_YUYV8_1_5X8 },
- { "YUYV2X8", V4L2_MBUS_FMT_YUYV8_2X8 },
- { "UYVY", V4L2_MBUS_FMT_UYVY8_1X16 },
- { "UYVY1_5X8", V4L2_MBUS_FMT_UYVY8_1_5X8 },
- { "UYVY2X8", V4L2_MBUS_FMT_UYVY8_2X8 },
- { "SBGGR8", V4L2_MBUS_FMT_SBGGR8_1X8 },
- { "SGBRG8", V4L2_MBUS_FMT_SGBRG8_1X8 },
- { "SGRBG8", V4L2_MBUS_FMT_SGRBG8_1X8 },
- { "SRGGB8", V4L2_MBUS_FMT_SRGGB8_1X8 },
- { "SBGGR10", V4L2_MBUS_FMT_SBGGR10_1X10 },
- { "SGBRG10", V4L2_MBUS_FMT_SGBRG10_1X10 },
- { "SGRBG10", V4L2_MBUS_FMT_SGRBG10_1X10 },
- { "SRGGB10", V4L2_MBUS_FMT_SRGGB10_1X10 },
- { "SBGGR10_DPCM8", V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 },
- { "SGBRG10_DPCM8", V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 },
- { "SGRBG10_DPCM8", V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 },
- { "SRGGB10_DPCM8", V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 },
- { "SBGGR12", V4L2_MBUS_FMT_SBGGR12_1X12 },
- { "SGBRG12", V4L2_MBUS_FMT_SGBRG12_1X12 },
- { "SGRBG12", V4L2_MBUS_FMT_SGRBG12_1X12 },
- { "SRGGB12", V4L2_MBUS_FMT_SRGGB12_1X12 },
- { "AYUV32", V4L2_MBUS_FMT_AYUV8_1X32 },
- { "ARGB32", V4L2_MBUS_FMT_ARGB_1X32 },
+ { "Y8", MEDIA_BUS_FMT_Y8_1X8},
+ { "Y10", MEDIA_BUS_FMT_Y10_1X10 },
+ { "Y12", MEDIA_BUS_FMT_Y12_1X12 },
+ { "YUYV", MEDIA_BUS_FMT_YUYV8_1X16 },
+ { "YUYV1_5X8", MEDIA_BUS_FMT_YUYV8_1_5X8 },
+ { "YUYV2X8", MEDIA_BUS_FMT_YUYV8_2X8 },
+ { "UYVY", MEDIA_BUS_FMT_UYVY8_1X16 },
+ { "UYVY1_5X8", MEDIA_BUS_FMT_UYVY8_1_5X8 },
+ { "UYVY2X8", MEDIA_BUS_FMT_UYVY8_2X8 },
+ { "SBGGR8", MEDIA_BUS_FMT_SBGGR8_1X8 },
+ { "SGBRG8", MEDIA_BUS_FMT_SGBRG8_1X8 },
+ { "SGRBG8", MEDIA_BUS_FMT_SGRBG8_1X8 },
+ { "SRGGB8", MEDIA_BUS_FMT_SRGGB8_1X8 },
+ { "SBGGR10", MEDIA_BUS_FMT_SBGGR10_1X10 },
+ { "SGBRG10", MEDIA_BUS_FMT_SGBRG10_1X10 },
+ { "SGRBG10", MEDIA_BUS_FMT_SGRBG10_1X10 },
+ { "SRGGB10", MEDIA_BUS_FMT_SRGGB10_1X10 },
+ { "SBGGR10_DPCM8", MEDIA_BUS_FMT_SBGGR10_DPCM8_1X8 },
+ { "SGBRG10_DPCM8", MEDIA_BUS_FMT_SGBRG10_DPCM8_1X8 },
+ { "SGRBG10_DPCM8", MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8 },
+ { "SRGGB10_DPCM8", MEDIA_BUS_FMT_SRGGB10_DPCM8_1X8 },
+ { "SBGGR12", MEDIA_BUS_FMT_SBGGR12_1X12 },
+ { "SGBRG12", MEDIA_BUS_FMT_SGBRG12_1X12 },
+ { "SGRBG12", MEDIA_BUS_FMT_SGRBG12_1X12 },
+ { "SRGGB12", MEDIA_BUS_FMT_SRGGB12_1X12 },
+ { "AYUV32", MEDIA_BUS_FMT_AYUV8_1X32 },
+ { "ARGB32", MEDIA_BUS_FMT_ARGB_1X32 },
};
const char *v4l2_subdev_pixelcode_to_string(enum v4l2_mbus_pixelcode code)
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
