Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Pekka Paalanen]

On Tue, 02 May 2017 07:45:25 -0700
Keith Packard  wrote:

> Pekka Paalanen  writes:

> > I presume that if "desktop" is set to "true", it implies that the HMD
> > is capable of showing a simple 2D canvas in stereo without any special
> > rendering and with the default video mode. That is, creating a sort of
> > a virtual 2D monitor. That would be nice.  
> 
> I was thinking that 'desktop' would be true for non-HMD displays that
> didn't need the VR compositor. If you've got a VR compositor and want to
> paint the desktop inside the VR environment, then I think you'd want to
> create a synthetic monitor and hand images from that to the VR
> compositor each frame.

Hi Keith,

do you mean to list all kinds of display devices in the database? I was
assuming it would list only HMDs, so not in database would imply it's a
normal display and good for extending the desktop to.

Or did you mean it for exceptions? As in, define a range of HMDs, but
the vendor put a few normal displays in the middle of the range, so one
needs to be able to exclude those?

The reason I mentioned "virtual 2D display" was that I recall hearing
that actually exists in some HMD hardware. If you don't do anything to
enable a 3D mode, the HMD will process the signal to produce a virtual
2D display in front the user. In such case, there is no need for a VR
compositor, the plain old 2D image signal will be shown correctly on a
plane in the virtual space by the HMD hardware itself.

I asked on #openhmd and was pointed to "Cinematic mode" on PSVR, and
found e.g. this:
http://www.psu.com/feature/31372/How-to-use-PlayStation-VR-cinematic-mode-effectively

Mind the note towards the bottom: you don't actually need a PS4 to use
it - so it must be something built into the HMD. However, reading more
details from
https://blog.us.playstation.com/2016/10/03/playstation-vr-the-ultimate-faq/
reveals that there is actually a separate processor box providing the
cinematic mode. Sounds like it's your VR compositor as a middle-man
hardware device rather than just a program. :-)


Thanks,
pq


pgpMNYGNFsHOZ.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/5] vblanke cleanup resend

[Daniel Vetter]

Hi all,

Very minor cleanups from Neil's review, and a minimal rebase because nouveau
changed something. Otherwise unchanged.

Still would like an ack from Ville/Mario before merging.

Thanks, Daniel

Daniel Vetter (5):
  drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool
  drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp
  drm/vblank: Add FIXME comments about moving the vblank ts hooks
  drm/vblank: drop the mode argument from
drm_calc_vbltimestamp_from_scanoutpos
  drm/vblank: Lock down vblank->hwmode more

 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   4 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  14 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  41 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |   3 +
 drivers/gpu/drm/drm_irq.c | 131 +-
 drivers/gpu/drm/i915/i915_irq.c   |  62 +++---
 drivers/gpu/drm/i915/intel_display.c  |  11 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  45 ++
 drivers/gpu/drm/nouveau/nouveau_display.c |  39 ++---
 drivers/gpu/drm/nouveau/nouveau_display.h |   8 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c |   2 +-
 drivers/gpu/drm/radeon/radeon_drv.c   |  18 ++--
 drivers/gpu/drm/radeon/radeon_kms.c   |  37 -
 drivers/gpu/drm/radeon/radeon_mode.h  |   3 +
 drivers/gpu/drm/vc4/vc4_crtc.c|  34 +++-
 drivers/gpu/drm/vc4/vc4_drv.c |   2 +-
 drivers/gpu/drm/vc4/vc4_drv.h |  11 +--
 include/drm/drmP.h|   9 --
 include/drm/drm_drv.h |  52 ++--
 include/drm/drm_irq.h |  21 +++--
 20 files changed, 196 insertions(+), 351 deletions(-)

-- 
2.11.0

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

[PATCH 2/5] drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp

[Daniel Vetter]

It's overkill to have a flag parameter which is essentially used just
as a boolean. This takes care of core + adjusting drivers.

Adjusting the scanout position callback is a bit harder, since radeon
also supplies it's own driver-private flags in there.

v2: Fixup misplaced hunks (Neil).

Cc: Mario Kleiner 
Cc: Eric Anholt 
Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: Ben Skeggs 
Reviewed-by: Ville Syrjälä 
Reviewed-by: Neil Armstrong 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  6 ++---
 drivers/gpu/drm/drm_irq.c | 41 +--
 drivers/gpu/drm/i915/i915_irq.c   |  4 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  4 +--
 drivers/gpu/drm/nouveau/nouveau_display.c |  5 ++--
 drivers/gpu/drm/nouveau/nouveau_display.h |  2 +-
 drivers/gpu/drm/radeon/radeon_drv.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_kms.c   |  4 +--
 drivers/gpu/drm/vc4/vc4_crtc.c|  6 ++---
 drivers/gpu/drm/vc4/vc4_drv.h |  2 +-
 include/drm/drm_drv.h | 17 +++--
 include/drm/drm_irq.h |  2 +-
 13 files changed, 51 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 7b4f808afff9..0ce8292d97c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1913,7 +1913,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe);
 bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
 int *max_error,
 struct timeval *vblank_time,
-unsigned flags);
+bool in_vblank_irq);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
 unsigned long arg);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index a1b97809305e..babd969a63d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -941,7 +941,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe)
  * @crtc: crtc to get the timestamp for
  * @max_error: max error
  * @vblank_time: time value
- * @flags: flags passed to the driver
+ * @in_vblank_irq: called from drm_handle_vblank()
  *
  * Gets the timestamp on the requested crtc based on the
  * scanout position.  (all asics).
@@ -950,7 +950,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe)
 bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
 int *max_error,
 struct timeval *vblank_time,
-unsigned flags)
+bool in_vblank_irq)
 {
struct drm_crtc *crtc;
struct amdgpu_device *adev = dev->dev_private;
@@ -971,7 +971,7 @@ bool amdgpu_get_vblank_timestamp_kms(struct drm_device 
*dev, unsigned int pipe,
 
/* Helper routine in DRM core does all the work: */
return drm_calc_vbltimestamp_from_scanoutpos(dev, pipe, max_error,
-vblank_time, flags,
+vblank_time, in_vblank_irq,
 &crtc->hwmode);
 }
 
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 677b37b0372b..fba6a842f4cd 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -54,7 +54,7 @@
 
 static bool
 drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
- struct timeval *tvblank, unsigned flags);
+ struct timeval *tvblank, bool in_vblank_irq);
 
 static unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
 
@@ -138,7 +138,7 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
 */
do {
cur_vblank = __get_vblank_counter(dev, pipe);
-   rc = drm_get_last_vbltimestamp(dev, pipe, &t_vblank, 0);
+   rc = drm_get_last_vbltimestamp(dev, pipe, &t_vblank, false);
} while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
 
/*
@@ -171,7 +171,7 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
  * device vblank fields.
  */
 static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
-   unsigned long flags)
+   bool in_vblank_irq)
 {
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
u32 cur_vblank, diff;
@@ -194,7 +194,7 

[PATCH 3/5] drm/vblank: Add FIXME comments about moving the vblank ts hooks

[Daniel Vetter]

This is going to be a bit too much, but good to have at least a small
note about where this should all head towards.

Reviewed-by: Neil Armstrong 
Signed-off-by: Daniel Vetter 
---
 include/drm/drm_drv.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index a97dbc1eeccd..619da98533cd 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -276,6 +276,11 @@ struct drm_driver {
 * constant but unknown small number of scanlines wrt. real scanout
 * position.
 *
+* FIXME:
+*
+* Since this is a helper to implement @get_vblank_timestamp, we should
+* move it to &struct drm_crtc_helper_funcs, like all the other
+* helper-internal hooks.
 */
int (*get_scanout_position) (struct drm_device *dev, unsigned int pipe,
 unsigned int flags, int *vpos, int *hpos,
@@ -319,6 +324,11 @@ struct drm_driver {
 *
 * True on success, false on failure, which means the core should
 * fallback to a simple timestamp taken in drm_crtc_handle_vblank().
+*
+* FIXME:
+*
+* We should move this hook to &struct drm_crtc_funcs like all the other
+* vblank hooks.
 */
bool (*get_vblank_timestamp) (struct drm_device *dev, unsigned int pipe,
 int *max_error,
-- 
2.11.0

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

[PATCH 4/5] drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos

[Daniel Vetter]

If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:

- All legacy drivers look at crtc->hwmode. But that is updated already
  at the beginning of the modeset helper, which means when we disable
  a pipe. Hence the final timestamps might be a bit off. But since
  this is an existing bug I'm not going to change it, but just try to
  be bug-for-bug compatible with the current code. This only applies
  to radeon&amdgpu.

- i915 tries to get it perfect by updating crtc->hwmode when the pipe
  is off (i.e. vblank->enabled = false).

- All other atomic drivers look at crtc->state->adjusted_mode. Those
  that look at state->requested_mode simply don't adjust their mode,
  so it's the same. That has two problems: Accessing crtc->state from
  interrupt handling code is unsafe, and it's updated before we shut
  down the pipe. For nonblocking modesets it's even worse.

For atomic drivers try to implement what i915 does. To do that we add
a new hwmode field to the vblank structure, and update it from
drm_calc_timestamping_constants(). For atomic drivers that's called
from the right spot by the helper library already, so all fine. But
for safety let's enforce that.

For legacy driver this function is only called at the end (oh the
fun), which is broken, so again let's not bother and just stay
bug-for-bug compatible.

The  benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
directly to implement ->get_vblank_timestamp in every driver, deleting
a lot of code.

v2: Completely new approach, trying to mimick the i915 solution.

v3: Fixup kerneldoc.

v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
currently unconditionally call this. Recomputing the same stuff should
be harmless.

v5: Fix typos and move misplaced hunks to the right patches (Neil).

Cc: Mario Kleiner 
Cc: Eric Anholt 
Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: Ben Skeggs 
Reviewed-by: Neil Armstrong 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  4 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 14 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 41 
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  3 ++
 drivers/gpu/drm/drm_irq.c | 43 ++---
 drivers/gpu/drm/i915/i915_irq.c   | 52 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 45 +-
 drivers/gpu/drm/nouveau/nouveau_display.c | 38 +-
 drivers/gpu/drm/nouveau/nouveau_display.h |  8 ++---
 drivers/gpu/drm/nouveau/nouveau_drm.c |  2 +-
 drivers/gpu/drm/radeon/radeon_drv.c   | 18 +++
 drivers/gpu/drm/radeon/radeon_kms.c   | 37 --
 drivers/gpu/drm/radeon/radeon_mode.h  |  3 ++
 drivers/gpu/drm/vc4/vc4_crtc.c| 32 ++-
 drivers/gpu/drm/vc4/vc4_drv.c |  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h | 11 +++
 include/drm/drmP.h|  8 -
 include/drm/drm_drv.h | 20 
 include/drm/drm_irq.h | 15 +++--
 19 files changed, 120 insertions(+), 276 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 0ce8292d97c0..9de615bb0c2e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1910,10 +1910,6 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
resume, bool fbcon);
 u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
 int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
 void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
-bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
-int *max_error,
-struct timeval *vblank_time,
-bool in_vblank_irq);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
 unsigned long arg);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 4e0f7d2d87f1..73e982cd6136 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -711,6 +711,16 @@ static const struct file_operations amdgpu_driver_kms_fops 
= {
 #endif
 };
 
+static bool
+amdgpu_get_crtc_scanout_position(struct drm_device *dev, unsigned int pipe,
+bool in_vblank_irq, int *vpos, int *hpos,
+ktime_t *stime, ktime_t *etime,
+const struct drm_display_mode *mode)
+{
+   return amdgpu_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
+   

[PATCH 1/5] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

[Daniel Vetter]

There's really no reason for anything more:
- Calling this while the crtc vblank stuff isn't set up is a driver
  bug. Those places alrready DRM_ERROR.
- Calling this when the crtc is off is either a driver bug (calling
  drm_crtc_handle_vblank at the wrong time) or a core bug (for
  anything else). Again, we DRM_ERROR.
- EINVAL is checked at higher levels already, and if we'd use struct
  drm_crtc * instead of (dev, pipe) it would be real obvious that
  those are again core bugs.

The only valid failure mode is crap hardware that couldn't sample a
useful timestamp, to ask the core to just grab a not-so-accurate
timestamp. Bool is perfectly fine for that.

v2: Also fix up the one caller, I lost that in the shuffling (Jani).

v3: Fixup commit message (Neil).

Cc: Jani Nikula 
Cc: Mario Kleiner 
Cc: Eric Anholt 
Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: Ben Skeggs 
Reviewed-by: Neil Armstrong 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  8 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 14 -
 drivers/gpu/drm/drm_irq.c | 49 ---
 drivers/gpu/drm/i915/i915_irq.c   |  8 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 12 
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 +--
 drivers/gpu/drm/nouveau/nouveau_display.h |  4 +--
 drivers/gpu/drm/radeon/radeon_drv.c   |  8 ++---
 drivers/gpu/drm/radeon/radeon_kms.c   | 14 -
 drivers/gpu/drm/vc4/vc4_crtc.c|  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h |  2 +-
 include/drm/drmP.h|  1 -
 include/drm/drm_drv.h |  7 ++---
 include/drm/drm_irq.h | 10 +++
 14 files changed, 64 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 6a8129949333..7b4f808afff9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1910,10 +1910,10 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
resume, bool fbcon);
 u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
 int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
 void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
-int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
-   int *max_error,
-   struct timeval *vblank_time,
-   unsigned flags);
+bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
+int *max_error,
+struct timeval *vblank_time,
+unsigned flags);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
 unsigned long arg);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 832be632478f..a1b97809305e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -945,19 +945,19 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe)
  *
  * Gets the timestamp on the requested crtc based on the
  * scanout position.  (all asics).
- * Returns postive status flags on success, negative error on failure.
+ * Returns true on success, false on failure.
  */
-int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
-   int *max_error,
-   struct timeval *vblank_time,
-   unsigned flags)
+bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
+int *max_error,
+struct timeval *vblank_time,
+unsigned flags)
 {
struct drm_crtc *crtc;
struct amdgpu_device *adev = dev->dev_private;
 
if (pipe >= dev->num_crtcs) {
DRM_ERROR("Invalid crtc %u\n", pipe);
-   return -EINVAL;
+   return false;
}
 
/* Get associated drm_crtc: */
@@ -966,7 +966,7 @@ int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, 
unsigned int pipe,
/* This can occur on driver load if some component fails to
 * initialize completely and driver is unloaded */
DRM_ERROR("Uninitialized crtc %d\n", pipe);
-   return -EINVAL;
+   return false;
}
 
/* Helper routine in DRM core does all the work: */
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 8c866cac62dd..677b37b0372b 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -724,43 +724,32 @@ E

[PATCH 5/5] drm/vblank: Lock down vblank->hwmode more

[Daniel Vetter]

In the previous patch we've implemented hwmode tracking a la i915 for
the vblank timestamp calculations. But that was just the basic
semantics, i915 has some nice sanity checks to make sure we keep
getting this right. Move them over too.

Cc: Ville Syrjälä 
Reviewed-by: Neil Armstrong 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c|  8 +++-
 drivers/gpu/drm/i915/i915_irq.c  | 10 ++
 drivers/gpu/drm/i915/intel_display.c | 11 ++-
 3 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 89f0928b042a..942183a2aa3c 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -775,8 +775,10 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
/* If mode timing undefined, just return as no-op:
 * Happens during initial modesetting of a crtc.
 */
-   if (mode->crtc_clock == 0) {
+   if (WARN_ON(mode->crtc_clock == 0)) {
DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
+   WARN_ON(drm_drv_uses_atomic_modeset(dev));
+
return false;
}
 
@@ -1338,6 +1340,10 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
send_vblank_event(dev, e, seq, &now);
}
spin_unlock_irqrestore(&dev->event_lock, irqflags);
+
+   /* Will be reset by the modeset helpers when re-enabling the crtc by
+* calling drm_calc_timestamping_constants(). */
+   vblank->hwmode.crtc_clock = 0;
 }
 EXPORT_SYMBOL(drm_crtc_vblank_off);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 837e5bc2019a..ff18b3fc00d2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -720,9 +720,7 @@ static u32 i915_get_vblank_counter(struct drm_device *dev, 
unsigned int pipe)
struct drm_i915_private *dev_priv = to_i915(dev);
i915_reg_t high_frame, low_frame;
u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
-   struct intel_crtc *intel_crtc = intel_get_crtc_for_pipe(dev_priv,
-   pipe);
-   const struct drm_display_mode *mode = &intel_crtc->base.hwmode;
+   const struct drm_display_mode *mode = &dev->vblank[pipe].hwmode;
unsigned long irqflags;
 
htotal = mode->crtc_htotal;
@@ -779,13 +777,17 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
*crtc)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   const struct drm_display_mode *mode = &crtc->base.hwmode;
+   const struct drm_display_mode *mode;
+   struct drm_vblank_crtc *vblank;
enum pipe pipe = crtc->pipe;
int position, vtotal;
 
if (!crtc->active)
return -1;
 
+   vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)];
+   mode = &vblank->hwmode;
+
vtotal = mode->crtc_vtotal;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
vtotal /= 2;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 85b9e2f521a0..a190973daeee 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11443,12 +11443,6 @@ intel_modeset_update_crtc_state(struct 
drm_atomic_state *state)
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
to_intel_crtc(crtc)->config = 
to_intel_crtc_state(new_crtc_state);
 
-   /* Update hwmode for vblank functions */
-   if (new_crtc_state->active)
-   crtc->hwmode = new_crtc_state->adjusted_mode;
-   else
-   crtc->hwmode.crtc_clock = 0;
-
/*
 * Update legacy state to satisfy fbc code. This can
 * be removed when fbc uses the atomic state.
@@ -15425,8 +15419,6 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
to_intel_crtc_state(crtc->base.state);
int pixclk = 0;
 
-   crtc->base.hwmode = crtc_state->base.adjusted_mode;
-
memset(&crtc->base.mode, 0, sizeof(crtc->base.mode));
if (crtc_state->base.active) {
intel_mode_from_pipe_config(&crtc->base.mode, 
crtc_state);
@@ -15456,7 +15448,8 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
pixclk = DIV_ROUND_UP(pixclk * 100, 95);
 
-   drm_calc_timestamping_constants(&crtc->base, 
&crtc->base.hwmode);
+   drm_calc_timestamping_constants(&crtc->base,
+   
&crtc_state->base.adjusted_mode);
update_scanline_offset(crtc);
  

Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform

[Daniel Vetter]

On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> >  /**
> > + * drm_gem_prime_import_platform - alternate implementation of the import 
> > callback
> > + * @dev: drm_device to import into
> > + * @dma_buf: dma-buf object to import
> > + *
> > + * This is identical to drm_gem_prime_import except the device used for 
> > dma_buf
> > + * attachment is an internal platform device instead of the standard device
> > + * structure. The use of this function should be limited to drivers that 
> > do not
> > + * set up an underlying device structure.
> > + */
> > +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device 
> > *dev,
> 
> Simpler soluation will be for the caller to provide the platformdev?
> 
> That works nicely for the vgem case, I think.

Yeah looking at this again, do we really need this patch? Couldn't we
instead change patch 1 to first allocate the fake platform device, then
pass that to drm_dev_alloc (instead of NULL like we do now)?

That way no resurrection of drm_device.platform_dev is needed (and I'd
really like this zombie to stay dead on 2nd thought).

Sry about this yet-another-round review :-/
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RESEND FOR CI PATCH v8 4/4] drm/dp: Track MST link bandwidth

[Daniel Vetter]

On Mon, May 01, 2017 at 11:36:59AM -0700, Dhinakaran Pandiyan wrote:
> From: "Pandiyan, Dhinakaran" 
> 
> Use the added helpers to track MST link bandwidth for atomic modesets.
> Link bw is acquired in the ->atomic_check() phase when CRTCs are being
> enabled with drm_atomic_find_vcpi_slots(). Similarly, link bw is released
> during ->atomic_check() with the connector helper callback ->atomic_check()
> when CRTCs are disabled.
> 
> v6: active_changed does not alter vcpi allocations (Maarten)
> v5: Implement connector->atomic_check() in place of atomic_release()
> v4: Return an int from intel_dp_mst_atomic_release() (Maarten)
> v3:
>  Handled the case where ->atomic_release() is called more than once
>  during an atomic_check() for the same state.
> v2:
>  Squashed atomic_release() implementation and caller (Daniel)
>  Fixed logic for connector-crtc switching case (Daniel)
>  Fixed logic for suspend-resume case.
> 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Archit Taneja 
> Cc: Chris Wilson 
> Cc: Harry Wentland 
> 
> Acked-by: Harry Wentland 
> Reviewed-by: Maarten Lankhorst 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 48 
> -
>  1 file changed, 42 insertions(+), 6 deletions(-)

This only touches i915 code, the prefix for the patch title should be
drm/i915 or drm/i915/dp, not drm/dp. drm/dp is only for core dp code
shared among drivers.
-Daniel

> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 5af22a7..68c788e 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -39,7 +39,7 @@ static bool intel_dp_mst_compute_config(struct 
> intel_encoder *encoder,
>   struct intel_dp *intel_dp = &intel_dig_port->dp;
>   struct intel_connector *connector =
>   to_intel_connector(conn_state->connector);
> - struct drm_atomic_state *state;
> + struct drm_atomic_state *state = pipe_config->base.state;
>   int bpp;
>   int lane_count, slots;
>   const struct drm_display_mode *adjusted_mode = 
> &pipe_config->base.adjusted_mode;
> @@ -57,20 +57,24 @@ static bool intel_dp_mst_compute_config(struct 
> intel_encoder *encoder,
>* seem to suggest we should do otherwise.
>*/
>   lane_count = intel_dp_max_lane_count(intel_dp);
> -
>   pipe_config->lane_count = lane_count;
>  
>   pipe_config->pipe_bpp = bpp;
> - pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
>  
> - state = pipe_config->base.state;
> + pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
>  
>   if (drm_dp_mst_port_has_audio(&intel_dp->mst_mgr, connector->port))
>   pipe_config->has_audio = true;
> - mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
>  
> + mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
>   pipe_config->pbn = mst_pbn;
> - slots = drm_dp_find_vcpi_slots(&intel_dp->mst_mgr, mst_pbn);
> +
> + slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
> +   connector->port, mst_pbn);
> + if (slots < 0) {
> + DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
> + return false;
> + }
>  
>   intel_link_compute_m_n(bpp, lane_count,
>  adjusted_mode->crtc_clock,
> @@ -80,7 +84,38 @@ static bool intel_dp_mst_compute_config(struct 
> intel_encoder *encoder,
>   pipe_config->dp_m_n.tu = slots;
>  
>   return true;
> +}
>  
> +static int intel_dp_mst_atomic_check(struct drm_connector *connector,
> + struct drm_connector_state *new_conn_state)
> +{
> + struct drm_atomic_state *state = new_conn_state->state;
> + struct drm_connector_state *old_conn_state;
> + struct drm_crtc *old_crtc;
> + struct drm_crtc_state *crtc_state;
> + int slots, ret = 0;
> +
> + old_conn_state = drm_atomic_get_old_connector_state(state, connector);
> + old_crtc = old_conn_state->crtc;
> + if (!old_crtc)
> + return ret;
> +
> + crtc_state = drm_atomic_get_new_crtc_state(state, old_crtc);
> + slots = to_intel_crtc_state(crtc_state)->dp_m_n.tu;
> + if (drm_atomic_crtc_needs_modeset(crtc_state) && slots > 0) {
> + struct drm_dp_mst_topology_mgr *mgr;
> + struct drm_encoder *old_encoder;
> +
> + old_encoder = old_conn_state->best_encoder;
> + mgr = &enc_to_mst(old_encoder)->primary->dp.mst_mgr;
> +
> + ret = drm_dp_atomic_release_vcpi_slots(state, mgr, slots);
> + if (ret)
> + DRM_DEBUG_KMS("failed releasing %d vcpi slots:%d\n", 
> slots, ret);
> + else
> + to_intel_crtc_state(crtc_state)->dp_m_n.tu = 0;
> + }
> + return ret;
>  }
>  
>  static void intel_mst_disable_dp(struct intel_encoder *encoder,
> @@ -378,6 +413,7 @@ static

Re: [PATCH] gpu: ipu-v3: pre: only use internal clock gating

[Philipp Zabel]

On Tue, 2017-05-02 at 17:38 +0200, Lucas Stach wrote:
> By setting the SFTRST bit, the PRE will be held in the lowest power state
> with clocks to the internal blocks gated. When external clock gating is
> used (from the external clock controller, or by setting the CLKGATE bit)
> the PRE will sporadically fail to start.
> 
> Signed-off-by: Lucas Stach 
> ---
> This is a fix for newly introduced functionality and should be applied
> for 4.12 fixes.
> ---
>  drivers/gpu/ipu-v3/ipu-pre.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c
> index c55563379e2e..e2f6acf42792 100644
> --- a/drivers/gpu/ipu-v3/ipu-pre.c
> +++ b/drivers/gpu/ipu-v3/ipu-pre.c
> @@ -131,8 +131,6 @@ int ipu_pre_get(struct ipu_pre *pre)
>   if (pre->in_use)
>   return -EBUSY;
>  
> - clk_prepare_enable(pre->clk_axi);
> -
>   /* first get the engine out of reset and remove clock gating */
>   writel(0, pre->regs + IPU_PRE_CTRL);
>  
> @@ -149,12 +147,7 @@ int ipu_pre_get(struct ipu_pre *pre)
>  
>  void ipu_pre_put(struct ipu_pre *pre)
>  {
> - u32 val;
> -
> - val = IPU_PRE_CTRL_SFTRST | IPU_PRE_CTRL_CLKGATE;
> - writel(val, pre->regs + IPU_PRE_CTRL);
> -
> - clk_disable_unprepare(pre->clk_axi);
> + writel(IPU_PRE_CTRL_SFTRST, pre->regs + IPU_PRE_CTRL);
>  
>   pre->in_use = false;
>  }
> @@ -249,6 +242,8 @@ static int ipu_pre_probe(struct platform_device *pdev)
>   if (!pre->buffer_virt)
>   return -ENOMEM;
>  
> + clk_prepare_enable(pre->clk_axi);
> +
>   pre->dev = dev;
>   platform_set_drvdata(pdev, pre);
>   mutex_lock(&ipu_pre_list_mutex);

Why is there no matching clk_disable_unprepare in ipu_pre_remove?

regards
Philipp

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

[PATCH v2] gpu: ipu-v3: pre: only use internal clock gating

[Lucas Stach]

By setting the SFTRST bit, the PRE will be held in the lowest power state
with clocks to the internal blocks gated. When external clock gating is
used (from the external clock controller, or by setting the CLKGATE bit)
the PRE will sporadically fail to start.

Signed-off-by: Lucas Stach 
---
v2: add missing clk_disable_unprepare in remove path

This is a fix for newly introduced functionality and should be applied
for 4.12 fixes.
---
 drivers/gpu/ipu-v3/ipu-pre.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c
index c55563379e2e..c35f74c83065 100644
--- a/drivers/gpu/ipu-v3/ipu-pre.c
+++ b/drivers/gpu/ipu-v3/ipu-pre.c
@@ -131,8 +131,6 @@ int ipu_pre_get(struct ipu_pre *pre)
if (pre->in_use)
return -EBUSY;
 
-   clk_prepare_enable(pre->clk_axi);
-
/* first get the engine out of reset and remove clock gating */
writel(0, pre->regs + IPU_PRE_CTRL);
 
@@ -149,12 +147,7 @@ int ipu_pre_get(struct ipu_pre *pre)
 
 void ipu_pre_put(struct ipu_pre *pre)
 {
-   u32 val;
-
-   val = IPU_PRE_CTRL_SFTRST | IPU_PRE_CTRL_CLKGATE;
-   writel(val, pre->regs + IPU_PRE_CTRL);
-
-   clk_disable_unprepare(pre->clk_axi);
+   writel(IPU_PRE_CTRL_SFTRST, pre->regs + IPU_PRE_CTRL);
 
pre->in_use = false;
 }
@@ -249,6 +242,8 @@ static int ipu_pre_probe(struct platform_device *pdev)
if (!pre->buffer_virt)
return -ENOMEM;
 
+   clk_prepare_enable(pre->clk_axi);
+
pre->dev = dev;
platform_set_drvdata(pdev, pre);
mutex_lock(&ipu_pre_list_mutex);
@@ -268,6 +263,8 @@ static int ipu_pre_remove(struct platform_device *pdev)
available_pres--;
mutex_unlock(&ipu_pre_list_mutex);
 
+   clk_disable_unprepare(pre->clk_axi);
+
if (pre->buffer_virt)
gen_pool_free(pre->iram, (unsigned long)pre->buffer_virt,
  IPU_PRE_MAX_WIDTH * IPU_PRE_NUM_SCANLINES * 4);
-- 
2.11.0

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

Re: [linux-sunxi] [PATCH 13/15] drm/sun4i: Add HDMI support

[Maxime Ripard]

On Wed, Apr 26, 2017 at 03:59:28PM +0800, Chen-Yu Tsai wrote:
> >> > +   writel(SUN4I_HDMI_VID_TIMING_X(mode->hdisplay) |
> >> > +  SUN4I_HDMI_VID_TIMING_Y(mode->vdisplay),
> >> > +  hdmi->base + SUN4I_HDMI_VID_TIMING_ACT_REG);
> >> > +
> >> > +   x = mode->htotal - mode->hsync_start;
> >> > +   y = mode->vtotal - mode->vsync_start;
> >>
> >> I'm a bit skeptical about this one. All the other parameters are not
> >> inclusive of other, why would this one be different? Shouldn't it
> >> be "Xtotal - Xsync_end" instead?
> >
> > By the usual meaning of backporch, you're right. However, Allwinner's
> > seems to have it's own, which is actually the backporch + sync length.
> >
> > We also have that on all the other connectors (and TCON), and this was
> > confirmed at the time using a scope on an RGB signal.
> 
> Yes. On the later SoCs such as the A31, the user manual actually has
> timing diagrams showing this.
> 
> Unlike the TCON, the HDMI controller's timings lists the front porch
> separately, instead of an all inclusive Xtotal. This is what made me
> look twice. This should be easy to confirm though. Since the HDMI modes
> are well known and can be exactly reproduced on our hardware, we can
> just check for any distortions or refresh rate errors.

This isn't as trivial as that. Screens usually have some tolerancies
on the timings, which will probably make it go unnoticed, even though
they are wrong.

> >>
> >> > +   writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> >> > +  hdmi->base + SUN4I_HDMI_VID_TIMING_BP_REG);
> >> > +
> >> > +   x = mode->hsync_start - mode->hdisplay;
> >> > +   y = mode->vsync_start - mode->vdisplay;
> >> > +   writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> >> > +  hdmi->base + SUN4I_HDMI_VID_TIMING_FP_REG);
> >> > +
> >> > +   x = mode->hsync_end - mode->hsync_start;
> >> > +   y = mode->vsync_end - mode->vsync_start;
> >> > +   writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> >> > +  hdmi->base + SUN4I_HDMI_VID_TIMING_SPW_REG);
> >> > +
> >> > +   val = SUN4I_HDMI_VID_TIMING_POL_TX_CLK;
> >> > +   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> >> > +   val |= SUN4I_HDMI_VID_TIMING_POL_HSYNC;
> >> > +
> >> > +   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> >> > +   val |= SUN4I_HDMI_VID_TIMING_POL_VSYNC;
> >> > +
> >> > +   writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
> >>
> >> You don't handle the interlaced video here, even though you set
> >>
> >> hdmi->connector.interlace_allowed = true
> >>
> >> later.
> >
> > I'll fix that.
> >
> >> The double clock and double scan flags aren't handled either, though
> >> I don't understand which one is supposed to represent the need for the
> >> HDMI pixel repeater. AFAIK this is required for resolutions with pixel
> >> clocks lower than 25 MHz, the lower limit of HDMI's TMDS link.
> >
> > I'm not sure about this one though. I'd like to keep things quite
> > simple for now and build up on that once the basis is working. Is it
> > common in the wild?
> 
> If you drive the display at SDTV resolutions, then yes. Mode lines from
> my HDMI monitor:
> 
>   720x576i 50 720 732 795 864 576 580 586 625 flags: nhsync, nvsync,
> interlace, dblclk; type: driver
>   720x480i 60 720 739 801 858 480 488 494 525 flags: nhsync, nvsync,
> interlace, dblclk; type: driver
>   720x480i 60 720 739 801 858 480 488 494 525 flags: nhsync, nvsync,
> interlace, dblclk; type: driver
> 
> AFAIK these are standard modes that all devices should support. Whether
> they are used daily is another thing. Maybe block modes with dblclk
> in .mode_fixup for now?

That would rather be atomic_check and / or mode_valid, but yeah, I can
do that.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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] gpu: ipu-v3: pre: only use internal clock gating

[Philipp Zabel]

