[PATCH] drm: aspeed: Select CMA only if available

2019-04-04 Thread Joel Stanley
When building this driver for architectures where CMA is not available.

Fixes: 4f2a8f5898ec ("drm: Add ASPEED GFX driver")
Reported-by: Stephen Rothwell 
Reported-by: kernel test robot 
Signed-off-by: Joel Stanley 
---
This fixes the build break.

Another question is if we need to select this at all, as we have a
reserved memory region to allocate from. I am not familiar with this
area, so advice is welcome.

 drivers/gpu/drm/aspeed/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/aspeed/Kconfig b/drivers/gpu/drm/aspeed/Kconfig
index 42b74d18a41b..1775fb85ec74 100644
--- a/drivers/gpu/drm/aspeed/Kconfig
+++ b/drivers/gpu/drm/aspeed/Kconfig
@@ -4,8 +4,8 @@ config DRM_ASPEED_GFX
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_PANEL
-   select DMA_CMA
-   select CMA
+   select DMA_CMA if HAVE_DMA_CONTIGUOUS
+   select CMA if HAVE_DMA_CONTIGUOUS
select MFD_SYSCON
help
  Chose this option if you have an ASPEED AST2500 SOC Display
-- 
2.20.1

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

Re: [git pull] drm fixes for 5.1-rc4

2019-04-04 Thread pr-tracker-bot
The pull request you sent on Fri, 5 Apr 2019 12:21:09 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-04-05

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

Thank you!

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

linux-next: build failure after merge of the drm-misc tree

2019-04-04 Thread Stephen Rothwell
Hi all,

After merging the drm-misc tree, today's linux-next build (powerpc
allyesconfig) failed like this:

kernel/dma/contiguous.c:19:10: fatal error: asm/dma-contiguous.h: No such file 
or directory
 #include 
  ^~

Caused by commit

  4f2a8f5898ec ("drm: Add ASPEED GFX driver")

I have disabled that driver for today (by making it depend on BROKEN).



-- 
Cheers,
Stephen Rothwell


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

[PATCH] drm/virtio: move drm_connector_update_edid_property() call

2019-04-04 Thread Gerd Hoffmann
drm_connector_update_edid_property can sleep, we must not
call it while holding a spinlock.  Move the callsize.

Reported-by: Max Filippov 
Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index e62fe24b1a2e..5bb0f0a084e9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -619,11 +619,11 @@ static void virtio_gpu_cmd_get_edid_cb(struct 
virtio_gpu_device *vgdev,
output = vgdev->outputs + scanout;
 
new_edid = drm_do_get_edid(>conn, virtio_get_edid_block, resp);
+   drm_connector_update_edid_property(>conn, new_edid);
 
spin_lock(>display_info_lock);
old_edid = output->edid;
output->edid = new_edid;
-   drm_connector_update_edid_property(>conn, output->edid);
spin_unlock(>display_info_lock);
 
kfree(old_edid);
-- 
2.18.1

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

[PATCH 3/3] drm/udl: move to embedding drm device inside udl device.

2019-04-04 Thread Dave Airlie
From: Dave Airlie 

This should help with some of the lifetime issues, and move us away
from load/unload.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/udl/udl_drv.c  | 56 +++---
 drivers/gpu/drm/udl/udl_drv.h  |  9 +++---
 drivers/gpu/drm/udl/udl_fb.c   |  2 +-
 drivers/gpu/drm/udl/udl_main.c | 23 ++
 4 files changed, 53 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index ff47f890e6ad..15c0e3eeaf3b 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -48,10 +48,16 @@ static const struct file_operations udl_driver_fops = {
.llseek = noop_llseek,
 };
 
+static void udl_driver_release(struct drm_device *dev)
+{
+   udl_fini(dev);
+   udl_modeset_cleanup(dev);
+   drm_dev_fini(dev);
+   kfree(dev);
+}
+
 static struct drm_driver driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
-   .load = udl_driver_load,
-   .unload = udl_driver_unload,
.release = udl_driver_release,
 
/* gem hooks */
@@ -75,28 +81,56 @@ static struct drm_driver driver = {
.patchlevel = DRIVER_PATCHLEVEL,
 };
 
+static struct udl_device *udl_driver_create(struct usb_interface *interface)
+{
+   struct usb_device *udev = interface_to_usbdev(interface);
+   struct udl_device *udl;
+   int r;
+
+   udl = kzalloc(sizeof(struct udl_device), GFP_KERNEL);
+   if (!udl)
+   return ERR_PTR(-ENOMEM);
+
+   r = drm_dev_init(>drm, , >dev);
+   if (r) {
+   kfree(udl);
+   return ERR_PTR(r);
+   }
+
+   udl->udev = udev;
+   udl->drm.dev_private = udl;
+
+   r = udl_init(udl);
+   if (r) {
+   drm_dev_fini(>drm);
+   kfree(udl);
+   return ERR_PTR(r);
+   }
+
+   usb_set_intfdata(interface, udl);
+   return udl;
+}
+
+
 static int udl_usb_probe(struct usb_interface *interface,
 const struct usb_device_id *id)
 {
-   struct usb_device *udev = interface_to_usbdev(interface);
-   struct drm_device *dev;
int r;
 
-   dev = drm_dev_alloc(, >dev);
-   if (IS_ERR(dev))
-   return PTR_ERR(dev);
+   struct udl_device *udl = udl_driver_create(interface);
+   if (IS_ERR(udl))
+   return PTR_ERR(udl);
 
-   r = drm_dev_register(dev, (unsigned long)udev);
+   r = drm_dev_register(>drm, 0);
if (r)
goto err_free;
 
-   usb_set_intfdata(interface, dev);
-   DRM_INFO("Initialized udl on minor %d\n", dev->primary->index);
+   DRM_INFO("Initialized udl on minor %d\n", udl->drm.primary->index);
 
return 0;
 
 err_free:
-   drm_dev_put(dev);
+   drm_dev_put(>drm);
return r;
 }
 
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index b3e08e876d62..35c1f33fbc1a 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -50,8 +50,8 @@ struct urb_list {
 struct udl_fbdev;
 
 struct udl_device {
+   struct drm_device drm;
struct device *dev;
-   struct drm_device *ddev;
struct usb_device *udev;
struct drm_crtc *crtc;
 
@@ -71,7 +71,7 @@ struct udl_device {
atomic_t cpu_kcycles_used; /* transpired during pixel processing */
 };
 
-#define to_udl(x) ((x)->dev_private)
+#define to_udl(x) container_of(x, struct udl_device, drm)
 
 struct udl_gem_object {
struct drm_gem_object base;
@@ -104,9 +104,8 @@ struct urb *udl_get_urb(struct drm_device *dev);
 int udl_submit_urb(struct drm_device *dev, struct urb *urb, size_t len);
 void udl_urb_completion(struct urb *urb);
 
-int udl_driver_load(struct drm_device *dev, unsigned long flags);
-void udl_driver_unload(struct drm_device *dev);
-void udl_driver_release(struct drm_device *dev);
+int udl_init(struct udl_device *udl);
+void udl_fini(struct drm_device *dev);
 
 int udl_fbdev_init(struct drm_device *dev);
 void udl_fbdev_cleanup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 590323ea261f..4ab101bf1df0 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -213,7 +213,7 @@ static int udl_fb_open(struct fb_info *info, int user)
struct udl_device *udl = to_udl(dev);
 
/* If the USB device is gone, we don't accept new opens */
-   if (drm_dev_is_unplugged(udl->ddev))
+   if (drm_dev_is_unplugged(>drm))
return -ENODEV;
 
ufbdev->fb_count++;
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 862c099d7c4c..6743eaef4594 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -311,20 +311,12 @@ int udl_submit_urb(struct drm_device *dev, struct urb 
*urb, size_t len)
return ret;
 }
 
-int udl_driver_load(struct drm_device *dev, unsigned long flags)
+int 

[PATCH 2/3] drm/udl: introduce a macro to convert dev to udl.

2019-04-04 Thread Dave Airlie
From: Dave Airlie 

This just makes it easier to later embed drm into udl.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/udl/udl_drv.h  |  2 ++
 drivers/gpu/drm/udl/udl_fb.c   | 10 +-
 drivers/gpu/drm/udl/udl_gem.c  |  2 +-
 drivers/gpu/drm/udl/udl_main.c | 12 ++--
 4 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 4ae67d882eae..b3e08e876d62 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -71,6 +71,8 @@ struct udl_device {
atomic_t cpu_kcycles_used; /* transpired during pixel processing */
 };
 
+#define to_udl(x) ((x)->dev_private)
+
 struct udl_gem_object {
struct drm_gem_object base;
struct page **pages;
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index dd9ffded223b..590323ea261f 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -82,7 +82,7 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, int 
y,
  int width, int height)
 {
struct drm_device *dev = fb->base.dev;
-   struct udl_device *udl = dev->dev_private;
+   struct udl_device *udl = to_udl(dev);
int i, ret;
char *cmd;
cycles_t start_cycles, end_cycles;
@@ -210,7 +210,7 @@ static int udl_fb_open(struct fb_info *info, int user)
 {
struct udl_fbdev *ufbdev = info->par;
struct drm_device *dev = ufbdev->ufb.base.dev;
-   struct udl_device *udl = dev->dev_private;
+   struct udl_device *udl = to_udl(dev);
 
/* If the USB device is gone, we don't accept new opens */
if (drm_dev_is_unplugged(udl->ddev))
@@ -441,7 +441,7 @@ static void udl_fbdev_destroy(struct drm_device *dev,
 
 int udl_fbdev_init(struct drm_device *dev)
 {
-   struct udl_device *udl = dev->dev_private;
+   struct udl_device *udl = to_udl(dev);
int bpp_sel = fb_bpp;
struct udl_fbdev *ufbdev;
int ret;
@@ -480,7 +480,7 @@ int udl_fbdev_init(struct drm_device *dev)
 
 void udl_fbdev_cleanup(struct drm_device *dev)
 {
-   struct udl_device *udl = dev->dev_private;
+   struct udl_device *udl = to_udl(dev);
if (!udl->fbdev)
return;
 
@@ -491,7 +491,7 @@ void udl_fbdev_cleanup(struct drm_device *dev)
 
 void udl_fbdev_unplug(struct drm_device *dev)
 {
-   struct udl_device *udl = dev->dev_private;
+   struct udl_device *udl = to_udl(dev);
struct udl_fbdev *ufbdev;
if (!udl->fbdev)
return;
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index bb7b58407039..3b3e17652bb2 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -203,7 +203,7 @@ int udl_gem_mmap(struct drm_file *file, struct drm_device 
*dev,
 {
struct udl_gem_object *gobj;
struct drm_gem_object *obj;
-   struct udl_device *udl = dev->dev_private;
+   struct udl_device *udl = to_udl(dev);
int ret = 0;
 
mutex_lock(>gem_lock);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 1f8ef34ade24..862c099d7c4c 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -30,7 +30,7 @@
 static int udl_parse_vendor_descriptor(struct drm_device *dev,
   struct usb_device *usbdev)
 {
-   struct udl_device *udl = dev->dev_private;
+   struct udl_device *udl = to_udl(dev);
char *desc;
char *buf;
char *desc_end;
@@ -166,7 +166,7 @@ void udl_urb_completion(struct urb *urb)
 
 static void udl_free_urb_list(struct drm_device *dev)
 {
-   struct udl_device *udl = dev->dev_private;
+   struct udl_device *udl = to_udl(dev);
int count = udl->urbs.count;
struct list_head *node;
struct urb_node *unode;
@@ -199,7 +199,7 @@ static void udl_free_urb_list(struct drm_device *dev)
 
 static int udl_alloc_urb_list(struct drm_device *dev, int count, size_t size)
 {
-   struct udl_device *udl = dev->dev_private;
+   struct udl_device *udl = to_udl(dev);
struct urb *urb;
struct urb_node *unode;
char *buf;
@@ -263,7 +263,7 @@ static int udl_alloc_urb_list(struct drm_device *dev, int 
count, size_t size)
 
 struct urb *udl_get_urb(struct drm_device *dev)
 {
-   struct udl_device *udl = dev->dev_private;
+   struct udl_device *udl = to_udl(dev);
int ret = 0;
struct list_head *entry;
struct urb_node *unode;
@@ -296,7 +296,7 @@ struct urb *udl_get_urb(struct drm_device *dev)
 
 int udl_submit_urb(struct drm_device *dev, struct urb *urb, size_t len)
 {
-   struct udl_device *udl = dev->dev_private;
+   struct udl_device *udl = to_udl(dev);
int ret;
 
BUG_ON(len > udl->urbs.size);
@@ -371,7 +371,7 @@ int udl_drop_usb(struct drm_device *dev)
 
 void udl_driver_unload(struct drm_device *dev)
 {
-   struct udl_device 

[PATCH 1/3] drm/udl: add a release method and delay modeset teardown

2019-04-04 Thread Dave Airlie
From: Dave Airlie 

If we unplug a udl device, the usb callback with deinit the
mode_config struct, however userspace will still have an open
file descriptor and a framebuffer on that device. When userspace
closes the fd, we'll oops because it'll try and look stuff up
in the object idr which we've destroyed.

This punts destroying the mode objects until release time instead.

Reviewed-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/udl/udl_drv.c  | 1 +
 drivers/gpu/drm/udl/udl_drv.h  | 1 +
 drivers/gpu/drm/udl/udl_main.c | 8 +++-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 22cd2d13e272..ff47f890e6ad 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -52,6 +52,7 @@ static struct drm_driver driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
.load = udl_driver_load,
.unload = udl_driver_unload,
+   .release = udl_driver_release,
 
/* gem hooks */
.gem_free_object_unlocked = udl_gem_free_object,
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index e9e9b1ff678e..4ae67d882eae 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -104,6 +104,7 @@ void udl_urb_completion(struct urb *urb);
 
 int udl_driver_load(struct drm_device *dev, unsigned long flags);
 void udl_driver_unload(struct drm_device *dev);
+void udl_driver_release(struct drm_device *dev);
 
 int udl_fbdev_init(struct drm_device *dev);
 void udl_fbdev_cleanup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 9086d0d1b880..1f8ef34ade24 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -379,6 +379,12 @@ void udl_driver_unload(struct drm_device *dev)
udl_free_urb_list(dev);
 
udl_fbdev_cleanup(dev);
-   udl_modeset_cleanup(dev);
kfree(udl);
 }
+
+void udl_driver_release(struct drm_device *dev)
+{
+   udl_modeset_cleanup(dev);
+   drm_dev_fini(dev);
+   kfree(dev);
+}
-- 
2.20.1

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

udl fix + 2 cleanups

2019-04-04 Thread Dave Airlie
The first patch is a repost, Daniel already reviewed it, and I'll put
it into fixes soon, the two follow-ups are for -next.

They move udl over to having the drm device embedded in the udl struct
which hopefully will help with future lifetime issues.

Dave.

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

Re: [PATCH 0/7] some cleanups and uapi clarification for leases

2019-04-04 Thread Dave Airlie
On Thu, 14 Mar 2019 at 18:58, Boris Brezillon
 wrote:
>
> On Thu, 28 Feb 2019 15:49:03 +0100
> Daniel Vetter  wrote:
>
> > Hi all,
> >
> > Nothing too major, only things I did find in all my igt test extending for
> > drm lease is some corner cases around implicit planes and atomic target
> > crtcs. Review and comments very much appreciated.
> >
> > Cheers, Daniel
> >
> > Test-with: 20190228141918.26043-1-daniel.vet...@ffwll.ch
> >
> > Daniel Vetter (7):
> >   drm/leases: Drop object_id validation for negative ids
> >   drm/lease: Drop recursive leads checks
> >   drm/leases: Don't init to 0 in drm_master_create
> >   drm/lease: Check for lessor outside of locks
> >   drm/lease: Make sure implicit planes are leased
> >   drm/atomic: Wire file_priv through for property changes
> >   drm/atomic: -EACCESS for lease-denied crtc lookup
>
> I had a look at patches 5-7 and they seem to do the right thing, but my
> knowledge on DRM leases is quite limited, and given all the corner
> cases of legacy CRTC/plane updates, I'm not comfortable adding my R-b
> on these.

For the series:

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

[git pull] drm fixes for 5.1-rc4

2019-04-04 Thread Dave Airlie
Hi Linus,

Pretty quiet week, just some amdgpu and i915 fixes.

i915:
- deadlock fix
- gvt fixes

amdgpu:
- PCIE dpm feature fix
- Powerplay fixes

Thanks,
Dave.

drm-fixes-2019-04-05:
drm: i915 and amdgpu fixes
The following changes since commit 79a3aaa7b82e3106be97842dedfd8429248896e6:

  Linux 5.1-rc3 (2019-03-31 14:39:29 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-04-05

for you to fetch changes up to 23b5f422e8f42d9d3b7063c05c839a8b0ff5adf5:

  Merge tag 'drm-intel-fixes-2019-04-04' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2019-04-05
10:45:32 +1000)


drm: i915 and amdgpu fixes


Chengming Gui (1):
  drm/amd/amdgpu: fix PCIe dpm feature issue (v3)

Chris Wilson (2):
  drm/i915: Always backoff after a drm_modeset_lock() deadlock
  drm/i915/gvt: Fix kerneldoc typo for intel_vgpu_emulate_hotplug

Dave Airlie (2):
  Merge branch 'drm-fixes-5.1' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2019-04-04' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Evan Quan (3):
  drm/amd/powerplay: add ECC feature bit
  drm/amd/powerplay: correct data type to avoid overflow
  drm/amd/powerplay: fix possible hang with 3+ 4K monitors

Le Ma (1):
  drm/amdgpu: remove unnecessary rlc reset function on gfx9

Paul Hsieh (1):
  drm/amd/display: VBIOS can't be light up HDMI when restart system

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2019-04-04' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Xiong Zhang (1):
  drm/i915/gvt: Correct the calculation of plane size

Yan Zhao (2):
  drm/i915/gvt: do not deliver a workload if its creation fails
  drm/i915/gvt: do not let pin count of shadow mm go negative

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  5 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   |  2 --
 drivers/gpu/drm/amd/display/dc/core/dc_link.c   |  6 ++
 drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c  | 20 ++--
 drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.h  |  1 +
 drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if.h |  5 +++--
 drivers/gpu/drm/i915/gvt/display.c  |  2 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c   |  8 ++--
 drivers/gpu/drm/i915/gvt/gtt.c  |  2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c|  5 +++--
 drivers/gpu/drm/i915/i915_debugfs.c |  5 -
 11 files changed, 44 insertions(+), 17 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/lima: Fix broken compilation.

2019-04-04 Thread Dave Airlie
On Fri, 5 Apr 2019 at 08:43, Rodrigo Vivi  wrote:
>
> On Thu, Apr 04, 2019 at 03:25:38PM -0700, Rodrigo Vivi wrote:
> > From: Rodrigo Vivi 
>
> And it seems that I don't know how to spell my own name anymore! :)
>
> If you decide for this patch please let me know, so we can fix while
> pushing to drm-misc-fixes or tell me to send a v2.
>
> >
> > I'm not entirely sure about the limits we should use
> > here on ARM based driver, but apparently the entry and limit
> > are inverted and UINT_MAX cannot be used directly there.
> >
> > So let's at least for now fix this compilation issue
> > on a compilation only driver:

I ended up writing this as well and squashing it into the merge into drm-next.

Thanks,
Dave.

> >
> > CC [M]  drivers/gpu/drm/lima/lima_ctx.o
> > In file included from ./include/linux/kernel.h:7,
> >  from ./include/asm-generic/bug.h:18,
> >  from ./arch/x86/include/asm/bug.h:83,
> >  from ./include/linux/bug.h:5,
> >  from ./include/linux/mmdebug.h:5,
> >  from ./include/linux/gfp.h:5,
> >  from ./include/linux/slab.h:15,
> >  from drivers/gpu/drm/lima/lima_ctx.c:4:
> > drivers/gpu/drm/lima/lima_ctx.c: In function ‘lima_ctx_create’:
> > ./include/linux/limits.h:13:18: error: incompatible type for argument 4 of 
> > ‘xa_alloc’
> >  #define UINT_MAX (~0U)
> >   ^
> > drivers/gpu/drm/lima/lima_ctx.c:27:41: note: in expansion of macro 
> > ‘UINT_MAX’
> >   err = xa_alloc(>handles, id, ctx, UINT_MAX, GFP_KERNEL);
> >  ^~~~
> > In file included from ./include/linux/radix-tree.h:31,
> >  from ./include/linux/idr.h:15,
> >  from ./include/drm/drm_device.h:7,
> >  from drivers/gpu/drm/lima/lima_device.h:7,
> >  from drivers/gpu/drm/lima/lima_ctx.c:7:
> > ./include/linux/xarray.h:817:32: note: expected ‘struct xa_limit’ but 
> > argument is of type ‘unsigned int’
> >void *entry, struct xa_limit limit, gfp_t gfp)
> > ^
> > make[4]: *** [scripts/Makefile.build:276: drivers/gpu/drm/lima/lima_ctx.o] 
> > Error 1
> > make[3]: *** [scripts/Makefile.build:486: drivers/gpu/drm/lima] Error 2
> > make[2]: *** [scripts/Makefile.build:486: drivers/gpu/drm] Error 2
> > make[1]: *** [scripts/Makefile.build:486: drivers/gpu] Error 2
> > make: *** [Makefile:1051: drivers] Error 2
> >
> > Cc: Qiang Yu 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/lima/lima_ctx.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/lima/lima_ctx.c 
> > b/drivers/gpu/drm/lima/lima_ctx.c
> > index c8d12f7c6894..22fff6caa961 100644
> > --- a/drivers/gpu/drm/lima/lima_ctx.c
> > +++ b/drivers/gpu/drm/lima/lima_ctx.c
> > @@ -23,7 +23,7 @@ int lima_ctx_create(struct lima_device *dev, struct 
> > lima_ctx_mgr *mgr, u32 *id)
> >   goto err_out0;
> >   }
> >
> > - err = xa_alloc(>handles, id, UINT_MAX, ctx, GFP_KERNEL);
> > + err = xa_alloc(>handles, id, ctx, xa_limit_32b, GFP_KERNEL);
> >   if (err < 0)
> >   goto err_out0;
> >
> > --
> > 2.20.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] drm/lima: Fix broken compilation.

2019-04-04 Thread Rodrigo Vivi
On Thu, Apr 04, 2019 at 03:25:38PM -0700, Rodrigo Vivi wrote:
> From: Rodrigo Vivi 

And it seems that I don't know how to spell my own name anymore! :)

If you decide for this patch please let me know, so we can fix while
pushing to drm-misc-fixes or tell me to send a v2.

> 
> I'm not entirely sure about the limits we should use
> here on ARM based driver, but apparently the entry and limit
> are inverted and UINT_MAX cannot be used directly there.
> 
> So let's at least for now fix this compilation issue
> on a compilation only driver:
> 
> CC [M]  drivers/gpu/drm/lima/lima_ctx.o
> In file included from ./include/linux/kernel.h:7,
>  from ./include/asm-generic/bug.h:18,
>  from ./arch/x86/include/asm/bug.h:83,
>  from ./include/linux/bug.h:5,
>  from ./include/linux/mmdebug.h:5,
>  from ./include/linux/gfp.h:5,
>  from ./include/linux/slab.h:15,
>  from drivers/gpu/drm/lima/lima_ctx.c:4:
> drivers/gpu/drm/lima/lima_ctx.c: In function ‘lima_ctx_create’:
> ./include/linux/limits.h:13:18: error: incompatible type for argument 4 of 
> ‘xa_alloc’
>  #define UINT_MAX (~0U)
>   ^
> drivers/gpu/drm/lima/lima_ctx.c:27:41: note: in expansion of macro ‘UINT_MAX’
>   err = xa_alloc(>handles, id, ctx, UINT_MAX, GFP_KERNEL);
>  ^~~~
> In file included from ./include/linux/radix-tree.h:31,
>  from ./include/linux/idr.h:15,
>  from ./include/drm/drm_device.h:7,
>  from drivers/gpu/drm/lima/lima_device.h:7,
>  from drivers/gpu/drm/lima/lima_ctx.c:7:
> ./include/linux/xarray.h:817:32: note: expected ‘struct xa_limit’ but 
> argument is of type ‘unsigned int’
>void *entry, struct xa_limit limit, gfp_t gfp)
> ^
> make[4]: *** [scripts/Makefile.build:276: drivers/gpu/drm/lima/lima_ctx.o] 
> Error 1
> make[3]: *** [scripts/Makefile.build:486: drivers/gpu/drm/lima] Error 2
> make[2]: *** [scripts/Makefile.build:486: drivers/gpu/drm] Error 2
> make[1]: *** [scripts/Makefile.build:486: drivers/gpu] Error 2
> make: *** [Makefile:1051: drivers] Error 2
> 
> Cc: Qiang Yu 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/lima/lima_ctx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/lima/lima_ctx.c b/drivers/gpu/drm/lima/lima_ctx.c
> index c8d12f7c6894..22fff6caa961 100644
> --- a/drivers/gpu/drm/lima/lima_ctx.c
> +++ b/drivers/gpu/drm/lima/lima_ctx.c
> @@ -23,7 +23,7 @@ int lima_ctx_create(struct lima_device *dev, struct 
> lima_ctx_mgr *mgr, u32 *id)
>   goto err_out0;
>   }
>  
> - err = xa_alloc(>handles, id, UINT_MAX, ctx, GFP_KERNEL);
> + err = xa_alloc(>handles, id, ctx, xa_limit_32b, GFP_KERNEL);
>   if (err < 0)
>   goto err_out0;
>  
> -- 
> 2.20.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/lima: Fix broken compilation.

2019-04-04 Thread Rodrigo Vivi
From: Rodrigo Vivi 

I'm not entirely sure about the limits we should use
here on ARM based driver, but apparently the entry and limit
are inverted and UINT_MAX cannot be used directly there.

So let's at least for now fix this compilation issue
on a compilation only driver:

CC [M]  drivers/gpu/drm/lima/lima_ctx.o
In file included from ./include/linux/kernel.h:7,
 from ./include/asm-generic/bug.h:18,
 from ./arch/x86/include/asm/bug.h:83,
 from ./include/linux/bug.h:5,
 from ./include/linux/mmdebug.h:5,
 from ./include/linux/gfp.h:5,
 from ./include/linux/slab.h:15,
 from drivers/gpu/drm/lima/lima_ctx.c:4:
drivers/gpu/drm/lima/lima_ctx.c: In function ‘lima_ctx_create’:
./include/linux/limits.h:13:18: error: incompatible type for argument 4 of 
‘xa_alloc’
 #define UINT_MAX (~0U)
  ^
drivers/gpu/drm/lima/lima_ctx.c:27:41: note: in expansion of macro ‘UINT_MAX’
  err = xa_alloc(>handles, id, ctx, UINT_MAX, GFP_KERNEL);
 ^~~~
In file included from ./include/linux/radix-tree.h:31,
 from ./include/linux/idr.h:15,
 from ./include/drm/drm_device.h:7,
 from drivers/gpu/drm/lima/lima_device.h:7,
 from drivers/gpu/drm/lima/lima_ctx.c:7:
./include/linux/xarray.h:817:32: note: expected ‘struct xa_limit’ but argument 
is of type ‘unsigned int’
   void *entry, struct xa_limit limit, gfp_t gfp)
^
make[4]: *** [scripts/Makefile.build:276: drivers/gpu/drm/lima/lima_ctx.o] 
Error 1
make[3]: *** [scripts/Makefile.build:486: drivers/gpu/drm/lima] Error 2
make[2]: *** [scripts/Makefile.build:486: drivers/gpu/drm] Error 2
make[1]: *** [scripts/Makefile.build:486: drivers/gpu] Error 2
make: *** [Makefile:1051: drivers] Error 2

Cc: Qiang Yu 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/lima/lima_ctx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/lima/lima_ctx.c b/drivers/gpu/drm/lima/lima_ctx.c
index c8d12f7c6894..22fff6caa961 100644
--- a/drivers/gpu/drm/lima/lima_ctx.c
+++ b/drivers/gpu/drm/lima/lima_ctx.c
@@ -23,7 +23,7 @@ int lima_ctx_create(struct lima_device *dev, struct 
lima_ctx_mgr *mgr, u32 *id)
goto err_out0;
}
 
-   err = xa_alloc(>handles, id, UINT_MAX, ctx, GFP_KERNEL);
+   err = xa_alloc(>handles, id, ctx, xa_limit_32b, GFP_KERNEL);
if (err < 0)
goto err_out0;
 
-- 
2.20.1

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

[PATCH v1 10/17] kunit: test: add the concept of assertions

2019-04-04 Thread Brendan Higgins
Add support for assertions which are like expectations except the test
terminates if the assertion is not satisfied.

The idea with assertions is that you use them to state all the
preconditions for your test. Logically speaking, these are the premises
of the test case, so if a premise isn't true, there is no point in
continuing the test case because there are no conclusions that can be
drawn without the premises. Whereas, the expectation is the thing you
are trying to prove. It is not used universally in x-unit style test
frameworks, but I really like it as a convention.  You could still
express the idea of a premise using the above idiom, but I think
KUNIT_ASSERT_* states the intended idea perfectly.

Signed-off-by: Brendan Higgins 
---
 include/kunit/test.h   | 401 -
 kunit/string-stream-test.c |  12 +-
 kunit/test-test.c  |   2 +
 kunit/test.c   |  33 +++
 4 files changed, 439 insertions(+), 9 deletions(-)

diff --git a/include/kunit/test.h b/include/kunit/test.h
index 1b77caeb5d51f..bb2f3e63a3522 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -85,9 +85,10 @@ struct kunit;
  * @name: the name of the test case.
  *
  * A test case is a function with the signature, ``void (*)(struct kunit *)``
- * that makes expectations (see KUNIT_EXPECT_TRUE()) about code under test. 
Each
- * test case is associated with a  kunit_module and will be run after 
the
- * module's init function and followed by the module's exit function.
+ * that makes expectations and assertions (see KUNIT_EXPECT_TRUE() and
+ * KUNIT_ASSERT_TRUE()) about code under test. Each test case is associated 
with
+ * a  kunit_module and will be run after the module's init function and
+ * followed by the module's exit function.
  *
  * A test case should be static and should only be created with the 
KUNIT_CASE()
  * macro; additionally, every array of test cases should be terminated with an
@@ -705,4 +706,398 @@ static inline void kunit_expect_binary(struct kunit *test,
KUNIT_EXPECT_END(test, !IS_ERR_OR_NULL(__ptr), __stream);  \
 } while (0)
 
+static inline struct kunit_stream *kunit_assert_start(struct kunit *test,
+ const char *file,
+ const char *line)
+{
+   struct kunit_stream *stream = kunit_new_stream(test);
+
+   kunit_stream_add(stream, "ASSERTION FAILED at %s:%s\n\t", file, line);
+
+   return stream;
+}
+
+static inline void kunit_assert_end(struct kunit *test,
+   bool success,
+   struct kunit_stream *stream)
+{
+   if (!success) {
+   test->fail(test, stream);
+   test->abort(test);
+   } else {
+   kunit_stream_clear(stream);
+   }
+}
+
+#define KUNIT_ASSERT_START(test) \
+   kunit_assert_start(test, __FILE__, __stringify(__LINE__))
+
+#define KUNIT_ASSERT_END(test, success, stream) \
+   kunit_assert_end(test, success, stream)
+
+#define KUNIT_ASSERT(test, success, message) do { \
+   struct kunit_stream *__stream = KUNIT_ASSERT_START(test);  \
+  \
+   kunit_stream_add(__stream, message);   \
+   KUNIT_ASSERT_END(test, success, __stream); \
+} while (0)
+
+#define KUNIT_ASSERT_MSG(test, success, message, fmt, ...) do {
   \
+   struct kunit_stream *__stream = KUNIT_ASSERT_START(test);  \
+  \
+   kunit_stream_add(__stream, message);   \
+   kunit_stream_add(__stream, fmt, ##__VA_ARGS__);\
+   KUNIT_ASSERT_END(test, success, __stream); \
+} while (0)
+
+#define KUNIT_ASSERT_FAILURE(test, fmt, ...) do { \
+   struct kunit_stream *__stream = KUNIT_ASSERT_START(test);  \
+  \
+   kunit_stream_add(__stream, fmt, ##__VA_ARGS__);\
+   KUNIT_ASSERT_END(test, false, __stream);   \
+} while (0)
+
+/**
+ * KUNIT_ASSERT_TRUE() - Sets an assertion that @condition is true.
+ * @test: The test context object.
+ * @condition: an arbitrary boolean expression. The test fails and aborts when
+ * this does not evaluate to true.
+ *
+ * This and assertions of the form `KUNIT_ASSERT_*` will cause the test case to
+ * fail *and immediately abort* when the specified condition is not met. Unlike
+ * an expectation failure, it will prevent the test case from continuing to 
run;
+ * this is otherwise known as an *assertion failure*.
+ */

[PATCH v1 03/17] kunit: test: add string_stream a std::stream like string builder

2019-04-04 Thread Brendan Higgins
A number of test features need to do pretty complicated string printing
where it may not be possible to rely on a single preallocated string
with parameters.

So provide a library for constructing the string as you go similar to
C++'s std::string.

Signed-off-by: Brendan Higgins 
---
 include/kunit/string-stream.h |  51 
 kunit/Makefile|   3 +-
 kunit/string-stream.c | 144 ++
 3 files changed, 197 insertions(+), 1 deletion(-)
 create mode 100644 include/kunit/string-stream.h
 create mode 100644 kunit/string-stream.c

diff --git a/include/kunit/string-stream.h b/include/kunit/string-stream.h
new file mode 100644
index 0..567a4629406da
--- /dev/null
+++ b/include/kunit/string-stream.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * C++ stream style string builder used in KUnit for building messages.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins 
+ */
+
+#ifndef _KUNIT_STRING_STREAM_H
+#define _KUNIT_STRING_STREAM_H
+
+#include 
+#include 
+#include 
+#include 
+
+struct string_stream_fragment {
+   struct list_head node;
+   char *fragment;
+};
+
+struct string_stream {
+   size_t length;
+   struct list_head fragments;
+
+   /* length and fragments are protected by this lock */
+   spinlock_t lock;
+   struct kref refcount;
+};
+
+struct string_stream *new_string_stream(void);
+
+void destroy_string_stream(struct string_stream *stream);
+
+void string_stream_get(struct string_stream *stream);
+
+int string_stream_put(struct string_stream *stream);
+
+int string_stream_add(struct string_stream *this, const char *fmt, ...);
+
+int string_stream_vadd(struct string_stream *this,
+  const char *fmt,
+  va_list args);
+
+char *string_stream_get_string(struct string_stream *this);
+
+void string_stream_clear(struct string_stream *this);
+
+bool string_stream_is_empty(struct string_stream *this);
+
+#endif /* _KUNIT_STRING_STREAM_H */
diff --git a/kunit/Makefile b/kunit/Makefile
index 5efdc4dea2c08..275b565a0e81f 100644
--- a/kunit/Makefile
+++ b/kunit/Makefile
@@ -1 +1,2 @@
-obj-$(CONFIG_KUNIT) += test.o
+obj-$(CONFIG_KUNIT) += test.o \
+   string-stream.o
diff --git a/kunit/string-stream.c b/kunit/string-stream.c
new file mode 100644
index 0..7018194ecf2fa
--- /dev/null
+++ b/kunit/string-stream.c
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * C++ stream style string builder used in KUnit for building messages.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins 
+ */
+
+#include 
+#include 
+#include 
+
+int string_stream_vadd(struct string_stream *this,
+  const char *fmt,
+  va_list args)
+{
+   struct string_stream_fragment *fragment;
+   int len;
+   va_list args_for_counting;
+   unsigned long flags;
+
+   /* Make a copy because `vsnprintf` could change it */
+   va_copy(args_for_counting, args);
+
+   /* Need space for null byte. */
+   len = vsnprintf(NULL, 0, fmt, args_for_counting) + 1;
+
+   va_end(args_for_counting);
+
+   fragment = kmalloc(sizeof(*fragment), GFP_KERNEL);
+   if (!fragment)
+   return -ENOMEM;
+
+   fragment->fragment = kmalloc(len, GFP_KERNEL);
+   if (!fragment->fragment) {
+   kfree(fragment);
+   return -ENOMEM;
+   }
+
+   len = vsnprintf(fragment->fragment, len, fmt, args);
+   spin_lock_irqsave(>lock, flags);
+   this->length += len;
+   list_add_tail(>node, >fragments);
+   spin_unlock_irqrestore(>lock, flags);
+   return 0;
+}
+
+int string_stream_add(struct string_stream *this, const char *fmt, ...)
+{
+   va_list args;
+   int result;
+
+   va_start(args, fmt);
+   result = string_stream_vadd(this, fmt, args);
+   va_end(args);
+   return result;
+}
+
+void string_stream_clear(struct string_stream *this)
+{
+   struct string_stream_fragment *fragment, *fragment_safe;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   list_for_each_entry_safe(fragment,
+fragment_safe,
+>fragments,
+node) {
+   list_del(>node);
+   kfree(fragment->fragment);
+   kfree(fragment);
+   }
+   this->length = 0;
+   spin_unlock_irqrestore(>lock, flags);
+}
+
+char *string_stream_get_string(struct string_stream *this)
+{
+   struct string_stream_fragment *fragment;
+   size_t buf_len = this->length + 1; /* +1 for null byte. */
+   char *buf;
+   unsigned long flags;
+
+   buf = kzalloc(buf_len, GFP_KERNEL);
+   if (!buf)
+   return NULL;
+
+   spin_lock_irqsave(>lock, flags);
+   list_for_each_entry(fragment, 

[PATCH v1 01/17] kunit: test: add KUnit test runner core

2019-04-04 Thread Brendan Higgins
Add core facilities for defining unit tests; this provides a common way
to define test cases, functions that execute code which is under test
and determine whether the code under test behaves as expected; this also
provides a way to group together related test cases in test suites (here
we call them test_modules).

Just define test cases and how to execute them for now; setting
expectations on code will be defined later.

Signed-off-by: Brendan Higgins 
---
 include/kunit/test.h | 165 ++
 kunit/Kconfig|  16 +
 kunit/Makefile   |   1 +
 kunit/test.c | 168 +++
 4 files changed, 350 insertions(+)
 create mode 100644 include/kunit/test.h
 create mode 100644 kunit/Kconfig
 create mode 100644 kunit/Makefile
 create mode 100644 kunit/test.c

diff --git a/include/kunit/test.h b/include/kunit/test.h
new file mode 100644
index 0..23c2ebedd6dd9
--- /dev/null
+++ b/include/kunit/test.h
@@ -0,0 +1,165 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Base unit test (KUnit) API.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins 
+ */
+
+#ifndef _KUNIT_TEST_H
+#define _KUNIT_TEST_H
+
+#include 
+#include 
+
+struct kunit;
+
+/**
+ * struct kunit_case - represents an individual test case.
+ * @run_case: the function representing the actual test case.
+ * @name: the name of the test case.
+ *
+ * A test case is a function with the signature, ``void (*)(struct kunit *)``
+ * that makes expectations (see KUNIT_EXPECT_TRUE()) about code under test. 
Each
+ * test case is associated with a  kunit_module and will be run after 
the
+ * module's init function and followed by the module's exit function.
+ *
+ * A test case should be static and should only be created with the 
KUNIT_CASE()
+ * macro; additionally, every array of test cases should be terminated with an
+ * empty test case.
+ *
+ * Example:
+ *
+ * .. code-block:: c
+ *
+ * void add_test_basic(struct kunit *test)
+ * {
+ * KUNIT_EXPECT_EQ(test, 1, add(1, 0));
+ * KUNIT_EXPECT_EQ(test, 2, add(1, 1));
+ * KUNIT_EXPECT_EQ(test, 0, add(-1, 1));
+ * KUNIT_EXPECT_EQ(test, INT_MAX, add(0, INT_MAX));
+ * KUNIT_EXPECT_EQ(test, -1, add(INT_MAX, INT_MIN));
+ * }
+ *
+ * static struct kunit_case example_test_cases[] = {
+ * KUNIT_CASE(add_test_basic),
+ * {},
+ * };
+ *
+ */
+struct kunit_case {
+   void (*run_case)(struct kunit *test);
+   const char name[256];
+
+   /* private: internal use only. */
+   bool success;
+};
+
+/**
+ * KUNIT_CASE - A helper for creating a  kunit_case
+ * @test_name: a reference to a test case function.
+ *
+ * Takes a symbol for a function representing a test case and creates a
+ *  kunit_case object from it. See the documentation for
+ *  kunit_case for an example on how to use it.
+ */
+#define KUNIT_CASE(test_name) { .run_case = test_name, .name = #test_name }
+
+/**
+ * struct kunit_module - describes a related collection of  kunit_case 
s.
+ * @name: the name of the test. Purely informational.
+ * @init: called before every test case.
+ * @exit: called after every test case.
+ * @test_cases: a null terminated array of test cases.
+ *
+ * A kunit_module is a collection of related  kunit_case s, such that
+ * @init is called before every test case and @exit is called after every test
+ * case, similar to the notion of a *test fixture* or a *test class* in other
+ * unit testing frameworks like JUnit or Googletest.
+ *
+ * Every  kunit_case must be associated with a kunit_module for KUnit to
+ * run it.
+ */
+struct kunit_module {
+   const char name[256];
+   int (*init)(struct kunit *test);
+   void (*exit)(struct kunit *test);
+   struct kunit_case *test_cases;
+};
+
+/**
+ * struct kunit - represents a running instance of a test.
+ * @priv: for user to store arbitrary data. Commonly used to pass data created
+ * in the init function (see  kunit_module).
+ *
+ * Used to store information about the current context under which the test is
+ * running. Most of this data is private and should only be accessed indirectly
+ * via public functions; the one exception is @priv which can be used by the
+ * test writer to store arbitrary data.
+ */
+struct kunit {
+   void *priv;
+
+   /* private: internal use only. */
+   const char *name; /* Read only after initialization! */
+   spinlock_t lock; /* Gaurds all mutable test state. */
+   bool success; /* Protected by lock. */
+   void (*vprintk)(const struct kunit *test,
+   const char *level,
+   struct va_format *vaf);
+};
+
+int kunit_init_test(struct kunit *test, const char *name);
+
+int kunit_run_tests(struct kunit_module *module);
+
+/**
+ * module_test() - used to register a  kunit_module with KUnit.
+ * @module: a statically allocated  kunit_module.
+ *
+ * 

[PATCH v1 16/17] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec()

2019-04-04 Thread Brendan Higgins
From: Iurii Zaikin 

KUnit tests for initialized data behavior of proc_dointvec that is
explicitly checked in the code. Includes basic parsing tests including
int min/max overflow.

Signed-off-by: Iurii Zaikin 
Signed-off-by: Brendan Higgins 
---
 kernel/Makefile  |   2 +
 kernel/sysctl-test.c | 292 +++
 lib/Kconfig.debug|   6 +
 3 files changed, 300 insertions(+)
 create mode 100644 kernel/sysctl-test.c

diff --git a/kernel/Makefile b/kernel/Makefile
index 6c57e78817dad..c81a8976b6a4b 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -112,6 +112,8 @@ obj-$(CONFIG_HAS_IOMEM) += iomem.o
 obj-$(CONFIG_ZONE_DEVICE) += memremap.o
 obj-$(CONFIG_RSEQ) += rseq.o
 
+obj-$(CONFIG_SYSCTL_KUNIT_TEST) += sysctl-test.o
+
 obj-$(CONFIG_GCC_PLUGIN_STACKLEAK) += stackleak.o
 KASAN_SANITIZE_stackleak.o := n
 KCOV_INSTRUMENT_stackleak.o := n
diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
new file mode 100644
index 0..a0fba6b6fc2dc
--- /dev/null
+++ b/kernel/sysctl-test.c
@@ -0,0 +1,292 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test of proc sysctl.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static int i_zero;
+static int i_one_hundred = 100;
+
+struct test_sysctl_data {
+   int int_0001;
+   int int_0002;
+   int int_0003[4];
+
+   unsigned int uint_0001;
+
+   char string_0001[65];
+};
+
+static struct test_sysctl_data test_data = {
+   .int_0001 = 60,
+   .int_0002 = 1,
+
+   .int_0003[0] = 0,
+   .int_0003[1] = 1,
+   .int_0003[2] = 2,
+   .int_0003[3] = 3,
+
+   .uint_0001 = 314,
+
+   .string_0001 = "(none)",
+};
+
+static void sysctl_test_dointvec_null_tbl_data(struct kunit *test)
+{
+   struct ctl_table table = {
+   .procname = "foo",
+   .data   = NULL,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   .extra1 = _zero,
+   .extra2 = _one_hundred,
+   };
+   void  *buffer = kunit_kzalloc(test, sizeof(int), GFP_USER);
+   size_t len;
+   loff_t pos;
+
+   len = 1234;
+   KUNIT_EXPECT_EQ(test, 0, proc_dointvec(, 0, buffer, , ));
+   KUNIT_EXPECT_EQ(test, 0, len);
+   len = 1234;
+   KUNIT_EXPECT_EQ(test, 0, proc_dointvec(, 1, buffer, , ));
+   KUNIT_EXPECT_EQ(test, 0, len);
+}
+
+static void sysctl_test_dointvec_table_maxlen_unset(struct kunit *test)
+{
+   struct ctl_table table = {
+   .procname = "foo",
+   .data   = _data.int_0001,
+   .maxlen = 0,
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   .extra1 = _zero,
+   .extra2 = _one_hundred,
+   };
+   void  *buffer = kunit_kzalloc(test, sizeof(int), GFP_USER);
+   size_t len;
+   loff_t pos;
+
+   len = 1234;
+   KUNIT_EXPECT_EQ(test, 0, proc_dointvec(, 0, buffer, , ));
+   KUNIT_EXPECT_EQ(test, 0, len);
+   len = 1234;
+   KUNIT_EXPECT_EQ(test, 0, proc_dointvec(, 1, buffer, , ));
+   KUNIT_EXPECT_EQ(test, 0, len);
+}
+
+static void sysctl_test_dointvec_table_len_is_zero(struct kunit *test)
+{
+   struct ctl_table table = {
+   .procname = "foo",
+   .data   = _data.int_0001,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   .extra1 = _zero,
+   .extra2 = _one_hundred,
+   };
+   void  *buffer = kunit_kzalloc(test, sizeof(int), GFP_USER);
+   size_t len;
+   loff_t pos;
+
+   len = 0;
+   KUNIT_EXPECT_EQ(test, 0, proc_dointvec(, 0, buffer, , ));
+   KUNIT_EXPECT_EQ(test, 0, len);
+   KUNIT_EXPECT_EQ(test, 0, proc_dointvec(, 1, buffer, , ));
+   KUNIT_EXPECT_EQ(test, 0, len);
+}
+
+static void sysctl_test_dointvec_table_read_but_position_set(struct kunit 
*test)
+{
+   struct ctl_table table = {
+   .procname = "foo",
+   .data   = _data.int_0001,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   .extra1 = _zero,
+   .extra2 = _one_hundred,
+   };
+   void  *buffer = kunit_kzalloc(test, sizeof(int), GFP_USER);
+   size_t len;
+   loff_t pos;
+
+   len = 1234;
+   pos = 1;
+   KUNIT_EXPECT_EQ(test, 0, proc_dointvec(, 0, buffer, , ));
+   KUNIT_EXPECT_EQ(test, 0, len);
+}
+
+static void sysctl_test_dointvec_happy_single_positive(struct kunit *test)
+{
+   struct ctl_table table = {
+   .procname = "foo",
+   .data   = _data.int_0001,
+   .maxlen = sizeof(int),
+   .mode   = 

[PATCH v1 07/17] kunit: test: add initial tests

2019-04-04 Thread Brendan Higgins
Add a test for string stream along with a simpler example.

Signed-off-by: Brendan Higgins 
---
 kunit/Kconfig  | 12 ++
 kunit/Makefile |  4 ++
 kunit/example-test.c   | 88 ++
 kunit/string-stream-test.c | 61 ++
 4 files changed, 165 insertions(+)
 create mode 100644 kunit/example-test.c
 create mode 100644 kunit/string-stream-test.c

diff --git a/kunit/Kconfig b/kunit/Kconfig
index 64480092b2c24..5cb500355c873 100644
--- a/kunit/Kconfig
+++ b/kunit/Kconfig
@@ -13,4 +13,16 @@ config KUNIT
  special hardware. For more information, please see
  Documentation/kunit/
 
+config KUNIT_TEST
+   bool "KUnit test for KUnit"
+   depends on KUNIT
+   help
+ Enables KUnit test to test KUnit.
+
+config KUNIT_EXAMPLE_TEST
+   bool "Example test for KUnit"
+   depends on KUNIT
+   help
+ Enables example KUnit test to demo features of KUnit.
+
 endmenu
diff --git a/kunit/Makefile b/kunit/Makefile
index 6ddc622ee6b1c..60a9ea6cb4697 100644
--- a/kunit/Makefile
+++ b/kunit/Makefile
@@ -1,3 +1,7 @@
 obj-$(CONFIG_KUNIT) += test.o \
string-stream.o \
kunit-stream.o
+
+obj-$(CONFIG_KUNIT_TEST) +=string-stream-test.o
+
+obj-$(CONFIG_KUNIT_EXAMPLE_TEST) +=example-test.o
diff --git a/kunit/example-test.c b/kunit/example-test.c
new file mode 100644
index 0..3947dd7c8f922
--- /dev/null
+++ b/kunit/example-test.c
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Example KUnit test to show how to use KUnit.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins 
+ */
+
+#include 
+
+/*
+ * This is the most fundamental element of KUnit, the test case. A test case
+ * makes a set EXPECTATIONs and ASSERTIONs about the behavior of some code; if
+ * any expectations or assertions are not met, the test fails; otherwise, the
+ * test passes.
+ *
+ * In KUnit, a test case is just a function with the signature
+ * `void (*)(struct kunit *)`. `struct kunit` is a context object that stores
+ * information about the current test.
+ */
+static void example_simple_test(struct kunit *test)
+{
+   /*
+* This is an EXPECTATION; it is how KUnit tests things. When you want
+* to test a piece of code, you set some expectations about what the
+* code should do. KUnit then runs the test and verifies that the code's
+* behavior matched what was expected.
+*/
+   KUNIT_EXPECT_EQ(test, 1 + 1, 2);
+}
+
+/*
+ * This is run once before each test case, see the comment on
+ * example_test_module for more information.
+ */
+static int example_test_init(struct kunit *test)
+{
+   kunit_info(test, "initializing\n");
+
+   return 0;
+}
+
+/*
+ * Here we make a list of all the test cases we want to add to the test module
+ * below.
+ */
+static struct kunit_case example_test_cases[] = {
+   /*
+* This is a helper to create a test case object from a test case
+* function; its exact function is not important to understand how to
+* use KUnit, just know that this is how you associate test cases with a
+* test module.
+*/
+   KUNIT_CASE(example_simple_test),
+   {},
+};
+
+/*
+ * This defines a suite or grouping of tests.
+ *
+ * Test cases are defined as belonging to the suite by adding them to
+ * `kunit_cases`.
+ *
+ * Often it is desirable to run some function which will set up things which
+ * will be used by every test; this is accomplished with an `init` function
+ * which runs before each test case is invoked. Similarly, an `exit` function
+ * may be specified which runs after every test case and can be used to for
+ * cleanup. For clarity, running tests in a test module would behave as 
follows:
+ *
+ * module.init(test);
+ * module.test_case[0](test);
+ * module.exit(test);
+ * module.init(test);
+ * module.test_case[1](test);
+ * module.exit(test);
+ * ...;
+ */
+static struct kunit_module example_test_module = {
+   .name = "example",
+   .init = example_test_init,
+   .test_cases = example_test_cases,
+};
+
+/*
+ * This registers the above test module telling KUnit that this is a suite of
+ * tests that need to be run.
+ */
+module_test(example_test_module);
diff --git a/kunit/string-stream-test.c b/kunit/string-stream-test.c
new file mode 100644
index 0..b2a98576797c9
--- /dev/null
+++ b/kunit/string-stream-test.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test for struct string_stream.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins 
+ */
+
+#include 
+#include 
+#include 
+
+static void string_stream_test_get_string(struct kunit *test)
+{
+   struct string_stream *stream = new_string_stream();
+   char *output;
+
+   string_stream_add(stream, "Foo");
+   

[PATCH v1 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

2019-04-04 Thread Brendan Higgins
This patch set proposes KUnit, a lightweight unit testing and mocking
framework for the Linux kernel.

Unlike Autotest and kselftest, KUnit is a true unit testing framework;
it does not require installing the kernel on a test machine or in a VM
and does not require tests to be written in userspace running on a host
kernel. Additionally, KUnit is fast: From invocation to completion KUnit
can run several dozen tests in under a second. Currently, the entire
KUnit test suite for KUnit runs in under a second from the initial
invocation (build time excluded).

KUnit is heavily inspired by JUnit, Python's unittest.mock, and
Googletest/Googlemock for C++. KUnit provides facilities for defining
unit test cases, grouping related test cases into test suites, providing
common infrastructure for running tests, mocking, spying, and much more.

## What's so special about unit testing?

A unit test is supposed to test a single unit of code in isolation,
hence the name. There should be no dependencies outside the control of
the test; this means no external dependencies, which makes tests orders
of magnitudes faster. Likewise, since there are no external dependencies,
there are no hoops to jump through to run the tests. Additionally, this
makes unit tests deterministic: a failing unit test always indicates a
problem. Finally, because unit tests necessarily have finer granularity,
they are able to test all code paths easily solving the classic problem
of difficulty in exercising error handling code.

## Is KUnit trying to replace other testing frameworks for the kernel?

No. Most existing tests for the Linux kernel are end-to-end tests, which
have their place. A well tested system has lots of unit tests, a
reasonable number of integration tests, and some end-to-end tests. KUnit
is just trying to address the unit test space which is currently not
being addressed.

## More information on KUnit

There is a bunch of documentation near the end of this patch set that
describes how to use KUnit and best practices for writing unit tests.
For convenience I am hosting the compiled docs here:
https://google.github.io/kunit-docs/third_party/kernel/docs/
Additionally for convenience, I have applied these patches to a branch:
https://kunit.googlesource.com/linux/+/kunit/rfc/v5.1-rc2/v1
The repo may be cloned with:
git clone https://kunit.googlesource.com/linux
This patchset is on the kunit/rfc/v5.1-rc2/v1 branch.

## Changes Since Last Version

Last version was RFC v4. It seemed we were pretty much done with the RFC
phase, so I started the numbering over again. Sorry if anyone finds that
confusing.

 - Reduced usage of object oriented style of member functions as
   suggested by Frank.
 - Did a bunch of heavy clean up of the kunit_abort stuff as suggested
   by Frank and Stephen:
   - Biggest change was to reduce the usage of direct calls of member
 functions.
   - Added a better explanation of what abort is for and further
 explained the rationale for KUNIT_ASSERT_* vs. KUNIT_EXPECT_*
   - Dropped BUG() usage
   - Also moved try_catch interface to a new file since it seemed
 obscured by being mixed in with the code that used it.
 - Fixed some other minor issues pointed out by Stephen.
 - Updated email address of one of the contributors.
 - Dropped DT unittest port since it seemed like there was a lot more
   discussion to be had: it wasn't ready to leave the RFC phase.
   Instead, I added a KUnit test written by Iurii for PROC SYSCTL that
   was requested by Luis some time ago.

For reference, RFC v4 can be found here:
https://lkml.org/lkml/2019/2/14/1144

-- 
2.21.0.392.gf8f6787159e-goog

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

[PATCH v1 12/17] kunit: tool: add Python wrappers for running KUnit tests

2019-04-04 Thread Brendan Higgins
From: Felix Guo 

The ultimate goal is to create minimal isolated test binaries; in the
meantime we are using UML to provide the infrastructure to run tests, so
define an abstract way to configure and run tests that allow us to
change the context in which tests are built without affecting the user.
This also makes pretty and dynamic error reporting, and a lot of other
nice features easier.

kunit_config.py:
  - parse .config and Kconfig files.

kunit_kernel.py: provides helper functions to:
  - configure the kernel using kunitconfig.
  - build the kernel with the appropriate configuration.
  - provide function to invoke the kernel and stream the output back.

Signed-off-by: Felix Guo 
Signed-off-by: Brendan Higgins 
---
 tools/testing/kunit/.gitignore  |   3 +
 tools/testing/kunit/kunit.py|  78 +++
 tools/testing/kunit/kunit_config.py |  66 +
 tools/testing/kunit/kunit_kernel.py | 148 
 tools/testing/kunit/kunit_parser.py | 119 ++
 5 files changed, 414 insertions(+)
 create mode 100644 tools/testing/kunit/.gitignore
 create mode 100755 tools/testing/kunit/kunit.py
 create mode 100644 tools/testing/kunit/kunit_config.py
 create mode 100644 tools/testing/kunit/kunit_kernel.py
 create mode 100644 tools/testing/kunit/kunit_parser.py

diff --git a/tools/testing/kunit/.gitignore b/tools/testing/kunit/.gitignore
new file mode 100644
index 0..c791ff59a37a9
--- /dev/null
+++ b/tools/testing/kunit/.gitignore
@@ -0,0 +1,3 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
\ No newline at end of file
diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
new file mode 100755
index 0..7413ec7351a20
--- /dev/null
+++ b/tools/testing/kunit/kunit.py
@@ -0,0 +1,78 @@
+#!/usr/bin/python3
+# SPDX-License-Identifier: GPL-2.0
+#
+# A thin wrapper on top of the KUnit Kernel
+#
+# Copyright (C) 2019, Google LLC.
+# Author: Felix Guo 
+# Author: Brendan Higgins 
+
+import argparse
+import sys
+import os
+import time
+
+import kunit_config
+import kunit_kernel
+import kunit_parser
+
+parser = argparse.ArgumentParser(description='Runs KUnit tests.')
+
+parser.add_argument('--raw_output', help='don\'t format output from kernel',
+   action='store_true')
+
+parser.add_argument('--timeout', help='maximum number of seconds to allow for '
+   'all tests to run. This does not include time taken to '
+   'build the tests.', type=int, default=300,
+   metavar='timeout')
+
+parser.add_argument('--jobs',
+   help='As in the make command, "Specifies  the number of '
+   'jobs (commands) to run simultaneously."',
+   type=int, default=8, metavar='jobs')
+
+parser.add_argument('--build_dir',
+   help='As in the make command, it specifies the build '
+   'directory.',
+   type=str, default=None, metavar='build_dir')
+
+cli_args = parser.parse_args()
+
+linux = kunit_kernel.LinuxSourceTree()
+
+build_dir = None
+if cli_args.build_dir:
+   build_dir = cli_args.build_dir
+
+config_start = time.time()
+success = linux.build_reconfig(build_dir)
+config_end = time.time()
+if not success:
+   quit()
+
+kunit_parser.print_with_timestamp('Building KUnit Kernel ...')
+
+build_start = time.time()
+
+success = linux.build_um_kernel(jobs=cli_args.jobs, build_dir=build_dir)
+build_end = time.time()
+if not success:
+   quit()
+
+kunit_parser.print_with_timestamp('Starting KUnit Kernel ...')
+test_start = time.time()
+
+if cli_args.raw_output:
+   kunit_parser.raw_output(linux.run_kernel(timeout=cli_args.timeout,
+build_dir=build_dir))
+else:
+   kunit_parser.parse_run_tests(linux.run_kernel(timeout=cli_args.timeout,
+ build_dir=build_dir))
+
+test_end = time.time()
+
+kunit_parser.print_with_timestamp((
+   "Elapsed time: %.3fs total, %.3fs configuring, %.3fs " +
+   "building, %.3fs running.\n") % (test_end - config_start,
+   config_end - config_start, build_end - build_start,
+   test_end - test_start))
diff --git a/tools/testing/kunit/kunit_config.py 
b/tools/testing/kunit/kunit_config.py
new file mode 100644
index 0..167f47d9ab8e4
--- /dev/null
+++ b/tools/testing/kunit/kunit_config.py
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Builds a .config from a kunitconfig.
+#
+# Copyright (C) 2019, Google LLC.
+# Author: Felix Guo 
+# Author: Brendan Higgins 
+
+import collections
+import re
+
+CONFIG_IS_NOT_SET_PATTERN = r'^# CONFIG_\w+ is not set$'
+CONFIG_PATTERN = r'^CONFIG_\w+=\S+$'
+
+KconfigEntryBase = collections.namedtuple('KconfigEntry', ['raw_entry'])
+
+
+class KconfigEntry(KconfigEntryBase):
+
+   def __str__(self) -> str:
+   return self.raw_entry
+
+
+class 

[PATCH v1 13/17] kunit: defconfig: add defconfigs for building KUnit tests

2019-04-04 Thread Brendan Higgins
Add defconfig for UML and a fragment that can be used to configure other
architectures for building KUnit tests. Add option to kunit_tool to use
a defconfig to create the kunitconfig.

Signed-off-by: Brendan Higgins 
---
 arch/um/configs/kunit_defconfig  |  8 
 tools/testing/kunit/configs/all_tests.config |  8 
 tools/testing/kunit/kunit.py | 17 +++--
 tools/testing/kunit/kunit_kernel.py  |  3 ++-
 4 files changed, 33 insertions(+), 3 deletions(-)
 create mode 100644 arch/um/configs/kunit_defconfig
 create mode 100644 tools/testing/kunit/configs/all_tests.config

diff --git a/arch/um/configs/kunit_defconfig b/arch/um/configs/kunit_defconfig
new file mode 100644
index 0..bfe49689038f1
--- /dev/null
+++ b/arch/um/configs/kunit_defconfig
@@ -0,0 +1,8 @@
+CONFIG_OF=y
+CONFIG_OF_UNITTEST=y
+CONFIG_OF_OVERLAY=y
+CONFIG_I2C=y
+CONFIG_I2C_MUX=y
+CONFIG_KUNIT=y
+CONFIG_KUNIT_TEST=y
+CONFIG_KUNIT_EXAMPLE_TEST=y
diff --git a/tools/testing/kunit/configs/all_tests.config 
b/tools/testing/kunit/configs/all_tests.config
new file mode 100644
index 0..bfe49689038f1
--- /dev/null
+++ b/tools/testing/kunit/configs/all_tests.config
@@ -0,0 +1,8 @@
+CONFIG_OF=y
+CONFIG_OF_UNITTEST=y
+CONFIG_OF_OVERLAY=y
+CONFIG_I2C=y
+CONFIG_I2C_MUX=y
+CONFIG_KUNIT=y
+CONFIG_KUNIT_TEST=y
+CONFIG_KUNIT_EXAMPLE_TEST=y
diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
index 7413ec7351a20..63e9fb3b60200 100755
--- a/tools/testing/kunit/kunit.py
+++ b/tools/testing/kunit/kunit.py
@@ -11,6 +11,7 @@ import argparse
 import sys
 import os
 import time
+import shutil
 
 import kunit_config
 import kunit_kernel
@@ -36,14 +37,26 @@ parser.add_argument('--build_dir',
'directory.',
type=str, default=None, metavar='build_dir')
 
-cli_args = parser.parse_args()
+parser.add_argument('--defconfig',
+   help='Uses a default kunitconfig.',
+   action='store_true')
 
-linux = kunit_kernel.LinuxSourceTree()
+def create_default_kunitconfig():
+   if not os.path.exists(kunit_kernel.KUNITCONFIG_PATH):
+   shutil.copyfile('arch/um/configs/kunit_defconfig',
+   kunit_kernel.KUNITCONFIG_PATH)
+
+cli_args = parser.parse_args()
 
 build_dir = None
 if cli_args.build_dir:
build_dir = cli_args.build_dir
 
+if cli_args.defconfig:
+   create_default_kunitconfig()
+
+linux = kunit_kernel.LinuxSourceTree()
+
 config_start = time.time()
 success = linux.build_reconfig(build_dir)
 config_end = time.time()
diff --git a/tools/testing/kunit/kunit_kernel.py 
b/tools/testing/kunit/kunit_kernel.py
index 07c0abf2f47df..bf38768353313 100644
--- a/tools/testing/kunit/kunit_kernel.py
+++ b/tools/testing/kunit/kunit_kernel.py
@@ -14,6 +14,7 @@ import os
 import kunit_config
 
 KCONFIG_PATH = '.config'
+KUNITCONFIG_PATH = 'kunitconfig'
 
 class ConfigError(Exception):
"""Represents an error trying to configure the Linux kernel."""
@@ -81,7 +82,7 @@ class LinuxSourceTree(object):
 
def __init__(self):
self._kconfig = kunit_config.Kconfig()
-   self._kconfig.read_from_file('kunitconfig')
+   self._kconfig.read_from_file(KUNITCONFIG_PATH)
self._ops = LinuxSourceTreeOperations()
 
def clean(self):
-- 
2.21.0.392.gf8f6787159e-goog

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

[PATCH v1 17/17] MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section

2019-04-04 Thread Brendan Higgins
Add entry for the new proc sysctl KUnit test to the PROC SYSCTL section.

Signed-off-by: Brendan Higgins 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index fc2cedbd9b43e..03054e4c6386c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12523,6 +12523,7 @@ S:  Maintained
 F: fs/proc/proc_sysctl.c
 F: include/linux/sysctl.h
 F: kernel/sysctl.c
+F: kernel/sysctl-test.c
 F: tools/testing/selftests/sysctl/
 
 PS3 NETWORK SUPPORT
-- 
2.21.0.392.gf8f6787159e-goog

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

[PATCH v1 15/17] MAINTAINERS: add entry for KUnit the unit testing framework

2019-04-04 Thread Brendan Higgins
Add myself as maintainer of KUnit, the Linux kernel's unit testing
framework.

Signed-off-by: Brendan Higgins 
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3e5a5d263f299..fc2cedbd9b43e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8448,6 +8448,16 @@ S:   Maintained
 F: tools/testing/selftests/
 F: Documentation/dev-tools/kselftest*
 
+KERNEL UNIT TESTING FRAMEWORK (KUnit)
+M: Brendan Higgins 
+L: kunit-...@googlegroups.com
+W: https://google.github.io/kunit-docs/third_party/kernel/docs/
+S: Maintained
+F: Documentation/kunit/
+F: include/kunit/
+F: kunit/
+F: tools/testing/kunit/
+
 KERNEL USERMODE HELPER
 M: Luis Chamberlain 
 L: linux-ker...@vger.kernel.org
-- 
2.21.0.392.gf8f6787159e-goog

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

[PATCH v1 14/17] Documentation: kunit: add documentation for KUnit

2019-04-04 Thread Brendan Higgins
Add documentation for KUnit, the Linux kernel unit testing framework.
- Add intro and usage guide for KUnit
- Add API reference

Signed-off-by: Felix Guo 
Signed-off-by: Brendan Higgins 
---
 Documentation/index.rst   |   1 +
 Documentation/kunit/api/index.rst |  16 ++
 Documentation/kunit/api/test.rst  |  15 +
 Documentation/kunit/faq.rst   |  46 +++
 Documentation/kunit/index.rst |  80 ++
 Documentation/kunit/start.rst | 180 
 Documentation/kunit/usage.rst | 447 ++
 7 files changed, 785 insertions(+)
 create mode 100644 Documentation/kunit/api/index.rst
 create mode 100644 Documentation/kunit/api/test.rst
 create mode 100644 Documentation/kunit/faq.rst
 create mode 100644 Documentation/kunit/index.rst
 create mode 100644 Documentation/kunit/start.rst
 create mode 100644 Documentation/kunit/usage.rst

diff --git a/Documentation/index.rst b/Documentation/index.rst
index 80a421cb935e7..264cfd613a774 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -65,6 +65,7 @@ merged much easier.
kernel-hacking/index
trace/index
maintainer/index
+   kunit/index
 
 Kernel API documentation
 
diff --git a/Documentation/kunit/api/index.rst 
b/Documentation/kunit/api/index.rst
new file mode 100644
index 0..c31c530088153
--- /dev/null
+++ b/Documentation/kunit/api/index.rst
@@ -0,0 +1,16 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+API Reference
+=
+.. toctree::
+
+   test
+
+This section documents the KUnit kernel testing API. It is divided into 3
+sections:
+
+= 
==
+:doc:`test`   documents all of the standard testing API
+  excluding mocking or mocking related 
features.
+= 
==
diff --git a/Documentation/kunit/api/test.rst b/Documentation/kunit/api/test.rst
new file mode 100644
index 0..7c926014f047c
--- /dev/null
+++ b/Documentation/kunit/api/test.rst
@@ -0,0 +1,15 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Test API
+
+
+This file documents all of the standard testing API excluding mocking or 
mocking
+related features.
+
+.. kernel-doc:: include/kunit/test.h
+   :internal:
+
+.. kernel-doc:: include/kunit/kunit-stream.h
+   :internal:
+
diff --git a/Documentation/kunit/faq.rst b/Documentation/kunit/faq.rst
new file mode 100644
index 0..cb8e4fb2257a0
--- /dev/null
+++ b/Documentation/kunit/faq.rst
@@ -0,0 +1,46 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+Frequently Asked Questions
+=
+
+How is this different from Autotest, kselftest, etc?
+
+KUnit is a unit testing framework. Autotest, kselftest (and some others) are
+not.
+
+A `unit test `_ is supposed to
+test a single unit of code in isolation, hence the name. A unit test should be
+the finest granularity of testing and as such should allow all possible code
+paths to be tested in the code under test; this is only possible if the code
+under test is very small and does not have any external dependencies outside of
+the test's control like hardware.
+
+There are no testing frameworks currently available for the kernel that do not
+require installing the kernel on a test machine or in a VM and all require
+tests to be written in userspace and run on the kernel under test; this is true
+for Autotest, kselftest, and some others, disqualifying any of them from being
+considered unit testing frameworks.
+
+What is the difference between a unit test and these other kinds of tests?
+==
+Most existing tests for the Linux kernel would be categorized as an integration
+test, or an end-to-end test.
+
+- A unit test is supposed to test a single unit of code in isolation, hence the
+  name. A unit test should be the finest granularity of testing and as such
+  should allow all possible code paths to be tested in the code under test; 
this
+  is only possible if the code under test is very small and does not have any
+  external dependencies outside of the test's control like hardware.
+- An integration test tests the interaction between a minimal set of 
components,
+  usually just two or three. For example, someone might write an integration
+  test to test the interaction between a driver and a piece of hardware, or to
+  test the interaction between the userspace libraries the kernel provides and
+  the kernel itself; however, one of these tests would probably not test the
+  entire kernel along with hardware interactions and interactions with the
+  userspace.
+- An end-to-end test usually tests the entire system from the 

[PATCH v1 11/17] kunit: test: add test managed resource tests

2019-04-04 Thread Brendan Higgins
From: Avinash Kondareddy 

Tests how tests interact with test managed resources in their lifetime.

Signed-off-by: Avinash Kondareddy 
Signed-off-by: Brendan Higgins 
---
 kunit/test-test.c | 122 ++
 1 file changed, 122 insertions(+)

diff --git a/kunit/test-test.c b/kunit/test-test.c
index 4bd7a34d0a6cb..54add8ca418a0 100644
--- a/kunit/test-test.c
+++ b/kunit/test-test.c
@@ -135,3 +135,125 @@ static struct kunit_module kunit_try_catch_test_module = {
.test_cases = kunit_try_catch_test_cases,
 };
 module_test(kunit_try_catch_test_module);
+
+/*
+ * Context for testing test managed resources
+ * is_resource_initialized is used to test arbitrary resources
+ */
+struct kunit_test_resource_context {
+   struct kunit test;
+   bool is_resource_initialized;
+};
+
+static int fake_resource_init(struct kunit_resource *res, void *context)
+{
+   struct kunit_test_resource_context *ctx = context;
+
+   res->allocation = >is_resource_initialized;
+   ctx->is_resource_initialized = true;
+   return 0;
+}
+
+static void fake_resource_free(struct kunit_resource *res)
+{
+   bool *is_resource_initialized = res->allocation;
+
+   *is_resource_initialized = false;
+}
+
+static void kunit_resource_test_init_resources(struct kunit *test)
+{
+   struct kunit_test_resource_context *ctx = test->priv;
+
+   kunit_init_test(>test, "testing_test_init_test");
+
+   KUNIT_EXPECT_TRUE(test, list_empty(>test.resources));
+}
+
+static void kunit_resource_test_alloc_resource(struct kunit *test)
+{
+   struct kunit_test_resource_context *ctx = test->priv;
+   struct kunit_resource *res;
+   kunit_resource_free_t free = fake_resource_free;
+
+   res = kunit_alloc_resource(>test,
+  fake_resource_init,
+  fake_resource_free,
+  ctx);
+
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, res);
+   KUNIT_EXPECT_EQ(test, >is_resource_initialized, res->allocation);
+   KUNIT_EXPECT_TRUE(test, list_is_last(>node, >test.resources));
+   KUNIT_EXPECT_EQ(test, free, res->free);
+}
+
+static void kunit_resource_test_free_resource(struct kunit *test)
+{
+   struct kunit_test_resource_context *ctx = test->priv;
+   struct kunit_resource *res = kunit_alloc_resource(>test,
+ fake_resource_init,
+ fake_resource_free,
+ ctx);
+
+   kunit_free_resource(>test, res);
+
+   KUNIT_EXPECT_EQ(test, false, ctx->is_resource_initialized);
+   KUNIT_EXPECT_TRUE(test, list_empty(>test.resources));
+}
+
+static void kunit_resource_test_cleanup_resources(struct kunit *test)
+{
+   int i;
+   struct kunit_test_resource_context *ctx = test->priv;
+   struct kunit_resource *resources[5];
+
+   for (i = 0; i < ARRAY_SIZE(resources); i++) {
+   resources[i] = kunit_alloc_resource(>test,
+   fake_resource_init,
+   fake_resource_free,
+   ctx);
+   }
+
+   kunit_cleanup(>test);
+
+   KUNIT_EXPECT_TRUE(test, list_empty(>test.resources));
+}
+
+static int kunit_resource_test_init(struct kunit *test)
+{
+   struct kunit_test_resource_context *ctx =
+   kzalloc(sizeof(*ctx), GFP_KERNEL);
+
+   if (!ctx)
+   return -ENOMEM;
+
+   test->priv = ctx;
+
+   kunit_init_test(>test, "test_test_context");
+
+   return 0;
+}
+
+static void kunit_resource_test_exit(struct kunit *test)
+{
+   struct kunit_test_resource_context *ctx = test->priv;
+
+   kunit_cleanup(>test);
+   kfree(ctx);
+}
+
+static struct kunit_case kunit_resource_test_cases[] = {
+   KUNIT_CASE(kunit_resource_test_init_resources),
+   KUNIT_CASE(kunit_resource_test_alloc_resource),
+   KUNIT_CASE(kunit_resource_test_free_resource),
+   KUNIT_CASE(kunit_resource_test_cleanup_resources),
+   {},
+};
+
+static struct kunit_module kunit_resource_test_module = {
+   .name = "kunit-resource-test",
+   .init = kunit_resource_test_init,
+   .exit = kunit_resource_test_exit,
+   .test_cases = kunit_resource_test_cases,
+};
+module_test(kunit_resource_test_module);
-- 
2.21.0.392.gf8f6787159e-goog

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

[PATCH v1 09/17] kunit: test: add tests for kunit test abort

2019-04-04 Thread Brendan Higgins
Add KUnit tests for the KUnit test abort mechanism (see preceding
commit). Add tests both for general try catch mechanism as well as
non-architecture specific mechanism.

Signed-off-by: Brendan Higgins 
---
 kunit/Makefile|   3 +-
 kunit/test-test.c | 135 ++
 2 files changed, 137 insertions(+), 1 deletion(-)
 create mode 100644 kunit/test-test.c

diff --git a/kunit/Makefile b/kunit/Makefile
index 1f7680cfa11ad..533355867abd2 100644
--- a/kunit/Makefile
+++ b/kunit/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_KUNIT) +=  test.o \
kunit-stream.o \
try-catch.o
 
-obj-$(CONFIG_KUNIT_TEST) +=string-stream-test.o
+obj-$(CONFIG_KUNIT_TEST) +=test-test.o \
+   string-stream-test.o
 
 obj-$(CONFIG_KUNIT_EXAMPLE_TEST) +=example-test.o
diff --git a/kunit/test-test.c b/kunit/test-test.c
new file mode 100644
index 0..c81ae6efb959f
--- /dev/null
+++ b/kunit/test-test.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test for core test infrastructure.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins 
+ */
+#include 
+
+struct kunit_try_catch_test_context {
+   struct kunit_try_catch *try_catch;
+   bool function_called;
+};
+
+void kunit_test_successful_try(void *data)
+{
+   struct kunit *test = data;
+   struct kunit_try_catch_test_context *ctx = test->priv;
+
+   ctx->function_called = true;
+}
+
+void kunit_test_no_catch(void *data)
+{
+   struct kunit *test = data;
+
+   KUNIT_FAIL(test, "Catch should not be called.\n");
+}
+
+static void kunit_test_try_catch_successful_try_no_catch(struct kunit *test)
+{
+   struct kunit_try_catch_test_context *ctx = test->priv;
+   struct kunit_try_catch *try_catch = ctx->try_catch;
+
+   kunit_try_catch_init(try_catch,
+test,
+kunit_test_successful_try,
+kunit_test_no_catch);
+   kunit_try_catch_run(try_catch, test);
+
+   KUNIT_EXPECT_TRUE(test, ctx->function_called);
+}
+
+void kunit_test_unsuccessful_try(void *data)
+{
+   struct kunit *test = data;
+   struct kunit_try_catch_test_context *ctx = test->priv;
+   struct kunit_try_catch *try_catch = ctx->try_catch;
+
+   kunit_try_catch_throw(try_catch);
+   KUNIT_FAIL(test, "This line should never be reached.\n");
+}
+
+void kunit_test_catch(void *data)
+{
+   struct kunit *test = data;
+   struct kunit_try_catch_test_context *ctx = test->priv;
+
+   ctx->function_called = true;
+}
+
+static void kunit_test_try_catch_unsuccessful_try_does_catch(struct kunit 
*test)
+{
+   struct kunit_try_catch_test_context *ctx = test->priv;
+   struct kunit_try_catch *try_catch = ctx->try_catch;
+
+   kunit_try_catch_init(try_catch,
+test,
+kunit_test_unsuccessful_try,
+kunit_test_catch);
+   kunit_try_catch_run(try_catch, test);
+
+   KUNIT_EXPECT_TRUE(test, ctx->function_called);
+}
+
+static void kunit_test_generic_try_catch_successful_try_no_catch(
+   struct kunit *test)
+{
+   struct kunit_try_catch_test_context *ctx = test->priv;
+   struct kunit_try_catch *try_catch = ctx->try_catch;
+
+   try_catch->test = test;
+   kunit_generic_try_catch_init(try_catch);
+   try_catch->try = kunit_test_successful_try;
+   try_catch->catch = kunit_test_no_catch;
+
+   kunit_try_catch_run(try_catch, test);
+
+   KUNIT_EXPECT_TRUE(test, ctx->function_called);
+}
+
+static void kunit_test_generic_try_catch_unsuccessful_try_does_catch(
+   struct kunit *test)
+{
+   struct kunit_try_catch_test_context *ctx = test->priv;
+   struct kunit_try_catch *try_catch = ctx->try_catch;
+
+   try_catch->test = test;
+   kunit_generic_try_catch_init(try_catch);
+   try_catch->try = kunit_test_unsuccessful_try;
+   try_catch->catch = kunit_test_catch;
+
+   kunit_try_catch_run(try_catch, test);
+
+   KUNIT_EXPECT_TRUE(test, ctx->function_called);
+}
+
+static int kunit_try_catch_test_init(struct kunit *test)
+{
+   struct kunit_try_catch_test_context *ctx;
+
+   ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
+   test->priv = ctx;
+
+   ctx->try_catch = kunit_kmalloc(test,
+  sizeof(*ctx->try_catch),
+  GFP_KERNEL);
+
+   return 0;
+}
+
+static struct kunit_case kunit_try_catch_test_cases[] = {
+   KUNIT_CASE(kunit_test_try_catch_successful_try_no_catch),
+   KUNIT_CASE(kunit_test_try_catch_unsuccessful_try_does_catch),
+   KUNIT_CASE(kunit_test_generic_try_catch_successful_try_no_catch),
+   

[PATCH v1 02/17] kunit: test: add test resource management API

2019-04-04 Thread Brendan Higgins
Create a common API for test managed resources like memory and test
objects. A lot of times a test will want to set up infrastructure to be
used in test cases; this could be anything from just wanting to allocate
some memory to setting up a driver stack; this defines facilities for
creating "test resources" which are managed by the test infrastructure
and are automatically cleaned up at the conclusion of the test.

Signed-off-by: Brendan Higgins 
---
 include/kunit/test.h | 109 +++
 kunit/test.c |  95 +
 2 files changed, 204 insertions(+)

diff --git a/include/kunit/test.h b/include/kunit/test.h
index 23c2ebedd6dd9..819edd8db4e81 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -12,6 +12,69 @@
 #include 
 #include 
 
+struct kunit_resource;
+
+typedef int (*kunit_resource_init_t)(struct kunit_resource *, void *);
+typedef void (*kunit_resource_free_t)(struct kunit_resource *);
+
+/**
+ * struct kunit_resource - represents a *test managed resource*
+ * @allocation: for the user to store arbitrary data.
+ * @free: a user supplied function to free the resource. Populated by
+ * kunit_alloc_resource().
+ *
+ * Represents a *test managed resource*, a resource which will automatically be
+ * cleaned up at the end of a test case.
+ *
+ * Example:
+ *
+ * .. code-block:: c
+ *
+ * struct kunit_kmalloc_params {
+ * size_t size;
+ * gfp_t gfp;
+ * };
+ *
+ * static int kunit_kmalloc_init(struct kunit_resource *res, void *context)
+ * {
+ * struct kunit_kmalloc_params *params = context;
+ * res->allocation = kmalloc(params->size, params->gfp);
+ *
+ * if (!res->allocation)
+ * return -ENOMEM;
+ *
+ * return 0;
+ * }
+ *
+ * static void kunit_kmalloc_free(struct kunit_resource *res)
+ * {
+ * kfree(res->allocation);
+ * }
+ *
+ * void *kunit_kmalloc(struct kunit *test, size_t size, gfp_t gfp)
+ * {
+ * struct kunit_kmalloc_params params;
+ * struct kunit_resource *res;
+ *
+ * params.size = size;
+ * params.gfp = gfp;
+ *
+ * res = kunit_alloc_resource(test, kunit_kmalloc_init,
+ * kunit_kmalloc_free, );
+ * if (res)
+ * return res->allocation;
+ * else
+ * return NULL;
+ * }
+ */
+struct kunit_resource {
+   void *allocation;
+   kunit_resource_free_t free;
+
+   /* private: internal use only. */
+   struct list_head node;
+};
+
 struct kunit;
 
 /**
@@ -104,6 +167,7 @@ struct kunit {
const char *name; /* Read only after initialization! */
spinlock_t lock; /* Gaurds all mutable test state. */
bool success; /* Protected by lock. */
+   struct list_head resources; /* Protected by lock. */
void (*vprintk)(const struct kunit *test,
const char *level,
struct va_format *vaf);
@@ -127,6 +191,51 @@ int kunit_run_tests(struct kunit_module *module);
} \
late_initcall(module_kunit_init##module)
 
+/**
+ * kunit_alloc_resource() - Allocates a *test managed resource*.
+ * @test: The test context object.
+ * @init: a user supplied function to initialize the resource.
+ * @free: a user supplied function to free the resource.
+ * @context: for the user to pass in arbitrary data to the init function.
+ *
+ * Allocates a *test managed resource*, a resource which will automatically be
+ * cleaned up at the end of a test case. See  kunit_resource for an
+ * example.
+ */
+struct kunit_resource *kunit_alloc_resource(struct kunit *test,
+   kunit_resource_init_t init,
+   kunit_resource_free_t free,
+   void *context);
+
+void kunit_free_resource(struct kunit *test, struct kunit_resource *res);
+
+/**
+ * kunit_kmalloc() - Like kmalloc() except the allocation is *test managed*.
+ * @test: The test context object.
+ * @size: The size in bytes of the desired memory.
+ * @gfp: flags passed to underlying kmalloc().
+ *
+ * Just like `kmalloc(...)`, except the allocation is managed by the test case
+ * and is automatically cleaned up after the test case concludes. See 
+ * kunit_resource for more information.
+ */
+void *kunit_kmalloc(struct kunit *test, size_t size, gfp_t gfp);
+
+/**
+ * kunit_kzalloc() - Just like kunit_kmalloc(), but zeroes the allocation.
+ * @test: The test context object.
+ * @size: The size in bytes of the desired memory.
+ * @gfp: flags passed to underlying kmalloc().
+ *
+ * See kzalloc() and kunit_kmalloc() for more information.
+ */
+static inline void *kunit_kzalloc(struct kunit *test, size_t size, gfp_t gfp)
+{
+   return kunit_kmalloc(test, size, gfp | __GFP_ZERO);
+}
+
+void 

[PATCH v1 05/17] kunit: test: add the concept of expectations

2019-04-04 Thread Brendan Higgins
Add support for expectations, which allow properties to be specified and
then verified in tests.

Signed-off-by: Brendan Higgins 
---
 include/kunit/test.h | 419 +++
 kunit/test.c |  34 
 2 files changed, 453 insertions(+)

diff --git a/include/kunit/test.h b/include/kunit/test.h
index 4668e8a635954..e441270561ece 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -273,4 +273,423 @@ void __printf(3, 4) kunit_printk(const char *level,
 #define kunit_err(test, fmt, ...) \
kunit_printk(KERN_ERR, test, fmt, ##__VA_ARGS__)
 
+static inline struct kunit_stream *kunit_expect_start(struct kunit *test,
+ const char *file,
+ const char *line)
+{
+   struct kunit_stream *stream = kunit_new_stream(test);
+
+   kunit_stream_add(stream, "EXPECTATION FAILED at %s:%s\n\t", file, line);
+
+   return stream;
+}
+
+static inline void kunit_expect_end(struct kunit *test,
+   bool success,
+   struct kunit_stream *stream)
+{
+   if (!success)
+   test->fail(test, stream);
+   else
+   kunit_stream_clear(stream);
+}
+
+#define KUNIT_EXPECT_START(test) \
+   kunit_expect_start(test, __FILE__, __stringify(__LINE__))
+
+#define KUNIT_EXPECT_END(test, success, stream) \
+   kunit_expect_end(test, success, stream)
+
+#define KUNIT_EXPECT_MSG(test, success, message, fmt, ...) do {
   \
+   struct kunit_stream *__stream = KUNIT_EXPECT_START(test);  \
+  \
+   kunit_stream_add(__stream, message);   \
+   kunit_stream_add(__stream, fmt, ##__VA_ARGS__);\
+   KUNIT_EXPECT_END(test, success, __stream); \
+} while (0)
+
+#define KUNIT_EXPECT(test, success, message) do { \
+   struct kunit_stream *__stream = KUNIT_EXPECT_START(test);  \
+  \
+   kunit_stream_add(__stream, message);   \
+   KUNIT_EXPECT_END(test, success, __stream); \
+} while (0)
+
+/**
+ * KUNIT_SUCCEED() - A no-op expectation. Only exists for code clarity.
+ * @test: The test context object.
+ *
+ * The opposite of KUNIT_FAIL(), it is an expectation that cannot fail. In 
other
+ * words, it does nothing and only exists for code clarity. See
+ * KUNIT_EXPECT_TRUE() for more information.
+ */
+#define KUNIT_SUCCEED(test) do {} while (0)
+
+/**
+ * KUNIT_FAIL() - Always causes a test to fail when evaluated.
+ * @test: The test context object.
+ * @fmt: an informational message to be printed when the assertion is made.
+ * @...: string format arguments.
+ *
+ * The opposite of KUNIT_SUCCEED(), it is an expectation that always fails. In
+ * other words, it always results in a failed expectation, and consequently
+ * always causes the test case to fail when evaluated. See KUNIT_EXPECT_TRUE()
+ * for more information.
+ */
+#define KUNIT_FAIL(test, fmt, ...) do {
   \
+   struct kunit_stream *__stream = KUNIT_EXPECT_START(test);  \
+  \
+   kunit_stream_add(__stream, fmt, ##__VA_ARGS__);\
+   KUNIT_EXPECT_END(test, false, __stream);   \
+} while (0)
+
+/**
+ * KUNIT_EXPECT_TRUE() - Causes a test failure when the expression is not true.
+ * @test: The test context object.
+ * @condition: an arbitrary boolean expression. The test fails when this does
+ * not evaluate to true.
+ *
+ * This and expectations of the form `KUNIT_EXPECT_*` will cause the test case
+ * to fail when the specified condition is not met; however, it will not 
prevent
+ * the test case from continuing to run; this is otherwise known as an
+ * *expectation failure*.
+ */
+#define KUNIT_EXPECT_TRUE(test, condition)\
+   KUNIT_EXPECT(test, (condition),\
+  "Expected " #condition " is true, but is false.\n")
+
+#define KUNIT_EXPECT_TRUE_MSG(test, condition, fmt, ...)  \
+   KUNIT_EXPECT_MSG(test, (condition),\
+   "Expected " #condition " is true, but is 
false.\n",\
+   fmt, ##__VA_ARGS__)
+
+/**
+ * KUNIT_EXPECT_FALSE() - Makes a test failure when the expression is not 
false.
+ * @test: The test context object.
+ * @condition: an arbitrary boolean expression. The test fails when this does
+ * not evaluate 

[PATCH v1 06/17] kbuild: enable building KUnit

2019-04-04 Thread Brendan Higgins
Add KUnit to root Kconfig and Makefile allowing it to actually be built.

Signed-off-by: Brendan Higgins 
---
 Kconfig  | 2 ++
 Makefile | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Kconfig b/Kconfig
index 48a80beab6853..10428501edb78 100644
--- a/Kconfig
+++ b/Kconfig
@@ -30,3 +30,5 @@ source "crypto/Kconfig"
 source "lib/Kconfig"
 
 source "lib/Kconfig.debug"
+
+source "kunit/Kconfig"
diff --git a/Makefile b/Makefile
index c0a34064c5744..639d353f98ca9 100644
--- a/Makefile
+++ b/Makefile
@@ -964,7 +964,7 @@ endif
 PHONY += prepare0
 
 ifeq ($(KBUILD_EXTMOD),)
-core-y += kernel/ certs/ mm/ fs/ ipc/ security/ crypto/ block/
+core-y += kernel/ certs/ mm/ fs/ ipc/ security/ crypto/ block/ kunit/
 
 vmlinux-dirs   := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
 $(core-y) $(core-m) $(drivers-y) $(drivers-m) \
-- 
2.21.0.392.gf8f6787159e-goog

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

[PATCH v1 08/17] kunit: test: add support for test abort

2019-04-04 Thread Brendan Higgins
Add support for aborting/bailing out of test cases, which is needed for
implementing assertions.

An assertion is like an expectation, but bails out of the test case
early if the assertion is not met. The idea with assertions is that you
use them to state all the preconditions for your test. Logically
speaking, these are the premises of the test case, so if a premise isn't
true, there is no point in continuing the test case because there are no
conclusions that can be drawn without the premises. Whereas, the
expectation is the thing you are trying to prove.

Signed-off-by: Brendan Higgins 
---
 include/kunit/test.h  |  13 
 include/kunit/try-catch.h |  91 +
 kunit/Makefile|   3 +-
 kunit/test.c  | 138 +++---
 kunit/try-catch.c |  96 ++
 5 files changed, 332 insertions(+), 9 deletions(-)
 create mode 100644 include/kunit/try-catch.h
 create mode 100644 kunit/try-catch.c

diff --git a/include/kunit/test.h b/include/kunit/test.h
index e441270561ece..1b77caeb5d51f 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct kunit_resource;
 
@@ -166,15 +167,27 @@ struct kunit {
 
/* private: internal use only. */
const char *name; /* Read only after initialization! */
+   struct kunit_try_catch try_catch;
spinlock_t lock; /* Gaurds all mutable test state. */
bool success; /* Protected by lock. */
+   bool death_test; /* Protected by lock. */
struct list_head resources; /* Protected by lock. */
void (*vprintk)(const struct kunit *test,
const char *level,
struct va_format *vaf);
void (*fail)(struct kunit *test, struct kunit_stream *stream);
+   void (*abort)(struct kunit *test);
 };
 
+static inline void kunit_set_death_test(struct kunit *test, bool death_test)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   test->death_test = death_test;
+   spin_unlock_irqrestore(>lock, flags);
+}
+
 int kunit_init_test(struct kunit *test, const char *name);
 
 int kunit_run_tests(struct kunit_module *module);
diff --git a/include/kunit/try-catch.h b/include/kunit/try-catch.h
new file mode 100644
index 0..e85abe044b6b5
--- /dev/null
+++ b/include/kunit/try-catch.h
@@ -0,0 +1,91 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * An API to allow a function, that may fail, to be executed, and recover in a
+ * controlled manner.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins 
+ */
+
+#ifndef _KUNIT_TRY_CATCH_H
+#define _KUNIT_TRY_CATCH_H
+
+#include 
+
+typedef void (*kunit_try_catch_func_t)(void *);
+
+struct kunit;
+
+/*
+ * struct kunit_try_catch - provides a generic way to run code which might 
fail.
+ * @context: used to pass user data to the try and catch functions.
+ *
+ * kunit_try_catch provides a generic, architecture independent way to execute
+ * an arbitrary function of type kunit_try_catch_func_t which may bail out by
+ * calling kunit_try_catch_throw(). If kunit_try_catch_throw() is called, @try
+ * is stopped at the site of invocation and @catch is catch is called.
+ *
+ * struct kunit_try_catch provides a generic interface for the functionality
+ * needed to implement kunit->abort() which in turn is needed for implementing
+ * assertions. Assertions allow stating a precondition for a test simplifying
+ * how test cases are written and presented.
+ *
+ * Assertions are like expectations, except they abort (call
+ * kunit_try_catch_throw()) when the specified condition is not met. This is
+ * useful when you look at a test case as a logical statement about some piece
+ * of code, where assertions are the premises for the test case, and the
+ * conclusion is a set of predicates, rather expectations, that must all be
+ * true. If your premises are violated, it does not makes sense to continue.
+ */
+struct kunit_try_catch {
+   /* private: internal use only. */
+   void (*run)(struct kunit_try_catch *try_catch);
+   void __noreturn (*throw)(struct kunit_try_catch *try_catch);
+   struct kunit *test;
+   struct completion *try_completion;
+   int try_result;
+   kunit_try_catch_func_t try;
+   kunit_try_catch_func_t catch;
+   void *context;
+};
+
+/*
+ * Exposed to be overridden for other architectures.
+ */
+void kunit_try_catch_init_internal(struct kunit_try_catch *try_catch);
+
+static inline void kunit_try_catch_init(struct kunit_try_catch *try_catch,
+   struct kunit *test,
+   kunit_try_catch_func_t try,
+   kunit_try_catch_func_t catch)
+{
+   try_catch->test = test;
+   kunit_try_catch_init_internal(try_catch);
+   try_catch->try = try;
+   try_catch->catch = catch;
+}
+
+static 

[PATCH v1 04/17] kunit: test: add kunit_stream a std::stream like logger

2019-04-04 Thread Brendan Higgins
A lot of the expectation and assertion infrastructure prints out fairly
complicated test failure messages, so add a C++ style log library for
for logging test results.

Signed-off-by: Brendan Higgins 
---
 include/kunit/kunit-stream.h |  85 
 include/kunit/test.h |   2 +
 kunit/Makefile   |   3 +-
 kunit/kunit-stream.c | 149 +++
 kunit/test.c |   8 ++
 5 files changed, 246 insertions(+), 1 deletion(-)
 create mode 100644 include/kunit/kunit-stream.h
 create mode 100644 kunit/kunit-stream.c

diff --git a/include/kunit/kunit-stream.h b/include/kunit/kunit-stream.h
new file mode 100644
index 0..d457a54fe0100
--- /dev/null
+++ b/include/kunit/kunit-stream.h
@@ -0,0 +1,85 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * C++ stream style string formatter and printer used in KUnit for outputting
+ * KUnit messages.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins 
+ */
+
+#ifndef _KUNIT_KUNIT_STREAM_H
+#define _KUNIT_KUNIT_STREAM_H
+
+#include 
+#include 
+
+struct kunit;
+
+/**
+ * struct kunit_stream - a std::stream style string builder.
+ *
+ * A std::stream style string builder. Allows messages to be built up and
+ * printed all at once.
+ */
+struct kunit_stream {
+   /* private: internal use only. */
+   struct kunit *test;
+   spinlock_t lock; /* Guards level. */
+   const char *level;
+   struct string_stream *internal_stream;
+};
+
+/**
+ * kunit_new_stream() - constructs a new  kunit_stream.
+ * @test: The test context object.
+ *
+ * Constructs a new test managed  kunit_stream.
+ */
+struct kunit_stream *kunit_new_stream(struct kunit *test);
+
+/**
+ * kunit_stream_set_level(): sets the level that string should be printed at.
+ * @this: the stream being operated on.
+ * @level: the print level the stream is set to output to.
+ *
+ * Sets the print level at which the stream outputs.
+ */
+void kunit_stream_set_level(struct kunit_stream *this, const char *level);
+
+/**
+ * kunit_stream_add(): adds the formatted input to the internal buffer.
+ * @this: the stream being operated on.
+ * @fmt: printf style format string to append to stream.
+ *
+ * Appends the formatted string, @fmt, to the internal buffer.
+ */
+void __printf(2, 3) kunit_stream_add(struct kunit_stream *this,
+const char *fmt, ...);
+
+/**
+ * kunit_stream_append(): appends the contents of @other to @this.
+ * @this: the stream to which @other is appended.
+ * @other: the stream whose contents are appended to @this.
+ *
+ * Appends the contents of @other to @this.
+ */
+void kunit_stream_append(struct kunit_stream *this, struct kunit_stream 
*other);
+
+/**
+ * kunit_stream_commit(): prints out the internal buffer to the user.
+ * @this: the stream being operated on.
+ *
+ * Outputs the contents of the internal buffer as a kunit_printk formatted
+ * output.
+ */
+void kunit_stream_commit(struct kunit_stream *this);
+
+/**
+ * kunit_stream_clear(): clears the internal buffer.
+ * @this: the stream being operated on.
+ *
+ * Clears the contents of the internal buffer.
+ */
+void kunit_stream_clear(struct kunit_stream *this);
+
+#endif /* _KUNIT_KUNIT_STREAM_H */
diff --git a/include/kunit/test.h b/include/kunit/test.h
index 819edd8db4e81..4668e8a635954 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 
 struct kunit_resource;
 
@@ -171,6 +172,7 @@ struct kunit {
void (*vprintk)(const struct kunit *test,
const char *level,
struct va_format *vaf);
+   void (*fail)(struct kunit *test, struct kunit_stream *stream);
 };
 
 int kunit_init_test(struct kunit *test, const char *name);
diff --git a/kunit/Makefile b/kunit/Makefile
index 275b565a0e81f..6ddc622ee6b1c 100644
--- a/kunit/Makefile
+++ b/kunit/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_KUNIT) += test.o \
-   string-stream.o
+   string-stream.o \
+   kunit-stream.o
diff --git a/kunit/kunit-stream.c b/kunit/kunit-stream.c
new file mode 100644
index 0..93c14eec03844
--- /dev/null
+++ b/kunit/kunit-stream.c
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * C++ stream style string formatter and printer used in KUnit for outputting
+ * KUnit messages.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins 
+ */
+
+#include 
+#include 
+#include 
+
+const char *kunit_stream_get_level(struct kunit_stream *this)
+{
+   unsigned long flags;
+   const char *level;
+
+   spin_lock_irqsave(>lock, flags);
+   level = this->level;
+   spin_unlock_irqrestore(>lock, flags);
+
+   return level;
+}
+
+void kunit_stream_set_level(struct kunit_stream *this, const char *level)
+{
+   unsigned long flags;
+
+   

[Bug 201273] Fatal error during GPU init amdgpu RX560

2019-04-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=201273

--- Comment #39 from quirin.blae...@freenet.de ---
Bug is still alive. v5.0.5

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

[PULL] drm-misc-next

2019-04-04 Thread Sean Paul

Hi Da.*,
So this one is a blockbuster!

We've got 1 new gpu, 1 new display controller, 2 new panels, 4 new ioctls, and 1
new encoder.

Everything seems to check out on my side of the world, please pull.

drm-misc-next-2019-04-04:
drm-misc-next for 5.2:

UAPI Changes:
-syncobj: Add TIMELINE_WAIT|QUERY|TRANSFER|TIMELINE_SIGNAL ioctls (Chunming)
-Clarify that 1.0 can be represented by drm_color_lut (Daniel)

Cross-subsystem Changes:
-dt-bindings: Add binding for rk3066 hdmi (Johan)
-dt-bindings: Add binding for Feiyang FY07024DI26A30-D panel (Jagan)
-dt-bindings: Add Rocktech vendor prefix and jh057n00900 panel bindings (Guido)
-MAINTAINERS: Add lima and ASPEED entries (Joel & Qiang)

Core Changes:
-memory: use dma_alloc_coherent when mem encryption is active (Christian)
-dma_buf: add support for a dma_fence chain (Christian)
-shmem_gem: fix off-by-one bug in new shmem gem helpers (Dan)

Driver Changes:
-rockchip: Add support for rk3066 hdmi (Johan)
-ASPEED: Add driver supporting ASPEED BMC display controller to drm (Joel)
-lima: Add driver supporting Arm Mali4xx gpus to drm (Qiang)
-vc4/v3d: Various cleanups and improved error handling (Eric)
-panel: Add support for Feiyang FY07024DI26A30-D MIPI-DSI panel (Jagan)
-panel: Add support for Rocktech jh057n00900 MIPI-DSI panel (Guido)

Cc: Johan Jonker 
Cc: Christian König 
Cc: Chunming Zhou 
Cc: Dan Carpenter 
Cc: Eric Anholt 
Cc: Qiang Yu 
Cc: Daniel Vetter 
Cc: Jagan Teki 
Cc: Guido Günther 
Cc: Joel Stanley 

Cheers, Sean


The following changes since commit 530b28426a94b822b3c03491cde5c9a961d80e7f:

  drm/virtio: rework resource creation workflow. (2019-03-28 12:11:56 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-04-04

for you to fetch changes up to f15a3ea80391e83f32d4a23f83b1f02415cd5889:

  MAINTAINERS: Add ASPEED BMC GFX DRM driver entry (2019-04-04 11:57:34 +1030)


drm-misc-next for 5.2:

UAPI Changes:
-syncobj: Add TIMELINE_WAIT|QUERY|TRANSFER|TIMELINE_SIGNAL ioctls (Chunming)
-Clarify that 1.0 can be represented by drm_color_lut (Daniel)

Cross-subsystem Changes:
-dt-bindings: Add binding for rk3066 hdmi (Johan)
-dt-bindings: Add binding for Feiyang FY07024DI26A30-D panel (Jagan)
-dt-bindings: Add Rocktech vendor prefix and jh057n00900 panel bindings (Guido)
-MAINTAINERS: Add lima and ASPEED entries (Joel & Qiang)

Core Changes:
-memory: use dma_alloc_coherent when mem encryption is active (Christian)
-dma_buf: add support for a dma_fence chain (Christian)
-shmem_gem: fix off-by-one bug in new shmem gem helpers (Dan)

Driver Changes:
-rockchip: Add support for rk3066 hdmi (Johan)
-ASPEED: Add driver supporting ASPEED BMC display controller to drm (Joel)
-lima: Add driver supporting Arm Mali4xx gpus to drm (Qiang)
-vc4/v3d: Various cleanups and improved error handling (Eric)
-panel: Add support for Feiyang FY07024DI26A30-D MIPI-DSI panel (Jagan)
-panel: Add support for Rocktech jh057n00900 MIPI-DSI panel (Guido)

Cc: Johan Jonker 
Cc: Christian König 
Cc: Chunming Zhou 
Cc: Dan Carpenter 
Cc: Eric Anholt 
Cc: Qiang Yu 
Cc: Daniel Vetter 
Cc: Jagan Teki 
Cc: Guido Günther 
Cc: Joel Stanley 


Christian König (4):
  drm: fallback to dma_alloc_coherent when memory encryption is active
  dma-buf: add new dma_fence_chain container v7
  drm/syncobj: add new drm_syncobj_add_point interface v4
  drm/syncobj: use the timeline point in drm_syncobj_find_fence v4

Chunming Zhou (4):
  drm/syncobj: add support for timeline point wait v8
  drm/syncobj: add timeline payload query ioctl v6
  drm/syncobj: add transition iotcls between binary and timeline v2
  drm/syncobj: add timeline signal ioctl for syncobj v5

Dan Carpenter (2):
  drm/v3d: fix a NULL vs error pointer mixup
  drm: shmem: Off by one in drm_gem_shmem_fault()

Daniel Vetter (1):
  drm/gamma: Clarify gamma lut uapi

Eric Anholt (10):
  drm/vc4: Make sure to emit a tile coordinates between two MSAA loads.
  drm/v3d: Add a note about OOM vs FLDONE, which may be racing on v3.3.
  drm/v3d: Rename the fence signaled from IRQs to "irq_fence".
  drm: Add a helper function for printing a debugfs_regset32.
  drm/vc4: Use drm_print_regset32() for our debug register dumping.
  drm/vc4: Use drm_printer for the debugfs and runtime bo stats output.
  drm/vc4: Add helpers for pm get/put.
  drm/vc4: Make sure that the v3d ident debugfs has vc4's power on.
  drm/vc4: Use common helpers for debugfs setup by the driver components.
  drm/vc4: Disable V3D interactions if the v3d component didn't probe.

Gerd Hoffmann (5):
  drm/virtio: add missing drm_atomic_helper_shutdown() call.
  drm/bochs: add missing drm_atomic_helper_shutdown() call.
  drm/cirrus: add missing drm_helper_force_disable_all() call.
  drm/bochs: drop 

Re: [PATCH v4 3/4] drm/vc4: Check for the binner bo before handling OOM interrupt

2019-04-04 Thread Eric Anholt
Paul Kocialkowski  writes:

> Hey,
>
> Le mercredi 03 avril 2019 à 11:58 -0700, Eric Anholt a écrit :
>> Paul Kocialkowski  writes:
>> 
>> > Since the OOM interrupt directly deals with the binner bo, it doesn't
>> > make sense to try and handle it without a binner buffer registered.
>> > The interrupt will kick again in due time, so we can safely ignore it
>> > without a binner bo allocated.
>> > 
>> > Signed-off-by: Paul Kocialkowski 
>> > ---
>> >  drivers/gpu/drm/vc4/vc4_irq.c | 3 +++
>> >  1 file changed, 3 insertions(+)
>> > 
>> > diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
>> > index ffd0a4388752..723dc86b4511 100644
>> > --- a/drivers/gpu/drm/vc4/vc4_irq.c
>> > +++ b/drivers/gpu/drm/vc4/vc4_irq.c
>> > @@ -64,6 +64,9 @@ vc4_overflow_mem_work(struct work_struct *work)
>> >struct vc4_exec_info *exec;
>> >unsigned long irqflags;
>> 
>> Since OOM handling is tricky, could we add a comment to help the next
>> person try to understand it:
>> 
>> /* The OOM IRQ is level-triggered, so we'll see one at power-on before
>>  * any jobs are submitted.  The OOM IRQ is masked when this work is
>>  * scheduled, so we can safely return if there's no binner memory
>>  * (because no client is currently using 3D).  When a bin job is
>>  * later submitted, its tile memory allocation will end up bringing us
>>  * back to a non-OOM state so the OOM can be triggered again.
>>  */
>> 
>> But, actually, I don't see how the OOM IRQ will ever get re-enabled.
>
> Okay so I investigated that to try and understand what's going on.
> We are definitely writing the OUTOMEM bit to V3D_INTDIS just before
> scheduling the workqueue, and never re-enable the IRQ when leaving
> early in the workqueue because !vc4->bin_bo.
>
> It turns out that what saves us here is vc4_irq_postinstall being
> called from runtime resume at "the right time". Obviously this is more
> than fragile, so we should really be re-enabling the IRQ as soon as we
> have the binner bo allocated.
>
> Since we're now allocating at the first non-dumb bo alloc, I think we
> need to make sure that we did in fact get the irq and registered the
> allocated BO with the workqueue before submitting the rcl. Or does the
> hardware provide any mechanism to take that off our hands somehow?

Maybe just enable the OOM interrupt using INTENA in the bin BO
allocation's success case?  That feels race-free, since it's a level
interrupt and even if we were racing the !bin_bo check in the work, we'd
end up re-scheduling the work?


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

Re: [PATCH 5/7] drm/pl111: fix possible object reference leak

2019-04-04 Thread Eric Anholt
Wen Yang  writes:

> The call to of_find_matching_node_and_match returns a node pointer with
> refcount incremented thus it must be explicitly decremented after the
> last usage.

Pushed to drm-misc-next.  Thanks!


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

Re: [PATCH] drm/panel: Rocktech jh057n00900: Add terminating newlines to logging

2019-04-04 Thread Sam Ravnborg
Hi Joe.

> > >  
> > >   ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> > >   if (ret < 0) {
> > > - DRM_DEV_ERROR(dev, "Failed to exit sleep mode");
> > > + DRM_DEV_ERROR(dev, "Failed to exit sleep mode\n");
> > 
> > I was under the impression that newlines was optional these days.
> > Should we always use them with logging?
> 
> Yes.
> 
> The general problem is KERN_CONT/pr_cont uses where interleaving
> is still possible from multiple threads.
> 
> > I did not find any obvious clues in linux/printk.h
> 
> I'll see about adding something one day to the Documentation.
> Likely in coding-style.rst.

Thanks for the clarification.
A seperate doc on logging would be awesome.

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

[Bug 109648] AMD Raven hang during va-api decoding

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109648

--- Comment #6 from Alex Deucher  ---
Fixed in:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=d4e0fbc92fd08be504f328144c874da47b78e5dc

-- 
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 109648] AMD Raven hang during va-api decoding

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109648

Alex Deucher  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

-- 
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 109648] AMD Raven hang during va-api decoding

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109648

--- Comment #5 from Michael Eagle  ---
Hello,

Sorry for the late reply, I've just tested it using mesa git SHA 138865e ,
which includes this commit. And the issue seems solved.
I suppose this can be closed now.
Thank you much!

-- 
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/panel: Rocktech jh057n00900: Add terminating newlines to logging

2019-04-04 Thread Joe Perches
On Thu, 2019-04-04 at 19:00 +0200, Sam Ravnborg wrote:
> Hi Joe.
> 
> On Thu, Apr 04, 2019 at 08:06:09AM -0700, Joe Perches wrote:
> > These were missing '\n' terminations, add them.
> > 
> > Signed-off-by: Joe Perches 
> > ---
> >  drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 19 ++-
> >  1 file changed, 10 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c 
> > b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> > index 158a6d548068..d88ea8da2ec2 100644
> > --- a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> > +++ b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> > @@ -123,7 +123,7 @@ static int jh057n_init_sequence(struct jh057n *ctx)
> >  
> > ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> > if (ret < 0) {
> > -   DRM_DEV_ERROR(dev, "Failed to exit sleep mode");
> > +   DRM_DEV_ERROR(dev, "Failed to exit sleep mode\n");
> 
> I was under the impression that newlines was optional these days.
> Should we always use them with logging?

Yes.

The general problem is KERN_CONT/pr_cont uses where interleaving
is still possible from multiple threads.

> I did not find any obvious clues in linux/printk.h

I'll see about adding something one day to the Documentation.
Likely in coding-style.rst.



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

Re: [PATCH v2 3/6] drm: move tinydrm_xrgb8888_to_rgb565() to drm_fb_helper.c

2019-04-04 Thread Noralf Trønnes


Den 04.04.2019 17.24, skrev Gerd Hoffmann:
> Also rename to drm_fb_xrgb_to_rgb565().
> Pure code motion, no functional change.
> 
> Signed-off-by: Gerd Hoffmann 
> ---


> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index fabeb408dce6..087e49741094 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -3380,3 +3380,48 @@ void drm_fb_memcpy(void *dst, void *vaddr, struct 
> drm_framebuffer *fb,
>   }
>  }
>  EXPORT_SYMBOL(drm_fb_memcpy);
> +
> +/**
> + * drm_fb_xrgb_to_rgb565 - Convert XRGB to RGB565 clip buffer
> + * @dst: RGB565 destination buffer
> + * @vaddr: XRGB source buffer
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + * @swap: Swap bytes
> + *
> + * Drivers can use this function for RGB565 devices that don't natively
> + * support XRGB.
> + */
> +void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
> +struct drm_framebuffer *fb,
> +struct drm_rect *clip, bool swap)
> +{
> + size_t len = (clip->x2 - clip->x1) * sizeof(u32);
> + unsigned int x, y;
> + u32 *src, *buf;
> + u16 val16;
> +
> + buf = kmalloc(len, GFP_KERNEL);

It's not obvious what purpose this buffer serves and there's no help
from the surrounding functions either (tinydrm_swab16() has a comment).

I think we need a comment, something along these lines:

/*
 * Write-combined buffers have uncached reads.
 * Speed up by fetching one line at a time.
 */

Noralf.

> + if (!buf)
> + return;
> +
> + for (y = clip->y1; y < clip->y2; y++) {
> + src = vaddr + (y * fb->pitches[0]);
> + src += clip->x1;
> + memcpy(buf, src, len);
> + src = buf;
> + for (x = clip->x1; x < clip->x2; x++) {
> + val16 = ((*src & 0x00F8) >> 8) |
> + ((*src & 0xFC00) >> 5) |
> + ((*src & 0x00F8) >> 3);
> + src++;
> + if (swap)
> + *dst++ = swab16(val16);
> + else
> + *dst++ = val16;
> + }
> + }
> +
> + kfree(buf);
> +}
> +EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
> b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> index f5c6f35e6161..f4b84b15da75 100644
> --- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> @@ -61,51 +61,6 @@ void tinydrm_swab16(u16 *dst, void *vaddr, struct 
> drm_framebuffer *fb,
>  }
>  EXPORT_SYMBOL(tinydrm_swab16);
>  
> -/**
> - * tinydrm_xrgb_to_rgb565 - Convert XRGB to RGB565 clip buffer
> - * @dst: RGB565 destination buffer
> - * @vaddr: XRGB source buffer
> - * @fb: DRM framebuffer
> - * @clip: Clip rectangle area to copy
> - * @swap: Swap bytes
> - *
> - * Drivers can use this function for RGB565 devices that don't natively
> - * support XRGB.
> - */
> -void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
> - struct drm_framebuffer *fb,
> - struct drm_rect *clip, bool swap)
> -{
> - size_t len = (clip->x2 - clip->x1) * sizeof(u32);
> - unsigned int x, y;
> - u32 *src, *buf;
> - u16 val16;
> -
> - buf = kmalloc(len, GFP_KERNEL);
> - if (!buf)
> - return;
> -
> - for (y = clip->y1; y < clip->y2; y++) {
> - src = vaddr + (y * fb->pitches[0]);
> - src += clip->x1;
> - memcpy(buf, src, len);
> - src = buf;
> - for (x = clip->x1; x < clip->x2; x++) {
> - val16 = ((*src & 0x00F8) >> 8) |
> - ((*src & 0xFC00) >> 5) |
> - ((*src & 0x00F8) >> 3);
> - src++;
> - if (swap)
> - *dst++ = swab16(val16);
> - else
> - *dst++ = val16;
> - }
> - }
> -
> - kfree(buf);
> -}
> -EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
> -
>  /**
>   * tinydrm_xrgb_to_gray8 - Convert XRGB to grayscale
>   * @dst: 8-bit grayscale destination buffer
> diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
> b/drivers/gpu/drm/tinydrm/mipi-dbi.c
> index e26fd61360a3..cf8df5fb7494 100644
> --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
> +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
> @@ -224,7 +224,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer 
> *fb,
>   drm_fb_memcpy(dst, src, fb, clip, false);
>   break;
>   case DRM_FORMAT_XRGB:
> - tinydrm_xrgb_to_rgb565(dst, src, fb, clip, swap);
> + drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap);
>   break;
>   

Re: [PATCH v2 1/6] drm: move tinydrm_memcpy() to drm_fb_helper.c

2019-04-04 Thread Noralf Trønnes


Den 04.04.2019 17.24, skrev Gerd Hoffmann:
> Also rename to drm_fb_memcpy().
> Pure code motion, no functional change.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/drm/drm_fb_helper.h   |  3 +++
>  include/drm/tinydrm/tinydrm-helpers.h |  2 --
>  drivers/gpu/drm/drm_fb_helper.c   | 25 +++

drm_fb_helper.c is for fbdev code so not a good place for this code, and
it's MIT licensed as well.
Daniel have in two rounds suggested a new drm_framebuffer_helper.c or
drm_format_helper.c as possible destinations for these functions.

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

[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109206

--- Comment #30 from Chris  ---
(In reply to Talha Khan from comment #29)
> Also, it seems that for the HP Envy x360 laptop, the latest BIOS is back to
> F.10; F.20 is listed in "previous versions".
> 
> https://support.hp.com/us-en/drivers/selfservice/hp-envy-15-bq100-x360-
> convertible-pc/16851053
> 
> Unfortunately there doesn't seem to be a way to downgrade.

Yes renaming should work. I didn't want to delete it either so I just backed up
the file and deleted it. F20 is the latest, their site is just wonky. Although
I hate that you can't downgrade I partially agree with the decision since it
includes security updates you shouldn't roll back. They take that very
seriously and I can objectively appreciate that

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

[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109206

--- Comment #29 from Talha Khan  ---
Also, it seems that for the HP Envy x360 laptop, the latest BIOS is back to
F.10; F.20 is listed in "previous versions".

https://support.hp.com/us-en/drivers/selfservice/hp-envy-15-bq100-x360-convertible-pc/16851053

Unfortunately there doesn't seem to be a way to downgrade.

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

Re: [PATCH 2/3] drm/panfrost: Expose HW counters to userspace

2019-04-04 Thread Boris Brezillon
On Thu, 4 Apr 2019 08:41:29 -0700
Alyssa Rosenzweig  wrote:


> > +/*
> > + * Returns true if the 2 jobs have exactly the same perfcnt context, false
> > + * otherwise.
> > + */
> > +static bool panfrost_perfcnt_job_ctx_cmp(struct panfrost_perfcnt_job_ctx 
> > *a,
> > +struct panfrost_perfcnt_job_ctx *b)
> > +{
> > +   unsigned int i, j;
> > +
> > +   if (a->perfmon_count != b->perfmon_count)
> > +   return false;
> > +
> > +   for (i = 0; i < a->perfmon_count; i++) {
> > +   for (j = 0; j < b->perfmon_count; j++) {
> > +   if (a->perfmons[i] == b->perfmons[j])
> > +   break;
> > +   }
> > +
> > +   if (j == b->perfmon_count)
> > +   return false;
> > +   }
> > +  
> 
> Would using memcmp() be cleaner here?

memcmp() does not account for the case where 2 jobs contain exactly the
same perfmons but in a different order. This being said, it's rather
unlikely to happen, so maybe we can accept the perf penalty for that
case.

> 
> > +   if (panfrost_model_cmp(pfdev, 0x1000) >= 0)  
> 
> What does 0x1000 refer to here? I'm assuming maybe Bifrost, but it's not
> obvious... probably better to have a #define somewhere and use that (or
> an enum equivalently).

Yes, all numbers above 0xfff are bifrost GPUs. I'll add a macro.

> 
> > +   /*
> > +* Due to PRLAM-8186 we need to disable the Tiler before we enable HW
> > +* counters.
> > +*/  
> 
> What on earth is PRLAM-8186? :)
> 
> Actually, wait, I can answer that -- old kbase versions had an errata
> list:
> 
> /* Write of PRFCNT_CONFIG_MODE_MANUAL to PRFCNT_CONFIG causes a 
> instrumentation dump if
>PRFCNT_TILER_EN is enabled */
> BASE_HW_ISSUE_8186,
> 
> So that's why. If people want, I'm considering moving these errata
> descriptions back into the kernel where possible, since otherwise code
> like this is opaque.

Will copy the errata.

> 
> > +   unsigned int nl2c, ncores;
> > +
> > +   /*
> > +* TODO: define a macro to extract the number of l2 caches from
> > +* mem_features.
> > +*/
> > +   nl2c = ((pfdev->features.mem_features >> 8) & GENMASK(3, 0)) + 
> > 1;
> > +
> > +   /*
> > +* The ARM driver is grouping cores per core group and then
> > +* only using the number of cores in group 0 to calculate the
> > +* size. Not sure why this is done like that, but I guess
> > +* shader_present will only show cores in the first group
> > +* anyway.
> > +*/
> > +   ncores = hweight64(pfdev->features.shader_present);
> > +  
> 
> Deja vu. Was this copypaste dmaybe?

Actually, that one is from me, hence the 'not sure why' part :).

> 
> > + (panfrost_model_cmp(pfdev, 0x1000) >= 0 ?  
> 
> THere's that pesky 0x1000 again.
> 
> > @@ -55,6 +63,15 @@ struct drm_panfrost_submit {
> >  
> > /** A combination of PANFROST_JD_REQ_* */
> > __u32 requirements;
> > +
> > +   /** Pointer to a u32 array of perfmons that should be attached to the 
> > job. */
> > +   __u64 perfmon_handles;
> > +
> > +   /** Number of perfmon handles passed in (size is that times 4). */
> > +   __u32 perfmon_handle_count;
> > +
> > +   /** Unused field, should be set to 0. */
> > +   __u32 padding;  
> 
> Bleep blorp. If we're modifying _submit, we'll need to be swift about
> merging this ahead of the main code to make sure we don't break the
> UABI. Although I guess if we're just adding fields at the end, that's a
> nonissue.

Others are using the same "if data passed is smaller than expected
size, unassigned fields are zeroed". That allows us to extend a struct
without breaking the ABI as long as zero is a valid value and does not
change the behavior compared to when the field was not present.

This is the case here: perfmon_handle_count = 0 means no perfmon
attached to the job, so the driver is acting like it previously was.

No need to get that part merged in the initial patch series IMO.

> 
> > +struct drm_panfrost_block_perfcounters {
> > +   /*
> > +* For DRM_IOCTL_PANFROST_GET_PERFCNT_LAYOUT, encodes the available
> > +* instances for a specific given block type.
> > +* For DRM_IOCTL_PANFROST_CREATE_PERFMON, encodes the instances the
> > +* user wants to monitor.
> > +* Note: the bitmap might be sparse.
> > +*/
> > +   __u64 instances;
> > +
> > +   /*
> > +* For DRM_IOCTL_PANFROST_GET_PERFCNT_LAYOUT, encodes the available
> > +* counters attached to a specific block type.
> > +* For DRM_IOCTL_PANFROST_CREATE_PERFMON, encodes the counters the user
> > +* wants to monitor.
> > +* Note: the bitmap might be sparse.
> > +*/
> > +   __u64 counters;
> > +};  
> 
> I don't understand this. Aren't there more than 64 counters?
> 
> > +struct drm_panfrost_get_perfcnt_layout {
> > +   struct drm_panfrost_block_perfcounters 

Re: [PATCH v2 6/6] drm/cirrus: rewrite and modernize driver.

2019-04-04 Thread Sam Ravnborg
Hi Gerd.

Very nice diffstat - good work indeed!

> I think it'll still be alot easier to review than a
> longish baby-step patch series.
Agreed.

Some random nits below.
With the relevant parts addressed you can add my:
Reviewed-by: Sam Ravnborg 

> new file mode 100644
> index ..5060e3d854d3
> --- /dev/null
> +++ b/drivers/gpu/drm/cirrus/cirrus.c
> @@ -0,0 +1,621 @@
> +/*
> + * Copyright 2012-2019 Red Hat
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License version 2. See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * Authors: Matthew Garrett
> + *   Dave Airlie
> + *   Gerd Hoffmann
> + *
> + * Portions of this code derived from cirrusfb.c:
> + * drivers/video/cirrusfb.c - driver for Cirrus Logic chipsets
> + *
> + * Copyright 1999-2001 Jeff Garzik 
> + */
Can we introduce an SPDX identifier?
(I am not good at the license stuff, so I cannot tell)

> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
Please sort again, you added a few new includes since last time

> +struct cirrus_device {
> + struct drm_device  dev;
> + struct drm_simple_display_pipe pipe;
> + struct drm_connector   conn;
> + unsigned int   cpp;
> + unsigned int   pitch;
> + void __iomem   *vram;
> + void __iomem   *mmio;
> +};
> +
> +/* -- */
> +/*
> + * The meat of this driver. The core passes us a mode and we have to program
> + * it. The modesetting here is the bare minimum required to satisfy the qemu
> + * emulation of this hardware, and running this against a real device is
> + * likely to result in an inadequately programmed mode. We've already had
> + * the opportunity to modify the mode, so whatever we receive here should
> + * be something that can be correctly programmed and displayed
> + */
> +
> +#define RREG8(reg) ioread8(((void __iomem *)cirrus->mmio) + (reg))
> +#define WREG8(reg, v) iowrite8(v, ((void __iomem *)cirrus->mmio) + (reg))
> +#define RREG32(reg) ioread32(((void __iomem *)cirrus->mmio) + (reg))
> +#define WREG32(reg, v) iowrite32(v, ((void __iomem *)cirrus->mmio) + (reg))

The cast of cirrus->mmio to (void __iomem *) should not be necessary as
this is the type is has in struct cirrus_device

There is not reason to use a define, use can use a static inline function

> +
> +#define SEQ_INDEX 4
> +#define SEQ_DATA 5
> +
> +#define WREG_SEQ(reg, v) \
> + do {\
> + WREG8(SEQ_INDEX, reg);  \
> + WREG8(SEQ_DATA, v); \
> + } while (0) \
This is only used once, drop the define?


> +#define CRT_INDEX 0x14
> +#define CRT_DATA 0x15
> +
> +#define WREG_CRT(reg, v) \
> + do {\
> + WREG8(CRT_INDEX, reg);  \
> + WREG8(CRT_DATA, v); \
> + } while (0) \
static inline?

> +#define GFX_INDEX 0xe
> +#define GFX_DATA 0xf
> +
> +#define WREG_GFX(reg, v) \
> + do {\
> + WREG8(GFX_INDEX, reg);  \
> + WREG8(GFX_DATA, v); \
> + } while (0) \
Used twice - drop?
> +
> +#define VGA_DAC_MASK 0x6
> +
> +#define WREG_HDR(v)  \
> + do {\
> + RREG8(VGA_DAC_MASK);\
> + RREG8(VGA_DAC_MASK);\
> + RREG8(VGA_DAC_MASK);\
> + RREG8(VGA_DAC_MASK);\
> + WREG8(VGA_DAC_MASK, v); \
> + } while (0) \
Used once, drop?

> +static int cirrus_convert_to(struct drm_framebuffer *fb)
> +{
> + if (fb->format->cpp[0] == 4 && fb->pitches[0] > CIRRUS_MAX_PITCH) {
> + if (fb->width * 3 <= CIRRUS_MAX_PITCH)
> + /* convert from XR24 to RG24 */
> + return 3;
> + else
> + /* convert from XR24 to RG16 */
> + return 2;
> + }
> + return 0;
> +}
> +
> +static int cirrus_cpp(struct 

Re: [PATCH 4/9] media: vsp1: Add support for missing 32-bit RGB formats

2019-04-04 Thread Jacopo Mondi
HI Laurent,
  if you help me out understanding the bit swapping procedure in VSP
I would be more confident in saying I actually reviewed the series.

On Thu, Mar 28, 2019 at 09:07:18AM +0200, Laurent Pinchart wrote:
> Add support for the V4L2_PIX_FMT_BGRA32, V4L2_PIX_FMT_BGRX32,
> V4L2_PIX_FMT_RGBA32 and V4L2_PIX_FMT_RGBX32 formats to the VSP driver.
>
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/media/platform/vsp1/vsp1_pipe.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
> b/drivers/media/platform/vsp1/vsp1_pipe.c
> index 54ff539ffea0..9f08d85e89d7 100644
> --- a/drivers/media/platform/vsp1/vsp1_pipe.c
> +++ b/drivers/media/platform/vsp1/vsp1_pipe.c
> @@ -68,6 +68,20 @@ static const struct vsp1_format_info vsp1_video_formats[] 
> = {
>   { V4L2_PIX_FMT_XBGR32, MEDIA_BUS_FMT_ARGB_1X32,
> VI6_FMT_ARGB_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> 1, { 32, 0, 0 }, false, false, 1, 1, false },
> + { V4L2_PIX_FMT_BGRA32, MEDIA_BUS_FMT_ARGB_1X32,
> +   VI6_FMT_RGBA_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +   1, { 32, 0, 0 }, false, false, 1, 1, true },
> + { V4L2_PIX_FMT_BGRX32, MEDIA_BUS_FMT_ARGB_1X32,
> +   VI6_FMT_RGBA_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +   1, { 32, 0, 0 }, false, false, 1, 1, false },
> + { V4L2_PIX_FMT_RGBA32, MEDIA_BUS_FMT_ARGB_1X32,
> +   VI6_FMT_RGBA_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> +   VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> +   1, { 32, 0, 0 }, false, false, 1, 1, true },
> + { V4L2_PIX_FMT_RGBX32, MEDIA_BUS_FMT_ARGB_1X32,
> +   VI6_FMT_RGBA_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> +   VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> +   1, { 32, 0, 0 }, false, false, 1, 1, false },


So, this is how I interpret the above lines for format BGRA32 (the
same applies to RGBA32 fwiw)

Bytes:  B3  B2  B1  B0
Input: ARGB_1X32:   A   R   G   B
Out:   BGRA32   R   G   B   A

If I apply LLS and LWS on the "Input Row", according to the table I get

 Position in Table 32.10:0  1  2  3
 IN Components ordering: A  R  G  B  (ARGB_1X32
 Position in Table 32.10:3  2  1  0  (with LLS and LWS applied)
 OUT Components ordering:B  G  R  A

Which to me is the ordering of components of the format named
V4L2_PIX_FMT_ARGB32 and not BGRA32 which is instead, as reported RGBA
(GREAT naming here!)

What am I doing wrong?

Thanks
  j


>   { V4L2_PIX_FMT_ARGB32, MEDIA_BUS_FMT_ARGB_1X32,
> VI6_FMT_ARGB_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> --
> Regards,
>
> Laurent Pinchart
>


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

[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #62 from Diego Viola  ---
We found quite a few things during our research:

export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier"

This helps alleviate the problem (xterm does not have the issue with this),
however, the problem is still present in Xephyr.

We tested Xephyr from the current git master down to Xephyr from xserver 1.16
and the problem is also present, however, setting the following environment
variable:

export R600_DEBUG=nodpbb

Makes the issue disappear entirely.

-- 
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 110138] Adaptive Sync, VRR, FreeSync out of range

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110138

gr...@sub.red changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from gr...@sub.red ---
> I think this patch should fix your issue

Indeed it does, thanks! :)

I've seen it is already in for 5.1. Don't you think it should be backported for
5.0 as well? I'm not sure if the issue could damage the display but for what I
can tell, it's a serious bug and surely looks disturbing to users.

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

Re: [PATCH v2 4/6] drm: add dstclip parameter to drm_fb_xrgb8888_to_rgb565()

2019-04-04 Thread Sam Ravnborg
On Thu, Apr 04, 2019 at 05:24:28PM +0200, Gerd Hoffmann wrote:
> When set apply clipping logic to destination too.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/drm/drm_fb_helper.h| 3 ++-
>  drivers/gpu/drm/drm_fb_helper.c| 8 +++-
>  drivers/gpu/drm/tinydrm/mipi-dbi.c | 2 +-
>  3 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 0350c7e9d6ba..1406057e1a93 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -646,6 +646,7 @@ void drm_fb_memcpy(void *dst, void *vaddr, struct 
> drm_framebuffer *fb,
>  struct drm_rect *clip, bool dstclip);
>  void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
>  struct drm_framebuffer *fb,
> -struct drm_rect *clip, bool swap);
> +struct drm_rect *clip,
> +bool swap, bool dstclip);
>  
>  #endif
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 087e49741094..2c9286702c3f 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -3388,13 +3388,15 @@ EXPORT_SYMBOL(drm_fb_memcpy);
>   * @fb: DRM framebuffer
>   * @clip: Clip rectangle area to copy
>   * @swap: Swap bytes
> + * @dstclip: Clip destination too.
>   *
>   * Drivers can use this function for RGB565 devices that don't natively
>   * support XRGB.
>   */
>  void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
>  struct drm_framebuffer *fb,
> -struct drm_rect *clip, bool swap)
> +struct drm_rect *clip,
> +bool swap, bool dstclip)
>  {
>   size_t len = (clip->x2 - clip->x1) * sizeof(u32);
>   unsigned int x, y;
> @@ -3405,6 +3407,8 @@ void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
>   if (!buf)
>   return;
>  
> + if (dstclip)
> + dst += clip->y1 * fb->width + clip->x1;
>   for (y = clip->y1; y < clip->y2; y++) {
>   src = vaddr + (y * fb->pitches[0]);
>   src += clip->x1;
> @@ -3420,6 +3424,8 @@ void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
>   else
>   *dst++ = val16;
>   }
> + if (dstclip)
> + dst += fb->width - (clip->x2 - clip->x1);
>   }

Same story as before with dstclip and boolean parameters to functions.
A small helper and you had two functions with and without clip.

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

Re: [PATCH v2 5/6] drm: add drm_fb_xrgb8888_to_rgb888() function to drm_fb_helper.c

2019-04-04 Thread Sam Ravnborg
Hi Gerd.

On Thu, Apr 04, 2019 at 05:24:29PM +0200, Gerd Hoffmann wrote:
> Like drm_fb_xrgb_to_rgb565() but converts to 24bpp (DRM_FORMAT_RGB888).
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/drm/drm_fb_helper.h |  4 +++
>  drivers/gpu/drm/drm_fb_helper.c | 49 +
>  2 files changed, 53 insertions(+)
> 
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 1406057e1a93..a6e56fcd948e 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -648,5 +648,9 @@ void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
>  struct drm_framebuffer *fb,
>  struct drm_rect *clip,
>  bool swap, bool dstclip);
> +void drm_fb_xrgb_to_rgb888(u8 *dst, void *vaddr,
> +struct drm_framebuffer *fb,
> +struct drm_rect *clip,
> +bool dstclip);
We have here three functions that take a *dst parameter:

void *dst
u8 *dst
u16 *dst

My OCD triggers when things like this is not consistent.
But that said I see why the three implementations takes three different types.

Something I noticed, so passed in onwards to you.
Feel free to ignore.

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

Re: [PATCH v2 3/6] drm: move tinydrm_xrgb8888_to_rgb565() to drm_fb_helper.c

2019-04-04 Thread Sam Ravnborg
Hi Gerd.

On Thu, Apr 04, 2019 at 05:24:27PM +0200, Gerd Hoffmann wrote:
> Also rename to drm_fb_xrgb_to_rgb565().
> Pure code motion, no functional change.
> 
> Signed-off-by: Gerd Hoffmann 
Reviewed-by: Sam Ravnborg 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/6] drm: add dstclip parameter to drm_fb_memcpy()

2019-04-04 Thread Sam Ravnborg
Hi Gerd.

Good to see these small incremental patches, and I recognize the parameter
from PATCH 1.

On Thu, Apr 04, 2019 at 05:24:26PM +0200, Gerd Hoffmann wrote:
> When set apply clipping logic to destination too.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/drm/drm_fb_helper.h| 2 +-
>  drivers/gpu/drm/drm_fb_helper.c| 6 --
>  drivers/gpu/drm/tinydrm/mipi-dbi.c | 2 +-
>  3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 696017b38add..a57420f40643 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -643,6 +643,6 @@ drm_fb_helper_remove_conflicting_pci_framebuffers(struct 
> pci_dev *pdev,
>  }
>  
>  void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
> -struct drm_rect *clip);
> +struct drm_rect *clip, bool dstclip);
>  
>  #endif
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 22d29834bbe9..fabeb408dce6 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -3363,7 +3363,7 @@ EXPORT_SYMBOL(drm_fb_helper_modinit);
>   * @dstclip: Clip destination too.
>   */
>  void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
> -struct drm_rect *clip)
> +struct drm_rect *clip, bool dstclip)

Not a huge fan of boolean parameters that decide what a simple
helper function should do.
Would have preferred two small helpers despite the small code duplication:

drm_fb_memcpy()
drm_fb_dstclip_memcpy()


>  {
>   unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
>   unsigned int pitch = fb->pitches[0];
> @@ -3371,10 +3371,12 @@ void drm_fb_memcpy(void *dst, void *vaddr, struct 
> drm_framebuffer *fb,
>   size_t len = (clip->x2 - clip->x1) * cpp;
>   unsigned int y;
>  
> + if (dstclip)
> + dst += (clip->y1 * pitch) + (clip->x1 * cpp);
Add newline?

>   for (y = clip->y1; y < clip->y2; y++) {
>   memcpy(dst, src, len);
>   src += pitch;
> - dst += len;
> + dst += dstclip ? pitch : len;
>   }
>  }
>  EXPORT_SYMBOL(drm_fb_memcpy);
> diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
> b/drivers/gpu/drm/tinydrm/mipi-dbi.c
> index fb7e4582e293..e26fd61360a3 100644
> --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
> +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
> @@ -221,7 +221,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer 
> *fb,
>   if (swap)
>   tinydrm_swab16(dst, src, fb, clip);
>   else
> - drm_fb_memcpy(dst, src, fb, clip);
> + drm_fb_memcpy(dst, src, fb, clip, false);
>   break;
>   case DRM_FORMAT_XRGB:
>   tinydrm_xrgb_to_rgb565(dst, src, fb, clip, swap);
> -- 
> 2.18.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] drm/panel: Rocktech jh057n00900: Add terminating newlines to logging

2019-04-04 Thread Thierry Reding
On Thu, Apr 04, 2019 at 05:48:50PM +0200, Guido Günther wrote:
> Hi Joe,
> On Thu, Apr 04, 2019 at 08:06:09AM -0700, Joe Perches wrote:
> > These were missing '\n' terminations, add them.
> > 
> > Signed-off-by: Joe Perches 
> > ---
> >  drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 19 ++-
> >  1 file changed, 10 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c 
> > b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> > index 158a6d548068..d88ea8da2ec2 100644
> > --- a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> > +++ b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> > @@ -123,7 +123,7 @@ static int jh057n_init_sequence(struct jh057n *ctx)
> >  
> > ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> > if (ret < 0) {
> > -   DRM_DEV_ERROR(dev, "Failed to exit sleep mode");
> > +   DRM_DEV_ERROR(dev, "Failed to exit sleep mode\n");
> > return ret;
> > }
> > /* Panel is operational 120 msec after reset */
> > @@ -132,7 +132,7 @@ static int jh057n_init_sequence(struct jh057n *ctx)
> > if (ret)
> > return ret;
> >  
> > -   DRM_DEV_DEBUG_DRIVER(dev, "Panel init sequence done");
> > +   DRM_DEV_DEBUG_DRIVER(dev, "Panel init sequence done\n");
> > return 0;
> >  }
> >  
> > @@ -172,7 +172,7 @@ static int jh057n_prepare(struct drm_panel *panel)
> > if (ctx->prepared)
> > return 0;
> >  
> > -   DRM_DEV_DEBUG_DRIVER(ctx->dev, "Resetting the panel.");
> > +   DRM_DEV_DEBUG_DRIVER(ctx->dev, "Resetting the panel\n");
> > gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> > usleep_range(20, 40);
> > gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> > @@ -180,7 +180,8 @@ static int jh057n_prepare(struct drm_panel *panel)
> >  
> > ret = jh057n_init_sequence(ctx);
> > if (ret < 0) {
> > -   DRM_DEV_ERROR(ctx->dev, "Panel init sequence failed: %d", ret);
> > +   DRM_DEV_ERROR(ctx->dev, "Panel init sequence failed: %d\n",
> > + ret);
> > return ret;
> > }
> >  
> > @@ -212,7 +213,7 @@ static int jh057n_get_modes(struct drm_panel *panel)
> >  
> > mode = drm_mode_duplicate(panel->drm, _mode);
> > if (!mode) {
> > -   DRM_DEV_ERROR(ctx->dev, "Failed to add mode %ux%u@%u",
> > +   DRM_DEV_ERROR(ctx->dev, "Failed to add mode %ux%u@%u\n",
> >   default_mode.hdisplay, default_mode.vdisplay,
> >   default_mode.vrefresh);
> > return -ENOMEM;
> > @@ -241,7 +242,7 @@ static int allpixelson_set(void *data, u64 val)
> > struct jh057n *ctx = data;
> > struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> >  
> > -   DRM_DEV_DEBUG_DRIVER(ctx->dev, "Setting all pixels on");
> > +   DRM_DEV_DEBUG_DRIVER(ctx->dev, "Setting all pixels on\n");
> > dsi_generic_write_seq(dsi, ST7703_CMD_ALL_PIXEL_ON);
> > msleep(val * 1000);
> > /* Reset the panel to get video back */
> > @@ -290,7 +291,7 @@ static int jh057n_probe(struct mipi_dsi_device *dsi)
> >  
> > ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> > if (IS_ERR(ctx->reset_gpio)) {
> > -   DRM_DEV_ERROR(dev, "cannot get reset gpio");
> > +   DRM_DEV_ERROR(dev, "cannot get reset gpio\n");
> > return PTR_ERR(ctx->reset_gpio);
> > }
> >  
> > @@ -315,12 +316,12 @@ static int jh057n_probe(struct mipi_dsi_device *dsi)
> >  
> > ret = mipi_dsi_attach(dsi);
> > if (ret < 0) {
> > -   DRM_DEV_ERROR(dev, "mipi_dsi_attach failed. Is host ready?");
> > +   DRM_DEV_ERROR(dev, "mipi_dsi_attach failed. Is host ready?\n");
> > drm_panel_remove(>panel);
> > return ret;
> > }
> >  
> > -   DRM_DEV_INFO(dev, "%ux%u@%u %ubpp dsi %udl - ready",
> > +   DRM_DEV_INFO(dev, "%ux%u@%u %ubpp dsi %udl - ready\n",
> >  default_mode.hdisplay, default_mode.vdisplay,
> >  default_mode.vrefresh,
> >  mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);
> > 
> 
> Reviewed-By: Guido Günther 

Nit: the correct tag is "Reviewed-by:", note the lowercase "by". I only
noticed because checkpatch complained, and fixed it up.

Thierry


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

Re: [PATCH] drm/panel: Rocktech jh057n00900: Add terminating newlines to logging

2019-04-04 Thread Thierry Reding
On Thu, Apr 04, 2019 at 08:06:09AM -0700, Joe Perches wrote:
> These were missing '\n' terminations, add them.
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)

Applied, thanks.

Thierry


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

Re: [PATCH v2 1/6] drm: move tinydrm_memcpy() to drm_fb_helper.c

2019-04-04 Thread Sam Ravnborg
Hi Gerd.

On Thu, Apr 04, 2019 at 05:24:25PM +0200, Gerd Hoffmann wrote:
> Also rename to drm_fb_memcpy().
> Pure code motion, no functional change.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/drm/drm_fb_helper.h   |  3 +++
>  include/drm/tinydrm/tinydrm-helpers.h |  2 --
>  drivers/gpu/drm/drm_fb_helper.c   | 25 +++
>  .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 24 --
>  drivers/gpu/drm/tinydrm/mipi-dbi.c|  3 ++-
>  5 files changed, 30 insertions(+), 27 deletions(-)
> 
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 81ae48a0df48..696017b38add 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -642,4 +642,7 @@ drm_fb_helper_remove_conflicting_pci_framebuffers(struct 
> pci_dev *pdev,
>  #endif
>  }
>  
> +void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
> +struct drm_rect *clip);
> +
>  #endif
> diff --git a/include/drm/tinydrm/tinydrm-helpers.h 
> b/include/drm/tinydrm/tinydrm-helpers.h
> index ae4a6abc43b5..591ca83330c4 100644
> --- a/include/drm/tinydrm/tinydrm-helpers.h
> +++ b/include/drm/tinydrm/tinydrm-helpers.h
> @@ -46,8 +46,6 @@ int tinydrm_display_pipe_init(struct drm_device *drm,
> const struct drm_display_mode *mode,
> unsigned int rotation);
>  
> -void tinydrm_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
> - struct drm_rect *clip);
>  void tinydrm_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
>   struct drm_rect *clip);
>  void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 03749a24e4dd..22d29834bbe9 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -3353,3 +3353,28 @@ int __init drm_fb_helper_modinit(void)
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_fb_helper_modinit);
> +
> +/**
> + * drm_fb_memcpy - Copy clip buffer
> + * @dst: Destination buffer
> + * @vaddr: Source buffer
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + * @dstclip: Clip destination too.
> + */
> +void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
> +struct drm_rect *clip)
Function has no parameter named @dstclip.

With this fixed:
Reviewed-by: Sam Ravnborg 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panel: Rocktech jh057n00900: Add terminating newlines to logging

2019-04-04 Thread Sam Ravnborg
Hi Joe.

On Thu, Apr 04, 2019 at 08:06:09AM -0700, Joe Perches wrote:
> These were missing '\n' terminations, add them.
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c 
> b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> index 158a6d548068..d88ea8da2ec2 100644
> --- a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> +++ b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> @@ -123,7 +123,7 @@ static int jh057n_init_sequence(struct jh057n *ctx)
>  
>   ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
>   if (ret < 0) {
> - DRM_DEV_ERROR(dev, "Failed to exit sleep mode");
> + DRM_DEV_ERROR(dev, "Failed to exit sleep mode\n");

I was under the impression that newlines was optional these days.
Should we always use them with logging?

I did not find any obvious clues in linux/printk.h

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

[Bug 108879] [CIK] [regression] All opencl apps hangs indefinitely in si_create_context

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108879

Steffen Klee  changed:

   What|Removed |Added

 CC||steffen.k...@gmail.com

--- Comment #9 from Steffen Klee  ---
AMD R9 390 (Linux 4.14, LLVM 8.0.0, AMDGPU kernel driver, Mesa 19.0.1)

Also experiencing hangs when running clinfo and other OpenCL software.
Applying mentioned patches results in segfaults when starting graphical
applications as well as OpenCL software.

However, when just applying the workaround in duplicate bug 108572, comment 6,
clinfo and other OpenCL software start working again.

-- 
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 110327] [exynos-drm] failed to presentate a dumb buffer format NV12 with modifier DRM_FORMAT_MOD_SAMSUNG_64_32_TILE

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110327

Bug ID: 110327
   Summary: [exynos-drm] failed to presentate a dumb buffer format
NV12 with modifier DRM_FORMAT_MOD_SAMSUNG_64_32_TILE
   Product: DRI
   Version: unspecified
  Hardware: ARM
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: zille...@gmx.de

Created attachment 143863
  --> https://bugs.freedesktop.org/attachment.cgi?id=143863=edit
picture from screen

I want to decode a H264 1280x720 video with v4l2 decoder and present this on
DRM with a dumb buffer.

On screen the Y plane is correct but UV plane have the doubled height. Pitch is
correct. But looks like a line from uv plane is used for 4 lines on y plane
instead of 2. Attached are a picture from the screen. I use the format
describtion from:
https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-nv12mt.html. 

For dumb buffer configuration the height must aligned to 64 instead of to 32.
If align height to 32 EINVAL is returned from AddFB2. OK, the UV plane have the
half height from Y plane and must aligned to 32.

The size from DRM_IOCTL_CREATE_DUMB_BUFFER is to big. IOCTL returned a dumb
buffer size from 1966080.
width = 1280 => aligned to 128 width = 1280
height = 720 => aligned to 64 height = 768
Y plane 1280 * 768 = 983040
UV plane 1280 * 768 / 2 = 491520
Dumb buffer size should be 1474560. Looks like the UV plane have doubled size
as it should be.

The device is a Odroid-U3 with Exynos4412.
Kernel version is 5.0.5.

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

Re: [RFC PATCH 01/20] drm: Remove users of drm_format_num_planes

2019-04-04 Thread Emil Velikov
On Tue, 2 Apr 2019 at 15:51, Maxime Ripard  wrote:
>
> Hi Emil,
>
> On Tue, Apr 02, 2019 at 10:43:31AM +0100, Emil Velikov wrote:
> > On Tue, 19 Mar 2019 at 21:57, Maxime Ripard  
> > wrote:
> > > drm_format_num_planes() is basically a lookup in the drm_format_info table
> > > plus an access to the num_planes field of the appropriate entry.
> > >
> > > Most drivers are using this function while having access to the entry
> > > already, which means that we will perform an unnecessary lookup. Removing
> > > the call to drm_format_num_planes is therefore more efficient.
> > >
> > > Some drivers will not have access to that entry in the function, but in
> > > this case the overhead is minimal (we just have to call drm_format_info()
> > > to perform the lookup) and we can even avoid multiple, inefficient lookups
> > > in some places that need multiple fields from the drm_format_info
> > > structure.
> > >
> >
> > I'm not fan of the duplicated loop-ups either.
> >
> > > -int drm_format_num_planes(uint32_t format)
> > > -{
> > > -   const struct drm_format_info *info;
> > > -
> > > -   info = drm_format_info(format);
> > > -   return info ? info->num_planes : 1;
> > > -}
> > > -EXPORT_SYMBOL(drm_format_num_planes);
> > > -
> >
> > The existing users are not updated to cater for the num_planes != 0
> > case... Which seems non-existent scenario since all the current format
> > descriptions have 1+ planes.
> > Should we add a test (alike the ones in 6/20) to ensure, that no entry
> > has 0 planes? Is it even worth it or I'm a bit too paranoid?
> >
> > The above comments apply to 2/20.
>
> I'm not entirely sure what you mean. num_planes is returned as is in
> the drm_format_num_planes function and it doesn't check for the
> num_planes value itself.
>
> That being said, we could definitely add some more tests to check that
> we haven't falling into the situation you describe, since most of the
> drivers indeed don't check for that value themselves. But that seems
> pretty othorgonal to me?
>
Hmm I misread the old function as "return info->num_planes ?
info->num_planes : 1;"

Pardon for the noise.
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panel: Rocktech jh057n00900: Add terminating newlines to logging

2019-04-04 Thread Joe Perches
On Thu, 2019-04-04 at 17:48 +0200, Guido Günther wrote:
> Hi Joe,
[]
> P.S.: The cc: list is huge, is there a reason for going way past what
> get_maintainers puts out for this patch?

No idea, I just used reply-all to your patch.


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

[PULL] drm-intel-fixes

2019-04-04 Thread Rodrigo Vivi
Hi Dave and Daniel,

Here goes drm-intel-fixes-2019-04-04:

Only one fix for DSC (backoff after drm_modeset_lock deadlock)
and GVT's fixes including vGPU display plane size calculation,
shadow mm pin count, error recovery path for workload create
and one kerneldoc fix.

Thanks,
Rodrigo.

The following changes since commit 79a3aaa7b82e3106be97842dedfd8429248896e6:

  Linux 5.1-rc3 (2019-03-31 14:39:29 -0700)

are available in the Git repository at:

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

for you to fetch changes up to 57cbec02f9b10992319ca578797c8059ac47d71e:

  Merge tag 'gvt-fixes-2019-04-04' of https://github.com/intel/gvt-linux into 
drm-intel-fixes (2019-04-03 18:00:42 -0700)


Only one fix for DSC (backoff after drm_modeset_lock deadlock)
and GVT's fixes including vGPU display plane size calculation,
shadow mm pin count, error recovery path for workload create
and one kerneldoc fix.


Chris Wilson (2):
  drm/i915: Always backoff after a drm_modeset_lock() deadlock
  drm/i915/gvt: Fix kerneldoc typo for intel_vgpu_emulate_hotplug

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2019-04-04' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Xiong Zhang (1):
  drm/i915/gvt: Correct the calculation of plane size

Yan Zhao (2):
  drm/i915/gvt: do not deliver a workload if its creation fails
  drm/i915/gvt: do not let pin count of shadow mm go negative

 drivers/gpu/drm/i915/gvt/display.c   | 2 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c| 8 ++--
 drivers/gpu/drm/i915/gvt/gtt.c   | 2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c | 5 +++--
 drivers/gpu/drm/i915/i915_debugfs.c  | 5 -
 5 files changed, 11 insertions(+), 11 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/9] v4l: Add definitions for missing 32-bit RGB formats

2019-04-04 Thread Jacopo Mondi
Hi Laurent,
   thanks for explaining.

On Tue, Apr 02, 2019 at 03:12:00PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Thu, Mar 28, 2019 at 02:15:43PM +0100, Jacopo Mondi wrote:
> > On Thu, Mar 28, 2019 at 09:07:15AM +0200, Laurent Pinchart wrote:
> > > The V4L2 API is missing the 32-bit RGB formats for the ABGR, XBGR, RGBA
> > > and RGBX component orders. Add them, using the same 4CCs as DRM.
> > >
> > > Signed-off-by: Laurent Pinchart 
> > > 
> > > ---
> > >  .../media/uapi/v4l/pixfmt-packed-rgb.rst  | 160 ++
> > >  include/uapi/linux/videodev2.h|   4 +
> > >  2 files changed, 164 insertions(+)
> > >
> > > diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst 
> > > b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> > > index 6b3781c04dd5..055f9c89e787 100644
> > > --- a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> > > +++ b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> > > @@ -453,6 +453,166 @@ next to each other in memory.
> > >- r\ :sub:`1`
> > >- r\ :sub:`0`
> > >
> > > +  -
> > > +  -
> > > +  -
> > > +  -
> > > +  -
> > > +  -
> > > +  -
> > > +  -
> > > +* .. _V4L2-PIX-FMT-BGRA32:
> > > +
> > > +  - ``V4L2_PIX_FMT_BGRA32``
> > > +  - 'RA24'
> > > +
> > > +  - a\ :sub:`7`
> > > +  - a\ :sub:`6`
> > > +  - a\ :sub:`5`
> > > +  - a\ :sub:`4`
> > > +  - a\ :sub:`3`
> > > +  - a\ :sub:`2`
> > > +  - a\ :sub:`1`
> > > +  - a\ :sub:`0`
> > > +
> > > +  - b\ :sub:`7`
> > > +  - b\ :sub:`6`
> > > +  - b\ :sub:`5`
> > > +  - b\ :sub:`4`
> > > +  - b\ :sub:`3`
> > > +  - b\ :sub:`2`
> > > +  - b\ :sub:`1`
> > > +  - b\ :sub:`0`
> > > +
> > > +  - g\ :sub:`7`
> > > +  - g\ :sub:`6`
> > > +  - g\ :sub:`5`
> > > +  - g\ :sub:`4`
> > > +  - g\ :sub:`3`
> > > +  - g\ :sub:`2`
> > > +  - g\ :sub:`1`
> > > +  - g\ :sub:`0`
> > > +
> > > +  - r\ :sub:`7`
> > > +  - r\ :sub:`6`
> > > +  - r\ :sub:`5`
> > > +  - r\ :sub:`4`
> > > +  - r\ :sub:`3`
> > > +  - r\ :sub:`2`
> > > +  - r\ :sub:`1`
> > > +  - r\ :sub:`0`
> > > +* .. _V4L2-PIX-FMT-BGRX32:
> > > +
> > > +  - ``V4L2_PIX_FMT_BGRX32``
> > > +  - 'RX24'
> > > +
> > > +  -
> > > +  -
> > > +  -
> > > +  -
> > > +  -
> > > +  -
> > > +  -
> > > +  -
> > > +
> > > +  - b\ :sub:`7`
> > > +  - b\ :sub:`6`
> > > +  - b\ :sub:`5`
> > > +  - b\ :sub:`4`
> > > +  - b\ :sub:`3`
> > > +  - b\ :sub:`2`
> > > +  - b\ :sub:`1`
> > > +  - b\ :sub:`0`
> > > +
> > > +  - g\ :sub:`7`
> > > +  - g\ :sub:`6`
> > > +  - g\ :sub:`5`
> > > +  - g\ :sub:`4`
> > > +  - g\ :sub:`3`
> > > +  - g\ :sub:`2`
> > > +  - g\ :sub:`1`
> > > +  - g\ :sub:`0`
> > > +
> > > +  - r\ :sub:`7`
> > > +  - r\ :sub:`6`
> > > +  - r\ :sub:`5`
> > > +  - r\ :sub:`4`
> > > +  - r\ :sub:`3`
> > > +  - r\ :sub:`2`
> > > +  - r\ :sub:`1`
> > > +  - r\ :sub:`0`
> > > +* .. _V4L2-PIX-FMT-RGBA32:
> > > +
> > > +  - ``V4L2_PIX_FMT_RGBA32``
> > > +  - 'AB24'
> > > +
> > > +  - r\ :sub:`7`
> > > +  - r\ :sub:`6`
> > > +  - r\ :sub:`5`
> > > +  - r\ :sub:`4`
> > > +  - r\ :sub:`3`
> > > +  - r\ :sub:`2`
> > > +  - r\ :sub:`1`
> > > +  - r\ :sub:`0`
> > > +
> > > +  - g\ :sub:`7`
> > > +  - g\ :sub:`6`
> > > +  - g\ :sub:`5`
> > > +  - g\ :sub:`4`
> > > +  - g\ :sub:`3`
> > > +  - g\ :sub:`2`
> > > +  - g\ :sub:`1`
> > > +  - g\ :sub:`0`
> > > +
> > > +  - b\ :sub:`7`
> > > +  - b\ :sub:`6`
> > > +  - b\ :sub:`5`
> > > +  - b\ :sub:`4`
> > > +  - b\ :sub:`3`
> > > +  - b\ :sub:`2`
> > > +  - b\ :sub:`1`
> > > +  - b\ :sub:`0`
> > > +
> > > +  - a\ :sub:`7`
> > > +  - a\ :sub:`6`
> > > +  - a\ :sub:`5`
> > > +  - a\ :sub:`4`
> > > +  - a\ :sub:`3`
> > > +  - a\ :sub:`2`
> > > +  - a\ :sub:`1`
> > > +  - a\ :sub:`0`
> > > +* .. _V4L2-PIX-FMT-RGBX32:
> > > +
> > > +  - ``V4L2_PIX_FMT_RGBX32``
> > > +  - 'XB24'
> > > +
> > > +  - r\ :sub:`7`
> > > +  - r\ :sub:`6`
> > > +  - r\ :sub:`5`
> > > +  - r\ :sub:`4`
> > > +  - r\ :sub:`3`
> > > +  - r\ :sub:`2`
> > > +  - r\ :sub:`1`
> > > +  - r\ :sub:`0`
> > > +
> > > +  - g\ :sub:`7`
> > > +  - g\ :sub:`6`
> > > +  - g\ :sub:`5`
> > > +  - g\ :sub:`4`
> > > +  - g\ :sub:`3`
> > > +  - g\ :sub:`2`
> > > +  - g\ :sub:`1`
> > > +  - g\ :sub:`0`
> > > +
> > > +  - b\ :sub:`7`
> > > +  - b\ :sub:`6`
> > > +  - b\ :sub:`5`
> > > +  - b\ :sub:`4`
> > > +  - b\ :sub:`3`
> > > +  - b\ :sub:`2`
> > > +  - b\ :sub:`1`
> > > +  - b\ :sub:`0`
> > > +
> >
> > I'm trying to compare these with the existing 32-bit RGB formats in
> > pixfmt-packed-rgb.rst and 

Re: [PATCH 2/9] v4l: Add definitions for missing 16-bit RGB4444 formats

2019-04-04 Thread Jacopo Mondi
Hi Laurent,

On Thu, Mar 28, 2019 at 09:07:16AM +0200, Laurent Pinchart wrote:
> The V4L2 API is missing the 16-bit RGB formats for the RGBA, RGBX,
> ABGR, XBGR, BGRA and BGRX component orders. Add them, using the same
> 4CCs as DRM.
>
> Signed-off-by: Laurent Pinchart 

I checked the documentation and it seems right, I cannot relate the
name to the ordering but I guess this is intended.

Reviewed-by: Jacopo Mondi 

Thanks
   j
> ---
>  .../media/uapi/v4l/pixfmt-packed-rgb.rst  | 138 ++
>  include/uapi/linux/videodev2.h|   6 +
>  2 files changed, 144 insertions(+)
>
> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst 
> b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> index 055f9c89e787..b475cbba492f 100644
> --- a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> @@ -139,6 +139,144 @@ next to each other in memory.
>- r\ :sub:`1`
>- r\ :sub:`0`
>-
> +* .. _V4L2-PIX-FMT-RGBA444:
> +
> +  - ``V4L2_PIX_FMT_RGBA444``
> +  - 'RA12'
> +
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - a\ :sub:`3`
> +  - a\ :sub:`2`
> +  - a\ :sub:`1`
> +  - a\ :sub:`0`
> +
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  -
> +* .. _V4L2-PIX-FMT-RGBX444:
> +
> +  - ``V4L2_PIX_FMT_RGBX444``
> +  - 'RX12'
> +
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  -
> +  -
> +  -
> +  -
> +
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  -
> +* .. _V4L2-PIX-FMT-ABGR444:
> +
> +  - ``V4L2_PIX_FMT_ABGR444``
> +  - 'AB12'
> +
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +
> +  - a\ :sub:`3`
> +  - a\ :sub:`2`
> +  - a\ :sub:`1`
> +  - a\ :sub:`0`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  -
> +* .. _V4L2-PIX-FMT-XBGR444:
> +
> +  - ``V4L2_PIX_FMT_XBGR444``
> +  - 'XB12'
> +
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +
> +  -
> +  -
> +  -
> +  -
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  -
> +* .. _V4L2-PIX-FMT-BGRA444:
> +
> +  - ``V4L2_PIX_FMT_BGRA444``
> +  - 'BA12'
> +
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - a\ :sub:`3`
> +  - a\ :sub:`2`
> +  - a\ :sub:`1`
> +  - a\ :sub:`0`
> +
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  -
> +* .. _V4L2-PIX-FMT-BGRX444:
> +
> +  - ``V4L2_PIX_FMT_BGRX444``
> +  - 'BX12'
> +
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  -
> +  -
> +  -
> +  -
> +
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  -
>  * .. _V4L2-PIX-FMT-ARGB555:
>
>- ``V4L2_PIX_FMT_ARGB555``
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 4e5222726719..df9fa78a6ab7 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -514,6 +514,12 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_RGB444  v4l2_fourcc('R', '4', '4', '4') /* 16   
>  */
>  #define V4L2_PIX_FMT_ARGB444 v4l2_fourcc('A', 'R', '1', '2') /* 16   
>  */
>  #define V4L2_PIX_FMT_XRGB444 v4l2_fourcc('X', 'R', '1', '2') /* 16   
>  */
> +#define V4L2_PIX_FMT_RGBA444 v4l2_fourcc('R', 'A', '1', '2') /* 16   
>  */
> +#define V4L2_PIX_FMT_RGBX444 v4l2_fourcc('R', 'X', '1', '2') /* 16   
>  */
> +#define V4L2_PIX_FMT_ABGR444 v4l2_fourcc('A', 'B', '1', '2') /* 16   
>  */
> +#define V4L2_PIX_FMT_XBGR444 v4l2_fourcc('X', 'B', '1', '2') /* 16   
>  */
> +#define V4L2_PIX_FMT_BGRA444 v4l2_fourcc('B', 'A', '1', '2') /* 16   
>  */
> +#define V4L2_PIX_FMT_BGRX444 v4l2_fourcc('B', 'X', '1', '2') /* 16   
>  */
>  #define V4L2_PIX_FMT_RGB555  v4l2_fourcc('R', 'G', 'B', 'O') /* 16  
> 

Re: [PATCH 3/9] v4l: Add definitions for missing 16-bit RGB555 formats

2019-04-04 Thread Jacopo Mondi
Hi Laurent

On Thu, Mar 28, 2019 at 09:07:17AM +0200, Laurent Pinchart wrote:
> The V4L2 API is missing the 16-bit RGB555 formats for the RGBA, RGBX,
> ABGR, XBGR, BGRA and BGRX component orders. Add them, using the same
> 4CCs as DRM.
>
> Signed-off-by: Laurent Pinchart 
> ---
>  .../media/uapi/v4l/pixfmt-packed-rgb.rst  | 138 ++
>  include/uapi/linux/videodev2.h|   6 +
>  2 files changed, 144 insertions(+)
>
> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst 
> b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> index b475cbba492f..9a9c1993b0fd 100644
> --- a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> @@ -323,6 +323,144 @@ next to each other in memory.
>- g\ :sub:`4`
>- g\ :sub:`3`
>-
> +* .. _V4L2-PIX-FMT-RGBA555:
> +
> +  - ``V4L2_PIX_FMT_RGBA555``
> +  - 'RA15'
> +
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - a
> +
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - g\ :sub:`4`
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  -
> +* .. _V4L2-PIX-FMT-RGBX555:
> +
> +  - ``V4L2_PIX_FMT_RGBX555``
> +  - 'RX15'
> +
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  -
> +
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - g\ :sub:`4`
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  -
> +* .. _V4L2-PIX-FMT-ABGR555:
> +
> +  - ``V4L2_PIX_FMT_ABGR555``
> +  - 'AB15'
> +
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +
> +  - a
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - g\ :sub:`4`
> +  - g\ :sub:`3`
> +  -
> +* .. _V4L2-PIX-FMT-XBGR555:
> +
> +  - ``V4L2_PIX_FMT_XBGR555``
> +  - 'XB15'
> +
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +
> +  -
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - g\ :sub:`4`
> +  - g\ :sub:`3`
> +  -
> +* .. _V4L2-PIX-FMT-BGRA555:
> +
> +  - ``V4L2_PIX_FMT_BGRA555``
> +  - 'BA15'
> +
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - a
> +
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - g\ :sub:`4`
> +  - g\ :sub:`3`
> +  -
> +* .. _V4L2-PIX-FMT-BGRX555:
> +
> +  - ``V4L2_PIX_FMT_BGRX555``
> +  - 'BX15'
> +
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  -
> +
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - g\ :sub:`4`
> +  - g\ :sub:`3`
> +  -

I see the last 4 formats are identical in their components
disposition. Is this intended?

   B1  B0
  b7   b0   b7  b0
ABGR555 | g2 g1 g0 b4 b3 b2 b1 b0 | a r4 r3 r2 r1 r0 g4 g3 |
XBGR555 | g2 g1 g0 b4 b3 b2 b1 b0 | x r4 r3 r2 r1 r0 g4 g3 |
BGRA555 | g2 g1 g0 b4 b3 b2 b1 b0 | a r4 r3 r2 r1 r0 g4 g3 |
BGRX555 | g2 g1 g0 b4 b3 b2 b1 b0 | x r4 r3 r2 r1 r0 g4 g3 |

If there is any correlation with the naming scheme (but I think
there's not, at least not a strict one) 'a' and 'x' of BGR* formats
should be in the most significant bit of Byte 1.

Thanks
  j

>  * .. _V4L2-PIX-FMT-RGB565:
>
>- ``V4L2_PIX_FMT_RGB565``
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index df9fa78a6ab7..fb6f01a7c91c 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -523,6 +523,12 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_RGB555  v4l2_fourcc('R', 'G', 'B', 'O') /* 16  
> RGB-5-5-5 */
>  #define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16  
> ARGB-1-5-5-5  */
>  #define V4L2_PIX_FMT_XRGB555 v4l2_fourcc('X', 'R', '1', '5') /* 16  
> XRGB-1-5-5-5  */
> +#define V4L2_PIX_FMT_RGBA555 v4l2_fourcc('R', 'A', '1', '5') /* 16  
> RGBA-5-5-5-1  */
> +#define 

Re: [PATCH] drm/panel: Rocktech jh057n00900: Add terminating newlines to logging

2019-04-04 Thread Guido Günther
Hi Joe,
On Thu, Apr 04, 2019 at 08:06:09AM -0700, Joe Perches wrote:
> These were missing '\n' terminations, add them.
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c 
> b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> index 158a6d548068..d88ea8da2ec2 100644
> --- a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> +++ b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> @@ -123,7 +123,7 @@ static int jh057n_init_sequence(struct jh057n *ctx)
>  
>   ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
>   if (ret < 0) {
> - DRM_DEV_ERROR(dev, "Failed to exit sleep mode");
> + DRM_DEV_ERROR(dev, "Failed to exit sleep mode\n");
>   return ret;
>   }
>   /* Panel is operational 120 msec after reset */
> @@ -132,7 +132,7 @@ static int jh057n_init_sequence(struct jh057n *ctx)
>   if (ret)
>   return ret;
>  
> - DRM_DEV_DEBUG_DRIVER(dev, "Panel init sequence done");
> + DRM_DEV_DEBUG_DRIVER(dev, "Panel init sequence done\n");
>   return 0;
>  }
>  
> @@ -172,7 +172,7 @@ static int jh057n_prepare(struct drm_panel *panel)
>   if (ctx->prepared)
>   return 0;
>  
> - DRM_DEV_DEBUG_DRIVER(ctx->dev, "Resetting the panel.");
> + DRM_DEV_DEBUG_DRIVER(ctx->dev, "Resetting the panel\n");
>   gpiod_set_value_cansleep(ctx->reset_gpio, 1);
>   usleep_range(20, 40);
>   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> @@ -180,7 +180,8 @@ static int jh057n_prepare(struct drm_panel *panel)
>  
>   ret = jh057n_init_sequence(ctx);
>   if (ret < 0) {
> - DRM_DEV_ERROR(ctx->dev, "Panel init sequence failed: %d", ret);
> + DRM_DEV_ERROR(ctx->dev, "Panel init sequence failed: %d\n",
> +   ret);
>   return ret;
>   }
>  
> @@ -212,7 +213,7 @@ static int jh057n_get_modes(struct drm_panel *panel)
>  
>   mode = drm_mode_duplicate(panel->drm, _mode);
>   if (!mode) {
> - DRM_DEV_ERROR(ctx->dev, "Failed to add mode %ux%u@%u",
> + DRM_DEV_ERROR(ctx->dev, "Failed to add mode %ux%u@%u\n",
> default_mode.hdisplay, default_mode.vdisplay,
> default_mode.vrefresh);
>   return -ENOMEM;
> @@ -241,7 +242,7 @@ static int allpixelson_set(void *data, u64 val)
>   struct jh057n *ctx = data;
>   struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
>  
> - DRM_DEV_DEBUG_DRIVER(ctx->dev, "Setting all pixels on");
> + DRM_DEV_DEBUG_DRIVER(ctx->dev, "Setting all pixels on\n");
>   dsi_generic_write_seq(dsi, ST7703_CMD_ALL_PIXEL_ON);
>   msleep(val * 1000);
>   /* Reset the panel to get video back */
> @@ -290,7 +291,7 @@ static int jh057n_probe(struct mipi_dsi_device *dsi)
>  
>   ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
>   if (IS_ERR(ctx->reset_gpio)) {
> - DRM_DEV_ERROR(dev, "cannot get reset gpio");
> + DRM_DEV_ERROR(dev, "cannot get reset gpio\n");
>   return PTR_ERR(ctx->reset_gpio);
>   }
>  
> @@ -315,12 +316,12 @@ static int jh057n_probe(struct mipi_dsi_device *dsi)
>  
>   ret = mipi_dsi_attach(dsi);
>   if (ret < 0) {
> - DRM_DEV_ERROR(dev, "mipi_dsi_attach failed. Is host ready?");
> + DRM_DEV_ERROR(dev, "mipi_dsi_attach failed. Is host ready?\n");
>   drm_panel_remove(>panel);
>   return ret;
>   }
>  
> - DRM_DEV_INFO(dev, "%ux%u@%u %ubpp dsi %udl - ready",
> + DRM_DEV_INFO(dev, "%ux%u@%u %ubpp dsi %udl - ready\n",
>default_mode.hdisplay, default_mode.vdisplay,
>default_mode.vrefresh,
>mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);
> 

Reviewed-By: Guido Günther 

Thanks,
 -- Guido

P.S.: The cc: list is huge, is there a reason for going way past what
get_maintainers puts out for this patch?



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

Re: [PATCH 5/8] drm: rcar-du: Implement interfaces to set clu and lut using drm data structures

2019-04-04 Thread Ville Syrjälä
On Thu, Apr 04, 2019 at 09:50:47AM +0200, Daniel Vetter wrote:
> On Wed, Apr 03, 2019 at 06:44:41PM +0530, 
> venkatarajesh.kalakod...@in.bosch.com wrote:
> > From: kalakodima venkata rajesh 
> > 
> > Impelement interfaces in cmm to set clu and lut tables using standard
> > drm data structures as input.
> > 
> > Signed-off-by: Harsha M M 
> > 
> >   - Resolved checkpatch errors
> >   - Resolved merge conflicts according to latest version
> > 
> > Signed-off-by: kalakodima venkata rajesh 
> > 
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_cmm.c  | 256 
> > +++--
> >  drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  11 ++
> >  2 files changed, 254 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_cmm.c 
> > b/drivers/gpu/drm/rcar-du/rcar_du_cmm.c
> > index 7983039..af4668f 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_cmm.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_cmm.c
> > @@ -114,6 +114,8 @@ struct rcar_du_cmm_pending_event {
> > struct drm_gem_object *gem_obj;
> > struct rcar_du_cmm *du_cmm;
> > struct rcar_du_cmm_file_priv *fpriv;
> > +   unsigned int *lut_buf;
> > +   unsigned int *clu_buf;
> >  };
> >  
> >  struct cmm_module_t {
> > @@ -238,14 +240,6 @@ static long long diff_timevals(struct timeval *start, 
> > struct timeval *end)
> >  }
> >  #endif
> >  
> > -static void du_cmm_clk(struct rcar_du_cmm *du_cmm, bool on)
> > -{
> > -   if (on)
> > -   clk_prepare_enable(du_cmm->clock);
> > -   else
> > -   clk_disable_unprepare(du_cmm->clock);
> > -}
> > -
> >  static void rcar_du_cmm_queue_lut_update(struct rcar_du_cmm_pending_event 
> > *p)
> >  {
> > mutex_lock(_event_lock);
> > @@ -284,6 +278,223 @@ static void rcar_du_cmm_queue_clu_update(struct 
> > rcar_du_cmm_pending_event *p)
> > drm_crtc_vblank_get(>du_cmm->rcrtc->crtc);
> >  }
> >  
> > +static s64 rcar_du_cmm_multiply_coeff(unsigned int color, s64 coeff)
> > +{
> > +   s64 r_val;
> > +   bool is_neg = false;
> > +
> > +   if (coeff & BIT_ULL(63)) {
> > +   is_neg = true;
> > +   coeff &= ~BIT_ULL(63);
> > +   }
> > +
> > +   r_val = DIV_ROUND_CLOSEST(((s64)(color * coeff)), BIT_ULL(32));
> > +
> > +   if (is_neg)
> > +   return -r_val;
> > +
> > +   return r_val;
> > +}
> > +
> > +static unsigned int rcar_du_cmm_scalar_product(unsigned int r, unsigned 
> > int g,
> > +  unsigned int b, s64 coeff1,
> > +  s64 coeff2, s64 coeff3)
> > +{
> > +   s64 product;
> > +
> > +   product = rcar_du_cmm_multiply_coeff(r, coeff1)
> > +   + rcar_du_cmm_multiply_coeff(g, coeff2)
> > +   + rcar_du_cmm_multiply_coeff(b, coeff3);
> > +
> > +   return (unsigned int)clamp_val(product, 0, U8_MAX);
> > +}
> > +
> > +#ifdef DEBUG_PROCE_TIME
> > +static long long diff_timevals(struct timeval *start, struct timeval *end)
> > +{
> > +   return (end->tv_sec * 100LL + end->tv_usec) -
> > +   (start->tv_sec * 100LL + start->tv_usec);
> > +}
> > +#endif
> > +
> > +void *rcar_du_cmm_alloc_lut(void *cmm_handle)
> > +{
> > +   struct rcar_du_cmm_pending_event *p;
> > +
> > +   if (!cmm_handle)
> > +   return NULL;
> > +
> > +   p = kzalloc(sizeof(*p), GFP_KERNEL);
> > +   if (!p)
> > +   return NULL;
> > +
> > +   p->gem_obj = NULL;
> > +   p->event = CMM_EVENT_LUT_DONE;
> > +   p->stat = QUE_STAT_PENDING;
> > +   p->callback_data = 0;
> > +   p->du_cmm = cmm_handle;
> > +   p->fpriv = NULL;
> > +   p->lut_buf = kmalloc(CMM_LUT_NUM * 4, GFP_KERNEL);
> > +   if (!p->lut_buf) {
> > +   kfree(p);
> > +   return NULL;
> > +   }
> > +
> > +   return p;
> > +}
> > +
> > +void rcar_du_cmm_free_lut(void *lut_handle)
> > +{
> > +   struct rcar_du_cmm_pending_event *p =
> > +   (struct rcar_du_cmm_pending_event *)lut_handle;
> > +
> > +   kfree(p->lut_buf);
> > +   kfree(p);
> > +}
> > +
> > +int rcar_du_cmm_lut_valid(unsigned int lut_length)
> > +{
> > +   return (lut_length == CMM_LUT_NUM) ? 0 : -EINVAL;
> > +}
> > +
> > +void rcar_du_cmm_update_lut_and_free(void *lut_handle,
> > +struct drm_color_lut *lut,
> > +unsigned int lut_length)
> > +{
> > +   struct rcar_du_cmm_pending_event *p =
> > +   (struct rcar_du_cmm_pending_event *)lut_handle;
> > +   unsigned int color;
> > +
> > +   if (!p)
> > +   return;
> > +
> > +   if (rcar_du_cmm_lut_valid(lut_length))
> > +   return;
> > +
> > +   /* Convert drm_color_lut to the format handled by hardware */
> > +   for (color = 0; color < lut_length; color++) {
> > +   p->lut_buf[color] = 0;
> > +   p->lut_buf[color] |= drm_color_lut_extract(lut[color].red, 8)
> > +   << 16;
> > +   p->lut_buf[color] |= drm_color_lut_extract(lut[color].green, 8)
> > +   << 8;

[PATCH v2 4/6] drm: add dstclip parameter to drm_fb_xrgb8888_to_rgb565()

2019-04-04 Thread Gerd Hoffmann
When set apply clipping logic to destination too.

Signed-off-by: Gerd Hoffmann 
---
 include/drm/drm_fb_helper.h| 3 ++-
 drivers/gpu/drm/drm_fb_helper.c| 8 +++-
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 2 +-
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 0350c7e9d6ba..1406057e1a93 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -646,6 +646,7 @@ void drm_fb_memcpy(void *dst, void *vaddr, struct 
drm_framebuffer *fb,
   struct drm_rect *clip, bool dstclip);
 void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
   struct drm_framebuffer *fb,
-  struct drm_rect *clip, bool swap);
+  struct drm_rect *clip,
+  bool swap, bool dstclip);
 
 #endif
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 087e49741094..2c9286702c3f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -3388,13 +3388,15 @@ EXPORT_SYMBOL(drm_fb_memcpy);
  * @fb: DRM framebuffer
  * @clip: Clip rectangle area to copy
  * @swap: Swap bytes
+ * @dstclip: Clip destination too.
  *
  * Drivers can use this function for RGB565 devices that don't natively
  * support XRGB.
  */
 void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
   struct drm_framebuffer *fb,
-  struct drm_rect *clip, bool swap)
+  struct drm_rect *clip,
+  bool swap, bool dstclip)
 {
size_t len = (clip->x2 - clip->x1) * sizeof(u32);
unsigned int x, y;
@@ -3405,6 +3407,8 @@ void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
if (!buf)
return;
 
+   if (dstclip)
+   dst += clip->y1 * fb->width + clip->x1;
for (y = clip->y1; y < clip->y2; y++) {
src = vaddr + (y * fb->pitches[0]);
src += clip->x1;
@@ -3420,6 +3424,8 @@ void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
else
*dst++ = val16;
}
+   if (dstclip)
+   dst += fb->width - (clip->x2 - clip->x1);
}
 
kfree(buf);
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index cf8df5fb7494..b2d74f8707db 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -224,7 +224,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
drm_fb_memcpy(dst, src, fb, clip, false);
break;
case DRM_FORMAT_XRGB:
-   drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap);
+   drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap, false);
break;
default:
dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
-- 
2.18.1

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

[PATCH v2 2/6] drm: add dstclip parameter to drm_fb_memcpy()

2019-04-04 Thread Gerd Hoffmann
When set apply clipping logic to destination too.

Signed-off-by: Gerd Hoffmann 
---
 include/drm/drm_fb_helper.h| 2 +-
 drivers/gpu/drm/drm_fb_helper.c| 6 --
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 2 +-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 696017b38add..a57420f40643 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -643,6 +643,6 @@ drm_fb_helper_remove_conflicting_pci_framebuffers(struct 
pci_dev *pdev,
 }
 
 void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
-  struct drm_rect *clip);
+  struct drm_rect *clip, bool dstclip);
 
 #endif
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 22d29834bbe9..fabeb408dce6 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -3363,7 +3363,7 @@ EXPORT_SYMBOL(drm_fb_helper_modinit);
  * @dstclip: Clip destination too.
  */
 void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
-  struct drm_rect *clip)
+  struct drm_rect *clip, bool dstclip)
 {
unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
unsigned int pitch = fb->pitches[0];
@@ -3371,10 +3371,12 @@ void drm_fb_memcpy(void *dst, void *vaddr, struct 
drm_framebuffer *fb,
size_t len = (clip->x2 - clip->x1) * cpp;
unsigned int y;
 
+   if (dstclip)
+   dst += (clip->y1 * pitch) + (clip->x1 * cpp);
for (y = clip->y1; y < clip->y2; y++) {
memcpy(dst, src, len);
src += pitch;
-   dst += len;
+   dst += dstclip ? pitch : len;
}
 }
 EXPORT_SYMBOL(drm_fb_memcpy);
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index fb7e4582e293..e26fd61360a3 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -221,7 +221,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
if (swap)
tinydrm_swab16(dst, src, fb, clip);
else
-   drm_fb_memcpy(dst, src, fb, clip);
+   drm_fb_memcpy(dst, src, fb, clip, false);
break;
case DRM_FORMAT_XRGB:
tinydrm_xrgb_to_rgb565(dst, src, fb, clip, swap);
-- 
2.18.1

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

[PATCH v2 3/6] drm: move tinydrm_xrgb8888_to_rgb565() to drm_fb_helper.c

2019-04-04 Thread Gerd Hoffmann
Also rename to drm_fb_xrgb_to_rgb565().
Pure code motion, no functional change.

Signed-off-by: Gerd Hoffmann 
---
 include/drm/drm_fb_helper.h   |  3 ++
 include/drm/tinydrm/tinydrm-helpers.h |  3 --
 drivers/gpu/drm/drm_fb_helper.c   | 45 +++
 .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 45 ---
 drivers/gpu/drm/tinydrm/mipi-dbi.c|  2 +-
 5 files changed, 49 insertions(+), 49 deletions(-)

diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index a57420f40643..0350c7e9d6ba 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -644,5 +644,8 @@ drm_fb_helper_remove_conflicting_pci_framebuffers(struct 
pci_dev *pdev,
 
 void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
   struct drm_rect *clip, bool dstclip);
+void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
+  struct drm_framebuffer *fb,
+  struct drm_rect *clip, bool swap);
 
 #endif
diff --git a/include/drm/tinydrm/tinydrm-helpers.h 
b/include/drm/tinydrm/tinydrm-helpers.h
index 591ca83330c4..220677107e0c 100644
--- a/include/drm/tinydrm/tinydrm-helpers.h
+++ b/include/drm/tinydrm/tinydrm-helpers.h
@@ -48,9 +48,6 @@ int tinydrm_display_pipe_init(struct drm_device *drm,
 
 void tinydrm_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
-void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
-   struct drm_framebuffer *fb,
-   struct drm_rect *clip, bool swap);
 void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer 
*fb,
   struct drm_rect *clip);
 
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index fabeb408dce6..087e49741094 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -3380,3 +3380,48 @@ void drm_fb_memcpy(void *dst, void *vaddr, struct 
drm_framebuffer *fb,
}
 }
 EXPORT_SYMBOL(drm_fb_memcpy);
+
+/**
+ * drm_fb_xrgb_to_rgb565 - Convert XRGB to RGB565 clip buffer
+ * @dst: RGB565 destination buffer
+ * @vaddr: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ * @swap: Swap bytes
+ *
+ * Drivers can use this function for RGB565 devices that don't natively
+ * support XRGB.
+ */
+void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
+  struct drm_framebuffer *fb,
+  struct drm_rect *clip, bool swap)
+{
+   size_t len = (clip->x2 - clip->x1) * sizeof(u32);
+   unsigned int x, y;
+   u32 *src, *buf;
+   u16 val16;
+
+   buf = kmalloc(len, GFP_KERNEL);
+   if (!buf)
+   return;
+
+   for (y = clip->y1; y < clip->y2; y++) {
+   src = vaddr + (y * fb->pitches[0]);
+   src += clip->x1;
+   memcpy(buf, src, len);
+   src = buf;
+   for (x = clip->x1; x < clip->x2; x++) {
+   val16 = ((*src & 0x00F8) >> 8) |
+   ((*src & 0xFC00) >> 5) |
+   ((*src & 0x00F8) >> 3);
+   src++;
+   if (swap)
+   *dst++ = swab16(val16);
+   else
+   *dst++ = val16;
+   }
+   }
+
+   kfree(buf);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index f5c6f35e6161..f4b84b15da75 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -61,51 +61,6 @@ void tinydrm_swab16(u16 *dst, void *vaddr, struct 
drm_framebuffer *fb,
 }
 EXPORT_SYMBOL(tinydrm_swab16);
 
-/**
- * tinydrm_xrgb_to_rgb565 - Convert XRGB to RGB565 clip buffer
- * @dst: RGB565 destination buffer
- * @vaddr: XRGB source buffer
- * @fb: DRM framebuffer
- * @clip: Clip rectangle area to copy
- * @swap: Swap bytes
- *
- * Drivers can use this function for RGB565 devices that don't natively
- * support XRGB.
- */
-void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
-   struct drm_framebuffer *fb,
-   struct drm_rect *clip, bool swap)
-{
-   size_t len = (clip->x2 - clip->x1) * sizeof(u32);
-   unsigned int x, y;
-   u32 *src, *buf;
-   u16 val16;
-
-   buf = kmalloc(len, GFP_KERNEL);
-   if (!buf)
-   return;
-
-   for (y = clip->y1; y < clip->y2; y++) {
-   src = vaddr + (y * fb->pitches[0]);
-   src += clip->x1;
-   memcpy(buf, src, len);
-   src = buf;
-   for (x = clip->x1; x < clip->x2; x++) {
-   

[PATCH v2 6/6] drm/cirrus: rewrite and modernize driver.

2019-04-04 Thread Gerd Hoffmann
Time to kill some bad sample code people are copying from ;)

This is a complete rewrite of the cirrus driver.  The cirrus_mode_set()
function is pretty much the only function which is carried over largely
unmodified.  Everything else is upside down.

It is a single monster patch.  But given that it does some pretty
fundamental changes to the drivers workflow and also reduces the code
size by roughly 70% I think it'll still be alot easier to review than a
longish baby-step patch series.

Changes summary:
 - Given the small amout of video memory (4 MB) the cirrus device has
   the rewritten driver doesn't try to manage buffers there.  Instead
   it will blit (memcpy) the active framebuffer to video memory.
 - All gem objects are stored in main memory and are manged using the
   new shmem helpers.  ttm is out.
 - It supports RG16, RG24 and XR24 formats.  XR24 gets converted to RG24
   or RG16 at blit time if needed, to avoid the pitch becoming larger
   than what the cirrus hardware can handle.
 - The simple display pipeline is used.
 - The generic fbdev emulation is used.
 - It's a atomic driver now.
 - It runs wayland.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/cirrus/cirrus_drv.h   | 251 ---
 drivers/gpu/drm/cirrus/cirrus.c   | 621 ++
 drivers/gpu/drm/cirrus/cirrus_drv.c   | 161 ---
 drivers/gpu/drm/cirrus/cirrus_fbdev.c | 309 -
 drivers/gpu/drm/cirrus/cirrus_main.c  | 328 --
 drivers/gpu/drm/cirrus/cirrus_mode.c  | 617 -
 drivers/gpu/drm/cirrus/cirrus_ttm.c   | 343 --
 drivers/gpu/drm/cirrus/Kconfig|   2 +-
 drivers/gpu/drm/cirrus/Makefile   |   3 -
 9 files changed, 622 insertions(+), 2013 deletions(-)
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_drv.h
 create mode 100644 drivers/gpu/drm/cirrus/cirrus.c
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_drv.c
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_fbdev.c
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_main.c
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_mode.c
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_ttm.c

diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h 
b/drivers/gpu/drm/cirrus/cirrus_drv.h
deleted file mode 100644
index 828b150cdb20..
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ /dev/null
@@ -1,251 +0,0 @@
-/*
- * Copyright 2012 Red Hat
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License version 2. See the file COPYING in the main
- * directory of this archive for more details.
- *
- * Authors: Matthew Garrett
- *  Dave Airlie
- */
-#ifndef __CIRRUS_DRV_H__
-#define __CIRRUS_DRV_H__
-
-#include 
-
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#define DRIVER_AUTHOR  "Matthew Garrett"
-
-#define DRIVER_NAME"cirrus"
-#define DRIVER_DESC"qemu Cirrus emulation"
-#define DRIVER_DATE"20110418"
-
-#define DRIVER_MAJOR   1
-#define DRIVER_MINOR   0
-#define DRIVER_PATCHLEVEL  0
-
-#define CIRRUSFB_CONN_LIMIT 1
-
-#define RREG8(reg) ioread8(((void __iomem *)cdev->rmmio) + (reg))
-#define WREG8(reg, v) iowrite8(v, ((void __iomem *)cdev->rmmio) + (reg))
-#define RREG32(reg) ioread32(((void __iomem *)cdev->rmmio) + (reg))
-#define WREG32(reg, v) iowrite32(v, ((void __iomem *)cdev->rmmio) + (reg))
-
-#define SEQ_INDEX 4
-#define SEQ_DATA 5
-
-#define WREG_SEQ(reg, v)   \
-   do {\
-   WREG8(SEQ_INDEX, reg);  \
-   WREG8(SEQ_DATA, v); \
-   } while (0) \
-
-#define CRT_INDEX 0x14
-#define CRT_DATA 0x15
-
-#define WREG_CRT(reg, v)   \
-   do {\
-   WREG8(CRT_INDEX, reg);  \
-   WREG8(CRT_DATA, v); \
-   } while (0) \
-
-#define GFX_INDEX 0xe
-#define GFX_DATA 0xf
-
-#define WREG_GFX(reg, v)   \
-   do {\
-   WREG8(GFX_INDEX, reg);  \
-   WREG8(GFX_DATA, v); \
-   } while (0) \
-
-/*
- * Cirrus has a "hidden" DAC register that can be accessed by writing to
- * the pixel mask register to reset the state, then reading from the register
- * four times. The next write will then pass to the DAC
- */
-#define VGA_DAC_MASK 0x6
-
-#define WREG_HDR(v)\
-   do {\
-   RREG8(VGA_DAC_MASK); 

[PATCH v2 5/6] drm: add drm_fb_xrgb8888_to_rgb888() function to drm_fb_helper.c

2019-04-04 Thread Gerd Hoffmann
Like drm_fb_xrgb_to_rgb565() but converts to 24bpp (DRM_FORMAT_RGB888).

Signed-off-by: Gerd Hoffmann 
---
 include/drm/drm_fb_helper.h |  4 +++
 drivers/gpu/drm/drm_fb_helper.c | 49 +
 2 files changed, 53 insertions(+)

diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 1406057e1a93..a6e56fcd948e 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -648,5 +648,9 @@ void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
   struct drm_framebuffer *fb,
   struct drm_rect *clip,
   bool swap, bool dstclip);
+void drm_fb_xrgb_to_rgb888(u8 *dst, void *vaddr,
+  struct drm_framebuffer *fb,
+  struct drm_rect *clip,
+  bool dstclip);
 
 #endif
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 2c9286702c3f..6ef0ad4f40b1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -3431,3 +3431,52 @@ void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
kfree(buf);
 }
 EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
+
+/**
+ * drm_fb_xrgb_to_rgb888 - Convert XRGB to RGB888 clip buffer
+ * @dst: RGB565 destination buffer
+ * @vaddr: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ * @dstclip: Clip destination too.
+ *
+ * Drivers can use this function for RGB888 devices that don't natively
+ * support XRGB.
+ */
+void drm_fb_xrgb_to_rgb888(u8 *dst, void *vaddr,
+  struct drm_framebuffer *fb,
+  struct drm_rect *clip,
+  bool dstclip)
+{
+   size_t len = (clip->x2 - clip->x1) * sizeof(u32);
+   unsigned int x, y;
+   u32 *src, *buf;
+   u8 red, green, blue;
+
+   buf = kmalloc(len, GFP_KERNEL);
+   if (!buf)
+   return;
+
+   if (dstclip)
+   dst += (clip->y1 * fb->width + clip->x1) * 3;
+   for (y = clip->y1; y < clip->y2; y++) {
+   src = vaddr + (y * fb->pitches[0]);
+   src += clip->x1;
+   memcpy(buf, src, len);
+   src = buf;
+   for (x = clip->x1; x < clip->x2; x++) {
+   red   = (*src & 0x00FF) >> 16;
+   green = (*src & 0xFF00) >>  8;
+   blue  = (*src & 0x00FF) >>  0;
+   src++;
+   *dst++ = blue;
+   *dst++ = green;
+   *dst++ = red;
+   }
+   if (dstclip)
+   dst += (fb->width - (clip->x2 - clip->x1)) * 3;
+   }
+
+   kfree(buf);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888);
-- 
2.18.1

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

[PATCH v2 0/6] drm/cirrus: rewrite and modernize driver.

2019-04-04 Thread Gerd Hoffmann
v2:
 - It's a little series now.  It moves tinydrm converters
   to drm_fb_helpers.c first.
 - Added support for RG24 and XR24.  Without bpp module
   parameter, instead the driver will convert formats if
   needed.
 - A bunch of little tweaks here and there (embedded
   struct drm_driver, use more drm helpers, ...)

Gerd Hoffmann (6):
  drm: move tinydrm_memcpy() to drm_fb_helper.c
  drm: add dstclip parameter to drm_fb_memcpy()
  drm: move tinydrm_xrgb_to_rgb565() to drm_fb_helper.c
  drm: add dstclip parameter to drm_fb_xrgb_to_rgb565()
  drm: add drm_fb_xrgb_to_rgb888() function to drm_fb_helper.c
  drm/cirrus: rewrite and modernize driver.

 drivers/gpu/drm/cirrus/cirrus_drv.h   | 251 ---
 include/drm/drm_fb_helper.h   |  11 +
 include/drm/tinydrm/tinydrm-helpers.h |   5 -
 drivers/gpu/drm/cirrus/cirrus.c   | 621 ++
 drivers/gpu/drm/cirrus/cirrus_drv.c   | 161 -
 drivers/gpu/drm/cirrus/cirrus_fbdev.c | 309 -
 drivers/gpu/drm/cirrus/cirrus_main.c  | 328 -
 drivers/gpu/drm/cirrus/cirrus_mode.c  | 617 -
 drivers/gpu/drm/cirrus/cirrus_ttm.c   | 343 --
 drivers/gpu/drm/drm_fb_helper.c   | 127 
 .../gpu/drm/tinydrm/core/tinydrm-helpers.c|  69 --
 drivers/gpu/drm/tinydrm/mipi-dbi.c|   5 +-
 drivers/gpu/drm/cirrus/Kconfig|   2 +-
 drivers/gpu/drm/cirrus/Makefile   |   3 -
 14 files changed, 763 insertions(+), 2089 deletions(-)
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_drv.h
 create mode 100644 drivers/gpu/drm/cirrus/cirrus.c
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_drv.c
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_fbdev.c
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_main.c
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_mode.c
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_ttm.c

-- 
2.18.1

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

[PATCH v2 1/6] drm: move tinydrm_memcpy() to drm_fb_helper.c

2019-04-04 Thread Gerd Hoffmann
Also rename to drm_fb_memcpy().
Pure code motion, no functional change.

Signed-off-by: Gerd Hoffmann 
---
 include/drm/drm_fb_helper.h   |  3 +++
 include/drm/tinydrm/tinydrm-helpers.h |  2 --
 drivers/gpu/drm/drm_fb_helper.c   | 25 +++
 .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 24 --
 drivers/gpu/drm/tinydrm/mipi-dbi.c|  3 ++-
 5 files changed, 30 insertions(+), 27 deletions(-)

diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 81ae48a0df48..696017b38add 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -642,4 +642,7 @@ drm_fb_helper_remove_conflicting_pci_framebuffers(struct 
pci_dev *pdev,
 #endif
 }
 
+void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
+  struct drm_rect *clip);
+
 #endif
diff --git a/include/drm/tinydrm/tinydrm-helpers.h 
b/include/drm/tinydrm/tinydrm-helpers.h
index ae4a6abc43b5..591ca83330c4 100644
--- a/include/drm/tinydrm/tinydrm-helpers.h
+++ b/include/drm/tinydrm/tinydrm-helpers.h
@@ -46,8 +46,6 @@ int tinydrm_display_pipe_init(struct drm_device *drm,
  const struct drm_display_mode *mode,
  unsigned int rotation);
 
-void tinydrm_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
-   struct drm_rect *clip);
 void tinydrm_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
 void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 03749a24e4dd..22d29834bbe9 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -3353,3 +3353,28 @@ int __init drm_fb_helper_modinit(void)
return 0;
 }
 EXPORT_SYMBOL(drm_fb_helper_modinit);
+
+/**
+ * drm_fb_memcpy - Copy clip buffer
+ * @dst: Destination buffer
+ * @vaddr: Source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ * @dstclip: Clip destination too.
+ */
+void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
+  struct drm_rect *clip)
+{
+   unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
+   unsigned int pitch = fb->pitches[0];
+   void *src = vaddr + (clip->y1 * pitch) + (clip->x1 * cpp);
+   size_t len = (clip->x2 - clip->x1) * cpp;
+   unsigned int y;
+
+   for (y = clip->y1; y < clip->y2; y++) {
+   memcpy(dst, src, len);
+   src += pitch;
+   dst += len;
+   }
+}
+EXPORT_SYMBOL(drm_fb_memcpy);
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d7b38dfb6438..f5c6f35e6161 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -26,30 +26,6 @@ static unsigned int spi_max;
 module_param(spi_max, uint, 0400);
 MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size");
 
-/**
- * tinydrm_memcpy - Copy clip buffer
- * @dst: Destination buffer
- * @vaddr: Source buffer
- * @fb: DRM framebuffer
- * @clip: Clip rectangle area to copy
- */
-void tinydrm_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
-   struct drm_rect *clip)
-{
-   unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
-   unsigned int pitch = fb->pitches[0];
-   void *src = vaddr + (clip->y1 * pitch) + (clip->x1 * cpp);
-   size_t len = (clip->x2 - clip->x1) * cpp;
-   unsigned int y;
-
-   for (y = clip->y1; y < clip->y2; y++) {
-   memcpy(dst, src, len);
-   src += pitch;
-   dst += len;
-   }
-}
-EXPORT_SYMBOL(tinydrm_memcpy);
-
 /**
  * tinydrm_swab16 - Swap bytes into clip buffer
  * @dst: RGB565 destination buffer
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 869c8f56da3b..fb7e4582e293 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -220,7 +221,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
if (swap)
tinydrm_swab16(dst, src, fb, clip);
else
-   tinydrm_memcpy(dst, src, fb, clip);
+   drm_fb_memcpy(dst, src, fb, clip);
break;
case DRM_FORMAT_XRGB:
tinydrm_xrgb_to_rgb565(dst, src, fb, clip, swap);
-- 
2.18.1

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

[PATCH 2/3] drm/panfrost: Expose HW counters to userspace

2019-04-04 Thread Boris Brezillon
Add the necessary infrastructure to expose GPU counters to userspace.
This takes the form of 4 new ioctls to:

- query the available counters
- create/destroy a performance monitor
- retrieve its values

The drm_panfrost_submit struct is extended to pass a list of perfmons
to attach to a job, which means perfmons will only track changes caused
by the jobs they are attached too.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panfrost/Makefile   |   3 +-
 drivers/gpu/drm/panfrost/panfrost_device.c  |   8 +
 drivers/gpu/drm/panfrost/panfrost_device.h  |  11 +
 drivers/gpu/drm/panfrost/panfrost_drv.c |  22 +-
 drivers/gpu/drm/panfrost/panfrost_gpu.c |  43 +-
 drivers/gpu/drm/panfrost/panfrost_job.c |  24 +
 drivers/gpu/drm/panfrost/panfrost_job.h |   4 +
 drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 954 
 drivers/gpu/drm/panfrost/panfrost_perfcnt.h |  54 ++
 drivers/gpu/drm/panfrost/panfrost_regs.h|  19 +
 include/uapi/drm/panfrost_drm.h | 122 +++
 11 files changed, 1260 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.c
 create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.h

diff --git a/drivers/gpu/drm/panfrost/Makefile 
b/drivers/gpu/drm/panfrost/Makefile
index d07e0971b687..31cfb9d25682 100644
--- a/drivers/gpu/drm/panfrost/Makefile
+++ b/drivers/gpu/drm/panfrost/Makefile
@@ -6,6 +6,7 @@ panfrost-y := \
panfrost_gem.o \
panfrost_gpu.o \
panfrost_job.o \
-   panfrost_mmu.o
+   panfrost_mmu.o \
+   panfrost_perfcnt.o
 
 obj-$(CONFIG_DRM_PANFROST) += panfrost.o
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 148b5caa2322..f6a87bfa486b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -13,6 +13,7 @@
 #include "panfrost_gpu.h"
 #include "panfrost_job.h"
 #include "panfrost_mmu.h"
+#include "panfrost_perfcnt.h"
 
 static int panfrost_reset_init(struct panfrost_device *pfdev)
 {
@@ -147,7 +148,13 @@ int panfrost_device_init(struct panfrost_device *pfdev)
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_put_autosuspend(pfdev->dev);
 
+   err = panfrost_perfcnt_init(pfdev);
+   if (err)
+   goto err_out5;
+
return 0;
+err_out5:
+   panfrost_job_fini(pfdev);
 err_out4:
panfrost_mmu_fini(pfdev);
 err_out3:
@@ -163,6 +170,7 @@ int panfrost_device_init(struct panfrost_device *pfdev)
 
 void panfrost_device_fini(struct panfrost_device *pfdev)
 {
+   panfrost_perfcnt_fini(pfdev);
panfrost_job_fini(pfdev);
panfrost_mmu_fini(pfdev);
panfrost_gpu_fini(pfdev);
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h 
b/drivers/gpu/drm/panfrost/panfrost_device.h
index a821b50a14c3..f7c4e9e55f1b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -9,11 +9,13 @@
 #include 
 #include 
 #include 
+#include 
 
 struct panfrost_device;
 struct panfrost_mmu;
 struct panfrost_job_slot;
 struct panfrost_job;
+struct panfrost_perfcnt;
 
 #define NUM_JOB_SLOTS 3
 
@@ -45,6 +47,8 @@ struct panfrost_features {
 
unsigned long hw_features[64 / BITS_PER_LONG];
unsigned long hw_issues[64 / BITS_PER_LONG];
+
+   struct drm_panfrost_block_perfcounters 
perfcnt_layout[PANFROST_NUM_BLOCKS];
 };
 
 struct panfrost_device {
@@ -70,6 +74,8 @@ struct panfrost_device {
struct panfrost_job *jobs[NUM_JOB_SLOTS];
struct list_head scheduled_jobs;
 
+   struct panfrost_perfcnt *perfcnt;
+
struct mutex sched_lock;
 };
 
@@ -77,6 +83,11 @@ struct panfrost_file_priv {
struct panfrost_device *pfdev;
 
struct drm_sched_entity sched_entity[NUM_JOB_SLOTS];
+
+   struct {
+   struct idr idr;
+   struct mutex lock;
+   } perfmon;
 };
 
 static inline struct panfrost_device *to_panfrost_device(struct drm_device 
*ddev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 8cffb70a3548..e5375b31627f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -19,6 +19,7 @@
 #include "panfrost_mmu.h"
 #include "panfrost_job.h"
 #include "panfrost_gpu.h"
+#include "panfrost_perfcnt.h"
 
 static int panfrost_ioctl_get_param(struct drm_device *ddev, void *data, 
struct drm_file *file)
 {
@@ -219,6 +220,10 @@ static int panfrost_ioctl_submit(struct drm_device *dev, 
void *data,
if (ret)
goto fail;
 
+   ret = panfrost_perfcnt_create_job_ctx(job, file, args);
+   if (ret)
+   goto fail;
+
ret = panfrost_job_push(job);
if (ret)
goto fail;
@@ -313,6 +318,7 @@ panfrost_open(struct drm_device *dev, struct drm_file *file)
 {
struct panfrost_device *pfdev = dev->dev_private;
struct 

[PATCH 0/3] drm/panfrost: Expose HW counters to userspace

2019-04-04 Thread Boris Brezillon
Hello,

This patch adds new ioctls to expose GPU counters to userspace.
These will be used by the mesa driver (should be posted soon).

A few words about the implementation: I followed the VC4/Etnaviv model
where perf counters are retrieved on a per-job basis. This allows one
to have get accurate results when there are users using the GPU
concurrently.
AFAICT, the mali kbase is using a different approach where several
users can register a performance monitor but with no way to have fined
grained control over what job/GPU-context to track.

This design choice comes at a cost: every time the perfmon context
changes (the perfmon context is the list of currently active
perfmons), the driver has to add a fence to prevent new jobs from
corrupting counters that will be dumped by previous jobs.

Let me know if that's an issue and if you think we should approach
things differently.

Regards,

Boris

Boris Brezillon (3):
  drm/panfrost: Move gpu_{write,read}() macros to panfrost_regs.h
  drm/panfrost: Expose HW counters to userspace
  panfrost/drm: Define T860 perf counters

 drivers/gpu/drm/panfrost/Makefile   |   3 +-
 drivers/gpu/drm/panfrost/panfrost_device.c  |   8 +
 drivers/gpu/drm/panfrost/panfrost_device.h  |  11 +
 drivers/gpu/drm/panfrost/panfrost_drv.c |  22 +-
 drivers/gpu/drm/panfrost/panfrost_gpu.c |  46 +-
 drivers/gpu/drm/panfrost/panfrost_job.c |  24 +
 drivers/gpu/drm/panfrost/panfrost_job.h |   4 +
 drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 954 
 drivers/gpu/drm/panfrost/panfrost_perfcnt.h |  59 ++
 drivers/gpu/drm/panfrost/panfrost_regs.h|  22 +
 include/uapi/drm/panfrost_drm.h | 122 +++
 11 files changed, 1268 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.c
 create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.h

-- 
2.20.1

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

[PATCH 1/3] drm/panfrost: Move gpu_{write, read}() macros to panfrost_regs.h

2019-04-04 Thread Boris Brezillon
So they can be used from other files.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panfrost/panfrost_gpu.c  | 3 ---
 drivers/gpu/drm/panfrost/panfrost_regs.h | 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c 
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 867e2ba3a761..d46d36170e18 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -15,9 +15,6 @@
 #include "panfrost_gpu.h"
 #include "panfrost_regs.h"
 
-#define gpu_write(dev, reg, data) writel(data, dev->iomem + reg)
-#define gpu_read(dev, reg) readl(dev->iomem + reg)
-
 static irqreturn_t panfrost_gpu_irq_handler(int irq, void *data)
 {
struct panfrost_device *pfdev = data;
diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h 
b/drivers/gpu/drm/panfrost/panfrost_regs.h
index 578c5fc2188b..42d08860fd76 100644
--- a/drivers/gpu/drm/panfrost/panfrost_regs.h
+++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
@@ -295,4 +295,7 @@
 #define AS_FAULTSTATUS_ACCESS_TYPE_READ(0x2 << 8)
 #define AS_FAULTSTATUS_ACCESS_TYPE_WRITE   (0x3 << 8)
 
+#define gpu_write(dev, reg, data) writel(data, dev->iomem + reg)
+#define gpu_read(dev, reg) readl(dev->iomem + reg)
+
 #endif
-- 
2.20.1

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

[PATCH 3/3] panfrost/drm: Define T860 perf counters

2019-04-04 Thread Boris Brezillon
So that userspace can now query perfcount values on T860.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panfrost/panfrost_perfcnt.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_perfcnt.h 
b/drivers/gpu/drm/panfrost/panfrost_perfcnt.h
index 7cbfeb072aa1..d1d275a3d750 100644
--- a/drivers/gpu/drm/panfrost/panfrost_perfcnt.h
+++ b/drivers/gpu/drm/panfrost/panfrost_perfcnt.h
@@ -18,7 +18,12 @@ struct panfrost_perfcnt_job_ctx;
 #define hw_perfcnt_t760NO_PERFCNT
 #define hw_perfcnt_t820NO_PERFCNT
 #define hw_perfcnt_t830NO_PERFCNT
-#define hw_perfcnt_t860NO_PERFCNT
+#define hw_perfcnt_t860PERFCNT(GENMASK_ULL(63, 4), 
\
+   GENMASK_ULL(63, 59) | GENMASK_ULL(53, 3),   
\
+   GENMASK_ULL(63, 46) | GENMASK_ULL(44, 30) | 
\
+   GENMASK_ULL(16, 12) | GENMASK_ULL(9, 4),
\
+   GENMASK_ULL(31, 28) | GENMASK_ULL(26, 20) | 
\
+   GENMASK_ULL(18, 12) | GENMASK_ULL(10, 4))
 #define hw_perfcnt_t880NO_PERFCNT
 #define hw_perfcnt_g76 NO_PERFCNT
 #define hw_perfcnt_g71 NO_PERFCNT
-- 
2.20.1

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

[PATCH] drm/panel: Rocktech jh057n00900: Add terminating newlines to logging

2019-04-04 Thread Joe Perches
These were missing '\n' terminations, add them.

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c 
b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
index 158a6d548068..d88ea8da2ec2 100644
--- a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
+++ b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
@@ -123,7 +123,7 @@ static int jh057n_init_sequence(struct jh057n *ctx)
 
ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
if (ret < 0) {
-   DRM_DEV_ERROR(dev, "Failed to exit sleep mode");
+   DRM_DEV_ERROR(dev, "Failed to exit sleep mode\n");
return ret;
}
/* Panel is operational 120 msec after reset */
@@ -132,7 +132,7 @@ static int jh057n_init_sequence(struct jh057n *ctx)
if (ret)
return ret;
 
-   DRM_DEV_DEBUG_DRIVER(dev, "Panel init sequence done");
+   DRM_DEV_DEBUG_DRIVER(dev, "Panel init sequence done\n");
return 0;
 }
 
@@ -172,7 +172,7 @@ static int jh057n_prepare(struct drm_panel *panel)
if (ctx->prepared)
return 0;
 
-   DRM_DEV_DEBUG_DRIVER(ctx->dev, "Resetting the panel.");
+   DRM_DEV_DEBUG_DRIVER(ctx->dev, "Resetting the panel\n");
gpiod_set_value_cansleep(ctx->reset_gpio, 1);
usleep_range(20, 40);
gpiod_set_value_cansleep(ctx->reset_gpio, 0);
@@ -180,7 +180,8 @@ static int jh057n_prepare(struct drm_panel *panel)
 
ret = jh057n_init_sequence(ctx);
if (ret < 0) {
-   DRM_DEV_ERROR(ctx->dev, "Panel init sequence failed: %d", ret);
+   DRM_DEV_ERROR(ctx->dev, "Panel init sequence failed: %d\n",
+ ret);
return ret;
}
 
@@ -212,7 +213,7 @@ static int jh057n_get_modes(struct drm_panel *panel)
 
mode = drm_mode_duplicate(panel->drm, _mode);
if (!mode) {
-   DRM_DEV_ERROR(ctx->dev, "Failed to add mode %ux%u@%u",
+   DRM_DEV_ERROR(ctx->dev, "Failed to add mode %ux%u@%u\n",
  default_mode.hdisplay, default_mode.vdisplay,
  default_mode.vrefresh);
return -ENOMEM;
@@ -241,7 +242,7 @@ static int allpixelson_set(void *data, u64 val)
struct jh057n *ctx = data;
struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
 
-   DRM_DEV_DEBUG_DRIVER(ctx->dev, "Setting all pixels on");
+   DRM_DEV_DEBUG_DRIVER(ctx->dev, "Setting all pixels on\n");
dsi_generic_write_seq(dsi, ST7703_CMD_ALL_PIXEL_ON);
msleep(val * 1000);
/* Reset the panel to get video back */
@@ -290,7 +291,7 @@ static int jh057n_probe(struct mipi_dsi_device *dsi)
 
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(ctx->reset_gpio)) {
-   DRM_DEV_ERROR(dev, "cannot get reset gpio");
+   DRM_DEV_ERROR(dev, "cannot get reset gpio\n");
return PTR_ERR(ctx->reset_gpio);
}
 
@@ -315,12 +316,12 @@ static int jh057n_probe(struct mipi_dsi_device *dsi)
 
ret = mipi_dsi_attach(dsi);
if (ret < 0) {
-   DRM_DEV_ERROR(dev, "mipi_dsi_attach failed. Is host ready?");
+   DRM_DEV_ERROR(dev, "mipi_dsi_attach failed. Is host ready?\n");
drm_panel_remove(>panel);
return ret;
}
 
-   DRM_DEV_INFO(dev, "%ux%u@%u %ubpp dsi %udl - ready",
+   DRM_DEV_INFO(dev, "%ux%u@%u %ubpp dsi %udl - ready\n",
 default_mode.hdisplay, default_mode.vdisplay,
 default_mode.vrefresh,
 mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);


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

Re: [PATCH] Revert "Documentation/gpu/meson: Remove link to meson_canvas.c"

2019-04-04 Thread Sean Paul
On Thu, Apr 04, 2019 at 04:43:42PM +0200, Neil Armstrong wrote:
> This reverts commit a3f98bb22cbfaaf67717e156f79e2bfeb42d4cac.
> 
> Patch "Documentation/gpu/meson: Remove link to meson_canvas.c" was
> incorrectly applied on the wrong branch not containing the fixed
> commit 2bf6b5b0e374 ("drm/meson: exclusively use the canvas provider module")
> 
> Signed-off-by: Neil Armstrong 

Acked-by: Sean Paul 

and I'll leave this for Maxime to apply if he so chooses.

Sean

> ---
>  Documentation/gpu/meson.rst | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/gpu/meson.rst b/Documentation/gpu/meson.rst
> index b9e2f9aa3bd8..479f6f51a13b 100644
> --- a/Documentation/gpu/meson.rst
> +++ b/Documentation/gpu/meson.rst
> @@ -42,6 +42,12 @@ Video Encoder
>  .. kernel-doc:: drivers/gpu/drm/meson/meson_venc.c
> :doc: Video Encoder
>  
> +Video Canvas Management
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/meson/meson_canvas.c
> +   :doc: Canvas
> +
>  Video Clocks
>  
>  
> -- 
> 2.21.0
> 

-- 
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] Revert "Documentation/gpu/meson: Remove link to meson_canvas.c"

2019-04-04 Thread Neil Armstrong
This reverts commit a3f98bb22cbfaaf67717e156f79e2bfeb42d4cac.

Patch "Documentation/gpu/meson: Remove link to meson_canvas.c" was
incorrectly applied on the wrong branch not containing the fixed
commit 2bf6b5b0e374 ("drm/meson: exclusively use the canvas provider module")

Signed-off-by: Neil Armstrong 
---
 Documentation/gpu/meson.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/gpu/meson.rst b/Documentation/gpu/meson.rst
index b9e2f9aa3bd8..479f6f51a13b 100644
--- a/Documentation/gpu/meson.rst
+++ b/Documentation/gpu/meson.rst
@@ -42,6 +42,12 @@ Video Encoder
 .. kernel-doc:: drivers/gpu/drm/meson/meson_venc.c
:doc: Video Encoder
 
+Video Canvas Management
+===
+
+.. kernel-doc:: drivers/gpu/drm/meson/meson_canvas.c
+   :doc: Canvas
+
 Video Clocks
 
 
-- 
2.21.0

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

Re: [PATCH v4 3/4] drm/vc4: Check for the binner bo before handling OOM interrupt

2019-04-04 Thread Paul Kocialkowski
Hey,

Le mercredi 03 avril 2019 à 11:58 -0700, Eric Anholt a écrit :
> Paul Kocialkowski  writes:
> 
> > Since the OOM interrupt directly deals with the binner bo, it doesn't
> > make sense to try and handle it without a binner buffer registered.
> > The interrupt will kick again in due time, so we can safely ignore it
> > without a binner bo allocated.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/gpu/drm/vc4/vc4_irq.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
> > index ffd0a4388752..723dc86b4511 100644
> > --- a/drivers/gpu/drm/vc4/vc4_irq.c
> > +++ b/drivers/gpu/drm/vc4/vc4_irq.c
> > @@ -64,6 +64,9 @@ vc4_overflow_mem_work(struct work_struct *work)
> > struct vc4_exec_info *exec;
> > unsigned long irqflags;
> 
> Since OOM handling is tricky, could we add a comment to help the next
> person try to understand it:
> 
> /* The OOM IRQ is level-triggered, so we'll see one at power-on before
>  * any jobs are submitted.  The OOM IRQ is masked when this work is
>  * scheduled, so we can safely return if there's no binner memory
>  * (because no client is currently using 3D).  When a bin job is
>  * later submitted, its tile memory allocation will end up bringing us
>  * back to a non-OOM state so the OOM can be triggered again.
>  */
> 
> But, actually, I don't see how the OOM IRQ will ever get re-enabled.

Okay so I investigated that to try and understand what's going on.
We are definitely writing the OUTOMEM bit to V3D_INTDIS just before
scheduling the workqueue, and never re-enable the IRQ when leaving
early in the workqueue because !vc4->bin_bo.

It turns out that what saves us here is vc4_irq_postinstall being
called from runtime resume at "the right time". Obviously this is more
than fragile, so we should really be re-enabling the IRQ as soon as we
have the binner bo allocated.

Since we're now allocating at the first non-dumb bo alloc, I think we
need to make sure that we did in fact get the irq and registered the
allocated BO with the workqueue before submitting the rcl. Or does the
hardware provide any mechanism to take that off our hands somehow?

What do you think?

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [PATCH] Documentation/gpu/meson: Remove link to meson_canvas.c

2019-04-04 Thread Sean Paul
On Thu, Apr 04, 2019 at 10:28:29AM +0200, Neil Armstrong wrote:
> On 04/04/2019 08:56, Neil Armstrong wrote:
> > On 03/04/2019 22:56, Sean Paul wrote:
> >> From: Sean Paul 
> >>
> >> The file was removed in the below patch and is causing this error:
> >> WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -function 
> >> Canvas ../drivers/gpu/drm/meson/meson_canvas.c' failed with return code
> >>
> >> Fixes: 2bf6b5b0e374 ("drm/meson: exclusively use the canvas provider 
> >> module")
> >> Cc: Maxime Jourdan 
> >> Cc: Neil Armstrong 
> >> Cc: Kevin Hilman 
> >> Cc: dri-devel@lists.freedesktop.org
> >> Cc: linux-amlo...@lists.infradead.org
> >> Cc: linux-arm-ker...@lists.infradead.org
> >> Signed-off-by: Sean Paul 
> >> ---
> >>  Documentation/gpu/meson.rst | 6 --
> >>  1 file changed, 6 deletions(-)
> >>
> >> diff --git a/Documentation/gpu/meson.rst b/Documentation/gpu/meson.rst
> >> index 479f6f51a13b..b9e2f9aa3bd8 100644
> >> --- a/Documentation/gpu/meson.rst
> >> +++ b/Documentation/gpu/meson.rst
> >> @@ -42,12 +42,6 @@ Video Encoder
> >>  .. kernel-doc:: drivers/gpu/drm/meson/meson_venc.c
> >> :doc: Video Encoder
> >>  
> >> -Video Canvas Management
> >> -===
> >> -
> >> -.. kernel-doc:: drivers/gpu/drm/meson/meson_canvas.c
> >> -   :doc: Canvas
> >> -
> >>  Video Clocks
> >>  
> >>  
> >>
> > 
> > Acked-by: Neil Armstrong 
> > 
> 
> Applied to drm-misc-fixes

Hmm, the commit referenced in the Fixes line hasn't landed in -fixes yet, it's
in -next. So the fix has landed before the bug :(

I'll ping mripard on irc and see what he wants to do about this.

Sean

> 
> Neil

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

Re: [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

2019-04-04 Thread Bjorn Helgaas
[+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime) 
resume")]

On Fri, Mar 22, 2019 at 06:30:15AM -0500, Bjorn Helgaas wrote:
> On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote:
> > On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote:
> > > On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote:
> > > > On Thu, 2019-02-14 at 18:43 -0600, Bjorn Helgaas wrote:
> > > > > On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude Paul wrote:
> > > > > > On a very specific subset of ThinkPad P50 SKUs, particularly
> > > > > > ones that come with a Quadro M1000M chip instead of the M2000M
> > > > > > variant, the BIOS seems to have a very nasty habit of not
> > > > > > always resetting the secondary Nvidia GPU between full reboots
> > > > > > if the laptop is configured in Hybrid Graphics mode. The
> > > > > > reason for this happening is unknown, but the following steps
> > > > > > and possibly a good bit of patience will reproduce the issue:
> > > > > > 
> > > > > > 1. Boot up the laptop normally in Hybrid graphics mode
> > > > > > 2. Make sure nouveau is loaded and that the GPU is awake
> > > > > > 2. Allow the nvidia GPU to runtime suspend itself after being idle
> > > > > > 3. Reboot the machine, the more sudden the better (e.g sysrq-b may 
> > > > > > help)
> > > > > > 4. If nouveau loads up properly, reboot the machine again and go 
> > > > > > back to
> > > > > > step 2 until you reproduce the issue
> > > > > > 
> > > > > > This results in some very strange behavior: the GPU will quite
> > > > > > literally be left in exactly the same state it was in when the
> > > > > > previously booted kernel started the reboot. This has all
> > > > > > sorts of bad sideaffects: for starters, this completely breaks
> > > > > > nouveau starting with a mysterious EVO channel failure that
> > > > > > happens well before we've actually used the EVO channel for
> > > > > > anything:
> > 
> > Thanks for the hybrid tutorial (snipped from this response).  IIUC,
> > what you said was that in hybrid mode, the Intel GPU drives the
> > built-in display and the Nvidia GPU drives any external displays and
> > may be used for DRI PRIME rendering (whatever that is).  But since you
> > say the Nvidia device gets runtime suspended, I assume there's no
> > external display here and you're not using DRI PRIME.
> > 
> > I wonder if it's related to the fact that the Nvidia GPU has been
> > runtime suspended before you do the reboot.  Can you try turning of
> > runtime power management for the GPU by setting the runpm module
> > parameter to 0?  I *think* this would be booting with
> > "nouveau.runpm=0".
> 
> Sorry, I wasn't really thinking here.  You already *said* this is
> related to runtime suspend.  It only happens when the Nvidia GPU has
> been suspended.
> 
> I don't know that much about suspend, but ISTR seeing comments about
> resuming devices before we shutdown.  If we do that, maybe there's
> some kind of race between that resume and the reboot?

I think we do in fact resume PCI devices before shutdown.  Here's the
path I'm looking at:

  device_shutdown
pm_runtime_get_noresume
pm_runtime_barrier
dev->bus->shutdown
  pci_device_shutdown
pm_runtime_resume
  __pm_runtime_resume(dev, 0)
rpm_resume(dev, 0)
  __update_runtime_status(dev, RPM_RESUMING)
  callback = RPM_GET_CALLBACK(dev, runtime_resume)
  rpm_callback(callback, dev)
__rpm_callback
  pci_pm_runtime_resume
drv->pm->runtime_resume
  nouveau_pmops_runtime_resume
nouveau_do_resume
schedule_work(hpd_work)   # <---
...
nouveau_display_hpd_work
  pm_runtime_get_sync
  drm_helper_hpd_irq_event
  pm_runtime_mark_last_busy
  pm_runtime_put_sync

I'm curious about that "schedule_work(hpd_work)" near the end because
no other drivers seem to use schedule_work() in the runtime_resume
path, and I don't know how that synchronizes with the shutdown
process.  I don't see anything that waits for
nouveau_display_hpd_work() to complete, so it seems like something
that could be a race.

I wonder this problem would be easier to reproduce if you added a
sleep in nouveau_display_hpd_work() as in the first hunk below, and I
wonder if the problem would then go away if you stopped scheduling
hpd_work as in the second hunk?  Obviously the second hunk isn't a
solution, it's just an attempt to figure out if I'm looking in the
right area.

Bjorn


diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 55c0fa451163..e50806012d41 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -350,6 +350,7 @@ nouveau_display_hpd_work(struct 

[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109206

--- Comment #28 from Talha Khan  ---
I'm not sure if I want to delete raven_dcmu.bin on my system, would renaming it
or moving it have the same effect? I have the same system as JerryD and am
running Fedora 29 KDE.

-- 
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/bridge: ti-tfp410: Fall back to HPD polling if HPD irq is not available

2019-04-04 Thread Laurent Pinchart
Hi Peter,

On Tue, Apr 02, 2019 at 04:10:41PM +0300, Peter Ujfalusi wrote:
> On 02/04/2019 14.21, Laurent Pinchart wrote:
> > On Mon, Apr 01, 2019 at 03:33:42PM +0300, Peter Ujfalusi wrote:
> >> In case either the HPD gpio is not specified or when the HPD gpio can not
> >> be used as interrupt we should tell the core that the HPD needs to be
> >> polled for detecting hotplug.
> >>
> >> Signed-off-by: Peter Ujfalusi 
> >> ---
> >>  drivers/gpu/drm/bridge/ti-tfp410.c | 14 +++---
> >>  1 file changed, 11 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
> >> b/drivers/gpu/drm/bridge/ti-tfp410.c
> >> index 285be4a0f4bd..6fc831eb3804 100644
> >> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> >> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> >> @@ -31,6 +31,7 @@ struct tfp410 {
> >>  
> >>struct i2c_adapter  *ddc;
> >>struct gpio_desc*hpd;
> >> +  int hpd_irq;
> >>struct delayed_work hpd_work;
> >>struct gpio_desc*powerdown;
> >>  
> >> @@ -124,8 +125,10 @@ static int tfp410_attach(struct drm_bridge *bridge)
> >>return -ENODEV;
> >>}
> >>  
> >> -  if (dvi->hpd)
> >> +  if (dvi->hpd_irq >= 0)
> > 
> > Do you need a new hpd_irq field ? Can't you just test dvi->hpd as done
> > today, simply adding the else clause to this if ?
> 
> We can have hpd GPIO, but the GPIO might not be usable for interrupt.

Ah, good point. I hadn't understood that from the commit message. Maybe
an additional sentence pointing out that not all GPIOs can be used as
IRQs would be useful.

Reviewed-by: Laurent Pinchart 

> >>dvi->connector.polled = DRM_CONNECTOR_POLL_HPD;
> >> +  else
> >> +  dvi->connector.polled = DRM_CONNECTOR_POLL_CONNECT | 
> >> DRM_CONNECTOR_POLL_DISCONNECT;
> >>  
> >>drm_connector_helper_add(>connector,
> >> _con_helper_funcs);
> >> @@ -324,10 +327,15 @@ static int tfp410_init(struct device *dev, bool i2c)
> >>return PTR_ERR(dvi->powerdown);
> >>}
> >>  
> >> -  if (dvi->hpd) {
> >> +  if (dvi->hpd)
> >> +  dvi->hpd_irq = gpiod_to_irq(dvi->hpd);
> >> +  else
> >> +  dvi->hpd_irq = -ENXIO;
> >> +
> >> +  if (dvi->hpd_irq >= 0) {
> >>INIT_DELAYED_WORK(>hpd_work, tfp410_hpd_work_func);
> >>  
> >> -  ret = devm_request_threaded_irq(dev, gpiod_to_irq(dvi->hpd),
> >> +  ret = devm_request_threaded_irq(dev, dvi->hpd_irq,
> >>NULL, tfp410_hpd_irq_thread, IRQF_TRIGGER_RISING |
> >>IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> >>"hdmi-hpd", dvi);

-- 
Regards,

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

Re: [PATCH] drm/nouveau: Remove duplicate ACPI_VIDEO_NOTIFY_PROBE definition

2019-04-04 Thread Hans de Goede

Hi,

On 04-04-19 15:49, Bjorn Helgaas wrote:

From: Bjorn Helgaas 

Commit 3a6536c51d5d ("drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE")
added a definition of ACPI_VIDEO_NOTIFY_PROBE because  didn't
supply one.  Later, commit eff4a751cce5 ("ACPI / video: Move
ACPI_VIDEO_NOTIFY_* defines to acpi/video.h") moved ACPI_VIDEO_NOTIFY_PROBE
and other definitions to , so the copy in nouveau_display.c
is now unnecessary.

Remove the unnecessary definition from nouveau_display.c.

Signed-off-by: Bjorn Helgaas 
CC: Hans de Goede 


Thank you for cleaning this up:

Acked-by: Hans de Goede 

Regards,

Hans




---
  drivers/gpu/drm/nouveau/nouveau_display.c | 9 -
  1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 55c0fa451163..832da8e0020d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -358,15 +358,6 @@ nouveau_display_hpd_work(struct work_struct *work)
  
  #ifdef CONFIG_ACPI
  
-/*

- * Hans de Goede: This define belongs in acpi/video.h, I've submitted a patch
- * to the acpi subsys to move it there from drivers/acpi/acpi_video.c .
- * This should be dropped once that is merged.
- */
-#ifndef ACPI_VIDEO_NOTIFY_PROBE
-#define ACPI_VIDEO_NOTIFY_PROBE0x81
-#endif
-
  static int
  nouveau_display_acpi_ntfy(struct notifier_block *nb, unsigned long val,
  void *data)


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

[PATCH] drm/nouveau: Remove duplicate ACPI_VIDEO_NOTIFY_PROBE definition

2019-04-04 Thread Bjorn Helgaas
From: Bjorn Helgaas 

Commit 3a6536c51d5d ("drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE")
added a definition of ACPI_VIDEO_NOTIFY_PROBE because  didn't
supply one.  Later, commit eff4a751cce5 ("ACPI / video: Move
ACPI_VIDEO_NOTIFY_* defines to acpi/video.h") moved ACPI_VIDEO_NOTIFY_PROBE
and other definitions to , so the copy in nouveau_display.c
is now unnecessary.

Remove the unnecessary definition from nouveau_display.c.

Signed-off-by: Bjorn Helgaas 
CC: Hans de Goede 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 55c0fa451163..832da8e0020d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -358,15 +358,6 @@ nouveau_display_hpd_work(struct work_struct *work)
 
 #ifdef CONFIG_ACPI
 
-/*
- * Hans de Goede: This define belongs in acpi/video.h, I've submitted a patch
- * to the acpi subsys to move it there from drivers/acpi/acpi_video.c .
- * This should be dropped once that is merged.
- */
-#ifndef ACPI_VIDEO_NOTIFY_PROBE
-#define ACPI_VIDEO_NOTIFY_PROBE0x81
-#endif
-
 static int
 nouveau_display_acpi_ntfy(struct notifier_block *nb, unsigned long val,
  void *data)
-- 
2.21.0.392.gf8f6787159e-goog

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

[Bug 110199] [amdgpu] Screen flickering when using a 75Hz monitor paired with an RX 480 GPU

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110199

--- Comment #8 from IvvanVG  ---
Also affects RX580. I think that the bug applies to 400, 500 series of graphics
cards

-- 
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 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102646

--- Comment #76 from IvvanVG  ---
problem because of this commit
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.18.y=d9ef158adf04b81772a7e9d682a054614ebac2fd
discussion on Ubuntu was here
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1813701
Also affects RX580. I think that the bug applies to 400, 500 series of graphics
cards

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix context IDs not released on driver hot unbind

2019-04-04 Thread Jani Nikula
On Thu, 04 Apr 2019, Chris Wilson  wrote:
> Quoting Janusz Krzysztofik (2019-04-04 11:50:14)
>> On Thu, 2019-04-04 at 11:43 +0100, Chris Wilson wrote:
>> > Quoting Janusz Krzysztofik (2019-04-04 11:40:24)
>> > > On Thu, 2019-04-04 at 11:28 +0100, Chris Wilson wrote:
>> > > > Quoting Janusz Krzysztofik (2019-04-04 11:24:45)
>> > > > > From: Janusz Krzysztofik 
>> > > > > 
>> > > > > In case the driver gets unbound while a device is open, kernel
>> > > > > panic
>> > > > > may be forced if a list of allocated context IDs is not empty.
>> > > > > 
>> > > > > When a device is open, the list may happen to be not empty
>> > > > > because
>> > > > > a
>> > > > > context ID, once allocated by a context ID allocator to a
>> > > > > context
>> > > > > assosiated with that open file descriptor, is released as late
>> > > > > as
>> > > > > on device close.
>> > > > > 
>> > > > > On the other hand, there is a need to release all allocated
>> > > > > context
>> > > > > IDs
>> > > > > and destroy the context ID allocator on driver unbind, even if
>> > > > > a
>> > > > > device
>> > > > > is open, in order to free memory resources consumed and prevent
>> > > > > from
>> > > > > memory leaks.  The purpose of the forced kernel panic was to
>> > > > > protect
>> > > > > the context ID allocator from being silently destroyed if not
>> > > > > all
>> > > > > allocated IDs had been released.
>> > > > 
>> > > > Those open fd are still pointing into kernel memory where the
>> > > > driver
>> > > > used to be. The panic is entirely correct, we should not be
>> > > > unloading
>> > > > the module before those dangling pointers have been made safe.
>> > > > 
>> > > > This is papering over the symptom. How is the module being
>> > > > unloaded
>> > > > with
>> > > > open fd? 
>> > > 
>> > > A user can play with the driver unbind or device remove sysfs
>> > > interface.
>> > 
>> > Sure, but we must still follow all the steps before _unloading_ the
>> > module or else the user is left pointing into reused kernel memory.
>> 
>> I'm not talking about unloading the module, that is prevented by open
>> fds.  The driver still exists after being unbound from a device and may
>> just respond with -ENODEV.
>
> i915_gem_contexts_fini() *is* module unload.

Janusz, please describe what you're doing exactly.

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

[Bug 110199] [amdgpu] Screen flickering when using a 75Hz monitor paired with an RX 480 GPU

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110199

--- Comment #7 from IvvanVG  ---
problem because of this commit
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.18.y=d9ef158adf04b81772a7e9d682a054614ebac2fd
discussion on Ubuntu was here
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1813701

-- 
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 6/7] drm: rcar-du: fix possible object reference leak

2019-04-04 Thread Laurent Pinchart
Hi Wen,

Thank you for the patch.

On Thu, Apr 04, 2019 at 12:04:14AM +0800, Wen Yang wrote:
> The call to of_get_parent returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
> 
> Detected by coccinelle with the following warnings:
> drivers/gpu/drm/rcar-du/rcar_du_of.c:235:2-8: ERROR: missing of_node_put; 
> acquired a node pointer with refcount incremented on line 216, but without a 
> corresponding object release within this function.
> drivers/gpu/drm/rcar-du/rcar_du_of.c:236:2-8: ERROR: missing of_node_put; 
> acquired a node pointer with refcount incremented on line 209, but without a 
> corresponding object release within this function.
> 
> Signed-off-by: Wen Yang 
> Cc: Laurent Pinchart 
> Cc: Kieran Bingham 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org (open list)
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_of.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> index afef696..30bceca 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_of.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> @@ -232,6 +232,8 @@ static void __init rcar_du_of_lvds_patch(const struct 
> of_device_id *of_ids)
>   lvds_node = of_find_compatible_node(NULL, NULL, compatible);
>   if (lvds_node) {
>   of_node_put(lvds_node);
> + of_node_put(soc_node);
> + of_node_put(du_node);
>   return;

Wouldn't it be simpler to just turn the return into a goto done ?

>   }
>  

-- 
Regards,

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

Re: [PATCH 4/7] drm/omap: fix possible object reference leak

2019-04-04 Thread Laurent Pinchart
Hello Wen,

Thank you for the patch.

On Thu, Apr 04, 2019 at 12:04:12AM +0800, Wen Yang wrote:
> The call to of_find_matching_node returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
> 
> Detected by coccinelle with the following warnings:
> drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing 
> of_node_put; acquired a node pointer with refcount incremented on line 209, 
> but without a corresponding object release within this function.
> drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing 
> of_node_put; acquired a node pointer with refcount incremented on line 209, 
> but without a corresponding object release within this function.
> 
> Signed-off-by: Wen Yang 
> Cc: Tomi Valkeinen 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sebastian Reichel 
> Cc: Laurent Pinchart 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org

Reviewed-by: Laurent Pinchart 

Would you like to get the series merged in one go, or individual patches
picked by the respective maintainer ?

> ---
>  drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c 
> b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
> index 2b41c75..60067e8 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
> @@ -208,8 +208,10 @@ static int __init omapdss_boot_init(void)
>  
>   dss = of_find_matching_node(NULL, omapdss_of_match);
>  
> - if (dss == NULL || !of_device_is_available(dss))
> + if (dss == NULL || !of_device_is_available(dss)) {
> + of_node_put(dss);
>   return 0;
> + }
>  
>   omapdss_walk_device(dss, true);
>  
> @@ -234,6 +236,7 @@ static int __init omapdss_boot_init(void)
>   kfree(n);
>   }
>  
> + of_node_put(dss);
>   return 0;
>  }
>  

-- 
Regards,

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

Re: [radeon-alex:drm-next-5.2-wip 21/42] drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:756:32: error: 'HMM_PFN_VALID' undeclared; did you mean '_PAGE_VALID'?

2019-04-04 Thread Deucher, Alexander
The fixes are there; they are the subsequent commits, I guess I can squash them 
in.

Alex

From: Kuehling, Felix
Sent: Wednesday, April 3, 2019 6:20 PM
To: Yang, Philip; Deucher, Alexander
Cc: dri-devel@lists.freedesktop.org; Koenig, Christian
Subject: Re: [radeon-alex:drm-next-5.2-wip 21/42] 
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:756:32: error: 'HMM_PFN_VALID' 
undeclared; did you mean '_PAGE_VALID'?

[dropping the robot]

I think Philip fixed those issues on amd-staging-drm-next. Either some
fixes are missing on drm-next-5.2-wip, or they are there but should be
squashed to avoid hitting these errors on intermediate builds.

Regards,
   Felix

On 2019-04-03 2:26 p.m., kbuild test robot wrote:
> tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
> head:   5666aea3ea494d4dd96df8f092cab32dbeeac321
> commit: 95db8d6001df8966e3370a66c9f358925fbcc890 [21/42] drm/amdgpu: replace 
> get_user_pages with HMM mirror helpers
> config: mips-allyesconfig (attached as .config)
> compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
>  wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
>  chmod +x ~/bin/make.cross
>  git checkout 95db8d6001df8966e3370a66c9f358925fbcc890
>  # save the attached .config to linux build tree
>  GCC_VERSION=7.2.0 make.cross ARCH=mips
>
> Note: the radeon-alex/drm-next-5.2-wip HEAD 
> 5666aea3ea494d4dd96df8f092cab32dbeeac321 builds fine.
>It only hurts bisectibility.
>
> All errors (new ones prefixed by >>):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:713:19: error: field 'range' has 
> incomplete type
>   struct hmm_range range;
>^
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: In function 
> 'amdgpu_ttm_tt_get_user_pages':
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:738:7: error: dereferencing 
> pointer to incomplete type 'struct hmm_range'
>   range->vma = find_vma(mm, gtt->userptr);
>^~
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:756:32: error: 'HMM_PFN_VALID' 
>>> undeclared (first use in this function); did you mean '_PAGE_VALID'?
>   range->pfns[0] = range->flags[HMM_PFN_VALID];
> ^
> _PAGE_VALID
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:756:32: note: each undeclared 
> identifier is reported only once for each function it appears in
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:758:22: error: 'HMM_PFN_WRITE' 
> undeclared (first use in this function); did you mean 'HMM_PFN_VALID'?
>  0 : range->flags[HMM_PFN_WRITE];
>   ^
>   HMM_PFN_VALID
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:763:6: error: implicit 
> declaration of function 'hmm_vma_fault'; did you mean 'hmm_mm_init'? 
> [-Werror=implicit-function-declaration]
>   r = hmm_vma_fault(range, true);
>   ^
>   hmm_mm_init
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:770:14: error: implicit 
> declaration of function 'hmm_pfn_to_page'; did you mean '__pfn_to_page'? 
> [-Werror=implicit-function-declaration]
>pages[i] = hmm_pfn_to_page(range, range->pfns[i]);
>   ^~~
>   __pfn_to_page
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: In function 
> 'amdgpu_ttm_tt_get_user_pages_done':
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:798:7: error: implicit 
> declaration of function 'hmm_vma_range_done'; did you mean 
> 'drm_vma_node_size'? [-Werror=implicit-function-declaration]
>r = hmm_vma_range_done(>range);
>^~
>drm_vma_node_size
> cc1: some warnings being treated as errors
>
> vim +756 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>
> 703
> 704   /*
> 705* TTM backend functions.
> 706*/
> 707   struct amdgpu_ttm_tt {
> 708   struct ttm_dma_tt   ttm;
> 709   u64 offset;
> 710   uint64_tuserptr;
> 711   struct task_struct  *usertask;
> 712   uint32_tuserflags;
>   > 713   struct hmm_rangerange;
> 714   };
> 715
> 716   /**
> 717* amdgpu_ttm_tt_get_user_pages - get device accessible pages 
> that back user
> 718* memory and start HMM tracking CPU page table update
> 719*
> 720* Calling function must call 
> amdgpu_ttm_tt_userptr_range_done() once and only
> 721* once afterwards to stop HMM tracking
> 722*/
> 723   int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct 
> page **pages)
> 724   {
> 725   struct amdgpu_ttm_tt *gtt = (void *)ttm;
> 726   struct mm_struct *mm = 

[Bug 110324] like is not working

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110324

anshu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|dri-devel@lists.freedesktop |indive...@gmail.com
   |.org|
 QA Contact|dri-devel@lists.freedesktop |anshujain...@gmail.com
   |.org|

-- 
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 110324] like is not working

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110324

Bug ID: 110324
   Summary: like is not working
   Product: Mesa
   Version: 5.1
  Hardware: Other
OS: All
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/DRI/R100
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: anshujain...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

www.xyz.com open 
login page 
and like feature is not working

-- 
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 v4 4/4] drm/vc4: Allocate binner bo when starting to use the V3D

2019-04-04 Thread Paul Kocialkowski
Hi,

Le mercredi 03 avril 2019 à 11:53 -0700, Eric Anholt a écrit :
> Paul Kocialkowski  writes:
> 
> > The binner bo is not required until the V3D is in use, so avoid
> > allocating it at probe and do it on the first non-dumb BO allocation.
> > Keep track of which clients are using the V3D and liberate the buffer
> > when there is none left.
> > 
> > We also want to keep it alive during runtime suspend/resume to avoid
> > failing to allocate it at resume. This happens when the CMA pool is
> > full at that point and results in a hard crash.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/gpu/drm/vc4/vc4_bo.c  | 32 
> >  drivers/gpu/drm/vc4/vc4_drv.c |  9 +
> >  drivers/gpu/drm/vc4/vc4_drv.h |  4 
> >  drivers/gpu/drm/vc4/vc4_v3d.c | 13 -
> >  4 files changed, 45 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> > index 88ebd681d7eb..b941f09b9378 100644
> > --- a/drivers/gpu/drm/vc4/vc4_bo.c
> > +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> > @@ -799,6 +799,30 @@ vc4_prime_import_sg_table(struct drm_device *dev,
> > return obj;
> >  }
> >  
> > +static int vc4_prepare_bin_bo(struct drm_device *dev,
> > + struct drm_file *file_priv)
> > +{
> > +   struct vc4_file *vc4file = file_priv->driver_priv;
> > +   struct vc4_dev *vc4 = to_vc4_dev(dev);
> > +   int ret;
> > +
> > +   if (!vc4->v3d)
> > +   return -ENODEV;
> > +
> > +   if (!vc4file->needs_bin_bo) {
> > +   atomic_inc(>bin_bo_usecnt);
> > +   vc4file->needs_bin_bo = true;
> > +   }
> > +
> > +   if (!vc4->bin_bo) {
> > +   ret = vc4_v3d_allocate_bin_bo(vc4);
> > +   if (ret)
> > +   return ret;
> > +   }
> > +
> 
> This atomic usage looks really racy.  For example, multiple clients
> could call allocate at the same time and leak one.  Or this timeline:
> 
> us   them
>  dec count to 0
> inc count
> check bin_bo
>  free bin_bo

Oh, you're definitely right. Sorry I missed that.

> vc4_v3d_allocate_bin_bo should probably be a vc4_v3d_bin_bo_get()
> returning a kref on the BO, called under a lock protecting both one
> file_priv being dereferenced by multiple threads in the kernel at the
> same time (so file_priv doesn't try to double-get its ref) and multiple
> file_privs trying to get the bin_bo at once.

Sounds good, I'll look into it and spin up a new revision soon.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

[Bug 110320] Improve igt_assert for timing checks

2019-04-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110320

Bug ID: 110320
   Summary: Improve igt_assert for timing checks
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: enhancement
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: dan...@ffwll.ch

We have a lot of timing checks to make sure something happened in a desired
intervall, especially around vblank/flip timestamps. Debugging those is really
hard, best option to get started is to dump the ftrace flight recorder of what
happened (likely shedding some lights on where we stalled).

Could be useful to roll that into an igt_assert_timing macro to do
automatically on assert failures.

-- 
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/cirrus: rewrite and modernize driver.

2019-04-04 Thread Gerd Hoffmann
  Hi,

> So I guess I have to add a dest_clip bool parameter when moving them.
> /me looks for a good place.  drm_fb_helpers.c I think.

https://git.kraxel.org/cgit/linux/log/?h=drm-rewrite-cirrus updated.

v2 series will follow later today or tomorrow.

cheers,
  Gerd

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

  1   2   >