[Bug 105076] [CI] results file indicate incomplete run.log say other result

[bugzilla-daemon]

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

--- Comment #4 from Marta Löfstedt  ---
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3779/shard-glkb1/igt@kms_...@pipe-b-bad-aux-stride.html

-- 
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 105076] [CI] results file indicate incomplete run.log say other result

[bugzilla-daemon]

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

--- Comment #3 from Marta Löfstedt  ---
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4258/shard-glkb1/igt@drm_vma_limiter_cached.html

run.log has finished

-- 
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 v5 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

[Heiko Stuebner]

Am Mittwoch, 14. Februar 2018, 21:08:59 CET schrieb Jernej Skrabec:
> dw_hdmi shouldn't set drvdata since some drivers might need to store
> it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
> instead to store it in drvdata. This way drivers are responsible to
> store and pass structure when needed.
> 
> Idea was taken from the following commit:
> 8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata")
> 
> Cc: p.za...@pengutronix.de
> Cc: narmstr...@baylibre.com
> Cc: laurent.pinch...@ideasonboard.com
> Cc: h...@rock-chips.com
> Cc: he...@sntech.de
> Acked-by: Neil Armstrong 
> Signed-off-by: Jernej Skrabec 

For the Rockchip-part
Tested-by: Heiko Stuebner 
Acked-by: Heiko Stuebner 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104597] [bisected] Compton weird colors

[bugzilla-daemon]

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

--- Comment #12 from gloriouseggr...@gmail.com ---
(In reply to Mario Kleiner from comment #5)
> Can you try what happens if you add the following snippet
> inside the  section of your /etc/drirc and restart compton?
> 
> 
> 
> 
> 
> The output of xdpyinfo and glxinfo could also be useful.
> 
> To disable the new rgb10 support globally, one can add this snippet instead:
> 
> 

adding this for obs resolves
https://bugs.freedesktop.org/show_bug.cgi?id=104540


 


-- 
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 104597] [bisected] Compton weird colors

[bugzilla-daemon]

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

--- Comment #11 from gloriouseggr...@gmail.com ---
(In reply to Mario Kleiner from comment #10)
> Created attachment 137087 [details] [review]
> Possible fix, tested against server 1.19 branch.
> 
> This patch fixes the problem with compton, as tested against server 1.19
> branch. Also applies cleanly against master, but i haven't tested it on
> master yet.
> 
> So far tested with KDE-5, compiz, and compton, on ati-ddx under Radeon gfx,
> both screen depth 24 and 30.

tested here 1.19 as well, sadly does not fix the issue with OBS xcomposite
window capture mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=104540

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

[git pull] drm fixes for 4.16-rc2

[Dave Airlie]

Hi Linus,

One nouveau regression fix, one AMD quirk and a full set of i915 fixes.

The i915 fixes are mostly for things caught by their CI system, main
ones being DSI panel fixes and GEM fixes.

Pretty quiet overall.

Dave.

The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:

  Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)

are available in the git repository at:

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

for you to fetch changes up to bfad2d08e540b18cfd92694fbb388e7d202df31f:

  Merge branch 'linux-4.16' of git://github.com/skeggsb/linux into
drm-fixes (2018-02-16 14:26:01 +1000)


i915 fixes, and single amd and nouveau fix


Chris Wilson (7):
  drm/i915/perf: Fix compiler warning for string truncation
  drm/i915/perf: Fix compiler warning for string truncation
  drm/i915: Avoid truncation before clamping userspace's priority value
  drm/i915: Don't wake the device up to check if the engine is asleep
  drm/i915/breadcrumbs: Ignore unsubmitted signalers
  drm/i915: Lock out execlist tasklet while peeking inside for busy-stats
  drm/i915/pmu: Fix building without CONFIG_PM

Dave Airlie (3):
  Merge branch 'drm-next-4.16' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2018-02-14-1' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'linux-4.16' of git://github.com/skeggsb/linux into drm-fixes

Hans de Goede (4):
  drm/i915/vlv: Add cdclk workaround for DSI
  drm/i915: Add intel_bios_cleanup() function
  drm/i915: Free memdup-ed DSI VBT data structures on driver_unload
  drm/i915: Fix DSI panels with v1 MIPI sequences without a
DEASSERT sequence v3

Kai-Heng Feng (1):
  drm/amdgpu: add new device to use atpx quirk

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2018-02-14' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Thierry Reding (1):
  drm/nouveau: Make clock gate support conditional

Tina Zhang (1):
  drm/i915/gvt: Support BAR0 8-byte reads/writes

Tvrtko Ursulin (2):
  drm/i915/pmu: Fix PMU enable vs execlists tasklet race
  drm/i915/pmu: Fix sleep under atomic in RC6 readout

Weinan Li (2):
  drm/i915/gvt: add 0xe4f0 into gen9 render list
  drm/i915/gvt: fix one typo of render_mmio trace

 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c |   1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c |  51 -
 drivers/gpu/drm/i915/gvt/mmio_context.c  |   1 +
 drivers/gpu/drm/i915/gvt/trace.h |   2 +-
 drivers/gpu/drm/i915/i915_drv.c  |  14 +-
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_gem_context.c  |   2 +-
 drivers/gpu/drm/i915/i915_oa_cflgt3.c|   4 +-
 drivers/gpu/drm/i915/i915_oa_cnl.c   |   4 +-
 drivers/gpu/drm/i915/i915_pmu.c  | 231 ++-
 drivers/gpu/drm/i915/i915_pmu.h  |   6 +
 drivers/gpu/drm/i915/intel_bios.c| 105 +++
 drivers/gpu/drm/i915/intel_breadcrumbs.c |  29 +--
 drivers/gpu/drm/i915/intel_cdclk.c   |   8 +
 drivers/gpu/drm/i915/intel_engine_cs.c   |  24 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  14 --
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c |   6 +-
 17 files changed, 350 insertions(+), 154 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

[Archit Taneja]

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote:

dw_hdmi shouldn't set drvdata since some drivers might need to store
it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
instead to store it in drvdata. This way drivers are responsible to
store and pass structure when needed.

Idea was taken from the following commit:
8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata")


Reviewed-by: Archit Taneja 



Cc: p.za...@pengutronix.de
Cc: narmstr...@baylibre.com
Cc: laurent.pinch...@ideasonboard.com
Cc: h...@rock-chips.com
Cc: he...@sntech.de
Acked-by: Neil Armstrong 
Signed-off-by: Jernej Skrabec 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 31 -
  drivers/gpu/drm/imx/dw_hdmi-imx.c   | 13 +---
  drivers/gpu/drm/meson/meson_dw_hdmi.c   | 14 +
  drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c  | 12 +--
  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +---
  include/drm/bridge/dw_hdmi.h| 13 ++--
  6 files changed, 60 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7d80f4b56683..f9802399cc0d 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2543,8 +2543,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
  
-	platform_set_drvdata(pdev, hdmi);

-
return hdmi;
  
  err_iahb:

@@ -2594,25 +2592,23 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
  /* 
-
   * Probe/remove API, used from platforms based on the DRM bridge API.
   */
-int dw_hdmi_probe(struct platform_device *pdev,
- const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
  {
struct dw_hdmi *hdmi;
  
  	hdmi = __dw_hdmi_probe(pdev, plat_data);

if (IS_ERR(hdmi))
-   return PTR_ERR(hdmi);
+   return hdmi;
  
  	drm_bridge_add(>bridge);
  
-	return 0;

+   return hdmi;
  }
  EXPORT_SYMBOL_GPL(dw_hdmi_probe);
  
-void dw_hdmi_remove(struct platform_device *pdev)

+void dw_hdmi_remove(struct dw_hdmi *hdmi)
  {
-   struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
-
drm_bridge_remove(>bridge);
  
  	__dw_hdmi_remove(hdmi);

@@ -2622,31 +2618,30 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
  /* 
-
   * Bind/unbind API, used from platforms based on the component framework.
   */
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
+struct drm_encoder *encoder,
+const struct dw_hdmi_plat_data *plat_data)
  {
struct dw_hdmi *hdmi;
int ret;
  
  	hdmi = __dw_hdmi_probe(pdev, plat_data);

if (IS_ERR(hdmi))
-   return PTR_ERR(hdmi);
+   return hdmi;
  
  	ret = drm_bridge_attach(encoder, >bridge, NULL);

if (ret) {
-   dw_hdmi_remove(pdev);
+   dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
-   return ret;
+   return ERR_PTR(ret);
}
  
-	return 0;

+   return hdmi;
  }
  EXPORT_SYMBOL_GPL(dw_hdmi_bind);
  
-void dw_hdmi_unbind(struct device *dev)

+void dw_hdmi_unbind(struct dw_hdmi *hdmi)
  {
-   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
__dw_hdmi_remove(hdmi);
  }
  EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index b62763aa8706..fe6becdcc29e 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -25,6 +25,7 @@
  struct imx_hdmi {
struct device *dev;
struct drm_encoder encoder;
+   struct dw_hdmi *hdmi;
struct regmap *regmap;
  };
  
@@ -239,14 +240,18 @@ static int dw_hdmi_imx_bind(struct device *dev, struct device *master,

drm_encoder_init(drm, encoder, _hdmi_imx_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
  
-	ret = dw_hdmi_bind(pdev, encoder, plat_data);

+   platform_set_drvdata(pdev, hdmi);
+
+   hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
  
  	/*

 * If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
 * which would have called the encoder cleanup.  Do it manually.
 */
-   if (ret)
+   if (IS_ERR(hdmi->hdmi)) {
+   ret = PTR_ERR(hdmi->hdmi);

Re: [PATCH v5 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

[Archit Taneja]

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote:

Parts of PHY code could be useful also for custom PHYs. For example,
Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
with few additional memory mapped registers, so most of the Synopsys PHY
related code could be reused.

Functions exported here are actually not specific to Synopsys PHYs but
to DWC HDMI controller PHY interface. This means that even if the PHY is
completely custom, i.e. not designed by Synopsys, exported functions can
be useful.


Reviewed-by: Archit Taneja 



Reviewed-by: Neil Armstrong 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Jernej Skrabec 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 +--
  drivers/gpu/drm/meson/meson_dw_hdmi.c |  8 +++---
  include/drm/bridge/dw_hdmi.h  | 11 
  3 files changed, 45 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7ca14d7325b5..7d80f4b56683 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi 
*hdmi, u8 enable)
 HDMI_PHY_CONF0_SVSRET_MASK);
  }
  
-static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)

+void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
  {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
 HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
 HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
  
-static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)

+void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
  {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
 HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
 HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
  
  static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)

  {
@@ -1065,6 +1067,22 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
  }
  
+void dw_hdmi_phy_reset(struct dw_hdmi *hdmi)

+{
+   /* PHY reset. The reset signal is active high on Gen2 PHYs. */
+   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
+   hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_reset);
+
+void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address)
+{
+   hdmi_phy_test_clear(hdmi, 1);
+   hdmi_writeb(hdmi, address, HDMI_PHY_I2CM_SLAVE_ADDR);
+   hdmi_phy_test_clear(hdmi, 0);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_set_addr);
+
  static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
  {
const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
@@ -1203,16 +1221,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
if (phy->has_svsret)
dw_hdmi_phy_enable_svsret(hdmi, 1);
  
-	/* PHY reset. The reset signal is active high on Gen2 PHYs. */

-   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
-   hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+   dw_hdmi_phy_reset(hdmi);
  
  	hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
  
-	hdmi_phy_test_clear(hdmi, 1);

-   hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
-   HDMI_PHY_I2CM_SLAVE_ADDR);
-   hdmi_phy_test_clear(hdmi, 0);
+   dw_hdmi_phy_i2c_set_addr(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2);
  
  	/* Write to the PHY as configured by the platform */

if (pdata->configure_phy)
@@ -1251,15 +1264,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, 
void *data)
dw_hdmi_phy_power_off(hdmi);
  }
  
-static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,

- void *data)
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+  void *data)
  {
return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
connector_status_connected : connector_status_disconnected;
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
  
-static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,

-  bool force, bool disabled, bool rxsense)
+void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+   bool force, bool disabled, bool rxsense)
  {
u8 old_mask = hdmi->phy_mask;
  
@@ -1271,8 +1285,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,

if (old_mask != hdmi->phy_mask)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
  }

Re: [PATCH v5 03/12] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a

[Archit Taneja]

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote:

Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.

Tests show that one iteration is enough.

Acked-by: Laurent Pinchart 


Reviewed-by: Archit Taneja 


Signed-off-by: Jernej Skrabec 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..7ca14d7325b5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1634,9 +1634,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
 * then write one of the FC registers several times.
 *
 * The number of iterations matters and depends on the HDMI TX revision
-* (and possibly on the platform). So far only i.MX6Q (v1.30a) and
-* i.MX6DL (v1.31a) have been identified as needing the workaround, with
-* 4 and 1 iterations respectively.
+* (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
+* (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
+* as needing the workaround, with 4 iterations for v1.30a and 1
+* iteration for others.
 */
  
  	switch (hdmi->version) {

@@ -1644,6 +1645,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
count = 4;
break;
case 0x131a:
+   case 0x132a:
count = 1;
break;
default:


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

[radeon-alex:amd-staging-dkms-4.13 3366/3830] include/drm/ttm/ttm_page_alloc.h:125:1: error: expected identifier or '(' before '{' token

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   7bde112fab15c0a28c1d056959167cd4393bf538
commit: ec96f6ceed1d387de0b264c59d31120c15888546 [3366/3830] drm/ttm: use an 
operation ctx for ttm_tt_populate in ttm_bo_driver
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ec96f6ceed1d387de0b264c59d31120c15888546
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

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

   In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:36:0:
>> include/drm/ttm/ttm_page_alloc.h:125:1: error: expected identifier or '(' 
>> before '{' token
{
^
>> include/drm/ttm/ttm_page_alloc.h:123:19: warning: 
>> 'ttm_populate_and_map_pages' used but never defined
static inline int ttm_populate_and_map_pages(struct device *dev, struct 
ttm_dma_tt *tt,
  ^~
--
   In file included from drivers/gpu/drm/ast/ast_ttm.c:29:0:
>> include/drm/ttm/ttm_page_alloc.h:125:1: error: expected identifier or '(' 
>> before '{' token
{
^
   include/drm/ttm/ttm_page_alloc.h:123:19: warning: 
'ttm_populate_and_map_pages' declared 'static' but never defined 
[-Wunused-function]
static inline int ttm_populate_and_map_pages(struct device *dev, struct 
ttm_dma_tt *tt,
  ^~

vim +125 include/drm/ttm/ttm_page_alloc.h

3588b82c Tom St Denis 2017-08-18  122  
ec96f6ce Roger He 2017-12-21 @123  static inline int 
ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt,
ec96f6ce Roger He 2017-12-21  124   struct 
ttm_operation_ctx *ctx);
3588b82c Tom St Denis 2017-08-18 @125  {
3588b82c Tom St Denis 2017-08-18  126   return -ENOMEM;
3588b82c Tom St Denis 2017-08-18  127  }
3588b82c Tom St Denis 2017-08-18  128  

:: The code at line 125 was first introduced by commit
:: 3588b82c043dd83f8c5885cd60bd6529635720d6 drm/ttm: Add helper functions 
to populate/map in one call (v2)

:: TO: Tom St Denis 
:: CC: Alex Deucher 

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


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

Re: [RFC PULL] Add Display Support for Qualcomm SDM845

[Rob Herring]

On Tue, Feb 13, 2018 at 1:18 PM, Sean Paul  wrote:
> Hi dri-devel,
> Qualcomm has been working for the past few weeks on forward porting their
> downstream drm driver from 4.14 to mainline. Please consider this PR as a
> request for review, rather than an attempt at mainlining the code as it
> currently stands. The goal is get this driver in shape over the next coming
> months.
>
> In the meantime, I'll be hosting a tree here [1] to stage the fixes. Patches
> will be posted and reviewed on linux-arm-...@vger.kernel.org. Once things look
> good, I'll send another pull 4realz.
>
> To get the ball rolling, I've done some review on the new connector code, my
> comments are below.
>
> Thanks in advance for your constructive feedback :)


>  .../devicetree/bindings/display/msm/dpu-rsc.txt|   96 +
>  .../devicetree/bindings/display/msm/dpu.txt|  736 +++
>  .../devicetree/bindings/display/msm/dsi.txt|   16 +

>  .../devicetree/bindings/drm/msm/dpu-dp.txt |  217 +
>  .../devicetree/bindings/drm/msm/dpu-dsi.txt|  102 +
>  .../devicetree/bindings/drm/msm/dpu-wb.txt |   23 +
>  .../devicetree/bindings/drm/msm/mdss-dsi-panel.txt |  772 +++

Not a correct path with /drm/.

772 lines for a panel or DSI!? I look at it when it is shorter...

>  .../devicetree/bindings/fb/mdss-dsi-panel.txt  |  742 +++

Hopefully just duplicated?

>  Documentation/devicetree/bindings/fb/mdss-pll.txt  |  103 +

Not a correct path either.

>  .../devicetree/bindings/msm_hdcp/msm_hdcp.txt  |   14 +

ditto.

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

[PATCH 2/2] selftests: ion: Add simple test with the vgem driver

[Laura Abbott]

Ion is designed to be a framework used by other clients who perform
operations on the buffer. Use the DRM vgem client as a simple consumer.
In conjunction with the dma-buf sync ioctls, this tests the full attach/map
path for the system heap.

Signed-off-by: Laura Abbott 
---
 tools/testing/selftests/android/ion/Makefile  |   3 +-
 tools/testing/selftests/android/ion/config|   1 +
 tools/testing/selftests/android/ion/ionmap_test.c | 136 ++
 3 files changed, 139 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/android/ion/ionmap_test.c

diff --git a/tools/testing/selftests/android/ion/Makefile 
b/tools/testing/selftests/android/ion/Makefile
index 96e0c448b39d..d23b6d537d8b 100644
--- a/tools/testing/selftests/android/ion/Makefile
+++ b/tools/testing/selftests/android/ion/Makefile
@@ -2,7 +2,7 @@
 INCLUDEDIR := -I. -I../../../../../drivers/staging/android/uapi/
 CFLAGS := $(CFLAGS) $(INCLUDEDIR) -Wall -O2 -g
 
-TEST_GEN_FILES := ionapp_export ionapp_import
+TEST_GEN_FILES := ionapp_export ionapp_import ionmap_test
 
 all: $(TEST_GEN_FILES)
 
@@ -14,3 +14,4 @@ include ../../lib.mk
 
 $(OUTPUT)/ionapp_export: ionapp_export.c ipcsocket.c ionutils.c
 $(OUTPUT)/ionapp_import: ionapp_import.c ipcsocket.c ionutils.c
+$(OUTPUT)/ionmap_test: ionmap_test.c ionutils.c
diff --git a/tools/testing/selftests/android/ion/config 
b/tools/testing/selftests/android/ion/config
index 19db6ca9aa2b..b4ad748a9dd9 100644
--- a/tools/testing/selftests/android/ion/config
+++ b/tools/testing/selftests/android/ion/config
@@ -2,3 +2,4 @@ CONFIG_ANDROID=y
 CONFIG_STAGING=y
 CONFIG_ION=y
 CONFIG_ION_SYSTEM_HEAP=y
+CONFIG_DRM_VGEM=y
diff --git a/tools/testing/selftests/android/ion/ionmap_test.c 
b/tools/testing/selftests/android/ion/ionmap_test.c
new file mode 100644
index ..dab36b06b37d
--- /dev/null
+++ b/tools/testing/selftests/android/ion/ionmap_test.c
@@ -0,0 +1,136 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include "ion.h"
+#include "ionutils.h"
+
+int check_vgem(int fd)
+{
+   drm_version_t version = { 0 };
+   char name[5];
+   int ret;
+
+   version.name_len = 4;
+   version.name = name;
+
+   ret = ioctl(fd, DRM_IOCTL_VERSION, );
+   if (ret)
+   return 1;
+
+   return strcmp(name, "vgem");
+}
+
+int open_vgem(void)
+{
+   int i, fd;
+   const char *drmstr = "/dev/dri/card";
+
+   fd = -1;
+   for (i = 0; i < 16; i++) {
+   char name[80];
+
+   sprintf(name, "%s%u", drmstr, i);
+
+   fd = open(name, O_RDWR);
+   if (fd < 0)
+   continue;
+
+   if (check_vgem(fd)) {
+   close(fd);
+   continue;
+   } else {
+   break;
+   }
+
+   }
+   return fd;
+}
+
+int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
+{
+   struct drm_prime_handle import_handle = { 0 };
+   int ret;
+
+   import_handle.fd = dma_buf_fd;
+   import_handle.flags = 0;
+   import_handle.handle = 0;
+
+   ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, _handle);
+   if (ret == 0)
+   *handle = import_handle.handle;
+   return ret;
+}
+
+void close_handle(int vgem_fd, uint32_t handle)
+{
+   struct drm_gem_close close = { 0 };
+
+   close.handle = handle;
+   ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, );
+}
+
+int main()
+{
+   int ret, vgem_fd;
+   struct ion_buffer_info info;
+   uint32_t handle = 0;
+   struct dma_buf_sync sync = { 0 };
+
+   info.heap_type = ION_HEAP_TYPE_SYSTEM;
+   info.heap_size = 4096;
+   info.flag_type = ION_FLAG_CACHED;
+
+   ret = ion_export_buffer_fd();
+   if (ret < 0) {
+   printf("ion buffer alloc failed\n");
+   return -1;
+   }
+
+   vgem_fd = open_vgem();
+   if (vgem_fd < 0) {
+   ret = vgem_fd;
+   printf("Failed to open vgem\n");
+   goto out_ion;
+   }
+
+   ret = import_vgem_fd(vgem_fd, info.buffd, );
+
+   if (ret < 0) {
+   printf("Failed to import buffer\n");
+   goto out_vgem;
+   }
+
+   sync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_RW;
+   ret = ioctl(info.buffd, DMA_BUF_IOCTL_SYNC, );
+   if (ret)
+   printf("sync start failed %d\n", errno);
+
+   memset(info.buffer, 0xff, 4096);
+
+   sync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_RW;
+   ret = ioctl(info.buffd, DMA_BUF_IOCTL_SYNC, );
+   if (ret)
+   printf("sync end failed %d\n", errno);
+
+   close_handle(vgem_fd, handle);
+   ret = 0;
+
+out_vgem:
+   close(vgem_fd);
+out_ion:
+   ion_close_buffer_fd();
+   printf("done.\n");
+   return ret;
+}
-- 
2.14.3

[RFC PATCH 0/2] Ion unit test with VGEM

[Laura Abbott]

Hi,

Ion hasn't had much in the way of unit tests and fixing that is
something that needs to happen before it can move out of staging. The
difficult part of testing parts of Ion is that it relies on having a
kernel driver to actually make some of the dma_buf calls. The vgem
DRM driver exists mostly for testing and works great for this case. I
went back and forth about trying to put this in the existing graphics
test suite but I think having something in the self-tests directory is
easier.

I'm mostly interested in feedback about the use of the DRM APIs but I
appreciate any and all comments.

Thanks,
Laura

Laura Abbott (2):
  selftests: ion: Remove some prints
  selftests: ion: Add simple test with the vgem driver

 tools/testing/selftests/android/ion/Makefile  |   3 +-
 tools/testing/selftests/android/ion/config|   1 +
 tools/testing/selftests/android/ion/ionmap_test.c | 136 ++
 tools/testing/selftests/android/ion/ionutils.c|   6 -
 4 files changed, 139 insertions(+), 7 deletions(-)
 create mode 100644 tools/testing/selftests/android/ion/ionmap_test.c

-- 
2.14.3

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

[PATCH 1/2] selftests: ion: Remove some prints

[Laura Abbott]

There's no need to print messages each time we alloc and free. Remove them.

Signed-off-by: Laura Abbott 
---
 tools/testing/selftests/android/ion/ionutils.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/tools/testing/selftests/android/ion/ionutils.c 
b/tools/testing/selftests/android/ion/ionutils.c
index ce69c14f51fa..7d1d37c4ef6a 100644
--- a/tools/testing/selftests/android/ion/ionutils.c
+++ b/tools/testing/selftests/android/ion/ionutils.c
@@ -80,11 +80,6 @@ int ion_export_buffer_fd(struct ion_buffer_info *ion_info)
heap_id = MAX_HEAP_COUNT + 1;
for (i = 0; i < query.cnt; i++) {
if (heap_data[i].type == ion_info->heap_type) {
-   printf("--\n");
-   printf("heap type: %d\n", heap_data[i].type);
-   printf("  heap id: %d\n", heap_data[i].heap_id);
-   printf("heap name: %s\n", heap_data[i].name);
-   printf("--\n");
heap_id = heap_data[i].heap_id;
break;
}
@@ -204,7 +199,6 @@ void ion_close_buffer_fd(struct ion_buffer_info *ion_info)
/* Finally, close the client fd */
if (ion_info->ionfd > 0)
close(ion_info->ionfd);
-   printf("<%s>: buffer release successfully\n", __func__);
}
 }
 
-- 
2.14.3

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

[radeon-alex:amd-staging-dkms-4.13 2525/3830] drivers/staging/vboxvideo/vbox_ttm.c:392:56: sparse: Using plain integer as NULL pointer

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   7bde112fab15c0a28c1d056959167cd4393bf538
commit: 7f7a03f8049d505d450f27973d5c96af13bc8fe6 [2525/3830] drm/ttm: add 
operation ctx to ttm_bo_validate v2
reproduce:
# apt-get install sparse
git checkout 7f7a03f8049d505d450f27973d5c96af13bc8fe6
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   drivers/staging/vboxvideo/vbox_ttm.c:233:22: sparse: symbol 'vbox_bo_driver' 
was not declared. Should it be
>> drivers/staging/vboxvideo/vbox_ttm.c:392:56: sparse: Using plain integer as 
>> NULL pointer
>> drivers/staging/vboxvideo/vbox_ttm.c:392:30: sparse: too many arguments for 
>> function ttm_bo_validate
   drivers/staging/vboxvideo/vbox_ttm.c:419:56: sparse: Using plain integer as 
NULL pointer
   drivers/staging/vboxvideo/vbox_ttm.c:419:30: sparse: too many arguments for 
function ttm_bo_validate
   drivers/staging/vboxvideo/vbox_ttm.c:451:56: sparse: Using plain integer as 
NULL pointer
   drivers/staging/vboxvideo/vbox_ttm.c:451:30: sparse: too many arguments for 
function ttm_bo_validate
   drivers/staging/vboxvideo/vbox_ttm.c: In function 'vbox_bo_pin':
   drivers/staging/vboxvideo/vbox_ttm.c:392:8: error: too many arguments to 
function 'ttm_bo_validate'
ret = ttm_bo_validate(>bo, >placement, false, false);
^~~
   In file included from drivers/staging/vboxvideo/vbox_drv.h:43:0,
from drivers/staging/vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:334:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object
^~~
   drivers/staging/vboxvideo/vbox_ttm.c: In function 'vbox_bo_unpin':
   drivers/staging/vboxvideo/vbox_ttm.c:419:8: error: too many arguments to 
function 'ttm_bo_validate'
ret = ttm_bo_validate(>bo, >placement, false, false);
^~~
   In file included from drivers/staging/vboxvideo/vbox_drv.h:43:0,
from drivers/staging/vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:334:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object
^~~
   drivers/staging/vboxvideo/vbox_ttm.c: In function 'vbox_bo_push_sysram':
   drivers/staging/vboxvideo/vbox_ttm.c:451:8: error: too many arguments to 
function 'ttm_bo_validate'
ret = ttm_bo_validate(>bo, >placement, false, false);
^~~
   In file included from drivers/staging/vboxvideo/vbox_drv.h:43:0,
from drivers/staging/vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:334:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object
^~~

vim +392 drivers/staging/vboxvideo/vbox_ttm.c

dd55d44f4 Hans de Goede 2017-07-06  232  
dd55d44f4 Hans de Goede 2017-07-06 @233  struct ttm_bo_driver vbox_bo_driver = {
dd55d44f4 Hans de Goede 2017-07-06  234 .ttm_tt_create = 
vbox_ttm_tt_create,
dd55d44f4 Hans de Goede 2017-07-06  235 .ttm_tt_populate = 
vbox_ttm_tt_populate,
dd55d44f4 Hans de Goede 2017-07-06  236 .ttm_tt_unpopulate = 
vbox_ttm_tt_unpopulate,
dd55d44f4 Hans de Goede 2017-07-06  237 .init_mem_type = 
vbox_bo_init_mem_type,
dd55d44f4 Hans de Goede 2017-07-06  238 .eviction_valuable = 
ttm_bo_eviction_valuable,
dd55d44f4 Hans de Goede 2017-07-06  239 .evict_flags = 
vbox_bo_evict_flags,
dd55d44f4 Hans de Goede 2017-07-06  240 .move = vbox_bo_move,
dd55d44f4 Hans de Goede 2017-07-06  241 .verify_access = 
vbox_bo_verify_access,
dd55d44f4 Hans de Goede 2017-07-06  242 .io_mem_reserve = 
_ttm_io_mem_reserve,
dd55d44f4 Hans de Goede 2017-07-06  243 .io_mem_free = 
_ttm_io_mem_free,
dd55d44f4 Hans de Goede 2017-07-06  244 .io_mem_pfn = 
ttm_bo_default_io_mem_pfn,
dd55d44f4 Hans de Goede 2017-07-06  245  };
dd55d44f4 Hans de Goede 2017-07-06  246  
dd55d44f4 Hans de Goede 2017-07-06  247  int vbox_mm_init(struct vbox_private 
*vbox)
dd55d44f4 Hans de Goede 2017-07-06  248  {
dd55d44f4 Hans de Goede 2017-07-06  249 int ret;
dd55d44f4 Hans de Goede 2017-07-06  250 struct drm_device *dev = 
vbox->dev;
dd55d44f4 Hans de Goede 2017-07-06  251 struct ttm_bo_device *bdev = 
>ttm.bdev;
dd55d44f4 Hans de Goede 2017-07-06  252  
dd55d44f4 Hans de Goede 2017-07-06  253 ret = 
vbox_ttm_global_init(vbox);
dd55d44f4 Hans de Goede 2017-07-06  254 if (ret)
dd55d44f4 Hans de Goede 2017-07-06  255 return ret;
dd55d44f4 Hans de Goede 2017-07-06  256  
dd55d44f4 Hans de Goede 2017-07-06  257 ret = 
ttm_bo_device_init(>ttm.bdev,
dd55d44f4 Hans de Goede 2017-07-06  258  
vbox->ttm.bo_global_ref.ref.object,
dd55d44f4 Hans de Goede 2017-07-06  259  
_bo_driver,
dd55d44f4 Hans de Goede 2017-07-06  260  
dev->anon_inode->i_mapping,
dd55d44f4 Hans de Goede 2017-07-06  261  

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Tomasz Figa]

On Fri, Feb 16, 2018 at 2:14 AM, Robin Murphy  wrote:
> On 15/02/18 04:17, Tomasz Figa wrote:
> [...]
>>>
>>> Could you elaborate on what kind of locking you are concerned about?
>>> As I explained before, the normally happening fast path would lock
>>> dev->power_lock only for the brief moment of incrementing the runtime
>>> PM usage counter.
>>
>>
>> My bad, that's not even it.
>>
>> The atomic usage counter is incremented beforehands, without any
>> locking [1] and the spinlock is acquired only for the sake of
>> validating that device's runtime PM state remained valid indeed [2],
>> which would be the case in the fast path of the same driver doing two
>> mappings in parallel, with the master powered on (and so the SMMU,
>> through device links; if master was not powered on already, powering
>> on the SMMU is unavoidable anyway and it would add much more latency
>> than the spinlock itself).
>
>
> We now have no locking at all in the map path, and only a per-domain lock
> around TLB sync in unmap which is unfortunately necessary for correctness;
> the latter isn't too terrible, since in "serious" hardware it should only be
> serialising a few cpus serving the same device against each other (e.g. for
> multiple queues on a single NIC).
>
> Putting in a global lock which serialises *all* concurrent map and unmap
> calls for *all* unrelated devices makes things worse. Period. Even if the
> lock itself were held for the minimum possible time, i.e. trivially
> "spin_lock(); spin_unlock()", the cost of repeatedly bouncing that
> one cache line around between 96 CPUs across two sockets is not negligible.

Fair enough. Note that we're in a quite interesting situation now:
 a) We need to have runtime PM enabled on Qualcomm SoC to have power
properly managed,
 b) We need to have lock-free map/unmap on such distributed systems,
 c) If runtime PM is enabled, we need to call into runtime PM from any
