date:20200707

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

--- Comment #49 from Christopher Snowhill (kod...@gmail.com) ---
One possibility that I hadn't considered when I was originally testing this. I
use the GNOME 3 desktop on Arch, and have two monitors, one 3840x2160@60Hz, one
1920x1080@60Hz, both DisplayPort. One thing I haven't enabled since I switched
back from my Nvidia GTX 960 backup card was Variable Refresh Rate, which I had
previously enabled in my Xorg configuration.

I never experienced crashes like these on page flips on my Nvidia card, and am
awaiting a crash any day now on the RX 480, assuming I haven't magically
configured it away with the deletion of that Xorg config snippet which did
nothing but enable VRR.

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

[radeon-alex:amd-staging-drm-next 9971/9999] drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:2280:5: warning: no previous prototype for 'parse_ta_bin_descriptor'

2020-07-07 Thread kernel test robot

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   6b7ad8618edbe6aecf1122e654d08a8237471800
commit: be165aab3d558e3b8573d0e2699c42af5b0f62c8 [9971/] drm/amdgpu: 
updated ta ucode loading
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout be165aab3d558e3b8573d0e2699c42af5b0f62c8
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=alpha 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:2280:5: warning: no previous 
>> prototype for 'parse_ta_bin_descriptor' [-Wmissing-prototypes]
2280 | int parse_ta_bin_descriptor(struct psp_context *psp,
 | ^~~
   In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:29:
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:192:19: warning: 'debug_evictions' 
defined but not used [-Wunused-const-variable=]
 192 | static const bool debug_evictions; /* = false */
 |   ^~~
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:191:18: warning: 'sched_policy' defined 
but not used [-Wunused-const-variable=]
 191 | static const int sched_policy = KFD_SCHED_POLICY_HWS;
 |  ^~~~
   In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:33,
from 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
from 
drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:65,
from drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:29:
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:76:32: warning: 
'dc_fixpt_ln2_div_2' defined but not used [-Wunused-const-variable=]
  76 | static const struct fixed31_32 dc_fixpt_ln2_div_2 = { 1488522236LL };
 |^~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:75:32: warning: 
'dc_fixpt_ln2' defined but not used [-Wunused-const-variable=]
  75 | static const struct fixed31_32 dc_fixpt_ln2 = { 2977044471LL };
 |^~~~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:74:32: warning: 
'dc_fixpt_e' defined but not used [-Wunused-const-variable=]
  74 | static const struct fixed31_32 dc_fixpt_e = { 11674931555LL };
 |^~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:73:32: warning: 
'dc_fixpt_two_pi' defined but not used [-Wunused-const-variable=]
  73 | static const struct fixed31_32 dc_fixpt_two_pi = { 26986075409LL };
 |^~~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:72:32: warning: 
'dc_fixpt_pi' defined but not used [-Wunused-const-variable=]
  72 | static const struct fixed31_32 dc_fixpt_pi = { 13493037705LL };
 |^~~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:67:32: warning: 
'dc_fixpt_zero' defined but not used [-Wunused-const-variable=]
  67 | static const struct fixed31_32 dc_fixpt_zero = { 0 };
 |^

vim +/parse_ta_bin_descriptor +2280 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c

  2279  
> 2280  int parse_ta_bin_descriptor(struct psp_context *psp,
  2281  const struct ta_fw_bin_desc *desc,
  2282  const struct ta_firmware_header_v2_0 
*ta_hdr)
  2283  {
  2284  uint8_t *ucode_start_addr  = NULL;
  2285  
  2286  if (!psp || !desc || !ta_hdr)
  2287  return -EINVAL;
  2288  
  2289  ucode_start_addr  = (uint8_t *)ta_hdr + 
le32_to_cpu(desc->offset_bytes);
  2290  
  2291  switch (desc->fw_type) {
  2292  case TA_FW_TYPE_PSP_ASD:
  2293  psp->asd_fw_version= 
le32_to_cpu(desc->fw_version);
  2294  psp->asd_feature_version   = 
le32_to_cpu(desc->fw_version);
  2295  psp->asd_ucode_size= 
le32_to_cpu(desc->size_bytes);
  2296  psp->asd_start_addr= ucode_start_addr;
  2297  break;
  2298  case TA_FW_TYPE_PSP_XGMI:
  2299  psp->ta_xgmi_ucode_version = 
le32_to_cpu(desc->fw_version);
  2300  psp->ta_xgmi_ucode_size= 
le32_to_cpu(desc->size_bytes);
  2301  psp->ta_xgmi_start_addr= ucode_start_addr;
  2302  break;
  2303  case TA_FW_TYPE_PSP_RAS:
  2304

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

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

--- Comment #48 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to Duncan from comment #47)
> > [I]dea to just try patch-reverting them on top of
> > 5.7 or current 5.8-rc, thus eliminating the apparently unrelated
> > kernel-panics I''ve twice triggered at the current bisect step.
> 
> So I tried this with the 11 above commits against
> 5.8.0-rc4-00025-gbfe91da29, which previously tested as triggering the freeze
> for me.  Of the 11, nine clean-reversed and I simply noted and skipped the
> other two (3202fa62f and 630f289b7) for the moment.  The patched kernel
> successfully built and I'm booted to it now.

Bah, humbug!  Got a freeze and the infamous logged trace on that too!  I was
hoping to demonstrably prove it to be in those nine!  I proved it *NOT* to be!

Well, there's still the two commits to look at that wouldn't cleanly
simple-revert.  Maybe I'll get lucky and it's just an ordering thing, since I
applied out of order compared to original commit, and they'll simple-revert on
top of the others.  Otherwise I'll have to actually look and see if I can make
sense of it and manual revert, maybe/maybe-not for a non-coder, or try on 5.7
instead of 5.8-rc.

If not them, maybe I'll just have to declare defeat on the bisect and hope for
a fix without that.  Last resort there's the buy-my-way-out solution, tho of
course that leaves others without that option in a bind.  But given the hours
I've put into this (that I've only been able to thanks to COVID work
suspension), at some point you just gotta cut your losses and declare defeat
defeat.

But we're not there yet.  There's still the two to look at first, and the
middle-ground 5.7 to try all 11 against.  Hopefully...

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

Re: [PATCH 12/25] drm/rcar-du: Annotate dma-fence critical section in commit path

2020-07-07 Thread Laurent Pinchart

Hi Daniel,

Thank you for the patch.

On Tue, Jul 07, 2020 at 10:12:16PM +0200, Daniel Vetter wrote:
> Ends right after drm_atomic_helper_commit_hw_done(), absolutely
> nothing fancy going on here.

Just looking at this patch and the commit message, I have no idea what
this does, and why. It would be nice to expand the commit message to
give some more context, and especially explain why ending signalling
right after drm_atomic_helper_commit_hw_done() is the right option.

I suppose I'll have to check the whole series in the meantime :-)

> Signed-off-by: Daniel Vetter 
> Cc: Laurent Pinchart 
> Cc: Kieran Bingham 
> Cc: linux-renesas-...@vger.kernel.org
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 482329102f19..42c5dc588435 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -391,6 +391,7 @@ static void rcar_du_atomic_commit_tail(struct 
> drm_atomic_state *old_state)
>   struct drm_crtc_state *crtc_state;
>   struct drm_crtc *crtc;
>   unsigned int i;
> + bool fence_cookie = dma_fence_begin_signalling();

Can this be moved right before the
drm_atomic_helper_commit_modeset_disables() call ?

>  
>   /*
>* Store RGB routing to DPAD0 and DPAD1, the hardware will be configured
> @@ -417,6 +418,7 @@ static void rcar_du_atomic_commit_tail(struct 
> drm_atomic_state *old_state)
>   drm_atomic_helper_commit_modeset_enables(dev, old_state);
>  
>   drm_atomic_helper_commit_hw_done(old_state);
> + dma_fence_end_signalling(fence_cookie);
>   drm_atomic_helper_wait_for_flip_done(dev, old_state);
>  
>   drm_atomic_helper_cleanup_planes(dev, old_state);

-- 
Regards,

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/mst: filter out the display mode exceed sink's capability

2020-07-07 Thread Imre Deak

On Tue, May 26, 2020 at 02:23:10PM -0400, Lyude Paul wrote:
> From: Lee Shawn C 
> 
> So far, max dot clock rate for MST mode rely on physcial
> bandwidth limitation. It would caused compatibility issue
> if source display resolution exceed MST hub output ability.
> 
> For example, source DUT had DP 1.2 output capability.
> And MST docking just support HDMI 1.4 spec. When a HDMI 2.0
> monitor connected. Source would retrieve EDID from external
> and get max resolution 4k@60fps. DP 1.2 can support 4K@60fps
> because it did not surpass DP physical bandwidth limitation.
> Do modeset to 4k@60fps, source output display data but MST
> docking can't output HDMI properly due to this resolution
> already over HDMI 1.4 spec.
> 
> Refer to commit  ("drm/dp_mst: Use full_pbn
> instead of available_pbn for bandwidth checks").
> Source driver should refer to full_pbn to evaluate sink
> output capability. And filter out the resolution surpass
> sink output limitation.
> 
> v2: Using mgr->base.lock to protect full_pbn.
> v3: Add ctx lock.
> v4:
> * s/intel_dp_mst_mode_clock_exceed_pbn_bandwidth/
>   intel_dp_mst_mode_clock_exceeds_pbn_bw/
> * Use the new drm_connector_helper_funcs.mode_valid_ctx to properly pipe
>   down the drm_modeset_acquire_ctx that the probe helpers are using, so
>   we can safely grab >base.lock without deadlocking
> 
> Cc: Manasi Navare 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Cooper Chiou 
> Co-developed-by: Lyude Paul 
> Signed-off-by: Lee Shawn C 
> Tested-by: Lee Shawn C 
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 39 ++---
>  1 file changed, 35 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index d18b406f2a7d2..cf052095ad785 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -610,15 +610,42 @@ static int intel_dp_mst_get_modes(struct drm_connector 
> *connector)
>   return intel_dp_mst_get_ddc_modes(connector);
>  }
>  
> +static int
> +intel_dp_mst_mode_clock_exceeds_pbn_bw(struct drm_connector *connector,
> +struct drm_modeset_acquire_ctx *ctx,
> +int clock, int bpp)
> +{
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> + struct intel_dp *intel_dp = intel_connector->mst_port;
> + struct drm_dp_mst_topology_mgr *mgr = _dp->mst_mgr;
> + struct drm_dp_mst_port *port = (to_intel_connector(connector))->port;

intel_connector

> + int ret = MODE_OK;
> +
> + if (!mgr)

As a NULL check this would be bogus, but also connector->mst_port and so
mst_mgr too should be always non-NULL?

> + return ret;
> +
> + ret = drm_modeset_lock(>base.lock, ctx);
> + if (ret == -EDEADLK)
> + return ret;
> +
> + if (port->full_pbn &&

How could full_pbn be unset?

> + drm_dp_calc_pbn_mode(clock, bpp, false) > port->full_pbn)
> + ret = MODE_CLOCK_HIGH;
> +
> + return ret;
> +}
> +
>  static enum drm_mode_status
> -intel_dp_mst_mode_valid(struct drm_connector *connector,
> - struct drm_display_mode *mode)
> +intel_dp_mst_mode_valid_ctx(struct drm_connector *connector,
> + struct drm_display_mode *mode,
> + struct drm_modeset_acquire_ctx *ctx)
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->dev);
>   struct intel_connector *intel_connector = to_intel_connector(connector);
>   struct intel_dp *intel_dp = intel_connector->mst_port;
>   int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
>   int max_rate, mode_rate, max_lanes, max_link_clock;
> + int ret;
>  
>   if (drm_connector_is_unregistered(connector))
>   return MODE_ERROR;
> @@ -632,7 +659,11 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
>   max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
>   mode_rate = intel_dp_link_required(mode->clock, 18);
>  
> - /* TODO - validate mode against available PBN for link */
> + ret = intel_dp_mst_mode_clock_exceeds_pbn_bw(connector, ctx,
> +  mode->clock, 24);

Why 24 bpp and not 18?

Nit: could be checked after max_rate/max_dotclk for consistency.

> + if (ret != MODE_OK)
> + return ret;
> +
>   if (mode->clock < 1)
>   return MODE_CLOCK_LOW;
>  
> @@ -671,7 +702,7 @@ intel_dp_mst_detect(struct drm_connector *connector,
>  
>  static const struct drm_connector_helper_funcs 
> intel_dp_mst_connector_helper_funcs = {
>   .get_modes = intel_dp_mst_get_modes,
> - .mode_valid = intel_dp_mst_mode_valid,
> + .mode_valid_ctx = intel_dp_mst_mode_valid_ctx,
>   .atomic_best_encoder = intel_mst_atomic_best_encoder,
>

Re: [PATCH v3 8/9] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api

Hi, Dennis:

Dennis YC Hsieh  於 2020年7月7日 週二 下午11:47寫道：
>
> Add clear parameter to let client decide if
> event should be clear to 0 after GCE receive it.

For DRM part,

Acked-by: Chun-Kuang Hu 

>
> Change since v2:
> - Keep behavior in drm crtc driver and
>   separate bug fix code into another patch.
>
> Signed-off-by: Dennis YC Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c  |2 +-
>  drivers/soc/mediatek/mtk-cmdq-helper.c   |5 +++--
>  include/linux/mailbox/mtk-cmdq-mailbox.h |3 +--
>  include/linux/soc/mediatek/mtk-cmdq.h|5 +++--
>  4 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index ec6c9ffbf35e..c84e7a14d4a8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -490,7 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc 
> *mtk_crtc)
> mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
> cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, 
> PAGE_SIZE);
> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> -   cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> +   cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, true);
> mtk_crtc_ddp_config(crtc, cmdq_handle);
> cmdq_pkt_finalize(cmdq_handle);
> cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index d55dc3296105..505651b0d715 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -316,15 +316,16 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, 
> u8 high_addr_reg_idx,
>  }
>  EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
>
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear)
>  {
> struct cmdq_instruction inst = { {0} };
> +   u32 clear_option = clear ? CMDQ_WFE_UPDATE : 0;
>
> if (event >= CMDQ_MAX_EVENT)
> return -EINVAL;
>
> inst.op = CMDQ_CODE_WFE;
> -   inst.value = CMDQ_WFE_OPTION;
> +   inst.value = CMDQ_WFE_OPTION | clear_option;
> inst.event = event;
>
> return cmdq_pkt_append_command(pkt, inst);
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index efbd8a9eb2d1..d5a983d65f05 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -28,8 +28,7 @@
>   * bit 16-27: update value
>   * bit 31: 1 - update, 0 - no update
>   */
> -#define CMDQ_WFE_OPTION(CMDQ_WFE_UPDATE | 
> CMDQ_WFE_WAIT | \
> -   CMDQ_WFE_WAIT_VALUE)
> +#define CMDQ_WFE_OPTION(CMDQ_WFE_WAIT | 
> CMDQ_WFE_WAIT_VALUE)
>
>  /** cmdq event maximum */
>  #define CMDQ_MAX_EVENT 0x3ff
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 34354e952f60..960704d75994 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -182,11 +182,12 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, 
> u8 high_addr_reg_idx,
>  /**
>   * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
>   * @pkt:   the CMDQ packet
> - * @event: the desired event type to "wait and CLEAR"
> + * @event: the desired event type to wait
> + * @clear: clear event or not after event arrive
>   *
>   * Return: 0 for success; else the error code is returned
>   */
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
>
>  /**
>   * cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
> --
> 1.7.9.5
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 9/9] drm/mediatek: reduce clear event

Hi, Dennis:

Dennis YC Hsieh  於 2020年7月7日 週二 下午11:47寫道：
>
> No need to clear event again since event always clear before wait.
> This fix depend on patch:
>   "soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api"

Acked-by: Chun-Kuang Hu 

>
> Fixes: 2f965be7f9008 ("drm/mediatek: apply CMDQ control flow")
> Signed-off-by: Dennis YC Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index c84e7a14d4a8..ba6cf956b239 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -490,7 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc 
> *mtk_crtc)
> mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
> cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, 
> PAGE_SIZE);
> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> -   cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, true);
> +   cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
> mtk_crtc_ddp_config(crtc, cmdq_handle);
> cmdq_pkt_finalize(cmdq_handle);
> cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
> --
> 1.7.9.5
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx

2020-07-07 Thread Imre Deak

Sorry for the delay, the review as I promised:

On Tue, May 26, 2020 at 02:23:09PM -0400, Lyude Paul wrote:
> This is just an atomic version of mode_valid, which is intended to be
> used for situations where a driver might need to check the atomic state
> of objects other than the connector itself. One such example is with
> MST, where the maximum possible bandwidth on a connector can change
> dynamically irregardless of the display configuration.
> 
> Signed-off-by: Lyude Paul 
> Cc: Lee Shawn C 
> Tested-by: Lee Shawn C 
> ---
>  drivers/gpu/drm/drm_crtc_helper_internal.h |  6 +-
>  drivers/gpu/drm/drm_probe_helper.c | 65 ++
>  include/drm/drm_modeset_helper_vtables.h   | 41 ++
>  3 files changed, 88 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h 
> b/drivers/gpu/drm/drm_crtc_helper_internal.h
> index f0a66ef47e5ad..ca767cba6094d 100644
> --- a/drivers/gpu/drm/drm_crtc_helper_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
> @@ -73,8 +73,10 @@ enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc 
> *crtc,
>const struct drm_display_mode *mode);
>  enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
>   const struct drm_display_mode 
> *mode);
> -enum drm_mode_status drm_connector_mode_valid(struct drm_connector 
> *connector,
> -   struct drm_display_mode *mode);
> +enum drm_mode_status
> +drm_connector_mode_valid(struct drm_connector *connector,
> +  struct drm_display_mode *mode,
> +  struct drm_modeset_acquire_ctx *ctx);
>  
>  struct drm_encoder *
>  drm_connector_get_single_encoder(struct drm_connector *connector);
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 466dfbba82564..3132784736841 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -86,16 +86,17 @@ drm_mode_validate_flag(const struct drm_display_mode 
> *mode,
>   return MODE_OK;
>  }
>  
> -static enum drm_mode_status
> +static int
>  drm_mode_validate_pipeline(struct drm_display_mode *mode,
> - struct drm_connector *connector)
> +struct drm_connector *connector,
> +struct drm_modeset_acquire_ctx *ctx)
>  {
>   struct drm_device *dev = connector->dev;
> - enum drm_mode_status ret = MODE_OK;
>   struct drm_encoder *encoder;
> + int ret = MODE_OK;
>  
>   /* Step 1: Validate against connector */
> - ret = drm_connector_mode_valid(connector, mode);
> + ret = drm_connector_mode_valid(connector, mode, ctx);
>   if (ret != MODE_OK)
>   return ret;
>  
> @@ -196,16 +197,23 @@ enum drm_mode_status drm_encoder_mode_valid(struct 
> drm_encoder *encoder,
>   return encoder_funcs->mode_valid(encoder, mode);
>  }
>  
> -enum drm_mode_status drm_connector_mode_valid(struct drm_connector 
> *connector,
> -   struct drm_display_mode *mode)
> +int
> +drm_connector_mode_valid(struct drm_connector *connector,
> +  struct drm_display_mode *mode,
> +  struct drm_modeset_acquire_ctx *ctx)
>  {
>   const struct drm_connector_helper_funcs *connector_funcs =
>   connector->helper_private;
>  
> - if (!connector_funcs || !connector_funcs->mode_valid)
> + if (!connector_funcs)
>   return MODE_OK;
>  
> - return connector_funcs->mode_valid(connector, mode);
> + if (connector_funcs->mode_valid_ctx)
> + return connector_funcs->mode_valid_ctx(connector, mode, ctx);
> + else if (connector_funcs->mode_valid)
> + return connector_funcs->mode_valid(connector, mode);
> + else
> + return MODE_OK;
>  }
>  
>  #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
> @@ -375,8 +383,9 @@ EXPORT_SYMBOL(drm_helper_probe_detect);
>   *  (if specified)
>   *- drm_mode_validate_flag() checks the modes against basic connector
>   *  capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
> - *- the optional _connector_helper_funcs.mode_valid helper can 
> perform
> - *  driver and/or sink specific checks
> + *- the optional _connector_helper_funcs.mode_valid or
> + *  _connector_helper_funcs.mode_valid_ctx helpers can perform driver
> + *  and/or sink specific checks
>   *- the optional _crtc_helper_funcs.mode_valid,
>   *  _bridge_funcs.mode_valid and _encoder_helper_funcs.mode_valid
>   *  helpers can perform driver and/or source specific checks which are 
> also
> @@ -507,22 +516,34 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>   mode_flags |= DRM_MODE_FLAG_3D_MASK;
>  
>   list_for_each_entry(mode, >modes, head) {
> -

RE: [RFC PATCH v2 0/3] RDMA: add dma-buf support

2020-07-07 Thread Xiong, Jianxin


> -Original Message-
> From: Christian König 
> Am 03.07.20 um 15:14 schrieb Jason Gunthorpe:
> > On Fri, Jul 03, 2020 at 02:52:03PM +0200, Daniel Vetter wrote:
> >
> >> So maybe I'm just totally confused about the rdma model. I thought:
> >> - you bind a pile of memory for various transactions, that might
> >> happen whenever. Kernel driver doesn't have much if any insight into
> >> when memory isn't needed anymore. I think in the rdma world that's
> >> called registering memory, but not sure.
> > Sure, but once registered the memory is able to be used at any moment
> > with no visibilty from the kernel.
> >
> > Unlike GPU the transactions that trigger memory access do not go
> > through the kernel - so there is no ability to interrupt a command
> > flow and fiddle with mappings.
> 
> This is the same for GPUs with user space queues as well.
> 
> But we can still say for a process if that this process is using a DMA-buf 
> which is moved out and so can't run any more unless the DMA-buf is
> accessible again.
> 
> In other words you somehow need to make sure that the hardware is not 
> accessing a piece of memory any more when you want to move it.
> 

While a process can be easily suspended, there is no way to tell the RDMA NIC 
not to process posted work requests that use specific memory regions (or with 
any other conditions). 

So far it appears to me that DMA-buf dynamic mapping for RDMA is only viable 
with ODP support. For NICs without ODP, a way to allow pinning the device 
memory is still needed.

Jianxin

> Christian.
> 
> >
> > Jason

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

Re: [PATCH v4 20/20] backlight: make of_find_backlight_by_node() static

2020-07-07 Thread kernel test robot

Hi Sam,

I love your patch! Yet something to improve:

[auto build test ERROR on backlight/for-backlight-next]
[also build test ERROR on tegra-drm/drm/tegra/for-next pwm/for-next 
linus/master v5.8-rc4]
[cannot apply to next-20200707]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Sam-Ravnborg/backlight-backlight-updates/20200704-024949
base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git 
for-backlight-next
config: arm-randconfig-r034-20200707 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/tilcdc/tilcdc_panel.c: In function 'panel_probe':
>> drivers/gpu/drm/tilcdc/tilcdc_panel.c:320:26: error: implicit declaration of 
>> function 'of_find_backlight_by_node'; did you mean 
>> 'of_find_i2c_adapter_by_node'? [-Werror=implicit-function-declaration]
 320 |   panel_mod->backlight = of_find_backlight_by_node(bl_node);
 |  ^
 |  of_find_i2c_adapter_by_node
>> drivers/gpu/drm/tilcdc/tilcdc_panel.c:320:24: error: assignment to 'struct 
>> backlight_device *' from 'int' makes pointer from integer without a cast 
>> [-Werror=int-conversion]
 320 |   panel_mod->backlight = of_find_backlight_by_node(bl_node);
 |^
   cc1: all warnings being treated as errors

vim +320 drivers/gpu/drm/tilcdc/tilcdc_panel.c

0d4bbaf9f3e5b9 Rob Clark2012-12-18  299  
0d4bbaf9f3e5b9 Rob Clark2012-12-18  300  static int panel_probe(struct 
platform_device *pdev)
0d4bbaf9f3e5b9 Rob Clark2012-12-18  301  {
18c44db8cafe9b Ezequiel Garcia  2014-09-02  302 struct device_node 
*bl_node, *node = pdev->dev.of_node;
0d4bbaf9f3e5b9 Rob Clark2012-12-18  303 struct panel_module 
*panel_mod;
0d4bbaf9f3e5b9 Rob Clark2012-12-18  304 struct tilcdc_module 
*mod;
0d4bbaf9f3e5b9 Rob Clark2012-12-18  305 struct pinctrl *pinctrl;
12778fc14301cf Ezequiel Garcia  2014-09-02  306 int ret;
0d4bbaf9f3e5b9 Rob Clark2012-12-18  307  
0d4bbaf9f3e5b9 Rob Clark2012-12-18  308 /* bail out early if no 
DT data: */
0d4bbaf9f3e5b9 Rob Clark2012-12-18  309 if (!node) {
0d4bbaf9f3e5b9 Rob Clark2012-12-18  310 
dev_err(>dev, "device-tree data is missing\n");
0d4bbaf9f3e5b9 Rob Clark2012-12-18  311 return -ENXIO;
0d4bbaf9f3e5b9 Rob Clark2012-12-18  312 }
0d4bbaf9f3e5b9 Rob Clark2012-12-18  313  
971645d1fd734b Ezequiel Garcia  2014-09-02  314 panel_mod = 
devm_kzalloc(>dev, sizeof(*panel_mod), GFP_KERNEL);
0d4bbaf9f3e5b9 Rob Clark2012-12-18  315 if (!panel_mod)
0d4bbaf9f3e5b9 Rob Clark2012-12-18  316 return -ENOMEM;
0d4bbaf9f3e5b9 Rob Clark2012-12-18  317  
18c44db8cafe9b Ezequiel Garcia  2014-09-02  318 bl_node = 
of_parse_phandle(node, "backlight", 0);
18c44db8cafe9b Ezequiel Garcia  2014-09-02  319 if (bl_node) {
18c44db8cafe9b Ezequiel Garcia  2014-09-02 @320 
panel_mod->backlight = of_find_backlight_by_node(bl_node);
18c44db8cafe9b Ezequiel Garcia  2014-09-02  321 
of_node_put(bl_node);
18c44db8cafe9b Ezequiel Garcia  2014-09-02  322  
18c44db8cafe9b Ezequiel Garcia  2014-09-02  323 if 
(!panel_mod->backlight)
18c44db8cafe9b Ezequiel Garcia  2014-09-02  324 return 
-EPROBE_DEFER;
18c44db8cafe9b Ezequiel Garcia  2014-09-02  325  
18c44db8cafe9b Ezequiel Garcia  2014-09-02  326 
dev_info(>dev, "found backlight\n");
18c44db8cafe9b Ezequiel Garcia  2014-09-02  327 }
18c44db8cafe9b Ezequiel Garcia  2014-09-02  328  
26a5bd26499fba Uwe Kleine-König 2015-02-11  329 panel_mod->enable_gpio 
= devm_gpiod_get_optional(>dev, "enable",
26a5bd26499fba Uwe Kleine-König 2015-02-11  330 
 GPIOD_OUT_LOW);
d898ce03675fc0 Ezequiel Garcia  2014-09-02  331 if 
(IS_ERR(panel_mod->enable_gpio)) {
d898ce03675fc0 Ezequiel Garcia  2014-09-02  332 ret = 
PTR_ERR(panel_mod->enable_gpio);
d898ce03675fc0 Ezequiel Garcia  2014-09-02

[PATCH] drm/atmel: Use drm_atomic_helper_commit

One of these drivers that predates the nonblocking support in helpers,
and hand-rolled its own thing. Entirely not anything specific here, we
can just delete it all and replace it with the helper version.

Could also perhaps use the drm_mode_config_helper_suspend/resume
stuff, for another few lines deleted. But I'm not looking at that
stuff, I'm just going through all the atomic commit functions and make
sure they have properly annotated dma-fence critical sections
everywhere.

v2:
- Also delete the workqueue (Sam)
- drop the @commit kerneldoc, I missed that one.

Signed-off-by: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Boris Brezillon 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Ludovic Desroches 
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 107 +--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h |   7 --
 2 files changed, 2 insertions(+), 112 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 871293d1aeeb..03984932d174 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -557,103 +557,10 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq, 
void *data)
return IRQ_HANDLED;
 }
 
-struct atmel_hlcdc_dc_commit {
-   struct work_struct work;
-   struct drm_device *dev;
-   struct drm_atomic_state *state;
-};
-
-static void
-atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit)
-{
-   struct drm_device *dev = commit->dev;
-   struct atmel_hlcdc_dc *dc = dev->dev_private;
-   struct drm_atomic_state *old_state = commit->state;
-
-   /* Apply the atomic update. */
-   drm_atomic_helper_commit_modeset_disables(dev, old_state);
-   drm_atomic_helper_commit_planes(dev, old_state, 0);
-   drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
-   drm_atomic_helper_wait_for_vblanks(dev, old_state);
-
-   drm_atomic_helper_cleanup_planes(dev, old_state);
-
-   drm_atomic_state_put(old_state);
-
-   /* Complete the commit, wake up any waiter. */
-   spin_lock(>commit.wait.lock);
-   dc->commit.pending = false;
-   wake_up_all_locked(>commit.wait);
-   spin_unlock(>commit.wait.lock);
-
-   kfree(commit);
-}
-
-static void atmel_hlcdc_dc_atomic_work(struct work_struct *work)
-{
-   struct atmel_hlcdc_dc_commit *commit =
-   container_of(work, struct atmel_hlcdc_dc_commit, work);
-
-   atmel_hlcdc_dc_atomic_complete(commit);
-}
-
-static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev,
-   struct drm_atomic_state *state,
-   bool async)
-{
-   struct atmel_hlcdc_dc *dc = dev->dev_private;
-   struct atmel_hlcdc_dc_commit *commit;
-   int ret;
-
-   ret = drm_atomic_helper_prepare_planes(dev, state);
-   if (ret)
-   return ret;
-
-   /* Allocate the commit object. */
-   commit = kzalloc(sizeof(*commit), GFP_KERNEL);
-   if (!commit) {
-   ret = -ENOMEM;
-   goto error;
-   }
-
-   INIT_WORK(>work, atmel_hlcdc_dc_atomic_work);
-   commit->dev = dev;
-   commit->state = state;
-
-   spin_lock(>commit.wait.lock);
-   ret = wait_event_interruptible_locked(dc->commit.wait,
- !dc->commit.pending);
-   if (ret == 0)
-   dc->commit.pending = true;
-   spin_unlock(>commit.wait.lock);
-
-   if (ret)
-   goto err_free;
-
-   /* We have our own synchronization through the commit lock. */
-   BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
-
-   /* Swap state succeeded, this is the point of no return. */
-   drm_atomic_state_get(state);
-   if (async)
-   queue_work(dc->wq, >work);
-   else
-   atmel_hlcdc_dc_atomic_complete(commit);
-
-   return 0;
-
-err_free:
-   kfree(commit);
-error:
-   drm_atomic_helper_cleanup_planes(dev, state);
-   return ret;
-}
-
 static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
