[PATCH v5 0/2] drm/i915: Finish conversion to GRAPHICS_VER

2021-06-05 Thread Lucas De Marchi
v3 is a resend from v2 (https://patchwork.freedesktop.org/series/90693/)
now with dri-devel Cc'ed. Notice that this patch series can be applied
splitting it up through the trees, it's not necessary to apply them
together. The intention is to apply first 3 patches on drm-intel-gt-next
and the remaining on drm-intel-next.  I'm intentionally _not_ removing
the INTEL_GEN/IS_GEN/IS_GEN_RANGE macros now. A few days/weeks after
this is applied and when drm-intel-gt-next and drm-intel-next is back in
sync, we can remove any leftovers that went in and remove the macros via
a topic branch.

Latest version of previous series "drm/i915: Extend GEN renames to the
rest of the driver" (https://patchwork.freedesktop.org/series/88825/)
dropped one patch converting all the instances of IS_GEN() and
INTEL_GEN() to GRAPHICS_VER() due to the patches changing the
meaning of the macros IS_GRAPHICS_VER/GRAPHICS_VER and removal of
IS_GRAPHICS_RANGE().

I couldn't find a way to convince coccinelle to fix all places, so I
just did it manually in separate commits the places that were not
updated.

Finish the conversion splitting the changes so it can go to the
different branches (drm-intel-gt-next and drm-intel-next). I also split
the gvt changes, but I think it would be easier to take this directly on
drm-intel-next.

v2: update commit messages with the proper semantic patch (Matt Roper)
and regenerate the patches to also convert changes that got added in
between.

v3: resend with dri-devel Cc'ed since we are touching gt/gem/core. Also,
let's get an ack on merge strategy

v4: rebase and remove patches already applied

v5: rebase, remove patches already applied and remove changes that conflict
with drm-intel-gt-next - they will be removed converted later, together with
the removal of the old macros.

Lucas De Marchi (2):
  drm/i915: replace IS_GEN and friends with GRAPHICS_VER
  drm/i915: Add remaining conversions to GRAPHICS_VER

 drivers/gpu/drm/i915/i915_cmd_parser.c| 10 +--
 drivers/gpu/drm/i915/i915_debugfs.c   | 30 +++
 drivers/gpu/drm/i915/i915_drv.c   | 20 ++---
 drivers/gpu/drm/i915/i915_drv.h   | 37 +
 drivers/gpu/drm/i915/i915_gem.c   |  4 +-
 drivers/gpu/drm/i915/i915_gpu_error.c | 80 +--
 drivers/gpu/drm/i915/i915_irq.c   | 34 
 drivers/gpu/drm/i915/i915_perf.c  | 44 +-
 drivers/gpu/drm/i915/i915_pmu.c   |  8 +-
 drivers/gpu/drm/i915/i915_reg.h   | 26 +++---
 drivers/gpu/drm/i915/i915_request.c   |  4 +-
 drivers/gpu/drm/i915/i915_suspend.c   | 16 ++--
 drivers/gpu/drm/i915/i915_sysfs.c |  2 +-
 drivers/gpu/drm/i915/i915_vgpu.c  |  2 +-
 drivers/gpu/drm/i915/intel_device_info.c  | 22 ++---
 drivers/gpu/drm/i915/intel_dram.c | 14 ++--
 drivers/gpu/drm/i915/intel_pch.c  | 10 +--
 drivers/gpu/drm/i915/intel_pm.c   | 14 ++--
 drivers/gpu/drm/i915/intel_sideband.c |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c   | 24 +++---
 drivers/gpu/drm/i915/intel_wopcm.c| 10 +--
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  4 +-
 drivers/gpu/drm/i915/selftests/i915_perf.c|  6 +-
 drivers/gpu/drm/i915/selftests/i915_request.c |  8 +-
 drivers/gpu/drm/i915/selftests/igt_spinner.c  | 12 +--
 drivers/gpu/drm/i915/selftests/intel_uncore.c |  2 +-
 26 files changed, 222 insertions(+), 223 deletions(-)

-- 
2.31.1



[PATCH v5 1/2] drm/i915: replace IS_GEN and friends with GRAPHICS_VER

2021-06-05 Thread Lucas De Marchi
This was done by the following semantic patch:

@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)

@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E

@@ expression dev_priv; expression E; @@
- !IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) != E

@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) == E

@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_VER(dev_priv, from, until)

@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)

@@
identifier def.id;
@@
- id
+ ver

It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".

Signed-off-by: Lucas De Marchi 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c| 10 +--
 drivers/gpu/drm/i915/i915_debugfs.c   | 30 +++
 drivers/gpu/drm/i915/i915_drv.c   | 20 ++---
 drivers/gpu/drm/i915/i915_gem.c   |  4 +-
 drivers/gpu/drm/i915/i915_gpu_error.c | 80 +--
 drivers/gpu/drm/i915/i915_irq.c   | 34 
 drivers/gpu/drm/i915/i915_perf.c  | 44 +-
 drivers/gpu/drm/i915/i915_pmu.c   |  8 +-
 drivers/gpu/drm/i915/i915_request.c   |  4 +-
 drivers/gpu/drm/i915/i915_suspend.c   | 16 ++--
 drivers/gpu/drm/i915/i915_sysfs.c |  2 +-
 drivers/gpu/drm/i915/i915_vgpu.c  |  2 +-
 drivers/gpu/drm/i915/intel_device_info.c  | 22 ++---
 drivers/gpu/drm/i915/intel_dram.c | 14 ++--
 drivers/gpu/drm/i915/intel_pch.c  | 10 +--
 drivers/gpu/drm/i915/intel_pm.c   | 14 ++--
 drivers/gpu/drm/i915/intel_sideband.c |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c   | 24 +++---
 drivers/gpu/drm/i915/intel_wopcm.c| 10 +--
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  4 +-
 drivers/gpu/drm/i915/selftests/i915_perf.c|  6 +-
 drivers/gpu/drm/i915/selftests/i915_request.c |  8 +-
 drivers/gpu/drm/i915/selftests/igt_spinner.c  | 12 +--
 drivers/gpu/drm/i915/selftests/intel_uncore.c |  2 +-
 24 files changed, 191 insertions(+), 191 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 5b4b2bd46e7c..3992c25a191d 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -946,8 +946,8 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs 
*engine)
int cmd_table_count;
int ret;
 
-   if (!IS_GEN(engine->i915, 7) && !(IS_GEN(engine->i915, 9) &&
- engine->class == COPY_ENGINE_CLASS))
+   if (GRAPHICS_VER(engine->i915) != 7 && !(GRAPHICS_VER(engine->i915) == 
9 &&
+engine->class == 
COPY_ENGINE_CLASS))
return 0;
 
switch (engine->class) {
@@ -977,7 +977,7 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs 
*engine)
break;
case COPY_ENGINE_CLASS:
engine->get_cmd_length_mask = gen7_blt_get_cmd_length_mask;
-   if (IS_GEN(engine->i915, 9)) {
+   if (GRAPHICS_VER(engine->i915) == 9) {
cmd_tables = gen9_blt_cmd_table;
cmd_table_count = ARRAY_SIZE(gen9_blt_cmd_table);
engine->get_cmd_length_mask =
@@ -993,7 +993,7 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs 
*engine)
cmd_table_count = ARRAY_SIZE(gen7_blt_cmd_table);
}
 
-   if (IS_GEN(engine->i915, 9)) {
+   if (GRAPHICS_VER(engine->i915) == 9) {
engine->reg_tables = gen9_blt_reg_tables;
engine->reg_table_count =
ARRAY_SIZE(gen9_blt_reg_tables);
@@ -1537,7 +1537,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
if (IS_HASWELL(engine->i915))
flags = MI_BATCH_NON_SECURE_HSW;
 
-   GEM_BUG_ON(!IS_GEN_RANGE(engine->i915, 6, 7));
+   GEM_BUG_ON(!IS_GRAPHICS_VER(engine->i915, 6, 
7));
__gen6_emit_bb_start(batch_end,
 batch_addr,
 flags);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a4d8a836bd57..cc745751ac53 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -361,7 +361,7 @@ 

[PATCH v5 2/2] drm/i915: Add remaining conversions to GRAPHICS_VER

2021-06-05 Thread Lucas De Marchi
For some reason coccinelle misses a few cases in header files with calls to
INTEL_GEN()/IS_GEN(). Do a manual conversion for those.

Signed-off-by: Lucas De Marchi 
Reviewed-by: Matt Roper 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20210605155356.4183026-6-lucas.demar...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h | 37 -
 drivers/gpu/drm/i915/i915_reg.h | 26 +++
 2 files changed, 31 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 91fda14f8f6c..38ff2fb89744 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1552,9 +1552,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
(IS_ALDERLAKE_P(__i915) && \
 IS_GT_STEP(__i915, since, until))
 
-#define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp)
-#define IS_GEN9_LP(dev_priv)   (IS_GEN(dev_priv, 9) && IS_LP(dev_priv))
-#define IS_GEN9_BC(dev_priv)   (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv))
+#define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp)
+#define IS_GEN9_LP(dev_priv)   (GRAPHICS_VER(dev_priv) == 9 && IS_LP(dev_priv))
+#define IS_GEN9_BC(dev_priv)   (GRAPHICS_VER(dev_priv) == 9 && 
!IS_LP(dev_priv))
 
 #define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id))
 #define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id)
@@ -1574,12 +1574,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
  * The Gen7 cmdparser copies the scanned buffer to the ggtt for execution
  * All later gens can run the final buffer from the ppgtt
  */
-#define CMDPARSER_USES_GGTT(dev_priv) IS_GEN(dev_priv, 7)
+#define CMDPARSER_USES_GGTT(dev_priv) (GRAPHICS_VER(dev_priv) == 7)
 
 #define HAS_LLC(dev_priv)  (INTEL_INFO(dev_priv)->has_llc)
 #define HAS_SNOOP(dev_priv)(INTEL_INFO(dev_priv)->has_snoop)
 #define HAS_EDRAM(dev_priv)((dev_priv)->edram_size_mb)
-#define HAS_SECURE_BATCHES(dev_priv) (INTEL_GEN(dev_priv) < 6)
+#define HAS_SECURE_BATCHES(dev_priv) (GRAPHICS_VER(dev_priv) < 6)
 #define HAS_WT(dev_priv)   HAS_EDRAM(dev_priv)
 
 #define HWS_NEEDS_PHYSICAL(dev_priv)   
(INTEL_INFO(dev_priv)->hws_needs_physical)
@@ -1612,7 +1612,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_BROKEN_CS_TLB(dev_priv)(IS_I830(dev_priv) || 
IS_I845G(dev_priv))
 
 #define NEEDS_RC6_CTX_CORRUPTION_WA(dev_priv)  \
-   (IS_BROADWELL(dev_priv) || IS_GEN(dev_priv, 9))
+   (IS_BROADWELL(dev_priv) || GRAPHICS_VER(dev_priv) == 9)
 
 /* WaRsDisableCoarsePowerGating:skl,cnl */
 #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv)   \
@@ -1620,23 +1620,22 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 IS_SKL_GT3(dev_priv) ||\
 IS_SKL_GT4(dev_priv))
 
-#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
-#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
+#define HAS_GMBUS_IRQ(dev_priv) (GRAPHICS_VER(dev_priv) >= 4)
+#define HAS_GMBUS_BURST_READ(dev_priv) (GRAPHICS_VER(dev_priv) >= 10 || \
IS_GEMINILAKE(dev_priv) || \
IS_KABYLAKE(dev_priv))
 
 /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
  * rows, which changed the alignment requirements and fence programming.
  */
-#define HAS_128_BYTE_Y_TILING(dev_priv) (!IS_GEN(dev_priv, 2) && \
-!(IS_I915G(dev_priv) || \
-IS_I915GM(dev_priv)))
+#define HAS_128_BYTE_Y_TILING(dev_priv) (GRAPHICS_VER(dev_priv) != 2 && \
+!(IS_I915G(dev_priv) || 
IS_I915GM(dev_priv)))
 #define SUPPORTS_TV(dev_priv)  
(INTEL_INFO(dev_priv)->display.supports_tv)
 #define I915_HAS_HOTPLUG(dev_priv) 
(INTEL_INFO(dev_priv)->display.has_hotplug)
 
-#define HAS_FW_BLC(dev_priv)   (INTEL_GEN(dev_priv) > 2)
+#define HAS_FW_BLC(dev_priv)   (GRAPHICS_VER(dev_priv) > 2)
 #define HAS_FBC(dev_priv)  (INTEL_INFO(dev_priv)->display.has_fbc)
-#define HAS_CUR_FBC(dev_priv)  (!HAS_GMCH(dev_priv) && INTEL_GEN(dev_priv) >= 
7)
+#define HAS_CUR_FBC(dev_priv)  (!HAS_GMCH(dev_priv) && GRAPHICS_VER(dev_priv) 
>= 7)
 
 #define HAS_IPS(dev_priv)  (IS_HSW_ULT(dev_priv) || IS_BROADWELL(dev_priv))
 
@@ -1647,7 +1646,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_PSR(dev_priv)   (INTEL_INFO(dev_priv)->display.has_psr)
 #define HAS_PSR_HW_TRACKING(dev_priv) \
(INTEL_INFO(dev_priv)->display.has_psr_hw_tracking)
-#define HAS_PSR2_SEL_FETCH(dev_priv)(INTEL_GEN(dev_priv) >= 12)
+#define HAS_PSR2_SEL_FETCH(dev_priv)(GRAPHICS_VER(dev_priv) >= 12)
 #define HAS_TRANSCODER(dev_priv, trans) 
((INTEL_INFO(dev_priv)->cpu_transcoder_mask & BIT(trans)) != 0)
 
 #define HAS_RC6(dev_priv)   (INTEL_INFO(dev_priv)->has_rc6)
@@ -1658,7 +1657,7 @@ 

Re: [PATCH v8 08/11] drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev

2021-06-05 Thread Bjorn Andersson
On Mon 24 May 19:01 CDT 2021, Douglas Anderson wrote:

> On its own, this change looks a little strange and doesn't do too much
> useful. To understand why we're doing this we need to look forward to
> future patches where we're going to probe our panel using the new DP
> AUX bus. See the patch ("drm/bridge: ti-sn65dsi86: Add support for the
> DP AUX bus").
> 
> Let's think about the set of steps we'll want to happen when we have
> the DP AUX bus:
> 
> 1. We'll create the DP AUX bus.
> 2. We'll populate the devices on the DP AUX bus (AKA our panel).
> 3. For setting up the bridge-related functions of ti-sn65dsi86 we'll
>need to get a reference to the panel.
> 
> If we do #1 - #3 in a single probe call things _mostly_ will work, but
> it won't be massively robust. Let's explore.
> 
> First let's think of the easy case of no -EPROBE_DEFER. In that case
> in step #2 when we populate the devices on the DP AUX bus it will
> actually try probing the panel right away. Since the panel probe
> doesn't defer then in step #3 we'll get a reference to the panel and
> we're golden.
> 
> Second, let's think of the case when the panel returns
> -EPROBE_DEFER. In that case step #2 won't synchronously create the
> panel (it'll just add the device to the defer list to do it
> later). Step #3 will fail to get the panel and the bridge sub-device
> will return -EPROBE_DEFER. We'll depopulate the DP AUX bus. Later
> we'll try the whole sequence again. Presumably the panel will
> eventually stop returning -EPROBE_DEFER and we'll go back to the first
> case where things were golden. So this case is OK too even if it's a
> bit ugly that we have to keep creating / deleting the AUX bus over and
> over.
> 
> So where is the problem? As I said, it's mostly about robustness. I
> don't believe that step #2 (creating the sub-devices) is really
> guaranteed to be synchronous. This is evidenced by the fact that it's
> allowed to "succeed" by just sticking the device on the deferred
> list. If anything about the process changes in Linux as a whole and
> step #2 just kicks off the probe of the DP AUX endpoints (our panel)
> in the background then we'd be in trouble because we might never get
> the panel in step #3.
> 
> Adding an extra sub-device means we just don't need to worry about
> it. We'll create the sub-device for the DP AUX bus and it won't go
> away until the whole ti-sn65dsi86 driver goes away. If the bridge
> sub-device defers (maybe because it can't find the panel) that won't
> depopulate the DP AUX bus and so we don't need to worry about it.
> 
> NOTE: there's a little bit of a trick here. Though the AUX channel can
> run without the MIPI-to-eDP bits of the code, the MIPI-to-eDP bits
> can't run without the AUX channel. We could come up a complicated
> signaling scheme (have the MIPI-to-eDP bits return EPROBE_DEFER for a
> while or wait on some sort of completion), but it seems simple enough
> to just not even bother creating the bridge device until the AUX
> channel probes. That's what we'll do.
> 
> Signed-off-by: Douglas Anderson 
> Reviewed-by: Lyude Paul 
> ---
> 
> (no changes since v7)
> 
> Changes in v7:
> - Beefed up commit message in context of the DP AUX bus.
> - Remove use of now-dropped drm_dp_aux_register_ddc() call.
> - Set the proper sub-device "dev" pointer in the AUX structure.
> 
> Changes in v6:
> - Use new drm_dp_aux_register_ddc() calls.
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 80 +++
>  1 file changed, 69 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 45a2969afb2b..1ea07d704705 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -116,6 +116,7 @@
>   * struct ti_sn65dsi86 - Platform data for ti-sn65dsi86 driver.
>   * @bridge_aux:   AUX-bus sub device for MIPI-to-eDP bridge functionality.
>   * @gpio_aux: AUX-bus sub device for GPIO controller functionality.
> + * @aux_aux:  AUX-bus sub device for eDP AUX channel functionality.
>   *
>   * @dev:  Pointer to the top level (i2c) device.
>   * @regmap:   Regmap for accessing i2c.
> @@ -148,6 +149,7 @@
>  struct ti_sn65dsi86 {
>   struct auxiliary_device bridge_aux;
>   struct auxiliary_device gpio_aux;
> + struct auxiliary_device aux_aux;
>  
>   struct device   *dev;
>   struct regmap   *regmap;
> @@ -1333,11 +1335,6 @@ static int ti_sn_bridge_probe(struct auxiliary_device 
> *adev,
>   if (ret)
>   return ret;
>  
> - pdata->aux.name = "ti-sn65dsi86-aux";
> - pdata->aux.dev = pdata->dev;
> - pdata->aux.transfer = ti_sn_aux_transfer;
> - drm_dp_aux_init(>aux);
> -
>   pdata->bridge.funcs = _sn_bridge_funcs;
>   pdata->bridge.of_node = np;
>  
> @@ -1432,6 +1429,53 @@ static int ti_sn65dsi86_add_aux_device(struct 
> ti_sn65dsi86 *pdata,
>   return 

Re: [PATCH] drm/msm: remove no need local variable

2021-06-05 Thread Stephen Boyd
Quoting Bernard Zhao (2021-06-05 05:35:20)
> Unneeded variable: "ret". Return "0" on line 880

But the variable is "rc".

>
> Signed-off-by: Bernard Zhao 
> ---

Otherwise

Reviewed-by: Stephen Boyd 


Re: [Nouveau] nouveau broken on Riva TNT2 in 5.13.0-rc4: NULL pointer dereference in nouveau_bo_sync_for_device

2021-06-05 Thread Ilia Mirkin
Another instance of a report like this here:
https://gitlab.freedesktop.org/drm/nouveau/-/issues/92

On Sat, Jun 5, 2021 at 3:53 PM Ondrej Zary  wrote:
>
> Hello,
> I'm testing 5.13.0-rc4 and nouveau crashes with NULL pointer dereference in 
> nouveau_bo_sync_for_device.
> Found various reports like this but that was back in februaryso that should 
> be fixed now.
>
> [   21.003216] BUG: kernel NULL pointer dereference, address: 
> [   21.003235] #PF: supervisor read access in kernel mode
> [   21.003243] #PF: error_code(0x) - not-present page
> [   21.003250] *pde = 
> [   21.003258] Oops:  [#1] SMP
> [   21.003268] CPU: 0 PID: 222 Comm: systemd-udevd Not tainted 5.13.0-rc4+ 
> #327
> [   21.003278] Hardware name:  /848P-ICH5, BIOS 6.00 PG 02/03/2005
> [   21.003285] EIP: nouveau_bo_sync_for_device+0x9e/0xbf [nouveau]
> [   21.003571] Code: 02 89 45 e8 01 d1 8b 19 89 5d ec bb 01 00 00 00 3b 5d e8 
> 74 0d 89 d8 c1 e0 05 03 45 ec 39 04 99 74 1e 8b 46 10 89 d9 c1 e1 0c <8b> 14 
> 10 8b 47 e0 8b 40 08 6a 01 e8 d5 03 55 df 01 5d f0 58 eb ae
> [   21.003588] EAX:  EBX: 0010 ECX: 0001 EDX: 
> [   21.003597] ESI: c3e90280 EDI: c185a494 EBP: c2ed7c10 ESP: c2ed7bf8
> [   21.003606] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00210206
> [   21.003615] CR0: 80050033 CR2:  CR3: 02ecb000 CR4: 0690
> [   21.003625] Call Trace:
> [   21.003635]  nouveau_bo_validate+0x3f/0x48 [nouveau]
> [   21.003911]  nouveau_bo_pin+0xf0/0x187 [nouveau]
> [   21.004182]  nouveau_channel_prep+0xc0/0x269 [nouveau]
> [   21.004454]  nouveau_channel_new+0x3c/0x5f5 [nouveau]
> [   21.004725]  ? slab_free_freelist_hook+0x3b/0xa7
> [   21.004740]  ? kfree+0x9e/0x11a
> [   21.004749]  ? nvif_object_sclass_put+0xd/0x16 [nouveau]
> [   21.004944]  nouveau_drm_device_init+0x2e2/0x646 [nouveau]
> [   21.005186]  ? pci_enable_device_flags+0x23/0x97
> [   21.005202]  nouveau_drm_probe+0xe5/0x182 [nouveau]
> [   21.005443]  ? nouveau_drm_device_init+0x646/0x646 [nouveau]
> [   21.005683]  pci_device_probe+0x89/0xe9
> [   21.005696]  really_probe+0x127/0x2b9
> [   21.005707]  driver_probe_device+0x62/0x89
> [   21.005715]  device_driver_attach+0x2e/0x41
> [   21.005724]  __driver_attach+0x83/0x8a
> [   21.005732]  bus_for_each_dev+0x4c/0x66
> [   21.005740]  driver_attach+0x14/0x16
> [   21.005747]  ? device_driver_attach+0x41/0x41
> [   21.005756]  bus_add_driver+0xc5/0x16c
> [   21.005764]  driver_register+0x87/0xb9
> [   21.005772]  __pci_register_driver+0x38/0x3b
> [   21.005780]  ? 0xf0be4000
> [   21.005787]  nouveau_drm_init+0x14c/0x1000 [nouveau]
> [   21.005964]  do_one_initcall+0x5a/0x134
> [   21.005975]  ? __vunmap+0x124/0x12d
> [   21.005984]  ? __vunmap+0x124/0x12d
> [   21.005992]  ? kmem_cache_alloc+0xa8/0xb6
> [   21.006001]  ? do_init_module+0x17/0x1cf
> [   21.006012]  do_init_module+0x46/0x1cf
> [   21.006021]  load_module+0x1799/0x1bcb
> [   21.006032]  __ia32_sys_finit_module+0x72/0x7a
> [   21.006044]  do_int80_syscall_32+0x53/0x62
> [   21.006054]  entry_INT80_32+0xf0/0xf0
> [   21.006063] EIP: 0xb7f40092
> [   21.006071] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 00 
> e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80  8d 
> b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00
> [   21.006086] EAX: ffda EBX: 0010 ECX: b7e9bbdd EDX: 
> [   21.006095] ESI: 008f27d0 EDI: 008f9e10 EBP:  ESP: bfa140b8
> [   21.006103] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS: 00200296
> [   21.006114] Modules linked in: nouveau(+) snd_intel8x0 snd_ac97_codec 
> pcmcia wmi hwmon ac97_bus yenta_socket pcmcia_rsrc drm_ttm_helper snd_pcm ttm 
> snd_timer pcmcia_core psmouse 8139cp snd sg soundcore serio_raw parport_pc 
> intel_agp parport
> [   21.006165] CR2: 
> [   21.006201] ---[ end trace 02dc541683feafc6 ]---
> [   21.006211] EIP: nouveau_bo_sync_for_device+0x9e/0xbf [nouveau]
> [   21.006460] Code: 02 89 45 e8 01 d1 8b 19 89 5d ec bb 01 00 00 00 3b 5d e8 
> 74 0d 89 d8 c1 e0 05 03 45 ec 39 04 99 74 1e 8b 46 10 89 d9 c1 e1 0c <8b> 14 
> 10 8b 47 e0 8b 40 08 6a 01 e8 d5 03 55 df 01 5d f0 58 eb ae
> [   21.006476] EAX:  EBX: 0010 ECX: 0001 EDX: 
> [   21.006485] ESI: c3e90280 EDI: c185a494 EBP: c2ed7c10 ESP: c2ed7bf8
> [   21.006494] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00210206
> [   21.006503] CR0: 80050033 CR2:  CR3: 02ecb000 CR4: 0690
>
>
> --
> Ondrej Zary
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau


Re: [PATCH] vgaarb: Call vga_arb_device_init() after PCI enumeration

2021-06-05 Thread Bjorn Helgaas
On Sat, Jun 05, 2021 at 10:02:05AM +0800, Huacai Chen wrote:
> On Sat, Jun 5, 2021 at 3:56 AM Bjorn Helgaas  wrote:
> > On Fri, Jun 04, 2021 at 12:50:03PM +0800, Huacai Chen wrote:
> > > On Thu, Jun 3, 2021 at 2:31 AM Bjorn Helgaas  wrote:

> > > > I think the simplest solution, which I suggested earlier [1],
> > > > would be to explicitly call vga_arbiter_add_pci_device()
> > > > directly from the PCI core when it enumerates a VGA device.
> > > > Then there's no initcall and no need for the
> > > > BUS_NOTIFY_ADD/DEL_DEVICE stuff.  vga_arbiter_add_pci_device()
> > > > could set the default VGA device when it is enumerated, and
> > > > change the default device if we enumerate a "better" one.  And
> > > > hotplug VGA devices would work automatically.
> > >
> > > Emm, It seems that your solution has some difficulties to remove
> > > the whole initcall(vga_arb_device_init): we call
> > > vga_arbiter_add_pci_device() in pci_bus_add_device(), the
> > > list_for_each_entry() loop can be moved to
> > > vga_arbiter_check_bridge_sharing(),
> > > vga_arb_select_default_device() can be renamed to
> > > vga_arb_update_default_device() and be called in
> > > vga_arbiter_add_pci_device(), but how to handle
> > > misc_register(_arb_device)?
> >
> > Might need to keep vga_arb_device_init() as an initcall, but
> > remove everything from it except the misc_register().
>
> OK, let me try. But I think call  vga_arbiter_add_pci_device() in
> pci core is nearly the same as notifier.  Anyway, I will send a new
> patch later.

Notifiers are useful in some situations, for example, if a loadable
module needs to be called when a device is added or removed.

But when possible, I will always choose a direct call instead because
it's much less complicated.  The VGA arbiter cannot be a loadable
module, so I don't think there's any reason to use a notifier in this
case.

Bjorn


[PATCH v4 2/5] drm/i915/gt: Add remaining conversions to GRAPHICS_VER

2021-06-05 Thread Lucas De Marchi
For some reason coccinelle misses a few cases in gt with calls to
INTEL_GEN()/IS_GEN(). Do a manual conversion for those.

Signed-off-by: Lucas De Marchi 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/debugfs_gt_pm.c  | 2 +-
 drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 ++--
 drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c 
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index 0389bceebd06..4270b5a34a83 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -230,7 +230,7 @@ static int drpc_show(struct seq_file *m, void *unused)
with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
err = vlv_drpc(m);
-   else if (INTEL_GEN(i915) >= 6)
+   else if (GRAPHICS_VER(i915) >= 6)
err = gen6_drpc(m);
else
err = ilk_drpc(m);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 9ef349cd5cea..e113f93b3274 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -606,10 +606,10 @@ intel_engine_has_relative_mmio(const struct 
intel_engine_cs * const engine)
 }
 
 #define instdone_has_slice(dev_priv___, sseu___, slice___) \
-   ((IS_GEN(dev_priv___, 7) ? 1 : ((sseu___)->slice_mask)) & BIT(slice___))
+   ((GRAPHICS_VER(dev_priv___) == 7 ? 1 : ((sseu___)->slice_mask)) & 
BIT(slice___))
 
 #define instdone_has_subslice(dev_priv__, sseu__, slice__, subslice__) \
-   (IS_GEN(dev_priv__, 7) ? (1 & BIT(subslice__)) : \
+   (GRAPHICS_VER(dev_priv__) == 7 ? (1 & BIT(subslice__)) : \
 intel_sseu_has_subslice(sseu__, 0, subslice__))
 
 #define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c 
b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
index 51780282d872..714fe8495775 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
@@ -248,7 +248,7 @@ int intel_sseu_status(struct seq_file *m, struct intel_gt 
*gt)
struct sseu_dev_info sseu;
intel_wakeref_t wakeref;
 
-   if (INTEL_GEN(i915) < 8)
+   if (GRAPHICS_VER(i915) < 8)
return -ENODEV;
 
seq_puts(m, "SSEU Device Info\n");
@@ -265,9 +265,9 @@ int intel_sseu_status(struct seq_file *m, struct intel_gt 
*gt)
cherryview_sseu_device_status(gt, );
else if (IS_BROADWELL(i915))
bdw_sseu_device_status(gt, );
-   else if (IS_GEN(i915, 9))
+   else if (GRAPHICS_VER(i915) == 9)
gen9_sseu_device_status(gt, );
-   else if (INTEL_GEN(i915) >= 10)
+   else if (GRAPHICS_VER(i915) >= 10)
gen10_sseu_device_status(gt, );
}
 
-- 
2.31.1



[PATCH v4 0/5] drm/i915: Finish conversion to GRAPHICS_VER

2021-06-05 Thread Lucas De Marchi
v3 is a resend from v2 (https://patchwork.freedesktop.org/series/90693/)
now with dri-devel Cc'ed. Notice that this patch series can be applied
splitting it up through the trees, it's not necessary to apply them
together. The intention is to apply first 3 patches on drm-intel-gt-next
and the remaining on drm-intel-next.  I'm intentionally _not_ removing
the INTEL_GEN/IS_GEN/IS_GEN_RANGE macros now. A few days/weeks after
this is applied and when drm-intel-gt-next and drm-intel-next is back in
sync, we can remove any leftovers that went in and remove the macros via
a topic branch.

Latest version of previous series "drm/i915: Extend GEN renames to the
rest of the driver" (https://patchwork.freedesktop.org/series/88825/)
dropped one patch converting all the instances of IS_GEN() and
INTEL_GEN() to GRAPHICS_VER() due to the patches changing the
meaning of the macros IS_GRAPHICS_VER/GRAPHICS_VER and removal of
IS_GRAPHICS_RANGE().

I couldn't find a way to convince coccinelle to fix all places, so I
just did it manually in separate commits the places that were not
updated.

Finish the conversion splitting the changes so it can go to the
different branches (drm-intel-gt-next and drm-intel-next). I also split
the gvt changes, but I think it would be easier to take this directly on
drm-intel-next.

v2: update commit messages with the proper semantic patch (Matt Roper)
and regenerate the patches to also convert changes that got added in
between.

v3: resend with dri-devel Cc'ed since we are touching gt/gem/core. Also,
let's get an ack on merge strategy

v4: rebase and remove patches already applied

Lucas De Marchi (5):
  drm/i915/gt: replace IS_GEN and friends with GRAPHICS_VER
  drm/i915/gt: Add remaining conversions to GRAPHICS_VER
  drm/i915/gem: replace IS_GEN and friends with GRAPHICS_VER
  drm/i915: replace IS_GEN and friends with GRAPHICS_VER
  drm/i915: Add remaining conversions to GRAPHICS_VER

 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  6 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 +--
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  2 +-
 .../gpu/drm/i915/gem/i915_gem_object_blt.c|  8 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 16 ++--
 drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 12 +--
 .../i915/gem/selftests/i915_gem_client_blt.c  | 10 +--
 .../i915/gem/selftests/i915_gem_coherency.c   |  4 +-
 .../drm/i915/gem/selftests/i915_gem_context.c | 16 ++--
 .../drm/i915/gem/selftests/i915_gem_mman.c| 14 ++--
 .../drm/i915/gem/selftests/igt_gem_utils.c| 10 +--
 drivers/gpu/drm/i915/gt/debugfs_gt_pm.c   | 40 +-
 drivers/gpu/drm/i915/gt/gen2_engine_cs.c  |  2 +-
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  2 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_context_sseu.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 54 ++---
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |  4 +-
 .../drm/i915/gt/intel_execlists_submission.c  | 18 ++---
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 18 ++---
 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c  | 34 
 drivers/gpu/drm/i915/gt/intel_gt.c| 27 ---
 .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 12 +--
 drivers/gpu/drm/i915/gt/intel_gt_irq.c|  6 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 10 +--
 drivers/gpu/drm/i915/gt/intel_gtt.c   | 14 ++--
 drivers/gpu/drm/i915/gt/intel_llc.c   |  6 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 46 +--
 drivers/gpu/drm/i915/gt/intel_mocs.c  |  8 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |  6 +-
 drivers/gpu/drm/i915/gt/intel_rc6.c   | 16 ++--
 drivers/gpu/drm/i915/gt/intel_renderstate.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_reset.c | 14 ++--
 .../gpu/drm/i915/gt/intel_ring_submission.c   | 64 +++
 drivers/gpu/drm/i915/gt/intel_rps.c   | 60 +++---
 drivers/gpu/drm/i915/gt/intel_sseu.c  | 14 ++--
 drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c  |  6 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 66 +++
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c  |  6 +-
 drivers/gpu/drm/i915/gt/selftest_engine_pm.c  |  2 +-
 drivers/gpu/drm/i915/gt/selftest_execlists.c  |  4 +-
 drivers/gpu/drm/i915/gt/selftest_gt_pm.c  |  8 +-
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |  8 +-
 drivers/gpu/drm/i915/gt/selftest_llc.c|  4 +-
 drivers/gpu/drm/i915/gt/selftest_lrc.c|  8 +-
 drivers/gpu/drm/i915/gt/selftest_mocs.c   |  2 +-
 drivers/gpu/drm/i915/gt/selftest_rc6.c|  4 +-
 .../drm/i915/gt/selftest_ring_submission.c|  6 +-
 drivers/gpu/drm/i915/gt/selftest_rps.c| 16 ++--
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  6 +-
 .../gpu/drm/i915/gt/selftest_workarounds.c|  8 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 

[PATCH v4 1/5] drm/i915/gt: replace IS_GEN and friends with GRAPHICS_VER

2021-06-05 Thread Lucas De Marchi
This was done by the following semantic patch:

@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)

@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E

@@ expression dev_priv; expression E; @@
- !IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) != E

@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) == E

@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_VER(dev_priv, from, until)

@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)

@@
identifier def.id;
@@
- id
+ ver

It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".

Signed-off-by: Lucas De Marchi 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/debugfs_gt_pm.c   | 38 +--
 drivers/gpu/drm/i915/gt/gen2_engine_cs.c  |  2 +-
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  2 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_context_sseu.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 54 +++
 .../drm/i915/gt/intel_execlists_submission.c  | 18 ++---
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 18 ++---
 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c  | 34 +-
 drivers/gpu/drm/i915/gt/intel_gt.c| 27 
 .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 12 ++--
 drivers/gpu/drm/i915/gt/intel_gt_irq.c|  6 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 10 +--
 drivers/gpu/drm/i915/gt/intel_gtt.c   | 14 ++--
 drivers/gpu/drm/i915/gt/intel_llc.c   |  6 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 46 ++---
 drivers/gpu/drm/i915/gt/intel_mocs.c  |  8 +--
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |  6 +-
 drivers/gpu/drm/i915/gt/intel_rc6.c   | 16 ++---
 drivers/gpu/drm/i915/gt/intel_renderstate.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_reset.c | 14 ++--
 .../gpu/drm/i915/gt/intel_ring_submission.c   | 64 +-
 drivers/gpu/drm/i915/gt/intel_rps.c   | 60 -
 drivers/gpu/drm/i915/gt/intel_sseu.c  | 14 ++--
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 66 +--
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c  |  6 +-
 drivers/gpu/drm/i915/gt/selftest_engine_pm.c  |  2 +-
 drivers/gpu/drm/i915/gt/selftest_execlists.c  |  4 +-
 drivers/gpu/drm/i915/gt/selftest_gt_pm.c  |  8 +--
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |  8 +--
 drivers/gpu/drm/i915/gt/selftest_llc.c|  4 +-
 drivers/gpu/drm/i915/gt/selftest_lrc.c|  8 +--
 drivers/gpu/drm/i915/gt/selftest_mocs.c   |  2 +-
 drivers/gpu/drm/i915/gt/selftest_rc6.c|  4 +-
 .../drm/i915/gt/selftest_ring_submission.c|  6 +-
 drivers/gpu/drm/i915/gt/selftest_rps.c| 16 ++---
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  6 +-
 .../gpu/drm/i915/gt/selftest_workarounds.c|  8 +--
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c |  2 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  6 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc.c|  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  4 +-
 44 files changed, 321 insertions(+), 320 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c 
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index d4f4452ce5ed..0389bceebd06 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -85,14 +85,14 @@ static int gen6_drpc(struct seq_file *m)
gt_core_status = intel_uncore_read_fw(uncore, GEN6_GT_CORE_STATUS);
 
rcctl1 = intel_uncore_read(uncore, GEN6_RC_CONTROL);
-   if (INTEL_GEN(i915) >= 9) {
+   if (GRAPHICS_VER(i915) >= 9) {
gen9_powergate_enable =
intel_uncore_read(uncore, GEN9_PG_ENABLE);
gen9_powergate_status =
intel_uncore_read(uncore, GEN9_PWRGT_DOMAIN_STATUS);
}
 
-   if (INTEL_GEN(i915) <= 7)
+   if (GRAPHICS_VER(i915) <= 7)
sandybridge_pcode_read(i915, GEN6_PCODE_READ_RC6VIDS,
   , NULL);
 
@@ -100,7 +100,7 @@ static int gen6_drpc(struct seq_file *m)
   yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
seq_printf(m, "RC6 Enabled: %s\n",
   yesno(rcctl1 & GEN6_RC_CTL_RC6_ENABLE));
-   if (INTEL_GEN(i915) >= 9) {
+   if (GRAPHICS_VER(i915) >= 9) {
seq_printf(m, "Render Well Gating Enabled: %s\n",
   

[PATCH v4 5/5] drm/i915: Add remaining conversions to GRAPHICS_VER

2021-06-05 Thread Lucas De Marchi
For some reason coccinelle misses a few cases in header files with calls to
INTEL_GEN()/IS_GEN(). Do a manual conversion for those.

Signed-off-by: Lucas De Marchi 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h | 37 -
 drivers/gpu/drm/i915/i915_reg.h | 26 +++
 2 files changed, 31 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 91fda14f8f6c..38ff2fb89744 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1552,9 +1552,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
(IS_ALDERLAKE_P(__i915) && \
 IS_GT_STEP(__i915, since, until))
 
-#define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp)
-#define IS_GEN9_LP(dev_priv)   (IS_GEN(dev_priv, 9) && IS_LP(dev_priv))
-#define IS_GEN9_BC(dev_priv)   (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv))
+#define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp)
+#define IS_GEN9_LP(dev_priv)   (GRAPHICS_VER(dev_priv) == 9 && IS_LP(dev_priv))
+#define IS_GEN9_BC(dev_priv)   (GRAPHICS_VER(dev_priv) == 9 && 
!IS_LP(dev_priv))
 
 #define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id))
 #define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id)
@@ -1574,12 +1574,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
  * The Gen7 cmdparser copies the scanned buffer to the ggtt for execution
  * All later gens can run the final buffer from the ppgtt
  */
-#define CMDPARSER_USES_GGTT(dev_priv) IS_GEN(dev_priv, 7)
+#define CMDPARSER_USES_GGTT(dev_priv) (GRAPHICS_VER(dev_priv) == 7)
 
 #define HAS_LLC(dev_priv)  (INTEL_INFO(dev_priv)->has_llc)
 #define HAS_SNOOP(dev_priv)(INTEL_INFO(dev_priv)->has_snoop)
 #define HAS_EDRAM(dev_priv)((dev_priv)->edram_size_mb)
-#define HAS_SECURE_BATCHES(dev_priv) (INTEL_GEN(dev_priv) < 6)
+#define HAS_SECURE_BATCHES(dev_priv) (GRAPHICS_VER(dev_priv) < 6)
 #define HAS_WT(dev_priv)   HAS_EDRAM(dev_priv)
 
 #define HWS_NEEDS_PHYSICAL(dev_priv)   
(INTEL_INFO(dev_priv)->hws_needs_physical)
@@ -1612,7 +1612,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_BROKEN_CS_TLB(dev_priv)(IS_I830(dev_priv) || 
IS_I845G(dev_priv))
 
 #define NEEDS_RC6_CTX_CORRUPTION_WA(dev_priv)  \
-   (IS_BROADWELL(dev_priv) || IS_GEN(dev_priv, 9))
+   (IS_BROADWELL(dev_priv) || GRAPHICS_VER(dev_priv) == 9)
 
 /* WaRsDisableCoarsePowerGating:skl,cnl */
 #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv)   \
@@ -1620,23 +1620,22 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 IS_SKL_GT3(dev_priv) ||\
 IS_SKL_GT4(dev_priv))
 
-#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
-#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
+#define HAS_GMBUS_IRQ(dev_priv) (GRAPHICS_VER(dev_priv) >= 4)
+#define HAS_GMBUS_BURST_READ(dev_priv) (GRAPHICS_VER(dev_priv) >= 10 || \
IS_GEMINILAKE(dev_priv) || \
IS_KABYLAKE(dev_priv))
 
 /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
  * rows, which changed the alignment requirements and fence programming.
  */
-#define HAS_128_BYTE_Y_TILING(dev_priv) (!IS_GEN(dev_priv, 2) && \
-!(IS_I915G(dev_priv) || \
-IS_I915GM(dev_priv)))
+#define HAS_128_BYTE_Y_TILING(dev_priv) (GRAPHICS_VER(dev_priv) != 2 && \
+!(IS_I915G(dev_priv) || 
IS_I915GM(dev_priv)))
 #define SUPPORTS_TV(dev_priv)  
(INTEL_INFO(dev_priv)->display.supports_tv)
 #define I915_HAS_HOTPLUG(dev_priv) 
(INTEL_INFO(dev_priv)->display.has_hotplug)
 
-#define HAS_FW_BLC(dev_priv)   (INTEL_GEN(dev_priv) > 2)
+#define HAS_FW_BLC(dev_priv)   (GRAPHICS_VER(dev_priv) > 2)
 #define HAS_FBC(dev_priv)  (INTEL_INFO(dev_priv)->display.has_fbc)
-#define HAS_CUR_FBC(dev_priv)  (!HAS_GMCH(dev_priv) && INTEL_GEN(dev_priv) >= 
7)
+#define HAS_CUR_FBC(dev_priv)  (!HAS_GMCH(dev_priv) && GRAPHICS_VER(dev_priv) 
>= 7)
 
 #define HAS_IPS(dev_priv)  (IS_HSW_ULT(dev_priv) || IS_BROADWELL(dev_priv))
 
@@ -1647,7 +1646,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_PSR(dev_priv)   (INTEL_INFO(dev_priv)->display.has_psr)
 #define HAS_PSR_HW_TRACKING(dev_priv) \
(INTEL_INFO(dev_priv)->display.has_psr_hw_tracking)
-#define HAS_PSR2_SEL_FETCH(dev_priv)(INTEL_GEN(dev_priv) >= 12)
+#define HAS_PSR2_SEL_FETCH(dev_priv)(GRAPHICS_VER(dev_priv) >= 12)
 #define HAS_TRANSCODER(dev_priv, trans) 
((INTEL_INFO(dev_priv)->cpu_transcoder_mask & BIT(trans)) != 0)
 
 #define HAS_RC6(dev_priv)   (INTEL_INFO(dev_priv)->has_rc6)
@@ -1658,7 +1657,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 #define HAS_DMC(dev_priv)  

[PATCH v4 3/5] drm/i915/gem: replace IS_GEN and friends with GRAPHICS_VER

2021-06-05 Thread Lucas De Marchi
This was done by the following semantic patch:

@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)

@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E

@@ expression dev_priv; expression E; @@
- !IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) != E

@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) == E

@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_VER(dev_priv, from, until)

@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)

@@
identifier def.id;
@@
- id
+ ver

