[Bug 201795] [Regression] Wrong 4k resolution detected with DisplayPort to HDMI adapter on amdgpu

[bugzilla-daemon]

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

thomas.lassdiesonner...@gmx.de changed:

   What|Removed |Added

 Kernel Version|4.19.4  |4.19.8

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

[Bug 201795] [Regression] Wrong 4k resolution detected with DisplayPort to HDMI adapter on amdgpu

[bugzilla-daemon]

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

--- Comment #10 from thomas.lassdiesonner...@gmx.de ---
Still there with 4.19.8
I know it is probably low priority. Just keeping this report up to date.

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

[Bug 108992] Regression: Lenovo e585 (ryzen 2500u) freezes during boot with 4.20-rc5/rc6, amdgpu error

[bugzilla-daemon]

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

--- Comment #10 from Brian Schott  ---
Ignore that previous comment. I'm getting some strange results here and may
have marked a commit with an intermittent crash as "good" while bisecting.

-- 
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 108992] Regression: Lenovo e585 (ryzen 2500u) freezes during boot with 4.20-rc5/rc6, amdgpu error

[bugzilla-daemon]

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

--- Comment #9 from Brian Schott  ---
020aa2ec15fc4a5ffdfcab7dc0db648a137abc41 lets me log in before the system
freezes.

770af5859d6903049b7f39ed4f4e6612b63fd82d locks up before LightDM can start.

I'll do a bit more testing.

-- 
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: [v5 1/2] drm: Add colorspace connector property

[kbuild test robot]

Hi Uma,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.20-rc6 next-20181214]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Uma-Shankar/drm-Add-colorspace-connector-property/20181212-114922
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   include/net/mac80211.h:477: warning: cannot understand function prototype: 
'struct ieee80211_ftm_responder_params '
   include/net/mac80211.h:477: warning: cannot understand function prototype: 
'struct ieee80211_ftm_responder_params '
   include/net/mac80211.h:477: warning: cannot understand function prototype: 
'struct ieee80211_ftm_responder_params '
   include/net/mac80211.h:477: warning: cannot understand function prototype: 
'struct ieee80211_ftm_responder_params '
   include/net/mac80211.h:477: warning: cannot understand function prototype: 
'struct ieee80211_ftm_responder_params '
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'rx_stats_avg' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'rx_stats_avg.signal' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'rx_stats_avg.chain_signal' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.filtered' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.retry_failed' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.retry_count' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.lost_packets' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.last_tdls_pkt_time' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.msdu_retries' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.msdu_failed' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.last_ack' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.last_ack_signal' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.ack_signal_filled' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.avg_ack_signal' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'tx_stats.packets' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'tx_stats.bytes' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'tx_stats.last_rate' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'tx_stats.msdu' not described in 'sta_info'
   kernel/rcu/tree.c:685: warning: Excess function parameter 'irq' description 
in 'rcu_nmi_exit'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_excl.cb' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_excl.poll' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_excl.active' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_shared.cb' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_shared.poll' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_shared.active' not described in 'dma_buf'
   include/linux/dma-fence-array.h:54: warning: Function parameter or member 
'work' not described in 'dma_fence_array'
   include/linux/gpio/driver.h:375: warning: Function parameter or member 
'init_valid_mask' not described in 'gpio_chip'
   include/linux/iio/hw-consumer.h:1: warning: no structured comments found
   include/linux/input/sparse-keymap.h:46: warning: Function parameter or 
member 'sw' not described in 'key_entry'
   include/linux/regulator/driver.h:227: warning: Function parameter or member 
'resume' not described in 'regulator_ops'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'esw.esw0' not described in 'irb'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'esw.esw1' not described in 'irb'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'es

Re: [PATCH v2 1/2] dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU

[Doug Anderson]

Hi,

On Fri, Dec 14, 2018 at 3:58 PM Doug Anderson  wrote:
>
> Hi,
>
> On Fri, Dec 14, 2018 at 2:16 PM Jordan Crouse  wrote:
> >
> > Add documentation for the interconnect and interconnect-names bindings
> > for the GPU node as detailed by bindings/interconnect/interconnect.txt.
> >
> > Signed-off-by: Jordan Crouse 
> > ---
> >  Documentation/devicetree/bindings/display/msm/gpu.txt | 6 ++
> >  1 file changed, 6 insertions(+)
>
> Looks good to me.  This could go into Andy's tree as soon as Georgi's
> series lands somewhere.
>
> Reviewed-by: Douglas Anderson 

To correct myself, this maybe should go through Georgi's tree together
with .  It's the actual
dts that would go into Andy's tree.

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

Re: [PATCH v2 2/2] arm64: dts: sdm845: Add interconnect for GPU

[Doug Anderson]

Hi,

On Fri, Dec 14, 2018 at 2:16 PM Jordan Crouse  wrote:
>
> Define an interconnect port for the GPU to set bus
> capabilities.
>
> Signed-off-by: Jordan Crouse 
> ---
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 3 +++
>  1 file changed, 3 insertions(+)

Looks good to me.  This could go into Andy's tree as soon as Georgi's
series lands somewhere.

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

[PATCH v5 4/5] drm/msm: clean up display thread

[Jeykumar Sankaran]

Since there are no clients using these threads,
cleaning it up.

changes in v2:
- switch all the dependent clients to use system wq
  before removing the disp_threads (Sean Paul)
changes in v3:
- none
changes in v4:
- none
changes in v5:
- Rebase on latest tip with [1] (Sean Paul)

[1] https://patchwork.freedesktop.org/patch/255105/

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/msm_drv.c | 43 ++-
 drivers/gpu/drm/msm/msm_drv.h |  1 -
 2 files changed, 2 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index c61ce06..f7cb2c7 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -287,13 +287,8 @@ static int msm_drm_uninit(struct device *dev)
kfree(vbl_ev);
}
 
-   /* clean up display commit/event worker threads */
+   /* clean up event worker threads */
for (i = 0; i < priv->num_crtcs; i++) {
-   if (priv->disp_thread[i].thread) {
-   kthread_destroy_worker(>disp_thread[i].worker);
-   priv->disp_thread[i].thread = NULL;
-   }
-
if (priv->event_thread[i].thread) {
kthread_destroy_worker(>event_thread[i].worker);
priv->event_thread[i].thread = NULL;
@@ -551,26 +546,6 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
 */
param.sched_priority = 16;
for (i = 0; i < priv->num_crtcs; i++) {
-
-   /* initialize display thread */
-   priv->disp_thread[i].crtc_id = priv->crtcs[i]->base.id;
-   kthread_init_worker(>disp_thread[i].worker);
-   priv->disp_thread[i].dev = ddev;
-   priv->disp_thread[i].thread =
-   kthread_run(kthread_worker_fn,
-   >disp_thread[i].worker,
-   "crtc_commit:%d", priv->disp_thread[i].crtc_id);
-   ret = sched_setscheduler(priv->disp_thread[i].thread,
-   SCHED_FIFO, );
-   if (ret)
-   pr_warn("display thread priority update failed: %d\n",
-   ret);
-
-   if (IS_ERR(priv->disp_thread[i].thread)) {
-   DRM_DEV_ERROR(dev, "failed to create crtc_commit 
kthread\n");
-   priv->disp_thread[i].thread = NULL;
-   }
-
/* initialize event thread */
priv->event_thread[i].crtc_id = priv->crtcs[i]->base.id;
kthread_init_worker(>event_thread[i].worker);
@@ -580,13 +555,6 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
>event_thread[i].worker,
"crtc_event:%d", priv->event_thread[i].crtc_id);
 
-   /**
-* event thread should also run at same priority as disp_thread
-* because it is handling frame_done events. A lower priority
-* event thread and higher priority disp_thread can causes
-* frame_pending counters beyond 2. This can lead to commit
-* failure at crtc commit level.
-*/
ret = sched_setscheduler(priv->event_thread[i].thread,
SCHED_FIFO, );
if (ret)
@@ -598,16 +566,9 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
priv->event_thread[i].thread = NULL;
}
 
-   if ((!priv->disp_thread[i].thread) ||
-   !priv->event_thread[i].thread) {
+   if (!priv->event_thread[i].thread) {
/* clean up previously created threads if any */
for ( ; i >= 0; i--) {
-   if (priv->disp_thread[i].thread) {
-   kthread_stop(
-   priv->disp_thread[i].thread);
-   priv->disp_thread[i].thread = NULL;
-   }
-
if (priv->event_thread[i].thread) {
kthread_stop(
priv->event_thread[i].thread);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 8fad151..2a30fc4 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -199,7 +199,6 @@ struct msm_drm_private {
unsigned int num_crtcs;
struct drm_crtc *crtcs[MAX_CRTCS];
 
-   struct msm_drm_thread disp_thread[MAX_CRTCS];
struct msm_drm_thread event_thread[MAX_CRTCS];
 
unsigned int 

[PATCH v5 5/5] drm/msm: subclass work object for vblank events

[Jeykumar Sankaran]

msm maintains a separate structure to define vblank
work definitions and a list to track events submitted
to the workqueue. We can avoid this redundant list
and its protection mechanism, if we subclass the
work object to encapsulate vblank event parameters.

changes in v2:
- subclass optimization on system wq (Sean Paul)
changes in v3:
- none
changes in v4:
- move flush_workqueue before irq uninstall
changes in v5:
- none

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/msm_drv.c | 71 ++-
 drivers/gpu/drm/msm/msm_drv.h |  7 -
 2 files changed, 22 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index f7cb2c7..f9ad362 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -207,61 +207,44 @@ u32 msm_readl(const void __iomem *addr)
return val;
 }
 
-struct vblank_event {
-   struct list_head node;
+struct msm_vblank_work {
+   struct work_struct work;
int crtc_id;
bool enable;
+   struct msm_drm_private *priv;
 };
 
 static void vblank_ctrl_worker(struct work_struct *work)
 {
-   struct msm_vblank_ctrl *vbl_ctrl = container_of(work,
-   struct msm_vblank_ctrl, work);
-   struct msm_drm_private *priv = container_of(vbl_ctrl,
-   struct msm_drm_private, vblank_ctrl);
+   struct msm_vblank_work *vbl_work = container_of(work,
+   struct msm_vblank_work, work);
+   struct msm_drm_private *priv = vbl_work->priv;
struct msm_kms *kms = priv->kms;
-   struct vblank_event *vbl_ev, *tmp;
-   unsigned long flags;
-
-   spin_lock_irqsave(_ctrl->lock, flags);
-   list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node) {
-   list_del(_ev->node);
-   spin_unlock_irqrestore(_ctrl->lock, flags);
-
-   if (vbl_ev->enable)
-   kms->funcs->enable_vblank(kms,
-   priv->crtcs[vbl_ev->crtc_id]);
-   else
-   kms->funcs->disable_vblank(kms,
-   priv->crtcs[vbl_ev->crtc_id]);
-
-   kfree(vbl_ev);
 
-   spin_lock_irqsave(_ctrl->lock, flags);
-   }
+   if (vbl_work->enable)
+   kms->funcs->enable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
+   else
+   kms->funcs->disable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
 
-   spin_unlock_irqrestore(_ctrl->lock, flags);
+   kfree(vbl_work);
 }
 
 static int vblank_ctrl_queue_work(struct msm_drm_private *priv,
int crtc_id, bool enable)
 {
-   struct msm_vblank_ctrl *vbl_ctrl = >vblank_ctrl;
-   struct vblank_event *vbl_ev;
-   unsigned long flags;
+   struct msm_vblank_work *vbl_work;
 
-   vbl_ev = kzalloc(sizeof(*vbl_ev), GFP_ATOMIC);
-   if (!vbl_ev)
+   vbl_work = kzalloc(sizeof(*vbl_work), GFP_ATOMIC);
+   if (!vbl_work)
return -ENOMEM;
 
-   vbl_ev->crtc_id = crtc_id;
-   vbl_ev->enable = enable;
+   INIT_WORK(_work->work, vblank_ctrl_worker);
 
-   spin_lock_irqsave(_ctrl->lock, flags);
-   list_add_tail(_ev->node, _ctrl->event_list);
-   spin_unlock_irqrestore(_ctrl->lock, flags);
+   vbl_work->crtc_id = crtc_id;
+   vbl_work->enable = enable;
+   vbl_work->priv = priv;
 
-   queue_work(priv->wq, _ctrl->work);
+   queue_work(priv->wq, _work->work);
 
return 0;
 }
@@ -273,19 +256,15 @@ static int msm_drm_uninit(struct device *dev)
struct msm_drm_private *priv = ddev->dev_private;
struct msm_kms *kms = priv->kms;
struct msm_mdss *mdss = priv->mdss;
-   struct msm_vblank_ctrl *vbl_ctrl = >vblank_ctrl;
-   struct vblank_event *vbl_ev, *tmp;
int i;
 
/* We must cancel and cleanup any pending vblank enable/disable
 * work before drm_irq_uninstall() to avoid work re-enabling an
 * irq after uninstall has disabled it.
 */
-   flush_work(_ctrl->work);
-   list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node) {
-   list_del(_ev->node);
-   kfree(vbl_ev);
-   }
+
+   flush_workqueue(priv->wq);
+   destroy_workqueue(priv->wq);
 
/* clean up event worker threads */
for (i = 0; i < priv->num_crtcs; i++) {
@@ -315,9 +294,6 @@ static int msm_drm_uninit(struct device *dev)
drm_irq_uninstall(ddev);
pm_runtime_put_sync(dev);
 
-   flush_workqueue(priv->wq);
-   destroy_workqueue(priv->wq);
-
if (kms && kms->funcs)
kms->funcs->destroy(kms);
 
@@ -482,9 +458,6 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
priv->wq = 

[PATCH v5 3/5] drm/msm/dpu: use msm wq for idle power collapse

[Jeykumar Sankaran]

msm is using msm wq for dispatching commit and vblank
events. Switch idle power collapse feature also to use
msm wq to handle delayed work handlers so that
msm can get rid of redundant display threads.

changes in v2:
- patch introduced in v2
changes in v3:
- none
changes in v4:
- use msm wq for delayed works
changes in v5:
- none

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 25 +++--
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0dda4a6..941ac25 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -205,7 +205,7 @@ struct dpu_encoder_virt {
bool idle_pc_supported;
struct mutex rc_lock;
enum dpu_enc_rc_states rc_state;
-   struct kthread_delayed_work delayed_off_work;
+   struct delayed_work delayed_off_work;
struct kthread_work vsync_event_work;
struct msm_display_topology topology;
bool mode_set_complete;
@@ -744,7 +744,6 @@ static int dpu_encoder_resource_control(struct drm_encoder 
*drm_enc,
 {
struct dpu_encoder_virt *dpu_enc;
struct msm_drm_private *priv;
-   struct msm_drm_thread *disp_thread;
bool is_vid_mode = false;
 
if (!drm_enc || !drm_enc->dev || !drm_enc->dev->dev_private ||
@@ -757,12 +756,6 @@ static int dpu_encoder_resource_control(struct drm_encoder 
*drm_enc,
is_vid_mode = dpu_enc->disp_info.capabilities &
MSM_DISPLAY_CAP_VID_MODE;
 
-   if (drm_enc->crtc->index >= ARRAY_SIZE(priv->disp_thread)) {
-   DPU_ERROR("invalid crtc index\n");
-   return -EINVAL;
-   }
-   disp_thread = >disp_thread[drm_enc->crtc->index];
-
/*
 * when idle_pc is not supported, process only KICKOFF, STOP and MODESET
 * events and return early for other events (ie wb display).
@@ -779,8 +772,7 @@ static int dpu_encoder_resource_control(struct drm_encoder 
*drm_enc,
switch (sw_event) {
case DPU_ENC_RC_EVENT_KICKOFF:
/* cancel delayed off work, if any */
-   if (kthread_cancel_delayed_work_sync(
-   _enc->delayed_off_work))
+   if (cancel_delayed_work_sync(_enc->delayed_off_work))
DPU_DEBUG_ENC(dpu_enc, "sw_event:%d, work cancelled\n",
sw_event);
 
@@ -839,10 +831,8 @@ static int dpu_encoder_resource_control(struct drm_encoder 
*drm_enc,
return 0;
}
 
-   kthread_queue_delayed_work(
-   _thread->worker,
-   _enc->delayed_off_work,
-   msecs_to_jiffies(dpu_enc->idle_timeout));
+   queue_delayed_work(priv->wq, _enc->delayed_off_work,
+  msecs_to_jiffies(dpu_enc->idle_timeout));
 
trace_dpu_enc_rc(DRMID(drm_enc), sw_event,
 dpu_enc->idle_pc_supported, dpu_enc->rc_state,
@@ -851,8 +841,7 @@ static int dpu_encoder_resource_control(struct drm_encoder 
*drm_enc,
 
case DPU_ENC_RC_EVENT_PRE_STOP:
/* cancel delayed off work, if any */
-   if (kthread_cancel_delayed_work_sync(
-   _enc->delayed_off_work))
+   if (cancel_delayed_work_sync(_enc->delayed_off_work))
DPU_DEBUG_ENC(dpu_enc, "sw_event:%d, work cancelled\n",
sw_event);
 
@@ -1370,7 +1359,7 @@ static void dpu_encoder_frame_done_callback(
}
 }
 
-static void dpu_encoder_off_work(struct kthread_work *work)
+static void dpu_encoder_off_work(struct work_struct *work)
 {
struct dpu_encoder_virt *dpu_enc = container_of(work,
struct dpu_encoder_virt, delayed_off_work.work);
@@ -2195,7 +2184,7 @@ int dpu_encoder_setup(struct drm_device *dev, struct 
drm_encoder *enc,
 
 
mutex_init(_enc->rc_lock);
-   kthread_init_delayed_work(_enc->delayed_off_work,
+   INIT_DELAYED_WORK(_enc->delayed_off_work,
dpu_encoder_off_work);
dpu_enc->idle_timeout = IDLE_TIMEOUT;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH v5 2/5] drm/msm/dpu: use msm wq for vblank events

[Jeykumar Sankaran]

DPU was using one thread per display to dispatch async commits and
vblank requests. Since clean up already happened in msm to use the
common thread for all the display commits, display threads are only
used to cater vblank requests. Since a single thread is sufficient
to do the job without any performance hits, use msm workqueue
to queue requests. A separate patch is submitted later in this
series to remove the display threads altogether.

changes in v2:
- switch to system wq before removing disp threads (Sean Paul)
changes in v3:
- none
changes in v4:
- use msm wq for vblank events
changes in v5:
- none

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/msm_drv.c | 9 -
 drivers/gpu/drm/msm/msm_drv.h | 2 +-
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 78d5b1c..c61ce06 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -213,7 +213,7 @@ struct vblank_event {
bool enable;
 };
 
-static void vblank_ctrl_worker(struct kthread_work *work)
+static void vblank_ctrl_worker(struct work_struct *work)
 {
struct msm_vblank_ctrl *vbl_ctrl = container_of(work,
struct msm_vblank_ctrl, work);
@@ -261,8 +261,7 @@ static int vblank_ctrl_queue_work(struct msm_drm_private 
*priv,
list_add_tail(_ev->node, _ctrl->event_list);
spin_unlock_irqrestore(_ctrl->lock, flags);
 
-   kthread_queue_work(>disp_thread[crtc_id].worker,
-   _ctrl->work);
+   queue_work(priv->wq, _ctrl->work);
 
return 0;
 }
@@ -282,7 +281,7 @@ static int msm_drm_uninit(struct device *dev)
 * work before drm_irq_uninstall() to avoid work re-enabling an
 * irq after uninstall has disabled it.
 */
-   kthread_flush_work(_ctrl->work);
+   flush_work(_ctrl->work);
list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node) {
list_del(_ev->node);
kfree(vbl_ev);
@@ -489,7 +488,7 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
 
INIT_LIST_HEAD(>inactive_list);
INIT_LIST_HEAD(>vblank_ctrl.event_list);
-   kthread_init_work(>vblank_ctrl.work, vblank_ctrl_worker);
+   INIT_WORK(>vblank_ctrl.work, vblank_ctrl_worker);
spin_lock_init(>vblank_ctrl.lock);
 
drm_mode_config_init(ddev);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 9cd6a96..8fad151 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -78,7 +78,7 @@ enum msm_mdp_plane_property {
 };
 
 struct msm_vblank_ctrl {
-   struct kthread_work work;
+   struct work_struct work;
struct list_head event_list;
spinlock_t lock;
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH v2 1/2] dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU

[Doug Anderson]

Hi,

On Fri, Dec 14, 2018 at 2:16 PM Jordan Crouse  wrote:
>
> Add documentation for the interconnect and interconnect-names bindings
> for the GPU node as detailed by bindings/interconnect/interconnect.txt.
>
> Signed-off-by: Jordan Crouse 
> ---
>  Documentation/devicetree/bindings/display/msm/gpu.txt | 6 ++
>  1 file changed, 6 insertions(+)

Looks good to me.  This could go into Andy's tree as soon as Georgi's
series lands somewhere.

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

[PATCH v5 1/5] drm/msm/dpu: use kthread_destroy_worker to release msm workers

[Jeykumar Sankaran]

use kthread_destroy_worker to destroy workers and
release their associated kthreads.

changes in v3:
- introduced in the series
changes in v4:
- none
changes in v5:
- none

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/msm_drv.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 6265be8..78d5b1c 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -291,14 +291,12 @@ static int msm_drm_uninit(struct device *dev)
/* clean up display commit/event worker threads */
for (i = 0; i < priv->num_crtcs; i++) {
if (priv->disp_thread[i].thread) {
-   kthread_flush_worker(>disp_thread[i].worker);
-   kthread_stop(priv->disp_thread[i].thread);
+   kthread_destroy_worker(>disp_thread[i].worker);
priv->disp_thread[i].thread = NULL;
}
 
if (priv->event_thread[i].thread) {
-   kthread_flush_worker(>event_thread[i].worker);
-   kthread_stop(priv->event_thread[i].thread);
+   kthread_destroy_worker(>event_thread[i].worker);
priv->event_thread[i].thread = NULL;
}
}
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH v2 1/2] dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU

[Jordan Crouse]

Add documentation for the interconnect and interconnect-names bindings
for the GPU node as detailed by bindings/interconnect/interconnect.txt.

Signed-off-by: Jordan Crouse 
---
 Documentation/devicetree/bindings/display/msm/gpu.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 8d9415180c22..19b5ae459fdb 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -19,6 +19,9 @@ Required properties:
   * "mem_iface"
 - iommus: optional phandle to an adreno iommu instance
 - operating-points-v2: optional phandle to the OPP operating points
+- interconnect: optional phandle to a interconnect provider.  See
+  ../interconnect/interconnect.txt for details.
+- interconnect-names: Name string for the interconnects.
 - qcom,gmu: For a6xx and newer targets a phandle to the GMU device that will
   control the power for the GPU
 
@@ -68,6 +71,9 @@ Example a6xx (with GMU):
 
operating-points-v2 = <_opp_table>;
 
+   interconnects = <_hlos MASTER_GFX3D _hlos SLAVE_EBI1>;
+   interconnect-names = "gfx-mem";
+
qcom,gmu = <>;
};
 };
-- 
2.18.0

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

[PATCH v2 2/2] arm64: dts: sdm845: Add interconnect for GPU

[Jordan Crouse]

Define an interconnect port for the GPU to set bus
capabilities.

Signed-off-by: Jordan Crouse 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0a5ddfc4c59b..2acfea87716c 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1370,6 +1370,9 @@
 
operating-points-v2 = <_opp_table>;
 
+   interconnects = <_hlos MASTER_GFX3D _hlos 
SLAVE_EBI1>;
+   interconnect-names = "gfx-mem";
+
qcom,gmu = <>;
 
gpu_opp_table: opp-table {
-- 
2.18.0

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

[PATCH v2 0/2] arm64: dts: sdm845: Add sdm845 GPU interconnect

[Jordan Crouse]

Two quick patches to document and add an interconnect port definition
for the sdm845 GPU.

This is based on the base GPU DT changes:
https://patchwork.freedesktop.org/series/39308/

As well as the DT nodes from Georgi:
https://patchwork.kernel.org/patch/10719483/

v2: Fix interconnect supplier to match latest per Doug Anderson
*** BLURB HERE ***

Jordan Crouse (2):
  dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU
  arm64: dts: sdm845: Add interconnect for GPU

 Documentation/devicetree/bindings/display/msm/gpu.txt | 6 ++
 arch/arm64/boot/dts/qcom/sdm845.dtsi  | 3 +++
 2 files changed, 9 insertions(+)

-- 
2.18.0

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

[Bug 109064] temp_comp_access::get_required_live_range: enclosing_scope_first_write is NULL

[bugzilla-daemon]

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

Bug ID: 109064
   Summary: temp_comp_access::get_required_live_range:
enclosing_scope_first_write is NULL
   Product: Mesa
   Version: 18.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: alex_y...@yahoo.ca
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 142814
  --> https://bugs.freedesktop.org/attachment.cgi?id=142814=edit
FS_bb6bfb3018b248ae9b31f50f6cc3c1401308f621.glsl

When loading a game in The Witcher 3, the game crashes.

#0  (anonymous namespace)::temp_comp_access::get_required_live_range
(this=0x7f8f6d259928) at
../mesa-18.3.1/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp:936
keep_for_full_loop = true
enclosing_scope = 0x7f8ff7beb0c0
enclosing_scope_first_read = 0x7f8ff7beb0c0
enclosing_scope_first_write = 
conditional = 
keep_for_full_loop = 
enclosing_scope_first_read = 
enclosing_scope_first_write = 
conditional = 
enclosing_scope = 

I used MESA_SHADER_DUMP_PATH to dump the shaders, and attached the last one in
chronological order (I assume this is probably the one that crashed).

-- 
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: [GIT PULL] etnaviv-next for 4.21

[Daniel Vetter]

On Fri, Dec 14, 2018 at 11:44:10AM +0100, Lucas Stach wrote:
> Hi Dave,
> 
> nothing major this time, mostly some cleanups that were found on the
> way of reworking the code in preparation for new feature additions.

dim: dea492e0cfcbe8ca592406fefc7ceeaf53f63380 is lacking review
dim: ead5bd82cc3785e68d83cb6a3922e6c91de454e3 is lacking review
dim: 2ef0ebf5cc6b4b40999fe64de1a39c7c68068ecf is lacking review

First two are simple enough that I'm not too lazy to review them, but 3rd
looks like not entirely trivial.  Please get one of the other etnaviv
folks to ack it.

Thanks, Daniel

> 
> Regards,
> Lucas
> 
> The following changes since commit 6fce3a406108ee6c8a61e2a33e52e9198a626ea0:
> 
>   drm/etnaviv: fix bogus fence complete check in timeout handler (2018-11-05 
> 18:14:48 +0100)
> 
> are available in the Git repository at:
> 
>   https://git.pengutronix.de/git/lst/linux etnaviv/next
> 
> for you to fetch changes up to dea492e0cfcbe8ca592406fefc7ceeaf53f63380:
> 
>   drm/etnaviv: remove lastctx member from gpu struct (2018-12-11 12:35:07 
> +0100)
> 
> 
> Lucas Stach (5):
>   drm/etnaviv: kill active fence tracking
>   drm/etnaviv: consolidate hardware fence handling in etnaviv_gpu
>   drm/etnaviv: remove unnecessary local irq disable
>   drm/etnaviv: replace header include with forward declaration
>   drm/etnaviv: remove lastctx member from gpu struct
> 
> Thomas Zimmermann (1):
>   drm/etnaviv: Replace drm_dev_unref with drm_dev_put
> 
>  drivers/gpu/drm/etnaviv/etnaviv_buffer.c |  2 --
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c| 16 +---
>  drivers/gpu/drm/etnaviv/etnaviv_drv.h| 11 ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 37 
> -
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 12 ++--
>  5 files changed, 23 insertions(+), 55 deletions(-)
> ___
> 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 v3 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel

[Sean Paul]

On Sat, Dec 15, 2018 at 02:11:01AM +0530, Jagan Teki wrote:
> Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
> 
> Add panel driver for it.
> 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v2:
> - use simple structure for command init
> - update proper comments on power, reset delay sequnce
> - fix to use set_display_off in disable function
> - move mode type to structure
> - drop refres rate value, let drm compute
> 
>  MAINTAINERS   |   6 +
>  drivers/gpu/drm/panel/Kconfig |   9 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  .../drm/panel/panel-feiyang-fy07024di26a30d.c | 296 ++
>  4 files changed, 312 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d2928a4d2847..e643238855ea 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4732,6 +4732,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
>  S:   Maintained
>  F:   drivers/gpu/drm/tve200/
>  
> +DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
> +M:   Jagan Teki 
> +S:   Maintained
> +F:   drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> +F:   
> Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
> +
>  DRM DRIVER FOR ILITEK ILI9225 PANELS
>  M:   David Lechner 
>  S:   Maintained

As I mentioned on IRC, this will be drm-misc maintained with the other panels,
no need to have a dedicated MAINTAINERS entry. You'll get pulled from
get_maintainers.pl as a majority commit signer

> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index d93b2ba709bc..cb8ca93550cf 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -38,6 +38,15 @@ config DRM_PANEL_SIMPLE
> that it can be automatically turned off when the panel goes into a
> low power state.
>  
> +config DRM_PANEL_FEIYANG_FY07024DI26A30D
> + tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y if you want to enable support for panels based on the
> +   Feiyang FY07024DI26A30-D MIPI-DSI interface.
> +
>  config DRM_PANEL_ILITEK_IL9322
>   tristate "Ilitek ILI9322 320x240 QVGA panels"
>   depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 6a9b4cec1891..0fa0ef69e109 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -2,6 +2,7 @@
>  obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
>  obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
>  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
> +obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += 
> panel-feiyang-fy07024di26a30d.o
>  obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
>  obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
>  obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
> diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c 
> b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> new file mode 100644
> index ..4abccbf62c3c
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> @@ -0,0 +1,296 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Amarula Solutions
> + * Author: Jagan Teki 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#define FEIYANG_INIT_CMD_LEN 2
> +
> +struct feiyang {
> + struct drm_panelpanel;
> + struct mipi_dsi_device  *dsi;
> +
> + struct backlight_device *backlight;
> + struct regulator*dvdd;
> + struct regulator*avdd;
> + struct gpio_desc*reset;
> +};
> +
> +static inline struct feiyang *panel_to_feiyang(struct drm_panel *panel)
> +{
> + return container_of(panel, struct feiyang, panel);
> +}
> +
> +struct feiyang_init_cmd {
> + u8 data[FEIYANG_INIT_CMD_LEN];
> +};
> +
> +static const struct feiyang_init_cmd feiyang_init_cmds[] = {
> + { .data = { 0x80, 0x58 } },
> + { .data = { 0x81, 0x47 } },
> + { .data = { 0x82, 0xD4 } },
> + { .data = { 0x83, 0x88 } },
> + { .data = { 0x84, 0xA9 } },
> + { .data = { 0x85, 0xC3 } },
> + { .data = { 0x86, 0x82 } },
> +};
> +
> +static int feiyang_prepare(struct drm_panel *panel)
> +{
> + struct feiyang *ctx = panel_to_feiyang(panel);
> + struct mipi_dsi_device *dsi = ctx->dsi;
> + unsigned int i;
> + int ret;
> +
> + ret = regulator_enable(ctx->dvdd);
> + if (ret)
> + return ret;
> +
> + /* T1 (dvdd start + dvdd rise) 0 < T1 <= 10ms */
> + msleep(10);
> +
> + ret = regulator_enable(ctx->avdd);
> + if (ret)
> + return ret;
> +
> + /* T3 (dvdd rise + avdd start 

[Bug 108754] hard crash of amdgpu in 4.20-rc

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=108585

-- 
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 108585] *ERROR* hw_init of IP block failed -22

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=108754

-- 
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 108754] hard crash of amdgpu in 4.20-rc

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher  ---
(In reply to Dan Horák from comment #1)
> Not a problem anymore with 4.20.0-0.rc6.git0.1.fc30.op.1.ppc64le (contains
> the reset fix from https://bugs.freedesktop.org/show_bug.cgi?id=108585#c15)

Should these patches go upstream?  Can you confirm they fix your issues?

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

[Bug 108585] *ERROR* hw_init of IP block failed -22

[bugzilla-daemon]

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

--- Comment #18 from Alex Deucher  ---
(In reply to Dan Horák from comment #17)
> Fedora/ppc64le users can find a pre-built kernel with the patchset at
> https://copr.fedorainfracloud.org/coprs/sharkcz/talos-kernel/build/817728/

Should these patches go upstream?  Can you confirm they fix your issues?

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

[Bug 109063] libdrm amdgpu.ids is missing raven ridge gpu ids

[bugzilla-daemon]

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

Bug ID: 109063
   Summary: libdrm amdgpu.ids is missing raven ridge gpu ids
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: libdrm
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: irher...@gmail.com

This bug is mostly cosmetic, however
https://gitlab.freedesktop.org/mesa/drm/blob/master/data/amdgpu.ids is missing
pci ids for newer AMD Raven Ridge apus like 2200G/2400G.

>From Xorg.0.log
[ 2.968] (--) AMDGPU(0): Chipset: "Unknown AMD Radeon GPU" (ChipID =
0x15dd)

-- 
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/amd/display: Pass app_tf by value rather than by reference

[Wentland, Harry]

On 2018-12-11 5:07 p.m., Nick Desaulniers wrote:
> On Tue, Dec 11, 2018 at 1:42 PM Nathan Chancellor
>  wrote:
>>
>> On Tue, Dec 11, 2018 at 01:25:00PM -0800, Nick Desaulniers wrote:
>>> On Mon, Dec 10, 2018 at 3:42 PM Nathan Chancellor
>>>  wrote:

 Clang warns when an expression that equals zero is used as a null
 pointer constant (in lieu of NULL):

 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4435:3:
 warning: expression which evaluates to zero treated as a null pointer
 constant of type 'const enum color_transfer_func *'
 [-Wnon-literal-null-conversion]
 TRANSFER_FUNC_UNKNOWN,
 ^
 1 warning generated.

 This warning is caused by commit bb47de736661 ("drm/amdgpu: Set FreeSync
 state using drm VRR properties") and it could be solved by using NULL
 instead of TRANSFER_FUNC_UNKNOWN or casting TRANSFER_FUNC_UNKNOWN as a
 pointer. However, after looking into it, there doesn't appear to be a
 good reason to pass app_tf by reference as it is never mutated along the
 way. This is the only code path in which app_tf is used:

 mod_freesync_build_vrr_infopacket ->
 build_vrr_infopacket_v2 ->
 build_vrr_infopacket_fs2_data

 Neither mod_freesync_build_vrr_infopacket or build_vrr_infopacket_v2
 modify app_tf's value and build_vrr_infopacket_fs2_data expects just
 the value so we can avoid dereferencing anything by just passing in
 app_tf's value to mod_freesync_build_vrr_infopacket and
 build_vrr_infopacket_v2.

 There is no functional change because build_vrr_infopacket_fs2_data
 doesn't do anything if TRANSFER_FUNC_UNKNOWN is passed to it, the same
 as not calling build_vrr_infopacket_fs2_data at all like before this
 change when NULL was used for app_tf.
>>>
>>> Nathan,
>>> Thanks for sending this patch.  I was hoping to provide review sooner,
>>> but have been quite busy lately.
>>>
>>
>> Late review is better than no review, I appeciate you taking the time to
>> do this!
>>
>>> Yeah, especially for LP64 targets, the pointer to enum is larger than
>>> just the enum, and if it's not being updated ("in/out paramter")
>>> there's no need to pass by pointer.
>>>
>>
>> Thanks for confirming!
>>

 Signed-off-by: Nathan Chancellor 
 ---
  drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 7 +++
  drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h  | 2 +-
  2 files changed, 4 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c 
 b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
 index 620a171620ee..520665a9d81a 100644
 --- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
 +++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
 @@ -656,7 +656,7 @@ static void build_vrr_infopacket_v1(enum signal_type 
 signal,

  static void build_vrr_infopacket_v2(enum signal_type signal,
 const struct mod_vrr_params *vrr,
 -   const enum color_transfer_func *app_tf,
 +   enum color_transfer_func app_tf,
 struct dc_info_packet *infopacket)
  {
 unsigned int payload_size = 0;
 @@ -664,8 +664,7 @@ static void build_vrr_infopacket_v2(enum signal_type 
 signal,
 build_vrr_infopacket_header_v2(signal, infopacket, _size);
 build_vrr_infopacket_data(vrr, infopacket);

 -   if (app_tf != NULL)
 -   build_vrr_infopacket_fs2_data(*app_tf, infopacket);
 +   build_vrr_infopacket_fs2_data(app_tf, infopacket);

 build_vrr_infopacket_checksum(_size, infopacket);

 @@ -676,7 +675,7 @@ void mod_freesync_build_vrr_infopacket(struct 
 mod_freesync *mod_freesync,
 const struct dc_stream_state *stream,
 const struct mod_vrr_params *vrr,
 enum vrr_packet_type packet_type,
 -   const enum color_transfer_func *app_tf,
 +   enum color_transfer_func app_tf,
 struct dc_info_packet *infopacket)
  {
 /* SPD info packet for FreeSync */
 diff --git a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h 
 b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
 index 949a8b62aa98..063af6258fd9 100644
 --- a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
 +++ b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
 @@ -145,7 +145,7 @@ void mod_freesync_build_vrr_infopacket(struct 
 mod_freesync *mod_freesync,
 const struct dc_stream_state *stream,
 const struct mod_vrr_params *vrr,
 enum vrr_packet_type packet_type,
 -   const enum color_transfer_func *app_tf,
 +   enum 

[DPU PATCH v2] drm/msm/dpu: Change RGB565 and BGR565 format map.

[Tanmay Shah]

Red and Blue colors will be interchanged on display with
current format maps for RGB565 and BGR565.

Change both format maps to display correct colors.

Signed-off-by: Tanmay Shah 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index d53abc8ce670..f59fe1a9f4b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -263,13 +263,13 @@ static const struct dpu_format dpu_format_map[] = {
 
INTERLEAVED_RGB_FMT(RGB565,
0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
-   C1_B_Cb, C0_G_Y, C2_R_Cr, 0, 3,
+   C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
false, 2, 0,
DPU_FETCH_LINEAR, 1),
 
INTERLEAVED_RGB_FMT(BGR565,
0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
-   C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
+   C1_B_Cb, C0_G_Y, C2_R_Cr, 0, 3,
false, 2, 0,
DPU_FETCH_LINEAR, 1),
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Bug 108992] Regression: Lenovo e585 (ryzen 2500u) freezes during boot with 4.20-rc5/rc6, amdgpu error

[bugzilla-daemon]

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

--- Comment #8 from Alex Deucher  ---
Can you bisect?

-- 
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 i-g-t] igt: add timeline test cases v2

[Wentland, Harry]

On 2018-12-11 5:37 a.m., Chunming Zhou wrote:
> v2: adapt to new transfer ioctl
> 
> Signed-off-by: Chunming Zhou 

+igt-dev

I think intel-gfx still works for IGT development but most of the IGT work 
happens on igt-...@lists.freedesktop.org now.

Harry

> ---
>  include/drm-uapi/drm.h   |   33 ++
>  lib/igt_syncobj.c|  206 
>  lib/igt_syncobj.h|   19 +
>  tests/meson.build|1 +
>  tests/syncobj_timeline.c | 1032 ++
>  5 files changed, 1291 insertions(+)
>  create mode 100644 tests/syncobj_timeline.c
> 
> diff --git a/include/drm-uapi/drm.h b/include/drm-uapi/drm.h
> index 85c685a2..dcd245d9 100644
> --- a/include/drm-uapi/drm.h
> +++ b/include/drm-uapi/drm.h
> @@ -731,6 +731,8 @@ struct drm_syncobj_handle {
>  
>  #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
>  #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
> +/* wait for time point to become available */
> +#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2)
>  struct drm_syncobj_wait {
>   __u64 handles;
>   /* absolute timeout */
> @@ -741,11 +743,38 @@ struct drm_syncobj_wait {
>   __u32 pad;
>  };
>  
> +struct drm_syncobj_timeline_wait {
> +__u64 handles;
> +/* wait on specific timeline point for every handles*/
> +__u64 points;
> +/* absolute timeout */
> +__s64 timeout_nsec;
> +__u32 count_handles;
> +__u32 flags;
> +__u32 first_signaled; /* only valid when not waiting all */
> +__u32 pad;
> +};
> +
>  struct drm_syncobj_array {
>   __u64 handles;
>   __u32 count_handles;
>   __u32 pad;
>  };
> +struct drm_syncobj_timeline_array {
> +   __u64 handles;
> +   __u64 points;
> +   __u32 count_handles;
> +   __u32 pad;
> +};
> +
> +struct drm_syncobj_transfer {
> +__u32 src_handle;
> +__u32 dst_handle;
> +__u64 src_point;
> +__u64 dst_point;
> +__u32 flags;
> +__u32 pad;
> +};
>  
>  /* Query current scanout sequence number */
>  struct drm_crtc_get_sequence {
> @@ -902,6 +931,10 @@ extern "C" {
>  #define DRM_IOCTL_MODE_LIST_LESSEES  DRM_IOWR(0xC7, struct 
> drm_mode_list_lessees)
>  #define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct 
> drm_mode_get_lease)
>  #define DRM_IOCTL_MODE_REVOKE_LEASE  DRM_IOWR(0xC9, struct 
> drm_mode_revoke_lease)
> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT DRM_IOWR(0xCA, struct 
> drm_syncobj_timeline_wait)
> +#define DRM_IOCTL_SYNCOBJ_QUERY DRM_IOWR(0xCB, struct 
> drm_syncobj_timeline_array)
> +#define DRM_IOCTL_SYNCOBJ_TRANSFERDRM_IOWR(0xCC, struct 
> drm_syncobj_transfer)
> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNALDRM_IOWR(0xCD, struct 
> drm_syncobj_timeline_array)
>  
>  /**
>   * Device specific ioctls should only be in their respective headers
> diff --git a/lib/igt_syncobj.c b/lib/igt_syncobj.c
> index d9114ca8..efa2adc4 100644
> --- a/lib/igt_syncobj.c
> +++ b/lib/igt_syncobj.c
> @@ -286,3 +286,209 @@ syncobj_signal(int fd, uint32_t *handles, uint32_t 
> count)
>  {
>   igt_assert_eq(__syncobj_signal(fd, handles, count), 0);
>  }
> +
> +static int
> +__syncobj_timeline_signal(int fd, uint32_t *handles, uint64_t *points, 
> uint32_t count)
> +{
> + struct drm_syncobj_timeline_array array = { 0 };
> + int err = 0;
> +
> + array.handles = to_user_pointer(handles);
> + array.points = to_user_pointer(points);
> + array.count_handles = count;
> + if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL, ))
> + err = -errno;
> + return err;
> +}
> +
> +/**
> + * syncobj_signal:
> + * @fd: The DRM file descriptor.
> + * @handles: Array of syncobj handles to signal
> + * @points: List of point of handles to signal.
> + * @count: Count of syncobj handles.
> + *
> + * Signal a set of syncobjs.
> + */
> +void
> +syncobj_timeline_signal(int fd, uint32_t *handles, uint64_t *points, 
> uint32_t count)
> +{
> + igt_assert_eq(__syncobj_timeline_signal(fd, handles, points, count), 0);
> +}
> +int
> +__syncobj_timeline_wait_ioctl(int fd, struct drm_syncobj_timeline_wait *args)
> +{
> + int err = 0;
> + if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, args))
> + err = -errno;
> + return err;
> +}
> +static int
> +__syncobj_timeline_wait(int fd, uint32_t *handles, uint64_t *points,
> + unsigned num_handles,
> + int64_t timeout_nsec, unsigned flags,
> + uint32_t *first_signaled)
> +{
> + struct drm_syncobj_timeline_wait args;
> + int ret;
> +
> + args.handles = to_user_pointer(handles);
> + args.points = (uint64_t)to_user_pointer(points);
> + args.timeout_nsec = timeout_nsec;
> + args.count_handles = num_handles;
> + args.flags = flags;
> + args.first_signaled = 0;
> + args.pad = 0;
> +
> + ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, );
> + if (ret < 0)
> + return -errno;
> +
> 

[Bug 201991] amdgpu: clock management is disabled for the 4K resolution with polaris 10

[bugzilla-daemon]

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

--- Comment #2 from fin4...@hotmail.com ---
(In reply to nancy from comment #1)
> (In reply to fin4478 from comment #0)
> 
> > simple app for the amdgpu sys interface
> 
> 
> 
> You might consider if you are trying out radeon-profile.
> 
> https://github.com/marazmista/radeon-profile

That uses the same sysfs api and uses old qt or special  modules (like
qtchartview) that are not compatible with latest qt packages. In other words
that app is broken on several distributions. When programming simple GUIs, use
python gtk that does not break so easily.

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

[radeon-alex:amd-18.50 1284/1415] drivers/gpu/drm/v3d/v3d_sched.c:157:44: error: 'job_q' undeclared; did you mean 'job'?

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-18.50
head:   88a0039cb034176ee3416dd0c3a49feea2f446ab
commit: a26f88704ef76f0213692b3b04f210de6e9e8676 [1284/1415] drm/scheduler: fix 
build error due to change in scheduler struct
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a26f88704ef76f0213692b3b04f210de6e9e8676
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm 

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

   In file included from include/linux/swab.h:5:0,
from arch/arm/include/asm/opcodes.h:89,
from arch/arm/include/asm/bug.h:7,
from include/linux/bug.h:5,
from include/linux/thread_info.h:12,
from include/asm-generic/current.h:5,
from ./arch/arm/include/generated/asm/current.h:1,
from include/linux/sched.h:12,
from include/linux/kthread.h:6,
from drivers/gpu/drm/v3d/v3d_sched.c:21:
   drivers/gpu/drm/v3d/v3d_sched.c: In function 'v3d_job_timedout':
>> drivers/gpu/drm/v3d/v3d_sched.c:157:44: error: 'job_q' undeclared (first use 
>> in this function); did you mean 'job'?
 u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
   ^
   include/uapi/linux/swab.h:114:54: note: in definition of macro '__swab32'
#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
 ^
   include/linux/byteorder/generic.h:89:21: note: in expansion of macro 
'__le32_to_cpu'
#define le32_to_cpu __le32_to_cpu
^
>> arch/arm/include/asm/io.h:310:32: note: in expansion of macro 'readl_relaxed'
#define readl(c)  ({ u32 __v = readl_relaxed(c); __iormb(); __v; })
   ^
>> drivers/gpu/drm/v3d/v3d_drv.h:166:37: note: in expansion of macro 'readl'
#define V3D_CORE_READ(core, offset) readl(v3d->core_regs[core] + offset)
^
>> drivers/gpu/drm/v3d/v3d_sched.c:157:13: note: in expansion of macro 
>> 'V3D_CORE_READ'
 u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
^
>> drivers/gpu/drm/v3d/v3d_sched.c:157:30: note: in expansion of macro 
>> 'V3D_CLE_CTNCA'
 u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
 ^
   drivers/gpu/drm/v3d/v3d_sched.c:157:44: note: each undeclared identifier is 
reported only once for each function it appears in
 u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
   ^
   include/uapi/linux/swab.h:114:54: note: in definition of macro '__swab32'
#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
 ^
   include/linux/byteorder/generic.h:89:21: note: in expansion of macro 
'__le32_to_cpu'
#define le32_to_cpu __le32_to_cpu
^
>> arch/arm/include/asm/io.h:310:32: note: in expansion of macro 'readl_relaxed'
#define readl(c)  ({ u32 __v = readl_relaxed(c); __iormb(); __v; })
   ^
>> drivers/gpu/drm/v3d/v3d_drv.h:166:37: note: in expansion of macro 'readl'
#define V3D_CORE_READ(core, offset) readl(v3d->core_regs[core] + offset)
^
>> drivers/gpu/drm/v3d/v3d_sched.c:157:13: note: in expansion of macro 
>> 'V3D_CORE_READ'
 u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
^
>> drivers/gpu/drm/v3d/v3d_sched.c:157:30: note: in expansion of macro 
>> 'V3D_CLE_CTNCA'
 u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
 ^
>> drivers/gpu/drm/v3d/v3d_sched.c:158:30: error: implicit declaration of 
>> function 'V3D_CLE_CTNRA'; did you mean 'V3D_CLE_CTNCA'? 
>> [-Werror=implicit-function-declaration]
 u32 ctra = V3D_CORE_READ(0, V3D_CLE_CTNRA(job_q));
 ^
   include/uapi/linux/swab.h:114:54: note: in definition of macro '__swab32'
#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
 ^
   include/linux/byteorder/generic.h:89:21: note: in expansion of macro 
'__le32_to_cpu'
#define le32_to_cpu __le32_to_cpu
^
>> arch/arm/include/asm/io.h:310:32: note: in expansion of macro 'readl_relaxed'
#define readl(c)  ({ u32 __v = readl_relaxed(c); __iormb(); __v; })
   ^
>> drivers/gpu/drm/v3d/v3d_drv.h:166:37: note: in expansion of macro 'readl'
#define 

Re: [DPU PATCH v1] drm/msm/dpu: Change RGB565 and BGR565 format map.

[jshekhar]

On 2018-12-15 00:04, jshek...@codeaurora.org wrote:

On 2018-12-14 23:53, Tanmay Shah wrote:

Red and Blue colors will be interchanged on display with
current format maps for RGB565 and BGR565.

Change both format maps to dispaly correct colors.



spelling: dispaly/display


Signed-off-by: Tanmay Shah 


LGTM.

Reviewed-by: Jayant Shekhar 


---
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index d53abc8ce670..f59fe1a9f4b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -263,13 +263,13 @@ static const struct dpu_format dpu_format_map[] 
= {


INTERLEAVED_RGB_FMT(RGB565,
0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
-   C1_B_Cb, C0_G_Y, C2_R_Cr, 0, 3,
+   C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
false, 2, 0,
DPU_FETCH_LINEAR, 1),

INTERLEAVED_RGB_FMT(BGR565,
0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
-   C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
+   C1_B_Cb, C0_G_Y, C2_R_Cr, 0, 3,
false, 2, 0,
DPU_FETCH_LINEAR, 1),

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

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

Re: [DPU PATCH v1] drm/msm/dpu: Change RGB565 and BGR565 format map.

[jshekhar]

On 2018-12-14 23:53, Tanmay Shah wrote:

Red and Blue colors will be interchanged on display with
current format maps for RGB565 and BGR565.

Change both format maps to dispaly correct colors.

Signed-off-by: Tanmay Shah 


LGTM.

Reviewed-by: Jayant Shekhar 


---
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index d53abc8ce670..f59fe1a9f4b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -263,13 +263,13 @@ static const struct dpu_format dpu_format_map[] = 
{


INTERLEAVED_RGB_FMT(RGB565,
0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
-   C1_B_Cb, C0_G_Y, C2_R_Cr, 0, 3,
+   C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
false, 2, 0,
DPU_FETCH_LINEAR, 1),

INTERLEAVED_RGB_FMT(BGR565,
0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
-   C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
+   C1_B_Cb, C0_G_Y, C2_R_Cr, 0, 3,
false, 2, 0,
DPU_FETCH_LINEAR, 1),

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

[PATCH v3 1/2] drm: Add color management LUT validation helper (v3)

[Matt Roper]

Some hardware may place additional restrictions on the gamma/degamma
curves described by our LUT properties.  E.g., that a gamma curve never
decreases or that the red/green/blue channels of a LUT's entries must be
equal.  Let's add a helper function that drivers can use to test that a
userspace-provided LUT is valid and doesn't violate hardware
requirements.

v2:
 - Combine into a single helper that just takes a bitmask of the tests
   to apply.  (Brian Starkey)
 - Add additional check (always performed) that LUT property blob size
   is always a multiple of the LUT entry size.  (stolen from ARM driver)

v3:
 - Drop the LUT size check again since
   drm_atomic_replace_property_blob_from_id() already covers this for
   us.  (Alexandru Gheorghe)

Cc: Uma Shankar 
Cc: Swati Sharma 
Cc: Brian Starkey 
Signed-off-by: Matt Roper 
Reviewed-by(v1): Brian Starkey 
Reviewed-by: Alexandru Gheorghe 
Reviewed-By: Uma Shankar 
---
 drivers/gpu/drm/drm_color_mgmt.c | 54 
 include/drm/drm_color_mgmt.h |  5 
 2 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 07dcf47daafe..684afcace58f 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -462,3 +462,57 @@ int drm_plane_create_color_properties(struct drm_plane 
*plane,
return 0;
 }
 EXPORT_SYMBOL(drm_plane_create_color_properties);
+
+/**
+ * drm_color_lut_check - check validity of lookup table
+ * @lut: property blob containing LUT to check
+ * @tests: bitmask of tests to run
+ *
+ * Helper to check whether a userspace-provided lookup table is valid and
+ * satisfies hardware requirements.  Drivers pass a bitmask indicating which of
+ * the following tests should be performed:
+ *
+ * "DRM_COLOR_LUT_EQUAL_CHANNELS":
+ * Checks whether the entries of a LUT all have equal values for the red,
+ * green, and blue channels.  Intended for hardware that only accepts a
+ * single value per LUT entry and assumes that value applies to all three
+ * color components.
+ *
+ * "DRM_COLOR_LUT_INCREASING":
+ * Checks whether the entries of a LUT are always flat or increasing
+ * (never decreasing).
+ *
+ * Returns 0 on success, -EINVAL on failure.
+ */
+int drm_color_lut_check(struct drm_property_blob *lut,
+   uint32_t tests)
+{
+   struct drm_color_lut *entry;
+   int i;
+
+   if (!lut || !tests)
+   return 0;
+
+   entry = lut->data;
+   for (i = 0; i < drm_color_lut_size(lut); i++) {
+   if (tests & DRM_COLOR_LUT_EQUAL_CHANNELS) {
+   if (entry[i].red != entry[i].blue ||
+   entry[i].red != entry[i].green) {
+   DRM_DEBUG_KMS("All LUT entries must have equal 
r/g/b\n");
+   return -EINVAL;
+   }
+   }
+
+   if (i > 0 && tests & DRM_COLOR_LUT_INCREASING) {
+   if (entry[i].red < entry[i - 1].red ||
+   entry[i].green < entry[i - 1].green ||
+   entry[i].blue < entry[i - 1].blue) {
+   DRM_DEBUG_KMS("LUT entries must never 
decrease.\n");
+   return -EINVAL;
+   }
+   }
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_color_lut_check);
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 90ef9996d9a4..7de16f70bcc3 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -69,4 +69,9 @@ int drm_plane_create_color_properties(struct drm_plane *plane,
  u32 supported_ranges,
  enum drm_color_encoding default_encoding,
  enum drm_color_range default_range);
+
+#define DRM_COLOR_LUT_EQUAL_CHANNELS BIT(0)
+#define DRM_COLOR_LUT_INCREASING BIT(1)
+int drm_color_lut_check(struct drm_property_blob *lut,
+   uint32_t tests);
 #endif
-- 
2.14.4

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

[PATCH v3 2/2] drm/i915: Validate userspace-provided color management LUT's (v3)

[Matt Roper]

We currently program userspace-provided gamma and degamma LUT's into our
hardware without really checking to see whether they satisfy our
hardware's rules.  We should try to catch tables that are invalid for
our hardware early and reject the atomic transaction.

All of our platforms that accept a degamma LUT expect that the entries
in the LUT are always flat or increasing, never decreasing.  Also, our
GLK and ICL platforms only accept degamma tables with r=g=b entries; so
we should also add the relevant checks for that in anticipation of
degamma support landing for those platforms.

v2:
 - Use new API (single check function with bitmask of tests to apply)
 - Call helper for our gamma table as well (with no additional tests
   specified) so that the table size will be validated.

v3:
 - Don't call on the gamma table since the LUT size is already tested at
   property blob upload and we don't have any additional hardware
   constraints for that LUT.

Cc: Uma Shankar 
Cc: Swati Sharma 
Signed-off-by: Matt Roper 
Reviewed-By: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_color.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 37fd9ddf762e..6c5d030236b9 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -609,10 +609,26 @@ int intel_color_check(struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
size_t gamma_length, degamma_length;
+   uint32_t tests = DRM_COLOR_LUT_INCREASING;
 
degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
 
+   /*
+* All of our platforms mandate that the degamma curve be
+* non-decreasing.  Additionally, GLK and gen11 only accept a single
+* value for red, green, and blue in the degamma table.  Make sure
+* userspace didn't try to pass us something we can't handle.
+*
+* We don't have any extra hardware constraints on the gamma table,
+* so no need to explicitly check it.
+*/
+   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+   tests |= DRM_COLOR_LUT_EQUAL_CHANNELS;
+
+   if (drm_color_lut_check(crtc_state->base.degamma_lut, tests) != 0)
+   return -EINVAL;
+
/*
 * We allow both degamma & gamma luts at the right size or
 * NULL.
-- 
2.14.4

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

[PATCH v3 0/2] Add gamma/degamma LUT validation helper

[Matt Roper]

Previous version of the series was here:
  https://lists.freedesktop.org/archives/dri-devel/2018-December/200505.html

The only change in this version is dropping the extra LUT size test I
added in v2; Alexandru pointed out that that already gets tested when a
new atomic blob is uploaded.


Matt Roper (2):
  drm: Add color management LUT validation helper (v3)
  drm/i915: Validate userspace-provided color management LUT's (v3)

 drivers/gpu/drm/drm_color_mgmt.c   | 54 ++
 drivers/gpu/drm/i915/intel_color.c | 16 +++
 include/drm/drm_color_mgmt.h   |  5 
 3 files changed, 75 insertions(+)

-- 
2.14.4

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

[Bug 103949] REG_WAIT timeout - dce110_stream_encoder_dp_blank line:930 - 4.15-rc1

[bugzilla-daemon]

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

--- Comment #3 from Jerry Zuo  ---
The issue is just getting fixed. Will show up soon.

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

Re: [PATCH v2 1/2] drm: Add color management LUT validation helper (v2)

[Matt Roper]

On Fri, Dec 14, 2018 at 09:43:08AM +, Alexandru-Cosmin Gheorghe wrote:
...
> > +int drm_color_lut_check(struct drm_property_blob *lut,
> > +uint32_t tests)
> > +{
> > +   struct drm_color_lut *entry;
> > +   int i;
> > +
> > +   if (!lut)
> > +   return 0;
> > +
> > +   if (lut->length % sizeof(struct drm_color_lut)) {
> > +   DRM_DEBUG_KMS("LUT size (%lu) is not a multiple of LUT entry 
> > size (%lu)\n",
> > + lut->length, sizeof(struct drm_color_lut));
> > +   return -EINVAL;
> > +   }
> > +
> 
> Isn't this already covered by drm_atomic_replace_property_blob_from_id ?
> Other than that feel free to add:
> 
> Reviewed-by: Alexandru Gheorghe 

Ah, you're right.  I thought there was a test somewhere but couldn't
find where we did it when I looked earlier.  I'll drop this extra test;
thanks for pointing that out.


Matt

> 
> > +   if (!tests)
> > +   return 0;
> > +
> > +   entry = lut->data;
> > +   for (i = 0; i < drm_color_lut_size(lut); i++) {
> > +   if (tests & DRM_COLOR_LUT_EQUAL_CHANNELS) {
> > +   if (entry[i].red != entry[i].blue ||
> > +   entry[i].red != entry[i].green) {
> > +   DRM_DEBUG_KMS("All LUT entries must have equal 
> > r/g/b\n");
> > +   return -EINVAL;
> > +   }
> > +   }
> > +
> > +   if (i > 0 && tests & DRM_COLOR_LUT_INCREASING) {
> > +   if (entry[i].red < entry[i - 1].red ||
> > +   entry[i].green < entry[i - 1].green ||
> > +   entry[i].blue < entry[i - 1].blue) {
> > +   DRM_DEBUG_KMS("LUT entries must never 
> > decrease.\n");
> > +   return -EINVAL;
> > +   }
> > +   }
> > +   }
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_color_lut_check);
> > diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> > index 90ef9996d9a4..7de16f70bcc3 100644
> > --- a/include/drm/drm_color_mgmt.h
> > +++ b/include/drm/drm_color_mgmt.h
> > @@ -69,4 +69,9 @@ int drm_plane_create_color_properties(struct drm_plane 
> > *plane,
> >   u32 supported_ranges,
> >   enum drm_color_encoding default_encoding,
> >   enum drm_color_range default_range);
> > +
> > +#define DRM_COLOR_LUT_EQUAL_CHANNELS BIT(0)
> > +#define DRM_COLOR_LUT_INCREASING BIT(1)
> > +int drm_color_lut_check(struct drm_property_blob *lut,
> > +   uint32_t tests);
> >  #endif
> > -- 
> > 2.14.4
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Cheers,
> Alex G

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[DPU PATCH v1] drm/msm/dpu: Change RGB565 and BGR565 format map.

[Tanmay Shah]

Red and Blue colors will be interchanged on display with
current format maps for RGB565 and BGR565.

Change both format maps to dispaly correct colors.

Signed-off-by: Tanmay Shah 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index d53abc8ce670..f59fe1a9f4b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -263,13 +263,13 @@ static const struct dpu_format dpu_format_map[] = {
 
INTERLEAVED_RGB_FMT(RGB565,
0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
-   C1_B_Cb, C0_G_Y, C2_R_Cr, 0, 3,
+   C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
false, 2, 0,
DPU_FETCH_LINEAR, 1),
 
INTERLEAVED_RGB_FMT(BGR565,
0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
-   C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
+   C1_B_Cb, C0_G_Y, C2_R_Cr, 0, 3,
false, 2, 0,
DPU_FETCH_LINEAR, 1),
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Bug 201991] amdgpu: clock management is disabled for the 4K resolution with polaris 10

[bugzilla-daemon]

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

nancy (nancy...@gmx.com) changed:

   What|Removed |Added

 CC||nancy...@gmx.com

--- Comment #1 from nancy (nancy...@gmx.com) ---
(In reply to fin4478 from comment #0)

> simple app for the amdgpu sys interface



You might consider if you are trying out radeon-profile.

https://github.com/marazmista/radeon-profile

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

[DPU PATCH v2] drm/msm/dpu: Clean up dpu hw interrupts

[Jayant Shekhar]

Remove unused functions and macros from dpu hw interrupts
file.

changes in v2:
  Removed clear_interrupt_status (Jordan Crouse)

Signed-off-by: Jayant Shekhar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 44 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 44 ---
 2 files changed, 88 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index c0b7f00..8a28a03 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -170,10 +170,6 @@
 /**
  * AD4 interrupt status bit definitions
  */
-#define DPU_INTR_BRIGHTPR_UPDATED BIT(4)
-#define DPU_INTR_DARKENH_UPDATED BIT(3)
-#define DPU_INTR_STREN_OUTROI_UPDATED BIT(2)
-#define DPU_INTR_STREN_INROI_UPDATED BIT(1)
 #define DPU_INTR_BACKLIGHT_UPDATED BIT(0)
 /**
  * struct dpu_intr_reg - array of DPU register sets
@@ -782,18 +778,6 @@ static int dpu_hw_intr_irqidx_lookup(enum dpu_intr_type 
intr_type,
return -EINVAL;
 }
 
-static void dpu_hw_intr_set_mask(struct dpu_hw_intr *intr, uint32_t reg_off,
-   uint32_t mask)
-{
-   if (!intr)
-   return;
-
-   DPU_REG_WRITE(>hw, reg_off, mask);
-
-   /* ensure register writes go through */
-   wmb();
-}
-
 static void dpu_hw_intr_dispatch_irq(struct dpu_hw_intr *intr,
void (*cbfunc)(void *, int),
void *arg)
@@ -1004,18 +988,6 @@ static int dpu_hw_intr_disable_irqs(struct dpu_hw_intr 
*intr)
return 0;
 }
 
-static int dpu_hw_intr_get_valid_interrupts(struct dpu_hw_intr *intr,
-   uint32_t *mask)
-{
-   if (!intr || !mask)
-   return -EINVAL;
-
-   *mask = IRQ_SOURCE_MDP | IRQ_SOURCE_DSI0 | IRQ_SOURCE_DSI1
-   | IRQ_SOURCE_HDMI | IRQ_SOURCE_EDP;
-
-   return 0;
-}
-
 static void dpu_hw_intr_get_interrupt_statuses(struct dpu_hw_intr *intr)
 {
int i;
@@ -1065,19 +1037,6 @@ static void dpu_hw_intr_clear_intr_status_nolock(struct 
dpu_hw_intr *intr,
wmb();
 }
 
-static void dpu_hw_intr_clear_interrupt_status(struct dpu_hw_intr *intr,
-   int irq_idx)
-{
-   unsigned long irq_flags;
-
-   if (!intr)
-   return;
-
-   spin_lock_irqsave(>irq_lock, irq_flags);
-   dpu_hw_intr_clear_intr_status_nolock(intr, irq_idx);
-   spin_unlock_irqrestore(>irq_lock, irq_flags);
-}
-
 static u32 dpu_hw_intr_get_interrupt_status(struct dpu_hw_intr *intr,
int irq_idx, bool clear)
 {
@@ -1113,16 +1072,13 @@ static u32 dpu_hw_intr_get_interrupt_status(struct 
dpu_hw_intr *intr,
 
 static void __setup_intr_ops(struct dpu_hw_intr_ops *ops)
 {
-   ops->set_mask = dpu_hw_intr_set_mask;
ops->irq_idx_lookup = dpu_hw_intr_irqidx_lookup;
ops->enable_irq = dpu_hw_intr_enable_irq;
ops->disable_irq = dpu_hw_intr_disable_irq;
ops->dispatch_irqs = dpu_hw_intr_dispatch_irq;
ops->clear_all_irqs = dpu_hw_intr_clear_irqs;
ops->disable_all_irqs = dpu_hw_intr_disable_irqs;
-   ops->get_valid_interrupts = dpu_hw_intr_get_valid_interrupts;
ops->get_interrupt_statuses = dpu_hw_intr_get_interrupt_statuses;
-   ops->clear_interrupt_status = dpu_hw_intr_clear_interrupt_status;
ops->clear_intr_status_nolock = dpu_hw_intr_clear_intr_status_nolock;
ops->get_interrupt_status = dpu_hw_intr_get_interrupt_status;
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
index 61e4cba..4d7a1c7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
@@ -20,13 +20,6 @@
 #include "dpu_hw_util.h"
 #include "dpu_hw_mdss.h"
 
-#define IRQ_SOURCE_MDP BIT(0)
-#define IRQ_SOURCE_DSI0BIT(4)
-#define IRQ_SOURCE_DSI1BIT(5)
-#define IRQ_SOURCE_HDMIBIT(8)
-#define IRQ_SOURCE_EDP BIT(12)
-#define IRQ_SOURCE_MHL BIT(16)
-
 /**
  * dpu_intr_type - HW Interrupt Type
  * @DPU_IRQ_TYPE_WB_ROT_COMP:  WB rotator done
@@ -96,18 +89,6 @@ enum dpu_intr_type {
  */
 struct dpu_hw_intr_ops {
/**
-* set_mask - Programs the given interrupt register with the
-*given interrupt mask. Register value will get overwritten.
-* @intr:   HW interrupt handle
-* @reg_off:MDSS HW register offset
-* @irqmask:IRQ mask value
-*/
-   void (*set_mask)(
-   struct dpu_hw_intr *intr,
-   uint32_t reg,
-   uint32_t irqmask);
-
-   /**
 * irq_idx_lookup - Lookup IRQ index on the HW interrupt type
 * Used for all irq related ops
 * @intr_type:  Interrupt type defined in dpu_intr_type
@@ -177,16 +158,6 @@ struct dpu_hw_intr_ops {

Re: [git pull] drm fixes for 4.20-rc7

[pr-tracker-bot]

The pull request you sent on Fri, 14 Dec 2018 11:54:15 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-12-14

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/92de1de51e99910ff0b45b340c95994573a1ad23

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes

[Doug Anderson]

Hi,

On Thu, Dec 13, 2018 at 8:41 PM Viresh Kumar  wrote:
>
> On 12-12-18, 14:18, Jordan Crouse wrote:
> > + gpu_opp_table: opp-table {
> > + compatible = "operating-points-v2-qcom-level";
>
> I think you need to mention "operating-points-v2" as well here.

Are you saying the above should be:
  compatible = "operating-points-v2-qcom-level", "operating-points-v2";

If so I'm not sure I agree.  It's _not_ really compatible with the
"operating-points-v2" binding.  If you had a driver that had never
heard of "operating-points-v2-qcom-level" and had only heard of
"operating-points-v2" and it took a look at this node it would have no
idea what to do with it.

I'll also note that other instances posted to the list don't list both:

https://patchwork.kernel.org/patch/10725801/ - RPM / RPMH PD bindings
https://patchwork.kernel.org/patch/10725793/ - RPMH PD device tree for sdm845

The bindings patch also makes no mention of needing
"operating-points-v2".  I think the common case when a fallback is
required it is explicitly called out in the bindings:

https://patchwork.kernel.org/patch/10725803/ - qcom-opp bindings


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

Re: [GIT PULL v2] exynos-drm-next

[Daniel Vetter]

On Fri, Dec 14, 2018 at 05:11:51PM +0100, Daniel Vetter wrote:
> On Fri, Dec 14, 2018 at 04:27:10PM +0900, Inki Dae wrote:
> > Hi Dave,
> > 
> >Just adding configurable plane alpha and pixel blend mode support
> >for FIMD device I missed.
> > 
> >Please kindly let me know if there is any problem.
> 
> Thanks, pulled into drm-next.

btw please don't rebase pull requests right before sending, at least not
as a rule. It's better to have the full history and see when the patches
actually landed, to guesstimate how much testing happened.

Cheers, Daniel

> -Daniel
> 
> > 
> > Thanks,
> > Inki Dae
> > 
> > The following changes since commit 2a3c83f5fe0770d13bbb71b23674886ff4111f44:
> > 
> >   Merge tag 'vmwgfx-next-2018-12-13' of 
> > git://people.freedesktop.org/~thomash/linux into drm-next (2018-12-14 
> > 04:57:45 +1000)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
> > tags/exynos-drm-next-for-v4.21-v2
> > 
> > for you to fetch changes up to 3b5129b3a7c62fdec9cc69b1b3f20917c36ab5d4:
> > 
> >   drm/exynos: fimd: Make pixel blend mode configurable (2018-12-14 15:46:15 
> > +0900)
> > 
> > 
> > Add configurable plane alpha and pixel blend mode support
> > - This patch series adds configurable plane alpha and pixel blend mode
> >   support for FIMD device driver.
> > 
> > 
> > Christoph Manszewski (2):
> >   drm/exynos: fimd: Make plane alpha configurable
> >   drm/exynos: fimd: Make pixel blend mode configurable
> > 
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 123 
> > +--
> >  include/video/samsung_fimd.h |  10 +++
> >  2 files changed, 110 insertions(+), 23 deletions(-)
> > ___
> > 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

-- 
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: [WIP PATCH 13/15] drm/dp_mst: Start tracking per-port VCPI allocations

[Daniel Vetter]

On Thu, Dec 13, 2018 at 08:25:42PM -0500, Lyude Paul wrote:
> There has been a TODO waiting for quite a long time in
> drm_dp_mst_topology.c:
> 
>   /* We cannot rely on port->vcpi.num_slots to update
>* topology_state->avail_slots as the port may not exist if the parent
>* branch device was unplugged. This should be fixed by tracking
>* per-port slot allocation in drm_dp_mst_topology_state instead of
>* depending on the caller to tell us how many slots to release.
>*/
> 
> That's not the only reason we should fix this: forcing the driver to
> track the VCPI allocations throughout a state's atomic check is
> error prone, because it means that extra care has to be taken with the
> order that drm_dp_atomic_find_vcpi_slots() and
> drm_dp_atomic_release_vcpi_slots() are called in in order to ensure
> idempotency. Currently the only driver actually using these helpers,
> i915, doesn't even do this correctly: multiple ->best_encoder() checks
> with i915's current implementation would not be idempotent and would
> over-allocate VCPI slots, something I learned trying to implement
> fallback retraining in MST.
> 
> So: simplify this whole mess, and teach drm_dp_atomic_find_vcpi_slots()
> and drm_dp_atomic_release_vcpi_slots() to track the VCPI allocations for
> each port. This allows us to ensure idempotency without having to rely
> on the driver as much. Additionally: the driver doesn't need to do any
> kind of VCPI slot tracking anymore if it doesn't need it for it's own
> internal state.
> 
> Additionally; this adds a new drm_dp_mst_atomic_check() helper which
> must be used by atomic drivers to perform validity checks for the new
> VCPI allocations incurred by a state.
> 
> Also: update the documentation and make it more obvious that these
> /must/ be called by /all/ atomic drivers supporting MST.
> 
> Changes since v6:
>  - Keep a kref to all of the ports we have allocations on. This required
>a good bit of changing to when we call drm_dp_find_vcpi_slots(),
>mainly that we need to ensure that we only redo VCPI allocations on
>actual mode or CRTC changes, not crtc_state->active changes.
>Additionally, we no longer take the registration of the DRM connector
>for each port into account because so long as we have a kref to the
>port in the new or previous atomic state, the connector will stay
>registered.
>  - Use the small changes to drm_dp_put_port() to add even more error
>checking to make misusage of the helpers more obvious. I added this
>after having to chase down various use-after-free conditions that
>started popping up from the new helpers so no one else has to
>troubleshoot that.
>  - Move some accidental DRM_DEBUG_KMS() calls to DRM_DEBUG_ATOMIC()
>  - Update documentation again, note that find/release() should both not be
>called on the same port in a single atomic check phase (but multiple
>calls to one or the other is OK)
> 
> Changes since v4:
>  - Don't skip the atomic checks for VCPI allocations if no new VCPI
>allocations happen in a state. This makes the next change I'm about
>to list here a lot easier to implement.
>  - Don't ignore VCPI allocations on destroyed ports, instead ensure that
>when ports are destroyed and still have VCPI allocations in the
>topology state, the only state changes allowed are releasing said
>ports' VCPI. This prevents a state with a mix of VCPI allocations
>from destroyed ports, and allocations from valid ports.
> 
> Changes since v3:
>  - Don't release VCPI allocations in the topology state immediately in
>drm_dp_atomic_release_vcpi_slots(), instead mark them as 0 and skip
>over them in drm_dp_mst_duplicate_state(). This makes it so
>drm_dp_atomic_release_vcpi_slots() is still idempotent while also
>throwing warnings if the driver messes up it's book keeping and tries
>to release VCPI slots on a port that doesn't have any pre-existing
>VCPI allocation - danvet
>  - Change mst_state/state in some debugging messages to "mst state"
> 
> Changes since v2:
>  - Use kmemdup() for duplicating MST state - danvet
>  - Move port validation out of duplicate state callback - danvet
>  - Handle looping through MST topology states in
>drm_dp_mst_atomic_check() so the driver doesn't have to do it
>  - Fix documentation in drm_dp_atomic_find_vcpi_slots()
>  - Move the atomic check for each individual topology state into it's
>own function, reduces indenting
>  - Don't consider "stale" MST ports when calculating the bandwidth
>requirements. This is needed because originally we relied on the
>state duplication functions to prune any stale ports from the new
>state, which would prevent us from incorrectly considering their
>bandwidth requirements alongside legitimate new payloads.
>  - Add function references in drm_dp_atomic_release_vcpi_slots() - danvet
>  - Annotate atomic VCPI and atomic check functions with 

[PATCH v2] drm/rockchip: Fix YUV buffers color rendering

[Ezequiel Garcia]

From: Daniele Castagna 

Currently, YUV hardware overlays are converted to RGB using
a color space conversion different than BT.601.

The result is that colors of e.g. NV12 buffers don't match
colors of YUV hardware overlays.

In order to fix this, enable YUV2YUV and set appropriate coefficients
for formats such as NV12 to be displayed correctly.

This commit was tested using modetest, gstreamer and chromeos (hardware
accelerated video playback). Before the commit, tests rendering
with NV12 format resulted in colors not displayed correctly.

Test examples (RK3399 Ficus board connected to HDMI monitor):

  $ modetest 39@32:1920x1080@NV12
  $ gst-launch-1.0 videotestrc ! video/x-raw,format=NV12 ! kmssink

Signed-off-by: Daniele Castagna 
[ezequiel: rebase on linux-next and massage commit log]
Signed-off-by: Ezequiel Garcia 
---
v2:
  * Addressed feedback from Sean Paul
  * Rebased on linux-next

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 41 -
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 13 +++
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 36 ++
 3 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb70fb486fbf..78c7f63a60c0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -52,6 +52,18 @@
vop_reg_set(vop, >phy->scl->ext->name, \
win->base, ~0, v, #name)
 
+#define VOP_WIN_YUV2YUV_SET(x, win_yuv2yuv, name, v) \
+   do { \
+   if (win_yuv2yuv->name.mask) \
+   vop_reg_set(vop, _yuv2yuv->name, 0, ~0, v, #name); \
+   } while (0)
+
+#define VOP_WIN_YUV2YUV_COEFFICIENT_SET(x, win_yuv2yuv, name, v) \
+   do { \
+   if (win_yuv2yuv->phy->name.mask) \
+   vop_reg_set(vop, _yuv2yuv->phy->name, 
win_yuv2yuv->base, ~0, v, #name); \
+   } while (0)
+
 #define VOP_INTR_SET_MASK(vop, name, mask, v) \
vop_reg_set(vop, >data->intr->name, 0, mask, v, #name)
 
@@ -84,6 +96,18 @@
 #define to_vop(x) container_of(x, struct vop, crtc)
 #define to_vop_win(x) container_of(x, struct vop_win, base)
 
+/*
+ * The coefficients of the following matrix are all fixed points.
+ * The format is S2.10 for the 3x3 part of the matrix, and S9.12 for the 
offsets.
+ * They are all represented in two's complement.
+ */
+static const uint32_t rockchip_bt601_yuv2rgb[] = {
+   0x04a8, 0x, 0x0662,
+   0x04a8, 0x1e6f, 0x1cbf,
+   0x04a8, 0x0812, 0x,
+   0x00321168, 0x000877cf, 0x002eb127
+};
+
 enum vop_pending {
VOP_PENDING_FB_UNREF,
 };
@@ -91,6 +115,7 @@ enum vop_pending {
 struct vop_win {
struct drm_plane base;
const struct vop_win_data *data;
+   const struct vop_win_yuv2yuv_data *yuv2yuv_data;
struct vop *vop;
 };
 
@@ -712,6 +737,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
struct drm_crtc *crtc = state->crtc;
struct vop_win *vop_win = to_vop_win(plane);
const struct vop_win_data *win = vop_win->data;
+   const struct vop_win_yuv2yuv_data *win_yuv2yuv = vop_win->yuv2yuv_data;
struct vop *vop = to_vop(state->crtc);
struct drm_framebuffer *fb = state->fb;
unsigned int actual_w, actual_h;
@@ -727,6 +753,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
bool rb_swap;
int win_index = VOP_WIN_TO_INDEX(vop_win);
int format;
+   int is_yuv = fb->format->is_yuv;
+   int i;
 
/*
 * can't update plane when vop is disabled.
@@ -767,7 +795,10 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
-   if (fb->format->is_yuv) {
+
+   VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, y2r_en, is_yuv);
+
+   if (is_yuv) {
int hsub = 
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub = 
drm_format_vert_chroma_subsampling(fb->format->format);
int bpp = fb->format->cpp[1];
@@ -781,6 +812,13 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
VOP_WIN_SET(vop, win, uv_vir, DIV_ROUND_UP(fb->pitches[1], 4));
VOP_WIN_SET(vop, win, uv_mst, dma_addr);
+
+   for (i = 0; i < NUM_YUV2YUV_COEFFICIENTS; i++) {
+   VOP_WIN_YUV2YUV_COEFFICIENT_SET(vop,
+   win_yuv2yuv,
+   y2r_coefficients[i],
+   
rockchip_bt601_yuv2rgb[i]);
+   }
}
 
 

Re: [maintainer-tools PATCH RFC 3/3] dim: fix rr_cache_dir discovery

[Daniel Vetter]

On Fri, Dec 14, 2018 at 02:38:52PM +0100, Andrzej Hajda wrote:
> rr_cache_dir function cannot assume REPO/.git is a directory. On the other
> side it should be backward compatible - if rr-cache directory/link already
> exists it should be returned.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> Hi,
> 
> I am not sure of the purpose of rr-cache symbolic link, dim does not use
> it (except its creation/removal). So this patch should be verified by
> someone who knows better what is going on here.
> 
> Regards
> Andrzej
> ---
>  dim | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/dim b/dim
> index 3afa8b6..b72ebfd 100755
> --- a/dim
> +++ b/dim
> @@ -554,15 +554,6 @@ function check_conflicts # tree
>   true
>  }
>  
> -function rr_cache_dir
> -{
> - if [ -d $DIM_PREFIX/drm-tip/.git/ ] ; then
> - echo $DIM_PREFIX/drm-tip/.git/rr-cache
> - else
> - echo $DIM_PREFIX/$DIM_REPO/.git/rr-cache
> - fi
> -}

I think this breaks it, rr-cache is shared among all worktrees (which is a
big reason for having them).

And yes dim only sets up the symlink, dim rebuild-tip uses the rr-cache
stuff automatically through git merge.
-Daniel

> -
>  function git_dir
>  {
>   local dir=${1:-$PWD}
> @@ -574,6 +565,17 @@ function git_dir
>   fi
>  }
>  
> +function rr_cache_dir
> +{
> + local dir=$(git_dir $DIM_PREFIX/$DIM_REPO)/rr-cache
> +
> + if [ -d $dir ]; then
> + echo $dir
> + else
> + echo $(git_dir $DIM_PREFIX/drm-tip)/rr-cache
> + fi
> +}
> +
>  function pull_rerere_cache
>  {
>   cd $DIM_PREFIX/drm-rerere/
> -- 
> 2.17.1
> 
> ___
> dim-tools mailing list
> dim-to...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dim-tools

-- 
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: [maintainer-tools PATCH RFC 2/3] dim: fix git directory handling

[Daniel Vetter]

On Fri, Dec 14, 2018 at 02:38:51PM +0100, Andrzej Hajda wrote:
> Assumption that git directory is always located at REPO/.git is incorrect,
> especially in case of git worktrees. There is already function to deal
> with it correctly - git_dir, let's then use it.
> 
> Signed-off-by: Andrzej Hajda 

Patch 1&2 are Reviewed-by: Daniel Vetter 

> ---
>  dim | 13 -
>  1 file changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/dim b/dim
> index df66c58..3afa8b6 100755
> --- a/dim
> +++ b/dim
> @@ -1088,12 +1088,7 @@ function dim_backmerge
>  
>   git merge --rerere-autoupdate --no-commit $upstream >& /dev/null || true
>  
> - if [[ -d .git ]]; then
> - patch_file=".git"
> - else
> - patch_file=$(cut -d ' ' -f 2 .git)
> - fi
> - patch_file=$patch_file/MERGE_MSG
> + patch_file=$(git_dir)/MERGE_MSG
>  
>  
>   cat > $patch_file <<-HERE
> @@ -1340,7 +1335,7 @@ dim_alias_mrr=magic-rebase-resolve
>  function dim_magic_rebase_resolve
>  {
>   git diff HEAD | patch -p1 -R
> - dim_magic_patch < .git/rebase-merge/patch
> + dim_magic_patch < $(git_dir)/rebase-merge/patch
>   make $DIM_MAKE_OPTIONS
>   git add -u
>   git rebase --continue
> @@ -2102,7 +2097,7 @@ function setup_aux_checkout # name url directory
>   git clone --reference=$DIM_PREFIX/$DIM_REPO/.git $url 
> $dir
>   cd $dir
>   git config remote.origin.url $url
> - echo "$DIM_PREFIX/$DIM_REPO/.git/objects" > 
> .git/objects/info/alternates
> + echo "$(git_dir $DIM_PREFIX/$DIM_REPO)/objects" > 
> $(git_dir)/objects/info/alternates
>   git repack -a -d -l
>   remote=origin
>   fi
> @@ -2132,7 +2127,7 @@ function dim_setup
>   fi
>   cd $DIM_PREFIX
>  
> - if [ ! -d $DIM_PREFIX/$DIM_REPO/.git ]; then
> + if [ ! -d $(git_dir $DIM_PREFIX/$DIM_REPO) ]; then
>   echoerr "No git checkout found in $DIM_PREFIX/$DIM_REPO."
>   echoerr "Please set up your maintainer linux repository at 
> $DIM_PREFIX/$DIM_REPO with"
>   echoerr "cd $DIM_PREFIX"
> -- 
> 2.17.1
> 
> ___
> dim-tools mailing list
> dim-to...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dim-tools

-- 
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] drm/vc4: Limit SAND tiling support to semiplanar YUV420 formats

[Eric Anholt]

Paul Kocialkowski  writes:

> Despite what the HVS documentation indicates, the VC4 does not actually
> support SAND tiling modes for any RGB format and only semiplanar YUV420
> formats (NV12/NV21) can be used in these tiling modes.
>
> The driver currently claims to support RGB formats for the associated
> modifiers, so remove them from the supported list in the
> format_mod_supported helper for RGB formats.
>
> Remove further checks that are no longer necessary along the way, since
> semi-planar YUV420 formats support every SAND tiling mode.
>
> Signed-off-by: Paul Kocialkowski 

Reviewed-by: Eric Anholt 


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

Re: [GIT PULL v2] exynos-drm-next

[Daniel Vetter]

On Fri, Dec 14, 2018 at 04:27:10PM +0900, Inki Dae wrote:
> Hi Dave,
> 
>Just adding configurable plane alpha and pixel blend mode support
>for FIMD device I missed.
> 
>Please kindly let me know if there is any problem.

Thanks, pulled into drm-next.
-Daniel

> 
> Thanks,
> Inki Dae
> 
> The following changes since commit 2a3c83f5fe0770d13bbb71b23674886ff4111f44:
> 
>   Merge tag 'vmwgfx-next-2018-12-13' of 
> git://people.freedesktop.org/~thomash/linux into drm-next (2018-12-14 
> 04:57:45 +1000)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
> tags/exynos-drm-next-for-v4.21-v2
> 
> for you to fetch changes up to 3b5129b3a7c62fdec9cc69b1b3f20917c36ab5d4:
> 
>   drm/exynos: fimd: Make pixel blend mode configurable (2018-12-14 15:46:15 
> +0900)
> 
> 
> Add configurable plane alpha and pixel blend mode support
> - This patch series adds configurable plane alpha and pixel blend mode
>   support for FIMD device driver.
> 
> 
> Christoph Manszewski (2):
>   drm/exynos: fimd: Make plane alpha configurable
>   drm/exynos: fimd: Make pixel blend mode configurable
> 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 123 
> +--
>  include/video/samsung_fimd.h |  10 +++
>  2 files changed, 110 insertions(+), 23 deletions(-)
> ___
> 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: [DPU PATCH ] drm/msm/dpu: Ignore alpha for XBGR8888 format

[Sean Paul]

On Fri, Nov 30, 2018 at 05:22:50PM +0530, Jayant Shekhar wrote:
> Alpha enable in the pixel format will help in
> selecting the blend rule. By keeping alpha enable
> to true we are allowing foreground alpha to blend
> with the layer. If alpha is don't care, then we
> should not allow pixel alpha to be part of blend
> equation.
> 
> Signed-off-by: Jayant Shekhar 

Pushed to dpu-staging/for-next.

Thanks for your patch!

Sean

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> index bfcd165..d743e7c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> @@ -216,7 +216,7 @@ struct dpu_media_color_map {
>   INTERLEAVED_RGB_FMT(XBGR,
>   COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
>   C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
> - true, 4, 0,
> + false, 4, 0,
>   DPU_FETCH_LINEAR, 1),
>  
>   INTERLEAVED_RGB_FMT(RGBA,
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

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

Re: [PATCH v3 2/3] drm/msm/dpu: handle failures while initializing displays

[Jordan Crouse]

On Thu, Dec 13, 2018 at 10:51:03AM -0800, Jeykumar Sankaran wrote:
> Bail out KMS hw init on display initialization failures with
> proper error logging.
> 
> changes in v3:
>   - introduced in the series
> 
> Signed-off-by: Jeykumar Sankaran 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 39 
> +++--
>  1 file changed, 27 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 685686e..39c8549 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -405,33 +405,36 @@ static void dpu_kms_wait_for_commit_done(struct msm_kms 
> *kms,
>   }
>  }
>  
> -static void _dpu_kms_initialize_dsi(struct drm_device *dev,
> +static int _dpu_kms_initialize_dsi(struct drm_device *dev,
>   struct msm_drm_private *priv,
>   struct dpu_kms *dpu_kms)
>  {
>   struct drm_encoder *encoder = NULL;
> - int i, rc;
> + int i, rc = 0;
> +
> + if (!(priv->dsi[0] || priv->dsi[1]))
> + return rc;
>  
>   /*TODO: Support two independent DSI connectors */
>   encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_DSI);
> - if (IS_ERR_OR_NULL(encoder)) {
> + if (IS_ERR(encoder)) {
>   DPU_ERROR("encoder init failed for dsi display\n");
> - return;
> + return PTR_ERR(encoder);
>   }
>  
>   for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
> - if (!priv->dsi[i]) {
> - DPU_DEBUG("invalid msm_dsi for ctrl %d\n", i);
> - return;
> - }
> + if (!priv->dsi[i])
> + continue;
>  
>   rc = msm_dsi_modeset_init(priv->dsi[i], dev, encoder);
>   if (rc) {
>   DPU_ERROR("modeset_init failed for dsi[%d], rc = %d\n",
>   i, rc);
> - continue;
> + return rc;
>   }
>   }
> +
> + return rc;

This also looks like one of those cases where you can drop out of the if
statement to return rc.
>  }
>  
>  /**
> @@ -442,16 +445,24 @@ static void _dpu_kms_initialize_dsi(struct drm_device 
> *dev,
>   * @dpu_kms:Pointer to dpu kms structure
>   * Returns: Zero on success
>   */
> -static void _dpu_kms_setup_displays(struct drm_device *dev,
> +static int _dpu_kms_setup_displays(struct drm_device *dev,
>   struct msm_drm_private *priv,
>   struct dpu_kms *dpu_kms)
>  {
> - _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
> + int rc = 0;
> +
> + rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
> + if (rc) {
> + DPU_ERROR("failed to initialize dsi, rc = %d\n", rc);
> + return rc;
> + }
>  
>   /**
>* Extend this function to initialize other
>* types of displays
>*/
> +
> + return rc;

Here too.

>  }
>  
>  static void _dpu_kms_drm_obj_destroy(struct dpu_kms *dpu_kms)
> @@ -517,7 +528,11 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
>* Create encoder and query display drivers to create
>* bridges and connectors
>*/
> - _dpu_kms_setup_displays(dev, priv, dpu_kms);
> + ret = _dpu_kms_setup_displays(dev, priv, dpu_kms);
> + if (ret) {
> + DPU_ERROR("failed to setup display, rc = %d\n", ret);

You don't need to pile on with another error message.

> + goto fail;
> + }
>  
>   max_crtc_count = min(catalog->mixer_count,
>(u32)dev->mode_config.num_encoder);

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [DPU PATCH] drm/msm/dpu: Clean up dpu hw interrupts

[Jordan Crouse]

On Fri, Dec 14, 2018 at 02:19:12PM +0530, Jayant Shekhar wrote:
> Remove unused functions and macros from dpu hw interrupts
> file.
> 
> Signed-off-by: Jayant Shekhar 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 30 
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 34 
> ---
>  2 files changed, 64 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> index c0b7f00..0f70cee 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> @@ -170,10 +170,6 @@
>  /**
>   * AD4 interrupt status bit definitions
>   */
> -#define DPU_INTR_BRIGHTPR_UPDATED BIT(4)
> -#define DPU_INTR_DARKENH_UPDATED BIT(3)
> -#define DPU_INTR_STREN_OUTROI_UPDATED BIT(2)
> -#define DPU_INTR_STREN_INROI_UPDATED BIT(1)
>  #define DPU_INTR_BACKLIGHT_UPDATED BIT(0)
>  /**
>   * struct dpu_intr_reg - array of DPU register sets
> @@ -782,18 +778,6 @@ static int dpu_hw_intr_irqidx_lookup(enum dpu_intr_type 
> intr_type,
>   return -EINVAL;
>  }
>  
> -static void dpu_hw_intr_set_mask(struct dpu_hw_intr *intr, uint32_t reg_off,
> - uint32_t mask)
> -{
> - if (!intr)
> - return;
> -
> - DPU_REG_WRITE(>hw, reg_off, mask);
> -
> - /* ensure register writes go through */
> - wmb();
> -}
> -
>  static void dpu_hw_intr_dispatch_irq(struct dpu_hw_intr *intr,
>   void (*cbfunc)(void *, int),
>   void *arg)
> @@ -1004,18 +988,6 @@ static int dpu_hw_intr_disable_irqs(struct dpu_hw_intr 
> *intr)
>   return 0;
>  }
>  
> -static int dpu_hw_intr_get_valid_interrupts(struct dpu_hw_intr *intr,
> - uint32_t *mask)
> -{
> - if (!intr || !mask)
> - return -EINVAL;
> -
> - *mask = IRQ_SOURCE_MDP | IRQ_SOURCE_DSI0 | IRQ_SOURCE_DSI1
> - | IRQ_SOURCE_HDMI | IRQ_SOURCE_EDP;
> -
> - return 0;
> -}
> -
>  static void dpu_hw_intr_get_interrupt_statuses(struct dpu_hw_intr *intr)
>  {
>   int i;
> @@ -1113,14 +1085,12 @@ static u32 dpu_hw_intr_get_interrupt_status(struct 
> dpu_hw_intr *intr,
>  
>  static void __setup_intr_ops(struct dpu_hw_intr_ops *ops)
>  {
> - ops->set_mask = dpu_hw_intr_set_mask;
>   ops->irq_idx_lookup = dpu_hw_intr_irqidx_lookup;
>   ops->enable_irq = dpu_hw_intr_enable_irq;
>   ops->disable_irq = dpu_hw_intr_disable_irq;
>   ops->dispatch_irqs = dpu_hw_intr_dispatch_irq;
>   ops->clear_all_irqs = dpu_hw_intr_clear_irqs;
>   ops->disable_all_irqs = dpu_hw_intr_disable_irqs;
> - ops->get_valid_interrupts = dpu_hw_intr_get_valid_interrupts;
>   ops->get_interrupt_statuses = dpu_hw_intr_get_interrupt_statuses;
>   ops->clear_interrupt_status = dpu_hw_intr_clear_interrupt_status;

I think you can zap clear_interrupt_status too.  Other than that, this looks
real good. Lots of nice negative lines.


>   ops->clear_intr_status_nolock = dpu_hw_intr_clear_intr_status_nolock;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
> index 61e4cba..985f873 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
> @@ -20,13 +20,6 @@
>  #include "dpu_hw_util.h"
>  #include "dpu_hw_mdss.h"
>  
> -#define IRQ_SOURCE_MDP   BIT(0)
> -#define IRQ_SOURCE_DSI0  BIT(4)
> -#define IRQ_SOURCE_DSI1  BIT(5)
> -#define IRQ_SOURCE_HDMI  BIT(8)
> -#define IRQ_SOURCE_EDP   BIT(12)
> -#define IRQ_SOURCE_MHL   BIT(16)
> -
>  /**
>   * dpu_intr_type - HW Interrupt Type
>   * @DPU_IRQ_TYPE_WB_ROT_COMP:WB rotator done
> @@ -96,18 +89,6 @@ enum dpu_intr_type {
>   */
>  struct dpu_hw_intr_ops {
>   /**
> -  * set_mask - Programs the given interrupt register with the
> -  *given interrupt mask. Register value will get overwritten.
> -  * @intr:   HW interrupt handle
> -  * @reg_off:MDSS HW register offset
> -  * @irqmask:IRQ mask value
> -  */
> - void (*set_mask)(
> - struct dpu_hw_intr *intr,
> - uint32_t reg,
> - uint32_t irqmask);
> -
> - /**
>* irq_idx_lookup - Lookup IRQ index on the HW interrupt type
>* Used for all irq related ops
>* @intr_type:  Interrupt type defined in dpu_intr_type
> @@ -206,21 +187,6 @@ struct dpu_hw_intr_ops {
>   struct dpu_hw_intr *intr,
>   int irq_idx,
>   bool clear);
> -
> - /**
> -  * get_valid_interrupts - Gets a mask of all valid interrupt sources
> -  *within DPU. These are actually status bits
> -  *within interrupt registers that specify the
> -  *   

Re: [PATCH v3 3/3] drm/msm/dpu: add display port support in DPU

[Jordan Crouse]

On Thu, Dec 13, 2018 at 10:51:04AM -0800, Jeykumar Sankaran wrote:
> Add display port support in DPU by creating hooks
> for DP encoder enumeration and encoder mode
> initialization.
> 
> This change is based on the SDM845 Display port
> driver changes[1].
> 
> changes in v2:
>   - rebase on [2] (Sean Paul)
>   - remove unwanted error checks and
> switch cases (Jordan Crouse)
> changes in v3:
>   - add dp support after fixing
> the current code base for error logging (Sean Paul)
> 
> [1] https://lwn.net/Articles/768265/
> [2] https://lkml.org/lkml/2018/11/17/87

Two more nits - with these: Reviewed-by: Jordan Crouse 

> Signed-off-by: Jeykumar Sankaran 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |  8 ++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 51 
> +
>  2 files changed, 49 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 36158b7..b79fd9d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -2029,7 +2029,7 @@ static int dpu_encoder_setup_display(struct 
> dpu_encoder_virt *dpu_enc,
>  {
>   int ret = 0;
>   int i = 0;
> - enum dpu_intf_type intf_type;
> + enum dpu_intf_type intf_type = INTF_NONE;
>   struct dpu_enc_phys_init_params phys_params;
>  
>   if (!dpu_enc || !dpu_kms) {
> @@ -2052,9 +2052,9 @@ static int dpu_encoder_setup_display(struct 
> dpu_encoder_virt *dpu_enc,
>   case DRM_MODE_ENCODER_DSI:
>   intf_type = INTF_DSI;
>   break;
> - default:
> - DPU_ERROR_ENC(dpu_enc, "unsupported display interface type\n");
> - return -EINVAL;
> + case DRM_MODE_ENCODER_TMDS:
> + intf_type = INTF_DP;
> + break;
>   }
>  
>   WARN_ON(disp_info->num_of_h_tiles < 1);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 39c8549..ba3e75c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -437,6 +437,32 @@ static int _dpu_kms_initialize_dsi(struct drm_device 
> *dev,
>   return rc;
>  }
>  
> +static int _dpu_kms_initialize_displayport(struct drm_device *dev,
> + struct msm_drm_private *priv,
> + struct dpu_kms *dpu_kms)
> +{
> + struct drm_encoder *encoder = NULL;
> + int rc = 0;
> +
> + if (!priv->dp)
> + return rc;
> +
> + encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_TMDS);
> + if (IS_ERR(encoder)) {
> + DPU_ERROR("encoder init failed for dsi display\n");
> + return PTR_ERR(encoder);
> + }
> +
> + rc = msm_dp_modeset_init(priv->dp, dev, encoder);
> + if (rc) {
> + DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
> + drm_encoder_cleanup(encoder);
> + return rc;

Return rc isn't needed here because you also return rc immediately after the
block.
> + }
> +
> + return rc;
> +}
> +
>  /**
>   * _dpu_kms_setup_displays - create encoders, bridges and connectors
>   *   for underlying displays
> @@ -457,6 +483,12 @@ static int _dpu_kms_setup_displays(struct drm_device 
> *dev,
>   return rc;
>   }
>  
> + rc = _dpu_kms_initialize_displayport(dev, priv, dpu_kms);
> + if (rc) {
> + DPU_ERROR("failed to initialize display port, rc = %d\n", rc);

_dpu_kms_initialize_displayport() already prints error messages in every path
so you don't need to pile on.

> + return rc;
> + }
> +
>   /**
>* Extend this function to initialize other
>* types of displays
> @@ -675,13 +707,20 @@ static void _dpu_kms_set_encoder_mode(struct msm_kms 
> *kms,
>   info.capabilities = cmd_mode ? MSM_DISPLAY_CAP_CMD_MODE :
>   MSM_DISPLAY_CAP_VID_MODE;
>  
> - /* TODO: No support for DSI swap */
> - for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
> - if (priv->dsi[i]) {
> - info.h_tile_instance[info.num_of_h_tiles] = i;
> - info.num_of_h_tiles++;
> + switch (info.intf_type) {
> + case DRM_MODE_ENCODER_DSI:
> + /* TODO: No support for DSI swap */
> + for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
> + if (priv->dsi[i]) {
> + info.h_tile_instance[info.num_of_h_tiles] = i;
> + info.num_of_h_tiles++;
> + }
>   }
> - }
> + break;
> + case DRM_MODE_ENCODER_TMDS:
> + info.num_of_h_tiles = 1;
> + break;
> + };
>  
>   rc = dpu_encoder_setup(encoder->dev, encoder, );
>   if (rc)

-- 
The Qualcomm Innovation Center, Inc. is a member 

Re: [PATCH v3 3/3] drm/msm/dpu: add display port support in DPU

[Sean Paul]

On Thu, Dec 13, 2018 at 10:51:04AM -0800, Jeykumar Sankaran wrote:
> Add display port support in DPU by creating hooks
> for DP encoder enumeration and encoder mode
> initialization.
> 
> This change is based on the SDM845 Display port
> driver changes[1].
> 
> changes in v2:
>   - rebase on [2] (Sean Paul)
>   - remove unwanted error checks and
> switch cases (Jordan Crouse)
> changes in v3:
>   - add dp support after fixing
> the current code base for error logging (Sean Paul)
> 
> [1] https://lwn.net/Articles/768265/
> [2] https://lkml.org/lkml/2018/11/17/87
> 
> Signed-off-by: Jeykumar Sankaran 

LGTM, thanks for revising. 

I'll land the first 2 patches (after the 2nd one is fixed up), and Chandan can
roll this patch into his set when he sends the new version. 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |  8 ++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 51 
> +
>  2 files changed, 49 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 36158b7..b79fd9d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -2029,7 +2029,7 @@ static int dpu_encoder_setup_display(struct 
> dpu_encoder_virt *dpu_enc,
>  {
>   int ret = 0;
>   int i = 0;
> - enum dpu_intf_type intf_type;
> + enum dpu_intf_type intf_type = INTF_NONE;
>   struct dpu_enc_phys_init_params phys_params;
>  
>   if (!dpu_enc || !dpu_kms) {
> @@ -2052,9 +2052,9 @@ static int dpu_encoder_setup_display(struct 
> dpu_encoder_virt *dpu_enc,
>   case DRM_MODE_ENCODER_DSI:
>   intf_type = INTF_DSI;
>   break;
> - default:
> - DPU_ERROR_ENC(dpu_enc, "unsupported display interface type\n");
> - return -EINVAL;
> + case DRM_MODE_ENCODER_TMDS:
> + intf_type = INTF_DP;
> + break;
>   }
>  
>   WARN_ON(disp_info->num_of_h_tiles < 1);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 39c8549..ba3e75c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -437,6 +437,32 @@ static int _dpu_kms_initialize_dsi(struct drm_device 
> *dev,
>   return rc;
>  }
>  
> +static int _dpu_kms_initialize_displayport(struct drm_device *dev,
> + struct msm_drm_private *priv,
> + struct dpu_kms *dpu_kms)
> +{
> + struct drm_encoder *encoder = NULL;
> + int rc = 0;
> +
> + if (!priv->dp)
> + return rc;
> +
> + encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_TMDS);
> + if (IS_ERR(encoder)) {
> + DPU_ERROR("encoder init failed for dsi display\n");
> + return PTR_ERR(encoder);
> + }
> +
> + rc = msm_dp_modeset_init(priv->dp, dev, encoder);
> + if (rc) {
> + DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
> + drm_encoder_cleanup(encoder);
> + return rc;
> + }
> +
> + return rc;
> +}
> +
>  /**
>   * _dpu_kms_setup_displays - create encoders, bridges and connectors
>   *   for underlying displays
> @@ -457,6 +483,12 @@ static int _dpu_kms_setup_displays(struct drm_device 
> *dev,
>   return rc;
>   }
>  
> + rc = _dpu_kms_initialize_displayport(dev, priv, dpu_kms);
> + if (rc) {
> + DPU_ERROR("failed to initialize display port, rc = %d\n", rc);
> + return rc;
> + }
> +
>   /**
>* Extend this function to initialize other
>* types of displays
> @@ -675,13 +707,20 @@ static void _dpu_kms_set_encoder_mode(struct msm_kms 
> *kms,
>   info.capabilities = cmd_mode ? MSM_DISPLAY_CAP_CMD_MODE :
>   MSM_DISPLAY_CAP_VID_MODE;
>  
> - /* TODO: No support for DSI swap */
> - for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
> - if (priv->dsi[i]) {
> - info.h_tile_instance[info.num_of_h_tiles] = i;
> - info.num_of_h_tiles++;
> + switch (info.intf_type) {
> + case DRM_MODE_ENCODER_DSI:
> + /* TODO: No support for DSI swap */
> + for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
> + if (priv->dsi[i]) {
> + info.h_tile_instance[info.num_of_h_tiles] = i;
> + info.num_of_h_tiles++;
> + }
>   }
> - }
> + break;
> + case DRM_MODE_ENCODER_TMDS:
> + info.num_of_h_tiles = 1;
> + break;
> + };
>  
>   rc = dpu_encoder_setup(encoder->dev, encoder, );
>   if (rc)
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation 

Re: [Freedreno] [PATCH v3 2/3] drm/msm/dpu: handle failures while initializing displays

[Sean Paul]

On Thu, Dec 13, 2018 at 10:51:03AM -0800, Jeykumar Sankaran wrote:
> Bail out KMS hw init on display initialization failures with
> proper error logging.
> 
> changes in v3:
>   - introduced in the series
> 
> Signed-off-by: Jeykumar Sankaran 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 39 
> +++--
>  1 file changed, 27 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 685686e..39c8549 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -405,33 +405,36 @@ static void dpu_kms_wait_for_commit_done(struct msm_kms 
> *kms,
>   }
>  }
>  
> -static void _dpu_kms_initialize_dsi(struct drm_device *dev,
> +static int _dpu_kms_initialize_dsi(struct drm_device *dev,
>   struct msm_drm_private *priv,
>   struct dpu_kms *dpu_kms)
>  {
>   struct drm_encoder *encoder = NULL;
> - int i, rc;
> + int i, rc = 0;
> +
> + if (!(priv->dsi[0] || priv->dsi[1]))

It'd be nice to not have to support both blocks if only one is hooked up.
Perhaps move the TODO below above this check.

> + return rc;
>  
>   /*TODO: Support two independent DSI connectors */
>   encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_DSI);
> - if (IS_ERR_OR_NULL(encoder)) {
> + if (IS_ERR(encoder)) {
>   DPU_ERROR("encoder init failed for dsi display\n");
> - return;
> + return PTR_ERR(encoder);
>   }
>  
>   for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
> - if (!priv->dsi[i]) {
> - DPU_DEBUG("invalid msm_dsi for ctrl %d\n", i);
> - return;
> - }
> + if (!priv->dsi[i])

I don't think this is possible given the check at the beginning of the function

> + continue;
>  
>   rc = msm_dsi_modeset_init(priv->dsi[i], dev, encoder);
>   if (rc) {
>   DPU_ERROR("modeset_init failed for dsi[%d], rc = %d\n",
>   i, rc);
> - continue;
> + return rc;
>   }
>   }
> +
> + return rc;

nit: You can keep rc uninitialized above and just return 0 here.

>  }
>  
>  /**
> @@ -442,16 +445,24 @@ static void _dpu_kms_initialize_dsi(struct drm_device 
> *dev,
>   * @dpu_kms:Pointer to dpu kms structure
>   * Returns: Zero on success
>   */
> -static void _dpu_kms_setup_displays(struct drm_device *dev,
> +static int _dpu_kms_setup_displays(struct drm_device *dev,
>   struct msm_drm_private *priv,
>   struct dpu_kms *dpu_kms)
>  {
> - _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
> + int rc = 0;

nit: No need to initialize to 0

> +
> + rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
> + if (rc) {
> + DPU_ERROR("failed to initialize dsi, rc = %d\n", rc);
> + return rc;
> + }
>  
>   /**
>* Extend this function to initialize other
>* types of displays
>*/
> +
> + return rc;
>  }
>  
>  static void _dpu_kms_drm_obj_destroy(struct dpu_kms *dpu_kms)
> @@ -517,7 +528,11 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
>* Create encoder and query display drivers to create
>* bridges and connectors
>*/
> - _dpu_kms_setup_displays(dev, priv, dpu_kms);
> + ret = _dpu_kms_setup_displays(dev, priv, dpu_kms);
> + if (ret) {
> + DPU_ERROR("failed to setup display, rc = %d\n", ret);
> + goto fail;
> + }
>  
>   max_crtc_count = min(catalog->mixer_count,
>(u32)dev->mode_config.num_encoder);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno

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

Re: [Freedreno] [PATCH v2 0/6] DPU resource manager cleanup

[Sean Paul]

On Fri, Dec 07, 2018 at 06:38:32PM -0800, Jeykumar Sankaran wrote:
> First set of clean up patches for DPU resource manager. 
> Removes/realigns some of the redudant RM interfaces.
> Eventual plan is to migrate resource maintenence using
> private state objects.
> 
> Thanks and Regards,
> Jeykumar S

Thanks for revising the set, it all LGTM. Pushed to dpu-staging

Sean

> 
> Jeykumar Sankaran (6):
>   drm/msm/dpu: avoid tracking reservations in RM
>   drm/msm/dpu: remove dev from RM
>   drm/msm/dpu: clean up dpu_rm_check_property_topctl declaration
>   drm/msm/dpu: remove encoder from crtc mixer struct
>   drm/msm/dpu: clean up redundant hw type
>   drm/msm/dpu: maintain hw_mdp in kms
> 
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |   2 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h  |   2 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  14 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 325 
> +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h|  28 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h |  28 +--
>  6 files changed, 66 insertions(+), 333 deletions(-)
> 
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno

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

Re: [PATCH v3 2/2] drm/sched: Rework HW fence processing.

[Grodzovsky, Andrey]

Just a reminder. Any new comments in light of all the discussion ?

Andrey


On 12/12/2018 08:08 AM, Grodzovsky, Andrey wrote:
> BTW, the problem I pointed out with drm_sched_entity_kill_jobs_cb is not
> an issue with this patch set since it removes the cb from
> s_fence->finished in general so we only free the job once - directly
> from drm_sched_entity_kill_jobs_cb.
>
> Andrey
>
>
> On 12/11/2018 11:20 AM, Christian König wrote:
>> Yeah, completely correct explained.
>>
>> I was unfortunately really busy today, but going to give that a look
>> as soon as I have time.
>>
>> Christian.
>>
>> Am 11.12.18 um 17:01 schrieb Grodzovsky, Andrey:
>>> A I understand you say that by the time the fence callback runs the job
>>> might have already been released,
>>>
>>> but how so if the job gets released from drm_sched_job_finish work
>>> handler in the normal flow - so, after the HW
>>>
>>> fence (s_fence->parent) cb is executed. Other 2 flows are error use
>>> cases where amdgpu_job_free is called directly in which
>>>
>>> cases I assume the job wasn't submitted to HW. Last flow I see is
>>> drm_sched_entity_kill_jobs_cb and here I actually see a problem
>>>
>>> with the code as it's today - drm_sched_fence_finished is called which
>>> will trigger s_fence->finished callback to run which today
>>>
>>> schedules drm_sched_job_finish which releases the job, but we don't even
>>> wait for that and call free_job cb directly from
>>>
>>> after that which seems wrong to me.
>>>
>>> Andrey
>>>
>>>
>>> On 12/10/2018 09:45 PM, Zhou, David(ChunMing) wrote:
 I don't think adding cb to sched job would work as soon as their
 lifetime is different with fence.
 Unless you make the sched job reference, otherwise we will get
 trouble sooner or later.

 -David

> -Original Message-
> From: amd-gfx  On Behalf Of
> Andrey Grodzovsky
> Sent: Tuesday, December 11, 2018 5:44 AM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ckoenig.leichtzumer...@gmail.com; e...@anholt.net;
> etna...@lists.freedesktop.org
> Cc: Zhou, David(ChunMing) ; Liu, Monk
> ; Grodzovsky, Andrey
> 
> Subject: [PATCH v3 2/2] drm/sched: Rework HW fence processing.
>
> Expedite job deletion from ring mirror list to the HW fence signal
> callback
> instead from finish_work, together with waiting for all such fences
> to signal in
> drm_sched_stop we garantee that already signaled job will not be
> processed
> twice.
> Remove the sched finish fence callback and just submit finish_work
> directly
> from the HW fence callback.
>
> v2: Fix comments.
>
> v3: Attach  hw fence cb to sched_job
>
> Suggested-by: Christian Koenig 
> Signed-off-by: Andrey Grodzovsky 
> ---
>     drivers/gpu/drm/scheduler/sched_main.c | 58
> --
> 
>     include/drm/gpu_scheduler.h    |  6 ++--
>     2 files changed, 30 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index cdf95e2..f0c1f32 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -284,8 +284,6 @@ static void drm_sched_job_finish(struct
> work_struct
> *work)
>     cancel_delayed_work_sync(>work_tdr);
>
>     spin_lock_irqsave(>job_list_lock, flags);
> -    /* remove job from ring_mirror_list */
> -    list_del_init(_job->node);
>     /* queue TDR for next job */
>     drm_sched_start_timeout(sched);
>     spin_unlock_irqrestore(>job_list_lock, flags); @@
> -293,22
> +291,11 @@ static void drm_sched_job_finish(struct work_struct *work)
>     sched->ops->free_job(s_job);
>     }
>
> -static void drm_sched_job_finish_cb(struct dma_fence *f,
> -    struct dma_fence_cb *cb)
> -{
> -    struct drm_sched_job *job = container_of(cb, struct
> drm_sched_job,
> - finish_cb);
> -    schedule_work(>finish_work);
> -}
> -
>     static void drm_sched_job_begin(struct drm_sched_job *s_job)  {
>     struct drm_gpu_scheduler *sched = s_job->sched;
>     unsigned long flags;
>
> - dma_fence_add_callback(_job->s_fence->finished, _job-
>> finish_cb,
> -   drm_sched_job_finish_cb);
> -
>     spin_lock_irqsave(>job_list_lock, flags);
>     list_add_tail(_job->node, >ring_mirror_list);
>     drm_sched_start_timeout(sched);
> @@ -359,12 +346,11 @@ void drm_sched_stop(struct drm_gpu_scheduler
> *sched, struct drm_sched_job *bad,
>     list_for_each_entry_reverse(s_job, >ring_mirror_list,
> node)
> {
>     if (s_job->s_fence->parent &&
> dma_fence_remove_callback(s_job->s_fence->parent,

Re: [Freedreno] [PATCH v4 4/5] drm/msm: clean up display thread

[Sean Paul]

On Thu, Dec 06, 2018 at 06:41:43PM -0800, Jeykumar Sankaran wrote:
> Since there are no clients using these threads,
> cleaning it up.
> 
> changes in v2:
>   - switch all the dependent clients to use system wq
> before removing the disp_threads (Sean Paul)
> changes in v3:
>   - none
> changes in v4:
>   - none
> 
> Signed-off-by: Jeykumar Sankaran 
> ---
>  drivers/gpu/drm/msm/msm_drv.c | 35 +--
>  drivers/gpu/drm/msm/msm_drv.h |  1 -
>  2 files changed, 1 insertion(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 37740b8..1e9fec1 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -286,13 +286,8 @@ static int msm_drm_uninit(struct device *dev)
>   kfree(vbl_ev);
>   }
>  
> - /* clean up display commit/event worker threads */
> + /* clean up event worker threads */
>   for (i = 0; i < priv->num_crtcs; i++) {
> - if (priv->disp_thread[i].thread) {
> - kthread_destroy_worker(>disp_thread[i].worker);
> - priv->disp_thread[i].thread = NULL;
> - }
> -
>   if (priv->event_thread[i].thread) {
>   kthread_destroy_worker(>event_thread[i].worker);
>   priv->event_thread[i].thread = NULL;
> @@ -545,27 +540,6 @@ static int msm_drm_init(struct device *dev, struct 
> drm_driver *drv)
>*/
>   param.sched_priority = 16;
>   for (i = 0; i < priv->num_crtcs; i++) {
> -
> - /* initialize display thread */
> - priv->disp_thread[i].crtc_id = priv->crtcs[i]->base.id;
> - kthread_init_worker(>disp_thread[i].worker);
> - priv->disp_thread[i].dev = ddev;
> - priv->disp_thread[i].thread =
> - kthread_run(kthread_worker_fn,
> - >disp_thread[i].worker,
> - "crtc_commit:%d", priv->disp_thread[i].crtc_id);
> - if (IS_ERR(priv->disp_thread[i].thread)) {
> - DRM_DEV_ERROR(dev, "failed to create crtc_commit 
> kthread\n");
> - priv->disp_thread[i].thread = NULL;
> - goto err_msm_uninit;
> - }
> -
> - ret = sched_setscheduler(priv->disp_thread[i].thread,
> -  SCHED_FIFO, );
> - if (ret)
> - dev_warn(dev, "disp_thread set priority failed: %d\n",
> -  ret);
> -

I'm getting the following compilation errors with this patch applied to 
dpu-staging/for-next:

../drivers/gpu/drm/msm/msm_drv.c: In function ‘msm_drm_init’:
../drivers/gpu/drm/msm/msm_drv.c:569:15: error: ‘struct msm_drm_private’ has no 
member named ‘disp_thread’; did you mean ‘event_thread’?
   if ((!priv->disp_thread[i].thread) ||
   ^~~
   event_thread
../drivers/gpu/drm/msm/msm_drv.c:573:15: error: ‘struct msm_drm_private’ has no 
member named ‘disp_thread’; did you mean ‘event_thread’?
 if (priv->disp_thread[i].thread) {
   ^~~
   event_thread
../drivers/gpu/drm/msm/msm_drv.c:575:13: error: ‘struct msm_drm_private’ has no 
member named ‘disp_thread’; did you mean ‘event_thread’?
   priv->disp_thread[i].thread);
 ^~~
 event_thread
../drivers/gpu/drm/msm/msm_drv.c:576:12: error: ‘struct msm_drm_private’ has no 
member named ‘disp_thread’; did you mean ‘event_thread’?
  priv->disp_thread[i].thread = NULL;
^~~
event_thread


I think you also need:

@@ -598,16 +566,9 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
priv->event_thread[i].thread = NULL;
}
 
-   if ((!priv->disp_thread[i].thread) ||
-   !priv->event_thread[i].thread) {
+   if (!priv->event_thread[i].thread) {
/* clean up previously created threads if any */
for ( ; i >= 0; i--) {
-   if (priv->disp_thread[i].thread) {
-   kthread_stop(
-   priv->disp_thread[i].thread);
-   priv->disp_thread[i].thread = NULL;
-   }
-
if (priv->event_thread[i].thread) {
kthread_stop(
priv->event_thread[i].thread);



>   /* initialize event thread */
>   priv->event_thread[i].crtc_id = priv->crtcs[i]->base.id;
>   kthread_init_worker(>event_thread[i].worker);
> @@ -580,13 +554,6 @@ static int msm_drm_init(struct device *dev, struct 
> drm_driver *drv)
>   goto 

[radeon-alex:amd-18.50 790/1415] drivers/gpu/drm/ttm/ttm_bo_util.c:315:3: error: implicit declaration of function '__kcl__kunmap_atomic'; did you mean '__ttm_kunmap_atomic'?

[kbuild test robot]

Hi Kevin,

FYI, the error/warning still remains.

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-18.50
head:   88a0039cb034176ee3416dd0c3a49feea2f446ab
commit: 7d0741bab20cb328c2c778764efc340896242ccb [790/1415] drm/amdkcl: [RHEL 
6] support kmap_atomic funciton for ttm module
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 7d0741bab20cb328c2c778764efc340896242ccb
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm 

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

   drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_kmap_atomic_prot':
   drivers/gpu/drm/ttm/ttm_bo_util.c:299:10: error: implicit declaration of 
function '__kcl__kmap_atomic'; did you mean '__kunmap_atomic'? 
[-Werror=implicit-function-declaration]
  return __kcl__kmap_atomic(page);
 ^~
 __kunmap_atomic
>> drivers/gpu/drm/ttm/ttm_bo_util.c:299:10: warning: return makes pointer from 
>> integer without a cast [-Wint-conversion]
  return __kcl__kmap_atomic(page);
 ^~~~
   drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_kunmap_atomic_prot':
>> drivers/gpu/drm/ttm/ttm_bo_util.c:315:3: error: implicit declaration of 
>> function '__kcl__kunmap_atomic'; did you mean '__ttm_kunmap_atomic'? 
>> [-Werror=implicit-function-declaration]
  __kcl__kunmap_atomic(addr);
  ^~~~
  __ttm_kunmap_atomic
   cc1: some warnings being treated as errors

vim +315 drivers/gpu/drm/ttm/ttm_bo_util.c

   280  
   281  
   282  /**
   283   * ttm_kmap_atomic_prot - Efficient kernel map of a single page with
   284   * specified page protection.
   285   *
   286   * @page: The page to map.
   287   * @prot: The page protection.
   288   *
   289   * This function maps a TTM page using the kmap_atomic api if available,
   290   * otherwise falls back to vmap. The user must make sure that the
   291   * specified page does not have an aliased mapping with a different 
caching
   292   * policy unless the architecture explicitly allows it. Also mapping and
   293   * unmapping using this api must be correctly nested. Unmapping should
   294   * occur in the reverse order of mapping.
   295   */
   296  void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot)
   297  {
   298  if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
 > 299  return __kcl__kmap_atomic(page);
   300  else
   301  return __ttm_kmap_atomic_prot(page, prot);
   302  }
   303  EXPORT_SYMBOL(ttm_kmap_atomic_prot);
   304  
   305  /**
   306   * ttm_kunmap_atomic_prot - Unmap a page that was mapped using
   307   * ttm_kmap_atomic_prot.
   308   *
   309   * @addr: The virtual address from the map.
   310   * @prot: The page protection.
   311   */
   312  void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot)
   313  {
   314  if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
 > 315  __kcl__kunmap_atomic(addr);
   316  else
   317  __ttm_kunmap_atomic(addr);
   318  }
   319  EXPORT_SYMBOL(ttm_kunmap_atomic_prot);
   320  

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

[radeon-alex:amd-18.50 1284/1415] arch/arm64/include/asm/io.h:136:32: note: in expansion of macro 'readl_relaxed'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-18.50
head:   88a0039cb034176ee3416dd0c3a49feea2f446ab
commit: a26f88704ef76f0213692b3b04f210de6e9e8676 [1284/1415] drm/scheduler: fix 
build error due to change in scheduler struct
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a26f88704ef76f0213692b3b04f210de6e9e8676
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/swab.h:5:0,
from include/uapi/linux/byteorder/big_endian.h:13,
from include/linux/byteorder/big_endian.h:5,
from arch/arm64/include/uapi/asm/byteorder.h:21,
from include/asm-generic/bitops/le.h:6,
from arch/arm64/include/asm/bitops.h:50,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/rculist.h:10,
from include/linux/pid.h:5,
from include/linux/sched.h:14,
from include/linux/kthread.h:6,
from drivers/gpu/drm/v3d/v3d_sched.c:21:
   drivers/gpu/drm/v3d/v3d_sched.c: In function 'v3d_job_timedout':
   drivers/gpu/drm/v3d/v3d_sched.c:157:44: error: 'job_q' undeclared (first use 
in this function); did you mean 'job'?
 u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
   ^
   include/uapi/linux/swab.h:117:32: note: in definition of macro '__swab32'
 (__builtin_constant_p((__u32)(x)) ? \
   ^
   include/linux/byteorder/generic.h:89:21: note: in expansion of macro 
'__le32_to_cpu'
#define le32_to_cpu __le32_to_cpu
^
>> arch/arm64/include/asm/io.h:136:32: note: in expansion of macro 
>> 'readl_relaxed'
#define readl(c)  ({ u32 __v = readl_relaxed(c); __iormb(); __v; })
   ^
   drivers/gpu/drm/v3d/v3d_drv.h:166:37: note: in expansion of macro 'readl'
#define V3D_CORE_READ(core, offset) readl(v3d->core_regs[core] + offset)
^
   drivers/gpu/drm/v3d/v3d_sched.c:157:13: note: in expansion of macro 
'V3D_CORE_READ'
 u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
^
   drivers/gpu/drm/v3d/v3d_sched.c:157:30: note: in expansion of macro 
'V3D_CLE_CTNCA'
 u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
 ^
   drivers/gpu/drm/v3d/v3d_sched.c:157:44: note: each undeclared identifier is 
reported only once for each function it appears in
 u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
   ^
   include/uapi/linux/swab.h:117:32: note: in definition of macro '__swab32'
 (__builtin_constant_p((__u32)(x)) ? \
   ^
   include/linux/byteorder/generic.h:89:21: note: in expansion of macro 
'__le32_to_cpu'
#define le32_to_cpu __le32_to_cpu
^
>> arch/arm64/include/asm/io.h:136:32: note: in expansion of macro 
>> 'readl_relaxed'
#define readl(c)  ({ u32 __v = readl_relaxed(c); __iormb(); __v; })
   ^
   drivers/gpu/drm/v3d/v3d_drv.h:166:37: note: in expansion of macro 'readl'
#define V3D_CORE_READ(core, offset) readl(v3d->core_regs[core] + offset)
^
   drivers/gpu/drm/v3d/v3d_sched.c:157:13: note: in expansion of macro 
'V3D_CORE_READ'
 u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
^
   drivers/gpu/drm/v3d/v3d_sched.c:157:30: note: in expansion of macro 
'V3D_CLE_CTNCA'
 u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
 ^
   drivers/gpu/drm/v3d/v3d_sched.c:158:30: error: implicit declaration of 
function 'V3D_CLE_CTNRA'; did you mean 'V3D_CLE_CTNCA'? 
[-Werror=implicit-function-declaration]
 u32 ctra = V3D_CORE_READ(0, V3D_CLE_CTNRA(job_q));
 ^
   include/uapi/linux/swab.h:117:32: note: in definition of macro '__swab32'
 (__builtin_constant_p((__u32)(x)) ? \
   ^
   include/linux/byteorder/generic.h:89:21: note: in expansion of macro 
'__le32_to_cpu'
#define le32_to_cpu __le32_to_cpu
^
>> arch/arm64/include/asm/io.h:136:32: note: in expansion of macro 
>> 'readl_relaxed'
#define readl(c)  ({ u32 __v = readl_relaxed(c); __iormb(); __v; })
  

RE: [PATCH v2 2/2] drm/i915: Validate userspace-provided color management LUT's (v2)

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Matt Roper
>Sent: Friday, December 14, 2018 3:25 AM
>To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
>Cc: Shankar, Uma ; Sharma, Swati2
>
>Subject: [PATCH v2 2/2] drm/i915: Validate userspace-provided color
>management LUT's (v2)
>
>We currently program userspace-provided gamma and degamma LUT's into our
>hardware without really checking to see whether they satisfy our hardware's
>rules.  We should try to catch tables that are invalid for our hardware early 
>and
>reject the atomic transaction.
>
>All of our platforms that accept a degamma LUT expect that the entries in the
>LUT are always flat or increasing, never decreasing.  Also, our GLK and ICL
>platforms only accept degamma tables with r=g=b entries; so we should also add
>the relevant checks for that in anticipation of degamma support landing for 
>those
>platforms.
>
>v2:
> - Use new API (single check function with bitmask of tests to apply)
> - Call helper for our gamma table as well (with no additional tests
>   specified) so that the table size will be validated.

Looks ok to me.
Reviewed-By: Uma Shankar 

>Cc: Uma Shankar 
>Cc: Swati Sharma 
>Signed-off-by: Matt Roper 
>---
> drivers/gpu/drm/i915/intel_color.c | 19 +++
> 1 file changed, 19 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_color.c
>b/drivers/gpu/drm/i915/intel_color.c
>index 37fd9ddf762e..5ad4459a5f3c 100644
>--- a/drivers/gpu/drm/i915/intel_color.c
>+++ b/drivers/gpu/drm/i915/intel_color.c
>@@ -609,10 +609,29 @@ int intel_color_check(struct intel_crtc_state
>*crtc_state)  {
>   struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
>   size_t gamma_length, degamma_length;
>+  uint32_t tests = DRM_COLOR_LUT_INCREASING;
>
>   degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
>   gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
>
>+  /*
>+   * All of our platforms mandate that the degamma curve be
>+   * non-decreasing.  Additionally, GLK and gen11 only accept a single
>+   * value for red, green, and blue in the degamma table.  Make sure
>+   * userspace didn't try to pass us something we can't handle.
>+   *
>+   * We don't have any extra hardware constraints on the gamma table,
>+   * so we just test that it's a proper size multiple
>+   * (tablesize % entrysize == 0).
>+   */
>+  if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
>+  tests |= DRM_COLOR_LUT_EQUAL_CHANNELS;
>+
>+  if (drm_color_lut_check(crtc_state->base.degamma_lut, tests) != 0)
>+  return -EINVAL;
>+  if (drm_color_lut_check(crtc_state->base.gamma_lut, 0) != 0)
>+  return -EINVAL;
>+
>   /*
>* We allow both degamma & gamma luts at the right size or
>* NULL.
>--
>2.14.4
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v2 1/2] drm: Add color management LUT validation helper (v2)

[Shankar, Uma]

>-Original Message-
>From: Roper, Matthew D
>Sent: Friday, December 14, 2018 3:25 AM
>To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
>Cc: Roper, Matthew D ; Shankar, Uma
>; Sharma, Swati2 ; Brian
>Starkey 
>Subject: [PATCH v2 1/2] drm: Add color management LUT validation helper (v2)
>
>Some hardware may place additional restrictions on the gamma/degamma
>curves described by our LUT properties.  E.g., that a gamma curve never
>decreases or that the red/green/blue channels of a LUT's entries must be equal.
>Let's add a helper function that drivers can use to test that a 
>userspace-provided
>LUT is valid and doesn't violate hardware requirements.
>
>v2:
> - Combine into a single helper that just takes a bitmask of the tests
>   to apply.  (Brian Starkey)
> - Add additional check (always performed) that LUT property blob size
>   is always a multiple of the LUT entry size.  (stolen from ARM driver)

Looks ok to me.
Reviewed-By: Uma Shankar 

>Cc: Uma Shankar 
>Cc: Swati Sharma 
>Cc: Brian Starkey 
>Signed-off-by: Matt Roper 
>Reviewed-by(v1): Brian Starkey 
>---
> drivers/gpu/drm/drm_color_mgmt.c | 64
>
> include/drm/drm_color_mgmt.h |  5 
> 2 files changed, 69 insertions(+)
>
>diff --git a/drivers/gpu/drm/drm_color_mgmt.c
>b/drivers/gpu/drm/drm_color_mgmt.c
>index 07dcf47daafe..5c2a2d228412 100644
>--- a/drivers/gpu/drm/drm_color_mgmt.c
>+++ b/drivers/gpu/drm/drm_color_mgmt.c
>@@ -462,3 +462,67 @@ int drm_plane_create_color_properties(struct
>drm_plane *plane,
>   return 0;
> }
> EXPORT_SYMBOL(drm_plane_create_color_properties);
>+
>+/**
>+ * drm_color_lut_check - check validity of lookup table
>+ * @lut: property blob containing LUT to check
>+ * @tests: bitmask of tests to run
>+ *
>+ * Helper to check whether a userspace-provided lookup table is valid
>+and
>+ * satisfies additional hardware requirements.  All table sizes should
>+be a
>+ * multiple of sizeof(struct drm_color_lut).  Drivers pass a bitmask
>+indicating
>+ * which of the following additional tests should also be performed:
>+ *
>+ * "DRM_COLOR_LUT_EQUAL_CHANNELS":
>+ * Checks whether the entries of a LUT all have equal values for the red,
>+ * green, and blue channels.  Intended for hardware that only accepts a
>+ * single value per LUT entry and assumes that value applies to all three
>+ * color components.
>+ *
>+ * "DRM_COLOR_LUT_INCREASING":
>+ * Checks whether the entries of a LUT are always flat or increasing
>+ * (never decreasing).
>+ *
>+ * Returns 0 on success, -EINVAL on failure.
>+ */
>+int drm_color_lut_check(struct drm_property_blob *lut,
>+   uint32_t tests)
>+{
>+  struct drm_color_lut *entry;
>+  int i;
>+
>+  if (!lut)
>+  return 0;
>+
>+  if (lut->length % sizeof(struct drm_color_lut)) {
>+  DRM_DEBUG_KMS("LUT size (%lu) is not a multiple of LUT entry
>size (%lu)\n",
>+lut->length, sizeof(struct drm_color_lut));
>+  return -EINVAL;
>+  }
>+
>+  if (!tests)
>+  return 0;
>+
>+  entry = lut->data;
>+  for (i = 0; i < drm_color_lut_size(lut); i++) {
>+  if (tests & DRM_COLOR_LUT_EQUAL_CHANNELS) {
>+  if (entry[i].red != entry[i].blue ||
>+  entry[i].red != entry[i].green) {
>+  DRM_DEBUG_KMS("All LUT entries must have
>equal r/g/b\n");
>+  return -EINVAL;
>+  }
>+  }
>+
>+  if (i > 0 && tests & DRM_COLOR_LUT_INCREASING) {
>+  if (entry[i].red < entry[i - 1].red ||
>+  entry[i].green < entry[i - 1].green ||
>+  entry[i].blue < entry[i - 1].blue) {
>+  DRM_DEBUG_KMS("LUT entries must never
>decrease.\n");
>+  return -EINVAL;
>+  }
>+  }
>+  }
>+
>+  return 0;
>+}
>+EXPORT_SYMBOL(drm_color_lut_check);
>diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
>index 90ef9996d9a4..7de16f70bcc3 100644
>--- a/include/drm/drm_color_mgmt.h
>+++ b/include/drm/drm_color_mgmt.h
>@@ -69,4 +69,9 @@ int drm_plane_create_color_properties(struct drm_plane
>*plane,
> u32 supported_ranges,
> enum drm_color_encoding
>default_encoding,
> enum drm_color_range default_range);
>+
>+#define DRM_COLOR_LUT_EQUAL_CHANNELS BIT(0)
>+#define DRM_COLOR_LUT_INCREASING BIT(1)
>+int drm_color_lut_check(struct drm_property_blob *lut,
>+  uint32_t tests);
> #endif
>--
>2.14.4

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

[PATCH v2 2/3] PM/runtime:Replace jiffies based accouting with ktime based accounting

[Vincent Guittot]

From: Thara Gopinath 

This patch replaces jiffies based accoutning for runtime_active_time
and runtime_suspended_time with ktime base accounting. This makes the
runtime debug counters inline with genpd and other pm subsytems which
uses ktime based accounting.

Signed-off-by: Thara Gopinath 
[move from ktime to raw nsec]
Signed-off-by: Vincent Guittot 
---
 drivers/base/power/runtime.c | 10 +-
 drivers/base/power/sysfs.c   | 11 ---
 include/linux/pm.h   |  6 +++---
 3 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 7062469..89655e2 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -66,8 +66,8 @@ static int rpm_suspend(struct device *dev, int rpmflags);
  */
 void update_pm_runtime_accounting(struct device *dev)
 {
-   unsigned long now = jiffies;
-   unsigned long delta;
+   u64 now = ktime_to_ns(ktime_get());
+   u64 delta;
 
delta = now - dev->power.accounting_timestamp;
 
@@ -77,9 +77,9 @@ void update_pm_runtime_accounting(struct device *dev)
return;
 
if (dev->power.runtime_status == RPM_SUSPENDED)
-   dev->power.suspended_jiffies += delta;
+   dev->power.suspended_time += delta;
else
-   dev->power.active_jiffies += delta;
+   dev->power.active_time += delta;
 }
 
 static void __update_runtime_status(struct device *dev, enum rpm_status status)
@@ -1491,7 +1491,7 @@ void pm_runtime_init(struct device *dev)
dev->power.request_pending = false;
dev->power.request = RPM_REQ_NONE;
dev->power.deferred_resume = false;
-   dev->power.accounting_timestamp = jiffies;
+   dev->power.accounting_timestamp = ktime_to_ns(ktime_get());
INIT_WORK(>power.work, pm_runtime_work);
 
dev->power.timer_expires = 0;
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index d713738..96c8a22 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -125,9 +125,12 @@ static ssize_t runtime_active_time_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
int ret;
+   u64 tmp;
spin_lock_irq(>power.lock);
update_pm_runtime_accounting(dev);
-   ret = sprintf(buf, "%i\n", jiffies_to_msecs(dev->power.active_jiffies));
+   tmp = dev->power.active_time;
+   do_div(tmp, NSEC_PER_MSEC);
+   ret = sprintf(buf, "%llu\n", tmp);
spin_unlock_irq(>power.lock);
return ret;
 }
@@ -138,10 +141,12 @@ static ssize_t runtime_suspended_time_show(struct device 
*dev,
struct device_attribute *attr, char *buf)
 {
int ret;
+   u64 tmp;
spin_lock_irq(>power.lock);
update_pm_runtime_accounting(dev);
-   ret = sprintf(buf, "%i\n",
-   jiffies_to_msecs(dev->power.suspended_jiffies));
+   tmp = dev->power.suspended_time;
+   do_div(tmp, NSEC_PER_MSEC);
+   ret = sprintf(buf, "%llu\n", tmp);
spin_unlock_irq(>power.lock);
return ret;
 }
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 0bd9de1..3d2cbf9 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -633,9 +633,9 @@ struct dev_pm_info {
int runtime_error;
int autosuspend_delay;
u64 last_busy;
-   unsigned long   active_jiffies;
-   unsigned long   suspended_jiffies;
-   unsigned long   accounting_timestamp;
+   u64 active_time;
+   u64 suspended_time;
+   u64 accounting_timestamp;
 #endif
struct pm_subsys_data   *subsys_data;  /* Owned by the subsystem. */
void (*set_latency_tolerance)(struct device *, s32);
-- 
2.7.4

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

Re: [RFC AFBC 07/12] drm/arm/malidp: Define the constraints on each supported drm_fourcc format for the AFBC modifiers.

[Ayan Halder]

On Tue, Dec 04, 2018 at 05:49:12PM +, Liviu Dudau wrote:
> On Mon, Dec 03, 2018 at 11:32:01AM +, Ayan Halder wrote:
> > The constraints are as follows (for Mali-DP 500, 550, 650) :-
> > 
> > 1. AFBC is not supported for the formats defined in 
> > malidp_hw_format_is_linear_only()
> > 
> > 2. Some of the formats are supported only with AFBC modifiers. Thus we have
> > introduced a new function 'malidp_hw_format_is_afbc_only()' which verifies 
> > the same.
> > 
> > 3. AFBC_FORMAT_MOD_YTR needs to be provided for any RGB format.
> > 
> > 4. Formats <= 16bpp cannot support AFBC_FORMAT_MOD_SPLIT.
> > 
> > 5. CBR should not be set for non-subsampled formats.
> > 
> > 6. SMART layer does not support framebuffer with AFBC modifiers.
> > Return -EINVAL for such a scenario.
> > 
> > 7. AFBC_FORMAT_MOD_YTR is not supported for any YUV formats.
> > 
> > 8. Formats which are subsampled cannot support AFBC_FORMAT_MOD_SPLIT. 
> > However in
> > DP550, YUV_420_10BIT is supported with AFBC_FORMAT_MOD_SPLIT. This feature 
> > has
> > been identified with MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT.
> > 
> > 9. In DP550 and DP650, for YUYV, the hardware supports different format-ids 
> > to
> > be used with and without AFBC modifier. We have used the feature
> > 'MALIDP_DEVICE_AFBC_YUYV_USE_422_P2' to identify this characteristic.
> > 
> > Signed-off-by: Ayan Kumar halder 
> > ---
> >  drivers/gpu/drm/arm/malidp_drv.c|  23 +--
> >  drivers/gpu/drm/arm/malidp_drv.h|   6 ++
> >  drivers/gpu/drm/arm/malidp_hw.c |  71 +++--
> >  drivers/gpu/drm/arm/malidp_hw.h |   5 +-
> >  drivers/gpu/drm/arm/malidp_mw.c |   2 +-
> >  drivers/gpu/drm/arm/malidp_planes.c | 124 
> > +++-
> >  6 files changed, 199 insertions(+), 32 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index b8db92f..2f0b553 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -264,29 +264,8 @@ static bool
> >  malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
> > const struct drm_mode_fb_cmd2 *mode_cmd)
> >  {
> > -   const struct drm_format_info *info;
> > -
> > -   if ((mode_cmd->modifier[0] >> 56) != DRM_FORMAT_MOD_VENDOR_ARM) {
> > -   DRM_DEBUG_KMS("Unknown modifier (not Arm)\n");
> > +   if (malidp_format_mod_supported(dev, mode_cmd->pixel_format, 
> > mode_cmd->modifier[0]) == false)
> > return false;
> > -   }
> > -
> > -   if (mode_cmd->modifier[0] &
> > -   ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_MOD_VALID_BITS)) {
> > -   DRM_DEBUG_KMS("Unsupported modifiers\n");
> > -   return false;
> > -   }
> > -
> > -   info = drm_get_format_info(dev, mode_cmd);
> > -   if (!info) {
> > -   DRM_DEBUG_KMS("Unable to get the format information\n");
> > -   return false;
> > -   }
> > -
> > -   if (info->num_planes != 1) {
> > -   DRM_DEBUG_KMS("AFBC buffers expect one plane\n");
> > -   return false;
> > -   }
> >  
> > if (mode_cmd->offsets[0] != 0) {
> > DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.h 
> > b/drivers/gpu/drm/arm/malidp_drv.h
> > index b76c86f..019a682 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.h
> > +++ b/drivers/gpu/drm/arm/malidp_drv.h
> > @@ -90,6 +90,12 @@ struct malidp_crtc_state {
> >  int malidp_de_planes_init(struct drm_device *drm);
> >  int malidp_crtc_init(struct drm_device *drm);
> >  
> > +bool malidp_hw_format_is_linear_only(u32 format);
> > +bool malidp_hw_format_is_afbc_only(u32 format);
> > +
> > +bool malidp_format_mod_supported(struct drm_device *drm,
> > +u32 format, u64 modifier);
> > +
> >  #ifdef CONFIG_DEBUG_FS
> >  void malidp_error(struct malidp_drm *malidp,
> >   struct malidp_error_stats *error_stats, u32 status,
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.c 
> > b/drivers/gpu/drm/arm/malidp_hw.c
> > index 25ac5890..4a774be 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > @@ -60,6 +60,8 @@ static const struct malidp_format_id 
> > malidp500_de_formats[] = {
> >  #define MALIDP_ID(__group, __format) \
> > __group) & 0x7) << 3) | ((__format) & 0x7))
> >  
> > +#define AFBC_YUV_422_FORMAT_ID MALIDP_ID(5, 1)
> > +
> >  #define MALIDP_COMMON_FORMATS \
> > /*fourcc,   layers supporting the format,  internal id   */ \
> > { DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | 
> > SE_MEMWRITE, MALIDP_ID(0, 0) }, \
> > @@ -887,7 +889,10 @@ const struct malidp_hw 
> > malidp_device[MALIDP_MAX_DEVICES] = {
> > .se_base = MALIDP550_SE_BASE,
> > .dc_base = MALIDP550_DC_BASE,
> > .out_depth_base = MALIDP550_DE_OUTPUT_DEPTH,
> > -   .features = 

[PATCH v2 3/3] drm/i915: Move to new PM core fields

[Vincent Guittot]

With jiffies been replaced by raw ns in PM core accounting, 915 driver is
updated to use this new time infrastructure.

Signed-off-by: Vincent Guittot 
---
 drivers/gpu/drm/i915/i915_pmu.c | 12 ++--
 drivers/gpu/drm/i915/i915_pmu.h |  4 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index d6c8f8f..cf6437d 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -493,14 +493,14 @@ static u64 get_rc6(struct drm_i915_private *i915)
 */
if (kdev->power.runtime_status == RPM_SUSPENDED) {
if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
-   i915->pmu.suspended_jiffies_last =
- kdev->power.suspended_jiffies;
+   i915->pmu.suspended_time_last =
+   kdev->power.suspended_time;
 
-   val = kdev->power.suspended_jiffies -
- i915->pmu.suspended_jiffies_last;
-   val += jiffies - kdev->power.accounting_timestamp;
+   val = kdev->power.suspended_time -
+   i915->pmu.suspended_time_last;
+   val += ktime_to_ns(ktime_get()) -
+   kdev->power.accounting_timestamp;
 
-   val = jiffies_to_nsecs(val);
val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
 
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
index 7f164ca..3dc2a30 100644
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@ -95,9 +95,9 @@ struct i915_pmu {
 */
struct i915_pmu_sample sample[__I915_NUM_PMU_SAMPLERS];
/**
-* @suspended_jiffies_last: Cached suspend time from PM core.
+* @suspended_time_last: Cached suspend time from PM core.
 */
-   unsigned long suspended_jiffies_last;
+   u64 suspended_time_last;
/**
 * @i915_attr: Memory block holding device attributes.
 */
-- 
2.7.4

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

[PATCH v2 1/3] PM/pm_runtime: move autosuspend on hrtimer

[Vincent Guittot]

pm runtime uses the timer infrastructure for autosuspend. This implies that
the minimum time before autosuspending a device is in the range
of 1 tick included to 2 ticks excluded
-On arm64 this means between 4ms and 8ms with default jiffies configuration
-And on arm, it is between 10ms and 20ms

These values are quite high for embedded system which sometimes wants
duration in the range of 1 ms.

We can move autosuspend on hrtimer to get finer granularity for short
duration and takes advantage of slack to keep some margins and gathers
long timeout in minimum wakeups.

On an arm64 platform that uses 1ms for autosuspending timeout of its GPU,
the power consumption improves by 10% for idle use case with hrtimer.

The latency impact on arm64 hikey octo cores is :
- mark_last_busy: from 1.11 us to 1.25 us
- rpm_suspend: from 15.54 us to 15.38 us
  Only the code path of rpm_suspend that starts hrtimer has been measured

arm64 image (arm64 default defconfig) decreases by around 3KB
with following details:

$ size vmlinux-timer
   textdata bss dec hex filename
120346466869268  386840 192907541265a82 vmlinux

$ size vmlinux-hrtimer
   textdata bss dec hex filename
120305506870164  387032 192877461264ec2 vmlinux

The latency impact on arm 32bits snowball dual cores is :
- mark_last_busy: from 0.31 us usec to 0.77 us
- rpm_suspend: from 6.83 us to 6.67 usec

The increase of the image for snowball platform that I used for testing
performance impact, is neglictable (244B)

$ size vmlinux-timer
   textdata bss dec hex filename
7157961 2119580  264120 9541661  91981d build-ux500/vmlinux

size vmlinux-hrtimer
   textdata bss dec hex filename
7157773 2119884  264248 9541905  919911 vmlinux-hrtimer

And arm 32bits image (multi_v7_defconfig) increases by around 1.7KB
with following details:

$ size vmlinux-timer
   textdata bss dec hex filename
133044436803420  402768 20510631138f7a7 vmlinux

$ size vmlinux-hrtimer
   textdata bss dec hex filename
133042996805276  402768 20512343138fe57 vmlinux

Signed-off-by: Vincent Guittot 
---
 drivers/base/power/runtime.c | 63 
 include/linux/pm.h   |  5 ++--
 include/linux/pm_runtime.h   |  6 ++---
 3 files changed, 40 insertions(+), 34 deletions(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index beb85c3..7062469 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -8,6 +8,8 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -93,7 +95,7 @@ static void __update_runtime_status(struct device *dev, enum 
rpm_status status)
 static void pm_runtime_deactivate_timer(struct device *dev)
 {
if (dev->power.timer_expires > 0) {
-   del_timer(>power.suspend_timer);
+   hrtimer_cancel(>power.suspend_timer);
dev->power.timer_expires = 0;
}
 }
@@ -124,12 +126,11 @@ static void pm_runtime_cancel_pending(struct device *dev)
  * This function may be called either with or without dev->power.lock held.
  * Either way it can be racy, since power.last_busy may be updated at any time.
  */
-unsigned long pm_runtime_autosuspend_expiration(struct device *dev)
+u64 pm_runtime_autosuspend_expiration(struct device *dev)
 {
int autosuspend_delay;
-   long elapsed;
-   unsigned long last_busy;
-   unsigned long expires = 0;
+   u64 last_busy, expires = 0;
+   u64 now = ktime_to_ns(ktime_get());
 
if (!dev->power.use_autosuspend)
goto out;
@@ -139,19 +140,9 @@ unsigned long pm_runtime_autosuspend_expiration(struct 
device *dev)
goto out;
 
last_busy = READ_ONCE(dev->power.last_busy);
-   elapsed = jiffies - last_busy;
-   if (elapsed < 0)
-   goto out;   /* jiffies has wrapped around. */
 
-   /*
-* If the autosuspend_delay is >= 1 second, align the timer by rounding
-* up to the nearest second.
-*/
-   expires = last_busy + msecs_to_jiffies(autosuspend_delay);
-   if (autosuspend_delay >= 1000)
-   expires = round_jiffies(expires);
-   expires += !expires;
-   if (elapsed >= expires - last_busy)
+   expires = last_busy + autosuspend_delay * NSEC_PER_MSEC;
+   if (expires <= now)
expires = 0;/* Already expired. */
 
  out:
@@ -515,7 +506,7 @@ static int rpm_suspend(struct device *dev, int rpmflags)
/* If the autosuspend_delay time hasn't expired yet, reschedule. */
if ((rpmflags & RPM_AUTO)
&& dev->power.runtime_status != RPM_SUSPENDING) {
-   unsigned long expires = pm_runtime_autosuspend_expiration(dev);
+   u64 expires = pm_runtime_autosuspend_expiration(dev);
 
if (expires != 0) {
/* Pending 

[PATCH v2 0/3] PM/pm_runtime: move on hrtimer and nsec

[Vincent Guittot]

Move pm_runtime on hrtimer and raw ns time to get finer granularity

Patch 1 moves runtime_pm autosuspend on hrtimer framework

Patch 2 moves time accounting on raw ns. This patch initially used
ktime instead of raw ns but it was easier to move i915 driver on raw ns
than on ktime

Patch 3 fixes drm/i915 driver that uses PM core fields

Changes since v1:
- updated commit message of patch 1
- Added patches 2 & 3 to move runtime_pm accounting on raw ns
  
Thara Gopinath (1):
  PM/runtime:Replace jiffies based accouting with ktime based accounting

Vincent Guittot (2):
  PM/pm_runtime: move autosuspend on hrtimer
  drm/i915: Move to new PM core fields

 drivers/base/power/runtime.c| 73 ++---
 drivers/base/power/sysfs.c  | 11 +--
 drivers/gpu/drm/i915/i915_pmu.c | 12 +++
 drivers/gpu/drm/i915/i915_pmu.h |  4 +--
 include/linux/pm.h  | 11 ---
 include/linux/pm_runtime.h  |  6 ++--
 6 files changed, 64 insertions(+), 53 deletions(-)

-- 
2.7.4

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

Re: [PATCH v2 11/12] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel

[Sean Paul]

On Fri, Dec 14, 2018 at 04:35:11PM +0530, Jagan Teki wrote:
> On Fri, Dec 14, 2018 at 1:25 AM Sean Paul  wrote:
> >
> > On Fri, Dec 14, 2018 at 12:56:03AM +0530, Jagan Teki wrote:
> > > On Thu, Dec 13, 2018 at 8:37 PM Sean Paul  wrote:
> > > >
> > > > On Fri, Nov 16, 2018 at 10:09:15PM +0530, Jagan Teki wrote:
> > > > > Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
> > > > >
> > > > > Add panel driver for it.
> > > > >
> > > > > Signed-off-by: Jagan Teki 
> > > > > ---
> > > > >  MAINTAINERS   |   6 +
> > > > >  drivers/gpu/drm/panel/Kconfig |   9 +
> > > > >  drivers/gpu/drm/panel/Makefile|   1 +
> > > > >  .../drm/panel/panel-feiyang-fy07024di26a30d.c | 286 
> > > > > ++
> > > > >  4 files changed, 302 insertions(+)
> > > > >  create mode 100644 
> > > > > drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > > > >
> >
> > /snip
> >
> > > > > diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c 
> > > > > b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > > > > new file mode 100644
> > > > > index ..a4b46bd8fdbe
> > > > > --- /dev/null
> > > > > +++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> >
> > /snip
> >
> > > > > +static int feiyang_prepare(struct drm_panel *panel)
> > > > > +{
> > > > > + struct feiyang *ctx = panel_to_feiyang(panel);
> > > > > + struct mipi_dsi_device *dsi = ctx->dsi;
> > > > > + unsigned int i;
> > > > > + int ret;
> > > > > +
> > > > > + ret = regulator_enable(ctx->dvdd);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + msleep(100);
> > > >
> > > > nit: You should do your best to correlate the sleeps with the timing 
> > > > parameters
> > > > from the datasheet with a comment.
> > > >
> > > > ie:
> > > > /* T1: > 100ms */
> > > > msleep(100);
> > >
> > > Sorry, what does this mean?
> >
> > On page 9 of the datasheet you sent me [1], it has the delays required to 
> > safely
> > power up the panel. This delay is the time between dvdd going high and avdd
> > going high. On the figure in the datasheet, this would be T2 (T1 is dvdd 
> > rise
> 
> time between dvdd going high and avdd going high is T1 + T3 right?
> 
> T2 > 0ms
> T3 > 20ms
> 
> In this case the delay can be msleep(20) ?

Hmm, yeah, I didn't notice that T3 was > 20ms, that's kind of confusing. So I
think you're right, this should be T2 + T3 > 20ms (T1 is covered in the
regulator_enable of dvdd).

> 
> > time and should be handled in the regulator subsystem (iirc)). Also 
> > according to
> > the datasheet, T2 just needs to be > 0, so you don't even need this delay. 
> > You
> > could replace this with a comment like:
> >
> > /* T1 (dvdd rise time) + T2 (dvdd->avdd) > 0 */
> >
> > So for all of the msleeps below you should get the delays from the 
> > datasheet and
> > add a comment referencing them.
> 
> T5 and T6 are delay between avdd to reset enable it can be 10 + 10
> = 20ms and finally T12 which is 200 after reset.
> 
> What about the delay between resets, I need to understand it a bit.

These are usually accounted for at the end of disable. Take a look at the sleep
parameters in panel-simple for an example.

Sean

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

[PATCH] drm/vc4: Limit SAND tiling support to semiplanar YUV420 formats

[Paul Kocialkowski]

Despite what the HVS documentation indicates, the VC4 does not actually
support SAND tiling modes for any RGB format and only semiplanar YUV420
formats (NV12/NV21) can be used in these tiling modes.

The driver currently claims to support RGB formats for the associated
modifiers, so remove them from the supported list in the
format_mod_supported helper for RGB formats.

Remove further checks that are no longer necessary along the way, since
semi-planar YUV420 formats support every SAND tiling mode.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 75db62cbe468..a176e7d8af27 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -596,20 +596,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
case DRM_FORMAT_MOD_BROADCOM_SAND256: {
uint32_t param = fourcc_mod_broadcom_param(fb->modifier);
 
-   /* Column-based NV12 or RGBA.
-*/
-   if (fb->format->num_planes > 1) {
-   if (hvs_format != HVS_PIXEL_FORMAT_YCBCR_YUV420_2PLANE) 
{
-   DRM_DEBUG_KMS("SAND format only valid for 
NV12/21");
-   return -EINVAL;
-   }
-   hvs_format = HVS_PIXEL_FORMAT_H264;
-   } else {
-   if (base_format_mod == DRM_FORMAT_MOD_BROADCOM_SAND256) 
{
-   DRM_DEBUG_KMS("SAND256 format only valid for 
H.264");
-   return -EINVAL;
-   }
-   }
+   hvs_format = HVS_PIXEL_FORMAT_H264;
 
switch (base_format_mod) {
case DRM_FORMAT_MOD_BROADCOM_SAND64:
@@ -1050,8 +1037,6 @@ static bool vc4_format_mod_supported(struct drm_plane 
*plane,
switch (fourcc_mod_broadcom_mod(modifier)) {
case DRM_FORMAT_MOD_LINEAR:
case DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED:
-   case DRM_FORMAT_MOD_BROADCOM_SAND64:
-   case DRM_FORMAT_MOD_BROADCOM_SAND128:
return true;
default:
return false;
-- 
2.19.2

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

Re: [RFC AFBC 06/12] drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650

[Ayan Halder]

On Tue, Dec 04, 2018 at 04:57:46PM +, Liviu Dudau wrote:

Hi Liviu,
> On Mon, Dec 03, 2018 at 11:32:00AM +, Ayan Halder wrote:
> > We have added some new formats to be supported on DP500/DP550/DP650.
> 
> Make a bit more descriptive commit message here, please!
>
I will keep the following commit message :-

""We have added support for some AFBC only pixel formats like :-
DRM_FORMAT_YUV420_8BIT (single plane YUV 420 8 bit format)
DRM_FORMAT_VUY888 (single plane YUV 444 8 bit format)
DRM_FORMAT_VUY101010 (single plane YUV 444 10 bit format)
DRM_FORMAT_YUV420_10BIT (single plane YUV 420 10 bit format)

Generally, these formats are supported by our hardware using the same hw-ids as
the equivalent multi plane pixel formats.

Also we have added support for XYUV 444 8 and 10 bit formats.""

Let me know if this looks fine.

Thanks,
Ayan Kumar halder
> > 
> > Signed-off-by: Ayan Kumar Halder 
> > 
> > Depends on :- https://patchwork.kernel.org/patch/10460063/
> 
> Reviewed-by: Liviu Dudau 
> 
> Best regards,
> Liviu
> 
> > ---
> >  drivers/gpu/drm/arm/malidp_hw.c | 22 +-
> >  1 file changed, 21 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.c 
> > b/drivers/gpu/drm/arm/malidp_hw.c
> > index 55d379b..25ac5890 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > @@ -49,6 +49,12 @@ static const struct malidp_format_id 
> > malidp500_de_formats[] = {
> > { DRM_FORMAT_YUYV, DE_VIDEO1, 13 },
> > { DRM_FORMAT_NV12, DE_VIDEO1 | SE_MEMWRITE, 14 },
> > { DRM_FORMAT_YUV420, DE_VIDEO1, 15 },
> > +   { DRM_FORMAT_XYUV, DE_VIDEO1, 16 },
> > +   /* These are supported with AFBC only */
> > +   { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1, 14 },
> > +   { DRM_FORMAT_VUY888, DE_VIDEO1, 16 },
> > +   { DRM_FORMAT_VUY101010, DE_VIDEO1, 17 },
> > +   { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1, 18 }
> >  };
> >  
> >  #define MALIDP_ID(__group, __format) \
> > @@ -74,11 +80,25 @@ static const struct malidp_format_id 
> > malidp500_de_formats[] = {
> > { DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, 
> > MALIDP_ID(4, 1) }, \
> > { DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4, 
> > 2) }, \
> > { DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4, 
> > 3) }, \
> > +   /* This is only supported with linear modifier */   \
> > +   { DRM_FORMAT_XYUV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) },\
> > +   /* This is only supported with AFBC modifier */ \
> > +   { DRM_FORMAT_VUY888, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) }, \
> > { DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
> > +   /* This is only supported with linear modifier */ \
> > { DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
> > { DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6) 
> > },  \
> > +   /* This is only supported with AFBC modifier */ \
> > +   { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) }, \
> > { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
> > -   { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
> > +   /* This is only supported with linear modifier */ \
> > +   { DRM_FORMAT_XVYU2101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
> > +   /* This is only supported with AFBC modifier */ \
> > +   { DRM_FORMAT_VUY101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
> > +   { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}, \
> > +   /* This is only supported with AFBC modifier */ \
> > +   { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}, \
> > +   { DRM_FORMAT_P010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}
> >  
> >  static const struct malidp_format_id malidp550_de_formats[] = {
> > MALIDP_COMMON_FORMATS,
> > -- 
> > 2.7.4
> > 
> 
> -- 
> 
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---
> ??\_(???)_/??
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107826] amdgpu-pro 18.30/18.40: Missing xserver modesetting package (--px install)

[bugzilla-daemon]

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

Jeremy Newton  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Jeremy Newton  ---
You can add the --opencl parameter to the all open install as well.

For example:

./amdgpu-install --opencl=pal

This would install the all open stack plus the OpenCL stack for Vega onwards.

The OpenCL stack is separate, so it should work over either variant.

I'll discuss with the team and add some clarification w.r.t. openCL in the
documentation. As for PX, I added a note about the deprecation in the docs, but
it didn't quite make the 18.50 release posted yesterday. It should be available
in newer builds.

Thanks for the bug report!

-- 
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 201991] New: amdgpu: clock management is disabled for the 4K resolution with polaris 10

[bugzilla-daemon]

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

Bug ID: 201991
   Summary: amdgpu: clock management is disabled for the 4K
resolution with polaris 10
   Product: Drivers
   Version: 2.5
Kernel Version: 4.18.0,4.20.0-rc6, drm-next-4.21-wip
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: fin4...@hotmail.com
Regression: No

Created attachment 280019
  --> https://bugzilla.kernel.org/attachment.cgi?id=280019=edit
simple app for the amdgpu sys interface

When the Xfce desktop is visible at 4K and idling, the engine clock is fixed at
level 6: 1220MHz and you can not change that. The temperature is 38 C. When the
monitor is sleeping, then the engine clock is 300Mhz. The automatic power
management works with 2560x1600 and lower resolutions as espected. I tested
with my python app and I have latest drivers, including firmware files. My
monitor is ASUS VP28UQG and I use the display port.

System:
  Host: ryzenpc Kernel: 4.20.0-rc6 x86_64 bits: 64 Desktop: Xfce 4.12.4 
  Distro: Debian GNU/Linux buster/sid 
Machine:
  Type: Desktop Mobo: ASUSTeK model: PRIME B350M-K v: Rev X.0x 
  serial:  UEFI [Legacy]: American Megatrends v: 4023 
  date: 08/20/2018 
CPU:
  6-Core: AMD Ryzen 5 1600 type: MT MCP speed: 2851 MHz 
Graphics:
  Device-1: AMD Ellesmere [Radeon RX 470/480] driver: amdgpu v: kernel 
  Display: x11 server: X.Org 1.20.3 driver: amdgpu,ati 
  unloaded: fbdev,modesetting,vesa resolution: 3840x2160~60Hz 
  OpenGL: 
  renderer: Radeon RX 570 Series (POLARIS10 DRM 3.27.0 4.20.0-rc6 LLVM 7.0.1) 
  v: 4.5 Mesa 19.0.0-devel (git-9ebc00f 2018-12-13 bionic-oibaf-ppa)

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

[radeon-alex:amd-18.50 790/1415] drivers/gpu//drm/ttm/ttm_bo_util.c:299:10: error: implicit declaration of function '__kcl__kmap_atomic'; did you mean '__kunmap_atomic'?

[kbuild test robot]

Hi Kevin,

FYI, the error/warning still remains.

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-18.50
head:   88a0039cb034176ee3416dd0c3a49feea2f446ab
commit: 7d0741bab20cb328c2c778764efc340896242ccb [790/1415] drm/amdkcl: [RHEL 
6] support kmap_atomic funciton for ttm module
config: ia64-defconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 7d0741bab20cb328c2c778764efc340896242ccb
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=ia64 

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

   drivers/gpu//drm/ttm/ttm_bo_util.c: In function 'ttm_kmap_atomic_prot':
>> drivers/gpu//drm/ttm/ttm_bo_util.c:299:10: error: implicit declaration of 
>> function '__kcl__kmap_atomic'; did you mean '__kunmap_atomic'? 
>> [-Werror=implicit-function-declaration]
  return __kcl__kmap_atomic(page);
 ^~
 __kunmap_atomic
>> drivers/gpu//drm/ttm/ttm_bo_util.c:299:10: warning: returning 'int' from a 
>> function with return type 'void *' makes pointer from integer without a cast 
>> [-Wint-conversion]
  return __kcl__kmap_atomic(page);
 ^~~~
   drivers/gpu//drm/ttm/ttm_bo_util.c: In function 'ttm_kunmap_atomic_prot':
>> drivers/gpu//drm/ttm/ttm_bo_util.c:315:3: error: implicit declaration of 
>> function '__kcl__kunmap_atomic'; did you mean '__kunmap_atomic'? 
>> [-Werror=implicit-function-declaration]
  __kcl__kunmap_atomic(addr);
  ^~~~
  __kunmap_atomic
   cc1: some warnings being treated as errors

vim +299 drivers/gpu//drm/ttm/ttm_bo_util.c

   280  
   281  
   282  /**
   283   * ttm_kmap_atomic_prot - Efficient kernel map of a single page with
   284   * specified page protection.
   285   *
   286   * @page: The page to map.
   287   * @prot: The page protection.
   288   *
   289   * This function maps a TTM page using the kmap_atomic api if available,
   290   * otherwise falls back to vmap. The user must make sure that the
   291   * specified page does not have an aliased mapping with a different 
caching
   292   * policy unless the architecture explicitly allows it. Also mapping and
   293   * unmapping using this api must be correctly nested. Unmapping should
   294   * occur in the reverse order of mapping.
   295   */
   296  void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot)
   297  {
   298  if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
 > 299  return __kcl__kmap_atomic(page);
   300  else
   301  return __ttm_kmap_atomic_prot(page, prot);
   302  }
   303  EXPORT_SYMBOL(ttm_kmap_atomic_prot);
   304  
   305  /**
   306   * ttm_kunmap_atomic_prot - Unmap a page that was mapped using
   307   * ttm_kmap_atomic_prot.
   308   *
   309   * @addr: The virtual address from the map.
   310   * @prot: The page protection.
   311   */
   312  void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot)
   313  {
   314  if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
 > 315  __kcl__kunmap_atomic(addr);
   316  else
   317  __ttm_kunmap_atomic(addr);
   318  }
   319  EXPORT_SYMBOL(ttm_kunmap_atomic_prot);
   320  

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


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

Re: [RFC v3 AFBC 04/12] drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier

[Ayan Halder]

On Tue, Dec 04, 2018 at 04:50:51PM +, Liviu Dudau wrote:

Hi Liviu,

Please let me know if you agree with my comments. Then I will send a
v4 patch for this.
> On Mon, Dec 03, 2018 at 11:31:58AM +, Ayan Halder wrote:
> > Added the AFBC decoder registers for DP500 , DP550 and DP650.
> > These registers control the processing of AFBC buffers. It controls various
> > features like AFBC decoder enable, lossless transformation and block split
> > as well as setting of the left, right, top and bottom cropping of AFBC 
> > buffers
> > (in number of pixels).
> > All the layers (except DE_SMART) support framebuffers with AFBC modifiers.
> > One needs to set the pixel values of the top, left, bottom and right 
> > cropping
> > for the AFBC framebuffer.
> > Cropping an AFBC framebuffer is controlled by the AFBC crop registers.
> > In that case, the layer input size registers should be configured with
> > framebuffer's dimensions and not with drm_plane_state source width/height
> > values (which is used for non AFBC framebuffer to denote cropping).
> > 
> > Changes from v1:
> >  - Removed the "if (fb->modifier)" check from malidp_de_plane_update()
> > and added it in malidp_de_set_plane_afbc(). This will consolidate all the
> > AFBC specific register configurations in a single function ie
> > malidp_de_set_plane_afbc().
> > 
> > Changes from v2:
> >  - For AFBC framebuffer, layer input size register should be set to 
> > framebuffer's
> > width and height
> > 
> > Signed-off-by: Ayan Kumar Halder 
> > ---
> >  drivers/gpu/drm/arm/malidp_hw.c |  25 +
> >  drivers/gpu/drm/arm/malidp_hw.h |   2 +
> >  drivers/gpu/drm/arm/malidp_planes.c | 109 
> > +++-
> >  drivers/gpu/drm/arm/malidp_regs.h   |  20 +++
> >  4 files changed, 130 insertions(+), 26 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.c 
> > b/drivers/gpu/drm/arm/malidp_hw.c
> > index b9bed11..87b7b12 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > @@ -94,11 +94,12 @@ static const struct malidp_layer malidp500_layers[] = {
> >  *  yuv2rgb matrix offset, mmu control register offset, 
> > rotation_features
> >  */
> > { DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
> > -   MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY },
> > +   MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY,
> > +   MALIDP500_DE_LV_AD_CTRL },
> > { DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
> > -   MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
> > +   MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP500_DE_LG1_AD_CTRL 
> > },
> > { DE_GRAPHICS2, MALIDP500_DE_LG2_BASE, MALIDP500_DE_LG2_PTR_BASE,
> > -   MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
> > +   MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP500_DE_LG2_AD_CTRL 
> > },
> >  };
> >  
> >  static const struct malidp_layer malidp550_layers[] = {
> > @@ -106,13 +107,15 @@ static const struct malidp_layer malidp550_layers[] = 
> > {
> >  *  yuv2rgb matrix offset, mmu control register offset, 
> > rotation_features
> >  */
> > { DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
> > -   MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
> > +   MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
> > +   MALIDP550_DE_LV1_AD_CTRL },
> > { DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
> > -   MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
> > +   MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP550_DE_LG_AD_CTRL 
> > },
> > { DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
> > -   MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
> > +   MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
> > +   MALIDP550_DE_LV2_AD_CTRL },
> > { DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
> > -   MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE },
> > +   MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE, 0 },
> >  };
> >  
> >  static const struct malidp_layer malidp650_layers[] = {
> > @@ -122,16 +125,16 @@ static const struct malidp_layer malidp650_layers[] = 
> > {
> >  */
> > { DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
> > MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
> > -   MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
> > +   MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY, MALIDP550_DE_LV1_AD_CTRL 
> > },
> > { DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
> > MALIDP_DE_LG_STRIDE, 0, MALIDP650_DE_LG_MMU_CTRL,
> > -   ROTATE_COMPRESSED },
> > +   ROTATE_COMPRESSED, MALIDP550_DE_LG_AD_CTRL },
> > { DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
> > MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
> > -   

[maintainer-tools PATCH RFC 0/3] dim: fix git directory evaluation

[Andrzej Hajda]

Hi all,

This small patchset fixes issues with dim used on git worktree's. It was not
widely tested - as I am little bit afraid to break drm infrastructure, and
I do not know if and how it interacts with other maintainer tools.
Especially in case of the last patch I am not sure what I am really touching :)

Regards
Andrzej


Andrzej Hajda (3):
  dim: allow git_dir to specify arbitrary work directory
  dim: fix git directory handling
  dim: fix rr_cache_dir discovery

 dim | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

-- 
2.17.1

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

[maintainer-tools PATCH RFC 2/3] dim: fix git directory handling

[Andrzej Hajda]

Assumption that git directory is always located at REPO/.git is incorrect,
especially in case of git worktrees. There is already function to deal
with it correctly - git_dir, let's then use it.

Signed-off-by: Andrzej Hajda 
---
 dim | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/dim b/dim
index df66c58..3afa8b6 100755
--- a/dim
+++ b/dim
@@ -1088,12 +1088,7 @@ function dim_backmerge
 
git merge --rerere-autoupdate --no-commit $upstream >& /dev/null || true
 
-   if [[ -d .git ]]; then
-   patch_file=".git"
-   else
-   patch_file=$(cut -d ' ' -f 2 .git)
-   fi
-   patch_file=$patch_file/MERGE_MSG
+   patch_file=$(git_dir)/MERGE_MSG
 
 
cat > $patch_file <<-HERE
@@ -1340,7 +1335,7 @@ dim_alias_mrr=magic-rebase-resolve
 function dim_magic_rebase_resolve
 {
git diff HEAD | patch -p1 -R
-   dim_magic_patch < .git/rebase-merge/patch
+   dim_magic_patch < $(git_dir)/rebase-merge/patch
make $DIM_MAKE_OPTIONS
git add -u
git rebase --continue
@@ -2102,7 +2097,7 @@ function setup_aux_checkout # name url directory
git clone --reference=$DIM_PREFIX/$DIM_REPO/.git $url 
$dir
cd $dir
git config remote.origin.url $url
-   echo "$DIM_PREFIX/$DIM_REPO/.git/objects" > 
.git/objects/info/alternates
+   echo "$(git_dir $DIM_PREFIX/$DIM_REPO)/objects" > 
$(git_dir)/objects/info/alternates
git repack -a -d -l
remote=origin
fi
@@ -2132,7 +2127,7 @@ function dim_setup
fi
cd $DIM_PREFIX
 
-   if [ ! -d $DIM_PREFIX/$DIM_REPO/.git ]; then
+   if [ ! -d $(git_dir $DIM_PREFIX/$DIM_REPO) ]; then
echoerr "No git checkout found in $DIM_PREFIX/$DIM_REPO."
echoerr "Please set up your maintainer linux repository at 
$DIM_PREFIX/$DIM_REPO with"
echoerr "cd $DIM_PREFIX"
-- 
2.17.1

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

[maintainer-tools PATCH RFC 1/3] dim: allow git_dir to specify arbitrary work directory

[Andrzej Hajda]

git_dir function returns git directory for current working directory.
Allowing specifying any directory allows to reuse it more widely.

Signed-off-by: Andrzej Hajda 
---
 dim | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/dim b/dim
index 70939ff..df66c58 100755
--- a/dim
+++ b/dim
@@ -565,10 +565,12 @@ function rr_cache_dir
 
 function git_dir
 {
-   if [ -d $PWD/.git ] ; then
-   echo $PWD/.git
+   local dir=${1:-$PWD}
+
+   if [ -d $dir/.git ] ; then
+   echo $dir/.git
else
-   cut -d ' ' -f 2 < $PWD/.git
+   cut -d ' ' -f 2 < $dir/.git
fi
 }
 
-- 
2.17.1

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

[maintainer-tools PATCH RFC 3/3] dim: fix rr_cache_dir discovery

[Andrzej Hajda]

rr_cache_dir function cannot assume REPO/.git is a directory. On the other
side it should be backward compatible - if rr-cache directory/link already
exists it should be returned.

Signed-off-by: Andrzej Hajda 
---
Hi,

I am not sure of the purpose of rr-cache symbolic link, dim does not use
it (except its creation/removal). So this patch should be verified by
someone who knows better what is going on here.

Regards
Andrzej
---
 dim | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/dim b/dim
index 3afa8b6..b72ebfd 100755
--- a/dim
+++ b/dim
@@ -554,15 +554,6 @@ function check_conflicts # tree
true
 }
 
-function rr_cache_dir
-{
-   if [ -d $DIM_PREFIX/drm-tip/.git/ ] ; then
-   echo $DIM_PREFIX/drm-tip/.git/rr-cache
-   else
-   echo $DIM_PREFIX/$DIM_REPO/.git/rr-cache
-   fi
-}
-
 function git_dir
 {
local dir=${1:-$PWD}
@@ -574,6 +565,17 @@ function git_dir
fi
 }
 
+function rr_cache_dir
+{
+   local dir=$(git_dir $DIM_PREFIX/$DIM_REPO)/rr-cache
+
+   if [ -d $dir ]; then
+   echo $dir
+   else
+   echo $(git_dir $DIM_PREFIX/drm-tip)/rr-cache
+   fi
+}
+
 function pull_rerere_cache
 {
cd $DIM_PREFIX/drm-rerere/
-- 
2.17.1

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

Re: [PATCH] drm/panel: simple: fix AUO g185han01 horizontal blanking

[Lucas Stach]

Hi Thierry,

can you please have a look at this one?

Regards,
Lucas

Am Montag, den 12.11.2018, 18:41 +0100 schrieb Lucas Stach:
> The horizontal blanking periods are too short, as the values are
> specified for a single LVDS channel. Since this panel is dual LVDS
> they need to be doubled. With this change the panel reaches its
> nominal vrefresh rate of 60Fps, instead of the 64Fps with the
> current wrong blanking.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 97964f7f2ace..2c89792e91e2 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -663,9 +663,9 @@ static const struct panel_desc auo_g133han01 = {
>  static const struct display_timing auo_g185han01_timings = {
>   .pixelclock = { 12000, 14400, 17500 },
>   .hactive = { 1920, 1920, 1920 },
> - .hfront_porch = { 18, 60, 74 },
> - .hback_porch = { 12, 44, 54 },
> - .hsync_len = { 10, 24, 32 },
> + .hfront_porch = { 36, 120, 148 },
> + .hback_porch = { 24, 88, 108 },
> + .hsync_len = { 20, 48, 64 },
>   .vactive = { 1080, 1080, 1080 },
>   .vfront_porch = { 6, 10, 40 },
>   .vback_porch = { 2, 5, 20 },
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107826] amdgpu-pro 18.30/18.40: Missing xserver modesetting package (--px install)

[bugzilla-daemon]

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

--- Comment #3 from qnerd  ---
Thank you, that clears the situation.

I am aware of using the all-open variant using PRIME,
and indeed it does work quite nicely.

What about OpenCl though?
Can you get away using the all-open driver and just
installing the opencl part via --headless?
Would you be able to access both graphic cards via OpenCl?


Regards,

-- 
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 108919] Parkitect (Unity Game) dispalys artifacts and black screens with Vega hardware

[bugzilla-daemon]

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

--- Comment #12 from Adam Lyall  ---
Just adding this same bug affects Tonga based GPUs as well.

-- 
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] video/backlight: Use of_node_name_eq for node name comparisons

[Lee Jones]

On Thu, 06 Dec 2018, Daniel Thompson wrote:

> On Wed, Dec 05, 2018 at 01:50:44PM -0600, Rob Herring wrote:
> > Convert string compares of DT node names to use of_node_name_eq helper
> > instead. This removes direct access to the node name pointer.
> > 
> > For instances using of_node_cmp, this has the side effect of now using
> > case sensitive comparisons. This should not matter for any FDT based
> > system which this is.
> > 
> > Cc: Lee Jones 
> > Cc: Daniel Thompson 
> > Cc: Jingoo Han 
> > Cc: Bartlomiej Zolnierkiewicz 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-fb...@vger.kernel.org
> > Signed-off-by: Rob Herring 
> 
> Acked-by: Daniel Thompson 
> 
> [this is FAO Lee J. rather than recommending you take it via you tree]

Rob knows better than that. ;)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 3/3] drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequences

[Hans de Goede]

Add support for PMIC MIPI sequences using the new
intel_soc_pmic_exec_mipi_pmic_seq_element function.

This fixes the DSI LCD panel not lighting up when not initialized by the
GOP (because an external monitor was connected) on GPD win and GPD pocket
devices.

Specifically the LCD panel seems to need GPIO pin 9 on the PMIC to be
driven high, which is done through a PMIC MIPI sequence. Before this commit
if the sequence was not executed by the GOP the pin would stay low causing
the LCD panel to not work. Having the MIPI sequences properly control this
GPIO should also help save some power when the panel is off.

Changes in v2, v3:
-Only changes to other patches in this patch-set

Changes in v4:
-Move decoding of the raw 15 bytes PMIC MIPI sequence element into
 i2c-address, register-address, value and mask into the mipi_exec_pmic()
 function instead of passing the raw data to
 intel_soc_pmic_exec_mipi_pmic_seq_element()

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_dsi_vbt.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index f27af47c6e49..ebe7e25614ce 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -29,9 +29,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "i915_drv.h"
 #include "intel_drv.h"
@@ -371,7 +373,25 @@ static const u8 *mipi_exec_spi(struct intel_dsi 
*intel_dsi, const u8 *data)
 
 static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data)
 {
-   DRM_DEBUG_KMS("Skipping PMIC element execution\n");
+#ifdef CONFIG_PMIC_OPREGION
+   u32 value, mask, reg_address;
+   u16 i2c_address;
+   int ret;
+
+   /* byte 0 aka PMIC Flag is reserved */
+   i2c_address = get_unaligned_le16(data + 1);
+   reg_address = get_unaligned_le32(data + 3);
+   value   = get_unaligned_le32(data + 7);
+   mask= get_unaligned_le32(data + 11);
+
+   ret = intel_soc_pmic_exec_mipi_pmic_seq_element(i2c_address,
+   reg_address,
+   value, mask);
+   if (ret)
+   DRM_ERROR("%s failed, error: %d\n", __func__, ret);
+#else
+   DRM_ERROR("Your hardware requires CONFIG_PMIC_OPREGION and it is not 
set\n");
+#endif
 
return data + 15;
 }
-- 
2.19.2

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

[PATCH v5 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC

[Hans de Goede]

Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.

On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, because an external monitor was plugged in and
the GOP initialized only the external monitor.

Reviewed-by: Mika Westerberg 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-The decoding of the raw data of the PMIC MIPI sequence element is now done
 in our caller, so drop this and adjust the callback prototype to accept
 the decoded addresses, value and mask

Changes in v3:
-Use hex values for out of range checks
-Make intel_cht_wc_exec_mipi_pmic_seq_element return errors

Changes in v2:
-Interpret data passed to the PMIC MIPI elements according to the docs
 instead of my own reverse engineered interpretation
---
 drivers/acpi/pmic/intel_pmic_chtwc.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c 
b/drivers/acpi/pmic/intel_pmic_chtwc.c
index 078b0448f30a..7ffd5624b8e1 100644
--- a/drivers/acpi/pmic/intel_pmic_chtwc.c
+++ b/drivers/acpi/pmic/intel_pmic_chtwc.c
@@ -231,6 +231,24 @@ static int intel_cht_wc_pmic_update_power(struct regmap 
*regmap, int reg,
return regmap_update_bits(regmap, reg, bitmask, on ? 1 : 0);
 }
 
+static int intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
+  u16 i2c_client_address,
+  u32 reg_address,
+  u32 value, u32 mask)
+{
+   u32 address;
+
+   if (i2c_client_address > 0xff || reg_address > 0xff) {
+   pr_warn("%s warning addresses too big client 0x%x reg 0x%x\n",
+   __func__, i2c_client_address, reg_address);
+   return -ERANGE;
+   }
+
+   address = (i2c_client_address << 8) | reg_address;
+
+   return regmap_update_bits(regmap, address, mask, value);
+}
+
 /*
  * The thermal table and ops are empty, we do not support the Thermal opregion
  * (DPTF) due to lacking documentation.
@@ -238,6 +256,7 @@ static int intel_cht_wc_pmic_update_power(struct regmap 
*regmap, int reg,
 static struct intel_pmic_opregion_data intel_cht_wc_pmic_opregion_data = {
.get_power  = intel_cht_wc_pmic_get_power,
.update_power   = intel_cht_wc_pmic_update_power,
+   .exec_mipi_pmic_seq_element = intel_cht_wc_exec_mipi_pmic_seq_element,
.power_table= power_table,
.power_table_count  = ARRAY_SIZE(power_table),
 };
-- 
2.19.2

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

[PATCH v5 0/3] ACPI/i915: Add support for PMIC MIPI sequence elements

[Hans de Goede]

Hi All,

The main reason for sending out this v5 is because the CI failed v4
(even though it liked v1-v3 and nothing significant changed), this
was likely a false positive, so the main goal of this version is to give
this another CI run.

Besides that I've dropped the unnecessary #include from the 2nd patch
which Mika pointed out.

Patches 1 and 2 have been Acked for merging through drm-intel-next-queued
even though they are for the ACPI subsys, so that we can keep the set
together.

If I can get a Reviewed-by or Acked-by for the 3th patch from one of the
i915 people, then I can push this set to dinq.

Regards,

Hans

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

[PATCH v5 1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements

[Hans de Goede]

DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes.

Although this is not really an ACPI opregion, the ACPI opregion code is the
closest thing we have. We need to have support for these PMIC specific MIPI
sequence elements somwhere. Since we already instantiate a special platform
device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to,
with PMIC specific implementations of the OpRegion, the handling of MIPI
sequence PMIC elements fits very well in the ACPI PMIC OpRegion code.

This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element()
function, which is to be backed by a PMIC specific
exec_mipi_pmic_seq_element callback. This function will be called by the
i915 code to execture MIPI sequence PMIC elements.

Reviewed-by: Mika Westerberg 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Pass i2c-address + register-address + value + mask as separate arguments to
 the intel_soc_pmic_exec_mipi_pmic_seq_element function. Instead of passing
 the 15 bytes of raw MIPI sequence data. The decoding will be done in the
 i915 VBT code instead.

Changes in v3:
-Add kerneldoc for intel_soc_pmic_exec_mipi_pmic_seq_element
-Make intel_soc_pmic_exec_mipi_pmic_seq_element return errors
---
 drivers/acpi/pmic/intel_pmic.c | 49 ++
 drivers/acpi/pmic/intel_pmic.h |  2 ++
 include/linux/mfd/intel_soc_pmic.h |  3 ++
 3 files changed, 54 insertions(+)

diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
index ca18e0d23df9..6bd25e96f41f 100644
--- a/drivers/acpi/pmic/intel_pmic.c
+++ b/drivers/acpi/pmic/intel_pmic.c
@@ -15,6 +15,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "intel_pmic.h"
@@ -36,6 +37,8 @@ struct intel_pmic_opregion {
struct intel_pmic_regs_handler_ctx ctx;
 };
 
+static struct intel_pmic_opregion *intel_pmic_opregion;
+
 static int pmic_get_reg_bit(int address, struct pmic_table *table,
int count, int *reg, int *bit)
 {
@@ -304,6 +307,7 @@ int intel_pmic_install_opregion_handler(struct device *dev, 
acpi_handle handle,
}
 
opregion->data = d;
+   intel_pmic_opregion = opregion;
return 0;
 
 out_remove_thermal_handler:
@@ -319,3 +323,48 @@ int intel_pmic_install_opregion_handler(struct device 
*dev, acpi_handle handle,
return ret;
 }
 EXPORT_SYMBOL_GPL(intel_pmic_install_opregion_handler);
+
+/**
+ * intel_soc_pmic_exec_mipi_pmic_seq_element - Execute PMIC MIPI sequence
+ * @i2c_address:  I2C client address for the PMIC
+ * @reg_address:  PMIC register address
+ * @value:New value for the register bits to change
+ * @mask: Mask indicating which register bits to change
+ *
+ * DSI LCD panels describe an initialization sequence in the i915 VBT (Video
+ * BIOS Tables) using so called MIPI sequences. One possible element in these
+ * sequences is a PMIC specific element of 15 bytes.
+ *
+ * This function executes these PMIC specific elements sending the embedded
+ * commands to the PMIC.
+ *
+ * Return 0 on success, < 0 on failure.
+ */
+int intel_soc_pmic_exec_mipi_pmic_seq_element(u16 i2c_address, u32 reg_address,
+ u32 value, u32 mask)
+{
+   struct intel_pmic_opregion_data *d;
+   int ret;
+
+   if (!intel_pmic_opregion) {
+   pr_warn("%s: No PMIC registered\n", __func__);
+   return -ENXIO;
+   }
+
+   d = intel_pmic_opregion->data;
+   if (!d->exec_mipi_pmic_seq_element) {
+   pr_warn("%s: Not implemented\n", __func__);
+   pr_warn("%s: i2c-addr: 0x%x reg-addr 0x%x value 0x%x mask 
0x%x\n",
+   __func__, i2c_address, reg_address, value, mask);
+   return -EOPNOTSUPP;
+   }
+
+   mutex_lock(_pmic_opregion->lock);
+   ret = d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap,
+   i2c_address, reg_address,
+   value, mask);
+   mutex_unlock(_pmic_opregion->lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_exec_mipi_pmic_seq_element);
diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
index 095afc96952e..5cd195fabca8 100644
--- a/drivers/acpi/pmic/intel_pmic.h
+++ b/drivers/acpi/pmic/intel_pmic.h
@@ -15,6 +15,8 @@ struct intel_pmic_opregion_data {
int (*update_aux)(struct regmap *r, int reg, int raw_temp);
int (*get_policy)(struct regmap *r, int reg, int bit, u64 *value);
int (*update_policy)(struct regmap *r, int reg, int bit, int enable);
+   int (*exec_mipi_pmic_seq_element)(struct regmap *r, u16 i2c_address,
+ u32 reg_address, u32 value, u32 mask);
struct pmic_table *power_table;
int power_table_count;
struct 

Re: [PATCH RFC v2 5/8] drm/bridge: dw-hdmi: support dynamically get input/out color info

[Heiko Stuebner]

Am Freitag, 30. November 2018, 14:42:58 CET schrieb Neil Armstrong:
> From: Zheng Yang 
> 
> To get input/output bus_format/enc_format dynamically, this patch
> introduce following funstion in plat_data:
>   - get_input_bus_format
>   - get_output_bus_format
>   - get_enc_in_encoding
>   - get_enc_out_encoding
> 
> Signed-off-by: Zheng Yang 
> Signed-off-by: Neil Armstrong 

Please see comments in patch1 for details.

on rk3288 and rk3328
Tested-by: Heiko Stuebner 



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

Re: [PATCH RFC v2 4/8] drm/bridge: dw-hdmi: add support for YUV420 output

[Heiko Stuebner]

Am Freitag, 30. November 2018, 14:42:57 CET schrieb Neil Armstrong:
> In order to support the HDMI2.0 YUV420 display modes, this patch
> adds support for the YUV420 TMDS Clock divided by 2 and the controller
> passthrough mode.
> 
> YUV420 Synopsys PHY support will need some specific configuration table
> to support theses modes.
> 
> This patch is based on work from Zheng Yang  in
> the Rockchip Linux 4.4 BSP at [1]
> 
> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4
> 
> Cc: Zheng Yang 
> Signed-off-by: Neil Armstrong 

Please see comments in patch1 for details.

on rk3288 and rk3328
Tested-by: Heiko Stuebner 



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

Re: [PATCH RFC v2 6/8] drm/bridge: dw-hdmi: allow ycbcr420 modes for >= 0x200a

[Heiko Stuebner]

Am Freitag, 30. November 2018, 14:42:59 CET schrieb Neil Armstrong:
> Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
> for these modes in the connector if the platform supports them.
> We limit these modes to DW-HDMI IP version >= 0x200a which
> are designed to support HDMI2.0 display modes.
> 
> Signed-off-by: Neil Armstrong 

Please see comments in patch1 for details.

on rk3288 and rk3328
Tested-by: Heiko Stuebner 



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

Re: [PATCH RFC v2 1/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support

[Heiko Stuebner]

Am Freitag, 30. November 2018, 14:42:54 CET schrieb Neil Armstrong:
> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
> Scrambling when supported or mandatory.
> 
> This patch also adds an helper to setup the control bit to support
> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with
> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes.
> 
> These changes were based on work done by Huicong Xu 
> and Nickey Yang  to support HDMI2.0 modes
> on the Rockchip 4.4 BSP kernel at [1]
> 
> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4
> 
> Cc: Nickey Yang 
> Cc: Huicong Xu 
> Signed-off-by: Neil Armstrong 

sorry this took a bit longer, but I can confirm that the 4 relevant
patches (1, 4, 5, 6) at least still provide 1080p hdmi output on
rk3288 (with internal hdmiphy) and rk3328 (with external innosilicon
hdmiphy). I don't know how to test newly added features, but at
least the patches don't seem to break existing users, so

on rk3288 and rk3328
Tested-by: Heiko Stuebner 



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

Re: [PATCH v4 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC

[Rafael J. Wysocki]

On Fri, Dec 14, 2018 at 12:05 PM Mika Westerberg
 wrote:
>
> On Fri, Dec 14, 2018 at 11:48:35AM +0100, Hans de Goede wrote:
> > > > +#include 
> > >
> > > Why is this include needed?
> >
> > It is no longer needed in v4, since the parsing of the raw
> > MIPI sequence data (which needed this include) has been moved
> > to the i915 VBT code now.
> >
> > I've dropped this from my local version of the patch.
>
> OK.
>
> > Note sure if you (Mika) are the right person to ask, but in the
> > coverletter of v1 I suggested merging all 3 patches through the i915 tree
> > since the drivers/acpi/pmic/intel_pmic* files typically do
> > not see all that churn.  If I can get an Ack from you or
> > Rafael for that then I can push the version with the include
> > dropped to drm-next (through drm-intel-next-queued) myself
> > once the 3th patch also has been acked.
>
> I guess it is up to Rafael whether my ack is enough

Yes, it is. :-)

> but here it is for both patches,
>
> Acked-by: Mika Westerberg 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC

[Hans de Goede]

Hi,

On 14-12-18 10:49, Mika Westerberg wrote:

On Thu, Dec 13, 2018 at 04:35:32PM +0100, Hans de Goede wrote:

Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.

On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, because an external monitor was plugged in and
the GOP initialized only the external monitor.

Signed-off-by: Hans de Goede 


One question see below, but regardless

Reviewed-by: Mika Westerberg 


---
Changes in v4:
-The decoding of the raw data of the PMIC MIPI sequence element is now done
  in our caller, so drop this and adjust the callback prototype to accept
  the decoded addresses, value and mask

Changes in v3:
-Use hex values for out of range checks
-Make intel_cht_wc_exec_mipi_pmic_seq_element return errors

Changes in v2:
-Interpret data passed to the PMIC MIPI elements according to the docs
  instead of my own reverse engineered interpretation
---
  drivers/acpi/pmic/intel_pmic_chtwc.c | 20 
  1 file changed, 20 insertions(+)

diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c 
b/drivers/acpi/pmic/intel_pmic_chtwc.c
index 078b0448f30a..c5037c5c5219 100644
--- a/drivers/acpi/pmic/intel_pmic_chtwc.c
+++ b/drivers/acpi/pmic/intel_pmic_chtwc.c
@@ -12,6 +12,7 @@
  #include 
  #include 
  #include 
+#include 


Why is this include needed?


It is no longer needed in v4, since the parsing of the raw
MIPI sequence data (which needed this include) has been moved
to the i915 VBT code now.

I've dropped this from my local version of the patch.

Note sure if you (Mika) are the right person to ask, but in the
coverletter of v1 I suggested merging all 3 patches through the i915 tree
since the drivers/acpi/pmic/intel_pmic* files typically do
not see all that churn.  If I can get an Ack from you or
Rafael for that then I can push the version with the include
dropped to drm-next (through drm-intel-next-queued) myself
once the 3th patch also has been acked.

Regards,

Hans

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

Re: [PATCH] drm/gem: Mark pinned pages as unevictable

[Kuo-Hsin Yang]

On Fri, Dec 14, 2018 at 6:19 PM Chris Wilson  wrote:
>
> Ta, I did not know of that relationship. Perfect details for the
> changelog to explain how this does improve page reclaim even in the
> absence of a GEM shrinker. :)

OK, I will update the changelog.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] etnaviv-next for 4.21

[Lucas Stach]

Hi Dave,

nothing major this time, mostly some cleanups that were found on the
way of reworking the code in preparation for new feature additions.

Regards,
Lucas

The following changes since commit 6fce3a406108ee6c8a61e2a33e52e9198a626ea0:

  drm/etnaviv: fix bogus fence complete check in timeout handler (2018-11-05 
18:14:48 +0100)

are available in the Git repository at:

  https://git.pengutronix.de/git/lst/linux etnaviv/next

for you to fetch changes up to dea492e0cfcbe8ca592406fefc7ceeaf53f63380:

  drm/etnaviv: remove lastctx member from gpu struct (2018-12-11 12:35:07 +0100)


Lucas Stach (5):
  drm/etnaviv: kill active fence tracking
  drm/etnaviv: consolidate hardware fence handling in etnaviv_gpu
  drm/etnaviv: remove unnecessary local irq disable
  drm/etnaviv: replace header include with forward declaration
  drm/etnaviv: remove lastctx member from gpu struct

Thomas Zimmermann (1):
  drm/etnaviv: Replace drm_dev_unref with drm_dev_put

 drivers/gpu/drm/etnaviv/etnaviv_buffer.c |  2 --
 drivers/gpu/drm/etnaviv/etnaviv_drv.c| 16 +---
 drivers/gpu/drm/etnaviv/etnaviv_drv.h| 11 ---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 37 
-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 12 ++--
 5 files changed, 23 insertions(+), 55 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gem: Mark pinned pages as unevictable

[Chris Wilson]

Quoting Kuo-Hsin Yang (2018-12-14 10:09:11)
> On Fri, Dec 14, 2018 at 5:51 PM Chris Wilson  wrote:
> >
> > Quoting Kuo-Hsin Yang (2018-12-14 09:33:19)
> > > On Fri, Dec 14, 2018 at 4:59 PM Chris Wilson  
> > > wrote:
> > > >
> > > >
> > > > Do you have a driver in mind (msm?) to demonstrate the use case?
> > >
> > > On Samsung Chromebook Plus, the drm/rockchip driver may call
> > > rockchip_gem_get_pages()/drm_gem_get_pages() to pin a lot of pages,
> > > breaking the page reclaim mechanism and causing oom-killer invocation.
> >
> > Hmm, but this doesn't change the unavailability of the pages, just how
> > much work the shrinker must do scanning the evictable lists containing
> > GEM pages to no avail. So it won't prevent an oom by itself because
> > rockchip will still be holding the pages.
> >
> > Or?
> 
> When the size of a zone is 4GB, the inactive_ratio is 5. If all pages
> in the inactive_anon are pinned and active_anon / inactive_anon < 5,
> page reclaim would only scan inactive_anon due to inactive_ratio. It
> breaks page reclaim when the rockchip driver only pins about 1/6 of
> the anon lru pages. If the pinned pages are marked unevictable, the
> oom-killer would be invoked when anon lru is close to 0.

Ta, I did not know of that relationship. Perfect details for the
changelog to explain how this does improve page reclaim even in the
absence of a GEM shrinker. :)
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gem: Mark pinned pages as unevictable

[Kuo-Hsin Yang]

On Fri, Dec 14, 2018 at 5:51 PM Chris Wilson  wrote:
>
> Quoting Kuo-Hsin Yang (2018-12-14 09:33:19)
> > On Fri, Dec 14, 2018 at 4:59 PM Chris Wilson  
> > wrote:
> > >
> > >
> > > Do you have a driver in mind (msm?) to demonstrate the use case?
> >
> > On Samsung Chromebook Plus, the drm/rockchip driver may call
> > rockchip_gem_get_pages()/drm_gem_get_pages() to pin a lot of pages,
> > breaking the page reclaim mechanism and causing oom-killer invocation.
>
> Hmm, but this doesn't change the unavailability of the pages, just how
> much work the shrinker must do scanning the evictable lists containing
> GEM pages to no avail. So it won't prevent an oom by itself because
> rockchip will still be holding the pages.
>
> Or?

When the size of a zone is 4GB, the inactive_ratio is 5. If all pages
in the inactive_anon are pinned and active_anon / inactive_anon < 5,
page reclaim would only scan inactive_anon due to inactive_ratio. It
breaks page reclaim when the rockchip driver only pins about 1/6 of
the anon lru pages. If the pinned pages are marked unevictable, the
oom-killer would be invoked when anon lru is close to 0.

An example dmesg with oom-killer invocation shows there are still a
lot of anon lru pages:

[  516.170949] TaskSchedulerFo invoked oom-killer: gfp_mask=0x24200ca,
order=0, oom_score_adj=300
...
[  516.211085] Mem-Info:
[  516.26] DMA free:48816kB min:45056kB low:56320kB high:67584kB
active_anon:1453484kB inactive_anon:309284kB active_file:208808kB
inactive_file:177308kB unevictable:0kB isolated(anon):3200kB
isolated(file):0kB present:4059136kB managed:3904852kB mlocked:0kB
dirty:0kB writeback:0kB mapped:245000kB shmem:323300kB
slab_reclaimable:43540kB slab_unreclaimable:87896kB
kernel_stack:31520kB pagetables:59440kB unstable:0kB bounce:0kB
free_pcp:588kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB
pages_scanned:10977908 all_unreclaimable? yes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gem: Mark pinned pages as unevictable

[Chris Wilson]

Quoting Kuo-Hsin Yang (2018-12-14 09:33:19)
> On Fri, Dec 14, 2018 at 4:59 PM Chris Wilson  wrote:
> >
> >
> > Do you have a driver in mind (msm?) to demonstrate the use case?
> 
> On Samsung Chromebook Plus, the drm/rockchip driver may call
> rockchip_gem_get_pages()/drm_gem_get_pages() to pin a lot of pages,
> breaking the page reclaim mechanism and causing oom-killer invocation.

Hmm, but this doesn't change the unavailability of the pages, just how
much work the shrinker must do scanning the evictable lists containing
GEM pages to no avail. So it won't prevent an oom by itself because
rockchip will still be holding the pages.

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

Re: [PATCH v2 1/2] drm: Add color management LUT validation helper (v2)

[Alexandru-Cosmin Gheorghe]

Hi,

On Thu, Dec 13, 2018 at 01:55:25PM -0800, Matt Roper wrote:
> Some hardware may place additional restrictions on the gamma/degamma
> curves described by our LUT properties.  E.g., that a gamma curve never
> decreases or that the red/green/blue channels of a LUT's entries must be
> equal.  Let's add a helper function that drivers can use to test that a
> userspace-provided LUT is valid and doesn't violate hardware
> requirements.
> 
> v2:
>  - Combine into a single helper that just takes a bitmask of the tests
>to apply.  (Brian Starkey)
>  - Add additional check (always performed) that LUT property blob size
>is always a multiple of the LUT entry size.  (stolen from ARM driver)
> 
> Cc: Uma Shankar 
> Cc: Swati Sharma 
> Cc: Brian Starkey 
> Signed-off-by: Matt Roper 
> Reviewed-by(v1): Brian Starkey 
> ---
>  drivers/gpu/drm/drm_color_mgmt.c | 64 
> 
>  include/drm/drm_color_mgmt.h |  5 
>  2 files changed, 69 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 07dcf47daafe..5c2a2d228412 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -462,3 +462,67 @@ int drm_plane_create_color_properties(struct drm_plane 
> *plane,
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_plane_create_color_properties);
> +
> +/**
> + * drm_color_lut_check - check validity of lookup table
> + * @lut: property blob containing LUT to check
> + * @tests: bitmask of tests to run
> + *
> + * Helper to check whether a userspace-provided lookup table is valid and
> + * satisfies additional hardware requirements.  All table sizes should be a
> + * multiple of sizeof(struct drm_color_lut).  Drivers pass a bitmask 
> indicating
> + * which of the following additional tests should also be performed:
> + *
> + * "DRM_COLOR_LUT_EQUAL_CHANNELS":
> + * Checks whether the entries of a LUT all have equal values for the red,
> + * green, and blue channels.  Intended for hardware that only accepts a
> + * single value per LUT entry and assumes that value applies to all three
> + * color components.
> + *
> + * "DRM_COLOR_LUT_INCREASING":
> + * Checks whether the entries of a LUT are always flat or increasing
> + * (never decreasing).
> + *
> + * Returns 0 on success, -EINVAL on failure.
> + */
> +int drm_color_lut_check(struct drm_property_blob *lut,
> +  uint32_t tests)
> +{
> + struct drm_color_lut *entry;
> + int i;
> +
> + if (!lut)
> + return 0;
> +
> + if (lut->length % sizeof(struct drm_color_lut)) {
> + DRM_DEBUG_KMS("LUT size (%lu) is not a multiple of LUT entry 
> size (%lu)\n",
> +   lut->length, sizeof(struct drm_color_lut));
> + return -EINVAL;
> + }
> +

Isn't this already covered by drm_atomic_replace_property_blob_from_id ?
Other than that feel free to add:

Reviewed-by: Alexandru Gheorghe 

> + if (!tests)
> + return 0;
> +
> + entry = lut->data;
> + for (i = 0; i < drm_color_lut_size(lut); i++) {
> + if (tests & DRM_COLOR_LUT_EQUAL_CHANNELS) {
> + if (entry[i].red != entry[i].blue ||
> + entry[i].red != entry[i].green) {
> + DRM_DEBUG_KMS("All LUT entries must have equal 
> r/g/b\n");
> + return -EINVAL;
> + }
> + }
> +
> + if (i > 0 && tests & DRM_COLOR_LUT_INCREASING) {
> + if (entry[i].red < entry[i - 1].red ||
> + entry[i].green < entry[i - 1].green ||
> + entry[i].blue < entry[i - 1].blue) {
> + DRM_DEBUG_KMS("LUT entries must never 
> decrease.\n");
> + return -EINVAL;
> + }
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_color_lut_check);
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 90ef9996d9a4..7de16f70bcc3 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -69,4 +69,9 @@ int drm_plane_create_color_properties(struct drm_plane 
> *plane,
> u32 supported_ranges,
> enum drm_color_encoding default_encoding,
> enum drm_color_range default_range);
> +
> +#define DRM_COLOR_LUT_EQUAL_CHANNELS BIT(0)
> +#define DRM_COLOR_LUT_INCREASING BIT(1)
> +int drm_color_lut_check(struct drm_property_blob *lut,
> + uint32_t tests);
>  #endif
> -- 
> 2.14.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Cheers,
Alex G
___
dri-devel mailing list

Re: [WIP PATCH 04/15] drm/dp_mst: Stop releasing VCPI when removing ports from topology

[Daniel Vetter]

On Thu, Dec 13, 2018 at 08:25:33PM -0500, Lyude Paul wrote:
> This has never actually worked, and isn't needed anyway: the driver's
> always going to try to deallocate VCPI when it tears down the display
> that the VCPI belongs to.
> 
> Signed-off-by: Lyude Paul 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index c196fb580beb..ae9d019af9f2 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1084,8 +1084,6 @@ static void drm_dp_destroy_port(struct kref *kref)
>   struct drm_dp_mst_topology_mgr *mgr = port->mgr;
>  
>   if (!port->input) {
> - port->vcpi.num_slots = 0;
> -
>   kfree(port->cached_edid);
>  
>   /*
> @@ -3381,12 +3379,6 @@ static void drm_dp_destroy_connector_work(struct 
> work_struct *work)
>   drm_dp_port_teardown_pdt(port, port->pdt);
>   port->pdt = DP_PEER_DEVICE_NONE;
>  
> - if (!port->input && port->vcpi.vcpi > 0) {
> - drm_dp_mst_reset_vcpi_slots(mgr, port);
> - drm_dp_update_payload_part1(mgr);
> - drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
> - }
> -
>   drm_dp_mst_put_port_malloc(port);
>   send_hotplug = true;
>   }
> -- 
> 2.19.2
> 

-- 
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] drm/etnaviv: fix broken build

[Christian König]

Am 14.12.18 um 09:41 schrieb Daniel Vetter:

On Fri, Dec 14, 2018 at 08:41:34AM +0100, Christian König wrote:

Fix a broken build because of a typo in
"drm/scheduler: Add drm_sched_suspend/resume_timeout()".

Signed-off-by: Christian König 

Maybe core and cross-driver changes should go in through drm-misc or
similar, where we do a lot more compile testing across all drivers. At
least if you touch other drivers.


This was actually reported by kbuild on amd-staging-drm-next as well.

The problem was rather that I didn't reacted because I thought that this 
was a rebase/merge conflict and not a real problem.




Anyway Dave fixed this up already in his merge request, see

commit e7df065a697783ecb5c6eaa5692d78dcfceb71dd
Merge: e69aa5f9b97f 674e78acae0d
Author: Dave Airlie 
Date:   Thu Dec 13 09:49:04 2018 +1000

 Merge branch 'drm-next-4.21' of git://people.freedesktop.org/~agd5f/linux 
into drm-next
 
 [airlied: make etnaviv build again]


Ok, thanks. Good to know and sorry for the noise.

Christian.



Cheeers, Daniel


---
  drivers/gpu/drm/etnaviv/etnaviv_dump.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c 
b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
index fd6bad2100cf..a07c828c6a9a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
@@ -135,13 +135,13 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
mmu_size + gpu->buffer.size;
  
  	/* Add in the active command buffers */

-   spin_lock_irqsave(>job_list_lock, flags);
+   spin_lock_irqsave(>sched->job_list_lock, flags);
list_for_each_entry(s_job, >sched.ring_mirror_list, node) {
submit = to_etnaviv_submit(s_job);
file_size += submit->cmdbuf.size;
n_obj++;
}
-   spin_unlock_irqrestore(>job_list_lock, flags);
+   spin_unlock_irqrestore(>sched->job_list_lock, flags);
  
  	/* Add in the active buffer objects */

list_for_each_entry(vram, >mmu->mappings, mmu_node) {
@@ -183,14 +183,14 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
  gpu->buffer.size,
  etnaviv_cmdbuf_get_va(>buffer));
  
-	spin_lock_irqsave(>job_list_lock, flags);

+   spin_lock_irqsave(>sched->job_list_lock, flags);
list_for_each_entry(s_job, >sched.ring_mirror_list, node) {
submit = to_etnaviv_submit(s_job);
etnaviv_core_dump_mem(, ETDUMP_BUF_CMD,
  submit->cmdbuf.vaddr, submit->cmdbuf.size,
  etnaviv_cmdbuf_get_va(>cmdbuf));
}
-   spin_unlock_irqrestore(>job_list_lock, flags);
+   spin_unlock_irqrestore(>sched->job_list_lock, flags);
  
  	/* Reserve space for the bomap */

if (n_bomap_pages) {
--
2.17.1

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


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