date:20180222


On 02/23/2018 02:25 AM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
  
  static int __init xen_drv_init(void)

  {
+   /* At the moment we only support case with XEN_PAGE_SIZE == PAGE_SIZE */
+   BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);


Why BUILD_BUG_ON? This should simply not load if page sizes are different.

  

This is a compile time check, so if kernel/Xen is configured
to use page size combination which is not supported by the
driver it will fail during compilation. This seems correct to me,
because you shouldn't even try to load the driver which
cannot handle different page sizes to not make any harm.





+   ret = gnttab_map_refs(map_ops, NULL, buf->pages, buf->num_pages);
+   BUG_ON(ret);


We should try not to BUG*(). There are a few in this patch (and possibly
others) that I think can be avoided.


I will rework BUG_* for map/unmap code to handle errors,
but will still leave
    /* either pages or sgt, not both */
    BUG_ON(cfg->pages && cfg->sgt);
which is a real driver bug and must not happen





+
+static int alloc_storage(struct xen_drm_front_shbuf *buf)
+{
+   if (buf->sgt) {
+   buf->pages = kvmalloc_array(buf->num_pages,
+   sizeof(struct page *), GFP_KERNEL);
+   if (!buf->pages)
+   return -ENOMEM;
+
+   if (drm_prime_sg_to_page_addr_arrays(buf->sgt, buf->pages,
+   NULL, buf->num_pages) < 0)
+   return -EINVAL;
+   }
+
+   buf->grefs = kcalloc(buf->num_grefs, sizeof(*buf->grefs), GFP_KERNEL);
+   if (!buf->grefs)
+   return -ENOMEM;
+
+   buf->directory = kcalloc(get_num_pages_dir(buf), PAGE_SIZE, GFP_KERNEL);
+   if (!buf->directory)
+   return -ENOMEM;

You need to clean up on errors.

this is called in xen_drm_front_shbuf_alloc and is properly cleaned
on failure, e.g.:
    ret = alloc_storage(buf);
    if (ret)
        goto fail;
[...]
fail:
    xen_drm_front_shbuf_free(buf);


-boris


+
+   return 0;
+}


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

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

2018-02-22 Thread Christian König


Am 22.02.2018 um 18:56 schrieb Michel Dänzer:

On 2018-02-22 06:37 PM, Ben Crocker wrote:

One of my colleagues did discover a "Radeon HG 5450 PCI" from February
2010 which did, apparently, have a Cedar GPU and very definitely had a
(plain old) PCI connector.

There must be a PCIe-to-PCI bridge on that board. The GPU itself is
always PCIe, and treated accordingly by the driver.


Ben, just an educated guess but is this one the one which is failing to 
work correctly?


Cause the PCIe bus interface is pretty much identical over all 
generations of the last decade or so. Only the newest Vega10 generation 
is a bit different.


So I strongly thing that this isn't related to the device being a Cedar 
at all, but rather that you have a bridge above it which doesn't 
correctly handle 64bit transfers.


Can you please send and "lspci -t" of both the working and the 
problematic devices?


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

[Bug 105221] kernel modeswitch fails on Fedora 27 on Evergreen (Radeon HD5850)

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

Bug ID: 105221
   Summary: kernel modeswitch fails on Fedora 27 on Evergreen
(Radeon HD5850)
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: brouh...@fedoraproject.org

With Fedora 26 I had sporadic problems with the system crashing at the first
kernel mode switch, before entering the LUKS passphrase at boot time, but I
could hit reset and usually the second time it would work. With Fedora 27 this
happens to me consistently every time. The only way I can successfully boot is
to use "nomodeset" on the kernel command line, which then causes issues for my
X session.

My system has Asus Sabertooth 990FX R2.0 motherboard, AMD FX-8350 CPU, and
Radeon HD 5850 graphics card. I'm running Fedora 27 with kernel
4.15.3-300.fc27.x86_64.

Fedora Bugzilla shows someone else having that problem with HD 5450. Maybe its
a general Evergreen problem.

https://bugzilla.redhat.com/show_bug.cgi?id=1474044

-- 
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 1/8] drm/ttm: add default implementations for ttm_tt_(un)populate

2018-02-22 Thread Christian König


Am 22.02.2018 um 16:55 schrieb Michel Dänzer:

On 2018-02-22 12:15 PM, Christian König wrote:

Use ttm_pool_populate/ttm_pool_unpopulate if the driver doesn't provide
a function.

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

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 9fd7115a013a..65bf4eac184b 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -410,7 +410,10 @@ int ttm_tt_populate(struct ttm_tt *ttm, struct 
ttm_operation_ctx *ctx)
if (ttm->state != tt_unpopulated)
return 0;
  
-	ret = ttm->bdev->driver->ttm_tt_populate(ttm, ctx);

+   if (ttm->bdev->driver->ttm_tt_populate)
+   ret = ttm->bdev->driver->ttm_tt_populate(ttm, ctx);
+   else
+   ret = ttm_pool_populate(ttm, ctx);
if (!ret)
ttm_tt_add_mapping(ttm);
return ret;
@@ -436,5 +439,8 @@ void ttm_tt_unpopulate(struct ttm_tt *ttm)
return;
  
  	ttm_tt_clear_mapping(ttm);

-   ttm->bdev->driver->ttm_tt_unpopulate(ttm);
+   if (ttm->bdev->driver->ttm_tt_unpopulate)
+   ttm->bdev->driver->ttm_tt_unpopulate(ttm);
+   else
+   ttm_pool_unpopulate(ttm);
  }


Instead of the if/else, have you considered setting
driver->ttm_tt_(un)populate = ttm_pool_(un)populate during
initialization if they're NULL?


Mhm, also an interesting possibility. But shouldn't the function 
pointers be const?


Christian.




Either way, the series is

Reviewed-by: Michel Dänzer 




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

Re: [PATCH] drm/bridge: analogix_dp: Keep PHY powered from between driver bind/unbind

2018-02-22 Thread Marek Szyprowski


Hi Laurent,

On 2018-02-21 13:49, Laurent Pinchart wrote:

Thank you for the patch.

On Wednesday, 21 February 2018 12:04:43 EET Marek Szyprowski wrote:

Patch f0a8b49c03d2 ("drm/bridge: analogix dp: Fix runtime PM state on
driver bind") fixed unbalanced call to phy_power_on() in analogix_dp_bind()
function by calling phy_power_off() at the end of bind operation.

However it turned out that having PHY powered is required for proper DRM
display pipeline initialization on Peach-Pit Chromebook2 board, as this
board freezes otherwise when PHY power off is called in bind. Fix this by
keeping PHY powered for the whole bind/unbind driver life cycle. The
freeze is probably related to the fact that the display pipeline (Exynos
FIMD CTRC -> Exynos/Analogix DP bridge -> PS8625 dp2lvds bridge -> B116XW03
panel) is already configured and enabled by the bootloader and require
reset of all components for proper shutdown.

"Probably" always makes me feel uncomfortable in such a context :-) Leaving
the PHY powered at all times isn't the best idea as it will increase power
consumption even when the DP output isn't in use. I can live with that if
there's no other way, but it feels to me like we should first get to the
bottom of the issue.


Frankly I spent some time on this and I have no other idea. Board 
freezes when
phy_power_off is called and the initial code worked properly on that 
board by

leaking phy turned on all the time.


Having PHY powered is also needed for proper EDID handling, which initially
fixed by commit 510353a63796 ("drm/bridge: analogix dp: Fix runtime PM state
in get_modes() callback").

Fixes: f0a8b49c03d2 ("drm/bridge: analogix dp: Fix runtime PM state on
driver bind")
Signed-off-by: Marek Szyprowski 
---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index
b2756bc4225a..42595863cb03 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1415,7 +1415,6 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev, goto err_disable_pm_runtime;
}

-   phy_power_off(dp->phy);
pm_runtime_put(dev);

return 0;
@@ -1448,6 +1447,7 @@ void analogix_dp_unbind(struct device *dev, struct
device *master,

drm_dp_aux_unregister(>aux);
pm_runtime_disable(dev);
+   phy_power_off(dp->phy);
clk_disable_unprepare(dp->clock);
  }
  EXPORT_SYMBOL_GPL(analogix_dp_unbind);


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

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

Re: [PATCH] drm/ttm: check if free mem space is under the lower limit

2018-02-22 Thread Christian König


Am 23.02.2018 um 03:18 schrieb He, Roger:


-Original Message-
From: Koenig, Christian
Sent: Thursday, February 22, 2018 8:54 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: check if free mem space is under the lower limit

Am 22.02.2018 um 12:43 schrieb He, Roger:

-Original Message-
From: Koenig, Christian
Sent: Thursday, February 22, 2018 7:28 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: check if free mem space is under the
lower limit

Am 22.02.2018 um 11:10 schrieb Roger He:

the free mem space and the lower limit both include two parts:
system memory and swap space.

For the OOM triggered by TTM, that is the case as below:
first swap space is full of swapped out pages and soon system memory
also is filled up with ttm pages. and then any memory allocation
request will run into OOM.

to cover two cases:
a. if no swap disk at all or free swap space is under swap mem
  limit but available system mem is bigger than sys mem limit,
  allow TTM allocation;

b. if the available system mem is less than sys mem limit but
  free swap space is bigger than swap mem limit, allow TTM
  allocation.

v2: merge two memory limit(swap and system) into one
v3: keep original behavior except ttm_opt_ctx->flags with
   TTM_OPT_FLAG_FORCE_ALLOC
v4: always set force_alloc as tx->flags & TTM_OPT_FLAG_FORCE_ALLOC
v5: add an attribute for lower_mem_limit

Signed-off-by: Roger He 
---
drivers/gpu/drm/ttm/ttm_memory.c | 94 

drivers/gpu/drm/ttm/ttm_page_alloc.c |  3 +
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 +
include/drm/ttm/ttm_memory.h |  5 ++
4 files changed, 105 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
b/drivers/gpu/drm/ttm/ttm_memory.c
index aa0c381..d015e39 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -36,6 +36,7 @@
#include 
#include 
#include 
+#include 

#define TTM_MEMORY_ALLOC_RETRIES 4

@@ -166,6 +167,52 @@ static struct kobj_type ttm_mem_zone_kobj_type = {

.default_attrs = ttm_mem_zone_attrs,
};

+static struct attribute ttm_mem_global_lower_mem_limit = {

+   .name = "lower_mem_limit",
+   .mode = S_IRUGO | S_IWUSR
+};
+
+static ssize_t ttm_mem_global_show(struct kobject *kobj,
+struct attribute *attr,
+char *buffer)
+{
+   struct ttm_mem_global *glob =
+   container_of(kobj, struct ttm_mem_global, kobj);
+   uint64_t val = 0;
+
+   spin_lock(>lock);
+   val = glob->lower_mem_limit;
+   spin_unlock(>lock);
+
+   return snprintf(buffer, PAGE_SIZE, "%llu\n",
+   (unsigned long long) val << 2);

What is that shift good for?

Because the unit of lower_mem_limit is 4KB, so (val << 2) can get KB for 
consistent with other parameters as below(all are showed with KB bytes.):

Ok that makes sense.


static struct attribute *ttm_mem_zone_attrs[] = {
_mem_sys,
_mem_emer,
_mem_max,
_mem_swap,
_mem_used,
NULL
};
   

+}
+
+static ssize_t ttm_mem_global_store(struct kobject *kobj,
+ struct attribute *attr,
+ const char *buffer,
+ size_t size)
+{
+   int chars;
+   uint64_t val64;
+   unsigned long val;
+   struct ttm_mem_global *glob =
+   container_of(kobj, struct ttm_mem_global, kobj);
+
+   chars = sscanf(buffer, "%lu", );
+   if (chars == 0)
+   return size;
+
+   val64 = val;
+   val64 >>= 2;

Dito?
Covert from KB to 4K page size here.


+
+   spin_lock(>lock);
+   glob->lower_mem_limit = val64;
+   spin_unlock(>lock);
+
+   return size;
+}
+
static void ttm_mem_global_kobj_release(struct kobject *kobj)
{
struct ttm_mem_global *glob =
@@ -174,8 +221,20 @@ static void ttm_mem_global_kobj_release(struct kobject 
*kobj)
kfree(glob);
}

+static struct attribute *ttm_mem_global_attrs[] = {

+   _mem_global_lower_mem_limit,
+   NULL
+};
+
+static const struct sysfs_ops ttm_mem_global_ops = {
+   .show = _mem_global_show,
+   .store = _mem_global_store,
+};
+
static struct kobj_type ttm_mem_glob_kobj_type = {
.release = _mem_global_kobj_release,
+   .sysfs_ops = _mem_global_ops,
+   .default_attrs = ttm_mem_global_attrs,
};

static bool ttm_zones_above_swap_target(struct ttm_mem_global

*glob, @@ -375,6 +434,11 @@ int ttm_mem_global_init(struct
ttm_mem_global
*glob)

	si_meminfo();

+	/* lower limit of swap space and 256MB is enough */

+   glob->lower_mem_limit = 256 << 8;
+   /* lower limit of ram and keep consistent with each

Re: [PATCH 4/9] drm/xen-front: Implement Xen event channel handling


On 02/23/2018 01:50 AM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+
+static irqreturn_t evtchnl_interrupt_ctrl(int irq, void *dev_id)
+{
+   struct xen_drm_front_evtchnl *evtchnl = dev_id;
+   struct xen_drm_front_info *front_info = evtchnl->front_info;
+   struct xendispl_resp *resp;
+   RING_IDX i, rp;
+   unsigned long flags;
+
+   spin_lock_irqsave(_info->io_lock, flags);
+
+   if (unlikely(evtchnl->state != EVTCHNL_STATE_CONNECTED))
+   goto out;

Do you need to check the state under lock? (in other routines too).

not really, will move out of the lock in interrupt handlers
other places (I assume you refer to be_stream_do_io)
it is set under lock as a part of atomic operation, e.g.
we get a new request pointer from the ring and reset completion
So, those places still seem to be ok

...


+
+static void evtchnl_free(struct xen_drm_front_info *front_info,
+   struct xen_drm_front_evtchnl *evtchnl)
+{
+   unsigned long page = 0;
+
+   if (evtchnl->type == EVTCHNL_TYPE_REQ)
+   page = (unsigned long)evtchnl->u.req.ring.sring;
+   else if (evtchnl->type == EVTCHNL_TYPE_EVT)
+   page = (unsigned long)evtchnl->u.evt.page;
+   if (!page)
+   return;
+
+   evtchnl->state = EVTCHNL_STATE_DISCONNECTED;
+
+   if (evtchnl->type == EVTCHNL_TYPE_REQ) {
+   /* release all who still waits for response if any */
+   evtchnl->u.req.resp_status = -EIO;
+   complete_all(>u.req.completion);
+   }
+
+   if (evtchnl->irq)
+   unbind_from_irqhandler(evtchnl->irq, evtchnl);
+
+   if (evtchnl->port)
+   xenbus_free_evtchn(front_info->xb_dev, evtchnl->port);
+
+   /* end access and free the page */
+   if (evtchnl->gref != GRANT_INVALID_REF)
+   gnttab_end_foreign_access(evtchnl->gref, 0, page);
+
+   if (evtchnl->type == EVTCHNL_TYPE_REQ)
+   evtchnl->u.req.ring.sring = NULL;
+   else
+   evtchnl->u.evt.page = NULL;
+
+   memset(evtchnl, 0, sizeof(*evtchnl));

Since you are zeroing out the structure you don't need to set fields to
zero.

good catch, thank you

I also think you need to free the page.

it is freed by gnttab_end_foreign_access, please see [1]

-boris


[1] 
https://elixir.bootlin.com/linux/v4.11-rc1/source/drivers/xen/grant-table.c#L380

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

Re: [PATCH 2/2] drm/panel: Add device_link from panel device to drm device

2018-02-22 Thread Lukas Wunner

On Thu, Feb 22, 2018 at 07:46:27PM +0200, Jyri Sarha wrote:
> Add device_link from panel device (supplier) to drm device (consumer)
> with DL_FLAG_AUTOREMOVE when drm_panel_attach() is called. Currently
> the master drm driver is not protected against the attached. The
> device_link with DL_FLAG_AUTOREMOVE should make sure the drm device is
> unbound before the panel driver becomes unavailable.
> 
> The device_link is removed when drm_panel_detach() is called. The
> drm_panel_detach() should be called by the panel driver it self when
> it is removed. Otherwise the both driver are racing to delete the same
> link.

Unfortunately you haven't addressed any of my comments on the previous
version of this patch:

https://www.spinics.net/lists/dri-devel/msg166320.html

Please respin with my comments addressed.  Thanks,

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

Re: [PATCH 3/9] drm/xen-front: Read driver configuration from Xen store


On 02/23/2018 01:20 AM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+
+static int cfg_connector(struct xen_drm_front_info *front_info,
+   struct xen_drm_front_cfg_connector *connector,
+   const char *path, int index)
+{
+   char *connector_path;
+
+   connector_path = devm_kasprintf(_info->xb_dev->dev,
+   GFP_KERNEL, "%s/%d", path, index);
+   if (!connector_path)
+   return -ENOMEM;
+
+   connector->xenstore_path = connector_path;
+   if (xenbus_scanf(XBT_NIL, connector_path, XENDISPL_FIELD_RESOLUTION,
+   "%d" XENDISPL_RESOLUTION_SEPARATOR "%d",
+   >width, >height) < 0) {
+   /* either no entry configured or wrong resolution set */
+   connector->width = 0;
+   connector->height = 0;

Do you also need to set connector->xenstore_path to NULL? Or maybe just
set it after xenbus_scanf() call.

Will move it down the code, after "if", thank you

-boris





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

Re: [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver


On 02/23/2018 12:23 AM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+static struct xenbus_driver xen_driver = {
+   .ids = xen_drv_ids,
+   .probe = xen_drv_probe,
+   .remove = xen_drv_remove,
+   .otherend_changed = backend_on_changed,

What does "_on_" stand for?

Well, it is somewhat like a hint that this is called "on" event,
e.g. event when the other end state has changed, backend in this
case. It could be something like "backend_on_state_changed"

-boris


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

[PATCH] drm/rockchip: vop: Init vskiplines in scl_vop_cal_scale()

2018-02-22 Thread Jeffy Chen

Currently we are calling scl_vop_cal_scale() to get vskiplines for yrgb
and cbcr. So the cbcr's vskiplines might be an unexpected value if the
second scl_vop_cal_scale() didn't update it.

Init vskiplines in scl_vop_cal_scale() to avoid that.

Signed-off-by: Jeffy Chen 
---

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 7715853ef90a..9b03c51903ab 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -259,6 +259,9 @@ static uint16_t scl_vop_cal_scale(enum scale_mode mode, 
uint32_t src,
 {
uint16_t val = 1 << SCL_FT_DEFAULT_FIXPOINT_SHIFT;
 
+   if (vskiplines)
+   *vskiplines = 0;
+
if (is_horizontal) {
if (mode == SCALE_UP)
val = GET_SCL_FT_BIC(src, dst);
@@ -299,7 +302,7 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const 
struct vop_win_data *win,
uint16_t vsu_mode;
uint16_t lb_mode;
uint32_t val;
-   int vskiplines = 0;
+   int vskiplines;
 
if (dst_w > 3840) {
DRM_DEV_ERROR(vop->dev, "Maximum dst width (3840) exceeded\n");
-- 
2.11.0


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

[Bug 100387] War Thunder game has visual errors, missing textures

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

--- Comment #22 from russianneuroman...@ya.ru ---
Looks similar: bug 105213

-- 
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 105213] [SUMO][TURKS] Alien: Isolation rendering artifacts

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

--- Comment #1 from russianneuroman...@ya.ru ---
By the way this issue looks like bug 100387, but I not sure if cause is the
same.

-- 
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/ttm: check if free mem space is under the lower limit

2018-02-22 Thread kbuild test robot

Hi Roger,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Roger-He/drm-ttm-check-if-free-mem-space-is-under-the-lower-limit/20180223-132039
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-x019-201807 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/ttm/ttm_memory.c: In function 'ttm_check_under_lowerlimit':
>> drivers/gpu//drm/ttm/ttm_memory.c:554:9: error: 'struct ttm_operation_ctx' 
>> has no member named 'flags'
 if (ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC)
^~
>> drivers/gpu//drm/ttm/ttm_memory.c:554:19: error: 'TTM_OPT_FLAG_FORCE_ALLOC' 
>> undeclared (first use in this function); did you mean 
>> 'TTM_PAGE_FLAG_ZERO_ALLOC'?
 if (ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC)
  ^~~~
  TTM_PAGE_FLAG_ZERO_ALLOC
   drivers/gpu//drm/ttm/ttm_memory.c:554:19: note: each undeclared identifier 
is reported only once for each function it appears in

vim +554 drivers/gpu//drm/ttm/ttm_memory.c

   535  
   536  /*
   537   * check if the available mem is under lower memory limit
   538   *
   539   * a. if no swap disk at all or free swap space is under swap_mem_limit
   540   * but available system mem is bigger than sys_mem_limit, allow TTM
   541   * allocation;
   542   *
   543   * b. if the available system mem is less than sys_mem_limit but free
   544   * swap disk is bigger than swap_mem_limit, allow TTM allocation.
   545   */
   546  bool
   547  ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
   548  uint64_t num_pages,
   549  struct ttm_operation_ctx *ctx)
   550  {
   551  bool ret = false;
   552  int64_t available;
   553  
 > 554  if (ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC)
   555  return false;
   556  
   557  available = get_nr_swap_pages() + si_mem_available();
   558  available -= num_pages;
   559  if (available < glob->lower_mem_limit)
   560  ret = true;
   561  
   562  return ret;
   563  }
   564  EXPORT_SYMBOL(ttm_check_under_lowerlimit);
   565  

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


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

[Bug 105200] [r600g] Regression: ImageMagick OpenCL kernel no longer compiles

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

--- Comment #4 from nixscrip...@gmail.com ---
Thanks to your quick response, I got libclc compiled successfully.

Now when I try to view an image, the OpenCL compile error is different:

:0:0: in function ResizeHorizontalFilter void (float addrspace(1)*,
i32, i32, i32, float addrspace(1)*, i32, i32, float, i32, i32, float
addrspace(1)*, float, float, float, float, float addrspace(3)*, i32, i32, i32,
<4 x float> addrspace(3)*, float addrspace(3)*, float addrspace(3)*):
unsupported call to function applyResizeFilter

I'd call that progress, certainly.

applyResizeFilter is on line 78 of the kernel, and ResizeHorizontalFilter is on
line 81.

-- 
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

[pull] radeon and amdgpu drm-fixes-4.16

Hi Dave,

A few fixes for 4.16:
- Powerplay fixes for cards with no displays attached
- Couple of DC fixes
- radeon workaround for PPC64

The following changes since commit bfad2d08e540b18cfd92694fbb388e7d202df31f:

  Merge branch 'linux-4.16' of git://github.com/skeggsb/linux into drm-fixes 
(2018-02-16 14:26:01 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.16

for you to fetch changes up to 2c83029cda55a5e7665c7c6326909427d6a01350:

  drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE (2018-02-22 
23:35:54 -0500)


Alex Deucher (3):
  drm/amd/powerplay/vega10: allow mclk switching with no displays
  drm/amd/powerplay/smu7: allow mclk switching with no displays
  Revert "drm/radeon/pm: autoswitch power state when in balanced mode"

Ben Crocker (1):
  drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

Hersen Wu (1):
  drm/amd/display: VGA black screen from s3 when attached to hook

Mikita Lipski (2):
  drm/amdgpu: Add a missing lock for drm_mm_takedown
  drm/amdgpu: Unify the dm resume calls into one

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  9 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c|  2 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  4 +++-
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   |  2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 11 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 11 +++
 drivers/gpu/drm/radeon/radeon_device.c |  4 
 drivers/gpu/drm/radeon/radeon_pm.c |  6 +-
 8 files changed, 24 insertions(+), 25 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/1] radeon and amdgpu drm-fixes-4.16

Hi Dave,

A few fixes for 4.16:
- Powerplay fixes for cards with no displays attached
- Couple of DC fixes
- radeon workaround for PPC64

The following changes since commit bfad2d08e540b18cfd92694fbb388e7d202df31f:

  Merge branch 'linux-4.16' of git://github.com/skeggsb/linux into drm-fixes 
(2018-02-16 14:26:01 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.16

for you to fetch changes up to 2c83029cda55a5e7665c7c6326909427d6a01350:

  drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE (2018-02-22 
23:35:54 -0500)


Alex Deucher (3):
  drm/amd/powerplay/vega10: allow mclk switching with no displays
  drm/amd/powerplay/smu7: allow mclk switching with no displays
  Revert "drm/radeon/pm: autoswitch power state when in balanced mode"

Ben Crocker (1):
  drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

Hersen Wu (1):
  drm/amd/display: VGA black screen from s3 when attached to hook

Mikita Lipski (2):
  drm/amdgpu: Add a missing lock for drm_mm_takedown
  drm/amdgpu: Unify the dm resume calls into one

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  9 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c|  2 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  4 +++-
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   |  2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 11 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 11 +++
 drivers/gpu/drm/radeon/radeon_device.c |  4 
 drivers/gpu/drm/radeon/radeon_pm.c |  6 +-
 8 files changed, 24 insertions(+), 25 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

On Thu, Feb 22, 2018 at 5:52 PM, Ben Crocker  wrote:
> In radeon_device_init, set the need_dma32 flag for Cedar chips
> (e.g. FirePro 2270).  This fixes, or at least works around, a bug
> on PowerPC exposed by last year's commits
>
> 8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)
>
> and
>
> 253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)
>
> which enabled the 64-bit DMA iommu bypass.
>
> This caused the device to freeze, in some cases unrecoverably, and is
> the subject of several bug reports internal to Red Hat.
>
> Signed-off-by: Ben Crocker 

Applied. thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_device.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index ffc10cadcf34..32b577c776b9 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1397,6 +1397,10 @@ int radeon_device_init(struct radeon_device *rdev,
> if ((rdev->flags & RADEON_IS_PCI) &&
> (rdev->family <= CHIP_RS740))
> rdev->need_dma32 = true;
> +#ifdef CONFIG_PPC64
> +   if (rdev->family == CHIP_CEDAR)
> +   rdev->need_dma32 = true;
> +#endif
>
> dma_bits = rdev->need_dma32 ? 32 : 40;
> r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
> --
> 2.13.6
>
> ___
> 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/ttm: check if free mem space is under the lower limit



-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com] 
Sent: Thursday, February 22, 2018 10:06 PM
To: He, Roger 
Cc: Koenig, Christian ; 
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: check if free mem space is under the lower limit

On Thu, Feb 22, 2018 at 6:43 AM, He, Roger  wrote:
>
>
> -Original Message-
> From: Koenig, Christian
> Sent: Thursday, February 22, 2018 7:28 PM
> To: He, Roger ; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH] drm/ttm: check if free mem space is under the 
> lower limit
>
> Am 22.02.2018 um 11:10 schrieb Roger He:
>> the free mem space and the lower limit both include two parts:
>> system memory and swap space.
>>
>> For the OOM triggered by TTM, that is the case as below:
>> first swap space is full of swapped out pages and soon system memory 
>> also is filled up with ttm pages. and then any memory allocation 
>> request will run into OOM.
>>
>> to cover two cases:
>> a. if no swap disk at all or free swap space is under swap mem
>> limit but available system mem is bigger than sys mem limit,
>> allow TTM allocation;
>>
>> b. if the available system mem is less than sys mem limit but
>> free swap space is bigger than swap mem limit, allow TTM
>> allocation.
>>
>> v2: merge two memory limit(swap and system) into one
>> v3: keep original behavior except ttm_opt_ctx->flags with
>>  TTM_OPT_FLAG_FORCE_ALLOC
>> v4: always set force_alloc as tx->flags & TTM_OPT_FLAG_FORCE_ALLOC
>> v5: add an attribute for lower_mem_limit
>>
>> Signed-off-by: Roger He 
>> ---
>>   drivers/gpu/drm/ttm/ttm_memory.c | 94 
>> 
>>   drivers/gpu/drm/ttm/ttm_page_alloc.c |  3 +
>>   drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 +
>>   include/drm/ttm/ttm_memory.h |  5 ++
>>   4 files changed, 105 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
>> b/drivers/gpu/drm/ttm/ttm_memory.c
>> index aa0c381..d015e39 100644
>> --- a/drivers/gpu/drm/ttm/ttm_memory.c
>> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
>> @@ -36,6 +36,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>
>>   #define TTM_MEMORY_ALLOC_RETRIES 4
>>
>> @@ -166,6 +167,52 @@ static struct kobj_type ttm_mem_zone_kobj_type = {
>>   .default_attrs = ttm_mem_zone_attrs,
>>   };
>>
>> +static struct attribute ttm_mem_global_lower_mem_limit = {
>> + .name = "lower_mem_limit",
>> + .mode = S_IRUGO | S_IWUSR
>> +};
>> +
>> +static ssize_t ttm_mem_global_show(struct kobject *kobj,
>> +  struct attribute *attr,
>> +  char *buffer) {
>> + struct ttm_mem_global *glob =
>> + container_of(kobj, struct ttm_mem_global, kobj);
>> + uint64_t val = 0;
>> +
>> + spin_lock(>lock);
>> + val = glob->lower_mem_limit;
>> + spin_unlock(>lock);
>> +
>> + return snprintf(buffer, PAGE_SIZE, "%llu\n",
>> + (unsigned long long) val << 2);
>
> What is that shift good for?
>
> Because the unit of lower_mem_limit is 4KB, so (val << 2) can get KB for 
> consistent with other parameters as below(all are showed with KB bytes.):

Might want to add a comment or use a define for the shift so others 
doen't get confused in the future.

Sure.

Thanks
Roger(Hongbo.He)
>
> static struct attribute *ttm_mem_zone_attrs[] = {
> _mem_sys,
> _mem_emer,
> _mem_max,
> _mem_swap,
> _mem_used,
> NULL
> };
>
>> +}
>> +
>> +static ssize_t ttm_mem_global_store(struct kobject *kobj,
>> +   struct attribute *attr,
>> +   const char *buffer,
>> +   size_t size) {
>> + int chars;
>> + uint64_t val64;
>> + unsigned long val;
>> + struct ttm_mem_global *glob =
>> + container_of(kobj, struct ttm_mem_global, kobj);
>> +
>> + chars = sscanf(buffer, "%lu", );
>> + if (chars == 0)
>> + return size;
>> +
>> + val64 = val;
>> + val64 >>= 2;
>
> Dito?
> Covert from KB to 4K page size here.
>
>> +
>> + spin_lock(>lock);
>> + glob->lower_mem_limit = val64;
>> + spin_unlock(>lock);
>> +
>> + return size;
>> +}
>> +
>>   static void ttm_mem_global_kobj_release(struct kobject *kobj)
>>   {
>>   struct ttm_mem_global *glob =
>> @@ -174,8 +221,20 @@ static void ttm_mem_global_kobj_release(struct kobject 
>> *kobj)
>>   kfree(glob);
>>   }
>>
>> +static struct attribute *ttm_mem_global_attrs[] = {
>> + _mem_global_lower_mem_limit,
>> + NULL
>> +};
>> +
>> +static const struct sysfs_ops ttm_mem_global_ops = {
>> + .show = _mem_global_show,
>> + .store = _mem_global_store, };
>> +
>>   static struct kobj_type ttm_mem_glob_kobj_type = {
>>   .release = _mem_global_kobj_release,
>> +

RE: [PATCH 8/8] drm/bochs: remove the default ttm_tt_populate callbacks

Series is:  Reviewed-by: Roger He 

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Thursday, February 22, 2018 7:16 PM
To: dri-devel@lists.freedesktop.org
Subject: [PATCH 8/8] drm/bochs: remove the default ttm_tt_populate callbacks

TTM calls the default implementation now.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/bochs/bochs_mm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 704e879711e4..5525b6660340 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -196,8 +196,6 @@ static struct ttm_tt *bochs_ttm_tt_create(struct 
ttm_bo_device *bdev,
 
 struct ttm_bo_driver bochs_bo_driver = {
.ttm_tt_create = bochs_ttm_tt_create,
-   .ttm_tt_populate = ttm_pool_populate,
-   .ttm_tt_unpopulate = ttm_pool_unpopulate,
.init_mem_type = bochs_bo_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = bochs_bo_evict_flags,
-- 
2.14.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 6/6] drm/ttm: drop persistent_swap_storage from ttm_bo_init and co

Series is:  Reviewed-by: Roger He 

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Thursday, February 22, 2018 11:02 PM
To: dri-devel@lists.freedesktop.org
Subject: [PATCH 6/6] drm/ttm: drop persistent_swap_storage from ttm_bo_init and 
co

Never used as parameter, the only driver actually using this is nouveau and 
there it is initialized after the BO is initialized.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |  4 ++--
 drivers/gpu/drm/ast/ast_ttm.c   |  2 +-
 drivers/gpu/drm/bochs/bochs_mm.c|  2 +-
 drivers/gpu/drm/cirrus/cirrus_ttm.c |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c |  2 +-
 drivers/gpu/drm/mgag200/mgag200_ttm.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c|  2 +-
 drivers/gpu/drm/qxl/qxl_object.c|  2 +-
 drivers/gpu/drm/radeon/radeon_object.c  |  4 ++--
 drivers/gpu/drm/ttm/ttm_bo.c|  9 ++---
 drivers/gpu/drm/virtio/virtgpu_object.c |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_mob.c |  5 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c|  4 ++--
 drivers/staging/vboxvideo/vbox_ttm.c|  2 +-
 include/drm/ttm/ttm_bo_api.h| 16 +---
 16 files changed, 21 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c2a4b7215c46..216799ccb545 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -418,8 +418,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
amdgpu_ttm_placement_from_domain(bo, domain);
 
r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
->placement, page_align, , NULL,
-acc_size, sg, resv, _ttm_bo_destroy);
+>placement, page_align, , acc_size,
+sg, resv, _ttm_bo_destroy);
if (unlikely(r != 0))
return r;
 
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c 
index 77d2035dc7b7..211224f6bdd3 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -321,7 +321,7 @@ int ast_bo_create(struct drm_device *dev, int size, int 
align,
 
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, acc_size,
  NULL, NULL, ast_bo_ttm_destroy);
if (ret)
goto error;
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 96edf005bfea..73722484e12b 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -368,7 +368,7 @@ static int bochs_bo_create(struct drm_device *dev, int 
size, int align,
 
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, acc_size,
  NULL, NULL, bochs_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 3413389c0fbe..6cd0233b3bf8 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -328,7 +328,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int 
align,
 
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, acc_size,
  NULL, NULL, cirrus_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index 50e317a2a4ca..8dfffdbb6b07 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -317,7 +317,7 @@ int hibmc_bo_create(struct drm_device *dev, int size, int 
align,
 
ret = ttm_bo_init(>bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, acc_size,
  NULL, NULL, hibmc_bo_ttm_destroy);
if (ret) {
hibmc_bo_unref();
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index cd55ff5f0f0a..69beb2046008 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++

[git pull] drm fixes for v4.16-rc3

2018-02-22 Thread Dave Airlie

Hi Linus,

A bunch of fixes for rc3,

Exynos fixes for using monotonic timestamps, register definitions and
removal of unused file
ipu-v3 - minor changes, make some register arrays const+static, fix some leaks
meson: fix for vsync
atomic: fix for memory leak
EDID parser: add quirks for some more non-desktop devices, and a 6-bit
panel fix.
drm_mm: fix a bug in the core drm mm hole handling
cirrus: fix lut loading regression

Lastly there is a deadlock fix around runtime suspend for secondary
GPUs, there was a deadlock
between one thread trying to wait for a workqueue job to finish in the
runtime suspend path,
and the workqueue job it was waiting for, in turn waiting for a
runtime_get_sync to return. The
fixes avoids it by not doing the runtime sync in the workqueue as then
we always wait for all
those tasks to complete before we runtime suspend.

Dave.

The following changes since commit 91ab883eb21325ad80f3473633f794c78ac87f51:

  Linux 4.16-rc2 (2018-02-18 17:29:42 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.16-rc3

for you to fetch changes up to b17800e9b7cb30e3a83d0b0ff4dc9872f0dad8c4:

  Merge tag 'imx-drm-next-2018-02-22' of
git://git.pengutronix.de/git/pza/linux into drm-fixes (2018-02-23
11:11:57 +1000)


exynos, meson, ipuv3, secondary gpu, cirrus, edid quirk fixes


Arnd Bergmann (1):
  drm/exynos: g2d: use monotonic timestamps

Chris Wilson (1):
  drm: Handle unexpected holes in color-eviction

Colin Ian King (1):
  gpu: ipu-v3: make const arrays int_reg static, shrinks object size

Corentin Labbe (1):
  drm/exynos: remove exynos_drm_rotator.h

Daniel Vetter (1):
  drm/cirrus: Load lut in crtc_commit

Dave Airlie (4):
  Merge tag 'exynos-drm-fixes-for-v4.16-rc3' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes
  Merge tag 'drm-misc-fixes-2018-01-31' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-misc-fixes-2018-02-21' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'imx-drm-next-2018-02-22' of
git://git.pengutronix.de/git/pza/linux into drm-fixes

Jan Luebbe (1):
  gpu: ipu-csi: add 10/12-bit grayscale support to mbus_code_to_bus_cfg

Jani Nikula (1):
  drm/tve200: fix kernel-doc documentation comment include

Kai-Heng Feng (1):
  drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA

Leo (Sunpeng) Li (1):
  drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

Lukas Wunner (5):
  workqueue: Allow retrieval of current task's work struct
  drm: Allow determining if current task is output poll worker
  drm/nouveau: Fix deadlock on runtime suspend
  drm/radeon: Fix deadlock on runtime suspend
  drm/amdgpu: Fix deadlock on runtime suspend

Markus Elfring (1):
  drm/exynos: g2d: Delete an error message for a failed memory
allocation in two functions

Neil Armstrong (1):
  drm/meson: fix vsync buffer update

Philipp Zabel (5):
  gpu: ipu-cpmem: add 8-bit grayscale support to ipu_cpmem_set_image
  gpu: ipu-cpmem: add 16-bit grayscale support to ipu_cpmem_set_image
  drm/edid: quirk Oculus Rift headsets as non-desktop
  drm/edid: quirk Windows Mixed Reality headsets as non-desktop
  drm/edid: quirk Sony PlayStation VR headset as non-desktop

Sylwester Nawrocki (1):
  drm: exynos: Use proper macro definition for HDMI_I2S_PIN_SEL_1

Tobias Jordan (2):
  gpu: ipu-v3: pre: fix device node leak in ipu_pre_lookup_by_phandle
  gpu: ipu-v3: prg: fix device node leak in ipu_prg_lookup_by_phandle

Wolfram Sang (1):
  drm/exynos: fix comparison to bitshift when dealing with a mask

 Documentation/gpu/tve200.rst   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +---
 drivers/gpu/drm/cirrus/cirrus_mode.c   | 40 --
 drivers/gpu/drm/drm_atomic_helper.c| 15 ++
 drivers/gpu/drm/drm_edid.c | 21 
 drivers/gpu/drm/drm_mm.c   | 21 ++--
 drivers/gpu/drm/drm_probe_helper.c | 20 +++
 drivers/gpu/drm/exynos/exynos_drm_g2d.c| 12 ++---
 drivers/gpu/drm/exynos/exynos_drm_rotator.h| 19 ---
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  7 ++-
 drivers/gpu/drm/exynos/regs-fimc.h |  2 +-
 drivers/gpu/drm/exynos/regs-hdmi.h |  2 +-
 drivers/gpu/drm/meson/meson_crtc.c |  6 +++
 drivers/gpu/drm/meson/meson_drv.h  |  3 ++
 drivers/gpu/drm/meson/meson_plane.c|  7 ++-
 drivers/gpu/drm/nouveau/nouveau_connector.c| 18 +--
 drivers/gpu/drm/radeon/radeon_connectors.c | 74 +-
 drivers/gpu/ipu-v3/ipu-common.c|  4 +-
 drivers/gpu/ipu-v3/ipu-cpmem.c |  2 +

[Bug 105200] [r600g] Regression: ImageMagick OpenCL kernel no longer compiles

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

--- Comment #3 from Jan Vesely  ---
you'll need the libclc build fixes from:
http://lists.llvm.org/pipermail/libclc-dev/2018-February/002796.html
and
http://lists.llvm.org/pipermail/libclc-dev/2018-February/002800.html

(all 5 of them).
Alternatively you can wait until they land.

-- 
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 RFC v3 4/6] drm: drm_fourcc: Add new formats for Xilinx IPs

2018-02-22 Thread Hyun Kwon

Hi Danidel,

Thanks for the comment.

On Mon, 2018-02-19 at 06:22:56 -0800, Daniel Vetter wrote:
> On Fri, Feb 09, 2018 at 05:35:54PM -0800, Hyun Kwon wrote:
> > This patch adds new formats needed by Xilinx IP. Pixels are not
> > byte-aligned in these formats, and the drm_format_info for these
> > formats has macro-pixel information.
> > 
> > Signed-off-by: Jeffrey Mouroux 
> > Signed-off-by: Hyun Kwon 
> > ---
> > v3
> > - Update entries for changes
> > - Squash fourcc patch into this
> > v2
> > - Add detailed descriptions
> > - Remove formats with no user
> > ---
> > ---
> >  drivers/gpu/drm/drm_fourcc.c  | 2 ++
> >  include/uapi/drm/drm_fourcc.h | 8 
> >  2 files changed, 10 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index ed95de2..36bff7a 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -168,6 +168,8 @@ const struct drm_format_info *__drm_format_info(u32 
> > format)
> > { .format = DRM_FORMAT_NV61,.depth = 0,  
> > .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 1 },
> > { .format = DRM_FORMAT_NV24,.depth = 0,  
> > .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 1, .vsub = 1 },
> > { .format = DRM_FORMAT_NV42,.depth = 0,  
> > .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_XV15,.depth = 0,  
> > .num_planes = 2, .pixels_per_macropixel = { 3, 3, 0 }, 
> > .bytes_per_macropixel = { 4, 8, 0 }, .hsub = 2, .vsub = 2, },
> > +   { .format = DRM_FORMAT_XV20,.depth = 0,  
> > .num_planes = 2, .pixels_per_macropixel = { 3, 3, 0 }, 
> > .bytes_per_macropixel = { 4, 8, 0 }, .hsub = 2, .vsub = 1, },
> 
> There's no need to set fields explicitly to 0. I think we could even do a
> separate patch to nuke all the .depth = 0, assignments.
> 
> One thing that I've realized now that your new pixel formats stick out:
> How is macropixel supposed to interact with hsub/vsub? From you example it
> looks like macropixels are applied after subsampling (i.e. a macropixel
> block of 3 pixels, but hsub = 2 means the macroblock will actually span 6
> pixels). I think the kerneldoc in the earlier patch should explain this is
> allowed, and how it's supposed to work exactly.
> 
> Also, do we have open-source userspace somewhere for this new pixel format?
> 

We have modified modetest to test these formats. The change, especially
the pattern generation part, isn't clean enough to be shared at the moment. But
I can do some clean-up and share if that helps.

Then this change (may not be the latest set) was used to prototype the support
in the gstreamer kmssink plug-in, but it's implemented by Collabora. Not sure
if the change is accessible, but I can check.

I'll address rest of your comments.

Thanks,
-hyun

> Thanks, Daniel
> 
> 
> > { .format = DRM_FORMAT_YUYV,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> > { .format = DRM_FORMAT_YVYU,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> > { .format = DRM_FORMAT_UYVY,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index e04613d..6ac5282 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -142,6 +142,14 @@ extern "C" {
> >  #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
> > non-subsampled Cb:Cr plane */
> >  
> >  /*
> > + * 2 plane 10 bit per component YCbCr
> > + * index 0 = Y plane, [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian
> > + * index 1 = Cb:Cr plane, [63:0] x:Cb2:Cr2:Cb1:x:Cr1:Cb0:Cr0 
> > 2:10:10:10:2:10:10:10 little endian
> > + */
> > +#define DRM_FORMAT_XV15fourcc_code('X', 'V', '1', '5') /* 2x2 
> > subsampled Cb:Cr plane 2:10:10:10 */
> > +#define DRM_FORMAT_XV20fourcc_code('X', 'V', '2', '0') /* 2x1 
> > subsampled Cb:Cr plane 2:10:10:10 */
> > +
> > +/*
> >   * 3 plane YCbCr
> >   * index 0: Y plane, [7:0] Y
> >   * index 1: Cb plane, [7:0] Cb
> > -- 
> > 2.7.4
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/5] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings

2018-02-22 Thread Hyun Kwon

Hi Laurent,

On Thu, 2018-02-22 at 06:23:38 -0800, Laurent Pinchart wrote:
> Hi Hyun,
> 
> Thank you for the patch.
> 
> On Wednesday, 7 February 2018 03:36:37 EET Hyun Kwon wrote:
> > This add a dt binding for ZynqMP DP subsystem.
> > 
> > Signed-off-by: Hyun Kwon 
> > Reviewed-by: Rob Herring 
> > ---
> > v4
> > - Specify phy related descriptions
> > - Specify dma related descriptions
> > - Remove ports
> > - Remove child nodes for layers
> > - Update the example accordingly
> > v2
> > - Group multiple ports under 'ports'
> > - Replace linux specific terms with generic hardware descriptions
> > ---
> > ---
> >  .../bindings/display/xlnx/xlnx,zynqmp-dpsub.txt| 67 +++
> >  1 file changed, 67 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
> > b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt new
> > file mode 100644
> > index 000..f4a2e6d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
> > @@ -0,0 +1,67 @@
> > +Xilinx ZynqMP DisplayPort subsystem
> > +---
> 
> A short description of the hardware would be useful. You can also link to the 
> documentation. I have found v1.0, v2.0 and v2.1 of the PG199 document, which 
> seem to correspond to the "dp" register map (and confusingly documented as 
> the 
> "DisplayPort TX Subsystem"), but no document that describes the full 
> DisplayPort subsystem as defined by these bindings.

Please refer to chapter 33 in
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
Not sure if it has enough details, but only public documentation that I know of.

> 
> > +Required properties:
> > +
> > +- compatible: Must be "xlnx,zynqmp-dpsub-1.7".
> > +
> > +- reg: Physical base address and length of the registers set for the
> > device.
> > +- reg-names: Must be "dp", "blend", "av_buf", and "aud" to map logical
> > register
> > +  partitions.
> > +
> > +- interrupts: Interrupt number.
> > +- interrupts-parent: phandle for interrupt controller.
> > +
> > +- clocks: phandles for axi, audio, non-live video, and live video clocks.
> > +  axi clock is required. Audio clock is optional. If not present, audio
> > will
> > +  be disabled. One of non-live or live video clock should be present.
> > +- clock-names: The identification strings are required. "aclk" for axi
> > clock.
> > +  "dp_aud_clk" for audio clock. "dp_vtc_pixel_clk_in" for non-live video
> > clock.
> > +  "dp_live_video_in_clk" for live video clock (clock from programmable
> > logic).
> > +
> > +- phys: phandles for phy specifier. The number of lanes is configurable
> > +  between 1 and 2. The number of phandles should be 1 or 2.
> > +- phy-names: The identifier strings. "dp-phy" followed by index, 0 or 1.
> > +  For single lane, only "dp-phy0" is required. For dual lane, both
> > "dp-phy0"
> > +  and "dp-phy1" are required where "dp-phy0" is the primary lane.
> > +
> > +- power-domains: phandle for the corresponding power domain
> > +
> > +- dmas: phandles for DMA channels as defined in
> > +  Documentation/devicetree/bindings/dma/dma.txt.
> > +- dma-names: The identifier strings are required. "gfx0" for graphics layer
> > +  dma channel. "vid" followed by index (0 - 2) for video layer dma
> > channels.
> > +
> > +Optional child node
> > +
> > +- The driver populates any child device node in this node. This can be
> > used,
> > +  for example, to populate the sound device from the DisplayPort subsystem
> > +  driver.
> 
> DT bindings should describe the hardware, not the OS software. You should not 
> mention drivers.
> 
> Furthermore the above paragraph doesn't seem very clear to me, and the 
> example 
> doesn't include any child node, so I'm left wondering what you meant.

I left some room for future and downstream, but I agree. I can remove this from
this set.

> 
> > +Example:
> > +   zynqmp-display-subsystem@fd4a {
> > +   compatible = "xlnx,zynqmp-dpsub-1.7";
> > +   reg = <0x0 0xfd4a 0x0 0x1000>,
> > + <0x0 0xfd4aa000 0x0 0x1000>,
> > + <0x0 0xfd4ab000 0x0 0x1000>,
> > + <0x0 0xfd4ac000 0x0 0x1000>;
> > +   reg-names = "dp", "blend", "av_buf", "aud";
> 
> Without seeing the documentation it's a bit hard to tell, but it looks to me 
> like this "subsystem" aggregates four separate IP cores that can be used 
> individually. The "dp" registers in particular make me think that the 
> DisplayPort transmitter is a separate IP core corresponding to PG199. If 
> that's the case, I think the IP cores should be modeled as individual DT 
> nodes, and connected through the OF graph bindings.
> 

The PG199 is for the soft IP core, but this is for the hardened IP on
ZynqMP SoC. Please refer to

Re: [PATCH 0/7] drm/virtio: Checkpatch cleanup for virtio

2018-02-22 Thread Gurchetan Singh

Patches 1 to 7 are:

Reviewed-by: Gurchetan Singh 

On Thu, Feb 22, 2018 at 3:59 PM, Rodrigo Siqueira
 wrote:
> This patchset fixes warnings and errors found by checkpatch.pl in the
> drm/virtio:
>
> * Removes return from void function;
> * Adds */ in block comments to separate line;
> * Adds blank line after variable declarations;
> * Adds tabs at the start of a line;
> * Replaces 'unsigned' for 'unsigned int';
> * Removes multiple blank lines;
> * Adds spaces around operators.
>
> Rodrigo Siqueira (7):
>   drm/virtio: Add tabs at the start of a line
>   drm/virtio: Add blank line after variable declarations
>   drm/virtio: Add */ in block comments to separate line
>   drm/virtio: Remove return from void function
>   drm/virtio: Replace 'unsigned' for 'unsigned int'
>   drm/virtio: Remove multiple blank lines
>   drm/virtio: Add spaces around operators
>
>  drivers/gpu/drm/virtio/virtgpu_display.c |  7 ---
>  drivers/gpu/drm/virtio/virtgpu_drv.c |  2 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.h |  8 
>  drivers/gpu/drm/virtio/virtgpu_fb.c  |  6 +-
>  drivers/gpu/drm/virtio/virtgpu_gem.c |  1 +
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c   | 23 +--
>  drivers/gpu/drm/virtio/virtgpu_prime.c   |  4 ++--
>  drivers/gpu/drm/virtio/virtgpu_ttm.c |  4 +---
>  drivers/gpu/drm/virtio/virtgpu_vq.c  | 13 -
>  9 files changed, 39 insertions(+), 29 deletions(-)
>
> --
> 2.16.2
>
> ___
> 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 v5 1/5] drm: xlnx: Xilinx DRM KMS module

2018-02-22 Thread Hyun Kwon

Hi Laurent,

On Thu, 2018-02-22 at 05:40:50 -0800, Laurent Pinchart wrote:
> Hi Hyun,
> 
> On Thursday, 22 February 2018 04:50:42 EET Hyun Kwon wrote:
> > On Wed, 2018-02-21 at 15:17:25 -0800, Laurent Pinchart wrote:
> > > On Wednesday, 7 February 2018 03:36:36 EET Hyun Kwon wrote:
> > >> Xilinx has various platforms for display, where users can create
> > >> using multiple IPs in the programmable FPGA fabric, or where
> > >> some hardened piepline is available on the chip. Furthermore,
> > > 
> > > s/piepline/pipeline/
> > > 
> > >> hardened pipeline can also interact with soft logics in FPGA.
> > >> 
> > >> The Xilinx DRM KMS module is to integrate multiple subdevices and
> > >> to represent the entire pipeline as a single DRM device. The module
> > >> includes helper (ex, framebuffer and gem helpers) and
> > >> glue logic (ex, crtc interface) functions.
> > >> 
> > >> Signed-off-by: Hyun Kwon 
> > >> Acked-by: Daniel Vetter 
> > >> ---
> > >> v5
> > >> - Redefine xlnx_pipeline_init()
> > >> v4
> > >> - Fix a bug in of graph binding handling
> > >> - Remove vblank callbacks from xlnx_crtc
> > >> - Remove the dt binding. This module becomes more like a library.
> > >> - Rephrase the commit message
> > >> v3
> > >> - Add Laurent as a maintainer
> > >> - Fix multiple-reference on gem objects
> > >> v2
> > >> - Change the SPDX identifier format
> > >> - Merge patches(crtc, gem, fb) into single one
> > >> v2 of xlnx_drv
> > >> - Rename kms to display in xlnx_drv
> > >> - Replace some xlnx specific fb helper with common helpers in xlnx_drv
> > >> - Don't set the commit tail callback in xlnx_drv
> > >> - Support 'ports' graph binding in xlnx_drv
> > >> v2 of xlnx_fb
> > >> - Remove wrappers in xlnx_fb
> > >> - Replace some functions with drm core helpers in xlnx_fb
> > >> ---
> > >> ---
> > >> 
> > >>  MAINTAINERS  |   9 +
> > >>  drivers/gpu/drm/Kconfig  |   2 +
> > >>  drivers/gpu/drm/Makefile |   1 +
> > >>  drivers/gpu/drm/xlnx/Kconfig |  12 +
> > >>  drivers/gpu/drm/xlnx/Makefile|   2 +
> > >>  drivers/gpu/drm/xlnx/xlnx_crtc.c | 177 ++
> > >>  drivers/gpu/drm/xlnx/xlnx_crtc.h |  70 ++
> > >>  drivers/gpu/drm/xlnx/xlnx_drv.c  | 501 +
> > >>  drivers/gpu/drm/xlnx/xlnx_drv.h  |  33 +++
> > >>  drivers/gpu/drm/xlnx/xlnx_fb.c   | 298 +++
> > >>  drivers/gpu/drm/xlnx/xlnx_fb.h   |  33 +++
> > >>  drivers/gpu/drm/xlnx/xlnx_gem.c  |  47 
> > >>  drivers/gpu/drm/xlnx/xlnx_gem.h  |  26 ++
> > >>  13 files changed, 1211 insertions(+)
> > >>  create mode 100644 drivers/gpu/drm/xlnx/Kconfig
> > >>  create mode 100644 drivers/gpu/drm/xlnx/Makefile
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.c
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.h
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.c
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.h
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.c
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.h
> 
> [snip]
> 
> > >> diff --git a/drivers/gpu/drm/xlnx/xlnx_crtc.c
> > >> b/drivers/gpu/drm/xlnx/xlnx_crtc.c new file mode 100644
> > >> index 000..de83905
> > >> --- /dev/null
> > >> +++ b/drivers/gpu/drm/xlnx/xlnx_crtc.c
> 
> [snip]
> 
> > >> +uint32_t xlnx_crtc_helper_get_format(struct xlnx_crtc_helper *helper)
> > > 
> > > You can use the u32 type within the kernel.
> > > 
> > >> +{
> > >> +struct xlnx_crtc *crtc;
> > >> +u32 format = 0, tmp;
> > >> +
> > >> +list_for_each_entry(crtc, >xlnx_crtcs, list) {
> > >> +if (crtc->get_format) {
> > >> +tmp = crtc->get_format(crtc);
> > >> +if (format && format != tmp)
> > >> +return 0;
> > >> +format = tmp;
> > > 
> > > Same comments regarding the tmp variable and the list locking issue.
> > > 
> > >> +}
> > >> +}
> > >> +
> > >> +return format;
> > > 
> > > Does this mean that your CRTCs support a single format each only ?
> 
> Does it ? :-)
>  
> > >> +}
> 
> [snip]
> 
> > >> diff --git a/drivers/gpu/drm/xlnx/xlnx_drv.c
> > >> b/drivers/gpu/drm/xlnx/xlnx_drv.c new file mode 100644
> > >> index 000..8f0e357
> > >> --- /dev/null
> > >> +++ b/drivers/gpu/drm/xlnx/xlnx_drv.c
> 
> [snip]
> 
> > >> +static int xlnx_of_component_probe(struct device *master_dev,
> > >> +   int (*compare_of)(struct device *, 
> > >> void *),
> > >> +   const struct component_master_ops 
> > >> *m_ops)
> > > 
> > > As there's a single user of this function, do you need to pass compare_of
> > > as a parameter ? Couldn't you move xlnx_compare_of() above and use it
> > > directly ?
> > > 
>

RE: [PATCH] drm/ttm: check if free mem space is under the lower limit



-Original Message-
From: Koenig, Christian 
Sent: Thursday, February 22, 2018 8:54 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: check if free mem space is under the lower limit

Am 22.02.2018 um 12:43 schrieb He, Roger:
>
> -Original Message-
> From: Koenig, Christian
> Sent: Thursday, February 22, 2018 7:28 PM
> To: He, Roger ; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH] drm/ttm: check if free mem space is under the 
> lower limit
>
> Am 22.02.2018 um 11:10 schrieb Roger He:
>> the free mem space and the lower limit both include two parts:
>> system memory and swap space.
>>
>> For the OOM triggered by TTM, that is the case as below:
>> first swap space is full of swapped out pages and soon system memory 
>> also is filled up with ttm pages. and then any memory allocation 
>> request will run into OOM.
>>
>> to cover two cases:
>> a. if no swap disk at all or free swap space is under swap mem
>>  limit but available system mem is bigger than sys mem limit,
>>  allow TTM allocation;
>>
>> b. if the available system mem is less than sys mem limit but
>>  free swap space is bigger than swap mem limit, allow TTM
>>  allocation.
>>
>> v2: merge two memory limit(swap and system) into one
>> v3: keep original behavior except ttm_opt_ctx->flags with
>>   TTM_OPT_FLAG_FORCE_ALLOC
>> v4: always set force_alloc as tx->flags & TTM_OPT_FLAG_FORCE_ALLOC
>> v5: add an attribute for lower_mem_limit
>>
>> Signed-off-by: Roger He 
>> ---
>>drivers/gpu/drm/ttm/ttm_memory.c | 94 
>> 
>>drivers/gpu/drm/ttm/ttm_page_alloc.c |  3 +
>>drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 +
>>include/drm/ttm/ttm_memory.h |  5 ++
>>4 files changed, 105 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
>> b/drivers/gpu/drm/ttm/ttm_memory.c
>> index aa0c381..d015e39 100644
>> --- a/drivers/gpu/drm/ttm/ttm_memory.c
>> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
>> @@ -36,6 +36,7 @@
>>#include 
>>#include 
>>#include 
>> +#include 
>>
>>#define TTM_MEMORY_ALLOC_RETRIES 4
>>
>> @@ -166,6 +167,52 @@ static struct kobj_type ttm_mem_zone_kobj_type = {
>>  .default_attrs = ttm_mem_zone_attrs,
>>};
>>
>> +static struct attribute ttm_mem_global_lower_mem_limit = {
>> +.name = "lower_mem_limit",
>> +.mode = S_IRUGO | S_IWUSR
>> +};
>> +
>> +static ssize_t ttm_mem_global_show(struct kobject *kobj,
>> + struct attribute *attr,
>> + char *buffer)
>> +{
>> +struct ttm_mem_global *glob =
>> +container_of(kobj, struct ttm_mem_global, kobj);
>> +uint64_t val = 0;
>> +
>> +spin_lock(>lock);
>> +val = glob->lower_mem_limit;
>> +spin_unlock(>lock);
>> +
>> +return snprintf(buffer, PAGE_SIZE, "%llu\n",
>> +(unsigned long long) val << 2);
>   What is that shift good for?
>
> Because the unit of lower_mem_limit is 4KB, so (val << 2) can get KB for 
> consistent with other parameters as below(all are showed with KB bytes.):

Ok that makes sense.

>
> static struct attribute *ttm_mem_zone_attrs[] = {
>   _mem_sys,
>   _mem_emer,
>   _mem_max,
>   _mem_swap,
>   _mem_used,
>   NULL
> };
>   
>> +}
>> +
>> +static ssize_t ttm_mem_global_store(struct kobject *kobj,
>> +  struct attribute *attr,
>> +  const char *buffer,
>> +  size_t size)
>> +{
>> +int chars;
>> +uint64_t val64;
>> +unsigned long val;
>> +struct ttm_mem_global *glob =
>> +container_of(kobj, struct ttm_mem_global, kobj);
>> +
>> +chars = sscanf(buffer, "%lu", );
>> +if (chars == 0)
>> +return size;
>> +
>> +val64 = val;
>> +val64 >>= 2;
>   Dito?
> Covert from KB to 4K page size here.
>
>> +
>> +spin_lock(>lock);
>> +glob->lower_mem_limit = val64;
>> +spin_unlock(>lock);
>> +
>> +return size;
>> +}
>> +
>>static void ttm_mem_global_kobj_release(struct kobject *kobj)
>>{
>>  struct ttm_mem_global *glob =
>> @@ -174,8 +221,20 @@ static void ttm_mem_global_kobj_release(struct kobject 
>> *kobj)
>>  kfree(glob);
>>}
>>
>> +static struct attribute *ttm_mem_global_attrs[] = {
>> +_mem_global_lower_mem_limit,
>> +NULL
>> +};
>> +
>> +static const struct sysfs_ops ttm_mem_global_ops = {
>> +.show = _mem_global_show,
>> +.store = _mem_global_store,
>> +};
>> +
>>static struct kobj_type ttm_mem_glob_kobj_type = {
>>  .release = _mem_global_kobj_release,
>> +.sysfs_ops = _mem_global_ops,
>> +.default_attrs = ttm_mem_global_attrs,
>>};
>>
>>static bool ttm_zones_above_swap_target(struct ttm_mem_global 
>> *glob, @@ -375,6 +434,11 @@ int ttm_mem_global_init(struct 
>> ttm_mem_global
>>

[Bug 105200] [r600g] Regression: ImageMagick OpenCL kernel no longer compiles

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

--- Comment #2 from nixscrip...@gmail.com ---
It seems the libclc version I'm using was Feb 2nd. Good point

... and now that I've tried to compile SVN r325851, I see why it was held back.

First, I had to patch this:

And this is after I did my little patch to avoid an LLVM syntax error:

Index: utils/prepare-builtins.cpp
===
--- utils/prepare-builtins.cpp  (revision 325851)
+++ utils/prepare-builtins.cpp  (working copy)
@@ -105,7 +105,7 @@
 exit(1);
   }

-  WriteBitcodeToFile(M, Out->os());
+  WriteBitcodeToFile(*M, Out->os());

   // Declare success.
   Out->keep();


And then... more address space issues:

[...]
WARNING: Linking two modules of different data layouts:
'r600--/lib/relational/isnormal.cl.cayman.bc' is
'e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-A5'
whereas 'llvm-link' is
'e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64'

WARNING: Linking two modules of different data layouts:
'r600--/lib/relational/isnotequal.cl.cayman.bc' is
'e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-A5'
whereas 'llvm-link' is
'e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64'
[...]
Allocation instruction pointer not in the stack address space!
  %2 = alloca i32, align 4, addrspace(5)
Allocation instruction pointer not in the stack address space!
  %3 = alloca i32, align 4, addrspace(5)
Allocation instruction pointer not in the stack address space!
  %4 = alloca i32, align 4, addrspace(5)
Allocation instruction pointer not in the stack address space!
  %5 = alloca i32, align 4, addrspace(5)
Allocation instruction pointer not in the stack address space!
  %6 = alloca i32, align 4, addrspace(5)
[...]
Allocation instruction pointer not in the stack address space!
  %33 = alloca float, align 4, addrspace(5)
/usr/bin/llvm-link: error: linked module is broken!
make: *** [Makefile:3127: r600--/lib/builtins.link.cedar.bc] Error 1

-- 
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 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

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

--- Comment #42 from Bong Cosca  ---
Created attachment 137550
  --> https://bugs.freedesktop.org/attachment.cgi?id=137550=edit
radeonsi: force si_write_harvested_raster_configs

Here's what finally worked.

Force the call to si_write_harvested_raster_configs() and remove the rb_per_se
check >= 2 inside it so even those cards with rb_per_se = 1 (such as mine) will
get the rb0/rb1 masking and the subsequent RASTER_CONFIG_RB_MAP computed
correctly.

-- 
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 libdrm v2] *-symbol-check: Don't hard-code nm executable

2018-02-22 Thread Emil Velikov

On 19 February 2018 at 16:35, Eric Engestrom  wrote:
> From: Heiko Becker 
>
> Helpful if your nm executable has a prefix based on the
> architecture, for example.
>

> +env_test = environment()
> +env_test.set('NM', find_program('nm').path())
> +
Everything else is great, just not too sure about this hunk.
Are you sure it does what the commit message says?

I know meson needs special configuration file for cross compilation -
one example where nm has prefix.
Yet the manual [1] does not say anything about nm. I cannot find any
instances of nm in the docs all together :-\

If Meson does not handle it currently, please open a bug and add a
comment with the bug number/link.

Thanks
Emil
[1] http://mesonbuild.com/Cross-compilation.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] drm/virtio: Replace 'unsigned' for 'unsigned int'

This patch fixes the checkpatch.pl warning:

drivers/gpu/drm/virtio/virtgpu_display.c:64: WARNING: Prefer 'unsigned
int' to bare use of 'unsigned'
...

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 4 ++--
 drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
 drivers/gpu/drm/virtio/virtgpu_fb.c  | 2 +-
 drivers/gpu/drm/virtio/virtgpu_ttm.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 2d1b25630c0e..8cc8c34d67f5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -61,9 +61,9 @@ static void virtio_gpu_user_framebuffer_destroy(struct 
drm_framebuffer *fb)
 static int
 virtio_gpu_framebuffer_surface_dirty(struct drm_framebuffer *fb,
 struct drm_file *file_priv,
-unsigned flags, unsigned color,
+unsigned int flags, unsigned int color,
 struct drm_clip_rect *clips,
-unsigned num_clips)
+unsigned int num_clips)
 {
struct virtio_gpu_framebuffer *virtio_gpu_fb
= to_virtio_gpu_framebuffer(fb);
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 59801728cfeb..d25c8ca224aa 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -246,7 +246,7 @@ int virtio_gpu_fbdev_init(struct virtio_gpu_device *vgdev);
 void virtio_gpu_fbdev_fini(struct virtio_gpu_device *vgdev);
 int virtio_gpu_surface_dirty(struct virtio_gpu_framebuffer *qfb,
 struct drm_clip_rect *clips,
-unsigned num_clips);
+unsigned int num_clips);
 /* virtio vg */
 int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev);
 void virtio_gpu_free_vbufs(struct virtio_gpu_device *vgdev);
diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c 
b/drivers/gpu/drm/virtio/virtgpu_fb.c
index b933cbba0685..8af69ab58b89 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -118,7 +118,7 @@ static int virtio_gpu_dirty_update(struct 
virtio_gpu_framebuffer *fb,
 
 int virtio_gpu_surface_dirty(struct virtio_gpu_framebuffer *vgfb,
 struct drm_clip_rect *clips,
-unsigned num_clips)
+unsigned int num_clips)
 {
struct virtio_gpu_device *vgdev = vgfb->base.dev->dev_private;
struct virtio_gpu_object *obj = gem_to_virtio_gpu_obj(vgfb->obj);
diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c 
b/drivers/gpu/drm/virtio/virtgpu_ttm.c
index cd4a17a1409a..580323ceeb8a 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
@@ -224,7 +224,7 @@ static int virtio_gpu_init_mem_type(struct ttm_bo_device 
*bdev, uint32_t type,
man->default_caching = TTM_PL_FLAG_CACHED;
break;
default:
-   DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
+   DRM_ERROR("Unsupported memory type %u\n", (unsigned int)type);
return -EINVAL;
}
return 0;
-- 
2.16.2

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

[PATCH 7/7] drm/virtio: Add spaces around operators

This patch fixes the checkpatch.pl check:

virtgpu_ioctl.c:535: CHECK: spaces preferred around that '|' (ctx:VxV)
virtgpu_vq.c:277: CHECK: spaces preferred around that '+' (ctx:VxV)
...

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 18 +-
 drivers/gpu/drm/virtio/virtgpu_vq.c|  6 +++---
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index d52a86eaa884..04e09fc56f66 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -532,34 +532,34 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device 
*dev,
 
 struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS] = {
DRM_IOCTL_DEF_DRV(VIRTGPU_MAP, virtio_gpu_map_ioctl,
- DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
 
DRM_IOCTL_DEF_DRV(VIRTGPU_EXECBUFFER, virtio_gpu_execbuffer_ioctl,
- DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
 
DRM_IOCTL_DEF_DRV(VIRTGPU_GETPARAM, virtio_gpu_getparam_ioctl,
- DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
 
DRM_IOCTL_DEF_DRV(VIRTGPU_RESOURCE_CREATE,
  virtio_gpu_resource_create_ioctl,
- DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
 
DRM_IOCTL_DEF_DRV(VIRTGPU_RESOURCE_INFO, virtio_gpu_resource_info_ioctl,
- DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
 
/* make transfer async to the main ring? - no sure, can we
 * thread these in the underlying GL
 */
DRM_IOCTL_DEF_DRV(VIRTGPU_TRANSFER_FROM_HOST,
  virtio_gpu_transfer_from_host_ioctl,
- DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VIRTGPU_TRANSFER_TO_HOST,
  virtio_gpu_transfer_to_host_ioctl,
- DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
 
DRM_IOCTL_DEF_DRV(VIRTGPU_WAIT, virtio_gpu_wait_ioctl,
- DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
 
DRM_IOCTL_DEF_DRV(VIRTGPU_GET_CAPS, virtio_gpu_get_caps_ioctl,
- DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
 };
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 18c78a7fa044..48e4f1df6e5d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -274,7 +274,7 @@ static int virtio_gpu_queue_ctrl_buffer_locked(struct 
virtio_gpu_device *vgdev,
return -ENODEV;
 
sg_init_one(, vbuf->buf, vbuf->size);
-   sgs[outcnt+incnt] = 
+   sgs[outcnt + incnt] = 
outcnt++;
 
if (vbuf->data_size) {
@@ -709,8 +709,8 @@ void virtio_gpu_cmd_context_create(struct virtio_gpu_device 
*vgdev, uint32_t id,
cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_CTX_CREATE);
cmd_p->hdr.ctx_id = cpu_to_le32(id);
cmd_p->nlen = cpu_to_le32(nlen);
-   strncpy(cmd_p->debug_name, name, sizeof(cmd_p->debug_name)-1);
-   cmd_p->debug_name[sizeof(cmd_p->debug_name)-1] = 0;
+   strncpy(cmd_p->debug_name, name, sizeof(cmd_p->debug_name) - 1);
+   cmd_p->debug_name[sizeof(cmd_p->debug_name) - 1] = 0;
virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
 }
 
-- 
2.16.2

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

[PATCH 6/7] drm/virtio: Remove multiple blank lines

This patch fixes the checkpatch.pl check:

virtgpu_drv.c:116: CHECK: Please don't use multiple blank lines
virtgpu_vq.c:599: CHECK: Please don't use multiple blank lines
virtgpu_prime.c:42: CHECK: Please don't use multiple blank lines

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/virtio/virtgpu_drv.c   | 1 -
 drivers/gpu/drm/virtio/virtgpu_prime.c | 1 -
 drivers/gpu/drm/virtio/virtgpu_vq.c| 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 5d21433b1cdf..d9287c144fe5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -113,7 +113,6 @@ static const struct file_operations virtio_gpu_driver_fops 
= {
.llseek = noop_llseek,
 };
 
-
 static struct drm_driver driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | 
DRIVER_RENDER | DRIVER_ATOMIC,
.load = virtio_gpu_driver_load,
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 6c6e9dbab096..d27a1688714f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -39,7 +39,6 @@ void virtgpu_gem_prime_unpin(struct drm_gem_object *obj)
WARN_ONCE(1, "not implemented");
 }
 
-
 struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
 {
WARN_ONCE(1, "not implemented");
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 809d20eb6571..18c78a7fa044 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -596,7 +596,6 @@ static void virtio_gpu_cmd_capset_cb(struct 
virtio_gpu_device *vgdev,
wake_up(>resp_wq);
 }
 
-
 int virtio_gpu_cmd_get_display_info(struct virtio_gpu_device *vgdev)
 {
struct virtio_gpu_ctrl_hdr *cmd_p;
-- 
2.16.2

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

[PATCH 4/7] drm/virtio: Remove return from void function

This patch fixes the checkpatch.pl warning:

virtgpu_ttm.c:181: WARNING: void function return statements are not
generally useful
...

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/virtio/virtgpu_ttm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c 
b/drivers/gpu/drm/virtio/virtgpu_ttm.c
index 36655b709eb2..cd4a17a1409a 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
@@ -177,7 +177,6 @@ static void ttm_bo_man_put_node(struct ttm_mem_type_manager 
*man,
struct ttm_mem_reg *mem)
 {
mem->mm_node = (void *)NULL;
-   return;
 }
 
 static int ttm_bo_man_init(struct ttm_mem_type_manager *man,
@@ -244,7 +243,6 @@ static void virtio_gpu_evict_flags(struct ttm_buffer_object 
*bo,
placement->busy_placement = 
placement->num_placement = 1;
placement->num_busy_placement = 1;
-   return;
 }
 
 static int virtio_gpu_verify_access(struct ttm_buffer_object *bo,
-- 
2.16.2

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

[PATCH 2/7] drm/virtio: Add blank line after variable declarations

This patch fixes the checkpatch.pl warnings:

virtgpu_drv.c:57: WARNING: Missing a blank line after declarations
virtgpu_display.c:99: WARNING: Missing a blank line after declarations
...

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 1 +
 drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
 drivers/gpu/drm/virtio/virtgpu_fb.c  | 4 
 drivers/gpu/drm/virtio/virtgpu_gem.c | 1 +
 drivers/gpu/drm/virtio/virtgpu_ioctl.c   | 2 ++
 drivers/gpu/drm/virtio/virtgpu_vq.c  | 3 +++
 6 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 22513d7f895c..2d1b25630c0e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -96,6 +96,7 @@ virtio_gpu_framebuffer_init(struct drm_device *dev,
 {
int ret;
struct virtio_gpu_object *bo;
+
vgfb->obj = obj;
 
bo = gem_to_virtio_gpu_obj(obj);
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 49a3d8d5a249..5d21433b1cdf 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -54,6 +54,7 @@ static int virtio_gpu_probe(struct virtio_device *vdev)
 static void virtio_gpu_remove(struct virtio_device *vdev)
 {
struct drm_device *dev = vdev->priv;
+
drm_put_dev(dev);
 }
 
diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c 
b/drivers/gpu/drm/virtio/virtgpu_fb.c
index 15d18fd0c64b..b933cbba0685 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -127,6 +127,7 @@ int virtio_gpu_surface_dirty(struct virtio_gpu_framebuffer 
*vgfb,
int left, right, top, bottom;
int i;
int inc = 1;
+
if (!num_clips) {
num_clips = 1;
clips = 
@@ -172,6 +173,7 @@ static void virtio_gpu_3d_fillrect(struct fb_info *info,
   const struct fb_fillrect *rect)
 {
struct virtio_gpu_fbdev *vfbdev = info->par;
+
drm_fb_helper_sys_fillrect(info, rect);
virtio_gpu_dirty_update(>vgfb, true, rect->dx, rect->dy,
 rect->width, rect->height);
@@ -182,6 +184,7 @@ static void virtio_gpu_3d_copyarea(struct fb_info *info,
   const struct fb_copyarea *area)
 {
struct virtio_gpu_fbdev *vfbdev = info->par;
+
drm_fb_helper_sys_copyarea(info, area);
virtio_gpu_dirty_update(>vgfb, true, area->dx, area->dy,
   area->width, area->height);
@@ -192,6 +195,7 @@ static void virtio_gpu_3d_imageblit(struct fb_info *info,
const struct fb_image *image)
 {
struct virtio_gpu_fbdev *vfbdev = info->par;
+
drm_fb_helper_sys_imageblit(info, image);
virtio_gpu_dirty_update(>vgfb, true, image->dx, image->dy,
 image->width, image->height);
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c 
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 92fb27753b9e..0f2768eacaee 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -124,6 +124,7 @@ int virtio_gpu_mode_dumb_mmap(struct drm_file *file_priv,
 {
struct drm_gem_object *gobj;
struct virtio_gpu_object *obj;
+
BUG_ON(!offset_p);
gobj = drm_gem_object_lookup(file_priv, handle);
if (gobj == NULL)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 5720a0d4ac0a..86243f131fc1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -83,6 +83,7 @@ static void virtio_gpu_unref_list(struct list_head *head)
struct ttm_validate_buffer *buf;
struct ttm_buffer_object *bo;
struct virtio_gpu_object *qobj;
+
list_for_each_entry(buf, head, head) {
bo = buf->bo;
qobj = container_of(bo, struct virtio_gpu_object, tbo);
@@ -478,6 +479,7 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
int ret;
struct virtio_gpu_drv_cap_cache *cache_ent;
void *ptr;
+
if (vgdev->num_capsets == 0)
return -ENOSYS;
 
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 9eb96fb2c147..16c05bc34bef 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -62,6 +62,7 @@ void virtio_gpu_ctrl_ack(struct virtqueue *vq)
 {
struct drm_device *dev = vq->vdev->priv;
struct virtio_gpu_device *vgdev = dev->dev_private;
+
schedule_work(>ctrlq.dequeue_work);
 }
 
@@ -69,6 +70,7 @@ void virtio_gpu_cursor_ack(struct virtqueue *vq)
 {
struct drm_device *dev = vq->vdev->priv;
struct virtio_gpu_device *vgdev = dev->dev_private;
+
schedule_work(>cursorq.dequeue_work);
 }
 
@@

[PATCH 3/7] drm/virtio: Add */ in block comments to separate line

This patch fixes the checkpatch.pl warning:

virtgpu_ioctl.c:551: WARNING: Block comments use a trailing */ on a
separate line
...

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 ++-
 drivers/gpu/drm/virtio/virtgpu_prime.c | 3 ++-
 drivers/gpu/drm/virtio/virtgpu_vq.c| 3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 86243f131fc1..d52a86eaa884 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -548,7 +548,8 @@ struct drm_ioctl_desc 
virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS] = {
  DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
 
/* make transfer async to the main ring? - no sure, can we
-  thread these in the underlying GL */
+* thread these in the underlying GL
+*/
DRM_IOCTL_DEF_DRV(VIRTGPU_TRANSFER_FROM_HOST,
  virtio_gpu_transfer_from_host_ioctl,
  DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 385e0eb9826a..6c6e9dbab096 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -25,7 +25,8 @@
 #include "virtgpu_drv.h"
 
 /* Empty Implementations as there should not be any other driver for a virtual
- * device that might share buffers with virtgpu */
+ * device that might share buffers with virtgpu
+ */
 
 int virtgpu_gem_prime_pin(struct drm_gem_object *obj)
 {
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 16c05bc34bef..809d20eb6571 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -383,7 +383,8 @@ static int virtio_gpu_queue_cursor(struct virtio_gpu_device 
*vgdev,
 }
 
 /* just create gem objects for userspace and long lived objects,
-   just use dma_alloced pages for the queue objects? */
+ * just use dma_alloced pages for the queue objects?
+ */
 
 /* create a basic resource */
 void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
-- 
2.16.2

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

[PATCH 1/7] drm/virtio: Add tabs at the start of a line

This patch fixes the checkpatch.pl errors:

drivers/gpu/drm/virtio/virtgpu_drv.h:371: ERROR: code indent should use
tabs where possible
...

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
 drivers/gpu/drm/virtio/virtgpu_drv.h | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 19114a3c5ee4..22513d7f895c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -387,7 +387,7 @@ int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev)
for (i = 0 ; i < vgdev->num_scanouts; ++i)
vgdev_output_init(vgdev, i);
 
-drm_mode_config_reset(vgdev->ddev);
+   drm_mode_config_reset(vgdev->ddev);
return 0;
 }
 
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index da2fb585fea4..59801728cfeb 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -363,12 +363,12 @@ int virtgpu_gem_prime_pin(struct drm_gem_object *obj);
 void virtgpu_gem_prime_unpin(struct drm_gem_object *obj);
 struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
 struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
-struct drm_device *dev, struct dma_buf_attachment *attach,
-struct sg_table *sgt);
+   struct drm_device *dev, struct dma_buf_attachment *attach,
+   struct sg_table *sgt);
 void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj);
 void virtgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
-struct vm_area_struct *vma);
+  struct vm_area_struct *vma);
 
 static inline struct virtio_gpu_object*
 virtio_gpu_object_ref(struct virtio_gpu_object *bo)
-- 
2.16.2

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

[PATCH 0/7] drm/virtio: Checkpatch cleanup for virtio

This patchset fixes warnings and errors found by checkpatch.pl in the
drm/virtio:

* Removes return from void function;
* Adds */ in block comments to separate line;
* Adds blank line after variable declarations;
* Adds tabs at the start of a line;
* Replaces 'unsigned' for 'unsigned int';
* Removes multiple blank lines;
* Adds spaces around operators.

Rodrigo Siqueira (7):
  drm/virtio: Add tabs at the start of a line
  drm/virtio: Add blank line after variable declarations
  drm/virtio: Add */ in block comments to separate line
  drm/virtio: Remove return from void function
  drm/virtio: Replace 'unsigned' for 'unsigned int'
  drm/virtio: Remove multiple blank lines
  drm/virtio: Add spaces around operators

 drivers/gpu/drm/virtio/virtgpu_display.c |  7 ---
 drivers/gpu/drm/virtio/virtgpu_drv.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_drv.h |  8 
 drivers/gpu/drm/virtio/virtgpu_fb.c  |  6 +-
 drivers/gpu/drm/virtio/virtgpu_gem.c |  1 +
 drivers/gpu/drm/virtio/virtgpu_ioctl.c   | 23 +--
 drivers/gpu/drm/virtio/virtgpu_prime.c   |  4 ++--
 drivers/gpu/drm/virtio/virtgpu_ttm.c |  4 +---
 drivers/gpu/drm/virtio/virtgpu_vq.c  | 13 -
 9 files changed, 39 insertions(+), 29 deletions(-)

-- 
2.16.2

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

Re: [PATCH v7 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

2018-02-22 Thread Jordan Crouse

On Wed, Feb 07, 2018 at 04:01:19PM +0530, Vivek Gautam wrote:
> From: Sricharan R 
> 
> The smmu device probe/remove and add/remove master device callbacks
> gets called when the smmu is not linked to its master, that is without
> the context of the master device. So calling runtime apis in those places
> separately.
> 
> Signed-off-by: Sricharan R 
> [vivek: Cleanup pm runtime calls]
> Signed-off-by: Vivek Gautam 
> ---
>  drivers/iommu/arm-smmu.c | 42 ++
>  1 file changed, 38 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 9e2f917e16c2..c024f69c1682 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -913,11 +913,15 @@ static void arm_smmu_destroy_domain_context(struct 
> iommu_domain *domain)
>   struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
>   struct arm_smmu_device *smmu = smmu_domain->smmu;
>   struct arm_smmu_cfg *cfg = _domain->cfg;
> - int irq;
> + int ret, irq;
>  
>   if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY)
>   return;
>  
> + ret = pm_runtime_get_sync(smmu->dev);
> + if (ret)
> + return;
> +
>   /*
>* Disable the context bank and free the page tables before freeing
>* it.
> @@ -932,6 +936,8 @@ static void arm_smmu_destroy_domain_context(struct 
> iommu_domain *domain)
>  
>   free_io_pgtable_ops(smmu_domain->pgtbl_ops);
>   __arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
> +
> + pm_runtime_put_sync(smmu->dev);
>  }
>  
>  static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
> @@ -1407,14 +1413,22 @@ static int arm_smmu_add_device(struct device *dev)
>   while (i--)
>   cfg->smendx[i] = INVALID_SMENDX;
>  
> - ret = arm_smmu_master_alloc_smes(dev);
> + ret = pm_runtime_get_sync(smmu->dev);
>   if (ret)
>   goto out_cfg_free;

Hey Vivek, I just hit a problem with this on sdm845. It turns out that
pm_runtime_get_sync() returns a positive 1 if the device is already active.

I hit this in the GPU code. The a6xx has two platform devices that each use a
different sid on the iommu. The GPU is probed normally from a platform driver
and it in turn initializes the GMU device by way of a phandle.

Because the GMU isn't probed with a platform driver we need to call
of_dma_configure() on the device to set up the IOMMU for the device which ends
up calling through this path and we discover that the smmu->dev is already
powered (pm_runtime_get_sync returns 1).

I'm not immediately sure if this is a bug on sdm845 or not because a cursory
inspection says that the SMMU device shouldn't be powered at this time but there
might be a connection that I'm not seeing. Obviously if the SMMU was left
powered thats a bad thing. But putting that aside it is obvious that this
code should be accommodating of the possibility that the device is already
powered, and so this should be

if (ret < 0)
goto out_cfg_free;

With that the GPU/GMU successfully comes up on Sean Paul's display testing
branch.

Jordan

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

[Bug 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8

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

Bug ID: 105218
Summary: Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: blocker
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel@lists.freedesktop.org
Reporter: dark_syl...@yahoo.com.ar
QA Contact: dri-devel@lists.freedesktop.org

Our Terrain sample from Ogre 2.1 uses a compute shader to generate the shadows
of the terrain, and later uses a special vs & ps to render the terrain.

What's special about that sample over the rest (that run fine) are:

1. The compute shader that generates the shadows
(https://bitbucket.org/sinbad/ogre/src/09181053ca69f4760b655c2eed5b5ca7d62fd7bc/Samples/Media/2.0/scripts/materials/Tutorial_Terrain/GLSL/TerraShadowGenerator.glsl?at=v2-1=file-view-default).
The heigthmap is in format R16_UNORM, the generated shadows texture is in
RGB10A2
2. A PS that generates the normals
(https://bitbucket.org/sinbad/ogre/src/09181053ca69f4760b655c2eed5b5ca7d62fd7bc/Samples/Media/2.0/scripts/materials/Tutorial_Terrain/GLSL/GpuNormalMapper_ps.glsl?at=v2-1=file-view-default).
The normals' texture are in RGB10A2
3. The VS has no vertex buffer bound, but rather relies on gl_VertexID and
integer ops
(https://bitbucket.org/sinbad/ogre/src/09181053ca69f4760b655c2eed5b5ca7d62fd7bc/Samples/Media/Hlms/Terra/GLSL/VertexShader_vs.glsl?at=v2-1=file-view-default#VertexShader_vs.glsl-66)
and reads the heightmap.

After commit 847d0a393d7f0f967f39302900d5330f32b804c8 and at least until latest
from today, running this sample causes an entire system freeze: Mouse cursor is
the only thing that responds. Keyboard does not respond, hard resetting is the
only way and tends to corrupt files in the drive (This was painful to bisect).

Before this commit the sample behaves as expected.

My GPU is a Radeon RX 560 2GB

I can provide a binary with the failing sample, or instructions on how to build
from source (https://ogrecave.github.io/ogre/api/2.1/SettingUpOgreLinux.html).
Whatever you need.

I'm flagging this as blocker because of the security implications of freezing
the entire system with ease.

Cheers

--
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 105200] [r600g] Regression: ImageMagick OpenCL kernel no longer compiles

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

--- Comment #1 from Jan Vesely  ---
(In reply to nixscripter from comment #0)
> Created attachment 137519 [details]
> The ImageMagick OpenCL Kernel
> 
> LLVM svn version: 325439
> Mesa version: git fa8a764b62
> 
> The last version that worked was several weeks ago -- prior to the LLVM 6
> branch.
> 
> The log is so short, I can paste it in here:
> 
> build options: -cl-single-precision-constant -cl-mad-enable
> -DMAGICKCORE_HDRI_SUPPORT=1 -DCLQuantum=float -DCLSignedQuantum=float
> -DCLPixelType=float4 -DQuantumRange=65535.00 -DQuantumScale=0.15
> -DCharQuantumScale=1.00 -DMagickEpsilon=0.00 -DMagickPI=3.141593 
> -DMaxMap=65535 -DMAGICKCORE_QUANTUM_DEPTH=16
> :0:0: in function AddNoise void (<4 x float> addrspace(1)*, <4 x
> float> addrspace(1)*, i32, i32, i32, i32, float, i32, i32, i32): unsupported
> initializer for address space
> 
> The unknown is because I have a stripped binary. I have not done all the
> manual rebuilds for the symbols yet.
> 
> The actual kernel being compiled is attached. Hopefully it should be obvious
> enough what the problem is.

well, not really. AS error suggests that this is a fallout of r325030 and
you'll need to update and rebuild libclc.

-- 
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 libdrm v2] *-symbol-check: Don't hard-code nm executable

Eric Engestrom  writes:

> From: Heiko Becker 
>
> Helpful if your nm executable has a prefix based on the
> architecture, for example.
>
> Signed-off-by: Heiko Becker 
> Cc: Timo Gurr 
> [Eric: v2: rebase and add Meson support]
> Signed-off-by: Eric Engestrom 

Reviewed-by: Eric Anholt 


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/p[111: add CONFIG_OF dependency

2018-02-22 Thread Arnd Bergmann

On Thu, Feb 22, 2018 at 9:08 PM, Eric Anholt  wrote:
> Arnd Bergmann  writes:
>
>> We cannot select a symbol without meeting its other dependencies:
>>
>> warning: (DRM_PL111) selects DRM_DUMB_VGA_DAC which has unmet direct 
>> dependencies (HAS_IOMEM && DRM && DRM_BRIDGE && OF)
>> drivers/gpu/drm/bridge/dumb-vga-dac.c: In function 'dumb_vga_probe':
>> drivers/gpu/drm/bridge/dumb-vga-dac.c:207:13: error: 'struct drm_bridge' has 
>> no member named 'of_node'
>>   vga->bridge.of_node = pdev->dev.of_node;
>>  ^
>>
>> Here it seems reasonable to depend on CONFIG_OF, as all platforms
>> using this driver already require that anyway.
>
> Looks like we'll be going with
>
> https://patchwork.freedesktop.org/patch/205580/

Ok, even better!

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

Re: [PATCH v6 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

2018-02-22 Thread Laurent Pinchart

Hi Frank,

On Friday, 23 February 2018 00:10:17 EET Frank Rowand wrote:
> Hi Laurent, Rob,
> 
> Thanks for the prompt spin to address my concerns.  There are some small
> technical issues.
> 
> I did not read the v3 patch until today.  v3 through v6 are still using the
> old overlay apply method which uses an expanded device tree as input.
> 
> Rob, I don't see my overlay patches in you for-next branch, and I have
> not seen an "Applied" message from you.  What is the status of the
> overlay patches?
> 
> Comments in the patch below.
> 
> On 02/22/18 05:13, Laurent Pinchart wrote:
> > The internal LVDS encoders now have their own DT bindings. Before
> > switching the driver infrastructure to those new bindings, implement
> > backward-compatibility through live DT patching.
> > 
> > Patching is disabled and will be enabled along with support for the new
> > DT bindings in the DU driver.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > Changes since v5:
> > 
> > - Use a private copy of rcar_du_of_changeset_add_property()
> > 
> > Changes since v3:
> > 
> > - Use the OF changeset API
> > - Use of_graph_get_endpoint_by_regs()
> > - Replace hardcoded constants by sizeof()
> > 
> > Changes since v2:
> > 
> > - Update the SPDX headers to use C-style comments in header files
> > - Removed the manually created __local_fixups__ node
> > - Perform manual fixups on live DT instead of overlay
> > 
> > Changes since v1:
> > 
> > - Select OF_FLATTREE
> > - Compile LVDS DT bindings patch code when DRM_RCAR_LVDS is selected
> > - Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
> > - Turn __dtb_rcar_du_of_lvds_(begin|end) from u8 to char
> > - Pass void begin and end pointers to rcar_du_of_get_overlay()
> > - Use of_get_parent() instead of accessing the parent pointer directly
> > - Find the LVDS endpoints nodes based on the LVDS node instead of the
> > 
> >   root of the overlay
> > 
> > - Update to the -lvds compatible string format
> > ---
> > 
> >  drivers/gpu/drm/rcar-du/Kconfig|   2 +
> >  drivers/gpu/drm/rcar-du/Makefile   |   7 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_of.c   | 342 
> >  drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 ++
> >  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  79 +
> >  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  53 
> >  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  53 
> >  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts|  53 
> >  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts|  53 
> >  9 files changed, 661 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
> >  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
> >  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
> >  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts
> >  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts
> >  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts
> >  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts

[snip]

> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_of.c new file mode 100644
> > index ..ac442ddfed16
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c

[snip]

> > +static int __init rcar_du_of_apply_overlay(const struct
> > rcar_du_of_overlay *dtbs,
> > +  const char *compatible)
> > +{
> > +   const struct rcar_du_of_overlay *dtb = NULL;
> > +   struct device_node *node = NULL;
> > +   unsigned int i;
> > +   int ovcs_id;
> > +   void *data;
> > +   void *mem;
> > +   int ret;
> > +
> > +   for (i = 0; dtbs[i].compatible; ++i) {
> > +   if (!strcmp(dtbs[i].compatible, compatible)) {
> > +   dtb = [i];
> > +   break;
> > +   }
> > +   }
> > +
> > +   if (!dtb)
> > +   return -ENODEV;
> 
> __If__ my overlay patches are accepted, this block:
> 
> > +
> > +   data = kmemdup(dtb->begin, dtb->end - dtb->begin, GFP_KERNEL);
> > +   if (!data)
> > +   return -ENOMEM;
> > +
> > +   mem = of_fdt_unflatten_tree(data, NULL, );
> > +   if (!mem) {
> > +   ret = -ENOMEM;
> > +   goto done;
> > +   }
> > +
> > +   ovcs_id = 0;
> > +   ret = of_overlay_apply(node, _id);
> > +
> > +done:
> > +   of_node_put(node);
> > +   kfree(data);
> > +   kfree(mem);
> 
> becomes:
> 
>   ret = of_overlay_fdt_apply(dtb->begin, _id);

I tried to rework this patch in a way that would make switching to FDT 
overlays easy, and I'm glad to hear I haven't done a too bad job :-)

Are your patches scheduled for merge in v4.17 ? If so, is it possible to get 
apply them in a stable branch on top of v4.16-rc1 that can be merged as a 
dependency for this series ? There are changes to the Renesas DT queued for 
merge

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

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

Jan Vesely  changed:

   What|Removed |Added

 Depends on||105200


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=105200
[Bug 105200] [r600g] Regression: ImageMagick OpenCL kernel no longer compiles
-- 
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 105200] [r600g] Regression: ImageMagick OpenCL kernel no longer compiles

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

Jan Vesely  changed:

   What|Removed |Added

 Blocks||99553


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99553
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

2018-02-22 Thread Ville Syrjala

From: Ville Syrjälä 

The documentation for the ctm matrix suggests a two's complement
format, but at least the i915 implementation is using sign-magnitude
instead. And looks like malidp is doing the same. Change the docs
to match the current implementation, and change the type from __s64
to __u64 to drive the point home.

Cc: dri-devel@lists.freedesktop.org
Cc: Mihail Atanassov 
Cc: Liviu Dudau 
Cc: Brian Starkey 
Cc: Mali DP Maintainers 
Cc: Johnson Lin 
Cc: Uma Shankar 
Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
 include/uapi/drm/drm_mode.h | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 2c575794fb52..b5d7d9e0eff5 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -598,8 +598,11 @@ struct drm_mode_crtc_lut {
 };
 
 struct drm_color_ctm {
-   /* Conversion matrix in S31.32 format. */
-   __s64 matrix[9];
+   /*
+* Conversion matrix in S31.32 sign-magnitude
+* (not two's complement!) format.
+*/
+   __u64 matrix[9];
 };
 
 struct drm_color_lut {
-- 
2.16.1

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

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

On Thu, Feb 22, 2018 at 1:49 PM, Bas Nieuwenhuizen
 wrote:
> On Thu, Feb 22, 2018 at 7:04 PM, Kristian Høgsberg  
> wrote:
>> On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher  wrote:
>>
>>> On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace 
>> wrote:
>>> > On Thu 21 Dec 2017, Daniel Vetter wrote:
>>> >> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen <
>> hoegsb...@google.com> wrote:
>>> >>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico <
>> mvicom...@nvidia.com> wrote:
>>>  On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg <
>> hoegsb...@gmail.com> wrote:
>>> > I'd like to see concrete examples of actual display controllers
>>> > supporting more format layouts than what can be specified with a 64
>>> > bit modifier.
>>> 
>>>  The main problem is our tiling and other metadata parameters can't
>>>  generally fit in a modifier, so we find passing a blob of metadata a
>>>  more suitable mechanism.
>>> >>>
>>> >>> I understand that you may have n knobs with a total of more than a
>> total of
>>> >>> 56 bits that configure your tiling/swizzling for color buffers. What
>> I don't
>>> >>> buy is that you need all those combinations when passing buffers
>> around
>>> >>> between codecs, cameras and display controllers. Even if you're
>> sharing
>>> >>> between the same 3D drivers in different processes, I expect just
>> locking
>>> >>> down, say, 64 different combinations (you can add more over time) and
>>> >>> assigning each a modifier would be sufficient. I doubt you'd extract
>>> >>> meaningful performance gains from going all the way to a blob.
>>> >
>>> > I agree with Kristian above. In my opinion, choosing to encode in
>>> > modifiers a precise description of every possible tiling/compression
>>> > layout is not technically incorrect, but I believe it misses the point.
>>> > The intention behind modifiers is not to exhaustively describe all
>>> > possibilites.
>>> >
>>> > I summarized this opinion in VK_EXT_image_drm_format_modifier,
>>> > where I wrote an "introdution to modifiers" section. Here's an excerpt:
>>> >
>>> > One goal of modifiers in the Linux ecosystem is to enumerate for
>> each
>>> > vendor a reasonably sized set of tiling formats that are
>> appropriate for
>>> > images shared across processes, APIs, and/or devices, where each
>>> > participating component may possibly be from different vendors.
>>> > A non-goal is to enumerate all tiling formats supported by all
>> vendors.
>>> > Some tiling formats used internally by vendors are inappropriate for
>>> > sharing; no modifiers should be assigned to such tiling formats.
>>
>>> Where it gets tricky is how to select that subset?  Our tiling mode
>>> are defined more by the asic specific constraints than the tiling mode
>>> itself.  At a high level we have basically 3 tiling modes (out of 16
>>> possible) that would be the minimum we'd want to expose for gfx6-8.
>>> gfx9 uses a completely new scheme.
>>> 1. Linear (per asic stride requirements, not usable by many hw blocks)
>>> 2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick)
>>> 3. 2D Thin (1D tiling constraints, plus pipe config (18 possible),
>>> tile split (7 possible), sample split (4 possible), num banks (4
>>> possible), bank width (4 possible), bank height (4 possible), macro
>>> tile aspect (4 possible) all of which are asic config specific)
>>
>>> I guess we could do something like:
>>> AMD_GFX6_LINEAR_ALIGNED_64B
>>> AMD_GFX6_LINEAR_ALIGNED_256B
>>> AMD_GFX6_LINEAR_ALIGNED_512B
>>> AMD_GFX6_1D_THIN_DISPLAY
>>> AMD_GFX6_1D_THIN_DEPTH
>>> AMD_GFX6_1D_THIN_ROTATED
>>> AMD_GFX6_1D_THIN_THIN
>>> AMD_GFX6_1D_THIN_THICK
>>
>> AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>>
>> AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>>
>> AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>>
>> AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>>
>> AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>>
>> AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>>
>> AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>>
>> AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>>
>>

[Bug 105213] [SUMO][TURKS] Alien: Isolation rendering artifacts

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

Bug ID: 105213
   Summary: [SUMO][TURKS] Alien: Isolation rendering artifacts
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: russianneuroman...@ya.ru
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 137537
  --> https://bugs.freedesktop.org/attachment.cgi?id=137537=edit
Alien: Isolation rendering on TURKS with Mesa git

Hi!

With Mesa 18.1~git180219165200.f78fe98 in Alien: Isolation there is rendering
artifacts - please look into attached screenshot. Issue is reproducible on
Radeon HD 6620G and 6650M. 
Graphical settings is all set to minimal, all visual effects is disabled.

Kubuntu 17.10 x86_64, Linux 4.15.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

[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)

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

--- Comment #7 from Harry Wentland  ---
Luke, does your comment relate to driver unload, specifically driver unload
throwing NULL pointer dereference?

If not, please open a separate ticket so as not to confuse two issues.

-- 
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 hwc] drm_hwcomposer: set CRTC background color when available

Stefan Schake  writes:

> Android assumes an implicit black background layer is always present
> behind all layers it specifies for composition. drm_hwcomposer currently
> punts responsibility for this to the kernel/DRM platform and puts layers
> with per-pixel alpha content on the primary plane when requested.
>
> On some platforms (e.g. VC4) a background color fill has a cycle cost for
> the hardware composer and is not enabled by default. Instead, userland can
> request a background color through a CRTC property. Use this property to
> specify the implicit black background Android expects.
>
> Signed-off-by: Stefan Schake 
> ---
> Kernel changes for this (background_color) are available here:
>
> https://github.com/stschake/linux/commits/background-upstream
>
> Sending as RFC because I'm not entirely clear on whose responsibility
> this should be, on most DRM drivers it seems to be implicit. I think
> a case could also be made that VC4 should not accept alpha formats on
> the lowest layer or enable background color fill when given one anyway.
> On the other hand, userland control over background color seems desirable
> regardless and is a feature of multiple hardware composers (i915, vc4, omap).

Couldn't we just ignore the alpha channel on the primary plane, on the
assumption that it's supposed to be all zeroes below it?  Or are we not
premultiplied, so we do still need to multiply the primary plane's
colors by the alpha value?  I couldn't find any obvious DRM
documentation about whether alpha is premultiplied.


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

[Bug 105177] amdgpu wrong colors with rx460 connected via hdmi

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

--- Comment #13 from Harry Wentland  ---
Created attachment 137536
  --> https://bugs.freedesktop.org/attachment.cgi?id=137536=edit
[PATCH] update infoframe after dig fe is turned on

This patch should fix your issue. Please let me know if you try it.

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

Re: [PATCH 3/3] drm/pl111: Use max memory bandwidth for resolution

Linus Walleij  writes:

> We were previously selecting 1024x768 and 32BPP as the default
> set-up for the PL111 consumers.
>
> This does not work on elder systems: the device tree bindings
> support a property "max-memory-bandwidth" in bytes/second that
> states that if you exceed this the memory bus will saturate.
> The result is flickering and unstable images.
>
> Parse the "max-memory-bandwidth" and respect it when
> intializing the driver. On the RealView PB11MP, Versatile and
> Integrator/CP we get a nice console as default with this code.
>
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Exploit the new .mode_valid() callback we added to the
>   simple KMS helper.
> - Use the hardcoded bits per pixel per variant instead of
>   trying to be heuristic about this setting for now.
> ---
>  drivers/gpu/drm/pl111/pl111_display.c | 30 ++
>  drivers/gpu/drm/pl111/pl111_drm.h |  1 +
>  drivers/gpu/drm/pl111/pl111_drv.c |  6 ++
>  3 files changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
> b/drivers/gpu/drm/pl111/pl111_display.c
> index d75923896609..a1ca9e1ffe15 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c

> + if (bw > priv->memory_bw) {
> + DRM_DEBUG("%d x %d @ %d Hz, %d cpp, bw %llu too fast\n",
> +   mode->hdisplay, mode->vdisplay, mode->clock, cpp, bw);
> +
> + return MODE_BAD;
> + }

Oh, hey, on platforms with no memory-bandwidth property, we should make
sure not to reject all modes :)


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

Re: [PATCH v6 0/4] R-Car DU: Convert LVDS code to bridge driver

2018-02-22 Thread Laurent Pinchart

Hi Frank,

On Thursday, 22 February 2018 22:23:20 EET Frank Rowand wrote:
> On 02/22/18 05:13, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series addresses a design mistake that dates back from the
> > initial DU support. Support for the LVDS encoders, which are IP cores
> > separate from the DU, was bundled in the DU driver. Worse, both the DU
> > and LVDS were described through a single DT node.
> > 
> > To fix the, patches 1/4 and 2/4 define new DT bindings for the LVDS
> > encoders, and deprecate their description inside the DU bindings. To
> > retain backward compatibility with existing DT, patch 3/4 then patch the
> > device tree at runtime to convert the legacy bindings to the new ones.
> > 
> > With the DT side addressed, patch 4/4 converts the LVDS support code to a
> > separate bridge driver.
> > 
> > I decided to go for live DT patching in patch 3/4 because implementing
> > support for both the legacy and new bindings in the driver would have been
> > very intrusive, and prevented further cleanups. This version relies more
> > heavily on overlays to avoid touching the internals of the OF core
> > compared to v2, even if manual fixes to the device tree are still needed.
> > 
> > As all the patches but the last one have been acked, I plan to send a pull
> > request by the end of the week if no new issue is discovered.
> > 
> > Compared to v5, I've dropped the OF changeset halpers series as Frank
> > raised concerns about hidding it in the middle of a driver patch series.
> > I've thus copied the implementation of of_changeset_add_property_copy()
> > in the driver to avoid blocking this series. The function arguments are
> > identical, so when the OF changeset helpers will land it will be very
> > easy to drop the private copy and use the
> > of_changeset_add_property_copy() helper.
> 
> Thank you Laurent.
> 
> My issues with that are procedural, and I'll reply later about this in the
> v4 patch thread, where I raised the issue.  (For the peanut gallery, I
> replied in thread v4 _after_ Laurent sent v5, so Laurent did not ignore
> me in v5.)

I would have waited for your ack anyway :-)

> My technical comments are more relevent than my process comments, in terms
> of helping Laurent get his driver submitted, so I will delay the process
> comments.

Thank you. 

> My technical comments will be in reply to patch 3/4.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm/pl111: Remove reverse dependency on DRM_DUMB_VGA_DAC

Thierry Reding  writes:

> From: Thierry Reding 
>
> DRM_DUMB_VGA_DAC is a user-visible symbol. Selecting it can cause unmet
> direct dependencies such as this (on i386, randconfig):
>
>   warning: (DRM_PL111) selects DRM_DUMB_VGA_DAC which has unmet direct 
> dependencies (HAS_IOMEM && DRM && DRM_BRIDGE && OF)
>
> This is because DRM_DUMB_VGA_DAC depends on OF while DRM_PL111 does not.
> It does indirectly depend on OF via the ARM and ARM64 dependencies, but
> since it can also be enabled under COMPILE_TEST, randconfig can find a
> case where DRM_PL111 is selected without pulling in OF and not meeting
> the dependency for DRM_DUMB_VGA_DAC.
>
> Since select is "heavy handed", DRM_DUMB_VGA_DAC is going to be enabled
> regardless of the above warning and causes the following build error:
>
>   ../drivers/gpu/drm/bridge/dumb-vga-dac.c: In function 'dumb_vga_probe':
>   ../drivers/gpu/drm/bridge/dumb-vga-dac.c:207:13: error: 'struct 
> drm_bridge' has no member named 'of_node'
> vga->bridge.of_node = pdev->dev.of_node;
>
> See Documentation/kbuild/kconfig-language.txt, "reverse dependencies".
>
> Fixes: 49f81d80ab84 ("drm/pl111: Support handling bridge timings")
> Reported-by: Randy Dunlap 
> Cc: Laurent Pinchart 
> Cc: Archit Taneja 
> Cc: Eric Anholt 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/pl111/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> index 82cb3e60ddc8..e5e2abd66491 100644
> --- a/drivers/gpu/drm/pl111/Kconfig
> +++ b/drivers/gpu/drm/pl111/Kconfig
> @@ -8,7 +8,6 @@ config DRM_PL111
>   select DRM_GEM_CMA_HELPER
>   select DRM_BRIDGE
>   select DRM_PANEL_BRIDGE
> - select DRM_DUMB_VGA_DAC
>   select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>   help
> Choose this option for DRM support for the PL111 CLCD controller.
> -- 
> 2.15.1

Reviewed-by: Eric Anholt 


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

[RFC v3 11/12] drm/client: Add bootsplash client

Just a hack to test the client API.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/client/Kconfig  |   5 +
 drivers/gpu/drm/client/Makefile |   1 +
 drivers/gpu/drm/client/drm_bootsplash.c | 205 
 3 files changed, 211 insertions(+)
 create mode 100644 drivers/gpu/drm/client/drm_bootsplash.c

diff --git a/drivers/gpu/drm/client/Kconfig b/drivers/gpu/drm/client/Kconfig
index 73902ab44c75..16cf1e14620a 100644
--- a/drivers/gpu/drm/client/Kconfig
+++ b/drivers/gpu/drm/client/Kconfig
@@ -17,4 +17,9 @@ config DRM_CLIENT_FBDEV
help
  Generic fbdev emulation
 
+config DRM_CLIENT_BOOTSPLASH
+   tristate "DRM Bootsplash"
+   help
+ DRM Bootsplash
+
 endmenu
diff --git a/drivers/gpu/drm/client/Makefile b/drivers/gpu/drm/client/Makefile
index 3ff694429dec..8660530e4646 100644
--- a/drivers/gpu/drm/client/Makefile
+++ b/drivers/gpu/drm/client/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 
 obj-$(CONFIG_DRM_CLIENT_FBDEV) += drm_fbdev.o
+obj-$(CONFIG_DRM_CLIENT_BOOTSPLASH) += drm_bootsplash.o
diff --git a/drivers/gpu/drm/client/drm_bootsplash.c 
b/drivers/gpu/drm/client/drm_bootsplash.c
new file mode 100644
index ..43c703606e74
--- /dev/null
+++ b/drivers/gpu/drm/client/drm_bootsplash.c
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct drm_bootsplash {
+   struct drm_client_dev *client;
+   struct drm_client_display *display;
+   struct drm_client_buffer *buffer[2];
+   struct work_struct worker;
+   bool stop;
+};
+
+static u32 drm_bootsplash_color_table[3] = {
+   0x00ff, 0xff00, 0x00ff,
+};
+
+/* Draw a box with changing colors */
+static void
+drm_bootsplash_draw(struct drm_client_buffer *buffer, unsigned int sequence)
+{
+   unsigned int x, y;
+   u32 *pix;
+
+   pix = buffer->vaddr;
+   pix += ((buffer->height / 2) - 50) * buffer->width;
+   pix += (buffer->width / 2) - 50;
+
+   for (y = 0; y < 100; y++) {
+   for (x = 0; x < 100; x++)
+   *pix++ = drm_bootsplash_color_table[sequence];
+   pix += buffer->width - 100;
+   }
+}
+
+static void drm_bootsplash_worker(struct work_struct *work)
+{
+   struct drm_bootsplash *splash = container_of(work, struct 
drm_bootsplash,
+worker);
+   struct drm_event *event;
+   unsigned int i = 0, sequence = 0, fb_id;
+   int ret;
+
+   while (!splash->stop) {
+   /* Are we still in charge? */
+   fb_id = drm_client_display_current_fb(splash->display);
+   if (fb_id != splash->buffer[i]->fb_ids[0])
+   break;
+
+   /*
+* We can race with userspace here between checking and doing
+* the page flip, so double buffering isn't such a good idea.
+* Tearing probably isn't a problem on a presumably small splash
+* animation. I've kept it to test the page flip code.
+*/
+
+   i = !i;
+   drm_bootsplash_draw(splash->buffer[i], sequence++);
+   if (sequence == 3)
+   sequence = 0;
+
+   ret = drm_client_display_page_flip(splash->display,
+  splash->buffer[i]->fb_ids[0],
+  true);
+   if (!ret) {
+   event = drm_client_read_event(splash->client, true);
+   if (!IS_ERR(event))
+   kfree(event);
+   }
+   msleep(500);
+   }
+
+   for (i = 0; i < 2; i++)
+   drm_client_framebuffer_delete(splash->buffer[i]);
+   drm_client_display_free(splash->display);
+}
+
+static int drm_bootsplash_setup(struct drm_bootsplash *splash)
+{
+   struct drm_client_dev *client = splash->client;
+   struct drm_client_buffer *buffer[2];
+   struct drm_client_display *display;
+   struct drm_mode_modeinfo *mode;
+   int ret, i;
+
+   display = drm_client_display_get_first_enabled(client, false);
+   if (IS_ERR(display))
+   return PTR_ERR(display);
+   if (!display)
+   return -ENOENT;
+
+   mode = drm_client_display_first_mode(display);
+   if (!mode) {
+   ret = -EINVAL;
+   goto err_free_display;
+   }
+
+   for (i = 0; i < 2; i++) {
+   buffer[i] = drm_client_framebuffer_create(client, mode,
+ DRM_FORMAT_XRGB);
+   if (IS_ERR(buffer[i])) {
+   ret = PTR_ERR(buffer[i]);
+   goto err_free_buffer;
+   }
+   }
+
+

[RFC v3 10/12] drm/client: Add fbdev emulation client

This adds generic fbdev emulation for drivers that support the
dumb buffer API. No fbdev code is necessary in the driver.

Differences from drm_fb_helper:
- The backing buffer is created when the first fd is opened.
- Supports changing the mode from userspace.
- Doesn't restore on lastclose if there is no fd/fbcon open.
- Supports changing the buffer size (yres_virtual) from userspace before
  the fd is opened (double/trippel/... buffering).
- Panning is only supported as page flipping, so no partial offset.
- Supports real page flipping with FBIO_WAITFORVSYNC waiting on the
  actual flip.
- Supports framebuffer flushing for fbcon on buffers that doesn't support
  fbdev deferred I/O (shmem). mmap doesn't work but fbcon does.

TODO:
- suspend/resume
- sysrq
- Look more into plane format selection/support.
- Need a way for the driver to say that it wants generic fbdev emulation.
  The client .new hook is run in drm_dev_register() which is before
  drivers set up fbdev themselves. So the client can't look at
  drm_device->fb_helper to find out.
- Do we need to support FB_VISUAL_PSEUDOCOLOR?

TROUBLE:
- fbcon can't handle fb_open returning an error, it just heads on. This
  results in a NULL deref in fbcon_init(). fbcon/vt is awful when it
  comes to error handling. It doesn't look to be easily fixed, so I guess
  a buffer has to be pre-allocated to ensure health and safety.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/client/Kconfig |  16 +
 drivers/gpu/drm/client/Makefile|   2 +
 drivers/gpu/drm/client/drm_fbdev.c | 997 +
 3 files changed, 1015 insertions(+)
 create mode 100644 drivers/gpu/drm/client/drm_fbdev.c

diff --git a/drivers/gpu/drm/client/Kconfig b/drivers/gpu/drm/client/Kconfig
index 4bb8e4655ff7..73902ab44c75 100644
--- a/drivers/gpu/drm/client/Kconfig
+++ b/drivers/gpu/drm/client/Kconfig
@@ -1,4 +1,20 @@
 menu "DRM Clients"
depends on DRM
 
+config DRM_CLIENT_FBDEV
+   tristate "Generic fbdev emulation"
+   depends on DRM
+   select FB
+   select FRAMEBUFFER_CONSOLE if !EXPERT
+   select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
+   select FB_SYS_FOPS
+   select FB_SYS_FILLRECT
+   select FB_SYS_COPYAREA
+   select FB_SYS_IMAGEBLIT
+   select FB_DEFERRED_IO
+   select FB_MODE_HELPERS
+   select VIDEOMODE_HELPERS
+   help
+ Generic fbdev emulation
+
 endmenu
diff --git a/drivers/gpu/drm/client/Makefile b/drivers/gpu/drm/client/Makefile
index f66554cd5c45..3ff694429dec 100644
--- a/drivers/gpu/drm/client/Makefile
+++ b/drivers/gpu/drm/client/Makefile
@@ -1 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_DRM_CLIENT_FBDEV) += drm_fbdev.o
diff --git a/drivers/gpu/drm/client/drm_fbdev.c 
b/drivers/gpu/drm/client/drm_fbdev.c
new file mode 100644
index ..e28416d72de1
--- /dev/null
+++ b/drivers/gpu/drm/client/drm_fbdev.c
@@ -0,0 +1,997 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright 2018 Noralf Trønnes
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct drm_fbdev {
+   struct mutex lock;
+
+   struct drm_client_dev *client;
+   struct drm_client_display *display;
+
+   unsigned int open_count;
+   struct drm_client_buffer *buffer;
+   bool page_flip_sent;
+   u32 curr_fb;
+
+   struct fb_info *info;
+   u32 pseudo_palette[17];
+
+   bool flush;
+   bool defio_no_flushing;
+   struct drm_clip_rect dirty_clip;
+   spinlock_t dirty_lock;
+   struct work_struct dirty_work;
+};
+
+static int drm_fbdev_mode_to_fb_mode(struct drm_device *dev,
+struct drm_mode_modeinfo *mode,
+struct fb_videomode *fb_mode)
+{
+   struct drm_display_mode display_mode = { };
+   struct videomode videomode = { };
+   int ret;
+
+   ret = drm_mode_convert_umode(dev, _mode, mode);
+   if (ret)
+   return ret;
+
+   memset(fb_mode, 0, sizeof(*fb_mode));
+   drm_display_mode_to_videomode(_mode, );
+   fb_videomode_from_videomode(, fb_mode);
+
+   return 0;
+}
+
+static void drm_fbdev_destroy_modelist(struct fb_info *info)
+{
+   struct fb_modelist *modelist, *tmp;
+
+   list_for_each_entry_safe(modelist, tmp, >modelist, list) {
+   kfree(modelist->mode.name);
+   list_del(>list);
+   kfree(modelist);
+   }
+}
+
+static void drm_fbdev_use_first_mode(struct fb_info *info)
+{
+   struct fb_modelist *modelist;
+
+   modelist = list_first_entry(>modelist, struct fb_modelist, list);
+   fb_videomode_to_var(>var, >mode);
+   info->mode = >mode;
+}
+
+static struct drm_mode_modeinfo *drm_fbdev_get_drm_mode(struct drm_fbdev 
*fbdev)
+{
+   struct drm_mode_modeinfo *mode_pos, *mode = NULL;
+   struct

[RFC v3 12/12] drm/client: Add VT console client

Just a hack to test the client API.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/client/Kconfig |   5 +
 drivers/gpu/drm/client/Makefile|   1 +
 drivers/gpu/drm/client/drm_vtcon.c | 760 +
 3 files changed, 766 insertions(+)
 create mode 100644 drivers/gpu/drm/client/drm_vtcon.c

diff --git a/drivers/gpu/drm/client/Kconfig b/drivers/gpu/drm/client/Kconfig
index 16cf1e14620a..50ce88515b65 100644
--- a/drivers/gpu/drm/client/Kconfig
+++ b/drivers/gpu/drm/client/Kconfig
@@ -22,4 +22,9 @@ config DRM_CLIENT_BOOTSPLASH
help
  DRM Bootsplash
 
+config DRM_CLIENT_VTCON
+   tristate "DRM VT console"
+   help
+ DRM VT console
+
 endmenu
diff --git a/drivers/gpu/drm/client/Makefile b/drivers/gpu/drm/client/Makefile
index 8660530e4646..47c8eaee5dab 100644
--- a/drivers/gpu/drm/client/Makefile
+++ b/drivers/gpu/drm/client/Makefile
@@ -2,3 +2,4 @@
 
 obj-$(CONFIG_DRM_CLIENT_FBDEV) += drm_fbdev.o
 obj-$(CONFIG_DRM_CLIENT_BOOTSPLASH) += drm_bootsplash.o
+obj-$(CONFIG_DRM_CLIENT_VTCON) += drm_vtcon.o
diff --git a/drivers/gpu/drm/client/drm_vtcon.c 
b/drivers/gpu/drm/client/drm_vtcon.c
new file mode 100644
index ..19297d065509
--- /dev/null
+++ b/drivers/gpu/drm/client/drm_vtcon.c
@@ -0,0 +1,760 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright 2018 Noralf Trønnes
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* TODO Need a way to unbind */
+
+/* TODO: Scrolling */
+
+/*
+ * The code consists of 3 parts:
+ *
+ * 1. The DRM client
+ *Gets a display, uses the first mode to find a font,
+ *sets the max cols/rows and a matching text buffer.
+ *
+ * 2. The VT console
+ *Writes to the text buffer which consists of CGA colored characters.
+ *Schedules the worker when it needs rendering or blanking.
+ *
+ * 3. Worker
+ *Does modesetting, blanking and rendering.
+ *It takes a snapshot of the VT text buffer and renders the changes since
+ *last.
+ */
+
+struct drm_vtcon_vc {
+   struct mutex lock;
+
+   u16 *text_buf;
+   size_t buf_len;
+
+   unsigned int rows;
+   unsigned int cols;
+   unsigned int max_rows;
+   unsigned int max_cols;
+   const struct font_desc *font;
+   bool blank;
+   unsigned long cursor_blink_jiffies;
+};
+
+static struct drm_vtcon_vc *drm_vtcon_vc;
+
+struct drm_vtcon {
+   struct drm_client_dev *client;
+   struct drm_client_display *display;
+   struct drm_client_buffer *buffer;
+
+   unsigned int rows;
+   unsigned int cols;
+
+   u16 *text_buf[2];
+   size_t buf_len;
+   unsigned int buf_idx;
+   bool blank;
+};
+
+static struct drm_vtcon *vtcon_instance;
+
+#define drm_vtcon_debug(vc, fmt, ...) \
+   printk(KERN_DEBUG "%s[%u]: " fmt, __func__, vc->vc_num, ##__VA_ARGS__)
+
+/* CGA color palette: 4-bit RGBI: intense red green blue */
+static const u32 drm_vtcon_paletteX888[16] = {
+   0x, /*  0 black */
+   0x00aa, /*  1 blue */
+   0xaa00, /*  2 green */
+   0x, /*  3 cyan */
+   0x00aa, /*  4 red */
+   0x00aa00aa, /*  5 magenta */
+   0x00aa5500, /*  6 brown */
+   0x00aa, /*  7 light gray */
+   0x0055, /*  8 dark gray */
+   0x00ff, /*  9 bright blue */
+   0x0055ff55, /* 10 bright green */
+   0x0055, /* 11 bright cyan */
+   0x00ff, /* 12 bright red */
+   0x00ff55ff, /* 13 bright magenta */
+   0x0055, /* 14 yellow */
+   0x00ff  /* 15 white */
+};
+
+static void
+drm_vtcon_render_char(struct drm_vtcon *vtcon, unsigned int x, unsigned int y,
+ u16 cc, const struct font_desc *font)
+{
+   struct drm_client_buffer *buffer = vtcon->buffer;
+   unsigned int h, w;
+   const u8 *src;
+   void *dst;
+   u32 *pix;
+   u32 fg_col = drm_vtcon_paletteX888[(cc & 0x0f00) >> 8];
+   u32 bg_col = drm_vtcon_paletteX888[cc >> 12];
+
+   src = font->data + (cc & 0xff) * font->height;
+   dst = vtcon->buffer->vaddr + y * buffer->pitch + x * sizeof(u32);
+
+   for (h = 0; h < font->height; h++) {
+   u8 fontline = *(src + h);
+
+   pix = dst;
+   for (w = 0; w < font->width; w++)
+   pix[w] = fontline & BIT(7 - w) ? fg_col : bg_col;
+   dst += buffer->pitch;
+   }
+}
+
+static int drm_vtcon_modeset(struct drm_vtcon *vtcon, unsigned int cols,
+unsigned int rows, const struct font_desc *font)
+{
+   struct drm_client_display *display = vtcon->display;
+   struct drm_client_dev *client = vtcon->client;
+   struct drm_mode_modeinfo use_mode, *mode, *best_mode = NULL;
+   unsigned int best_cols = ~0, best_rows = ~0;
+   struct drm_client_buffer *buffer;
+   int ret;
+
+   DRM_DEV_INFO(client->dev->dev,

Re: [PATCH] drm/p[111: add CONFIG_OF dependency

Arnd Bergmann  writes:

> We cannot select a symbol without meeting its other dependencies:
>
> warning: (DRM_PL111) selects DRM_DUMB_VGA_DAC which has unmet direct 
> dependencies (HAS_IOMEM && DRM && DRM_BRIDGE && OF)
> drivers/gpu/drm/bridge/dumb-vga-dac.c: In function 'dumb_vga_probe':
> drivers/gpu/drm/bridge/dumb-vga-dac.c:207:13: error: 'struct drm_bridge' has 
> no member named 'of_node'
>   vga->bridge.of_node = pdev->dev.of_node;
>  ^
>
> Here it seems reasonable to depend on CONFIG_OF, as all platforms
> using this driver already require that anyway.

Looks like we'll be going with

https://patchwork.freedesktop.org/patch/205580/


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

[RFC v3 00/12] drm: Add generic fbdev emulation

This patchset explores the possibility of having generic fbdev emulation
in DRM for drivers that supports dumb buffers which they can export.

The change this time is that I have tried to do an in-kernel client API.
The intention was to have callbacks on the drm_file, but I gave up on
that mainly because I have to take a ref on the driver module since
drm_driver->postclose is called in drm_file_free(). This blocks DRM
driver module unload. Another reason is that the callback signalling new
drm_devices would have to be out-of-band so I put all the callbacks
together.

The patchset includes 3 different clients that I have done to see how it
is to use the API:
- fbdev
- bootsplash
- VT console

There is still work left to be done, but it would be nice to get some
feedback about the direction I have taken.

For readers I suggest to first look at the bootsplash client to see the
API in use. The client is very simple so it's an easy read.

Noralf.

Changes since version 2:
- Don't set drm master for in-kernel clients. (Daniel Vetter)
- Add in-kernel client API

Changes since version 1:
- Don't add drm_fb_helper_fb_open() and drm_fb_helper_fb_release() to
  DRM_FB_HELPER_DEFAULT_OPS(). (Fi.CI.STATIC)
  The following uses that macro and sets fb_open/close: udlfb_ops,
  amdgpufb_ops, drm_fb_helper_generic_fbdev_ops, nouveau_fbcon_ops,
  nouveau_fbcon_sw_ops, radeonfb_ops.
  This results in: warning: Initializer entry defined twice
- Support CONFIG_DRM_KMS_HELPER=m (kbuild test robot)
  ERROR:  [drivers/gpu/drm/drm_kms_helper.ko] undefined!
- Drop buggy patch: (Chris Wilson)
  drm/prime: Clear drm_gem_object->dma_buf on release
- Defer buffer creation until fb_open.

David Herrmann (1):
  drm: provide management functions for drm_file

Noralf Trønnes (11):
  drm/file: Don't set master on in-kernel clients
  drm: Make ioctls available for in-kernel clients part 1
  drm: Make ioctls available for in-kernel clients part 2
  drm: Add _ioctl suffix to some functions
  drm: Add DRM device iterator
  drm/modes: Add drm_umode_equal()
  drm/framebuffer: Add drm_mode_can_dirtyfb()
  drm: Add API for in-kernel clients
  drm/client: Add fbdev emulation client
  drm/client: Add bootsplash client
  drm/client: Add VT console client

 drivers/gpu/drm/Kconfig |2 +
 drivers/gpu/drm/Makefile|3 +-
 drivers/gpu/drm/client/Kconfig  |   30 +
 drivers/gpu/drm/client/Makefile |5 +
 drivers/gpu/drm/client/drm_bootsplash.c |  205 
 drivers/gpu/drm/client/drm_client.c | 1612 +++
 drivers/gpu/drm/client/drm_fbdev.c  |  997 +++
 drivers/gpu/drm/client/drm_vtcon.c  |  760 +++
 drivers/gpu/drm/drm_connector.c |   50 +-
 drivers/gpu/drm/drm_crtc.c  |   47 +-
 drivers/gpu/drm/drm_crtc_internal.h |   80 +-
 drivers/gpu/drm/drm_drv.c   |   66 ++
 drivers/gpu/drm/drm_dumb_buffers.c  |   33 +-
 drivers/gpu/drm/drm_encoder.c   |   10 +-
 drivers/gpu/drm/drm_file.c  |  304 +++---
 drivers/gpu/drm/drm_framebuffer.c   |  149 ++-
 drivers/gpu/drm/drm_internal.h  |7 +
 drivers/gpu/drm/drm_ioc32.c |2 +-
 drivers/gpu/drm/drm_ioctl.c |   24 +-
 drivers/gpu/drm/drm_mode_config.c   |   81 +-
 drivers/gpu/drm/drm_mode_object.c   |   12 +-
 drivers/gpu/drm/drm_modes.c |   50 +
 drivers/gpu/drm/drm_plane.c |   24 +-
 drivers/gpu/drm/drm_prime.c |   13 +-
 drivers/gpu/drm/drm_probe_helper.c  |3 +
 drivers/gpu/drm/drm_vblank.c|   11 +-
 include/drm/drm_client.h|  192 
 include/drm/drm_device.h|1 +
 include/drm/drm_drv.h   |   34 +
 include/drm/drm_file.h  |7 +
 include/drm/drm_framebuffer.h   |2 +
 include/drm/drm_modes.h |2 +
 32 files changed, 4515 insertions(+), 303 deletions(-)
 create mode 100644 drivers/gpu/drm/client/Kconfig
 create mode 100644 drivers/gpu/drm/client/Makefile
 create mode 100644 drivers/gpu/drm/client/drm_bootsplash.c
 create mode 100644 drivers/gpu/drm/client/drm_client.c
 create mode 100644 drivers/gpu/drm/client/drm_fbdev.c
 create mode 100644 drivers/gpu/drm/client/drm_vtcon.c
 create mode 100644 include/drm/drm_client.h

-- 
2.15.1

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

[RFC v3 05/12] drm: Add _ioctl suffix to some functions

Add _ioctl suffix to the remaining ioctl functions so they match up with
the others:
- drm_mode_addfb()
- drm_mode_getfb()
- drm_mode_getplane_res()
- drm_mode_getplane()
- drm_mode_setplane()

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_crtc_internal.h | 20 ++--
 drivers/gpu/drm/drm_framebuffer.c   | 12 ++--
 drivers/gpu/drm/drm_ioctl.c | 10 +-
 drivers/gpu/drm/drm_plane.c | 12 ++--
 4 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 45713af5a015..3a9dd1dae06e 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -192,14 +192,14 @@ int drm_mode_dirtyfb(struct drm_device *dev, struct 
drm_mode_fb_dirty_cmd *req,
 struct drm_file *file_priv, bool user);
 
 /* IOCTL */
-int drm_mode_addfb(struct drm_device *dev,
-  void *data, struct drm_file *file_priv);
+int drm_mode_addfb_ioctl(struct drm_device *dev,
+void *data, struct drm_file *file_priv);
 int drm_mode_addfb2_ioctl(struct drm_device *dev,
  void *data, struct drm_file *file_priv);
 int drm_mode_rmfb_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
-int drm_mode_getfb(struct drm_device *dev,
-  void *data, struct drm_file *file_priv);
+int drm_mode_getfb_ioctl(struct drm_device *dev,
+void *data, struct drm_file *file_priv);
 int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv);
 
@@ -235,12 +235,12 @@ int drm_mode_page_flip(struct drm_device *dev,
 void drm_bridge_detach(struct drm_bridge *bridge);
 
 /* IOCTL */
-int drm_mode_getplane_res(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-int drm_mode_getplane(struct drm_device *dev,
- void *data, struct drm_file *file_priv);
-int drm_mode_setplane(struct drm_device *dev,
- void *data, struct drm_file *file_priv);
+int drm_mode_getplane_res_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_priv);
+int drm_mode_getplane_ioctl(struct drm_device *dev,
+   void *data, struct drm_file *file_priv);
+int drm_mode_setplane_ioctl(struct drm_device *dev,
+   void *data, struct drm_file *file_priv);
 int drm_mode_cursor_ioctl(struct drm_device *dev,
  void *data, struct drm_file *file_priv);
 int drm_mode_cursor2_ioctl(struct drm_device *dev,
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index b41770d29e6c..ad8f7d308656 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -93,7 +93,7 @@ int drm_framebuffer_check_src_coords(uint32_t src_x, uint32_t 
src_y,
 }
 
 /**
- * drm_mode_addfb - add an FB to the graphics configuration
+ * drm_mode_addfb_ioctl - add an FB to the graphics configuration
  * @dev: drm device for the ioctl
  * @data: data pointer for the ioctl
  * @file_priv: drm file for the ioctl call
@@ -106,8 +106,8 @@ int drm_framebuffer_check_src_coords(uint32_t src_x, 
uint32_t src_y,
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int drm_mode_addfb(struct drm_device *dev,
-  void *data, struct drm_file *file_priv)
+int drm_mode_addfb_ioctl(struct drm_device *dev,
+void *data, struct drm_file *file_priv)
 {
struct drm_mode_fb_cmd *or = data;
struct drm_mode_fb_cmd2 r = {};
@@ -447,7 +447,7 @@ int drm_mode_rmfb_ioctl(struct drm_device *dev,
 }
 
 /**
- * drm_mode_getfb - get FB info
+ * drm_mode_getfb_ioctl - get FB info
  * @dev: drm device for the ioctl
  * @data: data pointer for the ioctl
  * @file_priv: drm file for the ioctl call
@@ -459,8 +459,8 @@ int drm_mode_rmfb_ioctl(struct drm_device *dev,
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int drm_mode_getfb(struct drm_device *dev,
-  void *data, struct drm_file *file_priv)
+int drm_mode_getfb_ioctl(struct drm_device *dev,
+void *data, struct drm_file *file_priv)
 {
struct drm_mode_fb_cmd *r = data;
struct drm_framebuffer *fb;
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 726fbdb8a4b0..f00bea8b0da3 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -618,11 +618,11 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, 
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, 
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
 
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES,

[RFC v3 09/12] drm: Add API for in-kernel clients

This adds an API for writing in-kernel clients.

TODO:
- Flesh out and complete documentation.
- Cloned displays is not tested.
- Complete tiled display support and test it.
- Test plug/unplug different monitors.
- A runtime knob to prevent clients from attaching for debugging purposes.
- Maybe a way to unbind individual client instances.
- Maybe take the sysrq support in drm_fb_helper and move it here somehow.
- Add suspend/resume callbacks.
  Does anyone know why fbdev requires suspend/resume?

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/Kconfig |2 +
 drivers/gpu/drm/Makefile|3 +-
 drivers/gpu/drm/client/Kconfig  |4 +
 drivers/gpu/drm/client/Makefile |1 +
 drivers/gpu/drm/client/drm_client.c | 1612 +++
 drivers/gpu/drm/drm_drv.c   |6 +
 drivers/gpu/drm/drm_file.c  |3 +
 drivers/gpu/drm/drm_probe_helper.c  |3 +
 include/drm/drm_client.h|  192 +
 include/drm/drm_device.h|1 +
 include/drm/drm_file.h  |7 +
 11 files changed, 1833 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/client/Kconfig
 create mode 100644 drivers/gpu/drm/client/Makefile
 create mode 100644 drivers/gpu/drm/client/drm_client.c
 create mode 100644 include/drm/drm_client.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index deeefa7a1773..d4ae15f9ee9f 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -154,6 +154,8 @@ config DRM_SCHED
tristate
depends on DRM
 
+source "drivers/gpu/drm/client/Kconfig"
+
 source "drivers/gpu/drm/i2c/Kconfig"
 
 source "drivers/gpu/drm/arm/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 50093ff4479b..8e06dc7eeca1 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
-   drm_syncobj.o drm_lease.o
+   drm_syncobj.o drm_lease.o client/drm_client.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
@@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB) += mxsfb/
 obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
 obj-$(CONFIG_DRM_PL111) += pl111/
 obj-$(CONFIG_DRM_TVE200) += tve200/
+obj-y  += client/
diff --git a/drivers/gpu/drm/client/Kconfig b/drivers/gpu/drm/client/Kconfig
new file mode 100644
index ..4bb8e4655ff7
--- /dev/null
+++ b/drivers/gpu/drm/client/Kconfig
@@ -0,0 +1,4 @@
+menu "DRM Clients"
+   depends on DRM
+
+endmenu
diff --git a/drivers/gpu/drm/client/Makefile b/drivers/gpu/drm/client/Makefile
new file mode 100644
index ..f66554cd5c45
--- /dev/null
+++ b/drivers/gpu/drm/client/Makefile
@@ -0,0 +1 @@
+# SPDX-License-Identifier: GPL-2.0
diff --git a/drivers/gpu/drm/client/drm_client.c 
b/drivers/gpu/drm/client/drm_client.c
new file mode 100644
index ..a633bf747316
--- /dev/null
+++ b/drivers/gpu/drm/client/drm_client.c
@@ -0,0 +1,1612 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright 2018 Noralf Trønnes
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drm_crtc_internal.h"
+#include "drm_internal.h"
+
+struct drm_client_funcs_entry {
+   struct list_head list;
+   const struct drm_client_funcs *funcs;
+};
+
+static LIST_HEAD(drm_client_list);
+static LIST_HEAD(drm_client_funcs_list);
+static DEFINE_MUTEX(drm_client_list_lock);
+
+static void drm_client_new(struct drm_device *dev,
+  const struct drm_client_funcs *funcs)
+{
+   struct drm_client_dev *client;
+   int ret;
+
+   lockdep_assert_held(_client_list_lock);
+
+   client = kzalloc(sizeof(*client), GFP_KERNEL);
+   if (!client)
+   return;
+
+   mutex_init(>lock);
+   client->dev = dev;
+   client->funcs = funcs;
+
+   ret = funcs->new(client);
+   DRM_DEV_DEBUG_KMS(dev->dev, "%s: ret=%d\n", funcs->name, ret);
+   if (ret) {
+   drm_client_free(client);
+   return;
+   }
+
+   list_add(>list, _client_list);
+}
+
+/**
+ * drm_client_free - Free DRM client resources
+ * @client: DRM client
+ *
+ * This is called automatically on client removal unless the client returns
+ * non-zero in the _client_funcs->remove callback. The fbdev client does
+ * this when it can't close _file because userspace has an open fd.
+ */
+void drm_client_free(struct drm_client_dev *client)
+{
+   DRM_DEV_DEBUG_KMS(client->dev->dev, "%s\n", client->funcs->name);
+   if (WARN_ON(client->file)) {
+   client->file_ref_count = 1;
+   drm_client_put_file(client);
+   }
+

[RFC v3 01/12] drm: provide management functions for drm_file

From: David Herrmann 

Rather than doing drm_file allocation/destruction right in the fops, lets
provide separate helpers. This decouples drm_file management from the
still-mandatory drm-fops. It prepares for use of drm_file without the
fops, both by possible separate fops implementations and APIs (not that I
am aware of any such plans), and more importantly from in-kernel use where
no real file is available.

Signed-off-by: David Herrmann 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_file.c | 305 +++--
 drivers/gpu/drm/drm_internal.h |   2 +
 2 files changed, 175 insertions(+), 132 deletions(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index e394799979a6..d4588d33f91c 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -101,6 +101,175 @@ DEFINE_MUTEX(drm_global_mutex);
 
 static int drm_open_helper(struct file *filp, struct drm_minor *minor);
 
+/**
+ * drm_file_alloc - allocate file context
+ * @minor: minor to allocate on
+ *
+ * This allocates a new DRM file context. It is not linked into any context and
+ * can be used by the caller freely. Note that the context keeps a pointer to
+ * @minor, so it must be freed before @minor is.
+ *
+ * RETURNS:
+ * Pointer to newly allocated context, ERR_PTR on failure.
+ */
+struct drm_file *drm_file_alloc(struct drm_minor *minor)
+{
+   struct drm_device *dev = minor->dev;
+   struct drm_file *file;
+   int ret;
+
+   file = kzalloc(sizeof(*file), GFP_KERNEL);
+   if (!file)
+   return ERR_PTR(-ENOMEM);
+
+   file->pid = get_pid(task_pid(current));
+   file->minor = minor;
+
+   /* for compatibility root is always authenticated */
+   file->authenticated = capable(CAP_SYS_ADMIN);
+   file->lock_count = 0;
+
+   INIT_LIST_HEAD(>lhead);
+   INIT_LIST_HEAD(>fbs);
+   mutex_init(>fbs_lock);
+   INIT_LIST_HEAD(>blobs);
+   INIT_LIST_HEAD(>pending_event_list);
+   INIT_LIST_HEAD(>event_list);
+   init_waitqueue_head(>event_wait);
+   file->event_space = 4096; /* set aside 4k for event buffer */
+
+   mutex_init(>event_read_lock);
+
+   if (drm_core_check_feature(dev, DRIVER_GEM))
+   drm_gem_open(dev, file);
+
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_open(file);
+
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_prime_init_file_private(>prime);
+
+   if (dev->driver->open) {
+   ret = dev->driver->open(dev, file);
+   if (ret < 0)
+   goto out_prime_destroy;
+   }
+
+   if (drm_is_primary_client(file)) {
+   ret = drm_master_open(file);
+   if (ret)
+   goto out_close;
+   }
+
+   return file;
+
+out_close:
+   if (dev->driver->postclose)
+   dev->driver->postclose(dev, file);
+out_prime_destroy:
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_prime_destroy_file_private(>prime);
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_release(file);
+   if (drm_core_check_feature(dev, DRIVER_GEM))
+   drm_gem_release(dev, file);
+   put_pid(file->pid);
+   kfree(file);
+
+   return ERR_PTR(ret);
+}
+
+static void drm_events_release(struct drm_file *file_priv)
+{
+   struct drm_device *dev = file_priv->minor->dev;
+   struct drm_pending_event *e, *et;
+   unsigned long flags;
+
+   spin_lock_irqsave(>event_lock, flags);
+
+   /* Unlink pending events */
+   list_for_each_entry_safe(e, et, _priv->pending_event_list,
+pending_link) {
+   list_del(>pending_link);
+   e->file_priv = NULL;
+   }
+
+   /* Remove unconsumed events */
+   list_for_each_entry_safe(e, et, _priv->event_list, link) {
+   list_del(>link);
+   kfree(e);
+   }
+
+   spin_unlock_irqrestore(>event_lock, flags);
+}
+
+/**
+ * drm_file_free - free file context
+ * @file: context to free, or NULL
+ *
+ * This destroys and deallocates a DRM file context previously allocated via
+ * drm_file_alloc(). The caller must make sure to unlink it from any contexts
+ * before calling this.
+ *
+ * If NULL is passed, this is a no-op.
+ *
+ * RETURNS:
+ * 0 on success, or error code on failure.
+ */
+void drm_file_free(struct drm_file *file)
+{
+   struct drm_device *dev;
+
+   if (!file)
+   return;
+
+   dev = file->minor->dev;
+
+   DRM_DEBUG("pid = %d, device = 0x%lx, open_count = %d\n",
+ task_pid_nr(current),
+ (long)old_encode_dev(file->minor->kdev->devt),
+ dev->open_count);
+
+   if (drm_core_check_feature(dev,

[RFC v3 08/12] drm/framebuffer: Add drm_mode_can_dirtyfb()

Add a function so the generic fbdev client can check if the framebuffer
does flushing. This is needed to set up deferred I/O.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_framebuffer.c | 31 +++
 include/drm/drm_framebuffer.h |  2 ++
 2 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index ad8f7d308656..a659cff45844 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -600,6 +600,37 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
return drm_mode_dirtyfb(dev, data, file_priv, true);
 }
 
+/**
+ * drm_mode_can_dirtyfb - check if the FB does flushing
+ * @dev: drm device
+ * @fb_id: Framebuffer id
+ * @file_priv: drm file
+ *
+ * Returns:
+ * True if the framebuffer does flushing, false otherwise.
+ */
+bool drm_mode_can_dirtyfb(struct drm_device *dev, u32 fb_id,
+ struct drm_file *file_priv)
+{
+   struct drm_framebuffer *fb;
+   bool ret = false;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return false;
+
+   fb = drm_framebuffer_lookup(dev, file_priv, fb_id);
+   if (!fb)
+   return false;
+
+   if (fb->funcs->dirty)
+   ret = true;
+
+   drm_framebuffer_put(fb);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_mode_can_dirtyfb);
+
 /**
  * drm_fb_release - remove and free the FBs on this file
  * @priv: drm file for the ioctl
diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
index c50502c656e5..05d170f4e215 100644
--- a/include/drm/drm_framebuffer.h
+++ b/include/drm/drm_framebuffer.h
@@ -216,6 +216,8 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct 
drm_device *dev,
 void drm_framebuffer_remove(struct drm_framebuffer *fb);
 void drm_framebuffer_cleanup(struct drm_framebuffer *fb);
 void drm_framebuffer_unregister_private(struct drm_framebuffer *fb);
+bool drm_mode_can_dirtyfb(struct drm_device *dev, u32 fb_id,
+ struct drm_file *file_priv);
 
 /**
  * drm_framebuffer_get - acquire a framebuffer reference
-- 
2.15.1

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

[RFC v3 06/12] drm: Add DRM device iterator

Add functions for iterating the registered DRM devices.
This is done looping through the primary minors instead of using an
iter on drm_class which is also a possibility. The reason is that
drm_minor_acquire() takes a ref on the drm_device which is needed.

Another option would be to add a separate drm_device list.

Signed-off-by: Noralf Trønnes 
---

Does anyone know how I can make checkpatch happy, I've tried parentheses
around both dev and iter:

-:129: ERROR: Macros with complex values should be enclosed in parentheses
#129: FILE: include/drm/drm_drv.h:679:
+#define drm_for_each_device_iter(dev, iter) \
+   while ((dev = drm_device_list_iter_next(iter)))



 drivers/gpu/drm/drm_drv.c | 60 +++
 include/drm/drm_drv.h | 34 +++
 2 files changed, 94 insertions(+)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9acc1e157813..f869de185986 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -862,6 +862,66 @@ int drm_dev_set_unique(struct drm_device *dev, const char 
*name)
 }
 EXPORT_SYMBOL(drm_dev_set_unique);
 
+/**
+ * drm_device_list_iter_begin - Initialize a DRM device iterator
+ * @iter: DRM device iterator
+ *
+ * Sets @iter up to walk the registered DRM devices. @iter must always be
+ * cleaned up again by calling drm_device_list_iter_end(). Iteration itself
+ * happens using drm_device_list_iter_next() or drm_for_each_device_iter().
+ */
+void drm_device_list_iter_begin(struct drm_device_list_iter *iter)
+{
+   iter->dev = NULL;
+   iter->minor_id = 0;
+}
+EXPORT_SYMBOL(drm_device_list_iter_begin);
+
+/**
+ * drm_device_list_iter_next - Return the next DRM device
+ * @iter: DRM device iterator
+ *
+ * Returns the next DRM device for @iter, or NULL when there are no more
+ * devices.
+ */
+struct drm_device *
+drm_device_list_iter_next(struct drm_device_list_iter *iter)
+{
+   struct drm_minor *minor;
+
+   drm_dev_put(iter->dev);
+   iter->dev = NULL;
+
+   /* Loop through the primary minors */
+   for (; iter->minor_id < 64; iter->minor_id++) {
+   minor = drm_minor_acquire(iter->minor_id);
+   if (IS_ERR(minor))
+   continue;
+
+   iter->dev = minor->dev;
+   iter->minor_id++;
+   return minor->dev;
+   }
+
+   return NULL;
+}
+EXPORT_SYMBOL(drm_device_list_iter_next);
+
+/**
+ * drm_device_list_iter_end - Tear down a DRM device iterator
+ * @iter: DRM device iterator
+ *
+ * Tears down @iter and releases any resources (like _device references)
+ * acquired while walking the devices. This must always be called, both when
+ * the iteration completes fully or when it was aborted without walking the
+ * entire list.
+ */
+void drm_device_list_iter_end(struct drm_device_list_iter *iter)
+{
+   drm_dev_put(iter->dev);
+}
+EXPORT_SYMBOL(drm_device_list_iter_end);
+
 /*
  * DRM Core
  * The DRM core module initializes all global DRM objects and makes them
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index d32b688eb346..313a23ee7b30 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -644,5 +644,39 @@ static inline int drm_dev_is_unplugged(struct drm_device 
*dev)
 
 int drm_dev_set_unique(struct drm_device *dev, const char *name);
 
+/**
+ * struct drm_device_list_iter - DRM device iterator
+ *
+ * This iterator tracks state needed to be able to walk the registered
+ * DRM devices. Only use together with drm_device_list_iter_begin(),
+ * drm_device_list_iter_end() and drm_device_list_iter_next() respectively
+ * the convenience macro drm_for_each_device_iter().
+ */
+struct drm_device_list_iter {
+/* private: */
+   unsigned int minor_id;
+   struct drm_device *dev;
+};
+
+void drm_device_list_iter_begin(struct drm_device_list_iter *iter);
+struct drm_device *
+drm_device_list_iter_next(struct drm_device_list_iter *iter);
+void drm_device_list_iter_end(struct drm_device_list_iter *iter);
+
+/**
+ * drm_for_each_device_iter - DRM device iterator macro
+ * @dev: DRM device pointer used as cursor
+ * @iter: DRM device iterator
+ *
+ * Note that @dev is only valid within the list body, if you want to use @dev
+ * after calling drm_device_list_iter_end() then you need to grab your own
+ * reference first using drm_dev_get().
+ *
+ * Note:
+ * The DRM device was registered at the point when the reference was taken,
+ * but it's not guaranteed that this is still the case inside the loop.
+ */
+#define drm_for_each_device_iter(dev, iter) \
+   while ((dev = drm_device_list_iter_next(iter)))
 
 #endif
-- 
2.15.1

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

[RFC v3 02/12] drm/file: Don't set master on in-kernel clients

It only makes sense for userspace clients.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_file.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index d4588d33f91c..55505378df47 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -155,17 +155,8 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
goto out_prime_destroy;
}
 
-   if (drm_is_primary_client(file)) {
-   ret = drm_master_open(file);
-   if (ret)
-   goto out_close;
-   }
-
return file;
 
-out_close:
-   if (dev->driver->postclose)
-   dev->driver->postclose(dev, file);
 out_prime_destroy:
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_destroy_file_private(>prime);
@@ -365,6 +356,7 @@ static int drm_open_helper(struct file *filp, struct 
drm_minor *minor)
 {
struct drm_device *dev = minor->dev;
struct drm_file *priv;
+   int ret;
 
if (filp->f_flags & O_EXCL)
return -EBUSY;  /* No exclusive opens */
@@ -379,6 +371,14 @@ static int drm_open_helper(struct file *filp, struct 
drm_minor *minor)
if (IS_ERR(priv))
return PTR_ERR(priv);
 
+   if (drm_is_primary_client(priv)) {
+   ret = drm_master_open(priv);
+   if (ret) {
+   drm_file_free(priv);
+   return ret;
+   }
+   }
+
filp->private_data = priv;
priv->filp = filp;
 
-- 
2.15.1

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

[RFC v3 03/12] drm: Make ioctls available for in-kernel clients part 1

This is part 1 of making ioctls useable for in-kernel clients.
Make an ioctl wrapper function that calls a function that can be used by
in-kernel clients.

It adjusts the following functions to handle kernel buffers:
- drm_mode_getresources()
- drm_mode_setcrtc()
- drm_mode_getconnector()
- drm_mode_dirtyfb_ioctl()

There is no functional change from the userspace side.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_connector.c | 50 +++
 drivers/gpu/drm/drm_crtc.c  | 32 ++-
 drivers/gpu/drm/drm_crtc_internal.h | 23 ---
 drivers/gpu/drm/drm_framebuffer.c   | 56 +++--
 drivers/gpu/drm/drm_ioctl.c |  6 +--
 drivers/gpu/drm/drm_mode_config.c   | 81 +
 6 files changed, 164 insertions(+), 84 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..57c9c27ceb05 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1544,10 +1544,10 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
return true;
 }
 
-int drm_mode_getconnector(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+int drm_mode_getconnector(struct drm_device *dev,
+ struct drm_mode_get_connector *out_resp,
+ struct drm_file *file_priv, bool user)
 {
-   struct drm_mode_get_connector *out_resp = data;
struct drm_connector *connector;
struct drm_encoder *encoder;
struct drm_display_mode *mode;
@@ -1556,9 +1556,10 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
int ret = 0;
int copied = 0;
int i;
-   struct drm_mode_modeinfo u_mode;
-   struct drm_mode_modeinfo __user *mode_ptr;
-   uint32_t __user *encoder_ptr;
+   struct drm_mode_modeinfo __user *mode_ptr_user;
+   struct drm_mode_modeinfo u_mode, *mode_ptr;
+   uint32_t __user *encoder_ptr_user;
+   u32 *encoder_ptr;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -1575,13 +1576,18 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
 
if ((out_resp->count_encoders >= encoders_count) && encoders_count) {
copied = 0;
-   encoder_ptr = (uint32_t __user *)(unsigned 
long)(out_resp->encoders_ptr);
+   encoder_ptr_user = (uint32_t __user *)(unsigned 
long)(out_resp->encoders_ptr);
+   encoder_ptr = (u32 *)(unsigned long)(out_resp->encoders_ptr);
for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
if (connector->encoder_ids[i] != 0) {
-   if (put_user(connector->encoder_ids[i],
-encoder_ptr + copied)) {
-   ret = -EFAULT;
-   goto out;
+   if (user) {
+   if (put_user(connector->encoder_ids[i],
+encoder_ptr_user + 
copied)) {
+   ret = -EFAULT;
+   goto out;
+   }
+   } else {
+   encoder_ptr[copied] = 
connector->encoder_ids[i];
}
copied++;
}
@@ -1616,18 +1622,23 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
 */
if ((out_resp->count_modes >= mode_count) && mode_count) {
copied = 0;
-   mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned 
long)out_resp->modes_ptr;
+   mode_ptr_user = (struct drm_mode_modeinfo __user *)(unsigned 
long)out_resp->modes_ptr;
+   mode_ptr = (struct drm_mode_modeinfo *)(unsigned 
long)out_resp->modes_ptr;
list_for_each_entry(mode, >modes, head) {
if (!drm_mode_expose_to_userspace(mode, file_priv))
continue;
 
drm_mode_convert_to_umode(_mode, mode);
-   if (copy_to_user(mode_ptr + copied,
-_mode, sizeof(u_mode))) {
-   ret = -EFAULT;
-   mutex_unlock(>mode_config.mutex);
+   if (user) {
+   if (copy_to_user(mode_ptr_user + copied,
+_mode, sizeof(u_mode))) {
+   ret = -EFAULT;
+   mutex_unlock(>mode_config.mutex);
 
-   goto out;
+

[RFC v3 07/12] drm/modes: Add drm_umode_equal()

Add a way to check if userspace modes are equal. Useful for in-kernel
clients. Also export drm_mode_convert_umode().

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_modes.c | 50 +
 include/drm/drm_modes.h |  2 ++
 2 files changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 5a8033fda4e3..0e39164f15aa 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1631,6 +1631,56 @@ int drm_mode_convert_umode(struct drm_device *dev,
 out:
return ret;
 }
+EXPORT_SYMBOL(drm_mode_convert_umode);
+
+/**
+ * drm_umode_equal - test modeinfo modes for equality
+ * @mode1: first mode
+ * @mode2: second mode
+ *
+ * Check to see if @mode1 and @mode2 are equivalent.
+ *
+ * Returns:
+ * True if the modes are equal, false otherwise.
+ */
+bool drm_umode_equal(const struct drm_mode_modeinfo *mode1,
+const struct drm_mode_modeinfo *mode2)
+{
+   if (!mode1 && !mode2)
+   return true;
+
+   if (!mode1 || !mode2)
+   return false;
+
+   /* do clock check convert to PICOS so fb modes get matched the same */
+   if (mode1->clock && mode2->clock) {
+   if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock))
+   return false;
+   } else if (mode1->clock != mode2->clock) {
+   return false;
+   }
+
+   if ((mode1->flags & DRM_MODE_FLAG_3D_MASK) !=
+   (mode2->flags & DRM_MODE_FLAG_3D_MASK))
+   return false;
+
+   if (mode1->hdisplay == mode2->hdisplay &&
+   mode1->hsync_start == mode2->hsync_start &&
+   mode1->hsync_end == mode2->hsync_end &&
+   mode1->htotal == mode2->htotal &&
+   mode1->hskew == mode2->hskew &&
+   mode1->vdisplay == mode2->vdisplay &&
+   mode1->vsync_start == mode2->vsync_start &&
+   mode1->vsync_end == mode2->vsync_end &&
+   mode1->vtotal == mode2->vtotal &&
+   mode1->vscan == mode2->vscan &&
+   (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+(mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
+   return true;
+
+   return false;
+}
+EXPORT_SYMBOL(drm_umode_equal);
 
 /**
  * drm_mode_is_420_only - if a given videomode can be only supported in 
YCBCR420
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 0d310beae6af..05e73ca4f2ae 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -447,6 +447,8 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
 int drm_mode_convert_umode(struct drm_device *dev,
   struct drm_display_mode *out,
   const struct drm_mode_modeinfo *in);
+bool drm_umode_equal(const struct drm_mode_modeinfo *mode1,
+const struct drm_mode_modeinfo *mode2);
 void drm_mode_probed_add(struct drm_connector *connector, struct 
drm_display_mode *mode);
 void drm_mode_debug_printmodeline(const struct drm_display_mode *mode);
 bool drm_mode_is_420_only(const struct drm_display_info *display,
-- 
2.15.1

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

[RFC v3 04/12] drm: Make ioctls available for in-kernel clients part 2

This is part 2 of making ioctls useable for in-kernel clients.
Make an ioctl wrapper function that calls a function that can be used by
in-kernel clients.

It adjusts the signature of the following functions:
- drm_mode_getcrtc()
- drm_mode_create_dumb_ioctl()
- drm_mode_destroy_dumb_ioctl()
- drm_mode_getencoder()
- drm_mode_addfb2()
- drm_mode_rmfb()
- drm_mode_obj_set_property_ioctl()
- drm_mode_page_flip_ioctl()
- drm_prime_handle_to_fd_ioctl()
- drm_wait_vblank_ioctl()

drm_mode_addfb2() also gets the ability to override the debug name.

There is no functional change from the userspace side.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_crtc.c  | 15 +++
 drivers/gpu/drm/drm_crtc_internal.h | 37 +--
 drivers/gpu/drm/drm_dumb_buffers.c  | 33 
 drivers/gpu/drm/drm_encoder.c   | 10 ++--
 drivers/gpu/drm/drm_framebuffer.c   | 50 -
 drivers/gpu/drm/drm_internal.h  |  5 
 drivers/gpu/drm/drm_ioc32.c |  2 +-
 drivers/gpu/drm/drm_ioctl.c |  8 +++---
 drivers/gpu/drm/drm_mode_object.c   | 12 ++---
 drivers/gpu/drm/drm_plane.c | 12 ++---
 drivers/gpu/drm/drm_prime.c | 13 +++---
 drivers/gpu/drm/drm_vblank.c| 11 +---
 12 files changed, 147 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c9ab1cc6b412..61a6a90fae7e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -387,8 +387,8 @@ EXPORT_SYMBOL(drm_crtc_cleanup);
 /**
  * drm_mode_getcrtc - get CRTC configuration
  * @dev: drm device for the ioctl
- * @data: data pointer for the ioctl
- * @file_priv: drm file for the ioctl call
+ * @crtc_resp: pointer to crtc request structure
+ * @file_priv: drm file
  *
  * Construct a CRTC configuration structure to return to the user.
  *
@@ -397,10 +397,9 @@ EXPORT_SYMBOL(drm_crtc_cleanup);
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int drm_mode_getcrtc(struct drm_device *dev,
-void *data, struct drm_file *file_priv)
+int drm_mode_getcrtc(struct drm_device *dev, struct drm_mode_crtc *crtc_resp,
+struct drm_file *file_priv)
 {
-   struct drm_mode_crtc *crtc_resp = data;
struct drm_crtc *crtc;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
@@ -451,6 +450,12 @@ int drm_mode_getcrtc(struct drm_device *dev,
return 0;
 }
 
+int drm_mode_getcrtc_ioctl(struct drm_device *dev,
+  void *data, struct drm_file *file_priv)
+{
+   return drm_mode_getcrtc(dev, data, file_priv);
+}
+
 static int __drm_mode_set_config_internal(struct drm_mode_set *set,
  struct drm_modeset_acquire_ctx *ctx)
 {
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 29c59ce7e56e..45713af5a015 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -45,12 +45,14 @@ void drm_crtc_unregister_all(struct drm_device *dev);
 
 struct dma_fence *drm_crtc_create_fence(struct drm_crtc *crtc);
 
+int drm_mode_getcrtc(struct drm_device *dev, struct drm_mode_crtc *crtc_resp,
+struct drm_file *file_priv);
 int drm_mode_setcrtc(struct drm_device *dev, struct drm_mode_crtc *crtc_req,
 struct drm_file *file_priv, bool user);
 
 /* IOCTLs */
-int drm_mode_getcrtc(struct drm_device *dev,
-void *data, struct drm_file *file_priv);
+int drm_mode_getcrtc_ioctl(struct drm_device *dev,
+  void *data, struct drm_file *file_priv);
 int drm_mode_setcrtc_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv);
 
@@ -68,6 +70,12 @@ int drm_mode_getresources_ioctl(struct drm_device *dev, void 
*data,
 
 
 /* drm_dumb_buffers.c */
+int drm_mode_create_dumb(struct drm_device *dev,
+struct drm_mode_create_dumb *args,
+struct drm_file *file_priv);
+int drm_mode_destroy_dumb(struct drm_device *dev, u32 handle,
+ struct drm_file *file_priv);
+
 /* IOCTLs */
 int drm_mode_create_dumb_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv);
@@ -122,6 +130,9 @@ int drm_mode_object_get_properties(struct drm_mode_object 
*obj, bool atomic,
   uint32_t *arg_count_props);
 struct drm_property *drm_mode_obj_find_prop_id(struct drm_mode_object *obj,
   uint32_t prop_id);
+int drm_mode_obj_set_property(struct drm_device *dev,
+ struct drm_mode_obj_set_property *arg,
+ struct drm_file *file_priv);
 
 /* IOCTL */
 
@@ -133,10 +144,13 @@ int drm_mode_obj_set_property_ioctl(struct drm_device 
*dev, void *data,
 /*

[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)

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

--- Comment #6 from Luke McKee  ---
Harry I have tried the latest staging next 2 days ago.

Suggest you see there is a long standing issue with powerplay and buggy AMI
bioses that don't properly set up MMIO BAR regiions that need to be worked
around by your driver becuase the vendor says a 2 year old motherboard is too
old to support firmware updates, even if Intel ME is a massive security risk in
support emails. I'm actually thinking you guys need to add linuxbios/coreboot
support for your driver if available the way things are going:

https://forum-en.msi.com/index.php?topic=298468.0

I think Polaris 11 with buggy bioses that dont' properly setup PCIE MMIO BAR
ranges have hell with the amdgpu driver and powerplay (no fan control) cooked
cards etc. With your new powerplay code it gets even worse maybe and just
doesn't boot in this condition. I work OK on 4.14.20 but with exactly the same
config and amdgpu-staging-next from last updated 4 days ago I get this mess. 

Feb 23 01:41:59 hojuruku kernel: [drm] amdgpu kernel modesetting enabled.
Feb 23 01:41:59 hojuruku kernel: checking generic (e000 30) vs hw
(e000 1000)
Feb 23 01:41:59 hojuruku kernel: fb: switching to amdgpudrmfb from EFI VGA
Feb 23 01:41:59 hojuruku kernel: Console: switching to colour dummy device
80x25
Feb 23 01:41:59 hojuruku kernel: amdgpu :01:00.0: enabling device (0006 ->
0007)
Feb 23 01:41:59 hojuruku kernel: [drm] initializing kernel modesetting
(POLARIS11 0x1002:0x67FF 0x1462:0x8A91 0xCF).
Feb 23 01:41:59 hojuruku kernel: [drm] register mmio base: 0xF7E0
Feb 23 01:41:59 hojuruku kernel: [drm] register mmio size: 262144
Feb 23 01:41:59 hojuruku kernel: [drm] add ip block number 0 
Feb 23 01:41:59 hojuruku kernel: [drm] add ip block number 1 
Feb 23 01:41:59 hojuruku kernel: [drm] add ip block number 2 
Feb 23 01:41:59 hojuruku kernel: [drm] add ip block number 3 
Feb 23 01:41:59 hojuruku kernel: [drm] add ip block number 4 
Feb 23 01:41:59 hojuruku kernel: [drm] add ip block number 5 
Feb 23 01:41:59 hojuruku kernel: [drm] add ip block number 6 
Feb 23 01:41:59 hojuruku kernel: [drm] add ip block number 7 
Feb 23 01:41:59 hojuruku kernel: [drm] add ip block number 8 
Feb 23 01:41:59 hojuruku kernel: [drm] probing gen 2 caps for device 8086:c01 =
261ad03/e
Feb 23 01:41:59 hojuruku kernel: [drm] probing mlw for device 8086:c01 =
261ad03
Feb 23 01:41:59 hojuruku kernel: [drm] UVD is enabled in VM mode
Feb 23 01:41:59 hojuruku kernel: [drm] UVD ENC is enabled in VM mode
Feb 23 01:41:59 hojuruku kernel: [drm] VCE enabled in VM mode
Feb 23 01:41:59 hojuruku kernel: ATOM BIOS: 113-C98121-M01
Feb 23 01:41:59 hojuruku kernel: [drm] vm size is 64 GB, 2 levels, block size
is 10-bit, fragment size is 9-bit
Feb 23 01:41:59 hojuruku kernel: amdgpu :01:00.0: VRAM: 4096M
0x00F4 - 0x00F4 (4096M used)
Feb 23 01:41:59 hojuruku kernel: amdgpu :01:00.0: GTT: 256M
0x - 0x0FFF
Feb 23 01:41:59 hojuruku kernel: [drm] Detected VRAM RAM=4096M, BAR=256M
Feb 23 01:41:59 hojuruku kernel: [drm] RAM width 128bits GDDR5
Feb 23 01:41:59 hojuruku kernel: [TTM] Zone  kernel: Available graphics memory:
8174838 kiB
Feb 23 01:41:59 hojuruku kernel: [TTM] Zone   dma32: Available graphics memory:
2097152 kiB
Feb 23 01:41:59 hojuruku kernel: [TTM] Initializing pool allocator
Feb 23 01:41:59 hojuruku kernel: [TTM] Initializing DMA pool allocator
Feb 23 01:41:59 hojuruku kernel: [drm] amdgpu: 4096M of VRAM memory ready
Feb 23 01:41:59 hojuruku kernel: [drm] amdgpu: 4096M of GTT memory ready.
Feb 23 01:41:59 hojuruku kernel: [drm] GART: num cpu pages 65536, num gpu pages
65536
Feb 23 01:41:59 hojuruku kernel: [drm] PCIE GART of 256M enabled (table at
0x00F40004).
Feb 23 01:41:59 hojuruku kernel: [drm] Supports vblank timestamp caching Rev 2
(21.10.2013).
Feb 23 01:41:59 hojuruku kernel: [drm] Driver supports precise vblank timestamp
query.
Feb 23 01:41:59 hojuruku kernel: [drm] AMDGPU Display Connectors
Feb 23 01:41:59 hojuruku kernel: [drm] Connector 0:
Feb 23 01:41:59 hojuruku kernel: [drm]   DP-1
Feb 23 01:41:59 hojuruku kernel: [drm]   HPD2
Feb 23 01:41:59 hojuruku kernel: [drm]   DDC: 0x4868 0x4868 0x4869 0x4869
0x486a 0x486a 0x486b 0x486b
Feb 23 01:41:59 hojuruku kernel: [drm]   Encoders:
Feb 23 01:41:59 hojuruku kernel: [drm] DFP1: INTERNAL_UNIPHY1
Feb 23 01:41:59 hojuruku kernel: [drm] Connector 1:
Feb 23 01:41:59 hojuruku kernel: [drm]   HDMI-A-1
Feb 23 01:41:59 hojuruku kernel: [drm]   HPD5
Feb 23 01:41:59 hojuruku kernel: [drm]   DDC: 0x4874 0x4874 0x4875 0x4875
0x4876 0x4876 0x4877 0x4877
Feb 23 01:41:59 hojuruku kernel: [drm]   Encoders:
Feb 23 01:41:59 hojuruku kernel: [drm] DFP2: INTERNAL_UNIPHY1
Feb 23 01:41:59 hojuruku kernel: [drm] Connector 2:
Feb 23 01:41:59 hojuruku kernel: [drm]   DVI-D-1
Feb 23 01:41:59 hojuruku kernel: [drm]   HPD3
Feb 23 01:41:59 hojuruku kernel: [drm]   DDC: 0x4878

[bug report] drm/stm: ltdc: add clut mode support

2018-02-22 Thread Dan Carpenter

Hello Philippe CORNU,

This is a semi-automatic email about new static checker warnings.

The patch b706a25eaed0: "drm/stm: ltdc: add clut mode support" from 
Oct 26, 2017, leads to the following Smatch complaint:

drivers/gpu/drm/stm/ltdc.c:395 ltdc_crtc_update_clut()
warn: variable dereferenced before check 'crtc' (see line 390)

drivers/gpu/drm/stm/ltdc.c
   389  {
   390  struct ltdc_device *ldev = crtc_to_ltdc(crtc);

Dereferenced inside the function call

   391  struct drm_color_lut *lut;
   392  u32 val;
   393  int i;
   394  
   395  if (!crtc || !crtc->state)
 
Too late.

   396  return;
   397  

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

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

Kristian Høgsberg  writes:

> On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher  wrote:
>
>> On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace 
> wrote:
>> > On Thu 21 Dec 2017, Daniel Vetter wrote:
>> >> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen <
> hoegsb...@google.com> wrote:
>> >>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico <
> mvicom...@nvidia.com> wrote:
>>  On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg <
> hoegsb...@gmail.com> wrote:
>> > I'd like to see concrete examples of actual display controllers
>> > supporting more format layouts than what can be specified with a 64
>> > bit modifier.
>> 
>>  The main problem is our tiling and other metadata parameters can't
>>  generally fit in a modifier, so we find passing a blob of metadata a
>>  more suitable mechanism.
>> >>>
>> >>> I understand that you may have n knobs with a total of more than a
> total of
>> >>> 56 bits that configure your tiling/swizzling for color buffers. What
> I don't
>> >>> buy is that you need all those combinations when passing buffers
> around
>> >>> between codecs, cameras and display controllers. Even if you're
> sharing
>> >>> between the same 3D drivers in different processes, I expect just
> locking
>> >>> down, say, 64 different combinations (you can add more over time) and
>> >>> assigning each a modifier would be sufficient. I doubt you'd extract
>> >>> meaningful performance gains from going all the way to a blob.
>> >
>> > I agree with Kristian above. In my opinion, choosing to encode in
>> > modifiers a precise description of every possible tiling/compression
>> > layout is not technically incorrect, but I believe it misses the point.
>> > The intention behind modifiers is not to exhaustively describe all
>> > possibilites.
>> >
>> > I summarized this opinion in VK_EXT_image_drm_format_modifier,
>> > where I wrote an "introdution to modifiers" section. Here's an excerpt:
>> >
>> > One goal of modifiers in the Linux ecosystem is to enumerate for
> each
>> > vendor a reasonably sized set of tiling formats that are
> appropriate for
>> > images shared across processes, APIs, and/or devices, where each
>> > participating component may possibly be from different vendors.
>> > A non-goal is to enumerate all tiling formats supported by all
> vendors.
>> > Some tiling formats used internally by vendors are inappropriate for
>> > sharing; no modifiers should be assigned to such tiling formats.
>
>> Where it gets tricky is how to select that subset?  Our tiling mode
>> are defined more by the asic specific constraints than the tiling mode
>> itself.  At a high level we have basically 3 tiling modes (out of 16
>> possible) that would be the minimum we'd want to expose for gfx6-8.
>> gfx9 uses a completely new scheme.
>> 1. Linear (per asic stride requirements, not usable by many hw blocks)
>> 2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick)
>> 3. 2D Thin (1D tiling constraints, plus pipe config (18 possible),
>> tile split (7 possible), sample split (4 possible), num banks (4
>> possible), bank width (4 possible), bank height (4 possible), macro
>> tile aspect (4 possible) all of which are asic config specific)
>
>> I guess we could do something like:
>> AMD_GFX6_LINEAR_ALIGNED_64B
>> AMD_GFX6_LINEAR_ALIGNED_256B
>> AMD_GFX6_LINEAR_ALIGNED_512B
>> AMD_GFX6_1D_THIN_DISPLAY
>> AMD_GFX6_1D_THIN_DEPTH
>> AMD_GFX6_1D_THIN_ROTATED
>> AMD_GFX6_1D_THIN_THIN
>> AMD_GFX6_1D_THIN_THICK
>
> AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>> etc.
>
>> We only probably need 40 bits

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

2018-02-22 Thread Bas Nieuwenhuizen

On Thu, Feb 22, 2018 at 7:04 PM, Kristian Høgsberg  wrote:
> On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher  wrote:
>
>> On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace 
> wrote:
>> > On Thu 21 Dec 2017, Daniel Vetter wrote:
>> >> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen <
> hoegsb...@google.com> wrote:
>> >>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico <
> mvicom...@nvidia.com> wrote:
>>  On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg <
> hoegsb...@gmail.com> wrote:
>> > I'd like to see concrete examples of actual display controllers
>> > supporting more format layouts than what can be specified with a 64
>> > bit modifier.
>> 
>>  The main problem is our tiling and other metadata parameters can't
>>  generally fit in a modifier, so we find passing a blob of metadata a
>>  more suitable mechanism.
>> >>>
>> >>> I understand that you may have n knobs with a total of more than a
> total of
>> >>> 56 bits that configure your tiling/swizzling for color buffers. What
> I don't
>> >>> buy is that you need all those combinations when passing buffers
> around
>> >>> between codecs, cameras and display controllers. Even if you're
> sharing
>> >>> between the same 3D drivers in different processes, I expect just
> locking
>> >>> down, say, 64 different combinations (you can add more over time) and
>> >>> assigning each a modifier would be sufficient. I doubt you'd extract
>> >>> meaningful performance gains from going all the way to a blob.
>> >
>> > I agree with Kristian above. In my opinion, choosing to encode in
>> > modifiers a precise description of every possible tiling/compression
>> > layout is not technically incorrect, but I believe it misses the point.
>> > The intention behind modifiers is not to exhaustively describe all
>> > possibilites.
>> >
>> > I summarized this opinion in VK_EXT_image_drm_format_modifier,
>> > where I wrote an "introdution to modifiers" section. Here's an excerpt:
>> >
>> > One goal of modifiers in the Linux ecosystem is to enumerate for
> each
>> > vendor a reasonably sized set of tiling formats that are
> appropriate for
>> > images shared across processes, APIs, and/or devices, where each
>> > participating component may possibly be from different vendors.
>> > A non-goal is to enumerate all tiling formats supported by all
> vendors.
>> > Some tiling formats used internally by vendors are inappropriate for
>> > sharing; no modifiers should be assigned to such tiling formats.
>
>> Where it gets tricky is how to select that subset?  Our tiling mode
>> are defined more by the asic specific constraints than the tiling mode
>> itself.  At a high level we have basically 3 tiling modes (out of 16
>> possible) that would be the minimum we'd want to expose for gfx6-8.
>> gfx9 uses a completely new scheme.
>> 1. Linear (per asic stride requirements, not usable by many hw blocks)
>> 2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick)
>> 3. 2D Thin (1D tiling constraints, plus pipe config (18 possible),
>> tile split (7 possible), sample split (4 possible), num banks (4
>> possible), bank width (4 possible), bank height (4 possible), macro
>> tile aspect (4 possible) all of which are asic config specific)
>
>> I guess we could do something like:
>> AMD_GFX6_LINEAR_ALIGNED_64B
>> AMD_GFX6_LINEAR_ALIGNED_256B
>> AMD_GFX6_LINEAR_ALIGNED_512B
>> AMD_GFX6_1D_THIN_DISPLAY
>> AMD_GFX6_1D_THIN_DEPTH
>> AMD_GFX6_1D_THIN_ROTATED
>> AMD_GFX6_1D_THIN_THIN
>> AMD_GFX6_1D_THIN_THICK
>
> AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>
> AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
>> etc.
>

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

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

--- Comment #41 from Bong Cosca  ---
cik.c reports the following in cik_setup_rb():

max_rb_num_per_se: 1
enabled_rbs: 0
disabled_rbs: 1
mask: 2
se_num: 1
sh_per_se: 1

-- 
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: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

2018-02-22 Thread Kristian Høgsberg

On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher  wrote:

> On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace 
wrote:
> > On Thu 21 Dec 2017, Daniel Vetter wrote:
> >> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen <
hoegsb...@google.com> wrote:
> >>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico <
mvicom...@nvidia.com> wrote:
>  On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg <
hoegsb...@gmail.com> wrote:
> > I'd like to see concrete examples of actual display controllers
> > supporting more format layouts than what can be specified with a 64
> > bit modifier.
> 
>  The main problem is our tiling and other metadata parameters can't
>  generally fit in a modifier, so we find passing a blob of metadata a
>  more suitable mechanism.
> >>>
> >>> I understand that you may have n knobs with a total of more than a
total of
> >>> 56 bits that configure your tiling/swizzling for color buffers. What
I don't
> >>> buy is that you need all those combinations when passing buffers
around
> >>> between codecs, cameras and display controllers. Even if you're
sharing
> >>> between the same 3D drivers in different processes, I expect just
locking
> >>> down, say, 64 different combinations (you can add more over time) and
> >>> assigning each a modifier would be sufficient. I doubt you'd extract
> >>> meaningful performance gains from going all the way to a blob.
> >
> > I agree with Kristian above. In my opinion, choosing to encode in
> > modifiers a precise description of every possible tiling/compression
> > layout is not technically incorrect, but I believe it misses the point.
> > The intention behind modifiers is not to exhaustively describe all
> > possibilites.
> >
> > I summarized this opinion in VK_EXT_image_drm_format_modifier,
> > where I wrote an "introdution to modifiers" section. Here's an excerpt:
> >
> > One goal of modifiers in the Linux ecosystem is to enumerate for
each
> > vendor a reasonably sized set of tiling formats that are
appropriate for
> > images shared across processes, APIs, and/or devices, where each
> > participating component may possibly be from different vendors.
> > A non-goal is to enumerate all tiling formats supported by all
vendors.
> > Some tiling formats used internally by vendors are inappropriate for
> > sharing; no modifiers should be assigned to such tiling formats.

> Where it gets tricky is how to select that subset?  Our tiling mode
> are defined more by the asic specific constraints than the tiling mode
> itself.  At a high level we have basically 3 tiling modes (out of 16
> possible) that would be the minimum we'd want to expose for gfx6-8.
> gfx9 uses a completely new scheme.
> 1. Linear (per asic stride requirements, not usable by many hw blocks)
> 2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick)
> 3. 2D Thin (1D tiling constraints, plus pipe config (18 possible),
> tile split (7 possible), sample split (4 possible), num banks (4
> possible), bank width (4 possible), bank height (4 possible), macro
> tile aspect (4 possible) all of which are asic config specific)

> I guess we could do something like:
> AMD_GFX6_LINEAR_ALIGNED_64B
> AMD_GFX6_LINEAR_ALIGNED_256B
> AMD_GFX6_LINEAR_ALIGNED_512B
> AMD_GFX6_1D_THIN_DISPLAY
> AMD_GFX6_1D_THIN_DEPTH
> AMD_GFX6_1D_THIN_ROTATED
> AMD_GFX6_1D_THIN_THIN
> AMD_GFX6_1D_THIN_THICK

AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
> etc.

> We only probably need 40 bits to encode all of the tiling parameters
> so we could do family, plus tiling encoding that still seems unwieldy
> to deal with from an application perspective.  All of

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

2018-02-22 Thread Michel Dänzer

On 2018-02-22 06:37 PM, Ben Crocker wrote:
> One of my colleagues did discover a "Radeon HG 5450 PCI" from February
> 2010 which did, apparently, have a Cedar GPU and very definitely had a
> (plain old) PCI connector.

There must be a PCIe-to-PCI bridge on that board. The GPU itself is
always PCIe, and treated accordingly by the driver.


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

[PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

In radeon_device_init, set the need_dma32 flag for Cedar chips
(e.g. FirePro 2270).  This fixes, or at least works around, a bug
on PowerPC exposed by last year's commits

8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)

and

253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)

which enabled the 64-bit DMA iommu bypass.

This caused the device to freeze, in some cases unrecoverably, and is
the subject of several bug reports internal to Red Hat.

Signed-off-by: Ben Crocker 
---
 drivers/gpu/drm/radeon/radeon_device.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index ffc10cadcf34..32b577c776b9 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1397,6 +1397,10 @@ int radeon_device_init(struct radeon_device *rdev,
if ((rdev->flags & RADEON_IS_PCI) &&
(rdev->family <= CHIP_RS740))
rdev->need_dma32 = true;
+#ifdef CONFIG_PPC64
+   if (rdev->family == CHIP_CEDAR)
+   rdev->need_dma32 = true;
+#endif
 
dma_bits = rdev->need_dma32 ? 32 : 40;
r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
-- 
2.13.6

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

[PATCH 0/2] drm/panel: Add device link in drm_panel_attach()

The first patch could be squashed to second, but kept is separate
since I think it is correct even without the second patch.

With these patches unbinding a panel driver in use does not cause
nasty backtraces and corrupted drm core structures, but instead it
cleanly unbind the drm master device at the same time.

The only down side (currently[1]) is that the drm device does not reprobe
if the panel drived is bound again, but everything should work if the
drm master driver is bound manually. Atleast this the behavior with
this series on am335x-evm: 

https://lists.freedesktop.org/archives/dri-devel/2018-February/166898.html

[1] https://lists.freedesktop.org/archives/dri-devel/2018-February/166907.html

Jyri Sarha (2):
  drm/panel: Remove drm_panel_detach() calls from all panel drives
  drm/panel: Add device_link from panel device to drm device

 drivers/gpu/drm/drm_panel.c  | 12 
 drivers/gpu/drm/panel/panel-innolux-p079zca.c|  1 -
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c   |  1 -
 drivers/gpu/drm/panel/panel-lvds.c   |  1 -
 drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c |  1 -
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c  |  1 -
 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c  |  1 -
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c  |  1 -
 drivers/gpu/drm/panel/panel-simple.c |  1 -
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c   |  1 -
 include/drm/drm_panel.h  |  1 +
 11 files changed, 13 insertions(+), 9 deletions(-)

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

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

[PATCH 2/2] drm/panel: Add device_link from panel device to drm device

Add device_link from panel device (supplier) to drm device (consumer)
with DL_FLAG_AUTOREMOVE when drm_panel_attach() is called. Currently
the master drm driver is not protected against the attached. The
device_link with DL_FLAG_AUTOREMOVE should make sure the drm device is
unbound before the panel driver becomes unavailable.

The device_link is removed when drm_panel_detach() is called. The
drm_panel_detach() should be called by the panel driver it self when
it is removed. Otherwise the both driver are racing to delete the same
link.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/drm_panel.c | 12 
 include/drm/drm_panel.h |  1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 308d442..d9452e98 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -98,9 +99,18 @@ EXPORT_SYMBOL(drm_panel_remove);
  */
 int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
 {
+   u32 flags = DL_FLAG_AUTOREMOVE;
+
if (panel->connector)
return -EBUSY;
 
+   panel->link = device_link_add(connector->dev->dev, panel->dev, flags);
+   if (!panel->link) {
+   dev_err(panel->dev, "failed to link panel %s to %s\n",
+   dev_name(connector->dev->dev), dev_name(panel->dev));
+   return -EINVAL;
+   }
+
panel->connector = connector;
panel->drm = connector->dev;
 
@@ -119,6 +129,8 @@ EXPORT_SYMBOL(drm_panel_attach);
  */
 int drm_panel_detach(struct drm_panel *panel)
 {
+   device_link_del(panel->link);
+
panel->connector = NULL;
panel->drm = NULL;
 
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 14ac240..26a1b5f 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -89,6 +89,7 @@ struct drm_panel {
struct drm_device *drm;
struct drm_connector *connector;
struct device *dev;
+   struct device_link *link;
 
const struct drm_panel_funcs *funcs;
 
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 1/2] drm/panel: Remove drm_panel_detach() calls from all panel drives

Setting the connector and drm to NULL when the drm panel device is
going away hardly serves any purpose. Usually the the whole memory
stucture is freed right after the remove call.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/panel/panel-innolux-p079zca.c| 1 -
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c   | 1 -
 drivers/gpu/drm/panel/panel-lvds.c   | 1 -
 drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 1 -
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c  | 1 -
 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c  | 1 -
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c  | 1 -
 drivers/gpu/drm/panel/panel-simple.c | 1 -
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c   | 1 -
 9 files changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba9344..517782a 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -310,7 +310,6 @@ static int innolux_panel_remove(struct mipi_dsi_device *dsi)
DRM_DEV_ERROR(>dev, "failed to detach from DSI host: %d\n",
  err);
 
-   drm_panel_detach(>base);
innolux_panel_del(innolux);
 
return 0;
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index 5b2340e..3f6ac64 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -502,7 +502,6 @@ static int jdi_panel_remove(struct mipi_dsi_device *dsi)
dev_err(>dev, "failed to detach from DSI host: %d\n",
ret);
 
-   drm_panel_detach(>base);
jdi_panel_del(jdi);
 
return 0;
diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
b/drivers/gpu/drm/panel/panel-lvds.c
index b5e3994..e8bc356 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -282,7 +282,6 @@ static int panel_lvds_remove(struct platform_device *pdev)
 {
struct panel_lvds *lvds = dev_get_drvdata(>dev);
 
-   drm_panel_detach(>panel);
drm_panel_remove(>panel);
 
panel_lvds_disable(>panel);
diff --git a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c 
b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
index 74a8061..cb4dfb9 100644
--- a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
+++ b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
@@ -299,7 +299,6 @@ static int wuxga_nt_panel_remove(struct mipi_dsi_device 
*dsi)
if (ret < 0)
dev_err(>dev, "failed to detach from DSI host: %d\n", ret);
 
-   drm_panel_detach(_nt->base);
wuxga_nt_panel_del(wuxga_nt);
 
return 0;
diff --git a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c 
b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
index 71c09ed..75f9253 100644
--- a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
+++ b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
@@ -292,7 +292,6 @@ static int seiko_panel_remove(struct platform_device *pdev)
 {
struct seiko_panel *panel = dev_get_drvdata(>dev);
 
-   drm_panel_detach(>base);
drm_panel_remove(>base);
 
seiko_panel_disable(>base);
diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 3cce3ca..dcdf517 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -442,7 +442,6 @@ static int sharp_panel_remove(struct mipi_dsi_device *dsi)
if (err < 0)
dev_err(>dev, "failed to detach from DSI host: %d\n", err);
 
-   drm_panel_detach(>base);
sharp_panel_del(sharp);
 
return 0;
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
index 3aeb0bd..5f9d3ed 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -352,7 +352,6 @@ static int sharp_nt_panel_remove(struct mipi_dsi_device 
*dsi)
if (ret < 0)
dev_err(>dev, "failed to detach from DSI host: %d\n", ret);
 
-   drm_panel_detach(_nt->base);
sharp_nt_panel_del(sharp_nt);
 
return 0;
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 3b0ba9f..5aa736c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -364,7 +364,6 @@ static int panel_simple_remove(struct device *dev)
 {
struct panel_simple *panel = dev_get_drvdata(dev);
 
-   drm_panel_detach(>base);
drm_panel_remove(>base);
 
panel_simple_disable(>base);
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c 
b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
index 358c64e..74284e5 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
+++

Re: [PATCH 2/7] PCI: Make pci_wakeup_bus() & pci_bus_set_current_state() public

2018-02-22 Thread Bjorn Helgaas

On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote:
> There are PCI devices which are power-manageable by a nonstandard means,
> such as a custom ACPI method.  One example are discrete GPUs in hybrid
> graphics laptops, another are Thunderbolt controllers in Macs.
> 
> Such devices can't be put into D3cold with pci_set_power_state() because
> pci_platform_power_transition() fails with -ENODEV.  Instead they're put
> into D3hot by pci_set_power_state() and subsequently into D3cold by
> invoking the nonstandard means.  However as a consequence the cached
> current_state is incorrectly left at D3hot.
> 
> What we need to do is walk the hierarchy below such a PCI device on
> powerdown and update the current_state to D3cold.  On powerup the PCI
> device itself and the hierarchy below it is in D0uninitialized, so we
> need to walk the hierarchy again and wake all devices, causing them to
> be put into D0active and then letting them autosuspend as they see fit.
> 
> To this end make pci_wakeup_bus() & pci_bus_set_current_state() public
> so PCI drivers don't have to reinvent the wheel.
> 
> Cc: Bjorn Helgaas 
> Cc: Rafael J. Wysocki 
> Signed-off-by: Lukas Wunner 

Acked-by: Bjorn Helgaas 

> ---
>  drivers/pci/pci.c   | 8 
>  include/linux/pci.h | 2 ++
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index f694650235f2..6e6e322a5a7d 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -800,7 +800,7 @@ static int pci_wakeup(struct pci_dev *pci_dev, void *ign)
>   * pci_wakeup_bus - Walk given bus and wake up devices on it
>   * @bus: Top bus of the subtree to walk.
>   */
> -static void pci_wakeup_bus(struct pci_bus *bus)
> +void pci_wakeup_bus(struct pci_bus *bus)
>  {
>   if (bus)
>   pci_walk_bus(bus, pci_wakeup, NULL);
> @@ -850,11 +850,11 @@ static int __pci_dev_set_current_state(struct pci_dev 
> *dev, void *data)
>  }
>  
>  /**
> - * __pci_bus_set_current_state - Walk given bus and set current state of 
> devices
> + * pci_bus_set_current_state - Walk given bus and set current state of 
> devices
>   * @bus: Top bus of the subtree to walk.
>   * @state: state to be set
>   */
> -static void __pci_bus_set_current_state(struct pci_bus *bus, pci_power_t 
> state)
> +void pci_bus_set_current_state(struct pci_bus *bus, pci_power_t state)
>  {
>   if (bus)
>   pci_walk_bus(bus, __pci_dev_set_current_state, );
> @@ -876,7 +876,7 @@ int __pci_complete_power_transition(struct pci_dev *dev, 
> pci_power_t state)
>   ret = pci_platform_power_transition(dev, state);
>   /* Power off the bridge may power off the whole hierarchy */
>   if (!ret && state == PCI_D3cold)
> - __pci_bus_set_current_state(dev->subordinate, PCI_D3cold);
> + pci_bus_set_current_state(dev->subordinate, PCI_D3cold);
>   return ret;
>  }
>  EXPORT_SYMBOL_GPL(__pci_complete_power_transition);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 024a1beda008..ae42289662df 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1147,6 +1147,8 @@ void pci_pme_wakeup_bus(struct pci_bus *bus);
>  void pci_d3cold_enable(struct pci_dev *dev);
>  void pci_d3cold_disable(struct pci_dev *dev);
>  bool pcie_relaxed_ordering_enabled(struct pci_dev *dev);
> +void pci_wakeup_bus(struct pci_bus *bus);
> +void pci_bus_set_current_state(struct pci_bus *bus, pci_power_t state);
>  
>  /* PCI Virtual Channel */
>  int pci_save_vc_state(struct pci_dev *dev);
> -- 
> 2.15.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RFC] driver core: Reprobe consumer if it was unbound by dropped device_link

Put consumer device to deferred probe list if it is unbound due to a
dropped link to a supplier.

When a device link supplier is unbound (either manually or because one
of its own suppliers was unbound), its consumers are unbound as
well. Currently if the supplier binds again after this the consumer
does not automatically probe again. With this patch it does.

If this patch is not acceptable as such, how about adding this
behavior behind a new device link flag?

The idea to this patch was gotten from this post by Lucas Wunner:
https://www.spinics.net/lists/dri-devel/msg166318.html

Part of the code and the description is borrowed from him.

cc: Lukas Wunner 
cc: Rafael J. Wysocki 
cc: Thierry Reding 
Signed-off-by: Jyri Sarha 
---
 drivers/base/base.h | 1 +
 drivers/base/core.c | 2 ++
 drivers/base/dd.c   | 2 +-
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/base/base.h b/drivers/base/base.h
index d800de6..39370eb 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -114,6 +114,7 @@ extern void device_release_driver_internal(struct device 
*dev,
 
 extern void driver_detach(struct device_driver *drv);
 extern int driver_probe_device(struct device_driver *drv, struct device *dev);
+extern void driver_deferred_probe_add(struct device *dev);
 extern void driver_deferred_probe_del(struct device *dev);
 static inline int driver_match_device(struct device_driver *drv,
  struct device *dev)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index b2261f9..0964ed5 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -570,6 +570,8 @@ void device_links_unbind_consumers(struct device *dev)
 
device_release_driver_internal(consumer, NULL,
   consumer->parent);
+   driver_deferred_probe_add(consumer);
+
put_device(consumer);
goto start;
}
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index de6fd09..846ae78 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -140,7 +140,7 @@ static void deferred_probe_work_func(struct work_struct 
*work)
 }
 static DECLARE_WORK(deferred_probe_work, deferred_probe_work_func);
 
-static void driver_deferred_probe_add(struct device *dev)
+void driver_deferred_probe_add(struct device *dev)
 {
mutex_lock(_probe_mutex);
if (list_empty(>p->deferred_probe)) {
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

One of my colleagues did discover a "Radeon HG 5450 PCI" from February
2010 which did, apparently, have a Cedar GPU and very definitely had a
(plain old) PCI connector.

But I take your point, and will just drop the PCI/PCIE check.


On Thu, Feb 22, 2018 at 12:04 PM, Michel Dänzer  wrote:

> On 2018-02-22 10:57 PM, Ben Crocker wrote:
> > In radeon_device_init, set the need_dma32 flag for Cedar chips
> > (e.g. FirePro 2270).  This fixes, or at least works around, a bug
> > on PowerPC exposed by last year's commits
> >
> > 8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)
> >
> > and
> >
> > 253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)
> >
> > which enabled the 64-bit DMA iommu bypass.
> >
> > This caused the device to freeze, in some cases unrecoverably, and is
> > the subject of several bug reports internal to Red Hat.
> >
> > Signed-off-by: Ben Crocker 
> > ---
> >  drivers/gpu/drm/radeon/radeon_device.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> > index ffc10cadcf34..ba7435bcd208 100644
> > --- a/drivers/gpu/drm/radeon/radeon_device.c
> > +++ b/drivers/gpu/drm/radeon/radeon_device.c
> > @@ -1397,6 +1397,11 @@ int radeon_device_init(struct radeon_device *rdev,
> >   if ((rdev->flags & RADEON_IS_PCI) &&
> >   (rdev->family <= CHIP_RS740))
> >   rdev->need_dma32 = true;
> > +#ifdef CONFIG_PPC64
> > + if ((rdev->flags & (RADEON_IS_PCI | RADEON_IS_PCIE)) &&
>
> Cedar is (like all Radeons from the last decade) always PCIe, so this
> flags check is redundant FWIW.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 06/10] pwm: add PWM modes

2018-02-22 Thread Andy Shevchenko

On Thu, Feb 22, 2018 at 2:01 PM, Claudiu Beznea
 wrote:
> Add PWM normal and complementary modes.

> +- PWM_DTMODE_COMPLEMENTARY: PWM complementary working mode (for PWM
> +channels two outputs); if not specified, the default for PWM channel will
> +be used

What DT stands for?

-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1] drm/simple_kms_helper: Fix NULL pointer dereference with no active CRTC


On 02/22/2018 06:11 PM, Daniel Vetter wrote:

On Thu, Feb 22, 2018 at 08:12:48AM +0200, Oleksandr Andrushchenko wrote:

On 02/22/2018 08:09 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

It is possible that drm_simple_kms_plane_atomic_check called
with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID
to 0 before doing any actual drawing. This leads to NULL pointer
dereference because in this case new CRTC state is NULL and must be
checked before accessing.

Signed-off-by: Oleksandr Andrushchenko 
Reviewed-by: Daniel Vetter 

---
Changes since initial:
- re-worked checks for null CRTC as suggested by Daniel Vetter
---
   drivers/gpu/drm/drm_simple_kms_helper.c | 10 +++---
   1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 9ca8a4a59b74..4a1dbd88b1ec 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -121,12 +121,6 @@ static int drm_simple_kms_plane_atomic_check(struct 
drm_plane *plane,
pipe = container_of(plane, struct drm_simple_display_pipe, plane);
crtc_state = drm_atomic_get_new_crtc_state(plane_state->state,
   >crtc);
-   if (!crtc_state->enable)
-   return 0; /* nothing to check when disabling or disabled */
-
-   if (crtc_state->enable)
-   drm_mode_get_hv_timing(_state->mode,
-  , );
ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,
  ,
@@ -137,7 +131,9 @@ static int drm_simple_kms_plane_atomic_check(struct 
drm_plane *plane,
return ret;
if (!plane_state->visible)
-   return -EINVAL;

Daniel, I have put your R-b tag, but I had removed suggested
"WARN_ON(crtc_state && crtc_state->enable);"
here as it fires each time when crtc_state is not NULL.
Please let me know if this is not ok and you want me to remove
your R-b tag.

I'm a bit confused why that fires, but oh well. Applied, thanks for your
patch.

Thank you

-Daniel


+   return 0;
+
+   drm_mode_get_hv_timing(_state->mode, , );
if (!pipe->funcs || !pipe->funcs->check)
return 0;

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


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

Re: [PATCH 1/4] drm/simple_kms_helper: Add {enable|disable}_vblank callback support


On 02/22/2018 06:59 PM, Daniel Vetter wrote:

On Mon, Feb 19, 2018 at 11:11:23AM +0200, Oleksandr Andrushchenko wrote:

ping
On 02/12/2018 10:52 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

If simple_kms_helper based driver needs to work with vblanks,
then it has to provide drm_driver.{enable|disable}_vblank callbacks,
because drm_simple_kms_helper.drm_crtc_funcs does not provide any.
At the same time drm_driver.{enable|disable}_vblank callbacks
are marked as deprecated and shouldn't be used by new drivers.

Fix this by extending drm_simple_kms_helper.drm_crtc_funcs
to provide the missing callbacks.

Signed-off-by: Oleksandr Andrushchenko 

lgtm, all 4 applied, thanks for your patches.

Thank you, my pleasure

-Daniel


---
   drivers/gpu/drm/drm_simple_kms_helper.c | 24 
   include/drm/drm_simple_kms_helper.h | 18 ++
   2 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 9d3f6b70812c..9ca8a4a59b74 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -77,6 +77,28 @@ static const struct drm_crtc_helper_funcs 
drm_simple_kms_crtc_helper_funcs = {
.atomic_disable = drm_simple_kms_crtc_disable,
   };
+static int drm_simple_kms_crtc_enable_vblank(struct drm_crtc *crtc)
+{
+   struct drm_simple_display_pipe *pipe;
+
+   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
+   if (!pipe->funcs || !pipe->funcs->enable_vblank)
+   return 0;
+
+   return pipe->funcs->enable_vblank(pipe);
+}
+
+static void drm_simple_kms_crtc_disable_vblank(struct drm_crtc *crtc)
+{
+   struct drm_simple_display_pipe *pipe;
+
+   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
+   if (!pipe->funcs || !pipe->funcs->disable_vblank)
+   return;
+
+   pipe->funcs->disable_vblank(pipe);
+}
+
   static const struct drm_crtc_funcs drm_simple_kms_crtc_funcs = {
.reset = drm_atomic_helper_crtc_reset,
.destroy = drm_crtc_cleanup,
@@ -84,6 +106,8 @@ static const struct drm_crtc_funcs drm_simple_kms_crtc_funcs 
= {
.page_flip = drm_atomic_helper_page_flip,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+   .enable_vblank = drm_simple_kms_crtc_enable_vblank,
+   .disable_vblank = drm_simple_kms_crtc_disable_vblank,
   };
   static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane,
diff --git a/include/drm/drm_simple_kms_helper.h 
b/include/drm/drm_simple_kms_helper.h
index 6d9adbb46293..79567826b099 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -93,6 +93,24 @@ struct drm_simple_display_pipe_funcs {
 */
void (*cleanup_fb)(struct drm_simple_display_pipe *pipe,
   struct drm_plane_state *plane_state);
+
+   /**
+* @enable_vblank:
+*
+* Optional, called by _crtc_funcs.enable_vblank. Please read
+* the documentation for the _crtc_funcs.enable_vblank hook for
+* more details.
+*/
+   int (*enable_vblank)(struct drm_simple_display_pipe *pipe);
+
+   /**
+* @disable_vblank:
+*
+* Optional, called by _crtc_funcs.disable_vblank. Please read
+* the documentation for the _crtc_funcs.disable_vblank hook for
+* more details.
+*/
+   void (*disable_vblank)(struct drm_simple_display_pipe *pipe);
   };
   /**

___
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

[PATCH 2/4] drm/tilcdc: tilcdc_panel: Rename device from "panel" to "tilcdc-panel"

Rename the bundled tilcdc_panel driver from just "panel" to
"tilcdc-panel" to avoid noisy error messages from the driver trying to
probe all device nodes named "panel".

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index cf9ca16..d616d64 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -421,7 +421,7 @@ struct platform_driver panel_driver = {
.remove = panel_remove,
.driver = {
.owner = THIS_MODULE,
-   .name = "panel",
+   .name = "tilcdc-panel",
.of_match_table = panel_of_match,
},
 };
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 4/4] ARM: dts: am335x-evm: Use drm simple-panel instead of tilcdc-panel

Move to use the new drm panel support in tilcdc together with added
"tvc,s9700rtwv43tr-01b"-panel support in drm panel-simple.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-evm.dts | 44 
 1 file changed, 18 insertions(+), 26 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index fee6b3e..5a442b5 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -98,7 +98,7 @@
};
};
 
-   backlight {
+   backlight: backlight {
compatible = "pwm-backlight";
pwms = < 0 5 0>;
brightness-levels = <0 51 53 56 62 75 101 152 255>;
@@ -106,35 +106,19 @@
};
 
panel {
-   compatible = "ti,tilcdc,panel";
+   compatible = "tvc,s9700rtwv43tr-01b";
+
status = "okay";
+
pinctrl-names = "default";
pinctrl-0 = <_pins_s0>;
-   panel-info {
-   ac-bias   = <255>;
-   ac-bias-intrpt= <0>;
-   dma-burst-sz  = <16>;
-   bpp   = <32>;
-   fdd   = <0x80>;
-   sync-edge = <0>;
-   sync-ctrl = <1>;
-   raster-order  = <0>;
-   fifo-th   = <0>;
-   };
 
-   display-timings {
-   800x480p62 {
-   clock-frequency = <3000>;
-   hactive = <800>;
-   vactive = <480>;
-   hfront-porch = <39>;
-   hback-porch = <39>;
-   hsync-len = <47>;
-   vback-porch = <29>;
-   vfront-porch = <13>;
-   vsync-len = <2>;
-   hsync-active = <1>;
-   vsync-active = <1>;
+   backlight = <>;
+   ports {
+   port {
+   panel_0: endpoint@0 {
+   remote-endpoint = <_0>;
+   };
};
};
};
@@ -503,6 +487,14 @@
status = "okay";
 
blue-and-red-wiring = "crossed";
+
+   ports {
+   port {
+   lcdc_0: endpoint@0 {
+   remote-endpoint = <_0>;
+   };
+   };
+   };
 };
 
  {
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 3/4] drm/panel: simple: Add TVC S9700RTWV43TR-01B 800x480 panel support

Add support for TVC S9700RTWV43TR-01B 800x480 panel found on TI's
AM335X-EVM.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/panel/panel-simple.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984..3b0ba9f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1962,6 +1962,29 @@ static const struct panel_desc tpk_f10a_0102 = {
},
 };
 
+static const struct drm_display_mode tvc_s9700rtwv43tr_01b_mode = {
+   .clock = 3000,
+   .hdisplay = 800,
+   .hsync_start = 800 + 39,
+   .hsync_end = 800 + 39 + 47,
+   .htotal = 800 + 39 + 47 + 39,
+   .vdisplay = 480,
+   .vsync_start = 480 + 13,
+   .vsync_end = 480 + 13 + 2,
+   .vtotal = 480 + 13 + 2 + 29,
+   .vrefresh = 62,
+};
+
+static const struct panel_desc tvc_s9700rtwv43tr_01b = {
+   .modes = _s9700rtwv43tr_01b_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 155,
+   .height = 90,
+   },
+};
+
 static const struct display_timing urt_umsh_8596md_timing = {
.pixelclock = { 3326, 3326, 3326 },
.hactive = { 800, 800, 800 },
@@ -2214,6 +2237,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "tpk,f10a-0102",
.data = _f10a_0102,
}, {
+   .compatible = "tvc,s9700rtwv43tr-01b",
+   .data = _s9700rtwv43tr_01b,
+   }, {
.compatible = "urt,umsh-8596md-t",
.data = _umsh_8596md_parallel,
}, {
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 1/4] drm/tilcdc: Add support for drm panels

Add support for drm panels to tilcdc. Adding the support on top of the
existing bridge support needs only couple of lines of code when using
using the drm panel bridge helpers.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/Kconfig   |  2 ++
 drivers/gpu/drm/tilcdc/tilcdc_external.c | 29 -
 2 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index 81ac824..5259804 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -4,6 +4,8 @@ config DRM_TILCDC
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
+   select DRM_BRIDGE
+   select DRM_PANEL_BRIDGE
select VIDEOMODE_HELPERS
select BACKLIGHT_CLASS_DEVICE
select BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c 
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 711c7b3..d651bdd 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -188,18 +188,16 @@ int tilcdc_attach_bridge(struct drm_device *ddev, struct 
drm_bridge *bridge)
 int tilcdc_attach_external_device(struct drm_device *ddev)
 {
struct tilcdc_drm_private *priv = ddev->dev_private;
-   struct device_node *remote_node;
struct drm_bridge *bridge;
+   struct drm_panel *panel;
int ret;
 
-   remote_node = of_graph_get_remote_node(ddev->dev->of_node, 0, 0);
-   if (!remote_node)
+   ret = drm_of_find_panel_or_bridge(ddev->dev->of_node, 0, 0,
+ , );
+   if (ret == -ENODEV)
return 0;
-
-   bridge = of_drm_find_bridge(remote_node);
-   of_node_put(remote_node);
-   if (!bridge)
-   return -EPROBE_DEFER;
+   else if (ret)
+   return ret;
 
priv->external_encoder = devm_kzalloc(ddev->dev,
  sizeof(*priv->external_encoder),
@@ -215,10 +213,23 @@ int tilcdc_attach_external_device(struct drm_device *ddev)
return ret;
}
 
+   if (panel) {
+   bridge = devm_drm_panel_bridge_add(ddev->dev, panel,
+  DRM_MODE_CONNECTOR_DPI);
+   if (IS_ERR(bridge)) {
+   ret = PTR_ERR(bridge);
+   goto err_encoder_cleanup;
+   }
+   }
+
ret = tilcdc_attach_bridge(ddev, bridge);
if (ret)
-   drm_encoder_cleanup(priv->external_encoder);
+   goto err_encoder_cleanup;
+
+   return 0;
 
+err_encoder_cleanup:
+   drm_encoder_cleanup(priv->external_encoder);
return ret;
 }
 
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 0/4] drm/tilcdc: Add DRM panel support and use it for am335x-evm

The first patch adds support for drm panels to tilcdc. The second is
just for convenience. The third adds support for am335x-evm's panel to
panel-simple driver. The third changes am335x-evm's dts file to use
panel-simple instead of tilcdc's bundled dpi-panel support.

After the review I will pick the tilcdc patches, but how about the
panel-simple, who will take it?

There is no hurry with the dts patch. We can even wait with it until the
next release, when everything certainly ready for it. The evm works just
fine with the old tilcdc bundled panel support and we probably have to
keep it around indefinately for backward compatibility.

Best regards,
Jyri

Jyri Sarha (4):
  drm/tilcdc: Add support for drm panels
  drm/tilcdc: tilcdc_panel: Rename device from "panel" to "tilcdc-panel"
  drm/panel: simple: Add TVC S9700RTWV43TR-01B 800x480 panel support
  ARM: dts: am335x-evm: Use drm simple-panel instead of tilcdc-panel

 arch/arm/boot/dts/am335x-evm.dts | 44 +---
 drivers/gpu/drm/panel/panel-simple.c | 26 +++
 drivers/gpu/drm/tilcdc/Kconfig   |  2 ++
 drivers/gpu/drm/tilcdc/tilcdc_external.c | 29 ++---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c|  2 +-
 5 files changed, 67 insertions(+), 36 deletions(-)

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

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

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

2018-02-22 Thread Michel Dänzer

On 2018-02-22 10:57 PM, Ben Crocker wrote:
> In radeon_device_init, set the need_dma32 flag for Cedar chips
> (e.g. FirePro 2270).  This fixes, or at least works around, a bug
> on PowerPC exposed by last year's commits
> 
> 8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)
> 
> and
> 
> 253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)
> 
> which enabled the 64-bit DMA iommu bypass.
> 
> This caused the device to freeze, in some cases unrecoverably, and is
> the subject of several bug reports internal to Red Hat.
> 
> Signed-off-by: Ben Crocker 
> ---
>  drivers/gpu/drm/radeon/radeon_device.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index ffc10cadcf34..ba7435bcd208 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1397,6 +1397,11 @@ int radeon_device_init(struct radeon_device *rdev,
>   if ((rdev->flags & RADEON_IS_PCI) &&
>   (rdev->family <= CHIP_RS740))
>   rdev->need_dma32 = true;
> +#ifdef CONFIG_PPC64
> + if ((rdev->flags & (RADEON_IS_PCI | RADEON_IS_PCIE)) &&

Cedar is (like all Radeons from the last decade) always PCIe, so this
flags check is redundant FWIW.


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

Re: [PATCH] drm/amdgpu: Remove duplicate setting of ->need_swiotlb

On Tue, Feb 20, 2018 at 5:44 AM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> There's no need to set this before the number of DMA bits has been
> properly determined.
>
> Signed-off-by: Thierry Reding 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> index 9a170e37fbe7..9cc849f829d0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> @@ -1086,7 +1086,6 @@ static int gmc_v8_0_sw_init(void *handle)
>  */
> adev->need_dma32 = false;
> dma_bits = adev->need_dma32 ? 32 : 40;
> -   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
> r = pci_set_dma_mask(adev->pdev, DMA_BIT_MASK(dma_bits));
> if (r) {
> adev->need_dma32 = true;
> --
> 2.15.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

[Bug 198885] amdgpu.dc=1 on CIK (R4 Mullins APU) brightness impossible to change. by Fn or "echo".

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

--- Comment #3 from Przemek (sop...@gmail.com) ---
And here values from requested files without "amdgpu.dc=1"

"/sys/class/backlight/amdgpu_bl0 # ls -l
razem 0
-r--r--r-- 1 root root 4096 02-22 17:50 actual_brightness
-rw-r--r-- 1 root root 4096 02-22 17:50 bl_power
-rw-r--r-- 1 root root 4096 02-22 17:39 brightness
lrwxrwxrwx 1 root root0 02-22 17:50 device -> ../../card0-eDP-1
-r--r--r-- 1 root root 4096 02-22 17:39 max_brightness
drwxr-xr-x 2 root root0 02-22 17:50 power
lrwxrwxrwx 1 root root0 02-22 17:39 subsystem ->
../../../../../../../class/backlight
-r--r--r-- 1 root root 4096 02-22 17:39 type
-rw-r--r-- 1 root root 4096 02-22 17:38 uevent"

"/sys/class/backlight/amdgpu_bl0 # cat brightness
23"

"/sys/class/backlight/amdgpu_bl0 # cat actual_brightness
23"

"/sys/class/backlight/amdgpu_bl0 # cat max_brightness
255"


With smaller values from previous post (with "amdgpu.dc=1" on kernel
commandline) screen is much brighter, as backlight was set almost 100%.

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

Re: [PATCH 1/4] drm/simple_kms_helper: Add {enable|disable}_vblank callback support

2018-02-22 Thread Daniel Vetter

On Mon, Feb 19, 2018 at 11:11:23AM +0200, Oleksandr Andrushchenko wrote:
> ping
> On 02/12/2018 10:52 AM, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko 
> > 
> > If simple_kms_helper based driver needs to work with vblanks,
> > then it has to provide drm_driver.{enable|disable}_vblank callbacks,
> > because drm_simple_kms_helper.drm_crtc_funcs does not provide any.
> > At the same time drm_driver.{enable|disable}_vblank callbacks
> > are marked as deprecated and shouldn't be used by new drivers.
> > 
> > Fix this by extending drm_simple_kms_helper.drm_crtc_funcs
> > to provide the missing callbacks.
> > 
> > Signed-off-by: Oleksandr Andrushchenko 

lgtm, all 4 applied, thanks for your patches.
-Daniel

> > ---
> >   drivers/gpu/drm/drm_simple_kms_helper.c | 24 
> >   include/drm/drm_simple_kms_helper.h | 18 ++
> >   2 files changed, 42 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index 9d3f6b70812c..9ca8a4a59b74 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -77,6 +77,28 @@ static const struct drm_crtc_helper_funcs 
> > drm_simple_kms_crtc_helper_funcs = {
> > .atomic_disable = drm_simple_kms_crtc_disable,
> >   };
> > +static int drm_simple_kms_crtc_enable_vblank(struct drm_crtc *crtc)
> > +{
> > +   struct drm_simple_display_pipe *pipe;
> > +
> > +   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> > +   if (!pipe->funcs || !pipe->funcs->enable_vblank)
> > +   return 0;
> > +
> > +   return pipe->funcs->enable_vblank(pipe);
> > +}
> > +
> > +static void drm_simple_kms_crtc_disable_vblank(struct drm_crtc *crtc)
> > +{
> > +   struct drm_simple_display_pipe *pipe;
> > +
> > +   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> > +   if (!pipe->funcs || !pipe->funcs->disable_vblank)
> > +   return;
> > +
> > +   pipe->funcs->disable_vblank(pipe);
> > +}
> > +
> >   static const struct drm_crtc_funcs drm_simple_kms_crtc_funcs = {
> > .reset = drm_atomic_helper_crtc_reset,
> > .destroy = drm_crtc_cleanup,
> > @@ -84,6 +106,8 @@ static const struct drm_crtc_funcs 
> > drm_simple_kms_crtc_funcs = {
> > .page_flip = drm_atomic_helper_page_flip,
> > .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> > .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> > +   .enable_vblank = drm_simple_kms_crtc_enable_vblank,
> > +   .disable_vblank = drm_simple_kms_crtc_disable_vblank,
> >   };
> >   static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane,
> > diff --git a/include/drm/drm_simple_kms_helper.h 
> > b/include/drm/drm_simple_kms_helper.h
> > index 6d9adbb46293..79567826b099 100644
> > --- a/include/drm/drm_simple_kms_helper.h
> > +++ b/include/drm/drm_simple_kms_helper.h
> > @@ -93,6 +93,24 @@ struct drm_simple_display_pipe_funcs {
> >  */
> > void (*cleanup_fb)(struct drm_simple_display_pipe *pipe,
> >struct drm_plane_state *plane_state);
> > +
> > +   /**
> > +* @enable_vblank:
> > +*
> > +* Optional, called by _crtc_funcs.enable_vblank. Please read
> > +* the documentation for the _crtc_funcs.enable_vblank hook for
> > +* more details.
> > +*/
> > +   int (*enable_vblank)(struct drm_simple_display_pipe *pipe);
> > +
> > +   /**
> > +* @disable_vblank:
> > +*
> > +* Optional, called by _crtc_funcs.disable_vblank. Please read
> > +* the documentation for the _crtc_funcs.disable_vblank hook for
> > +* more details.
> > +*/
> > +   void (*disable_vblank)(struct drm_simple_display_pipe *pipe);
> >   };
> >   /**
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

In radeon_device_init, set the need_dma32 flag for Cedar chips
(e.g. FirePro 2270).  This fixes, or at least works around, a bug
on PowerPC exposed by last year's commits

8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)

and

253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)

which enabled the 64-bit DMA iommu bypass.

This caused the device to freeze, in some cases unrecoverably, and is
the subject of several bug reports internal to Red Hat.

Signed-off-by: Ben Crocker 
---
 drivers/gpu/drm/radeon/radeon_device.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index ffc10cadcf34..ba7435bcd208 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1397,6 +1397,11 @@ int radeon_device_init(struct radeon_device *rdev,
if ((rdev->flags & RADEON_IS_PCI) &&
(rdev->family <= CHIP_RS740))
rdev->need_dma32 = true;
+#ifdef CONFIG_PPC64
+   if ((rdev->flags & (RADEON_IS_PCI | RADEON_IS_PCIE)) &&
+   (rdev->family == CHIP_CEDAR))
+   rdev->need_dma32 = true;
+#endif
 
dma_bits = rdev->need_dma32 ? 32 : 40;
r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
-- 
2.13.6

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

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

On Thu, Feb 22, 2018 at 4:51 PM, Ben Crocker  wrote:
> In radeon_device_init, set the need_dma32 flag for Cedar chips
> (e.g. FirePro 2270).  This fixes, or at least works around, a bug
> on PowerPC exposed by last year's commits
>
> 8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)
>
> and
>
> 253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)
>
> which enabled the 64-bit DMA iommu bypass.
>
> This caused the device to freeze, in some cases unrecoverably, and is
> the subject of several bug reports internal to Red Hat.
>
> Signed-off-by: Ben Crocker 
> ---
>  drivers/gpu/drm/radeon/radeon_device.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index ffc10cadcf34..ba7435bcd208 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1397,6 +1397,11 @@ int radeon_device_init(struct radeon_device *rdev,
> if ((rdev->flags & RADEON_IS_PCI) &&
> (rdev->family <= CHIP_RS740))
> rdev->need_dma32 = true;
> +#ifdef CONFIG_PPC64
> +   if ((rdev->flags & (RADEON_IS_PCI | RADEON_IS_PCIE)) &&
> +   (rdev->family == CHIP_CEDAR))
> +   rdev->need_dma32 = true;
> +#endif

You can drop the PCI and PCIE checks and just check the family.

Alex

>
> dma_bits = rdev->need_dma32 ? 32 : 40;
> r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
> --
> 2.13.6
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

In radeon_device_init, set the need_dma32 flag for Cedar chips
(e.g. FirePro 2270).  This fixes, or at least works around, a bug
on PowerPC exposed by last year's commits

8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)

and

253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)

which enabled the 64-bit DMA iommu bypass.

This caused the device to freeze, in some cases unrecoverably, and is
the subject of several bug reports internal to Red Hat.

Signed-off-by: Ben Crocker 
---
 drivers/gpu/drm/radeon/radeon_device.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index ffc10cadcf34..ba7435bcd208 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1397,6 +1397,11 @@ int radeon_device_init(struct radeon_device *rdev,
if ((rdev->flags & RADEON_IS_PCI) &&
(rdev->family <= CHIP_RS740))
rdev->need_dma32 = true;
+#ifdef CONFIG_PPC64
+   if ((rdev->flags & (RADEON_IS_PCI | RADEON_IS_PCIE)) &&
+   (rdev->family == CHIP_CEDAR))
+   rdev->need_dma32 = true;
+#endif
 
dma_bits = rdev->need_dma32 ? 32 : 40;
r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
-- 
2.13.6

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

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar