[Bug 101478] Display not working after a certain commit

[bugzilla-daemon]

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

--- Comment #2 from John  ---
Oops, sorry about that.

And thank you for the quick reply!

-- 
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 101478] Display not working after a certain commit

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #1 from Michel Dänzer  ---
[3.750697] amdgpu :01:00.0: SI support provided by radeon.
[3.750698] amdgpu :01:00.0: Use radeon.si_support=0 amdgpu.si_support=1
to override.

You'll need to follow this suggestion.

-- 
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 196117] amdgpu - RX 480 (polaris) - freeze during boot

[bugzilla-daemon]

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

--- Comment #2 from Michel Dänzer (mic...@daenzer.net) ---
Sounds like maybe some files under /lib/firmware/amdgpu/ are missing in the
initrd. In order to get more information, try booting with

 modprobe.blacklist=amdgpu

on the kernel command line and then run

 sudo modprobe amdgpu

manually and check dmesg.

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

Re: [PATCH] drm: exynos: dsi: fix to return -ENODEV when DSI_PORT_OUT is not found

[Inki Dae]

Hi Shuah,

2017년 06월 17일 07:56에 Shuah Khan 이(가) 쓴 글:
> Fix exynos_dsi_parse_dt() to return -ENODEV when of_graph_get_remote_node()
> doesn't find DSI_PORT_OUT. -ENODEV is the correct error code to return and
> this change makes exynos behavior consistent with rest of the drm drivers.

For this, there is one relevant patch below,
https://patchwork.kernel.org/patch/9785517/

In case of Exynos SoC, bridge node is required optionally - one bridge device 
such as mDNIe or MIC could be placed between FIMD and MIPI-DSI devices but this 
pipeline is configurable - user can decide Display hardware pipeline by setting 
the sysreg register.
So no error should be returned.

Thanks,
Inki Dae

> 
> Signed-off-by: Shuah Khan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index e337cd2..cb99e82 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1652,7 +1652,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>  
>   dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_OUT, 0);
>   if (!dsi->bridge_node)
> - return -EINVAL;
> + return -ENODEV;
>  
>   return 0;
>  }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: dsi: do not try to find bridge

[Inki Dae]

Hi Shuah,

2017년 06월 17일 05:16에 Shuah Khan 이(가) 쓴 글:
> On 06/16/2017 08:16 AM, Shuah Khan wrote:
>> Hi Inki,
>>
>> On Fri, Jun 16, 2017 at 1:50 AM, Inki Dae  wrote:
>>> It doesn't need to try to find a bridge if bridge node doesn't exist.
>>>
>>> Signed-off-by: Inki Dae 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 +---
>>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index d404de8..e337cd2 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -1687,9 +1687,11 @@ static int exynos_dsi_bind(struct device *dev, 
>>> struct device *master,
>>> return ret;
>>> }
>>>
>>> -   bridge = of_drm_find_bridge(dsi->bridge_node);
>>
>> This is more of question than comment. I am seeing in some places,
>> such as mtk_dpi_probe(), of_node_put() is called right after
>> of_drm_find_bridge() whether or not bridge_node is found.
>>
>> In this case, of_node_put() is done from exynos_dsi_remove() which looks
>> correct to me.
>>
>> However, there is the discrepancy. One of these is incorrect perhaps?
>> When is the right time to call of_node_put()?

No problem but seems more reasonable to call of_node_put() right after 
of_drm_find_bridge() because there is no reason to keep bridge_node after 
binding it.
Could you clean up this?

Thanks,
Inki Dae

>>
>>> -   if (bridge)
>>> -   drm_bridge_attach(encoder, bridge, NULL);
>>> +   if (dsi->bridge_node) {
>>> +   bridge = of_drm_find_bridge(dsi->bridge_node);
>>> +   if (bridge)
>>> +   drm_bridge_attach(encoder, bridge, NULL);
>>> +   }
>>>
>>> return mipi_dsi_host_register(>dsi_host);
>>>  }
>>> --
>>> 1.9.1
>>
>> Looks good to me.
>>
>> Reviewed-by: Shuah Khan 
>>
> 
> I tested this on odroid-xu4
> 
> Tested-by: Shuah Khan 
> 
> thanks,
> -- Shuah
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Thu, Jun 15, 2017 at 10:28:31AM +0300, Peter Ujfalusi wrote:
> On 2017-06-15 01:11, Aaro Koskinen wrote:
> > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> > is no display.
> > 
> > Bisected to:
> > 
> > a09d2bc1503508c17ef3a71c6b1905e3660f3029 is the first bad commit
> > commit a09d2bc1503508c17ef3a71c6b1905e3660f3029
> > Author: Peter Ujfalusi 
> > Date:   Tue May 3 22:08:01 2016 +0300
> > 
> > drm/omap: Use omapdss_stack_is_ready() to check that the display stack 
> > is up
> > 
> > Instead of 'guessing' based on aliases of the status of the DSS drivers,
> > use the new interface to check that all needed drivers are loaded.
> > In this way we can be sure that all needed drivers are loaded so it is
> > safe to continue the probing of omapdrm.
> > This method will allow the omapdrm to be probed 'headless', without
> > outputs.
> > 
> > Signed-off-by: Peter Ujfalusi 
> > Signed-off-by: Tomi Valkeinen 
> > 
> > Reverting the commit seems to fix the issue.
> 
> When you revert this patch do you see a warning saying:
> "could not connect display: blah" ? if so what is 'blah'?

No.

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

Re: [Freedreno] [PATCH] fixup! drm/msm: Separate locking of buffer resources from struct_mutex

[Sushmita Susheelendra]

Sounds good.

On 2017-06-16 15:44, Rob Clark wrote:

On Fri, Jun 16, 2017 at 5:32 PM,   wrote:

Hi Rob,

This looks good to me!

Just one nit: msm_gem_vunmap becomes very shrinker specific as it 
holds the

msm_obj->lock with the shrinker class. Should we have the caller i.e.
msm_gem_shrinker_vmap hold it instead? Or change it's name to
msm_gem_vunmap_shrinker or something like that...?


Hmm, I suppose I could pass the lock class in to msm_gem_vunmap() in
case we ever want to call it elsewhere (iirc, i915 did something like
that)

BR,
-R

It does make sense to make the madv/priv->inactive_list locking 
cleanup

separately.

Thanks,
Sushmita



On 2017-06-16 08:22, Rob Clark wrote:


---
Ok, 2nd fixup to handle vmap shrinking.

 drivers/gpu/drm/msm/msm_gem.c | 44
+++
 1 file changed, 36 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c 
b/drivers/gpu/drm/msm/msm_gem.c

index f5d1f84..3190e05 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -42,6 +42,9 @@ enum {
OBJ_LOCK_SHRINKER,
 };

+static void msm_gem_vunmap_locked(struct drm_gem_object *obj);
+
+
 static dma_addr_t physaddr(struct drm_gem_object *obj)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);
@@ -484,6 +487,7 @@ int msm_gem_dumb_map_offset(struct drm_file 
*file,

struct drm_device *dev,
 void *msm_gem_get_vaddr(struct drm_gem_object *obj)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);
+   int ret = 0;

mutex_lock(_obj->lock);

@@ -492,22 +496,35 @@ void *msm_gem_get_vaddr(struct drm_gem_object 
*obj)

return ERR_PTR(-EBUSY);
}

+   /* increment vmap_count *before* vmap() call, so shrinker can
+* check vmap_count (is_vunmapable()) outside of 
msm_obj->lock.

+* This guarantees that we won't try to msm_gem_vunmap() this
+* same object from within the vmap() call (while we already
+* hold msm_obj->lock)
+*/
+   msm_obj->vmap_count++;
+
if (!msm_obj->vaddr) {
struct page **pages = get_pages(obj);
if (IS_ERR(pages)) {
-   mutex_unlock(_obj->lock);
-   return ERR_CAST(pages);
+   ret = PTR_ERR(pages);
+   goto fail;
}
msm_obj->vaddr = vmap(pages, obj->size >> PAGE_SHIFT,
VM_MAP, 
pgprot_writecombine(PAGE_KERNEL));

if (msm_obj->vaddr == NULL) {
-   mutex_unlock(_obj->lock);
-   return ERR_PTR(-ENOMEM);
+   ret = -ENOMEM;
+   goto fail;
}
}
-   msm_obj->vmap_count++;
+
mutex_unlock(_obj->lock);
return msm_obj->vaddr;
+
+fail:
+   msm_obj->vmap_count--;
+   mutex_unlock(_obj->lock);
+   return ERR_PTR(ret);
 }

 void msm_gem_put_vaddr(struct drm_gem_object *obj)
@@ -554,7 +571,7 @@ void msm_gem_purge(struct drm_gem_object *obj)

put_iova(obj);

-   msm_gem_vunmap(obj);
+   msm_gem_vunmap_locked(obj);

put_pages(obj);

@@ -576,10 +593,12 @@ void msm_gem_purge(struct drm_gem_object *obj)
mutex_unlock(_obj->lock);
 }

-void msm_gem_vunmap(struct drm_gem_object *obj)
+static void msm_gem_vunmap_locked(struct drm_gem_object *obj)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);

+   WARN_ON(!mutex_is_locked(_obj->lock));
+
if (!msm_obj->vaddr || WARN_ON(!is_vunmapable(msm_obj)))
return;

@@ -587,6 +606,15 @@ void msm_gem_vunmap(struct drm_gem_object *obj)
msm_obj->vaddr = NULL;
 }

+void msm_gem_vunmap(struct drm_gem_object *obj)
+{
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
+
+   mutex_lock_nested(_obj->lock, OBJ_LOCK_SHRINKER);
+   msm_gem_vunmap_locked(obj);
+   mutex_unlock(_obj->lock);
+}
+
 /* must be called before _move_to_active().. */
 int msm_gem_sync_object(struct drm_gem_object *obj,
struct msm_fence_context *fctx, bool exclusive)
@@ -799,7 +827,7 @@ void msm_gem_free_object(struct drm_gem_object 
*obj)


drm_prime_gem_destroy(obj, msm_obj->sgt);
} else {
-   msm_gem_vunmap(obj);
+   msm_gem_vunmap_locked(obj);
put_pages(obj);
}

___
Freedreno mailing list
freedr...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

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

[RFC PATCH v2 3/3] drm: atmel-hlcdc: add clut support for legacy fbdev

[Peter Rosin]

The clut is not synchronized with the drm gamma_lut state.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 53 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 12 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   |  4 ++
 3 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 694adcc..4bee26e 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -140,6 +140,58 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
   cfg);
 }
 
+static void
+atmel_hlcdc_crtc_load_lut(struct drm_crtc *c)
+{
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+   struct atmel_hlcdc_dc *dc = crtc->dc;
+   uint16_t *red = c->gamma_store;
+   uint16_t *green = red + c->gamma_size;
+   uint16_t *blue = green + c->gamma_size;
+   int layer;
+   int idx;
+
+   for (layer = 0; layer < ATMEL_HLCDC_MAX_LAYERS; layer++) {
+   if (!dc->layers[layer])
+   continue;
+
+   for (idx = 0; idx < ATMEL_HLCDC_CLUT_SIZE; idx++) {
+   u32 val = ((red[idx] << 8) & 0xff) |
+   (green[idx] & 0xff00) |
+   (blue[idx] >> 8);
+
+   atmel_hlcdc_layer_write_clut(dc->layers[layer],
+idx, val);
+   }
+   }
+}
+
+void atmel_hlcdc_gamma_set(struct drm_crtc *c,
+  u16 r, u16 g, u16 b, int idx)
+{
+   if (idx < 0 || idx >= c->gamma_size)
+   return;
+
+   c->gamma_store[idx] = r;
+   idx += c->gamma_size;
+   c->gamma_store[idx] = g;
+   idx += c->gamma_size;
+   c->gamma_store[idx] = b;
+}
+
+void atmel_hlcdc_gamma_get(struct drm_crtc *c,
+  u16 *r, u16 *g, u16 *b, int idx)
+{
+   if (idx < 0 || idx >= c->gamma_size)
+   return;
+
+   *r = c->gamma_store[idx];
+   idx += c->gamma_size;
+   *g = c->gamma_store[idx];
+   idx += c->gamma_size;
+   *b = c->gamma_store[idx];
+}
+
 static enum drm_mode_status
 atmel_hlcdc_crtc_mode_valid(struct drm_crtc *c,
const struct drm_display_mode *mode)
@@ -319,6 +371,7 @@ static const struct drm_crtc_helper_funcs 
lcdc_crtc_helper_funcs = {
.mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
.mode_set_base = drm_helper_crtc_mode_set_base,
+   .load_lut = atmel_hlcdc_crtc_load_lut,
.disable = atmel_hlcdc_crtc_disable,
.enable = atmel_hlcdc_crtc_enable,
.atomic_check = atmel_hlcdc_crtc_atomic_check,
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 4f6ef07..9a09c73 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -601,6 +601,12 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device 
*dev)
return 0;
 }
 
+static const struct drm_fb_helper_funcs atmel_hlcdc_fb_cma_helper_funcs = {
+   .gamma_set  = atmel_hlcdc_gamma_set,
+   .gamma_get  = atmel_hlcdc_gamma_get,
+   .fb_probe   = drm_fbdev_cma_create,
+};
+
 static int atmel_hlcdc_dc_load(struct drm_device *dev)
 {
struct platform_device *pdev = to_platform_device(dev->dev);
@@ -664,8 +670,10 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
 
platform_set_drvdata(pdev, dev);
 
-   dc->fbdev = drm_fbdev_cma_init(dev, 24,
-   dev->mode_config.num_connector);
+   dc->fbdev = drm_fbdev_cma_init_with_funcs2(dev, 24,
+   dev->mode_config.num_connector,
+   NULL,
+   _hlcdc_fb_cma_helper_funcs);
if (IS_ERR(dc->fbdev))
dc->fbdev = NULL;
 
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 709f7b9..1b13224 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -448,6 +449,9 @@ void atmel_hlcdc_plane_irq(struct atmel_hlcdc_plane *plane);
 int atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state);
 int atmel_hlcdc_plane_prepare_ahb_routing(struct drm_crtc_state *c_state);
 
+void atmel_hlcdc_gamma_set(struct drm_crtc *c, u16 r, u16 g, u16 b, int idx);
+void atmel_hlcdc_gamma_get(struct drm_crtc *c, u16 *r, u16 *g, u16 *b, int 
idx);
+
 void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
 
 int atmel_hlcdc_crtc_create(struct drm_device *dev);
-- 
2.1.4

___

[RFC PATCH v2 1/3] drm: atmel-hlcdc: add support for 8-bit color lookup table mode

[Peter Rosin]

All layers of all supported chips support this, the only variable is the
base address of the lookup table in the register map.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  5 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 13 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 16 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 29 +
 4 files changed, 63 insertions(+)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 5348985..694adcc 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -429,6 +429,8 @@ static const struct drm_crtc_funcs atmel_hlcdc_crtc_funcs = 
{
.atomic_destroy_state = atmel_hlcdc_crtc_destroy_state,
.enable_vblank = atmel_hlcdc_crtc_enable_vblank,
.disable_vblank = atmel_hlcdc_crtc_disable_vblank,
+   .set_property = drm_atomic_helper_crtc_set_property,
+   .gamma_set = drm_atomic_helper_legacy_gamma_set,
 };
 
 int atmel_hlcdc_crtc_create(struct drm_device *dev)
@@ -484,6 +486,9 @@ int atmel_hlcdc_crtc_create(struct drm_device *dev)
drm_crtc_helper_add(>base, _crtc_helper_funcs);
drm_crtc_vblank_reset(>base);
 
+   drm_mode_crtc_set_gamma_size(>base, ATMEL_HLCDC_CLUT_SIZE);
+   drm_crtc_enable_color_mgmt(>base, 0, false, 
ATMEL_HLCDC_CLUT_SIZE);
+
dc->crtc = >base;
 
return 0;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 30dbffd..4f6ef07 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -42,6 +42,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9n12_layers[] = {
.default_color = 3,
.general_config = 4,
},
+   .clut_offset = 0x400,
},
 };
 
@@ -73,6 +74,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.disc_pos = 5,
.disc_size = 6,
},
+   .clut_offset = 0x400,
},
{
.name = "overlay1",
@@ -91,6 +93,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0x800,
},
{
.name = "high-end-overlay",
@@ -112,6 +115,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.scaler_config = 13,
.csc = 14,
},
+   .clut_offset = 0x1000,
},
{
.name = "cursor",
@@ -131,6 +135,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0x1400,
},
 };
 
@@ -162,6 +167,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
.disc_pos = 5,
.disc_size = 6,
},
+   .clut_offset = 0x600,
},
{
.name = "overlay1",
@@ -180,6 +186,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0xa00,
},
{
.name = "overlay2",
@@ -198,6 +205,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0xe00,
},
{
.name = "high-end-overlay",
@@ -223,6 +231,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
},
.csc = 14,
},
+   .clut_offset = 0x1200,
},
{
.name = "cursor",
@@ -244,6 +253,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
.general_config = 9,
.scaler_config = 13,
},
+   .clut_offset = 0x1600,
},
 };
 
@@ -275,6 +285,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d4_layers[] = {
.disc_pos = 5,
.disc_size = 6,
},
+   .clut_offset = 0x600,
},
{
.name = "overlay1",
@@ -293,6 +304,7 @@ static const struct atmel_hlcdc_layer_desc 

Re: [Freedreno] [PATCH] fixup! drm/msm: Separate locking of buffer resources from struct_mutex

[ssusheel]

Hi Rob,

This looks good to me!

Just one nit: msm_gem_vunmap becomes very shrinker specific as it holds 
the msm_obj->lock with the shrinker class. Should we have the caller 
i.e. msm_gem_shrinker_vmap hold it instead? Or change it's name to 
msm_gem_vunmap_shrinker or something like that...?


It does make sense to make the madv/priv->inactive_list locking cleanup 
separately.


Thanks,
Sushmita


On 2017-06-16 08:22, Rob Clark wrote:

---
Ok, 2nd fixup to handle vmap shrinking.

 drivers/gpu/drm/msm/msm_gem.c | 44 
+++

 1 file changed, 36 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c 
b/drivers/gpu/drm/msm/msm_gem.c

index f5d1f84..3190e05 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -42,6 +42,9 @@ enum {
OBJ_LOCK_SHRINKER,
 };

+static void msm_gem_vunmap_locked(struct drm_gem_object *obj);
+
+
 static dma_addr_t physaddr(struct drm_gem_object *obj)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);
@@ -484,6 +487,7 @@ int msm_gem_dumb_map_offset(struct drm_file *file,
struct drm_device *dev,
 void *msm_gem_get_vaddr(struct drm_gem_object *obj)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);
+   int ret = 0;

mutex_lock(_obj->lock);

@@ -492,22 +496,35 @@ void *msm_gem_get_vaddr(struct drm_gem_object 
*obj)

return ERR_PTR(-EBUSY);
}

+   /* increment vmap_count *before* vmap() call, so shrinker can
+* check vmap_count (is_vunmapable()) outside of msm_obj->lock.
+* This guarantees that we won't try to msm_gem_vunmap() this
+* same object from within the vmap() call (while we already
+* hold msm_obj->lock)
+*/
+   msm_obj->vmap_count++;
+
if (!msm_obj->vaddr) {
struct page **pages = get_pages(obj);
if (IS_ERR(pages)) {
-   mutex_unlock(_obj->lock);
-   return ERR_CAST(pages);
+   ret = PTR_ERR(pages);
+   goto fail;
}
msm_obj->vaddr = vmap(pages, obj->size >> PAGE_SHIFT,
VM_MAP, pgprot_writecombine(PAGE_KERNEL));
if (msm_obj->vaddr == NULL) {
-   mutex_unlock(_obj->lock);
-   return ERR_PTR(-ENOMEM);
+   ret = -ENOMEM;
+   goto fail;
}
}
-   msm_obj->vmap_count++;
+
mutex_unlock(_obj->lock);
return msm_obj->vaddr;
+
+fail:
+   msm_obj->vmap_count--;
+   mutex_unlock(_obj->lock);
+   return ERR_PTR(ret);
 }

 void msm_gem_put_vaddr(struct drm_gem_object *obj)
@@ -554,7 +571,7 @@ void msm_gem_purge(struct drm_gem_object *obj)

put_iova(obj);

-   msm_gem_vunmap(obj);
+   msm_gem_vunmap_locked(obj);

put_pages(obj);

@@ -576,10 +593,12 @@ void msm_gem_purge(struct drm_gem_object *obj)
mutex_unlock(_obj->lock);
 }

-void msm_gem_vunmap(struct drm_gem_object *obj)
+static void msm_gem_vunmap_locked(struct drm_gem_object *obj)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);

+   WARN_ON(!mutex_is_locked(_obj->lock));
+
if (!msm_obj->vaddr || WARN_ON(!is_vunmapable(msm_obj)))
return;

@@ -587,6 +606,15 @@ void msm_gem_vunmap(struct drm_gem_object *obj)
msm_obj->vaddr = NULL;
 }

+void msm_gem_vunmap(struct drm_gem_object *obj)
+{
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
+
+   mutex_lock_nested(_obj->lock, OBJ_LOCK_SHRINKER);
+   msm_gem_vunmap_locked(obj);
+   mutex_unlock(_obj->lock);
+}
+
 /* must be called before _move_to_active().. */
 int msm_gem_sync_object(struct drm_gem_object *obj,
struct msm_fence_context *fctx, bool exclusive)
@@ -799,7 +827,7 @@ void msm_gem_free_object(struct drm_gem_object 
*obj)


drm_prime_gem_destroy(obj, msm_obj->sgt);
} else {
-   msm_gem_vunmap(obj);
+   msm_gem_vunmap_locked(obj);
put_pages(obj);
}

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

[RFC PATCH 2/3] drm/fb-cma-helper: expose more of fb cma guts

[Peter Rosin]

DRM drivers supporting clut may want a convenient way to only use
non-default .gamma_set and .gamma_get ops in the drm_fb_helper_funcs
in order to avoid the following

/*
 * The driver really shouldn't advertise pseudo/directcolor
 * visuals if it can't deal with the palette.
 */
if (WARN_ON(!fb_helper->funcs->gamma_set ||
!fb_helper->funcs->gamma_get))
return -EINVAL;

warning in drm_fb_helper.c:setcolreg().

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 55 ++---
 include/drm/drm_fb_cma_helper.h |  8 +-
 2 files changed, 52 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 53f9bdf..ef96227 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -426,7 +426,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
kfree(fbi->fbops);
 }
 
-static int
+/**
+ * drm_fbdev_cma_create() - Default fb_probe() function for fb_cma_helper_funcs
+ * @helper: The fb_helper to create a cma for
+ * @sizes: The fbdev sizes
+ */
+int
 drm_fbdev_cma_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
 {
@@ -507,23 +512,28 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
drm_gem_object_put_unlocked(>base);
return ret;
 }
+EXPORT_SYMBOL_GPL(drm_fbdev_cma_create);
 
 static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
.fb_probe = drm_fbdev_cma_create,
 };
 
 /**
- * drm_fbdev_cma_init_with_funcs() - Allocate and initializes a drm_fbdev_cma 
struct
+ * drm_fbdev_cma_init_with_funcs2() - Allocate and initializes a drm_fbdev_cma 
struct
  * @dev: DRM device
  * @preferred_bpp: Preferred bits per pixel for the device
  * @max_conn_count: Maximum number of connectors
- * @funcs: fb helper functions, in particular a custom dirty() callback
+ * @framebuffer_funcs: framebuffer functions, in particular a custom dirty() 
callback
+ * @fb_helper_funcs: fb helper functions, in particular custom gamma_set() and 
gamma_get() callbacks
+ *
+ * If framebuffer_funcs or fb_helper_funcs are NULL, default functions are 
used.
  *
  * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
  */
-struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct drm_device *dev,
+struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs2(struct drm_device *dev,
unsigned int preferred_bpp, unsigned int max_conn_count,
-   const struct drm_framebuffer_funcs *funcs)
+   const struct drm_framebuffer_funcs *framebuffer_funcs,
+   const struct drm_fb_helper_funcs *fb_helper_funcs)
 {
struct drm_fbdev_cma *fbdev_cma;
struct drm_fb_helper *helper;
@@ -534,11 +544,17 @@ struct drm_fbdev_cma 
*drm_fbdev_cma_init_with_funcs(struct drm_device *dev,
dev_err(dev->dev, "Failed to allocate drm fbdev.\n");
return ERR_PTR(-ENOMEM);
}
-   fbdev_cma->fb_funcs = funcs;
+
+   if (!framebuffer_funcs)
+   framebuffer_funcs = _fb_cma_funcs;
+   if (!fb_helper_funcs)
+   fb_helper_funcs = _fb_cma_helper_funcs;
+
+   fbdev_cma->fb_funcs = framebuffer_funcs;
 
helper = _cma->fb_helper;
 
-   drm_fb_helper_prepare(dev, helper, _fb_cma_helper_funcs);
+   drm_fb_helper_prepare(dev, helper, fb_helper_funcs);
 
ret = drm_fb_helper_init(dev, helper, max_conn_count);
if (ret < 0) {
@@ -568,6 +584,25 @@ struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct 
drm_device *dev,
 
return ERR_PTR(ret);
 }
+EXPORT_SYMBOL_GPL(drm_fbdev_cma_init_with_funcs2);
+
+/**
+ * drm_fbdev_cma_init_with_funcs() - Allocate and initializes a drm_fbdev_cma 
struct
+ * @dev: DRM device
+ * @preferred_bpp: Preferred bits per pixel for the device
+ * @max_conn_count: Maximum number of connectors
+ * @framebuffer_funcs: framebuffer functions, in particular a custom dirty() 
callback
+ *
+ * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
+ */
+struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct drm_device *dev,
+   unsigned int preferred_bpp, unsigned int max_conn_count,
+   const struct drm_framebuffer_funcs *framebuffer_funcs)
+{
+   return drm_fbdev_cma_init_with_funcs2(dev, preferred_bpp,
+ max_conn_count,
+ framebuffer_funcs, NULL);
+}
 EXPORT_SYMBOL_GPL(drm_fbdev_cma_init_with_funcs);
 
 /**
@@ -581,9 +616,9 @@ EXPORT_SYMBOL_GPL(drm_fbdev_cma_init_with_funcs);
 struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev,
unsigned int preferred_bpp, unsigned int max_conn_count)
 {
-   return drm_fbdev_cma_init_with_funcs(dev, preferred_bpp,
-max_conn_count,
-_fb_cma_funcs);
+ 

[RFC PATCH 3/3] atmel-hlcdc: add clut support for legacy fbdev

[Peter Rosin]

The clut is also synchronized with the drm gamma_lut state.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 49 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 12 +--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   |  4 +++
 3 files changed, 63 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 75871b5..54ecf56 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -158,6 +158,54 @@ atmel_hlcdc_crtc_load_lut(struct drm_crtc *c)
}
 }
 
+void atmel_hlcdc_gamma_set(struct drm_crtc *c,
+  u16 r, u16 g, u16 b, int idx)
+{
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+   struct drm_crtc_state *state = c->state;
+   struct drm_color_lut *lut;
+
+   if (idx < 0 || idx > 255)
+   return;
+
+   if (state->gamma_lut) {
+   lut = (struct drm_color_lut *)state->gamma_lut->data;
+
+   lut[idx].red = r;
+   lut[idx].green = g;
+   lut[idx].blue = b;
+   }
+
+   crtc->clut[idx] = ((r << 8) & 0xff) | (g & 0xff00) | (b >> 8);
+}
+
+void atmel_hlcdc_gamma_get(struct drm_crtc *c,
+  u16 *r, u16 *g, u16 *b, int idx)
+{
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+   struct drm_crtc_state *state = c->state;
+   struct drm_color_lut *lut;
+
+   if (idx < 0 || idx > 255)
+   return;
+
+   if (state->gamma_lut) {
+   lut = (struct drm_color_lut *)state->gamma_lut->data;
+
+   *r = lut[idx].red;
+   *g = lut[idx].green;
+   *b = lut[idx].blue;
+   return;
+   }
+
+   *r = (crtc->clut[idx] >> 8) & 0xff00;
+   *g = crtc->clut[idx] & 0xff00;
+   *b = (crtc->clut[idx] << 8) & 0xff00;
+   *r |= *r >> 8;
+   *g |= *g >> 8;
+   *b |= *b >> 8;
+}
+
 static void
 atmel_hlcdc_crtc_flush_lut(struct drm_crtc *c)
 {
@@ -363,6 +411,7 @@ static const struct drm_crtc_helper_funcs 
lcdc_crtc_helper_funcs = {
.mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
.mode_set_base = drm_helper_crtc_mode_set_base,
+   .load_lut = atmel_hlcdc_crtc_load_lut,
.disable = atmel_hlcdc_crtc_disable,
.enable = atmel_hlcdc_crtc_enable,
.atomic_check = atmel_hlcdc_crtc_atomic_check,
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 4f6ef07..9a09c73 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -601,6 +601,12 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device 
*dev)
return 0;
 }
 
+static const struct drm_fb_helper_funcs atmel_hlcdc_fb_cma_helper_funcs = {
+   .gamma_set  = atmel_hlcdc_gamma_set,
+   .gamma_get  = atmel_hlcdc_gamma_get,
+   .fb_probe   = drm_fbdev_cma_create,
+};
+
 static int atmel_hlcdc_dc_load(struct drm_device *dev)
 {
struct platform_device *pdev = to_platform_device(dev->dev);
@@ -664,8 +670,10 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
 
platform_set_drvdata(pdev, dev);
 
-   dc->fbdev = drm_fbdev_cma_init(dev, 24,
-   dev->mode_config.num_connector);
+   dc->fbdev = drm_fbdev_cma_init_with_funcs2(dev, 24,
+   dev->mode_config.num_connector,
+   NULL,
+   _hlcdc_fb_cma_helper_funcs);
if (IS_ERR(dc->fbdev))
dc->fbdev = NULL;
 
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 709f7b9..1b13224 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -448,6 +449,9 @@ void atmel_hlcdc_plane_irq(struct atmel_hlcdc_plane *plane);
 int atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state);
 int atmel_hlcdc_plane_prepare_ahb_routing(struct drm_crtc_state *c_state);
 
+void atmel_hlcdc_gamma_set(struct drm_crtc *c, u16 r, u16 g, u16 b, int idx);
+void atmel_hlcdc_gamma_get(struct drm_crtc *c, u16 *r, u16 *g, u16 *b, int 
idx);
+
 void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
 
 int atmel_hlcdc_crtc_create(struct drm_device *dev);
-- 
2.1.4

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

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> On 15/06/17 01:11, Aaro Koskinen wrote:
> > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> > is no display.
> 
> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
> check? If that's the case then this is easier to debug.

Yes I think so, I added debug prints to omap_connect_dssdevs() and
pdev_probe(), and it's omapdss_stack_is_ready() that is failing.

> > Bisected to:
> > 
> > a09d2bc1503508c17ef3a71c6b1905e3660f3029 is the first bad commit
> > commit a09d2bc1503508c17ef3a71c6b1905e3660f3029
> > Author: Peter Ujfalusi 
> > Date:   Tue May 3 22:08:01 2016 +0300
> > 
> > drm/omap: Use omapdss_stack_is_ready() to check that the display stack 
> > is up
> > 
> > Instead of 'guessing' based on aliases of the status of the DSS drivers,
> > use the new interface to check that all needed drivers are loaded.
> > In this way we can be sure that all needed drivers are loaded so it is
> > safe to continue the probing of omapdrm.
> > This method will allow the omapdrm to be probed 'headless', without
> > outputs.
> > 
> > Signed-off-by: Peter Ujfalusi 
> > Signed-off-by: Tomi Valkeinen 
> > 
> > Reverting the commit seems to fix the issue.
> 
> This is probably "fixed" by adding the display aliases into the n900 dts
> file. The aliases should not really be required, although they are
> recommended. Without the aliases the order of the displays is random,
> and n900 could end up using tv-out as the first display. But even then,
> the displays should still work.

I'm using up-to-date DTS from the kernel tree.

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

Re: [PATCH] drm/exynos: dsi: do not try to find bridge

[Shuah Khan]

Hi Inki,

On Fri, Jun 16, 2017 at 1:50 AM, Inki Dae  wrote:
> It doesn't need to try to find a bridge if bridge node doesn't exist.
>
> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index d404de8..e337cd2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1687,9 +1687,11 @@ static int exynos_dsi_bind(struct device *dev, struct 
> device *master,
> return ret;
> }
>
> -   bridge = of_drm_find_bridge(dsi->bridge_node);

This is more of question than comment. I am seeing in some places,
such as mtk_dpi_probe(), of_node_put() is called right after
of_drm_find_bridge() whether or not bridge_node is found.

In this case, of_node_put() is done from exynos_dsi_remove() which looks
correct to me.

However, there is the discrepancy. One of these is incorrect perhaps?
When is the right time to call of_node_put()?

> -   if (bridge)
> -   drm_bridge_attach(encoder, bridge, NULL);
> +   if (dsi->bridge_node) {
> +   bridge = of_drm_find_bridge(dsi->bridge_node);
> +   if (bridge)
> +   drm_bridge_attach(encoder, bridge, NULL);
> +   }
>
> return mipi_dsi_host_register(>dsi_host);
>  }
> --
> 1.9.1

Looks good to me.

Reviewed-by: Shuah Khan 

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

Re: [PATCH 03/44] dmaengine: ioat: don't use DMA_ERROR_CODE

[Alexander Duyck]

On Fri, Jun 16, 2017 at 11:10 AM, Christoph Hellwig  wrote:
> DMA_ERROR_CODE is not a public API and will go away.  Instead properly
> unwind based on the loop counter.
>
> Signed-off-by: Christoph Hellwig 
> Acked-by: Dave Jiang 
> Acked-By: Vinod Koul 
> ---
>  drivers/dma/ioat/init.c | 24 +++-
>  1 file changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/dma/ioat/init.c b/drivers/dma/ioat/init.c
> index 6ad4384b3fa8..ed8ed1192775 100644
> --- a/drivers/dma/ioat/init.c
> +++ b/drivers/dma/ioat/init.c
> @@ -839,8 +839,6 @@ static int ioat_xor_val_self_test(struct ioatdma_device 
> *ioat_dma)
> goto free_resources;
> }
>
> -   for (i = 0; i < IOAT_NUM_SRC_TEST; i++)
> -   dma_srcs[i] = DMA_ERROR_CODE;
> for (i = 0; i < IOAT_NUM_SRC_TEST; i++) {
> dma_srcs[i] = dma_map_page(dev, xor_srcs[i], 0, PAGE_SIZE,
>DMA_TO_DEVICE);
> @@ -910,8 +908,6 @@ static int ioat_xor_val_self_test(struct ioatdma_device 
> *ioat_dma)
>
> xor_val_result = 1;
>
> -   for (i = 0; i < IOAT_NUM_SRC_TEST + 1; i++)
> -   dma_srcs[i] = DMA_ERROR_CODE;
> for (i = 0; i < IOAT_NUM_SRC_TEST + 1; i++) {
> dma_srcs[i] = dma_map_page(dev, xor_val_srcs[i], 0, PAGE_SIZE,
>DMA_TO_DEVICE);
> @@ -965,8 +961,6 @@ static int ioat_xor_val_self_test(struct ioatdma_device 
> *ioat_dma)
> op = IOAT_OP_XOR_VAL;
>
> xor_val_result = 0;
> -   for (i = 0; i < IOAT_NUM_SRC_TEST + 1; i++)
> -   dma_srcs[i] = DMA_ERROR_CODE;
> for (i = 0; i < IOAT_NUM_SRC_TEST + 1; i++) {
> dma_srcs[i] = dma_map_page(dev, xor_val_srcs[i], 0, PAGE_SIZE,
>DMA_TO_DEVICE);
> @@ -1017,18 +1011,14 @@ static int ioat_xor_val_self_test(struct 
> ioatdma_device *ioat_dma)
> goto free_resources;
>  dma_unmap:
> if (op == IOAT_OP_XOR) {
> -   if (dest_dma != DMA_ERROR_CODE)
> -   dma_unmap_page(dev, dest_dma, PAGE_SIZE,
> -  DMA_FROM_DEVICE);
> -   for (i = 0; i < IOAT_NUM_SRC_TEST; i++)
> -   if (dma_srcs[i] != DMA_ERROR_CODE)
> -   dma_unmap_page(dev, dma_srcs[i], PAGE_SIZE,
> -  DMA_TO_DEVICE);
> +   while (--i >= 0)
> +   dma_unmap_page(dev, dma_srcs[i], PAGE_SIZE,
> +  DMA_TO_DEVICE);
> +   dma_unmap_page(dev, dest_dma, PAGE_SIZE, DMA_FROM_DEVICE);
> } else if (op == IOAT_OP_XOR_VAL) {
> -   for (i = 0; i < IOAT_NUM_SRC_TEST + 1; i++)
> -   if (dma_srcs[i] != DMA_ERROR_CODE)
> -   dma_unmap_page(dev, dma_srcs[i], PAGE_SIZE,
> -  DMA_TO_DEVICE);
> +   while (--i >= 0)
> +   dma_unmap_page(dev, dma_srcs[i], PAGE_SIZE,
> +  DMA_TO_DEVICE);

Wouldn't it make more sense to pull out the while loop and just call
dma_unmap_page on dest_dma if "op == IOAT_OP_XOR"? Odds are it is what
the compiler is already generating and will save a few lines of code
so what you end up with is something like:
while (--i >= 0)
dma_unmap_page(dev, dma_srcs[i], PAGE_SIZE, DMA_TO_DEVICE);
if (op == IOAT_OP_XOR)
dma_unmap_page(dev, dest_dma, PAGE_SIZE, DMA_FROM_DEVICE);

> }
>  free_resources:
> dma->device_free_chan_resources(dma_chan);
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2 2/3] drm/fb-cma-helper: expose more of fb cma guts

[Peter Rosin]

DRM drivers supporting clut may want a convenient way to only use
non-default .gamma_set and .gamma_get ops in the drm_fb_helper_funcs
in order to avoid the following

/*
 * The driver really shouldn't advertise pseudo/directcolor
 * visuals if it can't deal with the palette.
 */
