date:20210708

Re: [PATCH 1/7] drm/msm/dp: use dp_ctrl_off_link_stream during PHY compliance test run

2021-07-08 Thread Stephen Boyd

Quoting Kuogee Hsieh (2021-07-06 10:20:14)
> DP cable should always connect to DPU during the entire PHY compliance
> testing run. Since DP PHY compliance test is executed at irq_hpd event
> context, dp_ctrl_off_link_stream() should be used instead of dp_ctrl_off().
> dp_ctrl_off() is used for unplug event which is triggered when DP cable is
> dis connected.
>
> Signed-off-by: Kuogee Hsieh 
> ---

Is this

Fixes: f21c8a276c2d ("drm/msm/dp: handle irq_hpd with sink_count = 0 correctly")

or

Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")

? It's not clear how dp_ctrl_off() was working for compliance tests
before commit f21c8a276c2d.

>  drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c 
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index caf71fa..27fb0f0 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1530,7 +1530,7 @@ static int dp_ctrl_process_phy_test_request(struct 
> dp_ctrl_private *ctrl)
>  * running. Add the global reset just before disabling the
>  * link clocks and core clocks.
>  */
> -   ret = dp_ctrl_off(&ctrl->dp_ctrl);
> +   ret = dp_ctrl_off_link_stream(&ctrl->dp_ctrl);
> if (ret) {
> DRM_ERROR("failed to disable DP controller\n");
> return ret;

[PATCH v2 0/2] Add support of HDMI for rk3568

2021-07-08 Thread Benjamin Gaignard

Add a compatible and platform datas to support HDMI for rk3568 SoC.

version 2:
- Add the clocks needed for the phy.
 
Benjamin Gaignard (2):
  dt-bindings: display: rockchip: Add compatible for rk3568 HDMI
  drm/rockchip: dw_hdmi: add rk3568 support

 .../display/rockchip/rockchip,dw-hdmi.yaml|  6 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c   | 68 +++
 2 files changed, 73 insertions(+), 1 deletion(-)

-- 
2.25.1

[PATCH v2 2/2] drm/rockchip: dw_hdmi: add rk3568 support

2021-07-08 Thread Benjamin Gaignard

Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
This version of the HDMI hardware block need two clocks to provide
phy reference clock: hclk_vio and hclk.

Signed-off-by: Benjamin Gaignard 
---
version 2:
- Add the clocks needed for the phy.

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 68 +
 1 file changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 830bdd5e9b7ce..dc0e255e45745 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -50,6 +50,10 @@
 #define RK3399_GRF_SOC_CON20   0x6250
 #define RK3399_HDMI_LCDC_SEL   BIT(6)
 
+#define RK3568_GRF_VO_CON1 0x0364
+#define RK3568_HDMI_SDAIN_MSK  BIT(15)
+#define RK3568_HDMI_SCLIN_MSK  BIT(14)
+
 #define HIWORD_UPDATE(val, mask)   (val | (mask) << 16)
 
 /**
@@ -71,6 +75,8 @@ struct rockchip_hdmi {
const struct rockchip_hdmi_chip_data *chip_data;
struct clk *vpll_clk;
struct clk *grf_clk;
+   struct clk *hclk_vio;
+   struct clk *hclk_vop;
struct dw_hdmi *hdmi;
struct phy *phy;
 };
@@ -216,6 +222,26 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi 
*hdmi)
return PTR_ERR(hdmi->grf_clk);
}
 
+   hdmi->hclk_vio = devm_clk_get(hdmi->dev, "hclk_vio");
+   if (PTR_ERR(hdmi->hclk_vio) == -ENOENT) {
+   hdmi->hclk_vio = NULL;
+   } else if (PTR_ERR(hdmi->hclk_vio) == -EPROBE_DEFER) {
+   return -EPROBE_DEFER;
+   } else if (IS_ERR(hdmi->hclk_vio)) {
+   dev_err(hdmi->dev, "failed to get hclk_vio clock\n");
+   return PTR_ERR(hdmi->hclk_vio);
+   }
+
+   hdmi->hclk_vop = devm_clk_get(hdmi->dev, "hclk");
+   if (PTR_ERR(hdmi->hclk_vop) == -ENOENT) {
+   hdmi->hclk_vop = NULL;
+   } else if (PTR_ERR(hdmi->hclk_vop) == -EPROBE_DEFER) {
+   return -EPROBE_DEFER;
+   } else if (IS_ERR(hdmi->hclk_vop)) {
+   dev_err(hdmi->dev, "failed to get hclk_vop clock\n");
+   return PTR_ERR(hdmi->hclk_vop);
+   }
+
return 0;
 }
 
@@ -467,6 +493,19 @@ static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data 
= {
.use_drm_infoframe = true,
 };
 
+static struct rockchip_hdmi_chip_data rk3568_chip_data = {
+   .lcdsel_grf_reg = -1,
+};
+
+static const struct dw_hdmi_plat_data rk3568_hdmi_drv_data = {
+   .mode_valid = dw_hdmi_rockchip_mode_valid,
+   .mpll_cfg   = rockchip_mpll_cfg,
+   .cur_ctr= rockchip_cur_ctr,
+   .phy_config = rockchip_phy_config,
+   .phy_data = &rk3568_chip_data,
+   .use_drm_infoframe = true,
+};
+
 static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
{ .compatible = "rockchip,rk3228-dw-hdmi",
  .data = &rk3228_hdmi_drv_data
@@ -480,6 +519,9 @@ static const struct of_device_id dw_hdmi_rockchip_dt_ids[] 
= {
{ .compatible = "rockchip,rk3399-dw-hdmi",
  .data = &rk3399_hdmi_drv_data
},
+   { .compatible = "rockchip,rk3568-dw-hdmi",
+ .data = &rk3568_hdmi_drv_data
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, dw_hdmi_rockchip_dt_ids);
@@ -536,6 +578,28 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
return ret;
}
 
+   ret = clk_prepare_enable(hdmi->hclk_vio);
+   if (ret) {
+   dev_err(hdmi->dev, "Failed to enable HDMI hclk_vio: %d\n",
+   ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(hdmi->hclk_vop);
+   if (ret) {
+   dev_err(hdmi->dev, "Failed to enable HDMI hclk_vop: %d\n",
+   ret);
+   return ret;
+   }
+
+   if (hdmi->chip_data == &rk3568_chip_data) {
+   regmap_write(hdmi->regmap, RK3568_GRF_VO_CON1,
+HIWORD_UPDATE(RK3568_HDMI_SDAIN_MSK |
+  RK3568_HDMI_SCLIN_MSK,
+  RK3568_HDMI_SDAIN_MSK |
+  RK3568_HDMI_SCLIN_MSK));
+   }
+
hdmi->phy = devm_phy_optional_get(dev, "hdmi");
if (IS_ERR(hdmi->phy)) {
ret = PTR_ERR(hdmi->phy);
@@ -559,6 +623,8 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
ret = PTR_ERR(hdmi->hdmi);
drm_encoder_cleanup(encoder);
clk_disable_unprepare(hdmi->vpll_clk);
+   clk_disable_unprepare(hdmi->hclk_vio);
+   clk_disable_unprepare(hdmi->hclk_vop);
}
 
return ret;
@@ -571,6 +637,8 @@ static void dw_hdmi_rockchip_unbind(struct device *dev, 
struct device *master,
 
dw_hdmi_unbind(hdmi->hdmi);
clk_disable_unprepare(hdmi->vpll_clk);
+   clk_disable_unprepare(hdmi->hclk_vio);
+

Oops in qxl_bo_move_notify()

2021-07-08 Thread Roberto Sassu

Hi

I'm getting this oops (on commit a180bd1d7e16):

[   17.711520] BUG: kernel NULL pointer dereference, address: 
0010
[   17.739451] RIP: 0010:qxl_bo_move_notify+0x35/0x80 [qxl]
[   17.827345] RSP: 0018:c9457c08 EFLAGS: 00010286
[   17.827350] RAX: 0001 RBX:  RCX: 
dc00
[   17.827353] RDX: 0007 RSI: 0004 RDI: 
85596feb
[   17.827356] RBP: 88800e311c00 R08:  R09: 

[   17.827358] R10: 8697b243 R11: fbfff0d2f648 R12: 

[   17.827361] R13: 88800e311e48 R14: 88800e311e98 R15: 
88800e311e90
[   17.827364] FS:  () GS:88805d80() 
knlGS:
[   17.861699] CS:  0010 DS:  ES:  CR0: 80050033
[   17.861703] CR2: 0010 CR3: 2642c000 CR4: 
00350ee0
[   17.861707] Call Trace:
[   17.861712]  ttm_bo_cleanup_memtype_use+0x4d/0xb0 [ttm]
[   17.861730]  ttm_bo_release+0x42d/0x7c0 [ttm]
[   17.861746]  ? ttm_bo_cleanup_refs+0x127/0x420 [ttm]
[   17.888300]  ttm_bo_delayed_delete+0x289/0x390 [ttm]
[   17.888317]  ? ttm_bo_cleanup_refs+0x420/0x420 [ttm]
[   17.888332]  ? lock_release+0x9c/0x5c0
[   17.901033]  ? rcu_read_lock_held_common+0x1a/0x50
[   17.905183]  ttm_device_delayed_workqueue+0x18/0x50 [ttm]
[   17.909371]  process_one_work+0x537/0x9f0
[   17.913345]  ? pwq_dec_nr_in_flight+0x160/0x160
[   17.917297]  ? lock_acquired+0xa4/0x580
[   17.921168]  ? worker_thread+0x169/0x600
[   17.925034]  worker_thread+0x7a/0x600
[   17.928657]  ? process_one_work+0x9f0/0x9f0
[   17.932360]  kthread+0x200/0x230
[   17.935930]  ? set_kthread_struct+0x80/0x80
[   17.939593]  ret_from_fork+0x22/0x30
[   17.951737] CR2: 0010
[   17.955496] ---[ end trace e30cc21c24e81ee5 ]---

I had a look at the code, and it seems that this is caused by
trying to use bo->resource which is NULL.

bo->resource is freed by ttm_bo_cleanup_refs() ->
ttm_bo_cleanup_memtype_use() -> ttm_resource_free().

And then a notification is issued by ttm_bo_cleanup_refs() ->
ttm_bo_put() -> ttm_bo_release() ->
ttm_bo_cleanup_memtype_use(), this time with bo->release
equal to NULL.

I was thinking a proper way to fix this. Checking that
bo->release is not NULL in qxl_bo_move_notify() would
solve the issue. But maybe there is a better way, like
avoiding that ttm_bo_cleanup_memtype_use() is called
twice. Which way would be preferable?

Thanks

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli

Re: [PATCH v5 0/5] iommu/arm-smmu: adreno-smmu page fault handling

2021-07-08 Thread Rob Clark

On Tue, Jul 6, 2021 at 10:12 PM John Stultz  wrote:
>
> On Sun, Jul 4, 2021 at 11:16 AM Rob Clark  wrote:
> >
> > I suspect you are getting a dpu fault, and need:
> >
> > https://lore.kernel.org/linux-arm-msm/CAF6AEGvTjTUQXqom-xhdh456tdLscbVFPQ+iud1H1gHc8A2=h...@mail.gmail.com/
> >
> > I suppose Bjorn was expecting me to send that patch
>
> If it's helpful, I applied that and it got the db845c booting mainline
> again for me (along with some reverts for a separate ext4 shrinker
> crash).
> Tested-by: John Stultz 
>

Thanks, I'll send a patch shortly

BR,
-R

[PATCH 1/2] drivers/gpu/drm/i915/gt/intel_engine_cs.c: Repair typo in function name

2021-07-08 Thread zhaoxiao

Fixes the following W=1 kernel build warning(s):

drivers/gpu/drm/i915/gt/intel_engine_cs.c:882: warning: expecting prototype for 
intel_engines_init_common(). Prototype was for engine_init_common() instead
drivers/gpu/drm/i915/gt/intel_engine_cs.c:959: warning: expecting prototype for 
intel_engines_cleanup_common(). Prototype was for intel_engine_cleanup_common() 
instead

Signed-off-by: zhaoxiao 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 7f03df236613..01b4dc041a72 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -868,7 +868,7 @@ create_kernel_context(struct intel_engine_cs *engine)
 }
 
 /**
- * intel_engines_init_common - initialize cengine state which might require hw 
access
+ * engine_init_common - initialize cengine state which might require hw access
  * @engine: Engine to initialize.
  *
  * Initializes @engine@ structure members shared between legacy and execlists
@@ -949,7 +949,7 @@ int intel_engines_init(struct intel_gt *gt)
 }
 
 /**
- * intel_engines_cleanup_common - cleans up the engine state created by
+ * intel_engine_cleanup_common - cleans up the engine state created by
  *the common initiailizers.
  * @engine: Engine to cleanup.
  *
-- 
2.20.1

[PATCH 2/2] drivers/gpu/drm/i915/display/intel_display_power.c: Repair typo in function name

2021-07-08 Thread zhaoxiao

Fixes the following W=1 kernel build warning(s):

drivers/gpu/drm/i915/display/intel_display_power.c:2300: warning: expecting 
prototype for intel_display_power_put_async(). Prototype was for 
__intel_display_power_put_async() instead

Signed-off-by: zhaoxiao 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 4298ae684d7d..c37e14f2df90 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -2285,7 +2285,7 @@ intel_display_power_put_async_work(struct work_struct 
*work)
 }
 
 /**
- * intel_display_power_put_async - release a power domain reference 
asynchronously
+ * __intel_display_power_put_async - release a power domain reference 
asynchronously
  * @i915: i915 device instance
  * @domain: power domain to reference
  * @wakeref: wakeref acquired for the reference that is being released
-- 
2.20.1

[PATCH v2 1/2] dt-bindings: display: rockchip: Add compatible for rk3568 HDMI

2021-07-08 Thread Benjamin Gaignard

Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.

Signed-off-by: Benjamin Gaignard 
---
version 2:
- Add the clocks needed for the phy.

 .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index 75cd9c686e985..cb8643b3a8b84 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -23,6 +23,7 @@ properties:
   - rockchip,rk3288-dw-hdmi
   - rockchip,rk3328-dw-hdmi
   - rockchip,rk3399-dw-hdmi
+  - rockchip,rk3568-dw-hdmi
 
   reg-io-width:
 const: 4
@@ -51,8 +52,11 @@ properties:
   - vpll
   - enum:
   - grf
+  - hclk_vio
+  - vpll
+  - enum:
+  - hclk
   - vpll
-  - const: vpll
 
   ddc-i2c-bus:
 $ref: /schemas/types.yaml#/definitions/phandle
-- 
2.25.1

[PATCH] gpu: ttm: fix GPF in ttm_bo_release

2021-07-08 Thread Pavel Skripkin

My local syzbot instance hit GPF in ttm_bo_release().
Unfortunately, syzbot didn't produce a reproducer for this, but I
found out possible scenario:

drm_gem_vram_create()<-- drm_gem_vram_object kzalloced
 (bo embedded in this object)
  ttm_bo_init()
ttm_bo_init_reserved()
  ttm_resource_alloc()
man->func->alloc()   <-- allocation failure
  ttm_bo_put()
ttm_bo_release()
  ttm_mem_io_free()  <-- bo->resource == NULL passed
 as second argument
 *GPF*

So, I've added check in ttm_bo_release() to avoid passing
NULL as second argument to ttm_mem_io_free().

Fail log:

KASAN: null-ptr-deref in range [0x0020-0x0027]
CPU: 1 PID: 10419 Comm: syz-executor.3 Not tainted 5.13.0-rc7-next-20210625 #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
RIP: 0010:ttm_mem_io_free+0x28/0x170 drivers/gpu/drm/ttm/ttm_bo_util.c:66
Code: b1 90 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 e8 cd 19 24 fd 4c 8d 6b 
20 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 2a 01 
00 00 4c 8b 63 20 31 ff 4c 89 e6 e8 00 1f
RSP: 0018:c900141df968 EFLAGS: 00010202
RAX: dc00 RBX:  RCX: c90010da
RDX: 0004 RSI: 84513ea3 RDI: 888041fbc010
RBP: 888041fbc010 R08:  R09: 
R10: 0001 R11:  R12: 
R13: 0020 R14: 88806b258800 R15: 88806b258a38
FS:  7fa6e9845640() GS:88807ec0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fad61265e18 CR3: 5ad79000 CR4: 00350ee0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 ttm_bo_release+0xd94/0x10a0 drivers/gpu/drm/ttm/ttm_bo.c:422
 kref_put include/linux/kref.h:65 [inline]
 ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:470 [inline]
 ttm_bo_init_reserved+0x7cb/0x960 drivers/gpu/drm/ttm/ttm_bo.c:1050
 ttm_bo_init+0x105/0x270 drivers/gpu/drm/ttm/ttm_bo.c:1074
 drm_gem_vram_create+0x332/0x4c0 drivers/gpu/drm/drm_gem_vram_helper.c:228

Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
Signed-off-by: Pavel Skripkin 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1b950b45cf4b..15eb97459eab 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -419,7 +419,8 @@ static void ttm_bo_release(struct kref *kref)
bo->bdev->funcs->release_notify(bo);
 
drm_vma_offset_remove(bdev->vma_manager, &bo->base.vma_node);
-   ttm_mem_io_free(bdev, bo->resource);
+   if (bo->resource)
+   ttm_mem_io_free(bdev, bo->resource);
}
 
if (!dma_resv_test_signaled(bo->base.resv, true) ||
-- 
2.32.0

Re: [PATCH v2 1/2] drm/i915/opregion: add support for mailbox #5 EDID

2021-07-08 Thread Daniel Dadap

On 6/1/21 5:43 PM, Anisse Astier wrote:

Le Tue, Jun 01, 2021 at 06:50:24PM +0300, Ville Syrj?l? a ?crit :

On Mon, May 31, 2021 at 10:46:41PM +0200, Anisse Astier wrote:

The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via by adding
the EDID to the list of available modes on the connector, and use it for
eDP when available.

If a panel's EDID is broken, there may be an override EDID set in the
ACPI OpRegion mailbox #5. Use it if available.

Looks like Windows uses the ACPI _DDC method instead. We should probably
do the same, just in case some crazy machine stores the EDID somewhere
else.

Thanks, I wouldn't have thought of this. It seems Daniel Dadap did a
patch series to do just that, in a generic way:
https://lore.kernel.org/amd-gfx/20200727205357.27839-1-dda...@nvidia.com/

I've tried patch 1 & 2, and after a fix[1] was able to call the _DDC method
on most devices, but without any EDID being returned.

I looked at the disassembled ACPI tables[2], and could not find any
device with the _DDC method. Are you sure it's the only method the
Windows driver uses to get the EDID ?

_DDC only works on devices that actually implement it, and the vast
majority of devices don't, because the display just provides an EDID
normally. AIUI, usually a device will implement _DDC either because an
embedded panel has no ROM of its own to deliver an EDID, or to allow the
EDID to be read by either GPU on a system with a muxed display,
regardless of which GPU happens to have the DDC lines (in TMDS) or DP
AUX routed to it at the moment. (To my knowledge, nobody actually muxes
DP AUX independently from the main link, but there were some older
pre-DP designs where DDC could be muxed independently.)

I'm not sure whether the comment about Windows using _DDC was meant for
this device in particular, or just more generally, since DDC is part of
the ACPI spec and some Windows GPU drivers *do* use it, where available.
If it was meant for a particular device, then it's possible that the
ACPI tables advertise different methods depending on e.g. _OSI. If you
haven't already tried doing so, it might be worth overriding _OSI to
spoof Windows, to see if _DDC gets advertised.

I'm not sure how you were able to call _DDC without an EDID being
returned as described above, if there was no _DDC method in the ACPI
tables; I would expect that attempting to call _DDC would fail to locate
a suitable method and do_acpi_ddc would return NULL.

Regards,

Anisse

[1] _DOD ids should only use 16 lower bits, see table here:
https://uefi.org/specs/ACPI/6.4/Apx_B_Video_Extensions/display-specific-methods.html#dod-enumerate-all-devices-attached-to-the-display-adapter

1 2 >

1 - 100 of 166 matches

Mail list logo