On Wed, 2017-05-03 at 10:38 +0200, Lucas Stach wrote:
> By setting the SFTRST bit, the PRE will be held in the lowest power state
> with clocks to the internal blocks gated. When external clock gating is
> used (from the external clock controller, or by setting the CLKGATE bit)
> the PRE will sporadically fail to start.
> 
> Signed-off-by: Lucas Stach 
> ---
> v2: add missing clk_disable_unprepare in remove path
> 
> This is a fix for newly introduced functionality and should be applied
> for 4.12 fixes.
> ---
>  drivers/gpu/ipu-v3/ipu-pre.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c
> index c55563379e2e..c35f74c83065 100644
> --- a/drivers/gpu/ipu-v3/ipu-pre.c
> +++ b/drivers/gpu/ipu-v3/ipu-pre.c
> @@ -131,8 +131,6 @@ int ipu_pre_get(struct ipu_pre *pre)
>   if (pre->in_use)
>   return -EBUSY;
>  
> - clk_prepare_enable(pre->clk_axi);
> -
>   /* first get the engine out of reset and remove clock gating */
>   writel(0, pre->regs + IPU_PRE_CTRL);
>  
> @@ -149,12 +147,7 @@ int ipu_pre_get(struct ipu_pre *pre)
>  
>  void ipu_pre_put(struct ipu_pre *pre)
>  {
> - u32 val;
> -
> - val = IPU_PRE_CTRL_SFTRST | IPU_PRE_CTRL_CLKGATE;
> - writel(val, pre->regs + IPU_PRE_CTRL);
> -
> - clk_disable_unprepare(pre->clk_axi);
> + writel(IPU_PRE_CTRL_SFTRST, pre->regs + IPU_PRE_CTRL);
>  
>   pre->in_use = false;
>  }
> @@ -249,6 +242,8 @@ static int ipu_pre_probe(struct platform_device *pdev)
>   if (!pre->buffer_virt)
>   return -ENOMEM;
>  
> + clk_prepare_enable(pre->clk_axi);
> +
>   pre->dev = dev;
>   platform_set_drvdata(pdev, pre);
>   mutex_lock(&ipu_pre_list_mutex);
> @@ -268,6 +263,8 @@ static int ipu_pre_remove(struct platform_device *pdev)
>   available_pres--;
>   mutex_unlock(&ipu_pre_list_mutex);
>  
> + clk_disable_unprepare(pre->clk_axi);
> +

Thank you. I've applied this patch to imx-drm/fixes.

regards
Philipp

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

Re: [GIT PULL v2] drm/mali-dp changes for v4.12 (or drm-next)

[Liviu Dudau]

On Sat, Apr 29, 2017 at 05:48:14AM +1000, Dave Airlie wrote:
> On 27 April 2017 at 03:01, Liviu Dudau  wrote:
> > Hi Dave,
> >
> > Updated pull request to fix the all-modconfig build on 32bit arm
> > builds.
> >
> > This pull request includes the latest updates on Mali DP, adding
> > support for colour management, plane scaling and power management.
> > The patches have trickled into the mailing list since February, and
> > have baked on linux-next for a few weeks (strangely, the 64bit div
> > was only caught yesterday).

(mail got filed under a different folder because I was not in To: or Cc:)

> 
> I'd have preferred if we could have gotten this before -rc6, though since
> it was all queued in -next already I should be okay to still pull it
> with the fix.

Yes, sorry about that. Initially I wanted to send it before Easter but you
went on holiday before I had a chance to send the email and on your coming
back I left for mine, and I didn't want to fire and forget the pull request.

Will try to be more proactive in the future.

Best regards,
Liviu

> 
> Dave.
> 
> >
> > Please pull.
> >
> > Many thanks,
> > Liviu
> >
> > The following changes since commit 6b1462700b4a6a1244c018cdd2fa97ded43090a0:
> >
> >   Merge tag 'drm-misc-next-fixes-2017-04-20' of 
> > git://anongit.freedesktop.org/git/drm-misc into drm-next (2017-04-21 
> > 13:51:59 +1000)
> >
> > are available in the git repository at:
> >
> >   git://linux-arm.org/linux-ld.git for-upstream/mali-dp
> >
> > for you to fetch changes up to 763656d30b3d220a52e4b2bd1fc174a4cd6c0f43:
> >
> >   drm: mali-dp: use div_u64 for expensive 64-bit divisions (2017-04-26 
> > 17:54:58 +0100)
> >
> > 
> > Arnd Bergmann (2):
> >   drm: mali-dp: remove unused variable
> >   drm: mali-dp: use div_u64 for expensive 64-bit divisions
> >
> > Liviu Dudau (3):
> >   drm: mali-dp: Update the state of all planes before re-enabling 
> > active CRTCs.
> >   drm: mali-dp: Enable power management for the device.
> >   drm/mali-dp: Add core_id file to the sysfs interface
> >
> > Mihail Atanassov (8):
> >   drm: mali-dp: add atomic_print_state for planes
> >   drm: mali-dp: add custom reset hook for planes
> >   drm: mali-dp: add malidp_crtc_state struct
> >   drm: mali-dp: enable gamma support
> >   drm: mali-dp: Add CTM support
> >   drm: mali-dp: Add plane upscaling support
> >   drm: mali-dp: Enable image enhancement when scaling
> >   drm: mali-dp: Check the mclk rate and allow up/down scaling
> >
> >  drivers/gpu/drm/arm/malidp_crtc.c   | 341 
> > ++--
> >  drivers/gpu/drm/arm/malidp_drv.c| 307 +---
> >  drivers/gpu/drm/arm/malidp_drv.h|  13 ++
> >  drivers/gpu/drm/arm/malidp_hw.c | 213 ++
> >  drivers/gpu/drm/arm/malidp_hw.h |  81 +
> >  drivers/gpu/drm/arm/malidp_planes.c | 108 ++--
> >  drivers/gpu/drm/arm/malidp_regs.h   |  72 +++-
> >  7 files changed, 1073 insertions(+), 62 deletions(-)

-- 

| 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 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Archit Taneja]

Hi,

On 04/27/2017 10:06 PM, Eric Anholt wrote:

Many DRM drivers have common code to make a stub connector
implementation that wraps a drm_panel.  By wrapping the panel in a DRM
bridge, all of the connector code (including calls during encoder
enable/disable) goes away.

Signed-off-by: Eric Anholt 
---
 Documentation/gpu/drm-kms-helpers.rst |   3 +
 drivers/gpu/drm/bridge/Kconfig|  11 +-
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/lvds-encoder.c | 158 
 drivers/gpu/drm/bridge/panel.c| 188 ++
 include/drm/drm_bridge.h  |   8 ++
 6 files changed, 228 insertions(+), 141 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/panel.c

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index c075aadd7078..60eb3b41702b 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -143,6 +143,9 @@ Bridge Helper Reference
 .. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:export:

+.. kernel-doc:: drivers/gpu/drm/bridge/panel.c
+   :export:
+
 .. _drm_panel_helper:

 Panel Helper Reference
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index f6968d3b4b41..c4daca38743c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -4,6 +4,14 @@ config DRM_BRIDGE
help
  Bridge registration and lookup framework.

+config DRM_PANEL_BRIDGE
+   def_bool y
+   depends on DRM_BRIDGE
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   help
+ DRM bridge wrapper of DRM panels
+
 menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE

@@ -27,8 +35,7 @@ config DRM_DUMB_VGA_DAC
 config DRM_LVDS_ENCODER
tristate "Transparent parallel to LVDS encoder support"
depends on OF
-   select DRM_KMS_HELPER
-   select DRM_PANEL
+   select DRM_PANEL_BRIDGE
help
  Support for transparent parallel to LVDS encoders that don't require
  any configuration.
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 3fe2226ee2f2..40a43750ad55 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
+obj-$(CONFIG_DRM_PANEL_BRIDGE) += panel.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
b/drivers/gpu/drm/bridge/lvds-encoder.c
index f1f67a279426..04e1504c4d8f 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -8,144 +8,18 @@
  */

 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
 #include 

 #include 

-struct lvds_encoder {
-   struct device *dev;
-
-   struct drm_bridge bridge;
-   struct drm_connector connector;
-   struct drm_panel *panel;
-};
-
-static inline struct lvds_encoder *
-drm_bridge_to_lvds_encoder(struct drm_bridge *bridge)
-{
-   return container_of(bridge, struct lvds_encoder, bridge);
-}
-
-static inline struct lvds_encoder *
-drm_connector_to_lvds_encoder(struct drm_connector *connector)
-{
-   return container_of(connector, struct lvds_encoder, connector);
-}
-
-static int lvds_connector_get_modes(struct drm_connector *connector)
-{
-   struct lvds_encoder *lvds = drm_connector_to_lvds_encoder(connector);
-
-   return drm_panel_get_modes(lvds->panel);
-}
-
-static const struct drm_connector_helper_funcs lvds_connector_helper_funcs = {
-   .get_modes = lvds_connector_get_modes,
-};
-
-static const struct drm_connector_funcs lvds_connector_funcs = {
-   .dpms = drm_atomic_helper_connector_dpms,
-   .reset = drm_atomic_helper_connector_reset,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .destroy = drm_connector_cleanup,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-static int lvds_encoder_attach(struct drm_bridge *bridge)
-{
-   struct lvds_encoder *lvds = drm_bridge_to_lvds_encoder(bridge);
-   struct drm_connector *connector = &lvds->connector;
-   int ret;
-
-   if (!bridge->encoder) {
-   DRM_ERROR("Missing encoder\n");
-   return -ENODEV;
-   }
-
-   drm_connector_helper_add(connector, &lvds_connector_helper_funcs);
-
-   ret = drm_connector_init(bridge->dev, connector, &lvds_connector_funcs,
-DRM_MODE_CONNECTOR_LVDS);
-   if (ret) {
-   DRM_ERROR("Failed to initialize connector\n");

Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN

[Gerd Hoffmann]

  Hi,

> > R600+ supports bigendian framebuffer formats, so no byteswapping on
> > access is needed.  Not sure whenever that includes 16bpp formats or
> > whenever this is limited to the 8 bit-per-color formats [...]
> 
> It includes 16bpp. Looking at
> drivers/gpu/drm/radeon/atombios_crtc.c:dce4_crtc_do_set_base(), it sets
> up byte-swapping for all multi-byte formats, so it effectively treats
> all those formats as if they had DRM_FORMAT_BIG_ENDIAN set.

> If the radeon (and amdgpu) driver were to be changed to use
> drm_mode_legacy_fb_format_he for >= R600, that must also handle 16 bpp,
> which requires DRM_FORMAT_BIG_ENDIAN. So I still don't see how that can
> be removed or even deprecated.

Ok.

Dropped patch #1.

Updated patch #2 to include all formats returned by
drm_mode_legacy_fb_format, and also renamed them to DRM_FORMAT_HOST_*.

Question is how to go forward with patch #3.  I'd prefer to not add
drm_mode_legacy_fb_format_he if possible.  Is there a chance to adapt
the radeon and nvidia drivers to a fixed drm_mode_legacy_fb_format
function (returning be formats on be) without invasive changes?  Given
they both treat formats as if they had DRM_FORMAT_BIG_ENDIAN set this
could (with the help of the extended patch #2) be a simple
s/DRM_FORMAT_/DRM_FORMAT_HOST/ at the right places ...

Michael?  Ilia?

cheers,
  Gerd

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

Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Laurent Pinchart]

Hi Archit,

On Wednesday 03 May 2017 14:53:00 Archit Taneja wrote:
> On 04/27/2017 10:06 PM, Eric Anholt wrote:
> > Many DRM drivers have common code to make a stub connector
> > implementation that wraps a drm_panel.  By wrapping the panel in a DRM
> > bridge, all of the connector code (including calls during encoder
> > enable/disable) goes away.
> > 
> > Signed-off-by: Eric Anholt 
> > ---
> > 
> >  Documentation/gpu/drm-kms-helpers.rst |   3 +
> >  drivers/gpu/drm/bridge/Kconfig|  11 +-
> >  drivers/gpu/drm/bridge/Makefile   |   1 +
> >  drivers/gpu/drm/bridge/lvds-encoder.c | 158 
> >  drivers/gpu/drm/bridge/panel.c| 188 +
> >  include/drm/drm_bridge.h  |   8 ++
> >  6 files changed, 228 insertions(+), 141 deletions(-)
> >  create mode 100644 drivers/gpu/drm/bridge/panel.c
> > 
> > diff --git a/Documentation/gpu/drm-kms-helpers.rst
> > b/Documentation/gpu/drm-kms-helpers.rst index c075aadd7078..60eb3b41702b
> > 100644
> > --- a/Documentation/gpu/drm-kms-helpers.rst
> > +++ b/Documentation/gpu/drm-kms-helpers.rst
> > @@ -143,6 +143,9 @@ Bridge Helper Reference
> >  .. kernel-doc:: drivers/gpu/drm/drm_bridge.c
> > :export:
> > 
> > +.. kernel-doc:: drivers/gpu/drm/bridge/panel.c
> > +   :export:
> > +
> >  .. _drm_panel_helper:
> >  Panel Helper Reference
> > 
> > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > b/drivers/gpu/drm/bridge/Kconfig index f6968d3b4b41..c4daca38743c 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -4,6 +4,14 @@ config DRM_BRIDGE
> > help
> >   Bridge registration and lookup framework.
> > 
> > +config DRM_PANEL_BRIDGE
> > +   def_bool y
> > +   depends on DRM_BRIDGE
> > +   select DRM_KMS_HELPER
> > +   select DRM_PANEL
> > +   help
> > + DRM bridge wrapper of DRM panels
> > +
> >  menu "Display Interface Bridges"
> > depends on DRM && DRM_BRIDGE
> > 
> > @@ -27,8 +35,7 @@ config DRM_DUMB_VGA_DAC
> >  config DRM_LVDS_ENCODER
> > tristate "Transparent parallel to LVDS encoder support"
> > depends on OF
> > -   select DRM_KMS_HELPER
> > -   select DRM_PANEL
> > +   select DRM_PANEL_BRIDGE
> > help
> >   Support for transparent parallel to LVDS encoders that don't require
> >   any configuration.
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile index 3fe2226ee2f2..40a43750ad55 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> >  obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> >  obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> >  megachips-stdp-ge-b850v3-fw.o obj-$(CONFIG_DRM_NXP_PTN3460) +=
> >  nxp-ptn3460.o
> > +obj-$(CONFIG_DRM_PANEL_BRIDGE) += panel.o
> >  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> >  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> >  obj-$(CONFIG_DRM_SII902X) += sii902x.o
> > diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
> > b/drivers/gpu/drm/bridge/lvds-encoder.c index f1f67a279426..04e1504c4d8f
> > 100644
> > --- a/drivers/gpu/drm/bridge/lvds-encoder.c
> > +++ b/drivers/gpu/drm/bridge/lvds-encoder.c
> > @@ -8,144 +8,18 @@
> >   */
> >  
> >  #include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> >  
> >  #include 
> > 
> > -struct lvds_encoder {
> > -   struct device *dev;
> > -
> > -   struct drm_bridge bridge;
> > -   struct drm_connector connector;
> > -   struct drm_panel *panel;
> > -};
> > -
> > -static inline struct lvds_encoder *
> > -drm_bridge_to_lvds_encoder(struct drm_bridge *bridge)
> > -{
> > -   return container_of(bridge, struct lvds_encoder, bridge);
> > -}
> > -
> > -static inline struct lvds_encoder *
> > -drm_connector_to_lvds_encoder(struct drm_connector *connector)
> > -{
> > -   return container_of(connector, struct lvds_encoder, connector);
> > -}
> > -
> > -static int lvds_connector_get_modes(struct drm_connector *connector)
> > -{
> > -   struct lvds_encoder *lvds = drm_connector_to_lvds_encoder(connector);
> > -
> > -   return drm_panel_get_modes(lvds->panel);
> > -}
> > -
> > -static const struct drm_connector_helper_funcs
> > lvds_connector_helper_funcs = { -   .get_modes = lvds_connector_get_modes,
> > -};
> > -
> > -static const struct drm_connector_funcs lvds_connector_funcs = {
> > -   .dpms = drm_atomic_helper_connector_dpms,
> > -   .reset = drm_atomic_helper_connector_reset,
> > -   .fill_modes = drm_helper_probe_single_connector_modes,
> > -   .destroy = drm_connector_cleanup,
> > -   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> > -   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> > -};
> > -
> > -static int lvds_encoder_attach(struct drm_bridge *bridge)
> > -{
> > -   struct lvds_encoder *lvds = drm_bridge_to_lvds_encoder(bridge);
> > -   struct drm_connector *

Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Daniel Vetter]

On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
> +panel/bridge reviewers.
> 
> This does make things much cleaner, but it seems a bit strange to create
> a drm_bridge when there isn't really a HW bridge in the display chain (i.e,
> when the DSI encoder is directly connected to a DSI panel).
> 
> There are kms drivers that use drm_panel, but don't have simple stub 
> connectors
> that wrap around a drm_panel. They have more complicated connector ops, and
> may call drm_panel_prepare() and related functions a bit differently. We won't
> be able to use drm_panel_bridge for those drivers.
> 
> For msm, we check whether the DSI encoder is connected directly to a panel
> or an external bridge. If it's connected to an external bridge, we skip the
> creation of the stub connector, and rely on the external bridge driver to
> create the connector:
> 
> http://lxr.free-electrons.com/source/drivers/gpu/drm/msm/dsi/dsi.c#L227
> 
> The msm solution isn't very neat, but it avoids the need to create another
> bridge to glue things together.

Since I suggested this, yes I like it. And I think just unconditionally
creating the panel bridge is probably even simpler, after all bridges are
supposed to be chainable. I guess there's always going to be drivers where
we need special handling, but I'm kinda hoping that for most cases simply
plugging in a panel bridge is all that's need to glue drm_panel support
into a driver. The simple pipe helpers do support bridges, and part of the
goal there very much was to make it easy to glue in panel drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Laurent Pinchart]

Hi Daniel,

On Wednesday 03 May 2017 11:32:17 Daniel Vetter wrote:
> On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
> > +panel/bridge reviewers.
> > 
> > This does make things much cleaner, but it seems a bit strange to create
> > a drm_bridge when there isn't really a HW bridge in the display chain
> > (i.e, when the DSI encoder is directly connected to a DSI panel).
> > 
> > There are kms drivers that use drm_panel, but don't have simple stub
> > connectors that wrap around a drm_panel. They have more complicated
> > connector ops, and may call drm_panel_prepare() and related functions a
> > bit differently. We won't be able to use drm_panel_bridge for those
> > drivers.
> > 
> > For msm, we check whether the DSI encoder is connected directly to a panel
> > or an external bridge. If it's connected to an external bridge, we skip
> > the creation of the stub connector, and rely on the external bridge driver
> > to create the connector:
> > 
> > http://lxr.free-electrons.com/source/drivers/gpu/drm/msm/dsi/dsi.c#L227
> > 
> > The msm solution isn't very neat, but it avoids the need to create another
> > bridge to glue things together.
> 
> Since I suggested this, yes I like it. And I think just unconditionally
> creating the panel bridge is probably even simpler, after all bridges are
> supposed to be chainable. I guess there's always going to be drivers where
> we need special handling, but I'm kinda hoping that for most cases simply
> plugging in a panel bridge is all that's need to glue drm_panel support
> into a driver. The simple pipe helpers do support bridges, and part of the
> goal there very much was to make it easy to glue in panel drivers.

As I've just explained in another reply, I don't see the point in doing this 
when we can instead refactor the bridge and panel operations to expose a 
common base object that will then be easy to handle in core code. This isn't 
just for panels, as connectors should have DT nodes, it makes sense to 
instantiate an object for them that can be handled by the DRM core, without 
having to push connector handling in all bridge drivers.

-- 
Regards,

Laurent Pinchart

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

[GIT PULL v2] drm/hdlcd: fix for calculation of scanout address

[Liviu Dudau]

(I can't see this email that I have sent on 24th of April in the
dri-devel archives, so I'm guessing it fell through the cracks of my
wonderful email infrastructure. Please let me know if you want me
to rebase the tree on top of a more recent tag)

Hi Dave,

I'm not sure what is the best tree to target this, probably v4.12-rc1 if it
is too late to make it into the pull request for this merge window. Just a
patch that has been in linux-next for a very long time due to lack of feedback
and me going on holiday for a while.

Many thanks,
Liviu

The following changes since commit c02ed2e75ef4c74e41e421acb4ef1494671585e8:

  Linux 4.11-rc4 (2017-03-26 14:15:16 -0700)

are available in the git repository at:

  git://linux-arm.org/linux-ld.git for-upstream/hdlcd

for you to fetch changes up to 1de3cd4fb49f3463679c49afe0aa9ceb133f3e49:

  drm: hdlcd: Fix the calculation of the scanout start address (2017-03-27 
14:55:58 +0100)


Liviu Dudau (1):
  drm: hdlcd: Fix the calculation of the scanout start address

 drivers/gpu/drm/arm/hdlcd_crtc.c | 47 ++--
 1 file changed, 31 insertions(+), 16 deletions(-)

-- 

| 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 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Daniel Vetter]

On Thu, Apr 27, 2017 at 09:36:00AM -0700, Eric Anholt wrote:
> Many DRM drivers have common code to make a stub connector
> implementation that wraps a drm_panel.  By wrapping the panel in a DRM
> bridge, all of the connector code (including calls during encoder
> enable/disable) goes away.
> 
> Signed-off-by: Eric Anholt 
> ---
>  Documentation/gpu/drm-kms-helpers.rst |   3 +
>  drivers/gpu/drm/bridge/Kconfig|  11 +-
>  drivers/gpu/drm/bridge/Makefile   |   1 +
>  drivers/gpu/drm/bridge/lvds-encoder.c | 158 
>  drivers/gpu/drm/bridge/panel.c| 188 
> ++
>  include/drm/drm_bridge.h  |   8 ++
>  6 files changed, 228 insertions(+), 141 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/panel.c
> 
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index c075aadd7078..60eb3b41702b 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -143,6 +143,9 @@ Bridge Helper Reference
>  .. kernel-doc:: drivers/gpu/drm/drm_bridge.c
> :export:
>  

I'd do a separate heading for this one (even if it's just two functions)
to make it stick a bit more out. "Panel Bridge helper" or similar. And
please add kerneldoc for the remove function (and maybe cross-reference
them for ocd consistency).

Besides this nits, I very much like this. And I think this addresses
Laurent's concern of hard-coding the DT for his lvds bridge too much.

Acked-by: Daniel Vetter 

Feel free to upgrade to an r-b with the kerneldoc polish applied (but pls
make sure you have acks from Laurent and Archit before pushing).
-Daniel

> +.. kernel-doc:: drivers/gpu/drm/bridge/panel.c
> +   :export:
> +
>  .. _drm_panel_helper:
>  
>  Panel Helper Reference
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index f6968d3b4b41..c4daca38743c 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -4,6 +4,14 @@ config DRM_BRIDGE
>   help
> Bridge registration and lookup framework.
>  
> +config DRM_PANEL_BRIDGE
> + def_bool y
> + depends on DRM_BRIDGE
> + select DRM_KMS_HELPER
> + select DRM_PANEL
> + help
> +   DRM bridge wrapper of DRM panels
> +
>  menu "Display Interface Bridges"
>   depends on DRM && DRM_BRIDGE
>  
> @@ -27,8 +35,7 @@ config DRM_DUMB_VGA_DAC
>  config DRM_LVDS_ENCODER
>   tristate "Transparent parallel to LVDS encoder support"
>   depends on OF
> - select DRM_KMS_HELPER
> - select DRM_PANEL
> + select DRM_PANEL_BRIDGE
>   help
> Support for transparent parallel to LVDS encoders that don't require
> any configuration.
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 3fe2226ee2f2..40a43750ad55 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
>  obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
>  obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
> megachips-stdp-ge-b850v3-fw.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> +obj-$(CONFIG_DRM_PANEL_BRIDGE) += panel.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
> diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
> b/drivers/gpu/drm/bridge/lvds-encoder.c
> index f1f67a279426..04e1504c4d8f 100644
> --- a/drivers/gpu/drm/bridge/lvds-encoder.c
> +++ b/drivers/gpu/drm/bridge/lvds-encoder.c
> @@ -8,144 +8,18 @@
>   */
>  
>  #include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> +#include 
>  #include 
>  
>  #include 
>  
> -struct lvds_encoder {
> - struct device *dev;
> -
> - struct drm_bridge bridge;
> - struct drm_connector connector;
> - struct drm_panel *panel;
> -};
> -
> -static inline struct lvds_encoder *
> -drm_bridge_to_lvds_encoder(struct drm_bridge *bridge)
> -{
> - return container_of(bridge, struct lvds_encoder, bridge);
> -}
> -
> -static inline struct lvds_encoder *
> -drm_connector_to_lvds_encoder(struct drm_connector *connector)
> -{
> - return container_of(connector, struct lvds_encoder, connector);
> -}
> -
> -static int lvds_connector_get_modes(struct drm_connector *connector)
> -{
> - struct lvds_encoder *lvds = drm_connector_to_lvds_encoder(connector);
> -
> - return drm_panel_get_modes(lvds->panel);
> -}
> -
> -static const struct drm_connector_helper_funcs lvds_connector_helper_funcs = 
> {
> - .get_modes = lvds_connector_get_modes,
> -};
> -
> -static const struct drm_connector_funcs lvds_connector_funcs = {
> - .dpms = drm_atomic_helper_connector_dpms,
> - .reset = drm_atomic_helper_connector_reset,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> - .destroy = drm_connector_cleanup,
> - .atomic

Re: [PATCH v2 4/5] drm/etnaviv: Reuse dma_fence_release.

[Lucas Stach]

Hi Eric,

Am Mittwoch, den 12.04.2017, 12:12 -0700 schrieb Eric Anholt:
> If we follow the typical pattern of the base class being the first
> member, we can use the default dma_fence_free function.

Sorry, I don't like this change.
While it provides a bit of code simplification, it also bakes the
implicit assumption into the code that dma_fence is the first struct
member without any checks to validate this assumption. I would at least
expect a build bug assert, but then the current bit of code to keep this
explicit and self-documenting is probably just as good.

Regards,
Lucas

> Signed-off-by: Eric Anholt 
> Cc: Lucas Stach 
> Cc: Russell King 
> Cc: Christian Gmeiner 
> Cc: etna...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index da48819ff2e6..0d26ca56e94b 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -998,8 +998,8 @@ static void hangcheck_disable(struct etnaviv_gpu *gpu)
>  
>  /* fence object management */
>  struct etnaviv_fence {
> - struct etnaviv_gpu *gpu;
>   struct dma_fence base;
> + struct etnaviv_gpu *gpu;
>  };
>  
>  static inline struct etnaviv_fence *to_etnaviv_fence(struct dma_fence *fence)
> @@ -1031,20 +1031,13 @@ static bool etnaviv_fence_signaled(struct dma_fence 
> *fence)
>   return fence_completed(f->gpu, f->base.seqno);
>  }
>  
> -static void etnaviv_fence_release(struct dma_fence *fence)
> -{
> - struct etnaviv_fence *f = to_etnaviv_fence(fence);
> -
> - kfree_rcu(f, base.rcu);
> -}
> -
>  static const struct dma_fence_ops etnaviv_fence_ops = {
>   .get_driver_name = etnaviv_fence_get_driver_name,
>   .get_timeline_name = etnaviv_fence_get_timeline_name,
>   .enable_signaling = etnaviv_fence_enable_signaling,
>   .signaled = etnaviv_fence_signaled,
>   .wait = dma_fence_default_wait,
> - .release = etnaviv_fence_release,
> + .release = dma_fence_free,
>  };
>  
>  static struct dma_fence *etnaviv_gpu_fence_alloc(struct etnaviv_gpu *gpu)


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

Re: [PATCH 1/3] drm: Plumb modifiers through plane init

[Liviu Dudau]

On Tue, May 02, 2017 at 10:14:26PM -0700, Ben Widawsky wrote:
> v2: A minor addition from Daniel
> 
> Cc: Daniel Stone 

You are *really* pushing your luck by not Cc-ing *any* of the maintainers of
the drivers you touch. You do want reviews, don't you?

> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/arc/arcpgu_crtc.c   |  1 +
>  drivers/gpu/drm/arm/hdlcd_crtc.c|  1 +
>  drivers/gpu/drm/arm/malidp_planes.c |  2 +-
>  drivers/gpu/drm/armada/armada_crtc.c|  1 +
>  drivers/gpu/drm/armada/armada_overlay.c |  1 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  4 +++-
>  drivers/gpu/drm/drm_modeset_helper.c|  1 +
>  drivers/gpu/drm/drm_plane.c | 32 
> -
>  drivers/gpu/drm/drm_simple_kms_helper.c |  3 +++
>  drivers/gpu/drm/exynos/exynos_drm_plane.c   |  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |  2 +-
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  1 +
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  2 +-
>  drivers/gpu/drm/i915/intel_display.c|  7 +-
>  drivers/gpu/drm/i915/intel_sprite.c |  4 ++--
>  drivers/gpu/drm/imx/ipuv3-plane.c   |  4 ++--
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c|  2 +-
>  drivers/gpu/drm/meson/meson_plane.c |  1 +
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c   |  2 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  4 ++--
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  2 +-
>  drivers/gpu/drm/nouveau/nv50_display.c  |  5 ++--
>  drivers/gpu/drm/omapdrm/omap_plane.c|  3 ++-
>  drivers/gpu/drm/qxl/qxl_display.c   |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c |  4 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  4 ++--
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 ++--
>  drivers/gpu/drm/sti/sti_cursor.c|  2 +-
>  drivers/gpu/drm/sti/sti_gdp.c   |  2 +-
>  drivers/gpu/drm/sti/sti_hqvdp.c |  2 +-
>  drivers/gpu/drm/sun4i/sun4i_layer.c |  2 +-
>  drivers/gpu/drm/tegra/dc.c  | 12 +-
>  drivers/gpu/drm/vc4/vc4_plane.c |  2 +-
>  drivers/gpu/drm/virtio/virtgpu_plane.c  |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |  4 ++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|  4 ++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|  4 ++--
>  drivers/gpu/drm/zte/zx_plane.c  |  2 +-
>  include/drm/drm_plane.h | 21 +++-
>  include/drm/drm_simple_kms_helper.h |  1 +
>  include/uapi/drm/drm_fourcc.h   | 11 +
>  41 files changed, 126 insertions(+), 46 deletions(-)

I wish there was a way to sort the non-driver-specific changes out of this 
patch and
put the at the beginning or at the end of the patchset. That way one does not 
have to
hunt through the file for the relevant changes in the API.

How about introducing a new function called drm_universal_plane_mod_init() that 
has
the new parameter, a second patch that moves the relevant/all drivers to the 
new function
and (if all drivers were converted) a third patch to rename 
drm_universal_plane_mod_init()
back to drm_universal_plane_init()? I know it is more churn, but I'm struggling 
to figure
out why all the drivers have to pass a NULL here. Either they care about 
modifiers or
they don't, in which case a separate function would make things more obvious.

Finally, the questions I should've started with: why the change? What are you 
trying to
achieve? It is not very clear from the commit message at all.

