Re: [PATCH 1/2] drm/panel: Add and fill drm_panel type field

2019-08-22 Thread Sam Ravnborg
Hi Laurent.

Thanks for looking into this, but you will not be happy in a minute...

On Fri, Aug 23, 2019 at 04:40:32AM +0300, Laurent Pinchart wrote:
> Add a type field to the drm_panel structure to report the panel type,
> using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
> eDP, DSI and DPI).

> This will be used to initialise the corresponding connector type.
Ohh, that explains what this should be used for.
I had missed that we have the panel when we create the drm_connector.

(I had seen we had to use the connector type to match a panel with a
connector or something like that).

> diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c 
> b/drivers/gpu/drm/panel/panel-arm-versatile.c
> index 5f72c922a04b..5c335fc1632b 100644
> --- a/drivers/gpu/drm/panel/panel-arm-versatile.c
> +++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
> @@ -353,6 +353,7 @@ static int versatile_panel_probe(struct platform_device 
> *pdev)
>   drm_panel_init(>panel);
>   vpanel->panel.dev = dev;
>   vpanel->panel.funcs = _panel_drm_funcs;
> + vpanel->panel.type = DRM_MODE_CONNECTOR_DPI;

The pattern where we call a simple init like here,
and then have a set of mandatory assignments right after
is not a good way to help the driver writer.

We should instead do:

drm_panel_init(>panel, dev, _panel_drm_funcs, 
DRM_MODE_CONNECTOR_DPI);

Then all drm_panel users are forced to supply the init parameters,
and we do not secretly rely on some defaults for panels that do not have it.
Also new panels will fail to build if they do not specify the new field.



This may also allow us to chatch that:

> diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c 
> b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> index b5b14aa059ea..cac074939e2c 100644
> --- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> +++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> @@ -428,6 +428,7 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
>  
>   ts->base.dev = dev;
>   ts->base.funcs = _touchscreen_funcs;
> + ts->base.type = DRM_MODE_CONNECTOR_DSI;

forgets to call drm_panel_init()


> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 28fa6ba7b767..6d5d0c51e97e 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -94,6 +94,7 @@ struct panel_desc {
>  
>   u32 bus_format;
>   u32 bus_flags;
> + unsigned int type;
>  };
>  
>  struct panel_simple {
> @@ -467,6 +468,7 @@ static int panel_simple_probe(struct device *dev, const 
> struct panel_desc *desc)
>   drm_panel_init(>base);
>   panel->base.dev = dev;
>   panel->base.funcs = _simple_funcs;
> + panel->base.type = desc->type ? desc->type : DRM_MODE_CONNECTOR_DPI;
>  
>   err = drm_panel_add(>base);
>   if (err < 0)
> @@ -833,6 +835,7 @@ static const struct panel_desc auo_g133han01 = {
>   .unprepare = 1000,
>   },
>   .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
> + .type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct display_timing auo_g185han01_timings = {
> @@ -862,6 +865,7 @@ static const struct panel_desc auo_g185han01 = {
>   .unprepare = 1000,
>   },
>   .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> + .type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct display_timing auo_p320hvn03_timings = {
> @@ -890,6 +894,7 @@ static const struct panel_desc auo_p320hvn03 = {
>   .unprepare = 500,
>   },
>   .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> + .type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct drm_display_mode auo_t215hvn01_mode = {
> @@ -1205,6 +1210,7 @@ static const struct panel_desc dlc_dlc0700yzg_1 = {
>   .disable = 200,
>   },
>   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct display_timing dlc_dlc1010gig_timing = {
> @@ -1235,6 +1241,7 @@ static const struct panel_desc dlc_dlc1010gig = {
>   .unprepare = 60,
>   },
>   .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> + .type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct drm_display_mode edt_et035012dm6_mode = {
> @@ -1501,6 +1508,7 @@ static const struct panel_desc hannstar_hsd070pww1 = {
>   .height = 94,
>   },
>   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct display_timing hannstar_hsd100pxn1_timing = {
> @@ -1525,6 +1533,7 @@ static const struct panel_desc hannstar_hsd100pxn1 = {
>   .height = 152,
>   },
>   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct drm_display_mode hitachi_tx23d38vm0caa_mode = {
> @@ -1631,6 +1640,7 @@ static const struct panel_desc 

[PATCH 2/2] drm/msm/dpu: remove unused arg

2019-08-22 Thread Rob Clark
From: Rob Clark 

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 +--
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 4e54550c4a80..a52439e029c9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -634,7 +634,7 @@ void dpu_crtc_commit_kickoff(struct drm_crtc *crtc, bool 
async)
 */
drm_for_each_encoder_mask(encoder, crtc->dev,
  crtc->state->encoder_mask)
-   dpu_encoder_prepare_for_kickoff(encoder, async);
+   dpu_encoder_prepare_for_kickoff(encoder);
 
if (!async) {
/* wait for previous frame_event_done completion */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index ed677cf2e1af..627c57594221 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1780,7 +1780,7 @@ static void dpu_encoder_vsync_event_work_handler(struct 
kthread_work *work)
nsecs_to_jiffies(ktime_to_ns(wakeup_time)));
 }
 
-void dpu_encoder_prepare_for_kickoff(struct drm_encoder *drm_enc, bool async)
+void dpu_encoder_prepare_for_kickoff(struct drm_encoder *drm_enc)
 {
struct dpu_encoder_virt *dpu_enc;
struct dpu_encoder_phys *phys;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index a8bf1147fc56..997d131c2440 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -68,9 +68,8 @@ void dpu_encoder_register_frame_event_callback(struct 
drm_encoder *encoder,
  * Immediately: if no previous commit is outstanding.
  * Delayed: Block until next trigger can be issued.
  * @encoder:   encoder pointer
- * @async: true if this is an asynchronous commit
  */
-void dpu_encoder_prepare_for_kickoff(struct drm_encoder *encoder,  bool async);
+void dpu_encoder_prepare_for_kickoff(struct drm_encoder *encoder);
 
 /**
  * dpu_encoder_trigger_kickoff_pending - Clear the flush bits from previous
-- 
2.21.0

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

[PATCH 1/2] drm/msm/dpu: remove some impossible error checking

2019-08-22 Thread Rob Clark
From: Rob Clark 

I'm sure there is plenty more to remove.. this is just some of the ones
I noticed.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   | 19 ---
 .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c  |  3 ---
 .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c  |  5 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c|  3 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  5 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c  | 10 --
 6 files changed, 45 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0e2f74163a16..ed677cf2e1af 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1428,12 +1428,6 @@ static void _dpu_encoder_trigger_flush(struct 
drm_encoder *drm_enc,
int pending_kickoff_cnt;
u32 ret = UINT_MAX;
 
-   if (!drm_enc || !phys) {
-   DPU_ERROR("invalid argument(s), drm_enc %d, phys_enc %d\n",
-   drm_enc != 0, phys != 0);
-   return;
-   }
-
if (!phys->hw_pp) {
DPU_ERROR("invalid pingpong hw\n");
return;
@@ -1566,11 +1560,6 @@ static void _dpu_encoder_kickoff_phys(struct 
dpu_encoder_virt *dpu_enc,
uint32_t i, pending_flush;
unsigned long lock_flags;
 
-   if (!dpu_enc) {
-   DPU_ERROR("invalid encoder\n");
-   return;
-   }
-
pending_flush = 0x0;
 
/* update pending counts and trigger kickoff ctl flush atomically */
@@ -1798,10 +1787,6 @@ void dpu_encoder_prepare_for_kickoff(struct drm_encoder 
*drm_enc, bool async)
bool needs_hw_reset = false;
unsigned int i;
 
-   if (!drm_enc) {
-   DPU_ERROR("invalid args\n");
-   return;
-   }
dpu_enc = to_dpu_encoder_virt(drm_enc);
 
trace_dpu_enc_prepare_kickoff(DRMID(drm_enc));
@@ -1837,10 +1822,6 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc, 
bool async)
ktime_t wakeup_time;
unsigned int i;
 
-   if (!drm_enc) {
-   DPU_ERROR("invalid encoder\n");
-   return;
-   }
DPU_ATRACE_BEGIN("encoder_kickoff");
dpu_enc = to_dpu_encoder_virt(drm_enc);
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 1b3ab909f367..2923b63d95fe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -720,9 +720,6 @@ static int dpu_encoder_phys_cmd_wait_for_vblank(
 static void dpu_encoder_phys_cmd_handle_post_kickoff(
struct dpu_encoder_phys *phys_enc)
 {
-   if (!phys_enc)
-   return;
-
/**
 * re-enable external TE, either for the first time after enabling
 * or if disabled for Autorefresh
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 5055a5eec869..737fe963a490 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -612,11 +612,6 @@ static void dpu_encoder_phys_vid_handle_post_kickoff(
 {
unsigned long lock_flags;
 
-   if (!phys_enc) {
-   DPU_ERROR("invalid encoder\n");
-   return;
-   }
-
/*
 * Video mode must flush CTL before enabling timing engine
 * Video encoders need to turn on their interfaces now
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index b2f7b0e886b5..179e8d52cadb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -102,9 +102,6 @@ static inline void dpu_hw_ctl_update_pending_flush(struct 
dpu_hw_ctl *ctx,
 
 static u32 dpu_hw_ctl_get_pending_flush(struct dpu_hw_ctl *ctx)
 {
-   if (!ctx)
-   return 0x0;
-
return ctx->pending_flush_mask;
 }
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 681955eb286f..b8d264bd15df 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -490,11 +490,6 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
int primary_planes_idx = 0, cursor_planes_idx = 0, i, ret;
int max_crtc_count;
 
-   if (!dpu_kms || !dpu_kms->dev || !dpu_kms->dev->dev) {
-   DPU_ERROR("invalid dpu_kms\n");
-   return -EINVAL;
-   }
-
dev = dpu_kms->dev;
priv = dev->dev_private;
catalog = dpu_kms->catalog;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
index 8bc3aea7cd86..f98a882318d1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
+++ 

[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega

2019-08-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104602

--- Comment #26 from gurchetansi...@chromium.org ---
An issue similar occurs when running Civ6 on Virgl.  Is there any to disable
TGSI indirect indexing for testing purposes?

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

linux-next: manual merge of the drm tree with the drm-fixes tree

2019-08-22 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/mediatek/mtk_drm_drv.c

between commit:

  4c6f3196e6ea ("drm/mediatek: use correct device to import PRIME buffers")

from the drm-fixes tree and commit:

  3baeeb21983a ("drm/mtk: Drop drm_gem_prime_export/import")

from the drm tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 7f5408cb2377,2ee809a6f3dc..
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@@ -351,21 -314,8 +345,20 @@@ static const struct file_operations mtk
.compat_ioctl = drm_compat_ioctl,
  };
  
 +/*
 + * We need to override this because the device used to import the memory is
 + * not dev->dev, as drm_gem_prime_import() expects.
 + */
 +struct drm_gem_object *mtk_drm_gem_prime_import(struct drm_device *dev,
 +  struct dma_buf *dma_buf)
 +{
 +  struct mtk_drm_private *private = dev->dev_private;
 +
 +  return drm_gem_prime_import_dev(dev, dma_buf, private->dma_dev);
 +}
 +
  static struct drm_driver mtk_drm_driver = {
-   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
-  DRIVER_ATOMIC,
+   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
  
.gem_free_object_unlocked = mtk_drm_gem_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
@@@ -373,8 -323,6 +366,7 @@@
  
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = drm_gem_prime_export,
 +  .gem_prime_import = mtk_drm_gem_prime_import,
.gem_prime_get_sg_table = mtk_gem_prime_get_sg_table,
.gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
.gem_prime_mmap = mtk_drm_gem_mmap_buf,


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

nouveau-next-5.4

2019-08-22 Thread Ben Skeggs
Hey Dave,

This is mostly just the stuff I missed last round.  Various cleanup
patches + fixes, improvements to display colour management, and some
code to avoid loading when power cables aren't properly attached.

There may be a second round next week with more changes, development
system died unexpectedly during the week and held finalising things up
somewhat.

Thanks,
Ben.


The following changes since commit ae4530062620561d24683b1bd3438b8397693429:

  Merge branch 'etnaviv/next' of
https://git.pengutronix.de/git/lst/linux into drm-next (2019-08-22
13:21:16 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.4

for you to fetch changes up to a1af2afbd244089560794c260b2d4326a86e39b6:

  drm/nouveau/volt: Fix for some cards having 0 maximum voltage
(2019-08-23 12:55:34 +1000)


Ben Skeggs (15):
  drm/nouveau/kms/gv100: allow windows to use PACKED8BPP formats
  drm/nouveau/kms/tu102-: disable input lut when input is already FP16
  drm/nouveau/kms/nv50-: disable input lut harder
  drm/nouveau/fifo/gf1xx: convert to using nvkm_fault_data
  drm/nouveau/fifo/gk104-: fix parsing of mmu fault data
  drm/nouveau/kms/gv100-: use premultiplied alpha blending between planes
  drm/nouveau/kms/gv100-: implement csc + enable modern colour
managment properties
  drm/nouveau/kms/nv50-: use __drm_atomic_helper_plane_reset()
  drm/nouveau/kms/nv50-: create primary plane before overlay planes
  drm/nouveau/kms/nv50-: attach immutable zpos property to planes
  drm/nouveau/kms/gv100-: add support for plane zpos property
  drm/nouveau/kms/gv100-: attach alpha property to planes
  drm/nouveau/kms/gv100-: attach pixel blend mode property to planes
  drm/nouveau/therm: skip probing for devices not specified in
thermal tables
  drm/nouveau/therm: don't attempt fan control where PMU is
already managing it

Colin Ian King (1):
  drm/nouveau/bios/init: fix spelling mistake "CONDITON" -> "CONDITION"

Gustavo A. R. Silva (1):
  drm/nouveau/mmu: use struct_size() helper

Hariprasad Kelam (2):
  drm/nouveau/dispnv04: subdev/bios.h is included more than once
  drm/nouveau: fix nvif/device.h is included more than once

Ilia Mirkin (4):
  drm/nouveau/kms/nv50-: add fp16 scanout support
  drm/nouveau/kms/nv50-: remove overlay alpha formats
  drm/nouveau/kms/gf119-: add ctm property support
  drm/nouveau/kms/nv50-: enable modern color management properties

Lyude Paul (2):
  drm/nouveau/dispnv04: Remove runtime PM
  drm/nouveau/dispnv50: Fix runtime PM ref tracking for
non-blocking modesets

Mark Menzynski (5):
  drm/nouveau/bios/gpio: sort gpios by values
  drm/nouveau/gpio: fail if gpu external power is missing
  drm/nouveau/gpio: check the gpio function 16 in the power check as well
  drm/nouveau/gpio: check function 76 in the power check as well
  drm/nouveau/volt: Fix for some cards having 0 maximum voltage

Rhys Kidd (3):
  drm/nouveau/bios: downgrade absence of tmds table to info from an error
  drm/nouveau/bios/init: handle INIT_RESET_BEGUN devinit opcode
  drm/nouveau/bios/init: handle INIT_RESET_END devinit opcode

Sam Ravnborg (4):
  drm/nouveau: drop use of DRM_UDELAY
  drm/nouveau: drop drmP.h from nouveau_drv.h
  drm/nouveau: drop drmP.h from all header files
  drm/nouveau: drop use of drmp.h

Ville Syrjälä (1):
  drm/nouveau: Disable atomic support on a per-device basis

YueHaibing (1):
  drm/nouveau/secboot: Make acr_r352_ls_gpccs_func static

 drivers/gpu/drm/nouveau/dispnv04/arb.c|   2 -
 drivers/gpu/drm/nouveau/dispnv04/crtc.c   |  54
++-
 drivers/gpu/drm/nouveau/dispnv04/cursor.c |   1 -
 drivers/gpu/drm/nouveau/dispnv04/dac.c|   1 -
 drivers/gpu/drm/nouveau/dispnv04/dfp.c|   2 +-
 drivers/gpu/drm/nouveau/dispnv04/disp.c   |   3 +-
 drivers/gpu/drm/nouveau/dispnv04/disp.h   |   1 -
 drivers/gpu/drm/nouveau/dispnv04/hw.c |   1 -
 drivers/gpu/drm/nouveau/dispnv04/hw.h |   1 -
 drivers/gpu/drm/nouveau/dispnv04/overlay.c|   1 -
 drivers/gpu/drm/nouveau/dispnv04/tvmodesnv17.c|   1 -
 drivers/gpu/drm/nouveau/dispnv04/tvnv04.c |   1 -
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c |   1 -
 drivers/gpu/drm/nouveau/dispnv50/atom.h   |  14 +
 drivers/gpu/drm/nouveau/dispnv50/base507c.c   |  26 +++--
 drivers/gpu/drm/nouveau/dispnv50/base827c.c   |  11 +++-
 drivers/gpu/drm/nouveau/dispnv50/base907c.c   |  65
++
 drivers/gpu/drm/nouveau/dispnv50/base917c.c   |   2 +
 drivers/gpu/drm/nouveau/dispnv50/corec37d.c   |   2 +-
 

nouveau-fixes-5.3

2019-08-22 Thread Ben Skeggs
The following changes since commit 4d352dbd5850bfc752609d46b5c8403ae0bd5163:

  drm/nouveau/secboot/gp102-: remove WAR for SEC2 RTOS start bug
(2019-07-19 16:26:51 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.3

for you to fetch changes up to c358ebf59634f06d8ed176da651ec150df3c8686:

  drm/nouveau: Don't retry infinitely when receiving no data on i2c
over AUX (2019-08-23 12:42:43 +1000)


Lyude Paul (1):
  drm/nouveau: Don't retry infinitely when receiving no data on i2c over AUX

 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/8] drm/panfrost: Hold runtime PM reference until jobs complete

2019-08-22 Thread Rob Herring
Doing a pm_runtime_put as soon as a job is submitted is wrong as it should
not happen until the job completes. It works because we are relying on the
autosuspend timeout to keep the h/w enabled.

Cc: Tomeu Vizoso 
Cc: Steven Price 
Cc: Alyssa Rosenzweig 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Rob Herring 
---
v2: new patch

 drivers/gpu/drm/panfrost/panfrost_job.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 05c85f45a0de..80c9cab9a01b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -151,7 +151,7 @@ static void panfrost_job_hw_submit(struct panfrost_job 
*job, int js)
return;
 
if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js
-   goto end;
+   return;
 
cfg = panfrost_mmu_as_get(pfdev, >file_priv->mmu);
 
@@ -187,10 +187,6 @@ static void panfrost_job_hw_submit(struct panfrost_job 
*job, int js)
job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START);
 
spin_unlock_irqrestore(>hwaccess_lock, flags);
-
-end:
-   pm_runtime_mark_last_busy(pfdev->dev);
-   pm_runtime_put_autosuspend(pfdev->dev);
 }
 
 static void panfrost_acquire_object_fences(struct drm_gem_object **bos,
@@ -388,9 +384,13 @@ static void panfrost_job_timedout(struct drm_sched_job 
*sched_job)
 
mutex_lock(>reset_lock);
 
-   for (i = 0; i < NUM_JOB_SLOTS; i++)
+   for (i = 0; i < NUM_JOB_SLOTS; i++) {
drm_sched_stop(>js->queue[i].sched, sched_job);
-
+   if (pfdev->jobs[i]) {
+   pm_runtime_put_noidle(pfdev->dev);
+   pfdev->jobs[i] = NULL;
+   }
+   }
if (sched_job)
drm_sched_increase_karma(sched_job);
 
@@ -455,7 +455,9 @@ static irqreturn_t panfrost_job_irq_handler(int irq, void 
*data)
pfdev->jobs[j] = NULL;
panfrost_mmu_as_put(pfdev, >file_priv->mmu);
panfrost_devfreq_record_transition(pfdev, j);
+
dma_fence_signal(job->done_fence);
+   pm_runtime_put_autosuspend(pfdev->dev);
}
 
status &= ~mask;
-- 
2.20.1

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

[PATCH v2 2/8] drm/panfrost: Rework runtime PM initialization

2019-08-22 Thread Rob Herring
There's a few issues with the runtime PM initialization.

The documentation states pm_runtime_set_active() should be called before
pm_runtime_enable(). The pm_runtime_put_autosuspend() could suspend the GPU
before panfrost_perfcnt_init() is called which touches the h/w. The
autosuspend delay keeps things from breaking. There's no need explicitly
power off the GPU only to wake back up with pm_runtime_get_sync(). Just
delaying pm_runtime_enable to the end of probe is sufficient.

Lets move all the runtime PM calls into the probe() function so they are
all in one place and are done after all initialization.

Cc: Tomeu Vizoso 
Cc: Steven Price 
Cc: Alyssa Rosenzweig 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Rob Herring 
---
v2: new patch

 drivers/gpu/drm/panfrost/panfrost_device.c |  9 -
 drivers/gpu/drm/panfrost/panfrost_drv.c| 10 ++
 2 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 4da71bb56c20..73805210834e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -5,7 +5,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "panfrost_device.h"
@@ -166,14 +165,6 @@ int panfrost_device_init(struct panfrost_device *pfdev)
if (err)
goto err_out4;
 
-   /* runtime PM will wake us up later */
-   panfrost_gpu_power_off(pfdev);
-
-   pm_runtime_set_active(pfdev->dev);
-   pm_runtime_get_sync(pfdev->dev);
-   pm_runtime_mark_last_busy(pfdev->dev);
-   pm_runtime_put_autosuspend(pfdev->dev);
-
err = panfrost_perfcnt_init(pfdev);
if (err)
goto err_out5;
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index d74442d71048..f27e3d6aec12 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -523,10 +523,6 @@ static int panfrost_probe(struct platform_device *pdev)
mutex_init(>shrinker_lock);
INIT_LIST_HEAD(>shrinker_list);
 
-   pm_runtime_use_autosuspend(pfdev->dev);
-   pm_runtime_set_autosuspend_delay(pfdev->dev, 50); /* ~3 frames */
-   pm_runtime_enable(pfdev->dev);
-
err = panfrost_device_init(pfdev);
if (err) {
if (err != -EPROBE_DEFER)
@@ -541,6 +537,12 @@ static int panfrost_probe(struct platform_device *pdev)
goto err_out1;
}
 
+   pm_runtime_set_active(pfdev->dev);
+   pm_runtime_use_autosuspend(pfdev->dev);
+   pm_runtime_set_autosuspend_delay(pfdev->dev, 0); /* ~3 frames */
+   pm_runtime_mark_last_busy(pfdev->dev);
+   pm_runtime_enable(pfdev->dev);
+
/*
 * Register the DRM device with the core and the connectors with
 * sysfs
-- 
2.20.1

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

[PATCH v2 7/8] drm/panfrost: Rework page table flushing and runtime PM interaction

2019-08-22 Thread Rob Herring
There is no point in resuming the h/w just to do flush operations and
doing so takes several locks which cause lockdep issues with the shrinker.
Rework the flush operations to only happen when the h/w is already awake.
This avoids taking any locks associated with resuming.

Cc: Tomeu Vizoso 
Cc: Steven Price 
Cc: Alyssa Rosenzweig 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Rob Herring 
---
v2: new patch

 drivers/gpu/drm/panfrost/panfrost_mmu.c | 41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c 
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 842bdd7cf6be..ccf671a9c3fb 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -220,6 +220,23 @@ static size_t get_pgsize(u64 addr, size_t size)
return SZ_2M;
 }
 
+void panfrost_mmu_flush_range(struct panfrost_device *pfdev,
+ struct panfrost_mmu *mmu,
+ u64 iova, size_t size)
+{
+   if (mmu->as < 0)
+   return;
+
+   /* Flush the PTs only if we're already awake */
+   if (!pm_runtime_get_if_in_use(pfdev->dev))
+   return;
+
+   mmu_hw_do_operation(pfdev, mmu, iova, size, AS_COMMAND_FLUSH_PT);
+
+   pm_runtime_mark_last_busy(pfdev->dev);
+   pm_runtime_put_autosuspend(pfdev->dev);
+}
+
 static int mmu_map_sg(struct panfrost_device *pfdev, struct panfrost_mmu *mmu,
  u64 iova, int prot, struct sg_table *sgt)
 {
@@ -246,11 +263,10 @@ static int mmu_map_sg(struct panfrost_device *pfdev, 
struct panfrost_mmu *mmu,
}
}
 
-   mmu_hw_do_operation(pfdev, mmu, start_iova, iova - start_iova,
-   AS_COMMAND_FLUSH_PT);
-
mutex_unlock(>lock);
 
+   panfrost_mmu_flush_range(pfdev, mmu, start_iova, iova - start_iova);
+
return 0;
 }
 
@@ -259,7 +275,6 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
struct drm_gem_object *obj = >base.base;
struct panfrost_device *pfdev = to_panfrost_device(obj->dev);
struct sg_table *sgt;
-   int ret;
int prot = IOMMU_READ | IOMMU_WRITE;
 
if (WARN_ON(bo->is_mapped))
@@ -272,14 +287,7 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
if (WARN_ON(IS_ERR(sgt)))
return PTR_ERR(sgt);
 
-   ret = pm_runtime_get_sync(pfdev->dev);
-   if (ret < 0)
-   return ret;
-
mmu_map_sg(pfdev, bo->mmu, bo->node.start << PAGE_SHIFT, prot, sgt);
-
-   pm_runtime_mark_last_busy(pfdev->dev);
-   pm_runtime_put_autosuspend(pfdev->dev);
bo->is_mapped = true;
 
return 0;
@@ -293,17 +301,12 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
u64 iova = bo->node.start << PAGE_SHIFT;
size_t len = bo->node.size << PAGE_SHIFT;
size_t unmapped_len = 0;
-   int ret;
 
if (WARN_ON(!bo->is_mapped))
return;
 
dev_dbg(pfdev->dev, "unmap: as=%d, iova=%llx, len=%zx", bo->mmu->as, 
iova, len);
 
-   ret = pm_runtime_get_sync(pfdev->dev);
-   if (ret < 0)
-   return;
-
mutex_lock(>mmu->lock);
 
while (unmapped_len < len) {
@@ -318,13 +321,9 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
unmapped_len += pgsize;
}
 
-   mmu_hw_do_operation(pfdev, bo->mmu, bo->node.start << PAGE_SHIFT,
-   bo->node.size << PAGE_SHIFT, AS_COMMAND_FLUSH_PT);
-
mutex_unlock(>mmu->lock);
 
-   pm_runtime_mark_last_busy(pfdev->dev);
-   pm_runtime_put_autosuspend(pfdev->dev);
+   panfrost_mmu_flush_range(pfdev, bo->mmu, bo->node.start << PAGE_SHIFT, 
len);
bo->is_mapped = false;
 }
 
-- 
2.20.1

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

[PATCH v2 6/8] drm/panfrost: Use mutex_trylock in panfrost_gem_purge

2019-08-22 Thread Rob Herring
Lockdep reports a circular locking dependency with pages_lock taken in
the shrinker callback. The deadlock can't actually happen with current
users at least as a BO will never be purgeable when pages_lock is held.
To be safe, let's use mutex_trylock() instead and bail if a BO is locked
already.

Cc: Tomeu Vizoso 
Cc: Steven Price 
Cc: Alyssa Rosenzweig 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Rob Herring 
---
v2: new patch

 drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c 
b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
index d191632b6197..458f0fa68111 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
@@ -36,15 +36,18 @@ panfrost_gem_shrinker_count(struct shrinker *shrinker, 
struct shrink_control *sc
return count;
 }
 
-static void panfrost_gem_purge(struct drm_gem_object *obj)
+static bool panfrost_gem_purge(struct drm_gem_object *obj)
 {
struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
-   mutex_lock(>pages_lock);
+
+   if (!mutex_trylock(>pages_lock))
+   return false;
 
panfrost_mmu_unmap(to_panfrost_bo(obj));
drm_gem_shmem_purge_locked(obj);
 
mutex_unlock(>pages_lock);
+   return true;
 }
 
 static unsigned long
@@ -61,8 +64,8 @@ panfrost_gem_shrinker_scan(struct shrinker *shrinker, struct 
shrink_control *sc)
list_for_each_entry_safe(shmem, tmp, >shrinker_list, madv_list) {
if (freed >= sc->nr_to_scan)
break;
-   if (drm_gem_shmem_is_purgeable(shmem)) {
-   panfrost_gem_purge(>base);
+   if (drm_gem_shmem_is_purgeable(shmem) &&
+   panfrost_gem_purge(>base)) {
freed += shmem->base.size >> PAGE_SHIFT;
list_del_init(>madv_list);
}
-- 
2.20.1

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

[PATCH v2 4/8] drm/shmem: Do dma_unmap_sg before purging pages

2019-08-22 Thread Rob Herring
Calling dma_unmap_sg() in drm_gem_shmem_free_object() is too late if the
backing pages have already been released by the shrinker. The result is
the following abort:

Unable to handle kernel paging request at virtual address 898ed000
Mem abort info:
  ESR = 0x96000147
  Exception class = DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
Data abort info:
  ISV = 0, ISS = 0x0147
  CM = 1, WnR = 1
swapper pgtable: 4k pages, 48-bit VAs, pgdp=02f51000
[898ed000] pgd=401f8003, pud=401f7003, 
pmd=401b1003, pte=00e8098ed712
Internal error: Oops: 96000147 [#1] SMP
Modules linked in: panfrost gpu_sched
CPU: 5 PID: 902 Comm: gnome-shell Not tainted 5.3.0-rc1+ #95
Hardware name: 96boards Rock960 (DT)
pstate: 4005 (nZcv daif -PAN -UAO)
pc : __dma_inv_area+0x40/0x58
lr : arch_sync_dma_for_cpu+0x28/0x30
sp : 1321ba30
x29: 1321ba30 x28: 1321bd08
x27:  x26: 0009
x25: c1f86170 x24: 
x23:  x22: 
x21: 00021000 x20: 80003bb2d810
x19: 098ed000 x18: 
x17:  x16: 800023fd9480
x15:  x14: 
x13:  x12: 
x11: fffb9fff x10: 
x9 :  x8 : 800023fd9c18
x7 :  x6 : 
x5 :  x4 : 00021000
Purging 5693440 bytes
x3 : 003f x2 : 0040
x1 : 8990e000 x0 : 898ed000
Call trace:
 __dma_inv_area+0x40/0x58
 dma_direct_sync_single_for_cpu+0x7c/0x80
 dma_direct_unmap_page+0x80/0x88
 dma_direct_unmap_sg+0x54/0x80
 drm_gem_shmem_free_object+0xfc/0x108
 panfrost_gem_free_object+0x118/0x128 [panfrost]
 drm_gem_object_free+0x18/0x90
 drm_gem_object_put_unlocked+0x58/0x80
 drm_gem_object_handle_put_unlocked+0x64/0xb0
 drm_gem_object_release_handle+0x70/0x98
 drm_gem_handle_delete+0x64/0xb0
 drm_gem_close_ioctl+0x28/0x38
 drm_ioctl_kernel+0xb8/0x110
 drm_ioctl+0x244/0x3f0
 do_vfs_ioctl+0xbc/0x910
 ksys_ioctl+0x78/0xa8
 __arm64_sys_ioctl+0x1c/0x28
 el0_svc_common.constprop.0+0x88/0x150
 el0_svc_handler+0x28/0x78
 el0_svc+0x8/0xc
 Code: 8a23 5460 d50b7e20 1402 (d5087620)

Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers")
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Reviewed-by: Steven Price 
Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index df8f2c8adb2b..5423ec56b535 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -390,6 +390,12 @@ void drm_gem_shmem_purge_locked(struct drm_gem_object *obj)
 
WARN_ON(!drm_gem_shmem_is_purgeable(shmem));
 
+   dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
+shmem->sgt->nents, DMA_BIDIRECTIONAL);
+   sg_free_table(shmem->sgt);
+   kfree(shmem->sgt);
+   shmem->sgt = NULL;
+
drm_gem_shmem_put_pages_locked(shmem);
 
shmem->madv = -1;
-- 
2.20.1

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

[PATCH v2 8/8] drm/panfrost: Remove unnecessary flushing from tlb_inv_context

2019-08-22 Thread Rob Herring
tlb_inv_context() hook is only called when freeing the page tables. There's
no point in flushing only to free the page tables immediately following.
There is also a problem that we could be accessing the h/w when suspended.

Cc: Tomeu Vizoso 
Cc: Steven Price 
Cc: Alyssa Rosenzweig 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Rob Herring 
---
v2: new patch

 drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c 
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index ccf671a9c3fb..9f85275a896c 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -328,11 +328,7 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
 }
 
 static void mmu_tlb_inv_context_s1(void *cookie)
-{
-   struct panfrost_file_priv *priv = cookie;
-
-   mmu_hw_do_operation(priv->pfdev, >mmu, 0, ~0UL, 
AS_COMMAND_FLUSH_MEM);
-}
+{}
 
 static void mmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
 size_t granule, bool leaf, void *cookie)
-- 
2.20.1

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

[PATCH v2 5/8] drm/shmem: Use mutex_trylock in drm_gem_shmem_purge

2019-08-22 Thread Rob Herring
Lockdep reports a circular locking dependency with pages_lock taken in
the shrinker callback. The deadlock can't actually happen with current
users at least as a BO will never be purgeable when pages_lock is held.
To be safe, let's use mutex_trylock() instead and bail if a BO is locked
already.

WARNING: possible circular locking dependency detected
5.3.0-rc1+ #100 Tainted: G L
--
kswapd0/171 is trying to acquire lock:
9b9823fd (>pages_lock){+.+.}, at: drm_gem_shmem_purge+0x20/0x40

but task is already holding lock:
f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (fs_reclaim){+.+.}:
   fs_reclaim_acquire.part.18+0x34/0x40
   fs_reclaim_acquire+0x20/0x28
   __kmalloc_node+0x6c/0x4c0
   kvmalloc_node+0x38/0xa8
   drm_gem_get_pages+0x80/0x1d0
   drm_gem_shmem_get_pages+0x58/0xa0
   drm_gem_shmem_get_pages_sgt+0x48/0xd0
   panfrost_mmu_map+0x38/0xf8 [panfrost]
   panfrost_gem_open+0xc0/0xe8 [panfrost]
   drm_gem_handle_create_tail+0xe8/0x198
   drm_gem_handle_create+0x3c/0x50
   panfrost_gem_create_with_handle+0x70/0xa0 [panfrost]
   panfrost_ioctl_create_bo+0x48/0x80 [panfrost]
   drm_ioctl_kernel+0xb8/0x110
   drm_ioctl+0x244/0x3f0
   do_vfs_ioctl+0xbc/0x910
   ksys_ioctl+0x78/0xa8
   __arm64_sys_ioctl+0x1c/0x28
   el0_svc_common.constprop.0+0x90/0x168
   el0_svc_handler+0x28/0x78
   el0_svc+0x8/0xc

-> #0 (>pages_lock){+.+.}:
   __lock_acquire+0xa2c/0x1d70
   lock_acquire+0xdc/0x228
   __mutex_lock+0x8c/0x800
   mutex_lock_nested+0x1c/0x28
   drm_gem_shmem_purge+0x20/0x40
   panfrost_gem_shrinker_scan+0xc0/0x180 [panfrost]
   do_shrink_slab+0x208/0x500
   shrink_slab+0x10c/0x2c0
   shrink_node+0x28c/0x4d8
   balance_pgdat+0x2c8/0x570
   kswapd+0x22c/0x638
   kthread+0x128/0x130
   ret_from_fork+0x10/0x18

other info that might help us debug this:

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(fs_reclaim);
   lock(>pages_lock);
   lock(fs_reclaim);
  lock(>pages_lock);

 *** DEADLOCK ***

3 locks held by kswapd0/171:
 #0: f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40
 #1: ceb37808 (shrinker_rwsem){}, at: shrink_slab+0xbc/0x2c0
 #2: f31efa81 (>shrinker_lock){+.+.}, at: 
panfrost_gem_shrinker_scan+0x34/0x180 [panfrost]

Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers")
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 7 +--
 include/drm/drm_gem_shmem_helper.h | 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 5423ec56b535..f5918707672f 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -415,13 +415,16 @@ void drm_gem_shmem_purge_locked(struct drm_gem_object 
*obj)
 }
 EXPORT_SYMBOL(drm_gem_shmem_purge_locked);
 
-void drm_gem_shmem_purge(struct drm_gem_object *obj)
+bool drm_gem_shmem_purge(struct drm_gem_object *obj)
 {
struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
 
-   mutex_lock(>pages_lock);
+   if (!mutex_trylock(>pages_lock))
+   return false;
drm_gem_shmem_purge_locked(obj);
mutex_unlock(>pages_lock);
+
+   return true;
 }
 EXPORT_SYMBOL(drm_gem_shmem_purge);
 
diff --git a/include/drm/drm_gem_shmem_helper.h 
b/include/drm/drm_gem_shmem_helper.h
index ce1600fdfc3e..01f514521687 100644
--- a/include/drm/drm_gem_shmem_helper.h
+++ b/include/drm/drm_gem_shmem_helper.h
@@ -134,7 +134,7 @@ static inline bool drm_gem_shmem_is_purgeable(struct 
drm_gem_shmem_object *shmem
 }
 
 void drm_gem_shmem_purge_locked(struct drm_gem_object *obj);
-void drm_gem_shmem_purge(struct drm_gem_object *obj);
+bool drm_gem_shmem_purge(struct drm_gem_object *obj);
 
 struct drm_gem_shmem_object *
 drm_gem_shmem_create_with_handle(struct drm_file *file_priv,
-- 
2.20.1

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

[PATCH v2 1/8] drm/panfrost: Fix possible suspend in panfrost_remove

2019-08-22 Thread Rob Herring
Calls to panfrost_device_fini() access the h/w, but we already done a
pm_runtime_put_sync_autosuspend() beforehand. This only works if the
autosuspend delay is long enough. A 0ms delay will hang the system when
removing the device. Fix this by moving the pm_runtime_put_sync_suspend()
after the panfrost_device_fini() call.

Cc: Tomeu Vizoso 
Cc: Steven Price 
Cc: Alyssa Rosenzweig 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Rob Herring 
---
v2: new patch

 drivers/gpu/drm/panfrost/panfrost_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 44a558c6e17e..d74442d71048 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -570,11 +570,13 @@ static int panfrost_remove(struct platform_device *pdev)
 
drm_dev_unregister(ddev);
panfrost_gem_shrinker_cleanup(ddev);
+
pm_runtime_get_sync(pfdev->dev);
-   pm_runtime_put_sync_autosuspend(pfdev->dev);
-   pm_runtime_disable(pfdev->dev);
panfrost_devfreq_fini(pfdev);
panfrost_device_fini(pfdev);
+   pm_runtime_put_sync_suspend(pfdev->dev);
+   pm_runtime_disable(pfdev->dev);
+
drm_dev_put(ddev);
return 0;
 }
-- 
2.20.1

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

[no subject]

2019-08-22 Thread Rob Herring
Subject: [PATCH v2 0/8] panfrost: Locking and runtime PM fixes

With further testing of recent changes with lockdep and other locking
checks enabled, we've found several bugs in the shrinker code and one
sleep while atomic in panfrost_gem_open(). This series addresses those
issues.

Delaying the unmapping of pages turns out to be a bad idea. Instead we 
need to rework panfrost_mmu_unmap() to not do a runtime PM resume which 
takes several locks and causes more lockdep warnings. Unfortunately, 
there initially appeared to be some mismatches between the runtime PM 
state and the h/w. The result is several fixes to the runtime PM 
initialization and handling in jobs. With this, the changes to 
panfrost_mmu_unmap() are working correctly.

v2:
 - Drop already applied 'drm/panfrost: Fix sleeping while atomic in 
   panfrost_gem_open'
 - Runtime PM clean-ups
 - Keep panfrost_gem_purge and use mutex_trylock there
 - Rework panfrost_mmu_unmap runtime PM

Rob

Rob Herring (8):
  drm/panfrost: Fix possible suspend in panfrost_remove
  drm/panfrost: Rework runtime PM initialization
  drm/panfrost: Hold runtime PM reference until jobs complete
  drm/shmem: Do dma_unmap_sg before purging pages
  drm/shmem: Use mutex_trylock in drm_gem_shmem_purge
  drm/panfrost: Use mutex_trylock in panfrost_gem_purge
  drm/panfrost: Rework page table flushing and runtime PM interaction
  drm/panfrost: Remove unnecessary flushing from tlb_inv_context

 drivers/gpu/drm/drm_gem_shmem_helper.c| 13 -
 drivers/gpu/drm/panfrost/panfrost_device.c|  9 
 drivers/gpu/drm/panfrost/panfrost_drv.c   | 16 ---
 .../gpu/drm/panfrost/panfrost_gem_shrinker.c  | 11 +++--
 drivers/gpu/drm/panfrost/panfrost_job.c   | 16 ---
 drivers/gpu/drm/panfrost/panfrost_mmu.c   | 47 +--
 include/drm/drm_gem_shmem_helper.h|  2 +-
 7 files changed, 59 insertions(+), 55 deletions(-)

-- 
2.20.1

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

[git pull] drm fixes for 5.3-rc6

2019-08-22 Thread Dave Airlie
Hi Linus,
Hi Linus,

Live from the laundromat after my washing machine broke down, we have
the 5.3-rc6 fixes.  Changelog is in the tag below, but nothing too
noteworthy in here.

Dave.

drm-fixes-2019-08-23:
drm fixes for 5.3-rc6

rcar-du:
- LVDS dual-link mode fix

mediatek:
- of node refcount fix
- prime buffer import fix
- dma max seg fix

komeda:
- output polling fix
- abfc format fix
- memory-region DT fix

amdgpu:
- bpc display fix
- ioctl memory leak fix
- gfxoff fix
- smu warnings fix

i915:
- HDMI mode readout fix
The following changes since commit d1abaeb3be7b5fa6d7a1fbbd2e14e3310005c4c1:

  Linux 5.3-rc5 (2019-08-18 14:31:08 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-08-23

for you to fetch changes up to 75710f08ea7e41b2f7010da3f6deab061f7a853b:

  drm/amdgpu/powerplay: silence a warning in smu_v11_0_setup_pptable
(2019-08-23 11:46:32 +1000)


drm fixes for 5.3-rc6

rcar-du:
- LVDS dual-link mode fix

mediatek:
- of node refcount fix
- prime buffer import fix
- dma max seg fix

komeda:
- output polling fix
- abfc format fix
- memory-region DT fix

amdgpu:
- bpc display fix
- ioctl memory leak fix
- gfxoff fix
- smu warnings fix

i915:
- HDMI mode readout fix


Alex Deucher (2):
  drm/amdgpu/gfx9: update pg_flags after determining if gfx off is possible
  drm/amdgpu/powerplay: silence a warning in smu_v11_0_setup_pptable

Alexandre Courbot (2):
  drm/mediatek: use correct device to import PRIME buffers
  drm/mediatek: set DMA max segment size

Dave Airlie (5):
  Merge tag 'du-fixes-20190816' of
git://linuxtv.org/pinchartl/media into drm-fixes
  Merge tag 'mediatek-drm-fixes-5.3' of
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes
  Merge tag 'drm-fixes-5.3-2019-08-21' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2019-08-22' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'drm-misc-fixes-2019-08-22' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

Imre Deak (1):
  drm/i915: Fix HW readout for crtc_clock in HDMI mode

Jacopo Mondi (1):
  drm: rcar_lvds: Fix dual link mode operations

Kenneth Feng (1):
  drm/amd/amdgpu: disable MMHUB PG for navi10

Kevin Wang (2):
  drm/amd/powerplay: fix variable type errors in smu_v11_0_setup_pptable
  drm/amd/powerplay: remove duplicate macro
smu_get_uclk_dpm_states in amdgpu_smu.h

Lowry Li (Arm Technology China) (2):
  drm/komeda: Initialize and enable output polling on Komeda
  drm/komeda: Adds internal bpp computing for arm afbc only format YU08 YU10

Maarten Lankhorst (1):
  Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes

Mihail Atanassov (1):
  drm/komeda: Add support for 'memory-region' DT node property

Nicholas Kazlauskas (1):
  drm/amd/display: Calculate bpc based on max_requested_bpc

Nicolai Hähnle (1):
  drm/amdgpu: prevent memory leaks in AMDGPU_CS ioctl

Nishka Dasgupta (1):
  drm/mediatek: mtk_drm_drv.c: Add of_node_put() before goto

Tomi Valkeinen (1):
  drm/omap: ensure we have a valid dma_mask

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  9 +++-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  4 ++
 drivers/gpu/drm/amd/amdgpu/nv.c|  1 -
 drivers/gpu/drm/amd/amdgpu/soc15.c |  5 --
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 16 ++-
 drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h |  2 -
 drivers/gpu/drm/amd/powerplay/smu_v11_0.c  |  6 ++-
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c|  9 
 .../drm/arm/display/komeda/komeda_format_caps.c| 19 
 .../drm/arm/display/komeda/komeda_format_caps.h|  3 ++
 .../drm/arm/display/komeda/komeda_framebuffer.c|  5 +-
 drivers/gpu/drm/arm/display/komeda/komeda_kms.c|  5 ++
 drivers/gpu/drm/i915/display/intel_ddi.c   |  4 +-
 drivers/gpu/drm/i915/intel_drv.h   |  2 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 54 --
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |  2 +
 drivers/gpu/drm/omapdrm/omap_drv.c |  2 +-
 drivers/gpu/drm/rcar-du/rcar_lvds.c|  6 +--
 18 files changed, 126 insertions(+), 28 deletions(-)


Re: [PATCH] drm/panfrost: Add missing check for pfdev->regulator

2019-08-22 Thread Rob Herring
On Thu, Aug 22, 2019 at 4:32 AM Steven Price  wrote:
>
> When modifying panfrost_devfreq_target() to support a device without a
> regulator defined I missed the check on the error path. Let's add it.
>
> Reported-by: Dan Carpenter 
> Fixes: e21dd290881b ("drm/panfrost: Enable devfreq to work without regulator")
> Signed-off-by: Steven Price 
> ---
>  drivers/gpu/drm/panfrost/panfrost_devfreq.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Looks fine to me, but seems to be delayed getting to the list and
patchwork. I'm guessing you're not subscribed to dri-devel because all
your patches seem to get delayed.

Rob

>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 710d903f8e0d..a1f5fa6a742a 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -53,8 +53,10 @@ static int panfrost_devfreq_target(struct device *dev, 
> unsigned long *freq,
> if (err) {
> dev_err(dev, "Cannot set frequency %lu (%d)\n", target_rate,
> err);
> -   regulator_set_voltage(pfdev->regulator, 
> pfdev->devfreq.cur_volt,
> - pfdev->devfreq.cur_volt);
> +   if (pfdev->regulator)
> +   regulator_set_voltage(pfdev->regulator,
> + pfdev->devfreq.cur_volt,
> + pfdev->devfreq.cur_volt);
> return err;
> }
>
> --
> 2.20.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm-intel-next

2019-08-22 Thread Dave Airlie
On Fri, 23 Aug 2019 at 05:29, Rodrigo Vivi  wrote:
>
> Hi Dave and Daniel,
>
> Here goes the final pull request targeting 5.4.

For some reason patchwork hasn't picked this up. or if it has I can't
see it. Not sure whether it was the earlier patch code in it or
something else malformed.

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

[PATCH 1/2] drm/panel: Add and fill drm_panel type field

2019-08-22 Thread Laurent Pinchart
Add a type field to the drm_panel structure to report the panel type,
using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
eDP, DSI and DPI). This will be used to initialise the corresponding
connector type.

Update all panel drivers to fill the new field.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/panel/panel-arm-versatile.c   |  1 +
 .../drm/panel/panel-feiyang-fy07024di26a30d.c |  1 +
 drivers/gpu/drm/panel/panel-ilitek-ili9322.c  |  1 +
 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c |  1 +
 drivers/gpu/drm/panel/panel-innolux-p079zca.c |  1 +
 .../gpu/drm/panel/panel-jdi-lt070me05000.c|  1 +
 .../drm/panel/panel-kingdisplay-kd097d04.c|  1 +
 drivers/gpu/drm/panel/panel-lg-lb035q02.c |  1 +
 drivers/gpu/drm/panel/panel-lg-lg4573.c   |  1 +
 drivers/gpu/drm/panel/panel-lvds.c|  1 +
 drivers/gpu/drm/panel/panel-nec-nl8048hl11.c  |  1 +
 drivers/gpu/drm/panel/panel-novatek-nt39016.c |  1 +
 .../drm/panel/panel-olimex-lcd-olinuxino.c|  1 +
 .../gpu/drm/panel/panel-orisetech-otm8009a.c  |  1 +
 .../drm/panel/panel-osd-osd101t2587-53ts.c|  1 +
 .../drm/panel/panel-panasonic-vvx10f034n00.c  |  1 +
 .../drm/panel/panel-raspberrypi-touchscreen.c |  1 +
 drivers/gpu/drm/panel/panel-raydium-rm67191.c |  1 +
 drivers/gpu/drm/panel/panel-raydium-rm68200.c |  1 +
 .../drm/panel/panel-rocktech-jh057n00900.c|  1 +
 drivers/gpu/drm/panel/panel-ronbo-rb070d30.c  |  1 +
 drivers/gpu/drm/panel/panel-samsung-ld9040.c  |  1 +
 drivers/gpu/drm/panel/panel-samsung-s6d16d0.c |  1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c |  1 +
 .../gpu/drm/panel/panel-samsung-s6e63j0x03.c  |  1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63m0.c |  1 +
 drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c |  1 +
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c   |  1 +
 .../gpu/drm/panel/panel-sharp-lq101r1sx01.c   |  1 +
 .../gpu/drm/panel/panel-sharp-ls037v7dw01.c   |  1 +
 .../gpu/drm/panel/panel-sharp-ls043t1le01.c   |  1 +
 drivers/gpu/drm/panel/panel-simple.c  | 23 +++
 drivers/gpu/drm/panel/panel-sitronix-st7701.c |  1 +
 .../gpu/drm/panel/panel-sitronix-st7789v.c|  1 +
 drivers/gpu/drm/panel/panel-sony-acx565akm.c  |  1 +
 drivers/gpu/drm/panel/panel-tpo-td028ttec1.c  |  1 +
 drivers/gpu/drm/panel/panel-tpo-td043mtea1.c  |  1 +
 drivers/gpu/drm/panel/panel-tpo-tpg110.c  |  1 +
 drivers/gpu/drm/panel/panel-truly-nt35597.c   |  1 +
 include/drm/drm_panel.h   |  7 ++
 40 files changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c 
b/drivers/gpu/drm/panel/panel-arm-versatile.c
index 5f72c922a04b..5c335fc1632b 100644
--- a/drivers/gpu/drm/panel/panel-arm-versatile.c
+++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
@@ -353,6 +353,7 @@ static int versatile_panel_probe(struct platform_device 
*pdev)
drm_panel_init(>panel);
vpanel->panel.dev = dev;
vpanel->panel.funcs = _panel_drm_funcs;
+   vpanel->panel.type = DRM_MODE_CONNECTOR_DPI;
 
return drm_panel_add(>panel);
 }
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c 
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index dabf59e0f56f..58894a4bf02c 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -207,6 +207,7 @@ static int feiyang_dsi_probe(struct mipi_dsi_device *dsi)
drm_panel_init(>panel);
ctx->panel.dev = >dev;
ctx->panel.funcs = _funcs;
+   ctx->panel.type = DRM_MODE_CONNECTOR_DSI;
 
ctx->dvdd = devm_regulator_get(>dev, "dvdd");
if (IS_ERR(ctx->dvdd)) {
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
index 3c58f63adbf7..10a6f4ab53e2 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -898,6 +898,7 @@ static int ili9322_probe(struct spi_device *spi)
drm_panel_init(>panel);
ili->panel.dev = dev;
ili->panel.funcs = _drm_funcs;
+   ili->panel.type = DRM_MODE_CONNECTOR_DPI;
 
return drm_panel_add(>panel);
 }
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 3ad4a46c4e94..360b87ff62a1 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -436,6 +436,7 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
drm_panel_init(>panel);
ctx->panel.dev = >dev;
ctx->panel.funcs = _funcs;
+   ctx->panel.type = DRM_MODE_CONNECTOR_DSI;
 
ctx->power = devm_regulator_get(>dev, "power");
if (IS_ERR(ctx->power)) {
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index d92d1c98878c..00b24662ebb5 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ 

[PATCH 2/2] drm/bridge: panel: Use drm_panel.type instead of explicit connector_type

2019-08-22 Thread Laurent Pinchart
The drm panel bridge creates a connector using a connector type explicit
passed by the display controller or bridge driver that instantiates the
panel bridge. Now that drm_panel reports its connector type, use it and
remove the connector_type argument to drm_panel_bridge_add() and
devm_drm_panel_bridge_add().

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c |  2 +-
 drivers/gpu/drm/bridge/cdns-dsi.c|  2 +-
 drivers/gpu/drm/bridge/lvds-encoder.c|  2 +-
 drivers/gpu/drm/bridge/panel.c   | 16 
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c|  2 +-
 drivers/gpu/drm/ingenic/ingenic-drm.c|  6 ++
 drivers/gpu/drm/mcde/mcde_dsi.c  |  3 +--
 drivers/gpu/drm/pl111/pl111_drv.c|  3 +--
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c|  3 +--
 drivers/gpu/drm/rockchip/rockchip_rgb.c  |  2 +-
 drivers/gpu/drm/stm/ltdc.c   |  3 +--
 drivers/gpu/drm/tilcdc/tilcdc_external.c |  3 +--
 drivers/gpu/drm/tve200/tve200_drv.c  |  3 +--
 drivers/gpu/drm/vc4/vc4_dpi.c|  2 +-
 drivers/gpu/drm/vc4/vc4_dsi.c|  3 +--
 include/drm/drm_bridge.h |  6 ++
 16 files changed, 21 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index c388497366ca..34ce38217350 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -107,7 +107,7 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev, int endpoint)
output->encoder.possible_crtcs = 0x1;
 
if (panel) {
-   bridge = drm_panel_bridge_add(panel, 
DRM_MODE_CONNECTOR_Unknown);
+   bridge = drm_panel_bridge_add(panel);
if (IS_ERR(bridge))
return PTR_ERR(bridge);
}
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
index 2af7f25c7413..aa109b5dc41c 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -958,7 +958,7 @@ static int cdns_dsi_attach(struct mipi_dsi_host *host,
 
panel = of_drm_find_panel(np);
if (!IS_ERR(panel)) {
-   bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DSI);
+   bridge = drm_panel_bridge_add(panel);
} else {
bridge = of_drm_find_bridge(dev->dev.of_node);
if (!bridge)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 9ebc750449cf..7b03ba65673d 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -107,7 +107,7 @@ static int lvds_encoder_probe(struct platform_device *pdev)
}
 
lvds_encoder->panel_bridge =
-   devm_drm_panel_bridge_add(dev, panel, DRM_MODE_CONNECTOR_LVDS);
+   devm_drm_panel_bridge_add(dev, panel);
if (IS_ERR(lvds_encoder->panel_bridge))
return PTR_ERR(lvds_encoder->panel_bridge);
 
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index f5b8e55301ac..912b0e9ecd5f 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -16,7 +16,6 @@ struct panel_bridge {
struct drm_bridge bridge;
struct drm_connector connector;
struct drm_panel *panel;
-   u32 connector_type;
 };
 
 static inline struct panel_bridge *
@@ -72,7 +71,7 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
 
ret = drm_connector_init(bridge->dev, connector,
 _bridge_connector_funcs,
-panel_bridge->connector_type);
+panel_bridge->panel->type);
if (ret) {
DRM_ERROR("Failed to initialize connector\n");
return ret;
@@ -137,8 +136,6 @@ static const struct drm_bridge_funcs 
panel_bridge_bridge_funcs = {
  * just calls the appropriate functions from _panel.
  *
  * @panel: The drm_panel being wrapped.  Must be non-NULL.
- * @connector_type: The DRM_MODE_CONNECTOR_* for the connector to be
- * created.
  *
  * For drivers converting from directly using drm_panel: The expected
  * usage pattern is that during either encoder module probe or DSI
@@ -155,8 +152,7 @@ static const struct drm_bridge_funcs 
panel_bridge_bridge_funcs = {
  * See devm_drm_panel_bridge_add() for an automatically manged version of this
  * function.
  */
-struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
-   u32 connector_type)
+struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel)
 {
struct panel_bridge *panel_bridge;
 
@@ -168,7 +164,6 @@ struct drm_bridge *drm_panel_bridge_add(struct drm_panel 
*panel,

[PATCH 5/6] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata

2019-08-22 Thread Gwan-gyeong Mun
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
static HDR metadata. The HDR Metadata will be provided by userspace
compositors, based on blending policies and passed to the driver through
a blob property.

Because each of GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet, it adds and uses different register size.

Setup Infoframe SDP header and data block in function
intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata as per
dp 1.4 spec and CTA-861-F spec.
As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range and
Mastering Infoframe for HDR content, which is defined in CTA-861-F spec.
According to DP 1.4 spec and CEA-861-F spec Table 5, in order to transmit
static HDR metadata, we have to use Non-audio INFOFRAME SDP v1.3.

++---+
|  [ Packet Type Value ] |   [ Packet Type ] |
++---+
| 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
++---+
|  [Transmission Timing] |
++
| As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
| which Dynamic Range and Mastering INFOFRAME are defined|
++

Signed-off-by: Gwan-gyeong Mun 
---
 drivers/gpu/drm/i915/display/intel_ddi.c |  1 +
 drivers/gpu/drm/i915/display/intel_dp.c  | 90 
 drivers/gpu/drm/i915/display/intel_dp.h  |  3 +
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 4 files changed, 95 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a944d7c5091b..a7b7f05a7ada 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3478,6 +3478,7 @@ static void intel_enable_ddi_dp(struct intel_encoder 
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
+   intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
 
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a9a91f675b4a..edb21b261319 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4553,6 +4553,84 @@ intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
intel_dig_port->write_infoframe(_dig_port->base,
crtc_state, DP_SDP_VSC, _sdp, sizeof(vsc_sdp));
 }
+static int
+intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state 
*crtc_state,
+ const struct drm_connector_state 
*conn_state)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = 
to_i915(intel_dig_port->base.base.dev);
+   struct dp_sdp infoframe_sdp = {};
+   struct hdmi_drm_infoframe drm_infoframe = {};
+   const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE + 
HDMI_DRM_INFOFRAME_SIZE;
+   unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE + HDMI_DRM_INFOFRAME_SIZE];
+   ssize_t len;
+   int ret;
+
+   ret = drm_hdmi_infoframe_set_hdr_metadata(_infoframe, conn_state);
+   if (ret) {
+   DRM_DEBUG_KMS("couldn't set HDR metadata in infoframe\n");
+   return ret;
+   }
+
+   len = hdmi_drm_infoframe_pack_only(_infoframe, buf, sizeof(buf));
+   if (len < 0) {
+   DRM_DEBUG_KMS("buffer size is smaller than hdr metadata 
infoframe\n");
+   return (int)len;
+   }
+
+   if (len != infoframe_size) {
+   DRM_DEBUG_KMS("wrong static hdr metadata size\n");
+   return -EINVAL;
+   }
+
+   /*
+* Set up the infoframe sdp packet for HDR static metadata.
+* Prepare VSC Header for SU as per DP 1.4a spec,
+* Table 2-100 and Table 2-101
+*/
+
+   /* Packet ID, 00h for non-Audio INFOFRAME */
+   infoframe_sdp.sdp_header.HB0 = 0;
+   /*
+* Packet Type 80h + Non-audio INFOFRAME Type value
+* HDMI_INFOFRAME_TYPE_DRM: 0x87,
+*/
+   infoframe_sdp.sdp_header.HB1 = drm_infoframe.type;
+   /*
+* Least Significant Eight Bits of (Data Byte Count – 1)
+* infoframe_size - 1,
+*/
+

[PATCH 4/6] drm/i915/dp: Attach colorspace property

2019-08-22 Thread Gwan-gyeong Mun
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.

Based on colorspace property value create a VSC SDP packet with appropriate
colorspace. This would help to enable wider color gamut like BT2020 on a
sink device.

Signed-off-by: Gwan-gyeong Mun 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index d2815fdcbe8f..a9a91f675b4a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6402,6 +6402,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct 
drm_connector *connect
else if (INTEL_GEN(dev_priv) >= 5)
drm_connector_attach_max_bpc_property(connector, 6, 12);
 
+   intel_attach_colorspace_property(connector);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
 
-- 
2.22.0

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

[PATCH 2/6] drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA

2019-08-22 Thread Gwan-gyeong Mun
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. It adds output_colorspace to
intel_crtc_state struct as a place holder of pipe's output colorspace.
In order to distinguish needed colorimetry for VSC SDP, it adds
intel_dp_needs_vsc_colorimetry function.
If the output colorspace requires vsc sdp or output format is YCbCr 4:2:0,
it uses MSA with VSC SDP.

As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of
Color Encoding Format and Content Color Gamut] while sending
BT.2020 Colorimetry signals we should program MSA MISC1 fields which
indicate VSC SDP for the Pixel Encoding/Colorimetry Format.

Signed-off-by: Gwan-gyeong Mun 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  8 +++---
 .../drm/i915/display/intel_display_types.h|  3 +++
 drivers/gpu/drm/i915/display/intel_dp.c   | 25 ++-
 drivers/gpu/drm/i915/display/intel_dp.h   |  1 +
 4 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4f7ea0a35976..a944d7c5091b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1737,11 +1737,13 @@ void intel_ddi_set_pipe_settings(const struct 
intel_crtc_state *crtc_state)
/*
 * As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
 * of Color Encoding Format and Content Color Gamut] while sending
-* YCBCR 420 signals we should program MSA MISC1 fields which
-* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
+* YCBCR 420, HDR BT.2020 signals we should program MSA MISC1 fields
+* which indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
 */
-   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   if ((crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) ||
+   (intel_dp_needs_vsc_colorimetry(crtc_state->output_colorspace)))
temp |= TRANS_MSA_USE_VSC_SDP;
+
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 449abaea619f..9845abcf6f29 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -964,6 +964,9 @@ struct intel_crtc_state {
/* Output format RGB/YCBCR etc */
enum intel_output_format output_format;
 
+   /* Output colorspace sRGB/BT.2020 etc */
+   u32 output_colorspace;
+
/* Output down scaling is done in LSPCON device */
bool lspcon_downsampling;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 55d5ab97061c..d2815fdcbe8f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2164,6 +2164,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_pch_encoder = true;
 
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
+   pipe_config->output_colorspace = intel_conn_state->base.colorspace;
+
if (lspcon->active)
lspcon_ycbcr420_config(_connector->base, pipe_config);
else
@@ -4408,6 +4410,26 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp 
*intel_dp,
return 0;
 }
 
+bool
+intel_dp_needs_vsc_colorimetry(u32 colorspace)
+{
+   bool ret = false;
+
+   switch (colorspace) {
+   case DRM_MODE_COLORIMETRY_SYCC_601:
+   case DRM_MODE_COLORIMETRY_OPYCC_601:
+   case DRM_MODE_COLORIMETRY_BT2020_YCC:
+   case DRM_MODE_COLORIMETRY_BT2020_RGB:
+   case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+   ret = true;
+   break;
+   default:
+   break;
+   }
+
+   return ret;
+}
+
 static void
 intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
   const struct intel_crtc_state *crtc_state,
@@ -4536,7 +4558,8 @@ void intel_dp_vsc_enable(struct intel_dp *intel_dp,
 const struct intel_crtc_state *crtc_state,
 const struct drm_connector_state *conn_state)
 {
-   if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
+   if ((crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420) &&
+   (!intel_dp_needs_vsc_colorimetry(conn_state->colorspace)))
return;
 
intel_dp_setup_vsc_sdp(intel_dp, crtc_state, conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index 91a0ee6058fe..b2da7c9998f7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -111,6 +111,7 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
 bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp);
 int intel_dp_link_required(int pixel_clock, int bpp);
 int 

[PATCH 6/6] drm/i915/dp: Attach HDR metadata property to DP connector

2019-08-22 Thread Gwan-gyeong Mun
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.

Signed-off-by: Gwan-gyeong Mun 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index edb21b261319..af2f960a5dd2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6494,6 +6494,10 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
 
intel_attach_colorspace_property(connector);
 
+   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+   drm_object_attach_property(>base,
+   
connector->dev->mode_config.hdr_output_metadata_property, 0);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
 
-- 
2.22.0

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

[PATCH 3/6] drm: Add DisplayPort colorspace property

2019-08-22 Thread Gwan-gyeong Mun
In order to use colorspace property to Display Port connectors, it extends
DRM_MODE_CONNECTOR_DisplayPort connector_type on
drm_mode_create_colorspace_property function.

Signed-off-by: Gwan-gyeong Mun 
---
 drivers/gpu/drm/drm_connector.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..655ada9d4c16 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1703,7 +1703,9 @@ int drm_mode_create_colorspace_property(struct 
drm_connector *connector)
struct drm_property *prop;
 
if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
-   connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
+   connector->connector_type == DRM_MODE_CONNECTOR_HDMIB ||
+   connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+   connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
"Colorspace",
hdmi_colorspaces,
-- 
2.22.0

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

[PATCH 1/6] drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format

2019-08-22 Thread Gwan-gyeong Mun
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it adds an argument
of drm_connector_state type.

Setup VSC header and data block in function intel_dp_setup_vsc_sdp for
pixel encoding / colorimetry format as per dp 1.4a spec, section 2.2.5.7.1,
table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
table 2-120: VSC SDP Payload for DB16 through DB18.

Signed-off-by: Gwan-gyeong Mun 
---
 drivers/gpu/drm/i915/display/intel_ddi.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display.h |  2 -
 drivers/gpu/drm/i915/display/intel_dp.c  | 68 
 drivers/gpu/drm/i915/display/intel_dp.h  |  3 +
 4 files changed, 60 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 8eb2b3ec01ed..4f7ea0a35976 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3475,7 +3475,7 @@ static void intel_enable_ddi_dp(struct intel_encoder 
*encoder,
 
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
-   intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
+   intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
 
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index e57e6969051d..7bd59241fc32 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -499,8 +499,6 @@ void intel_dp_get_m_n(struct intel_crtc *crtc,
  struct intel_crtc_state *pipe_config);
 void intel_dp_set_m_n(const struct intel_crtc_state *crtc_state,
  enum link_m_n_set m_n);
-void intel_dp_ycbcr_420_enable(struct intel_dp *intel_dp,
-  const struct intel_crtc_state *crtc_state);
 int intel_dotclock_calculate(int link_freq, const struct intel_link_m_n *m_n);
 bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
struct dpll *best_clock);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c45a3bb102d..55d5ab97061c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4409,8 +4409,9 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
 }
 
 static void
-intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
-  const struct intel_crtc_state *crtc_state)
+intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct dp_sdp vsc_sdp = {};
@@ -4431,13 +4432,55 @@ intel_pixel_encoding_setup_vsc(struct intel_dp 
*intel_dp,
 */
vsc_sdp.sdp_header.HB3 = 0x13;
 
-   /*
-* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
-* DB16[3:0] DP 1.4a spec, Table 2-120
-*/
-   vsc_sdp.db[16] = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
-   /* RGB->YCBCR color conversion uses the BT.709 color space. */
-   vsc_sdp.db[16] |= 0x1; /* 0x1, ITU-R BT.709 */
+   /* DP 1.4a spec, Table 2-120 */
+   switch (crtc_state->output_format) {
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   vsc_sdp.db[16] = 0x1 << 4; /* YCbCr 444 : DB16[7:4] = 1h */
+   break;
+   case INTEL_OUTPUT_FORMAT_YCBCR420:
+   vsc_sdp.db[16] = 0x3 << 4; /* YCbCr 420 : DB16[7:4] = 3h */
+   break;
+   case INTEL_OUTPUT_FORMAT_RGB:
+   default:
+   /* RGB: DB16[7:4] = 0h */
+   break;
+   }
+
+   switch (conn_state->colorspace) {
+   case DRM_MODE_COLORIMETRY_BT709_YCC:
+   vsc_sdp.db[16] |= 0x1;
+   break;
+   case DRM_MODE_COLORIMETRY_XVYCC_601:
+   vsc_sdp.db[16] |= 0x2;
+   break;
+   case DRM_MODE_COLORIMETRY_XVYCC_709:
+   vsc_sdp.db[16] |= 0x3;
+   break;
+   case DRM_MODE_COLORIMETRY_SYCC_601:
+   vsc_sdp.db[16] |= 0x4;
+   break;
+   case DRM_MODE_COLORIMETRY_OPYCC_601:
+   vsc_sdp.db[16] |= 0x5;
+   break;
+   case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+   case DRM_MODE_COLORIMETRY_BT2020_RGB:
+   vsc_sdp.db[16] |= 0x6;
+   break;
+   case DRM_MODE_COLORIMETRY_BT2020_YCC:
+   vsc_sdp.db[16] |= 0x7;
+   break;
+   case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
+   case 

[PATCH 0/6] drm/i915/dp: Support for DP HDR outputs

2019-08-22 Thread Gwan-gyeong Mun
Support for HDR10 video was introduced in DisplayPort 1.4.
On GLK+ platform, in order to use DisplayPort HDR10, we need to support
BT.2020 colorimetry and HDR Static metadata.
It implements the CTA-861-G standard for transport of static HDR metadata.
It enables writing of HDR metadata infoframe SDP to the panel.
The HDR Metadata will be provided by userspace compositors, based on
blending policies and passed to the driver through a blob property.
And It refactors, renames and extends a function which handled vsc sdp
header and data block setup for supporting colorimetry format.
And It attaches the colorspace connector property and HDR metadata property
to a DisplayPort connector.

These patches tested on below test environment.
Test Environment:
 - Tested System: GLK and Gen11 platform.
 - Monitor: Dell UP2718Q 4K HDR Monitor.
 - In order to test DP HDR10, test environment uses patched Kodi-gbm,
   patched Media driver and HDR10 video.

   You can find these on below.
   [patched Kodi-gbm]
- repo: https://github.com/Kwiboo/xbmc/tree/drmprime-hdr 
   [download 4K HDR video file]
- link: https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/
   [Media Driver for GLK]
- repo https://gitlab.freedesktop.org/emersion/intel-vaapi-driver
  master branch
   [Media Driver for ICL]
- repo: https://github.com/harishkrupo/media-driver/tree/p010_composite

Gwan-gyeong Mun (6):
  drm/i915/dp: Extend program of VSC Header and DB for Colorimetry
Format
  drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
  drm: Add DisplayPort colorspace property
  drm/i915/dp: Attach colorspace property
  drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static
Metadata
  drm/i915/dp: Attach HDR metadata property to DP connector

 drivers/gpu/drm/drm_connector.c   |   4 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  |  11 +-
 drivers/gpu/drm/i915/display/intel_display.h  |   2 -
 .../drm/i915/display/intel_display_types.h|   3 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 189 --
 drivers/gpu/drm/i915/display/intel_dp.h   |   7 +
 drivers/gpu/drm/i915/i915_reg.h   |   1 +
 7 files changed, 197 insertions(+), 20 deletions(-)

-- 
2.22.0

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

[PATCH] MAINTAINERS: Add Steven and Alyssa as panfrost reviewers

2019-08-22 Thread Rob Herring
Add Steven Price and Alyssa Rosenzweig as reviewers as they have been the
primary reviewers already.

Cc: Steven Price 
Cc: Alyssa Rosenzweig 
Cc: Tomeu Vizoso 
Signed-off-by: Rob Herring 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 67b75fc33c61..28f4a20940cb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1255,6 +1255,8 @@ F:Documentation/gpu/afbc.rst
 ARM MALI PANFROST DRM DRIVER
 M: Rob Herring 
 M: Tomeu Vizoso 
+R: Steven Price 
+R: Alyssa Rosenzweig 
 L: dri-devel@lists.freedesktop.org
 S: Supported
 T: git git://anongit.freedesktop.org/drm/drm-misc
-- 
2.20.1

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

Re: [PATCH v2 13/50] drm/bridge: panel: Implement bridge connector operations

2019-08-22 Thread Laurent Pinchart
Hi Boris,

On Thu, Aug 22, 2019 at 08:02:47PM +0200, Boris Brezillon wrote:
> On Thu, 22 Aug 2019 19:35:24 +0300 Laurent Pinchart wrote:
> > On Thu, Aug 22, 2019 at 06:29:09PM +0200, Boris Brezillon wrote:
> >> On Tue, 20 Aug 2019 04:16:44 +0300 Laurent Pinchart wrote:
> >>   
> >>> Implement the newly added bridge connector operations, allowing the
> >>> usage of drm_bridge_panel with drm_bridge_connector.
> >>> 
> >>> Signed-off-by: Laurent Pinchart 
> >>> ---
> >>>  drivers/gpu/drm/bridge/panel.c | 18 +-
> >>>  1 file changed, 17 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/drivers/gpu/drm/bridge/panel.c 
> >>> b/drivers/gpu/drm/bridge/panel.c
> >>> index f5b8e55301ac..1c7f5b648f05 100644
> >>> --- a/drivers/gpu/drm/bridge/panel.c
> >>> +++ b/drivers/gpu/drm/bridge/panel.c
> >>> @@ -60,7 +60,7 @@ static int panel_bridge_attach(struct drm_bridge 
> >>> *bridge,
> >>>   int ret;
> >>>  
> >>>   if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> >>> - return -EINVAL;
> >>> + return 0;
> >>>  
> >>>   if (!bridge->encoder) {
> >>>   DRM_ERROR("Missing encoder\n");
> >>> @@ -123,6 +123,18 @@ static void panel_bridge_post_disable(struct 
> >>> drm_bridge *bridge)
> >>>   drm_panel_unprepare(panel_bridge->panel);
> >>>  }
> >>>  
> >>> +static int panel_bridge_get_modes(struct drm_bridge *bridge,
> >>> +   struct drm_connector *connector)
> >>> +{
> >>> + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> >>> +
> >>> + /*
> >>> +  * FIXME: drm_panel_get_modes() should take the connector as an
> >>> +  * argument.
> >>> +  */
> >>> + return drm_panel_get_modes(panel_bridge->panel);
> >>> +}
> >>> +
> >>>  static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
> >>>   .attach = panel_bridge_attach,
> >>>   .detach = panel_bridge_detach,
> >>> @@ -130,6 +142,7 @@ static const struct drm_bridge_funcs 
> >>> panel_bridge_bridge_funcs = {
> >>>   .enable = panel_bridge_enable,
> >>>   .disable = panel_bridge_disable,
> >>>   .post_disable = panel_bridge_post_disable,
> >>> + .get_modes = panel_bridge_get_modes,
> >>>  };
> >>>  
> >>>  /**
> >>> @@ -175,6 +188,9 @@ struct drm_bridge *drm_panel_bridge_add(struct 
> >>> drm_panel *panel,
> >>>  #ifdef CONFIG_OF
> >>>   panel_bridge->bridge.of_node = panel->dev->of_node;
> >>>  #endif
> >>> + panel_bridge->bridge.ops = DRM_BRIDGE_OP_MODES;
> >>> + /* FIXME: The panel should report its type. */
> >>> + panel_bridge->bridge.type = DRM_MODE_CONNECTOR_DPI;  
> >> 
> >> Shouldn't we patch all panel drivers to expose this type before doing
> >> this change? I mean, the connector type is exposed to userspace, and I
> >> wouldn't be surprised if some userspace apps/libs decided to base their
> >> output selection logic on this field.  
> > 
> > Note that this type will only make it to userspace for drivers that use
> > the bridge->type field, likely through the drm bridge connector helper.
> > I do agree that panel drivers should be updated, but given the number of
> > panels in panel-simple and the fact that the information would need to
> > be researched for most of them, this will be significant work. Can't
> > this be done when converting display controller drivers on a need basis
> > ?
> 
> I think setting a default value and fixing things on a need basis is
> okay, but that doesn't prevent you from adding the necessary
> infrastructure to let panel drivers pass this type (we can fallback to a
> default type in panel drivers instead of here).

I'll add the infrastructure/

> I'm also not sure why 'DPI' is chosen as the default, shouldn't we use
> 'Unknown' instead?

Mostly to avoid breaking userspace, as most panels supported by
drm_panel use DPI.

> > Or maybe we could, as an interim measure, derive the type from the bus
> > formats reported by the panel if the panel type is not set ? If the
> > panel reports MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> > MEDIA_BUS_FMT_RGB666_1X7X4_SPWG or MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA then
> > we can set the type to LVDS, otherwise we set it to DPI.
> 
> Hm, aren't we better off patching panel descs exposing these bus formats
> to also explicitly set desc->type to LVDS, leaving others to Unknown
> (Unknown is 0, so you don't have to patch all panel_desc definitions)?

I was thinking about adding this logic to
drivers/gpu/drm/bridge/panel.c, which would avoid patching lots of panel
drivers as a prerequisite. With such a logic there, plus a default to
DPI, I thought we would be good enough for an initial version. It would
leave DSI unhandled, so maybe not the best :-S

> > I can submit a
> > patch to add a type field to the panel structure and implement this
> > logic.

-- 
Regards,

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

Re: [PATCH v2 04/50] drm/bridge: Add connector-related bridge operations and data

2019-08-22 Thread Laurent Pinchart
Hi Boris,

On Thu, Aug 22, 2019 at 06:41:25PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:35 +0300 Laurent Pinchart wrote:
> 
> > +/**
> > + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > + */
> > +enum drm_bridge_ops {
> > +   /**
> > +* @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > +* its output. Bridges that set this flag shall implement the
> > +* _bridge_funcs->detect callback.
> > +*/
> > +   DRM_BRIDGE_OP_DETECT = BIT(0),
> > +   /**
> > +* @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > +* connected to its output. Bridges that set this flag shall implement
> > +* the _bridge_funcs->get_edid callback.
> > +*/
> > +   DRM_BRIDGE_OP_EDID = BIT(1),
> > +   /**
> > +* @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > +* without requiring polling. Bridges that set this flag shall
> > +* implement the _bridge_funcs->hpd_enable and
> > +* _bridge_funcs->hpd_disable callbacks if they support enabling
> > +* and disabling hot-plug detection dynamically.
> > +*/
> > +   DRM_BRIDGE_OP_HPD = BIT(2),
> > +   /**
> > +* @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > +* by the display at its output. This does not include readind EDID
> > +* which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > +* this flag shall implement the _bridge_funcs->get_modes callback.
> > +*/
> > +   DRM_BRIDGE_OP_MODES = BIT(3),
> > +};
> > +
> >  /**
> >   * struct drm_bridge - central DRM bridge control structure
> >   */
> > @@ -398,6 +538,33 @@ struct drm_bridge {
> > const struct drm_bridge_funcs *funcs;
> > /** @driver_private: pointer to the bridge driver's internal context */
> > void *driver_private;
> > +   /** @ops: bitmask of operations supported by the bridge */
> > +   enum drm_bridge_ops ops;
> 
> Just realized that you're not checking ->ops and ->funcs consistency at
> attach() time (you're only checking ->ops in the tfp410 driver before
> calling ->funcs->detect() and ->funcs->get_modes() and they might be
> NULL).

Do you think that's an issue ? I would then expect the driver to crash
right away during development and the issue to be fixed.

> > +   /**
> > +* @type: Type of the connection at the bridge output
> > +* (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > +* identifies the type of connected display.
> > +*/
> > +   int type;
> > +   /**
> > +* @ddc: Associated I2C adapter for DDC access, if any.
> > +*/
> > +   struct i2c_adapter *ddc;
> > +   /** private: */
> > +   /**
> > +* @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > +*/
> > +   struct mutex hpd_mutex;
> > +   /**
> > +* @hpd_cb: Hot plug detection callback, registered with
> > +* drm_bridge_hpd_enable().
> > +*/
> > +   void (*hpd_cb)(void *data, enum drm_connector_status status);
> > +   /**
> > +* @hpd_data: Private data passed to the Hot plug detection callback
> > +* @hpd_cb.
> > +*/
> > +   void *hpd_data;
> >  };

-- 
Regards,

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

[PATCH v3] drm/i915: Enable CONFIG_DMA_API_DEBUG_SG for intel-ci

2019-08-22 Thread Lyude Paul
Now that we've fixed i915 so that it sets a max SG segment length and
gotten rid of the relevant warnings, let's enable
CONFIG_DMA_API_DEBUG_SG for intel-ci so that we can catch issues like
this in the future as well.

Changes since v2:
* Also select DMA_API_DEBUG - Chris Wilson

Signed-off-by: Lyude Paul 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/Kconfig.debug | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 00786a142ff0..cb929d0218e8 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -32,6 +32,8 @@ config DRM_I915_DEBUG
select DRM_DEBUG_SELFTEST
select DMABUF_SELFTESTS
select SW_SYNC # signaling validation framework (igt/syncobj*)
+select DMA_API_DEBUG
+select DMA_API_DEBUG_SG
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
select DRM_I915_SELFTEST
select DRM_I915_DEBUG_RUNTIME_PM
-- 
2.21.0



Re: [PATCH v4 0/5] MST DSC support in drm-mst

2019-08-22 Thread Lyude Paul
OK-done reviewing, but there's some stuff missing here. The PBN bandwidth
checks in https://patchwork.freedesktop.org/patch/325604/?series=65423=3
need to be moved into drm_dp_mst_atomic_check(), along with moving amdgpu over 
to using drm_dp_mst_atomic_check(). Doing so will also give us PBN bandwidth 
checks in both i915 and nouveau as well, and keeps the bandwidth calculation 
where it should be.

Additionally, you still need to move the code here into an MST atomic helper
or drm_dp_mst_atomic_check() as well:

https://patchwork.freedesktop.org/patch/325611/?series=65423=3

Unless I'm mistaken, adding each CRTC which has a connector whose PBN requires
recalculation into the atomic state is something every DRM driver is going to
need to do. And, you can do this more easily by adding PBN information into
drm_dp_mst_topology_state. Yes-it's a lot of locks, but since every connector
in an MST topology is sharing the bandwidth on the same link it's kind of
expected. I already know I'm going to have to do basically the same thing with
every driver once I've got the time to actually implement fallback link rate
retraining with MST topologies.

If you need help figuring out how to structure this in a way that works for
all drivers, I'm willing to help and I'm sure Manasi is as well.

On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> Add necessary support for MST DSC.
> (Display Stream COmpression over Multi-Stream Transport)
> 
> v4: Split patchset and rebase onto drm-tip
> 
> David Francis (5):
>   drm/dp-mst: Add PBN calculation for DSC modes
>   drm/dp-mst: Parse FEC capability on MST ports
>   drm/dp-mst: Add MST support to DP DPCD R/W functions
>   drm/dp-mst: Fill branch->num_ports
>   drm/dp-mst: Add helpers for querying and enabling MST DSC
> 
>  drivers/gpu/drm/drm_dp_aux_dev.c  |  12 +-
>  drivers/gpu/drm/drm_dp_helper.c   |  10 +-
>  drivers/gpu/drm/drm_dp_mst_topology.c | 243 ++
>  include/drm/drm_dp_mst_helper.h   |   8 +-
>  4 files changed, 260 insertions(+), 13 deletions(-)
> 
-- 
Cheers,
Lyude Paul

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

Re: [PATCH v4 5/5] drm/dp-mst: Add helpers for querying and enabling MST DSC

2019-08-22 Thread Lyude Paul
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> Add drm_dp_mst_dsc_caps_for_port and drm_dp_mst_dsc_enable,
> two helper functions for MST DSC
> 
> The former, given a port, returns the raw DPCD DSC caps off
> that port.
> 
> The latter, given a port, enables or disables DSC on that port.
> 
> In both cases, the port given as input should be a leaf of
> the MST tree with an attached display.
> 
> The logic for this is somewhat complicated, as DSC can be
> enabled in 4 different ways.
> 
> Case 1: DP-to-DP peer device
> if the branch immediately upstream has
>  - PDT = DP_PEER_DEVICE_DP_MST_BRANCHING (2)
>  - DPCD rev. >= DP 1.4
>  - Exactly one input and one output
>  - The output has PDT = DP_PEER_DEVICE_SST_SINK (3)
> 
> In this case, DSC could be possible either on the endpoint
> or the peer device. Prefer the endpoint, which is possible if
>  - The endpoint has DP_DSC_DECOMPRESSION_IS_SUPPORTED bit set
>  - The endpoint has DP_FEC_CAPABLE bit set
>  - The peer device has DSC_PASSTHROUGH_CAPABILITY bit set (from DP v2.0)
> 
> Otherwise, use the peer device
> 
> Case 2: DP-to-HDMI peer device
> If the output port has
>  - PDT = DP_PEER_DEVICE_DP_LEGACY_CONV (4)
>  - DPCD rev. >= DP 1.4
>  - LDPS = true
>  - MCS = false
> 
> In this case, DSC can only be attempted on the peer device
> (the output port)
> 
> Case 3: Virtual DP Sink (Internal Display Panel)
> If the output port has
>  - DPCD rev. >= DP 1.4
>  - port_num >= 8
> 
> In this case, DSC can only be attempted on the peer device
> (the output port)
> 
> Case 4: Synaptix Workaround
> If the output has
>  - link DPCD rev. >= DP 1.4
>  - link branch_dev_id = 0x90CC24 (Synaptix)
>  - There is exactly one branch device between the link and output
> 
> In this case, DSC can be attempted, but only using the *link*
> aux device's caps. This is a quirk.
> 
> Cc: Lyude Paul 
> Cc: Wenjing Liu 
> Cc: Nikola Cornij 
> Signed-off-by: David Francis 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 195 ++
>  include/drm/drm_dp_mst_helper.h   |   3 +
>  2 files changed, 198 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index af4b5cec7c84..00ddc54af65b 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4186,3 +4186,198 @@ static void drm_dp_mst_unregister_i2c_bus(struct
> drm_dp_aux *aux)
>  {
>   i2c_del_adapter(>ddc);
>  }
> +
> +/**
> + * drm_dp_mst_is_virtual_dpcd() - Is the given port a virtual DPCD device?
> + * @port: The port to check
> + *

Mind elaborating a bit here in the kernel documentation on what a virtual DPCD
device is?

> + * Returns:
> + * true if the port is a virtual DPCD peer device, false otherwise
> + */
> +static bool drm_dp_mst_is_virtual_dpcd(struct drm_dp_mst_port *port)
> +{
> + struct drm_dp_mst_port *downstream_port;
> +
> + if (!port)
> + return false;

I'd drop this, and just move the if (!port) check into
drm_dp_mst_dsc_aux_for_port(). Makes things a little more explicit.

> +
> + /* Virtual DP Sink (Internal Display Panel) */
> + if (port->port_num >= 8 && port->dpcd_rev >= DP_DPCD_REV_14)
> + return true;
> +
> + /* DP-to-HDMI Protocol Converter */
> + if (port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV &&
> + !port->mcs &&
> + port->ldps &&
> + port->dpcd_rev >= DP_DPCD_REV_14)
> + return true;

Please fix the indenting here, most DRM code (I may have mistakenly pointed
you at the kernel style guidelines, but I realized they don't explicitly
mention this other then the rule of "your code should look like the code
around it") written with line continuations starting on the same column as the
beginning paranthesis

if (some_very_long_variable == another_very_long_variable_wow ||
every_identifier_here_is_long > but_what_if_we_have_a_sub_conditional ||
(then_we_end_up_formatting_it_like_this &&
 starting_at_the_beginning_paranthesis)) {
same_for_function_calls("Which also require very long lines\n",
foo, bar, baz);
}

> +
> + /* DP-to-DP */
> + if (port->pdt == DP_PEER_DEVICE_MST_BRANCHING &&
> + port->mstb &&
> + port->dpcd_rev >= DP_DPCD_REV_14 &&
> + port->mstb->num_ports == 2) {
> + list_for_each_entry(downstream_port, >mstb->ports, next)
> {
> + if (!downstream_port->input &&
> + downstream_port->pdt ==
> DP_PEER_DEVICE_SST_SINK)
> + return true;
> + }
This isn't safe, anything that iterates downwards (so either mstb->ports, or
port->mstb) in the MST topology needs to happen under >lock, since
otherwise the port list can change under us. Note there's probably some places
this isn't followed, but I'm in the process of fixing that:


Re: [PATCH v2 34/50] drm/omap: Create connector for bridges

2019-08-22 Thread Laurent Pinchart
Hi Boris,

On Thu, Aug 22, 2019 at 07:00:11PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:17:05 +0300 Laurent Pinchart wrote:
> > Use the drm_bridge_connector helper to create a connector for pipelines
> > that use drm_bridge. This allows splitting connector operations across
> > multiple bridges when necessary, instead of having the last bridge in
> > the chain creating the connector and handling all connector operations
> > internally.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> > Changes since v1:
> > 
> > - Squash with patch "drm/omap: Detach from panels at remove time"
> > ---
> >  drivers/gpu/drm/omapdrm/omap_drv.c | 82 +-
> >  1 file changed, 70 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> > b/drivers/gpu/drm/omapdrm/omap_drv.c
> > index de373fd50729..f38d95cb31ba 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> > @@ -11,10 +11,12 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -290,9 +292,14 @@ static int omap_modeset_init(struct drm_device *dev)
> >  
> > if (pipe->output->bridge) {
> > ret = drm_bridge_attach(pipe->encoder,
> > -   pipe->output->bridge, NULL, 0);
> > -   if (ret < 0)
> > +   pipe->output->bridge, NULL,
> > +   DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> 
> I guess the only external bridge connected to an omap display
> controller in upstream DTs is the TFP410.

No, there's also the TI OP362 (analog amplier) and TI TPD12S015 (HDMI
ESD protection and level shifter). Those are not really encoders, but
they're bridges.

> I was wondering if falling back to !DRM_BRIDGE_ATTACH_NO_CONNECTOR
> would be acceptable in case one wants to convert a display controller
> driver which is known to be used in conjunction with various external
> bridges.

Yes, a display controller can support both options. I would however
recommend addressing bridges first in a conversion, and once all bridges
used by a display controller support DRM_BRIDGE_ATTACH_NO_CONNECTOR (and
implement the connector bridge ops), switch the display controller to
DRM_BRIDGE_ATTACH_NO_CONNECTOR unconditionally.

> > +   if (ret < 0) {
> > +   dev_err(priv->dev,
> > +   "unable to attach bridge %pOF\n",
> > +   pipe->output->bridge->of_node);
> > return ret;
> > +   }
> > }
> >  

-- 
Regards,

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

Re: [PATCH 3/4] kernel.h: Add non_block_start/end()

2019-08-22 Thread Andrew Morton
On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter  wrote:

> Hi Peter,
> 
> Iirc you've been involved at least somewhat in discussing this. -mm folks
> are a bit undecided whether these new non_block semantics are a good idea.
> Michal Hocko still is in support, but Andrew Morton and Jason Gunthorpe
> are less enthusiastic. Jason said he's ok with merging the hmm side of
> this if scheduler folks ack. If not, then I'll respin with the
> preempt_disable/enable instead like in v1.

I became mollified once Michel explained the rationale.  I think it's
OK.  It's very specific to the oom reaper and hopefully won't be used
more widely(?).



Re: [PATCH v2 2/2] drm/i915: Enable CONFIG_DMA_API_DEBUG_SG for intel-ci

2019-08-22 Thread Chris Wilson
Quoting Lyude Paul (2019-08-22 21:31:27)
> Now that we've fixed i915 so that it sets a max SG segment length and
> gotten rid of the relevant warnings, let's enable
> CONFIG_DMA_API_DEBUG_SG for intel-ci so that we can catch issues like
> this in the future as well.
> 
> Signed-off-by: Lyude Paul 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/Kconfig.debug | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
> b/drivers/gpu/drm/i915/Kconfig.debug
> index 00786a142ff0..ad8d3cd63c9f 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -32,6 +32,7 @@ config DRM_I915_DEBUG
> select DRM_DEBUG_SELFTEST
> select DMABUF_SELFTESTS
> select SW_SYNC # signaling validation framework (igt/syncobj*)

select DMA_API_DEBUG
as well for it to be enabled, no recursive dependency solver in Kconfig.

> +select DMA_API_DEBUG_SG
> select DRM_I915_SW_FENCE_DEBUG_OBJECTS
> select DRM_I915_SELFTEST
> select DRM_I915_DEBUG_RUNTIME_PM
> -- 
> 2.21.0
> 


[PATCH] drm: Add LTTPR defines for DP 1.4

2019-08-22 Thread Siqueira, Rodrigo
DP 1.4 specification defines Link Training Tunable PHY Repeater (LTTPR)
which is required to add support for systems with Thunderbolt or other
repeater devices.

Cc: Abdoulaye Berthe 
Cc: Harry Wentland 
Cc: Leo Li 
Signed-off-by: Rodrigo Siqueira 
Signed-off-by: Abdoulaye Berthe 
---
 include/drm/drm_dp_helper.h | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8364502f92cf..8336d960da7f 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -134,6 +134,32 @@
 #define DP_SUPPORTED_LINK_RATES0x010 /* eDP 1.4 */
 # define DP_MAX_SUPPORTED_RATES 8  /* 16-bit 
little-endian */
 
+/** Link Training (LT)-tunable Physical Repeaters - DP 1.4 **/
+#define DP_LTTPR_REV  0xf
+#define DP_LTTPR_MAX_LINK_RATE0xf0001
+#define DP_LTTPR_REPEATER_CNT 0xf0002
+#define DP_LTTPR_REPEATER_MODE0xf0003
+#define DP_LTTPR_MAX_LANE_CNT 0xf0004
+#define DP_LTTPR_EXTENDED_WAIT_TIMEOUT0xf0005
+#define DP_LTTPR_TRAINING_PATTERN_SET_REPEATER1   0xf0010
+#define DP_LTTPR_TRAINING_LANE0_SET_REPEATER1 0xf0011
+#define DP_LTTPR_TRAINING_LANE1_SET_REPEATER1 0xf0012
+#define DP_LTTPR_TRAINING_LANE2_SET_REPEATER1 0xf0013
+#define DP_LTTPR_TRAINING_LANE3_SET_REPEATER1 0xf0014
+#define DP_LTTPR_TRAINING_AUX_RD_INTERVAL_REPEATER1   0xf0020
+#define DP_LTTPR_TRANSMITTER_CAPABILITY_REPEATER1 0xf0021
+#define DP_LTTPR_LANE0_1_STATUS_REPEATER1 0xf0030
+#define DP_LTTPR_LANE2_3_STATUS_REPEATER1 0xf0031
+#define DP_LTTPR_LANE_ALIGN_STATUS_UPDATED_REPEATER1  0xf0032
+#define DP_LTTPR_ADJUST_REQUEST_LANE0_1_REPEATER1 0xf0033
+#define DP_LTTPR_ADJUST_REQUEST_LANE2_3_REPEATER1 0xf0034
+#define DP_LTTPR_SYMBOL_ERROR_COUNT_LANE0_REPEATER1   0xf0035
+#define DP_LTTPR_SYMBOL_ERROR_COUNT_LANE1_REPEATER1   0xf0037
+#define DP_LTTPR_SYMBOL_ERROR_COUNT_LANE2_REPEATER1   0xf0039
+#define DP_LTTPR_SYMBOL_ERROR_COUNT_LANE3_REPEATER1   0xf003b
+#define DP_REPEATER_CONFIGURATION_AND_STATUS_OFFSET   0x50
+#define DP_LTTPR_FEC_STATUS_REPEATER1 0xf0290
+
 /* Multiple stream transport */
 #define DP_FAUX_CAP0x020   /* 1.2 */
 # define DP_FAUX_CAP_1 (1 << 0)
-- 
2.23.0


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

Re: [PATCH] drm/syncobj: Add documentation for timeline syncobj

2019-08-22 Thread Lionel Landwerlin

On 22/08/2019 21:24, Jason Ekstrand wrote:
On Thu, Aug 22, 2019 at 9:55 AM Lionel Landwerlin 
mailto:lionel.g.landwer...@intel.com>> 
wrote:


We've added a set of new APIs to manipulate syncobjs holding timelines
of dma_fence. This adds a bit of documentation about how this works.

Signed-off-by: Lionel Landwerlin mailto:lionel.g.landwer...@intel.com>>
Cc: Christian Koenig mailto:christian.koe...@amd.com>>
Cc: Jason Ekstrand mailto:ja...@jlekstrand.net>>
Cc: David(ChunMing) Zhou mailto:david1.z...@amd.com>>
---
 drivers/gpu/drm/drm_syncobj.c | 87
+--
 1 file changed, 74 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index b5ad73330a48..32ffded6d2c0 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -43,27 +43,66 @@
  *  - Signal a syncobj (set a trivially signaled fence)
  *  - Wait for a syncobj's fence to appear and be signaled
  *
+ * The syncobj userspace API also provides operations to
manipulate a syncobj
+ * in terms of a timeline of struct _fence rather than a
single struct
+ * _fence, through the following operations:
+ *
+ *   - Signal a given point on the timeline
+ *   - Wait for a given point to appear and/or be signaled
+ *   - Import and export from/to a given point of a timeline
+ *
  * At it's core, a syncobj is simply a wrapper around a pointer
to a struct
  * _fence which may be NULL.
  * When a syncobj is first created, its pointer is either NULL or
a pointer
  * to an already signaled fence depending on whether the
  * _SYNCOBJ_CREATE_SIGNALED flag is passed to
  * _IOCTL_SYNCOBJ_CREATE.
- * When GPU work which signals a syncobj is enqueued in a DRM driver,
- * the syncobj fence is replaced with a fence which will be
signaled by the
- * completion of that work.
- * When GPU work which waits on a syncobj is enqueued in a DRM
driver, the
- * driver retrieves syncobj's current fence at the time the work
is enqueued
- * waits on that fence before submitting the work to hardware.
- * If the syncobj's fence is NULL, the enqueue operation is
expected to fail.
- * All manipulation of the syncobjs's fence happens in terms of
the current
- * fence at the time the ioctl is called by userspace regardless
of whether
- * that operation is an immediate host-side operation (signal or
reset) or
- * or an operation which is enqueued in some driver queue.
- * _IOCTL_SYNCOBJ_RESET and _IOCTL_SYNCOBJ_SIGNAL can be
used to
- * manipulate a syncobj from the host by resetting its pointer to
NULL or
+ *
+ * If the syncobj is considered as a binary (signal/unsignaled)
primitive,


What does "considered as a binary" mean?  Is it an inherent property 
of the syncobj given at create time?  Is it a state the syncobj can be 
in?  Or is it a property of how the submit ioctl in the DRM driver 
references it?  I'm really hoping it's either 1 or 3



3: you either use it binary/legacy apis, or timeline apis. timeline apis 
also provide some binary compatibility with the point 0 (in particular 
for wait).




+ * when GPU work is enqueued in a DRM driver to signal the
syncobj, the fence
+ * is replaced with a fence which will be signaled by the
completion of that
+ * work.
+ * If the syncobj is considered as a timeline primitive, when GPU
work is
+ * enqueued in a DRM driver to signal the a given point of the
syncobj, a new
+ * struct _fence_chain pointing to the DRM driver's fence and
also
+ * pointing to the previous fence that was in the syncobj. The
new struct
+ * _fence_chain fence put into the syncobj will be signaled
by completion
+ * of the DRM driver's work and also any work associated with the
fence
+ * previously in the syncobj.
+ *
+ * When GPU work which waits on a syncobj is enqueued in a DRM
driver, at the
+ * time the work is enqueued, it waits on the fence coming from
the syncobj
+ * before submitting the work to hardware. That fence is either :
+ *
+ *    - The syncobj's current fence if the syncobj is considered
as a binary
+ *      primitive.
+ *    - The struct _fence associated with a given point if
the syncobj is
+ *      considered as a timeline primitive.
+ *
+ * If the syncobj's fence is NULL or not present in the syncobj's
timeline,
+ * the enqueue operation is expected to fail.
+ *
+ * With binary syncobj, all manipulation of the syncobjs's fence
happens in
+ * terms of the current fence at the time the ioctl is called by
userspace
+ * regardless of whether that operation is an immediate host-side
operation
+ * (signal or reset) or or an operation which 

Re: linux-next: build warning after merge of the drm-fixes tree

2019-08-22 Thread Alex Deucher
On Thu, Aug 22, 2019 at 6:06 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the drm-fixes tree, today's linux-next build (KCONFIG_NAME)
> produced this warning:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function 
> 'smu_v11_0_setup_pptable':
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:368:40: warning: 'size' 
> may be used uninitialized in this function [-Wmaybe-uninitialized]
>smu->smu_table.power_play_table_size = size;
>~^~
>
> Introduced by commit
>
>   00430144ff73 ("drm/amd/powerplay: fix variable type errors in 
> smu_v11_0_setup_pptable")
>
> Looks like a false positive.

Silenced here:
https://patchwork.freedesktop.org/patch/325728/

Alex

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


linux-next: build warning after merge of the drm-fixes tree

2019-08-22 Thread Stephen Rothwell
Hi all,

After merging the drm-fixes tree, today's linux-next build (KCONFIG_NAME)
produced this warning:

drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function 
'smu_v11_0_setup_pptable':
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:368:40: warning: 'size' may 
be used uninitialized in this function [-Wmaybe-uninitialized]
   smu->smu_table.power_play_table_size = size;
   ~^~

Introduced by commit

  00430144ff73 ("drm/amd/powerplay: fix variable type errors in 
smu_v11_0_setup_pptable")

Looks like a false positive.

-- 
Cheers,
Stephen Rothwell


pgpQGhfPiC2Tj.pgp
Description: OpenPGP digital signature


Re: [PATCH v4 4/5] drm/dp-mst: Fill branch->num_ports

2019-08-22 Thread Lyude Paul
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> This field on drm_dp_mst_branch was never filled
> 
> Initialize it to zero when the list of ports is created.
> When a port is added to the list, increment num_ports,
> and when a port is removed from the list, decrement num_ports.
> 
> v2: remember to decrement on port removal
> 
> Signed-off-by: David Francis 
> Reviewed-by: Lyude Paul 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 50a044718439..af4b5cec7c84 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -919,6 +919,7 @@ static struct drm_dp_mst_branch
> *drm_dp_add_mst_branch_device(u8 lct, u8 *rad)
>   INIT_LIST_HEAD(>ports);
>   kref_init(>topology_kref);
>   kref_init(>malloc_kref);
> + mstb->num_ports = 0;

Just realized as well, we can drop the mstb->num_ports = 0; here, since we're
allocating the struct with kzalloc()

>   return mstb;
>  }
>  
> @@ -1669,6 +1670,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
> *mstb,
>   mutex_lock(>mgr->lock);
>   drm_dp_mst_topology_get_port(port);
>   list_add(>next, >ports);
> + mstb->num_ports++;
>   mutex_unlock(>mgr->lock);
>   }
>  
> @@ -1703,6 +1705,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
> *mstb,
>   /* remove it from the port list */
>   mutex_lock(>mgr->lock);
>   list_del(>next);
> + mstb->num_ports--;
>   mutex_unlock(>mgr->lock);
>   /* drop port list reference */
>   drm_dp_mst_topology_put_port(port);
-- 
Cheers,
Lyude Paul

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

Re: [PATCH v4 3/5] drm/dp-mst: Add MST support to DP DPCD R/W functions

2019-08-22 Thread Lyude Paul
Mhhh, one last nitpick

On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> Instead of having drm_dp_dpcd_read/write and
> drm_dp_mst_dpcd_read/write as entry points into the
> aux code, have drm_dp_dpcd_read/write handle both.
> 
> This means that DRM drivers can make MST DPCD read/writes.
> 
> v2: Fix spacing
> 
> Cc: Leo Li 
> Cc: Lyude Paul 
> Signed-off-by: David Francis 
> ---
>  drivers/gpu/drm/drm_dp_aux_dev.c | 12 ++--
>  drivers/gpu/drm/drm_dp_helper.c  | 10 --
>  2 files changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c
> b/drivers/gpu/drm/drm_dp_aux_dev.c
> index 0cfb386754c3..418cad4f649a 100644
> --- a/drivers/gpu/drm/drm_dp_aux_dev.c
> +++ b/drivers/gpu/drm/drm_dp_aux_dev.c
> @@ -163,11 +163,7 @@ static ssize_t auxdev_read_iter(struct kiocb *iocb,
> struct iov_iter *to)
>   break;
>   }
>  
> - if (aux_dev->aux->is_remote)
> - res = drm_dp_mst_dpcd_read(aux_dev->aux, pos, buf,
> -todo);
> - else
> - res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
> + res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
>  
>   if (res <= 0)
>   break;
> @@ -215,11 +211,7 @@ static ssize_t auxdev_write_iter(struct kiocb *iocb,
> struct iov_iter *from)
>   break;
>   }
>  
> - if (aux_dev->aux->is_remote)
> - res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf,
> - todo);
> - else
> - res = drm_dp_dpcd_write(aux_dev->aux, pos, buf, todo);
> + res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf, todo);
>  
>   if (res <= 0)
>   break;
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index ffc68d305afe..b1599760b6a3 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -30,6 +30,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -251,7 +252,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
>  
>  /**
>   * drm_dp_dpcd_read() - read a series of bytes from the DPCD
> - * @aux: DisplayPort AUX channel
> + * @aux: DisplayPort AUX channel (SST or MST)
>   * @offset: address of the (first) register to read
>   * @buffer: buffer to store the register values
>   * @size: number of bytes in @buffer
> @@ -268,6 +269,8 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux,
> unsigned int offset,
>  {
>   int ret;
>  
> + if (aux->is_remote)
> + return drm_dp_mst_dpcd_read(aux, offset, buffer, size);

Let's actually replace this with

if (aux->is_remote)
ret = drm_dp_mst_dpcd_read(aux, offset, buffer, size);
else
ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer,
 size);

That way we still call drm_dp_dump_access() so that we can log the DPCD read
to the kernel log.

Let's also add a space down here ⬇...
>   /*
>* HP ZR24w corrupts the first DPCD access after entering power save
>* mode. Eg. on a read, the entire buffer will be filled with the same
> @@ -296,7 +299,7 @@ EXPORT_SYMBOL(drm_dp_dpcd_read);
>  
>  /**
>   * drm_dp_dpcd_write() - write a series of bytes to the DPCD
> - * @aux: DisplayPort AUX channel
> + * @aux: DisplayPort AUX channel (SST or MST)
>   * @offset: address of the (first) register to write
>   * @buffer: buffer containing the values to write
>   * @size: number of bytes in @buffer
> @@ -313,6 +316,9 @@ ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux,
> unsigned int offset,
>  {
>   int ret;
>  
> + if (aux->is_remote)
> + return drm_dp_mst_dpcd_write(aux, offset, buffer, size);
> +

...and do the same thing with drm_dp_dpcd_write() that we did with
drm_dp_dpcd_read()

With those changes, this patch is:

Reviewed-by: Lyude Paul 
>   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer,
>size);
>   drm_dp_dump_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer, ret);
-- 
Cheers,
Lyude Paul

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

[PATCH] drm/drm_connector: add additional aspect ratio values

2019-08-22 Thread Wayne Lin
For HDMI2.0 CTS item - HF1-35, it verifies if the source generates
video timing "64:27" video format correctly.

eg: (vic-76) 1920x1080p@60Hz,24bpp

This patch add on "64:27" and "256:135" to drm_aspect_ratio_enum_list.
Thereafter, one can specify the aspect ratio to "64:27" or "256:135"
after creating aspect ratio property.

Change-Id: Ifc9df54e8e8f78e70960fcd737a3a57e49c81152
Signed-off-by: Wayne Lin 
---
 drivers/gpu/drm/drm_connector.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 3a0cacb71235..c0629a01d08e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -772,6 +772,8 @@ static const struct drm_prop_enum_list 
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
+   { DRM_MODE_PICTURE_ASPECT_64_27, "64:27" },
+   { DRM_MODE_PICTURE_ASPECT_256_135, "256:135" },
 };
 
 static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
-- 
2.17.1

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

Re: [PATCH v4 1/5] drm/dp-mst: Add PBN calculation for DSC modes

2019-08-22 Thread Lyude Paul
Agh, sorry to go back on this - I'm noticing a lot more changes we should have
now that I've been able apply this locally to my tree. See below:

On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> With DSC, bpp can be a multiple of 1/16, so
> drm_dp_calc_pbn_mode is insufficient.
> 
> Add drm_dp_calc_pbn_mode_dsc, a function which is
> the same as drm_dp_calc_pbn_mode, but the bpp is
> in units of 1/16.
> 
> Reviewed-by: Lyude Paul 
> Signed-off-by: David Francis 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 43 +++
>  include/drm/drm_dp_mst_helper.h   |  2 +-
>  2 files changed, 44 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 82add736e17d..8e2e731c35c5 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3591,6 +3591,49 @@ static int test_calc_pbn_mode(void)
>   return 0;
>  }
>  
> +/**
> + * drm_dp_calc_pbn_mode_dsc() - Calculate the PBN for a mode with DSC
> enabled.
> + * @clock: dot clock for the mode
> + * @dsc_bpp: dsc bits per pixel x16 (e.g. dsc_bpp = 136 is 8.5 bpp)
> + *
> + * This uses the formula in the spec to calculate the PBN value for a mode,
> + * given that the mode is using DSC
> + * Returns:
> + * PBN required for this mode
> + */
> +int drm_dp_calc_pbn_mode_dsc(int clock, int dsc_bpp)
> +{
> + u64 kbps;
> + s64 peak_kbps;
> + u32 numerator;
> + u32 denominator;
> +
> + kbps = clock * dsc_bpp;
> +
> + /*
> +  * margin 5300ppm + 300ppm ~ 0.6% as per spec, factor is 1.006
> +  * The unit of 54/64Mbytes/sec is an arbitrary unit chosen based on
> +  * common multiplier to render an integer PBN for all link rate/lane
> +  * counts combinations
> +  * calculate
> +  * peak_kbps *= (1/16) bppx16 to bpp
> +  * peak_kbps *= (1006/1000)
> +  * peak_kbps *= (64/54)
> +  * peak_kbps *= 8convert to bytes
> +  *
> +  * Divide numerator and denominator by 16 to avoid overflow
> +  */
> +
> + numerator = 64 * 1006 / 16;
> + denominator = 54 * 8 * 1000 * 1000;
> +
> + kbps *= numerator;
> + peak_kbps = drm_fixp_from_fraction(kbps, denominator);
> +
> + return drm_fixp2int_ceil(peak_kbps);
> +}
> +EXPORT_SYMBOL(drm_dp_calc_pbn_mode_dsc);

I didn't notice until now that the only difference between the two functions
is

numerator = 64 * 1006 / 16;

So it doesn't seem like it's worth having two seperate functions for this, so
let's just get rid of drm_dp_calc_pbn_mode_dsc() and combine it with
drm_dp_calc_pbn_mode() by adding a bool parameter to specify whether or not
we're calculating for dsc

> +
>  /* we want to kick the TX after we've ack the up/down IRQs. */
>  static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr)
>  {
> diff --git a/include/drm/drm_dp_mst_helper.h
> b/include/drm/drm_dp_mst_helper.h
> index 2ba6253ea6d3..ddb518f2157a 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -611,7 +611,7 @@ struct edid *drm_dp_mst_get_edid(struct drm_connector
> *connector, struct drm_dp_
>  
>  
>  int drm_dp_calc_pbn_mode(int clock, int bpp);
> -
> +int drm_dp_calc_pbn_mode_dsc(int clock, int dsc_bpp);
>  
>  bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr,
> struct drm_dp_mst_port *port, int pbn, int
> slots);
-- 
Cheers,
Lyude Paul

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

Re: [PATCH v4 0/5] MST DSC support in drm-mst

2019-08-22 Thread Lyude Paul
Still in the process of reviewing this, but one minor change that should be
done on all of the patches (which I didn't notice before, whoops):

s:drm/dp-mst:drm/dp_mst:g

On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> Add necessary support for MST DSC.
> (Display Stream COmpression over Multi-Stream Transport)
> 
> v4: Split patchset and rebase onto drm-tip
> 
> David Francis (5):
>   drm/dp-mst: Add PBN calculation for DSC modes
>   drm/dp-mst: Parse FEC capability on MST ports
>   drm/dp-mst: Add MST support to DP DPCD R/W functions
>   drm/dp-mst: Fill branch->num_ports
>   drm/dp-mst: Add helpers for querying and enabling MST DSC
> 
>  drivers/gpu/drm/drm_dp_aux_dev.c  |  12 +-
>  drivers/gpu/drm/drm_dp_helper.c   |  10 +-
>  drivers/gpu/drm/drm_dp_mst_topology.c | 243 ++
>  include/drm/drm_dp_mst_helper.h   |   8 +-
>  4 files changed, 260 insertions(+), 13 deletions(-)
> 
-- 
Cheers,
Lyude Paul

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

[PATCH] drm/mcde: Fix an error handling path in 'mcde_probe()'

2019-08-22 Thread Christophe JAILLET
If we don't find any matching components, we should go through the error
handling path, in order to free some resources.

Fixes: ca5be902a87d ("drm/mcde: Fix uninitialized variable")
Signed-off-by: Christophe JAILLET 
---
 drivers/gpu/drm/mcde/mcde_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index 9a09eba53182..5649887d2b90 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -484,7 +484,8 @@ static int mcde_probe(struct platform_device *pdev)
}
if (!match) {
dev_err(dev, "no matching components\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto clk_disable;
}
if (IS_ERR(match)) {
dev_err(dev, "could not create component match\n");
-- 
2.20.1



Re: [PATCH][drm-next] drm/amd/display: fix a potential null pointer dereference

2019-08-22 Thread Alex Deucher
On Thu, Aug 22, 2019 at 3:21 PM Harry Wentland  wrote:
>
> On 2019-08-16 6:10 p.m., Colin King wrote:
> > From: Colin Ian King 
> >
> > Currently the pointer init_data is dereferenced on the assignment
> > of fw_info before init_data is sanity checked to see if it is null.
> > Fix te potential null pointer dereference on init_data by only
> > performing dereference after it is null checked.
> >
> > Addresses-Coverity: ("Dereference before null check")
> > Fixes: 9adc8050bf3c ("drm/amd/display: make firmware info only load once 
> > during dc_bios create")
> > Signed-off-by: Colin Ian King 
>
> Reviewed-by: Harry Wentland 
>

Applied.  Thanks!

Alex

> Harry
>
> > ---
> >  drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c 
> > b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> > index bee81bf288be..926954c804a6 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> > @@ -1235,7 +1235,7 @@ static bool calc_pll_max_vco_construct(
> >   struct calc_pll_clock_source_init_data *init_data)
> >  {
> >   uint32_t i;
> > - struct dc_firmware_info *fw_info = _data->bp->fw_info;
> > + struct dc_firmware_info *fw_info;
> >   if (calc_pll_cs == NULL ||
> >   init_data == NULL ||
> >   init_data->bp == NULL)
> > @@ -1244,6 +1244,7 @@ static bool calc_pll_max_vco_construct(
> >   if (init_data->bp->fw_info_valid)
> >   return false;
> >
> > + fw_info = _data->bp->fw_info;
> >   calc_pll_cs->ctx = init_data->ctx;
> >   calc_pll_cs->ref_freq_khz = fw_info->pll_info.crystal_frequency;
> >   calc_pll_cs->min_vco_khz =
> >
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu/powerplay: remove redundant assignment to variable baco_state

2019-08-22 Thread Alex Deucher
On Thu, Aug 22, 2019 at 9:09 AM Colin King  wrote:
>
> From: Colin Ian King 
>
> Variable baco_state is initialized to a value that is never read and it is
> re-assigned later. The initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused Value")
> Signed-off-by: Colin Ian King 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c 
> b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> index 89749b1d2019..a4aba8576900 100644
> --- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> +++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> @@ -1656,7 +1656,7 @@ static bool smu_v11_0_baco_is_support(struct 
> smu_context *smu)
>  static enum smu_baco_state smu_v11_0_baco_get_state(struct smu_context *smu)
>  {
> struct smu_baco_context *smu_baco = >smu_baco;
> -   enum smu_baco_state baco_state = SMU_BACO_STATE_EXIT;
> +   enum smu_baco_state baco_state;
>
> mutex_lock(_baco->mutex);
> baco_state = smu_baco->state;
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] drm/i915: Call dma_set_max_seg_size() in i915_ggtt_probe_hw()

2019-08-22 Thread Lyude Paul
Currently, we don't call dma_set_max_seg_size() for i915 because we
intentionally do not limit the segment length that the device supports.
However, this results in a warning being emitted if we try to map
anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG
enabled:

[7.751926] DMA-API: i915 :00:02.0: mapping sg segment longer
than device claims to support [len=98304] [max=65536]
[7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220
debug_dma_map_sg+0x20f/0x340

This was originally brought up on
https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus
there was it wasn't really useful to set a limit (and that dma-debug
isn't really all that useful for i915 in the first place). Unfortunately
though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for
various distro kernels. Since a WARN_ON() will disable automatic problem
reporting (and cause any CI with said option enabled to start
complaining), we really should just fix the problem.

Note that as me and Chris Wilson discussed, the other solution for this
would be to make DMA-API not make such assumptions when a driver hasn't
explicitly set a maximum segment size. But, taking a look at the commit
which originally introduced this behavior, commit 78c47830a5cb
("dma-debug: check scatterlist segments"), there is an explicit mention
of this assumption and how it applies to devices with no segment size:

Conversely, devices which are less limited than the rather
conservative defaults, or indeed have no limitations at all
(e.g. GPUs with their own internal MMU), should be encouraged to
set appropriate dma_parms, as they may get more efficient DMA
mapping performance out of it.

So unless there's any concerns (I'm open to discussion!), let's just
follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit
to silence any warnings.

Signed-off-by: Lyude Paul 
Cc: Chris Wilson 
Cc:  # v4.18+
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 0b81e0b64393..a1475039d182 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3152,6 +3152,11 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct 
intel_gt *gt)
if (ret)
return ret;
 
+   /* We don't have a max segment size, so set it to the max so sg's
+* debugging layer doesn't complain
+*/
+   dma_set_max_seg_size(ggtt->vm.dma, UINT_MAX);
+
if ((ggtt->vm.total - 1) >> 32) {
DRM_ERROR("We never expected a Global GTT with more than 32bits"
  " of address space! Found %lldM!\n",
-- 
2.21.0



[PATCH v2 2/2] drm/i915: Enable CONFIG_DMA_API_DEBUG_SG for intel-ci

2019-08-22 Thread Lyude Paul
Now that we've fixed i915 so that it sets a max SG segment length and
gotten rid of the relevant warnings, let's enable
CONFIG_DMA_API_DEBUG_SG for intel-ci so that we can catch issues like
this in the future as well.

Signed-off-by: Lyude Paul 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/Kconfig.debug | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 00786a142ff0..ad8d3cd63c9f 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -32,6 +32,7 @@ config DRM_I915_DEBUG
select DRM_DEBUG_SELFTEST
select DMABUF_SELFTESTS
select SW_SYNC # signaling validation framework (igt/syncobj*)
+select DMA_API_DEBUG_SG
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
select DRM_I915_SELFTEST
select DRM_I915_DEBUG_RUNTIME_PM
-- 
2.21.0



Re: [PATCH] drm/i915: Call dma_set_max_seg_size() in i915_ggtt_probe_hw()

2019-08-22 Thread Lyude Paul
...whoops.

Ignore this patch-Chris Wilson had requested that I send a patch along with
this one to enable CONFIG_DMA_API_DEBUG_SG in CI, but I completely forgot to
do that before sending. Will send out a reroll with that in just a moment

On Thu, 2019-08-22 at 16:04 -0400, Lyude Paul wrote:
> Currently, we don't call dma_set_max_seg_size() for i915 because we
> intentionally do not limit the segment length that the device supports.
> However, this results in a warning being emitted if we try to map
> anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG
> enabled:
> 
> [7.751926] DMA-API: i915 :00:02.0: mapping sg segment longer
> than device claims to support [len=98304] [max=65536]
> [7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220
> debug_dma_map_sg+0x20f/0x340
> 
> This was originally brought up on
> https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus
> there was it wasn't really useful to set a limit (and that dma-debug
> isn't really all that useful for i915 in the first place). Unfortunately
> though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for
> various distro kernels. Since a WARN_ON() will disable automatic problem
> reporting (and cause any CI with said option enabled to start
> complaining), we really should just fix the problem.
> 
> Note that as me and Chris Wilson discussed, the other solution for this
> would be to make DMA-API not make such assumptions when a driver hasn't
> explicitly set a maximum segment size. But, taking a look at the commit
> which originally introduced this behavior, commit 78c47830a5cb
> ("dma-debug: check scatterlist segments"), there is an explicit mention
> of this assumption and how it applies to devices with no segment size:
> 
>   Conversely, devices which are less limited than the rather
>   conservative defaults, or indeed have no limitations at all
>   (e.g. GPUs with their own internal MMU), should be encouraged to
>   set appropriate dma_parms, as they may get more efficient DMA
>   mapping performance out of it.
> 
> So unless there's any concerns (I'm open to discussion!), let's just
> follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit
> to silence any warnings.
> 
> Signed-off-by: Lyude Paul 
> Cc: Chris Wilson 
> Cc:  # v4.18+
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 0b81e0b64393..a1475039d182 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3152,6 +3152,11 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt,
> struct intel_gt *gt)
>   if (ret)
>   return ret;
>  
> + /* We don't have a max segment size, so set it to the max so sg's
> +  * debugging layer doesn't complain
> +  */
> + dma_set_max_seg_size(ggtt->vm.dma, UINT_MAX);
> +
>   if ((ggtt->vm.total - 1) >> 32) {
>   DRM_ERROR("We never expected a Global GTT with more than
> 32bits"
> " of address space! Found %lldM!\n",
-- 
Cheers,
Lyude Paul

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

[PATCH] drm/i915: Call dma_set_max_seg_size() in i915_ggtt_probe_hw()

2019-08-22 Thread Lyude Paul
Currently, we don't call dma_set_max_seg_size() for i915 because we
intentionally do not limit the segment length that the device supports.
However, this results in a warning being emitted if we try to map
anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG
enabled:

[7.751926] DMA-API: i915 :00:02.0: mapping sg segment longer
than device claims to support [len=98304] [max=65536]
[7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220
debug_dma_map_sg+0x20f/0x340

This was originally brought up on
https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus
there was it wasn't really useful to set a limit (and that dma-debug
isn't really all that useful for i915 in the first place). Unfortunately
though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for
various distro kernels. Since a WARN_ON() will disable automatic problem
reporting (and cause any CI with said option enabled to start
complaining), we really should just fix the problem.

Note that as me and Chris Wilson discussed, the other solution for this
would be to make DMA-API not make such assumptions when a driver hasn't
explicitly set a maximum segment size. But, taking a look at the commit
which originally introduced this behavior, commit 78c47830a5cb
("dma-debug: check scatterlist segments"), there is an explicit mention
of this assumption and how it applies to devices with no segment size:

Conversely, devices which are less limited than the rather
conservative defaults, or indeed have no limitations at all
(e.g. GPUs with their own internal MMU), should be encouraged to
set appropriate dma_parms, as they may get more efficient DMA
mapping performance out of it.

So unless there's any concerns (I'm open to discussion!), let's just
follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit
to silence any warnings.

Signed-off-by: Lyude Paul 
Cc: Chris Wilson 
Cc:  # v4.18+
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 0b81e0b64393..a1475039d182 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3152,6 +3152,11 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct 
intel_gt *gt)
if (ret)
return ret;
 
+   /* We don't have a max segment size, so set it to the max so sg's
+* debugging layer doesn't complain
+*/
+   dma_set_max_seg_size(ggtt->vm.dma, UINT_MAX);
+
if ((ggtt->vm.total - 1) >> 32) {
DRM_ERROR("We never expected a Global GTT with more than 32bits"
  " of address space! Found %lldM!\n",
-- 
2.21.0

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

Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression

2019-08-22 Thread Dave Airlie
On Fri, 23 Aug 2019 at 03:25, Thomas Zimmermann  wrote:
>
> Hi
>
> I was traveling and could reply earlier. Sorry for taking so long.
>
> Am 13.08.19 um 11:36 schrieb Feng Tang:
> > Hi Thomas,
> >
> > On Mon, Aug 12, 2019 at 03:25:45PM +0800, Feng Tang wrote:
> >> Hi Thomas,
> >>
> >> On Fri, Aug 09, 2019 at 04:12:29PM +0800, Rong Chen wrote:
> >>> Hi,
> >>>
> > Actually we run the benchmark as a background process, do we need to
> > disable the cursor and test again?
>  There's a worker thread that updates the display from the shadow buffer.
>  The blinking cursor periodically triggers the worker thread, but the
>  actual update is just the size of one character.
> 
>  The point of the test without output is to see if the regression comes
> >>> >from the buffer update (i.e., the memcpy from shadow buffer to VRAM), or
> >>> >from the worker thread. If the regression goes away after disabling the
>  blinking cursor, then the worker thread is the problem. If it already
>  goes away if there's simply no output from the test, the screen update
>  is the problem. On my machine I have to disable the blinking cursor, so
>  I think the worker causes the performance drop.
> >>>
> >>> We disabled redirecting stdout/stderr to /dev/kmsg,  and the regression is
> >>> gone.
> >>>
> >>> commit:
> >>>   f1f8555dfb9 drm/bochs: Use shadow buffer for bochs framebuffer console
> >>>   90f479ae51a drm/mgag200: Replace struct mga_fbdev with generic 
> >>> framebuffer
> >>> emulation
> >>>
> >>> f1f8555dfb9a70a2  90f479ae51afa45efab97afdde testcase/testparams/testbox
> >>>   -- ---
> >>>  %stddev  change %stddev
> >>>  \  |\
> >>>  43785   44481
> >>> vm-scalability/300s-8T-anon-cow-seq-hugetlb/lkp-knm01
> >>>  43785   44481GEO-MEAN 
> >>> vm-scalability.median
> >>
> >> Till now, from Rong's tests:
> >> 1. Disabling cursor blinking doesn't cure the regression.
> >> 2. Disabling printint test results to console can workaround the
> >> regression.
> >>
> >> Also if we set the perfer_shadown to 0, the regression is also
> >> gone.
> >
> > We also did some further break down for the time consumed by the
> > new code.
> >
> > The drm_fb_helper_dirty_work() calls sequentially
> > 1. drm_client_buffer_vmap   (290 us)
> > 2. drm_fb_helper_dirty_blit_real  (19240 us)
> > 3. helper->fb->funcs->dirty()---> NULL for mgag200 driver
> > 4. drm_client_buffer_vunmap   (215 us)
> >
>
> It's somewhat different to what I observed, but maybe I just couldn't
> reproduce the problem correctly.
>
> > The average run time is listed after the function names.
> >
> > From it, we can see drm_fb_helper_dirty_blit_real() takes too long
> > time (about 20ms for each run). I guess this is the root cause
> > of this regression, as the original code doesn't use this dirty worker.
>
> True, the original code uses a temporary buffer, but updates the display
> immediately.
>
> My guess is that this could be a caching problem. The worker runs on a
> different CPU, which doesn't have the shadow buffer in cache.
>
> > As said in last email, setting the prefer_shadow to 0 can avoid
> > the regrssion. Could it be an option?
>
> Unfortunately not. Without the shadow buffer, the console's display
> buffer permanently resides in video memory. It consumes significant
> amount of that memory (say 8 MiB out of 16 MiB). That doesn't leave
> enough room for anything else.
>
> The best option is to not print to the console.

Wait a second, I thought the driver did an eviction on modeset of the
scanned out object, this was a deliberate design decision made when
writing those drivers, has this been removed in favour of gem and
generic code paths?

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

Re: [PATCH v2 19/19] drm: rcar-du: kms: Update CMM in atomic commit tail

2019-08-22 Thread Laurent Pinchart
Hi Jacopo,

On Thu, Aug 22, 2019 at 09:19:25PM +0200, Jacopo Mondi wrote:
> On Tue, Aug 20, 2019 at 09:42:15PM +0300, Laurent Pinchart wrote:
> > On Sat, Jul 06, 2019 at 04:07:46PM +0200, Jacopo Mondi wrote:
> > > Update CMM settings at in the atomic commit tail helper method.
> > >
> > > The CMM is updated with new gamma values provided to the driver
> > > in the GAMMA_LUT blob property.
> > >
> > > Signed-off-by: Jacopo Mondi 
> > > ---
> > >  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 35 +++
> > >  1 file changed, 35 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> > > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > index b79cda2f5531..f9aece78ca5f 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > @@ -21,6 +21,7 @@
> > >  #include 
> > >  #include 
> > >
> > > +#include "rcar_cmm.h"
> > >  #include "rcar_du_crtc.h"
> > >  #include "rcar_du_drv.h"
> > >  #include "rcar_du_encoder.h"
> > > @@ -287,6 +288,37 @@ rcar_du_fb_create(struct drm_device *dev, struct 
> > > drm_file *file_priv,
> > >   * Atomic Check and Update
> > >   */
> > >
> > > +static void rcar_du_atomic_commit_update_cmm(struct drm_crtc *crtc,
> > > +  struct drm_crtc_state *old_state)
> > > +{
> > > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > > + struct rcar_cmm_config cmm_config = {};
> > > +
> > > + if (!rcrtc->cmm || !crtc->state->color_mgmt_changed)
> > > + return;
> > > +
> > > + if (!crtc->state->gamma_lut) {
> > > + cmm_config.lut.enable = false;
> > > + rcar_cmm_setup(rcrtc->cmm, _config);
> > > +
> > > + return;
> > > + }
> > > +
> > > + cmm_config.lut.enable = true;
> > > + cmm_config.lut.table = (struct drm_color_lut *)
> > > +crtc->state->gamma_lut->data;
> > > +
> > > + /* Set LUT table size to 0 if entries should not be updated. */
> > > + if (!old_state->gamma_lut ||
> > > + old_state->gamma_lut->base.id != crtc->state->gamma_lut->base.id)
> > > + cmm_config.lut.size = crtc->state->gamma_lut->length
> > > + / sizeof(cmm_config.lut.table[0]);
> > > + else
> > > + cmm_config.lut.size = 0;
> > > +
> > > + rcar_cmm_setup(rcrtc->cmm, _config);
> > > +}
> > > +
> > >  static int rcar_du_atomic_check(struct drm_device *dev,
> > >   struct drm_atomic_state *state)
> > >  {
> > > @@ -329,6 +361,9 @@ static void rcar_du_atomic_commit_tail(struct 
> > > drm_atomic_state *old_state)
> > >   rcdu->dpad1_source = rcrtc->index;
> > >   }
> > >
> > > + for_each_old_crtc_in_state(old_state, crtc, crtc_state, i)
> > > + rcar_du_atomic_commit_update_cmm(crtc, crtc_state);
> > > +
> >
> > I think this looks good overall, but I wonder if we couldn't simplify
> > the CMM driver suspend/resume and LUT caching due to config while not
> > enabled by handling it on the DU side. I have a rework on the commit
> > tail handler in progress, I'll think how this could be done. For now I
> > think you can leave it as is.
> 
> Does this mean I have your R-b tag ? :)

I'd like to review this in the context of v3 :-)

> > >   /* Apply the atomic update. */
> > >   drm_atomic_helper_commit_modeset_disables(dev, old_state);
> > >   drm_atomic_helper_commit_planes(dev, old_state,

-- 
Regards,

Laurent Pinchart


Re: [PATCH] drm/syncobj: Add documentation for timeline syncobj

2019-08-22 Thread Jason Ekstrand
On Thu, Aug 22, 2019 at 9:55 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> We've added a set of new APIs to manipulate syncobjs holding timelines
> of dma_fence. This adds a bit of documentation about how this works.
>
> Signed-off-by: Lionel Landwerlin 
> Cc: Christian Koenig 
> Cc: Jason Ekstrand 
> Cc: David(ChunMing) Zhou 
> ---
>  drivers/gpu/drm/drm_syncobj.c | 87 +--
>  1 file changed, 74 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index b5ad73330a48..32ffded6d2c0 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -43,27 +43,66 @@
>   *  - Signal a syncobj (set a trivially signaled fence)
>   *  - Wait for a syncobj's fence to appear and be signaled
>   *
> + * The syncobj userspace API also provides operations to manipulate a
> syncobj
> + * in terms of a timeline of struct _fence rather than a single struct
> + * _fence, through the following operations:
> + *
> + *   - Signal a given point on the timeline
> + *   - Wait for a given point to appear and/or be signaled
> + *   - Import and export from/to a given point of a timeline
> + *
>   * At it's core, a syncobj is simply a wrapper around a pointer to a
> struct
>   * _fence which may be NULL.
>   * When a syncobj is first created, its pointer is either NULL or a
> pointer
>   * to an already signaled fence depending on whether the
>   * _SYNCOBJ_CREATE_SIGNALED flag is passed to
>   * _IOCTL_SYNCOBJ_CREATE.
> - * When GPU work which signals a syncobj is enqueued in a DRM driver,
> - * the syncobj fence is replaced with a fence which will be signaled by
> the
> - * completion of that work.
> - * When GPU work which waits on a syncobj is enqueued in a DRM driver, the
> - * driver retrieves syncobj's current fence at the time the work is
> enqueued
> - * waits on that fence before submitting the work to hardware.
> - * If the syncobj's fence is NULL, the enqueue operation is expected to
> fail.
> - * All manipulation of the syncobjs's fence happens in terms of the
> current
> - * fence at the time the ioctl is called by userspace regardless of
> whether
> - * that operation is an immediate host-side operation (signal or reset) or
> - * or an operation which is enqueued in some driver queue.
> - * _IOCTL_SYNCOBJ_RESET and _IOCTL_SYNCOBJ_SIGNAL can be used to
> - * manipulate a syncobj from the host by resetting its pointer to NULL or
> + *
> + * If the syncobj is considered as a binary (signal/unsignaled) primitive,
>

What does "considered as a binary" mean?  Is it an inherent property of the
syncobj given at create time?  Is it a state the syncobj can be in?  Or is
it a property of how the submit ioctl in the DRM driver references it?  I'm
really hoping it's either 1 or 3


> + * when GPU work is enqueued in a DRM driver to signal the syncobj, the
> fence
> + * is replaced with a fence which will be signaled by the completion of
> that
> + * work.
> + * If the syncobj is considered as a timeline primitive, when GPU work is
> + * enqueued in a DRM driver to signal the a given point of the syncobj, a
> new
> + * struct _fence_chain pointing to the DRM driver's fence and also
> + * pointing to the previous fence that was in the syncobj. The new struct
> + * _fence_chain fence put into the syncobj will be signaled by
> completion
> + * of the DRM driver's work and also any work associated with the fence
> + * previously in the syncobj.
> + *
> + * When GPU work which waits on a syncobj is enqueued in a DRM driver, at
> the
> + * time the work is enqueued, it waits on the fence coming from the
> syncobj
> + * before submitting the work to hardware. That fence is either :
> + *
> + *- The syncobj's current fence if the syncobj is considered as a
> binary
> + *  primitive.
> + *- The struct _fence associated with a given point if the
> syncobj is
> + *  considered as a timeline primitive.
> + *
> + * If the syncobj's fence is NULL or not present in the syncobj's
> timeline,
> + * the enqueue operation is expected to fail.
> + *
> + * With binary syncobj, all manipulation of the syncobjs's fence happens
> in
> + * terms of the current fence at the time the ioctl is called by userspace
> + * regardless of whether that operation is an immediate host-side
> operation
> + * (signal or reset) or or an operation which is enqueued in some driver
> + * queue. _IOCTL_SYNCOBJ_RESET and _IOCTL_SYNCOBJ_SIGNAL can be
> used
> + * to manipulate a syncobj from the host by resetting its pointer to NULL
> or
>   * setting its pointer to a fence which is already signaled.
>   *
> + * With timeline syncobj, all manipulation of the timeline fences happens
> in
> + * terms of the fence referred to in the timeline. See
> + * dma_fence_chain_find_seqno() to see how a given point is found in the
> + * timeline.
> + *
> + * Note that applications should be careful to always use timeline set of
> + * 

Re: [PATCH][drm-next] drm/amd/display: fix a potential null pointer dereference

2019-08-22 Thread Harry Wentland
On 2019-08-16 6:10 p.m., Colin King wrote:
> From: Colin Ian King 
> 
> Currently the pointer init_data is dereferenced on the assignment
> of fw_info before init_data is sanity checked to see if it is null.
> Fix te potential null pointer dereference on init_data by only
> performing dereference after it is null checked.
> 
> Addresses-Coverity: ("Dereference before null check")
> Fixes: 9adc8050bf3c ("drm/amd/display: make firmware info only load once 
> during dc_bios create")
> Signed-off-by: Colin Ian King 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> index bee81bf288be..926954c804a6 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> @@ -1235,7 +1235,7 @@ static bool calc_pll_max_vco_construct(
>   struct calc_pll_clock_source_init_data *init_data)
>  {
>   uint32_t i;
> - struct dc_firmware_info *fw_info = _data->bp->fw_info;
> + struct dc_firmware_info *fw_info;
>   if (calc_pll_cs == NULL ||
>   init_data == NULL ||
>   init_data->bp == NULL)
> @@ -1244,6 +1244,7 @@ static bool calc_pll_max_vco_construct(
>   if (init_data->bp->fw_info_valid)
>   return false;
>  
> + fw_info = _data->bp->fw_info;
>   calc_pll_cs->ctx = init_data->ctx;
>   calc_pll_cs->ref_freq_khz = fw_info->pll_info.crystal_frequency;
>   calc_pll_cs->min_vco_khz =
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 19/19] drm: rcar-du: kms: Update CMM in atomic commit tail

2019-08-22 Thread Jacopo Mondi
Hi Laurent,

On Tue, Aug 20, 2019 at 09:42:15PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Sat, Jul 06, 2019 at 04:07:46PM +0200, Jacopo Mondi wrote:
> > Update CMM settings at in the atomic commit tail helper method.
> >
> > The CMM is updated with new gamma values provided to the driver
> > in the GAMMA_LUT blob property.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 35 +++
> >  1 file changed, 35 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > index b79cda2f5531..f9aece78ca5f 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -21,6 +21,7 @@
> >  #include 
> >  #include 
> >
> > +#include "rcar_cmm.h"
> >  #include "rcar_du_crtc.h"
> >  #include "rcar_du_drv.h"
> >  #include "rcar_du_encoder.h"
> > @@ -287,6 +288,37 @@ rcar_du_fb_create(struct drm_device *dev, struct 
> > drm_file *file_priv,
> >   * Atomic Check and Update
> >   */
> >
> > +static void rcar_du_atomic_commit_update_cmm(struct drm_crtc *crtc,
> > +struct drm_crtc_state *old_state)
> > +{
> > +   struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > +   struct rcar_cmm_config cmm_config = {};
> > +
> > +   if (!rcrtc->cmm || !crtc->state->color_mgmt_changed)
> > +   return;
> > +
> > +   if (!crtc->state->gamma_lut) {
> > +   cmm_config.lut.enable = false;
> > +   rcar_cmm_setup(rcrtc->cmm, _config);
> > +
> > +   return;
> > +   }
> > +
> > +   cmm_config.lut.enable = true;
> > +   cmm_config.lut.table = (struct drm_color_lut *)
> > +  crtc->state->gamma_lut->data;
> > +
> > +   /* Set LUT table size to 0 if entries should not be updated. */
> > +   if (!old_state->gamma_lut ||
> > +   old_state->gamma_lut->base.id != crtc->state->gamma_lut->base.id)
> > +   cmm_config.lut.size = crtc->state->gamma_lut->length
> > +   / sizeof(cmm_config.lut.table[0]);
> > +   else
> > +   cmm_config.lut.size = 0;
> > +
> > +   rcar_cmm_setup(rcrtc->cmm, _config);
> > +}
> > +
> >  static int rcar_du_atomic_check(struct drm_device *dev,
> > struct drm_atomic_state *state)
> >  {
> > @@ -329,6 +361,9 @@ static void rcar_du_atomic_commit_tail(struct 
> > drm_atomic_state *old_state)
> > rcdu->dpad1_source = rcrtc->index;
> > }
> >
> > +   for_each_old_crtc_in_state(old_state, crtc, crtc_state, i)
> > +   rcar_du_atomic_commit_update_cmm(crtc, crtc_state);
> > +
>
> I think this looks good overall, but I wonder if we couldn't simplify
> the CMM driver suspend/resume and LUT caching due to config while not
> enabled by handling it on the DU side. I have a rework on the commit
> tail handler in progress, I'll think how this could be done. For now I
> think you can leave it as is.
>

Does this mean I have your R-b tag ? :)

Thanks
  j

> > /* Apply the atomic update. */
> > drm_atomic_helper_commit_modeset_disables(dev, old_state);
> > drm_atomic_helper_commit_planes(dev, old_state,
>
> --
> Regards,
>
> Laurent Pinchart


signature.asc
Description: PGP signature


Re: [PATCH v2 16/19] drm: rcar-du: kms: Collect CMM instances

2019-08-22 Thread Jacopo Mondi
Hi Laurent,

On Tue, Aug 20, 2019 at 08:54:57PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Sat, Jul 06, 2019 at 04:07:43PM +0200, Jacopo Mondi wrote:
> > Implement device tree parsing to collect the available CMM instances
> > described by the 'cmms' property. Associate CMMs with CRTCs and store a
> > mask of active CMMs in the DU group for later enablement.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  6 +++
> >  drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |  2 +
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  3 ++
> >  drivers/gpu/drm/rcar-du/rcar_du_group.h |  2 +
> >  drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 50 +
> >  5 files changed, 63 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > index 2da46e3dc4ae..23f1d6cc1719 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -1194,6 +1194,12 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
> > unsigned int swindex,
> > if (ret < 0)
> > return ret;
> >
> > +   /* CMM might be disabled for this CRTC. */
> > +   if (rcdu->cmms[swindex]) {
> > +   rcrtc->cmm = rcdu->cmms[swindex];
> > +   rgrp->cmms_mask |= BIT(hwindex % 2);
> > +   }
> > +
> > drm_crtc_helper_add(crtc, _helper_funcs);
> >
> > /* Start with vertical blanking interrupt reporting disabled. */
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > index 3b7fc668996f..5f2940c42225 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > @@ -39,6 +39,7 @@ struct rcar_du_vsp;
> >   * @vblank_wait: wait queue used to signal vertical blanking
> >   * @vblank_count: number of vertical blanking interrupts to wait for
> >   * @group: CRTC group this CRTC belongs to
> > + * @cmm: CMM associated with this CRTC
> >   * @vsp: VSP feeding video to this CRTC
> >   * @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
> >   * @writeback: the writeback connector
> > @@ -64,6 +65,7 @@ struct rcar_du_crtc {
> > unsigned int vblank_count;
> >
> > struct rcar_du_group *group;
> > +   struct platform_device *cmm;
> > struct rcar_du_vsp *vsp;
> > unsigned int vsp_pipe;
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> > index a00dccc447aa..300ec60ba31b 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> > @@ -13,6 +13,7 @@
> >  #include 
> >  #include 
> >
> > +#include "rcar_cmm.h"
> >  #include "rcar_du_crtc.h"
> >  #include "rcar_du_group.h"
> >  #include "rcar_du_vsp.h"
> > @@ -70,6 +71,7 @@ struct rcar_du_device_info {
> >
> >  #define RCAR_DU_MAX_CRTCS  4
> >  #define RCAR_DU_MAX_GROUPS DIV_ROUND_UP(RCAR_DU_MAX_CRTCS, 2)
> > +#define RCAR_DU_MAX_CMMS   4
> >  #define RCAR_DU_MAX_VSPS   4
> >
> >  struct rcar_du_device {
> > @@ -86,6 +88,7 @@ struct rcar_du_device {
> > struct rcar_du_encoder *encoders[RCAR_DU_OUTPUT_MAX];
> >
> > struct rcar_du_group groups[RCAR_DU_MAX_GROUPS];
> > +   struct platform_device *cmms[RCAR_DU_MAX_CMMS];
> > struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
> >
> > struct {
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h 
> > b/drivers/gpu/drm/rcar-du/rcar_du_group.h
> > index 87950c1f6a52..b0c1466593a3 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
> > @@ -22,6 +22,7 @@ struct rcar_du_device;
> >   * @mmio_offset: registers offset in the device memory map
> >   * @index: group index
> >   * @channels_mask: bitmask of populated DU channels in this group
> > + * @cmms_mask: bitmask of enabled CMMs in this group
>
> enabled or available ?
>

I considered having a 'cmm' entry in DT as enabling it, but it is
actually just available.

> >   * @num_crtcs: number of CRTCs in this group (1 or 2)
> >   * @use_count: number of users of the group (rcar_du_group_(get|put))
> >   * @used_crtcs: number of CRTCs currently in use
> > @@ -37,6 +38,7 @@ struct rcar_du_group {
> > unsigned int index;
> >
> > unsigned int channels_mask;
> > +   unsigned int cmms_mask;
> > unsigned int num_crtcs;
> > unsigned int use_count;
> > unsigned int used_crtcs;
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > index f8f7fff34dff..b79cda2f5531 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -18,6 +18,7 @@
> >  #include 
> >
> >  #include 
> > +#include 
> >  #include 
> >
> >  #include "rcar_du_crtc.h"
> > @@ -534,6 +535,51 @@ static int rcar_du_vsps_init(struct rcar_du_device 
> > *rcdu)
> > return ret;
> >  }
> >
> > +static int 

Re: [PATCH v2 17/50] drm: Add helper to create a connector for a chain of bridges

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:48 +0300
Laurent Pinchart  wrote:


> + /**
> +  * @bridge_detect:

^ @bridge_modes

> +  *
> +  * The last bridge in the chain (closest to the connector) that provides
> +  * connector modes detection, if any (see _BRIDGE_OP_MODES).
> +  */
> + struct drm_bridge *bridge_modes;
> +};
> +

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

Re: [PATCH v2 16/50] drm/bridge: tfp410: Allow operation without drm_connector

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:47 +0300
Laurent Pinchart  wrote:

> The tfp410 driver can operate as part of a pipeline where the
> drm_connector is created by the display controller. Enable this mode of
> operation by skipping creation of a drm_connector internally.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index 65651ae6c553..16cc8abe3262 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -133,7 +133,7 @@ static int tfp410_attach(struct drm_bridge *bridge,
>   return ret;
>  
>   if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> - return -EINVAL;
> + return 0;
>  
>   if (!bridge->encoder) {
>   dev_err(dvi->dev, "Missing encoder\n");

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

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1

2019-08-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110659

--- Comment #45 from tempel.jul...@gmail.com ---
Created attachment 145140
  --> https://bugs.freedesktop.org/attachment.cgi?id=145140=edit
new dmesg log with debug patch applied after starting Hitman 2

-- 
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 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1

2019-08-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110659

--- Comment #44 from tempel.jul...@gmail.com ---
I applied the patch to linux 5.2 (among
0001-drm-amd-display-Allow-fast-updates-again-for-swappin.patch) and as
expected, gamma adjustments have stopped working.
Unfortunately, the games still show the issue.

Should the debug information be contained in dmesg? After doing
echo 0x4 > /sys/module/drm/parameters/debug
and starting Hitman 2, there don't seem to be any comprehensive debug
information inside the dmesg log, at least not to my layman eyes (attaching
right now nonetheless).

-- 
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 13/50] drm/bridge: panel: Implement bridge connector operations

2019-08-22 Thread Boris Brezillon
On Thu, 22 Aug 2019 19:35:24 +0300
Laurent Pinchart  wrote:

> Hi Boris,
> 
> On Thu, Aug 22, 2019 at 06:29:09PM +0200, Boris Brezillon wrote:
> > On Tue, 20 Aug 2019 04:16:44 +0300 Laurent Pinchart wrote:
> >   
> > > Implement the newly added bridge connector operations, allowing the
> > > usage of drm_bridge_panel with drm_bridge_connector.
> > > 
> > > Signed-off-by: Laurent Pinchart 
> > > ---
> > >  drivers/gpu/drm/bridge/panel.c | 18 +-
> > >  1 file changed, 17 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/bridge/panel.c 
> > > b/drivers/gpu/drm/bridge/panel.c
> > > index f5b8e55301ac..1c7f5b648f05 100644
> > > --- a/drivers/gpu/drm/bridge/panel.c
> > > +++ b/drivers/gpu/drm/bridge/panel.c
> > > @@ -60,7 +60,7 @@ static int panel_bridge_attach(struct drm_bridge 
> > > *bridge,
> > >   int ret;
> > >  
> > >   if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> > > - return -EINVAL;
> > > + return 0;
> > >  
> > >   if (!bridge->encoder) {
> > >   DRM_ERROR("Missing encoder\n");
> > > @@ -123,6 +123,18 @@ static void panel_bridge_post_disable(struct 
> > > drm_bridge *bridge)
> > >   drm_panel_unprepare(panel_bridge->panel);
> > >  }
> > >  
> > > +static int panel_bridge_get_modes(struct drm_bridge *bridge,
> > > +   struct drm_connector *connector)
> > > +{
> > > + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> > > +
> > > + /*
> > > +  * FIXME: drm_panel_get_modes() should take the connector as an
> > > +  * argument.
> > > +  */
> > > + return drm_panel_get_modes(panel_bridge->panel);
> > > +}
> > > +
> > >  static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
> > >   .attach = panel_bridge_attach,
> > >   .detach = panel_bridge_detach,
> > > @@ -130,6 +142,7 @@ static const struct drm_bridge_funcs 
> > > panel_bridge_bridge_funcs = {
> > >   .enable = panel_bridge_enable,
> > >   .disable = panel_bridge_disable,
> > >   .post_disable = panel_bridge_post_disable,
> > > + .get_modes = panel_bridge_get_modes,
> > >  };
> > >  
> > >  /**
> > > @@ -175,6 +188,9 @@ struct drm_bridge *drm_panel_bridge_add(struct 
> > > drm_panel *panel,
> > >  #ifdef CONFIG_OF
> > >   panel_bridge->bridge.of_node = panel->dev->of_node;
> > >  #endif
> > > + panel_bridge->bridge.ops = DRM_BRIDGE_OP_MODES;
> > > + /* FIXME: The panel should report its type. */
> > > + panel_bridge->bridge.type = DRM_MODE_CONNECTOR_DPI;  
> > 
> > Shouldn't we patch all panel drivers to expose this type before doing
> > this change? I mean, the connector type is exposed to userspace, and I
> > wouldn't be surprised if some userspace apps/libs decided to base their
> > output selection logic on this field.  
> 
> Note that this type will only make it to userspace for drivers that use
> the bridge->type field, likely through the drm bridge connector helper.
> I do agree that panel drivers should be updated, but given the number of
> panels in panel-simple and the fact that the information would need to
> be researched for most of them, this will be significant work. Can't
> this be done when converting display controller drivers on a need basis
> ?

I think setting a default value and fixing things on a need basis is
okay, but that doesn't prevent you from adding the necessary
infrastructure to let panel drivers pass this type (we can fallback to a
default type in panel drivers instead of here). I'm also not sure why
'DPI' is chosen as the default, shouldn't we use 'Unknown' instead?

> 
> Or maybe we could, as an interim measure, derive the type from the bus
> formats reported by the panel if the panel type is not set ? If the
> panel reports MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> MEDIA_BUS_FMT_RGB666_1X7X4_SPWG or MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA then
> we can set the type to LVDS, otherwise we set it to DPI.

Hm, aren't we better off patching panel descs exposing these bus formats
to also explicitly set desc->type to LVDS, leaving others to Unknown
(Unknown is 0, so you don't have to patch all panel_desc definitions)?

> I can submit a
> patch to add a type field to the panel structure and implement this
> logic.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression

2019-08-22 Thread Thomas Zimmermann
Hi

I was traveling and could reply earlier. Sorry for taking so long.

Am 13.08.19 um 11:36 schrieb Feng Tang:
> Hi Thomas, 
> 
> On Mon, Aug 12, 2019 at 03:25:45PM +0800, Feng Tang wrote:
>> Hi Thomas,
>>
>> On Fri, Aug 09, 2019 at 04:12:29PM +0800, Rong Chen wrote:
>>> Hi,
>>>
> Actually we run the benchmark as a background process, do we need to
> disable the cursor and test again?
 There's a worker thread that updates the display from the shadow buffer.
 The blinking cursor periodically triggers the worker thread, but the
 actual update is just the size of one character.

 The point of the test without output is to see if the regression comes
>>> >from the buffer update (i.e., the memcpy from shadow buffer to VRAM), or
>>> >from the worker thread. If the regression goes away after disabling the
 blinking cursor, then the worker thread is the problem. If it already
 goes away if there's simply no output from the test, the screen update
 is the problem. On my machine I have to disable the blinking cursor, so
 I think the worker causes the performance drop.
>>>
>>> We disabled redirecting stdout/stderr to /dev/kmsg,  and the regression is
>>> gone.
>>>
>>> commit:
>>>   f1f8555dfb9 drm/bochs: Use shadow buffer for bochs framebuffer console
>>>   90f479ae51a drm/mgag200: Replace struct mga_fbdev with generic framebuffer
>>> emulation
>>>
>>> f1f8555dfb9a70a2  90f479ae51afa45efab97afdde testcase/testparams/testbox
>>>   -- ---
>>>  %stddev  change %stddev
>>>  \  |    \
>>>  43785   44481
>>> vm-scalability/300s-8T-anon-cow-seq-hugetlb/lkp-knm01
>>>  43785   44481    GEO-MEAN vm-scalability.median
>>
>> Till now, from Rong's tests:
>> 1. Disabling cursor blinking doesn't cure the regression.
>> 2. Disabling printint test results to console can workaround the
>> regression.
>>
>> Also if we set the perfer_shadown to 0, the regression is also
>> gone.
> 
> We also did some further break down for the time consumed by the
> new code.
> 
> The drm_fb_helper_dirty_work() calls sequentially 
> 1. drm_client_buffer_vmap   (290 us)
> 2. drm_fb_helper_dirty_blit_real  (19240 us)
> 3. helper->fb->funcs->dirty()---> NULL for mgag200 driver
> 4. drm_client_buffer_vunmap   (215 us)
>

It's somewhat different to what I observed, but maybe I just couldn't
reproduce the problem correctly.

> The average run time is listed after the function names.
> 
> From it, we can see drm_fb_helper_dirty_blit_real() takes too long
> time (about 20ms for each run). I guess this is the root cause
> of this regression, as the original code doesn't use this dirty worker.

True, the original code uses a temporary buffer, but updates the display
immediately.

My guess is that this could be a caching problem. The worker runs on a
different CPU, which doesn't have the shadow buffer in cache.

> As said in last email, setting the prefer_shadow to 0 can avoid
> the regrssion. Could it be an option?

Unfortunately not. Without the shadow buffer, the console's display
buffer permanently resides in video memory. It consumes significant
amount of that memory (say 8 MiB out of 16 MiB). That doesn't leave
enough room for anything else.

The best option is to not print to the console.

Best regards
Thomas

> Thanks,
> Feng
> 
>>
>> --- a/drivers/gpu/drm/mgag200/mgag200_main.c
>> +++ b/drivers/gpu/drm/mgag200/mgag200_main.c
>> @@ -167,7 +167,7 @@ int mgag200_driver_load(struct drm_device *dev, unsigned 
>> long flags)
>>  dev->mode_config.preferred_depth = 16;
>>  else
>>  dev->mode_config.preferred_depth = 32;
>> -dev->mode_config.prefer_shadow = 1;
>> +dev->mode_config.prefer_shadow = 0;
>>
>> And from the perf data, one obvious difference is good case don't
>> call drm_fb_helper_dirty_work(), while bad case calls.
>>
>> Thanks,
>> Feng
>>
>>> Best Regards,
>>> Rong Chen
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)



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

Re: [PATCH v2 15/50] drm/bridge: tfp410: Replace manual connector handling with bridge

2019-08-22 Thread Boris Brezillon
On Thu, 22 Aug 2019 19:54:56 +0300
Laurent Pinchart  wrote:

> Hi Boris,
> 
> On Thu, Aug 22, 2019 at 06:36:45PM +0200, Boris Brezillon wrote:
> > On Tue, 20 Aug 2019 04:16:46 +0300 Laurent Pinchart wrote:
> >   
> > > Now that a driver is available for display connectors, replace the
> > > manual connector handling code with usage of the DRM bridge API. The
> > > tfp410 driver doesn't deal with the display connector directly anymore,
> > > but still delegates drm_connector operations to the next bridge. This
> > > brings us one step closer to having the tfp410 driver handling the
> > > TFP410 only.
> > > 
> > > Signed-off-by: Laurent Pinchart 
> > > ---
> > >  drivers/gpu/drm/bridge/ti-tfp410.c | 195 ++---
> > >  1 file changed, 68 insertions(+), 127 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
> > > b/drivers/gpu/drm/bridge/ti-tfp410.c
> > > index 4a468f44ef69..65651ae6c553 100644
> > > --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> > > +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> > > @@ -4,14 +4,12 @@
> > >   * Author: Jyri Sarha 
> > >   */
> > >  
> > > -#include 
> > > -#include 
> > >  #include 
> > >  #include 
> > > -#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  
> > >  #include 
> > >  #include 
> > > @@ -24,16 +22,13 @@
> > >  struct tfp410 {
> > >   struct drm_bridge   bridge;
> > >   struct drm_connectorconnector;
> > > - unsigned intconnector_type;
> > >  
> > >   u32 bus_format;
> > > - struct i2c_adapter  *ddc;
> > > - struct gpio_desc*hpd;
> > > - int hpd_irq;
> > >   struct delayed_work hpd_work;
> > >   struct gpio_desc*powerdown;
> > >  
> > >   struct drm_bridge_timings timings;
> > > + struct drm_bridge   *next_bridge;
> > >  
> > >   struct device *dev;
> > >  };
> > > @@ -56,10 +51,10 @@ static int tfp410_get_modes(struct drm_connector 
> > > *connector)
> > >   struct edid *edid;
> > >   int ret;
> > >  
> > > - if (!dvi->ddc)
> > > + if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID))
> > >   goto fallback;
> > >  
> > > - edid = drm_get_edid(connector, dvi->ddc);
> > > + edid = dvi->next_bridge->funcs->get_edid(dvi->next_bridge, connector);  
> > 
> > Can we create a drm_bridge_get_edid() wrapper for that?
> > Something like:
> > 
> > int drm_bridge_get_edid(struct drm_bridge *bridge,
> > struct drm_connector *conn)
> > {
> > if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID))
> > return -ENOTSUPP;  
> 
> I assume you mean ERR_PTR(-ENOTSUPP) with the return type changed to
> struct drm_edid *.
> 
> > 
> > return bridge->funcs->get_edid(bridge, connector);
> > }  
> 
> I've thought about it, but I'm not sure it's worth it. These operations
> are not meant to be called manually by bridges like in here. This is an
> interim solution until support for drm_connector can be dropped from the
> tfp410 driver, once its users will be converted. Do you think I should
> still create a wrapper (which I would make static inline then) ?

Well, this conversion is likely to take time, not to mention that other
drivers will go through the same process. And every time a bridge
driver is converted, it requires patching all display controller drivers
that are known to be connected to it before you can get rid of this
temporary solution. So yes, I still think it's worth adding those
helpers, maybe with a comment explaining that they should only be used
during the conversion phase (IOW, until the driver starts rejecting
the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case).

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

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1

2019-08-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110659

--- Comment #43 from Nicholas Kazlauskas  ---
Created attachment 145139
  --> https://bugs.freedesktop.org/attachment.cgi?id=145139=edit
0001-drm-amd-display-Test-patch-for-disabling-color-adjus.patch

>From your video it looks like something is issuing a lot of full updates. Those
are slow enough that they can miss the current vblank window and be forced to
wait until the next one with vsync on.

I've attached a debug patch you can try that should disable color adjustments
from triggering full updates.

I've also added some debug information to know when full updates are being
issued in case it was something other than color management.

You can view that output with log level 4, ie.

echo 0x4 > /sys/module/drm/parameters/debug

-- 
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: [EXT] [PATCH v3 2/2] drm/bridge: Add NWL MIPI DSI host controller support

2019-08-22 Thread Guido Günther
Hi Robert,
thanks for your comments! Most of this make sense, i have some comments
inline below (mostly since I only have access to the imx8mq reference
manual but not to the any NWL IP docs):

On Thu, Aug 22, 2019 at 01:18:21PM +, Robert Chiras wrote:
> Hi Guido,
> 
> I added my signed-off, plus some comments inline.
> 
> On Jo, 2019-08-22 at 12:44 +0200, Guido Günther wrote:
> > This adds initial support for the NWL MIPI DSI Host controller found
> > on
> > i.MX8 SoCs.
> > 
> > It adds support for the i.MX8MQ but the same IP can be found on
> > e.g. the i.MX8QXP.
> > 
> > It has been tested on the Librem 5 devkit using mxsfb.
> > 
> > Signed-off-by: Guido Günther 
> Signed-off-by: Robert Chiras 

Thanks!

> > Co-developed-by: Robert Chiras 
> > ---
> >  drivers/gpu/drm/bridge/Kconfig   |   2 +
> >  drivers/gpu/drm/bridge/Makefile  |   1 +
> >  drivers/gpu/drm/bridge/nwl-dsi/Kconfig   |  16 +
> >  drivers/gpu/drm/bridge/nwl-dsi/Makefile  |   4 +
> >  drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c | 501 
> >  drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h |  65 +++
> >  drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c | 700
> > +++
> >  drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h | 112 
> >  8 files changed, 1401 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Makefile
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
> > 
> > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > b/drivers/gpu/drm/bridge/Kconfig
> > index 1cc9f502c1f2..7980b5c2156f 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -154,6 +154,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
> > 
> >  source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> > 
> > +source "drivers/gpu/drm/bridge/nwl-dsi/Kconfig"
> > +
> >  source "drivers/gpu/drm/bridge/synopsys/Kconfig"
> > 
> >  endmenu
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 4934fcf5a6f8..d9f6c0f77592 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -16,4 +16,5 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> >  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> >  obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> >  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> > +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi/
> >  obj-y += synopsys/
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > new file mode 100644
> > index ..3b157a9f2229
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > @@ -0,0 +1,16 @@
> > +config DRM_NWL_MIPI_DSI
> > +   tristate "Support for Northwest Logic MIPI DSI Host
> > controller"
> > +   depends on DRM
> > +   depends on COMMON_CLK
> > +   depends on OF && HAS_IOMEM
> > +   select DRM_KMS_HELPER
> > +   select DRM_MIPI_DSI
> > +   select DRM_PANEL_BRIDGE
> > +   select GENERIC_PHY_MIPI_DPHY
> > +   select MFD_SYSCON
> > +   select MULTIPLEXER
> > +   select REGMAP_MMIO
> > +   help
> > + This enables the Northwest Logic MIPI DSI Host controller
> > as
> > + for example found on NXP's i.MX8 Processors.
> > +
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > new file mode 100644
> > index ..804baf2f1916
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +nwl-mipi-dsi-y := nwl-drv.o nwl-dsi.o
> > +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-mipi-dsi.o
> > +header-test-y += nwl-drv.h nwl-dsi.h
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > new file mode 100644
> > index ..e457438738c0
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > @@ -0,0 +1,501 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * i.MX8 NWL MIPI DSI host driver
> > + *
> > + * Copyright (C) 2017 NXP
> > + * Copyright (C) 2019 Purism SPC
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "nwl-drv.h"
> > +#include "nwl-dsi.h"
> > +
> > +#define DRV_NAME "nwl-dsi"
> > +
> > +/* Possible platform specific clocks */
> > +#define NWL_DSI_CLK_CORE   "core"
> > +
> > +static const struct regmap_config nwl_dsi_regmap_config = {
> > +   .reg_bits = 16,
> > +   .val_bits = 32,
> > +   .reg_stride = 4,
> > +   .max_register = 

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1

2019-08-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110659

--- Comment #42 from tempel.jul...@gmail.com ---
(In reply to Nicholas Kazlauskas from comment #39)
> Disabling the compositor doesn't make a difference as far as stuttering goes
> for Hitman 2's DXVK - I don't see any commits in the log that are lock the
> connector and all the planes.

Thanks for trying!

> I don't have Oblivion on my machine to test, but I tried running the DX9
> version of Heaven under proton and I don't see stuttering or any gamma/color
> adjustment commits under that either. No issues with FreeSync when running
> it either from what I can tell with vsync both on/off.

I've given Heaven a try, it doesn't show the issue for me either (DX9 via
D9VK).

> Those commits are definitely what's causing your stuttering, but I'm not
> sure what's actually creating them. My initial guess was something in the
> compatibility layer for DX9 games, but I don't see that on my setup.

I've attached a debug dmesg log after triggering the issue in Hitman 2. It is
also what is shown in the new video capture I've provided. As you can see,
there are no rendering spikes, but instead the mouse input (and perhaps
partially also keyboard) seems to be discarded a lot, causing such jumps. This
is also there without vsync enabled, but less obvious. Just like the render
spikes in Oblivion/Skyrim, this issue completely disappears by turning off
pageflipping in xorg config, switching to modesetting DDX or disabling atomic
modesetting via amdgpu.dc=0. I wonder if the log confirms that it's the same
issue (or the issue has the same roots)?

> Is it only Oblivion that has this issue for you?

I found out that also the native OpenGL renderer of Doom 2016 (which also has a
free demo on Steam) shows the same behavior as Oblivion/Skyrim, despite of no
3D API wrapper involved.
For whatever reason, the Vulkan renderer of the game doesn't show the issue, it
seems to run flawlessly with both pageflipping + vsync.

> I'm not sure how much of this can be a kernel level fix - I think we need to
> lock all the planes whenever gamma or color adjustments have been made and
> that probably includes the cursor plane as well. If the cursor plane is
> included that will block asynchronous cursor updates from occurring until
> the color adjustments have been done. This is why the cursor causes
> stuttering.

Would it be possible to provide a test patch that completely blocks any gamma
adjustment either in Xorg or the kernel? Then we'd have ultimate proof. :)

> A check could potentially be made to not lock all the planes for redundant
> color management commits, but I'm not sure if the color adjustments
> requested are redundant or not. It could be the case that the application is
> requesting different color adjustments every single time.

It seems some suboptimal behavior of Wine can trigger this issue, but I suppose
it would automatically be fixed together with this issue which I reported
regarding gamma adjustment performance and atomic modesetting:
https://bugs.freedesktop.org/show_bug.cgi?id=108917
I btw. can reproduce that issue by simply booting Fedora 30 Workstation Gnome
Live and enable the nightlight feature, the color grading phase makes
everything stutter.

-- 
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 34/50] drm/omap: Create connector for bridges

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:17:05 +0300
Laurent Pinchart  wrote:

> Use the drm_bridge_connector helper to create a connector for pipelines
> that use drm_bridge. This allows splitting connector operations across
> multiple bridges when necessary, instead of having the last bridge in
> the chain creating the connector and handling all connector operations
> internally.
> 
> Signed-off-by: Laurent Pinchart 
> ---
> Changes since v1:
> 
> - Squash with patch "drm/omap: Detach from panels at remove time"
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 82 +-
>  1 file changed, 70 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index de373fd50729..f38d95cb31ba 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -11,10 +11,12 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -290,9 +292,14 @@ static int omap_modeset_init(struct drm_device *dev)
>  
>   if (pipe->output->bridge) {
>   ret = drm_bridge_attach(pipe->encoder,
> - pipe->output->bridge, NULL, 0);
> - if (ret < 0)
> + pipe->output->bridge, NULL,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);

I guess the only external bridge connected to an omap display
controller in upstream DTs is the TFP410. I was wondering if falling
back to !DRM_BRIDGE_ATTACH_NO_CONNECTOR would be acceptable in case one
wants to convert a display controller driver which is known to be
used in conjunction with various external bridges.

> + if (ret < 0) {
> + dev_err(priv->dev,
> + "unable to attach bridge %pOF\n",
> + pipe->output->bridge->of_node);
>   return ret;
> + }
>   }
>  
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 15/50] drm/bridge: tfp410: Replace manual connector handling with bridge

2019-08-22 Thread Laurent Pinchart
Hi Boris,

On Thu, Aug 22, 2019 at 06:36:45PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:46 +0300 Laurent Pinchart wrote:
> 
> > Now that a driver is available for display connectors, replace the
> > manual connector handling code with usage of the DRM bridge API. The
> > tfp410 driver doesn't deal with the display connector directly anymore,
> > but still delegates drm_connector operations to the next bridge. This
> > brings us one step closer to having the tfp410 driver handling the
> > TFP410 only.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >  drivers/gpu/drm/bridge/ti-tfp410.c | 195 ++---
> >  1 file changed, 68 insertions(+), 127 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
> > b/drivers/gpu/drm/bridge/ti-tfp410.c
> > index 4a468f44ef69..65651ae6c553 100644
> > --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> > +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> > @@ -4,14 +4,12 @@
> >   * Author: Jyri Sarha 
> >   */
> >  
> > -#include 
> > -#include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -24,16 +22,13 @@
> >  struct tfp410 {
> > struct drm_bridge   bridge;
> > struct drm_connectorconnector;
> > -   unsigned intconnector_type;
> >  
> > u32 bus_format;
> > -   struct i2c_adapter  *ddc;
> > -   struct gpio_desc*hpd;
> > -   int hpd_irq;
> > struct delayed_work hpd_work;
> > struct gpio_desc*powerdown;
> >  
> > struct drm_bridge_timings timings;
> > +   struct drm_bridge   *next_bridge;
> >  
> > struct device *dev;
> >  };
> > @@ -56,10 +51,10 @@ static int tfp410_get_modes(struct drm_connector 
> > *connector)
> > struct edid *edid;
> > int ret;
> >  
> > -   if (!dvi->ddc)
> > +   if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID))
> > goto fallback;
> >  
> > -   edid = drm_get_edid(connector, dvi->ddc);
> > +   edid = dvi->next_bridge->funcs->get_edid(dvi->next_bridge, connector);
> 
> Can we create a drm_bridge_get_edid() wrapper for that?
> Something like:
> 
> int drm_bridge_get_edid(struct drm_bridge *bridge,
>   struct drm_connector *conn)
> {
>   if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID))
>   return -ENOTSUPP;

I assume you mean ERR_PTR(-ENOTSUPP) with the return type changed to
struct drm_edid *.

> 
>   return bridge->funcs->get_edid(bridge, connector);
> }

I've thought about it, but I'm not sure it's worth it. These operations
are not meant to be called manually by bridges like in here. This is an
interim solution until support for drm_connector can be dropped from the
tfp410 driver, once its users will be converted. Do you think I should
still create a wrapper (which I would make static inline then) ?

> > if (!edid) {
> > dev_info(dvi->dev,
> >  "EDID read failed. Fallback to standard modes\n");
> > @@ -93,21 +88,10 @@ tfp410_connector_detect(struct drm_connector 
> > *connector, bool force)
> >  {
> > struct tfp410 *dvi = drm_connector_to_tfp410(connector);
> >  
> > -   if (dvi->hpd) {
> > -   if (gpiod_get_value_cansleep(dvi->hpd))
> > -   return connector_status_connected;
> > -   else
> > -   return connector_status_disconnected;
> > -   }
> > +   if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_DETECT))
> > +   return connector_status_unknown;
> >  
> > -   if (dvi->ddc) {
> > -   if (drm_probe_ddc(dvi->ddc))
> > -   return connector_status_connected;
> > -   else
> > -   return connector_status_disconnected;
> > -   }
> > -
> > -   return connector_status_unknown;
> > +   return dvi->next_bridge->funcs->detect(dvi->next_bridge);
> 
> Same here for the detect hook.
> 

-- 
Regards,

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

Re: [PATCH v2 14/19] drm: rcar-du: Add support for CMM

2019-08-22 Thread Jacopo Mondi
Hi Ulrich,

On Tue, Aug 20, 2019 at 08:37:44PM +0300, Laurent Pinchart wrote:
> Hello,
>
> On Tue, Jul 16, 2019 at 03:17:04PM +0200, Ulrich Hecht wrote:
> > > On July 6, 2019 at 4:07 PM Jacopo Mondi  wrote:
> > >
> > > Add a driver for the R-Car Display Unit Color Correction Module.
> > >
> > > In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> > > to perform image enhancement and color correction.
> > >
> > > Add support for CMM through a driver that supports configuration of
> > > the 1-dimensional LUT table. More advanced CMM feature will be
> > > implemented on top of this basic one.
> > >
> > > Signed-off-by: Jacopo Mondi 
> > > ---
> > >  drivers/gpu/drm/rcar-du/Kconfig|   7 +
> > >  drivers/gpu/drm/rcar-du/Makefile   |   1 +
> > >  drivers/gpu/drm/rcar-du/rcar_cmm.c | 292 +
> > >  drivers/gpu/drm/rcar-du/rcar_cmm.h |  38 
> > >  4 files changed, 338 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
> > >  create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/Kconfig 
> > > b/drivers/gpu/drm/rcar-du/Kconfig
> > > index 1529849e217e..539d232790d1 100644
> > > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > > @@ -13,6 +13,13 @@ config DRM_RCAR_DU
> > > Choose this option if you have an R-Car chipset.
> > > If M is selected the module will be called rcar-du-drm.
> > >
> > > +config DRM_RCAR_CMM
> > > + bool "R-Car DU Color Management Module (CMM) Support"
> > > + depends on DRM && OF
> > > + depends on DRM_RCAR_DU
> > > + help
> > > +   Enable support for R-Car Color Management Module (CMM).
> > > +
> > >  config DRM_RCAR_DW_HDMI
> > >   tristate "R-Car DU Gen3 HDMI Encoder Support"
> > >   depends on DRM && OF
> > > diff --git a/drivers/gpu/drm/rcar-du/Makefile 
> > > b/drivers/gpu/drm/rcar-du/Makefile
> > > index 6c2ed9c46467..4d1187ccc3e5 100644
> > > --- a/drivers/gpu/drm/rcar-du/Makefile
> > > +++ b/drivers/gpu/drm/rcar-du/Makefile
> > > @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o 
> > > \
> > >  rcar-du-drm-$(CONFIG_DRM_RCAR_VSP)   += rcar_du_vsp.o
> > >  rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
> > >
> > > +obj-$(CONFIG_DRM_RCAR_CMM)   += rcar_cmm.o
> > >  obj-$(CONFIG_DRM_RCAR_DU)+= rcar-du-drm.o
> > >  obj-$(CONFIG_DRM_RCAR_DW_HDMI)   += rcar_dw_hdmi.o
> > >  obj-$(CONFIG_DRM_RCAR_LVDS)  += rcar_lvds.o
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c 
> > > b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > new file mode 100644
> > > index ..76ed3fce2b33
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > @@ -0,0 +1,292 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * rcar_cmm.c -- R-Car Display Unit Color Management Module
> > > + *
> > > + * Copyright (C) 2019 Jacopo Mondi 
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +
> > > +#include "rcar_cmm.h"
> > > +
> > > +#define CM2_LUT_CTRL 0x
> > > +#define CM2_LUT_CTRL_EN  BIT(0)
> > > +#define CM2_LUT_TBLA_BASE0x0600
> > > +#define CM2_LUT_TBLA(__i)(CM2_LUT_TBLA_BASE + (__i) * 4)
> > > +
> > > +struct rcar_cmm {
> > > + struct clk *clk;
> > > + void __iomem *base;
> > > + bool enabled;
> > > +
> > > + /*
> > > +  * restore: LUT restore flag
> > > +  * running: LUT operating flag
> > > +  * size: Number of programmed entries in the LUT table
> > > +  * table: Scratch buffer where to store the LUT table entries to be
> > > +  *later restored.
> > > +  */
> > > + struct {
> > > + bool restore;
> > > + bool running;
> > > + unsigned int size;
> > > + struct drm_color_lut table[CMM_GAMMA_LUT_SIZE];
> > > + } lut;
> > > +};
> > > +
> > > +static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
> > > +{
> > > + return ioread32(rcmm->base + reg);
> > > +}
> > > +
> > > +static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32 
> > > data)
> > > +{
> > > + iowrite32(data, rcmm->base + reg);
> > > +}
> > > +
> > > +static void rcar_cmm_lut_write(struct rcar_cmm *rcmm, unsigned int size,
> > > +struct drm_color_lut *lut)
> > > +{
> > > + unsigned int i;
> > > +
> > > + for (i = 0; i < size; ++i) {
> > > + struct drm_color_lut *entry = [i];
> > > +
> > > + u32 val = (entry->red & 0xff) << 16 |
> > > +   (entry->green & 0xff) << 8 |
> > > +   (entry->blue & 0xff);
> >
> > I don't think it's correct to cut off the high bits here. There is a
> > function "drm_color_lut_extract()" for converting drm_color_lut values
> > to hardware precision.
> >

Oh, I see! the value received from userspace in 16-bits precision
needs to be rescaled to the hw supported one! 

Re: [PATCH v2 04/50] drm/bridge: Add connector-related bridge operations and data

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:35 +0300
Laurent Pinchart  wrote:

>  
> +/**
> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> + */
> +enum drm_bridge_ops {
> + /**
> +  * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> +  * its output. Bridges that set this flag shall implement the
> +  * _bridge_funcs->detect callback.
> +  */
> + DRM_BRIDGE_OP_DETECT = BIT(0),
> + /**
> +  * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> +  * connected to its output. Bridges that set this flag shall implement
> +  * the _bridge_funcs->get_edid callback.
> +  */
> + DRM_BRIDGE_OP_EDID = BIT(1),
> + /**
> +  * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> +  * without requiring polling. Bridges that set this flag shall
> +  * implement the _bridge_funcs->hpd_enable and
> +  * _bridge_funcs->hpd_disable callbacks if they support enabling
> +  * and disabling hot-plug detection dynamically.
> +  */
> + DRM_BRIDGE_OP_HPD = BIT(2),
> + /**
> +  * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> +  * by the display at its output. This does not include readind EDID
> +  * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> +  * this flag shall implement the _bridge_funcs->get_modes callback.
> +  */
> + DRM_BRIDGE_OP_MODES = BIT(3),
> +};
> +
>  /**
>   * struct drm_bridge - central DRM bridge control structure
>   */
> @@ -398,6 +538,33 @@ struct drm_bridge {
>   const struct drm_bridge_funcs *funcs;
>   /** @driver_private: pointer to the bridge driver's internal context */
>   void *driver_private;
> + /** @ops: bitmask of operations supported by the bridge */
> + enum drm_bridge_ops ops;

Just realized that you're not checking ->ops and ->funcs consistency at
attach() time (you're only checking ->ops in the tfp410 driver before
calling ->funcs->detect() and ->funcs->get_modes() and they might be
NULL).

> + /**
> +  * @type: Type of the connection at the bridge output
> +  * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> +  * identifies the type of connected display.
> +  */
> + int type;
> + /**
> +  * @ddc: Associated I2C adapter for DDC access, if any.
> +  */
> + struct i2c_adapter *ddc;
> + /** private: */
> + /**
> +  * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> +  */
> + struct mutex hpd_mutex;
> + /**
> +  * @hpd_cb: Hot plug detection callback, registered with
> +  * drm_bridge_hpd_enable().
> +  */
> + void (*hpd_cb)(void *data, enum drm_connector_status status);
> + /**
> +  * @hpd_data: Private data passed to the Hot plug detection callback
> +  * @hpd_cb.
> +  */
> + void *hpd_data;
>  };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1

2019-08-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110659

--- Comment #41 from tempel.jul...@gmail.com ---
Created attachment 145138
  --> https://bugs.freedesktop.org/attachment.cgi?id=145138=edit
debug dmesg.log after running Hitman 2 with the issue

-- 
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 11/50] drm/bridge: Add bridge driver for display connectors

2019-08-22 Thread Laurent Pinchart
Hi Boris,

On Thu, Aug 22, 2019 at 06:05:20PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:42 +0300 Laurent Pinchart wrote:
> 
> > +   /*
> > +* Get the HPD GPIO for DVI and HDMI connectors. If the GPIO can provide
> > +* interrupts, register an interrupt handler.
> > +*/
> > +   if (type == DRM_MODE_CONNECTOR_DVII ||
> > +   type == DRM_MODE_CONNECTOR_HDMIA) {
> > +   conn->hpd_gpio = devm_gpiod_get_optional(>dev, "hpd",
> > +GPIOD_IN);
> > +   if (IS_ERR(conn->hpd_gpio)) {
> > +   if (PTR_ERR(conn->hpd_gpio) != -EPROBE_DEFER)
> > +   dev_err(>dev,
> > +   "Unable to retrieve HPD GPIO\n");
> > +   return PTR_ERR(conn->hpd_gpio);
> > +   }
> > +
> > +   conn->hpd_irq = gpiod_to_irq(conn->hpd_gpio);
> > +   } else {
> > +   conn->hpd_irq = -EINVAL;
> > +   }
> > +
> > +   if (conn->hpd_irq >= 0) {
> > +   ret = devm_request_threaded_irq(>dev, conn->hpd_irq,
> > +   NULL, display_connector_hpd_irq,
> > +   IRQF_TRIGGER_RISING |
> > +   IRQF_TRIGGER_FALLING |
> > +   IRQF_ONESHOT,
> > +   "HPD", conn);
> > +   if (ret) {
> > +   dev_err(>dev,
> > +   "Failed to request HPD interrupt\n");
> > +   return ret;
> 
> Is there anything that mandates support of edge events on GPIO chips?
> I know it's quite common, but maybe we should fallback to polling
> mode when devm_request_threaded_irq() fails.

That's a good point, I'll change this.

> > +   }
> > +   }
> > +
> > +   /* Retrieve the DDC I2C adapter for DVI, HDMI and VGA connectors. */
> > +   if (type == DRM_MODE_CONNECTOR_DVII ||
> > +   type == DRM_MODE_CONNECTOR_HDMIA ||
> > +   type == DRM_MODE_CONNECTOR_VGA) {
> > +   struct device_node *phandle;
> > +
> > +   phandle = of_parse_phandle(pdev->dev.of_node, "ddc-i2c-bus", 0);
> > +   if (phandle) {
> > +   conn->bridge.ddc = of_get_i2c_adapter_by_node(phandle);
> > +   of_node_put(phandle);
> > +   if (!conn->bridge.ddc)
> > +   return -EPROBE_DEFER;
> > +   } else {
> > +   dev_dbg(>dev,
> > +   "No I2C bus specified, disabling EDID 
> > readout\n");
> > +   }
> > +   }
> > +

-- 
Regards,

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

Re: [PATCH v2 15/50] drm/bridge: tfp410: Replace manual connector handling with bridge

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:46 +0300
Laurent Pinchart  wrote:

> Now that a driver is available for display connectors, replace the
> manual connector handling code with usage of the DRM bridge API. The
> tfp410 driver doesn't deal with the display connector directly anymore,
> but still delegates drm_connector operations to the next bridge. This
> brings us one step closer to having the tfp410 driver handling the
> TFP410 only.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/bridge/ti-tfp410.c | 195 ++---
>  1 file changed, 68 insertions(+), 127 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index 4a468f44ef69..65651ae6c553 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -4,14 +4,12 @@
>   * Author: Jyri Sarha 
>   */
>  
> -#include 
> -#include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -24,16 +22,13 @@
>  struct tfp410 {
>   struct drm_bridge   bridge;
>   struct drm_connectorconnector;
> - unsigned intconnector_type;
>  
>   u32 bus_format;
> - struct i2c_adapter  *ddc;
> - struct gpio_desc*hpd;
> - int hpd_irq;
>   struct delayed_work hpd_work;
>   struct gpio_desc*powerdown;
>  
>   struct drm_bridge_timings timings;
> + struct drm_bridge   *next_bridge;
>  
>   struct device *dev;
>  };
> @@ -56,10 +51,10 @@ static int tfp410_get_modes(struct drm_connector 
> *connector)
>   struct edid *edid;
>   int ret;
>  
> - if (!dvi->ddc)
> + if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID))
>   goto fallback;
>  
> - edid = drm_get_edid(connector, dvi->ddc);
> + edid = dvi->next_bridge->funcs->get_edid(dvi->next_bridge, connector);

Can we create a drm_bridge_get_edid() wrapper for that?
Something like:

int drm_bridge_get_edid(struct drm_bridge *bridge,
struct drm_connector *conn)
{
if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID))
return -ENOTSUPP;

return bridge->funcs->get_edid(bridge, connector);
}

>   if (!edid) {
>   dev_info(dvi->dev,
>"EDID read failed. Fallback to standard modes\n");
> @@ -93,21 +88,10 @@ tfp410_connector_detect(struct drm_connector *connector, 
> bool force)
>  {
>   struct tfp410 *dvi = drm_connector_to_tfp410(connector);
>  
> - if (dvi->hpd) {
> - if (gpiod_get_value_cansleep(dvi->hpd))
> - return connector_status_connected;
> - else
> - return connector_status_disconnected;
> - }
> + if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_DETECT))
> + return connector_status_unknown;
>  
> - if (dvi->ddc) {
> - if (drm_probe_ddc(dvi->ddc))
> - return connector_status_connected;
> - else
> - return connector_status_disconnected;
> - }
> -
> - return connector_status_unknown;
> + return dvi->next_bridge->funcs->detect(dvi->next_bridge);

Same here for the detect hook.

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

Re: [PATCH v2 13/50] drm/bridge: panel: Implement bridge connector operations

2019-08-22 Thread Laurent Pinchart
Hi Boris,

On Thu, Aug 22, 2019 at 06:29:09PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:44 +0300 Laurent Pinchart wrote:
> 
> > Implement the newly added bridge connector operations, allowing the
> > usage of drm_bridge_panel with drm_bridge_connector.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >  drivers/gpu/drm/bridge/panel.c | 18 +-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> > index f5b8e55301ac..1c7f5b648f05 100644
> > --- a/drivers/gpu/drm/bridge/panel.c
> > +++ b/drivers/gpu/drm/bridge/panel.c
> > @@ -60,7 +60,7 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
> > int ret;
> >  
> > if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> > -   return -EINVAL;
> > +   return 0;
> >  
> > if (!bridge->encoder) {
> > DRM_ERROR("Missing encoder\n");
> > @@ -123,6 +123,18 @@ static void panel_bridge_post_disable(struct 
> > drm_bridge *bridge)
> > drm_panel_unprepare(panel_bridge->panel);
> >  }
> >  
> > +static int panel_bridge_get_modes(struct drm_bridge *bridge,
> > + struct drm_connector *connector)
> > +{
> > +   struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> > +
> > +   /*
> > +* FIXME: drm_panel_get_modes() should take the connector as an
> > +* argument.
> > +*/
> > +   return drm_panel_get_modes(panel_bridge->panel);
> > +}
> > +
> >  static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
> > .attach = panel_bridge_attach,
> > .detach = panel_bridge_detach,
> > @@ -130,6 +142,7 @@ static const struct drm_bridge_funcs 
> > panel_bridge_bridge_funcs = {
> > .enable = panel_bridge_enable,
> > .disable = panel_bridge_disable,
> > .post_disable = panel_bridge_post_disable,
> > +   .get_modes = panel_bridge_get_modes,
> >  };
> >  
> >  /**
> > @@ -175,6 +188,9 @@ struct drm_bridge *drm_panel_bridge_add(struct 
> > drm_panel *panel,
> >  #ifdef CONFIG_OF
> > panel_bridge->bridge.of_node = panel->dev->of_node;
> >  #endif
> > +   panel_bridge->bridge.ops = DRM_BRIDGE_OP_MODES;
> > +   /* FIXME: The panel should report its type. */
> > +   panel_bridge->bridge.type = DRM_MODE_CONNECTOR_DPI;
> 
> Shouldn't we patch all panel drivers to expose this type before doing
> this change? I mean, the connector type is exposed to userspace, and I
> wouldn't be surprised if some userspace apps/libs decided to base their
> output selection logic on this field.

Note that this type will only make it to userspace for drivers that use
the bridge->type field, likely through the drm bridge connector helper.
I do agree that panel drivers should be updated, but given the number of
panels in panel-simple and the fact that the information would need to
be researched for most of them, this will be significant work. Can't
this be done when converting display controller drivers on a need basis
?

Or maybe we could, as an interim measure, derive the type from the bus
formats reported by the panel if the panel type is not set ? If the
panel reports MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
MEDIA_BUS_FMT_RGB666_1X7X4_SPWG or MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA then
we can set the type to LVDS, otherwise we set it to DPI. I can submit a
patch to add a type field to the panel structure and implement this
logic.

> > drm_bridge_add(_bridge->bridge);

-- 
Regards,

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

Re: [PATCH v2 13/50] drm/bridge: panel: Implement bridge connector operations

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:44 +0300
Laurent Pinchart  wrote:

> Implement the newly added bridge connector operations, allowing the
> usage of drm_bridge_panel with drm_bridge_connector.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/bridge/panel.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index f5b8e55301ac..1c7f5b648f05 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -60,7 +60,7 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
>   int ret;
>  
>   if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> - return -EINVAL;
> + return 0;
>  
>   if (!bridge->encoder) {
>   DRM_ERROR("Missing encoder\n");
> @@ -123,6 +123,18 @@ static void panel_bridge_post_disable(struct drm_bridge 
> *bridge)
>   drm_panel_unprepare(panel_bridge->panel);
>  }
>  
> +static int panel_bridge_get_modes(struct drm_bridge *bridge,
> +   struct drm_connector *connector)
> +{
> + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> +
> + /*
> +  * FIXME: drm_panel_get_modes() should take the connector as an
> +  * argument.
> +  */
> + return drm_panel_get_modes(panel_bridge->panel);
> +}
> +
>  static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
>   .attach = panel_bridge_attach,
>   .detach = panel_bridge_detach,
> @@ -130,6 +142,7 @@ static const struct drm_bridge_funcs 
> panel_bridge_bridge_funcs = {
>   .enable = panel_bridge_enable,
>   .disable = panel_bridge_disable,
>   .post_disable = panel_bridge_post_disable,
> + .get_modes = panel_bridge_get_modes,
>  };
>  
>  /**
> @@ -175,6 +188,9 @@ struct drm_bridge *drm_panel_bridge_add(struct drm_panel 
> *panel,
>  #ifdef CONFIG_OF
>   panel_bridge->bridge.of_node = panel->dev->of_node;
>  #endif
> + panel_bridge->bridge.ops = DRM_BRIDGE_OP_MODES;
> + /* FIXME: The panel should report its type. */
> + panel_bridge->bridge.type = DRM_MODE_CONNECTOR_DPI;

Shouldn't we patch all panel drivers to expose this type before doing
this change? I mean, the connector type is exposed to userspace, and I
wouldn't be surprised if some userspace apps/libs decided to base their
output selection logic on this field.

>  
>   drm_bridge_add(_bridge->bridge);
>  

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

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1

2019-08-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110659

--- Comment #40 from tempel.jul...@gmail.com ---
Created attachment 145137
  --> https://bugs.freedesktop.org/attachment.cgi?id=145137=edit
video demonstrating the issue in Hitman 2 (different to Oblivion/Skyrim)

-- 
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 110865] Rx480 consumes 20w more power in idle than under Windows

2019-08-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110865

--- Comment #17 from Alex Deucher  ---
Note that it will only work if your monitors have identical timing.

-- 
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 110865] Rx480 consumes 20w more power in idle than under Windows

2019-08-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110865

Alex Deucher  changed:

   What|Removed |Added

 Attachment #144983|0   |1
is obsolete||

--- Comment #16 from Alex Deucher  ---
Created attachment 145136
  --> https://bugs.freedesktop.org/attachment.cgi?id=145136=edit
fix DC code

Can you try this patch along with attachment 144978?

-- 
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 14/50] drm/bridge: tfp410: Don't include drmP.h

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:45 +0300
Laurent Pinchart  wrote:

> The drmP.h header is deprecated, replace it with the headers
> specifically needed by the tfp410 driver. While at it, replace the DRM
> print macros with dev_info() and dev_err() instead of including
> drm_print.h

Looks like drm_print.h is still included.

> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/bridge/ti-tfp410.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index a9359038f7dc..4a468f44ef69 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -14,6 +14,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -60,7 +61,8 @@ static int tfp410_get_modes(struct drm_connector *connector)
>  
>   edid = drm_get_edid(connector, dvi->ddc);
>   if (!edid) {
> - DRM_INFO("EDID read failed. Fallback to standard modes\n");
> + dev_info(dvi->dev,
> +  "EDID read failed. Fallback to standard modes\n");
>   goto fallback;
>   }
>  
> @@ -364,7 +366,7 @@ static int tfp410_init(struct device *dev, bool i2c)
>   IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>   "hdmi-hpd", dvi);
>   if (ret) {
> - DRM_ERROR("failed to register hpd interrupt\n");
> + dev_err(dev, "failed to register hpd interrupt\n");
>   goto fail;
>   }
>   }

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

Re: [PATCH v6 2/7] dt-bindings: display: msm: gmu: add optional ocmem property

2019-08-22 Thread Rob Herring
On Thu, Aug 22, 2019 at 9:37 AM Brian Masney  wrote:
>
> Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> optional ocmem property to the Adreno Graphics Management Unit bindings.
>
> Signed-off-by: Brian Masney 
> ---
> Changes since v5:
> - rename ocmem property to sram to match what TI currently has.
>
> Changes since v4:
> - None
>
> Changes since v3:
> - correct link to qcom,ocmem.yaml
>
> Changes since v2:
> - Add a3xx example with OCMEM
>
> Changes since v1:
> - None
>
>  .../devicetree/bindings/display/msm/gmu.txt   | 50 +++
>  1 file changed, 50 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
> b/Documentation/devicetree/bindings/display/msm/gmu.txt
> index 90af5b0a56a9..2305a2aede5a 100644
> --- a/Documentation/devicetree/bindings/display/msm/gmu.txt
> +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> @@ -31,6 +31,10 @@ Required properties:
>  - iommus: phandle to the adreno iommu
>  - operating-points-v2: phandle to the OPP operating points
>
> +Optional properties:
> +- sram: phandle to the On Chip Memory (OCMEM) that's present on some 
> Snapdragon
> +SoCs. See Documentation/devicetree/bindings/sram/qcom,ocmem.yaml.
> +
>  Example:
>
>  / {
> @@ -63,3 +67,49 @@ Example:
> operating-points-v2 = <_opp_table>;
> };
>  };
> +
> +a3xx example with OCMEM support:
> +
> +/ {
> +   ...
> +
> +   gpu: adreno@fdb0 {
> +   compatible = "qcom,adreno-330.2",
> +"qcom,adreno";
> +   reg = <0xfdb0 0x1>;
> +   reg-names = "kgsl_3d0_reg_memory";
> +   interrupts = ;
> +   interrupt-names = "kgsl_3d0_irq";
> +   clock-names = "core",
> + "iface",
> + "mem_iface";
> +   clocks = < OXILI_GFX3D_CLK>,
> +< OXILICX_AHB_CLK>,
> +< OXILICX_AXI_CLK>;
> +   sram = <>;

Shouldn't this point to gmu-sram@0? You can always get the parent from
the child which is a bit easier than the other way around.

> +   power-domains = < OXILICX_GDSC>;
> +   operating-points-v2 = <_opp_table>;
> +   iommus = <_iommu 0>;
> +   };
> +
> +   ocmem: ocmem@fdd0 {
> +   compatible = "qcom,msm8974-ocmem";
> +
> +   reg = <0xfdd0 0x2000>,
> + <0xfec0 0x18>;
> +   reg-names = "ctrl",
> +"mem";
> +
> +   clocks = < RPM_SMD_OCMEMGX_CLK>,
> +< OCMEMCX_OCMEMNOC_CLK>;
> +   clock-names = "core",
> + "iface";
> +
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +
> +   gmu-sram@0 {
> +   reg = <0x0 0x10>;
> +   };
> +   };
> +};
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 11/50] drm/bridge: Add bridge driver for display connectors

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:42 +0300
Laurent Pinchart  wrote:

> + /*
> +  * Get the HPD GPIO for DVI and HDMI connectors. If the GPIO can provide
> +  * interrupts, register an interrupt handler.
> +  */
> + if (type == DRM_MODE_CONNECTOR_DVII ||
> + type == DRM_MODE_CONNECTOR_HDMIA) {
> + conn->hpd_gpio = devm_gpiod_get_optional(>dev, "hpd",
> +  GPIOD_IN);
> + if (IS_ERR(conn->hpd_gpio)) {
> + if (PTR_ERR(conn->hpd_gpio) != -EPROBE_DEFER)
> + dev_err(>dev,
> + "Unable to retrieve HPD GPIO\n");
> + return PTR_ERR(conn->hpd_gpio);
> + }
> +
> + conn->hpd_irq = gpiod_to_irq(conn->hpd_gpio);
> + } else {
> + conn->hpd_irq = -EINVAL;
> + }
> +
> + if (conn->hpd_irq >= 0) {
> + ret = devm_request_threaded_irq(>dev, conn->hpd_irq,
> + NULL, display_connector_hpd_irq,
> + IRQF_TRIGGER_RISING |
> + IRQF_TRIGGER_FALLING |
> + IRQF_ONESHOT,
> + "HPD", conn);
> + if (ret) {
> + dev_err(>dev,
> + "Failed to request HPD interrupt\n");
> + return ret;

Is there anything that mandates support of edge events on GPIO chips?
I know it's quite common, but maybe we should fallback to polling
mode when devm_request_threaded_irq() fails.

> + }
> + }
> +
> + /* Retrieve the DDC I2C adapter for DVI, HDMI and VGA connectors. */
> + if (type == DRM_MODE_CONNECTOR_DVII ||
> + type == DRM_MODE_CONNECTOR_HDMIA ||
> + type == DRM_MODE_CONNECTOR_VGA) {
> + struct device_node *phandle;
> +
> + phandle = of_parse_phandle(pdev->dev.of_node, "ddc-i2c-bus", 0);
> + if (phandle) {
> + conn->bridge.ddc = of_get_i2c_adapter_by_node(phandle);
> + of_node_put(phandle);
> + if (!conn->bridge.ddc)
> + return -EPROBE_DEFER;
> + } else {
> + dev_dbg(>dev,
> + "No I2C bus specified, disabling EDID 
> readout\n");
> + }
> + }
> +
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: meson: use match data to detect vpu compatibility

2019-08-22 Thread Neil Armstrong
Hi Julien,

On 22/08/2019 16:43, Julien Masson wrote:
> This patch introduce new enum which contains all VPU family (GXBB,
> GXL, GXM and G12A).
> This enum is used to detect the VPU compatible with the device.
> 
> We only need to set .data to the corresponding enum in the device
> table, no need to check .compatible string anymore.
> 
> Signed-off-by: Julien Masson 
> ---
> 
> Changes since v1 at [1]:
> - Set .data field in struct dt_match instead of connectors_match
> - Add compat in struct meson_drm and set it the corresponding family at probe
> - Check directly compat in meson_vpu_is_compatible
> 
> [1] https://patchwork.kernel.org/patch/11108855/
> 
>  drivers/gpu/drm/meson/meson_crtc.c  |  2 +-
>  drivers/gpu/drm/meson/meson_drv.c   | 14 --
>  drivers/gpu/drm/meson/meson_drv.h   | 13 -
>  drivers/gpu/drm/meson/meson_dw_hdmi.c   |  2 +-
>  drivers/gpu/drm/meson/meson_overlay.c   |  2 +-
>  drivers/gpu/drm/meson/meson_plane.c | 10 ++--
>  drivers/gpu/drm/meson/meson_vclk.c  | 64 -
>  drivers/gpu/drm/meson/meson_venc.c  |  2 +-
>  drivers/gpu/drm/meson/meson_venc_cvbs.c | 10 ++--
>  drivers/gpu/drm/meson/meson_viu.c   | 10 ++--
>  drivers/gpu/drm/meson/meson_vpp.c   | 10 ++--
>  11 files changed, 77 insertions(+), 62 deletions(-)

Tested-by: Neil Armstrong 

on SEI510 (G12A), VIM2 (GXM) and Libretech-AC (GXL)

and

Acked-by: Neil Armstrong 

Applying to drm-misc-next

Neil

> 
> diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
> b/drivers/gpu/drm/meson/meson_crtc.c
> index bba25325aa9c..57ae1c13d1e6 100644
> --- a/drivers/gpu/drm/meson/meson_crtc.c
> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> @@ -575,7 +575,7 @@ int meson_crtc_create(struct meson_drm *priv)
>   return ret;
>   }
>  
> - if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
> + if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) {
>   meson_crtc->enable_osd1 = meson_g12a_crtc_enable_osd1;
>   meson_crtc->enable_vd1 = meson_g12a_crtc_enable_vd1;
>   meson_crtc->viu_offset = MESON_G12A_VIU_OFFSET;
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index ae0166181606..a24f8dec5adc 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -209,6 +209,8 @@ static int meson_drv_bind_master(struct device *dev, bool 
> has_components)
>   priv->drm = drm;
>   priv->dev = dev;
>  
> + priv->compat = (enum vpu_compatible)of_device_get_match_data(priv->dev);
> +
>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "vpu");
>   regs = devm_ioremap_resource(dev, res);
>   if (IS_ERR(regs)) {
> @@ -453,10 +455,14 @@ static int meson_drv_probe(struct platform_device *pdev)
>  };
>  
>  static const struct of_device_id dt_match[] = {
> - { .compatible = "amlogic,meson-gxbb-vpu" },
> - { .compatible = "amlogic,meson-gxl-vpu" },
> - { .compatible = "amlogic,meson-gxm-vpu" },
> - { .compatible = "amlogic,meson-g12a-vpu" },
> + { .compatible = "amlogic,meson-gxbb-vpu",
> +   .data   = (void *)VPU_COMPATIBLE_GXBB },
> + { .compatible = "amlogic,meson-gxl-vpu",
> +   .data   = (void *)VPU_COMPATIBLE_GXL },
> + { .compatible = "amlogic,meson-gxm-vpu",
> +   .data   = (void *)VPU_COMPATIBLE_GXM },
> + { .compatible = "amlogic,meson-g12a-vpu",
> +   .data   = (void *)VPU_COMPATIBLE_G12A },
>   {}
>  };
>  MODULE_DEVICE_TABLE(of, dt_match);
> diff --git a/drivers/gpu/drm/meson/meson_drv.h 
> b/drivers/gpu/drm/meson/meson_drv.h
> index c9aaec1a846e..820d07bdd42a 100644
> --- a/drivers/gpu/drm/meson/meson_drv.h
> +++ b/drivers/gpu/drm/meson/meson_drv.h
> @@ -9,6 +9,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct drm_crtc;
> @@ -16,8 +17,16 @@ struct drm_device;
>  struct drm_plane;
>  struct meson_drm;
>  
> +enum vpu_compatible {
> + VPU_COMPATIBLE_GXBB = 0,
> + VPU_COMPATIBLE_GXL  = 1,
> + VPU_COMPATIBLE_GXM  = 2,
> + VPU_COMPATIBLE_G12A = 3,
> +};
> +
>  struct meson_drm {
>   struct device *dev;
> + enum vpu_compatible compat;
>   void __iomem *io_base;
>   struct regmap *hhi;
>   int vsync_irq;
> @@ -116,9 +125,9 @@ struct meson_drm {
>  };
>  
>  static inline int meson_vpu_is_compatible(struct meson_drm *priv,
> -   const char *compat)
> +   enum vpu_compatible family)
>  {
> - return of_device_is_compatible(priv->dev->of_node, compat);
> + return priv->compat == family;
>  }
>  
>  #endif /* __MESON_DRV_H */
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index f893ebd0b799..68bbd987147b 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -937,7 +937,7 @@ static int meson_dw_hdmi_bind(struct device *dev, 

[PATCH v2] drm/msm/dpu: add rotation property

2019-08-22 Thread Rob Clark
From: Rob Clark 

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 45bfac9e3af7..970194958257 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1040,8 +1040,21 @@ static void dpu_plane_sspp_atomic_update(struct 
drm_plane *plane)
pstate->multirect_mode);
 
if (pdpu->pipe_hw->ops.setup_format) {
+   unsigned int rotation;
+
src_flags = 0x0;
 
+   rotation = drm_rotation_simplify(state->rotation,
+DRM_MODE_ROTATE_0 |
+DRM_MODE_REFLECT_X |
+DRM_MODE_REFLECT_Y);
+
+   if (rotation & DRM_MODE_REFLECT_X)
+   src_flags |= DPU_SSPP_FLIP_LR;
+
+   if (rotation & DRM_MODE_REFLECT_Y)
+   src_flags |= DPU_SSPP_FLIP_UD;
+
/* update format */
pdpu->pipe_hw->ops.setup_format(pdpu->pipe_hw, fmt, src_flags,
pstate->multirect_index);
@@ -1522,6 +1535,13 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
if (ret)
DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
 
+   drm_plane_create_rotation_property(plane,
+   DRM_MODE_ROTATE_0,
+   DRM_MODE_ROTATE_0 |
+   DRM_MODE_ROTATE_180 |
+   DRM_MODE_REFLECT_X |
+   DRM_MODE_REFLECT_Y);
+
drm_plane_enable_fb_damage_clips(plane);
 
/* success! finalize initialization */
-- 
2.21.0



Re: [PATCH v2 10/50] drm/bridge: simple-bridge: Add support for the TI OP362

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:41 +0300
Laurent Pinchart  wrote:

> The TI OP362 is an analog video amplifier controlled through a GPIO. Add
> support for it to the simple-bridge driver.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Andrzej Hajda 

Reviewed-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/bridge/simple-bridge.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c 
> b/drivers/gpu/drm/bridge/simple-bridge.c
> index 3e5031833368..52626e2de90e 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -302,6 +302,11 @@ static const struct of_device_id simple_bridge_match[] = 
> {
>   .timings = _bridge_timings,
>   .connector_type = DRM_MODE_CONNECTOR_VGA,
>   },
> + }, {
> + .compatible = "ti,opa362",
> + .data = &(const struct simple_bridge_info) {
> + .connector_type = DRM_MODE_CONNECTOR_Composite,
> + },
>   }, {
>   .compatible = "ti,ths8135",
>   .data = &(const struct simple_bridge_info) {

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

Re: [PATCH] drm/msm/dpu: add rotation property

2019-08-22 Thread Rob Clark
On Thu, Aug 22, 2019 at 5:26 AM Ville Syrjälä
 wrote:
>
> On Wed, Aug 21, 2019 at 06:57:24PM -0700, Rob Clark wrote:
> > From: Rob Clark 
> >
> > Signed-off-by: Rob Clark 
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > index 45bfac9e3af7..c5653771e8fa 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > @@ -1040,8 +1040,21 @@ static void dpu_plane_sspp_atomic_update(struct 
> > drm_plane *plane)
> >   pstate->multirect_mode);
> >
> >   if (pdpu->pipe_hw->ops.setup_format) {
> > + unsigned int rotation;
> > +
> >   src_flags = 0x0;
> >
> > + rotation = drm_rotation_simplify(state->rotation,
> > +  DRM_MODE_ROTATE_0 |
> > +  DRM_MODE_REFLECT_X |
> > +  DRM_MODE_REFLECT_Y);
> > +
> > + if (rotation & DRM_MODE_REFLECT_X)
> > + src_flags |= DPU_SSPP_FLIP_UD;
> > +
> > + if (rotation & DRM_MODE_REFLECT_Y)
> > + src_flags |= DPU_SSPP_FLIP_LR;
> > +
>
> UD vs. LR (assuming those mean what I think they mean) seem the wrong
> way around here.

ahh, right, reflect "along" vs "around"..

BR,
-R

>
> >
> >   /* update format */
> >   pdpu->pipe_hw->ops.setup_format(pdpu->pipe_hw, fmt, src_flags,
> >   pstate->multirect_index);
> > @@ -1522,6 +1535,13 @@ struct drm_plane *dpu_plane_init(struct drm_device 
> > *dev,
> >   if (ret)
> >   DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
> >
> > + drm_plane_create_rotation_property(plane,
> > + DRM_MODE_ROTATE_0,
> > + DRM_MODE_ROTATE_0 |
> > + DRM_MODE_ROTATE_180 |
> > + DRM_MODE_REFLECT_X |
> > + DRM_MODE_REFLECT_Y);
> > +
> >   drm_plane_enable_fb_damage_clips(plane);
> >
> >   /* success! finalize initialization */
> > --
> > 2.21.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel


Re: [PATCH v2 09/50] drm/bridge: simple-bridge: Add support for enable GPIO

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:40 +0300
Laurent Pinchart  wrote:

> If an enable GPIO is declared in the firmware, assert it when enabling
> the bridge and deassert it when disabling it.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Stefan Agner 

Reviewed-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/bridge/simple-bridge.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c 
> b/drivers/gpu/drm/bridge/simple-bridge.c
> index 85aa852eafb4..3e5031833368 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -6,6 +6,7 @@
>   * Maxime Ripard 
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +30,7 @@ struct simple_bridge {
>  
>   struct i2c_adapter  *ddc;
>   struct regulator*vdd;
> + struct gpio_desc*enable;
>  };
>  
>  static inline struct simple_bridge *
> @@ -140,19 +142,23 @@ static int simple_bridge_attach(struct drm_bridge 
> *bridge,
>  static void simple_bridge_enable(struct drm_bridge *bridge)
>  {
>   struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
> - int ret = 0;
> + int ret;
>  
> - if (sbridge->vdd)
> + if (sbridge->vdd) {
>   ret = regulator_enable(sbridge->vdd);
> + if (ret)
> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> + }
>  
> - if (ret)
> - DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> + gpiod_set_value_cansleep(sbridge->enable, 1);
>  }
>  
>  static void simple_bridge_disable(struct drm_bridge *bridge)
>  {
>   struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
>  
> + gpiod_set_value_cansleep(sbridge->enable, 0);
> +
>   if (sbridge->vdd)
>   regulator_disable(sbridge->vdd);
>  }
> @@ -205,6 +211,14 @@ static int simple_bridge_probe(struct platform_device 
> *pdev)
>   dev_dbg(>dev, "No vdd regulator found: %d\n", ret);
>   }
>  
> + sbridge->enable = devm_gpiod_get_optional(>dev, "enable",
> +   GPIOD_OUT_LOW);
> + if (IS_ERR(sbridge->enable)) {
> + if (PTR_ERR(sbridge->enable) != -EPROBE_DEFER)
> + dev_err(>dev, "Unable to retrieve enable GPIO\n");
> + return PTR_ERR(sbridge->enable);
> + }
> +
>   sbridge->ddc = simple_bridge_retrieve_ddc(>dev);
>   if (IS_ERR(sbridge->ddc)) {
>   if (PTR_ERR(sbridge->ddc) == -ENODEV) {

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

Re: [PATCH v2 08/50] drm/bridge: simple-bridge: Add support for non-VGA bridges

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:39 +0300
Laurent Pinchart  wrote:

> Create a new simple_bridge_info structure that stores information about
> the bridge model, and store the bridge timings in there, along with the
> connector type. Use that new structure for of_device_id data. This
> enables support for non-VGA bridges.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Stefan Agner 

Reviewed-by: Boris Brezillon 

> ---
> Changes since v1:
> 
> - Renamed simple_bridge_info.type field to connector_type
> ---
>  drivers/gpu/drm/bridge/simple-bridge.c | 41 ++
>  1 file changed, 29 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c 
> b/drivers/gpu/drm/bridge/simple-bridge.c
> index 7551a361f22e..85aa852eafb4 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -16,10 +16,17 @@
>  #include 
>  #include 
>  
> +struct simple_bridge_info {
> + const struct drm_bridge_timings *timings;
> + unsigned int connector_type;
> +};
> +
>  struct simple_bridge {
>   struct drm_bridge   bridge;
>   struct drm_connectorconnector;
>  
> + const struct simple_bridge_info *info;
> +
>   struct i2c_adapter  *ddc;
>   struct regulator*vdd;
>  };
> @@ -117,7 +124,7 @@ static int simple_bridge_attach(struct drm_bridge *bridge,
>_bridge_con_helper_funcs);
>   ret = drm_connector_init_with_ddc(bridge->dev, >connector,
> _bridge_con_funcs,
> -   DRM_MODE_CONNECTOR_VGA,
> +   sbridge->info->connector_type,
> sbridge->ddc);
>   if (ret) {
>   DRM_ERROR("Failed to initialize connector\n");
> @@ -187,6 +194,8 @@ static int simple_bridge_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>   platform_set_drvdata(pdev, sbridge);
>  
> + sbridge->info = of_device_get_match_data(>dev);
> +
>   sbridge->vdd = devm_regulator_get_optional(>dev, "vdd");
>   if (IS_ERR(sbridge->vdd)) {
>   int ret = PTR_ERR(sbridge->vdd);
> @@ -210,7 +219,7 @@ static int simple_bridge_probe(struct platform_device 
> *pdev)
>  
>   sbridge->bridge.funcs = _bridge_bridge_funcs;
>   sbridge->bridge.of_node = pdev->dev.of_node;
> - sbridge->bridge.timings = of_device_get_match_data(>dev);
> + sbridge->bridge.timings = sbridge->info->timings;
>  
>   drm_bridge_add(>bridge);
>  
> @@ -270,19 +279,27 @@ static const struct drm_bridge_timings 
> ti_ths8135_bridge_timings = {
>  static const struct of_device_id simple_bridge_match[] = {
>   {
>   .compatible = "dumb-vga-dac",
> - .data = NULL,
> - },
> - {
> + .data = &(const struct simple_bridge_info) {
> + .connector_type = DRM_MODE_CONNECTOR_VGA,
> + },
> + }, {
>   .compatible = "adi,adv7123",
> - .data = _bridge_timings,
> - },
> - {
> + .data = &(const struct simple_bridge_info) {
> + .timings = _bridge_timings,
> + .connector_type = DRM_MODE_CONNECTOR_VGA,
> + },
> + }, {
>   .compatible = "ti,ths8135",
> - .data = _ths8135_bridge_timings,
> - },
> - {
> + .data = &(const struct simple_bridge_info) {
> + .timings = _ths8135_bridge_timings,
> + .connector_type = DRM_MODE_CONNECTOR_VGA,
> + },
> + }, {
>   .compatible = "ti,ths8134",
> - .data = _ths8134_bridge_timings,
> + .data = &(const struct simple_bridge_info) {
> + .timings = _ths8134_bridge_timings,
> + .connector_type = DRM_MODE_CONNECTOR_VGA,
> + },
>   },
>   {},
>  };

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

Re: [PATCH v2 07/50] drm/bridge: dumb-vga-dac: Rename driver to simple-bridge

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:38 +0300
Laurent Pinchart  wrote:

> The dumb-vga-dac driver can support simple DRM bridges without being
> limited to VGA DACs. Rename it to simple-bridge.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Andrzej Hajda 

Reviewed-by: Boris Brezillon 

> ---
>  arch/arm/configs/davinci_all_defconfig   |  2 +-
>  arch/arm/configs/integrator_defconfig|  2 +-
>  arch/arm/configs/multi_v7_defconfig  |  2 +-
>  arch/arm/configs/shmobile_defconfig  |  2 +-
>  arch/arm/configs/sunxi_defconfig |  2 +-
>  arch/arm/configs/versatile_defconfig |  2 +-
>  drivers/gpu/drm/bridge/Kconfig   | 16 
>  drivers/gpu/drm/bridge/Makefile  |  2 +-
>  .../bridge/{dumb-vga-dac.c => simple-bridge.c}   |  2 +-
>  9 files changed, 16 insertions(+), 16 deletions(-)
>  rename drivers/gpu/drm/bridge/{dumb-vga-dac.c => simple-bridge.c} (99%)
> 
> diff --git a/arch/arm/configs/davinci_all_defconfig 
> b/arch/arm/configs/davinci_all_defconfig
> index 9a32a8c0f873..4b8cf51b2abd 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -155,7 +155,7 @@ CONFIG_VIDEO_TVP514X=m
>  CONFIG_VIDEO_ADV7343=m
>  CONFIG_DRM=m
>  CONFIG_DRM_TILCDC=m
> -CONFIG_DRM_DUMB_VGA_DAC=m
> +CONFIG_DRM_SIMPLE_BRIDGE=m
>  CONFIG_DRM_TINYDRM=m
>  CONFIG_TINYDRM_ST7586=m
>  CONFIG_FB=y
> diff --git a/arch/arm/configs/integrator_defconfig 
> b/arch/arm/configs/integrator_defconfig
> index 2f0a762dc3a0..a9755c501bec 100644
> --- a/arch/arm/configs/integrator_defconfig
> +++ b/arch/arm/configs/integrator_defconfig
> @@ -55,7 +55,7 @@ CONFIG_SMC91X=y
>  # CONFIG_KEYBOARD_ATKBD is not set
>  # CONFIG_SERIO_SERPORT is not set
>  CONFIG_DRM=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
>  CONFIG_DRM_PL111=y
>  CONFIG_FB_MODE_HELPERS=y
>  CONFIG_FB_MATROX=y
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 6a40bc2ef271..9eefc0cc29bc 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -644,11 +644,11 @@ CONFIG_DRM_PANEL_ORISETECH_OTM8009A=m
>  CONFIG_DRM_PANEL_RAYDIUM_RM68200=m
>  CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03=m
>  CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
> -CONFIG_DRM_DUMB_VGA_DAC=m
>  CONFIG_DRM_NXP_PTN3460=m
>  CONFIG_DRM_PARADE_PS8622=m
>  CONFIG_DRM_SII902X=m
>  CONFIG_DRM_SII9234=m
> +CONFIG_DRM_SIMPLE_BRIDGE=m
>  CONFIG_DRM_TOSHIBA_TC358764=m
>  CONFIG_DRM_I2C_ADV7511=m
>  CONFIG_DRM_I2C_ADV7511_AUDIO=y
> diff --git a/arch/arm/configs/shmobile_defconfig 
> b/arch/arm/configs/shmobile_defconfig
> index c6c70355141c..a8e7827a7214 100644
> --- a/arch/arm/configs/shmobile_defconfig
> +++ b/arch/arm/configs/shmobile_defconfig
> @@ -125,8 +125,8 @@ CONFIG_VIDEO_ADV7604=y
>  CONFIG_VIDEO_ML86V7667=y
>  CONFIG_DRM=y
>  CONFIG_DRM_RCAR_DU=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
>  CONFIG_DRM_SII902X=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
>  CONFIG_DRM_I2C_ADV7511=y
>  CONFIG_DRM_I2C_ADV7511_AUDIO=y
>  CONFIG_FB_SH_MOBILE_LCDC=y
> diff --git a/arch/arm/configs/sunxi_defconfig 
> b/arch/arm/configs/sunxi_defconfig
> index df433abfcb02..19cccae84a19 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -99,7 +99,7 @@ CONFIG_RC_DEVICES=y
>  CONFIG_IR_SUNXI=y
>  CONFIG_DRM=y
>  CONFIG_DRM_SUN4I=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
>  CONFIG_FB_SIMPLE=y
>  CONFIG_SOUND=y
>  CONFIG_SND=y
> diff --git a/arch/arm/configs/versatile_defconfig 
> b/arch/arm/configs/versatile_defconfig
> index fe4d4b596585..767935337413 100644
> --- a/arch/arm/configs/versatile_defconfig
> +++ b/arch/arm/configs/versatile_defconfig
> @@ -59,7 +59,7 @@ CONFIG_GPIO_PL061=y
>  CONFIG_DRM=y
>  CONFIG_DRM_PANEL_ARM_VERSATILE=y
>  CONFIG_DRM_PANEL_SIMPLE=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
>  CONFIG_DRM_PL111=y
>  CONFIG_FB_MODE_HELPERS=y
>  CONFIG_BACKLIGHT_CLASS_DEVICE=y
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 1cc9f502c1f2..d0146438b0f5 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -37,14 +37,6 @@ config DRM_CDNS_DSI
> Support Cadence DPI to DSI bridge. This is an internal
> bridge and is meant to be directly embedded in a SoC.
>  
> -config DRM_DUMB_VGA_DAC
> - tristate "Dumb VGA DAC Bridge support"
> - depends on OF
> - select DRM_KMS_HELPER
> - help
> -   Support for non-programmable RGB to VGA DAC bridges, such as ADI
> -   ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> -
>  config DRM_LVDS_ENCODER
>   tristate "Transparent parallel to LVDS encoder support"
>   depends on OF
> @@ -109,6 +101,14 @@ config DRM_SII9234
> It is an I2C driver, that detects connection of MHL bridge
> and starts encapsulation of HDMI signal.
>  
> +config DRM_SIMPLE_BRIDGE
> + 

Re: [PATCH v2 06/50] drm/bridge: dumb-vga-dac: Rename internal symbols to simple-bridge

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:37 +0300
Laurent Pinchart  wrote:

> The dumb-vga-dac driver is a simple DRM bridge driver for simple VGA
> DACs that don't require configuration. Other non-VGA bridges fall in a
> similar category, and would benefit from a common driver. Prepare for
> this by renaming the internal symbols from dumb-vga-dac to
> simple-bridge.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Andrzej Hajda 

Reviewed-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/bridge/dumb-vga-dac.c | 154 +-
>  1 file changed, 77 insertions(+), 77 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index 74ebca58eb1f..03ceb0cd8b9e 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -16,7 +16,7 @@
>  #include 
>  #include 
>  
> -struct dumb_vga {
> +struct simple_bridge {
>   struct drm_bridge   bridge;
>   struct drm_connectorconnector;
>  
> @@ -24,28 +24,28 @@ struct dumb_vga {
>   struct regulator*vdd;
>  };
>  
> -static inline struct dumb_vga *
> -drm_bridge_to_dumb_vga(struct drm_bridge *bridge)
> +static inline struct simple_bridge *
> +drm_bridge_to_simple_bridge(struct drm_bridge *bridge)
>  {
> - return container_of(bridge, struct dumb_vga, bridge);
> + return container_of(bridge, struct simple_bridge, bridge);
>  }
>  
> -static inline struct dumb_vga *
> -drm_connector_to_dumb_vga(struct drm_connector *connector)
> +static inline struct simple_bridge *
> +drm_connector_to_simple_bridge(struct drm_connector *connector)
>  {
> - return container_of(connector, struct dumb_vga, connector);
> + return container_of(connector, struct simple_bridge, connector);
>  }
>  
> -static int dumb_vga_get_modes(struct drm_connector *connector)
> +static int simple_bridge_get_modes(struct drm_connector *connector)
>  {
> - struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> + struct simple_bridge *sbridge = 
> drm_connector_to_simple_bridge(connector);
>   struct edid *edid;
>   int ret;
>  
> - if (!vga->ddc)
> + if (!sbridge->ddc)
>   goto fallback;
>  
> - edid = drm_get_edid(connector, vga->ddc);
> + edid = drm_get_edid(connector, sbridge->ddc);
>   if (!edid) {
>   DRM_INFO("EDID readout failed, falling back to standard 
> modes\n");
>   goto fallback;
> @@ -69,14 +69,14 @@ static int dumb_vga_get_modes(struct drm_connector 
> *connector)
>   return ret;
>  }
>  
> -static const struct drm_connector_helper_funcs dumb_vga_con_helper_funcs = {
> - .get_modes  = dumb_vga_get_modes,
> +static const struct drm_connector_helper_funcs 
> simple_bridge_con_helper_funcs = {
> + .get_modes  = simple_bridge_get_modes,
>  };
>  
>  static enum drm_connector_status
> -dumb_vga_connector_detect(struct drm_connector *connector, bool force)
> +simple_bridge_connector_detect(struct drm_connector *connector, bool force)
>  {
> - struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> + struct simple_bridge *sbridge = 
> drm_connector_to_simple_bridge(connector);
>  
>   /*
>* Even if we have an I2C bus, we can't assume that the cable
> @@ -84,14 +84,14 @@ dumb_vga_connector_detect(struct drm_connector 
> *connector, bool force)
>* wire the DDC pins, or the I2C bus might not be working at
>* all.
>*/
> - if (vga->ddc && drm_probe_ddc(vga->ddc))
> + if (sbridge->ddc && drm_probe_ddc(sbridge->ddc))
>   return connector_status_connected;
>  
>   return connector_status_unknown;
>  }
>  
> -static const struct drm_connector_funcs dumb_vga_con_funcs = {
> - .detect = dumb_vga_connector_detect,
> +static const struct drm_connector_funcs simple_bridge_con_funcs = {
> + .detect = simple_bridge_connector_detect,
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .destroy= drm_connector_cleanup,
>   .reset  = drm_atomic_helper_connector_reset,
> @@ -99,10 +99,10 @@ static const struct drm_connector_funcs 
> dumb_vga_con_funcs = {
>   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
>  };
>  
> -static int dumb_vga_attach(struct drm_bridge *bridge,
> -enum drm_bridge_attach_flags flags)
> +static int simple_bridge_attach(struct drm_bridge *bridge,
> + enum drm_bridge_attach_flags flags)
>  {
> - struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> + struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
>   int ret;
>  
>   if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> @@ -113,50 +113,50 @@ static int dumb_vga_attach(struct drm_bridge *bridge,
>   return -ENODEV;
>   }
>  
> - drm_connector_helper_add(>connector,
> -  

Re: [PATCH v2 05/50] drm/bridge: Extend bridge API to disable connector creation

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:36 +0300
Laurent Pinchart  wrote:

> Most bridge drivers create a DRM connector to model the connector at the
> output of the bridge. This model is historical and has worked pretty
> well so far, but causes several issues:
> 
> - It prevents supporting more complex display pipelines where DRM
> connector operations are split over multiple components. For instance a
> pipeline with a bridge connected to the DDC signals to read EDID data,
> and another one connected to the HPD signal to detect connection and
> disconnection, will not be possible to support through this model.
> 
> - It requires every bridge driver to implement similar connector
> handling code, resulting in code duplication.
> 
> - It assumes that a bridge will either be wired to a connector or to
> another bridge, but doesn't support bridges that can be used in both
> positions very well (although there is some ad-hoc support for this in
> the analogix_dp bridge driver).
> 
> In order to solve these issues, ownership of the connector should be
> moved to the display controller driver (where it can be implemented
> using helpers provided by the core).
> 
> Extend the bridge API to allow disabling connector creation in bridge
> drivers as a first step towards the new model. The new create_connector
> argument to the bridge .attach() operation tells the bridge driver
> whether to create a connector. Set the argument to true unconditionally,

You're talking about the extra arg passed to drm_bridge_attach(), right?
I guess this commit message reflects the old implementation where
the extra arg was a boolean.

> and modify all existing bridge drivers to return an error when connector
> creation is not requested as they don't support this feature yet.
> 
> The change is based on the following semantic patch, with manual review
> and edits.
> 
> @ rule1 @
> identifier funcs;
> identifier fn;
> @@
>  struct drm_bridge_funcs funcs = {
>   ...,
>   .attach = fn
>  };
> 
> @ depends on rule1 @
> identifier rule1.fn;
> identifier bridge;
> statement S, S1;
> @@
>  int fn(
>   struct drm_bridge *bridge
> + , enum drm_bridge_attach_flags flags
>  )
>  {
>   ... when != S
> + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> + return -EINVAL;
> +
>   S1
>   ...
>  }
> 
> @@
> expression E1, E2, E3;
> @@
>  drm_bridge_attach(E1, E2, E3
> + , 0
>  )
> 
> Signed-off-by: Laurent Pinchart 

Haven't gone through the diff but the semantic patch looks good, and
I'm pretty sure you compiled all drivers implementing the attach hook
and/or calling drm_bridge_attach().

Reviewed-by: Boris Brezillon 

> ---
> Changes since v1:
> 
> - Replace the create_connector boolean with a flags bitmask
> - Update ingenic driver
> - Add semantic patch to commit message
> ---
>  drivers/gpu/drm/arc/arcpgu_hdmi.c |  2 +-
>  .../gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c  |  2 +-
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c  |  6 +-
>  drivers/gpu/drm/bridge/analogix-anx78xx.c |  6 +-
>  .../drm/bridge/analogix/analogix_dp_core.c|  8 ++--
>  drivers/gpu/drm/bridge/cdns-dsi.c |  6 --
>  drivers/gpu/drm/bridge/dumb-vga-dac.c |  6 +-
>  drivers/gpu/drm/bridge/lvds-encoder.c |  5 +++--
>  .../bridge/megachips-stdp-ge-b850v3-fw.c  |  6 +-
>  drivers/gpu/drm/bridge/nxp-ptn3460.c  |  6 +-
>  drivers/gpu/drm/bridge/panel.c|  6 +-
>  drivers/gpu/drm/bridge/parade-ps8622.c|  6 +-
>  drivers/gpu/drm/bridge/sii902x.c  |  6 +-
>  drivers/gpu/drm/bridge/sil-sii8620.c  |  3 ++-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  8 ++--
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c |  8 +---
>  drivers/gpu/drm/bridge/tc358764.c |  6 +-
>  drivers/gpu/drm/bridge/tc358767.c |  6 +-
>  drivers/gpu/drm/bridge/thc63lvd1024.c |  5 +++--
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c |  6 +-
>  drivers/gpu/drm/bridge/ti-tfp410.c|  6 +-
>  drivers/gpu/drm/drm_bridge.c  |  6 --
>  drivers/gpu/drm/drm_simple_kms_helper.c   |  2 +-
>  drivers/gpu/drm/exynos/exynos_dp.c|  3 ++-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  4 ++--
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c |  2 +-
>  drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c  |  2 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c |  8 ++--
>  drivers/gpu/drm/imx/imx-ldb.c |  2 +-
>  drivers/gpu/drm/imx/parallel-display.c|  2 +-
>  drivers/gpu/drm/ingenic/ingenic-drm.c |  2 +-
>  drivers/gpu/drm/mcde/mcde_dsi.c   |  8 ++--
>  drivers/gpu/drm/mediatek/mtk_dpi.c|  2 +-
>  drivers/gpu/drm/mediatek/mtk_dsi.c|  2 +-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  8 ++--
>  

Re: [PATCH v2 04/50] drm/bridge: Add connector-related bridge operations and data

2019-08-22 Thread Boris Brezillon
On Tue, 20 Aug 2019 04:16:35 +0300
Laurent Pinchart  wrote:

> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations and
> data:
> 
> - Output detection, hot-plug notification, mode retrieval and EDID
>   retrieval operations
> - Bitmask of supported operations
> - Bridge output type
> - I2C adapter for DDC access
> 
> Add and document these.
> 
> Three new bridge helper functions are also added to handle hot plug
> notification in a way that is as transparent as possible for the
> bridges.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Boris Brezillon 

> ---
> Changes since v1:
> 
> - Make .hpd_enable() and .hpd_disable() optional
> - Rename .lost_hotplug() to .hpd_notify()
> - Add ddc field to drm_bridge
> ---
>  drivers/gpu/drm/drm_bridge.c |  94 +++
>  include/drm/drm_bridge.h | 177 ++-
>  2 files changed, 270 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index cba537c99e43..cf1fbed88410 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>   */
>  void drm_bridge_add(struct drm_bridge *bridge)
>  {
> + mutex_init(>hpd_mutex);
> +
>   mutex_lock(_lock);
>   list_add_tail(>list, _list);
>   mutex_unlock(_lock);
> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>   mutex_lock(_lock);
>   list_del_init(>list);
>   mutex_unlock(_lock);
> +
> + mutex_destroy(>hpd_mutex);
>  }
>  EXPORT_SYMBOL(drm_bridge_remove);
>  
> @@ -462,6 +466,96 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>  }
>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
>  
> +/**
> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> + * @bridge: bridge control structure
> + * @cb: hot-plug detection callback
> + * @data: data to be passed to the hot-plug detection callback
> + *
> + * Call _bridge_funcs.hpd_enable if implemented and register the given 
> @cb
> + * and @data as hot plug notification callback. From now on the @cb will be
> + * called with @data when an output status change is detected by the bridge,
> + * until hot plug notification gets disabled with drm_bridge_hpd_disable().
> + *
> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set 
> in
> + * bridge->ops. This function shall not be called when the flag is not set.
> + *
> + * Only one hot plug detection callback can be registered at a time, it is an
> + * error to call this function when hot plug detection is already enabled for
> + * the bridge.
> + */
> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> +void (*cb)(void *data,
> +   enum drm_connector_status status),
> +void *data)
> +{
> + if (!bridge || !(bridge->ops & DRM_BRIDGE_OP_HPD))
> + return;
> +
> + mutex_lock(>hpd_mutex);
> +
> + if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> + goto unlock;
> +
> + bridge->hpd_cb = cb;
> + bridge->hpd_data = data;
> +
> + if (bridge->funcs->hpd_enable)
> + bridge->funcs->hpd_enable(bridge);
> +
> +unlock:
> + mutex_unlock(>hpd_mutex);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> +
> +/**
> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> + * @bridge: bridge control structure
> + *
> + * Call _bridge_funcs.hpd_disable if implemented and unregister the hot
> + * plug detection callback previously registered with 
> drm_bridge_hpd_enable().
> + * Once this function returns the callback will not be called by the bridge
> + * when an output status change occurs.
> + *
> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set 
> in
> + * bridge->ops. This function shall not be called when the flag is not set.
> + */
> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> +{
> + if (!bridge || !(bridge->ops & DRM_BRIDGE_OP_HPD))
> + return;
> +
> + mutex_lock(>hpd_mutex);
> + if (bridge->funcs->hpd_disable)
> + bridge->funcs->hpd_disable(bridge);
> +
> + bridge->hpd_cb = NULL;
> + bridge->hpd_data = NULL;
> + mutex_unlock(>hpd_mutex);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> +
> +/**
> + * drm_bridge_hpd_notify - notify hot plug detection events
> + * @bridge: bridge control structure
> + * @status: output connection status
> + *
> + * Bridge drivers shall call this function to report hot plug events when 
> they
> + * detect a change in the output status, when hot plug detection has been
> + * enabled by drm_bridge_hpd_enable().
> + *
> + * This function shall be called in a context that can sleep.
> + */
> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> +enum drm_connector_status 

[PATCH v9 2/6] drm: Move port definition back to i915 header

2019-08-22 Thread Ramalingam C
Handled the need for exposing enum port to mei_hdcp driver, by
converting the port into ddi index as per ME FW and sending to mei_hdcp.

Hence move enum port definition into I915 driver itself.

v2:
  intel_display.h is included in intel_hdcp.h
v3:
  enum port is declared in headers.

Signed-off-by: Ramalingam C 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_bios.h|  1 +
 drivers/gpu/drm/i915/display/intel_display.h | 18 ++
 drivers/gpu/drm/i915/display/intel_dp.h  |  1 +
 drivers/gpu/drm/i915/display/intel_hdcp.h|  1 +
 drivers/gpu/drm/i915/display/intel_hdmi.h|  1 +
 drivers/gpu/drm/i915/display/intel_hotplug.h |  1 +
 drivers/gpu/drm/i915/display/intel_sdvo.h|  1 +
 include/drm/i915_drm.h   | 18 --
 8 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.h 
b/drivers/gpu/drm/i915/display/intel_bios.h
index 4969189e620f..4c6e56a3940a 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -35,6 +35,7 @@
 #include 
 
 struct drm_i915_private;
+enum port;
 
 enum intel_backlight_type {
INTEL_BACKLIGHT_PMIC,
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index e57e6969051d..40610d51327e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -182,6 +182,24 @@ enum plane_id {
for ((__p) = PLANE_PRIMARY; (__p) < I915_MAX_PLANES; (__p)++) \
for_each_if((__crtc)->plane_ids_mask & BIT(__p))
 
+enum port {
+   PORT_NONE = -1,
+
+   PORT_A = 0,
+   PORT_B,
+   PORT_C,
+   PORT_D,
+   PORT_E,
+   PORT_F,
+   PORT_G,
+   PORT_H,
+   PORT_I,
+
+   I915_MAX_PORTS
+};
+
+#define port_name(p) ((p) + 'A')
+
 /*
  * Ports identifier referenced from other drivers.
  * Expected to remain stable over time
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index 657bbb1f5ed0..e01d1f89409d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -13,6 +13,7 @@
 #include "i915_reg.h"
 
 enum pipe;
+enum port;
 struct drm_connector_state;
 struct drm_encoder;
 struct drm_i915_private;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 13555b054930..59a2b40405cc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -15,6 +15,7 @@ struct drm_connector_state;
 struct drm_i915_private;
 struct intel_connector;
 struct intel_hdcp_shim;
+enum port;
 
 void intel_hdcp_atomic_check(struct drm_connector *connector,
 struct drm_connector_state *old_state,
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.h 
b/drivers/gpu/drm/i915/display/intel_hdmi.h
index 106c2e0bc3c9..cf1ea5427639 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.h
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.h
@@ -23,6 +23,7 @@ struct intel_crtc_state;
 struct intel_hdmi;
 struct drm_connector_state;
 union hdmi_infoframe;
+enum port;
 
 void intel_hdmi_init(struct drm_i915_private *dev_priv, i915_reg_t hdmi_reg,
 enum port port);
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.h 
b/drivers/gpu/drm/i915/display/intel_hotplug.h
index b0cd447b7fbc..087b5f57b321 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.h
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.h
@@ -13,6 +13,7 @@
 struct drm_i915_private;
 struct intel_connector;
 struct intel_encoder;
+enum port;
 
 void intel_hpd_poll_init(struct drm_i915_private *dev_priv);
 enum intel_hotplug_state intel_encoder_hotplug(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.h 
b/drivers/gpu/drm/i915/display/intel_sdvo.h
index c9e05bcdd141..a66f224aa17d 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.h
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.h
@@ -14,6 +14,7 @@
 
 struct drm_i915_private;
 enum pipe;
+enum port;
 
 bool intel_sdvo_port_enabled(struct drm_i915_private *dev_priv,
 i915_reg_t sdvo_reg, enum pipe *pipe);
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 23274cf92712..6722005884db 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -100,22 +100,4 @@ extern struct resource intel_graphics_stolen_res;
 #define INTEL_GEN11_BSM_DW10xc4
 #define   INTEL_BSM_MASK   (-(1u << 20))
 
-enum port {
-   PORT_NONE = -1,
-
-   PORT_A = 0,
-   PORT_B,
-   PORT_C,
-   PORT_D,
-   PORT_E,
-   PORT_F,
-   PORT_G,
-   PORT_H,
-   PORT_I,
-
-   I915_MAX_PORTS
-};
-
-#define port_name(p) ((p) + 'A')
-
 #endif /* _I915_DRM_H_ */
-- 
2.20.1

___
dri-devel mailing list

[PATCH v9 4/6] misc/mei/hdcp: Fill transcoder index in port info

2019-08-22 Thread Ramalingam C
For gen12+ platform we need to pass the transcoder info
as part of the port info into ME FW.

This change fills the payload for ME FW from hdcp_port_data.

Signed-off-by: Ramalingam C 
Acked-by: Jani Nikula 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
 drivers/misc/mei/hdcp/mei_hdcp.h |  4 +++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 3638c77eba26..93027fd96c71 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -58,6 +58,7 @@ mei_hdcp_initiate_session(struct device *dev, struct 
hdcp_port_data *data,
 
session_init_in.port.integrated_port_type = data->port_type;
session_init_in.port.physical_port = (u8)data->fw_ddi;
+   session_init_in.port.attached_transcoder = (u8)data->fw_tc;
session_init_in.protocol = data->protocol;
 
byte = mei_cldev_send(cldev, (u8 *)_init_in,
@@ -127,6 +128,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
 
verify_rxcert_in.port.integrated_port_type = data->port_type;
verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
+   verify_rxcert_in.port.attached_transcoder = (u8)data->fw_tc;
 
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -197,6 +199,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct 
hdcp_port_data *data,
 
send_hprime_in.port.integrated_port_type = data->port_type;
send_hprime_in.port.physical_port = (u8)data->fw_ddi;
+   send_hprime_in.port.attached_transcoder = (u8)data->fw_tc;
 
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
   HDCP_2_2_H_PRIME_LEN);
@@ -254,6 +257,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct 
hdcp_port_data *data,
 
pairing_info_in.port.integrated_port_type = data->port_type;
pairing_info_in.port.physical_port = (u8)data->fw_ddi;
+   pairing_info_in.port.attached_transcoder = (u8)data->fw_tc;
 
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
   HDCP_2_2_E_KH_KM_LEN);
@@ -312,6 +316,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
 
lc_init_in.port.integrated_port_type = data->port_type;
lc_init_in.port.physical_port = (u8)data->fw_ddi;
+   lc_init_in.port.attached_transcoder = (u8)data->fw_tc;
 
byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
if (byte < 0) {
@@ -367,6 +372,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct 
hdcp_port_data *data,
 
verify_lprime_in.port.integrated_port_type = data->port_type;
verify_lprime_in.port.physical_port = (u8)data->fw_ddi;
+   verify_lprime_in.port.attached_transcoder = (u8)data->fw_tc;
 
memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
   HDCP_2_2_L_PRIME_LEN);
@@ -424,6 +430,7 @@ static int mei_hdcp_get_session_key(struct device *dev,
 
get_skey_in.port.integrated_port_type = data->port_type;
get_skey_in.port.physical_port = (u8)data->fw_ddi;
+   get_skey_in.port.attached_transcoder = (u8)data->fw_tc;
 
byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
if (byte < 0) {
@@ -488,6 +495,7 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct device *dev,
 
verify_repeater_in.port.integrated_port_type = data->port_type;
verify_repeater_in.port.physical_port = (u8)data->fw_ddi;
+   verify_repeater_in.port.attached_transcoder = (u8)data->fw_tc;
 
memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
   HDCP_2_2_RXINFO_LEN);
@@ -558,6 +566,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
 
verify_mprime_in.port.integrated_port_type = data->port_type;
verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
+   verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
 
memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
   HDCP_2_2_MPRIME_LEN);
@@ -619,6 +628,7 @@ static int mei_hdcp_enable_authentication(struct device 
*dev,
 
enable_auth_in.port.integrated_port_type = data->port_type;
enable_auth_in.port.physical_port = (u8)data->fw_ddi;
+   enable_auth_in.port.attached_transcoder = (u8)data->fw_tc;
enable_auth_in.stream_type = data->streams[0].stream_type;
 
byte = mei_cldev_send(cldev, (u8 *)_auth_in,
@@ -673,6 +683,7 @@ mei_hdcp_close_session(struct device *dev, struct 
hdcp_port_data *data)
 
session_close_in.port.integrated_port_type = data->port_type;
session_close_in.port.physical_port = (u8)data->fw_ddi;
+   session_close_in.port.attached_transcoder = (u8)data->fw_tc;
 
byte = mei_cldev_send(cldev, (u8 *)_close_in,
  sizeof(session_close_in));
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
index e60282eb2d48..58e439d2fc1a 

[PATCH v9 0/6] drm/i915: Enable HDCP 1.4 and 2.2 on Gen12+

2019-08-22 Thread Ramalingam C
Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
from DDI into transcoder.

v9:
  s/trans/cpu_transcoder
  enum port and transcoders are declared at few headers.

Ramalingam C (6):
  drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
  drm: Move port definition back to i915 header
  drm: Extend I915 mei interface for transcoder info
  misc/mei/hdcp: Fill transcoder index in port info
  drm/i915/hdcp: update current transcoder into  intel_hdcp
  drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+

 drivers/gpu/drm/i915/display/intel_bios.h |   1 +
 drivers/gpu/drm/i915/display/intel_display.h  |  18 ++
 .../drm/i915/display/intel_display_types.h|   7 +
 drivers/gpu/drm/i915/display/intel_dp.c   |   3 +
 drivers/gpu/drm/i915/display/intel_dp.h   |   1 +
 drivers/gpu/drm/i915/display/intel_hdcp.c | 210 +-
 drivers/gpu/drm/i915/display/intel_hdcp.h |   4 +
 drivers/gpu/drm/i915/display/intel_hdmi.c |  13 +-
 drivers/gpu/drm/i915/display/intel_hdmi.h |   1 +
 drivers/gpu/drm/i915/display/intel_hotplug.h  |   1 +
 drivers/gpu/drm/i915/display/intel_sdvo.h |   1 +
 drivers/gpu/drm/i915/i915_reg.h   | 124 ++-
 drivers/misc/mei/hdcp/mei_hdcp.c  |  45 ++--
 drivers/misc/mei/hdcp/mei_hdcp.h  |  16 +-
 include/drm/i915_drm.h|  18 --
 include/drm/i915_mei_hdcp_interface.h |  29 ++-
 16 files changed, 372 insertions(+), 120 deletions(-)

-- 
2.20.1

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

[PATCH v9 6/6] drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+

2019-08-22 Thread Ramalingam C
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.

Hence required changes in HW programming is handled here.

As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in hdcp_port_data.

v2:
  _MMIO_TRANS is used [Lucas and Daniel]
  platform check is moved into the caller [Lucas]
v3:
  platform check is moved into a macro [Shashank]
v4:
  Few optimizations in the coding [Shashank]
v5:
  Fixed alignment in macro definition in i915_reg.h [Shashank]
  unused variables "reg" is removed.
v6:
  Configuring the transcoder at compute_config.
  transcoder is used instead of pipe in macros.
  Rebased.
v7:
  transcoder is cached at intel_hdcp
  hdcp_port_data is configured with transcoder index asper ME FW.
v8:
  s/trans/cpu_transcoder
  s/tc/cpu_transcoder

Signed-off-by: Ramalingam C 
Reviewed-by: Shashank Sharma  [v5]
Acked-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 148 ++
 drivers/gpu/drm/i915/display/intel_hdmi.c |  10 +-
 drivers/gpu/drm/i915/i915_reg.h   | 124 --
 3 files changed, 219 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 1e5548833e8f..e2084403db27 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -18,6 +18,7 @@
 #include "intel_display_types.h"
 #include "intel_hdcp.h"
 #include "intel_sideband.h"
+#include "intel_connector.h"
 
 #define KEY_LOAD_TRIES 5
 #define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS   50
@@ -105,24 +106,20 @@ bool intel_hdcp2_capable(struct intel_connector 
*connector)
return capable;
 }
 
-static inline bool intel_hdcp_in_use(struct intel_connector *connector)
+static inline
+bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
+  enum transcoder cpu_transcoder, enum port port)
 {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   enum port port = connector->encoder->port;
-   u32 reg;
-
-   reg = I915_READ(PORT_HDCP_STATUS(port));
-   return reg & HDCP_STATUS_ENC;
+   return I915_READ(HDCP_STATUS(dev_priv, cpu_transcoder, port)) &
+  HDCP_STATUS_ENC;
 }
 
-static inline bool intel_hdcp2_in_use(struct intel_connector *connector)
+static inline
+bool intel_hdcp2_in_use(struct drm_i915_private *dev_priv,
+   enum transcoder cpu_transcoder, enum port port)
 {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   enum port port = connector->encoder->port;
-   u32 reg;
-
-   reg = I915_READ(HDCP2_STATUS_DDI(port));
-   return reg & LINK_ENCRYPTION_STATUS;
+   return I915_READ(HDCP2_STATUS(dev_priv, cpu_transcoder, port)) &
+  LINK_ENCRYPTION_STATUS;
 }
 
 static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
@@ -253,9 +250,28 @@ static int intel_write_sha_text(struct drm_i915_private 
*dev_priv, u32 sha_text)
 }
 
 static
-u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port *intel_dig_port)
+u32 intel_hdcp_get_repeater_ctl(struct drm_i915_private *dev_priv,
+   enum transcoder cpu_transcoder, enum port port)
 {
-   enum port port = intel_dig_port->base.port;
+   if (INTEL_GEN(dev_priv) >= 12) {
+   switch (cpu_transcoder) {
+   case TRANSCODER_A:
+   return HDCP_TRANSA_REP_PRESENT |
+  HDCP_TRANSA_SHA1_M0;
+   case TRANSCODER_B:
+   return HDCP_TRANSB_REP_PRESENT |
+  HDCP_TRANSB_SHA1_M0;
+   case TRANSCODER_C:
+   return HDCP_TRANSC_REP_PRESENT |
+  HDCP_TRANSC_SHA1_M0;
+   /* FIXME: Add a case for PIPE_D */
+   default:
+   DRM_ERROR("Unknown transcoder %d\n", cpu_transcoder);
+   break;
+   }
+   return -EINVAL;
+   }
+
switch (port) {
case PORT_A:
return HDCP_DDIA_REP_PRESENT | HDCP_DDIA_SHA1_M0;
@@ -268,18 +284,21 @@ u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port 
*intel_dig_port)
case PORT_E:
return HDCP_DDIE_REP_PRESENT | HDCP_DDIE_SHA1_M0;
default:
+   DRM_ERROR("Unknown port %d\n", port);
break;
}
-   DRM_ERROR("Unknown port %d\n", port);
return -EINVAL;
 }
 
 static
-int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
+int intel_hdcp_validate_v_prime(struct intel_connector *connector,
const struct intel_hdcp_shim *shim,
u8 *ksv_fifo, u8 num_downstream, u8 *bstatus)
 {
+   struct intel_digital_port *intel_dig_port = 

[PATCH v9 3/6] drm: Extend I915 mei interface for transcoder info

2019-08-22 Thread Ramalingam C
I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_ddi and add as a member into
the struct hdcp_port_data.

Signed-off-by: Ramalingam C 
Acked-by: Jani Nikula 
---
 include/drm/i915_mei_hdcp_interface.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/drm/i915_mei_hdcp_interface.h 
b/include/drm/i915_mei_hdcp_interface.h
index a97acf1c9710..0de629bf2f62 100644
--- a/include/drm/i915_mei_hdcp_interface.h
+++ b/include/drm/i915_mei_hdcp_interface.h
@@ -54,9 +54,21 @@ enum mei_fw_ddi {
MEI_DDI_RANGE_END = MEI_DDI_A,
 };
 
+enum mei_fw_tc {
+   MEI_INVALID_TRANSCODER = 0x00,  /* Invalid transcoder type */
+   MEI_TC_EDP, /* Transcoder for eDP */
+   MEI_TC_DSI0,/* Transcoder for DSI0 */
+   MEI_TC_DSI1,/* Transcoder for DSI1 */
+   MEI_TC_A = 0x10,/* Transcoder TCA */
+   MEI_TC_B,   /* Transcoder TCB */
+   MEI_TC_C,   /* Transcoder TCC */
+   MEI_TC_D/* Transcoder TCD */
+};
+
 /**
  * struct hdcp_port_data - intel specific HDCP port data
  * @fw_ddi: ddi index as per ME FW
+ * @fw_tc: transcoder index as per ME FW
  * @port_type: HDCP port type as per ME FW classification
  * @protocol: HDCP adaptation as per ME FW
  * @k: No of streams transmitted on a port. Only on DP MST this is != 1
@@ -69,6 +81,7 @@ enum mei_fw_ddi {
  */
 struct hdcp_port_data {
enum mei_fw_ddi fw_ddi;
+   enum mei_fw_tc fw_tc;
u8 port_type;
u8 protocol;
u16 k;
-- 
2.20.1

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

[PATCH v9 1/6] drm/i915: mei_hdcp: I915 sends ddi index as per ME FW

2019-08-22 Thread Ramalingam C
I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.

Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.

Signed-off-by: Ramalingam C 
Acked-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +-
 drivers/misc/mei/hdcp/mei_hdcp.c  | 34 ---
 drivers/misc/mei/hdcp/mei_hdcp.h  | 12 
 include/drm/i915_mei_hdcp_interface.h | 16 +--
 4 files changed, 39 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6ec5ceeab601..534832f435dc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1749,13 +1749,26 @@ static const struct component_ops 
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
 };
 
+static inline
+enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port port)
+{
+   switch (port) {
+   case PORT_A:
+   return MEI_DDI_A;
+   case PORT_B ... PORT_F:
+   return (enum mei_fw_ddi)port;
+   default:
+   return MEI_DDI_INVALID_PORT;
+   }
+}
+
 static inline int initialize_hdcp_port_data(struct intel_connector *connector,
const struct intel_hdcp_shim *shim)
 {
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
 
-   data->port = connector->encoder->port;
+   data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
data->protocol = (u8)shim->protocol;
 
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index c681f6fab342..3638c77eba26 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -27,18 +27,6 @@
 
 #include "mei_hdcp.h"
 
-static inline u8 mei_get_ddi_index(enum port port)
-{
-   switch (port) {
-   case PORT_A:
-   return MEI_DDI_A;
-   case PORT_B ... PORT_F:
-   return (u8)port;
-   default:
-   return MEI_DDI_INVALID_PORT;
-   }
-}
-
 /**
  * mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
  * @dev: device corresponding to the mei_cl_device
@@ -69,7 +57,7 @@ mei_hdcp_initiate_session(struct device *dev, struct 
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
 
session_init_in.port.integrated_port_type = data->port_type;
-   session_init_in.port.physical_port = mei_get_ddi_index(data->port);
+   session_init_in.port.physical_port = (u8)data->fw_ddi;
session_init_in.protocol = data->protocol;
 
byte = mei_cldev_send(cldev, (u8 *)_init_in,
@@ -138,7 +126,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
 
verify_rxcert_in.port.integrated_port_type = data->port_type;
-   verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
+   verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
 
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -208,7 +196,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct 
hdcp_port_data *data,
send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
 
send_hprime_in.port.integrated_port_type = data->port_type;
-   send_hprime_in.port.physical_port = mei_get_ddi_index(data->port);
+   send_hprime_in.port.physical_port = (u8)data->fw_ddi;
 
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
   HDCP_2_2_H_PRIME_LEN);
@@ -265,7 +253,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct 
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
 
pairing_info_in.port.integrated_port_type = data->port_type;
-   pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
+   pairing_info_in.port.physical_port = (u8)data->fw_ddi;
 
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
   HDCP_2_2_E_KH_KM_LEN);
@@ -323,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
 
lc_init_in.port.integrated_port_type = data->port_type;
-   lc_init_in.port.physical_port = mei_get_ddi_index(data->port);
+   lc_init_in.port.physical_port = (u8)data->fw_ddi;
 
byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
if (byte < 0) {
@@ -378,7 +366,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct 
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_VALIDATE_LOCALITY_IN;
 

  1   2   3   >