if (WARN_ON(!fb_helper->funcs->gamma_set ||
!fb_helper->funcs->gamma_get))
return -EINVAL;

warning in drm_fb_helper.c:setcolreg().

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 55 ++---
 include/drm/drm_fb_cma_helper.h |  8 +-
 2 files changed, 52 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 53f9bdf..ef96227 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -426,7 +426,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
kfree(fbi->fbops);
 }
 
-static int
+/**
+ * drm_fbdev_cma_create() - Default fb_probe() function for fb_cma_helper_funcs
+ * @helper: The fb_helper to create a cma for
+ * @sizes: The fbdev sizes
+ */
+int
 drm_fbdev_cma_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
 {
@@ -507,23 +512,28 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
drm_gem_object_put_unlocked(>base);
return ret;
 }
+EXPORT_SYMBOL_GPL(drm_fbdev_cma_create);
 
 static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
.fb_probe = drm_fbdev_cma_create,
 };
 
 /**
- * drm_fbdev_cma_init_with_funcs() - Allocate and initializes a drm_fbdev_cma 
struct
+ * drm_fbdev_cma_init_with_funcs2() - Allocate and initializes a drm_fbdev_cma 
struct
  * @dev: DRM device
  * @preferred_bpp: Preferred bits per pixel for the device
  * @max_conn_count: Maximum number of connectors
- * @funcs: fb helper functions, in particular a custom dirty() callback
+ * @framebuffer_funcs: framebuffer functions, in particular a custom dirty() 
callback
+ * @fb_helper_funcs: fb helper functions, in particular custom gamma_set() and 
gamma_get() callbacks
+ *
+ * If framebuffer_funcs or fb_helper_funcs are NULL, default functions are 
used.
  *
  * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
  */
-struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct drm_device *dev,
+struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs2(struct drm_device *dev,
unsigned int preferred_bpp, unsigned int max_conn_count,
-   const struct drm_framebuffer_funcs *funcs)
+   const struct drm_framebuffer_funcs *framebuffer_funcs,
+   const struct drm_fb_helper_funcs *fb_helper_funcs)
 {
struct drm_fbdev_cma *fbdev_cma;
struct drm_fb_helper *helper;
@@ -534,11 +544,17 @@ struct drm_fbdev_cma 
*drm_fbdev_cma_init_with_funcs(struct drm_device *dev,
dev_err(dev->dev, "Failed to allocate drm fbdev.\n");
return ERR_PTR(-ENOMEM);
}
-   fbdev_cma->fb_funcs = funcs;
+
+   if (!framebuffer_funcs)
+   framebuffer_funcs = _fb_cma_funcs;
+   if (!fb_helper_funcs)
+   fb_helper_funcs = _fb_cma_helper_funcs;
+
+   fbdev_cma->fb_funcs = framebuffer_funcs;
 
helper = _cma->fb_helper;
 
-   drm_fb_helper_prepare(dev, helper, _fb_cma_helper_funcs);
+   drm_fb_helper_prepare(dev, helper, fb_helper_funcs);
 
ret = drm_fb_helper_init(dev, helper, max_conn_count);
if (ret < 0) {
@@ -568,6 +584,25 @@ struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct 
drm_device *dev,
 
return ERR_PTR(ret);
 }
+EXPORT_SYMBOL_GPL(drm_fbdev_cma_init_with_funcs2);
+
+/**
+ * drm_fbdev_cma_init_with_funcs() - Allocate and initializes a drm_fbdev_cma 
struct
+ * @dev: DRM device
+ * @preferred_bpp: Preferred bits per pixel for the device
+ * @max_conn_count: Maximum number of connectors
+ * @framebuffer_funcs: framebuffer functions, in particular a custom dirty() 
callback
+ *
+ * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
+ */
+struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct drm_device *dev,
+   unsigned int preferred_bpp, unsigned int max_conn_count,
+   const struct drm_framebuffer_funcs *framebuffer_funcs)
+{
+   return drm_fbdev_cma_init_with_funcs2(dev, preferred_bpp,
+ max_conn_count,
+ framebuffer_funcs, NULL);
+}
 EXPORT_SYMBOL_GPL(drm_fbdev_cma_init_with_funcs);
 
 /**
@@ -581,9 +616,9 @@ EXPORT_SYMBOL_GPL(drm_fbdev_cma_init_with_funcs);
 struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev,
unsigned int preferred_bpp, unsigned int max_conn_count)
 {
-   return drm_fbdev_cma_init_with_funcs(dev, preferred_bpp,
-max_conn_count,
-_fb_cma_funcs);
+ 

[RFC PATCH 0/3] drm: atmel-hlcdc: clut support

[Peter Rosin]

Hi!

This series adds support for an 8-bit clut mode in the atmel-hlcdc
driver.

For various reasons I have only tested it with the fbdev interface,
and am therefore not really sure if it works w/o patch 2 and 3.

Also, when using it with the fbdev emulation layer, something seems
to allocate the first 16 clut entries, which throws my users of
ioctl(fb, FBIOPUTCMAP, ...) when index 0 in the given clut is
really pixel value 16. If anyone can shed some light on that, I'd
be most greatful!

Further, I suspect I might need to lock the crtc state when accessing
it in patch 3/3?

Cheers,
peda

Peter Rosin (3):
  atmel-hlcdc: add support for 8-bit color lookup table mode
  drm/fb-cma-helper: expose more of fb cma guts
  atmel-hlcdc: add clut support for legacy fbdev

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  | 97 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 25 ++-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 20 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  5 ++
 drivers/gpu/drm/drm_fb_cma_helper.c | 55 +++---
 include/drm/drm_fb_cma_helper.h |  8 +-
 6 files changed, 197 insertions(+), 13 deletions(-)

-- 
2.1.4

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

[RFC PATCH v2 0/3] drm: atmel-hlcdc: clut support

[Peter Rosin]

Hi!

This series adds support for an 8-bit clut mode in the atmel-hlcdc
driver.

I have only tested it with the fbdev interface, and am therefore not
really sure if it works w/o patch 2 and 3. One significant reason for
that is that the modetest test program in libdrm does not support clut
modes like C8.

Also, when using it with the fbdev emulation layer, something seems
to allocate the first 16 clut entries, which throws my users of
ioctl(fb, FBIOPUTCMAP, ...) when index 0 in the given clut is
really pixel value 16. If anyone can shed some light on that, I'd
be most greatful!

Changes since v1:

- Move the clut update from atmel_hlcdc_crtc_mode_valid to
  atmel_hlcdc_plane_atomic_update.
- Add default .gamma_set helper (drm_atomic_helper_legacy_gamma_set).
- Don't keep a spare copy of the clut, reuse gamma_store instead.
- Don't try to synchronize the legacy fb clut with the drm clut.

I'm obvously new to this part of the kernel, but I'm beginning to
think that perhaps the .gamma_set and .gamma_get implementations
that I add in patch 3/3 are generic enough to just be default
helper implementations? Then, all the spilt guts in patch 2/3
could be kept internal. But, I don't know if those are generic
enough implementations to be suitable as defaults...

Oh right, I forgot to mention this in v1, but I have not added any
.clut_offset to the overlay2 layer of sama5d4, since the chip does
not appear to have that layer. I didn't do that to make it easier
to work with the two patches, but I suspect bad things may happen
to sama5d4 users if they do not have that layer removed.

Cheers,
peda

Peter Rosin (3):
  drm: atmel-hlcdc: add support for 8-bit color lookup table mode
  drm/fb-cma-helper: expose more of fb cma guts
  drm: atmel-hlcdc: add clut support for legacy fbdev

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  | 58 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 25 ++-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 20 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 29 +
 drivers/gpu/drm/drm_fb_cma_helper.c | 55 ++-
 include/drm/drm_fb_cma_helper.h |  8 +++-
 6 files changed, 182 insertions(+), 13 deletions(-)

-- 
2.1.4

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

Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller

[Marek Vasut]

On 06/15/2017 10:02 PM, Sean Paul wrote:
> On Thu, Jun 15, 2017 at 01:53:15PM -0400, Sean Paul wrote:
>> On Fri, May 05, 2017 at 03:01:41PM -0300, Fabio Estevam wrote:
>>> According to the eLCDIF initialization steps listed in the MX6SX
>>> Reference Manual the eLCDIF block reset is mandatory. 
>>>
>>> Without performing the eLCDIF reset the display shows garbage content
>>> when the kernel boots.
>>>
>>> In earlier tests this issue has not been observed because the bootloader
>>> was previously showing a splash screen and the bootloader display driver
>>> does properly implement the eLCDIF reset.
>>>
>>> Add the eLCDIF reset to the driver, so that it can operate correctly
>>> independently of the bootloader.
>>>
>>> Tested on a imx6sx-sdb board.
>>>
>>> Cc: 
>>> Signed-off-by: Fabio Estevam 
>>
>> Per Marek's request, this has been applied to drm-misc-next
>>
> 
> Now applied to misc-fixes per Jani's request :)
> 

Excellent, thanks!

-- 
Best regards,
Marek Vasut
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller

[Sanchayan Maity]

Hello Marek,

On 17-06-15 19:57:35, Stefan Agner wrote:
> On 2017-06-15 10:26, Marek Vasut wrote:
> > On 06/15/2017 05:12 PM, Fabio Estevam wrote:
> >> Hi Marek,
> >>
> >> On Mon, Jun 5, 2017 at 9:08 AM, Marek Vasut  wrote:
> >>
> >>> I'm currently on vacation, try one more time and if it doesn't work out
> >>> (which means this trivial list is not really working?), I'll send a PR
> >>> sometime mid-month.
> >>
> >> Tried your suggestion, but it did not work.
> >>
> >> Could you please consider sending Dave Airlie a pull request with this 
> >> patch?
> > 
> > I poked the DRM people on IRC, so they should pick it up.
> > 
> > Stefan, can you test and add a T-B ?
> 
> Sorry, I am on vacation too, no access to actual hardware.
> 
> @Sanchayan, can you maybe check this patch on mainline?
>

Tested on Toradex Apalis iMX6Q module with edt,et070080dh6: EDT 7.0" LCD TFT.
Did not see any issues using this patch applied on top of latest mainline.

Tested-By: Sanchayan Maity 

Regards,
Sanchayan.

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

[PATCH][RESEND] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

[Kuninori Morimoto]

From: Kuninori Morimoto 

ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.
To solve this issue, this patch adds new .get_dai_id callback
on hdmi_codec_ops.
dw-hdmi-i2s will assume that HDMI sound will be connected
to reg = <2>. Then, ALSA SoC side will recognized it as DAI 0

ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
/* HDMI Video IN */
};
port@1 {
reg = <1>;
/* HDMI OUT */
};
port@2 {
reg = <2>;
/* HDMI Sound IN */
};
};

Signed-off-by: Kuninori Morimoto 
Acked-by: Archit Taneja 
---
v1 -> v1 resend

 - add Archit's Acked-by (= DRM maintainer)

 .../bindings/display/bridge/renesas,dw-hdmi.txt |  9 -
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 21 +
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt 
b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
index f6b3f36..81b6858 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
@@ -25,7 +25,8 @@ Required properties:
 - clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt.
 - ports: See dw_hdmi.txt. The DWC HDMI shall have one port numbered 0
   corresponding to the video input of the controller and one port numbered 1
-  corresponding to its HDMI output. Each port shall have a single endpoint.
+  corresponding to its HDMI output, and one port numbered 2 corresponding to
+  sound input of the controller. Each port shall have a single endpoint.
 
 Optional properties:
 
@@ -59,6 +60,12 @@ Example:
remote-endpoint = <_con>;
};
};
+   port@2 {
+   reg = <2>;
+   rcar_dw_hdmi0_sound_in: endpoint {
+   remote-endpoint = <_sound_out>;
+   };
+   };
};
};
 
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index aaf287d..b2cf59f 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -82,9 +82,30 @@ static void dw_hdmi_i2s_audio_shutdown(struct device *dev, 
void *data)
hdmi_write(audio, HDMI_AUD_CONF0_SW_RESET, HDMI_AUD_CONF0);
 }
 
+static int dw_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
+ struct device_node *endpoint)
+{
+   struct of_endpoint of_ep;
+   int ret;
+
+   ret = of_graph_parse_endpoint(endpoint, _ep);
+   if (ret < 0)
+   return ret;
+
+   /*
+* HDMI sound should be located as reg = <2>
+* Then, it is sound port 0
+*/
+   if (of_ep.port == 2)
+   return 0;
+
+   return -EINVAL;
+}
+
 static struct hdmi_codec_ops dw_hdmi_i2s_ops = {
.hw_params  = dw_hdmi_i2s_hw_params,
.audio_shutdown = dw_hdmi_i2s_audio_shutdown,
+   .get_dai_id = dw_hdmi_i2s_get_dai_id,
 };
 
 static int snd_dw_hdmi_probe(struct platform_device *pdev)
-- 
1.9.1

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

Re: Color lookup support for the atmel-hlcdc driver

[Peter Rosin]

On 2017-06-16 01:03, Peter Rosin wrote:
> On 2017-06-16 01:01, Peter Rosin wrote:
>> So, is this below better? I'll follow-up with a patch I need for the
>> fbdev emulation to work.
> 
> Without adding gamma callbacks in drm_fb_helper_funcs I hit
> 
>   /*
>* The driver really shouldn't advertise pseudo/directcolor
>* visuals if it can't deal with the palette.
>*/
>   if (WARN_ON(!fb_helper->funcs->gamma_set ||
>   !fb_helper->funcs->gamma_get))
>   return -EINVAL;
> 
> in drm_fb_helper.c:setcolreg(), so I need this patch which basically
> exposes some guts from fbdev_cma and glues it with the new clut
> handling in the atmel_hlcdc driver.
> 
> Cheers,
> peda
> +
> +/**
> + * drm_fbdev_cma_init_with_funcs() - Allocate and initializes a 
> drm_fbdev_cma struct
> + * @dev: DRM device
> + * @preferred_bpp: Preferred bits per pixel for the device
> + * @max_conn_count: Maximum number of connectors
> + * @framebuffer_funcs: framebuffer functions, in particular a custom dirty() 
> callback
> + *
> + * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
> + */
> +struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct drm_device *dev,
> + unsigned int preferred_bpp, unsigned int max_conn_count,
> + const struct drm_framebuffer_funcs *framebuffer_funcs)
> +{
> + return drm_fbdev_cma_init_with_funcs2(dev, preferred_bpp,
> +   max_conn_count,
> +   funcs, NULL);

s/funcs/framebuffer_funcs/

Sorry about that. I'm planning to resend this as a series anyway with proper
commit messages and signoffs etc.

Cheers,
peda

> +}
>  EXPORT_SYMBOL_GPL(drm_fbdev_cma_init_with_funcs);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 1/3] atmel-hlcdc: add support for 8-bit color lookup table mode

[Peter Rosin]

On 2017-06-16 12:01, Boris Brezillon wrote:
> Hi Peter,
> 
> On Fri, 16 Jun 2017 11:12:25 +0200
> Peter Rosin  wrote:
> 
>> All layers of chips support this, the only variable is the base address
>> of the lookup table in the register map.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  | 48 
>> +
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 13 +++
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 16 +
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  5 +++
>>  4 files changed, 82 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> index 5348985..75871b5 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> @@ -61,6 +61,7 @@ struct atmel_hlcdc_crtc {
>>  struct atmel_hlcdc_dc *dc;
>>  struct drm_pending_vblank_event *event;
>>  int id;
>> +u32 clut[ATMEL_HLCDC_CLUT_SIZE];
> 
> Do we really need to duplicate this table here? I mean, the gamma_lut
> table should always be available in the crtc_state, so do you have a
> good reason a copy here?

If I don't keep a copy in the driver, it doesn't work when there's no
gamma_lut. And there is no gamma_lut when I use fbdev emulation. Maybe
that's a bug somewhere else?

Sure, I could have added it in patch 3/3 instead, but didn't when I
divided the work into patches...

>>  };
>>  
>>  static inline struct atmel_hlcdc_crtc *
>> @@ -140,6 +141,46 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct 
>> drm_crtc *c)
>> cfg);
>>  }
>>  
>> +static void
>> +atmel_hlcdc_crtc_load_lut(struct drm_crtc *c)
>> +{
>> +struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
>> +struct atmel_hlcdc_dc *dc = crtc->dc;
>> +int layer;
>> +int idx;
>> +
>> +for (layer = 0; layer < ATMEL_HLCDC_MAX_LAYERS; layer++) {
>> +if (!dc->layers[layer])
>> +continue;
>> +for (idx = 0; idx < ATMEL_HLCDC_CLUT_SIZE; idx++)
>> +atmel_hlcdc_layer_write_clut(dc->layers[layer],
>> + idx, crtc->clut[idx]);
>> +}
>> +}
>> +
>> +static void
>> +atmel_hlcdc_crtc_flush_lut(struct drm_crtc *c)
>> +{
>> +struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
>> +struct drm_crtc_state *state = c->state;
>> +struct drm_color_lut *lut;
>> +int idx;
>> +
>> +if (!state->gamma_lut)
>> +return;
>> +
>> +lut = (struct drm_color_lut *)state->gamma_lut->data;
>> +
>> +for (idx = 0; idx < ATMEL_HLCDC_CLUT_SIZE; idx++) {
>> +crtc->clut[idx] =
>> +((lut[idx].red << 8) & 0xff) |
>> +(lut[idx].green & 0xff00) |
>> +(lut[idx].blue >> 8);
>> +}
>> +
>> +atmel_hlcdc_crtc_load_lut(c);
>> +}
>> +
>>  static enum drm_mode_status
>>  atmel_hlcdc_crtc_mode_valid(struct drm_crtc *c,
>>  const struct drm_display_mode *mode)
>> @@ -312,6 +353,9 @@ static void atmel_hlcdc_crtc_atomic_flush(struct 
>> drm_crtc *crtc,
>>struct drm_crtc_state *old_s)
>>  {
>>  /* TODO: write common plane control register if available */
>> +
>> +if (crtc->state->color_mgmt_changed)
>> +atmel_hlcdc_crtc_flush_lut(crtc);
> 
> Hm, it's probably too late to do it here. Planes have already been
> enabled and the engine may have started to fetch data and do the
> composition. You could do that in ->update_plane() [1], and make it a
> per-plane thing.
> 
> I'm not sure, but I think you can get the new crtc_state from
> plane->crtc->state in this context (state have already been swapped,
> and new state is being applied, which means relevant locks are held).

Ok, I can move it there. My plan is to just copy the default .update_plane
function and insert 

if (crtc->state->color_mgmt_changed && crtc->state->gamma_lut) {
...
}

just before the drm_atomic_commit(state) call. Sounds ok?

>>  }
>>  
>>  static const struct drm_crtc_helper_funcs lcdc_crtc_helper_funcs = {
>> @@ -429,6 +473,7 @@ static const struct drm_crtc_funcs 
>> atmel_hlcdc_crtc_funcs = {
>>  .atomic_destroy_state = atmel_hlcdc_crtc_destroy_state,
>>  .enable_vblank = atmel_hlcdc_crtc_enable_vblank,
>>  .disable_vblank = atmel_hlcdc_crtc_disable_vblank,
>> +.set_property = drm_atomic_helper_crtc_set_property,
> 
> Well, this change is independent from gamma LUT support. Should
> probably be done in a separate patch.

Ok, I think I fat-fingered some kernel cmdline at some point and fooled
myself into thinking I needed it for some reason...

> Also, you should probably have:
>  
>   .gamma_set = drm_atomic_helper_legacy_gamma_set,

That doesn't no anything for me, but 

Re: [RFC PATCH 1/3] atmel-hlcdc: add support for 8-bit color lookup table mode

[Peter Rosin]

On 2017-06-17 07:36, Boris Brezillon wrote:
> Le Sat, 17 Jun 2017 00:46:12 +0200,
> Peter Rosin  a écrit :
> 
>> Hm, it's probably too late to do it here. Planes have already been
>> enabled and the engine may have started to fetch data and do the
>> composition. You could do that in ->update_plane() [1], and make it a
>> per-plane thing.
>>
>> I'm not sure, but I think you can get the new crtc_state from
>> plane->crtc->state in this context (state have already been swapped,
>> and new state is being applied, which means relevant locks are held).
>
> Ok, I can move it there. My plan is to just copy the default .update_plane
> function and insert 
>
>   if (crtc->state->color_mgmt_changed && crtc->state->gamma_lut) {
>   ...
>   }
>
> just before the drm_atomic_commit(state) call. Sounds ok?  

 Why would you copy the default ->update_plane() when we already have
 our own ->atomic_update_plane() implementation [1]? Just put it there
 (before the atmel_hlcdc_layer_update_commit() call) and we should be
 good.  
>>>
>>> Ahh, but you said ->update_plane() and I took that as .update_plane in
>>> layer_plane_funcs, not ->atomic_update() in 
>>> atmel_hlcdc_layer_plane_helper_funcs.
>>>
>>> Makes sense now, and much neater too.  
>>
>> No, it doesn't make sense. There's no atmel_hlcdc_layer_update_commit call
>> anywhere, and no such function. You seem to have some further changes that
>> are not even in -next. Where am I getting those changes and why are they
>> not upstream yet?
> 
> My bad, this part as been reworked in 4.12 and I was reading 4.11 code.
> Indeed, atmel_hlcdc_layer_update_commit() no longer exists, but
> atmel_hlcdc_plane_atomic_update() does.

Ah, it was the other way around. I had too new code!

Anyway, I just sent a new series which I think addresses all issues except
that I have still not tested with plain drm ioctls.

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

Re: [RFC PATCH 1/3] atmel-hlcdc: add support for 8-bit color lookup table mode

[Peter Rosin]

On 2017-06-16 18:15, Boris Brezillon wrote:
> Hi Peter,
> 
> On Fri, 16 Jun 2017 17:54:04 +0200
> Peter Rosin  wrote:
> 
>> On 2017-06-16 12:01, Boris Brezillon wrote:
>>> Hi Peter,
>>>
>>> On Fri, 16 Jun 2017 11:12:25 +0200
>>> Peter Rosin  wrote:
>>>   
 All layers of chips support this, the only variable is the base address
 of the lookup table in the register map.

 Signed-off-by: Peter Rosin 
 ---
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  | 48 
 +
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 13 +++
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 16 +
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  5 +++
  4 files changed, 82 insertions(+)

 diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
 b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
 index 5348985..75871b5 100644
 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
 +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
 @@ -61,6 +61,7 @@ struct atmel_hlcdc_crtc {
struct atmel_hlcdc_dc *dc;
struct drm_pending_vblank_event *event;
int id;
 +  u32 clut[ATMEL_HLCDC_CLUT_SIZE];  
>>>
>>> Do we really need to duplicate this table here? I mean, the gamma_lut
>>> table should always be available in the crtc_state, so do you have a
>>> good reason a copy here?  
>>
>> If I don't keep a copy in the driver, it doesn't work when there's no
>> gamma_lut. And there is no gamma_lut when I use fbdev emulation. Maybe
>> that's a bug somewhere else?
> 
> Can't we re-use crtc->gamma_store? Honnestly, I don't know how the
> fbdev->DRM link should be done, so we'd better wait for DRM maintainers
> feedback here (Daniel, any opinion?).

Ahh, gamma_store. Makes perfect sense. Thanks for that pointer!

>>
>> Sure, I could have added it in patch 3/3 instead, but didn't when I
>> divided the work into patches...
> 
> No, my point is that IMO it shouldn't be needed at all.

Right, with gamma_store it's no longer needed.

>>
  };
  
  static inline struct atmel_hlcdc_crtc *
 @@ -140,6 +141,46 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct 
 drm_crtc *c)
   cfg);
  }
  
 +static void
 +atmel_hlcdc_crtc_load_lut(struct drm_crtc *c)
 +{
 +  struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
 +  struct atmel_hlcdc_dc *dc = crtc->dc;
 +  int layer;
 +  int idx;
 +
 +  for (layer = 0; layer < ATMEL_HLCDC_MAX_LAYERS; layer++) {
 +  if (!dc->layers[layer])
 +  continue;
 +  for (idx = 0; idx < ATMEL_HLCDC_CLUT_SIZE; idx++)
 +  atmel_hlcdc_layer_write_clut(dc->layers[layer],
 +   idx, crtc->clut[idx]);
 +  }
 +}
 +
 +static void
 +atmel_hlcdc_crtc_flush_lut(struct drm_crtc *c)
 +{
 +  struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
 +  struct drm_crtc_state *state = c->state;
 +  struct drm_color_lut *lut;
 +  int idx;
 +
 +  if (!state->gamma_lut)
 +  return;
 +
 +  lut = (struct drm_color_lut *)state->gamma_lut->data;
 +
 +  for (idx = 0; idx < ATMEL_HLCDC_CLUT_SIZE; idx++) {
 +  crtc->clut[idx] =
 +  ((lut[idx].red << 8) & 0xff) |
 +  (lut[idx].green & 0xff00) |
 +  (lut[idx].blue >> 8);
 +  }
 +
 +  atmel_hlcdc_crtc_load_lut(c);
 +}
 +
  static enum drm_mode_status
  atmel_hlcdc_crtc_mode_valid(struct drm_crtc *c,
const struct drm_display_mode *mode)
 @@ -312,6 +353,9 @@ static void atmel_hlcdc_crtc_atomic_flush(struct 
 drm_crtc *crtc,
  struct drm_crtc_state *old_s)
  {
/* TODO: write common plane control register if available */
 +
 +  if (crtc->state->color_mgmt_changed)
 +  atmel_hlcdc_crtc_flush_lut(crtc);  
>>>
>>> Hm, it's probably too late to do it here. Planes have already been
>>> enabled and the engine may have started to fetch data and do the
>>> composition. You could do that in ->update_plane() [1], and make it a
>>> per-plane thing.
>>>
>>> I'm not sure, but I think you can get the new crtc_state from
>>> plane->crtc->state in this context (state have already been swapped,
>>> and new state is being applied, which means relevant locks are held).  
>>
>> Ok, I can move it there. My plan is to just copy the default .update_plane
>> function and insert 
>>
>>  if (crtc->state->color_mgmt_changed && crtc->state->gamma_lut) {
>>  ...
>>  }
>>
>> just before the drm_atomic_commit(state) call. Sounds ok?
> 
> Why would you copy the default ->update_plane() when we already have
> our own ->atomic_update_plane() 

Re: Color lookup support for the atmel-hlcdc driver

[Peter Rosin]

On 2017-06-16 01:01, Peter Rosin wrote:
> So, is this below better? I'll follow-up with a patch I need for the
> fbdev emulation to work.

Without adding gamma callbacks in drm_fb_helper_funcs I hit

/*
 * The driver really shouldn't advertise pseudo/directcolor
 * visuals if it can't deal with the palette.
 */
if (WARN_ON(!fb_helper->funcs->gamma_set ||
!fb_helper->funcs->gamma_get))
return -EINVAL;

in drm_fb_helper.c:setcolreg(), so I need this patch which basically
exposes some guts from fbdev_cma and glues it with the new clut
handling in the atmel_hlcdc driver.

Cheers,
peda

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 68f5e66..2fb23aa 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -158,6 +158,54 @@ atmel_hlcdc_crtc_load_lut(struct drm_crtc *c)
}
 }
 
+void atmel_hlcdc_gamma_set(struct drm_crtc *c,
+  u16 r, u16 g, u16 b, int idx)
+{
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+   struct drm_crtc_state *state = c->state;
+   struct drm_color_lut *lut;
+
+   if (idx < 0 || idx > 255)
+   return;
+
+   if (state->gamma_lut) {
+   lut = (struct drm_color_lut *)state->gamma_lut->data;
+
+   lut[idx].red = r;
+   lut[idx].green = g;
+   lut[idx].blue = b;
+   }
+
+   crtc->clut[idx] = ((r << 8) & 0xff) | (g & 0xff00) | (b >> 8);
+}
+
+void atmel_hlcdc_gamma_get(struct drm_crtc *c,
+  u16 *r, u16 *g, u16 *b, int idx)
+{
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+   struct drm_crtc_state *state = c->state;
+   struct drm_color_lut *lut;
+
+   if (idx < 0 || idx > 255)
+   return;
+
+   if (state->gamma_lut) {
+   lut = (struct drm_color_lut *)state->gamma_lut->data;
+
+   *r = lut[idx].red;
+   *g = lut[idx].green;
+   *b = lut[idx].blue;
+   return;
+   }
+
+   *r = (crtc->clut[idx] >> 8) & 0xff00;
+   *g = crtc->clut[idx] & 0xff00;
+   *b = (crtc->clut[idx] << 8) & 0xff00;
+   *r |= *r >> 8;
+   *g |= *g >> 8;
+   *b |= *b >> 8;
+}
+
 static void
 atmel_hlcdc_crtc_flush_lut(struct drm_crtc *c)
 {
@@ -363,6 +411,7 @@ static const struct drm_crtc_helper_funcs 
lcdc_crtc_helper_funcs = {
.mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
.mode_set_base = drm_helper_crtc_mode_set_base,
+   .load_lut = atmel_hlcdc_crtc_load_lut,
.disable = atmel_hlcdc_crtc_disable,
.enable = atmel_hlcdc_crtc_enable,
.atomic_check = atmel_hlcdc_crtc_atomic_check,
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 4f6ef07..9a09c73 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -601,6 +601,12 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device 
*dev)
return 0;
 }
 
+static const struct drm_fb_helper_funcs atmel_hlcdc_fb_cma_helper_funcs = {
+   .gamma_set  = atmel_hlcdc_gamma_set,
+   .gamma_get  = atmel_hlcdc_gamma_get,
+   .fb_probe   = drm_fbdev_cma_create,
+};
+
 static int atmel_hlcdc_dc_load(struct drm_device *dev)
 {
struct platform_device *pdev = to_platform_device(dev->dev);
@@ -664,8 +670,10 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
 
platform_set_drvdata(pdev, dev);
 
-   dc->fbdev = drm_fbdev_cma_init(dev, 24,
-   dev->mode_config.num_connector);
+   dc->fbdev = drm_fbdev_cma_init_with_funcs2(dev, 24,
+   dev->mode_config.num_connector,
+   NULL,
+   _hlcdc_fb_cma_helper_funcs);
if (IS_ERR(dc->fbdev))
dc->fbdev = NULL;
 
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index a2cc2ab..2a4f874 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -446,6 +447,9 @@ void atmel_hlcdc_plane_irq(struct atmel_hlcdc_plane *plane);
 int atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state);
 int atmel_hlcdc_plane_prepare_ahb_routing(struct drm_crtc_state *c_state);
 
+void atmel_hlcdc_gamma_set(struct drm_crtc *c, u16 r, u16 g, u16 b, int idx);
+void atmel_hlcdc_gamma_get(struct drm_crtc *c, u16 *r, u16 *g, u16 *b, int 
idx);
+
 void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
 
 int atmel_hlcdc_crtc_create(struct drm_device *dev);
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 

[PATCH] drm: exynos: dsi: fix to return -ENODEV when DSI_PORT_OUT is not found

[Shuah Khan]

Fix exynos_dsi_parse_dt() to return -ENODEV when of_graph_get_remote_node()
doesn't find DSI_PORT_OUT. -ENODEV is the correct error code to return and
this change makes exynos behavior consistent with rest of the drm drivers.

Signed-off-by: Shuah Khan 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index e337cd2..cb99e82 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1652,7 +1652,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
 
dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_OUT, 0);
if (!dsi->bridge_node)
-   return -EINVAL;
+   return -ENODEV;
 
return 0;
 }
-- 
2.7.4

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

Re: [PATCH] drm/exynos: dsi: do not try to find bridge

[Shuah Khan]

On 06/16/2017 08:16 AM, Shuah Khan wrote:
> Hi Inki,
> 
> On Fri, Jun 16, 2017 at 1:50 AM, Inki Dae  wrote:
>> It doesn't need to try to find a bridge if bridge node doesn't exist.
>>
>> Signed-off-by: Inki Dae 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index d404de8..e337cd2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -1687,9 +1687,11 @@ static int exynos_dsi_bind(struct device *dev, struct 
>> device *master,
>> return ret;
>> }
>>
>> -   bridge = of_drm_find_bridge(dsi->bridge_node);
> 
> This is more of question than comment. I am seeing in some places,
> such as mtk_dpi_probe(), of_node_put() is called right after
> of_drm_find_bridge() whether or not bridge_node is found.
> 
> In this case, of_node_put() is done from exynos_dsi_remove() which looks
> correct to me.
> 
> However, there is the discrepancy. One of these is incorrect perhaps?
> When is the right time to call of_node_put()?
> 
>> -   if (bridge)
>> -   drm_bridge_attach(encoder, bridge, NULL);
>> +   if (dsi->bridge_node) {
>> +   bridge = of_drm_find_bridge(dsi->bridge_node);
>> +   if (bridge)
>> +   drm_bridge_attach(encoder, bridge, NULL);
>> +   }
>>
>> return mipi_dsi_host_register(>dsi_host);
>>  }
>> --
>> 1.9.1
> 
> Looks good to me.
> 
> Reviewed-by: Shuah Khan 
> 

I tested this on odroid-xu4

Tested-by: Shuah Khan 

thanks,
-- Shuah

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

[RFC PATCH 1/3] atmel-hlcdc: add support for 8-bit color lookup table mode

[Peter Rosin]

All layers of chips support this, the only variable is the base address
of the lookup table in the register map.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  | 48 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 13 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 16 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  5 +++
 4 files changed, 82 insertions(+)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 5348985..75871b5 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -61,6 +61,7 @@ struct atmel_hlcdc_crtc {
struct atmel_hlcdc_dc *dc;
struct drm_pending_vblank_event *event;
int id;
+   u32 clut[ATMEL_HLCDC_CLUT_SIZE];
 };
 
 static inline struct atmel_hlcdc_crtc *
@@ -140,6 +141,46 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
   cfg);
 }
 
+static void
+atmel_hlcdc_crtc_load_lut(struct drm_crtc *c)
+{
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+   struct atmel_hlcdc_dc *dc = crtc->dc;
+   int layer;
+   int idx;
+
+   for (layer = 0; layer < ATMEL_HLCDC_MAX_LAYERS; layer++) {
+   if (!dc->layers[layer])
+   continue;
+   for (idx = 0; idx < ATMEL_HLCDC_CLUT_SIZE; idx++)
+   atmel_hlcdc_layer_write_clut(dc->layers[layer],
+idx, crtc->clut[idx]);
+   }
+}
+
+static void
+atmel_hlcdc_crtc_flush_lut(struct drm_crtc *c)
+{
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+   struct drm_crtc_state *state = c->state;
+   struct drm_color_lut *lut;
+   int idx;
+
+   if (!state->gamma_lut)
+   return;
+
+   lut = (struct drm_color_lut *)state->gamma_lut->data;
+
+   for (idx = 0; idx < ATMEL_HLCDC_CLUT_SIZE; idx++) {
+   crtc->clut[idx] =
+   ((lut[idx].red << 8) & 0xff) |
+   (lut[idx].green & 0xff00) |
+   (lut[idx].blue >> 8);
+   }
+
+   atmel_hlcdc_crtc_load_lut(c);
+}
+
 static enum drm_mode_status
 atmel_hlcdc_crtc_mode_valid(struct drm_crtc *c,
const struct drm_display_mode *mode)
@@ -312,6 +353,9 @@ static void atmel_hlcdc_crtc_atomic_flush(struct drm_crtc 
*crtc,
  struct drm_crtc_state *old_s)
 {
/* TODO: write common plane control register if available */
+
+   if (crtc->state->color_mgmt_changed)
+   atmel_hlcdc_crtc_flush_lut(crtc);
 }
 
 static const struct drm_crtc_helper_funcs lcdc_crtc_helper_funcs = {
@@ -429,6 +473,7 @@ static const struct drm_crtc_funcs atmel_hlcdc_crtc_funcs = 
{
.atomic_destroy_state = atmel_hlcdc_crtc_destroy_state,
.enable_vblank = atmel_hlcdc_crtc_enable_vblank,
.disable_vblank = atmel_hlcdc_crtc_disable_vblank,
+   .set_property = drm_atomic_helper_crtc_set_property,
 };
 
 int atmel_hlcdc_crtc_create(struct drm_device *dev)
@@ -484,6 +529,9 @@ int atmel_hlcdc_crtc_create(struct drm_device *dev)
drm_crtc_helper_add(>base, _crtc_helper_funcs);
drm_crtc_vblank_reset(>base);
 
+   drm_mode_crtc_set_gamma_size(>base, ATMEL_HLCDC_CLUT_SIZE);
+   drm_crtc_enable_color_mgmt(>base, 0, false, 
ATMEL_HLCDC_CLUT_SIZE);
+
dc->crtc = >base;
 
return 0;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 30dbffd..4f6ef07 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -42,6 +42,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9n12_layers[] = {
.default_color = 3,
.general_config = 4,
},
+   .clut_offset = 0x400,
},
 };
 
@@ -73,6 +74,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.disc_pos = 5,
.disc_size = 6,
},
+   .clut_offset = 0x400,
},
{
.name = "overlay1",
@@ -91,6 +93,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0x800,
},
{
.name = "high-end-overlay",
@@ -112,6 +115,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.scaler_config = 13,
.csc = 14,
},
+   .clut_offset = 0x1000,
},
{
.name = 

Re: [RFC PATCH 1/3] atmel-hlcdc: add support for 8-bit color lookup table mode

[Peter Rosin]

On 2017-06-16 23:12, Peter Rosin wrote:
> On 2017-06-16 18:15, Boris Brezillon wrote:
>> To be very clear, I'd like you to test it through DRM ioctls, not only
>> through the fbdev emulation layer.
> 
> ...so yeah, right, I couldn't agree more. Any pointers to code w/o a bunch
> of complex library dependencies that I can test with?

I have now built libdrm-2.4.81, and get this:

$ modetest -M atmel-hlcdc -s 27@39:1024x768
setting mode 1024x768-60Hz@XR24 on connectors 27, crtc 39
$ modetest -M atmel-hlcdc -s 27@39:1024x768@RG16
setting mode 1024x768-60Hz@RG16 on connectors 27, crtc 39
$ modetest -M atmel-hlcdc -s 27@39:1024x768@C8
unknown format C8


(output on the lcd looks sane for the first two, not that I really
know exactly what to expect)

Looking at the libdrm code, I only find YUV and RGB modes in
tests/util/format.c which make me less confident that I will find
something sane to test with.

So, pointers to code to test with desperately needed...

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

Re: [RFC PATCH 1/3] atmel-hlcdc: add support for 8-bit color lookup table mode

[Peter Rosin]

 Hm, it's probably too late to do it here. Planes have already been
 enabled and the engine may have started to fetch data and do the
 composition. You could do that in ->update_plane() [1], and make it a
 per-plane thing.

 I'm not sure, but I think you can get the new crtc_state from
 plane->crtc->state in this context (state have already been swapped,
 and new state is being applied, which means relevant locks are held).  
>>>
>>> Ok, I can move it there. My plan is to just copy the default .update_plane
>>> function and insert 
>>>
>>> if (crtc->state->color_mgmt_changed && crtc->state->gamma_lut) {
>>> ...
>>> }
>>>
>>> just before the drm_atomic_commit(state) call. Sounds ok?
>>
>> Why would you copy the default ->update_plane() when we already have
>> our own ->atomic_update_plane() implementation [1]? Just put it there
>> (before the atmel_hlcdc_layer_update_commit() call) and we should be
>> good.
> 
> Ahh, but you said ->update_plane() and I took that as .update_plane in
> layer_plane_funcs, not ->atomic_update() in 
> atmel_hlcdc_layer_plane_helper_funcs.
> 
> Makes sense now, and much neater too.

No, it doesn't make sense. There's no atmel_hlcdc_layer_update_commit call
anywhere, and no such function. You seem to have some further changes that
are not even in -next. Where am I getting those changes and why are they
not upstream yet?

There's a mention of the missing function here [1], but that's some 18
months ago. What's going on?

[1] https://patchwork.kernel.org/patch/7965721/

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

Re: [PATCH v2 3/4] ARM: dts: exynos: Fix the active of reset gpios from rinato dts

[Krzysztof Kozlowski]

On Thu, Jun 15, 2017 at 07:03:29PM +0900, Hoegeun Kwon wrote:
> This reset gpios is active low, therefore fix from active high to low.
> 
> Signed-off-by: Hoegeun Kwon 
> ---
>  arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Thanks, applied this one only. As mentioned before, 4/4 will wait for
driver.

Best regards,
Krzysztof

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

[Bug 101294] radeonsi minecraft forge splash freeze since 17.1

[bugzilla-daemon]

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

Fabian Maurer  changed:

   What|Removed |Added

   Keywords||bisected

-- 
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 101294] radeonsi minecraft forge splash freeze since 17.1

[bugzilla-daemon]

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

--- Comment #6 from Fabian Maurer  ---
Bisected to
commit 2769dadb0fafdbafc98630fdf96924a3bb209ab7
Author: Marek Olšák 
Date:   Thu Apr 13 23:46:59 2017 +0200

gallium/radeon: always flush asynchronously and wait after begin_new_cs

This hides the overhead of everything in the driver after the CS flush and
before returning from pipe_context::flush.
Only microbenchmarks will benefit.

+2% FPS for glxgears.

Reviewed-by: Nicolai Hähnle 


Reverting this commit on the recent git tree fixes the freezes.
Now since the bug doesn't always appear, I'm not 100% sure, but I didn't get a
single freeze in 20 runs, while I got 13 out of 20 without reverting it.


Could you maybe look into this? I have no idea how to fix the issue without
throwing away all changes from this commit.

-- 
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 101224] texelFetch(usampler) returns black color

[bugzilla-daemon]

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

--- Comment #6 from Roland Scheidegger  ---
This is certainly not the first time it came up fwiw, especially since there's
binary drivers which will just ignore the incomplete texture since obviously
that sampler state isn't needed at all for texture fetch (yes technically they
are wrong). It is also very easy to miss since it's really not obvious you have
to worry about it for texel fetches (it is logical given how the incomplete
texture is defined, but still sort of surprising, especially when you might
have experience with d3d10 which doesn't have sampler state at all for just
fetches (loads)).
So I think everybody agrees hooking that detection up with ARB_debug_output
would be a good idea.

-- 
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 196117] amdgpu - RX 480 (polaris) - freeze during boot

[bugzilla-daemon]

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

Paul K. Gerke (paulkge...@craftware.nl) changed:

   What|Removed |Added

Summary|amdgpu RC 480 (polaris) |amdgpu - RX 480 (polaris) -
   |freeze after initramfs, |freeze during boot
   |before kernel load  |

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

[Bug 196117] amdgpu RC 480 (polaris) freeze after initramfs, before kernel load

[bugzilla-daemon]

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

--- Comment #1 from Paul K. Gerke (paulkge...@craftware.nl) ---
I just realized that while trying to be concise, I deprived this bug report of
a lot of information:

The very short version:

The AMDGPU driver somehow causes the system to hang after initramfs, after the
kernel was loaded, but VERY early in the boot sequence. Within the first 100
milliseconds or so during regular boot, when the system normally switches to
its graphics driver, my monitor goes black and the system just hangs. No
communication possible. As stated above, the monitor stays on, so there is some
sort of graphics signal.

With the "nomodeset"-option, this issue is gone and the system comes up
normally.

This happens on all modern kernels, with different linux distros. I currently
tried Xubuntu (16.04, 17.04), Ubuntu (17.04), and Arch Linux. I forgot which
kernel versions I exactly tested, if relevant I can list them, but the result
seemed all the same.

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

[Bug 196117] New: amdgpu RC 480 (polaris) freeze after initramfs, before kernel load

[bugzilla-daemon]

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

Bug ID: 196117
   Summary: amdgpu RC 480 (polaris) freeze after initramfs, before
kernel load
   Product: Drivers
   Version: 2.5
Kernel Version: 4.11.6
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: paulkge...@craftware.nl
Regression: No

Created attachment 257069
  --> https://bugzilla.kernel.org/attachment.cgi?id=257069=edit
screen capture of the last kernel messages before system freeze

Hey all!

I recently swapped out my old Radeon HD7850 for a Radeon RX 480, that I only
heard good things about on the Internet because of good kernel support.
However, I ran into an issue: all kernels I tried hang after initramfs, but
before the kernel actually boots. Here the symptoms:

I tried several kernels by now, the stock kernels that come with XUbuntu 16.04,
and several upstream ones (e.g. 4.12.0). This will be about 4.11.6, which I now
compiled myself.

- If I use "nomodeset" to boot the kernel, everything works fine, except for
the graphics drivers which fails to initialize (amdgpu fails because of VGACON
error).

- If I boot in with options
"linux /vmlinuz... root=UUID= ro debug ignore_loglevel boot_delay=100"

PS: I also setup a serial link for debugging, but the crash seems to occur
before the serial driver can start communicating, so no luck with that!

- I see "loading initial ramdisk..." ... booting takes 3 minutes until the
crash with that delay...
  - I taped the whole thing to at least capture some sort of error. The
attached screenshot is the best I got at the moment.

It says something about IOMMUv2 driver and... about it being not "avaialble on
the system" (?) Is that my error? This is the last (half) frame before my
screen turns black.

After this, my keyboard LEDs turn off, my mouse also turns off (it has fancy
LEDs which light up if it is initialized) and my screen stays **on**,
curiously. The machine is not responding after this.

At the moment I am stuck lacking good debugging tools. If somebody has an idea,
I would be greatful. Until now, the only thing I can think of is digging into a
fresh codebase - I bet graphics drivers are not really accessible though :-(

One last PS: The graphicscard I have works perfectly fine on Windows on the
same system. It is clearly some software issue, I assume!

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

[Bug 101492] Git repo ~agd5f/linux has problem: badTimezone: invalid author/committer line - bad time zone

[bugzilla-daemon]

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

Yurii Kolesnykov  changed:

   What|Removed |Added

 QA Contact||yuriko...@gmail.com

-- 
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 101492] Git repo ~agd5f/linux has problem: badTimezone: invalid author/committer line - bad time zone

[bugzilla-daemon]

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

Bug ID: 101492
   Summary: Git repo ~agd5f/linux has problem: badTimezone:
invalid author/committer line - bad time zone
   Product: DRI
   Version: DRI git
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: yuriko...@gmail.com

I'm trying to create a mirror for ~agd5f/linux on repo.or.cz, which fails with
the following error:

Initiated mirroring of git://people.freedesktop.org/~agd5f/linux to repo.or.cz
project agd5f-linux.git:

Project: agd5f-linux

Mirroring from URL "git://people.freedesktop.org/~agd5f/linux"

Initiating mirroring...
Fetching origin
error: object 17f7e29bd0870fd0f43ba1acde3c6c1b65aee734: badTimezone: invalid
author/committer line - bad time zone
fatal: Error in object
fatal: index-pack failed
error: Could not fetch origin

-- 
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 101491] Can't wake up the dedicated graphics card unless power management is disabled

[bugzilla-daemon]

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

--- Comment #1 from drkdf...@rocketmail.com ---
Created attachment 132032
  --> https://bugs.freedesktop.org/attachment.cgi?id=132032=edit
lspci -k output

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

[Bug 101491] Can't wake up the dedicated graphics card unless power management is disabled

[bugzilla-daemon]

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

Bug ID: 101491
   Summary: Can't wake up the dedicated graphics card unless power
management is disabled
   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: drkdf...@rocketmail.com

Created attachment 132031
  --> https://bugs.freedesktop.org/attachment.cgi?id=132031=edit
dmesg output

I have a ASUS K53TK with a AMD A6-3420M. It has an integrated graphics card the
AMD HD 6520G, and a dedicated one HD 7670M.
I am only able to use the dedicated card if I set the parameter
"radeon.runpm=0".
Otherwise xrandr only sees one provider, and DRI_PRIME=1 can't render any
program.

At boot time, if I don't disable the power management I get several error like
[  458.460874] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed
(scratch(0x8504)=0x).

-- 
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 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

[bugzilla-daemon]

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

--- Comment #30 from MirceaKitsune  ---
Created attachment 132030
  --> https://bugs.freedesktop.org/attachment.cgi?id=132030=edit
Photo of the corrupt image on the screen

I have discovered some very important details today. Everyone following up on
the report, please see this comment!

Recently I realized that a useful test would be to jump into a different run
level once I notice the crash, in order to see how the system behaves there. A
few minutes ago another freeze took place, so I instantly hit Control + Alt +
F1 to go to a console. What I noticed was pretty remarkable and sheds light on
a few aspects:

I could keep typing in the console for nearly 10 seconds, but after that the
exact same behavior still took place (monitor turned itself on and off two
times then the image froze). This time however I was able to toggle the NumLock
led a minute after the crash, while also seeing the HDD led still working; That
means this is not (always) a total system freeze such as a Kernel panic...
instead it appears to be the image output corrupting and staying that way,
freezing only specific components with it (I was still unable to issue a blind
reboot command for instance). To put everything into an approximate timeline,
this is what happened:

00 seconds in: The crash occurs.
02 seconds in: I notice and instantly hit Control + Alt + F1.
05 seconds in: I'm taken to a console where everything works fine: I see the
blinking cursor, can write my login and password, etc.
12 seconds in: Suddenly the monitor turns off and back on several times, then
the image remains frozen in place.

This time however, the screen did not remain turned off or black. Instead it
stayed stuck in a state showing corrupt lines and rectangles of random colors.
I took a photo of my screen with my smartphone, which I attached to this issue.

-- 
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 101294] radeonsi minecraft forge splash freeze since 17.1

[bugzilla-daemon]

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

Fabian Maurer  changed:

   What|Removed |Added

 CC||dark.shad...@web.de

--- Comment #5 from Fabian Maurer  ---
I can confirm the issue.

It doesn't always happen, but most of the time - it's fairly easy to reproduce.
Usually happens when you have a lot mods (I think).

LIBGL_ALWAYS_SOFTWARE resolves that issue and lets it load, and you can play it
just fine.

System the issue was tested on:
- Arch Linux 64bit
- Linux 4.11.6, AMDGPU driver
- Mesa 17.2.0-devel (git-58d337941e) / Mesa 17.1.2
- Radeon R9 285

I think it used to work previously, I'll run some regression tests in the
coming days.

-- 
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 100070] Rocket League: grass gets rendered incorrectly

[bugzilla-daemon]

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

--- Comment #7 from Nicolai Hähnle  ---
Hmm, I'm afraid that looks a bit tricky to analyze. I wonder if the game
actually does something slightly different on NVidia cards? Would be nice if
somebody could replay the trace on different hardware and see if the problem
exists there as well.

-- 
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] dt-bindings: display: sunxi: Improve endpoint ID scheme readability

[Rob Herring]

On Wed, Jun 14, 2017 at 02:30:16PM +0800, Chen-Yu Tsai wrote:
> The explanation for the endpoint ID numbering scheme is convoluted
> and hard to understand.
> 
> This patch aims to improve the readability of it by combining the
> existing two paragraphs, while also providing a diagram example,
> and how endpoints should be numbered based on that example.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
> 
> Hope this helps. I'm not sure I can improve this even more without
> spelling out all cases.
> 
> ---
>  .../bindings/display/sunxi/sun4i-drm.txt   | 36 
> --
>  1 file changed, 27 insertions(+), 9 deletions(-)

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

Re: [PATCH 42/44] powerpc/cell: use the dma_supported method for ops switching

[Benjamin Herrenschmidt]

On Sun, 2017-06-18 at 00:13 -0700, Christoph Hellwig wrote:
> On Sun, Jun 18, 2017 at 06:50:27AM +1000, Benjamin Herrenschmidt wrote:
> > What is your rationale here ? (I have missed patch 0 it seems).
> 
> Less code duplication, more modular dma_map_ops insteance.
> 
> > dma_supported() was supposed to be pretty much a "const" function
> > simply informing whether a given setup is possible. Having it perform
> > an actual switch of ops seems to be pushing it...
> 
> dma_supported() is already gone from the public DMA API as it doesn't
> make sense to be called separately from set_dma_mask.  It will be
> entirely gone in the next series after this one.

Ah ok, in that case it makes much more sense, we can rename it then.

> > What if a driver wants to test various dma masks and then pick one ?
> > 
> > Where does the API documents that if a driver calls dma_supported() it
> > then *must* set the corresponding mask and use that ?
> 
> Where is the API document for _any_ of the dma routines? (A: work in
> progress by me, but I need to clean up the mess of arch hooks before
> it can make any sense)

Heh fair enough.

> > I don't like a function that is a "boolean query" like this one to have
> > such a major side effect.
> > 
> > > From an API standpoint, dma_set_mask() is when the mask is established,
> > 
> > and thus when the ops switch should happen.
> 
> And that's exactly what happens at the driver API level.  It just turns
> out the dma_capable method is they way better place to actually
> implement it, as the ->set_dma_mask method requires lots of code
> duplication while not offering any actual benefit over ->dma_capable.
> And because of that it's gone after this series.
> 
> In theory we could rename ->dma_capable now, but it would require a
> _lot_ of churn.  Give me another merge window or two and we should
> be down to be about 2 handful of dma_map_ops instance, at which point
> we could do all this gratious renaming a lot more easily :)

Sure, I get it now, as long as it's not publicly exposed to drivers
we are fine.

Cheers,
Ben.

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

[Bug 101479] shader display problems Unreal 4 Engine

[bugzilla-daemon]

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

vinf...@gmail.com changed:

   What|Removed |Added

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

--- Comment #2 from vinf...@gmail.com ---
I built mesa with the patch, and it works.

-- 
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 101475] Max Core Profile for OpenGL showing 0.0

[bugzilla-daemon]

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

vinf...@gmail.com changed:

   What|Removed |Added

   Severity|normal  |minor

--- Comment #8 from vinf...@gmail.com ---
It turns out that this bug is only minor. Although it reports 0.0, running a
program with MESA_GL_VERSION_OVERRIDE works.

-- 
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 42/44] powerpc/cell: use the dma_supported method for ops switching

[Christoph Hellwig]

On Sun, Jun 18, 2017 at 06:50:27AM +1000, Benjamin Herrenschmidt wrote:
> What is your rationale here ? (I have missed patch 0 it seems).

Less code duplication, more modular dma_map_ops insteance.

> dma_supported() was supposed to be pretty much a "const" function
> simply informing whether a given setup is possible. Having it perform
> an actual switch of ops seems to be pushing it...

dma_supported() is already gone from the public DMA API as it doesn't
make sense to be called separately from set_dma_mask.  It will be
entirely gone in the next series after this one.

> What if a driver wants to test various dma masks and then pick one ?
> 
> Where does the API documents that if a driver calls dma_supported() it
> then *must* set the corresponding mask and use that ?

Where is the API document for _any_ of the dma routines? (A: work in
progress by me, but I need to clean up the mess of arch hooks before
it can make any sense)

> I don't like a function that is a "boolean query" like this one to have
> such a major side effect.
> 
> >From an API standpoint, dma_set_mask() is when the mask is established,
> and thus when the ops switch should happen.

And that's exactly what happens at the driver API level.  It just turns
out the dma_capable method is they way better place to actually
implement it, as the ->set_dma_mask method requires lots of code
duplication while not offering any actual benefit over ->dma_capable.
And because of that it's gone after this series.

In theory we could rename ->dma_capable now, but it would require a
_lot_ of churn.  Give me another merge window or two and we should
be down to be about 2 handful of dma_map_ops instance, at which point
we could do all this gratious renaming a lot more easily :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/44] dmaengine: ioat: don't use DMA_ERROR_CODE

[Christoph Hellwig]

On Fri, Jun 16, 2017 at 01:40:24PM -0700, Alexander Duyck wrote:
> dma_unmap_page on dest_dma if "op == IOAT_OP_XOR"? Odds are it is what
> the compiler is already generating and will save a few lines of code
> so what you end up with is something like:

Honestly wanted to touch the code as little as possible :)  If we want
to make it prettier and more readable it needs to be refactored.

If you're interested I can take a stab at that, but I'd like to keep
it out of this already giant series.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel