[Bug 199157] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000

[bugzilla-daemon]

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

--- Comment #5 from Kyle De'Vir (kyle.de...@mykolab.com) ---
This is the first time I've seen it happening on DC, so I decided to just throw
it up as bug report.

At the time, I was browsing on Firefox Nightly, while listening to some music
with MPV. My desktop is Plasma Shell with KWin on X11, which is heavy on OpenGL
usage. I've been running the git versions of Radeon Profile and Radeon Profile
Daemon, which autostart when Plasma Shell does.

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

Re: [PATCH] drm/scdc-helper: Convert errors into debug messages

[Sharma, Shashank]

Reviewed-by: Shashank Sharma 

Regards
Shashank
On 3/23/2018 11:55 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Since we may attempt to reconfigure SCDC when the sink has already been
disconnected we probably shouldn't scare the user with errors in dmesg
that are 100% expected in that case. Just leave it up to the caller
whether to print an error message or not, and just output debug
messages from the helper itself.

Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_scdc_helper.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
index 657ea5ab6c3f..870e25f1f788 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -141,7 +141,7 @@ bool drm_scdc_get_scrambling_status(struct i2c_adapter 
*adapter)
  
  	ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, );

if (ret < 0) {
-   DRM_ERROR("Failed to read scrambling status: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to read scrambling status: %d\n", ret);
return false;
}
  
@@ -168,7 +168,7 @@ bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, bool enable)
  
  	ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );

if (ret < 0) {
-   DRM_ERROR("Failed to read TMDS config: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to read TMDS config: %d\n", ret);
return false;
}
  
@@ -179,7 +179,7 @@ bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, bool enable)
  
  	ret = drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config);

if (ret < 0) {
-   DRM_ERROR("Failed to enable scrambling: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to enable scrambling: %d\n", ret);
return false;
}
  
@@ -223,7 +223,7 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct i2c_adapter *adapter, bool set)
  
  	ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );

if (ret < 0) {
-   DRM_ERROR("Failed to read TMDS config: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to read TMDS config: %d\n", ret);
return false;
}
  
@@ -234,7 +234,7 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct i2c_adapter *adapter, bool set)
  
  	ret = drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config);

if (ret < 0) {
-   DRM_ERROR("Failed to set TMDS clock ratio: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to set TMDS clock ratio: %d\n", ret);
return false;
}
  


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

[Bug 105712] intel-gpu-overlay is showing insane power consumption amounts

[bugzilla-daemon]

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

--- Comment #8 from leozinho29...@hotmail.com ---
$ sudo cat /sys/devices/power/events/energy-gpu.scale
2.3283064365386962890625e-10

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

[Bug 105712] intel-gpu-overlay is showing insane power consumption amounts

[bugzilla-daemon]

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

--- Comment #7 from Chris Wilson  ---
And for completeness:  cat /sys/devices/power/events/energy-gpu.scale

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

Re: [PATCH v2] drm/etnaviv: init DMA ops for virtual master device

[kbuild test robot]

Hi Lucas,

I love your patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20180323]
[cannot apply to v4.16-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Lucas-Stach/drm-etnaviv-init-DMA-ops-for-virtual-master-device/20180324-045537
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> ERROR: "arch_setup_dma_ops" [drivers/gpu/drm/etnaviv/etnaviv.ko] undefined!

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


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

[Bug 105712] intel-gpu-overlay is showing insane power consumption amounts

[bugzilla-daemon]

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

--- Comment #6 from leozinho29...@hotmail.com ---
The lines

fprintf(stderr, "rapl_type_id()=%"PRIx64",
rapl_gpu_power()=%"PRIx64"\n",
rapl_type_id(), rapl_gpu_power());

made the overlay fail to build. I have changed that to (using lx is not
perfect, but PRIx64 made it fail to build):

fprintf(stderr, "rapl_type_id()=%lx\n",rapl_type_id());
fprintf(stderr, "rapl_gpu_power()=%lx\n",rapl_gpu_power());

which should result in the intended output. It was:

rapl_type_id()=d
rapl_gpu_power()=4
rapl_gpu_power_scale()=2,00

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

[Bug 105712] intel-gpu-overlay is showing insane power consumption amounts

[bugzilla-daemon]

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

--- Comment #5 from Chris Wilson  ---
Add a couple of printfs,

diff --git a/overlay/power.c b/overlay/power.c
index 9ac90fde..e6ac728a 100644
--- a/overlay/power.c
+++ b/overlay/power.c
@@ -117,8 +117,12 @@ int power_init(struct power *power)
memset(power, 0, sizeof(*power));

power->fd = igt_perf_open(rapl_type_id(), rapl_gpu_power());
+   fprintf(stderr, "rapl_type_id()=%"PRIx64",
rapl_gpu_power()=%"PRIx64"\n",
+   rapl_type_id(), rapl_gpu_power());
if (power->fd >= 0) {
power->rapl_scale = rapl_gpu_power_scale();
+   fprintf(stderr, "rapl_gpu_power_scale()=%f\n",
+   rapl_gpu_power_scale());

if (power->rapl_scale != NAN) {
power->rapl_scale *= 1e3; /* from nano to micro */

and run with -f (so that it doesn't detach and we can see the output).

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

Re: [PATCH v6] ARM: dts: wheat: Fix ADV7513 address usage

[Kieran Bingham]

Hi Simon,

On 23/03/18 08:51, Simon Horman wrote:
> On Thu, Mar 22, 2018 at 09:30:40PM +, Kieran Bingham wrote:
>> The r8a7792 Wheat board has two ADV7513 devices sharing a single I2C
>> bus, however in low power mode the ADV7513 will reset it's slave maps to
>> use the hardware defined default addresses.
>>
>> The ADV7511 driver was adapted to allow the two devices to be registered
>> correctly - but it did not take into account the fault whereby the
>> devices reset the addresses.
>>
>> This results in an address conflict between the device using the default
>> addresses, and the other device if it is in low-power-mode.
>>
>> Repair this issue by moving both devices away from the default address
>> definitions.
> 
> Hi Kierean,
> 
> as this is a fix
> a) Does it warrant a fixes tag?
>Fixes: f6eea82a87db ("ARM: dts: wheat: add DU support")
> b) Does it warrant being posted as a fix for v4.16;
> c) or v4.17?

Tricky one, yes it could but this DTS fix, will only actually 'fix' the issue if
the corresponding driver updates to allow secondary addresses to be parsed are
also backported.

It should be safe to back port the dts fix without the driver updates, but the
addresses specified by this patch will simply be ignored.

Thus if this is marked with the fixes tag the corresponding patch "drm: adv7511:
Add support for i2c_new_secondary_device" should also be marked.

It looks like that patch has yet to be picked up by the DRM subsystem, so how
about I bundle both of these two patches together in a repost along with the
fixes tag.

In fact, I don't think the ADV7511 dt-bindings update has made any progress
either. (dt-bindings: adv7511: Extend bindings to allow specifying slave map
addresses). The media tree variants for the adv7604 have already been picked up
by Mauro I believe though.

I presume it would be acceptable for this dts patch (or rather all three patches
mentioned) to get integrated through the DRM tree ?

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

[Bug 105712] intel-gpu-overlay is showing insane power consumption amounts

[bugzilla-daemon]

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

--- Comment #4 from leozinho29...@hotmail.com ---
With this change it is showing the values as expected, 350 mW instead of
35000 mW.

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

[Bug 105712] intel-gpu-overlay is showing insane power consumption amounts

[bugzilla-daemon]

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

--- Comment #3 from Chris Wilson  ---
Ok, try changing intel-gpu-tools:

diff --git a/overlay/power.c b/overlay/power.c
index 9ac90fde..e02edec8 100644
--- a/overlay/power.c
+++ b/overlay/power.c
@@ -116,7 +116,8 @@ int power_init(struct power *power)

memset(power, 0, sizeof(*power));

-   power->fd = igt_perf_open(rapl_type_id(), rapl_gpu_power());
+   power->fd = -1;
+   //power->fd = igt_perf_open(rapl_type_id(), rapl_gpu_power());
if (power->fd >= 0) {
power->rapl_scale = rapl_gpu_power_scale();

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

Re: [PATCH 16/23] drm/amdgpu/dc: Stop updating plane->fb

[Harry Wentland]

On 2018-03-22 11:23 AM, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We want to get rid of plane->fb on atomic drivers. Stop setting it.
> 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: Harry Wentland 
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Harry Wentland 

Patches 1-8 & 15 also look reasonable to me, but I'm not an expert on this. 
Feel free to add my
Acked-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
>  1 file changed, 2 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 ae512ecb65ee..a8129eca6e6d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3941,8 +3941,6 @@ static void amdgpu_dm_do_flip(struct drm_crtc *crtc,
>  
>   /* Flip */
>   spin_lock_irqsave(>dev->event_lock, flags);
> - /* update crtc fb */
> - crtc->primary->fb = fb;
>  
>   WARN_ON(acrtc->pflip_status != AMDGPU_FLIP_NONE);
>   WARN_ON(!acrtc_state->stream);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105718] amdgpu reported fan speed looks too high (dual fan Sapphire Pulse Vega 56)

[bugzilla-daemon]

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

Shmerl  changed:

   What|Removed |Added

 OS|All |Linux (All)

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

[Bug 105712] intel-gpu-overlay is showing insane power consumption amounts

[bugzilla-daemon]

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

--- Comment #2 from leozinho29...@hotmail.com ---
I suppose drm-tip is this: https://cgit.freedesktop.org/drm-tip

I have tried to use that kernel but intel-gpu-overlay is still showing the
super high values. Both older versions of intel-gpu-overlay and turbostat show
sane values.

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

[PATCH] drm/scdc-helper: Convert errors into debug messages

[Ville Syrjala]

From: Ville Syrjälä 

Since we may attempt to reconfigure SCDC when the sink has already been
disconnected we probably shouldn't scare the user with errors in dmesg
that are 100% expected in that case. Just leave it up to the caller
whether to print an error message or not, and just output debug
messages from the helper itself.

Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_scdc_helper.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
index 657ea5ab6c3f..870e25f1f788 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -141,7 +141,7 @@ bool drm_scdc_get_scrambling_status(struct i2c_adapter 
*adapter)
 
ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, );
if (ret < 0) {
-   DRM_ERROR("Failed to read scrambling status: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to read scrambling status: %d\n", ret);
return false;
}
 
@@ -168,7 +168,7 @@ bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, 
bool enable)
 
ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );
if (ret < 0) {
-   DRM_ERROR("Failed to read TMDS config: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to read TMDS config: %d\n", ret);
return false;
}
 
@@ -179,7 +179,7 @@ bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, 
bool enable)
 
ret = drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config);
if (ret < 0) {
-   DRM_ERROR("Failed to enable scrambling: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to enable scrambling: %d\n", ret);
return false;
}
 
@@ -223,7 +223,7 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct i2c_adapter 
*adapter, bool set)
 
ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );
if (ret < 0) {
-   DRM_ERROR("Failed to read TMDS config: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to read TMDS config: %d\n", ret);
return false;
}
 
@@ -234,7 +234,7 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct i2c_adapter 
*adapter, bool set)
 
ret = drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config);
if (ret < 0) {
-   DRM_ERROR("Failed to set TMDS clock ratio: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to set TMDS clock ratio: %d\n", ret);
return false;
}
 
-- 
2.16.1

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

[PATCH 1/2] dt-bindings: msm/disp: Remove DPU RSC device bindings

[Rajesh Yadav]

Display controller's power resources and bus
bandwidth voting is controlled by DPU device.
Remove DPU RSC (hardware block for DPU power
resource control) device support.

Signed-off-by: Rajesh Yadav 
---
 .../devicetree/bindings/display/msm/dpu-rsc.txt| 96 --
 1 file changed, 96 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu-rsc.txt

diff --git a/Documentation/devicetree/bindings/display/msm/dpu-rsc.txt 
b/Documentation/devicetree/bindings/display/msm/dpu-rsc.txt
deleted file mode 100644
index f5fbcda..000
--- a/Documentation/devicetree/bindings/display/msm/dpu-rsc.txt
+++ /dev/null
@@ -1,96 +0,0 @@
-Qualcomm Technologies, Inc. DPU RSC
-
-Snapdragon Display Engine implements display rsc to driver
-display core to different modes for power saving
-
-Required properties
-- compatible:  Must be "qcom,dpu-rsc"
-- reg: Offset and length of the register set for
-   the device.
-- reg-names:   Names to refer to register sets related
-   to this device
-
-Optional properties:
-- clocks:  List of phandles for clock device nodes
-   needed by the device.
-- clock-names: List of clock names needed by the device.
-- vdd-supply:  phandle for vdd regulator device node.
-- qcom,dpu-rsc-version:U32 property represents the rsc 
version. It helps to
-   select correct sequence for dpu rsc based on 
version.
-- qcom,dpu-dram-channels:  U32 property represents the number of channels 
in the
-   Bus memory controller.
-- qcom,dpu-num-nrt-paths:  U32 property represents the number of 
non-realtime
-   paths in each Bus Scaling Usecase. This value 
depends on
-   number of AXI ports that are dedicated to 
non-realtime VBIF
-   for particular chipset.
-   These paths must be defined after rt-paths in
-   "qcom,msm-bus,vectors-KBps" vector request.
-
-Bus Scaling Subnodes:
-- qcom,dpu-data-bus:   Property to provide Bus scaling for data bus 
access for
-   dpu blocks.
-- qcom,dpu-llcc-bus:   Property to provide Bus scaling for data bus 
access for
-   mnoc to llcc.
-- qcom,dpu-ebi-bus:Property to provide Bus scaling for data bus 
access for
-   llcc to ebi.
-
-Bus Scaling Data:
-- qcom,msm-bus,name:   String property describing client name.
-- qcom,msm-bus,active-only:Boolean context flag for requests in active or
-   dual (active & sleep) contex
-- qcom,msm-bus,num-cases:  This is the number of Bus Scaling use cases
-   defined in the vectors property.
-- qcom,msm-bus,num-paths:  This represents the number of paths in each
-   Bus Scaling Usecase.
-- qcom,msm-bus,vectors-KBps:   * A series of 4 cell properties, with a format
-   of (src, dst, ab, ib) which is defined at
-   
Documentation/devicetree/bindings/arm/msm/msm_bus.txt
-   * Current values of src & dst are defined at
-   include/linux/msm-bus-board.h
-Example:
-   dpu_rscc {
-   cell-index = <0>;
-   compatible = "qcom,dpu-rsc";
-   reg = <0xaf2 0x1c44>,
-   <0xaf3 0x3fd4>;
-   reg-names = "drv", "wrapper";
-   clocks = <_mmss clk_mdss_ahb_clk>,
-   <_mmss clk_mdss_axi_clk>;
-   clock-names = "iface_clk", "bus_clk";
-   vdd-supply = <_mdss>;
-
-   qcom,dpu-rsc-version = <1>;
-   qcom,dpu-dram-channels = <2>;
-   qcom,dpu-num-nrt-paths = <1>;
-
-   qcom,dpu-data-bus {
- qcom,msm-bus,name = "dpu_rsc";
- qcom,msm-bus,active-only;
- qcom,msm-bus,num-cases = <3>;
- qcom,msm-bus,num-paths = <2>;
- qcom,msm-bus,vectors-KBps =
- <22 512 0 0>, <23 512 0 0>,
- <22 512 0 640>, <23 512 0 640>,
- <22 512 0 640>, <23 512 0 640>;
-   };
-   qcom,dpu-llcc-bus {
-   qcom,msm-bus,name = "dpu_rsc_llcc";
-   qcom,msm-bus,active-only;
-   qcom,msm-bus,num-cases = <3>;
-   qcom,msm-bus,num-paths = <1>;
-   qcom,msm-bus,vectors-KBps =
-   <20001 20513 0 0>,
-  

[DPU PATCH 0/2] Remove DPU RSC support

[Rajesh Yadav]

MSM display controller hardware (DPU) has an inbuilt RSC block
which can control power resources and bus bandwidth voting
w/o driver intervention.

Downstream driver relies on RSC hardware block for controlling
these resources for better power benefits.

Since, DPU driver controls these resources, removing RSC support.
Corresponding devicetree binding are also removed in this series.

DPU driver is currently hosted at
  https://gitlab.freedesktop.org/seanpaul/dpu-staging

Rajesh Yadav (2):
  dt-bindings: msm/disp: Remove DPU RSC device bindings
  drm/msm: Remove RSC support from DPU driver

 .../devicetree/bindings/display/msm/dpu-rsc.txt|   96 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  |  130 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h  |6 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |   14 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |9 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  242 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|7 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c |   20 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h |3 -
 drivers/gpu/drm/msm/dpu_dbg.c  |   27 -
 drivers/gpu/drm/msm/dpu_dbg.h  |   10 -
 drivers/gpu/drm/msm/dpu_power_handle.c |   71 +-
 drivers/gpu/drm/msm/dpu_power_handle.h |4 -
 drivers/gpu/drm/msm/dpu_rsc.c  | 1367 
 drivers/gpu/drm/msm/dpu_rsc_hw.c   |  818 
 drivers/gpu/drm/msm/dpu_rsc_priv.h |  191 ---
 include/linux/dpu_rsc.h|  302 -
 18 files changed, 42 insertions(+), 3276 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu-rsc.txt
 delete mode 100644 drivers/gpu/drm/msm/dpu_rsc.c
 delete mode 100644 drivers/gpu/drm/msm/dpu_rsc_hw.c
 delete mode 100644 drivers/gpu/drm/msm/dpu_rsc_priv.h
 delete mode 100644 include/linux/dpu_rsc.h

-- 
The Qualcomm Innovation Center, Inc. is a member of the 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

Re: [PATCH v2 2/2] drivers: remove force dma flag from buses

[kbuild test robot]

Hi Nipun,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc6 next-20180323]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nipun-Gupta/dma-mapping-move-dma-configuration-to-bus-infrastructure/20180323-232307
config: i386-randconfig-x014-201811 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers//bcma/main.c: In function 'bcma_of_fill_device':
>> drivers//bcma/main.c:210:2: error: too many arguments to function 
>> 'of_dma_configure'
 of_dma_configure(>dev, node, false);
 ^~~~
   In file included from include/linux/of_platform.h:12:0,
from drivers//bcma/main.c:17:
   include/linux/of_device.h:110:19: note: declared here
static inline int of_dma_configure(struct device *dev, struct device_node 
*np)
  ^~~~

vim +/of_dma_configure +210 drivers//bcma/main.c

   198  
   199  static void bcma_of_fill_device(struct device *parent,
   200  struct bcma_device *core)
   201  {
   202  struct device_node *node;
   203  
   204  node = bcma_of_find_child_device(parent, core);
   205  if (node)
   206  core->dev.of_node = node;
   207  
   208  core->irq = bcma_of_get_irq(parent, core, 0);
   209  
 > 210  of_dma_configure(>dev, node, false);
   211  }
   212  

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


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

Re: [PATCH 4/4] drm: Add getfb2 ioctl

[Ville Syrjälä]

On Fri, Mar 23, 2018 at 05:00:11PM +, Daniel Stone wrote:
> Hi,
> 
> On 23 March 2018 at 14:49, Ville Syrjälä  
> wrote:
> > On Fri, Mar 23, 2018 at 01:45:52PM +, Daniel Stone wrote:
> >> + for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
> >> + r->handles[i] = 0;
> >> + r->pitches[i] = 0;
> >> + r->offsets[i] = 0;
> >> + r->modifier[i] = DRM_FORMAT_MOD_INVALID;
> >
> > Don't we want to leave this zeroed too? For addfb2 we require any unused
> > modifier to be 0, so if someone does 'getfb2(); addfb2();' they
> > would get an error from the addfb2().
> 
> My thinking is that since the primary userspace for this doesn't have
> symmetry with add (args for add, struct for get), that it was better
> to feed in INVALID directly. This is going to change, e.g., X server
> to:
>   modifier = (fb->flags ? DRM_MODE_FB_MODIFIERS) ? fb->modifier :
> DRM_FORMAT_MOD_INVALID;
> 
> It's a good point about the symmetry though. Do you know of direct
> non-libdrm users? Apart from igt of course ;)

Nope. Just thought that since both take the same struct it'd make some
sense. And figured it could serve as a quick sanity check to make sure
getfb outputs sane data. Or rather, if the driver accepts it back in
it can't be all bad at least.

But if you think it's not a particularly useful thing to do then I'm
certainly willing to accept that.

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

Re: [PATCH 4/4] drm: Add getfb2 ioctl

[Daniel Stone]

Hi,

On 23 March 2018 at 14:49, Ville Syrjälä  wrote:
> On Fri, Mar 23, 2018 at 01:45:52PM +, Daniel Stone wrote:
>> + for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
>> + r->handles[i] = 0;
>> + r->pitches[i] = 0;
>> + r->offsets[i] = 0;
>> + r->modifier[i] = DRM_FORMAT_MOD_INVALID;
>
> Don't we want to leave this zeroed too? For addfb2 we require any unused
> modifier to be 0, so if someone does 'getfb2(); addfb2();' they
> would get an error from the addfb2().

My thinking is that since the primary userspace for this doesn't have
symmetry with add (args for add, struct for get), that it was better
to feed in INVALID directly. This is going to change, e.g., X server
to:
  modifier = (fb->flags ? DRM_MODE_FB_MODIFIERS) ? fb->modifier :
DRM_FORMAT_MOD_INVALID;

It's a good point about the symmetry though. Do you know of direct
non-libdrm users? Apart from igt of course ;)

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

[Bug 105718] amdgpu reported fan speed looks too high (dual fan Sapphire Pulse Vega 56)

[bugzilla-daemon]

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

Bug ID: 105718
   Summary: amdgpu reported fan speed looks too high (dual fan
Sapphire Pulse Vega 56)
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: shtetl...@gmail.com

I have Sapphire Pulse Vega 56, which ships with two fans. According to this:
https://www.youtube.com/watch?v=3mKSrSluxbM=1m25s
in a normal scenario, fans should spin at under 650 RPM. However sensors report
for idle load around 1280 RPM for me, which looks like a double value of the
above:

amdgpu-pci-2f00
Adapter: PCI adapter
fan1: 1281 RPM
temp1: +29.0°C (crit = +0.0°C, hyst = +0.0°C)

pwm1 is set to auto:

sudo cat /sys/class/drm/card0/device/hwmon/hwmon3/pwm1_enable
2

Is this a misdetection, or it's supposed to be like that? Actual fans are
pretty silent.

System: Debian testing, x86_64 (kernel 4.15.4).

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

Re: [RFC] splitting dri-devel to drm core and drivers lists?

[Daniel Vetter]

On Fri, Mar 23, 2018 at 06:22:46PM +0200, Jani Nikula wrote:
> There was some discussion on the dim-tools list about splitting the
> dri-devel list to drm core and drivers lists [1]. Moving the discussion
> to the list in question seems prudent. ;)
> 
> I freely admit I don't have the time or interest in reading the patches
> for other drivers than i915, but I do glance over almost everything
> touching drm core.
> 
> I'd like to encourage i915 developers to stay up to date on what's
> happening in drm core, but the firehose of dri-devel can be a bit
> daunting to handle. From this perspective the S/N on dri-devel is not
> great. YMMV, obviously.
> 
> Feels overkill to require all small drivers to have lists of their own,
> and that would also be counter productive to the ideal that they'd try
> to review each other's work. Hence the idea of having a, say,
> dri-drivers or drm-drivers list.
> 
> Thoughts?

I think especially for small drivers it makes sense to refactor a bit
more, to make them even smaller. The bigger drivers can and do afford to
invent their own dedicated wheels for many things, which make sense. So I
see plenty of benefit in having the small drivers and core bits all in one
huge pool.

There's also the question of whether we should then split drm-misc, and I
think drm-misc as purely the core thing without the small drivers
bandwagon is much less sustainable (because too small). So I'm not sure
splitting drm-misc would be a good idea. And split dri-devel without split
drm-misc is going to be a pain I think.

I think a quick mail filter that marks anything which isn't tagged as the
drm core as read is a good option. It's what I do too. With a bit better
infrastructure we could provide that filter to everyone, but alas, we're
stuck on mailing lists so that's just it.

Wrt encouraging more intel folks to look at what's happening in the drm
core: My cunning plan is to just throw commit rights at a bunch of them,
on average that seems to get the job done. I'll start nominating people as
soon as we have the drm-intel commit right story sorted. I do think we
have quite a pile of people involved in drm core work, that itself isn't a
problem I think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/tinydrm: Make fb_dirty into a lower level hook

[Noralf Trønnes]

Den 23.03.2018 16.35, skrev Ville Syrjala:

From: Ville Syrjälä 

mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us from taking the
plane mutex in fb->dirty() unless we also plumb down the acquire
context.

Instead it seems simpler to split the fb->dirty() into a tinydrm
specific lower level hook that can be called from
mipi_dbi_enable_flush() and from a generic higher level
tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
vfuncs table we'll just stick it into tinydrm_device directly
for now.

v2: Deal with the fb->dirty() in tinydrm_display_pipe_update() as weel (Noralf)

Cc: "Noralf Trønnes" 
Cc: David Lechner 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Noralf Trønnes 
---


Tested mi0823qt which covers core and mipi-dbi:

Tested-by: Noralf Trønnes 


  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30 ++
  drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c|  5 ++---
  drivers/gpu/drm/tinydrm/ili9225.c  | 23 ++--
  drivers/gpu/drm/tinydrm/mi0283qt.c |  2 +-
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 30 ++
  drivers/gpu/drm/tinydrm/repaper.c  | 28 
  drivers/gpu/drm/tinydrm/st7586.c   | 23 ++--
  drivers/gpu/drm/tinydrm/st7735r.c  |  2 +-
  include/drm/tinydrm/mipi-dbi.h |  4 +++-
  include/drm/tinydrm/tinydrm-helpers.h  |  5 +
  include/drm/tinydrm/tinydrm.h  |  4 
  11 files changed, 78 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d1c3ce9ab294..dcd390163a4a 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -78,6 +78,36 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
  }
  EXPORT_SYMBOL(tinydrm_merge_clips);
  
+int tinydrm_fb_dirty(struct drm_framebuffer *fb,

+struct drm_file *file_priv,
+unsigned int flags, unsigned int color,
+struct drm_clip_rect *clips,
+unsigned int num_clips)
+{
+   struct tinydrm_device *tdev = fb->dev->dev_private;
+   struct drm_plane *plane = >pipe.plane;
+   int ret = 0;
+
+   drm_modeset_lock(>mutex, NULL);
+
+   /* fbdev can flush even when we're not interested */
+   if (plane->state->fb == fb) {
+   mutex_lock(>dirty_lock);
+   ret = tdev->fb_dirty(fb, file_priv, flags,
+color, clips, num_clips);
+   mutex_unlock(>dirty_lock);
+   }
+
+   drm_modeset_unlock(>mutex);
+
+   if (ret)
+   dev_err_once(fb->dev->dev,
+"Failed to update display %d\n", ret);
+
+   return ret;
+}
+EXPORT_SYMBOL(tinydrm_fb_dirty);
+
  /**
   * tinydrm_memcpy - Copy clip buffer
   * @dst: Destination buffer
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
index 11ae950b0fc9..e68b528ae64d 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
@@ -125,9 +125,8 @@ void tinydrm_display_pipe_update(struct 
drm_simple_display_pipe *pipe,
struct drm_crtc *crtc = >pipe.crtc;
  
  	if (fb && (fb != old_state->fb)) {

-   pipe->plane.fb = fb;
-   if (fb->funcs->dirty)
-   fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
+   if (tdev->fb_dirty)
+   tdev->fb_dirty(fb, NULL, 0, 0, NULL, 0);
}
  
  	if (crtc->state->event) {

diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index 089d22798c8b..0874e877b111 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -88,14 +88,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
bool full;
void *tr;
  
-	mutex_lock(>dirty_lock);

-
if (!mipi->enabled)
-   goto out_unlock;
-
-   /* fbdev can flush even when we're not interested */
-   if (tdev->pipe.plane.fb != fb)
-   goto out_unlock;
+   return 0;
  
  	full = tinydrm_merge_clips(, clips, num_clips, flags,

   fb->width, fb->height);
@@ -108,7 +102,7 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
tr = mipi->tx_buf;
ret = mipi_dbi_buf_copy(mipi->tx_buf, fb, , swap);
if (ret)
-   goto out_unlock;
+   return ret;
} else {
tr = cma_obj->vaddr;
}
@@ -159,20 +153,13 @@ static int 

[RFC] splitting dri-devel to drm core and drivers lists?

[Jani Nikula]

There was some discussion on the dim-tools list about splitting the
dri-devel list to drm core and drivers lists [1]. Moving the discussion
to the list in question seems prudent. ;)

I freely admit I don't have the time or interest in reading the patches
for other drivers than i915, but I do glance over almost everything
touching drm core.

I'd like to encourage i915 developers to stay up to date on what's
happening in drm core, but the firehose of dri-devel can be a bit
daunting to handle. From this perspective the S/N on dri-devel is not
great. YMMV, obviously.

Feels overkill to require all small drivers to have lists of their own,
and that would also be counter productive to the ideal that they'd try
to review each other's work. Hence the idea of having a, say,
dri-drivers or drm-drivers list.

Thoughts?

BR,
Jani.

[1] http://mid.mail-archive.com/87d0zwicfq.fsf@intel.com

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

[PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[matthew . s . atwood]

From: Matt Atwood 

DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.

With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.

To avoid breaking panels that are not spec compiant we now warn on
invalid values.

V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
V6: print statement revisions, DP_REV to DPCD_REV, comment correction
V7: typo
V8: Style

Signed-off-by: Matt Atwood 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_dp_helper.c | 22 ++
 include/drm/drm_dp_helper.h |  6 ++
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..6bee2df 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,32 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
+ rd_interval);
+
+   if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DPCD_REV_14)
udelay(100);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
+ rd_interval);
+
+   if (rd_interval == 0)
udelay(400);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..8c59ce4 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
 /* AUX CH addresses */
 /* DPCD */
 #define DP_DPCD_REV 0x000
+# define DPCD_REV_100x10
+# define DPCD_REV_110x11
+# define DPCD_REV_120x12
+# define DPCD_REV_130x13
+# define DPCD_REV_140x14
 
 #define DP_MAX_LINK_RATE0x001
 
@@ -118,6 +123,7 @@
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.7.4

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

Re: [PATCH v2 2/2] drivers: remove force dma flag from buses

[kbuild test robot]

Hi Nipun,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc6 next-20180323]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nipun-Gupta/dma-mapping-move-dma-configuration-to-bus-infrastructure/20180323-232307
config: i386-randconfig-x013-201811 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/base/dma-mapping.c: In function 'dma_common_configure':
>> drivers/base/dma-mapping.c:344:9: error: too many arguments to function 
>> 'of_dma_configure'
  ret = of_dma_configure(dev, dev->of_node, force_dma);
^~~~
   In file included from drivers/base/dma-mapping.c:13:0:
   include/linux/of_device.h:110:19: note: declared here
static inline int of_dma_configure(struct device *dev, struct device_node 
*np)
  ^~~~
--
   drivers/pci/pci-driver.c: In function 'pci_dma_configure':
>> drivers/pci/pci-driver.c:1544:9: error: too many arguments to function 
>> 'of_dma_configure'
  ret = of_dma_configure(dev, bridge->parent->of_node, true);
^~~~
   In file included from drivers/pci/pci-driver.c:21:0:
   include/linux/of_device.h:110:19: note: declared here
static inline int of_dma_configure(struct device *dev, struct device_node 
*np)
  ^~~~

vim +/of_dma_configure +344 drivers/base/dma-mapping.c

   332  
   333  /*
   334   * Common configuration to enable DMA API use for a device.
   335   * A bus can use this function in its 'dma_configure' callback, if
   336   * suitable for the bus.
   337   */
   338  int dma_common_configure(struct device *dev, bool force_dma)
   339  {
   340  enum dev_dma_attr attr;
   341  int ret = 0;
   342  
   343  if (dev->of_node) {
 > 344  ret = of_dma_configure(dev, dev->of_node, force_dma);
   345  } else if (has_acpi_companion(dev)) {
   346  attr = 
acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
   347  if (attr != DEV_DMA_NOT_SUPPORTED)
   348  ret = acpi_dma_configure(dev, attr);
   349  }
   350  
   351  return ret;
   352  }
   353  

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


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

Re: [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

My apologies, but I found a few more things that look strange and should
be cleaned up. Sorry for this iterative review approach, but I think we're
slowly getting there.

Thank you for reviewing!

Cheers, Daniel


---
  
+static int xen_drm_drv_dumb_create(struct drm_file *filp,

+   struct drm_device *dev, struct drm_mode_create_dumb *args)
+{
+   struct xen_drm_front_drm_info *drm_info = dev->dev_private;
+   struct drm_gem_object *obj;
+   int ret;
+
+   ret = xen_drm_front_gem_dumb_create(filp, dev, args);
+   if (ret)
+   goto fail;
+
+   obj = drm_gem_object_lookup(filp, args->handle);
+   if (!obj) {
+   ret = -ENOENT;
+   goto fail_destroy;
+   }
+
+   drm_gem_object_unreference_unlocked(obj);

You can't drop the reference while you keep using the object, someone else
might sneak in and destroy your object. The unreference always must be
last.

Will fix, thank you

+
+   /*
+* In case of CONFIG_DRM_XEN_FRONTEND_CMA gem_obj is constructed
+* via DRM CMA helpers and doesn't have ->pages allocated
+* (xendrm_gem_get_pages will return NULL), but instead can provide
+* sg table
+*/
+   if (xen_drm_front_gem_get_pages(obj))
+   ret = xen_drm_front_dbuf_create_from_pages(
+   drm_info->front_info,
+   xen_drm_front_dbuf_to_cookie(obj),
+   args->width, args->height, args->bpp,
+   args->size,
+   xen_drm_front_gem_get_pages(obj));
+   else
+   ret = xen_drm_front_dbuf_create_from_sgt(
+   drm_info->front_info,
+   xen_drm_front_dbuf_to_cookie(obj),
+   args->width, args->height, args->bpp,
+   args->size,
+   xen_drm_front_gem_get_sg_table(obj));
+   if (ret)
+   goto fail_destroy;
+

The above also has another race: If you construct an object, then it must
be fully constructed by the time you publish it to the wider world. In gem
this is done by calling drm_gem_handle_create() - after that userspace can
get at your object and do nasty things with it in a separate thread,
forcing your driver to Oops if the object isn't fully constructed yet.

That means you need to redo this code here to make sure that the gem
object is fully set up (including pages and sg tables) _before_ anything
calls drm_gem_handle_create().

You are correct, I need to rework this code


This probably means you also need to open-code the cma side, by first
calling drm_gem_cma_create(), then doing any additional setup, and finally
doing the registration to userspace with drm_gem_handle_create as the very
last thing.
Although I tend to avoid open-coding, but this seems the necessary 
measure here


Alternativet is to do the pages/sg setup only when you create an fb (and
drop the pages again when the fb is destroyed), but that requires some
refcounting/locking in the driver.
Not sure this will work: nothing prevents you from attaching multiple 
FBs to a single dumb handle
So, not only ref-counting should be done here, but I also need to check 
if the dumb buffer,

we are attaching to, has been created already

So, I will rework with open-coding some stuff from CMA helpers



Aside: There's still a lot of indirection and jumping around which makes
the code a bit hard to follow.
Probably I am not sure of which indirection we are talking about, could 
you please

specifically mark those annoying you?




+
+static void xen_drm_drv_release(struct drm_device *dev)
+{
+   struct xen_drm_front_drm_info *drm_info = dev->dev_private;
+   struct xen_drm_front_info *front_info = drm_info->front_info;
+
+   drm_atomic_helper_shutdown(dev);
+   drm_mode_config_cleanup(dev);
+
+   xen_drm_front_evtchnl_free_all(front_info);
+   dbuf_free_all(_info->dbuf_list);
+
+   drm_dev_fini(dev);
+   kfree(dev);
+
+   /*
+* Free now, as this release could be not due to rmmod, but
+* due to the backend disconnect, making drm_info hang in
+* memory until rmmod
+*/
+   devm_kfree(_info->xb_dev->dev, front_info->drm_info);
+   front_info->drm_info = NULL;
+
+   /* Tell the backend we are ready to (re)initialize */
+   xenbus_switch_state(front_info->xb_dev, XenbusStateInitialising);

This needs to be in the unplug code. Yes that means you'll have multiple
drm_devices floating around, but that's how hotplug works. That would also
mean that you need to drop the front_info pointer from the backend at
unplug time.

If you don't like those semantics then the only other option is to never
destroy the drm_device, but only mark the drm_connector as disconnected
when the xenbus backend is gone. But this half-half solution here where
you 

Re: [PATCH v4 0/8] cgroup private data and DRM/i915 integration

[Matt Roper]

On Fri, Mar 23, 2018 at 02:15:38PM +0200, Joonas Lahtinen wrote:
> Quoting Matt Roper (2018-03-17 02:08:57)
> > This is the fourth iteration of the work previously posted here:
> >   (v1) 
> > https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
> >   (v2) 
> > https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html
> >   (v3) 
> > https://lists.freedesktop.org/archives/intel-gfx/2018-March/157928.html
> > 
> > The high level goal of this work is to allow non-cgroup-controller parts
> > of the kernel (e.g., device drivers) to register their own private
> > policy data for specific cgroups.  That mechanism is then made use of in
> > the i915 graphics driver to allow GPU priority to be assigned according
> > to the cgroup membership of the owning process.  Please see the v1 cover
> > letter linked above for a more in-depth explanation and justification.
> 
> Hi Matt,
> 
> For cross-subsystem changes such as this, it makes sense to Cc all
> relevant maintainers, especially if there have been previous comments to
> earlier revisions.
> 
> Please, do include and keep a reference to the userspace portion of the
> changes when you suggest new uAPI to be added. At least I have some trouble
> trying to track down the relevant interface consumer here.
> 
> I'm unsure how much sense it makes to commence with detailed i915 review
> if we will be blocked by lack of userspace after that? I'm assuming
> you've read through [1] already.

Hi Joonas,

I've sent the userspace code out a few times, but it looks like I forgot
to include a copy with v4/v4.5.  Here's the version I provided with v3:
  https://lists.freedesktop.org/archives/intel-gfx/2018-March/157935.html

Usually we don't consider things like i-g-t to be sufficient userspace
consumers because we need a real-world consumer rather than a "toy"
userspace.  However in this case, the i-g-t tool, although very simple,
is really the only userspace consumer I expect there to ever be.
Ultimately the true consumer of this cgroups work are bash scripts, sysv
init scripts, systemd recipes, etc.  that just need a very simple tool
to assign the specific values that make sense on a given system.
There's no expectation that graphics clients or display servers would
ever need to make use of these interfaces.



Matt

> 
> Regards, Joonas
> 
> [1] 
> https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook

[Ville Syrjälä]

On Fri, Mar 23, 2018 at 03:58:06PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 23, 2018 at 02:37:23PM +0100, Noralf Trønnes wrote:
> > 
> > Den 23.03.2018 12.31, skrev Ville Syrjälä:
> > > On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
> > >>
> > >> Den 22.03.2018 21.27, skrev Ville Syrjala:
> > >>> From: Ville Syrjälä 
> > >>>
> > >>> mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
> > >>> bowels of the .atomic_enable() hook. That prevents us from taking the
> > >>> plane mutex in fb->dirty() unless we also plumb down the acquire
> > >>> context.
> > >>>
> > >>> Instead it seems simpler to split the fb->dirty() into a tinydrm
> > >>> specific lower level hook that can be called from
> > >>> mipi_dbi_enable_flush() and from a generic higher level
> > >>> tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
> > >>> vfuncs table we'll just stick it into tinydrm_device directly
> > >>> for now.
> > >> The long term goal is to try and get rid of tinydrm.ko by moving stuff
> > >> elsewhere as it's kind of a middle layer. So I'd really like to avoid
> > >> adding a callback like this.
> > >> Hopefully we can work out a solution based on my suggestion in the
> > >> 'drm: Eliminate plane->fb/crtc usage for atomic drivers' thread.
> > > I don't want to start redesigning the entire architecture at
> > > this point. That would also cause a bigger risk of regression and
> > > then we'd potentially have to try and revert the entire plane->fb
> > > thing, which would not be fun if any significant changes have
> > > occurred in the meantime.
> > >
> > >> If we do need a hook, I prefer that we add it to
> > >> drm_simple_display_pipe_funcs.
> > > If you have plans to redesign tinydrm anyway it seems to me that
> > > a temporary hook in tinydrm is may be a bit less intrusive than
> > > inflicting it on the simple_kms_helper.
> > 
> > Yes you're right of course, what was I thinking.
> > 
> > You missed out on one call site:
> > 
> > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c 
> > b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > index 11ae950b0fc9..7924eb59c2e1 100644
> > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > @@ -124,11 +124,8 @@ void tinydrm_display_pipe_update(struct 
> > drm_simple_display_pipe *pipe,
> >      struct drm_framebuffer *fb = pipe->plane.state->fb;
> >      struct drm_crtc *crtc = >pipe.crtc;
> > 
> > -   if (fb && (fb != old_state->fb)) {
> > -   pipe->plane.fb = fb;
> > -   if (fb->funcs->dirty)
> > -   fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
> > -   }
> > +   if (fb && (fb != old_state->fb))
> > +   tdev->fb_dirty(fb, NULL, 0, 0, NULL, 0);
> > 
> >      if (crtc->state->event) {
> >      spin_lock_irq(>dev->event_lock);
> > 
> > With that fixed, series is:
> > 
> > Reviewed-by: Noralf Trønnes 
> 
> Awesome. Thanks. And thanks for catching that extra dirty() call. I'll
> go and fix it up.

OK, I posted the fixed version.

Would you be interested in running some kind of smoke test on this
before I push it? I'd hate to break things for you, and unfortunately
(or maybe fortunately :) I don't have any hardware to test this.

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

[PATCH v2 2/2] drm/tinydrm: Make fb_dirty into a lower level hook

[Ville Syrjala]

From: Ville Syrjälä 

mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us from taking the
plane mutex in fb->dirty() unless we also plumb down the acquire
context.

Instead it seems simpler to split the fb->dirty() into a tinydrm
specific lower level hook that can be called from
mipi_dbi_enable_flush() and from a generic higher level
tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
vfuncs table we'll just stick it into tinydrm_device directly
for now.

v2: Deal with the fb->dirty() in tinydrm_display_pipe_update() as weel (Noralf)

Cc: "Noralf Trønnes" 
Cc: David Lechner 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30 ++
 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c|  5 ++---
 drivers/gpu/drm/tinydrm/ili9225.c  | 23 ++--
 drivers/gpu/drm/tinydrm/mi0283qt.c |  2 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 30 ++
 drivers/gpu/drm/tinydrm/repaper.c  | 28 
 drivers/gpu/drm/tinydrm/st7586.c   | 23 ++--
 drivers/gpu/drm/tinydrm/st7735r.c  |  2 +-
 include/drm/tinydrm/mipi-dbi.h |  4 +++-
 include/drm/tinydrm/tinydrm-helpers.h  |  5 +
 include/drm/tinydrm/tinydrm.h  |  4 
 11 files changed, 78 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d1c3ce9ab294..dcd390163a4a 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -78,6 +78,36 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
 }
 EXPORT_SYMBOL(tinydrm_merge_clips);
 
+int tinydrm_fb_dirty(struct drm_framebuffer *fb,
+struct drm_file *file_priv,
+unsigned int flags, unsigned int color,
+struct drm_clip_rect *clips,
+unsigned int num_clips)
+{
+   struct tinydrm_device *tdev = fb->dev->dev_private;
+   struct drm_plane *plane = >pipe.plane;
+   int ret = 0;
+
+   drm_modeset_lock(>mutex, NULL);
+
+   /* fbdev can flush even when we're not interested */
+   if (plane->state->fb == fb) {
+   mutex_lock(>dirty_lock);
+   ret = tdev->fb_dirty(fb, file_priv, flags,
+color, clips, num_clips);
+   mutex_unlock(>dirty_lock);
+   }
+
+   drm_modeset_unlock(>mutex);
+
+   if (ret)
+   dev_err_once(fb->dev->dev,
+"Failed to update display %d\n", ret);
+
+   return ret;
+}
+EXPORT_SYMBOL(tinydrm_fb_dirty);
+
 /**
  * tinydrm_memcpy - Copy clip buffer
  * @dst: Destination buffer
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
index 11ae950b0fc9..e68b528ae64d 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
@@ -125,9 +125,8 @@ void tinydrm_display_pipe_update(struct 
drm_simple_display_pipe *pipe,
struct drm_crtc *crtc = >pipe.crtc;
 
if (fb && (fb != old_state->fb)) {
-   pipe->plane.fb = fb;
-   if (fb->funcs->dirty)
-   fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
+   if (tdev->fb_dirty)
+   tdev->fb_dirty(fb, NULL, 0, 0, NULL, 0);
}
 
if (crtc->state->event) {
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index 089d22798c8b..0874e877b111 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -88,14 +88,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
bool full;
void *tr;
 
-   mutex_lock(>dirty_lock);
-
if (!mipi->enabled)
-   goto out_unlock;
-
-   /* fbdev can flush even when we're not interested */
-   if (tdev->pipe.plane.fb != fb)
-   goto out_unlock;
+   return 0;
 
full = tinydrm_merge_clips(, clips, num_clips, flags,
   fb->width, fb->height);
@@ -108,7 +102,7 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
tr = mipi->tx_buf;
ret = mipi_dbi_buf_copy(mipi->tx_buf, fb, , swap);
if (ret)
-   goto out_unlock;
+   return ret;
} else {
tr = cma_obj->vaddr;
}
@@ -159,20 +153,13 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
ret = mipi_dbi_command_buf(mipi, ILI9225_WRITE_DATA_TO_GRAM, tr,
(clip.x2 

[pull] amdgpu drm-next-4.17

[Alex Deucher]

Hi Dave,

Last pull for 4.17.  Highlights:
- Vega12 support
- A few more bug fixes and cleanups for powerplay

The following changes since commit 6da2b9332c572fcda94de9631f8fa514f574388a:

  amdgpu/dm: Default PRE_VEGA ASIC support to 'y' (2018-03-16 16:16:50 -0500)

are available in the git repository at:

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

for you to fetch changes up to 09695ad78f1f5f315c7e9c5090f0c7b846a43690:

  drm/amd/pp: clean header file hwmgr.h (2018-03-23 09:42:42 -0500)


Alex Deucher (23):
  drm/amdgpu: add VCN to firmware query interface
  drm/amdgpu: add documentation for amdgpu_device.c
  drm/amdgpu: add gpu_info firmware for vega12
  drm/amdgpu: set asic family and ip blocks for vega12
  drm/amdgpu/psp: initial vega12 support
  drm/amdgpu: specify vega12 uvd firmware
  drm/amdgpu: specify vega12 vce firmware
  drm/amdgpu/virtual_dce: add vega12 support
  drm/amd/display/dm: add vega12 support
  drm/amdgpu: add vega12 to dc support check
  drm/amdgpu/gmc9: add vega12 support (v2)
  drm/amdgpu/mmhub: add clockgating support for vega12
  drm/amdgpu/sdma4: specify vega12 firmware
  drm/amdgpu/sdma4: Add placeholder for vega12 golden settings
  drm/amdgpu/sdma4: add clockgating support for vega12
  drm/amdgpu/gfx9: add support for vega12 firmware
  drm/amdgpu/gfx9: Add placeholder for vega12 golden settings
  drm/amdgpu/gfx9: add gfx config for vega12
  drm/amdgpu/gfx9: add support for vega12
  drm/amdgpu/gfx9: add clockgating support for vega12
  drm/amdgpu/soc15: add support for vega12
  drm/amdgpu: add vega12 pci ids (v2)
  drm/amdgpu: Add an ATPX quirk for hybrid laptop

Andrey Grodzovsky (2):
  drm/amd/powerplay: Fix NULL pointer deref on driver unbind.
  drm/amdgpu: Fix NULL ptr on driver unload due to init failure.

Christian König (1):
  drm/amdgpu: fix "mitigate workaround for i915"

Chunming Zhou (1):
  drm/amdgpu: Don't change preferred domian when fallback GTT v5

Colin Ian King (2):
  drm/amdgpu: fix spelling mistake: "asssert" -> "assert"
  drm/amd/pp: use mlck_table.count for array loop index limit

Evan Quan (12):
  drm/amdgpu: initilize vega12 psp firmwares
  drm/amdgpu/soc15: update vega12 cg_flags
  drm/amd/powerplay: add vega12_inc.h
  drm/amd/powerplay: update atomfirmware.h (v2)
  drm/amd/powerplay: add new smu9_driver_if.h for vega12 (v2)
  drm/amd/powerplay: add vega12_ppsmc.h
  drm/amd/powerplay: add vega12_pptable.h
  drm/amd/powerplay: update ppatomfwctl (v2)
  drm/amd/powerplay: add new pp_psm infrastructure for vega12 (v2)
  drm/amd/powerplay: add the smu manager for vega12 (v4)
  drm/amd/powerplay: add the hw manager for vega12 (v4)
  drm/amdgpu: no job timeout setting on compute queues

Feifei Xu (5):
  drm/amd/include: Add ip header files for vega12.
  drm/amdgpu: add vega12 to asic_type enum
  drm/amdgpu: add vega12 ucode loading method
  drm/amdgpu/sdma4: Update vega12 sdma golden setting.
  drm/amd/soc15: Add external_rev_id for vega12.

Hawking Zhang (5):
  drm/amdgpu/nbio6: Correct PCIE_INDEX/DATA pair used for smn register 
accessing
  drm/amdgpu: vega12 to smu firmware
  drm/amdgpu/sdma4: add sdma4_0_1 support for vega12 (v3)
  drm/amdgpu/gfx9: add golden setting for vega12 (v3)
  drm/amdgpu/soc15: initialize reg base for vega12

Jerry (Fangzhi) Zuo (1):
  drm/amd/display: Add bios firmware info version for VG12

Kenneth Feng (2):
  drm/amd/powerplay: Remove the SOC floor voltage setting
  drm/amd/powerplay: Return per DPM level clock

Mikita Lipski (3):
  drm/amdgpu: Use atomic function to disable crtcs with dc enabled
  drm/amdgpu: Disable irq on device before destroying it
  drm/amdgpu - Disable all irqs before disabling all CRTCs

Rex Zhu (19):
  drm/amdgpu: Delete dead code when early init
  drm/amd/pp: Remove dead functions in vega10_smumgr.c
  drm/amd/pp: Mark bunches of functins in vega10_smumgr.c static
  drm/amd/pp: Move functions to smu backend table for vega10
  drm/amd/pp: Clean up header file for Vega10
  drm/amd/pp: Delete get_xclk function in powerplay (v2)
  drm/amd/pp: Remove unneeded void * casts for Vega10
  drm/amdgpu: Fix kernel NULL pointer dereference when amdgpu fini
  drm/amdgpu: Fix kernel NULL pointer dereference in dpm functions
  drm/amd/pp: Fix gfx ring test failed on Fiji without hw avfs support
  drm/amd/pp: Fix unable to handle kernel paging request when set pp table
  drm/amdgpu: Remove wrapper layer of cgs irq handling
  drm/amd/pp: Refine register_thermal_interrupt function
  drm/amd/pp: Add smu irq handlers in sw_init instand of hw_init
  drm/amd/pp: Fix set wrong temperature range on smu7
  drm/amd/pp: Add smu irq handlers for legacy asics
  

Re: [igt-dev] [PATCH i-g-t 3/3] tests/kms_getfb: Add getfb2 tests

[Ville Syrjälä]

On Fri, Mar 23, 2018 at 01:46:16PM +, Daniel Stone wrote:
> Mirroring addfb2, add tests for the new ioctl which will return us
> information about framebuffers containing multiple buffers, as well as
> modifiers.

lgtm
Reviewed-by: Ville Syrjälä 

Maybe we also want to encode my earlier 'getfb2(); addfb2();'
idea into a test?

> 
> Signed-off-by: Daniel Stone 
> ---
>  tests/kms_getfb.c | 91 
> +++
>  1 file changed, 91 insertions(+)
> 
> diff --git a/tests/kms_getfb.c b/tests/kms_getfb.c
> index a9852626..b8583694 100644
> --- a/tests/kms_getfb.c
> +++ b/tests/kms_getfb.c
> @@ -186,7 +186,96 @@ static void test_duplicate_handles(int fd)
>   do_ioctl(fd, DRM_IOCTL_MODE_RMFB, _id);
>   gem_close(fd, add.handles[0]);
>   }
> +}
> +
> +static void test_getfb2(int fd)
> +{
> + struct drm_mode_fb_cmd2 add_basic = {};
> +
> + igt_fixture {
> + struct drm_mode_fb_cmd2 get = {};
> +
> + add_basic.width = 1024;
> + add_basic.height = 1024;
> + add_basic.pixel_format = DRM_FORMAT_XRGB;
> + add_basic.pitches[0] = 1024*4;
> + add_basic.handles[0] = igt_create_bo_with_dimensions(fd, 1024, 
> 1024,
> + DRM_FORMAT_XRGB, 0, 0, NULL, NULL, NULL);
> + igt_assert(add_basic.handles[0]);
> + do_ioctl(fd, DRM_IOCTL_MODE_ADDFB2, _basic);
> +
> + get.fb_id = add_basic.fb_id;
> + do_ioctl(fd, DRM_IOCTL_MODE_GETFB2, );
> + igt_assert_neq_u32(get.handles[0], 0);
> + gem_close(fd, get.handles[0]);
> + }
> +
> + igt_subtest("getfb2-handle-zero") {
> + struct drm_mode_fb_cmd2 get = {};
> + do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB2, , ENOENT);
> + }
> +
> + igt_subtest("getfb2-handle-closed") {
> + struct drm_mode_fb_cmd2 add = add_basic;
> + struct drm_mode_fb_cmd2 get = { };
> +
> + add.handles[0] = igt_create_bo_with_dimensions(fd, 1024, 1024,
> + DRM_FORMAT_XRGB, 0, 0, NULL, NULL, NULL);
> + igt_assert(add.handles[0]);
> + do_ioctl(fd, DRM_IOCTL_MODE_ADDFB2, );
> + do_ioctl(fd, DRM_IOCTL_MODE_RMFB, _id);
>  
> + get.fb_id = add.fb_id;
> + do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB2, , ENOENT);
> + gem_close(fd, add.handles[0]);
> + }
> +
> + igt_subtest("getfb2-handle-not-fb") {
> + struct drm_mode_fb_cmd get = { .fb_id = get_prop_id(fd) };
> + igt_require(get.fb_id > 0);
> + do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB, , ENOENT);
> + }
> +
> + igt_subtest("getfb2-accept-ccs") {
> + struct drm_mode_fb_cmd2 add_ccs = { };
> + struct drm_mode_fb_cmd2 get = { };
> + int i;
> +
> + get_ccs_fb(fd, _ccs);
> + igt_require(add_ccs.fb_id != 0);
> + get.fb_id = add_ccs.fb_id;
> + do_ioctl(fd, DRM_IOCTL_MODE_GETFB2, );
> +
> + igt_assert_eq_u32(get.width, add_ccs.width);
> + igt_assert_eq_u32(get.height, add_ccs.height);
> + igt_assert(get.flags & DRM_MODE_FB_MODIFIERS);
> +
> + for (i = 0; i < ARRAY_SIZE(get.handles); i++) {
> + igt_assert_eq_u32(get.pitches[i], add_ccs.pitches[i]);
> + igt_assert_eq_u32(get.offsets[i], add_ccs.offsets[i]);
> + if (add_ccs.handles[i] != 0) {
> + igt_assert_neq_u32(get.handles[i], 0);
> + igt_assert_neq_u32(get.handles[i],
> +add_ccs.handles[i]);
> + igt_assert_eq_u64(get.modifier[i],
> +   add_ccs.modifier[i]);
> + } else {
> + igt_assert_eq_u32(get.handles[i], 0);
> + igt_assert_eq_u64(get.modifier[i],
> +   DRM_FORMAT_MOD_INVALID);
> + }
> + }
> + igt_assert_eq_u32(get.handles[0], get.handles[1]);
> +
> + do_ioctl(fd, DRM_IOCTL_MODE_RMFB, _id);
> + gem_close(fd, add_ccs.handles[0]);
> + gem_close(fd, get.handles[0]);
> + }
> +
> + igt_fixture {
> + do_ioctl(fd, DRM_IOCTL_MODE_RMFB, _basic.fb_id);
> + gem_close(fd, add_basic.handles[0]);
> + }
>  }
>  
>  igt_main
> @@ -200,6 +289,8 @@ igt_main
>  
>   test_duplicate_handles(fd);
>  
> + test_getfb2(fd);
> +
>   igt_fixture
>   close(fd);
>  }
> -- 
> 2.16.2
> 
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev

-- 

Re: [igt-dev] [PATCH i-g-t 1/3] tests/kms_getfb: Split property-ID get into helper

[Daniel Stone]

On 23 March 2018 at 14:53, Ville Syrjälä  wrote:
> On Fri, Mar 23, 2018 at 01:46:14PM +, Daniel Stone wrote:
>> +/**
>> + * Find and return an arbitrary valid property ID.
>> + */
>> +static uint32_t get_prop_id(int fd)
>
> get_any_prop_id() or something like that maybe?

Yeah, a good choice of colour. :)

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

Re: [PATCH i-g-t 1/3] tests/kms_getfb: Split property-ID get into helper

[Ville Syrjälä]

On Fri, Mar 23, 2018 at 01:46:14PM +, Daniel Stone wrote:
> We'll want to reuse this, so split it out into a (smaller!) helper.
> 
> Signed-off-by: Daniel Stone 
> ---
>  tests/kms_getfb.c | 36 +++-
>  1 file changed, 19 insertions(+), 17 deletions(-)
> 
> diff --git a/tests/kms_getfb.c b/tests/kms_getfb.c
> index c5968e75..a9852626 100644
> --- a/tests/kms_getfb.c
> +++ b/tests/kms_getfb.c
> @@ -72,6 +72,23 @@ static void get_ccs_fb(int fd, struct drm_mode_fb_cmd2 
> *ret)
>   gem_close(fd, add.handles[0]);
>  }
>  
> +/**
> + * Find and return an arbitrary valid property ID.
> + */
> +static uint32_t get_prop_id(int fd)

get_any_prop_id() or something like that maybe?

Either way
Reviewed-by: Ville Syrjälä 

> +{
> + igt_display_t display;
> +
> + igt_display_init(, fd);
> + for (int i = 0; i < display.n_outputs; i++) {
> + igt_output_t *output = [i];
> + if (output->props[IGT_CONNECTOR_DPMS] != 0)
> + return output->props[IGT_CONNECTOR_DPMS];
> + }
> +
> + return 0;
> +}
> +
>  static void test_handle_input(int fd)
>  {
>   struct drm_mode_fb_cmd2 add = {};
> @@ -111,23 +128,8 @@ static void test_handle_input(int fd)
>   }
>  
>   igt_subtest("getfb-handle-not-fb") {
> - struct drm_mode_fb_cmd get = { };
> - uint32_t prop_id = 0;
> - igt_display_t display;
> -
> - /* Find a valid property ID to use. */
> - igt_display_init(, fd);
> - for (int i = 0; i < display.n_outputs; i++) {
> - igt_output_t *output = [i];
> -
> - if (output->props[IGT_CONNECTOR_DPMS] != 0) {
> - prop_id = output->props[IGT_CONNECTOR_DPMS];
> - break;
> - }
> - }
> - igt_require(prop_id > 0);
> -
> - get.fb_id = prop_id;
> + struct drm_mode_fb_cmd get = { .fb_id = get_prop_id(fd) };
> + igt_require(get.fb_id > 0);
>   do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB, , ENOENT);
>   }
>  }
> -- 
> 2.16.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 199157] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000

[bugzilla-daemon]

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

--- Comment #4 from Harry Wentland (harry.wentl...@amd.com) ---
I have one of the first R7 1700 at home on have only seen the marginality
problem affecting gcc and bash while compiling something multi-threaded. Never
noticed it crashing the kernel.

I think what you see might be a legit issue in DC. Does it happen randomly? On
boot? During normal usage? Gaming? How frequently do you see this?

-- 
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 2/4] drm/i915: Move GEM BO inside drm_framebuffer

[Daniel Stone]

Hi Ville,

On 23 March 2018 at 14:42, Ville Syrjälä  wrote:
> On Fri, Mar 23, 2018 at 01:45:50PM +, Daniel Stone wrote:
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -13916,7 +13916,8 @@ static void intel_user_framebuffer_destroy(struct 
>> drm_framebuffer *fb)
>>   drm_framebuffer_cleanup(fb);
>>
>>   i915_gem_object_lock(obj);
>> - WARN_ON(!obj->framebuffer_references--);
>> + WARN_ON(obj->framebuffer_references < fb->format->num_planes);
>> + obj->framebuffer_references -= fb->format->num_planes;
>
> Hmm. I'm thinking we can stick to the single reference per fb.
> IIRC this counter is there just to prevent changes of the obj
> tiling mode as long as any fb exists that uses the object. So
> doesn't actually matter how many planes the fb has.
>
> Naturally the story would be slightly difference if we supported
> fbs using multiple different BOs, as each BO would need to get its
> framebuffer_references adjusted.

Yeah, fair enough. It looks a little bit weird (perhaps deserving of a
comment) there. The reason to do that was just the general principle
of having one reference per object pointer, especially when other
drivers (ones which can have separate BOs in a single logical image)
will and do refcount them separately. Having different refcounting
semantics in shared structures depending on which driver is in use
makes me itchy.

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

Re: [PATCH 4/4] drm: Add getfb2 ioctl

[Ville Syrjälä]

On Fri, Mar 23, 2018 at 01:45:52PM +, Daniel Stone wrote:
> getfb2 allows us to pass multiple planes and modifiers, just like addfb2
> over addfb.
> 
> Signed-off-by: Daniel Stone 
> ---
>  drivers/gpu/drm/drm_crtc_internal.h |   2 +
>  drivers/gpu/drm/drm_framebuffer.c   | 109 
> 
>  drivers/gpu/drm/drm_ioctl.c |   2 +
>  include/uapi/drm/drm.h  |   1 +
>  4 files changed, 114 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 3c2b82865ad2..0cd02f3d203d 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -173,6 +173,8 @@ int drm_mode_rmfb(struct drm_device *dev,
> void *data, struct drm_file *file_priv);
>  int drm_mode_getfb(struct drm_device *dev,
>  void *data, struct drm_file *file_priv);
> +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> +   void *data, struct drm_file *file_priv);
>  int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
>  void *data, struct drm_file *file_priv);
>  
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index 6d5ff541225a..f1cfb6ddc776 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -494,7 +495,115 @@ int drm_mode_getfb(struct drm_device *dev,
>  
>  out:
>   drm_framebuffer_put(fb);
> + return ret;
> +}
> +
> +/**
> + * drm_mode_getfb2 - get extended FB info
> + * @dev: drm device for the ioctl
> + * @data: data pointer for the ioctl
> + * @file_priv: drm file for the ioctl call
> + *
> + * Lookup the FB given its ID and return info about it.
> + *
> + * Called by the user via ioctl.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> +   void *data, struct drm_file *file_priv)
> +{
> + struct drm_mode_fb_cmd2 *r = data;
> + struct drm_framebuffer *fb;
> + unsigned int i;
> + int ret;
> +
> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + return -EINVAL;
>  
> + fb = drm_framebuffer_lookup(dev, file_priv, r->fb_id);
> + if (!fb)
> + return -ENOENT;
> +
> + /* For multi-plane framebuffers, we require the driver to place the
> +  * GEM objects directly in the drm_framebuffer. For single-plane
> +  * framebuffers, we can fall back to create_handle.
> +  */
> + if (!fb->obj[0] &&
> + (fb->format->num_planes > 1 || !fb->funcs->create_handle)) {
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + r->height = fb->height;
> + r->width = fb->width;
> + r->pixel_format = fb->format->format;
> +
> + r->flags = 0;
> + if (dev->mode_config.allow_fb_modifiers)
> + r->flags |= DRM_MODE_FB_MODIFIERS;
> +
> + for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
> + r->handles[i] = 0;
> + r->pitches[i] = 0;
> + r->offsets[i] = 0;
> + r->modifier[i] = DRM_FORMAT_MOD_INVALID;

Don't we want to leave this zeroed too? For addfb2 we require any unused
modifier to be 0, so if someone does 'getfb2(); addfb2();' they
would get an error from the addfb2().

> + }
> +
> + for (i = 0; i < fb->format->num_planes; i++) {
> + int j;
> +
> + r->pitches[i] = fb->pitches[i];
> + r->offsets[i] = fb->offsets[i];
> + if (dev->mode_config.allow_fb_modifiers)
> + r->modifier[i] = fb->modifier;
> +
> + /* If we reuse the same object for multiple planes, also
> +  * return the same handle.
> +  */
> + for (j = 0; j < i; j++) {
> + if (fb->obj[i] == fb->obj[j]) {
> + r->handles[i] = r->handles[j];
> + break;
> + }
> + }
> +
> + if (r->handles[i])
> + continue;
> +
> + if (fb->obj[i]) {
> + ret = drm_gem_handle_create(file_priv, fb->obj[i],
> + >handles[i]);
> + } else {
> + WARN_ON(i > 0);
> + ret = fb->funcs->create_handle(fb, file_priv,
> +>handles[i]);
> + }
> +
> + if (ret != 0)
> + goto out;
> + }
> +
> +out:
> + if (ret != 0) {
> + /* Delete any previously-created handles on failure. */
> + for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
> + int j;
> +
> + if (r->handles[i])
> + 

Re: [PATCH 3/4] drm: Reshuffle getfb error returns

[Ville Syrjälä]

On Fri, Mar 23, 2018 at 01:45:51PM +, Daniel Stone wrote:
> Make it a little more clear what's going on inside of getfb, and also
> make it easier to add alternate paths to get a handle in future.
> 
> Signed-off-by: Daniel Stone 

Much better.
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_framebuffer.c | 33 +
>  1 file changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index ad67203de715..6d5ff541225a 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -468,29 +468,30 @@ int drm_mode_getfb(struct drm_device *dev,
>   goto out;
>   }
>  
> + if (!fb->funcs->create_handle) {
> + ret = -ENODEV;
> + goto out;
> + }
> +
>   r->height = fb->height;
>   r->width = fb->width;
>   r->depth = fb->format->depth;
>   r->bpp = fb->format->cpp[0] * 8;
>   r->pitch = fb->pitches[0];
> - if (fb->funcs->create_handle) {
> - if (drm_is_current_master(file_priv) || capable(CAP_SYS_ADMIN) 
> ||
> - drm_is_control_client(file_priv)) {
> - ret = fb->funcs->create_handle(fb, file_priv,
> ->handle);
> - } else {
> - /* GET_FB() is an unprivileged ioctl so we must not
> -  * return a buffer-handle to non-master processes! For
> -  * backwards-compatibility reasons, we cannot make
> -  * GET_FB() privileged, so just return an invalid handle
> -  * for non-masters. */
> - r->handle = 0;
> - ret = 0;
> - }
> - } else {
> - ret = -ENODEV;
> +
> + /* GET_FB() is an unprivileged ioctl so we must not return a
> +  * buffer-handle to non-master processes! For
> +  * backwards-compatibility reasons, we cannot make GET_FB() privileged,
> +  * so just return an invalid handle for non-masters. */
> + if (!drm_is_current_master(file_priv) && !capable(CAP_SYS_ADMIN) &&
> + !drm_is_control_client(file_priv)) {
> + r->handle = 0;
> + ret = 0;
> + goto out;
>   }
>  
> + ret = fb->funcs->create_handle(fb, file_priv, >handle);
> +
>  out:
>   drm_framebuffer_put(fb);
>  
> -- 
> 2.16.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer

[Ville Syrjälä]

On Fri, Mar 23, 2018 at 01:45:50PM +, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass.
> 
> Signed-off-by: Daniel Stone 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: intel-...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/i915/intel_display.c | 15 ---
>  drivers/gpu/drm/i915/intel_drv.h |  3 +--
>  2 files changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 49b0772e9abc..e8100a4fc877 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13916,7 +13916,8 @@ static void intel_user_framebuffer_destroy(struct 
> drm_framebuffer *fb)
>   drm_framebuffer_cleanup(fb);
>  
>   i915_gem_object_lock(obj);
> - WARN_ON(!obj->framebuffer_references--);
> + WARN_ON(obj->framebuffer_references < fb->format->num_planes);
> + obj->framebuffer_references -= fb->format->num_planes;

Hmm. I'm thinking we can stick to the single reference per fb.
IIRC this counter is there just to prevent changes of the obj
tiling mode as long as any fb exists that uses the object. So
doesn't actually matter how many planes the fb has.

Naturally the story would be slightly difference if we supported
fbs using multiple different BOs, as each BO would need to get its
framebuffer_references adjusted.

>   i915_gem_object_unlock(obj);
>  
>   i915_gem_object_put(obj);
> @@ -14176,9 +14177,9 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
> i, fb->pitches[i], stride_alignment);
>   goto err;
>   }
> - }
>  
> - intel_fb->obj = obj;
> + fb->obj[i] = >base;
> + }
>  
>   ret = intel_fill_fb_info(dev_priv, fb);
>   if (ret)
> @@ -14190,6 +14191,14 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
>   goto err;
>   }
>  
> + /* We already hold one reference to the fb, but in case it's
> +  * multi-planar and we've placed multiple pointers in
> +  * drm_framebuffer, hold extra refs.
> +  */
> + i915_gem_object_lock(obj);
> + obj->framebuffer_references += fb->format->num_planes - 1;
> + i915_gem_object_unlock(obj);
> +
>   return 0;
>  
>  err:
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 570f89b31544..d93ed9e59867 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -186,7 +186,6 @@ enum intel_output_type {
>  
>  struct intel_framebuffer {
>   struct drm_framebuffer base;
> - struct drm_i915_gem_object *obj;
>   struct intel_rotation_info rot_info;
>  
>   /* for each plane in the normal GTT view */
> @@ -985,7 +984,7 @@ struct cxsr_latency {
>  #define to_intel_framebuffer(x) container_of(x, struct intel_framebuffer, 
> base)
>  #define to_intel_plane(x) container_of(x, struct intel_plane, base)
>  #define to_intel_plane_state(x) container_of(x, struct intel_plane_state, 
> base)
> -#define intel_fb_obj(x) (x ? to_intel_framebuffer(x)->obj : NULL)
> +#define intel_fb_obj(x) (((x) && (x)->obj[0]) ? to_intel_bo((x)->obj[0]) : 
> NULL)