-   .atomic_commit = atmel_hlcdc_dc_atomic_commit,
+   .atomic_commit = drm_atomic_helper_commit,
 };
 
 static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
@@ -712,11 +619,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
if (!dc)
return -ENOMEM;
 
-   dc->wq = alloc_ordered_workqueue("atmel-hlcdc-dc", 0);
-   if (!dc->wq)
-   return -ENOMEM;
-
-   init_waitqueue_head(>commit.wait);
dc->desc = match->data;
dc->hlcdc = dev_get_drvdata(dev->dev->parent);
dev->dev_private = dc;
@@ -724,7 +626,7 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
ret =

[Bug 208489] New: amdgpu: kernel oops when overclocking Vega M GPU (i7-8809G)

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

Bug ID: 208489
   Summary: amdgpu: kernel oops when overclocking Vega M GPU
(i7-8809G)
   Product: Drivers
   Version: 2.5
Kernel Version: 5.7.7
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: crab2...@gmail.com
Regression: No

Created attachment 290165
  --> https://bugzilla.kernel.org/attachment.cgi?id=290165=edit
full kernel dmesg

CPU: Intel(R) Core(TM) i7-8809G CPU @ 3.10GHz
Intel Hades Canyon NUC Kit


❯ cat /sys/bus/pci/drivers/amdgpu/:01:00.0/pp_od_clk_voltage
OD_SCLK:
0:225MHz750mV
1:400MHz750mV
2:535MHz750mV
3:715MHz750mV
4:960MHz750mV
5:   1080MHz750mV
6:   1140MHz750mV
7:   1250MHz750mV
OD_MCLK:
0:300MHz750mV
1:500MHz750mV
2:800MHz800mV
OD_RANGE:
SCLK: 225MHz   1600MHz
MCLK: 300MHz   1000MHz
VDDC: 750mV 750mV

After doing this:

#!/bin/sh
sudo sh -c "echo 's 7 1250 750' >
/sys/devices/pci:00/:00:01.0/:01:00.0/pp_od_clk_voltage"
sudo sh -c "echo 'c' >
/sys/devices/pci:00/:00:01.0/:01:00.0/pp_od_clk_voltage"

kernel oops with the dmesg.


[4.932714] Bluetooth: RFCOMM TTY layer initialized
[4.932722] Bluetooth: RFCOMM socket layer initialized
[4.932725] Bluetooth: RFCOMM ver 1.11
[9.120298] rfkill: input handler enabled
[9.922018] fuse: init (API version 7.31)
[   10.492078] rfkill: input handler disabled
[   12.680512] wlp6s0: authenticate with 50:d2:f5:f1:12:ed
[   12.690803] wlp6s0: send auth to 50:d2:f5:f1:12:ed (try 1/3)
[   12.728470] wlp6s0: authenticated
[   12.728864] wlp6s0: associate with 50:d2:f5:f1:12:ed (try 1/3)
[   12.759696] wlp6s0: RX AssocResp from 50:d2:f5:f1:12:ed (capab=0x31 status=0
aid=2)
[   12.762966] wlp6s0: associated
[   13.100624] IPv6: ADDRCONF(NETDEV_CHANGE): wlp6s0: link becomes ready
[  606.958453] BUG: unable to handle page fault for address: 9032a4c849a4
[  606.958455] #PF: supervisor read access in kernel mode
[  606.958456] #PF: error_code(0x) - not-present page
[  606.958457] PGD 173c01067 P4D 173c01067 PUD 0 
[  606.958459] Oops:  [#1] PREEMPT SMP PTI
[  606.958460] CPU: 7 PID: 2337 Comm: bash Not tainted 5.7.7-zen1-1-zen #1
[  606.958461] Hardware name: Intel Corporation NUC8i7HVK/NUC8i7HVB, BIOS
HNKBLi70.86A.0054.2019.0214.1350 02/14/2019
[  606.958528] RIP: 0010:phm_find_closest_vddci+0x3b/0x60 [amdgpu]
[  606.958529] Code: c0 eb 09 48 83 c0 01 48 39 d0 74 19 44 0f b7 44 c3 0c 89
c5 66 41 39 f0 72 e9 44 89 c0 5b 5d c3 bd ff ff ff ff 0f 1f 44 00 00 <44> 0f b7
44 eb 0c 5b 5d 44 89 c0 c3 48 c7 c6 f0 c1 96 c0 48 c7 c7
[  606.958530] RSP: 0018:a3ecc18ff948 EFLAGS: 00010246
[  606.958531] RAX: 02ee RBX: 902aa4c849a0 RCX:
0008
[  606.958532] RDX:  RSI: 0226 RDI:
902aa4c849a0
[  606.958532] RBP:  R08: a3ecc18ff9d4 R09:
0029
[  606.958533] R10: e401 R11:  R12:
902aa6861600
[  606.958534] R13: 902aa4c84000 R14: 902aa4c85301 R15:
a3ecc18ff9d4
[  606.958534] FS:  7fe8233c0b80() GS:902aaedc()
knlGS:
[  606.958535] CS:  0010 DS:  ES:  CR0: 80050033
[  606.958536] CR2: 9032a4c849a4 CR3: 000467468005 CR4:
003606e0
[  606.958536] Call Trace:
[  606.958587]  vegam_get_dependency_volt_by_clk.isra.0+0x8e/0x220 [amdgpu]
[  606.958637]  vegam_populate_all_graphic_levels+0x26a/0x960 [amdgpu]
[  606.958686]  smu7_set_power_state_tasks+0x77c/0x12b0 [amdgpu]
[  606.958734]  phm_set_power_state+0x5a/0x80 [amdgpu]
[  606.958784]  psm_adjust_power_state_dynamic+0xca/0x1d0 [amdgpu]
[  606.958831]  hwmgr_handle_task+0x49/0xf0 [amdgpu]
[  606.958882]  pp_dpm_dispatch_tasks+0x3a/0x60 [amdgpu]
[  606.958915]  amdgpu_set_pp_od_clk_voltage+0x3cb/0x490 [amdgpu]
[  606.958921]  kernfs_fop_write+0xce/0x1b0
[  606.958923]  vfs_write+0x10a/0x420
[  606.958925]  __x64_sys_write+0x6d/0xf0
[  606.958926]  do_syscall_64+0x4e/0x160
[  606.958928]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  606.958930] RIP: 0033:0x7fe823523b57
[  606.958931] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00
f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[  606.958931] RSP: 002b:7ffea3ba5e88 EFLAGS: 0246 ORIG_RAX:
0001
[  606.958932] RAX: ffda RBX: 0002 RCX:
7fe823523b57
[  606.958933] RDX: 0002 RSI: 5648e5dda620 RDI:
0001
[  606.958934] RBP:

Re: Panic booting qemu-system-sparc64 with bochs_drm

2020-07-07 Thread Mark Cave-Ayland

On 07/07/2020 20:52, Sam Ravnborg wrote:

> Hi Gerd.
> 
> On Tue, Jul 07, 2020 at 09:03:41AM +0200, Gerd Hoffmann wrote:
>>> Yes, that's correct - I can confirm that the simplified diff below works:
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index 5609e164805f..83af05fac604 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct 
>>> drm_fb_helper
>>> *fb_helper,
>>> unsigned int y;
>>>
>>> for (y = clip->y1; y < clip->y2; y++) {
>>> -   memcpy(dst, src, len);
>>> +   fb_memcpy_tofb(dst, src, len);
>>
>> fb_memcpy_tofb is #defined to sbus_memcpy_toio @ sparc which looks
>> wrong to me given that this is a pci not a sbus device.  sparc also has
>> memcpy_toio which looks better to me.
> Looked at sbus_memcpy_toio and memcpy_toio for sparc64.
> They are essential the same. Only read bytes in little-endian format,
> the other read bytes in big-endian format. So thats the same.
> 
> I will prepare a proper patch with focus on fixin sparc64 only.

Thanks Sam! If you want to add me as a CC then I'm happy to test if needed.

>> There are blit helpers in drm_format_helper.c which already use
>> memcpy_toio(), I guess we should do the same here.  Not fully sure we
>> can use memcpy_toio() unconditionally here.  Given that a shadow
>> framebuffer makes sense only in case the real framebuffer is not in
>> normal ram we probably can.
> Not so sure about this part.
> We unconditionally enable the use of a shadow framebuffer.
> But on some archs the framebuffer is not in io space - but then
> on these architectures memcpy_toio boils down to a simple memcpy.
> So maybe in the end everything is fine.

I'm afraid this part is beyond my current knowledge of the various framebuffer
implementations within the kernel :/


ATB,

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

Re: [PATCH v2 14/14] phy/rockchip: inno-hdmi: Support more pre-pll configuration

2020-07-07 Thread Jonas Karlman

On 2020-07-07 21:53, Johan Jonker wrote:
> 
> Hi,
> 
> What's the status for this patch?
> This is just what I needed for A95X Z2 to get the vop+hdmi and monitor
> working. ;)
> 
> Could this become applied to mainline already?
> The ack is already there.

I will send a v3 of the phy/rockchip parts of this series later 
tonight/tomorrow.

The drm side still need work and I have some pending patches that also
improve rk3288/rk3399 hdmi support for up to 4k@30hz, should make its way
onto the list in a few days.

Regards,
Jonas

> 
> Thanks,
> 
> Johan Jonker
> 
> https://lore.kernel.org/lkml/20200620134659.4592-1-jbx6...@gmail.com/
> 
> On 1/8/20 10:07 PM, Jonas Karlman wrote:
>> From: Algea Cao 
>>
>> Adding the following freq cfg in 8-bit and 10-bit color depth:
>>
>> {
>>   4000,  6500,  7100,  8350, 8575,
>>   8875, 10800, 11900, 16200
>> }
>>
>> New freq has been validated by quantumdata 980.
>>
>> For some freq which can't be got by only using integer freq div,
>> frac freq div is needed, Such as 88.75Mhz 10-bit. But The actual
>> freq is different from the target freq, We must try to narrow
>> the gap between them. RK322X only support integer freq div.
>>
>> The VCO of pre-PLL must be more than 2Ghz, otherwise PLL may be
>> unlocked.
>>
>> Signed-off-by: Algea Cao 
>> Signed-off-by: Jonas Karlman 
>> Acked-by: Heiko Stuebner 
>> ---
>>  drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 74 ---
>>  1 file changed, 49 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c 
>> b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
>> index 3719309ad0d0..bb8bdf5e3301 100644
>> --- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
>> +++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
>> @@ -291,32 +291,56 @@ struct inno_hdmi_phy_drv_data {
>>  const struct phy_config *phy_cfg_table;
>>  };
>>  
>> +/*
>> + * If only using integer freq div can't get frequency we want, frac
>> + * freq div is needed. For example, pclk 88.75 Mhz and tmdsclk
>> + * 110.9375 Mhz must use frac div 0xF0. The actual frequency is 
>> different
>> + * from the target frequency. Such as the tmds clock 110.9375 Mhz,
>> + * the actual tmds clock we get is 110.93719 Mhz. It is important
>> + * to note that RK322X platforms do not support frac div.
>> + */
>>  static const struct pre_pll_config pre_pll_cfg_table[] = {
>> -{ 2700,  2700, 1,  90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
>> -{ 2700,  3375, 1,  90, 1, 3, 3, 10, 3, 3, 4, 0, 0},
>> -{ 4000,  4000, 1,  80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
>> -{ 59341000,  59341000, 1,  98, 3, 1, 2,  1, 3, 3, 4, 0, 0xE6AE6B},
>> -{ 5940,  5940, 1,  99, 3, 1, 1,  1, 3, 3, 4, 0, 0},
>> -{ 59341000,  74176250, 1,  98, 0, 3, 3,  1, 3, 3, 4, 0, 0xE6AE6B},
>> -{ 5940,  7425, 1,  99, 1, 2, 2,  1, 3, 3, 4, 0, 0},
>> -{ 74176000,  74176000, 1,  98, 1, 2, 2,  1, 2, 3, 4, 0, 0xE6AE6B},
>> -{ 7425,  7425, 1,  99, 1, 2, 2,  1, 2, 3, 4, 0, 0},
>> -{ 74176000,  9272, 4, 494, 1, 2, 2,  1, 3, 3, 4, 0, 0x816817},
>> -{ 7425,  92812500, 4, 495, 1, 2, 2,  1, 3, 3, 4, 0, 0},
>> -{148352000, 148352000, 1,  98, 1, 1, 1,  1, 2, 2, 2, 0, 0xE6AE6B},
>> -{14850, 14850, 1,  99, 1, 1, 1,  1, 2, 2, 2, 0, 0},
>> -{148352000, 18544, 4, 494, 0, 2, 2,  1, 3, 2, 2, 0, 0x816817},
>> -{14850, 185625000, 4, 495, 0, 2, 2,  1, 3, 2, 2, 0, 0},
>> -{296703000, 296703000, 1,  98, 0, 1, 1,  1, 0, 2, 2, 0, 0xE6AE6B},
>> -{29700, 29700, 1,  99, 0, 1, 1,  1, 0, 2, 2, 0, 0},
>> -{296703000, 370878750, 4, 494, 1, 2, 0,  1, 3, 1, 1, 0, 0x816817},
>> -{29700, 37125, 4, 495, 1, 2, 0,  1, 3, 1, 1, 0, 0},
>> -{593407000, 296703500, 1,  98, 0, 1, 1,  1, 0, 2, 1, 0, 0xE6AE6B},
>> -{59400, 29700, 1,  99, 0, 1, 1,  1, 0, 2, 1, 0, 0},
>> -{593407000, 370879375, 4, 494, 1, 2, 0,  1, 3, 1, 1, 1, 0x816817},
>> -{59400, 37125, 4, 495, 1, 2, 0,  1, 3, 1, 1, 1, 0},
>> -{593407000, 593407000, 1,  98, 0, 2, 0,  1, 0, 1, 1, 0, 0xE6AE6B},
>> -{59400, 59400, 1,  99, 0, 2, 0,  1, 0, 1, 1, 0, 0},
>> +{ 2700,  2700, 1,  90, 3, 2, 2, 10, 3, 3,  4, 0, 0},
>> +{ 2700,  3375, 1,  90, 1, 3, 3, 10, 3, 3,  4, 0, 0},
>> +{ 4000,  4000, 1,  80, 2, 2, 2, 12, 2, 2,  2, 0, 0},
>> +{ 4000,  5000, 1, 100, 2, 2, 2,  1, 0, 0, 15, 0, 0},
>> +{ 59341000,  59341000, 1,  98, 3, 1, 2,  1, 3, 3,  4, 0, 0xE6AE6B},
>> +{ 5940,  5940, 1,  99, 3, 1, 1,  1, 3, 3,  4, 0, 0},
>> +{ 59341000,  74176250, 1,  98, 0, 3, 3,  1, 3, 3,  4, 0, 0xE6AE6B},
>> +{ 5940,  7425, 1,  99, 1, 2, 2,  1, 3, 3,  4, 0, 0},
>> +{ 6500,  6500, 1, 130, 2, 2, 2,  1, 0, 0, 12, 0, 0},
>> +{ 6500,  8125, 3, 325, 0, 3, 3,  1, 0, 0, 10, 0, 0},
>> +{ 7100,  7100, 3, 284, 0, 3, 3,  1, 0, 0,  8, 0, 0},
>> +{ 7100,

[PATCH][next] fbdev: Use fallthrough pseudo-keyword

2020-07-07 Thread Gustavo A. R. Silva

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] 
https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/video/fbdev/acornfb.c |  2 +-
 drivers/video/fbdev/arcfb.c   |  2 +-
 drivers/video/fbdev/atmel_lcdfb.c |  4 ++--
 drivers/video/fbdev/aty/radeon_pm.c   |  6 +++---
 drivers/video/fbdev/cirrusfb.c|  4 ++--
 drivers/video/fbdev/controlfb.c   |  2 +-
 drivers/video/fbdev/core/fbmem.c  |  2 +-
 drivers/video/fbdev/fsl-diu-fb.c  |  4 ++--
 drivers/video/fbdev/gxt4500.c |  2 +-
 drivers/video/fbdev/i740fb.c  |  2 +-
 drivers/video/fbdev/offb.c|  4 ++--
 drivers/video/fbdev/omap/lcdc.c   |  4 ++--
 drivers/video/fbdev/omap/omapfb_main.c| 20 +--
 drivers/video/fbdev/omap2/omapfb/dss/dispc.c  |  4 ++--
 .../video/fbdev/omap2/omapfb/omapfb-ioctl.c   |  2 +-
 .../video/fbdev/omap2/omapfb/omapfb-main.c|  2 +-
 drivers/video/fbdev/pm2fb.c   |  4 ++--
 drivers/video/fbdev/pxafb.c   |  2 +-
 drivers/video/fbdev/s3c-fb.c  |  6 +++---
 drivers/video/fbdev/sa1100fb.c|  2 +-
 drivers/video/fbdev/savage/savagefb_driver.c  |  3 +--
 drivers/video/fbdev/sh_mobile_lcdcfb.c|  4 ++--
 drivers/video/fbdev/sm501fb.c |  2 +-
 drivers/video/fbdev/tdfxfb.c  |  2 +-
 drivers/video/fbdev/xen-fbfront.c |  2 +-
 25 files changed, 46 insertions(+), 47 deletions(-)

diff --git a/drivers/video/fbdev/acornfb.c b/drivers/video/fbdev/acornfb.c
index 09a9ad901dad..bcc92aecf666 100644
--- a/drivers/video/fbdev/acornfb.c
+++ b/drivers/video/fbdev/acornfb.c
@@ -857,7 +857,7 @@ static void acornfb_parse_dram(char *opt)
case 'M':
case 'm':
size *= 1024;
-   /* Fall through */
+   fallthrough;
case 'K':
case 'k':
size *= 1024;
diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c
index 6f7838979f0a..ae3d8e8b8d33 100644
--- a/drivers/video/fbdev/arcfb.c
+++ b/drivers/video/fbdev/arcfb.c
@@ -419,7 +419,7 @@ static int arcfb_ioctl(struct fb_info *info,
schedule();
finish_wait(_waitq, );
}
-   /* fall through */
+   fallthrough;
 
case FBIO_GETCONTROL2:
{
diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index 1e252192569a..8c1d47e52b1a 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -508,7 +508,7 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo 
*var,
case 32:
var->transp.offset = 24;
var->transp.length = 8;
-   /* fall through */
+   fallthrough;
case 24:
if (pdata->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
/* RGB:888 mode */
@@ -633,7 +633,7 @@ static int atmel_lcdfb_set_par(struct fb_info *info)
case 2: value |= ATMEL_LCDC_PIXELSIZE_2; break;
case 4: value |= ATMEL_LCDC_PIXELSIZE_4; break;
case 8: value |= ATMEL_LCDC_PIXELSIZE_8; break;
-   case 15: /* fall through */
+   case 15: fallthrough;
case 16: value |= ATMEL_LCDC_PIXELSIZE_16; break;
case 24: value |= ATMEL_LCDC_PIXELSIZE_24; break;
case 32: value |= ATMEL_LCDC_PIXELSIZE_32; break;
diff --git a/drivers/video/fbdev/aty/radeon_pm.c 
b/drivers/video/fbdev/aty/radeon_pm.c
index 7c4483c7f313..f3d8123d7f36 100644
--- a/drivers/video/fbdev/aty/radeon_pm.c
+++ b/drivers/video/fbdev/aty/radeon_pm.c
@@ -1208,11 +1208,11 @@ static void radeon_pm_enable_dll_m10(struct 
radeonfb_info *rinfo)
case 1:
if (mc & 0x4)
break;
-   /* fall through */
+   fallthrough;
case 2:
dll_sleep_mask |= MDLL_R300_RDCK__MRDCKB_SLEEP;
dll_reset_mask |= MDLL_R300_RDCK__MRDCKB_RESET;
-   /* fall through */
+   fallthrough;
case 0:
dll_sleep_mask |= MDLL_R300_RDCK__MRDCKA_SLEEP;
dll_reset_mask |= MDLL_R300_RDCK__MRDCKA_RESET;
@@ -1221,7 +1221,7 @@ static void radeon_pm_enable_dll_m10(struct radeonfb_info 
*rinfo)
case 1:
if (!(mc & 0x4))
break;
-   /* fall through */
+   fallthrough;
case 2:

Re: [PATCH 09/25] drm/atmel: Use drm_atomic_helper_commit

Hi Daniel.

On Tue, Jul 07, 2020 at 10:12:13PM +0200, Daniel Vetter wrote:
> One of these drivers that predates the nonblocking support in helpers,
> and hand-rolled its own thing. Entirely not anything specific here, we
> can just delete it all and replace it with the helper version.
> 
> Could also perhaps use the drm_mode_config_helper_suspend/resume
> stuff, for another few lines deleted. But I'm not looking at that
> stuff, I'm just going through all the atomic commit functions and make
> sure they have properly annotated dma-fence critical sections
> everywhere.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Sam Ravnborg 
> Cc: Boris Brezillon 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Ludovic Desroches 
> Cc: linux-arm-ker...@lists.infradead.org

Looks good, nice to see all this code deleted!

This more or less matches what I had concluded.
But..

atmel_hlcdc_dc.wq is no longer used - so can also be deleted.

This will delete even more code - good.

I will try to test the patch in the weekend.
Will get back if I suceed doing so.

Sam

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 96 +---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h |  4 -
>  2 files changed, 1 insertion(+), 99 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 871293d1aeeb..9ec156e98f06 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -557,103 +557,10 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq, 
> void *data)
>   return IRQ_HANDLED;
>  }
>  
> -struct atmel_hlcdc_dc_commit {
> - struct work_struct work;
> - struct drm_device *dev;
> - struct drm_atomic_state *state;
> -};
> -
> -static void
> -atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit)
> -{
> - struct drm_device *dev = commit->dev;
> - struct atmel_hlcdc_dc *dc = dev->dev_private;
> - struct drm_atomic_state *old_state = commit->state;
> -
> - /* Apply the atomic update. */
> - drm_atomic_helper_commit_modeset_disables(dev, old_state);
> - drm_atomic_helper_commit_planes(dev, old_state, 0);
> - drm_atomic_helper_commit_modeset_enables(dev, old_state);
> -
> - drm_atomic_helper_wait_for_vblanks(dev, old_state);
> -
> - drm_atomic_helper_cleanup_planes(dev, old_state);
> -
> - drm_atomic_state_put(old_state);
> -
> - /* Complete the commit, wake up any waiter. */
> - spin_lock(>commit.wait.lock);
> - dc->commit.pending = false;
> - wake_up_all_locked(>commit.wait);
> - spin_unlock(>commit.wait.lock);
> -
> - kfree(commit);
> -}
> -
> -static void atmel_hlcdc_dc_atomic_work(struct work_struct *work)
> -{
> - struct atmel_hlcdc_dc_commit *commit =
> - container_of(work, struct atmel_hlcdc_dc_commit, work);
> -
> - atmel_hlcdc_dc_atomic_complete(commit);
> -}
> -
> -static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev,
> - struct drm_atomic_state *state,
> - bool async)
> -{
> - struct atmel_hlcdc_dc *dc = dev->dev_private;
> - struct atmel_hlcdc_dc_commit *commit;
> - int ret;
> -
> - ret = drm_atomic_helper_prepare_planes(dev, state);
> - if (ret)
> - return ret;
> -
> - /* Allocate the commit object. */
> - commit = kzalloc(sizeof(*commit), GFP_KERNEL);
> - if (!commit) {
> - ret = -ENOMEM;
> - goto error;
> - }
> -
> - INIT_WORK(>work, atmel_hlcdc_dc_atomic_work);
> - commit->dev = dev;
> - commit->state = state;
> -
> - spin_lock(>commit.wait.lock);
> - ret = wait_event_interruptible_locked(dc->commit.wait,
> -   !dc->commit.pending);
> - if (ret == 0)
> - dc->commit.pending = true;
> - spin_unlock(>commit.wait.lock);
> -
> - if (ret)
> - goto err_free;
> -
> - /* We have our own synchronization through the commit lock. */
> - BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
> -
> - /* Swap state succeeded, this is the point of no return. */
> - drm_atomic_state_get(state);
> - if (async)
> - queue_work(dc->wq, >work);
> - else
> - atmel_hlcdc_dc_atomic_complete(commit);
> -
> - return 0;
> -
> -err_free:
> - kfree(commit);
> -error:
> - drm_atomic_helper_cleanup_planes(dev, state);
> - return ret;
> -}
> -
>  static const struct drm_mode_config_funcs mode_config_funcs = {
>   .fb_create = drm_gem_fb_create,
>   .atomic_check = drm_atomic_helper_check,
> - .atomic_commit = atmel_hlcdc_dc_atomic_commit,
> + .atomic_commit = drm_atomic_helper_commit,
>  };
>  
>  static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
> @@ -716,7 +623,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
>   if (!dc->wq)
>

[PATCH 2/2] drm/msm/adreno: un-open-code some packets

2020-07-07 Thread Rob Clark

From: Rob Clark 

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c |  5 +++--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 11 +++
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index d95970a73fb4..7f4526b3283d 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -186,7 +186,8 @@ static void a5xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
 * timestamp is written to the memory and then triggers the interrupt
 */
OUT_PKT7(ring, CP_EVENT_WRITE, 4);
-   OUT_RING(ring, CACHE_FLUSH_TS | (1 << 31));
+   OUT_RING(ring, CP_EVENT_WRITE_0_EVENT(CACHE_FLUSH_TS) |
+   CP_EVENT_WRITE_0_IRQ);
OUT_RING(ring, lower_32_bits(rbmemptr(ring, fence)));
OUT_RING(ring, upper_32_bits(rbmemptr(ring, fence)));
OUT_RING(ring, submit->seqno);
@@ -730,7 +731,7 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
 */
if (adreno_is_a530(adreno_gpu)) {
OUT_PKT7(gpu->rb[0], CP_EVENT_WRITE, 1);
-   OUT_RING(gpu->rb[0], 0x0F);
+   OUT_RING(gpu->rb[0], CP_EVENT_WRITE_0_EVENT(STAT_EVENT));
 
gpu->funcs->flush(gpu, gpu->rb[0]);
if (!a5xx_idle(gpu, gpu->rb[0]))
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 7768557cdfb2..1ed325bea430 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -74,7 +74,9 @@ static void get_stats_counter(struct msm_ringbuffer *ring, 
u32 counter,
u64 iova)
 {
OUT_PKT7(ring, CP_REG_TO_MEM, 3);
-   OUT_RING(ring, counter | (1 << 30) | (2 << 18));
+   OUT_RING(ring, CP_REG_TO_MEM_0_REG(counter) |
+   CP_REG_TO_MEM_0_CNT(2) |
+   CP_REG_TO_MEM_0_64B);
OUT_RING(ring, lower_32_bits(iova));
OUT_RING(ring, upper_32_bits(iova));
 }
@@ -102,10 +104,10 @@ static void a6xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
 
/* Invalidate CCU depth and color */
OUT_PKT7(ring, CP_EVENT_WRITE, 1);
-   OUT_RING(ring, PC_CCU_INVALIDATE_DEPTH);
+   OUT_RING(ring, CP_EVENT_WRITE_0_EVENT(PC_CCU_INVALIDATE_DEPTH));
 
OUT_PKT7(ring, CP_EVENT_WRITE, 1);
-   OUT_RING(ring, PC_CCU_INVALIDATE_COLOR);
+   OUT_RING(ring, CP_EVENT_WRITE_0_EVENT(PC_CCU_INVALIDATE_COLOR));
 
/* Submit the commands */
for (i = 0; i < submit->nr_cmds; i++) {
@@ -139,7 +141,8 @@ static void a6xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
 * timestamp is written to the memory and then triggers the interrupt
 */
OUT_PKT7(ring, CP_EVENT_WRITE, 4);
-   OUT_RING(ring, CACHE_FLUSH_TS | (1 << 31));
+   OUT_RING(ring, CP_EVENT_WRITE_0_EVENT(CACHE_FLUSH_TS) |
+   CP_EVENT_WRITE_0_IRQ);
OUT_RING(ring, lower_32_bits(rbmemptr(ring, fence)));
OUT_RING(ring, upper_32_bits(rbmemptr(ring, fence)));
OUT_RING(ring, submit->seqno);
-- 
2.26.2

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

[PATCH 0/2] drm/msm/adreno: cleanup some packet building

2020-07-07 Thread Rob Clark

From: Rob Clark 

Resync generated headers, which we haven't done in a while, and cleanup
some open coded packet building.

Rob Clark (2):
  drm/msm: sync generated headers
  drm/msm/adreno: un-open-code some packets

 drivers/gpu/drm/msm/adreno/a2xx.xml.h | 1102 +++-
 drivers/gpu/drm/msm/adreno/a3xx.xml.h |   85 +-
 drivers/gpu/drm/msm/adreno/a4xx.xml.h |   87 +-
 drivers/gpu/drm/msm/adreno/a5xx.xml.h |  156 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c |5 +-
 drivers/gpu/drm/msm/adreno/a6xx.xml.h | 2305 ++---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h |   28 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c |   11 +-
 .../gpu/drm/msm/adreno/adreno_common.xml.h|   29 +-
 drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h   |  932 ++-
 drivers/gpu/drm/msm/disp/mdp4/mdp4.xml.h  |2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5.xml.h  |2 +-
 drivers/gpu/drm/msm/disp/mdp_common.xml.h |2 +-
 drivers/gpu/drm/msm/dsi/dsi.xml.h |  208 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c|   14 +-
 drivers/gpu/drm/msm/dsi/mmss_cc.xml.h |2 +-
 drivers/gpu/drm/msm/dsi/sfpb.xml.h|2 +-
 drivers/gpu/drm/msm/edp/edp.xml.h |2 +-
 drivers/gpu/drm/msm/hdmi/hdmi.xml.h   |2 +-
 drivers/gpu/drm/msm/hdmi/qfprom.xml.h |2 +-
 20 files changed, 4328 insertions(+), 650 deletions(-)

-- 
2.26.2

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

Re: [PATCH v4 17/20] backlight: use backligt_get_brightness()

Hi Daniel

> >
> > When I stop doing backlight stuff I will compose a proper
> > todo entry. Right now I hope to get first batch included in upstream.
> 
> Sounds all good to me.
> 
> > I hope this set can hit upstream.
> > Next it to convert backlight stuff in gpu/drm/ - let me see how that
> > all turns out. One idea is to support embedding struct backlight_device,
> > but I am not sure if this really will fly.
> 
> Embedding means you tie the lifetime of the backlight device to the
> lifetime of whatever structure it's embedded in. This might be a
> complete pain, but it might also work out since backlight
> register/unregistering is fairly simple. But I'd be vary, maybe before
> we do that we'll need stuff like device_link between backlight and
> drm_device (to make sure the drm_device never outlives the backlight
> at a device level), and maybe a few other tricks.
> 
> Does sound like a lot of head-scratcher fun though to work through all this 
> :-)
If I see there are anything other than trivial lifetime issues
to consider I will not go down this route.
Thanks for the warning so I can keep an open eye on it.

Sam

> 
> Cheers, Daniel
> 
> >
> > Sam
> >
> > > -Daniel
> > >
> > > > ---
> > > >  drivers/video/backlight/88pm860x_bl.c | 13 +
> > > >  drivers/video/backlight/adp5520_bl.c  | 10 +-
> > > >  drivers/video/backlight/adp8860_bl.c  | 10 +-
> > > >  drivers/video/backlight/adp8870_bl.c  | 10 +-
> > > >  drivers/video/backlight/bd6107.c  |  7 +--
> > > >  drivers/video/backlight/corgi_lcd.c   |  8 +---
> > > >  drivers/video/backlight/da903x_bl.c   | 13 +
> > > >  drivers/video/backlight/ep93xx_bl.c   |  8 +---
> > > >  drivers/video/backlight/hp680_bl.c|  6 +-
> > > >  drivers/video/backlight/kb3886_bl.c   |  6 +-
> > > >  drivers/video/backlight/led_bl.c  |  7 +--
> > > >  drivers/video/backlight/lm3533_bl.c   |  8 +---
> > > >  drivers/video/backlight/locomolcd.c   |  6 +-
> > > >  drivers/video/backlight/lv5207lp.c|  7 +--
> > > >  drivers/video/backlight/max8925_bl.c  | 13 +
> > > >  drivers/video/backlight/pwm_bl.c  |  7 +--
> > > >  drivers/video/backlight/qcom-wled.c   |  7 +--
> > > >  drivers/video/backlight/tps65217_bl.c | 10 +-
> > > >  drivers/video/backlight/wm831x_bl.c   | 13 +
> > > >  19 files changed, 19 insertions(+), 150 deletions(-)
> > > >
> > > > diff --git a/drivers/video/backlight/88pm860x_bl.c 
> > > > b/drivers/video/backlight/88pm860x_bl.c
> > > > index 20d96a5ac384..25e409bbb1a2 100644
> > > > --- a/drivers/video/backlight/88pm860x_bl.c
> > > > +++ b/drivers/video/backlight/88pm860x_bl.c
> > > > @@ -121,18 +121,7 @@ static int pm860x_backlight_set(struct 
> > > > backlight_device *bl, int brightness)
> > > >
> > > >  static int pm860x_backlight_update_status(struct backlight_device *bl)
> > > >  {
> > > > -   int brightness = bl->props.brightness;
> > > > -
> > > > -   if (bl->props.power != FB_BLANK_UNBLANK)
> > > > -   brightness = 0;
> > > > -
> > > > -   if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > > > -   brightness = 0;
> > > > -
> > > > -   if (bl->props.state & BL_CORE_SUSPENDED)
> > > > -   brightness = 0;
> > > > -
> > > > -   return pm860x_backlight_set(bl, brightness);
> > > > +   return pm860x_backlight_set(bl, backlight_get_brightness(bl));
> > > >  }
> > > >
> > > >  static int pm860x_backlight_get_brightness(struct backlight_device *bl)
> > > > diff --git a/drivers/video/backlight/adp5520_bl.c 
> > > > b/drivers/video/backlight/adp5520_bl.c
> > > > index 0f63f76723a5..686988c3df3a 100644
> > > > --- a/drivers/video/backlight/adp5520_bl.c
> > > > +++ b/drivers/video/backlight/adp5520_bl.c
> > > > @@ -65,15 +65,7 @@ static int adp5520_bl_set(struct backlight_device 
> > > > *bl, int brightness)
> > > >
> > > >  static int adp5520_bl_update_status(struct backlight_device *bl)
> > > >  {
> > > > -   int brightness = bl->props.brightness;
> > > > -
> > > > -   if (bl->props.power != FB_BLANK_UNBLANK)
> > > > -   brightness = 0;
> > > > -
> > > > -   if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > > > -   brightness = 0;
> > > > -
> > > > -   return adp5520_bl_set(bl, brightness);
> > > > +   return adp5520_bl_set(bl, backlight_get_brightness(bl));
> > > >  }
> > > >
> > > >  static int adp5520_bl_get_brightness(struct backlight_device *bl)
> > > > diff --git a/drivers/video/backlight/adp8860_bl.c 
> > > > b/drivers/video/backlight/adp8860_bl.c
> > > > index 19968104fc47..ddc7f5f0401f 100644
> > > > --- a/drivers/video/backlight/adp8860_bl.c
> > > > +++ b/drivers/video/backlight/adp8860_bl.c
> > > > @@ -361,15 +361,7 @@ static int adp8860_bl_set(struct backlight_device 
> > > > *bl, int brightness)
> > > >
> > > >  static int adp8860_bl_update_status(struct backlight_device *bl)
> > > >  {
> > > > -   int brightness = bl->props.brightness;
> > > > -
> > > > -

Re: [PATCH v4 17/20] backlight: use backligt_get_brightness()

On Tue, Jul 7, 2020 at 9:59 PM Sam Ravnborg  wrote:
>
> On Tue, Jul 07, 2020 at 07:48:20AM +0200, Daniel Vetter wrote:
> > On Fri, Jul 03, 2020 at 08:45:43PM +0200, Sam Ravnborg wrote:
> > > Introduce the backlight_get_brightness() helper in all
> > > video/backlight/* drivers.
> > > This simplifies the code and align the implementation of the
> > > update_status() operation across the different backlight drivers.
> > >
> > > Some of the drivers gains a little extra functionality by the change
> > > as they now respect the fb_blank() ioctl.
> > >
> > > Signed-off-by: Sam Ravnborg 
> >
> > This looks really nice!
> >
> > Since there's a pile more backlight drivers all over the tree, care to
> > update the gpu/todo.rst entry with a note that conversions should use
> > backlight_get_brightness?
>
> When I stop doing backlight stuff I will compose a proper
> todo entry. Right now I hope to get first batch included in upstream.

Sounds all good to me.

> I hope this set can hit upstream.
> Next it to convert backlight stuff in gpu/drm/ - let me see how that
> all turns out. One idea is to support embedding struct backlight_device,
> but I am not sure if this really will fly.

Embedding means you tie the lifetime of the backlight device to the
lifetime of whatever structure it's embedded in. This might be a
complete pain, but it might also work out since backlight
register/unregistering is fairly simple. But I'd be vary, maybe before
we do that we'll need stuff like device_link between backlight and
drm_device (to make sure the drm_device never outlives the backlight
at a device level), and maybe a few other tricks.

Does sound like a lot of head-scratcher fun though to work through all this :-)

Cheers, Daniel

>
> Sam
>
> > -Daniel
> >
> > > ---
> > >  drivers/video/backlight/88pm860x_bl.c | 13 +
> > >  drivers/video/backlight/adp5520_bl.c  | 10 +-
> > >  drivers/video/backlight/adp8860_bl.c  | 10 +-
> > >  drivers/video/backlight/adp8870_bl.c  | 10 +-
> > >  drivers/video/backlight/bd6107.c  |  7 +--
> > >  drivers/video/backlight/corgi_lcd.c   |  8 +---
> > >  drivers/video/backlight/da903x_bl.c   | 13 +
> > >  drivers/video/backlight/ep93xx_bl.c   |  8 +---
> > >  drivers/video/backlight/hp680_bl.c|  6 +-
> > >  drivers/video/backlight/kb3886_bl.c   |  6 +-
> > >  drivers/video/backlight/led_bl.c  |  7 +--
> > >  drivers/video/backlight/lm3533_bl.c   |  8 +---
> > >  drivers/video/backlight/locomolcd.c   |  6 +-
> > >  drivers/video/backlight/lv5207lp.c|  7 +--
> > >  drivers/video/backlight/max8925_bl.c  | 13 +
> > >  drivers/video/backlight/pwm_bl.c  |  7 +--
> > >  drivers/video/backlight/qcom-wled.c   |  7 +--
> > >  drivers/video/backlight/tps65217_bl.c | 10 +-
> > >  drivers/video/backlight/wm831x_bl.c   | 13 +
> > >  19 files changed, 19 insertions(+), 150 deletions(-)
> > >
> > > diff --git a/drivers/video/backlight/88pm860x_bl.c 
> > > b/drivers/video/backlight/88pm860x_bl.c
> > > index 20d96a5ac384..25e409bbb1a2 100644
> > > --- a/drivers/video/backlight/88pm860x_bl.c
> > > +++ b/drivers/video/backlight/88pm860x_bl.c
> > > @@ -121,18 +121,7 @@ static int pm860x_backlight_set(struct 
> > > backlight_device *bl, int brightness)
> > >
> > >  static int pm860x_backlight_update_status(struct backlight_device *bl)
> > >  {
> > > -   int brightness = bl->props.brightness;
> > > -
> > > -   if (bl->props.power != FB_BLANK_UNBLANK)
> > > -   brightness = 0;
> > > -
> > > -   if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > > -   brightness = 0;
> > > -
> > > -   if (bl->props.state & BL_CORE_SUSPENDED)
> > > -   brightness = 0;
> > > -
> > > -   return pm860x_backlight_set(bl, brightness);
> > > +   return pm860x_backlight_set(bl, backlight_get_brightness(bl));
> > >  }
> > >
> > >  static int pm860x_backlight_get_brightness(struct backlight_device *bl)
> > > diff --git a/drivers/video/backlight/adp5520_bl.c 
> > > b/drivers/video/backlight/adp5520_bl.c
> > > index 0f63f76723a5..686988c3df3a 100644
> > > --- a/drivers/video/backlight/adp5520_bl.c
> > > +++ b/drivers/video/backlight/adp5520_bl.c
> > > @@ -65,15 +65,7 @@ static int adp5520_bl_set(struct backlight_device *bl, 
> > > int brightness)
> > >
> > >  static int adp5520_bl_update_status(struct backlight_device *bl)
> > >  {
> > > -   int brightness = bl->props.brightness;
> > > -
> > > -   if (bl->props.power != FB_BLANK_UNBLANK)
> > > -   brightness = 0;
> > > -
> > > -   if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > > -   brightness = 0;
> > > -
> > > -   return adp5520_bl_set(bl, brightness);
> > > +   return adp5520_bl_set(bl, backlight_get_brightness(bl));
> > >  }
> > >
> > >  static int adp5520_bl_get_brightness(struct backlight_device *bl)
> > > diff --git a/drivers/video/backlight/adp8860_bl.c 
> > > b/drivers/video/backlight/adp8860_bl.c
> > > index

[PATCH 18/25] drm/amdgpu: use dma-fence annotations in cs_submit()

This is a bit tricky, since ->notifier_lock is held while calling
dma_fence_wait we must ensure that also the read side (i.e.
dma_fence_begin_signalling) is on the same side. If we mix this up
lockdep complaints, and that's again why we want to have these
annotations.

A nice side effect of this is that because of the fs_reclaim priming
for dma_fence_enable lockdep now automatically checks for us that
nothing in here allocates memory, without even running any userptr
workloads.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index a512ccbc4dea..858528a06fe7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1212,6 +1212,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
struct amdgpu_job *job;
uint64_t seq;
int r;
+   bool fence_cookie;
 
job = p->job;
p->job = NULL;
@@ -1226,6 +1227,8 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
 */
mutex_lock(>adev->notifier_lock);
 
+   fence_cookie = dma_fence_begin_signalling();
+
/* If userptr are invalidated after amdgpu_cs_parser_bos(), return
 * -EAGAIN, drmIoctl in libdrm will restart the amdgpu_cs_ioctl.
 */
@@ -1262,12 +1265,14 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
amdgpu_vm_move_to_lru_tail(p->adev, >vm);
 
ttm_eu_fence_buffer_objects(>ticket, >validated, p->fence);
+   dma_fence_end_signalling(fence_cookie);
mutex_unlock(>adev->notifier_lock);
 
return 0;
 
 error_abort:
drm_sched_job_cleanup(>base);
+   dma_fence_end_signalling(fence_cookie);
mutex_unlock(>adev->notifier_lock);
 
 error_unlock:
-- 
2.27.0

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

[PATCH 25/25] drm/amdgpu: gpu recovery does full modesets

...

I think it's time to stop this little exercise.

The lockdep splat, for the record:

[  132.583381] ==
[  132.584091] WARNING: possible circular locking dependency detected
[  132.584775] 5.7.0-rc3+ #346 Tainted: GW
[  132.585461] --
[  132.586184] kworker/2:3/865 is trying to acquire lock:
[  132.586857] c9677c70 (crtc_ww_class_acquire){+.+.}-{0:0}, at: 
drm_atomic_helper_suspend+0x38/0x120 [drm_kms_helper]
[  132.587569]
   but task is already holding lock:
[  132.589044] 82318c80 (dma_fence_map){}-{0:0}, at: 
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[  132.589803]
   which lock already depends on the new lock.

[  132.592009]
   the existing dependency chain (in reverse order) is:
[  132.593507]
   -> #2 (dma_fence_map){}-{0:0}:
[  132.595019]dma_fence_begin_signalling+0x50/0x60
[  132.595767]drm_atomic_helper_commit+0xa1/0x180 [drm_kms_helper]
[  132.596567]drm_client_modeset_commit_atomic+0x1ea/0x250 [drm]
[  132.597420]drm_client_modeset_commit_locked+0x55/0x190 [drm]
[  132.598178]drm_client_modeset_commit+0x24/0x40 [drm]
[  132.598948]drm_fb_helper_restore_fbdev_mode_unlocked+0x4b/0xa0 
[drm_kms_helper]
[  132.599738]drm_fb_helper_set_par+0x30/0x40 [drm_kms_helper]
[  132.600539]fbcon_init+0x2e8/0x660
[  132.601344]visual_init+0xce/0x130
[  132.602156]do_bind_con_driver+0x1bc/0x2b0
[  132.602970]do_take_over_console+0x115/0x180
[  132.603763]do_fbcon_takeover+0x58/0xb0
[  132.604564]register_framebuffer+0x1ee/0x300
[  132.605369]__drm_fb_helper_initial_config_and_unlock+0x36e/0x520 
[drm_kms_helper]
[  132.606187]amdgpu_fbdev_init+0xb3/0xf0 [amdgpu]
[  132.607032]amdgpu_device_init.cold+0xe90/0x1677 [amdgpu]
[  132.607862]amdgpu_driver_load_kms+0x5a/0x200 [amdgpu]
[  132.608697]amdgpu_pci_probe+0xf7/0x180 [amdgpu]
[  132.609511]local_pci_probe+0x42/0x80
[  132.610324]pci_device_probe+0x104/0x1a0
[  132.611130]really_probe+0x147/0x3c0
[  132.611939]driver_probe_device+0xb6/0x100
[  132.612766]device_driver_attach+0x53/0x60
[  132.613593]__driver_attach+0x8c/0x150
[  132.614419]bus_for_each_dev+0x7b/0xc0
[  132.615249]bus_add_driver+0x14c/0x1f0
[  132.616071]driver_register+0x6c/0xc0
[  132.616902]do_one_initcall+0x5d/0x2f0
[  132.617731]do_init_module+0x5c/0x230
[  132.618560]load_module+0x2981/0x2bc0
[  132.619391]__do_sys_finit_module+0xaa/0x110
[  132.620228]do_syscall_64+0x5a/0x250
[  132.621064]entry_SYSCALL_64_after_hwframe+0x49/0xb3
[  132.621903]
   -> #1 (crtc_ww_class_mutex){+.+.}-{3:3}:
[  132.623587]__ww_mutex_lock.constprop.0+0xcc/0x10c0
[  132.624448]ww_mutex_lock+0x43/0xb0
[  132.625315]drm_modeset_lock+0x44/0x120 [drm]
[  132.626184]drmm_mode_config_init+0x2db/0x8b0 [drm]
[  132.627098]amdgpu_device_init.cold+0xbd1/0x1677 [amdgpu]
[  132.628007]amdgpu_driver_load_kms+0x5a/0x200 [amdgpu]
[  132.628920]amdgpu_pci_probe+0xf7/0x180 [amdgpu]
[  132.629804]local_pci_probe+0x42/0x80
[  132.630690]pci_device_probe+0x104/0x1a0
[  132.631583]really_probe+0x147/0x3c0
[  132.632479]driver_probe_device+0xb6/0x100
[  132.633379]device_driver_attach+0x53/0x60
[  132.634275]__driver_attach+0x8c/0x150
[  132.635170]bus_for_each_dev+0x7b/0xc0
[  132.636069]bus_add_driver+0x14c/0x1f0
[  132.636974]driver_register+0x6c/0xc0
[  132.637870]do_one_initcall+0x5d/0x2f0
[  132.638765]do_init_module+0x5c/0x230
[  132.639654]load_module+0x2981/0x2bc0
[  132.640522]__do_sys_finit_module+0xaa/0x110
[  132.641372]do_syscall_64+0x5a/0x250
[  132.642203]entry_SYSCALL_64_after_hwframe+0x49/0xb3
[  132.643022]
   -> #0 (crtc_ww_class_acquire){+.+.}-{0:0}:
[  132.644643]__lock_acquire+0x1241/0x23f0
[  132.645469]lock_acquire+0xad/0x370
[  132.646274]drm_modeset_acquire_init+0xd2/0x100 [drm]
[  132.647071]drm_atomic_helper_suspend+0x38/0x120 [drm_kms_helper]
[  132.647902]dm_suspend+0x1c/0x60 [amdgpu]
[  132.648698]amdgpu_device_ip_suspend_phase1+0x83/0xe0 [amdgpu]
[  132.649498]amdgpu_device_ip_suspend+0x1c/0x60 [amdgpu]
[  132.650300]amdgpu_device_gpu_recover.cold+0x4e6/0xe64 [amdgpu]
[  132.651084]amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[  132.651825]drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[  132.652594]process_one_work+0x23c/0x580
[  132.653402]worker_thread+0x50/0x3b0
[  132.654139]kthread+0x12e/0x150
[  132.654868]ret_from_fork+0x27/0x50
[  132.655598]

[PATCH 23/25] drm/amdgpu: use dma-fence annotations for gpu reset code

To improve coverage also annotate the gpu reset code itself, since
that's called from other places than drm/scheduler (which is already
annotated). Annotations nests, so this doesn't break anything, and
allows easier testing.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a649e40fd96f..3a3bccd7f1c7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4261,6 +4261,9 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
(amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO) ?
true : false;
bool audio_suspended = false;
+   bool fence_cookie;
+
+   fence_cookie = dma_fence_begin_signalling();
 
/*
 * Flush RAM to disk so that after reboot
@@ -4289,6 +4292,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as another 
already in progress",
  job ? job->base.id : -1, hive->hive_id);
mutex_unlock(>hive_lock);
+   dma_fence_end_signalling(fence_cookie);
return 0;
}
 
@@ -4299,8 +4303,10 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
 */
INIT_LIST_HEAD(_list);
if (adev->gmc.xgmi.num_physical_nodes > 1) {
-   if (!hive)
+   if (!hive) {
+   dma_fence_end_signalling(fence_cookie);
return -ENODEV;
+   }
if (!list_is_first(>gmc.xgmi.head, >device_list))
list_rotate_to_front(>gmc.xgmi.head, 
>device_list);
device_list_handle = >device_list;
@@ -4315,6 +4321,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
DRM_INFO("Bailing on TDR for s_job:%llx, as another 
already in progress",
  job ? job->base.id : -1);
mutex_unlock(>hive_lock);
+   dma_fence_end_signalling(fence_cookie);
return 0;
}
 
@@ -4455,6 +4462,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
 
if (r)
dev_info(adev->dev, "GPU reset end with ret = %d\n", r);
+   dma_fence_end_signalling(fence_cookie);
return r;
 }
 
-- 
2.27.0

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

[PATCH 20/25] drm/amdgpu: DC also loves to allocate stuff where it shouldn't

Not going to bother with a complete commit message, just
offending backtrace:

kvmalloc_node+0x47/0x80
dc_create_state+0x1f/0x60 [amdgpu]
dc_commit_state+0xcb/0x9b0 [amdgpu]
amdgpu_dm_atomic_commit_tail+0xd31/0x2010 [amdgpu]
commit_tail+0xa4/0x140 [drm_kms_helper]
drm_atomic_helper_commit+0x152/0x180 [drm_kms_helper]
drm_client_modeset_commit_atomic+0x1ea/0x250 [drm]
drm_client_modeset_commit_locked+0x55/0x190 [drm]
drm_client_modeset_commit+0x24/0x40 [drm]

v2: Found more in DC code, I'm just going to pile them all up.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/atom.c | 2 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c  | 4 +++-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c 
b/drivers/gpu/drm/amd/amdgpu/atom.c
index 4cfc786699c7..1b0c674fab25 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -1226,7 +1226,7 @@ static int amdgpu_atom_execute_table_locked(struct 
atom_context *ctx, int index,
ectx.abort = false;
ectx.last_jump = 0;
if (ws)
-   ectx.ws = kcalloc(4, ws, GFP_KERNEL);
+   ectx.ws = kcalloc(4, ws, GFP_ATOMIC);
else
ectx.ws = NULL;
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6afcc33ff846..3d41eddc7908 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6872,7 +6872,7 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
struct dc_stream_update stream_update;
} *bundle;
 
-   bundle = kzalloc(sizeof(*bundle), GFP_KERNEL);
+   bundle = kzalloc(sizeof(*bundle), GFP_ATOMIC);
 
if (!bundle) {
dm_error("Failed to allocate update bundle\n");
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 942ceb0f6383..f9a58509efb2 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1475,8 +1475,10 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
 
 struct dc_state *dc_create_state(struct dc *dc)
 {
+   /* No you really cant allocate random crap here this late in
+* atomic_commit_tail. */
struct dc_state *context = kvzalloc(sizeof(struct dc_state),
-   GFP_KERNEL);
+   GFP_ATOMIC);
 
if (!context)
return NULL;
-- 
2.27.0

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

[PATCH 21/25] drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail

Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.

Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to bother, READ_ONCE is
equivalent. And avoids the locking issue.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3d41eddc7908..d6bb876a74e5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6949,7 +6949,11 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
 * explicitly on fences instead
 * and in general should be called for
 * blocking commit to as per framework helpers
+*
+* Yes, this deadlocks, since you're calling dma_resv_lock in a
+* path that leads to a dma_fence_signal(). Don't do that.
 */
+#if 0
r = amdgpu_bo_reserve(abo, true);
if (unlikely(r != 0))
DRM_ERROR("failed to reserve buffer before flip\n");
@@ -6959,6 +6963,12 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
tmz_surface = amdgpu_bo_encrypted(abo);
 
amdgpu_bo_unreserve(abo);
+#endif
+   /*
+* this races anyway, so READ_ONCE isn't any better or worse
+* than the stuff above. Except the stuff above can deadlock.
+*/
+   tiling_flags = READ_ONCE(abo->tiling_flags);
 
fill_dc_plane_info_and_addr(
dm->adev, new_plane_state, tiling_flags,
-- 
2.27.0

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

[PATCH 24/25] Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset"

This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!

This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.

It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be held when we allocate memory, which
might never happen because the dma_fence_wait() is stuck waiting on
our gpu reset:

[  136.763714] ==
[  136.763714] WARNING: possible circular locking dependency detected
[  136.763715] 5.7.0-rc3+ #346 Tainted: GW
[  136.763716] --
[  136.763716] kworker/2:3/682 is trying to acquire lock:
[  136.763716] 8226f140 (console_lock){+.+.}-{0:0}, at: 
drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[  136.763723]
   but task is already holding lock:
[  136.763724] 82318c80 (dma_fence_map){}-{0:0}, at: 
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[  136.763726]
   which lock already depends on the new lock.

[  136.763726]
   the existing dependency chain (in reverse order) is:
[  136.763727]
   -> #2 (dma_fence_map){}-{0:0}:
[  136.763730]__dma_fence_might_wait+0x41/0xb0
[  136.763732]dma_resv_lockdep+0x171/0x202
[  136.763734]do_one_initcall+0x5d/0x2f0
[  136.763736]kernel_init_freeable+0x20d/0x26d
[  136.763738]kernel_init+0xa/0xfb
[  136.763740]ret_from_fork+0x27/0x50
[  136.763740]
   -> #1 (fs_reclaim){+.+.}-{0:0}:
[  136.763743]fs_reclaim_acquire.part.0+0x25/0x30
[  136.763745]kmem_cache_alloc_trace+0x2e/0x6e0
[  136.763747]device_create_groups_vargs+0x52/0xf0
[  136.763747]device_create+0x49/0x60
[  136.763749]fb_console_init+0x25/0x145
[  136.763750]fbmem_init+0xcc/0xe2
[  136.763750]do_one_initcall+0x5d/0x2f0
[  136.763751]kernel_init_freeable+0x20d/0x26d
[  136.763752]kernel_init+0xa/0xfb
[  136.763753]ret_from_fork+0x27/0x50
[  136.763753]
   -> #0 (console_lock){+.+.}-{0:0}:
[  136.763755]__lock_acquire+0x1241/0x23f0
[  136.763756]lock_acquire+0xad/0x370
[  136.763757]console_lock+0x47/0x70
[  136.763761]drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 
[drm_kms_helper]
[  136.763809]amdgpu_device_gpu_recover.cold+0x21e/0xe7b [amdgpu]
[  136.763850]amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[  136.763851]drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[  136.763852]process_one_work+0x23c/0x580
[  136.763853]worker_thread+0x50/0x3b0
[  136.763854]kthread+0x12e/0x150
[  136.763855]ret_from_fork+0x27/0x50
[  136.763855]
   other info that might help us debug this:

[  136.763856] Chain exists of:
 console_lock --> fs_reclaim --> dma_fence_map

[  136.763857]  Possible unsafe locking scenario:

[  136.763857]CPU0CPU1
[  136.763857]
[  136.763857]   lock(dma_fence_map);
[  136.763858]lock(fs_reclaim);
[  136.763858]lock(dma_fence_map);
[  136.763858]   lock(console_lock);
[  136.763859]
*** DEADLOCK ***

[  136.763860] 4 locks held by kworker/2:3/682:
[  136.763860]  #0: 8887fb81c938 ((wq_completion)events){+.+.}-{0:0}, at: 
process_one_work+0x1bc/0x580
[  136.763862]  #1: c9cafe58 
((work_completion)(&(>work_tdr)->work)){+.+.}-{0:0}, at: 
process_one_work+0x1bc/0x580
[  136.763863]  #2: 82318c80 (dma_fence_map){}-{0:0}, at: 
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[  136.763865]  #3: 8887ab621748 (>lock_reset){+.+.}-{3:3}, at: 
amdgpu_device_gpu_recover.cold+0x5ab/0xe7b [amdgpu]
[  136.763914]
   stack backtrace:
[  136.763915] CPU: 2 PID: 682 Comm: kworker/2:3 Tainted: GW 
5.7.0-rc3+ #346
[  136.763916] Hardware name: System manufacturer System Product Name/PRIME 
X370-PRO, BIOS 4011 04/19/2018
[  136.763918] Workqueue: events drm_sched_job_timedout [gpu_sched]
[  136.763919] Call Trace:
[  136.763922]  dump_stack+0x8f/0xd0
[  136.763924]  check_noncircular+0x162/0x180
[  136.763926]  __lock_acquire+0x1241/0x23f0
[  136.763927]  lock_acquire+0xad/0x370
[  136.763932]  ? drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[  136.763933]  ? mark_held_locks+0x2d/0x80
[  136.763934]  ? _raw_spin_unlock_irqrestore+0x46/0x60
[  136.763936]  console_lock+0x47/0x70
[  136.763940]  ? drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[  136.763944]  drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[  136.763993]  amdgpu_device_gpu_recover.cold+0x21e/0xe7b [amdgpu]
[  136.764036]  amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[  136.764038]  drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[  136.764040]

[PATCH 13/25] drm/tegra: Annotate dma-fence critical section in commit path

Again ends just after drm_atomic_helper_commit_hw_done(), but with the
twist that we need to make sure we're only annotate the custom
version. And not the other clause which just calls
drm_atomic_helper_commit_tail_rpm(), which is already annotated.

Signed-off-by: Daniel Vetter 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: linux-te...@vger.kernel.org
---
 drivers/gpu/drm/tegra/drm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index ba9d1c3e7cac..9aea8fe48db3 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -65,11 +65,14 @@ static void tegra_atomic_commit_tail(struct 
drm_atomic_state *old_state)
struct tegra_drm *tegra = drm->dev_private;
 
if (tegra->hub) {
+   bool fence_cookie = dma_fence_begin_signalling();
+
drm_atomic_helper_commit_modeset_disables(drm, old_state);
tegra_display_hub_atomic_commit(drm, old_state);
drm_atomic_helper_commit_planes(drm, old_state, 0);
drm_atomic_helper_commit_modeset_enables(drm, old_state);
drm_atomic_helper_commit_hw_done(old_state);
+   dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_wait_for_vblanks(drm, old_state);
drm_atomic_helper_cleanup_planes(drm, old_state);
} else {
-- 
2.27.0

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

[PATCH 22/25] drm/scheduler: use dma-fence annotations in tdr work

In the face of unpriviledged userspace being able to submit bogus gpu
workloads the kernel needs gpu timeout and reset (tdr) to guarantee
that dma_fences actually complete. Annotate this worker to make sure
we don't have any accidental locking inversions or other problems
lurking.

Originally this was part of the overall scheduler annotation patch.
But amdgpu has some glorious inversions here:

- grabs console_lock
- does a full modeset, which grabs all kinds of locks
  (drm_modeset_lock, dma_resv_lock) which can deadlock with
  dma_fence_wait held inside them.
- almost minor at that point, but the modeset code also allocates
  memory

These all look like they'll be very hard to fix properly, the hardware
seems to require a full display reset with any gpu recovery.

Hence split out as a seperate patch.

Since amdgpu isn't the only hardware driver that needs to reset the
display (at least gen2/3 on intel have the same problem) we need a
generic solution for this. There's two tricks we could still from
drm/i915 and lift to dma-fence:

- The big whack, aka force-complete all fences. i915 does this for all
  pending jobs if the reset is somehow stuck. Trouble is we'd need to
  do this for all fences in the entire system, and just the
  book-keeping for that will be fun. Plus lots of drivers use fences
  for all kinds of internal stuff like memory management, so
  unconditionally resetting all of them doesn't work.

  I'm also hoping that with these fence annotations we could enlist
  lockdep in finding the last offenders causing deadlocks, and we
  could remove this get-out-of-jail trick.

- The more feasible approach (across drivers at least as part of the
  dma_fence contract) is what drm/i915 does for gen2/3: When we need
  to reset the display we wake up all dma_fence_wait_interruptible
  calls, or well at least the equivalent of those in i915 internally.

  Relying on ioctl restart we force all other threads to release their
  locks, which means the tdr thread is guaranteed to be able to get
  them. I think we could implement this at the dma_fence level,
  including proper lockdep annotations.

  dma_fence_begin_tdr():
  - must be nested within a dma_fence_begin/end_signalling section
  - will wake up all interruptible (but not the non-interruptible)
dma_fence_wait() calls and force them to complete with a
-ERESTARTSYS errno code. All new interrupitble calls to
dma_fence_wait() will immeidately fail with the same error code.

  dma_fence_end_trdr():
  - this will convert dma_fence_wait() calls back to normal.

  Of course interrupting dma_fence_wait is only ok if the caller
  specified that, which means we need to split the annotations into
  interruptible and non-interruptible version. If we then make sure
  that we only use interruptible dma_fence_wait() calls while holding
  drm_modeset_lock we can grab them in tdr code, and allow display
  resets. Doing the same for dma_resv_lock might be a lot harder, so
  buffer updates must be avoided.

  What's worse, we're not going to be able to make the dma_fence_wait
  calls in mmu-notifiers interruptible, that doesn't work. So
  allocating memory still wont' be allowed, even in tdr sections. Plus
  obviously we can use this trick only in tdr, it is rather intrusive.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/scheduler/sched_main.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index 52f1ab4bc922..a1c091e11ffd 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -281,9 +281,12 @@ static void drm_sched_job_timedout(struct work_struct 
*work)
 {
struct drm_gpu_scheduler *sched;
struct drm_sched_job *job;
+   bool fence_cookie;
 
sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
 
+   fence_cookie = dma_fence_begin_signalling();
+
/* Protects against concurrent deletion in drm_sched_get_cleanup_job */
spin_lock(>job_list_lock);
job = list_first_entry_or_null(>ring_mirror_list,
@@ -315,6 +318,8 @@ static void drm_sched_job_timedout(struct work_struct *work)
spin_lock(>job_list_lock);
drm_sched_start_timeout(sched);
spin_unlock(>job_list_lock);
+
+   dma_fence_end_signalling(fence_cookie);
 }
 
  /**
-- 
2.27.0

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

[PATCH 11/25] drm/omapdrm: Annotate dma-fence critical section in commit path

Nothing special, just put the end right after hw_done(). Note that in
one path there's a wait for the flip/update to complete. But as far as
I understand from comments and code that's only relevant for modesets,
and skipped if there wasn't a modeset done on a given crtc.

For a bit more clarity pull the hw_done() call out of the if/else,
that way it's a bit clearer flow. But happy to shuffle this around as
is seen fit.

Signed-off-by: Daniel Vetter 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 4526967978b7..aa3a8034d0ea 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -68,6 +68,7 @@ static void omap_atomic_commit_tail(struct drm_atomic_state 
*old_state)
 {
struct drm_device *dev = old_state->dev;
struct omap_drm_private *priv = dev->dev_private;
+   bool fence_cookie = dma_fence_begin_signalling();
 
priv->dispc_ops->runtime_get(priv->dispc);
 
@@ -90,8 +91,6 @@ static void omap_atomic_commit_tail(struct drm_atomic_state 
*old_state)
omap_atomic_wait_for_completion(dev, old_state);
 
drm_atomic_helper_commit_planes(dev, old_state, 0);
-
-   drm_atomic_helper_commit_hw_done(old_state);
} else {
/*
 * OMAP3 DSS seems to have issues with the work-around above,
@@ -101,10 +100,12 @@ static void omap_atomic_commit_tail(struct 
drm_atomic_state *old_state)
drm_atomic_helper_commit_planes(dev, old_state, 0);
 
drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
-   drm_atomic_helper_commit_hw_done(old_state);
}
 
+   drm_atomic_helper_commit_hw_done(old_state);
+
+   dma_fence_end_signalling(fence_cookie);
+
/*
 * Wait for completion of the page flips to ensure that old buffers
 * can't be touched by the hardware anymore before cleaning up planes.
-- 
2.27.0

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

[PATCH 17/25] drm/scheduler: use dma-fence annotations in main thread

If the scheduler rt thread gets stuck on a mutex that we're holding
while waiting for gpu workloads to complete, we have a problem.

Add dma-fence annotations so that lockdep can check this for us.

I've tried to quite carefully review this, and I think it's at the
right spot. But obviosly no expert on drm scheduler.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/scheduler/sched_main.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index d6eaa23ad746..52f1ab4bc922 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -765,9 +765,12 @@ static int drm_sched_main(void *param)
struct sched_param sparam = {.sched_priority = 1};
struct drm_gpu_scheduler *sched = (struct drm_gpu_scheduler *)param;
int r;
+   bool fence_cookie;
 
sched_setscheduler(current, SCHED_FIFO, );
 
+   fence_cookie = dma_fence_begin_signalling();
+
while (!kthread_should_stop()) {
struct drm_sched_entity *entity = NULL;
struct drm_sched_fence *s_fence;
@@ -825,6 +828,9 @@ static int drm_sched_main(void *param)
 
wake_up(>job_scheduled);
}
+
+   dma_fence_end_signalling(fence_cookie);
+
return 0;
 }
 
-- 
2.27.0

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

[PATCH 10/25] drm/imx: Annotate dma-fence critical section in commit path

drm_atomic_helper_commit_hw_done() is the last thing (no plane cleanup
apparrently), so it's the entire function. And a nice comment
explaining why thw wait_for_flip_done is ahead, unlike the usual
sequence.

Aside, I think since the atomic helpers do track plane disabling now
separately this might no longer be a real problem since:

commit 21a01abbe32a3cbeb903378a24e504bfd9fe0648
Author: Maarten Lankhorst 
Date:   Mon Sep 4 12:48:37 2017 +0200

drm/atomic: Fix freeing connector/plane state too early by tracking 
commits, v3.

Plus the subsequent bugfixes of course, this was tricky to get right.

Signed-off-by: Daniel Vetter 
Cc: Philipp Zabel 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/gpu/drm/imx/imx-drm-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 36037b2e6564..8c209bd36780 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -80,6 +80,7 @@ static void imx_drm_atomic_commit_tail(struct 
drm_atomic_state *state)
struct drm_plane_state *old_plane_state, *new_plane_state;
bool plane_disabling = false;
int i;
+   bool fence_cookie = dma_fence_begin_signalling();
 
drm_atomic_helper_commit_modeset_disables(dev, state);
 
@@ -110,6 +111,7 @@ static void imx_drm_atomic_commit_tail(struct 
drm_atomic_state *state)
}
 
drm_atomic_helper_commit_hw_done(state);
+   dma_fence_end_signalling(fence_cookie);
 }
 
 static const struct drm_mode_config_helper_funcs imx_drm_mode_config_helpers = 
{
-- 
2.27.0

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

[PATCH 19/25] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code

My dma-fence lockdep annotations caught an inversion because we
allocate memory where we really shouldn't:

kmem_cache_alloc+0x2b/0x6d0
amdgpu_fence_emit+0x30/0x330 [amdgpu]
amdgpu_ib_schedule+0x306/0x550 [amdgpu]
amdgpu_job_run+0x10f/0x260 [amdgpu]
drm_sched_main+0x1b9/0x490 [gpu_sched]
kthread+0x12e/0x150

Trouble right now is that lockdep only validates against GFP_FS, which
would be good enough for shrinkers. But for mmu_notifiers we actually
need !GFP_ATOMIC, since they can be called from any page laundering,
even if GFP_NOFS or GFP_NOIO are set.

I guess we should improve the lockdep annotations for
fs_reclaim_acquire/release.

Ofc real fix is to properly preallocate this fence and stuff it into
the amdgpu job structure. But GFP_ATOMIC gets the lockdep splat out of
the way.

v2: Two more allocations in scheduler paths.

Frist one:

__kmalloc+0x58/0x720
amdgpu_vmid_grab+0x100/0xca0 [amdgpu]
amdgpu_job_dependency+0xf9/0x120 [amdgpu]
drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched]
drm_sched_main+0xf9/0x490 [gpu_sched]

Second one:

kmem_cache_alloc+0x2b/0x6d0
amdgpu_sync_fence+0x7e/0x110 [amdgpu]
amdgpu_vmid_grab+0x86b/0xca0 [amdgpu]
amdgpu_job_dependency+0xf9/0x120 [amdgpu]
drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched]
drm_sched_main+0xf9/0x490 [gpu_sched]

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c   | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 8d84975885cd..a089a827fdfe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -143,7 +143,7 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct 
dma_fence **f,
uint32_t seq;
int r;
 
-   fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_KERNEL);
+   fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_ATOMIC);
if (fence == NULL)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
index 267fa45ddb66..a333ca2d4ddd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
@@ -208,7 +208,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm,
if (ring->vmid_wait && !dma_fence_is_signaled(ring->vmid_wait))
return amdgpu_sync_fence(sync, ring->vmid_wait);
 
-   fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_KERNEL);
+   fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_ATOMIC);
if (!fences)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
index 8ea6c49529e7..af22b526cec9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
@@ -160,7 +160,7 @@ int amdgpu_sync_fence(struct amdgpu_sync *sync, struct 
dma_fence *f)
if (amdgpu_sync_add_later(sync, f))
return 0;
 
-   e = kmem_cache_alloc(amdgpu_sync_slab, GFP_KERNEL);
+   e = kmem_cache_alloc(amdgpu_sync_slab, GFP_ATOMIC);
if (!e)
return -ENOMEM;
 
-- 
2.27.0

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

[PATCH 06/25] drm/amdgpu: add dma-fence annotations to atomic commit path

I need a canary in a ttm-based atomic driver to make sure the
dma_fence_begin/end_signalling annotations actually work.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 5b0f708dd8c5..6afcc33ff846 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -57,6 +57,7 @@
 
 #include "ivsrcid/ivsrcid_vislands30.h"
 
+#include 
 #include 
 #include 
 #include 
@@ -7359,6 +7360,9 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
struct drm_connector_state *old_con_state, *new_con_state;
struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state;
int crtc_disable_count = 0;
+   bool fence_cookie;
+
+   fence_cookie = dma_fence_begin_signalling();
 
drm_atomic_helper_update_legacy_modeset_state(dev, state);
 
@@ -7639,6 +7643,8 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
/* Signal HW programming completion */
drm_atomic_helper_commit_hw_done(state);
 
+   dma_fence_end_signalling(fence_cookie);
+
if (wait_for_vblank)
drm_atomic_helper_wait_for_flip_done(dev, state);
 
-- 
2.27.0

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

[PATCH 16/25] drm/atomic-helper: Add dma-fence annotations

This is a bit disappointing since we need to split the annotations
over all the different parts.

I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
implementations of this hook right now), so bad flag day. And also a
bit leaky abstraction.

Hence just do it function-by-function.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c6bf9722b51b..f67ee513a7cc 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1550,6 +1550,7 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_flip_done);
 void drm_atomic_helper_commit_tail(struct drm_atomic_state *old_state)
 {
struct drm_device *dev = old_state->dev;
+   bool fence_cookie = dma_fence_begin_signalling();
 
drm_atomic_helper_commit_modeset_disables(dev, old_state);
 
@@ -1561,6 +1562,8 @@ void drm_atomic_helper_commit_tail(struct 
drm_atomic_state *old_state)
 
drm_atomic_helper_commit_hw_done(old_state);
 
+   dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
 
drm_atomic_helper_cleanup_planes(dev, old_state);
@@ -1580,6 +1583,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_tail);
 void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
 {
struct drm_device *dev = old_state->dev;
+   bool fence_cookie = dma_fence_begin_signalling();
 
drm_atomic_helper_commit_modeset_disables(dev, old_state);
 
@@ -1592,6 +1596,8 @@ void drm_atomic_helper_commit_tail_rpm(struct 
drm_atomic_state *old_state)
 
drm_atomic_helper_commit_hw_done(old_state);
 
+   dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
 
drm_atomic_helper_cleanup_planes(dev, old_state);
@@ -1607,6 +1613,9 @@ static void commit_tail(struct drm_atomic_state 
*old_state)
ktime_t start;
s64 commit_time_ms;
unsigned int i, new_self_refresh_mask = 0;
+   bool fence_cookie;
+
+   fence_cookie = dma_fence_begin_signalling();
 
funcs = dev->mode_config.helper_private;
 
@@ -1635,6 +1644,8 @@ static void commit_tail(struct drm_atomic_state 
*old_state)
if (new_crtc_state->self_refresh_active)
new_self_refresh_mask |= BIT(i);
 
+   dma_fence_end_signalling(fence_cookie);
+
if (funcs && funcs->atomic_commit_tail)
funcs->atomic_commit_tail(old_state);
else
@@ -1790,6 +1801,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 bool nonblock)
 {
int ret;
+   bool fence_cookie;
 
if (state->async_update) {
ret = drm_atomic_helper_prepare_planes(dev, state);
@@ -1812,6 +1824,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
if (ret)
return ret;
 
+   fence_cookie = dma_fence_begin_signalling();
+
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
if (ret)
@@ -1849,6 +1863,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 */
 
drm_atomic_state_get(state);
+   dma_fence_end_signalling(fence_cookie);
if (nonblock)
queue_work(system_unbound_wq, >commit_work);
else
@@ -1857,6 +1872,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
return 0;
 
 err:
+   dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
 }
-- 
2.27.0

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

[PATCH 07/25] drm/komdea: Annotate dma-fence critical section in commit path

Like the helpers, nothing special. Well except not, because we the
critical section extends until after hw_done(), since that's the last
thing which could hold up a subsequent atomic commit. That means the
wait_for_flip_done is included, but that's not a problem, we're
allowed to call dma_fence_wait() from signalling critical sections.
Even on our own fence (which this does), it's just a bit confusing.
But in a way those last 2 function calls are already part of the fence
signalling critical section for the next atomic commit.

Reading this I'm wondering why komeda waits for flip_done() before
calling hw_done(), which is a bit backwards (but hey hw can be
special). Might be good to throw a comment in there that explains why,
because the original commit that added this just doesn't.

Cc: "James (Qian) Wang" 
Cc: Liviu Dudau 
Cc: Mihail Atanassov 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 1f6682032ca4..cc5b5915bc5e 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -73,6 +73,7 @@ static struct drm_driver komeda_kms_driver = {
 static void komeda_kms_commit_tail(struct drm_atomic_state *old_state)
 {
struct drm_device *dev = old_state->dev;
+   bool fence_cookie = dma_fence_begin_signalling();
 
drm_atomic_helper_commit_modeset_disables(dev, old_state);
 
@@ -85,6 +86,8 @@ static void komeda_kms_commit_tail(struct drm_atomic_state 
*old_state)
 
drm_atomic_helper_commit_hw_done(old_state);
 
+   dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_cleanup_planes(dev, old_state);
 }
 
-- 
2.27.0

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

[PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea

Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.

What I'm not sure about is whether the text should be more explicit in
flat out mandating the amdkfd eviction fences for long running compute
workloads or workloads where userspace fencing is allowed.

v2: Now with dot graph!

Cc: Jesse Natalie 
Cc: Steve Pronovost 
Cc: Jason Ekstrand 
Cc: Felix Kuehling 
Cc: Mika Kuoppala 
Cc: Thomas Hellstrom 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 Documentation/driver-api/dma-buf.rst | 70 
 drivers/gpu/drm/virtio/virtgpu_display.c | 20 ---
 2 files changed, 70 insertions(+), 20 deletions(-)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index f8f6decde359..037ba0078bb4 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -178,3 +178,73 @@ DMA Fence uABI/Sync File
 .. kernel-doc:: include/linux/sync_file.h
:internal:
 
+Idefinite DMA Fences
+
+
+At various times _fence with an indefinite time until dma_fence_wait()
+finishes have been proposed. Examples include:
+
+* Future fences, used in HWC1 to signal when a buffer isn't used by the display
+  any longer, and created with the screen update that makes the buffer visible.
+  The time this fence completes is entirely under userspace's control.
+
+* Proxy fences, proposed to handle _syncobj for which the fence has not yet
+  been set. Used to asynchronously delay command submission.
+
+* Userspace fences or gpu futexes, fine-grained locking within a command buffer
+  that userspace uses for synchronization across engines or with the CPU, which
+  are then imported as a DMA fence for integration into existing winsys
+  protocols.
+
+* Long-running compute command buffers, while still using traditional end of
+  batch DMA fences for memory management instead of context preemption DMA
+  fences which get reattached when the compute job is rescheduled.
+
+Common to all these schemes is that userspace controls the dependencies of 
these
+fences and controls when they fire. Mixing indefinite fences with normal
+in-kernel DMA fences does not work, even when a fallback timeout is included to
+protect against malicious userspace:
+
+* Only the kernel knows about all DMA fence dependencies, userspace is not 
aware
+  of dependencies injected due to memory management or scheduler decisions.
+
+* Only userspace knows about all dependencies in indefinite fences and when
+  exactly they will complete, the kernel has no visibility.
+
+Furthermore the kernel has to be able to hold up userspace command submission
+for memory management needs, which means we must support indefinite fences 
being
+dependent upon DMA fences. If the kernel also support indefinite fences in the
+kernel like a DMA fence, like any of the above proposal would, there is the
+potential for deadlocks.
+
+.. kernel-render:: DOT
+   :alt: Indefinite Fencing Dependency Cycle
+   :caption: Indefinite Fencing Dependency Cycle
+
+   digraph "Fencing Cycle" {
+  node [shape=box bgcolor=grey style=filled]
+  kernel [label="Kernel DMA Fences"]
+  userspace [label="userspace controlled fences"]
+  kernel -> userspace [label="memory management"]
+  userspace -> kernel [label="Future fence, fence proxy, ..."]
+
+  { rank=same; kernel userspace }
+   }
+
+This means that the kernel might accidentally create deadlocks
+through memory management dependencies which userspace is unaware of, which
+randomly hangs workloads until the timeout kicks in. Workloads, which from
+userspace's perspective, do not contain a deadlock.  In such a mixed fencing
+architecture there is no single entity with knowledge of all dependencies.
+Thefore preventing such deadlocks from within the kernel is not possible.
+
+The only solution to avoid dependencies loops is by not allowing indefinite
+fences in the kernel. This means:
+
+* No future fences, proxy fences or userspace fences imported as DMA fences,
+  with or without a timeout.
+
+* No DMA fences that signal end of batchbuffer for command submission where
+  userspace is allowed to use userspace fencing or long running compute
+  workloads. This also means no implicit fencing for shared buffers in these
+  cases.
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index f3ce49c5a34c..af55b334be2f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -314,25 +314,6 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
return _gpu_fb->base;
 }
 
-static void vgdev_atomic_commit_tail(struct drm_atomic_state *state)
-{
-   struct drm_device *dev =

[PATCH 09/25] drm/atmel: Use drm_atomic_helper_commit

One of these drivers that predates the nonblocking support in helpers,
and hand-rolled its own thing. Entirely not anything specific here, we
can just delete it all and replace it with the helper version.

Could also perhaps use the drm_mode_config_helper_suspend/resume
stuff, for another few lines deleted. But I'm not looking at that
stuff, I'm just going through all the atomic commit functions and make
sure they have properly annotated dma-fence critical sections
everywhere.

Signed-off-by: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Boris Brezillon 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Ludovic Desroches 
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 96 +---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h |  4 -
 2 files changed, 1 insertion(+), 99 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 871293d1aeeb..9ec156e98f06 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -557,103 +557,10 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq, 
void *data)
return IRQ_HANDLED;
 }
 
-struct atmel_hlcdc_dc_commit {
-   struct work_struct work;
-   struct drm_device *dev;
-   struct drm_atomic_state *state;
-};
-
-static void
-atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit)
-{
-   struct drm_device *dev = commit->dev;
-   struct atmel_hlcdc_dc *dc = dev->dev_private;
-   struct drm_atomic_state *old_state = commit->state;
-
-   /* Apply the atomic update. */
-   drm_atomic_helper_commit_modeset_disables(dev, old_state);
-   drm_atomic_helper_commit_planes(dev, old_state, 0);
-   drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
-   drm_atomic_helper_wait_for_vblanks(dev, old_state);
-
-   drm_atomic_helper_cleanup_planes(dev, old_state);
-
-   drm_atomic_state_put(old_state);
-
-   /* Complete the commit, wake up any waiter. */
-   spin_lock(>commit.wait.lock);
-   dc->commit.pending = false;
-   wake_up_all_locked(>commit.wait);
-   spin_unlock(>commit.wait.lock);
-
-   kfree(commit);
-}
-
-static void atmel_hlcdc_dc_atomic_work(struct work_struct *work)
-{
-   struct atmel_hlcdc_dc_commit *commit =
-   container_of(work, struct atmel_hlcdc_dc_commit, work);
-
-   atmel_hlcdc_dc_atomic_complete(commit);
-}
-
-static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev,
-   struct drm_atomic_state *state,
-   bool async)
-{
-   struct atmel_hlcdc_dc *dc = dev->dev_private;
-   struct atmel_hlcdc_dc_commit *commit;
-   int ret;
-
-   ret = drm_atomic_helper_prepare_planes(dev, state);
-   if (ret)
-   return ret;
-
-   /* Allocate the commit object. */
-   commit = kzalloc(sizeof(*commit), GFP_KERNEL);
-   if (!commit) {
-   ret = -ENOMEM;
-   goto error;
-   }
-
-   INIT_WORK(>work, atmel_hlcdc_dc_atomic_work);
-   commit->dev = dev;
-   commit->state = state;
-
-   spin_lock(>commit.wait.lock);
-   ret = wait_event_interruptible_locked(dc->commit.wait,
- !dc->commit.pending);
-   if (ret == 0)
-   dc->commit.pending = true;
-   spin_unlock(>commit.wait.lock);
-
-   if (ret)
-   goto err_free;
-
-   /* We have our own synchronization through the commit lock. */
-   BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
-
-   /* Swap state succeeded, this is the point of no return. */
-   drm_atomic_state_get(state);
-   if (async)
-   queue_work(dc->wq, >work);
-   else
-   atmel_hlcdc_dc_atomic_complete(commit);
-
-   return 0;
-
-err_free:
-   kfree(commit);
-error:
-   drm_atomic_helper_cleanup_planes(dev, state);
-   return ret;
-}
-
 static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
-   .atomic_commit = atmel_hlcdc_dc_atomic_commit,
+   .atomic_commit = drm_atomic_helper_commit,
 };
 
 static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
@@ -716,7 +623,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
if (!dc->wq)
return -ENOMEM;
 
-   init_waitqueue_head(>commit.wait);
dc->desc = match->data;
dc->hlcdc = dev_get_drvdata(dev->dev->parent);
dev->dev_private = dc;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 469d4507e576..9367a3747a3a 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -346,10 +346,6 @@ struct atmel_hlcdc_dc {
u32 imr;

[PATCH 15/25] drm/tilcdc: Use standard drm_atomic_helper_commit

Gives us proper nonblocking support for free, and a pile of other
things. The tilcdc code is simply old enough that it was never
converted over, but was stuck forever with the copypasta from when it
was initially merged.

The riskiest thing with this conversion is maybe that there's an issue
with the vblank handling or vblank event handling, which will upset
the modern commit support in atomic helpers. But from a cursory review
drm_crtc_vblank_on/off is called in the right places, and the event
handling also seems to exist (albeit with much hand-rolling and
probably some races, could perhaps be converted over to
drm_crtc_arm_vblank_event without any real loss).

Motivated by me not having to hand-roll the dma-fence annotations for
this.

Signed-off-by: Daniel Vetter 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 47 +
 1 file changed, 1 insertion(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 0d74a6443263..4f5fc3e87383 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -87,55 +87,10 @@ static int tilcdc_atomic_check(struct drm_device *dev,
return ret;
 }
 
-static int tilcdc_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool async)
-{
-   int ret;
-
-   ret = drm_atomic_helper_prepare_planes(dev, state);
-   if (ret)
-   return ret;
-
-   ret = drm_atomic_helper_swap_state(state, true);
-   if (ret) {
-   drm_atomic_helper_cleanup_planes(dev, state);
-   return ret;
-   }
-
-   /*
-* Everything below can be run asynchronously without the need to grab
-* any modeset locks at all under one condition: It must be guaranteed
-* that the asynchronous work has either been cancelled (if the driver
-* supports it, which at least requires that the framebuffers get
-* cleaned up with drm_atomic_helper_cleanup_planes()) or completed
-* before the new state gets committed on the software side with
-* drm_atomic_helper_swap_state().
-*
-* This scheme allows new atomic state updates to be prepared and
-* checked in parallel to the asynchronous completion of the previous
-* update. Which is important since compositors need to figure out the
-* composition of the next frame right after having submitted the
-* current layout.
-*/
-
-   drm_atomic_helper_commit_modeset_disables(dev, state);
-
-   drm_atomic_helper_commit_planes(dev, state, 0);
-
-   drm_atomic_helper_commit_modeset_enables(dev, state);
-
-   drm_atomic_helper_wait_for_vblanks(dev, state);
-
-   drm_atomic_helper_cleanup_planes(dev, state);
-
-   return 0;
-}
-
 static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = tilcdc_atomic_check,
-   .atomic_commit = tilcdc_commit,
+   .atomic_commit = drm_atomic_helper_commit,
 };
 
 static void modeset_init(struct drm_device *dev)
-- 
2.27.0

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

[PATCH 14/25] drm/tidss: Annotate dma-fence critical section in commit path

Ends right after hw_done(), totally standard case.

Signed-off-by: Daniel Vetter 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/tidss/tidss_kms.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/tidss/tidss_kms.c 
b/drivers/gpu/drm/tidss/tidss_kms.c
index b6e61d6cf60f..556bc801b77c 100644
--- a/drivers/gpu/drm/tidss/tidss_kms.c
+++ b/drivers/gpu/drm/tidss/tidss_kms.c
@@ -4,6 +4,8 @@
  * Author: Tomi Valkeinen 
  */
 
+#include 
+
 #include 
 #include 
 #include 
@@ -26,6 +28,7 @@ static void tidss_atomic_commit_tail(struct drm_atomic_state 
*old_state)
 {
struct drm_device *ddev = old_state->dev;
struct tidss_device *tidss = to_tidss(ddev);
+   bool fence_cookie = dma_fence_begin_signalling();
 
dev_dbg(ddev->dev, "%s\n", __func__);
 
@@ -36,6 +39,7 @@ static void tidss_atomic_commit_tail(struct drm_atomic_state 
*old_state)
drm_atomic_helper_commit_modeset_enables(ddev, old_state);
 
drm_atomic_helper_commit_hw_done(old_state);
+   dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_wait_for_flip_done(ddev, old_state);
 
drm_atomic_helper_cleanup_planes(ddev, old_state);
-- 
2.27.0

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

[PATCH 12/25] drm/rcar-du: Annotate dma-fence critical section in commit path

Ends right after drm_atomic_helper_commit_hw_done(), absolutely
nothing fancy going on here.

Signed-off-by: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Kieran Bingham 
Cc: linux-renesas-...@vger.kernel.org
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 482329102f19..42c5dc588435 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -391,6 +391,7 @@ static void rcar_du_atomic_commit_tail(struct 
drm_atomic_state *old_state)
struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc;
unsigned int i;
+   bool fence_cookie = dma_fence_begin_signalling();
 
/*
 * Store RGB routing to DPAD0 and DPAD1, the hardware will be configured
@@ -417,6 +418,7 @@ static void rcar_du_atomic_commit_tail(struct 
drm_atomic_state *old_state)
drm_atomic_helper_commit_modeset_enables(dev, old_state);
 
drm_atomic_helper_commit_hw_done(old_state);
+   dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_wait_for_flip_done(dev, old_state);
 
drm_atomic_helper_cleanup_planes(dev, old_state);
-- 
2.27.0

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

[PATCH 08/25] drm/malidp: Annotate dma-fence critical section in commit path

Again needs to be put right after the call to
drm_atomic_helper_commit_hw_done(), since that's the last thing which
can hold up a subsequent atomic commit.

No surprises here.

Signed-off-by: Daniel Vetter 
Cc: "James (Qian) Wang" 
Cc: Liviu Dudau 
Cc: Mihail Atanassov 
---
 drivers/gpu/drm/arm/malidp_drv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 69fee05c256c..26e60401a8e1 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -234,6 +234,7 @@ static void malidp_atomic_commit_tail(struct 
drm_atomic_state *state)
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state;
int i;
+   bool fence_cookie = dma_fence_begin_signalling();
 
pm_runtime_get_sync(drm->dev);
 
@@ -260,6 +261,8 @@ static void malidp_atomic_commit_tail(struct 
drm_atomic_state *state)
 
malidp_atomic_commit_hw_done(state);
 
+   dma_fence_end_signalling(fence_cookie);
+
pm_runtime_put(drm->dev);
 
drm_atomic_helper_cleanup_planes(drm, state);
-- 
2.27.0

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

[PATCH 02/25] dma-fence: prime lockdep annotations

Two in one go:
- it is allowed to call dma_fence_wait() while holding a
  dma_resv_lock(). This is fundamental to how eviction works with ttm,
  so required.

- it is allowed to call dma_fence_wait() from memory reclaim contexts,
  specifically from shrinker callbacks (which i915 does), and from mmu
  notifier callbacks (which amdgpu does, and which i915 sometimes also
  does, and probably always should, but that's kinda a debate). Also
  for stuff like HMM we really need to be able to do this, or things
  get real dicey.

Consequence is that any critical path necessary to get to a
dma_fence_signal for a fence must never a) call dma_resv_lock nor b)
allocate memory with GFP_KERNEL. Also by implication of
dma_resv_lock(), no userspace faulting allowed. That's some supremely
obnoxious limitations, which is why we need to sprinkle the right
annotations to all relevant paths.

The one big locking context we're leaving out here is mmu notifiers,
added in

commit 23b68395c7c78a764e8963fc15a7cfd318bf187f
Author: Daniel Vetter 
Date:   Mon Aug 26 22:14:21 2019 +0200

mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end

that one covers a lot of other callsites, and it's also allowed to
wait on dma-fences from mmu notifiers. But there's no ready-made
functions exposed to prime this, so I've left it out for now.

v2: Also track against mmu notifier context.

v3: kerneldoc to spec the cross-driver contract. Note that currently
i915 throws in a hard-coded 10s timeout on foreign fences (not sure
why that was done, but it's there), which is why that rule is worded
with SHOULD instead of MUST.

Also some of the mmu_notifier/shrinker rules might surprise SoC
drivers, I haven't fully audited them all. Which is infeasible anyway,
we'll need to run them with lockdep and dma-fence annotations and see
what goes boom.

v4: A spelling fix from Mika

v5: #ifdef for CONFIG_MMU_NOTIFIER. Reported by 0day. Unfortunately
this means lockdep enforcement is slightly inconsistent, it won't spot
GFP_NOIO and GFP_NOFS allocations in the wrong spot if
CONFIG_MMU_NOTIFIER is disabled in the kernel config. Oh well.

v5: Note that only drivers/gpu has a reasonable (or at least
historical) excuse to use dma_fence_wait() from shrinker and mmu
notifier callbacks. Everyone else should either have a better memory
manager model, or better hardware. This reflects discussions with
Jason Gunthorpe.

Cc: Jason Gunthorpe 
Cc: Felix Kuehling 
Cc: kernel test robot 
Reviewed-by: Thomas Hellström  (v4)
Cc: Mika Kuoppala 
Cc: Thomas Hellstrom 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 Documentation/driver-api/dma-buf.rst |  6 
 drivers/dma-buf/dma-fence.c  | 46 
 drivers/dma-buf/dma-resv.c   |  8 +
 include/linux/dma-fence.h|  1 +
 4 files changed, 61 insertions(+)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index 05d856131140..f8f6decde359 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -133,6 +133,12 @@ DMA Fences
 .. kernel-doc:: drivers/dma-buf/dma-fence.c
:doc: DMA fences overview
 
+DMA Fence Cross-Driver Contract
+~~~
+
+.. kernel-doc:: drivers/dma-buf/dma-fence.c
+   :doc: fence cross-driver contract
+
 DMA Fence Signalling Annotations
 
 
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 0005bc002529..af1d8ea926b3 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -64,6 +64,52 @@ static atomic64_t dma_fence_context_counter = 
ATOMIC64_INIT(1);
  *   _buf.resv pointer.
  */
 
+/**
+ * DOC: fence cross-driver contract
+ *
+ * Since _fence provide a cross driver contract, all drivers must follow 
the
+ * same rules:
+ *
+ * * Fences must complete in a reasonable time. Fences which represent kernels
+ *   and shaders submitted by userspace, which could run forever, must be 
backed
+ *   up by timeout and gpu hang recovery code. Minimally that code must prevent
+ *   further command submission and force complete all in-flight fences, e.g.
+ *   when the driver or hardware do not support gpu reset, or if the gpu reset
+ *   failed for some reason. Ideally the driver supports gpu recovery which 
only
+ *   affects the offending userspace context, and no other userspace
+ *   submissions.
+ *
+ * * Drivers may have different ideas of what completion within a reasonable
+ *   time means. Some hang recovery code uses a fixed timeout, others a mix
+ *   between observing forward progress and increasingly strict timeouts.
+ *   Drivers should not try to second guess timeout handling of fences from
+ *   other drivers.
+ *
+ * * To ensure there's no

[PATCH 04/25] drm/vkms: Annotate vblank timer

This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
Cc: Rodrigo Siqueira 
Cc: Haneen Mohammed 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..a53a40848a72 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -1,5 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 
+#include 
+
 #include 
 #include 
 #include 
@@ -14,7 +16,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
hrtimer *timer)
struct drm_crtc *crtc = >crtc;
struct vkms_crtc_state *state;
u64 ret_overrun;
-   bool ret;
+   bool ret, fence_cookie;
+
+   fence_cookie = dma_fence_begin_signalling();
 
ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
  output->period_ns);
@@ -49,6 +53,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
hrtimer *timer)
DRM_DEBUG_DRIVER("Composer worker already queued\n");
}
 
+   dma_fence_end_signalling(fence_cookie);
+
return HRTIMER_RESTART;
 }
 
-- 
2.27.0

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

[PATCH 05/25] drm/vblank: Annotate with dma-fence signalling section

This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_vblank.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 42a84eb4cc8c..d681ab09963c 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -24,6 +24,7 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
 #include 
 #include 
 
@@ -1909,7 +1910,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
int pipe)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
unsigned long irqflags;
-   bool disable_irq;
+   bool disable_irq, fence_cookie;
 
if (drm_WARN_ON_ONCE(dev, !drm_dev_has_vblank(dev)))
return false;
@@ -1917,6 +1918,8 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
int pipe)
if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
return false;
 
+   fence_cookie = dma_fence_begin_signalling();
+
spin_lock_irqsave(>event_lock, irqflags);
 
/* Need timestamp lock to prevent concurrent execution with
@@ -1929,6 +1932,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
int pipe)
if (!vblank->enabled) {
spin_unlock(>vblank_time_lock);
spin_unlock_irqrestore(>event_lock, irqflags);
+   dma_fence_end_signalling(fence_cookie);
return false;
}
 
@@ -1954,6 +1958,8 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
int pipe)
if (disable_irq)
vblank_disable_fn(>disable_timer);
 
+   dma_fence_end_signalling(fence_cookie);
+
return true;
 }
 EXPORT_SYMBOL(drm_handle_vblank);
-- 
2.27.0

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

[PATCH 01/25] dma-fence: basic lockdep annotations

Design is similar to the lockdep annotations for workers, but with
some twists:

- We use a read-lock for the execution/worker/completion side, so that
  this explicit annotation can be more liberally sprinkled around.
  With read locks lockdep isn't going to complain if the read-side
  isn't nested the same way under all circumstances, so ABBA deadlocks
  are ok. Which they are, since this is an annotation only.

- We're using non-recursive lockdep read lock mode, since in recursive
  read lock mode lockdep does not catch read side hazards. And we
  _very_ much want read side hazards to be caught. For full details of
  this limitation see

  commit e91498589746065e3ae95d9a00b068e525eec34f
  Author: Peter Zijlstra 
  Date:   Wed Aug 23 13:13:11 2017 +0200

  locking/lockdep/selftests: Add mixed read-write ABBA tests

- To allow nesting of the read-side explicit annotations we explicitly
  keep track of the nesting. lock_is_held() allows us to do that.

- The wait-side annotation is a write lock, and entirely done within
  dma_fence_wait() for everyone by default.

- To be able to freely annotate helper functions I want to make it ok
  to call dma_fence_begin/end_signalling from soft/hardirq context.
  First attempt was using the hardirq locking context for the write
  side in lockdep, but this forces all normal spinlocks nested within
  dma_fence_begin/end_signalling to be spinlocks. That bollocks.

  The approach now is to simple check in_atomic(), and for these cases
  entirely rely on the might_sleep() check in dma_fence_wait(). That
  will catch any wrong nesting against spinlocks from soft/hardirq
  contexts.

The idea here is that every code path that's critical for eventually
signalling a dma_fence should be annotated with
dma_fence_begin/end_signalling. The annotation ideally starts right
after a dma_fence is published (added to a dma_resv, exposed as a
sync_file fd, attached to a drm_syncobj fd, or anything else that
makes the dma_fence visible to other kernel threads), up to and
including the dma_fence_wait(). Examples are irq handlers, the
scheduler rt threads, the tail of execbuf (after the corresponding
fences are visible), any workers that end up signalling dma_fences and
really anything else. Not annotated should be code paths that only
complete fences opportunistically as the gpu progresses, like e.g.
shrinker/eviction code.

The main class of deadlocks this is supposed to catch are:

Thread A:

mutex_lock(A);
mutex_unlock(A);

dma_fence_signal();

Thread B:

mutex_lock(A);
dma_fence_wait();
mutex_unlock(A);

Thread B is blocked on A signalling the fence, but A never gets around
to that because it cannot acquire the lock A.

Note that dma_fence_wait() is allowed to be nested within
dma_fence_begin/end_signalling sections. To allow this to happen the
read lock needs to be upgraded to a write lock, which means that any
other lock is acquired between the dma_fence_begin_signalling() call and
the call to dma_fence_wait(), and still held, this will result in an
immediate lockdep complaint. The only other option would be to not
annotate such calls, defeating the point. Therefore these annotations
cannot be sprinkled over the code entirely mindless to avoid false
positives.

Originally I hope that the cross-release lockdep extensions would
alleviate the need for explicit annotations:

https://lwn.net/Articles/709849/

But there's a few reasons why that's not an option:

- It's not happening in upstream, since it got reverted due to too
  many false positives:

commit e966eaeeb623f09975ef362c2866fae6f86844f9
Author: Ingo Molnar 
Date:   Tue Dec 12 12:31:16 2017 +0100

locking/lockdep: Remove the cross-release locking checks

This code (CONFIG_LOCKDEP_CROSSRELEASE=y and 
CONFIG_LOCKDEP_COMPLETIONS=y),
while it found a number of old bugs initially, was also causing too 
many
false positives that caused people to disable lockdep - which is 
arguably
a worse overall outcome.

- cross-release uses the complete() call to annotate the end of
  critical sections, for dma_fence that would be dma_fence_signal().
  But we do not want all dma_fence_signal() calls to be treated as
  critical, since many are opportunistic cleanup of gpu requests. If
  these get stuck there's still the main completion interrupt and
  workers who can unblock everyone. Automatically annotating all
  dma_fence_signal() calls would hence cause false positives.

- cross-release had some educated guesses for when a critical section
  starts, like fresh syscall or fresh work callback. This would again
  cause false positives without explicit annotations, since for
  dma_fence the critical sections only starts when we publish a fence.

- Furthermore there can be cases where a thread never does a
  dma_fence_signal, but is still critical for reaching completion of
  fences. One example would be a

[PATCH 00/25] dma-fence annotations, round 3

Hi all,

Bunch of changes that might matter:

- Clarification that dma_fences are for drivers/gpu, requested by Jason
  Gunthorpe.

- New patch to list all the past discussions around
  indefinite/future/whatever fences, and why this (sadly) still just plain
  doesn't work. Came up again when discussing this stuff, I'd like to just
  be able to point at some doc going forward.

- I rolled dma-fence critical section annotations to (almost, vc4, nouveau
  and i915 have a bit too much custom commit functions) atomic kms
  drivers. Really looking for some serious testing with these, aside from
  the amdgpu atomic commit issues we've also found some problems in vmwgfx
  commit code. All real issues, and noted in the patches.

After the modeset stuff there's still the drm/scheduler annotations.
Testing with other drivers than amdgpu using the drm scheduler would be
very much welcome.

Then the usual pile of amdgpu hacks that I used for developing this. That
stuff isn't for merging, I'm hoping amd is working on proper patches for
these things.

Testing for this series means, especially for the atomic kms drivers:
- build with CONFIG_PROVE_LOCKING
- run the kms_atomic igt, that one actually uses atomic in fences -
  withotu these it's only half the fun
- run anything else you feel like which might use fences, like your
  rendering driver. You do have testcases for that right :-)

The mmu notifier annotation integration landed in -mm for a few days
meanwhile, but I busted it pretty bad. That one needs more baking, I'm
trying to figure out how to write unit tests for these annotations so I'm
not blowing them up all the time.

Also I think it'd be nice if we could start merging some of the earlier
stuff maybe, that doest start to feel solid (at least to me).

Review, commenst and testing on drivers as per above very much welcome.

Thanks, Daniel

Daniel Vetter (25):
  dma-fence: basic lockdep annotations
  dma-fence: prime lockdep annotations
  dma-buf.rst: Document why idenfinite fences are a bad idea
  drm/vkms: Annotate vblank timer
  drm/vblank: Annotate with dma-fence signalling section
  drm/amdgpu: add dma-fence annotations to atomic commit path
  drm/komdea: Annotate dma-fence critical section in commit path
  drm/malidp: Annotate dma-fence critical section in commit path
  drm/atmel: Use drm_atomic_helper_commit
  drm/imx: Annotate dma-fence critical section in commit path
  drm/omapdrm: Annotate dma-fence critical section in commit path
  drm/rcar-du: Annotate dma-fence critical section in commit path
  drm/tegra: Annotate dma-fence critical section in commit path
  drm/tidss: Annotate dma-fence critical section in commit path
  drm/tilcdc: Use standard drm_atomic_helper_commit
  drm/atomic-helper: Add dma-fence annotations
  drm/scheduler: use dma-fence annotations in main thread
  drm/amdgpu: use dma-fence annotations in cs_submit()
  drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code
  drm/amdgpu: DC also loves to allocate stuff where it shouldn't
  drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
  drm/scheduler: use dma-fence annotations in tdr work
  drm/amdgpu: use dma-fence annotations for gpu reset code
  Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset"
  drm/amdgpu: gpu recovery does full modesets

 Documentation/driver-api/dma-buf.rst  |  82 +++
 drivers/dma-buf/dma-fence.c   | 207 ++
 drivers/dma-buf/dma-resv.c|   8 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|   5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c   |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c  |   2 +-
 drivers/gpu/drm/amd/amdgpu/atom.c |   2 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  18 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c  |   4 +-
 .../gpu/drm/arm/display/komeda/komeda_kms.c   |   3 +
 drivers/gpu/drm/arm/malidp_drv.c  |   3 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c  |  96 +---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h  |   4 -
 drivers/gpu/drm/drm_atomic_helper.c   |  16 ++
 drivers/gpu/drm/drm_vblank.c  |   8 +-
 drivers/gpu/drm/imx/imx-drm-core.c|   2 +
 drivers/gpu/drm/omapdrm/omap_drv.c|   9 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |   2 +
 drivers/gpu/drm/scheduler/sched_main.c|  11 +
 drivers/gpu/drm/tegra/drm.c   |   3 +
 drivers/gpu/drm/tidss/tidss_kms.c |   4 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.c   |  47 +---
 drivers/gpu/drm/virtio/virtgpu_display.c  |  20 --
 drivers/gpu/drm/vkms/vkms_crtc.c  |   8 +-
 include/linux/dma-fence.h |  13 ++
 27 files changed, 421 insertions(+), 182 deletions(-)

-- 
2.27.0

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

Re: [PATCH v4 17/20] backlight: use backligt_get_brightness()

On Tue, Jul 07, 2020 at 07:48:20AM +0200, Daniel Vetter wrote:
> On Fri, Jul 03, 2020 at 08:45:43PM +0200, Sam Ravnborg wrote:
> > Introduce the backlight_get_brightness() helper in all
> > video/backlight/* drivers.
> > This simplifies the code and align the implementation of the
> > update_status() operation across the different backlight drivers.
> > 
> > Some of the drivers gains a little extra functionality by the change
> > as they now respect the fb_blank() ioctl.
> > 
> > Signed-off-by: Sam Ravnborg 
> 
> This looks really nice!
> 
> Since there's a pile more backlight drivers all over the tree, care to
> update the gpu/todo.rst entry with a note that conversions should use
> backlight_get_brightness?

When I stop doing backlight stuff I will compose a proper
todo entry. Right now I hope to get first batch included in upstream.

I hope this set can hit upstream.
Next it to convert backlight stuff in gpu/drm/ - let me see how that
all turns out. One idea is to support embedding struct backlight_device,
but I am not sure if this really will fly.

Sam

> -Daniel
> 
> > ---
> >  drivers/video/backlight/88pm860x_bl.c | 13 +
> >  drivers/video/backlight/adp5520_bl.c  | 10 +-
> >  drivers/video/backlight/adp8860_bl.c  | 10 +-
> >  drivers/video/backlight/adp8870_bl.c  | 10 +-
> >  drivers/video/backlight/bd6107.c  |  7 +--
> >  drivers/video/backlight/corgi_lcd.c   |  8 +---
> >  drivers/video/backlight/da903x_bl.c   | 13 +
> >  drivers/video/backlight/ep93xx_bl.c   |  8 +---
> >  drivers/video/backlight/hp680_bl.c|  6 +-
> >  drivers/video/backlight/kb3886_bl.c   |  6 +-
> >  drivers/video/backlight/led_bl.c  |  7 +--
> >  drivers/video/backlight/lm3533_bl.c   |  8 +---
> >  drivers/video/backlight/locomolcd.c   |  6 +-
> >  drivers/video/backlight/lv5207lp.c|  7 +--
> >  drivers/video/backlight/max8925_bl.c  | 13 +
> >  drivers/video/backlight/pwm_bl.c  |  7 +--
> >  drivers/video/backlight/qcom-wled.c   |  7 +--
> >  drivers/video/backlight/tps65217_bl.c | 10 +-
> >  drivers/video/backlight/wm831x_bl.c   | 13 +
> >  19 files changed, 19 insertions(+), 150 deletions(-)
> > 
> > diff --git a/drivers/video/backlight/88pm860x_bl.c 
> > b/drivers/video/backlight/88pm860x_bl.c
> > index 20d96a5ac384..25e409bbb1a2 100644
> > --- a/drivers/video/backlight/88pm860x_bl.c
> > +++ b/drivers/video/backlight/88pm860x_bl.c
> > @@ -121,18 +121,7 @@ static int pm860x_backlight_set(struct 
> > backlight_device *bl, int brightness)
> >  
> >  static int pm860x_backlight_update_status(struct backlight_device *bl)
> >  {
> > -   int brightness = bl->props.brightness;
> > -
> > -   if (bl->props.power != FB_BLANK_UNBLANK)
> > -   brightness = 0;
> > -
> > -   if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > -   brightness = 0;
> > -
> > -   if (bl->props.state & BL_CORE_SUSPENDED)
> > -   brightness = 0;
> > -
> > -   return pm860x_backlight_set(bl, brightness);
> > +   return pm860x_backlight_set(bl, backlight_get_brightness(bl));
> >  }
> >  
> >  static int pm860x_backlight_get_brightness(struct backlight_device *bl)
> > diff --git a/drivers/video/backlight/adp5520_bl.c 
> > b/drivers/video/backlight/adp5520_bl.c
> > index 0f63f76723a5..686988c3df3a 100644
> > --- a/drivers/video/backlight/adp5520_bl.c
> > +++ b/drivers/video/backlight/adp5520_bl.c
> > @@ -65,15 +65,7 @@ static int adp5520_bl_set(struct backlight_device *bl, 
> > int brightness)
> >  
> >  static int adp5520_bl_update_status(struct backlight_device *bl)
> >  {
> > -   int brightness = bl->props.brightness;
> > -
> > -   if (bl->props.power != FB_BLANK_UNBLANK)
> > -   brightness = 0;
> > -
> > -   if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > -   brightness = 0;
> > -
> > -   return adp5520_bl_set(bl, brightness);
> > +   return adp5520_bl_set(bl, backlight_get_brightness(bl));
> >  }
> >  
> >  static int adp5520_bl_get_brightness(struct backlight_device *bl)
> > diff --git a/drivers/video/backlight/adp8860_bl.c 
> > b/drivers/video/backlight/adp8860_bl.c
> > index 19968104fc47..ddc7f5f0401f 100644
> > --- a/drivers/video/backlight/adp8860_bl.c
> > +++ b/drivers/video/backlight/adp8860_bl.c
> > @@ -361,15 +361,7 @@ static int adp8860_bl_set(struct backlight_device *bl, 
> > int brightness)
> >  
> >  static int adp8860_bl_update_status(struct backlight_device *bl)
> >  {
> > -   int brightness = bl->props.brightness;
> > -
> > -   if (bl->props.power != FB_BLANK_UNBLANK)
> > -   brightness = 0;
> > -
> > -   if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > -   brightness = 0;
> > -
> > -   return adp8860_bl_set(bl, brightness);
> > +   return adp8860_bl_set(bl, backlight_get_brightness(bl));
> >  }
> >  
> >  static int adp8860_bl_get_brightness(struct backlight_device *bl)
> > diff --git a/drivers/video/backlight/adp8870_bl.c 
> >

Re: Panic booting qemu-system-sparc64 with bochs_drm

Hi Gerd.

On Tue, Jul 07, 2020 at 09:03:41AM +0200, Gerd Hoffmann wrote:
> > Yes, that's correct - I can confirm that the simplified diff below works:
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 5609e164805f..83af05fac604 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct 
> > drm_fb_helper
> > *fb_helper,
> > unsigned int y;
> > 
> > for (y = clip->y1; y < clip->y2; y++) {
> > -   memcpy(dst, src, len);
> > +   fb_memcpy_tofb(dst, src, len);
> 
> fb_memcpy_tofb is #defined to sbus_memcpy_toio @ sparc which looks
> wrong to me given that this is a pci not a sbus device.  sparc also has
> memcpy_toio which looks better to me.
Looked at sbus_memcpy_toio and memcpy_toio for sparc64.
They are essential the same. Only read bytes in little-endian format,
the other read bytes in big-endian format. So thats the same.

I will prepare a proper patch with focus on fixin sparc64 only.

> 
> There are blit helpers in drm_format_helper.c which already use
> memcpy_toio(), I guess we should do the same here.  Not fully sure we
> can use memcpy_toio() unconditionally here.  Given that a shadow
> framebuffer makes sense only in case the real framebuffer is not in
> normal ram we probably can.
Not so sure about this part.
We unconditionally enable the use of a shadow framebuffer.
But on some archs the framebuffer is not in io space - but then
on these architectures memcpy_toio boils down to a simple memcpy.
So maybe in the end everything is fine.

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

Re: [PATCH 20/20] Documentation: vm/memory-model: eliminate duplicated word

2020-07-07 Thread Mike Rapoport

On Tue, Jul 07, 2020 at 11:04:13AM -0700, Randy Dunlap wrote:
> Drop the doubled word "the".
> 
> Signed-off-by: Randy Dunlap 
> Cc: Jonathan Corbet 
> Cc: linux-...@vger.kernel.org
> Cc: Andrew Morton 
> Cc: linux...@kvack.org

Reviewed-by: Mike Rapoport 

> ---
>  Documentation/vm/memory-model.rst |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-next-20200701.orig/Documentation/vm/memory-model.rst
> +++ linux-next-20200701/Documentation/vm/memory-model.rst
> @@ -159,7 +159,7 @@ frame. Inside a section, the PFN is the
>  The sparse vmemmap uses a virtually mapped memory map to optimize
>  pfn_to_page and page_to_pfn operations. There is a global `struct
>  page *vmemmap` pointer that points to a virtually contiguous array of
> -`struct page` objects. A PFN is an index to that array and the the
> +`struct page` objects. A PFN is an index to that array and the
>  offset of the `struct page` from `vmemmap` is the PFN of that
>  page.
>  

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

Re: [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value

2020-07-07 Thread Hans de Goede


Hi,

On 7/7/20 9:09 PM, Uwe Kleine-KÃ¶nig wrote:

Hello Hans,

On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote:

On 7/7/20 9:34 AM, Uwe Kleine-KÃ¶nig wrote:

On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote:

But if we do then I think closest to the truth would be:

state->period = UINT_MAX;
state->duty_cycle = 0;


I'd say state->period = 1 & state->duty_cycle = 0 is a better
representation.


But that would suggest the output is configured for an
infinitely high output frequency, but the frequency is
actually 0, the reason why get_state needs to treat a
base_unit val of 0 special at all is to avoid a division
by 0, and in math dividing by 0 gives infinite, isn't
UINT_MAX a better way to represent infinity ?


Given that duty_cycle is 0, how can to tell anything about the period
when only seeing the signal (= a constant low)?

Given that (ideally) a period is completed when pwm_apply_state() is
called, a short period is much more sensible.


Ok, I will add a patch to v4 of the patch-set to adjust the pwm-lpss
driver's get_state method accordingly.

Regards,

Hans

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

Re: [PATCH v3 15/15] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller

2020-07-07 Thread Hans de Goede


Hi Uwe,

On 7/7/20 9:50 AM, Uwe Kleine-KÃ¶nig wrote:

Hello Hans,

On Sat, Jun 20, 2020 at 02:17:58PM +0200, Hans de Goede wrote:

Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.


Note that there is no hard dependency, the atomic API should work just
fine even with a non-converted driver. (Of course a converted driver
behaves better, but the i915 using the atomic API with a non-converted
driver is just as good as the legacy API with the same driver.)

So regarding your plan to get this series in soon: There is no hard need
to halt the efforts for the drm part if the pwm patches take a bit
longer (or vice versa).


I understand, but the main reason to do the conversion to the atomic
API, is to be able to skip the step where we force the backlight
to 100% brightness (which can look quite ugly during boot).

After this patch the intel-panel code initializes its internal
backlight state and the brightness reported under /sys/class/backlight
with the "brightness" returned from the PWM-drivers' get_state callback.

Without getting the PWM patches in first I think that things will
mostly work, but we will always report an initial brightness value
of 0. Lets say it is actually 50% and the user then presses the
increase-brightness hotkey, causing userspace to change it from 0% to 5%
so instead of increasing it by 1/20th, it just decreased it a lot.

So I do believe it is better to get the whole series in as a whole,
since we are at rc4 already (time flies) I guess it might not make it
in this cycle, but that is fine.

Talking about merging this, is it ok for me to push the entire
series upstream through the intel-drm-next-queued branch,
once all the PWM patches have your Ack?


The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastset path.

Signed-off-by: Hans de Goede 
---
  .../drm/i915/display/intel_display_types.h|  3 +-
  drivers/gpu/drm/i915/display/intel_panel.c| 73 +--
  2 files changed, 37 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index de32f9efb120..4bd9981e70a1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -28,6 +28,7 @@
  
  #include 

  #include 
+#include 
  #include 
  
  #include 

@@ -223,7 +224,7 @@ struct intel_panel {
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
-   int pwm_period_ns;
+   struct pwm_state pwm_state;
  
  		/* DPCD backlight */

u8 pwmgen_bit_count;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index cb28b9908ca4..a0f76343f381 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -592,10 +592,11 @@ static u32 bxt_get_backlight(struct intel_connector 
*connector)
  static u32 pwm_get_backlight(struct intel_connector *connector)
  {
struct intel_panel *panel = >panel;
-   int duty_ns;
+   int duty_ns, period_ns;
  
  	duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);

-   return DIV_ROUND_UP(duty_ns * 100, panel->backlight.pwm_period_ns);
+   period_ns = pwm_get_period(panel->backlight.pwm);


The transformation is correct, but using

pwm_get_state(pwm, );
duty_ns = state.duty_cycle;
period_ns = state.period;

is a bit more effective as it calls pwm_get_state() only once.

There is a function pwm_get_relative_duty_cycle which is similar (with
scale = 100) just used different rounding.


Ah nice, that is better then doing our own stuff.
I will switch to that for v4 of this patch-set.


+   return DIV_ROUND_UP(duty_ns * 100, period_ns);
  }
  
  static void lpt_set_backlight(const struct drm_connector_state *conn_state, u32 level)

@@ -669,10 +670,10 @@ static void bxt_set_backlight(const struct 
drm_connector_state *conn_state, u32
  static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
  {
struct intel_panel *panel = 
_intel_connector(conn_state->connector)->panel;
-   int duty_ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
  
-	pwm_config(panel->backlight.pwm, duty_ns,

-  panel->backlight.pwm_period_ns);
+   panel->backlight.pwm_state.duty_cycle =
+   DIV_ROUND_UP(level * panel->backlight.pwm_state.period, 100);
+   pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
  }
  
  static void

@@ -841,10 +842,8 @@ static void pwm_disable_backlight(const struct 
drm_connector_state *old_conn_sta
struct intel_connector *connector =

RE: [PATCH 1/2] drm/ttm: further cleanup ttm_mem_reg handling

2020-07-07 Thread Chauhan, Madhav

[AMD Public Use]

-Original Message-
From: amd-gfx  On Behalf Of Christian 
König
Sent: Monday, July 6, 2020 11:18 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH 1/2] drm/ttm: further cleanup ttm_mem_reg handling

Stop touching the backend private pointer alltogether and make sure we never 
put the same mem twice by.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c| 46 +++--
 include/drm/ttm/ttm_bo_driver.h |  2 --
 2 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 
0c13fe96c7e3..7be36b9996ed 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -312,7 +312,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object 
*bo,
if (bdev->driver->move_notify)
bdev->driver->move_notify(bo, evict, mem);
bo->mem = *mem;
-   mem->mm_node = NULL;
goto moved;
}
}
@@ -616,7 +615,6 @@ static void ttm_bo_release(struct kref *kref)
ttm_bo_cleanup_memtype_use(bo);
dma_resv_unlock(bo->base.resv);
 
-   BUG_ON(bo->mem.mm_node != NULL);
atomic_dec(_bo_glob.bo_count);
dma_fence_put(bo->moving);
if (!ttm_bo_uses_embedded_gem_object(bo))
@@ -843,12 +841,29 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
return ret;
 }
 
+static int ttm_bo_mem_get(struct ttm_buffer_object *bo,
+ const struct ttm_place *place,
+ struct ttm_mem_reg *mem)
+{
+   struct ttm_mem_type_manager *man = >bdev->man[mem->mem_type];
+
+   mem->mm_node = NULL;
+   if (!man->func || !man->func->get_node)
+   return 0;
+
+   return man->func->get_node(man, bo, place, mem); }
+

Should not we export this as a symbol, so that it can be used similar to 
ttm_bo_mem_put in drm drivers??

Regards,
Madhav

 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];
 
-   if (mem->mm_node)
-   (*man->func->put_node)(man, mem);
+   if (!man->func || !man->func->put_node)
+   return;
+
+   man->func->put_node(man, mem);
+   mem->mm_node = NULL;
+   mem->mem_type = TTM_PL_SYSTEM;
 }
 EXPORT_SYMBOL(ttm_bo_mem_put);
 
@@ -902,7 +917,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
 
ticket = dma_resv_locking_ctx(bo->base.resv);
do {
-   ret = (*man->func->get_node)(man, bo, place, mem);
+   ret = ttm_bo_mem_get(bo, place, mem);
if (likely(!ret))
break;
if (unlikely(ret != -ENOSPC))
@@ -1032,7 +1047,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
if (unlikely(ret))
return ret;
 
-   mem->mm_node = NULL;
for (i = 0; i < placement->num_placement; ++i) {
const struct ttm_place *place = >placement[i];
struct ttm_mem_type_manager *man;
@@ -1044,20 +1058,16 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
goto error;
 
type_found = true;
-   mem->mm_node = NULL;
-   if (mem->mem_type == TTM_PL_SYSTEM)
-   return 0;
-
-   man = >man[mem->mem_type];
-   ret = (*man->func->get_node)(man, bo, place, mem);
+   ret = ttm_bo_mem_get(bo, place, mem);
if (ret == -ENOSPC)
continue;
if (unlikely(ret))
goto error;
 
+   man = >man[mem->mem_type];
ret = ttm_bo_add_move_fence(bo, man, mem, ctx->no_wait_gpu);
if (unlikely(ret)) {
-   (*man->func->put_node)(man, mem);
+   ttm_bo_mem_put(bo, mem);
if (ret == -EBUSY)
continue;
 
@@ -1076,12 +1086,8 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
goto error;
 
type_found = true;
-   mem->mm_node = NULL;
-   if (mem->mem_type == TTM_PL_SYSTEM)
-   return 0;
-
ret = ttm_bo_mem_force_space(bo, place, mem, ctx);
-   if (ret == 0 && mem->mm_node)
+   if (likely(!ret))
return 0;
 
if (ret && ret != -EBUSY)
@@ -1129,7 +1135,7 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object 
*bo,
goto out_unlock;
ret = ttm_bo_handle_move_mem(bo, , false, ctx);
 out_unlock:
-   if (ret && mem.mm_node)
+   if (ret)
ttm_bo_mem_put(bo, );
return ret;
 }
@@ -1144,7 +1150,7 @@ static bool

Re: [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value

2020-07-07 Thread Uwe Kleine-König

Hello Hans,

On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote:
> On 7/7/20 9:34 AM, Uwe Kleine-König wrote:
> > On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote:
> > > But if we do then I think closest to the truth would be:
> > > 
> > > state->period = UINT_MAX;
> > > state->duty_cycle = 0;
> > 
> > I'd say state->period = 1 & state->duty_cycle = 0 is a better
> > representation.
> 
> But that would suggest the output is configured for an
> infinitely high output frequency, but the frequency is
> actually 0, the reason why get_state needs to treat a
> base_unit val of 0 special at all is to avoid a division
> by 0, and in math dividing by 0 gives infinite, isn't
> UINT_MAX a better way to represent infinity ?

Given that duty_cycle is 0, how can to tell anything about the period
when only seeing the signal (= a constant low)?

Given that (ideally) a period is completed when pwm_apply_state() is
called, a short period is much more sensible.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


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

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

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

--- Comment #47 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to Duncan from comment #39)
> 28 candidates ATM, several of which are OCFS2 or spelling
> fixes neither of which should affect this bug.  Excluding those there are
> eleven left; the penultimate (next to last) one looks to be a good candidate:
> 
> 5f2d5026b mm/Makefile: disable KCSAN for kmemleak
> b0d14fc43 mm/kmemleak.c: use address-of operator on section symbols
> 667c79016 revert "topology: add support for node_to_mem_node() to determine
> the fallback node"
> 3202fa62f slub: relocate freelist pointer to middle of object
> 1ad53d9fa slub: improve bit diffusion for freelist ptr obfuscation
> bbd4e305e mm/slub.c: replace kmem_cache->cpu_partial with wrapped APIs
> 4c7ba22e4 mm/slub.c: replace cpu_slab->partial with wrapped APIs
> c537338c0 fs_parse: remove pr_notice() about each validation
> 630f289b7 asm-generic: make more kernel-space headers mandatory
> 98c985d7d kthread: mark timer used by delayed kthread works as IRQ safe
> 4054ab64e tools/accounting/getdelays.c: fix netlink attribute length

(... and comment #44)
> [I]dea to just try patch-reverting them on top of
> 5.7 or current 5.8-rc, thus eliminating the apparently unrelated
> kernel-panics I''ve twice triggered at the current bisect step.

[Again noting that on my polaris11 the bug doesn't seem to be fixed, despite
comment #45 saying it is on his navi10 with a patch/commit that I can see in
5.8-rc4+.]

So I tried this with the 11 above commits against 5.8.0-rc4-00025-gbfe91da29,
which previously tested as triggering the freeze for me.  Of the 11, nine
clean-reversed and I simply noted and skipped the other two (3202fa62f and
630f289b7) for the moment.  The patched kernel successfully built and I'm
booted to it now.  I just completed a system update (on gentoo so built from
source), which doesn't always trigger the freeze, but seems to do so with a
reasonable number of package updates on kernels with this bug perhaps 50% of
the time.  No freeze.

I'll now try some 4k youtube in firefox, the other stressor that sometimes
seems to trigger it here, and perhaps combine that with an unnecessary rebuild
(since my system's already current) of something big like qtwebengine.  If that
doesn't trigger a freeze I'll stay booted to this thing another few days and
try some more, before being confident enough to declare that one of those nine
commits triggers the bug on my hardware and reverting them eliminates it.

Assuming it is one of those 9 commits (down from 28, as I quoted above, at my
last completed auto-bisect step) I'll reset and try manually bisecting on the
9.  It's looking good so far, but other kernels have looked good at this stage
and then ultimately frozen with the telltale gpf log, so it remains to be seen.

Meanwhile, nice to be on a current development kernel and well past rc1 stage,
again. =:^)  Bisect-testing otherwise long-stale pre-rc1 kernels with other
kernel-crasher bugs to complicate things is *not* my definition of fun!

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

Re: [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object

Quoting lepton (2020-07-07 19:17:51)
> On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson  wrote:
> >
> > Quoting lepton (2020-07-07 18:05:21)
> > > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson  
> > > wrote:
> > > >
> > > > If we assign obj->filp, we believe that the create vgem bo is native and
> > > > allow direct operations like mmap() assuming it behaves as backed by a
> > > > shmemfs inode. When imported from a dmabuf, the obj->pages are
> > > > not always meaningful and the shmemfs backing store misleading.
> > > >
> > > > Note, that regular mmap access to a vgem bo is via the dumb buffer API,
> > > > and that rejects attempts to mmap an imported dmabuf,
> > > What do you mean by "regular mmap access" here?  It looks like vgem is
> > > using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call
> > > drm_gem_dumb_map_offset
> >
> > As I too found out, and so had to correct my story telling.
> >
> > By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer
> > API] as opposed to mmap() via an exported dma-buf fd. I had to look at
> > igt to see how it was being used.
> Now it seems your fix is to disable "regular mmap" on imported dma buf
> for vgem. I am not really a graphic guy, but then the api looks like:
> for a gem handle, user space has to guess to find out the way to mmap
> it. If user space guess wrong, then it will fail to mmap. Is this the
> expected way
> for people to handle gpu buffer?

You either have a dumb buffer handle, or a dma-buf fd. If you have the
handle, you have to use the dumb buffer API, there's no other way to
mmap it. If you have the dma-buf fd, you should mmap it directly. Those
two are clear.

It's when you import the dma-buf into vgem and create a handle out of
it, that's when the handle is no longer first class and certain uAPI
[the dumb buffer API in particular] fail.

It's not brilliant, as you say, it requires the user to remember the
difference between the handles, but at the same time it does prevent
them falling into coherency traps by forcing them to use the right
driver to handle the object, and have to consider the additional ioctls
that go along with that access.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/20] Documentation: kgdb: eliminate duplicated word

2020-07-07 Thread Doug Anderson

Hi,

On Tue, Jul 7, 2020 at 11:05 AM Randy Dunlap  wrote:
>
> Drop the doubled word "driver".
>
> Signed-off-by: Randy Dunlap 
> Cc: Jonathan Corbet 
> Cc: linux-...@vger.kernel.org
> Cc: Jason Wessel 
> Cc: Daniel Thompson 
> Cc: Douglas Anderson 
> Cc: kgdb-bugrep...@lists.sourceforge.net
> ---
>  Documentation/dev-tools/kgdb.rst |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [PATCH 12/20] Documentation: maintainer-entry-profile: eliminate duplicated word

2020-07-07 Thread Dan Williams

On Tue, Jul 7, 2020 at 11:07 AM Randy Dunlap  wrote:
>
> Drop the doubled word "have".
>
> Signed-off-by: Randy Dunlap 
> Cc: Jonathan Corbet 
> Cc: linux-...@vger.kernel.org
> Cc: Dan Williams 
> ---
>  Documentation/maintainer/maintainer-entry-profile.rst |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 
> linux-next-20200701.orig/Documentation/maintainer/maintainer-entry-profile.rst
> +++ linux-next-20200701/Documentation/maintainer/maintainer-entry-profile.rst
> @@ -31,7 +31,7 @@ Example questions to consider:
>  - What branch should contributors submit against?
>  - Links to any other Maintainer Entry Profiles? For example a
>device-driver may point to an entry for its parent subsystem. This makes
> -  the contributor aware of obligations a maintainer may have have for
> +  the contributor aware of obligations a maintainer may have for
>other maintainers in the submission chain.

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

[RFC PATCH] drm/msm: Add vblank timestamp support for dpu1

2020-07-07 Thread Robert Beckett

add vblank timestamp support via drm helpers

[RFC] some questions about modern vblank timestamp handling in context
of this patch:

1. When a driver is using output polling with no console defined and fb helpers
trigger an atomic mode set during initial output detection, existing
vblank->hwmode.crtc_clock is not set (no current mode).

While enabling vblank during the atomic commit we hit a warning in
drm_crtc_vblank_helper_get_vblank_timestamp_internal, which has a comment
indicating that it is expected to happen during initial modesetting of a crtc.

Given this, why is there a WARN_ON_ONCE? If it is expected, warnings just
pollute the log and cause alarm.
If it is there to warn on any future crtc_clock == 0, the the once version of
warn means it wont actually warn as it is disabled during the initial modeset.

2. It looks like drm_calc_timestamping_constants should be called by drivers to
set vblank->hwmode. The comment block for
drm_crtc_vblank_helper_get_vblank_timestamp_internal suggests that
drm_atomic_helper_update_legacy_modeset_state already calls it, yet the comment
block before drm_atomic_helper_update_legacy_modeset_state suggests that it
should only be used for drivers transitioning from legacy.

Where is the ideal place for new implementations to call it? I followed the
example of vkms which does it during vblank_enable handler.

3. When calling drm_calc_timestamping_constants, I used
crtc->state->adjusted_mode, which seemed like the most appropriate mode for that
point in the call chain. Is this the correct thing to use?

4. Is it safe to assume that crtc->mutex will already be held in call calls of
vblank_enable in an atomic driver?

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 69 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |  7 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |  5 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++-
 drivers/gpu/drm/msm/msm_drv.c   |  1 +
 5 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e15b42a780e0..7f2d9df699e1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1320,6 +1320,73 @@ static void dpu_crtc_early_unregister(struct drm_crtc 
*crtc)
debugfs_remove_recursive(dpu_crtc->debugfs_root);
 }
 
+static struct drm_encoder *get_encoder_from_crtc(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_encoder *encoder;
+
+   drm_for_each_encoder(encoder, dev)
+   if (encoder->crtc == crtc)
+   return encoder;
+
+   return NULL;
+}
+
+static bool dpu_crtc_get_scanout_position(struct drm_crtc *crtc,
+  bool in_vblank_irq,
+  int *vpos, int *hpos,
+  ktime_t *stime, ktime_t *etime,
+  const struct drm_display_mode *mode)
+{
+   unsigned int pipe = crtc->index;
+   struct drm_encoder *encoder;
+   int line, vsw, vbp, vactive_start, vactive_end, vfp_end;
+
+
+   encoder = get_encoder_from_crtc(crtc);
+   if (!encoder) {
+   DRM_ERROR("no encoder found for crtc %d\n", pipe);
+   return false;
+   }
+
+   vsw = mode->crtc_vsync_end - mode->crtc_vsync_start;
+   vbp = mode->crtc_vtotal - mode->crtc_vsync_end;
+
+   /*
+* the line counter is 1 at the start of the VSYNC pulse and VTOTAL at
+* the end of VFP. Translate the porch values relative to the line
+* counter positions.
+*/
+
+   vactive_start = vsw + vbp + 1;
+
+   vactive_end = vactive_start + mode->crtc_vdisplay;
+
+   /* last scan line before VSYNC */
+   vfp_end = mode->crtc_vtotal;
+
+   if (stime)
+   *stime = ktime_get();
+
+   line = dpu_encoder_get_linecount(encoder);
+
+   if (line < vactive_start)
+   line -= vactive_start;
+   else if (line > vactive_end)
+   line = line - vfp_end - vactive_start;
+   else
+   line -= vactive_start;
+
+   *vpos = line;
+   *hpos = 0;
+
+   if (etime)
+   *etime = ktime_get();
+
+   return true;
+}
+
+
 static const struct drm_crtc_funcs dpu_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy = dpu_crtc_destroy,
@@ -1331,6 +1398,7 @@ static const struct drm_crtc_funcs dpu_crtc_funcs = {
.early_unregister = dpu_crtc_early_unregister,
.enable_vblank  = msm_crtc_enable_vblank,
.disable_vblank = msm_crtc_disable_vblank,
+   .get_vblank_timestamp = drm_crtc_vblank_helper_get_vblank_timestamp,
 };
 
 static const struct drm_crtc_helper_funcs dpu_crtc_helper_funcs = {
@@ -1339,6 +1407,7 @@ static const struct drm_crtc_helper_funcs

Re: Panic booting qemu-system-sparc64 with bochs_drm

2020-07-07 Thread Gerd Hoffmann

> Thanks Gerd - I've just tested the diff below with memcpy_toio() and that 
> works too:
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 5609e164805f..4d05b0ab1592 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct 
> drm_fb_helper
> *fb_helper,
> unsigned int y;
> 
> for (y = clip->y1; y < clip->y2; y++) {
> -   memcpy(dst, src, len);
> +   memcpy_toio(dst, src, len);
> src += fb->pitches[0];
> dst += fb->pitches[0];
> }
> 
> Presumably there is some existing mechanism that ensures SPARC will always 
> choose a
> shadow framebuffer?

bochs-drm always runs with a shadow framebuffer (that allows to swap
the real framebuffer into and out of vram as needed).  With other
drivers this is in the hands of the driver.  It might not be needed,
virtio-gpu for example uses normal ram as framebuffer storage.

take care,
  Gerd

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

Re: [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value

2020-07-07 Thread Hans de Goede


Hi,

On 7/7/20 9:34 AM, Uwe Kleine-KÃ¶nig wrote:

On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote:

Hi,

Thank you for your review and sorry for the slow reply.


No problem for me, I didn't hold my breath :-)
  

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 43b1fc634af1..80d0f9c64f9d 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -97,6 +97,9 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
freq *= base_unit_range;
base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);


DIV_ROUND_CLOSEST_ULL is most probably wrong, too. But I didn't spend
the time to actually confirm that.


Yes I saw your comment elsewhere that the PWM API defines rounding
in a certain direction, but fixing that falls outside of this patch.


Yeah, sure.


[...]
I hope this helps to explain what is going on a bit.


I will try to make sense of that and reply to the patch directly when I
succeeded.


###

As for the behavior on base_unit==0 in the get_state method,
as mentioned above I wrote that when I did not fully understood
how the controller works.

We really should never encounter this.

But if we do then I think closest to the truth would be:

state->period = UINT_MAX;
state->duty_cycle = 0;


I'd say state->period = 1 & state->duty_cycle = 0 is a better
representation.


But that would suggest the output is configured for an
infinitely high output frequency, but the frequency is
actually 0, the reason why get_state needs to treat a
base_unit val of 0 special at all is to avoid a division
by 0, and in math dividing by 0 gives infinite, isn't
UINT_MAX a better way to represent infinity ?

Regards,

Hans

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

[PATCH][next] drm/nouveau: Use fallthrough pseudo-keyword

2020-07-07 Thread Gustavo A. R. Silva

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] 
https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c|2 -
 drivers/gpu/drm/nouveau/nouveau_bo.c   |2 -
 drivers/gpu/drm/nouveau/nouveau_connector.c|4 +-
 drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmi.c|   34 ++---
 drivers/gpu/drm/nouveau/nvkm/engine/dma/usernv04.c |2 -
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv04.c|4 +-
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv40.c|2 -
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/dcb.c |2 -
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/dp.c  |2 -
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/perf.c|2 -
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/pll.c |2 -
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/timing.c  |   10 +++---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c |2 -
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/mcp77.c|2 -
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv04.c |   12 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv40.c   |4 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/mxm/nv50.c |2 -
 17 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index d472942102f5..ee365f31056b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -932,7 +932,7 @@ nv50_dp_bpc_to_depth(unsigned int bpc)
switch (bpc) {
case  6: return 0x2;
case  8: return 0x5;
-   case 10: /* fall-through */
+   case 10: fallthrough;
default: return 0x6;
}
 }
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index c40f127de3d0..00581e6d183f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1458,7 +1458,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
struct ttm_mem_reg *reg)
if (drm->client.mem->oclass < NVIF_CLASS_MEM_NV50 || !mem->kind)
/* untiled */
break;
-   /* fall through - tiled memory */
+   fallthrough;/* tiled memory */
case TTM_PL_VRAM:
reg->bus.offset = reg->start << PAGE_SHIFT;
reg->bus.base = device->func->resource_addr(device, 1);
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 1b383ae0248f..ae3b3002d737 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -331,7 +331,7 @@ nouveau_conn_attach_properties(struct drm_connector 
*connector)
case DRM_MODE_CONNECTOR_VGA:
if (disp->disp.object.oclass < NV50_DISP)
break; /* Can only scale on DFPs. */
-   /* Fall-through. */
+   fallthrough;
default:
drm_object_attach_property(>base, dev->mode_config.
   scaling_mode_property,
@@ -446,7 +446,7 @@ nouveau_connector_ddc_detect(struct drm_connector 
*connector)
case DCB_OUTPUT_LVDS:
switcheroo_ddc = !!(vga_switcheroo_handler_flags() &
VGA_SWITCHEROO_CAN_SWITCH_DDC);
-   /* fall-through */
+   fallthrough;
default:
if (!nv_encoder->i2c)
break;
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmi.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmi.c
index 7147dc6d9018..1ccfc8314812 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmi.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmi.c
@@ -23,55 +23,55 @@ void pack_hdmi_infoframe(struct packed_hdmi_infoframe 
*packed_frame,
 */
case 17:
subpack1_high = (raw_frame[16] << 16);
-   /* fall through */
+   fallthrough;
case 16:
subpack1_high |= (raw_frame[15] << 8);
-   /* fall through */
+   fallthrough;
case 15:
subpack1_high |= raw_frame[14];
-   /* fall through */
+   fallthrough;
case 14:
subpack1_low = (raw_frame[13] << 24);
-   /* fall through */
+   fallthrough;
case 13:
subpack1_low |= (raw_frame[12] << 16);
-   /* fall through */
+   fallthrough;
case 12:
subpack1_low |= (raw_frame[11] << 8);
-   /* fall through */
+

Re: PROBLEM: kernel oops caused by vmwgfx_cmdbuf.c:399

2020-07-07 Thread Roland Scheidegger

Hi,

we are aware of an issue in our driver with kernel 5.7 resulting in
black screen and working on fixing it.

Roland

Am 07.07.20 um 17:43 schrieb Carle, Peter:
> Good morning! Line 399 of vmwgfx_cmdbuf.c apparently causes a kernel oops 
> that freezes the OS during boot-time. 
> 
> Here is the full line of the summary as reported by the Fedora notification 
> system:
> 
> ---
> 
> WARNING: CPU: 2 PID: 414 at drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:399 
> vmw_cmdbuf_ctx_process+0x262/0x270 [vmwgfx]
> 
> ---
> 
> This problem started with Fedora 32's recent upgrade to kernel version 5.7 on 
> July 2nd. It does not exist in kernel version 5.6. 
> 
> The problem occurs with Fedora running within VMware Workstation Pro on a 
> Windows 10 host. It does not occur with VirtualBox. 
> 
> When I attempt to boot the VM, it freezes with a black screen after getting 
> past the initial boot screen. 
> 
> I have included screenshots of the full error report from the notification 
> system, since it was having trouble exporting it to text format. Probably the 
> most pertinent screenshots are vmwgfx_crash.PNG and coredump_dmesg.PNG.
> 
> Thank you!
> 

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

Re: [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object

Quoting lepton (2020-07-07 18:05:21)
> On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson  wrote:
> >
> > If we assign obj->filp, we believe that the create vgem bo is native and
> > allow direct operations like mmap() assuming it behaves as backed by a
> > shmemfs inode. When imported from a dmabuf, the obj->pages are
> > not always meaningful and the shmemfs backing store misleading.
> >
> > Note, that regular mmap access to a vgem bo is via the dumb buffer API,
> > and that rejects attempts to mmap an imported dmabuf,
> What do you mean by "regular mmap access" here?  It looks like vgem is
> using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call
> drm_gem_dumb_map_offset

As I too found out, and so had to correct my story telling.

By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer
API] as opposed to mmap() via an exported dma-buf fd. I had to look at
igt to see how it was being used.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: dsi: Only register our component once a DSI device is attached

2020-07-07 Thread Eric Anholt

On Tue, Jul 7, 2020 at 3:26 AM Maxime Ripard  wrote:
>
> If the DSI driver is the last to probe, component_add will try to run all
> the bind callbacks straight away and return the error code.
>
> However, since we depend on a power domain, we're pretty much guaranteed to
> be in that case on the BCM2711, and are just lucky on the previous SoCs
> since the v3d also depends on that power domain and is further in the probe
> order.
>
> In that case, the DSI host will not stick around in the system: the DSI
> bind callback will be executed, will not find any DSI device attached and
> will return EPROBE_DEFER, and we will then remove the DSI host and ask to
> be probed later on.
>
> But since that host doesn't stick around, DSI devices like the RaspberryPi
> touchscreen whose probe is not linked to the DSI host (unlike the usual DSI
> devices that will be probed through the call to mipi_dsi_host_register)
> cannot attach to the DSI host, and we thus end up in a situation where the
> DSI host cannot probe because the panel hasn't probed yet, and the panel
> cannot probe because the DSI host hasn't yet.
>
> In order to break this cycle, let's wait until there's a DSI device that
> attaches to the DSI host to register the component and allow to progress
> further.
>
> Suggested-by: Andrzej Hajda 
> Signed-off-by: Maxime Ripard 

I feel like I've written this patch before, but I've thankfully
forgotten most of my battle with DSI probing.  As long as this still
lets vc4 probe in the absence of a DSI panel in the DT as well, then
this is enthusiastically acked.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/7] drm/mgag200: Inline prepare/commit helpers

2020-07-07 Thread Lyude Paul

For context - I already reviewed this once, it just missed the dri-devel list by
accident

For the whole series:

Reviewed-by: Lyude Paul 

On Tue, 2020-07-07 at 10:24 +0200, Thomas Zimmermann wrote:
> Mgag200's modesetting still utilizes the prepare and commit functions
> that were part of the non-atomic interface. This patchset integrates
> them into the simple-display's enable function.
> 
> Patch 1 disables CRTC write protection once when initializing the
> registers. Before, CRTC registers were temporarily write-protected for
> no apparent reason.
> 
> The screen is toggled on and off multiple times while setting a mode.
> Patch 3 removes any intermediate screen on/off changes.
> 
> In patch 4, DPMS functionality is reduced to on an off. The DPMS helper
> function implemements on, off, suspend and standby. In atomic modesetting,
> only on and off is required.
> 
> Tested on G200SE HW with Xorg, Weston and fbdev.
> 
> Thomas Zimmermann (7):
>   drm/mgag200: Don't write-protect CRTC 0-7 while in mga_crtc_prepare()
>   drm/mgag200: Move PLL setup out of mode-setting function
>   drm/mgag200: Don't set or clear  field during modeset
>   drm/mgag200: Split DPMS function into helpers
>   drm/mgag200: Set/clear  field in display enable/disable
> helpers
>   drm/mgag200: Rename G200WB prepare/commit function
>   drm/mgag200: Inline mga_crtc_{prepare,commit}() into enable function
> 
>  drivers/gpu/drm/mgag200/mgag200_drv.h  |   6 +
>  drivers/gpu/drm/mgag200/mgag200_mode.c | 168 +
>  drivers/gpu/drm/mgag200/mgag200_reg.h  |  11 ++
>  3 files changed, 76 insertions(+), 109 deletions(-)
> 
> --
> 2.27.0
> 

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

Re: Panic booting qemu-system-sparc64 with bochs_drm

2020-07-07 Thread Mark Cave-Ayland

On 07/07/2020 08:03, Gerd Hoffmann wrote:

>> Yes, that's correct - I can confirm that the simplified diff below works:
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 5609e164805f..83af05fac604 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct 
>> drm_fb_helper
>> *fb_helper,
>> unsigned int y;
>>
>> for (y = clip->y1; y < clip->y2; y++) {
>> -   memcpy(dst, src, len);
>> +   fb_memcpy_tofb(dst, src, len);
> 
> fb_memcpy_tofb is #defined to sbus_memcpy_toio @ sparc which looks
> wrong to me given that this is a pci not a sbus device.  sparc also has
> memcpy_toio which looks better to me.
> 
> There are blit helpers in drm_format_helper.c which already use
> memcpy_toio(), I guess we should do the same here.  Not fully sure we
> can use memcpy_toio() unconditionally here.  Given that a shadow
> framebuffer makes sense only in case the real framebuffer is not in
> normal ram we probably can.

Thanks Gerd - I've just tested the diff below with memcpy_toio() and that works 
too:

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5609e164805f..4d05b0ab1592 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct 
drm_fb_helper
*fb_helper,
unsigned int y;

for (y = clip->y1; y < clip->y2; y++) {
-   memcpy(dst, src, len);
+   memcpy_toio(dst, src, len);
src += fb->pitches[0];
dst += fb->pitches[0];
}

Presumably there is some existing mechanism that ensures SPARC will always 
choose a
shadow framebuffer?


ATB,

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

[PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object

If we assign obj->filp, we believe that the create vgem bo is native and
allow direct operations like mmap() assuming it behaves as backed by a
shmemfs inode. When imported from a dmabuf, the obj->pages are
not always meaningful and the shmemfs backing store misleading.

Note, that regular mmap access to a vgem bo is via the dumb buffer API,
and that rejects attempts to mmap an imported dmabuf,

drm_gem_dumb_map_offset():
if (obj->import_attach) return -EINVAL;

So the only route by which we might accidentally allow mmapping of an
imported buffer is via vgem_prime_mmap(), which checked for
obj->filp assuming that it would be NULL.

Well it would had it been updated to use the common
drm_gem_dum_map_offset() helper, instead it has

vgem_gem_dumb_map():
if (!obj->filp) return -EINVAL;

falling foul of the same trap as above.

Reported-by: Lepton Wu 
Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Signed-off-by: Chris Wilson 
Cc: Lepton Wu 
Cc: Daniel Vetter 
Cc: Christian König 
Cc: Thomas Hellström (Intel) 
Cc:  # v4.13+
---
 drivers/gpu/drm/vgem/vgem_drv.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 909eba43664a..eb3b7cdac941 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -91,7 +91,7 @@ static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
ret = 0;
}
mutex_unlock(>pages_lock);
-   if (ret) {
+   if (ret && obj->base.filp) {
struct page *page;
 
page = shmem_read_mapping_page(
@@ -157,7 +157,8 @@ static void vgem_postclose(struct drm_device *dev, struct 
drm_file *file)
 }
 
 static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
-   unsigned long size)
+struct file *shmem,
+unsigned long size)
 {
struct drm_vgem_gem_object *obj;
int ret;
@@ -166,11 +167,8 @@ static struct drm_vgem_gem_object 
*__vgem_gem_create(struct drm_device *dev,
if (!obj)
return ERR_PTR(-ENOMEM);
 
-   ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
-   if (ret) {
-   kfree(obj);
-   return ERR_PTR(ret);
-   }
+   drm_gem_private_object_init(dev, >base, size);
+   obj->base.filp = shmem;
 
mutex_init(>pages_lock);
 
@@ -189,11 +187,20 @@ static struct drm_gem_object *vgem_gem_create(struct 
drm_device *dev,
  unsigned long size)
 {
struct drm_vgem_gem_object *obj;
+   struct file *shmem;
int ret;
 
-   obj = __vgem_gem_create(dev, size);
-   if (IS_ERR(obj))
+   size = roundup(size, PAGE_SIZE);
+
+   shmem = shmem_file_setup(DRIVER_NAME, size, VM_NORESERVE);
+   if (IS_ERR(shmem))
+   return ERR_CAST(shmem);
+
+   obj = __vgem_gem_create(dev, shmem, size);
+   if (IS_ERR(obj)) {
+   fput(shmem);
return ERR_CAST(obj);
+   }
 
ret = drm_gem_handle_create(file, >base, handle);
if (ret) {
@@ -363,7 +370,7 @@ static struct drm_gem_object 
*vgem_prime_import_sg_table(struct drm_device *dev,
struct drm_vgem_gem_object *obj;
int npages;
 
-   obj = __vgem_gem_create(dev, attach->dmabuf->size);
+   obj = __vgem_gem_create(dev, NULL, attach->dmabuf->size);
if (IS_ERR(obj))
return ERR_CAST(obj);
 
-- 
2.27.0

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

[PATCH 2/2] drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset()

drm_gem_dumb_map_offset() now exists and does everything
vgem_gem_dump_map does and *ought* to do.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 28 +---
 1 file changed, 1 insertion(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index eb3b7cdac941..866cff537f28 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -236,32 +236,6 @@ static int vgem_gem_dumb_create(struct drm_file *file, 
struct drm_device *dev,
return 0;
 }
 
-static int vgem_gem_dumb_map(struct drm_file *file, struct drm_device *dev,
-uint32_t handle, uint64_t *offset)
-{
-   struct drm_gem_object *obj;
-   int ret;
-
-   obj = drm_gem_object_lookup(file, handle);
-   if (!obj)
-   return -ENOENT;
-
-   if (!obj->filp) {
-   ret = -EINVAL;
-   goto unref;
-   }
-
-   ret = drm_gem_create_mmap_offset(obj);
-   if (ret)
-   goto unref;
-
-   *offset = drm_vma_node_offset_addr(>vma_node);
-unref:
-   drm_gem_object_put_unlocked(obj);
-
-   return ret;
-}
-
 static struct drm_ioctl_desc vgem_ioctls[] = {
DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH, vgem_fence_attach_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL, vgem_fence_signal_ioctl, 
DRM_RENDER_ALLOW),
@@ -455,7 +429,7 @@ static struct drm_driver vgem_driver = {
.fops   = _driver_fops,
 
.dumb_create= vgem_gem_dumb_create,
-   .dumb_map_offset= vgem_gem_dumb_map,
+   .dumb_map_offset= drm_gem_dumb_map_offset,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-- 
2.27.0

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

Re: [GIT PULL] mediatek drm fixes for 5.8

Hi, Daniel:

Chun-Kuang Hu  於 2020年7月7日 週二 下午11:39寫道：
>
> Hi, Dave & David:

Sorry for your name.

>
> This include fixup for cmdq, mmsys, visibility checking and some refinement.
>
> Regards,
> Chun-Kuang.
>
>
> The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:
>
>   Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)
>
> are available in the Git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git 
> tags/mediatek-drm-fixes-5.8
>
> for you to fetch changes up to 5ab546f5e6309373aef01a8d398e163ab7a78431:
>
>   drm/mediatek: mtk_hdmi: Remove debug messages for function calls 
> (2020-07-05 06:39:21 +0800)
>
> 
> Mediatek DRM Fixes for Linux 5.8
>
> 
> Bernard Zhao (1):
>   drm/mediatek: Remove unnecessary conversion to bool
>
> Enric Balletbo i Serra (3):
>   drm/mediatek: Remove debug messages for function calls
>   drm/mediatek: mtk_mt8173_hdmi_phy: Remove unnused const variables
>   drm/mediatek: mtk_hdmi: Remove debug messages for function calls
>
> Hsin-Yi Wang (2):
>   drm/mediatek: Fix device passed to cmdq
>   drm/mediatek: Check plane visibility in atomic_update
>
> Matthias Brugger (1):
>   drm/mediatek: Delete not used of_device_get_match_data
>
> YueHaibing (1):
>   drm/mediatek: Fix Kconfig warning
>
>  drivers/gpu/drm/mediatek/Kconfig   |  2 +-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c|  8 +---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c |  6 +--
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c   | 25 -
>  drivers/gpu/drm/mediatek/mtk_dsi.c |  5 +--
>  drivers/gpu/drm/mediatek/mtk_hdmi.c| 12 +-
>  drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 52 
> --
>  7 files changed, 22 insertions(+), 88 deletions(-)
> ___
> 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

[GIT PULL] mediatek drm fixes for 5.8

Hi, Dave & David:

This include fixup for cmdq, mmsys, visibility checking and some refinement.

Regards,
Chun-Kuang.


The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:

  Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git 
tags/mediatek-drm-fixes-5.8

for you to fetch changes up to 5ab546f5e6309373aef01a8d398e163ab7a78431:

  drm/mediatek: mtk_hdmi: Remove debug messages for function calls (2020-07-05 
06:39:21 +0800)


Mediatek DRM Fixes for Linux 5.8


Bernard Zhao (1):
  drm/mediatek: Remove unnecessary conversion to bool

Enric Balletbo i Serra (3):
  drm/mediatek: Remove debug messages for function calls
  drm/mediatek: mtk_mt8173_hdmi_phy: Remove unnused const variables
  drm/mediatek: mtk_hdmi: Remove debug messages for function calls

Hsin-Yi Wang (2):
  drm/mediatek: Fix device passed to cmdq
  drm/mediatek: Check plane visibility in atomic_update

Matthias Brugger (1):
  drm/mediatek: Delete not used of_device_get_match_data

YueHaibing (1):
  drm/mediatek: Fix Kconfig warning

 drivers/gpu/drm/mediatek/Kconfig   |  2 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c|  8 +---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  6 +--
 drivers/gpu/drm/mediatek/mtk_drm_plane.c   | 25 -
 drivers/gpu/drm/mediatek/mtk_dsi.c |  5 +--
 drivers/gpu/drm/mediatek/mtk_hdmi.c| 12 +-
 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 52 --
 7 files changed, 22 insertions(+), 88 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

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

--- Comment #46 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to Fabian Möller from comment #45)
> Applying 6eb3cf2e06d22b2b08e6b0ab48cb9c05a8e1a107 to v5.7.7 fixed the issue
> for a RX5700/Navi10 under Wayland for me. 

Polaris11 uses a different code path or needs an additional fix?  (Less likely,
maybe X/plasma/kwin makes the kernel calls differently?)

Progress for all and a fix for some in any case! =:^)

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

Re: [PATCH] drm/radeon: fix double free

2020-07-07 Thread Alex Deucher

Applied.  Thanks!

Alex

On Mon, Jul 6, 2020 at 8:29 AM  wrote:
>
> From: Tom Rix 
>
> clang static analysis flags this error
>
> drivers/gpu/drm/radeon/ci_dpm.c:5652:9: warning: Use of memory after it is 
> freed [unix.Malloc]
> kfree(rdev->pm.dpm.ps[i].ps_priv);
>   ^~
> drivers/gpu/drm/radeon/ci_dpm.c:5654:2: warning: Attempt to free released 
> memory [unix.Malloc]
> kfree(rdev->pm.dpm.ps);
> ^~
>
> problem is reported in ci_dpm_fini, with these code blocks.
>
> for (i = 0; i < rdev->pm.dpm.num_ps; i++) {
> kfree(rdev->pm.dpm.ps[i].ps_priv);
> }
> kfree(rdev->pm.dpm.ps);
>
> The first free happens in ci_parse_power_table where it cleans up locally
> on a failure.  ci_dpm_fini also does a cleanup.
>
> ret = ci_parse_power_table(rdev);
> if (ret) {
> ci_dpm_fini(rdev);
> return ret;
> }
>
> So remove the cleanup in ci_parse_power_table and
> move the num_ps calculation to inside the loop so ci_dpm_fini
> will know how many array elements to free.
>
> Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)")
>
> Signed-off-by: Tom Rix 
> ---
>  drivers/gpu/drm/radeon/ci_dpm.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
> index 86ac032275bb..ba20c6f03719 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -5563,6 +5563,7 @@ static int ci_parse_power_table(struct radeon_device 
> *rdev)
> if (!rdev->pm.dpm.ps)
> return -ENOMEM;
> power_state_offset = (u8 *)state_array->states;
> +   rdev->pm.dpm.num_ps = 0;
> for (i = 0; i < state_array->ucNumEntries; i++) {
> u8 *idx;
> power_state = (union pplib_power_state *)power_state_offset;
> @@ -5572,10 +5573,8 @@ static int ci_parse_power_table(struct radeon_device 
> *rdev)
> if (!rdev->pm.power_state[i].clock_info)
> return -EINVAL;
> ps = kzalloc(sizeof(struct ci_ps), GFP_KERNEL);
> -   if (ps == NULL) {
> -   kfree(rdev->pm.dpm.ps);
> +   if (ps == NULL)
> return -ENOMEM;
> -   }
> rdev->pm.dpm.ps[i].ps_priv = ps;
> ci_parse_pplib_non_clock_info(rdev, >pm.dpm.ps[i],
>   non_clock_info,
> @@ -5597,8 +5596,8 @@ static int ci_parse_power_table(struct radeon_device 
> *rdev)
> k++;
> }
> power_state_offset += 2 + power_state->v2.ucNumDPMLevels;
> +   rdev->pm.dpm.num_ps = i + 1;
> }
> -   rdev->pm.dpm.num_ps = state_array->ucNumEntries;
>
> /* fill in the vce power states */
> for (i = 0; i < RADEON_MAX_VCE_LEVELS; i++) {
> --
> 2.18.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 v7 08/36] drm: exynos: fix common struct sg_table related issues



On 07.07.2020 11:40, Andrzej Hajda wrote:
> On 19.06.2020 12:36, Marek Szyprowski wrote:
>> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
>> returns the number of the created entries in the DMA address space.
>> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
>> dma_unmap_sg must be called with the original number of the entries
>> passed to the dma_map_sg().
>>
>> struct sg_table is a common structure used for describing a non-contiguous
>> memory buffer, used commonly in the DRM and graphics subsystems. It
>> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
>> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
>> and DMA mapped pages (nents entry).
>>
>> It turned out that it was a common mistake to misuse nents and orig_nents
>> entries, calling DMA-mapping functions with a wrong number of entries or
>> ignoring the number of mapped entries returned by the dma_map_sg()
>> function.
>>
>> To avoid such issues, lets use a common dma-mapping wrappers operating
>> directly on the struct sg_table objects and use scatterlist page
>> iterators where possible. This, almost always, hides references to the
>> nents and orig_nents entries, making the code robust, easier to follow
>> and copy/paste safe.
>>
>> Signed-off-by: Marek Szyprowski 
>

Just fixing my signature :)

Reviewed-by: Andrzej Hajda 

Regards
Andrzej

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

Re: [PATCH v7 07/36] drm: exynos: use common helper for a scatterlist contiguity check



On 07.07.2020 11:35, Andrzej Hajda wrote:
> Hi,
>
> On 19.06.2020 12:36, Marek Szyprowski wrote:
>> Use common helper for checking the contiguity of the imported dma-buf.
>>
>> Signed-off-by: Marek Szyprowski 

Just fixing my signature :)

Reviewed-by: Andrzej Hajda 

Regards
Andrzej

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

Re: [PATCH v7 01/36] drm: prime: add common helper to check scatterlist contiguity



On 07.07.2020 16:30, Andrzej Hajda wrote:
> On 19.06.2020 12:36, Marek Szyprowski wrote:
>> It is a common operation done by DRM drivers to check the contiguity
>> of the DMA-mapped buffer described by a scatterlist in the
>> sg_table object. Let's add a common helper for this operation.
>>
>> Signed-off-by: Marek Szyprowski 
>> ---

Just fixing my signature :)

Reviewed-by: Andrzej Hajda 

Regards
Andrzej

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

Re: [PATCH v7 03/36] drm: core: fix common struct sg_table related issues



On 19.06.2020 12:36, Marek Szyprowski wrote:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must be called with the original number of the entries
> passed to the dma_map_sg().
>
> struct sg_table is a common structure used for describing a non-contiguous
> memory buffer, used commonly in the DRM and graphics subsystems. It
> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
> and DMA mapped pages (nents entry).
>
> It turned out that it was a common mistake to misuse nents and orig_nents
> entries, calling DMA-mapping functions with a wrong number of entries or
> ignoring the number of mapped entries returned by the dma_map_sg()
> function.
>
> To avoid such issues, lets use a common dma-mapping wrappers operating
> directly on the struct sg_table objects and use scatterlist page
> iterators where possible. This, almost always, hides references to the
> nents and orig_nents entries, making the code robust, easier to follow
> and copy/paste safe.
>
> Signed-off-by: Marek Szyprowski 


I guess whole patchset can go via drm-misc, after r-b/a-b.


Reviewed-by: Andrzej Hajda 


Regards
Andrzej
> ---
>   drivers/gpu/drm/drm_cache.c|  2 +-
>   drivers/gpu/drm/drm_gem_shmem_helper.c | 14 +-
>   drivers/gpu/drm/drm_prime.c| 11 ++-
>   3 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index 03e01b000f7a..0fe3c496002a 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -127,7 +127,7 @@ drm_clflush_sg(struct sg_table *st)
>   struct sg_page_iter sg_iter;
>   
>   mb(); /*CLFLUSH is ordered only by using memory barriers*/
> - for_each_sg_page(st->sgl, _iter, st->nents, 0)
> + for_each_sgtable_page(st, _iter, 0)
>   drm_clflush_page(sg_page_iter_page(_iter));
>   mb(); /*Make sure that all cache line entry is flushed*/
>   
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 4b7cfbac4daa..47d8211221f2 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -126,8 +126,8 @@ void drm_gem_shmem_free_object(struct drm_gem_object *obj)
>   drm_prime_gem_destroy(obj, shmem->sgt);
>   } else {
>   if (shmem->sgt) {
> - dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
> -  shmem->sgt->nents, DMA_BIDIRECTIONAL);
> + dma_unmap_sgtable(obj->dev->dev, shmem->sgt,
> +   DMA_BIDIRECTIONAL, 0);
>   sg_free_table(shmem->sgt);
>   kfree(shmem->sgt);
>   }
> @@ -424,8 +424,7 @@ void drm_gem_shmem_purge_locked(struct drm_gem_object 
> *obj)
>   
>   WARN_ON(!drm_gem_shmem_is_purgeable(shmem));
>   
> - dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
> -  shmem->sgt->nents, DMA_BIDIRECTIONAL);
> + dma_unmap_sgtable(obj->dev->dev, shmem->sgt, DMA_BIDIRECTIONAL, 0);
>   sg_free_table(shmem->sgt);
>   kfree(shmem->sgt);
>   shmem->sgt = NULL;
> @@ -697,12 +696,17 @@ struct sg_table *drm_gem_shmem_get_pages_sgt(struct 
> drm_gem_object *obj)
>   goto err_put_pages;
>   }
>   /* Map the pages for use by the h/w. */
> - dma_map_sg(obj->dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL);
> + ret = dma_map_sgtable(obj->dev->dev, sgt, DMA_BIDIRECTIONAL, 0);
> + if (ret)
> + goto err_free_sgt;
>   
>   shmem->sgt = sgt;
>   
>   return sgt;
>   
> +err_free_sgt:
> + sg_free_table(sgt);
> + kfree(sgt);
>   err_put_pages:
>   drm_gem_shmem_put_pages(shmem);
>   return ERR_PTR(ret);
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index b717e52e909e..d583d6545666 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -617,6 +617,7 @@ struct sg_table *drm_gem_map_dma_buf(struct 
> dma_buf_attachment *attach,
>   {
>   struct drm_gem_object *obj = attach->dmabuf->priv;
>   struct sg_table *sgt;
> + int ret;
>   
>   if (WARN_ON(dir == DMA_NONE))
>   return ERR_PTR(-EINVAL);
> @@ -626,11 +627,12 @@ struct sg_table *drm_gem_map_dma_buf(struct 
> dma_buf_attachment *attach,
>   else
>   sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
>   
> - if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
> -   DMA_ATTR_SKIP_CPU_SYNC)) {
> + ret = dma_map_sgtable(attach->dev, sgt, dir,
> +

Re: [PATCH v7 02/36] drm: prime: use sgtable iterators in drm_prime_sg_to_page_addr_arrays()



On 19.06.2020 12:36, Marek Szyprowski wrote:
> Replace the current hand-crafted code for extracting pages and DMA
> addresses from the given scatterlist by the much more robust
> code based on the generic scatterlist iterators and recently
> introduced sg_table-based wrappers. The resulting code is simple and
> easy to understand, so the comment describing the old code is no
> longer needed.
>
> Signed-off-by: Marek Szyprowski 


Nice simplification.

Reviewed-by: Andrzej Hajda 

Btw, I've wrongly re-configured my e-mail client, so my R-Bs for other 
patches are little bit broken, I will resend them :)


Regards
Andrzej


> ---
>   drivers/gpu/drm/drm_prime.c | 49 -
>   1 file changed, 15 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 226cd6ad3985..b717e52e909e 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -990,45 +990,26 @@ EXPORT_SYMBOL(drm_gem_prime_import);
>   int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page 
> **pages,
>dma_addr_t *addrs, int max_entries)
>   {
> - unsigned count;
> - struct scatterlist *sg;
> - struct page *page;
> - u32 page_len, page_index;
> - dma_addr_t addr;
> - u32 dma_len, dma_index;
> -
> - /*
> -  * Scatterlist elements contains both pages and DMA addresses, but
> -  * one shoud not assume 1:1 relation between them. The sg->length is
> -  * the size of the physical memory chunk described by the sg->page,
> -  * while sg_dma_len(sg) is the size of the DMA (IO virtual) chunk
> -  * described by the sg_dma_address(sg).
> -  */
> - page_index = 0;
> - dma_index = 0;
> - for_each_sg(sgt->sgl, sg, sgt->nents, count) {
> - page_len = sg->length;
> - page = sg_page(sg);
> - dma_len = sg_dma_len(sg);
> - addr = sg_dma_address(sg);
> -
> - while (pages && page_len > 0) {
> - if (WARN_ON(page_index >= max_entries))
> + struct sg_dma_page_iter dma_iter;
> + struct sg_page_iter page_iter;
> + struct page **p = pages;
> + dma_addr_t *a = addrs;
> +
> + if (pages) {
> + for_each_sgtable_page(sgt, _iter, 0) {
> + if (p - pages >= max_entries)
>   return -1;
> - pages[page_index] = page;
> - page++;
> - page_len -= PAGE_SIZE;
> - page_index++;
> + *p++ = sg_page_iter_page(_iter);
>   }
> - while (addrs && dma_len > 0) {
> - if (WARN_ON(dma_index >= max_entries))
> + }
> + if (addrs) {
> + for_each_sgtable_dma_page(sgt, _iter, 0) {
> + if (a - addrs >= max_entries)
>   return -1;
> - addrs[dma_index] = addr;
> - addr += PAGE_SIZE;
> - dma_len -= PAGE_SIZE;
> - dma_index++;
> + *a++ = sg_page_iter_dma_address(_iter);
>   }
>   }
> +
>   return 0;
>   }
>   EXPORT_SYMBOL(drm_prime_sg_to_page_addr_arrays);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH v2 4/6] drm/msm: Add support to create a local pagetable

2020-07-07 Thread Rob Clark

On Tue, Jul 7, 2020 at 4:36 AM Robin Murphy  wrote:
>
> On 2020-06-26 21:04, Jordan Crouse wrote:
> > Add support to create a io-pgtable for use by targets that support
> > per-instance pagetables.  In order to support per-instance pagetables the
> > GPU SMMU device needs to have the qcom,adreno-smmu compatible string and
> > split pagetables and auxiliary domains need to be supported and enabled.
> >
> > Signed-off-by: Jordan Crouse 
> > ---
> >
> >   drivers/gpu/drm/msm/msm_gpummu.c |   2 +-
> >   drivers/gpu/drm/msm/msm_iommu.c  | 180 ++-
> >   drivers/gpu/drm/msm/msm_mmu.h|  16 ++-
> >   3 files changed, 195 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gpummu.c 
> > b/drivers/gpu/drm/msm/msm_gpummu.c
> > index 310a31b05faa..aab121f4beb7 100644
> > --- a/drivers/gpu/drm/msm/msm_gpummu.c
> > +++ b/drivers/gpu/drm/msm/msm_gpummu.c
> > @@ -102,7 +102,7 @@ struct msm_mmu *msm_gpummu_new(struct device *dev, 
> > struct msm_gpu *gpu)
> >   }
> >
> >   gpummu->gpu = gpu;
> > - msm_mmu_init(>base, dev, );
> > + msm_mmu_init(>base, dev, , MSM_MMU_GPUMMU);
> >
> >   return >base;
> >   }
> > diff --git a/drivers/gpu/drm/msm/msm_iommu.c 
> > b/drivers/gpu/drm/msm/msm_iommu.c
> > index 1b6635504069..f455c597f76d 100644
> > --- a/drivers/gpu/drm/msm/msm_iommu.c
> > +++ b/drivers/gpu/drm/msm/msm_iommu.c
> > @@ -4,15 +4,192 @@
> >* Author: Rob Clark 
> >*/
> >
> > +#include 
> >   #include "msm_drv.h"
> >   #include "msm_mmu.h"
> >
> >   struct msm_iommu {
> >   struct msm_mmu base;
> >   struct iommu_domain *domain;
> > + struct iommu_domain *aux_domain;
> >   };
> > +
> >   #define to_msm_iommu(x) container_of(x, struct msm_iommu, base)
> >
> > +struct msm_iommu_pagetable {
> > + struct msm_mmu base;
> > + struct msm_mmu *parent;
> > + struct io_pgtable_ops *pgtbl_ops;
> > + phys_addr_t ttbr;
> > + u32 asid;
> > +};
> > +
> > +static struct msm_iommu_pagetable *to_pagetable(struct msm_mmu *mmu)
> > +{
> > + return container_of(mmu, struct msm_iommu_pagetable, base);
> > +}
> > +
> > +static int msm_iommu_pagetable_unmap(struct msm_mmu *mmu, u64 iova,
> > + size_t size)
> > +{
> > + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> > + struct io_pgtable_ops *ops = pagetable->pgtbl_ops;
> > + size_t unmapped = 0;
> > +
> > + /* Unmap the block one page at a time */
> > + while (size) {
> > + unmapped += ops->unmap(ops, iova, 4096, NULL);
> > + iova += 4096;
> > + size -= 4096;
> > + }
> > +
> > + iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
> > +
> > + return (unmapped == size) ? 0 : -EINVAL;
> > +}
>
> Remember in patch #1 when you said "Then 'domain' can be used like any
> other iommu domain to map and unmap iova addresses in the pagetable."?
>
> This appears to be very much not that :/
>

I guess that comment is a bit stale.. the original plan was to create
an iommu_domain per set of pgtables, but at some point we realized
that by using the io-pgtable helpers directly, we would inflict a lot
less GPU-crazy on the iommu drivers

BR,
-R

> Robin.
>
> > +
> > +static int msm_iommu_pagetable_map(struct msm_mmu *mmu, u64 iova,
> > + struct sg_table *sgt, size_t len, int prot)
> > +{
> > + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> > + struct io_pgtable_ops *ops = pagetable->pgtbl_ops;
> > + struct scatterlist *sg;
> > + size_t mapped = 0;
> > + u64 addr = iova;
> > + unsigned int i;
> > +
> > + for_each_sg(sgt->sgl, sg, sgt->nents, i) {
> > + size_t size = sg->length;
> > + phys_addr_t phys = sg_phys(sg);
> > +
> > + /* Map the block one page at a time */
> > + while (size) {
> > + if (ops->map(ops, addr, phys, 4096, prot)) {
> > + msm_iommu_pagetable_unmap(mmu, iova, mapped);
> > + return -EINVAL;
> > + }
> > +
> > + phys += 4096;
> > + addr += 4096;
> > + size -= 4096;
> > + mapped += 4096;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void msm_iommu_pagetable_destroy(struct msm_mmu *mmu)
> > +{
> > + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> > +
> > + free_io_pgtable_ops(pagetable->pgtbl_ops);
> > + kfree(pagetable);
> > +}
> > +
> > +/*
> > + * Given a parent device, create and return an aux domain. This will 
> > enable the
> > + * TTBR0 region
> > + */
> > +static struct iommu_domain *msm_iommu_get_aux_domain(struct msm_mmu 
> > *parent)
> > +{
> > + struct msm_iommu *iommu = to_msm_iommu(parent);
> > + struct iommu_domain *domain;
> > + int ret;
> > +
> > + if (iommu->aux_domain)
> > + return iommu->aux_domain;

Re: [RFC PATCH 0/4] DSI/DBI and TinyDRM driver

2020-07-07 Thread Noralf Trønnes

(cc Dillon)

Den 03.07.2020 19.26, skrev Sam Ravnborg:
> Hi Noralf/Paul.
> 
> Trying to stir up this discussion again.
> 
> On Sun, Jun 14, 2020 at 06:36:22PM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 07.06.2020 15.38, skrev Paul Cercueil:
>>> Hi,
>>>
>>> Here's a follow-up on the previous discussion about the current state of
>>> DSI/DBI panel drivers, TinyDRM, and the need of a cleanup.
>>>
>>> This patchset introduces the following:
>>> * It slightly tweaks the MIPI DSI code so that it supports MIPI DBI over
>>>   various buses. This patch has been tested with a non-upstream DRM
>>>   panel driver for a ILI9331 DBI/8080 panel, written with the DSI
>>>   framework (and doesn't include ), and non-upstream
>>>   DSI/DBI host driver for the Ingenic SoCs.
>>>
>>> * A SPI DBI host driver, using the current MIPI DSI framework. It allows
>>>   MIPI DSI/DBI drivers to be written with the DSI framework, even if
>>>   they are connected over SPI, instead of registering as SPI device
>>>   drivers. Since most of these panels can be connected over various
>>>   buses, it permits to reuse the same driver independently of the bus
>>>   used.
>>>
>>> * A TinyDRM driver for DSI/DBI panels, once again independent of the bus
>>>   used; the only dependency (currently) being that the panel must
>>>   understand DCS commands.
>>>
>>> * A DRM panel driver to test the stack. This driver controls Ilitek
>>>   ILI9341 based DBI panels, like the Adafruit YX240QV29-T 320x240 2.4"
>>>   TFT LCD panel. This panel was converted from
>>>   drivers/gpu/drm/tiny/ili9341.c.
>>>
>>> I would like to emphasize that while it has been compile-tested, I did
>>> not test it with real hardware since I do not have any DBI panel
>>> connected over SPI. I did runtime-test the code, just without any panel
>>> connected.
>>>
>>> Another thing to note, is that it does not break Device Tree ABI. The
>>> display node stays the same:
>>>
>>> display@0 {
>>> compatible = "adafruit,yx240qv29", "ilitek,ili9341";
>>> reg = <0>;
>>> spi-max-frequency = <3200>;
>>> dc-gpios = < 9 GPIO_ACTIVE_HIGH>;
>>> reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
>>> rotation = <270>;
>>> backlight = <>;
>>> };
>>>
>>> The reason it works, is that the "adafruit,yx240qv29" device is probed
>>> on the SPI bus, so it will match with the SPI/DBI host driver. This will
>>> in turn register the very same node with the DSI bus, and the ILI9341
>>> DRM panel driver will probe. The driver will detect that no controller
>>> is linked to the panel, and eventually register the DBI/DSI TinyDRM
>>> driver.
>>>
>>> I can't stress it enough that this is a RFC, so it still has very rough
>>> edges.
>>>
>>
>> I don't know bridge and dsi drivers so I can't comment on that, but one
>> thing I didn't like is that the DT compatible string has to be added to
>> 2 different modules.
>>
>> As an example, a MI0283QT panel (ILI9341) supports these interface options:
>>
>> 1. SPI
>>Panel setup/control and framebuffer upload over SPI
>>
>> 2. SPI + DPI
>>Panel setup/control over SPI, framebuffer scanout over DPI
>>
>> 3. Parallel bus
>>Panel setup/control and framebuffer upload over parallel bus
> 
> To continue the configurations we should support:
> - Panels where the chip can be configured to SPI, SPI+DPI, Parallel bus
>   (as detailed by Noralf above)
> - Panels that supports only 6800 or 8080 - connected via GPIO pins or
>   memory mapped (maybe behind some special IP to support this)
>   Command set is often special.
> 
> We will see a number of chips with many different types of displays.
> So the drivers should be chip specific with configuration depending on
> the connected display.
> 
> What I hope we can find a solution for is a single file/driver that can
> support all the relevant interface types for a chip.
> So we would end up with a single file that included the necessary
> support for ili9341 in all interface configurations with the necessary
> support for the relevant displays.
> 
> I do not know how far we are from this as I have not dived into the
> details of any of the proposals.

In an ideal world I would have liked to see the MIPI DBI parallel
interface implemented using a new Linux parallel bus type. It could have
drivers for gpio bitbanging and mmio in addition to other hw specific
drivers. Now we could have a drm_mipi_dbi DRM driver that registers as a
SPI client driver and a Parallel bus client driver. Or it can be a
component driver for the existing DRM driver on the SoC.

I had plans to do this and made a prototype, but dropped it since it
would probably require a lot of work getting in a new Linux bus type.

However if we're going to treat this parallel bus only as a MIPI DBI
display interface but support gpio bitbanging and mmio as well, then we
could add DRM drivers for each MIPI DBI bus (that don't have special
parallel bus hw):
- mipi-dbi-spi
- mipi-dbi-gpio
- mipi-dbi-mmio

These drivers will register as a mipi_dsi_host adapted like

Re: [PATCH] drm/meson: overlay: fix build failure

2020-07-07 Thread Neil Armstrong

On 07/07/2020 15:50, Neil Armstrong wrote:
> The recent GCC compiler is very picky with the VD_H_START() and
> AFBC_DEC_PIXEL_BGN_H() macros, triggering a runtime assert error as:
> 
> In function 'meson_overlay_setup_scaler_params',
> inlined from 'meson_overlay_atomic_update' at
> drivers/gpu/drm/meson/meson_overlay.c:542:2:
> ./include/linux/compiler.h:392:38: error: call to
> '__compiletime_assert_341' declared with attribute error: FIELD_PREP:
> value too large for the field
> 
> drivers/gpu/drm/meson/meson_overlay.c:413:4: note: in expansion of macro
> 'AFBC_DEC_PIXEL_BGN_H'
>   413 |AFBC_DEC_PIXEL_BGN_H(hd_start_lines - afbc_left) |
>   |^~~~
> ./include/linux/compiler.h:392:38: error: call to
> '__compiletime_assert_401' declared with attribute error: FIELD_PREP:
> value too large for the field
> 
> It's not expected to overflow these fields, but the compiler did
> find a case where it overflows.
> We can safely ignore this, so mask the value with the field width.
> 
> Fixes: e860785d57306 ("drm/meson: overlay: setup overlay for Amlogic FBC")
> Signed-off-by: Neil Armstrong 
> Acked-by: Daniel Vetter 
> ---
> Got Daniel's Ack from irc
> 
>  drivers/gpu/drm/meson/meson_overlay.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_overlay.c 
> b/drivers/gpu/drm/meson/meson_overlay.c
> index 1f7b2055e012..646e605f30f3 100644
> --- a/drivers/gpu/drm/meson/meson_overlay.c
> +++ b/drivers/gpu/drm/meson/meson_overlay.c
> @@ -58,7 +58,8 @@
>  
>  /* VPP_POSTBLEND_VD1_H_START_END */
>  #define VD_H_END(value)  FIELD_PREP(GENMASK(11, 0), 
> value)
> -#define VD_H_START(value)FIELD_PREP(GENMASK(27, 16), value)
> +#define VD_H_START(value)FIELD_PREP(GENMASK(27, 16), \
> +(value & GENMASK(13, 0)))
>  
>  /* VPP_POSTBLEND_VD1_V_START_END */
>  #define VD_V_END(value)  FIELD_PREP(GENMASK(11, 0), 
> value)
> @@ -144,7 +145,8 @@
>  #define AFBC_MIF_BLK_END_V(value)FIELD_PREP(GENMASK(11, 0), value)
>  
>  /* AFBC_PIXEL_HOR_SCOPE */
> -#define AFBC_DEC_PIXEL_BGN_H(value)  FIELD_PREP(GENMASK(28, 16), value)
> +#define AFBC_DEC_PIXEL_BGN_H(value)  FIELD_PREP(GENMASK(28, 16), \
> +(value & GENMASK(12, 0)))
>  #define AFBC_DEC_PIXEL_END_H(value)  FIELD_PREP(GENMASK(12, 0), value)
>  
>  /* AFBC_PIXEL_VER_SCOPE */
> 

Applied to drm-misc-next
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 01/36] drm: prime: add common helper to check scatterlist contiguity



On 19.06.2020 12:36, Marek Szyprowski wrote:
> It is a common operation done by DRM drivers to check the contiguity
> of the DMA-mapped buffer described by a scatterlist in the
> sg_table object. Let's add a common helper for this operation.
>
> Signed-off-by: Marek Szyprowski 
> ---
>   drivers/gpu/drm/drm_gem_cma_helper.c | 23 +++--
>   drivers/gpu/drm/drm_prime.c  | 31 
>   include/drm/drm_prime.h  |  2 ++
>   3 files changed, 36 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 06a5b9ee1fe0..41566a15dabd 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -471,26 +471,9 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
>   {
>   struct drm_gem_cma_object *cma_obj;
>   
> - if (sgt->nents != 1) {
> - /* check if the entries in the sg_table are contiguous */
> - dma_addr_t next_addr = sg_dma_address(sgt->sgl);
> - struct scatterlist *s;
> - unsigned int i;
> -
> - for_each_sg(sgt->sgl, s, sgt->nents, i) {
> - /*
> -  * sg_dma_address(s) is only valid for entries
> -  * that have sg_dma_len(s) != 0
> -  */
> - if (!sg_dma_len(s))
> - continue;
> -
> - if (sg_dma_address(s) != next_addr)
> - return ERR_PTR(-EINVAL);
> -
> - next_addr = sg_dma_address(s) + sg_dma_len(s);
> - }
> - }
> + /* check if the entries in the sg_table are contiguous */
> + if (drm_prime_get_contiguous_size(sgt) < attach->dmabuf->size)
> + return ERR_PTR(-EINVAL);
>   
>   /* Create a CMA GEM buffer. */
>   cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size);
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index bbfc713bfdc3..226cd6ad3985 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -825,6 +825,37 @@ struct sg_table *drm_prime_pages_to_sg(struct page 
> **pages, unsigned int nr_page
>   }
>   EXPORT_SYMBOL(drm_prime_pages_to_sg);
>   
> +/**
> + * drm_prime_get_contiguous_size - returns the contiguous size of the buffer
> + * @sgt: sg_table describing the buffer to check
> + *
> + * This helper calculates the contiguous size in the DMA address space
> + * of the the buffer described by the provided sg_table.
> + *
> + * This is useful for implementing
> + * _gem_object_funcs.gem_prime_import_sg_table.
> + */
> +unsigned long drm_prime_get_contiguous_size(struct sg_table *sgt)
> +{
> + dma_addr_t expected = sg_dma_address(sgt->sgl);
> + struct scatterlist *sg;
> + unsigned long size = 0;
> + int i;
> +
> + for_each_sgtable_dma_sg(sgt, sg, i) {
> + unsigned int len = sg_dma_len(sg);
> +
> + if (!len)
> + break;


I wander if in some dark corners of the kernel 0-length buffers can be 
in use :)


> + if (sg_dma_address(sg) != expected)
> + break;
> + expected += len;
> + size += len;
> + }
> + return size;
> +}
> +EXPORT_SYMBOL(drm_prime_get_contiguous_size);
> +
>   /**
>* drm_gem_prime_export - helper library implementation of the export 
> callback
>* @obj: GEM object to export
> diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
> index 9af7422b44cf..47ef11614627 100644
> --- a/include/drm/drm_prime.h
> +++ b/include/drm/drm_prime.h
> @@ -92,6 +92,8 @@ struct sg_table *drm_prime_pages_to_sg(struct page **pages, 
> unsigned int nr_page
>   struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj,
>int flags);
>   
> +unsigned long drm_prime_get_contiguous_size(struct sg_table *sgt);
> +

Reviewed-by 

Regards
Andrzej


>   /* helper functions for importing */
>   struct drm_gem_object *drm_gem_prime_import_dev(struct drm_device *dev,
>   struct dma_buf *dma_buf,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm/vgem: Don't use get_page in fault handler.

2020-07-07 Thread Christian König

Am 07.07.20 um 14:05 schrieb Thomas Hellström (Intel):

On 7/7/20 1:07 PM, Chris Wilson wrote:

Quoting Christian König (2020-07-07 11:58:26)

Am 07.07.20 um 10:59 schrieb Daniel Vetter:

On Tue, Jul 7, 2020 at 9:27 AM Lepton Wu wrote:

For pages which are allocated in ttm with transparent huge pages,
tail pages have zero as reference count. The current vgem code use
get_page on them and it will trigger BUG when release_pages get
called

on those pages later.

fine. But it's there for fix another bug:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D103138data=02%7C01%7Cchristian.koenig%40amd.com%7C6c4170559c0a4d0d5f5708d8226e0f97%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637297203404761846sdata=qXBQBKvBM7zvi6PIkcAPfBjmOC8UrKmjnO03hWKzNHU%3Dreserved=0

It could also be "fixed" with this patch. But I am really not sure
if this is

the way to go.

For imported dma-buf objects, vgem should not handle this itself, but
forward to the exporter through the dma_buf_mmap stuff. We have
helpers for this all now, probably just not wired up correctly. Trying
to ensure that all combinations of mmap code across all drivers work
the same doesn't work.
Yes, Daniel is right what vgem does here is fundamentally broken in
many

ways.

First of all nobody should ever call get_page() on the pages TTM has
allocated. Those pages come out of a block box and should not be
touched

by anybody.
It doesn't. It's only used on the pages vgem allocates (from
shmemfs). So

I'm really confused as to how ttm gets involved here.
-Chris

Sounds like vgem is allowing mmap of imported dma-bufs?

Yeah agree, this is most likely the underlying problem and should be
fixed instead.

Christian.

/Thomas

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cchristian.koenig%40amd.com%7C6c4170559c0a4d0d5f5708d8226e0f97%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637297203404761846sdata=Ny4sdibo9o8%2F8UqxdP74HaOXQjoKkmd%2FrRAPHszr3rk%3Dreserved=0

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

[PATCH] drm/meson: overlay: fix build failure

2020-07-07 Thread Neil Armstrong

The recent GCC compiler is very picky with the VD_H_START() and
AFBC_DEC_PIXEL_BGN_H() macros, triggering a runtime assert error as:

In function 'meson_overlay_setup_scaler_params',
inlined from 'meson_overlay_atomic_update' at
drivers/gpu/drm/meson/meson_overlay.c:542:2:
./include/linux/compiler.h:392:38: error: call to
'__compiletime_assert_341' declared with attribute error: FIELD_PREP:
value too large for the field

drivers/gpu/drm/meson/meson_overlay.c:413:4: note: in expansion of macro
'AFBC_DEC_PIXEL_BGN_H'
  413 |AFBC_DEC_PIXEL_BGN_H(hd_start_lines - afbc_left) |
  |^~~~
./include/linux/compiler.h:392:38: error: call to
'__compiletime_assert_401' declared with attribute error: FIELD_PREP:
value too large for the field

It's not expected to overflow these fields, but the compiler did
find a case where it overflows.
We can safely ignore this, so mask the value with the field width.

Fixes: e860785d57306 ("drm/meson: overlay: setup overlay for Amlogic FBC")
Signed-off-by: Neil Armstrong 
Acked-by: Daniel Vetter 
---
Got Daniel's Ack from irc

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

diff --git a/drivers/gpu/drm/meson/meson_overlay.c 
b/drivers/gpu/drm/meson/meson_overlay.c
index 1f7b2055e012..646e605f30f3 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -58,7 +58,8 @@
 
 /* VPP_POSTBLEND_VD1_H_START_END */
 #define VD_H_END(value)FIELD_PREP(GENMASK(11, 0), 
value)
-#define VD_H_START(value)  FIELD_PREP(GENMASK(27, 16), value)
+#define VD_H_START(value)  FIELD_PREP(GENMASK(27, 16), \
+  (value & GENMASK(13, 0)))
 
 /* VPP_POSTBLEND_VD1_V_START_END */
 #define VD_V_END(value)FIELD_PREP(GENMASK(11, 0), 
value)
@@ -144,7 +145,8 @@
 #define AFBC_MIF_BLK_END_V(value)  FIELD_PREP(GENMASK(11, 0), value)
 
 /* AFBC_PIXEL_HOR_SCOPE */
-#define AFBC_DEC_PIXEL_BGN_H(value)FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_DEC_PIXEL_BGN_H(value)FIELD_PREP(GENMASK(28, 16), \
+  (value & GENMASK(12, 0)))
 #define AFBC_DEC_PIXEL_END_H(value)FIELD_PREP(GENMASK(12, 0), value)
 
 /* AFBC_PIXEL_VER_SCOPE */
-- 
2.22.0

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

Re: [PATCH v7 04/36] drm: amdgpu: fix common struct sg_table related issues

2020-07-07 Thread Marek Szyprowski

Hi Christian,

On 22.06.2020 15:27, Christian König wrote:
> Am 19.06.20 um 12:36 schrieb Marek Szyprowski:
>> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() 
>> function
>> returns the number of the created entries in the DMA address space.
>> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
>> dma_unmap_sg must be called with the original number of the entries
>> passed to the dma_map_sg().
>>
>> struct sg_table is a common structure used for describing a 
>> non-contiguous
>> memory buffer, used commonly in the DRM and graphics subsystems. It
>> consists of a scatterlist with memory pages and DMA addresses (sgl 
>> entry),
>> as well as the number of scatterlist entries: CPU pages (orig_nents 
>> entry)
>> and DMA mapped pages (nents entry).
>>
>> It turned out that it was a common mistake to misuse nents and 
>> orig_nents
>> entries, calling DMA-mapping functions with a wrong number of entries or
>> ignoring the number of mapped entries returned by the dma_map_sg()
>> function.
>>
>> To avoid such issues, lets use a common dma-mapping wrappers operating
>> directly on the struct sg_table objects and use scatterlist page
>> iterators where possible. This, almost always, hides references to the
>> nents and orig_nents entries, making the code robust, easier to follow
>> and copy/paste safe.
>>
>> Signed-off-by: Marek Szyprowski 
>> Reviewed-by: Christian König 
>
> Any objection that we pick this one and the radeon up into our 
> branches for upstreaming?
>
> That should about clashes with other driver changes.

I'm fine. This one and radeon doesn't depend on the prime changes, so it 
should merge fine via your tree. I will try to ask for more review of 
the remaining patches and then try merging via drm-misc.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

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

Re: [PATCH v5] drm/doc: device hot-unplug for userspace

2020-07-07 Thread Simon Ser

On Tuesday, July 7, 2020 1:38 PM, Pekka Paalanen  wrote:

> From: Pekka Paalanen pekka.paala...@collabora.com
>
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
>
> Written by Daniel Vetter's request and largely based on his comments in IRC 
> and
> from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
>
> A related Wayland protocol change proposal is at
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35
>
> Signed-off-by: Pekka Paalanen pekka.paala...@collabora.com
> Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
> Reviewed-by: Alex Deucher alexander.deuc...@amd.com
> Acked-by: Noralf Trønnes nor...@tronnes.org
> Cc: Andrey Grodzovsky andrey.grodzov...@amd.com
> Cc: Dave Airlie airl...@redhat.com
> Cc: Sean Paul s...@poorly.run
> Cc: Simon Ser cont...@emersion.fr
> Cc: Ben Skeggs skeg...@gmail.com
> Cc: Karol Herbst kher...@redhat.com

From a user-space point-of-view, this sounds fine.

Acked-by: Simon Ser 

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

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

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

--- Comment #45 from Fabian Möller (fabian...@gmail.com) ---
(In reply to Christopher Snowhill from comment #43)
> What about this patch?
> 
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.
> 8=6eb3cf2e06d22b2b08e6b0ab48cb9c05a8e1a107

Applying 6eb3cf2e06d22b2b08e6b0ab48cb9c05a8e1a107 to v5.7.7 fixed the issue for
a RX5700/Navi10 under Wayland for me. 
It still produces the following log, which might be related to
https://bugzilla.kernel.org/show_bug.cgi?id=206349.

[ cut here ]
WARNING: CPU: 2 PID: 1176 at arch/x86/kernel/fpu/core.c:109
kernel_fpu_end+0x19/0x20
Modules linked in: fuse xt_conntrack xt_MASQUERADE nf_conntrack_netlink
nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat
nf_conntrack nf_defrag_ipv4 br_netfilter overlay wireguard curve25519_x86_64
libchacha20poly1305 chacha_x86_64 poly1305_x86_64 libblake2s blake2s_x86_64
ip6_udp_tunnel udp_tunnel libcurve25519_generic libchacha libblake2s_generic
af_packet rfkill msr amdgpu amd_iommu_v2 gpu_sched ttm drm_kms_helper drm
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi
wmi_bmof mxm_wmi snd_hda_intel nls_iso8859_1 agpgart igb deflate nls_cp437
snd_intel_dspcfg sp5100_tco ptp mousedev vfat efi_pstore fb_sys_fops evdev fat
snd_hda_codec edac_mce_amd pstore mac_hid syscopyarea watchdog pps_core
sysfillrect edac_core snd_hda_core sysimgblt dca i2c_piix4 backlight
crc32_pclmul i2c_algo_bit ghash_clmulni_intel efivars k10temp snd_hwdep
i2c_core thermal wmi pinctrl_amd tiny_power_button button acpi_cpufreq
sch_fq_codel snd_pcm_oss
 snd_mixer_oss snd_pcm snd_timer snd soundcore atkbd libps2 serio loop
cpufreq_ondemand tun tap macvlan bridge stp llc vboxnetflt(OE) vboxnetadp(OE)
vboxdrv(OE) kvm_amd kvm irqbypass efivarfs ip_tables x_tables ipv6
nf_defrag_ipv6 crc_ccitt autofs4 xfs libcrc32c crc32c_generic dm_crypt
algif_skcipher af_alg input_leds led_class hid_generic usbhid hid ahci xhci_pci
libahci crc32c_intel xhci_hcd libata aesni_intel libaes crypto_simd nvme
usbcore cryptd scsi_mod glue_helper nvme_core t10_pi crc_t10dif
crct10dif_generic crct10dif_pclmul usb_common crct10dif_common rtc_cmos
dm_snapshot dm_bufio dm_mod
CPU: 2 PID: 1176 Comm: systemd-logind Tainted: G   OE 5.7.7
#1-NixOS
Hardware name: Gigabyte Technology Co., Ltd. X570 AORUS PRO/X570 AORUS PRO,
BIOS F10c 11/08/2019
RIP: 0010:kernel_fpu_end+0x19/0x20
Code: 90 e9 db 9b 14 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 65 8a
05 5c 1a 3e 66 84 c0 74 09 65 c6 05 50 1a 3e 66 00 c3 <0f> 0b eb f3 0f 1f 00 0f
1f 44 00 00 8b 15 cd 59 57 01 31 f6 e8 2e
RSP: 0018:b9dbc1417660 EFLAGS: 00010246
RAX:  RBX:  RCX: 121b
RDX: 0001 RSI: 90b685fa1cd4 RDI: 0002f980
RBP: 90b685fa R08:  R09: 0040
R10: b9dbc14175b0 R11: b9dbc14170a0 R12: 0001
R13: 90b685fa1da8 R14: 0006 R15: 90b5158f8400
FS:  7fd7ab143880() GS:90b6bea8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0e81091ef030 CR3: 0007d80c4000 CR4: 00340ee0
Call Trace:
 dcn20_validate_bandwidth+0x2c/0x40 [amdgpu]
 dc_commit_updates_for_stream+0xad7/0x1930 [amdgpu]
 ? amdgpu_display_get_crtc_scanoutpos+0x85/0x190 [amdgpu]
 amdgpu_dm_atomic_commit_tail+0xb4c/0x1fc0 [amdgpu]
 commit_tail+0x94/0x130 [drm_kms_helper]
 drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper]
 drm_client_modeset_commit_atomic+0x1c9/0x200 [drm]
 drm_client_modeset_commit_locked+0x50/0x150 [drm]
 __drm_fb_helper_restore_fbdev_mode_unlocked+0x59/0xc0 [drm_kms_helper]
 drm_fb_helper_set_par+0x3c/0x50 [drm_kms_helper]
 fb_set_var+0x175/0x370
 ? update_load_avg+0x78/0x630
 ? update_curr+0x69/0x1a0
 fbcon_blank+0x20d/0x270
 do_unblank_screen+0xaa/0x150
 complete_change_console+0x54/0xd0
 vt_ioctl+0x126f/0x1320
 tty_ioctl+0x372/0x8c0
 ksys_ioctl+0x87/0xc0
 __x64_sys_ioctl+0x16/0x20
 do_syscall_64+0x4e/0x160
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fd7ab75d1c7
Code: 00 00 90 48 8b 05 b9 9c 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff
c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01
c3 48 8b 0d 89 9c 0c 00 f7 d8 64 89 01 48
RSP: 002b:7ffe9138fec8 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX:  RCX: 7fd7ab75d1c7
RDX: 0001 RSI: 5605 RDI: 0015
RBP: 0015 R08:  R09: 
R10: 0001 R11: 0246 R12: 7ffe9138ff38
R13: 0006 R14: 7ffe91390050 R15: 7ffe91390048
---[ end trace eefc00b763354df8 ]---

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