code that does hardware accesses, otherwise the IOMMU API (and so DMA
API and then any V4L2 driver) becomes unusable.

I can see one more way that could potentially let us have all the
three. How about enabling runtime PM only on selected implementations
(e.g. qcom,smmu) and then having all the runtime PM calls surrounded
with if (pm_runtime_enabled()), which is lockless?

>
>> [1]
>> http://elixir.free-electrons.com/linux/v4.16-rc1/source/drivers/base/power/runtime.c#L1028
>> [2]
>> http://elixir.free-electrons.com/linux/v4.16-rc1/source/drivers/base/power/runtime.c#L613
>>
>> In any case, I can't imagine this working with V4L2 or anything else
>> relying on any memory management more generic than calling IOMMU API
>> directly from the driver, with the IOMMU device having runtime PM
>> enabled, but without managing the runtime PM from the IOMMU driver's
>> callbacks that need access to the hardware. As I mentioned before,
>> only the IOMMU driver knows when exactly the real hardware access
>> needs to be done (e.g. Rockchip/Exynos don't need to do that for
>> map/unmap if the power is down, but some implementations of SMMU with
>> TLB powered separately might need to do so).
>
>
> It's worth noting that Exynos and Rockchip are relatively small
> self-contained IP blocks integrated closely with the interfaces of their
> relevant master devices; SMMU is an architecture, implementations of which
> may be large, distributed, and have complex and wildly differing internal
> topologies. As such, it's a lot harder to make hardware-specific assumptions
> and/or be correct for all possible cases.
>
> Don't get me wrong, I do ultimately agree that the IOMMU driver is the only
> agent who ultimately knows what calls are going to be necessary for whatever
> operation it's performing on its own hardware*; it's just that for SMMU it
> needs to be implemented in a way that has zero impact on the cases where it
> doesn't matter, because it's not viable to specialise that driver for any
> particular IP implementation/use-case.

Still, exactly the same holds for the low power embedded use cases,
where we strive for the lowest possible power consumption, while
maintaining performance levels high as well. And so the SMMU code is
expected to also work with our use cases, such as V4L2 or DRM drivers.
Since these points don't hold for current SMMU code, I could say that
the it has been already specialized for large, distributed
implementations.

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

[radeon-alex:amd-staging-dkms-4.13 2529/3830] drivers/staging/vboxvideo/vbox_ttm.c:240:10: error: initialization from incompatible pointer type

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   7bde112fab15c0a28c1d056959167cd4393bf538
commit: 3f74ea1e32064cd589f8dd71cbb8fa4282c2 [2529/3830] drm/ttm: add 
context to driver move callback as well
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 3f74ea1e32064cd589f8dd71cbb8fa4282c2
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/staging/vboxvideo/vbox_ttm.c:240:10: error: initialization from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
 .move = vbox_bo_move,
 ^~~~
   drivers/staging/vboxvideo/vbox_ttm.c:240:10: note: (near initialization for 
'vbox_bo_driver.move')
   drivers/staging/vboxvideo/vbox_ttm.c: In function 'vbox_bo_pin':
   drivers/staging/vboxvideo/vbox_ttm.c:392:8: error: too many arguments to 
function 'ttm_bo_validate'
 ret = ttm_bo_validate(>bo, >placement, false, false);
   ^~~
   In file included from drivers/staging/vboxvideo/vbox_drv.h:43:0,
from drivers/staging/vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:334:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object *bo,
^~~
   drivers/staging/vboxvideo/vbox_ttm.c: In function 'vbox_bo_unpin':
   drivers/staging/vboxvideo/vbox_ttm.c:419:8: error: too many arguments to 
function 'ttm_bo_validate'
 ret = ttm_bo_validate(>bo, >placement, false, false);
   ^~~
   In file included from drivers/staging/vboxvideo/vbox_drv.h:43:0,
from drivers/staging/vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:334:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object *bo,
^~~
   drivers/staging/vboxvideo/vbox_ttm.c: In function 'vbox_bo_push_sysram':
   drivers/staging/vboxvideo/vbox_ttm.c:451:8: error: too many arguments to 
function 'ttm_bo_validate'
 ret = ttm_bo_validate(>bo, >placement, false, false);
   ^~~
   In file included from drivers/staging/vboxvideo/vbox_drv.h:43:0,
from drivers/staging/vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:334:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object *bo,
^~~
   cc1: some warnings being treated as errors

vim +240 drivers/staging/vboxvideo/vbox_ttm.c

dd55d44f4 Hans de Goede 2017-07-06  232  
dd55d44f4 Hans de Goede 2017-07-06  233  struct ttm_bo_driver vbox_bo_driver = {
dd55d44f4 Hans de Goede 2017-07-06  234 .ttm_tt_create = 
vbox_ttm_tt_create,
dd55d44f4 Hans de Goede 2017-07-06  235 .ttm_tt_populate = 
vbox_ttm_tt_populate,
dd55d44f4 Hans de Goede 2017-07-06  236 .ttm_tt_unpopulate = 
vbox_ttm_tt_unpopulate,
dd55d44f4 Hans de Goede 2017-07-06  237 .init_mem_type = 
vbox_bo_init_mem_type,
dd55d44f4 Hans de Goede 2017-07-06  238 .eviction_valuable = 
ttm_bo_eviction_valuable,
dd55d44f4 Hans de Goede 2017-07-06  239 .evict_flags = 
vbox_bo_evict_flags,
dd55d44f4 Hans de Goede 2017-07-06 @240 .move = vbox_bo_move,
dd55d44f4 Hans de Goede 2017-07-06  241 .verify_access = 
vbox_bo_verify_access,
dd55d44f4 Hans de Goede 2017-07-06  242 .io_mem_reserve = 
_ttm_io_mem_reserve,
dd55d44f4 Hans de Goede 2017-07-06  243 .io_mem_free = 
_ttm_io_mem_free,
dd55d44f4 Hans de Goede 2017-07-06  244 .io_mem_pfn = 
ttm_bo_default_io_mem_pfn,
dd55d44f4 Hans de Goede 2017-07-06  245  };
dd55d44f4 Hans de Goede 2017-07-06  246  

:: The code at line 240 was first introduced by commit
:: dd55d44f408419278c00887bfcb2261d0caae350 staging: vboxvideo: Add 
vboxvideo to drivers/staging

:: TO: Hans de Goede 
:: CC: Greg Kroah-Hartman 

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


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

[radeon-alex:amd-staging-dkms-4.13 3809/3830] drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:660:3: error: implicit declaration of function 'release_pages'; did you mean 'release_task'?

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   7bde112fab15c0a28c1d056959167cd4393bf538
commit: d3d63af4863b870bb0153c8fe24b41218d232b10 [3809/3830] drm/amdgpu: Remove 
unnecessary includes
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d3d63af4863b870bb0153c8fe24b41218d232b10
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function 
'init_user_pages':
>> drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:660:3: error: implicit 
>> declaration of function 'release_pages'; did you mean 'release_task'? 
>> [-Werror=implicit-function-declaration]
  release_pages(mem->user_pages, bo->tbo.ttm->num_pages, 0);
  ^
  release_task
   cc1: some warnings being treated as errors

vim +660 drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c

40731cf1 Harish Kasiviswanathan 2016-06-27  584  
24d10b3d Felix Kuehling 2017-03-21  585  /* Initializes user pages. It 
registers the MMU notifier and validates
24d10b3d Felix Kuehling 2017-03-21  586   * the userptr BO in the GTT 
domain.
24d10b3d Felix Kuehling 2017-03-21  587   *
24d10b3d Felix Kuehling 2017-03-21  588   * The BO must already be on 
the userptr_valid_list. Otherwise an
24d10b3d Felix Kuehling 2017-03-21  589   * eviction and restore may 
happen that leaves the new BO unmapped
24d10b3d Felix Kuehling 2017-03-21  590   * with the user mode queues 
running.
24d10b3d Felix Kuehling 2017-03-21  591   *
24d10b3d Felix Kuehling 2017-03-21  592   * Takes the 
process_info->lock to protect against concurrent restore
24d10b3d Felix Kuehling 2017-03-21  593   * workers.
24d10b3d Felix Kuehling 2017-03-21  594   *
24d10b3d Felix Kuehling 2017-03-21  595   * Returns 0 for success, 
negative errno for errors.
24d10b3d Felix Kuehling 2017-03-21  596   */
24d10b3d Felix Kuehling 2017-03-21  597  static int 
init_user_pages(struct kgd_mem *mem, struct mm_struct *mm,
24d10b3d Felix Kuehling 2017-03-21  598
uint64_t user_addr)
24d10b3d Felix Kuehling 2017-03-21  599  {
24d10b3d Felix Kuehling 2017-03-21  600 struct 
amdkfd_process_info *process_info = mem->process_info;
24d10b3d Felix Kuehling 2017-03-21  601 struct amdgpu_bo *bo = 
mem->bo;
ba839029 Le.Ma  2017-11-24  602 struct 
ttm_operation_ctx ctx = { true, false };
24d10b3d Felix Kuehling 2017-03-21  603 int ret = 0;
24d10b3d Felix Kuehling 2017-03-21  604  
24d10b3d Felix Kuehling 2017-03-21  605 
mutex_lock(_info->lock);
24d10b3d Felix Kuehling 2017-03-21  606  
24d10b3d Felix Kuehling 2017-03-21  607 ret = 
amdgpu_ttm_tt_set_userptr(bo->tbo.ttm, user_addr, 0);
24d10b3d Felix Kuehling 2017-03-21  608 if (ret) {
24d10b3d Felix Kuehling 2017-03-21  609 pr_err("%s: 
Failed to set userptr: %d\n", __func__, ret);
24d10b3d Felix Kuehling 2017-03-21  610 goto out;
24d10b3d Felix Kuehling 2017-03-21  611 }
24d10b3d Felix Kuehling 2017-03-21  612  
24d10b3d Felix Kuehling 2017-03-21  613 ret = 
amdgpu_mn_register(bo, user_addr);
24d10b3d Felix Kuehling 2017-03-21  614 if (ret) {
24d10b3d Felix Kuehling 2017-03-21  615 pr_err("%s: 
Failed to register MMU notifier: %d\n",
24d10b3d Felix Kuehling 2017-03-21  616
__func__, ret);
24d10b3d Felix Kuehling 2017-03-21  617 goto out;
24d10b3d Felix Kuehling 2017-03-21  618 }
24d10b3d Felix Kuehling 2017-03-21  619  
24d10b3d Felix Kuehling 2017-03-21  620 /* If no restore worker 
is running concurrently, user_pages
24d10b3d Felix Kuehling 2017-03-21  621  * should not be 
allocated
24d10b3d Felix Kuehling 2017-03-21  622  */
24d10b3d Felix Kuehling 2017-03-21  623 WARN(mem->user_pages, 
"Leaking user_pages array");
24d10b3d Felix Kuehling 2017-03-21  624  
96f59e87 Le.Ma  2017-09-11  625  #if LINUX_VERSION_CODE < 
KERNEL_VERSION(4, 12, 0)
24d10b3d Felix Kuehling 2017-03-21  626 mem->user_pages = 
drm_calloc_large(bo->tbo.ttm->num_pages,
24d10b3d Felix Kuehling 2017-03-21  627 
   sizeof(struct page *));
96f59e87 Le.Ma  2017-09-11  628  #else
96f59e87 Le.Ma  2017-09-11  629 mem->user_pages = 

[radeon-alex:amd-staging-dkms-4.13 3469/3830] drivers/gpu/drm/amd/amdkfd/kfd_device.c:365:7: error: too many arguments to function 'pci_enable_atomic_ops_to_root'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   7bde112fab15c0a28c1d056959167cd4393bf538
commit: 704c0ec9102104fba7fa522a1dac5c0f7f166a31 [3469/3830] drm/amdkcl: Update 
pci_enable_atomic_ops_to_root for upstreaming
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 704c0ec9102104fba7fa522a1dac5c0f7f166a31
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdkfd/kfd_device.c: In function 'kgd2kfd_probe':
>> drivers/gpu/drm/amd/amdkfd/kfd_device.c:365:7: error: too many arguments to 
>> function 'pci_enable_atomic_ops_to_root'
  if (pci_enable_atomic_ops_to_root(pdev,
  ^
   In file included from include/kcl/kcl_pci.h:4:0,
from drivers/gpu/drm/amd/amdkfd/backport/backport.h:9,
from :0:
   include/linux/pci.h:2013:5: note: declared here
int pci_enable_atomic_ops_to_root(struct pci_dev *dev);
^

vim +/pci_enable_atomic_ops_to_root +365 drivers/gpu/drm/amd/amdkfd/kfd_device.c

   346  
   347  struct kfd_dev *kgd2kfd_probe(struct kgd_dev *kgd,
   348  struct pci_dev *pdev, const struct kfd2kgd_calls *f2g)
   349  {
   350  struct kfd_dev *kfd;
   351  
   352  const struct kfd_device_info *device_info =
   353  
lookup_device_info(pdev->device);
   354  
   355  if (!device_info) {
   356  dev_err(kfd_device, "kgd2kfd_probe failed\n");
   357  return NULL;
   358  }
   359  
   360  if (device_info->needs_pci_atomics) {
   361  /* Allow BIF to recode atomics to PCIe 3.0 AtomicOps.
   362   * 32 and 64-bit requests are possible and must be
   363   * supported.
   364   */
 > 365  if (pci_enable_atomic_ops_to_root(pdev,
   366  PCI_EXP_DEVCAP2_ATOMIC_COMP32 |
   367  PCI_EXP_DEVCAP2_ATOMIC_COMP64) < 0) {
   368  dev_info(kfd_device,
   369  "skipped device %x:%x, PCI rejects 
atomics",
   370   pdev->vendor, pdev->device);
   371  return NULL;
   372  }
   373  }
   374  
   375  kfd = kzalloc(sizeof(*kfd), GFP_KERNEL);
   376  if (!kfd)
   377  return NULL;
   378  
   379  kfd->kgd = kgd;
   380  kfd->device_info = device_info;
   381  kfd->pdev = pdev;
   382  kfd->init_complete = false;
   383  kfd->kfd2kgd = f2g;
   384  
   385  mutex_init(>doorbell_mutex);
   386  memset(>doorbell_available_index, 0,
   387  sizeof(kfd->doorbell_available_index));
   388  
   389  return kfd;
   390  }
   391  

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


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

[radeon-alex:amd-staging-dkms-4.13 3810/3830] drivers/gpu//drm/radeon/radeon_kfd.c:166:2: error: unknown field 'open_graphic_handle' specified in initializer

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   7bde112fab15c0a28c1d056959167cd4393bf538
commit: ac9c689b72b5f0fdb7bfecc427d0aa4b2a5eccf5 [3810/3830] drm/amdgpu: Remove 
unused definitions, functions and interfaces
config: i386-randconfig-a0-201806 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout ac9c689b72b5f0fdb7bfecc427d0aa4b2a5eccf5
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/gpu//drm/radeon/radeon_kfd.c:166:2: error: unknown field 
>> 'open_graphic_handle' specified in initializer
 .open_graphic_handle = open_graphic_handle,
 ^
   drivers/gpu//drm/radeon/radeon_kfd.c:166:2: warning: initialization from 
incompatible pointer type
   drivers/gpu//drm/radeon/radeon_kfd.c:166:2: warning: (near initialization 
for 'kfd2kgd.alloc_pasid')
>> drivers/gpu//drm/radeon/radeon_kfd.c:169:2: error: unknown field 
>> 'init_pipeline' specified in initializer
 .init_pipeline = kgd_init_pipeline,
 ^
   drivers/gpu//drm/radeon/radeon_kfd.c:169:2: warning: initialization from 
incompatible pointer type
   drivers/gpu//drm/radeon/radeon_kfd.c:169:2: warning: (near initialization 
for 'kfd2kgd.init_interrupts')
>> drivers/gpu//drm/radeon/radeon_kfd.c:188:2: error: unknown field 
>> 'set_num_of_requests' specified in initializer
 .set_num_of_requests = set_num_of_requests,
 ^
   drivers/gpu//drm/radeon/radeon_kfd.c:188:2: warning: initialization from 
incompatible pointer type
   drivers/gpu//drm/radeon/radeon_kfd.c:188:2: warning: (near initialization 
for 'kfd2kgd.alloc_memory_of_scratch')
   In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpu//drm/radeon/radeon_kfd.c:23:
   drivers/gpu//drm/radeon/radeon_kfd.c: In function 'alloc_memory_of_gpu':
   drivers/gpu//drm/radeon/radeon_kfd.c:1427:32: warning: cast to pointer from 
integer of different size [-Wint-to-pointer-cast]
 pr_debug("Set BO to VA %p\n", (void *) va);
   ^
   include/linux/printk.h:136:18: note: in definition of macro 'no_printk'
   printk(fmt, ##__VA_ARGS__); \
 ^
   drivers/gpu//drm/radeon/radeon_kfd.c:1427:2: note: in expansion of macro 
'pr_debug'
 pr_debug("Set BO to VA %p\n", (void *) va);
 ^

vim +/open_graphic_handle +166 drivers/gpu//drm/radeon/radeon_kfd.c

e28740ece Oded Gabbay 2014-07-15  100  
e28740ece Oded Gabbay 2014-07-15  101  /*
e28740ece Oded Gabbay 2014-07-15  102   * Register access functions
e28740ece Oded Gabbay 2014-07-15  103   */
e28740ece Oded Gabbay 2014-07-15  104  
e28740ece Oded Gabbay 2014-07-15  105  static void 
kgd_program_sh_mem_settings(struct kgd_dev *kgd, uint32_t vmid,
e28740ece Oded Gabbay 2014-07-15  106   uint32_t sh_mem_config, 
uint32_t sh_mem_ape1_base,
e28740ece Oded Gabbay 2014-07-15  107   uint32_t 
sh_mem_ape1_limit, uint32_t sh_mem_bases);
e28740ece Oded Gabbay 2014-07-15  108  
e28740ece Oded Gabbay 2014-07-15  109  static int 
kgd_set_pasid_vmid_mapping(struct kgd_dev *kgd, unsigned int pasid,
e28740ece Oded Gabbay 2014-07-15  110   
unsigned int vmid);
e28740ece Oded Gabbay 2014-07-15  111  
e28740ece Oded Gabbay 2014-07-15  112  static int kgd_init_pipeline(struct 
kgd_dev *kgd, uint32_t pipe_id,
e28740ece Oded Gabbay 2014-07-15  113   
uint32_t hpd_size, uint64_t hpd_gpu_addr);
d36b94fcf Oded Gabbay 2015-03-05  114  static int 
kgd_init_interrupts(struct kgd_dev *kgd, uint32_t pipe_id);
e28740ece Oded Gabbay 2014-07-15  115  static int kgd_hqd_load(struct 
kgd_dev *kgd, void *mqd, uint32_t pipe_id,
3d1e75101 Jay Cornwall2016-10-24  116   uint32_t 
queue_id, uint32_t __user *wptr,
3d1e75101 Jay Cornwall2016-10-24  117   uint32_t 
wptr_shift, uint32_t wptr_mask,
3d1e75101 Jay Cornwall2016-10-24  118   struct 
mm_struct *mm);
dbb3576ec Felix Kuehling  2016-06-30  119  static int kgd_hqd_sdma_load(struct 
kgd_dev *kgd, void *mqd,
dbb3576ec Felix Kuehling  2016-06-30  120uint32_t 
__user *wptr, struct mm_struct *mm);
b64b8afcc Ben Goz 2014-12-09  121  static bool 
kgd_hqd_is_occupied(struct kgd_dev *kgd, uint64_t queue_address,
e28740ece Oded Gabbay 2014-07-15  122   
uint32_t pipe_id, uint32_t queue_id);
e28740ece Oded Gabbay 2014-07-15  123  
af98b47f0 Shaoyun Liu 2017-07-18  124  static int kgd_hqd_destroy(struct 
kgd_dev *kgd, void *mqd, uint32_t reset_type,
e28740ece Oded Gabbay 2014-07-15  125   
unsigned int timeout, uint32_t pipe_id,
e28740ece Oded Gabbay 2014-07-15  126   

[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

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

--- Comment #6 from Michael Zapf  ---
Created attachment 137386
  --> https://bugs.freedesktop.org/attachment.cgi?id=137386=edit
dmesg output after turning the monitor back on (2nd system)

This is another dmesg output, created on my office PC with a UHD display,
connected by DisplayPort.

The turn-off event occurs after time [2643.173460]. Turn-on occurs some seconds
later.

System was updated the same day in the morning (openSUSE Tumbleweed rolling
release, 4.15.2-1).

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

[radeon-alex:amd-staging-dkms-4.13 3272/3830] drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: incompatible type for argument 2 of 'ttm_bo_move_memcpy'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   7bde112fab15c0a28c1d056959167cd4393bf538
commit: d08b4d092e33c348cb01367e02e5dd2dd8104a46 [3272/3830] drm/ttm: use an 
ttm operation ctx for ttm_bo_move_xxx
config: i386-randconfig-a0-201806 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout d08b4d092e33c348cb01367e02e5dd2dd8104a46
# save the attached .config to linux build tree
make ARCH=i386 

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

   drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_move':
>> drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: incompatible type for 
>> argument 2 of 'ttm_bo_move_memcpy'
 return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
^
   In file included from drivers/staging//vboxvideo/vbox_drv.h:44:0,
from drivers/staging//vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_driver.h:1022:5: note: expected 'struct 
ttm_operation_ctx *' but argument is of type 'bool'
int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
^
   drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: incompatible type for 
argument 3 of 'ttm_bo_move_memcpy'
 return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
^
   In file included from drivers/staging//vboxvideo/vbox_drv.h:44:0,
from drivers/staging//vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_driver.h:1022:5: note: expected 'struct ttm_mem_reg 
*' but argument is of type 'bool'
int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
^
>> drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: too many arguments to 
>> function 'ttm_bo_move_memcpy'
 return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
^
   In file included from drivers/staging//vboxvideo/vbox_drv.h:44:0,
from drivers/staging//vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_driver.h:1022:5: note: declared here
int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
^
   drivers/staging//vboxvideo/vbox_ttm.c: At top level:
   drivers/staging//vboxvideo/vbox_ttm.c:240:2: warning: initialization from 
incompatible pointer type
 .move = vbox_bo_move,
 ^
   drivers/staging//vboxvideo/vbox_ttm.c:240:2: warning: (near initialization 
for 'vbox_bo_driver.move')
   drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_pin':
   drivers/staging//vboxvideo/vbox_ttm.c:392:8: error: too many arguments to 
function 'ttm_bo_validate'
 ret = ttm_bo_validate(>bo, >placement, false, false);
   ^
   In file included from drivers/staging//vboxvideo/vbox_drv.h:43:0,
from drivers/staging//vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:339:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object *bo,
^
   drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_unpin':
   drivers/staging//vboxvideo/vbox_ttm.c:419:8: error: too many arguments to 
function 'ttm_bo_validate'
 ret = ttm_bo_validate(>bo, >placement, false, false);
   ^
   In file included from drivers/staging//vboxvideo/vbox_drv.h:43:0,
from drivers/staging//vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:339:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object *bo,
^
   drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_push_sysram':
   drivers/staging//vboxvideo/vbox_ttm.c:451:8: error: too many arguments to 
function 'ttm_bo_validate'
 ret = ttm_bo_validate(>bo, >placement, false, false);
   ^
   In file included from drivers/staging//vboxvideo/vbox_drv.h:43:0,
from drivers/staging//vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:339:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object *bo,
^
   drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_move':
>> drivers/staging//vboxvideo/vbox_ttm.c:191:1: warning: control reaches end of 
>> non-void function [-Wreturn-type]
}
^

vim +/ttm_bo_move_memcpy +190 drivers/staging//vboxvideo/vbox_ttm.c

dd55d44f4 Hans de Goede 2017-07-06  185  
dd55d44f4 Hans de Goede 2017-07-06  186  static int vbox_bo_move(struct 
ttm_buffer_object *bo,
dd55d44f4 Hans de Goede 2017-07-06  187 bool evict, 
bool interruptible,
dd55d44f4 Hans de Goede 2017-07-06  188 bool 
no_wait_gpu, struct ttm_mem_reg *new_mem)
dd55d44f4 Hans de Goede 2017-07-06  189  {
dd55d44f4 Hans de Goede 2017-07-06 @190 return ttm_bo_move_memcpy(bo, 
interruptible, no_wait_gpu, new_mem);
dd55d44f4 Hans de Goede 2017-07-06 @191  }
dd55d44f4 Hans de Goede 2017-07-06  192  

:: The code at line 190 was first introduced by commit
:: dd55d44f408419278c00887bfcb2261d0caae350 staging: vboxvideo: Add 
vboxvideo to drivers/staging

:: TO: Hans de Goede 

[radeon-alex:amd-staging-dkms-4.13 3177/3830] drivers/gpu/drm/radeon/radeon_kfd.c:184:2: warning: initialization from incompatible pointer type

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   7bde112fab15c0a28c1d056959167cd4393bf538
commit: c30b9ce3a991b4531329cad536b3d7681acb6108 [3177/3830] amd/amdkfd: Remove 
write_vmid_invalidate_request() from kfd2kgd interface
config: i386-randconfig-a0-201806 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout c30b9ce3a991b4531329cad536b3d7681acb6108
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/radeon/radeon_kfd.c:184:2: error: unknown field 
'write_vmid_invalidate_request' specified in initializer
 .write_vmid_invalidate_request = write_vmid_invalidate_request,
 ^
>> drivers/gpu/drm/radeon/radeon_kfd.c:184:2: warning: initialization from 
>> incompatible pointer type
   drivers/gpu/drm/radeon/radeon_kfd.c:184:2: warning: (near initialization for 
'kfd2kgd.get_atc_vmid_pasid_mapping_pasid')
   In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpu/drm/radeon/radeon_kfd.c:23:
   drivers/gpu/drm/radeon/radeon_kfd.c: In function 'alloc_memory_of_gpu':
   drivers/gpu/drm/radeon/radeon_kfd.c:1435:32: warning: cast to pointer from 
integer of different size [-Wint-to-pointer-cast]
 pr_debug("Set BO to VA %p\n", (void *) va);
   ^
   include/linux/printk.h:136:18: note: in definition of macro 'no_printk'
   printk(fmt, ##__VA_ARGS__); \
 ^
   drivers/gpu/drm/radeon/radeon_kfd.c:1435:2: note: in expansion of macro 
'pr_debug'
 pr_debug("Set BO to VA %p\n", (void *) va);
 ^

vim +184 drivers/gpu/drm/radeon/radeon_kfd.c

e28740ece Oded Gabbay 2014-07-15  100  
e28740ece Oded Gabbay 2014-07-15  101  /*
e28740ece Oded Gabbay 2014-07-15  102   * Register access functions
e28740ece Oded Gabbay 2014-07-15  103   */
e28740ece Oded Gabbay 2014-07-15  104  
e28740ece Oded Gabbay 2014-07-15  105  static void 
kgd_program_sh_mem_settings(struct kgd_dev *kgd, uint32_t vmid,
e28740ece Oded Gabbay 2014-07-15  106   uint32_t sh_mem_config, 
uint32_t sh_mem_ape1_base,
e28740ece Oded Gabbay 2014-07-15  107   uint32_t 
sh_mem_ape1_limit, uint32_t sh_mem_bases);
e28740ece Oded Gabbay 2014-07-15  108  
e28740ece Oded Gabbay 2014-07-15  109  static int 
kgd_set_pasid_vmid_mapping(struct kgd_dev *kgd, unsigned int pasid,
e28740ece Oded Gabbay 2014-07-15  110   
unsigned int vmid);
e28740ece Oded Gabbay 2014-07-15  111  
e28740ece Oded Gabbay 2014-07-15  112  static int kgd_init_pipeline(struct 
kgd_dev *kgd, uint32_t pipe_id,
e28740ece Oded Gabbay 2014-07-15  113   
uint32_t hpd_size, uint64_t hpd_gpu_addr);
d36b94fcf Oded Gabbay 2015-03-05  114  static int 
kgd_init_interrupts(struct kgd_dev *kgd, uint32_t pipe_id);
e28740ece Oded Gabbay 2014-07-15  115  static int kgd_hqd_load(struct 
kgd_dev *kgd, void *mqd, uint32_t pipe_id,
3d1e75101 Jay Cornwall2016-10-24  116   uint32_t 
queue_id, uint32_t __user *wptr,
3d1e75101 Jay Cornwall2016-10-24  117   uint32_t 
wptr_shift, uint32_t wptr_mask,
3d1e75101 Jay Cornwall2016-10-24  118   struct 
mm_struct *mm);
dbb3576ec Felix Kuehling  2016-06-30  119  static int kgd_hqd_sdma_load(struct 
kgd_dev *kgd, void *mqd,
dbb3576ec Felix Kuehling  2016-06-30  120uint32_t 
__user *wptr, struct mm_struct *mm);
b64b8afcc Ben Goz 2014-12-09  121  static bool 
kgd_hqd_is_occupied(struct kgd_dev *kgd, uint64_t queue_address,
e28740ece Oded Gabbay 2014-07-15  122   
uint32_t pipe_id, uint32_t queue_id);
e28740ece Oded Gabbay 2014-07-15  123  
af98b47f0 Shaoyun Liu 2017-07-18  124  static int kgd_hqd_destroy(struct 
kgd_dev *kgd, void *mqd, uint32_t reset_type,
e28740ece Oded Gabbay 2014-07-15  125   
unsigned int timeout, uint32_t pipe_id,
e28740ece Oded Gabbay 2014-07-15  126   
uint32_t queue_id);
a84a9903b Ben Goz 2015-01-03  127  static bool 
kgd_hqd_sdma_is_occupied(struct kgd_dev *kgd, void *mqd);
a84a9903b Ben Goz 2015-01-03  128  static int 
kgd_hqd_sdma_destroy(struct kgd_dev *kgd, void *mqd,
a84a9903b Ben Goz 2015-01-03  129   
unsigned int timeout);
a6186f4d6 Yair Shachar2014-09-28  130  static int 
kgd_address_watch_disable(struct kgd_dev *kgd);
a6186f4d6 Yair Shachar2014-09-28  131  static int 
kgd_address_watch_execute(struct kgd_dev *kgd,
a6186f4d6 Yair Shachar2014-09-28  132   
unsigned int watch_point_id,
a6186f4d6 Yair Shachar2014-09-28  133

[radeon-alex:amd-staging-dkms-4.13 3810/3830] drivers/gpu/drm/radeon/radeon_kfd.c:166:3: error: 'const struct kfd2kgd_calls' has no member named 'open_graphic_handle'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   7bde112fab15c0a28c1d056959167cd4393bf538
commit: ac9c689b72b5f0fdb7bfecc427d0aa4b2a5eccf5 [3810/3830] drm/amdgpu: Remove 
unused definitions, functions and interfaces
config: i386-randconfig-i1-201806 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout ac9c689b72b5f0fdb7bfecc427d0aa4b2a5eccf5
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/radeon/radeon_kfd.c:166:3: error: 'const struct 
>> kfd2kgd_calls' has no member named 'open_graphic_handle'
 .open_graphic_handle = open_graphic_handle,
  ^~~
>> drivers/gpu/drm/radeon/radeon_kfd.c:166:25: error: initialization from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
 .open_graphic_handle = open_graphic_handle,
^~~
   drivers/gpu/drm/radeon/radeon_kfd.c:166:25: note: (near initialization for 
'kfd2kgd.alloc_pasid')
>> drivers/gpu/drm/radeon/radeon_kfd.c:169:3: error: 'const struct 
>> kfd2kgd_calls' has no member named 'init_pipeline'
 .init_pipeline = kgd_init_pipeline,
  ^
   drivers/gpu/drm/radeon/radeon_kfd.c:169:19: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 .init_pipeline = kgd_init_pipeline,
  ^
   drivers/gpu/drm/radeon/radeon_kfd.c:169:19: note: (near initialization for 
'kfd2kgd.init_interrupts')
>> drivers/gpu/drm/radeon/radeon_kfd.c:188:3: error: 'const struct 
>> kfd2kgd_calls' has no member named 'set_num_of_requests'
 .set_num_of_requests = set_num_of_requests,
  ^~~
   drivers/gpu/drm/radeon/radeon_kfd.c:188:25: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 .set_num_of_requests = set_num_of_requests,
^~~
   drivers/gpu/drm/radeon/radeon_kfd.c:188:25: note: (near initialization for 
'kfd2kgd.alloc_memory_of_scratch')
   In file included from include/linux/printk.h:329:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpu/drm/radeon/radeon_kfd.c:23:
   drivers/gpu/drm/radeon/radeon_kfd.c: In function 'alloc_memory_of_gpu':
   drivers/gpu/drm/radeon/radeon_kfd.c:1427:32: warning: cast to pointer from 
integer of different size [-Wint-to-pointer-cast]
 pr_debug("Set BO to VA %p\n", (void *) va);
   ^
   include/linux/dynamic_debug.h:127:10: note: in definition of macro 
'dynamic_pr_debug'
   ##__VA_ARGS__);  \
 ^~~
   drivers/gpu/drm/radeon/radeon_kfd.c:1427:2: note: in expansion of macro 
'pr_debug'
 pr_debug("Set BO to VA %p\n", (void *) va);
 ^~~~
   cc1: some warnings being treated as errors

vim +166 drivers/gpu/drm/radeon/radeon_kfd.c

e28740ece Oded Gabbay 2014-07-15  100  
e28740ece Oded Gabbay 2014-07-15  101  /*
e28740ece Oded Gabbay 2014-07-15  102   * Register access functions
e28740ece Oded Gabbay 2014-07-15  103   */
e28740ece Oded Gabbay 2014-07-15  104  
e28740ece Oded Gabbay 2014-07-15  105  static void 
kgd_program_sh_mem_settings(struct kgd_dev *kgd, uint32_t vmid,
e28740ece Oded Gabbay 2014-07-15  106   uint32_t sh_mem_config, 
uint32_t sh_mem_ape1_base,
e28740ece Oded Gabbay 2014-07-15  107   uint32_t 
sh_mem_ape1_limit, uint32_t sh_mem_bases);
e28740ece Oded Gabbay 2014-07-15  108  
e28740ece Oded Gabbay 2014-07-15  109  static int 
kgd_set_pasid_vmid_mapping(struct kgd_dev *kgd, unsigned int pasid,
e28740ece Oded Gabbay 2014-07-15  110   
unsigned int vmid);
e28740ece Oded Gabbay 2014-07-15  111  
e28740ece Oded Gabbay 2014-07-15  112  static int kgd_init_pipeline(struct 
kgd_dev *kgd, uint32_t pipe_id,
e28740ece Oded Gabbay 2014-07-15  113   
uint32_t hpd_size, uint64_t hpd_gpu_addr);
d36b94fcf Oded Gabbay 2015-03-05  114  static int 
kgd_init_interrupts(struct kgd_dev *kgd, uint32_t pipe_id);
e28740ece Oded Gabbay 2014-07-15  115  static int kgd_hqd_load(struct 
kgd_dev *kgd, void *mqd, uint32_t pipe_id,
3d1e75101 Jay Cornwall2016-10-24  116   uint32_t 
queue_id, uint32_t __user *wptr,
3d1e75101 Jay Cornwall2016-10-24  117   uint32_t 
wptr_shift, uint32_t wptr_mask,
3d1e75101 Jay Cornwall2016-10-24  118   struct 
mm_struct *mm);
dbb3576ec Felix Kuehling  2016-06-30  119  static int kgd_hqd_sdma_load(struct 
kgd_dev *kgd, void *mqd,
dbb3576ec Felix Kuehling  2016-06-30  120uint32_t 
__user *wptr, struct mm_struct *mm);
b64b8afcc Ben Goz 

[radeon-alex:amd-staging-dkms-4.13 2525/3830] drivers/staging/vboxvideo/vbox_ttm.c:392:8: error: too many arguments to function 'ttm_bo_validate'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   7bde112fab15c0a28c1d056959167cd4393bf538
commit: 7f7a03f8049d505d450f27973d5c96af13bc8fe6 [2525/3830] drm/ttm: add 
operation ctx to ttm_bo_validate v2
config: i386-randconfig-a0-201806 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 7f7a03f8049d505d450f27973d5c96af13bc8fe6
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/staging/vboxvideo/vbox_ttm.c: In function 'vbox_bo_pin':
>> drivers/staging/vboxvideo/vbox_ttm.c:392:8: error: too many arguments to 
>> function 'ttm_bo_validate'
 ret = ttm_bo_validate(>bo, >placement, false, false);
   ^
   In file included from drivers/staging/vboxvideo/vbox_drv.h:43:0,
from drivers/staging/vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:334:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object *bo,
^
   drivers/staging/vboxvideo/vbox_ttm.c: In function 'vbox_bo_unpin':
   drivers/staging/vboxvideo/vbox_ttm.c:419:8: error: too many arguments to 
function 'ttm_bo_validate'
 ret = ttm_bo_validate(>bo, >placement, false, false);
   ^
   In file included from drivers/staging/vboxvideo/vbox_drv.h:43:0,
from drivers/staging/vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:334:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object *bo,
^
   drivers/staging/vboxvideo/vbox_ttm.c: In function 'vbox_bo_push_sysram':
   drivers/staging/vboxvideo/vbox_ttm.c:451:8: error: too many arguments to 
function 'ttm_bo_validate'
 ret = ttm_bo_validate(>bo, >placement, false, false);
   ^
   In file included from drivers/staging/vboxvideo/vbox_drv.h:43:0,
from drivers/staging/vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:334:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object *bo,
^

vim +/ttm_bo_validate +392 drivers/staging/vboxvideo/vbox_ttm.c

dd55d44f4 Hans de Goede 2017-07-06  374  
dd55d44f4 Hans de Goede 2017-07-06  375  int vbox_bo_pin(struct vbox_bo *bo, 
u32 pl_flag, u64 *gpu_addr)
dd55d44f4 Hans de Goede 2017-07-06  376  {
dd55d44f4 Hans de Goede 2017-07-06  377 int i, ret;
dd55d44f4 Hans de Goede 2017-07-06  378  
dd55d44f4 Hans de Goede 2017-07-06  379 if (bo->pin_count) {
dd55d44f4 Hans de Goede 2017-07-06  380 bo->pin_count++;
dd55d44f4 Hans de Goede 2017-07-06  381 if (gpu_addr)
dd55d44f4 Hans de Goede 2017-07-06  382 *gpu_addr = 
vbox_bo_gpu_offset(bo);
dd55d44f4 Hans de Goede 2017-07-06  383  
dd55d44f4 Hans de Goede 2017-07-06  384 return 0;
dd55d44f4 Hans de Goede 2017-07-06  385 }
dd55d44f4 Hans de Goede 2017-07-06  386  
dd55d44f4 Hans de Goede 2017-07-06  387 vbox_ttm_placement(bo, pl_flag);
dd55d44f4 Hans de Goede 2017-07-06  388  
dd55d44f4 Hans de Goede 2017-07-06  389 for (i = 0; i < 
bo->placement.num_placement; i++)
dd55d44f4 Hans de Goede 2017-07-06  390 bo->placements[i].flags 
|= TTM_PL_FLAG_NO_EVICT;
dd55d44f4 Hans de Goede 2017-07-06  391  
dd55d44f4 Hans de Goede 2017-07-06 @392 ret = ttm_bo_validate(>bo, 
>placement, false, false);
dd55d44f4 Hans de Goede 2017-07-06  393 if (ret)
dd55d44f4 Hans de Goede 2017-07-06  394 return ret;
dd55d44f4 Hans de Goede 2017-07-06  395  
dd55d44f4 Hans de Goede 2017-07-06  396 bo->pin_count = 1;
dd55d44f4 Hans de Goede 2017-07-06  397  
dd55d44f4 Hans de Goede 2017-07-06  398 if (gpu_addr)
dd55d44f4 Hans de Goede 2017-07-06  399 *gpu_addr = 
vbox_bo_gpu_offset(bo);
dd55d44f4 Hans de Goede 2017-07-06  400  
dd55d44f4 Hans de Goede 2017-07-06  401 return 0;
dd55d44f4 Hans de Goede 2017-07-06  402  }
dd55d44f4 Hans de Goede 2017-07-06  403  

:: The code at line 392 was first introduced by commit
:: dd55d44f408419278c00887bfcb2261d0caae350 staging: vboxvideo: Add 
vboxvideo to drivers/staging

:: TO: Hans de Goede 
:: CC: Greg Kroah-Hartman 

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


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

[Bug 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

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

Ainola  changed:

   What|Removed |Added

 CC||b...@i--b.com

--- Comment #19 from Ainola  ---
Created attachment 137383
  --> https://bugs.freedesktop.org/attachment.cgi?id=137383=edit
stacktrace even with patches

I just got another freeze despite using the patches. I'm not sure if this is
the same bug since it mentions slub.c but I see amdgpu/drm stuff in the trace.
After this trace the journal was flooded with items like
"amdgpu_dm_irq_schedule_work FAILED src 4" (it alternates between 2 and 4)

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

[pull] amdgpu drm-next-4.16

[Alex Deucher]

Hi Dave,

Just one fix for a hybrid laptop for 4.16.

The following changes since commit 94fc27ac487a80daf42f97b1a0503d029f3c1325:

  Merge tag 'drm-intel-next-fixes-2018-02-07' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-02-08 08:21:37 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.16

for you to fetch changes up to 6e59de2048eb375a9bfcd39461ef841cd2a78962:

  drm/amdgpu: add new device to use atpx quirk (2018-02-08 18:05:03 -0500)


Kai-Heng Feng (1):
  drm/amdgpu: add new device to use atpx quirk

 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 +
 1 file changed, 1 insertion(+)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm/dpu: Remove unused code and move the header

[Jordan Crouse]

Remove unused code from dpu_io_util.c.  The functions are only
used inside of the msm driver so remove the EXPORT_SYMBOL
tags and move the header dpu_io_util.h from include/linux.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/dp/dp_parser.h |   2 +-
 drivers/gpu/drm/msm/dpu_io_util.c  | 154 ++---
 .../linux => drivers/gpu/drm/msm}/dpu_io_util.h|  10 --
 drivers/gpu/drm/msm/dpu_power_handle.c |   1 -
 drivers/gpu/drm/msm/dpu_power_handle.h |   2 +-
 drivers/gpu/drm/msm/dpu_rsc_priv.h |   1 -
 drivers/gpu/drm/msm/msm_drv.h  |   1 -
 7 files changed, 14 insertions(+), 157 deletions(-)
 rename {include/linux => drivers/gpu/drm/msm}/dpu_io_util.h (86%)

diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h 
b/drivers/gpu/drm/msm/dp/dp_parser.h
index a9cfd03fa5ed..703acb010c8b 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -15,7 +15,7 @@
 #ifndef _DP_PARSER_H_
 #define _DP_PARSER_H_
 
-#include 
+#include "dpu_io_util.h"
 
 #define DP_LABEL "MDSS DP DISPLAY"
 #define AUX_CFG_LEN10
diff --git a/drivers/gpu/drm/msm/dpu_io_util.c 
b/drivers/gpu/drm/msm/dpu_io_util.c
index a18bc992c136..f39ae38e4cfa 100644
--- a/drivers/gpu/drm/msm/dpu_io_util.c
+++ b/drivers/gpu/drm/msm/dpu_io_util.c
@@ -16,9 +16,9 @@
 #include 
 #include 
 #include 
-#include 
 
-#define MAX_I2C_CMDS  16
+#include "dpu_io_util.h"
+
 void dss_reg_w(struct dss_io_data *io, u32 offset, u32 value, u32 debug)
 {
u32 in_val;
@@ -42,8 +42,7 @@ void dss_reg_w(struct dss_io_data *io, u32 offset, u32 value, 
u32 debug)
(u32)(unsigned long)(io->base + offset),
value, in_val);
}
-} /* dss_reg_w */
-EXPORT_SYMBOL(dss_reg_w);
+}
 
 u32 dss_reg_r(struct dss_io_data *io, u32 offset, u32 debug)
 {
@@ -67,30 +66,7 @@ u32 dss_reg_r(struct dss_io_data *io, u32 offset, u32 debug)
(u32)(unsigned long)(io->base + offset), value);
 
return value;
-} /* dss_reg_r */
-EXPORT_SYMBOL(dss_reg_r);
-
-void dss_reg_dump(void __iomem *base, u32 length, const char *prefix,
-   u32 debug)
-{
-   if (debug)
-   print_hex_dump(KERN_INFO, prefix, DUMP_PREFIX_OFFSET, 32, 4,
-   (void *)base, length, false);
-} /* dss_reg_dump */
-EXPORT_SYMBOL(dss_reg_dump);
-
-static struct resource *msm_dss_get_res_byname(struct platform_device *pdev,
-   unsigned int type, const char *name)
-{
-   struct resource *res = NULL;
-
-   res = platform_get_resource_byname(pdev, type, name);
-   if (!res)
-   DEV_ERR("%s: '%s' resource not found\n", __func__, name);
-
-   return res;
-} /* msm_dss_get_res_byname */
-EXPORT_SYMBOL(msm_dss_get_res_byname);
+}
 
 int msm_dss_ioremap_byname(struct platform_device *pdev,
struct dss_io_data *io_data, const char *name)
@@ -103,7 +79,7 @@ int msm_dss_ioremap_byname(struct platform_device *pdev,
return -EINVAL;
}
 
-   res = msm_dss_get_res_byname(pdev, IORESOURCE_MEM, name);
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
if (!res) {
DEV_ERR("%pS->%s: '%s' msm_dss_get_res_byname failed\n",
__builtin_return_address(0), __func__, name);
@@ -119,8 +95,7 @@ int msm_dss_ioremap_byname(struct platform_device *pdev,
}
 
return 0;
-} /* msm_dss_ioremap_byname */
-EXPORT_SYMBOL(msm_dss_ioremap_byname);
+}
 
 void msm_dss_iounmap(struct dss_io_data *io_data)
 {
@@ -135,8 +110,7 @@ void msm_dss_iounmap(struct dss_io_data *io_data)
io_data->base = NULL;
}
io_data->len = 0;
-} /* msm_dss_iounmap */
-EXPORT_SYMBOL(msm_dss_iounmap);
+}
 
 int msm_dss_config_vreg(struct device *dev, struct dss_vreg *in_vreg,
int num_vreg, int config)
@@ -211,8 +185,7 @@ if (type == DSS_REG_LDO)
goto vreg_unconfig;
}
return rc;
-} /* msm_dss_config_vreg */
-EXPORT_SYMBOL(msm_dss_config_vreg);
+}
 
 int msm_dss_enable_vreg(struct dss_vreg *in_vreg, int num_vreg, int enable)
 {
@@ -283,48 +256,7 @@ int msm_dss_enable_vreg(struct dss_vreg *in_vreg, int 
num_vreg, int enable)
}
 
return rc;
-} /* msm_dss_enable_vreg */
-EXPORT_SYMBOL(msm_dss_enable_vreg);
-
-int msm_dss_enable_gpio(struct dss_gpio *in_gpio, int num_gpio, int enable)
-{
-   int i = 0, rc = 0;
-
-   if (enable) {
-   for (i = 0; i < num_gpio; i++) {
-   DEV_DBG("%pS->%s: %s enable\n",
-   __builtin_return_address(0), __func__,
-   in_gpio[i].gpio_name);
-
-   rc = gpio_request(in_gpio[i].gpio,
-   in_gpio[i].gpio_name);
-   if (rc < 0) {
-   DEV_ERR("%pS->%s: %s enable failed\n",
- 

Re: [PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

[Alex Deucher]

On Thu, Feb 15, 2018 at 9:19 AM, Christian König
 wrote:
> amdgpu needs to verify if userspace sends us valid addresses and the simplest
> way of doing this is to check if the buffer object is locked with the ticket
> of the current submission.
>
> Clean up the access to the ww_mutex internals by providing a function
> for this and extend the check to the thread owning the underlying mutex.
>
> Signed-off-by: Christian König 

Shouldn't this be two patches?  One to add the new ww_mutex code and
one to update amdgpu?

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  3 ++-
>  include/linux/ww_mutex.h   | 17 +
>  2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index eaa3cb0c3ad1..4c04b560e358 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -1594,7 +1594,8 @@ int amdgpu_cs_find_mapping(struct amdgpu_cs_parser 
> *parser,
> *map = mapping;
>
> /* Double check that the BO is reserved by this CS */
> -   if (READ_ONCE((*bo)->tbo.resv->lock.ctx) != >ticket)
> +   if (!ww_mutex_is_owned_by(&(*bo)->tbo.resv->lock, current,
> + >ticket))
> return -EINVAL;
>
> if (!((*bo)->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS)) {
> diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
> index 39fda195bf78..dd580db289e8 100644
> --- a/include/linux/ww_mutex.h
> +++ b/include/linux/ww_mutex.h
> @@ -358,4 +358,21 @@ static inline bool ww_mutex_is_locked(struct ww_mutex 
> *lock)
> return mutex_is_locked(>base);
>  }
>
> +/**
> + * ww_mutex_is_owned_by - is the w/w mutex locked by this task in that 
> context
> + * @lock: the mutex to be queried
> + * @task: the task structure to check
> + * @ctx: the w/w acquire context to test
> + *
> + * Returns true if the mutex is locked in the context by the given task, 
> false
> + * otherwise.
> + */
> +static inline bool ww_mutex_is_owned_by(struct ww_mutex *lock,
> +   struct task_struct *task,
> +   struct ww_acquire_ctx *ctx)
> +{
> +   return likely(__mutex_owner(>base) == task) &&
> +   READ_ONCE(lock->ctx) == ctx;
> +}
> +
>  #endif
> --
> 2.14.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: nerved -> nerfed in drm_ioctl.c

[Alex Deucher]

On Thu, Feb 15, 2018 at 2:56 PM, Harry Wentland  wrote:
> On 2018-02-15 11:40 AM, Daniel Stone wrote:
>> Hi Harry,
>>
>> On 15 February 2018 at 16:28, Harry Wentland  wrote:
>>> This threw me for a loop when I read the docs. I imagine this is the
>>> intended definition:
>>> http://www.dictionary.com/browse/nerf
>>
>> Yeah. I'm quite sure it was intended to be 'nerfed', but replacing it
>> with something more clear (and especially more accessible to
>> non-native speakers) would be great if you could do that instead
>> please. :)
>
> Good point.
>
> danvet, I'm not sure exactly what nerfed really means in this context? Does 
> it mean 'dropped', 'deprecated', 'no longer supported'?
>

I think in this context, it means broken.

Alex

> I also see a reference to drm version 1.4 but I only see version 1.3 in 
> libdrm?
>
> Harry
>
>>
>> Cheers,
>> Daniel
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [PATCH 07/21] vulkan: Add EXT_acquire_xlib_display

[Keith Packard]

Eric Engestrom  writes:

> Can be simplified a bit:
>
>   _xlib_lease = get_option('xlib-lease')
>   if _xlib_lease == 'auto'
> with_xlib_lease = with_platform_x11 and with_platform_display
>   else
> with_xlib_lease = _xlib_lease == 'true'
>   endif
>
> (We also usually try to avoid changing the type of a var, and meson might
> start being more strict with types in future releases)

I wondered about that in the places I copied my code from. Good to know
there's a better practice. I've switched to using this form.

>> +if with_xlib_lease
>> +  vulkan_wsi_deps += dep_xcb_xrandr
>> +  vulkan_wsi_args += [
>> +'-DVK_USE_PLATFORM_XLIB_XRANDR_EXT',
>> +  ]
>
> vulkan_wsi_args += '-DVK_USE_PLATFORM_XLIB_XRANDR_EXT'

I switched all of the inappropriate usage to this form for six separate
patches (three each for core/anv/radv by two extensions (DISPLAY and 
XLIB_XRANDR).

> with that, the meson part of this is
> Reviewed-by: Eric Engestrom 

Awesome!

Thanks for reviewing the build system bits; I'm just starting to use
meson and every new change is a learning opportunity at this point.

-- 
-keith


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

Re: [Freedreno] [RFC PULL] Add Display Support for Qualcomm SDM845

[Jordan Crouse]

On Tue, Feb 13, 2018 at 02:18:13PM -0500, Sean Paul wrote:
> Hi dri-devel,
> Qualcomm has been working for the past few weeks on forward porting their
> downstream drm driver from 4.14 to mainline. Please consider this PR as a
> request for review, rather than an attempt at mainlining the code as it
> currently stands. The goal is get this driver in shape over the next coming
> months.
> 
> In the meantime, I'll be hosting a tree here [1] to stage the fixes. Patches
> will be posted and reviewed on linux-arm-...@vger.kernel.org. Once things look
> good, I'll send another pull 4realz.
> 
> To get the ball rolling, I've done some review on the new connector code, my
> comments are below.
> 
> Thanks in advance for your constructive feedback :)
> 
> Sean
> 
> [1]- git://people.freedesktop.org/~seanpaul/dpu-staging
> 
> Review feedback:
> 
> - Solve the splash screen handling (or remove it)
> - Simplify devicetree binding (remove register offsets)
> feedback from reviewing sde_connector.c:
> - Rationalize backlight implementation in sde_connector (display_count static)
> - Sort out the dsi event passing between dsi/encoder/connector (move to 
> encoder)
> - include/uapi/drm/msm_drm_pp.h needs opensource userspace (or removal)
> - connector->state access violations reading/writing mode_info
> - s/sde_rect/drm_rect/
> - sde_kms_info usage needs to be replaced with formal data structures (not 
>   stringified keypairs)
> - sde_connector_ops needs to be trimmed, duplicates connector helpers, info
>   hooks circumvent state, and other hooks should be stored in state or
>   prepopulated (get_dst_format)
> - sde_connector_get_dpms unused
> - esd status check should migrate to encoder from connector
> - backlight should be handled in panel drivers, not in the generic 
> connector/dsi
>   encoder
> - sde_connector_helper_bridge_disable is called from encoder and calls back 
> into
>   set_power encoder function. if backlight, and esd status are removed,
>   pre_kickoff can probably go away
> - sde_connector_clk_ctrl is another example of encoder->connector->encoder 
> call
> - RETIRE_FENCE connector property should be removed, opting for the native
>   atomic fences
> - ROI (regions of interest) should be expressed per-plane instead of 
> connector.
>   there is work ongoing to support dirty_rects per-plane by Deepak Singh Rawat
>    and Lukasz Spintzyk 
> - Uma Shankar  has proposed HDR source metadata
>   properties on the list, we should pivot to those instead of hand-rolling 
> them
>   in the sde driver
> - Convert HDCP implementation to upstream Content Protection property
> - Merge dsi and dsi_staging into one driver
> - Writeback connector has been proposed by ARM (Liviu Dudau and Brian 
> Starkey),
>   we should work with their proposal instead of rolling OUT_FB ourselves
> - sde_connector_set_property should be replaced with atomic helper
> - dsi hotplug can probably be punted to the panel driver
> - dpms should switch to enable/disable (or at least use the atomic helpers)
> - dsi mode handling should also defer to the panel driver
> - SDE_WB_CONFIG ioctl should be removed in favor of the existing ioctl to add
>   user-defined modes
> - dp implementation should use the existing dp helpers wherever possible
> - lots of duplicated structures in dsi_defs.h that can be replaced with 
> existing
>   drm structs
> - mode_valid should be split up and implemented directly in connector/encoder 
> as
>   appropriate
> - sde_connector->aspace seems like it's unused?
> 
> 
> The following changes since commit 9afe236df559d0dc6818f64e728a3f931a0a2231:
> 
>   drm/msm/dsi: Fix potential NULL pointer dereference in msm_dsi_modeset_init 
> (2018-02-12 10:25:15 -0500)
> 
> are available in the Git repository at:
> 
>   git://people.freedesktop.org/~seanpaul/dpu-staging for-next-compiles
> 
> for you to fetch changes up to 672005da148f82021a62d4fa658728e19f13097e:
> 
>   ARM: dts: msm: add device tree changes for SDM845 (2018-02-13 13:14:43 
> -0500)
> 
> 
> Jeykumar Sankaran (9):
>   dt-bindings: msm/dsi: Add mdp transfer time to msm dsi binding
>   dt-bindings: msm/disp: Add bindings for Snapdragon 845 DPU
>   drm: Core changes
>   drm/msm: add DPU DRM driver to support SDM845
>   drm/msm: Change mdp_get_format arguments
>   drm/msm: Core msm changes
>   drm/msm: Add DSI Staging driver
>   drm/msm: Add DisplayPort support
>   ARM: dts: msm: add device tree changes for SDM845
> 
> Manasi Navare (1):
>   drm/dp: Add HBR3 support in existing DRM DP helpers
> 
> Rob Clark (1):
>   drm/msm: rename mdp->disp
> 
>  drivers/gpu/drm/msm/dpu_io_util.c  |  507 ++
>  include/linux/dpu_io_util.h|  113 +

This looks like it was borrowed from some older downstream code - its mostly a
wrapper for iomem and 

Re: [PATCH] drm/doc: nerved -> nerfed in drm_ioctl.c

[Harry Wentland]

On 2018-02-15 11:40 AM, Daniel Stone wrote:
> Hi Harry,
> 
> On 15 February 2018 at 16:28, Harry Wentland  wrote:
>> This threw me for a loop when I read the docs. I imagine this is the
>> intended definition:
>> http://www.dictionary.com/browse/nerf
> 
> Yeah. I'm quite sure it was intended to be 'nerfed', but replacing it
> with something more clear (and especially more accessible to
> non-native speakers) would be great if you could do that instead
> please. :)

Good point.

danvet, I'm not sure exactly what nerfed really means in this context? Does it 
mean 'dropped', 'deprecated', 'no longer supported'?

I also see a reference to drm version 1.4 but I only see version 1.3 in libdrm?

Harry

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

Re: [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Rodrigo Vivi]

Dave Airlie  writes:

> On 6 February 2018 at 06:32, Rodrigo Vivi  wrote:
>> On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
>>> Dhinakaran Pandiyan  writes:
>>>
>>> > From: "Pandiyan, Dhinakaran" 
>>> >
>>> > drm_vblank_count() has an u32 type returning what is a 64-bit vblank 
>>> > count.
>>> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
>>> > space requested vblank sequence using this clipped 32-bit count(when the
>>> > value is >= 2^32) as reference, the requested sequence remains a 32-bit
>>> > value and gets queued like that. However, the code that checks if the
>>> > requested sequence has passed compares this against the 64-bit vblank
>>> > count.
>>>
>>> For patches 1-7:
>>>
>>> Reviewed-by: Keith Packard 
>>
>> Dave, ack to merge them through drm-intel-next-queued ?
>
> Ack. do we know if any of those need to be in -fixes?

All patches merged to drm-intel-next-queued.
Thanks for the patches, reviews and acks.

>
> or too early to tell?
>
> Dave.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: mali-dp: Report underrun and axi bus errors

[Alexandru Gheorghe]

Errors will be reported in  /sys/kernel/debug/tracing/trace,
still not noisy enough, but better than silently ignoring them.
E.g:
-0 [000] d.h1   183.851864: malidp_de_irq: error occurred DE_STATUS 
is 0x0001
surfaceflinger-803   [000] d.h1   197.993003: malidp_de_irq: error occurred 
DE_STATUS is 0x0001
surfaceflinger-803   [000] d.h1   213.595119: malidp_de_irq: error occurred 
DE_STATUS is 0x0001
surfaceflinger-803   [000] d.h.   217.754371: malidp_de_irq: error occurred 
DE_STATUS is 0x0001
surfaceflinger-803   [000] d.h.   217.820848: malidp_de_irq: error occurred 
DE_STATUS is 0x0001
surfaceflinger-803   [000] d.h.   217.854034: malidp_de_irq: error occurred 
DE_STATUS is 0x0001

Signed-off-by: Alexandru Gheorghe 
---
 drivers/gpu/drm/arm/malidp_hw.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 2bfb542..8e7d49f 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -797,6 +797,9 @@ static irqreturn_t malidp_de_irq(int irq, void *arg)
if (status & de->vsync_irq)
drm_crtc_handle_vblank(>crtc);
 
+   if (status  & ~de->vsync_irq & de->irq_mask)
+   trace_printk("error occurred DE_STATUS is 0x%08X\n", status);
+
malidp_hw_clear_irq(hwdev, MALIDP_DE_BLOCK, status);
 
return (ret == IRQ_NONE) ? IRQ_HANDLED : ret;
@@ -880,6 +883,9 @@ static irqreturn_t malidp_se_irq(int irq, void *arg)
status &= mask;
/* ToDo: status decoding and firing up of VSYNC and page flip events */
 
+   if (status & ~se->vsync_irq & se->irq_mask)
+   trace_printk("error occurred SE_STATUS is 0x%08X\n", status);
+
malidp_hw_clear_irq(hwdev, MALIDP_SE_BLOCK, status);
 
return IRQ_HANDLED;
-- 
2.7.4

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

Re: [PATCH 04/10] drm: Add Plane Gamma properties

[Harry Wentland]

On 2018-02-15 12:32 AM, Daniele Castagna wrote:
> From: "uma.shankar at intel.com (Uma Shankar)" 
> 
> Add plane gamma as blob property and size as a
> range property.
> 

Plane degamma & CTM make sense to me but I'm not sure why gamma would be on a 
per-plane basis. That said, HW sometimes has these implemented in odd ways. Do 
we know of any HW that will currently or in the future need per-plane gamma or 
are we just trying to cover all potentialities?

Harry

> (am from https://patchwork.kernel.org/patch/9971325/)
> 
> Change-Id: I606cd40c9748b136fc2bf4750bea1da285add62d
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/drm_atomic.c|  8 
>  drivers/gpu/drm/drm_atomic_helper.c |  4 
>  drivers/gpu/drm/drm_mode_config.c   | 14 ++
>  include/drm/drm_mode_config.h   | 11 +++
>  include/drm/drm_plane.h |  9 +
>  5 files changed, 46 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d4b8c6cc84128..f634f6450f415 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -778,6 +778,12 @@ static int drm_atomic_plane_set_property(struct 
> drm_plane *plane,
>   );
>   state->color_mgmt_changed |= replaced;
>   return ret;
> + } else if (property == config->plane_gamma_lut_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + >gamma_lut,
> + val, -1, );
> + state->color_mgmt_changed |= replaced;
> + return ret;
>   } else {
>   return -EINVAL;
>   }
> @@ -841,6 +847,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   state->degamma_lut->base.id : 0;
>   } else if (property == config->plane_ctm_property) {
>   *val = (state->ctm) ? state->ctm->base.id : 0;
> + } else if (property == config->plane_gamma_lut_property) {
> + *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
>   } else {
>   return -EINVAL;
>   }
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 17e137a529a0e..97dbb36153d14 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3495,6 +3495,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
> drm_plane *plane,
>   drm_property_reference_blob(state->degamma_lut);
>   if (state->ctm)
>   drm_property_reference_blob(state->ctm);
> + if (state->gamma_lut)
> + drm_property_reference_blob(state->gamma_lut);
> +
>   state->color_mgmt_changed = false;
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> @@ -3543,6 +3546,7 @@ void __drm_atomic_helper_plane_destroy_state(struct 
> drm_plane_state *state)
>  
>   drm_property_unreference_blob(state->degamma_lut);
>   drm_property_unreference_blob(state->ctm);
> + drm_property_unreference_blob(state->gamma_lut);
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>  
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index c8763977413e7..bc6f8e51c7464 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -368,6 +368,20 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.plane_ctm_property = prop;
>  
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB,
> + "PLANE_GAMMA_LUT", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.plane_gamma_lut_property = prop;
> +
> + prop = drm_property_create_range(dev,
> + DRM_MODE_PROP_IMMUTABLE,
> + "PLANE_GAMMA_LUT_SIZE", 0, UINT_MAX);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.plane_gamma_lut_size_property = prop;
> +
>   return 0;
>  }
>  
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ad7235ced531b..3ca3eb3c98950 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -740,6 +740,17 @@ struct drm_mode_config {
>* degamma LUT.
>*/
>   struct drm_property *plane_ctm_property;
> + /**
> +  * @plane_gamma_lut_property: Optional Plane property to set the LUT
> +  * used to convert the colors, after the CTM matrix, to the common
> +  * gamma space chosen for blending.
> +  */
> + struct drm_property *plane_gamma_lut_property;
> + /**
> +  * @plane_gamma_lut_size_property: Optional Plane property for the size
> +  * of the gamma LUT as supported by the driver (read-only).
> +  */
> + struct drm_property 

[PATCH] gpu: ipu-v3: pre: fix device node leak in ipu_pre_lookup_by_phandle

[Tobias Jordan]

Before returning, call of_node_put() for the device node returned by
of_parse_phandle().

Fixes: d2a34232580a ("gpu: ipu-v3: add driver for Prefetch Resolve Engine")
Signed-off-by: Tobias Jordan 
---
 drivers/gpu/ipu-v3/ipu-pre.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c
index f1cec3d70498..0f70e8847540 100644
--- a/drivers/gpu/ipu-v3/ipu-pre.c
+++ b/drivers/gpu/ipu-v3/ipu-pre.c
@@ -129,11 +129,14 @@ ipu_pre_lookup_by_phandle(struct device *dev, const char 
*name, int index)
if (pre_node == pre->dev->of_node) {
mutex_unlock(_pre_list_mutex);
device_link_add(dev, pre->dev, DL_FLAG_AUTOREMOVE);
+   of_node_put(pre_node);
return pre;
}
}
mutex_unlock(_pre_list_mutex);
 
+   of_node_put(pre_node);
+
return NULL;
 }
 
-- 
2.11.0

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

Re: [PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

[Gustavo A. R. Silva]

Hi Oded,

On 02/15/2018 04:08 AM, Oded Gabbay wrote:

Hi Gustavo,
The patch is queued for the merge window of kernel 4.17 (opens in
about 7 weeks from now).



Awesome.

Thanks for the info.
--
Gustavo


Oded

On Wed, Feb 14, 2018 at 11:30 PM, Gustavo A. R. Silva
 wrote:

Hi all,

I was just wondering about the status of this patch.

Thanks
--
Gustavo


On 01/19/2018 04:18 PM, Felix Kuehling wrote:


Looks good. This change is Reviewed-by: Felix Kuehling


Regards,
Felix


On 2018-01-18 07:39 PM, Gustavo A. R. Silva wrote:


Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
   drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index c6a7609..7783250 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -677,7 +677,7 @@ static int kfd_build_sysfs_node_entry(struct
kfd_topology_device *dev,
 }
 /* All hardware blocks have the same number of attributes. */
-   num_attrs = sizeof(perf_attr_iommu)/sizeof(struct kfd_perf_attr);
+   num_attrs = ARRAY_SIZE(perf_attr_iommu);
 list_for_each_entry(perf, >perf_props, list) {
 perf->attr_group = kzalloc(sizeof(struct kfd_perf_attr)
 * num_attrs + sizeof(struct attribute_group),







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

[PATCH] gpu: ipu-v3: prg: fix device node leak in ipu_prg_lookup_by_phandle

[Tobias Jordan]

Before returning, call of_node_put() for the device node returned by
of_parse_phandle().

Fixes: ea9c260514c1 ("gpu: ipu-v3: add driver for Prefetch Resolve Gasket")
Signed-off-by: Tobias Jordan 
---
 drivers/gpu/ipu-v3/ipu-prg.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index 067365c733c6..97b99500153d 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -102,11 +102,14 @@ ipu_prg_lookup_by_phandle(struct device *dev, const char 
*name, int ipu_id)
mutex_unlock(_prg_list_mutex);
device_link_add(dev, prg->dev, DL_FLAG_AUTOREMOVE);
prg->id = ipu_id;
+   of_node_put(prg_node);
return prg;
}
}
mutex_unlock(_prg_list_mutex);
 
+   of_node_put(prg_node);
+
return NULL;
 }
 
-- 
2.11.0

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

Re: [PATCH] drm/i915/selftests: fix inconsistent IS_ERR and PTR_ERR

[Gustavo A. R. Silva]

On 02/15/2018 03:13 AM, Jani Nikula wrote:

On Wed, 14 Feb 2018, "Gustavo A. R. Silva"  wrote:

Fix inconsistent IS_ERR and PTR_ERR in shrink_boom.
The proper pointer to use is _explode_ instead of _purge_.

This issue was detected with the help of Coccinelle.

Fixes: fe215c8bc426 ("drm/i915/selftests: add missing gtt shrinker test")
Signed-off-by: Gustavo A. R. Silva 


Reviewed-by: Jani Nikula 

(Having some issues with fdo connections, thus not pushing.)



Thanks, Jani
--
Gustavo


---
  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index d806427..89b6ca9 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -927,7 +927,7 @@ static int shrink_boom(struct drm_i915_private *i915,
  
  		explode = fake_dma_object(i915, size);

if (IS_ERR(explode)) {
-   err = PTR_ERR(purge);
+   err = PTR_ERR(explode);
goto err_purge;
}



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

Re: [PATCH] drm/amdgpu_gem: fix error handling path in amdgpu_gem_va_update_vm

[Gustavo A. R. Silva]

On 02/15/2018 06:32 AM, Christian König wrote:

Am 15.02.2018 um 06:20 schrieb Gustavo A. R. Silva:

Currently, if amdgpu_vm_bo_update() fails, the returned error
is being ignored.

Fix this by properly checking _r_ after calling amdgpu_vm_bo_update.
Also, remove redundant code just before label _error_.

Addresses-Coverity-ID: 1464280 ("Unused value")
Fixes: 0abc6878fc2d ("drm/amdgpu: update VM PDs after the PTs")
Signed-off-by: Gustavo A. R. Silva 


Reviewed-by: Christian König 



Thanks, Christian
--
Gustavo


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c

index e48b4ec..db85fc0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -523,12 +523,13 @@ static void amdgpu_gem_va_update_vm(struct 
amdgpu_device *adev,

  goto error;
  if (operation == AMDGPU_VA_OP_MAP ||
-    operation == AMDGPU_VA_OP_REPLACE)
+    operation == AMDGPU_VA_OP_REPLACE) {
  r = amdgpu_vm_bo_update(adev, bo_va, false);
+    if (r)
+    goto error;
+    }
  r = amdgpu_vm_update_directories(adev, vm);
-    if (r)
-    goto error;
  error:
  if (r && r != -ERESTARTSYS)




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

Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

[Giulio Benetti]

Hi,

Il 08/02/2018 21:40, Maxime Ripard ha scritto:

On Wed, Feb 07, 2018 at 01:49:59PM +0100, Giulio Benetti wrote:

Hi,

Il 07/02/2018 11:39, Maxime Ripard ha scritto:

On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote:

Also, how was it tested? This seems quite weird that we haven't caught
that one sooner, and I'm a bit worried about the possible regressions
here.


It sounds really strange to me too,
because everybody under uboot use "sync:3"(HIGH).
I will retry to measure,
unfortunately at home I don't have a scope,
but I think I'm going to have one soon, because of this. :)


Here I am with scope captures and tcon0 registers dump:
tcon0_regs => https://pasteboard.co/H4r8Zcs.png
dclk_d0 => https://pasteboard.co/H4r8QRe.png
dclk_de => https://pasteboard.co/H4r8zh4R.png
dclk_vsnc => https://pasteboard.co/H4r8Hye.png

As you can see circled in reg on registers,
TCON0_IO_POL_REG = 0x.
But on all the waveforms you can see:
- dclk_d0: clock phase is 0, but it starts with falling edge, otherwise
the rising front overlaps dclk rising edge(not good), so to me this is
falling, then I mean it Negative.
- dclk_de: de pulse is clearly negative, even if register is 0 and its'
polarity bit is 0.
- dclk_vsnc: same as dclk_de
- dclk_hsync: I didn't take scope screenshot but I can assure you it's
negative.

You can also check all the other registers about TCON0.

Now I proceed testing it on A33, maybe the peripheral is slightly
different between Axx SoCs, if I find it that way,
it should be only a check about SoC or peripheral ID,
and treat polarity as it should be done.


Here I am with A33 waveforms:
tcon0_regs => https://pasteboard.co/H4rXfN0M.png
dclk_d0 => https://pasteboard.co/H4rVXwy.png
dclk_de => https://pasteboard.co/H4rWDt8.png
dclk_vsnc => https://pasteboard.co/H4rWRACu.png
dclk_hsync => https://pasteboard.co/H4rWK6I.png

It behaves the same way as A20, so as I mean IO polarity,
all signals(except D0-D23), are inverted.
For A33 I've used A33-OLinuXino.
For A20 our LiNova1.


If you have an A33 handy, you probably want to read that mail:
https://lists.freedesktop.org/archives/dri-devel/2017-July/147951.html

Especially the 90-phase part.


Here is a summary of different SoCs TCON:
With DCLK_Sel:
0x0 => normal phase
0x1 => 1/3 phase
0x2 => 2/3 phase

A10, A20


Have you tested the option 4 and 5 there too?


With DCLK_Sel:
0x0 => normal phase
0x1 => 1/3 phase
0x2 => 2/3 phase
0x5 => DCLK/2 phase 0
0x4 => DCLK/2 phase 90

A31, A31s, A33, A80, A83T


Ok, great, so Chen-Yu was right :)

I guess the option 5 (DCLK/2 phase 0) is still to early, just like
you've shown in the previous captures?


Exactly, it is like this:
https://pasteboard.co/H4r8QRe.png but with clock divided by 2.




Also I've found that TCON1 has not this feature,
nor first, nor second case(at least is not described on user manuals).


At lot of things are not described, unfortunately...


So I could handle differently according to SoC.
Unfortunately there is not TCON register keeping IP version,
so the only way I see is to create a long if-or statement to understand
which kind of TCON we're using.


You can base that on the compatible, and add a field in the
sun4i_tcon_quirks structure, that will avoid the if statements you
mentionned.


But what sounds not the best to me, is that DCLK is divided by 2 if
using phase 90. So we need to reconsider also bitclock driver according
to this.
I don't know if it make sense.

IMHO, I would keep only:
- As normal => "0x1 => 1/3 phase"


So that would mean sampling at raising edge on this one??


Exactly rising edge.




- As inverted => "0x0 => normal phase"


And falling edge?


Yes.



If so, and if remember the captures properly, the sampling would occur
right before the rise, and not really around the fall.

Would 2/3 be better here?


Yes, you're right, 2/3 phase is better:

1/3 phase: https://pasteboard.co/H4VehON.png
2/3 phase: https://pasteboard.co/H4Veq8a.png

Take a look at the bit in middle(yellow) sampled by clock(blue).

Rising edge is almost in the middle of D0 bit.




According to scope captures above on both A20 and A33.
Unfortunately I don't have other boards for the other SoCs to take captures.

What do you think?


I guess we can make that part applicable to all SoCs, we haven't seen
any significant differences on those part.


So let's keep:
- As normal(rising edge) => IO_POL_REG "0x2 => 2/3 phase"
- As inverted(falling edge) => IO_POL_REG "0x0 => normal phase"

Ok?



Maxime




--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/sun4i: fix HSYNC and VSYNC polarity

[Giulio Benetti]

Differently from other Lcd signals, HSYNC and VSYNC signals
result inverted if their bits are cleared to 0.

Invert their settings of IO_POL register.

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

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 3c15cf2..aaf911a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
 SUN4I_TCON0_BASIC3_H_SYNC(hsync));
 
/* Setup the polarity of the various signals */
-   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
 
-   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
 
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
-- 
2.7.4

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

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Keith Packard]

Jason Ekstrand  writes:

> It seems a little odd to me to default to opening the master node and then
> fall back to the render node if it doesn't work.  I suppose that's probably
> ok so long as we ensure that vkGetPhysicalDeviceDisplayPropertiesKHR
> returns no displays if we're on the render node.
>
> We could always go back to the DRM fd extension idea but I'm not coming up
> with something nice and clean in the 60 seconds I've thought about it.

As I said in the last comments about this section, Dave Airlie and I
added this code only recently so that we could test this extension
without also needing the kernel and X leasing changes.

I think we should decide how to enable this functionality "for real",
and I have two easy options:

 1) Use my KEITHP_kms_display extension (presumably renamed MESA), which
exposes a way to pass the DRM fd from the application into the
driver. This makes it possible for the application to get the FD
through any mechanism at all (including RandR or the new Wayland
extension) and leave that out of the Vulkan code entirely.

 2) Add a new extension which passes a new data structure that directs
the driver to open either the Render or Primary nodes.

When this is done, we can switch from the current code which tries to
open the Primary node whenever the KHR_display extension is requested.

> Would it make anything easier if we just storred the DRM struct here?  "No"
> is a perfectly valid answer.

Nope -- once we add the acquire_xlib extension, we get modes through
either X or DRM, depending on whether we're pre-lease or post-lease.

> Any particular reason why the list of modes is global and not in the
> connector?  It seems like it would be a tiny bit more efficient and
> convenient to put the list in the connector.

I think you're right. I have some vague memory of a lifetime issue with
connectors, but can't think of what it might be, even after reviewing
the relevant parts of the Vulkan spec. I've gone ahead and changed it;
seems to work fine.

>> +   LIST_FOR_EACH_ENTRY(display_mode, >display_modes, list)
>> +  if (display_mode->connector == connector)
>> + display_mode->valid = false;
>>
>
> Please use braces for loops containing more than one line.

Well, that was easy to fix -- the condition is now gone :-)

> Since we're allocating these in a physical device query, we need to use the
> INSTANCE scope.  the OBJECT scope is intended for vkCreate functions to
> allocated data that will live no longer than the associated vkDestroy
> function.

Thanks! The whole Vulkan memory model remains a mystery to me.

I've changed allocation of wsi_display_mode and wsi_display_connector to
use SCOPE_INSTANCE. VkIceSurfaceDisplay, wsi_display_fence and
wsi_display_swapchain remain using SCOPE_OBJECT.

I've also changed *all* instances of vk_alloc to use
vk_zalloc. These are all small data structures allocated only during
application startup, so I think the benefit of known memory contents is
worth the cost of memset.

> Hooray for obviously false fixed constants!
>
> I know the answer to this will be "EDIDs lie, never trust them!" but can we
> get the real value somehow?  As someone who has a 13" laptop with a
> 3200x1800 display, I know that number isn't always right. :-)

Yes, we could dig the real value out of the EDID, but we'd have to parse
the entire EDID to manage that. I don't want to stick an EDID parser
directly in Mesa, so I'm kinda waiting for someone to create a separate
EDID parsing library that the X server, Mesa and others can share. Until
then, I'd prefer to just lie here.

> double-;;

Thx. I remember seeing this while reviewing patches and forgot all about
it...

> From the Vulkan spec:
>
> Note:
> For devices which have no natural value to return here, implementations
> *should* return the maximum resolution supported.
>
> We should walk the list and pick the biggest one.

I did this intentionally -- most monitors have a preferred resolution,
which is their native pixel size. And, we want to tell applications to
use that size, even if the monitor offers a larger (presumabl scaled)
resolution in their mode list.

> See question about MM_PER_PIXEL above

Yeah, see response about not boiling the EDID ocean above ;-)

> I know i915 can do better at least in some cases.  Is there a practical way
> to expose this?  If not, I'm fine with just exposing IDENTITY.

I'm not seeing this exposed through the common DRM mode interfaces
yet. We should probably consider adding this to the kernel and then
adding it here.

> This error is not allowed for this function.  We should just write 0 to
> property_count and return VK_SUCCESS.  Maybe add some asserts for debug
> builds if you really think this shouldn't ever happen.

I bet it will happen if you VT switch away and then try this function.

I've added this at the end of the function:

bail:
   *property_count = 0;
   return VK_SUCCESS;

> 

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Robin Murphy]

On 15/02/18 04:17, Tomasz Figa wrote:
[...]

Could you elaborate on what kind of locking you are concerned about?
As I explained before, the normally happening fast path would lock
dev->power_lock only for the brief moment of incrementing the runtime
PM usage counter.


My bad, that's not even it.

The atomic usage counter is incremented beforehands, without any
locking [1] and the spinlock is acquired only for the sake of
validating that device's runtime PM state remained valid indeed [2],
which would be the case in the fast path of the same driver doing two
mappings in parallel, with the master powered on (and so the SMMU,
through device links; if master was not powered on already, powering
on the SMMU is unavoidable anyway and it would add much more latency
than the spinlock itself).


We now have no locking at all in the map path, and only a per-domain 
lock around TLB sync in unmap which is unfortunately necessary for 
correctness; the latter isn't too terrible, since in "serious" hardware 
it should only be serialising a few cpus serving the same device against 
each other (e.g. for multiple queues on a single NIC).


Putting in a global lock which serialises *all* concurrent map and unmap 
calls for *all* unrelated devices makes things worse. Period. Even if 
the lock itself were held for the minimum possible time, i.e. trivially 
"spin_lock(); spin_unlock()", the cost of repeatedly bouncing 
that one cache line around between 96 CPUs across two sockets is not 
negligible.



[1] 
http://elixir.free-electrons.com/linux/v4.16-rc1/source/drivers/base/power/runtime.c#L1028
[2] 
http://elixir.free-electrons.com/linux/v4.16-rc1/source/drivers/base/power/runtime.c#L613

In any case, I can't imagine this working with V4L2 or anything else
relying on any memory management more generic than calling IOMMU API
directly from the driver, with the IOMMU device having runtime PM
enabled, but without managing the runtime PM from the IOMMU driver's
callbacks that need access to the hardware. As I mentioned before,
only the IOMMU driver knows when exactly the real hardware access
needs to be done (e.g. Rockchip/Exynos don't need to do that for
map/unmap if the power is down, but some implementations of SMMU with
TLB powered separately might need to do so).


It's worth noting that Exynos and Rockchip are relatively small 
self-contained IP blocks integrated closely with the interfaces of their 
relevant master devices; SMMU is an architecture, implementations of 
which may be large, distributed, and have complex and wildly differing 
internal topologies. As such, it's a lot harder to make 
hardware-specific assumptions and/or be correct for all possible cases.


Don't get me wrong, I do ultimately agree that the IOMMU driver is the 
only agent who ultimately knows what calls are going to be necessary for 
whatever operation it's performing on its own hardware*; it's just that 
for SMMU it needs to be implemented in a way that has zero impact on the 
cases where it doesn't matter, because it's not viable to specialise 
that driver for any particular IP implementation/use-case.


Robin.


*AFAICS it still makes some sense to have the get_suppliers option as 
well, though - the IOMMU driver does what it needs for correctness 
internally, but the external consumer doing something non-standard can 
can grab and hold the link around multiple calls to short-circuit that.

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

Re: [PATCH] drm/doc: nerved -> nerfed in drm_ioctl.c

[Daniel Stone]

Hi Harry,

On 15 February 2018 at 16:28, Harry Wentland  wrote:
> This threw me for a loop when I read the docs. I imagine this is the
> intended definition:
> http://www.dictionary.com/browse/nerf

Yeah. I'm quite sure it was intended to be 'nerfed', but replacing it
with something more clear (and especially more accessible to
non-native speakers) would be great if you could do that instead
please. :)

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

Re: [PATCH] drm/i915/selftests: fix inconsistent IS_ERR and PTR_ERR

[Chris Wilson]

Quoting Gustavo A. R. Silva (2018-02-15 16:09:09)
> 
> 
> On 02/15/2018 03:13 AM, Jani Nikula wrote:
> > On Wed, 14 Feb 2018, "Gustavo A. R. Silva"  wrote:
> >> Fix inconsistent IS_ERR and PTR_ERR in shrink_boom.
> >> The proper pointer to use is _explode_ instead of _purge_.
> >>
> >> This issue was detected with the help of Coccinelle.
> >>
> >> Fixes: fe215c8bc426 ("drm/i915/selftests: add missing gtt shrinker test")
> >> Signed-off-by: Gustavo A. R. Silva 
> > 
> > Reviewed-by: Jani Nikula 
> > 
> > (Having some issues with fdo connections, thus not pushing.)
> >
> 
> Thanks, Jani

And pushed, thanks for the patch and review.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/doc: nerved -> nerfed in drm_ioctl.c

[Harry Wentland]

This threw me for a loop when I read the docs. I imagine this is the
intended definition:
http://www.dictionary.com/browse/nerf

Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/drm_ioctl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 4aafe4802099..82b7ce6c99c2 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -51,15 +51,15 @@
  *  - GET_UNIQUE ioctl, implemented by drm_getunique is wrapped up in libdrm
  *through the drmGetBusid function.
  *  - The libdrm drmSetBusid function is backed by the SET_UNIQUE ioctl. All
- *that code is nerved in the kernel with drm_invalid_op().
+ *that code is nerfed in the kernel with drm_invalid_op().
  *  - The internal set_busid kernel functions and driver callbacks are
  *exclusively use by the SET_VERSION ioctl, because only drm 1.0 (which is
- *nerved) allowed userspace to set the busid through the above ioctl.
+ *nerfed) allowed userspace to set the busid through the above ioctl.
  *  - Other ioctls and functions involved are named consistently.
  *
  * For anyone wondering what's the difference between drm 1.1 and 1.4: 
Correctly
  * handling pci domains in the busid on ppc. Doing this correctly was only
- * implemented in libdrm in 2010, hence can't be nerved yet. No one knows 
what's
+ * implemented in libdrm in 2010, hence can't be nerfed yet. No one knows 
what's
  * special with drm 1.2 and 1.3.
  *
  * Now the actual horror story of how device lookup in drm works. At large,
-- 
2.14.1

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

[Bug 105113] [hawaii, radeonsi, clover] Running Piglit cl/program/execute/{, tail-}calls{, -struct, -workitem-id}.cl cause GPU VM error and ring stalled GPU lockup

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 CC||arse...@gmail.com
Summary|[hawaii] Running Piglit |[hawaii, radeonsi, clover]
   |cl/program/execute/calls-st |Running Piglit
   |ruct.cl causes GPU VM error |cl/program/execute/{,tail-}
   |and ring stalled GPU lockup |calls{,-struct,-workitem-id
   ||}.cl cause GPU VM error and
   ||ring stalled GPU lockup
   Priority|medium  |high

-- 
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 105113] [hawaii] Running Piglit cl/program/execute/calls-struct.cl causes GPU VM error and ring stalled GPU lockup

[bugzilla-daemon]

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

--- Comment #1 from Vedran Miletić  ---
Same story with

tests/cl/program/execute/calls-struct.cl
tests/cl/program/execute/calls-workitem-id.cl
tests/cl/program/execute/calls.cl
tests/cl/program/execute/tail-calls.cl

while

tests/cl/program/execute/call-clobbers-amdgcn.cl

gets skipped. All those test were added in
e408ce1f2bff23121670a8206258c80bb3d9befd.

-- 
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 libdrm 0/4] gralloc handle fixes

[Robert Foss]

Hey Rob,

Thanks for ironing out the kinks, and the new helper.
If you need reviews for any of the related changes, CC me.

This all looks good to me. Feel free to add my r-b.


Rob.

On 02/15/2018 02:59 PM, Rob Herring wrote:

The recently committed gralloc handle definition has a few issues like
not actually compiling. This series fixes those issues. I now have
things working with these fixes and switching mesa, gbm_gralloc, and
drm_hwcomposer to use this header.

Rob

Rob Herring (4):
   android: revert making handle magic and version members const
   android: fix mis-named alloc_handle_t
   android: add helper to convert buffer_handle_t to gralloc_handle_t ptr
   android: fix gralloc_handle_create() problems

  android/gralloc_handle.h | 43 +++
  1 file changed, 23 insertions(+), 20 deletions(-)


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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Tomeu Vizoso]

On 02/12/2018 12:45 PM, Gerd Hoffmann wrote: 4. QEMU pops 
data+buffers from the virtqueue, looks up shmem FD for each

 resource, sends data + FDs to the compositor with SCM_RIGHTS
>>>
>>> BTW: Is there a 1:1 relationship between buffers and shmem blocks?  Or
>>> does the wayland protocol allow for offsets in buffer meta data, so you
>>> can place multiple buffers in a single shmem block?
>>
>> The latter:
>> 
https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_shm_pool

>
> Ah, good, that makes it alot easier.
>
> So, yes, using ivshmem would be one option.  Tricky part here is the
> buffer management though.  It's just a raw piece of memory.  The guest
> proxy could mmap the pci bar and manage it.  But then it is again either
> unmodified guest + copying the data, or modified client (which requests
> buffers from guest proxy) for zero-copy.

What if at VIRTIO_GPU_CMD_RESOURCE_CREATE_2D time we created a ivshmem 
device to back that resource. The ivshmem device would in turn be backed 
by a hostmem device that wraps a shmem FD.


The guest client can then export that resource/BO and pass the FD to the 
guest proxy. The guest proxy would import it and put the resource_id in 
the equivalent message in our protocol extension.


QEMU would get that resource id from vsock, look up which hostmem device 
is associated with that resource, and pass its FD to the compositor.


> We also need a solution for the keymap shmem block.  I guess the keymap
> doesn't change all that often, so maybe it is easiest to just copy it
> over (host proxy -> guest proxy) instead of trying to map the host shmem
> into the guest?

Not sure if that would be much simpler than creating a ivshmem+hostmem 
combo that wraps the incoming shmem FD and then having virtio-gpu create 
a BO that imports it.


Regards,

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

Re: [RFC PATCH v2 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

On 15.02.2018 13:14, Krzysztof Kozlowski wrote:
> On Thu, Feb 15, 2018 at 11:39 AM, Andrzej Hajda  wrote:
>> OF graph describes MHL data lanes between MHL and respective USB
>> connector.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 
>> +++---
>>  1 file changed, 28 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> index 7e49fadee412..ef758f7337e9 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> @@ -779,9 +779,22 @@
>> clocks = <_system_controller 0>;
>> clock-names = "xtal";
>>
>> -   port {
>> -   mhl_to_hdmi: endpoint {
>> -   remote-endpoint = <_to_mhl>;
>> +   ports {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   port@0 {
>> +   reg = <0>;
>> +   mhl_to_hdmi: endpoint {
>> +   remote-endpoint = <_to_mhl>;
>> +   };
>> +   };
>> +
>> +   port@1 {
>> +   reg = <1>;
>> +   mhl_to_musb_con: endpoint {
>> +   remote-endpoint = <_con_to_mhl>;
>> +   };
>> };
>> };
>> };
>> @@ -804,6 +817,18 @@
>>  "usb-b-connector";
>> label = "micro-USB";
>> type = "micro";
>> +
>> +   ports {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   port@3 {
> I think you might need here "reg = <3>". Doesn't it produce a warning now?

You are right, I will fix it. Warning is produced only if compiled with W=1.

Regards
Andrzej

>
> BR,
> Krzysztof
>
>> +   musb_con_to_mhl: endpoint {
>> +   remote-endpoint = 
>> <_to_musb_con>;
>> +   };
>> +   };
>> +   };
>> +   };
>> };
>> };
>>
>> --
>> 2.16.1
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>

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

[Bug 105113] [hawaii] Running Piglit cl/program/execute/calls-struct.cl causes GPU VM error and ring stalled GPU lockup

[bugzilla-daemon]

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

Bug ID: 105113
   Summary: [hawaii] Running Piglit
cl/program/execute/calls-struct.cl causes GPU VM error
and ring stalled GPU lockup
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ved...@miletic.net
QA Contact: dri-devel@lists.freedesktop.org

On kernel 4.16.0-0.rc1.git0.1.fc28.x86_64, with 01:00.0 VGA compatible
controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii XT GL [FirePro W9100]
upon running Piglit's cl/program/execute/calls-struct.cl test I get:

[ 1574.837119] radeon :01:00.0: GPU fault detected: 147 0x080a8401
[ 1574.837124] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00400840
[ 1574.837126] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0A084001
[ 1574.837128] VM fault (0x01, vmid 5) at page 4196416, read from 'TC5'
(0x54433500) (132)
[ 1585.420894] radeon :01:00.0: ring 0 stalled for more than 10080msec
[ 1585.420901] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1585.924885] radeon :01:00.0: ring 0 stalled for more than 10584msec
[ 1585.924892] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1586.428890] radeon :01:00.0: ring 0 stalled for more than 11088msec
[ 1586.428897] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1586.932902] radeon :01:00.0: ring 0 stalled for more than 11592msec
[ 1586.932911] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1587.436903] radeon :01:00.0: ring 0 stalled for more than 12096msec
[ 1587.436909] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1587.940855] radeon :01:00.0: ring 0 stalled for more than 12600msec
[ 1587.940859] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1588.444913] radeon :01:00.0: ring 0 stalled for more than 13104msec
[ 1588.444922] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1588.948909] radeon :01:00.0: ring 0 stalled for more than 13608msec
[ 1588.948918] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1589.452909] radeon :01:00.0: ring 0 stalled for more than 14112msec
[ 1589.452916] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1589.956912] radeon :01:00.0: ring 0 stalled for more than 14616msec
[ 1589.956920] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1590.460913] radeon :01:00.0: ring 0 stalled for more than 15120msec
[ 1590.460920] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1590.964927] radeon :01:00.0: ring 0 stalled for more than 15624msec
[ 1590.964934] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1591.468898] radeon :01:00.0: ring 0 stalled for more than 16128msec
[ 1591.468905] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1591.972882] radeon :01:00.0: ring 0 stalled for more than 16632msec
[ 1591.972887] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1592.476903] radeon :01:00.0: ring 0 stalled for more than 17136msec
[ 1592.476908] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1592.980928] radeon :01:00.0: ring 0 stalled for more than 17640msec
[ 1592.980936] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1593.484931] radeon :01:00.0: ring 0 stalled for more than 18144msec
[ 1593.484939] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1593.988933] radeon :01:00.0: ring 0 stalled for more than 18648msec
[ 1593.988941] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 0x002c on ring 0)
[ 1594.492935] radeon :01:00.0: ring 0 stalled for more than 19152msec
[ 1594.492943] radeon :01:00.0: GPU lockup (current fence id
0x002b last fence id 

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

Bong Cosca  changed:

   What|Removed |Added

Product|DRI |Mesa
  Component|DRM/Radeon  |Drivers/Gallium/radeonsi
 QA Contact||dri-devel@lists.freedesktop
   ||.org

-- 
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 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #30 from Bong Cosca  ---
Created attachment 137374
  --> https://bugs.freedesktop.org/attachment.cgi?id=137374=edit
Gnome desktop

The situation has improved somehow - but screen is still unusable. I tried to
patch si_state.c with:

/* KV should be 0x0002, but that causes problems with radeon */
raster_config = 0x0002; /* 0x0002 */

How do I remove the checkerboard pattern overlay? And why is 0x the
default value? This appears to be just a workaround to a greater underlying
problem that needs to be fixed.

-- 
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: Question about lima kernel MM implementation

[Liviu Dudau]

On Tue, Feb 13, 2018 at 09:34:26PM +0800, Qiang Yu wrote:
> Hi guys,
> 
> I'm working on the Lima project for ARM mali400/450 GPU. Now lima
> kernel driver uses CMA for all buffers, but mali400/450 GPU has MMU
> for each vertex/fragment shader processor, so I want to refine the lima
> kernel driver for non-contiguous memory support.
> 
> After some investigation on current available MM method used by
> several linux kernel DRM driver, I can't find an exactly match one for
> lima. So I'd like to hear some advise from you and see if I have some
> miss understanding on current MMs and if there's better approach.
> If can't use existing MM, I may have to write one for lima.
> 
> About Mali400/450 GPU:
> 1. it has separate vertex and fragment shader processors, 1 vertex
> processor and 1~4 fragment processors are grouped to process an
> OpenGL draw
> 2. each processor has an MMU work independently
> 3. Mali400/450 will work with different display DRM driver, some
> display DRM driver support non-contiguous framebuffer and some
> not
> 
> My requirement:
> 1. support non-contiguous memory allocation as GPU buffer
> 2. support contiguous memory allocation too for exporting to some
> display DRM driver as framebuffer
> 3. no GPU page fault for better performance and avoid multi MMU
> page fault handling, CPU page fault is OK
> 4. better have buffer swap to disk feature when memory is full
> 
> Current MM:
> 1. drm_gem_cma_object, only support contiguous memory

Please note that drm_gem_cma_object only looks at memory after the MMU
has done the mapping. If you have a good IOMMU driver that registers
correctly the dma_ops then you can allocate memory from anywhere and
still import it into the lima driver via drm_gem_cma_prime_import_sg_table()
hook attached to the gem_prime_import_sg_table.

> 2. drm_gem_get_pages
>   1) need to combine with cma method for contiguous memory
>   2) when shrink is needed, swap some idle buffer to disk and put
>   pages, need implement by myself
>   3) additional shmem layer introduced
> 3. TTM TTM_PL_SYSTEM only
>   1) no contiguous memory support
>   2) too complicated as we don't need other functions of TTM
>   3) need GPU page fault to populate memory?
>   4) no page pool for cached memory
> 
> My plan:
> 1. for contiguous memory allocation use dma_alloc_*
> 2. for non-contiguous memory allocation, use a page pool from
> alloc_page

You should probably try to figure out who is your primary memory allocator.
Most of the times you don't want the GPU driver to allocate the memory,
you want that to come from a library that takes into account all the
constraints of the devices in the chain (GPU + display driver). There is
more to memory allocation for GPU than contiguous memory (alignment,
buffer encoding, etc).

Best regards,
Liviu

> 3. buffer is not really allocated when GEM_CREATE, but in CPU
> page fault handler and task submit buffer validation which make
> sure no GPU page fault
> 4. in shrinker handler, free un-used page in the pool, if still not
> enough, swap some idle buffer to disk
> 
> 3&4 apply to both dma_alloc buffer and alloc_page buffer.
> 
> Thanks,
> Qiang

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


-- 
 /`\
/ : |
   _.._ | '/
 /`\| /
|  .-._ '-"` (
|_/   /   o  o\
  |  == () ==
   \   -- /   __
   / ---<_  |  
|___
  |  \\ \   |  I would like to fix the world but   |
  /
  | | \\__   \  |   no one gives me the source code.   |
 /
  / ; |.__)  /  |__|
 \
 (_/.-.   ; /__)
(_\
{ `|   \_/
 '-\   / |
| /  |
   /  \  '-.
   \__|-'
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/ttm: keep BOs reserved until end of eviction

[Christian König]

This avoids problems when BOs are evicted but directly moved back into
the domain from other threads.

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

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index fba40e22d088..568cf216b374 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -742,7 +742,8 @@ static bool ttm_bo_evict_swapout_allowable(struct 
ttm_buffer_object *bo,
 static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
   uint32_t mem_type,
   const struct ttm_place *place,
-  struct ttm_operation_ctx *ctx)
+  struct ttm_operation_ctx *ctx,
+  struct list_head *evicted)
 {
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = >man[mem_type];
@@ -792,17 +793,28 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
 
ret = ttm_bo_evict(bo, ctx);
if (locked) {
-   ttm_bo_unreserve(bo);
+   list_add_tail(>lru, evicted);
} else {
spin_lock(>lru_lock);
ttm_bo_add_to_lru(bo);
spin_unlock(>lru_lock);
+   kref_put(>list_kref, ttm_bo_release_list);
}
 
-   kref_put(>list_kref, ttm_bo_release_list);
return ret;
 }
 
+static void ttm_mem_evict_cleanup(struct list_head *evicted)
+{
+   struct ttm_buffer_object *bo, *tmp;
+
+   list_for_each_entry_safe(bo, tmp, evicted, lru) {
+   list_del_init(>lru);
+   ttm_bo_unreserve(bo);
+   kref_put(>list_kref, ttm_bo_release_list);
+   }
+}
+
 void ttm_bo_mem_put(struct ttm_buffer_object *bo, struct ttm_mem_reg *mem)
 {
struct ttm_mem_type_manager *man = >bdev->man[mem->mem_type];
@@ -852,20 +864,26 @@ static int ttm_bo_mem_force_space(struct 
ttm_buffer_object *bo,
 {
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_mem_type_manager *man = >man[mem_type];
+   struct list_head evicted;
int ret;
 
+   INIT_LIST_HEAD();
do {
ret = (*man->func->get_node)(man, bo, place, mem);
if (unlikely(ret != 0))
return ret;
if (mem->mm_node)
break;
-   ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
+   ret = ttm_mem_evict_first(bdev, mem_type, place, ctx, );
if (unlikely(ret != 0))
-   return ret;
+   goto error;
} while (1);
mem->mem_type = mem_type;
-   return ttm_bo_add_move_fence(bo, man, mem);
+   ret = ttm_bo_add_move_fence(bo, man, mem);
+
+error:
+   ttm_mem_evict_cleanup();
+   return ret;
 }
 
 static uint32_t ttm_bo_select_caching(struct ttm_mem_type_manager *man,
@@ -1345,6 +1363,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
struct ttm_operation_ctx ctx = { false, false };
struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_bo_global *glob = bdev->glob;
+   struct list_head evicted;
struct dma_fence *fence;
int ret;
unsigned i;
@@ -1352,18 +1371,20 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
/*
 * Can't use standard list traversal since we're unlocking.
 */
-
+   INIT_LIST_HEAD();
spin_lock(>lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(>lru[i])) {
spin_unlock(>lru_lock);
-   ret = ttm_mem_evict_first(bdev, mem_type, NULL, );
+   ret = ttm_mem_evict_first(bdev, mem_type, NULL, ,
+ );
if (ret)
return ret;
spin_lock(>lru_lock);
}
}
spin_unlock(>lru_lock);
+   ttm_mem_evict_cleanup();
 
spin_lock(>move_lock);
fence = dma_fence_get(man->move);
-- 
2.14.1

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

[PATCH 2/3] drm/ttm: handle already locked BOs during eviction and swapout.

[Christian König]

This solves the problem that when we swapout a BO from a domain we
sometimes couldn't make room for it because holding the lock blocks all
other BOs with this reservation object.

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

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index d90b1cf10b27..fba40e22d088 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -713,31 +713,30 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object 
*bo,
 EXPORT_SYMBOL(ttm_bo_eviction_valuable);
 
 /**
- * Check the target bo is allowable to be evicted or swapout, including cases:
- *
- * a. if share same reservation object with ctx->resv, have assumption
- * reservation objects should already be locked, so not lock again and
- * return true directly when either the opreation allow_reserved_eviction
- * or the target bo already is in delayed free list;
- *
- * b. Otherwise, trylock it.
+ * Check if the target bo is allowed to be evicted or swapedout.
  */
 static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
-   struct ttm_operation_ctx *ctx, bool *locked)
+  struct ttm_operation_ctx *ctx,
+  bool *locked)
 {
-   bool ret = false;
+   /* First check if we can lock it */
+   *locked = reservation_object_trylock(bo->resv);
+   if (*locked)
+   return true;
 
-   *locked = false;
+   /* Check if it's locked because it is part of the current operation */
if (bo->resv == ctx->resv) {
reservation_object_assert_held(bo->resv);
-   if (ctx->allow_reserved_eviction || !list_empty(>ddestroy))
-   ret = true;
-   } else {
-   *locked = reservation_object_trylock(bo->resv);
-   ret = *locked;
+   return ctx->allow_reserved_eviction ||
+   !list_empty(>ddestroy);
}
 
-   return ret;
+   /* Check if it's locked because it was already evicted */
+   if (ww_mutex_is_owned_by(>resv->lock, current, NULL))
+   return true;
+
+   /* Some other thread is using it, don't touch it */
+   return false;
 }
 
 static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-- 
2.14.1

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

[PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

[Christian König]

amdgpu needs to verify if userspace sends us valid addresses and the simplest
way of doing this is to check if the buffer object is locked with the ticket
of the current submission.

Clean up the access to the ww_mutex internals by providing a function
for this and extend the check to the thread owning the underlying mutex.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  3 ++-
 include/linux/ww_mutex.h   | 17 +
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index eaa3cb0c3ad1..4c04b560e358 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1594,7 +1594,8 @@ int amdgpu_cs_find_mapping(struct amdgpu_cs_parser 
*parser,
*map = mapping;
 
/* Double check that the BO is reserved by this CS */
-   if (READ_ONCE((*bo)->tbo.resv->lock.ctx) != >ticket)
+   if (!ww_mutex_is_owned_by(&(*bo)->tbo.resv->lock, current,
+ >ticket))
return -EINVAL;
 
if (!((*bo)->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS)) {
diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
index 39fda195bf78..dd580db289e8 100644
--- a/include/linux/ww_mutex.h
+++ b/include/linux/ww_mutex.h
@@ -358,4 +358,21 @@ static inline bool ww_mutex_is_locked(struct ww_mutex 
*lock)
return mutex_is_locked(>base);
 }
 
+/**
+ * ww_mutex_is_owned_by - is the w/w mutex locked by this task in that context
+ * @lock: the mutex to be queried
+ * @task: the task structure to check
+ * @ctx: the w/w acquire context to test
+ *
+ * Returns true if the mutex is locked in the context by the given task, false
+ * otherwise.
+ */
+static inline bool ww_mutex_is_owned_by(struct ww_mutex *lock,
+   struct task_struct *task,
+   struct ww_acquire_ctx *ctx)
+{
+   return likely(__mutex_owner(>base) == task) &&
+   READ_ONCE(lock->ctx) == ctx;
+}
+
 #endif
-- 
2.14.1

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

Re: [Freedreno] [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Rob Clark]

On Wed, Feb 14, 2018 at 11:09 PM, Tomasz Figa  wrote:
> On Thu, Feb 15, 2018 at 1:12 AM, Rob Clark  wrote:
>> On Wed, Feb 14, 2018 at 10:48 AM, Jordan Crouse  
>> wrote:
>>> On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote:

 - When submitting commands to the GPU, the GPU driver will
 pm_runtime_get_sync() on the GPU device, which will automatically do
 the same on all the linked suppliers, which would also include the
 SMMU itself. The role of device links here is exactly that the GPU
 driver doesn't have to care which other devices need to be brought up.
>>>
>>> This is true.  Assuming that the device link works correctly we would not 
>>> need
>>> to explicitly power the SMMU which makes my point entirely moot.
>>
>> Just to point out what motivated this patchset, the biggest problem is
>> iommu_unmap() because that can happen when GPU is not powered on (or
>> in the v4l2 case, because some other device dropped it's reference to
>> the dma-buf allowing it to be free'd).  Currently we pm get/put the
>> GPU device around unmap, but it is kinda silly to boot up the GPU just
>> to unmap a buffer.
>
> Note that in V4L2 both mapping and unmapping can happen completely
> without involving the driver. So AFAICT the approach being implemented
> by this patchset will not work, because there will be no one to power
> up the IOMMU before the operation. Moreover, there are platforms for
> which there is no reason to power up the IOMMU just for map/unmap,
> because the hardware state is lost anyway and the only real work
> needed is updating the page tables in memory. (I feel like this is
> actually true for most of the platforms in the wild, but this is based
> purely on the not so small number of platforms I worked with, haven't
> bothered looking for more general evidence.)
>

At least as far as drm/msm/adreno, I'm not terribly concerned about
other platforms that don't need to power up iommu.  It's not really
the same situation as a IP block that shows up in all different
vendor's SoCs.

But if you can convince Robin to go for get/put_sync() calls inside
the iommu driver, I'm fine with that approach too.  That is what I do
in qcom_iommu already.  But if not I'd like to at least solve this for
some platforms if we can't solve for all.

BR,
-R

>>
>> (Semi-related, I would also like to batch map/unmap's, I just haven't
>> gotten around to implementing it yet.. but that would be another case
>> where a single get_supplier()/put_supplier() outside of the iommu
>> would make sense instead of pm_get/put() inside the iommu driver's
>> ->unmap().)
>>
>> If you really dislike the get/put_supplier() approach, then perhaps we
>> need iommu_pm_get()/iommu_pm_put() operations that the iommu user
>> could use to accomplish the same thing?
>
> I'm afraid this wouldn't work for V4L2 either. And I still haven't
> been given any evidence that the approach I'm suggesting, which relies
> only on existing pieces of infrastructure and which worked for both
> Exynos and Rockchip, including V4L2, wouldn't work for SMMU and/or QC
> SoCs.
>
> Best regards,
> Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/8] dt-bindings: display: renesas, lvds: Add LVDS binding for D3

[Laurent Pinchart]

Hi Kieran,

On Thursday, 15 February 2018 10:45:33 EET Kieran Bingham wrote:
> On 15/02/18 08:38, Kieran Bingham wrote:
> > From: Kieran Bingham 
> > 
> > The D3 supports two LVDS channels. Extend the binding to support them.
> > 
> > Signed-off-by: Kieran Bingham 
> > ---
> > 
> >  Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt index
> > 79860f58a7ad..0dcf488b70df 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > 
> > @@ -14,6 +14,7 @@ Required properties:
> >  - compatible : Shall contain one of
> >- "renesas,lvds-r8a7795" for R8A7795 (R-Car H3) compatible LVDS
> >encoders
> >- "renesas,lvds-r8a7796" for R8A7796 (R-Car M3-W) compatible LVDS
> >encoders
> > +  - "renesas,lvds-r8a77995" for R8A77995 (R-Car D3) compatible LVDS
> > encoders
> 
> Hi Laurent,
> 
> Are we unable to have a generic lvds-gen3 here?
> 
> (Although to perhaps answer my own question I see that the D3/E3 have extra
> registers)
> 
> Also "lets pretend" that I intentionally separated out the LVDS updates to
> the rcar_lvds_of_table :)

We could for H3 and M3-W, but as you've noticed D3/E3 differ, and so does V3M.

> >  - reg: Base address and length for the memory-mapped registers
> >  - clocks: A phandle + clock-specifier pair for the functional clock

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 3/8] dt-bindings: display: renesas, lvds: Add LVDS binding for D3

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 15 February 2018 10:38:18 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The D3 supports two LVDS channels. Extend the binding to support them.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt index
> 79860f58a7ad..0dcf488b70df 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> @@ -14,6 +14,7 @@ Required properties:
>  - compatible : Shall contain one of
>- "renesas,lvds-r8a7795" for R8A7795 (R-Car H3) compatible LVDS encoders
>- "renesas,lvds-r8a7796" for R8A7796 (R-Car M3-W) compatible LVDS
> encoders
> +  - "renesas,lvds-r8a77995" for R8A77995 (R-Car D3) compatible
> LVDS encoders

This should be "renesas,r8a77995-lvds". I've already fixed the series you've 
based this patch on.

Apart from this,

Reviewed-by: Laurent Pinchart 

and taken in my tree with the compatible string fixed.

> 
>  - reg: Base address and length for the memory-mapped registers
>  - clocks: A phandle + clock-specifier pair for the functional clock


-- 
Regards,

Laurent Pinchart

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

[PATCH libdrm 3/4] android: add helper to convert buffer_handle_t to gralloc_handle_t ptr

[Rob Herring]

Clients frequently need to convert a buffer_handle_t (aka
native_handle_t *) to a gralloc_handle_t ptr. This is a simple cast, but
add an inline function to do the conversion.

Signed-off-by: Rob Herring 
---
 android/gralloc_handle.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/android/gralloc_handle.h b/android/gralloc_handle.h
index b0f5048cc6a1..43255ba539c2 100644
--- a/android/gralloc_handle.h
+++ b/android/gralloc_handle.h
@@ -76,6 +76,11 @@ struct gralloc_handle_t {
((sizeof(struct gralloc_handle_t) - 
sizeof(native_handle_t))/sizeof(int))   \
 - GRALLOC_HANDLE_NUM_FDS)
 
+static inline struct gralloc_handle_t *gralloc_handle(buffer_handle_t handle)
+{
+   return (struct gralloc_handle_t *)handle;
+}
+
 /**
  * Create a buffer handle.
  */
-- 
2.14.1

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

[PATCH libdrm 4/4] android: fix gralloc_handle_create() problems

[Rob Herring]

There's a number of problems with gralloc_handle_create starting with it
doesn't even compile. More importantly, it doesn't really create (i.e.
allocate) a handle. It allocates a native_handle_t, copies it to a
struct gralloc_handle_t on the stack and returns the struct (not a ptr).
So the caller still has to allocate a struct gralloc_handle_t to hold
the returned struct.

Rework gralloc_handle_create() to allocate a new handle and return the
pointer to the allocated handle. Callers should free the handle with
native_handle_close() and native_handle_delete().

Signed-off-by: Rob Herring 
---
 android/gralloc_handle.h | 32 +++-
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/android/gralloc_handle.h b/android/gralloc_handle.h
index 43255ba539c2..3177f7a1fd8f 100644
--- a/android/gralloc_handle.h
+++ b/android/gralloc_handle.h
@@ -84,28 +84,26 @@ static inline struct gralloc_handle_t 
*gralloc_handle(buffer_handle_t handle)
 /**
  * Create a buffer handle.
  */
-static struct gralloc_handle_t gralloc_handle_create(int32_t width,
+static inline struct gralloc_handle_t *gralloc_handle_create(int32_t width,
  int32_t height,
  int32_t format,
  int32_t usage)
 {
-   struct alloc_handle_t handle = {
-   .magic = GRALLOC_HANDLE_MAGIC,
-   .version = GRALLOC_HANDLE_VERSION };
-
+   struct gralloc_handle_t *handle;
native_handle_t *nhandle = native_handle_create(GRALLOC_HANDLE_NUM_FDS,
-   
GRALLOC_HANDLE_NUM_INTS);
-   handle.base = *nhandle;
-   native_handle_delete(nhandle);
-
-   handle.width = width;
-   handle.height = height;
-   handle.format = format;
-   handle.usage = usage;
-   handle.prime_fd = -1;
-
-   handle->data_owner = getpid();
-   handle->data = bo;
+   
GRALLOC_HANDLE_NUM_INTS);
+
+   if (!nhandle)
+   return NULL;
+
+   handle = gralloc_handle(nhandle);
+   handle->magic = GRALLOC_HANDLE_MAGIC;
+   handle->version = GRALLOC_HANDLE_VERSION;
+   handle->width = width;
+   handle->height = height;
+   handle->format = format;
+   handle->usage = usage;
+   handle->prime_fd = -1;
 
return handle;
 }
-- 
2.14.1

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

[PATCH libdrm 1/4] android: revert making handle magic and version members const

[Rob Herring]

Const members are problematic for dynamically allocating struct
gralloc_handle_t, so just drop the const modifier.

Signed-off-by: Rob Herring 
---
 android/gralloc_handle.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/android/gralloc_handle.h b/android/gralloc_handle.h
index b47bee191f94..b035e03566cc 100644
--- a/android/gralloc_handle.h
+++ b/android/gralloc_handle.h
@@ -51,8 +51,8 @@ struct gralloc_handle_t {
int prime_fd;
 
/* api variables */
-   const uint32_t magic; /* differentiate between allocator impls */
-   const uint32_t version; /* api version */
+   uint32_t magic; /* differentiate between allocator impls */
+   uint32_t version; /* api version */
 
uint32_t width; /* width of buffer in pixels */
uint32_t height; /* height of buffer in pixels */
-- 
2.14.1

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

[PATCH libdrm 2/4] android: fix mis-named alloc_handle_t

[Rob Herring]

Fix a typo where alloc_handle_t should be gralloc_handle_t. One still
remains in gralloc_handle_create, but a subsequent commit will fix that
along with other problems in gralloc_handle_create.

Signed-off-by: Rob Herring 
---
 android/gralloc_handle.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/android/gralloc_handle.h b/android/gralloc_handle.h
index b035e03566cc..b0f5048cc6a1 100644
--- a/android/gralloc_handle.h
+++ b/android/gralloc_handle.h
@@ -73,7 +73,7 @@ struct gralloc_handle_t {
 #define GRALLOC_HANDLE_MAGIC 0x60585350
 #define GRALLOC_HANDLE_NUM_FDS 1
 #define GRALLOC_HANDLE_NUM_INTS (  \
-   ((sizeof(struct alloc_handle_t) - sizeof(native_handle_t))/sizeof(int)) 
\
+   ((sizeof(struct gralloc_handle_t) - 
sizeof(native_handle_t))/sizeof(int))   \
 - GRALLOC_HANDLE_NUM_FDS)
 
 /**
-- 
2.14.1

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

[PATCH libdrm 0/4] gralloc handle fixes

[Rob Herring]

The recently committed gralloc handle definition has a few issues like 
not actually compiling. This series fixes those issues. I now have 
things working with these fixes and switching mesa, gbm_gralloc, and 
drm_hwcomposer to use this header.

Rob

Rob Herring (4):
  android: revert making handle magic and version members const
  android: fix mis-named alloc_handle_t
  android: add helper to convert buffer_handle_t to gralloc_handle_t ptr
  android: fix gralloc_handle_create() problems

 android/gralloc_handle.h | 43 +++
 1 file changed, 23 insertions(+), 20 deletions(-)

-- 
2.14.1

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

Re: [PATCH 2/8] dt-bindings: display: renesas, du: Document r8a77995 bindings

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 15 February 2018 10:38:17 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Document the D3 (r8a77995) SoC in the R-Car DU bindings.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

and applied to my tree.

> ---
>  Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
> b/Documentation/devicetree/bindings/display/renesas,du.txt index
> 8f6e0e118e3e..56f67453b9aa 100644
> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -13,6 +13,7 @@ Required Properties:
>  - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
>  - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
>  - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
> +- "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU
> 
>- reg: A list of base address and length of each memory resource, one for
> each entry in the reg-names property.
> @@ -60,6 +61,7 @@ corresponding to each DU output.
>   R8A7794 (R-Car E2)   DPAD 0 DPAD 1 -  -
>   R8A7795 (R-Car H3)   DPAD 0 HDMI 0 HDMI 1 LVDS 0
>   R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 -
> + R8A77995 (R-Car D3)  DPAD 0 LVDS 0 LVDS 1 -
> 
> 
>  Example: R8A7795 (R-Car H3) ES2.0 DU


-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature

[Jani Nikula]

On Wed, 14 Feb 2018, Anusha Srivatsa  wrote:
> Forward Error Correction is supported on DP 1.4.
> This patch adds corresponding DPCD register definitions.
>
> v2: Add dri-devel mailing list to the CC list(Jani)
>
> v3: Change names, add missing masks (Manasi)
>
> v4: Add missing shifts to mask (Manasi)
>
> v5: Arrange the definitions in ascending order
> of the address (Jani)
>
> v6: remove unnecessary definitions. Add missing masks,
> add "/* 1.4 */" to offset definitions. (Jani)
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 

Pushed to drm-misc-next, thanks for the patch.

BR,
Jani.

> ---
>  include/drm/drm_dp_helper.h | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c239e6e..4de97e9 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -329,6 +329,13 @@
>  # define DP_DS_12BPC 2
>  # define DP_DS_16BPC 3
>  
> +/* DP Forward error Correction Registers */
> +#define DP_FEC_CAPABILITY0x090/* 1.4 */
> +# define DP_FEC_CAPABLE  (1 << 0)
> +# define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
> +# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
> +# define DP_FEC_BIT_ERROR_COUNT_CAP  (1 << 3)
> +
>  /* link configuration */
>  #define  DP_LINK_BW_SET  0x100
>  # define DP_LINK_RATE_TABLE  0x00/* eDP 1.4 */
> @@ -445,6 +452,19 @@
>  #define DP_UPSTREAM_DEVICE_DP_PWR_NEED   0x118   /* 1.2 */
>  # define DP_PWR_NOT_NEEDED   (1 << 0)
>  
> +#define DP_FEC_CONFIGURATION 0x120/* 1.4 */
> +# define DP_FEC_READY(1 << 0)
> +# define DP_FEC_ERR_COUNT_SEL_MASK   (7 << 1)
> +# define DP_FEC_ERR_COUNT_DIS(0 << 1)
> +# define DP_FEC_UNCORR_BLK_ERROR_COUNT   (1 << 1)
> +# define DP_FEC_CORR_BLK_ERROR_COUNT (2 << 1)
> +# define DP_FEC_BIT_ERROR_COUNT  (3 << 1)
> +# define DP_FEC_LANE_SELECT_MASK (3 << 4)
> +# define DP_FEC_LANE_0_SELECT(0 << 4)
> +# define DP_FEC_LANE_1_SELECT(1 << 4)
> +# define DP_FEC_LANE_2_SELECT(2 << 4)
> +# define DP_FEC_LANE_3_SELECT(3 << 4)
> +
>  #define DP_AUX_FRAME_SYNC_VALUE  0x15c   /* eDP 1.4 */
>  # define DP_AUX_FRAME_SYNC_VALID (1 << 0)
>  
> @@ -620,6 +640,16 @@
>  #define DP_TEST_SINK 0x270
>  # define DP_TEST_SINK_START  (1 << 0)
>  
> +#define DP_FEC_STATUS0x280/* 1.4 */
> +# define DP_FEC_DECODE_EN_DETECTED   (1 << 0)
> +# define DP_FEC_DECODE_DIS_DETECTED  (1 << 1)
> +
> +#define DP_FEC_ERROR_COUNT_LSB   0x0281/* 1.4 */
> +
> +#define DP_FEC_ERROR_COUNT_MSB   0x0282/* 1.4 */
> +# define DP_FEC_ERROR_COUNT_MASK 0x7F
> +# define DP_FEC_ERR_COUNT_VALID  (1 << 7)
> +
>  #define DP_PAYLOAD_TABLE_UPDATE_STATUS  0x2c0   /* 1.2 MST */
>  # define DP_PAYLOAD_TABLE_UPDATED   (1 << 0)
>  # define DP_PAYLOAD_ACT_HANDLED (1 << 1)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 00/12] drm/sun4i: Add A83T HDMI support

[Maxime Ripard]

On Wed, Feb 14, 2018 at 09:08:54PM +0100, Jernej Skrabec wrote:
> This patch series implements support for A83T DW HDMI and PHY. Contrary to
> v1 series, this one is based on latest linux-next, since all needed patches
> were merged.
> 
> While exactly this combination of HDMI controller and PHY is not common in
> Allwinner SoCs, this patch series nevertheless makes groundwork for other
> SoCs, which have same DW HDMI IP block, but different PHYs, like H3 and H5.
> 
> Please take a look.

I've applied the two clk patches. I'm waiting for some review from
Archit on the synopsys bridge before merging anything else.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


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

[Bug 100759] [r600] System freeze on resume from sleep on battery with DPM enabled and linux 4.10

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher  ---
Sorry, slipped off my radar.  I just sent the revert out for review.

-- 
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 100759] [r600] System freeze on resume from sleep on battery with DPM enabled and linux 4.10

[bugzilla-daemon]

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

--- Comment #2 from Nicola Mori  ---
Is there any chance that this bug report will be addressed?

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

Re: [PATCH] drm/amdgpu_gem: fix error handling path in amdgpu_gem_va_update_vm

[Christian König]

Am 15.02.2018 um 06:20 schrieb Gustavo A. R. Silva:

Currently, if amdgpu_vm_bo_update() fails, the returned error
is being ignored.

Fix this by properly checking _r_ after calling amdgpu_vm_bo_update.
Also, remove redundant code just before label _error_.

Addresses-Coverity-ID: 1464280 ("Unused value")
Fixes: 0abc6878fc2d ("drm/amdgpu: update VM PDs after the PTs")
Signed-off-by: Gustavo A. R. Silva 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index e48b4ec..db85fc0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -523,12 +523,13 @@ static void amdgpu_gem_va_update_vm(struct amdgpu_device 
*adev,
goto error;
  
  	if (operation == AMDGPU_VA_OP_MAP ||

-   operation == AMDGPU_VA_OP_REPLACE)
+   operation == AMDGPU_VA_OP_REPLACE) {
r = amdgpu_vm_bo_update(adev, bo_va, false);
+   if (r)
+   goto error;
+   }
  
  	r = amdgpu_vm_update_directories(adev, vm);

-   if (r)
-   goto error;
  
  error:

if (r && r != -ERESTARTSYS)


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

[PATCH v5 9/9] drm: Add and handle new aspect ratios in DRM layer

[Nautiyal, Ankit K]

From: "Sharma, Shashank" 

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

This patch was once reviewed and merged, and later reverted due
to lack of DRM client protection, while adding aspect ratio bits
in user modes. This is a re-spin of the series, with DRM client
cap protection.

The previous series can be found here:
https://pw-emeril.freedesktop.org/series/10850/

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul  (V2)
Reviewed-by: Jose Abreu  (V2)

Cc: Ville Syrjala 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: rebase
V4: rebase
V5: corrected the macro name for an aspect ratio, in a switch case.
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 25140b9..ad907e6 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1659,6 +1659,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case HDMI_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1719,6 +1725,12 @@ int drm_mode_convert_umode(struct drm_device *dev,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 2c57579..93c27cd 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -93,6 +93,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354
 
 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -102,6 +104,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
 
 #define  DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
 DRM_MODE_FLAG_NHSYNC | \
-- 
2.7.4

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

[PATCH v5 8/9] drm: Add aspect ratio parsing in DRM layer

[Nautiyal, Ankit K]

From: "Sharma, Shashank" 

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.

Review link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride  (V2)
Reviewed-by: Jose Abreu  (V4)

Cc: Ville Syrjala 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: modified the aspect-ratio check in drm_mode_equal as per new flags
provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
---
 drivers/gpu/drm/drm_modes.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ca4c5cc..25140b9 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1050,7 +1050,8 @@ bool drm_mode_equal(const struct drm_display_mode *mode1,
  DRM_MODE_MATCH_TIMINGS |
  DRM_MODE_MATCH_CLOCK |
  DRM_MODE_MATCH_FLAGS |
- DRM_MODE_MATCH_3D_FLAGS);
+ DRM_MODE_MATCH_3D_FLAGS|
+ DRM_MODE_MATCH_ASPECT_RATIO);
 }
 EXPORT_SYMBOL(drm_mode_equal);
 
@@ -1649,6 +1650,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1693,6 +1709,21 @@ int drm_mode_convert_umode(struct drm_device *dev,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 
+   /* Clearing picture aspect ratio bits from out flags */
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }
+
out->status = drm_mode_validate_driver(dev, out);
if (out->status != MODE_OK)
goto out;
-- 
2.7.4

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

[PATCH v5 6/9] drm: Handle aspect ratio info in legacy and atomic modeset paths

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is not supported by the user.

This patch:
1. passes the file_priv structure from the drm_mode_atomic_ioctl till
   the drm_mode_crtc_set_mode_prop, to get the user capability.
2. rejects the modes with aspect-ratio info, during modeset, if the
   user does not support aspect ratio.
3. does not load the aspect-ratio info in user-mode structure, if
   aspect ratio is not supported.

Signed-off-by: Ankit Nautiyal 

V3: Addressed review comments from Ville:
Do not corrupt the current crtc state by updating aspect ratio on
the fly.
V4: rebase
V5: As suggested by Ville, rejected the modeset calls for modes with
aspect ratio, if the user does not set aspect ratio cap.
---
 drivers/gpu/drm/drm_atomic.c| 30 ++
 drivers/gpu/drm/drm_atomic_helper.c |  6 +++---
 drivers/gpu/drm/drm_crtc.c  | 15 +++
 drivers/gpu/drm/drm_crtc_internal.h |  3 ++-
 drivers/gpu/drm/drm_mode_object.c   |  9 ++---
 drivers/gpu/drm/drm_modes.c |  1 +
 include/drm/drm_atomic.h|  5 +++--
 7 files changed, 52 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 86b483e..7e78305 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -368,6 +368,7 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
  * drm_atomic_set_mode_prop_for_crtc - set mode for CRTC
  * @state: the CRTC whose incoming state to update
  * @blob: pointer to blob property to use for mode
+ * @file_priv: file priv structure, to get the userspace capabilities
  *
  * Set a mode (originating from a blob property) on the desired CRTC state.
  * This function will take a reference on the blob property for the CRTC state,
@@ -378,7 +379,8 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
  * Zero on success, error code on failure. Cannot return -EDEADLK.
  */
 int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state,
-  struct drm_property_blob *blob)
+ struct drm_property_blob *blob,
+ struct drm_file *file_priv)
 {
if (blob == state->mode_blob)
return 0;
@@ -389,10 +391,20 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
drm_crtc_state *state,
memset(>mode, 0, sizeof(state->mode));
 
if (blob) {
+   struct drm_mode_modeinfo *u_mode;
+
+   u_mode = (struct drm_mode_modeinfo *) blob->data;
+   if (!file_priv->aspect_ratio_allowed &&
+   (u_mode->flags & DRM_MODE_FLAG_PIC_AR_MASK) !=
+   DRM_MODE_FLAG_PIC_AR_NONE) {
+   DRM_DEBUG_ATOMIC("Unexpected aspect-ratio flag bits\n");
+   return -EINVAL;
+   }
+
if (blob->length != sizeof(struct drm_mode_modeinfo) ||
drm_mode_convert_umode(state->crtc->dev, >mode,
-  (const struct drm_mode_modeinfo *)
-   blob->data))
+  (const struct drm_mode_modeinfo *)
+  u_mode))
return -EINVAL;
 
state->mode_blob = drm_property_blob_get(blob);
@@ -441,6 +453,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
  * @state: the state object to update with the new property value
  * @property: the property to set
  * @val: the new property value
+ * @file_priv: the file private structure, to get the user capabilities
  *
  * This function handles generic/core properties and calls out to driver's
  * _crtc_funcs.atomic_set_property for driver properties. To ensure
@@ -452,7 +465,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
  */
 int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
struct drm_crtc_state *state, struct drm_property *property,
-   uint64_t val)
+   uint64_t val, struct drm_file *file_priv)
 {
struct drm_device *dev = crtc->dev;
struct drm_mode_config *config = >mode_config;
@@ -465,7 +478,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
struct drm_property_blob *mode =
drm_property_lookup_blob(dev, val);
mode->is_video_mode = true;
-   ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
+   ret = drm_atomic_set_mode_prop_for_crtc(state, mode, file_priv);
drm_property_blob_put(mode);
return ret;
} 

Re: [PATCH] drm/mm: Fix caching of leftmost node in the interval tree

[Chris Wilson]

Quoting Chris Wilson (2018-02-15 11:36:51)
> When we descend the tree to find our slot, if we step to the right, we
> are no longer the leftmost node.

Fortunately, the cached leftmost node is unused here and no drm_mm API
exposes it. So probably doesn't make sense to send it to stable@ as no
bug exists.
 
> Fixes: f808c13fd373 ("lib/interval_tree: fast overlap detection")
> Signed-off-by: Chris Wilson 
> Cc: Davidlohr Bueso 
> Cc: Jérôme Glisse 
> Cc: Christian König 
> Cc:  # v4.14+
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 7/9] drm: Expose modes with aspect ratio, only if requested

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regadless of
whether user space requested this information or not.

This patch prunes the modes with aspect-ratio information, from a
connector's modelist, if the user-space has not set the aspect ratio
DRM client cap.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 

Signed-off-by: Ankit Nautiyal 

V3: As suggested by Ville, modified the mechanism of pruning of modes
with aspect-ratio, if the aspect-ratio is not supported. Instead
of straight away pruning such a mode, the mode is retained with
aspect ratio bits set to zero, provided it is unique.
V4: rebase
V5: Addressed review comments from Ville:
-used a pointer to store last valid mode.
-avoided, modifying of picture_aspect_ratio in kernel mode,
 instead only flags bits of user mode are reset (if aspect-ratio
 is not supported).
---
 drivers/gpu/drm/drm_connector.c | 45 -
 1 file changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 16b9c38..49778e8 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1507,8 +1507,10 @@ static struct drm_encoder 
*drm_connector_get_encoder(struct drm_connector *conne
return connector->encoder;
 }
 
-static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
-const struct drm_file *file_priv)
+static bool
+drm_mode_expose_to_userspace(const struct drm_display_mode *last_mode,
+const struct drm_display_mode *mode,
+const struct drm_file *file_priv)
 {
/*
 * If user-space hasn't configured the driver to expose the stereo 3D
@@ -1516,6 +1518,23 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
 */
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   /*
+* If user-space hasn't configured the driver to expose the modes
+* with aspect-ratio, don't expose them. But in case of a unique
+* mode, let the mode be passed, so that it can be enumerated with
+* aspect ratio bits erased.
+*/
+   if (!file_priv->aspect_ratio_allowed &&
+   mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) {
+   if (last_mode && !drm_mode_match(mode, last_mode,
+DRM_MODE_MATCH_TIMINGS |
+DRM_MODE_MATCH_CLOCK |
+DRM_MODE_MATCH_FLAGS |
+DRM_MODE_MATCH_3D_FLAGS))
+   return true;
+   else
+   return false;
+   }
 
return true;
 }
@@ -1527,6 +1546,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
struct drm_connector *connector;
struct drm_encoder *encoder;
struct drm_display_mode *mode;
+   struct drm_display_mode *last_valid_mode;
int mode_count = 0;
int encoders_count = 0;
int ret = 0;
@@ -1582,9 +1602,13 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
out_resp->connection = connector->status;
 
/* delayed so we get modes regardless of pre-fill_modes state */
+   last_valid_mode = NULL;
list_for_each_entry(mode, >modes, head)
-   if (drm_mode_expose_to_userspace(mode, file_priv))
+   if (drm_mode_expose_to_userspace(last_valid_mode, mode,
+file_priv)) {
mode_count++;
+   last_valid_mode = mode;
+   }
 
/*
 * This ioctl is called twice, once to determine how much space is
@@ -1593,11 +1617,21 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
if ((out_resp->count_modes >= mode_count) && mode_count) {
copied = 0;
mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned 
long)out_resp->modes_ptr;
+   last_valid_mode = NULL;
list_for_each_entry(mode, >modes, head) {
-   if (!drm_mode_expose_to_userspace(mode, file_priv))
+   if (!drm_mode_expose_to_userspace(last_valid_mode,
+ mode,
+ file_priv))
continue;
-
drm_mode_convert_to_umode(_mode, mode);
+
+   /*
+* Reset 

[PATCH v5 1/9] drm/modes: Introduce drm_mode_match()

[Nautiyal, Ankit K]

From: Ville Syrjälä 

Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_modes.c | 134 ++--
 include/drm/drm_modes.h |   9 +++
 2 files changed, 112 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c397b52..6ca1f3b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -940,17 +940,68 @@ struct drm_display_mode *drm_mode_duplicate(struct 
drm_device *dev,
 }
 EXPORT_SYMBOL(drm_mode_duplicate);
 
+static bool drm_mode_match_timings(const struct drm_display_mode *mode1,
+  const struct drm_display_mode *mode2)
+{
+   return mode1->hdisplay == mode2->hdisplay &&
+   mode1->hsync_start == mode2->hsync_start &&
+   mode1->hsync_end == mode2->hsync_end &&
+   mode1->htotal == mode2->htotal &&
+   mode1->hskew == mode2->hskew &&
+   mode1->vdisplay == mode2->vdisplay &&
+   mode1->vsync_start == mode2->vsync_start &&
+   mode1->vsync_end == mode2->vsync_end &&
+   mode1->vtotal == mode2->vtotal &&
+   mode1->vscan == mode2->vscan;
+}
+
+static bool drm_mode_match_clock(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
+{
+   /*
+* do clock check convert to PICOS
+* so fb modes get matched the same
+*/
+   if (mode1->clock && mode2->clock)
+   return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock);
+   else
+   return mode1->clock == mode2->clock;
+}
+
+static bool drm_mode_match_flags(const struct drm_display_mode *mode1,
+const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_aspect_ratio(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio;
+}
+
 /**
- * drm_mode_equal - test modes for equality
+ * drm_mode_match - test modes for (partial) equality
  * @mode1: first mode
  * @mode2: second mode
+ * @match_flags: which parts need to match (DRM_MODE_MATCH_*)
  *
  * Check to see if @mode1 and @mode2 are equivalent.
  *
  * Returns:
- * True if the modes are equal, false otherwise.
+ * True if the modes are (partially) equal, false otherwise.
  */
-bool drm_mode_equal(const struct drm_display_mode *mode1, const struct 
drm_display_mode *mode2)
+bool drm_mode_match(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2,
+   unsigned int match_flags)
 {
if (!mode1 && !mode2)
return true;
@@ -958,15 +1009,48 @@ bool drm_mode_equal(const struct drm_display_mode 
*mode1, const struct drm_displ
if (!mode1 || !mode2)
return false;
 
-   /* do clock check convert to PICOS so fb modes get matched
-* the same */
-   if (mode1->clock && mode2->clock) {
-   if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock))
-   return false;
-   } else if (mode1->clock != mode2->clock)
+   if (match_flags & DRM_MODE_MATCH_TIMINGS &&
+   !drm_mode_match_timings(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_CLOCK &&
+   !drm_mode_match_clock(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_FLAGS &&
+   !drm_mode_match_flags(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_3D_FLAGS &&
+   !drm_mode_match_3d_flags(mode1, mode2))
return false;
 
-   return drm_mode_equal_no_clocks(mode1, mode2);
+   if (match_flags & DRM_MODE_MATCH_ASPECT_RATIO &&
+   !drm_mode_match_aspect_ratio(mode1, mode2))
+   return false;
+
+   return true;
+}
+EXPORT_SYMBOL(drm_mode_match);
+
+/**
+ * drm_mode_equal - test modes for equality
+ * @mode1: first mode
+ * @mode2: second mode
+ *
+ * Check to see if @mode1 and @mode2 are equivalent.
+ *
+ * Returns:
+ * True if the modes are equal, false otherwise.
+ */
+bool drm_mode_equal(const struct drm_display_mode *mode1,
+   const struct drm_display_mode 

[PATCH v5 5/9] drm: Handle aspect-ratio info in getblob

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

If the user space  does not support aspect-ratio, then getblob called
with the blob id of a user mode, should clear the aspect ratio
information in the blob data.

Currently for a given blob id, there is no way to determine if the
blob stores user mode or not. This can only be ascertained when the
blob is used for an atomic modeset call.

This patch:
-adds a new field 'is_video_mode' in drm_property_blob to
 differentiate between the video mode blobs and the other blobs.
-sets the field 'is_video_mode' when the blob is used for modeset.
-removes the aspect-ratio info from the mode data if aspect ratio is
 not supported by the user, while returning the blob to the user, in
 getblob ioctl.

Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/drm_atomic.c   | 1 +
 drivers/gpu/drm/drm_property.c | 6 ++
 include/drm/drm_property.h | 2 ++
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 46733d5..86b483e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -464,6 +464,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
else if (property == config->prop_mode_id) {
struct drm_property_blob *mode =
drm_property_lookup_blob(dev, val);
+   mode->is_video_mode = true;
ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
drm_property_blob_put(mode);
return ret;
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index bae50e6..639787c 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -746,6 +746,12 @@ int drm_mode_getblob_ioctl(struct drm_device *dev,
if (!blob)
return -ENOENT;
 
+   if (blob->is_video_mode && !file_priv->aspect_ratio_allowed) {
+   struct drm_mode_modeinfo *mode =
+   (struct drm_mode_modeinfo *) blob->data;
+   mode->flags &= (~DRM_MODE_FLAG_PIC_AR_MASK);
+   }
+
if (out_resp->length == blob->length) {
if (copy_to_user(u64_to_user_ptr(out_resp->data),
 blob->data,
diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h
index 8a522b4..95e6e32 100644
--- a/include/drm/drm_property.h
+++ b/include/drm/drm_property.h
@@ -194,6 +194,7 @@ struct drm_property {
  * @head_global: entry on the global blob list in
  * _mode_config.property_blob_list.
  * @head_file: entry on the per-file blob list in _file.blobs list.
+ * @is_video_mode: flag to mark the blobs that contain drm_mode_modeinfo.
  * @length: size of the blob in bytes, invariant over the lifetime of the 
object
  * @data: actual data, embedded at the end of this structure
  *
@@ -208,6 +209,7 @@ struct drm_property_blob {
struct drm_device *dev;
struct list_head head_global;
struct list_head head_file;
+   bool is_video_mode;
size_t length;
unsigned char data[];
 };
-- 
2.7.4

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

[PATCH v5 4/9] drm: Add DRM client cap for aspect-ratio

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
user-spaces which have no intention or support to use this aspect
ratio information.

To avoid this, a new drm client cap is required to enable a
user-space to advertise if it supports modes with aspect-ratio. Based
on this cap value, the kernel will take a call on exposing the aspect
ratio info in modes or not.

This patch adds the client cap for aspect-ratio.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Signed-off-by: Ankit Nautiyal 

V3: rebase
V4: As suggested by Marteen Lankhorst modified the commit message
explaining the need to use the DRM cap for aspect-ratio. Also,
tweaked the comment lines in the code for better understanding and
clarity, as recommended by Shashank Sharma.
V5: rebase

Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_ioctl.c | 5 +
 include/drm/drm_file.h  | 8 
 include/uapi/drm/drm.h  | 7 +++
 3 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index af78291..54a98b7 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -325,6 +325,11 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_ASPECT_RATIO:
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->aspect_ratio_allowed = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0e0c868..c025301 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -182,6 +182,14 @@ struct drm_file {
unsigned atomic:1;
 
/**
+* @aspect_ratio_allowed:
+*
+* True, if client can handle picture aspect ratios, and has requested
+* to pass this information along with the mode.
+*/
+   unsigned aspect_ratio_allowed:1;
+
+   /**
 * @is_master:
 *
 * This client is the creator of @master. Protected by struct
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff59..9c660e1 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -680,6 +680,13 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3
 
+/**
+ * DRM_CLIENT_CAP_ASPECT_RATIO
+ *
+ * If set to 1, the DRM core will provide aspect ratio information in modes.
+ */
+#define DRM_CLIENT_CAP_ASPECT_RATIO4
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
2.7.4

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

[PATCH v5 3/9] drm/edid: Fix cea mode aspect ratio handling

[Nautiyal, Ankit K]

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5594292..a4d3919 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2908,11 +2908,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
 static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2926,7 +2930,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2943,11 +2947,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
  */
 u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2961,7 +2969,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -3008,6 +3016,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode 
*hdmi_mode)
 static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
  unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3025,7 +3034,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
+   if (drm_mode_match(to_match, hdmi_mode, match_flags))
return vic;
}
 
@@ -3042,6 +3051,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
  */
 static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3057,7 +3067,7 @@ static u8 drm_match_hdmi_mode(const struct 
drm_display_mode *to_match)
 
if 

[PATCH v5 2/9] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

[Nautiyal, Ankit K]

From: Ville Syrjälä 

Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.

This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b1cb262..5594292 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3025,7 +3025,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks(to_match, hdmi_mode))
+   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
return vic;
}
 
-- 
2.7.4

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

[PATCH v5 0/9] Aspect ratio support in DRM layer

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

This patch series is a re-attempt to enable aspect ratio support in DRM layer.
Currently the aspect ratio information gets lost in translation during a
user->kernel mode or vice versa.

The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had
4 patches, out of which 2 patches were reverted due to lack of drm client
protection while loading the aspect information.

This patch series also includes 3 patches from Ville Syrjälä's series for
'Info-frame cleanup and fixes' https://patchwork.freedesktop.org/series/33730/
which fixes the mode matching mechanism via flags.

This patch series, adds a DRM client option for aspect ratio, and loads aspect
ratio flags, only when the client sets this cap.

To test this patch, the testdiplay IGT test is modified to have an option to do
a modeset with only aspect ratio modes.
https://patchwork.freedesktop.org/series/37033/

Also, there is a userspace implementation in Wayland/weston layer:
https://patchwork.freedesktop.org/patch/188125/
(Which is already ACK'ed by wayland community.)

This, helps us in passing HDMI compliance test cases like 7-27, where the test
equipment applies a CEA mode, and expects the exact VIC in the AVI infoframes.

Ankit Nautiyal (4):
  drm: Add DRM client cap for aspect-ratio
  drm: Handle aspect-ratio info in getblob
  drm: Handle aspect ratio info in legacy and atomic modeset paths
  drm: Expose modes with aspect ratio, only if requested

Sharma, Shashank (2):
  drm: Add aspect ratio parsing in DRM layer
  drm: Add and handle new aspect ratios in DRM layer

Ville Syrjälä (3):
  drm/modes: Introduce drm_mode_match()
  drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
  drm/edid: Fix cea mode aspect ratio handling

 drivers/gpu/drm/drm_atomic.c|  31 +--
 drivers/gpu/drm/drm_atomic_helper.c |   6 +-
 drivers/gpu/drm/drm_connector.c |  45 -
 drivers/gpu/drm/drm_crtc.c  |  15 +++
 drivers/gpu/drm/drm_crtc_internal.h |   3 +-
 drivers/gpu/drm/drm_edid.c  |  18 +++-
 drivers/gpu/drm/drm_ioctl.c |   5 +
 drivers/gpu/drm/drm_mode_object.c   |   9 +-
 drivers/gpu/drm/drm_modes.c | 178 +---
 drivers/gpu/drm/drm_property.c  |   6 ++
 include/drm/drm_atomic.h|   5 +-
 include/drm/drm_file.h  |   8 ++
 include/drm/drm_modes.h |   9 ++
 include/drm/drm_property.h  |   2 +
 include/uapi/drm/drm.h  |   7 ++
 include/uapi/drm/drm_mode.h |   6 ++
 16 files changed, 296 insertions(+), 57 deletions(-)

-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 06/10] drm/tegra: Handle 64-bit return from drm_crtc_vblank_count()

[Thierry Reding]

On Wed, Feb 07, 2018 at 01:41:18AM +, Pandiyan, Dhinakaran wrote:
> On Fri, 2018-02-02 at 21:12 -0800, Dhinakaran Pandiyan wrote:
> > 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
> > return type for drm_crtc_vblank_count() to u64. This could cause
> > potential problems if the return value is used in arithmetic operations
> > with a 32-bit reference HW vblank count. Explicitly typecasting this
> > down to u32 either fixes a potential problem or serves to add clarity in
> > case the implicit typecasting was already correct.
> > 
> > Cc: Keith Packard 
> > Cc: Thierry Reding 
> 
> 
> Thierry, 
> 
> Can I get an Ack on this please? 

Acked-by: Thierry Reding 


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

Re: [RFC PATCH v2 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Krzysztof Kozlowski]

On Thu, Feb 15, 2018 at 11:39 AM, Andrzej Hajda  wrote:
> OF graph describes MHL data lanes between MHL and respective USB
> connector.
>
> Signed-off-by: Andrzej Hajda 
> ---
>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 
> +++---
>  1 file changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> index 7e49fadee412..ef758f7337e9 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -779,9 +779,22 @@
> clocks = <_system_controller 0>;
> clock-names = "xtal";
>
> -   port {
> -   mhl_to_hdmi: endpoint {
> -   remote-endpoint = <_to_mhl>;
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   port@0 {
> +   reg = <0>;
> +   mhl_to_hdmi: endpoint {
> +   remote-endpoint = <_to_mhl>;
> +   };
> +   };
> +
> +   port@1 {
> +   reg = <1>;
> +   mhl_to_musb_con: endpoint {
> +   remote-endpoint = <_con_to_mhl>;
> +   };
> };
> };
> };
> @@ -804,6 +817,18 @@
>  "usb-b-connector";
> label = "micro-USB";
> type = "micro";
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   port@3 {

I think you might need here "reg = <3>". Doesn't it produce a warning now?

BR,
Krzysztof

> +   musb_con_to_mhl: endpoint {
> +   remote-endpoint = 
> <_to_musb_con>;
> +   };
> +   };
> +   };
> +   };
> };
> };
>
> --
> 2.16.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] s390/console: enable dummy console for vt

[Christian Borntraeger]

On 02/15/2018 12:57 PM, Thomas Huth wrote:
> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>> Hi Christian,
>>
>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>>  wrote:
>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>> via the graphics support. Instead of fully enabling the graphic
>>> drivers lets just provide a Kconfig option for the dummy console.
>>>
>>> Signed-off-by: Christian Borntraeger 
>>> ---
>>> New version: instead of moving around the graphic and console stuff,
>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>  arch/s390/Kconfig | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>> index cbe1d978693a..a69690f616f3 100644
>>> --- a/arch/s390/Kconfig
>>> +++ b/arch/s390/Kconfig
>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>
>>>  source "arch/s390/kvm/Kconfig"
>>>
>>> +config DUMMY_CONSOLE
>>> +   bool
>>> +   depends on VT
>>> +   default y
>>> +
>>>  config S390_GUEST
>>> def_bool y
>>> prompt "s390 support for virtio devices"
>>
>> Really?
>>
>> You already have your own copy of HAS_IOMEM, which makes it hard for
>> people to track which one applies where.
> 
> I think I agree with Geert - let's better fix this in a proper way
> instead of doing hacks like this. I guess there will be other
> architectures in the future that might want to use the dummy console
> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
> better to me.

The question is, what is the proper fix?

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

Re: [PATCH] s390/console: enable dummy console for vt

[Thomas Huth]

On 15.02.2018 12:26, Geert Uytterhoeven wrote:
> Hi Christian,
> 
> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>  wrote:
>> To enable the virtual terminal layer with virtio-gpu, we need to
>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>> via the graphics support. Instead of fully enabling the graphic
>> drivers lets just provide a Kconfig option for the dummy console.
>>
>> Signed-off-by: Christian Borntraeger 
>> ---
>> New version: instead of moving around the graphic and console stuff,
>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>  arch/s390/Kconfig | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>> index cbe1d978693a..a69690f616f3 100644
>> --- a/arch/s390/Kconfig
>> +++ b/arch/s390/Kconfig
>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>
>>  source "arch/s390/kvm/Kconfig"
>>
>> +config DUMMY_CONSOLE
>> +   bool
>> +   depends on VT
>> +   default y
>> +
>>  config S390_GUEST
>> def_bool y
>> prompt "s390 support for virtio devices"
> 
> Really?
> 
> You already have your own copy of HAS_IOMEM, which makes it hard for
> people to track which one applies where.

I think I agree with Geert - let's better fix this in a proper way
instead of doing hacks like this. I guess there will be other
architectures in the future that might want to use the dummy console
without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
better to me.

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

Re: [PATCH v3 5/8] drm: Handle aspect ratio info in atomic and legacy modeset paths

[Nautiyal, Ankit K]

Hi Ville,

I have addressed your review comments (including the policy regarding, 
rejection of mode with aspect ratio, if no aspect ratio cap)


and other suggestions in the next patch-set. I will be sending the next 
patch-set, shortly.


Regards,

Ankit


On 2/13/2018 10:15 PM, Ville Syrjälä wrote:

On Tue, Feb 13, 2018 at 09:53:53PM +0530, Nautiyal, Ankit K wrote:

Hi Ville,

Thanks yet again to look into this.

I am still skeptical about rejecting the mode, if aspect ratio cap is
not set.
Perhaps I am not aware with the userspace expectations.

Please find my response inline:

On 2/13/2018 6:48 PM, Ville Syrjälä wrote:

On Tue, Feb 13, 2018 at 10:21:15AM +0530, Nautiyal, Ankit K wrote:

Hi Ville,

As per our last discussion, following points were discussed:

1. To suppress the aspect-ratio info from getblob ioctl to a user that
does not support it:

   i. A new flag must be added to drm_blob_property to mark if the
blob has mode data.

   ii. This flag must be set when the user tries do an atomic modeset.

   iii. In the getblob ioctl, based on the above flag, it can be
determined that if the blob

   has mode data, and the aspect ratio info can be suppressed in
getblob ioctl, if user does not support it.

2. Instead of adding aspect ratio capabilities in drm_atomic_state, pass
on the file_priv which already has

the required information to the function drm_mode_convert_umode.

It will require addition of an new argument file_priv to several
functions, but that is right thing to do,

as file_priv is the correct structure for the capability information.

3. Changing the usermode aspect ratio flag bits, without change in the
picture_aspect_ratio would not matter, and does not need to be handled
in this patch.


I just have one query here. We have agreed to modify
drm_mode_convert_umode, to filter out the aspect-ratio

info if user has not set aspect-ratio capability, but do we need a
similar change the drm_mode_convert_to_umode?

I think you maybe had those backwards.

drm_mode_convert_umode(), or more likely its relevant callers setcrtc
and setproperty, need to reject the mode if the client cap is not set.

I guess, rejecting the mode, altogether can break the existing user-spaces.
Current user-spaces, oblivious of the aspect-ratio capability in drm,
will not set the aspect-ratio capability.
Some of them, might have some garbage value in the aspect ratio bits of
the user mode. If we reject such
modes, the user-spaces that were earlier working will break.
(But if we are sure, that the aspect ratio flag bits will all be reset,
then it makes sense to reject the mode.)

We already reject all unspecified flags.


Instead of rejecting such modes, if we just only ignore the aspect ratio
bits in such cases, and carry on with the
modeset for the given user mode, the behaviour would be intact, just as
prior to the aspect ratio changes.


drm_mode_convert_to_umode(), or rather its callers getblob and getcrtc,
need to filter out the flags.

Yes right. I'll be filtering out the flags in the getblob and getcrtc
functions.

Thanks & Regards,
Ankit

If we do, I am not sure if it would be possible to have the file_priv to
/drm_atomic_set_mode_for_crtc/, which calls

drm_mode_convert_to_umode.  The function /drm_atomic_set_mode_for_crtc/
is used to set mode, originating by kernel,

and make a blob from the kernel mode, which it saves in crtc_state.

This function /: drm_atomic_set_mode_for_crtc, /is called by several
helper functions and driver functions, and passing

file_priv from all these functions does not seem to be plausible.

I don't think we need to plumb it quite that deep. Doing the
check in drm_atomic_crtc_set_property() should be sufficient.


Any suggestions on how to handle this situation?


Regards,

Ankit


On 2/8/2018 9:59 AM, Nautiyal, Ankit K wrote:

Hi Ville,

I still have some queries regarding the handling of aspect ratio flags
in getblob ioctl.

Please find below my responses inline.


On 2/1/2018 6:24 PM, Ville Syrjälä wrote:

On Thu, Feb 01, 2018 at 04:35:22PM +0530, Nautiyal, Ankit K wrote:

Hi Ville,

Appreciate your time and the suggestions.
Please find my response inline:

On 1/31/2018 6:39 PM, Ville Syrjälä wrote:

On Wed, Jan 31, 2018 at 12:04:52PM +0530, Nautiyal, Ankit K wrote:

On 1/30/2018 12:23 AM, Ville Syrjälä wrote:

On Fri, Jan 12, 2018 at 11:51:33AM +0530, Nautiyal, Ankit K wrote:

From: Ankit Nautiyal 

If the user mode does not support aspect-ratio, and requests for
a modeset, then the flag bits representing aspect ratio in the
given user-mode must be rejected.
Similarly, while preparing a user-mode from kernel mode, the
aspect-ratio info must not be given, if aspect-ratio is not
supported by the user.

This patch:
1. adds a new bit field aspect_ratio_allowed in drm_atomic_state,
which is set only if the aspect-ratio is supported by the user.
2. discards the aspect-ratio info from the user mode while
preparing kernel mode 

Re: [PATCH] s390/console: enable dummy console for vt

[Christian Borntraeger]

On 02/15/2018 12:26 PM, Geert Uytterhoeven wrote:
> Hi Christian,
> 
> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>  wrote:
>> To enable the virtual terminal layer with virtio-gpu, we need to
>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>> via the graphics support. Instead of fully enabling the graphic
>> drivers lets just provide a Kconfig option for the dummy console.
>>
>> Signed-off-by: Christian Borntraeger 
>> ---
>> New version: instead of moving around the graphic and console stuff,
>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>  arch/s390/Kconfig | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>> index cbe1d978693a..a69690f616f3 100644
>> --- a/arch/s390/Kconfig
>> +++ b/arch/s390/Kconfig
>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>
>>  source "arch/s390/kvm/Kconfig"
>>
>> +config DUMMY_CONSOLE
>> +   bool
>> +   depends on VT
>> +   default y
>> +
>>  config S390_GUEST
>> def_bool y
>> prompt "s390 support for virtio devices"
> 
> Really?
> 
> You already have your own copy of HAS_IOMEM, which makes it hard for
> people to track which one applies where.
> 

I am open for better suggestions. One idea that I had was to reverse
the logic in s390 (and use the common code HAS_IOMEM)

like


diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index cbe1d978693a..123dd593ea20 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -715,8 +715,8 @@ endif   # PCI
 config PCI_DOMAINS
def_bool PCI
 
-config HAS_IOMEM
-   def_bool PCI
+config NO_IOMEM
+   def_bool y if !PCI
 
 config IOMMU_HELPER
def_bool PCI


This would enable CONFIG_VT and also CONFIG_DUMMY_CONSOLE as long as
PCI is enabled. If DUMMY_CONSOLE is not enabled (e.g. due to missing PCI),
we get a crash in the VT layer as conswitchp is then null.

Somewhat tricky.

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

[PATCH] drm/mm: Fix caching of leftmost node in the interval tree

[Chris Wilson]

When we descend the tree to find our slot, if we step to the right, we
are no longer the leftmost node.

Fixes: f808c13fd373 ("lib/interval_tree: fast overlap detection")
Signed-off-by: Chris Wilson 
Cc: Davidlohr Bueso 
Cc: Jérôme Glisse 
Cc: Christian König 
Cc:  # v4.14+
---
 drivers/gpu/drm/drm_mm.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 186c4e90cc1c..a351bd888a61 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -180,7 +180,7 @@ static void drm_mm_interval_tree_add_node(struct 
drm_mm_node *hole_node,
struct drm_mm *mm = hole_node->mm;
struct rb_node **link, *rb;
struct drm_mm_node *parent;
-   bool leftmost = true;
+   bool leftmost;
 
node->__subtree_last = LAST(node);
 
@@ -201,6 +201,7 @@ static void drm_mm_interval_tree_add_node(struct 
drm_mm_node *hole_node,
} else {
rb = NULL;
link = >interval_tree.rb_root.rb_node;
+   leftmost = true;
}
 
while (*link) {
@@ -208,11 +209,11 @@ static void drm_mm_interval_tree_add_node(struct 
drm_mm_node *hole_node,
parent = rb_entry(rb, struct drm_mm_node, rb);
if (parent->__subtree_last < node->__subtree_last)
parent->__subtree_last = node->__subtree_last;
-   if (node->start < parent->start)
+   if (node->start < parent->start) {
link = >rb.rb_left;
-   else {
+   } else {
link = >rb.rb_right;
-   leftmost = true;
+   leftmost = false;
}
}
 
-- 
2.16.1

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

Re: [PATCH v3 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Feb 15, 2018 at 12:03 PM, Laurent Pinchart
 wrote:
> On Thursday, 15 February 2018 11:18:25 EET Geert Uytterhoeven wrote:
>> On Thu, Feb 15, 2018 at 1:04 AM, Laurent Pinchart wrote:
>> > The internal LVDS encoders now have their own DT bindings. Before
>> > switching the driver infrastructure to those new bindings, implement
>> > backward-compatibility through live DT patching.
>> >
>> > Patching is disabled and will be enabled along with support for the new
>> > DT bindings in the DU driver.
>> >
>> > Signed-off-by: Laurent Pinchart
>> > 
>>
>> Thanks for your patch!
>>
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
>> > @@ -0,0 +1,81 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +/*
>> > + * rcar_du_of_lvds_r8a7790.dts - Legacy LVDS DT bindings conversion for
>> > R8A7790 + *
>> > + * Copyright (C) 2018 Laurent Pinchart
>> > 
>> > + *
>> > + * Based on work from Jyri Sarha 
>> > + * Copyright (C) 2015 Texas Instruments
>> > + */
>> > +
>> > +#include 
>> > +
>> > +/dts-v1/;
>> > +/plugin/;
>> > +/ {

>> > +   fragment@1 {
>> > +   target-path = "/display@feb0/ports";
>>
>> Does this work now there can be an "soc" subnode, too?
>>
>> Your code obtains the right parent:
>>
>> soc_node = of_get_parent(du_node);
>>
>> but the overlay is applied without considering that, if I'm not mistaken.
>
> Correct, and as I can't modify the target-path in the overlay dynamically
> anymore, I can't take this into account. I could duplicate the r8a7790 and
> r8a7791 overlays in two versions to handle this, but as the soc subnode isn't
> in mainline yet, I'd rather get this patch series merged with the current
> implementation in v4.17 to not have to handle this issue :-)

That's of course an option.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 06/12] ARM: dts: r8a7790: Convert to new LVDS DT bindings

[Laurent Pinchart]

Hi Geert,

On Thursday, 15 February 2018 11:20:22 EET Geert Uytterhoeven wrote:
> On Thu, Feb 15, 2018 at 1:04 AM, Laurent Pinchart wrote:
> > The internal LVDS encoder now has DT bindings separate from the DU. Port
> > the device tree over to the new model.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > 
> > --- a/arch/arm/boot/dts/r8a7790.dtsi
> > +++ b/arch/arm/boot/dts/r8a7790.dtsi
> > @@ -1067,17 +1067,13 @@
> > 
> > @@ -1092,11 +1088,61 @@
> > port@1 {
> > reg = <1>;
> > du_out_lvds0: endpoint {
> > +   remote-endpoint = <_in>;
> > };
> > };
> > port@2 {
> > reg = <2>;
> > du_out_lvds1: endpoint {
> > +   remote-endpoint = <_in>;
> > +   };
> > +   };
> > +   };
> > +   };
> > +
> > +   lvds0: lvds@feb9 {
> > +   compatible = "renesas,r8a7790-lvds";
> > +   reg = <0 0xfeb9 0 0x1c>;
> > +   clocks = < CPG_MOD 726>;
> > +   status = "disabled";
> 
> Missing resets, power-domains (for all lvds nodes in all DTS patches).

Will be fixed in v4.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] s390/console: enable dummy console for vt

[Geert Uytterhoeven]

Hi Christian,

On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
 wrote:
> To enable the virtual terminal layer with virtio-gpu, we need to
> provide the dummy console. This console is hidden behind CONFIG_IOMEM
> via the graphics support. Instead of fully enabling the graphic
> drivers lets just provide a Kconfig option for the dummy console.
>
> Signed-off-by: Christian Borntraeger 
> ---
> New version: instead of moving around the graphic and console stuff,
> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>  arch/s390/Kconfig | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index cbe1d978693a..a69690f616f3 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>
>  source "arch/s390/kvm/Kconfig"
>
> +config DUMMY_CONSOLE
> +   bool
> +   depends on VT
> +   default y
> +
>  config S390_GUEST
> def_bool y
> prompt "s390 support for virtio devices"

Really?

You already have your own copy of HAS_IOMEM, which makes it hard for
people to track which one applies where.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] s390/console: enable dummy console for vt

[Christian Borntraeger]

To enable the virtual terminal layer with virtio-gpu, we need to
provide the dummy console. This console is hidden behind CONFIG_IOMEM
via the graphics support. Instead of fully enabling the graphic
drivers lets just provide a Kconfig option for the dummy console.

Signed-off-by: Christian Borntraeger 
---
New version: instead of moving around the graphic and console stuff,
let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
 arch/s390/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index cbe1d978693a..a69690f616f3 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -952,6 +952,11 @@ config S390_HYPFS_FS
 
 source "arch/s390/kvm/Kconfig"
 
+config DUMMY_CONSOLE
+   bool
+   depends on VT
+   default y
+
 config S390_GUEST
def_bool y
prompt "s390 support for virtio devices"
-- 
2.14.3

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

Re: [PATCH v3 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

Hi Geert,

On Thursday, 15 February 2018 11:18:25 EET Geert Uytterhoeven wrote:
> On Thu, Feb 15, 2018 at 1:04 AM, Laurent Pinchart wrote:
> > The internal LVDS encoders now have their own DT bindings. Before
> > switching the driver infrastructure to those new bindings, implement
> > backward-compatibility through live DT patching.
> > 
> > Patching is disabled and will be enabled along with support for the new
> > DT bindings in the DU driver.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> 
> Thanks for your patch!
> 
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
> > @@ -0,0 +1,81 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * rcar_du_of_lvds_r8a7790.dts - Legacy LVDS DT bindings conversion for
> > R8A7790 + *
> > + * Copyright (C) 2018 Laurent Pinchart
> > 
> > + *
> > + * Based on work from Jyri Sarha 
> > + * Copyright (C) 2015 Texas Instruments
> > + */
> > +
> > +#include 
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +/ {
> > +   fragment@0 {
> > +   target-path = "/";
> > +   __overlay__ {
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +
> > +   lvds@feb9 {
> > +   compatible = "renesas,r8a7790-lvds";
> > +   reg = <0 0xfeb9 0 0x1c>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   reg = <0>;
> > +   lvds0_input: endpoint {
> > +   };
> > +   };
> > +   port@1 {
> > +   reg = <1>;
> > +   lvds0_out: endpoint {
> > +   };
> > +   };
> > +   };
> > +   };
> > +
> > +   lvds@feb94000 {
> > +   compatible = "renesas,r8a7790-lvds";
> > +   reg = <0 0xfeb94000 0 0x1c>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   reg = <0>;
> > +   lvds1_input: endpoint {
> > +   };
> > +   };
> > +   port@1 {
> > +   reg = <1>;
> > +   lvds1_out: endpoint {
> > +   };
> > +   };
> > +   };
> > +   };
> > +   };
> > +   };
> > +
> > +   fragment@1 {
> > +   target-path = "/display@feb0/ports";
> 
> Does this work now there can be an "soc" subnode, too?
> 
> Your code obtains the right parent:
> 
> soc_node = of_get_parent(du_node);
> 
> but the overlay is applied without considering that, if I'm not mistaken.

Correct, and as I can't modify the target-path in the overlay dynamically 
anymore, I can't take this into account. I could duplicate the r8a7790 and 
r8a7791 overlays in two versions to handle this, but as the soc subnode isn't 
in mainline yet, I'd rather get this patch series merged with the current 
implementation in v4.17 to not have to handle this issue :-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

An even simpler approach would be:

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index cbe1d978693a..35b7aba4b6a0 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -952,6 +952,10 @@ config S390_HYPFS_FS
 
 source "arch/s390/kvm/Kconfig"
 
+config DUMMY_CONSOLE
+   bool
+   default y
+
 config S390_GUEST
def_bool y
prompt "s390 support for virtio devices"

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

[RFC PATCH v2 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

[Andrzej Hajda]

From: Maciej Purski 

Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.

Signed-off-by: Maciej Purski 
Signed-off-by: Andrzej Hajda 
---
This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.

Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 97 ++--
 1 file changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 9e785b8e0ea2..565cc352ca81 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -81,6 +83,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+   struct extcon_dev *extcon;
+   struct notifier_block extcon_nb;
+   struct work_struct extcon_wq;
+   int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620 
*ctx)
ctx->rc_dev = rc_dev;
 }
 
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+   disable_irq(to_i2c_client(ctx->dev)->irq);
+   sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+   struct sii8620 *ctx =
+   container_of(work, struct sii8620, extcon_wq);
+   int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+   if (state == ctx->cable_state)
+   return;
+
+   ctx->cable_state = state;
+
+   if (state > 0)
+   sii8620_cable_in(ctx);
+   else
+   sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+   unsigned long event, void *ptr)
+{
+   struct sii8620 *ctx =
+   container_of(self, struct sii8620, extcon_nb);
+
+   schedule_work(>extcon_wq);
+
+   return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+   struct extcon_dev *edev;
+   struct device_node *musb, *muic;
+   int ret;
+
+   /* get micro-USB connector node */
+   musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+   /* next get micro-USB Interface Controller node */
+   muic = of_get_next_parent(musb);
+
+   if (!muic) {
+   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
+   return 0;
+   }
+
+   edev = extcon_get_edev_by_of_node(muic);
+   of_node_put(muic);
+   if (IS_ERR(edev)) {
+   if (PTR_ERR(edev) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(ctx->dev, "Invalid or missing extcon\n");
+   return PTR_ERR(edev);
+   }
+
+   ctx->extcon = edev;
+   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+   INIT_WORK(>extcon_wq, sii8620_extcon_work);
+   ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, >extcon_nb);
+   if (ret) {
+   dev_err(ctx->dev, "failed to register notifier for MHL\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
 {
return container_of(bridge, struct sii8620, bridge);
@@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
 
+   ret = sii8620_extcon_init(ctx);
+   if (ret < 0) {
+   dev_err(ctx->dev, "failed to initialize EXTCON\n");
+   return ret;
+   }
+
i2c_set_clientdata(client, ctx);
 
ctx->bridge.funcs = _bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
 
-   sii8620_cable_in(ctx);
+   if (!ctx->extcon)
+   sii8620_cable_in(ctx);
 
return 0;
 }
@@ -2322,8 +2406,15 @@ static int sii8620_remove(struct i2c_client *client)
 {
struct sii8620 *ctx = i2c_get_clientdata(client);
 
-   disable_irq(to_i2c_client(ctx->dev)->irq);
-   sii8620_hw_off(ctx);
+   if (ctx->extcon) {
+   extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL,
+   

[RFC PATCH v2 5/6] extcon: add possibility to get extcon device by OF node

[Andrzej Hajda]

Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.

Signed-off-by: Andrzej Hajda 
Acked-by: Chanwoo Choi 
---
v2: changed label to follow local convention (Chanwoo)
---
 drivers/extcon/extcon.c | 44 ++--
 include/linux/extcon.h  |  6 ++
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..c4972c4cb3bd 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
 #ifdef CONFIG_OF
+
+/*
+ * extcon_get_edev_by_of_node - Get the extcon device from devicetree.
+ * @node   : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   struct extcon_dev *edev;
+
+   mutex_lock(_dev_list_lock);
+   list_for_each_entry(edev, _dev_list, entry)
+   if (edev->dev.parent && edev->dev.parent->of_node == node)
+   goto out;
+   edev = ERR_PTR(-EPROBE_DEFER);
+out:
+   mutex_unlock(_dev_list_lock);
+
+   return edev;
+}
+
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
  * @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
device *dev, int index)
return ERR_PTR(-ENODEV);
}
 
-   mutex_lock(_dev_list_lock);
-   list_for_each_entry(edev, _dev_list, entry) {
-   if (edev->dev.parent && edev->dev.parent->of_node == node) {
-   mutex_unlock(_dev_list_lock);
-   of_node_put(node);
-   return edev;
-   }
-   }
-   mutex_unlock(_dev_list_lock);
+   edev = extcon_get_edev_by_of_node(node);
of_node_put(node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return edev;
 }
+
 #else
+
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
 {
return ERR_PTR(-ENOSYS);
 }
+
 #endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_get_edev_by_of_node);
 EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
 
 /**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 6d94e82c8ad9..b47e0c7f01fe 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
device *dev,
  * Following APIs get the extcon_dev from devicetree or by through extcon name.
  */
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node);
 extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
 int index);
 
@@ -283,6 +284,11 @@ static inline struct extcon_dev 
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
 }
 
+static inline struct extcon_dev *extcon_get_edev_by_of_node(struct device_node 
*node)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
 {
-- 
2.16.1

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