[Bug 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103791

--- Comment #12 from denisgolo...@yandex.ru ---
Created attachment 135917
  --> https://bugs.freedesktop.org/attachment.cgi?id=135917=edit
dmesg with debug

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103791

--- Comment #11 from denisgolo...@yandex.ru ---
Yes, I fixed some small issues with the patch.
Now I have following appear in dmesg:
[ 2108.319205] [drm] drm_crtc_vblank_get returned -EINVAL
[ 2108.319235] [drm] crtc 0 failed to acquire vblank counter, -22

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Heiko Stübner]

Hi Chris,

Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
> On 2017年12月02日 05:58, Heiko Stuebner wrote:
> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> >> Hi,
> >> 
> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:
> >>> Hi Doug
> >>> 
> >>> Thank you for mentioning this patch.
> >>> 
> >>> I think the focus of the discussion is: can we put the grf control bit
> >>> to
> >>> dts.
> >>> 
> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
> >>> "uphy_dp_sel"
> >>> 
> >>> can help to switch these 2 phy. So I think this bit can be considered as
> >>> a
> >>> part of
> >>> 
> >>> Type-C phy, these 2 phy have different bits, just similar to other bits
> >>> (such as "pipe-status").
> >>> 
> >>> Put them to DTS file might be a accepted practice.
> >> 
> >> I guess the first step would be finding the person to make a decision.
> >> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
> >> options:
> >> 
> >> 1. Land this series as-is.  This makes the new bit work just like all
> >> the other ones next to it.  If anyone happens to try to use an old
> >> device tree on a new kernel they'll break.  Seems rather unlikely
> >> given that the whole type C PHY is not really fully functional
> >> upstream, but technically this is a no-no from a device tree
> >> perspective.
> >> 
> >> 2. Change the series to make this property optional.  If it's not
> >> there then the code behaves like it always did.  This would address
> >> the "compatibility" problem but likely wouldn't actually help any real
> >> people, and it would be extra work.
> >> 
> >> 3. Redo the driver to deprecate all the old offsets / bits and just
> >> put the table in the driver, keyed off the compatible string and base
> >> address if the IO memory.
> >> 
> >> 
> >> I can't make this decision.  It's up to those folks who would be
> >> landing the patch and I'd be happy with any of them.  What I'm less
> >> happy with, however, is the indecision preventing forward progress.
> >> We should pick one of the above things and land it.  My own personal
> >> bias is #1: just land the series.  No real people will be hurt and
> >> it's just adding another property that matches the ones next to it.
> > 
> > I'd second that #1 . That whole type-c phy thingy never fully worked in
> > the past (some for the never used dp output), so personally I don't have
> > issues with going that route.
> > 
> >>  From a long term perspective (AKA how I'd write the next driver like
> >> 
> >> this) I personally lean towards to "tables in the driver, not in the
> >> device tree" but quite honestly I'm happy to take whatever direction
> >> the maintainers give.
> > 
> > It looks like we're in agreement here :-) . GRF stuff should not leak into
> > the devicetree, as it causes endless headaches later. But I guess we'll
> > need to live with the ones that happened so far.
> 
> So, the first step is: move all the private property of tcphy to
> drivers/phy/rockchip/phy-rockchip-typec.c.
> Second step: new a member: uphy-dp-sel.
> In my mind, we should have discussed these properties before, and then I
> moved them all into DTS.

Actually, I was agreeing with Doug, that we probably don't need to rework the 
type-c phy driver. As most properties for it are in the devicetree right now
we'll need to support them for backwards-compatiblity anyway.

And yes, there probably was discussion over dts vs. driver-table when the
type-c driver was introduced, but I either missed it or wasn't firm enough
back then ;-) .

Hence the "we'll need to live with it" for the type-c phy, but should not
do similar things in future drivers.


Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 2/2] drm/tinydrm: add driver for ILI9225 panels

[Daniel Vetter]

On Fri, Dec 01, 2017 at 03:03:30PM +0100, Linus Walleij wrote:
> On Wed, Nov 8, 2017 at 4:52 AM, David Lechner  wrote:
> 
> > This adds a new driver for display panels based on the Ilitek ILI9225
> > controller.
> >
> > This was developed for a no-name panel with a red PCB that is commonly
> > marketed for Arduino. See .
> >
> > I really did try very hard to find a make and model for this panel, but
> > there doesn't seem to be one, so the best I can do is offer the picture
> > in the link above for identification.
> >
> > Signed-off-by: David Lechner 
> 
> Can you explain why tinydrm is not putting its panel drivers in
> drivers/gpu/drm/panel?
> 
> I guess everybody knows except me, it's usually like that :(
> 
> I am anyways working on a driver for Ilitek 9322 that I want
> to land in drivers/gpu/drm/panel. Here is the last iteration:
> https://lists.freedesktop.org/archives/dri-devel/2017-August/150205.html
> Yeah I got sidetracked. OK I will get to it now.
> 
> There are some similarities with the code I'm seeing here
> but I believe they are essentially different. But it will be hard
> to share code if you put the driver in the tinydrm framework.
> 
> I guess you have also seen:
> drivers/video/backlight/ili922x.c
> ?
> 
> Stefano Babic who wrote the backlight driver is available for
> reviewing, so includ him in follow-ups (added to To: line).
> 
> I'm putting you on CC as I'm rewriting it a bit after the DT
> maintainers review, will try to repost ASAP.

Bit more historical context: We tried using drm_panel in tinydrm, but that
didn't really fit to well (as Noralf explains, tinydrm is kinda more for
stand-alone panels). But tinydrm is also a bit too much midlayer-y still,
so there's a bunch of todo items capture in Documentation/gpu/todo.rst. In
the end we shouldn't need a special tinydrm driver, that should be covered
by the usual drm helpers.

Might be worth it to at least capture/summarize some of the reasons for
why tinydrm doesn't use drm_panel, and what it would take to better share
code (or maybe that's just a silly idea, not the first duplicated driver
in drm).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104043] TV out garbled with linux > 3.2 (RV516)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104043

Alex Deucher  changed:

   What|Removed |Added

   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
Product|xorg|DRI
 QA Contact|xorg-t...@lists.x.org   |
  Component|Driver/Radeon   |DRM/Radeon

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Chris Zhong]

Hi Heiko


On 2017年12月02日 05:58, Heiko Stuebner wrote:

Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:

Hi,

On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:

Hi Doug

Thank you for mentioning this patch.

I think the focus of the discussion is: can we put the grf control bit to
dts.

The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel"

can help to switch these 2 phy. So I think this bit can be considered as a
part of

Type-C phy, these 2 phy have different bits, just similar to other bits
(such as "pipe-status").

Put them to DTS file might be a accepted practice.

I guess the first step would be finding the person to make a decision.
Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
options:

1. Land this series as-is.  This makes the new bit work just like all
the other ones next to it.  If anyone happens to try to use an old
device tree on a new kernel they'll break.  Seems rather unlikely
given that the whole type C PHY is not really fully functional
upstream, but technically this is a no-no from a device tree
perspective.

2. Change the series to make this property optional.  If it's not
there then the code behaves like it always did.  This would address
the "compatibility" problem but likely wouldn't actually help any real
people, and it would be extra work.

3. Redo the driver to deprecate all the old offsets / bits and just
put the table in the driver, keyed off the compatible string and base
address if the IO memory.


I can't make this decision.  It's up to those folks who would be
landing the patch and I'd be happy with any of them.  What I'm less
happy with, however, is the indecision preventing forward progress.
We should pick one of the above things and land it.  My own personal
bias is #1: just land the series.  No real people will be hurt and
it's just adding another property that matches the ones next to it.

I'd second that #1 . That whole type-c phy thingy never fully worked in
the past (some for the never used dp output), so personally I don't have
issues with going that route.



 From a long term perspective (AKA how I'd write the next driver like
this) I personally lean towards to "tables in the driver, not in the
device tree" but quite honestly I'm happy to take whatever direction
the maintainers give.

It looks like we're in agreement here :-) . GRF stuff should not leak into
the devicetree, as it causes endless headaches later. But I guess we'll
need to live with the ones that happened so far.

So, the first step is: move all the private property of tcphy to 
drivers/phy/rockchip/phy-rockchip-typec.c.

Second step: new a member: uphy-dp-sel.
In my mind, we should have discussed these properties before, and then I 
moved them all into DTS.










--
Chris Zhong


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Signed-off-by missing for commits in the drm tree

[Zhenyu Wang]

On 2017.12.04 10:57:35 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> There is a series of commits
> 
>   54cff6479fd8 - c1802534e5a6
> (not all in that range)
> 
> that are missing a Signed-off-by from their committer.
> 

They were originally committed by Zhi himself, but I had to rebase
onto intel -next before they're sent for pull and missed my signed-off..
Really sorry for that! I think maybe we could still be able to fix that
before next kernel merge.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: build warning after merge of the drm tree

[Dave Airlie]

On 4 December 2017 at 10:30, Stephen Rothwell  wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:

Oops, not sure how I missed it, force pushed drm-next with the merge fixed.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: build warning after merge of the drm tree

[Stephen Rothwell]

Hi all,

After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

drivers/gpu/drm/i915/gvt/cmd_parser.c: In function 'perform_bb_shadow':
drivers/gpu/drm/i915/gvt/cmd_parser.c:1647:8: warning: unused variable 'dst' 
[-Wunused-variable]
  void *dst = NULL;
^

Introduced by commit

  93588e545a4f ("Merge tag 'drm-intel-next-2017-11-17-1' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next")

this merge reintroduced the variable declaration removed by commit

  f52c380a48f5 ("drm/i915/gvt: Refine shadow batch buffer")

-- 
Cheers,
Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: Signed-off-by missing for commits in the drm tree

[Stephen Rothwell]

Hi all,

There is a series of commits

  54cff6479fd8 - c1802534e5a6
(not all in that range)

that are missing a Signed-off-by from their committer.

-- 
Cheers,
Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=197925

--- Comment #7 from kwka...@gmx.com ---
I have confirmed that the bug (with modified behavior as described above) is
still present on my hardware (Carrizo, specifically Toshiba L55D-C with AMD
A10-8700P), as of 4.15.0-rc2.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

[SF Markus Elfring]

> How many times have I told you to include the reason for your patches
> in your proposed commit message?

Will it be useful to look again at the involved circumstances?


> Too often.

Did I answer any concerns partly?


> Many people do not know that a generic kmalloc does a dump_stack() on OOM.

Do you see a need to represent such information better?

Is it expected that the function “devm_kzalloc” has got a similar property?


> That information should be part of the commit message.

How do you think about to share it also from any reference documentation
in a clearer way?

Do we stumble on a target conflict in this case?

I am generally trying to improve the software situation to some degree.
I prefer then to work with safe information sources.
Unfortunately, I might have not reached a desired confidence level here
for a more detailed commit message. I assume that software development
efforts could increase in significant ways if something should be improved
further in a direction I hope. But this could mean that time frames will
grow for corresponding clarifications.

* Does such a situation block progress on the deletion of other remaining
  questionable error messages?

* Would you like to increase the software development attention anyhow?



By the way:
It seems that my update suggestion for the directory “omapfb/dss”
could be superseded by the patch “omapfb: dss: Do not duplicate features data”
from Ladislav Michl.
https://patchwork.kernel.org/patch/10082027/
https://lkml.kernel.org/r/<20171129123308.GA26578@lenoch>

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104053] DDX opcode causes black screen on radeon R730

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104053

Bug ID: 104053
   Summary: DDX opcode causes black screen on radeon R730
   Product: DRI
   Version: XOrg git
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: lodg...@gmail.com

Hi,
i have a problem with retroarch+xmb on ArchLinux32bit: when i run it i have
black screen, monitor led blinking and i must reset pc.
This is final output error of retroarch:

[INFO] [GL]: VSync => on
[INFO] [GLX]: glXSwapIntervalEXT(1)
r300 VP: Compiler error:
Vertex program has too many instructions
Using a dummy shader instead.
r300 FP: Compiler Error:
compiler/r300_fragprog_emit.c::translate_rgb_opcode(): translate_rgb_opcode:
Unknown opcode DDX
Using a dummy shader instead.


If i run it with "LIBGL_ALWAYS_SOFTWARE=1 retroarch" it works but is very slow
(games run at 30fps).
I use xf86-video-ati driver and mesa.
More info: http://dpaste.com/39C6SQF

Retroarch devolopers advised me to ask here.



$ glxinfo | grep renderer
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: ATI RV370



$ LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep renderer
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: llvmpipe (LLVM 5.0, 128 bits)




$ lsmod|grep -i radeon
radeon   1343488  2
i2c_algo_bit   16384  1 radeon
drm_kms_helper126976  1 radeon
ttm69632  1 radeon
drm   258048  5 radeon,ttm,drm_kms_helper



$ lspci|grep -i vga
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370
[Radeon X300/X550/X1050 Series]



$ pacman -Q|grep xf86-video
xf86-video-ati 1:7.10.0-1
xf86-video-fbdev 0.4.4+12+ge0bce0d-1
xf86-video-vesa 2.3.4-4



$ pacman -Q|grep mesa
mesa 17.2.5-1
mesa-demos 8.3.0-4
mesa-vdpau 17.2.5-1



$ uname -r
4.13.12-1-ARCH

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Rebasing the IDR

[Daniel Vetter]

On Thu, Nov 30, 2017 at 10:09 PM, Matthew Wilcox  wrote:
> On Thu, Nov 30, 2017 at 08:56:43PM +0100, Daniel Vetter wrote:
>> Adding dri-devel, I think a pile of those are in drm.
>
> Yeah, quite a lot!  This is a good thing; means you didn't invent your
> own custom ID allocator.
>
>> On Thu, Nov 30, 2017 at 6:36 PM, Matthew Wilcox  wrote:
>> > About 40 of the approximately 180 users of the IDR in the kernel are
>> > "1-based" instead of "0-based".  That is, they never want to have ID 0
>> > allocated; they want to see IDs allocated between 1 and N.  Usually, that's
>> > expressed like this:
>> >
>> > /* Get the user-visible handle using idr. */
>> > ret = idr_alloc(_priv->object_idr, obj, 1, 0, GFP_KERNEL);
>> >
>
>> Just quick context on why we do this: We need to marshal/demarshal
>> NULL in a ton of our ioctls, mapping that to 0 is natural.
>
> Yep.  You could actually store NULL at IDR index 0; the IDR distinguishes
> between an allocated NULL and an unallocated entry.

We're storing NULL in a few interim cases already, to solve issues
around init/teardown of objects (where we need to keep the index
reserved, but not pointing to anything). So if I could pick, I'd
prefer to distinguish that from the always-NULL case for 0. Since
doing that would mean in our driver unload code we'd then have to
check for that NULL pointer in the usual cleanup loops (where we know
all the interim NULL values are definitely gone).

>> And yes I very much like this, and totally fine with trading an
>> idr_init_base when we can nuke the explicit index ranges at every
>> alloc side instead. So if you give me an idr_alloc function that
>> doesn't take a range as icing, that would be great.
>
> I think the API is definitely bad at making the easy things easy ... I'd
> call the current idr_alloc() idr_alloc_range().  But I don't want to change
> 200+ call sites, so I'll settle for a new name.
>
> ret = idr_get(_priv->object_idr, obj, GFP_KERNEL);
>
> I have another new API in the works for after the xarray lands and we can
> simplify the locking --
>
> int __must_check idr_alloc_u32(struct idr *idr, void *ptr,
> unsigned int *nextid, unsigned int max, gfp_t gfp)
>
> The trick is that we store to nextid before inserting the ptr into the
> xarray, so this will enable more users to dispense with their own locking
> (or avoid awful i-looked-up-this-object-but-it's-not-initialised-so-
> pretend-i-didn't-see-it dances).
>
> (There's also an idr_alloc_ul for completeness, but I think this is
> actually a bad idea; the radix tree gets pretty unwieldy at large sparse
> indices and I don't want to encourage people to go outside unsigned int).

+1 on idr_get. A bit confusing since get/put is usually used for
refcounting in the kernel (we're switching the drm subsystem from
ref/unref to get/put for more consistency), but oh well, flag days are
not pretty either.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 8/9] v4l: vsp1: Integrate DISCOM in display pipeline

[Laurent Pinchart]

The DISCOM is used to compute CRCs on display frames. Integrate it in
the display pipeline at the output of the blending unit to process
output frames.

Computing CRCs on input frames is possible by positioning the DISCOM at
a different point in the pipeline. This use case isn't supported at the
moment and could be implemented by extending the API between the VSP1
and DU drivers if needed.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 113 +++--
 drivers/media/platform/vsp1/vsp1_drm.h |  12 
 2 files changed, 121 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 97d2be3b0023..bcf30c25ccb3 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -26,6 +26,7 @@
 #include "vsp1_lif.h"
 #include "vsp1_pipe.h"
 #include "vsp1_rwpf.h"
+#include "vsp1_uif.h"
 
 
 /* 
-
@@ -36,9 +37,15 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe,
   bool completed)
 {
struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
+   u32 crc = 0;
 
-   if (drm_pipe->du_complete)
-   drm_pipe->du_complete(drm_pipe->du_private, completed, 0);
+   if (!drm_pipe->du_complete)
+   return;
+
+   if (drm_pipe->uif)
+   crc = vsp1_uif_get_crc(to_uif(_pipe->uif->subdev));
+
+   drm_pipe->du_complete(drm_pipe->du_private, completed, crc);
 }
 
 /* 
-
@@ -393,9 +400,67 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int 
pipe_index,
 }
 EXPORT_SYMBOL_GPL(vsp1_du_atomic_update);
 
+/*
+ * Insert the UIF in the pipeline between the prev and next entities. If no UIF
+ * is available connect the two entities directly.
+ */
+static int vsp1_du_insert_uif(struct vsp1_device *vsp1,
+ struct vsp1_pipeline *pipe,
+ struct vsp1_entity *uif,
+ struct vsp1_entity *prev, unsigned int prev_pad,
+ struct vsp1_entity *next, unsigned int next_pad)
+{
+   int ret;
+
+   if (uif) {
+   struct v4l2_subdev_format format;
+
+   prev->sink = uif;
+   prev->sink_pad = UIF_PAD_SINK;
+
+   memset(, 0, sizeof(format));
+   format.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+   format.pad = prev_pad;
+
+   ret = v4l2_subdev_call(>subdev, pad, get_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   format.pad = UIF_PAD_SINK;
+
+   ret = v4l2_subdev_call(>subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on UIF sink\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code);
+
+   /*
+* The UIF doesn't mangle the format between its sink and
+* source pads, so there is no need to retrieve the format on
+* its source pad.
+*/
+
+   uif->sink = next;
+   uif->sink_pad = next_pad;
+
+   list_add_tail(>list_pipe, >entities);
+   } else {
+   prev->sink = next;
+   prev->sink_pad = next_pad;
+   }
+
+   return 0;
+}
+
 static int vsp1_du_setup_rpf_pipe(struct vsp1_device *vsp1,
  struct vsp1_pipeline *pipe,
- struct vsp1_rwpf *rpf, unsigned int bru_input)
+ struct vsp1_rwpf *rpf,
+ struct vsp1_entity *uif,
+ unsigned int bru_input)
 {
struct v4l2_subdev_selection sel;
struct v4l2_subdev_format format;
@@ -468,6 +533,12 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device *vsp1,
if (ret < 0)
return ret;
 
+   /* Insert and configure the UIF if available. */
+   ret = vsp1_du_insert_uif(vsp1, pipe, uif, >entity, RWPF_PAD_SOURCE,
+pipe->bru, bru_input);
+   if (ret < 0)
+   return ret;
+
/* BRU sink, propagate the format from the RPF source. */
format.pad = bru_input;
 
@@ -517,6 +588,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index,
struct vsp1_bru *bru = to_bru(>bru->subdev);
struct vsp1_entity *entity;
struct vsp1_entity *next;
+   struct vsp1_entity *uif;
struct vsp1_dl_list *dl;

[PATCH 3/9] v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code

[Laurent Pinchart]

The implementation of the set_fmt pad operation is identical in the
three modules. Move it to a generic helper function.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_clu.c| 65 +--
 drivers/media/platform/vsp1/vsp1_entity.c | 75 +++
 drivers/media/platform/vsp1/vsp1_entity.h |  6 +++
 drivers/media/platform/vsp1/vsp1_lif.c| 65 +--
 drivers/media/platform/vsp1/vsp1_lut.c| 65 +--
 5 files changed, 116 insertions(+), 160 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index f2fb26e5ab4e..bc931a3ab498 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -118,18 +118,18 @@ static const struct v4l2_ctrl_config clu_mode_control = {
  * V4L2 Subdevice Pad Operations
  */
 
+static const unsigned int clu_codes[] = {
+   MEDIA_BUS_FMT_ARGB_1X32,
+   MEDIA_BUS_FMT_AHSV_1X32,
+   MEDIA_BUS_FMT_AYUV8_1X32,
+};
+
 static int clu_enum_mbus_code(struct v4l2_subdev *subdev,
  struct v4l2_subdev_pad_config *cfg,
  struct v4l2_subdev_mbus_code_enum *code)
 {
-   static const unsigned int codes[] = {
-   MEDIA_BUS_FMT_ARGB_1X32,
-   MEDIA_BUS_FMT_AHSV_1X32,
-   MEDIA_BUS_FMT_AYUV8_1X32,
-   };
-
-   return vsp1_subdev_enum_mbus_code(subdev, cfg, code, codes,
- ARRAY_SIZE(codes));
+   return vsp1_subdev_enum_mbus_code(subdev, cfg, code, clu_codes,
+ ARRAY_SIZE(clu_codes));
 }
 
 static int clu_enum_frame_size(struct v4l2_subdev *subdev,
@@ -145,51 +145,10 @@ static int clu_set_format(struct v4l2_subdev *subdev,
  struct v4l2_subdev_pad_config *cfg,
  struct v4l2_subdev_format *fmt)
 {
-   struct vsp1_clu *clu = to_clu(subdev);
-   struct v4l2_subdev_pad_config *config;
-   struct v4l2_mbus_framefmt *format;
-   int ret = 0;
-
-   mutex_lock(>entity.lock);
-
-   config = vsp1_entity_get_pad_config(>entity, cfg, fmt->which);
-   if (!config) {
-   ret = -EINVAL;
-   goto done;
-   }
-
-   /* Default to YUV if the requested format is not supported. */
-   if (fmt->format.code != MEDIA_BUS_FMT_ARGB_1X32 &&
-   fmt->format.code != MEDIA_BUS_FMT_AHSV_1X32 &&
-   fmt->format.code != MEDIA_BUS_FMT_AYUV8_1X32)
-   fmt->format.code = MEDIA_BUS_FMT_AYUV8_1X32;
-
-   format = vsp1_entity_get_pad_format(>entity, config, fmt->pad);
-
-   if (fmt->pad == CLU_PAD_SOURCE) {
-   /* The CLU output format can't be modified. */
-   fmt->format = *format;
-   goto done;
-   }
-
-   format->code = fmt->format.code;
-   format->width = clamp_t(unsigned int, fmt->format.width,
-   CLU_MIN_SIZE, CLU_MAX_SIZE);
-   format->height = clamp_t(unsigned int, fmt->format.height,
-CLU_MIN_SIZE, CLU_MAX_SIZE);
-   format->field = V4L2_FIELD_NONE;
-   format->colorspace = V4L2_COLORSPACE_SRGB;
-
-   fmt->format = *format;
-
-   /* Propagate the format to the source pad. */
-   format = vsp1_entity_get_pad_format(>entity, config,
-   CLU_PAD_SOURCE);
-   *format = fmt->format;
-
-done:
-   mutex_unlock(>entity.lock);
-   return ret;
+   return vsp1_subdev_set_pad_format(subdev, cfg, fmt, clu_codes,
+ ARRAY_SIZE(clu_codes),
+ CLU_MIN_SIZE, CLU_MIN_SIZE,
+ CLU_MAX_SIZE, CLU_MAX_SIZE);
 }
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_entity.c 
b/drivers/media/platform/vsp1/vsp1_entity.c
index 54de15095709..0fa310f1a8d1 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.c
+++ b/drivers/media/platform/vsp1/vsp1_entity.c
@@ -311,6 +311,81 @@ int vsp1_subdev_enum_frame_size(struct v4l2_subdev *subdev,
return ret;
 }
 
+/*
+ * vsp1_subdev_set_pad_format - Subdev pad set_fmt handler
+ * @subdev: V4L2 subdevice
+ * @cfg: V4L2 subdev pad configuration
+ * @fmt: V4L2 subdev format
+ * @codes: Array of supported media bus codes
+ * @ncodes: Number of supported media bus codes
+ * @min_width: Minimum image width
+ * @min_height: Minimum image height
+ * @max_width: Maximum image width
+ * @max_height: Maximum image height
+ *
+ * This function implements the subdev set_fmt pad operation for entities that
+ * do not support scaling or cropping. It defaults to the first supplied media
+ * bus code if the requested code isn't supported, 

[PATCH 4/9] v4l: vsp1: Reset the crop and compose rectangles in the set_fmt helper

[Laurent Pinchart]

To make vsp1_subdev_set_pad_format() usable by entities that support
selection rectangles, we need to reset the crop and compose rectangles
when setting the format on the sink pad. Do so and replace the custom
set_fmt implementation of the histogram code by a call to
vsp1_subdev_set_pad_format().

Resetting the crop and compose rectangles for entities that don't
support crop and compose has no adverse effect as the rectangles are
ignored anyway.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_entity.c | 16 +
 drivers/media/platform/vsp1/vsp1_histo.c  | 59 +++
 2 files changed, 20 insertions(+), 55 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_entity.c 
b/drivers/media/platform/vsp1/vsp1_entity.c
index 0fa310f1a8d1..b92d3985ae47 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.c
+++ b/drivers/media/platform/vsp1/vsp1_entity.c
@@ -339,6 +339,7 @@ int vsp1_subdev_set_pad_format(struct v4l2_subdev *subdev,
struct vsp1_entity *entity = to_vsp1_entity(subdev);
struct v4l2_subdev_pad_config *config;
struct v4l2_mbus_framefmt *format;
+   struct v4l2_rect *selection;
unsigned int i;
int ret = 0;
 
@@ -381,6 +382,21 @@ int vsp1_subdev_set_pad_format(struct v4l2_subdev *subdev,
format = vsp1_entity_get_pad_format(entity, config, 1);
*format = fmt->format;
 
+   /* Reset the crop and compose rectangles */
+   selection = vsp1_entity_get_pad_selection(entity, config, fmt->pad,
+ V4L2_SEL_TGT_CROP);
+   selection->left = 0;
+   selection->top = 0;
+   selection->width = format->width;
+   selection->height = format->height;
+
+   selection = vsp1_entity_get_pad_selection(entity, config, fmt->pad,
+ V4L2_SEL_TGT_COMPOSE);
+   selection->left = 0;
+   selection->top = 0;
+   selection->width = format->width;
+   selection->height = format->height;
+
 done:
mutex_unlock(>lock);
return ret;
diff --git a/drivers/media/platform/vsp1/vsp1_histo.c 
b/drivers/media/platform/vsp1/vsp1_histo.c
index afab77cf4fa5..f470626cb601 100644
--- a/drivers/media/platform/vsp1/vsp1_histo.c
+++ b/drivers/media/platform/vsp1/vsp1_histo.c
@@ -393,65 +393,14 @@ static int histo_set_format(struct v4l2_subdev *subdev,
struct v4l2_subdev_format *fmt)
 {
struct vsp1_histogram *histo = subdev_to_histo(subdev);
-   struct v4l2_subdev_pad_config *config;
-   struct v4l2_mbus_framefmt *format;
-   struct v4l2_rect *selection;
-   unsigned int i;
-   int ret = 0;
 
if (fmt->pad != HISTO_PAD_SINK)
return histo_get_format(subdev, cfg, fmt);
 
-   mutex_lock(>entity.lock);
-
-   config = vsp1_entity_get_pad_config(>entity, cfg, fmt->which);
-   if (!config) {
-   ret = -EINVAL;
-   goto done;
-   }
-
-   /*
-* Default to the first format if the requested format is not
-* supported.
-*/
-   for (i = 0; i < histo->num_formats; ++i) {
-   if (fmt->format.code == histo->formats[i])
-   break;
-   }
-   if (i == histo->num_formats)
-   fmt->format.code = histo->formats[0];
-
-   format = vsp1_entity_get_pad_format(>entity, config, fmt->pad);
-
-   format->code = fmt->format.code;
-   format->width = clamp_t(unsigned int, fmt->format.width,
-   HISTO_MIN_SIZE, HISTO_MAX_SIZE);
-   format->height = clamp_t(unsigned int, fmt->format.height,
-HISTO_MIN_SIZE, HISTO_MAX_SIZE);
-   format->field = V4L2_FIELD_NONE;
-   format->colorspace = V4L2_COLORSPACE_SRGB;
-
-   fmt->format = *format;
-
-   /* Reset the crop and compose rectangles */
-   selection = vsp1_entity_get_pad_selection(>entity, config,
- fmt->pad, V4L2_SEL_TGT_CROP);
-   selection->left = 0;
-   selection->top = 0;
-   selection->width = format->width;
-   selection->height = format->height;
-
-   selection = vsp1_entity_get_pad_selection(>entity, config,
- fmt->pad,
- V4L2_SEL_TGT_COMPOSE);
-   selection->left = 0;
-   selection->top = 0;
-   selection->width = format->width;
-   selection->height = format->height;
-
-done:
-   mutex_unlock(>entity.lock);
-   return ret;
+   return vsp1_subdev_set_pad_format(subdev, cfg, fmt,
+ histo->formats, histo->num_formats,
+ HISTO_MIN_SIZE, HISTO_MIN_SIZE,
+ HISTO_MAX_SIZE, HISTO_MAX_SIZE);
 }
 
 static const struct 

[PATCH 9/9] drm: rcar-du: Add support for CRC computation

[Laurent Pinchart]

Implement CRC computation configuration and reporting through the DRM
debugfs-based CRC API. The CRC source can be configured to any input
plane or the pipeline output.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 148 +++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  19 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |   7 ++
 3 files changed, 168 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 5685d5af6998..b65750096090 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -650,6 +650,52 @@ static const struct drm_crtc_helper_funcs 
crtc_helper_funcs = {
.atomic_disable = rcar_du_crtc_atomic_disable,
 };
 
+static struct drm_crtc_state *
+rcar_du_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
+{
+   struct rcar_du_crtc_state *state;
+   struct rcar_du_crtc_state *copy;
+
+   if (WARN_ON(!crtc->state))
+   return NULL;
+
+   state = to_rcar_crtc_state(crtc->state);
+   copy = kmemdup(state, sizeof(*state), GFP_KERNEL);
+   if (copy == NULL)
+   return NULL;
+
+   __drm_atomic_helper_crtc_duplicate_state(crtc, >state);
+
+   return >state;
+}
+
+static void rcar_du_crtc_atomic_destroy_state(struct drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+   __drm_atomic_helper_crtc_destroy_state(state);
+   kfree(to_rcar_crtc_state(state));
+}
+
+static void rcar_du_crtc_reset(struct drm_crtc *crtc)
+{
+   struct rcar_du_crtc_state *state;
+
+   if (crtc->state) {
+   rcar_du_crtc_atomic_destroy_state(crtc, crtc->state);
+   crtc->state = NULL;
+   }
+
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
+   if (state == NULL)
+   return;
+
+   state->crc.source = VSP1_DU_CRC_NONE;
+   state->crc.index = 0;
+
+   crtc->state = >state;
+   crtc->state->crtc = crtc;
+}
+
 static int rcar_du_crtc_enable_vblank(struct drm_crtc *crtc)
 {
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
@@ -669,15 +715,103 @@ static void rcar_du_crtc_disable_vblank(struct drm_crtc 
*crtc)
rcrtc->vblank_enable = false;
 }
 
-static const struct drm_crtc_funcs crtc_funcs = {
-   .reset = drm_atomic_helper_crtc_reset,
+static int rcar_du_crtc_set_crc_source(struct drm_crtc *crtc,
+  const char *source_name,
+  size_t *values_cnt)
+{
+   struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+   struct drm_modeset_acquire_ctx ctx;
+   struct drm_crtc_state *crtc_state;
+   struct drm_atomic_state *state;
+   enum vsp1_du_crc_source source;
+   unsigned int index;
+   int ret;
+
+   /*
+* Parse the source name. Supported values are "plane%u" to compute the
+* CRC on an input plane (%u is the plane index), and "auto" to compute
+* the CRC on the composer (VSP) output.
+*/
+   if (!source_name) {
+   source = VSP1_DU_CRC_NONE;
+   } else if (!strcmp(source_name, "auto")) {
+   source = VSP1_DU_CRC_OUTPUT;
+   } else if (strstarts(source_name, "plane")) {
+   source = VSP1_DU_CRC_PLANE;
+
+   ret = kstrtouint(source_name + strlen("plane"), 10, );
+   if (ret < 0)
+   return ret;
+
+   if (index >= rcrtc->vsp->num_planes)
+   return -EINVAL;
+   } else {
+   return -EINVAL;
+   }
+
+   *values_cnt = 1;
+
+   /* Perform an atomic commit to set the CRC source. */
+   drm_modeset_acquire_init(, 0);
+
+   state = drm_atomic_state_alloc(crtc->dev);
+   if (!state) {
+   ret = -ENOMEM;
+   goto unlock;
+   }
+
+   state->acquire_ctx = 
+
+retry:
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (!IS_ERR(crtc_state)) {
+   struct rcar_du_crtc_state *rcrtc_state;
+
+   rcrtc_state = to_rcar_crtc_state(crtc_state);
+   rcrtc_state->crc.source = source;
+   rcrtc_state->crc.index = index;
+
+   ret = drm_atomic_commit(state);
+   } else {
+   ret = PTR_ERR(crtc_state);
+   }
+
+   if (ret == -EDEADLK) {
+   drm_atomic_state_clear(state);
+   drm_modeset_backoff();
+   goto retry;
+   }
+
+   drm_atomic_state_put(state);
+
+unlock:
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+
+   return 0;
+}
+
+static const struct drm_crtc_funcs crtc_funcs_gen2 = {
+   .reset = rcar_du_crtc_reset,
+   .destroy = drm_crtc_cleanup,
+   .set_config = drm_atomic_helper_set_config,
+   .page_flip = drm_atomic_helper_page_flip,
+   

[PATCH 7/9] v4l: vsp1: Add support for the DISCOM entity

[Laurent Pinchart]

The DISCOM calculates a CRC on a configurable window of the frame. It
interfaces to the VSP through the UIF glue, hence the name used in the
code.

The module supports configuration of the CRC window through the crop
rectangle on the ink pad of the corresponding entity. However, unlike
the traditional V4L2 subdevice model, the crop rectangle does not
influence the format on the source pad.

Modeling the DISCOM as a sink-only entity would allow adhering to the
V4L2 subdevice model at the expense of more complex code in the driver,
as at the hardware level the UIF is handled as a sink+source entity. As
the DISCOM is only present in R-Car Gen3 VSP-D and VSP-DL instances it
is not exposed to userspace through V4L2 but controlled through the DU
driver. We can thus change this model later if needed without fear of
affecting userspace.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/Makefile  |   2 +-
 drivers/media/platform/vsp1/vsp1.h|   4 +
 drivers/media/platform/vsp1/vsp1_drv.c|  20 +++
 drivers/media/platform/vsp1/vsp1_entity.c |   6 +
 drivers/media/platform/vsp1/vsp1_entity.h |   1 +
 drivers/media/platform/vsp1/vsp1_regs.h   |  41 +
 drivers/media/platform/vsp1/vsp1_uif.c| 275 ++
 drivers/media/platform/vsp1/vsp1_uif.h|  36 
 8 files changed, 384 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/vsp1/vsp1_uif.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_uif.h

diff --git a/drivers/media/platform/vsp1/Makefile 
b/drivers/media/platform/vsp1/Makefile
index f5cd6f0491cb..3c73dd0cc898 100644
--- a/drivers/media/platform/vsp1/Makefile
+++ b/drivers/media/platform/vsp1/Makefile
@@ -5,6 +5,6 @@ vsp1-y  += vsp1_rpf.o 
vsp1_rwpf.o vsp1_wpf.o
 vsp1-y += vsp1_clu.o vsp1_hsit.o vsp1_lut.o
 vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o
 vsp1-y += vsp1_hgo.o vsp1_hgt.o vsp1_histo.o
-vsp1-y += vsp1_lif.o
+vsp1-y += vsp1_lif.o vsp1_uif.o
 
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1.o
diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 78ef838416b3..6f0b6baf125a 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -40,10 +40,12 @@ struct vsp1_lut;
 struct vsp1_rwpf;
 struct vsp1_sru;
 struct vsp1_uds;
+struct vsp1_uif;
 
 #define VSP1_MAX_LIF   2
 #define VSP1_MAX_RPF   5
 #define VSP1_MAX_UDS   3
+#define VSP1_MAX_UIF   2
 #define VSP1_MAX_WPF   4
 
 #define VSP1_HAS_LUT   (1 << 1)
@@ -64,6 +66,7 @@ struct vsp1_device_info {
unsigned int lif_count;
unsigned int rpf_count;
unsigned int uds_count;
+   unsigned int uif_count;
unsigned int wpf_count;
unsigned int num_bru_inputs;
bool uapi;
@@ -90,6 +93,7 @@ struct vsp1_device {
struct vsp1_rwpf *rpf[VSP1_MAX_RPF];
struct vsp1_sru *sru;
struct vsp1_uds *uds[VSP1_MAX_UDS];
+   struct vsp1_uif *uif[VSP1_MAX_UIF];
struct vsp1_rwpf *wpf[VSP1_MAX_WPF];
 
struct list_head entities;
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 962e4c304076..b1e360ebb587 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -39,6 +39,7 @@
 #include "vsp1_rwpf.h"
 #include "vsp1_sru.h"
 #include "vsp1_uds.h"
+#include "vsp1_uif.h"
 #include "vsp1_video.h"
 
 /* 
-
@@ -413,6 +414,19 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
list_add_tail(>entity.list_dev, >entities);
}
 
+   for (i = 0; i < vsp1->info->uif_count; ++i) {
+   struct vsp1_uif *uif;
+
+   uif = vsp1_uif_create(vsp1, i);
+   if (IS_ERR(uif)) {
+   ret = PTR_ERR(uif);
+   goto done;
+   }
+
+   vsp1->uif[i] = uif;
+   list_add_tail(>entity.list_dev, >entities);
+   }
+
for (i = 0; i < vsp1->info->wpf_count; ++i) {
struct vsp1_rwpf *wpf;
 
@@ -517,6 +531,9 @@ static int vsp1_device_init(struct vsp1_device *vsp1)
for (i = 0; i < vsp1->info->uds_count; ++i)
vsp1_write(vsp1, VI6_DPR_UDS_ROUTE(i), VI6_DPR_NODE_UNUSED);
 
+   for (i = 0; i < vsp1->info->uif_count; ++i)
+   vsp1_write(vsp1, VI6_DPR_UIF_ROUTE(i), VI6_DPR_NODE_UNUSED);
+
vsp1_write(vsp1, VI6_DPR_SRU_ROUTE, VI6_DPR_NODE_UNUSED);
vsp1_write(vsp1, VI6_DPR_LUT_ROUTE, VI6_DPR_NODE_UNUSED);
vsp1_write(vsp1, VI6_DPR_CLU_ROUTE, VI6_DPR_NODE_UNUSED);
@@ -732,6 +749,7 @@ static const struct vsp1_device_info 

[PATCH 0/9] R-Car DU: Support CRC calculation

[Laurent Pinchart]

Hello,

This patch series adds support for CRC calculation to the rcar-du-drm driver.

CRC calculation is supported starting at the Renesas R-Car Gen3 SoCs, as
earlier versions don't have the necessary hardware. On Gen3 SoCs, the CRC is
computed by the DISCOM module part of the VSP-D and VSP-DL.

The DISCOM is interfaced to the VSP through the UIF glue and appears as a VSP
entity with a sink pad and a source pad.

The series starts with two fixes. Patch 1/9 fixes a display stall when
requesting more than two planes from the VGA output. It is a temporary fix to
avoid complete stalls during unit testing, and a better fix will follow but
will take longer to develop. Patch 2/9 then fixes debug messages that confused
me when I was debugging the rest of this patch series.

The series then continues with cleanup and refactoring. Patches 3/9 and 4/9
prepare for DISCOM and UIF support by extending generic code to make it usable
for the UIF. Patch 5/9 documents a structure that will receive new fields.

Patch 6/9 then extends the API exposed by the VSP driver to the DU driver to
support CRC computation configuration and reporting. The patch unfortunately
needs to touch both the VSP and DU drivers. The whole series will need to be
merged through a single tree, I will check when it will be time to submit a
pull request which option would generate the least conflicts.

Patch 7/9 adds support for the DISCOM and UIF in the VSP driver, patch 8/9
integrates it in the DRM pipeline, and patch 9/9 finally implements the CRC
API in the DU driver to expose CRC computation to userspace.

The hardware supports computing the CRC at any arbitrary point in the
pipeline on a configurable window of the frame. This patch series supports CRC
computation on input planes or pipeline output, but on the full frame only.
Support for CRC window configuration can be added later if needed but will
require extending the userspace API, as the DRM/KMS CRC API doesn't support
this feature.

Note that exposing the DISCOM and UIF though the V4L2 API isn't supported as
the module is only found in VSP-D and VSP-DL instances that are not exposed
through V4L2. It is possible to expose those instances through V4L2 with a
small modification to the driver for testing purpose. If the need arises to
test DISCOM and UIF with such an out-of-tree patch, support for CRC reporting
through a V4L2 control can be added later without affecting how CRC is exposed
through the DRM/KMS API.

The patches are based on top of a merge of the Linux media master branch and
the pending DU patches. For convenience they are available at

git://linuxtv.org/pinchartl/media.git vsp1-discom-v1-20171203

The code has been tested through the kms-test-crc.py script part of the DU
test suite available at

git://git.ideasonboard.com/renesas/kms-tests.git discom


Laurent Pinchart (9):
  v4l: vsp1: Fix display stalls when requesting too many inputs
  v4l: vsp1: Print the correct blending unit name in debug messages
  v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code
  v4l: vsp1: Reset the crop and compose rectangles in the set_fmt helper
  v4l: vsp1: Document the vsp1_du_atomic_config structure
  v4l: vsp1: Extend the DU API to support CRC computation
  v4l: vsp1: Add support for the DISCOM entity
  v4l: vsp1: Integrate DISCOM in display pipeline
  drm: rcar-du: Add support for CRC computation

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 148 +++-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h|  19 +++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c |  13 +-
 drivers/media/platform/vsp1/Makefile  |   2 +-
 drivers/media/platform/vsp1/vsp1.h|   4 +
 drivers/media/platform/vsp1/vsp1_clu.c|  65 ++-
 drivers/media/platform/vsp1/vsp1_drm.c| 138 +--
 drivers/media/platform/vsp1/vsp1_drm.h|  14 +-
 drivers/media/platform/vsp1/vsp1_drv.c|  20 +++
 drivers/media/platform/vsp1/vsp1_entity.c |  97 +++
 drivers/media/platform/vsp1/vsp1_entity.h |   7 +
 drivers/media/platform/vsp1/vsp1_histo.c  |  59 +--
 drivers/media/platform/vsp1/vsp1_lif.c|  65 ++-
 drivers/media/platform/vsp1/vsp1_lut.c|  65 ++-
 drivers/media/platform/vsp1/vsp1_regs.h   |  41 +
 drivers/media/platform/vsp1/vsp1_uif.c| 275 ++
 drivers/media/platform/vsp1/vsp1_uif.h|  36 
 include/media/vsp1.h  |  39 -
 18 files changed, 870 insertions(+), 237 deletions(-)
 create mode 100644 drivers/media/platform/vsp1/vsp1_uif.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_uif.h

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/9] v4l: vsp1: Extend the DU API to support CRC computation

[Laurent Pinchart]

Add a parameter (in the form of a structure to ease future API
extensions) to the VSP atomic flush handler to pass CRC source
configuration, and pass the CRC value to the completion callback.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |  6 --
 drivers/media/platform/vsp1/vsp1_drm.c |  6 --
 drivers/media/platform/vsp1/vsp1_drm.h |  2 +-
 include/media/vsp1.h   | 29 +++--
 4 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 2c260c33840b..bdcec201591f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -31,7 +31,7 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_vsp.h"
 
-static void rcar_du_vsp_complete(void *private, bool completed)
+static void rcar_du_vsp_complete(void *private, bool completed, u32 crc)
 {
struct rcar_du_crtc *crtc = private;
 
@@ -102,7 +102,9 @@ void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
 
 void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
 {
-   vsp1_du_atomic_flush(crtc->vsp->vsp, crtc->vsp_pipe);
+   struct vsp1_du_atomic_pipe_config cfg = { { 0, } };
+
+   vsp1_du_atomic_flush(crtc->vsp->vsp, crtc->vsp_pipe, );
 }
 
 /* Keep the two tables in sync. */
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 0fe541084f5c..97d2be3b0023 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -38,7 +38,7 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe,
struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
 
if (drm_pipe->du_complete)
-   drm_pipe->du_complete(drm_pipe->du_private, completed);
+   drm_pipe->du_complete(drm_pipe->du_private, completed, 0);
 }
 
 /* 
-
@@ -505,8 +505,10 @@ static unsigned int rpf_zpos(struct vsp1_device *vsp1, 
struct vsp1_rwpf *rpf)
  * vsp1_du_atomic_flush - Commit an atomic update
  * @dev: the VSP device
  * @pipe_index: the DRM pipeline index
+ * @cfg: atomic pipe configuration
  */
-void vsp1_du_atomic_flush(struct device *dev, unsigned int pipe_index)
+void vsp1_du_atomic_flush(struct device *dev, unsigned int pipe_index,
+ const struct vsp1_du_atomic_pipe_config *cfg)
 {
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
struct vsp1_drm_pipeline *drm_pipe = >drm->pipe[pipe_index];
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index 1cd9db785bf7..c6515272da7d 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -29,7 +29,7 @@ struct vsp1_drm_pipeline {
bool enabled;
 
/* Frame synchronisation */
-   void (*du_complete)(void *, bool);
+   void (*du_complete)(void *data, bool completed, u32 crc);
void *du_private;
 };
 
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 7850f96fb708..89af1606ecb3 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -34,7 +34,7 @@ struct vsp1_du_lif_config {
unsigned int width;
unsigned int height;
 
-   void (*callback)(void *, bool);
+   void (*callback)(void *data, bool completed, u32 crc);
void *callback_data;
 };
 
@@ -61,11 +61,36 @@ struct vsp1_du_atomic_config {
unsigned int zpos;
 };
 
+/**
+ * enum vsp1_du_crc_source - Source used for CRC calculation
+ * @VSP1_DU_CRC_NONE: CRC calculation disabled
+ * @VSP_DU_CRC_PLANE: Perform CRC calculation on an input plane
+ * @VSP_DU_CRC_OUTPUT: Perform CRC calculation on the composed output
+ */
+enum vsp1_du_crc_source {
+   VSP1_DU_CRC_NONE,
+   VSP1_DU_CRC_PLANE,
+   VSP1_DU_CRC_OUTPUT,
+};
+
+/**
+ * struct vsp1_du_atomic_pipe_config - VSP atomic pipe configuration parameters
+ * @crc.source: source for CRC calculation
+ * @crc.index: index of the CRC source plane (when crc.source is set to plane)
+ */
+struct vsp1_du_atomic_pipe_config {
+   struct  {
+   enum vsp1_du_crc_source source;
+   unsigned int index;
+   } crc;
+};
+
 void vsp1_du_atomic_begin(struct device *dev, unsigned int pipe_index);
 int vsp1_du_atomic_update(struct device *dev, unsigned int pipe_index,
  unsigned int rpf,
  const struct vsp1_du_atomic_config *cfg);
-void vsp1_du_atomic_flush(struct device *dev, unsigned int pipe_index);
+void vsp1_du_atomic_flush(struct device *dev, unsigned int pipe_index,
+ const struct vsp1_du_atomic_pipe_config *cfg);
 int vsp1_du_map_sg(struct device *dev, struct sg_table *sgt);
 void vsp1_du_unmap_sg(struct device *dev, struct sg_table *sgt);
 
-- 
Regards,

Laurent Pinchart

[PATCH 5/9] v4l: vsp1: Document the vsp1_du_atomic_config structure

[Laurent Pinchart]

The structure is used in the API that the VSP1 driver exposes to the DU
driver. Documenting it is thus important.

Signed-off-by: Laurent Pinchart 
---
 include/media/vsp1.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 68a8abe4fac5..7850f96fb708 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -41,6 +41,16 @@ struct vsp1_du_lif_config {
 int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
  const struct vsp1_du_lif_config *cfg);
 
+/**
+ * struct vsp1_du_atomic_config - VSP atomic configuration parameters
+ * @pixelformat: plan pixel format (V4L2 4CC)
+ * @pitch: line pitch in bytes, for all planes
+ * @mem: DMA memory address for each plane of the frame buffer
+ * @src: source rectangle in the frame buffer (integer coordinates)
+ * @dst: destination rectangle on the display (integer coordinates)
+ * @alpha: alpha value (0: fully transparent, 255: fully opaque)
+ * @zpos: Z position of the plane (from 0 to number of planes minus 1)
+ */
 struct vsp1_du_atomic_config {
u32 pixelformat;
unsigned int pitch;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/9] v4l: vsp1: Fix display stalls when requesting too many inputs

[Laurent Pinchart]

Make sure we don't accept more inputs than the hardware can handle. This
is a temporary fix to avoid display stall, we need to instead allocate
the BRU or BRS to display pipelines dynamically based on the number of
planes they each use.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 7ce69f23f50a..ac85942162c1 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -530,6 +530,15 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
struct vsp1_rwpf *rpf = vsp1->rpf[i];
unsigned int j;
 
+   /*
+* Make sure we don't accept more inputs than the hardware can
+* handle. This is a temporary fix to avoid display stall, we
+* need to instead allocate the BRU or BRS to display pipelines
+* dynamically based on the number of planes they each use.
+*/
+   if (pipe->num_inputs >= pipe->bru->source_pad)
+   pipe->inputs[i] = NULL;
+
if (!pipe->inputs[i])
continue;
 
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/9] v4l: vsp1: Print the correct blending unit name in debug messages

[Laurent Pinchart]

The DRM pipelines can use either the BRU or the BRS for blending. Make
sure the right name is used in debugging messages to avoid confusion.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index ac85942162c1..0fe541084f5c 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -400,8 +400,11 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device *vsp1,
struct v4l2_subdev_selection sel;
struct v4l2_subdev_format format;
const struct v4l2_rect *crop;
+   const char *bru_name;
int ret;
 
+   bru_name = pipe->bru->type == VSP1_ENTITY_BRU ? "BRU" : "BRS";
+
/*
 * Configure the format on the RPF sink pad and propagate it up to the
 * BRU sink pad.
@@ -473,9 +476,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device *vsp1,
if (ret < 0)
return ret;
 
-   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on BRU pad %u\n",
+   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
__func__, format.format.width, format.format.height,
-   format.format.code, format.pad);
+   format.format.code, bru_name, format.pad);
 
sel.pad = bru_input;
sel.target = V4L2_SEL_TGT_COMPOSE;
@@ -486,10 +489,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device *vsp1,
if (ret < 0)
return ret;
 
-   dev_dbg(vsp1->dev,
-   "%s: set selection (%u,%u)/%ux%u on BRU pad %u\n",
+   dev_dbg(vsp1->dev, "%s: set selection (%u,%u)/%ux%u on %s pad %u\n",
__func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
-   sel.pad);
+   bru_name, sel.pad);
 
return 0;
 }
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel