Re: [PATCH 2/2] drm/omap: Normalize the zpos and use the normalized_zpos in runtime

[Peter Ujfalusi]

On 2017-12-21 15:17, Daniel Vetter wrote:
> On Thu, Dec 21, 2017 at 02:11:01PM +0200, Peter Ujfalusi wrote:
>> To avoid zpos collision, use the normalized_zpos when configuring the
>> zorder of the plane.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_drv.c   | 26 +-
>>  drivers/gpu/drm/omapdrm/omap_plane.c |  2 +-
>>  2 files changed, 26 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
>> b/drivers/gpu/drm/omapdrm/omap_drv.c
>> index 6bfc2d9ebb46..230df6d8edd1 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
>> @@ -21,6 +21,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -54,6 +55,29 @@ MODULE_PARM_DESC(displays,
>>   * devices
>>   */
>>  
>> +int omap_atomic_helper_check(struct drm_device *dev,
>> + struct drm_atomic_state *state)
>> +{
>> +int ret;
>> +
>> +ret = drm_atomic_helper_check_modeset(dev, state);
>> +if (ret)
>> +return ret;
>> +
>> +ret = drm_atomic_normalize_zpos(dev, state);
>> +if (ret)
>> +return ret;
> 
> Maybe we should call this by default from helpers instead of forcing
> everyone to reinvent this particular wheel?

> exynos and sti have the exact same code as you do here, ans rcar could
> also reuse it. That feels like we should just fix up
> drm_atomic_helper_check instead of patching all the drivers. And as long
> as you never change zpos it shouldn't ever run.

It used to be done within drm_atomic_helper_check_planes() which is
called from the drm_atomic_helper_check(), but commit
38d868e41c4b9 drm: Don't force all planes to be added to the state due
to zpos

removed it. Drivers need to do this by themselves if they want to use
the normalized_zpos.

> -Daniel
> 
>> +
>> +ret = drm_atomic_helper_check_planes(dev, state);
>> +if (ret)
>> +return ret;
>> +
>> +if (state->legacy_cursor_update)
>> +state->async_update = !drm_atomic_helper_async_check(dev, 
>> state);
>> +
>> +return ret;
>> +}
>> +
>>  static void omap_atomic_wait_for_completion(struct drm_device *dev,
>>  struct drm_atomic_state *old_state)
>>  {
>> @@ -133,7 +157,7 @@ static const struct drm_mode_config_helper_funcs 
>> omap_mode_config_helper_funcs =
>>  static const struct drm_mode_config_funcs omap_mode_config_funcs = {
>>  .fb_create = omap_framebuffer_create,
>>  .output_poll_changed = drm_fb_helper_output_poll_changed,
>> -.atomic_check = drm_atomic_helper_check,
>> +.atomic_check = omap_atomic_helper_check,
>>  .atomic_commit = drm_atomic_helper_commit,
>>  };
>>  
>> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
>> b/drivers/gpu/drm/omapdrm/omap_plane.c
>> index bbbdd560e503..abd78b511e6d 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
>> @@ -65,7 +65,7 @@ static void omap_plane_atomic_update(struct drm_plane 
>> *plane,
>>  info.rotation_type = OMAP_DSS_ROT_NONE;
>>  info.rotation = DRM_MODE_ROTATE_0;
>>  info.global_alpha = 0xff;
>> -info.zorder = state->zpos;
>> +info.zorder = state->normalized_zpos;
>>  
>>  /* update scanout: */
>>  omap_framebuffer_update_scanout(state->fb, state, );
>> -- 
>> Peter
>>
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>>
> 

- Péter

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

Re: [Intel-gfx] [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Pandiyan, Dhinakaran]

On Fri, 2017-12-22 at 00:48 +, Pandiyan, Dhinakaran wrote:
> On Thu, 2017-12-21 at 08:53 +0200, Jani Nikula wrote:
> > On Wed, 20 Dec 2017, Dhinakaran Pandiyan  
> > wrote:
> > > Occasionally there are LINK_ADDRESS sideband messages timing out with the
> > > Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> > > failures lead to the display not coming up on boot. Power cycling the port
> > > corresponding to the MST monitor's branch device and resending the message
> > > fixes the issue. I am not entirely sure if this is specific to my setup.
> > > However, as the power state is toggled conditionally on LINK_ADDRESS
> > > timeouts, this should not affect the working cases.
> > 
> > With stuff like this, I always wonder if catering for a failing setup
> > blocks us from improving working setups, because once we add this, we
> > can't regress it. For example, is there a valid scenario where we'd want
> > to fail fast here, instead of retrying?
> 
> Link address failure would result in not probing a branch device that
> already has been detected. I guess the fail fast case will be applicable
> if the said device was not really present but the parent branch told us
> otherwise.
>  

The other option is we could check the device ID of the dock and
implement this as a quirk.

Btw I found some relevant information in the spec.

"The Message Transaction originator must perform the reply timeout
check. If an error to a request causes the system to be in an invalid
state (e.g., all nodes failed to delete a virtual channel, it is the
responsibility of the Message Transaction originator to return the
system to a valid state). The Message Transaction originator is
responsible for any retries."

and

"SET_POWER_STATE
Must be programmed to 001 (binary) upon power-on reset or an upstream
device disconnect.
001 = Set local Sink device and all downstream Sink devices to D0
(normal operation mode)."

I wonder if the dock is missing this step because the monitor seems to
work well with a discrete MST hub.


> > 
> > Some nits below.
> > 
> > > Cc: Lyude 
> > > Cc: Dave Airlie 
> > > Cc: Jani Nikula 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
> > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 70dcfa58d3c2..e06defcdcf18 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> > > drm_dp_mst_topology_mgr *mgr,
> > >   int len;
> > >   struct drm_dp_sideband_msg_tx *txmsg;
> > >   int ret;
> > > + int attempts = 5;
> > >  
> > > - txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > > +retry:   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > >   if (!txmsg)
> > >   return;
> > >  
> > > @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> > > drm_dp_mst_topology_mgr *mgr,
> > >   }
> > >   (*mgr->cbs->hotplug)(mgr);
> > >   }
> > > + } else if (attempts--) {
> > 
> > You'll end up doing (attempts + 1) attempts, including the first one.
> Yeah, that is what I intended to do :) I renamed it from 'retry' to
> 'attempt' at the last moment, which made it a bit confusing I suppose.
> 
> 
> I am stressing testing my setup more to see how well this recovery works
> and update this patch.
> 

Here's what I got with 266 rounds of reboots. 
Correct link address at
 1st try180
 Retry 145
 Retry 232
 Retry 30
 Retry 40
 Retry 52
Giving up   3
Incorrect link address  4

The retries help about 30% of the cases. 

>  
> 
> > 
> > > + kfree(txmsg);
> > 
> > How about memset(txmsg, 0, sizoef(*txmsg)); here and move the goto label
> > down to avoid repeated allocations?
> Absolutely.
> 
> > 
> > > + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > > +  false);
> > > + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > > +  true);
> > > + DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);
> > 
> > Maybe do the debug message before you power down/up?
> Ok.
> > 
> > BR,
> > Jani.
> > 
> > > + goto retry;
> > >   } else {
> > >   mstb->link_address_sent = false;
> > > - DRM_DEBUG_KMS("link address failed %d\n", ret);
> > > + DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
> > >   }
> > >  
> > >   kfree(txmsg);
> > 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> 

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Use an atomic_t array to track power domain use count.

[Pandiyan, Dhinakaran]

On Thu, 2017-12-21 at 13:37 +0100, Maarten Lankhorst wrote:
> Hey,
> 
> Op 19-12-17 om 06:26 schreef Dhinakaran Pandiyan:
> > Convert the power_domains->domain_use_count array that tracks per-domain
> > use count to atomic_t type. This is needed to be able to read/write the use
> > counts outside of the power domain mutex.
> >
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
> >  drivers/gpu/drm/i915/i915_drv.h |  2 +-
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +--
> >  3 files changed, 7 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 1a7b28f62570..1f1d9162f2c2 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2764,7 +2764,7 @@ static int i915_power_domain_info(struct seq_file *m, 
> > void *unused)
> > for_each_power_domain(power_domain, power_well->domains)
> > seq_printf(m, "  %-23s %d\n",
> >  intel_display_power_domain_str(power_domain),
> > -power_domains->domain_use_count[power_domain]);
> > +
> > atomic_read(_domains->domain_use_count[power_domain]));
> > }
> >  
> > mutex_unlock(_domains->lock);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 1e4e613e7b41..ddadeb9eaf49 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1489,7 +1489,7 @@ struct i915_power_domains {
> > int power_well_count;
> >  
> > struct mutex lock;
> > -   int domain_use_count[POWER_DOMAIN_NUM];
> > +   atomic_t domain_use_count[POWER_DOMAIN_NUM];
> > struct i915_power_well *power_wells;
> >  };
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 96ab74f3d101..992caec1fbc4 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -1453,7 +1453,7 @@ __intel_display_power_get_domain(struct 
> > drm_i915_private *dev_priv,
> > for_each_power_domain_well(dev_priv, power_well, BIT_ULL(domain))
> > intel_power_well_get(dev_priv, power_well);
> >  
> > -   power_domains->domain_use_count[domain]++;
> > +   atomic_inc(_domains->domain_use_count[domain]);
> >  }
> >  
> >  /**
> > @@ -1539,10 +1539,9 @@ void intel_display_power_put(struct drm_i915_private 
> > *dev_priv,
> >  
> > mutex_lock(_domains->lock);
> >  
> > -   WARN(!power_domains->domain_use_count[domain],
> > -"Use count on domain %s is already zero\n",
> > +   WARN(atomic_dec_return(_domains->domain_use_count[domain]) < 0,
> > +"Use count on domain %s was already zero\n",
> >  intel_display_power_domain_str(domain));
> > -   power_domains->domain_use_count[domain]--;
> >  
> > for_each_power_domain_well_rev(dev_priv, power_well, BIT_ULL(domain))
> > intel_power_well_put(dev_priv, power_well);
> > @@ -3049,7 +3048,7 @@ static void intel_power_domains_dump_info(struct 
> > drm_i915_private *dev_priv)
> > for_each_power_domain(domain, power_well->domains)
> > DRM_DEBUG_DRIVER("  %-23s %d\n",
> >  intel_display_power_domain_str(domain),
> > -
> > power_domains->domain_use_count[domain]);
> > +
> > atomic_read(_domains->domain_use_count[domain]));
> > }
> >  }
> >  
> > @@ -3092,7 +3091,7 @@ void intel_power_domains_verify_state(struct 
> > drm_i915_private *dev_priv)
> >  
> > domains_count = 0;
> > for_each_power_domain(domain, power_well->domains)
> > -   domains_count += 
> > power_domains->domain_use_count[domain];
> > +   domains_count += 
> > atomic_read(_domains->domain_use_count[domain]);
> >  
> > if (power_well->count != domains_count) {
> > DRM_ERROR("power well %s refcount/domain refcount 
> > mismatch "
> 
> I can imagine this will start failing really badly. The previous code assumed 
> that
> everything is protected by power_domains->lock, and now this changes makes it 
> no
> longer the case..
> 

This won't fail until the next patch where it is read outside of the
mutex. And that patch reads these values within the new spin_lock. I was
trying to split the changes so that the next patch does not become too
heavy.

> I see the rest of the code changes things even more, but it would be better 
> if the
> locking rework was done in a single patch, and not bolted on..
> 
I see your point, I can squash them together.

> And instead 

[git pull] drm fixes for Xmas (4.15-rc5)

[Dave Airlie]

Hi Linus,

I've got most of two weeks worth of fixes here due to being on
holidays last week.

The main things are:
Core:
Syncobj fd reference count fix
Leasing ioctl misuse fix

nouveau regression fixes
further amdgpu DC fixes
sun4i regression fixes

I'm not sure I'll see many fixes over next couple of weeks, we'll see how we go.

I'm around between Xmas and NY, but off for a week after that mostly.

Dave.


The following changes since commit 1291a0d5049dbc06baaaf66a9ff3f53db493b19b:

  Linux 4.15-rc4 (2017-12-17 18:59:59 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.15-rc5

for you to fetch changes up to e7cdf5c82f1773c3386b93bbcf13b9bfff29fa31:

  drm/syncobj: Stop reusing the same struct file for all syncobj -> fd
(2017-12-22 14:14:39 +1000)


i915, nouveau, sun4i, amd, ttm and core drm fixes


Ben Skeggs (6):
  drm/nouveau/bios/dp: support DP Info Table 2.0
  drm/nouveau/imem/nv50: fix refcount_t warning
  drm/nouveau/mmu/gp10b: use correct implementation
  drm/nouveau: avoid GPU page sizes > PAGE_SIZE for buffer objects
in host memory
  drm/nouveau: use alternate memory type for system-memory buffers
with kind != 0
  drm/nouveau: fix obvious memory leak

Bhawanpreet Lakha (1):
  drm/amd/display: add pipe locking before front end programing

Chris Wilson (6):
  drm/i915: Flush pending GTT writes before unbinding
  drm/i915: Drop fb reference on load_detect_pipe failure path
  drm/i915: Stop listening to request resubmission from the signaler kthread
  drm/i915/fence: Use rcu to defer freeing of irq_work
  drm/i915/lpe: Remove double-encapsulation of info string
  drm/syncobj: Stop reusing the same struct file for all syncobj -> fd

Dave Airlie (6):
  Merge branch 'drm-fixes-4.15' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2017-12-14' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes
  Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2017-12-20' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'drm-misc-fixes-2017-12-21' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

Dmytro Laktyushkin (1):
  drm/amd/display: set chroma taps to 1 when not scaling

Eric Yang (1):
  drm/amd/display: fix missing pixel clock adjustment for dongle

Hans Verkuil (1):
  drm/sun4i: validate modes for HDMI

Jerry (Fangzhi) Zuo (1):
  drm/amd/display: Fix rehook MST display not light back on

Karol Herbst (2):
  drm/nouveau/fbcon: fix NULL pointer access in nouveau_fbcon_destroy
  drm/nouveau/pci: do a msi rearm on init

Keith Packard (1):
  drm: move lease init after validation in drm_lease_create

Maarten Lankhorst (1):
  drm/plane: Make framebuffer refcounting the responsibility of
setplane_internal callers

Maxime Ripard (2):
  drm/sun4i: Fix error path handling
  drm/sun4i: hdmi: Move the mode_valid callback to the encoder

Monk Liu (3):
  drm/ttm: fix incorrect calculate on shrink_pages
  drm/ttm: max_cpages is in unit of native page
  drm/amdgpu: fix MAP_QUEUES paramter

Rodrigo Vivi (1):
  drm/i915: Protect DDI port to DPLL map from theoretical race.

 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  2 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 13 ++--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |  2 +
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 51 ++
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h|  1 +
 drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c   |  9 +++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |  4 +-
 .../amd/display/dc/dce110/dce110_hw_sequencer.c| 26 ++--
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c   |  9 ++-
 drivers/gpu/drm/drm_lease.c| 22 +++
 drivers/gpu/drm/drm_plane.c| 42 ++--
 drivers/gpu/drm/drm_syncobj.c  | 77 --
 drivers/gpu/drm/i915/i915_gem.c|  9 +--
 drivers/gpu/drm/i915/i915_sw_fence.c   |  3 +-
 drivers/gpu/drm/i915/intel_breadcrumbs.c   | 22 +++
 drivers/gpu/drm/i915/intel_ddi.c   |  4 ++
 drivers/gpu/drm/i915/intel_display.c   |  3 +-
 drivers/gpu/drm/i915/intel_lpe_audio.c |  2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c   |  5 +-
 drivers/gpu/drm/nouveau/nouveau_drv.h  | 11 +++-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_mem.c  |  6 +-
 drivers/gpu/drm/nouveau/nouveau_ttm.c  | 39 

RE: [PATCH] drm/ttm: drop the spin in delayed delete if the trylock doesn't work

[He, Roger]

Reviewed-by: Roger He 

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Friday, December 22, 2017 2:06 AM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Subject: [PATCH] drm/ttm: drop the spin in delayed delete if the trylock 
doesn't work

Thomas actually noticed that, but I didn't realized what he meant until now.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 
60bb5c12b568..84dfa2368a72 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -592,6 +592,8 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
 
} else if (reservation_object_trylock(bo->resv)) {
ttm_bo_cleanup_refs(bo, false, !remove_all, true);
+   } else {
+   spin_unlock(>lru_lock);
}
 
kref_put(>list_kref, ttm_bo_release_list);
--
2.11.0

___
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: [Intel-gfx] [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Manasi Navare]

On Thu, Dec 21, 2017 at 05:32:43PM -0800, Manasi Navare wrote:
> On Thu, Dec 21, 2017 at 05:06:22PM -0800, Pandiyan, Dhinakaran wrote:
> > On Thu, 2017-12-21 at 10:52 -0800, Manasi Navare wrote:
> > > On Wed, Dec 20, 2017 at 10:36:24PM -0800, Dhinakaran Pandiyan wrote:
> > > > Occasionally there are LINK_ADDRESS sideband messages timing out with 
> > > > the
> > > > Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. 
> > > > These
> > > > failures lead to the display not coming up on boot. Power cycling the 
> > > > port
> > > > corresponding to the MST monitor's branch device and resending the 
> > > > message
> > > > fixes the issue. I am not entirely sure if this is specific to my setup.
> > > > However, as the power state is toggled conditionally on LINK_ADDRESS
> > > > timeouts, this should not affect the working cases.
> > > > 
> > > 
> > > > Cc: Lyude 
> > > > Cc: Dave Airlie 
> > > > Cc: Jani Nikula 
> > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > ---
> > > >  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
> > > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > index 70dcfa58d3c2..e06defcdcf18 100644
> > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> > > > drm_dp_mst_topology_mgr *mgr,
> > > > int len;
> > > > struct drm_dp_sideband_msg_tx *txmsg;
> > > > int ret;
> > > > +   int attempts = 5;
> > > >
> > > 
> > > Does the spec say this should be retried 5 times or is this just an
> > > experimental number?
> > 
> > The spec. does not say how many times to retry, but it does say the
> > source is responsible for retrying. 
> > 
> > > We have such magical numbers for retries all over the DP code and that 
> > > makes debugging
> > > harder later, so atleast a comment of why its 5 would help.
> >
>  
> > Takes about 22 seconds from boot to complete 5 retries on my SKL, I
> > think that's enough trying from the kernel side before pulling out the
> > DP cable makes sense :)
> >
> 
> It still appears to be a magical number so better to comment it properly.
> Helps in the debug
>  
> > >   
> > > > -   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > > > +retry: txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > > > if (!txmsg)
> > > > return;
> > > >  
> > > > @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> > > > drm_dp_mst_topology_mgr *mgr,
> > > > }
> > > > (*mgr->cbs->hotplug)(mgr);
> > > > }
> > > > +   } else if (attempts--) {
> > > 
> > > This should be --attempts if you want the total attempts to be 5
> > I don't.
> 
> Yes the variable attempts is misleading in that case. Probably call it "tries"
>
I meant retries..

Manasi 
> Manasi
> 
> > > 
> > > Manasi
> > > 
> > > > +   kfree(txmsg);
> > > > +   drm_dp_send_power_updown_phy(mstb->mgr, 
> > > > mstb->port_parent,
> > > > +false);
> > > > +   drm_dp_send_power_updown_phy(mstb->mgr, 
> > > > mstb->port_parent,
> > > > +true);
> > > > +   DRM_DEBUG_KMS("link address failed %d, retrying\n", 
> > > > ret);
> > > > +   goto retry;
> > > > } else {
> > > > mstb->link_address_sent = false;
> > > > -   DRM_DEBUG_KMS("link address failed %d\n", ret);
> > > > +   DRM_DEBUG_KMS("link address failed %d, giving up\n", 
> > > > ret);
> > > > }
> > > >  
> > > > kfree(txmsg);
> > > > -- 
> > > > 2.11.0
> > > > 
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > ___
> > > Intel-gfx mailing list
> > > intel-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> 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: [Intel-gfx] [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Manasi Navare]

On Thu, Dec 21, 2017 at 05:06:22PM -0800, Pandiyan, Dhinakaran wrote:
> On Thu, 2017-12-21 at 10:52 -0800, Manasi Navare wrote:
> > On Wed, Dec 20, 2017 at 10:36:24PM -0800, Dhinakaran Pandiyan wrote:
> > > Occasionally there are LINK_ADDRESS sideband messages timing out with the
> > > Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> > > failures lead to the display not coming up on boot. Power cycling the port
> > > corresponding to the MST monitor's branch device and resending the message
> > > fixes the issue. I am not entirely sure if this is specific to my setup.
> > > However, as the power state is toggled conditionally on LINK_ADDRESS
> > > timeouts, this should not affect the working cases.
> > > 
> > 
> > > Cc: Lyude 
> > > Cc: Dave Airlie 
> > > Cc: Jani Nikula 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
> > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 70dcfa58d3c2..e06defcdcf18 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> > > drm_dp_mst_topology_mgr *mgr,
> > >   int len;
> > >   struct drm_dp_sideband_msg_tx *txmsg;
> > >   int ret;
> > > + int attempts = 5;
> > >
> > 
> > Does the spec say this should be retried 5 times or is this just an
> > experimental number?
> 
> The spec. does not say how many times to retry, but it does say the
> source is responsible for retrying. 
> 
> > We have such magical numbers for retries all over the DP code and that 
> > makes debugging
> > harder later, so atleast a comment of why its 5 would help.
>
 
> Takes about 22 seconds from boot to complete 5 retries on my SKL, I
> think that's enough trying from the kernel side before pulling out the
> DP cable makes sense :)
>

It still appears to be a magical number so better to comment it properly.
Helps in the debug
 
> >   
> > > - txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > > +retry:   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > >   if (!txmsg)
> > >   return;
> > >  
> > > @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> > > drm_dp_mst_topology_mgr *mgr,
> > >   }
> > >   (*mgr->cbs->hotplug)(mgr);
> > >   }
> > > + } else if (attempts--) {
> > 
> > This should be --attempts if you want the total attempts to be 5
> I don't.

Yes the variable attempts is misleading in that case. Probably call it "tries"

Manasi

> > 
> > Manasi
> > 
> > > + kfree(txmsg);
> > > + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > > +  false);
> > > + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > > +  true);
> > > + DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);
> > > + goto retry;
> > >   } else {
> > >   mstb->link_address_sent = false;
> > > - DRM_DEBUG_KMS("link address failed %d\n", ret);
> > > + DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
> > >   }
> > >  
> > >   kfree(txmsg);
> > > -- 
> > > 2.11.0
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Pandiyan, Dhinakaran]

On Thu, 2017-12-21 at 10:52 -0800, Manasi Navare wrote:
> On Wed, Dec 20, 2017 at 10:36:24PM -0800, Dhinakaran Pandiyan wrote:
> > Occasionally there are LINK_ADDRESS sideband messages timing out with the
> > Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> > failures lead to the display not coming up on boot. Power cycling the port
> > corresponding to the MST monitor's branch device and resending the message
> > fixes the issue. I am not entirely sure if this is specific to my setup.
> > However, as the power state is toggled conditionally on LINK_ADDRESS
> > timeouts, this should not affect the working cases.
> > 
> 
> > Cc: Lyude 
> > Cc: Dave Airlie 
> > Cc: Jani Nikula 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 70dcfa58d3c2..e06defcdcf18 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> > drm_dp_mst_topology_mgr *mgr,
> > int len;
> > struct drm_dp_sideband_msg_tx *txmsg;
> > int ret;
> > +   int attempts = 5;
> >
> 
> Does the spec say this should be retried 5 times or is this just an
> experimental number?

The spec. does not say how many times to retry, but it does say the
source is responsible for retrying. 

> We have such magical numbers for retries all over the DP code and that makes 
> debugging
> harder later, so atleast a comment of why its 5 would help.

Takes about 22 seconds from boot to complete 5 retries on my SKL, I
think that's enough trying from the kernel side before pulling out the
DP cable makes sense :)

>   
> > -   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > +retry: txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > if (!txmsg)
> > return;
> >  
> > @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> > drm_dp_mst_topology_mgr *mgr,
> > }
> > (*mgr->cbs->hotplug)(mgr);
> > }
> > +   } else if (attempts--) {
> 
> This should be --attempts if you want the total attempts to be 5
I don't.
> 
> Manasi
> 
> > +   kfree(txmsg);
> > +   drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > +false);
> > +   drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > +true);
> > +   DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);
> > +   goto retry;
> > } else {
> > mstb->link_address_sent = false;
> > -   DRM_DEBUG_KMS("link address failed %d\n", ret);
> > +   DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
> > }
> >  
> > kfree(txmsg);
> > -- 
> > 2.11.0
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Pandiyan, Dhinakaran]

On Thu, 2017-12-21 at 08:53 +0200, Jani Nikula wrote:
> On Wed, 20 Dec 2017, Dhinakaran Pandiyan  
> wrote:
> > Occasionally there are LINK_ADDRESS sideband messages timing out with the
> > Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> > failures lead to the display not coming up on boot. Power cycling the port
> > corresponding to the MST monitor's branch device and resending the message
> > fixes the issue. I am not entirely sure if this is specific to my setup.
> > However, as the power state is toggled conditionally on LINK_ADDRESS
> > timeouts, this should not affect the working cases.
> 
> With stuff like this, I always wonder if catering for a failing setup
> blocks us from improving working setups, because once we add this, we
> can't regress it. For example, is there a valid scenario where we'd want
> to fail fast here, instead of retrying?

Link address failure would result in not probing a branch device that
already has been detected. I guess the fail fast case will be applicable
if the said device was not really present but the parent branch told us
otherwise.
 
> 
> Some nits below.
> 
> > Cc: Lyude 
> > Cc: Dave Airlie 
> > Cc: Jani Nikula 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 70dcfa58d3c2..e06defcdcf18 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> > drm_dp_mst_topology_mgr *mgr,
> > int len;
> > struct drm_dp_sideband_msg_tx *txmsg;
> > int ret;
> > +   int attempts = 5;
> >  
> > -   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > +retry: txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > if (!txmsg)
> > return;
> >  
> > @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> > drm_dp_mst_topology_mgr *mgr,
> > }
> > (*mgr->cbs->hotplug)(mgr);
> > }
> > +   } else if (attempts--) {
> 
> You'll end up doing (attempts + 1) attempts, including the first one.
Yeah, that is what I intended to do :) I renamed it from 'retry' to
'attempt' at the last moment, which made it a bit confusing I suppose.


I am stressing testing my setup more to see how well this recovery works
and update this patch.

 

> 
> > +   kfree(txmsg);
> 
> How about memset(txmsg, 0, sizoef(*txmsg)); here and move the goto label
> down to avoid repeated allocations?
Absolutely.

> 
> > +   drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > +false);
> > +   drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > +true);
> > +   DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);
> 
> Maybe do the debug message before you power down/up?
Ok.
> 
> BR,
> Jani.
> 
> > +   goto retry;
> > } else {
> > mstb->link_address_sent = false;
> > -   DRM_DEBUG_KMS("link address failed %d\n", ret);
> > +   DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
> > }
> >  
> > kfree(txmsg);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2 v3] drm/panel: Add Ilitek ILI9322 driver

[Linus Walleij]

This adds support for the Ilitek ILI9322 QVGA (320x240)
TFT panel driver.

This panel driver supports serial or parallel RGB or
YUV input and also ITU-T BT.656 input streams.

The controller is combined with a physical panel and
configured through the device tree.

Cc: David Lechner 
Cc: Stefano Babic 
Cc: Ben Dooks 
Acked-by: Thierry Reding 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Fix minor checkpatch fallouts.
- Collect Thierry's ACK.
ChangeLog v1->v2:
- Dropped all DT parsing code in favor of open-coding the
  display config on a per-system basis based on system-specific
  compatible strings, after feedback from the DT maintainers.
- Define a set of configs for the D-Link DIR-685 router.
- Tested on the D-Link DIR-685.
---
 drivers/gpu/drm/panel/Kconfig|   8 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 962 +++
 3 files changed, 971 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9322.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 726f3fb3312d..6ba4031f3919 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -28,6 +28,14 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.
 
+config DRM_PANEL_ILITEK_IL9322
+   tristate "Ilitek ILI9322 320x240 QVGA panels"
+   depends on OF && SPI
+   select REGMAP
+   help
+ Say Y here if you want to enable support for Ilitek IL9322
+ QVGA (320x240) RGB, YUV and ITU-T BT.656 panels.
+
 config DRM_PANEL_INNOLUX_P079ZCA
tristate "Innolux P079ZCA panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 2c4e1a93e05f..6d251ebc568c 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
new file mode 100644
index ..b4ec0ecff807
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -0,0 +1,962 @@
+/*
+ * Ilitek ILI9322 TFT LCD drm_panel driver.
+ *
+ * This panel can be configured to support:
+ * - 8-bit serial RGB interface
+ * - 24-bit parallel RGB interface
+ * - 8-bit ITU-R BT.601 interface
+ * - 8-bit ITU-R BT.656 interface
+ * - Up to 320RGBx240 dots resolution TFT LCD displays
+ * - Scaling, brightness and contrast
+ *
+ * The scaling means that the display accepts a 640x480 or 720x480
+ * input and rescales it to fit to the 320x240 display. So what we
+ * present to the system is something else than what comes out on the
+ * actual display.
+ *
+ * Copyright (C) 2017 Linus Walleij 
+ * Derived from drivers/drm/gpu/panel/panel-samsung-ld9040.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define ILI9322_CHIP_ID0x00
+#define ILI9322_CHIP_ID_MAGIC  0x96
+
+/*
+ * Voltage on the communication interface, from 0.7 (0x00)
+ * to 1.32 (0x1f) times the VREG1OUT voltage in 2% increments.
+ * 1.00 (0x0f) is the default.
+ */
+#define ILI9322_VCOM_AMP   0x01
+
+/*
+ * High voltage on the communication signals, from 0.37 (0x00) to
+ * 1.0 (0x3f) times the VREGOUT1 voltage in 1% increments.
+ * 0.83 (0x2e) is the default.
+ */
+#define ILI9322_VCOM_HIGH  0x02
+
+/*
+ * VREG1 voltage regulator from 3.6V (0x00) to 6.0V (0x18) in 0.1V
+ * increments. 5.4V (0x12) is the default. This is the reference
+ * voltage for the VCOM levels and the greyscale level.
+ */
+#define ILI9322_VREG1_VOLTAGE  0x03
+
+/* Describes the incoming signal */
+#define ILI9322_ENTRY  0x06
+/* 0 = right-to-left, 1 = left-to-right (default), horizontal flip */
+#define ILI9322_ENTRY_HDIR BIT(0)
+/* 0 = down-to-up, 1 = up-to-down (default), vertical flip  */
+#define ILI9322_ENTRY_VDIR BIT(1)
+/* NTSC, PAL or autodetect */
+#define ILI9322_ENTRY_NTSC (0 << 2)
+#define ILI9322_ENTRY_PAL  (1 << 2)
+#define ILI9322_ENTRY_AUTODETECT   (3 << 

Re: [PATCH 2/3] drm/panel: Add Ilitek ILI9322 driver

[Linus Walleij]

On Thu, Dec 21, 2017 at 5:15 PM, Thierry Reding
 wrote:

> Daniel just reminded me on IRC that you have commit rights to drm-misc,
> so once you've fixed up the bulk of the checkpatch warnings (nevermind
> those "prefer the BIT macro" checks), feel free to push this yourself
> with my:
>
> Acked-by: Thierry Reding 

OK thanks man I fix.

I will resend the patch with your ACK anyways, because
I have no clue how to get the right mailing list message ID into a
patch I just generate from my own tree.

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

Re: [PATCH 2/3] drm/panel: Add Ilitek ILI9322 driver

[Linus Walleij]

On Thu, Dec 21, 2017 at 3:15 PM, Thierry Reding
 wrote:

> checkpatch.pl gives me these:
>
> -:30: WARNING: please write a paragraph that describes the config 
> symbol fully
> #30: FILE: drivers/gpu/drm/panel/Kconfig:31:
> +config DRM_PANEL_ILITEK_IL9322

I don't understand this because there is a blurb. I have had this
false positive before.

> -:54: WARNING: added, moved or deleted file(s), does MAINTAINERS need 
> updating?
> #54:
> new file mode 100644

Skipping as agreed.

> -:130: CHECK: Prefer using the BIT macro
> #130: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:72:
> +#define ILI9322_ENTRY_PAL  (1 << 2)
>
> -:134: CHECK: Prefer using the BIT macro
> #134: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:76:
> +#define ILI9322_ENTRY_SERIAL_RGB_ALIGNED (1 << 4)

These are bananas because checkpatch doesn't understand
context. They are actually bitfields with the first bit set.

> -:196: CHECK: spaces preferred around that '|' (ctx:VxV)
> #196: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:138:
> +#define ILI9322_IF_CTRL_SYNC_DISABLED  (BIT(2)|BIT(3))

I didn't get this warning, wonder why. Fixed it anyways.

> -:551: WARNING: msleep < 20ms can sleep for up to 20ms; see 
> Documentation/timers/timers-howto.txt
> #551: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:493:
> +   msleep(10);

It's fine if it takes 20 or 90 ms so I chose to just ignore it. It's not on
any critical path.

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

Re: [PATCH v2 4/5] ARM: dts: Add support for emtrion emCON-MX6 series

[Rob Herring]

On Wed, Dec 20, 2017 at 02:47:04PM +0100, jan.tu...@emtrion.com wrote:
> From: Jan Tuerk 
> 
> This patch adds support for the emtrion GmbH emCON-MX6 modules.
> They are available with imx.6 Solo, Dual-Lite, Dual and Quad
> equipped with Memory from 512MB to 2GB (configured by U-Boot).
> 
> Our default developer-Kit ships with the Avari baseboard and the
> EDT ETM0700G0BDH6 Display (imx6[q|dl]-emcon-avari).
> 
> The devicetree is split into the common part providing all module
> components and the basic support for all SoC versions
> (imx6qdl-emcon.dtsi) and parts which are i.mx6 S|DL and D|Q relevant.
> Finally the support for the avari baseboard in the developer-kit
> configuration is provided by the emcon-avari dts files.
> 
> Signed-off-by: Jan Tuerk 
> ---
> Changes in v2:
>  - Fixed typo (reg_prallel.. --> reg_parallel)
>  - Removed trailing new-line
>  - Fix uppercase addresses as Rob H. noted
>  - Fix warning about lcd@di0 -> rename to disp0
>  - Renamed some nodes regarding Rob H.
> 
>  Documentation/devicetree/bindings/arm/emtrion.txt |  13 +
>  arch/arm/boot/dts/Makefile|   2 +
>  arch/arm/boot/dts/imx6dl-emcon-avari.dts  | 233 ++
>  arch/arm/boot/dts/imx6dl-emcon.dtsi   |  37 +
>  arch/arm/boot/dts/imx6q-emcon-avari.dts   | 233 ++
>  arch/arm/boot/dts/imx6q-emcon.dtsi|  37 +
>  arch/arm/boot/dts/imx6qdl-emcon.dtsi  | 848 
> ++
>  7 files changed, 1403 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/emtrion.txt
>  create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
>  create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi

[...]

> + captouch: touchscreen@38 {
> + reg = <0x38>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_irq_touch2 _emcon_gpio4>;
> + interrupt-parent = <>;
> + interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
> + compatible = "edt,edt-ft5406";

Put compatible as the first property.

> + wake-gpios = < 3 GPIO_ACTIVE_HIGH>;
> + wakeup-source;
> + };
> +};

[...]

> +_panel {
> + compatible = "edt,etm0700g0bdh6";
> + status = "okay";

Having compatible here is a bit strange and fragile. It's assuming 2 
different panels have the same common properties.


> diff --git a/arch/arm/boot/dts/imx6q-emcon.dtsi 
> b/arch/arm/boot/dts/imx6q-emcon.dtsi
> new file mode 100644
> index ..64fc0cd74c05
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-emcon.dtsi
> @@ -0,0 +1,37 @@
> +/*
> + * Copyright (C) 2017 emtrion GmbH
> + * Author: Jan Tuerk  
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html

You don't need this if...

> + *
> + * SPDX-License-Identifier: GPL-2.0

You have this.

Also, the rules around this are getting a bit stricter saying the SPDX 
tag should be the first line of the file using a C++ style comment.

> + *
> + */
> +
> +/ {
> + model = "emtrion SoM emCON-MX6 Dual/Quad";
> + compatible = "emtrion,emcon-mx6","fsl,imx6q";

Need a space ^

> diff --git a/arch/arm/boot/dts/imx6qdl-emcon.dtsi 
> b/arch/arm/boot/dts/imx6qdl-emcon.dtsi
> new file mode 100644
> index ..f87d8ed6a1b1
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-emcon.dtsi
> @@ -0,0 +1,848 @@
> +/*
> + * Copyright (C) 2017 emtrion GmbH
> + * Author: Jan Tuerk  
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +/ {
> +
> + model = "emtrion SoM emCON-MX6";
> + compatible = "emtrion,emcon-mx6","fsl,imx6q", "fsl,imx6dl";

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

Re: [PATCH v2 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6

[Rob Herring]

On Wed, Dec 20, 2017 at 02:47:01PM +0100, jan.tu...@emtrion.com wrote:
> From: Jan Tuerk 
> 
> The Emerging Display Technology ETM0700G0BDH6 is exactly
> the same display as the ETM0700G0DH6, exept the pixelclock
> polarity. Therefore re-use the ETM0700G0DH6 modes. It is
> used by default on emtrion Avari based development kits.

As I asked on v1, why not document the panels together in a single doc?

> 
> Signed-off-by: Jan Tuerk 
> ---
>  .../bindings/display/panel/edt,etm0700g0bdh6.txt  |  9 +
>  drivers/gpu/drm/panel/panel-simple.c  | 15 
> +++
>  2 files changed, 24 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vc4: Flush the caches before the bin jobs, as well.

[Eric Anholt]

If the frame samples from a render target that was just written, its
cache flush during the binning step may have occurred before the
previous frame's RCL was completed.  Flush the texture caches again
before starting each RCL job to make sure that the sampling of the
previous RCL's output is correct.

Fixes flickering in the top left of 3DMMES Taiji.

Signed-off-by: Eric Anholt 
Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and 
rendering jobs")
---
 drivers/gpu/drm/vc4/vc4_gem.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 6c32c89a83a9..afa7fe21b35e 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -436,6 +436,19 @@ vc4_flush_caches(struct drm_device *dev)
  VC4_SET_FIELD(0xf, V3D_SLCACTL_ICC));
 }
 
+static void
+vc4_flush_texture_caches(struct drm_device *dev)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+   V3D_WRITE(V3D_L2CACTL,
+ V3D_L2CACTL_L2CCLR);
+
+   V3D_WRITE(V3D_SLCACTL,
+ VC4_SET_FIELD(0xf, V3D_SLCACTL_T1CC) |
+ VC4_SET_FIELD(0xf, V3D_SLCACTL_T0CC));
+}
+
 /* Sets the registers for the next job to be actually be executed in
  * the hardware.
  *
@@ -474,6 +487,14 @@ vc4_submit_next_render_job(struct drm_device *dev)
if (!exec)
return;
 
+   /* A previous RCL may have written to one of our textures, and
+* our full cache flush at bin time may have occurred before
+* that RCL completed.  Flush the texture cache now, but not
+* the instructions or uniforms (since we don't write those
+* from an RCL).
+*/
+   vc4_flush_texture_caches(dev);
+
submit_cl(dev, 1, exec->ct1ca, exec->ct1ea);
 }
 
-- 
2.15.0

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

RE: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]

[Carroll, Lewis]

> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Thursday, December 21, 2017 3:31 PM
> To: Carroll, Lewis ; Daenzer, Michel
> 
> Cc: Wentland, Harry ; dri-
> de...@lists.freedesktop.org
> Subject: Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma table
> [patch proposed]
> 
> Fyi Michel, we've discussed similar issues for radeon/amdgpu on irc.
> 
> On Thu, Dec 21, 2017 at 4:21 PM, Carroll, Lewis 
> wrote:
> >> -Original Message-
> >> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> >> Vetter
> >> Sent: Thursday, December 21, 2017 5:07 AM
> >> To: Carroll, Lewis 
> >> Cc: Wentland, Harry ; dri-
> >> de...@lists.freedesktop.org
> >> Subject: Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma
> table
> >> [patch proposed]
> >>
> >> On Thu, Dec 21, 2017 at 12:00:39AM +, Carroll, Lewis wrote:
> >> > The discussion sounds similar as well - related to load_lut() not being
> called.
> >> >
> >> > Perhaps after the drm-next-4.14 merge, whatever call stack used to
> cause
> >> > load_lut to always get called is now gone. Even if
> FB_VISUAL_TRUECOLOR
> >> > doesn't support a clut, some hardware may still need a default gamma
> lut
> >> > loaded (appears to be the case with the AST2500). Perhaps checking for
> >> > that profile and loading the default LUT prepared by
> >> > drm_mode_crtc_set_gamma_size when FB_VISUAL_TRUECOLOR...?
> >>
> >> Yeah drivers should load that somehow. Unfortunately I'm going on
> >> vacations now, so I'm not going to fix anything anytime soon. Might be
> >> good to ping Peter Rosin, he did all the fbdev emulation gamma handling
> >> rework (which is the patch that removed the superflously-looking call to
> >> ->load_lut that some drivers relied on to have a consistent lut state).
> >> -Daniel
> >
> > Enjoy the holidays.
> >
> > Wonder if it would be better to just call load_lut after
> > drm_mode_crtc_set_gamma_size instead of adding a potentially
> > unnecessary DPMS ON event to the commit call-back as I did...? Or call
> > load_lut in the commit callback instead of the DPMS ON call...?
> >
> > The first approach (calling load_lut after set_gamma_size) also works on
> > two test systems.
> 
> Yeah, I think that's the cleanest approach. The underlying issue is
> that a bunch of drivers are not making sure that on driver-load they
> have a consistent sw/hw state for the gamma ramp. As long as you had
> fbcon enabled the strange ->load_lut call (which isn't really
> necessary for drivers that got this right) papered over these issues.
> 
> So a call to you driver's load_lut right affter
> drm_mode_crtc_set_gamma_size should fix this correctly. a-b:me if you
> submit that patch.

Reworked patch attached, commit message changed to summarize the
Above discussion.

> 
> /me off for real now
> 
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch


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

[Bug 103107] [CI] igt@gem_ctx_param@invalid-param-[get|set] - Failed assertion: __gem_context_get_param(fd, ) == -22

[bugzilla-daemon]

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

--- Comment #9 from Octavio  ---
The following tests are failing on BXT 

igt@gem_ctx_param@invalid-param-get
igt@gem_ctx_param@invalid-param-set

using
IGT-Version: 1.20-gbeb26d8 (x86_64) (Linux:
4.15.0-rc4-drm-intel-qa-ww51-commit-b480e79+ x86_64)

-- 
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] drm: Add DPCD definitions for DP 1.4 FEC feature

[Srivatsa, Anusha]

>-Original Message-
>From: Navare, Manasi D
>Sent: Thursday, December 21, 2017 12:36 PM
>To: Srivatsa, Anusha 
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Ville 
>Syrjala
>; Jani Nikula 
>Subject: Re: [PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature
>
>On Mon, Nov 27, 2017 at 04:55:44PM -0800, Anusha Srivatsa wrote:
>> Forward Error Correction is supported on DP 1.4.
>> This patch adds corresponding DPCD register definitions.
>>
>> v2: Add dri-devel to the CC list
>>
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: Ville Syrjala 
>> Cc: Jani Nikula 
>> Cc: Manasi Navare 
>> Signed-off-by: Anusha Srivatsa 
>> ---
>>  include/drm/drm_dp_helper.h | 29 +
>>  1 file changed, 29 insertions(+)
>>
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> index da58a42..bc816ea 100644
>> --- a/include/drm/drm_dp_helper.h
>> +++ b/include/drm/drm_dp_helper.h
>> @@ -284,6 +284,35 @@
>>  # define DP_DSC_BITS_PER_PIXEL_1_2  0x3
>>  # define DP_DSC_BITS_PER_PIXEL_10x4
>>
>> +/* DP Forward error Correction Registers */
>> +#define DP_FEC_CAPABILITY   0x090
>> +# define DP_FEC_CAPABLE (1 << 0)
>> +# define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
>> +# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
>> +# define DP_FEC_BIT_ERROR_COUNT_CAP (1 << 3)
>> +
>> +#define DP_FEC_CONFIGURATION0x120
>> +# define DP_FEC_READY   (1 << 0)
>> +# define DP_FEC_ERR_COUNT_DIS   (0 << 1)
>> +# define DP_FEC_UNCORR_BLK_ERROR_COUNT  (1 << 1)
>> +# define DP_FEC_CORR_BLK_ERROR_COUNT(2 << 1)
>> +# define DP_FEC_BIT_ERROR_COUNT (3 << 1)
>
>These above values indicate the value of FEC_ERROR_COUNT_SEL.
>I think we would need a mask for FEC_ERROR_COUNT_SEL field so that we can
>read this field as drm_dpcd_read(DP_FEC_CONFIGURATION) &
>FEC_ERROR_COUNT_SEL_MASK and then compare this to each of the values for
>that field.
>So we would need an extra #define for the MASK

Sounds good 

>> +# define DP_FEC_LANE_0_SELECT   (0 << 4)
>> +# define DP_FEC_LANE_1_SELECT   (1 << 4)
>> +# define DP_FEC_LANE_2_SELECT   (2 << 4)
>> +# define DP_FEC_LANE_3_SELECT   (3 << 4)
>> +
>> +#define DP_FEC_STATUS   0x280
>> +# define DP_FEC_EN_DETECTED (1 << 0)
>
>I think better name would be DP_FEC_DECODE_EN_DETECTED since this refers to
>FEC_DECODE_EN link symbol sequence

Now that you mentioned, I noticed that's the name used in spec too. I wonder 
why I went ahead with the above name. Shall change it. Thanks.

>> +# define DP_FEC_DEC_DETECTED(1 << 1)
>
>And this should be DP_FEC_DECODE_DIS_DETECTED since this refers to
>FEC_DECODE_DIS link symbol sequence
>
>> +
>> +#define DP_FEC_ERROR_COUNT_10x0281
>> +# define DP_FEC_ERR_COUNT_7_0(err_count)(err_count << 0)
>
>So this is a RO register and so we wont be writing the err_count by passing it 
>as
>an argument as above.
>And this is the entire reister that indicates the LSB of ERR_COUNT you can just
>rename the register as DP_FEC_ERR_COUNT_LSB So while reading you just pass
>this register address and get LSB into a variable.

Yes, good point.

>
>> +
>> +#define DP_FEC_ERROR_COUNT_20x0282
>> +# define DP_FEC_ERR_COUNT_14_8(err_count)   (err_count << 0)
>
>This could be DP_FEC_ERR_COUNT_MSB_MASK and SHIFT should be 8 since you
>want to put this value at the 8th bit of a 16 bit value.

This helps thanks!

>> +# define DP_FEC_ERR_COUNT_VALID (1 << 7)
>
>Everything else looks good.

Thanks Manasi. I will incorporate these changes in the next revision.

Anusha 
>Manasi
>
>> +
>>  #define DP_PSR_SUPPORT  0x070   /* XXX 1.2? */
>>  # define DP_PSR_IS_SUPPORTED1
>>  # define DP_PSR2_IS_SUPPORTED   2   /* eDP 1.4 */
>> --
>> 2.7.4
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104306] Mesa 17.3 breaks Firefox and other Xwayland apps on AMD HD7750

[bugzilla-daemon]

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

eric vz  changed:

   What|Removed |Added

 Attachment #136345|0   |1
is obsolete||

--- Comment #7 from eric vz  ---
Created attachment 136350
  --> https://bugs.freedesktop.org/attachment.cgi?id=136350=edit
Hung glxinfo backtrace - mesa 17.3.1-1

On the chance you'd want to see a newer version, I built mesa 17.3.1-1 (with
debug symbols this time!) and have the same issue.  Backtrace attached.

-- 
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] drm: Add DPCD definitions for DP 1.4 FEC feature

[Manasi Navare]

On Mon, Nov 27, 2017 at 04:55:44PM -0800, Anusha Srivatsa wrote:
> Forward Error Correction is supported on DP 1.4.
> This patch adds corresponding DPCD register definitions.
> 
> v2: Add dri-devel to the CC list
> 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 
> ---
>  include/drm/drm_dp_helper.h | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..bc816ea 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -284,6 +284,35 @@
>  # define DP_DSC_BITS_PER_PIXEL_1_2  0x3
>  # define DP_DSC_BITS_PER_PIXEL_10x4
>  
> +/* DP Forward error Correction Registers */
> +#define DP_FEC_CAPABILITY0x090
> +# define DP_FEC_CAPABLE  (1 << 0)
> +# define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
> +# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
> +# define DP_FEC_BIT_ERROR_COUNT_CAP  (1 << 3)
> +
> +#define DP_FEC_CONFIGURATION 0x120
> +# define DP_FEC_READY(1 << 0)
> +# define DP_FEC_ERR_COUNT_DIS(0 << 1)
> +# define DP_FEC_UNCORR_BLK_ERROR_COUNT   (1 << 1)
> +# define DP_FEC_CORR_BLK_ERROR_COUNT (2 << 1)
> +# define DP_FEC_BIT_ERROR_COUNT  (3 << 1)

These above values indicate the value of FEC_ERROR_COUNT_SEL.
I think we would need a mask for FEC_ERROR_COUNT_SEL field so that
we can read this field as drm_dpcd_read(DP_FEC_CONFIGURATION) & 
FEC_ERROR_COUNT_SEL_MASK
and then compare this to each of the values for that field.
So we would need an extra #define for the MASK

> +# define DP_FEC_LANE_0_SELECT(0 << 4)
> +# define DP_FEC_LANE_1_SELECT(1 << 4)
> +# define DP_FEC_LANE_2_SELECT(2 << 4)
> +# define DP_FEC_LANE_3_SELECT(3 << 4)
> +
> +#define DP_FEC_STATUS0x280
> +# define DP_FEC_EN_DETECTED  (1 << 0)

I think better name would be DP_FEC_DECODE_EN_DETECTED since this refers
to FEC_DECODE_EN link symbol sequence

> +# define DP_FEC_DEC_DETECTED (1 << 1)

And this should be DP_FEC_DECODE_DIS_DETECTED since this refers to
FEC_DECODE_DIS link symbol sequence

> +
> +#define DP_FEC_ERROR_COUNT_1 0x0281
> +# define DP_FEC_ERR_COUNT_7_0(err_count)(err_count << 0)

So this is a RO register and so we wont be writing the err_count by passing it 
as
an argument as above.
And this is the entire reister that indicates the LSB of ERR_COUNT you can just 
rename the
register as DP_FEC_ERR_COUNT_LSB
So while reading you just pass this register address and get LSB into a 
variable.

> +
> +#define DP_FEC_ERROR_COUNT_2 0x0282
> +# define DP_FEC_ERR_COUNT_14_8(err_count)   (err_count << 0)

This could be DP_FEC_ERR_COUNT_MSB_MASK and SHIFT should be 8 since
you want to put this value at the 8th bit of a 16 bit value.

> +# define DP_FEC_ERR_COUNT_VALID  (1 << 7)

Everything else looks good.

Manasi

> +
>  #define DP_PSR_SUPPORT  0x070   /* XXX 1.2? */
>  # define DP_PSR_IS_SUPPORTED1
>  # define DP_PSR2_IS_SUPPORTED2   /* eDP 1.4 */
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]

[Daniel Vetter]

Fyi Michel, we've discussed similar issues for radeon/amdgpu on irc.

