Hi Yong,
On Mon, Jan 14, 2019 at 09:37:44PM -0600, Yong Zhi wrote:
> This addresses the below TODO item.
> - Use V4L2_CTRL_TYPE_MENU for dual-pipe mode control. (Sakari)
>
> Signed-off-by: Yong Zhi
> ---
> drivers/staging/media/ipu3/TODO | 2 --
> drivers/staging/media/ipu3/inc
Hi Yong,
On Tue, Jan 15, 2019 at 12:38 PM Yong Zhi wrote:
>
> Since ipu3_css_buf_dequeue() never returns NULL, remove the
> dead code to fix static checker warning:
>
> drivers/staging/media/ipu3/ipu3.c:493 imgu_isr_threaded()
> warn: 'b' is an error pointer or valid
>
> Signed-off-by: Yong Zhi
Hi Yong,
On Tue, Jan 15, 2019 at 12:38 PM Yong Zhi wrote:
>
> This addresses the below TODO item.
> - Use V4L2_CTRL_TYPE_MENU for dual-pipe mode control. (Sakari)
>
> Signed-off-by: Yong Zhi
> ---
> drivers/staging/media/ipu3/TODO | 2 --
> drivers/staging/media/ipu3/include/in
Hi Ben,
You are referring to older type of sensor i2c control. You can refer to IMX258
driver.
drivers/media/i2c/imx258.c
/* Write registers up to 2 at a time */
static int imx258_write_reg(struct imx258 *imx258, u16 reg, u32 len, u32 val)
{
struct i2c_client *client = v4l2_get_subdevd
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 Jan 15 05:00:13 CET 2019
media-tree git hash:1e0d0a5fd38192f23304ea2fc2b531fea7c74247
media_build git
This addresses the below TODO item.
- Use V4L2_CTRL_TYPE_MENU for dual-pipe mode control. (Sakari)
Signed-off-by: Yong Zhi
---
drivers/staging/media/ipu3/TODO | 2 --
drivers/staging/media/ipu3/include/intel-ipu3.h | 6 --
drivers/staging/media/ipu3/ipu3-v4l2.c | 1
Since ipu3_css_buf_dequeue() never returns NULL, remove the
dead code to fix static checker warning:
drivers/staging/media/ipu3/ipu3.c:493 imgu_isr_threaded()
warn: 'b' is an error pointer or valid
Signed-off-by: Yong Zhi
---
Link to Dan's bug report:
https://www.spinics.net/lists/linux-media/ms
Hi Ben,
On Fri, Jan 11, 2019 at 12:12 PM Ben Kao wrote:
>
> This patch adds driver for Omnivision's ov8856 sensor,
> the driver supports following features:
[snip]
> +static int ov8856_write_reg(struct ov8856 *ov8856, u16 reg, u16 len, u32
> __val)
> +{
> + struct i2c_client *client = v4l2
Thanks for getting back to me Mauro.
So it works on MacOS via a hootoo USB-C dongle
https://s.natalian.org/2019-01-15/hootoo.jpeg
So since my T480s has two USB-C ports, I tried using the same dongle on my
Thinkpad. It works!
I discovered that I can reliably get the device working by using
Hauppauge USBLive2 was reported broken. A change in media controller
logic appears to be the culprit.
Fixes: 9d6d20e652 ("v4l2-mc: switch it to use the new approach to setup
pipelines")
Without "taint" set for signal type, devices
with analog capture fail during probe:
[5.821715] cx231xx 3-
Fixes: 9d6d20e652 ("v4l2-mc: switch it to use the new approach to setup
pipelines")
Without "taint" set for signal type, devices
with analog capture fail during probe:
[5.821715] cx231xx 3-2:1.1: v4l2 driver version 0.0.3
[5.955721] cx231xx 3-2:1.1: Registered video device video0 [v4l2]
Fixes: 9d6d20e652 ("v4l2-mc: switch it to use the new approach to setup
pipelines")
Without "taint" set for signal type, devices
with analog capture fail during probe:
[5.821715] cx231xx 3-2:1.1: v4l2 driver version 0.0.3
[5.955721] cx231xx 3-2:1.1: Registered video device video0 [v4l2]
From: Steve Longerbeam
There is a block of code in rvin_group_link_notify() that prevents
enabling a link to a VIN node if any entity in the media graph is
in use. This prevents enabling a VIN link even if there is an in-use
entity somewhere in the graph that is independent of the link's
pipeline
On 1/9/19 5:19 PM, Steve Longerbeam wrote:
On 1/9/19 2:40 PM, Niklas Söderlund wrote:
Hi Steve,
Thanks for your patch, I think it looks good.
Thanks for the Ack! I'm not real familiar with the RFC patch process.
Should this be submitted again with RFC stripped from the subject line?
I
Hi JM,
On 1/14/19 1:52 AM, Jean-Michel Hautbois wrote:
Hi,
I am currently using an upstream kernel on a i.MX6 Quad board, and I
have a strange issue.
The device I am using is able to produce RGB888 MIPI data, or RAW8/RAW10.
The MIPI data types are respectively 0x24, 0x2A and 0x2B.
When I config
Add a linear pipeline logic for the stream control. It's created by
walking backwards on the entity graph. When the stream starts it will
simply loop through the pipeline calling the respective process_frame
function of each entity.
Fixes: f2fe89061d797 ("vimc: Virtual Media Controller core, captu
Without this, we get failures like this when the kernel attempts to
initialize a cx231xx device:
[16046.153653] cx231xx 3-1.2:1.1: New device Hauppauge Hauppauge Device
@ 480 Mbps (2040:c200) with 6 interfaces
[16046.153900] cx231xx 3-1.2:1.1: can't change interface 3 alt no. to
Instead of assigning the return value to ret and then checking and
returning it, just return the value to the caller directly. The success
value is always 0.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/ov7670.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/driver
On Tue, Nov 20, 2018 at 11:03:07AM +0100, Lubomir Rintel wrote:
> This will allow us to restore the last set frame rate after the device
> returns from a power off.
>
> Signed-off-by: Lubomir Rintel
>
> ---
> Changes since v2:
> - This patch was added to the series
>
> drivers/media/i2c/ov7670
On Sat, Jan 12, 2019 at 01:03:05PM -0600, Shiraz Saleem wrote:
> On Sat, Jan 12, 2019 at 06:37:58PM +, Jason Gunthorpe wrote:
> > On Sat, Jan 12, 2019 at 12:27:05PM -0600, Shiraz Saleem wrote:
> > > On Fri, Jan 04, 2019 at 10:35:43PM +, Jason Gunthorpe wrote:
> > > > Commit 2db76d7c3c6d ("l
Linux
https://goo.gl/H3yrpC
JULIAN GARDNER
Le mardi 08 janvier 2019 à 16:30 +0100, Philipp Zabel a écrit :
> > # To demonstrate (with patched gst-plugins-bad
> > https://paste.fedoraproject.org/paste/rs-CbEq7coL4XSKrnWpEDw)
> > gst-launch-1.0 videotestsrc ! video/x-raw,format=YUY2 ! v4l2convert !
> > video/x-raw,format=xRGB ! kmssink
>
>
Make changes based on Laurent's v8 review:
https://www.spinics.net/lists/linux-media/msg144408.html
Signed-off-by: Yong Zhi
---
Documentation/media/uapi/v4l/meta-formats.rst | 2 +-
.../media/uapi/v4l/pixfmt-meta-intel-ipu3.rst | 119 ++---
Documentation/media/v4l-drivers
> From: Hans Verkuil
> Sent: Tuesday, January 8, 2019 8:46 AM
> To: Ken Sloat ; eugen.hris...@microchip.com
> Cc: mche...@kernel.org; nicolas.fe...@microchip.com;
> alexandre.bell...@bootlin.com; ludovic.desroc...@microchip.com; linux-
> me...@vger.kernel.org
> Subject: Re: [PATCH v1 2/2] media: a
> From: eugen.hris...@microchip.com
> Sent: Monday, January 7, 2019 6:10 AM
> To: Ken Sloat
> Cc: mche...@kernel.org; nicolas.fe...@microchip.com;
> alexandre.bell...@bootlin.com; ludovic.desroc...@microchip.com; linux-
> me...@vger.kernel.org
> Subject: Re: [PATCH v1 1/2] media: atmel-isc: Add s
On Mon, Jan 14, 2019 at 01:12:33PM +, Robin Murphy wrote:
> Ignoring the offset was kind of intentional there, because at the time I
> was primarily thinking about it in terms of the Keystone 2 platform where
> the peripherals are all in the same place (0-2GB) in both the bus and CPU
> physi
On 1/14/19 6:04 PM, Helen Koike wrote:
> Hi Hans,
>
> Thanks for the patch.
>
> On 1/14/19 12:58 PM, Hans Verkuil wrote:
>> Add VB2_USERPTR to the vimc capture device.
>>
>> Signed-off-by: Hans Verkuil
>> ---
>> diff --git a/drivers/media/platform/vimc/vimc-capture.c
>> b/drivers/media/platform
Hi Hans,
Thanks for the patch.
On 1/14/19 12:58 PM, Hans Verkuil wrote:
> Add VB2_USERPTR to the vimc capture device.
>
> Signed-off-by: Hans Verkuil
> ---
> diff --git a/drivers/media/platform/vimc/vimc-capture.c
> b/drivers/media/platform/vimc/vimc-capture.c
> index 3f7e9ed56633..35c730f484a
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 planar 4:2:0 YUV 12 bits per channel
>
> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
> channel video format.
>
The video output sizeimage calculation did not take data_offset into account.
This can cause problems with video loopback or exporting output buffers for
use as dmabuf import buffers since the output buffer size is now too small.
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/platfor
Having of_reserved_mem_device_init() forcibly reconfigure DMA for all
callers, potentially overriding the work done by a bus-specific
.dma_configure method earlier, is at best a bad idea and at worst
actively harmful. If drivers really need virtual devices to own
dma-coherent memory, they should ex
Add VB2_USERPTR to the vimc capture device.
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/platform/vimc/vimc-capture.c
b/drivers/media/platform/vimc/vimc-capture.c
index 3f7e9ed56633..35c730f484a7 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/v
Hi Jacopo,
Thanks for your patch.
On 2019-01-10 15:02:10 +0100, Jacopo Mondi wrote:
> The ADV748x chip supports routing AFE output to either TXA or TXB.
> In order to support run-time configuration of video stream path, create an
> additional (not enabled) "AFE:8->TXA:0" link, and remove the IMMU
Hi Jacopo,
Thanks for your work.
On 2019-01-10 15:02:09 +0100, Jacopo Mondi wrote:
> Rename the chip reset procedure as they configure the CP (HDMI) and SD
> (AFE) cores.
>
> Reviewed-by: Kieran Bingham
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
Reviewed-by: Niklas Söderlu
Hi Jacopo,
Thanks for your patch.
On 2019-01-10 15:02:08 +0100, Jacopo Mondi wrote:
> Add small is_txb() macro to the existing is_txa() and use it where
> appropriate.
>
> Reviewed-by: Kieran Bingham
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
Reviewed-by: Niklas Söderlund
Hi Kieran,
Thanks for your patch.
On 2019-01-11 17:41:41 +, Kieran Bingham wrote:
> The ADV748X_PAGE_WAIT is a fake page to insert arbitrary delays in the
> register tables.
>
> Its only usage was removed, so we can remove the handling and simplify
> the code.
>
> Signed-off-by: Kieran Bing
Hi Kieran,
Thanks for your work.
On 2019-01-11 17:41:40 +, Kieran Bingham wrote:
> The ADV748x is currently reset by writting a small table of registers to
> the device.
>
> The table lacks documentation and contains magic values to perform the
> actions, including using a fake register addr
Hi Ben,
Thanks for the update. A few trivial things below, and then I guess we're
done.
On Fri, Jan 11, 2019 at 11:15:16AM +0800, Ben Kao wrote:
> This patch adds driver for Omnivision's ov8856 sensor,
> the driver supports following features:
>
> - manual exposure/gain(analog and digital) contr
Hi Jacopo,
for this series:
Tested-by: Kieran Bingham
For anyone else who wants to use this series, please remember that if
you reset links on the media controller you will now have to set up the
links between the HDMI/AFE and TXA/TXB with this series in place.
The driver will default to the c
On 11/01/2019 18:17, Christoph Hellwig wrote:
Use WARN_ON_ONCE to print a stack trace and return a proper error
code instead.
I was racking my brain to remember the reasoning behind BUG_ON() being
the only viable way to prevent errors getting through unhandled, but of
course that was before w
Add support for META_OUTPUT buffer type to v4l2-ctl.
Signed-off-by: Sakari Ailus
---
utils/v4l2-ctl/Makefile.am | 3 +-
utils/v4l2-ctl/v4l2-ctl-common.cpp | 3 +-
utils/v4l2-ctl/v4l2-ctl-meta-out.cpp | 106 +++
utils/v4l2-ctl/v4l2-ctl-meta.cpp
It appears that the required libraries may depend on whether linking is
done statically or dynamically. The pkg-config thus needs to know. Update
the instructions accordingly.
Signed-off-by: Sakari Ailus
---
INSTALL | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/INST
Printing metadata formats was supported separately with
--list-formats-meta but no meta formats were printed with --all option.
Fix this.
Fixes: b3f1cf6b8519 ("v4l2-compliance/v4l2-ctl: support
V4L2_CTRL_FLAG_MODIFY_LAYOUT and metadata")
Signed-off-by: Sakari Ailus
---
utils/v4l2-ctl/v4l2-ctl.
Just import changes brought by patch "v4l: uAPI: V4L2_BUF_TYPE_META_OUTPUT
is an output buffer type". This is needed by further metadata output
patches.
Signed-off-by: Sakari Ailus
---
include/linux/videodev2.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/v
Hi folks,
This set adds metadata output buffer type support for v4l2-ctl. There are
a few more things done by the set, too:
- fixed static build instructions,
- fixed --all argument handling for metadata capture formats and
- include changes to videodev2.h brought by kernel patch I recently sen
V4L2_BUF_TYPE_META_OUTPUT was added by patch 72148d1a57e7 but the patch
missed adding the type to the macro telling whether a given type is an
output type or not. Do that now. Getting this wrong leads to handling the
buffer as a capture buffer in a lot of places.
Fixes: 72148d1a57e7 ("media: v4l:
It makes no sense to support the USERPTR memory model if the vivid instance was
configured as dma_contig. Disable it if this is the case.
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/platform/vivid/vivid-core.c
b/drivers/media/platform/vivid/vivid-core.c
index 7da5720b47a2..29e7b14
This is a first attempt at implementing proper access to buffers
imported with dma-buf and used as reference frames for decoding
subsequent frames.
The main concern associated with this scenario was that memory could be
liberated while the buffer is not in a queued state. After careful
checking, i
Access to reference frames that were imported from dma-buf was taken
care of and is no longer a pending item on the driver's TODO list.
Signed-off-by: Paul Kocialkowski
---
drivers/staging/media/sunxi/cedrus/TODO | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/media/sunxi
Because we need to request and release access to reference buffers
that are backed by a dma-buf import, keep track of the buffers used
as reference and add the appropriate calls in the device_run and
job_done m2m callbacks. The latter is introduced for this purpose.
Signed-off-by: Paul Kocialkowsk
Introduce a new optional job_done operation, which allows calling back
to the driver when a job is done. Since the job might be completed
from interrupt context where some operations are not available, having
a callback from non-atomic context allows performing these operations
upon completion of a
Introduce helpers to request and release access to buffers that are
not currently selected as current output or capture buffers.
This is useful to ensure proper access to buffers imported via dma-buf
that are used as reference and thus require associated map/unmap calls
before access.
Signed-off-
Hi Niklas,
On 14/01/2019 13:06, Niklas Söderlund wrote:
> Hi Kieran,
>
> Thanks for your work.
>
> On 2019-01-11 16:17:03 +, Kieran Bingham wrote:
>> From: Steve Longerbeam
>>
>> Switch to devm_kzalloc() when allocating the adv748x device struct.
>>
>> The sizeof() is updated to determine t
On 11/01/2019 18:17, Christoph Hellwig wrote:
Just returning the physical address when not map_resource method is
present is highly dangerous as it doesn't take any offset in the
direct mapping into account and does the completely wrong thing for
IOMMUs. Instead provide a proper implementation i
Hi Kieran,
Thanks for your work.
On 2019-01-11 16:17:03 +, Kieran Bingham wrote:
> From: Steve Longerbeam
>
> Switch to devm_kzalloc() when allocating the adv748x device struct.
>
> The sizeof() is updated to determine the correct allocation size from
> the dereferenced pointer type rather
Hi Hans
On 1/11/19 1:25 PM, Hans Verkuil wrote:
> Hi Helen,
>
> I've started work to fix the last compliance failures with vimc so that
> vimc can be used in regression tests.
>
> But I found a kernel warning and a kernel oops using vimc from our master
> tree.
>
> To test, load vimc, then run
Em Mon, 14 Jan 2019 05:26:42 -0700
James Hilliard escreveu:
> On Mon, Jan 14, 2019 at 4:00 AM Mauro Carvalho Chehab
> wrote:
> >
> > Hi James,
> >
> > Em Mon, 14 Jan 2019 07:38:25 +0800
> > james.hillia...@gmail.com escreveu:
> >
> > > From: Thomas Petazzoni
> > >
> >
> > Please add descrip
Hi Christoph,
On 2019-01-11 19:17, Christoph Hellwig wrote:
> vb2_dc_get_userptr pokes into arm direct mapping details to get the
> resemblance of a dma address for a a physical address that does is
> not backed by a page struct. Not only is this not portable to other
> architectures with dma dir
The driver name as returned in v4l2_capabilities must be vimc, not vimc_capture.
Fix this.
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/platform/vimc/vimc-capture.c
b/drivers/media/platform/vimc/vimc-capture.c
index 3f7e9ed56633..aaeddf24b042 100644
--- a/drivers/media/platform/vi
On Mon, Jan 14, 2019 at 4:00 AM Mauro Carvalho Chehab
wrote:
>
> Hi James,
>
> Em Mon, 14 Jan 2019 07:38:25 +0800
> james.hillia...@gmail.com escreveu:
>
> > From: Thomas Petazzoni
> >
>
> Please add description to the patches. It helps reviewing them, and,
> if we need to revert it for whatever
Hi Christoph,
On 2019-01-11 19:17, Christoph Hellwig wrote:
> Hi all,
>
> this series fixes a rather gross layering violation in videobuf2, which
> pokes into arm DMA mapping internals to get a DMA address for memory that
> does not have a page structure, and to do so fixes up the dma_map_resource
Em Mon, 14 Jan 2019 13:10:25 +0800
Kai Hendry escreveu:
> Archlinux user here. It doesn't matter whether I'm running LTS kernel
> 4.19.14-1-lts or 4.20.1.arch1-1, I get these very annoying USB issues with my
> Magewell XI100DUSB-HDMI. Most of the time it doesn't work. I seemingly have
> better
On Mon, Jan 14, 2019 at 09:04:56AM -0200, Mauro Carvalho Chehab wrote:
> It would be good if you could later send us a stable branch where
> you merged, in order to allow us to run some tests with the new
> DMA mapping patchset and be sure that it won't cause regressions
> to videobuf2.
I can do t
Em Mon, 14 Jan 2019 11:31:39 +0100
Christoph Hellwig escreveu:
> On Fri, Jan 11, 2019 at 05:54:16PM -0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 11 Jan 2019 19:17:31 +0100
> > Christoph Hellwig escreveu:
> >
> > > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > > re
Hi James,
Em Mon, 14 Jan 2019 07:38:25 +0800
james.hillia...@gmail.com escreveu:
> From: Thomas Petazzoni
>
Please add description to the patches. It helps reviewing them, and,
if we need to revert it for whatever reason in the future, the git log
will help to take into account the rationale a
On Fri, Jan 11, 2019 at 05:54:16PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 11 Jan 2019 19:17:31 +0100
> Christoph Hellwig escreveu:
>
> > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > resemblance of a dma address for a a physical address that does is
> > not backed
Hi,
I am currently using an upstream kernel on a i.MX6 Quad board, and I
have a strange issue.
The device I am using is able to produce RGB888 MIPI data, or RAW8/RAW10.
The MIPI data types are respectively 0x24, 0x2A and 0x2B.
When I configure the device to produce RGB888 data, everything is
fine,
Hi Sakari,
Thanks for reviewing my patch.
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sakari Ailus
> Sent: Wednesday, January 09, 2019 5:22 PM
> To: Vishal Sagar
> Cc: Hyun Kwon ; laurent.pinch...@ideasonboard.
On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
> > Changes since the RFC:
> > - Rework vmwgfx too [CH]
> > - Use a distinct type for the DMA page iterator [CH]
> > - Do not have a #ifdef [CH]
>
> ChristophH: Will you ack?
This looks generally fine.
>
> Are you still OK with th
Hi Sakari,
Thanks for reviewing this.
> -Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@linux.intel.com]
> Sent: Tuesday, January 08, 2019 6:35 PM
> To: Vishal Sagar
> Cc: Hyun Kwon ; laurent.pinch...@ideasonboard.com;
> Michal Simek ; linux-media@vger.kernel.org;
> devicet
On Sat, Jan 12, 2019 at 01:03:05PM -0600, Shiraz Saleem wrote:
> Well I was trying convert the RDMA drivers to use your new iterator variant
> and saw the need for it in locations where we need virtual address of the
> pages
> contained in the SGEs.
As far as i can tell that pg_arr[i] value is on
On 1/14/19 10:23 AM, Oleksandr Andrushchenko wrote:
> Hello, Hans!
> Could you please take a look at my answers below and kindly let me know
> if we are ready for (final?) v4 from your point of view.
Looks good, so I'm looking forward to a v4.
Regards,
Hans
>
> Konrad, Xen-devel - do y
Hello, Hans!
Could you please take a look at my answers below and kindly let me know
if we are ready for (final?) v4 from your point of view.
Konrad, Xen-devel - do you have any objections/comments on this?
Thank you,
Oleksandr
On 12/17/18 9:37 AM, Oleksandr Andrushchenko wrote:
Hello, Hans!
74 matches
Mail list logo