Re: [RFC] drm/vgem: Don't use get_page in fault handler.

Quoting Thomas Hellström (Intel) (2020-07-07 13:05:31)
> 
> On 7/7/20 1:07 PM, Chris Wilson wrote:
> > Quoting Christian König (2020-07-07 11:58:26)
> >> Am 07.07.20 um 10:59 schrieb Daniel Vetter:
> >>> On Tue, Jul 7, 2020 at 9:27 AM Lepton Wu  wrote:
>  For pages which are allocated in ttm with transparent huge pages,
>  tail pages have zero as reference count. The current vgem code use
>  get_page on them and it will trigger BUG when release_pages get called
>  on those pages later.
> 
>  Here I attach the minimal code to trigger this bug on a qemu VM which
>  enables virtio gpu (card1) and vgem (card0). BTW, since the upstream
>  virtio gpu has changed to use drm gem and moved away from ttm. So we
>  have to use an old kernel like 5.4 to reproduce it. But I guess
>  same thing could happen for a real GPU if the real GPU use similar code
>  path to allocate pages from ttm. I am not sure about two things: first, 
>  do we
>  need to fix this? will a real GPU hit this code path? Second, suppose 
>  this
>  need to be fixed, should this be fixed in ttm side or vgem side?  If we 
>  remove
>  "huge_flags &= ~__GFP_COMP" from ttm_get_pages, then get_page in vgem 
>  works
>  fine. But it's there for fix another bug:
>  https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D103138data=02%7C01%7Cchristian.koenig%40amd.com%7Cfc0831be8fd848abfd8908d82254266d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637297092113216357sdata=S%2BtLJyB8mqyyE%2BSIjbfHM6FGFuFjrfI50tahpaoJ3wU%3Dreserved=0
>  It could also be "fixed" with this patch. But I am really not sure if 
>  this is
>  the way to go.
> >>> For imported dma-buf objects, vgem should not handle this itself, but
> >>> forward to the exporter through the dma_buf_mmap stuff. We have
> >>> helpers for this all now, probably just not wired up correctly. Trying
> >>> to ensure that all combinations of mmap code across all drivers work
> >>> the same doesn't work.
> >> Yes, Daniel is right what vgem does here is fundamentally broken in many
> >> ways.
> >>
> >> First of all nobody should ever call get_page() on the pages TTM has
> >> allocated. Those pages come out of a block box and should not be touched
> >> by anybody.
> > It doesn't. It's only used on the pages vgem allocates (from shmemfs). So
> > I'm really confused as to how ttm gets involved here.
> > -Chris
> 
> Sounds like vgem is allowing mmap of imported dma-bufs?

It has vgem_prime_mmap(): if (!obj->filp) return -ENODEV;

Ah, vgem_prime_import_sg_table is where the wires get crossed.
Oh my, and that even calls __vgem_gem_create() so it ends up with a
dummy obj->filp from drm_gem_object_init.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm/doc: device hot-unplug for userspace