Ah, I've had that "(x)" part coded up so many times, but never sent it
out :)

>  
>  struct intel_hdmi {
>   i915_reg_t hdmi_reg;
> -- 
> 2.16.2
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Bug 105712] intel-gpu-overlay is showing insane power consumption amounts

[bugzilla-daemon]

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

--- Comment #1 from Chris Wilson  ---
Please try drm-tip as the interface intel-gpu-overlay uses has finally been
upstreamed, hopefully it's just that.

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

[Bug 105712] intel-gpu-overlay is showing insane power consumption amounts

[bugzilla-daemon]

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

Bug ID: 105712
   Summary: intel-gpu-overlay is showing insane power consumption
amounts
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: leozinho29...@hotmail.com

Created attachment 138312
  --> https://bugs.freedesktop.org/attachment.cgi?id=138312=edit
Screenshot showing intel-gpu-overlay in Xnest

The program intel-gpu-overlay from intel-gpu-tools is showing very high numbers
of power consumption. It is showing values as high as 60 GW of power
(60 mW). Comparing the values to versions that were OK previously
(intel-gpu-tools 1.18 shows proper values), it appears that there are many
additional numbers that should be in the decimal places, so that 60
mW would be 6000,00 mW, or 6 W (which, usually, is the maximum I've
seen so far).

This is happening both with intel-gpu-tools 1.22 and with the latest git
(c2ee9077).

-- chipset: Intel Core i3-6100U
-- system architecture: 64-bit
-- xf86-video-intel: 2:2.99.917+git20171229-1
-- xserver: 2:1.19.6-1ubuntu3
-- mesa: 18.1.0-devel (git-903e9952fb)
-- libdrm: 2.4.91-2
-- kernel: 4.16.0-rc6
-- Linux distribution: Xubuntu 18.04 (Development branch)
-- Machine or mobo model: Lenovo Ideapad 310-14ISK 80UG
-- Display connector: eDP and VGA

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

Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

[Joonas Lahtinen]

Quoting Stephen Rothwell (2018-03-23 02:50:18)
> Hi all,
> 
> On Thu, 22 Mar 2018 13:21:29 +1100 Stephen Rothwell  
> wrote:
> >
> > Today's linux-next merge of the drm-intel tree got a conflict in:
> > 
> >   drivers/gpu/drm/i915/gvt/scheduler.c
> > 
> > between commit:
> > 
> >   fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
> > 
> > from Linus' tree and commit:
> > 
> >   b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is 
> > pinned.")
> > 
> > from the drm-intel tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.

Hi Stephen,

Thanks for solving this, the resolution is correct.

You may want to replace Daniel, as the recipient here, with the current
i915 maintainers to get a faster feedback next time :)



> This is now a conflict between the drm tree and Linus' tree.
> 

My bad for not highlighting the merge conflict in my PR to Dave. He
probably did not notice, getting the resolution automatically from
drm-rerere, I'd guess. I've noted it in the ever improving draft of
things to remember with the PRs.

I'm very much currently flying based on what the previous PR authors
have remembered to tell me. But after 4.17, the cycle is complete and we
all "have been there, done that", and you can expect less of a turbulence.

(We'll probably have more magnificent documentation, too.)

Regards, Joonas

> -- 
> Cheers,
> Stephen Rothwell
> 
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook

[Ville Syrjälä]

On Fri, Mar 23, 2018 at 02:37:23PM +0100, Noralf Trønnes wrote:
> 
> Den 23.03.2018 12.31, skrev Ville Syrjälä:
> > On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
> >>
> >> Den 22.03.2018 21.27, skrev Ville Syrjala:
> >>> From: Ville Syrjälä 
> >>>
> >>> mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
> >>> bowels of the .atomic_enable() hook. That prevents us from taking the
> >>> plane mutex in fb->dirty() unless we also plumb down the acquire
> >>> context.
> >>>
> >>> Instead it seems simpler to split the fb->dirty() into a tinydrm
> >>> specific lower level hook that can be called from
> >>> mipi_dbi_enable_flush() and from a generic higher level
> >>> tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
> >>> vfuncs table we'll just stick it into tinydrm_device directly
> >>> for now.
> >> The long term goal is to try and get rid of tinydrm.ko by moving stuff
> >> elsewhere as it's kind of a middle layer. So I'd really like to avoid
> >> adding a callback like this.
> >> Hopefully we can work out a solution based on my suggestion in the
> >> 'drm: Eliminate plane->fb/crtc usage for atomic drivers' thread.
> > I don't want to start redesigning the entire architecture at
> > this point. That would also cause a bigger risk of regression and
> > then we'd potentially have to try and revert the entire plane->fb
> > thing, which would not be fun if any significant changes have
> > occurred in the meantime.
> >
> >> If we do need a hook, I prefer that we add it to
> >> drm_simple_display_pipe_funcs.
> > If you have plans to redesign tinydrm anyway it seems to me that
> > a temporary hook in tinydrm is may be a bit less intrusive than
> > inflicting it on the simple_kms_helper.
> 
> Yes you're right of course, what was I thinking.
> 
> You missed out on one call site:
> 
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c 
> b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> index 11ae950b0fc9..7924eb59c2e1 100644
> --- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> @@ -124,11 +124,8 @@ void tinydrm_display_pipe_update(struct 
> drm_simple_display_pipe *pipe,
>      struct drm_framebuffer *fb = pipe->plane.state->fb;
>      struct drm_crtc *crtc = >pipe.crtc;
> 
> -   if (fb && (fb != old_state->fb)) {
> -   pipe->plane.fb = fb;
> -   if (fb->funcs->dirty)
> -   fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
> -   }
> +   if (fb && (fb != old_state->fb))
> +   tdev->fb_dirty(fb, NULL, 0, 0, NULL, 0);
> 
>      if (crtc->state->event) {
>      spin_lock_irq(>dev->event_lock);
> 
> With that fixed, series is:
> 
> Reviewed-by: Noralf Trønnes 

Awesome. Thanks. And thanks for catching that extra dirty() call. I'll
go and fix it up.

> 
> To be honest I don't understand why it's necessary to wire through the
> plane state to the enable hook instead of just looking it up on the pipe
> object. You look it up on the pipe in tinydrm_fb_dirty(), and I look up
> the new plane state and crtc state on the pipe in the update hook.

The use of plane->state etc. isn't really the best practice. What
we really should be doing is plumbing down the drm_atomic_state
instead, which would allow us to look up the correct new state
explicitly. That said, I guess there is something in the helpers
to prevent the next swap_state() from overtaking the previous
commit, so supposedly using plane->state etc. does actually result
in the correct thing currently.

In this case since we were already plumbing down the new crtc
state I figured I'd just plumb down its friend as well.

> 
> Noralf.
> 
> 
> > But if you do prefer
> > drm_simple_display_pipe_funcs I can move it there of course.
> >
> >> Noralf.
> >>
> >>> Cc: "Noralf Trønnes" 
> >>> Cc: David Lechner 
> >>> Signed-off-by: Ville Syrjälä 
> >>> ---
> >>>drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30 
> >>> ++
> >>>drivers/gpu/drm/tinydrm/ili9225.c  | 23 
> >>> ++--
> >>>drivers/gpu/drm/tinydrm/mi0283qt.c |  2 +-
> >>>drivers/gpu/drm/tinydrm/mipi-dbi.c | 30 
> >>> ++
> >>>drivers/gpu/drm/tinydrm/repaper.c  | 28 
> >>> 
> >>>drivers/gpu/drm/tinydrm/st7586.c   | 23 
> >>> ++--
> >>>drivers/gpu/drm/tinydrm/st7735r.c  |  2 +-
> >>>include/drm/tinydrm/mipi-dbi.h |  4 +++-
> >>>include/drm/tinydrm/tinydrm-helpers.h  |  5 +
> >>>include/drm/tinydrm/tinydrm.h  |  4 
> >>>10 files changed, 76 insertions(+), 75 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
> >>> 

Re: [PATCH 0/8] Add GetFB2 ioctl

[Daniel Stone]

On 23 March 2018 at 13:42, Daniel Stone  wrote:
> This submission rights that historical wrong, which allows Xorg
> -background none to continue to work in the face of exotic buffers.
> I've written patches to Xorg to use this as UABI verification, and
> I'll post a link to that very shortly.

Et voila:
https://lists.x.org/archives/xorg-devel/2018-March/056363.html

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

[PATCH i-g-t 3/3] tests/kms_getfb: Add getfb2 tests

[Daniel Stone]

Mirroring addfb2, add tests for the new ioctl which will return us
information about framebuffers containing multiple buffers, as well as
modifiers.

Signed-off-by: Daniel Stone 
---
 tests/kms_getfb.c | 91 +++
 1 file changed, 91 insertions(+)

diff --git a/tests/kms_getfb.c b/tests/kms_getfb.c
index a9852626..b8583694 100644
--- a/tests/kms_getfb.c
+++ b/tests/kms_getfb.c
@@ -186,7 +186,96 @@ static void test_duplicate_handles(int fd)
do_ioctl(fd, DRM_IOCTL_MODE_RMFB, _id);
gem_close(fd, add.handles[0]);
}
+}
+
+static void test_getfb2(int fd)
+{
+   struct drm_mode_fb_cmd2 add_basic = {};
+
+   igt_fixture {
+   struct drm_mode_fb_cmd2 get = {};
+
+   add_basic.width = 1024;
+   add_basic.height = 1024;
+   add_basic.pixel_format = DRM_FORMAT_XRGB;
+   add_basic.pitches[0] = 1024*4;
+   add_basic.handles[0] = igt_create_bo_with_dimensions(fd, 1024, 
1024,
+   DRM_FORMAT_XRGB, 0, 0, NULL, NULL, NULL);
+   igt_assert(add_basic.handles[0]);
+   do_ioctl(fd, DRM_IOCTL_MODE_ADDFB2, _basic);
+
+   get.fb_id = add_basic.fb_id;
+   do_ioctl(fd, DRM_IOCTL_MODE_GETFB2, );
+   igt_assert_neq_u32(get.handles[0], 0);
+   gem_close(fd, get.handles[0]);
+   }
+
+   igt_subtest("getfb2-handle-zero") {
+   struct drm_mode_fb_cmd2 get = {};
+   do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB2, , ENOENT);
+   }
+
+   igt_subtest("getfb2-handle-closed") {
+   struct drm_mode_fb_cmd2 add = add_basic;
+   struct drm_mode_fb_cmd2 get = { };
+
+   add.handles[0] = igt_create_bo_with_dimensions(fd, 1024, 1024,
+   DRM_FORMAT_XRGB, 0, 0, NULL, NULL, NULL);
+   igt_assert(add.handles[0]);
+   do_ioctl(fd, DRM_IOCTL_MODE_ADDFB2, );
+   do_ioctl(fd, DRM_IOCTL_MODE_RMFB, _id);
 
+   get.fb_id = add.fb_id;
+   do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB2, , ENOENT);
+   gem_close(fd, add.handles[0]);
+   }
+
+   igt_subtest("getfb2-handle-not-fb") {
+   struct drm_mode_fb_cmd get = { .fb_id = get_prop_id(fd) };
+   igt_require(get.fb_id > 0);
+   do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB, , ENOENT);
+   }
+
+   igt_subtest("getfb2-accept-ccs") {
+   struct drm_mode_fb_cmd2 add_ccs = { };
+   struct drm_mode_fb_cmd2 get = { };
+   int i;
+
+   get_ccs_fb(fd, _ccs);
+   igt_require(add_ccs.fb_id != 0);
+   get.fb_id = add_ccs.fb_id;
+   do_ioctl(fd, DRM_IOCTL_MODE_GETFB2, );
+
+   igt_assert_eq_u32(get.width, add_ccs.width);
+   igt_assert_eq_u32(get.height, add_ccs.height);
+   igt_assert(get.flags & DRM_MODE_FB_MODIFIERS);
+
+   for (i = 0; i < ARRAY_SIZE(get.handles); i++) {
+   igt_assert_eq_u32(get.pitches[i], add_ccs.pitches[i]);
+   igt_assert_eq_u32(get.offsets[i], add_ccs.offsets[i]);
+   if (add_ccs.handles[i] != 0) {
+   igt_assert_neq_u32(get.handles[i], 0);
+   igt_assert_neq_u32(get.handles[i],
+  add_ccs.handles[i]);
+   igt_assert_eq_u64(get.modifier[i],
+ add_ccs.modifier[i]);
+   } else {
+   igt_assert_eq_u32(get.handles[i], 0);
+   igt_assert_eq_u64(get.modifier[i],
+ DRM_FORMAT_MOD_INVALID);
+   }
+   }
+   igt_assert_eq_u32(get.handles[0], get.handles[1]);
+
+   do_ioctl(fd, DRM_IOCTL_MODE_RMFB, _id);
+   gem_close(fd, add_ccs.handles[0]);
+   gem_close(fd, get.handles[0]);
+   }
+
+   igt_fixture {
+   do_ioctl(fd, DRM_IOCTL_MODE_RMFB, _basic.fb_id);
+   gem_close(fd, add_basic.handles[0]);
+   }
 }
 
 igt_main
@@ -200,6 +289,8 @@ igt_main
 
test_duplicate_handles(fd);
 
+   test_getfb2(fd);
+
igt_fixture
close(fd);
 }
-- 
2.16.2

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

[PATCH i-g-t 2/3] NOMERGE: Update DRM UAPI to latest kernel version

[Daniel Stone]

This depends on unmerged kernel code, so.
---
 include/drm-uapi/amdgpu_drm.h  | 1 +
 include/drm-uapi/drm.h | 1 +
 include/drm-uapi/drm_mode.h| 9 ++---
 include/drm-uapi/etnaviv_drm.h | 1 +
 include/drm-uapi/msm_drm.h | 9 -
 include/drm-uapi/virtgpu_drm.h | 1 +
 6 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/include/drm-uapi/amdgpu_drm.h b/include/drm-uapi/amdgpu_drm.h
index 1816bd82..528f6d04 100644
--- a/include/drm-uapi/amdgpu_drm.h
+++ b/include/drm-uapi/amdgpu_drm.h
@@ -806,6 +806,7 @@ struct drm_amdgpu_info_firmware {
 #define AMDGPU_VRAM_TYPE_GDDR5 5
 #define AMDGPU_VRAM_TYPE_HBM   6
 #define AMDGPU_VRAM_TYPE_DDR3  7
+#define AMDGPU_VRAM_TYPE_DDR4  8
 
 struct drm_amdgpu_info_device {
/** PCI Device ID */
diff --git a/include/drm-uapi/drm.h b/include/drm-uapi/drm.h
index f0bd91de..c0a35878 100644
--- a/include/drm-uapi/drm.h
+++ b/include/drm-uapi/drm.h
@@ -886,6 +886,7 @@ extern "C" {
 #define DRM_IOCTL_MODE_LIST_LESSEESDRM_IOWR(0xC7, struct 
drm_mode_list_lessees)
 #define DRM_IOCTL_MODE_GET_LEASE   DRM_IOWR(0xC8, struct 
drm_mode_get_lease)
 #define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct 
drm_mode_revoke_lease)
+#define DRM_IOCTL_MODE_GETFB2  DRM_IOWR(0xCA, struct drm_mode_fb_cmd2)
 
 /**
  * Device specific ioctls should only be in their respective headers
diff --git a/include/drm-uapi/drm_mode.h b/include/drm-uapi/drm_mode.h
index 2c575794..50bcf421 100644
--- a/include/drm-uapi/drm_mode.h
+++ b/include/drm-uapi/drm_mode.h
@@ -363,7 +363,7 @@ struct drm_mode_get_connector {
__u32 pad;
 };
 
-#define DRM_MODE_PROP_PENDING  (1<<0)
+#define DRM_MODE_PROP_PENDING  (1<<0) /* deprecated, do not use */
 #define DRM_MODE_PROP_RANGE(1<<1)
 #define DRM_MODE_PROP_IMMUTABLE(1<<2)
 #define DRM_MODE_PROP_ENUM (1<<3) /* enumerated type with text strings */
@@ -598,8 +598,11 @@ struct drm_mode_crtc_lut {
 };
 
 struct drm_color_ctm {
-   /* Conversion matrix in S31.32 format. */
-   __s64 matrix[9];
+   /*
+* Conversion matrix in S31.32 sign-magnitude
+* (not two's complement!) format.
+*/
+   __u64 matrix[9];
 };
 
 struct drm_color_lut {
diff --git a/include/drm-uapi/etnaviv_drm.h b/include/drm-uapi/etnaviv_drm.h
index e9b997a0..71958c80 100644
--- a/include/drm-uapi/etnaviv_drm.h
+++ b/include/drm-uapi/etnaviv_drm.h
@@ -145,6 +145,7 @@ struct drm_etnaviv_gem_submit_reloc {
  */
 #define ETNA_SUBMIT_BO_READ 0x0001
 #define ETNA_SUBMIT_BO_WRITE0x0002
+#define ETNA_SUBMIT_BO_NO_IMPLICIT  0x0004
 struct drm_etnaviv_gem_submit_bo {
__u32 flags;  /* in, mask of ETNA_SUBMIT_BO_x */
__u32 handle; /* in, GEM handle */
diff --git a/include/drm-uapi/msm_drm.h b/include/drm-uapi/msm_drm.h
index bbbaffad..57a67fb3 100644
--- a/include/drm-uapi/msm_drm.h
+++ b/include/drm-uapi/msm_drm.h
@@ -188,8 +188,13 @@ struct drm_msm_gem_submit_cmd {
  */
 #define MSM_SUBMIT_BO_READ 0x0001
 #define MSM_SUBMIT_BO_WRITE0x0002
+#define MSM_SUBMIT_BO_NO_IMPLICIT  0x0004 /* disable implicit sync */
 
-#define MSM_SUBMIT_BO_FLAGS(MSM_SUBMIT_BO_READ | 
MSM_SUBMIT_BO_WRITE)
+#define MSM_SUBMIT_BO_FLAGS( \
+   MSM_SUBMIT_BO_READ  | \
+   MSM_SUBMIT_BO_WRITE | \
+   MSM_SUBMIT_BO_NO_IMPLICIT   | \
+   0)
 
 struct drm_msm_gem_submit_bo {
__u32 flags;  /* in, mask of MSM_SUBMIT_BO_x */
@@ -201,10 +206,12 @@ struct drm_msm_gem_submit_bo {
 #define MSM_SUBMIT_NO_IMPLICIT   0x8000 /* disable implicit sync */
 #define MSM_SUBMIT_FENCE_FD_IN   0x4000 /* enable input fence_fd */
 #define MSM_SUBMIT_FENCE_FD_OUT  0x2000 /* enable output fence_fd */
+#define MSM_SUBMIT_SUDO  0x1000 /* run submitted cmds from RB */
 #define MSM_SUBMIT_FLAGS( \
MSM_SUBMIT_NO_IMPLICIT   | \
MSM_SUBMIT_FENCE_FD_IN   | \
MSM_SUBMIT_FENCE_FD_OUT  | \
+   MSM_SUBMIT_SUDO  | \
0)
 
 /* Each cmdstream submit consists of a table of buffers involved, and
diff --git a/include/drm-uapi/virtgpu_drm.h b/include/drm-uapi/virtgpu_drm.h
index 91a31ffe..9a781f06 100644
--- a/include/drm-uapi/virtgpu_drm.h
+++ b/include/drm-uapi/virtgpu_drm.h
@@ -63,6 +63,7 @@ struct drm_virtgpu_execbuffer {
 };
 
 #define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw */
+#define VIRTGPU_PARAM_CAPSET_QUERY_FIX 2 /* do we have the capset fix */
 
 struct drm_virtgpu_getparam {
__u64 param;
-- 
2.16.2

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

[PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.

Signed-off-by: Daniel Stone 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: intel-...@lists.freedesktop.org
---
 drivers/gpu/drm/i915/intel_display.c | 15 ---
 drivers/gpu/drm/i915/intel_drv.h |  3 +--
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 49b0772e9abc..e8100a4fc877 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13916,7 +13916,8 @@ static void intel_user_framebuffer_destroy(struct 
drm_framebuffer *fb)
drm_framebuffer_cleanup(fb);
 
i915_gem_object_lock(obj);
-   WARN_ON(!obj->framebuffer_references--);
+   WARN_ON(obj->framebuffer_references < fb->format->num_planes);
+   obj->framebuffer_references -= fb->format->num_planes;
i915_gem_object_unlock(obj);
 
i915_gem_object_put(obj);
@@ -14176,9 +14177,9 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
  i, fb->pitches[i], stride_alignment);
goto err;
}
-   }
 
-   intel_fb->obj = obj;
+   fb->obj[i] = >base;
+   }
 
ret = intel_fill_fb_info(dev_priv, fb);
if (ret)
@@ -14190,6 +14191,14 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
 
+   /* We already hold one reference to the fb, but in case it's
+* multi-planar and we've placed multiple pointers in
+* drm_framebuffer, hold extra refs.
+*/
+   i915_gem_object_lock(obj);
+   obj->framebuffer_references += fb->format->num_planes - 1;
+   i915_gem_object_unlock(obj);
+
return 0;
 
 err:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 570f89b31544..d93ed9e59867 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -186,7 +186,6 @@ enum intel_output_type {
 
 struct intel_framebuffer {
struct drm_framebuffer base;
-   struct drm_i915_gem_object *obj;
struct intel_rotation_info rot_info;
 
/* for each plane in the normal GTT view */
@@ -985,7 +984,7 @@ struct cxsr_latency {
 #define to_intel_framebuffer(x) container_of(x, struct intel_framebuffer, base)
 #define to_intel_plane(x) container_of(x, struct intel_plane, base)
 #define to_intel_plane_state(x) container_of(x, struct intel_plane_state, base)
-#define intel_fb_obj(x) (x ? to_intel_framebuffer(x)->obj : NULL)
+#define intel_fb_obj(x) (((x) && (x)->obj[0]) ? to_intel_bo((x)->obj[0]) : 
NULL)
 
 struct intel_hdmi {
i915_reg_t hdmi_reg;
-- 
2.16.2

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

[PATCH 1/4] drm/i915: Use intel_fb_obj() everywhere

[Daniel Stone]

We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.

Signed-off-by: Daniel Stone 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: intel-...@lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  4 ++--
 drivers/gpu/drm/i915/intel_display.c | 19 ++-
 drivers/gpu/drm/i915/intel_fbdev.c   |  9 +
 3 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7816cd53100a..68541df6f601 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1893,7 +1893,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m, 
void *data)
   fbdev_fb->base.format->cpp[0] * 8,
   fbdev_fb->base.modifier,
   drm_framebuffer_read_refcount(_fb->base));
-   describe_obj(m, fbdev_fb->obj);
+   describe_obj(m, intel_fb_obj(_fb->base));
seq_putc(m, '\n');
}
 #endif
@@ -1911,7 +1911,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m, 
void *data)
   fb->base.format->cpp[0] * 8,
   fb->base.modifier,
   drm_framebuffer_read_refcount(>base));
-   describe_obj(m, fb->obj);
+   describe_obj(m, intel_fb_obj(>base));
seq_putc(m, '\n');
}
mutex_unlock(>mode_config.fb_lock);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1b16b534871a..49b0772e9abc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2478,6 +2478,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
 {
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct intel_rotation_info *rot_info = _fb->rot_info;
+   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
u32 gtt_offset_rotated = 0;
unsigned int max_size = 0;
int i, num_planes = fb->format->num_planes;
@@ -2542,7 +2543,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
 * fb layout agrees with the fence layout. We already check 
that the
 * fb stride matches the fence stride elsewhere.
 */
-   if (i == 0 && i915_gem_object_is_tiled(intel_fb->obj) &&
+   if (i == 0 && i915_gem_object_is_tiled(obj) &&
(x + width) * cpp > fb->pitches[i]) {
DRM_DEBUG_KMS("bad fb plane %d offset: 0x%x\n",
  i, fb->offsets[i]);
@@ -2627,9 +2628,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
max_size = max(max_size, offset + size);
}
 
-   if (max_size * tile_size > intel_fb->obj->base.size) {
+   if (max_size * tile_size > obj->base.size) {
DRM_DEBUG_KMS("fb too big for bo (need %u bytes, have %zu 
bytes)\n",
- max_size * tile_size, intel_fb->obj->base.size);
+ max_size * tile_size, obj->base.size);
return -EINVAL;
}
 
@@ -13910,14 +13911,15 @@ static void intel_setup_outputs(struct 
drm_i915_private *dev_priv)
 static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
 {
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
 
drm_framebuffer_cleanup(fb);
 
-   i915_gem_object_lock(intel_fb->obj);
-   WARN_ON(!intel_fb->obj->framebuffer_references--);
-   i915_gem_object_unlock(intel_fb->obj);
+   i915_gem_object_lock(obj);
+   WARN_ON(!obj->framebuffer_references--);
+   i915_gem_object_unlock(obj);
 
-   i915_gem_object_put(intel_fb->obj);
+   i915_gem_object_put(obj);
 
kfree(intel_fb);
 }
@@ -13926,8 +13928,7 @@ static int intel_user_framebuffer_create_handle(struct 
drm_framebuffer *fb,
struct drm_file *file,
unsigned int *handle)
 {
-   struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
-   struct drm_i915_gem_object *obj = intel_fb->obj;
+   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
 
if (obj->userptr.mm) {
DRM_DEBUG("attempting to use a userptr for a framebuffer, 
denied\n");
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 65a3313723c9..fdef18488fb1 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -47,7 +47,7 @@
 
 static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
 {
-   struct 

[PATCH i-g-t 1/3] tests/kms_getfb: Split property-ID get into helper

[Daniel Stone]

We'll want to reuse this, so split it out into a (smaller!) helper.

Signed-off-by: Daniel Stone 
---
 tests/kms_getfb.c | 36 +++-
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/tests/kms_getfb.c b/tests/kms_getfb.c
index c5968e75..a9852626 100644
--- a/tests/kms_getfb.c
+++ b/tests/kms_getfb.c
@@ -72,6 +72,23 @@ static void get_ccs_fb(int fd, struct drm_mode_fb_cmd2 *ret)
gem_close(fd, add.handles[0]);
 }
 
+/**
+ * Find and return an arbitrary valid property ID.
+ */
+static uint32_t get_prop_id(int fd)
+{
+   igt_display_t display;
+
+   igt_display_init(, fd);
+   for (int i = 0; i < display.n_outputs; i++) {
+   igt_output_t *output = [i];
+   if (output->props[IGT_CONNECTOR_DPMS] != 0)
+   return output->props[IGT_CONNECTOR_DPMS];
+   }
+
+   return 0;
+}
+
 static void test_handle_input(int fd)
 {
struct drm_mode_fb_cmd2 add = {};
@@ -111,23 +128,8 @@ static void test_handle_input(int fd)
}
 
igt_subtest("getfb-handle-not-fb") {
-   struct drm_mode_fb_cmd get = { };
-   uint32_t prop_id = 0;
-   igt_display_t display;
-
-   /* Find a valid property ID to use. */
-   igt_display_init(, fd);
-   for (int i = 0; i < display.n_outputs; i++) {
-   igt_output_t *output = [i];
-
-   if (output->props[IGT_CONNECTOR_DPMS] != 0) {
-   prop_id = output->props[IGT_CONNECTOR_DPMS];
-   break;
-   }
-   }
-   igt_require(prop_id > 0);
-
-   get.fb_id = prop_id;
+   struct drm_mode_fb_cmd get = { .fb_id = get_prop_id(fd) };
+   igt_require(get.fb_id > 0);
do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB, , ENOENT);
}
 }
-- 
2.16.2

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

[PATCH 3/4] drm: Reshuffle getfb error returns

[Daniel Stone]

Make it a little more clear what's going on inside of getfb, and also
make it easier to add alternate paths to get a handle in future.

Signed-off-by: Daniel Stone 
---
 drivers/gpu/drm/drm_framebuffer.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index ad67203de715..6d5ff541225a 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -468,29 +468,30 @@ int drm_mode_getfb(struct drm_device *dev,
goto out;
}
 
+   if (!fb->funcs->create_handle) {
+   ret = -ENODEV;
+   goto out;
+   }
+
r->height = fb->height;
r->width = fb->width;
r->depth = fb->format->depth;
r->bpp = fb->format->cpp[0] * 8;
r->pitch = fb->pitches[0];
-   if (fb->funcs->create_handle) {
-   if (drm_is_current_master(file_priv) || capable(CAP_SYS_ADMIN) 
||
-   drm_is_control_client(file_priv)) {
-   ret = fb->funcs->create_handle(fb, file_priv,
-  >handle);
-   } else {
-   /* GET_FB() is an unprivileged ioctl so we must not
-* return a buffer-handle to non-master processes! For
-* backwards-compatibility reasons, we cannot make
-* GET_FB() privileged, so just return an invalid handle
-* for non-masters. */
-   r->handle = 0;
-   ret = 0;
-   }
-   } else {
-   ret = -ENODEV;
+
+   /* GET_FB() is an unprivileged ioctl so we must not return a
+* buffer-handle to non-master processes! For
+* backwards-compatibility reasons, we cannot make GET_FB() privileged,
+* so just return an invalid handle for non-masters. */
+   if (!drm_is_current_master(file_priv) && !capable(CAP_SYS_ADMIN) &&
+   !drm_is_control_client(file_priv)) {
+   r->handle = 0;
+   ret = 0;
+   goto out;
}
 
+   ret = fb->funcs->create_handle(fb, file_priv, >handle);
+
 out:
drm_framebuffer_put(fb);
 
-- 
2.16.2

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

[PATCH 4/4] drm: Add getfb2 ioctl

[Daniel Stone]

getfb2 allows us to pass multiple planes and modifiers, just like addfb2
over addfb.

Signed-off-by: Daniel Stone 
---
 drivers/gpu/drm/drm_crtc_internal.h |   2 +
 drivers/gpu/drm/drm_framebuffer.c   | 109 
 drivers/gpu/drm/drm_ioctl.c |   2 +
 include/uapi/drm/drm.h  |   1 +
 4 files changed, 114 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 3c2b82865ad2..0cd02f3d203d 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -173,6 +173,8 @@ int drm_mode_rmfb(struct drm_device *dev,
  void *data, struct drm_file *file_priv);
 int drm_mode_getfb(struct drm_device *dev,
   void *data, struct drm_file *file_priv);
+int drm_mode_getfb2_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
 int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv);
 
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 6d5ff541225a..f1cfb6ddc776 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -494,7 +495,115 @@ int drm_mode_getfb(struct drm_device *dev,
 
 out:
drm_framebuffer_put(fb);
+   return ret;
+}
+
+/**
+ * drm_mode_getfb2 - get extended FB info
+ * @dev: drm device for the ioctl
+ * @data: data pointer for the ioctl
+ * @file_priv: drm file for the ioctl call
+ *
+ * Lookup the FB given its ID and return info about it.
+ *
+ * Called by the user via ioctl.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_getfb2_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+   struct drm_mode_fb_cmd2 *r = data;
+   struct drm_framebuffer *fb;
+   unsigned int i;
+   int ret;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
 
+   fb = drm_framebuffer_lookup(dev, file_priv, r->fb_id);
+   if (!fb)
+   return -ENOENT;
+
+   /* For multi-plane framebuffers, we require the driver to place the
+* GEM objects directly in the drm_framebuffer. For single-plane
+* framebuffers, we can fall back to create_handle.
+*/
+   if (!fb->obj[0] &&
+   (fb->format->num_planes > 1 || !fb->funcs->create_handle)) {
+   ret = -ENODEV;
+   goto out;
+   }
+
+   r->height = fb->height;
+   r->width = fb->width;
+   r->pixel_format = fb->format->format;
+
+   r->flags = 0;
+   if (dev->mode_config.allow_fb_modifiers)
+   r->flags |= DRM_MODE_FB_MODIFIERS;
+
+   for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
+   r->handles[i] = 0;
+   r->pitches[i] = 0;
+   r->offsets[i] = 0;
+   r->modifier[i] = DRM_FORMAT_MOD_INVALID;
+   }
+
+   for (i = 0; i < fb->format->num_planes; i++) {
+   int j;
+
+   r->pitches[i] = fb->pitches[i];
+   r->offsets[i] = fb->offsets[i];
+   if (dev->mode_config.allow_fb_modifiers)
+   r->modifier[i] = fb->modifier;
+
+   /* If we reuse the same object for multiple planes, also
+* return the same handle.
+*/
+   for (j = 0; j < i; j++) {
+   if (fb->obj[i] == fb->obj[j]) {
+   r->handles[i] = r->handles[j];
+   break;
+   }
+   }
+
+   if (r->handles[i])
+   continue;
+
+   if (fb->obj[i]) {
+   ret = drm_gem_handle_create(file_priv, fb->obj[i],
+   >handles[i]);
+   } else {
+   WARN_ON(i > 0);
+   ret = fb->funcs->create_handle(fb, file_priv,
+  >handles[i]);
+   }
+
+   if (ret != 0)
+   goto out;
+   }
+
+out:
+   if (ret != 0) {
+   /* Delete any previously-created handles on failure. */
+   for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
+   int j;
+
+   if (r->handles[i])
+   drm_gem_handle_delete(file_priv, r->handles[i]);
+
+   /* Zero out any handles identical to the one we just
+* deleted. */
+   for (j = i + 1; j < ARRAY_SIZE(r->handles); j++) {
+   if (r->handles[j] == r->handles[i])
+   r->handles[j] = 0;
+   

[PATCH libdrm] NOMERGE: Add drmModeGetFB2

[Daniel Stone]

Add a wrapper around the getfb2 ioctl, which returns extended
framebuffer information mirroring addfb2, including multiple planes and
modifiers.

This depends on unmerged kernel API so should not be merged.
---
 include/drm/drm.h |  1 +
 xf86drmMode.c | 40 
 xf86drmMode.h | 15 +++
 3 files changed, 56 insertions(+)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index f0bd91de..c0a35878 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -886,6 +886,7 @@ extern "C" {
 #define DRM_IOCTL_MODE_LIST_LESSEESDRM_IOWR(0xC7, struct 
drm_mode_list_lessees)
 #define DRM_IOCTL_MODE_GET_LEASE   DRM_IOWR(0xC8, struct 
drm_mode_get_lease)
 #define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct 
drm_mode_revoke_lease)
+#define DRM_IOCTL_MODE_GETFB2  DRM_IOWR(0xCA, struct drm_mode_fb_cmd2)
 
 /**
  * Device specific ioctls should only be in their respective headers
diff --git a/xf86drmMode.c b/xf86drmMode.c
index cf8e1eac..d8cf6a0c 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -1582,3 +1582,43 @@ drmModeRevokeLease(int fd, uint32_t lessee_id)
return 0;
return -errno;
 }
+
+drmModeFB2Ptr
+drmModeGetFB2(int fd, uint32_t fb_id)
+{
+   struct drm_mode_fb_cmd2 get;
+   drmModeFB2Ptr ret;
+   int err;
+
+   memclear(get);
+   get.fb_id = fb_id;
+
+   err = DRM_IOCTL(fd, DRM_IOCTL_MODE_GETFB2, );
+   if (err != 0)
+   return NULL;
+
+   ret = drmMalloc(sizeof(drmModeFB2));
+   if (!ret)
+   return NULL;
+
+   ret->fb_id = fb_id;
+   ret->width = get.width;
+   ret->height = get.height;
+   ret->pixel_format = get.pixel_format;
+   ret->flags = get.flags;
+   ret->modifier = get.modifier[0];
+   memcpy(ret->handles, get.handles, sizeof(uint32_t) * 4);
+   memcpy(ret->pitches, get.pitches, sizeof(uint32_t) * 4);
+   memcpy(ret->offsets, get.offsets, sizeof(uint32_t) * 4);
+
+   return ret;
+}
+
+void drmModeFreeFB2(drmModeFB2Ptr ptr)
+{
+   if (!ptr)
+   return;
+
+   /* we might add more frees later. */
+   drmFree(ptr);
+}
diff --git a/xf86drmMode.h b/xf86drmMode.h
index 3cd27aee..70741c77 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -223,6 +223,19 @@ typedef struct _drmModeFB {
uint32_t handle;
 } drmModeFB, *drmModeFBPtr;
 
+typedef struct _drmModeFB2 {
+   uint32_t fb_id;
+   uint32_t width, height;
+   uint32_t pixel_format; /* fourcc code from drm_fourcc.h */
+   uint32_t modifier; /* applies to all buffers */
+   uint32_t flags;
+
+   /* per-plane GEM handle; may be duplicate entries for multiple planes */
+   uint32_t handles[4];
+   uint32_t pitches[4]; /* bytes */
+   uint32_t offsets[4]; /* bytes */
+} drmModeFB2, *drmModeFB2Ptr;
+
 typedef struct drm_clip_rect drmModeClip, *drmModeClipPtr;
 
 typedef struct _drmModePropertyBlob {
@@ -341,6 +354,7 @@ typedef struct _drmModePlaneRes {
 extern void drmModeFreeModeInfo( drmModeModeInfoPtr ptr );
 extern void drmModeFreeResources( drmModeResPtr ptr );
 extern void drmModeFreeFB( drmModeFBPtr ptr );
+extern void drmModeFreeFB2( drmModeFB2Ptr ptr );
 extern void drmModeFreeCrtc( drmModeCrtcPtr ptr );
 extern void drmModeFreeConnector( drmModeConnectorPtr ptr );
 extern void drmModeFreeEncoder( drmModeEncoderPtr ptr );
@@ -360,6 +374,7 @@ extern drmModeResPtr drmModeGetResources(int fd);
  * Retrive information about framebuffer bufferId
  */
 extern drmModeFBPtr drmModeGetFB(int fd, uint32_t bufferId);
+extern drmModeFB2Ptr drmModeGetFB2(int fd, uint32_t bufferId);
 
 /**
  * Creates a new framebuffer with an buffer object as its scanout buffer.
-- 
2.16.2

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

[PATCH 0/8] Add GetFB2 ioctl

[Daniel Stone]

Hi,
AddFB is single-planar, with no offset and only depth/bpp rather than
an explicit format, so we now have AddFB2 which can carry multiple
planes, an explicit format and also a modifier. At the time we never
actually did GetFB2 to go with GetFB.

This submission rights that historical wrong, which allows Xorg
-background none to continue to work in the face of exotic buffers.
I've written patches to Xorg to use this as UABI verification, and
I'll post a link to that very shortly.

This is also available in git form, in the wip/2018-03/getfb2 branches of:
https://gitlab.collabora.com/daniels/linux
https://gitlab.collabora.com/daniels/libdrm
https://gitlab.collabora.com/daniels/igt-gpu-tools
https://gitlab.collabora.com/daniels/xserver

Note that the kernel tree is based on top of drm-tip, and has a bunch
of patches to convert drivers to placing objects (rather than creating
handles). At the moment this is just missing amdgpu and nouveau to
complete the set of drivers, and also any testing whatsoever; I'm
sending a patch to convert Intel as that's what I've actually tested
on.

The conversion is necessary since GetFB2 ensures that it does _not_
return duplicate handles if multiple planes of a single buffer share
the same BO. This is impossible if we just use create_handle from the
driver, so instead we just rely on drivers placing the GEM object
pointers in the drm_framebuffer directly. This has the added advantage
of cleaning up a ton of unnecessary code in drivers.

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

Re: [PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook

[Noralf Trønnes]

Den 23.03.2018 12.31, skrev Ville Syrjälä:

On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:


Den 22.03.2018 21.27, skrev Ville Syrjala:

From: Ville Syrjälä 

mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us from taking the
plane mutex in fb->dirty() unless we also plumb down the acquire
context.

Instead it seems simpler to split the fb->dirty() into a tinydrm
specific lower level hook that can be called from
mipi_dbi_enable_flush() and from a generic higher level
tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
vfuncs table we'll just stick it into tinydrm_device directly
for now.

The long term goal is to try and get rid of tinydrm.ko by moving stuff
elsewhere as it's kind of a middle layer. So I'd really like to avoid
adding a callback like this.
Hopefully we can work out a solution based on my suggestion in the
'drm: Eliminate plane->fb/crtc usage for atomic drivers' thread.

I don't want to start redesigning the entire architecture at
this point. That would also cause a bigger risk of regression and
then we'd potentially have to try and revert the entire plane->fb
thing, which would not be fun if any significant changes have
occurred in the meantime.


If we do need a hook, I prefer that we add it to
drm_simple_display_pipe_funcs.

If you have plans to redesign tinydrm anyway it seems to me that
a temporary hook in tinydrm is may be a bit less intrusive than
inflicting it on the simple_kms_helper.


Yes you're right of course, what was I thinking.

You missed out on one call site:

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c

index 11ae950b0fc9..7924eb59c2e1 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
@@ -124,11 +124,8 @@ void tinydrm_display_pipe_update(struct 
drm_simple_display_pipe *pipe,

    struct drm_framebuffer *fb = pipe->plane.state->fb;
    struct drm_crtc *crtc = >pipe.crtc;

-   if (fb && (fb != old_state->fb)) {
-   pipe->plane.fb = fb;
-   if (fb->funcs->dirty)
-   fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
-   }
+   if (fb && (fb != old_state->fb))
+   tdev->fb_dirty(fb, NULL, 0, 0, NULL, 0);

    if (crtc->state->event) {
    spin_lock_irq(>dev->event_lock);

With that fixed, series is:

Reviewed-by: Noralf Trønnes 

To be honest I don't understand why it's necessary to wire through the
plane state to the enable hook instead of just looking it up on the pipe
object. You look it up on the pipe in tinydrm_fb_dirty(), and I look up
the new plane state and crtc state on the pipe in the update hook.

Noralf.



But if you do prefer
drm_simple_display_pipe_funcs I can move it there of course.


Noralf.


Cc: "Noralf Trønnes" 
Cc: David Lechner 
Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30 
++
   drivers/gpu/drm/tinydrm/ili9225.c  | 23 ++--
   drivers/gpu/drm/tinydrm/mi0283qt.c |  2 +-
   drivers/gpu/drm/tinydrm/mipi-dbi.c | 30 
++
   drivers/gpu/drm/tinydrm/repaper.c  | 28 
   drivers/gpu/drm/tinydrm/st7586.c   | 23 ++--
   drivers/gpu/drm/tinydrm/st7735r.c  |  2 +-
   include/drm/tinydrm/mipi-dbi.h |  4 +++-
   include/drm/tinydrm/tinydrm-helpers.h  |  5 +
   include/drm/tinydrm/tinydrm.h  |  4 
   10 files changed, 76 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d1c3ce9ab294..dcd390163a4a 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -78,6 +78,36 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
   }
   EXPORT_SYMBOL(tinydrm_merge_clips);
   
+int tinydrm_fb_dirty(struct drm_framebuffer *fb,

+struct drm_file *file_priv,
+unsigned int flags, unsigned int color,
+struct drm_clip_rect *clips,
+unsigned int num_clips)
+{
+   struct tinydrm_device *tdev = fb->dev->dev_private;
+   struct drm_plane *plane = >pipe.plane;
+   int ret = 0;
+
+   drm_modeset_lock(>mutex, NULL);
+
+   /* fbdev can flush even when we're not interested */
+   if (plane->state->fb == fb) {
+   mutex_lock(>dirty_lock);
+   ret = tdev->fb_dirty(fb, file_priv, flags,
+color, clips, num_clips);
+   mutex_unlock(>dirty_lock);
+   }
+
+   drm_modeset_unlock(>mutex);

[PATCH libdrm] tests/util: Add support for sun4i-drm module

[Jonathan Liu]

Add support for sun4i DRM driver merged for Linux 4.7.

Signed-off-by: Jonathan Liu 
---
 tests/util/kms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/util/kms.c b/tests/util/kms.c
index 8b3e7878..ffae2531 100644
--- a/tests/util/kms.c
+++ b/tests/util/kms.c
@@ -144,6 +144,7 @@ static const char * const modules[] = {
"mediatek",
"meson",
"pl111",
+   "sun4i-drm",
 };
 
 int util_open(const char *device, const char *module)
-- 
2.16.2

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

[PATCHv2 3/3] arm64: dts: meson-gx.dtsi: add cec-disable

[Hans Verkuil]

From: Hans Verkuil 

The meson-gx boards have two CEC controllers: the DesignWare controller
and a meson-specific controller. Disable the DW controller since the
CEC line is hooked up to the meson controller.

Signed-off-by: Hans Verkuil 
Acked-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 4ee2e7951482..4e2567012335 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -544,6 +544,7 @@
interrupts = ;
#address-cells = <1>;
#size-cells = <0>;
+   cec-disable;
status = "disabled";
 
/* VPU VENC Input */
-- 
2.15.1

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

[PATCHv2 0/3] dw-hdmi: add property to disable CEC

[Hans Verkuil]

From: Hans Verkuil 

Some boards (amlogic) have two CEC controllers: the DesignWare controller
and their own CEC controller (meson ao-cec).

Since the CEC line is not hooked up to the DW controller we need a way
to disable that controller. This patch series adds the cec-disable
property for that purpose.

Regards,

Hans

Changes since v1:

- Move the dts change to meson-gx.dtsi since according to Neil it is
  valid for all meson-gx boards.
- Fix bad subject line of patch 1.

Hans Verkuil (3):
  dt-bindings: display: dw_hdmi.txt: add cec-disable property
  drm: bridge: dw-hdmi: check the cec-disable property
  arm64: dts: meson-gx.dtsi: add cec-disable

 Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt | 3 +++
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi| 1 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c| 3 ++-
 3 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.15.1

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

[PATCHv2 2/3] drm: bridge: dw-hdmi: check the cec-disable property

[Hans Verkuil]

From: Hans Verkuil 

If the cec-disable property was set, then disable the DW CEC
controller. This is needed for boards that have their own
CEC controller.

Signed-off-by: Hans Verkuil 
Reviewed-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..597220e40541 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2508,7 +2508,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi->audio = platform_device_register_full();
}
 
-   if (config0 & HDMI_CONFIG0_CEC) {
+   if ((config0 & HDMI_CONFIG0_CEC) &&
+   !of_property_read_bool(np, "cec-disable")) {
cec.hdmi = hdmi;
cec.ops = _hdmi_cec_ops;
cec.irq = irq;
-- 
2.15.1

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

[PATCHv2 1/3] dt-bindings: display: dw_hdmi.txt: add cec-disable property

[Hans Verkuil]

From: Hans Verkuil 

Some boards have both a DesignWare and their own CEC controller.
The CEC pin is only hooked up to their own CEC controller and not
to the DW controller.

Add the cec-disable property to disable the DW CEC controller.

This particular situation happens on Amlogic boards that have their
own meson CEC controller.

Signed-off-by: Hans Verkuil 
Acked-by: Neil Armstrong 
---
 Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt 
b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
index 33bf981fbe33..4a13f4858bc0 100644
--- a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
@@ -27,6 +27,9 @@ responsible for defining whether each property is required or 
optional.
   - "isfr" is the internal register configuration clock (mandatory).
   - "cec" is the HDMI CEC controller main clock (optional).
 
+- cec-disable: Do not use the DWC CEC controller since the CEC line is not
+  hooked up even though the CEC DWC IP is present.
+
 - ports: The connectivity of the DWC HDMI TX with the rest of the system is
   expressed in using ports as specified in the device graph bindings defined
   in Documentation/devicetree/bindings/graph.txt. The numbering of the ports
-- 
2.15.1

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

[PATCH] drm/omap: fix memory barrier bug in DMM driver

[Peter Ujfalusi]

From: Tomi Valkeinen 

A DMM timeout "timed out waiting for done" has been observed on DRA7
devices. The timeout happens rarely, and only when the system is under
heavy load.

Debugging showed that the timeout can be made to happen much more
frequently by optimizing the DMM driver, so that there's almost no code
between writing the last DMM descriptors to RAM, and writing to DMM
register which starts the DMM transaction.

The current theory is that a wmb() does not properly ensure that the
data written to RAM is observable by all the components in the system.

This DMM timeout has caused interesting (and rare) bugs as the error
handling was not functioning properly (the error handling has been fixed
in previous commits):

 * If a DMM timeout happened when a GEM buffer was being pinned for
   display on the screen, a timeout error would be shown, but the driver
   would continue programming DSS HW with broken buffer, leading to
   SYNCLOST floods and possible crashes.

 * If a DMM timeout happened when other user (say, video decoder) was
   pinning a GEM buffer, a timeout would be shown but if the user
   handled the error properly, no other issues followed.

 * If a DMM timeout happened when a GEM buffer was being released, the
   driver does not even notice the error, leading to crashes or hang
   later.

This patch adds wmb() and readl() calls after the last bit is written to
RAM, which should ensure that the execution proceeds only after the data
is actually in RAM, and thus observable by DMM.

The read-back should not be needed. Further study is required to understand
if DMM is somehow special case and read-back is ok, or if DRA7's memory
barriers do not work correctly.

Signed-off-by: Tomi Valkeinen 
Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index c40f90d2db82..27c67bc36203 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -410,6 +410,17 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
}
 
txn->last_pat->next_pa = 0;
+   /* ensure that the written descriptors are visible to DMM */
+   wmb();
+
+   /*
+* NOTE: the wmb() above should be enough, but there seems to be a bug
+* in OMAP's memory barrier implementation, which in some rare cases may
+* cause the writes not to be observable after wmb().
+*/
+
+   /* read back to ensure the data is in RAM */
+   readl(>last_pat->next_pa);
 
/* write to PAT_DESCR to clear out any pending transaction */
dmm_write(dmm, 0x0, reg[PAT_DESCR][engine->id]);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v2 0/3] Cleanup excessive DSI host controller version checks

[Archit Taneja]

On Tuesday 20 March 2018 01:11 AM, Sibi S wrote:

This patch series aims to create and bind dsi host controller helper
functions to functionalities that vary across DSI v2, DSI 6G 1.x and
DSI 6G v2.0+ controllers. These functionalities are currently under
excessive version checks which is now replaced with the corresponding
helper function.


Reviewed-by: Archit Taneja 



V2:
   Removes command broadcast support for DSI 6G v2.0+ controllers from
   the patch series and incorporates all the suggested corrections
   


Sibi S (3):
   drm/msm/dsi: add dsi host helper functions support
   drm/msm/dsi: add implementation for helper functions
   drm/msm/dsi: replace version checks with helper functions

  drivers/gpu/drm/msm/dsi/dsi.h  |  16 ++
  drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  56 +-
  drivers/gpu/drm/msm/dsi/dsi_cfg.h  |  12 ++
  drivers/gpu/drm/msm/dsi/dsi_host.c | 362 +
  4 files changed, 280 insertions(+), 166 deletions(-)


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

Re: [PATCH v4 0/8] cgroup private data and DRM/i915 integration

[Joonas Lahtinen]

Quoting Matt Roper (2018-03-17 02:08:57)
> This is the fourth iteration of the work previously posted here:
>   (v1) 
> https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
>   (v2) 
> https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html
>   (v3) https://lists.freedesktop.org/archives/intel-gfx/2018-March/157928.html
> 
> The high level goal of this work is to allow non-cgroup-controller parts
> of the kernel (e.g., device drivers) to register their own private
> policy data for specific cgroups.  That mechanism is then made use of in
> the i915 graphics driver to allow GPU priority to be assigned according
> to the cgroup membership of the owning process.  Please see the v1 cover
> letter linked above for a more in-depth explanation and justification.

Hi Matt,

For cross-subsystem changes such as this, it makes sense to Cc all
relevant maintainers, especially if there have been previous comments to
earlier revisions.

Please, do include and keep a reference to the userspace portion of the
changes when you suggest new uAPI to be added. At least I have some trouble
trying to track down the relevant interface consumer here.

I'm unsure how much sense it makes to commence with detailed i915 review
if we will be blocked by lack of userspace after that? I'm assuming
you've read through [1] already.

Regards, Joonas

[1] 
https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Signed-off-by missing for commits in the drm tree

[Tomi Valkeinen]

On 21/03/18 11:27, Stephen Rothwell wrote:
> Hi all,
> 
> A series of commits
> 
>   a82f034765fa ("drm: omapdrm: Split init and cleanup from probe and remove 
> functions")
> to
>   663ac57b285d ("drm: omapdrm: venc: Allocate the venc private data structure 
> dynamically")
> 
> are missing a Signed-off-by from their commiter.

Sorry about that again. I now have a script to check this, so I hope
this was the last time...

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Fix uabi regression by allowing garbage mode->type from userspace

[Ville Syrjälä]

On Thu, Mar 22, 2018 at 08:42:11AM +0100, Thomas Hellstrom wrote:
> On 03/21/2018 10:12 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > Apparently xf86-video-vmware leaves the mode->type uninitialized
> > when feeding the mode to the kernel. Thus we have no choice but
> > to accept the garbage in. We'll just ignore any of the bits we
> > don't want. The mode type is just a hint anyway, and more
> > useful for the kernel->userspace direction.
> >
> > Reported-by: Thomas Hellstrom 
> > CC: Thomas Hellstrom 
> > Cc: Adam Jackson 
> > Cc: Alex Deucher 
> > Fixes: c6ed6dad5cfb ("drm/uapi: Validate the mode flags/type")
> > References: 
> > https://lists.freedesktop.org/archives/dri-devel/2018-March/170213.html
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/drm_modes.c | 8 +++-
> >   1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index f6b7c0e36a1a..e82b61e08f8c 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1611,7 +1611,13 @@ int drm_mode_convert_umode(struct drm_device *dev,
> > out->vscan = in->vscan;
> > out->vrefresh = in->vrefresh;
> > out->flags = in->flags;
> > -   out->type = in->type;
> > +   /*
> > +* Old xf86-video-vmware (possibly others too) used to
> > +* leave 'type' unititialized. Just ignore any bits we
> > +* don't like. It's a just hint after all, and more
> > +* useful for the kernel->userspace direction anyway.
> > +*/
> > +   out->type = in->type & DRM_MODE_TYPE_ALL;
> > strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> > out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> >   
> 
> Tested-by: Thomas Hellstrom 

Thanks for the testing and reviews. And sorry for the extra hassle.

Pushed to drm-misc-next-fixes.

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

[PATCH] drm/gma500: simplify a condition in psbfb_mmap()

[Dan Carpenter]

Since we enforce that "vma->vm_pgoff" has to be zero it means we don't
need an additional cap on the upper bound.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index cb0a2ae916e0..a6732bffb2e2 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -166,9 +166,7 @@ static int psbfb_mmap(struct fb_info *info, struct 
vm_area_struct *vma)
struct psb_fbdev *fbdev = info->par;
struct psb_framebuffer *psbfb = >pfb;
 
-   if (vma->vm_pgoff != 0)
-   return -EINVAL;
-   if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT))
+   if (vma->vm_pgoff)
return -EINVAL;
 
if (!psbfb->addr_space)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amd/pp: silence a static checker warning

[Dan Carpenter]

This has a static checker warning because "frev" and "crev" can be
uninitialized if "info" is NULL.  I just changed the order of the checks
so that we check "info" first.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
index 75a465f771f0..7b26607c646a 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
@@ -319,13 +319,13 @@ static int smu8_get_system_info_data(struct pp_hwmgr 
*hwmgr)
GetIndexIntoMasterTable(DATA, IntegratedSystemInfo),
, , );
 
-   if (crev != 9) {
-   pr_err("Unsupported IGP table: %d %d\n", frev, crev);
+   if (info == NULL) {
+   pr_err("Could not retrieve the Integrated System Info 
Table!\n");
return -EINVAL;
}
 
-   if (info == NULL) {
-   pr_err("Could not retrieve the Integrated System Info 
Table!\n");
+   if (crev != 9) {
+   pr_err("Unsupported IGP table: %d %d\n", frev, crev);
return -EINVAL;
}
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook

[Ville Syrjälä]

On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
> 
> 
> Den 22.03.2018 21.27, skrev Ville Syrjala:
> > From: Ville Syrjälä 
> >
> > mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
> > bowels of the .atomic_enable() hook. That prevents us from taking the
> > plane mutex in fb->dirty() unless we also plumb down the acquire
> > context.
> >
> > Instead it seems simpler to split the fb->dirty() into a tinydrm
> > specific lower level hook that can be called from
> > mipi_dbi_enable_flush() and from a generic higher level
> > tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
> > vfuncs table we'll just stick it into tinydrm_device directly
> > for now.
> 
> The long term goal is to try and get rid of tinydrm.ko by moving stuff
> elsewhere as it's kind of a middle layer. So I'd really like to avoid
> adding a callback like this.
> Hopefully we can work out a solution based on my suggestion in the
> 'drm: Eliminate plane->fb/crtc usage for atomic drivers' thread.

I don't want to start redesigning the entire architecture at
this point. That would also cause a bigger risk of regression and
then we'd potentially have to try and revert the entire plane->fb
thing, which would not be fun if any significant changes have
occurred in the meantime.

> 
> If we do need a hook, I prefer that we add it to
> drm_simple_display_pipe_funcs.

If you have plans to redesign tinydrm anyway it seems to me that
a temporary hook in tinydrm is may be a bit less intrusive than
inflicting it on the simple_kms_helper. But if you do prefer
drm_simple_display_pipe_funcs I can move it there of course.

> 
> Noralf.
> 
> > Cc: "Noralf Trønnes" 
> > Cc: David Lechner 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30 
> > ++
> >   drivers/gpu/drm/tinydrm/ili9225.c  | 23 ++--
> >   drivers/gpu/drm/tinydrm/mi0283qt.c |  2 +-
> >   drivers/gpu/drm/tinydrm/mipi-dbi.c | 30 
> > ++
> >   drivers/gpu/drm/tinydrm/repaper.c  | 28 
> > 
> >   drivers/gpu/drm/tinydrm/st7586.c   | 23 ++--
> >   drivers/gpu/drm/tinydrm/st7735r.c  |  2 +-
> >   include/drm/tinydrm/mipi-dbi.h |  4 +++-
> >   include/drm/tinydrm/tinydrm-helpers.h  |  5 +
> >   include/drm/tinydrm/tinydrm.h  |  4 
> >   10 files changed, 76 insertions(+), 75 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
> > b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > index d1c3ce9ab294..dcd390163a4a 100644
> > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > @@ -78,6 +78,36 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
> >   }
> >   EXPORT_SYMBOL(tinydrm_merge_clips);
> >   
> > +int tinydrm_fb_dirty(struct drm_framebuffer *fb,
> > +struct drm_file *file_priv,
> > +unsigned int flags, unsigned int color,
> > +struct drm_clip_rect *clips,
> > +unsigned int num_clips)
> > +{
> > +   struct tinydrm_device *tdev = fb->dev->dev_private;
> > +   struct drm_plane *plane = >pipe.plane;
> > +   int ret = 0;
> > +
> > +   drm_modeset_lock(>mutex, NULL);
> > +
> > +   /* fbdev can flush even when we're not interested */
> > +   if (plane->state->fb == fb) {
> > +   mutex_lock(>dirty_lock);
> > +   ret = tdev->fb_dirty(fb, file_priv, flags,
> > +color, clips, num_clips);
> > +   mutex_unlock(>dirty_lock);
> > +   }
> > +
> > +   drm_modeset_unlock(>mutex);
> > +
> > +   if (ret)
> > +   dev_err_once(fb->dev->dev,
> > +"Failed to update display %d\n", ret);
> > +
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL(tinydrm_fb_dirty);
> > +
> >   /**
> >* tinydrm_memcpy - Copy clip buffer
> >* @dst: Destination buffer
> > diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
> > b/drivers/gpu/drm/tinydrm/ili9225.c
> > index 089d22798c8b..0874e877b111 100644
> > --- a/drivers/gpu/drm/tinydrm/ili9225.c
> > +++ b/drivers/gpu/drm/tinydrm/ili9225.c
> > @@ -88,14 +88,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
> > bool full;
> > void *tr;
> >   
> > -   mutex_lock(>dirty_lock);
> > -
> > if (!mipi->enabled)
> > -   goto out_unlock;
> > -
> > -   /* fbdev can flush even when we're not interested */
> > -   if (tdev->pipe.plane.fb != fb)
> > -   goto out_unlock;
> > +   return 0;
> >   
> > full = tinydrm_merge_clips(, clips, num_clips, flags,
> >fb->width, fb->height);
> > @@ -108,7 +102,7 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
> > 

Re: [PATCH] drm: Fix uabi regression by allowing garbage mode->type from userspace

[Daniel Stone]

On 21 March 2018 at 21:12, Ville Syrjala  wrote:
> Apparently xf86-video-vmware leaves the mode->type uninitialized
> when feeding the mode to the kernel. Thus we have no choice but
> to accept the garbage in. We'll just ignore any of the bits we
> don't want. The mode type is just a hint anyway, and more
> useful for the kernel->userspace direction.

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

Re: [PATCH] drm: Fix uabi regression by allowing garbage mode->type from userspace

[Maarten Lankhorst]

Op 22-03-18 om 08:42 schreef Thomas Hellstrom:
> On 03/21/2018 10:12 PM, Ville Syrjala wrote:
>> From: Ville Syrjälä 
>>
>> Apparently xf86-video-vmware leaves the mode->type uninitialized
>> when feeding the mode to the kernel. Thus we have no choice but
>> to accept the garbage in. We'll just ignore any of the bits we
>> don't want. The mode type is just a hint anyway, and more
>> useful for the kernel->userspace direction.
>>
>> Reported-by: Thomas Hellstrom 
>> CC: Thomas Hellstrom 
>> Cc: Adam Jackson 
>> Cc: Alex Deucher 
>> Fixes: c6ed6dad5cfb ("drm/uapi: Validate the mode flags/type")
>> References: 
>> https://lists.freedesktop.org/archives/dri-devel/2018-March/170213.html
>> Signed-off-by: Ville Syrjälä 
>> ---
>>   drivers/gpu/drm/drm_modes.c | 8 +++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index f6b7c0e36a1a..e82b61e08f8c 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -1611,7 +1611,13 @@ int drm_mode_convert_umode(struct drm_device *dev,
>>   out->vscan = in->vscan;
>>   out->vrefresh = in->vrefresh;
>>   out->flags = in->flags;
>> -    out->type = in->type;
>> +    /*
>> + * Old xf86-video-vmware (possibly others too) used to
>> + * leave 'type' unititialized. Just ignore any bits we
>> + * don't like. It's a just hint after all, and more
>> + * useful for the kernel->userspace direction anyway.
>> + */
>> +    out->type = in->type & DRM_MODE_TYPE_ALL;
>>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>>   
>
> Tested-by: Thomas Hellstrom 
>
> Thanks,
>
> Thomas
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reviewed-by: Maarten Lankhorst 

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

Re: [PATCH 09/10] drm/sun4i: Add a dedicated ioctl call for allocating tiled buffers

[Maxime Ripard]

Hi,

On Wed, Mar 21, 2018 at 04:29:03PM +0100, Paul Kocialkowski wrote:
> This introduces a dedicated ioctl for allocating tiled buffers in the
> Allwinner MB32 format, that comes with a handful of specific
> constraints. In particular, the stride of the buffers is expected to be
> aligned to 32 bytes.

You should have more details here. What are those constraints, what is
the expected user? Can you use it only for the scanout, like the dumb
buffers, or also for the other devices in the system?

> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 96 
> +++
>  drivers/gpu/drm/sun4i/sun4i_drv.h |  2 +
>  include/uapi/drm/sun4i_drm.h  | 42 +
>  3 files changed, 140 insertions(+)
>  create mode 100644 include/uapi/drm/sun4i_drm.h
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index d374bb61c565..e9cb03d34b44 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -21,11 +21,18 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "sun4i_drv.h"
>  #include "sun4i_frontend.h"
>  #include "sun4i_framebuffer.h"
>  #include "sun4i_tcon.h"
> +#include "sun4i_format.h"
> +
> +static const struct drm_ioctl_desc sun4i_drv_ioctls[] = {
> + DRM_IOCTL_DEF_DRV(SUN4I_GEM_CREATE_TILED, drm_sun4i_gem_create_tiled,
> +   DRM_AUTH | DRM_RENDER_ALLOW),

Why do you need DRM_RENDER_ALLOW? as far as I know, this is only
useful for render-nodes.

> +};
>  
>  DEFINE_DRM_GEM_CMA_FOPS(sun4i_drv_fops);
>  
> @@ -34,6 +41,8 @@ static struct drm_driver sun4i_drv_driver = {
>  
>   /* Generic Operations */
>   .lastclose  = drm_fb_helper_lastclose,
> + .ioctls = sun4i_drv_ioctls,
> + .num_ioctls = ARRAY_SIZE(sun4i_drv_ioctls),
>   .fops   = _drv_fops,
>   .name   = "sun4i-drm",
>   .desc   = "Allwinner sun4i Display Engine",
> @@ -69,6 +78,93 @@ int drm_sun4i_gem_dumb_create(struct drm_file *file_priv,
>   return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
>  }
>  
> +int drm_sun4i_gem_create_tiled(struct drm_device *drm, void *data,
> +struct drm_file *file_priv)
> +{
> + struct drm_sun4i_gem_create_tiled *args = data;
> + struct drm_gem_cma_object *cma_obj;
> + struct drm_gem_object *gem_obj;
> + uint32_t luma_stride, chroma_stride;
> + uint32_t luma_height, chroma_height;
> + int ret;
> +
> + if (!sun4i_format_supports_tiling(args->format))
> + return -EINVAL;
> +
> + memset(args->pitches, 0, sizeof(args->pitches));
> + memset(args->offsets, 0, sizeof(args->offsets));
> +
> + /* Stride and height are aligned to 32 bytes for MB32 tiled format. */
> + luma_stride = ALIGN(args->width, 32);
> + luma_height = ALIGN(args->height, 32);
> +
> + if (sun4i_format_is_semiplanar(args->format)) {
> + chroma_stride = luma_stride;
> +
> + if (sun4i_format_is_yuv420(args->format))
> + chroma_height = ALIGN(DIV_ROUND_UP(args->height, 2), 
> 32);
> + else if (sun4i_format_is_yuv422(args->format))
> + chroma_height = luma_height;
> + else
> + return -EINVAL;
> +
> + args->pitches[0] = luma_stride;
> + args->pitches[1] = chroma_stride;
> +
> + args->offsets[0] = 0;
> + args->offsets[1] = luma_stride * luma_height;
> +
> + args->size = luma_stride * luma_height +
> +  chroma_stride * chroma_height;
> + } else if (sun4i_format_is_planar(args->format)) {
> + if (sun4i_format_is_yuv411(args->format)) {
> + chroma_stride = ALIGN(DIV_ROUND_UP(args->width, 4), 32);
> + chroma_height = luma_height;
> + } if (sun4i_format_is_yuv420(args->format)) {
> + chroma_stride = ALIGN(DIV_ROUND_UP(args->width, 2), 32);
> + chroma_height = ALIGN(DIV_ROUND_UP(args->height, 2), 
> 32);
> + } else if (sun4i_format_is_yuv422(args->format)) {
> + chroma_stride = ALIGN(DIV_ROUND_UP(args->width, 2), 32);
> + chroma_height = luma_height;
> + } else {
> + return -EINVAL;
> + }
> +
> + args->pitches[0] = luma_stride;
> + args->pitches[1] = chroma_stride;
> + args->pitches[2] = chroma_stride;
> +
> + args->offsets[0] = 0;
> + args->offsets[1] = luma_stride * luma_height;
> + args->offsets[2] = luma_stride * luma_height +
> +chroma_stride * chroma_height;
> +
> + args->size = luma_stride * luma_height +
> + 

Re: [PATCH 07/10] drm/sun4i: Add support for YUV formats through the frontend

[Maxime Ripard]

On Wed, Mar 21, 2018 at 04:29:01PM +0100, Paul Kocialkowski wrote:
> The frontend supports many YUV formats as input and also contains a
> color-space converter (CSC) block that can convert YUV input into
> RGB output. It also allows scaling between the input and output for
> every possible combination of supported formats.
> 
> This adds support for all the (untiled) YUV video formats supported by
> the frontend, with associated changes in the backend and layer
> management.
> 
> A specific dumb GEM create function translates a hardware constraint,
> that the stride must be an even number, when allocating dumb (linear)
> buffers.

This should be in a separate, potentially preliminary, patch.

> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/sun4i/sun4i_backend.c  |  10 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.c  |  11 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.h  |   4 +
>  drivers/gpu/drm/sun4i/sun4i_frontend.c | 234 
> -
>  drivers/gpu/drm/sun4i/sun4i_frontend.h |  48 ++-
>  drivers/gpu/drm/sun4i/sun4i_layer.c|  34 +++--
>  6 files changed, 293 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index e8af9f3cf20b..3de7f3a427c3 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -500,6 +500,11 @@ static int sun4i_backend_atomic_check(struct 
> sunxi_engine *engine,
>   layer_state->uses_frontend = true;
>   num_frontend_planes++;
>   } else {
> + if (sun4i_format_is_yuv(fb->format->format)) {
> + DRM_DEBUG_DRIVER("Plane FB format is YUV\n");
> + num_yuv_planes++;
> + }
> +
>   layer_state->uses_frontend = false;
>   }
>  
> @@ -510,11 +515,6 @@ static int sun4i_backend_atomic_check(struct 
> sunxi_engine *engine,
>   if (fb->format->has_alpha)
>   num_alpha_planes++;
>  
> - if (sun4i_format_is_yuv(fb->format->format)) {
> - DRM_DEBUG_DRIVER("Plane FB format is YUV\n");
> - num_yuv_planes++;
> - }
> -

Why is this needed?

>   DRM_DEBUG_DRIVER("Plane zpos is %d\n",
>plane_state->normalized_zpos);
>  
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 3957c2ff6870..d374bb61c565 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -42,7 +42,7 @@ static struct drm_driver sun4i_drv_driver = {
>   .minor  = 0,
>  
>   /* GEM Operations */
> - .dumb_create= drm_gem_cma_dumb_create,
> + .dumb_create= drm_sun4i_gem_dumb_create,
>   .gem_free_object_unlocked = drm_gem_cma_free_object,
>   .gem_vm_ops = _gem_cma_vm_ops,
>  
> @@ -60,6 +60,15 @@ static struct drm_driver sun4i_drv_driver = {
>   /* Frame Buffer Operations */
>  };
>  
> +int drm_sun4i_gem_dumb_create(struct drm_file *file_priv,
> +   struct drm_device *drm,
> +   struct drm_mode_create_dumb *args)
> +{
> + args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp, 8), 2);
> +
> + return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
> +}
> +
>  static void sun4i_remove_framebuffers(void)
>  {
>   struct apertures_struct *ap;
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h 
> b/drivers/gpu/drm/sun4i/sun4i_drv.h
> index 5750b8ce8b31..47969711a889 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
> @@ -23,4 +23,8 @@ struct sun4i_drv {
>   struct list_headtcon_list;
>  };
>  
> +int drm_sun4i_gem_dumb_create(struct drm_file *file_priv,
> +   struct drm_device *drm,
> +   struct drm_mode_create_dumb *args);
> +

I'm not sure this is needed, you just need to move the function before
the structure definition.

>  #endif /* _SUN4I_DRV_H_ */
> diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
> b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> index 2dc33383be22..d9e58e96119c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> @@ -16,6 +16,7 @@
>  #include 
>  
>  #include "sun4i_drv.h"
> +#include "sun4i_format.h"
>  #include "sun4i_frontend.h"
>  
>  static const u32 sun4i_frontend_vert_coef[32] = {
> @@ -89,26 +90,135 @@ void sun4i_frontend_update_buffer(struct sun4i_frontend 
> *frontend,
>  {
>   struct drm_plane_state *state = plane->state;
>   struct drm_framebuffer *fb = state->fb;
> + uint32_t format = fb->format->format;
> + uint32_t width, height;
> + uint32_t stride, offset;
> + bool swap;
>   dma_addr_t paddr;
>  

Re: [PATCH 06/10] drm/sun4i: Move and extend format-related helpers and tables

[Maxime Ripard]

On Wed, Mar 21, 2018 at 04:29:00PM +0100, Paul Kocialkowski wrote:
> This moves the various helpers and tables related to format detection
> and conversion to a dedicated file, while adding a bunch of new helpers
> (especially for YUV and tiling support) along the way.

The addition of new helpers should be in a separate patch.

> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/sun4i/Makefile|   1 +
>  drivers/gpu/drm/sun4i/sun4i_backend.c |  54 ++
>  drivers/gpu/drm/sun4i/sun4i_format.c  | 193 
> ++
>  drivers/gpu/drm/sun4i/sun4i_format.h  |  35 ++
>  4 files changed, 235 insertions(+), 48 deletions(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_format.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_format.h
> 
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 582607c0c488..c89c42ff803e 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -4,6 +4,7 @@ sun4i-frontend-y  += sun4i_frontend.o
>  
>  sun4i-drm-y  += sun4i_drv.o
>  sun4i-drm-y  += sun4i_framebuffer.o
> +sun4i-drm-y  += sun4i_format.o
>  
>  sun4i-drm-hdmi-y += sun4i_hdmi_ddc_clk.o
>  sun4i-drm-hdmi-y += sun4i_hdmi_enc.o
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index 1fad0714c70e..e8af9f3cf20b 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -29,6 +29,7 @@
>  #include "sun4i_drv.h"
>  #include "sun4i_frontend.h"
>  #include "sun4i_layer.h"
> +#include "sun4i_format.h"
>  #include "sunxi_engine.h"
>  
>  struct sun4i_backend_quirks {
> @@ -36,50 +37,6 @@ struct sun4i_backend_quirks {
>   bool needs_output_muxing;
>  };
>  
> -static const u32 sunxi_rgb2yuv_coef[12] = {
> - 0x0107, 0x0204, 0x0064, 0x0108,
> - 0x3f69, 0x3ed6, 0x01c1, 0x0808,
> - 0x01c1, 0x3e88, 0x3fb8, 0x0808
> -};
> -
> -static const u32 sunxi_bt601_yuv2rgb_coef[12] = {
> - 0x04a7, 0x1e6f, 0x1cbf, 0x0877,
> - 0x04a7, 0x, 0x0662, 0x3211,
> - 0x04a7, 0x0812, 0x, 0x2eb1,
> -};
> -
> -static inline bool sun4i_backend_format_is_planar_yuv(uint32_t format)
> -{
> - switch (format) {
> - case DRM_FORMAT_YUV411:
> - case DRM_FORMAT_YUV422:
> - case DRM_FORMAT_YUV444:
> - return true;
> - default:
> - return false;
> - }
> -}
> -
> -static inline bool sun4i_backend_format_is_packed_yuv422(uint32_t format)
> -{
> - switch (format) {
> - case DRM_FORMAT_YUYV:
> - case DRM_FORMAT_YVYU:
> - case DRM_FORMAT_UYVY:
> - case DRM_FORMAT_VYUY:
> - return true;
> -
> - default:
> - return false;
> - }
> -}
> -
> -static inline bool sun4i_backend_format_is_yuv(uint32_t format)
> -{
> - return sun4i_backend_format_is_planar_yuv(format) ||
> - sun4i_backend_format_is_packed_yuv422(format);
> -}
> -
>  static void sun4i_backend_apply_color_correction(struct sunxi_engine *engine)
>  {
>   int i;
> @@ -259,7 +216,7 @@ static int sun4i_backend_update_yuv_format(struct 
> sun4i_backend *backend,
>  SUN4I_BACKEND_ATTCTL_REG0_LAY_YUVEN,
>  SUN4I_BACKEND_ATTCTL_REG0_LAY_YUVEN);
>  
> - if (sun4i_backend_format_is_packed_yuv422(format))
> + if (sun4i_format_is_packed_yuv422(format))
>   val |= SUN4I_BACKEND_IYUVCTL_FBFMT_PACKED_YUV422;
>   else
>   DRM_DEBUG_DRIVER("Unknown YUV format\n");
> @@ -310,7 +267,7 @@ int sun4i_backend_update_layer_formats(struct 
> sun4i_backend *backend,
>   DRM_DEBUG_DRIVER("Switching display backend interlaced mode %s\n",
>interlaced ? "on" : "off");
>  
> - if (sun4i_backend_format_is_yuv(fb->format->format))
> + if (sun4i_format_is_yuv(fb->format->format))
>   return sun4i_backend_update_yuv_format(backend, layer, plane);
>  
>   ret = sun4i_backend_drm_format_to_layer(fb->format->format, );
> @@ -404,7 +361,7 @@ int sun4i_backend_update_layer_buffer(struct 
> sun4i_backend *backend,
>*/
>   paddr -= PHYS_OFFSET;
>  
> - if (sun4i_backend_format_is_yuv(fb->format->format))
> + if (sun4i_format_is_yuv(fb->format->format))
>   return sun4i_backend_update_yuv_buffer(backend, fb, paddr);
>  
>   /* Write the 32 lower bits of the address (in bits) */
> @@ -549,10 +506,11 @@ static int sun4i_backend_atomic_check(struct 
> sunxi_engine *engine,
>   DRM_DEBUG_DRIVER("Plane FB format is %s\n",
>drm_get_format_name(fb->format->format,
>_name));
> +
>   if (fb->format->has_alpha)
> 

Re: [PATCH 05/10] drm/sun4i: Explicitly list and check formats supported by the frontend

[Maxime Ripard]

On Wed, Mar 21, 2018 at 04:28:59PM +0100, Paul Kocialkowski wrote:
> In order to check whether the frontend supports a specific format, an
> explicit list and a related helper are introduced.
> 
> They are then used to determine whether the frontend can actually support
> the requested format when it was selected to be used.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/sun4i/sun4i_backend.c  |  5 
>  drivers/gpu/drm/sun4i/sun4i_frontend.c | 44 
> ++
>  drivers/gpu/drm/sun4i/sun4i_frontend.h |  1 +
>  3 files changed, 50 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index 7703ba989743..1fad0714c70e 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -532,6 +532,11 @@ static int sun4i_backend_atomic_check(struct 
> sunxi_engine *engine,
>   struct drm_format_name_buf format_name;
>  
>   if (sun4i_backend_plane_uses_frontend(plane_state)) {
> + if 
> (!sun4i_frontend_format_is_supported(fb->format->format)) {
> + DRM_DEBUG_DRIVER("Frontend plane check 
> failed\n");
> + return -EINVAL;
> + }
> +

So you're checking if the frontend doesn't support it and if the
backend doesn't support it. Who supports it then? :)

Like I was saying, this should be moved to the previous patch, within
sun4i_backend_plane_uses_frontend.

> +static const uint32_t sun4i_frontend_formats[] = {
> + /* RGB */
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_BGRX,
> + /* YUV444 */
> + DRM_FORMAT_YUV444,
> + DRM_FORMAT_YVU444,
> + /* YUV422 */
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_YVYU,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_VYUY,
> + DRM_FORMAT_NV16,
> + DRM_FORMAT_NV61,
> + DRM_FORMAT_YUV422,
> + DRM_FORMAT_YVU422,
> + /* YUV420 */
> + DRM_FORMAT_NV12,
> + DRM_FORMAT_NV21,
> + DRM_FORMAT_YUV420,
> + DRM_FORMAT_YVU420,
> + /* YUV411 */
> + DRM_FORMAT_YUV411,
> + DRM_FORMAT_YVU411,
> +};

I think this list should reflect what the driver currently supports,
not what the hardware supports.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/10] drm/sun4i: Explicitly list and check formats supported by the backend

[Maxime Ripard]

On Wed, Mar 21, 2018 at 04:28:58PM +0100, Paul Kocialkowski wrote:
> In order to check whether the backend supports a specific format, an
> explicit list and a related helper are introduced.
> 
> They are then used to determine whether the frontend should be used for
> a layer, when the format is not supported by the backend.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/sun4i/sun4i_backend.c | 48 
> ++-
>  drivers/gpu/drm/sun4i/sun4i_backend.h |  1 +
>  2 files changed, 48 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index 274a1db6fa8e..7703ba989743 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -172,6 +172,39 @@ static int sun4i_backend_drm_format_to_layer(u32 format, 
> u32 *mode)
>   return 0;
>  }
>  
> +static const uint32_t sun4i_backend_formats[] = {
> + /* RGB */
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_RGBA,
> + DRM_FORMAT_ARGB1555,
> + DRM_FORMAT_RGBA5551,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_BGRX,
> + DRM_FORMAT_ARGB,
> + /* YUV422 */
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_YVYU,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_VYUY,

Ordering them by alphabetical order would be better.

> +};
> +
> +bool sun4i_backend_format_is_supported(uint32_t fmt)
> +{
> + bool found = false;
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(sun4i_backend_formats); i++) {
> + if (sun4i_backend_formats[i] == fmt) {
> + found = true;
> + break;

return true?

> + }
> + }
> +
> + return found;
> +}
> +
>  int sun4i_backend_update_layer_coord(struct sun4i_backend *backend,
>int layer, struct drm_plane *plane)
>  {
> @@ -436,15 +469,28 @@ static bool sun4i_backend_plane_uses_frontend(struct 
> drm_plane_state *state)
>  {
>   struct sun4i_layer *layer = plane_to_sun4i_layer(state->plane);
>   struct sun4i_backend *backend = layer->backend;
> + struct drm_framebuffer *fb = state->fb;
>  
>   if (IS_ERR(backend->frontend))
>   return false;
>  
> + /*
> +  * Let's pretend that every format is either supported by the backend or
> +  * the frontend. This is not true in practice, as some tiling modes are
> +  * not supported by either. There is still room to check this later in
> +  * the atomic check process.

Then I guess there these tiling modes will not be exposed and we won't
ever get that far, wouldn't we?

> +  */
> + if (!sun4i_backend_format_is_supported(fb->format->format))
> + return true;

Even though there's a comment, this is not really natural. We are
checking whether the frontend supports the current plane_state, so it
just makes more sense to check whether the frontend supports the
format, rather than if the backend doesn't support them.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/10] drm/sun4i: Disable YUV channel when using the frontend and set interlace

[Maxime Ripard]

On Wed, Mar 21, 2018 at 04:28:56PM +0100, Paul Kocialkowski wrote:
> The YUV channel was only disabled in sun4i_backend_update_layer_formats,
> which is not called when the frontend is selected.
> 
> Thus, creating a layer with a YUV format handled by the backend and then
> switching to a format that requires the frontend would keep the YUV
> channel enabled for the layer.
> 
> This explicitly disables the YUV channel for the layer when using the
> frontend as well. It also sets the relevant interlace bit, which was
> missing in the frontend path as well.

This should be part of a separate patch. Usually, if you write "it
also does..." at the end of your commit log, it's a pretty good
indication that it should be another patch :)

> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/sun4i/sun4i_backend.c | 17 -
>  drivers/gpu/drm/sun4i/sun4i_backend.h |  3 ++-
>  drivers/gpu/drm/sun4i/sun4i_layer.c   |  2 +-
>  3 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index e07a33adc51d..b98dafda52f8 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -294,8 +294,10 @@ int sun4i_backend_update_layer_formats(struct 
> sun4i_backend *backend,
>  }
>  
>  int sun4i_backend_update_layer_frontend(struct sun4i_backend *backend,
> - int layer, uint32_t fmt)
> + int layer, struct drm_plane *plane,
> + uint32_t fmt)
>  {
> + bool interlaced = false;

There's no need to pass the full drm_plane pointer, you can just pass
a boolean to tell if it is interlaced or not.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/10] drm/sun4i: Disable frontend video channel before enabling a layer

[Maxime Ripard]

On Wed, Mar 21, 2018 at 04:28:55PM +0100, Paul Kocialkowski wrote:
> This adds a dedicated function for disabling the layer video channel
> from the frontend to the backend. It is called automatically on an
> atomic update, as to disable the frontend by default (it will be enabled
> later on in the atomic update if necessary).
> 
> It fixes an issue when enabling a layer that uses the frontend (e.g. for
> scaling) and then reusing the same layer without the frontend. Since the
> video channel to the frontend was never disabled, the backend was still
> trying to get data from there.
> 
> Signed-off-by: Paul Kocialkowski 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105617] [CI] [CNL only] igt@* - incomplete - Build timed out (after 18 minutes). Marking the build as aborted.

[bugzilla-daemon]

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

--- Comment #5 from Marta Löfstedt  ---
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_6/fi-cnl-y3/igt@kms_cursor_...@cursor-128x42-offscreen.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_6/fi-cnl-y3/igt@kms_f...@2x-flip-vs-rmfb-interruptible.html

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

[Bug 104064] (DC 4.15-rc2) WARNING: CPU: 4 PID: 75 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:601 dm_suspend+0x4e/0x60 [amdgpu]

[bugzilla-daemon]

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

--- Comment #47 from taij...@posteo.de ---
(In reply to Harry Wentland from comment #46)
> The backlight patch has been stuck in our submission queue for a while but
> it's in our internal repo. It should be part of the next set of DC patches,
> although I don't think it'll make the 4.17 kernel, unless we want to treat
> it as a bugfix (one could argue either way here).

Well, as an affected user, I'd of course argue that they are both clearly bug
fixes, because to me that's their effect. No idea how much weight that opinion
is going to carry with David Airlie, though...

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

Re: [PATCH v2 1/2] dt-bindings: arm: omap: dmm: Document new compatible for DRA7xx family

[Peter Ujfalusi]

On 2018-03-22 15:42, Peter Ujfalusi wrote:
> From: Tomi Valkeinen 
> 
> Define unique compatible string for the DMM in DRA7xx family.
> 
> The new compatible can be used to apply DRA7xx specific workarounds for
> ERRATAs, like i878 (MPU Lockup with concurrent DMM and EMIF accesses)
> 
> Signed-off-by: Tomi Valkeinen 

I have failed to add:
Signed-off-by: Peter Ujfalusi 

> ---
>  Documentation/devicetree/bindings/arm/omap/dmm.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt 
> b/Documentation/devicetree/bindings/arm/omap/dmm.txt
> index 8bd6d0a238a8..bbbe7cdba30c 100644
> --- a/Documentation/devicetree/bindings/arm/omap/dmm.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
> @@ -8,7 +8,8 @@ translation for initiators which need contiguous dma bus 
> addresses.
>  
>  Required properties:
>  - compatible:Should contain "ti,omap4-dmm" for OMAP4 family
> - Should contain "ti,omap5-dmm" for OMAP5 and DRA7x family
> + Should contain "ti,omap5-dmm" for OMAP5 family
> + Should contain "ti,dra7-dmm" for DRA7xx family
>  - reg:   Contains DMM register address range (base address and 
> length)
>  - interrupts:Should contain an interrupt-specifier for DMM_IRQ.
>  - ti,hwmods: Name of the hwmod associated to DMM, which is typically "dmm"
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

[Peter Ujfalusi]

On 2018-03-22 15:42, Peter Ujfalusi wrote:
> From: Tomi Valkeinen 
> 
> Errata i878 says that MPU should not be used to access RAM and DMM at
> the same time. As it's not possible to prevent MPU accessing RAM, we
> need to access DMM via a proxy.
> 
> This patch changes DMM driver to access DMM registers via sDMA. Instead
> of doing a normal readl/writel call to read/write a register, we use
> sDMA to copy 4 bytes from/to the DMM registers.
> 
> This patch provides only a partial workaround for i878, as not only DMM
> register reads/writes are affected, but also accesses to the DMM mapped
> buffers (framebuffers, usually).
> 
> Signed-off-by: Tomi Valkeinen 

I have failed to add:
Signed-off-by: Peter Ujfalusi 

> ---
>  drivers/gpu/drm/omapdrm/omap_dmm_priv.h  |   8 ++
>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 153 
> ++-
>  2 files changed, 159 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h 
> b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
> index c2785cc98dc9..9ce9d1d7039a 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
> @@ -155,10 +155,12 @@ struct refill_engine {
>  
>  struct dmm_platform_data {
>   u32 cpu_cache_flags;
> + bool errata_i878_wa;
>  };
>  
>  struct dmm {
>   struct device *dev;
> + dma_addr_t phys_base;
>   void __iomem *base;
>   int irq;
>  
> @@ -189,6 +191,12 @@ struct dmm {
>   struct list_head alloc_head;
>  
>   const struct dmm_platform_data *plat_data;
> +
> + bool dmm_workaround;
> + spinlock_t wa_lock;
> + u32 *wa_dma_data;
> + dma_addr_t wa_dma_handle;
> + struct dma_chan *wa_dma_chan;
>  };
>  
>  #endif
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index e84871e74615..27c67bc36203 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -79,14 +80,138 @@ static const u32 reg[][4] = {
>   DMM_PAT_DESCR__2, DMM_PAT_DESCR__3},
>  };
>  
> +static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, dma_addr_t dst)
> +{
> + struct dma_device *dma_dev = dmm->wa_dma_chan->device;
> + struct dma_async_tx_descriptor *tx;
> + enum dma_status status;
> + dma_cookie_t cookie;
> +
> + tx = dma_dev->device_prep_dma_memcpy(dmm->wa_dma_chan, dst, src, 4, 0);
> + if (!tx) {
> + dev_err(dmm->dev, "Failed to prepare DMA memcpy\n");
> + return -EIO;
> + }
> +
> + cookie = tx->tx_submit(tx);
> + if (dma_submit_error(cookie)) {
> + dev_err(dmm->dev, "Failed to do DMA tx_submit\n");
> + return -EIO;
> + }
> +
> + dma_async_issue_pending(dmm->wa_dma_chan);
> + status = dma_sync_wait(dmm->wa_dma_chan, cookie);
> + if (status != DMA_COMPLETE)
> + dev_err(dmm->dev, "i878 wa DMA copy failure\n");
> +
> + dmaengine_terminate_all(dmm->wa_dma_chan);
> + return 0;
> +}
> +
> +static u32 dmm_read_wa(struct dmm *dmm, u32 reg)
> +{
> + dma_addr_t src, dst;
> + int r;
> +
> + src = dmm->phys_base + reg;
> + dst = dmm->wa_dma_handle;
> +
> + r = dmm_dma_copy(dmm, src, dst);
> + if (r) {
> + dev_err(dmm->dev, "sDMA read transfer timeout\n");
> + return readl(dmm->base + reg);
> + }
> +
> + /*
> +  * As per i878 workaround, the DMA is used to access the DMM registers.
> +  * Make sure that the readl is not moved by the compiler or the CPU
> +  * earlier than the DMA finished writing the value to memory.
> +  */
> + rmb();
> + return readl(dmm->wa_dma_data);
> +}
> +
> +static void dmm_write_wa(struct dmm *dmm, u32 val, u32 reg)
> +{
> + dma_addr_t src, dst;
> + int r;
> +
> + writel(val, dmm->wa_dma_data);
> + /*
> +  * As per i878 workaround, the DMA is used to access the DMM registers.
> +  * Make sure that the writel is not moved by the compiler or the CPU, so
> +  * the data will be in place before we start the DMA to do the actual
> +  * register write.
> +  */
> + wmb();
> +
> + src = dmm->wa_dma_handle;
> + dst = dmm->phys_base + reg;
> +
> + r = dmm_dma_copy(dmm, src, dst);
> + if (r) {
> + dev_err(dmm->dev, "sDMA write transfer timeout\n");
> + writel(val, dmm->base + reg);
> + }
> +}
> +
>  static u32 dmm_read(struct dmm *dmm, u32 reg)
>  {
> - return readl(dmm->base + reg);
> + if (dmm->dmm_workaround) {
> + u32 v;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>wa_lock, flags);
> + v = dmm_read_wa(dmm, reg);
> + spin_unlock_irqrestore(>wa_lock, flags);
> +
> +

[Bug 104193] [radeonsi] The Witcher 3 freezes the system (POLARIS10)

[bugzilla-daemon]

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

Józef Kucia  changed:

   What|Removed |Added

Summary|[radeonsi] The Witcher 3|[radeonsi] The Witcher 3
   |freezes the system with no  |freezes the system
   |attachments calls & |(POLARIS10)
   |transform feedback Wine |
   |patch   |

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

Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node

[Tomi Valkeinen]

Hi Rob,

On 23/03/18 03:23, Rob Herring wrote:

>> Ok, I think the description was a bit unclear. So, the driver can do
>> this just fine, it can reserve hw planes dynamically when needed. The
>> problem is the userspace.
>>
>> When a DRM application starts, it sees a bunch of planes, and can see on
>> which crtcs each plane can be used. The expectation is, of course, that
>> these planes can be used normally. If the driver would dynamically
>> reserve an additional, currently unused plane, the userspace would be
>> totally baffled, as it fails to configure basic plane setups.
>>
>> For example, the userspace could see that there are two planes, usable
>> on LCD and HDMI crtcs. But mysteriously modesetting would sometimes fail
>> if the HDMI is 2k+ display. Setting up a plane on the HDMI would work,
>> except when the LCD already has a plane. Setting up two planes on the
>> LCD would work, but moving one or both planes to the HDMI would fail. Etc.
> 
> I suspect this is a common problem. Not because the h/w requires
> different allocation of planes, but because the memory bandwidth can't
> handle having a 2nd plane if the resolution is above a certain
> size/depth. So while the plane doesn't disappear, the effect is the
> same. How does DRM handle this?

I don't think DRM handles this. Each driver can probably filter out
videomodes which it knows can't be used even with single plane (we do
this on omapdrm), and also can give an error if the plane setup would
result in too high bandwidth use.

So yes, plane setups can always fail, "mysteriously" from userspace's
perspective. But I don't think it's exactly comparable to this one. The
difference is that in this case we can avoid all the userspace issues
with a simple static plane partitioning done at probe time, but I can't
see how the bandwidth issue could be solved in a similar way.

>> We could, of course, convey this information to the userspace at runtime
>> via the DRM properties, but then it would mean we'd need customized
>> applications.
>>
>> So, as far as I can see, keeping normal DRM behavior with 2k+ displays
>> on OMAP DSS requires a static virtual plane setup. The most simple setup
>> would be to just split the number of available planes by 2, but then in
>> many use cases that wastes one hw plane.
> 
> For HDMI, you can't know in advance what resolution will be. So I
> think you always need to reserve 2 planes. Now, if you want to reduce

We can decide not to support 2k+ resolutions for HDMI, which, with this
series, happens by not reserving dual-plane for the HDMI.

> the max resolution for some reason, I guess we could have properties
> for that. That would be more generic and work whether you need to
> change plane allocation or have a limit for other reasons.
> 
> For attached panels, you know the resolution up front and can allocate
> planes before the userspace interface is up.

But reserve how many of the planes? We have N planes and M displays. For
some of the displays we know they're 2k+, some are known to be -2k and
some are unknown. The driver can't independently make any sensible
static reservation of the planes for the displays, because it doesn't
know what the user wants to do.

So either we reserve the extra planes at runtime on demand, making it
difficult to manage for the userspace, or we rely on the user to give
the driver a static partitioning of the planes according to the user's
use case.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] drm/msm/A6xx: Add support for using system cache(llc)

[Sharat Masetty]

The last level system cache can be partitioned to 32
different slices of which GPU has two slices preallocated.
The "gpu" slice is used for caching GPU buffers and
the "gpuhtw" slice is used for caching the GPU SMMU
pagetables.  This patch talks to the core system cache
driver to acquire the slice handles, configure the SCID's
to those slices and activates and deactivates the slices
upon GPU power collapse and restore.

Some support from the IOMMU driver is also needed to
make use of the system cache. IOMMU_UPSTREAM_HINT is
a buffer protection flag which enables caching GPU data
buffers in the system cache with memory attributes such
as outer cacheable, read-allocate, write-allocate for buffers.
The GPU then has the ability to override a few cacheability
parameters which it does to override write-allocate to
write-no-allocate as the GPU hardware does not benefit much
from it.
Similarly DOMAIN_ATTR_USE_UPSTREAM_HINT is another domain level
attribute used by the IOMMU driver to set the right attributes
to cache the hardware pagetables into the system cache.

Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 162 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h |   9 ++
 drivers/gpu/drm/msm/msm_iommu.c   |  13 +++
 drivers/gpu/drm/msm/msm_mmu.h |   3 +
 4 files changed, 186 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index bd50674..e4554eb 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 
 #include "msm_gem.h"
 #include "msm_mmu.h"
@@ -913,6 +914,154 @@ static irqreturn_t a6xx_irq(struct msm_gpu *gpu)
~0
 };
 
+#define A6XX_LLC_NUM_GPU_SCIDS 5
+#define A6XX_GPU_LLC_SCID_NUM_BITS 5
+
+#define A6XX_GPU_LLC_SCID_MASK \
+   ((1 << (A6XX_LLC_NUM_GPU_SCIDS * A6XX_GPU_LLC_SCID_NUM_BITS)) - 1)
+
+#define A6XX_GPUHTW_LLC_SCID_SHIFT 25
+#define A6XX_GPUHTW_LLC_SCID_MASK \
+   (((1 << A6XX_GPU_LLC_SCID_NUM_BITS) - 1) << A6XX_GPUHTW_LLC_SCID_SHIFT)
+
+static inline void a6xx_gpu_cx_rmw(struct a6xx_llc *llc,
+   u32 reg, u32 mask, u32 or)
+{
+   msm_rmw(llc->mmio + (reg << 2), mask, or);
+}
+
+static void a6xx_llc_deactivate(struct msm_gpu *gpu)
+{
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+   struct a6xx_llc *llc = _gpu->llc;
+
+   llcc_slice_deactivate(llc->gpu_llc_slice);
+   llcc_slice_deactivate(llc->gpuhtw_llc_slice);
+}
+
+static void a6xx_llc_activate(struct msm_gpu *gpu)
+{
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+   struct a6xx_llc *llc = _gpu->llc;
+
+   if (!llc->mmio)
+   return;
+
+   if (llc->gpu_llc_slice)
+   if (!llcc_slice_activate(llc->gpu_llc_slice))
+   /* Program the sub-cache ID for all GPU blocks */
+   a6xx_gpu_cx_rmw(llc,
+   REG_A6XX_GPU_CX_MISC_SYSTEM_CACHE_CNTL_1,
+   A6XX_GPU_LLC_SCID_MASK,
+   (llc->cntl1_regval &
+   A6XX_GPU_LLC_SCID_MASK));
+
+   if (llc->gpuhtw_llc_slice)
+   if (!llcc_slice_activate(llc->gpuhtw_llc_slice))
+   /* Program the sub-cache ID for GPU pagetables */
+   a6xx_gpu_cx_rmw(llc,
+   REG_A6XX_GPU_CX_MISC_SYSTEM_CACHE_CNTL_1,
+   A6XX_GPUHTW_LLC_SCID_MASK,
+   (llc->cntl1_regval &
+   A6XX_GPUHTW_LLC_SCID_MASK));
+
+   /* Program cacheability overrides */
+   a6xx_gpu_cx_rmw(llc, REG_A6XX_GPU_CX_MISC_SYSTEM_CACHE_CNTL_0, 0xF,
+   llc->cntl0_regval);
+}
+
+void a6xx_llc_slices_destroy(struct a6xx_llc *llc)
+{
+   if (llc->mmio) {
+   iounmap(llc->mmio);
+   llc->mmio = NULL;
+   }
+
+   llcc_slice_putd(llc->gpu_llc_slice);
+   llc->gpu_llc_slice = NULL;
+
+   llcc_slice_putd(llc->gpuhtw_llc_slice);
+   llc->gpuhtw_llc_slice = NULL;
+}
+
+static int a6xx_llc_slices_init(struct platform_device *pdev,
+   struct a6xx_llc *llc)
+{
+   int i;
+
+   /* Get the system cache slice descriptor for GPU and GPUHTWs */
+   llc->gpu_llc_slice = llcc_slice_getd(>dev, "gpu");
+   if (IS_ERR(llc->gpu_llc_slice))
+   llc->gpu_llc_slice = NULL;
+
+   llc->gpuhtw_llc_slice = llcc_slice_getd(>dev, "gpuhtw");
+   if (IS_ERR(llc->gpuhtw_llc_slice))
+   llc->gpuhtw_llc_slice = NULL;
+
+   if (llc->gpu_llc_slice == NULL && llc->gpuhtw_llc_slice == NULL)
+   return -1;
+
+   /* Map registers */
+   llc->mmio = 

[PATCH 3/5] drm/msm/adreno: Add registers in the GPU CX domain

[Sharat Masetty]

Add the registers needed for configuring the system cache slice info and
other parameters in the GPU.

Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/adreno/a6xx.xml.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h 
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
index 17d1241..29ce813 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -1596,5 +1596,9 @@ static inline uint32_t 
A6XX_CP_PROTECT_REG_MASK_LEN(uint32_t val)
 
 #define REG_A6XX_PDC_GPU_SEQ_MEM_0 0x000a
 
+#define REG_A6XX_GPU_CX_MISC_SYSTEM_CACHE_CNTL_0   0x0001
+
+#define REG_A6XX_GPU_CX_MISC_SYSTEM_CACHE_CNTL_1   0x0002
+
 
 #endif /* A6XX_XML */
-- 
1.9.1

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

[PATCH 0/5] Adreno A6xx system cache support

[Sharat Masetty]

Some hardware variants contain a system level cache or the last level
cache(llc). This cache is typically a large block which is shared by multiple
clients on the SOC. GPU uses the system cache to cache both the GPU data
buffers(like textures) as well the SMMU pagetables. This helps with
improved render performance as well as lower power consumption by reducing
the bus traffic to the system memory.

The system cache architecture allows the cache to be split into slices which
then be used by multiple SOC clients. This patch series is an effort to enable
and use two of those slices perallocated for the GPU, one for the GPU data
buffers and another for the GPU SMMU hardware pagetables.

This patchseries depends on the core llcc driver which was submitted to the
mailing list: https://patchwork.kernel.org/patch/10184935/ and SMMU support
for upstream hint which will be posted to the lists soon by Vivek.


Sharat Masetty (5):
  drm/msm: rearrange the gpu_rmw() function
  arm64:dts:sdm845: Add support for GPU LLCC
  drm/msm/adreno: Add registers in the GPU CX domain
  drm/msm: Pass mmu features to generic layers
  drm/msm/A6xx: Add support for using system cache(llc)

 arch/arm64/boot/dts/qcom/sdm845.dtsi|   8 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |   2 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |   2 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   |   2 +-
 drivers/gpu/drm/msm/adreno/a6xx.xml.h   |   4 +
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   | 162 +++-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h   |   9 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |   4 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |   2 +-
 drivers/gpu/drm/msm/msm_drv.c   |   8 ++
 drivers/gpu/drm/msm/msm_drv.h   |   1 +
 drivers/gpu/drm/msm/msm_gpu.c   |   6 +-
 drivers/gpu/drm/msm/msm_gpu.h   |   6 +-
 drivers/gpu/drm/msm/msm_iommu.c |  13 +++
 drivers/gpu/drm/msm/msm_mmu.h   |  16 
 15 files changed, 231 insertions(+), 14 deletions(-)

--
1.9.1

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

[PATCH 1/5] drm/msm: rearrange the gpu_rmw() function

[Sharat Masetty]

The register read-modify-write construct is generic enough
that it can be used by other subsystems as needed, create
a more generic rmw() function and have the gpu_rmw() use
this new function.

Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/msm_drv.c | 8 
 drivers/gpu/drm/msm/msm_drv.h | 1 +
 drivers/gpu/drm/msm/msm_gpu.h | 5 +
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index fbad854..a08b7d2 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -149,6 +149,14 @@ u32 msm_readl(const void __iomem *addr)
return val;
 }
 
+void msm_rmw(void __iomem *addr, u32 mask, u32 or)
+{
+   u32 val = msm_readl(addr);
+
+   val &= ~mask;
+   msm_writel(val | or, addr);
+}
+
 struct vblank_event {
struct list_head node;
int crtc_id;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 0a653dd..7e71354 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -314,6 +314,7 @@ void __iomem *msm_ioremap(struct platform_device *pdev, 
const char *name,
const char *dbgname);
 void msm_writel(u32 data, void __iomem *addr);
 u32 msm_readl(const void __iomem *addr);
+void msm_rmw(void __iomem *addr, u32 mask, u32 or);
 
 struct msm_gpu_submitqueue;
 int msm_submitqueue_init(struct drm_device *drm, struct msm_file_private *ctx);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index b9b86ef..96058d2 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -194,10 +194,7 @@ static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
 
 static inline void gpu_rmw(struct msm_gpu *gpu, u32 reg, u32 mask, u32 or)
 {
-   uint32_t val = gpu_read(gpu, reg);
-
-   val &= ~mask;
-   gpu_write(gpu, reg, val | or);
+   msm_rmw(gpu->mmio + (reg << 2), mask, or);
 }
 
 static inline u64 gpu_read64(struct msm_gpu *gpu, u32 lo, u32 hi)
-- 
1.9.1

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

[PATCH 2/5] arm64:dts:sdm845: Add support for GPU LLCC

[Sharat Masetty]

Add client side bindings required for the GPU to use the last level
system cache. Also add a register range in the GPU CX domain.

Signed-off-by: Sharat Masetty 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index eb0a1b2..7e2d938 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -887,8 +887,8 @@
compatible = "qcom,adreno-630.2", "qcom,adreno";
#stream-id-cells = <16>;
 
-   reg = <0x500 0x4>;
-   reg-names = "kgsl_3d0_reg_memory";
+   reg = <0x500 0x4>, <0x509e000 0x10>;
+   reg-names = "kgsl_3d0_reg_memory", "cx_mem";
 
/*
 * Look ma, no clocks! The GPU clocks and power are controlled
@@ -898,6 +898,10 @@
interrupts = <0 300 0>;
interrupt-names = "kgsl_3d0_irq";
 
+   /* GPU related llc slices */
+   cache-slice-names = "gpu", "gpuhtw";
+   cache-slices = < 12>, < 11>;
+
iommus = <_smmu 0>;
 
operating-points-v2 = <_opp_table>;
-- 
1.9.1

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

[PATCH 4/5] drm/msm: Pass mmu features to generic layers

[Sharat Masetty]

Allow different Adreno targets the ability to pass
specific mmu features to the generic layers. This will
help conditionally configure certain iommu features for
certain Adreno targets.

Also Add a few simple support functions to support a bitmask of
features that a specific MMU implementation supports.

Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  4 +++-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  2 +-
 drivers/gpu/drm/msm/msm_gpu.c   |  6 --
 drivers/gpu/drm/msm/msm_gpu.h   |  1 +
 drivers/gpu/drm/msm/msm_mmu.h   | 13 +
 9 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 1dd84d3..a7a8573 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -492,7 +492,7 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
adreno_gpu->registers = a3xx_registers;
adreno_gpu->reg_offsets = a3xx_register_offsets;
 
-   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
+   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1, 0);
if (ret)
goto fail;
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 2884b1b..5e7e15d6 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -574,7 +574,7 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
adreno_gpu->registers = a4xx_registers;
adreno_gpu->reg_offsets = a4xx_register_offsets;
 
-   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
+   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1, 0);
if (ret)
goto fail;
 
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index a4f68af..c9e06ff 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1295,7 +1295,7 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
 
check_speed_bin(>dev);
 
-   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4);
+   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4, 0);
if (ret) {
a5xx_destroy(&(a5xx_gpu->base.base));
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index e83b066..bd50674 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1040,7 +1040,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
adreno_gpu->registers = a6xx_registers;
adreno_gpu->reg_offsets = a6xx_register_offsets;
 
-   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4);
+   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4, 0);
if (ret) {
a6xx_destroy(&(a6xx_gpu->base.base));
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 6657461..a87ec6b 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -557,7 +557,8 @@ static int adreno_get_pwrlevels(struct device *dev,
 
 int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
struct adreno_gpu *adreno_gpu,
-   const struct adreno_gpu_funcs *funcs, int nr_rings)
+   const struct adreno_gpu_funcs *funcs, int nr_rings,
+   unsigned long mmu_features)
 {
struct adreno_platform_config *config = pdev->dev.platform_data;
struct msm_gpu_config adreno_gpu_config  = { 0 };
@@ -576,6 +577,7 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
adreno_gpu_config.va_end = 0x;
 
adreno_gpu_config.nr_rings = nr_rings;
+   adreno_gpu_config.mmu_features = mmu_features;
 
adreno_get_pwrlevels(>dev, gpu);
 
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index bb9affd..19eda65 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -225,7 +225,7 @@ void adreno_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
 
 int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
struct adreno_gpu *gpu, const struct adreno_gpu_funcs *funcs,
-   int nr_rings);
+   int nr_rings, unsigned long mmu_features);
 void adreno_gpu_cleanup(struct adreno_gpu *gpu);
 int adreno_load_fw(struct adreno_gpu *adreno_gpu);
 
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index ce8e781..c7f616c 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ 

Re: [PATCH v5 2/6] drm/exynos: Let core take care of normalizing the zpos

[Inki Dae]

2018년 03월 21일 19:20에 Peter Ujfalusi 이(가) 쓴 글:
> Instead of re-implementing the drm_atomic_helper_check() locally with just
> adding drm_atomic_normalize_zpos() into it, set the
> drm_mode_config->normalize_zpos.
> 
> Signed-off-by: Peter Ujfalusi 
> CC: Inki Dae 
> CC: Joonyoung Shim 
> CC: Seung-Woo Kim 
> CC: Kyungmin Park 
> Acked-by: Daniel Vetter 

Acked-by: Inki Dae 

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |  1 -
>  drivers/gpu/drm/exynos/exynos_drm_fb.c  |  4 +++-
>  3 files changed, 3 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index a518e9c6d6cc..39284bb7c2c2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -37,26 +37,6 @@
>  #define DRIVER_MAJOR 1
>  #define DRIVER_MINOR 0
>  
> -int exynos_atomic_check(struct drm_device *dev,
> - struct drm_atomic_state *state)
> -{
> - int ret;
> -
> - ret = drm_atomic_helper_check_modeset(dev, state);
> - if (ret)
> - return ret;
> -
> - ret = drm_atomic_normalize_zpos(dev, state);
> - if (ret)
> - return ret;
> -
> - ret = drm_atomic_helper_check_planes(dev, state);
> - if (ret)
> - return ret;
> -
> - return ret;
> -}
> -
>  static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
>  {
>   struct drm_exynos_file_private *file_priv;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index df2262f70d91..075957cb6ba1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -275,7 +275,6 @@ static inline int exynos_dpi_bind(struct drm_device *dev,
>  
>  int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state 
> *state,
>bool nonblock);
> -int exynos_atomic_check(struct drm_device *dev, struct drm_atomic_state 
> *state);
>  
>  
>  extern struct platform_driver fimd_driver;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 0faaf829f5bf..2379d732da67 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -206,7 +206,7 @@ static struct drm_mode_config_helper_funcs 
> exynos_drm_mode_config_helpers = {
>  static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
>   .fb_create = exynos_user_fb_create,
>   .output_poll_changed = drm_fb_helper_output_poll_changed,
> - .atomic_check = exynos_atomic_check,
> + .atomic_check = drm_atomic_helper_check,
>   .atomic_commit = drm_atomic_helper_commit,
>  };
>  
> @@ -227,4 +227,6 @@ void exynos_drm_mode_config_init(struct drm_device *dev)
>   dev->mode_config.helper_private = _drm_mode_config_helpers;
>  
>   dev->mode_config.allow_fb_modifiers = true;
> +
> + dev->mode_config.normalize_zpos = true;
>  }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105426] [regression] Mesa-18.0rc4 - black screen in some Valve games when run under Wine

[bugzilla-daemon]

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

--- Comment #9 from Tapani Pälli  ---
*** Bug 105568 has been marked as a duplicate of this bug. ***

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