On Thu, Dec 21, 2017 at 4:21 PM, Carroll, Lewis  wrote:
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Thursday, December 21, 2017 5:07 AM
>> To: Carroll, Lewis 
>> Cc: Wentland, Harry ; dri-
>> de...@lists.freedesktop.org
>> Subject: Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma table
>> [patch proposed]
>>
>> On Thu, Dec 21, 2017 at 12:00:39AM +, Carroll, Lewis wrote:
>> > The discussion sounds similar as well - related to load_lut() not being 
>> > called.
>> >
>> > Perhaps after the drm-next-4.14 merge, whatever call stack used to cause
>> > load_lut to always get called is now gone. Even if FB_VISUAL_TRUECOLOR
>> > doesn't support a clut, some hardware may still need a default gamma lut
>> > loaded (appears to be the case with the AST2500). Perhaps checking for
>> > that profile and loading the default LUT prepared by
>> > drm_mode_crtc_set_gamma_size when FB_VISUAL_TRUECOLOR...?
>>
>> Yeah drivers should load that somehow. Unfortunately I'm going on
>> vacations now, so I'm not going to fix anything anytime soon. Might be
>> good to ping Peter Rosin, he did all the fbdev emulation gamma handling
>> rework (which is the patch that removed the superflously-looking call to
>> ->load_lut that some drivers relied on to have a consistent lut state).
>> -Daniel
>
> Enjoy the holidays.
>
> Wonder if it would be better to just call load_lut after
> drm_mode_crtc_set_gamma_size instead of adding a potentially
> unnecessary DPMS ON event to the commit call-back as I did...? Or call
> load_lut in the commit callback instead of the DPMS ON call...?
>
> The first approach (calling load_lut after set_gamma_size) also works on
> two test systems.

Yeah, I think that's the cleanest approach. The underlying issue is
that a bunch of drivers are not making sure that on driver-load they
have a consistent sw/hw state for the gamma ramp. As long as you had
fbcon enabled the strange ->load_lut call (which isn't really
necessary for drivers that got this right) papered over these issues.

So a call to you driver's load_lut right affter
drm_mode_crtc_set_gamma_size should fix this correctly. a-b:me if you
submit that patch.

/me off for real now

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: rcar-du: lvds: fix LVDCR1 for R-Car gen3

[Sergei Shtylyov]

The LVDCR1 register for the R-Car gen3 SoCs was documented as having the
layout different from the gen2 SoCs in  the early R-Car gen3 manuals but
since v0.52 the LVDCR1 layout is described as being the same as on the gen2
SoCs; the old CHn control values are said to be prohibited now (and there
seems to be no valid output signal when they are used).

Fixes: 6bc2e15cf21c ("drm: rcar-du: lvds: Add R-Car Gen3 support")
Signed-off-by: Sergei Shtylyov 

---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |   10 --
 drivers/gpu/drm/rcar-du/rcar_lvds_regs.h  |6 ++
 2 files changed, 6 insertions(+), 10 deletions(-)

Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -70,9 +70,8 @@ static void rcar_du_lvdsenc_start_gen2(s
 
/* Turn all the channels on. */
rcar_lvds_write(lvds, LVDCR1,
-   LVDCR1_CHSTBY_GEN2(3) | LVDCR1_CHSTBY_GEN2(2) |
-   LVDCR1_CHSTBY_GEN2(1) | LVDCR1_CHSTBY_GEN2(0) |
-   LVDCR1_CLKSTBY_GEN2);
+   LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
+   LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
 
/*
 * Turn the PLL on, wait for the startup delay, and turn the output
@@ -109,9 +108,8 @@ static void rcar_du_lvdsenc_start_gen3(s
 
/* Turn all the channels on. */
rcar_lvds_write(lvds, LVDCR1,
-   LVDCR1_CHSTBY_GEN3(3) | LVDCR1_CHSTBY_GEN3(2) |
-   LVDCR1_CHSTBY_GEN3(1) | LVDCR1_CHSTBY_GEN3(0) |
-   LVDCR1_CLKSTBY_GEN3);
+   LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
+   LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
 
/*
 * Turn the PLL on, set it to LVDS normal mode, wait for the startup
Index: linux/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h
+++ linux/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h
@@ -26,10 +26,8 @@
 
 #define LVDCR1 0x0004
 #define LVDCR1_CKSEL   (1 << 15)   /* Gen2 only */
-#define LVDCR1_CHSTBY_GEN2(n)  (3 << (2 + (n) * 2))/* Gen2 only */
-#define LVDCR1_CHSTBY_GEN3(n)  (1 << (2 + (n) * 2))/* Gen3 only */
-#define LVDCR1_CLKSTBY_GEN2(3 << 0)/* Gen2 only */
-#define LVDCR1_CLKSTBY_GEN3(1 << 0)/* Gen3 only */
+#define LVDCR1_CHSTBY(n)   (3 << (2 + (n) * 2))
+#define LVDCR1_CLKSTBY (3 << 0)
 
 #define LVDPLLCR   0x0008
 #define LVDPLLCR_CEEN  (1 << 14)

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

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

[bugzilla-daemon]

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

--- Comment #4 from mikita.lip...@amd.com  ---
Encountering a deadlock in DRM while trying to force disable CRTCs.
If no displays connected - system hard hangs.
If DC is disabled (any number of displays) - system hard hangs.

Currently investigating the deadlock issue.
Thanks

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

Re: AMD DC test results

[Harry Wentland]

Hi Drake,

thanks for your extensive testing, solid test results, and help in tracking 
bugs across multiple branches. These results are quite helpful.

If you have any questions don't hesitate to let us know.

Btw, great job you're doing with Endless OS. I've never tried it but I like 
your approach for a free, accessible OS for the masses.

Harry

On 2017-12-21 08:45 AM, Daniel Drake wrote:
> Hi,
> 
> Thanks for the hard work on AMD DC development! Here are some new test
> results - hope they are interesting/useful.
> 
> 
> CONTEXT
> 
> We have been tracking DC for a while as we work with multiple products
> where amdgpu previously was not able to support the HDMI audio output.
> We are hoping to ship the new driver as soon as possible to fix this
> Linux compatibility issue.
> 
> 
> TEST SETUP
> 
> With an eye to shipping this ASAP, we backported DC to the current
> stable release, Linux 4.14. To do this we took the amdgpu/DC commits
> from:
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=upstream-4.14-drm-next-amd-dc-staging-chrome
> 
> And added these two pull requests:
> https://www.spinics.net/lists/dri-devel/msg156828.html
> https://lists.freedesktop.org/archives/dri-devel/2017-November/157687.html
> 
> At this point we diff the resultant amdgpu directories with Linus tree
> as of commit f6705bf959efac87bca76d40050d342f1d212587 (when he
> accepted the DC driver) and the diff is zero. This is published on the
> master branch of https://github.com/endlessm/linux
> 
> There have been more AMD DC changes merged into Linus tree since then,
> however we tried and the backporting seems like loads of work, so we
> have not gone beyond the initial merge into Linus tree for now.
> 
> We then asked our QA team to run our standard tests with this kernel.
> They tested 3 platforms:
> Acer Aspire E5-553G (AMD FX-9800P RADEON R7)
> Acer Aspire E5-523G (AMD E2-9010 RADEON R2)
> Acer Aspire A315-21 (AMD A4-9120 RADEON R3)
> 
> CONFIG_DRM_AMD_DC_PRE_VEGA was set in order to have AMD DC support
> this hardware.
> 
> 
> TEST RESULTS
> 
> HDMI audio works now, however we have encountered some regressions. In
> all cases the 3 platforms behaved the same (either all 3 pass the
> individual tests, or all 3 show the same problem). The regressions
> are:
> 
> 1. System hangs on S3 resume.
> Bug can't be reproduced when booting with amdgpu.dc=0
> Also reproduced with DC on Linus master (4.15-rc), but appears fixed
> on agd5f/amd-staging-drm-next
> https://bugs.freedesktop.org/show_bug.cgi?id=104281
> 
> 2. Display corruption when using multiple displays
> Bug can't be reproduced when booting with amdgpu.dc=0
> Also reproduced with DC on Linus master (4.15-rc), but appears fixed
> on agd5f/amd-staging-drm-next
> https://bugs.freedesktop.org/show_bug.cgi?id=104319
> 
> 3. HDMI audio device still shown as present and active even after
> disconnecting HDMI cable
> Bug can't be reproduced when booting with amdgpu.dc=0
> Appears fixed with DC on Linus master (4.15-rc).
> 
> Full test results spreadsheet (including tests passed): http://goo.gl/oqnMDx
> Thanks to my colleagues: Carlo Caione for doing the backport and
> Vanessa Chang for managing the testing.
> 
> 
> NEXT STEPS
> 
> Unfortunately we can't ship the driver in current state with these
> regressions, but on the positive side it looks like it will be in
> better shape for Linux 4.16.
> 
> We will now focus on making 4.15 regression-free before revisiting the
> idea of backporting DC to earlier kernels.
> 
> After the holiday break we will try to identify the relevant fixes in
> amd-staging-drm-next and see if they can be included in Linux 4.15.
> We'll send these backports upstream as soon as we find them.
> 
> 
> Daniel
> ___
> 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 v3 3/3] drm/tinydrm: add driver for ST7735R panels

[David Lechner]

On 12/21/2017 01:23 PM, David Lechner wrote:

This adds a new driver for Sitronix ST7735R display panels.

This has been tested using an Adafruit 1.8" TFT.

Signed-off-by: David Lechner 
---





+   mipi_dbi_command(mipi, ST7735R_GAMCTRP1, 0x0f, 0x1a, 0x0f, 0x18, 0x2f,
+0x28, 0x20, 0x22, 0x1f, 0x1b, 0x23, 0x37, 0x00, 0x07,
+0x02, 0x10);
+   mipi_dbi_command(mipi, ST7735R_GAMCTRN1, 0x0f, 0x1b, 0x0f, 0x17, 0x33,
+0x2c, 0x29, 0x2e, 0x30, 0x30, 0x39, 0x3f, 0x00, 0x07,
+0x03, 0x10);
By the way, how do you know what is the "right" gamma curve? I think I 
copied this from the generic st7735r driver in fbtft, but I noticed that 
there is also a different curve for the Adafruit 1.8" display in fbtft. 
I'm wondering if I should have used that one instead. I can't really 
tell a difference looking at the display.

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

[PATCH v3 3/3] drm/tinydrm: add driver for ST7735R panels

[David Lechner]

This adds a new driver for Sitronix ST7735R display panels.

This has been tested using an Adafruit 1.8" TFT.

Signed-off-by: David Lechner 
---

v3 changes:
* Changed compatible string
* use SPDX license header
* Renamed mode struct to use panel name instead of controller name

v2 changes:
* Change delay from 10ms to 20ms to avoid checkpatch warning
* Use mipi_dbi_pipe_enable()/mipi_dbi_pipe_disable() to reduce duplicated code
* Rebase on drm-misc-next (tinydrm_lastclose => drm_fb_helper_lastclose)
* Use mipi_dbi_debugfs_init
* Add mipi->read_commands = NULL; since this display is write-only


 MAINTAINERS   |   6 ++
 drivers/gpu/drm/tinydrm/Kconfig   |  10 ++
 drivers/gpu/drm/tinydrm/Makefile  |   1 +
 drivers/gpu/drm/tinydrm/st7735r.c | 215 ++
 4 files changed, 232 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/st7735r.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 91268cb..95e98e2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4556,6 +4556,12 @@ S:   Maintained
 F: drivers/gpu/drm/tinydrm/st7586.c
 F: Documentation/devicetree/bindings/display/st7586.txt
 
+DRM DRIVER FOR SITRONIX ST7735R PANELS
+M: David Lechner 
+S: Maintained
+F: drivers/gpu/drm/tinydrm/st7735r.c
+F: Documentation/devicetree/bindings/display/st7735r.txt
+
 DRM DRIVER FOR TDFX VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 90c5bd5..b0e567d 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -52,3 +52,13 @@ config TINYDRM_ST7586
  * LEGO MINDSTORMS EV3
 
  If M is selected the module will be called st7586.
+
+config TINYDRM_ST7735R
+   tristate "DRM support for Sitronix ST7735R display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver Sitronix ST7735R with one of the following LCDs:
+ * JD-T18003-T01 1.8" 128x160 TFT
+
+ If M is selected the module will be called st7735r.
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 8aeee53..49a1119 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_TINYDRM_ILI9225)   += ili9225.o
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
 obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
+obj-$(CONFIG_TINYDRM_ST7735R)  += st7735r.o
diff --git a/drivers/gpu/drm/tinydrm/st7735r.c 
b/drivers/gpu/drm/tinydrm/st7735r.c
new file mode 100644
index 000..0b05b2c
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Sitronix ST7735R panels
+ *
+ * Copyright 2017 David Lechner 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define ST7735R_FRMCTR10xb1
+#define ST7735R_FRMCTR20xb2
+#define ST7735R_FRMCTR30xb3
+#define ST7735R_INVCTR 0xb4
+#define ST7735R_PWCTR1 0xc0
+#define ST7735R_PWCTR2 0xc1
+#define ST7735R_PWCTR3 0xc2
+#define ST7735R_PWCTR4 0xc3
+#define ST7735R_PWCTR5 0xc4
+#define ST7735R_VMCTR1 0xc5
+#define ST7735R_GAMCTRP1   0xe0
+#define ST7735R_GAMCTRN1   0xe1
+
+#define ST7735R_MY BIT(7)
+#define ST7735R_MX BIT(6)
+#define ST7735R_MV BIT(5)
+
+static void st7735r_pipe_enable(struct drm_simple_display_pipe *pipe,
+   struct drm_crtc_state *crtc_state)
+{
+   struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+   struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+   struct device *dev = tdev->drm->dev;
+   int ret;
+   u8 addr_mode;
+
+   DRM_DEBUG_KMS("\n");
+
+   mipi_dbi_hw_reset(mipi);
+
+   ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
+   return;
+   }
+
+   msleep(150);
+
+   mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+   msleep(500);
+
+   mipi_dbi_command(mipi, ST7735R_FRMCTR1, 0x01, 0x2c, 0x2d);
+   mipi_dbi_command(mipi, ST7735R_FRMCTR2, 0x01, 0x2c, 0x2d);
+   mipi_dbi_command(mipi, ST7735R_FRMCTR3, 0x01, 0x2c, 0x2d, 0x01, 0x2c,
+0x2d);
+   mipi_dbi_command(mipi, ST7735R_INVCTR, 0x07);
+   mipi_dbi_command(mipi, ST7735R_PWCTR1, 0xa2, 0x02, 0x84);
+   mipi_dbi_command(mipi, ST7735R_PWCTR2, 0xc5);
+   mipi_dbi_command(mipi, ST7735R_PWCTR3, 0x0a, 0x00);
+   mipi_dbi_command(mipi, ST7735R_PWCTR4, 0x8a, 0x2a);
+   mipi_dbi_command(mipi, ST7735R_PWCTR5, 0x8a, 0xee);
+   mipi_dbi_command(mipi, 

[PATCH v3 1/3] dt-bindings: add jianda vendor prefix

[David Lechner]

This adds a vendor prefix "jianda" for Jiandangjing Technology Co., Ltd.

Signed-off-by: David Lechner 
---

v3 changes:
* new patch in v3

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 41cb1ff0..fea7903 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -172,6 +172,7 @@ issiIntegrated Silicon Solutions Inc.
 itead  ITEAD Intelligent Systems Co.Ltd
 iwave  iWave Systems Technologies Pvt. Ltd.
 jdiJapan Display Inc.
+jianda Jiandangjing Technology Co., Ltd.
 jedec  JEDEC Solid State Technology Association
 karo   Ka-Ro electronics GmbH
 keithkoep  Keith & Koep GmbH
-- 
2.7.4

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

[PATCH v3 2/3] dt-bindings: Add binding for Sitronix ST7735R display panels

[David Lechner]

This adds a new device tree binding for Sitronix ST7735R display panels,
such as the Adafruit 1.8" TFT.

Signed-off-by: David Lechner 
---

v3 changes:
* compatible string is changed from "sitronix,st7735r-jd-t18003-t01" to
"jianda,jd-t18003-t01", "sitronix,st7735r"

v2 changes:
* none

 .../bindings/display/sitronix,st7735r.txt  | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7735r.txt

diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.txt 
b/Documentation/devicetree/bindings/display/sitronix,st7735r.txt
new file mode 100644
index 000..f0a5090
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.txt
@@ -0,0 +1,35 @@
+Sitronix ST7735R display panels
+
+This binding is for display panels using a Sitronix ST7735R controller in SPI
+mode.
+
+Required properties:
+- compatible:  "jianda,jd-t18003-t01", "sitronix,st7735r"
+- dc-gpios:Display data/command selection (D/CX)
+- reset-gpios: Reset signal (RSTX)
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+- backlight:   phandle of the backlight device attached to the panel
+
+Example:
+
+   backlight: backlight {
+   compatible = "gpio-backlight";
+   gpios = < 44 GPIO_ACTIVE_HIGH>;
+   }
+
+   ...
+
+   display@0{
+   compatible = "jianda,jd-t18003-t01", "sitronix,st7735r";
+   reg = <0>;
+   spi-max-frequency = <3200>;
+   dc-gpios = < 43 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
+   rotation = <270>;
+   backlight = 
+   };
-- 
2.7.4

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

[PATCH v3 0/3] DRM driver for Sitronix ST7735R display panels

[David Lechner]

This series adds a new DRM/TinyDRM driver for Sitronix ST7735R, specifically
the Adafruit 1.8" TFT.

Nothing fancy here. Just mostly TinyDRM boilerplate with the init sequence
from the fbtft driver for the same panel.

v3 changes:
* New patch for jianda vendor prefix
* Change compatible string in DT bindings (dropped ACK because of this)
* Use SPDX license ID

David Lechner (3):
  dt-bindings: add jianda vendor prefix
  dt-bindings: Add binding for Sitronix ST7735R display panels
  drm/tinydrm: add driver for ST7735R panels

 .../bindings/display/sitronix,st7735r.txt  |  35 
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 MAINTAINERS|   6 +
 drivers/gpu/drm/tinydrm/Kconfig|  10 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/st7735r.c  | 215 +
 6 files changed, 268 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7735r.txt
 create mode 100644 drivers/gpu/drm/tinydrm/st7735r.c

-- 
2.7.4

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

[Bug 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

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

Bug ID: 104362
   Summary: GPU fault detected on wine-nine Path of Exile
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: granti...@gmail.com

Created attachment 136347
  --> https://bugs.freedesktop.org/attachment.cgi?id=136347=edit
dmesg log

When i start game Path of Exile on wine-nine computer freez.
I can`t switch in kernel console.
When i connect on ssh i can get dmesg output.

Radeon HD 7950 (TAHITI)

kernel 4.13.4 - 4.14.6
kernel module AMDGPU

Mesa 17.2.1 - 17.3.1

wine-nine 2.20 - 2.21

-- 
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] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Manasi Navare]

On Wed, Dec 20, 2017 at 10:36:24PM -0800, Dhinakaran Pandiyan wrote:
> Occasionally there are LINK_ADDRESS sideband messages timing out with the
> Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> failures lead to the display not coming up on boot. Power cycling the port
> corresponding to the MST monitor's branch device and resending the message
> fixes the issue. I am not entirely sure if this is specific to my setup.
> However, as the power state is toggled conditionally on LINK_ADDRESS
> timeouts, this should not affect the working cases.
> 

> Cc: Lyude 
> Cc: Dave Airlie 
> Cc: Jani Nikula 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 70dcfa58d3c2..e06defcdcf18 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> drm_dp_mst_topology_mgr *mgr,
>   int len;
>   struct drm_dp_sideband_msg_tx *txmsg;
>   int ret;
> + int attempts = 5;
>

Does the spec say this should be retried 5 times or is this just an
experimental number?
We have such magical numbers for retries all over the DP code and that makes 
debugging
harder later, so atleast a comment of why its 5 would help.
  
> - txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> +retry:   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
>   if (!txmsg)
>   return;
>  
> @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> drm_dp_mst_topology_mgr *mgr,
>   }
>   (*mgr->cbs->hotplug)(mgr);
>   }
> + } else if (attempts--) {

This should be --attempts if you want the total attempts to be 5

Manasi

> + kfree(txmsg);
> + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> +  false);
> + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> +  true);
> + DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);
> + goto retry;
>   } else {
>   mstb->link_address_sent = false;
> - DRM_DEBUG_KMS("link address failed %d\n", ret);
> + DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
>   }
>  
>   kfree(txmsg);
> -- 
> 2.11.0
> 
> ___
> 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

[PATCH] drm: fix tainted kernel caused by drm_panel_orientation_quirks.c

[David Lechner]

drm_panel_orientation_quirks.c introduced in commit 404d1a3edc38 ("drm:
Add panel orientation quirks, v6.") taints the kernel when compiled as a
module. Fix this by adding MODULE_LICENSE().

Signed-off-by: David Lechner 
---
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 901a4e9..1f2af70 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -9,6 +9,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #ifdef CONFIG_DMI
@@ -172,3 +173,5 @@ int drm_get_panel_orientation_quirk(int width, int height)
 EXPORT_SYMBOL(drm_get_panel_orientation_quirk);
 
 #endif
+
+MODULE_LICENSE("Dual MIT/GPL");
-- 
2.7.4

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

[PATCH 3/3] drm/tinydrm: Update ILI9225 compatible string

[David Lechner]

This updates the compatible string for a no-name LCD panel to
"vot,v220hf01a-t", "ilitek,ili9225".

The original bindings were the generic "ilitek,ili9225-2.2in-176x220"
because I could not find a datasheet. However, after some more research,
I finally found one, so the actual vendor and model name are now known.

This previous bindings have not made it to the mainline kernel yet, so
this is not breaking backwards compatibility.

Signed-off-by: David Lechner 
---
 drivers/gpu/drm/tinydrm/ili9225.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index e8f1b3a..c0cf498 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -391,13 +391,13 @@ static struct drm_driver ili9225_driver = {
 };
 
 static const struct of_device_id ili9225_of_match[] = {
-   { .compatible = "ilitek,ili9225-2.2in-176x220" },
+   { .compatible = "vot,v220hf01a-t" },
{},
 };
 MODULE_DEVICE_TABLE(of, ili9225_of_match);
 
 static const struct spi_device_id ili9225_id[] = {
-   { "ili9225-2.2in-176x220", 0 },
+   { "v220hf01a-t", 0 },
{ },
 };
 MODULE_DEVICE_TABLE(spi, ili9225_id);
-- 
2.7.4

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

[PATCH 1/3] dt-bindings: Add "vot" vendor prefix

[David Lechner]

This adds a vendor prefix "vot" for Vision Optical Technology Co., Ltd.
They make LCD displays.

Signed-off-by: David Lechner 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 41cb1ff0..267d33b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -380,6 +380,7 @@ virtio  Virtual I/O Device Specification, developed by 
the OASIS consortium
 vivanteVivante Corporation
 vocore VoCore Studio
 voipac Voipac Technologies s.r.o.
+votVision Optical Technology Co., Ltd.
 wd Western Digital Corp.
 wetek  WeTek Electronics, limited.
 wexler Wexler
-- 
2.7.4

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

[PATCH 0/3] update compatible string for ILI9225

[David Lechner]

This updates the device tree compatible string for an ILI9225 display.
Detailed explanation is in the patches.

David Lechner (3):
  dt-bindings: Add "vot" vendor prefix
  dt-bindings: update compatible string for ILI9225
  drm/tinydrm: Update ILI9225 compatible string

 Documentation/devicetree/bindings/display/ilitek,ili9225.txt | 4 ++--
 Documentation/devicetree/bindings/vendor-prefixes.txt| 1 +
 drivers/gpu/drm/tinydrm/ili9225.c| 4 ++--
 3 files changed, 5 insertions(+), 4 deletions(-)

-- 
2.7.4

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

[PATCH 2/3] dt-bindings: update compatible string for ILI9225

[David Lechner]

This updates the compatible string for a no-name LCD panel to
"vot,v220hf01a-t", "ilitek,ili9225".

The original bindings [1] were the generic "ilitek,ili9225-2.2in-176x220"
because I could not find a datasheet. However, after some more research,
I finally found one, so the actual vendor and model name are now known.

This previous bindings have not made it to the mainline kernel yet, so
this is not breaking backwards compatibility.

This is also following the precedence of the ILI9322 bindings [2] by using
the pattern "vendor,specific-system-config", "vendor,ip-part";

[1]: https://patchwork.ozlabs.org/patch/839352/
[2]: https://patchwork.ozlabs.org/patch/843576/

Signed-off-by: David Lechner 
---
 Documentation/devicetree/bindings/display/ilitek,ili9225.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9225.txt 
b/Documentation/devicetree/bindings/display/ilitek,ili9225.txt
index 21607a5..a59feb5 100644
--- a/Documentation/devicetree/bindings/display/ilitek,ili9225.txt
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9225.txt
@@ -4,7 +4,7 @@ This binding is for display panels using an Ilitek ILI9225 
controller in SPI
 mode.
 
 Required properties:
-- compatible:  "ilitek,ili9225-2.2in-176x220"
+- compatible:  "vot,v220hf01a-t", "ilitek,ili9225"
 - rs-gpios:Register select signal
 - reset-gpios: Reset pin
 
@@ -16,7 +16,7 @@ Optional properties:
 
 Example:
display@0{
-   compatible = "ilitek,ili9225-2.2in-176x220";
+   compatible = "vot,v220hf01a-t", "ilitek,ili9225";
reg = <0>;
spi-max-frequency = <1200>;
rs-gpios = < 9 GPIO_ACTIVE_HIGH>;
-- 
2.7.4

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

[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

[bugzilla-daemon]

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

--- Comment #8 from mikhail.v.gavri...@gmail.com ---
Created attachment 136346
  --> https://bugs.freedesktop.org/attachment.cgi?id=136346=edit
dmesg with 4.15.0-rc2 amd-staging-drm-next

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

[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

[bugzilla-daemon]

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

--- Comment #7 from mikhail.v.gavri...@gmail.com ---
With latest build in dmesg appear message when hang again occurs:
[  341.475043] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
last signaled seq=110200, last emitted seq=110202
[  341.475059] [drm] No hardware hang detected. Did some blocks stall?

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

[PATCH] drm/ttm: drop the spin in delayed delete if the trylock doesn't work

[Christian König]

Thomas actually noticed that, but I didn't realized what he meant until
now.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 60bb5c12b568..84dfa2368a72 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -592,6 +592,8 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
 
} else if (reservation_object_trylock(bo->resv)) {
ttm_bo_cleanup_refs(bo, false, !remove_all, true);
+   } else {
+   spin_unlock(>lru_lock);
}
 
kref_put(>list_kref, ttm_bo_release_list);
-- 
2.11.0

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

Re: [PATCH v3 2/5] drm/tegra: Restore opaque and drop alpha formats on Tegra20/30

[Dmitry Osipenko]

On 21.12.2017 17:10, Thierry Reding wrote:
> On Thu, Dec 21, 2017 at 01:38:31AM +0300, Dmitry Osipenko wrote:
>> On 21.12.2017 01:23, Dmitry Osipenko wrote:
>>> On 21.12.2017 01:02, Thierry Reding wrote:
 On Thu, Dec 21, 2017 at 12:05:40AM +0300, Dmitry Osipenko wrote:
> On 20.12.2017 23:16, Thierry Reding wrote:
>> On Wed, Dec 20, 2017 at 11:01:49PM +0300, Dmitry Osipenko wrote:
>>> On 20.12.2017 21:01, Thierry Reding wrote:
 On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
> Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats") broke
> DRM's MODE_ADDFB IOCTL on Tegra20/30, because IOCTL uses XRGB format 
> if
> requested FB depth is 24bpp. As a result, Xorg doesn't work anymore 
> with
> both modesetting and opentegra drivers. On older Tegra's each plane 
> has
> a blending configuration which should be used to enable / disable 
> alpha
> blending and right now the blending configs are hardcoded to disabled
> alpha blending. In order to support alpha formats properly, planes
> blending configuration must be adjusted, until then the alpha formats
> are equal to non-alpha.
>
> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/gpu/drm/tegra/dc.c| 29 ++---
>  drivers/gpu/drm/tegra/dc.h|  1 +
>  drivers/gpu/drm/tegra/fb.c| 13 -
>  drivers/gpu/drm/tegra/hub.c   |  3 ++-
>  drivers/gpu/drm/tegra/plane.c | 22 +-
>  drivers/gpu/drm/tegra/plane.h |  2 +-
>  6 files changed, 39 insertions(+), 31 deletions(-)

 This kept bugging me, so I spent some time looking at the blending
 programming. I came up with the attached patch which seems to work
 for all scenarios and is fairly similar to your patch. It has the
 added benefit that we can keep support for more formats.

 Any comments?

 Thierry
 --- >8 ---
 From 3d2b7d1a9b8239dc6940477d8783461ac60783bc Mon Sep 17 00:00:00 2001
 From: Thierry Reding 
 Date: Wed, 20 Dec 2017 09:39:14 +0100
 Subject: [PATCH] drm/tegra: dc: Implement legacy blending

 This implements alpha blending on legacy display controllers (Tegra20,
 Tegra30 and Tegra114). While it's theoretically possible to support the
 zpos property to enable userspace to specify the Z-order of each plane
 individually, this is not currently supported and the same fixed Z-
 order as previously defined is used.
>>>
>>> Perhaps one variant of implementing zpos could be by making overlays 
>>> 'virtual',
>>> so each virtual overlay will be backed by the real HW plane and we 
>>> could swap
>>> the HW planes of the virtual overlays, emulating zpos.
>>>
 Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") 
 since
 the opaque formats are now supported.

 Reported-by: Dmitry Osipenko 
 Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
 Signed-off-by: Thierry Reding 
 ---
  drivers/gpu/drm/tegra/dc.c| 74 
 ++-
  drivers/gpu/drm/tegra/dc.h| 13 
  drivers/gpu/drm/tegra/fb.c| 12 ---
  drivers/gpu/drm/tegra/plane.c | 41 
  drivers/gpu/drm/tegra/plane.h |  3 ++
  5 files changed, 116 insertions(+), 27 deletions(-)

 diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
 index bc65c314e00f..07c687d7f615 100644
 --- a/drivers/gpu/drm/tegra/dc.c
 +++ b/drivers/gpu/drm/tegra/dc.c
 @@ -168,32 +168,46 @@ static inline u32 compute_initial_dda(unsigned 
 int in)
return dfixed_frac(inf);
  }
  
 -static void tegra_plane_setup_blending_legacy(struct tegra_plane 
 *plane)
 +static void
 +tegra_plane_setup_blending_legacy(struct tegra_plane *plane,
 +const struct tegra_dc_window *window)
  {
 +  u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
 +   BLEND_COLOR_KEY_NONE;
 +  u32 background = BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) |
 +   BLEND_COLOR_KEY_NONE;
 +  u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
 +
 +  /* enable alpha blending if window->alpha */
 +  if (window->alpha) {
 +  background |= BLEND_CONTROL_DEPENDENT;
 +

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Philip Müller]

Hi Max,

from Manjaro-side we have implemented it now in our v4.14 kernel series
and started to test out some themes. Current progress and feedback may
be found in our forum:

https://forum.manjaro.org/t/bootsplash-provided-by-the-kernel/34467

Best, Philip

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

[PATCH] drm/sun4i: hdmi: Fix sun4i_tmds_determine_rate

[Jonathan Liu]

There are several issues in sun4i_tmds_determine_rate:
- doesn't check if the best match was already set before comparing it
  with the enumerated parameters which could result in integer divide
  by zero
- doesn't consider rate halving when determining closest match if it
  can't match the requested rate exactly
- sets best_div to i which corresponds to rate halving when it should be
  set to j which corresponds to the divider

Fix these issues.

Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Jonathan Liu 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
index dc332ea56f6c..3ecffa52c814 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
@@ -102,10 +102,13 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
goto out;
}
 
-   if (abs(rate - rounded / i) <
-   abs(rate - best_parent / best_div)) {
+   if (!best_parent ||
+   abs(rate - rounded / i / j) <
+   abs(rate - best_parent / best_half /
+   best_div)) {
best_parent = rounded;
-   best_div = i;
+   best_half = i;
+   best_div = j;
}
}
}
-- 
2.15.0

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

[Bug 104306] Mesa 17.3 breaks Firefox and other Xwayland apps on AMD HD7750

[bugzilla-daemon]

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

--- Comment #6 from eric vz  ---
Created attachment 136345
  --> https://bugs.freedesktop.org/attachment.cgi?id=136345=edit
Hung glxinfo backtrace

gnome-shell 3.26.2+9+ga3736d3a3-1
xorg-server-xwayland 1.19.5-1

Backtrace attached.  I've also got strace output if it would be useful.  Thanks
for your help!

-- 
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 v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight

[Noralf Trønnes]

Den 21.12.2017 15.08, skrev Daniel Vetter:

On Thu, Dec 21, 2017 at 2:44 PM, Noralf Trønnes  wrote:

Den 21.12.2017 14.05, skrev Daniel Vetter:

On Thu, Dec 21, 2017 at 11:52:43AM +0100, Noralf Trønnes wrote:

Den 11.12.2017 18.56, skrev Noralf Trønnes:

Den 11.12.2017 18.45, skrev Noralf Trønnes:

Den 11.12.2017 15.58, skrev Meghana Madhyastha:

On Mon, Dec 11, 2017 at 03:12:06PM +0100, Noralf Trønnes wrote:

Den 11.12.2017 14.17, skrev Meghana Madhyastha:

On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:

Den 21.10.2017 13.55, skrev Meghana Madhyastha:

Changes in v14:
- s/backlight_get/of_find_backlight/ in patch 2/3
- Change commit message in patch 3/3 from requiring to acquiring

Meghana Madhyastha (3):
 drm/tinydrm: Move helper functions from
tinydrm-helpers to backlight.h
 drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
 drm/tinydrm: Add devres versions of of_find_backlight

I tried the patchset and this is what I got:

[8.057792] Unable to handle kernel paging
request at virtual address
fe6b



[9.144181] ---[ end trace 149c05934b6a6dcc ]---

Is the reason possibly because we have omitted error checking on the
return value of backlight_enable function ?
tinydrm_enable_backlight and
tinydrm_disable_baclight do this.
Eg.
ret = backlight_update_status(backlight);
if (ret)
  DRM_ERROR("Failed to enable backlight %d\n", ret);

I'm not sure, just asking whether this could be a possible reason
for the above trace.

The crash happens during probe.
I guess you'll figure this out when you get some hw to test on.

I have set up the raspberry pi and have built and boot into the
custom kernel
but I am waiting for the panel to arrive. Meanwhile, any thoughts on
error message ? Sorry for the trivial question, but I did not quite
understand the crash message and how to replicate it.

of_find_backlight() can return an error pointer (-EPROBE_DEFER):

diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 4bb7bf3ee443..57370c5d51f0 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -635,8 +635,8 @@ struct backlight_device
*devm_of_find_backlight(struct device *dev)
  int ret;

  bd = of_find_backlight(dev);
-   if (!bd)
-   return NULL;
+   if (IS_ERR_OR_NULL(bd))
+   return bd;

  ret = devm_add_action(dev, devm_backlight_put, bd);
  if (ret) {

That solved the crash, but the backlight didn't turn on.
I had to do this as well:

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5c441d4c049c..6f9925f10a7c 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -139,6 +139,8 @@ static inline int backlight_enable(struct
backlight_device *bd)
  if (!bd)
  return 0;

+   if (!bd->props.brightness)
+   bd->props.brightness = bd->props.max_brightness;

No, this is wrong, it should happen on probe, not every time it's
enabled.
So maybe it should be done in of_find_backlight() or something.
I see that I'm currently doing it in tinydrm_of_find_backlight().


I'm not happy with this brightness hack of mine really.

Since I last looked at this I see that pwm_bl has gained the ability to
start in a power off state (pwm_backlight_initial_power_state()).
However the gpio_backlight driver doesn't do this. gpio_backlight has a
'default-on' property, but the problem is that it sets brightness, not
power state. So the absense of the property sets brightness to zero,
which makes the driver turn off backlight on probe. This seems to be
fine, but then systemd-backlight comes along and restores brightness
to 1, since that's what it was on shutdown. This turns on backlight and
now I have a glaring white uninitialized panel waiting for the display
driver to set it up.

This patch would solve my problem:

diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index e470da95d806..54bb722e1ea3 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -142,7 +142,8 @@ static int gpio_backlight_probe(struct
platform_device
*pdev)
  return PTR_ERR(bl);
  }

-   bl->props.brightness = gbl->def_value;
+   bl->props.brightness = 1;
+   bl->props.state = gbl->def_value ? 0 : BL_CORE_FBBLANK;
  backlight_update_status(bl);

  platform_set_drvdata(pdev, bl);

The problem is that this will most likely break 2 in-kernel users of
gpio-backlight which doesn't set the 'default-on' property:
arch/arm/boot/dts/omap4-var-dvk-om44.dts
arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts

AFAICT they rely on systemd-backlight to turn on backlight by setting
brightness to 1.

So maybe my hack is _the_ soulution after all, but I'm no expert on
the backlight subsystem and it's corner cases.

Can we fix the dts instead?


Isn't 

[PULL] drm-misc-next

[Gustavo Padovan]

Hi Dave,

Flushing out drm-misc-next before the holidays. Docs and fbdev work
here. We will skip a pull request next week, back in 2018!

Regards,

Gustavo

drm-misc-next-2017-12-21:
drm-misc-next for 4.16:

Core Changes:
- mostly doc updates and some fbdev improvements
The following changes since commit ca40cfc85e548424e39dc3aebe61873535ddf7b6:

  drm/atomic-helper: Make zpos property kerneldoc less misleading (2017-12-14 
14:20:35 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2017-12-21

for you to fetch changes up to 8d44e9e69aacecd522bb2797eb2febc5c6c46558:

  drm/framebuffer: Print task that allocated the fb in debug info. (2017-12-20 
15:30:17 +0100)


drm-misc-next for 4.16:

Core Changes:
- mostly doc updates and some fbdev improvements


Daniel Vetter (5):
  drm/edid: kerneldoc for is_hdmi2_sink
  drm/print: Unconfuse kerneldoc
  drm/syncobj: some kerneldoc polish
  drm/atomic: document how to handle driver private objects
  drm/doc: Move legacy kms helpers to the very end

Fabio Estevam (2):
  drm/stm: dsi: Remove unnecessary platform_get_resource() error check
  drm/stm: ltdc: Remove unnecessary platform_get_resource() error check

Maarten Lankhorst (1):
  drm/framebuffer: Print task that allocated the fb in debug info.

Noralf Trønnes (5):
  drm/fb-helper: Set/clear dev->fb_helper in dummy init/fini
  drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()
  drm/docs: Add todo entry for drm_fb_helper_fbdev_setup()
  drm/fb-helper: Update DOC with new helpers
  drm/fb-helper: Add drm_fb_helper_defio_init()

 Documentation/gpu/drm-kms-helpers.rst |  36 +++
 Documentation/gpu/drm-kms.rst |  14 ++-
 Documentation/gpu/todo.rst|  18 
 drivers/gpu/drm/drm_atomic.c  |  45 +++-
 drivers/gpu/drm/drm_edid.c|   5 +
 drivers/gpu/drm/drm_fb_helper.c   | 191 +++---
 drivers/gpu/drm/drm_framebuffer.c |   2 +
 drivers/gpu/drm/drm_syncobj.c |  45 +++-
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c |   5 -
 drivers/gpu/drm/stm/ltdc.c|   6 --
 include/drm/drm_atomic.h  |  32 ++
 include/drm/drm_fb_helper.h   |  38 +++
 include/drm/drm_framebuffer.h |   6 ++
 include/drm/drm_mode_config.h |   9 ++
 include/drm/drm_print.h   |   2 +-
 include/drm/drm_syncobj.h |  34 +++---
 16 files changed, 419 insertions(+), 69 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/21/2017 10:48 AM, Daniel Vetter wrote:
> Ok, here's my expectation:
> 
> - fix plymouth and driver loading
> 
> If the plymouth maintainer tells me that's impossible, I'll look at this
> again. And no, this does not require killing drivers with SIGBUS, at least
> not with drm. Meanwhile I don't think this RFC makes sense to be merged.
I'm afraid I don't understand. How would we best go about fixing this issue?



Thank you for your valuable feedback so far, I'll be looking into addressing 
the issues you've brought up.

For now, I'll be on vacation until January 2018, so it'll take a while until I 
get back to you.



Thanks and happy new year!

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

[Bug 104306] Mesa 17.3 breaks Firefox and other Xwayland apps on AMD HD7750

[bugzilla-daemon]

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

--- Comment #5 from Michel Dänzer  ---
I can't reproduce this with weston or gnome-shell.

Which Wayland compositor and which version of Xwayland are you using?

Can you get a gdb backtrace of glxinfo when it hangs?

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

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/21/2017 03:51 PM, Ray Strode wrote:
> Hi,
> 
> On Wed, Dec 20, 2017 at 11:44 AM Max Staudt  wrote:
>> It'd be nice to see this bug fixed, as it happens only occasionally (as is 
>> the nature of a
>> race condition), and was thus really hard to debug. I'm sure it can drive 
>> people insane,
>> as they try to find out whether they've disabled Ctrl-Alt-Fx in their 
>> xorg.conf, but really
>> it's Plymouth getting the system into a bad state. I probably owe a bald 
>> patch on my
>> head to this bug.
> Okay, reading through the code I do see how what you're describing could 
> happen.
> 
> I sketched out a patch here:
> 
> https://cgit.freedesktop.org/plymouth/commit/?h=fix-vt-management-on-deactivate=0b5b790d628f4c96e3ab9fbc0daba67a29b850da
> 
> that I think should fix it.  I need to do some testing with it (ideally rig up
> a reproducer) before I push it.

Hmm, I haven't looked at what manager->renderers_activated means, but from just 
looking at the diff, it looks like it could solve the problem. Please do test 
it though! I'm afraid I can't really tell you how to rig up a reproducer, since 
it's a race condition. Maybe a sleep() in gdm, and then forcefully emptying the 
udev queue?

Are you sure that process_udev_event (manager) will do the right thing?
Will it keep a list of events not processed?

What if a card is plugged in, then unplugged? Would Plymouth then handle the 
plugin first, see that the card isn't there, and fail gracefully? And will it 
handle the unplug gracefully if the card wasn't there in the first place?

Or what if I plug in two cards - it needs to keep a list of events for this 
case, otherwise it will only detect one card when it resumes udev processing.

Maybe these concerns are unnecessary - I haven't looked at the full Plymouth 
code since. Just ideas to keep in mind when rigging up the patch.


Thanks for looking into a fix!


>> This is exactly where the kernel bootsplash is useful. Since it starts even 
>> before any
>> userspace program is loaded, it can close this gap.
>>
>> I've even tried it in combination with Plymouth: Plymouth is just another 
>> graphical
>> application, so it simply pops up "on top", just like X would. The two 
>> splashes
>> integrate flawlessly.
> I just wish it used our modern graphics platform instead of the
> deprecated subsystem.

I see, and I share your concern that legacy interfaces should die.
But with the current architecture in the kernel, building it on DRM wouldn't 
make sense, sorry.
Also, it would exclude the efifb case, which is decidedly a design requirement.


>> One could argue that one could put all DRM drivers into the initrd. Ubuntu 
>> does this,
>> and the initrd is ~40 MB in size. Not nice.
> well, that 40mb isn't just graphics drivers...
> ╎❯ du -sh /lib/modules/`uname -r`/kernel/drivers/gpu
> 2.7M /lib/modules/4.14.6-300.fc27.x86_64/kernel/drivers/gpu
> 
> 3M isn't too awful.

Oh, true. Weird, then I must have gotten something mixed up. That means there's 
truly tons of stuff in that initrd.


> But really you have two choices as I see it:
> 
> 1) make the initrd support new hardware
> 2) make the initrd be taylored to a specific configuration.
> 
> I actually think ubuntu has it right by doing 1. it's going to give
> the best user experience.
> (not just with graphics but other new hardware too).

Yes. Except when the mechanism fails.

And it doesn't cover the time before the driver is loaded.


> But if you do 2) then it's not unreasonable if things break with new
> hardware.

Agreed.


> Now
> ideally, the breakage would be as isolated as possible.  I mean maybe
> it's okay if the
> boot splash breaks (or shows a text splash),

Yup.


> but it's not okay if the
> bootsplash sort of
> works using /dev/fb, but then causes Xorg to break.  So we should
> probably change
> plymouth to avoid falling back to /dev/fb in the case where new
> hardware got added.
> Could probably fix this by detecting if kms is around when the initrd
> is generated,
> and adding a config option to skip fb renderer in that case.  or
> something like that.

That's not possible. When generating the initrd, you don't know where it will 
actually be booted next.

Practical example: Last year's installation media on next year's hardware.


> But the easy answer is to just fix the initrd to have the graphics drivers.

See above - you can't guarantee that I'm afraid.

Unless the distro decides to not care about vesafb/efifb, and just show the 
text mode plymouth splash in case no KMS driver has been loaded until then. 
That's what Fedora does when booted on non-EFI machines, since it boots in VGA 
text (non-graphics) mode. But ideally, we'd have a graphical splash in as many 
cases as possible. If you boot your Fedora machine in a framebuffer mode, or in 
EFI mode, you'll unleash these issues.


>> So let's take SUSE. They don't have a finishing transition, the splash 
>> simply stops
>> and is hidden at once. Such a splash makes 

Re: [PATCH 2/3] drm/panel: Add Ilitek ILI9322 driver

[Thierry Reding]

On Thu, Dec 21, 2017 at 03:15:56PM +0100, Thierry Reding wrote:
> On Fri, Dec 01, 2017 at 05:16:58PM +0100, Linus Walleij wrote:
> > This adds support for the Ilitek ILI9322 QVGA (320x240)
> > TFT panel driver.
> > 
> > This panel driver supports serial or parallel RGB or
> > YUV input and also ITU-T BT.656 input streams.
> > 
> > The controller is combined with a physical panel and
> > configured through the device tree.
> > 
> > Cc: David Lechner 
> > Cc: Stefano Babic 
> > Cc: Ben Dooks 
> > Signed-off-by: Linus Walleij 
> > ---
> > ChangeLog v1->v2:
> > - Dropped all DT parsing code in favor of open-coding the
> >   display config on a per-system basis based on system-specific
> >   compatible strings, after feedback from the DT maintainers.
> > - Define a set of configs for the D-Link DIR-685 router.
> > - Tested on the D-Link DIR-685.
> > ---
> >  drivers/gpu/drm/panel/Kconfig|   8 +
> >  drivers/gpu/drm/panel/Makefile   |   1 +
> >  drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 962 
> > +++
> >  3 files changed, 971 insertions(+)
> >  create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9322.c
> 
> checkpatch.pl gives me these:
> 
>   -:30: WARNING: please write a paragraph that describes the config 
> symbol fully
>   #30: FILE: drivers/gpu/drm/panel/Kconfig:31:
>   +config DRM_PANEL_ILITEK_IL9322
> 
>   -:54: WARNING: added, moved or deleted file(s), does MAINTAINERS need 
> updating?
>   #54:
>   new file mode 100644
> 
>   -:130: CHECK: Prefer using the BIT macro
>   #130: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:72:
>   +#define ILI9322_ENTRY_PAL  (1 << 2)
> 
>   -:134: CHECK: Prefer using the BIT macro
>   #134: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:76:
>   +#define ILI9322_ENTRY_SERIAL_RGB_ALIGNED (1 << 4)
> 
>   -:196: CHECK: spaces preferred around that '|' (ctx:VxV)
>   #196: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:138:
>   +#define ILI9322_IF_CTRL_SYNC_DISABLED  (BIT(2)|BIT(3))
>  ^
> 
>   -:551: WARNING: msleep < 20ms can sleep for up to 20ms; see 
> Documentation/timers/timers-howto.txt
>   #551: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:493:
>   +   msleep(10);
> 
>   total: 0 errors, 3 warnings, 3 checks, 983 lines checked
> 
> I'd like to see at least the warnings fixed. You can probably skip the
> entry in MAINTAINERS, though. I don't mind fixing these up while
> applying, but I don't know what to put in Kconfig. If you can send out
> a short paragraph for me to include I'll add it when I apply.

Daniel just reminded me on IRC that you have commit rights to drm-misc,
so once you've fixed up the bulk of the checkpatch warnings (nevermind
those "prefer the BIT macro" checks), feel free to push this yourself
with my:

Acked-by: Thierry Reding 


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

[Bug 104193] [radeonsi] The Witcher 3 freezes the system with no attachments calls & transform feedback Wine patch

[bugzilla-daemon]

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

--- Comment #1 from Shmerl  ---
Interestingly, this freeze seems to be Polaris specific. Users with Vega cards
didn't manage to reproduce it. Same with older GCN 1.0 cards such as R9 M375
using amdgpu.ko.

So can it be a bug in amdgpu itself then?

-- 
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: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]

[Carroll, Lewis]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Thursday, December 21, 2017 5:07 AM
> To: Carroll, Lewis 
> Cc: Wentland, Harry ; dri-
> de...@lists.freedesktop.org
> Subject: Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma table
> [patch proposed]
> 
> On Thu, Dec 21, 2017 at 12:00:39AM +, Carroll, Lewis wrote:
> > The discussion sounds similar as well - related to load_lut() not being 
> > called.
> >
> > Perhaps after the drm-next-4.14 merge, whatever call stack used to cause
> > load_lut to always get called is now gone. Even if FB_VISUAL_TRUECOLOR
> > doesn't support a clut, some hardware may still need a default gamma lut
> > loaded (appears to be the case with the AST2500). Perhaps checking for
> > that profile and loading the default LUT prepared by
> > drm_mode_crtc_set_gamma_size when FB_VISUAL_TRUECOLOR...?
> 
> Yeah drivers should load that somehow. Unfortunately I'm going on
> vacations now, so I'm not going to fix anything anytime soon. Might be
> good to ping Peter Rosin, he did all the fbdev emulation gamma handling
> rework (which is the patch that removed the superflously-looking call to
> ->load_lut that some drivers relied on to have a consistent lut state).
> -Daniel

Enjoy the holidays.

Wonder if it would be better to just call load_lut after
drm_mode_crtc_set_gamma_size instead of adding a potentially
unnecessary DPMS ON event to the commit call-back as I did...? Or call
load_lut in the commit callback instead of the DPMS ON call...?

The first approach (calling load_lut after set_gamma_size) also works on
two test systems.

> 
> >
> > Lewis
> >
> > -Original Message-
> > From: Wentland, Harry
> > Sent: Wednesday, December 20, 2017 6:29 PM
> > To: Carroll, Lewis ; dri-
> de...@lists.freedesktop.org
> > Subject: Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma
> table [patch proposed]
> >
> > This looks similar to this bug that I spotted while finally going through my
> large dri-devel backlog: https://bugzilla.kernel.org/show_bug.cgi?id=198123
> >
> > The discussion continues here https://lists.freedesktop.org/archives/dri-
> devel/2017-December/160667.html
> >
> > Not sure if this is related but the symptoms sound quite similar.
> >
> > Harry
> >
> > On 2017-12-17 07:08 PM, Carroll, Lewis wrote:
> > > Happy Holidays.
> > >
> > >
> > >
> > > Test-driving Linux 4.14 from the Ubuntu Bionic repo on an AMD EPYC
> server using the A-Speed AST2500 BMC and the AST DRM driver and
> framebuffer console configured into the kernel, I have observed multiple
> systems where the analog VGA color palette for the framebuffer console is
> incorrect. Background is blue and all text colors other than white / gray are
> incorrect.
> > >
> > >
> > >
> > > Instrumenting the AST DRM driver, it seems the default gamma table isn't
> loaded to the silicon until there is a DPMS action. When there is a DPMS
> action other than DPMS OFF, the gamma table is loaded and all is well. On
> these boards, the kernel is not calling for a DPMS event at driver init so the
> gamma table is not loaded.
> > >
> > >
> > >
> > > The attached proposed patch adds a DPMS ON event to the commit
> callback after a kernel modeset call. This solves the problem, however there
> may be a better / more proper way to solve this.
> > >
> > >
> > >
> > > Assuming no one on the mailing list has hardware on which to verify this, 
> > > I
> am happy to be a test driver for any suggested fixes.
> > >
> > >
> > >
> > > Regards,
> > >
> > >
> > >
> > > Lewis Carroll
> > >
> > > Principal Solutions Architect
> > >
> > > AMD Enterprise Business Group
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > 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
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos

[Ville Syrjälä]

On Thu, Dec 21, 2017 at 04:31:47PM +0200, Tomi Valkeinen wrote:
> On 21/12/17 16:20, Ville Syrjälä wrote:
> > On Thu, Dec 21, 2017 at 03:44:56PM +0200, Tomi Valkeinen wrote:
> >> On 21/12/17 14:55, Ville Syrjälä wrote:
> >>> On Thu, Dec 21, 2017 at 02:11:00PM +0200, Peter Ujfalusi wrote:
>  Make sure that the primary plane will get normalized_zpos=0 if it's zpos 
>  is
>  set to 0, avoiding other planes to be placed in the background.
> >>>
> >>> Can you describe the actual "bad" configuration?
> >>>
> >>> Without knowing the details this looks like it's making things
> >>> more complicated for no particularly good reason. If you're worried
> >>> about clients that don't set zpos, then I think you should just
> >>> assign the default zpos values better and/or allocate the planes
> >>> in a better order. But it's definitely possible I'm missing the
> >>> reason why you're doing this.
> >>
> >> Let's say we have two displays and two planes. First display will use
> >> crtc0 and plane0 as primary plane, the second display crtc1, plane1. The
> >> zpos of primary planes will be set to 0 by default.
> >>
> >> The userspace wants to use the second display, with an overlay plane. So
> >> it takes the plane0 and moves it to crtc1. Now the second display has
> >> two planes with zpos 0, and normalize_zpos will fix it according to the
> >> plane id, i.e. the primary plane of the second display will be on top of
> >> the "overlay" plane.
> >>
> >> I don't think other default zpos values and/or allocating planes in
> >> better order can solve this.
> > 
> > Hmm. True. OTOH this messes up the simple "plane id is used to resolve
> > zpos conflicts" logic.
> > 
> > Also since you have multiple primary planes on the same crtc, which
> > primary plane is the "real primary" for the crtc? How would userspace
> > even determine that? I guess the rule could be that the primary planes
> > have to be registered in the same order as the crtcs?
> 
> Hmm, true.
> 
> >> If the userspace is required to understand and set zpos, then this patch
> >> is not needed. But at least in my test scripts I've hit this a few times 
> >> =).
> > 
> > I think it would be nice if we can just make it a rule that any
> > userspace that moves planes between crtcs has to know about zpos.
> > Otherwise it's pretty much pure luck what stacking order you would
> > get.
> 
> Yes, but how does the userspace know when it is moving planes between crtcs?
> 
> If the userspace knows this, then it knows which primary plane is for 
> which crtc, right?
> 
> And if it doesn't know this, then the userspace cannot associate any 
> plane to any crtc (except what it configures itself).
> 
> So... If using legacy modesetting (and non-universal planes), there's no 
> problem, primary planes are fixed and at low zpos. If using atomic 
> modesetting and universal planes, there's really no (default) 
> association between planes and crtcs, and "primary plane" doesn't have 
> much meaning. Is that correct?
> 
> If so... Then I guess the atomic modesetting client essentially randomly 
> picks which plane it uses as a "root plane" (if it even needs such), and 
> which planes as overlay planes? If that's the case, then this patch 
> doesn't quite fix the issue...

I'm not sure anyone has really thought how userspace would/should assign
planes to crtcs. My only idea so far has been the crtc and their
preferred primary planes should be registered in the same order. But
someone should then also implement that same policy in userspace when
it's trying to figure out which plane to use. There are other
heuristics it should probably use, like preferring to pick a primary
plane for any fullscreen surface.

I guess from functional point of view it shouldn't matter which plane
you pick as long as the plane's user visible capabilities are
sufficient. But there might be user invisible power saving features and
whatnot that only work with specific planes. So from that point of view
maybe the order in which the planes get registered is important. Or we
could maybe come up with some kind of plane usage hints in the uapi
which could help userspace decide?

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

Re: [PATCH v7 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

[Philippe CORNU]

Hi Nickey,


On 12/12/2017 02:10 AM, Nickey Yang wrote:
> From: Brian Norris 
> 
> Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> parent driver might need to own this. Instead, let's return our
> 'dw_mipi_dsi' object and have callers pass that back to us for removal.
> 
> Signed-off-by: Brian Norris 
> Signed-off-by: Nickey Yang 
> Link:https://patchwork.kernel.org/patch/10078493/
> 
> ---
> Changes
> 
> v4:
> - Add From tag,update subject line
> - keep patch "drm/stm: dsi: Adjust dw_mipi_dsi_probe and remove"
>in this piece together.
> 
> v5:
> - remove Review & Ack tag
> - fix remove() directly referencing the static
>dw_mipi_dsi_stm_plat_data struct.
> 
> v7:
> - add missing platform_set_drvdata in stm part.
> 
>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36 
> ++-
>   drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 12 ++---
>   include/drm/bridge/dw_mipi_dsi.h  | 17 -
>   3 files changed, 32 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index d9cca4f..c39c7dc 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -922,8 +922,6 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge 
> *bridge)
>   dsi->bridge.of_node = pdev->dev.of_node;
>   #endif
>   
> - dev_set_drvdata(dev, dsi);
> -
>   return dsi;
>   }
>   
> @@ -935,23 +933,16 @@ static void __dw_mipi_dsi_remove(struct dw_mipi_dsi 
> *dsi)
>   /*
>* Probe/remove API, used from platforms based on the DRM bridge API.
>*/
> -int dw_mipi_dsi_probe(struct platform_device *pdev,
> -   const struct dw_mipi_dsi_plat_data *plat_data)
> +struct dw_mipi_dsi *
> +dw_mipi_dsi_probe(struct platform_device *pdev,
> +   const struct dw_mipi_dsi_plat_data *plat_data)
>   {
> - struct dw_mipi_dsi *dsi;
> -
> - dsi = __dw_mipi_dsi_probe(pdev, plat_data);
> - if (IS_ERR(dsi))
> - return PTR_ERR(dsi);
> -
> - return 0;
> + return __dw_mipi_dsi_probe(pdev, plat_data);
>   }
>   EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);
>   
> -void dw_mipi_dsi_remove(struct platform_device *pdev)
> +void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
>   {
> - struct dw_mipi_dsi *dsi = platform_get_drvdata(pdev);
> -
>   mipi_dsi_host_unregister(>dsi_host);
>   
>   __dw_mipi_dsi_remove(dsi);
> @@ -961,31 +952,30 @@ void dw_mipi_dsi_remove(struct platform_device *pdev)
>   /*
>* Bind/unbind API, used from platforms based on the component framework.
>*/
> -int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder 
> *encoder,
> -  const struct dw_mipi_dsi_plat_data *plat_data)
> +struct dw_mipi_dsi *
> +dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
> +  const struct dw_mipi_dsi_plat_data *plat_data)
>   {
>   struct dw_mipi_dsi *dsi;
>   int ret;
>   
>   dsi = __dw_mipi_dsi_probe(pdev, plat_data);
>   if (IS_ERR(dsi))
> - return PTR_ERR(dsi);
> + return dsi;
>   
>   ret = drm_bridge_attach(encoder, >bridge, NULL);
>   if (ret) {
> - dw_mipi_dsi_remove(pdev);
> + dw_mipi_dsi_remove(dsi);
>   DRM_ERROR("Failed to initialize bridge with drm\n");
> - return ret;
> + return ERR_PTR(ret);
>   }
>   
> - return 0;
> + return dsi;
>   }
>   EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);
>   
> -void dw_mipi_dsi_unbind(struct device *dev)
> +void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi)
>   {
> - struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
> -
>   __dw_mipi_dsi_remove(dsi);
>   }
>   EXPORT_SYMBOL_GPL(dw_mipi_dsi_unbind);
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index e5b6310..c1ed691 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -66,6 +66,7 @@ enum dsi_color {
>   struct dw_mipi_dsi_stm {
>   void __iomem *base;
>   struct clk *pllref_clk;
> + struct dw_mipi_dsi *dmd;
>   };
>   
>   static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 val)
> @@ -290,6 +291,8 @@ static int dw_mipi_dsi_stm_probe(struct platform_device 
> *pdev)
>   if (!dsi)
>   return -ENOMEM;
>   
> + platform_set_drvdata(pdev, dsi);
> +

Why don't you simply use the original patch from Brian.
With your last update, platform_set_drvdata() is called early during the 
stm_probe() and this is not the "classic" way: most of the time we 
prefer calling platform_set_drvdata() at the end of the probe (or as 
close as possible of the end of the probe). I took few minutes to look 
into drm directory and it seems to be the classic way for most of the 

[Bug 104319] AMDGPU/DC: Internal display corrupted when connecting (mirroring/extending) an external monitor on HDMI

[bugzilla-daemon]

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

--- Comment #4 from Harry Wentland  ---
Thanks, Daniel. The fix should land for 4.16 then.

-- 
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 104281] black / corrupted screen when resuming from S3 [AMDGPU]

[bugzilla-daemon]

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

--- Comment #4 from Harry Wentland  ---
Thanks, Daniel. The fix should land for 4.16 then.

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

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Ray Strode]

Hi,

On Wed, Dec 20, 2017 at 11:44 AM Max Staudt  wrote:
> It'd be nice to see this bug fixed, as it happens only occasionally (as is 
> the nature of a
> race condition), and was thus really hard to debug. I'm sure it can drive 
> people insane,
> as they try to find out whether they've disabled Ctrl-Alt-Fx in their 
> xorg.conf, but really
> it's Plymouth getting the system into a bad state. I probably owe a bald 
> patch on my
> head to this bug.
Okay, reading through the code I do see how what you're describing could happen.

I sketched out a patch here:

https://cgit.freedesktop.org/plymouth/commit/?h=fix-vt-management-on-deactivate=0b5b790d628f4c96e3ab9fbc0daba67a29b850da

that I think should fix it.  I need to do some testing with it (ideally rig up
a reproducer) before I push it.

> This is exactly where the kernel bootsplash is useful. Since it starts even 
> before any
> userspace program is loaded, it can close this gap.
>
> I've even tried it in combination with Plymouth: Plymouth is just another 
> graphical
> application, so it simply pops up "on top", just like X would. The two 
> splashes
> integrate flawlessly.
I just wish it used our modern graphics platform instead of the
deprecated subsystem.

> One could argue that one could put all DRM drivers into the initrd. Ubuntu 
> does this,
> and the initrd is ~40 MB in size. Not nice.
well, that 40mb isn't just graphics drivers...
╎❯ du -sh /lib/modules/`uname -r`/kernel/drivers/gpu
2.7M /lib/modules/4.14.6-300.fc27.x86_64/kernel/drivers/gpu

3M isn't too awful.

But really you have two choices as I see it:

1) make the initrd support new hardware
2) make the initrd be taylored to a specific configuration.

I actually think ubuntu has it right by doing 1. it's going to give
the best user experience.
(not just with graphics but other new hardware too).

But if you do 2) then it's not unreasonable if things break with new
hardware. Now
ideally, the breakage would be as isolated as possible.  I mean maybe
it's okay if the
boot splash breaks (or shows a text splash), but it's not okay if the
bootsplash sort of
works using /dev/fb, but then causes Xorg to break.  So we should
probably change
plymouth to avoid falling back to /dev/fb in the case where new
hardware got added.
Could probably fix this by detecting if kms is around when the initrd
is generated,
and adding a config option to skip fb renderer in that case.  or
something like that.

But the easy answer is to just fix the initrd to have the graphics drivers.

> And even then, the initrd could be outdated for some reason. Maybe it's a 
> developer
> machine. Nobody would expect the boot to hang/fail because of this problem.
Right, ideally boot splash problems should never stop boot from proceeding.

> So let's take SUSE. They don't have a finishing transition, the splash simply 
> stops
> and is hidden at once. Such a splash makes sense to be shown instantly, right?
I don't think it makes sense for animations to lack transitions.
animations without
transitions look buggy or unfinished. they should fade out or finish
the loop, or
whatever.  If it's a static image it should fade to black or the
background color.

(going to be away from the computer for a few days after this message
so probably won't reply for a while to further discussion)
--Ray
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Attachment #136340|0   |1
is obsolete||

--- Comment #9 from Christian König  ---
Created attachment 136343
  --> https://bugs.freedesktop.org/attachment.cgi?id=136343=edit
Possible fix v2

Please try that one instead.

-- 
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 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos

[Tomi Valkeinen]

On 21/12/17 16:20, Ville Syrjälä wrote:

On Thu, Dec 21, 2017 at 03:44:56PM +0200, Tomi Valkeinen wrote:

On 21/12/17 14:55, Ville Syrjälä wrote:

On Thu, Dec 21, 2017 at 02:11:00PM +0200, Peter Ujfalusi wrote:

Make sure that the primary plane will get normalized_zpos=0 if it's zpos is
set to 0, avoiding other planes to be placed in the background.


Can you describe the actual "bad" configuration?

Without knowing the details this looks like it's making things
more complicated for no particularly good reason. If you're worried
about clients that don't set zpos, then I think you should just
assign the default zpos values better and/or allocate the planes
in a better order. But it's definitely possible I'm missing the
reason why you're doing this.


Let's say we have two displays and two planes. First display will use
crtc0 and plane0 as primary plane, the second display crtc1, plane1. The
zpos of primary planes will be set to 0 by default.

The userspace wants to use the second display, with an overlay plane. So
it takes the plane0 and moves it to crtc1. Now the second display has
two planes with zpos 0, and normalize_zpos will fix it according to the
plane id, i.e. the primary plane of the second display will be on top of
the "overlay" plane.

I don't think other default zpos values and/or allocating planes in
better order can solve this.


Hmm. True. OTOH this messes up the simple "plane id is used to resolve
zpos conflicts" logic.

Also since you have multiple primary planes on the same crtc, which
primary plane is the "real primary" for the crtc? How would userspace
even determine that? I guess the rule could be that the primary planes
have to be registered in the same order as the crtcs?


Hmm, true.


If the userspace is required to understand and set zpos, then this patch
is not needed. But at least in my test scripts I've hit this a few times =).


I think it would be nice if we can just make it a rule that any
userspace that moves planes between crtcs has to know about zpos.
Otherwise it's pretty much pure luck what stacking order you would
get.


Yes, but how does the userspace know when it is moving planes between crtcs?

If the userspace knows this, then it knows which primary plane is for 
which crtc, right?


And if it doesn't know this, then the userspace cannot associate any 
plane to any crtc (except what it configures itself).


So... If using legacy modesetting (and non-universal planes), there's no 
problem, primary planes are fixed and at low zpos. If using atomic 
modesetting and universal planes, there's really no (default) 
association between planes and crtcs, and "primary plane" doesn't have 
much meaning. Is that correct?


If so... Then I guess the atomic modesetting client essentially randomly 
picks which plane it uses as a "root plane" (if it even needs such), and 
which planes as overlay planes? If that's the case, then this patch 
doesn't quite fix the issue...


 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[ANNOUNCE] Wayland/Weston/Mesa HDR support (proof of concept)

[Ville Syrjälä]

Here's a quick proof of concept implementation of HDR support
for Wayland/Weston/Mesa.

I'm not posting this as patches right now because I'm not sure
that would do much good given how rough this is. But here are
all the repos/branches:
git://github.com/vsyrjala/wayland.git hdr_poc
git://github.com/vsyrjala/wayland-protocols.git hdr_poc
git://github.com/vsyrjala/weston.git hdr_poc
git://github.com/vsyrjala/mesa.git hdr_poc
git://github.com/vsyrjala/linux.git hdr_poc

The kernel HDR bits were partially done by Uma Shankar, the rest
I hacked together myself.

As far as Wayland protocol goes I'm adding three new
extensions (should probably just have one with several requests?):
- zwp_colorspace_v1 - Specify the primaries/whitepoint chromacities 
  and transfer function for a surface
- zwp_ycbcr_encoding_v1 - Specify the encoding for YCbCr surfaces
- zwp_hdr_metadata_v1 - Allow the client to pass HDR metadata to 
  the compositor
Note that I've not given any thought to how the compositor might
advertize its capabilities.

I also hacked in a bunch of 10bpc+ YCbCr support to the protocol and
Weston so that I can actually get some HDR video onto the screen.

On the Mesa side I've crudely implementated the following egl/vk
extesions:
- EXT_gl_colorspace_*
- EXT_surface_SMPTE2086_metadata
- EXT_surface_CTA861_3_metadata
  (sidenote: these egl extension don't seem to match CTA-861.3 nicely
   when it comes to the min/max luminance stuff)
- VK_EXT_hdr_metadata

VK_EXT_hdr_metadata I plugged in for anv only, but the implementation
is in the common wayland wsi code. Note that I haven't actually tested
the vulkan stuff at all because I don't talk Vulkan (at least not yet).

Also note that I've not connected up the HDR metadata pipeline 
properly. The client can provide the metadata, but the compositor
doesn't actually pass it on to the display. For the time being the
HDR metadata that gets passed to the display is partially specified
in weston.ini and partially just hardocded (see
libweston/compositor-drm.c).

The Weston implementation involves a bunch of shaders and matrices to
do the ycbcr->rgb, "degamma", csc for each surface, blend it all as
linear RGB into an fp16 fbo, and finally blit that out to the final
framebuffer while applying the ST2084 PQ transfer function in the
process.

The reason for the fp16 fbo is that we store the full 1 nits of
linear RGB. That needs plenty of precisions in the low end so your
regular 10bpc fb doesn't seem to cut it. And also the display gamma LUT
doesn't have enough input precision for it either. Sadly there's no
fixed function hardware in the GPU to do the ST2084 PQ when blending.
When the output is not HDR I do skip the fp16 fbo step and use the
gamma LUT in the display engine instead. 

Another approach to the precisions problem might be to not store the
entire 1 nits of linear, and just cut off the super bright stuff
(your display can't show it anyway). But I've not really bothered to
figure out how low in nits we'd have to go here, probably too low.
Maybe blending as sRGB and the doing sRGB->PQ with the gamma LUT might
help a little bit?

Ideally we would bypass this all for a single fullscreen HDR surface
and just pass the PQ encoded data directly through. But I've not
implemented that. In fact I even disable the buffer_age damage stuff
when using the fp16 fbo, so we'll recompose the entire screen every
time. Yeah, I'm lazy.

Another thought that occurred to me was that it shouldn't be too hard
to make Weston do some tone mapping when there's a HDR client and no
HDR screen. To that end I included the ACES colorspaces in my
colorspace list, but I didn't actually look into plugging the ACES tone
mapping curve into the shaders. Might be a fun excercise, even though
the practical applications might be close to nil. Probably better to
not advertize HDR/wide gamuts when we can't actually output the stuff,
and instead let the client do its own tone mapping.

OK, so what can you do with this? I've included a few test clients:
- simple-colorspace
  Just a copy of simple-egl but it uses the egl extension to specify
  the colorspace, and produces ST2084 PQ encoded data when asked
- simple-hdr-video
  Uses ffmpeg to decode video into shm buffers, and sets the 
  colorspace/ycbcr encoding etc. appropriately. Ie. this one can
  actually output HDR video

Here's a weston.ini snippet that gets you outputting HDR:
[core]
gbm-format=xrgb2101010

[output]
name=HDMI-A-2
colorspace=BT.2020
gamma=ST2084
max_sdr_nits=100

Hardware wise you'll need a HDR capable display obviously, and 
you'll need an Intel Geminilake GPU. Older Intel platforms don't
support the HDR infoframe, so the display wouldn't know what to do
with the data you're feeding it.

As for the future, right now I don't really have any solid plans on
continuing to develop this. I might dabble with it a bit more out of
curiosity, but I'm more hoping we can find other people to move this
forward properly.

-- 
Ville Syrjälä

Re: [PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos

[Ville Syrjälä]

On Thu, Dec 21, 2017 at 03:44:56PM +0200, Tomi Valkeinen wrote:
> On 21/12/17 14:55, Ville Syrjälä wrote:
> > On Thu, Dec 21, 2017 at 02:11:00PM +0200, Peter Ujfalusi wrote:
> >> Make sure that the primary plane will get normalized_zpos=0 if it's zpos is
> >> set to 0, avoiding other planes to be placed in the background.
> > 
> > Can you describe the actual "bad" configuration?
> > 
> > Without knowing the details this looks like it's making things
> > more complicated for no particularly good reason. If you're worried
> > about clients that don't set zpos, then I think you should just
> > assign the default zpos values better and/or allocate the planes
> > in a better order. But it's definitely possible I'm missing the
> > reason why you're doing this.
> 
> Let's say we have two displays and two planes. First display will use 
> crtc0 and plane0 as primary plane, the second display crtc1, plane1. The 
> zpos of primary planes will be set to 0 by default.
> 
> The userspace wants to use the second display, with an overlay plane. So 
> it takes the plane0 and moves it to crtc1. Now the second display has 
> two planes with zpos 0, and normalize_zpos will fix it according to the 
> plane id, i.e. the primary plane of the second display will be on top of 
> the "overlay" plane.
> 
> I don't think other default zpos values and/or allocating planes in 
> better order can solve this.

Hmm. True. OTOH this messes up the simple "plane id is used to resolve
zpos conflicts" logic.

Also since you have multiple primary planes on the same crtc, which
primary plane is the "real primary" for the crtc? How would userspace
even determine that? I guess the rule could be that the primary planes
have to be registered in the same order as the crtcs?

> 
> If the userspace is required to understand and set zpos, then this patch 
> is not needed. But at least in my test scripts I've hit this a few times =).

I think it would be nice if we can just make it a rule that any
userspace that moves planes between crtcs has to know about zpos.
Otherwise it's pretty much pure luck what stacking order you would
get.

And my idea for planes that can move between crtcs is that the default
zpos should be assigned globally, probably matching the plane id
order as well. Ie. no two planes would default to the same zpos
value. And only in case of hardware that has no planes that can
move between crtcs you would allocate the default zpos per-crtc.

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

Re: [PATCH 2/3] drm/panel: Add Ilitek ILI9322 driver

[Thierry Reding]

On Fri, Dec 01, 2017 at 05:16:58PM +0100, Linus Walleij wrote:
> This adds support for the Ilitek ILI9322 QVGA (320x240)
> TFT panel driver.
> 
> This panel driver supports serial or parallel RGB or
> YUV input and also ITU-T BT.656 input streams.
> 
> The controller is combined with a physical panel and
> configured through the device tree.
> 
> Cc: David Lechner 
> Cc: Stefano Babic 
> Cc: Ben Dooks 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Dropped all DT parsing code in favor of open-coding the
>   display config on a per-system basis based on system-specific
>   compatible strings, after feedback from the DT maintainers.
> - Define a set of configs for the D-Link DIR-685 router.
> - Tested on the D-Link DIR-685.
> ---
>  drivers/gpu/drm/panel/Kconfig|   8 +
>  drivers/gpu/drm/panel/Makefile   |   1 +
>  drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 962 
> +++
>  3 files changed, 971 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9322.c

checkpatch.pl gives me these:

-:30: WARNING: please write a paragraph that describes the config 
symbol fully
#30: FILE: drivers/gpu/drm/panel/Kconfig:31:
+config DRM_PANEL_ILITEK_IL9322

-:54: WARNING: added, moved or deleted file(s), does MAINTAINERS need 
updating?
#54:
new file mode 100644

-:130: CHECK: Prefer using the BIT macro
#130: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:72:
+#define ILI9322_ENTRY_PAL  (1 << 2)

-:134: CHECK: Prefer using the BIT macro
#134: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:76:
+#define ILI9322_ENTRY_SERIAL_RGB_ALIGNED (1 << 4)

-:196: CHECK: spaces preferred around that '|' (ctx:VxV)
#196: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:138:
+#define ILI9322_IF_CTRL_SYNC_DISABLED  (BIT(2)|BIT(3))
   ^

-:551: WARNING: msleep < 20ms can sleep for up to 20ms; see 
Documentation/timers/timers-howto.txt
#551: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:493:
+   msleep(10);

total: 0 errors, 3 warnings, 3 checks, 983 lines checked

I'd like to see at least the warnings fixed. You can probably skip the
entry in MAINTAINERS, though. I don't mind fixing these up while
applying, but I don't know what to put in Kconfig. If you can send out
a short paragraph for me to include I'll add it when I apply.

Thierry


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

[Bug 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games

[bugzilla-daemon]

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

--- Comment #8 from Christian König  ---
I think I've figured out what is going on here. Give me a moment to provide a
new patch.

-- 
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] drm/tegra: Restore opaque and drop alpha formats on Tegra20/30

[Thierry Reding]

On Thu, Dec 21, 2017 at 01:38:31AM +0300, Dmitry Osipenko wrote:
> On 21.12.2017 01:23, Dmitry Osipenko wrote:
> > On 21.12.2017 01:02, Thierry Reding wrote:
> >> On Thu, Dec 21, 2017 at 12:05:40AM +0300, Dmitry Osipenko wrote:
> >>> On 20.12.2017 23:16, Thierry Reding wrote:
>  On Wed, Dec 20, 2017 at 11:01:49PM +0300, Dmitry Osipenko wrote:
> > On 20.12.2017 21:01, Thierry Reding wrote:
> >> On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
> >>> Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats") broke
> >>> DRM's MODE_ADDFB IOCTL on Tegra20/30, because IOCTL uses XRGB format 
> >>> if
> >>> requested FB depth is 24bpp. As a result, Xorg doesn't work anymore 
> >>> with
> >>> both modesetting and opentegra drivers. On older Tegra's each plane 
> >>> has
> >>> a blending configuration which should be used to enable / disable 
> >>> alpha
> >>> blending and right now the blending configs are hardcoded to disabled
> >>> alpha blending. In order to support alpha formats properly, planes
> >>> blending configuration must be adjusted, until then the alpha formats
> >>> are equal to non-alpha.
> >>>
> >>> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
> >>> Signed-off-by: Dmitry Osipenko 
> >>> ---
> >>>  drivers/gpu/drm/tegra/dc.c| 29 ++---
> >>>  drivers/gpu/drm/tegra/dc.h|  1 +
> >>>  drivers/gpu/drm/tegra/fb.c| 13 -
> >>>  drivers/gpu/drm/tegra/hub.c   |  3 ++-
> >>>  drivers/gpu/drm/tegra/plane.c | 22 +-
> >>>  drivers/gpu/drm/tegra/plane.h |  2 +-
> >>>  6 files changed, 39 insertions(+), 31 deletions(-)
> >>
> >> This kept bugging me, so I spent some time looking at the blending
> >> programming. I came up with the attached patch which seems to work
> >> for all scenarios and is fairly similar to your patch. It has the
> >> added benefit that we can keep support for more formats.
> >>
> >> Any comments?
> >>
> >> Thierry
> >> --- >8 ---
> >> From 3d2b7d1a9b8239dc6940477d8783461ac60783bc Mon Sep 17 00:00:00 2001
> >> From: Thierry Reding 
> >> Date: Wed, 20 Dec 2017 09:39:14 +0100
> >> Subject: [PATCH] drm/tegra: dc: Implement legacy blending
> >>
> >> This implements alpha blending on legacy display controllers (Tegra20,
> >> Tegra30 and Tegra114). While it's theoretically possible to support the
> >> zpos property to enable userspace to specify the Z-order of each plane
> >> individually, this is not currently supported and the same fixed Z-
> >> order as previously defined is used.
> >
> > Perhaps one variant of implementing zpos could be by making overlays 
> > 'virtual',
> > so each virtual overlay will be backed by the real HW plane and we 
> > could swap
> > the HW planes of the virtual overlays, emulating zpos.
> >
> >> Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") 
> >> since
> >> the opaque formats are now supported.
> >>
> >> Reported-by: Dmitry Osipenko 
> >> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
> >> Signed-off-by: Thierry Reding 
> >> ---
> >>  drivers/gpu/drm/tegra/dc.c| 74 
> >> ++-
> >>  drivers/gpu/drm/tegra/dc.h| 13 
> >>  drivers/gpu/drm/tegra/fb.c| 12 ---
> >>  drivers/gpu/drm/tegra/plane.c | 41 
> >>  drivers/gpu/drm/tegra/plane.h |  3 ++
> >>  5 files changed, 116 insertions(+), 27 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> >> index bc65c314e00f..07c687d7f615 100644
> >> --- a/drivers/gpu/drm/tegra/dc.c
> >> +++ b/drivers/gpu/drm/tegra/dc.c
> >> @@ -168,32 +168,46 @@ static inline u32 compute_initial_dda(unsigned 
> >> int in)
> >>return dfixed_frac(inf);
> >>  }
> >>  
> >> -static void tegra_plane_setup_blending_legacy(struct tegra_plane 
> >> *plane)
> >> +static void
> >> +tegra_plane_setup_blending_legacy(struct tegra_plane *plane,
> >> +const struct tegra_dc_window *window)
> >>  {
> >> +  u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
> >> +   BLEND_COLOR_KEY_NONE;
> >> +  u32 background = BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) |
> >> +   BLEND_COLOR_KEY_NONE;
> >> +  u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
> >> +
> >> +  /* enable alpha blending if window->alpha */
> >> +  if (window->alpha) {
> >> +  background |= BLEND_CONTROL_DEPENDENT;
> >> +  foreground |= BLEND_CONTROL_ALPHA;

Re: [PATCH v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight

[Daniel Vetter]

On Thu, Dec 21, 2017 at 2:44 PM, Noralf Trønnes  wrote:
>
> Den 21.12.2017 14.05, skrev Daniel Vetter:
>>
>> On Thu, Dec 21, 2017 at 11:52:43AM +0100, Noralf Trønnes wrote:
>>>
>>> Den 11.12.2017 18.56, skrev Noralf Trønnes:

 Den 11.12.2017 18.45, skrev Noralf Trønnes:
>
> Den 11.12.2017 15.58, skrev Meghana Madhyastha:
>>
>> On Mon, Dec 11, 2017 at 03:12:06PM +0100, Noralf Trønnes wrote:
>>>
>>> Den 11.12.2017 14.17, skrev Meghana Madhyastha:

 On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:
>
> Den 21.10.2017 13.55, skrev Meghana Madhyastha:
>>
>> Changes in v14:
>> - s/backlight_get/of_find_backlight/ in patch 2/3
>> - Change commit message in patch 3/3 from requiring to acquiring
>>
>> Meghana Madhyastha (3):
>> drm/tinydrm: Move helper functions from
>> tinydrm-helpers to backlight.h
>> drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
>> drm/tinydrm: Add devres versions of of_find_backlight
>
> I tried the patchset and this is what I got:
>
> [8.057792] Unable to handle kernel paging
> request at virtual address
> fe6b

 
>
> [9.144181] ---[ end trace 149c05934b6a6dcc ]---

 Is the reason possibly because we have omitted error checking on the
 return value of backlight_enable function ?
 tinydrm_enable_backlight and
 tinydrm_disable_baclight do this.
 Eg.
 ret = backlight_update_status(backlight);
 if (ret)
  DRM_ERROR("Failed to enable backlight %d\n", ret);

 I'm not sure, just asking whether this could be a possible reason
 for the above trace.
>>>
>>> The crash happens during probe.
>>> I guess you'll figure this out when you get some hw to test on.
>>
>> I have set up the raspberry pi and have built and boot into the
>> custom kernel
>> but I am waiting for the panel to arrive. Meanwhile, any thoughts on
>> error message ? Sorry for the trivial question, but I did not quite
>> understand the crash message and how to replicate it.
>
> of_find_backlight() can return an error pointer (-EPROBE_DEFER):
>
> diff --git a/drivers/video/backlight/backlight.c
> b/drivers/video/backlight/backlight.c
> index 4bb7bf3ee443..57370c5d51f0 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -635,8 +635,8 @@ struct backlight_device
> *devm_of_find_backlight(struct device *dev)
>  int ret;
>
>  bd = of_find_backlight(dev);
> -   if (!bd)
> -   return NULL;
> +   if (IS_ERR_OR_NULL(bd))
> +   return bd;
>
>  ret = devm_add_action(dev, devm_backlight_put, bd);
>  if (ret) {
>
> That solved the crash, but the backlight didn't turn on.
> I had to do this as well:
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 5c441d4c049c..6f9925f10a7c 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -139,6 +139,8 @@ static inline int backlight_enable(struct
> backlight_device *bd)
>  if (!bd)
>  return 0;
>
> +   if (!bd->props.brightness)
> +   bd->props.brightness = bd->props.max_brightness;

 No, this is wrong, it should happen on probe, not every time it's
 enabled.
 So maybe it should be done in of_find_backlight() or something.
 I see that I'm currently doing it in tinydrm_of_find_backlight().

>>> I'm not happy with this brightness hack of mine really.
>>>
>>> Since I last looked at this I see that pwm_bl has gained the ability to
>>> start in a power off state (pwm_backlight_initial_power_state()).
>>> However the gpio_backlight driver doesn't do this. gpio_backlight has a
>>> 'default-on' property, but the problem is that it sets brightness, not
>>> power state. So the absense of the property sets brightness to zero,
>>> which makes the driver turn off backlight on probe. This seems to be
>>> fine, but then systemd-backlight comes along and restores brightness
>>> to 1, since that's what it was on shutdown. This turns on backlight and
>>> now I have a glaring white uninitialized panel waiting for the display
>>> driver to set it up.
>>>
>>> This patch would solve my problem:
>>>
>>> diff --git a/drivers/video/backlight/gpio_backlight.c
>>> b/drivers/video/backlight/gpio_backlight.c
>>> index e470da95d806..54bb722e1ea3 100644
>>> --- a/drivers/video/backlight/gpio_backlight.c
>>> +++ b/drivers/video/backlight/gpio_backlight.c
>>> @@ -142,7 +142,8 @@ static int gpio_backlight_probe(struct
>>> platform_device
>>> *pdev)
>>>  

[PATCH v2] drm/tegra: dc: Implement legacy blending

[Thierry Reding]

From: Thierry Reding 

This implements alpha blending on legacy display controllers (Tegra20,
Tegra30 and Tegra114). While it's theoretically possible to support the
zpos property to enable userspace to specify the Z-order of each plane
individually, this is not currently supported and the same fixed Z-
order as previously defined is used.

Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") since
the opaque formats are now supported.

Reported-by: Dmitry Osipenko 
Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
Signed-off-by: Thierry Reding 
---
Changes in v2:
- properly implement blending if windows have different pixel formats

 drivers/gpu/drm/tegra/dc.c|  81 +
 drivers/gpu/drm/tegra/dc.h|  12 
 drivers/gpu/drm/tegra/fb.c|  12 
 drivers/gpu/drm/tegra/plane.c | 138 ++
 drivers/gpu/drm/tegra/plane.h |   8 +++
 5 files changed, 226 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 2a0c1e93f82e..4507063029e0 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -154,30 +154,53 @@ static inline u32 compute_initial_dda(unsigned int in)
 
 static void tegra_plane_setup_blending_legacy(struct tegra_plane *plane)
 {
+   u32 background[3] = {
+   BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) | BLEND_COLOR_KEY_NONE,
+   BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) | BLEND_COLOR_KEY_NONE,
+   BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) | BLEND_COLOR_KEY_NONE,
+   };
+   u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
+BLEND_COLOR_KEY_NONE;
+   u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
+   struct tegra_plane_state *state;
+   unsigned int i;
+
+   state = to_tegra_plane_state(plane->base.state);
+
+   /* alpha contribution is 1 minus sum of overlapping windows */
+   for (i = 0; i < 3; i++) {
+   if (state->dependent[i])
+   background[i] |= BLEND_CONTROL_DEPENDENT;
+   }
+
+   /* enable alpha blending if pixel format has an alpha component */
+   if (!state->opaque)
+   foreground |= BLEND_CONTROL_ALPHA;
+
/*
 * Disable blending and assume Window A is the bottom-most window,
 * Window C is the top-most window and Window B is in the middle.
 */
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_NOKEY);
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_1WIN);
+   tegra_plane_writel(plane, blendnokey, DC_WIN_BLEND_NOKEY);
+   tegra_plane_writel(plane, foreground, DC_WIN_BLEND_1WIN);
 
switch (plane->index) {
case 0:
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
+   tegra_plane_writel(plane, background[0], DC_WIN_BLEND_2WIN_X);
+   tegra_plane_writel(plane, background[1], DC_WIN_BLEND_2WIN_Y);
+   tegra_plane_writel(plane, background[2], DC_WIN_BLEND_3WIN_XY);
break;
 
case 1:
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
+   tegra_plane_writel(plane, foreground, DC_WIN_BLEND_2WIN_X);
+   tegra_plane_writel(plane, background[1], DC_WIN_BLEND_2WIN_Y);
+   tegra_plane_writel(plane, background[2], DC_WIN_BLEND_3WIN_XY);
break;
 
case 2:
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
+   tegra_plane_writel(plane, foreground, DC_WIN_BLEND_2WIN_X);
+   tegra_plane_writel(plane, foreground, DC_WIN_BLEND_2WIN_Y);
+   tegra_plane_writel(plane, foreground, DC_WIN_BLEND_3WIN_XY);
break;
}
 }
@@ -353,6 +376,11 @@ static const u32 tegra20_primary_formats[] = {
DRM_FORMAT_RGBA5551,
DRM_FORMAT_ABGR,
DRM_FORMAT_ARGB,
+   /* non-native formats */
+   DRM_FORMAT_XRGB1555,
+   DRM_FORMAT_RGBX5551,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_XRGB,
 };
 
 static const u32 tegra114_primary_formats[] = {
@@ -409,18 +437,40 @@ static int tegra_plane_atomic_check(struct drm_plane 
*plane,
struct tegra_bo_tiling *tiling = _state->tiling;
struct tegra_plane *tegra = to_tegra_plane(plane);
struct tegra_dc *dc = to_tegra_dc(state->crtc);
+   unsigned int format;
int err;
 
/* no need for 

[Bug 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games

[bugzilla-daemon]

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

--- Comment #7 from Michel Dänzer  ---
(In reply to Vedran Miletić from comment #5)
> I'm sorry, but I will not be able to bisect this. Checkouts of relevant
> commits don't boot and simple reverts do apply cleanly, but don't compile.

FWIW, you may still be able to at least narrow things down with git bisect. If
you can't test a selected commit, run "git bisect skip". That will select
another commit to test. You can also manually check out another commit to test.
In the worst case, the bisection process will end with identifying the minimal
set of candidates instead of a single commit.

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

AMD DC test results

[Daniel Drake]

Hi,

Thanks for the hard work on AMD DC development! Here are some new test
results - hope they are interesting/useful.


CONTEXT

We have been tracking DC for a while as we work with multiple products
where amdgpu previously was not able to support the HDMI audio output.
We are hoping to ship the new driver as soon as possible to fix this
Linux compatibility issue.


TEST SETUP

With an eye to shipping this ASAP, we backported DC to the current
stable release, Linux 4.14. To do this we took the amdgpu/DC commits
from:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=upstream-4.14-drm-next-amd-dc-staging-chrome

And added these two pull requests:
https://www.spinics.net/lists/dri-devel/msg156828.html
https://lists.freedesktop.org/archives/dri-devel/2017-November/157687.html

At this point we diff the resultant amdgpu directories with Linus tree
as of commit f6705bf959efac87bca76d40050d342f1d212587 (when he
accepted the DC driver) and the diff is zero. This is published on the
master branch of https://github.com/endlessm/linux

There have been more AMD DC changes merged into Linus tree since then,
however we tried and the backporting seems like loads of work, so we
have not gone beyond the initial merge into Linus tree for now.

We then asked our QA team to run our standard tests with this kernel.
They tested 3 platforms:
Acer Aspire E5-553G (AMD FX-9800P RADEON R7)
Acer Aspire E5-523G (AMD E2-9010 RADEON R2)
Acer Aspire A315-21 (AMD A4-9120 RADEON R3)

CONFIG_DRM_AMD_DC_PRE_VEGA was set in order to have AMD DC support
this hardware.


TEST RESULTS

HDMI audio works now, however we have encountered some regressions. In
all cases the 3 platforms behaved the same (either all 3 pass the
individual tests, or all 3 show the same problem). The regressions
are:

1. System hangs on S3 resume.
Bug can't be reproduced when booting with amdgpu.dc=0
Also reproduced with DC on Linus master (4.15-rc), but appears fixed
on agd5f/amd-staging-drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=104281

2. Display corruption when using multiple displays
Bug can't be reproduced when booting with amdgpu.dc=0
Also reproduced with DC on Linus master (4.15-rc), but appears fixed
on agd5f/amd-staging-drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=104319

3. HDMI audio device still shown as present and active even after
disconnecting HDMI cable
Bug can't be reproduced when booting with amdgpu.dc=0
Appears fixed with DC on Linus master (4.15-rc).

Full test results spreadsheet (including tests passed): http://goo.gl/oqnMDx
Thanks to my colleagues: Carlo Caione for doing the backport and
Vanessa Chang for managing the testing.


NEXT STEPS

Unfortunately we can't ship the driver in current state with these
regressions, but on the positive side it looks like it will be in
better shape for Linux 4.16.

We will now focus on making 4.15 regression-free before revisiting the
idea of backporting DC to earlier kernels.

After the holiday break we will try to identify the relevant fixes in
amd-staging-drm-next and see if they can be included in Linux 4.15.
We'll send these backports upstream as soon as we find them.


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

Re: [PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos

[Tomi Valkeinen]

On 21/12/17 14:55, Ville Syrjälä wrote:

On Thu, Dec 21, 2017 at 02:11:00PM +0200, Peter Ujfalusi wrote:

Make sure that the primary plane will get normalized_zpos=0 if it's zpos is
set to 0, avoiding other planes to be placed in the background.


Can you describe the actual "bad" configuration?

Without knowing the details this looks like it's making things
more complicated for no particularly good reason. If you're worried
about clients that don't set zpos, then I think you should just
assign the default zpos values better and/or allocate the planes
in a better order. But it's definitely possible I'm missing the
reason why you're doing this.


Let's say we have two displays and two planes. First display will use 
crtc0 and plane0 as primary plane, the second display crtc1, plane1. The 
zpos of primary planes will be set to 0 by default.


The userspace wants to use the second display, with an overlay plane. So 
it takes the plane0 and moves it to crtc1. Now the second display has 
two planes with zpos 0, and normalize_zpos will fix it according to the 
plane id, i.e. the primary plane of the second display will be on top of 
the "overlay" plane.


I don't think other default zpos values and/or allocating planes in 
better order can solve this.


If the userspace is required to understand and set zpos, then this patch 
is not needed. But at least in my test scripts I've hit this a few times =).


 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH 2/2] drm/omap: Normalize the zpos and use the normalized_zpos in runtime

[Daniel Vetter]

On Thu, Dec 21, 2017 at 02:11:01PM +0200, Peter Ujfalusi wrote:
> To avoid zpos collision, use the normalized_zpos when configuring the
> zorder of the plane.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c   | 26 +-
>  drivers/gpu/drm/omapdrm/omap_plane.c |  2 +-
>  2 files changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 6bfc2d9ebb46..230df6d8edd1 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -21,6 +21,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -54,6 +55,29 @@ MODULE_PARM_DESC(displays,
>   * devices
>   */
>  
> +int omap_atomic_helper_check(struct drm_device *dev,
> +  struct drm_atomic_state *state)
> +{
> + int ret;
> +
> + ret = drm_atomic_helper_check_modeset(dev, state);
> + if (ret)
> + return ret;
> +
> + ret = drm_atomic_normalize_zpos(dev, state);
> + if (ret)
> + return ret;

Maybe we should call this by default from helpers instead of forcing
everyone to reinvent this particular wheel?

exynos and sti have the exact same code as you do here, ans rcar could
also reuse it. That feels like we should just fix up
drm_atomic_helper_check instead of patching all the drivers. And as long
as you never change zpos it shouldn't ever run.
-Daniel

> +
> + ret = drm_atomic_helper_check_planes(dev, state);
> + if (ret)
> + return ret;
> +
> + if (state->legacy_cursor_update)
> + state->async_update = !drm_atomic_helper_async_check(dev, 
> state);
> +
> + return ret;
> +}
> +
>  static void omap_atomic_wait_for_completion(struct drm_device *dev,
>   struct drm_atomic_state *old_state)
>  {
> @@ -133,7 +157,7 @@ static const struct drm_mode_config_helper_funcs 
> omap_mode_config_helper_funcs =
>  static const struct drm_mode_config_funcs omap_mode_config_funcs = {
>   .fb_create = omap_framebuffer_create,
>   .output_poll_changed = drm_fb_helper_output_poll_changed,
> - .atomic_check = drm_atomic_helper_check,
> + .atomic_check = omap_atomic_helper_check,
>   .atomic_commit = drm_atomic_helper_commit,
>  };
>  
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
> b/drivers/gpu/drm/omapdrm/omap_plane.c
> index bbbdd560e503..abd78b511e6d 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -65,7 +65,7 @@ static void omap_plane_atomic_update(struct drm_plane 
> *plane,
>   info.rotation_type = OMAP_DSS_ROT_NONE;
>   info.rotation = DRM_MODE_ROTATE_0;
>   info.global_alpha = 0xff;
> - info.zorder = state->zpos;
> + info.zorder = state->normalized_zpos;
>  
>   /* update scanout: */
>   omap_framebuffer_update_scanout(state->fb, state, );
> -- 
> Peter
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 

-- 
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/1] drm: Add dirty_rects atomic blob property for drm_plane

[Daniel Vetter]

On Thu, Dec 21, 2017 at 02:46:55PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 21, 2017 at 12:10:08PM +0100, Lukasz Spintzyk wrote:
> > Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5
> > Signed-off-by: Lukasz Spintzyk 
> > ---
> >  drivers/gpu/drm/drm_atomic.c  | 10 ++
> >  drivers/gpu/drm/drm_mode_config.c |  6 ++
> >  drivers/gpu/drm/drm_plane.c   |  1 +
> >  include/drm/drm_mode_config.h |  5 +
> >  include/drm/drm_plane.h   |  3 +++
> >  5 files changed, 25 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index b76d49218cf1..cd3b4ed7b04c 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -759,6 +759,14 @@ static int drm_atomic_plane_set_property(struct 
> > drm_plane *plane,
> > state->rotation = val;
> > } else if (property == plane->zpos_property) {
> > state->zpos = val;
> > +   } else if (property == config->dirty_rects_property) {
> > +   bool replaced = false;
> > +   int ret = drm_atomic_replace_property_blob_from_id(dev,
> > +   >dirty_blob,
> > +   val,
> > +   -1,
> > +   );
> > +   return ret;
> > } else if (plane->funcs->atomic_set_property) {
> > return plane->funcs->atomic_set_property(plane, state,
> > property, val);
> > @@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> > *val = state->rotation;
> > } else if (property == plane->zpos_property) {
> > *val = state->zpos;
> > +   } else if (property == config->dirty_rects_property) {
> > +   *val = (state->dirty_blob) ? state->dirty_blob->base.id : 0;
> > } else if (plane->funcs->atomic_get_property) {
> > return plane->funcs->atomic_get_property(plane, state, 
> > property, val);
> > } else {
> > diff --git a/drivers/gpu/drm/drm_mode_config.c 
> > b/drivers/gpu/drm/drm_mode_config.c
> > index bc5c46306b3d..d5f1021c6ece 100644
> > --- a/drivers/gpu/drm/drm_mode_config.c
> > +++ b/drivers/gpu/drm/drm_mode_config.c
> > @@ -293,6 +293,12 @@ static int drm_mode_create_standard_properties(struct 
> > drm_device *dev)
> > return -ENOMEM;
> > dev->mode_config.prop_crtc_id = prop;
> >  
> > +   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> > +   "DIRTY_RECTS", 0);
> > +   if (!prop)
> > +   return -ENOMEM;
> > +   dev->mode_config.dirty_rects_property = prop;
> > +
> > prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
> > "ACTIVE");
> > if (!prop)
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 37a93cdffb4a..add110f025e5 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -258,6 +258,7 @@ int drm_universal_plane_init(struct drm_device *dev, 
> > struct drm_plane *plane,
> > drm_object_attach_property(>base, config->prop_src_y, 0);
> > drm_object_attach_property(>base, config->prop_src_w, 0);
> > drm_object_attach_property(>base, config->prop_src_h, 0);
> > +   drm_object_attach_property(>base, 
> > config->dirty_rects_property, 0);
> > }
> >  
> > if (config->allow_fb_modifiers)
> > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > index e5f3b43014e1..65f64eb04c0c 100644
> > --- a/include/drm/drm_mode_config.h
> > +++ b/include/drm/drm_mode_config.h
> > @@ -599,6 +599,11 @@ struct drm_mode_config {
> >  * _crtc.
> >  */
> > struct drm_property *prop_crtc_id;
> > +   /**
> > +* @dirty_rects_property: Optional plane property to mark damaged
> > +* regions on the plane framebuffer.
> 
> What exactly would the blob contain?
> 
> The comment seems to be implying these are in fb coordiantes as
> opposed to plane crtc coordinates? Not sure which would be more
> convenient. At least if they're fb coordinates then you probably
> want some helpers to translate/rotate/scale those rects to the
> crtc coordinates. Actual use depends on the driver/hw I suppose.

Yeah I think we also should add a decoded state to the drm_plane_state,
which has the full structure and all the details.

And when we discussed this iirc we've identified a clear need for at least
some drivers to deal in crtc dirty rectangles. I think the initial core
support should include a helper which takes an atomic update for a given
crtc, and converts all the plane dirty rectangles into crtc rectangles.
Including any full-plane or full-crtc upgrades needed due to e.g.
reposition, changed gamma, changed blendign/zpos or anything else really
that would affect the entire plane respectively crtc. That would also
provide a really good model for what damage actually means.

Plus 

[PULL] drm-misc-fixes

[Daniel Vetter]

Hi Dave,

drm-misc-fixes-2017-12-21:
drm-misc-fixes before holidays:

- fixup for the lease fixup (Keith)
- fb leak in the ww mutex fallback code (Maarten)
- sun4i fixes (Maxime, Hans)

I'll be away for two weeks, but I think Sean and Gustavo are somewhat
around-ish. But there's also not really much going on anyway.

Cheers, Daniel

The following changes since commit bd36d3bab2e3d08f80766c86487090dbceed4651:

  drm/drm_lease: Prevent deadlock in case drm_lease_create() fails (2017-12-14 
08:25:37 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2017-12-21

for you to fetch changes up to d2a48e52541cdf474ef35d51e8d73ded5be33122:

  drm: move lease init after validation in drm_lease_create (2017-12-21 
09:49:40 +0100)


drm-misc-fixes before holidays:

- fixup for the lease fixup (Keith)
- fb leak in the ww mutex fallback code (Maarten)
- sun4i fixes (Maxime, Hans)


Hans Verkuil (1):
  drm/sun4i: validate modes for HDMI

Keith Packard (1):
  drm: move lease init after validation in drm_lease_create

Maarten Lankhorst (1):
  drm/plane: Make framebuffer refcounting the responsibility of 
setplane_internal callers

Maxime Ripard (2):
  drm/sun4i: Fix error path handling
  drm/sun4i: hdmi: Move the mode_valid callback to the encoder

 drivers/gpu/drm/drm_lease.c| 22 +-
 drivers/gpu/drm/drm_plane.c| 42 --
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 20 
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  4 ++--
 4 files changed, 53 insertions(+), 35 deletions(-)

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

Re: [PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos

[Ville Syrjälä]

On Thu, Dec 21, 2017 at 02:11:00PM +0200, Peter Ujfalusi wrote:
> Make sure that the primary plane will get normalized_zpos=0 if it's zpos is
> set to 0, avoiding other planes to be placed in the background.

Can you describe the actual "bad" configuration?

Without knowing the details this looks like it's making things
more complicated for no particularly good reason. If you're worried
about clients that don't set zpos, then I think you should just
assign the default zpos values better and/or allocate the planes
in a better order. But it's definitely possible I'm missing the
reason why you're doing this.

> 
> If user space wants to move the primary plane forward, it can set the zpos
> of the plane.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/gpu/drm/drm_blend.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 4c62dff14893..bdc4f714afb8 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -301,7 +301,11 @@ static int drm_atomic_state_zpos_cmp(const void *a, 
> const void *b)
>   const struct drm_plane_state *sa = *(struct drm_plane_state **)a;
>   const struct drm_plane_state *sb = *(struct drm_plane_state **)b;
>  
> - if (sa->zpos != sb->zpos)
> + if (sa->plane == sa->crtc->primary && sa->zpos == 0)
> + return -1;
> + else if (sb->plane == sb->crtc->primary && sb->zpos == 0)
> + return 1;
> + else if (sa->zpos != sb->zpos)
>   return sa->zpos - sb->zpos;
>   else
>   return sa->plane->base.id - sb->plane->base.id;
> -- 
> Peter
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] drm/sun4i: hdmi: Fix sun4i_tmds_determine_rate

[Maxime Ripard]

Hi,

On Thu, Dec 21, 2017 at 10:24:11PM +1100, Jonathan Liu wrote:
> There are several issues in sun4i_tmds_determine_rate:
> - doesn't check if the best match was already set before comparing it
>   with the enumerated parameters which could result in integer divide
>   by zero
> - doesn't consider rate halving when determining closest match if it
>   can't match the requested rate exactly
> - sets best_div to i which corresponds to rate halving when it should be
>   set to j which corresponds to the divider
> 
> Fix these issues.
> 
> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> Signed-off-by: Jonathan Liu 

Please make separate patches for each of these issues, if possible
detailing how do you reproduce them.

Maxime

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


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

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

[Ville Syrjälä]

On Thu, Dec 21, 2017 at 12:10:08PM +0100, Lukasz Spintzyk wrote:
> Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5
> Signed-off-by: Lukasz Spintzyk 
> ---
>  drivers/gpu/drm/drm_atomic.c  | 10 ++
>  drivers/gpu/drm/drm_mode_config.c |  6 ++
>  drivers/gpu/drm/drm_plane.c   |  1 +
>  include/drm/drm_mode_config.h |  5 +
>  include/drm/drm_plane.h   |  3 +++
>  5 files changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index b76d49218cf1..cd3b4ed7b04c 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -759,6 +759,14 @@ static int drm_atomic_plane_set_property(struct 
> drm_plane *plane,
>   state->rotation = val;
>   } else if (property == plane->zpos_property) {
>   state->zpos = val;
> + } else if (property == config->dirty_rects_property) {
> + bool replaced = false;
> + int ret = drm_atomic_replace_property_blob_from_id(dev,
> + >dirty_blob,
> + val,
> + -1,
> + );
> + return ret;
>   } else if (plane->funcs->atomic_set_property) {
>   return plane->funcs->atomic_set_property(plane, state,
>   property, val);
> @@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->rotation;
>   } else if (property == plane->zpos_property) {
>   *val = state->zpos;
> + } else if (property == config->dirty_rects_property) {
> + *val = (state->dirty_blob) ? state->dirty_blob->base.id : 0;
>   } else if (plane->funcs->atomic_get_property) {
>   return plane->funcs->atomic_get_property(plane, state, 
> property, val);
>   } else {
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index bc5c46306b3d..d5f1021c6ece 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -293,6 +293,12 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.prop_crtc_id = prop;
>  
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> + "DIRTY_RECTS", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.dirty_rects_property = prop;
> +
>   prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
>   "ACTIVE");
>   if (!prop)
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 37a93cdffb4a..add110f025e5 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -258,6 +258,7 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>   drm_object_attach_property(>base, config->prop_src_y, 0);
>   drm_object_attach_property(>base, config->prop_src_w, 0);
>   drm_object_attach_property(>base, config->prop_src_h, 0);
> + drm_object_attach_property(>base, 
> config->dirty_rects_property, 0);
>   }
>  
>   if (config->allow_fb_modifiers)
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index e5f3b43014e1..65f64eb04c0c 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -599,6 +599,11 @@ struct drm_mode_config {
>* _crtc.
>*/
>   struct drm_property *prop_crtc_id;
> + /**
> +  * @dirty_rects_property: Optional plane property to mark damaged
> +  * regions on the plane framebuffer.

What exactly would the blob contain?

The comment seems to be implying these are in fb coordiantes as
opposed to plane crtc coordinates? Not sure which would be more
convenient. At least if they're fb coordinates then you probably
want some helpers to translate/rotate/scale those rects to the
crtc coordinates. Actual use depends on the driver/hw I suppose.

> +  */
> + struct drm_property *dirty_rects_property;
>   /**
>* @prop_active: Default atomic CRTC property to control the active
>* state, which is the simplified implementation for DPMS in atomic
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 8185e3468a23..7d45b164ccce 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -131,6 +131,9 @@ struct drm_plane_state {
>*/
>   struct drm_crtc_commit *commit;
>  
> + /* Optional blob property with damaged regions. */
> + struct drm_property_blob *dirty_blob;
> +
>   struct drm_atomic_state *state;
>  };
>  
> -- 
> 2.15.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Use an atomic_t array to track power domain use count.

[Maarten Lankhorst]

Hey,

Op 19-12-17 om 06:26 schreef Dhinakaran Pandiyan:
> Convert the power_domains->domain_use_count array that tracks per-domain
> use count to atomic_t type. This is needed to be able to read/write the use
> counts outside of the power domain mutex.
>
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
>  drivers/gpu/drm/i915/i915_drv.h |  2 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +--
>  3 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1a7b28f62570..1f1d9162f2c2 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2764,7 +2764,7 @@ static int i915_power_domain_info(struct seq_file *m, 
> void *unused)
>   for_each_power_domain(power_domain, power_well->domains)
>   seq_printf(m, "  %-23s %d\n",
>intel_display_power_domain_str(power_domain),
> -  power_domains->domain_use_count[power_domain]);
> +  
> atomic_read(_domains->domain_use_count[power_domain]));
>   }
>  
>   mutex_unlock(_domains->lock);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1e4e613e7b41..ddadeb9eaf49 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1489,7 +1489,7 @@ struct i915_power_domains {
>   int power_well_count;
>  
>   struct mutex lock;
> - int domain_use_count[POWER_DOMAIN_NUM];
> + atomic_t domain_use_count[POWER_DOMAIN_NUM];
>   struct i915_power_well *power_wells;
>  };
>  
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 96ab74f3d101..992caec1fbc4 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1453,7 +1453,7 @@ __intel_display_power_get_domain(struct 
> drm_i915_private *dev_priv,
>   for_each_power_domain_well(dev_priv, power_well, BIT_ULL(domain))
>   intel_power_well_get(dev_priv, power_well);
>  
> - power_domains->domain_use_count[domain]++;
> + atomic_inc(_domains->domain_use_count[domain]);
>  }
>  
>  /**
> @@ -1539,10 +1539,9 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>  
>   mutex_lock(_domains->lock);
>  
> - WARN(!power_domains->domain_use_count[domain],
> -  "Use count on domain %s is already zero\n",
> + WARN(atomic_dec_return(_domains->domain_use_count[domain]) < 0,
> +  "Use count on domain %s was already zero\n",
>intel_display_power_domain_str(domain));
> - power_domains->domain_use_count[domain]--;
>  
>   for_each_power_domain_well_rev(dev_priv, power_well, BIT_ULL(domain))
>   intel_power_well_put(dev_priv, power_well);
> @@ -3049,7 +3048,7 @@ static void intel_power_domains_dump_info(struct 
> drm_i915_private *dev_priv)
>   for_each_power_domain(domain, power_well->domains)
>   DRM_DEBUG_DRIVER("  %-23s %d\n",
>intel_display_power_domain_str(domain),
> -  
> power_domains->domain_use_count[domain]);
> +  
> atomic_read(_domains->domain_use_count[domain]));
>   }
>  }
>  
> @@ -3092,7 +3091,7 @@ void intel_power_domains_verify_state(struct 
> drm_i915_private *dev_priv)
>  
>   domains_count = 0;
>   for_each_power_domain(domain, power_well->domains)
> - domains_count += 
> power_domains->domain_use_count[domain];
> + domains_count += 
> atomic_read(_domains->domain_use_count[domain]);
>  
>   if (power_well->count != domains_count) {
>   DRM_ERROR("power well %s refcount/domain refcount 
> mismatch "

I can imagine this will start failing really badly. The previous code assumed 
that
everything is protected by power_domains->lock, and now this changes makes it no
longer the case..

I see the rest of the code changes things even more, but it would be better if 
the
locking rework was done in a single patch, and not bolted on..

And instead of using atomic_t, there is a refcount implementation in refcount.h,
it could be used here for locking power wells only if it would drop to zero..

Cheers,
Maarten

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

[Bug 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games

[bugzilla-daemon]

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

--- Comment #6 from Christian König  ---
Created attachment 136340
  --> https://bugs.freedesktop.org/attachment.cgi?id=136340=edit
Possible fix

Complete shot into the dark, but while double checking the code I've found that
at least this calculation isn't correct.

-- 
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 104281] black / corrupted screen when resuming from S3 [AMDGPU]

[bugzilla-daemon]

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

--- Comment #3 from Daniel Drake  ---
Need to do more testing to be sure, but it appears that this is not
reproducible on the development branch
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next

-- 
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 104319] AMDGPU/DC: Internal display corrupted when connecting (mirroring/extending) an external monitor on HDMI

[bugzilla-daemon]

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

--- Comment #3 from Daniel Drake  ---
Need to do more testing to be sure, but it appears that this is not
reproducible on the development branch
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next

-- 
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 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games

[bugzilla-daemon]

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

--- Comment #5 from Vedran Miletić  ---
(In reply to Christian König from comment #4)
> You can restrict that to changes to drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c.
> 
> The problem is that we use more dw than expected for clearing the page
> tables. No idea what exactly goes wrong, but bisecting the commit which
> introduced it would certainly help.

I'm sorry, but I will not be able to bisect this. Checkouts of relevant commits
don't boot and simple reverts do apply cleanly, but don't compile.

-- 
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 2/2] drm/omap: Normalize the zpos and use the normalized_zpos in runtime

[Peter Ujfalusi]

To avoid zpos collision, use the normalized_zpos when configuring the
zorder of the plane.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/omap_drv.c   | 26 +-
 drivers/gpu/drm/omapdrm/omap_plane.c |  2 +-
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 6bfc2d9ebb46..230df6d8edd1 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -21,6 +21,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -54,6 +55,29 @@ MODULE_PARM_DESC(displays,
  * devices
  */
 
+int omap_atomic_helper_check(struct drm_device *dev,
+struct drm_atomic_state *state)
+{
+   int ret;
+
+   ret = drm_atomic_helper_check_modeset(dev, state);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_normalize_zpos(dev, state);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_helper_check_planes(dev, state);
+   if (ret)
+   return ret;
+
+   if (state->legacy_cursor_update)
+   state->async_update = !drm_atomic_helper_async_check(dev, 
state);
+
+   return ret;
+}
+
 static void omap_atomic_wait_for_completion(struct drm_device *dev,
struct drm_atomic_state *old_state)
 {
@@ -133,7 +157,7 @@ static const struct drm_mode_config_helper_funcs 
omap_mode_config_helper_funcs =
 static const struct drm_mode_config_funcs omap_mode_config_funcs = {
.fb_create = omap_framebuffer_create,
.output_poll_changed = drm_fb_helper_output_poll_changed,
-   .atomic_check = drm_atomic_helper_check,
+   .atomic_check = omap_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
 
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index bbbdd560e503..abd78b511e6d 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -65,7 +65,7 @@ static void omap_plane_atomic_update(struct drm_plane *plane,
info.rotation_type = OMAP_DSS_ROT_NONE;
info.rotation = DRM_MODE_ROTATE_0;
info.global_alpha = 0xff;
-   info.zorder = state->zpos;
+   info.zorder = state->normalized_zpos;
 
/* update scanout: */
omap_framebuffer_update_scanout(state->fb, state, );
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 0/2] drm blend/omap: normalized zpos handling

[Peter Ujfalusi]

Hi,

The following two patch will change the omapdrm to use the normalized_zpos when
configuring the zpos/zorder of the planes.

In OMAP it is possible to move planes between crtcs freely and it is possible to
move even the primary plane from one crtc to another, where it should not be
treated as primary anymore (the crtc's primary plane is the primary for the
crtc).

The first patch will adjust the sorting of the planes for the given crtc to make
sure that the crtc's primary plane, if it has zpos=0 is going to be the bottom
plane. If the zpos of the primary plane is changed by user space then we obey
this and don't force the bottom position.

Regards,
Peter
---
Peter Ujfalusi (2):
  drm/blend: Account also the primary plane of the crtc for
normalized_zpos
  drm/omap: Normalize the zpos and use the normalized_zpos in runtime

 drivers/gpu/drm/drm_blend.c  |  6 +-
 drivers/gpu/drm/omapdrm/omap_drv.c   | 26 +-
 drivers/gpu/drm/omapdrm/omap_plane.c |  2 +-
 3 files changed, 31 insertions(+), 3 deletions(-)

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos

[Peter Ujfalusi]

Make sure that the primary plane will get normalized_zpos=0 if it's zpos is
set to 0, avoiding other planes to be placed in the background.

If user space wants to move the primary plane forward, it can set the zpos
of the plane.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/drm_blend.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 4c62dff14893..bdc4f714afb8 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -301,7 +301,11 @@ static int drm_atomic_state_zpos_cmp(const void *a, const 
void *b)
const struct drm_plane_state *sa = *(struct drm_plane_state **)a;
const struct drm_plane_state *sb = *(struct drm_plane_state **)b;
 
-   if (sa->zpos != sb->zpos)
+   if (sa->plane == sa->crtc->primary && sa->zpos == 0)
+   return -1;
+   else if (sb->plane == sb->crtc->primary && sb->zpos == 0)
+   return 1;
+   else if (sa->zpos != sb->zpos)
return sa->zpos - sb->zpos;
else
return sa->plane->base.id - sb->plane->base.id;
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

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

[Tomi Valkeinen]

Hi,

On 21/12/17 07:12, Stephen Rothwell wrote:

Hi all,

Commits

   bb5cdf8d1c76 ("drm: omapdrm: Remove filename from header and fix copyright 
tag")
   d66c36a3ee79 ("drm: omapdrm: Simplify platform registration")

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


Sorry about that, I missed those.

I think I need to create a script to verify my pull requests for things 
like this...


 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 0/1] Damage rectangles interface for DRM

[Lukasz Spintzyk]

This is a draft of damage interface for drm. Alluding to the topic 
"RFC: page-flip with damage?" on dri-devel
https://lists.freedesktop.org/archives/dri-devel/2017-September/153235.html
The following patch is a proof of concept, how we can deliver dirty rectangles 
to the drm drivers.
Patch was tested on Chromium OS to deliver damage regions to atomic version of 
evdi driver. Hence this supports atomic drivers for now.
We should agree on the approach how this can be implemented.
In the patch, I intend to use drm blob properties to pass c-style array of 
drm_clip_rects.
Is DRM properties framework suitable for this solution? The only doubt I have 
is that it requires to create and destroy property blob every 
atomic_commit/page flip as this is the only way to update blob with damage 
regions. This is associated with kmalloc and free for each flip. Do you think 
if this approach relates to some performance risk?

The proposed solution is attaching DIRTY_RECTS property to the 
drm_plane. The property means to hold list of rectangles in plane coordinates.
This is opposite to initial plan in thread from September 2017. I wanted to 
present our rationale for this.
Single rect vs rect list:
Some compositors like Chromium can have quite precise damage 
information that would be lost if we would collapse them. 
Damage rectangles on crtc vs per plane
The property is attached to drm plane initially. We had a talk with 
guys from Chromium compositor. The plan is to use overlay planes more 
extensively. Also, Chromium compositor operates on dirty rects per plane so it 
would be easier to use them as is.
In my opinion this is more natural to deliver information about damage per 
plane. Damage information is used primarily for bandwidth savings. For driver 
that deliver plane data it is more useful to know what parts of the plane have 
changed so it can send only these memory areas.
I don't know if this reasoning is valid. Probably it depends on hardware and 
driver.
I can speak about use cases I have faced. One of them is additional cursor 
plane. With damage regions on crtc I don't know if it is related to primary 
plane, or it is connected to cursor movement. Also, user space applications 
must generate additional damage regions when such cursor plane is moving over 
primary plane. For such cases passing dirty rectangles for planes seems to be 
more straightforward.

This is draft with minimal functionality. I would like to hear what is your 
opinion on it.  
I am happy to hear what are the requirements of other driver vendors.


Thanks
Lukasz Spintzyk

Lukasz Spintzyk (1):
  drm: Add dirty_rects atomic blob property for drm_plane

 drivers/gpu/drm/drm_atomic.c  | 10 ++
 drivers/gpu/drm/drm_mode_config.c |  6 ++
 drivers/gpu/drm/drm_plane.c   |  1 +
 include/drm/drm_mode_config.h |  5 +
 include/drm/drm_plane.h   |  3 +++
 5 files changed, 25 insertions(+)

-- 
2.15.1

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

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

[Lukasz Spintzyk]

Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5
Signed-off-by: Lukasz Spintzyk 
---
 drivers/gpu/drm/drm_atomic.c  | 10 ++
 drivers/gpu/drm/drm_mode_config.c |  6 ++
 drivers/gpu/drm/drm_plane.c   |  1 +
 include/drm/drm_mode_config.h |  5 +
 include/drm/drm_plane.h   |  3 +++
 5 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b76d49218cf1..cd3b4ed7b04c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -759,6 +759,14 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
+   } else if (property == config->dirty_rects_property) {
+   bool replaced = false;
+   int ret = drm_atomic_replace_property_blob_from_id(dev,
+   >dirty_blob,
+   val,
+   -1,
+   );
+   return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == plane->zpos_property) {
*val = state->zpos;
+   } else if (property == config->dirty_rects_property) {
+   *val = (state->dirty_blob) ? state->dirty_blob->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index bc5c46306b3d..d5f1021c6ece 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -293,6 +293,12 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_crtc_id = prop;
 
+   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+   "DIRTY_RECTS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.dirty_rects_property = prop;
+
prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
"ACTIVE");
if (!prop)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 37a93cdffb4a..add110f025e5 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -258,6 +258,7 @@ int drm_universal_plane_init(struct drm_device *dev, struct 
drm_plane *plane,
drm_object_attach_property(>base, config->prop_src_y, 0);
drm_object_attach_property(>base, config->prop_src_w, 0);
drm_object_attach_property(>base, config->prop_src_h, 0);
+   drm_object_attach_property(>base, 
config->dirty_rects_property, 0);
}
 
if (config->allow_fb_modifiers)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index e5f3b43014e1..65f64eb04c0c 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -599,6 +599,11 @@ struct drm_mode_config {
 * _crtc.
 */
struct drm_property *prop_crtc_id;
+   /**
+* @dirty_rects_property: Optional plane property to mark damaged
+* regions on the plane framebuffer.
+*/
+   struct drm_property *dirty_rects_property;
/**
 * @prop_active: Default atomic CRTC property to control the active
 * state, which is the simplified implementation for DPMS in atomic
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 8185e3468a23..7d45b164ccce 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -131,6 +131,9 @@ struct drm_plane_state {
 */
struct drm_crtc_commit *commit;
 
+   /* Optional blob property with damaged regions. */
+   struct drm_property_blob *dirty_blob;
+
struct drm_atomic_state *state;
 };
 
-- 
2.15.1

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

[PATCH v5 06/12] drm/sun4i: Create minimal multipliers and dividers

[Maxime Ripard]

The various outputs the TCON can provide have different constraints on the
dotclock divider. Let's make them configurable by the various mode_set
functions.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_dotclock.c | 10 +++---
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  2 ++
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  2 ++
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c 
b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
index d401156490f3..023f39bda633 100644
--- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
+++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
@@ -17,8 +17,9 @@
 #include "sun4i_dotclock.h"
 
 struct sun4i_dclk {
-   struct clk_hw   hw;
-   struct regmap   *regmap;
+   struct clk_hw   hw;
+   struct regmap   *regmap;
+   struct sun4i_tcon   *tcon;
 };
 
 static inline struct sun4i_dclk *hw_to_dclk(struct clk_hw *hw)
@@ -73,11 +74,13 @@ static unsigned long sun4i_dclk_recalc_rate(struct clk_hw 
*hw,
 static long sun4i_dclk_round_rate(struct clk_hw *hw, unsigned long rate,
  unsigned long *parent_rate)
 {
+   struct sun4i_dclk *dclk = hw_to_dclk(hw);
+   struct sun4i_tcon *tcon = dclk->tcon;
unsigned long best_parent = 0;
u8 best_div = 1;
int i;
 
-   for (i = 6; i <= 127; i++) {
+   for (i = tcon->dclk_min_div; i <= tcon->dclk_max_div; i++) {
unsigned long ideal = rate * i;
unsigned long rounded;
 
@@ -167,6 +170,7 @@ int sun4i_dclk_create(struct device *dev, struct sun4i_tcon 
*tcon)
dclk = devm_kzalloc(dev, sizeof(*dclk), GFP_KERNEL);
if (!dclk)
return -ENOMEM;
+   dclk->tcon = tcon;
 
init.name = clk_name;
init.ops = _dclk_ops;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index ea056a3d2131..46e28ca1f676 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -177,6 +177,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
u8 clk_delay;
u32 val = 0;
 
+   tcon->dclk_min_div = 6;
+   tcon->dclk_max_div = 127;
sun4i_tcon0_mode_set_common(tcon, mode);
 
/* Adjust clock delay */
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 839266a38505..bd3ad7684870 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -169,6 +169,8 @@ struct sun4i_tcon {
 
/* Pixel clock */
struct clk  *dclk;
+   u8  dclk_max_div;
+   u8  dclk_min_div;
 
/* Reset control */
struct reset_control*lcd_rst;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 12/12] ARM: dts: sun8i: a711: Enable the LCD

[Maxime Ripard]

The A711 has 1024x600 LVDS panel, with a PWM-based backlight. Add it to our
DT.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 61 -
 1 file changed, 61 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts 
b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
index a021ee6da396..511fca491fe8 100644
--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
@@ -45,6 +45,7 @@
 #include "sun8i-a83t.dtsi"
 
 #include 
+#include 
 
 / {
model = "TBS A711 Tablet";
@@ -59,6 +60,44 @@
stdout-path = "serial0:115200n8";
};
 
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 5 PWM_POLARITY_INVERTED>;
+   enable-gpios = < 3 29 GPIO_ACTIVE_HIGH>;
+
+   brightness-levels = <0 1 2 4 8 16 32 64 128 255>;
+   default-brightness-level = <9>;
+   };
+
+   panel {
+   compatible = "tbs,a711-panel", "panel-lvds";
+   backlight = <>;
+   power-supply = <_sw>;
+
+   width-mm = <153>;
+   height-mm = <90>;
+   data-mapping = "vesa-24";
+
+   panel-timing {
+   /* 1024x600 @60Hz */
+   clock-frequency = <5200>;
+   hactive = <1024>;
+   vactive = <600>;
+   hsync-len = <20>;
+   hfront-porch = <180>;
+   hback-porch = <160>;
+   vfront-porch = <12>;
+   vback-porch = <23>;
+   vsync-len = <5>;
+   };
+
+   port {
+   panel_input: endpoint {
+   remote-endpoint = <_out_lcd>;
+   };
+   };
+   };
+
reg_vbat: reg-vbat {
compatible = "regulator-fixed";
regulator-name = "vbat";
@@ -89,6 +128,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
 /*
  * An USB-2 hub is connected here, which also means we don't need to
  * enable the OHCI controller.
@@ -142,6 +185,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin>;
+   status = "okay";
+};
+
 _rsb {
status = "okay";
 
@@ -323,6 +372,18 @@
regulator-name = "vcc-lcd";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_lvds_pins>;
+};
+
+_out {
+   tcon0_out_lcd: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_input>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pb_pins>;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 10/12] ARM: dts: sun8i: a83t: Enable the PWM

[Maxime Ripard]

The A83T has the same PWM block than the H3. Add it to our DT.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index e4db38c717d9..ae34d22d6d47 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -440,6 +440,11 @@
bias-pull-up;
};
 
+   pwm_pin: pwm-pin {
+   pins = "PD28";
+   function = "pwm";
+   };
+
spdif_tx_pin: spdif-tx-pin {
pins = "PE18";
function = "spdif";
@@ -497,6 +502,15 @@
status = "disabled";
};
 
+   pwm: pwm@1c21400 {
+   compatible = "allwinner,sun8i-a83t-pwm",
+"allwinner,sun8i-h3-pwm";
+   reg = <0x01c21400 0x400>;
+   clocks = <>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
uart0: serial@1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 08/12] drm/sun4i: Add A83T support

[Maxime Ripard]

Add support for the A83T display pipeline.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c   |  1 +
 drivers/gpu/drm/sun4i/sun4i_tcon.c  |  5 +
 drivers/gpu/drm/sun4i/sun8i_mixer.c | 11 +++
 3 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 49215d91c853..6f5e721b545e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -347,6 +347,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun6i-a31s-display-engine" },
{ .compatible = "allwinner,sun7i-a20-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
+   { .compatible = "allwinner,sun8i-a83t-display-engine" },
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
{ }
 };
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 33b1a493fc0a..b78fed809992 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1133,6 +1133,10 @@ static const struct sun4i_tcon_quirks sun8i_a33_quirks = 
{
.has_lvds_alt   = true,
 };
 
+static const struct sun4i_tcon_quirks sun8i_a83t_lcd_quirks = {
+   /* nothing is supported */
+};
+
 static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
/* nothing is supported */
 };
@@ -1145,6 +1149,7 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun6i-a31s-tcon", .data = _a31s_quirks 
},
{ .compatible = "allwinner,sun7i-a20-tcon", .data = _a20_quirks },
{ .compatible = "allwinner,sun8i-a33-tcon", .data = _a33_quirks },
+   { .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data = 
_a83t_lcd_quirks },
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = _v3s_quirks },
{ }
 };
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c 
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 3a610a87cbd2..2cbb2de6d39c 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -478,6 +478,13 @@ static int sun8i_mixer_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct sun8i_mixer_cfg sun8i_a83t_mixer0_cfg = {
+   .ccsc   = 0,
+   .scaler_mask= 0xf,
+   .ui_num = 3,
+   .vi_num = 1,
+};
+
 static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
@@ -488,6 +495,10 @@ static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
 
 static const struct of_device_id sun8i_mixer_of_table[] = {
{
+   .compatible = "allwinner,sun8i-a83t-de2-mixer-0",
+   .data = _a83t_mixer0_cfg,
+   },
+   {
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = _v3s_mixer_cfg,
},
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 05/12] drm/sun4i: Force the mixer rate at 150MHz

[Maxime Ripard]

It seems like the mixer can only run properly when clocked at 150MHz. In
order to have something more robust than simply a fire-and-forget
assigned-clocks-rate, let's put that in the code.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun8i_mixer.c | 10 ++
 drivers/gpu/drm/sun4i/sun8i_mixer.h |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c 
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 29ceeb016d72..3a610a87cbd2 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -398,6 +398,15 @@ static int sun8i_mixer_bind(struct device *dev, struct 
device *master,
ret = PTR_ERR(mixer->mod_clk);
goto err_disable_bus_clk;
}
+
+   /*
+* It seems that we need to enforce that rate for whatever
+* reason for the mixer to be functional. Make sure it's the
+* case.
+*/
+   if (mixer->cfg->mod_rate)
+   clk_set_rate(mixer->mod_clk, mixer->cfg->mod_rate);
+
clk_prepare_enable(mixer->mod_clk);
 
list_add_tail(>engine.list, >engine_list);
@@ -474,6 +483,7 @@ static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.ui_num = 1,
.scaler_mask = 0x3,
.ccsc = 0,
+   .mod_rate = 15000,
 };
 
 static const struct of_device_id sun8i_mixer_of_table[] = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h 
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index bc58040a88f9..f34e70c42adf 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -121,12 +121,15 @@ struct de2_fmt_info {
  * Set value to 0 if this is first mixer or second mixer with VEP support.
  * Set value to 1 if this is second mixer without VEP support. Other values
  * are invalid.
+ * @mod_rate: module clock rate that needs to be set in order to have
+ * a functional block.
  */
 struct sun8i_mixer_cfg {
int vi_num;
int ui_num;
int scaler_mask;
int ccsc;
+   unsigned long   mod_rate;
 };
 
 struct sun8i_mixer {
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 07/12] drm/sun4i: Add LVDS support

[Maxime Ripard]

The TCON supports the LVDS interface to output to a panel or a bridge.
Let's add support for it.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/Makefile |   1 +-
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 177 ++-
 drivers/gpu/drm/sun4i/sun4i_lvds.h |  12 ++-
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 239 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  29 -
 5 files changed, 456 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h

diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 82a6ac57fbe3..2b37a6abbb1d 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -15,6 +15,7 @@ sun8i-mixer-y += sun8i_mixer.o 
sun8i_ui_layer.o \
 
 sun4i-tcon-y   += sun4i_crtc.o
 sun4i-tcon-y   += sun4i_dotclock.o
+sun4i-tcon-y   += sun4i_lvds.o
 sun4i-tcon-y   += sun4i_tcon.o
 sun4i-tcon-y   += sun4i_rgb.o
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
new file mode 100644
index ..be3f14d7746d
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2017 Free Electrons
+ * Maxime Ripard 
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun4i_crtc.h"
+#include "sun4i_tcon.h"
+#include "sun4i_lvds.h"
+
+struct sun4i_lvds {
+   struct drm_connectorconnector;
+   struct drm_encoder  encoder;
+
+   struct sun4i_tcon   *tcon;
+};
+
+static inline struct sun4i_lvds *
+drm_connector_to_sun4i_lvds(struct drm_connector *connector)
+{
+   return container_of(connector, struct sun4i_lvds,
+   connector);
+}
+
+static inline struct sun4i_lvds *
+drm_encoder_to_sun4i_lvds(struct drm_encoder *encoder)
+{
+   return container_of(encoder, struct sun4i_lvds,
+   encoder);
+}
+
+static int sun4i_lvds_get_modes(struct drm_connector *connector)
+{
+   struct sun4i_lvds *lvds =
+   drm_connector_to_sun4i_lvds(connector);
+   struct sun4i_tcon *tcon = lvds->tcon;
+
+   return drm_panel_get_modes(tcon->panel);
+}
+
+static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
+   .get_modes  = sun4i_lvds_get_modes,
+};
+
+static void
+sun4i_lvds_connector_destroy(struct drm_connector *connector)
+{
+   struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
+   struct sun4i_tcon *tcon = lvds->tcon;
+
+   drm_panel_detach(tcon->panel);
+   drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs sun4i_lvds_con_funcs = {
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .destroy= sun4i_lvds_connector_destroy,
+   .reset  = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
+};
+
+static void sun4i_lvds_encoder_enable(struct drm_encoder *encoder)
+{
+   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
+   struct sun4i_tcon *tcon = lvds->tcon;
+
+   DRM_DEBUG_DRIVER("Enabling LVDS output\n");
+
+   if (!IS_ERR(tcon->panel)) {
+   drm_panel_prepare(tcon->panel);
+   drm_panel_enable(tcon->panel);
+   }
+}
+
+static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder)
+{
+   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
+   struct sun4i_tcon *tcon = lvds->tcon;
+
+   DRM_DEBUG_DRIVER("Disabling LVDS output\n");
+
+   if (!IS_ERR(tcon->panel)) {
+   drm_panel_disable(tcon->panel);
+   drm_panel_unprepare(tcon->panel);
+   }
+}
+
+static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
+   .disable= sun4i_lvds_encoder_disable,
+   .enable = sun4i_lvds_encoder_enable,
+};
+
+static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
+   .destroy= drm_encoder_cleanup,
+};
+
+int sun4i_lvds_init(struct drm_device *drm, struct sun4i_tcon *tcon)
+{
+   struct drm_encoder *encoder;
+   struct drm_bridge *bridge;
+   struct sun4i_lvds *lvds;
+   int ret;
+
+   lvds = devm_kzalloc(drm->dev, sizeof(*lvds), GFP_KERNEL);
+   if (!lvds)
+   return -ENOMEM;
+   lvds->tcon = tcon;
+   encoder = >encoder;
+
+   ret = drm_of_find_panel_or_bridge(tcon->dev->of_node, 1, 0,
+ >panel, );
+   if (ret) {
+   dev_info(drm->dev, "No panel or bridge found... 

[PATCH v5 00/12] drm/sun4i: Add A83t LVDS support

[Maxime Ripard]

Hi,

Here is an attempt at supporting the LVDS output in our DRM driver. This
has been tested on the A83T (with DE2), but since everything is basically
in the TCON, it should also be usable on the older SoCs with minor
modifications.

This was the occasion to refactor a bunch of things. The most notable ones
would be the documentation, and split of the UI layers in the mixer code,
and the switch to kfifo for our endpoint parsing code in the driver that
fixes an issue introduced by the switch to BFS.

Let me know what you think,
Maxime

Changes from v4:
  - Changed the order of the clk_prepare_enable and clk_set_rate for the
mixer module clock
  - Squash the two DT PWM patches
  - Removed the output pins muxing
  - Changed the flag to tell if you have an LVDS alternate clock to
has_lvds_alt
  - Used SPDX headers

Changes from v3:
  - Collect the tags
  - Use SPDX headers when possible
  - Added the new mixer configuration options
  - Changed the LVDS clock for lvds-alt instead of lvds-pll
  - Removed the MIPI PLL from the A31s
  - Changed the LVDS_ANA0 macros name to reflect the generation they were
introduced in, and added a comment to mention the changes needed to
support the older SoCs

Changes from v2:
  - Move the module clock rate to the mixer structure
  - Adjusted the simple-panel documentation for power-supply
  - Changed the compatible for the first A83t mixer to mixer 0
  - Rebased on top of current drm-misc
  - Split out the A83t bindings in its separate patch

Changes from v1:
  - Added a fix for the error path handling in the TCON
  - Enable the TCON by default
  - Removed the patch that changes the channels offset but kept most of the
modifications as a cleanup
  - Deal with the LVDS clock being able to have another PLL parent on some
SoCs
  - Renamed the TCON compatible to TCON-TV, following the convention used
on newer SoCs
  - Removed the hardcoded timings
  - Moved LVDS enable quirks to a separate function
  - Used clock indices define in the DT
  - Removed the hardcoded clock rate in the DT and moved it to the driver
  - Changed sun8i_mixer_planes to sun8i_mixer_ui_planes to be consistent
  - Added the various tags collected
  - Rebased on top of 4.15

Maxime Ripard (12):
  dt-bindings: panel: lvds: Document power-supply property
  drm/panel: lvds: Add support for the power-supply property
  dt-bindings: display: sun4i-drm: Add LVDS properties
  dt-bindings: display: sun4i-drm: Add A83T pipeline
  drm/sun4i: Force the mixer rate at 150MHz
  drm/sun4i: Create minimal multipliers and dividers
  drm/sun4i: Add LVDS support
  drm/sun4i: Add A83T support
  ARM: dts: sun8i: a83t: Add display pipeline
  ARM: dts: sun8i: a83t: Enable the PWM
  ARM: dts: sun8i: a83t: Add LVDS pins group
  ARM: dts: sun8i: a711: Enable the LCD

 Documentation/devicetree/bindings/display/panel/panel-common.txt |   6 ++-
 Documentation/devicetree/bindings/display/panel/panel-lvds.txt   |   1 +-
 Documentation/devicetree/bindings/display/panel/simple-panel.txt |   2 +-
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt|  12 -
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts|  61 
++-
 arch/arm/boot/dts/sun8i-a83t.dtsi|  99 
+-
 drivers/gpu/drm/panel/panel-lvds.c   |  23 +++-
 drivers/gpu/drm/sun4i/Makefile   |   1 +-
 drivers/gpu/drm/sun4i/sun4i_dotclock.c   |  10 ++-
 drivers/gpu/drm/sun4i/sun4i_drv.c|   1 +-
 drivers/gpu/drm/sun4i/sun4i_lvds.c   | 177 
-
 drivers/gpu/drm/sun4i/sun4i_lvds.h   |  12 -
 drivers/gpu/drm/sun4i/sun4i_tcon.c   | 244 
+++-
 drivers/gpu/drm/sun4i/sun4i_tcon.h   |  31 
+-
 drivers/gpu/drm/sun4i/sun8i_mixer.c  |  21 ++-
 drivers/gpu/drm/sun4i/sun8i_mixer.h  |   3 +-
 16 files changed, 699 insertions(+), 5 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h

base-commit: 99239c7ba0214ec99011378a6ca1bcd589c3dc98
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 09/12] ARM: dts: sun8i: a83t: Add display pipeline

[Maxime Ripard]

The display pipeline on the A83T is mainly composed of the mixers and
TCONs, plus various encoders.

Let's add the first mixer and TCON to the DTSI since the only board I have
can use only the LVDS output on the first TCON. The other parts will be
added eventually.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 79 -
 1 file changed, 79 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 19acae1b4089..e4db38c717d9 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -45,8 +45,10 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 / {
@@ -151,6 +153,12 @@
};
};
 
+   de: display-engine {
+   compatible = "allwinner,sun8i-a83t-display-engine";
+   allwinner,pipelines = <>;
+   status = "disabled";
+   };
+
memory {
reg = <0x4000 0x8000>;
device_type = "memory";
@@ -162,6 +170,44 @@
#size-cells = <1>;
ranges;
 
+   display_clocks: clock@100 {
+   compatible = "allwinner,sun8i-a83t-de2-clk";
+   reg = <0x0100 0x10>;
+   clocks = < CLK_PLL_DE>,
+< CLK_BUS_DE>;
+   clock-names = "mod",
+ "bus";
+   resets = < RST_BUS_DE>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+   mixer0: mixer@110 {
+   compatible = "allwinner,sun8i-a83t-de2-mixer-0";
+   reg = <0x0110 0x10>;
+   clocks = <_clocks CLK_BUS_MIXER0>,
+<_clocks CLK_MIXER0>;
+   clock-names = "bus",
+ "mod";
+   resets = <_clocks RST_MIXER0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mixer0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mixer0_out_tcon0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_in_mixer0>;
+   };
+   };
+   };
+   };
+
syscon: syscon@1c0 {
compatible = "allwinner,sun8i-a83t-system-controller",
"syscon";
@@ -177,6 +223,39 @@
#dma-cells = <1>;
};
 
+   tcon0: lcd-controller@1c0c000 {
+   compatible = "allwinner,sun8i-a83t-tcon-lcd";
+   reg = <0x01c0c000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
+   clock-names = "ahb", "tcon-ch0";
+   clock-output-names = "tcon-pixel-clock";
+   resets = < RST_BUS_TCON0>, < RST_BUS_LVDS>;
+   reset-names = "lcd", "lvds";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tcon0_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   tcon0_in_mixer0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_out_tcon0>;
+   };
+   };
+
+   tcon0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun8i-a83t-mmc",
 "allwinner,sun7i-a20-mmc";
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 03/12] dt-bindings: display: sun4i-drm: Add LVDS properties

[Maxime Ripard]

Some clocks and resets supposed to drive the LVDS logic in the display
engine have been overlooked when the driver was first introduced.

Add those additional resources to the binding, and we'll deal with the ABI
stability in the code.

Reviewed-by: Chen-Yu Tsai 
Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt |  9 +++-
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 50cc72ee1168..1e21cfaac9e2 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -121,6 +121,15 @@ Required properties:
 On SoCs other than the A33 and V3s, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
 
+On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you
+need one more reset line:
+   - 'lvds': The reset line driving the LVDS logic
+
+And on the SoCs newer than the A31 (sun6i and sun8i families), you
+need one more clock line:
+   - 'lvds-alt': An alternative clock source, separate from the TCON channel 0
+ clock, that can be used to drive the LVDS clock
+
 DRC
 ---
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 02/12] drm/panel: lvds: Add support for the power-supply property

[Maxime Ripard]

A significant number of panels need to power up a regulator in order to
operate properly. Add support for the power-supply property to enable and
disable such a regulator whenever needed.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/panel/panel-lvds.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
b/drivers/gpu/drm/panel/panel-lvds.c
index e2d57c01200b..57e38a9e7ab4 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -39,6 +40,7 @@ struct panel_lvds {
bool data_mirror;
 
struct backlight_device *backlight;
+   struct regulator *supply;
 
struct gpio_desc *enable_gpio;
struct gpio_desc *reset_gpio;
@@ -69,6 +71,9 @@ static int panel_lvds_unprepare(struct drm_panel *panel)
if (lvds->enable_gpio)
gpiod_set_value_cansleep(lvds->enable_gpio, 0);
 
+   if (lvds->supply)
+   regulator_disable(lvds->supply);
+
return 0;
 }
 
@@ -76,6 +81,17 @@ static int panel_lvds_prepare(struct drm_panel *panel)
 {
struct panel_lvds *lvds = to_panel_lvds(panel);
 
+   if (lvds->supply) {
+   int err;
+
+   err = regulator_enable(lvds->supply);
+   if (err < 0) {
+   dev_err(lvds->dev, "failed to enable supply: %d\n",
+   err);
+   return err;
+   }
+   }
+
if (lvds->enable_gpio)
gpiod_set_value_cansleep(lvds->enable_gpio, 1);
 
@@ -196,6 +212,13 @@ static int panel_lvds_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
 
+   lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
+   if (IS_ERR(lvds->supply)) {
+   ret = PTR_ERR(lvds->supply);
+   dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
+   return ret;
+   }
+
/* Get GPIOs and backlight controller. */
lvds->enable_gpio = devm_gpiod_get_optional(lvds->dev, "enable",
 GPIOD_OUT_LOW);
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 04/12] dt-bindings: display: sun4i-drm: Add A83T pipeline

[Maxime Ripard]

The A83T has two video pipelines in parallel that looks quite similar to
the other SoCs.

The video planes are handled through a controller called the mixer, and the
video signal is then passed to the timing controller (TCON).

And while there is two instances of the mixers and TCONs, they have a
significant number of differences. The TCONs are quite easy to deal with,
one is supposed to generate TV (in the broader term, so including things
like HDMI) signals, the other one LCD (so RGB, LVDS, DSI) signals. And
while they are called TCON0 and TCON1 in the A83t datasheet, newer SoCs
call them TCON-TV and TCON-LCD, which seems more appropriate.

However, the mixers differ mostly by their capabilities, with some features
being available only in the first one, or the number of planes they expose,
but also through their register layout. And while the capabilities could be
represented as properties, the register layout differences would need to
express all the registers offsets as properties, which is usually quite
bad. Especially since documentation on that hardware block is close to
non-existant and we don't even have the list of all those registers in the
first place.

So let's call them mixer 0 and 1 in our compatibles, even though the name
is pretty bad...

At the moment, we only have tested the code on a board that has a single
display output, so we're leaving the tcon-tv and mixer1 out.

Reviewed-by: Rob Herring 
Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 1e21cfaac9e2..9f073af4c711 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -93,6 +93,7 @@ Required properties:
* allwinner,sun6i-a31s-tcon
* allwinner,sun7i-a20-tcon
* allwinner,sun8i-a33-tcon
+   * allwinner,sun8i-a83t-tcon-lcd
* allwinner,sun8i-v3s-tcon
  - reg: base address and size of memory-mapped region
  - interrupts: interrupt associated to this IP
@@ -225,6 +226,7 @@ supported.
 
 Required properties:
   - compatible: value must be one of:
+* allwinner,sun8i-a83t-de2-mixer-0
 * allwinner,sun8i-v3s-de2-mixer
   - reg: base address and size of the memory-mapped region.
   - clocks: phandles to the clocks feeding the mixer
@@ -254,6 +256,7 @@ Required properties:
 * allwinner,sun6i-a31s-display-engine
 * allwinner,sun7i-a20-display-engine
 * allwinner,sun8i-a33-display-engine
+* allwinner,sun8i-a83t-display-engine
 * allwinner,sun8i-v3s-display-engine
 
   - allwinner,pipelines: list of phandle to the display engine
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 01/12] dt-bindings: panel: lvds: Document power-supply property

[Maxime Ripard]

The power-supply property is used by a vast majority of panels, including
panel-simple. Let's document it as a common property

Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++
 Documentation/devicetree/bindings/display/panel/panel-lvds.txt   | 1 +
 Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +-
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt 
b/Documentation/devicetree/bindings/display/panel/panel-common.txt
index ec52c472c845..125ea68052af 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
@@ -78,6 +78,12 @@ used for panels that implement compatible control signals.
   while active. Active high reset signals can be supported by inverting the
   GPIO specifier polarity flag.
 
+Power
+-
+
+- power-supply: many display panels need an additional power supply in
+  order to be fully powered-up. For such panels, power-supply contains
+  a phandle to the regulator powering the panel.
 
 Backlight
 -
diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt 
b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
index b938269f841e..250850a2150b 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
@@ -32,6 +32,7 @@ Optional properties:
 - label: See panel-common.txt.
 - gpios: See panel-common.txt.
 - backlight: See panel-common.txt.
+- power-supply: See panel-common.txt.
 - data-mirror: If set, reverse the bit order described in the data mappings
   below on all data lanes, transmitting bits for slots 6 to 0 instead of
   0 to 6.
diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index 1341bbf4aa3d..16d8ff088b7d 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -1,7 +1,7 @@
 Simple display panel
 
 Required properties:
-- power-supply: regulator to provide the supply voltage
+- power-supply: See panel-common.txt
 
 Optional properties:
 - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 11/12] ARM: dts: sun8i: a83t: Add LVDS pins group

[Maxime Ripard]

The A83T has an LVDS bus that can be connected to a panel or a bridge. Add
the pinctrl group for it.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index ae34d22d6d47..a37517d4472a 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -415,6 +415,12 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
 
+   lcd_lvds_pins: lcd-lvds-pins {
+   pins = "PD18", "PD19", "PD20", "PD21", "PD22",
+  "PD23", "PD24", "PD25", "PD26", "PD27";
+   function = "lvds0";
+   };
+
mmc0_pins: mmc0-pins {
pins = "PF0", "PF1", "PF2",
   "PF3", "PF4", "PF5";
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight

[Noralf Trønnes]

Den 11.12.2017 18.56, skrev Noralf Trønnes:


Den 11.12.2017 18.45, skrev Noralf Trønnes:


Den 11.12.2017 15.58, skrev Meghana Madhyastha:

On Mon, Dec 11, 2017 at 03:12:06PM +0100, Noralf Trønnes wrote:

Den 11.12.2017 14.17, skrev Meghana Madhyastha:

On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:

Den 21.10.2017 13.55, skrev Meghana Madhyastha:

Changes in v14:
- s/backlight_get/of_find_backlight/ in patch 2/3
- Change commit message in patch 3/3 from requiring to acquiring

Meghana Madhyastha (3):
   drm/tinydrm: Move helper functions from tinydrm-helpers to 
backlight.h

   drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
   drm/tinydrm: Add devres versions of of_find_backlight

I tried the patchset and this is what I got:

[    8.057792] Unable to handle kernel paging request at virtual 
address

fe6b



[    9.144181] ---[ end trace 149c05934b6a6dcc ]---

Is the reason possibly because we have omitted error checking on the
return value of backlight_enable function ? 
tinydrm_enable_backlight and

tinydrm_disable_baclight do this.
Eg.
ret = backlight_update_status(backlight);
if (ret)
DRM_ERROR("Failed to enable backlight %d\n", ret);

I'm not sure, just asking whether this could be a possible reason
for the above trace.

The crash happens during probe.
I guess you'll figure this out when you get some hw to test on.
I have set up the raspberry pi and have built and boot into the 
custom kernel

but I am waiting for the panel to arrive. Meanwhile, any thoughts on
error message ? Sorry for the trivial question, but I did not quite
understand the crash message and how to replicate it.


of_find_backlight() can return an error pointer (-EPROBE_DEFER):

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c

index 4bb7bf3ee443..57370c5d51f0 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -635,8 +635,8 @@ struct backlight_device 
*devm_of_find_backlight(struct device *dev)

    int ret;

    bd = of_find_backlight(dev);
-   if (!bd)
-   return NULL;
+   if (IS_ERR_OR_NULL(bd))
+   return bd;

    ret = devm_add_action(dev, devm_backlight_put, bd);
    if (ret) {

That solved the crash, but the backlight didn't turn on.
I had to do this as well:

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5c441d4c049c..6f9925f10a7c 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -139,6 +139,8 @@ static inline int backlight_enable(struct 
backlight_device *bd)

    if (!bd)
    return 0;

+   if (!bd->props.brightness)
+   bd->props.brightness = bd->props.max_brightness;


No, this is wrong, it should happen on probe, not every time it's 
enabled.

So maybe it should be done in of_find_backlight() or something.
I see that I'm currently doing it in tinydrm_of_find_backlight().



I'm not happy with this brightness hack of mine really.

Since I last looked at this I see that pwm_bl has gained the ability to
start in a power off state (pwm_backlight_initial_power_state()).
However the gpio_backlight driver doesn't do this. gpio_backlight has a
'default-on' property, but the problem is that it sets brightness, not
power state. So the absense of the property sets brightness to zero,
which makes the driver turn off backlight on probe. This seems to be
fine, but then systemd-backlight comes along and restores brightness
to 1, since that's what it was on shutdown. This turns on backlight and
now I have a glaring white uninitialized panel waiting for the display
driver to set it up.

This patch would solve my problem:

diff --git a/drivers/video/backlight/gpio_backlight.c 
b/drivers/video/backlight/gpio_backlight.c

index e470da95d806..54bb722e1ea3 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -142,7 +142,8 @@ static int gpio_backlight_probe(struct 
platform_device *pdev)

    return PTR_ERR(bl);
    }

-   bl->props.brightness = gbl->def_value;
+   bl->props.brightness = 1;
+   bl->props.state = gbl->def_value ? 0 : BL_CORE_FBBLANK;
    backlight_update_status(bl);

    platform_set_drvdata(pdev, bl);

The problem is that this will most likely break 2 in-kernel users of
gpio-backlight which doesn't set the 'default-on' property:
  arch/arm/boot/dts/omap4-var-dvk-om44.dts
  arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts

AFAICT they rely on systemd-backlight to turn on backlight by setting
brightness to 1.

So maybe my hack is _the_ soulution after all, but I'm no expert on
the backlight subsystem and it's corner cases.

Noralf.


bd->props.power = FB_BLANK_UNBLANK;
    bd->props.state &= ~BL_CORE_FBBLANK;

This is my backlight node[1]:

backlight: backlight {
    compatible = "gpio-backlight";
    gpios = < 18 0>; // GPIO_ACTIVE_HIGH
};

Not certain that this is the "correct" 

[drm-tip:drm-tip 2/8] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:219:6: error: redefinition of 'dm_dp_mst_dc_sink_create'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   e421f7f2b48c47438cd22d673a2c025562d1f728
commit: d4afdbb09e6b347d3ae084331e8b5d70aa168564 [2/8] Merge remote-tracking 
branch 'airlied/drm-next' into drm-tip
config: i386-randconfig-i1-201751 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout d4afdbb09e6b347d3ae084331e8b5d70aa168564
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:219:6: 
>> error: redefinition of 'dm_dp_mst_dc_sink_create'
void dm_dp_mst_dc_sink_create(struct drm_connector *connector)
 ^~~~
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:183:6: 
note: previous definition of 'dm_dp_mst_dc_sink_create' was here
void dm_dp_mst_dc_sink_create(struct drm_connector *connector)
 ^~~~

vim +/dm_dp_mst_dc_sink_create +219 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c

54427651 Jerry Zuo   2017-09-20  218  
becd0875 Jerry (Fangzhi  Zuo 2017-12-01 @219) void 
dm_dp_mst_dc_sink_create(struct drm_connector *connector)
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  220) {
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  221)   struct amdgpu_dm_connector 
*aconnector = to_amdgpu_dm_connector(connector);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  222)   struct edid *edid;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  223)   struct dc_sink *dc_sink;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  224)   struct dc_sink_init_data 
init_params = {
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  225)   .link = 
aconnector->dc_link,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  226)   .sink_signal = 
SIGNAL_TYPE_DISPLAY_PORT_MST };
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  227) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  228)   edid = 
drm_dp_mst_get_edid(connector, >mst_port->mst_mgr, 
aconnector->port);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  229) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  230)   if (!edid) {
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  231)   
drm_mode_connector_update_edid_property(
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  232)   
>base,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  233)   NULL);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  234)   return;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  235)   }
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  236) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  237)   aconnector->edid = edid;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  238) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  239)   dc_sink = 
dc_link_add_remote_sink(
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  240)   aconnector->dc_link,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  241)   (uint8_t 
*)aconnector->edid,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  242)   
(aconnector->edid->extensions + 1) * EDID_LENGTH,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  243)   _params);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  244) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  245)   dc_sink->priv = aconnector;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  246)   aconnector->dc_sink = dc_sink;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  247) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  248)   
amdgpu_dm_add_sink_to_freesync_module(
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  249)   connector, 
aconnector->edid);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  250) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  251)   
drm_mode_connector_update_edid_property(
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  252)   
>base, aconnector->edid);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  253) }
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  254) 

:: The code at line 219 was first introduced by commit
:: becd0875f4393a992afbf57aa323f7bf1a71c3ff drm/amd/display: Fix rehook MST 
display not light back on

:: TO: Jerry (Fangzhi) Zuo 
:: CC: Alex Deucher 

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