[radeon-alex:drm-next-5.1-wip 197/225] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5173:4: note: in expansion of macro 'amdgpu_dm_crtc_set_crc_source'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-5.1-wip
head:   f9028b9278422fdf186f1b88662e28ed24e13df8
commit: 43a6a02eb3558d1f3a0618f9bf02328662fb06e3 [197/225] drm/amd/display: 
Re-enable CRC capture following modeset
config: x86_64-randconfig-s2-02021031 (attached as .config)
compiler: gcc-6 (Debian 6.5.0-2) 6.5.0 20181026
reproduce:
git checkout 43a6a02eb3558d1f3a0618f9bf02328662fb06e3
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/posix_types.h:5:0,
from include/uapi/linux/types.h:14,
from include/linux/types.h:6,
from include/uapi/linux/byteorder/little_endian.h:12,
from include/linux/byteorder/little_endian.h:5,
from arch/x86/include/uapi/asm/byteorder.h:5,
from drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:29,
from 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
from 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:29:
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function 
'amdgpu_dm_atomic_commit_tail':
>> include/linux/stddef.h:8:14: error: called object is not a function or 
>> function pointer
#define NULL ((void *)0)
 ^
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:340:39: note: in 
>> expansion of macro 'NULL'
#define amdgpu_dm_crtc_set_crc_source NULL
  ^~~~
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5173:4: note: in 
>> expansion of macro 'amdgpu_dm_crtc_set_crc_source'
   amdgpu_dm_crtc_set_crc_source(crtc, "auto");
   ^

vim +/amdgpu_dm_crtc_set_crc_source +5173 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c

  4949  
  4950  /**
  4951   * amdgpu_dm_atomic_commit_tail() - AMDgpu DM's commit tail 
implementation.
  4952   * @state: The atomic state to commit
  4953   *
  4954   * This will tell DC to commit the constructed DC state from 
atomic_check,
  4955   * programming the hardware. Any failures here implies a hardware 
failure, since
  4956   * atomic check should have filtered anything non-kosher.
  4957   */
  4958  static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state)
  4959  {
  4960  struct drm_device *dev = state->dev;
  4961  struct amdgpu_device *adev = dev->dev_private;
  4962  struct amdgpu_display_manager *dm = >dm;
  4963  struct dm_atomic_state *dm_state;
  4964  struct dc_state *dc_state = NULL, *dc_state_temp = NULL;
  4965  uint32_t i, j;
  4966  struct drm_crtc *crtc;
  4967  struct drm_crtc_state *old_crtc_state, *new_crtc_state;
  4968  unsigned long flags;
  4969  bool wait_for_vblank = true;
  4970  struct drm_connector *connector;
  4971  struct drm_connector_state *old_con_state, *new_con_state;
  4972  struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state;
  4973  int crtc_disable_count = 0;
  4974  
  4975  drm_atomic_helper_update_legacy_modeset_state(dev, state);
  4976  
  4977  dm_state = dm_atomic_get_new_state(state);
  4978  if (dm_state && dm_state->context) {
  4979  dc_state = dm_state->context;
  4980  } else {
  4981  /* No state changes, retain current state. */
  4982  dc_state_temp = dc_create_state();
  4983  ASSERT(dc_state_temp);
  4984  dc_state = dc_state_temp;
  4985  dc_resource_state_copy_construct_current(dm->dc, 
dc_state);
  4986  }
  4987  
  4988  /* update changed items */
  4989  for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
  4990  struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
  4991  
  4992  dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
  4993  dm_old_crtc_state = to_dm_crtc_state(old_crtc_state);
  4994  
  4995  DRM_DEBUG_DRIVER(
  4996  "amdgpu_crtc id:%d crtc_state_flags: enable:%d, 
active:%d, "
  4997  "planes_changed:%d, 
mode_changed:%d,active_changed:%d,"
  4998  "connectors_changed:%d\n",
  4999  acrtc->crtc_id,
  5000  new_crtc_state->enable,
  5001  new_crtc_state->active,
  5002  new_crtc_state->planes_changed,
  5003  new_crtc_state->mode_changed,
  5004  new_crtc_state->active_changed,
  5005  new_crtc_state->connectors_changed);
  5006  
  5007  /* Copy all transient state flags 

Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV*

[Joe Perches]

On Fri, 2019-02-01 at 14:37 +0100, Sam Ravnborg wrote:
> Hi Thierry.
> 
> > I'm slightly on the fence about this patch.
> 
> Please ignore patch 3-19, there is no consensus on the logging changes.
> We do not want to apply these and then have to redo parts/all of
> it later.
> 
> But the first two patches has not seen any feedback yet:
> 
> [PATCH v1 01/19] drm/panel: drop drmP.h usage
> [PATCH v1 02/19] drm/panel: panel-innolux: drop unused variable
> 
> Please consider these, or maybe wait a little to see if someone
> find time to review.
> 
> I can resend the patches if this is preferred.

My preference would also convert all the
DRM_DEV_ uses to drm_dev_ eventually.

Also, the macros themselves could change to use a
more consistent mechanism.

This would make the drm logging mechanisms more like
other logging mechanisms used in the kernel.

Something like:
---
Subject: [PATCH] drm: Improve and standardize logging functions

Use a more typical logging style.

Add and use drm_printk and drm_dev_printk functions that include the
test for KERN_ERR use where '*ERROR*' is added to logging output.

Remove the slightly unusual _DRM_PRINTK macro and use the new drm_printk
function instead.
---
 drivers/gpu/drm/drm_print.c | 67 +
 include/drm/drm_print.h | 51 --
 2 files changed, 74 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 0e7fc3e7dfb4..4e3ae7b5cce1 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -174,22 +174,59 @@ void drm_printf(struct drm_printer *p, const char *f, ...)
 }
 EXPORT_SYMBOL(drm_printf);
 
-void drm_dev_printk(const struct device *dev, const char *level,
-   const char *format, ...)
+void drm_printk(const char *format, ...)
 {
struct va_format vaf;
va_list args;
+   char lvl[PRINTK_MAX_SINGLE_HEADER_LEN + 1] = KERN_DEFAULT;
+   int level = printk_get_level(format);
+   size_t size = printk_skip_level(format) - format;
+
+   if (size) {
+   memcpy(lvl, format, size);
+   lvl[size] = '\0';
+   }
 
va_start(args, format);
-   vaf.fmt = format;
+   vaf.fmt = format + size;
+   vaf.va = 
+
+   printk("%s" "[" DRM_NAME ":%ps] %s%pV",
+  lvl, __builtin_return_address(0),
+  level == LOGLEVEL_ERR ? "*ERROR* " : "",
+  );
+
+   va_end(args);
+}
+EXPORT_SYMBOL(drm_printk);
+
+void drm_dev_printk(const struct device *dev, const char *format, ...)
+{
+   struct va_format vaf;
+   va_list args;
+   char lvl[PRINTK_MAX_SINGLE_HEADER_LEN + 1] = KERN_DEFAULT;
+   int level = printk_get_level(format);
+   size_t size = printk_skip_level(format) - format;
+
+   if (size) {
+   memcpy(lvl, format, size);
+   lvl[size] = '\0';
+   }
+
+   va_start(args, format);
+   vaf.fmt = format + size;
vaf.va = 
 
if (dev)
-   dev_printk(level, dev, "[" DRM_NAME ":%ps] %pV",
-  __builtin_return_address(0), );
+   dev_printk(lvl, dev, "[" DRM_NAME ":%ps] %s%pV",
+  __builtin_return_address(0),
+  level == LOGLEVEL_ERR ? "*ERROR* " : "",
+  );
else
-   printk("%s" "[" DRM_NAME ":%ps] %pV",
-  level, __builtin_return_address(0), );
+   printk("%s" "[" DRM_NAME ":%ps] %s%pV",
+  lvl, __builtin_return_address(0),
+  level == LOGLEVEL_ERR ? "*ERROR* " : "",
+  );
 
va_end(args);
 }
@@ -237,19 +274,3 @@ void drm_dbg(unsigned int category, const char *format, 
...)
va_end(args);
 }
 EXPORT_SYMBOL(drm_dbg);
-
-void drm_err(const char *format, ...)
-{
-   struct va_format vaf;
-   va_list args;
-
-   va_start(args, format);
-   vaf.fmt = format;
-   vaf.va = 
-
-   printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
-  __builtin_return_address(0), );
-
-   va_end(args);
-}
-EXPORT_SYMBOL(drm_err);
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index afbc3beef089..9d9fd10e6ff8 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -268,9 +268,8 @@ static inline struct drm_printer drm_debug_printer(const 
char *prefix)
 #define DRM_UT_LEASE   0x80
 #define DRM_UT_DP  0x100
 
-__printf(3, 4)
-void drm_dev_printk(const struct device *dev, const char *level,
-   const char *format, ...);
+__printf(2, 3)
+void drm_dev_printk(const struct device *dev, const char *format, ...);
 __printf(3, 4)
 void drm_dev_dbg(const struct device *dev, unsigned int category,
 const char *format, ...);
@@ -278,26 +277,38 @@ void drm_dev_dbg(const struct device *dev, unsigned int 
category,
 __printf(2, 3)

[PATCH] drm: Trivial comment grammar cleanups

[Matt Roper]

Most of these are just cases where code comments used contractions
(it's, who's) where they actually mean to use a possessive pronoun (its,
whose) or vice-versa.

Signed-off-by: Matt Roper 
---
A couple of these were bugging me enough that I did a quick search for
other similar mistakes in the DRM core.  I'm sure there are plenty more
in the various driver trees that could be cleaned up if someone wanted
to spend the time to track them down.

 drivers/gpu/drm/drm_agpsupport.c |  2 +-
 drivers/gpu/drm/drm_atomic_helper.c  |  8 
 drivers/gpu/drm/drm_atomic_uapi.c|  4 ++--
 drivers/gpu/drm/drm_bufs.c   |  4 ++--
 drivers/gpu/drm/drm_connector.c  |  2 +-
 drivers/gpu/drm/drm_dp_mst_topology.c| 30 +++---
 drivers/gpu/drm/drm_fb_helper.c  |  2 +-
 drivers/gpu/drm/drm_file.c   |  2 +-
 drivers/gpu/drm/drm_framebuffer.c|  2 +-
 drivers/gpu/drm/drm_gem.c|  2 +-
 drivers/gpu/drm/drm_mm.c |  2 +-
 drivers/gpu/drm/drm_modes.c  |  2 +-
 drivers/gpu/drm/drm_property.c   |  2 +-
 drivers/gpu/drm/drm_vblank.c |  2 +-
 include/drm/drm_atomic.h |  2 +-
 include/drm/drm_client.h |  2 +-
 include/drm/drm_connector.h  |  2 +-
 include/drm/drm_mode_config.h|  2 +-
 include/drm/drm_modeset_helper_vtables.h |  2 +-
 include/drm/drm_modeset_lock.h   |  2 +-
 include/drm/ttm/ttm_bo_driver.h  |  2 +-
 21 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 737f02885c28..40fba1c04dfc 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -348,7 +348,7 @@ int drm_agp_bind_ioctl(struct drm_device *dev, void *data,
  * \return zero on success or a negative number on failure.
  *
  * Verifies the AGP device is present and has been acquired and looks up the
- * AGP memory entry. If the memory it's currently bound, unbind it via
+ * AGP memory entry. If the memory is currently bound, unbind it via
  * unbind_agp(). Frees it via free_agp() as well as the entry itself
  * and unlinks from the doubly linked list it's inserted in.
  */
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 6fe2303fccd9..440cfa91162a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -330,7 +330,7 @@ update_connector_routing(struct drm_atomic_state *state,
 * Since the connector can be unregistered at any point during an
 * atomic check or commit, this is racy. But that's OK: all we care
 * about is ensuring that userspace can't do anything but shut off the
-* display on a connector that was destroyed after its been notified,
+* display on a connector that was destroyed after it's been notified,
 * not before.
 */
if (drm_connector_is_unregistered(connector) && crtc_state->active) {
@@ -685,7 +685,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 
/*
 * After all the routing has been prepared we need to add in any
-* connector which is itself unchanged, but who's crtc changes it's
+* connector which is itself unchanged, but whose crtc changes its
 * configuration. This must be done before calling mode_fixup in case a
 * crtc only changed its mode but has the same set of connectors.
 */
@@ -1670,7 +1670,7 @@ EXPORT_SYMBOL(drm_atomic_helper_async_commit);
  * drm_atomic_helper_setup_commit() and related functions.
  *
  * Committing the actual hardware state is done through the
- * _mode_config_helper_funcs.atomic_commit_tail callback, or it's default
+ * _mode_config_helper_funcs.atomic_commit_tail callback, or its default
  * implementation drm_atomic_helper_commit_tail().
  *
  * RETURNS:
@@ -1893,7 +1893,7 @@ crtc_or_fake_commit(struct drm_atomic_state *state, 
struct drm_crtc *crtc)
  * functions. drm_atomic_helper_wait_for_dependencies() must be called before
  * actually committing the hardware state, and for nonblocking commits this 
call
  * must be placed in the async worker. See also drm_atomic_helper_swap_state()
- * and it's stall parameter, for when a driver's commit hooks look at the
+ * and its stall parameter, for when a driver's commit hooks look at the
  * _crtc.state, _plane.state or _connector.state pointer directly.
  *
  * Completion of the hardware commit step must be signalled using
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41adfc67..0aabd401d3ca 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -44,8 +44,8 @@
  * DOC: overview
  *
  * This file contains the marshalling and demarshalling glue for the atomic 
UAPI
- * in all it's form: The monster ATOMIC IOCTL itself, code for 

[Bug 109022] ring gfx timeout during particular shader generation on yuzu emulator

[bugzilla-daemon]

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

--- Comment #9 from e88z4  ---
I tried to enable NIR using R600_DEBUG=nir, I got a different behaviour on GFX
timeout. 
[Feb 1 19:44] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240122] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[Feb 1 19:45] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240145] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240170] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.239953] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240061] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240340] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[Feb 1 19:46] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240003] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240173] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240074] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.239890] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[Feb 1 19:44] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240122] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[Feb 1 19:45] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240145] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240170] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.239953] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240061] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240340] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[Feb 1 19:46] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240003] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240173] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240074] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered

I get a a looping error message like the above but I can kill the application
from ssh. Display is once again usable, no hard reset is required.

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

[PATCH v3 4/4] drm/nouveau: Move PBN and VCPI allocation into nv50_head_atom

[Lyude Paul]

Atomic checks should never modify anything outside of the state that
they're passed in. Unfortunately this appears to be exactly what we're
doing in nv50_msto_atomic_check() where we update mstc->pbn every time
the function is called. This hasn't caused any bugs yet, but it needs to
be fixed in order to ensure that when committing an artificially
duplicated state (like during system resume), that we reuse the PBN of
that state to perform VCPI allocations and don't recalculate a different
value from the drm connector's reported bpc.

Also, move the VCPI slot allocations while we're at it as well. With
this, removing a topology in suspend while using nouveau no longer
causes the new atomic VCPI helpers to complain.

Signed-off-by: Lyude Paul 
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Cc: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  6 ++
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 28 +++--
 drivers/gpu/drm/nouveau/dispnv50/head.c |  1 +
 3 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h 
b/drivers/gpu/drm/nouveau/dispnv50/atom.h
index a194990d2b0d..b5fae5ab3fa8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
@@ -116,6 +116,12 @@ struct nv50_head_atom {
u8 depth:4;
} or;
 
+   /* Currently only used for MST */
+   struct {
+   int pbn;
+   u8 tu:6;
+   } dp;
+
union nv50_head_atom_mask {
struct {
bool olut:1;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 60d858c2f2ce..e8bb35f6d015 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -659,8 +659,6 @@ struct nv50_mstc {
 
struct drm_display_mode *native;
struct edid *edid;
-
-   int pbn;
 };
 
 struct nv50_msto {
@@ -765,17 +763,26 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
struct drm_connector *connector = conn_state->connector;
struct nv50_mstc *mstc = nv50_mstc(connector);
struct nv50_mstm *mstm = mstc->mstm;
-   int bpp = connector->display_info.bpc * 3;
+   struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
int slots;
 
-   mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
-bpp);
+   /* When restoring duplicated states, we need to make sure that the
+* bw remains the same and avoid recalculating it, as the connector's
+* bpc may have changed after the state was duplicated
+*/
+   if (!state->duplicated)
+   asyh->dp.pbn =
+   drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
+connector->display_info.bpc * 3);
 
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
slots = drm_dp_atomic_find_vcpi_slots(state, >mgr,
- mstc->port, mstc->pbn);
+ mstc->port,
+ asyh->dp.pbn);
if (slots < 0)
return slots;
+
+   asyh->dp.tu = slots;
}
 
return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
@@ -786,13 +793,13 @@ static void
 nv50_msto_enable(struct drm_encoder *encoder)
 {
struct nv50_head *head = nv50_head(encoder->crtc);
+   struct nv50_head_atom *armh = nv50_head_atom(head->base.base.state);
struct nv50_msto *msto = nv50_msto(encoder);
struct nv50_mstc *mstc = NULL;
struct nv50_mstm *mstm = NULL;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
u8 proto, depth;
-   int slots;
bool r;
 
drm_connector_list_iter_begin(encoder->dev, _iter);
@@ -808,8 +815,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
if (WARN_ON(!mstc))
return;
 
-   slots = drm_dp_find_vcpi_slots(>mgr, mstc->pbn);
-   r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, mstc->pbn, slots);
+   r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, armh->dp.pbn,
+armh->dp.tu);
WARN_ON(!r);
 
if (!mstm->links++)
@@ -827,8 +834,7 @@ nv50_msto_enable(struct drm_encoder *encoder)
default: depth = 0x6; break;
}
 
-   mstm->outp->update(mstm->outp, head->base.index,
-  nv50_head_atom(head->base.base.state), proto, depth);
+   mstm->outp->update(mstm->outp, head->base.index, armh, proto, depth);
 
msto->head = head;
msto->mstc = mstc;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index ac97ebce5b35..2e7a0c347ddb 100644
--- 

[PATCH v3 2/4] drm/dp_mst: Remove port validation in drm_dp_atomic_find_vcpi_slots()

[Lyude Paul]

Since we now have an easy way of refcounting drm_dp_mst_port structs and
safely accessing their contents, there isn't any good reason to keep
validating ports here. It doesn't prevent us from performing modesets on
branch devices that have been removed either, and we already disallow
enabling new displays on unregistered connectors in
update_connector_routing() in drm_atomic_check_modeset(). All it does is
cause us to have to make weird special exceptions in our atomic
modesetting code. So, get rid of it entirely.

Signed-off-by: Lyude Paul 
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_mst_topology.c   | 12 ++--
 drivers/gpu/drm/i915/intel_dp_mst.c | 17 ++---
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  3 +--
 3 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index abb0ea8ba9d9..4325e1518286 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3117,10 +3117,6 @@ int drm_dp_atomic_find_vcpi_slots(struct 
drm_atomic_state *state,
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
 
-   port = drm_dp_mst_topology_get_port_validated(mgr, port);
-   if (port == NULL)
-   return -EINVAL;
-
/* Find the current allocation for this port, if any */
list_for_each_entry(pos, _state->vcpis, next) {
if (pos->port == port) {
@@ -3153,10 +3149,8 @@ int drm_dp_atomic_find_vcpi_slots(struct 
drm_atomic_state *state,
/* Add the new allocation to the state */
if (!vcpi) {
vcpi = kzalloc(sizeof(*vcpi), GFP_KERNEL);
-   if (!vcpi) {
-   ret = -ENOMEM;
-   goto out;
-   }
+   if (!vcpi)
+   return -ENOMEM;
 
drm_dp_mst_get_port_malloc(port);
vcpi->port = port;
@@ -3165,8 +3159,6 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state 
*state,
vcpi->vcpi = req_slots;
 
ret = req_slots;
-out:
-   drm_dp_mst_topology_put_port(port);
return ret;
 }
 EXPORT_SYMBOL(drm_dp_atomic_find_vcpi_slots);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index cdb83d294cdd..fb67cd931117 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -80,17 +80,12 @@ static int intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
 
-   /* Zombie connectors can't have VCPI slots */
-   if (!drm_connector_is_unregistered(connector)) {
-   slots = drm_dp_atomic_find_vcpi_slots(state,
- _dp->mst_mgr,
- port,
- mst_pbn);
-   if (slots < 0) {
-   DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
- slots);
-   return slots;
-   }
+   slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr, port,
+ mst_pbn);
+   if (slots < 0) {
+   DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
+ slots);
+   return slots;
}
 
intel_link_compute_m_n(bpp, lane_count,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 2e8a5fd9b262..60d858c2f2ce 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -771,8 +771,7 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
 bpp);
 
-   if (drm_atomic_crtc_needs_modeset(crtc_state) &&
-   !drm_connector_is_unregistered(connector)) {
+   if (drm_atomic_crtc_needs_modeset(crtc_state)) {
slots = drm_dp_atomic_find_vcpi_slots(state, >mgr,
  mstc->port, mstc->pbn);
if (slots < 0)
-- 
2.20.1

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

[PATCH v3 0/4] drm/dp_mst: Fix regressions from new atomic VCPI helpers

[Lyude Paul]

This fixes the extra issues I discovered upstream after the introduction
of my rework of the atomic VCPI helpers that occur during
suspend/resume.

This time around, we use a slightly different but much less complicated
approach for fixing said issues.

Cc: Daniel Vetter 

Lyude Paul (4):
  drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()
  drm/dp_mst: Remove port validation in drm_dp_atomic_find_vcpi_slots()
  drm/atomic: Add drm_atomic_state->duplicated
  drm/nouveau: Move PBN and VCPI allocation into nv50_head_atom

 drivers/gpu/drm/drm_atomic_helper.c | 10 +++-
 drivers/gpu/drm/drm_dp_mst_topology.c   | 32 +
 drivers/gpu/drm/i915/intel_dp_mst.c | 17 +
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  6 +
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 31 ++--
 drivers/gpu/drm/nouveau/dispnv50/head.c |  1 +
 include/drm/drm_atomic.h|  9 +++
 7 files changed, 66 insertions(+), 40 deletions(-)

-- 
2.20.1

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

[PATCH v3 3/4] drm/atomic: Add drm_atomic_state->duplicated

[Lyude Paul]

Since

commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
connectors harder")

We've been failing atomic checks if they try to enable new displays on
unregistered connectors. This is fine except for the one situation that
breaks atomic assumptions: suspend/resume. If a connector is
unregistered before we attempt to restore the atomic state, something we
end up failing the atomic check that happens when trying to restore the
state during resume.

Normally this would be OK: we try our best to make sure that the atomic
state pre-suspend can be restored post-suspend, but failures at that
point usually don't cause problems. That is of course, until we
introduced the new atomic MST VCPI helpers:

[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:65:pipe B] active 
changed
[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for 
[CONNECTOR:123:DP-5]
[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Disabling 
[CONNECTOR:123:DP-5]
[drm:drm_atomic_get_private_obj_state [drm]] Added new private object 
25844636 state 9fd2899a to 3a13d7b8
WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153 
drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
Modules linked in: fuse vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic joydev iTCO_wdt i915(O) wmi_bmof intel_rapl btusb btrtl 
x86_pkg_temp_thermal btbcm btintel coretemp i2c_algo_bit drm_kms_helper(O) 
crc32_pclmul snd_hda_intel syscopyarea sysfillrect snd_hda_codec sysimgblt 
snd_hda_core bluetooth fb_sys_fops snd_pcm pcspkr drm(O) psmouse snd_timer 
mei_me ecdh_generic i2c_i801 mei i2c_core ucsi_acpi typec_ucsi typec wmi 
thinkpad_acpi ledtrig_audio snd soundcore tpm_tis rfkill tpm_tis_core video tpm 
acpi_pad pcc_cpufreq uas usb_storage crc32c_intel nvme serio_raw xhci_pci 
nvme_core xhci_hcd
CPU: 6 PID: 1070 Comm: gnome-shell Tainted: GW  O  
5.0.0-rc2Lyude-Test+ #1
Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018
RIP: 0010:drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
Code: 00 4c 39 6d f0 74 49 48 8d 7b 10 48 89 f9 48 c1 e9 03 42 80 3c 21 00 0f 
85 d2 00 00 00 48 8b 6b 10 48 8d 5d f0 49 39 ee 75 c5 <0f> 0b 48 c7 c7 c0 78 b3 
a0 48 89 c2 4c 89 ee e8 03 6c aa ff b8 ea
RSP: 0018:88841235f268 EFLAGS: 00010246
RAX: 88841bf12ab0 RBX: 88841bf12aa8 RCX: 1110837e2557
RDX: dc00 RSI:  RDI: ed108246bde0
RBP: 88841bf12ab8 R08: ed1083db3c93 R09: ed1083db3c92
R10: ed1083db3c92 R11: 88841ed9e497 R12: 888419555d80
R13: 8883bc499100 R14: 88841bf12ab8 R15: 
FS:  7f16fbd4cd00() GS:88841ed8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f1687c9f000 CR3: 0003ba3cc003 CR4: 003606e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 drm_atomic_helper_check_modeset+0xf21/0x2f50 [drm_kms_helper]
 ? drm_atomic_helper_commit_modeset_enables+0xa90/0xa90 [drm_kms_helper]
 ? __printk_safe_exit+0x10/0x10
 ? save_stack+0x8c/0xb0
 ? vprintk_func+0x96/0x1bf
 ? __printk_safe_exit+0x10/0x10
 intel_atomic_check+0x234/0x4750 [i915]
 ? printk+0x9f/0xc5
 ? kmsg_dump_rewind_nolock+0xd9/0xd9
 ? _raw_spin_lock_irqsave+0xa4/0x140
 ? drm_atomic_check_only+0xb1/0x28b0 [drm]
 ? drm_dbg+0x186/0x1b0 [drm]
 ? drm_dev_dbg+0x200/0x200 [drm]
 ? intel_link_compute_m_n+0xb0/0xb0 [i915]
 ? drm_mode_put_tile_group+0x20/0x20 [drm]
 ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915]
 ? drm_plane_check_pixel_format+0x14a/0x310 [drm]
 drm_atomic_check_only+0x13c4/0x28b0 [drm]
 ? drm_state_info+0x220/0x220 [drm]
 ? drm_atomic_helper_disable_plane+0x1d0/0x1d0 [drm_kms_helper]
 ? pick_single_encoder_for_connector+0xe0/0xe0 [drm_kms_helper]
 ? kasan_unpoison_shadow+0x35/0x40
 drm_atomic_commit+0x3b/0x100 [drm]
 drm_atomic_helper_set_config+0xd5/0x100 [drm_kms_helper]
 drm_mode_setcrtc+0x636/0x1660 [drm]
 ? vprintk_func+0x96/0x1bf
 ? drm_dev_dbg+0x200/0x200 [drm]
 ? drm_mode_getcrtc+0x790/0x790 [drm]
 ? printk+0x9f/0xc5
 ? mutex_unlock+0x1d/0x40
 ? drm_mode_addfb2+0x2e9/0x3a0 [drm]
 ? rcu_sync_dtor+0x2e0/0x2e0
 ? drm_dbg+0x186/0x1b0 [drm]
 ? set_page_dirty+0x271/0x4d0
 drm_ioctl_kernel+0x203/0x290 [drm]
 ? drm_mode_getcrtc+0x790/0x790 [drm]
 ? drm_setversion+0x7f0/0x7f0 [drm]
 ? __switch_to_asm+0x34/0x70
 ? __switch_to_asm+0x34/0x70
 drm_ioctl+0x445/0x950 [drm]
 ? drm_mode_getcrtc+0x790/0x790 [drm]
 ? drm_getunique+0x220/0x220 [drm]
 ? expand_files.part.10+0x920/0x920
 do_vfs_ioctl+0x1a1/0x13d0
 ? ioctl_preallocate+0x2b0/0x2b0
 ? __fget_light+0x2d6/0x390
 ? schedule+0xd7/0x2e0
 ? fget_raw+0x10/0x10
 ? apic_timer_interrupt+0xa/0x20
 ? apic_timer_interrupt+0xa/0x20
 ? rcu_cleanup_dead_rnp+0x2c0/0x2c0
 ksys_ioctl+0x60/0x90
 __x64_sys_ioctl+0x6f/0xb0
 do_syscall_64+0x136/0x440
 ? 

[PATCH v3 1/4] drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

[Lyude Paul]

In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call
drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we
never successfully allocated VCPI to it. This is contrary to what we do
in drm_dp_mst_allocate_vcpi(), where we only call
drm_dp_mst_get_port_malloc() on the passed port if we successfully
allocated VCPI to it.

As a result, if drm_dp_mst_allocate_vcpi() fails during a modeset and
another successive modeset calls drm_dp_mst_deallocate_vcpi() we will
end up dropping someone else's malloc reference to the port. Example:

[  962.309260] 
==
[  962.309290] BUG: KASAN: use-after-free in 
drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309296] Read of size 4 at addr 888416c30004 by task kworker/0:1H/500

[  962.309308] CPU: 0 PID: 500 Comm: kworker/0:1H Tainted: GW  O  
5.0.0-rc2Lyude-Test+ #1
[  962.309313] Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 
) 04/09/2018
[  962.309428] Workqueue: events_highpri intel_atomic_cleanup_work [i915]
[  962.309434] Call Trace:
[  962.309452]  dump_stack+0xad/0x150
[  962.309462]  ? dump_stack_print_info.cold.0+0x1b/0x1b
[  962.309472]  ? kmsg_dump_rewind_nolock+0xd9/0xd9
[  962.309504]  ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309515]  print_address_description+0x6c/0x23c
[  962.309542]  ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309568]  ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309577]  kasan_report.cold.3+0x1a/0x32
[  962.309605]  ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309631]  drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309658]  ? drm_dp_mst_put_mstb_malloc+0x180/0x180 [drm_kms_helper]
[  962.309687]  drm_dp_mst_destroy_state+0xcd/0x120 [drm_kms_helper]
[  962.309745]  drm_atomic_state_default_clear+0x6ee/0xcc0 [drm]
[  962.309864]  intel_atomic_state_clear+0xe/0x80 [i915]
[  962.309928]  __drm_atomic_state_free+0x35/0xd0 [drm]
[  962.310044]  intel_atomic_cleanup_work+0x56/0x70 [i915]
[  962.310057]  process_one_work+0x884/0x1400
[  962.310067]  ? drain_workqueue+0x5a0/0x5a0
[  962.310075]  ? __schedule+0x87f/0x1e80
[  962.310086]  ? __sched_text_start+0x8/0x8
[  962.310095]  ? run_rebalance_domains+0x400/0x400
[  962.310110]  ? deref_stack_reg+0xb4/0x120
[  962.310117]  ? __read_once_size_nocheck.constprop.7+0x10/0x10
[  962.310124]  ? worker_enter_idle+0x47f/0x6a0
[  962.310134]  ? schedule+0xd7/0x2e0
[  962.310141]  ? __schedule+0x1e80/0x1e80
[  962.310148]  ? _raw_spin_lock_irq+0x9f/0x130
[  962.310155]  ? _raw_write_unlock_irqrestore+0x110/0x110
[  962.310164]  worker_thread+0x196/0x11e0
[  962.310175]  ? set_load_weight+0x2e0/0x2e0
[  962.310181]  ? __switch_to_asm+0x34/0x70
[  962.310187]  ? __switch_to_asm+0x40/0x70
[  962.310194]  ? process_one_work+0x1400/0x1400
[  962.310199]  ? __switch_to_asm+0x40/0x70
[  962.310205]  ? __switch_to_asm+0x34/0x70
[  962.310211]  ? __switch_to_asm+0x34/0x70
[  962.310216]  ? __switch_to_asm+0x40/0x70
[  962.310221]  ? __switch_to_asm+0x34/0x70
[  962.310226]  ? __switch_to_asm+0x40/0x70
[  962.310231]  ? __switch_to_asm+0x34/0x70
[  962.310236]  ? __switch_to_asm+0x40/0x70
[  962.310242]  ? syscall_return_via_sysret+0xf/0x7f
[  962.310248]  ? __switch_to_asm+0x34/0x70
[  962.310253]  ? __switch_to_asm+0x40/0x70
[  962.310258]  ? __switch_to_asm+0x34/0x70
[  962.310263]  ? __switch_to_asm+0x40/0x70
[  962.310268]  ? __switch_to_asm+0x34/0x70
[  962.310273]  ? __switch_to_asm+0x40/0x70
[  962.310281]  ? __schedule+0x87f/0x1e80
[  962.310292]  ? __sched_text_start+0x8/0x8
[  962.310300]  ? save_stack+0x8c/0xb0
[  962.310308]  ? __kasan_kmalloc.constprop.6+0xc6/0xd0
[  962.310313]  ? kthread+0x98/0x3a0
[  962.310318]  ? ret_from_fork+0x35/0x40
[  962.310334]  ? __wake_up_common+0x178/0x6f0
[  962.310343]  ? _raw_spin_lock_irqsave+0xa4/0x140
[  962.310349]  ? __lock_text_start+0x8/0x8
[  962.310355]  ? _raw_write_lock_irqsave+0x70/0x130
[  962.310360]  ? __lock_text_start+0x8/0x8
[  962.310371]  ? process_one_work+0x1400/0x1400
[  962.310376]  kthread+0x2e2/0x3a0
[  962.310383]  ? kthread_create_on_node+0xc0/0xc0
[  962.310389]  ret_from_fork+0x35/0x40

[  962.310401] Allocated by task 1462:
[  962.310410]  __kasan_kmalloc.constprop.6+0xc6/0xd0
[  962.310437]  drm_dp_add_port+0xd60/0x1960 [drm_kms_helper]
[  962.310464]  drm_dp_send_link_address+0x4b0/0x770 [drm_kms_helper]
[  962.310491]  drm_dp_check_and_send_link_address+0x197/0x1f0 [drm_kms_helper]
[  962.310515]  drm_dp_mst_link_probe_work+0x2b6/0x330 [drm_kms_helper]
[  962.310522]  process_one_work+0x884/0x1400
[  962.310529]  worker_thread+0x196/0x11e0
[  962.310533]  kthread+0x2e2/0x3a0
[  962.310538]  ret_from_fork+0x35/0x40

[  962.310543] Freed by task 500:
[  962.310550]  __kasan_slab_free+0x133/0x180
[  962.310555]  kfree+0x92/0x1a0
[  962.310581]  drm_dp_mst_put_port_malloc+0x14d/0x180 [drm_kms_helper]
[  

Re: [PATCH 0/2] drm/vkms: Bugfix for igt-tests

[Shayenne Moura]

Daniel Vetter and I were discussing about this solution. We figured out that
after these patches, tests were passing but when the computer has a heavy
background workload, tests fail.

I tried a new solution. Instead of change the vblank_time variable, make the
`get_vblank_timestamp` return false when is not happening a vblank_irq.

It worked in the same way of our last attempt.

The reason for this change is that, when the timestamp is not accurate,
drm_vblank deals with this correcting timestamp when `get_vblank_timestamp`
returns false. However, this requirement is important when real hardware has an
error, and could not return the accurate vblank. Now, we need to know if our
`vkms_get_vblank_timestamp` should return false and when.

Em qua, 30 de jan de 2019 às 14:05, Shayenne Moura
 escreveu:
>
> This patchset contains patches to fix the extra frame bug on kms_flip
> igt-test. First patch solves the extra vblank frame that breaks many
> tests on kms_flip and second patch solves the race condition caused
> by the solution added in the first one.
>
> Shayenne Moura (2):
>   drm/vkms: Bugfix extra vblank frame
>   drm/vkms: Bugfix racing hrtimer vblank handle
>
>  drivers/gpu/drm/vkms/vkms_crtc.c | 21 +
>  1 file changed, 9 insertions(+), 12 deletions(-)
>
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/4] drm/atomic: Add drm_atomic_state->duplicated

[Lyude Paul]

Important! below

On Fri, 2019-02-01 at 18:57 +0100, Daniel Vetter wrote:
> On Thu, Jan 31, 2019 at 08:14:50PM -0500, Lyude Paul wrote:
> > Since
> > 
> > commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
> > connectors harder")
> > 
> > We've been failing atomic checks if they try to enable new displays on
> > unregistered connectors. This is fine except for the one situation that
> > breaks atomic assumptions: suspend/resume. If a connector is
> > unregistered before we attempt to restore the atomic state, something we
> > end up failing the atomic check that happens when trying to restore the
> > state during resume.
> > 
> > Normally this would be OK: we try our best to make sure that the atomic
> > state pre-suspend can be restored post-suspend, but failures at that
> > point usually don't cause problems. That is of course, until we
> > introduced the new atomic MST VCPI helpers:
> > 
> > [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:65:pipe B]
> > active changed
> > [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing
> > for [CONNECTOR:123:DP-5]
> > [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Disabling
> > [CONNECTOR:123:DP-5]
> > [drm:drm_atomic_get_private_obj_state [drm]] Added new private object
> > 25844636 state 9fd2899a to 3a13d7b8
> > WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153
> > drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
> > Modules linked in: fuse vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek
> > snd_hda_codec_generic joydev iTCO_wdt i915(O) wmi_bmof intel_rapl btusb
> > btrtl x86_pkg_temp_thermal btbcm btintel coretemp i2c_algo_bit
> > drm_kms_helper(O) crc32_pclmul snd_hda_intel syscopyarea sysfillrect
> > snd_hda_codec sysimgblt snd_hda_core bluetooth fb_sys_fops snd_pcm pcspkr
> > drm(O) psmouse snd_timer mei_me ecdh_generic i2c_i801 mei i2c_core
> > ucsi_acpi typec_ucsi typec wmi thinkpad_acpi ledtrig_audio snd soundcore
> > tpm_tis rfkill tpm_tis_core video tpm acpi_pad pcc_cpufreq uas usb_storage
> > crc32c_intel nvme serio_raw xhci_pci nvme_core xhci_hcd
> > CPU: 6 PID: 1070 Comm: gnome-shell Tainted: GW  O  5.0.0-
> > rc2Lyude-Test+ #1
> > Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 )
> > 04/09/2018
> > RIP: 0010:drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
> > Code: 00 4c 39 6d f0 74 49 48 8d 7b 10 48 89 f9 48 c1 e9 03 42 80 3c 21 00
> > 0f 85 d2 00 00 00 48 8b 6b 10 48 8d 5d f0 49 39 ee 75 c5 <0f> 0b 48 c7 c7
> > c0 78 b3 a0 48 89 c2 4c 89 ee e8 03 6c aa ff b8 ea
> > RSP: 0018:88841235f268 EFLAGS: 00010246
> > RAX: 88841bf12ab0 RBX: 88841bf12aa8 RCX: 1110837e2557
> > RDX: dc00 RSI:  RDI: ed108246bde0
> > RBP: 88841bf12ab8 R08: ed1083db3c93 R09: ed1083db3c92
> > R10: ed1083db3c92 R11: 88841ed9e497 R12: 888419555d80
> > R13: 8883bc499100 R14: 88841bf12ab8 R15: 
> > FS:  7f16fbd4cd00() GS:88841ed8()
> > knlGS:
> > CS:  0010 DS:  ES:  CR0: 80050033
> > CR2: 7f1687c9f000 CR3: 0003ba3cc003 CR4: 003606e0
> > DR0:  DR1:  DR2: 
> > DR3:  DR6: fffe0ff0 DR7: 0400
> > Call Trace:
> >  drm_atomic_helper_check_modeset+0xf21/0x2f50 [drm_kms_helper]
> >  ? drm_atomic_helper_commit_modeset_enables+0xa90/0xa90 [drm_kms_helper]
> >  ? __printk_safe_exit+0x10/0x10
> >  ? save_stack+0x8c/0xb0
> >  ? vprintk_func+0x96/0x1bf
> >  ? __printk_safe_exit+0x10/0x10
> >  intel_atomic_check+0x234/0x4750 [i915]
> >  ? printk+0x9f/0xc5
> >  ? kmsg_dump_rewind_nolock+0xd9/0xd9
> >  ? _raw_spin_lock_irqsave+0xa4/0x140
> >  ? drm_atomic_check_only+0xb1/0x28b0 [drm]
> >  ? drm_dbg+0x186/0x1b0 [drm]
> >  ? drm_dev_dbg+0x200/0x200 [drm]
> >  ? intel_link_compute_m_n+0xb0/0xb0 [i915]
> >  ? drm_mode_put_tile_group+0x20/0x20 [drm]
> >  ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915]
> >  ? drm_plane_check_pixel_format+0x14a/0x310 [drm]
> >  drm_atomic_check_only+0x13c4/0x28b0 [drm]
> >  ? drm_state_info+0x220/0x220 [drm]
> >  ? drm_atomic_helper_disable_plane+0x1d0/0x1d0 [drm_kms_helper]
> >  ? pick_single_encoder_for_connector+0xe0/0xe0 [drm_kms_helper]
> >  ? kasan_unpoison_shadow+0x35/0x40
> >  drm_atomic_commit+0x3b/0x100 [drm]
> >  drm_atomic_helper_set_config+0xd5/0x100 [drm_kms_helper]
> >  drm_mode_setcrtc+0x636/0x1660 [drm]
> >  ? vprintk_func+0x96/0x1bf
> >  ? drm_dev_dbg+0x200/0x200 [drm]
> >  ? drm_mode_getcrtc+0x790/0x790 [drm]
> >  ? printk+0x9f/0xc5
> >  ? mutex_unlock+0x1d/0x40
> >  ? drm_mode_addfb2+0x2e9/0x3a0 [drm]
> >  ? rcu_sync_dtor+0x2e0/0x2e0
> >  ? drm_dbg+0x186/0x1b0 [drm]
> >  ? set_page_dirty+0x271/0x4d0
> >  drm_ioctl_kernel+0x203/0x290 [drm]
> >  ? drm_mode_getcrtc+0x790/0x790 [drm]
> >  ? drm_setversion+0x7f0/0x7f0 [drm]
> >  ? 

RE: [PATCH v2 RESEND 2/2] drm/i915/icl: Implement half float formats

[Strasser, Kevin]

Ville Syrjälä wrote:
> > @@ -1774,6 +1776,45 @@ static const u32 skl_planar_formats[] = {
> >DRM_FORMAT_NV12,
> >  };
> >
> > +static const uint32_t icl_hdr_plane_formats[] = {
>
> Please switch to u32 & co. We recently had a mass conversion in the
> driver.

Will do. Looks like the CI caught that too.

> >  static const u64 skl_plane_format_modifiers_noccs[] = {
> >I915_FORMAT_MOD_Yf_TILED,
> >I915_FORMAT_MOD_Y_TILED,
> > @@ -1917,6 +1958,10 @@ static bool skl_plane_format_mod_supported(struct
> > drm_plane *_plane,
> >return true;
> >/* fall through */
> >case DRM_FORMAT_C8:
> > + case DRM_FORMAT_XBGR16161616F:
> > + case DRM_FORMAT_ABGR16161616F:
> > + case DRM_FORMAT_XRGB16161616F:
> > + case DRM_FORMAT_ARGB16161616F:
> >if (modifier == DRM_FORMAT_MOD_LINEAR ||
> >modifier == I915_FORMAT_MOD_X_TILED ||
> >modifier == I915_FORMAT_MOD_Y_TILED)
> > @@ -2053,11 +2098,21 @@ skl_universal_plane_create(struct drm_i915_private
> > *dev_priv,
> >plane->update_slave = icl_update_slave;
> >
> >if (skl_plane_has_planar(dev_priv, pipe, plane_id)) {
> > - formats = skl_planar_formats;
> > - num_formats = ARRAY_SIZE(skl_planar_formats);
> > + if (INTEL_GEN(dev_priv) > 10 && plane_id < PLANE_SPRITE2) {
>
> is_hdr_plane() is around now, please use it.

I don't think I can use icl_is_hdr_plane here without some refactoring. It 
requires the plane->base to be initialized through drm_universal_plane_init, 
which depends on formats/num_formats pointers to be already set.

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

Re: [PATCH v2 2/2] drm/panel: Add driver for Samsung S6E63M0 panel

[Sam Ravnborg]

Hi Paweł

Looks good, thanks for addressing all the review feedback.

On Fri, Feb 01, 2019 at 06:28:52PM +0100, Paweł Chmiel wrote:
> This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over
> spi. It's based on already removed, non dt s6e63m0 driver and
> panel-samsung-ld9040. It can be found for example in some of Samsung
> Aries based phones.
> 
> Signed-off-by: Paweł Chmiel 
If you consider (do not change unless you think it better) the
following nits than you can add my:

Reviewed-by: Sam Ravnborg 

Sam

> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 3f3537719beb..be05ed5218eb 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -158,6 +158,13 @@ config DRM_PANEL_SAMSUNG_S6E63J0X03
>   depends on BACKLIGHT_CLASS_DEVICE
>   select VIDEOMODE_HELPERS
>  
> +config DRM_PANEL_SAMSUNG_S6E63M0
> + tristate "Samsung S6E63M0 RGB/SPI panel"
> + depends on OF
> + depends on SPI
> + depends on BACKLIGHT_CLASS_DEVICE
> + select VIDEOMODE_HELPERS
With the use of display_mode the above "select VIDEOMODE_HELPERS"
is likely no longer required. Please check.

A help text would be nice.

> +
>  config DRM_PANEL_SAMSUNG_S6E8AA0
>   tristate "Samsung S6E8AA0 DSI video mode panel"
>   depends on OF


> +#include 
> +#include 
Please check if these two files are required.

> +struct s6e63m0 {
> + struct device *dev;
> + struct drm_panel panel;
> + struct backlight_device *bl_dev;
> +
> + struct regulator_bulk_data supplies[2];
> + struct gpio_desc *reset_gpio;
> + struct videomode vm;
vm is no longer used - delete it.

> +
> + bool prepared;
> + bool enabled;
> +
> + /*
> +  * This field is tested by functions directly accessing bus before
> +  * transfer, transfer is skipped if it is set. In case of transfer
> +  * failure or unexpected response the field is set to error value.
> +  * Such construct allows to eliminate many checks in higher level
> +  * functions.
> +  */
> + int error;
> +};
> +

> +static int s6e63m0_get_modes(struct drm_panel *panel)
> +{
> + struct drm_connector *connector = panel->connector;
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(panel->drm, _mode);
> + if (!mode) {
> + DRM_ERROR("failed to add mode %ux%ux@%u\n",
> +   default_mode.hdisplay, default_mode.vdisplay,
> +   default_mode.vrefresh);
I recall I have seen a generic way to print the above,
but I have failed to find it.
Maybe it is just my memory that fools me.

The above is fine.

> +
> + s6e63m0_backlight_register(ctx);

Is it correct that we continue even if we fail to register backlight?


> +
> + return 0;
> +}
> +
> +
> +static const struct of_device_id s6e63m0_of_match[] = {
> + { .compatible = "samsung,s6e63m0" },
> + { }

Add /* sentinel */ comment?

> +};

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

Re: [PATCH] drm/amd/display: Use memset to initialize variables in fill_plane_dcc_attributes

[Alex Deucher]

On Fri, Feb 1, 2019 at 3:25 PM Nathan Chancellor
 wrote:
>
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2314:38:
> warning: suggest braces around initialization of subobject
> [-Wmissing-braces]
> struct dc_surface_dcc_cap output = {0};
> ^
> {}
>
> Previous efforts to fix this type of warning by adding or removing
> braces have been met with some pushback in favor of using memset [1][2].
> Do that here, mirroring commit 05794eff1aa6 ("drm/amdgpu/gmc: fix
> compiler errors [-Werror,-Wmissing-braces] (V2)") in this tree.
>
> [1]: 
> https://lore.kernel.org/lkml/022e41c0-8465-dc7a-a45c-64187ecd9...@amd.com/
> [2]: 
> https://lore.kernel.org/lkml/20181128.215241.702406654469517539.da...@davemloft.net/
>
> Fixes: 7df7e505e82a ("drm/amd/display: Set requested plane state DCC params 
> for GFX9")
> Signed-off-by: Nathan Chancellor 

Applied all three patches.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index dccad2d207ce..1c1c162c4eee 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2310,12 +2310,15 @@ static bool fill_plane_dcc_attributes(struct 
> amdgpu_device *adev,
>   uint64_t info)
>  {
> struct dc *dc = adev->dm.dc;
> -   struct dc_dcc_surface_param input = {0};
> -   struct dc_surface_dcc_cap output = {0};
> +   struct dc_dcc_surface_param input;
> +   struct dc_surface_dcc_cap output;
> uint32_t offset = AMDGPU_TILING_GET(info, DCC_OFFSET_256B);
> uint32_t i64b = AMDGPU_TILING_GET(info, DCC_INDEPENDENT_64B) != 0;
> uint64_t dcc_address;
>
> +   memset(, 0, sizeof(input));
> +   memset(, 0, sizeof(output));
> +
> if (!offset)
> return false;
>
> --
> 2.20.1
>
> ___
> 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

Re: [PATCH v4 0/9] mmu notifier provide context informations

[Jan Kara]

On Thu 31-01-19 11:10:06, Jerome Glisse wrote:
> 
> Andrew what is your plan for this ? I had a discussion with Peter Xu
> and Andrea about change_pte() and kvm. Today the change_pte() kvm
> optimization is effectively disabled because of invalidate_range
> calls. With a minimal couple lines patch on top of this patchset
> we can bring back the kvm change_pte optimization and we can also
> optimize some other cases like for instance when write protecting
> after fork (but i am not sure this is something qemu does often so
> it might not help for real kvm workload).
> 
> I will be posting a the extra patch as an RFC, but in the meantime
> i wanted to know what was the status for this.
> 
> Jan, Christian does your previous ACK still holds for this ?

Yes, I still think the approach makes sense. Dan's concern about in tree
users is valid but it seems you have those just not merged yet, right?

Honza

-- 
Jan Kara 
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 RESEND 2/2] drm/i915/icl: Implement half float formats

[Ville Syrjälä]

On Fri, Feb 01, 2019 at 09:43:40AM -0800, Kevin Strasser wrote:
> 64 bpp half float formats are supported on hdr planes only and are subject
> to the following restrictions:
>   * 90/270 rotation not supported
>   * Yf Tiling not supported
>   * Frame Buffer Compression not supported
>   * Color Keying not supported
> 
> v2:
> - Drop handling pixel normalize register
> - Don't use icl_is_hdr_plane too early
> 
> Signed-off-by: Kevin Strasser 
> Cc: Uma Shankar 
> Cc: Shashank Sharma 
> Cc: Ville Syrjälä 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/i915/intel_display.c | 22 
>  drivers/gpu/drm/i915/intel_sprite.c  | 67 
> 
>  2 files changed, 83 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a6d8985..f413ccd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2668,6 +2668,18 @@ int skl_format_to_fourcc(int format, bool rgb_order, 
> bool alpha)
>   return DRM_FORMAT_RGB565;
>   case PLANE_CTL_FORMAT_NV12:
>   return DRM_FORMAT_NV12;
> + case PLANE_CTL_FORMAT_XRGB_16161616F:
> + if (rgb_order) {
> + if (alpha)
> + return DRM_FORMAT_ABGR16161616F;
> + else
> + return DRM_FORMAT_XBGR16161616F;
> + } else {
> + if (alpha)
> + return DRM_FORMAT_ARGB16161616F;
> + else
> + return DRM_FORMAT_XRGB16161616F;
> + }
>   default:
>   case PLANE_CTL_FORMAT_XRGB_:
>   if (rgb_order) {
> @@ -3566,6 +3578,12 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
>   return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
>   case DRM_FORMAT_NV12:
>   return PLANE_CTL_FORMAT_NV12;
> + case DRM_FORMAT_XBGR16161616F:
> + case DRM_FORMAT_ABGR16161616F:
> + return PLANE_CTL_FORMAT_XRGB_16161616F | PLANE_CTL_ORDER_RGBX;
> + case DRM_FORMAT_XRGB16161616F:
> + case DRM_FORMAT_ARGB16161616F:
> + return PLANE_CTL_FORMAT_XRGB_16161616F;
>   default:
>   MISSING_CASE(pixel_format);
>   }
> @@ -5069,6 +5087,10 @@ static int skl_update_scaler_plane(struct 
> intel_crtc_state *crtc_state,
>   case DRM_FORMAT_UYVY:
>   case DRM_FORMAT_VYUY:
>   case DRM_FORMAT_NV12:
> + case DRM_FORMAT_XBGR16161616F:
> + case DRM_FORMAT_ABGR16161616F:
> + case DRM_FORMAT_XRGB16161616F:
> + case DRM_FORMAT_ARGB16161616F:
>   break;
>   default:
>   DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
> 0x%x\n",
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index cd42e81..97f9d05 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1450,8 +1450,6 @@ static int skl_plane_check_fb(const struct 
> intel_crtc_state *crtc_state,
>   /*
>* 90/270 is not allowed with RGB64 16:16:16:16 and
>* Indexed 8-bit. RGB 16-bit 5:6:5 is allowed gen11 onwards.
> -  * TBD: Add RGB64 case once its added in supported format
> -  * list.
>*/
>   switch (fb->format->format) {
>   case DRM_FORMAT_RGB565:
> @@ -1459,6 +1457,10 @@ static int skl_plane_check_fb(const struct 
> intel_crtc_state *crtc_state,
>   break;
>   /* fall through */
>   case DRM_FORMAT_C8:
> + case DRM_FORMAT_XRGB16161616F:
> + case DRM_FORMAT_XBGR16161616F:
> + case DRM_FORMAT_ARGB16161616F:
> + case DRM_FORMAT_ABGR16161616F:
>   DRM_DEBUG_KMS("Unsupported pixel format %s for 
> 90/270!\n",
> drm_get_format_name(fb->format->format,
> _name));
> @@ -1774,6 +1776,45 @@ static const u32 skl_planar_formats[] = {
>   DRM_FORMAT_NV12,
>  };
>  
> +static const uint32_t icl_hdr_plane_formats[] = {

Please switch to u32 & co. We recently had a mass conversion in the
driver.

> + DRM_FORMAT_C8,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_XRGB2101010,
> + DRM_FORMAT_XBGR2101010,

I just noticed that icl should also support alpha for 10bpc. But that's
not relevant for this patch.

> + DRM_FORMAT_XRGB16161616F,
> + DRM_FORMAT_XBGR16161616F,
> + DRM_FORMAT_ARGB16161616F,
> + DRM_FORMAT_ABGR16161616F,
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_YVYU,
> + DRM_FORMAT_UYVY,
> + 

Re: linux-next: Fixes tags need some work in the drm tree

[Alex Deucher]

On Fri, Feb 1, 2019 at 5:05 AM Daniel Vetter  wrote:
>
> On Fri, Feb 1, 2019 at 12:57 AM Stephen Rothwell  
> wrote:
> >
> > Hi all,
> >
> > In commit
> >
> >   a93587b31e34 ("drm/amd/display: Only get the connector state for VRR when 
> > toggled")
> >
> > Fixes tag
> >
> >   Fixes: 3cc22f281318 ("drm/amdgpu: Set FreeSync state using drm VRR 
> > properties")
> >
> > has these problem(s):
> >
> >   - Target SHA1 does not exist
> >
> > Maybe instead:
> >
> >   FIxes: bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR 
> > properties")
> >
> > In commit
> >
> >   32e61361b82e ("drm/amd/display: Fix 64-bit division for 32-bit builds")
> >
> > Fixes tag
> >
> >   Fixes: 
> > https://lists.freedesktop.org/archives/dri-devel/2018-December/201008.html
> >
> > has these problem(s):
> >
> >   - No SHA1 recognised
> >
> > Maybe instead:
> >
> >   Fixes: 80604e27bc9 ("drm/amd/display: Use 100 Hz precision for pipe pixel 
> > clocks")
> >
> > In commit
> >
> >   c4312c27c826 ("drm/amdgpu: Cleanup 2 compiler warnings")
> >
> > Fixes tag
> >
> >   Fixes: e4ae0fc drm/amdgpu: implement gfx8 post_soft_reset
> >
> > has these problem(s):
> >
> >   - SHA1 should be at least 12 digits long
> > Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
> > or later) just making sure it is not set (or set to "auto").
> >
> > Fixes tag
> >
> >   Fixes: 5e01c09 drm/amdgpu/gfx_v8_0: Reorder the gfx, kiq and kcq rings
> >
> > has these problem(s):
> >
> >   - Target SHA1 does not exist
> >
> > Maybe instead:
> >
> >   Fixes: c6064de4b734 ("drm/amdgpu/gfx_v8_0: Reorder the gfx, kiq and kcq 
> > rings test sequence")
>
> Yeah the top 71 commits in the latest amdgpu pull got rebased, which
> is a bit much. Where are we with the "direct group commit, no more
> rebases" project for amd? Still stuck on CI troubles?

In fairness, some of the rebasing was to squash in some bug fixes to
help with bisecting.  As to direct commit, not enough internal
priority at the moment and too many other projects.  I'll try to
double check them better going forward.

Alex

>
> Another one: Is the above checker script available somewhere, could be
> useful to put that into our own scripts to make sure this doesn't
> happen again.
> -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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][drm-next] drm/amd/amdgpu: fix spelling mistake "matech" -> "match"

[Alex Deucher]

On Fri, Feb 1, 2019 at 5:42 AM Colin King  wrote:
>
> From: Colin Ian King 
>
> There is a spelling mistake in a dev_err message. Fix it.
>
> Signed-off-by: Colin Ian King 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> index dac187454b33..2ae25095e501 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> @@ -129,7 +129,7 @@ int amdgpu_xgmi_add_device(struct amdgpu_device *adev)
> if (!hive) {
> ret = -EINVAL;
> dev_err(adev->dev,
> -   "XGMI: node 0x%llx, can not matech hive 0x%llx in the 
> hive list.\n",
> +   "XGMI: node 0x%llx, can not match hive 0x%llx in the 
> hive list.\n",
> adev->gmc.xgmi.node_id, adev->gmc.xgmi.hive_id);
> goto exit;
> }
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 RESEND 1/2] drm/fourcc: Add 64 bpp half float formats

[Ville Syrjälä]

On Fri, Feb 01, 2019 at 09:43:39AM -0800, Kevin Strasser wrote:
> Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
> formatted in IEEE-754 half-precision float (binary16) 1:5:10
> MSb-sign:exponent:fraction form.
> 
> This patch attempts to address the feedback provided when 2 of these
> formats were previosly proposed:
>   https://patchwork.kernel.org/patch/10072545/
> 
> v2:
> - Fixed cpp (Ville)
> - Added detail pixel formatting (Ville)
> - Ordered formats in header (Ville)
> 
> Signed-off-by: Kevin Strasser 
> Cc: Tina Zhang 
> Cc: Uma Shankar 
> Cc: Shashank Sharma 
> Cc: Ville Syrjälä 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org

This lgtm:
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_fourcc.c  |  4 
>  include/uapi/drm/drm_fourcc.h | 11 +++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index d90ee03..c866452 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -198,6 +198,10 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
>   { .format = DRM_FORMAT_ABGR,.depth = 32, 
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
>   { .format = DRM_FORMAT_RGBA,.depth = 32, 
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
>   { .format = DRM_FORMAT_BGRA,.depth = 32, 
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
> + { .format = DRM_FORMAT_XRGB16161616F,   .depth = 48, 
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> + { .format = DRM_FORMAT_XBGR16161616F,   .depth = 48, 
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> + { .format = DRM_FORMAT_ARGB16161616F,   .depth = 64, 
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
> + { .format = DRM_FORMAT_ABGR16161616F,   .depth = 64, 
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
>   { .format = DRM_FORMAT_RGB888_A8,   .depth = 32, 
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
>   { .format = DRM_FORMAT_BGR888_A8,   .depth = 32, 
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
>   { .format = DRM_FORMAT_XRGB_A8, .depth = 32, 
> .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 91d08a2..c516b40 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -144,6 +144,17 @@ extern "C" {
>  #define DRM_FORMAT_RGBA1010102   fourcc_code('R', 'A', '3', '0') /* 
> [31:0] R:G:B:A 10:10:10:2 little endian */
>  #define DRM_FORMAT_BGRA1010102   fourcc_code('B', 'A', '3', '0') /* 
> [31:0] B:G:R:A 10:10:10:2 little endian */
>  
> +/*
> + * Floating point 64bpp RGB
> + * IEEE 754-2008 binary16 half-precision float
> + * [15:0] sign:exponent:mantissa 1:5:10
> + */
> +#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0] 
> x:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0] 
> x:B:G:R 16:16:16:16 little endian */
> +
> +#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0] 
> A:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0] 
> A:B:G:R 16:16:16:16 little endian */
> +
>  /* packed YCbCr */
>  #define DRM_FORMAT_YUYV  fourcc_code('Y', 'U', 'Y', 'V') /* 
> [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
>  #define DRM_FORMAT_YVYU  fourcc_code('Y', 'V', 'Y', 'U') /* 
> [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
> -- 
> 2.7.4

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

[tegra-drm:drm/tegra/for-next 10/24] drivers/gpu/host1x/cdma.c:253:13: error: 'struct host1x_cdma' has no member named 'sem'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
head:   e01c78172871cc703e6228fe2b195a3876e1a0a9
commit: db5652be58a96bdde402cabebc0567ee08631276 [10/24] gpu: host1x: Introduce 
support for wide opcodes
config: arm-tegra_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 8.2.0-11) 8.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout db5652be58a96bdde402cabebc0567ee08631276
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/gpu/host1x/cdma.c: In function 'host1x_cdma_wait_pushbuffer_space':
>> drivers/gpu/host1x/cdma.c:253:13: error: 'struct host1x_cdma' has no member 
>> named 'sem'
  down(>sem);
^~

vim +253 drivers/gpu/host1x/cdma.c

   219  
   220  /*
   221   * Sleep (if necessary) until the push buffer has enough free space.
   222   *
   223   * Must be called with the cdma lock held.
   224   */
   225  int host1x_cdma_wait_pushbuffer_space(struct host1x *host1x,
   226struct host1x_cdma *cdma,
   227unsigned int needed)
   228  {
   229  while (true) {
   230  struct push_buffer *pb = >push_buffer;
   231  unsigned int space;
   232  
   233  space = host1x_pushbuffer_space(pb);
   234  if (space >= needed)
   235  break;
   236  
   237  
trace_host1x_wait_cdma(dev_name(cdma_to_channel(cdma)->dev),
   238 CDMA_EVENT_PUSH_BUFFER_SPACE);
   239  
   240  host1x_hw_cdma_flush(host1x, cdma);
   241  
   242  /* If somebody has managed to already start waiting, 
yield */
   243  if (cdma->event != CDMA_EVENT_NONE) {
   244  mutex_unlock(>lock);
   245  schedule();
   246  mutex_lock(>lock);
   247  continue;
   248  }
   249  
   250  cdma->event = CDMA_EVENT_PUSH_BUFFER_SPACE;
   251  
   252  mutex_unlock(>lock);
 > 253  down(>sem);
   254  mutex_lock(>lock);
   255  }
   256  
   257  return 0;
   258  }
   259  /*
   260   * Start timer that tracks the time spent by the job.
   261   * Must be called with the cdma lock held.
   262   */
   263  static void cdma_start_timer_locked(struct host1x_cdma *cdma,
   264  struct host1x_job *job)
   265  {
   266  struct host1x *host = cdma_to_host1x(cdma);
   267  
   268  if (cdma->timeout.client) {
   269  /* timer already started */
   270  return;
   271  }
   272  
   273  cdma->timeout.client = job->client;
   274  cdma->timeout.syncpt = host1x_syncpt_get(host, job->syncpt_id);
   275  cdma->timeout.syncpt_val = job->syncpt_end;
   276  cdma->timeout.start_ktime = ktime_get();
   277  
   278  schedule_delayed_work(>timeout.wq,
   279msecs_to_jiffies(job->timeout));
   280  }
   281  

---
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: [v10 2/3] drm: Add DP colorspace property

[Ville Syrjälä]

On Wed, Jan 30, 2019 at 06:24:25PM +0530, Uma Shankar wrote:
> This patch adds a DP colorspace property, enabling
> userspace to switch to various supported colorspaces.
> This will help enable BT2020 along with other colorspaces.
> 
> v2: Addressed Maarten and Ville's review comments. Enhanced
> the colorspace enum to incorporate both HDMI and DP supported
> colorspaces. Also, added a default option for colorspace.
> 
> v3: Split the changes to have separate colorspace property for
> DP and HDMI.
> 
> v4: Addressed Chris and Ville's review comments, and created a
> common colorspace property for DP and HDMI, filtered the list
> based on the colorspaces supported by the respective protocol
> standard.
> 
> v5: Merged the DP handling along with platform colorspace
> handling as per Shashank's comments.
> 
> v6: Reverted to old design of exposing all colorspaces to
> userspace as per Ville's review comment
> 
> v7: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
> 
> Signed-off-by: Uma Shankar 
> Acked-by: Jani Nikula 
> Reviewed-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_connector.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index ed10dd9..b331be8 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -850,6 +850,29 @@ int drm_display_info_set_bus_formats(struct 
> drm_display_info *info,
>   { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
>  };
>  
> +static const struct drm_prop_enum_list dp_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> + /* Standard Definition Colorimetry based on CEA 861 */
> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },

What's with the duplicated 601/709 values? I think in the HDMI verison
you had only these ones here. Maybe we want to actually state explicitly
that they are for YCbCr, if only to be consistent with the
BT2020 values.

> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> + /* Colorimetry based on IEC 61966-2-5 */
> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> + /* DP MSA Colorimetry */
> + { DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601, "YCBCR_ITU_601" },
> + { DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709, "YCBCR_ITU_709" },
> + { DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
> + { DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
> + { DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" },
> + { DRM_MODE_DP_COLORIMETRY_DCI_P3, "DCI-P3" },
> + { DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE, "Custom Profile" },

I don't think we want this last one since we don't implement anything
that could transmit the custom profile.

The MSA bits are have "CEA RGB" which we probably want to keep hidden
since it seems to be just a poorly specced limited range vs. full range
knob, and we already have a mechanism for that. The Y-only and RAW I
guess we can skip. Not sure anyone would ever have use for those.

> +};
> +
> +
>  /**
>   * DOC: standard connector properties
>   *
> @@ -1611,6 +1634,14 @@ int drm_mode_create_colorspace_property(struct 
> drm_connector *connector)
>   ARRAY_SIZE(hdmi_colorspaces));
>   if (!prop)
>   return -ENOMEM;
> + } else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
> +connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) 
> {
> + prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
> + "Colorspace", dp_colorspaces,
> + ARRAY_SIZE(dp_colorspaces));
> +
> + if (!prop)
> + return -ENOMEM;
>   } else {
>   DRM_DEBUG_KMS("Colorspace property not supported\n");
>   return 0;
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [v10 3/3] drm/i915: Attach colorspace property and enable modeset

[Ville Syrjälä]

On Wed, Jan 30, 2019 at 06:24:26PM +0530, Uma Shankar wrote:
> This patch attaches the colorspace connector property to the
> hdmi connector. Based on colorspace change, modeset will be
> triggered to switch to new colorspace.
> 
> Based on colorspace property value create an infoframe
> with appropriate colorspace. This can be used to send an
> infoframe packet with proper colorspace value set which
> will help to enable wider color gamut like BT2020 on sink.
> 
> This patch attaches and enables HDMI colorspace, DP will be
> taken care separately.
> 
> v2: Merged the changes of creating infoframe as well to this
> patch as per Maarten's suggestion.
> 
> v3: Addressed review comments from Shashank. Separated HDMI
> and DP colorspaces as suggested by Ville and Maarten.
> 
> v4: Addressed Chris and Ville's review comments, and created a
> common colorspace property for DP and HDMI, filtered the list
> based on the colorspaces supported by the respective protocol
> standard. Handle the default case properly.
> 
> v5: Merged the DP handling along with platform colorspace
> handling as per Shashank's comments.
> 
> v6: Reverted to old design of exposing all colorspaces to
> userspace as per Ville's review comment
> 
> v7: Fixed a checkpatch complaint, Addressed  Maarten' review
> comment, updated the RB from Maarten and Jani's ack.
> 
> Signed-off-by: Uma Shankar 
> Acked-by: Jani Nikula 
> Reviewed-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_atomic.c|  1 +
>  drivers/gpu/drm/i915/intel_connector.c |  8 
>  drivers/gpu/drm/i915/intel_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_hdmi.c  | 25 +
>  4 files changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 16263ad..a4bb906 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct 
> drm_connector *conn,
>*/
>   if (new_conn_state->force_audio != old_conn_state->force_audio ||
>   new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
> + new_conn_state->base.colorspace != old_conn_state->base.colorspace 
> ||
>   new_conn_state->base.picture_aspect_ratio != 
> old_conn_state->base.picture_aspect_ratio ||
>   new_conn_state->base.content_type != 
> old_conn_state->base.content_type ||
>   new_conn_state->base.scaling_mode != 
> old_conn_state->base.scaling_mode)
> diff --git a/drivers/gpu/drm/i915/intel_connector.c 
> b/drivers/gpu/drm/i915/intel_connector.c
> index ee16758..8352d0b 100644
> --- a/drivers/gpu/drm/i915/intel_connector.c
> +++ b/drivers/gpu/drm/i915/intel_connector.c
> @@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector *connector,
>   connector->dev->mode_config.aspect_ratio_property,
>   DRM_MODE_PICTURE_ASPECT_NONE);
>  }
> +
> +void
> +intel_attach_colorspace_property(struct drm_connector *connector)
> +{
> + if (!drm_mode_create_colorspace_property(connector))
> + drm_object_attach_property(>base,
> +connector->colorspace_property, 0);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 85b913e..5178a9a 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1783,6 +1783,7 @@ int intel_connector_update_modes(struct drm_connector 
> *connector,
>  void intel_attach_force_audio_property(struct drm_connector *connector);
>  void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
>  void intel_attach_aspect_ratio_property(struct drm_connector *connector);
> +void intel_attach_colorspace_property(struct drm_connector *connector);
>  
>  /* intel_csr.c */
>  void intel_csr_ucode_init(struct drm_i915_private *);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 97a98e1..5c5009d 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -498,6 +498,24 @@ static void intel_hdmi_set_avi_infoframe(struct 
> intel_encoder *encoder,
>   else
>   frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>  
> + if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
> + /* Set ITU 709 as default for HDMI */
> + frame.avi.colorimetry = DRM_MODE_COLORIMETRY_ITU_709;

Default should map to NONE.

> + } else if (conn_state->colorspace < DRM_MODE_COLORIMETRY_XV_YCC_601) {
> + frame.avi.colorimetry = conn_state->colorspace;
> + } else {
> + frame.avi.colorimetry = HDMI_COLORIMETRY_EXTENDED;
> + /*
> +  * Starting from extended list where COLORIMETRY_XV_YCC_601
> +  * is the first extended mode and its value is 0 as per HDMI
> +  * specification.
> + 

Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property

[Ville Syrjälä]

On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
> Create a new connector property to program colorspace to sink
> devices. Modern sink devices support more than 1 type of
> colorspace like 601, 709, BT2020 etc. This helps to switch
> based on content type which is to be displayed. The decision
> lies with compositors as to in which scenarios, a particular
> colorspace will be picked.
> 
> This will be helpful mostly to switch to higher gamut colorspaces
> like BT2020 when the media content is encoded as BT2020. Thereby
> giving a good visual experience to users.
> 
> The expectation from userspace is that it should parse the EDID
> and get supported colorspaces. Use this property and switch to the
> one supported. Sink supported colorspaces should be retrieved by
> userspace from EDID and driver will not explicitly expose them.
> 
> Basically the expectation from userspace is:
>  - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>colorspace
>  - Set this new property to let the sink know what it
>converted the CRTC output to.
> 
> v2: Addressed Maarten and Ville's review comments. Enhanced
> the colorspace enum to incorporate both HDMI and DP supported
> colorspaces. Also, added a default option for colorspace.
> 
> v3: Removed Adobe references from enum definitions as per
> Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
> Default to an unset state where driver will assign the colorspace
> is not chosen by user, suggested by Ville and Maarten. Addressed
> other misc review comments from Maarten. Split the changes to
> have separate colorspace property for DP and HDMI.
> 
> v4: Addressed Chris and Ville's review comments, and created a
> common colorspace property for DP and HDMI, filtered the list
> based on the colorspaces supported by the respective protocol
> standard.
> 
> v5: Made the property creation helper accept enum list based on
> platform capabilties as suggested by Shashank. Consolidated HDMI
> and DP property creation in the common helper.
> 
> v6: Addressed Shashank's review comments.
> 
> v7: Added defines instead of enum in uapi as per Brian Starkey's
> suggestion in order to go with string matching at userspace. Updated
> the commit message to add more details as well kernel docs.
> 
> v8: Addressed Maarten's review comments.
> 
> v9: Removed macro defines from uapi as per Brian Starkey and Daniel
> Stone's comments and moved to drm include file. Moved back to older
> design with exposing all HDMI colorspaces to userspace since infoframe
> capability is there even on legacy platforms, as per Ville's review
> comments.
> 
> v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
> 
> Signed-off-by: Uma Shankar 
> Acked-by: Jani Nikula 
> Reviewed-by: Shashank Sharma 
> Reviewed-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic_uapi.c |  4 +++
>  drivers/gpu/drm/drm_connector.c   | 75 
> +++
>  include/drm/drm_connector.h   | 46 
>  3 files changed, 125 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 9a1f41a..9b5d44f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   return -EINVAL;
>   }
>   state->content_protection = val;
> + } else if (property == connector->colorspace_property) {
> + state->colorspace = val;
>   } else if (property == config->writeback_fb_id_property) {
>   struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
> val);
>   int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
> @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   *val = state->picture_aspect_ratio;
>   } else if (property == config->content_type_property) {
>   *val = state->content_type;
> + } else if (property == connector->colorspace_property) {
> + *val = state->colorspace;
>   } else if (property == connector->scaling_mode_property) {
>   *val = state->scaling_mode;
>   } else if (property == connector->content_protection_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 8475396..ed10dd9 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -826,6 +826,30 @@ int drm_display_info_set_bus_formats(struct 
> drm_display_info *info,
>  };
>  DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
>  
> +static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> + /* Standard Definition Colorimetry based on CEA 861 */
> + { 

Re: [PATCH v2 3/4] drm/atomic: Add drm_atomic_state->duplicated

[Daniel Vetter]

On Thu, Jan 31, 2019 at 08:14:50PM -0500, Lyude Paul wrote:
> Since
> 
> commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
> connectors harder")
> 
> We've been failing atomic checks if they try to enable new displays on
> unregistered connectors. This is fine except for the one situation that
> breaks atomic assumptions: suspend/resume. If a connector is
> unregistered before we attempt to restore the atomic state, something we
> end up failing the atomic check that happens when trying to restore the
> state during resume.
> 
> Normally this would be OK: we try our best to make sure that the atomic
> state pre-suspend can be restored post-suspend, but failures at that
> point usually don't cause problems. That is of course, until we
> introduced the new atomic MST VCPI helpers:
> 
> [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:65:pipe B] 
> active changed
> [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for 
> [CONNECTOR:123:DP-5]
> [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Disabling 
> [CONNECTOR:123:DP-5]
> [drm:drm_atomic_get_private_obj_state [drm]] Added new private object 
> 25844636 state 9fd2899a to 3a13d7b8
> WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153 
> drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
> Modules linked in: fuse vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek 
> snd_hda_codec_generic joydev iTCO_wdt i915(O) wmi_bmof intel_rapl btusb btrtl 
> x86_pkg_temp_thermal btbcm btintel coretemp i2c_algo_bit drm_kms_helper(O) 
> crc32_pclmul snd_hda_intel syscopyarea sysfillrect snd_hda_codec sysimgblt 
> snd_hda_core bluetooth fb_sys_fops snd_pcm pcspkr drm(O) psmouse snd_timer 
> mei_me ecdh_generic i2c_i801 mei i2c_core ucsi_acpi typec_ucsi typec wmi 
> thinkpad_acpi ledtrig_audio snd soundcore tpm_tis rfkill tpm_tis_core video 
> tpm acpi_pad pcc_cpufreq uas usb_storage crc32c_intel nvme serio_raw xhci_pci 
> nvme_core xhci_hcd
> CPU: 6 PID: 1070 Comm: gnome-shell Tainted: GW  O  
> 5.0.0-rc2Lyude-Test+ #1
> Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018
> RIP: 0010:drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
> Code: 00 4c 39 6d f0 74 49 48 8d 7b 10 48 89 f9 48 c1 e9 03 42 80 3c 21 00 0f 
> 85 d2 00 00 00 48 8b 6b 10 48 8d 5d f0 49 39 ee 75 c5 <0f> 0b 48 c7 c7 c0 78 
> b3 a0 48 89 c2 4c 89 ee e8 03 6c aa ff b8 ea
> RSP: 0018:88841235f268 EFLAGS: 00010246
> RAX: 88841bf12ab0 RBX: 88841bf12aa8 RCX: 1110837e2557
> RDX: dc00 RSI:  RDI: ed108246bde0
> RBP: 88841bf12ab8 R08: ed1083db3c93 R09: ed1083db3c92
> R10: ed1083db3c92 R11: 88841ed9e497 R12: 888419555d80
> R13: 8883bc499100 R14: 88841bf12ab8 R15: 
> FS:  7f16fbd4cd00() GS:88841ed8() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7f1687c9f000 CR3: 0003ba3cc003 CR4: 003606e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  drm_atomic_helper_check_modeset+0xf21/0x2f50 [drm_kms_helper]
>  ? drm_atomic_helper_commit_modeset_enables+0xa90/0xa90 [drm_kms_helper]
>  ? __printk_safe_exit+0x10/0x10
>  ? save_stack+0x8c/0xb0
>  ? vprintk_func+0x96/0x1bf
>  ? __printk_safe_exit+0x10/0x10
>  intel_atomic_check+0x234/0x4750 [i915]
>  ? printk+0x9f/0xc5
>  ? kmsg_dump_rewind_nolock+0xd9/0xd9
>  ? _raw_spin_lock_irqsave+0xa4/0x140
>  ? drm_atomic_check_only+0xb1/0x28b0 [drm]
>  ? drm_dbg+0x186/0x1b0 [drm]
>  ? drm_dev_dbg+0x200/0x200 [drm]
>  ? intel_link_compute_m_n+0xb0/0xb0 [i915]
>  ? drm_mode_put_tile_group+0x20/0x20 [drm]
>  ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915]
>  ? drm_plane_check_pixel_format+0x14a/0x310 [drm]
>  drm_atomic_check_only+0x13c4/0x28b0 [drm]
>  ? drm_state_info+0x220/0x220 [drm]
>  ? drm_atomic_helper_disable_plane+0x1d0/0x1d0 [drm_kms_helper]
>  ? pick_single_encoder_for_connector+0xe0/0xe0 [drm_kms_helper]
>  ? kasan_unpoison_shadow+0x35/0x40
>  drm_atomic_commit+0x3b/0x100 [drm]
>  drm_atomic_helper_set_config+0xd5/0x100 [drm_kms_helper]
>  drm_mode_setcrtc+0x636/0x1660 [drm]
>  ? vprintk_func+0x96/0x1bf
>  ? drm_dev_dbg+0x200/0x200 [drm]
>  ? drm_mode_getcrtc+0x790/0x790 [drm]
>  ? printk+0x9f/0xc5
>  ? mutex_unlock+0x1d/0x40
>  ? drm_mode_addfb2+0x2e9/0x3a0 [drm]
>  ? rcu_sync_dtor+0x2e0/0x2e0
>  ? drm_dbg+0x186/0x1b0 [drm]
>  ? set_page_dirty+0x271/0x4d0
>  drm_ioctl_kernel+0x203/0x290 [drm]
>  ? drm_mode_getcrtc+0x790/0x790 [drm]
>  ? drm_setversion+0x7f0/0x7f0 [drm]
>  ? __switch_to_asm+0x34/0x70
>  ? __switch_to_asm+0x34/0x70
>  drm_ioctl+0x445/0x950 [drm]
>  ? drm_mode_getcrtc+0x790/0x790 [drm]
>  ? drm_getunique+0x220/0x220 [drm]
>  ? expand_files.part.10+0x920/0x920
>  do_vfs_ioctl+0x1a1/0x13d0
>  ? ioctl_preallocate+0x2b0/0x2b0
>  ? 

Re: [PATCH v2 2/4] drm/dp_mst: Remove port validation in drm_dp_atomic_find_vcpi_slots()

[Daniel Vetter]

On Thu, Jan 31, 2019 at 08:14:49PM -0500, Lyude Paul wrote:
> Since we now have an easy way of refcounting drm_dp_mst_port structs and
> safely accessing their contents, there isn't any good reason to keep
> validating ports here. It doesn't prevent us from performing modesets on
> branch devices that have been removed either, and we already disallow
> enabling new displays on unregistered connectors in
> update_connector_routing() in drm_atomic_check_modeset(). All it does is
> cause us to have to make weird special exceptions in our atomic
> modesetting code. So, get rid of it entirely.
> 
> Signed-off-by: Lyude Paul 
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c   | 12 ++--
>  drivers/gpu/drm/i915/intel_dp_mst.c | 17 ++---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c |  3 +--
>  3 files changed, 9 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index abb0ea8ba9d9..4325e1518286 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3117,10 +3117,6 @@ int drm_dp_atomic_find_vcpi_slots(struct 
> drm_atomic_state *state,
>   if (IS_ERR(topology_state))
>   return PTR_ERR(topology_state);
>  
> - port = drm_dp_mst_topology_get_port_validated(mgr, port);
> - if (port == NULL)
> - return -EINVAL;
> -
>   /* Find the current allocation for this port, if any */
>   list_for_each_entry(pos, _state->vcpis, next) {
>   if (pos->port == port) {

Also noticed that the WARN_ON() return -EINVAL; here gets fixed with this
patch.

Reviewed-by: Daniel Vetter 

> @@ -3153,10 +3149,8 @@ int drm_dp_atomic_find_vcpi_slots(struct 
> drm_atomic_state *state,
>   /* Add the new allocation to the state */
>   if (!vcpi) {
>   vcpi = kzalloc(sizeof(*vcpi), GFP_KERNEL);
> - if (!vcpi) {
> - ret = -ENOMEM;
> - goto out;
> - }
> + if (!vcpi)
> + return -ENOMEM;
>  
>   drm_dp_mst_get_port_malloc(port);
>   vcpi->port = port;
> @@ -3165,8 +3159,6 @@ int drm_dp_atomic_find_vcpi_slots(struct 
> drm_atomic_state *state,
>   vcpi->vcpi = req_slots;
>  
>   ret = req_slots;
> -out:
> - drm_dp_mst_topology_put_port(port);
>   return ret;
>  }
>  EXPORT_SYMBOL(drm_dp_atomic_find_vcpi_slots);
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index cdb83d294cdd..fb67cd931117 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -80,17 +80,12 @@ static int intel_dp_mst_compute_config(struct 
> intel_encoder *encoder,
>   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
>   pipe_config->pbn = mst_pbn;
>  
> - /* Zombie connectors can't have VCPI slots */
> - if (!drm_connector_is_unregistered(connector)) {
> - slots = drm_dp_atomic_find_vcpi_slots(state,
> -   _dp->mst_mgr,
> -   port,
> -   mst_pbn);
> - if (slots < 0) {
> - DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
> -   slots);
> - return slots;
> - }
> + slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr, port,
> +   mst_pbn);
> + if (slots < 0) {
> + DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
> +   slots);
> + return slots;
>   }
>  
>   intel_link_compute_m_n(bpp, lane_count,
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 2e8a5fd9b262..60d858c2f2ce 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -771,8 +771,7 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
>   mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
>bpp);
>  
> - if (drm_atomic_crtc_needs_modeset(crtc_state) &&
> - !drm_connector_is_unregistered(connector)) {
> + if (drm_atomic_crtc_needs_modeset(crtc_state)) {
>   slots = drm_dp_atomic_find_vcpi_slots(state, >mgr,
> mstc->port, mstc->pbn);
>   if (slots < 0)
> -- 
> 2.20.1
> 

-- 
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 v4.1 0/3] CRTC background color

[Matt Roper]

On Fri, Feb 01, 2019 at 06:13:48PM +0100, Daniel Vetter wrote:
> On Wed, Jan 30, 2019 at 03:48:50PM -0800, Matt Roper wrote:
> > On Wed, Jan 30, 2019 at 09:57:10PM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 30, 2019 at 10:56:26AM -0800, Matt Roper wrote:
> > > > On Wed, Jan 30, 2019 at 10:51:19AM -0800, Matt Roper wrote:
> > > > > Previous patch series was here:
> > > > >   
> > > > > https://lists.freedesktop.org/archives/dri-devel/2018-December/201949.html
> > > > > 
> > > > > I'm told the ChromeOS userspace code to make use of the background 
> > > > > color
> > > > > has been reviewed and is ready for use:
> > > > >  * https://chromium-review.googlesource.com/c/chromium/src/+/1278858
> > > > >  * https://chromium-review.googlesource.com/c/chromium/src/+/1278858
> > > > 
> > > > Woops, the second link here should have been to
> > > > 
> > > >   
> > > > https://chromium-review.googlesource.com/c/chromiumos/platform/drm-tests/+/1241436
> > > > 
> > > > which I believe is some unit tests to go along with the main userspace
> > > > code.
> > > 
> > > Do we have this as igts too?
> > > -Daniel
> > 
> > Yeah, I posted it along with some of the earlier revisions of the
> > series, but haven't reposted the latest copy lately.  I'll check and see
> > if it needs a rebase and then post it shortly.
> > 
> > Unfortunately the IGT isn't as useful as I'd like it to be since the
> > CRC's for a plane filled with a solid color never come up the same as a
> > pure background color (at least on the APL platform I'm using).  I can
> > run the IGT in interactive mode and the colors seem identical to visual
> > inspection, but the CRC values never agree, so I've disabled the CRC
> > comparison in the test for now.  I'm not sure if this is related to the
> > other blending quirks of gen9; it will be interesting to see if the
> > CRC's match on an Icelake or something.
> 
> Please don't do that, we need to know when stuff doesn't work. Also, igt
> (at least for more generic stuff like this) shouldn't be bent to exactly
> match intel hw bugs.
> 
> And yes if the blending is generally broken on gen9 then I'd be surprised
> if they managed to not screw it up for the background color. Usually
> backgroun color works as if it's a separate additional plane that you
> blend the others with.
> -Daniel

+igt-dev list

So looking at the bspec closer, it sounds like it might not actually be
valid for us to take a DMUX (pipe) CRC of just the background color.
The bspec for gen9+ states

"The DMUX CRC should only be enabled when the pipe, and one or more
planes in the pipe are enabled."

which implies that just using the background color (which is always on)
isn't sufficient.

I'll uncomment the CRC check when we actually push the test so that it
can still be used on non-Intel platforms that don't have this
restriction.  Should we just make the test skip on the relevant i915
platforms, or should we do something else to mark the test as an
expected failure due to hardware?


Matt

> 
> > FWIW, I've mmap'd the Cairo-generated plane framebuffer and verified
> > that it contains exactly the pixel values we'd expect (so it's not a
> > matter of bad roundoff in Cairo), and I've tried flipping both 8bpc and
> > 10bpc pixel formats (to match the background color's 10 bits per
> > component), but nothing seems to make the CRC's match.  :-(
> > 
> > 
> > Matt
> > 
> > > 
> > > > 
> > > > 
> > > > Matt
> > > > 
> > > > > 
> > > > > So I think ABI-wise we've met the userspace consumer requirements to
> > > > > upstream this; we just need to get reviews on the two i915-specific
> > > > > patches and a clean CI report.
> > > > > 
> > > > > v4.1 is identical to v4 aside from a rebase onto the latest drm-tip.
> > > > > 
> > > > > 
> > > > > Matt Roper (3):
> > > > >   drm/i915: Force background color to black for gen9+ (v2)
> > > > >   drm: Add CRTC background color property (v4)
> > > > >   drm/i915/gen9+: Add support for pipe background color (v4)
> > > > > 
> > > > >  drivers/gpu/drm/drm_atomic_uapi.c|  4 
> > > > >  drivers/gpu/drm/drm_blend.c  | 27 +++---
> > > > >  drivers/gpu/drm/drm_mode_config.c|  6 +
> > > > >  drivers/gpu/drm/i915/i915_debugfs.c  |  9 
> > > > >  drivers/gpu/drm/i915/i915_reg.h  |  6 +
> > > > >  drivers/gpu/drm/i915/intel_display.c | 43 
> > > > > 
> > > > >  include/drm/drm_blend.h  |  1 +
> > > > >  include/drm/drm_crtc.h   | 12 ++
> > > > >  include/drm/drm_mode_config.h|  5 +
> > > > >  include/uapi/drm/drm_mode.h  | 28 +++
> > > > >  10 files changed, 138 insertions(+), 3 deletions(-)
> > > > > 
> > > > > -- 
> > > > > 2.14.5
> > > > > 
> > > > 
> > > > -- 
> > > > Matt Roper
> > > > Graphics Software Engineer
> > > > IoTG Platform Enabling & Development
> > > > Intel Corporation
> > > > (916) 356-2795
> > > > 

[PATCH v2 RESEND 2/2] drm/i915/icl: Implement half float formats

[Kevin Strasser]

64 bpp half float formats are supported on hdr planes only and are subject
to the following restrictions:
  * 90/270 rotation not supported
  * Yf Tiling not supported
  * Frame Buffer Compression not supported
  * Color Keying not supported

v2:
- Drop handling pixel normalize register
- Don't use icl_is_hdr_plane too early

Signed-off-by: Kevin Strasser 
Cc: Uma Shankar 
Cc: Shashank Sharma 
Cc: Ville Syrjälä 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/i915/intel_display.c | 22 
 drivers/gpu/drm/i915/intel_sprite.c  | 67 
 2 files changed, 83 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a6d8985..f413ccd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2668,6 +2668,18 @@ int skl_format_to_fourcc(int format, bool rgb_order, 
bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+   case PLANE_CTL_FORMAT_XRGB_16161616F:
+   if (rgb_order) {
+   if (alpha)
+   return DRM_FORMAT_ABGR16161616F;
+   else
+   return DRM_FORMAT_XBGR16161616F;
+   } else {
+   if (alpha)
+   return DRM_FORMAT_ARGB16161616F;
+   else
+   return DRM_FORMAT_XRGB16161616F;
+   }
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3566,6 +3578,12 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+   case DRM_FORMAT_XBGR16161616F:
+   case DRM_FORMAT_ABGR16161616F:
+   return PLANE_CTL_FORMAT_XRGB_16161616F | PLANE_CTL_ORDER_RGBX;
+   case DRM_FORMAT_XRGB16161616F:
+   case DRM_FORMAT_ARGB16161616F:
+   return PLANE_CTL_FORMAT_XRGB_16161616F;
default:
MISSING_CASE(pixel_format);
}
@@ -5069,6 +5087,10 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+   case DRM_FORMAT_XBGR16161616F:
+   case DRM_FORMAT_ABGR16161616F:
+   case DRM_FORMAT_XRGB16161616F:
+   case DRM_FORMAT_ARGB16161616F:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index cd42e81..97f9d05 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1450,8 +1450,6 @@ static int skl_plane_check_fb(const struct 
intel_crtc_state *crtc_state,
/*
 * 90/270 is not allowed with RGB64 16:16:16:16 and
 * Indexed 8-bit. RGB 16-bit 5:6:5 is allowed gen11 onwards.
-* TBD: Add RGB64 case once its added in supported format
-* list.
 */
switch (fb->format->format) {
case DRM_FORMAT_RGB565:
@@ -1459,6 +1457,10 @@ static int skl_plane_check_fb(const struct 
intel_crtc_state *crtc_state,
break;
/* fall through */
case DRM_FORMAT_C8:
+   case DRM_FORMAT_XRGB16161616F:
+   case DRM_FORMAT_XBGR16161616F:
+   case DRM_FORMAT_ARGB16161616F:
+   case DRM_FORMAT_ABGR16161616F:
DRM_DEBUG_KMS("Unsupported pixel format %s for 
90/270!\n",
  drm_get_format_name(fb->format->format,
  _name));
@@ -1774,6 +1776,45 @@ static const u32 skl_planar_formats[] = {
DRM_FORMAT_NV12,
 };
 
+static const uint32_t icl_hdr_plane_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_XRGB16161616F,
+   DRM_FORMAT_XBGR16161616F,
+   DRM_FORMAT_ARGB16161616F,
+   DRM_FORMAT_ABGR16161616F,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+};
+
+static const uint32_t icl_hdr_planar_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_XRGB16161616F,
+   

[PATCH v2 RESEND 1/2] drm/fourcc: Add 64 bpp half float formats

[Kevin Strasser]

Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
formatted in IEEE-754 half-precision float (binary16) 1:5:10
MSb-sign:exponent:fraction form.

This patch attempts to address the feedback provided when 2 of these
formats were previosly proposed:
  https://patchwork.kernel.org/patch/10072545/

v2:
- Fixed cpp (Ville)
- Added detail pixel formatting (Ville)
- Ordered formats in header (Ville)

Signed-off-by: Kevin Strasser 
Cc: Tina Zhang 
Cc: Uma Shankar 
Cc: Shashank Sharma 
Cc: Ville Syrjälä 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/drm_fourcc.c  |  4 
 include/uapi/drm/drm_fourcc.h | 11 +++
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index d90ee03..c866452 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -198,6 +198,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_ABGR,.depth = 32, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_RGBA,.depth = 32, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_BGRA,.depth = 32, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+   { .format = DRM_FORMAT_XRGB16161616F,   .depth = 48, 
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XBGR16161616F,   .depth = 48, 
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_ARGB16161616F,   .depth = 64, 
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+   { .format = DRM_FORMAT_ABGR16161616F,   .depth = 64, 
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_RGB888_A8,   .depth = 32, 
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_BGR888_A8,   .depth = 32, 
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_XRGB_A8, .depth = 32, 
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 91d08a2..c516b40 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -144,6 +144,17 @@ extern "C" {
 #define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0] 
R:G:B:A 10:10:10:2 little endian */
 #define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0] 
B:G:R:A 10:10:10:2 little endian */
 
+/*
+ * Floating point 64bpp RGB
+ * IEEE 754-2008 binary16 half-precision float
+ * [15:0] sign:exponent:mantissa 1:5:10
+ */
+#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0] 
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0] 
x:B:G:R 16:16:16:16 little endian */
+
+#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0] 
A:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0] 
A:B:G:R 16:16:16:16 little endian */
+
 /* packed YCbCr */
 #define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /* 
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
 #define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /* 
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
-- 
2.7.4

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

Re: [PATCH v6 1/5] staging/vboxvideo: prepare for drmP.h removal from drm_modeset_helper.h

[Greg Kroah-Hartman]

On Fri, Feb 01, 2019 at 06:37:49PM +0100, Daniel Vetter wrote:
> On Sat, Jan 26, 2019 at 01:25:23PM +0100, Sam Ravnborg wrote:
> > The use of drmP.h is discouraged and removal of it from
> > drm_modeset_helper.h caused vboxvideo to fail to build.
> > 
> > This patch introduce the necessary fixes to prepare for the
> > drmP.h removal from drm_modeset_helper.h.
> > 
> > In the files touched sort the include files
> > 
> > Build tested on x86 and arm allmodconfig / allyesconfig.
> > 
> > Signed-off-by: Sam Ravnborg 
> > Cc: Greg Kroah-Hartman 
> > Cc: Hans de Goede 
> > Cc: Daniel Vetter 
> 
> Hi Greg,
> 
> Ack for merging this through drm-misc? I think we've defacto-maintained
> vboxvideo in drm anyway this release ...

Sorry, feel free to just always take this type of stuff without my ack,
I can merge around you if I ever have any problems.

Acked-by: Greg Kroah-Hartman 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 RESEND 0/2] Support 64 bpp half float formats

[Kevin Strasser]

This series defines new formats and adds implementation to the i915 driver.
Since posting v1 I have removed the pixel normalize property, as it's not needed
for basic functionality. Also, I have been working on adding support to
userspace, but we can't land any patches until drm_fourcc.h has been updated
here.

I have submitted a series to Mesa to make use of the RGBA ordered formats:
  https://patchwork.freedesktop.org/series/54759/

My igt branch is reworked to drop usage of pixel normalize and includes use
of f16c intrinsics to speed up conversion:
  https://gitlab.freedesktop.org/strassek/igt-gpu-tools/commits/fp16

I also have a libdrm branch with fp16 coverage added to modetest:
  https://gitlab.freedesktop.org/strassek/drm/commits/fp16

To serve as a smoke test of the whole stack I have a modified version of
kmscube:
  https://gitlab.freedesktop.org/strassek/kmscube/commits/fp16

Kevin Strasser (2):
  drm/fourcc: Add 64 bpp half float formats
  drm/i915/icl: Implement half float formats

 drivers/gpu/drm/drm_fourcc.c |  4 +++
 drivers/gpu/drm/i915/intel_display.c | 22 
 drivers/gpu/drm/i915/intel_sprite.c  | 67 
 include/uapi/drm/drm_fourcc.h| 11 ++
 4 files changed, 98 insertions(+), 6 deletions(-)

-- 
2.7.4

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

Re: [PATCH 4/5] drm: v3d: Switch to use drm_gem_object reservation_object

[Rob Herring]

On Fri, Feb 1, 2019 at 11:12 AM Eric Anholt  wrote:
>
> Rob Herring  writes:
>
> > Now that the base struct drm_gem_object has a reservation_object, use it
> > and remove the private BO one.
> >
> > Cc: Eric Anholt 
> > Cc: Daniel Vetter 
> > Cc: David Airlie 
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Rob Herring 
>
> > @@ -453,8 +453,6 @@ v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
> >  {
> >   int ret;
> >   struct drm_v3d_wait_bo *args = data;
> > - struct drm_gem_object *gem_obj;
> > - struct v3d_bo *bo;
> >   ktime_t start = ktime_get();
> >   u64 delta_ns;
> >   unsigned long timeout_jiffies =
> > @@ -463,21 +461,8 @@ v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
> >   if (args->pad != 0)
> >   return -EINVAL;
> >
> > - gem_obj = drm_gem_object_lookup(file_priv, args->handle);
> > - if (!gem_obj) {
> > - DRM_DEBUG("Failed to look up GEM BO %d\n", args->handle);
> > - return -EINVAL;
> > - }
> > - bo = to_v3d_bo(gem_obj);
> > -
> > - ret = reservation_object_wait_timeout_rcu(bo->resv,
> > -   true, true,
> > -   timeout_jiffies);
> > -
> > - if (ret == 0)
> > - ret = -ETIME;
> > - else if (ret > 0)
> > - ret = 0;
> > + ret = drm_gem_reservation_object_wait(file_priv, args->handle,
> > +   true, timeout_jiffies);
>
> Looks like you lost my ret handling in the change.

Indeed as initially I had moved that internal.

> Honestly, I'd love to see drm_gem_reservation_object_wait return
> sensible values like this (0 for success, -ETIME for timeouts) instead
> of drivers having to stubmle over this API.

Me too, but then I found some drivers use ETIMEDOUT instead. I didn't
really want to have to fixup one value to the other and gave up. They
also pass an absolute timeout instead.

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

Re: [PATCH v6 1/5] staging/vboxvideo: prepare for drmP.h removal from drm_modeset_helper.h

[Daniel Vetter]

On Sat, Jan 26, 2019 at 01:25:23PM +0100, Sam Ravnborg wrote:
> The use of drmP.h is discouraged and removal of it from
> drm_modeset_helper.h caused vboxvideo to fail to build.
> 
> This patch introduce the necessary fixes to prepare for the
> drmP.h removal from drm_modeset_helper.h.
> 
> In the files touched sort the include files
> 
> Build tested on x86 and arm allmodconfig / allyesconfig.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Greg Kroah-Hartman 
> Cc: Hans de Goede 
> Cc: Daniel Vetter 

Hi Greg,

Ack for merging this through drm-misc? I think we've defacto-maintained
vboxvideo in drm anyway this release ...
-Daniel

> ---
>  drivers/staging/vboxvideo/vbox_drv.c  |  6 +-
>  drivers/staging/vboxvideo/vbox_fb.c   | 18 ++
>  drivers/staging/vboxvideo/vbox_mode.c |  5 -
>  3 files changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/staging/vboxvideo/vbox_drv.c 
> b/drivers/staging/vboxvideo/vbox_drv.c
> index cc6532d8c2fa..d1b0d7b4886a 100644
> --- a/drivers/staging/vboxvideo/vbox_drv.c
> +++ b/drivers/staging/vboxvideo/vbox_drv.c
> @@ -7,11 +7,15 @@
>   *  Michael Thayer*  Hans de Goede 
>   */
> -#include 
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include "vbox_drv.h"
>  
> diff --git a/drivers/staging/vboxvideo/vbox_fb.c 
> b/drivers/staging/vboxvideo/vbox_fb.c
> index 397496cf0bdf..83a04afd1766 100644
> --- a/drivers/staging/vboxvideo/vbox_fb.c
> +++ b/drivers/staging/vboxvideo/vbox_fb.c
> @@ -6,20 +6,22 @@
>   * Authors: Dave Airlie 
>   *  Michael Thayer*/
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  
>  #include 
> -#include 
>  #include 
> +#include 
> +#include 
>  
>  #include "vbox_drv.h"
>  #include "vboxvideo.h"
> diff --git a/drivers/staging/vboxvideo/vbox_mode.c 
> b/drivers/staging/vboxvideo/vbox_mode.c
> index 1aaff02c07ff..213551394495 100644
> --- a/drivers/staging/vboxvideo/vbox_mode.c
> +++ b/drivers/staging/vboxvideo/vbox_mode.c
> @@ -10,14 +10,17 @@
>   *  Hans de Goede 
>   */
>  #include 
> +
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  
> +#include "hgsmi_channels.h"
>  #include "vbox_drv.h"
>  #include "vboxvideo.h"
> -#include "hgsmi_channels.h"
>  
>  /*
>   * Set a graphics mode.  Poke any required values into registers, do an HGSMI
> -- 
> 2.12.0
> 

-- 
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 v3 08/16] gpu: host1x: Use correct semantics for HOST1X_CHANNEL_DMAEND

[Dmitry Osipenko]

01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding 
> 
> The HOST1X_CHANNEL_DMAEND is an offset relative to the value written to
> the HOST1X_CHANNEL_DMASTART register, but it is currently treated as an
> absolute address. This can cause SMMU faults if the CDMA fetches past a
> pushbuffer's IOMMU mapping.
> 
> Properly setting the DMAEND prevents the CDMA from fetching beyond that
> address and avoid such issues. This is currently not observed because a
> whole (almost) page of essentially scratch space absorbs any excessive
> prefetching by CDMA. However, changing the number of slots in the push
> buffer can trigger these SMMU faults.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/host1x/hw/cdma_hw.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/host1x/hw/cdma_hw.c b/drivers/gpu/host1x/hw/cdma_hw.c
> index 485aef5761af..a24c090ac96f 100644
> --- a/drivers/gpu/host1x/hw/cdma_hw.c
> +++ b/drivers/gpu/host1x/hw/cdma_hw.c
> @@ -75,7 +75,7 @@ static void cdma_start(struct host1x_cdma *cdma)
>  
>   cdma->last_pos = cdma->push_buffer.pos;
>   start = cdma->push_buffer.dma;
> - end = start + cdma->push_buffer.size + 4;
> + end = cdma->push_buffer.size + 4;
>  
>   host1x_ch_writel(ch, HOST1X_CHANNEL_DMACTRL_DMASTOP,
>HOST1X_CHANNEL_DMACTRL);
> @@ -126,7 +126,7 @@ static void cdma_timeout_restart(struct host1x_cdma 
> *cdma, u32 getptr)
>HOST1X_CHANNEL_DMACTRL);
>  
>   start = cdma->push_buffer.dma;
> - end = start + cdma->push_buffer.size + 4;
> + end = cdma->push_buffer.size + 4;
>  
>   /* set base, end pointer (all of memory) */
>   host1x_ch_writel(ch, lower_32_bits(start), HOST1X_CHANNEL_DMASTART);
> 

Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] drm/panel: Add driver for Samsung S6E63M0 panel

[Paweł Chmiel]

This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over
spi. It's based on already removed, non dt s6e63m0 driver and
panel-samsung-ld9040. It can be found for example in some of Samsung
Aries based phones.

Signed-off-by: Paweł Chmiel 
---
Changes from v1:
  - Correct order of Kconfig/Makefile entry
  - Fix SPDX tag, so it matches value of MODULE_LICENSE
  - Remove inclusion of drmP.h
  - Fix code formatting
  - Use DRM_DEV_ERROR/DEBUG
  - Extract hardcoded values
  - Remove possibility to change gamma through sysfs, leaving only one
gamma table values
  - Fix reset_gpio handling, so it'll be asserted in power_on and
deasserted in power_off. Also do it before turning voltage on.
  - Disable backlight and enter sleep mode in disable callback.
Previously it was done in unprepare
  - Enable display and backlight in enable callback. Previously it was
done in prepare
  - Hardcode display timings and delays. Previously they were readed
from device tree
  - We're using SPDX, so we don't need to have license body
  - Use MIPI_DCS_EXIT_SLEEP_MODE and MIPI_DCS_SET_DISPLAY_ON
  - Rename MAX_GAMMA_LEVEL to NUM_GAMMA_LEVELS
  - Ommit get_brightness callback
  - Use backlight_enable/disable API, like it's done in other panel
drivers (for example panel-simple)
  - Make set_brightness called only from backlight api, like it's done
in other panel drivers (for example panel-simple).
  - Reset gpio should be set to GPIOD_OUT_HIGH. It's declared as active
low in device tree
  - Don't call power_off in remove callback
---
 drivers/gpu/drm/panel/Kconfig |   7 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 517 ++
 3 files changed, 525 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3f3537719beb..be05ed5218eb 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -158,6 +158,13 @@ config DRM_PANEL_SAMSUNG_S6E63J0X03
depends on BACKLIGHT_CLASS_DEVICE
select VIDEOMODE_HELPERS
 
+config DRM_PANEL_SAMSUNG_S6E63M0
+   tristate "Samsung S6E63M0 RGB/SPI panel"
+   depends on OF
+   depends on SPI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4396658a7996..4507a2d253ac 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += 
panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D16D0) += panel-samsung-s6d16d0.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63M0) += panel-samsung-s6e63m0.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
new file mode 100644
index ..7658bd993088
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
@@ -0,0 +1,517 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * S6E63M0 AMOLED LCD drm_panel driver.
+ *
+ * Copyright (C) 2019 Paweł Chmiel 
+ * Derived from drivers/gpu/drm/panel-samsung-ld9040.c
+ *
+ * Andrzej Hajda 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* Manufacturer Command Set */
+#define MCS_ELVSS_ON0xb1
+#define MCS_ACL_CTRL0xc0
+#define MCS_DISPLAY_CONDITION   0xf2
+#define MCS_ETC_CONDITION   0xf6
+#define MCS_PANEL_CONDITION 0xF8
+#define MCS_GAMMA_CTRL  0xfa
+
+#define NUM_GAMMA_LEVELS 11
+#define GAMMA_TABLE_COUNT   23
+
+#define DATA_MASK   0x100
+
+#define MAX_BRIGHTNESS  (NUM_GAMMA_LEVELS - 1)
+
+/* array of gamma tables for gamma value 2.2 */
+static u8 const s6e63m0_gamma_22[NUM_GAMMA_LEVELS][GAMMA_TABLE_COUNT] = {
+   { MCS_GAMMA_CTRL, 0x00,
+ 0x18, 0x08, 0x24, 0x78, 0xEC, 0x3D, 0xC8,
+ 0xC2, 0xB6, 0xC4, 0xC7, 0xB6, 0xD5, 0xD7,
+ 0xCC, 0x00, 0x39, 0x00, 0x36, 0x00, 0x51 },
+   { MCS_GAMMA_CTRL, 0x00,
+ 0x18, 0x08, 0x24, 0x73, 0x4A, 0x3D, 0xC0,
+ 0xC2, 0xB1, 0xBB, 0xBE, 0xAC, 0xCE, 0xCF,
+ 0xC5, 0x00, 0x5D, 0x00, 0x5E, 0x00, 0x82 },
+   { MCS_GAMMA_CTRL, 0x00,
+ 0x18, 0x08, 0x24, 0x70, 0x51, 0x3E, 0xBF,
+ 0xC1, 0xAF, 0xB9, 0xBC, 0xAB, 0xCC, 0xCC,
+ 0xC2, 

Re: [PATCH v3 08/16] gpu: host1x: Use correct semantics for HOST1X_CHANNEL_DMAEND

[Dmitry Osipenko]

01.02.2019 17:10, Thierry Reding пишет:
> On Fri, Feb 01, 2019 at 04:48:56PM +0300, Dmitry Osipenko wrote:
>> 01.02.2019 16:41, Thierry Reding пишет:
>>> On Fri, Feb 01, 2019 at 04:37:59PM +0300, Dmitry Osipenko wrote:
 01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding 
>
> The HOST1X_CHANNEL_DMAEND is an offset relative to the value written to
> the HOST1X_CHANNEL_DMASTART register, but it is currently treated as an
> absolute address. This can cause SMMU faults if the CDMA fetches past a
> pushbuffer's IOMMU mapping.
>
> Properly setting the DMAEND prevents the CDMA from fetching beyond that
> address and avoid such issues. This is currently not observed because a
> whole (almost) page of essentially scratch space absorbs any excessive
> prefetching by CDMA. However, changing the number of slots in the push
> buffer can trigger these SMMU faults.
>
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/host1x/hw/cdma_hw.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/host1x/hw/cdma_hw.c 
> b/drivers/gpu/host1x/hw/cdma_hw.c
> index 485aef5761af..a24c090ac96f 100644
> --- a/drivers/gpu/host1x/hw/cdma_hw.c
> +++ b/drivers/gpu/host1x/hw/cdma_hw.c
> @@ -75,7 +75,7 @@ static void cdma_start(struct host1x_cdma *cdma)
>  
>   cdma->last_pos = cdma->push_buffer.pos;
>   start = cdma->push_buffer.dma;
> - end = start + cdma->push_buffer.size + 4;
> + end = cdma->push_buffer.size + 4;
>  
>   host1x_ch_writel(ch, HOST1X_CHANNEL_DMACTRL_DMASTOP,
>HOST1X_CHANNEL_DMACTRL);
> @@ -126,7 +126,7 @@ static void cdma_timeout_restart(struct host1x_cdma 
> *cdma, u32 getptr)
>HOST1X_CHANNEL_DMACTRL);
>  
>   start = cdma->push_buffer.dma;
> - end = start + cdma->push_buffer.size + 4;
> + end = cdma->push_buffer.size + 4;
>  
>   /* set base, end pointer (all of memory) */
>   host1x_ch_writel(ch, lower_32_bits(start), HOST1X_CHANNEL_DMASTART);
>

 This seems fixes problem that was added by a previous patch in this
 series, "gpu: host1x: Support 40-bit addressing". What about to just
 squash the patches? 
>>>
>>> This actually fixes a bug that's always been there. This just happens to
>>> touch the same lines as an earlier patch as a result of some refactoring
>>> that the earlier patch did.
>>
>> Oh, wow. Indeed! That's a bit unfortunate :) Though it's quite
>> difficult to spot that bug by looking at the code, good that it got
>> caught. Was this bug triggered by trying to move IOVA allocation to
>> the end of the AS?
> 
> This was actually triggered because I noticed that we were using 512
> slots in the push buffer, which means 4096 bytes, but then we needed
> that extra 4 bytes for the RESTART opcode, which means that we're
> currently allocating 8192 bytes of which only 4092 are being used.
> 
> So I thought: "Well, we should be able to live with 511 slots per push
> buffer and save a full memory page. This is an easy optimization!" Boy
> was I wrong... After making that change I started to see SMMU faults
> for the address immediately after the push buffer mapping. I think the
> same error happens regardless of where the push buffer is located. The
> reason for the SMMU faults seem to be that CDMA happily keeps on pre-
> fetching (a lot of) commands before it wraps around because of the
> RESTART opcode. DMAEND is designed as a mechanism to prevent CDMA from
> excessively fetching commands, but if you program a really large value
> into it, it'll add that really large value to the DMASTART as offset
> and the mechanism doesn't work anymore.
> 
> We don't currently see this because the 4092 bytes in the "scratch"
> page of the push buffer allocation are enough to absorb the prefetching
> that CDMA does.
> 
> We would also likely never see it happen in non-SMMU cases because the
> CDMA would just keep on prefetching whatever memory happened to be after
> the push buffer.

Yeah, that's what usually happens when the code is getting improved. Good job! 
:)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] drm/omap: panel-tpo-td028ttec1: add backlight support

[Andreas Kemnade]

ping

On Sat, 19 Jan 2019 19:21:29 +0100
Andreas Kemnade  wrote:

> This panel has a backlight, so add a property describing that and
> add the code to use that.
> This makes things like xset dpms force off
> also turn off the backlight, so we do not need to rely on additional
> userspace programs to do that.
> 
> Andreas Kemnade (2):
>   drm/omap: panel-tpo-td028ttec1: add backlight support
>   dt-bindings: panel: td028ttec1: add backlight property
> 
>  .../bindings/display/panel/tpo,td028ttec1.txt  |  2 ++
>  .../gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c| 18 
> +++---
>  2 files changed, 17 insertions(+), 3 deletions(-)
> 
> -- 
> 2.11.0
> 
> 


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

Re: [PATCH -next] drm/xen-front: Drop pointless static qualifier in fb_destroy()

[Oleksandr Andrushchenko]

On 1/28/19 8:36 AM, Oleksandr Andrushchenko wrote:
> On 1/26/19 2:05 PM, YueHaibing wrote:
>> There is no need to have the 'struct drm_framebuffer *fb' variable
>> static since new value always be assigned before use it.
>>
>> Signed-off-by: YueHaibing 
> Good catch, thank you!
> Reviewed-by: Oleksandr Andrushchenko 
If nobody objects I'll apply this to drm-misc-fixes next Monday
>> ---
>>   drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c 
>> b/drivers/gpu/drm/xen/xen_drm_front_kms.c
>> index 860da05..c2955d3 100644
>> --- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
>> +++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
>> @@ -54,7 +54,7 @@ static void fb_destroy(struct drm_framebuffer *fb)
>>     const struct drm_mode_fb_cmd2 *mode_cmd)
>>   {
>>   struct xen_drm_front_drm_info *drm_info = dev->dev_private;
>> -    static struct drm_framebuffer *fb;
>> +    struct drm_framebuffer *fb;
>>   struct drm_gem_object *gem_obj;
>>   int ret;
>>
>>
>>
>>
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Xen-devel][PATCH] drm/xen-front: Fix mmap attributes for display buffers

[Oleksandr Andrushchenko]

On 1/30/19 11:09 AM, Oleksandr Andrushchenko wrote:
> On 1/29/19 9:07 PM, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko 
>>>
>>> When GEM backing storage is allocated those are normal pages,
>>> so there is no point using pgprot_writecombine while mmaping.
>>> This fixes mismatch of buffer pages' memory attributes between
>>> the frontend and backend which may cause screen artifacts.
>>>
>>> Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display 
>>> frontend")
>>>
>>> Signed-off-by: Oleksandr Andrushchenko 
>>> 
>>> Suggested-by: Julien Grall 
>>> ---
>>>   drivers/gpu/drm/xen/xen_drm_front_gem.c | 5 ++---
>>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c 
>>> b/drivers/gpu/drm/xen/xen_drm_front_gem.c
>>> index d303a2e17f5e..9d5c03d7668d 100644
>>> --- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
>>> +++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
>>> @@ -235,8 +235,7 @@ static int gem_mmap_obj(struct xen_gem_object 
>>> *xen_obj,
>>>   vma->vm_flags &= ~VM_PFNMAP;
>>>   vma->vm_flags |= VM_MIXEDMAP;
>>>   vma->vm_pgoff = 0;
>>> -    vma->vm_page_prot =
>>> - pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
>>> +    vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>>
>> The patch looks good to me. It would be worth expanding the comment a 
>> bit before to explain that we overwrite vm_page_prot to use cacheable 
>> attribute as required by the Xen ABI.
>>
> Ok, then I'll put:
>
> +   /*
> +    * According to Xen on ARM ABI (xen/include/public/arch-arm.h):
> +    * all memory which is shared with other entities in the system
> +    * (including the hypervisor and other guests) must reside in 
> memory
> +    * which is mapped as Normal Inner Write-Back Outer Write-Back
> +    * Inner-Shareable.
> +    */
>     vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> Please let me know if this is not what you want
>> With the comment updated:
>>
>> Acked-by: Julien Grall 
>>
If nobody objects I'll apply this to drm-misc-fixes next Monday
>> Cheers,
>>
> Thank you,
> Oleksandr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 06/16] gpu: host1x: Restrict IOVA space to DMA mask

[Dmitry Osipenko]

01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding 
> 
> On Tegra186 and later, the ARM SMMU provides an input address space that
> is 48 bits wide. However, memory clients can only address up to 40 bits.
> If the geometry is used as-is, allocations of IOVA space can end up in a
> region that is not addressable by the memory clients.
> 
> To fix this, restrict the IOVA space to the DMA mask of the host1x
> device.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/host1x/dev.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
> index 4c044ee54fe6..544b67f2b3ff 100644
> --- a/drivers/gpu/host1x/dev.c
> +++ b/drivers/gpu/host1x/dev.c
> @@ -283,6 +283,8 @@ static int host1x_probe(struct platform_device *pdev)
>   host->group = iommu_group_get(>dev);
>   if (host->group) {
>   struct iommu_domain_geometry *geometry;
> + u64 mask = dma_get_mask(host->dev);
> + dma_addr_t start, end;
>   unsigned long order;
>  
>   err = iova_cache_get();
> @@ -310,11 +312,12 @@ static int host1x_probe(struct platform_device *pdev)
>   }
>  
>   geometry = >domain->geometry;
> + start = geometry->aperture_start & mask;
> + end = geometry->aperture_end & mask;
>  
>   order = __ffs(host->domain->pgsize_bitmap);
> - init_iova_domain(>iova, 1UL << order,
> -  geometry->aperture_start >> order);
> - host->iova_end = geometry->aperture_end;
> + init_iova_domain(>iova, 1UL << order, start >> order);
> + host->iova_end = end;
>   }
>  
>  skip_iommu:
> 

For older Tegra's:

Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 05/16] gpu: host1x: Use direct DMA with IOMMU API usage

[Dmitry Osipenko]

01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding 
> 
> If we use the IOMMU API directly to map buffers into host1x' IOVA space,
> we must make sure that the DMA API doesn't already set up a mapping, or
> else translation will fail.
> 
> The direct DMA API allows us to allocate memory that will not be mapped
> through an IOMMU automatically.
> 
> Reviewed-by: Dmitry Osipenko 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/host1x/cdma.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
> index e2d106fa3c0b..a96c4dd1e449 100644
> --- a/drivers/gpu/host1x/cdma.c
> +++ b/drivers/gpu/host1x/cdma.c
> @@ -19,6 +19,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -70,6 +71,7 @@ static void host1x_pushbuffer_destroy(struct push_buffer 
> *pb)
>   */
>  static int host1x_pushbuffer_init(struct push_buffer *pb)
>  {
> + unsigned long attrs = DMA_ATTR_WRITE_COMBINE;
>   struct host1x_cdma *cdma = pb_to_cdma(pb);
>   struct host1x *host1x = cdma_to_host1x(cdma);
>   struct iova *alloc;
> @@ -91,8 +93,8 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
>  
>   size = iova_align(>iova, size);
>  
> - pb->mapped = dma_alloc_wc(host1x->dev, size, >phys,
> -   GFP_KERNEL);
> + pb->mapped = dma_direct_alloc(host1x->dev, size, >phys,
> +   GFP_KERNEL, attrs);
>   if (!pb->mapped)
>   return -ENOMEM;
>  
> @@ -127,7 +129,10 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
>  iommu_free_iova:
>   __free_iova(>iova, alloc);
>  iommu_free_mem:
> - dma_free_wc(host1x->dev, size, pb->mapped, pb->phys);
> + if (host1x->domain)
> + dma_direct_free(host1x->dev, size, pb->mapped, pb->phys, attrs);
> + else
> + dma_free_wc(host1x->dev, size, pb->mapped, pb->phys);
>  
>   return err;
>  }
> 

Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 12/16] drm/tegra: Setup shared IOMMU domain after initialization

[Dmitry Osipenko]

01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding 
> 
> Move initialization of the shared IOMMU domain after the host1x device
> has been initialized. At this point all the Tegra DRM clients have been
> attached to the shared IOMMU domain.
> 
> This is important because Tegra186 and later use an ARM SMMU, for which
> the driver defers setting up the geometry for a domain until a device is
> attached to it. This is to ensure that the domain is properly set up for
> a specific ARM SMMU instance, which is unknown at allocation time.
> 
> Reviewed-by: Dmitry Osipenko 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/tegra/drm.c | 54 -
>  1 file changed, 29 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index 61dcbd218ffc..271c7a5fc954 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -92,10 +92,6 @@ static int tegra_drm_load(struct drm_device *drm, unsigned 
> long flags)
>   return -ENOMEM;
>  
>   if (iommu_present(_bus_type)) {
> - u64 carveout_start, carveout_end, gem_start, gem_end;
> - struct iommu_domain_geometry *geometry;
> - unsigned long order;
> -
>   tegra->domain = iommu_domain_alloc(_bus_type);
>   if (!tegra->domain) {
>   err = -ENOMEM;
> @@ -105,27 +101,6 @@ static int tegra_drm_load(struct drm_device *drm, 
> unsigned long flags)
>   err = iova_cache_get();
>   if (err < 0)
>   goto domain;
> -
> - geometry = >domain->geometry;
> - gem_start = geometry->aperture_start;
> - gem_end = geometry->aperture_end - CARVEOUT_SZ;
> - carveout_start = gem_end + 1;
> - carveout_end = geometry->aperture_end;
> -
> - order = __ffs(tegra->domain->pgsize_bitmap);
> - init_iova_domain(>carveout.domain, 1UL << order,
> -  carveout_start >> order);
> -
> - tegra->carveout.shift = iova_shift(>carveout.domain);
> - tegra->carveout.limit = carveout_end >> tegra->carveout.shift;
> -
> - drm_mm_init(>mm, gem_start, gem_end - gem_start + 1);
> - mutex_init(>mm_lock);
> -
> - DRM_DEBUG("IOMMU apertures:\n");
> - DRM_DEBUG("  GEM: %#llx-%#llx\n", gem_start, gem_end);
> - DRM_DEBUG("  Carveout: %#llx-%#llx\n", carveout_start,
> -   carveout_end);
>   }
>  
>   mutex_init(>clients_lock);
> @@ -159,6 +134,35 @@ static int tegra_drm_load(struct drm_device *drm, 
> unsigned long flags)
>   if (err < 0)
>   goto fbdev;
>  
> + if (tegra->domain) {
> + u64 carveout_start, carveout_end, gem_start, gem_end;
> + dma_addr_t start, end;
> + unsigned long order;
> +
> + start = tegra->domain->geometry.aperture_start;
> + end = tegra->domain->geometry.aperture_end;
> +
> + gem_start = start;
> + gem_end = end - CARVEOUT_SZ;
> + carveout_start = gem_end + 1;
> + carveout_end = end;
> +
> + order = __ffs(tegra->domain->pgsize_bitmap);
> + init_iova_domain(>carveout.domain, 1UL << order,
> +  carveout_start >> order);
> +
> + tegra->carveout.shift = iova_shift(>carveout.domain);
> + tegra->carveout.limit = carveout_end >> tegra->carveout.shift;
> +
> + drm_mm_init(>mm, gem_start, gem_end - gem_start + 1);
> + mutex_init(>mm_lock);
> +
> + DRM_DEBUG("IOMMU apertures:\n");
> + DRM_DEBUG("  GEM: %#llx-%#llx\n", gem_start, gem_end);
> + DRM_DEBUG("  Carveout: %#llx-%#llx\n", carveout_start,
> +   carveout_end);
> + }
> +
>   if (tegra->hub) {
>   err = tegra_display_hub_prepare(tegra->hub);
>   if (err < 0)
> 

Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/7] drm: rockchip: introduce rk3066 hdmi

[Johan Jonker]

Hi,

Beside the binding for "rockchip,rk3066-vop" this patch series
also has a new binding for "rockchip,rk3066-hdmi".
Can Rob Herring advise here? Including the document describing the binding.

This patch still has the original license text included.
Can the copyright holder (or Sandy) approve the replacement of the GPL text
by a SPDX License Identifier for GPL-2.0?

Is Heiko's test setup for rk3066 already functional?

Thanks

2018-12-29 14:33 GMT+01:00, Johan Jonker :

> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> @@ -0,0 +1,928 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + *Zheng Yang 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that 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.
> + */

> +static inline u8 rk3066_hdmi_get_power_mode(struct rk3066_hdmi *hdmi)
> +{
> + return hdmi_readb(hdmi, HDMI_SYS_CTRL) & HDMI_SYS_POWER_MODE_MASK;
> +}
> +
> +static void rk3066_hdmi_set_power_mode(struct rk3066_hdmi *hdmi, int mode)
> +{
> + u8 current_mode, next_mode;
> + u8 i = 0;
> +

The function rk3066_hdmi_get_power_mode can also returns 0 with VIO
power domain disabled.
That would lead to an endless loop. Just replaced 0 with
HDMI_SYS_POWER_MODE_A to prevent a crash.
Please advise if this function is OK with you?

> + current_mode = rk3066_hdmi_get_power_mode(hdmi);
> +
> + dev_dbg(hdmi->dev, "mode :%d\n", mode);
> + dev_dbg(hdmi->dev, "current_mode :%d\n", current_mode);
> +
> + if (current_mode == mode)
> + return;
> +
> + do {
> + if (current_mode > mode)
> + next_mode = current_mode / 2;
> + else {
> + if (current_mode < HDMI_SYS_POWER_MODE_A)
> + next_mode = HDMI_SYS_POWER_MODE_A;
> + else
> + next_mode = current_mode * 2;
> + }
> +
> + dev_dbg(hdmi->dev, "%d: next_mode :%d\n", i, next_mode);
> +
> + if (next_mode != HDMI_SYS_POWER_MODE_D) {
> + hdmi_modb(hdmi, HDMI_SYS_CTRL,
> +   HDMI_SYS_POWER_MODE_MASK, next_mode);
> + } else {
> + hdmi_writeb(hdmi, HDMI_SYS_CTRL,
> + HDMI_SYS_POWER_MODE_D |
> + HDMI_SYS_PLL_RESET_MASK);
> + usleep_range(90, 100);
> + hdmi_writeb(hdmi, HDMI_SYS_CTRL,
> + HDMI_SYS_POWER_MODE_D |
> + HDMI_SYS_PLLB_RESET);
> + usleep_range(90, 100);
> + hdmi_writeb(hdmi, HDMI_SYS_CTRL,
> + HDMI_SYS_POWER_MODE_D);
> + }
> + current_mode = next_mode;
> + i = i + 1;
> + } while ((next_mode != mode) && (i < 5));

> +static const struct drm_display_mode edid_cea_modes[] = {
> + /* 4 - 1280x720@60Hz 16:9 */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> +};
> +
> +static int rk3066_hdmi_connector_get_modes(struct drm_connector
> *connector)
> +{
> + struct rk3066_hdmi *hdmi = to_rk3066_hdmi(connector);
> + struct drm_display_mode *mode = NULL;
> + struct edid *edid;
> + int ret = 0;
> +
> + if (!hdmi->ddc)
> + return 0;
> +
> + hdmi->hdmi_data.sink_is_hdmi = false;
> +
> + edid = drm_get_edid(connector, hdmi->ddc);
> + if (edid) {
> + hdmi->hdmi_data.sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> +
> + dev_info(hdmi->dev, "monitor type : %s : %dx%d cm\n",
> + (hdmi->hdmi_data.sink_is_hdmi ? "HDMI" : "DVI"),
> + edid->width_cm, edid->height_cm);
> +
> + drm_connector_update_edid_property(connector, edid);
> + ret = drm_add_edid_modes(connector, edid);
> + kfree(edid);
> + }
> +

The DRM framework doesn't provide a function to make a CEA mode. DVI-D
needs a mode set here.
Adding more modes needs an extra for loop. For now one mode is enough.
Just leave it that way.? Please advise.

> + if ((ret == 0) || (hdmi->hdmi_data.sink_is_hdmi == false)) {
> + hdmi->hdmi_data.sink_is_hdmi = false;
> +
> + mode = drm_mode_duplicate(hdmi->drm_dev, _cea_modes[0]);
> + 

[PATCH v2 1/2] dt-bindings: drm: panel: Add Samsung s6e63m0 panel documentation

[Paweł Chmiel]

From: Jonathan Bakker 

This commit adds documentation for Samsung s6e63m0 AMOLED LCD panel
driver.

Signed-off-by: Jonathan Bakker 
Signed-off-by: Paweł Chmiel 
---
Changes from v1:
  - Add missing subject prefix
  - Rename reset-gpio to reset-gpios
  - Add link to spi properites documentation. They're required
for driver to work
  - Removed delay properties, which are now hardcoded in driver
  - Removed display timings, which are now hardcoded in driver
---
 .../display/panel/samsung,s6e63m0.txt | 33 +++
 1 file changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
new file mode 100644
index ..9fb9ebeef8e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
@@ -0,0 +1,33 @@
+Samsung s6e63m0 AMOLED LCD panel
+
+Required properties:
+  - compatible: "samsung,s6e63m0"
+  - reset-gpios: GPIO spec for reset pin
+  - vdd3-supply: VDD regulator
+  - vci-supply: VCI regulator
+
+The panel must obey rules for SPI slave device specified in document [1].
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/spi/spi-bus.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   s6e63m0: display@0 {
+   compatible = "samsung,s6e63m0";
+   reg = <0>;
+   reset-gpio = < 5 1>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   spi-max-frequency = <120>;
+
+   port {
+   lcd_ep: endpoint {
+   remote-endpoint = <_ep>;
+   };
+   };
+   };
-- 
2.17.1

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

[PATCH] dt-bindings: display: rockchip: add document for rk3066 hdmi

[Johan Jonker]

This patch adds a binding that describes the HDMI controller for
rk3066.

Signed-off-by: Johan Jonker 
---
 .../display/rockchip/rk3066_hdmi-rockchip.txt  | 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rk3066_hdmi-rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rk3066_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/rk3066_hdmi-rockchip.txt
new file mode 100644
index 0..6a8f3754f
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/rockchip/rk3066_hdmi-rockchip.txt
@@ -0,0 +1,60 @@
+Rockchip specific extensions for rk3066 HDMI
+
+
+Required properties:
+- compatible:
+   "rockchip,rk3066-hdmi";
+- reg:
+   Physical base address and length of the controller's registers.
+- clocks, clock-names:
+   Phandle to HDMI controller clock, name should be "hclk".
+- interrupts:
+   HDMI interrupt number.
+- power-domains:
+   Phandle to the RK3066_PD_VIO power domain.
+- rockchip,grf:
+   This soc uses GRF regs to switch the HDMI TX input between vop0 and 
vop1.
+- ports:
+   Contains one port node with two endpoints, numbered 0 and 1,
+   connected respectively to vop0 and vop1.
+- pinctrl-0, pinctrl-name:
+   Switch the iomux for the HPD/I2C pins to HDMI function.
+
+Example:
+   hdmi: hdmi@10116000 {
+   compatible = "rockchip,rk3066-hdmi";
+   reg = <0x10116000 0x2000>;
+   interrupts = ;
+   clocks = < HCLK_HDMI>;
+   clock-names = "hclk";
+   power-domains = < RK3066_PD_VIO>;
+   rockchip,grf = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_xfer>, <_hpd>;
+   status = "disabled";
+
+   hdmi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_vop0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   hdmi_in_vop1: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   };
+   };
+
+ {
+   hdmi {
+   hdmi_hpd: hdmi-hpd {
+   rockchip,pins = <0 RK_PA0 1 _pull_default>;
+   };
+   hdmii2c_xfer: hdmii2c-xfer {
+   rockchip,pins = <0 RK_PA1 1 _pull_none>,
+   <0 RK_PA2 1 _pull_none>;
+   };
+   };
+};
-- 
2.11.0

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

Re: [PATCH v3 00/16] drm/tegra: Fix IOVA space on Tegra186 and later

[Dmitry Osipenko]

01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding 
> 
> Tegra186 and later are different from earlier generations in that they
> use an ARM SMMU rather than the Tegra SMMU. The ARM SMMU driver behaves
> slightly differently in that the geometry for IOMMU domains is set only
> after a device was attached to it. This is to make sure that the SMMU
> instance that the domain belongs to is known, because each instance can
> have a different input address space (i.e. geometry).
> 
> Work around this by moving all IOVA allocations to a point where the
> geometry of the domain is properly initialized.
> 
> This second version of the series addresses all review comments and adds
> a number of patches that will actually allow host1x to work with an SMMU
> enabled on Tegra186. The patches also add programming required to
> address the full 40 bits of address space.
> 
> The third version of the series fixes the 40-bit addressing code by
> making sure that wide opcodes are always written atomically to the push
> buffer. Another pair of patches are introduced to fix a long-standing
> bug where the HOST1X_CHANNEL_DMAEND register wasn't properly programmed
> and one push buffer memory optimization that avoid wasting almost one
> full memory page per push buffer.
> 
> This supersedes the following patch:
> 
>   https://patchwork.kernel.org/patch/10775579/
> 
> Thierry
> 
> Thierry Reding (16):
>   gpu: host1x: Set up stream ID table
>   gpu: host1x: Program the channel stream ID
>   gpu: host1x: Introduce support for wide opcodes
>   gpu: host1x: Support 40-bit addressing
>   gpu: host1x: Use direct DMA with IOMMU API usage
>   gpu: host1x: Restrict IOVA space to DMA mask
>   gpu: host1x: Support 40-bit addressing on Tegra186
>   gpu: host1x: Use correct semantics for HOST1X_CHANNEL_DMAEND
>   gpu: host1x: Optimize CDMA push buffer memory usage
>   drm/tegra: Store parent pointer in Tegra DRM clients
>   drm/tegra: vic: Load firmware on demand
>   drm/tegra: Setup shared IOMMU domain after initialization
>   drm/tegra: Restrict IOVA space to DMA mask
>   drm/tegra: vic: Do not clear driver data
>   drm/tegra: vic: Support stream ID register programming
>   arm64: tegra: Enable SMMU for VIC on Tegra186
> 
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi|   1 +
>  drivers/gpu/drm/tegra/drm.c |  57 +
>  drivers/gpu/drm/tegra/drm.h |   1 +
>  drivers/gpu/drm/tegra/vic.c |  75 ---
>  drivers/gpu/drm/tegra/vic.h |   9 ++
>  drivers/gpu/host1x/cdma.c   | 132 ++--
>  drivers/gpu/host1x/cdma.h   |   2 +
>  drivers/gpu/host1x/dev.c|  49 +++-
>  drivers/gpu/host1x/dev.h|   8 ++
>  drivers/gpu/host1x/hw/cdma_hw.c |  32 -
>  drivers/gpu/host1x/hw/channel_hw.c  |  42 ++-
>  drivers/gpu/host1x/hw/host1x06_hardware.h   |   6 +
>  drivers/gpu/host1x/hw/host1x07_hardware.h   |   6 +
>  drivers/gpu/host1x/hw/hw_host1x06_channel.h |  11 ++
>  drivers/gpu/host1x/hw/hw_host1x07_channel.h |  11 ++
>  include/trace/events/host1x.h   |  26 
>  16 files changed, 404 insertions(+), 64 deletions(-)
>  create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_channel.h
>  create mode 100644 drivers/gpu/host1x/hw/hw_host1x07_channel.h
> 

I gave a test to this series on T20 and T30. Opentegra works, grate tests work, 
glxgears are spinning.. everything working fine.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API

[Souptick Joarder]

On Thu, Jan 31, 2019 at 6:04 PM Heiko Stuebner  wrote:
>
> Am Donnerstag, 31. Januar 2019, 13:31:52 CET schrieb Souptick Joarder:
> > On Thu, Jan 31, 2019 at 5:37 PM Heiko Stuebner  wrote:
> > >
> > > Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder:
> > > > Previouly drivers have their own way of mapping range of
> > > > kernel pages/memory into user vma and this was done by
> > > > invoking vm_insert_page() within a loop.
> > > >
> > > > As this pattern is common across different drivers, it can
> > > > be generalized by creating new functions and use it across
> > > > the drivers.
> > > >
> > > > vm_insert_range() is the API which could be used to mapped
> > > > kernel memory/pages in drivers which has considered vm_pgoff
> > > >
> > > > vm_insert_range_buggy() is the API which could be used to map
> > > > range of kernel memory/pages in drivers which has not considered
> > > > vm_pgoff. vm_pgoff is passed default as 0 for those drivers.
> > > >
> > > > We _could_ then at a later "fix" these drivers which are using
> > > > vm_insert_range_buggy() to behave according to the normal vm_pgoff
> > > > offsetting simply by removing the _buggy suffix on the function
> > > > name and if that causes regressions, it gives us an easy way to revert.
> > > >
> > > > Signed-off-by: Souptick Joarder 
> > > > Suggested-by: Russell King 
> > > > Suggested-by: Matthew Wilcox 
> > >
> > > hmm, I'm missing a changelog here between v1 and v2.
> > > Nevertheless I managed to test v1 on Rockchip hardware
> > > and display is still working, including talking to Lima via prime.
> > >
> > > So if there aren't any big changes for v2, on Rockchip
> > > Tested-by: Heiko Stuebner 
> >
> > Change log is available in [0/9].
> > Patch [1/9] & [4/9] have no changes between v1 -> v2.
>
> I never seem to get your cover-letters, so didn't see that, sorry.

I added you in sender list for all cover-letters but it didn't reach
your inbox :-)
Thanks for reviewing and validating the patch.

>
> But great that there weren't changes then :-)
>
> Heiko
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 13/16] drm/tegra: Restrict IOVA space to DMA mask

[Dmitry Osipenko]

01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding 
> 
> On Tegra186 and later, the ARM SMMU provides an input address space that
> is 48 bits wide. However, memory clients can only address up to 40 bits.
> If the geometry is used as-is, allocations of IOVA space can end up in a
> region that cannot be addressed by the memory clients.
> 
> To fix this, restrict the IOVA space to the DMA mask of the host1x
> device. Note that, technically, the IOVA space needs to be restricted to
> the intersection of the DMA masks for all clients that are attached to
> the IOMMU domain. In practice using the DMA mask of the host1x device is
> sufficient because all host1x clients share the same DMA mask.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/tegra/drm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index 271c7a5fc954..0c5f1e6a0446 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -136,11 +136,12 @@ static int tegra_drm_load(struct drm_device *drm, 
> unsigned long flags)
>  
>   if (tegra->domain) {
>   u64 carveout_start, carveout_end, gem_start, gem_end;
> + u64 dma_mask = dma_get_mask(>dev);
>   dma_addr_t start, end;
>   unsigned long order;
>  
> - start = tegra->domain->geometry.aperture_start;
> - end = tegra->domain->geometry.aperture_end;
> + start = tegra->domain->geometry.aperture_start & dma_mask;
> + end = tegra->domain->geometry.aperture_end & dma_mask;
>  
>   gem_start = start;
>   gem_end = end - CARVEOUT_SZ;
> 

For older Tegra's:

Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 10/16] drm/tegra: Store parent pointer in Tegra DRM clients

[Dmitry Osipenko]

01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding 
> 
> Tegra DRM clients need access to their parent, so store a pointer to it
> upon registration. It's technically possible to get at this by going via
> the host1x client's parent and getting the driver data, but that's quite
> complicated and not very transparent. It's much more straightforward and
> natural to let the children know about their parent.
> 
> Signed-off-by: Thierry Reding 
> Reviewed-by: Dmitry Osipenko 
> ---
>  drivers/gpu/drm/tegra/drm.c | 2 ++
>  drivers/gpu/drm/tegra/drm.h | 1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index 4b70ce664c41..61dcbd218ffc 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -1041,6 +1041,7 @@ int tegra_drm_register_client(struct tegra_drm *tegra,
>  {
>   mutex_lock(>clients_lock);
>   list_add_tail(>list, >clients);
> + client->drm = tegra;
>   mutex_unlock(>clients_lock);
>  
>   return 0;
> @@ -1051,6 +1052,7 @@ int tegra_drm_unregister_client(struct tegra_drm *tegra,
>  {
>   mutex_lock(>clients_lock);
>   list_del_init(>list);
> + client->drm = NULL;
>   mutex_unlock(>clients_lock);
>  
>   return 0;
> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> index 7370f7a0fdb8..70154c253d45 100644
> --- a/drivers/gpu/drm/tegra/drm.h
> +++ b/drivers/gpu/drm/tegra/drm.h
> @@ -88,6 +88,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
>  struct tegra_drm_client {
>   struct host1x_client base;
>   struct list_head list;
> + struct tegra_drm *drm;
>  
>   unsigned int version;
>   const struct tegra_drm_client_ops *ops;
> 

Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 08/16] gpu: host1x: Use correct semantics for HOST1X_CHANNEL_DMAEND

[Dmitry Osipenko]

01.02.2019 16:41, Thierry Reding пишет:
> On Fri, Feb 01, 2019 at 04:37:59PM +0300, Dmitry Osipenko wrote:
>> 01.02.2019 16:28, Thierry Reding пишет:
>>> From: Thierry Reding 
>>>
>>> The HOST1X_CHANNEL_DMAEND is an offset relative to the value written to
>>> the HOST1X_CHANNEL_DMASTART register, but it is currently treated as an
>>> absolute address. This can cause SMMU faults if the CDMA fetches past a
>>> pushbuffer's IOMMU mapping.
>>>
>>> Properly setting the DMAEND prevents the CDMA from fetching beyond that
>>> address and avoid such issues. This is currently not observed because a
>>> whole (almost) page of essentially scratch space absorbs any excessive
>>> prefetching by CDMA. However, changing the number of slots in the push
>>> buffer can trigger these SMMU faults.
>>>
>>> Signed-off-by: Thierry Reding 
>>> ---
>>>  drivers/gpu/host1x/hw/cdma_hw.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/host1x/hw/cdma_hw.c 
>>> b/drivers/gpu/host1x/hw/cdma_hw.c
>>> index 485aef5761af..a24c090ac96f 100644
>>> --- a/drivers/gpu/host1x/hw/cdma_hw.c
>>> +++ b/drivers/gpu/host1x/hw/cdma_hw.c
>>> @@ -75,7 +75,7 @@ static void cdma_start(struct host1x_cdma *cdma)
>>>  
>>> cdma->last_pos = cdma->push_buffer.pos;
>>> start = cdma->push_buffer.dma;
>>> -   end = start + cdma->push_buffer.size + 4;
>>> +   end = cdma->push_buffer.size + 4;
>>>  
>>> host1x_ch_writel(ch, HOST1X_CHANNEL_DMACTRL_DMASTOP,
>>>  HOST1X_CHANNEL_DMACTRL);
>>> @@ -126,7 +126,7 @@ static void cdma_timeout_restart(struct host1x_cdma 
>>> *cdma, u32 getptr)
>>>  HOST1X_CHANNEL_DMACTRL);
>>>  
>>> start = cdma->push_buffer.dma;
>>> -   end = start + cdma->push_buffer.size + 4;
>>> +   end = cdma->push_buffer.size + 4;
>>>  
>>> /* set base, end pointer (all of memory) */
>>> host1x_ch_writel(ch, lower_32_bits(start), HOST1X_CHANNEL_DMASTART);
>>>
>>
>> This seems fixes problem that was added by a previous patch in this
>> series, "gpu: host1x: Support 40-bit addressing". What about to just
>> squash the patches? 
> 
> This actually fixes a bug that's always been there. This just happens to
> touch the same lines as an earlier patch as a result of some refactoring
> that the earlier patch did.

Oh, wow. Indeed! That's a bit unfortunate :) Though it's quite difficult to 
spot that bug by looking at the code, good that it got caught. Was this bug 
triggered by trying to move IOVA allocation to the end of the AS?

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

Re: [PATCH v3 08/16] gpu: host1x: Use correct semantics for HOST1X_CHANNEL_DMAEND

[Dmitry Osipenko]

01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding 
> 
> The HOST1X_CHANNEL_DMAEND is an offset relative to the value written to
> the HOST1X_CHANNEL_DMASTART register, but it is currently treated as an
> absolute address. This can cause SMMU faults if the CDMA fetches past a
> pushbuffer's IOMMU mapping.
> 
> Properly setting the DMAEND prevents the CDMA from fetching beyond that
> address and avoid such issues. This is currently not observed because a
> whole (almost) page of essentially scratch space absorbs any excessive
> prefetching by CDMA. However, changing the number of slots in the push
> buffer can trigger these SMMU faults.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/host1x/hw/cdma_hw.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/host1x/hw/cdma_hw.c b/drivers/gpu/host1x/hw/cdma_hw.c
> index 485aef5761af..a24c090ac96f 100644
> --- a/drivers/gpu/host1x/hw/cdma_hw.c
> +++ b/drivers/gpu/host1x/hw/cdma_hw.c
> @@ -75,7 +75,7 @@ static void cdma_start(struct host1x_cdma *cdma)
>  
>   cdma->last_pos = cdma->push_buffer.pos;
>   start = cdma->push_buffer.dma;
> - end = start + cdma->push_buffer.size + 4;
> + end = cdma->push_buffer.size + 4;
>  
>   host1x_ch_writel(ch, HOST1X_CHANNEL_DMACTRL_DMASTOP,
>HOST1X_CHANNEL_DMACTRL);
> @@ -126,7 +126,7 @@ static void cdma_timeout_restart(struct host1x_cdma 
> *cdma, u32 getptr)
>HOST1X_CHANNEL_DMACTRL);
>  
>   start = cdma->push_buffer.dma;
> - end = start + cdma->push_buffer.size + 4;
> + end = cdma->push_buffer.size + 4;
>  
>   /* set base, end pointer (all of memory) */
>   host1x_ch_writel(ch, lower_32_bits(start), HOST1X_CHANNEL_DMASTART);
> 

This seems fixes problem that was added by a previous patch in this series, 
"gpu: host1x: Support 40-bit addressing". What about to just squash the 
patches? 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 09/16] gpu: host1x: Optimize CDMA push buffer memory usage

[Dmitry Osipenko]

01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding 
> 
> The host1x CDMA push buffer is terminated by a special opcode (RESTART)
> that tells the CDMA to wrap around to the beginning of the push buffer.
> To accomodate the RESTART opcode, an extra 4 bytes are allocated on top
> of the 512 * 8 = 4096 bytes needed for the 512 slots (1 slot = 2 words)
> that are used for other commands passed to CDMA. This requires that two
> memory pages are allocated, but most of the second page (4092 bytes) is
> never used.
> 
> Decrease the number of slots to 511 so that the RESTART opcode fits
> within the page. Adjust the push buffer wraparound code to take into
> account push buffer sizes that are not a power of two.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/host1x/cdma.c | 29 +
>  1 file changed, 25 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
> index a96c4dd1e449..50c1370b56c7 100644
> --- a/drivers/gpu/host1x/cdma.c
> +++ b/drivers/gpu/host1x/cdma.c
> @@ -42,7 +42,17 @@
>   * means that the push buffer is full, not empty.
>   */
>  
> -#define HOST1X_PUSHBUFFER_SLOTS  512
> +/*
> + * Typically the commands written into the push buffer are a pair of words. 
> We
> + * use slots to represent each of these pairs and to simplify things. Note 
> the
> + * strange number of slots allocated here. 512 slots will fit exactly within 
> a
> + * single memory page. We also need one additional word at the end of the 
> push
> + * buffer for the RESTART opcode that will instruct the CDMA to jump back to
> + * the beginning of the push buffer. With 512 slots, this means that we'll 
> use
> + * 2 memory pages and waste 4092 bytes of the second page that will never be
> + * used.
> + */
> +#define HOST1X_PUSHBUFFER_SLOTS  511
>  
>  /*
>   * Clean up push buffer resources
> @@ -148,7 +158,10 @@ static void host1x_pushbuffer_push(struct push_buffer 
> *pb, u32 op1, u32 op2)
>   WARN_ON(pb->pos == pb->fence);
>   *(p++) = op1;
>   *(p++) = op2;
> - pb->pos = (pb->pos + 8) & (pb->size - 1);
> + pb->pos += 8;
> +
> + if (pb->pos >= pb->size)
> + pb->pos -= pb->size;
>  }
>  
>  /*
> @@ -158,7 +171,10 @@ static void host1x_pushbuffer_push(struct push_buffer 
> *pb, u32 op1, u32 op2)
>  static void host1x_pushbuffer_pop(struct push_buffer *pb, unsigned int slots)
>  {
>   /* Advance the next write position */
> - pb->fence = (pb->fence + slots * 8) & (pb->size - 1);
> + pb->fence += slots * 8;
> +
> + if (pb->fence >= pb->size)
> + pb->fence -= pb->size;
>  }
>  
>  /*
> @@ -166,7 +182,12 @@ static void host1x_pushbuffer_pop(struct push_buffer 
> *pb, unsigned int slots)
>   */
>  static u32 host1x_pushbuffer_space(struct push_buffer *pb)
>  {
> - return ((pb->fence - pb->pos) & (pb->size - 1)) / 8;
> + unsigned int fence = pb->fence;
> +
> + if (pb->fence < pb->pos)
> + fence += pb->size;
> +
> + return (fence - pb->pos) / 8;
>  }
>  
>  /*
> 

Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging: android: ion: fix sys heap pool's gfp_flags

[Xiaqing (A)]

On 2019/2/1 16:15, Dan Carpenter wrote:

On Fri, Feb 01, 2019 at 02:59:46PM +0800, Qing Xia wrote:

In the first loop, gfp_flags will be modified to high_order_gfp_flags,
and there will be no chance to change back to low_order_gfp_flags.

Fixes: e7f63771 ("ION: Sys_heap: Add cached pool to spead up cached buffer 
alloc")


Huh...  Presumably you found this bug just by reading the code.  I
wonder how it affects runtime?


The problem is that when I found that there was no page allocation failure 
warning
after the failure of the ion alloc in my test, and then I found the problem of 
gfp_flags.

regards,
Qing


regards,
dan carpenter


.



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

Re: [PATCH 0/5] Add reservation_object to drm_gem_object

[Daniel Vetter]

On Thu, Jan 31, 2019 at 06:50:52PM -0600, Rob Herring wrote:
> This series implements the todo to add reservation_object to 
> drm_gem_object. I converted the easy drivers, but not Intel or AMD. The 
> series is build tested only.

Maybe keep the todo around the (just update it a bit) untill the callback
is completely gone.
-Daniel

> 
> Rob
> 
> Rob Herring (5):
>   drm: Add reservation_object to drm_gem_object
>   drm: etnaviv: Switch to use drm_gem_object reservation_object
>   drm: msm: Switch to use drm_gem_object reservation_object
>   drm: v3d: Switch to use drm_gem_object reservation_object
>   drm: vc4: Switch to use drm_gem_object reservation_object
> 
>  Documentation/gpu/todo.rst   |  9 -
>  drivers/gpu/drm/drm_gem.c| 39 
>  drivers/gpu/drm/drm_prime.c  |  1 +
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c|  1 -
>  drivers/gpu/drm/etnaviv/etnaviv_drv.h|  1 -
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c| 16 +++-
>  drivers/gpu/drm/etnaviv/etnaviv_gem.h|  4 --
>  drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c  |  7 
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 22 +--
>  drivers/gpu/drm/msm/msm_drv.c|  1 -
>  drivers/gpu/drm/msm/msm_drv.h|  1 -
>  drivers/gpu/drm/msm/msm_gem.c| 27 +-
>  drivers/gpu/drm/msm/msm_gem_prime.c  |  7 
>  drivers/gpu/drm/msm/msm_gem_submit.c |  8 ++--
>  drivers/gpu/drm/v3d/v3d_bo.c | 14 +--
>  drivers/gpu/drm/v3d/v3d_drv.c|  1 -
>  drivers/gpu/drm/v3d/v3d_drv.h|  5 ---
>  drivers/gpu/drm/v3d/v3d_gem.c| 35 +-
>  drivers/gpu/drm/vc4/vc4_bo.c | 15 +---
>  drivers/gpu/drm/vc4/vc4_drv.c|  1 -
>  drivers/gpu/drm/vc4/vc4_drv.h|  7 +---
>  drivers/gpu/drm/vc4/vc4_gem.c| 18 -
>  drivers/gpu/drm/vc4/vc4_plane.c  |  2 +-
>  include/drm/drm_gem.h|  7 
>  24 files changed, 98 insertions(+), 151 deletions(-)
> 
> -- 
> 2.19.1
> 

-- 
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/5] drm: Add reservation_object to drm_gem_object

[Daniel Vetter]

On Thu, Jan 31, 2019 at 06:50:53PM -0600, Rob Herring wrote:
> Many users of drm_gem_object embed a struct reservation_object into
> their subclassed struct, so let's add one to struct drm_gem_object.
> This will allow removing the reservation object from the subclasses
> and removing the ->gem_prime_res_obj callback.
> 
> With the addition, add a drm_gem_reservation_object_wait() helper
> function for drivers to use in wait ioctls.
> 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Signed-off-by: Rob Herring 
> ---
>  Documentation/gpu/todo.rst  |  9 -
>  drivers/gpu/drm/drm_gem.c   | 39 +
>  drivers/gpu/drm/drm_prime.c |  1 +
>  include/drm/drm_gem.h   |  7 +++
>  4 files changed, 47 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 14191b64446d..6e0a37d0bf6d 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -209,15 +209,6 @@ Would be great to refactor this all into a set of small 
> common helpers.
>  
>  Contact: Daniel Vetter
>  
> -Put a reservation_object into drm_gem_object
> -
> -
> -This would remove the need for the ->gem_prime_res_obj callback. It would 
> also
> -allow us to implement generic helpers for waiting for a bo, allowing for 
> quite a
> -bit of refactoring in the various wait ioctl implementations.
> -
> -Contact: Daniel Vetter
> -
>  idr_init_base()
>  ---
>  
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 8b55ece97967..91dd06c1b3a8 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -170,6 +170,10 @@ void drm_gem_private_object_init(struct drm_device *dev,
>   kref_init(>refcount);
>   obj->handle_count = 0;
>   obj->size = size;
> + if (!obj->resv) {
> + obj->resv = >_resv;
> + reservation_object_init(obj->resv);

You _fini unconditionally, but don't _init unconditionally. I think
simplest to just always init (and only assign the pointer if nothing's
been assigned to it yet).

> + }
>   drm_vma_node_reset(>vma_node);
>  }
>  EXPORT_SYMBOL(drm_gem_private_object_init);
> @@ -657,6 +661,40 @@ drm_gem_object_lookup(struct drm_file *filp, u32 handle)
>  }
>  EXPORT_SYMBOL(drm_gem_object_lookup);
>  
> +/**
> + * drm_gem_object_lookup - Wait on GEM object's reservation's objects
> + * shared and/or exclusive fences.
> + * @filp: DRM file private date
> + * @handle: userspace handle
> + * @wait_all: if true, wait on all fences, else wait on just exclusive fence
> + * @timeout: timeout value in jiffies or zero to return immediately
> + *
> + * Returns:
> + *
> + * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
> + * greater than 0 on success.
> + */
> +long drm_gem_reservation_object_wait(struct drm_file *filep, u32 handle,
> + bool wait_all, unsigned long timeout)
> +{
> + long ret;
> + struct drm_gem_object *obj;
> +
> + obj = drm_gem_object_lookup(filep, handle);
> + if (!obj) {
> + DRM_DEBUG("Failed to look up GEM BO %d\n", handle);
> + return -EINVAL;
> + }
> +
> + ret = reservation_object_wait_timeout_rcu(obj->resv, wait_all,
> +   true, timeout);
> +
> + drm_gem_object_put_unlocked(obj);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_gem_reservation_object_wait);
> +
>  /**
>   * drm_gem_close_ioctl - implementation of the GEM_CLOSE ioctl
>   * @dev: drm_device
> @@ -821,6 +859,7 @@ drm_gem_object_release(struct drm_gem_object *obj)
>   if (obj->filp)
>   fput(obj->filp);
>  
> + reservation_object_fini(>_resv);
>   drm_gem_free_mmap_offset(obj);
>  }
>  EXPORT_SYMBOL(drm_gem_object_release);
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 231e3f6d5f41..dc079efb3b0f 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -504,6 +504,7 @@ struct dma_buf *drm_gem_prime_export(struct drm_device 
> *dev,
>   .size = obj->size,
>   .flags = flags,
>   .priv = obj,
> + .resv = obj->resv,
>   };
>  
>   if (dev->driver->gem_prime_res_obj)
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index c95727425284..f450a5b6038e 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -35,6 +35,7 @@
>   */
>  
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -262,6 +263,10 @@ struct drm_gem_object {
>*/
>   struct dma_buf_attachment *import_attach;
>  
> + /* normally (resv == &_resv) except for imported bo's */
> + struct reservation_object *resv;
> + struct reservation_object _resv;

Some kerneldoc here would be neat too.

Otherwise looks good to me..
-Daniel

> +
>   /**
>* @funcs:

Re: [PATCH v2,1/2] drm/vkms: Use alpha for blending in blend() function

[Daniel Vetter]

On Thu, Jan 31, 2019 at 10:44:09AM -0200, Rodrigo Siqueira wrote:
> Hi,
> 
> First of all, thanks for your patch :)
> 
> I tested your patch against the tests that you implemented in the IGT
> [1]. All the alpha tests passed, but there was a weird warning that
> says:
> 
>  $ sudo IGT_FORCE_DRIVER=vkms ./tests/kms_cursor_crc --run-subtest 
> cursor-alpha-opaque
>  IGT-Version: 1.23-g8d81c2c2 (x86_64) (Linux: 5.0.0-rc1-VKMS-RULES+ x86_64)
>  Force option used: Using driver vkms
>  Starting subtest: cursor-alpha-opaque
>  (kms_cursor_crc:423) igt_debugfs-WARNING: Warning on condition all_zero in 
> function crc_sanity_checks, file ../lib/igt_debugfs.c:901
>  (kms_cursor_crc:423) igt_debugfs-WARNING: Suspicious CRC: All values are 0.

If this only happens once then maybe we have a race condition somewhere in
our CRC code. Or we need to seed it with something to avoid a silly corner
case. If it happens all the time (i.e. every time the test captures a crc)
then there's a bug in our crc code.
-Daniel

>  Beginning cursor-alpha-opaque on pipe A, connector Virtual-2
>  
>  cursor-alpha-opaque on pipe A, connector Virtual-2: PASSED
>  
>  Subtest cursor-alpha-opaque: SUCCESS (0.315s)
> 
> Do you know the reason for that? Could you detail this issue? Is it
> possible to fix it?
> 
> You can see the other comments inline.
> 
> [1] https://patchwork.freedesktop.org/series/55944/
> 
> On 01/30, Mamta Shukla wrote:
> > Use the alpha value to blend vaddr_src with vaddr_dst instead
> > of overwriting it in blend().
> > 
> > Signed-off-by: Mamta Shukla 
> > ---
> > changes in v2:
> > -Use macro to avoid code duplication
> > -Add spaces around '/' and '-'
> > -Remove spaces at the end of the line
> > 
> >  drivers/gpu/drm/vkms/vkms_crc.c | 25 +++--
> >  1 file changed, 23 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_crc.c 
> > b/drivers/gpu/drm/vkms/vkms_crc.c
> > index 9d9e8146db90..dc6cb4c2cced 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> > @@ -5,6 +5,8 @@
> >  #include 
> >  #include 
> >  
> > +#define BITSHIFT(val,i)  (u8)((*(u32 *)(val)) >> i & 0xff)
> 
> - Take care with the macros definition, since you can create a precedence
>   problem. For example, here, you didn't surround “i” with “()”.
> - At the end of this operation you cast all the value to u8. In this
>   sense, why do you need the 0xff in the end?
> - I’m worried about the little and big endian issues here. If I
>   understood well, this macro could fail on a big-endian environment. Is it
>   right? Did I miss something? Could you explain to me what going to
>   happen in the big and endian case?
> - Finally, did you take a look at “include/linux/bitops.h” and
>   “include/linux/kernel.h”? These headers have a bunch of useful macros
>   and functions; probably you can find something useful for you in this
>   file. 
> 
> > +
> >  /**
> >   * compute_crc - Compute CRC value on output frame
> >   *
> > @@ -71,6 +73,9 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> > int y_limit = y_src + h_dst;
> > int x_limit = x_src + w_dst;
> >  
> > +   u8 alpha, r_src, r_dst, g_src, g_dst, b_src, b_dst;
> > +   u8 r_alpha, g_alpha, b_alpha;
> > +
> > for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
> > for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
> > offset_dst = crc_dst->offset
> > @@ -79,9 +84,25 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> > offset_src = crc_src->offset
> >  + (i * crc_src->pitch)
> >  + (j * crc_src->cpp);
> > +   
> > +   /*Currently handles alpha values for fully opaque or 
> > fully transparent*/
> > +   alpha = (u8)((*(u32 *)vaddr_src + offset_src) >> 24);
> > +   alpha = alpha / 255;
> > +   r_src = BITSHIFT(vaddr_src + offset_src, 16);
> > +   g_src = BITSHIFT(vaddr_src + offset_src, 8);
> > +   b_src = BITSHIFT(vaddr_src + offset_src, 0);
> 
> If I correctly understood, you have an u32 values which gave you 4
> bytes; because of this, you have one byte for Red, Green, Blue, and
> Alpha. The above operations extracts each value, one by one. In this
> sense, why do we need all of this bitwise operation since you can access
> it as an array of chars? Something like this (draft alert):
> 
> char *cursor_addr = (char*)vaddr_src + offset_src;
> r_src = cursor_addr[2];
> g_src = cursor_addr[1];
> b_src = cursor_addr[0];
> ...
> 
> There's any restriction for that? Is it related to the big and little
> endian issue? Finally, is it ok to make pointer operation with void* in
> the kernel?
> 
> > +   r_dst = BITSHIFT(vaddr_dst + offset_dst, 16);
> > +   g_dst = BITSHIFT(vaddr_dst + offset_dst, 8);
> > +   b_dst = 

Re: [Intel-gfx] [PATCH v4.1 0/3] CRTC background color

[Daniel Vetter]

On Wed, Jan 30, 2019 at 03:48:50PM -0800, Matt Roper wrote:
> On Wed, Jan 30, 2019 at 09:57:10PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 30, 2019 at 10:56:26AM -0800, Matt Roper wrote:
> > > On Wed, Jan 30, 2019 at 10:51:19AM -0800, Matt Roper wrote:
> > > > Previous patch series was here:
> > > >   
> > > > https://lists.freedesktop.org/archives/dri-devel/2018-December/201949.html
> > > > 
> > > > I'm told the ChromeOS userspace code to make use of the background color
> > > > has been reviewed and is ready for use:
> > > >  * https://chromium-review.googlesource.com/c/chromium/src/+/1278858
> > > >  * https://chromium-review.googlesource.com/c/chromium/src/+/1278858
> > > 
> > > Woops, the second link here should have been to
> > > 
> > >   
> > > https://chromium-review.googlesource.com/c/chromiumos/platform/drm-tests/+/1241436
> > > 
> > > which I believe is some unit tests to go along with the main userspace
> > > code.
> > 
> > Do we have this as igts too?
> > -Daniel
> 
> Yeah, I posted it along with some of the earlier revisions of the
> series, but haven't reposted the latest copy lately.  I'll check and see
> if it needs a rebase and then post it shortly.
> 
> Unfortunately the IGT isn't as useful as I'd like it to be since the
> CRC's for a plane filled with a solid color never come up the same as a
> pure background color (at least on the APL platform I'm using).  I can
> run the IGT in interactive mode and the colors seem identical to visual
> inspection, but the CRC values never agree, so I've disabled the CRC
> comparison in the test for now.  I'm not sure if this is related to the
> other blending quirks of gen9; it will be interesting to see if the
> CRC's match on an Icelake or something.

Please don't do that, we need to know when stuff doesn't work. Also, igt
(at least for more generic stuff like this) shouldn't be bent to exactly
match intel hw bugs.

And yes if the blending is generally broken on gen9 then I'd be surprised
if they managed to not screw it up for the background color. Usually
backgroun color works as if it's a separate additional plane that you
blend the others with.
-Daniel

> FWIW, I've mmap'd the Cairo-generated plane framebuffer and verified
> that it contains exactly the pixel values we'd expect (so it's not a
> matter of bad roundoff in Cairo), and I've tried flipping both 8bpc and
> 10bpc pixel formats (to match the background color's 10 bits per
> component), but nothing seems to make the CRC's match.  :-(
> 
> 
> Matt
> 
> > 
> > > 
> > > 
> > > Matt
> > > 
> > > > 
> > > > So I think ABI-wise we've met the userspace consumer requirements to
> > > > upstream this; we just need to get reviews on the two i915-specific
> > > > patches and a clean CI report.
> > > > 
> > > > v4.1 is identical to v4 aside from a rebase onto the latest drm-tip.
> > > > 
> > > > 
> > > > Matt Roper (3):
> > > >   drm/i915: Force background color to black for gen9+ (v2)
> > > >   drm: Add CRTC background color property (v4)
> > > >   drm/i915/gen9+: Add support for pipe background color (v4)
> > > > 
> > > >  drivers/gpu/drm/drm_atomic_uapi.c|  4 
> > > >  drivers/gpu/drm/drm_blend.c  | 27 +++---
> > > >  drivers/gpu/drm/drm_mode_config.c|  6 +
> > > >  drivers/gpu/drm/i915/i915_debugfs.c  |  9 
> > > >  drivers/gpu/drm/i915/i915_reg.h  |  6 +
> > > >  drivers/gpu/drm/i915/intel_display.c | 43 
> > > > 
> > > >  include/drm/drm_blend.h  |  1 +
> > > >  include/drm/drm_crtc.h   | 12 ++
> > > >  include/drm/drm_mode_config.h|  5 +
> > > >  include/uapi/drm/drm_mode.h  | 28 +++
> > > >  10 files changed, 138 insertions(+), 3 deletions(-)
> > > > 
> > > > -- 
> > > > 2.14.5
> > > > 
> > > 
> > > -- 
> > > Matt Roper
> > > Graphics Software Engineer
> > > IoTG Platform Enabling & Development
> > > Intel Corporation
> > > (916) 356-2795
> > > ___
> > > Intel-gfx mailing list
> > > intel-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795

-- 
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 5/5] drm: vc4: Switch to use drm_gem_object reservation_object

[Eric Anholt]

Rob Herring  writes:

> Now that the base struct drm_gem_object has a reservation_object, use it
> and remove the private BO one.

Reviewed-by: Eric Anholt 


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

Re: [PATCH 4/5] drm: v3d: Switch to use drm_gem_object reservation_object

[Eric Anholt]

Rob Herring  writes:

> Now that the base struct drm_gem_object has a reservation_object, use it
> and remove the private BO one.
>
> Cc: Eric Anholt 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring 

> @@ -453,8 +453,6 @@ v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
>  {
>   int ret;
>   struct drm_v3d_wait_bo *args = data;
> - struct drm_gem_object *gem_obj;
> - struct v3d_bo *bo;
>   ktime_t start = ktime_get();
>   u64 delta_ns;
>   unsigned long timeout_jiffies =
> @@ -463,21 +461,8 @@ v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
>   if (args->pad != 0)
>   return -EINVAL;
>  
> - gem_obj = drm_gem_object_lookup(file_priv, args->handle);
> - if (!gem_obj) {
> - DRM_DEBUG("Failed to look up GEM BO %d\n", args->handle);
> - return -EINVAL;
> - }
> - bo = to_v3d_bo(gem_obj);
> -
> - ret = reservation_object_wait_timeout_rcu(bo->resv,
> -   true, true,
> -   timeout_jiffies);
> -
> - if (ret == 0)
> - ret = -ETIME;
> - else if (ret > 0)
> - ret = 0;
> + ret = drm_gem_reservation_object_wait(file_priv, args->handle,
> +   true, timeout_jiffies);

Looks like you lost my ret handling in the change.

Honestly, I'd love to see drm_gem_reservation_object_wait return
sensible values like this (0 for success, -ETIME for timeouts) instead
of drivers having to stubmle over this API.


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

Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI

[Jagan Teki]

On Fri, Feb 1, 2019 at 8:01 PM Maxime Ripard  wrote:
>
> On Tue, Jan 29, 2019 at 11:01:31PM +0530, Jagan Teki wrote:
> > On Tue, Jan 29, 2019 at 8:43 PM Maxime Ripard  
> > wrote:
> > >
> > > On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote:
> > > > On Sat, Jan 26, 2019 at 2:54 AM Maxime Ripard 
> > > >  wrote:
> > > > >
> > > > > On Fri, Jan 25, 2019 at 01:28:49AM +0530, Jagan Teki wrote:
> > > > > > Minimum PLL used for MIPI is 500MHz, as per manual, but
> > > > > > lowering the min rate by 300MHz can result proper working
> > > > > > nkms divider with the help of desired dclock rate from
> > > > > > panel driver.
> > > > > >
> > > > > > Signed-off-by: Jagan Teki 
> > > > > > Acked-by: Stephen Boyd 
> > > > >
> > > > > Going 200MHz below the minimum doesn't seem really reasonable. What
> > > > > is the issue that you are trying to fix here?
> > > > >
> > > > > It looks like it's picking bad dividers, but if that's the case, this
> > > > > isn't the proper fix.
> > > >
> > > > As I stated in earlier patches, the whole idea is pick the desired
> > > > dclk divider based dclk rate. So the dotclock, sun4i_dclk_round_rate
> > > > is unable to get the proper dclk divider at the end, so it eventually
> > > > picking up wrong divider value and fired vblank timeout.
> > > >
> > > > So, we come-up with optimal and working min_rate 300MHz in pll-mipi to
> > > > get the desired clock something like below.
> > > > [2.415773] [drm] No driver support for vblank timestamp query.
> > > > [2.424116] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = 
> > > > 5500
> > > > [2.424172] ideal = 22000, rounded = 0
> > > > [2.424176] ideal = 27500, rounded = 0
> > > > [2.424194] ccu_nkm_round_rate: rate = 33000
> > > > [2.424197] ideal = 33000, rounded = 33000
> > > > [2.424201] sun4i_dclk_round_rate: div = 6 rate = 5500
> > > > [2.424205] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = 
> > > > 5500
> > > > [2.424209] ideal = 22000, rounded = 0
> > > > [2.424213] ideal = 27500, rounded = 0
> > > > [2.424230] ccu_nkm_round_rate: rate = 33000
> > > > [2.424233] ideal = 33000, rounded = 33000
> > > > [2.424236] sun4i_dclk_round_rate: div = 6 rate = 5500
> > > > [2.424253] ccu_nkm_round_rate: rate = 33000
> > > > [2.424270] ccu_nkm_round_rate: rate = 33000
> > > > [2.424278] sun4i_dclk_recalc_rate: val = 1, rate = 33000
> > > > [2.424281] sun4i_dclk_recalc_rate: val = 1, rate = 33000
> > > > [2.424306] ccu_nkm_set_rate: rate = 33000, parent_rate = 
> > > > 29700
> > > > [2.424309] ccu_nkm_set_rate: _nkm.n = 5
> > > > [2.424311] ccu_nkm_set_rate: _nkm.k = 2
> > > > [2.424313] ccu_nkm_set_rate: _nkm.m = 9
> > > > [2.424661] sun4i_dclk_set_rate div 6
> > > > [2.424668] sun4i_dclk_recalc_rate: val = 6, rate = 5500
> > > >
> > > > But look like this wouldn't valid for all other dclock rates, say BPI
> > > > panel has 30MHz clock that would failed with this logic.
> > > >
> > > > On the other side Allwinner BSP calculating dclk divider based on the
> > > > SoC's. for A33 [1] it is fixed dclk divider of 4 and for A64 is is
> > > > calculated based on the bpp/lanes.
> > >
> > > It looks like the A64 has the same divider of 4:
> > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L12
> > >
> > > I think you're confusing it with the ratio between the pixel clock and
> > > the dotclock, called dsi_div:
> > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L198
> >
> > Ahh.. I thought this initially but as far as DSI clock computation is
> > concern, the L12 tcon_div is local variable which is used for edge0
> > computation in burst mode and not for the dsi clock computation. Since
> > the BSP is unable to get the tcon_div during edge0 computation, they
> > defined it locally I think.
> >
> > You can see the lcd_clk_config() code [2], where we can see DSI clock
> > computation using dsi_div value.
> >
> > Here is dump after the in Line 792 which is after computation[3]
> > [   10.800737] lcd_clk_config: dsi_div = 6, tcon_div = 4, lcd_div = 1
> > [   10.800743] lcd_clk_config: lcd_dclk_freq = 55, dclk_rate = 5500
> > [   10.800749] lcd_clk_config: lcd_rate = 33000, pll_rate = 33000
> >
> > The above dump the lcd_rate 330MHz is computed with panel clock, 55MHz
> > into dsi_div 6. So this can be our actual divider values dclk_min_div,
> > dclk_max_div in sun4i_dclk_round_rate (from
> > drivers/gpu/drm/sun4i/sun4i_dotclock.c)
>
> I wish it was in your commit log in the first place, instead of having
> to exchange multiple mails over this.
>
> However, I don't think that's quite true, and it might be a bug in
> Allwinner's implementation (or rather something quite confusing).
>

Re: [PATCH v7 00/23] drm/sun4i: Allwinner A64 MIPI-DSI support

[Jagan Teki]

On Fri, Feb 1, 2019 at 9:19 PM Maxime Ripard  wrote:
>
> On Fri, Feb 01, 2019 at 09:12:09PM +0530, Jagan Teki wrote:
> > Here is next version changes for Allwinner A64 MIPI-DSI support
> >
> > This series grouped the changes like previous version[1] with different
> > sets to support three different panels types that can fit into the DSI
> > controller.
> >
> > set:1, for 4-lane, burst mode support
> > - patch 0001: 0009, DSI controller changes that support burst mode.
> >
> > set:2, for A64 DSI support
> > - patch 0010: tcon dclk divider computation based on A64 BSP.
> > - patch 0011: 0017, Allwinner A64 DSI controller changes.
> >
> > set:3, enable 4-lane burst mode panel:
> > - patch 0018: Overlay patch that enable Feiyang FY07024DI26A30-D
> >   burst mode panel on Pine64-LTS
> >
> > set:4, enable 4-lane video mode panel:
> > - patch 0019: msg type MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM support
> > - patch 0020: Overlay patch that enable Bananapi S070WV20-CT16 ICN6211
> >   panel on Bananapi M64
> >
> > set:5, enable 2-lane video mode panel:
> > - patch 0021, 0022: DSI hfp and hbp timings fixes
> > - patch 0023: Enable Techstar TS8550B panel on Amarula A64-Relic
>
> You do realise that pushing through a series while the previous
> version's discussion hasn't settled yet will not get you anywhere,
> right?

Except the clock, I made few changes with your previous comments. Yes
we can still under clock discussion page, no issues on that. just to
group the remaining patches to finalize if any issues on those.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 00/23] drm/sun4i: Allwinner A64 MIPI-DSI support

[Maxime Ripard]

On Fri, Feb 01, 2019 at 09:12:09PM +0530, Jagan Teki wrote:
> Here is next version changes for Allwinner A64 MIPI-DSI support
> 
> This series grouped the changes like previous version[1] with different
> sets to support three different panels types that can fit into the DSI
> controller.
> 
> set:1, for 4-lane, burst mode support
> - patch 0001: 0009, DSI controller changes that support burst mode.
> 
> set:2, for A64 DSI support
> - patch 0010: tcon dclk divider computation based on A64 BSP. 
> - patch 0011: 0017, Allwinner A64 DSI controller changes.
> 
> set:3, enable 4-lane burst mode panel:
> - patch 0018: Overlay patch that enable Feiyang FY07024DI26A30-D
>   burst mode panel on Pine64-LTS
> 
> set:4, enable 4-lane video mode panel:
> - patch 0019: msg type MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM support
> - patch 0020: Overlay patch that enable Bananapi S070WV20-CT16 ICN6211 
>   panel on Bananapi M64
> 
> set:5, enable 2-lane video mode panel:
> - patch 0021, 0022: DSI hfp and hbp timings fixes
> - patch 0023: Enable Techstar TS8550B panel on Amarula A64-Relic

You do realise that pushing through a series while the previous
version's discussion hasn't settled yet will not get you anywhere,
right?

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 19/23] drm/sun4i: sun6i_mipi_dsi: Add DSI Generic short write 2 param transfer

[Jagan Teki]

Short transfer write support for DCS and Generic transfer types
share similar way to process command sequence in DSI block so
add generic write 2 param transfer type macro so-that the panels
which are requesting similar transfer type may process properly.

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index a0697d78b915..09569938c20d 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -984,6 +984,7 @@ static ssize_t sun6i_dsi_transfer(struct mipi_dsi_host 
*host,
switch (msg->type) {
case MIPI_DSI_DCS_SHORT_WRITE:
case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
+   case MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM:
ret = sun6i_dsi_dcs_write_short(dsi, msg);
break;
 
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 17/23] arm64: dts: allwinner: a64: Add MIPI DSI pipeline

[Jagan Teki]

Add MIPI DSI pipeline for Allwinner A64.

- dsi node, with A64 compatible since it doesn't support
  DSI_SCLK gating unlike A33
- dphy node, with A64 compatible with A33 fallback since
  DPHY on A64 and A33 is similar
- finally, attach the dsi_in to tcon0 for complete MIPI DSI

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 45 +++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 6e5a608f56f2..f221c50e7fd4 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -359,6 +359,12 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+
+   tcon0_out_dsi: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = 
<_in_tcon0>;
+   allwinner,tcon-channel = <1>;
+   };
};
};
};
@@ -936,6 +942,45 @@
status = "disabled";
};
 
+   dsi: dsi@1ca {
+   compatible = "allwinner,sun50i-a64-mipi-dsi";
+   reg = <0x01ca 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_MIPI_DSI>;
+   clock-names = "bus";
+   resets = < RST_BUS_MIPI_DSI>;
+   phys = <>;
+   phy-names = "dphy";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   dsi_in_tcon0: endpoint {
+   remote-endpoint = 
<_out_dsi>;
+   };
+   };
+   };
+   };
+
+   dphy: d-phy@1ca1000 {
+   compatible = "allwinner,sun50i-a64-mipi-dphy",
+"allwinner,sun6i-a31-mipi-dphy";
+   reg = <0x01ca1000 0x1000>;
+   clocks = < CLK_BUS_MIPI_DSI>,
+< CLK_DSI_DPHY>;
+   clock-names = "bus", "mod";
+   resets = < RST_BUS_MIPI_DSI>;
+   status = "disabled";
+   #phy-cells = <0>;
+   };
+
csi: csi@1cb {
compatible = "allwinner,sun50i-a64-csi";
reg = <0x01cb 0x1000>;
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 02/23] drm/sun4i: sun6i_mipi_dsi: Support instruction loop selection

[Jagan Teki]

Instruction loop selection would require before writing
loop number registers, so enable idle, LP11 bits on
loop selection register.

Reference code available in BSP (from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)

(dsi_dev[sel]->dsi_inst_loop_sel.dwval = 2<<(4*DSI_INST_ID_LP11) |
3<<(4*DSI_INST_ID_DLY);

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index a5fcee750bee..813d5523f1c7 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -403,6 +403,9 @@ static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi,
 {
u16 delay = sun6i_dsi_setup_inst_delay(dsi, mode);
 
+   regmap_write(dsi->regs, SUN6I_DSI_INST_LOOP_SEL_REG,
+DSI_INST_ID_HSC  << (4 * DSI_INST_ID_LP11) |
+DSI_INST_ID_HSD  << (4 * DSI_INST_ID_DLY));
regmap_write(dsi->regs, SUN6I_DSI_INST_LOOP_NUM_REG(0),
 SUN6I_DSI_INST_LOOP_NUM_N0(50 - 1) |
 SUN6I_DSI_INST_LOOP_NUM_N1(delay));
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 22/23] drm/sun4i: sun6i_mipi_dsi: Fix DSI hfp timing value

[Jagan Teki]

Current driver is calculating hfp maximum value by subtracting
htotal with hsync_end which is front back value, but the
hpp refers to front porch.

Front porch value is calculating by subtracting hsync_start with
hdisplay as per drm_mode timings, and BSP code from BPI-M64-bsp
is eventually following the same.

BPI-M64-bsp is computing hfp as (from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)

dsi_hbp = (hbp-hspw)*dsi_pixel_bits[format]/8 - (4+2);
dsi_hact = x * dsi_pixel_bits[format]/8;
dsi_hblk = (ht-hspw)*dsi_pixel_bits[format]/8-(4+4+2);
dsi_hfp = dsi_hblk - (4+dsi_hact+2) - (4+dsi_hbp+2);

Example,
u32 fmt = dsi_pixel_bits[format]/8;
=> ((ht-hspw)*fmt - 10) - (6 + x * fmt) - (6 + (hbp-hspw)*fmt - 6)
=> (ht - hspw - x - (hbp - hspw)) * fmt - 16
=> (ht - x - hbp) * fmt - 16
=> (ht - x - (timmings->hor_total_time - timmings->hor_front_porch - x)
* fmt - 16
=> (timmings->hor_total_time - x - timmings->hor_total_time +
timmings->hor_front_porch + x) * fmt - 16
=> timmings->hor_front_porch * fmt - 16

So, update the DSI hfp timing accordingly.

Tested on 2-lane, 4-lane MIPI-DSI LCD panels.

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 780b1906c661..3fbe2132eb6a 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -587,7 +587,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
 */
 #define HFP_PACKET_OVERHEAD6
hfp = max((unsigned int)HFP_PACKET_OVERHEAD,
- (mode->htotal - mode->hsync_end) * Bpp - HFP_PACKET_OVERHEAD);
+ (mode->hsync_start - mode->hdisplay) * Bpp -
+ HFP_PACKET_OVERHEAD);
 
/*
 * hblk seems to be the line + porches length.
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 15/23] drm/sun4i: sun6i_mipi_dsi: Add has_mod_clk quirk

[Jagan Teki]

As per the user manual, look like mod clock is not mandatory
for all Allwinner MIPI DSI controllers, it is connected to
CLK_DSI_SCLK for A31 and not available in A64.

So add has_mod_clk quirk and process the clk accordingly.

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 38 ++
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |  5 
 2 files changed, 32 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 9be414131460..de7d9dcb049f 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1099,6 +1100,7 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
dsi->dev = dev;
dsi->host.ops = _dsi_host_ops;
dsi->host.dev = dev;
+   dsi->variant = of_device_get_match_data(dev);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(dev, res);
@@ -1126,17 +1128,20 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
return PTR_ERR(dsi->reset);
}
 
-   dsi->mod_clk = devm_clk_get(dev, "mod");
-   if (IS_ERR(dsi->mod_clk)) {
-   dev_err(dev, "Couldn't get the DSI mod clock\n");
-   return PTR_ERR(dsi->mod_clk);
+   if (dsi->variant->has_mod_clk) {
+   dsi->mod_clk = devm_clk_get(dev, "mod");
+   if (IS_ERR(dsi->mod_clk)) {
+   dev_err(dev, "Couldn't get the DSI mod clock\n");
+   return PTR_ERR(dsi->mod_clk);
+   }
}
 
/*
 * In order to operate properly, that clock seems to be always
 * set to 297MHz.
 */
-   clk_set_rate_exclusive(dsi->mod_clk, 29700);
+   if (dsi->variant->has_mod_clk)
+   clk_set_rate_exclusive(dsi->mod_clk, 29700);
 
dphy_node = of_parse_phandle(dev->of_node, "phys", 0);
ret = sun6i_dphy_probe(dsi, dphy_node);
@@ -1168,7 +1173,8 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
pm_runtime_disable(dev);
sun6i_dphy_remove(dsi);
 err_unprotect_clk:
-   clk_rate_exclusive_put(dsi->mod_clk);
+   if (dsi->variant->has_mod_clk)
+   clk_rate_exclusive_put(dsi->mod_clk);
return ret;
 }
 
@@ -1181,7 +1187,8 @@ static int sun6i_dsi_remove(struct platform_device *pdev)
mipi_dsi_host_unregister(>host);
pm_runtime_disable(dev);
sun6i_dphy_remove(dsi);
-   clk_rate_exclusive_put(dsi->mod_clk);
+   if (dsi->variant->has_mod_clk)
+   clk_rate_exclusive_put(dsi->mod_clk);
 
return 0;
 }
@@ -1198,7 +1205,8 @@ static int __maybe_unused sun6i_dsi_runtime_resume(struct 
device *dev)
}
 
reset_control_deassert(dsi->reset);
-   clk_prepare_enable(dsi->mod_clk);
+   if (dsi->variant->has_mod_clk)
+   clk_prepare_enable(dsi->mod_clk);
 
/*
 * Enable the DSI block.
@@ -1226,7 +1234,8 @@ static int __maybe_unused 
sun6i_dsi_runtime_suspend(struct device *dev)
 {
struct sun6i_dsi *dsi = dev_get_drvdata(dev);
 
-   clk_disable_unprepare(dsi->mod_clk);
+   if (dsi->variant->has_mod_clk)
+   clk_disable_unprepare(dsi->mod_clk);
reset_control_assert(dsi->reset);
regulator_disable(dsi->regulator);
 
@@ -1239,9 +1248,16 @@ static const struct dev_pm_ops sun6i_dsi_pm_ops = {
   NULL)
 };
 
+static const struct sun6i_dsi_variant sun6i_a31_mipi_dsi = {
+   .has_mod_clk = true,
+};
+
 static const struct of_device_id sun6i_dsi_of_table[] = {
-   { .compatible = "allwinner,sun6i-a31-mipi-dsi" },
-   { }
+   {
+   .compatible = "allwinner,sun6i-a31-mipi-dsi",
+   .data = _a31_mipi_dsi,
+   },
+   { /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
 
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
index 06cce0d0d3ad..3c532e83958d 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
@@ -22,6 +22,10 @@ struct sun6i_dphy {
struct reset_control*reset;
 };
 
+struct sun6i_dsi_variant {
+   boolhas_mod_clk;
+};
+
 struct sun6i_dsi {
struct drm_connectorconnector;
struct drm_encoder  encoder;
@@ -39,6 +43,7 @@ struct sun6i_dsi {
struct sun4i_tcon   *tcon;
struct mipi_dsi_device  *device;
struct drm_panel*panel;
+   const struct sun6i_dsi_variant  *variant;
 };
 
 static inline struct sun6i_dsi *host_to_sun6i_dsi(struct mipi_dsi_host *host)
-- 
2.18.0.321.gffc6fa0e3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH v7 09/23] drm/sun4i: sun6i_mipi_dsi: Enable HBP, HSA_HSE for burst mode

[Jagan Teki]

Horizontal back porch, sync active and sync end bits are
needed to disable for burst mode panel operations.

So, disable them via dsi base control register.

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index a2ad9fa7f8d5..3d7c03161954 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -549,12 +549,17 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
u16 hbp, hfp, hsa, hblk, vblk;
size_t bytes;
u8 *buffer;
+   u32 val = 0;
 
/* Do all timing calculations up front to allocate buffer space */
 
if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
hbp = hfp = hsa = vblk = 0;
hblk = (mode->hdisplay * Bpp);
+
+   regmap_read(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, );
+   val |= SUN6I_DSI_BASIC_CTL_HBP_DIS;
+   val |= SUN6I_DSI_BASIC_CTL_HSA_HSE_DIS;
goto alloc_buf;
}
 
@@ -603,7 +608,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
if (WARN_ON(!buffer))
return;
 
-   regmap_write(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, 0);
+   regmap_write(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, val);
 
regmap_write(dsi->regs, SUN6I_DSI_SYNC_HSS_REG,
 sun6i_dsi_build_sync_pkt(MIPI_DSI_H_SYNC_START,
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 16/23] drm/sun4i: sun6i_mipi_dsi: Add Allwinner A64 MIPI DSI support

[Jagan Teki]

The MIPI DSI controller in Allwinner A64 is similar to A33.

But unlike A33, A64 doesn't have DSI_SCLK gating so add compatible
for Allwinner A64 with uninitialized has_mod_clk driver.

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index de7d9dcb049f..a0697d78b915 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -1252,11 +1252,18 @@ static const struct sun6i_dsi_variant 
sun6i_a31_mipi_dsi = {
.has_mod_clk = true,
 };
 
+static const struct sun6i_dsi_variant sun50i_a64_mipi_dsi = {
+};
+
 static const struct of_device_id sun6i_dsi_of_table[] = {
{
.compatible = "allwinner,sun6i-a31-mipi-dsi",
.data = _a31_mipi_dsi,
},
+   {
+   .compatible = "allwinner,sun50i-a64-mipi-dsi",
+   .data = _a64_mipi_dsi,
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 12/23] drm/sun4i: sun6i_mipi_dsi: Add support for VCC-DSI voltage regulator

[Jagan Teki]

Allwinner MIPI DSI controllers are supplied with SoC DSI power rails
via VCC-DSI pin.

Add support for this supply pin by adding voltage regulator handling
code to MIPI DSI driver.

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 14 ++
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |  3 +++
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 3d7c03161954..9be414131460 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -1107,6 +1107,12 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
return PTR_ERR(base);
}
 
+   dsi->regulator = devm_regulator_get(dev, "vcc-dsi");
+   if (IS_ERR(dsi->regulator)) {
+   dev_err(dev, "Couldn't get VCC-DSI supply\n");
+   return PTR_ERR(dsi->regulator);
+   }
+
dsi->regs = devm_regmap_init_mmio_clk(dev, "bus", base,
  _dsi_regmap_config);
if (IS_ERR(dsi->regs)) {
@@ -1183,6 +1189,13 @@ static int sun6i_dsi_remove(struct platform_device *pdev)
 static int __maybe_unused sun6i_dsi_runtime_resume(struct device *dev)
 {
struct sun6i_dsi *dsi = dev_get_drvdata(dev);
+   int err;
+
+   err = regulator_enable(dsi->regulator);
+   if (err) {
+   dev_err(dsi->dev, "failed to enable VCC-DSI supply: %d\n", err);
+   return err;
+   }
 
reset_control_deassert(dsi->reset);
clk_prepare_enable(dsi->mod_clk);
@@ -1215,6 +1228,7 @@ static int __maybe_unused 
sun6i_dsi_runtime_suspend(struct device *dev)
 
clk_disable_unprepare(dsi->mod_clk);
reset_control_assert(dsi->reset);
+   regulator_disable(dsi->regulator);
 
return 0;
 }
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
index 257cca660da0..06cce0d0d3ad 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include 
+
 struct sun6i_dphy {
struct clk  *bus_clk;
struct clk  *mod_clk;
@@ -28,6 +30,7 @@ struct sun6i_dsi {
struct clk  *bus_clk;
struct clk  *mod_clk;
struct regmap   *regs;
+   struct regulator*regulator;
struct reset_control*reset;
struct sun6i_dphy   *dphy;
 
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 11/23] dt-bindings: sun6i-dsi: Add VCC-DSI supply property

[Jagan Teki]

Allwinner MIPI DSI controllers are supplied with SoC DSI
power rails via VCC-DSI pin.

Some board still work without supplying this but give more
faith on datasheet and hardware schematics and document this
supply property in required property list.

Signed-off-by: Jagan Teki 
Reviewed-by: Rob Herring 
Tested-by: Merlijn Wajer 
---
 Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
index 6a6cf5de08b0..1cc40663b7a2 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
@@ -21,6 +21,7 @@ Required properties:
   - phys: phandle to the D-PHY
   - phy-names: must be "dphy"
   - resets: phandle to the reset controller driving the encoder
+  - vcc-dsi-supply: the VCC-DSI power supply of the DSI encoder
 
   - ports: A ports node with endpoint definitions as defined in
 Documentation/devicetree/bindings/media/video-interfaces.txt. The
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 21/23] drm/sun4i: sun6i_mipi_dsi: Fix DSI hbp timing value

[Jagan Teki]

Current driver is calculating hbp maximum value by subtracting
hsync_start with hdisplay which is front porch value, but the
hbp refers to back porch.

Back porch value is calculating by subtracting htotal with
hsync_end as per drm_mode timings, and BSP code from BPI-M64-bsp
is eventually following the same.

BPI-M64-bsp is computing hbp as
(in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
dsi_hbp = (hbp-hspw)*dsi_pixel_bits[format]/8 - (4+2);
=> (panel->lcd_hbp - timmings->hor_sync_time)
=> (timmings->hor_back_porch + timmings->hor_sync_time -
timmings->hor_sync_time)
=> timmings->hor_back_porch
=> mode->htotal - mode->hsync_end

So, update the MIPI-DSI hbp value accordingly.

Tested on 2-lane, 4-lane DSI LCD panels.

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 09569938c20d..780b1906c661 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -579,7 +579,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
 */
 #define HBP_PACKET_OVERHEAD6
hbp = max((unsigned int)HBP_PACKET_OVERHEAD,
- (mode->hsync_start - mode->hdisplay) * Bpp - 
HBP_PACKET_OVERHEAD);
+ (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD);
 
/*
 * The frontporch is set using a blanking packet (4 bytes +
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 07/23] drm/sun4i: sun6i_mipi_dsi: Setup burst mode

[Jagan Teki]

Burst mode in DSI would require separate setup initialization
with respect to conventional video mode.

Allwinner DSI controller would need below sequence to setup the
burst mode.
1) configure the burst drq.
2) configure the burst line.
3) finally enable mode.

To configure burst drq, controller would require to compute the edge0,
edge1 and fill into burst mode register.

To configure burst line, controller would require to compute the line,
sync values and fill into burst line register.

Enable burst mode, would require to enable burst mode bit in DSI control
register.

Since there is no direct documentation for these computations
the edge and line formulas are taken from BSP code (from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)

line_num = panel->lcd_ht*dsi_pixel_bits[panel->lcd_dsi_format]/
  (8*panel->lcd_dsi_lane);
edge1 = sync_point+(panel->lcd_x+panel->lcd_hbp+20)*
dsi_pixel_bits[panel->lcd_dsi_format] /(8*panel->lcd_dsi_lane);
edge1 = (edge1>line_num)?line_num:edge1;
edge0 = edge1+(panel->lcd_x+40)*tcon_div/8;
edge0 = (edge0>line_num)?(edge0-line_num):1;

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 70 --
 1 file changed, 67 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 2aeaa19a8d1e..46ad142e66e8 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -355,6 +355,41 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
 SUN6I_DSI_INST_JUMP_CFG_NUM(1));
 };
 
+static u32 sun6i_dsi_get_edge1(struct sun6i_dsi *dsi,
+  struct drm_display_mode *mode, u32 sync_point)
+{
+   struct mipi_dsi_device *device = dsi->device;
+   unsigned int bpp = mipi_dsi_pixel_format_to_bpp(device->format);
+   u32 hact_sync_bp;
+
+   /* Horizontal timings duration excluding front porch */
+   hact_sync_bp = (mode->hdisplay + mode->htotal - mode->hsync_start);
+
+   return (sync_point + ((hact_sync_bp + 20) * bpp / (8 * device->lanes)));
+}
+
+static u32 sun6i_dsi_get_edge0(struct sun6i_dsi *dsi,
+  struct drm_display_mode *mode, u32 edge1)
+{
+   struct sun4i_tcon *tcon = dsi->tcon;
+   unsigned long dclk_rate, dclk_parent_rate, tcon0_div;
+
+   dclk_rate = clk_get_rate(tcon->dclk);
+   dclk_parent_rate = clk_get_rate(clk_get_parent(tcon->dclk));
+   tcon0_div = dclk_parent_rate / dclk_rate;
+
+   return (edge1 + (mode->hdisplay + 40) * tcon0_div / 8);
+}
+
+static u32 sun6i_dsi_get_line_num(struct sun6i_dsi *dsi,
+ struct drm_display_mode *mode)
+{
+   struct mipi_dsi_device *device = dsi->device;
+   unsigned int bpp = mipi_dsi_pixel_format_to_bpp(device->format);
+
+   return (mode->htotal * bpp / (8 * device->lanes));
+}
+
 static int sun6i_dsi_get_drq(struct sun6i_dsi *dsi,
  struct drm_display_mode *mode)
 {
@@ -404,8 +439,32 @@ static u16 sun6i_dsi_get_video_start_delay(struct 
sun6i_dsi *dsi,
 static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
  struct drm_display_mode *mode)
 {
-   regmap_write(dsi->regs, SUN6I_DSI_TCON_DRQ_REG,
-sun6i_dsi_get_drq(dsi, mode));
+   struct mipi_dsi_device *device = dsi->device;
+   u32 sync_point = 40;
+   u32 line_num = sun6i_dsi_get_line_num(dsi, mode);
+   u32 edge1 = sun6i_dsi_get_edge1(dsi, mode, sync_point);
+   u32 edge0 = sun6i_dsi_get_edge0(dsi, mode, edge1);
+   u32 val;
+
+   if (edge1 > line_num)
+   edge1 = line_num;
+
+   if (edge0 > line_num)
+   edge0 -= line_num;
+   else
+   edge0 = 1;
+
+   regmap_write(dsi->regs, SUN6I_DSI_BURST_DRQ_REG,
+SUN6I_DSI_BURST_DRQ_EDGE1(edge1) |
+SUN6I_DSI_BURST_DRQ_EDGE0(edge0));
+   regmap_write(dsi->regs, SUN6I_DSI_BURST_LINE_REG,
+SUN6I_DSI_BURST_LINE_NUM(line_num) |
+SUN6I_DSI_BURST_LINE_SYNC_POINT(sync_point));
+
+   /* enable burst mode */
+   regmap_read(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, );
+   val |= SUN6I_DSI_BASIC_CTL_VIDEO_BURST;
+   regmap_write(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, val);
 }
 
 static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi,
@@ -667,7 +726,12 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
*encoder)
 SUN6I_DSI_BASIC_CTL1_VIDEO_PRECISION |
 SUN6I_DSI_BASIC_CTL1_VIDEO_MODE);
 
-   sun6i_dsi_setup_burst(dsi, mode);
+   regmap_write(dsi->regs, SUN6I_DSI_TCON_DRQ_REG,
+sun6i_dsi_get_drq(dsi, mode));
+
+   if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
+   sun6i_dsi_setup_burst(dsi, mode);
+

[PATCH v7 04/23] drm/sun4i: sun6i_mipi_dsi: Simplify drq to support all modes

[Jagan Teki]

Allwinner MIPI DSI drq has enable mode bit and set bits.
1) drq for non-burst, with front porch less than 20 would need to
   set both enable mode bit and set bits.
2) drq for non-burst, with front porch greater or equal to 20 would
   not require to do any drq bit setup.
3) drq for burst mode, would only need to set enable mode bit.

This patch simplifies existing drq code by grouping into
sun6i_dsi_get_drq and support all video modes.

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 39 --
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 0f02bcc997a5..16a86d35dc5a 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -354,6 +354,28 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
 SUN6I_DSI_INST_JUMP_CFG_NUM(1));
 };
 
+static int sun6i_dsi_get_drq(struct sun6i_dsi *dsi,
+ struct drm_display_mode *mode)
+{
+   struct mipi_dsi_device *device = dsi->device;
+
+   if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
+   return SUN6I_DSI_TCON_DRQ_ENABLE_MODE;
+
+   if ((mode->hsync_start - mode->hdisplay) > 20) {
+   /* Maagic */
+   u16 drq = (mode->hsync_start - mode->hdisplay) - 20;
+
+   drq *= mipi_dsi_pixel_format_to_bpp(device->format);
+   drq /= 32;
+
+   return (SUN6I_DSI_TCON_DRQ_ENABLE_MODE |
+   SUN6I_DSI_TCON_DRQ_SET(drq));
+   }
+
+   return 0;
+}
+
 static u16 sun6i_dsi_setup_inst_delay(struct sun6i_dsi *dsi,
  struct drm_display_mode *mode)
 {
@@ -381,21 +403,8 @@ static u16 sun6i_dsi_get_video_start_delay(struct 
sun6i_dsi *dsi,
 static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
  struct drm_display_mode *mode)
 {
-   struct mipi_dsi_device *device = dsi->device;
-   u32 val = 0;
-
-   if ((mode->hsync_end - mode->hdisplay) > 20) {
-   /* Maagic */
-   u16 drq = (mode->hsync_end - mode->hdisplay) - 20;
-
-   drq *= mipi_dsi_pixel_format_to_bpp(device->format);
-   drq /= 32;
-
-   val = (SUN6I_DSI_TCON_DRQ_ENABLE_MODE |
-  SUN6I_DSI_TCON_DRQ_SET(drq));
-   }
-
-   regmap_write(dsi->regs, SUN6I_DSI_TCON_DRQ_REG, val);
+   regmap_write(dsi->regs, SUN6I_DSI_TCON_DRQ_REG,
+sun6i_dsi_get_drq(dsi, mode));
 }
 
 static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi,
-- 
2.18.0.321.gffc6fa0e3

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

[DO NOT MERGE][PATCH v7 18/23] arm64: allwinner: a64: pine64-lts: Enable Feiyang FY07024DI26A30-D DSI panel

[Jagan Teki]

Feiyang FY07024DI26A30-D MIPI_DSI panel is desiged to attach with
DSI connector on pine64 boards, enable the same for pine64 LTS.

DSI panel connected via board DSI port with,
- DC1SW as AVDD supply
- DLDO2 as DVDD supply
- DLDO1 as VCC-DSI supply
- PD24 gpio for reset pin
- PH10 gpio for backlight enable pin

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 .../dts/allwinner/sun50i-a64-pine64-lts.dts   | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
index 72d6961dc312..341b1c035604 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
@@ -5,9 +5,48 @@
  */
 
 #include "sun50i-a64-sopine-baseboard.dts"
+#include 
 
 / {
model = "Pine64 LTS";
compatible = "pine64,pine64-lts", "allwinner,sun50i-r18",
 "allwinner,sun50i-a64";
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
+   brightness-levels = <1 2 4 8 16 32 64 128 512>;
+   default-brightness-level = <8>;
+   enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PH10 
*/
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   vcc-dsi-supply = <_dldo1>;  /* VCC3V3-DSI */
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   panel@0 {
+   compatible = "feiyang,fy07024di26a30d";
+   reg = <0>;
+   avdd-supply = <_dc1sw>; /* VCC-LCD */
+   dvdd-supply = <_dldo2>; /* VCC-MIPI */
+   reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+   backlight = <>;
+   };
+};
+
+_pwm {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwm_pin>;
+   status = "okay";
 };
-- 
2.18.0.321.gffc6fa0e3

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

[DO NOT MERGE][PATCH v7 20/23] arm64: dts: allwinner: bananapi-m64: Bananapi S070WV20-CT16 DSI panel

[Jagan Teki]

This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M64 board.

DSI panel connected via board DSI port with,
- DLDO1 as VDD supply
- PD6 gpio for reset pin
- PD5 gpio for backlight enable pin
- PD7 gpio for backlight vdd supply

Signed-off-by: Jagan Teki 
---
 .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index c99f66271287..14ecc57c72cf 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -45,6 +45,7 @@
 #include "sun50i-a64.dtsi"
 
 #include 
+#include 
 
 / {
model = "BananaPi-M64";
@@ -56,6 +57,15 @@
serial1 = 
};
 
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
+   brightness-levels = <1 2 4 8 16 32 64 128 512>;
+   default-brightness-level = <2>;
+   enable-gpios = < 3 5 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PD5 */
+   power-supply = <_vdd_backlight>;
+   };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -126,6 +136,15 @@
};
};
 
+   reg_vdd_backlight: vdd-backlight {
+   compatible = "regulator-fixed";
+   regulator-name = "vdd-backlight";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 3 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PD7 */
+   enable-active-high;
+   };
+
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
@@ -169,6 +188,24 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   panel@0 {
+   compatible = "bananapi,s070wv20-ct16-icn6211";
+   reg = <0>;
+   reset-gpios = < 3 6 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD6 */
+   vdd-supply = <_dldo1>;
+   backlight = <>;
+   };
+};
+
  {
status = "okay";
 };
@@ -261,6 +298,12 @@
status = "okay";
 };
 
+_pwm {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwm_pin>;
+   status = "okay";
+};
+
 _rsb {
status = "okay";
 
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 10/23] drm/sun4i: tcon: Compute DCLK dividers based on format, lanes

[Jagan Teki]

TCON dotclock compute the desired DCLK register divider based on panel
pixel clock along with input DCLK or DSI clock dividers from tcon driver.

The current code allowing an input DCLK dividers ranging from 4 to 127,
but the existing dclock logic is unable to compute the desired output
DCLK divider value for new panels instead it ended-up producing unknown
divider values which no longer exists.

So, add the computation logic 'format/lanes' to dclk min and max dividers
and indeed it produced the desired DCLK divider even for the new panels.

This computation logic align with Allwinner A64 BSP, hoping that would work
even for A33.

Tested this on 3 different panels, and below are the desired divider values
with respect to pixel clock frequency.

- 55MHz pixel clock with 4-lane panel, and the desired DSI clock divider
  is 6 with the output parent clock rate of 330MHz.
- 30MHz pixel clock with 4-lane panel, and the desired DSI clock divider
  is 6 with parent clock rate of 180MHz.
- 27.5Mhz pixel clock with 2-lane pane, and the desired DSI clock divider
  is 12 with the output parent clock rate of 330MHz.

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 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 3da75a0c5c5d..4d5a158d9a25 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -342,8 +342,8 @@ static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon 
*tcon,
u32 block_space, start_delay;
u32 tcon_div;
 
-   tcon->dclk_min_div = 4;
-   tcon->dclk_max_div = 127;
+   tcon->dclk_min_div = bpp / lanes;
+   tcon->dclk_max_div = bpp / lanes;
 
sun4i_tcon0_mode_set_common(tcon, mode);
 
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 01/23] drm/sun4i: sun6i_mipi_dsi: Compute burst mode loop N1 instruction delay

[Jagan Teki]

Loop N1 instruction delay varies between burst and non-burst video modes.

1) for burst mode panels it is computed based on the panel pixel clock
   along with horizontal sync and porch timings.
2) for non-burst mode panels, it is same as existing (50 - 1)

Reference code is available in BSP (from linux-sunxi
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)

dsi_dev[sel]->dsi_inst_loop_num.bits.loop_n1=
(panel->lcd_ht-panel->lcd_x)*(150)/(panel->lcd_dclk_freq*8) - 50;
=> (((mode->htotal - mode->hdisplay) * 150) /
 ((mode->clock / 1000) * 8)) - 50;

This patch add loop N1 computation for burst mode by simplifying
existing code to support all possible modes.

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index e3b34a345546..a5fcee750bee 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -354,6 +354,24 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
 SUN6I_DSI_INST_JUMP_CFG_NUM(1));
 };
 
+static u16 sun6i_dsi_setup_inst_delay(struct sun6i_dsi *dsi,
+ struct drm_display_mode *mode)
+{
+   struct mipi_dsi_device *device = dsi->device;
+   u32 hsync_porch, dclk;
+   u16 delay;
+
+   hsync_porch = (mode->htotal - mode->hdisplay);
+   dclk = (mode->clock / 1000);
+
+   if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
+   delay = ((hsync_porch * 150) / (dclk * 8)) - 50;
+   else
+   delay = 50 - 1;
+
+   return delay;
+}
+
 static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
   struct drm_display_mode *mode)
 {
@@ -383,7 +401,7 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
 static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi,
  struct drm_display_mode *mode)
 {
-   u16 delay = 50 - 1;
+   u16 delay = sun6i_dsi_setup_inst_delay(dsi, mode);
 
regmap_write(dsi->regs, SUN6I_DSI_INST_LOOP_NUM_REG(0),
 SUN6I_DSI_INST_LOOP_NUM_N0(50 - 1) |
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 05/23] drm/sun4i: tcon: Export get tcon0 routine

[Jagan Teki]

Sometimes tcon attributes like tcon divider, clock rate etc are needed
in interface drivers like DSI. So for such cases interface driver must
probe the respective tcon and get the attributes.

Since tcon0 probe is already available, via sun4i_get_tcon0 function,
export the same instead of probing tcon explicitly.

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 ++-
 drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 0420f5c978b9..3da75a0c5c5d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -221,7 +221,7 @@ EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
  * are located in TCON0. This helper returns a pointer to TCON0's
  * sun4i_tcon structure, or NULL if not found.
  */
-static struct sun4i_tcon *sun4i_get_tcon0(struct drm_device *drm)
+struct sun4i_tcon *sun4i_get_tcon0(struct drm_device *drm)
 {
struct sun4i_drv *drv = drm->dev_private;
struct sun4i_tcon *tcon;
@@ -235,6 +235,7 @@ static struct sun4i_tcon *sun4i_get_tcon0(struct drm_device 
*drm)
 
return NULL;
 }
+EXPORT_SYMBOL(sun4i_get_tcon0);
 
 void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
const struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index b5214d71610f..a52696db14a5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -274,6 +274,7 @@ struct sun4i_tcon {
 struct drm_bridge *sun4i_tcon_find_bridge(struct device_node *node);
 struct drm_panel *sun4i_tcon_find_panel(struct device_node *node);
 
+struct sun4i_tcon *sun4i_get_tcon0(struct drm_device *drm);
 void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, bool enable);
 void sun4i_tcon_mode_set(struct sun4i_tcon *tcon,
 const struct drm_encoder *encoder,
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 03/23] drm/sun4i: sun6i_mipi_dsi: Setup burst mode timings

[Jagan Teki]

Burst mode display timings are different from conventional video mode.

For burst mode most of the timings hsa, hbp, hfp, vblk are 0 and hblk
is computed as (mode->hdisplay * Bpp)

This patch simply add burst mode timings without touching existing mode
timings.

Reference code taken from BSP (from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)

dsi_hsa  = 0;
dsi_hbp  = 0;
dsi_hact = x*dsi_pixel_bits[format]/8;
dsi_hblk = dsi_hact;
dsi_hfp  = 0;
dsi_vblk = 0;

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 813d5523f1c7..0f02bcc997a5 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -477,6 +477,12 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
 
/* Do all timing calculations up front to allocate buffer space */
 
+   if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
+   hbp = hfp = hsa = vblk = 0;
+   hblk = (mode->hdisplay * Bpp);
+   goto alloc_buf;
+   }
+
/*
 * A sync period is composed of a blanking packet (4 bytes +
 * payload + 2 bytes) and a sync event packet (4 bytes). Its
@@ -515,6 +521,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
 */
vblk = 0;
 
+alloc_buf:
/* How many bytes do we need to send all payloads? */
bytes = max_t(size_t, max(max(hfp, hblk), max(hsa, hbp)), vblk);
buffer = kmalloc(bytes, GFP_KERNEL);
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 00/23] drm/sun4i: Allwinner A64 MIPI-DSI support

[Jagan Teki]

Here is next version changes for Allwinner A64 MIPI-DSI support

This series grouped the changes like previous version[1] with different
sets to support three different panels types that can fit into the DSI
controller.

set:1, for 4-lane, burst mode support
- patch 0001: 0009, DSI controller changes that support burst mode.

set:2, for A64 DSI support
- patch 0010: tcon dclk divider computation based on A64 BSP. 
- patch 0011: 0017, Allwinner A64 DSI controller changes.

set:3, enable 4-lane burst mode panel:
- patch 0018: Overlay patch that enable Feiyang FY07024DI26A30-D
  burst mode panel on Pine64-LTS

set:4, enable 4-lane video mode panel:
- patch 0019: msg type MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM support
- patch 0020: Overlay patch that enable Bananapi S070WV20-CT16 ICN6211 
  panel on Bananapi M64

set:5, enable 2-lane video mode panel:
- patch 0021, 0022: DSI hfp and hbp timings fixes
- patch 0023: Enable Techstar TS8550B panel on Amarula A64-Relic

Changes for v7:
- moved vcc-dsi binding to required filed.
- drop quotes on fallback dphy bindings.
- drop min_rate clock pll-mipi patches.
- introduce dclk divider computation as like A64 BSP.
- add A64 DSI quark patches.
- fixed A64 DSI pipeline.
- add proper commit messages.
- collect Merlijn Wajer Tested-by credits.
Changes for v6:
- dropped unneeded changes, patches
- fixed all burst mode patches as per previous version comments
- rebase on master
- update proper commit message
- dropped unneeded comments
- order the patches that make review easy
Changes for v5:
- collect Rob, Acked-by
- droped "Fix VBP size calculation" patch
- updated vblk timing calculation.
- droped techstar, bananapi dsi panel drivers which may require
  bridge or other setup. it's under discussion.
Changes for v4:
- droppoed untested CCU_FEATURE_FIXED_POSTDIV check code in
  nkm min, max rate patches
- create two patches for "Add Allwinner A64 MIPI DSI support"
  one for has_mod_clk quirk and other one for A64 support
- use existing driver code construct for hblk computation
- dropped "Increase hfp packet overhead" patch [2], though BSP added
  this but we have no issues as of now.
  (no issues on panel side w/o this change)
- create separate function for vblk computation 
- enable vcc-dsi regulator in dsi_runtime_resume
- collect Rob, Acked-by
- update MAINTAINERS file for panel drivers
- cleanup commit messages
- fixed checkpatch warnings/errors

[1] https://patchwork.kernel.org/cover/10779893/

Any inputs?
Jagan.

Jagan Teki (23):
  drm/sun4i: sun6i_mipi_dsi: Compute burst mode loop N1 instruction
delay
  drm/sun4i: sun6i_mipi_dsi: Support instruction loop selection
  drm/sun4i: sun6i_mipi_dsi: Setup burst mode timings
  drm/sun4i: sun6i_mipi_dsi: Simplify drq to support all modes
  drm/sun4i: tcon: Export get tcon0 routine
  drm/sun4i: sun6i_mipi_dsi: Probe tcon0 during dsi_bind
  drm/sun4i: sun6i_mipi_dsi: Setup burst mode
  drm/sun4i: sun6i_mipi_dsi: Enable trail_inv and trail_fill controls
  drm/sun4i: sun6i_mipi_dsi: Enable HBP, HSA_HSE for burst mode
  drm/sun4i: tcon: Compute DCLK dividers based on format, lanes
  dt-bindings: sun6i-dsi: Add VCC-DSI supply property
  drm/sun4i: sun6i_mipi_dsi: Add support for VCC-DSI voltage regulator
  dt-bindings: sun6i-dsi: Add A64 MIPI-DSI compatible
  dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback)
  drm/sun4i: sun6i_mipi_dsi: Add has_mod_clk quirk
  drm/sun4i: sun6i_mipi_dsi: Add Allwinner A64 MIPI DSI support
  arm64: dts: allwinner: a64: Add MIPI DSI pipeline
  [DO NOT MERGE] arm64: allwinner: a64: pine64-lts: Enable Feiyang 
FY07024DI26A30-D DSI
panel
  drm/sun4i: sun6i_mipi_dsi: Add DSI Generic short write 2 param
transfer
  [DO NOT MERGE] arm64: dts: allwinner: bananapi-m64: Bananapi S070WV20-CT16 
DSI panel
  drm/sun4i: sun6i_mipi_dsi: Fix DSI hbp timing value
  drm/sun4i: sun6i_mipi_dsi: Fix DSI hfp timing value
  arm64: dts: allwinner: a64-amarula-relic: Add Techstar TS8550B
MIPI-DSI panel

 .../bindings/display/sunxi/sun6i-dsi.txt  |   3 +
 .../allwinner/sun50i-a64-amarula-relic.dts|  39 
 .../dts/allwinner/sun50i-a64-bananapi-m64.dts |  43 
 .../dts/allwinner/sun50i-a64-pine64-lts.dts   |  39 
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  45 
 drivers/gpu/drm/sun4i/sun4i_tcon.c|   7 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.h|   1 +
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 210 +++---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h|   9 +
 9 files changed, 367 insertions(+), 29 deletions(-)

-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 13/23] dt-bindings: sun6i-dsi: Add A64 MIPI-DSI compatible

[Jagan Teki]

The MIPI DSI controller in Allwinner A64 is similar to A33.

But unlike A33, A64 doesn't have DSI_SCLK gating so it is valid
to with separate compatible for A64 on the same driver.

Signed-off-by: Jagan Teki 
Reviewed-by: Rob Herring 
Tested-by: Merlijn Wajer 
---
 Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
index 1cc40663b7a2..9877398be69a 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
@@ -12,6 +12,7 @@ The DSI Encoder generates the DSI signal from the TCON's.
 Required properties:
   - compatible: value must be one of:
 * allwinner,sun6i-a31-mipi-dsi
+* allwinner,sun50i-a64-mipi-dsi
   - reg: base address and size of memory-mapped region
   - interrupts: interrupt associated to this IP
   - clocks: phandles to the clocks feeding the DSI encoder
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 23/23] arm64: dts: allwinner: a64-amarula-relic: Add Techstar TS8550B MIPI-DSI panel

[Jagan Teki]

Amarula A64-Relic board by default bound with Techstar TS8550B
MIPI-DSI panel, add support for it.

DSI panel connected via board DSI port with,
- DLDO2 as VCC supply
- DLDO2 as IOVCC supply
- DLDO1 as VCC-DSI supply
- PD24 gpio for reset pin
- PD23 gpio for backlight enable pin

Signed-off-by: Jagan Teki 
---
 .../allwinner/sun50i-a64-amarula-relic.dts| 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
index df0de0772d6b..a5a0a650b589 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -9,6 +9,7 @@
 #include "sun50i-a64.dtsi"
 
 #include 
+#include 
 
 / {
model = "Amarula A64-Relic";
@@ -18,6 +19,14 @@
serial0 = 
};
 
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 5 PWM_POLARITY_INVERTED>;
+   brightness-levels = <1 2 4 8 16 32 64 128 512>;
+   default-brightness-level = <2>;
+   enable-gpios = < 3 23 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PD23 
*/
+   };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -83,6 +92,30 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   vcc-dsi-supply = <_dldo1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   panel@0 {
+   compatible = "techstar,ts8550b", "sitronix,st7701";
+   reg = <0>;
+   VCC-supply = <_dldo2>;
+   IOVCC-supply = <_dldo2>;
+   reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+   backlight = <>;
+   };
+};
+
  {
status = "okay";
 };
@@ -160,6 +193,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin>;
+   status = "okay";
+};
+
 _rsb {
status = "okay";
 
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 08/23] drm/sun4i: sun6i_mipi_dsi: Enable trail_inv and trail_fill controls

