date:20210324

On Sat, Mar 20, 2021 at 02:20:56AM +0200, Laurent Pinchart wrote:
> Hi Maxime,
> 
> Thank you for the patch.
> 
> On Fri, Mar 19, 2021 at 04:29:20PM +0100, Maxime Ripard wrote:
> > Commit 977697e20b3d ("drm/atomic: Pass the full state to planes atomic
> > disable and update") added the old_state variable instead of what used
> > to be a parameter, but it also removed the sole user of that variable in
> > the vop_plane_atomic_update function leading to an usused variable.
> > Remove it.
> > 
> > Fixes: 977697e20b3d ("drm/atomic: Pass the full state to planes atomic 
> > disable and update")
> > Reported-by: Stephen Rothwell 
> > Signed-off-by: Maxime Ripard 
> 
> Reviewed-by: Laurent Pinchart 

Applie,d thanks for your review

Maxime


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

Re: [RFC PATCH 04/11] drm/bridge: ti-sn65dsi86: Use bitmask to store valid rates

2021-03-24 Thread Geert Uytterhoeven

Hi Doug,

On Tue, Mar 23, 2021 at 10:10 PM Doug Anderson  wrote:
> On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart
>  wrote:
> >
> > The valid rates are stored in an array of 8 booleans. Replace it with a
> > bitmask to save space.
>
> I'm curious: do you have evidence that this does anything useful? I
> guess you're expecting it to save .text space, right? Stack usage and
> execution time differences should be irrelevant--it's not in a
> critical section and the difference should be tiny anyway. As far as
> .text segment goes, it's not obvious to me that the compiler will use
> fewer instructions to manipulate bits compared to booleans.
>
> Doing a super simple "ls -ah" on vmlinux (unstripped):
>
> Before: 224820232 bytes
> After: 224820376 bytes
>
> ...so your change made it _bigger_.   OK, so running "strip
> --strip-debug" on those:
>
> Before: 26599464 bytes
> After: 26599464 bytes

I've been surprised by the counter-intuitive impact of similar changes
before, too.  The result may also differ a lot between arm32 or arm64.

> ...so exactly the same. I tried finding some evidence using "readelf -ah":
>
> Before:
>   [ 2] .text PROGBITS ffc01001  0002
>00b03508   WAX   0 0 65536
>   [ 3] .rodata   PROGBITS ffc010b2  00b3
>002e84b3   WAMS   0 0 4096
>
> After:
>   [ 2] .text PROGBITS ffc01001  0002
>00b03508   WAX   0 0 65536
>   [ 3] .rodata   PROGBITS ffc010b2  00b3
>002e84b3   WAMS   0 0 4096
>
> Maybe you have some evidence showing an improvement? Ah, OK. I
> disassembled ti_sn_bridge_enable() and your patch saves 12 bytes, but
> I guess maybe alignment washes it out in reality...

Yes, arm64 is bad w.r.t. this.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/2] video: backlight: qcom-wled: Add PMI8994 compatible

2021-03-24 Thread Geert Uytterhoeven

Hi Lee,

On Tue, Mar 23, 2021 at 9:40 AM Lee Jones  wrote:
> On Mon, 22 Mar 2021, Daniel Thompson wrote:
> > On Sun, Feb 28, 2021 at 01:41:05PM +0100, Konrad Dybcio wrote:
> > > Add a compatible for PMI8994 WLED. It uses the V4 of WLED IP.
> > >
> > > Signed-off-by: Konrad Dybcio 
> >
> > Reviewed-by: Daniel Thompson 
>
> Why are you Reviewing/Acking a patch that was applied on the 10th?

Only 12 days later?!?

It's not uncommon to receive acks for patches after they have been
applied upstream. But it is if the patch was applied 10 years and 9
months ago!
https://lore.kernel.org/linux-m68k/f5513ae92a5a1047ac2f91aebb9202680288cbba3...@e2k7-ms2.ds.strath.ac.uk/

Gr{oetje,eeting}s,

Geert

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

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

[PATCH] drm/bridge: adv7511: fix support for large EDIDs

2021-03-24 Thread Hans Verkuil

While testing support for large (> 256 bytes) EDIDs on the Renesas
Koelsch board I noticed that the adv7511 bridge driver only read the
first two blocks.

The media V4L2 version for the adv7511 (drivers/media/i2c/adv7511-v4l2.c)
handled this correctly.

Besides a simple bug when setting the segment register (it was set to the
block number instead of block / 2), the logic of the code was also weird.
In particular reading the DDC_STATUS is odd: this is unrelated to EDID
reading.

The reworked code just waits for any EDID segment reads to finish (this
does nothing if the a segment is already read), checks if the desired
segment matches the read segment, and if not, then it requests the new
segment and waits again for the EDID segment to be read.

Finally it checks if the currently buffered EDID segment contains the
desired EDID block, and if not it will update the EDID buffer from
the adv7511.

Tested with my Koelsch board and with EDIDs of 1, 2, 3 and 4 blocks.

Signed-off-by: Hans Verkuil 
---
Testing on the Renesas board also requires these two adv7604 patches
if you want to test with an HDMI cable between the HDMI input and output:

https://patchwork.linuxtv.org/project/linux-media/patch/00882808-472a-d429-c565-a701da579...@xs4all.nl/
https://patchwork.linuxtv.org/project/linux-media/patch/c7093e76-ffb4-b19c-f576-b264f935a...@xs4all.nl/
---
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 76555ae64e9c..9e8db1c60167 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -328,6 +328,7 @@ static void adv7511_set_link_config(struct adv7511 *adv7511,
 static void __adv7511_power_on(struct adv7511 *adv7511)
 {
adv7511->current_edid_segment = -1;
+   adv7511->edid_read = false;

regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
   ADV7511_POWER_POWER_DOWN, 0);
@@ -529,29 +530,35 @@ static int adv7511_get_edid_block(void *data, u8 *buf, 
unsigned int block,
struct adv7511 *adv7511 = data;
struct i2c_msg xfer[2];
uint8_t offset;
+   unsigned int cur_segment;
unsigned int i;
int ret;

if (len > 128)
return -EINVAL;

-   if (adv7511->current_edid_segment != block / 2) {
-   unsigned int status;
+   /* wait for any EDID segment reads to finish */
+   adv7511_wait_for_edid(adv7511, 200);

-   ret = regmap_read(adv7511->regmap, ADV7511_REG_DDC_STATUS,
- &status);
+   ret = regmap_read(adv7511->regmap, ADV7511_REG_EDID_SEGMENT, 
&cur_segment);
+   if (ret < 0)
+   return ret;
+
+   /*
+* If the current read segment does not match what we need, then
+* write the new segment and wait for it to be read.
+*/
+   if (cur_segment != block / 2) {
+   adv7511->edid_read = false;
+   cur_segment = block / 2;
+   regmap_write(adv7511->regmap, ADV7511_REG_EDID_SEGMENT,
+cur_segment);
+   ret = adv7511_wait_for_edid(adv7511, 200);
if (ret < 0)
return ret;
+   }

-   if (status != 2) {
-   adv7511->edid_read = false;
-   regmap_write(adv7511->regmap, ADV7511_REG_EDID_SEGMENT,
-block);
-   ret = adv7511_wait_for_edid(adv7511, 200);
-   if (ret < 0)
-   return ret;
-   }
-
+   if (adv7511->current_edid_segment != cur_segment) {
/* Break this apart, hopefully more I2C controllers will
 * support 64 byte transfers than 256 byte transfers
 */
@@ -579,7 +586,7 @@ static int adv7511_get_edid_block(void *data, u8 *buf, 
unsigned int block,
offset += 64;
}

-   adv7511->current_edid_segment = block / 2;
+   adv7511->current_edid_segment = cur_segment;
}

if (block % 2 == 0)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] video: backlight: qcom-wled: Add PMI8994 compatible

2021-03-24 Thread Lee Jones

On Wed, 24 Mar 2021, Geert Uytterhoeven wrote:

> Hi Lee,
> 
> On Tue, Mar 23, 2021 at 9:40 AM Lee Jones  wrote:
> > On Mon, 22 Mar 2021, Daniel Thompson wrote:
> > > On Sun, Feb 28, 2021 at 01:41:05PM +0100, Konrad Dybcio wrote:
> > > > Add a compatible for PMI8994 WLED. It uses the V4 of WLED IP.
> > > >
> > > > Signed-off-by: Konrad Dybcio 
> > >
> > > Reviewed-by: Daniel Thompson 
> >
> > Why are you Reviewing/Acking a patch that was applied on the 10th?
> 
> Only 12 days later?!?
> 
> It's not uncommon to receive acks for patches after they have been
> applied upstream. But it is if the patch was applied 10 years and 9
> months ago!
> https://lore.kernel.org/linux-m68k/f5513ae92a5a1047ac2f91aebb9202680288cbba3...@e2k7-ms2.ds.strath.ac.uk/

That truly is next level! :)

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/4] drm: sun4i: dsi: Use drm_of_find_panel_or_bridge

2021-03-24 Thread Jagan Teki

On Wed, Mar 24, 2021 at 8:18 AM Samuel Holland  wrote:
>
> On 3/23/21 5:53 PM, Laurent Pinchart wrote:
> > Hi Jagan,
> >
> > Thank you for the patch.
> >
> > On Mon, Mar 22, 2021 at 07:31:49PM +0530, Jagan Teki wrote:
> >> Replace of_drm_find_panel with drm_of_find_panel_or_bridge
> >> for finding panel, this indeed help to find the bridge if
> >> bridge support added.
> >>
> >> Added NULL in bridge argument, same will replace with bridge
> >> parameter once bridge supported.
> >>
> >> Signed-off-by: Jagan Teki 
> >
> > Looks good, there should be no functional change.
>
> Actually this breaks all existing users of this driver, see below.
>
> > Reviewed-by: Laurent Pinchart 
> >
> >> ---
> >> Changes for v4, v3:
> >> - none
> >>
> >>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 11 ---
> >>  1 file changed, 8 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> >> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> >> index 4f5efcace68e..2e9e7b2d4145 100644
> >> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> >> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> >> @@ -21,6 +21,7 @@
> >>
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -963,10 +964,14 @@ static int sun6i_dsi_attach(struct mipi_dsi_host 
> >> *host,
> >>  struct mipi_dsi_device *device)
> >>  {
> >>  struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> >> -struct drm_panel *panel = of_drm_find_panel(device->dev.of_node);
>
> This is using the OF node of the DSI device, which is a direct child of
> the DSI host's OF node. There is no OF graph involved.
>
> >> +struct drm_panel *panel;
> >> +int ret;
> >> +
> >> +ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 0, 0,
> >> +  &panel, NULL);
>
> However, this function expects to find the panel using OF graph. This
> does not work with existing device trees (PinePhone, PineTab) which do
> not use OF graph to connect the panel. And it cannot work, because the
> DSI host's binding specifies a single port: the input port from the
> display engine.

Thanks for noticing this. I did understand your point and yes, I did
mention the updated pipeline in previous versions and forgot to add it
to this series.

Here is the updated pipeline to make it work:

https://patchwork.kernel.org/project/dri-devel/patch/20190524104252.20236-1-ja...@amarulasolutions.com/

Let me know your comments on this, so I will add a patch for the
above-affected DTS files.

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

[PATCH drm/amdgpu 2/2] drm/amd/pm: Convert sysfs sprintf/snprintf family to sysfs_emit

2021-03-24 Thread Tian Tao

Fix the following coccicheck warning:
drivers/gpu/drm/amd/pm/amdgpu_pm.c:1940:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:1978:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2022:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:294:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:154:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:496:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:512:9-17: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:1740:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:1667:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2074:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2047:9-17: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2768:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2738:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2442:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:3246:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:3253:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2458:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:3047:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:3133:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:3209:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:3216:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2410:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2496:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2470:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2426:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2965:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2972:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:3006:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:3013:8-16: WARNING:
use scnprintf or sprintf

Signed-off-by: Tian Tao 
---
 drivers/gpu/drm/amd/pm/amdgpu_pm.c | 88 +++---
 1 file changed, 44 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c 
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index 5fa65f1..0ee3e55 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
@@ -151,9 +151,9 @@ static ssize_t amdgpu_get_power_dpm_state(struct device 
*dev,
pm_runtime_mark_last_busy(ddev->dev);
pm_runtime_put_autosuspend(ddev->dev);
 
-   return snprintf(buf, PAGE_SIZE, "%s\n",
-   (pm == POWER_STATE_TYPE_BATTERY) ? "battery" :
-   (pm == POWER_STATE_TYPE_BALANCED) ? "balanced" : 
"performance");
+   return sysfs_emit(buf, "%s\n",
+ (pm == POWER_STATE_TYPE_BATTERY) ? "battery" :
+ (pm == POWER_STATE_TYPE_BALANCED) ? "balanced" : 
"performance");
 }
 
 static ssize_t amdgpu_set_power_dpm_state(struct device *dev,
@@ -291,16 +291,16 @@ static ssize_t 
amdgpu_get_power_dpm_force_performance_level(struct device *dev,
pm_runtime_mark_last_busy(ddev->dev);
pm_runtime_put_autosuspend(ddev->dev);
 
-   return snprintf(buf, PAGE_SIZE, "%s\n",
-   (level == AMD_DPM_FORCED_LEVEL_AUTO) ? "auto" :
-   (level == AMD_DPM_FORCED_LEVEL_LOW) ? "low" :
-   (level == AMD_DPM_FORCED_LEVEL_HIGH) ? "high" :
-   (level == AMD_DPM_FORCED_LEVEL_MANUAL) ? "manual" :
-   (level == AMD_DPM_FORCED_LEVEL_PROFILE_STANDARD) ? 
"profile_standard" :
-   (level == AMD_DPM_FORCED_LEVEL_PROFILE_MIN_SCLK) ? 
"profile_min_sclk" :
-   (level == AMD_DPM_FORCED_LEVEL_PROFILE_MIN_MCLK) ? 
"profile_min_mclk" :
-   (level == AMD_DPM_FORCED_LEVEL_PROFILE_PEAK) ? 
"profile_peak" :
-   "unknown");
+   return sysfs_emit(buf, "%s\n",
+ (level == AMD_DPM_FORCED_LEVEL_AUTO) ? "auto" :
+ (level == AMD_DPM_FORCED_LEVEL_LOW) ? "low" :
+ (level == AMD_DPM_FORCED_LEVEL_HIGH) ? "high" :
+ (level == AMD_DPM_FORCED_LEVEL_MANUAL) ? "manual" :
+ (level == AMD_DPM_FORCED_LEVEL_PROFILE_STANDARD) ? 
"profile_standard" :
+ (level == AMD_DPM_FORCED_LEVEL_PROFILE_MIN_SCLK) ? 
"profile_min_sclk" :
+ (level == AMD_DPM_FORCED_LEVEL_PROFILE_MIN_MCLK) ? 
"profile_min_mclk" :
+ (level == AMD_

[PATCH drm/amdgpu 0/2] Convert sysfs sprintf/snprintf family to sysfs_emit

2021-03-24 Thread Tian Tao

Use the generic sysfs_emit() function to take place of
snprintf/scnprintf, to avoid buffer overrun.

Tian Tao (2):
  drm/amdgpu: Convert sysfs sprintf/snprintf family to sysfs_emit
  drm/amd/pm: Convert sysfs sprintf/snprintf family to sysfs_emit

 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   |  8 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c  |  6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c  |  8 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 32 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/df_v3_6.c |  2 +-
 drivers/gpu/drm/amd/pm/amdgpu_pm.c   | 88 ++--
 9 files changed, 73 insertions(+), 79 deletions(-)

-- 
2.7.4

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

[PATCH drm/amdgpu 1/2] drm/amdgpu: Convert sysfs sprintf/snprintf family to sysfs_emit

2021-03-24 Thread Tian Tao

Fix the following coccicheck warning:
drivers/gpu//drm/amd/amdgpu/amdgpu_ras.c:434:9-17: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c:220:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c:249:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/df_v3_6.c:208:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_psp.c:2973:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_vram_mgr.c:75:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_vram_mgr.c:112:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_vram_mgr.c:58:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_vram_mgr.c:93:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_vram_mgr.c:125:9-17: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_gtt_mgr.c:52:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_gtt_mgr.c:71:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_device.c:140:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_device.c:164:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_device.c:186:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_device.c:208:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_atombios.c:1916:8-16: WARNING:
use scnprintf or sprintf

Signed-off-by: Tian Tao 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   |  8 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c  |  6 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c  |  8 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 32 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c |  4 ++--
 drivers/gpu/drm/amd/amdgpu/df_v3_6.c |  2 +-
 8 files changed, 29 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
index 86add0f..5b04bfcb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -1947,7 +1947,7 @@ static ssize_t amdgpu_atombios_get_vbios_version(struct 
device *dev,
struct amdgpu_device *adev = drm_to_adev(ddev);
struct atom_context *ctx = adev->mode_info.atom_context;
 
-   return snprintf(buf, PAGE_SIZE, "%s\n", ctx->vbios_version);
+   return sysfs_emit(buf, "%s\n", ctx->vbios_version);
 }
 
 static DEVICE_ATTR(vbios_version, 0444, amdgpu_atombios_get_vbios_version,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 6447cd6..33b6e46 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -136,7 +136,7 @@ static ssize_t amdgpu_device_get_pcie_replay_count(struct 
device *dev,
struct amdgpu_device *adev = drm_to_adev(ddev);
uint64_t cnt = amdgpu_asic_get_pcie_replay_count(adev);
 
-   return snprintf(buf, PAGE_SIZE, "%llu\n", cnt);
+   return sysfs_emit(buf, "%llu\n", cnt);
 }
 
 static DEVICE_ATTR(pcie_replay_count, S_IRUGO,
@@ -160,7 +160,7 @@ static ssize_t amdgpu_device_get_product_name(struct device 
*dev,
struct drm_device *ddev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(ddev);
 
-   return snprintf(buf, PAGE_SIZE, "%s\n", adev->product_name);
+   return sysfs_emit(buf, "%s\n", adev->product_name);
 }
 
 static DEVICE_ATTR(product_name, S_IRUGO,
@@ -182,7 +182,7 @@ static ssize_t amdgpu_device_get_product_number(struct 
device *dev,
struct drm_device *ddev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(ddev);
 
-   return snprintf(buf, PAGE_SIZE, "%s\n", adev->product_number);
+   return sysfs_emit(buf, "%s\n", adev->product_number);
 }
 
 static DEVICE_ATTR(product_number, S_IRUGO,
@@ -204,7 +204,7 @@ static ssize_t amdgpu_device_get_serial_number(struct 
device *dev,
struct drm_device *ddev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(ddev);
 
-   return snprintf(buf, PAGE_SIZE, "%s\n", adev->serial);
+   return sysfs_emit(buf, "%s\n", adev->serial);
 }
 
 static DEVICE_ATTR(serial_number, S_IRUGO,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 8980329..540c010 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -49,8 +49,7 @@ static ssize_t amdgpu_mem_info_gtt_total_show(struct device 
*dev,
struct amdgpu_device *adev = drm_to_adev(ddev);
struct ttm_resource_manager *man = ttm_manager_type(&adev->mman.bdev, 
TTM_PL_TT);
 
-   return snprintf(buf, PAGE_SIZE, "%llu\n",

RE: [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning

2021-03-24 Thread David Laight

From: Martin Sebor
> Sent: 22 March 2021 22:08
...
> In GCC 11, all access warnings expect objects to be either declared
> or allocated.  Pointers with constant values are taken to point to
> nothing valid (as Arnd mentioned above, this is to detect invalid
> accesses to members of structs at address zero).
> 
> One possible solution to the known address problem is to extend GCC
> attributes address and io that pin an object to a hardwired address
> to all targets (at the moment they're supported on just one or two
> targets).  I'm not sure this can still happen before GCC 11 releases
> sometime in April or May.

A different solution is to define a normal C external data item
and then assign a fixed address with an asm statement or in
the linker script.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v2)




On 23/03/2021 17:51, Jason Ekstrand wrote:

This API is entirely unnecessary and I'd love to get rid of it.  If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed.  The justification given at the time
was that it would help GL drivers which are inherently single-timeline.
However, neither of our GL drivers actually wanted the feature.  i965
was already in maintenance mode at the time and iris uses syncobj for
everything.

Unfortunately, as much as I'd love to get rid of it, it is used by the
media driver so we can't do that.  We can, however, do the next-best
thing which is to embed a syncobj in the context and do exactly what
we'd expect from userspace internally.  This isn't an entirely identical
implementation because it's no longer atomic if userspace races with
itself by calling execbuffer2 twice simultaneously from different
threads.  It won't crash in that case; it just doesn't guarantee any
ordering between those two submits.

Moving SINGLE_TIMELINE to a syncobj emulation has a couple of technical
advantages beyond mere annoyance.  One is that intel_timeline is no
longer an api-visible object and can remain entirely an implementation
detail.  This may be advantageous as we make scheduler changes going
forward.  Second is that, together with deleting the CLONE_CONTEXT API,
we should now have a 1:1 mapping between intel_context and
intel_timeline which may help us reduce locking.


Much, much better commit message although I still fail to understand 
where do you see implementation details leaking out. So for me this is 
still something I'd like to get to the bottom of.


I would also mention the difference regarding fence context change.

And in general I would maintain this patch as part of a series which 
ends up demonstrating the "mays" and "shoulds".




v2 (Jason Ekstrand):
  - Update the comment on i915_gem_context::syncobj to mention that it's
an emulation and the possible race if userspace calls execbuffer2
twice on the same context concurrently.
  - Wrap the checks for eb.gem_context->syncobj in unlikely()
  - Drop the dma_fence reference
  - Improved commit message

Signed-off-by: Jason Ekstrand 
Cc: Maarten Lankhorst 
Cc: Matthew Brost 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 47 ---
  .../gpu/drm/i915/gem/i915_gem_context_types.h | 14 +-
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 16 +++
  3 files changed, 39 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index f88bac19333ec..e094f4a1ca4cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -67,6 +67,8 @@
  #include 
  #include 
  
+#include 

+
  #include "gt/gen6_ppgtt.h"
  #include "gt/intel_context.h"
  #include "gt/intel_engine_heartbeat.h"
@@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context *ce,
ce->vm = vm;
}
  
-	GEM_BUG_ON(ce->timeline);

-   if (ctx->timeline)
-   ce->timeline = intel_timeline_get(ctx->timeline);
-
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
@@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
mutex_destroy(&ctx->engines_mutex);
mutex_destroy(&ctx->lut_mutex);
  
-	if (ctx->timeline)

-   intel_timeline_put(ctx->timeline);
+   if (ctx->syncobj)
+   drm_syncobj_put(ctx->syncobj);
  
  	put_pid(ctx->pid);

mutex_destroy(&ctx->mutex);
@@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
i915_vm_close(vm);
  }
  
-static void __set_timeline(struct intel_timeline **dst,

-  struct intel_timeline *src)
-{
-   struct intel_timeline *old = *dst;
-
-   *dst = src ? intel_timeline_get(src) : NULL;
-
-   if (old)
-   intel_timeline_put(old);
-}
-
-static void __apply_timeline(struct intel_context *ce, void *timeline)
-{
-   __set_timeline(&ce->timeline, timeline);
-}
-
-static void __assign_timeline(struct i915_gem_context *ctx,
- struct intel_timeline *timeline)
-{
-   __set_timeline(&ctx->timeline, timeline);
-   context_apply_all(ctx, __apply_timeline, timeline);
-}
-
  static struct i915_gem_context *
  i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
  {
struct i915_gem_context *ctx;
+   int ret;
  
  	if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&

!HAS_EXECLISTS(i915))
@@ -845,16 +821,13 @@ i915_gem_create_context(struct drm_i915_private *i915, 
unsigned int flags)
}
  
  	if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {

-   s

Re: [Intel-gfx] [PATCH v9 68/70] drm/i915: Pass ww ctx to pin_map

2021-03-24 Thread Maarten Lankhorst

Op 23-03-2021 om 18:30 schreef Matthew Auld:
> On Tue, 23 Mar 2021 at 15:51, Maarten Lankhorst
>  wrote:
>> This will allow us to explicitly pass the ww to pin_pages,
>> when it starts taking it.
>>
>> This allows us to finally kill off the explicit passing of ww
>> by retrieving it from the obj.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  7 ---
>>  drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  2 +-
>>  drivers/gpu/drm/i915/gem/i915_gem_object.h|  1 +
>>  .../gpu/drm/i915/gem/i915_gem_object_blt.c|  4 ++--
>>  drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 +++
>>  .../drm/i915/gem/selftests/i915_gem_context.c |  8 ---
>>  .../drm/i915/gem/selftests/i915_gem_dmabuf.c  |  2 +-
>>  drivers/gpu/drm/i915/gt/gen7_renderclear.c|  2 +-
>>  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  2 +-
>>  drivers/gpu/drm/i915/gt/intel_engine_pm.c |  2 +-
>>  drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 ++--
>>  drivers/gpu/drm/i915/gt/intel_renderstate.c   |  2 +-
>>  drivers/gpu/drm/i915/gt/intel_ring.c  |  2 +-
>>  .../gpu/drm/i915/gt/intel_ring_submission.c   |  2 +-
>>  drivers/gpu/drm/i915/gt/intel_timeline.c  |  7 ---
>>  drivers/gpu/drm/i915/gt/intel_timeline.h  |  3 ++-
>>  drivers/gpu/drm/i915/gt/intel_workarounds.c   |  2 +-
>>  drivers/gpu/drm/i915/gt/mock_engine.c |  2 +-
>>  drivers/gpu/drm/i915/gt/selftest_lrc.c|  2 +-
>>  drivers/gpu/drm/i915/gt/selftest_rps.c| 10 -
>>  .../gpu/drm/i915/gt/selftest_workarounds.c|  6 +++---
>>  drivers/gpu/drm/i915/gvt/cmd_parser.c |  4 ++--
>>  drivers/gpu/drm/i915/i915_perf.c  |  4 ++--
>>  drivers/gpu/drm/i915/selftests/igt_spinner.c  |  2 +-
>>  24 files changed, 60 insertions(+), 43 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
>> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> index dcfcae9c841b..73dd2a7673f5 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> @@ -1340,7 +1340,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer 
>> *eb,
>> if (err)
>> goto err_pool;
>>
>> -   cmd = i915_gem_object_pin_map(pool->obj, pool->type);
>> +   cmd = i915_gem_object_pin_map(pool->obj, &eb->ww, pool->type);
>> if (IS_ERR(cmd)) {
>> err = PTR_ERR(cmd);
>> goto err_pool;
>> @@ -2489,7 +2489,8 @@ static int eb_parse_pipeline(struct i915_execbuffer 
>> *eb,
>> goto err_shadow;
>> }
>>
>> -   pw->shadow_map = i915_gem_object_pin_map(shadow->obj, I915_MAP_WB);
>> +   pw->shadow_map = i915_gem_object_pin_map(shadow->obj, &eb->ww,
>> +I915_MAP_WB);
>> if (IS_ERR(pw->shadow_map)) {
>> err = PTR_ERR(pw->shadow_map);
>> goto err_trampoline;
>> @@ -2500,7 +2501,7 @@ static int eb_parse_pipeline(struct i915_execbuffer 
>> *eb,
>>
>> pw->batch_map = ERR_PTR(-ENODEV);
>> if (needs_clflush && i915_has_memcpy_from_wc())
>> -   pw->batch_map = i915_gem_object_pin_map(batch, I915_MAP_WC);
>> +   pw->batch_map = i915_gem_object_pin_map(batch, &eb->ww, 
>> I915_MAP_WC);
>>
>> if (IS_ERR(pw->batch_map)) {
>> err = i915_gem_object_pin_pages(batch);
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> index 2561a2f1e54f..edac8ee3be9a 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> @@ -439,7 +439,7 @@ vm_access(struct vm_area_struct *area, unsigned long 
>> addr,
>> goto out;
>>
>> /* As this is primarily for debugging, let's focus on simplicity */
>> -   vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
>> +   vaddr = i915_gem_object_pin_map(obj, &ww, I915_MAP_FORCE_WC);
>> if (IS_ERR(vaddr)) {
>> err = PTR_ERR(vaddr);
>> goto out;
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
>> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
>> index 1a8ec4035112..9bd9b47dcc8d 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
>> @@ -450,6 +450,7 @@ void i915_gem_object_writeback(struct 
>> drm_i915_gem_object *obj);
>>   * ERR_PTR() on error.
>>   */
>>  void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
>> +  struct i915_gem_ww_ctx *ww,
>>enum i915_map_type type);
>>
>>  void *__must_check i915_gem_object_pin_map_unlocked(struct 
>> drm_i915_gem_object *obj,
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c 
>> b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>> index df8e8c18c6c9..fa

Re: [PATCH v4 1/4] drm: sun4i: dsi: Use drm_of_find_panel_or_bridge

Hi Jagan,

On Wed, Mar 24, 2021 at 02:44:57PM +0530, Jagan Teki wrote:
> On Wed, Mar 24, 2021 at 8:18 AM Samuel Holland wrote:
> > On 3/23/21 5:53 PM, Laurent Pinchart wrote:
> > > On Mon, Mar 22, 2021 at 07:31:49PM +0530, Jagan Teki wrote:
> > >> Replace of_drm_find_panel with drm_of_find_panel_or_bridge
> > >> for finding panel, this indeed help to find the bridge if
> > >> bridge support added.
> > >>
> > >> Added NULL in bridge argument, same will replace with bridge
> > >> parameter once bridge supported.
> > >>
> > >> Signed-off-by: Jagan Teki 
> > >
> > > Looks good, there should be no functional change.
> >
> > Actually this breaks all existing users of this driver, see below.
> >
> > > Reviewed-by: Laurent Pinchart 
> > >
> > >> ---
> > >> Changes for v4, v3:
> > >> - none
> > >>
> > >>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 11 ---
> > >>  1 file changed, 8 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > >> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > >> index 4f5efcace68e..2e9e7b2d4145 100644
> > >> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > >> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > >> @@ -21,6 +21,7 @@
> > >>
> > >>  #include 
> > >>  #include 
> > >> +#include 
> > >>  #include 
> > >>  #include 
> > >>  #include 
> > >> @@ -963,10 +964,14 @@ static int sun6i_dsi_attach(struct mipi_dsi_host 
> > >> *host,
> > >>  struct mipi_dsi_device *device)
> > >>  {
> > >>  struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> > >> -struct drm_panel *panel = of_drm_find_panel(device->dev.of_node);
> >
> > This is using the OF node of the DSI device, which is a direct child of
> > the DSI host's OF node. There is no OF graph involved.
> >
> > >> +struct drm_panel *panel;
> > >> +int ret;
> > >> +
> > >> +ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 0, 0,
> > >> +  &panel, NULL);
> >
> > However, this function expects to find the panel using OF graph. This
> > does not work with existing device trees (PinePhone, PineTab) which do
> > not use OF graph to connect the panel. And it cannot work, because the
> > DSI host's binding specifies a single port: the input port from the
> > display engine.
> 
> Thanks for noticing this. I did understand your point and yes, I did
> mention the updated pipeline in previous versions and forgot to add it
> to this series.
> 
> Here is the updated pipeline to make it work:
> 
> https://patchwork.kernel.org/project/dri-devel/patch/20190524104252.20236-1-ja...@amarulasolutions.com/
> 
> Let me know your comments on this, so I will add a patch for the
> above-affected DTS files.

DT is an ABI, we need to ensure backward compatibility. Changes in
kernel drivers can't break devices that have an old DT.

-- 
Regards,

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

Re: [PATCH v2 1/3] drm: bridge/panel: Cleanup connector on bridge detach

On Wed, Mar 24, 2021 at 04:15:37AM +0200, Laurent Pinchart wrote:
> On Wed, Jan 20, 2021 at 06:38:03PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 20, 2021 at 6:12 PM Paul Cercueil wrote:
> > > Le mer. 20 janv. 2021 à 17:03, Daniel Vetter a écrit :
> > > > On Wed, Jan 20, 2021 at 1:35 PM Paul Cercueil wrote:
> > > >>
> > > >>  If we don't call drm_connector_cleanup() manually in
> > > >>  panel_bridge_detach(), the connector will be cleaned up with the other
> > > >>  DRM objects in the call to drm_mode_config_cleanup(). However, since 
> > > >> our
> > > >>  drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
> > > >>  will be called, our connector will be long gone. Therefore, the
> > > >>  connector must be cleaned up when the bridge is detached to avoid
> > > >>  use-after-free conditions.
> > > >
> > > > For -fixes this sounds ok, but for -next I think switching to drmm_
> > > > would be much better.
> > >
> > > The API would need to change to have access to the drm_device struct,
> > > though. That would be quite a big patch, there are a few dozens source
> > > files that use this API already.
> > 
> > Hm right pure drmm_ doesn't work for panel or bridge since it's
> > usually a separate driver. But devm_ also doesn't work. I think what
> > we need here is two-stage: first kmalloc the panel (or bridge, it's
> > really the same) in the panel/bridge driver load. Then when we bind it
> > to the drm_device we can tie it into the managed resources with
> > drmm_add_action_or_reset. Passing the drm_device to the point where we
> > allocate the panel/bridge doesn't work for these.
> > 
> > I think minimally we need a FIXME here and ack from Laurent on how
> > this should be solved at least, since panel bridge is used rather
> > widely.
> 
> Bridge removal is completely broken. If you unbind a bridge driver from
> the device, the bridge will be unregistered and resources freed, without
> the display driver knowing about this. The lifetime of the drm_bridge
> structure itself isn't the only issue to be addressed here, it's broader
> than that, and needs to consider that the display driver could be
> calling the bridge operations concurrently to the removal.

So for the "unloading bridge should first unload display" problem that was
supposed to get fixed with device links. There was at least a patch for
that, and I Rafel from pm side did all the core changes to make it work.
But it didn't land I think, so things keep on sucking.

Ofc the lifetime of the bridge structure is then an additional problem on
top here.

> We need a volunteer with enough motivation to solve this subsystem-wide
> :-) In the meantime, whatever shortcut addresses immediate issues is
> probably fine, as yak-shaving in this area would definitely not be
> reasonable.

I guess drm/bridge keeps on disappointing :-/
-Daniel

> 
> > > >> v2: Cleanup connector only if it was created
> > > >>
> > > >> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from 
> > > >> the lvds-encoder bridge.")
> > > >> Cc:  # 4.12+
> > > >> Cc: Andrzej Hajda 
> > > >> Cc: Neil Armstrong 
> > > >> Cc: Laurent Pinchart 
> > > >> Cc: Jonas Karlman 
> > > >> Cc: Jernej Skrabec 
> > > >> Signed-off-by: Paul Cercueil 
> > > >> ---
> > > >>  drivers/gpu/drm/bridge/panel.c | 6 ++
> > > >>  1 file changed, 6 insertions(+)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/bridge/panel.c 
> > > >> b/drivers/gpu/drm/bridge/panel.c
> > > >> index 0ddc37551194..df86b0ee0549 100644
> > > >> --- a/drivers/gpu/drm/bridge/panel.c
> > > >> +++ b/drivers/gpu/drm/bridge/panel.c
> > > >> @@ -87,6 +87,12 @@ static int panel_bridge_attach(struct drm_bridge 
> > > >> *bridge,
> > > >>
> > > >>  static void panel_bridge_detach(struct drm_bridge *bridge)
> > > >>  {
> > > >> +  struct panel_bridge *panel_bridge = 
> > > >> drm_bridge_to_panel_bridge(bridge);
> > > >> +  struct drm_connector *connector = &panel_bridge->connector;
> > > >> +
> > > >> +  /* Cleanup the connector if we know it was initialized */
> > > >> +  if (!!panel_bridge->connector.dev)
> > > >> +  drm_connector_cleanup(connector);
> > > >>  }
> > > >>
> > > >>  static void panel_bridge_pre_enable(struct drm_bridge *bridge)
> 
> -- 
> Regards,
> 
> Laurent Pinchart

-- 
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: [Intel-gfx] [PATCH] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v2)

On Tue, Mar 23, 2021 at 12:51:49PM -0500, Jason Ekstrand wrote:
> This API is entirely unnecessary and I'd love to get rid of it.  If
> userspace wants a single timeline across multiple contexts, they can
> either use implicit synchronization or a syncobj, both of which existed
> at the time this feature landed.  The justification given at the time
> was that it would help GL drivers which are inherently single-timeline.
> However, neither of our GL drivers actually wanted the feature.  i965
> was already in maintenance mode at the time and iris uses syncobj for
> everything.
> 
> Unfortunately, as much as I'd love to get rid of it, it is used by the
> media driver so we can't do that.  We can, however, do the next-best
> thing which is to embed a syncobj in the context and do exactly what
> we'd expect from userspace internally.  This isn't an entirely identical
> implementation because it's no longer atomic if userspace races with
> itself by calling execbuffer2 twice simultaneously from different
> threads.  It won't crash in that case; it just doesn't guarantee any
> ordering between those two submits.
> 
> Moving SINGLE_TIMELINE to a syncobj emulation has a couple of technical
> advantages beyond mere annoyance.  One is that intel_timeline is no
> longer an api-visible object and can remain entirely an implementation
> detail.  This may be advantageous as we make scheduler changes going
> forward.  Second is that, together with deleting the CLONE_CONTEXT API,
> we should now have a 1:1 mapping between intel_context and
> intel_timeline which may help us reduce locking.

Yeah I think this captures everything we need to say here.

Acked-by: Daniel Vetter 

No full r-b because I have a pile of other things to do too.
-Daniel

> 
> v2 (Jason Ekstrand):
>  - Update the comment on i915_gem_context::syncobj to mention that it's
>an emulation and the possible race if userspace calls execbuffer2
>twice on the same context concurrently.
>  - Wrap the checks for eb.gem_context->syncobj in unlikely()
>  - Drop the dma_fence reference
>  - Improved commit message
> 
> Signed-off-by: Jason Ekstrand 
> Cc: Maarten Lankhorst 
> Cc: Matthew Brost 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 47 ---
>  .../gpu/drm/i915/gem/i915_gem_context_types.h | 14 +-
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 16 +++
>  3 files changed, 39 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index f88bac19333ec..e094f4a1ca4cd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -67,6 +67,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #include "gt/gen6_ppgtt.h"
>  #include "gt/intel_context.h"
>  #include "gt/intel_engine_heartbeat.h"
> @@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context 
> *ce,
>   ce->vm = vm;
>   }
>  
> - GEM_BUG_ON(ce->timeline);
> - if (ctx->timeline)
> - ce->timeline = intel_timeline_get(ctx->timeline);
> -
>   if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
>   intel_engine_has_timeslices(ce->engine))
>   __set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
> @@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
>   mutex_destroy(&ctx->engines_mutex);
>   mutex_destroy(&ctx->lut_mutex);
>  
> - if (ctx->timeline)
> - intel_timeline_put(ctx->timeline);
> + if (ctx->syncobj)
> + drm_syncobj_put(ctx->syncobj);
>  
>   put_pid(ctx->pid);
>   mutex_destroy(&ctx->mutex);
> @@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
>   i915_vm_close(vm);
>  }
>  
> -static void __set_timeline(struct intel_timeline **dst,
> -struct intel_timeline *src)
> -{
> - struct intel_timeline *old = *dst;
> -
> - *dst = src ? intel_timeline_get(src) : NULL;
> -
> - if (old)
> - intel_timeline_put(old);
> -}
> -
> -static void __apply_timeline(struct intel_context *ce, void *timeline)
> -{
> - __set_timeline(&ce->timeline, timeline);
> -}
> -
> -static void __assign_timeline(struct i915_gem_context *ctx,
> -   struct intel_timeline *timeline)
> -{
> - __set_timeline(&ctx->timeline, timeline);
> - context_apply_all(ctx, __apply_timeline, timeline);
> -}
> -
>  static struct i915_gem_context *
>  i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
>  {
>   struct i915_gem_context *ctx;
> + int ret;
>  
>   if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
>   !HAS_EXECLISTS(i915))
> @@ -845,16 +821,13 @@ i915_gem_create_context(struct drm_i915_private *i915, 
> unsigned int flags)
>   }
>  
>   if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
> - struct intel_timeline *timeline;
> -
> -

Re: [PATCH v2 1/3] drm: bridge/panel: Cleanup connector on bridge detach

On Wed, Mar 24, 2021 at 10:39:52AM +0100, Daniel Vetter wrote:
> On Wed, Mar 24, 2021 at 04:15:37AM +0200, Laurent Pinchart wrote:
> > On Wed, Jan 20, 2021 at 06:38:03PM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 20, 2021 at 6:12 PM Paul Cercueil wrote:
> > > > Le mer. 20 janv. 2021 à 17:03, Daniel Vetter a écrit :
> > > > > On Wed, Jan 20, 2021 at 1:35 PM Paul Cercueil wrote:
> > > > >>
> > > > >>  If we don't call drm_connector_cleanup() manually in
> > > > >>  panel_bridge_detach(), the connector will be cleaned up with the 
> > > > >> other
> > > > >>  DRM objects in the call to drm_mode_config_cleanup(). However, 
> > > > >> since our
> > > > >>  drm_connector is devm-allocated, by the time 
> > > > >> drm_mode_config_cleanup()
> > > > >>  will be called, our connector will be long gone. Therefore, the
> > > > >>  connector must be cleaned up when the bridge is detached to avoid
> > > > >>  use-after-free conditions.
> > > > >
> > > > > For -fixes this sounds ok, but for -next I think switching to drmm_
> > > > > would be much better.
> > > >
> > > > The API would need to change to have access to the drm_device struct,
> > > > though. That would be quite a big patch, there are a few dozens source
> > > > files that use this API already.
> > > 
> > > Hm right pure drmm_ doesn't work for panel or bridge since it's
> > > usually a separate driver. But devm_ also doesn't work. I think what
> > > we need here is two-stage: first kmalloc the panel (or bridge, it's
> > > really the same) in the panel/bridge driver load. Then when we bind it
> > > to the drm_device we can tie it into the managed resources with
> > > drmm_add_action_or_reset. Passing the drm_device to the point where we
> > > allocate the panel/bridge doesn't work for these.
> > > 
> > > I think minimally we need a FIXME here and ack from Laurent on how
> > > this should be solved at least, since panel bridge is used rather
> > > widely.
> > 
> > Bridge removal is completely broken. If you unbind a bridge driver from
> > the device, the bridge will be unregistered and resources freed, without
> > the display driver knowing about this. The lifetime of the drm_bridge
> > structure itself isn't the only issue to be addressed here, it's broader
> > than that, and needs to consider that the display driver could be
> > calling the bridge operations concurrently to the removal.
> 
> So for the "unloading bridge should first unload display" problem that was
> supposed to get fixed with device links. There was at least a patch for
> that, and I Rafel from pm side did all the core changes to make it work.
> But it didn't land I think, so things keep on sucking.
> 
> Ofc the lifetime of the bridge structure is then an additional problem on
> top here.

There's a set of interesting problems. I don't think it's impossible,
but it will require someone with a good understanding of the problem (as
that person would really need to see the big picture, and take all use
cases into account), and a large amount of time and motivation.

> > We need a volunteer with enough motivation to solve this subsystem-wide
> > :-) In the meantime, whatever shortcut addresses immediate issues is
> > probably fine, as yak-shaving in this area would definitely not be
> > reasonable.
> 
> I guess drm/bridge keeps on disappointing :-/

I usually blame the x86 folks for not caring enough about bridges
initially, resulting in it being a second class citizen ;-)

> > > > >> v2: Cleanup connector only if it was created
> > > > >>
> > > > >> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper 
> > > > >> from the lvds-encoder bridge.")
> > > > >> Cc:  # 4.12+
> > > > >> Cc: Andrzej Hajda 
> > > > >> Cc: Neil Armstrong 
> > > > >> Cc: Laurent Pinchart 
> > > > >> Cc: Jonas Karlman 
> > > > >> Cc: Jernej Skrabec 
> > > > >> Signed-off-by: Paul Cercueil 
> > > > >> ---
> > > > >>  drivers/gpu/drm/bridge/panel.c | 6 ++
> > > > >>  1 file changed, 6 insertions(+)
> > > > >>
> > > > >> diff --git a/drivers/gpu/drm/bridge/panel.c 
> > > > >> b/drivers/gpu/drm/bridge/panel.c
> > > > >> index 0ddc37551194..df86b0ee0549 100644
> > > > >> --- a/drivers/gpu/drm/bridge/panel.c
> > > > >> +++ b/drivers/gpu/drm/bridge/panel.c
> > > > >> @@ -87,6 +87,12 @@ static int panel_bridge_attach(struct drm_bridge 
> > > > >> *bridge,
> > > > >>
> > > > >>  static void panel_bridge_detach(struct drm_bridge *bridge)
> > > > >>  {
> > > > >> +struct panel_bridge *panel_bridge = 
> > > > >> drm_bridge_to_panel_bridge(bridge);
> > > > >> +struct drm_connector *connector = &panel_bridge->connector;
> > > > >> +
> > > > >> +/* Cleanup the connector if we know it was initialized */
> > > > >> +if (!!panel_bridge->connector.dev)
> > > > >> +drm_connector_cleanup(connector);
> > > > >>  }
> > > > >>
> > > > >>  static void panel_bridge_pre_enable(struct drm_bridge *bridge)

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list

Re: [PATCH v4 1/4] drm: sun4i: dsi: Use drm_of_find_panel_or_bridge

2021-03-24 Thread Jagan Teki

Hi Laurent,

On Wed, Mar 24, 2021 at 3:09 PM Laurent Pinchart
 wrote:
>
> Hi Jagan,
>
> On Wed, Mar 24, 2021 at 02:44:57PM +0530, Jagan Teki wrote:
> > On Wed, Mar 24, 2021 at 8:18 AM Samuel Holland wrote:
> > > On 3/23/21 5:53 PM, Laurent Pinchart wrote:
> > > > On Mon, Mar 22, 2021 at 07:31:49PM +0530, Jagan Teki wrote:
> > > >> Replace of_drm_find_panel with drm_of_find_panel_or_bridge
> > > >> for finding panel, this indeed help to find the bridge if
> > > >> bridge support added.
> > > >>
> > > >> Added NULL in bridge argument, same will replace with bridge
> > > >> parameter once bridge supported.
> > > >>
> > > >> Signed-off-by: Jagan Teki 
> > > >
> > > > Looks good, there should be no functional change.
> > >
> > > Actually this breaks all existing users of this driver, see below.
> > >
> > > > Reviewed-by: Laurent Pinchart 
> > > >
> > > >> ---
> > > >> Changes for v4, v3:
> > > >> - none
> > > >>
> > > >>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 11 ---
> > > >>  1 file changed, 8 insertions(+), 3 deletions(-)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > > >> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > >> index 4f5efcace68e..2e9e7b2d4145 100644
> > > >> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > >> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > >> @@ -21,6 +21,7 @@
> > > >>
> > > >>  #include 
> > > >>  #include 
> > > >> +#include 
> > > >>  #include 
> > > >>  #include 
> > > >>  #include 
> > > >> @@ -963,10 +964,14 @@ static int sun6i_dsi_attach(struct mipi_dsi_host 
> > > >> *host,
> > > >>  struct mipi_dsi_device *device)
> > > >>  {
> > > >>  struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> > > >> -struct drm_panel *panel = of_drm_find_panel(device->dev.of_node);
> > >
> > > This is using the OF node of the DSI device, which is a direct child of
> > > the DSI host's OF node. There is no OF graph involved.
> > >
> > > >> +struct drm_panel *panel;
> > > >> +int ret;
> > > >> +
> > > >> +ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 0, 0,
> > > >> +  &panel, NULL);
> > >
> > > However, this function expects to find the panel using OF graph. This
> > > does not work with existing device trees (PinePhone, PineTab) which do
> > > not use OF graph to connect the panel. And it cannot work, because the
> > > DSI host's binding specifies a single port: the input port from the
> > > display engine.
> >
> > Thanks for noticing this. I did understand your point and yes, I did
> > mention the updated pipeline in previous versions and forgot to add it
> > to this series.
> >
> > Here is the updated pipeline to make it work:
> >
> > https://patchwork.kernel.org/project/dri-devel/patch/20190524104252.20236-1-ja...@amarulasolutions.com/
> >
> > Let me know your comments on this, so I will add a patch for the
> > above-affected DTS files.
>
> DT is an ABI, we need to ensure backward compatibility. Changes in
> kernel drivers can't break devices that have an old DT.

Thanks for your point.

So, we need to choose APIs that would compatible with the old DT and
new DT changes. Am I correct?

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

Re: [Intel-gfx] [PATCH] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v2)

On Wed, Mar 24, 2021 at 09:28:58AM +, Tvrtko Ursulin wrote:
> 
> On 23/03/2021 17:51, Jason Ekstrand wrote:
> > This API is entirely unnecessary and I'd love to get rid of it.  If
> > userspace wants a single timeline across multiple contexts, they can
> > either use implicit synchronization or a syncobj, both of which existed
> > at the time this feature landed.  The justification given at the time
> > was that it would help GL drivers which are inherently single-timeline.
> > However, neither of our GL drivers actually wanted the feature.  i965
> > was already in maintenance mode at the time and iris uses syncobj for
> > everything.
> > 
> > Unfortunately, as much as I'd love to get rid of it, it is used by the
> > media driver so we can't do that.  We can, however, do the next-best
> > thing which is to embed a syncobj in the context and do exactly what
> > we'd expect from userspace internally.  This isn't an entirely identical
> > implementation because it's no longer atomic if userspace races with
> > itself by calling execbuffer2 twice simultaneously from different
> > threads.  It won't crash in that case; it just doesn't guarantee any
> > ordering between those two submits.
> > 
> > Moving SINGLE_TIMELINE to a syncobj emulation has a couple of technical
> > advantages beyond mere annoyance.  One is that intel_timeline is no
> > longer an api-visible object and can remain entirely an implementation
> > detail.  This may be advantageous as we make scheduler changes going
> > forward.  Second is that, together with deleting the CLONE_CONTEXT API,
> > we should now have a 1:1 mapping between intel_context and
> > intel_timeline which may help us reduce locking.
> 
> Much, much better commit message although I still fail to understand where
> do you see implementation details leaking out. So for me this is still
> something I'd like to get to the bottom of.
> 
> I would also mention the difference regarding fence context change.
> 
> And in general I would maintain this patch as part of a series which ends up
> demonstrating the "mays" and "shoulds".

I disagree. The past few years we've merged way too much patches and
features without carefully answering the high level questions of
- do we really need to solve this problem
- and if so, are we really solving this problem in the right place

Now we're quite in a hole, and we're not going to get out of this hole if
we keep applying the same standards that got us here. Anything that does
not clearly and without reservation the above two questions with "yes"
needs to be removed or walled off, just so we can eventually see which
complexity we really need, and what is actually superflous.

Especially when the kernel patch is this simple.
-Daniel

> 
> > 
> > v2 (Jason Ekstrand):
> >   - Update the comment on i915_gem_context::syncobj to mention that it's
> > an emulation and the possible race if userspace calls execbuffer2
> > twice on the same context concurrently.
> >   - Wrap the checks for eb.gem_context->syncobj in unlikely()
> >   - Drop the dma_fence reference
> >   - Improved commit message
> > 
> > Signed-off-by: Jason Ekstrand 
> > Cc: Maarten Lankhorst 
> > Cc: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_context.c   | 47 ---
> >   .../gpu/drm/i915/gem/i915_gem_context_types.h | 14 +-
> >   .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 16 +++
> >   3 files changed, 39 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index f88bac19333ec..e094f4a1ca4cd 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -67,6 +67,8 @@
> >   #include 
> >   #include 
> > +#include 
> > +
> >   #include "gt/gen6_ppgtt.h"
> >   #include "gt/intel_context.h"
> >   #include "gt/intel_engine_heartbeat.h"
> > @@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context 
> > *ce,
> > ce->vm = vm;
> > }
> > -   GEM_BUG_ON(ce->timeline);
> > -   if (ctx->timeline)
> > -   ce->timeline = intel_timeline_get(ctx->timeline);
> > -
> > if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> > intel_engine_has_timeslices(ce->engine))
> > __set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
> > @@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
> > mutex_destroy(&ctx->engines_mutex);
> > mutex_destroy(&ctx->lut_mutex);
> > -   if (ctx->timeline)
> > -   intel_timeline_put(ctx->timeline);
> > +   if (ctx->syncobj)
> > +   drm_syncobj_put(ctx->syncobj);
> > put_pid(ctx->pid);
> > mutex_destroy(&ctx->mutex);
> > @@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context 
> > *ctx,
> > i915_vm_close(vm);
> >   }
> > -static void __set_timeline(struct intel_timeline **dst,
> > -  struct intel_timeline *src)
> > -{
>

Re: [PATCH v4 1/4] drm: sun4i: dsi: Use drm_of_find_panel_or_bridge

Hi Jagan,

On Wed, Mar 24, 2021 at 03:19:10PM +0530, Jagan Teki wrote:
> On Wed, Mar 24, 2021 at 3:09 PM Laurent Pinchart wrote:
> > On Wed, Mar 24, 2021 at 02:44:57PM +0530, Jagan Teki wrote:
> > > On Wed, Mar 24, 2021 at 8:18 AM Samuel Holland wrote:
> > > > On 3/23/21 5:53 PM, Laurent Pinchart wrote:
> > > > > On Mon, Mar 22, 2021 at 07:31:49PM +0530, Jagan Teki wrote:
> > > > >> Replace of_drm_find_panel with drm_of_find_panel_or_bridge
> > > > >> for finding panel, this indeed help to find the bridge if
> > > > >> bridge support added.
> > > > >>
> > > > >> Added NULL in bridge argument, same will replace with bridge
> > > > >> parameter once bridge supported.
> > > > >>
> > > > >> Signed-off-by: Jagan Teki 
> > > > >
> > > > > Looks good, there should be no functional change.
> > > >
> > > > Actually this breaks all existing users of this driver, see below.
> > > >
> > > > > Reviewed-by: Laurent Pinchart 
> > > > >
> > > > >> ---
> > > > >> Changes for v4, v3:
> > > > >> - none
> > > > >>
> > > > >>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 11 ---
> > > > >>  1 file changed, 8 insertions(+), 3 deletions(-)
> > > > >>
> > > > >> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > > > >> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > >> index 4f5efcace68e..2e9e7b2d4145 100644
> > > > >> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > >> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > >> @@ -21,6 +21,7 @@
> > > > >>
> > > > >>  #include 
> > > > >>  #include 
> > > > >> +#include 
> > > > >>  #include 
> > > > >>  #include 
> > > > >>  #include 
> > > > >> @@ -963,10 +964,14 @@ static int sun6i_dsi_attach(struct 
> > > > >> mipi_dsi_host *host,
> > > > >>  struct mipi_dsi_device *device)
> > > > >>  {
> > > > >>  struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> > > > >> -struct drm_panel *panel = 
> > > > >> of_drm_find_panel(device->dev.of_node);
> > > >
> > > > This is using the OF node of the DSI device, which is a direct child of
> > > > the DSI host's OF node. There is no OF graph involved.
> > > >
> > > > >> +struct drm_panel *panel;
> > > > >> +int ret;
> > > > >> +
> > > > >> +ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 0, 0,
> > > > >> +  &panel, NULL);
> > > >
> > > > However, this function expects to find the panel using OF graph. This
> > > > does not work with existing device trees (PinePhone, PineTab) which do
> > > > not use OF graph to connect the panel. And it cannot work, because the
> > > > DSI host's binding specifies a single port: the input port from the
> > > > display engine.
> > >
> > > Thanks for noticing this. I did understand your point and yes, I did
> > > mention the updated pipeline in previous versions and forgot to add it
> > > to this series.
> > >
> > > Here is the updated pipeline to make it work:
> > >
> > > https://patchwork.kernel.org/project/dri-devel/patch/20190524104252.20236-1-ja...@amarulasolutions.com/
> > >
> > > Let me know your comments on this, so I will add a patch for the
> > > above-affected DTS files.
> >
> > DT is an ABI, we need to ensure backward compatibility. Changes in
> > kernel drivers can't break devices that have an old DT.
> 
> Thanks for your point.
> 
> So, we need to choose APIs that would compatible with the old DT and
> new DT changes. Am I correct?

Yes, that's correct.

-- 
Regards,

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

Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages

On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel) wrote:
> 
> On 3/23/21 5:37 PM, Jason Gunthorpe wrote:
> > On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel) wrote:
> > 
> > > > > @@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct 
> > > > > vm_fault *vmf,
> > > > >   if ((pfn & (fault_page_size - 1)) != 0)
> > > > >   goto out_fallback;
> > > > > + /*
> > > > > +  * Huge entries must be special, that is marking them as devmap
> > > > > +  * with no backing device map range. If there is a backing
> > > > > +  * range, Don't insert a huge entry.
> > > > > +  * If this check turns out to be too much of a performance hit,
> > > > > +  * we can instead have drivers indicate whether they may have
> > > > > +  * backing device map ranges and if not, skip this lookup.
> > > > > +  */
> > > > I think we can do this statically:
> > > > - if it's system memory we know there's no devmap for it, and we do the
> > > > trick to block gup_fast
> > > Yes, that should work.
> > > > - if it's iomem, we know gup_fast wont work anyway if don't set PFN_DEV,
> > > > so might as well not do that
> > > I think gup_fast will unfortunately mistake a huge iomem page for an
> > > ordinary page and try to access a non-existant struct page for it, unless 
> > > we
> > > do the devmap trick.
> > > 
> > > And the lookup would then be for the rare case where a driver would have
> > > already registered a dev_pagemap for an iomem area which may also be 
> > > mapped
> > > through TTM (like the patch from Felix a couple of weeks ago). If a driver
> > > can promise not to do that, then we can safely remove the lookup.
> > Isn't the devmap PTE flag arch optional? Does this fall back to not
> > using huge pages on arches that don't support it?
> 
> Good point. No, currently it's only conditioned on transhuge page support.
> Need to condition it on also devmap support.
> 
> > 
> > Also, I feel like this code to install "pte_special" huge pages does
> > not belong in the drm subsystem..
> 
> I could add helpers in huge_memory.c:
> 
> vmf_insert_pfn_pmd_prot_special() and
> vmf_insert_pfn_pud_prot_special()

The somewhat annoying thing is that we'd need an error code so we fall
back to pte fault handling. That's at least my understanding of how
pud/pmd fault handling works. Not sure how awkward that is going to be
with the overall fault handling flow.

But aside from that I think this makes tons of sense.
-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: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages

On Tue, Mar 23, 2021 at 09:42:18PM +0100, Thomas Hellström (Intel) wrote:
> 
> On 3/23/21 8:52 PM, Williams, Dan J wrote:
> > On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:
> > > TTM sets up huge page-table-entries both to system- and device
> > > memory,
> > > and we don't want gup to assume there are always valid backing struct
> > > pages for these. For PTEs this is handled by setting the pte_special
> > > bit,
> > > but for the huge PUDs and PMDs, we have neither pmd_special nor
> > > pud_special. Normally, huge TTM entries are identified by looking at
> > > vma_is_special_huge(), but fast gup can't do that, so as an
> > > alternative
> > > define _devmap entries for which there are no backing dev_pagemap as
> > > special, update documentation and make huge TTM entries _devmap,
> > > after
> > > verifying that there is no backing dev_pagemap.
> > Please do not abuse p{m,u}d_devmap like this. I'm in the process of
> > removing get_devpagemap() from the gup-fast path [1]. Instead there
> > should be space for p{m,u}d_special in the page table entries (at least
> > for x86-64). So the fix is to remove that old assumption that huge
> > pages can never be special.
> > 
> > [1]:
> > http://lore.kernel.org/r/161604050866.1463742.7759521510383551055.st...@dwillia2-desk3.amr.corp.intel.com
> > 
> Hmm, yes with that patch it will obviously not work as intended.
> 
> Given that, I think we'll need to disable the TTM huge pages for now until
> we can sort out and agree on using a page table entry bit.

Yeah :-/

I think going full pud/pmd_mkspecial should then also mesh well with
Jason's request to wrap it all up into a vmf_insert_* helper, so at least
it would all look rather pretty in the end.
-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] i915_vma: Rename vma_lookup to i915_vma_lookup

On Tue, Mar 23, 2021 at 01:42:21PM +, Liam Howlett wrote:
> Use i915 prefix to avoid name collision with future vma_lookup() in mm.
> 
> Signed-off-by: Liam R. Howlett 
> Reviewed-by: Matthew Wilcox (Oracle) 

Applied to i915-gem-next branch for 5.13. We have a bit a branch shuffling
going on right now so unusal path, it should show up in linux-next through
drm-next hopefully this week still.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_vma.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index caa9b041616b..ee0028c697f6 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -230,7 +230,7 @@ vma_create(struct drm_i915_gem_object *obj,
>  }
>  
>  static struct i915_vma *
> -vma_lookup(struct drm_i915_gem_object *obj,
> +i915_vma_lookup(struct drm_i915_gem_object *obj,
>  struct i915_address_space *vm,
>  const struct i915_ggtt_view *view)
>  {
> @@ -278,7 +278,7 @@ i915_vma_instance(struct drm_i915_gem_object *obj,
>   GEM_BUG_ON(!atomic_read(&vm->open));
>  
>   spin_lock(&obj->vma.lock);
> - vma = vma_lookup(obj, vm, view);
> + vma = i915_vma_lookup(obj, vm, view);
>   spin_unlock(&obj->vma.lock);
>  
>   /* vma_create() will resolve the race if another creates the vma */
> -- 
> 2.30.0

-- 
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: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages

On 3/24/21 10:58 AM, Daniel Vetter wrote:

On Tue, Mar 23, 2021 at 09:42:18PM +0100, Thomas Hellström (Intel) wrote:

On 3/23/21 8:52 PM, Williams, Dan J wrote:

On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:

TTM sets up huge page-table-entries both to system- and device
memory,
and we don't want gup to assume there are always valid backing struct
pages for these. For PTEs this is handled by setting the pte_special
bit,
but for the huge PUDs and PMDs, we have neither pmd_special nor
pud_special. Normally, huge TTM entries are identified by looking at
vma_is_special_huge(), but fast gup can't do that, so as an
alternative
define _devmap entries for which there are no backing dev_pagemap as
special, update documentation and make huge TTM entries _devmap,
after
verifying that there is no backing dev_pagemap.

Please do not abuse p{m,u}d_devmap like this. I'm in the process of
removing get_devpagemap() from the gup-fast path [1]. Instead there
should be space for p{m,u}d_special in the page table entries (at least
for x86-64). So the fix is to remove that old assumption that huge
pages can never be special.

[1]:
http://lore.kernel.org/r/161604050866.1463742.7759521510383551055.st...@dwillia2-desk3.amr.corp.intel.com

Hmm, yes with that patch it will obviously not work as intended.

Given that, I think we'll need to disable the TTM huge pages for now until
we can sort out and agree on using a page table entry bit.

Yeah :-/

I think going full pud/pmd_mkspecial should then also mesh well with
Jason's request to wrap it all up into a vmf_insert_* helper, so at least
it would all look rather pretty in the end.

Yes, I agree. Seems like the special (SW1) is available also for huge
page table entries on x86 AFAICT, although just not implemented.
Otherwise the SW bits appear completely used up.

The PTE size vmf_insert_pfn__xxx functions either insert one of devmap
or special. I think the only users of the huge insert functions apart
form TTM currently insert devmap so we should probably be able to do the
same, and then DRM / TTM wouldn't need to care at all about special or not.

/Thomas

-Daniel

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

Re: [PATCH v4 1/4] drm: sun4i: dsi: Use drm_of_find_panel_or_bridge

On Wed, Mar 24, 2021 at 11:55:35AM +0200, Laurent Pinchart wrote:
> Hi Jagan,
> 
> On Wed, Mar 24, 2021 at 03:19:10PM +0530, Jagan Teki wrote:
> > On Wed, Mar 24, 2021 at 3:09 PM Laurent Pinchart wrote:
> > > On Wed, Mar 24, 2021 at 02:44:57PM +0530, Jagan Teki wrote:
> > > > On Wed, Mar 24, 2021 at 8:18 AM Samuel Holland wrote:
> > > > > On 3/23/21 5:53 PM, Laurent Pinchart wrote:
> > > > > > On Mon, Mar 22, 2021 at 07:31:49PM +0530, Jagan Teki wrote:
> > > > > >> Replace of_drm_find_panel with drm_of_find_panel_or_bridge
> > > > > >> for finding panel, this indeed help to find the bridge if
> > > > > >> bridge support added.
> > > > > >>
> > > > > >> Added NULL in bridge argument, same will replace with bridge
> > > > > >> parameter once bridge supported.
> > > > > >>
> > > > > >> Signed-off-by: Jagan Teki 
> > > > > >
> > > > > > Looks good, there should be no functional change.
> > > > >
> > > > > Actually this breaks all existing users of this driver, see below.
> > > > >
> > > > > > Reviewed-by: Laurent Pinchart 
> > > > > >
> > > > > >> ---
> > > > > >> Changes for v4, v3:
> > > > > >> - none
> > > > > >>
> > > > > >>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 11 ---
> > > > > >>  1 file changed, 8 insertions(+), 3 deletions(-)
> > > > > >>
> > > > > >> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > > > > >> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > > >> index 4f5efcace68e..2e9e7b2d4145 100644
> > > > > >> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > > >> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > > >> @@ -21,6 +21,7 @@
> > > > > >>
> > > > > >>  #include 
> > > > > >>  #include 
> > > > > >> +#include 
> > > > > >>  #include 
> > > > > >>  #include 
> > > > > >>  #include 
> > > > > >> @@ -963,10 +964,14 @@ static int sun6i_dsi_attach(struct 
> > > > > >> mipi_dsi_host *host,
> > > > > >>  struct mipi_dsi_device *device)
> > > > > >>  {
> > > > > >>  struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> > > > > >> -struct drm_panel *panel = 
> > > > > >> of_drm_find_panel(device->dev.of_node);
> > > > >
> > > > > This is using the OF node of the DSI device, which is a direct child 
> > > > > of
> > > > > the DSI host's OF node. There is no OF graph involved.
> > > > >
> > > > > >> +struct drm_panel *panel;
> > > > > >> +int ret;
> > > > > >> +
> > > > > >> +ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 0, 0,
> > > > > >> +  &panel, NULL);
> > > > >
> > > > > However, this function expects to find the panel using OF graph. This
> > > > > does not work with existing device trees (PinePhone, PineTab) which do
> > > > > not use OF graph to connect the panel. And it cannot work, because the
> > > > > DSI host's binding specifies a single port: the input port from the
> > > > > display engine.
> > > >
> > > > Thanks for noticing this. I did understand your point and yes, I did
> > > > mention the updated pipeline in previous versions and forgot to add it
> > > > to this series.
> > > >
> > > > Here is the updated pipeline to make it work:
> > > >
> > > > https://patchwork.kernel.org/project/dri-devel/patch/20190524104252.20236-1-ja...@amarulasolutions.com/
> > > >
> > > > Let me know your comments on this, so I will add a patch for the
> > > > above-affected DTS files.
> > >
> > > DT is an ABI, we need to ensure backward compatibility. Changes in
> > > kernel drivers can't break devices that have an old DT.
> > 
> > Thanks for your point.
> > 
> > So, we need to choose APIs that would compatible with the old DT and
> > new DT changes. Am I correct?
> 
> Yes, that's correct.

However, I see no particular reason to change the DT binding in this
case. The DSI devices are supposed to be described through a subnode of
their DSI controller, that's the generic binding and except for very odd
devices (and a bridge like this one is certainly not one), I see no
reason to deviate from that.

Maxime


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

Re: [Intel-gfx] [PATCH v9 68/70] drm/i915: Pass ww ctx to pin_map

On Wed, Mar 24, 2021 at 10:31:26AM +0100, Maarten Lankhorst wrote:
> Op 23-03-2021 om 18:30 schreef Matthew Auld:
> > On Tue, 23 Mar 2021 at 15:51, Maarten Lankhorst
> >  wrote:
> >> This will allow us to explicitly pass the ww to pin_pages,
> >> when it starts taking it.
> >>
> >> This allows us to finally kill off the explicit passing of ww
> >> by retrieving it from the obj.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  7 ---
> >>  drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  2 +-
> >>  drivers/gpu/drm/i915/gem/i915_gem_object.h|  1 +
> >>  .../gpu/drm/i915/gem/i915_gem_object_blt.c|  4 ++--
> >>  drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 +++
> >>  .../drm/i915/gem/selftests/i915_gem_context.c |  8 ---
> >>  .../drm/i915/gem/selftests/i915_gem_dmabuf.c  |  2 +-
> >>  drivers/gpu/drm/i915/gt/gen7_renderclear.c|  2 +-
> >>  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  2 +-
> >>  drivers/gpu/drm/i915/gt/intel_engine_pm.c |  2 +-
> >>  drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 ++--
> >>  drivers/gpu/drm/i915/gt/intel_renderstate.c   |  2 +-
> >>  drivers/gpu/drm/i915/gt/intel_ring.c  |  2 +-
> >>  .../gpu/drm/i915/gt/intel_ring_submission.c   |  2 +-
> >>  drivers/gpu/drm/i915/gt/intel_timeline.c  |  7 ---
> >>  drivers/gpu/drm/i915/gt/intel_timeline.h  |  3 ++-
> >>  drivers/gpu/drm/i915/gt/intel_workarounds.c   |  2 +-
> >>  drivers/gpu/drm/i915/gt/mock_engine.c |  2 +-
> >>  drivers/gpu/drm/i915/gt/selftest_lrc.c|  2 +-
> >>  drivers/gpu/drm/i915/gt/selftest_rps.c| 10 -
> >>  .../gpu/drm/i915/gt/selftest_workarounds.c|  6 +++---
> >>  drivers/gpu/drm/i915/gvt/cmd_parser.c |  4 ++--
> >>  drivers/gpu/drm/i915/i915_perf.c  |  4 ++--
> >>  drivers/gpu/drm/i915/selftests/igt_spinner.c  |  2 +-
> >>  24 files changed, 60 insertions(+), 43 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> >> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >> index dcfcae9c841b..73dd2a7673f5 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >> @@ -1340,7 +1340,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer 
> >> *eb,
> >> if (err)
> >> goto err_pool;
> >>
> >> -   cmd = i915_gem_object_pin_map(pool->obj, pool->type);
> >> +   cmd = i915_gem_object_pin_map(pool->obj, &eb->ww, pool->type);
> >> if (IS_ERR(cmd)) {
> >> err = PTR_ERR(cmd);
> >> goto err_pool;
> >> @@ -2489,7 +2489,8 @@ static int eb_parse_pipeline(struct i915_execbuffer 
> >> *eb,
> >> goto err_shadow;
> >> }
> >>
> >> -   pw->shadow_map = i915_gem_object_pin_map(shadow->obj, I915_MAP_WB);
> >> +   pw->shadow_map = i915_gem_object_pin_map(shadow->obj, &eb->ww,
> >> +I915_MAP_WB);
> >> if (IS_ERR(pw->shadow_map)) {
> >> err = PTR_ERR(pw->shadow_map);
> >> goto err_trampoline;
> >> @@ -2500,7 +2501,7 @@ static int eb_parse_pipeline(struct i915_execbuffer 
> >> *eb,
> >>
> >> pw->batch_map = ERR_PTR(-ENODEV);
> >> if (needs_clflush && i915_has_memcpy_from_wc())
> >> -   pw->batch_map = i915_gem_object_pin_map(batch, 
> >> I915_MAP_WC);
> >> +   pw->batch_map = i915_gem_object_pin_map(batch, &eb->ww, 
> >> I915_MAP_WC);
> >>
> >> if (IS_ERR(pw->batch_map)) {
> >> err = i915_gem_object_pin_pages(batch);
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
> >> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> >> index 2561a2f1e54f..edac8ee3be9a 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> >> @@ -439,7 +439,7 @@ vm_access(struct vm_area_struct *area, unsigned long 
> >> addr,
> >> goto out;
> >>
> >> /* As this is primarily for debugging, let's focus on simplicity */
> >> -   vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
> >> +   vaddr = i915_gem_object_pin_map(obj, &ww, I915_MAP_FORCE_WC);
> >> if (IS_ERR(vaddr)) {
> >> err = PTR_ERR(vaddr);
> >> goto out;
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
> >> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> >> index 1a8ec4035112..9bd9b47dcc8d 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> >> @@ -450,6 +450,7 @@ void i915_gem_object_writeback(struct 
> >> drm_i915_gem_object *obj);
> >>   * ERR_PTR() on error.
> >>   */
> >>  void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object 
> >> *obj,
> >> +  struct i915_gem_ww_ctx *ww,
> >>

Re: [PATCH] drm/amdgpu: Ensure that the modifier requested is supported by plane.

2021-03-24 Thread Michel Dänzer

On 2021-03-23 4:32 p.m., Mark Yacoub wrote:
> On Tue, Mar 23, 2021 at 11:02 AM Alex Deucher  wrote:
>>
>> On Wed, Mar 10, 2021 at 11:15 AM Mark Yacoub  wrote:
>>>
>>> From: Mark Yacoub 
>>>
>>> On initializing the framebuffer, call drm_any_plane_has_format to do a
>>> check if the modifier is supported. drm_any_plane_has_format calls
>>> dm_plane_format_mod_supported which is extended to validate that the
>>> modifier is on the list of the plane's supported modifiers.
>>>
>>> The bug was caught using igt-gpu-tools test: 
>>> kms_addfb_basic.addfb25-bad-modifier
>>>
>>> Tested on ChromeOS Zork by turning on the display, running an overlay
>>> test, and running a YT video.
>>>
>>> Cc: Alex Deucher 
>>> Cc: Bas Nieuwenhuizen 
>>> Signed-off-by: default avatarMark Yacoub 
>>
>> I'm not an expert with modifiers yet.  Will this break chips which
>> don't currently support modifiers?
> No it shouldn't. When you don't support modifiers yet, your will
> default to Linear Modifier (DRM_FORMAT_MOD_LINEAR),
> [...]
No modifier support does not imply linear. It's generally signalled via 
DRM_FORMAT_MOD_INVALID, which roughly means "tiling is determined by driver 
specific mechanisms".


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: stop warning on TT shrinker failure



On 3/23/21 4:45 PM, Christian König wrote:

Am 23.03.21 um 16:13 schrieb Michal Hocko:

On Tue 23-03-21 14:56:54, Christian König wrote:

Am 23.03.21 um 14:41 schrieb Michal Hocko:

[...]
Anyway, I am wondering whether the overall approach is sound. Why 
don't
you simply use shmem as your backing storage from the beginning and 
pin

those pages if they are used by the device?
Yeah, that is exactly what the Intel guys are doing for their 
integrated

GPUs :)

Problem is for TTM I need to be able to handle dGPUs and those have all
kinds of funny allocation restrictions. In other words I need to 
guarantee
that the allocated memory is coherent accessible to the GPU without 
using

SWIOTLB.

The simple case is that the device can only do DMA32, but you also got
device which can only do 40bits or 48bits.

On top of that you also got AGP, CMA and stuff like CPU cache behavior
changes (write back vs. write through, vs. uncached).

OK, so the underlying problem seems to be that gfp mask (thus
mapping_gfp_mask) cannot really reflect your requirements, right?  Would
it help if shmem would allow to provide an allocation callback to
override alloc_page_vma which is used currently? I am pretty sure there
will be more to handle but going through shmem for the whole life time
is just so much easier to reason about than some tricks to abuse shmem
just for the swapout path.


Well it's a start, but the pages can have special CPU cache settings. 
So direct IO from/to them usually doesn't work as expected.


Additional to that for AGP and CMA I need to make sure that I give 
those pages back to the relevant subsystems instead of just dropping 
the page reference.


So I would need to block for the swapio to be completed.

Anyway I probably need to revert those patches for now since this 
isn't working as we hoped it would.


Thanks for the explanation how stuff works here.


Another alternative here that I've tried before without being successful 
would perhaps be to drop shmem completely and, if it's a normal page (no 
dma or funny caching attributes) just use add_to_swap_cache()? If it's 
something else, try alloc a page with relevant gfp attributes, copy and 
add_to_swap_cache()? Or perhaps that doesn't work well from a shrinker 
either?


/Thomas





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

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

Re: [PATCH v1] MAINTAINERS: Update Maintainers of DRM Bridge Drivers

2021-03-24 Thread Neil Armstrong

Hi !

On 24/03/2021 11:20, Robert Foss wrote:
> Add myself as co-maintainer of DRM Bridge Drivers. Repository
> commit access has already been granted.
> 
> https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/338
> 
> Cc: Neil Armstrong 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Andrzej Hajda 
> Cc: Jernej Škrabec 
> Cc: Daniel Vetter 
> Signed-off-by: Robert Foss 

+ CC: dri-devel@lists.freedesktop.org

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4b705ba51c54..16ace8f58649 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5902,6 +5902,7 @@ F:  drivers/gpu/drm/atmel-hlcdc/
>  DRM DRIVERS FOR BRIDGE CHIPS
>  M:   Andrzej Hajda 
>  M:   Neil Armstrong 
> +M:   Robert Foss 
>  R:   Laurent Pinchart 
>  R:   Jonas Karlman 
>  R:   Jernej Skrabec 
> 

Acked-by: Neil Armstrong 

Welcome to the team, help is needed !

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

Re: [PATCH v1] MAINTAINERS: Update Maintainers of DRM Bridge Drivers

Hi Rob,

On Wed, Mar 24, 2021 at 11:20:19AM +0100, Robert Foss wrote:
> Add myself as co-maintainer of DRM Bridge Drivers. Repository
> commit access has already been granted.
> 
> https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/338
> 
> Cc: Neil Armstrong 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Andrzej Hajda 
> Cc: Jernej Škrabec 
> Cc: Daniel Vetter 
> Signed-off-by: Robert Foss 

Acked-by: Laurent Pinchart 

and welcome :-)

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4b705ba51c54..16ace8f58649 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5902,6 +5902,7 @@ F:  drivers/gpu/drm/atmel-hlcdc/
>  DRM DRIVERS FOR BRIDGE CHIPS
>  M:   Andrzej Hajda 
>  M:   Neil Armstrong 
> +M:   Robert Foss 
>  R:   Laurent Pinchart 
>  R:   Jonas Karlman 
>  R:   Jernej Skrabec 

-- 
Regards,

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

Re: [RESEND 00/19] Rid GPU from W=1 warnings

2021-03-24 Thread Lee Jones

Daniel,

> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> This is a resend of the remaining patches.
> 
> All of these patches have been sent before.

Are you still keen to 'hoover these up'?

Just leave the one that requires work and take the rest perhaps?

> Lee Jones (19):
>   drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc
>   drm/nouveau/dispnv50/disp: Remove unused variable 'ret'
>   drm/msm/dp/dp_display: Remove unused variable 'hpd'
>   include: drm: drm_atomic: Make use of 'new_plane_state'
>   drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc
> headers
>   drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the
> stack to the heap
>   drm/amd/display/dc/calcs/dce_calcs: Remove some large variables from
> the stack
>   drm/amd/display/dc/dce80/dce80_resource: Make local functions static
>   drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc
> header
>   drm/nouveau/nouveau_bo: Remove unused variables 'dev'
>   drm/nouveau/nouveau_display: Remove set but unused variable 'width'
>   drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers
>   drm/nouveau/dispnv50/disp: Remove unused variable 'ret' from function
> returning void
>   drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut'
> static
>   drm/nouveau/nv50_display: Remove superfluous prototype for local
> static functions
>   drm/nouveau/dispnv50/disp: Include header containing our prototypes
>   drm/nouveau/nouveau_ioc32: File headers are not good candidates for
> kernel-doc
>   drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void
> function
>   drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment
> block
> 
>  .../gpu/drm/amd/display/dc/calcs/dce_calcs.c  | 1154 +
>  .../drm/amd/display/dc/dce80/dce80_resource.c |   16 +-
>  drivers/gpu/drm/msm/dp/dp_display.c   |3 -
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c   |4 +-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |   10 +-
>  drivers/gpu/drm/nouveau/dispnv50/headc57d.c   |2 +-
>  drivers/gpu/drm/nouveau/nouveau_bo.c  |4 -
>  drivers/gpu/drm/nouveau/nouveau_display.c |8 +-
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c   |4 +-
>  drivers/gpu/drm/nouveau/nouveau_svm.c |5 +-
>  drivers/gpu/drm/nouveau/nv50_display.h|3 -
>  .../gpu/drm/nouveau/nvkm/engine/gr/gf100.c|2 +-
>  .../gpu/drm/nouveau/nvkm/subdev/bios/init.c   |  204 +--
>  .../gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c  |4 +-
>  include/drm/drm_atomic.h  |3 +-
>  15 files changed, 692 insertions(+), 734 deletions(-)
> 
> Cc: Alex Deucher 
> Cc: amd-...@lists.freedesktop.org
> Cc: Anthony Koo 
> Cc: Ben Skeggs 
> Cc: "Christian König" 
> Cc: Colin Ian King 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Cc: freedr...@lists.freedesktop.org
> Cc: Harry Wentland 
> Cc: Jeremy Kolb 
> Cc: Kuogee Hsieh 
> Cc: Leo Li 
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Lyude Paul 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: nouv...@lists.freedesktop.org
> Cc: Rob Clark 
> Cc: Sean Paul 
> Cc: Sumit Semwal 
> Cc: Thomas Zimmermann 

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning

2021-03-24 Thread David Laight

From: David Laight
> Sent: 24 March 2021 09:12
> 
> From: Martin Sebor
> > Sent: 22 March 2021 22:08
> ...
> > In GCC 11, all access warnings expect objects to be either declared
> > or allocated.  Pointers with constant values are taken to point to
> > nothing valid (as Arnd mentioned above, this is to detect invalid
> > accesses to members of structs at address zero).
> >
> > One possible solution to the known address problem is to extend GCC
> > attributes address and io that pin an object to a hardwired address
> > to all targets (at the moment they're supported on just one or two
> > targets).  I'm not sure this can still happen before GCC 11 releases
> > sometime in April or May.
> 
> A different solution is to define a normal C external data item
> and then assign a fixed address with an asm statement or in
> the linker script.

Or stop gcc tracking the value by using:
struct foo *foo = (void *)x;
asm ("", "+r" (foo));

If the address is used more than once forcing it into
a register is also likely to generate better code.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/6] drm/sprd: add Unisoc's drm kms master

Hi

On Mon, Feb 22, 2021 at 09:28:18PM +0800, Kevin Tang wrote:
> Adds drm support for the Unisoc's display subsystem.
> 
> This is drm kms driver, this driver provides support for the
> application framework in Android, Yocto and more.
> 
> Application framework can access Unisoc's display internel

^ internal

> peripherals through libdrm or libkms, it's test ok by modetest
> (DRM/KMS test tool) and Android HWComposer.
> 
> Cc: Orson Zhai 
> Cc: Chunyan Zhang 
> Signed-off-by: Kevin Tang 
> 
> v4:
>   - Move the devm_drm_dev_alloc to master_ops->bind function.
>   - The managed drmm_mode_config_init() it is no longer necessary for drivers 
> to explicitly call drm_mode_config_cleanup, so delete it.
> ---
>  drivers/gpu/drm/Kconfig |   2 +
>  drivers/gpu/drm/Makefile|   1 +
>  drivers/gpu/drm/sprd/Kconfig|  12 ++
>  drivers/gpu/drm/sprd/Makefile   |   5 +
>  drivers/gpu/drm/sprd/sprd_drm.c | 217 
>  drivers/gpu/drm/sprd/sprd_drm.h |  16 +++
>  6 files changed, 253 insertions(+)
>  create mode 100644 drivers/gpu/drm/sprd/Kconfig
>  create mode 100644 drivers/gpu/drm/sprd/Makefile
>  create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
>  create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 8bf103de1..9d6ce2867 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -382,6 +382,8 @@ source "drivers/gpu/drm/tidss/Kconfig"
>  
>  source "drivers/gpu/drm/xlnx/Kconfig"
>  
> +source "drivers/gpu/drm/sprd/Kconfig"
> +
>  # Keep legacy drivers last
>  
>  menuconfig DRM_LEGACY
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 02c229392..42d211d9c 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -126,3 +126,4 @@ obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
>  obj-$(CONFIG_DRM_MCDE) += mcde/
>  obj-$(CONFIG_DRM_TIDSS) += tidss/
>  obj-y+= xlnx/
> +obj-$(CONFIG_DRM_SPRD) += sprd/
> diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> new file mode 100644
> index 0..6e80cc9f3
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/Kconfig
> @@ -0,0 +1,12 @@
> +config DRM_SPRD
> + tristate "DRM Support for Unisoc SoCs Platform"
> + depends on ARCH_SPRD || COMPILE_TEST
> + depends on DRM && OF
> + select DRM_KMS_HELPER
> + select DRM_GEM_CMA_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_MIPI_DSI

I guess this should rather be moved to your DSI introduction patch?

> + help
> +   Choose this option if you have a Unisoc chipset.
> +   If M is selected the module will be called sprd_drm.
> +
> diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
> new file mode 100644
> index 0..86d95d93a
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +subdir-ccflags-y += -I$(srctree)/$(src)

Is it really needed? I'm not seeing any header that aren't in the
include path already.

> +obj-y := sprd_drm.o
> diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
> new file mode 100644
> index 0..a1d3ed655
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/sprd_drm.c
> @@ -0,0 +1,217 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Unisoc Inc.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sprd_drm.h"
> +
> +#define DRIVER_NAME  "sprd"
> +#define DRIVER_DESC  "Spreadtrum SoCs' DRM Driver"
> +#define DRIVER_DATE  "20200201"
> +#define DRIVER_MAJOR 1
> +#define DRIVER_MINOR 0
> +
> +static const struct drm_mode_config_helper_funcs sprd_drm_mode_config_helper 
> = {
> + .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> +};
> +
> +static const struct drm_mode_config_funcs sprd_drm_mode_config_funcs = {
> + .fb_create = drm_gem_fb_create,
> + .atomic_check = drm_atomic_helper_check,
> + .atomic_commit = drm_atomic_helper_commit,
> +};
> +
> +static void sprd_drm_mode_config_init(struct drm_device *drm)
> +{
> + drm->mode_config.min_width = 0;
> + drm->mode_config.min_height = 0;
> + drm->mode_config.max_width = 8192;
> + drm->mode_config.max_height = 8192;
> + drm->mode_config.allow_fb_modifiers = true;
> +
> + drm->mode_config.funcs = &sprd_drm_mode_config_funcs;
> + drm->mode_config.helper_private = &sprd_drm_mode_config_helper;
> +}
> +
> +DEFINE_DRM_GEM_CMA_FOPS(sprd_drm_fops);
> +
> +static struct drm_driver sprd_drm_drv = {
> + .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> + .fops   = &sprd_drm_fops,
> +
> + /* GEM Operations */
> + DRM_GEM_CMA_DRIVER_OPS,
> +
> + .name   = D

Re: [PATCH] drm/amdgpu: Ensure that the modifier requested is supported by plane.

2021-03-24 Thread Bas Nieuwenhuizen

On Wed, Mar 24, 2021 at 11:13 AM Michel Dänzer  wrote:

> On 2021-03-23 4:32 p.m., Mark Yacoub wrote:
> > On Tue, Mar 23, 2021 at 11:02 AM Alex Deucher 
> wrote:
> >>
> >> On Wed, Mar 10, 2021 at 11:15 AM Mark Yacoub 
> wrote:
> >>>
> >>> From: Mark Yacoub 
> >>>
> >>> On initializing the framebuffer, call drm_any_plane_has_format to do a
> >>> check if the modifier is supported. drm_any_plane_has_format calls
> >>> dm_plane_format_mod_supported which is extended to validate that the
> >>> modifier is on the list of the plane's supported modifiers.
> >>>
> >>> The bug was caught using igt-gpu-tools test:
> kms_addfb_basic.addfb25-bad-modifier
> >>>
> >>> Tested on ChromeOS Zork by turning on the display, running an overlay
> >>> test, and running a YT video.
> >>>
> >>> Cc: Alex Deucher 
> >>> Cc: Bas Nieuwenhuizen 
> >>> Signed-off-by: default avatarMark Yacoub 
> >>
> >> I'm not an expert with modifiers yet.  Will this break chips which
> >> don't currently support modifiers?
> > No it shouldn't. When you don't support modifiers yet, your will
> > default to Linear Modifier (DRM_FORMAT_MOD_LINEAR),
> > [...]
> No modifier support does not imply linear. It's generally signalled via
> DRM_FORMAT_MOD_INVALID, which roughly means "tiling is determined by driver
> specific mechanisms".
>

Doesn't quite work that way in the kernel sadly. If you don't set
DRM_MODE_FB_MODIFIERS then the modifier fields have to be 0 (which happens
to alias DRM_FORMAT_MOD_LINEAR and then now deprecated
DRM_FORMAT_MOD_NONE). This is verified in shared drm code.

(and all userspace code I've seen simply doesn't set DRM_MODE_FB_MODIFIERS
if the incoming modifier is DRM_FORMAT_MOD_INVALID)

>
>
> --
> Earthling Michel Dänzer   |   https://redhat.com
> Libre software enthusiast | Mesa and X developer
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 4/6] drm/sprd: add Unisoc's drm display controller driver

Hi,

On Mon, Feb 22, 2021 at 09:28:20PM +0800, Kevin Tang wrote:
> Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
> It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
> 
> Cc: Orson Zhai 
> Cc: Chunyan Zhang 
> Signed-off-by: Kevin Tang 
> 
> v2:
>   - Use drm_xxx to replace all DRM_XXX.
>   - Use kzalloc to replace devm_kzalloc for sprd_dpu structure init.
> 
> v3:
>   - Remove dpu_layer stuff layer and commit layers by aotmic_update
> 
> v4:
>   - Use drmm_helpers to allocate crtc and planes.
>   - Move rotation enum definitions to crtc layer reg bitfields.
>   - Move allocate crtc and planes to bind funtion.

There's a number of checkpatch warnings, make sure to fix them

> ---
>  drivers/gpu/drm/sprd/Kconfig|   1 +
>  drivers/gpu/drm/sprd/Makefile   |   4 +-
>  drivers/gpu/drm/sprd/sprd_dpu.c | 964 
>  drivers/gpu/drm/sprd/sprd_dpu.h | 109 
>  drivers/gpu/drm/sprd/sprd_drm.c |   1 +
>  drivers/gpu/drm/sprd/sprd_drm.h |   2 +
>  6 files changed, 1079 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c
>  create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h
> 
> diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> index 6e80cc9f3..9b4ef9aea 100644
> --- a/drivers/gpu/drm/sprd/Kconfig
> +++ b/drivers/gpu/drm/sprd/Kconfig
> @@ -3,6 +3,7 @@ config DRM_SPRD
>   depends on ARCH_SPRD || COMPILE_TEST
>   depends on DRM && OF
>   select DRM_KMS_HELPER
> + select VIDEOMODE_HELPERS
>   select DRM_GEM_CMA_HELPER
>   select DRM_KMS_CMA_HELPER
>   select DRM_MIPI_DSI
> diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
> index 86d95d93a..6c25bfa99 100644
> --- a/drivers/gpu/drm/sprd/Makefile
> +++ b/drivers/gpu/drm/sprd/Makefile
> @@ -1,5 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
> -subdir-ccflags-y += -I$(srctree)/$(src)
> +obj-y := sprd_drm.o \
> + sprd_dpu.o
>  
> -obj-y := sprd_drm.o
> diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c b/drivers/gpu/drm/sprd/sprd_dpu.c
> new file mode 100644
> index 0..75b7e40d9
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/sprd_dpu.c
> @@ -0,0 +1,964 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Unisoc Inc.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sprd_drm.h"
> +#include "sprd_dpu.h"
> +
> +/* Global control registers */
> +#define REG_DPU_CTRL 0x04
> +#define REG_DPU_CFG0 0x08
> +#define REG_PANEL_SIZE   0x20
> +#define REG_BLEND_SIZE   0x24
> +#define REG_BG_COLOR 0x2C
> +
> +/* Layer0 control registers */
> +#define REG_LAY_BASE_ADDR0   0x30
> +#define REG_LAY_BASE_ADDR1   0x34
> +#define REG_LAY_BASE_ADDR2   0x38
> +#define REG_LAY_CTRL 0x40
> +#define REG_LAY_SIZE 0x44
> +#define REG_LAY_PITCH0x48
> +#define REG_LAY_POS  0x4C
> +#define REG_LAY_ALPHA0x50
> +#define REG_LAY_CROP_START   0x5C
> +
> +/* Interrupt control registers */
> +#define REG_DPU_INT_EN   0x1E0
> +#define REG_DPU_INT_CLR  0x1E4
> +#define REG_DPU_INT_STS  0x1E8
> +
> +/* DPI control registers */
> +#define REG_DPI_CTRL 0x1F0
> +#define REG_DPI_H_TIMING 0x1F4
> +#define REG_DPI_V_TIMING 0x1F8
> +
> +/* MMU control registers */
> +#define REG_MMU_EN   0x800
> +#define REG_MMU_VPN_RANGE0x80C
> +#define REG_MMU_VAOR_ADDR_RD 0x818
> +#define REG_MMU_VAOR_ADDR_WR 0x81C
> +#define REG_MMU_INV_ADDR_RD  0x820
> +#define REG_MMU_INV_ADDR_WR  0x824
> +#define REG_MMU_PPN1 0x83C
> +#define REG_MMU_RANGE1   0x840
> +#define REG_MMU_PPN2 0x844
> +#define REG_MMU_RANGE2   0x848
> +
> +/* Global control bits */
> +#define BIT_DPU_RUN  BIT(0)
> +#define BIT_DPU_STOP BIT(1)
> +#define BIT_DPU_REG_UPDATE   BIT(2)
> +#define BIT_DPU_IF_EDPI  BIT(0)
> +
> +/* Layer control bits */
> +#define BIT_DPU_LAY_EN   BIT(0)
> +#define BIT_DPU_LAY_LAYER_ALPHA  (0x01 << 2)
> +#define BIT_DPU_LAY_COMBO_ALPHA  (0x02 << 2)
> +#define BIT_DPU_LAY_FORMAT_YUV422_2PLANE (0x00 << 4)
> +#define BIT_DPU_LAY_FORMAT_YUV420_2PLANE (0x01 << 4)
> +#define BIT_DPU_LAY_FORMAT_YUV420_3PLANE (0x02 << 4)
> +#define BIT_DPU_LAY_FORMAT_ARGB  (0x03 << 4)
> +#define BIT_DPU_LAY_FORMAT_RGB565(0x04 << 4)
> +#define BIT_DPU_LAY_DATA_ENDIAN_B0B1B2B3 (0x00 << 8)
> +#define BIT_DPU_LAY_DATA_ENDIAN_B3B2B1B0 (0x01 << 8)
> +#define BIT_DPU_LAY_NO_SWITCH

Re: [PATCH v4 5/6] dt-bindings: display: add Unisoc's mipi dsi controller bindings

On Mon, Feb 22, 2021 at 09:28:21PM +0800, Kevin Tang wrote:
> From: Kevin Tang 
> 
> Adds MIPI DSI Controller
> support for Unisoc's display subsystem.
> 
> Cc: Orson Zhai 
> Cc: Chunyan Zhang 
> Signed-off-by: Kevin Tang 
> Reviewed-by: Rob Herring 
> ---
>  .../display/sprd/sprd,sharkl3-dsi-host.yaml   | 102 ++
>  1 file changed, 102 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml 
> b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
> new file mode 100644
> index 0..d439f688f
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
> @@ -0,0 +1,102 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dsi-host.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc MIPI DSI Controller
> +
> +maintainers:
> +  - Kevin Tang 
> +
> +properties:
> +  compatible:
> +const: sprd,sharkl3-dsi-host
> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +maxItems: 2
> +
> +  clocks:
> +minItems: 1
> +
> +  clock-names:
> +items:
> +  - const: clk_src_96m
> +
> +  power-domains:
> +maxItems: 1
> +
> +  ports:
> +type: object
> +
> +properties:
> +  "#address-cells":
> +const: 1
> +
> +  "#size-cells":
> +const: 0
> +
> +  port@0:
> +type: object
> +description:
> +  A port node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +  That port should be the input endpoint, usually coming from
> +  the associated DPU.
> +  port@1:
> +type: object
> +description:
> +  A port node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +  That port should be the output endpoint, usually output to
> +  the associated panel.

The DSI generic binding asks that peripherals that are controlled
through a DCS be a subnode of the MIPI-DSI bus, not through a port
endpoint.

Maxime


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

Re: [Intel-gfx] [PATCH v9 17/70] drm/i915: Flatten obj->mm.lock

On Tue, Mar 23, 2021 at 04:50:06PM +0100, Maarten Lankhorst wrote:
> With userptr fixed, there is no need for all separate lockdep classes
> now, and we can remove all lockdep tricks used. A trylock in the
> shrinker is all we need now to flatten the locking hierarchy.
> 
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Thomas Hellström 

Minor conflict with this one here when applying, due to lack of

https://lore.kernel.org/intel-gfx/20210202154318.19246-1-ch...@chris-wilson.co.

It's not a bad idea, but if we do this we really should move this helper
into the right headers, and ideally get linux-mm/-fs folks to ack this as
a good idea. Especially Dave Chinner very much wants to be in the loop for
anything that touches fs_reclaim lockdep annotations.
-Daniel


> ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.c   |  5 +--
>  drivers/gpu/drm/i915/gem/i915_gem_object.h   | 20 ++--
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c| 34 ++--
>  drivers/gpu/drm/i915/gem/i915_gem_phys.c |  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 10 +++---
>  drivers/gpu/drm/i915/gem/i915_gem_userptr.c  |  2 +-
>  6 files changed, 27 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 6083b9c14be6..821cb40f8d73 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -62,7 +62,7 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
> const struct drm_i915_gem_object_ops *ops,
> struct lock_class_key *key, unsigned flags)
>  {
> - __mutex_init(&obj->mm.lock, ops->name ?: "obj->mm.lock", key);
> + mutex_init(&obj->mm.lock);
>  
>   spin_lock_init(&obj->vma.lock);
>   INIT_LIST_HEAD(&obj->vma.list);
> @@ -86,9 +86,6 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
>   mutex_init(&obj->mm.get_page.lock);
>   INIT_RADIX_TREE(&obj->mm.get_dma_page.radix, GFP_KERNEL | __GFP_NOWARN);
>   mutex_init(&obj->mm.get_dma_page.lock);
> -
> - if (IS_ENABLED(CONFIG_LOCKDEP) && i915_gem_object_is_shrinkable(obj))
> - fs_reclaim_taints_mutex(&obj->mm.lock);
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index b5af9c440ac5..a0e1c4ff0de4 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -372,27 +372,10 @@ void __i915_gem_object_set_pages(struct 
> drm_i915_gem_object *obj,
>  int i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
>  int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
>  
> -enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
> - I915_MM_NORMAL = 0,
> - /*
> -  * Only used by struct_mutex, when called "recursively" from
> -  * direct-reclaim-esque. Safe because there is only every one
> -  * struct_mutex in the entire system.
> -  */
> - I915_MM_SHRINKER = 1,
> - /*
> -  * Used for obj->mm.lock when allocating pages. Safe because the object
> -  * isn't yet on any LRU, and therefore the shrinker can't deadlock on
> -  * it. As soon as the object has pages, obj->mm.lock nests within
> -  * fs_reclaim.
> -  */
> - I915_MM_GET_PAGES = 1,
> -};
> -
>  static inline int __must_check
>  i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
>  {
> - might_lock_nested(&obj->mm.lock, I915_MM_GET_PAGES);
> + might_lock(&obj->mm.lock);
>  
>   if (atomic_inc_not_zero(&obj->mm.pages_pin_count))
>   return 0;
> @@ -436,6 +419,7 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object 
> *obj)
>  }
>  
>  int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
> +int __i915_gem_object_put_pages_locked(struct drm_i915_gem_object *obj);
>  void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
>  void i915_gem_object_writeback(struct drm_i915_gem_object *obj);
>  
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index e7d7650072c5..e947d4c0da1f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -114,7 +114,7 @@ int __i915_gem_object_get_pages(struct 
> drm_i915_gem_object *obj)
>  {
>   int err;
>  
> - err = mutex_lock_interruptible_nested(&obj->mm.lock, I915_MM_GET_PAGES);
> + err = mutex_lock_interruptible(&obj->mm.lock);
>   if (err)
>   return err;
>  
> @@ -196,21 +196,13 @@ __i915_gem_object_unset_pages(struct 
> drm_i915_gem_object *obj)
>   return pages;
>  }
>  
> -int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
> +int __i915_gem_object_put_pages_locked(struct drm_i915_gem_object *obj)
>  {
>   struct sg_table *pages;
> - int err;
>  
>   if (i915_gem_object_has_pinne

Re: [PATCH v4 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver

On Mon, Feb 22, 2021 at 09:28:22PM +0800, Kevin Tang wrote:
> Adds dsi host controller support for the Unisoc's display subsystem.
> Adds dsi phy support for the Unisoc's display subsystem.
> Only MIPI DSI Displays supported, DP/TV/HMDI will be support
> in the feature.
> 
> v1:
>   - Remove dphy and dsi graph binding, merge the dphy driver into the dsi.
> 
> v2:
>   - Use drm_xxx to replace all DRM_XXX.
>   - Use kzalloc to replace devm_kzalloc for sprd_dsi structure init.
> 
> v4:
>   - Use drmm_helpers to allocate encoder.
>   - Move allocate encoder and connector to bind funtion.

You're missing your Signed-off-by

And there's a bunch of errors warnings and (important) checks reported
by checkpatch --strict that you should fix.

> ---
>  drivers/gpu/drm/sprd/Makefile  |7 +-
>  drivers/gpu/drm/sprd/dw_dsi_ctrl.c |  794 +
>  drivers/gpu/drm/sprd/dw_dsi_ctrl.h | 1475 
>  drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c |  157 +++
>  drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h |   26 +
>  drivers/gpu/drm/sprd/megacores_pll.c   |  317 +
>  drivers/gpu/drm/sprd/megacores_pll.h   |  146 +++
>  drivers/gpu/drm/sprd/sprd_drm.c|1 +
>  drivers/gpu/drm/sprd/sprd_drm.h|1 +
>  drivers/gpu/drm/sprd/sprd_dsi.c| 1132 ++
>  drivers/gpu/drm/sprd/sprd_dsi.h|  104 ++
>  11 files changed, 4158 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.c
>  create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.h
>  create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c
>  create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h
>  create mode 100644 drivers/gpu/drm/sprd/megacores_pll.c
>  create mode 100644 drivers/gpu/drm/sprd/megacores_pll.h
>  create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.c
>  create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.h
> 
> diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
> index 6c25bfa99..d49f4977b 100644
> --- a/drivers/gpu/drm/sprd/Makefile
> +++ b/drivers/gpu/drm/sprd/Makefile
> @@ -1,5 +1,8 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
>  obj-y := sprd_drm.o \
> - sprd_dpu.o
> -
> + sprd_dpu.o \
> + sprd_dsi.o \
> + dw_dsi_ctrl.o \
> + dw_dsi_ctrl_ppi.o \

So it's a designware IP? There's a driver for it already that seems
fairly similar:
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c

> + megacores_pll.o
> diff --git a/drivers/gpu/drm/sprd/dw_dsi_ctrl.c 
> b/drivers/gpu/drm/sprd/dw_dsi_ctrl.c
> new file mode 100644
> index 0..1034aba4a
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/dw_dsi_ctrl.c
> @@ -0,0 +1,794 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Unisoc Inc.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "dw_dsi_ctrl.h"
> +
> +/*
> + * Modify power status of DSI Host core
> + */
> +void dsi_power_enable(struct dsi_context *ctx, int enable)
> +{
> + struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
> +
> + writel(enable, ®->SOFT_RESET);
> +}
> +/*
> + * Enable/disable DPI video mode
> + */
> +void dsi_video_mode(struct dsi_context *ctx)
> +{
> + struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
> +
> + writel(0, ®->DSI_MODE_CFG);
> +}
> +/*
> + * Enable command mode (Generic interface)
> + */
> +void dsi_cmd_mode(struct dsi_context *ctx)
> +{
> + struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
> +
> + writel(1, ®->DSI_MODE_CFG);
> +}
> +
> +bool dsi_is_cmd_mode(struct dsi_context *ctx)
> +{
> + struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
> +
> + return readl(®->DSI_MODE_CFG);
> +}
> +/*
> + * Configure the read back virtual channel for the generic interface
> + */
> +void dsi_rx_vcid(struct dsi_context *ctx, u8 vc)
> +{
> + struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
> + union _0x1C virtual_channel_id;
> +
> + virtual_channel_id.val = readl(®->VIRTUAL_CHANNEL_ID);
> + virtual_channel_id.bits.gen_rx_vcid = vc;
> +
> + writel(virtual_channel_id.val, ®->VIRTUAL_CHANNEL_ID);
> +}
> +/*
> + * Write the DPI video virtual channel destination
> + */
> +void dsi_video_vcid(struct dsi_context *ctx, u8 vc)
> +{
> + struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
> + union _0x1C virtual_channel_id;
> +
> + virtual_channel_id.val = readl(®->VIRTUAL_CHANNEL_ID);
> + virtual_channel_id.bits.video_pkt_vcid = vc;
> +
> + writel(virtual_channel_id.val, ®->VIRTUAL_CHANNEL_ID);
> +}
> +/*
> + * Set DPI video mode type (burst/non-burst - with sync pulses or events)
> + */
> +void dsi_dpi_video_burst_mode(struct dsi_context *ctx, int mode)
> +{
> + struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
> + union _0x38 vid_mode_cfg;
> +
> + vid_mode_cfg.val = readl(®->VID_MODE_CFG);
> + vid_mode_cfg.bits.vid_mode_type = mode;
> +
> + writel(vid_mode_cfg.val, ®->VID_MODE_CFG);
> +}
> +/*
> + * Set DPI video color coding
> + */
> +void dsi_dpi_color_coding(

Re: [Intel-gfx] [PATCH v9 16/70] drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7.

On Tue, Mar 23, 2021 at 04:50:05PM +0100, Maarten Lankhorst wrote:
> Instead of doing what we do currently, which will never work with
> PROVE_LOCKING, do the same as AMD does, and something similar to
> relocation slowpath. When all locks are dropped, we acquire the
> pages for pinning. When the locks are taken, we transfer those
> pages in .get_pages() to the bo. As a final check before installing
> the fences, we ensure that the mmu notifier was not called; if it is,
> we return -EAGAIN to userspace to signal it has to start over.
> 
> Changes since v1:
> - Unbinding is done in submit_init only. submit_begin() removed.
> - MMU_NOTFIER -> MMU_NOTIFIER
> Changes since v2:
> - Make i915->mm.notifier a spinlock.
> Changes since v3:
> - Add WARN_ON if there are any page references left, should have been 0.
> - Return 0 on success in submit_init(), bug from spinlock conversion.
> - Release pvec outside of notifier_lock (Thomas).
> Changes since v4:
> - Mention why we're clearing eb->[i + 1].vma in the code. (Thomas)
> - Actually check all invalidations in eb_move_to_gpu. (Thomas)
> - Do not wait when process is exiting to fix gem_ctx_persistence.userptr.
> Changes since v5:
> - Clarify why check on PF_EXITING is (temporarily) required.
> Changes since v6:
> - Ensure userptr validity is checked in set_domain through a special path.
> 
> Signed-off-by: Maarten Lankhorst 
> Acked-by: Dave Airlie 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_domain.c|  18 +-
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 101 ++-
>  drivers/gpu/drm/i915/gem/i915_gem_object.h|  38 +-
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  10 +-
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c |   2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_userptr.c   | 796 ++
>  drivers/gpu/drm/i915/i915_drv.h   |   9 +-
>  drivers/gpu/drm/i915/i915_gem.c   |   5 +-
>  8 files changed, 395 insertions(+), 584 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index 2f4980bf742e..76cb9f5c66aa 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -468,14 +468,28 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
> *data,
>   if (!obj)
>   return -ENOENT;
>  
> + if (i915_gem_object_is_userptr(obj)) {
> + /*
> +  * Try to grab userptr pages, iris uses set_domain to check
> +  * userptr validity
> +  */
> + err = i915_gem_object_userptr_validate(obj);
> + if (!err)
> + err = i915_gem_object_wait(obj,
> +I915_WAIT_INTERRUPTIBLE |
> +I915_WAIT_PRIORITY |
> +(write_domain ? 
> I915_WAIT_ALL : 0),
> +MAX_SCHEDULE_TIMEOUT);
> + goto out;
> + }
> +
>   /*
>* Proxy objects do not control access to the backing storage, ergo
>* they cannot be used as a means to manipulate the cache domain
>* tracking for that backing storage. The proxy object is always
>* considered to be outside of any cache domain.
>*/
> - if (i915_gem_object_is_proxy(obj) &&
> - !i915_gem_object_is_userptr(obj)) {
> + if (i915_gem_object_is_proxy(obj)) {
>   err = -ENXIO;
>   goto out;
>   }
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 795c68fcc6ed..b5ca9eb53565 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -53,14 +53,16 @@ enum {
>  /* __EXEC_OBJECT_NO_RESERVE is BIT(31), defined in i915_vma.h */
>  #define __EXEC_OBJECT_HAS_PINBIT(30)
>  #define __EXEC_OBJECT_HAS_FENCE  BIT(29)
> -#define __EXEC_OBJECT_NEEDS_MAP  BIT(28)
> -#define __EXEC_OBJECT_NEEDS_BIAS BIT(27)
> -#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 27) /* all of the above + */
> +#define __EXEC_OBJECT_USERPTR_INIT   BIT(28)
> +#define __EXEC_OBJECT_NEEDS_MAP  BIT(27)
> +#define __EXEC_OBJECT_NEEDS_BIAS BIT(26)
> +#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 26) /* all of the above + */
>  #define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN | 
> __EXEC_OBJECT_HAS_FENCE)
>  
>  #define __EXEC_HAS_RELOC BIT(31)
>  #define __EXEC_ENGINE_PINNED BIT(30)
> -#define __EXEC_INTERNAL_FLAGS(~0u << 30)
> +#define __EXEC_USERPTR_USED  BIT(29)
> +#define __EXEC_INTERNAL_FLAGS(~0u << 29)
>  #define UPDATE   PIN_OFFSET_FIXED
>  
>  #define BATCH_OFFSET_BIAS (256*1024)
> @@ -871,6 +873,26 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
>   }
>  
>   eb_add_vma(eb, i, batch, vma);

Re: [Intel-gfx] [PATCH v9 16/70] drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7.



On 3/24/21 12:28 PM, Daniel Vetter wrote:

On Tue, Mar 23, 2021 at 04:50:05PM +0100, Maarten Lankhorst wrote:

Instead of doing what we do currently, which will never work with
PROVE_LOCKING, do the same as AMD does, and something similar to
relocation slowpath. When all locks are dropped, we acquire the
pages for pinning. When the locks are taken, we transfer those
pages in .get_pages() to the bo. As a final check before installing
the fences, we ensure that the mmu notifier was not called; if it is,
we return -EAGAIN to userspace to signal it has to start over.

Changes since v1:
- Unbinding is done in submit_init only. submit_begin() removed.
- MMU_NOTFIER -> MMU_NOTIFIER
Changes since v2:
- Make i915->mm.notifier a spinlock.
Changes since v3:
- Add WARN_ON if there are any page references left, should have been 0.
- Return 0 on success in submit_init(), bug from spinlock conversion.
- Release pvec outside of notifier_lock (Thomas).
Changes since v4:
- Mention why we're clearing eb->[i + 1].vma in the code. (Thomas)
- Actually check all invalidations in eb_move_to_gpu. (Thomas)
- Do not wait when process is exiting to fix gem_ctx_persistence.userptr.
Changes since v5:
- Clarify why check on PF_EXITING is (temporarily) required.
Changes since v6:
- Ensure userptr validity is checked in set_domain through a special path.

Signed-off-by: Maarten Lankhorst 
Acked-by: Dave Airlie 
---
  drivers/gpu/drm/i915/gem/i915_gem_domain.c|  18 +-
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 101 ++-
  drivers/gpu/drm/i915/gem/i915_gem_object.h|  38 +-
  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  10 +-
  drivers/gpu/drm/i915/gem/i915_gem_pages.c |   2 +-
  drivers/gpu/drm/i915/gem/i915_gem_userptr.c   | 796 ++
  drivers/gpu/drm/i915/i915_drv.h   |   9 +-
  drivers/gpu/drm/i915/i915_gem.c   |   5 +-
  8 files changed, 395 insertions(+), 584 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 2f4980bf742e..76cb9f5c66aa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -468,14 +468,28 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
if (!obj)
return -ENOENT;
  
+	if (i915_gem_object_is_userptr(obj)) {

+   /*
+* Try to grab userptr pages, iris uses set_domain to check
+* userptr validity
+*/
+   err = i915_gem_object_userptr_validate(obj);
+   if (!err)
+   err = i915_gem_object_wait(obj,
+  I915_WAIT_INTERRUPTIBLE |
+  I915_WAIT_PRIORITY |
+  (write_domain ? 
I915_WAIT_ALL : 0),
+  MAX_SCHEDULE_TIMEOUT);
+   goto out;
+   }
+
/*
 * Proxy objects do not control access to the backing storage, ergo
 * they cannot be used as a means to manipulate the cache domain
 * tracking for that backing storage. The proxy object is always
 * considered to be outside of any cache domain.
 */
-   if (i915_gem_object_is_proxy(obj) &&
-   !i915_gem_object_is_userptr(obj)) {
+   if (i915_gem_object_is_proxy(obj)) {
err = -ENXIO;
goto out;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 795c68fcc6ed..b5ca9eb53565 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -53,14 +53,16 @@ enum {
  /* __EXEC_OBJECT_NO_RESERVE is BIT(31), defined in i915_vma.h */
  #define __EXEC_OBJECT_HAS_PIN BIT(30)
  #define __EXEC_OBJECT_HAS_FENCE   BIT(29)
-#define __EXEC_OBJECT_NEEDS_MAPBIT(28)
-#define __EXEC_OBJECT_NEEDS_BIAS   BIT(27)
-#define __EXEC_OBJECT_INTERNAL_FLAGS   (~0u << 27) /* all of the above + */
+#define __EXEC_OBJECT_USERPTR_INIT BIT(28)
+#define __EXEC_OBJECT_NEEDS_MAPBIT(27)
+#define __EXEC_OBJECT_NEEDS_BIAS   BIT(26)
+#define __EXEC_OBJECT_INTERNAL_FLAGS   (~0u << 26) /* all of the above + */
  #define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN | 
__EXEC_OBJECT_HAS_FENCE)
  
  #define __EXEC_HAS_RELOC	BIT(31)

  #define __EXEC_ENGINE_PINNED  BIT(30)
-#define __EXEC_INTERNAL_FLAGS  (~0u << 30)
+#define __EXEC_USERPTR_USEDBIT(29)
+#define __EXEC_INTERNAL_FLAGS  (~0u << 29)
  #define UPDATEPIN_OFFSET_FIXED
  
  #define BATCH_OFFSET_BIAS (256*1024)

@@ -871,6 +873,26 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
}
  
  		eb_add_vma(eb, i, batch, vma);

+
+   if (i915_gem_object_is_userptr(vma->obj)) {
+   err = i915_gem_objec

Re: [Intel-gfx] [PATCH] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v2)




On 24/03/2021 09:52, Daniel Vetter wrote:

On Wed, Mar 24, 2021 at 09:28:58AM +, Tvrtko Ursulin wrote:


On 23/03/2021 17:51, Jason Ekstrand wrote:

This API is entirely unnecessary and I'd love to get rid of it.  If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed.  The justification given at the time
was that it would help GL drivers which are inherently single-timeline.
However, neither of our GL drivers actually wanted the feature.  i965
was already in maintenance mode at the time and iris uses syncobj for
everything.

Unfortunately, as much as I'd love to get rid of it, it is used by the
media driver so we can't do that.  We can, however, do the next-best
thing which is to embed a syncobj in the context and do exactly what
we'd expect from userspace internally.  This isn't an entirely identical
implementation because it's no longer atomic if userspace races with
itself by calling execbuffer2 twice simultaneously from different
threads.  It won't crash in that case; it just doesn't guarantee any
ordering between those two submits.

Moving SINGLE_TIMELINE to a syncobj emulation has a couple of technical
advantages beyond mere annoyance.  One is that intel_timeline is no
longer an api-visible object and can remain entirely an implementation
detail.  This may be advantageous as we make scheduler changes going
forward.  Second is that, together with deleting the CLONE_CONTEXT API,
we should now have a 1:1 mapping between intel_context and
intel_timeline which may help us reduce locking.


Much, much better commit message although I still fail to understand where
do you see implementation details leaking out. So for me this is still
something I'd like to get to the bottom of.

I would also mention the difference regarding fence context change.

And in general I would maintain this patch as part of a series which ends up
demonstrating the "mays" and "shoulds".


I disagree. The past few years we've merged way too much patches and
features without carefully answering the high level questions of
- do we really need to solve this problem
- and if so, are we really solving this problem in the right place

Now we're quite in a hole, and we're not going to get out of this hole if
we keep applying the same standards that got us here. Anything that does
not clearly and without reservation the above two questions with "yes"
needs to be removed or walled off, just so we can eventually see which
complexity we really need, and what is actually superflous.


I understand your general point but when I apply it to this specific 
patch, even if it is simple, it is neither removing the uapi or walling 
it off. So I see it as the usual review standard to ask to see what 
"mays" and "shoulds" actually get us in concrete terms.


I would be able to understand putting the uapi behind the "if gen > 12 
|| is_discrete EINVAL", or whatever, since it is fair game to deprecate 
for any new platform or say GuC submission.


Not doing simply that makes me worry there are still misunderstandings 
on what kind of problems were encountered with regards to 
intel_timeline, by work item this or work item that, and that there 
isn't still a confusion about what is the internal timeline object and 
what is the internal hwsp object. I feel there hasn't been full 
transparency on these technical issues which is why I think seeing the 
actual series which is supposed to build on top of this would be helpful.


I even worry that we still have a big disconnect on whether this flag is 
leaking any internal implementation details out to userspace. If the 
commit message was reworded without actual agreement that implementation 
details are not exposed we will continue disagreeing going forward, 
which is not a good start.


We exchanged so many emails on this but I don't feel we are getting 
anywhere so I really have no idea - obviously you will steamroll this in 
regardless so I don't think there is point to argue further.


Regards,

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

[PATCH v2 0/2] HDCP 2.2 DP errata

2021-03-24 Thread Anshuman Gupta

HDCP DP 2.2 errata is part of HDCP DP 2.3 specs
as well. 

Anshuman Gupta (2):
  drm/i915/hdcp: Add DP HDCP2.2 timeout to read entire msg
  drm/hdcp: DP HDCP2.2 errata LC_Send_L_Prime=16

 drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 45 ++--
 include/drm/drm_hdcp.h   |  5 ++-
 2 files changed, 36 insertions(+), 14 deletions(-)

-- 
2.26.2

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

[PATCH v2 1/2] drm/i915/hdcp: Add DP HDCP2.2 timeout to read entire msg

2021-03-24 Thread Anshuman Gupta

As documented in HDCP 2.2 DP Errata spec transmitter should abort the
authentication protocol in case transmitter has not received the
entire {AKE_Send_Cert, AKE_Send_H_prime, AKE_Send_Paring_Info} msg
within {110,7,5} miliseconds.

Adding above msg timeout values and aborting the HDCP authentication
in case it timedout to read entire msg.

https://www.digital-cp.com/sites/default/files/HDCP%202_2_DisplayPort_Errata_v3_0.pdf

v2:
- Removed redundant variable msg_can_timedout. [Ankit]

Cc: Ramalingam C 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 45 ++--
 include/drm/drm_hdcp.h   |  3 ++
 2 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 40c516e90193..8bad4b3d34dd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -294,37 +294,39 @@ struct hdcp2_dp_msg_data {
bool msg_detectable;
u32 timeout;
u32 timeout2; /* Added for non_paired situation */
+   /* Timeout to read entire msg */
+   u32 msg_read_timeout;
 };
 
 static const struct hdcp2_dp_msg_data hdcp2_dp_msg_data[] = {
-   { HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0 },
+   { HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0, 0},
{ HDCP_2_2_AKE_SEND_CERT, DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
- false, HDCP_2_2_CERT_TIMEOUT_MS, 0 },
+ false, HDCP_2_2_CERT_TIMEOUT_MS, 0, HDCP_2_2_DP_CERT_READ_TIMEOUT_MS},
{ HDCP_2_2_AKE_NO_STORED_KM, DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
- false, 0, 0 },
+ false, 0, 0, 0 },
{ HDCP_2_2_AKE_STORED_KM, DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
- false, 0, 0 },
+ false, 0, 0, 0 },
{ HDCP_2_2_AKE_SEND_HPRIME, DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
  true, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
- HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS },
+ HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS, 
HDCP_2_2_DP_HPRIME_READ_TIMEOUT_MS},
{ HDCP_2_2_AKE_SEND_PAIRING_INFO,
  DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, true,
- HDCP_2_2_PAIRING_TIMEOUT_MS, 0 },
-   { HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0 },
+ HDCP_2_2_PAIRING_TIMEOUT_MS, 0, HDCP_2_2_DP_PAIRING_READ_TIMEOUT_MS },
+   { HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0, 0 },
{ HDCP_2_2_LC_SEND_LPRIME, DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
- false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0 },
+ false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0, 0 },
{ HDCP_2_2_SKE_SEND_EKS, DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, false,
- 0, 0 },
+ 0, 0, 0 },
{ HDCP_2_2_REP_SEND_RECVID_LIST,
  DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
- HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0 },
+ HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0, 0 },
{ HDCP_2_2_REP_SEND_ACK, DP_HDCP_2_2_REP_SEND_ACK_OFFSET, false,
- 0, 0 },
+ 0, 0, 0 },
{ HDCP_2_2_REP_STREAM_MANAGE,
  DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
- 0, 0 },
+ 0, 0, 0},
{ HDCP_2_2_REP_STREAM_READY, DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
- false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0 },
+ false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0, 0 },
 /* local define to shovel this through the write_2_2 interface */
 #define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
{ HDCP_2_2_ERRATA_DP_STREAM_TYPE,
@@ -513,6 +515,8 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port 
*dig_port,
u8 *byte = buf;
ssize_t ret, bytes_to_recv, len;
const struct hdcp2_dp_msg_data *hdcp2_msg_data;
+   ktime_t msg_end;
+   bool msg_expired;
 
hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id);
if (!hdcp2_msg_data)
@@ -539,6 +543,11 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port 
*dig_port,
len = bytes_to_recv > DP_AUX_MAX_PAYLOAD_BYTES ?
  DP_AUX_MAX_PAYLOAD_BYTES : bytes_to_recv;
 
+   /* Entire msg read timeout since initiate of msg read */
+   if (bytes_to_recv == size - 1 && 
hdcp2_msg_data->msg_read_timeout > 0)
+   msg_end = ktime_add_ms(ktime_get_raw(),
+  
hdcp2_msg_data->msg_read_timeout);
+
ret = drm_dp_dpcd_read(&dig_port->dp.aux, offset,
   (void *)byte, len);
if (ret < 0) {
@@ -551,6 +560,16 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port 
*dig_port,
byte += ret;
offset += ret;
}
+
+   if (hdcp2_msg_data->msg_read_timeout > 0) {
+   msg_expired = ktime_after(ktime_get_raw(), msg_end);
+   if (msg_expired) {
+   drm_dbg_kms(&i915->drm, "msg_id %d, entire msg read 
timeout(mSec): %

[PATCH v2 2/2] drm/hdcp: DP HDCP2.2 errata LC_Send_L_Prime=16

2021-03-24 Thread Anshuman Gupta

Fix LC_Send_L_Prime message timeout to 16 as documented
in DP HDCP 2.2 errata page 3.

https://www.digital-cp.com/sites/default/files/HDCP%202_2_DisplayPort_Errata_v3_0.pdf

Cc: Ramalingam C 
Reviewed-by: Ankit Nautiyal 
Signed-off-by: Anshuman Gupta 
---
 include/drm/drm_hdcp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 2b165a0f434f..0be3228e 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -231,7 +231,7 @@ struct hdcp2_rep_stream_ready {
 #define HDCP_2_2_PAIRING_TIMEOUT_MS200
 #define HDCP_2_2_DP_PAIRING_READ_TIMEOUT_MS5
 #defineHDCP_2_2_HDMI_LPRIME_TIMEOUT_MS 20
-#define HDCP_2_2_DP_LPRIME_TIMEOUT_MS  7
+#define HDCP_2_2_DP_LPRIME_TIMEOUT_MS  16
 #define HDCP_2_2_RECVID_LIST_TIMEOUT_MS3000
 #define HDCP_2_2_STREAM_READY_TIMEOUT_MS   100
 
-- 
2.26.2

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

[PATCH] drm/i915: Pass ww ctx to pin_map, v2.

2021-03-24 Thread Maarten Lankhorst

This will allow us to explicitly pass the ww to pin_pages,
when it starts taking it.

This allows us to finally kill off the explicit passing of ww
by retrieving it from the obj.

Changes since v1:
- Rename 'ret' to ptr, fix error handling of return ptr.

Signed-off-by: Maarten Lankhorst 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  7 +++---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  1 +
 .../gpu/drm/i915/gem/i915_gem_object_blt.c|  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 24 +++
 .../drm/i915/gem/selftests/i915_gem_context.c |  8 ---
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  |  2 +-
 drivers/gpu/drm/i915/gt/gen7_renderclear.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_pm.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 ++--
 drivers/gpu/drm/i915/gt/intel_renderstate.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_ring.c  |  2 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_timeline.c  |  7 +++---
 drivers/gpu/drm/i915/gt/intel_timeline.h  |  3 ++-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   |  2 +-
 drivers/gpu/drm/i915/gt/mock_engine.c |  2 +-
 drivers/gpu/drm/i915/gt/selftest_lrc.c|  2 +-
 drivers/gpu/drm/i915/gt/selftest_rps.c| 10 
 .../gpu/drm/i915/gt/selftest_workarounds.c|  6 ++---
 drivers/gpu/drm/i915/gvt/cmd_parser.c |  4 ++--
 drivers/gpu/drm/i915/i915_perf.c  |  4 ++--
 drivers/gpu/drm/i915/selftests/igt_spinner.c  |  2 +-
 24 files changed, 62 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index dcfcae9c841b..73dd2a7673f5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1340,7 +1340,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
if (err)
goto err_pool;
 
-   cmd = i915_gem_object_pin_map(pool->obj, pool->type);
+   cmd = i915_gem_object_pin_map(pool->obj, &eb->ww, pool->type);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto err_pool;
@@ -2489,7 +2489,8 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
goto err_shadow;
}
 
-   pw->shadow_map = i915_gem_object_pin_map(shadow->obj, I915_MAP_WB);
+   pw->shadow_map = i915_gem_object_pin_map(shadow->obj, &eb->ww,
+I915_MAP_WB);
if (IS_ERR(pw->shadow_map)) {
err = PTR_ERR(pw->shadow_map);
goto err_trampoline;
@@ -2500,7 +2501,7 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
 
pw->batch_map = ERR_PTR(-ENODEV);
if (needs_clflush && i915_has_memcpy_from_wc())
-   pw->batch_map = i915_gem_object_pin_map(batch, I915_MAP_WC);
+   pw->batch_map = i915_gem_object_pin_map(batch, &eb->ww, 
I915_MAP_WC);
 
if (IS_ERR(pw->batch_map)) {
err = i915_gem_object_pin_pages(batch);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2561a2f1e54f..edac8ee3be9a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -439,7 +439,7 @@ vm_access(struct vm_area_struct *area, unsigned long addr,
goto out;
 
/* As this is primarily for debugging, let's focus on simplicity */
-   vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
+   vaddr = i915_gem_object_pin_map(obj, &ww, I915_MAP_FORCE_WC);
if (IS_ERR(vaddr)) {
err = PTR_ERR(vaddr);
goto out;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 1a8ec4035112..9bd9b47dcc8d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -450,6 +450,7 @@ void i915_gem_object_writeback(struct drm_i915_gem_object 
*obj);
  * ERR_PTR() on error.
  */
 void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
+  struct i915_gem_ww_ctx *ww,
   enum i915_map_type type);
 
 void *__must_check i915_gem_object_pin_map_unlocked(struct drm_i915_gem_object 
*obj,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
index df8e8c18c6c9..fae18622d2da 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
@@ -58,7 +58,7 @@ struct i915_vma *intel_emit_vma_fill_blt(struct intel_context 
*ce,
/* we pinned the pool, mark it as such */
intel_gt_buffer_pool_mark_used(pool);
 
-   cmd = i915_gem_obj

Re: [PATCH] drm/ttm: stop warning on TT shrinker failure

On Wed, Mar 24, 2021 at 11:19:13AM +0100, Thomas Hellström (Intel) wrote:
> 
> On 3/23/21 4:45 PM, Christian König wrote:
> > Am 23.03.21 um 16:13 schrieb Michal Hocko:
> > > On Tue 23-03-21 14:56:54, Christian König wrote:
> > > > Am 23.03.21 um 14:41 schrieb Michal Hocko:
> > > [...]
> > > > > Anyway, I am wondering whether the overall approach is
> > > > > sound. Why don't
> > > > > you simply use shmem as your backing storage from the
> > > > > beginning and pin
> > > > > those pages if they are used by the device?
> > > > Yeah, that is exactly what the Intel guys are doing for their
> > > > integrated
> > > > GPUs :)
> > > > 
> > > > Problem is for TTM I need to be able to handle dGPUs and those have all
> > > > kinds of funny allocation restrictions. In other words I need to
> > > > guarantee
> > > > that the allocated memory is coherent accessible to the GPU
> > > > without using
> > > > SWIOTLB.
> > > > 
> > > > The simple case is that the device can only do DMA32, but you also got
> > > > device which can only do 40bits or 48bits.
> > > > 
> > > > On top of that you also got AGP, CMA and stuff like CPU cache behavior
> > > > changes (write back vs. write through, vs. uncached).
> > > OK, so the underlying problem seems to be that gfp mask (thus
> > > mapping_gfp_mask) cannot really reflect your requirements, right?  Would
> > > it help if shmem would allow to provide an allocation callback to
> > > override alloc_page_vma which is used currently? I am pretty sure there
> > > will be more to handle but going through shmem for the whole life time
> > > is just so much easier to reason about than some tricks to abuse shmem
> > > just for the swapout path.
> > 
> > Well it's a start, but the pages can have special CPU cache settings. So
> > direct IO from/to them usually doesn't work as expected.
> > 
> > Additional to that for AGP and CMA I need to make sure that I give those
> > pages back to the relevant subsystems instead of just dropping the page
> > reference.
> > 
> > So I would need to block for the swapio to be completed.
> > 
> > Anyway I probably need to revert those patches for now since this isn't
> > working as we hoped it would.
> > 
> > Thanks for the explanation how stuff works here.
> 
> Another alternative here that I've tried before without being successful
> would perhaps be to drop shmem completely and, if it's a normal page (no dma
> or funny caching attributes) just use add_to_swap_cache()? If it's something
> else, try alloc a page with relevant gfp attributes, copy and
> add_to_swap_cache()? Or perhaps that doesn't work well from a shrinker
> either?

So before we toss everything and go an a great rewrite-the-world tour,
what if we just try to split up big objects. So for objects which are
bigger than e.g. 10mb

- move them to a special "under eviction" list
- keep a note how far we evicted thus far
- interleave allocating shmem pages, copying data and releasing the ttm
  backing store on a chunk basis (maybe 10mb or whatever, tuning tbh)

If that's not enough, occasionally break out of the shrinker entirely so
other parts of reclaim can reclaim the shmem stuff. But just releasing our
own pages as we go should help a lot 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] drm/ttm: stop warning on TT shrinker failure

2021-03-24 Thread Christian König


Am 24.03.21 um 12:55 schrieb Daniel Vetter:

On Wed, Mar 24, 2021 at 11:19:13AM +0100, Thomas Hellström (Intel) wrote:

On 3/23/21 4:45 PM, Christian König wrote:

Am 23.03.21 um 16:13 schrieb Michal Hocko:

On Tue 23-03-21 14:56:54, Christian König wrote:

Am 23.03.21 um 14:41 schrieb Michal Hocko:

[...]

Anyway, I am wondering whether the overall approach is
sound. Why don't
you simply use shmem as your backing storage from the
beginning and pin
those pages if they are used by the device?

Yeah, that is exactly what the Intel guys are doing for their
integrated
GPUs :)

Problem is for TTM I need to be able to handle dGPUs and those have all
kinds of funny allocation restrictions. In other words I need to
guarantee
that the allocated memory is coherent accessible to the GPU
without using
SWIOTLB.

The simple case is that the device can only do DMA32, but you also got
device which can only do 40bits or 48bits.

On top of that you also got AGP, CMA and stuff like CPU cache behavior
changes (write back vs. write through, vs. uncached).

OK, so the underlying problem seems to be that gfp mask (thus
mapping_gfp_mask) cannot really reflect your requirements, right?  Would
it help if shmem would allow to provide an allocation callback to
override alloc_page_vma which is used currently? I am pretty sure there
will be more to handle but going through shmem for the whole life time
is just so much easier to reason about than some tricks to abuse shmem
just for the swapout path.

Well it's a start, but the pages can have special CPU cache settings. So
direct IO from/to them usually doesn't work as expected.

Additional to that for AGP and CMA I need to make sure that I give those
pages back to the relevant subsystems instead of just dropping the page
reference.

So I would need to block for the swapio to be completed.

Anyway I probably need to revert those patches for now since this isn't
working as we hoped it would.

Thanks for the explanation how stuff works here.

Another alternative here that I've tried before without being successful
would perhaps be to drop shmem completely and, if it's a normal page (no dma
or funny caching attributes) just use add_to_swap_cache()? If it's something
else, try alloc a page with relevant gfp attributes, copy and
add_to_swap_cache()? Or perhaps that doesn't work well from a shrinker
either?

So before we toss everything and go an a great rewrite-the-world tour,
what if we just try to split up big objects. So for objects which are
bigger than e.g. 10mb

- move them to a special "under eviction" list
- keep a note how far we evicted thus far
- interleave allocating shmem pages, copying data and releasing the ttm
   backing store on a chunk basis (maybe 10mb or whatever, tuning tbh)

If that's not enough, occasionally break out of the shrinker entirely so
other parts of reclaim can reclaim the shmem stuff. But just releasing our
own pages as we go should help a lot I think.


Yeah, the later is exactly what I was currently prototyping.

I just didn't used a limit but rather a only partially evicted BOs list 
which is used when we fail to allocate a page.


For the 5.12 cycle I think we should just go back to a hard 50% limit 
for now and then resurrect this when we have solved the issues.


Christian.


-Daniel


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

Re: [PATCH] drm/ttm: stop warning on TT shrinker failure

On Wed, Mar 24, 2021 at 01:00:28PM +0100, Christian König wrote:
> Am 24.03.21 um 12:55 schrieb Daniel Vetter:
> > On Wed, Mar 24, 2021 at 11:19:13AM +0100, Thomas Hellström (Intel) wrote:
> > > On 3/23/21 4:45 PM, Christian König wrote:
> > > > Am 23.03.21 um 16:13 schrieb Michal Hocko:
> > > > > On Tue 23-03-21 14:56:54, Christian König wrote:
> > > > > > Am 23.03.21 um 14:41 schrieb Michal Hocko:
> > > > > [...]
> > > > > > > Anyway, I am wondering whether the overall approach is
> > > > > > > sound. Why don't
> > > > > > > you simply use shmem as your backing storage from the
> > > > > > > beginning and pin
> > > > > > > those pages if they are used by the device?
> > > > > > Yeah, that is exactly what the Intel guys are doing for their
> > > > > > integrated
> > > > > > GPUs :)
> > > > > > 
> > > > > > Problem is for TTM I need to be able to handle dGPUs and those have 
> > > > > > all
> > > > > > kinds of funny allocation restrictions. In other words I need to
> > > > > > guarantee
> > > > > > that the allocated memory is coherent accessible to the GPU
> > > > > > without using
> > > > > > SWIOTLB.
> > > > > > 
> > > > > > The simple case is that the device can only do DMA32, but you also 
> > > > > > got
> > > > > > device which can only do 40bits or 48bits.
> > > > > > 
> > > > > > On top of that you also got AGP, CMA and stuff like CPU cache 
> > > > > > behavior
> > > > > > changes (write back vs. write through, vs. uncached).
> > > > > OK, so the underlying problem seems to be that gfp mask (thus
> > > > > mapping_gfp_mask) cannot really reflect your requirements, right?  
> > > > > Would
> > > > > it help if shmem would allow to provide an allocation callback to
> > > > > override alloc_page_vma which is used currently? I am pretty sure 
> > > > > there
> > > > > will be more to handle but going through shmem for the whole life time
> > > > > is just so much easier to reason about than some tricks to abuse shmem
> > > > > just for the swapout path.
> > > > Well it's a start, but the pages can have special CPU cache settings. So
> > > > direct IO from/to them usually doesn't work as expected.
> > > > 
> > > > Additional to that for AGP and CMA I need to make sure that I give those
> > > > pages back to the relevant subsystems instead of just dropping the page
> > > > reference.
> > > > 
> > > > So I would need to block for the swapio to be completed.
> > > > 
> > > > Anyway I probably need to revert those patches for now since this isn't
> > > > working as we hoped it would.
> > > > 
> > > > Thanks for the explanation how stuff works here.
> > > Another alternative here that I've tried before without being successful
> > > would perhaps be to drop shmem completely and, if it's a normal page (no 
> > > dma
> > > or funny caching attributes) just use add_to_swap_cache()? If it's 
> > > something
> > > else, try alloc a page with relevant gfp attributes, copy and
> > > add_to_swap_cache()? Or perhaps that doesn't work well from a shrinker
> > > either?
> > So before we toss everything and go an a great rewrite-the-world tour,
> > what if we just try to split up big objects. So for objects which are
> > bigger than e.g. 10mb
> > 
> > - move them to a special "under eviction" list
> > - keep a note how far we evicted thus far
> > - interleave allocating shmem pages, copying data and releasing the ttm
> >backing store on a chunk basis (maybe 10mb or whatever, tuning tbh)
> > 
> > If that's not enough, occasionally break out of the shrinker entirely so
> > other parts of reclaim can reclaim the shmem stuff. But just releasing our
> > own pages as we go should help a lot I think.
> 
> Yeah, the later is exactly what I was currently prototyping.
> 
> I just didn't used a limit but rather a only partially evicted BOs list
> which is used when we fail to allocate a page.
> 
> For the 5.12 cycle I think we should just go back to a hard 50% limit for
> now and then resurrect this when we have solved the issues.

Can we do the 50% limit without tossing out all the code we've done thus
far? Just so this doesn't get too disruptive.
-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] drm/ttm: stop warning on TT shrinker failure

2021-03-24 Thread Christian König




Am 24.03.21 um 13:01 schrieb Daniel Vetter:

On Wed, Mar 24, 2021 at 01:00:28PM +0100, Christian König wrote:

Am 24.03.21 um 12:55 schrieb Daniel Vetter:

On Wed, Mar 24, 2021 at 11:19:13AM +0100, Thomas Hellström (Intel) wrote:

On 3/23/21 4:45 PM, Christian König wrote:

Am 23.03.21 um 16:13 schrieb Michal Hocko:

On Tue 23-03-21 14:56:54, Christian König wrote:

Am 23.03.21 um 14:41 schrieb Michal Hocko:

[...]

Anyway, I am wondering whether the overall approach is
sound. Why don't
you simply use shmem as your backing storage from the
beginning and pin
those pages if they are used by the device?

Yeah, that is exactly what the Intel guys are doing for their
integrated
GPUs :)

Problem is for TTM I need to be able to handle dGPUs and those have all
kinds of funny allocation restrictions. In other words I need to
guarantee
that the allocated memory is coherent accessible to the GPU
without using
SWIOTLB.

The simple case is that the device can only do DMA32, but you also got
device which can only do 40bits or 48bits.

On top of that you also got AGP, CMA and stuff like CPU cache behavior
changes (write back vs. write through, vs. uncached).

OK, so the underlying problem seems to be that gfp mask (thus
mapping_gfp_mask) cannot really reflect your requirements, right?  Would
it help if shmem would allow to provide an allocation callback to
override alloc_page_vma which is used currently? I am pretty sure there
will be more to handle but going through shmem for the whole life time
is just so much easier to reason about than some tricks to abuse shmem
just for the swapout path.

Well it's a start, but the pages can have special CPU cache settings. So
direct IO from/to them usually doesn't work as expected.

Additional to that for AGP and CMA I need to make sure that I give those
pages back to the relevant subsystems instead of just dropping the page
reference.

So I would need to block for the swapio to be completed.

Anyway I probably need to revert those patches for now since this isn't
working as we hoped it would.

Thanks for the explanation how stuff works here.

Another alternative here that I've tried before without being successful
would perhaps be to drop shmem completely and, if it's a normal page (no dma
or funny caching attributes) just use add_to_swap_cache()? If it's something
else, try alloc a page with relevant gfp attributes, copy and
add_to_swap_cache()? Or perhaps that doesn't work well from a shrinker
either?

So before we toss everything and go an a great rewrite-the-world tour,
what if we just try to split up big objects. So for objects which are
bigger than e.g. 10mb

- move them to a special "under eviction" list
- keep a note how far we evicted thus far
- interleave allocating shmem pages, copying data and releasing the ttm
backing store on a chunk basis (maybe 10mb or whatever, tuning tbh)

If that's not enough, occasionally break out of the shrinker entirely so
other parts of reclaim can reclaim the shmem stuff. But just releasing our
own pages as we go should help a lot I think.

Yeah, the later is exactly what I was currently prototyping.

I just didn't used a limit but rather a only partially evicted BOs list
which is used when we fail to allocate a page.

For the 5.12 cycle I think we should just go back to a hard 50% limit for
now and then resurrect this when we have solved the issues.

Can we do the 50% limit without tossing out all the code we've done thus
far? Just so this doesn't get too disruptive.


Yeah, I just need to get back to v1 of this patch. Before you convinced 
me that the shrinker is the better approach .)


Cheers,
Christian.


-Daniel


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

Re: [PATCH] drm/amdgpu: Ensure that the modifier requested is supported by plane.

2021-03-24 Thread Daniel Stone

On Wed, 24 Mar 2021 at 10:53, Bas Nieuwenhuizen 
wrote:

> On Wed, Mar 24, 2021 at 11:13 AM Michel Dänzer  wrote:
>
>> No modifier support does not imply linear. It's generally signalled via
>> DRM_FORMAT_MOD_INVALID, which roughly means "tiling is determined by driver
>> specific mechanisms".
>>
>
> Doesn't quite work that way in the kernel sadly. If you don't set
> DRM_MODE_FB_MODIFIERS then the modifier fields have to be 0 (which happens
> to alias DRM_FORMAT_MOD_LINEAR and then now deprecated
> DRM_FORMAT_MOD_NONE). This is verified in shared drm code.
>
> (and all userspace code I've seen simply doesn't set DRM_MODE_FB_MODIFIERS
> if the incoming modifier is DRM_FORMAT_MOD_INVALID)
>

Yes, but even though the field is zero, the lack of the flag means it must
be treated as INVALID. If the kernel is not doing this, the kernel is
objectively wrong. (And I know it doesn't do this in most cases, because
otherwise I wouldn't be able to use this GNOME session on an Intel laptop,
where modifiers are blacklisted.)

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

