[PATCH] drm/atomic: Add new reverse iterator over all plane state (V2)

[S, Shirish]

From: Shirish S 

Add reverse iterator for_each_oldnew_plane_in_state_reverse to compliment the 
for_each_oldnew_plane_in_state way or reading plane states.

The plane states are required to be read in reverse order for amd drivers, 
cause the z order convention followed in linux is opposite to how the planes 
are supposed to be presented to DC engine, which is in common to both windows 
and linux.

V2: fix compile time errors due to -Werror flag.

Signed-off-by: Shirish S 
Signed-off-by: Pratik Vishwakarma 
---
 include/drm/drm_atomic.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index 
cf13842..3fe8dde 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -754,6 +754,28 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
  (new_plane_state) = 
(__state)->planes[__i].new_state, 1))
 
 /**
+ * for_each_oldnew_plane_in_state_reverse - iterate over all planes in 
+an atomic
+ * update in reverse order
+ * @__state:  drm_atomic_state pointer
+ * @plane:  drm_plane iteration cursor
+ * @old_plane_state:  drm_plane_state iteration cursor for the 
+old state
+ * @new_plane_state:  drm_plane_state iteration cursor for the 
+new state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all planes in an atomic update in reverse order,
+ * tracking both old and  new state. This is useful in places where the
+ * state delta needs to be considered, for example in atomic check functions.
+ */
+#define for_each_oldnew_plane_in_state_reverse(__state, plane, 
old_plane_state, new_plane_state, __i) \
+   for ((__i) = ((__state)->dev->mode_config.num_total_plane - 1); \
+(__i) >= 0;\
+(__i)--)   \
+   for_each_if ((__state)->planes[__i].ptr &&  \
+((plane) = (__state)->planes[__i].ptr, \
+ (old_plane_state) = 
(__state)->planes[__i].old_state,\
+ (new_plane_state) = 
(__state)->planes[__i].new_state, 1))
+
+/**
  * for_each_old_plane_in_state - iterate over all planes in an atomic update
  * @__state:  drm_atomic_state pointer
  * @plane:  drm_plane iteration cursor
--
2.7.4

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

Re: [PATCH v4 6/6] drm/omap: Use normalized zpos for plane placement

[Tomi Valkeinen]

On 06/02/18 14:05, Peter Ujfalusi wrote:
> Planes with identical zpos value will result undefined behavior:
> disappearing planes, screen flickering and it is not supported by the
> hardware.
> 
> Use normalized zpos to make sure that we don't encounter invalid
> configuration.
> 
> Signed-off-by: Peter Ujfalusi 
> CC: Tomi Valkeinen 
> Acked-by: Daniel Vetter 

Reviewed-by: Tomi Valkeinen 

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 17/17] drm/omap: cleanup color space conversion

[Tomi Valkeinen]

On 28/02/18 23:23, Laurent Pinchart wrote:

>> +REG_FLD_MOD(dispc, DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 
>> 11);
> 
> I think I mentioned in my review of v1 that you can drop the !!. Apart from 
> that,
> 
> Reviewed-by: Laurent Pinchart 

Sorry about. I did remove it, but I made a few versions of the change,
and apparently missed this in the final one. Now it's gone.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105302] [DC] - Maximum pixel clock of dual-link DVI too low for some modes

[bugzilla-daemon]

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

Bug ID: 105302
   Summary: [DC] - Maximum pixel clock of dual-link DVI too low
for some modes
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: asheldo...@gmail.com

I have a monitor that supports 2560x1440 >60hz (up to around 110hz) through the
DVI-D interface but requires pixel clocks greater than the current dual-link
limit of 330khz, with amdgpu.dc=1. Setting TMDS_MAX_PIXEL_CLOCK to 25 in
signal_types.h works around the problem. 

amdgpu.dc=0 doesn't appear to have this limit (or the value is higher) so the
problem does not exist there.

I'm using ~ag5df's drm-next-4.17-wip branch.

There appears to be a discussion about setting a higher pixel clock limit in
this bug: https://bugs.freedesktop.org/show_bug.cgi?id=93885 but focused on
HDMI and not DVI-D, and regarding the older radeon driver.

-- 
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 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

[bugzilla-daemon]

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

--- Comment #24 from mikhail.v.gavri...@gmail.com ---
Created attachment 137710
  --> https://bugs.freedesktop.org/attachment.cgi?id=137710=edit
photo of test when computer is hang

-- 
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 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

[bugzilla-daemon]

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

--- Comment #23 from mikhail.v.gavri...@gmail.com ---
Found you another crash case:

The @GraphicsFuzz demo found 1 issue (14/15 tests passed) on my desktop device,
affecting my @AMD GPU driver Give it a try: www.graphicsfuzz.com/#demo
#GraphicsFuzz

Computer always hangs on shader15

-- 
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: [DPU PATCH 06/11] drm/msm: Remove msm_commit/kthread, use atomic helper commit

[jsanka]

On 2018-02-28 11:19, Sean Paul wrote:

Moving further towards switching fully to the the atomic helpers, this
patch removes the hand-rolled kthread nonblock commit code and uses the
atomic helpers commit_work model.

There's still a lot of copypasta here, but it's still needed to
facilitate the swap_state and prepare_fence private functions. These
will be sorted out in a follow-on patch.

Change-Id: I9fcba27824ba63d3fab96cb2bc194bfa6f3475b7
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/msm_atomic.c | 199 ++-
 drivers/gpu/drm/msm/msm_drv.c|   1 -
 drivers/gpu/drm/msm/msm_drv.h|   4 -
 3 files changed, 35 insertions(+), 169 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c
b/drivers/gpu/drm/msm/msm_atomic.c
index 3a18bd3dc215..7e54eb65d096 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -21,51 +21,6 @@
 #include "msm_gem.h"
 #include "msm_fence.h"

-struct msm_commit {
-   struct drm_device *dev;
-   struct drm_atomic_state *state;
-   uint32_t crtc_mask;
-   bool nonblock;
-   struct kthread_work commit_work;
-};
-
-/* block until specified crtcs are no longer pending update, and
- * atomically mark them as pending update
- */
-static int start_atomic(struct msm_drm_private *priv, uint32_t 
crtc_mask)

-{
-   int ret;
-
-   spin_lock(>pending_crtcs_event.lock);
-   ret = wait_event_interruptible_locked(priv->pending_crtcs_event,
-   !(priv->pending_crtcs & crtc_mask));
-   if (ret == 0) {
-   DBG("start: %08x", crtc_mask);
-   priv->pending_crtcs |= crtc_mask;
-   }
-   spin_unlock(>pending_crtcs_event.lock);
-
-   return ret;
-}
-
-/* clear specified crtcs (no longer pending update)
- */
-static void end_atomic(struct msm_drm_private *priv, uint32_t 
crtc_mask)

-{
-   spin_lock(>pending_crtcs_event.lock);
-   DBG("end: %08x", crtc_mask);
-   priv->pending_crtcs &= ~crtc_mask;
-   wake_up_all_locked(>pending_crtcs_event);
-   spin_unlock(>pending_crtcs_event.lock);
-}
-
-static void commit_destroy(struct msm_commit *c)
-{
-   end_atomic(c->dev->dev_private, c->crtc_mask);
-   if (c->nonblock)
-   kfree(c);
-}
-
 static void msm_atomic_wait_for_commit_done(
struct drm_device *dev,
struct drm_atomic_state *old_state)
@@ -118,6 +73,10 @@ static void msm_atomic_commit_tail(struct
drm_atomic_state *state)

msm_atomic_wait_for_commit_done(dev, state);

+   drm_atomic_helper_commit_hw_done(state);
+
+   drm_atomic_helper_wait_for_vblanks(dev, state);
+
drm_atomic_helper_cleanup_planes(dev, state);

kms->funcs->complete_commit(kms, state);
@@ -126,109 +85,25 @@ static void msm_atomic_commit_tail(struct
drm_atomic_state *state)
 /* The (potentially) asynchronous part of the commit.  At this point
  * nothing can fail short of armageddon.
  */
-static void complete_commit(struct msm_commit *c)
+static void commit_tail(struct drm_atomic_state *state)
 {
-   struct drm_atomic_state *state = c->state;
-   struct drm_device *dev = state->dev;
+   drm_atomic_helper_wait_for_fences(state->dev, state, false);

-   drm_atomic_helper_wait_for_fences(dev, state, false);
+   drm_atomic_helper_wait_for_dependencies(state);

msm_atomic_commit_tail(state);

-   drm_atomic_state_put(state);
-}
-
-static void _msm_drm_commit_work_cb(struct kthread_work *work)
-{
-   struct msm_commit *commit =  NULL;
-
-   if (!work) {
-   DRM_ERROR("%s: Invalid commit work data!\n", __func__);
-   return;
-   }
-
-   commit = container_of(work, struct msm_commit, commit_work);
-
-   complete_commit(commit);
-
-   commit_destroy(commit);
-}
-
-static struct msm_commit *commit_init(struct drm_atomic_state *state,
-   bool nonblock)
-{
-   struct msm_commit *c = kzalloc(sizeof(*c), GFP_KERNEL);
+   drm_atomic_helper_commit_cleanup_done(state);

-   if (!c)
-   return NULL;
-
-   c->dev = state->dev;
-   c->state = state;
-   c->nonblock = nonblock;
-
-   kthread_init_work(>commit_work, _msm_drm_commit_work_cb);
-
-   return c;
+   drm_atomic_state_put(state);
 }

-/* Start display thread function */
-static void msm_atomic_commit_dispatch(struct drm_device *dev,
-   struct drm_atomic_state *state, struct msm_commit *commit)
+static void commit_work(struct work_struct *work)
 {
-   struct msm_drm_private *priv = dev->dev_private;
-   struct drm_crtc *crtc = NULL;
-   struct drm_crtc_state *new_crtc_state = NULL;
-   int ret = -EINVAL, i = 0, j = 0;
-   bool nonblock;
-
-   /* cache since work will kfree commit in non-blocking case */
-   nonblock = commit->nonblock;
-
-   for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
-   for (j = 0; j < 

[Bug 105262] ttf fonts are invisible

[bugzilla-daemon]

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

--- Comment #8 from Pavel Vinogradov  ---
Sorry, no qt stuff here, but I have rxvt-unicode with the same problem. So,
it's not gtk specific.

(In reply to LoneVVolf from comment #5)
> Installed gvim to verify, and that has no menus AND shows no text.
> It looks like both of us have the same issue, but i have an additonal one:
> no text at all in affected programs.
> 
> I'm running archlinux x86_64 with xf86-video-ati on an AMD HD 4870.
> xorg 1.19.6, kernel 4.15.5
>  
> programs without text in menus on my system : 
> openbox, lxde, gvim, libreoffice, firefox gtk-filechooser, thunderbird
> gtk-filechooser
> 
> No issues at all in qt programs like lxqt, kwin, gwenview , okular, calligra
> .
> 
> Could you verify whether qt programs have issues ?

-- 
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 105244] NULL dereference during startup of Cape Verde with AMDGPU and GPU passthrough

[bugzilla-daemon]

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

--- Comment #4 from Alex Deucher  ---
SI still uses the legacy dpm code rather than powerplay so it doesn't expose
all the same options as newer chips.  SI also has an older smu implementation
so it has a more limited feature set compared to CI and VI.

-- 
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: [Xen-devel] [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend

[Stefano Stabellini]

On Wed, 28 Feb 2018, Julien Grall wrote:
> (+ Stefano and Wei)
> 
> Hi,
> 
> On 02/27/2018 12:40 PM, Oleksandr Andrushchenko wrote:
> > Please find some more clarifications on VirtIO use with Xen
> > (I would like to thank Xen community for helping with this)
> > 
> > 1. Possible security issues - VirtIO devices are PCI bus masters, thus
> > allowing real device (running, for example, in untrusted driver domain)
> > to get control over guest's memory by writing to its memory
> > 
> > 2. VirtIO currently uses GFNs written into the shared ring, without Xen
> > grants support. This will require generic grant-mapping/sharing layer
> > to be added to VirtIO.

This is important. VirtIO doesn't allow for driver domains (running the
backend inside a virtual machine). 


> > 3. VirtIO requires QEMU PCI emulation for setting up a device. Xen PV (and
> > PVH)
> > domains don't use QEMU for platform emulation in order to reduce attack
> > surface.
> > (PVH is in the process of gaining PCI config space emulation though, but it
> > is
> > optional, not a requirement)
> I don't think the support of PCI configuration space emulation for PVH would
> help there. The plan is to emulate in Xen, QEMU is still out of the equation
> there.

Right: there is no infrastructure to run IO emulation in userspace for
PV, PVH and ARM guests. We do have a QEMU instance running for PV, PVH
and ARM guests but only to implement PV backends, such as the vdispl
backend for example, which are handling asynchronous requests from
frontends using the traditional grant table maps/unmaps.


> > 4. Most of the PV drivers a guest uses at the moment are Xen PV drivers,
> > e.g. net,
> > block, console, so only virtio-gpu will require QEMU to run.
> > Although this use case would work on x86 it will require additional changes
> > to get this running on ARM, which is my target platform.
> 
> All type of guests but x86 HVM are not using QEMU for device emulation.
> 
> I would even be stronger here. Using QEMU would require a significant amount
> of engineering to make it work and increase the cost of safety certification
> for automotive use cases. So IHMO, the Xen PV display solution is the best.
> 
> The protocol was accepted and merged in Xen 4.9. This the standard way to have
> para-virtualized display for guests on Xen. Having the driver merged in Linux
> would help user to get out-of-box display in guest.

That's right. I don't think it really makes sense to introduce virtio
support in Xen on ARM as it is today.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend

[Stefano Stabellini]

Hi all,

just as a clarification, this patch series implements the frontend
driver for the "vdispl" protocol, which was reviewed, approved and
committed in xen.git back in April:

https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/displif.h

As Xen maintainer, if a competing PV DRM protocol proposal will come up,
I'll try to steer it into evolving the existing vdispl protocol, as we
like to have only one protocol per device class.

I am really looking forward to having this driver upstream in Linux.

Thanks Oleksandr!

Cheers,

Stefano

On Wed, 21 Feb 2018, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Hello!
> 
> This patch series adds support for Xen [1] para-virtualized
> frontend display driver. It implements the protocol from
> include/xen/interface/io/displif.h [2].
> Accompanying backend [3] is implemented as a user-space application
> and its helper library [4], capable of running as a Weston client
> or DRM master.
> Configuration of both backend and frontend is done via 
> Xen guest domain configuration options [5].
> 
> ***
> * Driver limitations
> ***
>  1. Configuration options 1.1 (contiguous display buffers) and 2 (backend
> allocated buffers) below are not supported at the same time.
> 
>  2. Only primary plane without additional properties is supported.
> 
>  3. Only one video mode supported which resolution is configured via XenStore.
> 
>  4. All CRTCs operate at fixed frequency of 60Hz.
> 
> ***
> * Driver modes of operation in terms of display buffers used
> ***
>  Depending on the requirements for the para-virtualized environment, namely
>  requirements dictated by the accompanying DRM/(v)GPU drivers running in both
>  host and guest environments, number of operating modes of para-virtualized
>  display driver are supported:
>   - display buffers can be allocated by either frontend driver or backend
>   - display buffers can be allocated to be contiguous in memory or not
> 
>  Note! Frontend driver itself has no dependency on contiguous memory for
>its operation.
> 
> ***
> * 1. Buffers allocated by the frontend driver.
> ***
> 
>  The below modes of operation are configured at compile-time via
>  frontend driver's kernel configuration.
> 
>  1.1. Front driver configured to use GEM CMA helpers
>   This use-case is useful when used with accompanying DRM/vGPU driver in
>   guest domain which was designed to only work with contiguous buffers,
>   e.g. DRM driver based on GEM CMA helpers: such drivers can only import
>   contiguous PRIME buffers, thus requiring frontend driver to provide
>   such. In order to implement this mode of operation para-virtualized
>   frontend driver can be configured to use GEM CMA helpers.
> 
>  1.2. Front driver doesn't use GEM CMA
>   If accompanying drivers can cope with non-contiguous memory then, to
>   lower pressure on CMA subsystem of the kernel, driver can allocate
>   buffers from system memory.
> 
>  Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
>may require IOMMU support on the platform, so accompanying DRM/vGPU
>hardware can still reach display buffer memory while importing PRIME
>buffers from the frontend driver.
> 
> ***
> * 2. Buffers allocated by the backend
> ***
> 
>  This mode of operation is run-time configured via guest domain configuration
>  through XenStore entries.
> 
>  For systems which do not provide IOMMU support, but having specific
>  requirements for display buffers it is possible to allocate such buffers
>  at backend side and share those with the frontend.
>  For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting
>  physically contiguous memory, this allows implementing zero-copying
>  use-cases.
> 
> 
> I would like to thank at least, but not at last the following
> people/communities who helped this driver to happen ;)
> 
> 1. My team at EPAM for continuous support
> 2. Xen community for answering tons of questions on different
> modes of operation of the driver with respect to virtualized
> environment.
> 3. Rob Clark for "GEM allocation for para-virtualized DRM driver" [6]
> 4. Maarten Lankhorst for "Atomic driver and old remove FB behavior" [7]
> 5. Ville Syrjälä for "Questions on page flips and atomic modeset" [8]
> 
> Thank you,
> 

[PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave,

I have these same patches stashed since last week, but last week
I wasn't confident that CI was happy with these ones so I decided to
hold on. Now after running multiple times with and without the patches applied
I see that it was only a fix on test case, which is now catching old bugs

So I'm now convinced that these patches here are good to go.

And no new fix this week.

Here goes drm-intel-fixes-2018-02-28:

- 2 display fixes: audio av_enc_map overflow check, and Cannonlake PLL related 
register offset.
- 3 gem fixes: Clear for in-fence out-fence, fix for clearing exec_flags on 
execbuf failure, and add back global seqno to tracepoints that had been removed 
recently by other fence related patch.

Thanks,
Rodrigo.

The following changes since commit 4a3928c6f8a53fa1aed28ccba227742486e8ddcb:

  Linux 4.16-rc3 (2018-02-25 18:50:41 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-02-28

for you to fetch changes up to fa89782b4f9c40d40e3f7d9ad7ef14e0bb0c3ca0:

  drm/i915: Make global seqno known in i915_gem_request_execute tracepoint 
(2018-02-28 11:10:48 -0800)


- 2 display fixes: audio av_enc_map overflow check, and Cannonlake PLL related 
register offset.
- 3 gem fixes: Clear for in-fence out-fence, fix for clearing exec_flags on 
execbuf failure, and add back global seqno to tracepoints that had been removed 
recently by other fence related patch.


Chris Wilson (1):
  drm/i915: Clear the in-use marker on execbuf failure

Daniele Ceraolo Spurio (1):
  drm/i915: Fix rsvd2 mask when out-fence is returned

Jani Nikula (1):
  drm/i915/audio: fix check for av_enc_map overflow

Mahesh Kumar (1):
  drm/i915/cnl: Fix PORT_TX_DW5/7 register address

Tvrtko Ursulin (1):
  drm/i915: Make global seqno known in i915_gem_request_execute tracepoint

 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +++-
 drivers/gpu/drm/i915/i915_gem_request.c| 4 ++--
 drivers/gpu/drm/i915/i915_reg.h| 4 ++--
 drivers/gpu/drm/i915/intel_audio.c | 6 +++---
 4 files changed, 10 insertions(+), 8 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:amd-staging-drm-next 699/734] sound/soc//amd/raven/pci-acp3x.c:122:2: error: implicit declaration of function 'pci_disable_msi'; did you mean 'pci_disable_sriov'?

[kbuild test robot]

Hi Maruthi,

FYI, the error/warning still remains.

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   2846f4ca3abe46839b82f424cc2ef935a3cb038a
commit: 944b5289c92d9c1aad3760c012daf4cf2478381f [699/734] ASoC: AMD: enable 
ACP3x drivers build
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 944b5289c92d9c1aad3760c012daf4cf2478381f
# save the attached .config to linux build tree
make.cross ARCH=sh 

All errors (new ones prefixed by >>):

   sound/soc//amd/raven/pci-acp3x.c: In function 'snd_acp3x_probe':
   sound/soc//amd/raven/pci-acp3x.c:58:8: error: implicit declaration of 
function 'pci_enable_msi'; did you mean 'pci_enable_sriov'? 
[-Werror=implicit-function-declaration]
 ret = pci_enable_msi(pci);
   ^~
   pci_enable_sriov
>> sound/soc//amd/raven/pci-acp3x.c:122:2: error: implicit declaration of 
>> function 'pci_disable_msi'; did you mean 'pci_disable_sriov'? 
>> [-Werror=implicit-function-declaration]
 pci_disable_msi(pci);
 ^~~
 pci_disable_sriov
   sound/soc//amd/raven/pci-acp3x.c: At top level:
   sound/soc//amd/raven/pci-acp3x.c:159:1: warning: data definition has no type 
or storage class
module_pci_driver(acp3x_driver);
^
   sound/soc//amd/raven/pci-acp3x.c:159:1: error: type defaults to 'int' in 
declaration of 'module_pci_driver' [-Werror=implicit-int]
   sound/soc//amd/raven/pci-acp3x.c:159:1: warning: parameter names (without 
types) in function declaration
   sound/soc//amd/raven/pci-acp3x.c:152:26: warning: 'acp3x_driver' defined but 
not used [-Wunused-variable]
static struct pci_driver acp3x_driver  = {
 ^~~~
   cc1: some warnings being treated as errors

vim +122 sound/soc//amd/raven/pci-acp3x.c

e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   29  
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   30  static int 
snd_acp3x_probe(struct pci_dev *pci,
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   31  
const struct pci_device_id *pci_id)
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   32  {
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   33   int ret;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   34   u32 addr, val;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   35   struct acp3x_dev_data 
*adata;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   36   struct 
platform_device_info pdevinfo;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   37   unsigned int irqflags;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   38  
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   39   if 
(pci_enable_device(pci)) {
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   40   
dev_err(>dev, "pci_enable_device failed\n");
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   41   return -ENODEV;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   42   }
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   43  
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   44   ret = 
pci_request_regions(pci, "AMD ACP3x audio");
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   45   if (ret < 0) {
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   46   
dev_err(>dev, "pci_request_regions failed\n");
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   47   goto 
disable_pci;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   48   }
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   49  
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   50   adata = 
devm_kzalloc(>dev, sizeof(struct acp3x_dev_data),
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   51   
GFP_KERNEL);
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   52   if (adata == NULL) {
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   53   ret = -ENOMEM;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   54   goto 
release_regions;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   55   }
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   56  
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   57   /* check for msi 
interrupt support */
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29  @58   ret = 
pci_enable_msi(pci);
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   59   if (ret)
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   60   /* msi is not 
enabled */
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   61   irqflags = 
IRQF_SHARED;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   62   else
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   63   /* msi is 
enabled */
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   64   irqflags = 0;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   65  
e8f3716a Maruthi Srinivas 

[Bug 105244] NULL dereference during startup of Cape Verde with AMDGPU and GPU passthrough

[bugzilla-daemon]

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

--- Comment #3 from Bas Nieuwenhuizen  ---
Sorry for the delay, I can confirm this fixes the NULL issue.

pp_dpm_mclk / pp_dpm_sclk look empty to me, not sure though if that is just
because they are not hooked up yet for SI, but since I don't need DPM and this
now boots AMDGPU with the default config to an usable state I'd consider this
fixed.

(leaving open because I don't know if the patch landed yet, feel free to close
when you push it)

-- 
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

[PATCH] drm/radeon/mkregtable: Delete unused list functions and macros

[Matthias Kaehlcke]

The util mkregtable includes a copy of the kernel API for linked lists,
only a small subset of it is used. Delete the unused functions and macros.

Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/radeon/mkregtable.c | 433 
 1 file changed, 433 deletions(-)

diff --git a/drivers/gpu/drm/radeon/mkregtable.c 
b/drivers/gpu/drm/radeon/mkregtable.c
index c21d8fa591ef..ba704633b072 100644
--- a/drivers/gpu/drm/radeon/mkregtable.c
+++ b/drivers/gpu/drm/radeon/mkregtable.c
@@ -43,10 +43,6 @@ struct list_head {
struct list_head *next, *prev;
 };
 
-#define LIST_HEAD_INIT(name) { &(name), &(name) }
-
-#define LIST_HEAD(name) \
-   struct list_head name = LIST_HEAD_INIT(name)
 
 static inline void INIT_LIST_HEAD(struct list_head *list)
 {
@@ -74,19 +70,6 @@ extern void __list_add(struct list_head *new,
   struct list_head *prev, struct list_head *next);
 #endif
 
-/**
- * list_add - add a new entry
- * @new: new entry to be added
- * @head: list head to add it after
- *
- * Insert a new entry after the specified head.
- * This is good for implementing stacks.
- */
-static inline void list_add(struct list_head *new, struct list_head *head)
-{
-   __list_add(new, head, head->next);
-}
-
 /**
  * list_add_tail - add a new entry
  * @new: new entry to be added
@@ -100,250 +83,6 @@ static inline void list_add_tail(struct list_head *new, 
struct list_head *head)
__list_add(new, head->prev, head);
 }
 
-/*
- * Delete a list entry by making the prev/next entries
- * point to each other.
- *
- * This is only for internal list manipulation where we know
- * the prev/next entries already!
- */
-static inline void __list_del(struct list_head *prev, struct list_head *next)
-{
-   next->prev = prev;
-   prev->next = next;
-}
-
-/**
- * list_del - deletes entry from list.
- * @entry: the element to delete from the list.
- * Note: list_empty() on entry does not return true after this, the entry is
- * in an undefined state.
- */
-#ifndef CONFIG_DEBUG_LIST
-static inline void list_del(struct list_head *entry)
-{
-   __list_del(entry->prev, entry->next);
-   entry->next = (void *)0xDEADBEEF;
-   entry->prev = (void *)0xBEEFDEAD;
-}
-#else
-extern void list_del(struct list_head *entry);
-#endif
-
-/**
- * list_replace - replace old entry by new one
- * @old : the element to be replaced
- * @new : the new element to insert
- *
- * If @old was empty, it will be overwritten.
- */
-static inline void list_replace(struct list_head *old, struct list_head *new)
-{
-   new->next = old->next;
-   new->next->prev = new;
-   new->prev = old->prev;
-   new->prev->next = new;
-}
-
-static inline void list_replace_init(struct list_head *old,
-struct list_head *new)
-{
-   list_replace(old, new);
-   INIT_LIST_HEAD(old);
-}
-
-/**
- * list_del_init - deletes entry from list and reinitialize it.
- * @entry: the element to delete from the list.
- */
-static inline void list_del_init(struct list_head *entry)
-{
-   __list_del(entry->prev, entry->next);
-   INIT_LIST_HEAD(entry);
-}
-
-/**
- * list_move - delete from one list and add as another's head
- * @list: the entry to move
- * @head: the head that will precede our entry
- */
-static inline void list_move(struct list_head *list, struct list_head *head)
-{
-   __list_del(list->prev, list->next);
-   list_add(list, head);
-}
-
-/**
- * list_move_tail - delete from one list and add as another's tail
- * @list: the entry to move
- * @head: the head that will follow our entry
- */
-static inline void list_move_tail(struct list_head *list,
- struct list_head *head)
-{
-   __list_del(list->prev, list->next);
-   list_add_tail(list, head);
-}
-
-/**
- * list_is_last - tests whether @list is the last entry in list @head
- * @list: the entry to test
- * @head: the head of the list
- */
-static inline int list_is_last(const struct list_head *list,
-  const struct list_head *head)
-{
-   return list->next == head;
-}
-
-/**
- * list_empty - tests whether a list is empty
- * @head: the list to test.
- */
-static inline int list_empty(const struct list_head *head)
-{
-   return head->next == head;
-}
-
-/**
- * list_empty_careful - tests whether a list is empty and not being modified
- * @head: the list to test
- *
- * Description:
- * tests whether a list is empty _and_ checks that no other CPU might be
- * in the process of modifying either member (next or prev)
- *
- * NOTE: using list_empty_careful() without synchronization
- * can only be safe if the only activity that can happen
- * to the list entry is list_del_init(). Eg. it cannot be used
- * if another CPU could re-list_add() it.
- */
-static inline int list_empty_careful(const struct list_head *head)
-{
-   struct list_head *next = head->next;
-   return (next == head) && (next 

Re: [PATCH v2 1/2] drm/panel: Remove drm_panel_detach() calls from all panel drives

[Jyri Sarha]

On 28/02/18 20:53, Thierry Reding wrote:
> On Wed, Feb 28, 2018 at 01:09:29PM +0200, Jyri Sarha wrote:
>> Setting the connector and drm to NULL when the drm panel device is
>> going away hardly serves any purpose. Usually the the whole memory
>> stucture is freed right after the remove call.
>>
>> Signed-off-by: Jyri Sarha 
>> ---
>>  drivers/gpu/drm/panel/panel-innolux-p079zca.c| 1 -
>>  drivers/gpu/drm/panel/panel-jdi-lt070me05000.c   | 1 -
>>  drivers/gpu/drm/panel/panel-lvds.c   | 1 -
>>  drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 1 -
>>  drivers/gpu/drm/panel/panel-seiko-43wvf1g.c  | 1 -
>>  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c  | 1 -
>>  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c  | 1 -
>>  drivers/gpu/drm/panel/panel-simple.c | 1 -
>>  drivers/gpu/drm/panel/panel-sitronix-st7789v.c   | 1 -
>>  9 files changed, 9 deletions(-)
> 
> I don't understand the purpose of this patch. I'll grant you that the
> current implementation of drm_panel_detach() is not very useful, but
> then you add code to drm_panel_detach() in the next patch and mention
> in the commit message that panel drivers should be calling the
> drm_panel_detach() function to remove the link.
> 
> This is confusing. Can you clarify?
> 

When looking at the current implementation it does not make any sense to
me to call drm_panel_detach() from the panel driver itself. However, it
makes perfect sense calling it from drm driver. Setting panel->connector
= NULL marks it free and attachable to other devices, but the panel
driver that the passive element in the picture should not go and mark
itself available on its own.

But now that I take the steps to make the drm_panel_detach() to be
called only from drm device I should at least document it too.

Also in general I think it is hard to come up with a detach
implementation that would work from both panel and the drm device.

Best regards,
Jyri

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 17/17] drm/omap: cleanup color space conversion

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Wednesday, 28 February 2018 13:26:14 EET Tomi Valkeinen wrote:
> The setup code for color space conversion is a bit messy. This patch
> cleans it up.
> 
> For some reason the TRM uses values in YCrCb order, which is also used
> in the current driver, whereas everywhere else it's YCbCr (which also
> matches YUV order). This patch changes the tables to use the common
> order to avoid confusion.
> 
> The tables are split into separate lines, and comments added for
> clarity.
> 
> WB color conversion registers are similar but different than non-WB, but
> the same function was used to write both. It worked fine because the
> coef table was adjusted accordingly, but that was rather confusing. This
> patch adds a separate function to write the WB values so that the coef
> table can be written in an understandable way.
> 
> Recalculation also showed that 'bcb' value in yuv-to-rgb conversion had
> been rounded wrongly, and it should be 516 instead of 517.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c | 59 +-
>  1 file changed, 44 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c index 57960df1517a..f688f09b4eae
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -352,11 +352,6 @@ static const struct {
>   },
>  };
> 
> -struct color_conv_coef {
> - int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
> - int full_range;
> -};
> -
>  static unsigned long dispc_fclk_rate(struct dispc_device *dispc);
>  static unsigned long dispc_core_clk_rate(struct dispc_device *dispc);
>  static unsigned long dispc_mgr_lclk_rate(struct dispc_device *dispc,
> @@ -868,10 +863,19 @@ static void dispc_ovl_set_scale_coef(struct
> dispc_device *dispc, }
>  }
> 
> +struct csc_coef_yuv2rgb {
> + int ry, rcb, rcr, gy, gcb, gcr, by, bcb, bcr;
> + bool full_range;
> +};
> +
> +struct csc_coef_rgb2yuv {
> + int yr, yg, yb, cbr, cbg, cbb, crr, crg, crb;
> + bool full_range;
> +};
> 
>  static void dispc_ovl_write_color_conv_coef(struct dispc_device *dispc,
>   enum omap_plane_id plane,
> - const struct color_conv_coef *ct)
> + const struct csc_coef_yuv2rgb *ct)
>  {
>  #define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
> 
> @@ -886,25 +890,50 @@ static void dispc_ovl_write_color_conv_coef(struct
> dispc_device *dispc, #undef CVAL
>  }
> 
> +static void dispc_wb_write_color_conv_coef(struct dispc_device *dispc,
> +const struct csc_coef_rgb2yuv *ct)
> +{
> + const enum omap_plane_id plane = OMAP_DSS_WB;
> +
> +#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
> +
> + dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 0), CVAL(ct->yg, 
> ct->yr));
> + dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 1), CVAL(ct->crr,
> ct->yb));
> + dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 2), CVAL(ct->crb,
> ct->crg));
> + dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->cbg,
> ct->cbr));
> + dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->cbb));
> +
> + REG_FLD_MOD(dispc, DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 
> 11);

I think I mentioned in my review of v1 that you can drop the !!. Apart from 
that,

Reviewed-by: Laurent Pinchart 

> +#undef CVAL
> +}
> +
>  static void dispc_setup_color_conv_coef(struct dispc_device *dispc)
>  {
>   int i;
>   int num_ovl = dispc_get_num_ovls(dispc);
> - const struct color_conv_coef ctbl_bt601_5_ovl = {
> - /* YUV -> RGB */
> - 298, 409, 0, 298, -208, -100, 298, 0, 517, 0,
> +
> + /* YUV -> RGB, ITU-R BT.601, limited range */
> + const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
> + 298,0,  409,/* ry, rcb, rcr */
> + 298, -100, -208,/* gy, gcb, gcr */
> + 298,  516,0,/* by, bcb, bcr */
> + false,  /* limited range */
>   };
> - const struct color_conv_coef ctbl_bt601_5_wb = {
> - /* RGB -> YUV */
> - 66, 129, 25, 112, -94, -18, -38, -74, 112, 0,
> +
> + /* RGB -> YUV, ITU-R BT.601, limited range */
> + const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
> +  66, 129,  25,  /* yr,   yg,  yb */
> + -38, -74, 112,  /* cbr, cbg, cbb */
> + 112, -94, -18,  /* crr, crg, crb */
> + false,  /* limited range */
>   };
> 
>   for (i = 1; i < num_ovl; i++)
> - dispc_ovl_write_color_conv_coef(dispc, i, _bt601_5_ovl);
> + dispc_ovl_write_color_conv_coef(dispc, i, 
> 

Re: [PATCHv2 04/17] drm/omap: add HPD support to connector-dvi

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Wednesday, 28 February 2018 13:26:01 EET Tomi Valkeinen wrote:
> Add HPD support to the DVI connector driver. The code is almost
> identical to the HPD code in the HDMI connector driver.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 118 
>  1 file changed, 118 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c index
> 391d80364346..6d8cbd9e2110 100644
> --- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> +++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> @@ -9,6 +9,7 @@
>   * the Free Software Foundation.
>   */
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -44,6 +45,14 @@ struct panel_drv_data {
>   struct videomode vm;
> 
>   struct i2c_adapter *i2c_adapter;
> +
> + struct gpio_desc *hpd_gpio;
> +
> + void (*hpd_cb)(void *cb_data, enum drm_connector_status status);
> + void *hpd_cb_data;
> + bool hpd_enabled;
> + /* mutex for hpd fields above */
> + struct mutex hpd_lock;
>  };
> 
>  #define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
> @@ -189,6 +198,9 @@ static int dvic_read_edid(struct omap_dss_device
> *dssdev, struct panel_drv_data *ddata = to_panel_data(dssdev);
>   int r, l, bytes_read;
> 
> + if (ddata->hpd_gpio && !gpiod_get_value_cansleep(ddata->hpd_gpio))
> + return -ENODEV;
> +
>   if (!ddata->i2c_adapter)
>   return -ENODEV;
> 
> @@ -220,6 +232,9 @@ static bool dvic_detect(struct omap_dss_device *dssdev)
>   unsigned char out;
>   int r;
> 
> + if (ddata->hpd_gpio)
> + return gpiod_get_value_cansleep(ddata->hpd_gpio);
> +
>   if (!ddata->i2c_adapter)
>   return true;
> 
> @@ -228,6 +243,60 @@ static bool dvic_detect(struct omap_dss_device *dssdev)
> return r == 0;
>  }
> 
> +static int dvic_register_hpd_cb(struct omap_dss_device *dssdev,
> +  void (*cb)(void *cb_data,
> + enum drm_connector_status status),
> +  void *cb_data)
> +{
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
> +
> + if (!ddata->hpd_gpio)
> + return -ENOTSUPP;
> +
> + mutex_lock(>hpd_lock);
> + ddata->hpd_cb = cb;
> + ddata->hpd_cb_data = cb_data;
> + mutex_unlock(>hpd_lock);
> + return 0;
> +}
> +
> +static void dvic_unregister_hpd_cb(struct omap_dss_device *dssdev)
> +{
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
> +
> + if (!ddata->hpd_gpio)
> + return;
> +
> + mutex_lock(>hpd_lock);
> + ddata->hpd_cb = NULL;
> + ddata->hpd_cb_data = NULL;
> + mutex_unlock(>hpd_lock);
> +}
> +
> +static void dvic_enable_hpd(struct omap_dss_device *dssdev)
> +{
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
> +
> + if (!ddata->hpd_gpio)
> + return;
> +
> + mutex_lock(>hpd_lock);
> + ddata->hpd_enabled = true;
> + mutex_unlock(>hpd_lock);
> +}
> +
> +static void dvic_disable_hpd(struct omap_dss_device *dssdev)
> +{
> + struct panel_drv_data *ddata = to_panel_data(dssdev);
> +
> + if (!ddata->hpd_gpio)
> + return;
> +
> + mutex_lock(>hpd_lock);
> + ddata->hpd_enabled = false;
> + mutex_unlock(>hpd_lock);
> +}
> +
>  static struct omap_dss_driver dvic_driver = {
>   .connect= dvic_connect,
>   .disconnect = dvic_disconnect,
> @@ -241,14 +310,60 @@ static struct omap_dss_driver dvic_driver = {
> 
>   .read_edid  = dvic_read_edid,
>   .detect = dvic_detect,
> +
> + .register_hpd_cb= dvic_register_hpd_cb,
> + .unregister_hpd_cb  = dvic_unregister_hpd_cb,
> + .enable_hpd = dvic_enable_hpd,
> + .disable_hpd= dvic_disable_hpd,
>  };
> 
> +static irqreturn_t dvic_hpd_isr(int irq, void *data)
> +{
> + struct panel_drv_data *ddata = data;
> +
> + mutex_lock(>hpd_lock);
> + if (ddata->hpd_enabled && ddata->hpd_cb) {
> + enum drm_connector_status status;
> +
> + if (dvic_detect(>dssdev))
> + status = connector_status_connected;
> + else
> + status = connector_status_disconnected;
> +
> + ddata->hpd_cb(ddata->hpd_cb_data, status);
> + }
> + mutex_unlock(>hpd_lock);
> +
> + return IRQ_HANDLED;
> +}
> +
>  static int dvic_probe_of(struct platform_device *pdev)
>  {
>   struct panel_drv_data *ddata = platform_get_drvdata(pdev);
>   struct device_node *node = pdev->dev.of_node;
>   struct device_node *adapter_node;
>   struct i2c_adapter *adapter;
> + struct gpio_desc *gpio;
> + int r;
> +
> + gpio = devm_gpiod_get_optional(>dev, 

Re: [PATCHv2 02/17] drm/omap: cleanup fbdev init/free

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Wednesday, 28 February 2018 13:25:59 EET Tomi Valkeinen wrote:
> omap_fbdev_init() and omap_fbdev_free() use priv->fbdev directly.
> However, omap_fbdev_init() returns the fbdev, and omap_drv.c also
> assigns the return value to priv->fbdev. This is slightly confusing.
> 
> Clean this up by removing the omap_fbdev_init() return value, as we
> don't care whether fbdev init succeeded or not. Also change omap_drv.c
> to call omap_fbdev_free() always, and omap_fbdev_free() does the check
> if fbdev was initialized.
> 
> While at it, rename omap_fbdev_free() to omap_fbdev_fini() to better
> match the "init" counterpart.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c   |  9 -
>  drivers/gpu/drm/omapdrm/omap_fbdev.c | 18 --
>  drivers/gpu/drm/omapdrm/omap_fbdev.h |  9 -
>  3 files changed, 16 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index 65a567dcf3ab..4f48b908bdc6
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -570,7 +570,7 @@ static int omapdrm_init(struct omap_drm_private *priv,
> struct device *dev) for (i = 0; i < priv->num_crtcs; i++)
>   drm_crtc_vblank_off(priv->crtcs[i]);
> 
> - priv->fbdev = omap_fbdev_init(ddev);
> + omap_fbdev_init(ddev);
> 
>   drm_kms_helper_poll_init(ddev);
>   omap_modeset_enable_external_hpd();
> @@ -588,8 +588,8 @@ static int omapdrm_init(struct omap_drm_private *priv,
> struct device *dev) err_cleanup_helpers:
>   omap_modeset_disable_external_hpd();
>   drm_kms_helper_poll_fini(ddev);
> - if (priv->fbdev)
> - omap_fbdev_free(ddev);
> +
> + omap_fbdev_fini(ddev);
>  err_cleanup_modeset:
>   drm_mode_config_cleanup(ddev);
>   omap_drm_irq_uninstall(ddev);
> @@ -615,8 +615,7 @@ static void omapdrm_cleanup(struct omap_drm_private
> *priv) omap_modeset_disable_external_hpd();
>   drm_kms_helper_poll_fini(ddev);
> 
> - if (priv->fbdev)
> - omap_fbdev_free(ddev);
> + omap_fbdev_fini(ddev);
> 
>   drm_atomic_helper_shutdown(ddev);
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> b/drivers/gpu/drm/omapdrm/omap_fbdev.c index 632ebcf2165f..be94480326d7
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> @@ -242,7 +242,7 @@ static struct drm_fb_helper *get_fb(struct fb_info *fbi)
> }
> 
>  /* initialize fbdev helper */
> -struct drm_fb_helper *omap_fbdev_init(struct drm_device *dev)
> +void omap_fbdev_init(struct drm_device *dev)
>  {
>   struct omap_drm_private *priv = dev->dev_private;
>   struct omap_fbdev *fbdev = NULL;
> @@ -260,10 +260,8 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device
> *dev) drm_fb_helper_prepare(dev, helper, _fb_helper_funcs);
> 
>   ret = drm_fb_helper_init(dev, helper, priv->num_connectors);
> - if (ret) {
> - dev_err(dev->dev, "could not init fbdev: ret=%d\n", ret);
> + if (ret)
>   goto fail;
> - }
> 
>   ret = drm_fb_helper_single_add_all_connectors(helper);
>   if (ret)
> @@ -275,7 +273,7 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device
> *dev)
> 
>   priv->fbdev = helper;
> 
> - return helper;
> + return;
> 
>  fini:
>   drm_fb_helper_fini(helper);
> @@ -283,12 +281,9 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device
> *dev) kfree(fbdev);
> 
>   dev_warn(dev->dev, "omap_fbdev_init failed\n");
> - /* well, limp along without an fbdev.. maybe X11 will work? */
> -
> - return NULL;
>  }
> 
> -void omap_fbdev_free(struct drm_device *dev)
> +void omap_fbdev_fini(struct drm_device *dev)
>  {
>   struct omap_drm_private *priv = dev->dev_private;
>   struct drm_fb_helper *helper = priv->fbdev;
> @@ -296,11 +291,14 @@ void omap_fbdev_free(struct drm_device *dev)
> 
>   DBG();
> 
> + if (!helper)
> + return;
> +
>   drm_fb_helper_unregister_fbi(helper);
> 
>   drm_fb_helper_fini(helper);
> 
> - fbdev = to_omap_fbdev(priv->fbdev);
> + fbdev = to_omap_fbdev(helper);
> 
>   /* unpin the GEM object pinned in omap_fbdev_create() */
>   if (fbdev->bo)
> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.h
> b/drivers/gpu/drm/omapdrm/omap_fbdev.h index 1f5ba0996a1a..7dfd843f73f1
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.h
> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.h
> @@ -24,14 +24,13 @@ struct drm_device;
>  struct drm_fb_helper;
> 
>  #ifdef CONFIG_DRM_FBDEV_EMULATION
> -struct drm_fb_helper *omap_fbdev_init(struct drm_device *dev);
> -void omap_fbdev_free(struct drm_device *dev);
> +void omap_fbdev_init(struct drm_device *dev);
> +void omap_fbdev_fini(struct drm_device *dev);
>  #else
> -static inline struct drm_fb_helper 

[Bug 36072] celestia causes kernel oops when allocation a lot of memory (for textures)

[bugzilla-daemon]

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

aceman (aceli...@atlas.sk) changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #11 from aceman (aceli...@atlas.sk) ---
I no longer have that particular GPU but I also haven't seen the problem in
ages. I added the vmalloc argument to the kernel cmdline, that may also have
helped.
With the recent amdgpu kernel driver I am trying to run without this argument
and haven't seen any problems with Celestia yet. I also have 4GB of VRAM on a
Polaris11 GPU now.

-- 
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: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

[Alex Deucher]

On Tue, Feb 27, 2018 at 7:56 AM, Ville Syrjala
 wrote:
> From: Ville Syrjälä 
>
> Currently we have a mix of static and dynamic information stored in
> the display info structure. That makes it rather difficult to repopulate
> the dynamic parts when a new EDID appears. Let's make life easier by
> splitting the structure up into static and dynamic parts.
>
> The static part will consist of subpixel_order, panel_orientation,
> and bus_formats.
>
> Actually I'm not sure where bus_formats & co. fit in all this. For some
> drivers those seem to be static, even though they might fill them out
> from .get_modes(). For other drivers this stuff even gets frobbed at
> runtime, making it more some kind of a bastard encoder/connector state.
> I'll just stick it into the static side so that the behaviour doesn't
> change when I start clear out the entire dynamic state with memset().
>
> Cc: Keith Packard 
> Cc: Daniel Vetter 
> Cc: Hans de Goede 
> Cc: Shashank Sharma 
> Cc: Stefan Agner 
> Cc: Thierry Reding 
> Cc: Boris Brezillon 
> Cc: Philipp Zabel 
> Cc: Laurent Pinchart 
> Cc: Manfred Schlaegl 
> Cc: Marek Vasut 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Alison Wang 
> Cc: Eric Anholt 
> Cc: Linus Walleij 
> Cc: linux-renesas-...@vger.kernel.org
> Cc: Maxime Ripard 
> Signed-off-by: Ville Syrjälä 

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

RE: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane

[Deepak Singh Rawat]

> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Thursday, December 21, 2017 5:11 AM
> To: Ville Syrjälä 
> Cc: airl...@linux.ie; daniel.vet...@intel.com; dri-
> de...@lists.freedesktop.org; Lukasz Spintzyk
> 
> Subject: Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for
> drm_plane
> 
> On Thu, Dec 21, 2017 at 02:46:55PM +0200, Ville Syrjälä wrote:
> > On Thu, Dec 21, 2017 at 12:10:08PM +0100, Lukasz Spintzyk wrote:
> > > Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5
> > > Signed-off-by: Lukasz Spintzyk 
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c  | 10 ++
> > >  drivers/gpu/drm/drm_mode_config.c |  6 ++
> > >  drivers/gpu/drm/drm_plane.c   |  1 +
> > >  include/drm/drm_mode_config.h |  5 +
> > >  include/drm/drm_plane.h   |  3 +++
> > >  5 files changed, 25 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c
> b/drivers/gpu/drm/drm_atomic.c
> > > index b76d49218cf1..cd3b4ed7b04c 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -759,6 +759,14 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> > >   state->rotation = val;
> > >   } else if (property == plane->zpos_property) {
> > >   state->zpos = val;
> > > + } else if (property == config->dirty_rects_property) {
> > > + bool replaced = false;
> > > + int ret = drm_atomic_replace_property_blob_from_id(dev,
> > > + >dirty_blob,
> > > + val,
> > > + -1,
> > > + );
> > > + return ret;
> > >   } else if (plane->funcs->atomic_set_property) {
> > >   return plane->funcs->atomic_set_property(plane, state,
> > >   property, val);
> > > @@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct
> drm_plane *plane,
> > >   *val = state->rotation;
> > >   } else if (property == plane->zpos_property) {
> > >   *val = state->zpos;
> > > + } else if (property == config->dirty_rects_property) {
> > > + *val = (state->dirty_blob) ? state->dirty_blob->base.id : 0;
> > >   } else if (plane->funcs->atomic_get_property) {
> > >   return plane->funcs->atomic_get_property(plane, state,
> property, val);
> > >   } else {
> > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> > > index bc5c46306b3d..d5f1021c6ece 100644
> > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > @@ -293,6 +293,12 @@ static int
> drm_mode_create_standard_properties(struct drm_device *dev)
> > >   return -ENOMEM;
> > >   dev->mode_config.prop_crtc_id = prop;
> > >
> > > + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> > > + "DIRTY_RECTS", 0);
> > > + if (!prop)
> > > + return -ENOMEM;
> > > + dev->mode_config.dirty_rects_property = prop;
> > > +
> > >   prop = drm_property_create_bool(dev,
> DRM_MODE_PROP_ATOMIC,
> > >   "ACTIVE");
> > >   if (!prop)
> > > diff --git a/drivers/gpu/drm/drm_plane.c
> b/drivers/gpu/drm/drm_plane.c
> > > index 37a93cdffb4a..add110f025e5 100644
> > > --- a/drivers/gpu/drm/drm_plane.c
> > > +++ b/drivers/gpu/drm/drm_plane.c
> > > @@ -258,6 +258,7 @@ int drm_universal_plane_init(struct drm_device
> *dev, struct drm_plane *plane,
> > >   drm_object_attach_property(>base, config-
> >prop_src_y, 0);
> > >   drm_object_attach_property(>base, config-
> >prop_src_w, 0);
> > >   drm_object_attach_property(>base, config-
> >prop_src_h, 0);
> > > + drm_object_attach_property(>base, config-
> >dirty_rects_property, 0);
> > >   }
> > >
> > >   if (config->allow_fb_modifiers)
> > > diff --git a/include/drm/drm_mode_config.h
> b/include/drm/drm_mode_config.h
> > > index e5f3b43014e1..65f64eb04c0c 100644
> > > --- a/include/drm/drm_mode_config.h
> > > +++ b/include/drm/drm_mode_config.h
> > > @@ -599,6 +599,11 @@ struct drm_mode_config {
> > >* _crtc.
> > >*/
> > >   struct drm_property *prop_crtc_id;
> > > + /**
> > > +  * @dirty_rects_property: Optional plane property to mark damaged
> > > +  * regions on the plane framebuffer.
> >
> > What exactly would the blob contain?
> >
> > The comment seems to be implying these are in fb coordiantes as
> > opposed to plane crtc coordinates? Not sure which would be more
> > convenient. At least if they're fb coordinates then you probably
> > want some helpers to translate/rotate/scale those rects to the
> > crtc coordinates. Actual use depends on the driver/hw I suppose.
> 
> Yeah I think we also should add a decoded state to the drm_plane_state,
> which has the full structure and all the details.

Hi Daniel,

I am working on this 

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Fix plane YCbCr->RGB conversion for GLK

[Imre Deak]

On Wed, Feb 14, 2018 at 09:23:24PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> On GLK the plane CSC controls moved into the COLOR_CTL register.
> Update the code to progam the YCbCr->RGB CSC mode correctly when
> faced with an YCbCr framebuffer.
> 
> The spec is rather confusing as it calls the mode "YUV601 to RGB709".
> I'm going to assume that just means it's going to use the YCbCr->RGB
> matrix as specified in BT.601 and doesn't actually change the gamut.
> 
> Cc: Harry Wentland 
> Cc: Daniel Vetter 
> Cc: Daniel Stone 
> Cc: Russell King - ARM Linux 
> Cc: Ilia Mirkin 
> Cc: Hans Verkuil 
> Cc: Uma Shankar 
> Cc: Shashank Sharma 
> Signed-off-by: Ville Syrjälä 

Matches the spec, so:
Reviewed-by: Imre Deak 

I asked for clarification in the spec about the BT.601 vs. 709 oddity you
noticed.

> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  5 +
>  drivers/gpu/drm/i915/intel_display.c |  3 +++
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_sprite.c  | 10 +-
>  4 files changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 28b36eac064e..6abeaf64c2d2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6463,6 +6463,11 @@ enum {
>  #define _PLANE_COLOR_CTL_3_A 0x703CC /* GLK+ */
>  #define   PLANE_COLOR_PIPE_GAMMA_ENABLE  (1 << 30)
>  #define   PLANE_COLOR_PIPE_CSC_ENABLE(1 << 23)
> +#define   PLANE_COLOR_CSC_MODE_BYPASS(0 << 17)
> +#define   PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709  (1 << 17)
> +#define   PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709  (2 << 17)
> +#define   PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020(3 << 17)
> +#define   PLANE_COLOR_CSC_MODE_RGB709_TO_RGB2020 (4 << 17)
>  #define   PLANE_COLOR_PLANE_GAMMA_DISABLE(1 << 13)
>  #define   PLANE_COLOR_ALPHA_MASK (0x3 << 4)
>  #define   PLANE_COLOR_ALPHA_DISABLE  (0 << 4)
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 286a9591d179..a22b583838f7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3573,6 +3573,9 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
> *crtc_state,
>   plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
>   plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
>  
> + if (intel_format_is_yuv(fb->format->format))
> + plane_color_ctl |= PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> +
>   return plane_color_ctl;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 898064e8bea7..6e43da40c859 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1591,6 +1591,7 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
> *crtc_state,
>   const struct intel_plane_state *plane_state);
>  u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
> const struct intel_plane_state *plane_state);
> +u32 glk_color_ctl(const struct intel_plane_state *plane_state);
>  u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
>unsigned int rotation);
>  int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
> @@ -2016,6 +2017,7 @@ bool intel_sdvo_init(struct drm_i915_private *dev_priv,
>  
>  
>  /* intel_sprite.c */
> +bool intel_format_is_yuv(u32 format);
>  int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
>int usecs);
>  struct intel_plane *intel_sprite_plane_create(struct drm_i915_private 
> *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index fac9e01b4795..b4acde2058fe 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -41,8 +41,7 @@
>  #include 
>  #include "i915_drv.h"
>  
> -static bool
> -format_is_yuv(uint32_t format)
> +bool intel_format_is_yuv(u32 format)
>  {
>   switch (format) {
>   case DRM_FORMAT_YUYV:
> @@ -266,6 +265,7 @@ skl_update_plane(struct intel_plane *plane,
>   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
>   I915_WRITE_FW(PLANE_COLOR_CTL(pipe, plane_id),
> plane_state->color_ctl);
> +
>   if (key->flags) {
>   I915_WRITE_FW(PLANE_KEYVAL(pipe, plane_id), key->min_value);
>   I915_WRITE_FW(PLANE_KEYMAX(pipe, plane_id), key->max_value);
> @@ -354,7 +354,7 @@ chv_update_csc(const struct intel_plane_state 
> 

[pull] amdgpu drm-fixes-4.16

[Alex Deucher]

Hi Dave,

A few misc fixes for 4.16.

The following changes since commit 219b3b22df9d828367a4eeceed7600890e2ff4ef:

  Merge branch 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2018-02-28 11:39:52 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.16

for you to fetch changes up to fd430a702d37747d79bb5520590ce198df02aaa5:

  drm/amdgpu: skip ECC for SRIOV in gmc late_init (2018-02-28 15:20:22 -0500)


Emily Deng (1):
  drm/amdgpu: Correct sdma_v4 get_wptr(v2)

Eric Huang (1):
  drm/amd/powerplay: fix power over limit on Fiji

James Zhu (1):
  drm/amdgpu:Fixed wrong emit frame size for enc

Monk Liu (4):
  drm/amdgpu: only flush hotplug work without DC
  drm/amdgpu: move WB_FREE to correct place
  drm/amdgpu: fix for wb_clear
  drm/amdgpu: skip ECC for SRIOV in gmc late_init

Shirish S (1):
  drm/amd/display: check for ipp before calling cursor operations

Tom St Denis (1):
  drm/amd/amdgpu: Correct VRAM width for APUs with GMC9

 drivers/gpu/drm/amd/amdgpu/amdgpu.h  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 17 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c  |  6 --
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c|  7 +--
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c   | 18 +++---
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c|  2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c  |  6 --
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c |  7 ---
 8 files changed, 32 insertions(+), 33 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-next

[Sean Paul]

Hi Dave,
Here's this weeks pull, relatively small when you pull out the trivial fixes.

drm-misc-next-2018-02-28:
drm-misc-next for 4.17:

UAPI Changes:
 Fix drm_color_ctm matrix docs to match usage and change the type to
 __u64 make it obvious (Ville)

Core Changes:
 Check modifier with format when checking if a plane state is supported (Ville)

Driver Changes:
 sun4i: Improve hw plane utilization (Maxime)
 simple: Add per-pipe enable/disable vblank functions (Oleksandr)
 virtio: Whitespace + checkpatch changes (Rodrigo)

Cc: Maxime Ripard 
Cc: Oleksandr Andrushchenko 
Cc: Ville Syrjälä 
Cc: Rodrigo Siqueira 

Cheers, Sean


The following changes since commit 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e:

  drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-02-28

for you to fetch changes up to 7628166d5e2883e4cdd142b99863d29d411a81b2:

  tinydrm: add backlight dependency (2018-02-28 15:08:56 -0500)


drm-misc-next for 4.17:

UAPI Changes:
 Fix drm_color_ctm matrix docs to match usage and change the type to
 __u64 make it obvious (Ville)

Core Changes:
 Check modifier with format when checking if a plane state is supported (Ville)

Driver Changes:
 sun4i: Improve hw plane utilization (Maxime)
 simple: Add per-pipe enable/disable vblank functions (Oleksandr)
 virtio: Whitespace + checkpatch changes (Rodrigo)

Cc: Maxime Ripard 
Cc: Oleksandr Andrushchenko 
Cc: Ville Syrjälä 
Cc: Rodrigo Siqueira 


Arnd Bergmann (2):
  drm: fix drm_get_max_iomem type mismatch
  tinydrm: add backlight dependency

Benjamin Gaignard (1):
  drm/stm: check pitch and size calculations even if !CONFIG_MMU

Chris Wilson (1):
  drm/mm: Fix caching of leftmost node in the interval tree

Linus Walleij (1):
  drm/panel: Fix ARM Versatile panel clocks

Maxime Ripard (4):
  drm/sun4i: backend: Assign the pipes automatically
  drm/sun4i: Remove the plane description structure
  drm/sun4i: backend: Make zpos configurable
  drm/sun4i: backend: Remove ARGB spoofing

Oleksandr Andrushchenko (5):
  drm/simple_kms_helper: Fix NULL pointer dereference with no active CRTC
  drm/simple_kms_helper: Add {enable|disable}_vblank callback support
  drm/mxsfb: Do not use deprecated drm_driver.{enable|disable)_vblank
  drm/tve200: Do not use deprecated drm_driver.{enable|disable)_vblank
  drm/pl111: Do not use deprecated drm_driver.{enable|disable)_vblank

Rodrigo Siqueira (7):
  drm/virtio: Add tabs at the start of a line
  drm/virtio: Add blank line after variable declarations
  drm/virtio: Add */ in block comments to separate line
  drm/virtio: Remove return from void function
  drm/virtio: Replace 'unsigned' for 'unsigned int'
  drm/virtio: Remove multiple blank lines
  drm/virtio: Add spaces around operators

Thierry Reding (1):
  drm/pl111: Remove reverse dependency on DRM_DUMB_VGA_DAC

Ville Syrjälä (4):
  drm: Check that the plane supports the request format+modifier combo
  drm/i915: Remove the pipe/plane ID checks from skl_check_ccs_aux_surface()
  drm: Include the header with the prototype for 
drm_get_panel_orientation_quirk()
  drm/uapi: The ctm matrix uses sign-magnitude representation

 drivers/gpu/drm/drm_atomic.c   | 10 +++--
 drivers/gpu/drm/drm_crtc.c | 10 +++--
 drivers/gpu/drm/drm_crtc_internal.h|  4 +-
 drivers/gpu/drm/drm_memory.c   |  2 +-
 drivers/gpu/drm/drm_mm.c   |  9 +++--
 drivers/gpu/drm/drm_panel_orientation_quirks.c |  1 +
 drivers/gpu/drm/drm_plane.c| 33 
 drivers/gpu/drm/drm_simple_kms_helper.c| 34 
 drivers/gpu/drm/i915/intel_display.c   |  8 
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  | 54 +
 drivers/gpu/drm/panel/panel-arm-versatile.c|  8 ++--
 drivers/gpu/drm/pl111/Kconfig  |  1 -
 drivers/gpu/drm/pl111/pl111_display.c  | 15 +--
 drivers/gpu/drm/pl111/pl111_drm.h  |  2 -
 drivers/gpu/drm/pl111/pl111_drv.c  |  5 ---
 drivers/gpu/drm/stm/drv.c  |  2 -
 drivers/gpu/drm/sun4i/sun4i_backend.c  | 52 ++--
 drivers/gpu/drm/sun4i/sun4i_layer.c| 55 ++
 drivers/gpu/drm/sun4i/sun4i_layer.h|  1 +
 drivers/gpu/drm/tinydrm/Kconfig|  2 +
 drivers/gpu/drm/tve200/tve200_display.c| 10 

[Bug 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock

[bugzilla-daemon]

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

Bug ID: 105300
   Summary: amd-staging-drm-next-git 4.16 & RX 560 DL-DVI:
corruption with refreshrates >73Hz when DPM changing
VRAM clock
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: tempel.jul...@gmail.com

Created attachment 137704
  --> https://bugs.freedesktop.org/attachment.cgi?id=137704=edit
edids for 2560x1440 73Hz, 74Hz and 75Hz

Hello,
I tried out amd-staging-drm-next-git with Linux 4.16 and my DL-DVI 2560x1440
display:
Now I finally get a picture and refreshrates below 74Hz seem to work without
apparent issues, thanks for fixing the black screen issue!

However, when using edid information which contains a resolution with
refreshrates higher than 73Hz, I get flickering artifacts on the desktop. The
issue disappears when I force full clocks via sysfs or use display timings
which prevent the VRAM from downclocking. So it seems very likely to me that
it's related to downclocking of the VRAM when using higher refreshrates.
This is a regression, the old display stack (amdgpu.dc=0) works with
refreshrates higher than 73Hz and VRAM downclocking at the same time without
issues.

I attached edid files which can be loaded via drm_kms_helper.edid_firmware and
drm.edid_firmware (they show equal behavior in this case), they use LCD
standard timings.

Thanks!

-- 
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 104555] RX 560 DPM auto - driver doesn't reliably set high clocks, causing stutter in mpv

[bugzilla-daemon]

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

tempel.jul...@gmail.com changed:

   What|Removed |Added

   Severity|major   |normal

-- 
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] tinydrm: add backlight dependency

[Sean Paul]

On Wed, Feb 28, 2018 at 02:40:48PM +0100, Arnd Bergmann wrote:
> Calling devm_of_find_backlight directly means we get a link failure
> without CONFIG_BACKLIGHT_CLASS_DEVICE:
> 
> drivers/gpu/drm/tinydrm/mi0283qt.o: In function `mi0283qt_probe':
> mi0283qt.c:(.text+0x684): undefined reference to `devm_of_find_backlight'
> 
> This adds an explicit Kconfig dependency for it. While I did not
> observe that failure for st7735r, I assume the same change is needed
> there for the same reason.
> 
> Fixes: d1a2e7004b5e ("drm/tinydrm: Replace tinydrm_of_find_backlight with 
> of_find_backlight")
> Signed-off-by: Arnd Bergmann 

Applied to drm-misc-next, thanks!

Sean

> ---
>  drivers/gpu/drm/tinydrm/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
> index 13339be843bc..4592a5e3f20b 100644
> --- a/drivers/gpu/drm/tinydrm/Kconfig
> +++ b/drivers/gpu/drm/tinydrm/Kconfig
> @@ -23,6 +23,7 @@ config TINYDRM_ILI9225
>  config TINYDRM_MI0283QT
>   tristate "DRM support for MI0283QT"
>   depends on DRM_TINYDRM && SPI
> + depends on BACKLIGHT_CLASS_DEVICE
>   select TINYDRM_MIPI_DBI
>   help
> DRM driver for the Multi-Inno MI0283QT display panel
> @@ -54,6 +55,7 @@ config TINYDRM_ST7586
>  config TINYDRM_ST7735R
>   tristate "DRM support for Sitronix ST7735R display panels"
>   depends on DRM_TINYDRM && SPI
> + depends on BACKLIGHT_CLASS_DEVICE
>   select TINYDRM_MIPI_DBI
>   help
> DRM driver Sitronix ST7735R with one of the following LCDs:
> -- 
> 2.9.0
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Jani Nikula]

On Wed, 28 Feb 2018, Thierry Reding  wrote:
> Anyone that needs something other than normal mode should use the new
> atomic PWM API.

At the risk of revealing my true ignorance, what is the new atomic PWM
API? Where? Examples of how one would convert old code over to the new
API?

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

[Oleksandr Andrushchenko]

On 02/28/2018 09:46 PM, Boris Ostrovsky wrote:

On 02/27/2018 01:52 AM, Oleksandr Andrushchenko wrote:

On 02/27/2018 01:47 AM, Boris Ostrovsky wrote:

On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:

On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+    ret = gem_alloc_pages_array(xen_obj, size);
+    if (ret < 0) {
+    gem_free_pages_array(xen_obj);
+    goto fail;
+    }
+
+    ret = alloc_xenballooned_pages(xen_obj->num_pages,
+    xen_obj->pages);

Why are you allocating balloon pages?

in this use-case we map pages provided by the backend
(yes, I know this can be a problem from both security
POV and that DomU can die holding pages of Dom0 forever:
but still it is a configuration option, so user decides
if her use-case needs this and takes responsibility for
such a decision).

Perhaps I am missing something here but when you say "I know this can be
a problem from both security POV ..." then there is something wrong with
your solution.

well, in this scenario there are actually 2 concerns:
1. If DomU dies the pages/grants from Dom0/DomD cannot be
reclaimed back
2. Misbehaving guest may send too many requests to the
backend exhausting grant references and memory of Dom0/DomD
(this is the only concern from security POV). Please see [1]

But, we are focusing on embedded use-cases,
so those systems we use are not that "dynamic" with respect to 2).
Namely: we have fixed number of domains and their functionality
is well known, so we can do rather precise assumption on resource
usage. This is why I try to warn on such a use-case and rely on
the end user who understands the caveats


How will dom0/backend know whether or not to trust the front end (and
thus whether or not to provide provide pages to it)? Will there be
something in xenstore, for example, to indicate such trusted frontends?
Exactly, there is a dedicated xl configuration option available [1] for 
vdispl:


"be-alloc=BOOLEAN
Indicates if backend can be a buffer provider/allocator for this domain. 
See display protocol for details."


Thus, one can configure this per domain for trusted ones in corresponding
xl configuration files

-boris



I'll probably add more precise description of this use-case
clarifying what is that security POV, so there is no confusion

Hope this explanation answers your questions

-boris


Please see description of the buffering modes in xen_drm_front.h
specifically for backend allocated buffers:
  
***


   * 2. Buffers allocated by the backend
  
***


   *
   * This mode of operation is run-time configured via guest domain
configuration
   * through XenStore entries.
   *
   * For systems which do not provide IOMMU support, but having specific
   * requirements for display buffers it is possible to allocate such
buffers
   * at backend side and share those with the frontend.
   * For example, if host domain is 1:1 mapped and has DRM/GPU hardware
expecting
   * physically contiguous memory, this allows implementing zero-copying
   * use-cases.


-boris


+    if (ret < 0) {
+    DRM_ERROR("Cannot allocate %zu ballooned pages: %d\n",
+    xen_obj->num_pages, ret);
+    goto fail;
+    }
+
+    return xen_obj;
+    }
+    /*
+ * need to allocate backing pages now, so we can share those
+ * with the backend
+ */
+    xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
+    xen_obj->pages = drm_gem_get_pages(_obj->base);
+    if (IS_ERR_OR_NULL(xen_obj->pages)) {
+    ret = PTR_ERR(xen_obj->pages);
+    xen_obj->pages = NULL;
+    goto fail;
+    }
+
+    return xen_obj;
+
+fail:
+    DRM_ERROR("Failed to allocate buffer with size %zu\n", size);
+    return ERR_PTR(ret);
+}
+


Thank you,
Oleksandr

[1]
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03100.html


[1] https://xenbits.xen.org/docs/4.10-testing/man/xl.cfg.5.html

   Indicates if backend can be a buffer provider/allocator for this
   domain. See display protocol for details.

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

Re: [PATCH v2 0/2] drm/panel: Add device link in drm_panel_attach()

[Lukas Wunner]

On Wed, Feb 28, 2018 at 01:09:28PM +0200, Jyri Sarha wrote:
> The device_link_del() is still there in drm_panel_detach(), despite
> Lukas Wunner's comment[1]. In the usual (currently all) cases things
> would work perfectly without the call too, because
> device_links_driver_cleanup() will eventually remove all orphaned
> links. However, this would cause an error in the situation where a drm
> device would like to detach a panel but remain operational, since the
> drm device would be unbound for no good reason if the detached panel
> is later unbound.

Okay, in that case I'd suggest dropping the DL_FLAG_AUTOREMOVE flag
and keep the device_link_del().  That gives you the flexibility to
detach a panel at runtime and drop the device link, but also have
the DRM driver unbound once the panel driver is unbound.

If you have things like optional panels that can be detached without
the necessity to unbind the DRM driver, you need something else instead
of or on top of device links.  Perhaps some kind of notifier block.
And perhaps two drm_panel_attach/detach() helpers in the DRM library,
one with device link and one with notifier.

As stated in the device links documentation, optional dependencies
are "beyond the scope of device links."

Thanks,

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

Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Thierry Reding]

On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
> Add PWM mode to pwm_config() function. The drivers which uses pwm_config()
> were adapted to this change.
> 
> Signed-off-by: Claudiu Beznea 
> ---
>  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
>  drivers/bus/ts-nbus.c|  2 +-
>  drivers/clk/clk-pwm.c|  3 ++-
>  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
>  drivers/hwmon/pwm-fan.c  |  2 +-
>  drivers/input/misc/max77693-haptic.c |  2 +-
>  drivers/input/misc/max8997_haptic.c  |  6 +-
>  drivers/leds/leds-pwm.c  |  5 -
>  drivers/media/rc/ir-rx51.c   |  5 -
>  drivers/media/rc/pwm-ir-tx.c |  5 -
>  drivers/video/backlight/lm3630a_bl.c |  4 +++-
>  drivers/video/backlight/lp855x_bl.c  |  4 +++-
>  drivers/video/backlight/lp8788_bl.c  |  5 -
>  drivers/video/backlight/pwm_bl.c | 11 +--
>  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
>  include/linux/pwm.h  |  6 --
>  16 files changed, 70 insertions(+), 21 deletions(-)

I don't think it makes sense to leak mode support into the legacy API.
The pwm_config() function is considered legacy and should eventually go
away. As such it doesn't make sense to integrate a new feature such as
PWM modes into it. All users of pwm_config() assume normal mode, and
that's what pwm_config() should provide.

Anyone that needs something other than normal mode should use the new
atomic PWM API.

Thierry


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

Re: [PATCH v2 2/2] drm/panel: Add device_link from panel device to drm device

[Lukas Wunner]

On Wed, Feb 28, 2018 at 01:09:30PM +0200, Jyri Sarha wrote:
> Add device_link from panel device (supplier) to drm device (consumer)
> with DL_FLAG_AUTOREMOVE when drm_panel_attach() is called. Currently
> the master drm driver is not protected against the attached. The
> device_link with DL_FLAG_AUTOREMOVE should make sure the drm device is
> unbound before the panel driver becomes unavailable.
> 
> The device_link is removed when drm_panel_detach() is called. The
> drm_panel_detach() should be called by the panel driver it self when
> it is removed. Otherwise the both driver are racing to delete the same
> link.

AFAICS drm_panel_detach() is always called by the DRM drivers, so it's
confusing that you're saying here it should be called by the panel
drivers.  That would also seem to be asymmetric since drm_panel_attach()
is called by the DRM drivers.


> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -89,6 +89,7 @@ struct drm_panel {
>   struct drm_device *drm;
>   struct drm_connector *connector;
>   struct device *dev;
> + struct device_link *link;
>  
>   const struct drm_panel_funcs *funcs;

If you ditch the device_link_del() and use DL_FLAG_AUTOREMOVE only,
you don't need to save the pointer to struct device_link.

Thanks,

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

[DPU PATCH 07/11] drm/msm: Use atomic private_obj instead of subclassing

[Sean Paul]

Instead of subclassing atomic state, store driver private data in
private_obj/state. This allows us to remove the swap_state driver hook
for mdp5 and get closer to using the atomic helpers entirely.

Change-Id: I65a4a2887593ae257d584e00b352b5daf00e4e61
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 37 ++
 drivers/gpu/drm/msm/msm_atomic.c | 30 ---
 drivers/gpu/drm/msm/msm_drv.c| 65 ++--
 drivers/gpu/drm/msm/msm_drv.h|  4 +-
 drivers/gpu/drm/msm/msm_kms.h| 28 +-
 5 files changed, 95 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 6d8e3a9a6fc0..f1a248419655 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -74,36 +74,32 @@ struct mdp5_state *mdp5_get_state(struct drm_atomic_state 
*s)
 {
struct msm_drm_private *priv = s->dev->dev_private;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
-   struct msm_kms_state *state = to_kms_state(s);
-   struct mdp5_state *new_state;
+   struct msm_kms_state *kms_state;
int ret;
 
-   if (state->state)
-   return state->state;
-
ret = drm_modeset_lock(_kms->state_lock, s->acquire_ctx);
if (ret)
return ERR_PTR(ret);
 
-   new_state = kmalloc(sizeof(*mdp5_kms->state), GFP_KERNEL);
-   if (!new_state)
-   return ERR_PTR(-ENOMEM);
+   kms_state = msm_kms_get_state(s);
+   if (IS_ERR_OR_NULL(kms_state))
+   return (struct mdp5_state *)kms_state; /* casting ERR_PTR */
 
-   /* Copy state: */
-   new_state->hwpipe = mdp5_kms->state->hwpipe;
-   new_state->hwmixer = mdp5_kms->state->hwmixer;
-   if (mdp5_kms->smp)
-   new_state->smp = mdp5_kms->state->smp;
+   return kms_state->state;
+}
 
-   state->state = new_state;
+static void *mdp5_duplicate_state(void *state)
+{
+   if (!state)
+   return kzalloc(sizeof(struct mdp5_state), GFP_KERNEL);
 
-   return new_state;
+   return kmemdup(state, sizeof(struct mdp5_state), GFP_KERNEL);
 }
 
-static void mdp5_swap_state(struct msm_kms *kms, struct drm_atomic_state 
*state)
+static void mdp5_destroy_state(void *state)
 {
-   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
-   swap(to_kms_state(state)->state, mdp5_kms->state);
+   struct mdp5_state *mdp_state = state;
+   kfree(mdp_state);
 }
 
 static void mdp5_prepare_commit(struct msm_kms *kms, struct drm_atomic_state 
*state)
@@ -229,7 +225,8 @@ static const struct mdp_kms_funcs kms_funcs = {
.irq = mdp5_irq,
.enable_vblank   = mdp5_enable_vblank,
.disable_vblank  = mdp5_disable_vblank,
-   .swap_state  = mdp5_swap_state,
+   .duplicate_state = mdp5_duplicate_state,
+   .destroy_state   = mdp5_destroy_state,
.prepare_commit  = mdp5_prepare_commit,
.complete_commit = mdp5_complete_commit,
.wait_for_crtc_commit_done = mdp5_wait_for_crtc_commit_done,
@@ -726,8 +723,6 @@ static void mdp5_destroy(struct platform_device *pdev)
 
if (mdp5_kms->rpm_enabled)
pm_runtime_disable(>dev);
-
-   kfree(mdp5_kms->state);
 }
 
 static int construct_pipes(struct mdp5_kms *mdp5_kms, int cnt,
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 7e54eb65d096..1f53262ea46b 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -169,9 +169,6 @@ int msm_atomic_commit(struct drm_device *dev,
 */
BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
 
-   if (to_kms_state(state)->state)
-   priv->kms->funcs->swap_state(priv->kms, state);
-
/*
 * Provide the driver a chance to prepare for output fences. This is
 * done after the point of no return, but before asynchronous commits
@@ -210,30 +207,3 @@ int msm_atomic_commit(struct drm_device *dev,
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
 }
-
-struct drm_atomic_state *msm_atomic_state_alloc(struct drm_device *dev)
-{
-   struct msm_kms_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
-
-   if (!state || drm_atomic_state_init(dev, >base) < 0) {
-   kfree(state);
-   return NULL;
-   }
-
-   return >base;
-}
-
-void msm_atomic_state_clear(struct drm_atomic_state *s)
-{
-   struct msm_kms_state *state = to_kms_state(s);
-   drm_atomic_state_default_clear(>base);
-   kfree(state->state);
-   state->state = NULL;
-}
-
-void msm_atomic_state_free(struct drm_atomic_state *state)
-{
-   kfree(to_kms_state(state)->state);
-   drm_atomic_state_default_release(state);
-   

[DPU PATCH 11/11] drm/msm: Remove dpu input fences

[Sean Paul]

These are already provided by drm atomic core.

In conjunction with the output fences removed earlier, this obsoletes
dpu_fence, and it can be entirely removed as well.

Change-Id: Ida4924a09c455d7a84bfee569bd0d2fb436418de
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/Makefile  |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  84 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_fence.c | 404 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_fence.h | 190 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 104 --
 drivers/gpu/drm/msm/msm_drv.h |   4 +-
 6 files changed, 1 insertion(+), 786 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_fence.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_fence.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 2fb9ba11df19..b47ef5267e19 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -55,7 +55,6 @@ msm-y := \
disp/dpu1/dpu_encoder.o \
disp/dpu1/dpu_encoder_phys_cmd.o \
disp/dpu1/dpu_encoder_phys_vid.o \
-   disp/dpu1/dpu_fence.o \
disp/dpu1/dpu_formats.o \
disp/dpu1/dpu_hw_ad4.o \
disp/dpu1/dpu_hw_blk.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 2d44989ade7a..8dd986e476bd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -64,16 +64,6 @@ static struct dpu_crtc_custom_events custom_events[] = {
{DRM_EVENT_IDLE_NOTIFY, dpu_crtc_idle_interrupt_handler}
 };
 
-/* default input fence timeout, in ms */
-#define DPU_CRTC_INPUT_FENCE_TIMEOUT1
-
-/*
- * The default input fence timeout is 2 seconds while max allowed
- * range is 10 seconds. Any value above 10 seconds adds glitches beyond
- * tolerance limit.
- */
-#define DPU_CRTC_MAX_INPUT_FENCE_TIMEOUT 1
-
 /* layer mixer index on dpu_crtc */
 #define LEFT_MIXER 0
 #define RIGHT_MIXER 1
@@ -1946,21 +1936,6 @@ static void _dpu_crtc_set_idle_timeout(struct drm_crtc 
*crtc, u64 val)
}
 }
 
-/**
- * _dpu_crtc_set_input_fence_timeout - update ns version of in fence timeout
- * @cstate: Pointer to dpu crtc state
- */
-static void _dpu_crtc_set_input_fence_timeout(struct dpu_crtc_state *cstate)
-{
-   if (!cstate) {
-   DPU_ERROR("invalid cstate\n");
-   return;
-   }
-   cstate->input_fence_timeout_ns =
-   dpu_crtc_get_property(cstate, CRTC_PROP_INPUT_FENCE_TIMEOUT);
-   cstate->input_fence_timeout_ns *= NSEC_PER_MSEC;
-}
-
 /**
  * _dpu_crtc_set_dim_layer_v1 - copy dim layer settings from userspace
  * @cstate:  Pointer to dpu crtc state
@@ -2385,53 +2360,6 @@ static int _dpu_crtc_check_dest_scaler_data(struct 
drm_crtc *crtc,
return ret;
 }
 
-/**
- * _dpu_crtc_wait_for_fences - wait for incoming framebuffer sync fences
- * @crtc: Pointer to CRTC object
- */
-static void _dpu_crtc_wait_for_fences(struct drm_crtc *crtc)
-{
-   struct drm_plane *plane = NULL;
-   uint32_t wait_ms = 1;
-   ktime_t kt_end, kt_wait;
-   int rc = 0;
-
-   DPU_DEBUG("\n");
-
-   if (!crtc || !crtc->state) {
-   DPU_ERROR("invalid crtc/state %pK\n", crtc);
-   return;
-   }
-
-   /* use monotonic timer to limit total fence wait time */
-   kt_end = ktime_add_ns(ktime_get(),
-   to_dpu_crtc_state(crtc->state)->input_fence_timeout_ns);
-
-   /*
-* Wait for fences sequentially, as all of them need to be signalled
-* before we can proceed.
-*
-* Limit total wait time to INPUT_FENCE_TIMEOUT, but still call
-* dpu_plane_wait_input_fence with wait_ms == 0 after the timeout so
-* that each plane can check its fence status and react appropriately
-* if its fence has timed out. Call input fence wait multiple times if
-* fence wait is interrupted due to interrupt call.
-*/
-   DPU_ATRACE_BEGIN("plane_wait_input_fence");
-   drm_atomic_crtc_for_each_plane(plane, crtc) {
-   do {
-   kt_wait = ktime_sub(kt_end, ktime_get());
-   if (ktime_compare(kt_wait, ktime_set(0, 0)) >= 0)
-   wait_ms = ktime_to_ms(kt_wait);
-   else
-   wait_ms = 0;
-
-   rc = dpu_plane_wait_input_fence(plane, wait_ms);
-   } while (wait_ms && rc == -ERESTARTSYS);
-   }
-   DPU_ATRACE_END("plane_wait_input_fence");
-}
-
 static void _dpu_crtc_setup_mixer_for_encoder(
struct drm_crtc *crtc,
struct drm_encoder *enc)
@@ -2716,9 +2644,6 @@ static void dpu_crtc_atomic_flush(struct drm_crtc *crtc,
drm_atomic_crtc_for_each_plane(plane, crtc)
dpu_plane_restore(plane);
 
-   /* wait for acquire fences before anything else 

[DPU PATCH 06/11] drm/msm: Remove msm_commit/kthread, use atomic helper commit

[Sean Paul]

Moving further towards switching fully to the the atomic helpers, this
patch removes the hand-rolled kthread nonblock commit code and uses the
atomic helpers commit_work model.

There's still a lot of copypasta here, but it's still needed to
facilitate the swap_state and prepare_fence private functions. These
will be sorted out in a follow-on patch.

Change-Id: I9fcba27824ba63d3fab96cb2bc194bfa6f3475b7
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/msm_atomic.c | 199 ++-
 drivers/gpu/drm/msm/msm_drv.c|   1 -
 drivers/gpu/drm/msm/msm_drv.h|   4 -
 3 files changed, 35 insertions(+), 169 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 3a18bd3dc215..7e54eb65d096 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -21,51 +21,6 @@
 #include "msm_gem.h"
 #include "msm_fence.h"
 
-struct msm_commit {
-   struct drm_device *dev;
-   struct drm_atomic_state *state;
-   uint32_t crtc_mask;
-   bool nonblock;
-   struct kthread_work commit_work;
-};
-
-/* block until specified crtcs are no longer pending update, and
- * atomically mark them as pending update
- */
-static int start_atomic(struct msm_drm_private *priv, uint32_t crtc_mask)
-{
-   int ret;
-
-   spin_lock(>pending_crtcs_event.lock);
-   ret = wait_event_interruptible_locked(priv->pending_crtcs_event,
-   !(priv->pending_crtcs & crtc_mask));
-   if (ret == 0) {
-   DBG("start: %08x", crtc_mask);
-   priv->pending_crtcs |= crtc_mask;
-   }
-   spin_unlock(>pending_crtcs_event.lock);
-
-   return ret;
-}
-
-/* clear specified crtcs (no longer pending update)
- */
-static void end_atomic(struct msm_drm_private *priv, uint32_t crtc_mask)
-{
-   spin_lock(>pending_crtcs_event.lock);
-   DBG("end: %08x", crtc_mask);
-   priv->pending_crtcs &= ~crtc_mask;
-   wake_up_all_locked(>pending_crtcs_event);
-   spin_unlock(>pending_crtcs_event.lock);
-}
-
-static void commit_destroy(struct msm_commit *c)
-{
-   end_atomic(c->dev->dev_private, c->crtc_mask);
-   if (c->nonblock)
-   kfree(c);
-}
-
 static void msm_atomic_wait_for_commit_done(
struct drm_device *dev,
struct drm_atomic_state *old_state)
@@ -118,6 +73,10 @@ static void msm_atomic_commit_tail(struct drm_atomic_state 
*state)
 
msm_atomic_wait_for_commit_done(dev, state);
 
+   drm_atomic_helper_commit_hw_done(state);
+
+   drm_atomic_helper_wait_for_vblanks(dev, state);
+
drm_atomic_helper_cleanup_planes(dev, state);
 
kms->funcs->complete_commit(kms, state);
@@ -126,109 +85,25 @@ static void msm_atomic_commit_tail(struct 
drm_atomic_state *state)
 /* The (potentially) asynchronous part of the commit.  At this point
  * nothing can fail short of armageddon.
  */
-static void complete_commit(struct msm_commit *c)
+static void commit_tail(struct drm_atomic_state *state)
 {
-   struct drm_atomic_state *state = c->state;
-   struct drm_device *dev = state->dev;
+   drm_atomic_helper_wait_for_fences(state->dev, state, false);
 
-   drm_atomic_helper_wait_for_fences(dev, state, false);
+   drm_atomic_helper_wait_for_dependencies(state);
 
msm_atomic_commit_tail(state);
 
-   drm_atomic_state_put(state);
-}
-
-static void _msm_drm_commit_work_cb(struct kthread_work *work)
-{
-   struct msm_commit *commit =  NULL;
-
-   if (!work) {
-   DRM_ERROR("%s: Invalid commit work data!\n", __func__);
-   return;
-   }
-
-   commit = container_of(work, struct msm_commit, commit_work);
-
-   complete_commit(commit);
-
-   commit_destroy(commit);
-}
-
-static struct msm_commit *commit_init(struct drm_atomic_state *state,
-   bool nonblock)
-{
-   struct msm_commit *c = kzalloc(sizeof(*c), GFP_KERNEL);
+   drm_atomic_helper_commit_cleanup_done(state);
 
-   if (!c)
-   return NULL;
-
-   c->dev = state->dev;
-   c->state = state;
-   c->nonblock = nonblock;
-
-   kthread_init_work(>commit_work, _msm_drm_commit_work_cb);
-
-   return c;
+   drm_atomic_state_put(state);
 }
 
-/* Start display thread function */
-static void msm_atomic_commit_dispatch(struct drm_device *dev,
-   struct drm_atomic_state *state, struct msm_commit *commit)
+static void commit_work(struct work_struct *work)
 {
-   struct msm_drm_private *priv = dev->dev_private;
-   struct drm_crtc *crtc = NULL;
-   struct drm_crtc_state *new_crtc_state = NULL;
-   int ret = -EINVAL, i = 0, j = 0;
-   bool nonblock;
-
-   /* cache since work will kfree commit in non-blocking case */
-   nonblock = commit->nonblock;
-
-   for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
-   for (j = 0; j < priv->num_crtcs; j++) {
-  

[DPU PATCH 09/11] drm/msm: Remove prepare_fence kms_function

[Sean Paul]

This is the last piece that is keeping us from matching the atomic
helper commit function. By removing this (now unused) hook, we can
switch to drm_atomic_helper_commit()

Change-Id: I081056a6e1689807871f5deedc76499bb91b6969
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/msm_atomic.c | 10 --
 drivers/gpu/drm/msm/msm_kms.h|  2 --
 2 files changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 1f53262ea46b..204c66cbfd31 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -169,16 +169,6 @@ int msm_atomic_commit(struct drm_device *dev,
 */
BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
 
-   /*
-* Provide the driver a chance to prepare for output fences. This is
-* done after the point of no return, but before asynchronous commits
-* are dispatched to work queues, so that the fence preparation is
-* finished before the .atomic_commit returns.
-*/
-   if (priv && priv->kms && priv->kms->funcs &&
-   priv->kms->funcs->prepare_fence)
-   priv->kms->funcs->prepare_fence(priv->kms, state);
-
/*
 * Everything below can be run asynchronously without the need to grab
 * any modeset locks at all under one conditions: It must be guaranteed
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 4c5a69258c42..25800c046bd1 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -60,8 +60,6 @@ struct msm_kms_funcs {
void *(*duplicate_state)(void *state);
void (*destroy_state)(void *state);
/* modeset, bracketing atomic_commit(): */
-   void (*prepare_fence)(struct msm_kms *kms,
-   struct drm_atomic_state *state);
void (*prepare_commit)(struct msm_kms *kms,
struct drm_atomic_state *state);
void (*commit)(struct msm_kms *kms, struct drm_atomic_state *state);
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[DPU PATCH 05/11] drm/msm: Mark the crtc->state->event consumed

[Sean Paul]

Don't leave the event != NULL once it's consumed, this is used a signal
to the atomic helpers that the event will be handled by the driver.

Change-Id: Ib934fb2e97bacbb4a1f9c780cc7369c2bb98ed50
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 2 ++
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 1 +
 3 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 94fab2dcca5b..a261021e5deb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -2714,6 +2714,7 @@ static void dpu_crtc_atomic_begin(struct drm_crtc *crtc,
} else {
spin_lock_irqsave(>event_lock, flags);
dpu_crtc->event = crtc->state->event;
+   crtc->state->event = NULL;
spin_unlock_irqrestore(>event_lock, flags);
}
 
@@ -2798,6 +2799,7 @@ static void dpu_crtc_atomic_flush(struct drm_crtc *crtc,
} else {
spin_lock_irqsave(>event_lock, flags);
dpu_crtc->event = crtc->state->event;
+   crtc->state->event = NULL;
spin_unlock_irqrestore(>event_lock, flags);
}
 
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
index 6e5e1aa54ce1..b001699297c4 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
@@ -351,6 +351,7 @@ static void mdp4_crtc_atomic_flush(struct drm_crtc *crtc,
 
spin_lock_irqsave(>event_lock, flags);
mdp4_crtc->event = crtc->state->event;
+   crtc->state->event = NULL;
spin_unlock_irqrestore(>event_lock, flags);
 
blend_setup(crtc);
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 8c5ed0b59e46..5cb490a58f20 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -704,6 +704,7 @@ static void mdp5_crtc_atomic_flush(struct drm_crtc *crtc,
 
spin_lock_irqsave(>event_lock, flags);
mdp5_crtc->event = crtc->state->event;
+   crtc->state->event = NULL;
spin_unlock_irqrestore(>event_lock, flags);
 
/*
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[DPU PATCH 10/11] drm/msm: Switch to atomic_helper_commit()

[Sean Paul]

Now that all of the msm-specific goo is tucked safely away we can switch
over to using the atomic helper commit directly. \o/

Change-Id: Ieab0bd0c526b2a9d3b3345eeba402ac4857fe418
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/msm_atomic.c | 120 +--
 drivers/gpu/drm/msm/msm_drv.c|   7 +-
 drivers/gpu/drm/msm/msm_drv.h|   3 +-
 3 files changed, 8 insertions(+), 122 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 204c66cbfd31..91ffded576d8 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -18,8 +18,6 @@
 
 #include "msm_drv.h"
 #include "msm_kms.h"
-#include "msm_gem.h"
-#include "msm_fence.h"
 
 static void msm_atomic_wait_for_commit_done(
struct drm_device *dev,
@@ -39,7 +37,7 @@ static void msm_atomic_wait_for_commit_done(
}
 }
 
-static void msm_atomic_commit_tail(struct drm_atomic_state *state)
+void msm_atomic_commit_tail(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
struct msm_drm_private *priv = dev->dev_private;
@@ -81,119 +79,3 @@ static void msm_atomic_commit_tail(struct drm_atomic_state 
*state)
 
kms->funcs->complete_commit(kms, state);
 }
-
-/* The (potentially) asynchronous part of the commit.  At this point
- * nothing can fail short of armageddon.
- */
-static void commit_tail(struct drm_atomic_state *state)
-{
-   drm_atomic_helper_wait_for_fences(state->dev, state, false);
-
-   drm_atomic_helper_wait_for_dependencies(state);
-
-   msm_atomic_commit_tail(state);
-
-   drm_atomic_helper_commit_cleanup_done(state);
-
-   drm_atomic_state_put(state);
-}
-
-static void commit_work(struct work_struct *work)
-{
-   struct drm_atomic_state *state = container_of(work,
- struct drm_atomic_state,
- commit_work);
-   commit_tail(state);
-}
-
-/**
- * drm_atomic_helper_commit - commit validated state object
- * @dev: DRM device
- * @state: the driver state object
- * @nonblock: nonblocking commit
- *
- * This function commits a with drm_atomic_helper_check() pre-validated state
- * object. This can still fail when e.g. the framebuffer reservation fails.
- *
- * RETURNS
- * Zero for success or -errno.
- */
-int msm_atomic_commit(struct drm_device *dev,
-   struct drm_atomic_state *state, bool nonblock)
-{
-   struct msm_drm_private *priv = dev->dev_private;
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
-   struct drm_plane *plane;
-   struct drm_plane_state *old_plane_state, *new_plane_state;
-   int i, ret;
-
-   /*
-* Note that plane->atomic_async_check() should fail if we need
-* to re-assign hwpipe or anything that touches global atomic
-* state, so we'll never go down the async update path in those
-* cases.
-*/
-   if (state->async_update) {
-   ret = drm_atomic_helper_prepare_planes(dev, state);
-   if (ret)
-   return ret;
-
-   drm_atomic_helper_async_commit(dev, state);
-   drm_atomic_helper_cleanup_planes(dev, state);
-   return 0;
-   }
-
-   ret = drm_atomic_helper_setup_commit(state, nonblock);
-   if (ret)
-   return ret;
-
-   INIT_WORK(>commit_work, commit_work);
-
-   ret = drm_atomic_helper_prepare_planes(dev, state);
-   if (ret)
-   return ret;
-
-   if (!nonblock) {
-   ret = drm_atomic_helper_wait_for_fences(dev, state, true);
-   if (ret)
-   goto error;
-   }
-
-   /*
-* This is the point of no return - everything below never fails except
-* when the hw goes bonghits. Which means we can commit the new state on
-* the software side now.
-*
-* swap driver private state while still holding state_lock
-*/
-   BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
-
-   /*
-* Everything below can be run asynchronously without the need to grab
-* any modeset locks at all under one conditions: It must be guaranteed
-* that the asynchronous work has either been cancelled (if the driver
-* supports it, which at least requires that the framebuffers get
-* cleaned up with drm_atomic_helper_cleanup_planes()) or completed
-* before the new state gets committed on the software side with
-* drm_atomic_helper_swap_state().
-*
-* This scheme allows new atomic state updates to be prepared and
-* checked in parallel to the asynchronous completion of the previous
-* update. Which is important since compositors need to figure out the
-* composition of the next frame right after having submitted the
-* 

[DPU PATCH 03/11] drm/msm: Refactor complete_commit() to look more the helpers

[Sean Paul]

Factor out the commit_tail() portions of complete_commit() into a
separate function to facilitate moving to the atomic helpers in future
patches.

Change-Id: I4b858ad9fe356b31ed0ed9eecdb394a61048e39c
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/msm_atomic.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index f5794dce25dd..eb2ccda5da0f 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -84,18 +84,12 @@ static void msm_atomic_wait_for_commit_done(
}
 }
 
-/* The (potentially) asynchronous part of the commit.  At this point
- * nothing can fail short of armageddon.
- */
-static void complete_commit(struct msm_commit *c)
+static void msm_atomic_commit_tail(struct drm_atomic_state *state)
 {
-   struct drm_atomic_state *state = c->state;
struct drm_device *dev = state->dev;
struct msm_drm_private *priv = dev->dev_private;
struct msm_kms *kms = priv->kms;
 
-   drm_atomic_helper_wait_for_fences(dev, state, false);
-
kms->funcs->prepare_commit(kms, state);
 
drm_atomic_helper_commit_modeset_disables(dev, state);
@@ -127,10 +121,21 @@ static void complete_commit(struct msm_commit *c)
drm_atomic_helper_cleanup_planes(dev, state);
 
kms->funcs->complete_commit(kms, state);
+}
 
-   drm_atomic_state_put(state);
+/* The (potentially) asynchronous part of the commit.  At this point
+ * nothing can fail short of armageddon.
+ */
+static void complete_commit(struct msm_commit *c)
+{
+   struct drm_atomic_state *state = c->state;
+   struct drm_device *dev = state->dev;
 
-   commit_destroy(c);
+   drm_atomic_helper_wait_for_fences(dev, state, false);
+
+   msm_atomic_commit_tail(state);
+
+   drm_atomic_state_put(state);
 }
 
 static void _msm_drm_commit_work_cb(struct kthread_work *work)
@@ -145,6 +150,8 @@ static void _msm_drm_commit_work_cb(struct kthread_work 
*work)
commit = container_of(work, struct msm_commit, commit_work);
 
complete_commit(commit);
+
+   commit_destroy(commit);
 }
 
 static struct msm_commit *commit_init(struct drm_atomic_state *state,
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[DPU PATCH 08/11] drm/msm: Remove hand-rolled out fences

[Sean Paul]

Remove release/output/retire fences from the dpu driver. These are
already available via drm core's OUT_FENCE property.

Change-Id: Id4238d0b5457f2c8ee2e87bb7814e1850a573623
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c |  66 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h |  23 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 178 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h  |  28 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   |   3 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h   |   4 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h  |   8 -
 .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c  |  73 +--
 .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c  |  19 --
 .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c   |  12 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  30 ---
 drivers/gpu/drm/msm/msm_drv.h |   3 -
 12 files changed, 36 insertions(+), 411 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
index 57b8627ef418..cc5bfa862cb7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
@@ -521,7 +521,6 @@ static void dpu_connector_destroy(struct drm_connector 
*connector)
backlight_device_unregister(c_conn->bl_device);
drm_connector_unregister(connector);
mutex_destroy(_conn->lock);
-   dpu_fence_deinit(_conn->retire_fence);
drm_connector_cleanup(connector);
kfree(c_conn);
 }
@@ -906,12 +905,9 @@ static int dpu_connector_atomic_get_property(struct 
drm_connector *connector,
c_state = to_dpu_connector_state(state);
 
idx = msm_property_index(_conn->property_info, property);
-   if (idx == CONNECTOR_PROP_RETIRE_FENCE)
-   rc = dpu_fence_create(_conn->retire_fence, val, 0);
-   else
-   /* get cached property value */
-   rc = msm_property_atomic_get(_conn->property_info,
-   _state->property_state, property, val);
+   /* get cached property value */
+   rc = msm_property_atomic_get(_conn->property_info,
+   _state->property_state, property, val);
 
/* allow for custom override */
if (c_conn->ops.get_property)
@@ -923,39 +919,6 @@ static int dpu_connector_atomic_get_property(struct 
drm_connector *connector,
return rc;
 }
 
-void dpu_connector_prepare_fence(struct drm_connector *connector)
-{
-   if (!connector) {
-   DPU_ERROR("invalid connector\n");
-   return;
-   }
-
-   dpu_fence_prepare(_dpu_connector(connector)->retire_fence);
-}
-
-void dpu_connector_complete_commit(struct drm_connector *connector,
-   ktime_t ts)
-{
-   if (!connector) {
-   DPU_ERROR("invalid connector\n");
-   return;
-   }
-
-   /* signal connector's retire fence */
-   dpu_fence_signal(_dpu_connector(connector)->retire_fence, ts, false);
-}
-
-void dpu_connector_commit_reset(struct drm_connector *connector, ktime_t ts)
-{
-   if (!connector) {
-   DPU_ERROR("invalid connector\n");
-   return;
-   }
-
-   /* signal connector's retire fence */
-   dpu_fence_signal(_dpu_connector(connector)->retire_fence, ts, true);
-}
-
 static enum drm_connector_status
 dpu_connector_detect(struct drm_connector *connector, bool force)
 {
@@ -1214,26 +1177,19 @@ struct drm_connector *dpu_connector_init(struct 
drm_device *dev,
"conn%u",
c_conn->base.base.id);
 
-   rc = dpu_fence_init(_conn->retire_fence, c_conn->name,
-   c_conn->base.base.id);
-   if (rc) {
-   DPU_ERROR("failed to init fence, %d\n", rc);
-   goto error_cleanup_conn;
-   }
-
mutex_init(_conn->lock);
 
rc = drm_mode_connector_attach_encoder(_conn->base, encoder);
if (rc) {
DPU_ERROR("failed to attach encoder to connector, %d\n", rc);
-   goto error_cleanup_fence;
+   goto error_cleanup_conn;
}
 
 #ifdef CONFIG_DRM_MSM_DSI_STAGING
rc = dpu_backlight_setup(c_conn, dev);
if (rc) {
DPU_ERROR("failed to setup backlight, rc=%d\n", rc);
-   goto error_cleanup_fence;
+   goto error_cleanup_conn;
}
 #endif
 
@@ -1248,7 +1204,7 @@ struct drm_connector *dpu_connector_init(struct 
drm_device *dev,
if (!info) {
DPU_ERROR("failed to allocate info buffer\n");
rc = -ENOMEM;
-   goto error_cleanup_fence;
+   goto error_cleanup_conn;
}
 
dpu_kms_info_reset(info);
@@ -1256,7 +1212,7 @@ struct drm_connector *dpu_connector_init(struct 
drm_device *dev,
if (rc) {
  

[DPU PATCH 02/11] drm/msm: Don't duplicate modeset_enables atomic helper

[Sean Paul]

Instead, shuffle things around so we kickoff crtc after enabling encoder
during modesets. Also moves the vblank wait to after the frame.

Change-Id: I16c7b7f9390d04f6050aa20e17a5335fbf49eba3
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|   9 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |   5 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  31 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |   2 +
 drivers/gpu/drm/msm/msm_atomic.c| 132 +---
 5 files changed, 48 insertions(+), 131 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index a3ab6ed2bf1d..94fab2dcca5b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -3525,6 +3525,12 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
DPU_EVT32_VERBOSE(DRMID(crtc));
dpu_crtc = to_dpu_crtc(crtc);
 
+   if (msm_is_mode_seamless(>state->adjusted_mode) ||
+   msm_is_mode_seamless_vrr(>state->adjusted_mode)) {
+   DPU_DEBUG("Skipping crtc enable, seamless mode\n");
+   return;
+   }
+
pm_runtime_get_sync(crtc->dev->dev);
 
drm_for_each_encoder(encoder, crtc->dev) {
@@ -3572,6 +3578,9 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
DPU_POWER_EVENT_POST_ENABLE | DPU_POWER_EVENT_POST_DISABLE |
DPU_POWER_EVENT_PRE_DISABLE,
dpu_crtc_handle_power_event, crtc, dpu_crtc->name);
+
+   if (msm_needs_vblank_pre_modeset(>state->adjusted_mode))
+   drm_crtc_wait_one_vblank(crtc);
 }
 
 struct plane_state {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 28ceb589ee40..4d1e3652dbf4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -3693,8 +3693,11 @@ static void dpu_encoder_frame_done_timeout(struct 
timer_list *t)
 static const struct drm_encoder_helper_funcs dpu_encoder_helper_funcs = {
.mode_set = dpu_encoder_virt_mode_set,
.disable = dpu_encoder_virt_disable,
-   .enable = dpu_encoder_virt_enable,
+   .enable = dpu_kms_encoder_enable,
.atomic_check = dpu_encoder_virt_atomic_check,
+
+   /* This is called by dpu_kms_encoder_enable */
+   .commit = dpu_encoder_virt_enable,
 };
 
 static const struct drm_encoder_funcs dpu_encoder_funcs = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 81fd3a429e9f..3d83037e8305 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -425,14 +425,37 @@ static void dpu_kms_prepare_commit(struct msm_kms *kms,
dpu_encoder_prepare_commit(encoder);
 }
 
-static void dpu_kms_commit(struct msm_kms *kms,
-   struct drm_atomic_state *old_state)
+/*
+ * Override the encoder enable since we need to setup the inline rotator and do
+ * some crtc magic before enabling any bridge that might be present.
+ */
+void dpu_kms_encoder_enable(struct drm_encoder *encoder)
+{
+   const struct drm_encoder_helper_funcs *funcs = encoder->helper_private;
+   struct drm_crtc *crtc = encoder->crtc;
+
+   /* Forward this enable call to the commit hook */
+   if (funcs && funcs->commit)
+   funcs->commit(encoder);
+
+   if (crtc && crtc->state->active) {
+   DPU_EVT32(DRMID(crtc));
+   dpu_crtc_commit_kickoff(crtc);
+   }
+}
+
+static void dpu_kms_commit(struct msm_kms *kms, struct drm_atomic_state *state)
 {
struct drm_crtc *crtc;
-   struct drm_crtc_state *old_crtc_state;
+   struct drm_crtc_state *crtc_state;
+   struct dpu_crtc_state *cstate;
int i;
 
-   for_each_old_crtc_in_state(old_state, crtc, old_crtc_state, i) {
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   /* If modeset is required, kickoff is run in encoder_enable */
+   if (drm_atomic_crtc_needs_modeset(crtc_state))
+   continue;
+
if (crtc->state->active) {
DPU_EVT32(DRMID(crtc));
dpu_crtc_commit_kickoff(crtc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 8cadd29a48b1..42c809ed9467 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -529,4 +529,6 @@ int dpu_kms_fbo_reference(struct dpu_kms_fbo *fbo);
  */
 void dpu_kms_fbo_unreference(struct dpu_kms_fbo *fbo);
 
+void dpu_kms_encoder_enable(struct drm_encoder *encoder);
+
 #endif /* __dpu_kms_H__ */
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 5cfb80345052..f5794dce25dd 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -84,131 

[DPU PATCH 00/11] drm/msm: Use atomic helper functions for msm

[Sean Paul]

Hey!
This set converts msm to using the atomic helper functions for commit. 
In order to do this, I needed to do the following:

Relocate/remove the copied atomic helper code from msm_atomic:
  Most of this was to deal with seamless modesets introduced in the dpu.
  I'll need to revisit the seamless code soon, but for the purpose of this
  set, moving it down into the driver was fine.

Remove the kthread commit code to do nonblock:
  I think this is an artifact of dpu being forward-ported since 4.4. Now
  that the core has a commit worker, we can use that.

Remove the dpu fences:
  Core has these as well, so we can just nuke them.

Convert mdp5 to use atomic_private_obj:
  By using the private_obj, I could remove the kms->funcs->swap_state()
  hook in atomic commit.


I think this could apply to msm-next pretty easily by taking the
private_obj + event clearing + atomic_helper_commit patches, but I
haven't tried to do that atm.

I think I'll tackle the build warnings next, to ensure I'm not
introducing more.

Sean


Sean Paul (11):
  drm/msm: Skip seamless disables in crtc/encoder
  drm/msm: Don't duplicate modeset_enables atomic helper
  drm/msm: Refactor complete_commit() to look more the helpers
  drm/msm: Move implicit sync fence handling to prepare_fb
  drm/msm: Mark the crtc->state->event consumed
  drm/msm: Remove msm_commit/kthread, use atomic helper commit
  drm/msm: Use atomic private_obj instead of subclassing
  drm/msm: Remove hand-rolled out fences
  drm/msm: Remove prepare_fence kms_function
  drm/msm: Switch to atomic_helper_commit()
  drm/msm: Remove dpu input fences

 drivers/gpu/drm/msm/Makefile  |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c |  66 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h |  23 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 281 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h  |  28 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   |  16 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h   |   4 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h  |   8 -
 .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c  |  73 +--
 .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c  |  19 -
 .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c   |  12 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_fence.c | 404 
 drivers/gpu/drm/msm/disp/dpu1/dpu_fence.h | 190 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  61 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 112 +---
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c |   1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |   1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  |  37 +-
 drivers/gpu/drm/msm/msm_atomic.c  | 616 +-
 drivers/gpu/drm/msm/msm_drv.c |  73 ++-
 drivers/gpu/drm/msm/msm_drv.h |  18 +-
 drivers/gpu/drm/msm/msm_kms.h |  30 +-
 23 files changed, 219 insertions(+), 1857 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_fence.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_fence.h

-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[DPU PATCH 01/11] drm/msm: Skip seamless disables in crtc/encoder

[Sean Paul]

Instead of duplicating whole swaths of atomic helper functions (which
are already out-of-date), just skip the encoder/crtc disables in the
.disable hooks.

Change-Id: I7bd9183ae60624204fb1de9550656b776efc7202
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|   8 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |   8 +
 drivers/gpu/drm/msm/msm_atomic.c| 185 +---
 3 files changed, 17 insertions(+), 184 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 3cdf1e3d9d96..a3ab6ed2bf1d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -3393,6 +3393,7 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
 {
struct dpu_crtc *dpu_crtc;
struct dpu_crtc_state *cstate;
+   struct drm_display_mode *mode;
struct drm_encoder *encoder;
struct msm_drm_private *priv;
unsigned long flags;
@@ -3407,8 +3408,15 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
}
dpu_crtc = to_dpu_crtc(crtc);
cstate = to_dpu_crtc_state(crtc->state);
+   mode = >base.adjusted_mode;
priv = crtc->dev->dev_private;
 
+   if (msm_is_mode_seamless(mode) || msm_is_mode_seamless_vrr(mode) ||
+   msm_is_mode_seamless_dms(mode)) {
+   DPU_DEBUG("Seamless mode is being applied, skip disable\n");
+   return;
+   }
+
DPU_DEBUG("crtc%d\n", crtc->base.id);
 
if (dpu_kms_is_suspend_state(crtc->dev))
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3d168fa09f3f..28ceb589ee40 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2183,6 +2183,7 @@ static void dpu_encoder_virt_disable(struct drm_encoder 
*drm_enc)
struct dpu_encoder_virt *dpu_enc = NULL;
struct msm_drm_private *priv;
struct dpu_kms *dpu_kms;
+   struct drm_display_mode *mode;
int i = 0;
 
if (!drm_enc) {
@@ -2196,6 +2197,13 @@ static void dpu_encoder_virt_disable(struct drm_encoder 
*drm_enc)
return;
}
 
+   mode = _enc->crtc->state->adjusted_mode;
+   if (msm_is_mode_seamless(mode) || msm_is_mode_seamless_vrr(mode) ||
+   msm_is_mode_seamless_dms(mode)) {
+   DPU_DEBUG("Seamless mode is being applied, skip disable\n");
+   return;
+   }
+
dpu_enc = to_dpu_encoder_virt(drm_enc);
DPU_DEBUG_ENC(dpu_enc, "\n");
 
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 46536edb72ee..5cfb80345052 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -84,189 +84,6 @@ static void msm_atomic_wait_for_commit_done(
}
 }
 
-static void
-msm_disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
-{
-   struct drm_connector *connector;
-   struct drm_connector_state *old_conn_state, *new_conn_state;
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
-   int i;
-
-   for_each_oldnew_connector_in_state(old_state, connector, 
old_conn_state, new_conn_state, i) {
-   const struct drm_encoder_helper_funcs *funcs;
-   struct drm_encoder *encoder;
-   struct drm_crtc_state *old_crtc_state;
-   unsigned int crtc_idx;
-
-   /*
-* Shut down everything that's in the changeset and currently
-* still on. So need to check the old, saved state.
-*/
-   if (!old_conn_state->crtc)
-   continue;
-
-   crtc_idx = drm_crtc_index(old_conn_state->crtc);
-   old_crtc_state = drm_atomic_get_old_crtc_state(old_state,
-   old_conn_state->crtc);
-
-   if (!old_crtc_state->active ||
-   !drm_atomic_crtc_needs_modeset(old_conn_state->crtc->state))
-   continue;
-
-   encoder = old_conn_state->best_encoder;
-
-   /* We shouldn't get this far if we didn't previously have
-* an encoder.. but WARN_ON() rather than explode.
-*/
-   if (WARN_ON(!encoder))
-   continue;
-
-   if (msm_is_mode_seamless(
-   >encoder->crtc->state->mode) ||
-   msm_is_mode_seamless_vrr(
-   >encoder->crtc->state->adjusted_mode))
-   continue;
-
-   if (msm_is_mode_seamless_dms(
-   >encoder->crtc->state->adjusted_mode))
-   continue;
-
-   funcs = encoder->helper_private;
-
-   DRM_DEBUG_ATOMIC("disabling [ENCODER:%d:%s]\n",
- 

[DPU PATCH 04/11] drm/msm: Move implicit sync fence handling to prepare_fb

[Sean Paul]

This is another piece that can be moved out of atomic to facilitate using
the atomic helpers.

Change-Id: I6dc3c4e5df508942bbc378c73a44e46e511b8469
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |  8 
 drivers/gpu/drm/msm/msm_atomic.c  | 13 -
 2 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 834dcc0bfefd..29e72b39fd72 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -2720,6 +2720,8 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane,
struct dpu_plane_rot_state *new_rstate;
struct dpu_hw_fmt_layout layout;
struct msm_gem_address_space *aspace;
+   struct msm_gem_object *msm_obj;
+   struct dma_fence *fence;
int ret;
 
if (!new_state->fb)
@@ -2761,6 +2763,12 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane,
return ret;
}
 
+   /* To support implicit sync, set a fence on the plane if appropriate */
+   msm_obj = to_msm_bo(msm_framebuffer_bo(fb, 0));
+   fence = reservation_object_get_excl_rcu(msm_obj->resv);
+   if (fence)
+   drm_atomic_set_fence_for_plane(new_state, fence);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index eb2ccda5da0f..3a18bd3dc215 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -282,19 +282,6 @@ int msm_atomic_commit(struct drm_device *dev,
for_each_new_crtc_in_state(state, crtc, crtc_state, i)
c->crtc_mask |= drm_crtc_mask(crtc);
 
-   /*
-* Figure out what fence to wait for:
-*/
-   for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
new_plane_state, i) {
-   if ((new_plane_state->fb != old_plane_state->fb) && 
new_plane_state->fb) {
-   struct drm_gem_object *obj = 
msm_framebuffer_bo(new_plane_state->fb, 0);
-   struct msm_gem_object *msm_obj = to_msm_bo(obj);
-   struct dma_fence *fence = 
reservation_object_get_excl_rcu(msm_obj->resv);
-
-   drm_atomic_set_fence_for_plane(new_plane_state, fence);
-   }
-   }
-
/*
 * Wait for pending updates on any of the same crtc's and then
 * mark our set of crtc's as busy:
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [PATCH v1 2/2] drm/panel: Add support for Raydium rm68200 panel driver

[Thierry Reding]

On Thu, Feb 08, 2018 at 03:30:26PM +0100, Philippe Cornu wrote:
> This patch adds Raydium Semiconductor Corporation rm68200
> 5.5" 720x1280 TFT LCD panel driver (MIPI-DSI video mode).
> 
> Signed-off-by: Philippe Cornu 
> ---
>  drivers/gpu/drm/panel/Kconfig |   8 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  drivers/gpu/drm/panel/panel-raydium-rm68200.c | 464 
> ++
>  3 files changed, 473 insertions(+)
>  create mode 100755 drivers/gpu/drm/panel/panel-raydium-rm68200.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 988048ebcc22..08d99dd46765 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -108,6 +108,14 @@ config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN
> Pi 7" Touchscreen.  To compile this driver as a module,
> choose M here.
>  
> +config DRM_PANEL_RAYDIUM_RM68200
> + tristate "Raydium rm68200 720x1280 dsi 2dl video mode panel"

What's 2dl? Either this is something already implied by the RM68200
model or if there are multiple variants of the RM68200 you'll probably
want to ensure that's reflected in the compatible string.

> + depends on OF
> + depends on DRM_MIPI_DSI
> + help
> +   Say Y here if you want to enable support for Raydium rm68200
> +   720x1280 dsi 2dl video mode panel
> +
>  config DRM_PANEL_SAMSUNG_S6E3HA2
>   tristate "Samsung S6E3HA2 DSI video mode panel"
>   depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 3d2a88d0e965..f26efc11d746 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
>  obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
>  obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
> panel-panasonic-vvx10f034n00.o
>  obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += 
> panel-raspberrypi-touchscreen.o
> +obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
>  obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
>  obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
>  obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c 
> b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
> new file mode 100755
> index ..f3e15873d05a
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
> @@ -0,0 +1,464 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) STMicroelectronics SA 2017
> + *
> + * Authors: Philippe Cornu 
> + *  Yannick Fertre 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRV_NAME "raydium_rm68200"

Not needed, see below.

> +
> +/*** Manufacturer Command Set ***/
> +#define MCS_CMD_MODE_SW  0xFE /* CMD Mode Switch */
> +#define MCS_CMD1_UCS 0x00 /* User Command Set (UCS = CMD1) */
> +#define MCS_CMD2_P0  0x01 /* Manufacture Command Set Page0 (CMD2 P0) */
> +#define MCS_CMD2_P1  0x02 /* Manufacture Command Set Page1 (CMD2 P1) */
> +#define MCS_CMD2_P2  0x03 /* Manufacture Command Set Page2 (CMD2 P2) */
> +#define MCS_CMD2_P3  0x04 /* Manufacture Command Set Page3 (CMD2 P3) */
> +
> +/* CMD2 P0 commands (Display Options and Power) */
> +#define MCS_STBCTR   0x12 /* TE1 Output Setting Zig-Zag Connection */
> +#define MCS_SGOPCTR  0x16 /* Source Bias Current */
> +#define MCS_SDCTR0x1A /* Source Output Delay Time */
> +#define MCS_INVCTR   0x1B /* Inversion Type */
> +#define MCS_EXT_PWR_IC   0x24 /* External PWR IC Control */
> +#define MCS_SETAVDD  0x27 /* PFM Control for AVDD Output */
> +#define MCS_SETAVEE  0x29 /* PFM Control for AVEE Output */
> +#define MCS_BT2CTR   0x2B /* DDVDL Charge Pump Control */
> +#define MCS_BT3CTR   0x2F /* VGH Charge Pump Control */
> +#define MCS_BT4CTR   0x34 /* VGL Charge Pump Control */
> +#define MCS_VCMCTR   0x46 /* VCOM Output Level Control */
> +#define MCS_SETVGN   0x52 /* VG M/S N Control */
> +#define MCS_SETVGP   0x54 /* VG M/S P Control */
> +#define MCS_SW_CTRL  0x5F /* Interface Control for PFM and MIPI */
> +
> +/* CMD2 P2 commands (GOA Timing Control) - no description in datasheet */
> +#define GOA_VSTV10x00
> +#define GOA_VSTV20x07
> +#define GOA_VCLK10x0E
> +#define GOA_VCLK20x17
> +#define GOA_VCLK_OPT10x20
> +#define GOA_BICLK1   0x2A
> +#define GOA_BICLK2   0x37
> +#define GOA_BICLK3   0x44
> +#define GOA_BICLK4   0x4F
> +#define GOA_BICLK_OPT1   0x5B
> +#define GOA_BICLK_OPT2   0x60
> +#define MCS_GOA_GPO1 0x6D
> +#define MCS_GOA_GPO2 0x71
> +#define MCS_GOA_EQ   0x74
> +#define MCS_GOA_CLK_GALLON 0x7C
> +#define MCS_GOA_FS_SEL0  0x7E
> +#define MCS_GOA_FS_SEL1  0x87
> +#define MCS_GOA_FS_SEL2  0x91
> +#define 

[Bug 102323] [DC] System crashes when woken up from S3 sleep while HDMI display is switched off

[bugzilla-daemon]

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

--- Comment #7 from Arvind  ---
(In reply to dwagner from comment #6)
> @Arvind: From the description of the symptoms you experience it might be
> rather the scenario of https://bugs.freedesktop.org/show_bug.cgi?id=103277
> that you run into.

You are right, my issue is indeed closer to the bug #103277 instead of this
one.

(In reply to Harry Wentland from comment #5)
> Are you able to give Alex's amd-staging-drm-next or drm-next-4.17-wip branch
> from https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next a try?

I'll give drm-next-4.17-wip a shot, thank you!

Also, since my issue is more related to the other bug report, I'll report back
my testing directly there.

-- 
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 v2 1/2] drm/panel: Remove drm_panel_detach() calls from all panel drives

[Thierry Reding]

On Wed, Feb 28, 2018 at 01:09:29PM +0200, Jyri Sarha wrote:
> Setting the connector and drm to NULL when the drm panel device is
> going away hardly serves any purpose. Usually the the whole memory
> stucture is freed right after the remove call.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/panel/panel-innolux-p079zca.c| 1 -
>  drivers/gpu/drm/panel/panel-jdi-lt070me05000.c   | 1 -
>  drivers/gpu/drm/panel/panel-lvds.c   | 1 -
>  drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 1 -
>  drivers/gpu/drm/panel/panel-seiko-43wvf1g.c  | 1 -
>  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c  | 1 -
>  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c  | 1 -
>  drivers/gpu/drm/panel/panel-simple.c | 1 -
>  drivers/gpu/drm/panel/panel-sitronix-st7789v.c   | 1 -
>  9 files changed, 9 deletions(-)

I don't understand the purpose of this patch. I'll grant you that the
current implementation of drm_panel_detach() is not very useful, but
then you add code to drm_panel_detach() in the next patch and mention
in the commit message that panel drivers should be calling the
drm_panel_detach() function to remove the link.

This is confusing. Can you clarify?

Thierry


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

[PATCH libdrm] omap: add Android build support

[Andrew F. Davis]

From: Gowtham Tammana 

Add Android.mk file to build libdrm_omap library.

Signed-off-by: Gowtham Tammana 
Signed-off-by: Andrew F. Davis 
---
 omap/Android.mk | 13 +
 1 file changed, 13 insertions(+)
 create mode 100644 omap/Android.mk

diff --git a/omap/Android.mk b/omap/Android.mk
new file mode 100644
index ..b25cca13
--- /dev/null
+++ b/omap/Android.mk
@@ -0,0 +1,13 @@
+LOCAL_PATH := $(call my-dir)
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := libdrm_omap
+LOCAL_VENDOR_MODULE := true
+
+LOCAL_SRC_FILES := omap_drm.c
+
+LOCAL_SHARED_LIBRARIES := libdrm
+
+include $(LIBDRM_COMMON_MK)
+
+include $(BUILD_SHARED_LIBRARY)
-- 
2.16.2

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

Re: [PATCH v2] drm/panel: simple: Add TVC S9700RTWV43TR-01B 800x480 panel support

[Thierry Reding]

On Wed, Feb 28, 2018 at 12:40:43PM +0200, Jyri Sarha wrote:
> Add support for TVC S9700RTWV43TR-01B 800x480 panel found on TI's
> AM335X-EVM.
> 
> Signed-off-by: Jyri Sarha 
> Reviewed-by: Tomi Valkeinen 
> ---
> The only change is added "Reviewed-by: Tomi Valkeinen 
> ".
> Who is going to pick this up?
> 
> The first version of the patch can be found here:
> https://lists.freedesktop.org/archives/dri-devel/2018-February/166902.html
> 
>  drivers/gpu/drm/panel/panel-simple.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 5591984..3b0ba9f 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1962,6 +1962,29 @@ static const struct panel_desc tpk_f10a_0102 = {
>   },
>  };
>  
> +static const struct drm_display_mode tvc_s9700rtwv43tr_01b_mode = {
> + .clock = 3000,

This seems to be missing a 0. Does the panel even work with 3 MHz? I'd
be somewhat surprised if it did.

Thierry


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

Re: [PATCH] drm/sun4i: init dclk_min_div & dclk_max_div inside encoder init functions

[Giulio Benetti]

Hi,

Il 28/02/2018 17:34, Giulio Benetti ha scritto:

Hi,

Il 28/02/2018 16:55, Maxime Ripard ha scritto:

Hi,

On Wed, Feb 28, 2018 at 01:51:58PM +0100, Giulio Benetti wrote:

sun4i_dclk_round_rate is called before sun4i_tcon_mode_set,
so it finds dclk_min_div and dclk_max_div set to 0 and fails
adding crtc.

Move dclk_min_div and dclk_max_div to encoders init functions.

Signed-off-by: Giulio Benetti 


I sent a similar patch there:
https://lists.freedesktop.org/archives/dri-devel/2018-February/16.html 



I've missed that.
And where you put it is better, since it's called every time set_mode is 
called.


On lvds instead I don't see anything about this,
it should have the same potential problem.
Also I can't understand why it has been set min=7 and max=7 on lvds.
With those values I would obtain 77Mhz only.
And I can't find values on datasheet for minimum and maximum.


Submitted patchset for that.





I guess eventually, we'll want to remove the usage of the clock
framework entirely, but it's not really the scope of a fix.


Where would you handle dclk instead of tcon?


Don't mind.

--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642



Thanks




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

Re: [PATCH v2 2/2] drm/panel: Add device_link from panel device to drm device

[Eric Anholt]

Jyri Sarha  writes:

> Add device_link from panel device (supplier) to drm device (consumer)
> with DL_FLAG_AUTOREMOVE when drm_panel_attach() is called. Currently
> the master drm driver is not protected against the attached. The
> device_link with DL_FLAG_AUTOREMOVE should make sure the drm device is
> unbound before the panel driver becomes unavailable.
>
> The device_link is removed when drm_panel_detach() is called. The
> drm_panel_detach() should be called by the panel driver it self when
> it is removed. Otherwise the both driver are racing to delete the same
> link.

I think this paragraph wants to be:

The device_link is removed when drm_panel_detach() is called. The
drm_panel_detach() should be called by the consumer DRM driver, not the
panel driver, otherwise both drivers are racing to delete the same link.

Other than that, these patches are:

Reviewed-by: Eric Anholt 

(though you'll probably want to wait a bit for Thierry to look at them
too)


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

Aspirant for GSOC 2018 for Nouveau Vulkan driver

[Anusha Srivastava]

Hi,

I would like to participate in  GSOC 2018 with Xorg to contribute to
project "Initial Nouveau Vulkan driver'
I would need some help in how to get started with the same.

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

[PATCH 2/2] drm/sun4i: add lvds mode_valid function

[Giulio Benetti]

mode_valid function is missing for lvds.

Add it based on rgb model, also setting up dclk_min_div and dclk_max_div

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 ++
 1 file changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index be3f14d..75223ee 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -46,8 +46,63 @@ static int sun4i_lvds_get_modes(struct drm_connector 
*connector)
return drm_panel_get_modes(tcon->panel);
 }
 
+static int sun4i_lvds_mode_valid(struct drm_connector *connector,
+   struct drm_display_mode *mode)
+{
+   struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
+   struct sun4i_tcon *tcon = lvds->tcon;
+   u32 hsync = mode->hsync_end - mode->hsync_start;
+   u32 vsync = mode->vsync_end - mode->vsync_start;
+   unsigned long rate = mode->clock * 1000;
+   long rounded_rate;
+
+   DRM_DEBUG_DRIVER("Validating modes...\n");
+
+   if (hsync < 1)
+   return MODE_HSYNC_NARROW;
+
+   if (hsync > 0x3ff)
+   return MODE_HSYNC_WIDE;
+
+   if ((mode->hdisplay < 1) || (mode->htotal < 1))
+   return MODE_H_ILLEGAL;
+
+   if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
+   return MODE_BAD_HVALUE;
+
+   DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
+
+   if (vsync < 1)
+   return MODE_VSYNC_NARROW;
+
+   if (vsync > 0x3ff)
+   return MODE_VSYNC_WIDE;
+
+   if ((mode->vdisplay < 1) || (mode->vtotal < 1))
+   return MODE_V_ILLEGAL;
+
+   if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff))
+   return MODE_BAD_VVALUE;
+
+   DRM_DEBUG_DRIVER("Vertical parameters OK\n");
+
+   tcon->dclk_min_div = 7;
+   tcon->dclk_max_div = 18;
+   rounded_rate = clk_round_rate(tcon->dclk, rate);
+   if (rounded_rate < rate)
+   return MODE_CLOCK_LOW;
+
+   if (rounded_rate > rate)
+   return MODE_CLOCK_HIGH;
+
+   DRM_DEBUG_DRIVER("Clock rate OK\n");
+
+   return MODE_OK;
+}
+
 static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
.get_modes  = sun4i_lvds_get_modes,
+   .mode_valid = sun4i_lvds_mode_valid,
 };
 
 static void
-- 
2.7.4

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

[PATCH 1/2] drm/sun4i: increase lvds dclk max divisor

[Giulio Benetti]

At the moment both min and max dclk div are set to 7.
This doesn't allow to have lower frequencies.

Increase dclk_max_div to 18 to achieve 30Mhz.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 029d2ce..bb35f41 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -278,7 +278,7 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon 
*tcon,
u32 reg, val = 0;
 
tcon->dclk_min_div = 7;
-   tcon->dclk_max_div = 7;
+   tcon->dclk_max_div = 18;
sun4i_tcon0_mode_set_common(tcon, mode);
 
/* Adjust clock delay */
-- 
2.7.4

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

Re: [PATCH libdrm] meson: add configuration summary

[Dylan Baker]

Quoting Eric Engestrom (2018-02-28 07:11:20)
> On Tuesday, 2018-02-27 12:30:48 -0800, Eric Anholt wrote:
> > Dylan Baker  writes:
> > 
> > > [ Unknown signature status ]
> > > Quoting Eric Engestrom (2018-02-27 03:11:07)
> > >> The message block printed is the same as the one in configure.ac
> > >> 
> > >> Signed-off-by: Eric Engestrom 
> > >> ---
> > >>  meson.build | 17 +
> > >>  1 file changed, 17 insertions(+)
> > >> 
> > >> diff --git a/meson.build b/meson.build
> > >> index bd00cdc2cae9f0749180..ab6f881755935968b822 100644
> > >> --- a/meson.build
> > >> +++ b/meson.build
> > >> @@ -373,3 +373,20 @@ if with_man_pages
> > >>  endif
> > >>  subdir('data')
> > >>  subdir('tests')
> > >> +
> > >> +message('')
> > >> +message('@0@ will be compiled with:'.format(meson.project_name()))
> > >> +message('')
> > >> +message('  libkms @0@'.format(with_libkms))
> > >> +message('  Intel API  @0@'.format(with_intel))
> > >> +message('  vmwgfx API @0@'.format(with_vmwgfx))
> > >> +message('  Radeon API @0@'.format(with_radeon))
> > >> +message('  AMDGPU API @0@'.format(with_amdgpu))
> > >> +message('  Nouveau API@0@'.format(with_nouveau))
> > >> +message('  OMAP API   @0@'.format(with_omap))
> > >> +message('  EXYNOS API @0@'.format(with_exynos))
> > >> +message('  Freedreno API  @0@ (kgsl: @1@)'.format(with_freedreno, 
> > >> with_freedreno_kgsl))
> > >> +message('  Tegra API  @0@'.format(with_tegra))
> > >> +message('  VC4 API@0@'.format(with_vc4))
> > >> +message('  Etnaviv API@0@'.format(with_etnaviv))
> > >> +message('')
> > >> -- 
> > >> Cheers,
> > >>   Eric
> > >> 
> > >
> > > This one is certainly simple enough that we can use a single message call 
> > > and a
> > > ''' string :)
> > 
> > But then you end up with 13 @n@ values and when someone wants to put
> > something earlier in the list for some sorting reason, then they need to
> > renumber the rest.  This is much nicer.
> 
> I have to agree here. Dylan, why did you want to avoid multiple
> `message()`? They're not expensive afaict, so I'm not sure what the gain
> would be?
> 
> I also had a try, and multiline messages only get a `Message:` prefix on
> the first line, so combining them would result in unpredictable vertical
> alignments. Unless there's a good reason to merge them, I'll keep them
> separate.

It's mostly my irrational OCD, but I think a long series of calls to print or
message (or whatever your language calls it) are incredibly hard to read.

message('')
message('@0@ will be compiled with:'.format(meson.project_name()))
message('')
message('  libkms @0@'.format(with_libkms))
message('  Intel API  @0@'.format(with_intel))
message('  vmwgfx API @0@'.format(with_vmwgfx))
message('  Radeon API @0@'.format(with_radeon))
message('  AMDGPU API @0@'.format(with_amdgpu))
message('  Nouveau API@0@'.format(with_nouveau))
message('  OMAP API   @0@'.format(with_omap))
message('  EXYNOS API @0@'.format(with_exynos))
message('  Freedreno API  @0@ (kgsl: @1@)'.format(with_freedreno, 
with_freedreno_kgsl))
message('  Tegra API  @0@'.format(with_tegra))
message('  VC4 API@0@'.format(with_vc4))
message('  Etnaviv API@0@'.format(with_etnaviv))
message('')

vs

message('''

  @0@ will be compiled with:

  libkms @1@
  Intel API  @2@
  vmwgfx API @3@
  Radeon API @4@
  AMDGPU API @5@
  Nouveau API@6@
  OMAP API   @7@
  EXYNOS API @8@
  Freedreno API  @9@ (kgsl: @10@)
  Tegra API  @11@
  VC4 API@12@
  Etnaviv API@13@

'''.format(
  meson.project_name(),
  with_libkms,
  with_intel,
  with_vmwgfx,
  ...
)

I do have to admit that Anholt is right that the lack of either an inline
replacement syntax or an unnumbered formatter makes this somewhat unwieldy in
meson. And it's not that big of a deal either way I guess.

Dylan


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

Re: [PATCH v2] drm/panel: simple: Add TVC S9700RTWV43TR-01B 800x480 panel support

[Eric Anholt]

Jyri Sarha  writes:

> Add support for TVC S9700RTWV43TR-01B 800x480 panel found on TI's
> AM335X-EVM.
>
> Signed-off-by: Jyri Sarha 
> Reviewed-by: Tomi Valkeinen 
> ---
> The only change is added "Reviewed-by: Tomi Valkeinen 
> ".
> Who is going to pick this up?
>
> The first version of the patch can be found here:
> https://lists.freedesktop.org/archives/dri-devel/2018-February/166902.html

Since panels are maintained in drm-misc now, I believe you can just
merge it yourself.


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

[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)

[bugzilla-daemon]

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

--- Comment #12 from Jordan L  ---
Thanks. Just to clarify, you aren't able to enable DC with your current Kconfig
configuration, which prevents you from retrying on this ticket?

If so, please just open a new bug rather than conflate the issue here. Once
you're unblocked from testing DC with your configuration, we can look at this
issue again. 

Cheers

-- 
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 105284] Every boot I get an error in dmesg "WARNING: CPU: 2 PID: 1380 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu]"

[bugzilla-daemon]

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

--- Comment #2 from mikhail.v.gavri...@gmail.com ---
(In reply to Harry Wentland from comment #1)
> Is this on a Vega or Raven ASIC?
> 
> If so it's known and a fix should land shortly.

This is Sapphire Radeon RX VEGA 56

-- 
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: [2/3] drm/sun4i: rgb: Fix potential division by zero

[Giulio Benetti]

Il 21/02/2018 13:57, Maxime Ripard ha scritto:

In the case where mode_valid callback of our RGB connector was called
before mode_set was being called, the range of dividers would not be set,
resulting in a division by zero later on in the clk_round_rate logic.

Set the range of dividers before calling clk_round_rate to fix this.

Signed-off-by: Maxime Ripard 

Tested-by: Giulio Benetti 

Before crtc couldn't be added because of min=0 and max=0.
Now they're initiliazed and crtc is added correctly.

---
  drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 832f8f9bc47f..b8da5a50a61d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -92,6 +92,8 @@ static int sun4i_rgb_mode_valid(struct drm_connector 
*connector,
  
  	DRM_DEBUG_DRIVER("Vertical parameters OK\n");
  
+	tcon->dclk_min_div = 6;

+   tcon->dclk_max_div = 127;
rounded_rate = clk_round_rate(tcon->dclk, rate);
if (rounded_rate < rate)
return MODE_CLOCK_LOW;




--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 3/3] drm: writeback: Add client capability for exposing writeback connectors

[Liviu Dudau]

Due to the fact that writeback connectors behave in a special way
in DRM (they always report being disconnected) we might confuse some
userspace. Add a client capability for writeback connectors that will
filter them out for clients that don't understand the capability.

Re-requested-by: Sean Paul 
Cc: Brian Starkey 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/drm_ioctl.c   | 5 +
 drivers/gpu/drm/drm_mode_config.c | 5 +
 include/drm/drm_file.h| 7 +++
 include/uapi/drm/drm.h| 9 +
 4 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 02ffa0e8d77b..48895a469963 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -322,6 +322,11 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_WRITEBACK_CONNECTORS:
+   if (!file_priv->atomic || !drm_core_check_feature(dev, 
DRIVER_ATOMIC))
+   return -EINVAL;
+   file_priv->writeback_connectors = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index e5c653357024..21e353bd3948 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -145,6 +145,11 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
count = 0;
connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
drm_for_each_connector_iter(connector, _iter) {
+   /* only expose writeback connectors if userspace understands 
them */
+   if (!file_priv->writeback_connectors &&
+   (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK))
+   continue;
+
if (drm_lease_held(file_priv, connector->base.id)) {
if (count < card_res->count_connectors &&
put_user(connector->base.id, connector_id + count)) 
{
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 5176c3797680..2a09b3c8965c 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -181,6 +181,13 @@ struct drm_file {
/** @atomic: True if client understands atomic properties. */
unsigned atomic:1;
 
+   /**
+* @writeback_connectors:
+*
+* True if client understands writeback connectors
+*/
+   unsigned writeback_connectors:1;
+
/**
 * @is_master:
 *
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff5945c8a..59f27ea928b4 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -680,6 +680,15 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3
 
+/**
+ * DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
+ *
+ * If set to 1, the DRM core will expose special connectors to be used for
+ * writing back to memory the scene setup in the commit. Depends on client
+ * also supporting DRM_CLIENT_CAP_ATOMIC
+ */
+#define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS4
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
2.16.2

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

[PATCH v6 1/3] drm: Add writeback connector type

[Liviu Dudau]

From: Brian Starkey 

Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.

Drivers should initialize a writeback connector with
drm_writeback_connector_init() which takes care of setting up all the
writeback-specific details on top of the normal functionality of
drm_connector_init().

Writeback connectors have a WRITEBACK_FB_ID property, used to set the
output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
supported writeback formats to userspace.

When a framebuffer is attached to a writeback connector with the
WRITEBACK_FB_ID property, it is used only once (for the commit in which
it was included), and userspace can never read back the value of
WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
attached to a CRTC.

Changes since v1:
 - Added drm_writeback.c + documentation
 - Added helper to initialize writeback connector in one go
 - Added core checks
 - Squashed into a single commit
 - Dropped the client cap
 - Writeback framebuffers are no longer persistent

Changes since v2:
 Daniel Vetter:
 - Subclass drm_connector to drm_writeback_connector
 - Relax check to allow CRTC to be set without an FB
 - Add some writeback_ prefixes
 - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
 Gustavo Padovan:
 - Add drm_writeback_job to handle writeback signalling centrally

Changes since v3:
 - Rebased
 - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS

Chances since v4:
 - Embed a drm_encoder inside the drm_writeback_connector to
   reduce the amount of boilerplate code required from the drivers
   that are using it.

Changes since v5:
 - Added Rob Clark's atomic_commit() vfunc to connector helper
   funcs, so that writeback jobs are commited from atomic helpers
 - Updated create_writeback_properties() signature to return an
   error code rather than a boolean false for failure.
 - Free writeback job with the connector state rather than when
   doing the cleanup_work()

Signed-off-by: Brian Starkey 
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov 
[rebased and added atomic_commit() vfunc for writeback jobs]
Signed-off-by: Rob Clark 
Signed-off-by: Liviu Dudau 
---
 Documentation/gpu/drm-kms.rst|   9 ++
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_atomic.c | 128 
 drivers/gpu/drm/drm_atomic_helper.c  |  30 
 drivers/gpu/drm/drm_connector.c  |   4 +-
 drivers/gpu/drm/drm_writeback.c  | 256 +++
 include/drm/drm_atomic.h |   3 +
 include/drm/drm_connector.h  |  13 ++
 include/drm/drm_mode_config.h|  15 ++
 include/drm/drm_modeset_helper_vtables.h |  11 ++
 include/drm/drm_writeback.h  |  88 +++
 include/uapi/drm/drm_mode.h  |   1 +
 12 files changed, 558 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_writeback.c
 create mode 100644 include/drm/drm_writeback.h

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 56a3780e39b8..a0ee22020360 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -370,6 +370,15 @@ Connector Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_connector.c
:export:
 
+Writeback Connectors
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
+  :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
+  :export:
+
 Encoder Abstraction
 ===
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 50093ff4479b..3d708959b224 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
-   drm_syncobj.o drm_lease.o
+   drm_syncobj.o drm_lease.o drm_writeback.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 46733d534587..b2a61aebe92c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "drm_crtc_internal.h"
@@ -638,6 +639,45 @@ static void drm_atomic_crtc_print_state(struct drm_printer 
*p,
crtc->funcs->atomic_print_state(p, state);
 }
 
+/**
+ * drm_atomic_connector_check - check connector state
+ * @connector: connector to check
+ * @state: connector state to check
+ *
+ * Provides core sanity checks for connector state.
+ *
+ * RETURNS:
+ * 

[PATCH v6 2/3] drm: writeback: Add out-fences for writeback connectors

[Liviu Dudau]

From: Brian Starkey 

Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to
enable userspace to get a fence which will signal once the writeback is
complete. It is not allowed to request an out-fence without a
framebuffer attached to the connector.

A timeline is added to drm_writeback_connector for use by the writeback
out-fences.

In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence
is set to -1.

Changes from v2:
 - Rebase onto Gustavo Padovan's v9 explicit sync series
 - Change out_fence_ptr type to s32 __user *
 - Set *out_fence_ptr to -1 in drm_atomic_connector_set_property
 - Store fence in drm_writeback_job
 Gustavo Padovan:
 - Move out_fence_ptr out of connector_state
 - Signal fence from drm_writeback_signal_completion instead of
   in driver directly

Changes from v3:
 - Rebase onto '7e9081c5aac7 ("drm/fence: fix memory overwrite when setting
   out_fence fd")'
   (change out_fence_ptr to s32 __user *, for real this time.)
 - Update documentation around WRITEBACK_OUT_FENCE_PTR

Signed-off-by: Brian Starkey 
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/drm_atomic.c|  99 
 drivers/gpu/drm/drm_writeback.c | 108 +++-
 include/drm/drm_atomic.h|   8 +++
 include/drm/drm_connector.h |   8 +--
 include/drm/drm_mode_config.h   |   8 +++
 include/drm/drm_writeback.h |  43 +++-
 6 files changed, 258 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b2a61aebe92c..b38405433db3 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -318,6 +318,35 @@ static s32 __user *get_out_fence_for_crtc(struct 
drm_atomic_state *state,
return fence_ptr;
 }
 
+static int set_out_fence_for_connector(struct drm_atomic_state *state,
+   struct drm_connector *connector,
+   s32 __user *fence_ptr)
+{
+   unsigned int index = drm_connector_index(connector);
+
+   if (!fence_ptr)
+   return 0;
+
+   if (put_user(-1, fence_ptr))
+   return -EFAULT;
+
+   state->connectors[index].out_fence_ptr = fence_ptr;
+
+   return 0;
+}
+
+static s32 __user *get_out_fence_for_connector(struct drm_atomic_state *state,
+  struct drm_connector *connector)
+{
+   unsigned int index = drm_connector_index(connector);
+   s32 __user *fence_ptr;
+
+   fence_ptr = state->connectors[index].out_fence_ptr;
+   state->connectors[index].out_fence_ptr = NULL;
+
+   return fence_ptr;
+}
+
 /**
  * drm_atomic_set_mode_for_crtc - set mode for CRTC
  * @state: the CRTC whose incoming state to update
@@ -675,6 +704,12 @@ static int drm_atomic_connector_check(struct drm_connector 
*connector,
return -EINVAL;
}
 
+   if (writeback_job->out_fence && !writeback_job->fb) {
+   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence 
without framebuffer\n",
+connector->base.id, connector->name);
+   return -EINVAL;
+   }
+
return 0;
 }
 
@@ -1276,6 +1311,11 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
if (fb)
drm_framebuffer_unreference(fb);
return ret;
+   } else if (property == config->writeback_out_fence_ptr_property) {
+   s32 __user *fence_ptr = u64_to_user_ptr(val);
+
+   return set_out_fence_for_connector(state->state, connector,
+  fence_ptr);
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1360,6 +1400,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
+   } else if (property == config->writeback_out_fence_ptr_property) {
+   *val = 0;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
@@ -2219,7 +2261,7 @@ static int setup_out_fence(struct drm_out_fence_state 
*fence_state,
return 0;
 }
 
-static int prepare_crtc_signaling(struct drm_device *dev,
+static int prepare_signaling(struct drm_device *dev,
  struct drm_atomic_state *state,
  struct drm_mode_atomic *arg,
 

[PATCH v6 0/3] drm: Introduce writeback connectors

[Liviu Dudau]

Hi,

This is v6 of the writeback connector series. Based on renewed
interest in the feature and recent efforts from Rob Clark I'm
refreshing the series to address some comments and feedback.

Main changes are to incorporate Rob Clark's atomic_commit() vfunc
for the connector helper funcs, change the signature of the
create_writeback_properties() function to return the error code
rather than a boolean false and making sure that the writeback job
doesn't get freed in the cleanup_work() function but when the
connector state gets discarded.

Additionally, based on Sean Paul's comments, I'm providing the
3rd patch in the series that adds a client cap for exposing the
writeback connectors to userspace. The idea was initially considered
unnecessary by Daniel Vetter here [1] but Sean thinks it is useful.
Note that the patch depends on the cleanup patch [2] sent earlier.


Comments are welcome on the suitability of this series.

Best regards,
Liviu


[1] https://lists.freedesktop.org/archives/dri-devel/2016-October/120519.html
[2] https://lists.freedesktop.org/archives/dri-devel/2018-February/167677.html

Brian Starkey (2):
  drm: Add writeback connector type
  drm: writeback: Add out-fences for writeback connectors

Liviu Dudau (1):
  drm: writeback: Add client capability for exposing writeback
connectors

 Documentation/gpu/drm-kms.rst|   9 +
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_atomic.c | 227 ++-
 drivers/gpu/drm/drm_atomic_helper.c  |  30 +++
 drivers/gpu/drm/drm_connector.c  |   4 +-
 drivers/gpu/drm/drm_ioctl.c  |   5 +
 drivers/gpu/drm/drm_mode_config.c|   5 +
 drivers/gpu/drm/drm_writeback.c  | 360 +++
 include/drm/drm_atomic.h |  11 +
 include/drm/drm_connector.h  |  13 ++
 include/drm/drm_file.h   |   7 +
 include/drm/drm_mode_config.h|  23 ++
 include/drm/drm_modeset_helper_vtables.h |  11 +
 include/drm/drm_writeback.h  | 129 +++
 include/uapi/drm/drm.h   |   9 +
 include/uapi/drm/drm_mode.h  |   1 +
 16 files changed, 835 insertions(+), 11 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_writeback.c
 create mode 100644 include/drm/drm_writeback.h

-- 
2.16.2

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

[PATCH] drm/sun4i: Fix dclk_set_phase

[Giulio Benetti]

Phase value is not shifted before writing.

Shift left of 28 bits to fit right bits

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_dotclock.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c 
b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
index 023f39b..e36004f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
+++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
@@ -132,10 +132,13 @@ static int sun4i_dclk_get_phase(struct clk_hw *hw)
 static int sun4i_dclk_set_phase(struct clk_hw *hw, int degrees)
 {
struct sun4i_dclk *dclk = hw_to_dclk(hw);
+   u32 val = degrees / 120;
+
+   val <<= 28;
 
regmap_update_bits(dclk->regmap, SUN4I_TCON0_IO_POL_REG,
   GENMASK(29, 28),
-  degrees / 120);
+  val);
 
return 0;
 }
-- 
2.7.4

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

[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #21 from Kyle De'Vir (kyle.de...@mykolab.com) ---
> I don't see any DC or other DRM change in the stable kernel between 4.15.5
> and 4.15.6.

What about any of the other point releases? I tried without your patch, and
amdgpu.dc=1 mysteriously just works... so strange that it just didn't before.

I don't understand what even happened, and that's even more frustrating than it
not working... urgh. :/

-- 
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

[Bug 105262] ttf fonts are invisible

[bugzilla-daemon]

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

--- Comment #7 from LoneVVolf  ---
I started bisecting this. Had to move head several times due to build failures
and runtime problems, but managed to find some more good commits.

$ git bisect log
git bisect start
# good: [aa2f609f700919f824970f9c13f016994364] broadcom/vc5: Ignore
samplers for finding uniform offsets.
git bisect good aa2f609f700919f824970f9c13f016994364
# bad: [3f7a7bd897ce4d7da50d4f25b1549001abef05cc] r600: implement tg4 integer
workaround. (v2)
git bisect bad 3f7a7bd897ce4d7da50d4f25b1549001abef05cc
# good: [4081e088962315b5c3f4e7030868faf01e7c4a69] winsys/amdgpu: allow non
page-aligned size bo creation from pointer
git bisect good 4081e088962315b5c3f4e7030868faf01e7c4a69
$

-- 
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 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #20 from Kyle De'Vir (kyle.de...@mykolab.com) ---
I'm going to test without your patch to see if the problem pops up again.

-- 
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: [PATCH] drm/sun4i: init dclk_min_div & dclk_max_div inside encoder init functions

[Giulio Benetti]

Hi,

Il 28/02/2018 16:55, Maxime Ripard ha scritto:

Hi,

On Wed, Feb 28, 2018 at 01:51:58PM +0100, Giulio Benetti wrote:

sun4i_dclk_round_rate is called before sun4i_tcon_mode_set,
so it finds dclk_min_div and dclk_max_div set to 0 and fails
adding crtc.

Move dclk_min_div and dclk_max_div to encoders init functions.

Signed-off-by: Giulio Benetti 


I sent a similar patch there:
https://lists.freedesktop.org/archives/dri-devel/2018-February/16.html


I've missed that.
And where you put it is better, since it's called every time set_mode is 
called.


On lvds instead I don't see anything about this,
it should have the same potential problem.
Also I can't understand why it has been set min=7 and max=7 on lvds.
With those values I would obtain 77Mhz only.
And I can't find values on datasheet for minimum and maximum.



I guess eventually, we'll want to remove the usage of the clock
framework entirely, but it's not really the scope of a fix.


Where would you handle dclk instead of tcon?

Thanks

--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642



Maxime




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

Re: [PATCH] drm/drm_ioctl.c: Test client capability value early when setting.

[Liviu Dudau]

On Wed, Feb 28, 2018 at 05:57:15PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 28, 2018 at 03:44:44PM +, Liviu Dudau wrote:
> > On Wed, Feb 28, 2018 at 05:40:41PM +0200, Ville Syrjälä wrote:
> > > On Wed, Feb 28, 2018 at 03:27:41PM +, Liviu Dudau wrote:
> > > > The drm_setclientcap() function implementing the 
> > > > DRM_IOCTL_SET_CLIENT_CAP
> > > > ioctl expects that any capability set by the client will have a value 
> > > > of 1.
> > > > Make the check early so that we don't have to test the value for each
> > > > capability.
> > > 
> > > What if we want a a non-boolean capability at some point?
> > 
> > Well, I'm adding another boolean capability soon, so you will be going
> > against the trend :)
> 
> Plenty of non-bools in driver specific counterparts I believe.

So, is that a NACK? 


> 
> > I guess you will have 2 options: revert the patch or add a condition to
> > the test.
> > 
> > I don't have strong feelings, just felt like too much copying when
> > adding another capability so I thought to do some "cleanup".
> > 
> > Best regards,
> > Liviu
> > 
> > > 
> > > > 
> > > > Signed-off-by: Liviu Dudau 
> > > > ---
> > > >  drivers/gpu/drm/drm_ioctl.c | 9 +++--
> > > >  1 file changed, 3 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > > > index af782911c505..02ffa0e8d77b 100644
> > > > --- a/drivers/gpu/drm/drm_ioctl.c
> > > > +++ b/drivers/gpu/drm/drm_ioctl.c
> > > > @@ -306,22 +306,19 @@ drm_setclientcap(struct drm_device *dev, void 
> > > > *data, struct drm_file *file_priv)
> > > >  {
> > > > struct drm_set_client_cap *req = data;
> > > >  
> > > > +   if (req->value > 1)
> > > > +   return -EINVAL;
> > > > +
> > > > switch (req->capability) {
> > > > case DRM_CLIENT_CAP_STEREO_3D:
> > > > -   if (req->value > 1)
> > > > -   return -EINVAL;
> > > > file_priv->stereo_allowed = req->value;
> > > > break;
> > > > case DRM_CLIENT_CAP_UNIVERSAL_PLANES:
> > > > -   if (req->value > 1)
> > > > -   return -EINVAL;
> > > > file_priv->universal_planes = req->value;
> > > > break;
> > > > case DRM_CLIENT_CAP_ATOMIC:
> > > > if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> > > > return -EINVAL;
> > > > -   if (req->value > 1)
> > > > -   return -EINVAL;
> > > > file_priv->atomic = req->value;
> > > > file_priv->universal_planes = req->value;
> > > > break;
> > > > -- 
> > > > 2.16.2
> > > > 
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > 
> > > -- 
> > > Ville Syrjälä
> > > Intel OTC
> > 
> > -- 
> > 
> > | I would like to |
> > | fix the world,  |
> > | but they're not |
> > | giving me the   |
> >  \ source code!  /
> >   ---
> > ¯\_(ツ)_/¯
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

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

--- Comment #9 from Michael Zapf  ---
Unfortunately, that does not work, I just tried it. I suppose that otherwise,
turning the monitor off and on should have already helped.

The only way to restore leads me via killing the Xserver. Maybe some xrandr
command? It needs to refresh its resolution list, though.

There may be some influence by the A/V receiver in the chain, but as I posted
on Feb 15, the effect is also there with my UHD monitor in the office,
connected by DisplayPort, and having nothing in between.

-- 
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: [Xen-devel] [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend

[Julien Grall]

(+ Stefano and Wei)

Hi,

On 02/27/2018 12:40 PM, Oleksandr Andrushchenko wrote:

Please find some more clarifications on VirtIO use with Xen
(I would like to thank Xen community for helping with this)

1. Possible security issues - VirtIO devices are PCI bus masters, thus
allowing real device (running, for example, in untrusted driver domain)
to get control over guest's memory by writing to its memory

2. VirtIO currently uses GFNs written into the shared ring, without Xen
grants support. This will require generic grant-mapping/sharing layer
to be added to VirtIO.

3. VirtIO requires QEMU PCI emulation for setting up a device. Xen PV 
(and PVH)
domains don't use QEMU for platform emulation in order to reduce attack 
surface.
(PVH is in the process of gaining PCI config space emulation though, but 
it is

optional, not a requirement)
I don't think the support of PCI configuration space emulation for PVH 
would help there. The plan is to emulate in Xen, QEMU is still out of 
the equation there.




4. Most of the PV drivers a guest uses at the moment are Xen PV drivers, 
e.g. net,

block, console, so only virtio-gpu will require QEMU to run.
Although this use case would work on x86 it will require additional changes
to get this running on ARM, which is my target platform.


All type of guests but x86 HVM are not using QEMU for device emulation.

I would even be stronger here. Using QEMU would require a significant 
amount of engineering to make it work and increase the cost of safety 
certification for automotive use cases. So IHMO, the Xen PV display 
solution is the best.


The protocol was accepted and merged in Xen 4.9. This the standard way 
to have para-virtualized display for guests on Xen. Having the driver 
merged in Linux would help user to get out-of-box display in guest.


Cheers,

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

Re: [PATCH v3 05/43] drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind

[Marc Zyngier]

On 28/02/18 14:37, Heiko Stübner wrote:
> Am Dienstag, 30. Januar 2018, 21:28:35 CET schrieb Thierry Escande:
>> From: zain wang 
>>
>> The bridge does not need to be powered in analogix_dp_bind(), so
>> remove the calls to pm_runtime_get()/phy_power_on()/analogix_dp_init_dp()
>> as well as their power-off counterparts.
>>
>> Cc: Stéphane Marchesin 
>> Signed-off-by: zain wang 
>> Signed-off-by: Caesar Wang 
>> [the patch originally just removed the power_on portion, seanpaul removed
>> the power off code as well as improved the commit message]
>> Signed-off-by: Sean Paul 
>> Signed-off-by: Thierry Escande 
>> ---
>>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 10 --
>>  1 file changed, 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index
>> cb5e18d6ba04..1477ea9ba85d 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -1382,11 +1382,6 @@ analogix_dp_bind(struct device *dev, struct
>> drm_device *drm_dev,
>>
>>  pm_runtime_enable(dev);
>>
>> -pm_runtime_get_sync(dev);
>> -phy_power_on(dp->phy);
>> -
>> -analogix_dp_init_dp(dp);
>> -
>>  ret = devm_request_threaded_irq(>dev, dp->irq,
>>  analogix_dp_hardirq,
>>  analogix_dp_irq_thread,
> 
> Not 100% sure here, as the driver has the request-irq + disable-irq hack
> here. So a pending interrupt could possibly fire between request and
> disable.
> 
> Right now the block should be on, but can it still handle such an irq
> when the power is removed?

Probably not (see below).

> So before removing the power here, we might want something
> similar to what Marc posted for the vop [0] for the analogix-dp?

You can do that trick only if the interrupt is not shared. In the VOP
case, it is shared with the IOMMU, which makes it more... interesting.

And when it comes to power and the analogix-dp driver, I've been
carrying this[1] for a while. Fully exploitable from userspace. I know
it is about to be replaced by this series, but at least 4.15 and 4.16
are affected.

M.

[1] https://www.spinics.net/lists/arm-kernel/msg623892.html
-- 
Jazz is not dead. It just smells funny...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #19 from Harry Wentland (harry.wentl...@amd.com) ---
I don't see any DC or other DRM change in the stable kernel between 4.15.5 and
4.15.6.

-- 
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

[PATCH] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE

[Giulio Benetti]

Handle both positive and negative dclk polarity,
according to bus_flags.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index aaf911a..534e5ee 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -340,6 +341,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon 
*tcon,
 static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
 const struct drm_display_mode *mode)
 {
+   struct drm_panel *panel = tcon->panel;
+   struct drm_connector *connector = panel->connector;
+   struct drm_display_info display_info = connector->display_info;
unsigned int bp, hsync, vsync;
u8 clk_delay;
u32 val = 0;
@@ -395,8 +399,15 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
 
+   if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
+   clk_set_phase(tcon->dclk, 240);
+
+   if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+   clk_set_phase(tcon->dclk, 0);
+
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
-  SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | 
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
+  SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
+  SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
   val);
 
/* Map output pins to channel 0 */
-- 
2.7.4

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

[Bug 105284] Every boot I get an error in dmesg "WARNING: CPU: 2 PID: 1380 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu]"

[bugzilla-daemon]

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

--- Comment #1 from Harry Wentland  ---
Is this on a Vega or Raven ASIC?

If so it's known and a fix should land shortly.

-- 
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 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #18 from Kyle De'Vir (kyle.de...@mykolab.com) ---
Actually, there was a change! Didn't have to boot headless at all, happily.

Your patch didn't seem to change anything, but the update to 4.15.6 might have
done something...? Did anything change for Display Core in the latest stable
update?

-- 
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: [PATCH] drm/drm_ioctl.c: Test client capability value early when setting.

[Ville Syrjälä]

On Wed, Feb 28, 2018 at 03:44:44PM +, Liviu Dudau wrote:
> On Wed, Feb 28, 2018 at 05:40:41PM +0200, Ville Syrjälä wrote:
> > On Wed, Feb 28, 2018 at 03:27:41PM +, Liviu Dudau wrote:
> > > The drm_setclientcap() function implementing the DRM_IOCTL_SET_CLIENT_CAP
> > > ioctl expects that any capability set by the client will have a value of 
> > > 1.
> > > Make the check early so that we don't have to test the value for each
> > > capability.
> > 
> > What if we want a a non-boolean capability at some point?
> 
> Well, I'm adding another boolean capability soon, so you will be going
> against the trend :)

Plenty of non-bools in driver specific counterparts I believe.

> I guess you will have 2 options: revert the patch or add a condition to
> the test.
> 
> I don't have strong feelings, just felt like too much copying when
> adding another capability so I thought to do some "cleanup".
> 
> Best regards,
> Liviu
> 
> > 
> > > 
> > > Signed-off-by: Liviu Dudau 
> > > ---
> > >  drivers/gpu/drm/drm_ioctl.c | 9 +++--
> > >  1 file changed, 3 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > > index af782911c505..02ffa0e8d77b 100644
> > > --- a/drivers/gpu/drm/drm_ioctl.c
> > > +++ b/drivers/gpu/drm/drm_ioctl.c
> > > @@ -306,22 +306,19 @@ drm_setclientcap(struct drm_device *dev, void 
> > > *data, struct drm_file *file_priv)
> > >  {
> > >   struct drm_set_client_cap *req = data;
> > >  
> > > + if (req->value > 1)
> > > + return -EINVAL;
> > > +
> > >   switch (req->capability) {
> > >   case DRM_CLIENT_CAP_STEREO_3D:
> > > - if (req->value > 1)
> > > - return -EINVAL;
> > >   file_priv->stereo_allowed = req->value;
> > >   break;
> > >   case DRM_CLIENT_CAP_UNIVERSAL_PLANES:
> > > - if (req->value > 1)
> > > - return -EINVAL;
> > >   file_priv->universal_planes = req->value;
> > >   break;
> > >   case DRM_CLIENT_CAP_ATOMIC:
> > >   if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> > >   return -EINVAL;
> > > - if (req->value > 1)
> > > - return -EINVAL;
> > >   file_priv->atomic = req->value;
> > >   file_priv->universal_planes = req->value;
> > >   break;
> > > -- 
> > > 2.16.2
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> 
> -- 
> 
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---
> ¯\_(ツ)_/¯

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

[Giulio Benetti]

Hi,

Il 16/02/2018 16:50, Maxime Ripard ha scritto:

On Thu, Feb 15, 2018 at 07:05:56PM +0100, Giulio Benetti wrote:

If so, and if remember the captures properly, the sampling would occur
right before the rise, and not really around the fall.

Would 2/3 be better here?


Yes, you're right, 2/3 phase is better:

1/3 phase: https://pasteboard.co/H4VehON.png
2/3 phase: https://pasteboard.co/H4Veq8a.png

Take a look at the bit in middle(yellow) sampled by clock(blue).

Rising edge is almost in the middle of D0 bit.




According to scope captures above on both A20 and A33.
Unfortunately I don't have other boards for the other SoCs to take captures.

What do you think?


I guess we can make that part applicable to all SoCs, we haven't seen
any significant differences on those part.


So let's keep:
- As normal(rising edge) => IO_POL_REG "0x2 => 2/3 phase"
- As inverted(falling edge) => IO_POL_REG "0x0 => normal phase"


I was actually thinking 1/3 for rising, 2/3 for falling.


1/3 is almost the same waveform as D0,
having rising an falling edges almost in sync with D0.
It's not so clear because DCLK has a bad figure,
but it is that way.

2/3 instead is almost in the middle of D0 as rising.

Summarizing:
- use 0/3 as falling, then DRM_BUS_FLAG_PIXDATA_NEGEDGE
- use 2/3 as rising, then DRM_BUS_FLAG_PIXDATA_POSEDGE

I follow with a new patch using clk_set_phase function.



Maxime




--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/sun4i: init dclk_min_div & dclk_max_div inside encoder init functions

[Maxime Ripard]

Hi,

On Wed, Feb 28, 2018 at 01:51:58PM +0100, Giulio Benetti wrote:
> sun4i_dclk_round_rate is called before sun4i_tcon_mode_set,
> so it finds dclk_min_div and dclk_max_div set to 0 and fails
> adding crtc.
> 
> Move dclk_min_div and dclk_max_div to encoders init functions.
> 
> Signed-off-by: Giulio Benetti 

I sent a similar patch there:
https://lists.freedesktop.org/archives/dri-devel/2018-February/16.html

I guess eventually, we'll want to remove the usage of the clock
framework entirely, but it's not really the scope of a fix.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

[PATCH 02/23] drm/mali-dp: Align pitch size to be multiple of bus burst read size.

[Liviu Dudau]

Mali DP hardware needs pitch line sizes aligned to the bus burst
size for reads, so take that into consideration when allocating dumb
buffers. If the layer is rotated then the stride size requirement is
even larger for some hardware versions, so allocate for the worst case
scenario. Update the ->dumb_create() hook to a driver specific function
that sets the correct pitch size.

Reported-by: Ayan Halder 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_drv.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 3d82712d8002..d88a3b9d59cc 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -312,13 +312,26 @@ static int malidp_irq_init(struct platform_device *pdev)
 
 DEFINE_DRM_GEM_CMA_FOPS(fops);
 
+static int malidp_dumb_create(struct drm_file *file_priv,
+ struct drm_device *drm,
+ struct drm_mode_create_dumb *args)
+{
+   struct malidp_drm *malidp = drm->dev_private;
+   /* allocate for the worst case scenario, i.e. rotated buffers */
+   u8 alignment = malidp_hw_get_pitch_align(malidp->dev, 1);
+
+   args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp, 8), 
alignment);
+
+   return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
+}
+
 static struct drm_driver malidp_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
   DRIVER_PRIME,
.lastclose = drm_fb_helper_lastclose,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
-   .dumb_create = drm_gem_cma_dumb_create,
+   .dumb_create = malidp_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
-- 
2.16.2

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

[PATCH 04/23] drm/mali-dp: Don't enable scaling engine for planes that only rotate.

[Liviu Dudau]

Currently the scaling engine gets enabled for a plane where the input
size differs from the composition size. As rotation is done natively
by the plane's hardware layer, we don't need the scaling engine to be
enabled.

Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_planes.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 9d5039f0f84e..651bd10557e0 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -159,8 +159,14 @@ static int malidp_se_check_scaling(struct malidp_plane *mp,
if (ret)
return ret;
 
-   src_w = state->src_w >> 16;
-   src_h = state->src_h >> 16;
+   if (state->rotation & MALIDP_ROTATED_MASK) {
+   src_w = state->src_h >> 16;
+   src_h = state->src_w >> 16;
+   } else {
+   src_w = state->src_w >> 16;
+   src_h = state->src_h >> 16;
+   }
+
if ((state->crtc_w == src_w) && (state->crtc_h == src_h)) {
/* Scaling not necessary for this plane. */
mc->scaled_planes_mask &= ~(mp->layer->id);
-- 
2.16.2

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

[PATCH 01/23] drm/mali-dp: Rotated planes need a larger pitch size.

[Liviu Dudau]

Rotated planes need a pitch size that is aligned to 8 bytes
for older DP500 and DP550 and at least 64 bytes for DP650. Replace
the malidp_hw_pitch_valid() function with one that calculates
the correct pitch alignment to take into account rotation.

Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_hw.h | 12 +---
 drivers/gpu/drm/arm/malidp_planes.c |  4 +++-
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index b0690ebb3565..42d3e7b9ba98 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -285,10 +285,16 @@ void malidp_se_irq_fini(struct drm_device *drm);
 u8 malidp_hw_get_format_id(const struct malidp_hw_regmap *map,
   u8 layer_id, u32 format);
 
-static inline bool malidp_hw_pitch_valid(struct malidp_hw_device *hwdev,
-unsigned int pitch)
+static inline u8 malidp_hw_get_pitch_align(struct malidp_hw_device *hwdev, 
bool rotated)
 {
-   return !(pitch & (hwdev->hw->map.bus_align_bytes - 1));
+   /*
+* only hardware that cannot do 8 bytes bus alignments have further
+* constraints on rotated planes
+*/
+   if (hwdev->hw->map.bus_align_bytes == 8)
+   return 8;
+   else
+   return hwdev->hw->map.bus_align_bytes << (rotated ? 2 : 0);
 }
 
 /* U16.16 */
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 2885d69af456..6f05c6421ba8 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -180,6 +180,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
 {
struct malidp_plane *mp = to_malidp_plane(plane);
struct malidp_plane_state *ms = to_malidp_plane_state(state);
+   bool rotated = state->rotation & MALIDP_ROTATED_MASK;
struct drm_framebuffer *fb;
int i, ret;
 
@@ -196,7 +197,8 @@ static int malidp_de_plane_check(struct drm_plane *plane,
 
ms->n_planes = fb->format->num_planes;
for (i = 0; i < ms->n_planes; i++) {
-   if (!malidp_hw_pitch_valid(mp->hwdev, fb->pitches[i])) {
+   u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
+   if (fb->pitches[i] & (alignment - 1)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
  fb->pitches[i], i);
return -EINVAL;
-- 
2.16.2

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

Re: [PATCH] drm/drm_ioctl.c: Test client capability value early when setting.

[Liviu Dudau]

On Wed, Feb 28, 2018 at 05:40:41PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 28, 2018 at 03:27:41PM +, Liviu Dudau wrote:
> > The drm_setclientcap() function implementing the DRM_IOCTL_SET_CLIENT_CAP
> > ioctl expects that any capability set by the client will have a value of 1.
> > Make the check early so that we don't have to test the value for each
> > capability.
> 
> What if we want a a non-boolean capability at some point?

Well, I'm adding another boolean capability soon, so you will be going
against the trend :)

I guess you will have 2 options: revert the patch or add a condition to
the test.

I don't have strong feelings, just felt like too much copying when
adding another capability so I thought to do some "cleanup".

Best regards,
Liviu

> 
> > 
> > Signed-off-by: Liviu Dudau 
> > ---
> >  drivers/gpu/drm/drm_ioctl.c | 9 +++--
> >  1 file changed, 3 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > index af782911c505..02ffa0e8d77b 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -306,22 +306,19 @@ drm_setclientcap(struct drm_device *dev, void *data, 
> > struct drm_file *file_priv)
> >  {
> > struct drm_set_client_cap *req = data;
> >  
> > +   if (req->value > 1)
> > +   return -EINVAL;
> > +
> > switch (req->capability) {
> > case DRM_CLIENT_CAP_STEREO_3D:
> > -   if (req->value > 1)
> > -   return -EINVAL;
> > file_priv->stereo_allowed = req->value;
> > break;
> > case DRM_CLIENT_CAP_UNIVERSAL_PLANES:
> > -   if (req->value > 1)
> > -   return -EINVAL;
> > file_priv->universal_planes = req->value;
> > break;
> > case DRM_CLIENT_CAP_ATOMIC:
> > if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> > return -EINVAL;
> > -   if (req->value > 1)
> > -   return -EINVAL;
> > file_priv->atomic = req->value;
> > file_priv->universal_planes = req->value;
> > break;
> > -- 
> > 2.16.2
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/drm_ioctl.c: Test client capability value early when setting.

[Ville Syrjälä]

On Wed, Feb 28, 2018 at 03:27:41PM +, Liviu Dudau wrote:
> The drm_setclientcap() function implementing the DRM_IOCTL_SET_CLIENT_CAP
> ioctl expects that any capability set by the client will have a value of 1.
> Make the check early so that we don't have to test the value for each
> capability.

What if we want a a non-boolean capability at some point?

> 
> Signed-off-by: Liviu Dudau 
> ---
>  drivers/gpu/drm/drm_ioctl.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index af782911c505..02ffa0e8d77b 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -306,22 +306,19 @@ drm_setclientcap(struct drm_device *dev, void *data, 
> struct drm_file *file_priv)
>  {
>   struct drm_set_client_cap *req = data;
>  
> + if (req->value > 1)
> + return -EINVAL;
> +
>   switch (req->capability) {
>   case DRM_CLIENT_CAP_STEREO_3D:
> - if (req->value > 1)
> - return -EINVAL;
>   file_priv->stereo_allowed = req->value;
>   break;
>   case DRM_CLIENT_CAP_UNIVERSAL_PLANES:
> - if (req->value > 1)
> - return -EINVAL;
>   file_priv->universal_planes = req->value;
>   break;
>   case DRM_CLIENT_CAP_ATOMIC:
>   if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
>   return -EINVAL;
> - if (req->value > 1)
> - return -EINVAL;
>   file_priv->atomic = req->value;
>   file_priv->universal_planes = req->value;
>   break;
> -- 
> 2.16.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-fixes

[Gustavo Padovan]

Hi Dave,

A few more fixes for 4.16, including 2 regression fixes. Please pull.

Thanks,

Gustavo

drm-misc-fixes-2018-02-28:
Two regression fixes here: a fb format regression on nouveau and a 4.16-rc1
regression with on LVDS with one sun4i device. Plus a sun4i and  a virtio-gpu
fixes.
The following changes since commit dfe8db22372873d205c78a9fd5370b1b088a2b87:

  Merge tag 'drm-misc-fixes-2018-02-21' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2018-02-22 08:39:26 
+1000)

are available in the Git repository at:

  git://people.freedesktop.org/drm-misc tags/drm-misc-fixes-2018-02-28

for you to fetch changes up to 9a191b114906457c4b2494c474f58ae4142d4e67:

  virtio-gpu: fix ioctl and expose the fixed status to userspace. (2018-02-27 
08:37:58 +0100)


Two regression fixes here: a fb format regression on nouveau and a 4.16-rc1
regression with on LVDS with one sun4i device. Plus a sun4i and  a virtio-gpu
fixes.


Dave Airlie (1):
  virtio-gpu: fix ioctl and expose the fixed status to userspace.

Ilia Mirkin (1):
  drm/nouveau: prefer XBGR2101010 for addfb ioctl

Maxime Ripard (1):
  drm/sun4i: Protect the TCON pixel clocks

Ondrej Jirman (1):
  drm/sun4i: Enable the output on the pins (tcon0)

 drivers/gpu/drm/drm_framebuffer.c  |  4 
 drivers/gpu/drm/nouveau/nv50_display.c |  1 +
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  7 +--
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 17 +++--
 include/drm/drm_drv.h  |  1 +
 include/uapi/drm/virtgpu_drm.h |  1 +
 6 files changed, 23 insertions(+), 8 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

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

--- Comment #8 from Harry Wentland  ---
Unplugging and replugging the display should get you back to normal.

-- 
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/3] console: Expand dummy functions for CFI

[Greg Kroah-Hartman]

On Wed, Feb 28, 2018 at 04:14:38PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday, February 28, 2018 04:09:47 PM Bartlomiej Zolnierkiewicz wrote:
> > On Monday, February 26, 2018 04:04:17 PM Kees Cook wrote:
> > > This is a small series that cleans up struct consw a bit and
> > > prepares it for Control Flow Integrity checking (i.e. Clang's
> > > -fsanitize=cfi).
> > 
> > for drivers/video/ parts:
> > 
> > Acked-by: Bartlomiej Zolnierkiewicz 
> 
> also I'll be happy to merge all patches through fbdev tree
> (if Greg is fine with it and ACKs drivers/usb/ parts)

I've already taken this through the tty tree, sorry about that.
Shouldn't cause any merge issues.

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

[PATCH] drm/drm_ioctl.c: Test client capability value early when setting.

[Liviu Dudau]

The drm_setclientcap() function implementing the DRM_IOCTL_SET_CLIENT_CAP
ioctl expects that any capability set by the client will have a value of 1.
Make the check early so that we don't have to test the value for each
capability.

Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/drm_ioctl.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index af782911c505..02ffa0e8d77b 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -306,22 +306,19 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
 {
struct drm_set_client_cap *req = data;
 
+   if (req->value > 1)
+   return -EINVAL;
+
switch (req->capability) {
case DRM_CLIENT_CAP_STEREO_3D:
-   if (req->value > 1)
-   return -EINVAL;
file_priv->stereo_allowed = req->value;
break;
case DRM_CLIENT_CAP_UNIVERSAL_PLANES:
-   if (req->value > 1)
-   return -EINVAL;
file_priv->universal_planes = req->value;
break;
case DRM_CLIENT_CAP_ATOMIC:
if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
return -EINVAL;
-   if (req->value > 1)
-   return -EINVAL;
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
-- 
2.16.2

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

[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #17 from Harry Wentland (harry.wentl...@amd.com) ---
Thanks for checking. Non-DC display driver and DC do detection somewhat
differently. It's somewhat difficult to say what's going wrong there.

Do you see different behavior when booting headless, then plugging in the
display?

If you're interested in debugging I'd probably use ftrace to get started,
checking that the functions get hit:
- handle_hpd_irq (only on hotplug)
- dc_link_detect (crucial to detection)
- dc_sink_create
- dm_helpers_read_local_edid
- drm_get_edid
- dm_helpers_parse_edid_caps
- amdgpu_dm_update_connector_after_detect
- drm_mode_connector_update_edid_property

Script to do ftrace debugging (run as root):

#!/bin/bash
cd /sys/kernel/debug/tracing/

echo handle_hpd_irq >> set_ftrace_filter
echo dc_link_detect >> set_ftrace_filter
echo dc_sink_create >> set_ftrace_filter
echo dm_helpers_read_local_edid >> set_ftrace_filter
echo drm_get_edid >> set_ftrace_filter
echo dm_helpers_parse_edid_caps >> set_ftrace_filter
echo amdgpu_dm_update_connector_after_detect >> set_ftrace_filter
echo drm_mode_connector_update_edid_property >> set_ftrace_filter

echo function_graph >> current_tracer
echo '' >> trace
cat trace_pipe

-- 
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: [PATCH v3 05/43] drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind

[Heiko Stübner]

Am Dienstag, 30. Januar 2018, 21:28:35 CET schrieb Thierry Escande:
> From: zain wang 
> 
> The bridge does not need to be powered in analogix_dp_bind(), so
> remove the calls to pm_runtime_get()/phy_power_on()/analogix_dp_init_dp()
> as well as their power-off counterparts.
> 
> Cc: Stéphane Marchesin 
> Signed-off-by: zain wang 
> Signed-off-by: Caesar Wang 
> [the patch originally just removed the power_on portion, seanpaul removed
> the power off code as well as improved the commit message]
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index
> cb5e18d6ba04..1477ea9ba85d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1382,11 +1382,6 @@ analogix_dp_bind(struct device *dev, struct
> drm_device *drm_dev,
> 
>   pm_runtime_enable(dev);
> 
> - pm_runtime_get_sync(dev);
> - phy_power_on(dp->phy);
> -
> - analogix_dp_init_dp(dp);
> -
>   ret = devm_request_threaded_irq(>dev, dp->irq,
>   analogix_dp_hardirq,
>   analogix_dp_irq_thread,
> @@ -1414,15 +1409,10 @@ analogix_dp_bind(struct device *dev, struct
> drm_device *drm_dev, goto err_disable_pm_runtime;
>   }
> 
> - phy_power_off(dp->phy);
> - pm_runtime_put(dev);
> -
>   return dp;
> 
>  err_disable_pm_runtime:
> 
> - phy_power_off(dp->phy);
> - pm_runtime_put(dev);
>   pm_runtime_disable(dev);
> 
>   return ERR_PTR(ret);

In general, this patch seems to also create the opposite than
"drm/bridge: analogix_dp: Keep PHY powered between driver bind/unbind" [0]

posted on monday?

[0] https://patchwork.kernel.org/patch/10242493/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] console: Expand dummy functions for CFI

[Bartlomiej Zolnierkiewicz]

On Monday, February 26, 2018 04:04:17 PM Kees Cook wrote:
> This is a small series that cleans up struct consw a bit and
> prepares it for Control Flow Integrity checking (i.e. Clang's
> -fsanitize=cfi).

for drivers/video/ parts:

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

[PATCH] drm: mali-dp: Turn off CRTC vblank when removing module.

[Liviu Dudau]

When unbinding the mali-dp driver the drm_vblank_cleanup() function
warns us that the vblanks are still enabled. Fix that by calling
drm_crtc_vblank_off() in the malidp_unbind() function.

Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 1d2b1c1c83aa..5c2e8260cfa1 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -673,8 +673,10 @@ static void malidp_unbind(struct device *dev)
drm_fb_cma_fbdev_fini(drm);
drm_kms_helper_poll_fini(drm);
pm_runtime_get_sync(dev);
+   drm_crtc_vblank_off(>crtc);
malidp_se_irq_fini(drm);
malidp_de_irq_fini(drm);
+   drm->irq_enabled = false;
component_unbind_all(dev, drm);
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
-- 
2.16.2

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

Re: [PATCH 0/3] console: Expand dummy functions for CFI

[Bartlomiej Zolnierkiewicz]

On Wednesday, February 28, 2018 04:09:47 PM Bartlomiej Zolnierkiewicz wrote:
> On Monday, February 26, 2018 04:04:17 PM Kees Cook wrote:
> > This is a small series that cleans up struct consw a bit and
> > prepares it for Control Flow Integrity checking (i.e. Clang's
> > -fsanitize=cfi).
> 
> for drivers/video/ parts:
> 
> Acked-by: Bartlomiej Zolnierkiewicz 

also I'll be happy to merge all patches through fbdev tree
(if Greg is fine with it and ACKs drivers/usb/ parts)

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

[PATCH] drm/arm: mali-dp: Reorder atomic_commit_hw_done to avoid waiting on wrong vblank event

[Liviu Dudau]

mali-dp driver sets the 'go' bit (config_valid) and then waits for
confirmation from the hardware that the config has been updated before
arming the vblank event. The issue is that config_valid is actually
asserted by the hardware after vblank event, during the prefetch phase,
so when arming the vblank event we are going to wait on the wrong
vblank.

Fix it by arming the vblank event first and then setting the
config_valid bit. That way the event will be signalled for the correct
vblank interrupt.

Reported-by: Alexandru-Cosmin Gheorghe 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_drv.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index d88a3b9d59cc..ac44c6127a4f 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -189,12 +189,6 @@ static void malidp_atomic_commit_hw_done(struct 
drm_atomic_state *state)
struct drm_device *drm = state->dev;
struct malidp_drm *malidp = drm->dev_private;
 
-   if (malidp->crtc.enabled) {
-   /* only set config_valid if the CRTC is enabled */
-   if (malidp_set_and_wait_config_valid(drm))
-   DRM_DEBUG_DRIVER("timed out waiting for updated 
configuration\n");
-   }
-
event = malidp->crtc.state->event;
if (event) {
malidp->crtc.state->event = NULL;
@@ -206,6 +200,12 @@ static void malidp_atomic_commit_hw_done(struct 
drm_atomic_state *state)
drm_crtc_send_vblank_event(>crtc, event);
spin_unlock_irq(>event_lock);
}
+   if (malidp->crtc.enabled) {
+   /* only set config_valid if the CRTC is enabled */
+   if (malidp_set_and_wait_config_valid(drm))
+   DRM_DEBUG_DRIVER("timed out waiting for updated 
configuration\n");
+   }
+
drm_atomic_helper_commit_hw_done(state);
 }
 
@@ -232,8 +232,6 @@ static void malidp_atomic_commit_tail(struct 
drm_atomic_state *state)
 
malidp_atomic_commit_hw_done(state);
 
-   drm_atomic_helper_wait_for_vblanks(drm, state);
-
pm_runtime_put(drm->dev);
 
drm_atomic_helper_cleanup_planes(drm, state);
-- 
2.16.2

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

Re: [PATCH libdrm] meson: add configuration summary

[Eric Engestrom]

On Tuesday, 2018-02-27 12:30:48 -0800, Eric Anholt wrote:
> Dylan Baker  writes:
> 
> > [ Unknown signature status ]
> > Quoting Eric Engestrom (2018-02-27 03:11:07)
> >> The message block printed is the same as the one in configure.ac
> >> 
> >> Signed-off-by: Eric Engestrom 
> >> ---
> >>  meson.build | 17 +
> >>  1 file changed, 17 insertions(+)
> >> 
> >> diff --git a/meson.build b/meson.build
> >> index bd00cdc2cae9f0749180..ab6f881755935968b822 100644
> >> --- a/meson.build
> >> +++ b/meson.build
> >> @@ -373,3 +373,20 @@ if with_man_pages
> >>  endif
> >>  subdir('data')
> >>  subdir('tests')
> >> +
> >> +message('')
> >> +message('@0@ will be compiled with:'.format(meson.project_name()))
> >> +message('')
> >> +message('  libkms @0@'.format(with_libkms))
> >> +message('  Intel API  @0@'.format(with_intel))
> >> +message('  vmwgfx API @0@'.format(with_vmwgfx))
> >> +message('  Radeon API @0@'.format(with_radeon))
> >> +message('  AMDGPU API @0@'.format(with_amdgpu))
> >> +message('  Nouveau API@0@'.format(with_nouveau))
> >> +message('  OMAP API   @0@'.format(with_omap))
> >> +message('  EXYNOS API @0@'.format(with_exynos))
> >> +message('  Freedreno API  @0@ (kgsl: @1@)'.format(with_freedreno, 
> >> with_freedreno_kgsl))
> >> +message('  Tegra API  @0@'.format(with_tegra))
> >> +message('  VC4 API@0@'.format(with_vc4))
> >> +message('  Etnaviv API@0@'.format(with_etnaviv))
> >> +message('')
> >> -- 
> >> Cheers,
> >>   Eric
> >> 
> >
> > This one is certainly simple enough that we can use a single message call 
> > and a
> > ''' string :)
> 
> But then you end up with 13 @n@ values and when someone wants to put
> something earlier in the list for some sorting reason, then they need to
> renumber the rest.  This is much nicer.

I have to agree here. Dylan, why did you want to avoid multiple
`message()`? They're not expensive afaict, so I'm not sure what the gain
would be?

I also had a try, and multiline messages only get a `Message:` prefix on
the first line, so combining them would result in unpredictable vertical
alignments. Unless there's a good reason to merge them, I'll keep them
separate.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 05/10] drm: Define helper function for plane color enabling

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sean Paul
>Sent: Tuesday, February 27, 2018 8:59 PM
>To: Daniele Castagna 
>Cc: dri-devel@lists.freedesktop.org
>Subject: Re: [PATCH 05/10] drm: Define helper function for plane color enabling
>
>On Thu, Feb 15, 2018 at 12:32:55AM -0500, Daniele Castagna wrote:
>> From: "uma.shankar at intel.com (Uma Shankar)" 
>>
>> Define helper function to enable Plane color features to attach plane
>> color properties to plane structure.
>>
>> (am from https://patchwork.kernel.org/patch/9971333/)
>>
>> Change-Id: I0a6647607fe482786e7cdb5f997faf196b2f59a2
>> Signed-off-by: Uma Shankar 
>> ---
>>  drivers/gpu/drm/drm_plane.c  | 48
>> 
>>  include/drm/drm_color_mgmt.h |  5 
>>  2 files changed, 53 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
>> index 2c90519576a3e..bc2fc5e6771ac 100644
>> --- a/drivers/gpu/drm/drm_plane.c
>> +++ b/drivers/gpu/drm/drm_plane.c
>> @@ -143,6 +143,54 @@ static int create_in_format_blob(struct drm_device
>*dev, struct drm_plane *plane
>>  return 0;
>>  }
>>
>> + /**
>> + * drm_plane_enable_color_mgmt - enable color management properties
>> + * @plane: DRM Plane
>> + * @plane_degamma_lut_size: the size of the degamma lut (before CSC)
>> + * @plane_has_ctm: whether to attach ctm_property for CSC matrix
>> + * @plane_gamma_lut_size: the size of the gamma lut (after CSC)
>> + *
>> + * This function lets the driver enable the color correction
>> + * properties on a plane. This includes 3 degamma, csc and gamma
>> + * properties that userspace can set and 2 size properties to inform
>> + * the userspace of the lut sizes. Each of the properties are
>> + * optional. The gamma and degamma properties are only attached if
>> + * their size is not 0 and ctm_property is only attached if has_ctm
>> +is
>> + * true.
>> + *
>> + * Drivers should use drm_atomic_helper_legacy_gamma_set() to
>> +implement the
>> + * legacy _crtc_funcs.gamma_set callback.
>> + */
>> +void drm_plane_enable_color_mgmt(struct drm_plane *plane,
>> +uint plane_degamma_lut_size,
>> +bool plane_has_ctm,
>> +uint plane_gamma_lut_size)
>> +{
>
>This seems like a good place to create the properties once they're located in
>drm_plane.
>

Yeah, I agree. Will update the series.

Regards,
Uma Shankar

>> +struct drm_device *dev = plane->dev;
>> +struct drm_mode_config *config = >mode_config;
>> +
>> +if (plane_degamma_lut_size) {
>> +drm_object_attach_property(>base,
>> +config->plane_degamma_lut_property, 0);
>> +drm_object_attach_property(>base,
>> +config->plane_degamma_lut_size_property,
>> +plane_degamma_lut_size);
>> +}
>> +
>> +if (plane_has_ctm)
>> +drm_object_attach_property(>base,
>> +config->plane_ctm_property, 0);
>> +
>> +if (plane_gamma_lut_size) {
>> +drm_object_attach_property(>base,
>> +config->plane_gamma_lut_property, 0);
>> +drm_object_attach_property(>base,
>> +config->plane_gamma_lut_size_property,
>> +plane_gamma_lut_size);
>> +}
>> +}
>> +EXPORT_SYMBOL(drm_plane_enable_color_mgmt);
>> +
>>  /**
>>   * drm_universal_plane_init - Initialize a new universal plane object
>>   * @dev: DRM device
>> diff --git a/include/drm/drm_color_mgmt.h
>> b/include/drm/drm_color_mgmt.h index 03a59cbce6212..155a9ba38471c
>> 100644
>> --- a/include/drm/drm_color_mgmt.h
>> +++ b/include/drm/drm_color_mgmt.h
>> @@ -37,4 +37,9 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc
>> *crtc,  int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>>   int gamma_size);
>>
>> +void drm_plane_enable_color_mgmt(struct drm_plane *plane,
>> + uint plane_degamma_lut_size,
>> + bool plane_has_ctm,
>> + uint plane_gamma_lut_size);
>> +
>>  #endif
>> --
>> 2.16.1.291.g4437f3f132-goog
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Sean Paul, Software Engineer, Google / Chromium OS
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 05/43] drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind

[Heiko Stübner]

Am Mittwoch, 28. Februar 2018, 15:54:30 CET schrieb Marc Zyngier:
> On 28/02/18 14:37, Heiko Stübner wrote:
> > Am Dienstag, 30. Januar 2018, 21:28:35 CET schrieb Thierry Escande:
> >> From: zain wang 
> >> 
> >> The bridge does not need to be powered in analogix_dp_bind(), so
> >> remove the calls to pm_runtime_get()/phy_power_on()/analogix_dp_init_dp()
> >> as well as their power-off counterparts.
> >> 
> >> Cc: Stéphane Marchesin 
> >> Signed-off-by: zain wang 
> >> Signed-off-by: Caesar Wang 
> >> [the patch originally just removed the power_on portion, seanpaul removed
> >> the power off code as well as improved the commit message]
> >> Signed-off-by: Sean Paul 
> >> Signed-off-by: Thierry Escande 
> >> ---
> >> 
> >>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 10 --
> >>  1 file changed, 10 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index
> >> cb5e18d6ba04..1477ea9ba85d 100644
> >> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> >> @@ -1382,11 +1382,6 @@ analogix_dp_bind(struct device *dev, struct
> >> drm_device *drm_dev,
> >> 
> >>pm_runtime_enable(dev);
> >> 
> >> -  pm_runtime_get_sync(dev);
> >> -  phy_power_on(dp->phy);
> >> -
> >> -  analogix_dp_init_dp(dp);
> >> -
> >> 
> >>ret = devm_request_threaded_irq(>dev, dp->irq,
> >>
> >>analogix_dp_hardirq,
> >>analogix_dp_irq_thread,
> > 
> > Not 100% sure here, as the driver has the request-irq + disable-irq hack
> > here. So a pending interrupt could possibly fire between request and
> > disable.
> > 
> > Right now the block should be on, but can it still handle such an irq
> > when the power is removed?
> 
> Probably not (see below).
> 
> > So before removing the power here, we might want something
> > similar to what Marc posted for the vop [0] for the analogix-dp?
> 
> You can do that trick only if the interrupt is not shared. In the VOP
> case, it is shared with the IOMMU, which makes it more... interesting.

Yep, which is why I mentioned it, as the dp-irq should not be shared
I'd think :-)


Heiko

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

RE: [PATCH 03/10] drm: Add Plane CTM property

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sean Paul
>Sent: Tuesday, February 27, 2018 8:53 PM
>To: Daniele Castagna 
>Cc: dri-devel@lists.freedesktop.org
>Subject: Re: [PATCH 03/10] drm: Add Plane CTM property
>
>On Thu, Feb 15, 2018 at 12:32:53AM -0500, Daniele Castagna wrote:
>> From: "uma.shankar at intel.com (Uma Shankar)" 
>>
>> Add a blob property for plane CSC usage.
>>
>> (am from https://patchwork.kernel.org/patch/9971339/)
>>
>> Change-Id: I688ce7c95c20d307cb0aa35c5eba5ce2e1e88314
>> Signed-off-by: Uma Shankar 
>> ---
>>  drivers/gpu/drm/drm_atomic.c| 10 ++
>>  drivers/gpu/drm/drm_atomic_helper.c |  3 +++
>>  drivers/gpu/drm/drm_mode_config.c   |  6 ++
>>  include/drm/drm_mode_config.h   |  6 ++
>>  include/drm/drm_plane.h |  8 
>>  5 files changed, 33 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c
>> b/drivers/gpu/drm/drm_atomic.c index 4a06ff2fd1a5e..d4b8c6cc84128
>> 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -770,6 +770,14 @@ static int drm_atomic_plane_set_property(struct
>drm_plane *plane,
>>  val, -1, );
>>  state->color_mgmt_changed |= replaced;
>>  return ret;
>> +} else if (property == config->plane_ctm_property) {
>> +ret = drm_atomic_replace_property_blob_from_id(dev,
>> +>ctm,
>> +val,
>> +sizeof(struct drm_color_ctm),
>> +);
>> +state->color_mgmt_changed |= replaced;
>> +return ret;
>>  } else {
>>  return -EINVAL;
>>  }
>> @@ -831,6 +839,8 @@ drm_atomic_plane_get_property(struct drm_plane
>*plane,
>>  } else if (property == config->plane_degamma_lut_property) {
>>  *val = (state->degamma_lut) ?
>>  state->degamma_lut->base.id : 0;
>> +} else if (property == config->plane_ctm_property) {
>> +*val = (state->ctm) ? state->ctm->base.id : 0;
>>  } else {
>>  return -EINVAL;
>>  }
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index d3eaf4d397681..17e137a529a0e 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -3493,6 +3493,8 @@ void
>> __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>>
>>  if (state->degamma_lut)
>>  drm_property_reference_blob(state->degamma_lut);
>> +if (state->ctm)
>> +drm_property_reference_blob(state->ctm);
>>  state->color_mgmt_changed = false;
>>  }
>>  EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
>> @@ -3540,6 +3542,7 @@ void
>__drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
>>  drm_crtc_commit_put(state->commit);
>>
>>  drm_property_unreference_blob(state->degamma_lut);
>> +drm_property_unreference_blob(state->ctm);
>>  }
>>  EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>>
>> diff --git a/drivers/gpu/drm/drm_mode_config.c
>> b/drivers/gpu/drm/drm_mode_config.c
>> index 7d8e74715b565..c8763977413e7 100644
>> --- a/drivers/gpu/drm/drm_mode_config.c
>> +++ b/drivers/gpu/drm/drm_mode_config.c
>> @@ -361,6 +361,12 @@ static int
>drm_mode_create_standard_properties(struct drm_device *dev)
>>  if (!prop)
>>  return -ENOMEM;
>>  dev->mode_config.plane_degamma_lut_size_property = prop;
>> +prop = drm_property_create(dev,
>> +DRM_MODE_PROP_BLOB,
>> +"PLANE_CTM", 0);
>> +if (!prop)
>> +return -ENOMEM;
>> +dev->mode_config.plane_ctm_property = prop;
>>
>>  return 0;
>>  }
>> diff --git a/include/drm/drm_mode_config.h
>> b/include/drm/drm_mode_config.h index dcec93d062b4d..ad7235ced531b
>> 100644
>> --- a/include/drm/drm_mode_config.h
>> +++ b/include/drm/drm_mode_config.h
>> @@ -734,6 +734,12 @@ struct drm_mode_config {
>>   * size of the degamma LUT as supported by the driver (read-only).
>>   */
>>  struct drm_property *plane_degamma_lut_size_property;
>> +/**
>> + * @plane_ctm_property: Optional CRTC property to set the
>> + * matrix used to convert colors after the lookup in the
>> + * degamma LUT.
>> + */
>> +struct drm_property *plane_ctm_property;
>
>Same comments re: puttting the property in drm_plane and adding a helper to
>create it.
>

Sure, will update this.

Regards,
Uma Shankar

>Sean
>
>>  /**
>>   * @ctm_property: Optional CRTC property to set the
>>   * matrix used to convert colors after the lookup in the diff --git
>> a/include/drm/drm_plane.h b/include/drm/drm_plane.h index
>> 2f8f5db77a406..21aecc9c91a09 100644
>> --- a/include/drm/drm_plane.h
>> +++ 

RE: [PATCH 02/10] drm: Add Plane Degamma properties

[Shankar, Uma]

>-Original Message-
>From: Sean Paul [mailto:seanp...@chromium.org]
>Sent: Tuesday, February 27, 2018 8:44 PM
>To: Daniele Castagna 
>Cc: dri-devel@lists.freedesktop.org; brian.star...@arm.com; Shankar, Uma
>
>Subject: Re: [PATCH 02/10] drm: Add Plane Degamma properties
>
>On Thu, Feb 15, 2018 at 12:32:52AM -0500, Daniele Castagna wrote:
>> From: "uma.shankar at intel.com (Uma Shankar)" 
>>
>> Add Plane Degamma as a blob property and plane degamma size as a range
>> property.
>>
>> (am from https://patchwork.kernel.org/patch/10046515/)
>
>The discussion on this previous version has some feedback on using 32-bit 
>values
>in the gamma lut instead of 16-bit. Have you considered this?
>

This needs to be modified. Will address this and send a next version.
Kept it on hold since was trying to get a userspace implementation done.
But, it's good to refresh the series addressing all the review comments.
Thanks for the review Sean Paul.

>>
>> Change-Id: Iaead6f944a8b677227d1be11169f46178de533b1
>> Signed-off-by: Uma Shankar 
>> ---
>>  drivers/gpu/drm/drm_atomic.c| 12 
>>  drivers/gpu/drm/drm_atomic_helper.c |  7 +++
>>  drivers/gpu/drm/drm_mode_config.c   | 14 ++
>>  include/drm/drm_mode_config.h   | 10 ++
>>  include/drm/drm_plane.h | 10 ++
>>  5 files changed, 53 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c
>> b/drivers/gpu/drm/drm_atomic.c index b76d49218cf1d..4a06ff2fd1a5e
>> 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -717,6 +717,8 @@ static int drm_atomic_plane_set_property(struct
>> drm_plane *plane,  {
>>  struct drm_device *dev = plane->dev;
>>  struct drm_mode_config *config = >mode_config;
>> +bool replaced = false;
>> +int ret;
>>
>>  if (property == config->prop_fb_id) {
>>  struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
>NULL,
>> val); @@ -762,6 +764,12 @@ static int drm_atomic_plane_set_property(struct
>drm_plane *plane,
>>  } else if (plane->funcs->atomic_set_property) {
>>  return plane->funcs->atomic_set_property(plane, state,
>>  property, val);
>> +} else if (property == config->plane_degamma_lut_property) {
>> +ret = drm_atomic_replace_property_blob_from_id(dev,
>> +>degamma_lut,
>> +val, -1, );
>> +state->color_mgmt_changed |= replaced;
>> +return ret;
>>  } else {
>>  return -EINVAL;
>>  }
>> @@ -820,6 +828,9 @@ drm_atomic_plane_get_property(struct drm_plane
>*plane,
>>  *val = state->zpos;
>>  } else if (plane->funcs->atomic_get_property) {
>>  return plane->funcs->atomic_get_property(plane, state,
>property,
>> val);
>> +} else if (property == config->plane_degamma_lut_property) {
>> +*val = (state->degamma_lut) ?
>> +state->degamma_lut->base.id : 0;
>>  } else {
>>  return -EINVAL;
>>  }
>> @@ -944,6 +955,7 @@ static void drm_atomic_plane_print_state(struct
>drm_printer *p,
>>  drm_printf(p, "\tcrtc-pos=" DRM_RECT_FMT "\n",
>DRM_RECT_ARG());
>>  drm_printf(p, "\tsrc-pos=" DRM_RECT_FP_FMT "\n",
>DRM_RECT_FP_ARG());
>>  drm_printf(p, "\trotation=%x\n", state->rotation);
>> +drm_printf(p, "\tcolor_mgmt_changed=%d\n",
>> +state->color_mgmt_changed);
>>
>>  if (plane->funcs->atomic_print_state)
>>  plane->funcs->atomic_print_state(p, state); diff --git
>> a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index ab4032167094c..d3eaf4d397681 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -3488,7 +3488,12 @@ void
>__drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>>  drm_framebuffer_get(state->fb);
>>
>>  state->fence = NULL;
>> +
>
>Extra line snuck in here
>

Will rectify this.

>>  state->commit = NULL;
>> +
>> +if (state->degamma_lut)
>> +drm_property_reference_blob(state->degamma_lut);
>> +state->color_mgmt_changed = false;
>>  }
>>  EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
>>
>> @@ -3533,6 +3538,8 @@ void
>> __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
>>
>>  if (state->commit)
>>  drm_crtc_commit_put(state->commit);
>> +
>> +drm_property_unreference_blob(state->degamma_lut);
>>  }
>>  EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>>
>> diff --git a/drivers/gpu/drm/drm_mode_config.c
>> b/drivers/gpu/drm/drm_mode_config.c
>> index e5c653357024d..7d8e74715b565 100644
>> --- a/drivers/gpu/drm/drm_mode_config.c
>> +++ b/drivers/gpu/drm/drm_mode_config.c
>> @@ -348,6 +348,20 @@ static int
>drm_mode_create_standard_properties(struct drm_device