It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".

Signed-off-by: Lucas De Marchi 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c  |  6 +++---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c   | 10 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_object_blt.c   |  8 
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c   | 16 
 drivers/gpu/drm/i915/gem/i915_gem_tiling.c   | 12 ++--
 .../drm/i915/gem/selftests/i915_gem_client_blt.c | 10 +-
 .../drm/i915/gem/selftests/i915_gem_coherency.c  |  4 ++--
 .../drm/i915/gem/selftests/i915_gem_context.c| 16 
 .../gpu/drm/i915/gem/selftests/i915_gem_mman.c   | 14 +++---
 .../gpu/drm/i915/gem/selftests/igt_gem_utils.c   | 10 +-
 11 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 188dee13e017..7720b8c22c81 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1190,7 +1190,7 @@ static void set_ppgtt_barrier(void *data)
 {
struct i915_address_space *old = data;
 
-   if (INTEL_GEN(old->i915) < 8)
+   if (GRAPHICS_VER(old->i915) < 8)
gen6_ppgtt_unpin_all(i915_vm_to_ppgtt(old));
 
i915_vm_close(old);
@@ -1436,7 +1436,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
context->max_eus_per_subslice = user->max_eus_per_subslice;
 
/* Part specific restrictions. */
-   if (IS_GEN(i915, 11)) {
+   if (GRAPHICS_VER(i915) == 11) {
unsigned int hw_s = hweight8(device->slice_mask);
unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
unsigned int req_s = hweight8(context->slice_mask);
@@ -1503,7 +1503,7 @@ static int set_sseu(struct i915_gem_context *ctx,
if (args->size < sizeof(user_sseu))
return -EINVAL;
 
-   if (!IS_GEN(i915, 11))
+   if (GRAPHICS_VER(i915) != 11)
return -ENODEV;
 
if (copy_from_user(_sseu, u64_to_user_ptr(args->value),
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 297143511f99..24c0582e46fb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -500,7 +500,7 @@ eb_validate_vma(struct i915_execbuffer *eb,
 * also covers all platforms with local memory.
 */
if (entry->relocation_count &&
-   INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
+   GRAPHICS_VER(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
return -EINVAL;
 
if (unlikely(entry->flags & eb->invalid_flags))
@@ -1439,7 +1439,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
 
 static bool reloc_can_use_engine(const struct intel_engine_cs *engine)
 {
-   return engine->class != VIDEO_DECODE_CLASS || !IS_GEN(engine->i915, 6);
+   return engine->class != VIDEO_DECODE_CLASS || 
GRAPHICS_VER(engine->i915) != 6;
 }
 
 static u32 *reloc_gpu(struct i915_execbuffer *eb,
@@ -1671,7 +1671,7 @@ eb_relocate_entry(struct i915_execbuffer *eb,
 * batchbuffers.
 */
if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
-   IS_GEN(eb->i915, 6)) {
+   GRAPHICS_VER(eb->i915) == 6) {
err = i915_vma_bind(target->vma,
target->vma->obj->cache_level,
PIN_GLOBAL, NULL);
@@ -2332,7 +2332,7 @@ static int i915_reset_gen7_sol_offsets(struct 
i915_request *rq)
u32 *cs;
int i;
 
-   if (!IS_GEN(rq->engine->i915, 7) || rq->engine->id != RCS0) {
+   if (GRAPHICS_VER(rq->engine->i915) != 7 || rq->engine->id != RCS0) {
drm_dbg(>engine->i915->drm, "sol reset is gen7/rcs 

[PATCH v4 4/5] drm/i915: replace IS_GEN and friends with GRAPHICS_VER

2021-06-05 Thread Lucas De Marchi
This was done by the following semantic patch:

@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)

@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E

@@ expression dev_priv; expression E; @@
- !IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) != E

@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) == E

@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_VER(dev_priv, from, until)

@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)

@@
identifier def.id;
@@
- id
+ ver

It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".

Signed-off-by: Lucas De Marchi 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c| 10 +--
 drivers/gpu/drm/i915/i915_debugfs.c   | 32 
 drivers/gpu/drm/i915/i915_drv.c   | 20 ++---
 drivers/gpu/drm/i915/i915_gem.c   |  4 +-
 drivers/gpu/drm/i915/i915_gpu_error.c | 80 +--
 drivers/gpu/drm/i915/i915_irq.c   | 34 
 drivers/gpu/drm/i915/i915_perf.c  | 44 +-
 drivers/gpu/drm/i915/i915_pmu.c   |  8 +-
 drivers/gpu/drm/i915/i915_request.c   |  4 +-
 drivers/gpu/drm/i915/i915_suspend.c   | 16 ++--
 drivers/gpu/drm/i915/i915_sysfs.c |  2 +-
 drivers/gpu/drm/i915/i915_vgpu.c  |  2 +-
 drivers/gpu/drm/i915/intel_device_info.c  | 22 ++---
 drivers/gpu/drm/i915/intel_dram.c | 14 ++--
 drivers/gpu/drm/i915/intel_pch.c  | 10 +--
 drivers/gpu/drm/i915/intel_pm.c   | 14 ++--
 drivers/gpu/drm/i915/intel_sideband.c |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c   | 26 +++---
 drivers/gpu/drm/i915/intel_wopcm.c| 10 +--
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  4 +-
 drivers/gpu/drm/i915/selftests/i915_perf.c|  6 +-
 drivers/gpu/drm/i915/selftests/i915_request.c |  8 +-
 drivers/gpu/drm/i915/selftests/igt_spinner.c  | 12 +--
 drivers/gpu/drm/i915/selftests/intel_uncore.c |  2 +-
 24 files changed, 193 insertions(+), 193 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 5b4b2bd46e7c..3992c25a191d 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -946,8 +946,8 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs 
*engine)
int cmd_table_count;
int ret;
 
-   if (!IS_GEN(engine->i915, 7) && !(IS_GEN(engine->i915, 9) &&
- engine->class == COPY_ENGINE_CLASS))
+   if (GRAPHICS_VER(engine->i915) != 7 && !(GRAPHICS_VER(engine->i915) == 
9 &&
+engine->class == 
COPY_ENGINE_CLASS))
return 0;
 
switch (engine->class) {
@@ -977,7 +977,7 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs 
*engine)
break;
case COPY_ENGINE_CLASS:
engine->get_cmd_length_mask = gen7_blt_get_cmd_length_mask;
-   if (IS_GEN(engine->i915, 9)) {
+   if (GRAPHICS_VER(engine->i915) == 9) {
cmd_tables = gen9_blt_cmd_table;
cmd_table_count = ARRAY_SIZE(gen9_blt_cmd_table);
engine->get_cmd_length_mask =
@@ -993,7 +993,7 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs 
*engine)
cmd_table_count = ARRAY_SIZE(gen7_blt_cmd_table);
}
 
-   if (IS_GEN(engine->i915, 9)) {
+   if (GRAPHICS_VER(engine->i915) == 9) {
engine->reg_tables = gen9_blt_reg_tables;
engine->reg_table_count =
ARRAY_SIZE(gen9_blt_reg_tables);
@@ -1537,7 +1537,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
if (IS_HASWELL(engine->i915))
flags = MI_BATCH_NON_SECURE_HSW;
 
-   GEM_BUG_ON(!IS_GEN_RANGE(engine->i915, 6, 7));
+   GEM_BUG_ON(!IS_GRAPHICS_VER(engine->i915, 6, 
7));
__gen6_emit_bb_start(batch_end,
 batch_addr,
 flags);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a4d8a836bd57..0529576f069c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -361,7 +361,7 @@ 

Re: [PATCH v2] drm/panel: db7430: Add driver for Samsung DB7430

2021-06-05 Thread Dillon Hua
Hi Linus

Linus Walleij  于2021年6月5日周六 上午7:19写道:
>
> On Tue, Jun 1, 2021 at 11:31 PM Doug Anderson  wrote:
>
> > Still hoping that this can work atop DBI so we can avoid the raw SPI
> > writes. You said you're trying for it for v3 so I'm looking forward to
> > checking it out there.
>
> Struggling with this. The DBI bus is only used by tiny DRM
> for the panel drivers that are jitted with that display controller
> ATM. No normal panel driver is using it.

Quite similar to my ili9341 driver submission last year [1].
I guess, if it just simply combines tinyDRM and dpi driver
into one source code like what i was doing. it's might not
easy to get accepted from maintainers.

Anyway, there was a discussion on support dbi & dsi by one
driver [2], hope it'll give some help for you on this work.

[1] 
https://lore.kernel.org/lkml/1590378348-8115-7-git-send-email-dillon.min...@gmail.com/
[2] https://lists.freedesktop.org/archives/dri-devel/2020-May/267031.html

Best Regards.
Dillon

>
> > panel-simple also sets the bpc in the "display_info". Do you need to?
> >
> > I didn't see a reply, so I'm still curious about the answer.
>
> I think it depends on whether the display controller/bridge actually
> make use of this or not. It is implied from the MEDIA_BUS_FMT*
> in practice and this controller (MCDE) only had settings for
> BPP, no fine grained bits to fiddle for BPC.
>
> But I added it for completeness, why not! Who knows who else
> will come along. I think I should patch a few other drivers with
> this as well.
>
> Yours,
> Linus Walleij


[PATCH] drm/msm: remove no need local variable

2021-06-05 Thread Bernard Zhao
Unneeded variable: "ret". Return "0" on line 880

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/msm/dp/dp_panel.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 9cc816663668..8cb3d016101c 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -351,7 +351,6 @@ void dp_panel_dump_regs(struct dp_panel *dp_panel)
 
 int dp_panel_timing_cfg(struct dp_panel *dp_panel)
 {
-   int rc = 0;
u32 data, total_ver, total_hor;
struct dp_catalog *catalog;
struct dp_panel_private *panel;
@@ -404,7 +403,7 @@ int dp_panel_timing_cfg(struct dp_panel *dp_panel)
dp_catalog_panel_timing_cfg(catalog);
panel->panel_on = true;
 
-   return rc;
+   return 0;
 }
 
 int dp_panel_init_panel_info(struct dp_panel *dp_panel)
-- 
2.31.0



[PATCH] drm/amd/display: remove no need variable

2021-06-05 Thread Bernard Zhao
remove no need variable, just return the DC_OK

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
index f962b905e79e..7daadb6a5233 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
@@ -1266,8 +1266,6 @@ static enum dc_status dcn10_validate_global(struct dc 
*dc, struct dc_state *cont
 
 static enum dc_status dcn10_patch_unknown_plane_state(struct dc_plane_state 
*plane_state)
 {
-   enum dc_status result = DC_OK;
-
enum surface_pixel_format surf_pix_format = plane_state->format;
unsigned int bpp = resource_pixel_format_to_bpp(surf_pix_format);
 
@@ -1279,7 +1277,7 @@ static enum dc_status 
dcn10_patch_unknown_plane_state(struct dc_plane_state *pla
swizzle = DC_SW_64KB_S;
 
plane_state->tiling_info.gfx9.swizzle = swizzle;
-   return result;
+   return DC_OK;
 }
 
 struct stream_encoder *dcn10_find_first_free_match_stream_enc_for_link(
-- 
2.31.0



[PATCH] drm/etnaviv: remove no need NULL check

2021-06-05 Thread Bernard Zhao
NULL check before kvfree functions is not needed.

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index d05c35994579..bd0d66ebf314 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -612,14 +612,10 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
 err_submit_cmds:
if (ret && (out_fence_fd >= 0))
put_unused_fd(out_fence_fd);
-   if (stream)
-   kvfree(stream);
-   if (bos)
-   kvfree(bos);
-   if (relocs)
-   kvfree(relocs);
-   if (pmrs)
-   kvfree(pmrs);
+   kvfree(stream);
+   kvfree(bos);
+   kvfree(relocs);
+   kvfree(pmrs);
 
return ret;
 }
-- 
2.31.0



[PATCH] drm/etnaviv: remove NULL check which is not needed

2021-06-05 Thread Bernard Zhao
NULL check before kvfree functions is not needed.

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index b390dd4d60b7..d741b1d735f7 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -80,8 +80,7 @@ static void etnaviv_gem_prime_release(struct 
etnaviv_gem_object *etnaviv_obj)
/* Don't drop the pages for imported dmabuf, as they are not
 * ours, just free the array we allocated:
 */
-   if (etnaviv_obj->pages)
-   kvfree(etnaviv_obj->pages);
+   kvfree(etnaviv_obj->pages);
 
drm_prime_gem_destroy(_obj->base, etnaviv_obj->sgt);
 }
-- 
2.31.0



Re: [PATCH 1/2] dt-bindings: Add SONY Synaptics JDI panel

2021-06-05 Thread Konrad Dybcio


>> +
>> +maintainers:
>> +  - Konrad Dybcio 
>> +
>> +description: |+
> Do you need the formatting? If not, drop '|+'.

I'm not sure whether I do, so I guess dropping it is fine.


>> +  This panel seems to only be found in SONY Xperia
>> +  X, X Performance, X Compact, XZ and XZs
>> +  smartphones and we have no straightforward way of
>> +  actually getting the correct model number,
>> +  as no schematics are released publicly.
> Odd choice of line break length. 80 char please.

Right.


>> +
>> +  preset-gpio:
>> +description: panel reset pin
> What's reset-gpios then?

reset-gpios is an overlook on my side :)


>> +
>> +  pvddio-gpio:
>> +description: panel vddio pin
>> +
>> +  treset-gpio:
>> +description: touch reset pin
> Use '-gpios'
>
> And need to define how many (maxItems: 1).

Right.



>> +#include 
>> +
>> +dsi {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +panel: panel@0 {
>> +reg = <0>;
>> +
>> +pvddio-gpio = < 51 GPIO_ACTIVE_HIGH>;
>> +preset-gpio = < 8 GPIO_ACTIVE_HIGH>;
>> +treset-gpio = < 89 GPIO_ACTIVE_HIGH>;
>> +
>> +vddio-supply = <_s4>;
>> +avdd-supply = <_l2>;
>> +tvdd-supply = <_tvdd>;
>> +
>> +backlight = <_wled>;
>> +
>> +port {
>> +  panel_in: endpoint {
>> +remote-endpoint = <_out>;
>> +  };
> Consistent indentation please. 4 spaces is good.

Another mistake, ack.


I'll send a v2 shortly.


Konrad



Re: [PATCH] dma-buf: fix build due to missing export

2021-06-05 Thread Christian König

That was an already known issue and I've just pushed a patch to fix it.

Christian.

Am 05.06.21 um 02:20 schrieb Lucas De Marchi:

Commit 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit 
v2")
turned dma_resv_reset_shared_max() into a function when
CONFIG_DEBUG_MUTEXES is set, but forgot to export it. That resulted in a
broken build:

ERROR: modpost: "dma_resv_reset_shared_max" 
[drivers/gpu/drm/vgem/vgem.ko] undefined!
ERROR: modpost: "dma_resv_reset_shared_max" 
[drivers/gpu/drm/i915/i915.ko] undefined!
ERROR: modpost: "dma_resv_reset_shared_max" 
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "dma_resv_reset_shared_max" 
[drivers/gpu/drm/ttm/ttm.ko] undefined!
ERROR: modpost: "dma_resv_reset_shared_max" [drivers/gpu/drm/drm.ko] 
undefined!
ERROR: modpost: "dma_resv_reset_shared_max" 
[drivers/gpu/drm/drm_vram_helper.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:150: modules-only.symvers] Error 
1

Fixes: 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit 
v2")
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lucas De Marchi 
---
  drivers/dma-buf/dma-resv.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 3964df438505..6132ba631991 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -226,6 +226,7 @@ void dma_resv_reset_shared_max(struct dma_resv *obj)
fence->shared_max = fence->shared_count;
}
  }
+EXPORT_SYMBOL(dma_resv_reset_shared_max);
  #endif
  
  /**




[PATCH v2 2/2] drm/panel: Add support for SONY JDI Synaptics panel

2021-06-05 Thread Konrad Dybcio
From: AngeloGioacchino Del Regno 

This commit adds support for Synaptics+JDI display panels
used in SONY Xperia X, X Compact, X Performance, XZ and XZs
smartphones.

Due to the nature of phone manufacturing, it is impossible
to retrieve the actual panel names, hence the replacement
ones, detailing the devices they are used on.

Co-developed-by: Konrad Dybcio 
Signed-off-by: AngeloGioacchino Del Regno 

Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/panel/Kconfig |  10 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-sony-synaptics-jdi.c  | 511 ++
 3 files changed, 522 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-sony-synaptics-jdi.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 47a3348acfc6..ac76cca2947e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -514,6 +514,16 @@ config DRM_PANEL_SONY_ACX565AKM
  Say Y here if you want to enable support for the Sony ACX565AKM
  800x600 3.5" panel (found on the Nokia N900).
 
+config DRM_PANEL_SONY_SYNAPTICS_JDI
+   tristate "SONY Synaptics JDI panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Synaptics+JDI hybrid
+ in-cell 720x1280/1080x1920 up-to 120Hz panels found in some SONY
+ Xperia X, X Performance, X Compact, XZ and XZs devices.
+
 config DRM_PANEL_TDO_TL070WSH30
tristate "TDO TL070WSH30 DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 2fca73ba06cb..70ad719ec712 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += 
panel-sitronix-st7703.o
 obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
 obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
 obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_SONY_SYNAPTICS_JDI) += panel-sony-synaptics-jdi.o
 obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o
 obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
 obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
diff --git a/drivers/gpu/drm/panel/panel-sony-synaptics-jdi.c 
b/drivers/gpu/drm/panel/panel-sony-synaptics-jdi.c
new file mode 100644
index ..2b1972dea58a
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sony-synaptics-jdi.c
@@ -0,0 +1,511 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2021 AngeloGioacchino Del Regno 

+ * Copyright (C) 2021 Konrad Dybcio 
+ *
+ * Parameters from dsi-panel-somc-synaptics-jdi-1080p-cmd.dtsi
+ * and dsi-panel-somc-synaptics-jdi-720p-cmd.dtsi from SONY stock kernel.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+enum synaptics_jdi_type {
+   TYPE_FHD60HZ_SONY_KAGURA,
+   TYPE_FHD60HZ_SONY_SUZU,
+   TYPE_HD60HZ_SONY_KUGO,
+};
+
+struct synaptics_jdi_panel_desc {
+   const struct drm_display_mode *mode;
+   enum synaptics_jdi_type type;
+};
+
+struct synaptics_jdi_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   struct backlight_device *backlight;
+
+   struct regulator_bulk_data supplies[5];
+
+   struct gpio_desc *pan_reset_gpio;
+   struct gpio_desc *ts_reset_gpio;
+
+   bool prepared;
+   bool enabled;
+
+   const struct synaptics_jdi_panel_desc *desc;
+};
+
+/* FHD panel initialization sequences */
+static const u8 cmd_on1[2] = {0xB0, 0x00};
+static const u8 cmd_on2[2] = {0xD6, 0x01};
+static const u8 cmd_on3[3] = {0xC4, 0x70, 0x03};
+static const u8 cmd_on4[27] = {
+   0xED, 0x27, 0x31, 0x2F, 0x13, 0x00, 0x6A, 0x99,
+   0x03, 0x17, 0x91, 0xF2, 0x00, 0x00, 0x03, 0x14,
+   0x17, 0x3F, 0x14, 0x12, 0x26, 0x23, 0x00, 0x20,
+   0x00, 0x00, 0x57
+};
+static const u8 cmd_on5[27] = {
+   0xEE, 0x13, 0x61, 0x5F, 0x09, 0x00, 0x6A, 0x99,
+   0x03, 0x00, 0x01, 0xB2, 0x00, 0x00, 0x03, 0x00,
+   0x00, 0x33, 0x14, 0x12, 0x00, 0x21, 0x00, 0x20,
+   0x00, 0x00, 0x57
+};
+static const u8 cmd_on6[27] = {
+   0xEF, 0x27, 0x31, 0x2F, 0x13, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x14,
+   0x17, 0x0F, 0x14, 0x00, 0x00, 0x20, 0x00, 0x00,
+   0x00, 0x00, 0xA6
+};
+static const u8 cmd_on7[27] = {
+   0xF0, 0xE3, 0x07, 0x73, 0xDF, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0xE0, 0xE3, 0x00,
+   0x00, 0x03, 0x14, 0x00, 0x00, 0x20, 0x00, 0x00,
+   0x00, 0x00, 0xA7
+};
+static const u8 cmd_on8[2] = {0x35, 0x00};
+static const u8 cmd_on9[2] = {0x36, 0x00};
+static const u8 cmd_on10[2] = {0x3A, 0x77};
+static const u8 cmd_on11[5] = {0x2A, 0x00, 0x00, 0x04, 0x37};
+static const u8 cmd_on12[5] = {0x2B, 0x00, 0x00, 0x07, 

[PATCH v2 1/2] dt-bindings: Add SONY Synaptics JDI panel

2021-06-05 Thread Konrad Dybcio
Add bindings for the SONY Synaptics JDI panel used in
Xperia X, X Performance, X Compact, XZ and XZs smartphones.

Due to the nature of phone manufacturing and lack of any docs
whatsoever, replacement names have been used to indicate the
devices that this panel is used on.

Signed-off-by: Konrad Dybcio 
---
Changes since v1:
- gpio -> gpios
- description: |+ -> description: |
- remove redundant reset-gpio
- fix up indentation in the example

 .../display/panel/sony,synaptics-jdi.yaml | 100 ++
 1 file changed, 100 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/sony,synaptics-jdi.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/sony,synaptics-jdi.yaml 
b/Documentation/devicetree/bindings/display/panel/sony,synaptics-jdi.yaml
new file mode 100644
index ..81d841c049e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sony,synaptics-jdi.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/sony,synaptics-jdi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SONY Synaptics JDI panel
+
+maintainers:
+  - Konrad Dybcio 
+
+description: |+
+  This panel seems to only be found in SONY Xperia
+  X, X Performance, X Compact, XZ and XZs
+  smartphones and we have no straightforward way of
+  actually getting the correct model number,
+  as no schematics are released publicly.
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+items:
+  - enum:
+  - sony,synaptics-jdi-dora
+  - sony,synaptics-jdi-kagura
+  - sony,synaptics-jdi-keyaki
+  - sony,synaptics-jdi-kugo
+  - sony,synaptics-jdi-suzu
+
+  reg: true
+
+  reset-gpios: true
+
+  avdd-supply:
+description: avdd supply
+
+  vddio-supply:
+description: vddio supply
+
+  vsn-supply:
+description: voltage negative supply
+
+  vsp-supply:
+description: voltage positive supply
+
+  tvdd-supply:
+description: tvdd supply
+
+  preset-gpio:
+description: panel reset pin
+
+  pvddio-gpio:
+description: panel vddio pin
+
+  treset-gpio:
+description: touch reset pin
+
+required:
+  - compatible
+  - reg
+  - preset-gpio
+  - pvddio-gpio
+  - treset-gpio
+  - avdd-supply
+  - vddio-supply
+  - vsn-supply
+  - vsp-supply
+  - tvdd-supply
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel: panel@0 {
+reg = <0>;
+
+pvddio-gpio = < 51 GPIO_ACTIVE_HIGH>;
+preset-gpio = < 8 GPIO_ACTIVE_HIGH>;
+treset-gpio = < 89 GPIO_ACTIVE_HIGH>;
+
+vddio-supply = <_s4>;
+avdd-supply = <_l2>;
+tvdd-supply = <_tvdd>;
+
+backlight = <_wled>;
+
+port {
+  panel_in: endpoint {
+remote-endpoint = <_out>;
+  };
+};
+};
+};
-- 
2.31.1



[PATCH] drm/amdgpu: Fix a a typo in a comment

2021-06-05 Thread Christophe JAILLET
s/than/then/

Signed-off-by: Christophe JAILLET 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 89ebbf363e27..1476236f5c7c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -662,7 +662,7 @@ static int amdgpu_cs_sync_rings(struct amdgpu_cs_parser *p)
  * @error: error number
  * @backoff:   indicator to backoff the reservation
  *
- * If error is set than unvalidate buffer, otherwise just free memory
+ * If error is set then unvalidate buffer, otherwise just free memory
  * used by parsing context.
  **/
 static void amdgpu_cs_parser_fini(struct amdgpu_cs_parser *parser, int error,
-- 
2.30.2



[PATCH] drm/sun4i: de3: Be explicit about supported modifiers

2021-06-05 Thread Jernej Skrabec
From: Piotr Oniszczuk 

Currently only linear formats are supported in sun4i-drm driver, but
SoCs like H6 supports AFBC variant of some of them in multiple cores
(GPU, VPU, DE3). Panfrost already implements AFBC compression and is
sometimes confused what should be default choice (linear, AFBC) if DRM
driver is not explicit about modifier support (MiniMyth2 distro with
MythTV app).

After some discussion with Daniel Stone on #panfrost IRC, it was decided
to make modifiers in sun4i-drm explicit, to avoid any kind of guessing,
not just in panfrost, but everywhere. In fact, long term idea is to make
modifier parameter in drm_universal_plane_init() mandatory (non NULL).

Signed-off-by: Piotr Oniszczuk 
Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 7 ++-
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 8 +++-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c 
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index 0db164a774a1..e779855bcd6e 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -370,6 +370,11 @@ static const u32 sun8i_ui_layer_formats[] = {
DRM_FORMAT_XRGB,
 };
 
+static const uint64_t sun8i_layer_modifiers[] = {
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 struct sun8i_ui_layer *sun8i_ui_layer_init_one(struct drm_device *drm,
   struct sun8i_mixer *mixer,
   int index)
@@ -392,7 +397,7 @@ struct sun8i_ui_layer *sun8i_ui_layer_init_one(struct 
drm_device *drm,
   _ui_layer_funcs,
   sun8i_ui_layer_formats,
   ARRAY_SIZE(sun8i_ui_layer_formats),
-  NULL, type, NULL);
+  sun8i_layer_modifiers, type, NULL);
if (ret) {
dev_err(drm->dev, "Couldn't initialize layer\n");
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c 
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index 46420780db59..1c86c2dd0bbf 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -534,6 +534,11 @@ static const u32 sun8i_vi_layer_de3_formats[] = {
DRM_FORMAT_YVU422,
 };
 
+static const uint64_t sun8i_layer_modifiers[] = {
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct drm_device *drm,
   struct sun8i_mixer *mixer,
   int index)
@@ -560,7 +565,8 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct 
drm_device *drm,
ret = drm_universal_plane_init(drm, >plane, 0,
   _vi_layer_funcs,
   formats, format_count,
-  NULL, DRM_PLANE_TYPE_OVERLAY, NULL);
+  sun8i_layer_modifiers,
+  DRM_PLANE_TYPE_OVERLAY, NULL);
if (ret) {
dev_err(drm->dev, "Couldn't initialize layer\n");
return ERR_PTR(ret);
-- 
2.31.1



Re: [PATCH] dma-buf: fix build due to missing export

2021-06-05 Thread kernel test robot
Hi Lucas,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Lucas-De-Marchi/dma-buf-fix-build-due-to-missing-export/20210605-082109
base:   git://anongit.freedesktop.org/drm/drm-misc for-linux-next
config: arm-allmodconfig (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
# 
https://github.com/0day-ci/linux/commit/c3c64fb8ca0e44b7fee87ed5cc623f2b2a8fa2c6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Lucas-De-Marchi/dma-buf-fix-build-due-to-missing-export/20210605-082109
git checkout c3c64fb8ca0e44b7fee87ed5cc623f2b2a8fa2c6
# 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 >>, old ones prefixed by <<):

>> ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] 
>> undefined!
>> ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] 
>> undefined!

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


Re: [PATCH v3 2/2] radeon: use memcpy_to/fromio for UVD fw upload

2021-06-05 Thread Chen Li
On Fri, 04 Jun 2021 16:08:26 +0800,
Christian König wrote:
> 
> 
> 
> Am 04.06.21 um 09:53 schrieb Chen Li:
> > I met a gpu addr bug recently and the kernel log
> > tells me the pc is memcpy/memset and link register is
> > radeon_uvd_resume.
> > 
> > As we know, in some architectures, optimized memcpy/memset
> > may not work well on device memory. Trival memcpy_toio/memset_io
> > can fix this problem.
> > 
> > BTW, amdgpu has already done it in:
> > commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
> > that's why it has no this issue on the same gpu and platform.
> > 
> > Signed-off-by: Chen Li 
> > ---
> >   drivers/gpu/drm/radeon/radeon_uvd.c | 6 --
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> > b/drivers/gpu/drm/radeon/radeon_uvd.c
> > index 85a1f2c31749..55abf9a9623b 100644
> > --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> > +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> > @@ -288,7 +288,9 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> > if (rdev->uvd.vcpu_bo == NULL)
> > return -EINVAL;
> >   - memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
> > +   memcpy_toio((void __iomem *)rdev->uvd.cpu_addr,
> > +   rdev->uvd_fw->data,
> > +   rdev->uvd_fw->size);
> 
> The coding style still looks wrong here, e.g. it is indented to far to the 
> right
> and data/size can be on one line.

It's really werid that the patch before being replyed has not this coding style 
issue and do always indent the same with previous memcpy(in all of v1, v2 and 
v3),
you can check at 
https://patchwork.kernel.org/project/dri-devel/patch/87im2ufhyz.wl-che...@uniontech.com/
 Cannot figure out what happened, sorry.

I'll take merge them in single line in the next series, thanks.
> 
> Apart from that the patch is Reviewed-by: Christian König
> 
> 
> Regards,
> Christian.
> 
> > size = radeon_bo_size(rdev->uvd.vcpu_bo);
> > size -= rdev->uvd_fw->size;
> > @@ -296,7 +298,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> > ptr = rdev->uvd.cpu_addr;
> > ptr += rdev->uvd_fw->size;
> >   - memset(ptr, 0, size);
> > +   memset_io((void __iomem *)ptr, 0, size);
> > return 0;
> >   }
> 
> 
> 




RE: [bug report] Commit ccf953d8f3d6 ("fb_defio: Remove custom address_space_operations") breaks Hyper-V FB driver

2021-06-05 Thread Dexuan Cui
> From: Dexuan Cui
> Sent: Friday, June 4, 2021 11:17 AM
> > >> ...
> > > I've heard a similar report from Vineeth but we didn't get to the bottom
> > > of this.
> > I have just tried reverting the commit mentioned above and it solves the
> > GUI freeze
> > I was also seeing. Previously, login screen was just freezing, but VM
> > was accessible
> > through ssh. With the above commit reverted, I can login to Gnome.
> >
> > Looks like I am also experiencing the same bug mentioned here.
> >
> > Thanks,
> > Vineeth
> 
> As Matthew mentioned, this is a known issue:
> https://lwn.net/ml/linux-kernel/ylzehv0cpzp8u...@casper.infradead.org/
> 
> Matthew has reverted ccf953d8f3d6:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=
> 0b78f8bcf4951af30b0ae83ea4fad27d641ab617
> so the latest mainline should work now.
> 
> Thanks,
> Dexuan

Hi Matthew,
With today's latest mainline 16f0596fc1d78a1f3ae4628cff962bb297dc908c,
the Xorg works again in Linux VM on Hyper-V, but when I reboot the VM, I
always see a lot of "BUG: Bad page state in process Xorg " warnings (there
are about 60 such warnings) before the VM reboots.

BTW, I happen to have an older Mar-28 mainline kernel (36a14638f7c0654),
which has the same warnings. 

Any idea which change introduced the warnings? 

[   87.446129] BUG: Bad page state in process Xorg  pfn:151807
[   87.448238] page:4f982270 refcount:0 mapcount:0 
mapping:dcf68290 index:0x0 pfn:0x151807
[   87.455506] aops:fb_deferred_io_aops ino:f9 dentry name:"fb0"
[   87.455506] flags: 0x57fffc0(node=1|zone=2|lastcpupid=0x1)
[   87.455506] raw: 057fffc0 dead0100 dead0122 
9fa811c4a280
[   87.455506] raw:    

[   87.455506] page dumped because: non-NULL mapping
[   87.487491] Modules linked in: ...
[   87.491504] CPU: 6 PID: 1388 Comm: Xorg Tainted: GE 
5.13.0-rc4+ #1
[   87.533204] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090008  12/07/2018
[   87.533204] Call Trace:
[   87.533204]  dump_stack+0x64/0x7c
[   87.533204]  bad_page.cold.118+0x63/0x93
[  OK 87.533204]  free_pcppages_bulk+0x1ac/0x770
0m] Stopped Crea[   87.533204]  free_unref_page_list+0x101/0x180
te final runtime[   87.533204]  release_pages+0x186/0x4c0
[   87.533204]  tlb_flush_mmu+0x44/0x120
 dir for shutdow[   87.533204]  tlb_finish_mmu+0x3c/0x70
n pivot root.
[   87.533204]  unmap_region+0xd1/0x110
[   87.533204]  __do_munmap+0x2a2/0x500
[   87.533204]  __vm_munmap+0x7d/0x130
[   87.533204]  __x64_sys_munmap+0x27/0x30
[   87.533204]  do_syscall_64+0x3c/0xb0
[   87.533204]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   87.533204] RIP: 0033:0x7f22b49a7567
[   87.533204] Code: 10 e9 67 ff ff ff 0f 1f 44 00 00 48 8b 15 21 ...
[   87.533204] RSP: 002b:7ffd56c4f2b8 EFLAGS: 0206 ORIG_RAX: 
000b
[   87.533204] RAX: ffda RBX: 557f7299e200 RCX: 7f22b49a7567
[   87.533204] RDX:  RSI: 0040 RDI: 7f22b3652000
[   87.533204] RBP: 557f7299edf0 R08: 557f729abfc0 R09: 0005
[   87.533204] R10: 0034 R11: 0206 R12: 557f7299edf0
[   87.533204] R13:  R14: 557f71cf6968 R15: 557f71cdbe10
[   87.533204] Disabling lock debugging due to kernel taint
[   87.533204] BUG: Bad page state in process Xorg  pfn:151806
[   87.533204] page:cf964098 refcount:0 mapcount:0 
mapping:dcf68290 index:0x0 pfn:0x151806
[   87.533204] aops:fb_deferred_io_aops ino:f9 dentry name:"fb0"
[   87.533204] flags: 0x57fffc0(node=1|zone=2|lastcpupid=0x1)
[   87.533204] raw: 057fffc0 dead0100 dead0122 
9fa811c4a280
[   87.533204] raw:    

[   87.533204] page dumped because: non-NULL mapping
[   87.533204] Modules linked in: ...
[   87.533204] CPU: 6 PID: 1388 Comm: Xorg Tainted: GB   E 
5.13.0-rc4+ #1
[   87.533204] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090008  12/07/2018
[   87.747523] Call Trace:
[   87.747523]  dump_stack+0x64/0x7c
[   87.747523]  bad_page.cold.118+0x63/0x93
[   87.747523]  free_pcppages_bulk+0x1ac/0x770
[   87.747523]  free_unref_page_list+0x101/0x180
[   87.747523]  release_pages+0x186/0x4c0
[   87.747523]  tlb_flush_mmu+0x44/0x120
[   87.747523]  tlb_finish_mmu+0x3c/0x70
[   87.747523]  unmap_region+0xd1/0x110
[   87.747523]  __do_munmap+0x2a2/0x500
[   87.747523]  __vm_munmap+0x7d/0x130
[   87.747523]  __x64_sys_munmap+0x27/0x30
[   87.747523]  do_syscall_64+0x3c/0xb0
[   87.747523]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   87.747523] RIP: 0033:0x7f22b49a7567
[   87.747523] Code: 10 e9 67 ff ff ff 0f 1f 44 00 00 48 8b 15 21 ...
[   87.747523] RSP: 002b:7ffd56c4f2b8 EFLAGS: 0206 ORIG_RAX: 
000b
[   87.747523] RAX: ffda 

[PATCH v4 1/2] radeon: fix coding issues reported from sparse

2021-06-05 Thread Chen Li


Also fix some coding issues reported from sparse.

Signed-off-by: Chen Li 
Acked-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_uvd.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index dfa9fdbe98da..85a1f2c31749 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -152,9 +152,11 @@ int radeon_uvd_init(struct radeon_device *rdev)
 
rdev->uvd.fw_header_present = true;
 
-   family_id = le32_to_cpu(hdr->ucode_version) & 0xff;
-   version_major = (le32_to_cpu(hdr->ucode_version) >> 24) 
& 0xff;
-   version_minor = (le32_to_cpu(hdr->ucode_version) >> 8) 
& 0xff;
+   family_id = (__force u32)(hdr->ucode_version) & 0xff;
+   version_major = (le32_to_cpu((__force 
__le32)(hdr->ucode_version))
+>> 24) & 0xff;
+   version_minor = (le32_to_cpu((__force 
__le32)(hdr->ucode_version))
+>> 8) & 0xff;
DRM_INFO("Found UVD firmware Version: %u.%u Family ID: 
%u\n",
 version_major, version_minor, family_id);
 
@@ -791,17 +793,17 @@ int radeon_uvd_get_create_msg(struct radeon_device *rdev, 
int ring,
return r;
 
/* stitch together an UVD create msg */
-   writel(cpu_to_le32(0x0de4), [0]);
+   writel((__force u32)cpu_to_le32(0x0de4), [0]);
writel(0x0, (void __iomem *)[1]);
-   writel(cpu_to_le32(handle), [2]);
+   writel((__force u32)cpu_to_le32(handle), [2]);
writel(0x0, [3]);
writel(0x0, [4]);
writel(0x0, [5]);
writel(0x0, [6]);
-   writel(cpu_to_le32(0x0780), [7]);
-   writel(cpu_to_le32(0x0440), [8]);
+   writel((__force u32)cpu_to_le32(0x0780), [7]);
+   writel((__force u32)cpu_to_le32(0x0440), [8]);
writel(0x0, [9]);
-   writel(cpu_to_le32(0x01b37000), [10]);
+   writel((__force u32)cpu_to_le32(0x01b37000), [10]);
for (i = 11; i < 1024; ++i)
writel(0x0, [i]);
 
@@ -827,9 +829,9 @@ int radeon_uvd_get_destroy_msg(struct radeon_device *rdev, 
int ring,
return r;
 
/* stitch together an UVD destroy msg */
-   writel(cpu_to_le32(0x0de4), [0]);
-   writel(cpu_to_le32(0x0002), [1]);
-   writel(cpu_to_le32(handle), [2]);
+   writel((__force u32)cpu_to_le32(0x0de4), [0]);
+   writel((__force u32)cpu_to_le32(0x0002), [1]);
+   writel((__force u32)cpu_to_le32(handle), [2]);
writel(0x0, [3]);
for (i = 4; i < 1024; ++i)
writel(0x0, [i]);
-- 
2.31.1







[PATCH v4 0/2] use memcpy_to/fromio for UVD fw upload

2021-06-05 Thread Chen Li


changelog:
v1->v2: split sparse and memcp/memset fix
v2->v3: fix coding issue and misuse of le32_to_cpu
v3->v4: merge memcpy_toio's arguments to one line
Chen Li (2):
  radeon: fix coding issues reported from sparse
  radeon: use memcpy_to/fromio for UVD fw upload

 drivers/gpu/drm/radeon/radeon_uvd.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

-- 
2.31.1





RE: [bug report] Commit ccf953d8f3d6 ("fb_defio: Remove custom address_space_operations") breaks Hyper-V FB driver

2021-06-05 Thread Dexuan Cui
> From: Vineeth Pillai 
> Sent: Friday, June 4, 2021 8:47 AM
> To: Wei Liu ; vkuznets 
> Cc: Matthew Wilcox ; dri-devel@lists.freedesktop.org;
> linux-hyp...@vger.kernel.org; linux-fb...@vger.kernel.org;
> linux-ker...@vger.kernel.org; Michael Kelley ;
> Dexuan Cui 
> Subject: Re: [bug report] Commit ccf953d8f3d6 ("fb_defio: Remove custom
> address_space_operations") breaks Hyper-V FB driver
> 
> 
> On 6/4/2021 9:00 AM, Wei Liu wrote:
> > On Fri, Jun 04, 2021 at 02:25:01PM +0200, Vitaly Kuznetsov wrote:
> >> Hi,
> >>
> >> Commit ccf953d8f3d6 ("fb_defio: Remove custom
> address_space_operations")
> >> seems to be breaking Hyper-V framebuffer
> >> (drivers/video/fbdev/hyperv_fb.c) driver for me: Hyper-V guest boots
> >> well and plymouth even works but when I try starting Gnome, virtual
> >> screen just goes black. Reverting the above mentioned commit on top of
> >> 5.13-rc4 saves the day. The behavior is 100% reproducible. I'm using
> >> Gen2 guest runing on Hyper-V 2019. It was also reported that Gen1 guests
> >> are equally broken.
> >>
> >> Is this something known?
> >>
> > I've heard a similar report from Vineeth but we didn't get to the bottom
> > of this.
> I have just tried reverting the commit mentioned above and it solves the
> GUI freeze
> I was also seeing. Previously, login screen was just freezing, but VM
> was accessible
> through ssh. With the above commit reverted, I can login to Gnome.
> 
> Looks like I am also experiencing the same bug mentioned here.
> 
> Thanks,
> Vineeth

As Matthew mentioned, this is a known issue:
https://lwn.net/ml/linux-kernel/ylzehv0cpzp8u...@casper.infradead.org/

Matthew has reverted ccf953d8f3d6:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b78f8bcf4951af30b0ae83ea4fad27d641ab617
so the latest mainline should work now.

Thanks,
Dexuan



[PATCH v3 2/2] radeon: use memcpy_to/fromio for UVD fw upload

2021-06-05 Thread Chen Li


I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.

As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix this problem.

BTW, amdgpu has already done it in:
commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
that's why it has no this issue on the same gpu and platform.

Signed-off-by: Chen Li 
---
 drivers/gpu/drm/radeon/radeon_uvd.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 85a1f2c31749..55abf9a9623b 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -288,7 +288,9 @@ int radeon_uvd_resume(struct radeon_device *rdev)
if (rdev->uvd.vcpu_bo == NULL)
return -EINVAL;
 
-   memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
+   memcpy_toio((void __iomem *)rdev->uvd.cpu_addr,
+   rdev->uvd_fw->data,
+   rdev->uvd_fw->size);
 
size = radeon_bo_size(rdev->uvd.vcpu_bo);
size -= rdev->uvd_fw->size;
@@ -296,7 +298,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
ptr = rdev->uvd.cpu_addr;
ptr += rdev->uvd_fw->size;
 
-   memset(ptr, 0, size);
+   memset_io((void __iomem *)ptr, 0, size);
 
return 0;
 }
-- 
2.31.1





[PATCH v3 1/2] radeon: fix coding issues reported from sparse

2021-06-05 Thread Chen Li


Also fix some coding issues reported from sparse.

Signed-off-by: Chen Li 
Acked-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_uvd.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index dfa9fdbe98da..85a1f2c31749 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -152,9 +152,11 @@ int radeon_uvd_init(struct radeon_device *rdev)
 
rdev->uvd.fw_header_present = true;
 
-   family_id = le32_to_cpu(hdr->ucode_version) & 0xff;
-   version_major = (le32_to_cpu(hdr->ucode_version) >> 24) 
& 0xff;
-   version_minor = (le32_to_cpu(hdr->ucode_version) >> 8) 
& 0xff;
+   family_id = (__force u32)(hdr->ucode_version) & 0xff;
+   version_major = (le32_to_cpu((__force 
__le32)(hdr->ucode_version))
+>> 24) & 0xff;
+   version_minor = (le32_to_cpu((__force 
__le32)(hdr->ucode_version))
+>> 8) & 0xff;
DRM_INFO("Found UVD firmware Version: %u.%u Family ID: 
%u\n",
 version_major, version_minor, family_id);
 
@@ -791,17 +793,17 @@ int radeon_uvd_get_create_msg(struct radeon_device *rdev, 
int ring,
return r;
 
/* stitch together an UVD create msg */
-   writel(cpu_to_le32(0x0de4), [0]);
+   writel((__force u32)cpu_to_le32(0x0de4), [0]);
writel(0x0, (void __iomem *)[1]);
-   writel(cpu_to_le32(handle), [2]);
+   writel((__force u32)cpu_to_le32(handle), [2]);
writel(0x0, [3]);
writel(0x0, [4]);
writel(0x0, [5]);
writel(0x0, [6]);
-   writel(cpu_to_le32(0x0780), [7]);
-   writel(cpu_to_le32(0x0440), [8]);
+   writel((__force u32)cpu_to_le32(0x0780), [7]);
+   writel((__force u32)cpu_to_le32(0x0440), [8]);
writel(0x0, [9]);
-   writel(cpu_to_le32(0x01b37000), [10]);
+   writel((__force u32)cpu_to_le32(0x01b37000), [10]);
for (i = 11; i < 1024; ++i)
writel(0x0, [i]);
 
@@ -827,9 +829,9 @@ int radeon_uvd_get_destroy_msg(struct radeon_device *rdev, 
int ring,
return r;
 
/* stitch together an UVD destroy msg */
-   writel(cpu_to_le32(0x0de4), [0]);
-   writel(cpu_to_le32(0x0002), [1]);
-   writel(cpu_to_le32(handle), [2]);
+   writel((__force u32)cpu_to_le32(0x0de4), [0]);
+   writel((__force u32)cpu_to_le32(0x0002), [1]);
+   writel((__force u32)cpu_to_le32(handle), [2]);
writel(0x0, [3]);
for (i = 4; i < 1024; ++i)
writel(0x0, [i]);
-- 
2.31.1





[PATCH v4 2/2] radeon: use memcpy_to/fromio for UVD fw upload

2021-06-05 Thread Chen Li


I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.

As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix this problem.

BTW, amdgpu has already done it in:
commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
that's why it has no this issue on the same gpu and platform.

Signed-off-by: Chen Li 
Reviewed-by: Christian König
---
 drivers/gpu/drm/radeon/radeon_uvd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 85a1f2c31749..753da95e6abb 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -288,7 +288,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
if (rdev->uvd.vcpu_bo == NULL)
return -EINVAL;
 
-   memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
+   memcpy_toio((void __iomem *)rdev->uvd.cpu_addr, rdev->uvd_fw->data, 
rdev->uvd_fw->size);
 
size = radeon_bo_size(rdev->uvd.vcpu_bo);
size -= rdev->uvd_fw->size;
@@ -296,7 +296,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
ptr = rdev->uvd.cpu_addr;
ptr += rdev->uvd_fw->size;
 
-   memset(ptr, 0, size);
+   memset_io((void __iomem *)ptr, 0, size);
 
return 0;
 }
-- 
2.31.1






[PATCH v3 0/2] use memcpy_to/fromio for UVD fw upload

2021-06-05 Thread Chen Li



changelog:
v1->v2: split sparse and memcp/memset fix
v2->v3: fix coding issue and misuse of le32_to_cpu

Chen Li (2):
  radeon: fix coding issues reported from sparse
  radeon: use memcpy_to/fromio for UVD fw upload

 drivers/gpu/drm/radeon/radeon_uvd.c | 30 -
 1 file changed, 17 insertions(+), 13 deletions(-)

-- 
2.31.1





Re: [PATCH v3 2/2] radeon: use memcpy_to/fromio for UVD fw upload

2021-06-05 Thread Chen Li
On Fri, 04 Jun 2021 16:31:28 +0800,
Christian König wrote:
> 
> 
> 
> Am 04.06.21 um 10:28 schrieb Chen Li:
> > On Fri, 04 Jun 2021 16:08:26 +0800,
> > Christian König wrote:
> >> 
> >> 
> >> Am 04.06.21 um 09:53 schrieb Chen Li:
> >>> I met a gpu addr bug recently and the kernel log
> >>> tells me the pc is memcpy/memset and link register is
> >>> radeon_uvd_resume.
> >>> 
> >>> As we know, in some architectures, optimized memcpy/memset
> >>> may not work well on device memory. Trival memcpy_toio/memset_io
> >>> can fix this problem.
> >>> 
> >>> BTW, amdgpu has already done it in:
> >>> commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw 
> >>> upload"),
> >>> that's why it has no this issue on the same gpu and platform.
> >>> 
> >>> Signed-off-by: Chen Li 
> >>> ---
> >>>drivers/gpu/drm/radeon/radeon_uvd.c | 6 --
> >>>1 file changed, 4 insertions(+), 2 deletions(-)
> >>> 
> >>> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> >>> b/drivers/gpu/drm/radeon/radeon_uvd.c
> >>> index 85a1f2c31749..55abf9a9623b 100644
> >>> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> >>> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> >>> @@ -288,7 +288,9 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> >>>   if (rdev->uvd.vcpu_bo == NULL)
> >>>   return -EINVAL;
> >>>-  memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, 
> >>> rdev->uvd_fw->size);
> >>> + memcpy_toio((void __iomem *)rdev->uvd.cpu_addr,
> >>> + rdev->uvd_fw->data,
> >>> + rdev->uvd_fw->size);
> >> The coding style still looks wrong here, e.g. it is indented to far to the 
> >> right
> >> and data/size can be on one line.
> > It's really werid that the patch before being replyed has not this coding 
> > style issue and do always indent the same with previous memcpy(in all of 
> > v1, v2 and v3),
> > you can check at 
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Fdri-devel%2Fpatch%2F87im2ufhyz.wl-chenli%40uniontech.com%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7C3faf061c19b54a68e72508d92732cd5e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637583921450406148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=b0726ORwyeLQsKVzqjfZEMaU4Vi543szpFYoHekPMIU%3Dreserved=0
> >  Cannot figure out what happened, sorry.
> > 
> > I'll take merge them in single line in the next series, thanks.
> 
> It's not much of an issue, just make sure that checkpatch.pl doesn't complain.

Yes, have already done checkpatch in all these series.
> 
> Christian.
> 
> >> Apart from that the patch is Reviewed-by: Christian König
> >> 
> >> 
> >> Regards,
> >> Christian.
> >> 
> >>>   size = radeon_bo_size(rdev->uvd.vcpu_bo);
> >>>   size -= rdev->uvd_fw->size;
> >>> @@ -296,7 +298,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> >>>   ptr = rdev->uvd.cpu_addr;
> >>>   ptr += rdev->uvd_fw->size;
> >>>-  memset(ptr, 0, size);
> >>> + memset_io((void __iomem *)ptr, 0, size);
> >>>   return 0;
> >>>}
> >> 
> >> 
> > 
> 
> 
> 




Re: [bug report] Commit ccf953d8f3d6 ("fb_defio: Remove custom address_space_operations") breaks Hyper-V FB driver

2021-06-05 Thread Vineeth Pillai



On 6/4/2021 9:00 AM, Wei Liu wrote:

On Fri, Jun 04, 2021 at 02:25:01PM +0200, Vitaly Kuznetsov wrote:

Hi,

Commit ccf953d8f3d6 ("fb_defio: Remove custom address_space_operations")
seems to be breaking Hyper-V framebuffer
(drivers/video/fbdev/hyperv_fb.c) driver for me: Hyper-V guest boots
well and plymouth even works but when I try starting Gnome, virtual
screen just goes black. Reverting the above mentioned commit on top of
5.13-rc4 saves the day. The behavior is 100% reproducible. I'm using
Gen2 guest runing on Hyper-V 2019. It was also reported that Gen1 guests
are equally broken.

Is this something known?


I've heard a similar report from Vineeth but we didn't get to the bottom
of this.
I have just tried reverting the commit mentioned above and it solves the 
GUI freeze
I was also seeing. Previously, login screen was just freezing, but VM 
was accessible

through ssh. With the above commit reverted, I can login to Gnome.

Looks like I am also experiencing the same bug mentioned here.

Thanks,
Vineeth



[QUESTION] drmModeAtomicCommit returns -EINVAL on return

2021-06-05 Thread Sichem Zhou
Hi,

Sorry to post usage questions here, but I didn't find a better place.

I used libdrm for my wayland based compositor, it generally works but
I've been experiencing hiccups here and there. I have a few questions.
Most of them are generic and one of them is specific.

1. Is there any way to debug when the functions like drmModeSetCrtc,
drmModePageFlip and drmModeAtomicCommit returns non zero, besides
getting the errno?

2. Do I need to attach a 0 fb_id and 0 crtc_id if I intend to
deactivate the connector? It seems I don't need to do it in legacy drm
code, and I am required to do it using atomic functions.

3. I tried what I described above for returning to tty, however I got
-ENIVAL on return(maybe it is because I didn't wait for vblank).

4. Do I need to wait for vblank for modesetting? I know it will be an
error if I tried to do drmModePageFlip before the last one is handled
but what about drmModeSetCrtc? Do I need to wait for a vblank for the
last pageflip?

Is it actually valid to set a 0 crtc_id for connector and 0 fb_id for crtc?

Sorry I didn't place the actual code here, my application is already
rather complex and a lot of abstraction on top of it.

Best regards,
Sichem


[PATCH 3/3] drm/loongson: Add interrupt driver for LS7A

2021-06-05 Thread lichenyang



Add LS7A DC vsync interrupt enable and close function, and
register irq_handler function interface.
Add vbrank event processing flow.

Signed-off-by: lichenyang 
---
 drivers/gpu/drm/loongson/Makefile|   3 +-
 drivers/gpu/drm/loongson/loongson_crtc.c |  43 +-
 drivers/gpu/drm/loongson/loongson_drv.c  |   8 ++
 drivers/gpu/drm/loongson/loongson_drv.h  |  17 +++-
 drivers/gpu/drm/loongson/loongson_irq.c  | 105 +++
 5 files changed, 170 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/loongson/loongson_irq.c

diff --git a/drivers/gpu/drm/loongson/Makefile 
b/drivers/gpu/drm/loongson/Makefile
index 773b806e99a2..cc50b65c7e03 100644
--- a/drivers/gpu/drm/loongson/Makefile
+++ b/drivers/gpu/drm/loongson/Makefile
@@ -11,5 +11,6 @@ loongson-y := loongson_drv.o \
loongson_device.o \
loongson_connector.o \
loongson_encoder.o \
-   loongson_i2c.o
+   loongson_i2c.o \
+   loongson_irq.o
 obj-$(CONFIG_DRM_LOONGSON) += loongson.o
diff --git a/drivers/gpu/drm/loongson/loongson_crtc.c 
b/drivers/gpu/drm/loongson/loongson_crtc.c
index 4cb65fa08778..4c62d5b2bd56 100644
--- a/drivers/gpu/drm/loongson/loongson_crtc.c
+++ b/drivers/gpu/drm/loongson/loongson_crtc.c
@@ -154,19 +154,25 @@ static void loongson_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
 }
 
 static void loongson_crtc_atomic_enable(struct drm_crtc *crtc,
-   struct drm_atomic_state *old_state)
+   struct drm_atomic_state *old_crtc_state)
 {
struct drm_device *dev = crtc->dev;
struct loongson_device *ldev = dev->dev_private;
struct loongson_crtc *lcrtc = to_loongson_crtc(crtc);
u32 reg_offset = lcrtc->reg_offset;
 
+   if (lcrtc->cfg_reg & CFG_ENABLE)
+   goto vblank_on;
+
lcrtc->cfg_reg |= CFG_ENABLE;
ls7a_mm_wreg(ldev, FB_CFG_REG + reg_offset, lcrtc->cfg_reg);
+
+vblank_on:
+   drm_crtc_vblank_on(crtc);
 }
 
 static void loongson_crtc_atomic_disable(struct drm_crtc *crtc,
-struct drm_atomic_state *old_state)
+struct drm_atomic_state 
*old_crtc_state)
 {
struct drm_device *dev = crtc->dev;
struct loongson_device *ldev = dev->dev_private;
@@ -175,10 +181,36 @@ static void loongson_crtc_atomic_disable(struct drm_crtc 
*crtc,
 
lcrtc->cfg_reg &= ~CFG_ENABLE;
ls7a_mm_wreg(ldev, FB_CFG_REG + reg_offset, lcrtc->cfg_reg);
+
+   spin_lock_irq(>dev->event_lock);
+   if (crtc->state->event) {
+   drm_crtc_send_vblank_event(crtc, crtc->state->event);
+   crtc->state->event = NULL;
+   }
+   spin_unlock_irq(>dev->event_lock);
+
+   drm_crtc_vblank_off(crtc);
+}
+
+static void loongson_crtc_atomic_flush(struct drm_crtc *crtc,
+  struct drm_crtc_state *old_crtc_state)
+{
+   struct drm_pending_vblank_event *event = crtc->state->event;
+
+   if (event) {
+   crtc->state->event = NULL;
+
+   spin_lock_irq(>dev->event_lock);
+   if (drm_crtc_vblank_get(crtc) == 0)
+   drm_crtc_arm_vblank_event(crtc, event);
+   else
+   drm_crtc_send_vblank_event(crtc, event);
+   spin_unlock_irq(>dev->event_lock);
+   }
 }
 
 static enum drm_mode_status loongson_mode_valid(struct drm_crtc *crtc,
-   const struct drm_display_mode 
*mode)
+   const struct drm_display_mode *mode)
 {
if (mode->hdisplay > 1920)
return MODE_BAD;
@@ -194,9 +226,10 @@ static enum drm_mode_status loongson_mode_valid(struct 
drm_crtc *crtc,
 
 static const struct drm_crtc_helper_funcs loongson_crtc_helper_funcs = {
.mode_valid = loongson_mode_valid,
+   .mode_set_nofb = loongson_crtc_mode_set_nofb,
+   .atomic_flush = loongson_crtc_atomic_flush,
.atomic_enable = loongson_crtc_atomic_enable,
.atomic_disable = loongson_crtc_atomic_disable,
-   .mode_set_nofb = loongson_crtc_mode_set_nofb,
 };
 
 static const struct drm_crtc_funcs loongson_crtc_funcs = {
@@ -206,6 +239,8 @@ static const struct drm_crtc_funcs loongson_crtc_funcs = {
.destroy = drm_crtc_cleanup,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+   .enable_vblank = loongson_crtc_enable_vblank,
+   .disable_vblank = loongson_crtc_disable_vblank,
 };
 
 int loongson_crtc_init(struct loongson_device *ldev, int index)
diff --git a/drivers/gpu/drm/loongson/loongson_drv.c 
b/drivers/gpu/drm/loongson/loongson_drv.c
index 252be9e25aff..89450c8c9102 100644
--- a/drivers/gpu/drm/loongson/loongson_drv.c
+++ b/drivers/gpu/drm/loongson/loongson_drv.c
@@ -167,6 +167,10 @@ static int loongson_drm_load(struct drm_device *dev, 

[PATCH 2/3] drm/loongson: Add GPIO and I2C driver for loongson drm.

2021-06-05 Thread lichenyang



Implement use GPIO and I2C driver to detect connector
and fetch EDID via DDC.

Signed-off-by: lichenyang 
---
 drivers/gpu/drm/loongson/Makefile |   3 +-
 drivers/gpu/drm/loongson/loongson_connector.c |  70 -
 drivers/gpu/drm/loongson/loongson_drv.c   |  16 +-
 drivers/gpu/drm/loongson/loongson_drv.h   |  10 +
 drivers/gpu/drm/loongson/loongson_i2c.c   | 280 ++
 drivers/gpu/drm/loongson/loongson_i2c.h   |  38 +++
 6 files changed, 410 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/loongson/loongson_i2c.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_i2c.h

diff --git a/drivers/gpu/drm/loongson/Makefile 
b/drivers/gpu/drm/loongson/Makefile
index 22d063953b78..773b806e99a2 100644
--- a/drivers/gpu/drm/loongson/Makefile
+++ b/drivers/gpu/drm/loongson/Makefile
@@ -10,5 +10,6 @@ loongson-y := loongson_drv.o \
loongson_plane.o \
loongson_device.o \
loongson_connector.o \
-   loongson_encoder.o
+   loongson_encoder.o \
+   loongson_i2c.o
 obj-$(CONFIG_DRM_LOONGSON) += loongson.o
diff --git a/drivers/gpu/drm/loongson/loongson_connector.c 
b/drivers/gpu/drm/loongson/loongson_connector.c
index 6b1f0ffa33bd..2096a6ddc366 100644
--- a/drivers/gpu/drm/loongson/loongson_connector.c
+++ b/drivers/gpu/drm/loongson/loongson_connector.c
@@ -4,12 +4,65 @@
 
 static int loongson_get_modes(struct drm_connector *connector)
 {
-   int count;
+   struct loongson_connector *lconnector;
+   struct i2c_adapter *adapter;
+   struct edid *edid = NULL;
+   u32 ret;
+
+   lconnector = to_loongson_connector(connector);
+   adapter = lconnector->i2c->adapter;
 
-   count = drm_add_modes_noedid(connector, 1920, 1080);
-   drm_set_preferred_mode(connector, 1024, 768);
+   if (adapter != NULL)
+   edid = drm_get_edid(connector, adapter);
+   else
+   DRM_DEBUG_KMS("get loongson connector adapter err\n");
 
-   return count;
+   if (edid) {
+   drm_connector_update_edid_property(connector, edid);
+   ret = drm_add_edid_modes(connector, edid);
+   } else {
+   DRM_ERROR("Failed to read EDID\n");
+   ret = drm_add_modes_noedid(connector, 1024, 768);
+   }
+
+   return ret;
+}
+
+static bool is_connected(struct loongson_connector *ls_connector)
+{
+   unsigned char start = 0x0;
+   struct i2c_adapter *adapter;
+   struct i2c_msg msgs = {
+   .addr = DDC_ADDR,
+   .flags = 0,
+   .len = 1,
+   .buf = ,
+   };
+
+   if (!ls_connector->i2c)
+   return false;
+
+   adapter = ls_connector->i2c->adapter;
+   if (i2c_transfer(adapter, , 1) != 1) {
+   DRM_DEBUG_KMS("display-%d not connect\n", ls_connector->id);
+   return false;
+   }
+
+   return true;
+}
+
+static enum drm_connector_status
+loongson_detect(struct drm_connector *connector, bool force)
+{
+   struct loongson_connector *lconnector;
+   enum drm_connector_status ret = connector_status_disconnected;
+
+   lconnector = to_loongson_connector(connector);
+
+   if (is_connected(lconnector))
+   ret = connector_status_connected;
+
+   return ret;
 }
 
 static const struct drm_connector_helper_funcs loongson_connector_helper = {
@@ -17,6 +70,7 @@ static const struct drm_connector_helper_funcs 
loongson_connector_helper = {
 };
 
 static const struct drm_connector_funcs loongson_connector_funcs = {
+   .detect = loongson_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = drm_connector_cleanup,
.reset = drm_atomic_helper_connector_reset,
@@ -37,11 +91,17 @@ int loongson_connector_init(struct loongson_device *ldev, 
int index)
 
lconnector->ldev = ldev;
lconnector->id = index;
+   lconnector->i2c_id = index + DC_I2C_BASE;
+
+   lconnector->i2c = loongson_i2c_bus_match(ldev, lconnector->i2c_id);
+   if (!lconnector->i2c)
+   DRM_INFO("connector-%d match i2c-%d err\n", index,
+lconnector->i2c_id);
 
ldev->mode_info[index].connector = lconnector;
connector = >base;
drm_connector_init(ldev->dev, connector, _connector_funcs,
-  DRM_MODE_CONNECTOR_Unknown);
+   DRM_MODE_CONNECTOR_Unknown);
drm_connector_helper_add(connector, _connector_helper);
 
return 0;
diff --git a/drivers/gpu/drm/loongson/loongson_drv.c 
b/drivers/gpu/drm/loongson/loongson_drv.c
index e405199a3df6..252be9e25aff 100644
--- a/drivers/gpu/drm/loongson/loongson_drv.c
+++ b/drivers/gpu/drm/loongson/loongson_drv.c
@@ -11,9 +11,10 @@
 
 /* Interface history:
  * 0.1 - original.
+ * 0.2 - add i2c and connector detect.
  */
 #define DRIVER_MAJOR 0
-#define DRIVER_MINOR 1
+#define DRIVER_MINOR 2
 
 static const struct drm_mode_config_funcs 

[PATCH 1/3] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip

2021-06-05 Thread lichenyang
From: Chenyang Li 

This patch adds an initial DRM driver for the Loongson LS7A1000
bridge chip(LS7A). The LS7A bridge chip contains two display
controllers, support dual display output. The maximum support for
each channel display is to 1920x1080@60Hz.
At present, DC device detection and DRM driver registration are
completed, the crtc/plane/encoder/connector objects has been
implemented.
On Loongson 3A4000 CPU and 7A1000 system, we have achieved the use
of dual screen, and support dual screen clone mode and expansion
mode.

v8:
- Update the atomic_update function interface.

v7:
- The pixel clock is limited to less than 173000.

v6:
- Remove spin_lock in mmio reg read and write.
- TO_UNCAC is replac with ioremap.
- Fix error arguments in crtc_atomic_enable/disable/mode_valid.

v5:
- Change the name of the chip to LS7A.
- Change magic value in crtc to macros.
- Correct mistakes words.
- Change the register operation function prefix to ls7a.

v4:
- Move the mode_valid function to the crtc.

v3:
- Move the mode_valid function to the connector and optimize it.
- Fix num_crtc calculation method.

v2:
- Complete the case of 32-bit color in CRTC.

Signed-off-by: Chenyang Li 
---
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/loongson/Kconfig  |  14 +
 drivers/gpu/drm/loongson/Makefile |  14 +
 drivers/gpu/drm/loongson/loongson_connector.c |  48 
 drivers/gpu/drm/loongson/loongson_crtc.c  | 243 
 drivers/gpu/drm/loongson/loongson_device.c|  47 +++
 drivers/gpu/drm/loongson/loongson_drv.c   | 270 ++
 drivers/gpu/drm/loongson/loongson_drv.h   | 139 +
 drivers/gpu/drm/loongson/loongson_encoder.c   |  37 +++
 drivers/gpu/drm/loongson/loongson_plane.c | 102 +++
 11 files changed, 917 insertions(+)
 create mode 100644 drivers/gpu/drm/loongson/Kconfig
 create mode 100644 drivers/gpu/drm/loongson/Makefile
 create mode 100644 drivers/gpu/drm/loongson/loongson_connector.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_crtc.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_device.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_drv.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_drv.h
 create mode 100644 drivers/gpu/drm/loongson/loongson_encoder.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_plane.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3c16bd1afd87..c0c281635cee 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -372,6 +372,8 @@ source "drivers/gpu/drm/xen/Kconfig"
 
 source "drivers/gpu/drm/vboxvideo/Kconfig"
 
+source "drivers/gpu/drm/loongson/Kconfig"
+
 source "drivers/gpu/drm/lima/Kconfig"
 
 source "drivers/gpu/drm/panfrost/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 5279db4392df..77975fdb4d51 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -119,6 +119,7 @@ obj-$(CONFIG_DRM_PL111) += pl111/
 obj-$(CONFIG_DRM_TVE200) += tve200/
 obj-$(CONFIG_DRM_XEN) += xen/
 obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/
+obj-$(CONFIG_DRM_LOONGSON) += loongson/
 obj-$(CONFIG_DRM_LIMA)  += lima/
 obj-$(CONFIG_DRM_PANFROST) += panfrost/
 obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
diff --git a/drivers/gpu/drm/loongson/Kconfig b/drivers/gpu/drm/loongson/Kconfig
new file mode 100644
index ..3cf42a4cca08
--- /dev/null
+++ b/drivers/gpu/drm/loongson/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+config DRM_LOONGSON
+   tristate "DRM support for LS7A bridge chipset"
+   depends on DRM && PCI
+   depends on CPU_LOONGSON64
+   select DRM_KMS_HELPER
+   select DRM_VRAM_HELPER
+   select DRM_TTM
+   select DRM_TTM_HELPER
+   default n
+   help
+ Support the display controllers found on the Loongson LS7A
+ bridge.
diff --git a/drivers/gpu/drm/loongson/Makefile 
b/drivers/gpu/drm/loongson/Makefile
new file mode 100644
index ..22d063953b78
--- /dev/null
+++ b/drivers/gpu/drm/loongson/Makefile
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Makefile for loongson drm drivers.
+# This driver provides support for the
+# Direct Rendering Infrastructure (DRI)
+
+ccflags-y := -Iinclude/drm
+loongson-y := loongson_drv.o \
+   loongson_crtc.o \
+   loongson_plane.o \
+   loongson_device.o \
+   loongson_connector.o \
+   loongson_encoder.o
+obj-$(CONFIG_DRM_LOONGSON) += loongson.o
diff --git a/drivers/gpu/drm/loongson/loongson_connector.c 
b/drivers/gpu/drm/loongson/loongson_connector.c
new file mode 100644
index ..6b1f0ffa33bd
--- /dev/null
+++ b/drivers/gpu/drm/loongson/loongson_connector.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include "loongson_drv.h"
+
+static int loongson_get_modes(struct drm_connector *connector)
+{
+   int count;
+
+   count =