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 26 05:00:11 CEST 2019
media-tree git hash:7afa8db323e37b9174cf78a1c9ab0ae7a9f5e7dd
media_build gi
Switch to sync registration for the IPU internal sub-devices, re-organize
modules, and a few other miscellaneous cleanups.
Steve Longerbeam (6):
media: staging/imx: Switch to sync registration for IPU subdevs
media: staging/imx: Pass device to alloc/free_dma_buf
media: staging/imx: Move add_
If the driver is in multiplanar mode, fill the vb2 structures
with the planes sizes and verify it the sizes allocated to the
planes are enough.
Signed-off-by: André Almeida
Acked-by: Helen Koike
---
Change in v4: none
Change in v3: none
Change in v2:
- Use IS_MULTIPLANAR macro
drivers/media/
Change the scaling functions in order to scale planes. This change makes
easier to support multiplanar pixel formats.
Signed-off-by: André Almeida
---
Changes in v4:
- Rename `frame_size` to `plane_size`
- Correct `unsigned int ret` to `int ret`
- Remove label `free_planes` from else scope
- Chan
This commit adapts vimc-sensor to handle multiplanar pixel formats,
adapting the memory allocation and TPG configuration.
Signed-off-by: André Almeida
---
Changes in v4:
- Correct `unsigned int ret` to `int ret`
- Remove label `free_planes` from else scope
Changes in v3:
- Adapt to new vimc_fram
Adapt vimc-capture to support multiplanar formats, copying
each plane to the correct buffer.
Signed-off-by: André Almeida
---
Change in v4:
- Move variables to inside the for loop
- Change `plane_size` type from `unsigned int` to `size_t`
Change in v3:
- Adapt to new vimc_frame
Change in v2: no
Create multiplanar kernel module parameter to define if the driver is
running in single planar or in multiplanar mode. Define the device
capabilities according to the multiplanar kernel parameter. A device can't
support both CAP_VIDEO_CAPTURE and CAP_VIDEO_CAPTURE_MPLANAR at the
same time.
Signed-
Struct vimc_frame is intended to hold metadata about a frame,
such as memory address of a plane, number of planes and size
of each plane, to better integrated with the multiplanar operations.
The struct can be also used with singleplanar formats, making the
implementation of frame manipulation gene
vimc_cap_device.format field was defined as v4l2_pix_format,
a struct to handle single planar pixel formats. It turns out that
if v4l2_format is used, we can reuse functions for both
v4l2_pix_format and v4l2_pix_format_mplane. This change will
help at future commits implementing multiplanar pixel
f
Add multiplanar formats to be exposed to the userspace as
supported formats. Since we don't want to support multiplanar
formats when the driver is in singleplanar mode, we only access
the multiplanar formats array if the multiplanar mode is enabled.
Signed-off-by: André Almeida
Acked-by: Helen Ko
vimc already have a default single planar format.
Add a multiplanar default pixel format to perform those
same actions. Change where the default pixelformat is set to make sure
that the vcap is with the right capabilities.
Signed-off-by: André Almeida
---
Change in v4: none
Changes in v3:
- Fix
Change the way subdevices check if the stream is running. Verify the stream
pointer instead of src_frame. This makes easier to get rid of the void* and
u8* in the subdevices structs. Also, remove redundant checks for stream.
Signed-off-by: André Almeida
Acked-by: Helen Koike
---
Changes in v4:
-
Define the pixelformat of the streamer depending to the
mode (single/multiplanar). Add a macro to help checking if the device is
in multilplanar mode.
Signed-off-by: André Almeida
Acked-by: Helen Koike
---
Change in v4: none
Change in v3:
- Replace if with triaste operator
Change in v2:
- Add
Move sp2mp functions from vivid code to v4l2-common as it will be reused
by vimc driver for multiplanar support.
Signed-off-by: André Almeida
---
Changes in v4: none
Changes in v3:
- Change commit order
- Reword comments
Changes in v2:
- Fix indentation
- Change the style of comments. Functions
Add functions to handle multiplanar format ioctls, calling
the generic format ioctls functions when possible.
Signed-off-by: André Almeida
---
Change in v4:
- Split from multiplanar parameter commit
- Use `IS_MULTIPLANAR` instead of `multiplanar`
- Move "Functions to handle..." to commit 5
Chang
Since multiplanar is a superset of single planar formats, instead of
having different implementations for them, treat all formats as
multiplanar. If we need to work with single planar formats, convert them to
multiplanar (with num_planes = 1), re-use the multiplanar code, and
transform them back to
Hello,
This series implements support for multiplane pixel formats at Vimc.
A lot of changes were required since vimc support for singleplane
was "hardcoded". The code has been adapted in order to support both
formats. When was possible, the functions were written generically,
avoiding functions f
Hi Mauro,
Sorry for the inconvenience, here is the third attempt.
Added two more fixes for Venus v4 properties and dynamic buffer mode.
Please pull.
The following changes since commit 7afa8db323e37b9174cf78a1c9ab0ae7a9f5e7dd:
media: vsp1: Add support for missing 16-bit RGB555 formats (2019-0
On Fri, 2019-04-12 at 17:51 +0200, Philipp Zabel wrote:
> v4l2-compliance likes to queue a buffer with field set to V4L2_FIELD_ANY
> and expects it to be returned corrected to a valid field.
>
> Follow vicodec in handling this in the buf_prepare callback.
>
> Signed-off-by: Philipp Zabel
> ---
>
On 4/25/19 8:35 PM, Ezequiel Garcia wrote:
> This is just a cosmetic change to print a more descriptive
> message, to distinguish decoder from encoder:
>
> So, instead of printing
>
> coda 204.vpu: codec registered as /dev/video[4-5]
>
> With this change, the driver now prints
>
> coda
There isn't any reason to run the mem2mem job on a separate worker,
because the mem2mem framework guarantees that device_run will never
run in interrupt context.
Therefore, get rid of the extra pic_run_work worker, and instead
run the job in the context of .device_run itself.
Signed-off-by: Ezequ
This commit clears the interrupt reason (INT_REASON) register
on the interrupt handler. Without this clearing, the CODA hardware
has been observed to get completely stalled on CODA980 variants,
requiring a pretty deep hardware reset.
The datasheet specifies that the INT_REASON register is set
by t
The mutex unlock in the threaded interrupt handler is not paired
with any mutex lock. Remove it.
This bug has been here for a really long time, so it applies
to any stable repo.
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/coda/coda-bit.c | 1 -
1 file changed, 1 deletion(-)
diff
While working on a SoC with CODA980 (currently not supported by the
driver), I came across some low-hanging fruit that looked worth
addressing.
Patch 1 is just a cosmetic change to print a different "more standard"
device registered message, if such thing exists.
Patches 2 to 4 address unneeded u
This is just a cosmetic change to print a more descriptive
message, to distinguish decoder from encoder:
So, instead of printing
coda 204.vpu: codec registered as /dev/video[4-5]
With this change, the driver now prints
coda 204.vpu: encoder registered as /dev/video4
coda 204.v
The current interrupt handler is doing very little, and not doing
any non-atomic operations. Pretty much all it does is accessing
a couple registers, taking a couple spinlocks and then signalling
a completion.
There is no reason this should be a threaded interrupt handler,
so move the handler to r
On 4/24/19 8:19 PM, Helen Koike wrote:
>
> On 4/24/19 8:03 PM, André Almeida wrote:
>> Hello Helen,
>>
>> Thanks for your review!
>>
>> On 4/24/19 6:32 PM, Helen Koike wrote:
>>> Hi André,
>>>
>>> Thanks for the patch, please see my comments below.
>>>
>>> On 4/24/19 10:56 AM, André Almeida wrote
Em Thu, 25 Apr 2019 11:46:18 -0300
Mauro Carvalho Chehab escreveu:
> Em Tue, 23 Apr 2019 17:07:02 +0300
> Stanimir Varbanov escreveu:
>
> > Hi Mauro,
> >
> > Here is the second attempt.
> >
> > Added two more fixes for Venus v4 properties and dynamic buffer mode.
> >
> > Please pull.
> >
>
Em Tue, 23 Apr 2019 17:07:02 +0300
Stanimir Varbanov escreveu:
> Hi Mauro,
>
> Here is the second attempt.
>
> Added two more fixes for Venus v4 properties and dynamic buffer mode.
>
> Please pull.
>
> The following changes since commit 26d5d1fe53e966efe567e9773d1158baef303e3b:
>
> venus:
This pull request contains patches 1-10 of the "[PATCH v4 00/21] Add MPEG-2
decoding to Rockchip VPU" series.
These are all fixes and are independent of the mpeg-2 support.
Regards,
Hans
The following changes since commit a4dfc8a24796ff312d1d307e11f26f8ca466e938:
media: MAINTAINERS:
Em Tue, 9 Apr 2019 12:38:34 +
Руслан Ижбулатов escreveu:
> Here's a few patches that might be useful.
>
> Руслан Ижбулатов (8):
> Include windows.h for vfw
> Specify correct path to barcode.png
> Check for clock_gettime on pthread library as well
> Disable zbarcam-gtk on Win
Good Day
I am Mr.Umor Salif, a regional managing director (CORIS BANK
INTERNATIONAL) Ouagadougou Burkina Faso, in my department we have
US$9,500. million united state dollars, to transfer into your
account as a dormant fund.If you are interested to use this fund to
help the orphans around the
Sehr geehrte Damen und Herren,
nach unserem Besuch Ihrer Homepage möchten wir Ihnen ein Angebot von Produkten
vorstellen, das Ihnen ermöglichen wird, den Verkauf Ihrer Produkte sowie
Dienstleistungen deutlich zu erhöhen.
Die Datenbanken der Firmen sind in für Sie interessante und relevante
Zie
On 4/25/19 11:36 AM, Boris Brezillon wrote:
> On Thu, 25 Apr 2019 10:21:16 +0200
> Hans Verkuil wrote:
>
>> On 4/25/19 10:06 AM, Boris Brezillon wrote:
>>> On Thu, 25 Apr 2019 09:12:21 +0200
>>> Boris Brezillon wrote:
>>>
This series introduces the decoding infrastructure that will be
>>
On Thu, 25 Apr 2019 10:21:16 +0200
Hans Verkuil wrote:
> On 4/25/19 10:06 AM, Boris Brezillon wrote:
> > On Thu, 25 Apr 2019 09:12:21 +0200
> > Boris Brezillon wrote:
> >
> >> This series introduces the decoding infrastructure that will be
> >> used to add support for other codecs such as VP8
Compile tested this series and I get the following sparse/smatch wanings:
sparse: WARNINGS
SPARSE:/home/hans/work/build/media-git/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
/home/hans/work/build/media-git/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:38:6:
warning: symbol 'ro
On 4/25/19 10:06 AM, Boris Brezillon wrote:
> On Thu, 25 Apr 2019 09:12:21 +0200
> Boris Brezillon wrote:
>
>> This series introduces the decoding infrastructure that will be
>> used to add support for other codecs such as VP8, VP9 and H.264.
>>
>> As explained in the cover letter for the v1 patc
On Thu, 25 Apr 2019 10:06:28 +0200
Boris Brezillon wrote:
> On Thu, 25 Apr 2019 09:12:21 +0200
> Boris Brezillon wrote:
>
> > This series introduces the decoding infrastructure that will be
> > used to add support for other codecs such as VP8, VP9 and H.264.
> >
> > As explained in the cover l
The following changes since commit a4dfc8a24796ff312d1d307e11f26f8ca466e938:
media: MAINTAINERS: Update AO CEC with ao-cec-g12a driver (2019-04-22
13:16:35 -0400)
are available in the Git repository at:
git://linuxtv.org/hverkuil/media_tree.git tags/br-v5.2h
for you to fetch changes up to
On Thu, 25 Apr 2019 09:12:21 +0200
Boris Brezillon wrote:
> This series introduces the decoding infrastructure that will be
> used to add support for other codecs such as VP8, VP9 and H.264.
>
> As explained in the cover letter for the v1 patchset,
> the driver is now exposing two video device n
From: Jonas Karlman
Add necessary bits to support MPEG2 decoding on RK3288.
Signed-off-by: Jonas Karlman
Signed-off-by: Boris Brezillon
---
Changes from v3:
* Coding style improvements (Jonas)
* Use ALIGN() instead of div+shift (Jonas)
Changes from v2:
* New patch
---
drivers/staging/media/r
When initializing a context, the core wants to reset both src and dst
formats. Right now the order doesn't matter, but if we want to have a
valid default width/height on the non-coded/raw format side (src in
case of encoders, dst in case of decoders), we need to reset those
formats in the right ord
The code in rockchip_vpu_v4l2 was hardcoded for encoder support.
Modify it more generic to support the decoder case so that we can
re-use the same vb2/v4l2 ops for both devices.
Co-developed-by: Ezequiel Garcia
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
---
Changes from v3:
*
This makes the function more generic so it can easily be re-used when
adding support for the decoding functionality.
Signed-off-by: Boris Brezillon
---
Changes from v3:
* New patch
---
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Ezequiel Garcia
In preparation to support decoders, using a single memory-to-memory
device, we need to roll our own media controller entities registration.
To do that, we define a rockchip_vpu_func object that embeds the
video_device object plus all the elements that are needed to attach t
From: Ezequiel Garcia
Introduce support for the Request API. Although the JPEG encoder
does not mandate using the Request API, it's perfectly possible to
use it, if the application wants to.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
--
Changes from v3:
* None
Changes from
v4l2-compliance complains that ->bus_info is empty.
Signed-off-by: Boris Brezillon
---
Changes from v3:
* New patch
---
drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
b/drivers/sta
The V4L2/VB2 implementation for the encoder and decoder logic are very
similar, so let's rename rockchip_vpu_enc.c file into
rockchip_vpu_v4l2.c and remove the _enc_ part in objects/functions
exposed in rockchip_vpu_v4l2.h. We also rename the enc_queue_init()
function (in rockchip_vpu_drv.c) queue_
We're about to add prototypes for the vb2/v4l2 helpers shared by the
encoder/decoder logic in this file, so let's pick a name that reflects
that (rockchip_vpu_common.h was a bit to generic).
Suggested-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
---
Changes from v3:
* None
Changes from v2
From: Jonas Karlman
Add the necessary bits to support MPEG2 decoding on RK3399.
Signed-off-by: Jonas Karlman
Signed-off-by: Boris Brezillon
---
Changes from v3:
* New patch (was part of another patch before)
---
drivers/staging/media/rockchip/vpu/Makefile | 1 +
.../media/rockchip/vpu/rk3
From: Jonas Karlman
Only adds structs and helpers to allow supporting MPEG-2 decoding on
rockchip SoCs. Support for RK3399 and RK3288 will be added in separate
commits
Signed-off-by: Jonas Karlman
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
--
Changes from v3:
* Coding style
From: Jonas Karlman
Pass -1 to video_register_device() to let the core assign the first
free id instead of trying to get id 0.
In practice it doesn't make a difference since video_register_device()
is not strict about id requests and will anyway pick the first free id
starting at the id passed in
From: Ezequiel Garcia
This commit adds the needed boilerplate code to support the VPU
in decoding operation. Two v4l2 interfaces are exposed, one for
encoding and one for decoding, but a single m2m device is shared
by them, so jobs are properly serialized.
Signed-off-by: Ezequiel Garcia
Signed-
From: Ezequiel Garcia
Rework the way controls are registered by the driver,
so it can support non-standard controls, such as those
used by stateless codecs.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
--
Changes from v3:
* None
Changes from v2:
* Got rid of unused ctrls rela
From: Ezequiel Garcia
Use the recently introduced v4l2_m2m_buf_copy_metadata helper
and get rid of some code.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
---
Changes from v3:
* None
Changes from v2:
* None
---
drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c | 9 +-
From: Ezequiel Garcia
In order to make the code more generic, introduce a pair of start/stop
codec operations, and use them to allocate and release the JPEG bounce
buffer.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
---
Changes from v3:
* None
Changes from v2:
* Reword boun
From: Jonas Karlman
media_device_cleanup() and v4l2_m2m_unregister_media_controller() were
missing in the probe error path.
While at it, re-order calls in the remove path to unregister/cleanup
things in the reverse order they were initialized/registered.
Signed-off-by: Jonas Karlman
Signed-off-
From: Ezequiel Garcia
Now that we've introduced the pixel format helpers, use them
in vpu driver, and get rid of the internal helpers.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
---
Changes from v3:
* None
Changes from v2:
* None
---
.../media/rockchip/vpu/rockchip_vpu_enc
From: Jonas Karlman
Those calls are needed to restore a clean PM state when the probe fails
or when the driver is unloaded such that future ->probe() calls can
initialize runtime PM again.
Signed-off-by: Jonas Karlman
Signed-off-by: Boris Brezillon
---
Changes from v3:
* New patch
---
drivers
This series introduces the decoding infrastructure that will be
used to add support for other codecs such as VP8, VP9 and H.264.
As explained in the cover letter for the v1 patchset,
the driver is now exposing two video device nodes.
The VPU encoder is exposed on /dev/video0, and the VPU decoder
i
vdev is guaranteed to be equal to vpu->vfd_enc thanks a test done a few
lines above. Remove this useless test.
Signed-off-by: Boris Brezillon
---
Changes from v3:
* Move earlier in the series
Changes from v2:
* New patch
---
drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c | 6 ++
1 fi
From: Ezequiel Garcia
We need to make the macrobock alignment generic, in order
to support multiple codecs.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
---
Changes from v3:
* None
Changes from v2:
* None
---
.../media/rockchip/vpu/rockchip_vpu_enc.c | 20 ---
62 matches
Mail list logo
