Re: [PATCH] drm/virtio: fix vblank handling

[Thomas Zimmermann]

Hi

Am 05.02.20 um 07:53 schrieb Gerd Hoffmann:
> virtio has its own commit fail function.  Add the
> drm_atomic_helper_fake_vblank() call there.
> 
> Fixes: 2a735ad3d211 ("drm/virtio: Remove sending of vblank event")

Thanks for fixing the fallout.

> Signed-off-by: Gerd Hoffmann 

Acked-by: Thomas Zimmermann 

> ---
>  drivers/gpu/drm/virtio/virtgpu_display.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index ecf4ba7cc32b..7b0f0643bb2d 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -324,6 +324,7 @@ static void vgdev_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   drm_atomic_helper_commit_modeset_enables(dev, state);
>   drm_atomic_helper_commit_planes(dev, state, 0);
>  
> + drm_atomic_helper_fake_vblank(state);
>   drm_atomic_helper_commit_hw_done(state);
>  
>   drm_atomic_helper_wait_for_vblanks(dev, state);
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



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

[PATCH v4 3/3] arm64: dts: qcom: sc7180: Add A618 gpu dt blob

[Sharat Masetty]

This patch adds the required dt nodes and properties
to enabled A618 GPU.

Signed-off-by: Sharat Masetty 
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 102 +++
 1 file changed, 102 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index f3fcc5c..63fff15 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1043,6 +1043,108 @@
};
};
 
+   gpu: gpu@500 {
+   compatible = "qcom,adreno-618.0", "qcom,adreno";
+   #stream-id-cells = <16>;
+   reg = <0 0x0500 0 0x4>, <0 0x0509e000 0 0x1000>,
+   <0 0x05061000 0 0x800>;
+   reg-names = "kgsl_3d0_reg_memory", "cx_mem", "cx_dbgc";
+   interrupts = ;
+   iommus = <_smmu 0>;
+   operating-points-v2 = <_opp_table>;
+   qcom,gmu = <>;
+
+   gpu_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-8 {
+   opp-hz = /bits/ 64 <8>;
+   opp-level = 
;
+   };
+
+   opp-65000 {
+   opp-hz = /bits/ 64 <65000>;
+   opp-level = 
;
+   };
+
+   opp-56500 {
+   opp-hz = /bits/ 64 <56500>;
+   opp-level = ;
+   };
+
+   opp-43000 {
+   opp-hz = /bits/ 64 <43000>;
+   opp-level = 
;
+   };
+
+   opp-35500 {
+   opp-hz = /bits/ 64 <35500>;
+   opp-level = ;
+   };
+
+   opp-26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-level = 
;
+   };
+
+   opp-18000 {
+   opp-hz = /bits/ 64 <18000>;
+   opp-level = 
;
+   };
+   };
+   };
+
+   adreno_smmu: iommu@504 {
+   compatible = "qcom,sc7180-smmu-v2", "qcom,smmu-v2";
+   reg = <0 0x0504 0 0x1>;
+   #iommu-cells = <1>;
+   #global-interrupts = <2>;
+   interrupts = ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   clocks = < GCC_GPU_MEMNOC_GFX_CLK>,
+   < GCC_GPU_CFG_AHB_CLK>,
+   < GCC_DDRSS_GPU_AXI_CLK>;
+
+   clock-names = "bus", "iface", "mem_iface_clk";
+   power-domains = < CX_GDSC>;
+   };
+
+   gmu: gmu@506a000 {
+   compatible="qcom,adreno-gmu-618.0", "qcom,adreno-gmu";
+   reg = <0 0x0506a000 0 0x31000>, <0 0x0b29 0 
0x1>,
+   <0 0x0b49 0 0x1>;
+   reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+   interrupts = ,
+  ;
+   interrupt-names = "hfi", "gmu";
+   clocks = < GPU_CC_CX_GMU_CLK>,
+  < GPU_CC_CXO_CLK>,
+  < GCC_DDRSS_GPU_AXI_CLK>,
+  < GCC_GPU_MEMNOC_GFX_CLK>;
+   clock-names = "gmu", "cxo", "axi", "memnoc";
+   power-domains = < CX_GDSC>, < GX_GDSC>;
+   power-domain-names = "cx", "gx";
+   iommus = <_smmu 5>;
+   operating-points-v2 = <_opp_table>;
+
+   gmu_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-level = 
;
+   

[PATCH v4 1/3] dt-bindings: clk: qcom: Add support for GPU GX GDSCR

[Sharat Masetty]

From: Taniya Das 

In the cases where the GPU SW requires to use the GX GDSCR add
support for the same.

Signed-off-by: Taniya Das 
---
 include/dt-bindings/clock/qcom,gpucc-sc7180.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/dt-bindings/clock/qcom,gpucc-sc7180.h 
b/include/dt-bindings/clock/qcom,gpucc-sc7180.h
index 0e4643b..65e706d 100644
--- a/include/dt-bindings/clock/qcom,gpucc-sc7180.h
+++ b/include/dt-bindings/clock/qcom,gpucc-sc7180.h
@@ -15,7 +15,8 @@
 #define GPU_CC_CXO_CLK 6
 #define GPU_CC_GMU_CLK_SRC 7
 
-/* CAM_CC GDSCRs */
+/* GPU_CC GDSCRs */
 #define CX_GDSC0
+#define GX_GDSC1
 
 #endif
-- 
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 0/3] sc7180: Add A618 GPU bindings

[Sharat Masetty]

I used this branch qcom/arm64-for-5.6-to-be-rebased as suggested by Matthias.
This patch needs the clock patches and the clock patches have not yet landed, so

please apply the following series and patches in order
a) All patches from 
https://patchwork.kernel.org/project/linux-clk/list/?series=203517=%2a=both
b) Patches 1 and 2 from 
https://patchwork.kernel.org/project/linux-clk/list/?series=203527=both=%2a
c) All patches from 
https://patchwork.kernel.org/project/linux-clk/list/?series=221739=both=%2a
d) 
https://lore.kernel.org/linux-arm-msm/20200124144154.v2.10.I1a4b93fb005791e29a9dcf288fc8bd459a555a59%40changeid/raw
e) This patch "arm64: dts: qcom: sc7180: Add A618 gpu dt blob"

v3: Addressed review comments from previous submits. Also removed the
interconnect bindings from this patch and I will submit as a new patch with its
dependencies listed. Also I will be sending a new patch for updating the
bindings documentation.

v4: Add GX_GDSC power domain binding for GMU

Sharat Masetty (1):
  arm64: dts: qcom: sc7180: Add A618 gpu dt blob

Taniya Das (2):
  dt-bindings: clk: qcom: Add support for GPU GX GDSCR
  clk: qcom: gpucc: Add support for GX GDSC for SC7180

 arch/arm64/boot/dts/qcom/sc7180.dtsi  | 102 ++
 drivers/clk/qcom/gpucc-sc7180.c   |  37 ++
 include/dt-bindings/clock/qcom,gpucc-sc7180.h |   3 +-
 3 files changed, 141 insertions(+), 1 deletion(-)

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

[PATCH v4 2/3] clk: qcom: gpucc: Add support for GX GDSC for SC7180

[Sharat Masetty]

From: Taniya Das 

 Most of the time the CPU should not be touching the GX domain on the
 GPU
 except for a very special use case when the CPU needs to force the GX
 headswitch off. Add a dummy enable function for the GX gdsc to simulate
 success so that the pm_runtime reference counting is correct.

Signed-off-by: Taniya Das 
---
 drivers/clk/qcom/gpucc-sc7180.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/clk/qcom/gpucc-sc7180.c b/drivers/clk/qcom/gpucc-sc7180.c
index ec61194..3b29f19 100644
--- a/drivers/clk/qcom/gpucc-sc7180.c
+++ b/drivers/clk/qcom/gpucc-sc7180.c
@@ -172,8 +172,45 @@ enum {
.flags = VOTABLE,
 };
 
+/*
+ * On SC7180 the GPU GX domain is *almost* entirely controlled by the GMU
+ * running in the CX domain so the CPU doesn't need to know anything about the
+ * GX domain EXCEPT
+ *
+ * Hardware constraints dictate that the GX be powered down before the CX. If
+ * the GMU crashes it could leave the GX on. In order to successfully bring 
back
+ * the device the CPU needs to disable the GX headswitch. There being no sane
+ * way to reach in and touch that register from deep inside the GPU driver we
+ * need to set up the infrastructure to be able to ensure that the GPU can
+ * ensure that the GX is off during this super special case. We do this by
+ * defining a GX gdsc with a dummy enable function and a "default" disable
+ * function.
+ *
+ * This allows us to attach with genpd_dev_pm_attach_by_name() in the GPU
+ * driver. During power up, nothing will happen from the CPU (and the GMU will
+ * power up normally but during power down this will ensure that the GX domain
+ * is *really* off - this gives us a semi standard way of doing what we need.
+ */
+static int gx_gdsc_enable(struct generic_pm_domain *domain)
+{
+   /* Do nothing but give genpd the impression that we were successful */
+   return 0;
+}
+
+static struct gdsc gx_gdsc = {
+   .gdscr = 0x100c,
+   .clamp_io_ctrl = 0x1508,
+   .pd = {
+   .name = "gpu_gx_gdsc",
+   .power_on = gx_gdsc_enable,
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+   .flags = CLAMP_IO,
+};
+
 static struct gdsc *gpu_cc_sc7180_gdscs[] = {
[CX_GDSC] = _gdsc,
+   [GX_GDSC] = _gdsc,
 };
 
 static struct clk_regmap *gpu_cc_sc7180_clocks[] = {
-- 
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/virtio: fix vblank handling

[Gerd Hoffmann]

virtio has its own commit fail function.  Add the
drm_atomic_helper_fake_vblank() call there.

Fixes: 2a735ad3d211 ("drm/virtio: Remove sending of vblank event")
Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index ecf4ba7cc32b..7b0f0643bb2d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -324,6 +324,7 @@ static void vgdev_atomic_commit_tail(struct 
drm_atomic_state *state)
drm_atomic_helper_commit_modeset_enables(dev, state);
drm_atomic_helper_commit_planes(dev, state, 0);
 
+   drm_atomic_helper_fake_vblank(state);
drm_atomic_helper_commit_hw_done(state);
 
drm_atomic_helper_wait_for_vblanks(dev, state);
-- 
2.18.1

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

Re: [PATCH v3] arm64: dts: qcom: sc7180: Add A618 gpu dt blob

[smasetty]

On 2020-02-01 03:13, Doug Anderson wrote:

Hi,

On Fri, Jan 31, 2020 at 4:04 AM Sharat Masetty 
 wrote:


+   adreno_smmu: iommu@504 {
+   compatible = "qcom,sc7180-smmu-v2", 
"qcom,smmu-v2";

+   reg = <0 0x0504 0 0x1>;
+   #iommu-cells = <1>;
+   #global-interrupts = <2>;
+   interrupts = IRQ_TYPE_LEVEL_HIGH>,
+   IRQ_TYPE_LEVEL_HIGH>,
+   IRQ_TYPE_EDGE_RISING>,
+   IRQ_TYPE_EDGE_RISING>,
+   IRQ_TYPE_EDGE_RISING>,
+   IRQ_TYPE_EDGE_RISING>,
+   IRQ_TYPE_EDGE_RISING>,
+   IRQ_TYPE_EDGE_RISING>,
+   IRQ_TYPE_EDGE_RISING>,
+   IRQ_TYPE_EDGE_RISING>;

+   clocks = < GCC_GPU_MEMNOC_GFX_CLK>,
+   < GCC_GPU_CFG_AHB_CLK>,
+   < GCC_DDRSS_GPU_AXI_CLK>;
+
+   clock-names = "bus", "iface", "mem_iface_clk";


Repeated comment from v2 feedback:

Please send a patch to:

Documentation/devicetree/bindings/iommu/arm,smmu.yaml

...adding 'qcom,sc7180-smmu-v2'.  If you do this it will point out
that you've added a new clock: "mem_iface_clk".  Is this truly a new
clock in sc7180 compared to previous IOMMUs?  ...or is it not really
needed?
I can confirm that this clock is needed for SC7180. I will send out a 
new patch

to update the documentation this week.




+   gmu: gmu@506a000 {
+   compatible="qcom,adreno-gmu-618.0", 
"qcom,adreno-gmu";
+   reg = <0 0x0506a000 0 0x31000>, <0 0x0b29 
0 0x1>,

+   <0 0x0b49 0 0x1>;
+   reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+   interrupts = IRQ_TYPE_LEVEL_HIGH>,

+  ;
+   interrupt-names = "hfi", "gmu";
+   clocks = < GPU_CC_CX_GMU_CLK>,
+  < GPU_CC_CXO_CLK>,
+  < GCC_DDRSS_GPU_AXI_CLK>,
+  < GCC_GPU_MEMNOC_GFX_CLK>;
+   clock-names = "gmu", "cxo", "axi", "memnoc";
+   power-domains = < CX_GDSC>;
+   power-domain-names = "cx";


As per continued comments on v2, please see if this works for you:

  power-domains = < CX_GDSC>, <0>;
  power-domain-names = "cx", "gx";

...and work to get something more real for "gx" ASAP.  It did seem to
boot for me and (unless someone disagrees) it seems better than
totally leaving it out / violating the bindings?


-Doug

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

[Bug 203905] amdgpu:actual_brightness has unreal/wrong value

[bugzilla-daemon]

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

--- Comment #5 from Sandor Ecker (esa...@freemail.hu) ---
Would it be possible to set max_brightness to 2^16-1 ?

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

[Bug 203905] amdgpu:actual_brightness has unreal/wrong value

[bugzilla-daemon]

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

Sandor Ecker (esa...@freemail.hu) changed:

   What|Removed |Added

 CC||esa...@freemail.hu

--- Comment #4 from Sandor Ecker (esa...@freemail.hu) ---
Hi,

I have the same Issue.

I have written a bug report to this:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1861925

Maybe that is not the correct place...

Is any news regarding the problem?

Thx,
Regards,
Sandor

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

[PATCH 09/14] drm/amdgpu: don't call drm_connector_register for non-MST ports

[Alex Deucher]

The core does this for us now.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c| 1 -
 drivers/gpu/drm/amd/amdgpu/dce_virtual.c  | 1 -
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index a62cbc8199de..ec1501e3a63a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1931,7 +1931,6 @@ amdgpu_connector_add(struct amdgpu_device *adev,
connector->polled = DRM_CONNECTOR_POLL_HPD;
 
connector->display_info.subpixel_order = subpixel_order;
-   drm_connector_register(connector);
 
if (has_aux)
amdgpu_atombios_dp_aux_init(amdgpu_connector);
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c 
b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
index e4f94863332c..3c9f2d2490a5 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
@@ -609,7 +609,6 @@ static int dce_virtual_connector_encoder_init(struct 
amdgpu_device *adev,
connector->display_info.subpixel_order = SubPixelHorizontalRGB;
connector->interlace_allowed = false;
connector->doublescan_allowed = false;
-   drm_connector_register(connector);
 
/* link them */
drm_connector_attach_encoder(connector, encoder);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index d0ddbc9df264..7c094bfe07e2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5839,7 +5839,6 @@ static int amdgpu_dm_connector_init(struct 
amdgpu_display_manager *dm,
drm_connector_attach_encoder(
>base, >base);
 
-   drm_connector_register(>base);
 #if defined(CONFIG_DEBUG_FS)
connector_debugfs_init(aconnector);
aconnector->debugfs_dpcd_address = 0;
-- 
2.24.1

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

[PATCH 11/14] drm/amd/display: move dpcd debugfs members setup

[Alex Deucher]

Into the function that creates the debugfs files rather
than setting them explicitly in the callers.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c   | 2 --
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c   | 3 +++
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 --
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index efe74a8a8ace..5b9154ecc690 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5836,8 +5836,6 @@ static int amdgpu_dm_connector_init(struct 
amdgpu_display_manager *dm,
 
 #if defined(CONFIG_DEBUG_FS)
connector_debugfs_init(aconnector);
-   aconnector->debugfs_dpcd_address = 0;
-   aconnector->debugfs_dpcd_size = 0;
 #endif
 
if (connector_type == DRM_MODE_CONNECTOR_DisplayPort
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index f81d3439ee8c..3cafbba37aef 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1008,6 +1008,9 @@ void connector_debugfs_init(struct amdgpu_dm_connector 
*connector)
debugfs_create_file_unsafe("force_yuv420_output", 0644, dir, connector,
   _yuv420_output_fops);
 
+   connector->debugfs_dpcd_address = 0;
+   connector->debugfs_dpcd_size = 0;
+
 }
 
 /*
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 5672f7765919..3959c942c88b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -158,8 +158,6 @@ amdgpu_dm_mst_connector_late_register(struct drm_connector 
*connector)
 
 #if defined(CONFIG_DEBUG_FS)
connector_debugfs_init(amdgpu_dm_connector);
-   amdgpu_dm_connector->debugfs_dpcd_address = 0;
-   amdgpu_dm_connector->debugfs_dpcd_size = 0;
 #endif
 
return drm_dp_mst_connector_late_register(connector, port);
-- 
2.24.1

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

[PATCH 14/14] drm/amdgpu: drop legacy drm load and unload callbacks

[Alex Deucher]

We've moved the debugfs handling into a centralized place
so we can remove the legacy load an unload callbacks.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 13 +++--
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 4dc7145368fc..12aab522f459 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3091,10 +3091,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
} else
adev->ucode_sysfs_en = true;
 
-   r = amdgpu_debugfs_init(adev);
-   if (r)
-   DRM_ERROR("Creating debugfs files failed (%d).\n", r);
-
if ((amdgpu_testing & 1)) {
if (adev->accel_working)
amdgpu_test_moves(adev);
@@ -3216,7 +3212,6 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
amdgpu_ucode_sysfs_fini(adev);
if (IS_ENABLED(CONFIG_PERF_EVENTS))
amdgpu_pmu_fini(adev);
-   amdgpu_debugfs_fini(adev);
if (amdgpu_discovery && adev->asic_type >= CHIP_NAVI10)
amdgpu_discovery_fini(adev);
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index f26532998781..9753c55b317d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1031,6 +1031,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
 {
struct drm_device *dev;
+   struct amdgpu_device *adev;
unsigned long flags = ent->driver_data;
int ret, retry = 0;
bool supports_atomic = false;
@@ -1100,6 +1101,8 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
 
pci_set_drvdata(pdev, dev);
 
+   amdgpu_driver_load_kms(dev, ent->driver_data);
+
 retry_init:
ret = drm_dev_register(dev, ent->driver_data);
if (ret == -EAGAIN && ++retry <= 3) {
@@ -1110,6 +1113,11 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
} else if (ret)
goto err_pci;
 
+   adev = dev->dev_private;
+   ret = amdgpu_debugfs_init(adev);
+   if (ret)
+   DRM_ERROR("Creating debugfs files failed (%d).\n", ret);
+
return 0;
 
 err_pci:
@@ -1123,6 +1131,7 @@ static void
 amdgpu_pci_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
+   struct amdgpu_device *adev = dev->dev_private;
 
 #ifdef MODULE
if (THIS_MODULE->state != MODULE_STATE_GOING)
@@ -1130,6 +1139,8 @@ amdgpu_pci_remove(struct pci_dev *pdev)
DRM_ERROR("Hotplug removal is not supported\n");
drm_dev_unplug(dev);
drm_dev_put(dev);
+   amdgpu_debugfs_fini(adev);
+   amdgpu_driver_unload_kms(dev);
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
 }
@@ -1434,11 +1445,9 @@ static struct drm_driver kms_driver = {
DRIVER_GEM |
DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ |
DRIVER_SYNCOBJ_TIMELINE,
-   .load = amdgpu_driver_load_kms,
.open = amdgpu_driver_open_kms,
.postclose = amdgpu_driver_postclose_kms,
.lastclose = amdgpu_driver_lastclose_kms,
-   .unload = amdgpu_driver_unload_kms,
.get_vblank_counter = amdgpu_get_vblank_counter_kms,
.enable_vblank = amdgpu_enable_vblank_kms,
.disable_vblank = amdgpu_disable_vblank_kms,
-- 
2.24.1

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

[PATCH 12/14] drm/amdgpu/display: add a late register connector callback

[Alex Deucher]

To handle debugfs setup on non DP MST connectors.

Signed-off-by: Alex Deucher 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 5b9154ecc690..1d86b9d53a61 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4486,6 +4486,19 @@ amdgpu_dm_connector_atomic_duplicate_state(struct 
drm_connector *connector)
return _state->base;
 }
 
+static int
+amdgpu_dm_connector_late_register(struct drm_connector *connector)
+{
+   struct amdgpu_dm_connector *amdgpu_dm_connector =
+   to_amdgpu_dm_connector(connector);
+
+#if defined(CONFIG_DEBUG_FS)
+   connector_debugfs_init(amdgpu_dm_connector);
+#endif
+
+   return 0;
+}
+
 static const struct drm_connector_funcs amdgpu_dm_connector_funcs = {
.reset = amdgpu_dm_connector_funcs_reset,
.detect = amdgpu_dm_connector_detect,
@@ -4495,6 +4508,7 @@ static const struct drm_connector_funcs 
amdgpu_dm_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_set_property = amdgpu_dm_connector_atomic_set_property,
.atomic_get_property = amdgpu_dm_connector_atomic_get_property,
+   .late_register = amdgpu_dm_connector_late_register,
.early_unregister = amdgpu_dm_connector_unregister
 };
 
@@ -5834,10 +5848,6 @@ static int amdgpu_dm_connector_init(struct 
amdgpu_display_manager *dm,
drm_connector_attach_encoder(
>base, >base);
 
-#if defined(CONFIG_DEBUG_FS)
-   connector_debugfs_init(aconnector);
-#endif
-
if (connector_type == DRM_MODE_CONNECTOR_DisplayPort
|| connector_type == DRM_MODE_CONNECTOR_eDP)
amdgpu_dm_initialize_dp_connector(dm, aconnector);
-- 
2.24.1

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

[PATCH 06/14] drm/amdgpu/gem: move debugfs init into core amdgpu debugfs

[Alex Deucher]

In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling.  Do this for gem.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index bcd10daa6e39..cb7db7edfc3f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1248,6 +1248,10 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
if (amdgpu_debugfs_fence_init(adev))
dev_err(adev->dev, "fence debugfs file creation failed\n");
 
+   r = amdgpu_debugfs_gem_init(adev);
+   if (r)
+   DRM_ERROR("registering gem debugfs failed (%d).\n", r);
+
return amdgpu_debugfs_add_files(adev, amdgpu_debugfs_list,
ARRAY_SIZE(amdgpu_debugfs_list));
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 3b09897eb1e9..64a275664c72 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3091,10 +3091,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
} else
adev->ucode_sysfs_en = true;
 
-   r = amdgpu_debugfs_gem_init(adev);
-   if (r)
-   DRM_ERROR("registering gem debugfs failed (%d).\n", r);
-
r = amdgpu_debugfs_regs_init(adev);
if (r)
DRM_ERROR("registering register debugfs failed (%d).\n", r);
-- 
2.24.1

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

[PATCH 08/14] drm/amdgpu/firmware: move debugfs init into core amdgpu debugfs

[Alex Deucher]

In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling.  Do this for firmware.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 7721f1416cdb..5bf43f20ec30 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1256,6 +1256,10 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
if (r)
DRM_ERROR("registering register debugfs failed (%d).\n", r);
 
+   r = amdgpu_debugfs_firmware_init(adev);
+   if (r)
+   DRM_ERROR("registering firmware debugfs failed (%d).\n", r);
+
return amdgpu_debugfs_add_files(adev, amdgpu_debugfs_list,
ARRAY_SIZE(amdgpu_debugfs_list));
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index d84a61e18bf8..4dc7145368fc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3091,10 +3091,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
} else
adev->ucode_sysfs_en = true;
 
-   r = amdgpu_debugfs_firmware_init(adev);
-   if (r)
-   DRM_ERROR("registering firmware debugfs failed (%d).\n", r);
-
r = amdgpu_debugfs_init(adev);
if (r)
DRM_ERROR("Creating debugfs files failed (%d).\n", r);
-- 
2.24.1

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

[PATCH 10/14] drm/amdgpu/display: move debugfs init into core amdgpu debugfs

[Alex Deucher]

In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling.  Do this for display.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c   | 6 ++
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 -
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 5bf43f20ec30..82d30bae2ba0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -32,6 +32,7 @@
 
 #include "amdgpu.h"
 #include "amdgpu_pm.h"
+#include "amdgpu_dm_debugfs.h"
 
 /**
  * amdgpu_debugfs_add_files - Add simple debugfs entries
@@ -1260,6 +1261,11 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
if (r)
DRM_ERROR("registering firmware debugfs failed (%d).\n", r);
 
+   if (amdgpu_device_has_dc_support(adev)) {
+   if (dtn_debugfs_init(adev))
+   DRM_ERROR("amdgpu: failed initialize dtn debugfs 
support.\n");
+   }
+
return amdgpu_debugfs_add_files(adev, amdgpu_debugfs_list,
ARRAY_SIZE(amdgpu_debugfs_list));
 }
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 7c094bfe07e2..efe74a8a8ace 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -991,11 +991,6 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
goto error;
}
 
-#if defined(CONFIG_DEBUG_FS)
-   if (dtn_debugfs_init(adev))
-   DRM_ERROR("amdgpu: failed initialize dtn debugfs support.\n");
-#endif
-
DRM_DEBUG_DRIVER("KMS initialized.\n");
 
return 0;
-- 
2.24.1

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

[PATCH 02/14] drm/amdgpu/ttm: move debugfs init into core amdgpu debugfs

[Alex Deucher]

In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling.  Do this for ttm.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 10 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  3 +++
 3 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 58b5e1b4f814..f49604c0d0b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1216,6 +1216,8 @@ DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL,
 
 int amdgpu_debugfs_init(struct amdgpu_device *adev)
 {
+   int r;
+
adev->debugfs_preempt =
debugfs_create_file("amdgpu_preempt_ib", 0600,
adev->ddev->primary->debugfs_root, adev,
@@ -1225,12 +1227,20 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
return -EIO;
}
 
+   /* Register debugfs entries for amdgpu_ttm */
+   r = amdgpu_ttm_debugfs_init(adev);
+   if (r) {
+   DRM_ERROR("Failed to init debugfs\n");
+   return r;
+   }
+
return amdgpu_debugfs_add_files(adev, amdgpu_debugfs_list,
ARRAY_SIZE(amdgpu_debugfs_list));
 }
 
 void amdgpu_debugfs_fini(struct amdgpu_device *adev)
 {
+   amdgpu_ttm_debugfs_fini(adev);
debugfs_remove(adev->debugfs_preempt);
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 56f743698868..0c35978626d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -66,9 +66,6 @@ static int amdgpu_map_buffer(struct ttm_buffer_object *bo,
 struct amdgpu_ring *ring,
 uint64_t *addr);
 
-static int amdgpu_ttm_debugfs_init(struct amdgpu_device *adev);
-static void amdgpu_ttm_debugfs_fini(struct amdgpu_device *adev);
-
 static int amdgpu_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
 {
return 0;
@@ -1911,12 +1908,6 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
return r;
}
 
-   /* Register debugfs entries for amdgpu_ttm */
-   r = amdgpu_ttm_debugfs_init(adev);
-   if (r) {
-   DRM_ERROR("Failed to init debugfs\n");
-   return r;
-   }
return 0;
 }
 
@@ -1938,7 +1929,6 @@ void amdgpu_ttm_fini(struct amdgpu_device *adev)
if (!adev->mman.initialized)
return;
 
-   amdgpu_ttm_debugfs_fini(adev);
amdgpu_ttm_training_reserve_vram_fini(adev);
/* return the IP Discovery TMR memory back to VRAM */
amdgpu_bo_free_kernel(>discovery_memory, NULL, NULL);
@@ -2545,7 +2535,7 @@ static const struct {
 
 #endif
 
-static int amdgpu_ttm_debugfs_init(struct amdgpu_device *adev)
+int amdgpu_ttm_debugfs_init(struct amdgpu_device *adev)
 {
 #if defined(CONFIG_DEBUG_FS)
unsigned count;
@@ -2581,7 +2571,7 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
 #endif
 }
 
-static void amdgpu_ttm_debugfs_fini(struct amdgpu_device *adev)
+void amdgpu_ttm_debugfs_fini(struct amdgpu_device *adev)
 {
 #if defined(CONFIG_DEBUG_FS)
unsigned i;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index f1ebd424510c..2c4ad5b589d0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -133,4 +133,7 @@ uint64_t amdgpu_ttm_tt_pde_flags(struct ttm_tt *ttm, struct 
ttm_mem_reg *mem);
 uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device *adev, struct ttm_tt 
*ttm,
 struct ttm_mem_reg *mem);
 
+int amdgpu_ttm_debugfs_init(struct amdgpu_device *adev);
+void amdgpu_ttm_debugfs_fini(struct amdgpu_device *adev);
+
 #endif
-- 
2.24.1

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

[PATCH 13/14] drm/amdgpu/ring: move debugfs init into core amdgpu debugfs

[Alex Deucher]

In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling.  Do this for rings.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 23 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c| 15 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h|  4 
 3 files changed, 29 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 82d30bae2ba0..a7e6b5de2c62 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1218,7 +1218,7 @@ DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL,
 
 int amdgpu_debugfs_init(struct amdgpu_device *adev)
 {
-   int r;
+   int r, i;
 
adev->debugfs_preempt =
debugfs_create_file("amdgpu_preempt_ib", 0600,
@@ -1266,12 +1266,33 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
DRM_ERROR("amdgpu: failed initialize dtn debugfs 
support.\n");
}
 
+   for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
+   struct amdgpu_ring *ring = adev->rings[i];
+
+   if (!ring)
+   continue;
+
+   if (amdgpu_debugfs_ring_init(adev, ring)) {
+   DRM_ERROR("Failed to register debugfs file for rings 
!\n");
+   }
+   }
+
return amdgpu_debugfs_add_files(adev, amdgpu_debugfs_list,
ARRAY_SIZE(amdgpu_debugfs_list));
 }
 
 void amdgpu_debugfs_fini(struct amdgpu_device *adev)
 {
+   int i;
+
+   for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
+   struct amdgpu_ring *ring = adev->rings[i];
+
+   if (!ring)
+   continue;
+
+   amdgpu_debugfs_ring_fini(ring);
+   }
amdgpu_ttm_debugfs_fini(adev);
debugfs_remove(adev->debugfs_preempt);
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
index e5c83e164d82..539be138260e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
@@ -48,9 +48,6 @@
  * wptr.  The GPU then starts fetching commands and executes
  * them until the pointers are equal again.
  */
-static int amdgpu_debugfs_ring_init(struct amdgpu_device *adev,
-   struct amdgpu_ring *ring);
-static void amdgpu_debugfs_ring_fini(struct amdgpu_ring *ring);
 
 /**
  * amdgpu_ring_alloc - allocate space on the ring buffer
@@ -334,10 +331,6 @@ int amdgpu_ring_init(struct amdgpu_device *adev, struct 
amdgpu_ring *ring,
for (i = 0; i < DRM_SCHED_PRIORITY_MAX; ++i)
atomic_set(>num_jobs[i], 0);
 
-   if (amdgpu_debugfs_ring_init(adev, ring)) {
-   DRM_ERROR("Failed to register debugfs file for rings !\n");
-   }
-
return 0;
 }
 
@@ -367,8 +360,6 @@ void amdgpu_ring_fini(struct amdgpu_ring *ring)
  >gpu_addr,
  (void **)>ring);
 
-   amdgpu_debugfs_ring_fini(ring);
-
dma_fence_put(ring->vmid_wait);
ring->vmid_wait = NULL;
ring->me = 0;
@@ -485,8 +476,8 @@ static const struct file_operations 
amdgpu_debugfs_ring_fops = {
 
 #endif
 
-static int amdgpu_debugfs_ring_init(struct amdgpu_device *adev,
-   struct amdgpu_ring *ring)
+int amdgpu_debugfs_ring_init(struct amdgpu_device *adev,
+struct amdgpu_ring *ring)
 {
 #if defined(CONFIG_DEBUG_FS)
struct drm_minor *minor = adev->ddev->primary;
@@ -507,7 +498,7 @@ static int amdgpu_debugfs_ring_init(struct amdgpu_device 
*adev,
return 0;
 }
 
-static void amdgpu_debugfs_ring_fini(struct amdgpu_ring *ring)
+void amdgpu_debugfs_ring_fini(struct amdgpu_ring *ring)
 {
 #if defined(CONFIG_DEBUG_FS)
debugfs_remove(ring->ent);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 5134d0dd6dc2..0d098dafd23c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -329,4 +329,8 @@ static inline void amdgpu_ring_write_multiple(struct 
amdgpu_ring *ring,
 
 int amdgpu_ring_test_helper(struct amdgpu_ring *ring);
 
+int amdgpu_debugfs_ring_init(struct amdgpu_device *adev,
+struct amdgpu_ring *ring);
+void amdgpu_debugfs_ring_fini(struct amdgpu_ring *ring);
+
 #endif
-- 
2.24.1

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

[PATCH 07/14] drm/amdgpu/regs: move debugfs init into core amdgpu debugfs

[Alex Deucher]

In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling.  Do this for register access files.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index cb7db7edfc3f..7721f1416cdb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1252,6 +1252,10 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
if (r)
DRM_ERROR("registering gem debugfs failed (%d).\n", r);
 
+   r = amdgpu_debugfs_regs_init(adev);
+   if (r)
+   DRM_ERROR("registering register debugfs failed (%d).\n", r);
+
return amdgpu_debugfs_add_files(adev, amdgpu_debugfs_list,
ARRAY_SIZE(amdgpu_debugfs_list));
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 64a275664c72..d84a61e18bf8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3091,10 +3091,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
} else
adev->ucode_sysfs_en = true;
 
-   r = amdgpu_debugfs_regs_init(adev);
-   if (r)
-   DRM_ERROR("registering register debugfs failed (%d).\n", r);
-
r = amdgpu_debugfs_firmware_init(adev);
if (r)
DRM_ERROR("registering firmware debugfs failed (%d).\n", r);
-- 
2.24.1

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

[PATCH 03/14] drm/amdgpu/pm: move debugfs init into core amdgpu debugfs

[Alex Deucher]

In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling.  Do this for pm.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 7 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c  | 9 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h  | 2 ++
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index f49604c0d0b8..c1d66cc6e6d8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -31,6 +31,7 @@
 #include 
 
 #include "amdgpu.h"
+#include "amdgpu_pm.h"
 
 /**
  * amdgpu_debugfs_add_files - Add simple debugfs entries
@@ -1234,6 +1235,12 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
return r;
}
 
+   r = amdgpu_debugfs_pm_init(adev);
+   if (r) {
+   DRM_ERROR("Failed to register debugfs file for dpm!\n");
+   return r;
+   }
+
return amdgpu_debugfs_add_files(adev, amdgpu_debugfs_list,
ARRAY_SIZE(amdgpu_debugfs_list));
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index b03b1eb7ba04..bc3cf04a1a94 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -41,8 +41,6 @@
 #include "hwmgr.h"
 #define WIDTH_4K 3840
 
-static int amdgpu_debugfs_pm_init(struct amdgpu_device *adev);
-
 static const struct cg_flag_name clocks[] = {
{AMD_CG_SUPPORT_GFX_MGCG, "Graphics Medium Grain Clock Gating"},
{AMD_CG_SUPPORT_GFX_MGLS, "Graphics Medium Grain memory Light Sleep"},
@@ -3398,11 +3396,6 @@ int amdgpu_pm_sysfs_init(struct amdgpu_device *adev)
DRM_ERROR("failed to create device file unique_id\n");
return ret;
}
-   ret = amdgpu_debugfs_pm_init(adev);
-   if (ret) {
-   DRM_ERROR("Failed to register debugfs file for dpm!\n");
-   return ret;
-   }
 
if ((adev->asic_type >= CHIP_VEGA10) &&
!(adev->flags & AMD_IS_APU)) {
@@ -3669,7 +3662,7 @@ static const struct drm_info_list amdgpu_pm_info_list[] = 
{
 };
 #endif
 
-static int amdgpu_debugfs_pm_init(struct amdgpu_device *adev)
+int amdgpu_debugfs_pm_init(struct amdgpu_device *adev)
 {
 #if defined(CONFIG_DEBUG_FS)
return amdgpu_debugfs_add_files(adev, amdgpu_pm_info_list, 
ARRAY_SIZE(amdgpu_pm_info_list));
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h
index 3da1da277805..5db0ef86e84c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h
@@ -43,4 +43,6 @@ void amdgpu_dpm_enable_uvd(struct amdgpu_device *adev, bool 
enable);
 void amdgpu_dpm_enable_vce(struct amdgpu_device *adev, bool enable);
 void amdgpu_dpm_enable_jpeg(struct amdgpu_device *adev, bool enable);
 
+int amdgpu_debugfs_pm_init(struct amdgpu_device *adev);
+
 #endif
-- 
2.24.1

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

[PATCH 04/14] drm/amdgpu/sa: move debugfs init into core amdgpu debugfs

[Alex Deucher]

In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling.  Do this for SA (sub allocator).

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c  | 7 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  | 1 +
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index c1d66cc6e6d8..84c5e9f23c76 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1241,6 +1241,10 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
return r;
}
 
+   if (amdgpu_debugfs_sa_init(adev)) {
+   dev_err(adev->dev, "failed to register debugfs file for SA\n");
+   }
+
return amdgpu_debugfs_add_files(adev, amdgpu_debugfs_list,
ARRAY_SIZE(amdgpu_debugfs_list));
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 6e0f97afb030..abf286f2bc5e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -48,7 +48,6 @@
  * produce command buffers which are send to the kernel and
  * put in IBs for execution by the requested ring.
  */
-static int amdgpu_debugfs_sa_init(struct amdgpu_device *adev);
 
 /**
  * amdgpu_ib_get - request an IB (Indirect Buffer)
@@ -295,9 +294,7 @@ int amdgpu_ib_pool_init(struct amdgpu_device *adev)
}
 
adev->ib_pool_ready = true;
-   if (amdgpu_debugfs_sa_init(adev)) {
-   dev_err(adev->dev, "failed to register debugfs file for SA\n");
-   }
+
return 0;
 }
 
@@ -421,7 +418,7 @@ static const struct drm_info_list amdgpu_debugfs_sa_list[] 
= {
 
 #endif
 
-static int amdgpu_debugfs_sa_init(struct amdgpu_device *adev)
+int amdgpu_debugfs_sa_init(struct amdgpu_device *adev)
 {
 #if defined(CONFIG_DEBUG_FS)
return amdgpu_debugfs_add_files(adev, amdgpu_debugfs_sa_list, 1);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 26a654cbd530..7d41f7b9a340 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -330,6 +330,7 @@ void amdgpu_sa_bo_free(struct amdgpu_device *adev,
 void amdgpu_sa_bo_dump_debug_info(struct amdgpu_sa_manager *sa_manager,
 struct seq_file *m);
 #endif
+int amdgpu_debugfs_sa_init(struct amdgpu_device *adev);
 
 bool amdgpu_bo_support_uswc(u64 bo_flags);
 
-- 
2.24.1

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

[PATCH 01/14] drm/amdgpu: rename amdgpu_debugfs_preempt_cleanup

[Alex Deucher]

to amdgpu_debugfs_fini.  It will be used for other things in
the future.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index f24ed9a1a3e5..58b5e1b4f814 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1229,7 +1229,7 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
ARRAY_SIZE(amdgpu_debugfs_list));
 }
 
-void amdgpu_debugfs_preempt_cleanup(struct amdgpu_device *adev)
+void amdgpu_debugfs_fini(struct amdgpu_device *adev)
 {
debugfs_remove(adev->debugfs_preempt);
 }
@@ -1239,7 +1239,7 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
 {
return 0;
 }
-void amdgpu_debugfs_preempt_cleanup(struct amdgpu_device *adev) { }
+void amdgpu_debugfs_fini(struct amdgpu_device *adev) { }
 int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
 {
return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h
index f289d28ad6b2..b382527e359a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h
@@ -34,7 +34,7 @@ struct amdgpu_debugfs {
 int amdgpu_debugfs_regs_init(struct amdgpu_device *adev);
 void amdgpu_debugfs_regs_cleanup(struct amdgpu_device *adev);
 int amdgpu_debugfs_init(struct amdgpu_device *adev);
-void amdgpu_debugfs_preempt_cleanup(struct amdgpu_device *adev);
+void amdgpu_debugfs_fini(struct amdgpu_device *adev);
 int amdgpu_debugfs_add_files(struct amdgpu_device *adev,
 const struct drm_info_list *files,
 unsigned nfiles);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8df7727815cb..3b09897eb1e9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3228,7 +3228,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
amdgpu_ucode_sysfs_fini(adev);
if (IS_ENABLED(CONFIG_PERF_EVENTS))
amdgpu_pmu_fini(adev);
-   amdgpu_debugfs_preempt_cleanup(adev);
+   amdgpu_debugfs_fini(adev);
if (amdgpu_discovery && adev->asic_type >= CHIP_NAVI10)
amdgpu_discovery_fini(adev);
 }
-- 
2.24.1

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

[PATCH 05/14] drm/amdgpu/fence: move debugfs init into core amdgpu debugfs

[Alex Deucher]

In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling.  Do this for fence handling.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c   | 3 ---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 84c5e9f23c76..bcd10daa6e39 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1245,6 +1245,9 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
dev_err(adev->dev, "failed to register debugfs file for SA\n");
}
 
+   if (amdgpu_debugfs_fence_init(adev))
+   dev_err(adev->dev, "fence debugfs file creation failed\n");
+
return amdgpu_debugfs_add_files(adev, amdgpu_debugfs_list,
ARRAY_SIZE(amdgpu_debugfs_list));
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 3c01252b1e0e..7531527067df 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -503,9 +503,6 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring *ring,
  */
 int amdgpu_fence_driver_init(struct amdgpu_device *adev)
 {
-   if (amdgpu_debugfs_fence_init(adev))
-   dev_err(adev->dev, "fence debugfs file creation failed\n");
-
return 0;
 }
 
-- 
2.24.1

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

[PATCH 00/14] amdgpu: remove load and unload callbacks

[Alex Deucher]

These are deprecated and the drm will soon start warning when drivers still
use them.  It was a long and twisty road, but seems to work.

Alex Deucher (14):
  drm/amdgpu: rename amdgpu_debugfs_preempt_cleanup
  drm/amdgpu/ttm: move debugfs init into core amdgpu debugfs
  drm/amdgpu/pm: move debugfs init into core amdgpu debugfs
  drm/amdgpu/sa: move debugfs init into core amdgpu debugfs
  drm/amdgpu/fence: move debugfs init into core amdgpu debugfs
  drm/amdgpu/gem: move debugfs init into core amdgpu debugfs
  drm/amdgpu/regs: move debugfs init into core amdgpu debugfs
  drm/amdgpu/firmware: move debugfs init into core amdgpu debugfs
  drm/amdgpu: don't call drm_connector_register for non-MST ports
  drm/amdgpu/display: move debugfs init into core amdgpu debugfs
  drm/amd/display: move dpcd debugfs members setup
  drm/amdgpu/display: add a late register connector callback
  drm/amdgpu/ring: move debugfs init into core amdgpu debugfs
  drm/amdgpu: drop legacy drm load and unload callbacks

 .../gpu/drm/amd/amdgpu/amdgpu_connectors.c|  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c   | 67 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 17 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 13 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c |  3 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c|  7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c|  9 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h|  2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c  | 15 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h  |  4 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   | 14 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h   |  3 +
 drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  1 -
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 26 +++
 .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c |  3 +
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  2 -
 18 files changed, 112 insertions(+), 78 deletions(-)

-- 
2.24.1

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

Re: [PATCH 1/5] drm: Remove PageReserved manipulation from drm_pci_alloc

[Chris Wilson]

Quoting Alex Deucher (2020-02-03 21:49:48)
> On Sun, Feb 2, 2020 at 12:16 PM Chris Wilson  wrote:
> >
> > drm_pci_alloc/drm_pci_free are very thin wrappers around the core dma
> > facilities, and we have no special reason within the drm layer to behave
> > differently. In particular, since
> >
> > commit de09d31dd38a50fdce106c15abd68432eebbd014
> > Author: Kirill A. Shutemov 
> > Date:   Fri Jan 15 16:51:42 2016 -0800
> >
> > page-flags: define PG_reserved behavior on compound pages
> >
> > As far as I can see there's no users of PG_reserved on compound pages.
> > Let's use PF_NO_COMPOUND here.
> >
> > it has been illegal to combine GFP_COMP with SetPageReserved, so lets
> > stop doing both and leave the dma layer to its own devices.
> >
> > Reported-by: Taketo Kabe
> 
> Needs an email address.

None provided, I don't insist that they opt in to potential spam
harvesting.

> > Closes: https://gitlab.freedesktop.org/drm/intel/issues/1027
> 
> Should be Bug: rather than Closes:

We're using Closes for gitlab, since we hope to integrate with gitlab
someday. (Or at least some integrated bug/source management, of which
gitlab is the current forerunner.)
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1] drm: shmobile: Platform data shan't include kernel.h

[Geert Uytterhoeven]

Hi Andy,

On Tue, Feb 4, 2020 at 8:30 PM Andy Shevchenko
 wrote:
> On Tue, Feb 04, 2020 at 08:26:21PM +0200, Laurent Pinchart wrote:
> > On Tue, Feb 04, 2020 at 06:39:34PM +0100, Geert Uytterhoeven wrote:
> > > On Tue, Feb 4, 2020 at 5:20 PM Andy Shevchenko wrote:
> > > > Replace with appropriate types.h.
> > >
> > > Thanks for your patch!
> > >
> > > I have only one very short question: why?
> >
> > Likewise :-) The patch itself looks fine, but the commit message is a
> > bit terse.
>
> The kernel.h for a long time being a dump of a lot of things. I started
> cleaning it up a bit. During this I notice that developers too far too lazy to
> use appropriate headers. For platform data kernel.h by definition is not
> appropriate.

Thanks, that makes perfect sense.

> Any suggestion what should I put to commit message?

I became intrigued by the one-line summary, which seemed to suggest
(according to my interpretation) that including kernel.h is a Real Bad
Thing.

But basically all you wanted to say was:

drm: shmobile: Reduce include dependencies

and:

This file doesn't need everything provided by .
All it needs are some types, which are provided by .

Right?

BTW,  already includes , but not relying
on implicit includes is indeed a good thing.

Gr{oetje,eeting}s,

Geert

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

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

[PATCH 4/4] drm/i915: Force DPCD backlight mode for some Precision 7750 panels

[Lyude Paul]

According to Dell, trying to match their panels via OUI is not reliable
enough and we've been told that we should check against the EDID
instead. As well, Dell seems to have some panels that are actually
intended to switch between using PWM for backlight controls and DPCD for
backlight controls depending on whether or not the panel is in HDR or
SDR mode. Yikes.

Regardless, we need to add quirks for these so that DPCD backlight
controls get enabled by default, since without additional driver support
that's the only form of brightness control that will work. Hopefully in
the future we can remove these quirks once we have a better way of
probing for this.

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
---
 drivers/gpu/drm/drm_dp_helper.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a39c3cdacb20..c24bbea3e2a2 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1240,6 +1240,19 @@ static const struct edid_quirk edid_quirk_list[] = {
 * only supports DPCD backlight controls
 */
{ MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
+   /*
+* Some Dell Precision 7750 systems have panels support both AUX and
+* PWM backlight control, and some only support AUX backlight control.
+* All said panels start up in AUX mode by default, and we don't have
+* any support for disabling HDR mode on these panels which would be
+* required to switch to PWM backlight control mode (plus, I'm not
+* even sure we want PWM backlight controls over DPCD backlight
+* controls anyway...). Until we have a better way of detecting these,
+* force DPCD backlight mode on all of them.
+*/
+   { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
+   { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
+   { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
 };
 
 #undef MFG
-- 
2.24.1

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

[PATCH 0/4] drm/dp,i915: eDP DPCD backlight control detection fixes

[Lyude Paul]

Unfortunately, it turned out that the DPCD is also not a reliable way of
probing for DPCD backlight support as some panels will lie and say they
have DPCD backlight controls when they don't actually.

So, revert back to the old behavior and add a bunch of EDID-based DP
quirks for the panels that we know need this. As you might have already
guessed, OUI quirks didn't seem to be a very safe bet for these panels
due to them not having their device IDs filled out.

Lyude Paul (4):
  Revert "drm/i915: Don't use VBT for detecting DPCD backlight controls"
  drm/dp: Introduce EDID-based quirks
  drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED
panel
  drm/i915: Force DPCD backlight mode for some Precision 7750 panels

 drivers/gpu/drm/drm_dp_helper.c   | 78 +++
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 11 ++-
 .../drm/i915/display/intel_dp_aux_backlight.c | 28 +--
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 21 -
 8 files changed, 130 insertions(+), 16 deletions(-)

-- 
2.24.1

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

[PATCH 2/4] drm/dp: Introduce EDID-based quirks

[Lyude Paul]

The whole point of using OUIs is so that we can recognize certain
devices and potentially apply quirks for them. Normally this should work
quite well, but there appears to be quite a number of laptop panels out
there that will fill the OUI but not the device ID. As such, for devices
like this I can't imagine it's a very good idea to try relying on OUIs
for applying quirks. As well, some laptop vendors have confirmed to us
that their panels have this exact issue.

So, let's introduce the ability to apply DP quirks based on EDID
identification. We reuse the same quirk bits for OUI-based quirks, so
that callers can simply check all possible quirks using
drm_dp_has_quirk().

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
---
 drivers/gpu/drm/drm_dp_helper.c   | 61 +++
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 11 ++--
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 11 +++-
 7 files changed, 81 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5a103e9b3c86..db23308f4d8b 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1221,6 +1221,67 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, 
bool is_branch)
 #undef DEVICE_ID_ANY
 #undef DEVICE_ID
 
+struct edid_quirk {
+   u8 mfg_id[2];
+   u8 prod_id[2];
+   u32 quirks;
+};
+
+#define MFG(first, second) { (first), (second) }
+#define PROD_ID(first, second) { (first), (second) }
+
+/*
+ * Some devices have unreliable OUIDs where they don't set the device ID
+ * correctly, and as a result we need to use the EDID for finding additional
+ * DP quirks in such cases.
+ */
+static const struct edid_quirk edid_quirk_list[] = {
+};
+
+#undef MFG
+#undef PROD_ID
+
+/**
+ * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
+ * DP-specific quirks
+ * @edid: The EDID to check
+ *
+ * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
+ * of manufacturers don't seem to like following standards and neglect to fill
+ * the dev-ID in, making it impossible to only use OUIDs for determining
+ * quirks in some cases. This function can be used to check the EDID and look
+ * up any additional DP quirks. The bits returned by this function correspond
+ * to the quirk bits in _dp_quirk.
+ *
+ * Returns: a bitmask of quirks, if any. The driver can check this using
+ * drm_dp_has_quirk().
+ */
+u32 drm_dp_get_edid_quirks(const struct edid *edid)
+{
+   const struct edid_quirk *quirk;
+   u32 quirks = 0;
+   int i;
+
+   if (!edid)
+   return 0;
+
+   for (i = 0; i < ARRAY_SIZE(edid_quirk_list); i++) {
+   quirk = _quirk_list[i];
+   if (memcmp(quirk->mfg_id, edid->mfg_id,
+  sizeof(edid->mfg_id)) == 0 &&
+   memcmp(quirk->prod_id, edid->prod_code,
+  sizeof(edid->prod_code)) == 0)
+   quirks |= quirk->quirks;
+   }
+
+   DRM_DEBUG_KMS("DP sink: EDID mfg %*phD prod-ID %*phD quirks: 0x%04x\n",
+ (int)sizeof(edid->mfg_id), edid->mfg_id,
+ (int)sizeof(edid->prod_code), edid->prod_code, quirks);
+
+   return quirks;
+}
+EXPORT_SYMBOL(drm_dp_get_edid_quirks);
+
 /**
  * drm_dp_read_desc - read sink/branch descriptor from DPCD
  * @aux: DisplayPort AUX channel
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index a811247cecfe..68247670427a 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -5452,7 +5452,8 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct 
drm_dp_mst_port *port)
if (drm_dp_read_desc(port->mgr->aux, , true))
return NULL;
 
-   if (drm_dp_has_quirk(, DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) &&
+   if (drm_dp_has_quirk(, 0,
+DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) &&
port->mgr->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14 &&
port->parent == port->mgr->mst_primary) {
u8 downstreamport;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 7c6133a9c51b..eebf02ff4ed2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1231,6 +1231,7 @@ struct intel_dp {
int max_link_rate;
/* sink or branch descriptor */
struct drm_dp_desc desc;
+   u32 edid_quirks;
struct drm_dp_aux aux;
u32 aux_busy_last_status;
u8 train_set[4];
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c

[PATCH 3/4] drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel

[Lyude Paul]

The X1 Extreme is one of the systems that lies about which backlight
interface that it uses in its VBIOS as PWM backlight controls don't work
at all on this machine. It's possible that this panel could be one of
the infamous ones that can switch between PWM mode and DPCD backlight
control mode, but we haven't gotten any more details on this from Lenovo
just yet. For the time being though, making sure the backlight 'just
works' is a bit more important.

So, add a quirk to force DPCD backlight controls on for these systems
based on EDID (since this panel doesn't appear to fill in the device ID).
Hopefully in the future we'll figure out a better way of probing this.

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
---
 drivers/gpu/drm/drm_dp_helper.c   |  4 +++
 .../drm/i915/display/intel_dp_aux_backlight.c | 25 ---
 include/drm/drm_dp_helper.h   | 10 
 3 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index db23308f4d8b..a39c3cdacb20 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1236,6 +1236,10 @@ struct edid_quirk {
  * DP quirks in such cases.
  */
 static const struct edid_quirk edid_quirk_list[] = {
+   /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
+* only supports DPCD backlight controls
+*/
+   { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
 };
 
 #undef MFG
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 48276237b362..35a19c0314fa 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -328,15 +328,32 @@ intel_dp_aux_display_control_capable(struct 
intel_connector *connector)
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
 {
struct intel_panel *panel = _connector->panel;
-   struct drm_i915_private *dev_priv = to_i915(intel_connector->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
+   struct drm_device *dev = intel_connector->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
 
if (i915_modparams.enable_dpcd_backlight == 0 ||
-   (i915_modparams.enable_dpcd_backlight == -1 &&
-   dev_priv->vbt.backlight.type != 
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE))
+   !intel_dp_aux_display_control_capable(intel_connector))
return -ENODEV;
 
-   if (!intel_dp_aux_display_control_capable(intel_connector))
+   /*
+* There are a lot of machines that don't advertise the backlight
+* control interface to use properly in their VBIOS, :\
+*/
+   if (dev_priv->vbt.backlight.type !=
+   INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
+   !drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
+ DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
+   DRM_DEV_INFO(dev->dev,
+"Panel advertises DPCD backlight support, but "
+"VBT disagrees. If your backlight controls "
+"don't work try booting with "
+"i915.enable_dpcd_backlight=1. If your machine "
+"needs this, please file a _new_ bug report on "
+"bugs.freedesktop.org against DRI -> "
+"DRM/Intel\n");
return -ENODEV;
+   }
 
panel->backlight.setup = intel_dp_aux_setup_backlight;
panel->backlight.enable = intel_dp_aux_enable_backlight;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 7f5dd2ee4a94..c5580e988826 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1535,6 +1535,16 @@ enum drm_dp_quirk {
 * The DSC caps can be read from the physical aux instead.
 */
DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
+   /**
+* @DP_QUIRK_FORCE_DPCD_BACKLIGHT:
+*
+* The device is telling the truth when it says that it uses DPCD
+* backlight controls, even if the system's firmware disagrees. This
+* quirk should be checked against both the ident and panel EDID.
+* When present, the driver should honor the DPCD backlight
+* capabilities advertised.
+*/
+   DP_QUIRK_FORCE_DPCD_BACKLIGHT,
 };
 
 /**
-- 
2.24.1

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

[PATCH 1/4] Revert "drm/i915: Don't use VBT for detecting DPCD backlight controls"

[Lyude Paul]

This reverts commit d2a4bb6f8bc8cf2d788adf7e59b5b52fe3ac.

So, turns out that this ended up just breaking things. While many
laptops incorrectly advertise themselves as supporting PWM backlight
controls, they actually will only work with DPCD backlight controls.
Unfortunately, it also seems there are a number of systems which
advertise DPCD backlight controls in their eDP DPCD but don't actually
support them. Talking with some laptop manufacturers has shown it might
be possible to probe this support via the EDID (!?!?) but I haven't been
able to confirm that this would work on any other manufacturer's
systems.

So in the mean time, we'll just revert this commit for now and go back
to the old way of doing things. Additionally, let's print out an info
message into the kernel log so that it's a little more obvious if a
system needs DPCD backlight controls enabled through a quirk (which
we'll introduce in the next commit).

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index e86feebef299..48276237b362 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -328,16 +328,15 @@ intel_dp_aux_display_control_capable(struct 
intel_connector *connector)
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
 {
struct intel_panel *panel = _connector->panel;
-   enum intel_backlight_type type =
-   to_i915(intel_connector->base.dev)->vbt.backlight.type;
+   struct drm_i915_private *dev_priv = to_i915(intel_connector->base.dev);
 
if (i915_modparams.enable_dpcd_backlight == 0 ||
(i915_modparams.enable_dpcd_backlight == -1 &&
-!intel_dp_aux_display_control_capable(intel_connector)))
+   dev_priv->vbt.backlight.type != 
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE))
return -ENODEV;
 
-   if (type != INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
-   DRM_DEBUG_DRIVER("Ignoring VBT backlight type\n");
+   if (!intel_dp_aux_display_control_capable(intel_connector))
+   return -ENODEV;
 
panel->backlight.setup = intel_dp_aux_setup_backlight;
panel->backlight.enable = intel_dp_aux_enable_backlight;
-- 
2.24.1

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

Re: [v5] arm64: dts: sc7180: add display dt nodes

[Doug Anderson]

Hi,

On Tue, Feb 4, 2020 at 6:15 AM Harigovindan P  wrote:
>
> Add display, DSI hardware DT nodes for sc7180.
>
> Co-developed-by: Kalyan Thota 
> Signed-off-by: Kalyan Thota 
> Signed-off-by: Harigovindan P 
> ---
>
> Changes in v1:
> - Added display DT nodes for sc7180
> Changes in v2:
> - Renamed node names
> - Corrected code alignments
> - Removed extra new line
> - Added DISP AHB clock for register access
>   under display_subsystem node for global settings
> Changes in v3:
> - Modified node names
> - Modified hard coded values
> - Removed mdss reg entry
> Changes in v4:
> - Reverting mdp node name
> - Setting status to disabled in main SOC dtsi file
> - Replacing _ to - for node names
> - Adding clock dependency patch link
> - Splitting idp dt file to a separate patch
> Changes in v5:
> - Renaming "gcc_bus" to "bus" as per bindings (Doug Anderson)
> - Making status as disabled for mdss and mdss_mdp by default (Doug 
> Anderson)
> - Removing "disp_cc" register space (Doug Anderson)
> - Renaming "dsi_controller" to "dsi" as per bindings (Doug Anderson)
> - Providing "ref" clk for dsi_phy (Doug Anderson)
> - Sorting mdss node before dispcc (Doug Anderson)
>
> This patch has dependency on the below series
> https://lkml.org/lkml/2019/12/27/73

You should have probably pointed to [1] which is a much newer version.


>  arch/arm64/boot/dts/qcom/sc7180.dtsi | 136 
> ++-
>  1 file changed, 134 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index bd2584d..3ac1b87 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -1173,13 +1173,145 @@
> #power-domain-cells = <1>;
> };
>
> +   mdss: mdss@ae0 {
> +   compatible = "qcom,sc7180-mdss";
> +   reg = <0 0x0ae0 0 0x1000>;
> +   reg-names = "mdss";
> +
> +   power-domains = < MDSS_GDSC>;
> +
> +   clocks = < GCC_DISP_AHB_CLK>,
> +< GCC_DISP_HF_AXI_CLK>,
> +< DISP_CC_MDSS_AHB_CLK>,
> +< DISP_CC_MDSS_MDP_CLK>;
> +   clock-names = "iface", "bus", "ahb", "core";
> +
> +   assigned-clocks = < DISP_CC_MDSS_MDP_CLK>;
> +   assigned-clock-rates = <3>;
> +
> +   interrupts = ;
> +   interrupt-controller;
> +   #interrupt-cells = <1>;
> +
> +   iommus = <_smmu 0x800 0x2>;
> +
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +   ranges;
> +
> +   status = "disabled";
> +
> +   mdp: mdp@ae01000 {
> +   compatible = "qcom,sc7180-dpu";
> +   reg = <0 0x0ae01000 0 0x8f000>,
> + <0 0x0aeb 0 0x2008>;
> +   reg-names = "mdp", "vbif";
> +
> +   clocks = < DISP_CC_MDSS_AHB_CLK>,
> +< DISP_CC_MDSS_ROT_CLK>,
> +< DISP_CC_MDSS_MDP_LUT_CLK>,
> +< DISP_CC_MDSS_MDP_CLK>,
> +< DISP_CC_MDSS_VSYNC_CLK>;
> +   clock-names = "iface", "rot", "lut", "core",
> + "vsync";
> +   assigned-clocks = < 
> DISP_CC_MDSS_MDP_CLK>,
> + < 
> DISP_CC_MDSS_VSYNC_CLK>;
> +   assigned-clock-rates = <3>,
> +  <1920>;
> +
> +   interrupt-parent = <>;
> +   interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> +   status = "disabled";
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   port@0 {
> +   reg = <0>;
> +   dpu_intf1_out: endpoint {
> +   remote-endpoint = 
> <_in>;
> +   };
> +   };
> +   };
> +   };
> +
> +   dsi0: dsi@ae94000 {
> 

Re: [PATCH] drm/dp_mst: Check crc4 value while building sideband message

[Lyude Paul]

Reviewed-by: Lyude Paul 

On Mon, 2020-02-03 at 13:16 +0100, Benjamin Gaignard wrote:
> Check that computed crc value is matching the one encoded in the message.
> 
> Signed-off-by: Benjamin Gaignard 
> ---
> CC: ly...@redhat.com
> CC: airl...@linux.ie
> CC: jani.nik...@linux.intel.com
>  drivers/gpu/drm/drm_dp_mst_topology.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 822d2f177f90..eee899d6742b 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -736,6 +736,10 @@ static bool drm_dp_sideband_msg_build(struct
> drm_dp_sideband_msg_rx *msg,
>   if (msg->curchunk_idx >= msg->curchunk_len) {
>   /* do CRC */
>   crc4 = drm_dp_msg_data_crc4(msg->chunk, msg->curchunk_len -
> 1);
> + if (crc4 != msg->chunk[msg->curchunk_len - 1])
> + print_hex_dump(KERN_DEBUG, "wrong crc",
> +DUMP_PREFIX_NONE, 16, 1,
> +msg->chunk,  msg->curchunk_len, false);
>   /* copy chunk into bigger msg */
>   memcpy(>msg[msg->curlen], msg->chunk, msg->curchunk_len -
> 1);
>   msg->curlen += msg->curchunk_len - 1;
-- 
Cheers,
Lyude Paul

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

Re: [PATCH v1] drm: shmobile: Platform data shan't include kernel.h

[Laurent Pinchart]

On Tue, Feb 04, 2020 at 06:39:34PM +0100, Geert Uytterhoeven wrote:
> On Tue, Feb 4, 2020 at 5:20 PM Andy Shevchenko wrote:
> > Replace with appropriate types.h.
> 
> Thanks for your patch!
> 
> I have only one very short question: why?

Likewise :-) The patch itself looks fine, but the commit message is a
bit terse.

-- 
Regards,

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

Re: [v1] dt-bindings: msm:disp: update dsi and dpu bindings

[Doug Anderson]

Hi,

On Tue, Feb 4, 2020 at 6:15 AM Harigovindan P  wrote:
>
> Updating bindings of dsi and dpu by adding and removing certain
> properties.
>
> Signed-off-by: Harigovindan P 
> ---
>
> Changes in v1:
> - Adding "ahb" clock as a required property.
> - Adding "bus", "rot", "lut" as optional properties for sc7180 device.
> - Removing properties from dsi bindings that are unused.
> - Removing power-domain property since DSI is the child node of MDSS
>   and it will inherit supply from its parent.
>
>  Documentation/devicetree/bindings/display/msm/dpu.txt | 7 +++
>  Documentation/devicetree/bindings/display/msm/dsi.txt | 5 -
>  2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt 
> b/Documentation/devicetree/bindings/display/msm/dpu.txt
> index 551ae26..dd58472a 100644
> --- a/Documentation/devicetree/bindings/display/msm/dpu.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dpu.txt
> @@ -19,6 +19,7 @@ Required properties:
>The following clocks are required:
>* "iface"
>* "bus"
> +  * "ahb"

This is only required for sc7180?  ...or old SoCs should have had it
all along too?


>* "core"
>  - interrupts: interrupt signal from MDSS.
>  - interrupt-controller: identifies the node as an interrupt controller.
> @@ -50,6 +51,8 @@ Required properties:
>  - clock-names: device clock names, must be in same order as clocks property.
>The following clocks are required.
>* "bus"
> +  For the device "qcom,sc7180-dpu":
> +  * "bus" - is an optional property due to architecture change.

This is a really odd way to write it for two reasons:
* You're breaking up the flow of the list.
* This shouldn't be listed as "optional" in sc7180 but unless there is
some reason to ever provide it on sc7180.  It should simply be
disallowed.

Maybe instead just:

   The following clocks are required.
-  * "bus"
+  * "bus" (anything other than qcom,sc7180-dpu)

We really need to get this into yaml ASAP but that'd probably be OK to
tide us over.

NOTE: when converting to yaml, ideally we'll have a separate file per
SoC to avoid crazy spaghetti, see commit 2a8aa18c1131 ("dt-bindings:
clk: qcom: Fix self-validation, split, and clean cruft") in clk-next
for an example of starting the transition to one yaml per SoC (at
least for anything majorly different).


>* "iface"
>* "core"
>* "vsync"
> @@ -70,6 +73,10 @@ Optional properties:
>  - assigned-clocks: list of clock specifiers for clocks needing rate 
> assignment
>  - assigned-clock-rates: list of clock frequencies sorted in the same order as
>the assigned-clocks property.
> +- For the device "qcom,sc7180-dpu":
> +  clock-names: optional device clocks, needed for accessing LUT blocks.
> +  * "rot"
> +  * "lut"
>
>  Example:
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
> b/Documentation/devicetree/bindings/display/msm/dsi.txt
> index af95586..61d659a 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> @@ -8,13 +8,10 @@ Required properties:
>  - reg-names: The names of register regions. The following regions are 
> required:
>* "dsi_ctrl"
>  - interrupts: The interrupt signal from the DSI block.
> -- power-domains: Should be < MDSS_GDSC>.

Is this supposed to be removed from all SoCs using this bindings, or
just yours?

I'll also note that you left it in the "Example:" below.


>  - clocks: Phandles to device clocks.
>  - clock-names: the following clocks are required:
> -  * "mdp_core"
>* "iface"
>* "bus"
> -  * "core_mmss"

As Jeffrey pointed out, you shouldn't be removing these from old SoCs.
In "drivers/gpu/drm/msm/dsi/dsi_cfg.c" you can clearly see them used.
Maybe it's time for you to do the yaml conversion and handle this
correctly per-SoC.

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

Re: [PATCH] drm/msm/a6xx: Remove unneeded GBIF unhalt

[Rob Clark]

+jstultz

On Tue, Feb 4, 2020 at 9:42 AM Jordan Crouse  wrote:
>
> Commit e812744c5f95 ("drm: msm: a6xx: Add support for A618") added a
> universal GBIF un-halt into a6xx_start(). This can cause problems for
> a630 targets which do not use GBIF and might have access protection
> enabled on the region now occupied by the GBIF registers.
>
> But it turns out that we didn't need to unhalt the GBIF in this path
> since the stop function already takes care of that after executing a flush
> but before turning off the headswitch. We should be confident that the
> GBIF is open for business when we restart the hardware.
>
> Signed-off-by: Jordan Crouse 
> ---
>
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 
>  1 file changed, 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index daf0780..e51c723 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -378,18 +378,6 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
> struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> int ret;
>
> -   /*
> -* During a previous slumber, GBIF halt is asserted to ensure
> -* no further transaction can go through GPU before GPU
> -* headswitch is turned off.
> -*
> -* This halt is deasserted once headswitch goes off but
> -* incase headswitch doesn't goes off clear GBIF halt
> -* here to ensure GPU wake-up doesn't fail because of
> -* halted GPU transactions.
> -*/
> -   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0x0);
> -
> /* Make sure the GMU keeps the GPU on while we set it up */
> a6xx_gmu_set_oob(_gpu->gmu, GMU_OOB_GPU_SET);
>
> --
> 2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm/a6xx: Remove unneeded GBIF unhalt

[Jordan Crouse]

Commit e812744c5f95 ("drm: msm: a6xx: Add support for A618") added a
universal GBIF un-halt into a6xx_start(). This can cause problems for
a630 targets which do not use GBIF and might have access protection
enabled on the region now occupied by the GBIF registers.

But it turns out that we didn't need to unhalt the GBIF in this path
since the stop function already takes care of that after executing a flush
but before turning off the headswitch. We should be confident that the
GBIF is open for business when we restart the hardware.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index daf0780..e51c723 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -378,18 +378,6 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
int ret;
 
-   /*
-* During a previous slumber, GBIF halt is asserted to ensure
-* no further transaction can go through GPU before GPU
-* headswitch is turned off.
-*
-* This halt is deasserted once headswitch goes off but
-* incase headswitch doesn't goes off clear GBIF halt
-* here to ensure GPU wake-up doesn't fail because of
-* halted GPU transactions.
-*/
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0x0);
-
/* Make sure the GMU keeps the GPU on while we set it up */
a6xx_gmu_set_oob(_gpu->gmu, GMU_OOB_GPU_SET);
 
-- 
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm/dp_mst: Fix W=1 warnings

[Lyude Paul]

Mostly looks good, some comments below:

On Fri, 2020-01-31 at 11:01 +0100, Benjamin Gaignard wrote:
> Fix the warnings that show up with W=1.
> They are all about unused but set variables.
> If functions returns are not used anymore make them void.
> 
> Signed-off-by: Benjamin Gaignard 
> ---
> version 5:
> - fix indentation
>   
> version 4:
> - do not touch crc4 unused variable in this patch
> CC: ly...@redhat.com
> CC: airl...@linux.ie
> CC: jani.nik...@linux.intel.com
> 
>  drivers/gpu/drm/drm_dp_mst_topology.c | 92 +++-
> ---
>  1 file changed, 40 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 4104f15f4594..822d2f177f90 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1034,7 +1034,8 @@ static bool drm_dp_sideband_parse_req(struct
> drm_dp_sideband_msg_rx *raw,
>   }
>  }
>  
> -static int build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8
> port_num, u32 offset, u8 num_bytes, u8 *bytes)
> +static void build_dpcd_write(struct drm_dp_sideband_msg_tx *msg,
> +  u8 port_num, u32 offset, u8 num_bytes, u8 *bytes)
>  {
>   struct drm_dp_sideband_msg_req_body req;
>  
> @@ -1044,17 +1045,14 @@ static int build_dpcd_write(struct
> drm_dp_sideband_msg_tx *msg, u8 port_num, u32
>   req.u.dpcd_write.num_bytes = num_bytes;
>   req.u.dpcd_write.bytes = bytes;
>   drm_dp_encode_sideband_req(, msg);
> -
> - return 0;
>  }
>  
> -static int build_link_address(struct drm_dp_sideband_msg_tx *msg)
> +static void build_link_address(struct drm_dp_sideband_msg_tx *msg)
>  {
>   struct drm_dp_sideband_msg_req_body req;
>  
>   req.req_type = DP_LINK_ADDRESS;
>   drm_dp_encode_sideband_req(, msg);
> - return 0;
>  }
>  
>  static int build_clear_payload_id_table(struct drm_dp_sideband_msg_tx *msg)
> @@ -1066,7 +1064,8 @@ static int build_clear_payload_id_table(struct
> drm_dp_sideband_msg_tx *msg)
>   return 0;
>  }
>  
> -static int build_enum_path_resources(struct drm_dp_sideband_msg_tx *msg,
> int port_num)
> +static int build_enum_path_resources(struct drm_dp_sideband_msg_tx *msg,
> +  int port_num)
>  {
>   struct drm_dp_sideband_msg_req_body req;
>  
> @@ -1077,10 +1076,11 @@ static int build_enum_path_resources(struct
> drm_dp_sideband_msg_tx *msg, int por
>   return 0;
>  }
>  
> -static int build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int
> port_num,
> -   u8 vcpi, uint16_t pbn,
> -   u8 number_sdp_streams,
> -   u8 *sdp_stream_sink)
> +static void build_allocate_payload(struct drm_dp_sideband_msg_tx *msg,
> +int port_num,
> +u8 vcpi, uint16_t pbn,
> +u8 number_sdp_streams,
> +u8 *sdp_stream_sink)
>  {
>   struct drm_dp_sideband_msg_req_body req;
>   memset(, 0, sizeof(req));
> @@ -1093,11 +1093,10 @@ static int build_allocate_payload(struct
> drm_dp_sideband_msg_tx *msg, int port_n
>  number_sdp_streams);
>   drm_dp_encode_sideband_req(, msg);
>   msg->path_msg = true;
> - return 0;
>  }
>  
> -static int build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
> -   int port_num, bool power_up)
> +static void build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
> +int port_num, bool power_up)
>  {
>   struct drm_dp_sideband_msg_req_body req;
>  
> @@ -1109,7 +1108,6 @@ static int build_power_updown_phy(struct
> drm_dp_sideband_msg_tx *msg,
>   req.u.port_num.port_number = port_num;
>   drm_dp_encode_sideband_req(, msg);
>   msg->path_msg = true;
> - return 0;
>  }
>  
>  static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr
> *mgr,
> @@ -2054,25 +2052,20 @@ ssize_t drm_dp_mst_dpcd_write(struct drm_dp_aux
> *aux,
>  
>  static void drm_dp_check_mstb_guid(struct drm_dp_mst_branch *mstb, u8
> *guid)
>  {
> - int ret;
> -
>   memcpy(mstb->guid, guid, 16);
>  
>   if (!drm_dp_validate_guid(mstb->mgr, mstb->guid)) {
>   if (mstb->port_parent) {
> - ret = drm_dp_send_dpcd_write(
> - mstb->mgr,
> - mstb->port_parent,
> - DP_GUID,
> - 16,
> - mstb->guid);
> + drm_dp_send_dpcd_write(mstb->mgr,
> +mstb->port_parent,
> +DP_GUID,
> +16,
> +mstb->guid);
>   } 

Re: [PATCH v1] drm: shmobile: Platform data shan't include kernel.h

[Geert Uytterhoeven]

Hi Andy,

On Tue, Feb 4, 2020 at 5:20 PM Andy Shevchenko
 wrote:
> Replace with appropriate types.h.

Thanks for your patch!

I have only one very short question: why?

Gr{oetje,eeting}s,

Geert

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

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

Re: [Freedreno] [PATCH v2 2/3] drm: msm: a6xx: Add support for A618

[Jordan Crouse]

On Mon, Feb 03, 2020 at 04:40:40PM -0800, Rob Clark wrote:
> On Mon, Feb 3, 2020 at 4:21 PM John Stultz  wrote:
> >
> > On Wed, Jan 22, 2020 at 11:19 PM Sharat Masetty  
> > wrote:
> > >
> > > This patch adds support for enabling Graphics Bus Interface(GBIF)
> > > used in multiple A6xx series chipets. Also makes changes to the
> > > PDC/RSC sequencing specifically required for A618. This is needed
> > > for proper interfacing with RPMH.
> > >
> > > Signed-off-by: Sharat Masetty 
> > > ---
> > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
> > > b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > index dc8ec2c..2ac9a51 100644
> > > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > @@ -378,6 +378,18 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
> > > struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> > > int ret;
> > >
> > > +   /*
> > > +* During a previous slumber, GBIF halt is asserted to ensure
> > > +* no further transaction can go through GPU before GPU
> > > +* headswitch is turned off.
> > > +*
> > > +* This halt is deasserted once headswitch goes off but
> > > +* incase headswitch doesn't goes off clear GBIF halt
> > > +* here to ensure GPU wake-up doesn't fail because of
> > > +* halted GPU transactions.
> > > +*/
> > > +   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0x0);
> > > +
> > > /* Make sure the GMU keeps the GPU on while we set it up */
> > > a6xx_gmu_set_oob(_gpu->gmu, GMU_OOB_GPU_SET);
> > >
> >
> > So I already brought this up on #freedreno but figured I'd follow up
> > on the list.
> >
> > With linus/master, I'm seeing hard crashes (into usb crash mode) with
> > the db845c, which I isolated down to this patch, and then to the chunk
> > above.
> 
> (repeating my speculation from #freedreno for benefit of those not on IRC)
> 
> I'm suspecting, that like the registers to take the GPU out of secure
> mode, this register is being blocked on LA devices (like db845c),
> which is why we didn't see this on cheza.
> 
> Maybe we can make this write conditional on whether we have a zap shader?

Sorry, I was WFH yesterday and didn't have IRC on.

The 845 doesn't have GBIF (it still uses VBIF) and on a AC enabled target large
chunks of unused register space would be blocked by default so Rob's hypothesis
is correct. Since the 845 is the only a6xx target that still has a VBIF a
!adreno_is_a630() check would do here, but I'm not 100% convinced we need this
code at all. We explicitly clear the GBIF halt in the stop function before the
headswitch is turned off so I think this is mostly unneeded paranoia.

I need to get a tree with the 618 code in it and I'll try to get a fix out
shortly.

Jordan

> > Dropping the gpu_write line above gets things booting again for me.
> >
> > Let me know if there are any follow on patches I can help validate.
> >
> > thanks
> > -john
> > ___
> > Freedreno mailing list
> > freedr...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/freedreno
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] drm/fbdev-helper: don't force restores

[Daniel Vetter]

Instead check for master status, in case we've raced.

This is the last exception to the general rule that we restore fbcon
only when there's no master active. Compositors are supposed to drop
their master status before they switch to a different console back to
text mode (or just switch to text mode directly, without a vt switch).

This is known to break some subtests of kms_fbcon_fbt in igt, but they're
just wrong - it does a graphics/text mode switch for the vt without
updating the master status.

Also add a comment to the drm_client->restore hook that this is expected
going forward from all clients (there's currently just one).

v2: Also drop the force in pan_display

v3: Restore the _force to pan_display, this actually means _locked in that
path. Spotted by Noralf.

Cc: Noralf Trønnes 
Reviewed-by: Noralf Trønnes 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 12 +---
 include/drm/drm_client.h|  5 +
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4c7cbce7bae7..672934e0eeed 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -250,17 +250,7 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
return 0;
 
mutex_lock(_helper->lock);
-   /*
-* TODO:
-* We should bail out here if there is a master by dropping _force.
-* Currently these igt tests fail if we do that:
-* - kms_fbcon_fbt@psr
-* - kms_fbcon_fbt@psr-suspend
-*
-* So first these tests need to be fixed so they drop master or don't
-* have an fd open.
-*/
-   ret = drm_client_modeset_commit_force(_helper->client);
+   ret = drm_client_modeset_commit(_helper->client);
 
do_delayed = fb_helper->delayed_hotplug;
if (do_delayed)
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
index 5cf2c5dd8b1e..d01d311023ac 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -44,6 +44,11 @@ struct drm_client_funcs {
 * returns zero gets the privilege to restore and no more clients are
 * called. This callback is not called after @unregister has been 
called.
 *
+* Note that the core does not guarantee exclusion against concurrent
+* drm_open(). Clients need to ensure this themselves, for example by
+* using drm_master_internal_acquire() and
+* drm_master_internal_release().
+*
 * This callback is optional.
 */
int (*restore)(struct drm_client_dev *client);
-- 
2.24.1

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

[PATCH 3/5] drm/client: Rename _force to _locked

[Daniel Vetter]

Plus extend the kerneldoc a bit to explain how this should be used.
With the previous patch to drop the force restore the main user of
this function is not emphasis on the "I hold the internal master lock
already" aspect, so rename the function to match.

Suggested by Noralf.

Cc: Noralf Trønnes 
Reviewed-by: Noralf Trønnes 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_client_modeset.c | 12 +++-
 drivers/gpu/drm/drm_fb_helper.c  |  4 ++--
 include/drm/drm_client.h |  2 +-
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 6d4a29e99ae2..841794e19eb6 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -1094,15 +1094,17 @@ static int drm_client_modeset_commit_legacy(struct 
drm_client_dev *client)
 }
 
 /**
- * drm_client_modeset_commit_force() - Force commit CRTC configuration
+ * drm_client_modeset_commit_locked() - Force commit CRTC configuration
  * @client: DRM client
  *
- * Commit modeset configuration to crtcs without checking if there is a DRM 
master.
+ * Commit modeset configuration to crtcs without checking if there is a DRM
+ * master. The assumption is that the caller already holds an internal DRM
+ * master reference acquired with drm_master_internal_acquire().
  *
  * Returns:
  * Zero on success or negative error code on failure.
  */
-int drm_client_modeset_commit_force(struct drm_client_dev *client)
+int drm_client_modeset_commit_locked(struct drm_client_dev *client)
 {
struct drm_device *dev = client->dev;
int ret;
@@ -1116,7 +1118,7 @@ int drm_client_modeset_commit_force(struct drm_client_dev 
*client)
 
return ret;
 }
-EXPORT_SYMBOL(drm_client_modeset_commit_force);
+EXPORT_SYMBOL(drm_client_modeset_commit_locked);
 
 /**
  * drm_client_modeset_commit() - Commit CRTC configuration
@@ -1135,7 +1137,7 @@ int drm_client_modeset_commit(struct drm_client_dev 
*client)
if (!drm_master_internal_acquire(dev))
return -EBUSY;
 
-   ret = drm_client_modeset_commit_force(client);
+   ret = drm_client_modeset_commit_locked(client);
 
drm_master_internal_release(dev);
 
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 672934e0eeed..490a99de6ec1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -284,7 +284,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
continue;
 
mutex_lock(>lock);
-   ret = drm_client_modeset_commit_force(>client);
+   ret = drm_client_modeset_commit_locked(>client);
if (ret)
error = true;
mutex_unlock(>lock);
@@ -1347,7 +1347,7 @@ static int pan_display_atomic(struct fb_var_screeninfo 
*var,
 
pan_set(fb_helper, var->xoffset, var->yoffset);
 
-   ret = drm_client_modeset_commit_force(_helper->client);
+   ret = drm_client_modeset_commit_locked(_helper->client);
if (!ret) {
info->var.xoffset = var->xoffset;
info->var.yoffset = var->yoffset;
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
index d01d311023ac..3ed5dee899fd 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -161,7 +161,7 @@ int drm_client_modeset_create(struct drm_client_dev 
*client);
 void drm_client_modeset_free(struct drm_client_dev *client);
 int drm_client_modeset_probe(struct drm_client_dev *client, unsigned int 
width, unsigned int height);
 bool drm_client_rotation(struct drm_mode_set *modeset, unsigned int *rotation);
-int drm_client_modeset_commit_force(struct drm_client_dev *client);
+int drm_client_modeset_commit_locked(struct drm_client_dev *client);
 int drm_client_modeset_commit(struct drm_client_dev *client);
 int drm_client_modeset_dpms(struct drm_client_dev *client, int mode);
 
-- 
2.24.1

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

[PATCH 4/5] drm: Push drm_global_mutex locking in drm_open

[Daniel Vetter]

We want to only take the BKL on crap drivers, but to know whether
we have a crap driver we first need to look it up. Split this shuffle
out from the main BKL-disabling patch, for more clarity. Historical
aside: When the kernel-wide BKL was removed, it was replaced by
drm_global_mutex within the scope of the drm subsystem hence why these
two things are (almost) interchangeable as concepts here.

Since the minors are refcounted drm_minor_acquire is purely internal
and this does not have a driver visible effect.

v2: Push the locking even further into drm_open(), suggested by Chris.
This gives us more symmetry with drm_release(), and maybe a futuer
avenue where we make drm_global_mutex locking (partially) opt-in like
with drm_release_noglobal().

v3:
- Actually push this stuff correctly, don't unlock twice (Chris)
- Fix typo on commit message, plus explain why BKL = drm_global_mutex
  (Sam)

Cc: Sam Ravnborg 
Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_drv.c  | 14 +-
 drivers/gpu/drm/drm_file.c |  6 ++
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 8deff75b484c..05bdf0b9d2b3 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -1085,17 +1085,14 @@ static int drm_stub_open(struct inode *inode, struct 
file *filp)
 
DRM_DEBUG("\n");
 
-   mutex_lock(_global_mutex);
minor = drm_minor_acquire(iminor(inode));
-   if (IS_ERR(minor)) {
-   err = PTR_ERR(minor);
-   goto out_unlock;
-   }
+   if (IS_ERR(minor))
+   return PTR_ERR(minor);
 
new_fops = fops_get(minor->dev->driver->fops);
if (!new_fops) {
err = -ENODEV;
-   goto out_release;
+   goto out;
}
 
replace_fops(filp, new_fops);
@@ -1104,10 +1101,9 @@ static int drm_stub_open(struct inode *inode, struct 
file *filp)
else
err = 0;
 
-out_release:
+out:
drm_minor_release(minor);
-out_unlock:
-   mutex_unlock(_global_mutex);
+
return err;
 }
 
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 1075b3a8b5b1..80d556402ab4 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -378,6 +378,8 @@ int drm_open(struct inode *inode, struct file *filp)
if (IS_ERR(minor))
return PTR_ERR(minor);
 
+   mutex_lock(_global_mutex);
+
dev = minor->dev;
if (!atomic_fetch_inc(>open_count))
need_setup = 1;
@@ -395,10 +397,14 @@ int drm_open(struct inode *inode, struct file *filp)
goto err_undo;
}
}
+
+   mutex_unlock(_global_mutex);
+
return 0;
 
 err_undo:
atomic_dec(>open_count);
+   mutex_unlock(_global_mutex);
drm_minor_release(minor);
return retcode;
 }
-- 
2.24.1

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

[PATCH 1/5] drm: Complain if drivers still use the ->load callback

[Daniel Vetter]

Kinda time to get this sorted. The locking around this really is not
nice.

Thomas mentioned in his review that the only drivers left unconverted
are radeon and amdgpu.

Cc: Harry Wentland 
Cc: Alex Deucher 
Reviewed-by: Chris Wilson 
Reviewed-by: Thomas Zimmermann 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_drv.c | 6 ++
 include/drm/drm_drv.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7c18a980cd4b..8deff75b484c 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -948,6 +948,12 @@ int drm_dev_register(struct drm_device *dev, unsigned long 
flags)
 
mutex_lock(_global_mutex);
 
+   if (dev->driver->load) {
+   if (!drm_core_check_feature(dev, DRIVER_LEGACY))
+   DRM_INFO("drm driver %s is using deprecated ->load 
callback\n",
+dev->driver->name);
+   }
+
ret = drm_minor_register(dev, DRM_MINOR_RENDER);
if (ret)
goto err_minors;
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 77685ed7aa65..77bc63de0a91 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -173,6 +173,9 @@ struct drm_driver {
 *
 * This is deprecated, do not use!
 *
+* FIXME: A few non-DRIVER_LEGACY drivers still use this, and should be
+* converted.
+*
 * Returns:
 *
 * Zero on success, non-zero value on failure.
-- 
2.24.1

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

[PATCH 5/5] drm: Nerf drm_global_mutex BKL for good drivers

[Daniel Vetter]

This catches the majority of drivers (unfortunately not if we take
users into account, because all the big drivers have at least a
lastclose hook).

With the prep patches out of the way all drm state is fully protected
and either prevents or can deal with the races from dropping the BKL
around open/close. The only thing left to audit are the various driver
hooks - by keeping the BKL around if any of them are set we have a
very simple cop-out!

Note that one of the biggest prep pieces to get here was making
dev->open_count atomic, which was done in

commit 7e13ad896484a0165a68197a2e64091ea28c9602
Author: Chris Wilson 
Date:   Fri Jan 24 13:01:07 2020 +

drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count

v2:
- Rebase and fix locking in drm_open() (Chris)
- Indentation fix in drm_release
- Typo fix in the commit message (Sam)

Cc: Chris Wilson 
Cc: Sam Ravnborg 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_drv.c  |  6 +++--
 drivers/gpu/drm/drm_file.c | 48 +-
 drivers/gpu/drm/drm_internal.h |  1 +
 3 files changed, 47 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 05bdf0b9d2b3..9fcd6ab3c154 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -946,7 +946,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long 
flags)
struct drm_driver *driver = dev->driver;
int ret;
 
-   mutex_lock(_global_mutex);
+   if (drm_dev_needs_global_mutex(dev))
+   mutex_lock(_global_mutex);
 
if (dev->driver->load) {
if (!drm_core_check_feature(dev, DRIVER_LEGACY))
@@ -992,7 +993,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long 
flags)
drm_minor_unregister(dev, DRM_MINOR_PRIMARY);
drm_minor_unregister(dev, DRM_MINOR_RENDER);
 out_unlock:
-   mutex_unlock(_global_mutex);
+   if (drm_dev_needs_global_mutex(dev))
+   mutex_unlock(_global_mutex);
return ret;
 }
 EXPORT_SYMBOL(drm_dev_register);
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 80d556402ab4..c4c704e01961 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -51,6 +51,37 @@
 /* from BKL pushdown */
 DEFINE_MUTEX(drm_global_mutex);
 
+bool drm_dev_needs_global_mutex(struct drm_device *dev)
+{
+   /*
+* Legacy drivers rely on all kinds of BKL locking semantics, don't
+* bother. They also still need BKL locking for their ioctls, so better
+* safe than sorry.
+*/
+   if (drm_core_check_feature(dev, DRIVER_LEGACY))
+   return true;
+
+   /*
+* The deprecated ->load callback must be called after the driver is
+* already registered. This means such drivers rely on the BKL to make
+* sure an open can't proceed until the driver is actually fully set up.
+* Similar hilarity holds for the unload callback.
+*/
+   if (dev->driver->load || dev->driver->unload)
+   return true;
+
+   /*
+* Drivers with the lastclose callback assume that it's synchronized
+* against concurrent opens, which again needs the BKL. The proper fix
+* is to use the drm_client infrastructure with proper locking for each
+* client.
+*/
+   if (dev->driver->lastclose)
+   return true;
+
+   return false;
+}
+
 /**
  * DOC: file operations
  *
@@ -378,9 +409,10 @@ int drm_open(struct inode *inode, struct file *filp)
if (IS_ERR(minor))
return PTR_ERR(minor);
 
-   mutex_lock(_global_mutex);
-
dev = minor->dev;
+   if (drm_dev_needs_global_mutex(dev))
+   mutex_lock(_global_mutex);
+
if (!atomic_fetch_inc(>open_count))
need_setup = 1;
 
@@ -398,13 +430,15 @@ int drm_open(struct inode *inode, struct file *filp)
}
}
 
-   mutex_unlock(_global_mutex);
+   if (drm_dev_needs_global_mutex(dev))
+   mutex_unlock(_global_mutex);
 
return 0;
 
 err_undo:
atomic_dec(>open_count);
-   mutex_unlock(_global_mutex);
+   if (drm_dev_needs_global_mutex(dev))
+   mutex_unlock(_global_mutex);
drm_minor_release(minor);
return retcode;
 }
@@ -444,7 +478,8 @@ int drm_release(struct inode *inode, struct file *filp)
struct drm_minor *minor = file_priv->minor;
struct drm_device *dev = minor->dev;
 
-   mutex_lock(_global_mutex);
+   if (drm_dev_needs_global_mutex(dev))
+   mutex_lock(_global_mutex);
 
DRM_DEBUG("open_count = %d\n", atomic_read(>open_count));
 
@@ -453,7 +488,8 @@ int drm_release(struct inode *inode, struct file *filp)
if (atomic_dec_and_test(>open_count))
drm_lastclose(dev);
 
-   mutex_unlock(_global_mutex);
+   if (drm_dev_needs_global_mutex(dev))
+   

[PATCH 0/5] disable drm_global_mutex for most drivers, take 2

[Daniel Vetter]

CI didn't like my test-with tag :-/

Test-with: 20200128112549.172135-1-daniel.vet...@ffwll.ch

Daniel Vetter (5):
  drm: Complain if drivers still use the ->load callback
  drm/fbdev-helper: don't force restores
  drm/client: Rename _force to _locked
  drm: Push drm_global_mutex locking in drm_open
  drm: Nerf drm_global_mutex BKL for good drivers

 drivers/gpu/drm/drm_client_modeset.c | 12 +---
 drivers/gpu/drm/drm_drv.c| 26 +---
 drivers/gpu/drm/drm_fb_helper.c  | 16 ++
 drivers/gpu/drm/drm_file.c   | 46 ++--
 drivers/gpu/drm/drm_internal.h   |  1 +
 include/drm/drm_client.h |  7 -
 include/drm/drm_drv.h|  3 ++
 7 files changed, 79 insertions(+), 32 deletions(-)

-- 
2.24.1

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

RE: [Intel-gfx] [PATCH 6/8] drm/edid: Add a FIXME about DispID CEA data block revision

[Shankar, Uma]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, February 4, 2020 7:02 PM
> To: Shankar, Uma 
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; Andres
> Rodriguez 
> Subject: Re: [Intel-gfx] [PATCH 6/8] drm/edid: Add a FIXME about DispID CEA 
> data
> block revision
> 
> On Mon, Feb 03, 2020 at 08:15:51PM +, Shankar, Uma wrote:
> >
> >
> > > -Original Message-
> > > From: Intel-gfx  On Behalf
> > > Of Ville Syrjala
> > > Sent: Saturday, January 25, 2020 1:32 AM
> > > To: dri-devel@lists.freedesktop.org
> > > Cc: intel-...@lists.freedesktop.org; Andres Rodriguez
> > > 
> > > Subject: [Intel-gfx] [PATCH 6/8] drm/edid: Add a FIXME about DispID
> > > CEA data block revision
> > >
> > > From: Ville Syrjälä 
> > >
> > > I don't understand what the DispID CEA data block revision means.
> > > The spec doesn't say. I guess some DispID must have a value of >= 3
> > > in there or else we generally wouldn't even parse the CEA data
> > > blocks. Or does all this code actually not do anything?
> >
> > This signifies the CTA extension revision (byte 1 of the block). As
> > per the spec, seems like Version 1 is legacy and 2 is deprecated. So 
> > version >=3 is
> checked here.
> > Refer section 7.3 of CTA-861-G
> 
> The confusion is about the revision field in the DispID CTA block, not in the 
> CTA
> extension block.

Oh ok, got the ambiguity here. Not sure if we actually get >3 here as value for 
the block revision,
totally unclear from spec, default being 0. Good to have this comment till we 
get some clarity on
its significance. Thanks for the clarification.

Reviewed-by: Uma Shankar 

> >
> > > Cc: Andres Rodriguez 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/drm_edid.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index
> > > 0369a54e3d32..fd9b724067a7 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3977,6 +3977,13 @@ cea_db_tag(const u8 *db)  static int
> > > cea_revision(const
> > > u8 *cea)  {
> > > + /*
> > > +  * FIXME is this correct for the DispID variant?
> > > +  * The DispID spec doesn't really specify whether
> > > +  * this is the revision of the CEA extension or
> > > +  * the DispID CEA data block. And the only value
> > > +  * given as an example is 0.
> > > +  */
> > >   return cea[1];
> > >  }
> > >
> > > --
> > > 2.24.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > intel-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_priv

[Boris Brezillon]

On Tue,  4 Feb 2020 15:35:03 +0100
Boris Brezillon  wrote:

> Jobs can be in-flight when the file descriptor is closed (either because
> the process did not terminate properly, or because it didn't wait for
> all GPU jobs to be finished), and apparently panfrost_job_close() does
> not cancel already running jobs. Let's refcount the MMU context object
> so it's lifetime is no longer bound to the FD lifetime and running jobs

 ^its

> can finish properly without generating spurious page faults.
> 
> Reported-by: Icecream95 
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc: 
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/gpu/drm/panfrost/panfrost_device.h |   8 +-
>  drivers/gpu/drm/panfrost/panfrost_drv.c|  50 ++-
>  drivers/gpu/drm/panfrost/panfrost_gem.c|  20 ++-
>  drivers/gpu/drm/panfrost/panfrost_job.c|   4 +-
>  drivers/gpu/drm/panfrost/panfrost_mmu.c| 158 ++---
>  drivers/gpu/drm/panfrost/panfrost_mmu.h|   5 +-
>  6 files changed, 135 insertions(+), 110 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h 
> b/drivers/gpu/drm/panfrost/panfrost_device.h
> index 06713811b92c..3f19288e8375 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> @@ -94,8 +94,12 @@ struct panfrost_device {
>  };
>  
>  struct panfrost_mmu {
> + struct panfrost_device *pfdev;
> + struct kref refcount;
>   struct io_pgtable_cfg pgtbl_cfg;
>   struct io_pgtable_ops *pgtbl_ops;
> + struct drm_mm mm;
> + spinlock_t mm_lock;
>   int as;
>   atomic_t as_count;
>   struct list_head list;
> @@ -106,9 +110,7 @@ struct panfrost_file_priv {
>  
>   struct drm_sched_entity sched_entity[NUM_JOB_SLOTS];
>  
> - struct panfrost_mmu mmu;
> - struct drm_mm mm;
> - spinlock_t mm_lock;
> + struct panfrost_mmu *mmu;
>  };
>  
>  static inline struct panfrost_device *to_panfrost_device(struct drm_device 
> *ddev)
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 273d67e251c2..41e574742a3c 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -418,7 +418,7 @@ static int panfrost_ioctl_madvise(struct drm_device *dev, 
> void *data,
>* anyway, so let's not bother.
>*/
>   if (!list_is_singular(>mappings.list) ||
> - WARN_ON_ONCE(first->mmu != >mmu)) {
> + WARN_ON_ONCE(first->mmu != priv->mmu)) {
>   ret = -EINVAL;
>   goto out_unlock_mappings;
>   }
> @@ -450,32 +450,6 @@ int panfrost_unstable_ioctl_check(void)
>   return 0;
>  }
>  
> -#define PFN_4G   (SZ_4G >> PAGE_SHIFT)
> -#define PFN_4G_MASK  (PFN_4G - 1)
> -#define PFN_16M  (SZ_16M >> PAGE_SHIFT)
> -
> -static void panfrost_drm_mm_color_adjust(const struct drm_mm_node *node,
> -  unsigned long color,
> -  u64 *start, u64 *end)
> -{
> - /* Executable buffers can't start or end on a 4GB boundary */
> - if (!(color & PANFROST_BO_NOEXEC)) {
> - u64 next_seg;
> -
> - if ((*start & PFN_4G_MASK) == 0)
> - (*start)++;
> -
> - if ((*end & PFN_4G_MASK) == 0)
> - (*end)--;
> -
> - next_seg = ALIGN(*start, PFN_4G);
> - if (next_seg - *start <= PFN_16M)
> - *start = next_seg + 1;
> -
> - *end = min(*end, ALIGN(*start, PFN_4G) - 1);
> - }
> -}
> -
>  static int
>  panfrost_open(struct drm_device *dev, struct drm_file *file)
>  {
> @@ -490,15 +464,11 @@ panfrost_open(struct drm_device *dev, struct drm_file 
> *file)
>   panfrost_priv->pfdev = pfdev;
>   file->driver_priv = panfrost_priv;
>  
> - spin_lock_init(_priv->mm_lock);
> -
> - /* 4G enough for now. can be 48-bit */
> - drm_mm_init(_priv->mm, SZ_32M >> PAGE_SHIFT, (SZ_4G - SZ_32M) 
> >> PAGE_SHIFT);
> - panfrost_priv->mm.color_adjust = panfrost_drm_mm_color_adjust;
> -
> - ret = panfrost_mmu_pgtable_alloc(panfrost_priv);
> - if (ret)
> - goto err_pgtable;
> + panfrost_priv->mmu = panfrost_mmu_ctx_create(pfdev);
> + if (IS_ERR(panfrost_priv->mmu)) {
> + ret = PTR_ERR(panfrost_priv->mmu);
> + goto err_free;
> + }
>  
>   ret = panfrost_job_open(panfrost_priv);
>   if (ret)
> @@ -507,9 +477,8 @@ panfrost_open(struct drm_device *dev, struct drm_file 
> *file)
>   return 0;
>  
>  err_job:
> - panfrost_mmu_pgtable_free(panfrost_priv);
> -err_pgtable:
> - drm_mm_takedown(_priv->mm);
> + panfrost_mmu_ctx_put(panfrost_priv->mmu);
> +err_free:
>   kfree(panfrost_priv);
>   return ret;
>  }
> @@ -522,8 +491,7 @@ panfrost_postclose(struct drm_device *dev, struct 
> 

Re: [PATCH] drm/edid: fix building error

[Ville Syrjälä]

On Mon, Feb 03, 2020 at 10:31:13PM +0100, Mauro Rossi wrote:
> Fixes the following building error:
> 
> CC [M]  drivers/gpu/drm/drm_edid.o
> ~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c: In function 
> 'cea_mode_alternate_timings':
> ~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c:3275:2: error: call to 
> '__compiletime_assert_3282'
> declared with attribute error: BUILD_BUG_ON failed: 
> cea_mode_for_vic(8)->vtotal != 262 || cea_mode_for_vic(9)->vtotal != 262 || 
> cea_mode_for_vic(12)->vtotal != 262 || cea_mode_for_vic(13)->vtotal != 262 || 
> cea_mode_for_vic(23)->vtotal != 312 || cea_mode_for_vic(24)->vtotal != 312 || 
> cea_mode_for_vic(27)->vtotal != 312 || cea_mode_for_vic(28)->vtotal != 312
> make[4]: *** [~/pie-x86_kernel/kernel/scripts/Makefile.build:265: 
> drivers/gpu/drm/drm_edid.o] Error 1
> 
> Fixes: 7befe62 ("drm/edid: Abstract away cea_edid_modes[]")
> Signed-off-by: Mauro Rossi 
> ---
>  drivers/gpu/drm/drm_edid.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6c9f84..805fb004c8eb 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3211,7 +3211,7 @@ static u8 *drm_find_cea_extension(const struct edid 
> *edid)
>   return cea;
>  }
>  
> -static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
> +static __always_inline const struct drm_display_mode *cea_mode_for_vic(u8 
> vic)

Thanks for the fix. I've had another few reports of this fail on ia64
at least. Hoping to get an answer whether this fixes that one as well.
If not we need to do something else.

>  {
>   BUILD_BUG_ON(1 + ARRAY_SIZE(edid_cea_modes_1) - 1 != 127);
>   BUILD_BUG_ON(193 + ARRAY_SIZE(edid_cea_modes_193) - 1 != 219);
> -- 
> 2.20.1

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_priv

[Boris Brezillon]

Jobs can be in-flight when the file descriptor is closed (either because
the process did not terminate properly, or because it didn't wait for
all GPU jobs to be finished), and apparently panfrost_job_close() does
not cancel already running jobs. Let's refcount the MMU context object
so it's lifetime is no longer bound to the FD lifetime and running jobs
can finish properly without generating spurious page faults.

Reported-by: Icecream95 
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Cc: 
Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panfrost/panfrost_device.h |   8 +-
 drivers/gpu/drm/panfrost/panfrost_drv.c|  50 ++-
 drivers/gpu/drm/panfrost/panfrost_gem.c|  20 ++-
 drivers/gpu/drm/panfrost/panfrost_job.c|   4 +-
 drivers/gpu/drm/panfrost/panfrost_mmu.c| 158 ++---
 drivers/gpu/drm/panfrost/panfrost_mmu.h|   5 +-
 6 files changed, 135 insertions(+), 110 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h 
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 06713811b92c..3f19288e8375 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -94,8 +94,12 @@ struct panfrost_device {
 };
 
 struct panfrost_mmu {
+   struct panfrost_device *pfdev;
+   struct kref refcount;
struct io_pgtable_cfg pgtbl_cfg;
struct io_pgtable_ops *pgtbl_ops;
+   struct drm_mm mm;
+   spinlock_t mm_lock;
int as;
atomic_t as_count;
struct list_head list;
@@ -106,9 +110,7 @@ struct panfrost_file_priv {
 
struct drm_sched_entity sched_entity[NUM_JOB_SLOTS];
 
-   struct panfrost_mmu mmu;
-   struct drm_mm mm;
-   spinlock_t mm_lock;
+   struct panfrost_mmu *mmu;
 };
 
 static inline struct panfrost_device *to_panfrost_device(struct drm_device 
*ddev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 273d67e251c2..41e574742a3c 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -418,7 +418,7 @@ static int panfrost_ioctl_madvise(struct drm_device *dev, 
void *data,
 * anyway, so let's not bother.
 */
if (!list_is_singular(>mappings.list) ||
-   WARN_ON_ONCE(first->mmu != >mmu)) {
+   WARN_ON_ONCE(first->mmu != priv->mmu)) {
ret = -EINVAL;
goto out_unlock_mappings;
}
@@ -450,32 +450,6 @@ int panfrost_unstable_ioctl_check(void)
return 0;
 }
 
-#define PFN_4G (SZ_4G >> PAGE_SHIFT)
-#define PFN_4G_MASK(PFN_4G - 1)
-#define PFN_16M(SZ_16M >> PAGE_SHIFT)
-
-static void panfrost_drm_mm_color_adjust(const struct drm_mm_node *node,
-unsigned long color,
-u64 *start, u64 *end)
-{
-   /* Executable buffers can't start or end on a 4GB boundary */
-   if (!(color & PANFROST_BO_NOEXEC)) {
-   u64 next_seg;
-
-   if ((*start & PFN_4G_MASK) == 0)
-   (*start)++;
-
-   if ((*end & PFN_4G_MASK) == 0)
-   (*end)--;
-
-   next_seg = ALIGN(*start, PFN_4G);
-   if (next_seg - *start <= PFN_16M)
-   *start = next_seg + 1;
-
-   *end = min(*end, ALIGN(*start, PFN_4G) - 1);
-   }
-}
-
 static int
 panfrost_open(struct drm_device *dev, struct drm_file *file)
 {
@@ -490,15 +464,11 @@ panfrost_open(struct drm_device *dev, struct drm_file 
*file)
panfrost_priv->pfdev = pfdev;
file->driver_priv = panfrost_priv;
 
-   spin_lock_init(_priv->mm_lock);
-
-   /* 4G enough for now. can be 48-bit */
-   drm_mm_init(_priv->mm, SZ_32M >> PAGE_SHIFT, (SZ_4G - SZ_32M) 
>> PAGE_SHIFT);
-   panfrost_priv->mm.color_adjust = panfrost_drm_mm_color_adjust;
-
-   ret = panfrost_mmu_pgtable_alloc(panfrost_priv);
-   if (ret)
-   goto err_pgtable;
+   panfrost_priv->mmu = panfrost_mmu_ctx_create(pfdev);
+   if (IS_ERR(panfrost_priv->mmu)) {
+   ret = PTR_ERR(panfrost_priv->mmu);
+   goto err_free;
+   }
 
ret = panfrost_job_open(panfrost_priv);
if (ret)
@@ -507,9 +477,8 @@ panfrost_open(struct drm_device *dev, struct drm_file *file)
return 0;
 
 err_job:
-   panfrost_mmu_pgtable_free(panfrost_priv);
-err_pgtable:
-   drm_mm_takedown(_priv->mm);
+   panfrost_mmu_ctx_put(panfrost_priv->mmu);
+err_free:
kfree(panfrost_priv);
return ret;
 }
@@ -522,8 +491,7 @@ panfrost_postclose(struct drm_device *dev, struct drm_file 
*file)
panfrost_perfcnt_close(file);
panfrost_job_close(panfrost_priv);
 
-   panfrost_mmu_pgtable_free(panfrost_priv);
-   drm_mm_takedown(_priv->mm);
+   

[PATCH 2/2] drm/panfrost: Propagate panfrost_fence_create() errors to the scheduler

[Boris Brezillon]

->job_run() can return an ERR_PTR() if somethings fails. Let's
propagate the error returned by panfrost_fence_create() instead of
returning NULL.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_job.c
index b0716e49eeca..242147b36d8e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -349,7 +349,7 @@ static struct dma_fence *panfrost_job_run(struct 
drm_sched_job *sched_job)
 
fence = panfrost_fence_create(pfdev, slot);
if (IS_ERR(fence))
-   return NULL;
+   return fence;
 
if (job->done_fence)
dma_fence_put(job->done_fence);
-- 
2.24.1

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

Re: [bug report] drm/ttm: fix re-init of global structures

[Christian König]

Am 04.02.20 um 15:24 schrieb Dan Carpenter:

On Tue, Feb 04, 2020 at 03:03:43PM +0100, Christian König wrote:

Am 04.02.20 um 13:57 schrieb Dan Carpenter:

Hello Christian König,

The patch bd4264112f93: "drm/ttm: fix re-init of global structures"
from Apr 16, 2019, leads to the following static checker warning:

drivers/gpu/drm/ttm/ttm_bo.c:1610 ttm_bo_global_release()
warn: passing freed memory 'glob'

drivers/gpu/drm/ttm/ttm_bo.c
1591  static void ttm_bo_global_kobj_release(struct kobject *kobj)
1592  {
1593  struct ttm_bo_global *glob =
1594  container_of(kobj, struct ttm_bo_global, kobj);
1595
1596  __free_page(glob->dummy_read_page);
1597  }
1598
1599  static void ttm_bo_global_release(void)
1600  {
1601  struct ttm_bo_global *glob = _bo_glob;
1602
1603  mutex_lock(_global_mutex);
1604  if (--ttm_bo_glob_use_count > 0)
1605  goto out;
1606
1607  kobject_del(>kobj);
1608  kobject_put(>kobj);
1609  ttm_mem_global_release(_mem_glob);
1610  memset(glob, 0, sizeof(*glob));
 ^^
Depending on the config kobject_release() might call 
ttm_bo_global_kobj_release()
a few seconds after this memset.  Maybe put the memset into
ttm_bo_global_kobj_release()?

That's not possible. The object might be re-used directly after we drop the
ttm_global_mutex.


Hm...  That sucks.  If we reallocate glob->dummy_read_page before the
ttm_bo_global_kobj_release() gets called then we're toasted.


How can we wait for the ttm_mem_global_release() to have finished?


A bunch of these release functions use a completion.  But you probably
don't want a four second delay before we can re-use the struct.


Actually that should be fine.

I mean the function is usually called on module unload, if that really 
waits for 4 seconds until it calls ttm_bo_global_kobj_release() then 
that would most likely result in a crash anyway because the code segment 
is already unloaded.


Regards,
Christian.



regards,
dan carpenter


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

Re: [bug report] drm/ttm: fix re-init of global structures

[Dan Carpenter]

On Tue, Feb 04, 2020 at 03:03:43PM +0100, Christian König wrote:
> Am 04.02.20 um 13:57 schrieb Dan Carpenter:
> > Hello Christian König,
> > 
> > The patch bd4264112f93: "drm/ttm: fix re-init of global structures"
> > from Apr 16, 2019, leads to the following static checker warning:
> > 
> > drivers/gpu/drm/ttm/ttm_bo.c:1610 ttm_bo_global_release()
> > warn: passing freed memory 'glob'
> > 
> > drivers/gpu/drm/ttm/ttm_bo.c
> >1591  static void ttm_bo_global_kobj_release(struct kobject *kobj)
> >1592  {
> >1593  struct ttm_bo_global *glob =
> >1594  container_of(kobj, struct ttm_bo_global, kobj);
> >1595
> >1596  __free_page(glob->dummy_read_page);
> >1597  }
> >1598
> >1599  static void ttm_bo_global_release(void)
> >1600  {
> >1601  struct ttm_bo_global *glob = _bo_glob;
> >1602
> >1603  mutex_lock(_global_mutex);
> >1604  if (--ttm_bo_glob_use_count > 0)
> >1605  goto out;
> >1606
> >1607  kobject_del(>kobj);
> >1608  kobject_put(>kobj);
> >1609  ttm_mem_global_release(_mem_glob);
> >1610  memset(glob, 0, sizeof(*glob));
> > ^^
> > Depending on the config kobject_release() might call 
> > ttm_bo_global_kobj_release()
> > a few seconds after this memset.  Maybe put the memset into
> > ttm_bo_global_kobj_release()?
> 
> That's not possible. The object might be re-used directly after we drop the
> ttm_global_mutex.
> 

Hm...  That sucks.  If we reallocate glob->dummy_read_page before the
ttm_bo_global_kobj_release() gets called then we're toasted.

> How can we wait for the ttm_mem_global_release() to have finished?
> 

A bunch of these release functions use a completion.  But you probably
don't want a four second delay before we can re-use the struct.

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

Re: [Intel-gfx] [PATCH 5/5] drm: Remove exports for drm_pci_alloc/drm_pci_free

[Daniel Vetter]

On Sun, Feb 02, 2020 at 05:16:35PM +, Chris Wilson wrote:
> The drm_pci_alloc routines have been a thin wrapper around the core dma
> coherent routines. Remove the crutch of a wrapper and the exported
> symbols, marking it for only internal legacy use.
> 
> Signed-off-by: Chris Wilson 

Since Alex bothered to review the drm_bufs patches ...

Reviewed-by: Daniel Vetter 

I think all the other patches I've r-b stamped somewhere else already, but
if they changed pls poke.
-Daniel


> ---
>  drivers/gpu/drm/drm_bufs.c   |  5 +++--
>  drivers/gpu/drm/drm_legacy.h | 23 +++
>  drivers/gpu/drm/drm_pci.c| 31 ++-
>  include/drm/drm_pci.h| 18 --
>  4 files changed, 32 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index 19297e58b232..a33df3744f76 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -675,7 +675,7 @@ static void drm_cleanup_buf_error(struct drm_device *dev,
>   if (entry->seg_count) {
>   for (i = 0; i < entry->seg_count; i++) {
>   if (entry->seglist[i]) {
> - drm_pci_free(dev, entry->seglist[i]);
> + drm_legacy_pci_free(dev, entry->seglist[i]);
>   }
>   }
>   kfree(entry->seglist);
> @@ -975,7 +975,8 @@ int drm_legacy_addbufs_pci(struct drm_device *dev,
>  
>   while (entry->buf_count < count) {
>  
> - dmah = drm_pci_alloc(dev, PAGE_SIZE << page_order, 0x1000);
> + dmah = drm_legacy_pci_alloc(dev,
> + PAGE_SIZE << page_order, 0x1000);
>  
>   if (!dmah) {
>   /* Set count correctly so we free the proper amount. */
> diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
> index 1be3ea320474..3853b45341c7 100644
> --- a/drivers/gpu/drm/drm_legacy.h
> +++ b/drivers/gpu/drm/drm_legacy.h
> @@ -36,6 +36,7 @@
>  
>  struct agp_memory;
>  struct drm_device;
> +struct drm_dma_handle;
>  struct drm_file;
>  struct drm_buf_desc;
>  
> @@ -211,4 +212,26 @@ void drm_master_legacy_init(struct drm_master *master);
>  static inline void drm_master_legacy_init(struct drm_master *master) {}
>  #endif
>  
> +
> +#if IS_ENABLED(CONFIG_DRM_LEGACY) && IS_ENABLED(CONFIG_PCI)
> +
> +struct drm_dma_handle *
> +drm_legacy_pci_alloc(struct drm_device *dev, size_t size, size_t align);
> +void drm_legacy_pci_free(struct drm_device *dev, struct drm_dma_handle * 
> dmah);
> +
> +#else
> +
> +static inline struct drm_dma_handle *
> +drm_legacy_pci_alloc(struct drm_device *dev, size_t size, size_t align)
> +{
> + return NULL;
> +}
> +
> +static inline void drm_legacy_pci_free(struct drm_device *dev,
> +struct drm_dma_handle *dmah)
> +{
> +}
> +
> +#endif
> +
>  #endif /* __DRM_LEGACY_H__ */
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index c6bb98729a26..12239498538c 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -36,19 +36,10 @@
>  #include "drm_internal.h"
>  #include "drm_legacy.h"
>  
> -/**
> - * drm_pci_alloc - Allocate a PCI consistent memory block, for DMA.
> - * @dev: DRM device
> - * @size: size of block to allocate
> - * @align: alignment of block
> - *
> - * FIXME: This is a needless abstraction of the Linux dma-api and should be
> - * removed.
> - *
> - * Return: A handle to the allocated memory block on success or NULL on
> - * failure.
> - */
> -drm_dma_handle_t *drm_pci_alloc(struct drm_device * dev, size_t size, size_t 
> align)
> +#if IS_ENABLED(CONFIG_DRM_LEGACY) && IS_ENABLED(CONFIG_PCI)
> +
> +drm_dma_handle_t *
> +drm_legacy_pci_alloc(struct drm_device * dev, size_t size, size_t align)
>  {
>   drm_dma_handle_t *dmah;
>  
> @@ -76,24 +67,14 @@ drm_dma_handle_t *drm_pci_alloc(struct drm_device * dev, 
> size_t size, size_t ali
>   return dmah;
>  }
>  
> -EXPORT_SYMBOL(drm_pci_alloc);
> -
> -/**
> - * drm_pci_free - Free a PCI consistent memory block
> - * @dev: DRM device
> - * @dmah: handle to memory block
> - *
> - * FIXME: This is a needless abstraction of the Linux dma-api and should be
> - * removed.
> - */
> -void drm_pci_free(struct drm_device * dev, drm_dma_handle_t * dmah)
> +void drm_legacy_pci_free(struct drm_device * dev, drm_dma_handle_t * dmah)
>  {
>   dma_free_coherent(>pdev->dev, dmah->size, dmah->vaddr,
> dmah->busaddr);
>   kfree(dmah);
>  }
>  
> -EXPORT_SYMBOL(drm_pci_free);
> +#endif
>  
>  static int drm_get_pci_domain(struct drm_device *dev)
>  {
> diff --git a/include/drm/drm_pci.h b/include/drm/drm_pci.h
> index 9031e217b506..cade5b60b643 100644
> --- a/include/drm/drm_pci.h
> +++ b/include/drm/drm_pci.h
> @@ -34,34 +34,16 @@
>  
>  #include 
>  
> -struct drm_dma_handle;
> -struct drm_device;
>  struct drm_driver;
> -struct 

Re: [bug report] drm/ttm: fix re-init of global structures

[Christian König]

Am 04.02.20 um 13:57 schrieb Dan Carpenter:

Hello Christian König,

The patch bd4264112f93: "drm/ttm: fix re-init of global structures"
from Apr 16, 2019, leads to the following static checker warning:

drivers/gpu/drm/ttm/ttm_bo.c:1610 ttm_bo_global_release()
warn: passing freed memory 'glob'

drivers/gpu/drm/ttm/ttm_bo.c
   1591  static void ttm_bo_global_kobj_release(struct kobject *kobj)
   1592  {
   1593  struct ttm_bo_global *glob =
   1594  container_of(kobj, struct ttm_bo_global, kobj);
   1595
   1596  __free_page(glob->dummy_read_page);
   1597  }
   1598
   1599  static void ttm_bo_global_release(void)
   1600  {
   1601  struct ttm_bo_global *glob = _bo_glob;
   1602
   1603  mutex_lock(_global_mutex);
   1604  if (--ttm_bo_glob_use_count > 0)
   1605  goto out;
   1606
   1607  kobject_del(>kobj);
   1608  kobject_put(>kobj);
   1609  ttm_mem_global_release(_mem_glob);
   1610  memset(glob, 0, sizeof(*glob));
^^
Depending on the config kobject_release() might call 
ttm_bo_global_kobj_release()
a few seconds after this memset.  Maybe put the memset into
ttm_bo_global_kobj_release()?


That's not possible. The object might be re-used directly after we drop 
the ttm_global_mutex.


How can we wait for the ttm_mem_global_release() to have finished?

I mean in theory that function should actually be used from a 
module_exit() callback, and we need to make 100% sure that the kobj is 
gone or we are running in a bunch of trouble.


Christian.



   1611  out:
   1612  mutex_unlock(_global_mutex);
   1613  }


regards,
dan carpenter


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

[PATCH 2/3] drm/tegra: Reuse IOVA mapping where possible

[Thierry Reding]

From: Thierry Reding 

This partially reverts the DMA API support that was recently merged
because it was causing performance regressions on older Tegra devices.
Unfortunately, the cache maintenance performed by dma_map_sg() and
dma_unmap_sg() causes performance to drop by a factor of 10.

The right solution for this would be to cache mappings for buffers per
consumer device, but that's a bit involved. Instead, we simply revert to
the old behaviour of sharing IOVA mappings when we know that devices can
do so (i.e. they share the same IOMMU domain).

Reported-by: Dmitry Osipenko 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/gem.c   | 10 +++-
 drivers/gpu/drm/tegra/plane.c | 44 ---
 drivers/gpu/host1x/job.c  | 32 ++---
 3 files changed, 63 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 1237df157e05..623768100c6a 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -60,8 +60,16 @@ static struct sg_table *tegra_bo_pin(struct device *dev, 
struct host1x_bo *bo,
/*
 * If we've manually mapped the buffer object through the IOMMU, make
 * sure to return the IOVA address of our mapping.
+*
+* Similarly, for buffers that have been allocated by the DMA API the
+* physical address can be used for devices that are not attached to
+* an IOMMU. For these devices, callers must pass a valid pointer via
+* the @phys argument.
+*
+* Imported buffers were also already mapped at import time, so the
+* existing mapping can be reused.
 */
-   if (phys && obj->mm) {
+   if (phys) {
*phys = obj->iova;
return NULL;
}
diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index cadcdd9ea427..9ccfb56e9b01 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -3,6 +3,8 @@
  * Copyright (C) 2017 NVIDIA CORPORATION.  All rights reserved.
  */
 
+#include 
+
 #include 
 #include 
 #include 
@@ -107,21 +109,27 @@ const struct drm_plane_funcs tegra_plane_funcs = {
 
 static int tegra_dc_pin(struct tegra_dc *dc, struct tegra_plane_state *state)
 {
+   struct iommu_domain *domain = iommu_get_domain_for_dev(dc->dev);
unsigned int i;
int err;
 
for (i = 0; i < state->base.fb->format->num_planes; i++) {
struct tegra_bo *bo = tegra_fb_get_plane(state->base.fb, i);
+   dma_addr_t phys_addr, *phys;
+   struct sg_table *sgt;
 
-   if (!dc->client.group) {
-   struct sg_table *sgt;
+   if (!domain || dc->client.group)
+   phys = _addr;
+   else
+   phys = NULL;
 
-   sgt = host1x_bo_pin(dc->dev, >base, NULL);
-   if (IS_ERR(sgt)) {
-   err = PTR_ERR(sgt);
-   goto unpin;
-   }
+   sgt = host1x_bo_pin(dc->dev, >base, phys);
+   if (IS_ERR(sgt)) {
+   err = PTR_ERR(sgt);
+   goto unpin;
+   }
 
+   if (sgt) {
err = dma_map_sg(dc->dev, sgt->sgl, sgt->nents,
 DMA_TO_DEVICE);
if (err == 0) {
@@ -143,7 +151,7 @@ static int tegra_dc_pin(struct tegra_dc *dc, struct 
tegra_plane_state *state)
state->iova[i] = sg_dma_address(sgt->sgl);
state->sgt[i] = sgt;
} else {
-   state->iova[i] = bo->iova;
+   state->iova[i] = phys_addr;
}
}
 
@@ -156,9 +164,11 @@ static int tegra_dc_pin(struct tegra_dc *dc, struct 
tegra_plane_state *state)
struct tegra_bo *bo = tegra_fb_get_plane(state->base.fb, i);
struct sg_table *sgt = state->sgt[i];
 
-   dma_unmap_sg(dc->dev, sgt->sgl, sgt->nents, DMA_TO_DEVICE);
-   host1x_bo_unpin(dc->dev, >base, sgt);
+   if (sgt)
+   dma_unmap_sg(dc->dev, sgt->sgl, sgt->nents,
+DMA_TO_DEVICE);
 
+   host1x_bo_unpin(dc->dev, >base, sgt);
state->iova[i] = DMA_MAPPING_ERROR;
state->sgt[i] = NULL;
}
@@ -172,17 +182,13 @@ static void tegra_dc_unpin(struct tegra_dc *dc, struct 
tegra_plane_state *state)
 
for (i = 0; i < state->base.fb->format->num_planes; i++) {
struct tegra_bo *bo = tegra_fb_get_plane(state->base.fb, i);
+   struct sg_table *sgt = state->sgt[i];
 
-   if (!dc->client.group) {
-   struct sg_table *sgt = state->sgt[i];
-
-   if (sgt) {
-  

[PATCH 3/3] gpu: host1x: Set DMA direction only for DMA-mapped buffer objects

[Thierry Reding]

From: Thierry Reding 

The DMA direction is only used by the DMA API, so there is no use in
setting it when a buffer object isn't mapped with the DMA API.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/job.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 8198a4d42c77..a10643aa89aa 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -248,6 +248,7 @@ static unsigned int pin_job(struct host1x *host, struct 
host1x_job *job)
goto unpin;
}
 
+   job->unpins[job->num_unpins].dir = DMA_TO_DEVICE;
job->unpins[job->num_unpins].dev = host->dev;
phys_addr = sg_dma_address(sgt->sgl);
}
@@ -255,7 +256,6 @@ static unsigned int pin_job(struct host1x *host, struct 
host1x_job *job)
job->addr_phys[job->num_unpins] = phys_addr;
job->gather_addr_phys[i] = phys_addr;
 
-   job->unpins[job->num_unpins].dir = DMA_TO_DEVICE;
job->unpins[job->num_unpins].bo = g->bo;
job->unpins[job->num_unpins].sgt = sgt;
job->num_unpins++;
-- 
2.24.1

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

[PATCH 0/3] drm/tegra: A couple of fixes for v5.6-rc1

[Thierry Reding]

From: Thierry Reding 

Hi,

this contains a couple of fixes for a DMA API performance regression
that was introduced in v5.5 for older Tegra devices. Patches 1 and 2
will likely have to be backported to v5.5.

Thierry

Thierry Reding (3):
  drm/tegra: Relax IOMMU usage criteria on old Tegra
  drm/tegra: Reuse IOVA mapping where possible
  gpu: host1x: Set DMA direction only for DMA-mapped buffer objects

 drivers/gpu/drm/tegra/drm.c   | 49 +++
 drivers/gpu/drm/tegra/gem.c   | 10 ++-
 drivers/gpu/drm/tegra/plane.c | 44 +--
 drivers/gpu/host1x/job.c  | 34 +---
 4 files changed, 96 insertions(+), 41 deletions(-)

-- 
2.24.1

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

[PATCH 1/3] drm/tegra: Relax IOMMU usage criteria on old Tegra

[Thierry Reding]

From: Thierry Reding 

Older Tegra devices only allow addressing 32 bits of memory, so whether
or not the host1x is attached to an IOMMU doesn't matter. host1x IOMMU
attachment is only needed on devices that can address memory beyond the
32-bit boundary and where the host1x doesn't support the wide GATHER
opcode that allows it to access buffers at higher addresses.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c | 49 -
 1 file changed, 32 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index aa9e49f04988..bd268028fb3d 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1037,23 +1037,9 @@ void tegra_drm_free(struct tegra_drm *tegra, size_t 
size, void *virt,
free_pages((unsigned long)virt, get_order(size));
 }
 
-static int host1x_drm_probe(struct host1x_device *dev)
+static bool host1x_drm_wants_iommu(struct host1x_device *dev)
 {
-   struct drm_driver *driver = _drm_driver;
struct iommu_domain *domain;
-   struct tegra_drm *tegra;
-   struct drm_device *drm;
-   int err;
-
-   drm = drm_dev_alloc(driver, >dev);
-   if (IS_ERR(drm))
-   return PTR_ERR(drm);
-
-   tegra = kzalloc(sizeof(*tegra), GFP_KERNEL);
-   if (!tegra) {
-   err = -ENOMEM;
-   goto put;
-   }
 
/*
 * If the Tegra DRM clients are backed by an IOMMU, push buffers are
@@ -1082,9 +1068,38 @@ static int host1x_drm_probe(struct host1x_device *dev)
 * up the device tree appropriately. This is considered an problem
 * of integration, so care must be taken for the DT to be consistent.
 */
-   domain = iommu_get_domain_for_dev(drm->dev->parent);
+   domain = iommu_get_domain_for_dev(dev->dev.parent);
+
+   /*
+* Tegra20 and Tegra30 don't support addressing memory beyond the
+* 32-bit boundary, so the regular GATHER opcodes will always be
+* sufficient and whether or not the host1x is attached to an IOMMU
+* doesn't matter.
+*/
+   if (!domain && dma_get_mask(dev->dev.parent) <= DMA_BIT_MASK(32))
+   return true;
+
+   return domain != NULL;
+}
+
+static int host1x_drm_probe(struct host1x_device *dev)
+{
+   struct drm_driver *driver = _drm_driver;
+   struct tegra_drm *tegra;
+   struct drm_device *drm;
+   int err;
+
+   drm = drm_dev_alloc(driver, >dev);
+   if (IS_ERR(drm))
+   return PTR_ERR(drm);
+
+   tegra = kzalloc(sizeof(*tegra), GFP_KERNEL);
+   if (!tegra) {
+   err = -ENOMEM;
+   goto put;
+   }
 
-   if (domain && iommu_present(_bus_type)) {
+   if (host1x_drm_wants_iommu(dev) && iommu_present(_bus_type)) {
tegra->domain = iommu_domain_alloc(_bus_type);
if (!tegra->domain) {
err = -ENOMEM;
-- 
2.24.1

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

[Bug 206393] amdgpu: garbled screen after resume

[bugzilla-daemon]

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

Bjoern Franke (b...@nord-west.org) changed:

   What|Removed |Added

 Regression|No  |Yes

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

Re: [Intel-gfx] [PATCH 6/8] drm/edid: Add a FIXME about DispID CEA data block revision

[Ville Syrjälä]

On Mon, Feb 03, 2020 at 08:15:51PM +, Shankar, Uma wrote:
> 
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of 
> > Ville Syrjala
> > Sent: Saturday, January 25, 2020 1:32 AM
> > To: dri-devel@lists.freedesktop.org
> > Cc: intel-...@lists.freedesktop.org; Andres Rodriguez 
> > Subject: [Intel-gfx] [PATCH 6/8] drm/edid: Add a FIXME about DispID CEA 
> > data block
> > revision
> > 
> > From: Ville Syrjälä 
> > 
> > I don't understand what the DispID CEA data block revision means. The spec 
> > doesn't
> > say. I guess some DispID must have a value of >= 3 in there or else we 
> > generally
> > wouldn't even parse the CEA data blocks. Or does all this code actually not 
> > do
> > anything?
> 
> This signifies the CTA extension revision (byte 1 of the block). As per the 
> spec, seems like
> Version 1 is legacy and 2 is deprecated. So version >=3 is checked here.
> Refer section 7.3 of CTA-861-G

The confusion is about the revision field in the DispID CTA
block, not in the CTA extension block.

> 
> > Cc: Andres Rodriguez 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> > 0369a54e3d32..fd9b724067a7 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3977,6 +3977,13 @@ cea_db_tag(const u8 *db)  static int  
> > cea_revision(const
> > u8 *cea)  {
> > +   /*
> > +* FIXME is this correct for the DispID variant?
> > +* The DispID spec doesn't really specify whether
> > +* this is the revision of the CEA extension or
> > +* the DispID CEA data block. And the only value
> > +* given as an example is 0.
> > +*/
> > return cea[1];
> >  }
> > 
> > --
> > 2.24.1
> > 
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[bug report] drm/ttm: fix re-init of global structures

[Dan Carpenter]

Hello Christian König,

The patch bd4264112f93: "drm/ttm: fix re-init of global structures"
from Apr 16, 2019, leads to the following static checker warning:

drivers/gpu/drm/ttm/ttm_bo.c:1610 ttm_bo_global_release()
warn: passing freed memory 'glob'

drivers/gpu/drm/ttm/ttm_bo.c
  1591  static void ttm_bo_global_kobj_release(struct kobject *kobj)
  1592  {
  1593  struct ttm_bo_global *glob =
  1594  container_of(kobj, struct ttm_bo_global, kobj);
  1595  
  1596  __free_page(glob->dummy_read_page);
  1597  }
  1598  
  1599  static void ttm_bo_global_release(void)
  1600  {
  1601  struct ttm_bo_global *glob = _bo_glob;
  1602  
  1603  mutex_lock(_global_mutex);
  1604  if (--ttm_bo_glob_use_count > 0)
  1605  goto out;
  1606  
  1607  kobject_del(>kobj);
  1608  kobject_put(>kobj);
  1609  ttm_mem_global_release(_mem_glob);
  1610  memset(glob, 0, sizeof(*glob));
   ^^
Depending on the config kobject_release() might call 
ttm_bo_global_kobj_release()
a few seconds after this memset.  Maybe put the memset into
ttm_bo_global_kobj_release()?

  1611  out:
  1612  mutex_unlock(_global_mutex);
  1613  }


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

Re: [PATCH] drm/stm: ltdc: check number of endpoints

[Benjamin Gaignard]

Le jeu. 23 janv. 2020 à 10:51, Philippe CORNU  a écrit :
>
> Dear Yannick,
> Thank you for your patch,
>
> Acked-by: Philippe Cornu 
>
> Philippe :-)
>
> On 1/21/20 11:14 AM, Yannick Fertre wrote:
> > Number of endpoints could exceed the fix value MAX_ENDPOINTS(2).
> > Instead of increase simply this value, the number of endpoint
> > could be read from device tree. Load sequence has been a little
> > rework to take care of several panel or bridge which can be
> > connected/disconnected or enable/disable.

This patch doesn't apply on drm-misc-next.
Yannick could you rebase is on top of drm-misc-next and resend it ?
Thanks,

Benjamin
> >
> > Signed-off-by: Yannick Fertré 
> > ---
> >   drivers/gpu/drm/stm/ltdc.c | 104 
> > ++---
> >   1 file changed, 52 insertions(+), 52 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> > index c2815e8..dba8e7f 100644
> > --- a/drivers/gpu/drm/stm/ltdc.c
> > +++ b/drivers/gpu/drm/stm/ltdc.c
> > @@ -42,8 +42,6 @@
> >
> >   #define MAX_IRQ 4
> >
> > -#define MAX_ENDPOINTS 2
> > -
> >   #define HWVER_10200 0x010200
> >   #define HWVER_10300 0x010300
> >   #define HWVER_20101 0x020101
> > @@ -1190,36 +1188,20 @@ int ltdc_load(struct drm_device *ddev)
> >   struct ltdc_device *ldev = ddev->dev_private;
> >   struct device *dev = ddev->dev;
> >   struct device_node *np = dev->of_node;
> > - struct drm_bridge *bridge[MAX_ENDPOINTS] = {NULL};
> > - struct drm_panel *panel[MAX_ENDPOINTS] = {NULL};
> > + struct drm_bridge *bridge;
> > + struct drm_panel *panel;
> >   struct drm_crtc *crtc;
> >   struct reset_control *rstc;
> >   struct resource *res;
> > - int irq, ret, i, endpoint_not_ready = -ENODEV;
> > + int irq, i, nb_endpoints;
> > + int ret = -ENODEV;
> >
> >   DRM_DEBUG_DRIVER("\n");
> >
> > - /* Get endpoints if any */
> > - for (i = 0; i < MAX_ENDPOINTS; i++) {
> > - ret = drm_of_find_panel_or_bridge(np, 0, i, [i],
> > -   [i]);
> > -
> > - /*
> > -  * If at least one endpoint is -EPROBE_DEFER, defer probing,
> > -  * else if at least one endpoint is ready, continue probing.
> > -  */
> > - if (ret == -EPROBE_DEFER)
> > - return ret;
> > - else if (!ret)
> > - endpoint_not_ready = 0;
> > - }
> > -
> > - if (endpoint_not_ready)
> > - return endpoint_not_ready;
> > -
> > - rstc = devm_reset_control_get_exclusive(dev, NULL);
> > -
> > - mutex_init(>err_lock);
> > + /* Get number of endpoints */
> > + nb_endpoints = of_graph_get_endpoint_count(np);
> > + if (!nb_endpoints)
> > + return -ENODEV;
> >
> >   ldev->pixel_clk = devm_clk_get(dev, "lcd");
> >   if (IS_ERR(ldev->pixel_clk)) {
> > @@ -1233,6 +1215,43 @@ int ltdc_load(struct drm_device *ddev)
> >   return -ENODEV;
> >   }
> >
> > + /* Get endpoints if any */
> > + for (i = 0; i < nb_endpoints; i++) {
> > + ret = drm_of_find_panel_or_bridge(np, 0, i, , );
> > +
> > + /*
> > +  * If at least one endpoint is -ENODEV, continue probing,
> > +  * else if at least one endpoint returned an error
> > +  * (ie -EPROBE_DEFER) then stop probing.
> > +  */
> > + if (ret == -ENODEV)
> > + continue;
> > + else if (ret)
> > + goto err;
> > +
> > + if (panel) {
> > + bridge = drm_panel_bridge_add_typed(panel,
> > + 
> > DRM_MODE_CONNECTOR_DPI);
> > + if (IS_ERR(bridge)) {
> > + DRM_ERROR("panel-bridge endpoint %d\n", i);
> > + ret = PTR_ERR(bridge);
> > + goto err;
> > + }
> > + }
> > +
> > + if (bridge) {
> > + ret = ltdc_encoder_init(ddev, bridge);
> > + if (ret) {
> > + DRM_ERROR("init encoder endpoint %d\n", i);
> > + goto err;
> > + }
> > + }
> > + }
> > +
> > + rstc = devm_reset_control_get_exclusive(dev, NULL);
> > +
> > + mutex_init(>err_lock);
> > +
> >   if (!IS_ERR(rstc)) {
> >   reset_control_assert(rstc);
> >   usleep_range(10, 20);
> > @@ -1268,7 +1287,6 @@ int ltdc_load(struct drm_device *ddev)
> >   }
> >   }
> >
> > -
> >   ret = ltdc_get_caps(ddev);
> >   if (ret) {
> >   DRM_ERROR("hardware identifier (0x%08x) not supported!\n",
> > @@ -1278,27 +1296,6 @@ int ltdc_load(struct drm_device *ddev)
> >
> >   DRM_DEBUG_DRIVER("ltdc hw version 0x%08x\n", 

Re: [PATCH] drm/stm: dsi: stm mipi dsi doesn't print error on probe deferral

[Benjamin Gaignard]

Le jeu. 23 janv. 2020 à 10:54, Philippe CORNU  a écrit :
>
> Dears Yannick & Etienne,
> Thank you for your patch,
>
> Reviewed-by: Philippe Cornu 
>
> Philippe :-)
>
> On 1/21/20 11:24 AM, Yannick Fertre wrote:
> > From: Etienne Carriere 
> >
> > Change DSI driver to not print an error trace when probe
> > is deferred for a clock resource.

Applied on drm-misc-next?
Thanks,
Benjamin

> >
> > Signed-off-by: Etienne Carriere 
> > ---
> >   drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
> > b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> > index 4b16563..2e1f266 100644
> > --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> > +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> > @@ -377,7 +377,9 @@ static int dw_mipi_dsi_stm_probe(struct platform_device 
> > *pdev)
> >   dsi->pllref_clk = devm_clk_get(dev, "ref");
> >   if (IS_ERR(dsi->pllref_clk)) {
> >   ret = PTR_ERR(dsi->pllref_clk);
> > - DRM_ERROR("Unable to get pll reference clock: %d\n", ret);
> > + if (ret != -EPROBE_DEFER)
> > + DRM_ERROR("Unable to get pll reference clock: %d\n",
> > +   ret);
> >   goto err_clk_get;
> >   }
> >
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/stm: ltdc: check crtc state before enabling LIE

[Benjamin Gaignard]

Le jeu. 23 janv. 2020 à 10:50, Philippe CORNU  a écrit :
>
> Dear Yannick,
> Thank you for your patch,
>
> Acked-by: Philippe Cornu 
>
> Philippe :-)
>
> On 1/21/20 11:14 AM, Yannick Fertre wrote:
> > Following investigations of a hardware bug, the LIE interrupt
> > can occur while the display controller is not activated.
> > LIE interrupt (vblank) don't have to be set if the CRTC is not
> > enabled.
> >

Applied on drm-misc-next.

Thanks
Benjamin

> > Signed-off-by: Yannick Fertre 
> > ---
> >   drivers/gpu/drm/stm/ltdc.c | 7 ++-
> >   1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> > index c2815e8..ea654c7 100644
> > --- a/drivers/gpu/drm/stm/ltdc.c
> > +++ b/drivers/gpu/drm/stm/ltdc.c
> > @@ -648,9 +648,14 @@ static const struct drm_crtc_helper_funcs 
> > ltdc_crtc_helper_funcs = {
> >   static int ltdc_crtc_enable_vblank(struct drm_crtc *crtc)
> >   {
> >   struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> > + struct drm_crtc_state *state = crtc->state;
> >
> >   DRM_DEBUG_DRIVER("\n");
> > - reg_set(ldev->regs, LTDC_IER, IER_LIE);
> > +
> > + if (state->enable)
> > + reg_set(ldev->regs, LTDC_IER, IER_LIE);
> > + else
> > + return -EPERM;
> >
> >   return 0;
> >   }
> >
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/stm: ltdc: add number of interrupts

[Benjamin Gaignard]

Le jeu. 23 janv. 2020 à 10:49, Philippe CORNU  a écrit :
>
> Dear Yannick,
> Thank you for your patch,
>
> Acked-by: Philippe Cornu 
>
> Philippe :-)
>
> On 1/21/20 11:13 AM, Yannick Fertre wrote:
> > The number of interrupts depends on the ltdc version.
> > Don't try to get interrupt which not exist, avoiding
> > kernel warning messages.

Applied on drm-misc-next.

Thanks,
Benjamin

> >
> > Signed-off-by: Yannick Fertre 
> > ---
> >   drivers/gpu/drm/stm/ltdc.c | 30 +++---
> >   drivers/gpu/drm/stm/ltdc.h |  1 +
> >   2 files changed, 16 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> > index c2815e8..58092b0 100644
> > --- a/drivers/gpu/drm/stm/ltdc.c
> > +++ b/drivers/gpu/drm/stm/ltdc.c
> > @@ -1146,12 +1146,14 @@ static int ltdc_get_caps(struct drm_device *ddev)
> >   ldev->caps.pad_max_freq_hz = 9000;
> >   if (ldev->caps.hw_version == HWVER_10200)
> >   ldev->caps.pad_max_freq_hz = 6500;
> > + ldev->caps.nb_irq = 2;
> >   break;
> >   case HWVER_20101:
> >   ldev->caps.reg_ofs = REG_OFS_4;
> >   ldev->caps.pix_fmt_hw = ltdc_pix_fmt_a1;
> >   ldev->caps.non_alpha_only_l1 = false;
> >   ldev->caps.pad_max_freq_hz = 15000;
> > + ldev->caps.nb_irq = 4;
> >   break;
> >   default:
> >   return -ENODEV;
> > @@ -1251,13 +1253,21 @@ int ltdc_load(struct drm_device *ddev)
> >   reg_clear(ldev->regs, LTDC_IER,
> > IER_LIE | IER_RRIE | IER_FUIE | IER_TERRIE);
> >
> > - for (i = 0; i < MAX_IRQ; i++) {
> > + ret = ltdc_get_caps(ddev);
> > + if (ret) {
> > + DRM_ERROR("hardware identifier (0x%08x) not supported!\n",
> > +   ldev->caps.hw_version);
> > + goto err;
> > + }
> > +
> > + DRM_DEBUG_DRIVER("ltdc hw version 0x%08x\n", ldev->caps.hw_version);
> > +
> > + for (i = 0; i < ldev->caps.nb_irq; i++) {
> >   irq = platform_get_irq(pdev, i);
> > - if (irq == -EPROBE_DEFER)
> > + if (irq < 0) {
> > + ret = irq;
> >   goto err;
> > -
> > - if (irq < 0)
> > - continue;
> > + }
> >
> >   ret = devm_request_threaded_irq(dev, irq, ltdc_irq,
> >   ltdc_irq_thread, IRQF_ONESHOT,
> > @@ -1268,16 +1278,6 @@ int ltdc_load(struct drm_device *ddev)
> >   }
> >   }
> >
> > -
> > - ret = ltdc_get_caps(ddev);
> > - if (ret) {
> > - DRM_ERROR("hardware identifier (0x%08x) not supported!\n",
> > -   ldev->caps.hw_version);
> > - goto err;
> > - }
> > -
> > - DRM_DEBUG_DRIVER("ltdc hw version 0x%08x\n", ldev->caps.hw_version);
> > -
> >   /* Add endpoints panels or bridges if any */
> >   for (i = 0; i < MAX_ENDPOINTS; i++) {
> >   if (panel[i]) {
> > diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
> > index a1ad0ae..310e87f 100644
> > --- a/drivers/gpu/drm/stm/ltdc.h
> > +++ b/drivers/gpu/drm/stm/ltdc.h
> > @@ -19,6 +19,7 @@ struct ltdc_caps {
> >   const u32 *pix_fmt_hw;  /* supported pixel formats */
> >   bool non_alpha_only_l1; /* non-native no-alpha formats on layer 1 */
> >   int pad_max_freq_hz;/* max frequency supported by pad */
> > + int nb_irq; /* number of hardware interrupts */
> >   };
> >
> >   #define LTDC_MAX_LAYER  4
> >
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/stm: ltdc: enable/disable depends on encoder

[Benjamin Gaignard]

Le jeu. 23 janv. 2020 à 10:47, Philippe CORNU  a écrit :
>
> Dear Yannick,
> Thank you for your patch,
>
> Acked-by: Philippe Cornu 
>
> Philippe :-)
>
> On 1/20/20 2:46 PM, Yannick Fertre wrote:
> > From: Yannick Fertré 
> >
> > When connected to a dsi host, the ltdc display controller
> > must send frames only after the end of the dsi panel
> > initialization to avoid errors when the dsi host sends
> > commands to the dsi panel (dsi px fifo full).
> > To avoid this issue, the display controller must be
> > enabled/disabled when the encoder is enabled/disabled.
> >

Applied on drm-misc-next.

Thanks
Benjamin

> > Signed-off-by: Yannick Fertré 
> > ---
> >   drivers/gpu/drm/stm/ltdc.c | 14 --
> >   1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> > index 719dfc5..9ef125d 100644
> > --- a/drivers/gpu/drm/stm/ltdc.c
> > +++ b/drivers/gpu/drm/stm/ltdc.c
> > @@ -437,9 +437,6 @@ static void ltdc_crtc_atomic_enable(struct drm_crtc 
> > *crtc,
> >   /* Commit shadow registers = update planes at next vblank */
> >   reg_set(ldev->regs, LTDC_SRCR, SRCR_VBR);
> >
> > - /* Enable LTDC */
> > - reg_set(ldev->regs, LTDC_GCR, GCR_LTDCEN);
> > -
> >   drm_crtc_vblank_on(crtc);
> >   }
> >
> > @@ -453,9 +450,6 @@ static void ltdc_crtc_atomic_disable(struct drm_crtc 
> > *crtc,
> >
> >   drm_crtc_vblank_off(crtc);
> >
> > - /* disable LTDC */
> > - reg_clear(ldev->regs, LTDC_GCR, GCR_LTDCEN);
> > -
> >   /* disable IRQ */
> >   reg_clear(ldev->regs, LTDC_IER, IER_RRIE | IER_FUIE | IER_TERRIE);
> >
> > @@ -1058,9 +1052,13 @@ static const struct drm_encoder_funcs 
> > ltdc_encoder_funcs = {
> >   static void ltdc_encoder_disable(struct drm_encoder *encoder)
> >   {
> >   struct drm_device *ddev = encoder->dev;
> > + struct ltdc_device *ldev = ddev->dev_private;
> >
> >   DRM_DEBUG_DRIVER("\n");
> >
> > + /* Disable LTDC */
> > + reg_clear(ldev->regs, LTDC_GCR, GCR_LTDCEN);
> > +
> >   /* Set to sleep state the pinctrl whatever type of encoder */
> >   pinctrl_pm_select_sleep_state(ddev->dev);
> >   }
> > @@ -1068,6 +1066,7 @@ static void ltdc_encoder_disable(struct drm_encoder 
> > *encoder)
> >   static void ltdc_encoder_enable(struct drm_encoder *encoder)
> >   {
> >   struct drm_device *ddev = encoder->dev;
> > + struct ltdc_device *ldev = ddev->dev_private;
> >
> >   DRM_DEBUG_DRIVER("\n");
> >
> > @@ -1078,6 +1077,9 @@ static void ltdc_encoder_enable(struct drm_encoder 
> > *encoder)
> >*/
> >   if (encoder->encoder_type == DRM_MODE_ENCODER_DPI)
> >   pinctrl_pm_select_default_state(ddev->dev);
> > +
> > + /* Enable LTDC */
> > + reg_set(ldev->regs, LTDC_GCR, GCR_LTDCEN);
> >   }
> >
> >   static const struct drm_encoder_helper_funcs ltdc_encoder_helper_funcs = {
> >
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/12] drm/i915/display: conversion to drm_device based logging macros

[Jani Nikula]

On Thu, 30 Jan 2020, Wambui Karuga  wrote:
> This series continues the conversion of the printk based logging macros
> to the new struct drm_device based logging macros in the drm/i915/display
> folder.

Thanks for the patches, series pushed to drm-intel-next-queued.

BR,
Jani.

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

Re: [Intel-gfx] [PATCH v5 00/21] drm: Introduce struct drm_device based WARN* and use them in i915

[Jani Nikula]

On Tue, 28 Jan 2020, Pankaj Bharadiya  
wrote:
> Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
> include device information in the backtrace, so we know what device
> the warnings originate from.
>
> Similar to this, add new struct drm_device based drm_WARN* macros. These
> macros include device information in the backtrace, so we know
> what device the warnings originate from. Knowing the device specific
> information in the backtrace would be helpful in development all
> around.
>
> This patch series aims to convert calls of WARN(), WARN_ON(),
> WARN_ONCE() and WARN_ON_ONCE() in i915 driver to use the drm
> device-specific variants automatically wherever struct device pointer
> is available.
>
> To do this, this patch series -
>   - introduces new struct drm_device based WARN* macros
>   - automatically converts WARN* with device specific dev_WARN*
> variants using coccinelle semantic patch scripts.
>
> The goal is to convert all the calls of WARN* with drm_WARN* in i915,
> but there are still cases where device pointer is not readily
> available in some functions (or I missed them somehow) using WARN*
> hence some manual churning is needed. Handle such remaining cases
> separately later.

Thanks for the patches, pushed all that applied, please rebase the rest.

BR,
Jani.


>
> changes since v4:
>- Address Jani's comment
>  - split major i915/display related conversions per file into
>seperate patches so that non conflicting patches can be
>merged.
>
> changes since v3:
>   - rebase pending unmerged patches on drm-tip
>   (bc626bbb5b6e drm-tip: 2020y-01m-25d-14h-28m-41s UTC integration 
> manifest)
>
> changes since v2:
>   - rebase pending unmerged patches on drm-tip
>
> changes since v1:
>   - Address Jani's review comments
> - Fix typo in comment of patch 0001
> - Get rid of helper functions
> - Split patches by directory
>
> Changes since RFC at [1]
>   - Introduce drm_WARN* macros and use them as suggested by Sam and Jani
>   - Get rid of extra local variables
>
> [1] https://patchwork.freedesktop.org/series/71668/
>
>
> Pankaj Bharadiya (21):
>   drm/i915/display/icl_dsi: Make WARN* drm specific where drm_priv ptr is 
> available
>   drm/i915/display/audio: Make WARN* drm specific where drm_priv ptr is 
> available
>   drm/i915/display/cdclk: Make WARN* drm specific where drm_priv ptr is 
> available
>   drm/i915/display/crt: Make WARN* drm specific where drm_priv ptr is 
> available
>   drm/i915/display/ddi: Make WARN* drm specific where drm_device ptr is 
> available
>   drm/i915/display/display: Make WARN* drm specific where drm_device ptr is 
> available
>   drm/i915/display/power: Make WARN* drm specific where drm_priv ptr is 
> available
>   drm/i915/display/dp: Make WARN* drm specific where drm_device ptr is 
> available
>   drm/i915/display/dpll_mgr: Make WARN* drm specific where drm_device ptr is 
> available
>   drm/i915/display/fbc: Make WARN* drm specific where drm_priv ptr is 
> available
>   drm/i915/fbdev: Make WARN* drm specific where drm_device ptr is available
>   drm/i915/display/hdcp: Make WARN* drm specific where drm_priv ptr is 
> available
>   drm/i915/display/hdmi: Make WARN* drm specific where drm_device ptr is 
> available
>   drm/i915/display/overlay: Make WARN* drm specific where drm_priv ptr is 
> available
>   drm/i915/display/panel: Make WARN* drm specific where drm_priv ptr is 
> available
>   drm/i915/display/psr: Make WARN* drm specific where drm_priv ptr is 
> available
>   drm/i915/display/sdvo: Make WARN* drm specific where drm_priv ptr is 
> available
>   drm/i915/display/tc: Make WARN* drm specific where drm_priv ptr is available
>   drm/i915/display: Make WARN* drm specific where drm_device ptr is available
>   drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available
>   drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available
>
>  drivers/gpu/drm/i915/display/icl_dsi.c|  14 +-
>  drivers/gpu/drm/i915/display/intel_atomic.c   |   6 +-
>  drivers/gpu/drm/i915/display/intel_audio.c|  19 +-
>  drivers/gpu/drm/i915/display/intel_bios.c |  10 +-
>  drivers/gpu/drm/i915/display/intel_bw.c   |   3 +-
>  drivers/gpu/drm/i915/display/intel_cdclk.c|  81 ---
>  drivers/gpu/drm/i915/display/intel_color.c|   3 +-
>  .../gpu/drm/i915/display/intel_combo_phy.c|   2 +-
>  .../gpu/drm/i915/display/intel_connector.c|   3 +-
>  drivers/gpu/drm/i915/display/intel_crt.c  |  10 +-
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  92 +++
>  drivers/gpu/drm/i915/display/intel_display.c  | 226 ++
>  .../drm/i915/display/intel_display_power.c| 168 +++--
>  drivers/gpu/drm/i915/display/intel_dp.c   | 117 +
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  10 +-
>  drivers/gpu/drm/i915/display/intel_dpio_phy.c |   3 +-
>  drivers/gpu/drm/i915/display/intel_dpll_mgr.c |  37 +--
>  

Re: [PATCH 5/5] drm: Remove exports for drm_pci_alloc/drm_pci_free

[kbuild test robot]

Hi Chris,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next 
linus/master next-20200203]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next v5.5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-Remove-PageReserved-manipulation-from-drm_pci_alloc/20200203-201707
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-s2-20200204 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.2-10+deb8u1) 4.9.2
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

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

All errors (new ones prefixed by >>):

   drivers/gpu/drm/drm_dma.c: In function 'drm_legacy_dma_takedown':
>> drivers/gpu/drm/drm_dma.c:103:6: error: implicit declaration of function 
>> 'drm_pci_free' [-Werror=implicit-function-declaration]
 drm_pci_free(dev, dma->bufs[i].seglist[j]);
 ^
   cc1: some warnings being treated as errors

vim +/drm_pci_free +103 drivers/gpu/drm/drm_dma.c

^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   72  
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   73  
/**
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   74   
* Cleanup the DMA resources.
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   75   *
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   76   
* \param dev DRM device.
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   77   *
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   78   
* Free all pages associated with DMA buffers, the buffers and pages lists, and
59c51591a0ac75 drivers/char/drm/drm_dma.c Michael Opdenacker 2007-05-09   79   
* finally the drm_device::dma structure itself.
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   80   
*/
e2e99a8206bcce drivers/gpu/drm/drm_dma.c  Daniel Vetter  2013-08-08   81  
void drm_legacy_dma_takedown(struct drm_device *dev)
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   82  {
cdd55a294c13f8 drivers/char/drm/drm_dma.c Dave Airlie2007-07-11   83
struct drm_device_dma *dma = dev->dma;
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   84
int i, j;
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   85  
e2e99a8206bcce drivers/gpu/drm/drm_dma.c  Daniel Vetter  2013-08-08   86
if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA) ||
fa5386459f06dc drivers/gpu/drm/drm_dma.c  Daniel Vetter  2016-08-03   87
!drm_core_check_feature(dev, DRIVER_LEGACY))
e2e99a8206bcce drivers/gpu/drm/drm_dma.c  Daniel Vetter  2013-08-08   88
return;
e2e99a8206bcce drivers/gpu/drm/drm_dma.c  Daniel Vetter  2013-08-08   89  
b5e89ed53ed8d2 drivers/char/drm/drm_dma.c Dave Airlie2005-09-25   90
if (!dma)
b5e89ed53ed8d2 drivers/char/drm/drm_dma.c Dave Airlie2005-09-25   91
return;
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   92  
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   93
/* Clear dma buffers */
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   94
for (i = 0; i <= DRM_MAX_ORDER; i++) {
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   95
if (dma->bufs[i].seg_count) {
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   96
DRM_DEBUG("order %d: buf_count = %d,"
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   97
  " seg_count = %d\n",
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   98
  i,
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16   99
  dma->bufs[i].buf_count,
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16  100
  dma->bufs[i].seg_count);
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16  101
for (j = 0; j < dma->bufs[i].seg_count; j++) {
^1da177e4c3f41 drivers/char/drm/drm_dma.c Linus Torvalds 2005-04-16  102
if (dma->bufs[i].seglist[j]) {
ddf19b973be5a9 drivers/char/drm/drm_dma.c Dave Airlie2006-03-19 @103
drm_pci_free(dev, dma->bufs[i].s

Re: [PATCH v3 3/9] drm/bridge: ti-sn65dsi86: Don't use MIPI variables for DP link

[Bjorn Andersson]

On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:

> The ti-sn65dsi86 is a bridge from MIPI to DP and thus has two links:
> the MIPI link and the DP link.  The two links do not need to have the
> same format or number of lanes.  Stop using MIPI variables when
> talking about the DP link.
> 
> This has zero functional change because:
> * currently we are hardcoding the MIPI link as unpacked RGB888 which
>   requires 24 bits and currently we are not changing the DP link rate
>   from the bridge's default of 8 bits per pixel.
> * currently we are hardcoding both the MIPI and DP as being 4 lanes.
> 
> This is all in prep for fixing some of the above.
> 
> Signed-off-by: Douglas Anderson 
> Tested-by: Rob Clark 
> Reviewed-by: Rob Clark 

Reviewed-by: Bjorn Andersson 

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 7b596af265e4..ab644baaf90c 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -100,6 +100,7 @@ struct ti_sn_bridge {
>   struct drm_panel*panel;
>   struct gpio_desc*enable_gpio;
>   struct regulator_bulk_data  supplies[SN_REGULATOR_SUPPLY_NUM];
> + int dp_lanes;
>  };
>  
>  static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
> @@ -313,6 +314,7 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge)
>   }
>  
>   /* TODO: setting to 4 lanes always for now */
> + pdata->dp_lanes = 4;
>   dsi->lanes = 4;
>   dsi->format = MIPI_DSI_FMT_RGB888;
>   dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
> @@ -451,13 +453,17 @@ static void ti_sn_bridge_set_dp_rate(struct 
> ti_sn_bridge *pdata)
>   struct drm_display_mode *mode =
>   >bridge.encoder->crtc->state->adjusted_mode;
>  
> - /* set DSIA clk frequency */
> - bit_rate_mhz = (mode->clock / 1000) *
> - mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
> + /*
> +  * Calculate minimum bit rate based on our pixel clock.  At
> +  * the moment this driver never sets the DP_18BPP_EN bit in
> +  * register 0x5b so we hardcode 24bpp.
> +  */
> + bit_rate_mhz = (mode->clock / 1000) * 24;
>  
> - /* set DP data rate */
> - dp_rate_mhz = ((bit_rate_mhz / pdata->dsi->lanes) * DP_CLK_FUDGE_NUM) /
> + /* Calculate minimum DP data rate, taking 80% as per DP spec */
> + dp_rate_mhz = ((bit_rate_mhz / pdata->dp_lanes) * DP_CLK_FUDGE_NUM) /
>   DP_CLK_FUDGE_DEN;
> +
>   for (i = 1; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++)
>   if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
>   break;
> @@ -517,7 +523,7 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
>  CHA_DSI_LANES_MASK, val);
>  
>   /* DP lane config */
> - val = DP_NUM_LANES(pdata->dsi->lanes - 1);
> + val = DP_NUM_LANES(pdata->dp_lanes - 1);
>   regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG, DP_NUM_LANES_MASK,
>  val);
>  
> -- 
> 2.24.1.735.g03f4e72817-goog
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: Parse Colorimetry data block from EDID

[Stephen Boyd]

Quoting abhin...@codeaurora.org (2020-01-31 13:01:38)
> Hi Steven
> 
> Any further comments on this change?
> 

No. I was more of a drive by review comment on the previous patch.

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

Re: [PATCH v3 5/9] drm/bridge: ti-sn65dsi86: Read num lanes from the DP sink

[Bjorn Andersson]

On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:

> At least one panel hooked up to the bridge (AUO B116XAK01) only
> supports 1 lane of DP.  Let's read this information and stop
> hardcoding 4 DP lanes.
> 
> Signed-off-by: Douglas Anderson 
> Tested-by: Rob Clark 
> Reviewed-by: Rob Clark 

Reviewed-by: Bjorn Andersson 

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 32 +--
>  1 file changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index d55d19759796..0fc9e97b2d98 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -313,8 +313,7 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge)
>   goto err_dsi_host;
>   }
>  
> - /* TODO: setting to 4 lanes always for now */
> - pdata->dp_lanes = 4;
> + /* TODO: setting to 4 MIPI lanes always for now */
>   dsi->lanes = 4;
>   dsi->format = MIPI_DSI_FMT_RGB888;
>   dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
> @@ -511,12 +510,41 @@ static void ti_sn_bridge_set_video_timings(struct 
> ti_sn_bridge *pdata)
>   usleep_range(1, 10500); /* 10ms delay recommended by spec */
>  }
>  
> +static unsigned int ti_sn_get_max_lanes(struct ti_sn_bridge *pdata)
> +{
> + u8 data;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(>aux, DP_MAX_LANE_COUNT, );
> + if (ret != 1) {
> + DRM_DEV_ERROR(pdata->dev,
> +   "Can't read lane count (%d); assuming 4\n", ret);
> + return 4;
> + }
> +
> + return data & DP_LANE_COUNT_MASK;
> +}
> +
>  static void ti_sn_bridge_enable(struct drm_bridge *bridge)
>  {
>   struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
>   unsigned int val;
>   int ret;
>  
> + /*
> +  * Run with the maximum number of lanes that the DP sink supports.
> +  *
> +  * Depending use cases, we might want to revisit this later because:
> +  * - It's plausible that someone may have run fewer lines to the
> +  *   sink than the sink actually supports, assuming that the lines
> +  *   will just be driven at a higher rate.
> +  * - The DP spec seems to indicate that it's more important to minimize
> +  *   the number of lanes than the link rate.
> +  *
> +  * If we do revisit, it would be important to measure the power impact.
> +  */
> + pdata->dp_lanes = ti_sn_get_max_lanes(pdata);
> +
>   /* DSI_A lane config */
>   val = CHA_DSI_LANES(4 - pdata->dsi->lanes);
>   regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
> -- 
> 2.24.1.735.g03f4e72817-goog
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] drm/panfrost: Remove set but not used variable 'bo'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/panfrost/panfrost_job.c: In function 'panfrost_job_cleanup':
drivers/gpu/drm/panfrost/panfrost_job.c:278:31: warning:
 variable 'bo' set but not used [-Wunused-but-set-variable]

commit bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem_mapping concept")
involved this unused variable.

Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
---
 drivers/gpu/drm/panfrost/panfrost_job.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 7c36ec675b73..ccb8546a9342 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -275,12 +275,8 @@ static void panfrost_job_cleanup(struct kref *ref)
}
 
if (job->bos) {
-   struct panfrost_gem_object *bo;
-
-   for (i = 0; i < job->bo_count; i++) {
-   bo = to_panfrost_bo(job->bos[i]);
+   for (i = 0; i < job->bo_count; i++)
drm_gem_object_put_unlocked(job->bos[i]);
-   }
 
kvfree(job->bos);
}



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

Re: [PATCH v3 7/9] drm/bridge: ti-sn65dsi86: Group DP link training bits in a function

[Bjorn Andersson]

On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:

> We'll re-organize the ti_sn_bridge_enable() function a bit to group
> together all the parts relating to link training and split them into a
> sub-function.  This is not intended to have any functional change and
> is in preparation for trying link training several times at different
> rates.  One small side effect here is that if link training fails
> we'll now leave the DP PLL disabled, but that seems like a sane thing
> to do.
> 
> Signed-off-by: Douglas Anderson 
> Tested-by: Rob Clark 
> Reviewed-by: Rob Clark 

Reviewed-by: Bjorn Andersson 

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 86 ---
>  1 file changed, 52 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index d5990a0947b9..48fb4dc72e1c 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -530,6 +530,46 @@ static unsigned int ti_sn_get_max_lanes(struct 
> ti_sn_bridge *pdata)
>   return data & DP_LANE_COUNT_MASK;
>  }
>  
> +static int ti_sn_link_training(struct ti_sn_bridge *pdata)
> +{
> + unsigned int val;
> + int ret;
> +
> + /* set dp clk frequency value */
> + ti_sn_bridge_set_dp_rate(pdata);
> +
> + /* enable DP PLL */
> + regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1);
> +
> + ret = regmap_read_poll_timeout(pdata->regmap, SN_DPPLL_SRC_REG, val,
> +val & DPPLL_SRC_DP_PLL_LOCK, 1000,
> +50 * 1000);
> + if (ret) {
> + DRM_ERROR("DP_PLL_LOCK polling failed (%d)\n", ret);
> + goto exit;
> + }
> +
> + /* Semi auto link training mode */
> + regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> + ret = regmap_read_poll_timeout(pdata->regmap, SN_ML_TX_MODE_REG, val,
> +val == ML_TX_MAIN_LINK_OFF ||
> +val == ML_TX_NORMAL_MODE, 1000,
> +500 * 1000);
> + if (ret) {
> + DRM_ERROR("Training complete polling failed (%d)\n", ret);
> + } else if (val == ML_TX_MAIN_LINK_OFF) {
> + DRM_ERROR("Link training failed, link is off\n");
> + ret = -EIO;
> + }
> +
> +exit:
> + /* Disable the PLL if we failed */
> + if (ret)
> + regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 0);
> +
> + return ret;
> +}
> +
>  static void ti_sn_bridge_enable(struct drm_bridge *bridge)
>  {
>   struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> @@ -555,29 +595,8 @@ static void ti_sn_bridge_enable(struct drm_bridge 
> *bridge)
>   regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
>  CHA_DSI_LANES_MASK, val);
>  
> - /* Set the DP output format (18 bpp or 24 bpp) */
> - val = (ti_sn_bridge_get_bpp(pdata) == 18) ? BPP_18_RGB : 0;
> - regmap_update_bits(pdata->regmap, SN_DATA_FORMAT_REG, BPP_18_RGB, val);
> -
> - /* DP lane config */
> - val = DP_NUM_LANES(min(pdata->dp_lanes, 3));
> - regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG, DP_NUM_LANES_MASK,
> -val);
> -
> - /* set dsi/dp clk frequency value */
> + /* set dsi clk frequency value */
>   ti_sn_bridge_set_dsi_rate(pdata);
> - ti_sn_bridge_set_dp_rate(pdata);
> -
> - /* enable DP PLL */
> - regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1);
> -
> - ret = regmap_read_poll_timeout(pdata->regmap, SN_DPPLL_SRC_REG, val,
> -val & DPPLL_SRC_DP_PLL_LOCK, 1000,
> -50 * 1000);
> - if (ret) {
> - DRM_ERROR("DP_PLL_LOCK polling failed (%d)\n", ret);
> - return;
> - }
>  
>   /**
>* The SN65DSI86 only supports ASSR Display Authentication method and
> @@ -588,19 +607,18 @@ static void ti_sn_bridge_enable(struct drm_bridge 
> *bridge)
>   drm_dp_dpcd_writeb(>aux, DP_EDP_CONFIGURATION_SET,
>  DP_ALTERNATE_SCRAMBLER_RESET_ENABLE);
>  
> - /* Semi auto link training mode */
> - regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> - ret = regmap_read_poll_timeout(pdata->regmap, SN_ML_TX_MODE_REG, val,
> -val == ML_TX_MAIN_LINK_OFF ||
> -val == ML_TX_NORMAL_MODE, 1000,
> -500 * 1000);
> - if (ret) {
> - DRM_ERROR("Training complete polling failed (%d)\n", ret);
> - return;
> - } else if (val == ML_TX_MAIN_LINK_OFF) {
> - DRM_ERROR("Link training failed, link is off\n");
> + /* Set the DP output format (18 bpp or 24 bpp) */
> + val = (ti_sn_bridge_get_bpp(pdata) == 18) ? BPP_18_RGB : 0;
> + 

Re: [PATCH v3 9/9] drm/bridge: ti-sn65dsi86: Avoid invalid rates

[Bjorn Andersson]

On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:

> Based on work by Bjorn Andersson ,
> Jeffrey Hugo , and
> Rob Clark .
> 
> Let's read the SUPPORTED_LINK_RATES and/or MAX_LINK_RATE (depending on
> the eDP version of the sink) to figure out what eDP rates are
> supported and pick the ideal one.
> 
> NOTE: I have only personally tested this code on eDP panels that are
> 1.3 or older.  Code reading SUPPORTED_LINK_RATES for DP 1.4+ was
> tested by hacking the code to pretend that a table was there.
> 
> Signed-off-by: Douglas Anderson 

Reviewed-by: Bjorn Andersson 

> ---
> 
> Changes in v3:
> - Init rate_valid table, don't rely on stack being 0 (oops).
> - Rename rate_times_200khz to rate_per_200khz.
> - Loop over the ti_sn_bridge_dp_rate_lut table, making code smaller.
> - Use 'true' instead of 1 for bools.
> - Added note to commit message noting DP 1.4+ isn't well tested.
> 
> Changes in v2:
> - Patch ("Avoid invalid rates") replaces ("Skip non-standard DP rates")
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 100 +++---
>  1 file changed, 75 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index e1b817ccd9c7..a57c6108cb1f 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -475,39 +475,85 @@ static int ti_sn_bridge_calc_min_dp_rate_idx(struct 
> ti_sn_bridge *pdata)
>   return i;
>  }
>  
> -static int ti_sn_bridge_get_max_dp_rate_idx(struct ti_sn_bridge *pdata)
> +static void ti_sn_bridge_read_valid_rates(struct ti_sn_bridge *pdata,
> +   bool rate_valid[])
>  {
> - u8 data;
> + unsigned int rate_per_200khz;
> + unsigned int rate_mhz;
> + u8 dpcd_val;
>   int ret;
> + int i, j;
> +
> + ret = drm_dp_dpcd_readb(>aux, DP_EDP_DPCD_REV, _val);
> + if (ret != 1) {
> + DRM_DEV_ERROR(pdata->dev,
> +   "Can't read eDP rev (%d), assuming 1.1\n", ret);
> + dpcd_val = DP_EDP_11;
> + }
> +
> + if (dpcd_val >= DP_EDP_14) {
> + /* eDP 1.4 devices must provide a custom table */
> + __le16 sink_rates[DP_MAX_SUPPORTED_RATES];
> +
> + ret = drm_dp_dpcd_read(>aux, DP_SUPPORTED_LINK_RATES,
> +sink_rates, sizeof(sink_rates));
> +
> + if (ret != sizeof(sink_rates)) {
> + DRM_DEV_ERROR(pdata->dev,
> + "Can't read supported rate table (%d)\n", ret);
> +
> + /* By zeroing we'll fall back to DP_MAX_LINK_RATE. */
> + memset(sink_rates, 0, sizeof(sink_rates));
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(sink_rates); i++) {
> + rate_per_200khz = le16_to_cpu(sink_rates[i]);
> +
> + if (!rate_per_200khz)
> + break;
> +
> + rate_mhz = rate_per_200khz * 200 / 1000;
> + for (j = 0;
> +  j < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut);
> +  j++) {
> + if (ti_sn_bridge_dp_rate_lut[j] == rate_mhz)
> + rate_valid[j] = true;
> + }
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut); i++) {
> + if (rate_valid[i])
> + return;
> + }
> + DRM_DEV_ERROR(pdata->dev,
> +   "No matching eDP rates in table; falling back\n");
> + }
>  
> - ret = drm_dp_dpcd_readb(>aux, DP_MAX_LINK_RATE, );
> + /* On older versions best we can do is use DP_MAX_LINK_RATE */
> + ret = drm_dp_dpcd_readb(>aux, DP_MAX_LINK_RATE, _val);
>   if (ret != 1) {
>   DRM_DEV_ERROR(pdata->dev,
> "Can't read max rate (%d); assuming 5.4 GHz\n",
> ret);
> - return ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1;
> + dpcd_val = DP_LINK_BW_5_4;
>   }
>  
> - /*
> -  * Return an index into ti_sn_bridge_dp_rate_lut.  Just hardcode
> -  * these indicies since it's not like the register spec is ever going
> -  * to change and a loop would just be more complicated.  Apparently
> -  * the DP sink can only return these few rates as supported even
> -  * though the bridge allows some rates in between.
> -  */
> - switch (data) {
> - case DP_LINK_BW_1_62:
> - return 1;
> - case DP_LINK_BW_2_7:
> - return 4;
> + switch (dpcd_val) {
> + default:
> + DRM_DEV_ERROR(pdata->dev,
> +   "Unexpected max rate (%#x); assuming 5.4 GHz\n",
> +   (int)dpcd_val);
> + /* fall through */
>   case DP_LINK_BW_5_4:
> - 

Re: [PATCH v2] drm/radeon: have the callers of set_memory_*() check the return value

[Tianlin Li]

> On Feb 3, 2020, at 11:16 AM, Christian König  wrote:
> 
> Am 03.02.20 um 17:18 schrieb Tianlin Li:
>> Right now several architectures allow their set_memory_*() family of
>> functions to fail,
> 
> Oh, that is a detail I previously didn't recognized. Which architectures are 
> that?
> 
> Cause the RS400/480, RS690 and RS740 which are affected by this are 
> integrated in the south-bridge.

At least x86 is. 
Some details: 
https://lore.kernel.org/netdev/20180628213459.28631-4-dan...@iogearbox.net/ 


>>  but callers may not be checking the return values.
>> If set_memory_*() returns with an error, call-site assumptions may be
>> infact wrong to assume that it would either succeed or not succeed at
>> all. Ideally, the failure of set_memory_*() should be passed up the
>> call stack, and callers should examine the failure and deal with it.
>> 
>> Need to fix the callers and add the __must_check attribute. They also
>> may not provide any level of atomicity, in the sense that the memory
>> protections may be left incomplete on failure. This issue likely has a
>> few steps on effects architectures:
>> 1)Have all callers of set_memory_*() helpers check the return value.
>> 2)Add __must_check to all set_memory_*() helpers so that new uses do
>> not ignore the return value.
>> 3)Add atomicity to the calls so that the memory protections aren't left
>> in a partial state.
>> 
>> This series is part of step 1. Make drm/radeon check the return value of
>> set_memory_*().
>> 
>> Signed-off-by: Tianlin Li 
> 
> Reviewed-by: Christian König  >
> 
>> ---
>> v2:
>> The hardware is too old to be tested on and the code cannot be simply
>> removed from the kernel, so this is the solution for the short term.
>> - Just print an error when something goes wrong
>> - Remove patch 2.
>> v1:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F20200107192555.20606-1-tli%40digitalocean.com%2Fdata=02%7C01%7Cchristian.koenig%40amd.com%7Cba2176d2ca834214e6b108d7a8c4bb1d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637163435227030235sdata=mDhUEi3vmxahjsdrZOr83OEIWNBHefO8lkXST%2FW32CE%3Dreserved=0
>>  
>> 
>> ---
>>  drivers/gpu/drm/radeon/radeon_gart.c | 10 ++
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
>> b/drivers/gpu/drm/radeon/radeon_gart.c
>> index f178ba321715..a2cc864aa08d 100644
>> --- a/drivers/gpu/drm/radeon/radeon_gart.c
>> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
>> @@ -80,8 +80,9 @@ int radeon_gart_table_ram_alloc(struct radeon_device *rdev)
>>  #ifdef CONFIG_X86
>>  if (rdev->family == CHIP_RS400 || rdev->family == CHIP_RS480 ||
>>  rdev->family == CHIP_RS690 || rdev->family == CHIP_RS740) {
>> -set_memory_uc((unsigned long)ptr,
>> -  rdev->gart.table_size >> PAGE_SHIFT);
>> +if (set_memory_uc((unsigned long)ptr,
>> +  rdev->gart.table_size >> PAGE_SHIFT))
>> +DRM_ERROR("set_memory_uc failed.\n");
>>  }
>>  #endif
>>  rdev->gart.ptr = ptr;
>> @@ -106,8 +107,9 @@ void radeon_gart_table_ram_free(struct radeon_device 
>> *rdev)
>>  #ifdef CONFIG_X86
>>  if (rdev->family == CHIP_RS400 || rdev->family == CHIP_RS480 ||
>>  rdev->family == CHIP_RS690 || rdev->family == CHIP_RS740) {
>> -set_memory_wb((unsigned long)rdev->gart.ptr,
>> -  rdev->gart.table_size >> PAGE_SHIFT);
>> +if (set_memory_wb((unsigned long)rdev->gart.ptr,
>> +  rdev->gart.table_size >> PAGE_SHIFT))
>> +DRM_ERROR("set_memory_wb failed.\n");
>>  }
>>  #endif
>>  pci_free_consistent(rdev->pdev, rdev->gart.table_size,

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

Re: [PATCH v3 1/9] drm/bridge: ti-sn65dsi86: Split the setting of the dp and dsi rates

[Bjorn Andersson]

On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:

> These two things were in one function.  Split into two.  This looks
> like it's duplicating some code, but don't worry.  This is is just in
> preparation for future changes.
> 
> This is intended to have zero functional change and will just make
> future patches easier to understand.
> 
> Signed-off-by: Douglas Anderson 
> Tested-by: Rob Clark 
> Reviewed-by: Rob Clark 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 33 +++
>  1 file changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 43abf01ebd4c..2fb9370a76e6 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -417,6 +417,24 @@ static void ti_sn_bridge_set_refclk_freq(struct 
> ti_sn_bridge *pdata)
>  REFCLK_FREQ(i));
>  }
>  
> +static void ti_sn_bridge_set_dsi_rate(struct ti_sn_bridge *pdata)
> +{
> + unsigned int bit_rate_mhz, clk_freq_mhz;
> + unsigned int val;
> + struct drm_display_mode *mode =
> + >bridge.encoder->crtc->state->adjusted_mode;
> +
> + /* set DSIA clk frequency */
> + bit_rate_mhz = (mode->clock / 1000) *
> + mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
> + clk_freq_mhz = bit_rate_mhz / (pdata->dsi->lanes * 2);
> +
> + /* for each increment in val, frequency increases by 5MHz */
> + val = (MIN_DSI_CLK_FREQ_MHZ / 5) +
> + (((clk_freq_mhz - MIN_DSI_CLK_FREQ_MHZ) / 5) & 0xFF);
> + regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
> +}
> +
>  /**
>   * LUT index corresponds to register value and
>   * LUT values corresponds to dp data rate supported
> @@ -426,22 +444,16 @@ static const unsigned int ti_sn_bridge_dp_rate_lut[] = {
>   0, 1620, 2160, 2430, 2700, 3240, 4320, 5400
>  };
>  
> -static void ti_sn_bridge_set_dsi_dp_rate(struct ti_sn_bridge *pdata)
> +static void ti_sn_bridge_set_dp_rate(struct ti_sn_bridge *pdata)
>  {
> - unsigned int bit_rate_mhz, clk_freq_mhz, dp_rate_mhz;
> - unsigned int val, i;
> + unsigned int bit_rate_mhz, dp_rate_mhz;
> + unsigned int i;
>   struct drm_display_mode *mode =
>   >bridge.encoder->crtc->state->adjusted_mode;
>  
>   /* set DSIA clk frequency */
>   bit_rate_mhz = (mode->clock / 1000) *
>   mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
> - clk_freq_mhz = bit_rate_mhz / (pdata->dsi->lanes * 2);
> -
> - /* for each increment in val, frequency increases by 5MHz */
> - val = (MIN_DSI_CLK_FREQ_MHZ / 5) +
> - (((clk_freq_mhz - MIN_DSI_CLK_FREQ_MHZ) / 5) & 0xFF);
> - regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
>  
>   /* set DP data rate */
>   dp_rate_mhz = ((bit_rate_mhz / pdata->dsi->lanes) * DP_CLK_FUDGE_NUM) /
> @@ -510,7 +522,8 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
>  val);
>  
>   /* set dsi/dp clk frequency value */
> - ti_sn_bridge_set_dsi_dp_rate(pdata);
> + ti_sn_bridge_set_dsi_rate(pdata);
> + ti_sn_bridge_set_dp_rate(pdata);
>  
>   /* enable DP PLL */
>   regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1);
> -- 
> 2.24.1.735.g03f4e72817-goog
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915/gvt: more locking for ppgtt mm LRU list

[Igor Druzhinin]

When the lock was introduced in 72aabfb862e40 ("drm/i915/gvt: Add mutual
lock for ppgtt mm LRU list") one place got lost.

Signed-off-by: Igor Druzhinin 
---
 drivers/gpu/drm/i915/gvt/gtt.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 34cb404..4a48280 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1956,7 +1956,11 @@ void _intel_vgpu_mm_release(struct kref *mm_ref)
 
if (mm->type == INTEL_GVT_MM_PPGTT) {
list_del(>ppgtt_mm.list);
+
+   mutex_lock(>vgpu->gvt->gtt.ppgtt_mm_lock);
list_del(>ppgtt_mm.lru_list);
+   mutex_unlock(>vgpu->gvt->gtt.ppgtt_mm_lock);
+
invalidate_ppgtt_mm(mm);
} else {
vfree(mm->ggtt_mm.virtual_ggtt);
-- 
2.7.4

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

Re: [PATCH -next] drm/panfrost: Remove set but not used variable 'bo'

[Alyssa Rosenzweig]

Reviewed-by: Alyssas Rosenzweig , thank
you!

On Mon, Feb 03, 2020 at 03:27:24PM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/gpu/drm/panfrost/panfrost_job.c: In function 'panfrost_job_cleanup':
> drivers/gpu/drm/panfrost/panfrost_job.c:278:31: warning:
>  variable 'bo' set but not used [-Wunused-but-set-variable]
> 
> commit bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem_mapping concept")
> involved this unused variable.
> 
> Reported-by: Hulk Robot 
> Signed-off-by: YueHaibing 
> ---
>  drivers/gpu/drm/panfrost/panfrost_job.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
> b/drivers/gpu/drm/panfrost/panfrost_job.c
> index 7c36ec675b73..ccb8546a9342 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> @@ -275,12 +275,8 @@ static void panfrost_job_cleanup(struct kref *ref)
>   }
>  
>   if (job->bos) {
> - struct panfrost_gem_object *bo;
> -
> - for (i = 0; i < job->bo_count; i++) {
> - bo = to_panfrost_bo(job->bos[i]);
> + for (i = 0; i < job->bo_count; i++)
>   drm_gem_object_put_unlocked(job->bos[i]);
> - }
>  
>   kvfree(job->bos);
>   }
> 
> 
> 


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

Re: [PATCH v3 4/9] drm/bridge: ti-sn65dsi86: Config number of DP lanes Mo' Betta

[Bjorn Andersson]

On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:

> The driver used to say that the value to program into bridge register
> 0x93 was dp_lanes - 1.  Looking at the datasheet for the bridge, this
> is wrong.  The data sheet says:
> * 1 = 1 lane
> * 2 = 2 lanes
> * 3 = 4 lanes
> 
> A more proper way to express this encoding is min(dp_lanes, 3).
> 
> At the moment this change has zero effect because we've hardcoded the
> number of DP lanes to 4.  ...and (4 - 1) == min(4, 3).  How fortunate!
> ...but soon we'll stop hardcoding the number of lanes.
> 
> Signed-off-by: Douglas Anderson 
> Tested-by: Rob Clark 
> Reviewed-by: Rob Clark 

Reviewed-by: Bjorn Andersson 

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index ab644baaf90c..d55d19759796 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -523,7 +523,7 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
>  CHA_DSI_LANES_MASK, val);
>  
>   /* DP lane config */
> - val = DP_NUM_LANES(pdata->dp_lanes - 1);
> + val = DP_NUM_LANES(min(pdata->dp_lanes, 3));
>   regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG, DP_NUM_LANES_MASK,
>  val);
>  
> -- 
> 2.24.1.735.g03f4e72817-goog
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/dp_mst: Check crc4 value while building sideband message

[Benjamin Gaignard]

Check that computed crc value is matching the one encoded in the message.

Signed-off-by: Benjamin Gaignard 
---
CC: ly...@redhat.com
CC: airl...@linux.ie
CC: jani.nik...@linux.intel.com
 drivers/gpu/drm/drm_dp_mst_topology.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 822d2f177f90..eee899d6742b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -736,6 +736,10 @@ static bool drm_dp_sideband_msg_build(struct 
drm_dp_sideband_msg_rx *msg,
if (msg->curchunk_idx >= msg->curchunk_len) {
/* do CRC */
crc4 = drm_dp_msg_data_crc4(msg->chunk, msg->curchunk_len - 1);
+   if (crc4 != msg->chunk[msg->curchunk_len - 1])
+   print_hex_dump(KERN_DEBUG, "wrong crc",
+  DUMP_PREFIX_NONE, 16, 1,
+  msg->chunk,  msg->curchunk_len, false);
/* copy chunk into bigger msg */
memcpy(>msg[msg->curlen], msg->chunk, msg->curchunk_len - 
1);
msg->curlen += msg->curchunk_len - 1;
-- 
2.15.0

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

Re: [PATCH v3 2/9] drm/bridge: ti-sn65dsi86: zero is never greater than an unsigned int

[Bjorn Andersson]

On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:

> When we iterate over ti_sn_bridge_dp_rate_lut, there's no reason to
> start at index 0 which always contains the value 0.  0 is not a valid
> link rate.
> 
> This change should have no real effect but is a small cleanup.
> 
> Signed-off-by: Douglas Anderson 
> Tested-by: Rob Clark 
> Reviewed-by: Rob Clark 

Reviewed-by: Bjorn Andersson 

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 2fb9370a76e6..7b596af265e4 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -458,7 +458,7 @@ static void ti_sn_bridge_set_dp_rate(struct ti_sn_bridge 
> *pdata)
>   /* set DP data rate */
>   dp_rate_mhz = ((bit_rate_mhz / pdata->dsi->lanes) * DP_CLK_FUDGE_NUM) /
>   DP_CLK_FUDGE_DEN;
> - for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++)
> + for (i = 1; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++)
>   if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
>   break;
>  
> -- 
> 2.24.1.735.g03f4e72817-goog
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/9] drm/bridge: ti-sn65dsi86: Improve support for AUO B116XAK01 + other DP

[Bjorn Andersson]

On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:

> This series contains a pile of patches that was created to support
> hooking up the AUO B116XAK01 panel to the eDP side of the bridge.  In
> general it should be useful for hooking up a wider variety of DP
> panels to the bridge, especially those with lower resolution and lower
> bits per pixel.
> 
> The overall result of this series:
> * Allows panels with fewer than 4 DP lanes hooked up to work.
> * Optimizes the link rate for panels with 6 bpp.
> * Supports trying more than one link rate when training if the main
>   link rate didn't work.
> * Avoids invalid link rates.
> 
> It's not expected that this series will break any existing users but
> testing is always good.
> 
> To support the AUO B116XAK01, we could actually stop at the ("Use
> 18-bit DP if we can") patch since that causes the panel to run at a
> link rate of 1.62 which works.  The patches to try more than one link
> rate were all developed prior to realizing that I could just use
> 18-bit mode and were validated with that patch reverted.
> 
> These patches were tested on sdm845-cheza atop mainline as of
> 2019-12-13 and also on another board (the one with AUO B116XAK01) atop
> a downstream kernel tree.
> 
> This patch series doesn't do anything to optimize the MIPI link and
> only focuses on the DP link.  For instance, it's left as an exercise
> to the reader to see if we can use the 666-packed mode on the MIPI
> link and save some power (because we could lower the clock rate).
> 
> I am nowhere near a display expert and my knowledge of DP and MIPI is
> pretty much zero.  If something about this patch series smells wrong,
> it probably is.  Please let know and I'll try to fix it.
> 

Thanks for the patches Doug, this fixes the rate and DP lane-count
issues I'm seeing on my Lenovo Yoga C630 with the current
implementation.

Tested-by: Bjorn Andersson 

Regards,
Bjorn

> Changes in v3:
> - Init rate_valid table, don't rely on stack being 0 (oops).
> - Rename rate_times_200khz to rate_per_200khz.
> - Loop over the ti_sn_bridge_dp_rate_lut table, making code smaller.
> - Use 'true' instead of 1 for bools.
> - Added note to commit message noting DP 1.4+ isn't well tested.
> 
> Changes in v2:
> - Squash in maybe-uninitialized fix from Rob Clark.
> - Patch ("Avoid invalid rates") replaces ("Skip non-standard DP rates")
> 
> Douglas Anderson (9):
>   drm/bridge: ti-sn65dsi86: Split the setting of the dp and dsi rates
>   drm/bridge: ti-sn65dsi86: zero is never greater than an unsigned int
>   drm/bridge: ti-sn65dsi86: Don't use MIPI variables for DP link
>   drm/bridge: ti-sn65dsi86: Config number of DP lanes Mo' Betta
>   drm/bridge: ti-sn65dsi86: Read num lanes from the DP sink
>   drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can
>   drm/bridge: ti-sn65dsi86: Group DP link training bits in a function
>   drm/bridge: ti-sn65dsi86: Train at faster rates if slower ones fail
>   drm/bridge: ti-sn65dsi86: Avoid invalid rates
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 259 +-
>  1 file changed, 216 insertions(+), 43 deletions(-)
> 
> -- 
> 2.24.1.735.g03f4e72817-goog
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/1] drm: sun4i: hdmi: Add support for sun4i HDMI encoder audio

[Maxime Ripard]

Hi,

On Thu, Jan 30, 2020 at 08:20:55AM +0200, Stefan Mavrodiev wrote:
> On 1/29/20 6:43 PM, Maxime Ripard wrote:
> > On Tue, Jan 28, 2020 at 04:06:42PM +0200, Stefan Mavrodiev wrote:
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
> > > b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> > > index 68d4644ac2dc..4cd35c97c503 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> > > @@ -23,6 +23,8 @@
> > >   #include 
> > >   #include 
> > >
> > > +#include 
> > > +
> > >   #include "sun4i_backend.h"
> > >   #include "sun4i_crtc.h"
> > >   #include "sun4i_drv.h"
> > > @@ -87,6 +89,10 @@ static void sun4i_hdmi_disable(struct drm_encoder 
> > > *encoder)
> > >
> > >   DRM_DEBUG_DRIVER("Disabling the HDMI Output\n");
> > >
> > > +#ifdef CONFIG_DRM_SUN4I_HDMI_AUDIO
> > > + sun4i_hdmi_audio_destroy(hdmi);
> > > +#endif
> > > +
> > >   val = readl(hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
> > >   val &= ~SUN4I_HDMI_VID_CTRL_ENABLE;
> > >   writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
> > > @@ -114,6 +120,11 @@ static void sun4i_hdmi_enable(struct drm_encoder 
> > > *encoder)
> > >   val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE;
> > >
> > >   writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
> > > +
> > > +#ifdef CONFIG_DRM_SUN4I_HDMI_AUDIO
> > > + if (hdmi->hdmi_audio && sun4i_hdmi_audio_create(hdmi))
> > > + DRM_ERROR("Couldn't create the HDMI audio adapter\n");
> > > +#endif
> > I really don't think we should be creating / removing the audio card
> > at enable / disable time.
>
> For me it's unnatural to have sound card all the time, even when the HDMI
> is not plugged-in.

It's also a matter of being consistent: pretty much everyone else is
doing it:
  * vc4 (RaspberryPi)

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_hdmi.c#L1437

  * omap

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/dss/hdmi4.c#L620

  * sti

https://elixir.bootlin.com/linux/v5.5.1/source/drivers/gpu/drm/sti/sti_hdmi.c#L1310

  * msm

https://elixir.bootlin.com/linux/v5.5.1/source/drivers/gpu/drm/msm/hdmi/hdmi.c#L597

etc...

If we were to think about this at a more theorical level though, it's
pretty much the same case than having a sound card but no headphone
attached, or having a display engine but no display attached. In both
case, you register the driver before having a sink, you just let the
userspace know that there's nothing connected on the other end.

Maxime


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

[PATCH v2] drm/radeon: have the callers of set_memory_*() check the return value

[Tianlin Li]

Right now several architectures allow their set_memory_*() family of  
functions to fail, but callers may not be checking the return values.
If set_memory_*() returns with an error, call-site assumptions may be
infact wrong to assume that it would either succeed or not succeed at  
all. Ideally, the failure of set_memory_*() should be passed up the 
call stack, and callers should examine the failure and deal with it. 

Need to fix the callers and add the __must_check attribute. They also 
may not provide any level of atomicity, in the sense that the memory 
protections may be left incomplete on failure. This issue likely has a 
few steps on effects architectures:
1)Have all callers of set_memory_*() helpers check the return value.
2)Add __must_check to all set_memory_*() helpers so that new uses do  
not ignore the return value.
3)Add atomicity to the calls so that the memory protections aren't left 
in a partial state.

This series is part of step 1. Make drm/radeon check the return value of  
set_memory_*().

Signed-off-by: Tianlin Li 
---
v2:
The hardware is too old to be tested on and the code cannot be simply
removed from the kernel, so this is the solution for the short term. 
- Just print an error when something goes wrong
- Remove patch 2.  
v1:
https://lore.kernel.org/lkml/20200107192555.20606-1-...@digitalocean.com/
---
 drivers/gpu/drm/radeon/radeon_gart.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index f178ba321715..a2cc864aa08d 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -80,8 +80,9 @@ int radeon_gart_table_ram_alloc(struct radeon_device *rdev)
 #ifdef CONFIG_X86
if (rdev->family == CHIP_RS400 || rdev->family == CHIP_RS480 ||
rdev->family == CHIP_RS690 || rdev->family == CHIP_RS740) {
-   set_memory_uc((unsigned long)ptr,
- rdev->gart.table_size >> PAGE_SHIFT);
+   if (set_memory_uc((unsigned long)ptr,
+ rdev->gart.table_size >> PAGE_SHIFT))
+   DRM_ERROR("set_memory_uc failed.\n");
}
 #endif
rdev->gart.ptr = ptr;
@@ -106,8 +107,9 @@ void radeon_gart_table_ram_free(struct radeon_device *rdev)
 #ifdef CONFIG_X86
if (rdev->family == CHIP_RS400 || rdev->family == CHIP_RS480 ||
rdev->family == CHIP_RS690 || rdev->family == CHIP_RS740) {
-   set_memory_wb((unsigned long)rdev->gart.ptr,
- rdev->gart.table_size >> PAGE_SHIFT);
+   if (set_memory_wb((unsigned long)rdev->gart.ptr,
+ rdev->gart.table_size >> PAGE_SHIFT))
+   DRM_ERROR("set_memory_wb failed.\n");
}
 #endif
pci_free_consistent(rdev->pdev, rdev->gart.table_size,
-- 
2.17.1

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

Re: [PATCH v3 8/9] drm/bridge: ti-sn65dsi86: Train at faster rates if slower ones fail

[Bjorn Andersson]

On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:

> If we fail training at a lower DP link rate let's now keep trying
> until we run out of rates to try.  Basically the algorithm here is to
> start at the link rate that is the theoretical minimum and then slowly
> bump up until we run out of rates or hit the max rate of the sink.  We
> query the sink using a DPCD read.
> 
> This is, in fact, important in practice.  Specifically at least one
> panel hooked up to the bridge (AUO B116XAK01) had a theoretical min
> rate more than 1.62 GHz (if run at 24 bpp) and fails to train at the
> next rate (2.16 GHz).  It would train at 2.7 GHz, though.
> 
> Signed-off-by: Douglas Anderson 
> Tested-by: Rob Clark 
> Reviewed-by: Rob Clark 

Reviewed-by: Bjorn Andersson 

> ---
> 
> Changes in v3: None
> Changes in v2:
> - Squash in maybe-uninitialized fix from Rob Clark.
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 71 ++-
>  1 file changed, 60 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 48fb4dc72e1c..e1b817ccd9c7 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -454,7 +454,7 @@ static const unsigned int ti_sn_bridge_dp_rate_lut[] = {
>   0, 1620, 2160, 2430, 2700, 3240, 4320, 5400
>  };
>  
> -static void ti_sn_bridge_set_dp_rate(struct ti_sn_bridge *pdata)
> +static int ti_sn_bridge_calc_min_dp_rate_idx(struct ti_sn_bridge *pdata)
>  {
>   unsigned int bit_rate_khz, dp_rate_mhz;
>   unsigned int i;
> @@ -472,8 +472,42 @@ static void ti_sn_bridge_set_dp_rate(struct ti_sn_bridge 
> *pdata)
>   if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
>   break;
>  
> - regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
> -DP_DATARATE_MASK, DP_DATARATE(i));
> + return i;
> +}
> +
> +static int ti_sn_bridge_get_max_dp_rate_idx(struct ti_sn_bridge *pdata)
> +{
> + u8 data;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(>aux, DP_MAX_LINK_RATE, );
> + if (ret != 1) {
> + DRM_DEV_ERROR(pdata->dev,
> +   "Can't read max rate (%d); assuming 5.4 GHz\n",
> +   ret);
> + return ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1;
> + }
> +
> + /*
> +  * Return an index into ti_sn_bridge_dp_rate_lut.  Just hardcode
> +  * these indicies since it's not like the register spec is ever going
> +  * to change and a loop would just be more complicated.  Apparently
> +  * the DP sink can only return these few rates as supported even
> +  * though the bridge allows some rates in between.
> +  */
> + switch (data) {
> + case DP_LINK_BW_1_62:
> + return 1;
> + case DP_LINK_BW_2_7:
> + return 4;
> + case DP_LINK_BW_5_4:
> + return 7;
> + }
> +
> + DRM_DEV_ERROR(pdata->dev,
> +   "Unexpected max data rate (%#x); assuming 5.4 GHz\n",
> +   (int)data);
> + return ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1;
>  }
>  
>  static void ti_sn_bridge_set_video_timings(struct ti_sn_bridge *pdata)
> @@ -530,13 +564,15 @@ static unsigned int ti_sn_get_max_lanes(struct 
> ti_sn_bridge *pdata)
>   return data & DP_LANE_COUNT_MASK;
>  }
>  
> -static int ti_sn_link_training(struct ti_sn_bridge *pdata)
> +static int ti_sn_link_training(struct ti_sn_bridge *pdata, int dp_rate_idx,
> +const char **last_err_str)
>  {
>   unsigned int val;
>   int ret;
>  
>   /* set dp clk frequency value */
> - ti_sn_bridge_set_dp_rate(pdata);
> + regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
> +DP_DATARATE_MASK, DP_DATARATE(dp_rate_idx));
>  
>   /* enable DP PLL */
>   regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1);
> @@ -545,7 +581,7 @@ static int ti_sn_link_training(struct ti_sn_bridge *pdata)
>  val & DPPLL_SRC_DP_PLL_LOCK, 1000,
>  50 * 1000);
>   if (ret) {
> - DRM_ERROR("DP_PLL_LOCK polling failed (%d)\n", ret);
> + *last_err_str = "DP_PLL_LOCK polling failed";
>   goto exit;
>   }
>  
> @@ -556,9 +592,9 @@ static int ti_sn_link_training(struct ti_sn_bridge *pdata)
>  val == ML_TX_NORMAL_MODE, 1000,
>  500 * 1000);
>   if (ret) {
> - DRM_ERROR("Training complete polling failed (%d)\n", ret);
> + *last_err_str = "Training complete polling failed";
>   } else if (val == ML_TX_MAIN_LINK_OFF) {
> - DRM_ERROR("Link training failed, link is off\n");
> + *last_err_str = "Link training failed, link is off";
>   ret = -EIO;
>   }
>  
> @@ -573,8 +609,11 @@ static int 

Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can

[Bjorn Andersson]

On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:

> The current bridge driver always forced us to use 24 bits per pixel
> over the DP link.  This is a waste if you are hooked up to a panel
> that only supports 6 bits per color or fewer, since in that case you
> ran run at 18 bits per pixel and thus end up at a lower DP clock rate.

s/ran/can/

> 
> Let's support this.
> 
> While at it, let's clean up the math in the function to avoid rounding
> errors (and round in the correct direction when we have to round).
> Numbers are sufficiently small (because mode->clock is in kHz) that we
> don't need to worry about integer overflow.
> 
> Signed-off-by: Douglas Anderson 
> Tested-by: Rob Clark 
> Reviewed-by: Rob Clark 

Reviewed-by: Bjorn Andersson 

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 27 ++-
>  1 file changed, 18 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 0fc9e97b2d98..d5990a0947b9 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -51,6 +51,7 @@
>  #define SN_ENH_FRAME_REG 0x5A
>  #define  VSTREAM_ENABLE  BIT(3)
>  #define SN_DATA_FORMAT_REG   0x5B
> +#define  BPP_18_RGB  BIT(0)
>  #define SN_HPD_DISABLE_REG   0x5C
>  #define  HPD_DISABLE BIT(0)
>  #define SN_AUX_WDATA_REG(x)  (0x64 + (x))
> @@ -436,6 +437,14 @@ static void ti_sn_bridge_set_dsi_rate(struct 
> ti_sn_bridge *pdata)
>   regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
>  }
>  
> +static unsigned int ti_sn_bridge_get_bpp(struct ti_sn_bridge *pdata)
> +{
> + if (pdata->connector.display_info.bpc <= 6)
> + return 18;
> + else
> + return 24;
> +}
> +
>  /**
>   * LUT index corresponds to register value and
>   * LUT values corresponds to dp data rate supported
> @@ -447,21 +456,17 @@ static const unsigned int ti_sn_bridge_dp_rate_lut[] = {
>  
>  static void ti_sn_bridge_set_dp_rate(struct ti_sn_bridge *pdata)
>  {
> - unsigned int bit_rate_mhz, dp_rate_mhz;
> + unsigned int bit_rate_khz, dp_rate_mhz;
>   unsigned int i;
>   struct drm_display_mode *mode =
>   >bridge.encoder->crtc->state->adjusted_mode;
>  
> - /*
> -  * Calculate minimum bit rate based on our pixel clock.  At
> -  * the moment this driver never sets the DP_18BPP_EN bit in
> -  * register 0x5b so we hardcode 24bpp.
> -  */
> - bit_rate_mhz = (mode->clock / 1000) * 24;
> + /* Calculate minimum bit rate based on our pixel clock. */
> + bit_rate_khz = mode->clock * ti_sn_bridge_get_bpp(pdata);
>  
>   /* Calculate minimum DP data rate, taking 80% as per DP spec */
> - dp_rate_mhz = ((bit_rate_mhz / pdata->dp_lanes) * DP_CLK_FUDGE_NUM) /
> - DP_CLK_FUDGE_DEN;
> + dp_rate_mhz = DIV_ROUND_UP(bit_rate_khz * DP_CLK_FUDGE_NUM,
> +1000 * pdata->dp_lanes * DP_CLK_FUDGE_DEN);
>  
>   for (i = 1; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++)
>   if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
> @@ -550,6 +555,10 @@ static void ti_sn_bridge_enable(struct drm_bridge 
> *bridge)
>   regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
>  CHA_DSI_LANES_MASK, val);
>  
> + /* Set the DP output format (18 bpp or 24 bpp) */
> + val = (ti_sn_bridge_get_bpp(pdata) == 18) ? BPP_18_RGB : 0;
> + regmap_update_bits(pdata->regmap, SN_DATA_FORMAT_REG, BPP_18_RGB, val);
> +
>   /* DP lane config */
>   val = DP_NUM_LANES(min(pdata->dp_lanes, 3));
>   regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG, DP_NUM_LANES_MASK,
> -- 
> 2.24.1.735.g03f4e72817-goog
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] crypto: ccree - remove set but not used variable 'du_size'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/crypto/ccree/cc_cipher.c: In function 'cc_setup_state_desc':
drivers/crypto/ccree/cc_cipher.c:536:15: warning:
 variable 'du_size' set but not used [-Wunused-but-set-variable]

commit 5c83e8ec4d51 ("crypto: ccree - fix FDE descriptor sequence")
involved this unused variable, so remove it.

Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
---
 drivers/crypto/ccree/cc_cipher.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/crypto/ccree/cc_cipher.c b/drivers/crypto/ccree/cc_cipher.c
index 7d6252d892d7..b5133f57bc87 100644
--- a/drivers/crypto/ccree/cc_cipher.c
+++ b/drivers/crypto/ccree/cc_cipher.c
@@ -533,14 +533,6 @@ static void cc_setup_state_desc(struct crypto_tfm *tfm,
int flow_mode = ctx_p->flow_mode;
int direction = req_ctx->gen_ctx.op_type;
dma_addr_t iv_dma_addr = req_ctx->gen_ctx.iv_dma_addr;
-   unsigned int du_size = nbytes;
-
-   struct cc_crypto_alg *cc_alg =
-   container_of(tfm->__crt_alg, struct cc_crypto_alg,
-skcipher_alg.base);
-
-   if (cc_alg->data_unit)
-   du_size = cc_alg->data_unit;
 
switch (cipher_mode) {
case DRV_CIPHER_ECB:



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

Re: [git pull] drm ttm/mm for 5.6-rc1

[pr-tracker-bot]

The pull request you sent on Tue, 4 Feb 2020 09:26:45 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-02-04

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9717c1cea16e3eae81ca226f4c3670bb799b61ad

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel