Re: [PATCH RESEND] gpu: drm: bridge: sii9234: convert to devm_i2c_new_dummy_device

[Andrzej Hajda]

On 08.10.2019 22:33, Wolfram Sang wrote:
> Move from the deprecated i2c_new_dummy() to devm_i2c_new_dummy_device().
> We now get an ERRPTR which we use in error handling and we can skip
> removal of the created devices.
>
> Signed-off-by: Wolfram Sang 
> ---


Applied, thx.


Rergards

Andrzej


>
> Rebased to v5.4-rc2 since last time. One of the last two users of the
> old API, so please apply soon, so I can remove the old interface. Only
> build tested.
>
>  drivers/gpu/drm/bridge/sii9234.c | 36 +++-
>  1 file changed, 12 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sii9234.c 
> b/drivers/gpu/drm/bridge/sii9234.c
> index 25d4ad8c7ad6..8a6c85693a88 100644
> --- a/drivers/gpu/drm/bridge/sii9234.c
> +++ b/drivers/gpu/drm/bridge/sii9234.c
> @@ -841,39 +841,28 @@ static int sii9234_init_resources(struct sii9234 *ctx,
>  
>   ctx->client[I2C_MHL] = client;
>  
> - ctx->client[I2C_TPI] = i2c_new_dummy(adapter, I2C_TPI_ADDR);
> - if (!ctx->client[I2C_TPI]) {
> + ctx->client[I2C_TPI] = devm_i2c_new_dummy_device(&client->dev, adapter,
> +  I2C_TPI_ADDR);
> + if (IS_ERR(ctx->client[I2C_TPI])) {
>   dev_err(ctx->dev, "failed to create TPI client\n");
> - return -ENODEV;
> + return PTR_ERR(ctx->client[I2C_TPI]);
>   }
>  
> - ctx->client[I2C_HDMI] = i2c_new_dummy(adapter, I2C_HDMI_ADDR);
> - if (!ctx->client[I2C_HDMI]) {
> + ctx->client[I2C_HDMI] = devm_i2c_new_dummy_device(&client->dev, adapter,
> +   I2C_HDMI_ADDR);
> + if (IS_ERR(ctx->client[I2C_HDMI])) {
>   dev_err(ctx->dev, "failed to create HDMI RX client\n");
> - goto fail_tpi;
> + return PTR_ERR(ctx->client[I2C_HDMI]);
>   }
>  
> - ctx->client[I2C_CBUS] = i2c_new_dummy(adapter, I2C_CBUS_ADDR);
> - if (!ctx->client[I2C_CBUS]) {
> + ctx->client[I2C_CBUS] = devm_i2c_new_dummy_device(&client->dev, adapter,
> +   I2C_CBUS_ADDR);
> + if (IS_ERR(ctx->client[I2C_CBUS])) {
>   dev_err(ctx->dev, "failed to create CBUS client\n");
> - goto fail_hdmi;
> + return PTR_ERR(ctx->client[I2C_CBUS]);
>   }
>  
>   return 0;
> -
> -fail_hdmi:
> - i2c_unregister_device(ctx->client[I2C_HDMI]);
> -fail_tpi:
> - i2c_unregister_device(ctx->client[I2C_TPI]);
> -
> - return -ENODEV;
> -}
> -
> -static void sii9234_deinit_resources(struct sii9234 *ctx)
> -{
> - i2c_unregister_device(ctx->client[I2C_CBUS]);
> - i2c_unregister_device(ctx->client[I2C_HDMI]);
> - i2c_unregister_device(ctx->client[I2C_TPI]);
>  }
>  
>  static inline struct sii9234 *bridge_to_sii9234(struct drm_bridge *bridge)
> @@ -950,7 +939,6 @@ static int sii9234_remove(struct i2c_client *client)
>  
>   sii9234_cable_out(ctx);
>   drm_bridge_remove(&ctx->bridge);
> - sii9234_deinit_resources(ctx);
>  
>   return 0;
>  }


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

Re: [PATCH RESEND] gpu: drm: bridge: analogix-anx78xx: convert to i2c_new_dummy_device

[Andrzej Hajda]

On 08.10.2019 22:31, Wolfram Sang wrote:
> Move from the deprecated i2c_new_dummy() to i2c_new_dummy_device(). We
> now get an ERRPTR which we use in error handling.
>
> Signed-off-by: Wolfram Sang 


Brian's patch is already applied.


Regards

Andrzej


> ---
>
> Rebased to v5.4-rc2 since last time. One of the last two users of the
> old API, so please apply soon, so I can remove the old interface. Only
> build tested.
>
>  drivers/gpu/drm/bridge/analogix-anx78xx.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> index 3c7cc5af735c..be7756280e41 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> @@ -1350,10 +1350,10 @@ static int anx78xx_i2c_probe(struct i2c_client 
> *client,
>  
>   /* Map slave addresses of ANX7814 */
>   for (i = 0; i < I2C_NUM_ADDRESSES; i++) {
> - anx78xx->i2c_dummy[i] = i2c_new_dummy(client->adapter,
> + anx78xx->i2c_dummy[i] = i2c_new_dummy_device(client->adapter,
>   anx78xx_i2c_addresses[i] >> 1);
> - if (!anx78xx->i2c_dummy[i]) {
> - err = -ENOMEM;
> + if (IS_ERR(anx78xx->i2c_dummy[i])) {
> + err = PTR_ERR(anx78xx->i2c_dummy[i]);
>   DRM_ERROR("Failed to reserve I2C bus %02x\n",
> anx78xx_i2c_addresses[i]);
>   goto err_unregister_i2c;

Re: [PATCH] Revert "ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware."

[Stefan Wahren]

On 09.10.19 23:42, Florian Fainelli wrote:
> On 10/9/19 2:33 PM, Stefan Wahren wrote:
>> Hi Florian,
>>
>> Am 23.09.19 um 20:56 schrieb Florian Fainelli:
>>> On 9/8/2019 8:44 AM, Stefan Wahren wrote:
 Since release of the new BCM2835 PM driver there has been several reports
 of V3D probing issues. This is caused by timeouts during powering-up the
 GRAFX PM domain:

   bcm2835-power: Timeout waiting for grafx power OK

 I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting
 force_turbo=1 in the firmware configuration. Since there are no issues
 using the firmware PM driver with the same setup, there must be an issue
 in the BCM2835 PM driver.

 Unfortunately there hasn't been much progress in identifying the root cause
 since June (mostly in the lack of documentation), so i decided to switch
 back until the issue in the BCM2835 PM driver is fixed.

 Link: https://github.com/raspberrypi/linux/issues/3046
 Fixes: e1dc2b2e1bef (" ARM: bcm283x: Switch V3D over to using the PM 
 driver instead of firmware.")
 Cc: sta...@vger.kernel.org
 Signed-off-by: Stefan Wahren 
>>> Applied to devicetree/fixes, thanks!
>> i noticed that X hangs with recent Raspbian and Linux 5.4-rc2 after this
>> revert has been applied.
>>
>> Is there a chance to drop the revert?
> I have not sent anything yet as I wanted to get some testing done on
> other platforms, so yes, I can definitively drop that particular changes
> from devicetree/fixes and not send it for a 5.4-rc3 pull request. Does
> that work for you?

Yes, definitely

Thanks Stefan

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

Re: [PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver

[Christian König]

Am 09.10.19 um 17:39 schrieb Daniel Vetter:

On Mon, Sep 30, 2019 at 03:12:53PM +0200, Christian König wrote:
[SNIP]

+static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
+{
+   struct vm_area_struct *vma = vmf->vma;
+   struct ttm_buffer_object *bo = vma->vm_private_data;
+   pgprot_t prot;
+   vm_fault_t ret;
+
+   ret = ttm_bo_vm_reserve(bo, vmf);
+   if (ret)
+   return ret;
+
+   nouveau_bo_del_io_reserve_lru(bo);

Isn't this opening up a can of worms (in theory) where a lot of concurrent
faults will all fail because they're all removed themselves from the lru,
so can't see anyone else to throw out?

Same problem really that ttm had (well still has I think for !amdgpu) with
its other lru ...

Or am I getting totally lost again here?


No, your are pretty much correct. But we are not opening up that can of 
worms, it has been here for like always.


You just need to imagine that you have two processes kicking out the 
page tables of each other before somebody had a chance to make progress. 
This will just loop forever :)


The correct solution is to not use a BO based approach at all, but 
rather a window based approach where you have an LRU of the window you 
gave out last to access something. This way you have a much larger 
number of windows you can use (4k if you use 64kB window size on a 256MB 
BAR).


This way you can safely assume that the number of windows you have 
available is always larger than the number of faults you can process at 
the same time. But that would require quite a bunch of changes for TTM 
as well as nouveau.


BTW: This is one of the reasons (additional to that it is horrible slow) 
why we never used the remapping feature on AMD hardware for Linux.


Regards,
Christian.


-Daniel



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

[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9

[bugzilla-daemon]

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

--- Comment #82 from Jaap Buurman  ---
Running the 5.3.5 Kernel, 19.2.0 Mesa and latest firmware in Arch's repository
I am also running into the same issue:

[46623.025576] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout,
signaled seq=75019, emitted seq=75022
[46623.025668] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process chromium pid 24183 thread chromium:cs0 pid 24244


This happened while switching tabs in Chromium. The umr command is not
available for me, and AFAIK the official arch repository doesn't have any
packages that provide it.

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

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Stephen Rothwell  wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/gpu/drm/i915/gt/intel_gt_pm.c: In function 'intel_gt_resume':
> drivers/gpu/drm/i915/gt/intel_gt_pm.c:183:54: error: macro "mutex_release" 
> passed 3 arguments, but takes just 2
>   183 |mutex_release(&ce->pin_mutex.dep_map, 0, _THIS_IP_);
>   |  ^
> In file included from include/linux/spinlock_types.h:18,
>  from include/linux/spinlock.h:83,
>  from include/linux/mmzone.h:8,
>  from include/linux/gfp.h:6,
>  from include/linux/slab.h:15,
>  from include/linux/io-mapping.h:10,
>  from drivers/gpu/drm/i915/i915_drv.h:36,
>  from drivers/gpu/drm/i915/gt/intel_gt_pm.c:7:
> include/linux/lockdep.h:605: note: macro "mutex_release" defined here
>   605 | #define mutex_release(l, i)   lock_release(l, i)
>   | 
> drivers/gpu/drm/i915/gt/intel_lrc.c: In function '__context_pin_release':
> drivers/gpu/drm/i915/gt/intel_lrc.c:245:51: error: macro "mutex_release" 
> passed 3 arguments, but takes just 2
>   245 |  mutex_release(&ce->pin_mutex.dep_map, 0, _RET_IP_);
>   |   ^
> In file included from include/linux/hardirq.h:6,
>  from include/linux/interrupt.h:11,
>  from drivers/gpu/drm/i915/gt/intel_lrc.c:134:
> include/linux/lockdep.h:605: note: macro "mutex_release" defined here
>   605 | #define mutex_release(l, i)   lock_release(l, i)
>   | 
> 
> Caused by commit
> 
>   5facae4f3549 ("locking/lockdep: Remove unused @nested argument from 
> lock_release()")
> 
> interacting with commits
> 
>   dffa8feb3084 ("drm/i915/perf: Assert locking for i915_init_oa_perf_state()")
>   fcde8c7eea60 ("drm/i915/selftests: Exercise potential false lite-restore")
>   b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex")
> 
> from the drm tree.
> 
> I added the following merge fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Thu, 10 Oct 2019 13:08:43 +1100
> Subject: [PATCH] drm/i915: update for mutex_release API change
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c | 2 +-
>  drivers/gpu/drm/i915/gt/intel_lrc.c   | 2 +-
>  drivers/gpu/drm/i915/i915_active.c| 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

I suspect -next will have to carry this semantic merge conflict 
resolution until the DRM tree is merged upstream.

Thanks,

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

Re: [PATCH V2 6/8] mdev: introduce virtio device and its device ops

[Jason Wang]

On 2019/9/25 上午7:06, Alex Williamson wrote:

On Tue, 24 Sep 2019 21:53:30 +0800
Jason Wang  wrote:


This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.

Signed-off-by: Jason Wang
---
  include/linux/mdev.h|   2 +
  include/linux/virtio_mdev.h | 145 
  2 files changed, 147 insertions(+)
  create mode 100644 include/linux/virtio_mdev.h

diff --git a/include/linux/mdev.h b/include/linux/mdev.h
index 3414307311f1..73ac27b3b868 100644
--- a/include/linux/mdev.h
+++ b/include/linux/mdev.h
@@ -126,6 +126,8 @@ struct mdev_device *mdev_from_dev(struct device *dev);
  
  enum {

MDEV_ID_VFIO = 1,
+   MDEV_ID_VIRTIO = 2,
+   MDEV_ID_VHOST = 3,

MDEV_ID_VHOST isn't used yet here.  Also, given the strong
interdependence between the class_id and the ops structure, we might
wand to define them in the same place.  Thanks,

Alex



Rethink about this, consider we may have more types of devices supported 
in the future, moving all device_ops to mdev.h seems unnecessary. I 
prefer to keep the device_ops into their own headers.


Thanks

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

Re: [PATCH] drm/bridge: tc358767: fix max_tu_symbol value

[Andrzej Hajda]

On 24.09.2019 15:17, Tomi Valkeinen wrote:
> max_tu_symbol was programmed to TU_SIZE_RECOMMENDED - 1, which is not
> what the spec says. The spec says:
>
> roundup ((input active video bandwidth in bytes/output active video
> bandwidth in bytes) * tu_size)
>
> It is not quite clear what the above means, but calculating
> max_tu_symbol = (input Bps / output Bps) * tu_size seems to work and
> fixes the issues seen.
>
> This fixes artifacts in some videomodes (e.g. 1024x768@60 on 2-lanes &
> 1.62Gbps was pretty bad for me).
>
> Signed-off-by: Tomi Valkeinen 


Queued to fixes.


Regards

Andrzej


> ---
>  drivers/gpu/drm/bridge/tc358767.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index 13ade28a36a8..b6aa1bd47e1d 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -677,6 +677,8 @@ static int tc_set_video_mode(struct tc_data *tc,
>   int upper_margin = mode->vtotal - mode->vsync_end;
>   int lower_margin = mode->vsync_start - mode->vdisplay;
>   int vsync_len = mode->vsync_end - mode->vsync_start;
> + u32 bits_per_pixel = 24;
> + u32 in_bw, out_bw;
>  
>   /*
>* Recommended maximum number of symbols transferred in a transfer unit:
> @@ -684,7 +686,10 @@ static int tc_set_video_mode(struct tc_data *tc,
>*  (output active video bandwidth in bytes))
>* Must be less than tu_size.
>*/
> - max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
> +
> + in_bw = mode->clock * bits_per_pixel / 8;
> + out_bw = tc->link.base.num_lanes * tc->link.base.rate;
> + max_tu_symbol = DIV_ROUND_UP(in_bw * TU_SIZE_RECOMMENDED, out_bw);
>  
>   dev_dbg(tc->dev, "set mode %dx%d\n",
>   mode->hdisplay, mode->vdisplay);


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

[PATCH 5/7] drm/meson: viu: add AFBC modules routing functions

[Neil Armstrong]

The Amlogic G12A AFBC Decoder pixel input need to be routed diferently
than the Amlogic GXM AFBC decoder, this adds support for routing the
VIU OSD1 pixel source to the AFBC "Mali Unpack" module.

This "Mali Unpack" module is also configured with a static RGBA mapping
for now until we support more pixel formats.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_viu.c | 52 +++
 drivers/gpu/drm/meson/meson_viu.h |  4 +++
 2 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/meson/meson_viu.c 
b/drivers/gpu/drm/meson/meson_viu.c
index 68cf2c2eca5f..cdd4962484db 100644
--- a/drivers/gpu/drm/meson/meson_viu.c
+++ b/drivers/gpu/drm/meson/meson_viu.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 
 #include "meson_drv.h"
 #include "meson_viu.h"
@@ -335,6 +336,57 @@ void meson_viu_osd1_reset(struct meson_drm *priv)
meson_viu_load_matrix(priv);
 }
 
+void meson_viu_g12a_enable_osd1_afbc(struct meson_drm *priv)
+{
+   /* Enable Mali AFBC Unpack */
+   writel_bits_relaxed(VIU_OSD1_MALI_UNPACK_EN,
+   VIU_OSD1_MALI_UNPACK_EN,
+   priv->io_base + _REG(VIU_OSD1_MALI_UNPACK_CTRL));
+
+   /* Setup RGBA Reordering */
+   writel_bits_relaxed(VIU_OSD1_MALI_AFBCD_A_REORDER |
+   VIU_OSD1_MALI_AFBCD_B_REORDER |
+   VIU_OSD1_MALI_AFBCD_G_REORDER |
+   VIU_OSD1_MALI_AFBCD_R_REORDER,
+   FIELD_PREP(VIU_OSD1_MALI_AFBCD_A_REORDER,
+  VIU_OSD1_MALI_REORDER_A) |
+   FIELD_PREP(VIU_OSD1_MALI_AFBCD_B_REORDER,
+  VIU_OSD1_MALI_REORDER_B) |
+   FIELD_PREP(VIU_OSD1_MALI_AFBCD_G_REORDER,
+  VIU_OSD1_MALI_REORDER_G) |
+   FIELD_PREP(VIU_OSD1_MALI_AFBCD_R_REORDER,
+  VIU_OSD1_MALI_REORDER_R),
+   priv->io_base + _REG(VIU_OSD1_MALI_UNPACK_CTRL));
+
+   /* Select AFBCD path for OSD1 */
+   writel_bits_relaxed(OSD_PATH_OSD_AXI_SEL_OSD1_AFBCD,
+   OSD_PATH_OSD_AXI_SEL_OSD1_AFBCD,
+   priv->io_base + _REG(OSD_PATH_MISC_CTRL));
+}
+
+void meson_viu_g12a_disable_osd1_afbc(struct meson_drm *priv)
+{
+   /* Disable AFBCD path for OSD1 */
+   writel_bits_relaxed(OSD_PATH_OSD_AXI_SEL_OSD1_AFBCD, 0,
+   priv->io_base + _REG(OSD_PATH_MISC_CTRL));
+
+   /* Disable AFBCD unpack */
+   writel_bits_relaxed(VIU_OSD1_MALI_UNPACK_EN, 0,
+   priv->io_base + _REG(VIU_OSD1_MALI_UNPACK_CTRL));
+}
+
+void meson_viu_gxm_enable_osd1_afbc(struct meson_drm *priv)
+{
+   writel_bits_relaxed(MALI_AFBC_MISC, FIELD_PREP(MALI_AFBC_MISC, 0x90),
+   priv->io_base + _REG(VIU_MISC_CTRL1));
+}
+
+void meson_viu_gxm_disable_osd1_afbc(struct meson_drm *priv)
+{
+   writel_bits_relaxed(MALI_AFBC_MISC, FIELD_PREP(MALI_AFBC_MISC, 0x00),
+   priv->io_base + _REG(VIU_MISC_CTRL1));
+}
+
 static inline uint32_t meson_viu_osd_burst_length_reg(uint32_t length)
 {
uint32_t val = (((length & 0x80) % 24) / 12);
diff --git a/drivers/gpu/drm/meson/meson_viu.h 
b/drivers/gpu/drm/meson/meson_viu.h
index e297772d967f..e4a2f24d7c38 100644
--- a/drivers/gpu/drm/meson/meson_viu.h
+++ b/drivers/gpu/drm/meson/meson_viu.h
@@ -63,6 +63,10 @@
 #define OSD_PENDING_STAT_CLEAN BIT(1)
 
 void meson_viu_osd1_reset(struct meson_drm *priv);
+void meson_viu_g12a_enable_osd1_afbc(struct meson_drm *priv);
+void meson_viu_g12a_disable_osd1_afbc(struct meson_drm *priv);
+void meson_viu_gxm_enable_osd1_afbc(struct meson_drm *priv);
+void meson_viu_gxm_disable_osd1_afbc(struct meson_drm *priv);
 void meson_viu_init(struct meson_drm *priv);
 
 #endif /* __MESON_VIU_H */
-- 
2.22.0

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

[PATCH 7/7] drm/meson: crtc: add OSD1 plane AFBC commit

[Neil Armstrong]

Finally, setup the VIU registers and start the AFBC decoder at each
vsync IRQ to support displaying AFBC encoded buffers on Amlogic GXM
and G12A SoCs.

Since the DRM core will stop the vsync IRQ after a few interrupts,
we need to keep the IRQ enabled while using the AFBC decoder.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_crtc.c | 79 --
 1 file changed, 74 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
b/drivers/gpu/drm/meson/meson_crtc.c
index d478fa232951..d28efd0dbf11 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -24,6 +24,7 @@
 #include "meson_venc.h"
 #include "meson_viu.h"
 #include "meson_vpp.h"
+#include "meson_osd_afbcd.h"
 
 #define MESON_G12A_VIU_OFFSET  0x5ec0
 
@@ -35,7 +36,11 @@ struct meson_crtc {
struct meson_drm *priv;
void (*enable_osd1)(struct meson_drm *priv);
void (*enable_vd1)(struct meson_drm *priv);
+   void (*enable_osd1_afbc)(struct meson_drm *priv);
+   void (*disable_osd1_afbc)(struct meson_drm *priv);
unsigned int viu_offset;
+   bool vsync_forced;
+   bool vsync_disabled;
 };
 #define to_meson_crtc(x) container_of(x, struct meson_crtc, base)
 
@@ -46,6 +51,7 @@ static int meson_crtc_enable_vblank(struct drm_crtc *crtc)
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct meson_drm *priv = meson_crtc->priv;
 
+   meson_crtc->vsync_disabled = false;
meson_venc_enable_vsync(priv);
 
return 0;
@@ -56,7 +62,10 @@ static void meson_crtc_disable_vblank(struct drm_crtc *crtc)
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct meson_drm *priv = meson_crtc->priv;
 
-   meson_venc_disable_vsync(priv);
+   if (!meson_crtc->vsync_forced) {
+   meson_crtc->vsync_disabled = true;
+   meson_venc_disable_vsync(priv);
+   }
 }
 
 static const struct drm_crtc_funcs meson_crtc_funcs = {
@@ -236,6 +245,26 @@ static void meson_crtc_enable_osd1(struct meson_drm *priv)
priv->io_base + _REG(VPP_MISC));
 }
 
+static void meson_crtc_g12a_enable_osd1_afbc(struct meson_drm *priv)
+{
+   writel_relaxed(priv->viu.osd1_blk2_cfg4,
+  priv->io_base + _REG(VIU_OSD1_BLK2_CFG_W4));
+
+   writel_bits_relaxed(OSD_MEM_LINEAR_ADDR, OSD_MEM_LINEAR_ADDR,
+   priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
+
+   writel_relaxed(priv->viu.osd1_blk1_cfg4,
+  priv->io_base + _REG(VIU_OSD1_BLK1_CFG_W4));
+
+   meson_viu_g12a_enable_osd1_afbc(priv);
+
+   writel_bits_relaxed(OSD_MEM_LINEAR_ADDR, OSD_MEM_LINEAR_ADDR,
+   priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
+
+   writel_bits_relaxed(OSD_MALI_SRC_EN, OSD_MALI_SRC_EN,
+   priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W0));
+}
+
 static void meson_g12a_crtc_enable_osd1(struct meson_drm *priv)
 {
writel_relaxed(priv->viu.osd_blend_din0_scope_h,
@@ -293,6 +322,19 @@ void meson_crtc_irq(struct meson_drm *priv)
priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W3));
writel_relaxed(priv->viu.osd1_blk0_cfg[4],
priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W4));
+
+   if (priv->viu.osd1_afbcd) {
+   if (meson_crtc->enable_osd1_afbc)
+   meson_crtc->enable_osd1_afbc(priv);
+   } else {
+   if (meson_crtc->disable_osd1_afbc)
+   meson_crtc->disable_osd1_afbc(priv);
+   if (priv->afbcd.ops) {
+   priv->afbcd.ops->reset(priv);
+   priv->afbcd.ops->disable(priv);
+   }
+   }
+
writel_relaxed(priv->viu.osd_sc_ctrl0,
priv->io_base + _REG(VPP_OSD_SC_CTRL0));
writel_relaxed(priv->viu.osd_sc_i_wh_m1,
@@ -314,15 +356,23 @@ void meson_crtc_irq(struct meson_drm *priv)
writel_relaxed(priv->viu.osd_sc_v_ctrl0,
priv->io_base + _REG(VPP_OSD_VSC_CTRL0));
 
-   meson_canvas_config(priv->canvas, priv->canvas_id_osd1,
-   priv->viu.osd1_addr, priv->viu.osd1_stride,
-   priv->viu.osd1_height, MESON_CANVAS_WRAP_NONE,
-   MESON_CANVAS_BLKMODE_LINEAR, 0);
+   if (!priv->viu.osd1_afbcd)
+   meson_canvas_config(priv->canvas, priv->canvas_id_osd1,
+   priv->viu.osd1_addr,
+   priv->viu.osd1_stride,
+   priv->viu.osd1_height,
+   MESON_CANVAS_WRAP_NONE,
+   MES

[PATCH 1/7] drm/meson: add AFBC decoder registers for GXM and G12A

[Neil Armstrong]

Add the registers used to program the ARM Framebuffer Compression decoders
used in the Amlogic GXM and G12A SoCs families.

This also adds the routing and pipeline configuration bits and registers
needed to enable AFBC support.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_registers.h | 61 +
 drivers/gpu/drm/meson/meson_viu.h   | 15 ++
 2 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/meson/meson_registers.h 
b/drivers/gpu/drm/meson/meson_registers.h
index 05fce48ceee0..69e566acb8b9 100644
--- a/drivers/gpu/drm/meson/meson_registers.h
+++ b/drivers/gpu/drm/meson/meson_registers.h
@@ -138,14 +138,19 @@
 #define VIU_ADDR_START 0x1a00
 #define VIU_ADDR_END 0x1aff
 #define VIU_SW_RESET 0x1a01
+#defineVIU_SW_RESET_OSD1_AFBCD BIT(31)
+#defineVIU_SW_RESET_G12A_OSD1_AFBCDBIT(21)
+#defineVIU_SW_RESET_G12A_AFBC_ARB  BIT(19)
 #defineVIU_SW_RESET_OSD1   BIT(0)
 #define VIU_MISC_CTRL0 0x1a06
 #defineVIU_CTRL0_VD1_AFBC_MASK 0x17
 #define VIU_MISC_CTRL1 0x1a07
+#defineMALI_AFBC_MISC  GENMASK(15, 8)
 #define D2D3_INTF_LENGTH 0x1a08
 #define D2D3_INTF_CTRL0 0x1a09
 #define VIU_OSD1_CTRL_STAT 0x1a10
 #defineVIU_OSD1_OSD_BLK_ENABLE BIT(0)
+#defineVIU_OSD1_OSD_MEM_MODE_LINEARBIT(2)
 #defineVIU_OSD1_POSTBLD_SRC_VD1(1 << 8)
 #defineVIU_OSD1_POSTBLD_SRC_VD2(2 << 8)
 #defineVIU_OSD1_POSTBLD_SRC_OSD1   (3 << 8)
@@ -181,6 +186,16 @@
 #define VIU_OSD1_FIFO_CTRL_STAT 0x1a2b
 #define VIU_OSD1_TEST_RDDATA 0x1a2c
 #define VIU_OSD1_PROT_CTRL 0x1a2e
+#define VIU_OSD1_MALI_UNPACK_CTRL 0x1a2f
+#defineVIU_OSD1_MALI_UNPACK_EN BIT(31)
+#defineVIU_OSD1_MALI_AFBCD_R_REORDER   GENMASK(15, 12)
+#defineVIU_OSD1_MALI_AFBCD_G_REORDER   GENMASK(11, 8)
+#defineVIU_OSD1_MALI_AFBCD_B_REORDER   GENMASK(7, 4)
+#defineVIU_OSD1_MALI_AFBCD_A_REORDER   GENMASK(3, 0)
+#defineVIU_OSD1_MALI_REORDER_R 1
+#defineVIU_OSD1_MALI_REORDER_G 2
+#defineVIU_OSD1_MALI_REORDER_B 3
+#defineVIU_OSD1_MALI_REORDER_A 4
 #define VIU_OSD2_CTRL_STAT 0x1a30
 #define VIU_OSD2_CTRL_STAT2 0x1a4d
 #define VIU_OSD2_COLOR_ADDR 0x1a31
@@ -1595,15 +1610,33 @@
 
 /* osd afbcd on gxtvbb */
 #define OSD1_AFBCD_ENABLE 0x31a0
+#defineOSD1_AFBCD_ID_FIFO_THRD GENMASK(15, 9)
+#defineOSD1_AFBCD_DEC_ENABLE   BIT(8)
+#defineOSD1_AFBCD_FRM_STARTBIT(0)
 #define OSD1_AFBCD_MODE 0x31a1
+#defineOSD1_AFBCD_SOFT_RESET   BIT(31)
+#defineOSD1_AFBCD_AXI_REORDER_MODE BIT(28)
+#defineOSD1_AFBCD_MIF_URGENT   GENMASK(25, 24)
+#defineOSD1_AFBCD_HOLD_LINE_NUMGENMASK(22, 16)
+#defineOSD1_AFBCD_RGBA_EXCHAN_CTRL GENMASK(15, 8)
+#defineOSD1_AFBCD_HREG_BLOCK_SPLIT BIT(6)
+#defineOSD1_AFBCD_HREG_HALF_BLOCK  BIT(5)
+#defineOSD1_AFBCD_HREG_PIXEL_PACKING_FMT   GENMASK(4, 0)
 #define OSD1_AFBCD_SIZE_IN 0x31a2
+#defineOSD1_AFBCD_HREG_VSIZE_INGENMASK(31, 16)
+#defineOSD1_AFBCD_HREG_HSIZE_INGENMASK(15, 0)
 #define OSD1_AFBCD_HDR_PTR 0x31a3
 #define OSD1_AFBCD_FRAME_PTR 0x31a4
 #define OSD1_AFBCD_CHROMA_PTR 0x31a5
 #define OSD1_AFBCD_CONV_CTRL 0x31a6
+#defineOSD1_AFBCD_CONV_LBUF_LENGENMASK(15, 0)
 #define OSD1_AFBCD_STATUS 0x31a8
 #define OSD1_AFBCD_PIXEL_HSCOPE 0x31a9
+#defineOSD1_AFBCD_DEC_PIXEL_BGN_H  GENMASK(31, 16)
+#defineOSD1_AFBCD_DEC_PIXEL_END_H  GENMASK(15, 0)
 #define OSD1_AFBCD_PIXEL_VSCOPE 0x31aa
+#defineOSD1_AFBCD_DEC_PIXEL_BGN_V  GENMASK(31, 16)
+#defineOSD1_AFBCD_DEC_PIXEL_END_V  GENMASK(15, 0)
 
 /* add for gxm and 962e dv core2 */
 #define DOLBY_CORE2A_SWAP_CTRL10x3434
@@ -1615,12 +1648,34 @@
 #define VPU_MAFBC_IRQ_CLEAR 0x3a02
 #define VPU_MAFBC_IRQ_MASK 0x3a03
 #define VPU_MAFBC_IRQ_STATUS 0x3a04
+#defineVPU_MAFBC_IRQ_SECURE_ID_ERROR   BIT(5)
+#defineVPU_MAFBC_IRQ_AXI_ERROR BIT(4)
+#defineVPU_MAFBC_IRQ_DETILING_ERRORBIT(3)
+#defineVPU_MAFBC_IRQ_DECODE_ERROR  BIT(2)
+#defineVPU_MAFBC_IRQ_CONFIGURATION_SWAPPED BIT(1)
+#defineVPU_MAFBC_IRQ_SURFACES_COMPLETEDBIT(0)
 #define VPU_MAFBC_COMMAND 0x3a05
+#defineVPU

[PATCH 6/7] drm/meson: hold 32 lines after vsync to give time for AFBC start

[Neil Armstrong]

When using an AFBC encoded frame, the AFBC Decoder must be resetted,
configured and enabled at each vsync IRQ.

To leave time for that, use the maximum lines hold time to give time
for AFBC setup and avoid visual glitches.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_viu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/meson/meson_viu.c 
b/drivers/gpu/drm/meson/meson_viu.c
index cdd4962484db..be535e23fc99 100644
--- a/drivers/gpu/drm/meson/meson_viu.c
+++ b/drivers/gpu/drm/meson/meson_viu.c
@@ -414,7 +414,7 @@ void meson_viu_init(struct meson_drm *priv)
 
/* Initialize OSD1 fifo control register */
reg = VIU_OSD_DDR_PRIORITY_URGENT |
-   VIU_OSD_HOLD_FIFO_LINES(4) |
+   VIU_OSD_HOLD_FIFO_LINES(31) |
VIU_OSD_FIFO_DEPTH_VAL(32) | /* fifo_depth_val: 32*8=256 */
VIU_OSD_WORDS_PER_BURST(4) | /* 4 words in 1 burst */
VIU_OSD_FIFO_LIMITS(2);  /* fifo_lim: 2*16=32 */
-- 
2.22.0

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

[PATCH 2/7] drm/meson: store the framebuffer width for plane commit

[Neil Armstrong]

Also store the framebuffer width in the private common struct
to be used by the AFBC decoder module driver when committing the AFBC
plane.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_drv.h   | 1 +
 drivers/gpu/drm/meson/meson_plane.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/meson/meson_drv.h 
b/drivers/gpu/drm/meson/meson_drv.h
index 820d07bdd42a..3287282450a9 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -52,6 +52,7 @@ struct meson_drm {
uint32_t osd1_addr;
uint32_t osd1_stride;
uint32_t osd1_height;
+   uint32_t osd1_width;
uint32_t osd_sc_ctrl0;
uint32_t osd_sc_i_wh_m1;
uint32_t osd_sc_o_h_start_end;
diff --git a/drivers/gpu/drm/meson/meson_plane.c 
b/drivers/gpu/drm/meson/meson_plane.c
index ed543227b00d..5e798c276037 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -305,6 +305,7 @@ static void meson_plane_atomic_update(struct drm_plane 
*plane,
priv->viu.osd1_addr = gem->paddr;
priv->viu.osd1_stride = fb->pitches[0];
priv->viu.osd1_height = fb->height;
+   priv->viu.osd1_width = fb->width;
 
if (!meson_plane->enabled) {
/* Reset OSD1 before enabling it on GXL+ SoCs */
-- 
2.22.0

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

[PATCH 0/7] drm/meson: add AFBC support

[Neil Armstrong]

This adds support for the ARM Framebuffer Compression decoders found
in the Amlogic GXM and G12A SoCs.

The Amlogic GXM and G12A AFBC decoder are totally different, the GXM only
handling only the AFBC v1.0 modes and the G12A decoder handling the
AFBC v1.2 modes.

The G12A AFBC decoder is an external IP integrated in the video pipeline,
and the GXM AFBC decoder seems to the an Amlogic custom decoder more
tighly integrated in the video pipeline.

The GXM AFBC decoder can handle only one AFBC plane for 2 available
OSD planes available in HW, and the G12A AFBC decoder can handle up
to 4 AFBC planes for up to 3 OSD planes available in HW.

The Amlogic GXM supports 16x16 SPARSE and 16x16 SPLIT AFBC buffers up
to 4k.

On the other side, for G12A SPLIT is mandatory in 16x16 block mode, but
for 4k modes 32x8+SPLIT AFBC buffers is manadatory for performances reasons.

The Amlogic GXM and G12A AFBC decoders are integrated very differently.

The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.

On the other side, the Amlogic G12A AFBC decoder seems to be an external
IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
feeding the OSD1 VIU pixel input.
This uses a weird "0x100" internal HW physical address on both
sides to transfer the pixels.

For Amlogic GXM, the supported pixel formats are the same as the normal
linear OSD1 mode.

On the other side, Amlogic added support for all AFBC v1.2 formats for
the G12A AFBC integration.

For testing, the only available AFBC buffer generation is the Android
Yukawa Dvalin Android Mali blobs found at [1].

Both SoCs has been tested using buffers generated under AOSP, but only
G12A was tested using a runtime stream of AFBC buffers, GXM was only
tested using static buffers loaded from files.

[1] 
https://android.googlesource.com/device/amlogic/yukawa/+/refs/heads/master/gpu/

Neil Armstrong (7):
  drm/meson: add AFBC decoder registers for GXM and G12A
  drm/meson: store the framebuffer width for plane commit
  drm/meson: Add AFBCD module driver
  drm/meson: plane: add support for AFBC mode for OSD1 plane
  drm/meson: viu: add AFBC modules routing functions
  drm/meson: hold 32 lines after vsync to give time for AFBC start
  drm/meson: crtc: add OSD1 plane AFBC commit

 drivers/gpu/drm/meson/Makefile  |   1 +
 drivers/gpu/drm/meson/meson_crtc.c  |  81 +-
 drivers/gpu/drm/meson/meson_drv.c   |  38 ++-
 drivers/gpu/drm/meson/meson_drv.h   |  17 ++
 drivers/gpu/drm/meson/meson_osd_afbcd.c | 370 
 drivers/gpu/drm/meson/meson_osd_afbcd.h |  28 ++
 drivers/gpu/drm/meson/meson_plane.c | 216 --
 drivers/gpu/drm/meson/meson_registers.h |  61 
 drivers/gpu/drm/meson/meson_viu.c   |  54 +++-
 drivers/gpu/drm/meson/meson_viu.h   |  19 ++
 10 files changed, 842 insertions(+), 43 deletions(-)
 create mode 100644 drivers/gpu/drm/meson/meson_osd_afbcd.c
 create mode 100644 drivers/gpu/drm/meson/meson_osd_afbcd.h

-- 
2.22.0

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

[PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane

[Neil Armstrong]

This adds all the OSD configuration plumbing to support the AFBC decoders
path to display of the OSD1 plane.

The Amlogic GXM and G12A AFBC decoders are integrated very differently.

The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.

On the other side, the Amlogic G12A AFBC decoder seems to be an external
IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
feeding the OSD1 VIU pixel input.
This uses a weird "0x100" internal HW physical address on both
sides to transfer the pixels.

For Amlogic GXM, the supported pixel formats are the same as the normal
linear OSD1 mode.

On the other side, Amlogic added support for all AFBC v1.2 formats for
the G12A AFBC integration.

For simplicity, we stick to the already supported formats for now.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_crtc.c  |   2 +
 drivers/gpu/drm/meson/meson_drv.h   |   4 +
 drivers/gpu/drm/meson/meson_plane.c | 215 
 3 files changed, 190 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
b/drivers/gpu/drm/meson/meson_crtc.c
index 57ae1c13d1e6..d478fa232951 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
writel_relaxed(priv->viu.osd1_ctrl_stat,
priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
+   writel_relaxed(priv->viu.osd1_ctrl_stat2,
+   priv->io_base + _REG(VIU_OSD1_CTRL_STAT2));
writel_relaxed(priv->viu.osd1_blk0_cfg[0],
priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W0));
writel_relaxed(priv->viu.osd1_blk0_cfg[1],
diff --git a/drivers/gpu/drm/meson/meson_drv.h 
b/drivers/gpu/drm/meson/meson_drv.h
index 60f13c6f34e5..de25349be8aa 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -53,8 +53,12 @@ struct meson_drm {
bool osd1_enabled;
bool osd1_interlace;
bool osd1_commit;
+   bool osd1_afbcd;
uint32_t osd1_ctrl_stat;
+   uint32_t osd1_ctrl_stat2;
uint32_t osd1_blk0_cfg[5];
+   uint32_t osd1_blk1_cfg4;
+   uint32_t osd1_blk2_cfg4;
uint32_t osd1_addr;
uint32_t osd1_stride;
uint32_t osd1_height;
diff --git a/drivers/gpu/drm/meson/meson_plane.c 
b/drivers/gpu/drm/meson/meson_plane.c
index 5e798c276037..412941aa8402 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -23,6 +23,7 @@
 #include "meson_plane.h"
 #include "meson_registers.h"
 #include "meson_viu.h"
+#include "meson_osd_afbcd.h"
 
 /* OSD_SCI_WH_M1 */
 #define SCI_WH_M1_W(w) FIELD_PREP(GENMASK(28, 16), w)
@@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane *plane,
   false, true);
 }
 
+#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |  \
+  AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |\
+  AFBC_FORMAT_MOD_YTR |\
+  AFBC_FORMAT_MOD_SPARSE | \
+  AFBC_FORMAT_MOD_SPLIT)
+
 /* Takes a fixed 16.16 number and converts it to integer. */
 static inline int64_t fixed16_to_int(int64_t value)
 {
return value >> 16;
 }
 
+static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv)
+{
+   u32 line_stride = 0;
+
+   switch (priv->afbcd.format) {
+   case DRM_FORMAT_RGB565:
+   line_stride = ((priv->viu.osd1_width << 4) + 127) >> 7;
+   break;
+   case DRM_FORMAT_RGB888:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ABGR:
+   line_stride = ((priv->viu.osd1_width << 5) + 127) >> 7;
+   break;
+   }
+
+   return ((line_stride + 1) >> 1) << 1;
+}
+
 static void meson_plane_atomic_update(struct drm_plane *plane,
  struct drm_plane_state *old_state)
 {
@@ -126,57 +153,88 @@ static void meson_plane_atomic_update(struct drm_plane 
*plane,
 */
spin_lock_irqsave(&priv->drm->event_lock, flags);
 
+   /* Check if AFBC decoder is required for this buffer */
+   if ((meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXM) ||
+meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) &&
+   fb->modifier & DRM_FORMAT_MOD_ARM_AFBC(MESON_MOD_AFBC_VALID_BITS))
+   priv->viu.osd1_afbcd = true;
+   else
+   priv->viu.osd1_afbcd = false;
+
/* Enable OSD and BL

[PATCH 3/7] drm/meson: Add AFBCD module driver

[Neil Armstrong]

This adds the driver for the ARM Framebuffer Compression decoders found
in the Amlogic GXM and G12A SoCs.

The Amlogic GXM and G12A AFBC decoder are totally different, the GXM only
handling only the AFBC v1.0 modes and the G12A decoder handling the
AFBC v1.2 modes.

The G12A AFBC decoder is an external IP integrated in the video pipeline,
and the GXM AFBC decoder seems to the an Amlogic custom decoder more
tighly integrated in the video pipeline.

The GXM AFBC decoder can handle only one AFBC plane for 2 available
OSD planes available in HW, and the G12A AFBC decoder can handle up
to 4 AFBC planes for up to 3 OSD planes available in HW.

The Amlogic GXM supports 16x16 SPARSE and 16x16 SPLIT AFBC buffers up
to 4k.

On the other side, for G12A SPLIT is mandatory in 16x16 block mode, but
for 4k modes 32x8+SPLIT AFBC buffers is manadatory for performances reasons.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/Makefile  |   1 +
 drivers/gpu/drm/meson/meson_drv.c   |  38 ++-
 drivers/gpu/drm/meson/meson_drv.h   |  12 +
 drivers/gpu/drm/meson/meson_osd_afbcd.c | 370 
 drivers/gpu/drm/meson/meson_osd_afbcd.h |  28 ++
 5 files changed, 443 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/meson/meson_osd_afbcd.c
 create mode 100644 drivers/gpu/drm/meson/meson_osd_afbcd.h

diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index c389e2399133..b1fa055aaed3 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o meson_venc_cvbs.o
 meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o 
meson_overlay.o
+meson-drm-y += meson_osd_afbcd.o
 
 obj-$(CONFIG_DRM_MESON) += meson-drm.o
 obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index a24f8dec5adc..0f31e70bb94f 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -28,6 +28,7 @@
 #include "meson_drv.h"
 #include "meson_overlay.h"
 #include "meson_plane.h"
+#include "meson_osd_afbcd.h"
 #include "meson_registers.h"
 #include "meson_venc_cvbs.h"
 #include "meson_viu.h"
@@ -184,6 +185,7 @@ static void meson_remove_framebuffers(void)
 static int meson_drv_bind_master(struct device *dev, bool has_components)
 {
struct platform_device *pdev = to_platform_device(dev);
+   const struct meson_drm_match_data *match;
struct meson_drm *priv;
struct drm_device *drm;
struct resource *res;
@@ -196,6 +198,10 @@ static int meson_drv_bind_master(struct device *dev, bool 
has_components)
return -ENODEV;
}
 
+   match = of_device_get_match_data(dev);
+   if (!match)
+   return -ENODEV;
+
drm = drm_dev_alloc(&meson_driver, dev);
if (IS_ERR(drm))
return PTR_ERR(drm);
@@ -208,8 +214,8 @@ static int meson_drv_bind_master(struct device *dev, bool 
has_components)
drm->dev_private = priv;
priv->drm = drm;
priv->dev = dev;
-
-   priv->compat = (enum vpu_compatible)of_device_get_match_data(priv->dev);
+   priv->compat = match->compat;
+   priv->afbcd.ops = match->afbcd_ops;
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "vpu");
regs = devm_ioremap_resource(dev, res);
@@ -289,6 +295,8 @@ static int meson_drv_bind_master(struct device *dev, bool 
has_components)
meson_venc_init(priv);
meson_vpp_init(priv);
meson_viu_init(priv);
+   if (priv->afbcd.ops)
+   priv->afbcd.ops->init(priv);
 
/* Encoder Initialization */
 
@@ -454,15 +462,33 @@ static int meson_drv_probe(struct platform_device *pdev)
return 0;
 };
 
+static struct meson_drm_match_data meson_drm_gxbb_data = {
+   .compat = VPU_COMPATIBLE_GXBB,
+};
+
+static struct meson_drm_match_data meson_drm_gxl_data = {
+   .compat = VPU_COMPATIBLE_GXL,
+};
+
+static struct meson_drm_match_data meson_drm_gxm_data = {
+   .compat = VPU_COMPATIBLE_GXM,
+   .afbcd_ops = &meson_afbcd_gxm_ops,
+};
+
+static struct meson_drm_match_data meson_drm_g12a_data = {
+   .compat = VPU_COMPATIBLE_G12A,
+   .afbcd_ops = &meson_afbcd_g12a_ops,
+};
+
 static const struct of_device_id dt_match[] = {
{ .compatible = "amlogic,meson-gxbb-vpu",
- .data   = (void *)VPU_COMPATIBLE_GXBB },
+ .data   = (void *)&meson_drm_gxbb_data },
{ .compatible = "amlogic,meson-gxl-vpu",
- .data   = (void *)VPU_COMPATIBLE_GXL },
+ .data   = (void *)&meson_drm_gxl_data },
{ .compatible = "amlogic,meson-gxm-vpu",
- .data   = (void *)VPU_COMPATIBLE_GXM },
+ .data   = (void *)&meson_drm_gxm_data },
{ .compatible = "amlogic,meson-g12a-vpu",
- .data   = (void *)VPU_COMPATIBLE_G1

Re: [PATCH] drm/bridge: tc358767: fix max_tu_symbol value

[Tomi Valkeinen]

Hi Andrzej,

On 10/10/2019 12:19, Andrzej Hajda wrote:

On 24.09.2019 15:17, Tomi Valkeinen wrote:

max_tu_symbol was programmed to TU_SIZE_RECOMMENDED - 1, which is not
what the spec says. The spec says:

roundup ((input active video bandwidth in bytes/output active video
bandwidth in bytes) * tu_size)

It is not quite clear what the above means, but calculating
max_tu_symbol = (input Bps / output Bps) * tu_size seems to work and
fixes the issues seen.

This fixes artifacts in some videomodes (e.g. 1024x768@60 on 2-lanes &
1.62Gbps was pretty bad for me).

Signed-off-by: Tomi Valkeinen 



Queued to fixes.


If you didn't push this yet, can you drop it for now? This works for all 
the video modes I have tested, but as I mention above, the calculation 
is really not quite clear to me.


I've sent queries to Toshiba about how to calculate this, and I'm hoping 
to get a reply soon.


If you did push it already, that's fine too, as it does improve things.

 Tomi

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

[PATCH v2 0/2] Add initial support for slimport anx7625

[Xin Ji]

Hi all,

The following series add initial support for the Slimport ANX7625 transmitter, a
ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device.

This is the initial version, any mistakes, please let me know, I will fix it in
the next series.

Thanks,
Xin


Xin Ji (2):
  dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
  drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver

 .../bindings/display/bridge/anx7625.yaml   |   96 +
 drivers/gpu/drm/bridge/Makefile|2 +-
 drivers/gpu/drm/bridge/analogix/Kconfig|6 +
 drivers/gpu/drm/bridge/analogix/Makefile   |1 +
 drivers/gpu/drm/bridge/analogix/anx7625.c  | 2155 
 drivers/gpu/drm/bridge/analogix/anx7625.h  |  406 
 6 files changed, 2665 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/anx7625.yaml
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h

-- 
2.7.4

RE: [Intel-gfx] [PATCH 8/8] drm/print: introduce new struct drm_device based logging macros

[Jani Nikula]

On Wed, 09 Oct 2019, "Ruhl, Michael J"  wrote:
>>-Original Message-
>>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>>Jani Nikula

>>+/* Helper for struct drm_device based logging. */
>>+#define __drm_printk(drm, level, type, fmt, ...) \
>>+ dev_##level##type(drm->dev, "[drm] " fmt, ##__VA_ARGS__)
>
> In the past, I have been able to do a:
>
> #undef pr_fmt
> #define pr_fmt(fmt) "[myinfo here] " fmt
>
> And have the "[myinfo here]" portion show up the output.
>
> Is it possible that you might be able to use this instead of "[drm] " fmt?
>
> I think that the this will be the same result, but might be more in
> line with the printk interface?

pr_fmt is only used by the pr_() macros in printk.h that use
printk. This does not use printk.

BR,
Jani.

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

[PATCH v4 4/8] drm/omap: cleanup OMAP_BO flags

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

Reorder OMAP_BO flags and improve the comments.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 include/uapi/drm/omap_drm.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
index 1fccffef9e27..d8ee2f840697 100644
--- a/include/uapi/drm/omap_drm.h
+++ b/include/uapi/drm/omap_drm.h
@@ -38,19 +38,20 @@ struct drm_omap_param {
__u64 value;/* in (set_param), out (get_param) */
 };
 
-#define OMAP_BO_SCANOUT0x0001  /* scanout capable 
(phys contiguous) */
-#define OMAP_BO_CACHE_MASK 0x0006  /* cache type mask, see cache 
modes */
-#define OMAP_BO_TILED_MASK 0x0f00  /* tiled mapping mask, see 
tiled modes */
+/* Scanout buffer, consumable by DSS */
+#define OMAP_BO_SCANOUT0x0001
 
-/* cache modes */
-#define OMAP_BO_CACHED 0x  /* default */
-#define OMAP_BO_WC 0x0002  /* write-combine */
-#define OMAP_BO_UNCACHED   0x0004  /* strongly-ordered (uncached) 
*/
+/* Buffer CPU caching mode: cached, write-combining or uncached. */
+#define OMAP_BO_CACHED 0x
+#define OMAP_BO_WC 0x0002
+#define OMAP_BO_UNCACHED   0x0004
+#define OMAP_BO_CACHE_MASK 0x0006
 
-/* tiled modes */
+/* Use TILER for the buffer. The TILER container unit can be 8, 16 or 32 bits. 
*/
 #define OMAP_BO_TILED_80x0100
 #define OMAP_BO_TILED_16   0x0200
 #define OMAP_BO_TILED_32   0x0300
+#define OMAP_BO_TILED_MASK 0x0f00
 #define OMAP_BO_TILED  (OMAP_BO_TILED_8 | OMAP_BO_TILED_16 | 
OMAP_BO_TILED_32)
 
 union omap_gem_size {
-- 
2.17.1

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

[PATCH v4 7/8] drm/omap: add omap_gem_validate_flags()

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

Add a helper function omap_gem_validate_flags() which validates the
omap_bo flags passed from the userspace.

Also drop the dev_err() message, as the userspace can cause that at
will.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 40 ++
 1 file changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 5c4cdf618347..cafa9d0bf3c1 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1131,6 +1131,38 @@ void omap_gem_free_object(struct drm_gem_object *obj)
kfree(omap_obj);
 }
 
+static bool omap_gem_validate_flags(struct drm_device *dev, u32 flags)
+{
+   struct omap_drm_private *priv = dev->dev_private;
+
+   switch (flags & OMAP_BO_CACHE_MASK) {
+   case OMAP_BO_CACHED:
+   case OMAP_BO_WC:
+   case OMAP_BO_CACHE_MASK:
+   break;
+
+   default:
+   return false;
+   }
+
+   if (flags & OMAP_BO_TILED_MASK) {
+   if (!priv->usergart)
+   return false;
+
+   switch (flags & OMAP_BO_TILED_MASK) {
+   case OMAP_BO_TILED_8:
+   case OMAP_BO_TILED_16:
+   case OMAP_BO_TILED_32:
+   break;
+
+   default:
+   return false;
+   }
+   }
+
+   return true;
+}
+
 /* GEM buffer object constructor */
 struct drm_gem_object *omap_gem_new(struct drm_device *dev,
union omap_gem_size gsize, u32 flags)
@@ -1142,13 +1174,11 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
size_t size;
int ret;
 
+   if (!omap_gem_validate_flags(dev, flags))
+   return NULL;
+
/* Validate the flags and compute the memory and cache flags. */
if (flags & OMAP_BO_TILED_MASK) {
-   if (!priv->usergart) {
-   dev_err(dev->dev, "Tiled buffers require DMM\n");
-   return NULL;
-   }
-
/*
 * Tiled buffers are always shmem paged backed. When they are
 * scanned out, they are remapped into DMM/TILER.
-- 
2.17.1

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

[PATCH v4 5/8] drm/omap: remove OMAP_BO_TILED define

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

OMAP_BO_TILED does not make sense, as OMAP_BO_TILED_* values are not
bitmasks but normal values. As we already have OMAP_BO_TILED_MASK for
the mask, we can remove OMAP_BO_TILED and use OMAP_BO_TILED_MASK
instead.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.h  |  2 +-
 drivers/gpu/drm/omapdrm/omap_fb.c |  6 +++---
 drivers/gpu/drm/omapdrm/omap_gem.c| 18 +-
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  2 +-
 include/uapi/drm/omap_drm.h   |  1 -
 5 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
index 835e6654fa82..43c1d096b021 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
@@ -113,7 +113,7 @@ extern struct platform_driver omap_dmm_driver;
 /* GEM bo flags -> tiler fmt */
 static inline enum tiler_fmt gem2fmt(u32 flags)
 {
-   switch (flags & OMAP_BO_TILED) {
+   switch (flags & OMAP_BO_TILED_MASK) {
case OMAP_BO_TILED_8:
return TILFMT_8BIT;
case OMAP_BO_TILED_16:
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 7e89e5cb4068..8daf46fd5e05 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -95,7 +95,7 @@ static u32 get_linear_addr(struct drm_framebuffer *fb,
 
 bool omap_framebuffer_supports_rotation(struct drm_framebuffer *fb)
 {
-   return omap_gem_flags(fb->obj[0]) & OMAP_BO_TILED;
+   return omap_gem_flags(fb->obj[0]) & OMAP_BO_TILED_MASK;
 }
 
 /* Note: DRM rotates counter-clockwise, TILER & DSS rotates clockwise */
@@ -154,7 +154,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb,
x = state->src_x >> 16;
y = state->src_y >> 16;
 
-   if (omap_gem_flags(fb->obj[0]) & OMAP_BO_TILED) {
+   if (omap_gem_flags(fb->obj[0]) & OMAP_BO_TILED_MASK) {
u32 w = state->src_w >> 16;
u32 h = state->src_h >> 16;
 
@@ -212,7 +212,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb,
plane = &omap_fb->planes[1];
 
if (info->rotation_type == OMAP_DSS_ROT_TILER) {
-   WARN_ON(!(omap_gem_flags(fb->obj[1]) & OMAP_BO_TILED));
+   WARN_ON(!(omap_gem_flags(fb->obj[1]) & 
OMAP_BO_TILED_MASK));
omap_gem_rotated_dma_addr(fb->obj[1], orient, x/2, y/2,
  &info->p_uv_addr);
} else {
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 2ac83cdbb15a..07dba300ec07 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -194,7 +194,7 @@ static void omap_gem_evict(struct drm_gem_object *obj)
struct omap_gem_object *omap_obj = to_omap_bo(obj);
struct omap_drm_private *priv = obj->dev->dev_private;
 
-   if (omap_obj->flags & OMAP_BO_TILED) {
+   if (omap_obj->flags & OMAP_BO_TILED_MASK) {
enum tiler_fmt fmt = gem2fmt(omap_obj->flags);
int i;
 
@@ -322,7 +322,7 @@ size_t omap_gem_mmap_size(struct drm_gem_object *obj)
struct omap_gem_object *omap_obj = to_omap_bo(obj);
size_t size = obj->size;
 
-   if (omap_obj->flags & OMAP_BO_TILED) {
+   if (omap_obj->flags & OMAP_BO_TILED_MASK) {
/* for tiled buffers, the virtual size has stride rounded up
 * to 4kb.. (to hide the fact that row n+1 might start 16kb or
 * 32kb later!).  But we don't back the entire buffer with
@@ -511,7 +511,7 @@ vm_fault_t omap_gem_fault(struct vm_fault *vmf)
 * probably trigger put_pages()?
 */
 
-   if (omap_obj->flags & OMAP_BO_TILED)
+   if (omap_obj->flags & OMAP_BO_TILED_MASK)
ret = omap_gem_fault_2d(obj, vma, vmf);
else
ret = omap_gem_fault_1d(obj, vma, vmf);
@@ -784,7 +784,7 @@ int omap_gem_pin(struct drm_gem_object *obj, dma_addr_t 
*dma_addr)
if (ret)
goto fail;
 
-   if (omap_obj->flags & OMAP_BO_TILED) {
+   if (omap_obj->flags & OMAP_BO_TILED_MASK) {
block = tiler_reserve_2d(fmt,
omap_obj->width,
omap_obj->height, 0);
@@ -890,7 +890,7 @@ int omap_gem_rotated_dma_addr(struct drm_gem_object *obj, 
u32 orient,
mutex_lock(&omap_obj->lock);
 
if ((refcount_read(&omap_obj->dma_addr_cnt) > 0) && omap_obj->block &&
-   (omap_obj->flags & OMAP_BO_TILED)) {
+   (omap_obj->flags & OMAP_BO_TILED_MASK)) {
*dma_addr = tiler_tsptr(omap_obj->block, orient, x, y);
 

[PATCH v4 0/8] drm/omap: OMAP_BO flags

[Jean-Jacques Hiblot]

A first version of this work had been sent by Tomi Valkeinen in may 2017 
(https://www.spinics.net/lists/dri-devel/msg140663.html).

This series adds a few new OMAP_BO flags to help the userspace manage
situations where it needs to use lots of buffers, and would currently run
out of TILER space. The TILER space is limited to mapping 128MB at any given
time and some applications might need more.

This seres is also the opportunity to do some cleanup in the flags and
improve the comments describing them.

The user-space patches for libdrm, although ready, haven't been posted yet.
It will be be done when this series have been discussed and hopefully in
the process of getting merged.

JJ

changes in v4:
- fixed incremental build issue introduced by patch #1 and later fixed by
  patch #2.
- Added my reviewed-by to Tomis's patch

changes in v3:
- rebase on top of v5.4-rc2
- Document omap_gem_new() and the new flags using the kernel-doc format

changes in v2:
- fixed build error that crept in during rebase before sending (sorry
  about that)
- rework the refcount part a bit.

Jean-Jacques Hiblot (1):
  drm/omap: use refcount API to track the number of users of dma_addr

Tomi Valkeinen (7):
  drm/omap: add omap_gem_unpin_locked()
  drm/omap: accept NULL for dma_addr in omap_gem_pin
  drm/omap: cleanup OMAP_BO flags
  drm/omap: remove OMAP_BO_TILED define
  drm/omap: cleanup OMAP_BO_SCANOUT use
  drm/omap: add omap_gem_validate_flags()
  drm/omap: add OMAP_BO flags to affect buffer allocation

 drivers/gpu/drm/omapdrm/omap_dmm_tiler.h  |   2 +-
 drivers/gpu/drm/omapdrm/omap_fb.c |   6 +-
 drivers/gpu/drm/omapdrm/omap_gem.c| 191 --
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |   2 +-
 include/uapi/drm/omap_drm.h   |  27 ++-
 5 files changed, 164 insertions(+), 64 deletions(-)

-- 
2.17.1

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

[PATCH v4 8/8] drm/omap: add OMAP_BO flags to affect buffer allocation

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

On SoCs with DMM/TILER, we have two ways to allocate buffers: normal
dma_alloc or via DMM (which basically functions as an IOMMU). DMM can
map 128MB at a time, and we only map the DMM buffers when they are used
(i.e. not at alloc time). If DMM is present, omapdrm always uses DMM.

There are use cases that require lots of big buffers that are being used
at the same time by different IPs. At the moment the userspace has a
hard maximum of 128MB.

This patch adds three new flags that can be used by the userspace to
solve the situation:

OMAP_BO_MEM_CONTIG: The driver will use dma_alloc to get the memory.
This can be used to avoid DMM if the userspace knows it needs more than
128M of memory at the same time.

OMAP_BO_MEM_DMM: The driver will use DMM to get the memory. There's not
much use for this flag at the moment, as on platforms with DMM it is
used by default, but it's here for completeness.

OMAP_BO_MEM_PIN: The driver will pin the memory at alloc time, and keep
it pinned. This can be used to 1) get an error at alloc time if DMM
space is full, and 2) get rid of the constant pin/unpin operations which
may have some effect on performance.

If none of the flags are given, the behavior is the same as currently.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 54 --
 include/uapi/drm/omap_drm.h|  9 +
 2 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index cafa9d0bf3c1..9af2c9a4bd28 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1095,6 +1095,9 @@ void omap_gem_free_object(struct drm_gem_object *obj)
list_del(&omap_obj->mm_list);
mutex_unlock(&priv->list_lock);
 
+   if (omap_obj->flags & OMAP_BO_MEM_PIN)
+   omap_gem_unpin_locked(obj);
+
/*
 * We own the sole reference to the object at this point, but to keep
 * lockdep happy, we must still take the omap_obj_lock to call
@@ -1145,10 +1148,19 @@ static bool omap_gem_validate_flags(struct drm_device 
*dev, u32 flags)
return false;
}
 
+   if ((flags & OMAP_BO_MEM_CONTIG) && (flags & OMAP_BO_MEM_DMM))
+   return false;
+
+   if ((flags & OMAP_BO_MEM_DMM) && !priv->usergart)
+   return false;
+
if (flags & OMAP_BO_TILED_MASK) {
if (!priv->usergart)
return false;
 
+   if (flags & OMAP_BO_MEM_CONTIG)
+   return false;
+
switch (flags & OMAP_BO_TILED_MASK) {
case OMAP_BO_TILED_8:
case OMAP_BO_TILED_16:
@@ -1163,7 +1175,34 @@ static bool omap_gem_validate_flags(struct drm_device 
*dev, u32 flags)
return true;
 }
 
-/* GEM buffer object constructor */
+/**
+ * omap_gem_new() - Create a new GEM buffer
+ * @dev: The DRM device
+ * @gsize: The requested size for the GEM buffer. If the buffer is tiled
+ * (2D buffer), the size is a pair of values: height and width
+ * expressed in pixels. If the buffers is not tiled, it is expressed
+ * in bytes.
+ * @flags: Flags give additionnal information about the allocation:
+ * OMAP_BO_TILED_x: use the TILER (2D buffers). The TILER container
+ *  unit can be 8, 16 or 32 bits. Cache is always disabled for
+ *  tiled buffers.
+ * OMAP_BO_SCANOUT: Scannout buffer, consummable by the DSS
+ * OMAP_BO_CACHED: Buffer CPU caching mode: cached
+ * OMAP_BO_WC: Buffer CPU caching mode: write-combined
+ * OMAP_BO_UNCACHED: Buffer CPU caching mode: uncached
+ * OMAP_BO_MEM_CONTIG: The driver will use dma_alloc to get the memory.
+ *  This can be used to avoid DMM if the userspace knows it needs
+ *  more than 128M of memory at the same time.
+ * OMAP_BO_MEM_DMM: The driver will use DMM to get the memory. There's
+ *  not much use for this flag at the moment, as on platforms with
+ *  DMM it is used by default, but it's here for completeness.
+ * OMAP_BO_MEM_PIN: The driver will pin the memory at alloc time, and
+ *  keep it pinned. This can be used to 1) get an error at alloc
+ *  time if DMM space is full, and 2) get rid of the constant
+ *  pin/unpin operations which may have some effect on performance.
+ *
+ * Return: The GEM buffer or NULL if the allocation failed
+ */
 struct drm_gem_object *omap_gem_new(struct drm_device *dev,
union omap_gem_size gsize, u32 flags)
 {
@@ -1191,7 +1230,8 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
 */
flags &= ~(OMAP_BO_CACHED|OMAP_BO_WC|OMAP_BO_UNCACHED);
flags |= tiler_get_cpu_cache_flags();
-   } else if ((flags & OMAP_BO_SCANOUT) &&

[PATCH v4 6/8] drm/omap: cleanup OMAP_BO_SCANOUT use

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

omap_gem_new() has a comment about OMAP_BO_SCANOUT which does not make
sense. Also, for the TILER case, we drop OMAP_BO_SCANOUT flag for some
reason.

It's not clear what the original purpose of OMAP_BO_SCANOUT is, but
presuming it means "scanout buffer, something that can be consumed by
DSS", this patch cleans up the above issues.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 07dba300ec07..5c4cdf618347 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1153,7 +1153,6 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
 * Tiled buffers are always shmem paged backed. When they are
 * scanned out, they are remapped into DMM/TILER.
 */
-   flags &= ~OMAP_BO_SCANOUT;
flags |= OMAP_BO_MEM_SHMEM;
 
/*
@@ -1164,9 +1163,8 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
flags |= tiler_get_cpu_cache_flags();
} else if ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm) {
/*
-* OMAP_BO_SCANOUT hints that the buffer doesn't need to be
-* tiled. However, to lower the pressure on memory allocation,
-* use contiguous memory only if no TILER is available.
+* If we don't have DMM, we must allocate scanout buffers
+* from contiguous DMA memory.
 */
flags |= OMAP_BO_MEM_DMA_API;
} else if (!(flags & OMAP_BO_MEM_DMABUF)) {
-- 
2.17.1

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

[PATCH v4 1/8] drm/omap: use refcount API to track the number of users of dma_addr

[Jean-Jacques Hiblot]

This would give us a WARN_ON() if the pin/unpin calls are unbalanced.

Proposed-by: Laurent Pinchart 
Signed-off-by: Jean-Jacques Hiblot 
Reviewed-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 44 +++---
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 37378dbc50d0..5c97ff810b5d 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -65,7 +65,7 @@ struct omap_gem_object {
/**
 * # of users of dma_addr
 */
-   u32 dma_addr_cnt;
+   refcount_t dma_addr_cnt;
 
/**
 * If the buffer has been imported from a dmabuf the OMAP_DB_DMABUF flag
@@ -771,13 +771,15 @@ int omap_gem_pin(struct drm_gem_object *obj, dma_addr_t 
*dma_addr)
mutex_lock(&omap_obj->lock);
 
if (!omap_gem_is_contiguous(omap_obj) && priv->has_dmm) {
-   if (omap_obj->dma_addr_cnt == 0) {
+   if (refcount_read(&omap_obj->dma_addr_cnt) == 0) {
u32 npages = obj->size >> PAGE_SHIFT;
enum tiler_fmt fmt = gem2fmt(omap_obj->flags);
struct tiler_block *block;
 
BUG_ON(omap_obj->block);
 
+   refcount_set(&omap_obj->dma_addr_cnt, 1);
+
ret = omap_gem_attach_pages(obj);
if (ret)
goto fail;
@@ -811,10 +813,10 @@ int omap_gem_pin(struct drm_gem_object *obj, dma_addr_t 
*dma_addr)
omap_obj->block = block;
 
DBG("got dma address: %pad", &omap_obj->dma_addr);
+   } else {
+   refcount_inc(&omap_obj->dma_addr_cnt);
}
 
-   omap_obj->dma_addr_cnt++;
-
*dma_addr = omap_obj->dma_addr;
} else if (omap_gem_is_contiguous(omap_obj)) {
*dma_addr = omap_obj->dma_addr;
@@ -844,22 +846,19 @@ void omap_gem_unpin(struct drm_gem_object *obj)
 
mutex_lock(&omap_obj->lock);
 
-   if (omap_obj->dma_addr_cnt > 0) {
-   omap_obj->dma_addr_cnt--;
-   if (omap_obj->dma_addr_cnt == 0) {
-   ret = tiler_unpin(omap_obj->block);
-   if (ret) {
-   dev_err(obj->dev->dev,
-   "could not unpin pages: %d\n", ret);
-   }
-   ret = tiler_release(omap_obj->block);
-   if (ret) {
-   dev_err(obj->dev->dev,
-   "could not release unmap: %d\n", ret);
-   }
-   omap_obj->dma_addr = 0;
-   omap_obj->block = NULL;
+   if (refcount_dec_and_test(&omap_obj->dma_addr_cnt)) {
+   ret = tiler_unpin(omap_obj->block);
+   if (ret) {
+   dev_err(obj->dev->dev,
+   "could not unpin pages: %d\n", ret);
+   }
+   ret = tiler_release(omap_obj->block);
+   if (ret) {
+   dev_err(obj->dev->dev,
+   "could not release unmap: %d\n", ret);
}
+   omap_obj->dma_addr = 0;
+   omap_obj->block = NULL;
}
 
mutex_unlock(&omap_obj->lock);
@@ -877,7 +876,7 @@ int omap_gem_rotated_dma_addr(struct drm_gem_object *obj, 
u32 orient,
 
mutex_lock(&omap_obj->lock);
 
-   if ((omap_obj->dma_addr_cnt > 0) && omap_obj->block &&
+   if ((refcount_read(&omap_obj->dma_addr_cnt) > 0) && omap_obj->block &&
(omap_obj->flags & OMAP_BO_TILED)) {
*dma_addr = tiler_tsptr(omap_obj->block, orient, x, y);
ret = 0;
@@ -1028,7 +1027,8 @@ void omap_gem_describe(struct drm_gem_object *obj, struct 
seq_file *m)
 
seq_printf(m, "%08x: %2d (%2d) %08llx %pad (%2d) %p %4d",
omap_obj->flags, obj->name, kref_read(&obj->refcount),
-   off, &omap_obj->dma_addr, omap_obj->dma_addr_cnt,
+   off, &omap_obj->dma_addr,
+   refcount_read(&omap_obj->dma_addr_cnt),
omap_obj->vaddr, omap_obj->roll);
 
if (omap_obj->flags & OMAP_BO_TILED) {
@@ -1091,7 +1091,7 @@ void omap_gem_free_object(struct drm_gem_object *obj)
mutex_lock(&omap_obj->lock);
 
/* The object should not be pinned. */
-   WARN_ON(omap_obj->dma_addr_cnt > 0);
+   WARN_ON(refcount_read(&omap_obj->dma_addr_cnt) > 0);
 
if (omap_obj->pages) {
if (omap_obj->flags & OMAP_BO_MEM_DMABUF)
-- 
2.17.1

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

[PATCH v4 3/8] drm/omap: accept NULL for dma_addr in omap_gem_pin

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

Allow NULL to be passed in 'dma_addr' for omap_gem_pin(), in case the
caller does not need the dma_addr.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 3071e815da73..2ac83cdbb15a 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -817,9 +817,11 @@ int omap_gem_pin(struct drm_gem_object *obj, dma_addr_t 
*dma_addr)
refcount_inc(&omap_obj->dma_addr_cnt);
}
 
-   *dma_addr = omap_obj->dma_addr;
+   if (dma_addr)
+   *dma_addr = omap_obj->dma_addr;
} else if (omap_gem_is_contiguous(omap_obj)) {
-   *dma_addr = omap_obj->dma_addr;
+   if (dma_addr)
+   *dma_addr = omap_obj->dma_addr;
} else {
ret = -EINVAL;
goto fail;
-- 
2.17.1

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

[PATCH v4 2/8] drm/omap: add omap_gem_unpin_locked()

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

Add omap_gem_unpin_locked() which is a version of omap_gem_unpin() that
expects the caller to hold the omap_obj lock.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 5c97ff810b5d..3071e815da73 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -832,20 +832,16 @@ int omap_gem_pin(struct drm_gem_object *obj, dma_addr_t 
*dma_addr)
 }
 
 /**
- * omap_gem_unpin() - Unpin a GEM object from memory
+ * omap_gem_unpin_locked() - Unpin a GEM object from memory
  * @obj: the GEM object
  *
- * Unpin the given GEM object previously pinned with omap_gem_pin(). Pins are
- * reference-counted, the actualy unpin will only be performed when the number
- * of calls to this function matches the number of calls to omap_gem_pin().
+ * omap_gem_unpin() without locking.
  */
-void omap_gem_unpin(struct drm_gem_object *obj)
+static void omap_gem_unpin_locked(struct drm_gem_object *obj)
 {
struct omap_gem_object *omap_obj = to_omap_bo(obj);
int ret;
 
-   mutex_lock(&omap_obj->lock);
-
if (refcount_dec_and_test(&omap_obj->dma_addr_cnt)) {
ret = tiler_unpin(omap_obj->block);
if (ret) {
@@ -860,7 +856,22 @@ void omap_gem_unpin(struct drm_gem_object *obj)
omap_obj->dma_addr = 0;
omap_obj->block = NULL;
}
+}
 
+/**
+ * omap_gem_unpin() - Unpin a GEM object from memory
+ * @obj: the GEM object
+ *
+ * Unpin the given GEM object previously pinned with omap_gem_pin(). Pins are
+ * reference-counted, the actual unpin will only be performed when the number
+ * of calls to this function matches the number of calls to omap_gem_pin().
+ */
+void omap_gem_unpin(struct drm_gem_object *obj)
+{
+   struct omap_gem_object *omap_obj = to_omap_bo(obj);
+
+   mutex_lock(&omap_obj->lock);
+   omap_gem_unpin_locked(obj);
mutex_unlock(&omap_obj->lock);
 }
 
-- 
2.17.1

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

[PATCH v2 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver

[Xin Ji]

The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.

The ANX7625 can support both USB Type-C PD feature and MIPI DSI/DPI
to DP feature. This driver only enabled MIPI DSI/DPI to DP feature.

Signed-off-by: Xin Ji 
---
 drivers/gpu/drm/bridge/Makefile   |2 +-
 drivers/gpu/drm/bridge/analogix/Kconfig   |6 +
 drivers/gpu/drm/bridge/analogix/Makefile  |1 +
 drivers/gpu/drm/bridge/analogix/anx7625.c | 2155 +
 drivers/gpu/drm/bridge/analogix/anx7625.h |  406 ++
 5 files changed, 2569 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h

diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..bcd388a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -12,8 +12,8 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
 obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
-obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
 obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-y += analogix/
 obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
b/drivers/gpu/drm/bridge/analogix/Kconfig
index e930ff9..b2f127e 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -2,3 +2,9 @@
 config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config ANALOGIX_ANX7625
+   tristate "Analogix MIPI to DP interface support"
+   help
+   ANX7625 is an ultra-low power 4K mobile HD transmitter designed
+   for portable devices. It converts MIPI/DPI to DisplayPort1.3 4K.
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
b/drivers/gpu/drm/bridge/analogix/Makefile
index fdbf3fd..8a52867 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_ANALOGIX_ANX7625) += anx7625.o
 analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
new file mode 100644
index 000..4328c4e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -0,0 +1,2155 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "anx7625.h"
+
+/*
+ * there is a sync issue while access I2C register between AP(CPU) and
+ * internal firmware(OCM), to avoid the race condition, AP should access
+ * the reserved slave address before slave address occurs changes.
+ */
+static int i2c_access_workaround(struct anx7625_data *ctx,
+struct i2c_client *client)
+{
+   u8 offset;
+   struct device *dev = &client->dev;
+   int ret;
+
+   if (client == ctx->last_client)
+   return 0;
+
+   ctx->last_client = client;
+
+   if (client == ctx->i2c.tcpc_client)
+   offset = RSVD_00_ADDR;
+   else if (client == ctx->i2c.tx_p0_client)
+   offset = RSVD_D1_ADDR;
+   else if (client == ctx->i2c.tx_p1_client)
+   offset = RSVD_60_ADDR;
+   else if (client == ctx->i2c.rx_p0_client)
+   offset = RSVD_39_ADDR;
+   else if (client == ctx->i2c.rx_p1_client)
+   offset = RSVD_7F_ADDR;
+   else
+   offset = RSVD_00_ADDR;
+
+   ret = i2c_smbus_write_byte_data(client, offset, 0x00);
+   if (ret < 0)
+   DRM_DEV_ERROR(dev,
+ "failed to access i2c id=%x\n:%x",
+ client->addr, offset);
+
+   return ret;
+}
+
+static int anx7625_reg_read(struct anx7625_data *ctx,
+   struct i2c_client *client, u8 reg_addr)
+{
+   int ret;
+   struct device *dev = &client->dev;
+
+   i2c_access_workaround(ctx, client);
+
+   ret = i2c_smbus_read_byte_data(client, reg_addr);
+   if (ret < 0)
+   DRM_DEV_ERROR(dev, "read i2c failed id=%x:%x\n",
+ client->addr, reg_addr);
+
+   return ret;
+}
+
+static int anx7625_reg_block_read(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 reg_addr, u8 len, u8 *buf)
+{
+   int ret;
+   str

Re: [PATCH v4 0/8] drm/omap: OMAP_BO flags

[Tomi Valkeinen]

Hi JJ,

On 10/10/2019 12:34, Jean-Jacques Hiblot wrote:

A first version of this work had been sent by Tomi Valkeinen in may 2017
(https://www.spinics.net/lists/dri-devel/msg140663.html).

This series adds a few new OMAP_BO flags to help the userspace manage
situations where it needs to use lots of buffers, and would currently run
out of TILER space. The TILER space is limited to mapping 128MB at any given
time and some applications might need more.

This seres is also the opportunity to do some cleanup in the flags and
improve the comments describing them.

The user-space patches for libdrm, although ready, haven't been posted yet.
It will be be done when this series have been discussed and hopefully in
the process of getting merged.

JJ

changes in v4:
- fixed incremental build issue introduced by patch #1 and later fixed by
   patch #2.
- Added my reviewed-by to Tomis's patch


This doesn't compile on top of 5.4 as the last patch is using 
dma_free_writecombine instead of dma_free_wc. In v3, it was correct, but 
the changenotes don't mention the change.


Was there some mix up? What kernel are your patches based on?

 Tomi

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

Re: [PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver

[Daniel Vetter]

On Thu, Oct 10, 2019 at 9:54 AM Christian König
 wrote:
>
> Am 09.10.19 um 17:39 schrieb Daniel Vetter:
> > On Mon, Sep 30, 2019 at 03:12:53PM +0200, Christian König wrote:
> > [SNIP]
> >> +static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
> >> +{
> >> +struct vm_area_struct *vma = vmf->vma;
> >> +struct ttm_buffer_object *bo = vma->vm_private_data;
> >> +pgprot_t prot;
> >> +vm_fault_t ret;
> >> +
> >> +ret = ttm_bo_vm_reserve(bo, vmf);
> >> +if (ret)
> >> +return ret;
> >> +
> >> +nouveau_bo_del_io_reserve_lru(bo);
> > Isn't this opening up a can of worms (in theory) where a lot of concurrent
> > faults will all fail because they're all removed themselves from the lru,
> > so can't see anyone else to throw out?
> >
> > Same problem really that ttm had (well still has I think for !amdgpu) with
> > its other lru ...
> >
> > Or am I getting totally lost again here?
>
> No, your are pretty much correct. But we are not opening up that can of
> worms, it has been here for like always.

Ah, I didn't check the ttm-based version closely enough to convince
myself it has the same problem.

> You just need to imagine that you have two processes kicking out the
> page tables of each other before somebody had a chance to make progress.
> This will just loop forever :)
>
> The correct solution is to not use a BO based approach at all, but
> rather a window based approach where you have an LRU of the window you
> gave out last to access something. This way you have a much larger
> number of windows you can use (4k if you use 64kB window size on a 256MB
> BAR).
>
> This way you can safely assume that the number of windows you have
> available is always larger than the number of faults you can process at
> the same time. But that would require quite a bunch of changes for TTM
> as well as nouveau.

Yeah we do that on i915 since a while, buffers became way too big.
Somewhat tricky on older hw where we also detile, there the window we
pick needs to be at least a full tile row.

> BTW: This is one of the reasons (additional to that it is horrible slow)
> why we never used the remapping feature on AMD hardware for Linux.

Not feeling like a full r-b, and you definitely want someone to test
this on nouveau, but at leat

Acked-by: Daniel Vetter 

for the series.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver

[Dan Carpenter]

This code is *so* much nicer than before.  I hope you feel good about
the changes.  It makes me happy to look at this code now.

On Thu, Oct 10, 2019 at 09:34:19AM +, Xin Ji wrote:
> +static int edid_read(struct anx7625_data *ctx,
> +  u8 offset, u8 *pblock_buf)
> +{
> + int ret, cnt;
> + struct device *dev = &ctx->client->dev;
> +
> + for (cnt = 0; cnt < EDID_TRY_CNT; cnt++) {
> + sp_tx_aux_wr(ctx, offset);
> + /* set I2C read com 0x01 mot = 0 and read 16 bytes */
> + ret = sp_tx_aux_rd(ctx, 0xf1);
> +
> + if (ret) {
> + sp_tx_rst_aux(ctx);
> + DRM_DEV_DEBUG_DRIVER(dev, "edid read failed, reset!\n");
> + cnt++;

I don't think you should increment cnt.  It's just a counter.

> + } else {
> + ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
> +  AP_AUX_BUFF_START,
> +  MAX_DPCD_BUFFER_SIZE,
> +  pblock_buf);
> + if (!ret)
> + break;
> + }
> + }
> +
> + if (cnt == EDID_TRY_CNT)

And it could mean that "cnt > EDID_TRY_CNT".

> + return -EIO;
> +
> + return 0;
> +}
> +
> +static int segments_edid_read(struct anx7625_data *ctx,
> +   u8 segment, u8 *buf, u8 offset)
> +{
> + u8 cnt;
> + int ret;
> + struct device *dev = &ctx->client->dev;
> +
> + /* write address only */
> + ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> + AP_AUX_ADDR_7_0, 0x30);
> + ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> +  AP_AUX_COMMAND, 0x04);
> + ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> +  AP_AUX_CTRL_STATUS,
> +  AP_AUX_CTRL_ADDRONLY | AP_AUX_CTRL_OP_EN);
> +
> + ret |= wait_aux_op_finish(ctx);
> + /* write segment address */
> + ret |= sp_tx_aux_wr(ctx, segment);
> + /* data read */
> + ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> +  AP_AUX_ADDR_7_0, 0x50);
> + if (ret) {
> + DRM_ERROR("IO error : aux initial failed.\n");
> + return ret;
> + }
> +
> + for (cnt = 0; cnt < EDID_TRY_CNT; cnt++) {
> + sp_tx_aux_wr(ctx, offset);
> + /* set I2C read com 0x01 mot = 0 and read 16 bytes */
> + ret = sp_tx_aux_rd(ctx, 0xf1);
> +
> + if (ret) {
> + ret = sp_tx_rst_aux(ctx);
> + DRM_DEV_ERROR(dev, "segment read failed, reset!\n");
> + cnt++;

Same.

> + } else {
> + ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
> +  AP_AUX_BUFF_START,
> +  MAX_DPCD_BUFFER_SIZE, buf);
> + if (!ret)
> + break;
> + }
> + }
> +
> + if (cnt == EDID_TRY_CNT)
> + return -EIO;
> +
> + return 0;
> +}

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

Re: [pull] amdgpu/kfd, radeon, ttm drm-next-5.5

[Daniel Vetter]

On Thu, Oct 10, 2019 at 6:17 AM Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> New stuff for 5.5.  There's an export of a cgroup function that
> Tejun acked for merging through the drm tree. kfd uses it to handle
> permissions in containers since there is only one /dev/kfd.
>
> The following changes since commit 9a60b2990d6c2b7ab935fe0a5cc274de67d98bed:
>
>   Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux 
> into drm-next (2019-09-06 16:58:10 +1000)
>
> are available in the Git repository at:
>
>   git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.5-2019-10-09
>
> for you to fetch changes up to 1cd4d9eead73c004d08a58536dc726bd172eaaec:
>
>   drm/amdkfd: update for drmP.h removal (2019-10-09 12:04:48 -0500)
>
> 
> drm-next-5.5-2019-10-09:
>
> amdgpu:
> - Additional RAS enablement for vega20
> - RAS page retirement and bad page storage in EEPROM
> - No GPU reset with unrecoverable RAS errors
> - Reserve vram for page tables rather than trying to evict
> - Fix issues with GPU reset and xgmi hives
> - DC i2c over aux fixes
> - Direct submission for clears, PTE/PDE updates
> - Improvements to help support recoverable GPU page faults
> - Silence harmless SAD block messages
> - Clean up code for creating a bo at a fixed location
> - Initial DC HDCP support
> - Lots of documentation fixes
> - GPU reset for renoir
> - Add IH clockgating support for soc15 asics
> - Powerplay improvements
> - DC MST cleanups
> - Add support for MSI-X
> - Misc cleanups and bug fixes
>
> amdkfd:
> - Query KFD device info by asic type rather than pci ids
> - Add navi14 support
> - Add renoir support
> - Add navi12 support
> - gfx10 trap handler improvements
> - pasid cleanups
> - Check against device cgroup
>
> ttm:
> - Return -EBUSY with pipelining with no_gpu_wait
>
> radeon:
> - Silence harmless SAD block messages
>
> device_cgroup:
> - Export devcgroup_check_permission
>
> 
> Aaron Liu (4):
>   drm/amd/display: update renoir_ip_offset.h
>   drm/amdgpu: disable stutter mode for renoir
>   drm/amdgpu: remove program of lbpw for renoir
>   Revert "drm/amdgpu: disable stutter mode for renoir"
>
> Adam Zerella (1):
>   docs: drm/amdgpu: Resolve build warnings
>
> Alex Deucher (20):
>   drm/amdgpu/irq: check if nbio funcs exist
>   drm/amdgpu/vm: fix documentation for amdgpu_vm_bo_param
>   drm/amdgpu/ras: use GPU PAGE_SIZE/SHIFT for reserving pages
>   drm/amdgpu/psp: flush HDP write fifo after submitting cmds to the psp
>   drm/amdgpu/psp: invalidate the hdp read cache before reading the psp 
> response
>   drm/amdgpu: flag navi12 and 14 as experimental for 5.4
>   drm/amdgpu: fix documentation for amdgpu_gem_prime_export
>   drm/amdgpu/mn: fix documentation for amdgpu_mn_read_lock
>   drm/amdgpu/vm: fix up documentation in amdgpu_vm.c
>   drm/amdgpu/ih: fix documentation in amdgpu_irq_dispatch
>   drm/amdgpu: fix documentation for amdgpu_pm.c
>   drm/amdgpu/ras: fix and update the documentation for RAS
>   drm/amdgpu/display: fix 64 bit divide
>   drm/amdgpu/display: include slab.h in dcn21_resource.c
>   drm/amdgpu/atomfirmware: use proper index for querying vram type (v3)
>   drm/amdgpu/atomfirmware: simplify the interface to get vram info
>   drm/amdgpu: don't increment vram lost if we are in hibernation
>   drm/amdgpu: improve MSI-X handling (v3)
>   drm/amdgpu: move amdgpu_device_get_job_timeout_settings
>   drm/amdkfd: fix the build when CIK support is disabled
>
> Allen Pais (1):
>   drm/amdkfd: fix a potential NULL pointer dereference (v2)
>
> Alvin Lee (1):
>   drm/amd/display: Don't allocate payloads if link lost
>
> Andrey Grodzovsky (11):
>   drm/amdgpu: Fix bugs in amdgpu_device_gpu_recover in XGMI case.
>   drm/amdgpu: Avoid HW GPU reset for RAS.
>   dmr/amdgpu: Add system auto reboot to RAS.
>   drm/amdgpu: Add smu lock around in pp_smu_i2c_bus_access
>   drm/amdgpu: Remove clock gating restore.
>   drm/madgpu: Fix EEPROM Checksum calculation.
>   drm/amdgpu: Avoid RAS recovery init when no RAS support.
>   drm/amdgpu: Add amdgpu_ras_eeprom_reset_table
>   drm/amdgpu: Allow to reset to EERPOM table.
>   drm/amdgpu: Fix mutex lock from atomic context.
>   drm/amdgpu:Fix EEPROM checksum calculation.
>
> Anthony Koo (2):
>   drm/amd/display: 3.2.49
>   drm/amd/display: set minimum abm backlight level
>
> Aric Cyr (4):
>   drm/amd/display: 3.2.50
>   drm/amd/display: 3.2.51
>   drm/amd/display: 3.2.51.1
>   drm/amd/display: Improve LFC behaviour
>
> Arnd Bergmann (4):
>   drm/amd/display: hide an unused variable
>   drm/amdgpu: make pmu support optional, again
>   drm/amdgpu: hide another #warning
>   drm/amdgpu: display_mode_vba_21: remove uint typedef
>
> Austin Kim (1):
> 

Re: [PATCH v2 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver

[Dan Carpenter]

On Thu, Oct 10, 2019 at 12:53:15PM +0300, Dan Carpenter wrote:
> This code is *so* much nicer than before.  I hope you feel good about
> the changes.  It makes me happy to look at this code now.
> 
> On Thu, Oct 10, 2019 at 09:34:19AM +, Xin Ji wrote:
> > +static int edid_read(struct anx7625_data *ctx,
> > +u8 offset, u8 *pblock_buf)
> > +{
> > +   int ret, cnt;
> > +   struct device *dev = &ctx->client->dev;
> > +
> > +   for (cnt = 0; cnt < EDID_TRY_CNT; cnt++) {
  ^

> > +   sp_tx_aux_wr(ctx, offset);
> > +   /* set I2C read com 0x01 mot = 0 and read 16 bytes */
> > +   ret = sp_tx_aux_rd(ctx, 0xf1);
> > +
> > +   if (ret) {
> > +   sp_tx_rst_aux(ctx);
> > +   DRM_DEV_DEBUG_DRIVER(dev, "edid read failed, reset!\n");
> > +   cnt++;
^

I mean that it's incremented twice, yeah?

regards,
dan carpenter

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

Re: [PATCH v2 1/4] drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support

[Andrzej Hajda]

On 07.10.2019 21:21, Jonas Karlman wrote:
> Add support for configuring Dynamic Range and Mastering InfoFrame from
> the hdr_output_metadata connector property.
>
> This patch adds a use_drm_infoframe flag to dw_hdmi_plat_data that platform
> drivers use to signal when Dynamic Range and Mastering infoframes is 
> supported.
> This flag is needed because Amlogic GXBB and GXL report same DW-HDMI version,
> and only GXL support DRM InfoFrame.
>
> These changes were based on work done by Zheng Yang 
> to support DRM InfoFrame on the Rockchip 4.4 BSP kernel at [1] and [2]
>
> [1] https://github.com/rockchip-linux/kernel/tree/develop-4.4
> [2] 
> https://github.com/rockchip-linux/kernel/commit/d1943fde81ff41d7cca87f4a42f03992e90bddd5
>
> Cc: Zheng Yang 
> Signed-off-by: Jonas Karlman 
> Reviewed-by: Neil Armstrong 


Reviewed-by: Andrzej Hajda 


Neil, since you want to take care of patch3/4, will you take care of the
whole patchset?


 --
Regards
Andrzej


> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 81 +++
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 37 +++
>  include/drm/bridge/dw_hdmi.h  |  1 +
>  3 files changed, 119 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index a15fbf71b9d7..fdc29869d75a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -25,6 +25,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1743,6 +1744,41 @@ static void 
> hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
>   HDMI_FC_DATAUTO0_VSD_MASK);
>  }
>  
> +static void hdmi_config_drm_infoframe(struct dw_hdmi *hdmi)
> +{
> + const struct drm_connector_state *conn_state = hdmi->connector.state;
> + struct hdmi_drm_infoframe frame;
> + u8 buffer[30];
> + ssize_t err;
> + int i;
> +
> + if (!hdmi->plat_data->use_drm_infoframe)
> + return;
> +
> + hdmi_modb(hdmi, HDMI_FC_PACKET_TX_EN_DRM_DISABLE,
> +   HDMI_FC_PACKET_TX_EN_DRM_MASK, HDMI_FC_PACKET_TX_EN);
> +
> + err = drm_hdmi_infoframe_set_hdr_metadata(&frame, conn_state);
> + if (err < 0)
> + return;
> +
> + err = hdmi_drm_infoframe_pack(&frame, buffer, sizeof(buffer));
> + if (err < 0) {
> + dev_err(hdmi->dev, "Failed to pack drm infoframe: %zd\n", err);
> + return;
> + }
> +
> + hdmi_writeb(hdmi, frame.version, HDMI_FC_DRM_HB0);
> + hdmi_writeb(hdmi, frame.length, HDMI_FC_DRM_HB1);
> +
> + for (i = 0; i < frame.length; i++)
> + hdmi_writeb(hdmi, buffer[4 + i], HDMI_FC_DRM_PB0 + i);
> +
> + hdmi_writeb(hdmi, 1, HDMI_FC_DRM_UP);
> + hdmi_modb(hdmi, HDMI_FC_PACKET_TX_EN_DRM_ENABLE,
> +   HDMI_FC_PACKET_TX_EN_DRM_MASK, HDMI_FC_PACKET_TX_EN);
> +}
> +
>  static void hdmi_av_composer(struct dw_hdmi *hdmi,
>const struct drm_display_mode *mode)
>  {
> @@ -2064,6 +2100,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>   /* HDMI Initialization Step F - Configure AVI InfoFrame */
>   hdmi_config_AVI(hdmi, mode);
>   hdmi_config_vendor_specific_infoframe(hdmi, mode);
> + hdmi_config_drm_infoframe(hdmi);
>   } else {
>   dev_dbg(hdmi->dev, "%s DVI mode\n", __func__);
>   }
> @@ -2230,6 +2267,45 @@ static int dw_hdmi_connector_get_modes(struct 
> drm_connector *connector)
>   return ret;
>  }
>  
> +static bool hdr_metadata_equal(const struct drm_connector_state *old_state,
> +const struct drm_connector_state *new_state)
> +{
> + struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
> + struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
> +
> + if (!old_blob || !new_blob)
> + return old_blob == new_blob;
> +
> + if (old_blob->length != new_blob->length)
> + return false;
> +
> + return !memcmp(old_blob->data, new_blob->data, old_blob->length);
> +}
> +
> +static int dw_hdmi_connector_atomic_check(struct drm_connector *connector,
> +   struct drm_atomic_state *state)
> +{
> + struct drm_connector_state *old_state =
> + drm_atomic_get_old_connector_state(state, connector);
> + struct drm_connector_state *new_state =
> + drm_atomic_get_new_connector_state(state, connector);
> + struct drm_crtc *crtc = new_state->crtc;
> + struct drm_crtc_state *crtc_state;
> +
> + if (!crtc)
> + return 0;
> +
> + if (!hdr_metadata_equal(old_state, new_state)) {
> + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> +
> + crtc_state->mode_changed = true;
> + }

[PATCH] drm/komeda: Don't flush inactive pipes

[Mihail Atanassov]

HW doesn't allow flushing inactive pipes and raises an MERR interrupt
if you try to do so. Stop triggering the MERR interrupt in the
middle of a commit by calling drm_atomic_helper_commit_planes
with the ACTIVE_ONLY flag.

Signed-off-by: Mihail Atanassov 
---
 drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 8820ce15ce37..ae274902ff92 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -82,7 +82,8 @@ static void komeda_kms_commit_tail(struct drm_atomic_state 
*old_state)
 
drm_atomic_helper_commit_modeset_disables(dev, old_state);
 
-   drm_atomic_helper_commit_planes(dev, old_state, 0);
+   drm_atomic_helper_commit_planes(dev, old_state,
+   DRM_PLANE_COMMIT_ACTIVE_ONLY);
 
drm_atomic_helper_commit_modeset_enables(dev, old_state);
 
-- 
2.23.0

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

Re: [PATCH v10 4/6] dts-bindings: leds: Document the naming requirement for LED properties

[Jean-Jacques Hiblot]

On 09/10/2019 21:26, Rob Herring wrote:

On Wed, Oct 09, 2019 at 10:51:25AM +0200, Jean-Jacques Hiblot wrote:

LED properties must be named "leds" in the same way that PWM, clocks or
PHY properties are names respectively "pwms", "clocks" and "phys".

Cc: devicet...@vger.kernel.org
Signed-off-by: Jean-Jacques Hiblot 
---
  .../devicetree/bindings/leds/common.txt   | 20 ---
  1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/common.txt 
b/Documentation/devicetree/bindings/leds/common.txt
index 9fa6f9795d50..31b8c1f68d27 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -10,6 +10,9 @@ can influence the way of the LED device initialization, the 
LED components
  have to be tightly coupled with the LED device binding. They are represented
  by child nodes of the parent LED device binding.
  
+LED properties should be named "leds". The exact meaning of each leds

+property must be documented in the device tree binding for each device.
+

This is worded oddly. The property is 'leds' and it is always a list of
phandles to LED device nodes. It is present in an LED consumer device.


How about:

[...]

A LED consumer device has a 'leds' property. This property is always a list
of phandles to LED nodes (child node of a LED device node).

led_device {
    ...

    led0: led@0 {
        ...
    };

    led1: led@1 {
        ...
    };
};

consumer {
    ...
    leds = , ;
};



  
  Optional properties for child nodes:

  - led-sources : List of device current outputs the LED is connected to. The
@@ -165,9 +168,20 @@ led-controller@30 {
function-enumerator = <2>;
  };
  
-led@3 {

+bkl_led0: led@3 {
reg = <3>;
-   function = LED_FUNCTION_INDICATOR;
-   function-enumerator = <3>;
+   function = LED_FUNCTION_BACKLIGHT;
+   function-enumerator = <1>;
  };
+
+bkl_led1: led@4 {
+   reg = <4>;
+   function = LED_FUNCTION_BACKLIGHT;
+   function-enumerator = <2>;
+};
+};
+
+
+backlight@40 {

Either needs 'reg' or the unit-address dropped.


+   leds = <&bkl_led0> , <&bkl_led1>;

drop the space^


  };
--
2.17.1


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

Re: [PATCH v2 1/4] drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support

[Neil Armstrong]

On 10/10/2019 12:12, Andrzej Hajda wrote:
> On 07.10.2019 21:21, Jonas Karlman wrote:
>> Add support for configuring Dynamic Range and Mastering InfoFrame from
>> the hdr_output_metadata connector property.
>>
>> This patch adds a use_drm_infoframe flag to dw_hdmi_plat_data that platform
>> drivers use to signal when Dynamic Range and Mastering infoframes is 
>> supported.
>> This flag is needed because Amlogic GXBB and GXL report same DW-HDMI version,
>> and only GXL support DRM InfoFrame.
>>
>> These changes were based on work done by Zheng Yang 
>> 
>> to support DRM InfoFrame on the Rockchip 4.4 BSP kernel at [1] and [2]
>>
>> [1] https://github.com/rockchip-linux/kernel/tree/develop-4.4
>> [2] 
>> https://github.com/rockchip-linux/kernel/commit/d1943fde81ff41d7cca87f4a42f03992e90bddd5
>>
>> Cc: Zheng Yang 
>> Signed-off-by: Jonas Karlman 
>> Reviewed-by: Neil Armstrong 
> 
> 
> Reviewed-by: Andrzej Hajda 
> 
> 
> Neil, since you want to take care of patch3/4, will you take care of the
> whole patchset?

Sure,

Neil

> 
> 
>  --
> Regards
> Andrzej
> 
> 
>> ---
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 81 +++
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 37 +++
>>  include/drm/bridge/dw_hdmi.h  |  1 +
>>  3 files changed, 119 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index a15fbf71b9d7..fdc29869d75a 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -25,6 +25,7 @@
>>  #include 
>>  
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -1743,6 +1744,41 @@ static void 
>> hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
>>  HDMI_FC_DATAUTO0_VSD_MASK);
>>  }
>>  
>> +static void hdmi_config_drm_infoframe(struct dw_hdmi *hdmi)
>> +{
>> +const struct drm_connector_state *conn_state = hdmi->connector.state;
>> +struct hdmi_drm_infoframe frame;
>> +u8 buffer[30];
>> +ssize_t err;
>> +int i;
>> +
>> +if (!hdmi->plat_data->use_drm_infoframe)
>> +return;
>> +
>> +hdmi_modb(hdmi, HDMI_FC_PACKET_TX_EN_DRM_DISABLE,
>> +  HDMI_FC_PACKET_TX_EN_DRM_MASK, HDMI_FC_PACKET_TX_EN);
>> +
>> +err = drm_hdmi_infoframe_set_hdr_metadata(&frame, conn_state);
>> +if (err < 0)
>> +return;
>> +
>> +err = hdmi_drm_infoframe_pack(&frame, buffer, sizeof(buffer));
>> +if (err < 0) {
>> +dev_err(hdmi->dev, "Failed to pack drm infoframe: %zd\n", err);
>> +return;
>> +}
>> +
>> +hdmi_writeb(hdmi, frame.version, HDMI_FC_DRM_HB0);
>> +hdmi_writeb(hdmi, frame.length, HDMI_FC_DRM_HB1);
>> +
>> +for (i = 0; i < frame.length; i++)
>> +hdmi_writeb(hdmi, buffer[4 + i], HDMI_FC_DRM_PB0 + i);
>> +
>> +hdmi_writeb(hdmi, 1, HDMI_FC_DRM_UP);
>> +hdmi_modb(hdmi, HDMI_FC_PACKET_TX_EN_DRM_ENABLE,
>> +  HDMI_FC_PACKET_TX_EN_DRM_MASK, HDMI_FC_PACKET_TX_EN);
>> +}
>> +
>>  static void hdmi_av_composer(struct dw_hdmi *hdmi,
>>   const struct drm_display_mode *mode)
>>  {
>> @@ -2064,6 +2100,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
>> drm_display_mode *mode)
>>  /* HDMI Initialization Step F - Configure AVI InfoFrame */
>>  hdmi_config_AVI(hdmi, mode);
>>  hdmi_config_vendor_specific_infoframe(hdmi, mode);
>> +hdmi_config_drm_infoframe(hdmi);
>>  } else {
>>  dev_dbg(hdmi->dev, "%s DVI mode\n", __func__);
>>  }
>> @@ -2230,6 +2267,45 @@ static int dw_hdmi_connector_get_modes(struct 
>> drm_connector *connector)
>>  return ret;
>>  }
>>  
>> +static bool hdr_metadata_equal(const struct drm_connector_state *old_state,
>> +   const struct drm_connector_state *new_state)
>> +{
>> +struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
>> +struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
>> +
>> +if (!old_blob || !new_blob)
>> +return old_blob == new_blob;
>> +
>> +if (old_blob->length != new_blob->length)
>> +return false;
>> +
>> +return !memcmp(old_blob->data, new_blob->data, old_blob->length);
>> +}
>> +
>> +static int dw_hdmi_connector_atomic_check(struct drm_connector *connector,
>> +  struct drm_atomic_state *state)
>> +{
>> +struct drm_connector_state *old_state =
>> +drm_atomic_get_old_connector_state(state, connector);
>> +struct drm_connector_state *new_state =
>> +drm_atomic_get_new_connector_state(state, connector);
>> +struct drm_crtc *crtc = new_state->crtc;
>> +struct drm_crtc_state *crtc_state;
>> +
>> +if (!crtc)
>> +return 0;
>> +
>> +if (!hdr_metadata_equal(old_state, new_state)) {
>> +crtc_state = drm_atomic_get_crtc_state(state, 

Re: [PATCH v4 0/8] drm/omap: OMAP_BO flags

[Jean-Jacques Hiblot]

On 10/10/2019 11:45, Tomi Valkeinen wrote:

Hi JJ,

On 10/10/2019 12:34, Jean-Jacques Hiblot wrote:

A first version of this work had been sent by Tomi Valkeinen in may 2017
(https://www.spinics.net/lists/dri-devel/msg140663.html).

This series adds a few new OMAP_BO flags to help the userspace manage
situations where it needs to use lots of buffers, and would currently 
run
out of TILER space. The TILER space is limited to mapping 128MB at 
any given

time and some applications might need more.

This seres is also the opportunity to do some cleanup in the flags and
improve the comments describing them.

The user-space patches for libdrm, although ready, haven't been 
posted yet.

It will be be done when this series have been discussed and hopefully in
the process of getting merged.

JJ

changes in v4:
- fixed incremental build issue introduced by patch #1 and later 
fixed by

   patch #2.
- Added my reviewed-by to Tomis's patch


This doesn't compile on top of 5.4 as the last patch is using 
dma_free_writecombine instead of dma_free_wc. In v3, it was correct, 
but the changenotes don't mention the change.


Was there some mix up? What kernel are your patches based on?


Yes I rushed an then got things mixed up, doing other stuff in parallel. 
Sorry about that.


Expect a fixed version based on v5.4-rc2 soon.

JJ




 Tomi


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

[PULL] drm-misc-fixes

[Maxime Ripard]

Hi Dave, Daniel,

Here's this week drm-misc-fixes PR, dealing mostly with SPI probing
related issues.

Maxime

drm-misc-fixes-2019-10-10:
Short summary of fixes pull (less than what git shortlog provides):
- SPI Aliases fixes for panels
- One fix for the tc358767 bridge dealing with visual artifacts
The following changes since commit b6559bf3ac32acfe34e17c73d68581e7f7415785:

  Merge drm-misc-next-fixes-2019-10-02 into drm-misc-fixes (2019-10-03 10:00:13 
+0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-10-10

for you to fetch changes up to fd70c7755bf0172ddd33b558aef69c322de3b5cf:

  drm/bridge: tc358767: fix max_tu_symbol value (2019-10-10 11:15:45 +0200)


Short summary of fixes pull (less than what git shortlog provides):
- SPI Aliases fixes for panels
- One fix for the tc358767 bridge dealing with visual artifacts


Laurent Pinchart (5):
  drm/panel: lg-lb035q02: Fix SPI alias
  drm/panel: nec-nl8048hl11: Fix SPI alias
  drm/panel: sony-acx565akm: Fix SPI alias
  drm/panel: tpo-td028ttec1: Fix SPI alias
  drm/panel: tpo-td043mtea1: Fix SPI alias

Tomi Valkeinen (1):
  drm/bridge: tc358767: fix max_tu_symbol value

 drivers/gpu/drm/bridge/tc358767.c| 7 ++-
 drivers/gpu/drm/panel/panel-lg-lb035q02.c| 9 -
 drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 9 -
 drivers/gpu/drm/panel/panel-sony-acx565akm.c | 9 -
 drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 3 +--
 drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 9 -
 6 files changed, 39 insertions(+), 7 deletions(-)


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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Ingo,

On Thu, 10 Oct 2019 10:02:07 +0200 Ingo Molnar  wrote:
>
> I suspect -next will have to carry this semantic merge conflict 
> resolution until the DRM tree is merged upstream.

Yep, its not a real problem, I get a few like this every cycle.

-- 
Cheers,
Stephen Rothwell


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

[PATCH] drm/ttm: fix handling in ttm_bo_add_mem_to_lru

[Christian König]

We should not add the BO to the swap LRU when the new mem is fixed and
the TTM object about to be destroyed.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 6394e0c5cc02..c51bb2c9ed4f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -185,8 +185,9 @@ static void ttm_bo_add_mem_to_lru(struct ttm_buffer_object 
*bo,
list_add_tail(&bo->lru, &man->lru[bo->priority]);
kref_get(&bo->list_kref);
 
-   if (bo->ttm && !(bo->ttm->page_flags &
-(TTM_PAGE_FLAG_SG | TTM_PAGE_FLAG_SWAPPED))) {
+   if (!(man->flags & TTM_MEMTYPE_FLAG_FIXED) && bo->ttm &&
+   !(bo->ttm->page_flags & (TTM_PAGE_FLAG_SG |
+TTM_PAGE_FLAG_SWAPPED))) {
list_add_tail(&bo->swap, &bdev->glob->swap_lru[bo->priority]);
kref_get(&bo->list_kref);
}
-- 
2.14.1

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

[PATCH] drm/plane: Clarify our expectations for src/dst rectangles

[Maarten Lankhorst]

The rectangles are usually clipped, but it can be useful to have
them unclipped, for example for cursor planes.

Signed-off-by: Maarten Lankhorst 
---
 include/drm/drm_plane.h | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index cd5903ad33f7..94bbbf215100 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -183,8 +183,26 @@ struct drm_plane_state {
 */
struct drm_property_blob *fb_damage_clips;
 
-   /** @src: clipped source coordinates of the plane (in 16.16) */
-   /** @dst: clipped destination coordinates of the plane */
+   /**
+* @src:
+*
+* source coordinates of the plane (in 16.16).
+*
+* When using drm_atomic_helper_check_plane_state(),
+* the coordinates are clipped, but the driver may choose
+* to use unclipped coordinates instead.
+*
+* This can be useful when using a hardcoded size in a cursor plane.
+*/
+   /**
+* @dst:
+*
+* When using drm_atomic_helper_check_plane_state(),
+* the coordinates are clipped, but the driver may choose
+* to use unclipped coordinates instead.
+*
+* This can be useful when using a hardcoded size in a cursor plane.
+*/
struct drm_rect src, dst;
 
/**
-- 
2.23.0

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

Re: [PATCH] drm/ttm: fix handling in ttm_bo_add_mem_to_lru

[Wang, Kevin(Yang)]

Reviewed-by: Kevin Wang 

Best Regards,
Kevin

From: Christian König 
Sent: Thursday, October 10, 2019 7:26 PM
To: dri-devel@lists.freedesktop.org ; Wang, 
Kevin(Yang) ; Zhang, Hawking 
Subject: [PATCH] drm/ttm: fix handling in ttm_bo_add_mem_to_lru

We should not add the BO to the swap LRU when the new mem is fixed and
the TTM object about to be destroyed.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 6394e0c5cc02..c51bb2c9ed4f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -185,8 +185,9 @@ static void ttm_bo_add_mem_to_lru(struct ttm_buffer_object 
*bo,
 list_add_tail(&bo->lru, &man->lru[bo->priority]);
 kref_get(&bo->list_kref);

-   if (bo->ttm && !(bo->ttm->page_flags &
-(TTM_PAGE_FLAG_SG | TTM_PAGE_FLAG_SWAPPED))) {
+   if (!(man->flags & TTM_MEMTYPE_FLAG_FIXED) && bo->ttm &&
+   !(bo->ttm->page_flags & (TTM_PAGE_FLAG_SG |
+TTM_PAGE_FLAG_SWAPPED))) {
 list_add_tail(&bo->swap, &bdev->glob->swap_lru[bo->priority]);
 kref_get(&bo->list_kref);
 }
--
2.14.1

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

[PATCH -next] drm/vkms: Remove duplicated include from vkms_drv.c

[YueHaibing]

Remove duplicated include.

Signed-off-by: YueHaibing 
---
 drivers/gpu/drm/vkms/vkms_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 54703463d966..d1fe144aa289 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 

Re: [pull] ttm drm-fixes-5.4

[Koenig, Christian]

Am 09.10.19 um 09:47 schrieb Arkadiusz Hiler:
> On Tue, Oct 08, 2019 at 09:13:41AM -0400, Alex Deucher wrote:
>> On Tue, Oct 8, 2019 at 4:04 AM Koenig, Christian
>>  wrote:
>>> My git version should be relative new, but I'm usually using thunderbird
>>> to send pull requests not git itself since I want to edit the message
>>> before sending.
>>>
>>> How would I do this in a way patchwork likes it with git?
>> FWIW, I usually generate the email first and then use git-send-email
>> to actually send it.
>>
>> Alex
> Hey,
>
> FDO patchwork maintainer here.
>
> I have tried few things quickly with no luck. There is something fishy
> about FDO deployment of patchwork - you email works just fine on my
> development instance.
>
> I have created issue for this:
> https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/issues/28
>
> Sorry for the inconvenience.

Maybe it's the non-Latin letter in my last name? Anyway we need to get 
the TTM fixes upstream for 5.4.

Dave/Daniel any objections that I push those directly to drm-misc-fixes?

Thanks,
Christian.

>
> Cheers,
> Arek
>
>>> Thanks,
>>> Christian.
>>>
>>> Am 07.10.19 um 21:58 schrieb Dave Airlie:
 For some reason this didn't end up in patchwork which makes it hard
 for me to process.

 Usual suspects are using too old a git to send it or maybe it got ctrl-Ms 
 in it.

 Dave.

 On Thu, 3 Oct 2019 at 01:44, Christian König
  wrote:
> Hi Dave, Daniel,
>
> we had some problems this cycle sending out TTM fixes because of lack of
> time to rebase amd-staging-drm-next.
>
> Because of this Alex and I decided that I'm going to send out TTM pull
> requests separately now. So this is the first small bunch of fixes for 
> 5.4.
>
> The following changes since commit 
> 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c:
>
>  Linux 5.4-rc1 (2019-09-30 10:35:40 -0700)
>
> are available in the Git repository at:
>
>  https://gitlab.freedesktop.org/ckoenig/linux-drm.git drm-ttm-fixes
>
> for you to fetch changes up to 3eefcfe9a644be4409691b44c3b2d629d177fb9a:
>
>  drm/ttm: Restore ttm prefaulting (2019-10-02 15:57:34 +0200)
>
> 
> Christian König (1):
>  drm/ttm: fix busy reference in ttm_mem_evict_first
>
> Thomas Hellstrom (1):
>  drm/ttm: Restore ttm prefaulting
>
> drivers/gpu/drm/ttm/ttm_bo.c|  4 ++--
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 16 +++-
> 2 files changed, 9 insertions(+), 11 deletions(-)
>
> Regards,
> 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

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

Re: [PATCH v2 0/4] drm/bridge: dw-hdmi: Add support for HDR metadata

[Neil Armstrong]

On 07/10/2019 21:19, Jonas Karlman wrote:
> Add support for HDR metadata using the hdr_output_metadata connector property,
> configure Dynamic Range and Mastering InfoFrame accordingly.
> 
> A use_drm_infoframe flag is added to dw_hdmi_plat_data that platform drivers
> can use to signal when Dynamic Range and Mastering infoframes is supported.
> This flag is needed because Amlogic GXBB and GXL report same DW-HDMI version,
> and only GXL support DRM InfoFrame.
> 
> The first patch add functionality to configure DRM InfoFrame based on the
> hdr_output_metadata connector property.
> 
> The remaining patches sets the use_drm_infoframe flag on some SoCs supporting
> Dynamic Range and Mastering InfoFrame.
> 
> v2 has been runtime tested on a Rock64 (RK3328) and Rock Pi 4 (RK3399),
> only build tested for Amlogic and Allwinner.
> 
> Changes in v2:
>   * address comments from Andrzej Hajda
>   - renamed blob_equal to hdr_metadata_equal
>   - renamed drm_infoframe flag to use_drm_infoframe
>   - use hdmi_drm_infoframe_pack and a loop to write regs
>   - remove hdmi version check in hdmi_config_drm_infoframe
> 
> Jonas Karlman (4):
>   drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support
>   drm/rockchip: Enable DRM InfoFrame support on RK3328 and RK3399
>   drm/meson: Enable DRM InfoFrame support on GXL, GXM and G12A
>   drm/sun4i: Enable DRM InfoFrame support on H6
> 
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 81 +
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h   | 37 ++
>  drivers/gpu/drm/meson/meson_dw_hdmi.c   |  5 ++
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +
>  drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c   |  2 +
>  drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h   |  1 +
>  include/drm/bridge/dw_hdmi.h|  1 +
>  7 files changed, 129 insertions(+)
> 

Applied to drm-misc-next,

Thanks,
Neil

[PATCH v5 7/8] drm/omap: add omap_gem_validate_flags()

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

Add a helper function omap_gem_validate_flags() which validates the
omap_bo flags passed from the userspace.

Also drop the dev_err() message, as the userspace can cause that at
will.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 40 ++
 1 file changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 27e0a2f8508a..e518d93ca6df 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1133,6 +1133,38 @@ void omap_gem_free_object(struct drm_gem_object *obj)
kfree(omap_obj);
 }
 
+static bool omap_gem_validate_flags(struct drm_device *dev, u32 flags)
+{
+   struct omap_drm_private *priv = dev->dev_private;
+
+   switch (flags & OMAP_BO_CACHE_MASK) {
+   case OMAP_BO_CACHED:
+   case OMAP_BO_WC:
+   case OMAP_BO_CACHE_MASK:
+   break;
+
+   default:
+   return false;
+   }
+
+   if (flags & OMAP_BO_TILED_MASK) {
+   if (!priv->usergart)
+   return false;
+
+   switch (flags & OMAP_BO_TILED_MASK) {
+   case OMAP_BO_TILED_8:
+   case OMAP_BO_TILED_16:
+   case OMAP_BO_TILED_32:
+   break;
+
+   default:
+   return false;
+   }
+   }
+
+   return true;
+}
+
 /* GEM buffer object constructor */
 struct drm_gem_object *omap_gem_new(struct drm_device *dev,
union omap_gem_size gsize, u32 flags)
@@ -1144,13 +1176,11 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
size_t size;
int ret;
 
+   if (!omap_gem_validate_flags(dev, flags))
+   return NULL;
+
/* Validate the flags and compute the memory and cache flags. */
if (flags & OMAP_BO_TILED_MASK) {
-   if (!priv->usergart) {
-   dev_err(dev->dev, "Tiled buffers require DMM\n");
-   return NULL;
-   }
-
/*
 * Tiled buffers are always shmem paged backed. When they are
 * scanned out, they are remapped into DMM/TILER.
-- 
2.17.1

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

[PATCH v5 3/8] drm/omap: accept NULL for dma_addr in omap_gem_pin

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

Allow NULL to be passed in 'dma_addr' for omap_gem_pin(), in case the
caller does not need the dma_addr.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 9201c21e206f..a6562d23d314 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -819,9 +819,11 @@ int omap_gem_pin(struct drm_gem_object *obj, dma_addr_t 
*dma_addr)
refcount_inc(&omap_obj->dma_addr_cnt);
}
 
-   *dma_addr = omap_obj->dma_addr;
+   if (dma_addr)
+   *dma_addr = omap_obj->dma_addr;
} else if (omap_gem_is_contiguous(omap_obj)) {
-   *dma_addr = omap_obj->dma_addr;
+   if (dma_addr)
+   *dma_addr = omap_obj->dma_addr;
} else {
ret = -EINVAL;
goto fail;
-- 
2.17.1

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

[PATCH v5 2/8] drm/omap: add omap_gem_unpin_locked()

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

Add omap_gem_unpin_locked() which is a version of omap_gem_unpin() that
expects the caller to hold the omap_obj lock.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 61caa7a1a24b..9201c21e206f 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -834,20 +834,16 @@ int omap_gem_pin(struct drm_gem_object *obj, dma_addr_t 
*dma_addr)
 }
 
 /**
- * omap_gem_unpin() - Unpin a GEM object from memory
+ * omap_gem_unpin_locked() - Unpin a GEM object from memory
  * @obj: the GEM object
  *
- * Unpin the given GEM object previously pinned with omap_gem_pin(). Pins are
- * reference-counted, the actualy unpin will only be performed when the number
- * of calls to this function matches the number of calls to omap_gem_pin().
+ * omap_gem_unpin() without locking.
  */
-void omap_gem_unpin(struct drm_gem_object *obj)
+static void omap_gem_unpin_locked(struct drm_gem_object *obj)
 {
struct omap_gem_object *omap_obj = to_omap_bo(obj);
int ret;
 
-   mutex_lock(&omap_obj->lock);
-
if (refcount_dec_and_test(&omap_obj->dma_addr_cnt)) {
ret = tiler_unpin(omap_obj->block);
if (ret) {
@@ -862,7 +858,22 @@ void omap_gem_unpin(struct drm_gem_object *obj)
omap_obj->dma_addr = 0;
omap_obj->block = NULL;
}
+}
 
+/**
+ * omap_gem_unpin() - Unpin a GEM object from memory
+ * @obj: the GEM object
+ *
+ * Unpin the given GEM object previously pinned with omap_gem_pin(). Pins are
+ * reference-counted, the actual unpin will only be performed when the number
+ * of calls to this function matches the number of calls to omap_gem_pin().
+ */
+void omap_gem_unpin(struct drm_gem_object *obj)
+{
+   struct omap_gem_object *omap_obj = to_omap_bo(obj);
+
+   mutex_lock(&omap_obj->lock);
+   omap_gem_unpin_locked(obj);
mutex_unlock(&omap_obj->lock);
 }
 
-- 
2.17.1

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

[PATCH v5 4/8] drm/omap: cleanup OMAP_BO flags

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

Reorder OMAP_BO flags and improve the comments.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 include/uapi/drm/omap_drm.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
index 1fccffef9e27..d8ee2f840697 100644
--- a/include/uapi/drm/omap_drm.h
+++ b/include/uapi/drm/omap_drm.h
@@ -38,19 +38,20 @@ struct drm_omap_param {
__u64 value;/* in (set_param), out (get_param) */
 };
 
-#define OMAP_BO_SCANOUT0x0001  /* scanout capable 
(phys contiguous) */
-#define OMAP_BO_CACHE_MASK 0x0006  /* cache type mask, see cache 
modes */
-#define OMAP_BO_TILED_MASK 0x0f00  /* tiled mapping mask, see 
tiled modes */
+/* Scanout buffer, consumable by DSS */
+#define OMAP_BO_SCANOUT0x0001
 
-/* cache modes */
-#define OMAP_BO_CACHED 0x  /* default */
-#define OMAP_BO_WC 0x0002  /* write-combine */
-#define OMAP_BO_UNCACHED   0x0004  /* strongly-ordered (uncached) 
*/
+/* Buffer CPU caching mode: cached, write-combining or uncached. */
+#define OMAP_BO_CACHED 0x
+#define OMAP_BO_WC 0x0002
+#define OMAP_BO_UNCACHED   0x0004
+#define OMAP_BO_CACHE_MASK 0x0006
 
-/* tiled modes */
+/* Use TILER for the buffer. The TILER container unit can be 8, 16 or 32 bits. 
*/
 #define OMAP_BO_TILED_80x0100
 #define OMAP_BO_TILED_16   0x0200
 #define OMAP_BO_TILED_32   0x0300
+#define OMAP_BO_TILED_MASK 0x0f00
 #define OMAP_BO_TILED  (OMAP_BO_TILED_8 | OMAP_BO_TILED_16 | 
OMAP_BO_TILED_32)
 
 union omap_gem_size {
-- 
2.17.1

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

[PATCH v5 0/8] drm/omap: OMAP_BO flags

[Jean-Jacques Hiblot]

A first version of this work had been sent by Tomi Valkeinen in may 2017 
(https://www.spinics.net/lists/dri-devel/msg140663.html).

This series adds a few new OMAP_BO flags to help the userspace manage
situations where it needs to use lots of buffers, and would currently run
out of TILER space. The TILER space is limited to mapping 128MB at any given
time and some applications might need more.

This seres is also the opportunity to do some cleanup in the flags and
improve the comments describing them.

The user-space patches for libdrm, although ready, haven't been posted yet.
It will be be done when this series have been discussed and hopefully in
the process of getting merged.

JJ

changes in v5:
- use dma_free_wc() instead of dma_free_writecombine(). This reverts
  an unintended change introduced in v4.

changes in v4:
- fixed incremental build issue introduced by patch #1 and later fixed by
  patch #2.
- Added my reviewed-by to Tomis's patch

changes in v3:
- rebase on top of v5.4-rc2
- Document omap_gem_new() and the new flags using the kernel-doc format

changes in v2:
- fixed build error that crept in during rebase before sending (sorry
  about that)
- rework the refcount part a bit.

Jean-Jacques Hiblot (1):
  drm/omap: use refcount API to track the number of users of dma_addr

Tomi Valkeinen (7):
  drm/omap: add omap_gem_unpin_locked()
  drm/omap: accept NULL for dma_addr in omap_gem_pin
  drm/omap: cleanup OMAP_BO flags
  drm/omap: remove OMAP_BO_TILED define
  drm/omap: cleanup OMAP_BO_SCANOUT use
  drm/omap: add omap_gem_validate_flags()
  drm/omap: add OMAP_BO flags to affect buffer allocation

 drivers/gpu/drm/omapdrm/omap_dmm_tiler.h  |   2 +-
 drivers/gpu/drm/omapdrm/omap_fb.c |   6 +-
 drivers/gpu/drm/omapdrm/omap_gem.c| 191 --
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |   2 +-
 include/uapi/drm/omap_drm.h   |  27 ++-
 5 files changed, 164 insertions(+), 64 deletions(-)

-- 
2.17.1

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

[PATCH v5 6/8] drm/omap: cleanup OMAP_BO_SCANOUT use

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

omap_gem_new() has a comment about OMAP_BO_SCANOUT which does not make
sense. Also, for the TILER case, we drop OMAP_BO_SCANOUT flag for some
reason.

It's not clear what the original purpose of OMAP_BO_SCANOUT is, but
presuming it means "scanout buffer, something that can be consumed by
DSS", this patch cleans up the above issues.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 4e8fcfdff3a0..27e0a2f8508a 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1155,7 +1155,6 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
 * Tiled buffers are always shmem paged backed. When they are
 * scanned out, they are remapped into DMM/TILER.
 */
-   flags &= ~OMAP_BO_SCANOUT;
flags |= OMAP_BO_MEM_SHMEM;
 
/*
@@ -1166,9 +1165,8 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
flags |= tiler_get_cpu_cache_flags();
} else if ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm) {
/*
-* OMAP_BO_SCANOUT hints that the buffer doesn't need to be
-* tiled. However, to lower the pressure on memory allocation,
-* use contiguous memory only if no TILER is available.
+* If we don't have DMM, we must allocate scanout buffers
+* from contiguous DMA memory.
 */
flags |= OMAP_BO_MEM_DMA_API;
} else if (!(flags & OMAP_BO_MEM_DMABUF)) {
-- 
2.17.1

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

[PATCH v5 1/8] drm/omap: use refcount API to track the number of users of dma_addr

[Jean-Jacques Hiblot]

This would give us a WARN_ON() if the pin/unpin calls are unbalanced.

Proposed-by: Laurent Pinchart 
Signed-off-by: Jean-Jacques Hiblot 
Reviewed-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 44 +++---
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 08f539efddfb..61caa7a1a24b 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -67,7 +67,7 @@ struct omap_gem_object {
/**
 * # of users of dma_addr
 */
-   u32 dma_addr_cnt;
+   refcount_t dma_addr_cnt;
 
/**
 * If the buffer has been imported from a dmabuf the OMAP_DB_DMABUF flag
@@ -773,13 +773,15 @@ int omap_gem_pin(struct drm_gem_object *obj, dma_addr_t 
*dma_addr)
mutex_lock(&omap_obj->lock);
 
if (!omap_gem_is_contiguous(omap_obj) && priv->has_dmm) {
-   if (omap_obj->dma_addr_cnt == 0) {
+   if (refcount_read(&omap_obj->dma_addr_cnt) == 0) {
u32 npages = obj->size >> PAGE_SHIFT;
enum tiler_fmt fmt = gem2fmt(omap_obj->flags);
struct tiler_block *block;
 
BUG_ON(omap_obj->block);
 
+   refcount_set(&omap_obj->dma_addr_cnt, 1);
+
ret = omap_gem_attach_pages(obj);
if (ret)
goto fail;
@@ -813,10 +815,10 @@ int omap_gem_pin(struct drm_gem_object *obj, dma_addr_t 
*dma_addr)
omap_obj->block = block;
 
DBG("got dma address: %pad", &omap_obj->dma_addr);
+   } else {
+   refcount_inc(&omap_obj->dma_addr_cnt);
}
 
-   omap_obj->dma_addr_cnt++;
-
*dma_addr = omap_obj->dma_addr;
} else if (omap_gem_is_contiguous(omap_obj)) {
*dma_addr = omap_obj->dma_addr;
@@ -846,22 +848,19 @@ void omap_gem_unpin(struct drm_gem_object *obj)
 
mutex_lock(&omap_obj->lock);
 
-   if (omap_obj->dma_addr_cnt > 0) {
-   omap_obj->dma_addr_cnt--;
-   if (omap_obj->dma_addr_cnt == 0) {
-   ret = tiler_unpin(omap_obj->block);
-   if (ret) {
-   dev_err(obj->dev->dev,
-   "could not unpin pages: %d\n", ret);
-   }
-   ret = tiler_release(omap_obj->block);
-   if (ret) {
-   dev_err(obj->dev->dev,
-   "could not release unmap: %d\n", ret);
-   }
-   omap_obj->dma_addr = 0;
-   omap_obj->block = NULL;
+   if (refcount_dec_and_test(&omap_obj->dma_addr_cnt)) {
+   ret = tiler_unpin(omap_obj->block);
+   if (ret) {
+   dev_err(obj->dev->dev,
+   "could not unpin pages: %d\n", ret);
+   }
+   ret = tiler_release(omap_obj->block);
+   if (ret) {
+   dev_err(obj->dev->dev,
+   "could not release unmap: %d\n", ret);
}
+   omap_obj->dma_addr = 0;
+   omap_obj->block = NULL;
}
 
mutex_unlock(&omap_obj->lock);
@@ -879,7 +878,7 @@ int omap_gem_rotated_dma_addr(struct drm_gem_object *obj, 
u32 orient,
 
mutex_lock(&omap_obj->lock);
 
-   if ((omap_obj->dma_addr_cnt > 0) && omap_obj->block &&
+   if ((refcount_read(&omap_obj->dma_addr_cnt) > 0) && omap_obj->block &&
(omap_obj->flags & OMAP_BO_TILED)) {
*dma_addr = tiler_tsptr(omap_obj->block, orient, x, y);
ret = 0;
@@ -1030,7 +1029,8 @@ void omap_gem_describe(struct drm_gem_object *obj, struct 
seq_file *m)
 
seq_printf(m, "%08x: %2d (%2d) %08llx %pad (%2d) %p %4d",
omap_obj->flags, obj->name, kref_read(&obj->refcount),
-   off, &omap_obj->dma_addr, omap_obj->dma_addr_cnt,
+   off, &omap_obj->dma_addr,
+   refcount_read(&omap_obj->dma_addr_cnt),
omap_obj->vaddr, omap_obj->roll);
 
if (omap_obj->flags & OMAP_BO_TILED) {
@@ -1093,7 +1093,7 @@ void omap_gem_free_object(struct drm_gem_object *obj)
mutex_lock(&omap_obj->lock);
 
/* The object should not be pinned. */
-   WARN_ON(omap_obj->dma_addr_cnt > 0);
+   WARN_ON(refcount_read(&omap_obj->dma_addr_cnt) > 0);
 
if (omap_obj->pages) {
if (omap_obj->flags & OMAP_BO_MEM_DMABUF)
-- 
2.17.1

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

[PATCH v5 8/8] drm/omap: add OMAP_BO flags to affect buffer allocation

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

On SoCs with DMM/TILER, we have two ways to allocate buffers: normal
dma_alloc or via DMM (which basically functions as an IOMMU). DMM can
map 128MB at a time, and we only map the DMM buffers when they are used
(i.e. not at alloc time). If DMM is present, omapdrm always uses DMM.

There are use cases that require lots of big buffers that are being used
at the same time by different IPs. At the moment the userspace has a
hard maximum of 128MB.

This patch adds three new flags that can be used by the userspace to
solve the situation:

OMAP_BO_MEM_CONTIG: The driver will use dma_alloc to get the memory.
This can be used to avoid DMM if the userspace knows it needs more than
128M of memory at the same time.

OMAP_BO_MEM_DMM: The driver will use DMM to get the memory. There's not
much use for this flag at the moment, as on platforms with DMM it is
used by default, but it's here for completeness.

OMAP_BO_MEM_PIN: The driver will pin the memory at alloc time, and keep
it pinned. This can be used to 1) get an error at alloc time if DMM
space is full, and 2) get rid of the constant pin/unpin operations which
may have some effect on performance.

If none of the flags are given, the behavior is the same as currently.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 54 --
 include/uapi/drm/omap_drm.h|  9 +
 2 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index e518d93ca6df..bf18dfe2b689 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1097,6 +1097,9 @@ void omap_gem_free_object(struct drm_gem_object *obj)
list_del(&omap_obj->mm_list);
mutex_unlock(&priv->list_lock);
 
+   if (omap_obj->flags & OMAP_BO_MEM_PIN)
+   omap_gem_unpin_locked(obj);
+
/*
 * We own the sole reference to the object at this point, but to keep
 * lockdep happy, we must still take the omap_obj_lock to call
@@ -1147,10 +1150,19 @@ static bool omap_gem_validate_flags(struct drm_device 
*dev, u32 flags)
return false;
}
 
+   if ((flags & OMAP_BO_MEM_CONTIG) && (flags & OMAP_BO_MEM_DMM))
+   return false;
+
+   if ((flags & OMAP_BO_MEM_DMM) && !priv->usergart)
+   return false;
+
if (flags & OMAP_BO_TILED_MASK) {
if (!priv->usergart)
return false;
 
+   if (flags & OMAP_BO_MEM_CONTIG)
+   return false;
+
switch (flags & OMAP_BO_TILED_MASK) {
case OMAP_BO_TILED_8:
case OMAP_BO_TILED_16:
@@ -1165,7 +1177,34 @@ static bool omap_gem_validate_flags(struct drm_device 
*dev, u32 flags)
return true;
 }
 
-/* GEM buffer object constructor */
+/**
+ * omap_gem_new() - Create a new GEM buffer
+ * @dev: The DRM device
+ * @gsize: The requested size for the GEM buffer. If the buffer is tiled
+ * (2D buffer), the size is a pair of values: height and width
+ * expressed in pixels. If the buffers is not tiled, it is expressed
+ * in bytes.
+ * @flags: Flags give additionnal information about the allocation:
+ * OMAP_BO_TILED_x: use the TILER (2D buffers). The TILER container
+ *  unit can be 8, 16 or 32 bits. Cache is always disabled for
+ *  tiled buffers.
+ * OMAP_BO_SCANOUT: Scannout buffer, consummable by the DSS
+ * OMAP_BO_CACHED: Buffer CPU caching mode: cached
+ * OMAP_BO_WC: Buffer CPU caching mode: write-combined
+ * OMAP_BO_UNCACHED: Buffer CPU caching mode: uncached
+ * OMAP_BO_MEM_CONTIG: The driver will use dma_alloc to get the memory.
+ *  This can be used to avoid DMM if the userspace knows it needs
+ *  more than 128M of memory at the same time.
+ * OMAP_BO_MEM_DMM: The driver will use DMM to get the memory. There's
+ *  not much use for this flag at the moment, as on platforms with
+ *  DMM it is used by default, but it's here for completeness.
+ * OMAP_BO_MEM_PIN: The driver will pin the memory at alloc time, and
+ *  keep it pinned. This can be used to 1) get an error at alloc
+ *  time if DMM space is full, and 2) get rid of the constant
+ *  pin/unpin operations which may have some effect on performance.
+ *
+ * Return: The GEM buffer or NULL if the allocation failed
+ */
 struct drm_gem_object *omap_gem_new(struct drm_device *dev,
union omap_gem_size gsize, u32 flags)
 {
@@ -1193,7 +1232,8 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
 */
flags &= ~(OMAP_BO_CACHED|OMAP_BO_WC|OMAP_BO_UNCACHED);
flags |= tiler_get_cpu_cache_flags();
-   } else if ((flags & OMAP_BO_SCANOUT) &&

[PATCH v5 5/8] drm/omap: remove OMAP_BO_TILED define

[Jean-Jacques Hiblot]

From: Tomi Valkeinen 

OMAP_BO_TILED does not make sense, as OMAP_BO_TILED_* values are not
bitmasks but normal values. As we already have OMAP_BO_TILED_MASK for
the mask, we can remove OMAP_BO_TILED and use OMAP_BO_TILED_MASK
instead.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Jean-Jacques Hiblot 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.h  |  2 +-
 drivers/gpu/drm/omapdrm/omap_fb.c |  6 +++---
 drivers/gpu/drm/omapdrm/omap_gem.c| 18 +-
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  2 +-
 include/uapi/drm/omap_drm.h   |  1 -
 5 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
index 835e6654fa82..43c1d096b021 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
@@ -113,7 +113,7 @@ extern struct platform_driver omap_dmm_driver;
 /* GEM bo flags -> tiler fmt */
 static inline enum tiler_fmt gem2fmt(u32 flags)
 {
-   switch (flags & OMAP_BO_TILED) {
+   switch (flags & OMAP_BO_TILED_MASK) {
case OMAP_BO_TILED_8:
return TILFMT_8BIT;
case OMAP_BO_TILED_16:
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 1b8b5108caf8..7403316088b8 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -95,7 +95,7 @@ static u32 get_linear_addr(struct drm_framebuffer *fb,
 
 bool omap_framebuffer_supports_rotation(struct drm_framebuffer *fb)
 {
-   return omap_gem_flags(fb->obj[0]) & OMAP_BO_TILED;
+   return omap_gem_flags(fb->obj[0]) & OMAP_BO_TILED_MASK;
 }
 
 /* Note: DRM rotates counter-clockwise, TILER & DSS rotates clockwise */
@@ -154,7 +154,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb,
x = state->src_x >> 16;
y = state->src_y >> 16;
 
-   if (omap_gem_flags(fb->obj[0]) & OMAP_BO_TILED) {
+   if (omap_gem_flags(fb->obj[0]) & OMAP_BO_TILED_MASK) {
u32 w = state->src_w >> 16;
u32 h = state->src_h >> 16;
 
@@ -212,7 +212,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb,
plane = &omap_fb->planes[1];
 
if (info->rotation_type == OMAP_DSS_ROT_TILER) {
-   WARN_ON(!(omap_gem_flags(fb->obj[1]) & OMAP_BO_TILED));
+   WARN_ON(!(omap_gem_flags(fb->obj[1]) & 
OMAP_BO_TILED_MASK));
omap_gem_rotated_dma_addr(fb->obj[1], orient, x/2, y/2,
  &info->p_uv_addr);
} else {
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index a6562d23d314..4e8fcfdff3a0 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -196,7 +196,7 @@ static void omap_gem_evict(struct drm_gem_object *obj)
struct omap_gem_object *omap_obj = to_omap_bo(obj);
struct omap_drm_private *priv = obj->dev->dev_private;
 
-   if (omap_obj->flags & OMAP_BO_TILED) {
+   if (omap_obj->flags & OMAP_BO_TILED_MASK) {
enum tiler_fmt fmt = gem2fmt(omap_obj->flags);
int i;
 
@@ -324,7 +324,7 @@ size_t omap_gem_mmap_size(struct drm_gem_object *obj)
struct omap_gem_object *omap_obj = to_omap_bo(obj);
size_t size = obj->size;
 
-   if (omap_obj->flags & OMAP_BO_TILED) {
+   if (omap_obj->flags & OMAP_BO_TILED_MASK) {
/* for tiled buffers, the virtual size has stride rounded up
 * to 4kb.. (to hide the fact that row n+1 might start 16kb or
 * 32kb later!).  But we don't back the entire buffer with
@@ -513,7 +513,7 @@ vm_fault_t omap_gem_fault(struct vm_fault *vmf)
 * probably trigger put_pages()?
 */
 
-   if (omap_obj->flags & OMAP_BO_TILED)
+   if (omap_obj->flags & OMAP_BO_TILED_MASK)
ret = omap_gem_fault_2d(obj, vma, vmf);
else
ret = omap_gem_fault_1d(obj, vma, vmf);
@@ -786,7 +786,7 @@ int omap_gem_pin(struct drm_gem_object *obj, dma_addr_t 
*dma_addr)
if (ret)
goto fail;
 
-   if (omap_obj->flags & OMAP_BO_TILED) {
+   if (omap_obj->flags & OMAP_BO_TILED_MASK) {
block = tiler_reserve_2d(fmt,
omap_obj->width,
omap_obj->height, 0);
@@ -892,7 +892,7 @@ int omap_gem_rotated_dma_addr(struct drm_gem_object *obj, 
u32 orient,
mutex_lock(&omap_obj->lock);
 
if ((refcount_read(&omap_obj->dma_addr_cnt) > 0) && omap_obj->block &&
-   (omap_obj->flags & OMAP_BO_TILED)) {
+   (omap_obj->flags & OMAP_BO_TILED_MASK)) {
*dma_addr = tiler_tsptr(omap_obj->block, orient, x, y);
 

[Bug 111932] driconf: TypeError: cannot concatenate 'str' and 'int' objects

[bugzilla-daemon]

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

mmokr...@fold.natur.cuni.cz  changed:

   What|Removed |Added

URL||https://sourceforge.net/p/d
   ||riconf/bugs/6/

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

[Bug 111933] driconf-0.9.1-r2 - assert iter or allowNone

[bugzilla-daemon]

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

mmokr...@fold.natur.cuni.cz  changed:

   What|Removed |Added

URL||https://sourceforge.net/p/d
   ||riconf/bugs/7/

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

Re: [PATCH] drm/plane: Clarify our expectations for src/dst rectangles

[Ville Syrjälä]

On Thu, Oct 10, 2019 at 01:29:17PM +0200, Maarten Lankhorst wrote:
> The rectangles are usually clipped, but it can be useful to have
> them unclipped, for example for cursor planes.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  include/drm/drm_plane.h | 22 --
>  1 file changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index cd5903ad33f7..94bbbf215100 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -183,8 +183,26 @@ struct drm_plane_state {
>*/
>   struct drm_property_blob *fb_damage_clips;
>  
> - /** @src: clipped source coordinates of the plane (in 16.16) */
> - /** @dst: clipped destination coordinates of the plane */
> + /**
> +  * @src:
> +  *
> +  * source coordinates of the plane (in 16.16).
> +  *
> +  * When using drm_atomic_helper_check_plane_state(),
> +  * the coordinates are clipped, but the driver may choose
> +  * to use unclipped coordinates instead.
> +  *
> +  * This can be useful when using a hardcoded size in a cursor plane.

I would instead say something like "when the hardware performs
the clipping automagically".

> +  */
> + /**
> +  * @dst:
> +  *
> +  * When using drm_atomic_helper_check_plane_state(),
> +  * the coordinates are clipped, but the driver may choose
> +  * to use unclipped coordinates instead.
> +  *
> +  * This can be useful when using a hardcoded size in a cursor plane.
> +  */
>   struct drm_rect src, dst;
>  
>   /**
> -- 
> 2.23.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 111796] [CI][SHARDS] igt@gem_eio@in-flight-suspend - crash - Received signal SIGSEGV

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
  Component|DRM/Intel   |IGT

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

Re: [PATCH] drm/plane: Clarify our expectations for src/dst rectangles

[Maarten Lankhorst]

Op 10-10-2019 om 14:36 schreef Ville Syrjälä:
> On Thu, Oct 10, 2019 at 01:29:17PM +0200, Maarten Lankhorst wrote:
>> The rectangles are usually clipped, but it can be useful to have
>> them unclipped, for example for cursor planes.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  include/drm/drm_plane.h | 22 --
>>  1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
>> index cd5903ad33f7..94bbbf215100 100644
>> --- a/include/drm/drm_plane.h
>> +++ b/include/drm/drm_plane.h
>> @@ -183,8 +183,26 @@ struct drm_plane_state {
>>   */
>>  struct drm_property_blob *fb_damage_clips;
>>  
>> -/** @src: clipped source coordinates of the plane (in 16.16) */
>> -/** @dst: clipped destination coordinates of the plane */
>> +/**
>> + * @src:
>> + *
>> + * source coordinates of the plane (in 16.16).
>> + *
>> + * When using drm_atomic_helper_check_plane_state(),
>> + * the coordinates are clipped, but the driver may choose
>> + * to use unclipped coordinates instead.
>> + *
>> + * This can be useful when using a hardcoded size in a cursor plane.
> I would instead say something like "when the hardware performs
> the clipping automagically".


With that fixed, r-b?

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

[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII

[bugzilla-daemon]

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

--- Comment #160 from ReddestDream  ---
Well, today I had a hard freeze using more than one display with Radeon VII.
Back to Radeon VII + iGPU . . . :(

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

Re: [PATCH] drm/plane: Clarify our expectations for src/dst rectangles

[Ville Syrjälä]

On Thu, Oct 10, 2019 at 02:46:26PM +0200, Maarten Lankhorst wrote:
> Op 10-10-2019 om 14:36 schreef Ville Syrjälä:
> > On Thu, Oct 10, 2019 at 01:29:17PM +0200, Maarten Lankhorst wrote:
> >> The rectangles are usually clipped, but it can be useful to have
> >> them unclipped, for example for cursor planes.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  include/drm/drm_plane.h | 22 --
> >>  1 file changed, 20 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> >> index cd5903ad33f7..94bbbf215100 100644
> >> --- a/include/drm/drm_plane.h
> >> +++ b/include/drm/drm_plane.h
> >> @@ -183,8 +183,26 @@ struct drm_plane_state {
> >> */
> >>struct drm_property_blob *fb_damage_clips;
> >>  
> >> -  /** @src: clipped source coordinates of the plane (in 16.16) */
> >> -  /** @dst: clipped destination coordinates of the plane */
> >> +  /**
> >> +   * @src:
> >> +   *
> >> +   * source coordinates of the plane (in 16.16).
> >> +   *
> >> +   * When using drm_atomic_helper_check_plane_state(),
> >> +   * the coordinates are clipped, but the driver may choose
> >> +   * to use unclipped coordinates instead.
> >> +   *
> >> +   * This can be useful when using a hardcoded size in a cursor plane.
> > I would instead say something like "when the hardware performs
> > the clipping automagically".
> 
> 
> With that fixed, r-b?

Aye

Reviewed-by: Ville Syrjälä 

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

[PATCH 1/3] drm/amd/display: Use swap() where appropriate

[Ville Syrjala]

From: Ville Syrjälä 

Mostly a cocci-job, but it flat out refused to remove the
declaration in drivers/gpu/drm/amd/display/dc/core/dc.c so
had to do that part manually.

@swap@
identifier TEMP;
expression A,B;
@@
- TEMP = A;
- A = B;
- B = TEMP;
+ swap(A, B);

@@
type T;
identifier swap.TEMP;
@@
(
- T TEMP;
|
- T TEMP = {...};
)
... when != TEMP

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "David (ChunMing) Zhou" 
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 7 ++-
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 8 ++--
 drivers/gpu/drm/amd/display/dc/core/dc.c   | 6 +-
 3 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c 
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
index 221e0f56389f..823843cd2613 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
@@ -2543,7 +2543,6 @@ static enum bp_result construct_integrated_info(
 
/* Sort voltage table from low to high*/
if (result == BP_RESULT_OK) {
-   struct clock_voltage_caps temp = {0, 0};
uint32_t i;
uint32_t j;
 
@@ -2553,10 +2552,8 @@ static enum bp_result construct_integrated_info(

info->disp_clk_voltage[j].max_supported_clk <

info->disp_clk_voltage[j-1].max_supported_clk) {
/* swap j and j - 1*/
-   temp = info->disp_clk_voltage[j-1];
-   info->disp_clk_voltage[j-1] =
-   
info->disp_clk_voltage[j];
-   info->disp_clk_voltage[j] = temp;
+   swap(info->disp_clk_voltage[j - 1],
+info->disp_clk_voltage[j]);
}
}
}
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index dff65c0fe82f..7873abea4112 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -1613,8 +1613,6 @@ static enum bp_result construct_integrated_info(
 
struct atom_common_table_header *header;
struct atom_data_revision revision;
-
-   struct clock_voltage_caps temp = {0, 0};
uint32_t i;
uint32_t j;
 
@@ -1644,10 +1642,8 @@ static enum bp_result construct_integrated_info(
info->disp_clk_voltage[j-1].max_supported_clk
) {
/* swap j and j - 1*/
-   temp = info->disp_clk_voltage[j-1];
-   info->disp_clk_voltage[j-1] =
-   info->disp_clk_voltage[j];
-   info->disp_clk_voltage[j] = temp;
+   swap(info->disp_clk_voltage[j - 1],
+info->disp_clk_voltage[j]);
}
}
}
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 5d1adeda4d90..fb6a7288caf4 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -901,15 +901,11 @@ static void program_timing_sync(
 
/* set first pipe with plane as master */
for (j = 0; j < group_size; j++) {
-   struct pipe_ctx *temp;
-
if (pipe_set[j]->plane_state) {
if (j == 0)
break;
 
-   temp = pipe_set[0];
-   pipe_set[0] = pipe_set[j];
-   pipe_set[j] = temp;
+   swap(pipe_set[0], pipe_set[j]);
break;
}
}
-- 
2.21.0

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

[PATCH 3/3] drm/atmel-hlcdc: Use swap() where appropriate

[Ville Syrjala]

From: Ville Syrjälä 

@swap@
identifier TEMP;
expression A,B;
@@
- TEMP = A;
- A = B;
- B = TEMP;
+ swap(A, B);

@@
type T;
identifier swap.TEMP;
@@
(
- T TEMP;
|
- T TEMP = {...};
)
... when != TEMP

Cc: Sam Ravnborg 
Cc: Boris Brezillon 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 89f5a756fa37..034f202dfe8f 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -601,7 +601,6 @@ static int atmel_hlcdc_plane_atomic_check(struct drm_plane 
*p,
struct drm_framebuffer *fb = state->base.fb;
const struct drm_display_mode *mode;
struct drm_crtc_state *crtc_state;
-   unsigned int tmp;
int ret;
int i;
 
@@ -694,9 +693,7 @@ static int atmel_hlcdc_plane_atomic_check(struct drm_plane 
*p,
 * Swap width and size in case of 90 or 270 degrees rotation
 */
if (drm_rotation_90_or_270(state->base.rotation)) {
-   tmp = state->src_w;
-   state->src_w = state->src_h;
-   state->src_h = tmp;
+   swap(state->src_w, state->src_h);
}
 
if (!desc->layout.size &&
-- 
2.21.0

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

[PATCH 2/3] drm/amdgpu/powerplay: Use swap() where appropriate

[Ville Syrjala]

From: Ville Syrjälä 

@swap@
identifier TEMP;
expression A,B;
@@
- TEMP = A;
- A = B;
- B = TEMP;
+ swap(A, B);

@@
type T;
identifier swap.TEMP;
@@
(
- T TEMP;
|
- T TEMP = {...};
)
... when != TEMP

Cc: Rex Zhu 
Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "David (ChunMing) Zhou" 
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 6 ++
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 6 ++
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 34f95e0e3ea4..1fe992835a76 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -1994,7 +1994,6 @@ static int smu7_sort_lookup_table(struct pp_hwmgr *hwmgr,
struct phm_ppt_v1_voltage_lookup_table *lookup_table)
 {
uint32_t table_size, i, j;
-   struct phm_ppt_v1_voltage_lookup_record tmp_voltage_lookup_record;
table_size = lookup_table->count;
 
PP_ASSERT_WITH_CODE(0 != lookup_table->count,
@@ -2005,9 +2004,8 @@ static int smu7_sort_lookup_table(struct pp_hwmgr *hwmgr,
for (j = i + 1; j > 0; j--) {
if (lookup_table->entries[j].us_vdd <
lookup_table->entries[j - 1].us_vdd) {
-   tmp_voltage_lookup_record = 
lookup_table->entries[j - 1];
-   lookup_table->entries[j - 1] = 
lookup_table->entries[j];
-   lookup_table->entries[j] = 
tmp_voltage_lookup_record;
+   swap(lookup_table->entries[j - 1],
+lookup_table->entries[j]);
}
}
}
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index d08493b67b67..f5dcba44f74a 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -712,7 +712,6 @@ static int vega10_sort_lookup_table(struct pp_hwmgr *hwmgr,
struct phm_ppt_v1_voltage_lookup_table *lookup_table)
 {
uint32_t table_size, i, j;
-   struct phm_ppt_v1_voltage_lookup_record tmp_voltage_lookup_record;
 
PP_ASSERT_WITH_CODE(lookup_table && lookup_table->count,
"Lookup table is empty", return -EINVAL);
@@ -724,9 +723,8 @@ static int vega10_sort_lookup_table(struct pp_hwmgr *hwmgr,
for (j = i + 1; j > 0; j--) {
if (lookup_table->entries[j].us_vdd <
lookup_table->entries[j - 1].us_vdd) {
-   tmp_voltage_lookup_record = 
lookup_table->entries[j - 1];
-   lookup_table->entries[j - 1] = 
lookup_table->entries[j];
-   lookup_table->entries[j] = 
tmp_voltage_lookup_record;
+   swap(lookup_table->entries[j - 1],
+lookup_table->entries[j]);
}
}
}
-- 
2.21.0

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

Re: [PATCH v2 16/24] drm/msm: dpu: Add modeset lock checks where applicable

[Sean Paul]

On Thu, Oct 10, 2019 at 12:20:56AM +0200, Daniel Vetter wrote:
> On Fri, Nov 16, 2018 at 7:44 PM Sean Paul  wrote:
> >
> > From: Sean Paul 
> >
> > Add modeset lock checks to functions that could be called outside the
> > core atomic stack.
> >
> > Changes in v2:
> > - None
> >
> > Signed-off-by: Sean Paul 
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 ++
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 1 +
> >  2 files changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > index a008a87a8113..cd0a0bea4335 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > @@ -284,6 +284,8 @@ enum dpu_intf_mode dpu_crtc_get_intf_mode(struct 
> > drm_crtc *crtc)
> > return INTF_MODE_NONE;
> > }
> >
> > +   WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
> > +
> > /* TODO: Returns the first INTF_MODE, could there be multiple 
> > values? */
> > drm_for_each_encoder_mask(encoder, crtc->dev, 
> > crtc->state->encoder_mask)
> > return dpu_encoder_get_intf_mode(encoder);
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > index 64134d619748..5104fc01147e 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > @@ -358,6 +358,7 @@ void dpu_kms_encoder_enable(struct drm_encoder *encoder)
> > if (funcs && funcs->commit)
> > funcs->commit(encoder);
> >
> > +   WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
> > drm_for_each_crtc(crtc, dev) {
> > if (!(crtc->state->encoder_mask & 
> > drm_encoder_mask(encoder)))
> > continue;
> 
> I'm fairly sure this is called in the atomic_commit path, and in there
> you might not actually hold these locks (if you do a nonblocking
> modeset).

Indeed. I'm not sure what my thinking was when submitting this, I think some of
the callsites may have changed since this was posted (with the enable/probe
refactors from a few months ago). At any rate, doesn't matter now, I'll post the
revert :-)

> 
> The locking rules for ->state are pretty fun: Either hold the lock, or
> be in atomic commit. In the later case atomic helpers' commit ordering
> guarantees that you can safely access ->state (but read-only only)
> without hodling any locks. You might want to revert.
> 
> Don't ask why I stumbled over this.

Ok, I'll just assume that you read seanpaul's 11-month old reviews before bed to
relax ;-)

Sean


> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm/msm: fix memleak on release

[Johan Hovold]

If a process is interrupted while accessing the "gpu" debugfs file and
the drm device struct_mutex is contended, release() could return early
and fail to free related resources.

Note that the return value from release() is ignored.

Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU 
state")
Cc: stable  # 4.18
Cc: Jordan Crouse 
Cc: Rob Clark 
Signed-off-by: Johan Hovold 
---
 drivers/gpu/drm/msm/msm_debugfs.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_debugfs.c 
b/drivers/gpu/drm/msm/msm_debugfs.c
index 6be879578140..1c74381a4fc9 100644
--- a/drivers/gpu/drm/msm/msm_debugfs.c
+++ b/drivers/gpu/drm/msm/msm_debugfs.c
@@ -47,12 +47,8 @@ static int msm_gpu_release(struct inode *inode, struct file 
*file)
struct msm_gpu_show_priv *show_priv = m->private;
struct msm_drm_private *priv = show_priv->dev->dev_private;
struct msm_gpu *gpu = priv->gpu;
-   int ret;
-
-   ret = mutex_lock_interruptible(&show_priv->dev->struct_mutex);
-   if (ret)
-   return ret;
 
+   mutex_lock(&show_priv->dev->struct_mutex);
gpu->funcs->gpu_state_put(show_priv->state);
mutex_unlock(&show_priv->dev->struct_mutex);
 
-- 
2.23.0

[PATCH 3/4] media: radio: wl1273: fix interrupt masking on release

[Johan Hovold]

If a process is interrupted while accessing the radio device and the
core lock is contended, release() could return early and fail to update
the interrupt mask.

Note that the return value of the v4l2 release file operation is
ignored.

Fixes: 87d1a50ce451 ("[media] V4L2: WL1273 FM Radio: TI WL1273 FM radio driver")
Cc: stable  # 2.6.38
Cc: Matti Aaltonen 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Johan Hovold 
---
 drivers/media/radio/radio-wl1273.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
index 104ac41c6f96..112376873167 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -1148,8 +1148,7 @@ static int wl1273_fm_fops_release(struct file *file)
if (radio->rds_users > 0) {
radio->rds_users--;
if (radio->rds_users == 0) {
-   if (mutex_lock_interruptible(&core->lock))
-   return -EINTR;
+   mutex_lock(&core->lock);
 
radio->irq_flags &= ~WL1273_RDS_EVENT;
 
-- 
2.23.0

[PATCH 0/4] treewide: fix interrupted release

[Johan Hovold]

Two old USB drivers had a bug in them which could lead to memory leaks
if an interrupted process raced with a disconnect event.

Turns out we had a few more driver in other subsystems with the same
kind of bug in them.

Note that all but the s390 patch have only been compile tested, while
the s390 one has not even been built.

Johan


Johan Hovold (4):
  drm/msm: fix memleak on release
  media: bdisp: fix memleak on release
  media: radio: wl1273: fix interrupt masking on release
  s390/zcrypt: fix memleak at release

 drivers/gpu/drm/msm/msm_debugfs.c | 6 +-
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 3 +--
 drivers/media/radio/radio-wl1273.c| 3 +--
 drivers/s390/crypto/zcrypt_api.c  | 3 +--
 4 files changed, 4 insertions(+), 11 deletions(-)

-- 
2.23.0

[PATCH 4/4] s390/zcrypt: fix memleak at release

[Johan Hovold]

If a process is interrupted while accessing the crypto device and the
global ap_perms_mutex is contented, release() could return early and
fail to free related resources.

Fixes: 00fab2350e6b ("s390/zcrypt: multiple zcrypt device nodes support")
Cc: stable  # 4.19
Cc: Harald Freudenberger 
Cc: Martin Schwidefsky 
Signed-off-by: Johan Hovold 
---
 drivers/s390/crypto/zcrypt_api.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/s390/crypto/zcrypt_api.c b/drivers/s390/crypto/zcrypt_api.c
index 45bdb47f84c1..9157e728a362 100644
--- a/drivers/s390/crypto/zcrypt_api.c
+++ b/drivers/s390/crypto/zcrypt_api.c
@@ -522,8 +522,7 @@ static int zcrypt_release(struct inode *inode, struct file 
*filp)
if (filp->f_inode->i_cdev == &zcrypt_cdev) {
struct zcdn_device *zcdndev;
 
-   if (mutex_lock_interruptible(&ap_perms_mutex))
-   return -ERESTARTSYS;
+   mutex_lock(&ap_perms_mutex);
zcdndev = find_zcdndev_by_devt(filp->f_inode->i_rdev);
mutex_unlock(&ap_perms_mutex);
if (zcdndev) {
-- 
2.23.0

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

[PATCH 2/4] media: bdisp: fix memleak on release

[Johan Hovold]

If a process is interrupted while accessing the video device and the
device lock is contended, release() could return early and fail to free
related resources.

Note that the return value of the v4l2 release file operation is
ignored.

Fixes: 28ffeebbb7bd ("[media] bdisp: 2D blitter driver using v4l2 mem2mem 
framework")
Cc: stable  # 4.2
Cc: Fabien Dessenne 
Cc: Hans Verkuil 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Johan Hovold 
---
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c 
b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
index e90f1ba30574..675b5f2b4c2e 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
@@ -651,8 +651,7 @@ static int bdisp_release(struct file *file)
 
dev_dbg(bdisp->dev, "%s\n", __func__);
 
-   if (mutex_lock_interruptible(&bdisp->lock))
-   return -ERESTARTSYS;
+   mutex_lock(&bdisp->lock);
 
v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
 
-- 
2.23.0

Re: [PATCH 3/3] drm/atmel-hlcdc: Use swap() where appropriate

[Boris Brezillon]

On Thu, 10 Oct 2019 16:11:59 +0300
Ville Syrjala  wrote:

> From: Ville Syrjälä 
> 
> @swap@
> identifier TEMP;
> expression A,B;
> @@
> - TEMP = A;
> - A = B;
> - B = TEMP;
> + swap(A, B);
> 
> @@
> type T;
> identifier swap.TEMP;
> @@
> (
> - T TEMP;
> |
> - T TEMP = {...};
> )
> ... when != TEMP
> 
> Cc: Sam Ravnborg 
> Cc: Boris Brezillon 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 89f5a756fa37..034f202dfe8f 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -601,7 +601,6 @@ static int atmel_hlcdc_plane_atomic_check(struct 
> drm_plane *p,
>   struct drm_framebuffer *fb = state->base.fb;
>   const struct drm_display_mode *mode;
>   struct drm_crtc_state *crtc_state;
> - unsigned int tmp;
>   int ret;
>   int i;
>  
> @@ -694,9 +693,7 @@ static int atmel_hlcdc_plane_atomic_check(struct 
> drm_plane *p,
>* Swap width and size in case of 90 or 270 degrees rotation
>*/
>   if (drm_rotation_90_or_270(state->base.rotation)) {
> - tmp = state->src_w;
> - state->src_w = state->src_h;
> - state->src_h = tmp;
> + swap(state->src_w, state->src_h);
>   }
>  
>   if (!desc->layout.size &&

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

Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane

[Ayan Halder]

On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
> This adds all the OSD configuration plumbing to support the AFBC decoders
> path to display of the OSD1 plane.
> 
> The Amlogic GXM and G12A AFBC decoders are integrated very differently.
> 
> The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
> because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
> 
> On the other side, the Amlogic G12A AFBC decoder seems to be an external
> IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
> feeding the OSD1 VIU pixel input.
> This uses a weird "0x100" internal HW physical address on both
> sides to transfer the pixels.
> 
> For Amlogic GXM, the supported pixel formats are the same as the normal
> linear OSD1 mode.
> 
> On the other side, Amlogic added support for all AFBC v1.2 formats for
> the G12A AFBC integration.
> 
> For simplicity, we stick to the already supported formats for now.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/meson/meson_crtc.c  |   2 +
>  drivers/gpu/drm/meson/meson_drv.h   |   4 +
>  drivers/gpu/drm/meson/meson_plane.c | 215 
>  3 files changed, 190 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
> b/drivers/gpu/drm/meson/meson_crtc.c
> index 57ae1c13d1e6..d478fa232951 100644
> --- a/drivers/gpu/drm/meson/meson_crtc.c
> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> @@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
>   if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
>   writel_relaxed(priv->viu.osd1_ctrl_stat,
>   priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
> + writel_relaxed(priv->viu.osd1_ctrl_stat2,
> + priv->io_base + _REG(VIU_OSD1_CTRL_STAT2));
>   writel_relaxed(priv->viu.osd1_blk0_cfg[0],
>   priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W0));
>   writel_relaxed(priv->viu.osd1_blk0_cfg[1],
> diff --git a/drivers/gpu/drm/meson/meson_drv.h 
> b/drivers/gpu/drm/meson/meson_drv.h
> index 60f13c6f34e5..de25349be8aa 100644
> --- a/drivers/gpu/drm/meson/meson_drv.h
> +++ b/drivers/gpu/drm/meson/meson_drv.h
> @@ -53,8 +53,12 @@ struct meson_drm {
>   bool osd1_enabled;
>   bool osd1_interlace;
>   bool osd1_commit;
> + bool osd1_afbcd;
>   uint32_t osd1_ctrl_stat;
> + uint32_t osd1_ctrl_stat2;
>   uint32_t osd1_blk0_cfg[5];
> + uint32_t osd1_blk1_cfg4;
> + uint32_t osd1_blk2_cfg4;
>   uint32_t osd1_addr;
>   uint32_t osd1_stride;
>   uint32_t osd1_height;
> diff --git a/drivers/gpu/drm/meson/meson_plane.c 
> b/drivers/gpu/drm/meson/meson_plane.c
> index 5e798c276037..412941aa8402 100644
> --- a/drivers/gpu/drm/meson/meson_plane.c
> +++ b/drivers/gpu/drm/meson/meson_plane.c
> @@ -23,6 +23,7 @@
>  #include "meson_plane.h"
>  #include "meson_registers.h"
>  #include "meson_viu.h"
> +#include "meson_osd_afbcd.h"
>  
>  /* OSD_SCI_WH_M1 */
>  #define SCI_WH_M1_W(w)   FIELD_PREP(GENMASK(28, 16), w)
> @@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane 
> *plane,
>  false, true);
>  }
>  
> +#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> \
> +AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |\
> +AFBC_FORMAT_MOD_YTR |\
> +AFBC_FORMAT_MOD_SPARSE | \
> +AFBC_FORMAT_MOD_SPLIT)
> +
>  /* Takes a fixed 16.16 number and converts it to integer. */
>  static inline int64_t fixed16_to_int(int64_t value)
>  {
>   return value >> 16;
>  }
>  
> +static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv)
> +{
> + u32 line_stride = 0;
> +
> + switch (priv->afbcd.format) {
> + case DRM_FORMAT_RGB565:
> + line_stride = ((priv->viu.osd1_width << 4) + 127) >> 7;
> + break;
> + case DRM_FORMAT_RGB888:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
Please have a look at
https://www.kernel.org/doc/html/latest/gpu/afbc.html for our
recommendation. We suggest that *X* formats are avoided.

Also, for interoperability and maximum compression efficiency (with
AFBC_FORMAT_MOD_YTR), we suggest the following order :-

Component 0: R
Component 1: G
Component 2: B
Component 3: A (if available)

Thus, DRM_FORMAT_ABGR, DRM_FORMAT_BGR should only be allowed.
> + line_stride = ((priv->viu.osd1_width << 5) + 127) >> 7;
> + break;
> + }
> +
> + return ((line_stride + 1) >> 1) << 1;
> +}
> +
>  static void meson_plane_atomic_update(struct drm

Re: [1/3] drm/tinydrm/Kconfig: Remove menuconfig DRM_TINYDRM

[Noralf Trønnes]

Den 09.10.2019 15.31, skrev Maxime Ripard:
> On Wed, Oct 09, 2019 at 02:48:20PM +0200, Noralf Trønnes wrote:
>> Den 09.10.2019 12.45, skrev Daniel Vetter:
>>> On Tue, Oct 01, 2019 at 04:07:38PM +0200, Noralf Trønnes wrote:
 Hi drm-misc maintainers,

 I have just applied a patch to drm-misc-next that as it turns out should
 have been applied to -fixes for this -rc cycle.

 Should I cherry pick it to drm-misc-next-fixes?
>>>
>>> Yup, cherry pick and reference the commit that's already in -next (in case
>>> it creates conflicts down the road that reference makes the mess easier to
>>> understand).
>>>
>>
>> I remembered that Maxime just sent out a fixes pull and the subject says
>> drm-misc-fixes. The prevous one he sent out was -next-fixes.
>> So it looks like I should cherry pick to drm-misc-fixes for it to show
>> up in 5.4?
> 
> drm-misc-next-fixes is the branch where we gather fixes supposed to be
> applied on top of drm-misc-next during the merge window. If you have
> something targeting the current release, it should be drm-misc-fixes
> indeed.

Thanks, it's applied now.

Noralf.

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

Re: [PATCH] drm/dp-mst: Drop connection_mutex check

[Daniel Vetter]

On Wed, Oct 09, 2019 at 06:46:38PM -0400, Lyude Paul wrote:
> oh, completely forgot about this one
> 
> Reviewed-by: Lyude Paul 

Thanks for your review, applied to drm-misc-next.
-Daniel
> 
> On Thu, 2019-10-10 at 00:41 +0200, Daniel Vetter wrote:
> > Private atomic objects have grown their own locking with
> > 
> > commit b962a12050a387e4bbf3a48745afe1d29d396b0d
> > Author: Rob Clark 
> > Date:   Mon Oct 22 14:31:22 2018 +0200
> > 
> > drm/atomic: integrate modeset lock with private objects
> > 
> > which means we're no longer relying on connection_mutex for mst state
> > locking needs.
> > 
> > Cc: Lyude Paul 
> > Cc: Sean Paul 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 6b14b63b8d62..9364e4f42975 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -4186,7 +4186,6 @@ struct drm_dp_mst_topology_state
> > *drm_atomic_get_mst_topology_state(struct drm_a
> >  {
> > struct drm_device *dev = mgr->dev;
> >  
> > -   WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
> > return
> > to_dp_mst_topology_state(drm_atomic_get_private_obj_state(state, &mgr-
> > >base));
> >  }
> >  EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
> -- 
> Cheers,
>   Lyude Paul
> 

-- 
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 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane

[Neil Armstrong]

Hi Ayan,

On 10/10/2019 15:26, Ayan Halder wrote:
> On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
>> This adds all the OSD configuration plumbing to support the AFBC decoders
>> path to display of the OSD1 plane.
>>
>> The Amlogic GXM and G12A AFBC decoders are integrated very differently.
>>
>> The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
>> because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
>>
>> On the other side, the Amlogic G12A AFBC decoder seems to be an external
>> IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
>> feeding the OSD1 VIU pixel input.
>> This uses a weird "0x100" internal HW physical address on both
>> sides to transfer the pixels.
>>
>> For Amlogic GXM, the supported pixel formats are the same as the normal
>> linear OSD1 mode.
>>
>> On the other side, Amlogic added support for all AFBC v1.2 formats for
>> the G12A AFBC integration.
>>
>> For simplicity, we stick to the already supported formats for now.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/gpu/drm/meson/meson_crtc.c  |   2 +
>>  drivers/gpu/drm/meson/meson_drv.h   |   4 +
>>  drivers/gpu/drm/meson/meson_plane.c | 215 
>>  3 files changed, 190 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
>> b/drivers/gpu/drm/meson/meson_crtc.c
>> index 57ae1c13d1e6..d478fa232951 100644
>> --- a/drivers/gpu/drm/meson/meson_crtc.c
>> +++ b/drivers/gpu/drm/meson/meson_crtc.c
>> @@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
>>  if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
>>  writel_relaxed(priv->viu.osd1_ctrl_stat,
>>  priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
>> +writel_relaxed(priv->viu.osd1_ctrl_stat2,
>> +priv->io_base + _REG(VIU_OSD1_CTRL_STAT2));
>>  writel_relaxed(priv->viu.osd1_blk0_cfg[0],
>>  priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W0));
>>  writel_relaxed(priv->viu.osd1_blk0_cfg[1],
>> diff --git a/drivers/gpu/drm/meson/meson_drv.h 
>> b/drivers/gpu/drm/meson/meson_drv.h
>> index 60f13c6f34e5..de25349be8aa 100644
>> --- a/drivers/gpu/drm/meson/meson_drv.h
>> +++ b/drivers/gpu/drm/meson/meson_drv.h
>> @@ -53,8 +53,12 @@ struct meson_drm {
>>  bool osd1_enabled;
>>  bool osd1_interlace;
>>  bool osd1_commit;
>> +bool osd1_afbcd;
>>  uint32_t osd1_ctrl_stat;
>> +uint32_t osd1_ctrl_stat2;
>>  uint32_t osd1_blk0_cfg[5];
>> +uint32_t osd1_blk1_cfg4;
>> +uint32_t osd1_blk2_cfg4;
>>  uint32_t osd1_addr;
>>  uint32_t osd1_stride;
>>  uint32_t osd1_height;
>> diff --git a/drivers/gpu/drm/meson/meson_plane.c 
>> b/drivers/gpu/drm/meson/meson_plane.c
>> index 5e798c276037..412941aa8402 100644
>> --- a/drivers/gpu/drm/meson/meson_plane.c
>> +++ b/drivers/gpu/drm/meson/meson_plane.c
>> @@ -23,6 +23,7 @@
>>  #include "meson_plane.h"
>>  #include "meson_registers.h"
>>  #include "meson_viu.h"
>> +#include "meson_osd_afbcd.h"
>>  
>>  /* OSD_SCI_WH_M1 */
>>  #define SCI_WH_M1_W(w)  FIELD_PREP(GENMASK(28, 16), w)
>> @@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane 
>> *plane,
>> false, true);
>>  }
>>  
>> +#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |   
>> \
>> +   AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |\
>> +   AFBC_FORMAT_MOD_YTR |\
>> +   AFBC_FORMAT_MOD_SPARSE | \
>> +   AFBC_FORMAT_MOD_SPLIT)
>> +
>>  /* Takes a fixed 16.16 number and converts it to integer. */
>>  static inline int64_t fixed16_to_int(int64_t value)
>>  {
>>  return value >> 16;
>>  }
>>  
>> +static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv)
>> +{
>> +u32 line_stride = 0;
>> +
>> +switch (priv->afbcd.format) {
>> +case DRM_FORMAT_RGB565:
>> +line_stride = ((priv->viu.osd1_width << 4) + 127) >> 7;
>> +break;
>> +case DRM_FORMAT_RGB888:
>> +case DRM_FORMAT_XRGB:
>> +case DRM_FORMAT_ARGB:
>> +case DRM_FORMAT_XBGR:
>> +case DRM_FORMAT_ABGR:
> Please have a look at
> https://www.kernel.org/doc/html/latest/gpu/afbc.html for our
> recommendation. We suggest that *X* formats are avoided.
> 
> Also, for interoperability and maximum compression efficiency (with
> AFBC_FORMAT_MOD_YTR), we suggest the following order :-
> 
> Component 0: R
> Component 1: G
> Component 2: B
> Component 3: A (if available)


Sorry I don't understand, you ask me to limit AFBC to ABGR ?

But why if the HW (GPU and DPU) is capable of ?

Isn't it an userspace choice

Re: [PATCH 1/6] drm/gem: refine drm_gem_objects_lookup

[Daniel Vetter]

On Thu, Oct 10, 2019 at 10:02:31AM +0800, Qiang Yu wrote:
> On Wed, Oct 9, 2019 at 10:57 PM Daniel Vetter  wrote:
> >
> > On Fri, Sep 27, 2019 at 08:09:52AM +0800, Qiang Yu wrote:
> > > On Thu, Sep 26, 2019 at 11:01 PM Rob Herring  wrote:
> > > >
> > > > On Thu, Sep 26, 2019 at 9:12 AM Qiang Yu  wrote:
> > > > >
> > > > > Do not use user space bo handles directly and left the user
> > > > > to kernel copy work to drivers calling this function.
> > > > >
> > > > > This is for driver like lima which does not pass gem bo
> > > > > handles continously in an array in ioctl argument.
> > > > >
> > > > > Cc: Rob Herring 
> > > > > Cc: Tomeu Vizoso 
> > > > > Cc: Steven Price 
> > > > > Cc: Alyssa Rosenzweig 
> > > > > Signed-off-by: Qiang Yu 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_gem.c   | 28 
> > > > > +++--
> > > > >  drivers/gpu/drm/panfrost/panfrost_drv.c | 23 +---
> > > >
> > > > Please keep the current variant. While only panfrost is converted ATM,
> > > > vc4 and v3d will use this too.
> > > >
> > > > >  include/drm/drm_gem.h   |  2 +-
> > > > >  3 files changed, 29 insertions(+), 24 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > > > > index 6854f5867d51..9f73e5f3b53f 100644
> > > > > --- a/drivers/gpu/drm/drm_gem.c
> > > > > +++ b/drivers/gpu/drm/drm_gem.c
> > > > > @@ -679,11 +679,11 @@ static int objects_lookup(struct drm_file 
> > > > > *filp, u32 *handle, int count,
> > > > >  /**
> > > > >   * drm_gem_objects_lookup - look up GEM objects from an array of 
> > > > > handles
> > > > >   * @filp: DRM file private date
> > > > > - * @bo_handles: user pointer to array of userspace handle
> > > > > + * @bo_handles: array of GEM object handles
> > > > >   * @count: size of handle array
> > > > >   * @objs_out: returned pointer to array of drm_gem_object pointers
> > > > >   *
> > > > > - * Takes an array of userspace handles and returns a newly allocated 
> > > > > array of
> > > > > + * Takes an array of GEM object handles and returns a newly 
> > > > > allocated array of
> > > > >   * GEM objects.
> > > > >   *
> > > > >   * For a single handle lookup, use drm_gem_object_lookup().
> > > > > @@ -695,11 +695,10 @@ static int objects_lookup(struct drm_file 
> > > > > *filp, u32 *handle, int count,
> > > > >   * failure. 0 is returned on success.
> > > > >   *
> > > > >   */
> > > > > -int drm_gem_objects_lookup(struct drm_file *filp, void __user 
> > > > > *bo_handles,
> > > > > +int drm_gem_objects_lookup(struct drm_file *filp, u32 *bo_handles,
> > > > >int count, struct drm_gem_object 
> > > > > ***objs_out)
> > > >
> > > > Either split into drm_gem_objects_lookup() and a
> > > > drm_gem_objects_lookup_user() with the latter calling the former or
> > > > just make the helper take both a user and u32* ptr with the
> > > > expectation that only one of them is non-NULL.
> > > >
> > > OK, I prefer the first way, will send v2 for it.
> >
> > Note that hopefully soon (Christian König is working on it) we'll have
> > ww_mutex locking helpers, which will introduce a drm_gem_operation_ctx.
> > Once we have that I think we can unify a lot of these helpers (Gerd
> > Hoffmann has looked into it) all while making them more flexible (i.e. not
> > only works with arrays). So might be worth to coordinate a bit here, and
> > maybe hold off on just this part for lima for a bit.
> 
> I don't know the context of these works, so I think I'd better wait some time
> for the new interface and send the rest of lima patches as v4.

Yeah I think with the new stuff we might be able to avoid the
kvmalloc_array, that's not really a great idea to plug into a fastpath
like execbuf. The other patches can imo still go ahead, I don't want to
hold up everything :-)
-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: linux-next: build failure after merge of the tip tree

[Daniel Vetter]

On Thu, Oct 10, 2019 at 10:23:21PM +1100, Stephen Rothwell wrote:
> Hi Ingo,
> 
> On Thu, 10 Oct 2019 10:02:07 +0200 Ingo Molnar  wrote:
> >
> > I suspect -next will have to carry this semantic merge conflict 
> > resolution until the DRM tree is merged upstream.
> 
> Yep, its not a real problem, I get a few like this every cycle.

Yeah totally within expectations when I acked that cleanup patch. We'll
probably have a few more lockdep annotation patches/changes that will
conflict in drm.
-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 -next] drm/vkms: Remove duplicated include from vkms_drv.c

[Daniel Vetter]

On Thu, Oct 10, 2019 at 11:52:13AM +, YueHaibing wrote:
> Remove duplicated include.
> 
> Signed-off-by: YueHaibing 

Applied, thanks.
-Daniel

> ---
>  drivers/gpu/drm/vkms/vkms_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 54703463d966..d1fe144aa289 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -19,7 +19,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> 
> 
> 
> 
> 

-- 
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 1/3] drm/amd/display: Use swap() where appropriate

[Kazlauskas, Nicholas]

On 2019-10-10 9:11 a.m., Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Mostly a cocci-job, but it flat out refused to remove the
> declaration in drivers/gpu/drm/amd/display/dc/core/dc.c so
> had to do that part manually.
> 
> @swap@
> identifier TEMP;
> expression A,B;
> @@
> - TEMP = A;
> - A = B;
> - B = TEMP;
> + swap(A, B);
> 
> @@
> type T;
> identifier swap.TEMP;
> @@
> (
> - T TEMP;
> |
> - T TEMP = {...};
> )
> ... when != TEMP
> 
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Nicholas Kazlauskas 

Thanks!

Nicholas Kazlauskas

> ---
>   drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 7 ++-
>   drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 8 ++--
>   drivers/gpu/drm/amd/display/dc/core/dc.c   | 6 +-
>   3 files changed, 5 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c 
> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> index 221e0f56389f..823843cd2613 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> @@ -2543,7 +2543,6 @@ static enum bp_result construct_integrated_info(
>   
>   /* Sort voltage table from low to high*/
>   if (result == BP_RESULT_OK) {
> - struct clock_voltage_caps temp = {0, 0};
>   uint32_t i;
>   uint32_t j;
>   
> @@ -2553,10 +2552,8 @@ static enum bp_result construct_integrated_info(
>   
> info->disp_clk_voltage[j].max_supported_clk <
>   
> info->disp_clk_voltage[j-1].max_supported_clk) {
>   /* swap j and j - 1*/
> - temp = info->disp_clk_voltage[j-1];
> - info->disp_clk_voltage[j-1] =
> - 
> info->disp_clk_voltage[j];
> - info->disp_clk_voltage[j] = temp;
> + swap(info->disp_clk_voltage[j - 1],
> +  info->disp_clk_voltage[j]);
>   }
>   }
>   }
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> index dff65c0fe82f..7873abea4112 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> @@ -1613,8 +1613,6 @@ static enum bp_result construct_integrated_info(
>   
>   struct atom_common_table_header *header;
>   struct atom_data_revision revision;
> -
> - struct clock_voltage_caps temp = {0, 0};
>   uint32_t i;
>   uint32_t j;
>   
> @@ -1644,10 +1642,8 @@ static enum bp_result construct_integrated_info(
>   info->disp_clk_voltage[j-1].max_supported_clk
>   ) {
>   /* swap j and j - 1*/
> - temp = info->disp_clk_voltage[j-1];
> - info->disp_clk_voltage[j-1] =
> - info->disp_clk_voltage[j];
> - info->disp_clk_voltage[j] = temp;
> + swap(info->disp_clk_voltage[j - 1],
> +  info->disp_clk_voltage[j]);
>   }
>   }
>   }
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 5d1adeda4d90..fb6a7288caf4 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -901,15 +901,11 @@ static void program_timing_sync(
>   
>   /* set first pipe with plane as master */
>   for (j = 0; j < group_size; j++) {
> - struct pipe_ctx *temp;
> -
>   if (pipe_set[j]->plane_state) {
>   if (j == 0)
>   break;
>   
> - temp = pipe_set[0];
> - pipe_set[0] = pipe_set[j];
> - pipe_set[j] = temp;
> + swap(pipe_set[0], pipe_set[j]);
>   break;
>   }
>   }
> 

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

Re: [PATCH] drm/plane: Clarify our expectations for src/dst rectangles

[Maarten Lankhorst]

Op 10-10-2019 om 15:07 schreef Ville Syrjälä:
> On Thu, Oct 10, 2019 at 02:46:26PM +0200, Maarten Lankhorst wrote:
>> Op 10-10-2019 om 14:36 schreef Ville Syrjälä:
>>> On Thu, Oct 10, 2019 at 01:29:17PM +0200, Maarten Lankhorst wrote:
 The rectangles are usually clipped, but it can be useful to have
 them unclipped, for example for cursor planes.

 Signed-off-by: Maarten Lankhorst 
 ---
  include/drm/drm_plane.h | 22 --
  1 file changed, 20 insertions(+), 2 deletions(-)

 diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
 index cd5903ad33f7..94bbbf215100 100644
 --- a/include/drm/drm_plane.h
 +++ b/include/drm/drm_plane.h
 @@ -183,8 +183,26 @@ struct drm_plane_state {
 */
struct drm_property_blob *fb_damage_clips;
  
 -  /** @src: clipped source coordinates of the plane (in 16.16) */
 -  /** @dst: clipped destination coordinates of the plane */
 +  /**
 +   * @src:
 +   *
 +   * source coordinates of the plane (in 16.16).
 +   *
 +   * When using drm_atomic_helper_check_plane_state(),
 +   * the coordinates are clipped, but the driver may choose
 +   * to use unclipped coordinates instead.
 +   *
 +   * This can be useful when using a hardcoded size in a cursor plane.
>>> I would instead say something like "when the hardware performs
>>> the clipping automagically".
>>
>> With that fixed, r-b?
> Aye
>
> Reviewed-by: Ville Syrjälä 
>
Noticed I dropped the explanation for dst when checking docbook output, fixed 
and pushed. :)

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

Re: [PATCH 0/4] treewide: fix interrupted release

[Daniel Vetter]

On Thu, Oct 10, 2019 at 03:13:29PM +0200, Johan Hovold wrote:
> Two old USB drivers had a bug in them which could lead to memory leaks
> if an interrupted process raced with a disconnect event.
> 
> Turns out we had a few more driver in other subsystems with the same
> kind of bug in them.
> 
> Note that all but the s390 patch have only been compile tested, while
> the s390 one has not even been built.

Random funny idea: Could we do some debug annotations (akin to
might_sleep) that splats when you might_sleep_interruptible somewhere
where interruptible sleeps are generally a bad idea? Like in
fops->release?

Something like non_block_start/end that I've recently done, but for
interruptible sleeps only? Would need might_sleep_interruptibly()
annotations and non_interruptly_sleep_start/end annotations.
-Daniel

> 
> Johan
> 
> 
> Johan Hovold (4):
>   drm/msm: fix memleak on release
>   media: bdisp: fix memleak on release
>   media: radio: wl1273: fix interrupt masking on release
>   s390/zcrypt: fix memleak at release
> 
>  drivers/gpu/drm/msm/msm_debugfs.c | 6 +-
>  drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 3 +--
>  drivers/media/radio/radio-wl1273.c| 3 +--
>  drivers/s390/crypto/zcrypt_api.c  | 3 +--
>  4 files changed, 4 insertions(+), 11 deletions(-)
> 
> -- 
> 2.23.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/tiny: Kconfig: Remove always-y THERMAL dep. from TINYDRM_REPAPER

[Noralf Trønnes]

Den 01.10.2019 12.58, skrev Noralf Trønnes:
> 
> 
> Den 27.09.2019 19.42, skrev Ulf Magnusson:
>> Commit 554b3529fe01 ("thermal/drivers/core: Remove the module Kconfig's
>> option") changed the type of THERMAL from tristate to bool, so
>> THERMAL || !THERMAL is now always y. Remove the redundant dependency.
>>
>> Discovered through Kconfiglib detecting a dependency loop. The C tools
>> simplify the expression to y before running dependency loop detection,
>> and so don't see it. Changing the type of THERMAL back to tristate makes
>> the C tools detect the same loop.
>>
>> Not sure if running dep. loop detection after simplification can be
>> called a bug. Fixing this nit unbreaks Kconfiglib on the kernel at
>> least.
>>
>> Signed-off-by: Ulf Magnusson 
>> ---
> 
> Thanks, applied to drm-misc-next.
> 

This has now been queued for the next -rc pull.

Discussion: https://patchwork.freedesktop.org/patch/319826/

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

[PATCH v4 0/3] drm/lima: simplify driver by using more drm helpers

[Qiang Yu]

By using shared drm helpers:
1. drm_gem_(un)lock_reservations
2. drm_gem_shmem_helpers
we can simplify lima driver a lot and benifit from updates to
these functions.

Patch series is based on drm-misc-next branch

v2:
Add drm_gem_objects_lookup_user and use it for driver which
pass user GEM handles in contious array.

v3:
improve commit comment.

v4:
Drop drm_gem_objects_lookup refine patches.

Qiang Yu (3):
  drm/lima: use drm_gem_shmem_helpers
  drm/lima: use drm_gem_(un)lock_reservations
  drm/lima: add __GFP_NOWARN flag to all dma_alloc_wc

 drivers/gpu/drm/lima/Kconfig  |   1 +
 drivers/gpu/drm/lima/Makefile |   4 +-
 drivers/gpu/drm/lima/lima_device.c|   2 +-
 drivers/gpu/drm/lima/lima_drv.c   |  22 +--
 drivers/gpu/drm/lima/lima_gem.c   | 195 ++
 drivers/gpu/drm/lima/lima_gem.h   |  32 -
 drivers/gpu/drm/lima/lima_gem_prime.c |  46 --
 drivers/gpu/drm/lima/lima_gem_prime.h |  13 --
 drivers/gpu/drm/lima/lima_mmu.c   |   1 -
 drivers/gpu/drm/lima/lima_object.c| 119 
 drivers/gpu/drm/lima/lima_object.h|  35 -
 drivers/gpu/drm/lima/lima_sched.c |   6 +-
 drivers/gpu/drm/lima/lima_vm.c|  87 ++--
 13 files changed, 148 insertions(+), 415 deletions(-)
 delete mode 100644 drivers/gpu/drm/lima/lima_gem_prime.c
 delete mode 100644 drivers/gpu/drm/lima/lima_gem_prime.h
 delete mode 100644 drivers/gpu/drm/lima/lima_object.c
 delete mode 100644 drivers/gpu/drm/lima/lima_object.h

-- 
2.17.1

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

[PATCH v4 2/3] drm/lima: use drm_gem_(un)lock_reservations

[Qiang Yu]

Simplify the driver code with DRM GEM helper function.

v2:
improve commit comment.

Signed-off-by: Qiang Yu 
---
 drivers/gpu/drm/lima/lima_gem.c | 64 -
 1 file changed, 6 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index 6094b9e27fa4..a0e49c6323b1 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -147,61 +147,6 @@ static int lima_gem_sync_bo(struct lima_sched_task *task, 
struct lima_bo *bo,
return drm_gem_fence_array_add_implicit(&task->deps, &bo->base.base, 
write);
 }
 
-static int lima_gem_lock_bos(struct lima_bo **bos, u32 nr_bos,
-struct ww_acquire_ctx *ctx)
-{
-   int i, ret = 0, contended, slow_locked = -1;
-
-   ww_acquire_init(ctx, &reservation_ww_class);
-
-retry:
-   for (i = 0; i < nr_bos; i++) {
-   if (i == slow_locked) {
-   slow_locked = -1;
-   continue;
-   }
-
-   ret = ww_mutex_lock_interruptible(&lima_bo_resv(bos[i])->lock, 
ctx);
-   if (ret < 0) {
-   contended = i;
-   goto err;
-   }
-   }
-
-   ww_acquire_done(ctx);
-   return 0;
-
-err:
-   for (i--; i >= 0; i--)
-   ww_mutex_unlock(&lima_bo_resv(bos[i])->lock);
-
-   if (slow_locked >= 0)
-   ww_mutex_unlock(&lima_bo_resv(bos[slow_locked])->lock);
-
-   if (ret == -EDEADLK) {
-   /* we lost out in a seqno race, lock and retry.. */
-   ret = ww_mutex_lock_slow_interruptible(
-   &lima_bo_resv(bos[contended])->lock, ctx);
-   if (!ret) {
-   slow_locked = contended;
-   goto retry;
-   }
-   }
-   ww_acquire_fini(ctx);
-
-   return ret;
-}
-
-static void lima_gem_unlock_bos(struct lima_bo **bos, u32 nr_bos,
-   struct ww_acquire_ctx *ctx)
-{
-   int i;
-
-   for (i = 0; i < nr_bos; i++)
-   ww_mutex_unlock(&lima_bo_resv(bos[i])->lock);
-   ww_acquire_fini(ctx);
-}
-
 static int lima_gem_add_deps(struct drm_file *file, struct lima_submit *submit)
 {
int i, err;
@@ -267,7 +212,8 @@ int lima_gem_submit(struct drm_file *file, struct 
lima_submit *submit)
bos[i] = bo;
}
 
-   err = lima_gem_lock_bos(bos, submit->nr_bos, &ctx);
+   err = drm_gem_lock_reservations((struct drm_gem_object **)bos,
+   submit->nr_bos, &ctx);
if (err)
goto err_out0;
 
@@ -300,7 +246,8 @@ int lima_gem_submit(struct drm_file *file, struct 
lima_submit *submit)
dma_resv_add_shared_fence(lima_bo_resv(bos[i]), fence);
}
 
-   lima_gem_unlock_bos(bos, submit->nr_bos, &ctx);
+   drm_gem_unlock_reservations((struct drm_gem_object **)bos,
+   submit->nr_bos, &ctx);
 
for (i = 0; i < submit->nr_bos; i++)
drm_gem_object_put_unlocked(&bos[i]->base.base);
@@ -317,7 +264,8 @@ int lima_gem_submit(struct drm_file *file, struct 
lima_submit *submit)
 err_out2:
lima_sched_task_fini(submit->task);
 err_out1:
-   lima_gem_unlock_bos(bos, submit->nr_bos, &ctx);
+   drm_gem_unlock_reservations((struct drm_gem_object **)bos,
+   submit->nr_bos, &ctx);
 err_out0:
for (i = 0; i < submit->nr_bos; i++) {
if (!bos[i])
-- 
2.17.1

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

[PATCH v4 1/3] drm/lima: use drm_gem_shmem_helpers

[Qiang Yu]

Do not need to maintain our own shmem memory management
code as drm_gem_shmem_helpers provides it. And we can
also benifit from the work of others with shared code.

This is also a preparation for implementing buffer madv.

Signed-off-by: Qiang Yu 
---
 drivers/gpu/drm/lima/Kconfig  |   1 +
 drivers/gpu/drm/lima/Makefile |   4 +-
 drivers/gpu/drm/lima/lima_drv.c   |  22 +---
 drivers/gpu/drm/lima/lima_gem.c   | 141 +-
 drivers/gpu/drm/lima/lima_gem.h   |  32 --
 drivers/gpu/drm/lima/lima_gem_prime.c |  46 -
 drivers/gpu/drm/lima/lima_gem_prime.h |  13 ---
 drivers/gpu/drm/lima/lima_mmu.c   |   1 -
 drivers/gpu/drm/lima/lima_object.c| 119 --
 drivers/gpu/drm/lima/lima_object.h|  35 ---
 drivers/gpu/drm/lima/lima_sched.c |   6 +-
 drivers/gpu/drm/lima/lima_vm.c|  85 
 12 files changed, 145 insertions(+), 360 deletions(-)
 delete mode 100644 drivers/gpu/drm/lima/lima_gem_prime.c
 delete mode 100644 drivers/gpu/drm/lima/lima_gem_prime.h
 delete mode 100644 drivers/gpu/drm/lima/lima_object.c
 delete mode 100644 drivers/gpu/drm/lima/lima_object.h

diff --git a/drivers/gpu/drm/lima/Kconfig b/drivers/gpu/drm/lima/Kconfig
index bb4ddc6bb0a6..571dc369a7e9 100644
--- a/drivers/gpu/drm/lima/Kconfig
+++ b/drivers/gpu/drm/lima/Kconfig
@@ -9,5 +9,6 @@ config DRM_LIMA
depends on COMMON_CLK
depends on OF
select DRM_SCHED
+   select DRM_GEM_SHMEM_HELPER
help
  DRM driver for ARM Mali 400/450 GPUs.
diff --git a/drivers/gpu/drm/lima/Makefile b/drivers/gpu/drm/lima/Makefile
index 38cc70281ba5..a85444b0a1d4 100644
--- a/drivers/gpu/drm/lima/Makefile
+++ b/drivers/gpu/drm/lima/Makefile
@@ -13,9 +13,7 @@ lima-y := \
lima_vm.o \
lima_sched.o \
lima_ctx.o \
-   lima_gem_prime.o \
lima_dlbu.o \
-   lima_bcast.o \
-   lima_object.o
+   lima_bcast.o
 
 obj-$(CONFIG_DRM_LIMA) += lima.o
diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
index 75ec703d22e0..96544c7fc218 100644
--- a/drivers/gpu/drm/lima/lima_drv.c
+++ b/drivers/gpu/drm/lima/lima_drv.c
@@ -12,7 +12,6 @@
 
 #include "lima_drv.h"
 #include "lima_gem.h"
-#include "lima_gem_prime.h"
 #include "lima_vm.h"
 
 int lima_sched_timeout_ms;
@@ -240,16 +239,7 @@ static const struct drm_ioctl_desc 
lima_drm_driver_ioctls[] = {
DRM_IOCTL_DEF_DRV(LIMA_CTX_FREE, lima_ioctl_ctx_free, DRM_RENDER_ALLOW),
 };
 
-static const struct file_operations lima_drm_driver_fops = {
-   .owner  = THIS_MODULE,
-   .open   = drm_open,
-   .release= drm_release,
-   .unlocked_ioctl = drm_ioctl,
-#ifdef CONFIG_COMPAT
-   .compat_ioctl   = drm_compat_ioctl,
-#endif
-   .mmap   = lima_gem_mmap,
-};
+DEFINE_DRM_GEM_SHMEM_FOPS(lima_drm_driver_fops);
 
 static struct drm_driver lima_drm_driver = {
.driver_features= DRIVER_RENDER | DRIVER_GEM | DRIVER_SYNCOBJ,
@@ -258,10 +248,6 @@ static struct drm_driver lima_drm_driver = {
.ioctls = lima_drm_driver_ioctls,
.num_ioctls = ARRAY_SIZE(lima_drm_driver_ioctls),
.fops   = &lima_drm_driver_fops,
-   .gem_free_object_unlocked = lima_gem_free_object,
-   .gem_open_object= lima_gem_object_open,
-   .gem_close_object   = lima_gem_object_close,
-   .gem_vm_ops = &lima_gem_vm_ops,
.name   = "lima",
.desc   = "lima DRM",
.date   = "20190217",
@@ -269,11 +255,11 @@ static struct drm_driver lima_drm_driver = {
.minor  = 0,
.patchlevel = 0,
 
+   .gem_create_object  = lima_gem_create_object,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import_sg_table = lima_gem_prime_import_sg_table,
+   .gem_prime_import_sg_table = drm_gem_shmem_prime_import_sg_table,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .gem_prime_get_sg_table = lima_gem_prime_get_sg_table,
-   .gem_prime_mmap = lima_gem_prime_mmap,
+   .gem_prime_mmap = drm_gem_prime_mmap,
 };
 
 static int lima_pdev_probe(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index 4da21353c3a2..6094b9e27fa4 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -3,7 +3,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
@@ -13,40 +13,55 @@
 
 #include "lima_drv.h"
 #include "lima_gem.h"
-#include "lima_gem_prime.h"
 #include "lima_vm.h"
-#include "lima_object.h"
 
 int lima_gem_create_handle(struct drm_device *dev, struct drm_file *file,
   u32 size, u32 flags, u32 *handle)
 {
int err;
-   struct lima_bo *bo;
-   struct lima_device *ldev = to_lima_dev(dev);
+   gfp_t mask;
+   struct drm_gem_

[PATCH v4 3/3] drm/lima: add __GFP_NOWARN flag to all dma_alloc_wc

[Qiang Yu]

This prevent CMA printing dumy "PFNs busy" info which is
caused by alloc fail re-try case.

Signed-off-by: Qiang Yu 
---
 drivers/gpu/drm/lima/lima_device.c | 2 +-
 drivers/gpu/drm/lima/lima_vm.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_device.c 
b/drivers/gpu/drm/lima/lima_device.c
index e3e0ca11382e..19829b543024 100644
--- a/drivers/gpu/drm/lima/lima_device.c
+++ b/drivers/gpu/drm/lima/lima_device.c
@@ -314,7 +314,7 @@ int lima_device_init(struct lima_device *ldev)
ldev->va_end = LIMA_VA_RESERVE_START;
ldev->dlbu_cpu = dma_alloc_wc(
ldev->dev, LIMA_PAGE_SIZE,
-   &ldev->dlbu_dma, GFP_KERNEL);
+   &ldev->dlbu_dma, GFP_KERNEL | __GFP_NOWARN);
if (!ldev->dlbu_cpu) {
err = -ENOMEM;
goto err_out2;
diff --git a/drivers/gpu/drm/lima/lima_vm.c b/drivers/gpu/drm/lima/lima_vm.c
index 8e69c4540e8b..840e2350d872 100644
--- a/drivers/gpu/drm/lima/lima_vm.c
+++ b/drivers/gpu/drm/lima/lima_vm.c
@@ -56,7 +56,7 @@ static int lima_vm_map_page(struct lima_vm *vm, dma_addr_t 
pa, u32 va)
 
vm->bts[pbe].cpu = dma_alloc_wc(
vm->dev->dev, LIMA_PAGE_SIZE << 
LIMA_VM_NUM_PT_PER_BT_SHIFT,
-   &vm->bts[pbe].dma, GFP_KERNEL | __GFP_ZERO);
+   &vm->bts[pbe].dma, GFP_KERNEL | __GFP_NOWARN | 
__GFP_ZERO);
if (!vm->bts[pbe].cpu)
return -ENOMEM;
 
@@ -208,7 +208,7 @@ struct lima_vm *lima_vm_create(struct lima_device *dev)
kref_init(&vm->refcount);
 
vm->pd.cpu = dma_alloc_wc(dev->dev, LIMA_PAGE_SIZE, &vm->pd.dma,
- GFP_KERNEL | __GFP_ZERO);
+ GFP_KERNEL | __GFP_NOWARN | __GFP_ZERO);
if (!vm->pd.cpu)
goto err_out0;
 
-- 
2.17.1

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

Re: [PATCH] drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50

[Alex Deucher]

On Wed, Oct 9, 2019 at 3:12 AM Kai-Heng Feng
 wrote:
>
>
>
> > On Jun 6, 2019, at 16:04, Kai-Heng Feng  wrote:
> >
> > Hi,
> >
> > at 11:30, Kai-Heng Feng  wrote:
> >
> >> Another panel that needs 6BPC quirk.
> >
> > Please include this patch if possible.
>
> Another gentle ping.

Reviewed and pushed out to drm-misc-fixes.

Thanks,

Alex

>
> >
> > Kai-Heng
> >
> >>
> >> BugLink: https://bugs.launchpad.net/bugs/1819968
> >> Cc:  # v4.8+
> >> Signed-off-by: Kai-Heng Feng 
> >> ---
> >> drivers/gpu/drm/drm_edid.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 990b1909f9d7..1cb4d0052efe 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -166,6 +166,9 @@ static const struct edid_quirk {
> >>  /* Medion MD 30217 PG */
> >>  { "MED", 0x7b8, EDID_QUIRK_PREFER_LARGE_75 },
> >>
> >> +/* Lenovo G50 */
> >> +{ "SDC", 18514, EDID_QUIRK_FORCE_6BPC },
> >> +
> >>  /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */
> >>  { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },
> >>
> >> --
> >> 2.17.1
> >
> >
>
> ___
> 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 2/4] media: bdisp: fix memleak on release

[Fabien DESSENNE]

Hi Johan

Thank you for the patch

BR

Fabien


On 10/10/2019 3:13 PM, Johan Hovold wrote:
> If a process is interrupted while accessing the video device and the
> device lock is contended, release() could return early and fail to free
> related resources.
>
> Note that the return value of the v4l2 release file operation is
> ignored.
>
> Fixes: 28ffeebbb7bd ("[media] bdisp: 2D blitter driver using v4l2 mem2mem 
> framework")
> Cc: stable  # 4.2
> Cc: Fabien Dessenne 
> Cc: Hans Verkuil 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Johan Hovold 
Reviewed-by: Fabien Dessenne 
> ---
>   drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c 
> b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
> index e90f1ba30574..675b5f2b4c2e 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
> +++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
> @@ -651,8 +651,7 @@ static int bdisp_release(struct file *file)
>   
>   dev_dbg(bdisp->dev, "%s\n", __func__);
>   
> - if (mutex_lock_interruptible(&bdisp->lock))
> - return -ERESTARTSYS;
> + mutex_lock(&bdisp->lock);
>   
>   v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
>   

Re: [PATCH] drm/scheduler: make unexported items static

[Alex Deucher]

On Thu, Oct 10, 2019 at 2:55 AM Ben Dooks  wrote:
>
> The drm_sched_fence_ops_{scheduled,finished} are not exported
> from the file so make them static to avoid the following
> warnings from sparse:
>
> drivers/gpu/drm/scheduler/sched_fence.c:131:28: warning: symbol 
> 'drm_sched_fence_ops_scheduled' was not declared. Should it be static?
> drivers/gpu/drm/scheduler/sched_fence.c:137:28: warning: symbol 
> 'drm_sched_fence_ops_finished' was not declared. Should it be static?
>
> Signed-off-by: Ben Dooks 

Reviewed and pushed out to drm-misc-next.

Thanks!

Alex

> ---
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/scheduler/sched_fence.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_fence.c 
> b/drivers/gpu/drm/scheduler/sched_fence.c
> index 54977408f574..8b45c3a1b84e 100644
> --- a/drivers/gpu/drm/scheduler/sched_fence.c
> +++ b/drivers/gpu/drm/scheduler/sched_fence.c
> @@ -128,13 +128,13 @@ static void drm_sched_fence_release_finished(struct 
> dma_fence *f)
> dma_fence_put(&fence->scheduled);
>  }
>
> -const struct dma_fence_ops drm_sched_fence_ops_scheduled = {
> +static const struct dma_fence_ops drm_sched_fence_ops_scheduled = {
> .get_driver_name = drm_sched_fence_get_driver_name,
> .get_timeline_name = drm_sched_fence_get_timeline_name,
> .release = drm_sched_fence_release_scheduled,
>  };
>
> -const struct dma_fence_ops drm_sched_fence_ops_finished = {
> +static const struct dma_fence_ops drm_sched_fence_ops_finished = {
> .get_driver_name = drm_sched_fence_get_driver_name,
> .get_timeline_name = drm_sched_fence_get_timeline_name,
> .release = drm_sched_fence_release_finished,
> --
> 2.23.0
>
> ___
> 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 1/3] drm/amd/display: Use swap() where appropriate

[Alex Deucher]

Applied.  Thanks!

Alex

On Thu, Oct 10, 2019 at 9:48 AM Kazlauskas, Nicholas
 wrote:
>
> On 2019-10-10 9:11 a.m., Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > Mostly a cocci-job, but it flat out refused to remove the
> > declaration in drivers/gpu/drm/amd/display/dc/core/dc.c so
> > had to do that part manually.
> >
> > @swap@
> > identifier TEMP;
> > expression A,B;
> > @@
> > - TEMP = A;
> > - A = B;
> > - B = TEMP;
> > + swap(A, B);
> >
> > @@
> > type T;
> > identifier swap.TEMP;
> > @@
> > (
> > - T TEMP;
> > |
> > - T TEMP = {...};
> > )
> > ... when != TEMP
> >
> > Cc: Harry Wentland 
> > Cc: Leo Li 
> > Cc: Alex Deucher 
> > Cc: "Christian König" 
> > Cc: "David (ChunMing) Zhou" 
> > Cc: amd-...@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä 
>
> Reviewed-by: Nicholas Kazlauskas 
>
> Thanks!
>
> Nicholas Kazlauskas
>
> > ---
> >   drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 7 ++-
> >   drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 8 ++--
> >   drivers/gpu/drm/amd/display/dc/core/dc.c   | 6 +-
> >   3 files changed, 5 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c 
> > b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> > index 221e0f56389f..823843cd2613 100644
> > --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> > +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> > @@ -2543,7 +2543,6 @@ static enum bp_result construct_integrated_info(
> >
> >   /* Sort voltage table from low to high*/
> >   if (result == BP_RESULT_OK) {
> > - struct clock_voltage_caps temp = {0, 0};
> >   uint32_t i;
> >   uint32_t j;
> >
> > @@ -2553,10 +2552,8 @@ static enum bp_result construct_integrated_info(
> >   
> > info->disp_clk_voltage[j].max_supported_clk <
> >   
> > info->disp_clk_voltage[j-1].max_supported_clk) {
> >   /* swap j and j - 1*/
> > - temp = info->disp_clk_voltage[j-1];
> > - info->disp_clk_voltage[j-1] =
> > - 
> > info->disp_clk_voltage[j];
> > - info->disp_clk_voltage[j] = temp;
> > + swap(info->disp_clk_voltage[j - 1],
> > +  info->disp_clk_voltage[j]);
> >   }
> >   }
> >   }
> > diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
> > b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> > index dff65c0fe82f..7873abea4112 100644
> > --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> > +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> > @@ -1613,8 +1613,6 @@ static enum bp_result construct_integrated_info(
> >
> >   struct atom_common_table_header *header;
> >   struct atom_data_revision revision;
> > -
> > - struct clock_voltage_caps temp = {0, 0};
> >   uint32_t i;
> >   uint32_t j;
> >
> > @@ -1644,10 +1642,8 @@ static enum bp_result construct_integrated_info(
> >   info->disp_clk_voltage[j-1].max_supported_clk
> >   ) {
> >   /* swap j and j - 1*/
> > - temp = info->disp_clk_voltage[j-1];
> > - info->disp_clk_voltage[j-1] =
> > - info->disp_clk_voltage[j];
> > - info->disp_clk_voltage[j] = temp;
> > + swap(info->disp_clk_voltage[j - 1],
> > +  info->disp_clk_voltage[j]);
> >   }
> >   }
> >   }
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> > b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > index 5d1adeda4d90..fb6a7288caf4 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > @@ -901,15 +901,11 @@ static void program_timing_sync(
> >
> >   /* set first pipe with plane as master */
> >   for (j = 0; j < group_size; j++) {
> > - struct pipe_ctx *temp;
> > -
> >   if (pipe_set[j]->plane_state) {
> >   if (j == 0)
> >   break;
> >
> > - temp = pipe_set[0];
> > - pipe_set[0] = pipe_set[j];
> > - pipe_set[j] = temp;
> > + swap(pipe_set[0], pipe_set[j]);
> >   break;
> >   }
> >   }
> >
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesk

Re: [PATCH 2/3] drm/amdgpu/powerplay: Use swap() where appropriate

[Alex Deucher]

On Thu, Oct 10, 2019 at 9:12 AM Ville Syrjala
 wrote:
>
> From: Ville Syrjälä 
>
> @swap@
> identifier TEMP;
> expression A,B;
> @@
> - TEMP = A;
> - A = B;
> - B = TEMP;
> + swap(A, B);
>
> @@
> type T;
> identifier swap.TEMP;
> @@
> (
> - T TEMP;
> |
> - T TEMP = {...};
> )
> ... when != TEMP
>
> Cc: Rex Zhu 
> Cc: Evan Quan 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä 

Reviewed and applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 6 ++
>  drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 6 ++
>  2 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> index 34f95e0e3ea4..1fe992835a76 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> @@ -1994,7 +1994,6 @@ static int smu7_sort_lookup_table(struct pp_hwmgr 
> *hwmgr,
> struct phm_ppt_v1_voltage_lookup_table *lookup_table)
>  {
> uint32_t table_size, i, j;
> -   struct phm_ppt_v1_voltage_lookup_record tmp_voltage_lookup_record;
> table_size = lookup_table->count;
>
> PP_ASSERT_WITH_CODE(0 != lookup_table->count,
> @@ -2005,9 +2004,8 @@ static int smu7_sort_lookup_table(struct pp_hwmgr 
> *hwmgr,
> for (j = i + 1; j > 0; j--) {
> if (lookup_table->entries[j].us_vdd <
> lookup_table->entries[j - 1].us_vdd) {
> -   tmp_voltage_lookup_record = 
> lookup_table->entries[j - 1];
> -   lookup_table->entries[j - 1] = 
> lookup_table->entries[j];
> -   lookup_table->entries[j] = 
> tmp_voltage_lookup_record;
> +   swap(lookup_table->entries[j - 1],
> +lookup_table->entries[j]);
> }
> }
> }
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> index d08493b67b67..f5dcba44f74a 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> @@ -712,7 +712,6 @@ static int vega10_sort_lookup_table(struct pp_hwmgr 
> *hwmgr,
> struct phm_ppt_v1_voltage_lookup_table *lookup_table)
>  {
> uint32_t table_size, i, j;
> -   struct phm_ppt_v1_voltage_lookup_record tmp_voltage_lookup_record;
>
> PP_ASSERT_WITH_CODE(lookup_table && lookup_table->count,
> "Lookup table is empty", return -EINVAL);
> @@ -724,9 +723,8 @@ static int vega10_sort_lookup_table(struct pp_hwmgr 
> *hwmgr,
> for (j = i + 1; j > 0; j--) {
> if (lookup_table->entries[j].us_vdd <
> lookup_table->entries[j - 1].us_vdd) {
> -   tmp_voltage_lookup_record = 
> lookup_table->entries[j - 1];
> -   lookup_table->entries[j - 1] = 
> lookup_table->entries[j];
> -   lookup_table->entries[j] = 
> tmp_voltage_lookup_record;
> +   swap(lookup_table->entries[j - 1],
> +lookup_table->entries[j]);
> }
> }
> }
> --
> 2.21.0
>
> ___
> 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] dma-buf/resv: fix exclusive fence get

[Qiang Yu]

Hi Chris,

This fix has been pushed to drm-misc-next for a while. But Linux
5.4-rc kernels still does not have this fix.
Should it be also pushed to drm-misc-fixes?

Thanks,
Qiang


On Sun, Sep 22, 2019 at 8:50 PM Chris Wilson  wrote:
>
> Quoting Chris Wilson (2019-09-22 13:17:19)
> > Quoting Qiang Yu (2019-09-22 08:49:00)
> > > This causes kernel crash when testing lima driver.
> > >
> > > Cc: Christian König 
> > > Fixes: b8c036dfc66f ("dma-buf: simplify reservation_object_get_fences_rcu 
> > > a bit")
> > > Signed-off-by: Qiang Yu 
> > > ---
> > >  drivers/dma-buf/dma-resv.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > > index 42a8f3f11681..709002515550 100644
> > > --- a/drivers/dma-buf/dma-resv.c
> > > +++ b/drivers/dma-buf/dma-resv.c
> > > @@ -471,7 +471,7 @@ int dma_resv_get_fences_rcu(struct dma_resv *obj,
> > > if (pfence_excl)
> > > *pfence_excl = fence_excl;
> > > else if (fence_excl)
> > > -   shared[++shared_count] = fence_excl;
> > > +   shared[shared_count++] = fence_excl;
> >
> > Oops.
> >
> > Reviewed-by: Chris Wilson 
>
> Applied, thanks for the fix.
> -Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave and Daniel,

This pull request includes the ones we missed for -rc1
drm-intel-next-fixes-2019-09-26 & drm-intel-next-fixes-2019-09-19
plus few fixes for execlists requests and CML display.

Here goes drm-intel-fixes-2019-10-10:
- Fix CML display by adding a missing ID.
- Drop redundant list_del_init
- Only enqueue already completed requests to avoid races
- Fixup preempt-to-busy vs reset of a virtual request
- Protect peeking at execlists->active
- execlists->active is serialised by the tasklet

drm-intel-next-fixes-2019-09-19:
- Extend old HSW workaround to fix some GPU hangs on Haswell GT2
- Fix return error code on GEM mmap.
- White list a chicken bit register for push constants legacy mode on Mesa
- Fix resume issue related to GGTT restore
- Remove incorrect BUG_ON on execlist's schedule-out
- Fix unrecoverable GPU hangs with Vulkan compute workloads on SKL

drm-intel-next-fixes-2019-09-26:
- Fix concurrence on cases where requests where getting retired at same time as 
resubmitted to HW
- Fix gen9 display resolutions by setting the right max plane width
- Fix GPU hang on preemption
- Mark contents as dirty on a write fault. This was breaking cursor sprite with 
dumb buffers.

Thanks,
Rodrigo.

The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce:

  Linux 5.4-rc2 (2019-10-06 14:27:30 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-10-10

for you to fetch changes up to e137d3abdfca0fb6fc270da576a9d9d6a1f8d8b3:

  drm/i915/gt: execlists->active is serialised by the tasklet (2019-10-09 
14:39:31 -0700)


- Fix CML display by adding a missing ID.
- Drop redundant list_del_init
- Only enqueue already completed requests to avoid races
- Fixup preempt-to-busy vs reset of a virtual request
- Protect peeking at execlists->active
- execlists->active is serialised by the tasklet

drm-intel-next-fixes-2019-09-19:
- Extend old HSW workaround to fix some GPU hangs on Haswell GT2
- Fix return error code on GEM mmap.
- White list a chicken bit register for push constants legacy mode on Mesa
- Fix resume issue related to GGTT restore
- Remove incorrect BUG_ON on execlist's schedule-out
- Fix unrecoverable GPU hangs with Vulkan compute workloads on SKL

drm-intel-next-fixes-2019-09-26:
- Fix concurrence on cases where requests where getting retired at same time as 
resubmitted to HW
- Fix gen9 display resolutions by setting the right max plane width
- Fix GPU hang on preemption
- Mark contents as dirty on a write fault. This was breaking cursor sprite with 
dumb buffers.


Chris Wilson (12):
  drm/i915/execlists: Remove incorrect BUG_ON for schedule-out
  drm/i915: Perform GGTT restore much earlier during resume
  drm/i915: Don't mix srcu tag and negative error codes
  drm/i915: Extend Haswell GT1 PSMI workaround to all
  drm/i915: Verify the engine after acquiring the active.lock
  drm/i915: Prevent bonded requests from overtaking each other on preemption
  drm/i915: Mark contents as dirty on a write fault
  drm/i915/execlists: Drop redundant list_del_init(&rq->sched.link)
  drm/i915: Only enqueue already completed requests
  drm/i915: Fixup preempt-to-busy vs reset of a virtual request
  drm/i915/execlists: Protect peeking at execlists->active
  drm/i915/gt: execlists->active is serialised by the tasklet

Kenneth Graunke (1):
  drm/i915: Whitelist COMMON_SLICE_CHICKEN2

Matt Roper (1):
  drm/i915/cml: Add second PCH ID for CMP

Ville Syrjälä (1):
  drm/i915: Bump skl+ max plane width to 5k for linear/x-tiled

 drivers/gpu/drm/i915/display/intel_display.c |  15 +++-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |  12 ++--
 drivers/gpu/drm/i915/gem/i915_gem_pm.c   |   3 -
 drivers/gpu/drm/i915/gt/intel_engine.h   |  14 
 drivers/gpu/drm/i915/gt/intel_engine_cs.c|  16 ++---
 drivers/gpu/drm/i915/gt/intel_lrc.c  | 101 +--
 drivers/gpu/drm/i915/gt/intel_reset.c|  12 ++--
 drivers/gpu/drm/i915/gt/intel_reset.h|   2 +-
 drivers/gpu/drm/i915/gt/intel_ringbuffer.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c  |   3 +
 drivers/gpu/drm/i915/i915_drv.c  |   5 ++
 drivers/gpu/drm/i915/i915_gem.h  |   6 ++
 drivers/gpu/drm/i915/i915_request.c  |  69 ++
 drivers/gpu/drm/i915/i915_request.h  |   2 +-
 drivers/gpu/drm/i915/intel_pch.c |   1 +
 drivers/gpu/drm/i915/intel_pch.h |   1 +
 drivers/gpu/drm/i915/selftests/i915_gem.c|   6 ++
 17 files changed, 188 insertions(+), 82 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf/resv: fix exclusive fence get

[Koenig, Christian]

Hi Qiang,

oh, good point. Yes it certainly should.

Looks like I accidentally pushed it to the wrong branch.

Thanks,
Christian.

Am 10.10.19 um 16:27 schrieb Qiang Yu:
> Hi Chris,
>
> This fix has been pushed to drm-misc-next for a while. But Linux
> 5.4-rc kernels still does not have this fix.
> Should it be also pushed to drm-misc-fixes?
>
> Thanks,
> Qiang
>
>
> On Sun, Sep 22, 2019 at 8:50 PM Chris Wilson  wrote:
>> Quoting Chris Wilson (2019-09-22 13:17:19)
>>> Quoting Qiang Yu (2019-09-22 08:49:00)
 This causes kernel crash when testing lima driver.

 Cc: Christian König 
 Fixes: b8c036dfc66f ("dma-buf: simplify reservation_object_get_fences_rcu 
 a bit")
 Signed-off-by: Qiang Yu 
 ---
   drivers/dma-buf/dma-resv.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
 index 42a8f3f11681..709002515550 100644
 --- a/drivers/dma-buf/dma-resv.c
 +++ b/drivers/dma-buf/dma-resv.c
 @@ -471,7 +471,7 @@ int dma_resv_get_fences_rcu(struct dma_resv *obj,
  if (pfence_excl)
  *pfence_excl = fence_excl;
  else if (fence_excl)
 -   shared[++shared_count] = fence_excl;
 +   shared[shared_count++] = fence_excl;
>>> Oops.
>>>
>>> Reviewed-by: Chris Wilson 
>> Applied, thanks for the fix.
>> -Chris

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

Re: [pull] amdgpu/kfd, radeon, ttm drm-next-5.5

[Alex Deucher]

AOn Thu, Oct 10, 2019 at 5:54 AM Daniel Vetter  wrote:
>
> On Thu, Oct 10, 2019 at 6:17 AM Alex Deucher  wrote:
> >
> > Hi Dave, Daniel,
> >
> > New stuff for 5.5.  There's an export of a cgroup function that
> > Tejun acked for merging through the drm tree. kfd uses it to handle
> > permissions in containers since there is only one /dev/kfd.
> >
> > The following changes since commit 9a60b2990d6c2b7ab935fe0a5cc274de67d98bed:
> >
> >   Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux 
> > into drm-next (2019-09-06 16:58:10 +1000)
> >
> > are available in the Git repository at:
> >
> >   git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.5-2019-10-09
> >
> > for you to fetch changes up to 1cd4d9eead73c004d08a58536dc726bd172eaaec:
> >
> >   drm/amdkfd: update for drmP.h removal (2019-10-09 12:04:48 -0500)
> >
> > 
> > drm-next-5.5-2019-10-09:
> >
> > amdgpu:
> > - Additional RAS enablement for vega20
> > - RAS page retirement and bad page storage in EEPROM
> > - No GPU reset with unrecoverable RAS errors
> > - Reserve vram for page tables rather than trying to evict
> > - Fix issues with GPU reset and xgmi hives
> > - DC i2c over aux fixes
> > - Direct submission for clears, PTE/PDE updates
> > - Improvements to help support recoverable GPU page faults
> > - Silence harmless SAD block messages
> > - Clean up code for creating a bo at a fixed location
> > - Initial DC HDCP support
> > - Lots of documentation fixes
> > - GPU reset for renoir
> > - Add IH clockgating support for soc15 asics
> > - Powerplay improvements
> > - DC MST cleanups
> > - Add support for MSI-X
> > - Misc cleanups and bug fixes
> >
> > amdkfd:
> > - Query KFD device info by asic type rather than pci ids
> > - Add navi14 support
> > - Add renoir support
> > - Add navi12 support
> > - gfx10 trap handler improvements
> > - pasid cleanups
> > - Check against device cgroup
> >
> > ttm:
> > - Return -EBUSY with pipelining with no_gpu_wait
> >
> > radeon:
> > - Silence harmless SAD block messages
> >
> > device_cgroup:
> > - Export devcgroup_check_permission
> >
> > 
> > Aaron Liu (4):
> >   drm/amd/display: update renoir_ip_offset.h
> >   drm/amdgpu: disable stutter mode for renoir
> >   drm/amdgpu: remove program of lbpw for renoir
> >   Revert "drm/amdgpu: disable stutter mode for renoir"
> >
> > Adam Zerella (1):
> >   docs: drm/amdgpu: Resolve build warnings
> >
> > Alex Deucher (20):
> >   drm/amdgpu/irq: check if nbio funcs exist
> >   drm/amdgpu/vm: fix documentation for amdgpu_vm_bo_param
> >   drm/amdgpu/ras: use GPU PAGE_SIZE/SHIFT for reserving pages
> >   drm/amdgpu/psp: flush HDP write fifo after submitting cmds to the psp
> >   drm/amdgpu/psp: invalidate the hdp read cache before reading the psp 
> > response
> >   drm/amdgpu: flag navi12 and 14 as experimental for 5.4
> >   drm/amdgpu: fix documentation for amdgpu_gem_prime_export
> >   drm/amdgpu/mn: fix documentation for amdgpu_mn_read_lock
> >   drm/amdgpu/vm: fix up documentation in amdgpu_vm.c
> >   drm/amdgpu/ih: fix documentation in amdgpu_irq_dispatch
> >   drm/amdgpu: fix documentation for amdgpu_pm.c
> >   drm/amdgpu/ras: fix and update the documentation for RAS
> >   drm/amdgpu/display: fix 64 bit divide
> >   drm/amdgpu/display: include slab.h in dcn21_resource.c
> >   drm/amdgpu/atomfirmware: use proper index for querying vram type (v3)
> >   drm/amdgpu/atomfirmware: simplify the interface to get vram info
> >   drm/amdgpu: don't increment vram lost if we are in hibernation
> >   drm/amdgpu: improve MSI-X handling (v3)
> >   drm/amdgpu: move amdgpu_device_get_job_timeout_settings
> >   drm/amdkfd: fix the build when CIK support is disabled
> >
> > Allen Pais (1):
> >   drm/amdkfd: fix a potential NULL pointer dereference (v2)
> >
> > Alvin Lee (1):
> >   drm/amd/display: Don't allocate payloads if link lost
> >
> > Andrey Grodzovsky (11):
> >   drm/amdgpu: Fix bugs in amdgpu_device_gpu_recover in XGMI case.
> >   drm/amdgpu: Avoid HW GPU reset for RAS.
> >   dmr/amdgpu: Add system auto reboot to RAS.
> >   drm/amdgpu: Add smu lock around in pp_smu_i2c_bus_access
> >   drm/amdgpu: Remove clock gating restore.
> >   drm/madgpu: Fix EEPROM Checksum calculation.
> >   drm/amdgpu: Avoid RAS recovery init when no RAS support.
> >   drm/amdgpu: Add amdgpu_ras_eeprom_reset_table
> >   drm/amdgpu: Allow to reset to EERPOM table.
> >   drm/amdgpu: Fix mutex lock from atomic context.
> >   drm/amdgpu:Fix EEPROM checksum calculation.
> >
> > Anthony Koo (2):
> >   drm/amd/display: 3.2.49
> >   drm/amd/display: set minimum abm backlight level
> >
> > Aric Cyr (4):
> >   drm/amd/display: 3.2.50
> >   drm/amd/display: 3.2.51
> >   drm/amd/display: 3.2.51.1

Re: [pull] amdgpu/kfd, radeon, ttm drm-next-5.5

[Koenig, Christian]

Am 10.10.19 um 16:34 schrieb Alex Deucher:
> AOn Thu, Oct 10, 2019 at 5:54 AM Daniel Vetter  wrote:
>> On Thu, Oct 10, 2019 at 6:17 AM Alex Deucher  wrote:
>>> [SNIP]
>>> Christian König (22):
>>>drm/amdgpu: use moving fence instead of exclusive for VM updates
>>>drm/amdgpu: reserve at least 4MB of VRAM for page tables v2
>>>drm/amdgpu: remove amdgpu_cs_try_evict
>> Patch no handy for a direct reply, so asking here (but this is totally
>> unrelated to the pull):
>>
>> Do you have other stuff than scanout and pagetables that need to be in
>> vram? I was kinda assume this is needed for big vram-only objects to
>> fit, making space by throwing stuff out that could also be put into
>> system memory. But sounds like it was only for making pagetables fit.
> Yes, basically making page tables fit.  If you push a bunch of stuff
> to system ram, your page table requirements go up too.  See the
> discussion here:
> https://www.spinics.net/lists/amd-gfx/msg38640.html

Yeah, typical chicken and egg problem.

When you evict things to system memory because you don't have enough 
VRAM you need more VRAM for page tables so you need to evict even more 
things to system memory

Additional to that we have a few other cases where we really need VRAM 
for correct operation (firmware, old MM engines etc...), but nothing 
major like page tables.

Regards,
Christian.

>
> Alex
>
>> -Daniel
>>
>>

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

Re: [pull] amdgpu/kfd, radeon, ttm drm-next-5.5

[Daniel Vetter]

On Thu, Oct 10, 2019 at 4:37 PM Koenig, Christian
 wrote:
> Am 10.10.19 um 16:34 schrieb Alex Deucher:
> > AOn Thu, Oct 10, 2019 at 5:54 AM Daniel Vetter  
> > wrote:
> >> On Thu, Oct 10, 2019 at 6:17 AM Alex Deucher  wrote:
> >>> [SNIP]
> >>> Christian König (22):
> >>>drm/amdgpu: use moving fence instead of exclusive for VM updates
> >>>drm/amdgpu: reserve at least 4MB of VRAM for page tables v2
> >>>drm/amdgpu: remove amdgpu_cs_try_evict
> >> Patch no handy for a direct reply, so asking here (but this is totally
> >> unrelated to the pull):
> >>
> >> Do you have other stuff than scanout and pagetables that need to be in
> >> vram? I was kinda assume this is needed for big vram-only objects to
> >> fit, making space by throwing stuff out that could also be put into
> >> system memory. But sounds like it was only for making pagetables fit.
> > Yes, basically making page tables fit.  If you push a bunch of stuff
> > to system ram, your page table requirements go up too.  See the
> > discussion here:
> > https://www.spinics.net/lists/amd-gfx/msg38640.html

Yeah read that, that's why I asked whether pagetables was the only big thing.

> Yeah, typical chicken and egg problem.
>
> When you evict things to system memory because you don't have enough
> VRAM you need more VRAM for page tables so you need to evict even more
> things to system memory
>
> Additional to that we have a few other cases where we really need VRAM
> for correct operation (firmware, old MM engines etc...), but nothing
> major like page tables.

Yeah makes sense. Afaiui we'll have a few more big things in vram
only, so I think we'll steal this idea for i915.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] Revert "drm/msm: dpu: Add modeset lock checks where applicable"

[Sean Paul]

From: Sean Paul 

This reverts commit 1dfdb0e107dbe6ebff3f6bbbe4aad0b5aa87bba4.

As Daniel mentions in his email [1], non-blocking commits don't hold the
modeset locks, so we can safely access state as long as these functions
are in the commit path. I'm not entirely sure if these have always been
isolated to the commit path, but they seem to be now.

[1]- https://lists.freedesktop.org/archives/dri-devel/2019-October/239441.html

Fixes: 1dfdb0e107db ("drm/msm: dpu: Add modeset lock checks where applicable")
Cc: Jeykumar Sankaran 
Cc: Rob Clark 
Suggested-by: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 1 -
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index db6c9ccf3be26..c645dd201368b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -282,8 +282,6 @@ enum dpu_intf_mode dpu_crtc_get_intf_mode(struct drm_crtc 
*crtc)
return INTF_MODE_NONE;
}
 
-   WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
-
/* TODO: Returns the first INTF_MODE, could there be multiple values? */
drm_for_each_encoder_mask(encoder, crtc->dev, crtc->state->encoder_mask)
return dpu_encoder_get_intf_mode(encoder);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index e393a423d7d7a..0e68e20d19c87 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -305,7 +305,6 @@ void dpu_kms_encoder_enable(struct drm_encoder *encoder)
if (funcs && funcs->commit)
funcs->commit(encoder);
 
-   WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
drm_for_each_crtc(crtc, dev) {
if (!(crtc->state->encoder_mask & drm_encoder_mask(encoder)))
continue;
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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