Hi,
I thought I had answered here already, but looks I never sent the email.
On Sat 05 Oct 19, 23:21, Tomasz Figa wrote:
> On Sat, Oct 5, 2019 at 11:12 PM Paul Kocialkowski
> wrote:
> >
> > On Sat 05 Oct 19, 22:54, Tomasz Figa wrote:
> > > On Sat, Oct 5, 2019 at
On Sat 05 Oct 19, 23:21, Tomasz Figa wrote:
> On Sat, Oct 5, 2019 at 11:12 PM Paul Kocialkowski
> wrote:
> >
> > On Sat 05 Oct 19, 22:54, Tomasz Figa wrote:
> > > On Sat, Oct 5, 2019 at 10:39 PM Paul Kocialkowski
> > > wrote:
> > > >
> > &
On Sat 05 Oct 19, 22:54, Tomasz Figa wrote:
> On Sat, Oct 5, 2019 at 10:39 PM Paul Kocialkowski
> wrote:
> >
> > Hi,
> >
> > On Sat 05 Oct 19, 17:22, Tomasz Figa wrote:
> > > On Fri, Oct 4, 2019 at 6:12 AM Paul Kocialkowski
> > > wrote:
> > &
Hi,
On Sat 05 Oct 19, 17:22, Tomasz Figa wrote:
> On Fri, Oct 4, 2019 at 6:12 AM Paul Kocialkowski
> wrote:
> >
> > Hi,
> >
> > On Thu 05 Sep 19, 13:42, Philipp Zabel wrote:
> > > To explain why num_ref_idx_active_override_flag is not part of the API,
nd it doesn't
do slice parsing itself), we could always check the flag in the driver and use
either the default PPS values or the slice-specific values there.
What do you think?
Cheers,
Paul
> Signed-off-by: Philipp Zabel
> ---
> Documentation/media/uapi/v4l/ext-ctrls-codec.rst
Hi,
On Thu 05 Sep 19, 12:15, Philipp Zabel wrote:
> This flag tells the kernel whether the slice header contained the
> num_ref_idx_l[01]_active_minus1 syntax elements, or whether the
> num_ref_idx_l[01]_default_active_minus1 from PPS should be used
> instead.
Looks good to me:
Revie
us no need to have the flag in the uapi), if userspace
> > fills the default into the override fields as a fallback. Such a decoder
> > does need the num_ref_idx_l[01]_active_minus1 override, but doesn't need
> > the num_ref_idx_l[01]_default_active_minus1 field nor the flag.
> >
> > That is my current understanding of the intention behind this interface,
> > I hope this is accurate.
> > I've tried to make the docs reflect this in ("media: uapi: h264: clarify
> > num_ref_idx_l[01]_(default_)active fields") [1].
> >
> > [1]
> > https://lore.kernel.org/linux-media/20190905114210.9232-1-p.za...@pengutronix.de/T/#u
>
> Yes, makes sense for me.
Sorry for being late to the party and catching up with this just now.
It looks like the conclusion is that we need to keep both the PPS default
and slice-specific set of fields to cover both hardware that parses the slice
header and hardware that doesn't.
In H265, I had evicted the PPS default value and the flag in favor of only
providing a slice-specific value, but I should certainly revise this to have
the two sets of values and the flag. This should allow covering hardware that
does slice header parsing itself.
Cheers,
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
has no requirements since it can parse all the
> + information from the raw bytestream.
Maybe it would be clearer to mention that "no requirements" concerns the
lack of frame/field boundary requirement? Otherwise it feels a bit unclear
what userspace
Hi,
On Mon 12 Aug 19, 13:05, Hans Verkuil wrote:
> From: Maxime Jourdan
>
> Tag all the coded formats where the vicodec stateful decoder supports
> dynamic resolution switching and bytestream parsing.
Looks good to me:
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> Signed
Hi,
On Mon 12 Aug 19, 13:05, Hans Verkuil wrote:
> From: Maxime Jourdan
>
> Tag all the coded formats where the mtk-vcodec decoder supports dynamic
> resolution switching.
Looks good to me despite lack of knowledge about the hardware.
Reviewed-by: Paul Kocialkowski
Cheers,
Pa
dware really supports.
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> Signed-off-by: Maxime Jourdan
> Signed-off-by: Hans Verkuil
> [hverkuil-ci...@xs4all.nl: added CONTINUOUS_BYTESTREAM]
> ---
> .../media/platform/s5p-mfc/s5p_mfc_common.h| 1 +
> drivers/media/platfor
Hi,
On Mon 12 Aug 19, 13:05, Hans Verkuil wrote:
> From: Maxime Jourdan
>
> Tag all the coded formats where the venus vdec supports dynamic
> resolution switching.
Looks good to me.
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> Signed-off-by: Maxime Jourdan
> Signed-of
pre-parses the bytestream into
> frames or fields (see the corresponding pixelformat descriptions
> for details).
>
> If this flag is set, then this pre-parsing step is not required
> (but still possible, of course).
Although I wasn't involved with the initial issue, l
resolution switching for one or more of their listed coded formats. It
> allows userspace to know whether it should extract the video parameters
> itself, or if it can rely on the device to send V4L2_EVENT_SOURCE_CHANGE
> when such changes are detected.
Makes sense and looks good to me:
ng one pixel format per hardware implementation and I believe it
makes no sense. I really don't find it to be an elegant or scalable way to
expose the differences between decoder implementations.
So the approach I currently like best is to have as much information as possible
passed to the d
Hi,
On Sat 27 Jul 19, 11:46, Boris Brezillon wrote:
> On Sat, 27 Jul 2019 11:27:43 +0200
> Paul Kocialkowski wrote:
>
> > Hi,
> >
> > On Fri 26 Jul 19, 10:53, Hans Verkuil wrote:
> > > On 7/26/19 9:30 AM, Boris Brezillon wrote:
> > > >
Hi,
On Sun 28 Jul 19, 23:05, Tomasz Figa wrote:
> On Sat, Jul 27, 2019 at 6:37 PM Paul Kocialkowski
> wrote:
> >
> > Hi,
> >
> > On Wed 24 Jul 19, 13:05, Hans Verkuil wrote:
> > > Add an enum_fmt format flag to specifically tag coded formats where
> >
Hi,
On Wed 24 Jul 19, 13:05, Hans Verkuil wrote:
> Fix typo.
>
> Signed-off-by: Hans Verkuil
Looks good!
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
> Documentation/media/videodev2.h.rst.exceptions | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
COMPRESSED`` flag, since this applies to compressed
> + formats only.
Should this flag be set for stateless codecs as well? It seems a bit over-kill
for this case. I am not sure whether "compressed bitstream format" clearly only
covers the formats used by stateful decoders and no
Hi,
On Fri 26 Jul 19, 10:53, Hans Verkuil wrote:
> On 7/26/19 9:30 AM, Boris Brezillon wrote:
> > On Fri, 26 Jul 2019 08:28:28 +0200
> > Boris Brezillon wrote:
> >
> >> On Thu, 25 Jul 2019 23:39:11 -0300
> >> Ezequiel Garcia wrote:
> >&g
am order
> > > -* - __u8
> > > - - ``ref_pic_list_b1[32]``
> > > - - Forward reference list used by B-frames in the original
> > > bitstream order
> > > * - __s32
> > >- ``top_field_order_cnt``
> > >- Picture Order Count for the coded top field
> >
> > Thanks for the patch.
> >
> > Don't we also need to remove these fields from the UAPI structs?
>
> Oops, indeed. I'll drop them in the next version.
With that change, feel free to add my:
Reviewed-by: Paul Kocialkowski
Cheers and thanks!
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Hi,
On Thu 25 Jul 19, 08:42, Boris Brezillon wrote:
> On Fri, 5 Jul 2019 19:16:18 +0200
> Boris Brezillon wrote:
>
> > On Fri, 05 Jul 2019 13:40:03 -0300
> > Ezequiel Garcia wrote:
> >
> > > Hi Boris, Paul,
> > >
> > > On Wed, 2019-07-03
t; to select the type of NAL header to use.
After thinking a bit about this, I'd rather be in favor of having offsets
in the control structures rather than forcing the start code type or having a
dedicated control for that, as I've mentionned on the other patch.
What do you think?
Ch
ainly be done as a subsequent patch/series, and definitely not
necessarily by you (don't want to add more on your shoulders at this point)!
Cheers,
Paul
> /* Offset in bits to slice_data() from the beginning of this slice. */
> __u32 header_bit_size;
>
> --
> 2.21.0
Hi,
On Mon 22 Jul 19, 18:58, Sakari Ailus wrote:
> On Mon, Jul 22, 2019 at 07:14:08PM +0530, Nishka Dasgupta wrote:
> > On 22/07/19 5:54 PM, Paul Kocialkowski wrote:
> > > Hi,
> > >
> > > On Mon 22 Jul 19, 12:12, Jeremy Sowden wrote:
> > > > O
Hi,
On Mon 22 Jul 19, 19:14, Nishka Dasgupta wrote:
> On 22/07/19 5:54 PM, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Mon 22 Jul 19, 12:12, Jeremy Sowden wrote:
> > > On 2019-07-22, at 11:36:51 +0530, Nishka Dasgupta wrote:
> > > > Typecast as bool
hey are non-zero. As a result, I think it's best to be careful.
However, I'm not sure I really see what cocinelle was unhappy about. You
mentionned single-line functions, but I don't see how that can be a problem.
So in the end, I think we should keep the !! and drop the (bool) cast if there's
no particular warning about it.
What do you think?
Cheers,
Paul
> > static void cedrus_prepare_format(struct v4l2_pix_format *pix_fmt)
> > --
> > 2.19.1
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
r so that
we are sure that the function returns either false or true, but never a
non-zero value that is not true?
Cheers,
Paul
> Signed-off-by: Nishka Dasgupta
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Hi,
On Fri 05 Jul 19, 17:43, Nishka Dasgupta wrote:
> On 05/07/19 3:56 PM, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Wed 03 Jul 19, 13:43, Nishka Dasgupta wrote:
> > > Remove function cedrus_check_format as all it does is call
> > > cedrus_find_for
Hi,
On Fri 12 Jul 19, 12:26, wens Tsai wrote:
> On Thu, Jul 11, 2019 at 8:19 PM Paul Kocialkowski
> wrote:
> >
> > On Thu 11 Jul 19, 19:51, wens Tsai wrote:
> > > On Thu, Jul 11, 2019 at 5:39 PM Paul Kocialkowski
> > > wrote:
> > > >
> >
On Thu 11 Jul 19, 19:51, wens Tsai wrote:
> On Thu, Jul 11, 2019 at 5:39 PM Paul Kocialkowski
> wrote:
> >
> > Hi,
> >
> > On Thu 11 Jul 19, 17:21, wens Tsai wrote:
> > > I noticed that recent codec driver additions, such as hantro, meson/vdec,
>
ated in a single chunk (the single-plane
V4L2 API). I don't have any better answer than "userspace should cope with both
APIs as it reflects a hardware constraint", which is indeed what ffmpeg is
already doing.
Cheers,
Paul
> Also I noticed that v4l-utils has a plugin that se
a !! or a bool cast to make coccinelle happy here?
Cheers,
Paul
> Signed-off-by: Nishka Dasgupta
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/media/sunxi/c
icial, sorry.
Cheers,
Paul
> Signed-off-by: Nishka Dasgupta
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> b/d
> +
> + __u8 num_dct_parts;
> + __u32 dct_part_sizes[8];
> +
> + __u8 bool_dec_range;
> + __u8 bool_dec_value;
> + __u8 bool_dec_count;
> +
> + __u64 last_frame_ts;
> + __u64 golden_frame_ts;
> + __u64 alt_frame_ts;
> +
> + __
removing the DPB or at least renaming it, but
I don't have a clear idea of the outcome as well.
Cheers,
Paul
> Signed-off-by: Boris Brezillon
> ---
> Changes in v2:
> * None
> ---
> Documentation/media/uapi/v4l/ext-ctrls-codec.rst | 9 -
> 1 file changed, 9
ssed at a time.
About that, I'm wondering how we could handle that in our drivers.
It will probably be something like:
device_run -+-> decode slice i -> IRQ -+-> job_finish
`--- i++ --'
And I'm wondering if there could be common helpers to hel
control
> to select the type of NAL header to use.
>
> Signed-off-by: Boris Brezillon
Looks good to me:
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
> Changes in v2:
> * None
>
> Note: we might want to add a nal_header_size field to allow drivers to
> quickly
uld give us enough information to achieve both. A
> > slice with index 0 is obviously going to be the first slice in a frame.
>
> We do this in per-frame mode only. The offset of the slice in the
> bitstream is always 0 in per-slice mode, since each v4l2 input buffer
> is a slice.
I don't think we need a slice index either, we most likely already have
enough information to know where we're at regarding slices position.
But how about allowing an arbitrary number of slices within frame
boundary in per-slice decoding mode?
Cheers,
Paul
Hi,
Le lundi 03 juin 2019 à 13:09 +0200, Boris Brezillon a écrit :
> We are about to add a menu control, so let's make the code more generic
> to support other control types.
Did you have a chance to test this or should I better give it a spin
before adding my Reviewed-By?
Ch
LAG 0x01
> #define V4L2_H264_SPS_CONSTRAINT_SET1_FLAG 0x02
> @@ -111,6 +118,8 @@ struct v4l2_h264_pred_weight_table {
> struct v4l2_h264_weight_factors weight_factors[2];
> };
>
> +#define V4L2_H264_MAX_SLICES_PER_FRAME
> +:widths: 1 1 2
> > > > > > +
> > > > > > +* - ``V4L2_MPEG_VIDEO_H264_DECODING_PER_SLICE``
> > > > > > + - 0
> > > > > > + - The decoding is done per slice.
> > > > > > v4l2_ctrl_h26
all the time out of simplicity. I mean drivers that don't need it will
> > > > already ignore it (i.e. they must not break if they get the extra data)
> > > > so other than the potential runtime savings on some hardware, there are
> > > > no advantages.
> >
pace
side by having these decoder-specific details handled by the kernel.
It also brings us closer to bitstream format (where the modifications
are coded) and leaves DPB management to the decoder/driver, which IMO
makes a lot of sense.
Cheers,
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
m where we group controls (parsed
bitstream meta-data) and source (OUTPUT) buffers together and submit
them tied. When each request gets processed its buffer enters the
OUTPUT queue, which gets picked up by the driver and associated with
the first destination (CAPTURE) buffer available. Then the driver grabs
the buffers and applies the controls matching the source buffer's
request before starting decoding with M2M.
We have already worked on handling the case of requiring a single
destination buffer for the different slices, by having a flag to
indicate whether the destination buffer should be held.
Cheers,
Paul
Hi,
Le mercredi 22 mai 2019 à 15:48 +0900, Tomasz Figa a écrit :
> On Sat, May 18, 2019 at 11:09 PM Nicolas Dufresne
> wrote:
> > Le samedi 18 mai 2019 à 12:29 +0200, Paul Kocialkowski a écrit :
> > > Hi,
> > >
> > > Le samedi 18 mai 2019 à 12:04 +020
Hi,
On Tue, 2019-05-21 at 19:27 +0900, Tomasz Figa wrote:
> On Thu, May 16, 2019 at 2:43 AM Paul Kocialkowski
> wrote:
> > Hi,
> >
> > Le mercredi 15 mai 2019 à 10:42 -0400, Nicolas Dufresne a écrit :
> > > Le mercredi 15 mai 2019 à 12:09 +0200, Paul
Hi,
Le samedi 18 mai 2019 à 12:04 +0200, Jernej Škrabec a écrit :
> Dne sobota, 18. maj 2019 ob 11:50:37 CEST je Paul Kocialkowski napisal(a):
> > Hi,
> >
> > On Fri, 2019-05-17 at 16:43 -0400, Nicolas Dufresne wrote:
> > > Le jeudi 16 mai 2019 à 20:45 +0
Hi,
On Fri, 2019-05-17 at 16:43 -0400, Nicolas Dufresne wrote:
> Le jeudi 16 mai 2019 à 20:45 +0200, Paul Kocialkowski a écrit :
> > Hi,
> >
> > Le jeudi 16 mai 2019 à 14:24 -0400, Nicolas Dufresne a écrit :
> > > Le mercredi 15 mai 2019 à 22:59 +0200, Paul Koc
Hi,
Le jeudi 16 mai 2019 à 14:24 -0400, Nicolas Dufresne a écrit :
> Le mercredi 15 mai 2019 à 22:59 +0200, Paul Kocialkowski a écrit :
> > Hi,
> >
> > Le mercredi 15 mai 2019 à 14:54 -0400, Nicolas Dufresne a écrit :
> > > Le mercredi 15 mai 2019 à 19:42 +0
Hi,
Le mercredi 15 mai 2019 à 14:54 -0400, Nicolas Dufresne a écrit :
> Le mercredi 15 mai 2019 à 19:42 +0200, Paul Kocialkowski a écrit :
> > Hi,
> >
> > Le mercredi 15 mai 2019 à 10:42 -0400, Nicolas Dufresne a écrit :
> > > Le mercredi 15 mai 2019 à 12:09 +0
Hi,
Le mercredi 15 mai 2019 à 10:42 -0400, Nicolas Dufresne a écrit :
> Le mercredi 15 mai 2019 à 12:09 +0200, Paul Kocialkowski a écrit :
> > Hi,
> >
> > With the Rockchip stateless VPU driver in the works, we now have a
> > better idea of what the situation is l
er;
I'm up for preparing and submitting these control changes and updating
cedrus if they seem agreeable.
What do you think?
Cheers,
Paul
[0]: https://lkml.org/lkml/2019/3/6/82
[1]: https://patchwork.linuxtv.org/patch/55947/
[2]:
https://chromium.googlesource.com/chromiumos/third_party/k
U horsepower and RAM bandwidth may be scarce
> (though not as a rule), X11 is not mandatory and HW blitting may
> actually matter...
It sure does, indeed! The situation you are describing for non-x86 is
exactly the problem I want to help tackle with this :)
Cheers and thanks for your interest,
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
r to take this into account, marking
both src/dst buffers as error (as suggested by Hans on IRC).
> Signed-off-by: Dafna Hirschfeld
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 18 +++---
> include/media/v4l2-ctrls.h
ht need to get rid of the
flag when adding support for decoding JPEG, which may not require the
request API.
Acked-by: Paul Kocialkowski
Cheers,
Paul
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/d
Hi,
On Wed, 2019-03-06 at 13:13 -0800, Dafna Hirschfeld wrote:
> From: Hans Verkuil
>
> Add capability to indicate that requests are required instead of
> merely supported.
>
> Signed-off-by: Hans Verkuil
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
> Docu
Hi,
On Wed, 2019-03-06 at 13:13 -0800, Dafna Hirschfeld wrote:
> From: Hans Verkuil
>
> Stateless codecs require the use of the Request API as opposed of it
> being optional.
>
> So add a bit to indicate this and let vb2 check for this.
>
> Signed-off-by: Hans Ver
unsubscribe linux-wireless
, 4 bits.
Signed-off-by: Paul Kocialkowski
---
Documentation/media/uapi/v4l/biblio.rst | 9 +
.../media/uapi/v4l/ext-ctrls-codec.rst| 418 ++
.../media/uapi/v4l/pixfmt-compressed.rst | 15 +
.../media/uapi/v4l/vidioc-queryctrl.rst | 18 +
.../media
indices in the DPB
* Declared variable in their reduced scope as suggested;
* Added the H.265/HEVC spec to the biblio;
* Used in-doc references to the spec and the required APIs;
* Removed debugging leftovers.
Cheers!
Paul Kocialkowski (2):
media: v4l: Add definitions for the HEVC slice format
This introduces support for HEVC/H.265 to the Cedrus VPU driver, with
both uni-directional and bi-directional prediction modes supported.
Field-coded (interlaced) pictures, custom quantization matrices and
10-bit output are not supported at this point.
Signed-off-by: Paul Kocialkowski
Since there's a v4l2_m2m_get_vq helper, use it instead of accessing the
queue directly, which slightly increases readability.
Also reformat the code using the queue a bit while at it.
Signed-off-by: Paul Kocialkowski
---
drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c | 10 +-
1
Check that our queues are not busy before setting the format or return
EBUSY if that's the case. This ensures that our format can't change
once buffers are allocated for the queue.
Signed-off-by: Paul Kocialkowski
---
drivers/staging/media/sunxi/cedrus/cedrus_video.c | 10
Hi,
On Thu, 2019-02-14 at 09:59 +0100, Hans Verkuil wrote:
> On 2/14/19 9:37 AM, Paul Kocialkowski wrote:
> > Check that our queues are not busy before setting the format or return
> > EBUSY if that's the case. This ensures that our format can't change
> > once buff
Check that our queues are not busy before setting the format or return
EBUSY if that's the case. This ensures that our format can't change
once buffers are allocated for the queue.
Signed-off-by: Paul Kocialkowski
---
drivers/staging/media/sunxi/cedrus/cedrus_video.c | 14
On Wed, 2019-02-13 at 10:39 +0100, Hans Verkuil wrote:
> On 2/13/19 10:08 AM, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Wed, 2019-02-13 at 09:20 +0100, Hans Verkuil wrote:
> > As far as I understand from [0], the capture and output formats can't
> > be cha
Hi,
On Wed, 2019-02-13 at 10:57 +0100, Hans Verkuil wrote:
> On 2/13/19 10:20 AM, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Wed, 2019-02-13 at 09:59 +0100, Hans Verkuil wrote:
> > > On 2/13/19 6:58 AM, Alexandre Courbot wrote:
> > > > On Wed,
ec
controls). It also allows setting the control outside of a request for
enumerating formats.
What do you think?
Cheers,
Paul
> Regards,
>
> Hans
>
> > Signed-off-by: Hans Verkuil
> > ---
> > .../media/uapi/v4l/vidioc-queryctrl.rst
e the memory it refers
> to is no longer valid.
>
> So keep track of a 'copied_timestamp' state: it is set when the
> timestamp is copied from an output to a capture buffer, and is
> cleared when it is no longer valid.
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> Si
when all frames depending on it have been decoded. So I am leaning
> towards not complicating matters and keeping your first sentence
> as-is.
Yes, I believe it would be much simpler to require userspace to only
queue capture buffers once they are no longer needed as references.
This also means that the dmabuf fd can't be changed so we are
guaranteed that memory will still be there.
Cheers,
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Hi,
On Mon, 2019-02-04 at 11:11 +0100, hverkuil-ci...@xs4all.nl wrote:
> From: Hans Verkuil
>
> The bool type is not recommended for use in structs, so replace these
> by bitfields.
>
> Signed-off-by: Hans Verkuil
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
&g
n't happen today with the cedrus driver AFAIK. Or can it?
As far as I understand from [0], the capture and output formats can't
be changed once we have allocated buffers so I don't really see how we
could end up with mixed resolutions.
[0]:
https://linuxtv.org/downloads/v4l-dvb
about a silly mistake when refactoring. Looks good otherwise,
so with that fixed:
Reviewed-by: Paul Kocialkowski
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/bridge/cdns-dsi.c | 101 ++-
> 1 file changed, 73 insertions(+), 28 deletions(-)
>
&
Hi,
On Mon, 2019-01-21 at 16:45 +0100, Maxime Ripard wrote:
> Now that our MIPI D-PHY driver has been converted to the phy framework,
> let's move it into the drivers/phy directory.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
>
Ripard
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
> drivers/gpu/drm/sun4i/Kconfig | 11 +-
> drivers/gpu/drm/sun4i/Makefile | 6 +-
> drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 164 ++---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c |
Ripard
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
> drivers/gpu/drm/sun4i/Kconfig | 11 +-
> drivers/gpu/drm/sun4i/Makefile | 6 +-
> drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 164 ++---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c |
Hi,
On Thu, 2019-01-24 at 20:23 +0800, Ayaka wrote:
>
> Sent from my iPad
>
> > On Jan 24, 2019, at 6:27 PM, Paul Kocialkowski
> > wrote:
> >
> > Hi,
> >
> > > On Thu, 2019-01-10 at 21:32 +0800, ayaka wrote:
> > > I forget a impo
Hi,
On Tue, 2018-11-27 at 09:21 +0100, Maxime Ripard wrote:
> Hi!
>
> On Fri, Nov 23, 2018 at 02:02:09PM +0100, Paul Kocialkowski wrote:
> > This introduces support for HEVC/H.265 to the Cedrus VPU driver, with
> > both uni-directional and bi-directional predi
: Paul Kocialkowski
---
drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 13 -
drivers/staging/media/sunxi/cedrus/cedrus_dec.h | 2 --
drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c | 10 --
3 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/staging
Hi,
On Thu, 2019-01-24 at 11:32 +0100, Greg KH wrote:
> On Thu, Jan 24, 2019 at 10:55:42AM +0100, Paul Kocialkowski wrote:
> > This reverts commit cf20ae1535eb690a87c29b9cc7af51881384e967.
> >
> > The vb2_find_timestamp helper was modified to allow finding buffers
> >
Hi,
On Tue, 2019-01-08 at 18:00 +0800, Ayaka wrote:
>
> Sent from my iPad
>
> > On Jan 8, 2019, at 4:38 PM, Paul Kocialkowski
> > wrote:
> >
> > Hi,
> >
> > > On Tue, 2019-01-08 at 09:16 +0800, Ayaka wrote:
> > >
> > >
m2m stateless video decoder interface
Can you detail exactly what the rockchip decoder absolutely needs in
raw bitstream format?
Cheers,
Paul
> On 1/8/19 6:00 PM, Ayaka wrote:
> > Sent from my iPad
> >
> > > On Jan 8, 2019, at 4:38 PM, Paul Kocialkowski
> > > wr
This reverts commit cf20ae1535eb690a87c29b9cc7af51881384e967.
The vb2_find_timestamp helper was modified to allow finding buffers
regardless of their current state in the queue. This means that we
no longer have to take particular care of references to the current
capture buffer.
---
drivers/stag
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/
uffer once (when it
is first needed when queued) and keep it mapped until it is freed.
Signed-off-by: Pawel Osciak
Reviewed-on: https://chromium-review.googlesource.com/334103
Signed-off-by: Paul Kocialkowski
[Paul: Updated for mainline and changed commit message]
---
drivers/media/common/vide
t copy timestamps.
>
> This change allows for more efficient pipelining (i.e. you can use
> a buffer for a reference frame even when it is queued).
>
> Signed-off-by: Hans Verkuil
Reviewed-by: Paul Kocialkowski
I guess I'll prepare a new patch to revert the change I made
Hi,
On Thu, 2019-01-24 at 17:07 +0900, Tomasz Figa wrote:
> On Wed, Jan 23, 2019 at 7:42 PM Paul Kocialkowski
> wrote:
> > Hi Alex,
> >
> > On Wed, 2019-01-23 at 18:43 +0900, Alexandre Courbot wrote:
> > > On Tue, Jan 22, 2019 at 7:10 PM Paul Koci
Hi Alex,
On Wed, 2019-01-23 at 18:43 +0900, Alexandre Courbot wrote:
> On Tue, Jan 22, 2019 at 7:10 PM Paul Kocialkowski
> wrote:
> > Hi,
> >
> > On Tue, 2019-01-22 at 17:19 +0900, Tomasz Figa wrote:
> > > Hi Paul,
> > >
> > > On Fri, De
Hi,
On Tue, 2019-01-22 at 17:19 +0900, Tomasz Figa wrote:
> Hi Paul,
>
> On Fri, Dec 7, 2018 at 5:30 PM Paul Kocialkowski
> wrote:
> > Hi,
> >
> > Thanks for this new version! I only have one comment left, see below.
> >
> > On Wed, 2018-12-
ff-by: Maxime Ripard
Aside from the wakeup change mentioned in patch 8,
Acked-by: Sean Paul
> ---
> drivers/gpu/drm/bridge/Kconfig| 1 +-
> drivers/gpu/drm/bridge/cdns-dsi.c | 485 +++
> drivers/phy/cadence/cdns-dphy.c | 2 +-
> 3 files chang
evm_clk_get(&pdev->dev, "pll_ref");
> + if (IS_ERR(dphy->pll_ref_clk))
> + return PTR_ERR(dphy->pll_ref_clk);
> +
> + if (dphy->ops->probe) {
> + ret = dphy->ops->probe(dphy);
> + if (ret)
>
id(struct drm_bridge *bridge,
> if ((mode->hdisplay * bpp) % 32)
> return MODE_H_ILLEGAL;
>
> - nlanes = output->dev->lanes;
> -
> - ret = cdns_dsi_mode2cfg(dsi, mode, &dsi_cfg, &dphy_cfg, true);
> + ret = cdns_dsi_check_conf(dsi, mode, &dsi_cfg, &dphy_cfg, true);
> if (ret)
> - return MODE_CLOCK_RANGE;
> + return MODE_BAD;
>
> return MODE_OK;
> }
> @@ -990,7 +1030,7 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
> *bridge)
> bpp = mipi_dsi_pixel_format_to_bpp(output->dev->format);
> nlanes = output->dev->lanes;
>
> - WARN_ON_ONCE(cdns_dsi_mode2cfg(dsi, mode, &dsi_cfg, &dphy_cfg, false));
> + WARN_ON_ONCE(cdns_dsi_check_conf(dsi, mode, &dsi_cfg, &dphy_cfg,
> false));
>
> cdns_dsi_hs_init(dsi, &dphy_cfg);
> cdns_dsi_init_link(dsi);
> --
> git-series 0.9.1
--
Sean Paul, Software Engineer, Google / Chromium OS
starting with:
media: cedrus: Cleanup duplicate declarations from cedrus_dec header
Paul Kocialkowski (4):
media: vb2: Add helpers to access unselected buffers
media: v4l2-mem2mem: Add an optional job_done operation
media: cedrus: Request access to reference buffers when decoding
media: cedrus
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/
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
can be passed to the operation.
Delaying the current context clearing should not be a problem since the
next call to v4l2_m2m_try_run happens right after that.
Signed-off-by: Paul Kocialkowski
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 8 ++--
include/media/v4l2-mem2mem.h | 4
-by: Paul Kocialkowski
---
.../media/common/videobuf2/videobuf2-core.c | 46 +++
include/media/videobuf2-core.h| 15 ++
2 files changed, 61 insertions(+)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
b/drivers/media/common/videobuf2/videobuf2
Hi,
On Wed, 2019-01-09 at 15:29 +0100, Hans Verkuil wrote:
> On 01/09/19 15:19, Paul Kocialkowski wrote:
> > It was reported that some cases of interleaved video decoding require
> > using the current destination buffer as a reference. However, this is
> > no longer possi
the current destination
buffer before resorting to vb2_find_timestamp and use it in MPEG-2.
Signed-off-by: Paul Kocialkowski
---
drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 13 +
drivers/staging/media/sunxi/cedrus/cedrus_dec.h | 2 ++
drivers/staging/media/sunxi/cedrus
1 - 100 of 453 matches
Mail list logo