> 
> diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
> b/drivers/gpu/drm/arc/arcpgu_crtc.c
> index ad9a95916f1f..cd8a24c7c67d 100644
> --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> @@ -218,6 +218,7 @@ static struct drm_plane *arc_pgu_plane_init(struct 
> drm_device *drm)
>  
>   ret = drm_universal_plane_init(drm, plane, 0xff, &arc_pgu_plane_funcs,
>  formats, ARRAY_SIZE(formats),
> +NULL,
>  DRM_PLANE_TYPE_PRIMARY, NULL);
>   if (ret)
>   return ERR_PTR(ret);
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 798a3cc480a2..0caa03ae8708 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -303,6 +303,7 @@ static struct drm_plane *hdlcd_plane_init(struct 
> drm_device *drm)
>  
>   ret = drm_universal_plane_init(drm, plane, 0xff, &hdlcd_plane_funcs,
>  formats, ARRAY_SIZE(formats),
> +NULL,
>  DRM_PLANE_TYPE_PRIMARY, NULL);
>   if (ret) {
>   devm_kfree(drm-

Re: [PATCH 2/3] drm: Create a format/modifier blob

[Brian Starkey]

Hi,

Having just caught up on IRC I'm sure I'm far too late for this party,
but...

Wouldn't this whole thing be a whole lot simpler if "IN_FORMATS"
stored "pointers" to separate blobs for the format and modifier lists?

struct drm_format_modifier_blob {
#define FORMAT_BLOB_CURRENT 1
/* Version of this blob format */
u32 version;

/* Flags */
u32 flags;

/* ID of a blob storing an array of FourCCs */
u32 formats_blob_id;

/* ID of a blob storing an array of drm_format_modifiers */
u32 modifiers_blob_id;
} __packed;

I've used/written a few interfaces with offsets to
variable-length-arrays and IMO the code to handle them is always
hideous.

Added bonus: With smart enough helper code the FourCC and modifiers
blobs can be shared across planes.

-Brian

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:

Updated blob layout (Rob, Daniel, Kristian, xerpi)

Cc: Rob Clark 
Cc: Daniel Stone 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
drivers/gpu/drm/drm_mode_config.c |   7 +++
drivers/gpu/drm/drm_plane.c   | 119 ++
include/drm/drm_mode_config.h |   6 ++
include/uapi/drm/drm_mode.h   |  26 +
4 files changed, 158 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..6bfbc3839df5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;

+   prop = drm_property_create(dev,
+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "IN_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.modifiers = prop;
+
return 0;
}

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 286e183891e5..2e89e0e73435 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
return num;
}

+struct drm_format_modifier_blob {
+#define FORMAT_BLOB_CURRENT 1
+   /* Version of this blob format */
+   u32 version;
+
+   /* Flags */
+   u32 flags;
+
+   /* Number of fourcc formats supported */
+   u32 count_formats;
+
+   /* Where in this blob the formats exist (in bytes) */
+   u32 formats_offset;
+
+   /* Number of drm_format_modifiers */
+   u32 count_modifiers;
+
+   /* Where in this blob the modifiers exist (in bytes) */
+   u32 modifiers_offset;
+
+   /* u32 formats[] */
+   /* struct drm_format_modifier modifiers[] */
+} __packed;
+
+static inline u32 *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (u32 *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (struct drm_format_modifier *)(((char *)blob) + 
blob->modifiers_offset);
+}
+
+static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
*plane,
+const struct drm_plane_funcs *funcs,
+const uint32_t *formats, unsigned int 
format_count,
+const uint64_t *format_modifiers)
+{
+   const struct drm_mode_config *config = &dev->mode_config;
+   const uint64_t *temp_modifiers = format_modifiers;
+   unsigned int format_modifier_count = 0;
+   struct drm_property_blob *blob = NULL;
+   struct drm_format_modifier *mod;
+   size_t blob_size = 0, formats_size, modifiers_size;
+   struct drm_format_modifier_blob *blob_data;
+   int i, j, ret = 0;
+
+   if (format_modifiers)
+   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
+   format_modifier_count++;
+
+   formats_size = sizeof(__u32) * format_count;
+   if (WARN_ON(!formats_size)) {
+   /* 0 formats are never expected */
+   return 0;
+   }
+
+   modifiers_size =
+   sizeof(struct drm_format_modifier) * format_modifier_count;
+
+   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
+   blob_size += ALIGN(formats_size, 8);
+   blob_size += modifiers_size;
+
+   blob = drm_property_create_blob(dev, blob_size, NULL);
+   if (IS_ERR(blob))
+   return -1;
+
+   blob_data = (struct drm_format_modifier_blob *)blob->data;
+   blob_data->version = FORMAT_BLOB_CURRENT;
+   blob_data->count_formats = format_count;
+   blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
+   blob_data->count_modifiers = format_modifier_count;
+
+   /* Modifiers offset is a pointer to a struct with a 64 bit field so it
+   

Re: [PATCH 2/3] drm: Create a format/modifier blob

[Daniel Stone]

Hi Brian,

On 3 May 2017 at 12:00, Brian Starkey  wrote:
> Having just caught up on IRC I'm sure I'm far too late for this party,
> but...
>
> Wouldn't this whole thing be a whole lot simpler if "IN_FORMATS"
> stored "pointers" to separate blobs for the format and modifier lists?
>
> I've used/written a few interfaces with offsets to
> variable-length-arrays and IMO the code to handle them is always
> hideous.

I don't agree ...

The idea is that the header can grow because the offsets allow it to;
adding a new member slots in between the end of static data and the
start of variable data, and since all the variable data is accessed by
an array, userspace doesn't have to be aware of the new members. The
code for that is very clean (modulo the casts for pointer maths), cf.
formats_ptr and modifiers_ptr; I'd expect userspace to copy and use
those with version guards:
uint32_t *formats = formats_ptr(blob);
struct drm_format_modifier *modifiers = modifiers_ptr(blob);
struct drm_format_unifier *unifiiers = (blob->version >= 2) ?
unifiers_ptr(blob) : NULL;

That's shorter than fetching separate blobs, and doesn't have multiple
error paths either. What am I missing?

> Added bonus: With smart enough helper code the FourCC and modifiers
> blobs can be shared across planes.

I think this is a serious case of premature optimisation; the memory
savings might be outweighed by the additional number of objects to
track, and userspace would have to jump through serious hoops with a
blob ID cache - something which is a very bad idea regardless - to
take any advantage of it.

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

[PATCH v2 3/20] clk: sunxi-ng: div: Switch to divider_round_rate

[Maxime Ripard]

divider_round_rate already evaluates changing the parent rate if
CLK_SET_RATE_PARENT is set. Now that we can do that on muxes too, let's
just use it.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_div.c | 27 ---
 1 file changed, 4 insertions(+), 23 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
index a489f18a3c01..419463375bc1 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -20,18 +20,11 @@ static unsigned long ccu_div_round_rate(struct 
ccu_mux_internal *mux,
void *data)
 {
struct ccu_div *cd = data;
-   unsigned long val;
-
-   /*
-* We can't use divider_round_rate that assumes that there's
-* several parents, while we might be called to evaluate
-* several different parents.
-*/
-   val = divider_get_val(rate, *parent_rate, cd->div.table, cd->div.width,
- cd->div.flags);
 
-   return divider_recalc_rate(&cd->common.hw, *parent_rate, val,
-  cd->div.table, cd->div.flags);
+   return divider_round_rate_parent(&cd->common.hw, parent,
+rate, parent_rate,
+cd->div.table, cd->div.width,
+cd->div.flags);
 }
 
 static void ccu_div_disable(struct clk_hw *hw)
@@ -78,18 +71,6 @@ static int ccu_div_determine_rate(struct clk_hw *hw,
 {
struct ccu_div *cd = hw_to_ccu_div(hw);
 
-   if (clk_hw_get_num_parents(hw) == 1) {
-   req->rate = divider_round_rate(hw, req->rate,
-  &req->best_parent_rate,
-  cd->div.table,
-  cd->div.width,
-  cd->div.flags);
-
-   req->best_parent_hw = clk_hw_get_parent(hw);
-
-   return 0;
-   }
-
return ccu_mux_helper_determine_rate(&cd->common, &cd->mux,
 req, ccu_div_round_rate, cd);
 }
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/20] drm: sun4i: Add support for the HDMI controller

[Maxime Ripard]

Hi,

Here is an attempt at getting the HDMI controller running.

This HDMI controller is found on a number of old Allwinner SoCs (A10, A10s,
A20, A31).

This driver only supports for now the A10s because it was an easy target,
being very close to the A13 that is already supported by our DRM driver.

There's nothing out of the extraordinary there, except maybe the clock
setup. All the internal clocks (TMDS, DDC) have been modeled using the
common clock framework, the TMDS clock being the parent of the DDC one.

While this might sound overkill, other SoC have a different, external
source for the DDC clock, which will be easier to support through the clock
framework.

The IP also supports audio (through an already supported i2s controller,
and some missing configuration in the HDMI controller) and CEC. Both will
come eventually.

Let me know what you think!
Maxime

Changes from v1:
  - Fixed typos in the CCU header and the HDMI code
  - Reintroduced the comment for the backporch timings
  - Renamed the hdmi node to hdmi, instead of hdmi0
  - Added support for hdmi-connector
  - Added a separate Kconfig option for the HDMI support
  - Changed the TCON muxing configuration for an explicit call in the
TCON's "clients"
  - Fixed the initialisation sequence that was clearing the clocks bits
  - Constified the HDMI's structures and removed whitespaces errors
  - Fixed an issue in the sunxi-ng code that was not reporting the proper
parent clock rate if it was modified
  - Removed unused headers
  - Removed CLK_SET_RATE_PARENT for the DDC clock
  - Used the DDC address defines
  - Removed the interlace flag that wasn't supported at the moment
  - Moved most of the HDMI encoder init to the bind function like we do for
the other encoders
  - Switched to drm_of_find_possible_crtcs
  - Removed the extra printk that were still in my code
  - Rebased on top of linux-next
  - Removed the patch changing the divider_round_rate prototype to
introduce a new function instead that takes the parent clock to
evaluate
  - Added a clk_set_rate for the hdmi module clock
  - Fixed the V_TOTAL TCON ch0 calculation to be consistent with ch1's
  - Defined all registers, and remove the TODOs
  - Fixed the EDID issues by increasing the timeout.
  - Added an atomic_check to prevent the DBLCLK modes to be used, as it is
not supported yet
  - Updated the binding to add the interrupts and DMA channels

Maxime Ripard (20):
  clk: divider: Make divider_round_rate take the parent clock
  clk: sunxi-ng: Pass the parent and a pointer to the clocks round rate
  clk: sunxi-ng: div: Switch to divider_round_rate
  clk: sunxi-ng: mux: Don't just rely on the parent for CLK_SET_RATE_PARENT
  clk: sunxi-ng: mux: split out the pre-divider computation code
  clk: sunxi-ng: mux: Change pre-divider application function prototype
  clk: sunxi-ng: mux: Re-adjust parent rate
  clk: sunxi-ng: sun5i: Export video PLLs
  drm/sun4i: tcon: Add channel debug
  drm/sun4i: tcon: Move the muxing out of the mode set function
  drm/sun4i: tcon: Switch mux on only for composite
  drm/sun4i: tcon: Fix tcon channel 1 backporch calculation
  drm/sun4i: tcon: Change vertical total size computation inconsistency
  drm/sun4i: tcon: multiply the vtotal when not in interlace
  drm/sun4i: Ignore the generic connectors for components
  dt-bindings: display: sun4i: Add HDMI display bindings
  dt-bindings: display: sun4i: Add allwinner,tcon-channel property
  drm/sun4i: Add HDMI support
  ARM: sun5i: a10s: Add the HDMI controller node
  ARM: sun5i: a10s-olinuxino: Enable HDMI

 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt |  90 +-
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts  |  29 +-
 arch/arm/boot/dts/sun5i-a10s.dtsi |  50 +-
 arch/arm/boot/dts/sun5i.dtsi  |   1 +-
 drivers/clk/clk-divider.c |  26 +-
 drivers/clk/sunxi-ng/ccu-sun5i.h  |   6 +-
 drivers/clk/sunxi-ng/ccu_div.c|  38 +-
 drivers/clk/sunxi-ng/ccu_mp.c |  15 +-
 drivers/clk/sunxi-ng/ccu_mult.c   |  19 +-
 drivers/clk/sunxi-ng/ccu_mux.c|  90 +-
 drivers/clk/sunxi-ng/ccu_mux.h|  11 +-
 drivers/clk/sunxi-ng/ccu_nkm.c|   7 +-
 drivers/gpu/drm/sun4i/Kconfig |   9 +-
 drivers/gpu/drm/sun4i/Makefile|   6 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c |   8 +-
 drivers/gpu/drm/sun4i/sun4i_hdmi.h| 157 ++-
 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c| 127 ++-
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 493 +++-
 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c   | 225 +++-
 drivers/gpu/drm/sun4i/sun4i_rgb.c  

[PATCH v2 2/20] clk: sunxi-ng: Pass the parent and a pointer to the clocks round rate

[Maxime Ripard]

The clocks might need to modify their parent clocks. In order to make that
possible, give them access to the parent clock being evaluated, and to a
pointer to the parent rate so that they can modify it if needed.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_div.c  |  7 ---
 drivers/clk/sunxi-ng/ccu_mp.c   |  7 ---
 drivers/clk/sunxi-ng/ccu_mult.c | 11 ++-
 drivers/clk/sunxi-ng/ccu_mux.c  |  8 +---
 drivers/clk/sunxi-ng/ccu_mux.h  |  3 ++-
 drivers/clk/sunxi-ng/ccu_nkm.c  |  7 ---
 6 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
index 4057e6021aa9..a489f18a3c01 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -14,7 +14,8 @@
 #include "ccu_div.h"
 
 static unsigned long ccu_div_round_rate(struct ccu_mux_internal *mux,
-   unsigned long parent_rate,
+   struct clk_hw *parent,
+   unsigned long *parent_rate,
unsigned long rate,
void *data)
 {
@@ -26,10 +27,10 @@ static unsigned long ccu_div_round_rate(struct 
ccu_mux_internal *mux,
 * several parents, while we might be called to evaluate
 * several different parents.
 */
-   val = divider_get_val(rate, parent_rate, cd->div.table, cd->div.width,
+   val = divider_get_val(rate, *parent_rate, cd->div.table, cd->div.width,
  cd->div.flags);
 
-   return divider_recalc_rate(&cd->common.hw, parent_rate, val,
+   return divider_recalc_rate(&cd->common.hw, *parent_rate, val,
   cd->div.table, cd->div.flags);
 }
 
diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
index b583f186a804..de02e6c386d8 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.c
+++ b/drivers/clk/sunxi-ng/ccu_mp.c
@@ -41,7 +41,8 @@ static void ccu_mp_find_best(unsigned long parent, unsigned 
long rate,
 }
 
 static unsigned long ccu_mp_round_rate(struct ccu_mux_internal *mux,
-  unsigned long parent_rate,
+  struct clk_hw *hw,
+  unsigned long *parent_rate,
   unsigned long rate,
   void *data)
 {
@@ -52,9 +53,9 @@ static unsigned long ccu_mp_round_rate(struct 
ccu_mux_internal *mux,
max_m = cmp->m.max ?: 1 << cmp->m.width;
max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
 
-   ccu_mp_find_best(parent_rate, rate, max_m, max_p, &m, &p);
+   ccu_mp_find_best(*parent_rate, rate, max_m, max_p, &m, &p);
 
-   return parent_rate / p / m;
+   return *parent_rate / p / m;
 }
 
 static void ccu_mp_disable(struct clk_hw *hw)
diff --git a/drivers/clk/sunxi-ng/ccu_mult.c b/drivers/clk/sunxi-ng/ccu_mult.c
index 671141359895..6ee7ba0738fb 100644
--- a/drivers/clk/sunxi-ng/ccu_mult.c
+++ b/drivers/clk/sunxi-ng/ccu_mult.c
@@ -33,9 +33,10 @@ static void ccu_mult_find_best(unsigned long parent, 
unsigned long rate,
 }
 
 static unsigned long ccu_mult_round_rate(struct ccu_mux_internal *mux,
-   unsigned long parent_rate,
-   unsigned long rate,
-   void *data)
+struct clk_hw *parent,
+unsigned long *parent_rate,
+unsigned long rate,
+void *data)
 {
struct ccu_mult *cm = data;
struct _ccu_mult _cm;
@@ -47,9 +48,9 @@ static unsigned long ccu_mult_round_rate(struct 
ccu_mux_internal *mux,
else
_cm.max = (1 << cm->mult.width) + cm->mult.offset - 1;
 
-   ccu_mult_find_best(parent_rate, rate, &_cm);
+   ccu_mult_find_best(*parent_rate, rate, &_cm);
 
-   return parent_rate * _cm.mult;
+   return *parent_rate * _cm.mult;
 }
 
 static void ccu_mult_disable(struct clk_hw *hw)
diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index c6bb1f523232..bae735e252b6 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -61,7 +61,8 @@ int ccu_mux_helper_determine_rate(struct ccu_common *common,
  struct ccu_mux_internal *cm,
  struct clk_rate_request *req,
  unsigned long (*round)(struct 
ccu_mux_internal *,
-unsigned long,
+struct clk_hw *,
+unsigned long *,
 unsigned long,
  

[PATCH v2 5/20] clk: sunxi-ng: mux: split out the pre-divider computation code

[Maxime Ripard]

The pre-divider retrieval code was merged into the function to apply the
current pre-divider onto the parent clock rate so that we can use that
adjusted value to do our factors computation.

However, since we'll need to do the reverse operation, we need to split out
that code into a function that will be shared.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_mux.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index 58b6e349a0ed..3eb23d4e6534 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -15,24 +15,20 @@
 #include "ccu_gate.h"
 #include "ccu_mux.h"
 
-void ccu_mux_helper_adjust_parent_for_prediv(struct ccu_common *common,
-struct ccu_mux_internal *cm,
-int parent_index,
-unsigned long *parent_rate)
+static u16 ccu_mux_get_prediv(struct ccu_common *common,
+ struct ccu_mux_internal *cm,
+ int parent_index)
 {
u16 prediv = 1;
u32 reg;
-   int i;
 
if (!((common->features & CCU_FEATURE_FIXED_PREDIV) ||
  (common->features & CCU_FEATURE_VARIABLE_PREDIV) ||
  (common->features & CCU_FEATURE_ALL_PREDIV)))
-   return;
+   return 1;
 
-   if (common->features & CCU_FEATURE_ALL_PREDIV) {
-   *parent_rate = *parent_rate / common->prediv;
-   return;
-   }
+   if (common->features & CCU_FEATURE_ALL_PREDIV)
+   return common->prediv;
 
reg = readl(common->base + common->reg);
if (parent_index < 0) {
@@ -40,10 +36,13 @@ void ccu_mux_helper_adjust_parent_for_prediv(struct 
ccu_common *common,
parent_index &= (1 << cm->width) - 1;
}
 
-   if (common->features & CCU_FEATURE_FIXED_PREDIV)
+   if (common->features & CCU_FEATURE_FIXED_PREDIV) {
+   int i;
+
for (i = 0; i < cm->n_predivs; i++)
if (parent_index == cm->fixed_predivs[i].index)
prediv = cm->fixed_predivs[i].div;
+   }
 
if (common->features & CCU_FEATURE_VARIABLE_PREDIV)
if (parent_index == cm->variable_prediv.index) {
@@ -54,7 +53,16 @@ void ccu_mux_helper_adjust_parent_for_prediv(struct 
ccu_common *common,
prediv = div + 1;
}
 
-   *parent_rate = *parent_rate / prediv;
+   return prediv;
+}
+
+void ccu_mux_helper_adjust_parent_for_prediv(struct ccu_common *common,
+struct ccu_mux_internal *cm,
+int parent_index,
+unsigned long *parent_rate)
+{
+   *parent_rate = *parent_rate / ccu_mux_get_prediv(common, cm,
+parent_index);
 }
 
 int ccu_mux_helper_determine_rate(struct ccu_common *common,
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/20] clk: sunxi-ng: mux: Don't just rely on the parent for CLK_SET_RATE_PARENT

[Maxime Ripard]

The current code only rely on the parent to change its rate in the case
where CLK_SET_RATE_PARENT is set.

However, some clock rates might be obtained only through a modification of
the parent and the clock divider. Just rely on the round rate of the clocks
to give us the best computation that might be achieved for a given rate.

round_rate functions now need to honor CLK_SET_RATE_PARENT, but either the
functions already do that if they modify the parent, or don't modify the
praents at all.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_mux.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index bae735e252b6..58b6e349a0ed 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -95,19 +95,7 @@ int ccu_mux_helper_determine_rate(struct ccu_common *common,
if (!parent)
continue;
 
-   if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
-   struct clk_rate_request parent_req = *req;
-   int ret = __clk_determine_rate(parent, &parent_req);
-
-   if (ret)
-   continue;
-
-   parent_rate = parent_req.rate;
-   } else {
-   parent_rate = clk_hw_get_rate(parent);
-   }
-
-   adj_parent_rate = parent_rate;
+   adj_parent_rate = parent_rate = clk_hw_get_rate(parent);
ccu_mux_helper_adjust_parent_for_prediv(common, cm, i,
&adj_parent_rate);
 
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/20] clk: divider: Make divider_round_rate take the parent clock

[Maxime Ripard]

So far, divider_round_rate only considers the parent clock returned by
clk_hw_get_parent.

This works fine on clocks that have a single parents, this doesn't work on
muxes, since we will only consider the first parent, while other parents
may totally be able to provide a better combination.

Clocks in that case cannot use divider_round_rate, so would have to come up
with a very similar logic to work around it. Instead of having to do
something like this, and duplicate that logic everywhere, create a
divider_round_rate parent to allow caller to give an additional parameter
for the parent clock to consider.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/clk-divider.c| 26 ++
 include/linux/clk-provider.h |  4 
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 96386ffc8483..48750439b1cd 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -275,7 +275,8 @@ static int _next_div(const struct clk_div_table *table, int 
div,
return div;
 }
 
-static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
+static int clk_divider_bestdiv(struct clk_hw *hw, struct clk_hw *parent,
+  unsigned long rate,
   unsigned long *best_parent_rate,
   const struct clk_div_table *table, u8 width,
   unsigned long flags)
@@ -314,8 +315,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned 
long rate,
*best_parent_rate = parent_rate_saved;
return i;
}
-   parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw),
-  rate * i);
+   parent_rate = clk_hw_round_rate(parent, rate * i);
now = DIV_ROUND_UP_ULL((u64)parent_rate, i);
if (_is_best_div(rate, now, best, flags)) {
bestdiv = i;
@@ -326,22 +326,32 @@ static int clk_divider_bestdiv(struct clk_hw *hw, 
unsigned long rate,
 
if (!bestdiv) {
bestdiv = _get_maxdiv(table, width, flags);
-   *best_parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw), 1);
+   *best_parent_rate = clk_hw_round_rate(parent, 1);
}
 
return bestdiv;
 }
 
-long divider_round_rate(struct clk_hw *hw, unsigned long rate,
-   unsigned long *prate, const struct clk_div_table *table,
-   u8 width, unsigned long flags)
+long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
+  unsigned long rate, unsigned long *prate,
+  const struct clk_div_table *table,
+  u8 width, unsigned long flags)
 {
int div;
 
-   div = clk_divider_bestdiv(hw, rate, prate, table, width, flags);
+   div = clk_divider_bestdiv(hw, parent, rate, prate, table, width, flags);
 
return DIV_ROUND_UP_ULL((u64)*prate, div);
 }
+EXPORT_SYMBOL_GPL(divider_round_rate_parent);
+
+long divider_round_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long *prate, const struct clk_div_table *table,
+   u8 width, unsigned long flags)
+{
+   return divider_round_rate_parent(hw, clk_hw_get_parent(hw), rate, prate,
+table, width, flags);
+}
 EXPORT_SYMBOL_GPL(divider_round_rate);
 
 static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index a428aec36ace..14102f783f64 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -412,6 +412,10 @@ extern const struct clk_ops clk_divider_ro_ops;
 unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate,
unsigned int val, const struct clk_div_table *table,
unsigned long flags);
+long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
+  unsigned long rate, unsigned long *prate,
+  const struct clk_div_table *table,
+  u8 width, unsigned long flags);
 long divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate, const struct clk_div_table *table,
u8 width, unsigned long flags);
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 6/20] clk: sunxi-ng: mux: Change pre-divider application function prototype

[Maxime Ripard]

The current function name is a bit confusing, and doesn't really allow to
create an explicit function to reverse the operation.

We also for now change the parent rate through a pointer, while we don't
return anything.

In order to be less confusing, and easier to use for downstream users,
change the function name to something hopefully clearer, and return the
adjusted rate instead of changing the pointer.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_div.c  |  8 
 drivers/clk/sunxi-ng/ccu_mp.c   |  8 
 drivers/clk/sunxi-ng/ccu_mult.c |  8 
 drivers/clk/sunxi-ng/ccu_mux.c  | 29 -
 drivers/clk/sunxi-ng/ccu_mux.h  |  8 
 5 files changed, 28 insertions(+), 33 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
index 419463375bc1..c0e5c10d0091 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -59,8 +59,8 @@ static unsigned long ccu_div_recalc_rate(struct clk_hw *hw,
val = reg >> cd->div.shift;
val &= (1 << cd->div.width) - 1;
 
-   ccu_mux_helper_adjust_parent_for_prediv(&cd->common, &cd->mux, -1,
-   &parent_rate);
+   parent_rate = ccu_mux_helper_apply_prediv(&cd->common, &cd->mux, -1,
+ parent_rate);
 
return divider_recalc_rate(hw, parent_rate, val, cd->div.table,
   cd->div.flags);
@@ -83,8 +83,8 @@ static int ccu_div_set_rate(struct clk_hw *hw, unsigned long 
rate,
unsigned long val;
u32 reg;
 
-   ccu_mux_helper_adjust_parent_for_prediv(&cd->common, &cd->mux, -1,
-   &parent_rate);
+   parent_rate = ccu_mux_helper_apply_prediv(&cd->common, &cd->mux, -1,
+ parent_rate);
 
val = divider_get_val(rate, parent_rate, cd->div.table, cd->div.width,
  cd->div.flags);
diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
index de02e6c386d8..b917ad7a386c 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.c
+++ b/drivers/clk/sunxi-ng/ccu_mp.c
@@ -87,8 +87,8 @@ static unsigned long ccu_mp_recalc_rate(struct clk_hw *hw,
u32 reg;
 
/* Adjust parent_rate according to pre-dividers */
-   ccu_mux_helper_adjust_parent_for_prediv(&cmp->common, &cmp->mux,
-   -1, &parent_rate);
+   parent_rate = ccu_mux_helper_apply_prediv(&cmp->common, &cmp->mux, -1,
+ parent_rate);
 
reg = readl(cmp->common.base + cmp->common.reg);
 
@@ -123,8 +123,8 @@ static int ccu_mp_set_rate(struct clk_hw *hw, unsigned long 
rate,
u32 reg;
 
/* Adjust parent_rate according to pre-dividers */
-   ccu_mux_helper_adjust_parent_for_prediv(&cmp->common, &cmp->mux,
-   -1, &parent_rate);
+   parent_rate = ccu_mux_helper_apply_prediv(&cmp->common, &cmp->mux, -1,
+ parent_rate);
 
max_m = cmp->m.max ?: 1 << cmp->m.width;
max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
diff --git a/drivers/clk/sunxi-ng/ccu_mult.c b/drivers/clk/sunxi-ng/ccu_mult.c
index 6ee7ba0738fb..20d0300867f2 100644
--- a/drivers/clk/sunxi-ng/ccu_mult.c
+++ b/drivers/clk/sunxi-ng/ccu_mult.c
@@ -88,8 +88,8 @@ static unsigned long ccu_mult_recalc_rate(struct clk_hw *hw,
val = reg >> cm->mult.shift;
val &= (1 << cm->mult.width) - 1;
 
-   ccu_mux_helper_adjust_parent_for_prediv(&cm->common, &cm->mux, -1,
-   &parent_rate);
+   parent_rate = ccu_mux_helper_apply_prediv(&cm->common, &cm->mux, -1,
+ parent_rate);
 
return parent_rate * (val + cm->mult.offset);
 }
@@ -116,8 +116,8 @@ static int ccu_mult_set_rate(struct clk_hw *hw, unsigned 
long rate,
else
ccu_frac_helper_disable(&cm->common, &cm->frac);
 
-   ccu_mux_helper_adjust_parent_for_prediv(&cm->common, &cm->mux, -1,
-   &parent_rate);
+   parent_rate = ccu_mux_helper_apply_prediv(&cm->common, &cm->mux, -1,
+ parent_rate);
 
_cm.min = cm->mult.min;
 
diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index 3eb23d4e6534..c33210972581 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -56,13 +56,12 @@ static u16 ccu_mux_get_prediv(struct ccu_common *common,
return prediv;
 }
 
-void ccu_mux_helper_adjust_parent_for_prediv(struct ccu_common *common,
-struct ccu_mux_internal *cm,
-int parent_index,
-

[PATCH v2 8/20] clk: sunxi-ng: sun5i: Export video PLLs

[Maxime Ripard]

The video PLLs are used directly by the HDMI controller. Export them so
that we can use them in our DT node.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu-sun5i.h  | 6 --
 include/dt-bindings/clock/sun5i-ccu.h | 3 +++
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.h b/drivers/clk/sunxi-ng/ccu-sun5i.h
index 8144487eb7ca..93a275fbd9a9 100644
--- a/drivers/clk/sunxi-ng/ccu-sun5i.h
+++ b/drivers/clk/sunxi-ng/ccu-sun5i.h
@@ -28,15 +28,17 @@
 #define CLK_PLL_AUDIO_4X   6
 #define CLK_PLL_AUDIO_8X   7
 #define CLK_PLL_VIDEO0 8
-#define CLK_PLL_VIDEO0_2X  9
+
+/* The PLL_VIDEO0_2X is exported for HDMI */
+
 #define CLK_PLL_VE 10
 #define CLK_PLL_DDR_BASE   11
 #define CLK_PLL_DDR12
 #define CLK_PLL_DDR_OTHER  13
 #define CLK_PLL_PERIPH 14
 #define CLK_PLL_VIDEO1 15
-#define CLK_PLL_VIDEO1_2X  16
 
+/* The PLL_VIDEO1_2X is exported for HDMI */
 /* The CPU clock is exported */
 
 #define CLK_AXI18
diff --git a/include/dt-bindings/clock/sun5i-ccu.h 
b/include/dt-bindings/clock/sun5i-ccu.h
index aeb2e2f781fb..81f34d477aeb 100644
--- a/include/dt-bindings/clock/sun5i-ccu.h
+++ b/include/dt-bindings/clock/sun5i-ccu.h
@@ -19,6 +19,9 @@
 
 #define CLK_HOSC   1
 
+#define CLK_PLL_VIDEO0_2X  9
+
+#define CLK_PLL_VIDEO1_2X  16
 #define CLK_CPU17
 
 #define CLK_AHB_OTG23
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 17/20] dt-bindings: display: sun4i: Add allwinner, tcon-channel property

[Maxime Ripard]

The Allwinner Timings Controller has two, mutually exclusive, channels.
When the binding has been introduced, it was assumed that there would be
only a single user per channel in the system.

While this is likely for the channel 0 which only connects to LCD displays,
it turns out that the channel 1 can be connected to multiple controllers in
the SoC (HDMI and TV encoders for example). And while the simultaneous use
of HDMI and TV outputs cannot be achieved, switching from one to the other
at runtime definitely sounds plausible.

Add an extra property, allwinner,tcon-channel, to specify for a given
endpoint which TCON channel it is connected to, while falling back to the
previous mechanism if that property is missing.

Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 11 ---
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 91ce2c920750..acdc0c17c00e 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -75,10 +75,13 @@ Required properties:
   Documentation/devicetree/bindings/media/video-interfaces.txt. The
   first port should be the input endpoint, the second one the output
 
-  The output should have two endpoints. The first is the block
-  connected to the TCON channel 0 (usually a panel or a bridge), the
-  second the block connected to the TCON channel 1 (usually the TV
-  encoder)
+  The output may have multiple endpoints. The TCON has two channels,
+  usually with the first channel being used for the panels interfaces
+  (RGB, LVDS, etc.), and the second being used for the outputs that
+  require another controller (TV Encoder, HDMI, etc.). The endpoints
+  will take an extra property, allwinner,tcon-channel, to specify the
+  channel the endpoint is associated to. If that property is not
+  present, the endpoint number will be used as the channel number.
 
 On SoCs other than the A33, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 9/20] drm/sun4i: tcon: Add channel debug

[Maxime Ripard]

While all functions have debug logs, the channel enable and disable are not
logged. Make sure this is the case.

Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 
 1 file changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 9a83a85529ac..66a5bb9b85e9 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -54,6 +54,8 @@ EXPORT_SYMBOL(sun4i_tcon_enable);
 
 void sun4i_tcon_channel_disable(struct sun4i_tcon *tcon, int channel)
 {
+   DRM_DEBUG_DRIVER("Disabling TCON channel %d\n", channel);
+
/* Disable the TCON's channel */
if (channel == 0) {
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
@@ -71,6 +73,8 @@ EXPORT_SYMBOL(sun4i_tcon_channel_disable);
 
 void sun4i_tcon_channel_enable(struct sun4i_tcon *tcon, int channel)
 {
+   DRM_DEBUG_DRIVER("Enabling TCON channel %d\n", channel);
+
/* Enable the TCON's channel */
if (channel == 0) {
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 18/20] drm/sun4i: Add HDMI support

[Maxime Ripard]

The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI
controller.

That HDMI controller is able to do audio and CEC, but those have been left
out for now.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/Kconfig   |   9 +-
 drivers/gpu/drm/sun4i/Makefile  |   6 +-
 drivers/gpu/drm/sun4i/sun4i_hdmi.h  | 157 +++-
 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c  | 127 +-
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c  | 493 +-
 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 225 ++-
 6 files changed, 1017 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi.h
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index a4b357db8856..35299c4e2594 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -12,3 +12,12 @@ config DRM_SUN4I
  Choose this option if you have an Allwinner SoC with a
  Display Engine. If M is selected the module will be called
  sun4i-drm.
+
+if DRM_SUN4I
+config DRM_SUN4I_HDMI
+   tristate "Allwinner A10 HDMI Controller Support"
+   help
+ Choose this option if you have an Allwinner SoC with an HDMI
+ controller.
+
+endif
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 59b757350a1f..c09bf8093710 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -11,3 +11,9 @@ obj-$(CONFIG_DRM_SUN4I)   += sun4i-drm.o 
sun4i-tcon.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_backend.o
 obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
+
+sun4i-drm-hdmi-y += sun4i_hdmi_enc.o
+sun4i-drm-hdmi-y += sun4i_hdmi_ddc_clk.o
+sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
+
+obj-$(CONFIG_DRM_SUN4I_HDMI)   += sun4i-drm-hdmi.o
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
new file mode 100644
index ..40d57b195b48
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -0,0 +1,157 @@
+/*
+ * Copyright (C) 2016 Maxime Ripard
+ *
+ * Maxime Ripard 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#ifndef _SUN4I_HDMI_H_
+#define _SUN4I_HDMI_H_
+
+#include 
+#include 
+
+#define SUN4I_HDMI_CTRL_REG0x004
+#define SUN4I_HDMI_CTRL_ENABLE BIT(31)
+
+#define SUN4I_HDMI_IRQ_REG 0x008
+#define SUN4I_HDMI_IRQ_STA_MASK0x73
+#define SUN4I_HDMI_IRQ_STA_FIFO_OF BIT(1)
+#define SUN4I_HDMI_IRQ_STA_FIFO_UF BIT(0)
+
+#define SUN4I_HDMI_HPD_REG 0x00c
+#define SUN4I_HDMI_HPD_HIGHBIT(0)
+
+#define SUN4I_HDMI_VID_CTRL_REG0x010
+#define SUN4I_HDMI_VID_CTRL_ENABLE BIT(31)
+#define SUN4I_HDMI_VID_CTRL_HDMI_MODE  BIT(30)
+
+#define SUN4I_HDMI_VID_TIMING_ACT_REG  0x014
+#define SUN4I_HDMI_VID_TIMING_BP_REG   0x018
+#define SUN4I_HDMI_VID_TIMING_FP_REG   0x01c
+#define SUN4I_HDMI_VID_TIMING_SPW_REG  0x020
+
+#define SUN4I_HDMI_VID_TIMING_X(x) x) - 1) & GENMASK(11, 0)))
+#define SUN4I_HDMI_VID_TIMING_Y(y) y) - 1) & GENMASK(11, 0)) 
<< 16)
+
+#define SUN4I_HDMI_VID_TIMING_POL_REG  0x024
+#define SUN4I_HDMI_VID_TIMING_POL_TX_CLK(0x3e0 << 16)
+#define SUN4I_HDMI_VID_TIMING_POL_VSYNCBIT(1)
+#define SUN4I_HDMI_VID_TIMING_POL_HSYNCBIT(0)
+
+#define SUN4I_HDMI_AVI_INFOFRAME_REG(n)(0x080 + (n))
+
+#define SUN4I_HDMI_PAD_CTRL0_REG   0x200
+#define SUN4I_HDMI_PAD_CTRL0_BIASENBIT(31)
+#define SUN4I_HDMI_PAD_CTRL0_LDOCENBIT(30)
+#define SUN4I_HDMI_PAD_CTRL0_LDODENBIT(29)
+#define SUN4I_HDMI_PAD_CTRL0_PWENC BIT(28)
+#define SUN4I_HDMI_PAD_CTRL0_PWEND BIT(27)
+#define SUN4I_HDMI_PAD_CTRL0_PWENG BIT(26)
+#define SUN4I_HDMI_PAD_CTRL0_CKEN  BIT(25)
+#define SUN4I_HDMI_PAD_CTRL0_TXEN  BIT(23)
+
+#define SUN4I_HDMI_PAD_CTRL1_REG   0x204
+#define SUN4I_HDMI_PAD_CTRL1_AMP_OPT   BIT(23)
+#define SUN4I_HDMI_PAD_CTRL1_AMPCK_OPT BIT(22)
+#define SUN4I_HDMI_PAD_CTRL1_EMP_OPT   BIT(20)
+#define SUN4I_HDMI_PAD_CTRL1_EMPCK_OPT BIT(19)
+#define SUN4I_HDMI_PAD_CTRL1_REG_DEN   BIT(15)
+#define SUN4I_HDMI_PAD_CTRL1_REG_DENCK BIT(14)
+#define SUN4I_HDMI_PAD_CTRL1_REG_EMP(n)(((n) & 7) << 10)
+#define SUN4I_HDMI_PAD_CTRL1_HALVE_CLK BIT(6)
+#define SUN4I_HDMI_PAD_CTRL1_REG_AMP(n) 

[PATCH v2 7/20] clk: sunxi-ng: mux: Re-adjust parent rate

[Maxime Ripard]

Currently, the parent rate given back to the clock framework in our
request is the original parent rate we calculated before trying to round
the rate of our clock.

This works fine unless our clock also changes its parent rate, in which
case we will simply ignore that change and still use the previous parent
rate.

Create a new function to re-adjust the parent rate to take the pre-dividers
into account, and give that back to the clock framework.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_mux.c | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index c33210972581..1ce62cc23f8a 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -64,6 +64,14 @@ unsigned long ccu_mux_helper_apply_prediv(struct ccu_common 
*common,
return parent_rate / ccu_mux_get_prediv(common, cm, parent_index);
 }
 
+unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
+   struct ccu_mux_internal *cm,
+   int parent_index,
+   unsigned long parent_rate)
+{
+   return parent_rate * ccu_mux_get_prediv(common, cm, parent_index);
+}
+
 int ccu_mux_helper_determine_rate(struct ccu_common *common,
  struct ccu_mux_internal *cm,
  struct clk_rate_request *req,
@@ -89,22 +97,37 @@ int ccu_mux_helper_determine_rate(struct ccu_common *common,
best_rate = round(cm, best_parent, &adj_parent_rate,
  req->rate, data);
 
+   /*
+* parent_rate might have been modified by our clock.
+* Re-apply the pre-divider if there's one, and give
+* the actual frequency the parent needs to run at.
+*/
+   best_parent_rate = ccu_mux_helper_unapply_prediv(common, cm, -1,
+
adj_parent_rate);
+
goto out;
}
 
for (i = 0; i < clk_hw_get_num_parents(hw); i++) {
-   unsigned long tmp_rate, parent_rate, adj_parent_rate;
+   unsigned long tmp_rate, parent_rate;
struct clk_hw *parent;
 
parent = clk_hw_get_parent_by_index(hw, i);
if (!parent)
continue;
 
-   parent_rate = clk_hw_get_rate(parent);
-   adj_parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
- parent_rate);
+   parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
+ 
clk_hw_get_rate(parent));
+
+   tmp_rate = round(cm, parent, &parent_rate, req->rate, data);
 
-   tmp_rate = round(cm, parent, &adj_parent_rate, req->rate, data);
+   /*
+* parent_rate might have been modified by our clock.
+* Re-apply the pre-divider if there's one, and give
+* the actual frequency the parent needs to run at.
+*/
+   parent_rate = ccu_mux_helper_unapply_prediv(common, cm, i,
+   parent_rate);
if (tmp_rate == req->rate) {
best_parent = parent;
best_parent_rate = parent_rate;
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 20/20] ARM: sun5i: a10s-olinuxino: Enable HDMI

[Maxime Ripard]

The A10s Olinuxino has an HDMI connector. Make sure we can use it.

Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 29 +-
 1 file changed, 29 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index 894f874a5beb..1d13b6407222 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -63,6 +63,17 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -76,6 +87,10 @@
};
 };
 
+&be0 {
+   status = "okay";
+};
+
 &ehci0 {
status = "okay";
 };
@@ -91,6 +106,16 @@
status = "okay";
 };
 
+&hdmi {
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins_a>;
@@ -248,6 +273,10 @@
status = "okay";
 };
 
+&tcon0 {
+   status = "okay";
+};
+
 &uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 19/20] ARM: sun5i: a10s: Add the HDMI controller node

[Maxime Ripard]

The A10s has an HDMI controller connected to the second TCON channel. Add
it to our DT.

Since the TV Encoder was the only channel 1 user so far, also add the
property now that we have several users.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 50 -
 arch/arm/boot/dts/sun5i.dtsi  |  1 +-
 2 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 1e38ff80366c..c9d4ee12599d 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -71,7 +71,49 @@
};
};
 
+   display-engine {
+   compatible = "allwinner,sun5i-a10s-display-engine",
+"allwinner,sun5i-a13-display-engine";
+   allwinner,pipelines = <&fe0>;
+   };
+
soc@01c0 {
+   hdmi: hdmi@01c16000 {
+   compatible = "allwinner,sun5i-a10s-hdmi";
+   reg = <0x01c16000 0x1000>;
+   interrupts = <58>;
+   clocks = <&ccu CLK_AHB_HDMI>, <&ccu CLK_HDMI>,
+<&ccu CLK_PLL_VIDEO0_2X>,
+<&ccu CLK_PLL_VIDEO1_2X>;
+   clock-names = "ahb", "mod", "pll-0", "pll-1";
+   dmas = <&dma SUN4I_DMA_NORMAL 16>,
+  <&dma SUN4I_DMA_NORMAL 16>,
+  <&dma SUN4I_DMA_DEDICATED 24>;
+   dma-names = "ddc-tx", "ddc-rx", "audio-tx";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hdmi_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hdmi_in_tcon0: endpoint {
+   remote-endpoint = 
<&tcon0_out_hdmi>;
+   };
+   };
+
+   hdmi_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+   };
+
pwm: pwm@01c20e00 {
compatible = "allwinner,sun5i-a10s-pwm";
reg = <0x01c20e00 0xc>;
@@ -128,3 +170,11 @@
 
 &sram_a {
 };
+
+&tcon0_out {
+   tcon0_out_hdmi: endpoint@2 {
+   reg = <2>;
+   remote-endpoint = <&hdmi_in_tcon0>;
+   allwinner,tcon-channel = <1>;
+   };
+};
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 5175f9cc9bed..0e29f1d98a9e 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -272,6 +272,7 @@
tcon0_out_tve0: endpoint@1 {
reg = <1>;
remote-endpoint = 
<&tve0_in_tcon0>;
+   allwinner,tcon-channel = <1>;
};
};
};
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 10/20] drm/sun4i: tcon: Move the muxing out of the mode set function

[Maxime Ripard]

The muxing can actually happen on both channels on some SoCs, so it makes
more sense to just move it out of the sun4i_tcon1_mode_set function and
create a separate function that needs to be called by the encoders.

Let's do that and convert the existing drivers.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_rgb.c  |  1 +
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 --
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  2 ++
 drivers/gpu/drm/sun4i/sun4i_tv.c   |  1 +
 4 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 67f0b91a99de..3003d290c635 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -175,6 +175,7 @@ static void sun4i_rgb_encoder_mode_set(struct drm_encoder 
*encoder,
struct sun4i_tcon *tcon = rgb->tcon;
 
sun4i_tcon0_mode_set(tcon, mode);
+   sun4i_tcon_set_mux(tcon, 0, encoder);
 
clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 66a5bb9b85e9..0204d9fadb66 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -108,6 +108,22 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, 
bool enable)
 }
 EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
 
+void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
+   struct drm_encoder *encoder)
+{
+   if (!tcon->quirks->has_unknown_mux)
+   return;
+
+   if (channel != 1)
+   return;
+
+   /*
+* FIXME: Undocumented bits
+*/
+   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
+}
+EXPORT_SYMBOL(sun4i_tcon_set_mux);
+
 static int sun4i_tcon_get_clk_delay(struct drm_display_mode *mode,
int channel)
 {
@@ -266,12 +282,6 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
   SUN4I_TCON_GCTL_IOMAP_MASK,
   SUN4I_TCON_GCTL_IOMAP_TCON1);
-
-   /*
-* FIXME: Undocumented bits
-*/
-   if (tcon->quirks->has_unknown_mux)
-   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
 }
 EXPORT_SYMBOL(sun4i_tcon1_mode_set);
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index f636343a935d..0350936b413c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -190,6 +190,8 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, bool 
enable);
 /* Mode Related Controls */
 void sun4i_tcon_switch_interlace(struct sun4i_tcon *tcon,
 bool enable);
+void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
+   struct drm_encoder *encoder);
 void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
  struct drm_display_mode *mode);
 void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 49c49431a053..03c494b8159c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -393,6 +393,7 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
const struct tv_mode *tv_mode = sun4i_tv_find_tv_by_mode(mode);
 
sun4i_tcon1_mode_set(tcon, mode);
+   sun4i_tcon_set_mux(tcon, 1, encoder);
 
/* Enable and map the DAC to the output */
regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 15/20] drm/sun4i: Ignore the generic connectors for components

[Maxime Ripard]

The generic connectors such as hdmi-connector doesn't have any driver in,
so if they are added to the component list, we will be waiting forever for
a non-existing driver to probe.

Add a list of the connectors we want to ignore when building our component
list.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 8ddd72cd5873..8c9d2e36be55 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -164,6 +164,11 @@ static const struct component_master_ops 
sun4i_drv_master_ops = {
.unbind = sun4i_drv_unbind,
 };
 
+static bool sun4i_drv_node_is_connector(struct device_node *node)
+{
+   return of_device_is_compatible(node, "hdmi-connector");
+}
+
 static bool sun4i_drv_node_is_frontend(struct device_node *node)
 {
return of_device_is_compatible(node, 
"allwinner,sun5i-a13-display-frontend") ||
@@ -204,7 +209,8 @@ static int sun4i_drv_add_endpoints(struct device *dev,
!of_device_is_available(node))
return 0;
 
-   if (!sun4i_drv_node_is_frontend(node)) {
+   if (!sun4i_drv_node_is_connector(node) &&
+   !sun4i_drv_node_is_frontend(node)) {
/* Add current component */
DRM_DEBUG_DRIVER("Adding component %s\n",
 of_node_full_name(node));
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 13/20] drm/sun4i: tcon: Change vertical total size computation inconsistency

[Maxime Ripard]

Both TCON channels need to have the resolution doubled, since the size the
hardware is going to use is whatever we put in the register divided by two.

However, we handle it differently for the two channels: in the channel 0,
our register access macro does the multiplication of the value passed as
paremeter, while in the channel 1, the macro doesn't do this, and we need
to do it before calling it.

Make this consistent by aligning the channel 0 with the channel 1
behaviour.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 86a806fae9fb..0f91ec8a4b26 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -190,7 +190,7 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
 
/* Set vertical display timings */
regmap_write(tcon->regs, SUN4I_TCON0_BASIC2_REG,
-SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal) |
+SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal * 2) |
 SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
 
/* Set Hsync and Vsync length */
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 0350936b413c..3517122ee679 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -51,7 +51,7 @@
 #define SUN4I_TCON0_BASIC1_H_BACKPORCH(bp) (((bp) - 1) & 0xfff)
 
 #define SUN4I_TCON0_BASIC2_REG 0x50
-#define SUN4I_TCON0_BASIC2_V_TOTAL(total)  total) * 2) & 
0x1fff) << 16)
+#define SUN4I_TCON0_BASIC2_V_TOTAL(total)  (((total) & 0x1fff) << 
16)
 #define SUN4I_TCON0_BASIC2_V_BACKPORCH(bp) (((bp) - 1) & 0xfff)
 
 #define SUN4I_TCON0_BASIC3_REG 0x54
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 14/20] drm/sun4i: tcon: multiply the vtotal when not in interlace

[Maxime Ripard]

It appears that the total vertical resolution needs to be doubled when
we're not in interlaced. Make sure that is the case.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 0f91ec8a4b26..efa079c1a3f5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -272,9 +272,9 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
/* Set vertical display timings */
bp = mode->crtc_vtotal - mode->crtc_vsync_start;
DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
-mode->vtotal, bp);
+mode->crtc_vtotal, bp);
regmap_write(tcon->regs, SUN4I_TCON1_BASIC4_REG,
-SUN4I_TCON1_BASIC4_V_TOTAL(mode->vtotal) |
+SUN4I_TCON1_BASIC4_V_TOTAL(mode->crtc_vtotal * 2) |
 SUN4I_TCON1_BASIC4_V_BACKPORCH(bp));
 
/* Set Hsync and Vsync length */
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 11/20] drm/sun4i: tcon: Switch mux on only for composite

[Maxime Ripard]

Even though that mux is undocumented, it seems like it needs to be set to 1
when using composite, and 0 when using HDMI.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 0204d9fadb66..1c609d808b86 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -111,16 +111,23 @@ EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
 void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
struct drm_encoder *encoder)
 {
+   u32 val;
+
if (!tcon->quirks->has_unknown_mux)
return;
 
if (channel != 1)
return;
 
+   if (encoder->encoder_type == DRM_MODE_ENCODER_TVDAC)
+   val = 1;
+   else
+   val = 0;
+
/*
 * FIXME: Undocumented bits
 */
-   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
+   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, val);
 }
 EXPORT_SYMBOL(sun4i_tcon_set_mux);
 
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 16/20] dt-bindings: display: sun4i: Add HDMI display bindings

[Maxime Ripard]

One of the possible output of the display pipeline, on the SoCs that have
it, is the HDMI controller.

Add a binding for it.

Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 79 +++-
 1 file changed, 79 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 57a8d0610062..91ce2c920750 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -4,6 +4,34 @@ Allwinner A10 Display Pipeline
 The Allwinner A10 Display pipeline is composed of several components
 that are going to be documented below:
 
+HDMI Encoder
+
+
+The HDMI Encoder supports the HDMI video and audio outputs, and does
+CEC. It is one end of the pipeline.
+
+Required properties:
+  - compatible: value must be one of:
+* allwinner,sun5i-a10s-hdmi
+  - reg: base address and size of memory-mapped region
+  - interrupts: interrupt associated to this IP
+  - clocks: phandles to the clocks feeding the HDMI encoder
+* ahb: the HDMI interface clock
+* mod: the HDMI module clock
+* pll-0: the first video PLL
+* pll-1: the second video PLL
+  - clock-names: the clock names mentioned above
+  - dmas: phandles to the DMA channels used by the HDMI encoder
+* ddc-tx: The channel for DDC transmission
+* ddc-rx: The channel for DDC reception
+* audio-tx: The channel used for audio transmission
+  - dma-names: the channel names mentioned above
+
+  - ports: A ports node with endpoint definitions as defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The
+first port should be the input endpoint. The second should be the
+output, usually to an HDMI connector.
+
 TV Encoder
 --
 
@@ -173,6 +201,57 @@ panel: panel {
};
 };
 
+connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+};
+
+hdmi: hdmi@01c16000 {
+   compatible = "allwinner,sun5i-a10s-hdmi";
+   reg = <0x01c16000 0x1000>;
+   interrupts = <58>;
+   clocks = <&ccu CLK_AHB_HDMI>, <&ccu CLK_HDMI>,
+<&ccu CLK_PLL_VIDEO0_2X>,
+<&ccu CLK_PLL_VIDEO1_2X>;
+   clock-names = "ahb", "mod", "pll-0", "pll-1";
+   dmas = <&dma SUN4I_DMA_NORMAL 16>,
+  <&dma SUN4I_DMA_NORMAL 16>,
+  <&dma SUN4I_DMA_DEDICATED 24>;
+   dma-names = "ddc-tx", "ddc-rx", "audio-tx";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hdmi_in_tcon0: endpoint {
+   remote-endpoint = <&tcon0_out_hdmi>;
+   };
+   };
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+   };
+   };
+};
+
 tve0: tv-encoder@01c0a000 {
compatible = "allwinner,sun4i-a10-tv-encoder";
reg = <0x01c0a000 0x1000>;
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 12/20] drm/sun4i: tcon: Fix tcon channel 1 backporch calculation

[Maxime Ripard]

It seems like what's called a backporch in the datasheet is actually the
backporch plus the sync period. Fix that in our driver.

Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 1c609d808b86..86a806fae9fb 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -262,7 +262,7 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
 SUN4I_TCON1_BASIC2_Y(mode->crtc_vdisplay));
 
/* Set horizontal display timings */
-   bp = mode->crtc_htotal - mode->crtc_hsync_end;
+   bp = mode->crtc_htotal - mode->crtc_hsync_start;
DRM_DEBUG_DRIVER("Setting horizontal total %d, backporch %d\n",
 mode->htotal, bp);
regmap_write(tcon->regs, SUN4I_TCON1_BASIC3_REG,
@@ -270,7 +270,7 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
 SUN4I_TCON1_BASIC3_H_BACKPORCH(bp));
 
/* Set vertical display timings */
-   bp = mode->crtc_vtotal - mode->crtc_vsync_end;
+   bp = mode->crtc_vtotal - mode->crtc_vsync_start;
DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
 mode->vtotal, bp);
regmap_write(tcon->regs, SUN4I_TCON1_BASIC4_REG,
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm: Create a format/modifier blob

[Brian Starkey]

Hi Daniel,

On Wed, May 03, 2017 at 12:47:18PM +0100, Daniel Stone wrote:

Hi Brian,

On 3 May 2017 at 12:00, Brian Starkey  wrote:

Having just caught up on IRC I'm sure I'm far too late for this party,
but...

Wouldn't this whole thing be a whole lot simpler if "IN_FORMATS"
stored "pointers" to separate blobs for the format and modifier lists?

I've used/written a few interfaces with offsets to
variable-length-arrays and IMO the code to handle them is always
hideous.


I don't agree ...

The idea is that the header can grow because the offsets allow it to;
adding a new member slots in between the end of static data and the
start of variable data, and since all the variable data is accessed by
an array, userspace doesn't have to be aware of the new members. 


This is the same in both approaches.


The
code for that is very clean (modulo the casts for pointer maths), cf.
formats_ptr and modifiers_ptr; I'd expect userspace to copy and use
those with version guards:
   uint32_t *formats = formats_ptr(blob);
   struct drm_format_modifier *modifiers = modifiers_ptr(blob);
   struct drm_format_unifier *unifiiers = (blob->version >= 2) ?
unifiers_ptr(blob) : NULL;


I concede the tricky code is all confined to the single implementation
in the kernel (encoding is far harder than decoding) - I just think
create_in_format_blob() is cumbersome, ugly and error-prone.



That's shorter than fetching separate blobs, and doesn't have multiple
error paths either. What am I missing?


Yes, this is a convincing argument.




Added bonus: With smart enough helper code the FourCC and modifiers
blobs can be shared across planes.


I think this is a serious case of premature optimisation; the memory
savings might be outweighed by the additional number of objects to
track, and userspace would have to jump through serious hoops with a
blob ID cache - something which is a very bad idea regardless - to
take any advantage of it.


Hey I'm just saying it's an option - not that it should be implemented
in V1.

Where both the formats and the modifiers are the same, Ben's approach
lets the blob be shared anyway.

Thanks,
Brian



Cheers, Daniel

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

Re: [PATCH 0/3] GPU-DRM-Radeon: Fine-tuning for three function implementations

[Christian König]

Am 02.05.2017 um 22:04 schrieb SF Markus Elfring:

From: Markus Elfring 
Date: Tue, 2 May 2017 22:00:02 +0200

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
   Use seq_putc() in radeon_sa_bo_dump_debug_info()
   Use seq_puts() in radeon_debugfs_pm_info()
   Use seq_puts() in r100_debugfs_cp_csq_fifo()


Reviewed-by: Christian König 



  drivers/gpu/drm/radeon/r100.c  | 6 +++---
  drivers/gpu/drm/radeon/radeon_pm.c | 5 +++--
  drivers/gpu/drm/radeon/radeon_sa.c | 9 +++--
  3 files changed, 9 insertions(+), 11 deletions(-)



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

Re: [PATCH 2/3] drm: Create a format/modifier blob

[Brian Starkey]

Hi,

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:

Updated blob layout (Rob, Daniel, Kristian, xerpi)

Cc: Rob Clark 
Cc: Daniel Stone 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
drivers/gpu/drm/drm_mode_config.c |   7 +++
drivers/gpu/drm/drm_plane.c   | 119 ++
include/drm/drm_mode_config.h |   6 ++
include/uapi/drm/drm_mode.h   |  26 +
4 files changed, 158 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..6bfbc3839df5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;

+   prop = drm_property_create(dev,
+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "IN_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.modifiers = prop;
+
return 0;
}

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 286e183891e5..2e89e0e73435 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
return num;
}

+struct drm_format_modifier_blob {
+#define FORMAT_BLOB_CURRENT 1
+   /* Version of this blob format */
+   u32 version;
+
+   /* Flags */
+   u32 flags;
+
+   /* Number of fourcc formats supported */
+   u32 count_formats;
+
+   /* Where in this blob the formats exist (in bytes) */
+   u32 formats_offset;
+
+   /* Number of drm_format_modifiers */
+   u32 count_modifiers;
+
+   /* Where in this blob the modifiers exist (in bytes) */
+   u32 modifiers_offset;
+
+   /* u32 formats[] */
+   /* struct drm_format_modifier modifiers[] */
+} __packed;
+
+static inline u32 *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (u32 *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (struct drm_format_modifier *)(((char *)blob) + 
blob->modifiers_offset);
+}
+
+static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
*plane,
+const struct drm_plane_funcs *funcs,
+const uint32_t *formats, unsigned int 
format_count,
+const uint64_t *format_modifiers)
+{
+   const struct drm_mode_config *config = &dev->mode_config;
+   const uint64_t *temp_modifiers = format_modifiers;
+   unsigned int format_modifier_count = 0;
+   struct drm_property_blob *blob = NULL;
+   struct drm_format_modifier *mod;
+   size_t blob_size = 0, formats_size, modifiers_size;
+   struct drm_format_modifier_blob *blob_data;
+   int i, j, ret = 0;
+
+   if (format_modifiers)
+   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
+   format_modifier_count++;
+
+   formats_size = sizeof(__u32) * format_count;
+   if (WARN_ON(!formats_size)) {
+   /* 0 formats are never expected */
+   return 0;
+   }
+
+   modifiers_size =
+   sizeof(struct drm_format_modifier) * format_modifier_count;
+
+   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
+   blob_size += ALIGN(formats_size, 8);
+   blob_size += modifiers_size;
+
+   blob = drm_property_create_blob(dev, blob_size, NULL);
+   if (IS_ERR(blob))
+   return -1;
+
+   blob_data = (struct drm_format_modifier_blob *)blob->data;
+   blob_data->version = FORMAT_BLOB_CURRENT;
+   blob_data->count_formats = format_count;
+   blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);


This looks to be missing some alignment.

Definitely needs to be at least to 4 bytes, but given you aligned
it up to 8 for the initial "blob_size" I assume the intention was to
put the formats on the next 8-byte aligned address after the end of
the struct, e.g.:

blob_data->formats_offset = ALIGN(sizeof(struct 
drm_format_modifier_blob), 8);

-Brian


+   blob_data->count_modifiers = format_modifier_count;
+
+   /* Modifiers offset is a pointer to a struct with a 64 bit field so it
+* should be naturally aligned to 8B.
+*/
+   blob_data->modifiers_offset =
+   ALIGN(blob_data->formats_offset + formats_size, 8);
+
+   memcpy(formats_ptr(blob_data), formats, formats_size);
+
+   /* If we can't determine support, just bail */
+   if (!funcs->format_mod_supported)
+   goto done;
+
+   mod = modifiers_ptr(blob_data);
+   for (i = 0; i < format_modifier_count; i++) {
+   

Re: [PATCH 2/3] drm: Create a format/modifier blob

[Liviu Dudau]

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
> 
> Cc: Rob Clark 
> Cc: Daniel Stone 
> Cc: Kristian H. Kristensen 
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/drm_mode_config.c |   7 +++
>  drivers/gpu/drm/drm_plane.c   | 119 
> ++
>  include/drm/drm_mode_config.h |   6 ++
>  include/uapi/drm/drm_mode.h   |  26 +
>  4 files changed, 158 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index d9862259a2a7..6bfbc3839df5 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.gamma_lut_size_property = prop;
>  
> + prop = drm_property_create(dev,
> +DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
> +"IN_FORMATS", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.modifiers = prop;
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 286e183891e5..2e89e0e73435 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
>   return num;
>  }
>  
> +struct drm_format_modifier_blob {
> +#define FORMAT_BLOB_CURRENT 1
> + /* Version of this blob format */
> + u32 version;
> +
> + /* Flags */
> + u32 flags;
> +
> + /* Number of fourcc formats supported */
> + u32 count_formats;
> +
> + /* Where in this blob the formats exist (in bytes) */
> + u32 formats_offset;
> +
> + /* Number of drm_format_modifiers */
> + u32 count_modifiers;
> +
> + /* Where in this blob the modifiers exist (in bytes) */
> + u32 modifiers_offset;
> +
> + /* u32 formats[] */
> + /* struct drm_format_modifier modifiers[] */
> +} __packed;
> +
> +static inline u32 *
> +formats_ptr(struct drm_format_modifier_blob *blob)
> +{
> + return (u32 *)(((char *)blob) + blob->formats_offset);
> +}
> +
> +static inline struct drm_format_modifier *
> +modifiers_ptr(struct drm_format_modifier_blob *blob)
> +{
> + return (struct drm_format_modifier *)(((char *)blob) + 
> blob->modifiers_offset);
> +}
> +
> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
> *plane,
> +  const struct drm_plane_funcs *funcs,
> +  const uint32_t *formats, unsigned int 
> format_count,
> +  const uint64_t *format_modifiers)

Why do you have to pass the format_modifiers again when you have 
plane->modifiers?
Or the reverse question: why do you need plane->modifiers when you are passing 
the
modifiers as parameters all the time?

> +{
> + const struct drm_mode_config *config = &dev->mode_config;
> + const uint64_t *temp_modifiers = format_modifiers;
> + unsigned int format_modifier_count = 0;
> + struct drm_property_blob *blob = NULL;
> + struct drm_format_modifier *mod;
> + size_t blob_size = 0, formats_size, modifiers_size;
> + struct drm_format_modifier_blob *blob_data;
> + int i, j, ret = 0;
> +
> + if (format_modifiers)
> + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> + format_modifier_count++;
> +
> + formats_size = sizeof(__u32) * format_count;
> + if (WARN_ON(!formats_size)) {
> + /* 0 formats are never expected */
> + return 0;
> + }
> +
> + modifiers_size =
> + sizeof(struct drm_format_modifier) * format_modifier_count;
> +
> + blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
> + blob_size += ALIGN(formats_size, 8);
> + blob_size += modifiers_size;
> +
> + blob = drm_property_create_blob(dev, blob_size, NULL);
> + if (IS_ERR(blob))
> + return -1;
> +
> + blob_data = (struct drm_format_modifier_blob *)blob->data;
> + blob_data->version = FORMAT_BLOB_CURRENT;
> + blob_data->count_formats = format_count;
> + blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
> + blob_data->count_modifiers = format_modifier_count;
> +
> + /* Modifiers offset is a pointer to a struct with a 64 bit field so it
> +  * should be naturally aligned to 8B.
> +  */
> + blob_data->modifiers_offset =
> + ALIGN(blob_data->formats_offset + formats_size, 8);
> +
> + memcpy(formats_ptr(blob_data), formats, formats_size);
> +
> + /* If we can't determine support, just bail */
> + if (!funcs->format_mod_supported)
> + goto done;
> +
> + mod = modifiers_ptr(blob_data);
> + for (i = 0; i < format_modifier_count; i++) {
> + for (j = 0

Re: [PATCH 2/3] drm: Create a format/modifier blob

[Emil Velikov]

Hi Ben,

On 3 May 2017 at 06:14, Ben Widawsky  wrote:

> +struct drm_format_modifier_blob {
> +#define FORMAT_BLOB_CURRENT 1
> +   /* Version of this blob format */
> +   u32 version;
> +
> +   /* Flags */
> +   u32 flags;
> +
> +   /* Number of fourcc formats supported */
> +   u32 count_formats;
> +
> +   /* Where in this blob the formats exist (in bytes) */
> +   u32 formats_offset;
> +
> +   /* Number of drm_format_modifiers */
> +   u32 count_modifiers;
> +
> +   /* Where in this blob the modifiers exist (in bytes) */
> +   u32 modifiers_offset;
> +
> +   /* u32 formats[] */
> +   /* struct drm_format_modifier modifiers[] */
> +} __packed;
> +
Why do we need packing here? Both layout and member offsets are
identical with and w/o it.
If there's something subtle to it, please add a comment.


> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
> *plane,
> +const struct drm_plane_funcs *funcs,
> +const uint32_t *formats, unsigned int 
> format_count,
> +const uint64_t *format_modifiers)
> +{

> +   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
> +   blob_size += ALIGN(formats_size, 8);
The 8 is "sizeof(void *) isn't it? Shouldn't we use that instead since
it expands to 4 for 32bit systems?

> +   blob_size += modifiers_size;
> +
> +   blob = drm_property_create_blob(dev, blob_size, NULL);
> +   if (IS_ERR(blob))
> +   return -1;
> +
> +   blob_data = (struct drm_format_modifier_blob *)blob->data;
> +   blob_data->version = FORMAT_BLOB_CURRENT;
> +   blob_data->count_formats = format_count;

> +   blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
Shouldn't we reuse the ALIGN(...) from above?


> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 8c67fc03d53d..dcdd04c55792 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -665,6 +665,32 @@ struct drm_mode_atomic {
> __u64 user_data;
>  };
>
> +struct drm_format_modifier {
> +   /* Bitmask of formats in get_plane format list this info applies to. 
> The
> +   * offset allows a sliding window of which 64 formats (bits).
> +   *
> +   * Some examples:
> +   * In today's world with < 65 formats, and formats 0, and 2 are
> +   * supported
> +   * 0x0005
> +   * ^-offset = 0, formats = 5
> +   *
> +   * If the number formats grew to 128, and formats 98-102 are
> +   * supported with the modifier:
> +   *
> +   * 0x003c 
> +   * ^
> +   * |__offset = 64, formats = 0x3c
> +   *
> +   */
> +   uint64_t formats;
> +   uint32_t offset;
> +   uint32_t pad;
> +
> +   /* This modifier can be used with the format for this plane. */
> +   uint64_t modifier;
> +} __packed;
> +
As above - why __packed?

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

Re: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init

[Daniel Stone]

Hi Liviu,

On 3 May 2017 at 11:34, Liviu Dudau  wrote:
> On Tue, May 02, 2017 at 10:14:26PM -0700, Ben Widawsky wrote:
>> v2: A minor addition from Daniel
>
> You are *really* pushing your luck by not Cc-ing *any* of the maintainers of
> the drivers you touch. You do want reviews, don't you?

Ouch. I'm very sure Ben does want reviews, but he mainly works in Mesa
where you can rely on the list rather than having to CC everyone
individually. It was a mistake, so please be more gentle with him;
your whole mail comes across as quite hostile to me.

> Finally, the questions I should've started with: why the change? What are you 
> trying to
> achieve? It is not very clear from the commit message at all.

It does deserve a much better commit message than what it has, but as
he is on holiday for the rest of the week, I can answer. Currently, we
advertise which formats each plane is capable of displaying. In order
for userspace to be able to allocate tiled/compressed buffers for
scanout, we want userspace to be able to discover which modifiers each
plane supports as well.

>> @@ -105,6 +108,28 @@ int drm_universal_plane_init(struct drm_device *dev, 
>> struct drm_plane *plane,
>>   return -ENOMEM;
>>   }
>>
>> + /* First driver to need more than 64 formats needs to fix this */
>> + if (WARN_ON(format_count > 64))
>> + return -EINVAL;
>
> What is the link between format_count and format modifiers? Why are you 
> introducing
> this artificial restriction on the format_count? Also, there doesn't seem to 
> be any
> check if format_modifier_count == format_count. What happens when they don't 
> match?

Inside the blob, each modifier carries a bitmask of formats (specified
by index) that the modifier applies to, i.e. with:
  .formats = { ARGB, XRGB, RGB565 },

a modifier which applied only to the 32-bit formats would specify a
bitmask of 0x3. The uABI supports this just fine, but the internal
plumbing does not yet, because no-one supports more than 64 formats.

>> +
>> + if (format_modifiers) {
>> + const uint64_t *temp_modifiers = format_modifiers;
>> + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
>> + format_modifier_count++;
>> + }
>> +
>> + plane->modifier_count = format_modifier_count;
>
> Why do you need to remember this? It is not used anywhere else!

It is used to populate the blob in a later patch!

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

Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob

[Daniel Stone]

Hi Brian,

On 3 May 2017 at 13:51, Brian Starkey  wrote:
> On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>> +   modifiers_size =
>> +   sizeof(struct drm_format_modifier) *
>> format_modifier_count;
>> +
>> +   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
>> +   blob_size += ALIGN(formats_size, 8);
>> +   blob_size += modifiers_size;
>> +
>> +   blob = drm_property_create_blob(dev, blob_size, NULL);
>> +   if (IS_ERR(blob))
>> +   return -1;
>> +
>> +   blob_data = (struct drm_format_modifier_blob *)blob->data;
>> +   blob_data->version = FORMAT_BLOB_CURRENT;
>> +   blob_data->count_formats = format_count;
>> +   blob_data->formats_offset = sizeof(struct
>> drm_format_modifier_blob);
>
> This looks to be missing some alignment.
>
> Definitely needs to be at least to 4 bytes, but given you aligned
> it up to 8 for the initial "blob_size" I assume the intention was to
> put the formats on the next 8-byte aligned address after the end of
> the struct, e.g.:
>
> blob_data->formats_offset = ALIGN(sizeof(struct
> drm_format_modifier_blob), 8);

It's fairly subtle, but I think it's correct.

formats_offset is the end of the fixed-size element, which is
currently aligned to 32 bytes, and practically speaking would always
have to be anyway. As it is an array of uint32_t, this gives natural
alignment.

If we have an odd number of formats supported, the formats[] array
will end on a 4-byte rather than 8-byte boundary, so the ALIGN() on
formats_size guarantees that modifiers_offset will be aligned to an
8-byte quantity, which is required as it has 64-bit elements.

The size of a pointer is not relevant since we're not passing pointers
across the kernel/userspace boundary, just offsets within a struct.
The alignment of those offsets has to correspond to the types located
at those offsets, i.e. 4 bytes for formats (guaranteed by fixed header
layout), and 8 bytes for modifiers (guaranteed by explicit alignment).

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

Re: [PATCH] drm/msm: fix splat when userspace is killed with pending atomic update

[Rob Clark]

On Tue, May 2, 2017 at 5:01 AM, Daniel Vetter  wrote:
> On Fri, Apr 28, 2017 at 8:05 PM, Rob Clark  wrote:
>> The ->preclose() hook is a good place to block for pending atomic
>> updates.  We can't do this in ->postclose(), as it needs to happen
>> before drm_fb_release().  Otherwise, since we have already swapped
>> state (in the case of a non-blocking atomic update), this means that
>> the plane_state->fb will be released and cleared before we wait for
>> fences from the atomic-commit wq.
>>
>> There are probably more complex solutions possible.  But since already
>> scheduled atomic update, possibly blocking on already scheduled gpu/etc
>> fences, will complete eventually (assuming nothing catches fire), so
>> the sanest thing seems to be just block until already scheduled atomic
>> updates complete before tearing things down.
>>
>> Fixes:
>>
>>WARNING: CPU: 1 PID: 69 at ../drivers/gpu/drm/drm_atomic_helper.c:1061 
>> drm_atomic_helper_wait_for_fences+0xe0/0xf8
>>Modules linked in:
>>
>>CPU: 1 PID: 69 Comm: kworker/1:1 Tainted: GW   4.11.0-rc8+ 
>> #1187
>>Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
>>Workqueue: events drm_mode_rmfb_work_fn
>>task: ffc036560d00 task.stack: ffc03655
>>PC is at drm_atomic_helper_wait_for_fences+0xe0/0xf8
>>LR is at complete_commit.isra.1+0x44/0x1c0
>>pc : [] lr : [] pstate: 2145
>>sp : ffc036553b60
>>x29: ffc036553b60 x28: ffc0264e6a00
>>x27: ffc035659000 x26: 
>>x25: ffc0240e8000 x24: 0038
>>x23:  x22: ff800858f200
>>x21: ffc0240e8000 x20: ffc02f56a800
>>x19:  x18: 
>>x17:  x16: 
>>x15:  x14: ffc00a192700
>>x13: 0004 x12: 
>>x11: ff80089a1690 x10: 08f0
>>x9 : ffc036553b20 x8 : ffc036561650
>>x7 : ffc03fe6cb40 x6 : 
>>x5 : 0001 x4 : 0002
>>x3 : ffc035659000 x2 : ffc0240e8c80
>>x1 :  x0 : ffc02adbe588
>>
>>---[ end trace 13aeec77c3fb55e2 ]---
>>Call trace:
>>Exception stack(0xffc036553990 to 0xffc036553ac0)
>>3980:    0080
>>39a0: ffc036553b60 ff80084f6040 4ff0 0038
>>39c0: ffc0365539d0 ff800857e098 ffc036553a00 ff800857e1b0
>>39e0: ffc036553a10 ff800857c554 ffc0365e8400 ffc0365e8400
>>3a00: ffc036553a20 ff8008103358 0001aad7 ff800851b72c
>>3a20: ffc036553a50 ff80080e9228 ffc02adbe588 
>>3a40: ffc0240e8c80 ffc035659000 0002 0001
>>3a60:  ffc03fe6cb40 ffc036561650 ffc036553b20
>>3a80: 08f0 ff80089a1690  0004
>>3aa0: ffc00a192700   
>>[] drm_atomic_helper_wait_for_fences+0xe0/0xf8
>>[] complete_commit.isra.1+0x44/0x1c0
>>[] msm_atomic_commit+0x32c/0x350
>>[] drm_atomic_commit+0x50/0x60
>>[] drm_atomic_remove_fb+0x158/0x250
>>[] drm_framebuffer_remove+0x50/0x158
>>[] drm_mode_rmfb_work_fn+0x40/0x58
>>[] process_one_work+0x1d0/0x378
>>[] worker_thread+0x244/0x488
>>[] kthread+0xfc/0x128
>>[] ret_from_fork+0x10/0x50
>>
>> Reported-by: Stanimir Varbanov 
>> Signed-off-by: Rob Clark 
>> ---
>> The hunk that removes the comment about ->preclose() included in this
>> patch to challenge the assumption that ->preclose() shouldn't exist ;-)
>
> And I'm going to challenge your patch here. Both fences and
> framebuffers and atomic commits are refcounted. If you go boom on them
> when userspace closes the fd, you have a refcount bug. We don't fix
> those by flusing stuff :-)

So, it isn't a refcount'ing but, but something much funnier..

It seems that mdp5 had custom plane state with it's own dup_state fxn,
pre-dating the addition of
__drm_atomic_helper_plane_duplicate_state(), and when the helper was
introduced it wasn't retrofitted.  Which was all good until the fence
ptr is added to base plane_state struct.  So this means that
plane_state->fence was getting copied over into the duplicated
plane_state.

So the atomic rmfb code would sometimes manage to copy the fence ptr
if there is another pending update which had already swapped state but
not yet committed.

BR,
-R

> Please add a pair of get/put() calls at the right place instead.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob

[Brian Starkey]

On Wed, May 03, 2017 at 02:51:18PM +0100, Daniel Stone wrote:

Hi Brian,

On 3 May 2017 at 13:51, Brian Starkey  wrote:

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:

+   modifiers_size =
+   sizeof(struct drm_format_modifier) *
format_modifier_count;
+
+   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
+   blob_size += ALIGN(formats_size, 8);
+   blob_size += modifiers_size;
+
+   blob = drm_property_create_blob(dev, blob_size, NULL);
+   if (IS_ERR(blob))
+   return -1;
+
+   blob_data = (struct drm_format_modifier_blob *)blob->data;
+   blob_data->version = FORMAT_BLOB_CURRENT;
+   blob_data->count_formats = format_count;
+   blob_data->formats_offset = sizeof(struct
drm_format_modifier_blob);


This looks to be missing some alignment.

Definitely needs to be at least to 4 bytes, but given you aligned
it up to 8 for the initial "blob_size" I assume the intention was to
put the formats on the next 8-byte aligned address after the end of
the struct, e.g.:

blob_data->formats_offset = ALIGN(sizeof(struct
drm_format_modifier_blob), 8);


It's fairly subtle, but I think it's correct.


It's the exact subtlety that I was concerned about.



formats_offset is the end of the fixed-size element, which is
currently aligned to 32 bytes, and practically speaking would always
have to be anyway. As it is an array of uint32_t, this gives natural
alignment.


Why must it always be? The __packed attribute means it'll have no
padding - so any u16 or u8 added to the end will break it - putting
the formats array on a non-aligned boundary.

If the assumption is that the struct will always be made of only
u32/u64 members (and the implementation will break otherwise) then
there had better be a really big comment saying so, and preferably a
compile-time assertion too.

I'm missing the reason for it being __packed in the first place -
perhaps that's just a left over and needs to be removed.

Either way, this line aligns to 8:

+   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);

...and the rest of the blob_size calculation looks like it assumes the
formats array starts at that 8-byte boundary. So, for clarity and
consistency I reckon the blob_size code and the code that builds the
blob should do the same thing.

Cheers,
-Brian



If we have an odd number of formats supported, the formats[] array
will end on a 4-byte rather than 8-byte boundary, so the ALIGN() on
formats_size guarantees that modifiers_offset will be aligned to an
8-byte quantity, which is required as it has 64-bit elements.

The size of a pointer is not relevant since we're not passing pointers
across the kernel/userspace boundary, just offsets within a struct.
The alignment of those offsets has to correspond to the types located
at those offsets, i.e. 4 bytes for formats (guaranteed by fixed header
layout), and 8 bytes for modifiers (guaranteed by explicit alignment).

Cheers,
Daniel

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

Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob

[Daniel Stone]

Hi Brian,

On 3 May 2017 at 15:03, Brian Starkey  wrote:
> On Wed, May 03, 2017 at 02:51:18PM +0100, Daniel Stone wrote:
>> formats_offset is the end of the fixed-size element, which is
>> currently aligned to 32 bytes, and practically speaking would always
>> have to be anyway. As it is an array of uint32_t, this gives natural
>> alignment.
>
> Why must it always be? The __packed attribute means it'll have no
> padding - so any u16 or u8 added to the end will break it - putting
> the formats array on a non-aligned boundary.
>
> If the assumption is that the struct will always be made of only
> u32/u64 members (and the implementation will break otherwise) then
> there had better be a really big comment saying so, and preferably a
> compile-time assertion too.

Indeed that's the case, for most ioctls at least. A comment would
definitely be in order.

> I'm missing the reason for it being __packed in the first place -
> perhaps that's just a left over and needs to be removed.
>
> Either way, this line aligns to 8:
>
> +   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
>
> ...and the rest of the blob_size calculation looks like it assumes the
> formats array starts at that 8-byte boundary. So, for clarity and
> consistency I reckon the blob_size code and the code that builds the
> blob should do the same thing.

All this is correct - the __packed declaration is unnecessary, and so
is the rounding up when calculating the size. And with that fixed, I
believe it should be correct, no?

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

Re: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init

[Liviu Dudau]

On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
> Hi Liviu,
> 
> On 3 May 2017 at 11:34, Liviu Dudau  wrote:
> > On Tue, May 02, 2017 at 10:14:26PM -0700, Ben Widawsky wrote:
> >> v2: A minor addition from Daniel
> >
> > You are *really* pushing your luck by not Cc-ing *any* of the maintainers of
> > the drivers you touch. You do want reviews, don't you?
> 
> Ouch. I'm very sure Ben does want reviews, but he mainly works in Mesa
> where you can rely on the list rather than having to CC everyone
> individually. It was a mistake, so please be more gentle with him;
> your whole mail comes across as quite hostile to me.

Sorry, I'm not trying to be hostile. Try to read the bolded words with a long
(southern USA) intonation as if to draw attention to them. You will see that
it is just pointing to two facts: he does not warn anyone about the changes and
he is not making the patchset that obviously critical by having a commit message
that implies everyone should pay attention to it. So he is really hoping to be
lucky to get reviews (or doesn't actively seek them).

> 
> > Finally, the questions I should've started with: why the change? What are 
> > you trying to
> > achieve? It is not very clear from the commit message at all.
> 
> It does deserve a much better commit message than what it has, but as
> he is on holiday for the rest of the week, I can answer. Currently, we
> advertise which formats each plane is capable of displaying. In order
> for userspace to be able to allocate tiled/compressed buffers for
> scanout, we want userspace to be able to discover which modifiers each
> plane supports as well.

I get the overall goal. We need/want something similar for Mali DP and AFBC 
buffers.
What I don't understand is the current aproach (but I've found from Brian that 
somehow
I've missed the long discussion(s) around the subject). I was hoping to learn
from the commit message why he thinks the introduction of this code is the right
way of doing it. And the IRC logs seem to imply that he is mostly doing 
something
that others have agreed upon and he doesn't really care about the approach as 
long
as it ticks the "supported by intel driver" box.

> 
> >> @@ -105,6 +108,28 @@ int drm_universal_plane_init(struct drm_device *dev, 
> >> struct drm_plane *plane,
> >>   return -ENOMEM;
> >>   }
> >>
> >> + /* First driver to need more than 64 formats needs to fix this */
> >> + if (WARN_ON(format_count > 64))
> >> + return -EINVAL;
> >
> > What is the link between format_count and format modifiers? Why are you 
> > introducing
> > this artificial restriction on the format_count? Also, there doesn't seem 
> > to be any
> > check if format_modifier_count == format_count. What happens when they 
> > don't match?
> 
> Inside the blob, each modifier carries a bitmask of formats (specified
> by index) that the modifier applies to, i.e. with:
>   .formats = { ARGB, XRGB, RGB565 },
> 
> a modifier which applied only to the 32-bit formats would specify a
> bitmask of 0x3. The uABI supports this just fine, but the internal
> plumbing does not yet, because no-one supports more than 64 formats.

Yeah, still doesn't answer the question. Maybe if the comment said something 
like:
"When building format modifiers bitmap we only have space to map up to 64 
formats.
Check that the driver is not trying to exceed that." then it would've been more
obvious why the check is needed and also why one doesn't care about 
format_modifier_count.

To explain my mindset: the way the patch series was formatted and the way I've 
read it
initially I did not realised that the idea is to build a bitmask. Nothing in 
this patch
alludes to that so I assumed there was a 1:1 relationship between format 
modifiers and
format.

> 
> >> +
> >> + if (format_modifiers) {
> >> + const uint64_t *temp_modifiers = format_modifiers;
> >> + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> >> + format_modifier_count++;
> >> + }
> >> +
> >> + plane->modifier_count = format_modifier_count;
> >
> > Why do you need to remember this? It is not used anywhere else!
> 
> It is used to populate the blob in a later patch!

I cannot find that patch. Nothing in the 3 patches uses that. Have a look!

Best regards,
Liviu

> 
> Cheers,
> Daniel

-- 

| 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 5/5] drm/vblank: Lock down vblank->hwmode more

[Ville Syrjälä]

On Wed, May 03, 2017 at 09:26:38AM +0200, Daniel Vetter wrote:
> In the previous patch we've implemented hwmode tracking a la i915 for
> the vblank timestamp calculations. But that was just the basic
> semantics, i915 has some nice sanity checks to make sure we keep
> getting this right. Move them over too.
> 
> Cc: Ville Syrjälä 
> Reviewed-by: Neil Armstrong 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c|  8 +++-
>  drivers/gpu/drm/i915/i915_irq.c  | 10 ++
>  drivers/gpu/drm/i915/intel_display.c | 11 ++-
>  3 files changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 89f0928b042a..942183a2aa3c 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -775,8 +775,10 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
> drm_device *dev,
>   /* If mode timing undefined, just return as no-op:
>* Happens during initial modesetting of a crtc.
>*/
> - if (mode->crtc_clock == 0) {
> + if (WARN_ON(mode->crtc_clock == 0)) {
>   DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
> + WARN_ON(drm_drv_uses_atomic_modeset(dev));

I would make these _ONCE() otherwise the machine might end up
practically dead.

> +
>   return false;
>   }
>  
> @@ -1338,6 +1340,10 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
>   send_vblank_event(dev, e, seq, &now);
>   }
>   spin_unlock_irqrestore(&dev->event_lock, irqflags);
> +
> + /* Will be reset by the modeset helpers when re-enabling the crtc by
> +  * calling drm_calc_timestamping_constants(). */
> + vblank->hwmode.crtc_clock = 0;
>  }
>  EXPORT_SYMBOL(drm_crtc_vblank_off);

Shouldn't we do this in drm_crtc_vblank_reset() as well?

Hmm. Except we call that after drm_calc_timestamping_constants(). I
guess we should be able to move the reset() into
intel_modeset_readout_hw_state(). And possibly move the vblank_on()
call as well?

>  
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 837e5bc2019a..ff18b3fc00d2 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -720,9 +720,7 @@ static u32 i915_get_vblank_counter(struct drm_device 
> *dev, unsigned int pipe)
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   i915_reg_t high_frame, low_frame;
>   u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
> - struct intel_crtc *intel_crtc = intel_get_crtc_for_pipe(dev_priv,
> - pipe);
> - const struct drm_display_mode *mode = &intel_crtc->base.hwmode;
> + const struct drm_display_mode *mode = &dev->vblank[pipe].hwmode;
>   unsigned long irqflags;
>  
>   htotal = mode->crtc_htotal;
> @@ -779,13 +777,17 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
> *crtc)
>  {
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - const struct drm_display_mode *mode = &crtc->base.hwmode;
> + const struct drm_display_mode *mode;
> + struct drm_vblank_crtc *vblank;
>   enum pipe pipe = crtc->pipe;
>   int position, vtotal;
>  
>   if (!crtc->active)
>   return -1;
>  
> + vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)];
> + mode = &vblank->hwmode;
> +
>   vtotal = mode->crtc_vtotal;
>   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
>   vtotal /= 2;
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 85b9e2f521a0..a190973daeee 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11443,12 +11443,6 @@ intel_modeset_update_crtc_state(struct 
> drm_atomic_state *state)
>   for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
>   to_intel_crtc(crtc)->config = 
> to_intel_crtc_state(new_crtc_state);
>  
> - /* Update hwmode for vblank functions */
> - if (new_crtc_state->active)
> - crtc->hwmode = new_crtc_state->adjusted_mode;
> - else
> - crtc->hwmode.crtc_clock = 0;
> -
>   /*
>* Update legacy state to satisfy fbc code. This can
>* be removed when fbc uses the atomic state.
> @@ -15425,8 +15419,6 @@ static void intel_modeset_readout_hw_state(struct 
> drm_device *dev)
>   to_intel_crtc_state(crtc->base.state);
>   int pixclk = 0;
>  
> - crtc->base.hwmode = crtc_state->base.adjusted_mode;
> -
>   memset(&crtc->base.mode, 0, sizeof(crtc->base.mode));
>   if (crtc_state->base.active) {
>   intel_mode_from_pipe_config(&crtc->base.mode, 
> crtc_state);
> @@ -15456,7 +15448,8 @@ static void intel_modeset

Re: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init

[Daniel Stone]

On 3 May 2017 at 15:07, Liviu Dudau  wrote:
> On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
>> On 3 May 2017 at 11:34, Liviu Dudau  wrote:
>> > You are *really* pushing your luck by not Cc-ing *any* of the maintainers 
>> > of
>> > the drivers you touch. You do want reviews, don't you?
>>
>> Ouch. I'm very sure Ben does want reviews, but he mainly works in Mesa
>> where you can rely on the list rather than having to CC everyone
>> individually. It was a mistake, so please be more gentle with him;
>> your whole mail comes across as quite hostile to me.
>
> Sorry, I'm not trying to be hostile. Try to read the bolded words with a long
> (southern USA) intonation as if to draw attention to them. You will see that
> it is just pointing to two facts: he does not warn anyone about the changes 
> and
> he is not making the patchset that obviously critical by having a commit 
> message
> that implies everyone should pay attention to it. So he is really hoping to be
> lucky to get reviews (or doesn't actively seek them).

You could achieve the same thing with absolutely no room for
misinterpretation: 'Hi Ben. Not sure if you weren't aware or forgot,
but when posting patches here, please use get_maintainers.pl to build
a CC list. I only really saw this by luck, and other maintainers have
probably missed this too.'

>> It does deserve a much better commit message than what it has, but as
>> he is on holiday for the rest of the week, I can answer. Currently, we
>> advertise which formats each plane is capable of displaying. In order
>> for userspace to be able to allocate tiled/compressed buffers for
>> scanout, we want userspace to be able to discover which modifiers each
>> plane supports as well.
>
> I get the overall goal. We need/want something similar for Mali DP and AFBC 
> buffers.
> What I don't understand is the current aproach (but I've found from Brian 
> that somehow
> I've missed the long discussion(s) around the subject). I was hoping to learn
> from the commit message why he thinks the introduction of this code is the 
> right
> way of doing it. And the IRC logs seem to imply that he is mostly doing 
> something
> that others have agreed upon and he doesn't really care about the approach as 
> long
> as it ticks the "supported by intel driver" box.

Or, with another interpretation, he thinks the various approaches of
doing it are all equally good. He took guidance from a couple of
userspace developers (Weston, ChromeOS), a Freedreno developer and
also I believe an AFBC developer, to end up where he is now, which he
still thinks is fine. In doing so, he's been through several
iterations, always modifying the driver to suit. I think that's a
pretty good way to do development of new uABI, if you ask me. (And
again, I have trouble reading your last sentence as anything other
than hostile.)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob

[Brian Starkey]

Hi Daniel,

On Wed, May 03, 2017 at 03:07:40PM +0100, Daniel Stone wrote:

Hi Brian,

On 3 May 2017 at 15:03, Brian Starkey  wrote:

On Wed, May 03, 2017 at 02:51:18PM +0100, Daniel Stone wrote:

formats_offset is the end of the fixed-size element, which is
currently aligned to 32 bytes, and practically speaking would always
have to be anyway. As it is an array of uint32_t, this gives natural
alignment.


Why must it always be? The __packed attribute means it'll have no
padding - so any u16 or u8 added to the end will break it - putting
the formats array on a non-aligned boundary.

If the assumption is that the struct will always be made of only
u32/u64 members (and the implementation will break otherwise) then
there had better be a really big comment saying so, and preferably a
compile-time assertion too.


Indeed that's the case, for most ioctls at least. A comment would
definitely be in order.



No need for a comment if the code is fixed to do the right thing
irrespective of the value of sizeof(drm_formats_modifier_blob) - which
IMO is mandatory.


I'm missing the reason for it being __packed in the first place -
perhaps that's just a left over and needs to be removed.

Either way, this line aligns to 8:

+   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);

...and the rest of the blob_size calculation looks like it assumes the
formats array starts at that 8-byte boundary. So, for clarity and
consistency I reckon the blob_size code and the code that builds the
blob should do the same thing.


All this is correct - the __packed declaration is unnecessary, and so
is the rounding up when calculating the size. And with that fixed, I
believe it should be correct, no?


Yes, with those problems fixed it looks correct to me.

Thanks,
-Brian



Cheers,
Daniel

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

Re: Soliciting DRM feedback on latest DC rework

[Christian König]

Hi Harry,

while this looks more and more like it could work something which would 
really help would be to have a set of patches squashed together and 
rebased on drm-next.


The dc-drm-next-atomic-wip looks like a start, but we need more 
something like:

drm/amdgpu: add base DC components
drm/amdgpu: add DCE8 support for DC
drm/amdgpu: add DCE9 support for DC
drm/amdgpu: add DCE10 support for DC
...
drm/amdgpu: enable DC globally
drm/amdgpu: remove old display infrastructure

Otherwise I fear that people will just be lost in the mass amount of 
patches we have in the branch.


Regards,
Christian.

Am 03.05.2017 um 16:13 schrieb Harry Wentland:

Hi all,

Over the last few months we (mostly Andrey and myself) have taken and 
addressed some of the feedback received from December's DC RFC. A lot 
of our work so far centers around atomic. We were able to take a whole 
bunch of the areas where we rolled our own solution and use DRM atomic 
helpers instead.


You can find our most recent drm-next based tree at 
https://cgit.freedesktop.org/~hwentland/linux/log/?h=dc-drm-next-atomic-wip


An outline of the changes with commit hashes from that tree are listed 
below. They aren't necessarily in order but are grouped by functionality.


I would like to solicit input on the changes and the current state of 
amd/display in general.


I'm on IRC every weekday from 9-5 eastern time, sometimes at other 
hours. Feel free to ask questions, discuss, leave comments. Let me 
know if there's anything else I can do to facilitate review.


We know there's more work to be done but would much rather prioritize 
that work based on community feedback than merely our own impressions.


We haven't finished plumbing drm types to the dc types yet, and there 
are still a bunch of other things in progress.  We are not looking to 
re-hash the previous discussion, but rather we'd like some feedback on 
our work so far.


The list of changes (trimmed commit tags):

== Use common helpers for pageflip ==
144da239b047 Use pflip prepare and submit parts (v2)
ff7ac264a9a1 Fix page flip after daniel's acquire_ctx change


== implement atomic_get_properties ==
cf4a84df7189 Fallback on legacy properties in atomic_get_properties
01f96706b6ca get_atomic_property missing for drm_connector_funcs


== Use common helpers for gamma ==
3f547d7098de Use atomic helpers for gamma


== Use atomic helpers for commit ==
41831f55bd58 Refactor atomic commit implementation. (v2)
6c67dd3c5cd5 Refactor headless to use atomic commit.
eb22ef1ecb16 Remove page_fleep_needed function.


== Use atomic helpers for S3 ==
5a6ae6f76249 Switch to DRM helpers in s3.


== Simmplify mapping between DRM and DC objects ==
84a3ee023b9b Remove get_connector_for_link.
6d8978a98b40 Remove get_connector_for_sink.


== Use DRM EDID read instead of DC ==
566969dacfad Fix i2c write flag.
527c3699ff3c Refactor edid read.
5ac51023d275 Fix missing irq refactor causing potential i2c race


== Save DC validate_ctx in atomic_check and use in commit ==
8c194d8e4ee9 pull commit_surfaces out of atomic_commit into helper 
function

27eef98b38c8 Return context from validate_context
ca3ee10e915b Add DM global atomic state
8ba1ca856532 Hook dm private state into atomic_check
10160455ac6d Add correct retain/release for objs in dm_atomic_state
0f1b2e2aecbb Commit validation set from state
258e6a91fc61 Add validate_context to atomic_state
64f569b5df20 Use validate_context from atomic_check in commit


== Start multi-plane implementation ==
601ff4e70b7c decouple per-crtc-plane model
a0b859a0b114 Fix cleanup in amdgpu_dm_initialize_drm_device
ee02010d7a82 update plane functionalities
3b7345fd1abb Allow planes on all crtcs
d9cf37462156 initialize YUV plane capabilities
248f06b2613e Universal cursor plane hook-up.


== Minor cleanups ==
d99bf02cb8fc Rename atomic_commit parameter.
f15fb9726502 Use amdgpu mode funcs statically
d3e37fa70643 Remove unused define from amdgpu_dm_types
80a38ad58125 Add lock around updating freesync property
8c7f16853824 Use new drm_dp_find_vcpi_slots to compute slots

Regards,
Harry
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



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

Soliciting DRM feedback on latest DC rework

[Harry Wentland]

Hi all,

Over the last few months we (mostly Andrey and myself) have taken and 
addressed some of the feedback received from December's DC RFC. A lot of 
our work so far centers around atomic. We were able to take a whole 
bunch of the areas where we rolled our own solution and use DRM atomic 
helpers instead.


You can find our most recent drm-next based tree at 
https://cgit.freedesktop.org/~hwentland/linux/log/?h=dc-drm-next-atomic-wip


An outline of the changes with commit hashes from that tree are listed 
below. They aren't necessarily in order but are grouped by functionality.


I would like to solicit input on the changes and the current state of 
amd/display in general.


I'm on IRC every weekday from 9-5 eastern time, sometimes at other 
hours. Feel free to ask questions, discuss, leave comments. Let me know 
if there's anything else I can do to facilitate review.


We know there's more work to be done but would much rather prioritize 
that work based on community feedback than merely our own impressions.


We haven't finished plumbing drm types to the dc types yet, and there 
are still a bunch of other things in progress.  We are not looking to 
re-hash the previous discussion, but rather we'd like some feedback on 
our work so far.


The list of changes (trimmed commit tags):

== Use common helpers for pageflip ==
144da239b047 Use pflip prepare and submit parts (v2)
ff7ac264a9a1 Fix page flip after daniel's acquire_ctx change


== implement atomic_get_properties ==
cf4a84df7189 Fallback on legacy properties in atomic_get_properties
01f96706b6ca get_atomic_property missing for drm_connector_funcs


== Use common helpers for gamma ==
3f547d7098de Use atomic helpers for gamma


== Use atomic helpers for commit ==
41831f55bd58 Refactor atomic commit implementation. (v2)
6c67dd3c5cd5 Refactor headless to use atomic commit.
eb22ef1ecb16 Remove page_fleep_needed function.


== Use atomic helpers for S3 ==
5a6ae6f76249 Switch to DRM helpers in s3.


== Simmplify mapping between DRM and DC objects ==
84a3ee023b9b Remove get_connector_for_link.
6d8978a98b40 Remove get_connector_for_sink.


== Use DRM EDID read instead of DC ==
566969dacfad Fix i2c write flag.
527c3699ff3c Refactor edid read.
5ac51023d275 Fix missing irq refactor causing potential i2c race


== Save DC validate_ctx in atomic_check and use in commit ==
8c194d8e4ee9 pull commit_surfaces out of atomic_commit into helper function
27eef98b38c8 Return context from validate_context
ca3ee10e915b Add DM global atomic state
8ba1ca856532 Hook dm private state into atomic_check
10160455ac6d Add correct retain/release for objs in dm_atomic_state
0f1b2e2aecbb Commit validation set from state
258e6a91fc61 Add validate_context to atomic_state
64f569b5df20 Use validate_context from atomic_check in commit


== Start multi-plane implementation ==
601ff4e70b7c decouple per-crtc-plane model
a0b859a0b114 Fix cleanup in amdgpu_dm_initialize_drm_device
ee02010d7a82 update plane functionalities
3b7345fd1abb Allow planes on all crtcs
d9cf37462156 initialize YUV plane capabilities
248f06b2613e Universal cursor plane hook-up.


== Minor cleanups ==
d99bf02cb8fc Rename atomic_commit parameter.
f15fb9726502 Use amdgpu mode funcs statically
d3e37fa70643 Remove unused define from amdgpu_dm_types
80a38ad58125 Add lock around updating freesync property
8c7f16853824 Use new drm_dp_find_vcpi_slots to compute slots

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

Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Daniel Vetter]

On Wed, May 03, 2017 at 12:36:06PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Wednesday 03 May 2017 11:32:17 Daniel Vetter wrote:
> > On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
> > > +panel/bridge reviewers.
> > > 
> > > This does make things much cleaner, but it seems a bit strange to create
> > > a drm_bridge when there isn't really a HW bridge in the display chain
> > > (i.e, when the DSI encoder is directly connected to a DSI panel).
> > > 
> > > There are kms drivers that use drm_panel, but don't have simple stub
> > > connectors that wrap around a drm_panel. They have more complicated
> > > connector ops, and may call drm_panel_prepare() and related functions a
> > > bit differently. We won't be able to use drm_panel_bridge for those
> > > drivers.
> > > 
> > > For msm, we check whether the DSI encoder is connected directly to a panel
> > > or an external bridge. If it's connected to an external bridge, we skip
> > > the creation of the stub connector, and rely on the external bridge driver
> > > to create the connector:
> > > 
> > > http://lxr.free-electrons.com/source/drivers/gpu/drm/msm/dsi/dsi.c#L227
> > > 
> > > The msm solution isn't very neat, but it avoids the need to create another
> > > bridge to glue things together.
> > 
> > Since I suggested this, yes I like it. And I think just unconditionally
> > creating the panel bridge is probably even simpler, after all bridges are
> > supposed to be chainable. I guess there's always going to be drivers where
> > we need special handling, but I'm kinda hoping that for most cases simply
> > plugging in a panel bridge is all that's need to glue drm_panel support
> > into a driver. The simple pipe helpers do support bridges, and part of the
> > goal there very much was to make it easy to glue in panel drivers.
> 
> As I've just explained in another reply, I don't see the point in doing this 
> when we can instead refactor the bridge and panel operations to expose a 
> common base object that will then be easy to handle in core code. This isn't 
> just for panels, as connectors should have DT nodes, it makes sense to 
> instantiate an object for them that can be handled by the DRM core, without 
> having to push connector handling in all bridge drivers.

Imo you're aiming too high. We have 21 bridge drivers and 11 panel
drivers. Asking someone to refactor them all (plus all the callers and
everything) means it won't happen. At least I personally will definitely
not block a contribution on this happening, that's a totally outsized
demand.

What we could do instead is slowly merge these two worlds together, and
this here is definitely a step into that direction. Let's please not throw
out useful improvements by insisting that we only merge perfect code. We
already did merge both drm_panel and drm_bridge (plus a few more earlier
attempts), clearly we're not only merging perfect code :-)

Or you go ahead and deliver that refactoring, that's another option ofc
...

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm/mdp5: use __drm_atomic_helper_plane_duplicate_state()

[Rob Clark]

Somehow the helper was never retrofitted for mdp5.  Which meant when
plane_state->fence was added, it could get copied into new state in
mdp5_plane_duplicate_state().

If an update to disable the plane (for example on rmfb) managed to sneak
in after an nonblock update had swapped state, but before it was
committed, we'd get a splat:

WARNING: CPU: 1 PID: 69 at ../drivers/gpu/drm/drm_atomic_helper.c:1061 
drm_atomic_helper_wait_for_fences+0xe0/0xf8
   Modules linked in:

   CPU: 1 PID: 69 Comm: kworker/1:1 Tainted: GW   4.11.0-rc8+ #1187
   Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
   Workqueue: events drm_mode_rmfb_work_fn
   task: ffc036560d00 task.stack: ffc03655
   PC is at drm_atomic_helper_wait_for_fences+0xe0/0xf8
   LR is at complete_commit.isra.1+0x44/0x1c0
   pc : [] lr : [] pstate: 2145
   sp : ffc036553b60
   x29: ffc036553b60 x28: ffc0264e6a00
   x27: ffc035659000 x26: 
   x25: ffc0240e8000 x24: 0038
   x23:  x22: ff800858f200
   x21: ffc0240e8000 x20: ffc02f56a800
   x19:  x18: 
   x17:  x16: 
   x15:  x14: ffc00a192700
   x13: 0004 x12: 
   x11: ff80089a1690 x10: 08f0
   x9 : ffc036553b20 x8 : ffc036561650
   x7 : ffc03fe6cb40 x6 : 
   x5 : 0001 x4 : 0002
   x3 : ffc035659000 x2 : ffc0240e8c80
   x1 :  x0 : ffc02adbe588

   ---[ end trace 13aeec77c3fb55e2 ]---
   Call trace:
   Exception stack(0xffc036553990 to 0xffc036553ac0)
   3980:    0080
   39a0: ffc036553b60 ff80084f6040 4ff0 0038
   39c0: ffc0365539d0 ff800857e098 ffc036553a00 ff800857e1b0
   39e0: ffc036553a10 ff800857c554 ffc0365e8400 ffc0365e8400
   3a00: ffc036553a20 ff8008103358 0001aad7 ff800851b72c
   3a20: ffc036553a50 ff80080e9228 ffc02adbe588 
   3a40: ffc0240e8c80 ffc035659000 0002 0001
   3a60:  ffc03fe6cb40 ffc036561650 ffc036553b20
   3a80: 08f0 ff80089a1690  0004
   3aa0: ffc00a192700   
   [] drm_atomic_helper_wait_for_fences+0xe0/0xf8
   [] complete_commit.isra.1+0x44/0x1c0
   [] msm_atomic_commit+0x32c/0x350
   [] drm_atomic_commit+0x50/0x60
   [] drm_atomic_remove_fb+0x158/0x250
   [] drm_framebuffer_remove+0x50/0x158
   [] drm_mode_rmfb_work_fn+0x40/0x58
   [] process_one_work+0x1d0/0x378
   [] worker_thread+0x244/0x488
   [] kthread+0xfc/0x128
   [] ret_from_fork+0x10/0x50

Reported-by: Stanimir Varbanov 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index a38c5fe..30b4691 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -225,9 +225,10 @@ mdp5_plane_duplicate_state(struct drm_plane *plane)
 
mdp5_state = kmemdup(to_mdp5_plane_state(plane->state),
sizeof(*mdp5_state), GFP_KERNEL);
+   if (!mdp5_state)
+   return NULL;
 
-   if (mdp5_state && mdp5_state->base.fb)
-   drm_framebuffer_reference(mdp5_state->base.fb);
+   __drm_atomic_helper_plane_duplicate_state(plane, &mdp5_state->base);
 
return &mdp5_state->base;
 }
-- 
2.9.3

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

Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform

[Laura Abbott]

On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
>> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
>>>  /**
>>> + * drm_gem_prime_import_platform - alternate implementation of the import 
>>> callback
>>> + * @dev: drm_device to import into
>>> + * @dma_buf: dma-buf object to import
>>> + *
>>> + * This is identical to drm_gem_prime_import except the device used for 
>>> dma_buf
>>> + * attachment is an internal platform device instead of the standard device
>>> + * structure. The use of this function should be limited to drivers that 
>>> do not
>>> + * set up an underlying device structure.
>>> + */
>>> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device 
>>> *dev,
>>
>> Simpler soluation will be for the caller to provide the platformdev?
>>
>> That works nicely for the vgem case, I think.
> 
> Yeah looking at this again, do we really need this patch? Couldn't we
> instead change patch 1 to first allocate the fake platform device, then
> pass that to drm_dev_alloc (instead of NULL like we do now)?
> 

That was what I proposed in the first version and it was rejected.
It's useful to have at least one driver with a NULL device for testing
edge cases.

> That way no resurrection of drm_device.platform_dev is needed (and I'd
> really like this zombie to stay dead on 2nd thought).
> 

I had a hunch this would be unpopular but I figured it was worth a
shot. I think an even cleaner solution is to allow passing of any
struct device. I'll see about reworking this.

> Sry about this yet-another-round review :-/
> -Daniel
> 

Thanks for your patience.

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

Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Laurent Pinchart]

Hi Daniel,

On Wednesday 03 May 2017 16:28:56 Daniel Vetter wrote:
> On Wed, May 03, 2017 at 12:36:06PM +0300, Laurent Pinchart wrote:
> > On Wednesday 03 May 2017 11:32:17 Daniel Vetter wrote:
> >> On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
> >>> +panel/bridge reviewers.
> >>> 
> >>> This does make things much cleaner, but it seems a bit strange to
> >>> create a drm_bridge when there isn't really a HW bridge in the display
> >>> chain (i.e, when the DSI encoder is directly connected to a DSI panel).
> >>> 
> >>> There are kms drivers that use drm_panel, but don't have simple stub
> >>> connectors that wrap around a drm_panel. They have more complicated
> >>> connector ops, and may call drm_panel_prepare() and related functions
> >>> a bit differently. We won't be able to use drm_panel_bridge for those
> >>> drivers.
> >>> 
> >>> For msm, we check whether the DSI encoder is connected directly to a
> >>> panel or an external bridge. If it's connected to an external bridge,
> >>> we skip the creation of the stub connector, and rely on the external
> >>> bridge driver to create the connector:
> >>> 
> >>> http://lxr.free-electrons.com/source/drivers/gpu/drm/msm/dsi/dsi.c#L22
> >>> 7
> >>> 
> >>> The msm solution isn't very neat, but it avoids the need to create
> >>> another bridge to glue things together.
> >> 
> >> Since I suggested this, yes I like it. And I think just unconditionally
> >> creating the panel bridge is probably even simpler, after all bridges
> >> are supposed to be chainable. I guess there's always going to be drivers
> >> where we need special handling, but I'm kinda hoping that for most cases
> >> simply plugging in a panel bridge is all that's need to glue drm_panel
> >> support into a driver. The simple pipe helpers do support bridges, and
> >> part of the goal there very much was to make it easy to glue in panel
> >> drivers.
> > 
> > As I've just explained in another reply, I don't see the point in doing
> > this when we can instead refactor the bridge and panel operations to
> > expose a common base object that will then be easy to handle in core
> > code. This isn't just for panels, as connectors should have DT nodes, it
> > makes sense to instantiate an object for them that can be handled by the
> > DRM core, without having to push connector handling in all bridge
> > drivers.
> 
> Imo you're aiming too high. We have 21 bridge drivers and 11 panel
> drivers. Asking someone to refactor them all (plus all the callers and
> everything) means it won't happen. At least I personally will definitely
> not block a contribution on this happening, that's a totally outsized
> demand.

I think you're aiming too low. When the atomic update API was introduced I 
could have told you that converting all drivers was an impossible task ;-)

Jokes aside, I believe it might be possible to implement something simple. I'm 
flexible about the naming, so instead of creating a new base structure and 
refactor drm_bridge and drm_panel to embed it, we could as a first step use 
drm_bridge as that base structure. We would only need to embed a drm_bridge 
instance in drm_panel and add a few connector-related operations to the bridge 
ops structure. As existing bridge drivers wouldn't need to provide those new 
ops, they wouldn't need to be touched.

> What we could do instead is slowly merge these two worlds together, and
> this here is definitely a step into that direction. Let's please not throw
> out useful improvements by insisting that we only merge perfect code. We
> already did merge both drm_panel and drm_bridge (plus a few more earlier
> attempts), clearly we're not only merging perfect code :-)
> 
> Or you go ahead and deliver that refactoring, that's another option ofc
> ...

It's on my to-do list for the near future actually, in order to convert the 
omapdrm-specific bridge and panel drivers into standard DRM drivers. I'd like 
to get a general agreement on the direction I'd like to take before converting 
everything though, so I'd appreciate your feedback on the thoughts above.

-- 
Regards,

Laurent Pinchart

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

Re: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init

[Liviu Dudau]

On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote:
> On 3 May 2017 at 15:07, Liviu Dudau  wrote:
> > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
> >> On 3 May 2017 at 11:34, Liviu Dudau  wrote:
> >> > You are *really* pushing your luck by not Cc-ing *any* of the 
> >> > maintainers of
> >> > the drivers you touch. You do want reviews, don't you?
> >>
> >> Ouch. I'm very sure Ben does want reviews, but he mainly works in Mesa
> >> where you can rely on the list rather than having to CC everyone
> >> individually. It was a mistake, so please be more gentle with him;
> >> your whole mail comes across as quite hostile to me.
> >
> > Sorry, I'm not trying to be hostile. Try to read the bolded words with a 
> > long
> > (southern USA) intonation as if to draw attention to them. You will see that
> > it is just pointing to two facts: he does not warn anyone about the changes 
> > and
> > he is not making the patchset that obviously critical by having a commit 
> > message
> > that implies everyone should pay attention to it. So he is really hoping to 
> > be
> > lucky to get reviews (or doesn't actively seek them).
> 
> You could achieve the same thing with absolutely no room for
> misinterpretation: 'Hi Ben. Not sure if you weren't aware or forgot,
> but when posting patches here, please use get_maintainers.pl to build
> a CC list. I only really saw this by luck, and other maintainers have
> probably missed this too.'

Agree, probably a better tone. Apologies to Ben for the initial form. I'm sure
he will do the correct thing next time.

> 
> >> It does deserve a much better commit message than what it has, but as
> >> he is on holiday for the rest of the week, I can answer. Currently, we
> >> advertise which formats each plane is capable of displaying. In order
> >> for userspace to be able to allocate tiled/compressed buffers for
> >> scanout, we want userspace to be able to discover which modifiers each
> >> plane supports as well.
> >
> > I get the overall goal. We need/want something similar for Mali DP and AFBC 
> > buffers.
> > What I don't understand is the current aproach (but I've found from Brian 
> > that somehow
> > I've missed the long discussion(s) around the subject). I was hoping to 
> > learn
> > from the commit message why he thinks the introduction of this code is the 
> > right
> > way of doing it. And the IRC logs seem to imply that he is mostly doing 
> > something
> > that others have agreed upon and he doesn't really care about the approach 
> > as long
> > as it ticks the "supported by intel driver" box.
> 
> Or, with another interpretation, he thinks the various approaches of
> doing it are all equally good. He took guidance from a couple of
> userspace developers (Weston, ChromeOS), a Freedreno developer and
> also I believe an AFBC developer, to end up where he is now, which he
> still thinks is fine. In doing so, he's been through several
> iterations, always modifying the driver to suit. I think that's a
> pretty good way to do development of new uABI, if you ask me. (And
> again, I have trouble reading your last sentence as anything other
> than hostile.)

I am getting the message. You think I am too strong here, so I'm going to back 
off.
Also look forward to see the next version where he takes into account the 
technical
comments that I have sent.

Best regards,
Liviu

-- 

| 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 1/2] drm: Introduce crtc->mode_valid() callback

[Daniel Vetter]

On Wed, May 03, 2017 at 03:16:13PM +0100, Jose Abreu wrote:
> Hi Daniel,
> 
> 
> On 03-05-2017 07:19, Daniel Vetter wrote:
> > On Tue, May 2, 2017 at 11:29 AM, Jose Abreu  wrote:
> >> On 02-05-2017 09:48, Daniel Vetter wrote:
> >>> On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote:
>  Some crtc's may have restrictions in the mode they can display. In
>  this patch a new callback (crtc->mode_valid()) is introduced that
>  is called at the same stage of connector->mode_valid() callback.
> 
>  This shall be implemented if the crtc has some sort of restriction
>  so that we don't probe modes that will fail in the commit() stage.
>  For example: A given crtc may be responsible to set a clock value.
>  If the clock can not produce all the values for the available
>  modes then this callback can be used to restrict the number of
>  probbed modes to only the ones that can be displayed.
> 
>  If the crtc does not implement the callback then the behaviour will
>  remain the same. Also, for a given set of crtcs that can be bound to
>  the connector, if at least one can display the mode then the mode
>  will be probbed.
> 
>  Signed-off-by: Jose Abreu 
>  Cc: Carlos Palminha 
>  Cc: Alexey Brodkin 
>  Cc: Ville Syrjälä 
>  Cc: Daniel Vetter 
>  Cc: Dave Airlie 
> >>> Not sure this is useful, since you still have to duplicate the exact same
> >>> check into your ->mode_fixup hook. That seems to make things even more
> >>> confusing.
> >> Yeah, in arcpgu I had to duplicate the code in ->atomic_check.
> >>
> >>> Also this doesn't update the various kerneldoc comments. For the existing
> >>> hooks. Since this topic causes so much confusion, I don't think a
> >>> half-solution will help, but has some good potential to make things worse.
> >> I only documented the callback in drm_modeset_helper_vtables.h.
> >>
> >> Despite all of this, I think it doesn't makes sense delivering
> >> modes to userspace which can never be used.
> >>
> >> This is really annoying in arcpgu. Imagine: I try to use mpv to
> >> play a video, the full set of modes from EDID were probed so if I
> >> just start mpv it will pick the native mode of the TV instead of
> >> the one that is supported, so mpv will fail to play. I know the
> >> value of clock which will work (so I know what mode shall be
> >> used), but a normal user which is not aware of the HW will have
> >> to cycle through the list of modes and try them all until it hits
> >> one that works. Its really boring.
> >>
> >> For the modes that user specifies manually there is nothing we
> >> can do, but we should not trick users into thinking that a given
> >> mode is supported when it will always fail at commit.
> > Yes, you are supposed to filter these out in ->mode_valid. But my
> > stance is that only adding a half-baked support for a new callback to
> > the core isn't going to make life easier for drivers, it will just add
> > to the confusion. There's already piles of docs for both @mode_valid
> > and @mode_fixup hooks explaining this, I don't want to make the
> > documentation even more complex. And half-baked crtc checking is
> > _much_ easier to implement in the driver directly (e.g. i915 checks
> > for crtc constraints since forever, as do the other big x86 drivers).
> 
> But i915 crtc checks are done after handing the mode to
> userspace, arcpgu also does that. We must let users specify
> manually a mode but there is no point in returning modes in
> get_connector which will always fail to commit. I get your point
> and this can lead to code duplication, but I don't think it will
> lead to confusion as long as it is well documented. And besides,
> the callback is completely optional.

Look closer, e.g. intel_dp_mode_valid calls
intel_dp_downstream_max_dotclock which also looks at
dev_priv->max_dotclkc_freq (which is the source dotclk limit, yeah it's a
misnamed function).

And the max dotclk is very much a crtc limit, not a port limit. Note that
a bunch of other ports have port limits which are guaranteed to be lower
than the crtc limit, hence the absence of the checks.

> > So all taken together, if we add a ->mode_valid to crtcs, then imo we
> > should do it right and actually make life easier for drivers. A good
> > proof would be if your patch would allow us to drop a lot of the
> > lenghty language from the @mode_valid hooks.
> 
> I completely agree that it should make life easier for drivers
> but unfortunately I don't really see how :/
> 
> So, in summary:
> Disadvantage 1: Code duplication
> Disadvantage 2: Confusing documentation can lead to callback
> misuse
> 
> Advantage 1: User will get life simpler

Ok, let me try to explain a bit in more detail what I think would be a
real improvement:
- Add ->mode_valid checks to all the places where we currently have
  ->mode_fixup. That'd be crtc, encoder and bridges.

- Pimp the probe helper code to go through all of the comb

Re: Soliciting DRM feedback on latest DC rework

[Daniel Vetter]

On Wed, May 03, 2017 at 04:26:51PM +0200, Christian König wrote:
> Hi Harry,
> 
> while this looks more and more like it could work something which would
> really help would be to have a set of patches squashed together and rebased
> on drm-next.
> 
> The dc-drm-next-atomic-wip looks like a start, but we need more something
> like:
> drm/amdgpu: add base DC components
> drm/amdgpu: add DCE8 support for DC
> drm/amdgpu: add DCE9 support for DC
> drm/amdgpu: add DCE10 support for DC
> ...
> drm/amdgpu: enable DC globally
> drm/amdgpu: remove old display infrastructure
> 
> Otherwise I fear that people will just be lost in the mass amount of patches
> we have in the branch.

I think for a quick first feedback round simply something that's based on
top of recent drm-next is good enough, since I'll probably only look at
the aggregate diff anyway (or resulting tree).
-Daniel

> 
> Regards,
> Christian.
> 
> Am 03.05.2017 um 16:13 schrieb Harry Wentland:
> > Hi all,
> > 
> > Over the last few months we (mostly Andrey and myself) have taken and
> > addressed some of the feedback received from December's DC RFC. A lot of
> > our work so far centers around atomic. We were able to take a whole
> > bunch of the areas where we rolled our own solution and use DRM atomic
> > helpers instead.
> > 
> > You can find our most recent drm-next based tree at
> > https://cgit.freedesktop.org/~hwentland/linux/log/?h=dc-drm-next-atomic-wip
> > 
> > An outline of the changes with commit hashes from that tree are listed
> > below. They aren't necessarily in order but are grouped by
> > functionality.
> > 
> > I would like to solicit input on the changes and the current state of
> > amd/display in general.
> > 
> > I'm on IRC every weekday from 9-5 eastern time, sometimes at other
> > hours. Feel free to ask questions, discuss, leave comments. Let me know
> > if there's anything else I can do to facilitate review.
> > 
> > We know there's more work to be done but would much rather prioritize
> > that work based on community feedback than merely our own impressions.
> > 
> > We haven't finished plumbing drm types to the dc types yet, and there
> > are still a bunch of other things in progress.  We are not looking to
> > re-hash the previous discussion, but rather we'd like some feedback on
> > our work so far.
> > 
> > The list of changes (trimmed commit tags):
> > 
> > == Use common helpers for pageflip ==
> > 144da239b047 Use pflip prepare and submit parts (v2)
> > ff7ac264a9a1 Fix page flip after daniel's acquire_ctx change
> > 
> > 
> > == implement atomic_get_properties ==
> > cf4a84df7189 Fallback on legacy properties in atomic_get_properties
> > 01f96706b6ca get_atomic_property missing for drm_connector_funcs
> > 
> > 
> > == Use common helpers for gamma ==
> > 3f547d7098de Use atomic helpers for gamma
> > 
> > 
> > == Use atomic helpers for commit ==
> > 41831f55bd58 Refactor atomic commit implementation. (v2)
> > 6c67dd3c5cd5 Refactor headless to use atomic commit.
> > eb22ef1ecb16 Remove page_fleep_needed function.
> > 
> > 
> > == Use atomic helpers for S3 ==
> > 5a6ae6f76249 Switch to DRM helpers in s3.
> > 
> > 
> > == Simmplify mapping between DRM and DC objects ==
> > 84a3ee023b9b Remove get_connector_for_link.
> > 6d8978a98b40 Remove get_connector_for_sink.
> > 
> > 
> > == Use DRM EDID read instead of DC ==
> > 566969dacfad Fix i2c write flag.
> > 527c3699ff3c Refactor edid read.
> > 5ac51023d275 Fix missing irq refactor causing potential i2c race
> > 
> > 
> > == Save DC validate_ctx in atomic_check and use in commit ==
> > 8c194d8e4ee9 pull commit_surfaces out of atomic_commit into helper
> > function
> > 27eef98b38c8 Return context from validate_context
> > ca3ee10e915b Add DM global atomic state
> > 8ba1ca856532 Hook dm private state into atomic_check
> > 10160455ac6d Add correct retain/release for objs in dm_atomic_state
> > 0f1b2e2aecbb Commit validation set from state
> > 258e6a91fc61 Add validate_context to atomic_state
> > 64f569b5df20 Use validate_context from atomic_check in commit
> > 
> > 
> > == Start multi-plane implementation ==
> > 601ff4e70b7c decouple per-crtc-plane model
> > a0b859a0b114 Fix cleanup in amdgpu_dm_initialize_drm_device
> > ee02010d7a82 update plane functionalities
> > 3b7345fd1abb Allow planes on all crtcs
> > d9cf37462156 initialize YUV plane capabilities
> > 248f06b2613e Universal cursor plane hook-up.
> > 
> > 
> > == Minor cleanups ==
> > d99bf02cb8fc Rename atomic_commit parameter.
> > f15fb9726502 Use amdgpu mode funcs statically
> > d3e37fa70643 Remove unused define from amdgpu_dm_types
> > 80a38ad58125 Add lock around updating freesync property
> > 8c7f16853824 Use new drm_dp_find_vcpi_slots to compute slots
> > 
> > Regards,
> > Harry
> > ___
> > amd-gfx mailing list
> > amd-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.

Re: [PATCH] drm/msm/mdp5: use __drm_atomic_helper_plane_duplicate_state()

[Daniel Vetter]

On Wed, May 03, 2017 at 10:40:36AM -0400, Rob Clark wrote:
> Somehow the helper was never retrofitted for mdp5.  Which meant when
> plane_state->fence was added, it could get copied into new state in
> mdp5_plane_duplicate_state().
> 
> If an update to disable the plane (for example on rmfb) managed to sneak
> in after an nonblock update had swapped state, but before it was
> committed, we'd get a splat:
> 
> WARNING: CPU: 1 PID: 69 at ../drivers/gpu/drm/drm_atomic_helper.c:1061 
> drm_atomic_helper_wait_for_fences+0xe0/0xf8
>Modules linked in:
> 
>CPU: 1 PID: 69 Comm: kworker/1:1 Tainted: GW   4.11.0-rc8+ 
> #1187
>Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
>Workqueue: events drm_mode_rmfb_work_fn
>task: ffc036560d00 task.stack: ffc03655
>PC is at drm_atomic_helper_wait_for_fences+0xe0/0xf8
>LR is at complete_commit.isra.1+0x44/0x1c0
>pc : [] lr : [] pstate: 2145
>sp : ffc036553b60
>x29: ffc036553b60 x28: ffc0264e6a00
>x27: ffc035659000 x26: 
>x25: ffc0240e8000 x24: 0038
>x23:  x22: ff800858f200
>x21: ffc0240e8000 x20: ffc02f56a800
>x19:  x18: 
>x17:  x16: 
>x15:  x14: ffc00a192700
>x13: 0004 x12: 
>x11: ff80089a1690 x10: 08f0
>x9 : ffc036553b20 x8 : ffc036561650
>x7 : ffc03fe6cb40 x6 : 
>x5 : 0001 x4 : 0002
>x3 : ffc035659000 x2 : ffc0240e8c80
>x1 :  x0 : ffc02adbe588
> 
>---[ end trace 13aeec77c3fb55e2 ]---
>Call trace:
>Exception stack(0xffc036553990 to 0xffc036553ac0)
>3980:    0080
>39a0: ffc036553b60 ff80084f6040 4ff0 0038
>39c0: ffc0365539d0 ff800857e098 ffc036553a00 ff800857e1b0
>39e0: ffc036553a10 ff800857c554 ffc0365e8400 ffc0365e8400
>3a00: ffc036553a20 ff8008103358 0001aad7 ff800851b72c
>3a20: ffc036553a50 ff80080e9228 ffc02adbe588 
>3a40: ffc0240e8c80 ffc035659000 0002 0001
>3a60:  ffc03fe6cb40 ffc036561650 ffc036553b20
>3a80: 08f0 ff80089a1690  0004
>3aa0: ffc00a192700   
>[] drm_atomic_helper_wait_for_fences+0xe0/0xf8
>[] complete_commit.isra.1+0x44/0x1c0
>[] msm_atomic_commit+0x32c/0x350
>[] drm_atomic_commit+0x50/0x60
>[] drm_atomic_remove_fb+0x158/0x250
>[] drm_framebuffer_remove+0x50/0x158
>[] drm_mode_rmfb_work_fn+0x40/0x58
>[] process_one_work+0x1d0/0x378
>[] worker_thread+0x244/0x488
>[] kthread+0xfc/0x128
>[] ret_from_fork+0x10/0x50
> 
> Reported-by: Stanimir Varbanov 
> Signed-off-by: Rob Clark 

Oops, but does indeed explain what's going on.

Cc: sta...@vger.kernel.org
Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> index a38c5fe..30b4691 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> @@ -225,9 +225,10 @@ mdp5_plane_duplicate_state(struct drm_plane *plane)
>  
>   mdp5_state = kmemdup(to_mdp5_plane_state(plane->state),
>   sizeof(*mdp5_state), GFP_KERNEL);
> + if (!mdp5_state)
> + return NULL;
>  
> - if (mdp5_state && mdp5_state->base.fb)
> - drm_framebuffer_reference(mdp5_state->base.fb);
> + __drm_atomic_helper_plane_duplicate_state(plane, &mdp5_state->base);
>  
>   return &mdp5_state->base;
>  }
> -- 
> 2.9.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform

[Daniel Vetter]

On Wed, May 03, 2017 at 07:40:51AM -0700, Laura Abbott wrote:
> On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> > On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> >> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> >>>  /**
> >>> + * drm_gem_prime_import_platform - alternate implementation of the 
> >>> import callback
> >>> + * @dev: drm_device to import into
> >>> + * @dma_buf: dma-buf object to import
> >>> + *
> >>> + * This is identical to drm_gem_prime_import except the device used for 
> >>> dma_buf
> >>> + * attachment is an internal platform device instead of the standard 
> >>> device
> >>> + * structure. The use of this function should be limited to drivers that 
> >>> do not
> >>> + * set up an underlying device structure.
> >>> + */
> >>> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device 
> >>> *dev,
> >>
> >> Simpler soluation will be for the caller to provide the platformdev?
> >>
> >> That works nicely for the vgem case, I think.
> > 
> > Yeah looking at this again, do we really need this patch? Couldn't we
> > instead change patch 1 to first allocate the fake platform device, then
> > pass that to drm_dev_alloc (instead of NULL like we do now)?
> > 
> 
> That was what I proposed in the first version and it was rejected.
> It's useful to have at least one driver with a NULL device for testing
> edge cases.

Oh drat :( I'd say dropping the coverage for NULL testing is ok, there's
no other driver than vgem using this. And now that we have vgem dma-buf
(or will, soonish) I'd expect that the same will hold for vkms, if it ever
happens.
-Daniel

> > That way no resurrection of drm_device.platform_dev is needed (and I'd
> > really like this zombie to stay dead on 2nd thought).
> > 
> 
> I had a hunch this would be unpopular but I figured it was worth a
> shot. I think an even cleaner solution is to allow passing of any
> struct device. I'll see about reworking this.
> 
> > Sry about this yet-another-round review :-/
> > -Daniel
> > 
> 
> Thanks for your patience.
> 
> Laura
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob

[Daniel Vetter]

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
> 
> Cc: Rob Clark 
> Cc: Daniel Stone 
> Cc: Kristian H. Kristensen 
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/drm_mode_config.c |   7 +++
>  drivers/gpu/drm/drm_plane.c   | 119 
> ++
>  include/drm/drm_mode_config.h |   6 ++
>  include/uapi/drm/drm_mode.h   |  26 +
>  4 files changed, 158 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index d9862259a2a7..6bfbc3839df5 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.gamma_lut_size_property = prop;
>  
> + prop = drm_property_create(dev,
> +DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
> +"IN_FORMATS", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.modifiers = prop;
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 286e183891e5..2e89e0e73435 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
>   return num;
>  }
>  
> +struct drm_format_modifier_blob {
> +#define FORMAT_BLOB_CURRENT 1
> + /* Version of this blob format */
> + u32 version;
> +
> + /* Flags */
> + u32 flags;
> +
> + /* Number of fourcc formats supported */
> + u32 count_formats;
> +
> + /* Where in this blob the formats exist (in bytes) */
> + u32 formats_offset;
> +
> + /* Number of drm_format_modifiers */
> + u32 count_modifiers;
> +
> + /* Where in this blob the modifiers exist (in bytes) */
> + u32 modifiers_offset;
> +
> + /* u32 formats[] */
> + /* struct drm_format_modifier modifiers[] */
> +} __packed;

The struct should be in the uapi header. Otherwise it won't show up in
libdrm headers when following the proper process.
-Daniel

> +
> +static inline u32 *
> +formats_ptr(struct drm_format_modifier_blob *blob)
> +{
> + return (u32 *)(((char *)blob) + blob->formats_offset);
> +}
> +
> +static inline struct drm_format_modifier *
> +modifiers_ptr(struct drm_format_modifier_blob *blob)
> +{
> + return (struct drm_format_modifier *)(((char *)blob) + 
> blob->modifiers_offset);
> +}
> +
> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
> *plane,
> +  const struct drm_plane_funcs *funcs,
> +  const uint32_t *formats, unsigned int 
> format_count,
> +  const uint64_t *format_modifiers)
> +{
> + const struct drm_mode_config *config = &dev->mode_config;
> + const uint64_t *temp_modifiers = format_modifiers;
> + unsigned int format_modifier_count = 0;
> + struct drm_property_blob *blob = NULL;
> + struct drm_format_modifier *mod;
> + size_t blob_size = 0, formats_size, modifiers_size;
> + struct drm_format_modifier_blob *blob_data;
> + int i, j, ret = 0;
> +
> + if (format_modifiers)
> + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> + format_modifier_count++;
> +
> + formats_size = sizeof(__u32) * format_count;
> + if (WARN_ON(!formats_size)) {
> + /* 0 formats are never expected */
> + return 0;
> + }
> +
> + modifiers_size =
> + sizeof(struct drm_format_modifier) * format_modifier_count;
> +
> + blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
> + blob_size += ALIGN(formats_size, 8);
> + blob_size += modifiers_size;
> +
> + blob = drm_property_create_blob(dev, blob_size, NULL);
> + if (IS_ERR(blob))
> + return -1;
> +
> + blob_data = (struct drm_format_modifier_blob *)blob->data;
> + blob_data->version = FORMAT_BLOB_CURRENT;
> + blob_data->count_formats = format_count;
> + blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
> + blob_data->count_modifiers = format_modifier_count;
> +
> + /* Modifiers offset is a pointer to a struct with a 64 bit field so it
> +  * should be naturally aligned to 8B.
> +  */
> + blob_data->modifiers_offset =
> + ALIGN(blob_data->formats_offset + formats_size, 8);
> +
> + memcpy(formats_ptr(blob_data), formats, formats_size);
> +
> + /* If we can't determine support, just bail */
> + if (!funcs->format_mod_supported)
> + goto done;
> +
> + mod = modifiers_ptr(blob_data);
> + for (i = 0; i < format_modifier_count; i++) {
> + for (j = 0; j < format_count; j++) {
> + if (funcs->format_mod_supp

Re: [PATCH] drm/atomic: fix doc to use new name for commit types

[Gustavo Padovan]

2017-05-02 Daniel Vetter :

> On Thu, Apr 27, 2017 at 11:35:06AM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Use "non-blocking" and "blocking" instead of old names.
> > 
> > Signed-off-by: Gustavo Padovan 
> 
> Reviewed-by: Daniel Vetter 

Thanks for the review. Pushed to drm-misc-next.

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

Re: [PATCH 1/2] drm: Introduce crtc->mode_valid() callback

[Ville Syrjälä]

On Wed, May 03, 2017 at 05:00:31PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 03:16:13PM +0100, Jose Abreu wrote:
> > Hi Daniel,
> > 
> > 
> > On 03-05-2017 07:19, Daniel Vetter wrote:
> > > On Tue, May 2, 2017 at 11:29 AM, Jose Abreu  
> > > wrote:
> > >> On 02-05-2017 09:48, Daniel Vetter wrote:
> > >>> On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote:
> >  Some crtc's may have restrictions in the mode they can display. In
> >  this patch a new callback (crtc->mode_valid()) is introduced that
> >  is called at the same stage of connector->mode_valid() callback.
> > 
> >  This shall be implemented if the crtc has some sort of restriction
> >  so that we don't probe modes that will fail in the commit() stage.
> >  For example: A given crtc may be responsible to set a clock value.
> >  If the clock can not produce all the values for the available
> >  modes then this callback can be used to restrict the number of
> >  probbed modes to only the ones that can be displayed.
> > 
> >  If the crtc does not implement the callback then the behaviour will
> >  remain the same. Also, for a given set of crtcs that can be bound to
> >  the connector, if at least one can display the mode then the mode
> >  will be probbed.
> > 
> >  Signed-off-by: Jose Abreu 
> >  Cc: Carlos Palminha 
> >  Cc: Alexey Brodkin 
> >  Cc: Ville Syrjälä 
> >  Cc: Daniel Vetter 
> >  Cc: Dave Airlie 
> > >>> Not sure this is useful, since you still have to duplicate the exact 
> > >>> same
> > >>> check into your ->mode_fixup hook. That seems to make things even more
> > >>> confusing.
> > >> Yeah, in arcpgu I had to duplicate the code in ->atomic_check.
> > >>
> > >>> Also this doesn't update the various kerneldoc comments. For the 
> > >>> existing
> > >>> hooks. Since this topic causes so much confusion, I don't think a
> > >>> half-solution will help, but has some good potential to make things 
> > >>> worse.
> > >> I only documented the callback in drm_modeset_helper_vtables.h.
> > >>
> > >> Despite all of this, I think it doesn't makes sense delivering
> > >> modes to userspace which can never be used.
> > >>
> > >> This is really annoying in arcpgu. Imagine: I try to use mpv to
> > >> play a video, the full set of modes from EDID were probed so if I
> > >> just start mpv it will pick the native mode of the TV instead of
> > >> the one that is supported, so mpv will fail to play. I know the
> > >> value of clock which will work (so I know what mode shall be
> > >> used), but a normal user which is not aware of the HW will have
> > >> to cycle through the list of modes and try them all until it hits
> > >> one that works. Its really boring.
> > >>
> > >> For the modes that user specifies manually there is nothing we
> > >> can do, but we should not trick users into thinking that a given
> > >> mode is supported when it will always fail at commit.
> > > Yes, you are supposed to filter these out in ->mode_valid. But my
> > > stance is that only adding a half-baked support for a new callback to
> > > the core isn't going to make life easier for drivers, it will just add
> > > to the confusion. There's already piles of docs for both @mode_valid
> > > and @mode_fixup hooks explaining this, I don't want to make the
> > > documentation even more complex. And half-baked crtc checking is
> > > _much_ easier to implement in the driver directly (e.g. i915 checks
> > > for crtc constraints since forever, as do the other big x86 drivers).
> > 
> > But i915 crtc checks are done after handing the mode to
> > userspace, arcpgu also does that. We must let users specify
> > manually a mode but there is no point in returning modes in
> > get_connector which will always fail to commit. I get your point
> > and this can lead to code duplication, but I don't think it will
> > lead to confusion as long as it is well documented. And besides,
> > the callback is completely optional.
> 
> Look closer, e.g. intel_dp_mode_valid calls
> intel_dp_downstream_max_dotclock which also looks at
> dev_priv->max_dotclkc_freq (which is the source dotclk limit, yeah it's a
> misnamed function).
> 
> And the max dotclk is very much a crtc limit, not a port limit. Note that
> a bunch of other ports have port limits which are guaranteed to be lower
> than the crtc limit, hence the absence of the checks.
> 
> > > So all taken together, if we add a ->mode_valid to crtcs, then imo we
> > > should do it right and actually make life easier for drivers. A good
> > > proof would be if your patch would allow us to drop a lot of the
> > > lenghty language from the @mode_valid hooks.
> > 
> > I completely agree that it should make life easier for drivers
> > but unfortunately I don't really see how :/
> > 
> > So, in summary:
> > Disadvantage 1: Code duplication
> > Disadvantage 2: Confusing documentation can lead to callback
> > misuse
> > 
> > Advantage 1: User will 

Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform

[Chris Wilson]

On Wed, May 03, 2017 at 05:07:03PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 07:40:51AM -0700, Laura Abbott wrote:
> > On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> > > On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> > >> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> > >>>  /**
> > >>> + * drm_gem_prime_import_platform - alternate implementation of the 
> > >>> import callback
> > >>> + * @dev: drm_device to import into
> > >>> + * @dma_buf: dma-buf object to import
> > >>> + *
> > >>> + * This is identical to drm_gem_prime_import except the device used 
> > >>> for dma_buf
> > >>> + * attachment is an internal platform device instead of the standard 
> > >>> device
> > >>> + * structure. The use of this function should be limited to drivers 
> > >>> that do not
> > >>> + * set up an underlying device structure.
> > >>> + */
> > >>> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device 
> > >>> *dev,
> > >>
> > >> Simpler soluation will be for the caller to provide the platformdev?
> > >>
> > >> That works nicely for the vgem case, I think.
> > > 
> > > Yeah looking at this again, do we really need this patch? Couldn't we
> > > instead change patch 1 to first allocate the fake platform device, then
> > > pass that to drm_dev_alloc (instead of NULL like we do now)?
> > > 
> > 
> > That was what I proposed in the first version and it was rejected.
> > It's useful to have at least one driver with a NULL device for testing
> > edge cases.
> 
> Oh drat :( I'd say dropping the coverage for NULL testing is ok, there's
> no other driver than vgem using this. And now that we have vgem dma-buf
> (or will, soonish) I'd expect that the same will hold for vkms, if it ever
> happens.

This series creates vgem->platformdev which we can just pass to
drm_gem_prime_import_platform() (or equivalent drm_gem_prime function that
takes an explicit dev). It was a bit of a surprise that import_platform
didn't take the platformdev after going to the trouble of creating
vgem->platformdev.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/msm/mdp5: use __drm_atomic_helper_plane_duplicate_state()

[Rob Clark]

On Wed, May 3, 2017 at 11:04 AM, Daniel Vetter  wrote:
> On Wed, May 03, 2017 at 10:40:36AM -0400, Rob Clark wrote:
>> Somehow the helper was never retrofitted for mdp5.  Which meant when
>> plane_state->fence was added, it could get copied into new state in
>> mdp5_plane_duplicate_state().
>>
>> If an update to disable the plane (for example on rmfb) managed to sneak
>> in after an nonblock update had swapped state, but before it was
>> committed, we'd get a splat:
>>
>> WARNING: CPU: 1 PID: 69 at ../drivers/gpu/drm/drm_atomic_helper.c:1061 
>> drm_atomic_helper_wait_for_fences+0xe0/0xf8
>>Modules linked in:
>>
>>CPU: 1 PID: 69 Comm: kworker/1:1 Tainted: GW   4.11.0-rc8+ 
>> #1187
>>Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
>>Workqueue: events drm_mode_rmfb_work_fn
>>task: ffc036560d00 task.stack: ffc03655
>>PC is at drm_atomic_helper_wait_for_fences+0xe0/0xf8
>>LR is at complete_commit.isra.1+0x44/0x1c0
>>pc : [] lr : [] pstate: 2145
>>sp : ffc036553b60
>>x29: ffc036553b60 x28: ffc0264e6a00
>>x27: ffc035659000 x26: 
>>x25: ffc0240e8000 x24: 0038
>>x23:  x22: ff800858f200
>>x21: ffc0240e8000 x20: ffc02f56a800
>>x19:  x18: 
>>x17:  x16: 
>>x15:  x14: ffc00a192700
>>x13: 0004 x12: 
>>x11: ff80089a1690 x10: 08f0
>>x9 : ffc036553b20 x8 : ffc036561650
>>x7 : ffc03fe6cb40 x6 : 
>>x5 : 0001 x4 : 0002
>>x3 : ffc035659000 x2 : ffc0240e8c80
>>x1 :  x0 : ffc02adbe588
>>
>>---[ end trace 13aeec77c3fb55e2 ]---
>>Call trace:
>>Exception stack(0xffc036553990 to 0xffc036553ac0)
>>3980:    0080
>>39a0: ffc036553b60 ff80084f6040 4ff0 0038
>>39c0: ffc0365539d0 ff800857e098 ffc036553a00 ff800857e1b0
>>39e0: ffc036553a10 ff800857c554 ffc0365e8400 ffc0365e8400
>>3a00: ffc036553a20 ff8008103358 0001aad7 ff800851b72c
>>3a20: ffc036553a50 ff80080e9228 ffc02adbe588 
>>3a40: ffc0240e8c80 ffc035659000 0002 0001
>>3a60:  ffc03fe6cb40 ffc036561650 ffc036553b20
>>3a80: 08f0 ff80089a1690  0004
>>3aa0: ffc00a192700   
>>[] drm_atomic_helper_wait_for_fences+0xe0/0xf8
>>[] complete_commit.isra.1+0x44/0x1c0
>>[] msm_atomic_commit+0x32c/0x350
>>[] drm_atomic_commit+0x50/0x60
>>[] drm_atomic_remove_fb+0x158/0x250
>>[] drm_framebuffer_remove+0x50/0x158
>>[] drm_mode_rmfb_work_fn+0x40/0x58
>>[] process_one_work+0x1d0/0x378
>>[] worker_thread+0x244/0x488
>>[] kthread+0xfc/0x128
>>[] ret_from_fork+0x10/0x50
>>
>> Reported-by: Stanimir Varbanov 
>> Signed-off-by: Rob Clark 
>

I've also added:

Fixes: 9626014 ("drm/fence: add in-fences support")

(so folks know which stable branches it should end up in)

BR,
-R

> Oops, but does indeed explain what's going on.
>
> Cc: sta...@vger.kernel.org
> Reviewed-by: Daniel Vetter 
>
>> ---
>>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
>> index a38c5fe..30b4691 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
>> @@ -225,9 +225,10 @@ mdp5_plane_duplicate_state(struct drm_plane *plane)
>>
>>   mdp5_state = kmemdup(to_mdp5_plane_state(plane->state),
>>   sizeof(*mdp5_state), GFP_KERNEL);
>> + if (!mdp5_state)
>> + return NULL;
>>
>> - if (mdp5_state && mdp5_state->base.fb)
>> - drm_framebuffer_reference(mdp5_state->base.fb);
>> + __drm_atomic_helper_plane_duplicate_state(plane, &mdp5_state->base);
>>
>>   return &mdp5_state->base;
>>  }
>> --
>> 2.9.3
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] drm/etnaviv: Reuse dma_fence_release.

[Eric Anholt]

Lucas Stach  writes:

> Hi Eric,
>
> Am Mittwoch, den 12.04.2017, 12:12 -0700 schrieb Eric Anholt:
>> If we follow the typical pattern of the base class being the first
>> member, we can use the default dma_fence_free function.
>
> Sorry, I don't like this change.
> While it provides a bit of code simplification, it also bakes the
> implicit assumption into the code that dma_fence is the first struct
> member without any checks to validate this assumption. I would at least
> expect a build bug assert, but then the current bit of code to keep this
> explicit and self-documenting is probably just as good.

Fine with me.  Please make sure you grab patch 2, though.


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

[PATCH] gpu: ipu-v3: prg: remove counter load enable

[Lucas Stach]

The counter load enable bit has no effect when the shadow register
set is activated. As we always operate the PRG with shadow enabled
it is safe to remove this.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/ipu-v3/ipu-prg.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index caca57febbd6..ecc9ea44dc50 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -318,8 +318,6 @@ int ipu_prg_channel_configure(struct ipuv3_channel 
*ipu_chan,
writel(val, prg->regs + IPU_PRG_BADDR(prg_chan));
 
val = readl(prg->regs + IPU_PRG_CTL);
-   /* counter load enable */
-   val |= IPU_PRG_CTL_CNT_LOAD_EN(prg_chan);
/* config AXI ID */
val &= ~(IPU_PRG_CTL_SOFT_ARID_MASK <<
 IPU_PRG_CTL_SOFT_ARID_SHIFT(prg_chan));
-- 
2.11.0

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

Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Eric Anholt]

Laurent Pinchart  writes:

> Hi Daniel,
>
> On Wednesday 03 May 2017 16:28:56 Daniel Vetter wrote:
>> On Wed, May 03, 2017 at 12:36:06PM +0300, Laurent Pinchart wrote:
>> > On Wednesday 03 May 2017 11:32:17 Daniel Vetter wrote:
>> >> On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
>> >>> +panel/bridge reviewers.
>> >>> 
>> >>> This does make things much cleaner, but it seems a bit strange to
>> >>> create a drm_bridge when there isn't really a HW bridge in the display
>> >>> chain (i.e, when the DSI encoder is directly connected to a DSI panel).
>> >>> 
>> >>> There are kms drivers that use drm_panel, but don't have simple stub
>> >>> connectors that wrap around a drm_panel. They have more complicated
>> >>> connector ops, and may call drm_panel_prepare() and related functions
>> >>> a bit differently. We won't be able to use drm_panel_bridge for those
>> >>> drivers.
>> >>> 
>> >>> For msm, we check whether the DSI encoder is connected directly to a
>> >>> panel or an external bridge. If it's connected to an external bridge,
>> >>> we skip the creation of the stub connector, and rely on the external
>> >>> bridge driver to create the connector:
>> >>> 
>> >>> http://lxr.free-electrons.com/source/drivers/gpu/drm/msm/dsi/dsi.c#L22
>> >>> 7
>> >>> 
>> >>> The msm solution isn't very neat, but it avoids the need to create
>> >>> another bridge to glue things together.
>> >> 
>> >> Since I suggested this, yes I like it. And I think just unconditionally
>> >> creating the panel bridge is probably even simpler, after all bridges
>> >> are supposed to be chainable. I guess there's always going to be drivers
>> >> where we need special handling, but I'm kinda hoping that for most cases
>> >> simply plugging in a panel bridge is all that's need to glue drm_panel
>> >> support into a driver. The simple pipe helpers do support bridges, and
>> >> part of the goal there very much was to make it easy to glue in panel
>> >> drivers.
>> > 
>> > As I've just explained in another reply, I don't see the point in doing
>> > this when we can instead refactor the bridge and panel operations to
>> > expose a common base object that will then be easy to handle in core
>> > code. This isn't just for panels, as connectors should have DT nodes, it
>> > makes sense to instantiate an object for them that can be handled by the
>> > DRM core, without having to push connector handling in all bridge
>> > drivers.
>> 
>> Imo you're aiming too high. We have 21 bridge drivers and 11 panel
>> drivers. Asking someone to refactor them all (plus all the callers and
>> everything) means it won't happen. At least I personally will definitely
>> not block a contribution on this happening, that's a totally outsized
>> demand.
>
> I think you're aiming too low. When the atomic update API was introduced I 
> could have told you that converting all drivers was an impossible task ;-)
>
> Jokes aside, I believe it might be possible to implement something simple. 
> I'm 
> flexible about the naming, so instead of creating a new base structure and 
> refactor drm_bridge and drm_panel to embed it, we could as a first step use 
> drm_bridge as that base structure. We would only need to embed a drm_bridge 
> instance in drm_panel and add a few connector-related operations to the 
> bridge 
> ops structure. As existing bridge drivers wouldn't need to provide those new 
> ops, they wouldn't need to be touched.

I think drm_bridge itself should be the base structure, as it is today.
It's got the entrypoints we want, connected in at the right level in the
modeset chain.  You could call it the "drm_display_chain_link" or
something, but "bridge" is short and I don't think renaming is worth the
trouble.  This helper just makes it easy to make one of these display
chain links for the endpoint of your display chain when it's a
drm_panel.

One of the followons I'd like to see after this is to make a helper that
drivers get to use that does the "grab a bridge?  no?  grab a panel?
Ok? wrap it in a bridge" pattern.  Then the drm_panel/drm_connector are
an implementation detail of whatever is at the end of the chain, and not
something that the middle of the chain needs to know about.

The alternative to that that I see would be to have panel drivers call
this code to advertise themselves through the list of bridges.


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

[PATCH 3/4] drm/imx: add FB modifier support

[Lucas Stach]

This adds FB modifier support for the Vivante single buffer tiled formats,
when the PRG/PRE engines are present.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/imx/imx-drm-core.c |  1 +
 drivers/gpu/drm/imx/ipuv3-plane.c  | 55 ++
 2 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 50add2f9e250..d21e7db95979 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -266,6 +266,7 @@ static int imx_drm_bind(struct device *dev)
drm->mode_config.max_height = 4096;
drm->mode_config.funcs = &imx_drm_mode_config_funcs;
drm->mode_config.helper_private = &imx_drm_mode_config_helpers;
+   drm->mode_config.allow_fb_modifiers = true;
 
drm_mode_config_init(drm);
 
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 705ca93847ff..44593dd6ba31 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -527,7 +527,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
  drm_rect_height(&state->src) >> 16,
  state->fb->pitches[0],
  state->fb->format->format,
- 0,
+ state->fb->modifier,
  &eba);
}
 
@@ -673,17 +673,62 @@ int ipu_planes_assign_pre(struct drm_device *dev,
  struct drm_atomic_state *state)
 {
struct drm_plane_state *plane_state;
+   struct ipu_plane_state *ipu_state;
+   struct ipu_plane *ipu_plane;
struct drm_plane *plane;
int available_pres = ipu_prg_max_active_channels();
int i;
 
+   /*
+* We are going over the planes in 2 passes: first we assign PREs to
+* planes with a tiling modifier, which need the PREs to resolve into
+* linear. Any failure to assign a PRE there is fatal. In the second
+* pass we try to assign PREs to linear FBs, to improve memory access
+* patterns for them. Failure at this point is non-fatal, as we can
+* scan out linear FBs without a PRE.
+*/
for_each_plane_in_state(state, plane, plane_state, i) {
-   struct ipu_plane_state *ipu_state =
-   to_ipu_plane_state(plane_state);
-   struct ipu_plane *ipu_plane = to_ipu_plane(plane);
+   ipu_state = to_ipu_plane_state(plane_state);
+   ipu_plane = to_ipu_plane(plane);
+
+   if (!plane_state->fb) {
+   ipu_state->use_pre = false;
+   continue;
+   }
+
+   if (!(plane_state->fb->flags & DRM_MODE_FB_MODIFIERS) ||
+   plane_state->fb->modifier == DRM_FORMAT_MOD_LINEAR)
+   continue;
+
+   if (!ipu_prg_present(ipu_plane->ipu) || !available_pres)
+   return -EINVAL;
+
+   if (!ipu_prg_format_supported(ipu_plane->ipu,
+ plane_state->fb->format->format,
+ plane_state->fb->modifier))
+   return -EINVAL;
+
+   ipu_state->use_pre = true;
+   available_pres--;
+   }
+
+   for_each_plane_in_state(state, plane, plane_state, i) {
+   ipu_state = to_ipu_plane_state(plane_state);
+   ipu_plane = to_ipu_plane(plane);
+
+   if (!plane_state->fb) {
+   ipu_state->use_pre = false;
+   continue;
+   }
+
+   if ((plane_state->fb->flags & DRM_MODE_FB_MODIFIERS) &&
+   plane_state->fb->modifier != DRM_FORMAT_MOD_LINEAR)
+   continue;
+
+   /* make sure that modifier is initialized */
+   plane_state->fb->modifier = DRM_FORMAT_MOD_LINEAR;
 
if (ipu_prg_present(ipu_plane->ipu) && available_pres &&
-   plane_state->fb &&
ipu_prg_format_supported(ipu_plane->ipu,
 plane_state->fb->format->format,
 plane_state->fb->modifier)) {
-- 
2.11.0

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

[PATCH 0/4] IPu tiled scanout support

[Lucas Stach]

This adds the required bits to the ipu-v3 and imx-drm driver to make
scanout of the Vivante (super-)tiled single buffer format work on
i.MX6 QuadPlus. A userspace taking advantage of this support is able
to skip the linear resolve step in the GPU, saving quite a lot of memory
bandwidth especially with higher resolution displays.

The first 3 patches can go in as-is, while the last patch depends on
Ben Widawsky's series to add a format modifier blob property to the
DRM planes.

Regards,
Lucas

Lucas Stach (4):
  gpu: ipu-v3: pre: add tiled prefetch support
  gpu: ipu-v3: prg: add modifier support
  drm/imx: add FB modifier support
  drm/imx: advertise supported plane format modifiers

 drivers/gpu/drm/imx/imx-drm-core.c |  1 +
 drivers/gpu/drm/imx/ipuv3-plane.c  | 92 +++---
 drivers/gpu/ipu-v3/ipu-pre.c   | 24 +-
 drivers/gpu/ipu-v3/ipu-prg.c   | 13 --
 drivers/gpu/ipu-v3/ipu-prv.h   |  4 +-
 include/video/imx-ipu-v3.h |  2 +-
 6 files changed, 122 insertions(+), 14 deletions(-)

-- 
2.11.0

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

[PATCH 1/4] gpu: ipu-v3: pre: add tiled prefetch support

[Lucas Stach]

This configures the TPR unit, using the DRM format modifier. For now only
the single buffer modifiers are supported, as split buffer needs more
configuration for the required cropping.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/ipu-v3/ipu-pre.c | 24 ++--
 drivers/gpu/ipu-v3/ipu-prg.c |  2 +-
 drivers/gpu/ipu-v3/ipu-prv.h |  4 ++--
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c
index c55563379e2e..d895f92d8d33 100644
--- a/drivers/gpu/ipu-v3/ipu-pre.c
+++ b/drivers/gpu/ipu-v3/ipu-pre.c
@@ -49,6 +49,10 @@
 #define IPU_PRE_TPR_CTRL   0x070
 #define  IPU_PRE_TPR_CTRL_TILE_FORMAT(v)   ((v & 0xff) << 0)
 #define  IPU_PRE_TPR_CTRL_TILE_FORMAT_MASK 0xff
+#define  IPU_PRE_TPR_CTRL_TILE_FORMAT_16_BIT   (1 << 0)
+#define  IPU_PRE_TPR_CTRL_TILE_FORMAT_SPLIT_BUF(1 << 4)
+#define  IPU_PRE_TPR_CTRL_TILE_FORMAT_SINGLE_BUF   (1 << 5)
+#define  IPU_PRE_TPR_CTRL_TILE_FORMAT_SUPER_TILED  (1 << 6)
 
 #define IPU_PRE_PREFETCH_ENG_CTRL  0x080
 #define  IPU_PRE_PREF_ENG_CTRL_PREFETCH_EN (1 << 0)
@@ -140,7 +144,7 @@ int ipu_pre_get(struct ipu_pre *pre)
val = IPU_PRE_CTRL_HANDSHAKE_ABORT_SKIP_EN |
  IPU_PRE_CTRL_HANDSHAKE_EN |
  IPU_PRE_CTRL_TPR_REST_SEL |
- IPU_PRE_CTRL_BLOCK_16 | IPU_PRE_CTRL_SDW_UPDATE;
+ IPU_PRE_CTRL_SDW_UPDATE;
writel(val, pre->regs + IPU_PRE_CTRL);
 
pre->in_use = true;
@@ -161,7 +165,7 @@ void ipu_pre_put(struct ipu_pre *pre)
 
 void ipu_pre_configure(struct ipu_pre *pre, unsigned int width,
   unsigned int height, unsigned int stride, u32 format,
-  unsigned int bufaddr)
+  uint64_t modifier, unsigned int bufaddr)
 {
const struct drm_format_info *info = drm_format_info(format);
u32 active_bpp = info->cpp[0] >> 1;
@@ -198,9 +202,25 @@ void ipu_pre_configure(struct ipu_pre *pre, unsigned int 
width,
 
writel(pre->buffer_paddr, pre->regs + IPU_PRE_STORE_ENG_ADDR);
 
+   val = readl(pre->regs + IPU_PRE_TPR_CTRL);
+   val &= ~IPU_PRE_TPR_CTRL_TILE_FORMAT_MASK;
+   if (modifier != DRM_FORMAT_MOD_LINEAR) {
+   /* only support single buffer formats for now */
+   val |= IPU_PRE_TPR_CTRL_TILE_FORMAT_SINGLE_BUF;
+   if (modifier == DRM_FORMAT_MOD_VIVANTE_SUPER_TILED)
+   val |= IPU_PRE_TPR_CTRL_TILE_FORMAT_SUPER_TILED;
+   if (info->cpp[0] == 2)
+   val |= IPU_PRE_TPR_CTRL_TILE_FORMAT_16_BIT;
+   }
+   writel(val, pre->regs + IPU_PRE_TPR_CTRL);
+
val = readl(pre->regs + IPU_PRE_CTRL);
val |= IPU_PRE_CTRL_EN_REPEAT | IPU_PRE_CTRL_ENABLE |
   IPU_PRE_CTRL_SDW_UPDATE;
+   if (modifier == DRM_FORMAT_MOD_LINEAR)
+   val &= ~IPU_PRE_CTRL_BLOCK_EN;
+   else
+   val |= IPU_PRE_CTRL_BLOCK_EN;
writel(val, pre->regs + IPU_PRE_CTRL);
 }
 
diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index ecc9ea44dc50..454b1f1eb5df 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -295,7 +295,7 @@ int ipu_prg_channel_configure(struct ipuv3_channel 
*ipu_chan,
return ret;
 
ipu_pre_configure(prg->pres[chan->used_pre],
- width, height, stride, format, *eba);
+ width, height, stride, format, 0, *eba);
 
 
ret = clk_prepare_enable(prg->clk_ipg);
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index ca2a223a0d1e..11be49de2eba 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -274,8 +274,8 @@ int ipu_pre_get(struct ipu_pre *pre);
 void ipu_pre_put(struct ipu_pre *pre);
 u32 ipu_pre_get_baddr(struct ipu_pre *pre);
 void ipu_pre_configure(struct ipu_pre *pre, unsigned int width,
-  unsigned int height,
-  unsigned int stride, u32 format, unsigned int bufaddr);
+  unsigned int height, unsigned int stride, u32 format,
+  uint64_t modifier, unsigned int bufaddr);
 void ipu_pre_update(struct ipu_pre *pre, unsigned int bufaddr);
 
 struct ipu_prg *ipu_prg_lookup_by_phandle(struct device *dev, const char *name,
-- 
2.11.0

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

[PATCH 2/4] gpu: ipu-v3: prg: add modifier support

[Lucas Stach]

Allow to pass through the modifier to the PRE unit and extend the
format check with the supported modifiers.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/imx/ipuv3-plane.c |  4 +++-
 drivers/gpu/ipu-v3/ipu-prg.c  | 13 ++---
 include/video/imx-ipu-v3.h|  2 +-
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 6c708c3b1cdc..705ca93847ff 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -526,7 +526,9 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
  drm_rect_width(&state->src) >> 16,
  drm_rect_height(&state->src) >> 16,
  state->fb->pitches[0],
- state->fb->format->format, &eba);
+ state->fb->format->format,
+ 0,
+ &eba);
}
 
if (old_state->fb && !drm_atomic_crtc_needs_modeset(crtc_state)) {
diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index 454b1f1eb5df..22d36dba09dc 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -131,7 +131,14 @@ bool ipu_prg_format_supported(struct ipu_soc *ipu, 
uint32_t format,
if (info->num_planes != 1)
return false;
 
-   return true;
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case DRM_FORMAT_MOD_VIVANTE_TILED:
+   case DRM_FORMAT_MOD_VIVANTE_SUPER_TILED:
+   return true;
+   default:
+   return false;
+   }
 }
 EXPORT_SYMBOL_GPL(ipu_prg_format_supported);
 
@@ -274,7 +281,7 @@ EXPORT_SYMBOL_GPL(ipu_prg_channel_disable);
 int ipu_prg_channel_configure(struct ipuv3_channel *ipu_chan,
  unsigned int axi_id, unsigned int width,
  unsigned int height, unsigned int stride,
- u32 format, unsigned long *eba)
+ u32 format, uint64_t modifier, unsigned long *eba)
 {
int prg_chan = ipu_prg_ipu_to_prg_chan(ipu_chan->num);
struct ipu_prg *prg = ipu_chan->ipu->prg_priv;
@@ -295,7 +302,7 @@ int ipu_prg_channel_configure(struct ipuv3_channel 
*ipu_chan,
return ret;
 
ipu_pre_configure(prg->pres[chan->used_pre],
- width, height, stride, format, 0, *eba);
+ width, height, stride, format, modifier, *eba);
 
 
ret = clk_prepare_enable(prg->clk_ipg);
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 8cb07680fb41..755728cf58d8 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -343,7 +343,7 @@ void ipu_prg_channel_disable(struct ipuv3_channel 
*ipu_chan);
 int ipu_prg_channel_configure(struct ipuv3_channel *ipu_chan,
  unsigned int axi_id,  unsigned int width,
  unsigned int height, unsigned int stride,
- u32 format, unsigned long *eba);
+ u32 format, uint64_t modifier, unsigned long 
*eba);
 
 /*
  * IPU CMOS Sensor Interface (csi) functions
-- 
2.11.0

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

[PATCH 4/4] drm/imx: advertise supported plane format modifiers

[Lucas Stach]

Let userspace know about the supported modifiers, to make automatic
selection of a proper modifier possible.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 44593dd6ba31..8b54fcb4ae5c 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -76,6 +76,18 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_BGRX_A8,
 };
 
+static const uint64_t ipu_format_modifiers[] = {
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
+static const uint64_t pre_format_modifiers[] = {
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_VIVANTE_TILED,
+   DRM_FORMAT_MOD_VIVANTE_SUPER_TILED,
+   DRM_FORMAT_MOD_INVALID
+};
+
 int ipu_plane_irq(struct ipu_plane *ipu_plane)
 {
return ipu_idmac_channel_irq(ipu_plane->ipu, ipu_plane->ipu_ch,
@@ -302,6 +314,22 @@ void ipu_plane_destroy_state(struct drm_plane *plane,
kfree(ipu_state);
 }
 
+static bool ipu_plane_format_mod_supported(struct drm_plane *plane,
+  uint32_t format, uint64_t modifier)
+{
+   struct ipu_soc *ipu = to_ipu_plane(plane)->ipu;
+
+   /* linear is supported for all planes and formats */
+   if (modifier == DRM_FORMAT_MOD_LINEAR)
+   return true;
+
+   /* without a PRG there are no supported modifiers */
+   if (!ipu_prg_present(ipu))
+   return false;
+
+   return ipu_prg_format_supported(ipu, format, modifier);
+}
+
 static const struct drm_plane_funcs ipu_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
@@ -309,6 +337,7 @@ static const struct drm_plane_funcs ipu_plane_funcs = {
.reset  = ipu_plane_state_reset,
.atomic_duplicate_state = ipu_plane_duplicate_state,
.atomic_destroy_state   = ipu_plane_destroy_state,
+   .format_mod_supported = ipu_plane_format_mod_supported,
 };
 
 static int ipu_plane_atomic_check(struct drm_plane *plane,
@@ -748,6 +777,7 @@ struct ipu_plane *ipu_plane_init(struct drm_device *dev, 
struct ipu_soc *ipu,
 enum drm_plane_type type)
 {
struct ipu_plane *ipu_plane;
+   const uint64_t *modifiers = ipu_format_modifiers;
int ret;
 
DRM_DEBUG_KMS("channel %d, dp flow %d, possible_crtcs=0x%x\n",
@@ -763,10 +793,13 @@ struct ipu_plane *ipu_plane_init(struct drm_device *dev, 
struct ipu_soc *ipu,
ipu_plane->dma = dma;
ipu_plane->dp_flow = dp;
 
+   if (ipu_prg_present(ipu))
+   modifiers = pre_format_modifiers;
+
ret = drm_universal_plane_init(dev, &ipu_plane->base, possible_crtcs,
   &ipu_plane_funcs, ipu_plane_formats,
   ARRAY_SIZE(ipu_plane_formats),
-  NULL, type, NULL);
+  modifiers, type, NULL);
if (ret) {
DRM_ERROR("failed to initialize plane\n");
kfree(ipu_plane);
-- 
2.11.0

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

Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Eric Anholt]

Archit Taneja  writes:

> Hi,
>
> On 04/27/2017 10:06 PM, Eric Anholt wrote:
>> Many DRM drivers have common code to make a stub connector
>> implementation that wraps a drm_panel.  By wrapping the panel in a DRM
>> bridge, all of the connector code (including calls during encoder
>> enable/disable) goes away.
>>
>> Signed-off-by: Eric Anholt 
>> ---
>>  Documentation/gpu/drm-kms-helpers.rst |   3 +
>>  drivers/gpu/drm/bridge/Kconfig|  11 +-
>>  drivers/gpu/drm/bridge/Makefile   |   1 +
>>  drivers/gpu/drm/bridge/lvds-encoder.c | 158 
>>  drivers/gpu/drm/bridge/panel.c| 188 
>> ++
>>  include/drm/drm_bridge.h  |   8 ++
>>  6 files changed, 228 insertions(+), 141 deletions(-)
>>  create mode 100644 drivers/gpu/drm/bridge/panel.c
>>
>> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
>> b/Documentation/gpu/drm-kms-helpers.rst
>> index c075aadd7078..60eb3b41702b 100644
>> --- a/Documentation/gpu/drm-kms-helpers.rst
>> +++ b/Documentation/gpu/drm-kms-helpers.rst
>> @@ -143,6 +143,9 @@ Bridge Helper Reference
>>  .. kernel-doc:: drivers/gpu/drm/drm_bridge.c
>> :export:
>>
>> +.. kernel-doc:: drivers/gpu/drm/bridge/panel.c
>> +   :export:
>> +
>>  .. _drm_panel_helper:
>>
>>  Panel Helper Reference
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index f6968d3b4b41..c4daca38743c 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -4,6 +4,14 @@ config DRM_BRIDGE
>>  help
>>Bridge registration and lookup framework.
>>
>> +config DRM_PANEL_BRIDGE
>> +def_bool y
>> +depends on DRM_BRIDGE
>> +select DRM_KMS_HELPER
>> +select DRM_PANEL
>> +help
>> +  DRM bridge wrapper of DRM panels
>> +
>>  menu "Display Interface Bridges"
>>  depends on DRM && DRM_BRIDGE
>>
>> @@ -27,8 +35,7 @@ config DRM_DUMB_VGA_DAC
>>  config DRM_LVDS_ENCODER
>>  tristate "Transparent parallel to LVDS encoder support"
>>  depends on OF
>> -select DRM_KMS_HELPER
>> -select DRM_PANEL
>> +select DRM_PANEL_BRIDGE
>>  help
>>Support for transparent parallel to LVDS encoders that don't require
>>any configuration.
>> diff --git a/drivers/gpu/drm/bridge/Makefile 
>> b/drivers/gpu/drm/bridge/Makefile
>> index 3fe2226ee2f2..40a43750ad55 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
>>  obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
>>  obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
>> megachips-stdp-ge-b850v3-fw.o
>>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>> +obj-$(CONFIG_DRM_PANEL_BRIDGE) += panel.o
>>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>>  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
>>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
>> diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
>> b/drivers/gpu/drm/bridge/lvds-encoder.c
>> index f1f67a279426..04e1504c4d8f 100644
>> --- a/drivers/gpu/drm/bridge/lvds-encoder.c
>> +++ b/drivers/gpu/drm/bridge/lvds-encoder.c
>> @@ -8,144 +8,18 @@
>>   */
>>
>>  #include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> +#include 
>>  #include 
>>
>>  #include 
>>
>> -struct lvds_encoder {
>> -struct device *dev;
>> -
>> -struct drm_bridge bridge;
>> -struct drm_connector connector;
>> -struct drm_panel *panel;
>> -};
>> -
>> -static inline struct lvds_encoder *
>> -drm_bridge_to_lvds_encoder(struct drm_bridge *bridge)
>> -{
>> -return container_of(bridge, struct lvds_encoder, bridge);
>> -}
>> -
>> -static inline struct lvds_encoder *
>> -drm_connector_to_lvds_encoder(struct drm_connector *connector)
>> -{
>> -return container_of(connector, struct lvds_encoder, connector);
>> -}
>> -
>> -static int lvds_connector_get_modes(struct drm_connector *connector)
>> -{
>> -struct lvds_encoder *lvds = drm_connector_to_lvds_encoder(connector);
>> -
>> -return drm_panel_get_modes(lvds->panel);
>> -}
>> -
>> -static const struct drm_connector_helper_funcs lvds_connector_helper_funcs 
>> = {
>> -.get_modes = lvds_connector_get_modes,
>> -};
>> -
>> -static const struct drm_connector_funcs lvds_connector_funcs = {
>> -.dpms = drm_atomic_helper_connector_dpms,
>> -.reset = drm_atomic_helper_connector_reset,
>> -.fill_modes = drm_helper_probe_single_connector_modes,
>> -.destroy = drm_connector_cleanup,
>> -.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>> -.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> -};
>> -
>> -static int lvds_encoder_attach(struct drm_bridge *bridge)
>> -{
>> -struct lvds_encoder *lvds = drm_bridge_to_lvds_encoder(bridge);
>> -struct drm_connector *connector = &lvds->connector;
>> -int ret;
>> -
>> -if (!bridge->encoder) {
>> -DRM_ERROR("Missing encoder\n");
>>

Re: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init

[Daniel Vetter]

On Wed, May 03, 2017 at 03:52:23PM +0100, Liviu Dudau wrote:
> On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote:
> > On 3 May 2017 at 15:07, Liviu Dudau  wrote:
> > > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
> > >> It does deserve a much better commit message than what it has, but as
> > >> he is on holiday for the rest of the week, I can answer. Currently, we
> > >> advertise which formats each plane is capable of displaying. In order
> > >> for userspace to be able to allocate tiled/compressed buffers for
> > >> scanout, we want userspace to be able to discover which modifiers each
> > >> plane supports as well.
> > >
> > > I get the overall goal. We need/want something similar for Mali DP and 
> > > AFBC buffers.
> > > What I don't understand is the current aproach (but I've found from Brian 
> > > that somehow
> > > I've missed the long discussion(s) around the subject). I was hoping to 
> > > learn
> > > from the commit message why he thinks the introduction of this code is 
> > > the right
> > > way of doing it. And the IRC logs seem to imply that he is mostly doing 
> > > something
> > > that others have agreed upon and he doesn't really care about the 
> > > approach as long
> > > as it ticks the "supported by intel driver" box.
> > 
> > Or, with another interpretation, he thinks the various approaches of
> > doing it are all equally good. He took guidance from a couple of
> > userspace developers (Weston, ChromeOS), a Freedreno developer and
> > also I believe an AFBC developer, to end up where he is now, which he
> > still thinks is fine. In doing so, he's been through several
> > iterations, always modifying the driver to suit. I think that's a
> > pretty good way to do development of new uABI, if you ask me. (And
> > again, I have trouble reading your last sentence as anything other
> > than hostile.)
> 
> I am getting the message. You think I am too strong here, so I'm going to 
> back off.
> Also look forward to see the next version where he takes into account the 
> technical
> comments that I have sent.

Just to make it really clear: Google has an implementation for AFBC using
exactly this scheme for cros. The only reasons it's not floating around
here in upstream is that one of the critical pieces is missing (*hint*,
*hint* you really want an open mail driver ...). But besides that, it works
perfectly fine for arm render compression format too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] drm/imx: add FB modifier support

[Daniel Stone]

Hi Lucas,

On 3 May 2017 at 17:28, Lucas Stach  wrote:
> int available_pres = ipu_prg_max_active_channels();
> int i;
>
> +   /*
> +* We are going over the planes in 2 passes: first we assign PREs to
> +* planes with a tiling modifier, which need the PREs to resolve into
> +* linear. Any failure to assign a PRE there is fatal. In the second
> +* pass we try to assign PREs to linear FBs, to improve memory access
> +* patterns for them. Failure at this point is non-fatal, as we can
> +* scan out linear FBs without a PRE.
> +*/
> for_each_plane_in_state(state, plane, plane_state, i) {
> -   struct ipu_plane_state *ipu_state =
> -   to_ipu_plane_state(plane_state);
> -   struct ipu_plane *ipu_plane = to_ipu_plane(plane);
> +   ipu_state = to_ipu_plane_state(plane_state);
> +   ipu_plane = to_ipu_plane(plane);
> +
> +   if (!plane_state->fb) {
> +   ipu_state->use_pre = false;
> +   continue;
> +   }
> +
> +   if (!(plane_state->fb->flags & DRM_MODE_FB_MODIFIERS) ||
> +   plane_state->fb->modifier == DRM_FORMAT_MOD_LINEAR)
> +   continue;
> +
> +   if (!ipu_prg_present(ipu_plane->ipu) || !available_pres)
> +   return -EINVAL;

What about planes which aren't present in this commit, but are still
taking up a PRE unit? Will they have their PRE stolen, or am I missing
something?

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

Re: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init

[Liviu Dudau]

On Wed, May 03, 2017 at 06:45:05PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 03:52:23PM +0100, Liviu Dudau wrote:
> > On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote:
> > > On 3 May 2017 at 15:07, Liviu Dudau  wrote:
> > > > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
> > > >> It does deserve a much better commit message than what it has, but as
> > > >> he is on holiday for the rest of the week, I can answer. Currently, we
> > > >> advertise which formats each plane is capable of displaying. In order
> > > >> for userspace to be able to allocate tiled/compressed buffers for
> > > >> scanout, we want userspace to be able to discover which modifiers each
> > > >> plane supports as well.
> > > >
> > > > I get the overall goal. We need/want something similar for Mali DP and 
> > > > AFBC buffers.
> > > > What I don't understand is the current aproach (but I've found from 
> > > > Brian that somehow
> > > > I've missed the long discussion(s) around the subject). I was hoping to 
> > > > learn
> > > > from the commit message why he thinks the introduction of this code is 
> > > > the right
> > > > way of doing it. And the IRC logs seem to imply that he is mostly doing 
> > > > something
> > > > that others have agreed upon and he doesn't really care about the 
> > > > approach as long
> > > > as it ticks the "supported by intel driver" box.
> > > 
> > > Or, with another interpretation, he thinks the various approaches of
> > > doing it are all equally good. He took guidance from a couple of
> > > userspace developers (Weston, ChromeOS), a Freedreno developer and
> > > also I believe an AFBC developer, to end up where he is now, which he
> > > still thinks is fine. In doing so, he's been through several
> > > iterations, always modifying the driver to suit. I think that's a
> > > pretty good way to do development of new uABI, if you ask me. (And
> > > again, I have trouble reading your last sentence as anything other
> > > than hostile.)
> > 
> > I am getting the message. You think I am too strong here, so I'm going to 
> > back off.
> > Also look forward to see the next version where he takes into account the 
> > technical
> > comments that I have sent.
> 
> Just to make it really clear: Google has an implementation for AFBC using
> exactly this scheme for cros. The only reasons it's not floating around
> here in upstream is that one of the critical pieces is missing (*hint*,
> *hint* you really want an open mail driver ...).


Don't know about open _mail_ drivers but there are plenty of open mail apps 
that one can use


Joke aside, the Mali GPU *kernel* driver *is* open source. Just not in the 
mainline and
not enough for what you want. But I'm not the right person to fix all that.

And GPU is not the only IP capable of producing AFBC data, so there might be 
another driver
in the making that will be open source.

Best regards,
Liviu

> But besides that, it works
> perfectly fine for arm render compression format too.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 

| 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: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init

[kbuild test robot]

Hi Ben,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20170503]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane-init/20170504-004955
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   include/linux/init.h:1: warning: no structured comments found
   kernel/sched/core.c:2085: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2085: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   drivers/regulator/core.c:1467: warning: Excess function parameter 'ret' 
description in 'regulator_dev_lookup'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'num_ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'fops'
>> include/drm/drm_plane.h:545: warning: No description found for parameter 
>> 'formats'
>> includ

Re: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init

[kbuild test robot]

Hi Ben,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20170503]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane-init/20170504-004955
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c: In function 
'tinydrm_display_pipe_init':
>> drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c:227:8: warning: passing argument 
>> 6 of 'drm_simple_display_pipe_init' from incompatible pointer type
 ret = drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
   ^
   In file included from include/drm/tinydrm/tinydrm.h:15:0,
from drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c:13:
   include/drm/drm_simple_kms_helper.h:121:5: note: expected 'const uint64_t *' 
but argument is of type 'struct drm_connector *'
int drm_simple_display_pipe_init(struct drm_device *dev,
^
   drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c:227:8: error: too few arguments 
to function 'drm_simple_display_pipe_init'
 ret = drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
   ^
   In file included from include/drm/tinydrm/tinydrm.h:15:0,
from drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c:13:
   include/drm/drm_simple_kms_helper.h:121:5: note: declared here
int drm_simple_display_pipe_init(struct drm_device *dev,
^

vim +/drm_simple_display_pipe_init +227 
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c

fa201ac2 Noralf Trønnes 2017-01-22  211 *mode_copy = *mode;
fa201ac2 Noralf Trønnes 2017-01-22  212 ret = 
tinydrm_rotate_mode(mode_copy, rotation);
fa201ac2 Noralf Trønnes 2017-01-22  213 if (ret) {
fa201ac2 Noralf Trønnes 2017-01-22  214 DRM_ERROR("Illegal 
rotation value %u\n", rotation);
fa201ac2 Noralf Trønnes 2017-01-22  215 return -EINVAL;
fa201ac2 Noralf Trønnes 2017-01-22  216 }
fa201ac2 Noralf Trønnes 2017-01-22  217  
fa201ac2 Noralf Trønnes 2017-01-22  218 drm->mode_config.min_width = 
mode_copy->hdisplay;
fa201ac2 Noralf Trønnes 2017-01-22  219 drm->mode_config.max_width = 
mode_copy->hdisplay;
fa201ac2 Noralf Trønnes 2017-01-22  220 drm->mode_config.min_height = 
mode_copy->vdisplay;
fa201ac2 Noralf Trønnes 2017-01-22  221 drm->mode_config.max_height = 
mode_copy->vdisplay;
fa201ac2 Noralf Trønnes 2017-01-22  222  
fa201ac2 Noralf Trønnes 2017-01-22  223 connector = 
tinydrm_connector_create(drm, mode_copy, connector_type);
fa201ac2 Noralf Trønnes 2017-01-22  224 if (IS_ERR(connector))
fa201ac2 Noralf Trønnes 2017-01-22  225 return 
PTR_ERR(connector);
fa201ac2 Noralf Trønnes 2017-01-22  226  
fa201ac2 Noralf Trønnes 2017-01-22 @227 ret = 
drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
fa201ac2 Noralf Trønnes 2017-01-22  228 
   format_count, connector);
fa201ac2 Noralf Trønnes 2017-01-22  229 if (ret)
fa201ac2 Noralf Trønnes 2017-01-22  230 return ret;
fa201ac2 Noralf Trønnes 2017-01-22  231  
fa201ac2 Noralf Trønnes 2017-01-22  232 return 0;
fa201ac2 Noralf Trønnes 2017-01-22  233  }
fa201ac2 Noralf Trønnes 2017-01-22  234  
EXPORT_SYMBOL(tinydrm_display_pipe_init);

:: The code at line 227 was first introduced by commit
:: fa201ac2c61f51d9abdaffdf994d5780dcb51703 drm: Add DRM support for tiny 
LCD displays

:: TO: Noralf Trønnes 
:: CC: Noralf Trønnes 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

[Eric Anholt]

Daniel Vetter  writes:

> On Fri, Apr 28, 2017 at 03:42:22PM -0700, Eric Anholt wrote:
>> The FBDEV initialization would throw an error in dmesg, when we just
>> want to silently not initialize fbdev on a V3D-only VC4 instance.
>> 
>> Signed-off-by: Eric Anholt 
>
> With the commit message updated that passing num_connector is the bug that
> throws the error (and not that we set up a no-op fbdev):
>
> Reviewed-by: Daniel Vetter 
>
> Still kinda hoping for a follow-up to entirely get rid fo num_connector in
> the fbdev init funcs.

New commit message:

drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

There's no sense in having an fbdev if there's no display, since
connectors don't get hotplugged to this hardware.  On Cygnus we were
getting a dmesg error from passing in num_connectors (0), when that
argument is supposed to be the maximum number of cloned connectors per
CRTC (1).

Still no drm-misc acks on the other two patches, so I don't think I can
merge them.


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

[Bug 100919] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

[bugzilla-daemon]

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

Bug ID: 100919
   Summary: "Out of range" on a display connected to a DVI-D
output of RX460 card via DVI-D<=>HDMI-A cable
   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: nikola.fo...@gmail.com

I'm using the latest code from amd-staging-4.9 branch of ~agd5f/linux.

The problem is caused by this commit:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-4.9&id=2b2d4cfb0a629961a44e1ea0b29d336c1336deb9

After this change, when sink_signal is DVI_DUAL_LINK but pix_clk_khz is lower
than TMDS_MAX_PIXEL_CLOCK_IN_KHZ, stream->signal is set to DVI_DUAL_LINK, while
previously it was being set to DVI_SINGLE_LINK.

As a result, the connected display just reports "Out of range" error.

-- 
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 v3 4/4] drm: zte: add VGA driver support

[Sean Paul]

On Wed, May 03, 2017 at 08:44:53AM +0800, Shawn Guo wrote:
> Hi Sean,
> 
> On Tue, Apr 11, 2017 at 7:30 PM, Shawn Guo  wrote:
> > From: Shawn Guo 
> >
> > It adds VGA driver support, which needs to configure corresponding VOU
> > interface in RGB_888 format, and thus the following changes are needed
> > on zx_vou.
> >
> >  - Rename the CSC block of Graphic Layer a bit to make it more specific,
> >and add CSC of Channel to support RGB output.
> >  - Bypass Dither block for RGB output.
> >
> > Signed-off-by: Shawn Guo 
> > Acked-by: Daniel Vetter 
> > ---
> > Changes for v3:
> >  - Set device state into disconnected when edid read fails in .get_modes
> >hook.
> >  - Drop locking and add comments for understanding why it's not
> >necessary.
> 
> Are you okay with this version?  I need a 'go' from you to push the
> series to drm-misc-next.

Apologies for the delay.

Reviewed-by: Sean Paul 

> 
> Shawn

-- 
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: Soliciting DRM feedback on latest DC rework

[Harry Wentland]

On 2017-05-03 11:02 AM, Daniel Vetter wrote:

On Wed, May 03, 2017 at 04:26:51PM +0200, Christian König wrote:

Hi Harry,

while this looks more and more like it could work something which would
really help would be to have a set of patches squashed together and rebased
on drm-next.

The dc-drm-next-atomic-wip looks like a start, but we need more something
like:
drm/amdgpu: add base DC components
drm/amdgpu: add DCE8 support for DC
drm/amdgpu: add DCE9 support for DC
drm/amdgpu: add DCE10 support for DC
...
drm/amdgpu: enable DC globally
drm/amdgpu: remove old display infrastructure

Otherwise I fear that people will just be lost in the mass amount of patches
we have in the branch.


I think for a quick first feedback round simply something that's based on
top of recent drm-next is good enough, since I'll probably only look at
the aggregate diff anyway (or resulting tree).


This was basically what I figured which is why I didn't invest more time 
to squash changes. I agree with Christian that eventually we probably 
want something like his suggested split but for now I'd rather focus on 
tying a dc_surface to a drm_plane (and same for other objects). Starting 
to tie our objects to drm objects has been very eye-opening, to say the 
least.


Daniel, do you think you'll find time to take a look at this this week 
or next?


Harry


-Daniel



Regards,
Christian.

Am 03.05.2017 um 16:13 schrieb Harry Wentland:

Hi all,

Over the last few months we (mostly Andrey and myself) have taken and
addressed some of the feedback received from December's DC RFC. A lot of
our work so far centers around atomic. We were able to take a whole
bunch of the areas where we rolled our own solution and use DRM atomic
helpers instead.

You can find our most recent drm-next based tree at
https://cgit.freedesktop.org/~hwentland/linux/log/?h=dc-drm-next-atomic-wip

An outline of the changes with commit hashes from that tree are listed
below. They aren't necessarily in order but are grouped by
functionality.

I would like to solicit input on the changes and the current state of
amd/display in general.

I'm on IRC every weekday from 9-5 eastern time, sometimes at other
hours. Feel free to ask questions, discuss, leave comments. Let me know
if there's anything else I can do to facilitate review.

We know there's more work to be done but would much rather prioritize
that work based on community feedback than merely our own impressions.

We haven't finished plumbing drm types to the dc types yet, and there
are still a bunch of other things in progress.  We are not looking to
re-hash the previous discussion, but rather we'd like some feedback on
our work so far.

The list of changes (trimmed commit tags):

== Use common helpers for pageflip ==
144da239b047 Use pflip prepare and submit parts (v2)
ff7ac264a9a1 Fix page flip after daniel's acquire_ctx change


== implement atomic_get_properties ==
cf4a84df7189 Fallback on legacy properties in atomic_get_properties
01f96706b6ca get_atomic_property missing for drm_connector_funcs


== Use common helpers for gamma ==
3f547d7098de Use atomic helpers for gamma


== Use atomic helpers for commit ==
41831f55bd58 Refactor atomic commit implementation. (v2)
6c67dd3c5cd5 Refactor headless to use atomic commit.
eb22ef1ecb16 Remove page_fleep_needed function.


== Use atomic helpers for S3 ==
5a6ae6f76249 Switch to DRM helpers in s3.


== Simmplify mapping between DRM and DC objects ==
84a3ee023b9b Remove get_connector_for_link.
6d8978a98b40 Remove get_connector_for_sink.


== Use DRM EDID read instead of DC ==
566969dacfad Fix i2c write flag.
527c3699ff3c Refactor edid read.
5ac51023d275 Fix missing irq refactor causing potential i2c race


== Save DC validate_ctx in atomic_check and use in commit ==
8c194d8e4ee9 pull commit_surfaces out of atomic_commit into helper
function
27eef98b38c8 Return context from validate_context
ca3ee10e915b Add DM global atomic state
8ba1ca856532 Hook dm private state into atomic_check
10160455ac6d Add correct retain/release for objs in dm_atomic_state
0f1b2e2aecbb Commit validation set from state
258e6a91fc61 Add validate_context to atomic_state
64f569b5df20 Use validate_context from atomic_check in commit


== Start multi-plane implementation ==
601ff4e70b7c decouple per-crtc-plane model
a0b859a0b114 Fix cleanup in amdgpu_dm_initialize_drm_device
ee02010d7a82 update plane functionalities
3b7345fd1abb Allow planes on all crtcs
d9cf37462156 initialize YUV plane capabilities
248f06b2613e Universal cursor plane hook-up.


== Minor cleanups ==
d99bf02cb8fc Rename atomic_commit parameter.
f15fb9726502 Use amdgpu mode funcs statically
d3e37fa70643 Remove unused define from amdgpu_dm_types
80a38ad58125 Add lock around updating freesync property
8c7f16853824 Use new drm_dp_find_vcpi_slots to compute slots

Regards,
Harry
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/mm: Split up long running selftests with cond_resched()

[Chris Wilson]

On Thu, Mar 30, 2017 at 01:16:26PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-03-29 at 10:10 +0100, Chris Wilson wrote:
> > Scatter a few cond_resched() in between phases of the drm_mm selftests
> > to try and prevent us incurring the wrath of the NMI watchdog.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> 
> Reviewed-by: Joonas Lahtinen 

Daniel, pretty please?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 0/3] Intel FPGA VIP Frame Buffer II DRM Driver

[Eric Anholt]

hean.loong@intel.com writes:

> From: Ong Hean Loong 
>
> Hi,
>
> The new Intel Arria10 SOC FPGA devkit has a Display Port IP component 
> which requires a new driver. This is a virtual driver in which the
> FGPA hardware would enable the Display Port based on the information
> and data provided from the DRM frame buffer from the OS. Basically all
> all information with reagrds to resolution and bits per pixel are
> pre-configured on the FPGA design and these information are fed to
> the driver via the device tree information as part of the hardware 
> information.

I started reviewing the code, but I want to make sure I understand
what's going on:

This IP core isn't displaying contents from system memory on some sort
of actual physical display, right?  It's a core that takes some input
video stream (not described in the DT or in this driver) and stores it
to memory?


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

Re: [PATCHv2 2/3] ARM: drm: Intel FPGA VIP Frame Buffer II drm driver

[Eric Anholt]

hean.loong@intel.com writes:

> From: "Ong, Hean Loong" 
>
> Driver for Intel FPGA Video and Image Processing
> Suite Frame Buffer II. The driver only supports the Intel
> Arria10 devkit and its variants. This driver can be either
> loaded staticlly or in modules. The OF device tree binding
> is located at:
> Documentation/devicetree/bindings/display/altr,vip-fb2.txt
>
> Signed-off-by: Ong, Hean Loong 

I'm not sure if this driver is going to make sense as-is, if it doesn't
actually do display of planes from system memory.  But in case I was
wrong, here's my review:


> diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c 
> b/drivers/gpu/drm/ivip/intel_vip_conn.c
> new file mode 100644
> index 000..499d3b4
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
> @@ -0,0 +1,96 @@
> +/*
> + * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
> + * Frame Buffer II driver
> + *
> + * This driver supports the Intel VIP Frame Reader component.
> + * More info on the hardware can be found in the Intel Video
> + * and Image Processing Suite User Guide at this address
> + * http://www.altera.com/literature/ug/ug_vip.pdf.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * Authors:
> + * Ong, Hean-Loong 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static enum drm_connector_status
> +intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
> +{
> + return connector_status_connected;
> +}
> +
> +static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
> +{
> + drm_connector_unregister(connector);
> + drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = {
> + .dpms = drm_helper_connector_dpms,
> + .reset = drm_atomic_helper_connector_reset,
> + .detect = intelvipfb_drm_connector_detect,
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = intelvipfb_drm_connector_destroy,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static int intelvipfb_drm_connector_get_modes(struct drm_connector 
> *connector)
> +{
> + struct drm_device *drm = connector->dev;
> + int count;
> +
> + count = drm_add_modes_noedid(connector, drm->mode_config.max_width,
> +  drm->mode_config.max_height);
> + drm_set_preferred_mode(connector, drm->mode_config.max_width,
> +drm->mode_config.max_height);
> + return count;
> +}

You're adding a bunch of modes here, but I don't see anywhere in the
driver that you change the resolution being scanned out.

If you can't change resolution, then I'd probably use drm_gtf_mode() or
something to generate just the one mode (do you have a vrefresh for
it?).  Also, in the simple display pipe's atomic_check, make sure that
the mode chosen is the width/height you can support.

> +
> +static const struct drm_connector_helper_funcs
> +intelvipfb_drm_connector_helper_funcs = {
> + .get_modes = intelvipfb_drm_connector_get_modes,
> +};
> +
> +struct drm_connector *
> +intelvipfb_conn_setup(struct drm_device *drm)
> +{
> + struct drm_connector *conn;
> + int ret;
> +
> + conn = devm_kzalloc(drm->dev, sizeof(*conn), GFP_KERNEL);
> + if (IS_ERR(conn))
> + return NULL;
> +
> + ret = drm_connector_init(drm, conn, &intelvipfb_drm_connector_funcs,
> +  DRM_MODE_CONNECTOR_DisplayPort);

Are you actually outputting DisplayPort
(https://en.wikipedia.org/wiki/DisplayPort)?

You probably want something else from the DRM_MODE_CONNECTOR list, or
maybe just DRM_MODE_CONNECTOR_Unknown.


> + if (ret < 0) {
> + dev_err(drm->dev, "failed to initialize drm connector\n");
> + ret = -ENOMEM;
> + goto error_connector_cleanup;
> + }
> +
> + drm_connector_helper_add(conn, &intelvipfb_drm_connector_helper_funcs);
> +
> + return conn;
> +
> +error_connector_cleanup:
> + drm_connector_cleanup(conn);
> +
> + return NULL;
> +}
> diff --git a/drivers/gpu/drm/ivip/intel_vip_core.c 
> b/drivers/gpu/drm/ivip/intel_vip_core.c
> new file mode 100644
> index 000..4e83343
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/intel_vip_core.c
> @@ -0,0 +1,171 @@
> +/*
> + * intel_vip_core.c -- Intel Video and Image Processing(VIP)
> + * Frame Buffer II driver
> + *
> + * This driver 

Re: [PATCH v2 1/2] drm: Introduce crtc->mode_valid() callback

[Manasi Navare]

On Fri, Apr 28, 2017 at 02:47:11PM +0100, Jose Abreu wrote:
> Some crtc's may have restrictions in the mode they can display. In
> this patch a new callback (crtc->mode_valid()) is introduced that
> is called at the same stage of connector->mode_valid() callback.
> 
> This shall be implemented if the crtc has some sort of restriction
> so that we don't probe modes that will fail in the commit() stage.
> For example: A given crtc may be responsible to set a clock value.
> If the clock can not produce all the values for the available
> modes then this callback can be used to restrict the number of
> probbed modes to only the ones that can be displayed.
> 
> If the crtc does not implement the callback then the behaviour will
> remain the same. Also, for a given set of crtcs that can be bound to
> the connector, if at least one can display the mode then the mode
> will be probbed.
> 
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Alexey Brodkin 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Dave Airlie 
> Cc: Andrzej Hajda 
> ---
> 
> Changes v1->v2:
>   - Correct indentation
>   - Change function name to drm_validate_connector
>   - Move connnector->mode_valid() to new function
>   - Change crtc->mode_valid() "mode" field to const
>   - Code reogarnization
>   - Return earlier if crtc accepts mode
> 
>  drivers/gpu/drm/drm_probe_helper.c   | 50 
> ++--
>  include/drm/drm_modeset_helper_vtables.h | 26 +
>  2 files changed, 74 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 1b0c14a..0741f36 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -80,6 +80,52 @@
>   return MODE_OK;
>  }
>  
> +static enum drm_mode_status
> +drm_mode_validate_connector(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> + const struct drm_connector_helper_funcs *connector_funcs =
> + connector->helper_private;
> + struct drm_device *dev = connector->dev;
> + uint32_t *ids = connector->encoder_ids;
> + enum drm_mode_status ret = MODE_OK;
> + unsigned int i;
> +
> + /* Step 1: Validate against connector */
> + if (connector_funcs->mode_valid)
> + ret = connector_funcs->mode_valid(connector, mode);
> +
> + if (ret != MODE_OK)
> + return ret;
> +
> + /* Step 2: Validate against crtc's */
> + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> + struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
> + struct drm_crtc *crtc;
> +
> + if (!encoder)
> + continue;
> +
> + drm_for_each_crtc(crtc, dev) {
> + const struct drm_crtc_helper_funcs *crtc_funcs;
> +
> + if (!drm_encoder_crtc_ok(encoder, crtc))
> + continue;
> +
> + crtc_funcs = crtc->helper_private;
> + if (!crtc_funcs || !crtc_funcs->mode_valid)
> + return MODE_OK; /* crtc accepts everything */
> +
> + ret = crtc_funcs->mode_valid(crtc, mode);
> + if (ret == MODE_OK)
> + return ret;

> + }
> + }
> +
> + /* NOTE: If no crtc or encoder is found then we return MODE_OK */

I think this comment is misleading because here ret is not alwyas MODE_OK.
It will be the return value from crtc_func->mode_valid which could also
be MODE_NOCLOCK

Manasi

> + return ret;
> +}
> +
>  static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
>  {
>   struct drm_cmdline_mode *cmdline_mode;
> @@ -428,8 +474,8 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>   if (mode->status == MODE_OK)
>   mode->status = drm_mode_validate_flag(mode, mode_flags);
>  
> - if (mode->status == MODE_OK && connector_funcs->mode_valid)
> - mode->status = connector_funcs->mode_valid(connector,
> + if (mode->status == MODE_OK)
> + mode->status = drm_mode_validate_connector(connector,
>  mode);
>   }
>  
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index c01c328..ecb055c 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -106,6 +106,32 @@ struct drm_crtc_helper_funcs {
>   void (*commit)(struct drm_crtc *crtc);
>  
>   /**
> +  * @mode_valid:
> +  *
> +  * This callback should be implemented if the crtc has some sort of
> +  * restriction in the modes it can display. For example, a given crtc
> +  * may be responsible to set a clock va

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

[Stephen Rothwell]

Hi all,

On Fri, 21 Apr 2017 12:10:14 +1000 Stephen Rothwell  
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in 
> initializer
>   .kmap_atomic = tee_shm_op_kmap_atomic,
>   ^
> drivers/tee/tee_shm.c:87:17: error: initialization from incompatible pointer 
> type [-Werror=incompatible-pointer-types]
>   .kmap_atomic = tee_shm_op_kmap_atomic,
>  ^
> drivers/tee/tee_shm.c:87:17: note: (near initialization for 
> 'tee_shm_dma_buf_ops.begin_cpu_access')
> drivers/tee/tee_shm.c:88:2: error: unknown field 'kmap' specified in 
> initializer
>   .kmap = tee_shm_op_kmap,
>   ^
> drivers/tee/tee_shm.c:88:10: error: initialization from incompatible pointer 
> type [-Werror=incompatible-pointer-types]
>   .kmap = tee_shm_op_kmap,
>   ^
> drivers/tee/tee_shm.c:88:10: note: (near initialization for 
> 'tee_shm_dma_buf_ops.end_cpu_access')
> 
> Caused by commit
> 
>   f9b67f0014cb ("dma-buf: Rename dma-ops to prevent conflict with 
> kunmap_atomic macro")
> 
> interacting with commit
> 
>   967c9cca2cc5 ("tee: generic TEE subsystem")
> 
> from the arm-soc tree.
> 
> I applied the following merge fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Fri, 21 Apr 2017 12:06:32 +1000
> Subject: [PATCH] tee: merge fix for dma-ops field name changes
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/tee/tee_shm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
> index 0be1e3e93bee..4e14c9c9cb1c 100644
> --- a/drivers/tee/tee_shm.c
> +++ b/drivers/tee/tee_shm.c
> @@ -84,8 +84,8 @@ static struct dma_buf_ops tee_shm_dma_buf_ops = {
>   .map_dma_buf = tee_shm_op_map_dma_buf,
>   .unmap_dma_buf = tee_shm_op_unmap_dma_buf,
>   .release = tee_shm_op_release,
> - .kmap_atomic = tee_shm_op_kmap_atomic,
> - .kmap = tee_shm_op_kmap,
> + .map_atomic = tee_shm_op_kmap_atomic,
> + .map = tee_shm_op_kmap,
>   .mmap = tee_shm_op_mmap,
>  };
>  
> -- 
> 2.11.0

This fixup is now needed when merging the arm-soc tree with Linus' tree.
-- 
Cheers,
Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Keith Packard]

Pekka Paalanen  writes:

> do you mean to list all kinds of display devices in the database? I was
> assuming it would list only HMDs, so not in database would imply it's a
> normal display and good for extending the desktop to.

I intended for it to be a general database to which we could add almost
anything; you can imagine using this to replace broken EDID values,
configure alternate preferred modes or whatever.

The 'desktop' boolean says whether the desktop should be expected to use
the device or not; that's all I need for the HMD case.

> Or did you mean it for exceptions? As in, define a range of HMDs, but
> the vendor put a few normal displays in the middle of the range, so one
> needs to be able to exclude those?

Oh, that's a great thought; I hadn't considered what we would do with
conflicting entries that mapped the same device. I'd like to make that
invalid, and potentially spit out a warning message somewhere...

> The reason I mentioned "virtual 2D display" was that I recall hearing
> that actually exists in some HMD hardware. If you don't do anything to
> enable a 3D mode, the HMD will process the signal to produce a virtual
> 2D display in front the user. In such case, there is no need for a VR
> compositor, the plain old 2D image signal will be shown correctly on a
> plane in the virtual space by the HMD hardware itself.

Oh, cool! That doesn't help as it means the user will want to pick if
this happens or not. Maybe just don't include it in the database and let
the VR application turn off the X output before creating a lease?

> Mind the note towards the bottom: you don't actually need a PS4 to use
> it - so it must be something built into the HMD. However, reading more
> details from
> https://blog.us.playstation.com/2016/10/03/playstation-vr-the-ultimate-faq/
> reveals that there is actually a separate processor box providing the
> cinematic mode. Sounds like it's your VR compositor as a middle-man
> hardware device rather than just a program. :-)

Interesting. I guess it's a way to make it work without hacking the
desktop environment at all?

Thanks for your suggestions; I hope we're getting closer to some kind of
prototype at least...

-- 
-keith


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