[Jagan Teki]

The burst mode panels with 4-lane would require to enable trail bits
in DSI basic control register.

So, enable 2byte trail and trail_env for 4-lane burst mode devices.

Allwinner A64 BSP should also relie on same setup for enabling trail
bit in DSI controller.

Reference code avialable in BSP (from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)

if (panel->lcd_dsi_lane == 4)
{
   dsi_dev[sel]->dsi_basic_ctl.bits.trail_inv = 0xc;
   dsi_dev[sel]->dsi_basic_ctl.bits.trail_fill = 1;
}

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 46ad142e66e8..a2ad9fa7f8d5 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -33,6 +33,8 @@
 #define SUN6I_DSI_CTL_EN   BIT(0)
 
 #define SUN6I_DSI_BASIC_CTL_REG0x00c
+#define SUN6I_DSI_BASIC_CTL_TRAIL_INV(n)   (((n) & 0xf) << 4)
+#define SUN6I_DSI_BASIC_CTL_TRAIL_FILL BIT(3)
 #define SUN6I_DSI_BASIC_CTL_HBP_DISBIT(2)
 #define SUN6I_DSI_BASIC_CTL_HSA_HSE_DISBIT(1)
 #define SUN6I_DSI_BASIC_CTL_VIDEO_BURSTBIT(0)
@@ -464,6 +466,10 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
/* enable burst mode */
regmap_read(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, );
val |= SUN6I_DSI_BASIC_CTL_VIDEO_BURST;
+   if (device->lanes == 4) {
+   val |= SUN6I_DSI_BASIC_CTL_TRAIL_INV(0xc);
+   val |= SUN6I_DSI_BASIC_CTL_TRAIL_FILL;
+   }
regmap_write(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, val);
 }
 
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 06/23] drm/sun4i: sun6i_mipi_dsi: Probe tcon0 during dsi_bind

[Jagan Teki]

Probe tcon0 during dsi_bind, so-that the tcon attributes like
divider value, clock rate can get whenever it need.

Signed-off-by: Jagan Teki 
Tested-by: Merlijn Wajer 
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 +++
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 16a86d35dc5a..2aeaa19a8d1e 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -24,6 +24,7 @@
 #include 
 
 #include "sun4i_drv.h"
+#include "sun4i_tcon.h"
 #include "sun6i_mipi_dsi.h"
 
 #include 
@@ -947,6 +948,7 @@ static int sun6i_dsi_bind(struct device *dev, struct device 
*master,
struct drm_device *drm = data;
struct sun4i_drv *drv = drm->dev_private;
struct sun6i_dsi *dsi = dev_get_drvdata(dev);
+   struct sun4i_tcon *tcon0 = sun4i_get_tcon0(drm);
int ret;
 
if (!dsi->panel)
@@ -954,6 +956,11 @@ static int sun6i_dsi_bind(struct device *dev, struct 
device *master,
 
dsi->drv = drv;
 
+   if (!tcon0)
+   return -EINVAL;
+
+   dsi->tcon = tcon0;
+
drm_encoder_helper_add(>encoder,
   _dsi_enc_helper_funcs);
ret = drm_encoder_init(drm,
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
index dbbc5b3ecbda..257cca660da0 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
@@ -33,6 +33,7 @@ struct sun6i_dsi {
 
struct device   *dev;
struct sun4i_drv*drv;
+   struct sun4i_tcon   *tcon;
struct mipi_dsi_device  *device;
struct drm_panel*panel;
 };
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v7 14/23] dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback)

[Jagan Teki]

The MIPI DSI PHY controller on Allwinner A64 is similar
on the one on A31.

Add A64 compatible and append A31 compatible as fallback.

Signed-off-by: Jagan Teki 
Reviewed-by: Rob Herring 
Tested-by: Merlijn Wajer 
---
 Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
index 9877398be69a..d0ce51fea103 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
@@ -38,6 +38,7 @@ D-PHY
 Required properties:
   - compatible: value must be one of:
 * allwinner,sun6i-a31-mipi-dphy
+* allwinner,sun50i-a64-mipi-dphy, allwinner,sun6i-a31-mipi-dphy
   - reg: base address and size of memory-mapped region
   - clocks: phandles to the clocks feeding the DSI encoder
 * bus: the DSI interface clock
-- 
2.18.0.321.gffc6fa0e3

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

[Bug 108824] Invalid handling when GL buffer is bound on one context and invalidated on another

[bugzilla-daemon]

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

--- Comment #2 from olivier.jo...@laposte.net ---
I also encounter what is most probably this same bug (same assertion at least)
in a randomly fashion when using Blender 2.80.

My setup is debian unstable with a Radeon HD 7950 (and also GeForce GTX 1060
for Cuda only).

I encountered this crash on mesa 18.3.2 (packaged in debian), 18.3.3 and
19.0.0-rc1 (compiled manually)

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

[Bug 108824] Invalid handling when GL buffer is bound on one context and invalidated on another

[bugzilla-daemon]

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

--- Comment #1 from olivier.jo...@laposte.net ---
Created attachment 143269
  --> https://bugs.freedesktop.org/attachment.cgi?id=143269=edit
backtrace of crash when hitting this assert (from 18.3.3/19.0.0-rc1)

-- 
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 2/5] dt-bindings: display: renesas: lvds: Document r8a7744 bindings

[Laurent Pinchart]

Hi Rob,

On Wed, Jan 30, 2019 at 10:39:10AM -0600, Rob Herring wrote:
> On Tue, Jan 22, 2019 at 05:44:28PM +0200, Laurent Pinchart wrote:
> > On Tue, Jan 22, 2019 at 03:25:46PM +, Biju Das wrote:
> >> Document the RZ/G1N (R8A7744) LVDS bindings.
> >> 
> >> Signed-off-by: Biju Das 
> > 
> > Reviewed-by: Laurent Pinchart 
> > 
> > and taken in my tree.
> 
> But not in linux-next? Or you did some $subject fixups which breaks my 
> detecting that. :(

My tree isn't part of linux-next. I'll send a pull reques to Dave very
soon.

-- 
Regards,

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

[PULL] drm-misc-next

[Maxime Ripard]

Hi Dave, Daniel,

Here is the drm-misc-next PR for this week.

Thanks!
Maxime

drm-misc-next-2019-02-01:
drm-misc-next for 5.1:

UAPI Changes:

Cross-subsystem Changes:

Core Changes:
  - Split out some part of drm_crtc_helper.h into drm_probe_helper.h
  - DRIVER_* flags improvements
  - New tasks on the TODO-list
  - Improvements to the documentation

Driver Changes:
  - Continual of drmP.h removal in multiple drivers
  - Removal of FBINFO_(FLAG_)DEFAULT in multiple drivers
  - sun4i: Addition of the A23 support, multiple fixes for the tiled
formats
  - atmel-hlcdc: Fix of clipping and rotation properties
  - qxl: various BO-related improvements, prime and generic fbdev emulation
support
  - dw-hdmi: Support for HDMI2.0 2160p modes and YUV420 output
  - New Sitronix ST7701 panel driver
  - New Kingdisplay KD097D04 panel driver
  - New LeMaker BL035-RGB-002 panel driver
  - New PDA 91-00156-A0 panel driver
The following changes since commit 8ca4fd0406b41a872055048d694f3702d8eddb76:

  Merge tag 'drm-intel-next-2019-01-10' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2019-01-24 19:44:16 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-02-01

for you to fetch changes up to ba9877e2361c46cae3841181aea61e55fc2309b9:

  drm/bridge: dw-hdmi: add support for YUV420 output (2019-02-01 13:15:10 +0100)


drm-misc-next for 5.1:

UAPI Changes:

Cross-subsystem Changes:

Core Changes:
  - Split out some part of drm_crtc_helper.h into drm_probe_helper.h
  - DRIVER_* flags improvements
  - New tasks on the TODO-list
  - Improvements to the documentation

Driver Changes:
  - Continual of drmP.h removal in multiple drivers
  - Removal of FBINFO_(FLAG_)DEFAULT in multiple drivers
  - sun4i: Addition of the A23 support, multiple fixes for the tiled
formats
  - atmel-hlcdc: Fix of clipping and rotation properties
  - qxl: various BO-related improvements, prime and generic fbdev emulation
support
  - dw-hdmi: Support for HDMI2.0 2160p modes and YUV420 output
  - New Sitronix ST7701 panel driver
  - New Kingdisplay KD097D04 panel driver
  - New LeMaker BL035-RGB-002 panel driver
  - New PDA 91-00156-A0 panel driver


Chen-Yu Tsai (5):
  dt-bindings: display: sun4i-drm: Add compatible strings for A23 display
  drm/sun4i: backend: Remove BGRX from list of supported formats
  drm/sun4i: layer: Assign backend pointer before calling DRM helpers
  drm/sun4i: layer: support just backend formats when frontend is 
unavailable
  drm/sun4i: Add support for A23 display pipeline

Cristian Birsan (1):
  dt-bindings: display: Add support for PDA 91-00156-A0 panel

Damian Kos (1):
  drm/rockchip: fix for mailbox read validation.

Daniel Vetter (10):
  drm: Split out drm_probe_helper.h
  drm/doc: Add a warning to drm_dev_is_unplugged
  drm/: Don't set FBINFO_(FLAG_)DEFAULT
  drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install
  drm: Switch DRIVER_ flags to an enum
  drm/irq: Ditch DRIVER_IRQ_SHARED
  drm/doc: fix VRR_ENABLED casing
  drm/doc: Task to rename CMA helpers
  drm/doc: Move hdmi infoframe docs
  drm/doc: Drop chapter "KMS Initialization and Cleanup"

Eugen Hristev (2):
  dt-bindings: Add vendor prefix for PDA Precision Design Associates, Inc.
  drm/panel: simple: Add support for PDA 91-00156-A0 panel

Frediano Ziglio (1):
  drm/qxl: change the way slot is detected

Gerd Hoffmann (22):
  drm/qxl: drop ttm_mem_reg arg from qxl_hw_surface_alloc()
  drm/qxl: drop unused qxl_fb_virtual_address
  drm/qxl: simplify slot management
  drm/qxl: drop unused fields from struct qxl_device
  drm/qxl: use separate offset spaces for the two slots / ttm memory types.
  drm/qxl: allow both PRIV and VRAM placement for QXL_GEM_DOMAIN_SURFACE
  drm/qxl: use QXL_GEM_DOMAIN_SURFACE for shadow bo.
  drm/qxl: use QXL_GEM_DOMAIN_SURFACE for dumb gem objects
  drm/qxl: move qxl_primary_apply_cursor to correct place
  drm/qxl: drop unused offset parameter from qxl_io_create_primary()
  drm/qxl: track primary bo
  drm/qxl: use shadow bo directly
  drm/qxl: cover all crtcs in shadow bo.
  drm/qxl: use qxl_num_crtc directly
  drm/qxl: implement prime kmap/kunmap
  drm/qxl: use generic fbdev emulation
  drm/qxl: remove dead qxl fbdev emulation code
  drm/qxl: implement qxl_gem_prime_(un)pin
  drm/qxl: add mode/framebuffer check functions
  drm/qxl: add qxl_add_mode helper function
  drm/qxl: use kernel mode db
  drm/qxl: use ttm_tt

Gustavo A. R. Silva (2):
  drm/via: mark expected switch fall-throughs
  drm/savage: mark expected switch fall-throughs

Heiko Stuebner (1):
  drm/rockchip: check yuv2yuv existence before assigning window data

Re: [Nouveau] [PATCH -next] drm/nouveau: fix copy-paste error in nouveau_fence_wait_uevent_handler

[Pierre Moreau]

Friendly ping, Ben.
I see that in `nouveau_fence_done()` there is a check on `chan` not being NULL
prior to passing it to `nouveau_fence_update()`. Would something similar be
needed here?

Pierre

On 2018-11-15 — 12:14, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/gpu/drm/nouveau/nouveau_fence.c: In function 
> 'nouveau_fence_wait_uevent_handler':
> drivers/gpu/drm/nouveau/nouveau_fence.c:156:27: warning:
>  variable 'chan' set but not used [-Wunused-but-set-variable]
> 
> nouveau_fence_update should use rcu protected 'chan'
> rather than 'fence->channel'
> 
> Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and 
> protect with rcu")
> Signed-off-by: YueHaibing 
> ---
>  drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
> b/drivers/gpu/drm/nouveau/nouveau_fence.c
> index d4964f3..91286d0 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
> @@ -157,7 +157,7 @@
>  
>   fence = list_entry(fctx->pending.next, typeof(*fence), head);
>   chan = rcu_dereference_protected(fence->channel, 
> lockdep_is_held(>lock));
> - if (nouveau_fence_update(fence->channel, fctx))
> + if (nouveau_fence_update(chan, fctx))
>   ret = NVIF_NOTIFY_DROP;
>   }
>   spin_unlock_irqrestore(>lock, flags);
> 
> 
> 
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI

[Maxime Ripard]

On Tue, Jan 29, 2019 at 11:01:31PM +0530, Jagan Teki wrote:
> On Tue, Jan 29, 2019 at 8:43 PM Maxime Ripard  
> wrote:
> >
> > On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote:
> > > On Sat, Jan 26, 2019 at 2:54 AM Maxime Ripard  
> > > wrote:
> > > >
> > > > On Fri, Jan 25, 2019 at 01:28:49AM +0530, Jagan Teki wrote:
> > > > > Minimum PLL used for MIPI is 500MHz, as per manual, but
> > > > > lowering the min rate by 300MHz can result proper working
> > > > > nkms divider with the help of desired dclock rate from
> > > > > panel driver.
> > > > >
> > > > > Signed-off-by: Jagan Teki 
> > > > > Acked-by: Stephen Boyd 
> > > >
> > > > Going 200MHz below the minimum doesn't seem really reasonable. What
> > > > is the issue that you are trying to fix here?
> > > >
> > > > It looks like it's picking bad dividers, but if that's the case, this
> > > > isn't the proper fix.
> > >
> > > As I stated in earlier patches, the whole idea is pick the desired
> > > dclk divider based dclk rate. So the dotclock, sun4i_dclk_round_rate
> > > is unable to get the proper dclk divider at the end, so it eventually
> > > picking up wrong divider value and fired vblank timeout.
> > >
> > > So, we come-up with optimal and working min_rate 300MHz in pll-mipi to
> > > get the desired clock something like below.
> > > [2.415773] [drm] No driver support for vblank timestamp query.
> > > [2.424116] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = 
> > > 5500
> > > [2.424172] ideal = 22000, rounded = 0
> > > [2.424176] ideal = 27500, rounded = 0
> > > [2.424194] ccu_nkm_round_rate: rate = 33000
> > > [2.424197] ideal = 33000, rounded = 33000
> > > [2.424201] sun4i_dclk_round_rate: div = 6 rate = 5500
> > > [2.424205] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = 
> > > 5500
> > > [2.424209] ideal = 22000, rounded = 0
> > > [2.424213] ideal = 27500, rounded = 0
> > > [2.424230] ccu_nkm_round_rate: rate = 33000
> > > [2.424233] ideal = 33000, rounded = 33000
> > > [2.424236] sun4i_dclk_round_rate: div = 6 rate = 5500
> > > [2.424253] ccu_nkm_round_rate: rate = 33000
> > > [2.424270] ccu_nkm_round_rate: rate = 33000
> > > [2.424278] sun4i_dclk_recalc_rate: val = 1, rate = 33000
> > > [2.424281] sun4i_dclk_recalc_rate: val = 1, rate = 33000
> > > [2.424306] ccu_nkm_set_rate: rate = 33000, parent_rate = 29700
> > > [2.424309] ccu_nkm_set_rate: _nkm.n = 5
> > > [2.424311] ccu_nkm_set_rate: _nkm.k = 2
> > > [2.424313] ccu_nkm_set_rate: _nkm.m = 9
> > > [2.424661] sun4i_dclk_set_rate div 6
> > > [2.424668] sun4i_dclk_recalc_rate: val = 6, rate = 5500
> > >
> > > But look like this wouldn't valid for all other dclock rates, say BPI
> > > panel has 30MHz clock that would failed with this logic.
> > >
> > > On the other side Allwinner BSP calculating dclk divider based on the
> > > SoC's. for A33 [1] it is fixed dclk divider of 4 and for A64 is is
> > > calculated based on the bpp/lanes.
> >
> > It looks like the A64 has the same divider of 4:
> > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L12
> >
> > I think you're confusing it with the ratio between the pixel clock and
> > the dotclock, called dsi_div:
> > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L198
> 
> Ahh.. I thought this initially but as far as DSI clock computation is
> concern, the L12 tcon_div is local variable which is used for edge0
> computation in burst mode and not for the dsi clock computation. Since
> the BSP is unable to get the tcon_div during edge0 computation, they
> defined it locally I think.
> 
> You can see the lcd_clk_config() code [2], where we can see DSI clock
> computation using dsi_div value.
> 
> Here is dump after the in Line 792 which is after computation[3]
> [   10.800737] lcd_clk_config: dsi_div = 6, tcon_div = 4, lcd_div = 1
> [   10.800743] lcd_clk_config: lcd_dclk_freq = 55, dclk_rate = 5500
> [   10.800749] lcd_clk_config: lcd_rate = 33000, pll_rate = 33000
> 
> The above dump the lcd_rate 330MHz is computed with panel clock, 55MHz
> into dsi_div 6. So this can be our actual divider values dclk_min_div,
> dclk_max_div in sun4i_dclk_round_rate (from
> drivers/gpu/drm/sun4i/sun4i_dotclock.c)

I wish it was in your commit log in the first place, instead of having
to exchange multiple mails over this.

However, I don't think that's quite true, and it might be a bug in
Allwinner's implementation (or rather something quite confusing).

You're right that the lcd_rate and pll_rate seem to be generated from
the pixel clock, and it indeed looks like the ratio between the pixel
clock and the TCON dotclock is defined through the number of bits per
lanes.

However, in this case, 

Re: [PATCH] host1x: cdma: use completion instead of semaphore

[Thierry Reding]

On Mon, Dec 10, 2018 at 10:51:04PM +0100, Arnd Bergmann wrote:
> In this usage, the two are completely equivalent, but the
> completion documents better what is going on, and we generally
> try to avoid semaphores these days.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/host1x/cdma.c | 6 +++---
>  drivers/gpu/host1x/cdma.h | 4 ++--
>  2 files changed, 5 insertions(+), 5 deletions(-)

Applied, thanks.

Thierry


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

Re: [PATCH libdrm 1/2] xf86drm: fallback to MODALIAS for OF less platform devices

[Lucas Stach]

Hi Emil,

Am Donnerstag, den 24.01.2019, 14:42 + schrieb Emil Velikov:
> > On Wed, 23 Jan 2019 at 11:26, Emil Velikov  wrote:
> > 
> > On Wed, 23 Jan 2019 at 11:04, Eric Engestrom  
> > wrote:
> > > 
> > > On Wednesday, 2019-01-23 10:45:17 +, Emil Velikov wrote:
> > > > > > > > From: Emil Velikov 
> > > > 
> > > > Some devices can lack OF data or it may not be available in the uevent
> > > > file. Fallback to the MODALIAS data in those cases.
> > > > 
> > > > We strip any leading "MODALIAS=.*:" thus the resulting information is
> > > > compatible with existing code in Mesa.
> > > > 
> > > > > > > > Signed-off-by: Emil Velikov 
> > > > ---
> > > >  xf86drm.c | 55 ++-
> > > >  1 file changed, 42 insertions(+), 13 deletions(-)
> > > > 
> > > > diff --git a/xf86drm.c b/xf86drm.c
> > > > index 10df682b..374734eb 100644
> > > > --- a/xf86drm.c
> > > > +++ b/xf86drm.c
> > > > @@ -3511,15 +3511,28 @@ free_device:
> > > >  static int drmParsePlatformBusInfo(int maj, int min, 
> > > > drmPlatformBusInfoPtr info)
> > > >  {
> > > >  #ifdef __linux__
> > > > -char path[PATH_MAX + 1], *name;
> > > > +char path[PATH_MAX + 1], *name, *foo;
> > > 
> > > I assume you didn't mean to send this patch yet? :P
> > > 
> > 
> > Thanks Eric, I intentionally sent it out. Mind was blank thinking for
> > a reasonable variable name :-\
> > Suggestions are more than welcome.
> > 
> > For reference with this patch drmdevice and other drmDevice API users list:
> >  - VGEM, needs "drm/vgem: Fix vgem_init to get drm device available."
> > - in v5.0 only :'-(
> >  - etnaviv, after "drm/etnaviv: remove the need for a gpu-subsystem DT
> > node" landed in v4.17/18
> > 
> 
> Christian can you please test that this patches brings etnaviv back to the 
> list?
> Above is a reasonable assumption, yet assumption never the less.

I can confirm that with this patch applied
loader_open_render_node("etnaviv") works as intended.

Regards,
Lucas

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

Re: [PATCH v2 2/3] dt-bindings: phy: Add documentation for mixel dphy

[Sam Ravnborg]

Hi Guido

On Fri, Feb 01, 2019 at 09:49:54AM +0100, Guido Günther wrote:
> Add support for the MIXEL DPHY IP as found in the NXP's i.MX8MQ.
> 
> Signed-off-by: Guido Günther 
> ---
>  .../bindings/phy/mixel,mipi-dsi-phy.txt   | 29 +++
>  1 file changed, 29 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt 
> b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
> new file mode 100644
> index ..10323ae8ee37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
> @@ -0,0 +1,29 @@
> +Mixel DSI PHY for i.MX8
> +
> +The Mixel MIPI-DSI PHY IP block is e.g. found on MX8 platforms (along
MX8 => i.MX8 ?

Other than this nit:
Reviewed-by: Sam Ravnborg 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 08/16] gpu: host1x: Use correct semantics for HOST1X_CHANNEL_DMAEND

[Thierry Reding]

On Fri, Feb 01, 2019 at 04:48:56PM +0300, Dmitry Osipenko wrote:
> 01.02.2019 16:41, Thierry Reding пишет:
> > On Fri, Feb 01, 2019 at 04:37:59PM +0300, Dmitry Osipenko wrote:
> >> 01.02.2019 16:28, Thierry Reding пишет:
> >>> From: Thierry Reding 
> >>>
> >>> The HOST1X_CHANNEL_DMAEND is an offset relative to the value written to
> >>> the HOST1X_CHANNEL_DMASTART register, but it is currently treated as an
> >>> absolute address. This can cause SMMU faults if the CDMA fetches past a
> >>> pushbuffer's IOMMU mapping.
> >>>
> >>> Properly setting the DMAEND prevents the CDMA from fetching beyond that
> >>> address and avoid such issues. This is currently not observed because a
> >>> whole (almost) page of essentially scratch space absorbs any excessive
> >>> prefetching by CDMA. However, changing the number of slots in the push
> >>> buffer can trigger these SMMU faults.
> >>>
> >>> Signed-off-by: Thierry Reding 
> >>> ---
> >>>  drivers/gpu/host1x/hw/cdma_hw.c | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/host1x/hw/cdma_hw.c 
> >>> b/drivers/gpu/host1x/hw/cdma_hw.c
> >>> index 485aef5761af..a24c090ac96f 100644
> >>> --- a/drivers/gpu/host1x/hw/cdma_hw.c
> >>> +++ b/drivers/gpu/host1x/hw/cdma_hw.c
> >>> @@ -75,7 +75,7 @@ static void cdma_start(struct host1x_cdma *cdma)
> >>>  
> >>>   cdma->last_pos = cdma->push_buffer.pos;
> >>>   start = cdma->push_buffer.dma;
> >>> - end = start + cdma->push_buffer.size + 4;
> >>> + end = cdma->push_buffer.size + 4;
> >>>  
> >>>   host1x_ch_writel(ch, HOST1X_CHANNEL_DMACTRL_DMASTOP,
> >>>HOST1X_CHANNEL_DMACTRL);
> >>> @@ -126,7 +126,7 @@ static void cdma_timeout_restart(struct host1x_cdma 
> >>> *cdma, u32 getptr)
> >>>HOST1X_CHANNEL_DMACTRL);
> >>>  
> >>>   start = cdma->push_buffer.dma;
> >>> - end = start + cdma->push_buffer.size + 4;
> >>> + end = cdma->push_buffer.size + 4;
> >>>  
> >>>   /* set base, end pointer (all of memory) */
> >>>   host1x_ch_writel(ch, lower_32_bits(start), HOST1X_CHANNEL_DMASTART);
> >>>
> >>
> >> This seems fixes problem that was added by a previous patch in this
> >> series, "gpu: host1x: Support 40-bit addressing". What about to just
> >> squash the patches? 
> > 
> > This actually fixes a bug that's always been there. This just happens to
> > touch the same lines as an earlier patch as a result of some refactoring
> > that the earlier patch did.
> 
> Oh, wow. Indeed! That's a bit unfortunate :) Though it's quite
> difficult to spot that bug by looking at the code, good that it got
> caught. Was this bug triggered by trying to move IOVA allocation to
> the end of the AS?

This was actually triggered because I noticed that we were using 512
slots in the push buffer, which means 4096 bytes, but then we needed
that extra 4 bytes for the RESTART opcode, which means that we're
currently allocating 8192 bytes of which only 4092 are being used.

So I thought: "Well, we should be able to live with 511 slots per push
buffer and save a full memory page. This is an easy optimization!" Boy
was I wrong... After making that change I started to see SMMU faults
for the address immediately after the push buffer mapping. I think the
same error happens regardless of where the push buffer is located. The
reason for the SMMU faults seem to be that CDMA happily keeps on pre-
fetching (a lot of) commands before it wraps around because of the
RESTART opcode. DMAEND is designed as a mechanism to prevent CDMA from
excessively fetching commands, but if you program a really large value
into it, it'll add that really large value to the DMASTART as offset
and the mechanism doesn't work anymore.

We don't currently see this because the 4092 bytes in the "scratch"
page of the push buffer allocation are enough to absorb the prefetching
that CDMA does.

We would also likely never see it happen in non-SMMU cases because the
CDMA would just keep on prefetching whatever memory happened to be after
the push buffer.

Thierry


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

Re: [PATCH 1/2] dt-bindings: display: tegra: Support SOR crossbar configuration

[Thierry Reding]

On Fri, Jan 25, 2019 at 11:00:57AM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The SOR has a crossbar that can map each lane of the SOR to each of the
> SOR pads. The mapping is usually the same across designs for a specific
> SoC generation, but every now and then there's a design that doesn't.
> 
> Allow the crossbar configuration to be specified in device tree to make
> it possible to support these designs.
> 
> Signed-off-by: Thierry Reding 
> ---
>  .../bindings/display/tegra/nvidia,tegra20-host1x.txt   | 3 +++
>  1 file changed, 3 insertions(+)

Hi Rob,

any comments on this?

Thanks,
Thierry

> diff --git 
> a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt 
> b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> index 593be44a53c9..255ac5b6 100644
> --- 
> a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> +++ 
> b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> @@ -238,6 +238,9 @@ of the following host1x client modules:
>- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
>- nvidia,edid: supplies a binary EDID blob
>- nvidia,panel: phandle of a display panel
> +  - nvidia,xbar-cfg: 5 cells containing the crossbar configuration. Each lane
> +of the SOR, identified by the cell's index, is mapped via the crossbar to
> +the pad specified by the cell's value.
>  
>Optional properties when driving an eDP output:
>- nvidia,dpaux: phandle to a DispayPort AUX interface
> -- 
> 2.19.1
> 


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

Re: [PATCH v3 08/16] gpu: host1x: Use correct semantics for HOST1X_CHANNEL_DMAEND

[Thierry Reding]

On Fri, Feb 01, 2019 at 04:37:59PM +0300, Dmitry Osipenko wrote:
> 01.02.2019 16:28, Thierry Reding пишет:
> > From: Thierry Reding 
> > 
> > The HOST1X_CHANNEL_DMAEND is an offset relative to the value written to
> > the HOST1X_CHANNEL_DMASTART register, but it is currently treated as an
> > absolute address. This can cause SMMU faults if the CDMA fetches past a
> > pushbuffer's IOMMU mapping.
> > 
> > Properly setting the DMAEND prevents the CDMA from fetching beyond that
> > address and avoid such issues. This is currently not observed because a
> > whole (almost) page of essentially scratch space absorbs any excessive
> > prefetching by CDMA. However, changing the number of slots in the push
> > buffer can trigger these SMMU faults.
> > 
> > Signed-off-by: Thierry Reding 
> > ---
> >  drivers/gpu/host1x/hw/cdma_hw.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/host1x/hw/cdma_hw.c 
> > b/drivers/gpu/host1x/hw/cdma_hw.c
> > index 485aef5761af..a24c090ac96f 100644
> > --- a/drivers/gpu/host1x/hw/cdma_hw.c
> > +++ b/drivers/gpu/host1x/hw/cdma_hw.c
> > @@ -75,7 +75,7 @@ static void cdma_start(struct host1x_cdma *cdma)
> >  
> > cdma->last_pos = cdma->push_buffer.pos;
> > start = cdma->push_buffer.dma;
> > -   end = start + cdma->push_buffer.size + 4;
> > +   end = cdma->push_buffer.size + 4;
> >  
> > host1x_ch_writel(ch, HOST1X_CHANNEL_DMACTRL_DMASTOP,
> >  HOST1X_CHANNEL_DMACTRL);
> > @@ -126,7 +126,7 @@ static void cdma_timeout_restart(struct host1x_cdma 
> > *cdma, u32 getptr)
> >  HOST1X_CHANNEL_DMACTRL);
> >  
> > start = cdma->push_buffer.dma;
> > -   end = start + cdma->push_buffer.size + 4;
> > +   end = cdma->push_buffer.size + 4;
> >  
> > /* set base, end pointer (all of memory) */
> > host1x_ch_writel(ch, lower_32_bits(start), HOST1X_CHANNEL_DMASTART);
> > 
> 
> This seems fixes problem that was added by a previous patch in this
> series, "gpu: host1x: Support 40-bit addressing". What about to just
> squash the patches? 

This actually fixes a bug that's always been there. This just happens to
touch the same lines as an earlier patch as a result of some refactoring
that the earlier patch did.

Thierry


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

Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV*

[Sam Ravnborg]

Hi Thierry.

> I'm slightly on the fence about this patch.

Please ignore patch 3-19, there is no consensus on the logging changes.
We do not want to apply these and then have to redo parts/all of
it later.

But the first two patches has not seen any feedback yet:

[PATCH v1 01/19] drm/panel: drop drmP.h usage
[PATCH v1 02/19] drm/panel: panel-innolux: drop unused variable

Please consider these, or maybe wait a little to see if someone
find time to review.

I can resend the patches if this is preferred.

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

[PATCH v3 07/16] gpu: host1x: Support 40-bit addressing on Tegra186

[Thierry Reding]

From: Thierry Reding 

The host1x and clients instantiated on Tegra186 support addressing 40
bits of memory.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 544b67f2b3ff..ee3c7b81a29d 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -136,7 +136,7 @@ static const struct host1x_info host1x06_info = {
.nb_bases = 16,
.init = host1x06_init,
.sync_offset = 0x0,
-   .dma_mask = DMA_BIT_MASK(34),
+   .dma_mask = DMA_BIT_MASK(40),
.has_hypervisor = true,
.num_sid_entries = ARRAY_SIZE(tegra186_sid_table),
.sid_table = tegra186_sid_table,
-- 
2.19.1

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

[PATCH v3 05/16] gpu: host1x: Use direct DMA with IOMMU API usage

[Thierry Reding]

From: Thierry Reding 

If we use the IOMMU API directly to map buffers into host1x' IOVA space,
we must make sure that the DMA API doesn't already set up a mapping, or
else translation will fail.

The direct DMA API allows us to allocate memory that will not be mapped
through an IOMMU automatically.

Reviewed-by: Dmitry Osipenko 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/cdma.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index e2d106fa3c0b..a96c4dd1e449 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -70,6 +71,7 @@ static void host1x_pushbuffer_destroy(struct push_buffer *pb)
  */
 static int host1x_pushbuffer_init(struct push_buffer *pb)
 {
+   unsigned long attrs = DMA_ATTR_WRITE_COMBINE;
struct host1x_cdma *cdma = pb_to_cdma(pb);
struct host1x *host1x = cdma_to_host1x(cdma);
struct iova *alloc;
@@ -91,8 +93,8 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
 
size = iova_align(>iova, size);
 
-   pb->mapped = dma_alloc_wc(host1x->dev, size, >phys,
- GFP_KERNEL);
+   pb->mapped = dma_direct_alloc(host1x->dev, size, >phys,
+ GFP_KERNEL, attrs);
if (!pb->mapped)
return -ENOMEM;
 
@@ -127,7 +129,10 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
 iommu_free_iova:
__free_iova(>iova, alloc);
 iommu_free_mem:
-   dma_free_wc(host1x->dev, size, pb->mapped, pb->phys);
+   if (host1x->domain)
+   dma_direct_free(host1x->dev, size, pb->mapped, pb->phys, attrs);
+   else
+   dma_free_wc(host1x->dev, size, pb->mapped, pb->phys);
 
return err;
 }
-- 
2.19.1

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