This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Sat Feb 9 05:00:12 CET 2019
media-tree git hash:6fd369dd1cb65a032f1ab9227033ecb7b759656d
media_build git
Buffers generated with YUV32 format seems to be incorrect, hence use
VUYA32 instead.
Changes from v1:
Add both formats VUYA32 and VUYX32 but associate only VUYX32 to the
output queue as the alpha channel of buffers is ignored on this queue.
Cc: Philipp Zabel
Signed-off-by: Vivek Kasireddy
---
Add support for the following formats to tpg:
V4L2_PIX_FMT_AYUV32
V4L2_PIX_FMT_XYUV32
V4L2_PIX_FMT_VUYA32
V4L2_PIX_FMT_VUYX32
Changes from v1:
Remove the duplicate case value
Cc: Hans Verkuil
Signed-off-by: Vivek Kasireddy
---
drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 12
Simplify the selection of the Y'CbCr encoding matrices in init_csc().
A side-effect of this change is that init_csc() now allows YUV->YUV
using the identity matrix, intead of returning error.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 12
1 file changed, 4 ins
The IC now supports BT.709 Y'CbCr encoding, in addition to existing BT.601
encoding, so allow both, for pipelines that route through the IC.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- move ic_route check above default colorimetry checks, and fill default
color
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v4:
- fix compile error.
Chnges in v3:
- none.
Changes in v2:
- only return "Unsupported YCbCr
This patchset adds support for the BT.709 encoding and inverse encoding
matrices to the ipu_ic task init functions. The imx-media driver can
now support both BT.601 and BT.709 encoding.
History:
v4:
- fix a compile error in init_csc(), reported by Tim Harvey.
v3:
- fix some inconsistent From: and
The ycbcr2rgb and inverse rgb2ycbcr matrices define the BT.601 encoding
coefficients, so rename them to indicate that. And add some comments
to make clear these are BT.601 coefficients encoding between YUV limited
range and RGB full range. The ic_csc_rgb2rgb matrix is just an identity
matrix, so re
On 2/8/19 4:20 PM, Tim Harvey wrote:
On Fri, Feb 8, 2019 at 11:28 AM Steve Longerbeam wrote:
if (inf == outf)
params = &ic_csc_identity;
else if (inf == IPUV3_COLORSPACE_YUV)
- params = &ic_csc_ycbcr2rgb_bt601;
+ params = &ic_csc
On Fri, Feb 8, 2019 at 11:28 AM Steve Longerbeam wrote:
>
> Pass v4l2 encoding enum to the ipu_ic task init functions, and add
> support for the BT.709 encoding and inverse encoding matrices.
>
> Reported-by: Tim Harvey
> Signed-off-by: Steve Longerbeam
> ---
> Changes in v2:
> - only return "Un
On 2/8/19 1:23 PM, Tim Harvey wrote:
On Thu, Feb 7, 2019 at 5:54 PM Steve Longerbeam wrote:
Ok there is definitely something wrong when using the IC with
UYVY8_1X16 (passthrough) which works with UYVY8_2X8. It looks to me
like the ipu1_ic_prp isn't negotiating its format properly. You ca
Hi Maxime,
On Wed, Feb 06, 2019 at 10:16:05PM +0100, Maxime Ripard wrote:
> Hi Sakari,
>
> Thanks for your review, I have a few questions though, and the rest
> will be addressed in the next version.
>
> On Tue, Jan 29, 2019 at 02:39:49PM +0200, Sakari Ailus wrote:
> > > +static int csi_notify_c
Hi Mauro,
Here are the last RC fixes for 5.1.
Thanks,
Sean
The following changes since commit 6fd369dd1cb65a032f1ab9227033ecb7b759656d:
media: vimc: fill in bus_info in media_device_info (2019-02-07 12:38:59 -0500)
are available in the Git repository at:
git://linuxtv.org/syoung/media_tr
On Thu, Feb 7, 2019 at 5:54 PM Steve Longerbeam wrote:
>
>
> >>
> > Ok there is definitely something wrong when using the IC with
> > UYVY8_1X16 (passthrough) which works with UYVY8_2X8. It looks to me
> > like the ipu1_ic_prp isn't negotiating its format properly. You can't
> > re-create this be
On Thu, Feb 07, 2019 at 12:49:48PM +0100, hverkuil-ci...@xs4all.nl wrote:
> From: Hans Verkuil
>
> The epoll function expects that whenever the poll file op is
> called, the poll_wait function is also called. That didn't
> always happen in dvb_demux_poll(), dvb_dvr_poll() and
> dvb_ca_en50221_io_
Le 08/02/2019 16:51, Daniel Vetter a écrit :
> On Thu, Feb 07, 2019 at 10:44:10AM +0100, Neil Armstrong wrote:
>> Hi,
>>
>> On 14/01/2019 17:36, Ayan Halder wrote:
>>> On Thu, Jan 10, 2019 at 03:57:09AM +0800, Randy Li wrote:
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
On Thu, Feb 07, 2019 at 12:49:41PM +0100, hverkuil-ci...@xs4all.nl wrote:
> From: Hans Verkuil
>
> The epoll function expects that whenever the poll file op is
> called, the poll_wait function is also called. That didn't
> always happen in cec_poll(). Fix this, otherwise epoll()
> would timeout w
Hi Ezequiel,
On Wed, Feb 06, 2019 at 07:59:43PM -0300, Ezequiel Garcia wrote:
> > + csi->isp_clk = devm_clk_get(&pdev->dev, "isp");
> > + if (IS_ERR(csi->isp_clk)) {
> > + dev_err(&pdev->dev, "Couldn't get our ISP clock\n");
> > + return PTR_ERR(csi->isp_clk
Simplify the selection of the Y'CbCr encoding matrices in init_csc().
A side-effect of this change is that init_csc() now allows YUV->YUV
using the identity matrix, intead of returning error.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 12
1 file changed, 4 ins
The ycbcr2rgb and inverse rgb2ycbcr matrices define the BT.601 encoding
coefficients, so rename them to indicate that. And add some comments
to make clear these are BT.601 coefficients encoding between YUV limited
range and RGB full range. The ic_csc_rgb2rgb matrix is just an identity
matrix, so re
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- only return "Unsupported YCbCr encoding" error if inf != outf,
since if inf == outf, th
The IC now supports BT.709 Y'CbCr encoding, in addition to existing BT.601
encoding, so allow both, for pipelines that route through the IC.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- move ic_route check above default colorimetry checks, and fill default
color
This patchset adds support for the BT.709 encoding and inverse encoding
matrices to the ipu_ic task init functions. The imx-media driver can
now support both BT.601 and BT.709 encoding.
History:
v3:
- fix some inconsistent From: and Signed-off-by:'s.
No functional changes.
v2:
- rename ic_csc_rg
Simplify the selection of the Y'CbCr encoding matrices in init_csc().
A side-effect of this change is that init_csc() now allows YUV->YUV
using the identity matrix, intead of returning error.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 12
1 file changed, 4 ins
This patchset adds support for the BT.709 encoding and inverse encoding
matrices to the ipu_ic task init functions. The imx-media driver can
now support both BT.601 and BT.709 encoding.
History:
v2:
- rename ic_csc_rgb2rgb matrix to ic_csc_identity.
- only return "Unsupported YCbCr encoding" error
From: Steve Longerbeam
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- only return "Unsupported YCbCr encoding" error if inf != outf,
From: Steve Longerbeam
The IC now supports BT.709 Y'CbCr encoding, in addition to existing BT.601
encoding, so allow both, for pipelines that route through the IC.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- move ic_route check above default colorimetry checks,
From: Steve Longerbeam
The ycbcr2rgb and inverse rgb2ycbcr matrices define the BT.601 encoding
coefficients, so rename them to indicate that. And add some comments
to make clear these are BT.601 coefficients encoding between YUV limited
range and RGB full range. The ic_csc_rgb2rgb matrix is just
On 2/8/19 8:24 AM, Tim Harvey wrote:
On Sun, Feb 3, 2019 at 11:48 AM Steve Longerbeam wrote:
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
driv
On Thu, Feb 07, 2019 at 03:26:47PM -0700, Jason Gunthorpe wrote:
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index 31786b200afc47..e84f6aaee778f0 100644
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -311,7 +311,13 @@ static d
On Sun, Feb 3, 2019 at 11:48 AM Steve Longerbeam wrote:
>
> Pass v4l2 encoding enum to the ipu_ic task init functions, and add
> support for the BT.709 encoding and inverse encoding matrices.
>
> Reported-by: Tim Harvey
> Signed-off-by: Steve Longerbeam
> ---
> drivers/gpu/ipu-v3/ipu-ic.c
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct v
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct v
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct v
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct v
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct v
This commit changes the return type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
whi
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct v
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct v
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct v
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct v
As the subject says, we want to fix the return type
of these mem2mem buffer helpers. They are currently returning
a void pointer, which prevents type checking.
The patchset turned out to be much bigger than I was expecting,
so it's splitted in per-driver patches.
It'd be awesome if driver maintai
On Thu, Feb 07, 2019 at 10:44:10AM +0100, Neil Armstrong wrote:
> Hi,
>
> On 14/01/2019 17:36, Ayan Halder wrote:
> > On Thu, Jan 10, 2019 at 03:57:09AM +0800, Randy Li wrote:
> >> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
> >> channel video format.
> >>
> >> P012 is a plan
As long as I have these two sensors, I can review and test the patches.
Cc: Marco Felsch
Cc: Sakari Ailus
Cc: Mauro Carvalho Chehab
Signed-off-by: Akinobu Mita
---
MAINTAINERS | 18 ++
1 file changed, 18 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8c68de3c..ca9
VIDEO_V4L2_SUBDEV_API depends on MEDIA_CONTROLLER, so depending on both
two is redundant.
Cc: Sakari Ailus
Cc: Mauro Carvalho Chehab
Signed-off-by: Akinobu Mita
---
drivers/media/i2c/Kconfig | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/media/i2c/Kconfi
The camera sensor drivers should depend on MEDIA_CAMERA_SUPPORT so that
we don't see unnecessary menu options.
Cc: Sakari Ailus
Cc: Mauro Carvalho Chehab
Signed-off-by: Akinobu Mita
---
drivers/media/i2c/Kconfig| 4
drivers/media/i2c/et8ek8/Kconfig | 1 +
2 files changed, 5 insert
This driver currently supports MC and V4L2 sub-device uAPI, so add
related dependency and remove unneeded ifdefs.
Just adding VIDEO_V4L2_SUBDEV_API dependency is enough, because
VIDEO_V4L2_SUBDEV_API depends on MEDIA_CONTROLLER.
Cc: Sakari Ailus
Cc: Mauro Carvalho Chehab
Signed-off-by: Akinobu
This patch series improves Kconfig dependencies for some camera sensor
drivers.
Akinobu Mita (4):
media: ov2640: add VIDEO_V4L2_SUBDEV_API dependency
media: mt9m111: add VIDEO_V4L2_SUBDEV_API dependency
media: i2c: add missing MEDIA_CAMERA_SUPPORT
media: i2c: remove redundant MEDIA_CONTROL
This driver currently supports MC and V4L2 sub-device uAPI, so add
related dependency and remove unneeded ifdefs.
Just adding VIDEO_V4L2_SUBDEV_API dependency is enough, because
VIDEO_V4L2_SUBDEV_API depends on MEDIA_CONTROLLER.
Suggested-by: Marco Felsch
Cc: Enrico Scholz
Cc: Michael Grzeschik
Hi Mauro,
This set moves the SoC camera framework to staging and makes it depend on
BROKEN, as previously agreed.
Please pull.
The following changes since commit 6fd369dd1cb65a032f1ab9227033ecb7b759656d:
media: vimc: fill in bus_info in media_device_info (2019-02-07 12:38:59 -0500)
are avai
Hi Mauro,
Here's the next set of ov5640 and imgu driver patches.
Please pull.
The following changes since commit 6fd369dd1cb65a032f1ab9227033ecb7b759656d:
media: vimc: fill in bus_info in media_device_info (2019-02-07 12:38:59 -0500)
are available in the git repository at:
ssh://linuxtv.
/linux/commits/Vivek-Kasireddy/Add-support-for-32-bit-packed-YUV-formats/20190208-173506
base: git://linuxtv.org/media_tree.git master
config: nds32-allmodconfig (attached as .config)
compiler: nds32le-linux-gcc (GCC) 6.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests
Hi Hans,
On Fri, Feb 08, 2019 at 10:08:22AM +0100, Hans Verkuil wrote:
> On 2/8/19 10:06 AM, Sakari Ailus wrote:
> > On Fri, Feb 08, 2019 at 09:49:23AM +0100, Hans Verkuil wrote:
> >> The sd argument of this macro can be a more complex expression. Since it
> >> is used 5 times in the macro it can
Hi Vivek,
On Thu, 2019-02-07 at 19:18 -0800, Vivek Kasireddy wrote:
> Buffers generated with YUV32 format seems to be incorrect, hence use
> VUYA32 instead.
>
> Cc: Philipp Zabel
> Signed-off-by: Vivek Kasireddy
> ---
> drivers/media/platform/imx-pxp.c | 8
> 1 file changed, 4 inserti
/linux/commits/Vivek-Kasireddy/Add-support-for-32-bit-packed-YUV-formats/20190208-173506
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x017-201905 (attached as .config)
compiler: gcc-8 (Debian 8.2.0-15) 8.2.0
reproduce:
# save the attached .config to linux build tree
The following changes since commit 6fd369dd1cb65a032f1ab9227033ecb7b759656d:
media: vimc: fill in bus_info in media_device_info (2019-02-07 12:38:59 -0500)
are available in the Git repository at:
git://linuxtv.org/hverkuil/media_tree.git tags/br-v5.1n
for you to fetch changes up to 72a98aae
On 1/30/19 10:11 AM, Fish Lin wrote:
> Add following V4L2 QP parameters for H.264:
> * V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP
> * V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP
> * V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MIN_QP
> * V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP
>
> These controls will limit QP ra
On Fri, 2019-02-08 at 10:15 +0100, Hans Verkuil wrote:
> On 2/8/19 4:18 AM, Vivek Kasireddy wrote:
> > Buffers generated with YUV32 format seems to be incorrect, hence use
> > VUYA32 instead.
> >
> > Cc: Philipp Zabel
> > Signed-off-by: Vivek Kasireddy
>
> Philipp, I wonder whether VUYA32 or VU
On Thu, 2019-02-07 at 19:18 -0800, Vivek Kasireddy wrote:
> Buffers generated with YUV32 format seems to be incorrect, hence use
> VUYA32 instead.
>
> Cc: Philipp Zabel
> Signed-off-by: Vivek Kasireddy
Thanks!
Acked-by: Philipp Zabel
regards
Philipp
On 2/8/19 4:18 AM, Vivek Kasireddy wrote:
> Buffers generated with YUV32 format seems to be incorrect, hence use
> VUYA32 instead.
>
> Cc: Philipp Zabel
> Signed-off-by: Vivek Kasireddy
Philipp, I wonder whether VUYA32 or VUYX32 should be used? I think the alpha
channel is completely ignored on
On 2/8/19 10:06 AM, Sakari Ailus wrote:
> On Fri, Feb 08, 2019 at 09:49:23AM +0100, Hans Verkuil wrote:
>> The sd argument of this macro can be a more complex expression. Since it
>> is used 5 times in the macro it can be evaluated that many times as well.
>>
>> So assign it to a temp variable in t
On Fri, Feb 08, 2019 at 09:49:23AM +0100, Hans Verkuil wrote:
> The sd argument of this macro can be a more complex expression. Since it
> is used 5 times in the macro it can be evaluated that many times as well.
>
> So assign it to a temp variable in the beginning and use that instead.
>
> This
On 2/8/19 9:41 AM, Sakari Ailus wrote:
> Hi all,
>
> This series moves the SoC camera framework and the remaining drivers under
> the staging tree and makes them depend on BROKEN.
>
> The files could be later removed.
For this series:
Acked-by: Hans Verkuil
Thanks!
Hans
>
> Sakari
The sd argument of this macro can be a more complex expression. Since it
is used 5 times in the macro it can be evaluated that many times as well.
So assign it to a temp variable in the beginning and use that instead.
This also avoids any potential side-effects of evaluating sd.
Signed-off-by: H
On Fri, Feb 08, 2019 at 10:41:43AM +0200, Sakari Ailus wrote:
> Hi all,
>
> This series moves the SoC camera framework and the remaining drivers under
> the staging tree and makes them depend on BROKEN.
>
> The files could be later removed.
>
> Sakari Ailus (4):
> soc_camera: Move to the stagi
This patch makes the SoC camera framework as well as effectively the few
remaining sensor drivers depend on BROKEN, rendering it uncompileable
without changes in Kconfig.
The purpose is to leave the code around if someone wishes to convert the
drivers to the modern day V4L2 sub-device framework wi
Move the mt9t031 driver to the soc_camera directory in the media staging
tree.
Signed-off-by: Sakari Ailus
---
drivers/staging/media/Kconfig | 2 --
drivers/staging/media/Makefile | 1 -
drivers/staging/media/soc_camera/Kconfig|
The SoC camera framework has no functional drivers left, something that
has not changed for years. Move the leftovers to the staging tree.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/Kconfig | 8
drivers/media/i2c/Makefile
Hi all,
This series moves the SoC camera framework and the remaining drivers under
the staging tree and makes them depend on BROKEN.
The files could be later removed.
Sakari Ailus (4):
soc_camera: Move to the staging tree
soc_camera: Move the imx074 under soc_camera directory
soc_camera: M
Move the imx074 driver to the soc_camera directory in the media staging
tree.
Signed-off-by: Sakari Ailus
---
drivers/staging/media/Kconfig | 2 --
drivers/staging/media/Makefile| 1 -
drivers/staging/media/imx074/Kconfig | 5 -
70 matches
Mail list logo