[PATCH v4 0/7] Default request/fence expiry + watchdog

From: Tvrtko Ursulin 

"Watchdog" aka "restoring hangcheck" aka default request/fence expiry - second
post of a somewhat controversial feature, now upgraded to patch status.

I quote the "watchdog" becuase in classical sense watchdog would allow userspace
to ping it and so remain alive.

I quote "restoring hangcheck" because this series, contrary to the old
hangcheck, is not looking at whether the workload is making any progress from
the kernel side either. (Although disclaimer my memory may be leaky - Daniel
suspects old hangcheck had some stricter, more indiscriminatory, angles to it.
But apart from being prone to both false negatives and false positives I can't
remember that myself.)

Short version - ask is to fail any user submissions after a set time period. In
this RFC that time is twelve seconds.

Time counts from the moment user submission is "runnable" (implicit and explicit
dependencies have been cleared) and keeps counting regardless of the GPU
contetion caused by other users of the system.

So semantics are really a bit weak, but again, I understand this is really
really wanted by the DRM core even if I am not convinced it is a good idea.

There are some dangers with doing this - text borrowed from a patch in the
series:

  This can have an effect that workloads which used to work fine will
  suddenly start failing. Even workloads comprised of short batches but in
  long dependency chains can be terminated.

  And becuase of lack of agreement on usefulness and safety of fence error
  propagation this partial execution can be invisible to userspace even if
  it is "listening" to returned fence status.

  Another interaction is with hangcheck where care needs to be taken timeout
  is not set lower or close to three times the heartbeat interval. Otherwise
  a hang in any application can cause complete termination of all
  submissions from unrelated clients. Any users modifying the per engine
  heartbeat intervals therefore need to be aware of this potential denial of
  service to avoid inadvertently enabling it.

  Given all this I am personally not convinced the scheme is a good idea.
  Intuitively it feels object importers would be better positioned to
  enforce the time they are willing to wait for something to complete.

v2:
 * Dropped context param.
 * Improved commit messages and Kconfig text.

v3:
 * Log timeouts.
 * Bump timeout to 20s to see if it helps Tigerlake.
 * Fix sentinel assert.

v4:
 * A round of review feedback applied.

Chris Wilson (1):
  drm/i915: Individual request cancellation

Tvrtko Ursulin (6):
  drm/i915: Extract active lookup engine to a helper
  drm/i915: Restrict sentinel requests further
  drm/i915: Handle async cancellation in sentinel assert
  drm/i915: Request watchdog infrastructure
  drm/i915: Fail too long user submissions by default
  drm/i915: Allow configuring default request expiry via modparam

 drivers/gpu/drm/i915/Kconfig.profile  |  14 ++
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  73 ---
 .../gpu/drm/i915/gem/i915_gem_context_types.h |   4 +
 drivers/gpu/drm/i915/gt/intel_context_param.h |  11 +-
 drivers/gpu/drm/i915/gt/intel_context_types.h |   4 +
 .../gpu/drm/i915/gt/intel_engine_heartbeat.c  |   1 +
 .../drm/i915/gt/intel_execlists_submission.c  |  23 +-
 .../drm/i915/gt/intel_execlists_submission.h  |   2 +
 drivers/gpu/drm/i915/gt/intel_gt.c|   3 +
 drivers/gpu/drm/i915/gt/intel_gt.h|   2 +
 drivers/gpu/drm/i915/gt/intel_gt_requests.c   |  28 +++
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |   7 +
 drivers/gpu/drm/i915/i915_params.c|   5 +
 drivers/gpu/drm/i915/i915_params.h|   1 +
 drivers/gpu/drm/i915/i915_request.c   | 129 ++-
 drivers/gpu/drm/i915/i915_request.h   |  16 +-
 drivers/gpu/drm/i915/selftests/i915_request.c | 201 ++
 17 files changed, 479 insertions(+), 45 deletions(-)

-- 
2.27.0

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

[PATCH 1/7] drm/i915: Extract active lookup engine to a helper

From: Tvrtko Ursulin 

Move active engine lookup to exported i915_request_active_engine.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 34 +---
 drivers/gpu/drm/i915/i915_request.c | 44 +
 drivers/gpu/drm/i915/i915_request.h |  4 ++
 3 files changed, 49 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ca37d93ef5e7..03a2f5f2a11f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -408,38 +408,6 @@ static bool __cancel_engine(struct intel_engine_cs *engine)
return intel_engine_pulse(engine) == 0;
 }
 
-static bool
-__active_engine(struct i915_request *rq, struct intel_engine_cs **active)
-{
-   struct intel_engine_cs *engine, *locked;
-   bool ret = false;
-
-   /*
-* Serialise with __i915_request_submit() so that it sees
-* is-banned?, or we know the request is already inflight.
-*
-* Note that rq->engine is unstable, and so we double
-* check that we have acquired the lock on the final engine.
-*/
-   locked = READ_ONCE(rq->engine);
-   spin_lock_irq(&locked->sched.lock);
-   while (unlikely(locked != (engine = READ_ONCE(rq->engine {
-   spin_unlock(&locked->sched.lock);
-   locked = engine;
-   spin_lock(&locked->sched.lock);
-   }
-
-   if (i915_request_is_active(rq)) {
-   if (!__i915_request_is_complete(rq))
-   *active = locked;
-   ret = true;
-   }
-
-   spin_unlock_irq(&locked->sched.lock);
-
-   return ret;
-}
-
 static struct intel_engine_cs *active_engine(struct intel_context *ce)
 {
struct intel_engine_cs *engine = NULL;
@@ -467,7 +435,7 @@ static struct intel_engine_cs *active_engine(struct 
intel_context *ce)
/* Check with the backend if the request is inflight */
found = true;
if (likely(rcu_access_pointer(rq->timeline) == ce->timeline))
-   found = __active_engine(rq, &engine);
+   found = i915_request_active_engine(rq, &engine);
 
i915_request_put(rq);
if (found)
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index e7b4c4bc41a6..8416b0bc4eb3 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -244,6 +244,50 @@ static void __i915_request_fill(struct i915_request *rq, 
u8 val)
memset(vaddr + head, val, rq->postfix - head);
 }
 
+/**
+ * i915_request_active_engine
+ * @rq: request to inspect
+ * @active: pointer in which to return the active engine
+ *
+ * Fills the currently active engine to the @active pointer if the request
+ * is active and still not completed.
+ *
+ * Returns true if request was active or false otherwise.
+ */
+bool
+i915_request_active_engine(struct i915_request *rq,
+  struct intel_engine_cs **active)
+{
+   struct intel_engine_cs *engine, *locked;
+   bool ret = false;
+
+   /*
+* Serialise with __i915_request_submit() so that it sees
+* is-banned?, or we know the request is already inflight.
+*
+* Note that rq->engine is unstable, and so we double
+* check that we have acquired the lock on the final engine.
+*/
+   locked = READ_ONCE(rq->engine);
+   spin_lock_irq(&locked->sched.lock);
+   while (unlikely(locked != (engine = READ_ONCE(rq->engine {
+   spin_unlock(&locked->sched.lock);
+   locked = engine;
+   spin_lock(&locked->sched.lock);
+   }
+
+   if (i915_request_is_active(rq)) {
+   if (!__i915_request_is_complete(rq))
+   *active = locked;
+   ret = true;
+   }
+
+   spin_unlock_irq(&locked->sched.lock);
+
+   return ret;
+}
+
+
 static void remove_from_engine(struct i915_request *rq)
 {
struct intel_engine_cs *engine, *locked;
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index dd10a6db3d21..f5374bab7e69 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -650,4 +650,8 @@ static inline bool i915_request_use_semaphores(const struct 
i915_request *rq)
return intel_engine_has_semaphores(rq->engine);
 }
 
+bool
+i915_request_active_engine(struct i915_request *rq,
+  struct intel_engine_cs **active);
+
 #endif /* I915_REQUEST_H */
-- 
2.27.0

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

[PATCH 2/7] drm/i915: Individual request cancellation

From: Chris Wilson 

Currently, we cancel outstanding requests within a context when the
context is closed. We may also want to cancel individual requests using
the same graceful preemption mechanism.

v2 (Tvrtko):
 * Cancel waiters carefully considering no timeline lock and RCU.
 * Fixed selftests.

v3 (Tvrtko):
 * Remove error propagation to waiters for now.

v4 (Tvrtko):
 * Rebase for extracted i915_request_active_engine. (Matt)

Signed-off-by: Chris Wilson 
Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Matthew Auld  # v3
---
 .../gpu/drm/i915/gt/intel_engine_heartbeat.c  |   1 +
 .../drm/i915/gt/intel_execlists_submission.c  |   9 +-
 drivers/gpu/drm/i915/i915_request.c   |  33 ++-
 drivers/gpu/drm/i915/i915_request.h   |   4 +-
 drivers/gpu/drm/i915/selftests/i915_request.c | 201 ++
 5 files changed, 242 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c 
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 0b062fad1837..e2fb3ae2aaf3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -314,6 +314,7 @@ int intel_engine_pulse(struct intel_engine_cs *engine)
mutex_unlock(&ce->timeline->mutex);
}
 
+   intel_engine_flush_scheduler(engine);
intel_engine_pm_put(engine);
return err;
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 85ff5fe861b4..4c2acb5a6c0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -421,6 +421,11 @@ static void reset_active(struct i915_request *rq,
ce->lrc.lrca = lrc_update_regs(ce, engine, head);
 }
 
+static bool bad_request(const struct i915_request *rq)
+{
+   return rq->fence.error && i915_request_started(rq);
+}
+
 static struct intel_engine_cs *
 __execlists_schedule_in(struct i915_request *rq)
 {
@@ -433,7 +438,7 @@ __execlists_schedule_in(struct i915_request *rq)
 !intel_engine_has_heartbeat(engine)))
intel_context_set_banned(ce);
 
-   if (unlikely(intel_context_is_banned(ce)))
+   if (unlikely(intel_context_is_banned(ce) || bad_request(rq)))
reset_active(rq, engine);
 
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
@@ -1112,7 +1117,7 @@ static unsigned long active_preempt_timeout(struct 
intel_engine_cs *engine,
return 0;
 
/* Force a fast reset for terminated contexts (ignoring sysfs!) */
-   if (unlikely(intel_context_is_banned(rq->context)))
+   if (unlikely(intel_context_is_banned(rq->context) || bad_request(rq)))
return 1;
 
return READ_ONCE(engine->props.preempt_timeout_ms);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 8416b0bc4eb3..d1a4a3fa7425 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -33,7 +33,10 @@
 #include "gem/i915_gem_context.h"
 #include "gt/intel_breadcrumbs.h"
 #include "gt/intel_context.h"
+#include "gt/intel_engine.h"
+#include "gt/intel_engine_heartbeat.h"
 #include "gt/intel_gpu_commands.h"
+#include "gt/intel_reset.h"
 #include "gt/intel_ring.h"
 #include "gt/intel_rps.h"
 
@@ -473,20 +476,22 @@ void __i915_request_skip(struct i915_request *rq)
rq->infix = rq->postfix;
 }
 
-void i915_request_set_error_once(struct i915_request *rq, int error)
+bool i915_request_set_error_once(struct i915_request *rq, int error)
 {
int old;
 
GEM_BUG_ON(!IS_ERR_VALUE((long)error));
 
if (i915_request_signaled(rq))
-   return;
+   return false;
 
old = READ_ONCE(rq->fence.error);
do {
if (fatal_error(old))
-   return;
+   return false;
} while (!try_cmpxchg(&rq->fence.error, &old, error));
+
+   return true;
 }
 
 struct i915_request *i915_request_mark_eio(struct i915_request *rq)
@@ -653,6 +658,28 @@ void i915_request_unsubmit(struct i915_request *request)
spin_unlock_irqrestore(&se->lock, flags);
 }
 
+static void __cancel_request(struct i915_request *rq)
+{
+   struct intel_engine_cs *engine = NULL;
+
+   i915_request_active_engine(rq, &engine);
+
+   if (engine && intel_engine_pulse(engine))
+   intel_gt_handle_error(engine->gt, engine->mask, 0,
+ "request cancellation by %s",
+ current->comm);
+}
+
+void i915_request_cancel(struct i915_request *rq, int error)
+{
+   if (!i915_request_set_error_once(rq, error))
+   return;
+
+   set_bit(I915_FENCE_FLAG_SENTINEL, &rq->fence.flags);
+
+   __cancel_request(rq);
+}
+
 static int __i915_sw_fence_call
 submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
 {
diff --gi

[PATCH 3/7] drm/i915: Restrict sentinel requests further

From: Tvrtko Ursulin 

Disallow sentinel requests follow previous sentinels to make request
cancellation work better when faced with a chain of requests which have
all been marked as in error.

Because in cases where we end up with a stream of cancelled requests we
want to turn of request coalescing so they each will get individually
skipped by the execlists_schedule_in (which is called per ELSP port, not
per request).

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 4c2acb5a6c0a..4b870eca9693 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -896,7 +896,7 @@ static bool can_merge_rq(const struct i915_request *prev,
if (__i915_request_is_complete(next))
return true;
 
-   if (unlikely((i915_request_flags(prev) ^ i915_request_flags(next)) &
+   if (unlikely((i915_request_flags(prev) | i915_request_flags(next)) &
 (BIT(I915_FENCE_FLAG_NOPREEMPT) |
  BIT(I915_FENCE_FLAG_SENTINEL
return false;
-- 
2.27.0

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

[PATCH 4/7] drm/i915: Handle async cancellation in sentinel assert

From: Tvrtko Ursulin 

With the watchdog cancelling requests asynchronously to preempt-to-busy we
need to relax one assert making it apply only to requests not in error.

v2:
 * Check against the correct request!

v3:
 * Simplify the check to avoid the question of when to sample the fence
   error vs sentinel bit.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 4b870eca9693..9d264d4ffa75 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -700,9 +700,8 @@ assert_pending_valid(const struct intel_engine_execlists 
*execlists,
 {
struct intel_engine_cs *engine =
container_of(execlists, typeof(*engine), execlists);
-   struct i915_request * const *port, *rq;
+   struct i915_request * const *port, *rq, *prev = NULL;
struct intel_context *ce = NULL;
-   bool sentinel = false;
u32 ccid = -1;
 
trace_ports(execlists, msg, execlists->pending);
@@ -752,15 +751,20 @@ assert_pending_valid(const struct intel_engine_execlists 
*execlists,
 * Sentinels are supposed to be the last request so they flush
 * the current execution off the HW. Check that they are the 
only
 * request in the pending submission.
+*
+* NB: Due to the async nature of preempt-to-busy and request
+* cancellation we need to handle the case where request
+* becomes a sentinel in parallel to CSB processing.
 */
-   if (sentinel) {
+   if (prev && i915_request_has_sentinel(prev) &&
+   !READ_ONCE(prev->fence.error)) {
GEM_TRACE_ERR("%s: context:%llx after sentinel in 
pending[%zd]\n",
  engine->name,
  ce->timeline->fence_context,
  port - execlists->pending);
return false;
}
-   sentinel = i915_request_has_sentinel(rq);
+   prev = rq;
 
/*
 * We want virtual requests to only be in the first slot so
-- 
2.27.0

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

[PATCH 7/7] drm/i915: Allow configuring default request expiry via modparam

From: Tvrtko Ursulin 

Module parameter is added (request_timeout_ms) to allow configuring the
default request/fence expiry.

Default value is inherited from CONFIG_DRM_I915_REQUEST_TIMEOUT.

Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +++--
 drivers/gpu/drm/i915/i915_params.c  | 5 +
 drivers/gpu/drm/i915/i915_params.h  | 1 +
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 33ff1a6a7724..0e8f0476e01f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -845,11 +845,12 @@ static void __set_default_fence_expiry(struct 
i915_gem_context *ctx)
struct drm_i915_private *i915 = ctx->i915;
int ret;
 
-   if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT))
+   if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) ||
+   !i915->params.request_timeout_ms)
return;
 
/* Default expiry for user fences. */
-   ret = __set_watchdog(ctx, CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000);
+   ret = __set_watchdog(ctx, i915->params.request_timeout_ms * 1000);
if (ret)
drm_notice(&i915->drm,
   "Failed to configure default fence expiry! (%d)",
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 6939634e56ed..0320878d96b0 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -197,6 +197,11 @@ i915_param_named_unsafe(fake_lmem_start, ulong, 0400,
"Fake LMEM start offset (default: 0)");
 #endif
 
+#if CONFIG_DRM_I915_REQUEST_TIMEOUT
+i915_param_named_unsafe(request_timeout_ms, uint, 0600,
+   "Default request/fence/batch buffer expiration 
timeout.");
+#endif
+
 static __always_inline void _print_param(struct drm_printer *p,
 const char *name,
 const char *type,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 48f47e44e848..34ebb0662547 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -72,6 +72,7 @@ struct drm_printer;
param(int, enable_dpcd_backlight, -1, 0600) \
param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \
param(unsigned long, fake_lmem_start, 0, 0400) \
+   param(unsigned int, request_timeout_ms, 
CONFIG_DRM_I915_REQUEST_TIMEOUT, 0600) \
/* leave bools at the end to not create holes */ \
param(bool, enable_hangcheck, true, 0600) \
param(bool, load_detect_test, false, 0600) \
-- 
2.27.0

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

[PATCH 5/7] drm/i915: Request watchdog infrastructure

From: Tvrtko Ursulin 

Prepares the plumbing for setting request/fence expiration time. All code
is put in place but is never activated due yet missing ability to actually
configure the timer.

Outline of the basic operation:

A timer is started when request is ready for execution. If the request
completes (retires) before the timer fires, timer is cancelled and nothing
further happens.

If the timer fires request is added to a lockless list and worker queued.
Purpose of this is twofold: a) It allows request cancellation from a more
friendly context and b) coalesces multiple expirations into a single event
of consuming the list.

Worker locklessly consumes the list of expired requests and cancels them
all using previous added i915_request_cancel().

Associated timeout value is stored in rq->context.watchdog.timeout_us.

v2:
 * Log expiration.

v3:
 * Include more information about user timeline in the log message.

v4:
 * Remove obsolete comment and fix formatting. (Matt)

Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gt/intel_context_types.h |  4 ++
 .../drm/i915/gt/intel_execlists_submission.h  |  2 +
 drivers/gpu/drm/i915/gt/intel_gt.c|  3 ++
 drivers/gpu/drm/i915/gt/intel_gt.h|  2 +
 drivers/gpu/drm/i915/gt/intel_gt_requests.c   | 28 ++
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |  7 +++
 drivers/gpu/drm/i915/i915_request.c   | 52 +++
 drivers/gpu/drm/i915/i915_request.h   |  8 +++
 8 files changed, 106 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0ea18c9e2aca..65a5730a4f5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -99,6 +99,10 @@ struct intel_context {
 #define CONTEXT_FORCE_SINGLE_SUBMISSION7
 #define CONTEXT_NOPREEMPT  8
 
+   struct {
+   u64 timeout_us;
+   } watchdog;
+
u32 *lrc_reg_state;
union {
struct {
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
index f7bd3fccfee8..4ca9b475e252 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
@@ -6,6 +6,7 @@
 #ifndef __INTEL_EXECLISTS_SUBMISSION_H__
 #define __INTEL_EXECLISTS_SUBMISSION_H__
 
+#include 
 #include 
 
 struct drm_printer;
@@ -13,6 +14,7 @@ struct drm_printer;
 struct i915_request;
 struct intel_context;
 struct intel_engine_cs;
+struct intel_gt;
 
 enum {
INTEL_CONTEXT_SCHEDULE_IN = 0,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index ca76f93bc03d..8d77dcbad059 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -31,6 +31,9 @@ void intel_gt_init_early(struct intel_gt *gt, struct 
drm_i915_private *i915)
INIT_LIST_HEAD(>->closed_vma);
spin_lock_init(>->closed_lock);
 
+   init_llist_head(>->watchdog.list);
+   INIT_WORK(>->watchdog.work, intel_gt_watchdog_work);
+
intel_gt_init_buffer_pool(gt);
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index a17bd8b3195f..7ec395cace69 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -78,4 +78,6 @@ static inline bool intel_gt_is_wedged(const struct intel_gt 
*gt)
 void intel_gt_info_print(const struct intel_gt_info *info,
 struct drm_printer *p);
 
+void intel_gt_watchdog_work(struct work_struct *work);
+
 #endif /* __INTEL_GT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c 
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index 36ec97f79174..fbfd19b2e5f2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -8,6 +8,7 @@
 #include "i915_drv.h" /* for_each_engine() */
 #include "i915_request.h"
 #include "intel_engine_heartbeat.h"
+#include "intel_execlists_submission.h"
 #include "intel_gt.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_requests.h"
@@ -242,4 +243,31 @@ void intel_gt_fini_requests(struct intel_gt *gt)
 {
/* Wait until the work is marked as finished before unloading! */
cancel_delayed_work_sync(>->requests.retire_work);
+
+   flush_work(>->watchdog.work);
+}
+
+void intel_gt_watchdog_work(struct work_struct *work)
+{
+   struct intel_gt *gt =
+   container_of(work, typeof(*gt), watchdog.work);
+   struct i915_request *rq, *rn;
+   struct llist_node *first;
+
+   first = llist_del_all(>->watchdog.list);
+   if (!first)
+   return;
+
+   llist_for_each_entry_safe(rq, rn, first, watchdog.link) {
+   if (!i915_request_completed(rq)) {
+   str

[PATCH 6/7] drm/i915: Fail too long user submissions by default

From: Tvrtko Ursulin 

A new Kconfig option CONFIG_DRM_I915_REQUEST_TIMEOUT is added, defaulting
to 20s, and this timeout is applied to all users contexts using the
previously added watchdog facility.

Result of this is that any user submission will simply fail after this
timeout, either causing a reset (for non-preemptable), or incomplete
results.

This can have an effect that workloads which used to work fine will
suddenly start failing. Even workloads comprised of short batches but in
long dependency chains can be terminated.

And because of lack of agreement on usefulness and safety of fence error
propagation this partial execution can be invisible to userspace even if
it is "listening" to returned fence status.

Another interaction is with hangcheck where care needs to be taken timeout
is not set lower or close to three times the heartbeat interval. Otherwise
a hang in any application can cause complete termination of all
submissions from unrelated clients. Any users modifying the per engine
heartbeat intervals therefore need to be aware of this potential denial of
service to avoid inadvertently enabling it.

Given all this I am personally not convinced the scheme is a good idea.
Intuitively it feels object importers would be better positioned to
enforce the time they are willing to wait for something to complete.

v2:
 * Improved commit message and Kconfig text.
 * Pull in some helper code from patch which got dropped.

v3:
 * Bump timeout to 20s to see if it helps Tigerlake.

Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
Acked-by: Matthew Auld 
---
 drivers/gpu/drm/i915/Kconfig.profile  | 14 +++
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 38 +++
 .../gpu/drm/i915/gem/i915_gem_context_types.h |  4 ++
 drivers/gpu/drm/i915/gt/intel_context_param.h | 11 +-
 4 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.profile 
b/drivers/gpu/drm/i915/Kconfig.profile
index 35bbe2b80596..39328567c200 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -1,3 +1,17 @@
+config DRM_I915_REQUEST_TIMEOUT
+   int "Default timeout for requests (ms)"
+   default 2 # milliseconds
+   help
+ Configures the default timeout after which any user submissions will
+ be forcefully terminated.
+
+ Beware setting this value lower, or close to heartbeat interval
+ rounded to whole seconds times three, in order to avoid allowing
+ misbehaving applications causing total rendering failure in unrelated
+ clients.
+
+ May be 0 to disable the timeout.
+
 config DRM_I915_FENCE_TIMEOUT
int "Timeout for unsignaled foreign fences (ms, jiffy granularity)"
default 1 # milliseconds
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 03a2f5f2a11f..33ff1a6a7724 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -233,6 +233,8 @@ static void intel_context_set_gem(struct intel_context *ce,
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
+
+   intel_context_set_watchdog_us(ce, ctx->watchdog.timeout_us);
 }
 
 static void __free_engines(struct i915_gem_engines *e, unsigned int count)
@@ -820,6 +822,40 @@ static void __assign_timeline(struct i915_gem_context *ctx,
context_apply_all(ctx, __apply_timeline, timeline);
 }
 
+static int __apply_watchdog(struct intel_context *ce, void *timeout_us)
+{
+   return intel_context_set_watchdog_us(ce, (uintptr_t)timeout_us);
+}
+
+static int
+__set_watchdog(struct i915_gem_context *ctx, unsigned long timeout_us)
+{
+   int ret;
+
+   ret = context_apply_all(ctx, __apply_watchdog,
+   (void *)(uintptr_t)timeout_us);
+   if (!ret)
+   ctx->watchdog.timeout_us = timeout_us;
+
+   return ret;
+}
+
+static void __set_default_fence_expiry(struct i915_gem_context *ctx)
+{
+   struct drm_i915_private *i915 = ctx->i915;
+   int ret;
+
+   if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT))
+   return;
+
+   /* Default expiry for user fences. */
+   ret = __set_watchdog(ctx, CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000);
+   if (ret)
+   drm_notice(&i915->drm,
+  "Failed to configure default fence expiry! (%d)",
+  ret);
+}
+
 static struct i915_gem_context *
 i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
 {
@@ -864,6 +900,8 @@ i915_gem_create_context(struct drm_i915_private *i915, 
unsigned int flags)
intel_timeline_put(timeline);
}
 
+   __set_default_fence_expiry(ctx);
+
trace_i915_context_create(ctx);
 
return ctx;
diff --git a/drivers/gpu/drm/i

[PATCH] [v2] drm/imx: imx-ldb: fix out of bounds array access warning

2021-03-24 Thread Arnd Bergmann

From: Arnd Bergmann 

When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:

drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array 
bounds of 'struct clk *[4]' [-Werror=array-bounds]

Add an error check before the index is used, which helps with the
warning, as well as any possible other error condition that may be
triggered at runtime.

The warning could be fixed by adding a Kconfig depedency on CONFIG_OF,
but Liu Ying points out that the driver may hit the out-of-bounds
problem at runtime anyway.

Signed-off-by: Arnd Bergmann 
---
v2: fix subject line
expand patch description
print mux number
check upper bound as well
---
 drivers/gpu/drm/imx/imx-ldb.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index dbfe39e2f7f6..40310327fa76 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -197,6 +197,12 @@ static void imx_ldb_encoder_enable(struct drm_encoder 
*encoder)
int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 
+   if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+   dev_warn(ldb->dev, "%s: invalid mux %d\n",
+__func__, ERR_PTR(mux));
+   return;
+   }
+
drm_panel_prepare(imx_ldb_ch->panel);
 
if (dual) {
@@ -255,6 +261,12 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder 
*encoder,
int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
u32 bus_format = imx_ldb_ch->bus_format;
 
+   if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+   dev_warn(ldb->dev, "%s: invalid mux %d\n",
+__func__, ERR_PTR(mux));
+   return;
+   }
+
if (mode->clock > 17) {
dev_warn(ldb->dev,
 "%s: mode exceeds 170 MHz pixel clock\n", __func__);
-- 
2.29.2

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

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Extract active lookup engine to a helper

2021-03-24 Thread Matthew Auld

On Wed, 24 Mar 2021 at 12:13, Tvrtko Ursulin
 wrote:
>
> From: Tvrtko Ursulin 
>
> Move active engine lookup to exported i915_request_active_engine.
>
> Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Matthew Auld 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages

On Wed, Mar 24, 2021 at 10:56:43AM +0100, Daniel Vetter wrote:
> On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel) wrote:
> > 
> > On 3/23/21 5:37 PM, Jason Gunthorpe wrote:
> > > On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel) wrote:
> > > 
> > > > > > @@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct 
> > > > > > vm_fault *vmf,
> > > > > > if ((pfn & (fault_page_size - 1)) != 0)
> > > > > > goto out_fallback;
> > > > > > +   /*
> > > > > > +* Huge entries must be special, that is marking them as devmap
> > > > > > +* with no backing device map range. If there is a backing
> > > > > > +* range, Don't insert a huge entry.
> > > > > > +* If this check turns out to be too much of a performance hit,
> > > > > > +* we can instead have drivers indicate whether they may have
> > > > > > +* backing device map ranges and if not, skip this lookup.
> > > > > > +*/
> > > > > I think we can do this statically:
> > > > > - if it's system memory we know there's no devmap for it, and we do 
> > > > > the
> > > > > trick to block gup_fast
> > > > Yes, that should work.
> > > > > - if it's iomem, we know gup_fast wont work anyway if don't set 
> > > > > PFN_DEV,
> > > > > so might as well not do that
> > > > I think gup_fast will unfortunately mistake a huge iomem page for an
> > > > ordinary page and try to access a non-existant struct page for it, 
> > > > unless we
> > > > do the devmap trick.
> > > > 
> > > > And the lookup would then be for the rare case where a driver would have
> > > > already registered a dev_pagemap for an iomem area which may also be 
> > > > mapped
> > > > through TTM (like the patch from Felix a couple of weeks ago). If a 
> > > > driver
> > > > can promise not to do that, then we can safely remove the lookup.
> > > Isn't the devmap PTE flag arch optional? Does this fall back to not
> > > using huge pages on arches that don't support it?
> > 
> > Good point. No, currently it's only conditioned on transhuge page support.
> > Need to condition it on also devmap support.
> > 
> > > 
> > > Also, I feel like this code to install "pte_special" huge pages does
> > > not belong in the drm subsystem..
> > 
> > I could add helpers in huge_memory.c:
> > 
> > vmf_insert_pfn_pmd_prot_special() and
> > vmf_insert_pfn_pud_prot_special()
> 
> The somewhat annoying thing is that we'd need an error code so we fall
> back to pte fault handling. That's at least my understanding of how
> pud/pmd fault handling works. Not sure how awkward that is going to be
> with the overall fault handling flow.
> 
> But aside from that I think this makes tons of sense.

Why should the driver be so specific?

vmf_insert_pfn_range_XXX()

And it will figure out the optimal way to build the page tables.

Driver should provide the largest physically contiguous range it can

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

Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages



On 3/24/21 1:24 PM, Jason Gunthorpe wrote:

On Wed, Mar 24, 2021 at 10:56:43AM +0100, Daniel Vetter wrote:

On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel) wrote:

On 3/23/21 5:37 PM, Jason Gunthorpe wrote:

On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel) wrote:


@@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault 
*vmf,
if ((pfn & (fault_page_size - 1)) != 0)
goto out_fallback;
+   /*
+* Huge entries must be special, that is marking them as devmap
+* with no backing device map range. If there is a backing
+* range, Don't insert a huge entry.
+* If this check turns out to be too much of a performance hit,
+* we can instead have drivers indicate whether they may have
+* backing device map ranges and if not, skip this lookup.
+*/

I think we can do this statically:
- if it's system memory we know there's no devmap for it, and we do the
 trick to block gup_fast

Yes, that should work.

- if it's iomem, we know gup_fast wont work anyway if don't set PFN_DEV,
 so might as well not do that

I think gup_fast will unfortunately mistake a huge iomem page for an
ordinary page and try to access a non-existant struct page for it, unless we
do the devmap trick.

And the lookup would then be for the rare case where a driver would have
already registered a dev_pagemap for an iomem area which may also be mapped
through TTM (like the patch from Felix a couple of weeks ago). If a driver
can promise not to do that, then we can safely remove the lookup.

Isn't the devmap PTE flag arch optional? Does this fall back to not
using huge pages on arches that don't support it?

Good point. No, currently it's only conditioned on transhuge page support.
Need to condition it on also devmap support.


Also, I feel like this code to install "pte_special" huge pages does
not belong in the drm subsystem..

I could add helpers in huge_memory.c:

vmf_insert_pfn_pmd_prot_special() and
vmf_insert_pfn_pud_prot_special()

The somewhat annoying thing is that we'd need an error code so we fall
back to pte fault handling. That's at least my understanding of how
pud/pmd fault handling works. Not sure how awkward that is going to be
with the overall fault handling flow.

But aside from that I think this makes tons of sense.

Why should the driver be so specific?

vmf_insert_pfn_range_XXX()

And it will figure out the optimal way to build the page tables.

Driver should provide the largest physically contiguous range it can


I figure that would probably work, but since the huge_fault() interface 
is already providing the size of the fault based on how the pagetable is 
currently populated I figure that would have to move a lot of that logic 
into that helper...


/Thomas




Jason

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

Re: [Intel-gfx] [PATCH v9 25/70] drm/i915: Take reservation lock around i915_vma_pin.

On Tue, Mar 23, 2021 at 04:50:14PM +0100, Maarten Lankhorst wrote:
> We previously complained when ww == NULL.
> 
> This function is now only used in selftests to pin an object,
> and ww locking is now fixed.
> 
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Thomas Hellström 
> ---
>  .../i915/gem/selftests/i915_gem_coherency.c   | 12 ---
>  drivers/gpu/drm/i915/i915_gem.c   |  6 +-
>  drivers/gpu/drm/i915/i915_vma.c   |  4 +---
>  drivers/gpu/drm/i915/i915_vma.h   | 20 +++
>  4 files changed, 26 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c 
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
> index b5dbf15570fc..3eec385d43bb 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
> @@ -218,15 +218,13 @@ static int gpu_set(struct context *ctx, unsigned long 
> offset, u32 v)
>   u32 *cs;
>   int err;
>  
> + vma = i915_gem_object_ggtt_pin(ctx->obj, NULL, 0, 0, 0);
> + if (IS_ERR(vma))
> + return PTR_ERR(vma);
> +
>   i915_gem_object_lock(ctx->obj, NULL);
>   i915_gem_object_set_to_gtt_domain(ctx->obj, false);

I have different context here because of

https://lore.kernel.org/intel-gfx/20210203090205.25818-8-ch...@chris-wilson.co.uk/

What's really worrying here is the silent (accidental maybe, commit
message doesn't explain anything) change to the argument of
set_to_gtt_domain(). I've decided to just go with what we have right now,
but please double-check this matches the old version you've had before
this landed in drm-tip. Since I haven't pushed out the branch I've pinged
you with the pastebin on irc for now.
-Daniel

>  
> - vma = i915_gem_object_ggtt_pin(ctx->obj, NULL, 0, 0, 0);
> - if (IS_ERR(vma)) {
> - err = PTR_ERR(vma);
> - goto out_unlock;
> - }
> -
>   rq = intel_engine_create_kernel_request(ctx->engine);
>   if (IS_ERR(rq)) {
>   err = PTR_ERR(rq);
> @@ -265,9 +263,7 @@ static int gpu_set(struct context *ctx, unsigned long 
> offset, u32 v)
>   i915_request_add(rq);
>  out_unpin:
>   i915_vma_unpin(vma);
> -out_unlock:
>   i915_gem_object_unlock(ctx->obj);
> -
>   return err;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 3dee4e31fb14..8373662e4b5f 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -920,7 +920,11 @@ i915_gem_object_ggtt_pin_ww(struct drm_i915_gem_object 
> *obj,
>   return ERR_PTR(ret);
>   }
>  
> - ret = i915_vma_pin_ww(vma, ww, size, alignment, flags | PIN_GLOBAL);
> + if (ww)
> + ret = i915_vma_pin_ww(vma, ww, size, alignment, flags | 
> PIN_GLOBAL);
> + else
> + ret = i915_vma_pin(vma, size, alignment, flags | PIN_GLOBAL);
> +
>   if (ret)
>   return ERR_PTR(ret);
>  
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 1ffda2aaa7a0..265e3a3079e2 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -863,9 +863,7 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct 
> i915_gem_ww_ctx *ww,
>   int err;
>  
>  #ifdef CONFIG_PROVE_LOCKING
> - if (debug_locks && lockdep_is_held(&vma->vm->i915->drm.struct_mutex))
> - WARN_ON(!ww);
> - if (debug_locks && ww && vma->resv)
> + if (debug_locks && !WARN_ON(!ww) && vma->resv)
>   assert_vma_held(vma);
>  #endif
>  
> diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
> index 6b48f5c42488..8df784a026d2 100644
> --- a/drivers/gpu/drm/i915/i915_vma.h
> +++ b/drivers/gpu/drm/i915/i915_vma.h
> @@ -246,10 +246,22 @@ i915_vma_pin_ww(struct i915_vma *vma, struct 
> i915_gem_ww_ctx *ww,
>  static inline int __must_check
>  i915_vma_pin(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
>  {
> -#ifdef CONFIG_LOCKDEP
> - WARN_ON_ONCE(vma->resv && dma_resv_held(vma->resv));
> -#endif
> - return i915_vma_pin_ww(vma, NULL, size, alignment, flags);
> + struct i915_gem_ww_ctx ww;
> + int err;
> +
> + i915_gem_ww_ctx_init(&ww, true);
> +retry:
> + err = i915_gem_object_lock(vma->obj, &ww);
> + if (!err)
> + err = i915_vma_pin_ww(vma, &ww, size, alignment, flags);
> + if (err == -EDEADLK) {
> + err = i915_gem_ww_ctx_backoff(&ww);
> + if (!err)
> + goto retry;
> + }
> + i915_gem_ww_ctx_fini(&ww);
> +
> + return err;
>  }
>  
>  int i915_ggtt_pin(struct i915_vma *vma, struct i915_gem_ww_ctx *ww,
> -- 
> 2.31.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corpo

Re: [Intel-gfx] [PATCH v9 27/70] drm/i915: Make __engine_unpark() compatible with ww locking.

On Tue, Mar 23, 2021 at 04:50:16PM +0100, Maarten Lankhorst wrote:
> Take the ww lock around engine_unpark. Because of the
> many many places where rpm is used, I chose the safest option
> and used a trylock to opportunistically take this lock for
> __engine_unpark.

Correct choice, runtime pm resume is on the critical path for dma-fence
(we might need to wake up the device for e.g. atomic modeset commits), so
definitely can't have a dma_resv_lock in here.
-Daniel

> 
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Thomas Hellström 
> ---
>  drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index 27d9d17b35cb..bddc5c98fb04 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -27,12 +27,16 @@ static void dbg_poison_ce(struct intel_context *ce)
>   int type = i915_coherent_map_type(ce->engine->i915);
>   void *map;
>  
> + if (!i915_gem_object_trylock(obj))
> + return;
> +
>   map = i915_gem_object_pin_map(obj, type);
>   if (!IS_ERR(map)) {
>   memset(map, CONTEXT_REDZONE, obj->base.size);
>   i915_gem_object_flush_map(obj);
>   i915_gem_object_unpin_map(obj);
>   }
> + i915_gem_object_unlock(obj);
>   }
>  }
>  
> -- 
> 2.31.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages

On Wed, Mar 24, 2021 at 01:35:17PM +0100, Thomas Hellström (Intel) wrote:
> 
> On 3/24/21 1:24 PM, Jason Gunthorpe wrote:
> > On Wed, Mar 24, 2021 at 10:56:43AM +0100, Daniel Vetter wrote:
> > > On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel) wrote:
> > > > On 3/23/21 5:37 PM, Jason Gunthorpe wrote:
> > > > > On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel) 
> > > > > wrote:
> > > > > 
> > > > > > > > @@ -210,6 +211,20 @@ static vm_fault_t 
> > > > > > > > ttm_bo_vm_insert_huge(struct vm_fault *vmf,
> > > > > > > > if ((pfn & (fault_page_size - 1)) != 0)
> > > > > > > > goto out_fallback;
> > > > > > > > +   /*
> > > > > > > > +* Huge entries must be special, that is marking them 
> > > > > > > > as devmap
> > > > > > > > +* with no backing device map range. If there is a 
> > > > > > > > backing
> > > > > > > > +* range, Don't insert a huge entry.
> > > > > > > > +* If this check turns out to be too much of a 
> > > > > > > > performance hit,
> > > > > > > > +* we can instead have drivers indicate whether they 
> > > > > > > > may have
> > > > > > > > +* backing device map ranges and if not, skip this 
> > > > > > > > lookup.
> > > > > > > > +*/
> > > > > > > I think we can do this statically:
> > > > > > > - if it's system memory we know there's no devmap for it, and we 
> > > > > > > do the
> > > > > > >  trick to block gup_fast
> > > > > > Yes, that should work.
> > > > > > > - if it's iomem, we know gup_fast wont work anyway if don't set 
> > > > > > > PFN_DEV,
> > > > > > >  so might as well not do that
> > > > > > I think gup_fast will unfortunately mistake a huge iomem page for an
> > > > > > ordinary page and try to access a non-existant struct page for it, 
> > > > > > unless we
> > > > > > do the devmap trick.
> > > > > > 
> > > > > > And the lookup would then be for the rare case where a driver would 
> > > > > > have
> > > > > > already registered a dev_pagemap for an iomem area which may also 
> > > > > > be mapped
> > > > > > through TTM (like the patch from Felix a couple of weeks ago). If a 
> > > > > > driver
> > > > > > can promise not to do that, then we can safely remove the lookup.
> > > > > Isn't the devmap PTE flag arch optional? Does this fall back to not
> > > > > using huge pages on arches that don't support it?
> > > > Good point. No, currently it's only conditioned on transhuge page 
> > > > support.
> > > > Need to condition it on also devmap support.
> > > > 
> > > > > Also, I feel like this code to install "pte_special" huge pages does
> > > > > not belong in the drm subsystem..
> > > > I could add helpers in huge_memory.c:
> > > > 
> > > > vmf_insert_pfn_pmd_prot_special() and
> > > > vmf_insert_pfn_pud_prot_special()
> > > The somewhat annoying thing is that we'd need an error code so we fall
> > > back to pte fault handling. That's at least my understanding of how
> > > pud/pmd fault handling works. Not sure how awkward that is going to be
> > > with the overall fault handling flow.
> > > 
> > > But aside from that I think this makes tons of sense.
> > Why should the driver be so specific?
> > 
> > vmf_insert_pfn_range_XXX()
> > 
> > And it will figure out the optimal way to build the page tables.
> > 
> > Driver should provide the largest physically contiguous range it can
> 
> I figure that would probably work, but since the huge_fault() interface is
> already providing the size of the fault based on how the pagetable is
> currently populated I figure that would have to move a lot of that logic
> into that helper...

But we don't really care about the size of the fault when we stuff the
pfns.

The device might use it when handling the fault, but once the fault is
handled the device knows what the contiguous pfn range is that it has
available to stuff into the page tables, it just tells the vmf_insert
what it was able to create, and it creates the necessary page table
structure.

The size of the hole in the page table is really only advisory, the
device may not want to make a 2M or 1G page entry and may prefer to
only create 4k.

In an ideal world the creation/destruction of page table levels would
by dynamic at this point, like THP.

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

Re: [PATCH 3/3] mm: unexport follow_pfn

On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
> follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
> follow_pte()")) have lost their callsites of follow_pfn(). All the
> other ones have been switched over to unsafe_follow_pfn because they
> cannot be fixed without breaking userspace api.
> 
> Argueably the vfio code is still racy, but that's kinda a bigger
> picture. But since it does leak the pte beyond where it drops the pt
> lock, without anything else like an mmu notifier guaranteeing
> coherence, the problem is at least clearly visible in the vfio code.
> So good enough with me.
> 
> I've decided to keep the explanation that after dropping the pt lock
> you must have an mmu notifier if you keep using the pte somehow by
> adjusting it and moving it into the kerneldoc for the new follow_pte()
> function.
> 
> Cc: 3...@google.com
> Cc: Jann Horn 
> Cc: Paolo Bonzini 
> Cc: Jason Gunthorpe 
> Cc: Cornelia Huck 
> Cc: Peter Xu 
> Cc: Alex Williamson 
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: k...@vger.kernel.org
> Signed-off-by: Daniel Vetter 
> ---
>  include/linux/mm.h |  2 --
>  mm/memory.c| 26 +-
>  mm/nommu.c | 13 +
>  3 files changed, 6 insertions(+), 35 deletions(-)

I think this is the right thing to do.

Alex is working on fixing VFIO and while kvm is still racy using
follow pte, I think they are working on it too?

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

Re: [PATCH] amdgpu: fix gcc -Wrestrict warning

2021-03-24 Thread Arnd Bergmann

On Tue, Mar 23, 2021 at 4:57 PM Rasmus Villemoes
 wrote:
> On 23/03/2021 14.04, Arnd Bergmann wrote:
> >   if (securedisplay_cmd->status == 
> > TA_SECUREDISPLAY_STATUS__SUCCESS) {
> > + int pos = 0;
> >   memset(i2c_output,  0, sizeof(i2c_output));
> >   for (i = 0; i < 
> > TA_SECUREDISPLAY_I2C_BUFFER_SIZE; i++)
> > - sprintf(i2c_output, "%s 0x%X", 
> > i2c_output,
> > + pos += sprintf(i2c_output + pos, " 
> > 0x%X",
> >   
> > securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf[i]);
> >   dev_info(adev->dev, "SECUREDISPLAY: I2C 
> > buffer out put is :%s\n", i2c_output);
>
> Eh, why not get rid of the 256 byte stack allocation and just replace
> all of this by
>
>   dev_info(adev->dev, ""SECUREDISPLAY: I2C buffer out put is: %*ph\n",
> TA_SECUREDISPLAY_I2C_BUFFER_SIZE,
> securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf);
>
> That's much less code (both in #LOC and .text), and avoids adding yet
> another place that will be audited over and over for "hm, yeah, that
> sprintf() is actually not gonna overflow".
>
> Yeah, it'll lose the 0x prefixes for each byte and use lowercase hex chars.

Ah, I didn't know the kernel's sprintf could do that, that's really nice.

I'll send a follow-up patch, as Alex has already applied the first one.

Alex, feel free to merge the two into one, or just keep as they are.

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

Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages



On 3/24/21 1:41 PM, Jason Gunthorpe wrote:

On Wed, Mar 24, 2021 at 01:35:17PM +0100, Thomas Hellström (Intel) wrote:

On 3/24/21 1:24 PM, Jason Gunthorpe wrote:

On Wed, Mar 24, 2021 at 10:56:43AM +0100, Daniel Vetter wrote:

On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel) wrote:

On 3/23/21 5:37 PM, Jason Gunthorpe wrote:

On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel) wrote:


@@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault 
*vmf,
if ((pfn & (fault_page_size - 1)) != 0)
goto out_fallback;
+   /*
+* Huge entries must be special, that is marking them as devmap
+* with no backing device map range. If there is a backing
+* range, Don't insert a huge entry.
+* If this check turns out to be too much of a performance hit,
+* we can instead have drivers indicate whether they may have
+* backing device map ranges and if not, skip this lookup.
+*/

I think we can do this statically:
- if it's system memory we know there's no devmap for it, and we do the
  trick to block gup_fast

Yes, that should work.

- if it's iomem, we know gup_fast wont work anyway if don't set PFN_DEV,
  so might as well not do that

I think gup_fast will unfortunately mistake a huge iomem page for an
ordinary page and try to access a non-existant struct page for it, unless we
do the devmap trick.

And the lookup would then be for the rare case where a driver would have
already registered a dev_pagemap for an iomem area which may also be mapped
through TTM (like the patch from Felix a couple of weeks ago). If a driver
can promise not to do that, then we can safely remove the lookup.

Isn't the devmap PTE flag arch optional? Does this fall back to not
using huge pages on arches that don't support it?

Good point. No, currently it's only conditioned on transhuge page support.
Need to condition it on also devmap support.


Also, I feel like this code to install "pte_special" huge pages does
not belong in the drm subsystem..

I could add helpers in huge_memory.c:

vmf_insert_pfn_pmd_prot_special() and
vmf_insert_pfn_pud_prot_special()

The somewhat annoying thing is that we'd need an error code so we fall
back to pte fault handling. That's at least my understanding of how
pud/pmd fault handling works. Not sure how awkward that is going to be
with the overall fault handling flow.

But aside from that I think this makes tons of sense.

Why should the driver be so specific?

vmf_insert_pfn_range_XXX()

And it will figure out the optimal way to build the page tables.

Driver should provide the largest physically contiguous range it can

I figure that would probably work, but since the huge_fault() interface is
already providing the size of the fault based on how the pagetable is
currently populated I figure that would have to move a lot of that logic
into that helper...

But we don't really care about the size of the fault when we stuff the
pfns.

The device might use it when handling the fault, but once the fault is
handled the device knows what the contiguous pfn range is that it has
available to stuff into the page tables, it just tells the vmf_insert
what it was able to create, and it creates the necessary page table
structure.

The size of the hole in the page table is really only advisory, the
device may not want to make a 2M or 1G page entry and may prefer to
only create 4k.

In an ideal world the creation/destruction of page table levels would
by dynamic at this point, like THP.


Hmm, but I'm not sure what problem we're trying to solve by changing the 
interface in this way?


Currently if the core vm requests a huge pud, we give it one, and if we 
can't or don't want to (because of dirty-tracking, for example, which is 
always done on 4K page-level) we just return VM_FAULT_FALLBACK, and the 
fault is retried at a lower level. Also, determining whether we have a 
contigous range is not free, so we  don't want to do that unnecessarily.


/Thomas


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

[PATCH] amdgpu: securedisplay: simplify i2c hexdump output

2021-03-24 Thread Arnd Bergmann

From: Arnd Bergmann 

A previous fix I did left a rather complicated loop in
amdgpu_securedisplay_debugfs_write() for what could be expressed in a
simple sprintf, as Rasmus pointed out.

This drops the leading 0x for each byte, but is otherwise
much nicer.

Suggested-by: Rasmus Villemoes 
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
index 69d7f6bff5d4..fc3ddd7aa6f0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
@@ -92,9 +92,7 @@ static ssize_t amdgpu_securedisplay_debugfs_write(struct file 
*f, const char __u
struct drm_device *dev = adev_to_drm(adev);
uint32_t phy_id;
uint32_t op;
-   int i;
char str[64];
-   char i2c_output[256];
int ret;
 
if (*pos || size > sizeof(str) - 1)
@@ -136,12 +134,9 @@ static ssize_t amdgpu_securedisplay_debugfs_write(struct 
file *f, const char __u
ret = psp_securedisplay_invoke(psp, 
TA_SECUREDISPLAY_COMMAND__SEND_ROI_CRC);
if (!ret) {
if (securedisplay_cmd->status == 
TA_SECUREDISPLAY_STATUS__SUCCESS) {
-   int pos = 0;
-   memset(i2c_output,  0, sizeof(i2c_output));
-   for (i = 0; i < 
TA_SECUREDISPLAY_I2C_BUFFER_SIZE; i++)
-   pos += sprintf(i2c_output + pos, " 
0x%X",
-   
securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf[i]);
-   dev_info(adev->dev, "SECUREDISPLAY: I2C buffer 
out put is :%s\n", i2c_output);
+   dev_info(adev->dev, "SECUREDISPLAY: I2C buffer 
out put is: %*ph\n",
+TA_SECUREDISPLAY_I2C_BUFFER_SIZE,
+
securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf);
} else {
psp_securedisplay_parse_resp_status(psp, 
securedisplay_cmd->status);
}
-- 
2.29.2

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

Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages

On Wed, Mar 24, 2021 at 02:35:38PM +0100, Thomas Hellström (Intel) wrote:

> > In an ideal world the creation/destruction of page table levels would
> > by dynamic at this point, like THP.
> 
> Hmm, but I'm not sure what problem we're trying to solve by changing the
> interface in this way?

We are trying to make a sensible driver API to deal with huge pages.

> Currently if the core vm requests a huge pud, we give it one, and if we
> can't or don't want to (because of dirty-tracking, for example, which is
> always done on 4K page-level) we just return VM_FAULT_FALLBACK, and the
> fault is retried at a lower level.

Well, my thought would be to move the pte related stuff into
vmf_insert_range instead of recursing back via VM_FAULT_FALLBACK.

I don't know if the locking works out, but it feels cleaner that the
driver tells the vmf how big a page it can stuff in, not the vm
telling the driver to stuff in a certain size page which it might not
want to do.

Some devices want to work on a in-between page size like 64k so they
can't form 2M pages but they can stuff 64k of 4K pages in a batch on
every fault.

That idea doesn't fit naturally if the VM is driving the size.

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

[PATCH] drm/ttm: switch back to static allocation limits for now

2021-03-24 Thread Christian König

The shrinker based approach still has some flaws. Especially that we need
temporary pages to free up the pages allocated to the driver is problematic
in a shrinker.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_device.c |  14 ++--
 drivers/gpu/drm/ttm/ttm_tt.c | 112 ---
 include/drm/ttm/ttm_tt.h |   3 +-
 3 files changed, 53 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 95e1b7b1f2e6..388da2a7f0bb 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -53,7 +53,6 @@ static void ttm_global_release(void)
goto out;
 
ttm_pool_mgr_fini();
-   ttm_tt_mgr_fini();
 
__free_page(glob->dummy_read_page);
memset(glob, 0, sizeof(*glob));
@@ -64,7 +63,7 @@ static void ttm_global_release(void)
 static int ttm_global_init(void)
 {
struct ttm_global *glob = &ttm_glob;
-   unsigned long num_pages;
+   unsigned long num_pages, num_dma32;
struct sysinfo si;
int ret = 0;
unsigned i;
@@ -79,8 +78,15 @@ static int ttm_global_init(void)
 * system memory.
 */
num_pages = ((u64)si.totalram * si.mem_unit) >> PAGE_SHIFT;
-   ttm_pool_mgr_init(num_pages * 50 / 100);
-   ttm_tt_mgr_init();
+   num_pages /= 2;
+
+   /* But for DMA32 we limit ourself to only use 2GiB maximum. */
+   num_dma32 = (u64)(si.totalram - si.totalhigh) * si.mem_unit
+   >> PAGE_SHIFT;
+   num_dma32 = min(num_dma32, 2UL << (30 - PAGE_SHIFT));
+
+   ttm_pool_mgr_init(num_pages);
+   ttm_tt_mgr_init(num_pages, num_dma32);
 
spin_lock_init(&glob->lru_lock);
glob->dummy_read_page = alloc_page(__GFP_ZERO | GFP_DMA32);
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2f0833c98d2c..5d8820725b75 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -40,8 +40,18 @@
 
 #include "ttm_module.h"
 
-static struct shrinker mm_shrinker;
-static atomic_long_t swapable_pages;
+static unsigned long ttm_pages_limit;
+
+MODULE_PARM_DESC(pages_limit, "Limit for the allocated pages");
+module_param_named(pages_limit, ttm_pages_limit, ulong, 0644);
+
+static unsigned long ttm_dma32_pages_limit;
+
+MODULE_PARM_DESC(dma32_pages_limit, "Limit for the allocated DMA32 pages");
+module_param_named(dma32_pages_limit, ttm_dma32_pages_limit, ulong, 0644);
+
+static atomic_long_t ttm_pages_allocated;
+static atomic_long_t ttm_dma32_pages_allocated;
 
 /*
  * Allocates a ttm structure for the given BO.
@@ -294,8 +304,6 @@ static void ttm_tt_add_mapping(struct ttm_device *bdev, 
struct ttm_tt *ttm)
 
for (i = 0; i < ttm->num_pages; ++i)
ttm->pages[i]->mapping = bdev->dev_mapping;
-
-   atomic_long_add(ttm->num_pages, &swapable_pages);
 }
 
 int ttm_tt_populate(struct ttm_device *bdev,
@@ -309,12 +317,25 @@ int ttm_tt_populate(struct ttm_device *bdev,
if (ttm_tt_is_populated(ttm))
return 0;
 
+   atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
+   if (bdev->pool.use_dma32)
+   atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
+
+   while (atomic_long_read(&ttm_pages_allocated) > ttm_pages_limit ||
+  atomic_long_read(&ttm_dma32_pages_allocated) >
+  ttm_dma32_pages_limit) {
+
+   ret = ttm_bo_swapout(ctx, GFP_KERNEL);
+   if (ret)
+   goto error;
+   }
+
if (bdev->funcs->ttm_tt_populate)
ret = bdev->funcs->ttm_tt_populate(bdev, ttm, ctx);
else
ret = ttm_pool_alloc(&bdev->pool, ttm, ctx);
if (ret)
-   return ret;
+   goto error;
 
ttm_tt_add_mapping(bdev, ttm);
ttm->page_flags |= TTM_PAGE_FLAG_PRIV_POPULATED;
@@ -327,6 +348,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
}
 
return 0;
+
+error:
+   atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+   if (bdev->pool.use_dma32)
+   atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+   return ret;
 }
 EXPORT_SYMBOL(ttm_tt_populate);
 
@@ -342,12 +369,9 @@ static void ttm_tt_clear_mapping(struct ttm_tt *ttm)
(*page)->mapping = NULL;
(*page++)->index = 0;
}
-
-   atomic_long_sub(ttm->num_pages, &swapable_pages);
 }
 
-void ttm_tt_unpopulate(struct ttm_device *bdev,
-  struct ttm_tt *ttm)
+void ttm_tt_unpopulate(struct ttm_device *bdev, struct ttm_tt *ttm)
 {
if (!ttm_tt_is_populated(ttm))
return;
@@ -357,76 +381,24 @@ void ttm_tt_unpopulate(struct ttm_device *bdev,
bdev->funcs->ttm_tt_unpopulate(bdev, ttm);
else
ttm_pool_free(&bdev->pool, ttm);
-   ttm->page_flags &= ~TTM_PAGE_FLAG_PRIV_POPULATED;
-}
-
-/* As long as pages are avai

[PATCH] drm/radeon/r600_cs: Couple of typo fixes

2021-03-24 Thread Bhaskar Chowdhury



s/miror/mirror/
s/needind/needing/

Signed-off-by: Bhaskar Chowdhury 
---
 drivers/gpu/drm/radeon/r600_cs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 34b7c6f16479..aded1f2264e0 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -38,7 +38,7 @@ extern void r600_cs_legacy_get_tiling_conf(struct drm_device 
*dev, u32 *npipes,


 struct r600_cs_track {
-   /* configuration we miror so that we use same code btw kms/ums */
+   /* configuration we mirror so that we use same code btw kms/ums */
u32 group_size;
u32 nbanks;
u32 npipes;
@@ -963,7 +963,7 @@ static int r600_cs_parse_packet0(struct radeon_cs_parser *p,
  *
  * This function will test against r600_reg_safe_bm and return 0
  * if register is safe. If register is not flag as safe this function
- * will test it against a list of register needind special handling.
+ * will test it against a list of register needing special handling.
  */
 static int r600_cs_check_reg(struct radeon_cs_parser *p, u32 reg, u32 idx)
 {
--
2.30.1

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

Re: [Intel-gfx] [PATCH v9 11/70] drm/i915: Disable userptr pread/pwrite support.

2021-03-24 Thread Jason Ekstrand

Never used by Mesa AFAIK

Acked-by: Jason Ekstrand 

On Tue, Mar 23, 2021 at 10:51 AM Maarten Lankhorst
 wrote:
>
> Userptr should not need the kernel for a userspace memcpy, userspace
> needs to call memcpy directly.
>
> Specifically, disable i915_gem_pwrite_ioctl() and i915_gem_pread_ioctl().
>
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Thomas Hellström 
>
> -- Still needs an ack from relevant userspace that it won't break, but should 
> be good.
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 20 
>  drivers/gpu/drm/i915/i915_gem.c |  5 +
>  2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> index 0f9024c62c06..5a19699c2d7e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> @@ -700,6 +700,24 @@ i915_gem_userptr_dmabuf_export(struct 
> drm_i915_gem_object *obj)
> return i915_gem_userptr_init__mmu_notifier(obj, 0);
>  }
>
> +static int
> +i915_gem_userptr_pwrite(struct drm_i915_gem_object *obj,
> +   const struct drm_i915_gem_pwrite *args)
> +{
> +   drm_dbg(obj->base.dev, "pwrite to userptr no longer allowed\n");
> +
> +   return -EINVAL;
> +}
> +
> +static int
> +i915_gem_userptr_pread(struct drm_i915_gem_object *obj,
> +  const struct drm_i915_gem_pread *args)
> +{
> +   drm_dbg(obj->base.dev, "pread from userptr no longer allowed\n");
> +
> +   return -EINVAL;
> +}
> +
>  static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = {
> .name = "i915_gem_object_userptr",
> .flags = I915_GEM_OBJECT_IS_SHRINKABLE |
> @@ -708,6 +726,8 @@ static const struct drm_i915_gem_object_ops 
> i915_gem_userptr_ops = {
> .get_pages = i915_gem_userptr_get_pages,
> .put_pages = i915_gem_userptr_put_pages,
> .dmabuf_export = i915_gem_userptr_dmabuf_export,
> +   .pwrite = i915_gem_userptr_pwrite,
> +   .pread = i915_gem_userptr_pread,
> .release = i915_gem_userptr_release,
>  };
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 25444d360f7f..dde12ce4f90b 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -403,6 +403,11 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
> }
>
> trace_i915_gem_object_pread(obj, args->offset, args->size);
> +   ret = -ENODEV;
> +   if (obj->ops->pread)
> +   ret = obj->ops->pread(obj, args);
> +   if (ret != -ENODEV)
> +   goto out;
>
> ret = -ENODEV;
> if (obj->ops->pread)
> --
> 2.31.0
>
> ___
> 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: [Intel-gfx] [PATCH resend 2/2] drm/i915/display: Make vlv_find_free_pps() skip pipes which are in use for non DP purposes

2021-03-24 Thread Ville Syrjälä

On Tue, Mar 23, 2021 at 11:39:09AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 3/2/21 3:51 PM, Ville Syrjälä wrote:
> > On Tue, Mar 02, 2021 at 01:00:40PM +0100, Hans de Goede wrote:
> >> As explained by a long comment block, on VLV intel_setup_outputs()
> >> sometimes thinks there might be an eDP panel connected while there is none.
> >> In this case intel_setup_outputs() will call intel_dp_init() to check.
> >>
> >> In this scenario vlv_find_free_pps() ends up selecting pipe A for the pps,
> >> even though this might be in use for non DP purposes. When this is the case
> >> then the assert_pipe() in vlv_force_pll_on() will fail when called from
> >> vlv_power_sequencer_kick().
> > 
> > The idea is that you *can* select a PPS from a pipe used for a non-DP
> > port since those don't care about the PPS stuff. So this doesn't seem
> > correct.
> 
> They may not care about the PPS stuff, but as the WARN / backtrace
> shows if the DPLL_VCO_ENABLE bit is not already set for the pipe, while
> the pipe is "otherwise" in use then vlv_force_pll_on() becomes unhappy
> triggering the WARN.
> 
> > a) I would like to see the VBT for this machine
> 
> https://fedorapeople.org/~jwrdegoede/voyo-winpad-a15-vbt
> 
> > b) I wonder if the DSI PLL is sufficient for getting the PPS going?
> 
> I have no idea, I just noticed the WARN / backtrace and this seemed
> like a reasonably way to deal with it. With that said I'm fine with fixing
> this a different way.
> 
> > c) If we do need the normal DPLL is there any harm to DSI in enabling it?
> 
> I would assume this increases power-consumption and DSI panels are almost
> always used in battery powered devices.

This is just used while probing the panel, so power consumption is
not a concern.

> 
> Also this would impact all BYT/CHT devices, possible triggering unwanted
> side-effects. Where as the proposed fix below is much more narrowly targeted
> at the problem. It might not be the most pretty fix but AFAICT it has a low
> risk of causing regressions.

It rather significantly changes the logic of the workaround, potentially
causing us to not find a free PPS at all. Eg. if you were to boot with
a VLV with pipe A -> eDP B + eDP C inactive + pipe B -> VGA then your
change would cause us to not find the free pipe B PPS for probing eDP C,
and in the end we'd get a WARN and fall back to pipe A PPS which would
clobber the actually in use pipe A PPS.

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

Re: [Intel-gfx] [PATCH resend 2/2] drm/i915/display: Make vlv_find_free_pps() skip pipes which are in use for non DP purposes

2021-03-24 Thread Hans de Goede

Hi,

On 3/24/21 3:02 PM, Ville Syrjälä wrote:
> On Tue, Mar 23, 2021 at 11:39:09AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 3/2/21 3:51 PM, Ville Syrjälä wrote:
>>> On Tue, Mar 02, 2021 at 01:00:40PM +0100, Hans de Goede wrote:
 As explained by a long comment block, on VLV intel_setup_outputs()
 sometimes thinks there might be an eDP panel connected while there is none.
 In this case intel_setup_outputs() will call intel_dp_init() to check.

 In this scenario vlv_find_free_pps() ends up selecting pipe A for the pps,
 even though this might be in use for non DP purposes. When this is the case
 then the assert_pipe() in vlv_force_pll_on() will fail when called from
 vlv_power_sequencer_kick().
>>>
>>> The idea is that you *can* select a PPS from a pipe used for a non-DP
>>> port since those don't care about the PPS stuff. So this doesn't seem
>>> correct.
>>
>> They may not care about the PPS stuff, but as the WARN / backtrace
>> shows if the DPLL_VCO_ENABLE bit is not already set for the pipe, while
>> the pipe is "otherwise" in use then vlv_force_pll_on() becomes unhappy
>> triggering the WARN.DPLL_VCO_ENABLE bit is not
>>
>>> a) I would like to see the VBT for this machine
>>
>> https://fedorapeople.org/~jwrdegoede/voyo-winpad-a15-vbt
>>
>>> b) I wonder if the DSI PLL is sufficient for getting the PPS going?
>>
>> I have no idea, I just noticed the WARN / backtrace and this seemed
>> like a reasonably way to deal with it. With that said I'm fine with fixing
>> this a different way.
>>
>>> c) If we do need the normal DPLL is there any harm to DSI in enabling it?
>>
>> I would assume this increases power-consumption and DSI panels are almost
>> always used in battery powered devices.
> 
> This is just used while probing the panel, so power consumption is
> not a concern.

Sorry I misinterpreted what you wrote, I interpreted it as have the DSI
code enable it to avoid this problem. I see now that that is now what
you meant.

>> Also this would impact all BYT/CHT devices, possible triggering unwanted
>> side-effects. Where as the proposed fix below is much more narrowly targeted
>> at the problem. It might not be the most pretty fix but AFAICT it has a low
>> risk of causing regressions.
> 
> It rather significantly changes the logic of the workaround, potentially
> causing us to not find a free PPS at all. Eg. if you were to boot with
> a VLV with pipe A -> eDP B + eDP C inactive + pipe B -> VGA then your
> change would cause us to not find the free pipe B PPS for probing eDP C,
> and in the end we'd get a WARN and fall back to pipe A PPS which would
> clobber the actually in use pipe A PPS.

I would welcome, and will happily test, another fix for this. ATM we
have a WARN triggering on actual hardware (and not just in a hypothetical
example) and I would like to see that WARN fixed. If you can come up with
a better fix I would be happy to test.

Regards,

Hans


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

Re: [Intel-gfx] [PATCH v9 28/70] drm/i915: Take obj lock around set_domain ioctl

On Tue, Mar 23, 2021 at 04:50:17PM +0100, Maarten Lankhorst wrote:
> We need to lock the object to move it to the correct domain,
> add the missing lock.
> 
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Thomas Hellström 

This conflicted real bad with the in-flight -gt-next stuff that wasn't
reset yet, so I picked up the old version here:

https://lore.kernel.org/intel-gfx/20210128162612.927917-29-maarten.lankho...@linux.intel.com/

That one looks a lot more reasonable.
-Daniel

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_domain.c | 41 ++
>  1 file changed, 19 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index 41dae0d83dbb..e3537922183b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -456,13 +456,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
> *data,
>* userptr validity
>*/
>   err = i915_gem_object_userptr_validate(obj);
> - if (!err)
> - err = i915_gem_object_wait(obj,
> -I915_WAIT_INTERRUPTIBLE |
> -I915_WAIT_PRIORITY |
> -(write_domain ? 
> I915_WAIT_ALL : 0),
> -MAX_SCHEDULE_TIMEOUT);
> - goto out;
> + goto out_wait;
>   }
>  
>   /*
> @@ -476,6 +470,10 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
> *data,
>   goto out;
>   }
>  
> + err = i915_gem_object_lock_interruptible(obj, NULL);
> + if (err)
> + goto out;
> +
>   /*
>* Flush and acquire obj->pages so that we are coherent through
>* direct access in memory with previous cached writes through
> @@ -487,7 +485,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
> *data,
>*/
>   err = i915_gem_object_pin_pages(obj);
>   if (err)
> - goto out;
> + goto out_unlock;
>  
>   /*
>* Already in the desired write domain? Nothing for us to do!
> @@ -500,10 +498,6 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
> *data,
>* without having to further check the requested write_domain.
>*/
>   if (READ_ONCE(obj->write_domain) == read_domains)
> - goto out_wait;
> -
> - err = i915_gem_object_lock_interruptible(obj, NULL);
> - if (err)
>   goto out_unpin;
>  
>   if (read_domains & I915_GEM_DOMAIN_WC)
> @@ -513,19 +507,22 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
> *data,
>   else
>   i915_gem_object_set_to_cpu_domain(obj, write_domain);
>  
> - i915_gem_object_unlock(obj);
> +out_unpin:
> + i915_gem_object_unpin_pages(obj);
>  
> +out_unlock:
> + i915_gem_object_unlock(obj);
>  out_wait:
> - err = i915_gem_object_wait(obj,
> -I915_WAIT_INTERRUPTIBLE |
> -I915_WAIT_PRIORITY |
> -(write_domain ? I915_WAIT_ALL : 0),
> -MAX_SCHEDULE_TIMEOUT);
> - if (write_domain)
> - i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
> + if (!err) {
> + err = i915_gem_object_wait(obj,
> +   I915_WAIT_INTERRUPTIBLE |
> +   I915_WAIT_PRIORITY |
> +   (write_domain ? I915_WAIT_ALL : 0),
> +   MAX_SCHEDULE_TIMEOUT);
> + if (write_domain)
> + i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
> + }
>  
> -out_unpin:
> - i915_gem_object_unpin_pages(obj);
>  out:
>   i915_gem_object_put(obj);
>   return err;
> -- 
> 2.31.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] amdgpu: fix gcc -Wrestrict warning

2021-03-24 Thread Rasmus Villemoes

On 24/03/2021 14.33, Arnd Bergmann wrote:
> On Tue, Mar 23, 2021 at 4:57 PM Rasmus Villemoes
>  wrote:
>> On 23/03/2021 14.04, Arnd Bergmann wrote:
>>>   if (securedisplay_cmd->status == 
>>> TA_SECUREDISPLAY_STATUS__SUCCESS) {
>>> + int pos = 0;
>>>   memset(i2c_output,  0, sizeof(i2c_output));
>>>   for (i = 0; i < 
>>> TA_SECUREDISPLAY_I2C_BUFFER_SIZE; i++)
>>> - sprintf(i2c_output, "%s 0x%X", 
>>> i2c_output,
>>> + pos += sprintf(i2c_output + pos, " 
>>> 0x%X",
>>>   
>>> securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf[i]);
>>>   dev_info(adev->dev, "SECUREDISPLAY: I2C 
>>> buffer out put is :%s\n", i2c_output);
>>
>> Eh, why not get rid of the 256 byte stack allocation and just replace
>> all of this by
>>
>>   dev_info(adev->dev, ""SECUREDISPLAY: I2C buffer out put is: %*ph\n",
>> TA_SECUREDISPLAY_I2C_BUFFER_SIZE,
>> securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf);
>>
>> That's much less code (both in #LOC and .text), and avoids adding yet
>> another place that will be audited over and over for "hm, yeah, that
>> sprintf() is actually not gonna overflow".
>>
>> Yeah, it'll lose the 0x prefixes for each byte and use lowercase hex chars.
> 
> Ah, I didn't know the kernel's sprintf could do that, that's really nice.

If you're bored, you can "git grep -E -C4 '%[0.]2[xX]'" and find places
that are inside a small loop, many can trivially be converted to %ph,
though often with some small change in formatting. If you're lucky, you
even get to fix real bugs when people pass a "char" to %02x and "know"
that that will produce precisely two bytes of output, so they've sized
their stack buffer accordingly - boom when "char" happens to be signed
and one of the bytes have a value beyond ascii and %02x produces 0xffXX.

%ph has a hard-coded upper bound of 64 bytes, I think that's silly
because people instead do these inefficient and very verbose loops
instead, wasting stack, .text and runtime.

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

Re: [PATCH] [v2] drm/imx: imx-ldb: fix out of bounds array access warning

2021-03-24 Thread Joe Perches

On Wed, 2021-03-24 at 13:17 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> When CONFIG_OF is disabled, building with 'make W=1' produces warnings
> about out of bounds array access:
> 
> drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
> drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below 
> array bounds of 'struct clk *[4]' [-Werror=array-bounds]
> 
> Add an error check before the index is used, which helps with the
> warning, as well as any possible other error condition that may be
> triggered at runtime.
> 
> The warning could be fixed by adding a Kconfig depedency on CONFIG_OF,
> but Liu Ying points out that the driver may hit the out-of-bounds
> problem at runtime anyway.
> 
> Signed-off-by: Arnd Bergmann 
> ---
> v2: fix subject line
> expand patch description
> print mux number
> check upper bound as well
[]
> diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
[]
> @@ -197,6 +197,12 @@ static void imx_ldb_encoder_enable(struct drm_encoder 
> *encoder)
>   int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
>   int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
> 
> + if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
> + dev_warn(ldb->dev, "%s: invalid mux %d\n",
> +  __func__, ERR_PTR(mux));

This does not compile without warnings.

drivers/gpu/drm/imx/imx-ldb.c: In function ‘imx_ldb_encoder_enable’:
drivers/gpu/drm/imx/imx-ldb.c:201:22: warning: format ‘%d’ expects argument of 
type ‘int’, but argument 4 has type ‘void *’ [-Wformat=]
  201 |   dev_warn(ldb->dev, "%s: invalid mux %d\n",
  |  ^~

If you want to use ERR_PTR, the %d should be %pe as ERR_PTR
is converting an int a void * to decode the error type and
emit it as a string.


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

Re: RE: [PATCH] video/fbdev: Fix a double free in hvfb_probe

2021-03-24 Thread lyl2019




> -原始邮件-
> 发件人: "Michael Kelley" 
> 发送时间: 2021-03-24 02:52:07 (星期三)
> 收件人: "Lv Yunlong" , "KY Srinivasan" 
> , "Haiyang Zhang" , "Stephen 
> Hemminger" , "wei@kernel.org" 
> 抄送: "linux-hyp...@vger.kernel.org" , 
> "dri-devel@lists.freedesktop.org" , 
> "linux-fb...@vger.kernel.org" , 
> "linux-ker...@vger.kernel.org" 
> 主题: RE: [PATCH] video/fbdev: Fix a double free in hvfb_probe
> 
> From: Lv Yunlong  Sent: Tuesday, March 23, 2021 
> 12:34 AM
> > 
> > In function hvfb_probe in hyperv_fb.c, it calls hvfb_getmem(hdev, info)
> > and return err when info->apertures is freed.
> > 
> > In the error1 label of hvfb_probe, info->apertures will be freed twice
> > by framebuffer_release(info).
> > 
> > My patch sets info->apertures to NULL after it was freed to avoid
> > double free.
> > 
> > Signed-off-by: Lv Yunlong 
> > ---
> >  drivers/video/fbdev/hyperv_fb.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/video/fbdev/hyperv_fb.c 
> > b/drivers/video/fbdev/hyperv_fb.c
> > index c8b0ae676809..2fc9b507e73a 100644
> > --- a/drivers/video/fbdev/hyperv_fb.c
> > +++ b/drivers/video/fbdev/hyperv_fb.c
> > @@ -1032,6 +1032,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct 
> > fb_info
> > *info)
> > if (!pdev) {
> > pr_err("Unable to find PCI Hyper-V video\n");
> > kfree(info->apertures);
> > +   info->apertures = NULL;
> > return -ENODEV;
> > }
> > 
> > @@ -1130,6 +1131,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct 
> > fb_info
> > *info)
> > pci_dev_put(pdev);
> > }
> > kfree(info->apertures);
> > +   info->apertures = NULL;
> > 
> > return 0;
> > 
> > @@ -1142,6 +1144,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct 
> > fb_info
> > *info)
> > if (!gen2vm)
> > pci_dev_put(pdev);
> > kfree(info->apertures);
> > +   info->apertures = NULL;
> > 
> > return -ENOMEM;
> >  }
> > --
> > 2.25.1
> > 
> 
> While I think this works, a slightly better solution might be to remove
> all calls to kfree(info->apertures) in hvfb_getmem(),  and just let
> framebuffer_release() handle freeing the memory.  That's what is
> done in other drivers that follow the fbdev pattern, and it's less
> code overall.  
> 
> Michael

Ok, i agree with you. Remove all calls to kfree(info->apertures)
in hvfb_getmem() is a better solution.

I will subimt a PATCH v2 for you to review. Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] mm: unexport follow_pfn

2021-03-24 Thread Paolo Bonzini


On 24/03/21 13:52, Jason Gunthorpe wrote:

I think this is the right thing to do.

Alex is working on fixing VFIO and while kvm is still racy using
follow pte, I think they are working on it too?


Yeah, or at least we have a plan.

Paolo

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

Re: [PATCH] amdgpu: fix gcc -Wrestrict warning

2021-03-24 Thread Joe Perches

On Tue, 2021-03-23 at 14:04 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> gcc warns about an sprintf() that uses the same buffer as source
> and destination, which is undefined behavior in C99:
> 
> drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c: In function 
> 'amdgpu_securedisplay_debugfs_write':
> drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c:141:6: error: 'sprintf' 
> argument 3 overlaps destination object 'i2c_output' [-Werror=restrict]
>   141 |  sprintf(i2c_output, "%s 0x%X", i2c_output,
>   |  ^~
>   142 |   
> securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf[i]);
>   |   
> ~
> drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c:97:7: note: destination 
> object referenced by 'restrict'-qualified argument 1 was declared here
>    97 |  char i2c_output[256];
>   |   ^~
> 
> Rewrite it to remember the current offset into the buffer instead.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
> index 834440ab9ff7..69d7f6bff5d4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
> @@ -136,9 +136,10 @@ static ssize_t amdgpu_securedisplay_debugfs_write(struct 
> file *f, const char __u
>   ret = psp_securedisplay_invoke(psp, 
> TA_SECUREDISPLAY_COMMAND__SEND_ROI_CRC);
>   if (!ret) {
>   if (securedisplay_cmd->status == 
> TA_SECUREDISPLAY_STATUS__SUCCESS) {
> + int pos = 0;
>   memset(i2c_output,  0, sizeof(i2c_output));
>   for (i = 0; i < 
> TA_SECUREDISPLAY_I2C_BUFFER_SIZE; i++)
> - sprintf(i2c_output, "%s 0x%X", 
> i2c_output,
> + pos += sprintf(i2c_output + pos, " 
> 0x%X",
>   
> securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf[i]);
>   dev_info(adev->dev, "SECUREDISPLAY: I2C buffer 
> out put is :%s\n", i2c_output);

Perhaps use a hex output like:

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
index 9cf856c94f94..25bb34c72d20 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
@@ -97,13 +97,12 @@ static ssize_t amdgpu_securedisplay_debugfs_write(struct 
file *f, const char __u
uint32_t op;
int i;
char str[64];
-   char i2c_output[256];
int ret;
 
if (*pos || size > sizeof(str) - 1)
return -EINVAL;
 
-   memset(str,  0, sizeof(str));
+   memset(str, 0, sizeof(str));
ret = copy_from_user(str, buf, size);
if (ret)
return -EFAULT;
@@ -139,11 +138,9 @@ static ssize_t amdgpu_securedisplay_debugfs_write(struct 
file *f, const char __u
ret = psp_securedisplay_invoke(psp, 
TA_SECUREDISPLAY_COMMAND__SEND_ROI_CRC);
if (!ret) {
if (securedisplay_cmd->status == 
TA_SECUREDISPLAY_STATUS__SUCCESS) {
-   memset(i2c_output,  0, sizeof(i2c_output));
-   for (i = 0; i < 
TA_SECUREDISPLAY_I2C_BUFFER_SIZE; i++)
-   sprintf(i2c_output, "%s 0x%X", 
i2c_output,
-   
securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf[i]);
-   dev_info(adev->dev, "SECUREDISPLAY: I2C buffer 
out put is :%s\n", i2c_output);
+   dev_info(adev->dev, "SECUREDISPLAY: I2C buffer 
output is: %*ph\n",
+(int)TA_SECUREDISPLAY_I2C_BUFFER_SIZE,
+
securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf);
} else {
psp_securedisplay_parse_resp_status(psp, 
securedisplay_cmd->status);
}


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

Re: [Intel-gfx] [PATCH resend 2/2] drm/i915/display: Make vlv_find_free_pps() skip pipes which are in use for non DP purposes

2021-03-24 Thread Ville Syrjälä

On Wed, Mar 24, 2021 at 03:10:59PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 3/24/21 3:02 PM, Ville Syrjälä wrote:
> > On Tue, Mar 23, 2021 at 11:39:09AM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 3/2/21 3:51 PM, Ville Syrjälä wrote:
> >>> On Tue, Mar 02, 2021 at 01:00:40PM +0100, Hans de Goede wrote:
>  As explained by a long comment block, on VLV intel_setup_outputs()
>  sometimes thinks there might be an eDP panel connected while there is 
>  none.
>  In this case intel_setup_outputs() will call intel_dp_init() to check.
> 
>  In this scenario vlv_find_free_pps() ends up selecting pipe A for the 
>  pps,
>  even though this might be in use for non DP purposes. When this is the 
>  case
>  then the assert_pipe() in vlv_force_pll_on() will fail when called from
>  vlv_power_sequencer_kick().
> >>>
> >>> The idea is that you *can* select a PPS from a pipe used for a non-DP
> >>> port since those don't care about the PPS stuff. So this doesn't seem
> >>> correct.
> >>
> >> They may not care about the PPS stuff, but as the WARN / backtrace
> >> shows if the DPLL_VCO_ENABLE bit is not already set for the pipe, while
> >> the pipe is "otherwise" in use then vlv_force_pll_on() becomes unhappy
> >> triggering the WARN.DPLL_VCO_ENABLE bit is not
> >>
> >>> a) I would like to see the VBT for this machine
> >>
> >> https://fedorapeople.org/~jwrdegoede/voyo-winpad-a15-vbt
> >>
> >>> b) I wonder if the DSI PLL is sufficient for getting the PPS going?
> >>
> >> I have no idea, I just noticed the WARN / backtrace and this seemed
> >> like a reasonably way to deal with it. With that said I'm fine with fixing
> >> this a different way.
> >>
> >>> c) If we do need the normal DPLL is there any harm to DSI in enabling it?
> >>
> >> I would assume this increases power-consumption and DSI panels are almost
> >> always used in battery powered devices.
> > 
> > This is just used while probing the panel, so power consumption is
> > not a concern.
> 
> Sorry I misinterpreted what you wrote, I interpreted it as have the DSI
> code enable it to avoid this problem. I see now that that is now what
> you meant.
> 
> >> Also this would impact all BYT/CHT devices, possible triggering unwanted
> >> side-effects. Where as the proposed fix below is much more narrowly 
> >> targeted
> >> at the problem. It might not be the most pretty fix but AFAICT it has a low
> >> risk of causing regressions.
> > 
> > It rather significantly changes the logic of the workaround, potentially
> > causing us to not find a free PPS at all. Eg. if you were to boot with
> > a VLV with pipe A -> eDP B + eDP C inactive + pipe B -> VGA then your
> > change would cause us to not find the free pipe B PPS for probing eDP C,
> > and in the end we'd get a WARN and fall back to pipe A PPS which would
> > clobber the actually in use pipe A PPS.
> 
> I would welcome, and will happily test, another fix for this. ATM we
> have a WARN triggering on actual hardware (and not just in a hypothetical
> example) and I would like to see that WARN fixed. If you can come up with
> a better fix I would be happy to test.

Well, I think there are a couple things we want to experiment wiht:

a) Just skip the asserts and see if enabling the DPLL/poking the PPS
   perturbs the DSI output in any way.

--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -1467,7 +1467,7 @@ void vlv_enable_pll(struct intel_crtc *crtc,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
 
-   assert_pipe_disabled(dev_priv, pipe_config->cpu_transcoder);
+   //assert_pipe_disabled(dev_priv, pipe_config->cpu_transcoder);
 
/* PLL is protected by panel, make sure we can write it */
assert_panel_unlocked(dev_priv, pipe);
@@ -1800,7 +1800,7 @@ void vlv_disable_pll(struct drm_i915_private *dev_priv, 
enum pipe pipe)
u32 val;
 
/* Make sure the pipe isn't still relying on us */
-   assert_pipe_disabled(dev_priv, (enum transcoder)pipe);
+   //assert_pipe_disabled(dev_priv, (enum transcoder)pipe);
 
val = DPLL_INTEGRATED_REF_CLK_VLV |
DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS;
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -110,6 +110,8 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
intel_de_write(dev_priv, intel_dp->output_reg, DP & ~DP_PORT_EN);
intel_de_posting_read(dev_priv, intel_dp->output_reg);
 
+   msleep(1000); // just to make sure we keep angering DSI for a bit longer
+
if (!pll_enabled) {
vlv_force_pll_off(dev_priv, pipe);
 

b) Don't enable the DPLL at all and see if the DSI PLL is capable of
   clocking the PPS. My gut feeling says this will not work and we
   should see the PPS state machine not make progress, but not sure.

--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers

[PATCH v2] video: hyperv_fb: Fix a double free in hvfb_probe

2021-03-24 Thread Lv Yunlong

In function hvfb_probe in hyperv_fb.c, it calls hvfb_getmem(hdev, info)
and return err when info->apertures is freed.

In the error1 label of hvfb_probe, info->apertures will be freed for the
second time in framebuffer_release(info).

My patch removes all kfree(info->apertures) instead of set info->apertures
to NULL. It is because that let framebuffer_release() handle freeing the
memory flows the fbdev pattern, and less code overall.

Signed-off-by: Lv Yunlong 
---
 drivers/video/fbdev/hyperv_fb.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index c8b0ae676809..4dc9077dd2ac 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1031,7 +1031,6 @@ static int hvfb_getmem(struct hv_device *hdev, struct 
fb_info *info)
PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
if (!pdev) {
pr_err("Unable to find PCI Hyper-V video\n");
-   kfree(info->apertures);
return -ENODEV;
}
 
@@ -1129,7 +1128,6 @@ static int hvfb_getmem(struct hv_device *hdev, struct 
fb_info *info)
} else {
pci_dev_put(pdev);
}
-   kfree(info->apertures);
 
return 0;
 
@@ -1141,7 +1139,6 @@ static int hvfb_getmem(struct hv_device *hdev, struct 
fb_info *info)
 err1:
if (!gen2vm)
pci_dev_put(pdev);
-   kfree(info->apertures);
 
return -ENOMEM;
 }
-- 
2.25.1


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

Re: [PATCH 6/9] drm/tegra: gem: Add a clarifying comment

2021-03-24 Thread Dmitry Osipenko

23.03.2021 18:54, Thierry Reding пишет:
> From: Thierry Reding 
> 
> Clarify when a fixed IOV address can be used and when a buffer has to
> be mapped before the IOVA can be used.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/tegra/plane.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
> index 19e8847a164b..793da5d675d2 100644
> --- a/drivers/gpu/drm/tegra/plane.c
> +++ b/drivers/gpu/drm/tegra/plane.c
> @@ -119,6 +119,14 @@ static int tegra_dc_pin(struct tegra_dc *dc, struct 
> tegra_plane_state *state)
>   dma_addr_t phys_addr, *phys;
>   struct sg_table *sgt;
>  
> + /*
> +  * If we're not attached to a domain, we already stored the
> +  * physical address when the buffer was allocated. If we're
> +  * part of a group that's shared between all display
> +  * controllers, we've also already mapped the framebuffer
> +  * through the SMMU. In both cases we can short-circuit the
> +  * code below and retrieve the stored IOV address.
> +  */
>   if (!domain || dc->client.group)
>   phys = &phys_addr;
>   else
> 

This comment is correct, but the logic feels a bit lame because it
should be wasteful to re-map DMA on each FB flip. Personally I don't
care much about this since older Tegras use pinned buffers by default,
but this shouldn't be good for T124+ users.

Perhaps dumb buffers should be pinned to display by default and then we
should extend the Tegra UAPI to support BO mapping to display client(?).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v9 30/70] drm/i915: Fix pread/pwrite to work with new locking rules.

On Tue, Mar 23, 2021 at 04:50:19PM +0100, Maarten Lankhorst wrote:
> We are removing obj->mm.lock, and need to take the reservation lock
> before we can pin pages. Move the pinning pages into the helper, and
> merge gtt pwrite/pread preparation and cleanup paths.
> 
> The fence lock is also removed; it will conflict with fence annotations,
> because of memory allocations done when pagefaulting inside copy_*_user.
> 
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Thomas Hellström 

Same here, I picked the old version from there

https://lore.kernel.org/intel-gfx/20210128162612.927917-31-maarten.lankho...@linux.intel.com/

because too much conflicts with this version here.
-Daniel

> ---
>  drivers/gpu/drm/i915/Makefile  |   1 -
>  drivers/gpu/drm/i915/gem/i915_gem_fence.c  |  95 -
>  drivers/gpu/drm/i915/gem/i915_gem_object.h |   5 -
>  drivers/gpu/drm/i915/i915_gem.c| 215 +++--
>  4 files changed, 112 insertions(+), 204 deletions(-)
>  delete mode 100644 drivers/gpu/drm/i915/gem/i915_gem_fence.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 33c2100414a0..70a535798ef5 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -140,7 +140,6 @@ gem-y += \
>   gem/i915_gem_dmabuf.o \
>   gem/i915_gem_domain.o \
>   gem/i915_gem_execbuffer.o \
> - gem/i915_gem_fence.o \
>   gem/i915_gem_internal.o \
>   gem/i915_gem_object.o \
>   gem/i915_gem_object_blt.o \
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_fence.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_fence.c
> deleted file mode 100644
> index 8ab842c80f99..
> --- a/drivers/gpu/drm/i915/gem/i915_gem_fence.c
> +++ /dev/null
> @@ -1,95 +0,0 @@
> -/*
> - * SPDX-License-Identifier: MIT
> - *
> - * Copyright © 2019 Intel Corporation
> - */
> -
> -#include "i915_drv.h"
> -#include "i915_gem_object.h"
> -
> -struct stub_fence {
> - struct dma_fence dma;
> - struct i915_sw_fence chain;
> -};
> -
> -static int __i915_sw_fence_call
> -stub_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
> -{
> - struct stub_fence *stub = container_of(fence, typeof(*stub), chain);
> -
> - switch (state) {
> - case FENCE_COMPLETE:
> - dma_fence_signal(&stub->dma);
> - break;
> -
> - case FENCE_FREE:
> - dma_fence_put(&stub->dma);
> - break;
> - }
> -
> - return NOTIFY_DONE;
> -}
> -
> -static const char *stub_driver_name(struct dma_fence *fence)
> -{
> - return DRIVER_NAME;
> -}
> -
> -static const char *stub_timeline_name(struct dma_fence *fence)
> -{
> - return "object";
> -}
> -
> -static void stub_release(struct dma_fence *fence)
> -{
> - struct stub_fence *stub = container_of(fence, typeof(*stub), dma);
> -
> - i915_sw_fence_fini(&stub->chain);
> -
> - BUILD_BUG_ON(offsetof(typeof(*stub), dma));
> - dma_fence_free(&stub->dma);
> -}
> -
> -static const struct dma_fence_ops stub_fence_ops = {
> - .get_driver_name = stub_driver_name,
> - .get_timeline_name = stub_timeline_name,
> - .release = stub_release,
> -};
> -
> -struct dma_fence *
> -i915_gem_object_lock_fence(struct drm_i915_gem_object *obj)
> -{
> - struct stub_fence *stub;
> -
> - assert_object_held(obj);
> -
> - stub = kmalloc(sizeof(*stub), GFP_KERNEL);
> - if (!stub)
> - return NULL;
> -
> - i915_sw_fence_init(&stub->chain, stub_notify);
> - dma_fence_init(&stub->dma, &stub_fence_ops, &stub->chain.wait.lock,
> -0, 0);
> -
> - if (i915_sw_fence_await_reservation(&stub->chain,
> - obj->base.resv, NULL, true,
> - 
> i915_fence_timeout(to_i915(obj->base.dev)),
> - I915_FENCE_GFP) < 0)
> - goto err;
> -
> - dma_resv_add_excl_fence(obj->base.resv, &stub->dma);
> -
> - return &stub->dma;
> -
> -err:
> - stub_release(&stub->dma);
> - return NULL;
> -}
> -
> -void i915_gem_object_unlock_fence(struct drm_i915_gem_object *obj,
> -   struct dma_fence *fence)
> -{
> - struct stub_fence *stub = container_of(fence, typeof(*stub), dma);
> -
> - i915_sw_fence_commit(&stub->chain);
> -}
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index fef0d62f3eb7..6c3f75adb53c 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -189,11 +189,6 @@ static inline void i915_gem_object_unlock(struct 
> drm_i915_gem_object *obj)
>   dma_resv_unlock(obj->base.resv);
>  }
>  
> -struct dma_fence *
> -i915_gem_object_lock_fence(struct drm_i915_gem_object *obj);
> -void i915_gem_object_unlock_fence(struct drm_i915_gem_object *obj,
> -   struct dma_fence *fence);
> -
>  static in

Re: [PATCH 3/6] drm/rockchip: dsi: add ability to work as a phy instead of full dsi

2021-03-24 Thread Heiko Stübner

Am Montag, 15. Februar 2021, 15:33:19 CET schrieb Helen Koike:
> > From: Heiko Stuebner 
> > diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> > b/drivers/gpu/drm/rockchip/Kconfig
> > index cb25c0e8fc9b..3094d4533ad6 100644
> > --- a/drivers/gpu/drm/rockchip/Kconfig
> > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > @@ -9,6 +9,8 @@ config DRM_ROCKCHIP
> > select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
> > select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
> > select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
> > +   select GENERIC_PHY if ROCKCHIP_DW_MIPI_DSI
> > +   select GENERIC_PHY_MIPI_DPHY if ROCKCHIP_DW_MIPI_DSI
> 
> maybe alphabetical order?

ok

> > +static int dw_mipi_dsi_dphy_power_on(struct phy *phy)
> > +{
> > +   struct dw_mipi_dsi_rockchip *dsi = phy_get_drvdata(phy);
> > +   int i, ret;
> 
> It seems "i" could be removed, use ret instead.

I don't think so

I.e. the driver does

i = max_mbps_to_parameter(...)
...
ret = power-on-clocks-and-stuff
...
dw_mipi_dsi_phy_write( dppa_map[i].hsfreqrange)

So will need to keep the param index separate.


> In general, the patch doesn't look wrong to me.
> 
> For the whole serie:
> Acked-by: Helen Koike 

Thanks a lot :-)


Heiko


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

Re: [PATCH] drm/amdgpu: Ensure that the modifier requested is supported by plane.

2021-03-24 Thread Mark Yacoub

On Wed, Mar 24, 2021 at 8:10 AM Daniel Stone  wrote:
>
> On Wed, 24 Mar 2021 at 10:53, Bas Nieuwenhuizen  
> wrote:
>>
>> On Wed, Mar 24, 2021 at 11:13 AM Michel Dänzer  wrote:
>>>
>>> No modifier support does not imply linear. It's generally signalled via 
>>> DRM_FORMAT_MOD_INVALID, which roughly means "tiling is determined by driver 
>>> specific mechanisms".
So you mean it would make more sense to be more explicit in handling
DRM_FORMAT_MOD_INVALID as an incoming modifier (which will, just like
DRM_FORMAT_MOD_LINEAR, will return true in
dm_plane_format_mod_supported)?
>>
>>
>> Doesn't quite work that way in the kernel sadly. If you don't set 
>> DRM_MODE_FB_MODIFIERS then the modifier fields have to be 0 (which happens 
>> to alias DRM_FORMAT_MOD_LINEAR and then now deprecated DRM_FORMAT_MOD_NONE). 
>> This is verified in shared drm code.
>>
>> (and all userspace code I've seen simply doesn't set DRM_MODE_FB_MODIFIERS 
>> if the incoming modifier is DRM_FORMAT_MOD_INVALID)
>
>
> Yes, but even though the field is zero, the lack of the flag means it must be 
> treated as INVALID. If the kernel is not doing this, the kernel is 
> objectively wrong. (And I know it doesn't do this in most cases, because 
> otherwise I wouldn't be able to use this GNOME session on an Intel laptop, 
> where modifiers are blacklisted.)
>
> Cheers,
> Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/21] drm/msm/dpu: enable DPU_SSPP_QOS_8LVL for SM8250

SM8250 platform has a 8-Levels VIG QoS setting. This setting was missed
due to bad interaction with b8dab65b5ac3 ("drm/msm/dpu: Move
DPU_SSPP_QOS_8LVL bit to SDM845 and SC7180 masks"), which was applied in
parallel.

Fixes: d21fc5dfc3df ("drm/msm/dpu1: add support for qseed3lite used on sm8250")
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 189f3533525c..e452759c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -22,7 +22,7 @@
(VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4))
 
 #define VIG_SM8250_MASK \
-   (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3LITE))
+   (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE))
 
 #define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
-- 
2.30.2

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

[PATCH 06/21] drm/msm/dpu: get PINGPONG blocks directly rather than through RM

Each PINGPONG block is tied to a single LM. No LMs can share single PINGPONG
block. So there is no need to handle PINGPONG blocks through all resource
allocation/deallocation/assignment, just receive PINGPONG block as a part of
LM hardware instance.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   | 12 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 10 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h |  6 +-
 .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h   |  1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |  1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 99 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h|  2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h |  9 +-
 8 files changed, 26 insertions(+), 114 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index b3d50f6d976d..d98b4e4097fb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -974,10 +974,9 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
struct drm_crtc *drm_crtc;
struct dpu_crtc_state *cstate;
struct dpu_global_state *global_state;
-   struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
-   int num_lm, num_ctl, num_pp;
+   int num_lm, num_ctl;
int i, j;
 
if (!drm_enc) {
@@ -1020,18 +1019,11 @@ static void dpu_encoder_virt_mode_set(struct 
drm_encoder *drm_enc,
break;
 
/* Query resource that have been reserved in atomic check step. */
-   num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
-   drm_enc->base.id, DPU_HW_BLK_PINGPONG, hw_pp,
-   ARRAY_SIZE(hw_pp));
num_ctl = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
num_lm = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_LM, hw_lm, ARRAY_SIZE(hw_lm));
 
-   for (i = 0; i < MAX_CHANNELS_PER_ENC; i++)
-   dpu_enc->hw_pp[i] = i < num_pp ? to_dpu_hw_pingpong(hw_pp[i])
-   : NULL;
-
cstate = to_dpu_crtc_state(drm_crtc->state);
 
for (i = 0; i < num_lm; i++) {
@@ -1040,6 +1032,8 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
cstate->mixers[i].hw_lm = to_dpu_hw_mixer(hw_lm[i]);
cstate->mixers[i].lm_ctl = to_dpu_hw_ctl(hw_ctl[ctl_idx]);
cstate->mixers[i].hw_dspp = cstate->mixers[i].hw_lm->dspp;
+
+   dpu_enc->hw_pp[i] = cstate->mixers[i].hw_lm->pingpong;
}
 
cstate->num_mixers = num_lm;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 35675744a6b7..fd09b9ab9b4b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -8,6 +8,7 @@
 #include "dpu_hw_dspp.h"
 #include "dpu_hw_lm.h"
 #include "dpu_hw_mdss.h"
+#include "dpu_hw_pingpong.h"
 
 #define LM_OP_MODE0x00
 #define LM_OUT_SIZE   0x04
@@ -163,7 +164,8 @@ static void _setup_mixer_ops(const struct dpu_mdss_cfg *m,
 
 struct dpu_hw_mixer *dpu_hw_lm_init(enum dpu_lm idx,
void __iomem *addr,
-   const struct dpu_mdss_cfg *m)
+   const struct dpu_mdss_cfg *m,
+   struct dpu_hw_merge_3d **merge_3d_blks)
 {
struct dpu_hw_mixer *c;
const struct dpu_lm_cfg *cfg;
@@ -185,6 +187,8 @@ struct dpu_hw_mixer *dpu_hw_lm_init(enum dpu_lm idx,
 
if (cfg->dspp && cfg->dspp < DSPP_MAX)
c->dspp = dpu_hw_dspp_init(cfg->dspp, addr, m);
+   if (cfg->pingpong && cfg->pingpong < PINGPONG_MAX)
+   c->pingpong = dpu_hw_pingpong_init(cfg->pingpong, addr, m, 
merge_3d_blks);
 
dpu_hw_blk_init(&c->base, DPU_HW_BLK_LM, idx);
 
@@ -193,7 +197,9 @@ struct dpu_hw_mixer *dpu_hw_lm_init(enum dpu_lm idx,
 
 void dpu_hw_lm_destroy(struct dpu_hw_mixer *lm)
 {
-   if (lm)
+   if (lm) {
dpu_hw_dspp_destroy(lm->dspp);
+   dpu_hw_pingpong_destroy(lm->pingpong);
+   }
kfree(lm);
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h
index effb78311a43..182740f2914b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h
@@ -64,6 +64,7 @@ struct dpu_hw_mixer {
const struct dpu_lm_cfg   *cap;
const struct dpu_mdp_cfg  *mdp;
const struct dpu_ctl_cfg  *ctl;
+   struct dpu_hw_pingpong *pingpong;
struct dpu_hw_dspp *dspp;
 
/* ops */
@@ -83,16 +84,19 @@ static inline struct dpu_

[PATCH 03/21] drm/msm/dpu: drop dpu_hw_blk_destroy function

The dpu_hw_blk_destroy() function is empty, so we can drop it now.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c  | 13 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h  |  1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c  |  2 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c |  3 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c |  2 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c   |  2 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c  |  2 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c |  2 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c |  2 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c  |  2 --
 10 files changed, 31 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
index abad043f35f5..1f2b74b9eb65 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
@@ -22,16 +22,3 @@ void dpu_hw_blk_init(struct dpu_hw_blk *hw_blk, u32 type, 
int id)
hw_blk->type = type;
hw_blk->id = id;
 }
-
-/**
- * dpu_hw_blk_destroy - destroy hw block object.
- * @hw_blk:  pointer to hw block object
- * return: none
- */
-void dpu_hw_blk_destroy(struct dpu_hw_blk *hw_blk)
-{
-   if (!hw_blk) {
-   pr_err("invalid parameters\n");
-   return;
-   }
-}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
index fb3be9a36a50..7768694b558a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
@@ -24,5 +24,4 @@ struct dpu_hw_blk {
 };
 
 void dpu_hw_blk_init(struct dpu_hw_blk *hw_blk, u32 type, int id);
-void dpu_hw_blk_destroy(struct dpu_hw_blk *hw_blk);
 #endif /*_DPU_HW_BLK_H */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index ad60d59d3106..ac0f10dd0490 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -591,7 +591,5 @@ struct dpu_hw_ctl *dpu_hw_ctl_init(enum dpu_ctl idx,
 
 void dpu_hw_ctl_destroy(struct dpu_hw_ctl *ctx)
 {
-   if (ctx)
-   dpu_hw_blk_destroy(&ctx->base);
kfree(ctx);
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index d2f1045a736a..977b25968f34 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -117,9 +117,6 @@ struct dpu_hw_dspp *dpu_hw_dspp_init(enum dpu_dspp idx,
 
 void dpu_hw_dspp_destroy(struct dpu_hw_dspp *dspp)
 {
-   if (dspp)
-   dpu_hw_blk_destroy(&dspp->base);
-
kfree(dspp);
 }
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index db78842e3999..8df75936d906 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -322,8 +322,6 @@ struct dpu_hw_intf *dpu_hw_intf_init(enum dpu_intf idx,
 
 void dpu_hw_intf_destroy(struct dpu_hw_intf *intf)
 {
-   if (intf)
-   dpu_hw_blk_destroy(&intf->base);
kfree(intf);
 }
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 554bb881de3a..76f8b8f75b82 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -189,7 +189,5 @@ struct dpu_hw_mixer *dpu_hw_lm_init(enum dpu_lm idx,
 
 void dpu_hw_lm_destroy(struct dpu_hw_mixer *lm)
 {
-   if (lm)
-   dpu_hw_blk_destroy(&lm->base);
kfree(lm);
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
index 863229dd0140..406ba950a066 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
@@ -86,7 +86,5 @@ struct dpu_hw_merge_3d *dpu_hw_merge_3d_init(enum 
dpu_merge_3d idx,
 
 void dpu_hw_merge_3d_destroy(struct dpu_hw_merge_3d *hw)
 {
-   if (hw)
-   dpu_hw_blk_destroy(&hw->base);
kfree(hw);
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 334d5b28f533..92cd724263ce 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -289,7 +289,5 @@ struct dpu_hw_pingpong *dpu_hw_pingpong_init(enum 
dpu_pingpong idx,
 
 void dpu_hw_pingpong_destroy(struct dpu_hw_pingpong *pp)
 {
-   if (pp)
-   dpu_hw_blk_destroy(&pp->base);
kfree(pp);
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index ceb2488ea270..8734a47040aa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -740,8 +740,6 @@ struct dpu_hw_pipe *dpu_hw_sspp_init(enum dpu_sspp idx,
 
 void dpu_hw_sspp_destro

[PATCH 04/21] drm/msm/dpu: get DSPP blocks directly rather than through RM

Each DSPP block is tied to a single LM. No LMs can share single DSPP
block. So there is no need to handle DSPP blocks through all resource
allocation/deallocation/assignment, just receive DSPP block as a part of
LM hardware instance.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |   6 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c   |   6 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h   |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c  | 116 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h  |   2 -
 6 files changed, 44 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 288e95ee8e1d..b3d50f6d976d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -977,7 +977,6 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
-   struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
int num_lm, num_ctl, num_pp;
int i, j;
 
@@ -1028,9 +1027,6 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
drm_enc->base.id, DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
num_lm = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_LM, hw_lm, ARRAY_SIZE(hw_lm));
-   dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
-   drm_enc->base.id, DPU_HW_BLK_DSPP, hw_dspp,
-   ARRAY_SIZE(hw_dspp));
 
for (i = 0; i < MAX_CHANNELS_PER_ENC; i++)
dpu_enc->hw_pp[i] = i < num_pp ? to_dpu_hw_pingpong(hw_pp[i])
@@ -1043,7 +1039,7 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
 
cstate->mixers[i].hw_lm = to_dpu_hw_mixer(hw_lm[i]);
cstate->mixers[i].lm_ctl = to_dpu_hw_ctl(hw_ctl[ctl_idx]);
-   cstate->mixers[i].hw_dspp = to_dpu_hw_dspp(hw_dspp[i]);
+   cstate->mixers[i].hw_dspp = cstate->mixers[i].hw_lm->dspp;
}
 
cstate->num_mixers = num_lm;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 76f8b8f75b82..35675744a6b7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -5,6 +5,7 @@
 #include "dpu_kms.h"
 #include "dpu_hw_catalog.h"
 #include "dpu_hwio.h"
+#include "dpu_hw_dspp.h"
 #include "dpu_hw_lm.h"
 #include "dpu_hw_mdss.h"
 
@@ -182,6 +183,9 @@ struct dpu_hw_mixer *dpu_hw_lm_init(enum dpu_lm idx,
c->cap = cfg;
_setup_mixer_ops(m, &c->ops, c->cap->features);
 
+   if (cfg->dspp && cfg->dspp < DSPP_MAX)
+   c->dspp = dpu_hw_dspp_init(cfg->dspp, addr, m);
+
dpu_hw_blk_init(&c->base, DPU_HW_BLK_LM, idx);
 
return c;
@@ -189,5 +193,7 @@ struct dpu_hw_mixer *dpu_hw_lm_init(enum dpu_lm idx,
 
 void dpu_hw_lm_destroy(struct dpu_hw_mixer *lm)
 {
+   if (lm)
+   dpu_hw_dspp_destroy(lm->dspp);
kfree(lm);
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h
index 4a6b2de19ef6..effb78311a43 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h
@@ -64,6 +64,7 @@ struct dpu_hw_mixer {
const struct dpu_lm_cfg   *cap;
const struct dpu_mdp_cfg  *mdp;
const struct dpu_ctl_cfg  *ctl;
+   struct dpu_hw_dspp *dspp;
 
/* ops */
struct dpu_hw_lm_ops ops;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index d6717d6672f7..195a854245fa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -164,7 +164,6 @@ struct dpu_global_state {
uint32_t mixer_to_enc_id[LM_MAX - LM_0];
uint32_t ctl_to_enc_id[CTL_MAX - CTL_0];
uint32_t intf_to_enc_id[INTF_MAX - INTF_0];
-   uint32_t dspp_to_enc_id[DSPP_MAX - DSPP_0];
 };
 
 struct dpu_global_state
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index fd2d104f0a91..bb03ff8b8c9f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -9,7 +9,6 @@
 #include "dpu_hw_ctl.h"
 #include "dpu_hw_pingpong.h"
 #include "dpu_hw_intf.h"
-#include "dpu_hw_dspp.h"
 #include "dpu_hw_merge3d.h"
 #include "dpu_encoder.h"
 #include "dpu_trace.h"
@@ -35,6 +34,14 @@ int dpu_rm_destroy(struct dpu_rm *rm)
 {
int i;
 
+   for (i = 0; i < ARRAY_SIZE(rm->mixer_blks); i++) {
+   struct dpu_hw_mixer *hw;
+
+   if (rm->mixer_blks[i]) {
+   hw = to_dpu_hw_mixer(rm->mixer_blks[i]);
+

[PATCH 07/21] drm/msm/dpu: drop unused lm_max_width from RM

No code uses lm_max_width from resource manager, so drop it.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 12 
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |  4 
 2 files changed, 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 7792dff60bcd..dbcf4929810b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -134,18 +134,6 @@ int dpu_rm_init(struct dpu_rm *rm,
goto fail;
}
rm->mixer_blks[lm->id - LM_0] = &hw->base;
-
-   if (!rm->lm_max_width) {
-   rm->lm_max_width = lm->sblk->maxwidth;
-   } else if (rm->lm_max_width != lm->sblk->maxwidth) {
-   /*
-* Don't expect to have hw where lm max widths differ.
-* If found, take the min.
-*/
-   DPU_ERROR("unsupported: lm maxwidth differs\n");
-   if (rm->lm_max_width > lm->sblk->maxwidth)
-   rm->lm_max_width = lm->sblk->maxwidth;
-   }
}
 
return 0;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index a618c0ef43db..3f68a1c0dc1e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
@@ -18,15 +18,11 @@ struct dpu_global_state;
  * @mixer_blks: array of layer mixer hardware resources
  * @ctl_blks: array of ctl hardware resources
  * @intf_blks: array of intf hardware resources
- * @lm_max_width: cached layer mixer maximum width
- * @rm_lock: resource manager mutex
  */
 struct dpu_rm {
struct dpu_hw_blk *mixer_blks[LM_MAX - LM_0];
struct dpu_hw_blk *ctl_blks[CTL_MAX - CTL_0];
struct dpu_hw_blk *intf_blks[INTF_MAX - INTF_0];
-
-   uint32_t lm_max_width;
 };
 
 struct dpu_kms;
-- 
2.30.2

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

[PATCH 13/21] drm/msm/dpu: hw_pp: make setup_dither mandatory

All supported hardware instances feature DPU_PINGPONG_DITHER option, so
just mark setup_dither as mandatory rather than optional callback.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 3 +--
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index f80694456fd6..ac03f329491d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -217,9 +217,6 @@ static void _dpu_encoder_setup_dither(struct 
dpu_hw_pingpong *hw_pp, unsigned bp
 {
struct dpu_hw_dither_cfg dither_cfg = { 0 };
 
-   if (!hw_pp->ops.setup_dither)
-   return;
-
switch (bpc) {
case 6:
dither_cfg.c0_bitdepth = 6;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 89c1123d957f..5c1ce835cf49 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -258,8 +258,7 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
c->ops.poll_timeout_wr_ptr = dpu_hw_pp_poll_timeout_wr_ptr;
c->ops.get_line_count = dpu_hw_pp_get_line_count;
 
-   if (test_bit(DPU_PINGPONG_DITHER, &features))
-   c->ops.setup_dither = dpu_hw_pp_setup_dither;
+   c->ops.setup_dither = dpu_hw_pp_setup_dither;
 };
 
 struct dpu_hw_pingpong *dpu_hw_pingpong_init(enum dpu_pingpong idx,
-- 
2.30.2

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

[PATCH 08/21] drm/msm/dpu: simplify peer LM handling

For each LM there is at max 1 peer LM which can be driven by the same
CTL, so there no need to have a mask instead of just an ID of the peer
LM.

Signed-off-by: Dmitry Baryshkov 
---
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|  2 +-
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|  4 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 30 +--
 3 files changed, 11 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index e452759c..f21f630af476 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -497,7 +497,7 @@ static const struct dpu_lm_sub_blks sdm845_lm_sblk = {
.features = _fmask, \
.sblk = _sblk, \
.pingpong = _pp, \
-   .lm_pair_mask = (1 << _lmpair), \
+   .lm_pair = _lmpair, \
.dspp = _dspp \
}
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index ea4647d21a20..08864f0addc4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -494,14 +494,14 @@ struct dpu_sspp_cfg {
  * @features   bit mask identifying sub-blocks/features
  * @sblk:  LM Sub-blocks information
  * @pingpong:  ID of connected PingPong, PINGPONG_MAX if unsupported
- * @lm_pair_mask:  Bitmask of LMs that can be controlled by same CTL
+ * @lm_pair:   ID of LM that can be controlled by same CTL
  */
 struct dpu_lm_cfg {
DPU_HW_BLK_INFO;
const struct dpu_lm_sub_blks *sblk;
u32 pingpong;
u32 dspp;
-   unsigned long lm_pair_mask;
+   unsigned long lm_pair;
 };
 
 /**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index dbcf4929810b..969286c6f104 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -150,28 +150,19 @@ static bool _dpu_rm_needs_split_display(const struct 
msm_display_topology *top)
 }
 
 /**
- * _dpu_rm_check_lm_peer - check if a mixer is a peer of the primary
+ * _dpu_rm_get_lm_peer - get the id of a mixer which is a peer of the primary
  * @rm: dpu resource manager handle
  * @primary_idx: index of primary mixer in rm->mixer_blks[]
- * @peer_idx: index of other mixer in rm->mixer_blks[]
- * Return: true if rm->mixer_blks[peer_idx] is a peer of
- *  rm->mixer_blks[primary_idx]
  */
-static bool _dpu_rm_check_lm_peer(struct dpu_rm *rm, int primary_idx,
-   int peer_idx)
+static int _dpu_rm_get_lm_peer(struct dpu_rm *rm, int primary_idx)
 {
const struct dpu_lm_cfg *prim_lm_cfg;
-   const struct dpu_lm_cfg *peer_cfg;
 
prim_lm_cfg = to_dpu_hw_mixer(rm->mixer_blks[primary_idx])->cap;
-   peer_cfg = to_dpu_hw_mixer(rm->mixer_blks[peer_idx])->cap;
 
-   if (!test_bit(peer_cfg->id, &prim_lm_cfg->lm_pair_mask)) {
-   DPU_DEBUG("lm %d not peer of lm %d\n", peer_cfg->id,
-   peer_cfg->id);
-   return false;
-   }
-   return true;
+   if (prim_lm_cfg->lm_pair >= LM_0 && prim_lm_cfg->lm_pair < LM_MAX)
+   return prim_lm_cfg->lm_pair - LM_0;
+   return -EINVAL;
 }
 
 static int _dpu_rm_reserve_lms(struct dpu_rm *rm,
@@ -205,17 +196,12 @@ static int _dpu_rm_reserve_lms(struct dpu_rm *rm,
++lm_count;
 
/* Valid primary mixer found, find matching peers */
-   for (j = i + 1; j < ARRAY_SIZE(rm->mixer_blks) &&
-   lm_count < reqs->topology.num_lm; j++) {
+   j = _dpu_rm_get_lm_peer(rm, i);
+   /* ignore the peer if there is an error or if the peer was 
already processed */
+   if (j > i) {
if (!rm->mixer_blks[j])
continue;
 
-   if (!_dpu_rm_check_lm_peer(rm, i, j)) {
-   DPU_DEBUG("lm %d not peer of lm %d\n", LM_0 + j,
-   LM_0 + i);
-   continue;
-   }
-
if (reserved_by_other(global_state->mixer_to_enc_id, j, 
enc_id)) {
DPU_DEBUG("lm %d already reserved\n", j + LM_0);
continue;
-- 
2.30.2

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

[PATCH 05/21] drm/msm/dpu: get MERGE_3D blocks directly rather than through RM

MERGE_3D blocks are not really handled by resource manager, they are
used by corresponding PP blocks directly, each merge_3d is used by two
known PP blocks. So allocate them outside of RM and use them directly.

Signed-off-by: Dmitry Baryshkov 
---
 .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c  | 11 +++---
 .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c   |  7 +++-
 .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h   |  6 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 27 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |  1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 36 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h|  8 ++---
 7 files changed, 48 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 9a69fad832cd..e77a68c2fc73 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -284,7 +284,7 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
intf_cfg.stream_sel = 0; /* Don't care value for video mode */
intf_cfg.mode_3d = dpu_encoder_helper_get_3d_blend_mode(phys_enc);
if (phys_enc->hw_pp->merge_3d)
-   intf_cfg.merge_3d = phys_enc->hw_pp->merge_3d->id;
+   intf_cfg.merge_3d = phys_enc->hw_pp->merge_3d->idx;
 
spin_lock_irqsave(phys_enc->enc_spinlock, lock_flags);
phys_enc->hw_intf->ops.setup_timing_gen(phys_enc->hw_intf,
@@ -298,11 +298,8 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
true,
phys_enc->hw_pp->idx);
 
-   if (phys_enc->hw_pp->merge_3d) {
-   struct dpu_hw_merge_3d *merge_3d = 
to_dpu_hw_merge_3d(phys_enc->hw_pp->merge_3d);
-
-   merge_3d->ops.setup_3d_mode(merge_3d, intf_cfg.mode_3d);
-   }
+   if (phys_enc->hw_pp->merge_3d)
+   
phys_enc->hw_pp->merge_3d->ops.setup_3d_mode(phys_enc->hw_pp->merge_3d, 
intf_cfg.mode_3d);
 
spin_unlock_irqrestore(phys_enc->enc_spinlock, lock_flags);
 
@@ -461,7 +458,7 @@ static void dpu_encoder_phys_vid_enable(struct 
dpu_encoder_phys *phys_enc)
 
ctl->ops.update_pending_flush_intf(ctl, phys_enc->hw_intf->idx);
if (ctl->ops.update_pending_flush_merge_3d && phys_enc->hw_pp->merge_3d)
-   ctl->ops.update_pending_flush_merge_3d(ctl, 
phys_enc->hw_pp->merge_3d->id);
+   ctl->ops.update_pending_flush_merge_3d(ctl, 
phys_enc->hw_pp->merge_3d->idx);
 
 skip_flush:
DPU_DEBUG_VIDENC(phys_enc,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 92cd724263ce..89c1123d957f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -8,6 +8,7 @@
 #include "dpu_hwio.h"
 #include "dpu_hw_catalog.h"
 #include "dpu_hw_pingpong.h"
+#include "dpu_hw_merge3d.h"
 #include "dpu_kms.h"
 #include "dpu_trace.h"
 
@@ -263,7 +264,8 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
 
 struct dpu_hw_pingpong *dpu_hw_pingpong_init(enum dpu_pingpong idx,
void __iomem *addr,
-   const struct dpu_mdss_cfg *m)
+   const struct dpu_mdss_cfg *m,
+   struct dpu_hw_merge_3d **merge_3d_blks)
 {
struct dpu_hw_pingpong *c;
const struct dpu_pingpong_cfg *cfg;
@@ -282,6 +284,9 @@ struct dpu_hw_pingpong *dpu_hw_pingpong_init(enum 
dpu_pingpong idx,
c->caps = cfg;
_setup_pingpong_ops(c, c->caps->features);
 
+   if (cfg->merge_3d && cfg->merge_3d < MERGE_3D_MAX)
+   c->merge_3d = merge_3d_blks[cfg->merge_3d - MERGE_3D_0];
+
dpu_hw_blk_init(&c->base, DPU_HW_BLK_PINGPONG, idx);
 
return c;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
index 845b9ce80e31..a9e960b8814b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
@@ -133,7 +133,7 @@ struct dpu_hw_pingpong {
/* pingpong */
enum dpu_pingpong idx;
const struct dpu_pingpong_cfg *caps;
-   struct dpu_hw_blk *merge_3d;
+   struct dpu_hw_merge_3d *merge_3d;
 
/* ops */
struct dpu_hw_pingpong_ops ops;
@@ -155,11 +155,13 @@ static inline struct dpu_hw_pingpong 
*to_dpu_hw_pingpong(struct dpu_hw_blk *hw)
  * @idx:  Pingpong index for which driver object is required
  * @addr: Mapped register io address of MDP
  * @m:Pointer to mdss catalog data
+ * @merge_3d_blks: Pointer to merge 3d blocks
  * Returns: Error code or allocated dpu_hw_pingpong context
  */
 struct dpu_hw_pingpong *dpu_hw_pingpong_init(enum dpu_pingpong idx,
void __iomem *addr,
-   const struct dpu_mdss_cfg *m);
+   const struct dpu_mdss_cfg *m,
+   struct dpu_h

[PATCH 12/21] drm/msm/dpu: call hw_dspp ops directly

Replace dpu_hw_dspp callbacks with direct functions calls.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|  6 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 15 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h | 19 ++-
 3 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 5a0a6741a431..bf3048e44001 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -462,14 +462,14 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc 
*crtc)
ctl = mixer[i].lm_ctl;
dspp = mixer[i].hw_dspp;
 
-   if (!dspp || !dspp->ops.setup_pcc)
+   if (!dspp)
continue;
 
if (!state->ctm) {
-   dspp->ops.setup_pcc(dspp, NULL);
+   dpu_hw_dspp_setup_pcc(dspp, NULL);
} else {
_dpu_crtc_get_pcc_coeff(state, &cfg);
-   dspp->ops.setup_pcc(dspp, &cfg);
+   dpu_hw_dspp_setup_pcc(dspp, &cfg);
}
 
mixer[i].flush_mask |= ctl->ops.get_bitmask_dspp(ctl,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index 977b25968f34..c17f2bf3324f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -22,7 +22,7 @@
 #define PCC_BLUE_G_OFF 0x24
 #define PCC_BLUE_B_OFF 0x30
 
-static void dpu_setup_dspp_pcc(struct dpu_hw_dspp *ctx,
+void dpu_hw_dspp_setup_pcc(struct dpu_hw_dspp *ctx,
struct dpu_hw_pcc_cfg *cfg)
 {
 
@@ -33,6 +33,11 @@ static void dpu_setup_dspp_pcc(struct dpu_hw_dspp *ctx,
return;
}
 
+   if (!test_bit(DPU_DSPP_PCC, &ctx->cap->features)) {
+   DRM_ERROR("called for wrong DSPP block\n");
+   return;
+   }
+
if (!cfg) {
DRM_DEBUG_DRIVER("disable pcc feature\n");
DPU_REG_WRITE(&ctx->hw, base, PCC_DIS);
@@ -54,13 +59,6 @@ static void dpu_setup_dspp_pcc(struct dpu_hw_dspp *ctx,
DPU_REG_WRITE(&ctx->hw, base, PCC_EN);
 }
 
-static void _setup_dspp_ops(struct dpu_hw_dspp *c,
-   unsigned long features)
-{
-   if (test_bit(DPU_DSPP_PCC, &features))
-   c->ops.setup_pcc = dpu_setup_dspp_pcc;
-}
-
 static const struct dpu_dspp_cfg *_dspp_offset(enum dpu_dspp dspp,
const struct dpu_mdss_cfg *m,
void __iomem *addr,
@@ -108,7 +106,6 @@ struct dpu_hw_dspp *dpu_hw_dspp_init(enum dpu_dspp idx,
/* Assign ops */
c->idx = idx;
c->cap = cfg;
-   _setup_dspp_ops(c, c->cap->features);
 
dpu_hw_blk_init(&c->base, DPU_HW_BLK_DSPP, idx);
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h
index 7fa189cfcb06..e712e3e4c67b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h
@@ -36,19 +36,15 @@ struct dpu_hw_pcc_cfg {
 };
 
 /**
- * struct dpu_hw_dspp_ops - interface to the dspp hardware driver functions
  * Caller must call the init function to get the dspp context for each dspp
  * Assumption is these functions will be called after clocks are enabled
  */
-struct dpu_hw_dspp_ops {
-   /**
-* setup_pcc - setup dspp pcc
-* @ctx: Pointer to dspp context
-* @cfg: Pointer to configuration
-*/
-   void (*setup_pcc)(struct dpu_hw_dspp *ctx, struct dpu_hw_pcc_cfg *cfg);
-
-};
+/**
+ * setup_pcc - setup dspp pcc
+ * @ctx: Pointer to dspp context
+ * @cfg: Pointer to configuration
+ */
+void dpu_hw_dspp_setup_pcc(struct dpu_hw_dspp *ctx, struct dpu_hw_pcc_cfg 
*cfg);
 
 /**
  * struct dpu_hw_dspp - dspp description
@@ -65,9 +61,6 @@ struct dpu_hw_dspp {
/* dspp */
int idx;
const struct dpu_dspp_cfg *cap;
-
-   /* Ops */
-   struct dpu_hw_dspp_ops ops;
 };
 
 /**
-- 
2.30.2

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

[PATCH 00/21] drm/msm/dpu: cleanup callbacks, resource manager