[RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

[Inki Dae]

On 2014년 11월 20일 23:23, Andrzej Hajda wrote:
> On 11/20/2014 02:56 PM, Inki Dae wrote:
>> On 2014년 11월 20일 22:19, Andrzej Hajda wrote:
>>> On 11/20/2014 11:24 AM, Inki Dae wrote:
 This patch makes kms drivers to be independent drivers.
 For this, it removes all register codes to kms drivers
 from exynos_drm_drv module and adds module_init/exit
 for each kms driver so that each kms driver can be
 called independently.

 Changelog v3:
 - Use module_platform_driver macro instead module_init/exit.
 - Configure all kms drivers to be built in kernel image.

 Changelog v2:
 - none

 Signed-off-by: Inki Dae 
 ---
  drivers/gpu/drm/exynos/exynos_dp_core.c  |2 ++
  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 
 +++---
  drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |2 ++
  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++
  drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
  drivers/gpu/drm/exynos/exynos_mixer.c|2 ++
  7 files changed, 13 insertions(+), 45 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index ed818b9..30ebf5d 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = {
},
  };
  
 +module_platform_driver(dp_driver);
>>>
>>> If you try to build exynosdrm as module you will receive errors due to
>>> multiple definitions of init_module, ie module_init/module_*_driver
>>> macros can be used once per module.
>>
>> Ah, right. we had ever tried same way before but failed in same problem.
>> I didn't realize that. Anyway, I will try to find out a better way. I'd
>> really like to remove all register codes of sub drivers from
>> exynos_drm_drv somehow.
> 
> I have proposed once solution with sparse arrays, using linker scripts
> [1]. Something similar is used with clock controllers as I remember.
> I do not see other possibilities to fully separate components of
> exynos_drm_drv.
> 
> [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/103816
> 

I know this patch. I wasn't sure that the use of the private linker
section is reasonable and overuse it. Actually, Mr. Park opposed this
way. It might be a good idea if no problem for device drivers use the
private linker section. Is there any device driver using the private
linker section?

Thanks,
Inki Dae

> Regards
> Andrzej
> 
>>
>>>
>>> Anyway I am afraid exynosdrm seems to be still fragile to order of
>>> successful probes of their components.
>>> It can be easily observed on the system with two display pipelines with
>>> one of them probe deferring. For example universal with fimd/dpi + vidi:
>>> 1. fimd defers probe because panel is not yet probed.
>>> 2. vidi probes ok.
>>> 3. drmdev is initialized.
>>> 4. fimd probes ok, but it is too late!!!
>>>
>>> So you can reproduce the scenario on any target when one of the
>>> components defers and vidi is present (vidi never defers I suppose).
>>
>> Thanks for checking,
>> Inki Dae
>>
>>>
>>> Regards
>>> Andrzej
>>>
 +
  MODULE_AUTHOR("Jingoo Han ");
  MODULE_DESCRIPTION("Samsung SoC DP Driver");
  MODULE_LICENSE("GPL v2");
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index eab12f0..02d4772 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -484,12 +484,6 @@ static struct component_match 
 *exynos_drm_match_add(struct device *dev)
  
mutex_lock(_component_lock);
  
 -  /* Do not retry to probe if there is no any kms driver regitered. */
 -  if (list_empty(_component_list)) {
 -  mutex_unlock(_component_lock);
 -  return ERR_PTR(-ENODEV);
 -  }
 -
list_for_each_entry(cdev, _component_list, list) {
/*
 * Add components to master only in case that crtc and
 @@ -545,22 +539,6 @@ static const struct component_master_ops 
 exynos_drm_ops = {
.unbind = exynos_drm_unbind,
  };
  
 -static struct platform_driver *const exynos_drm_kms_drivers[] = {
 -#ifdef CONFIG_DRM_EXYNOS_FIMD
 -  _driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_DP
 -  _driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_DSI
 -  _driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_HDMI
 -  _driver,
 -  _driver,
 -#endif
 -};
 -
  static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
  #ifdef CONFIG_DRM_EXYNOS_G2D
_driver,
 @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct 
 platform_device *pdev)
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);

[RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

[Inki Dae]

Hi Javier,

On 2014년 11월 20일 23:06, Javier Martinez Canillas wrote:
> Hello Inki,
> 
> On Thu, Nov 20, 2014 at 2:56 PM, Inki Dae  wrote:
>>> If you try to build exynosdrm as module you will receive errors due to
>>> multiple definitions of init_module, ie module_init/module_*_driver
>>> macros can be used once per module.
>>
>> Ah, right. we had ever tried same way before but failed in same problem.
>> I didn't realize that. Anyway, I will try to find out a better way. I'd
>> really like to remove all register codes of sub drivers from
>> exynos_drm_drv somehow.
>>
> 
> Maybe as an immediate fix we can move the platform driver registration
> out of probe as suggested by Andrzej?
> 
> I posted an RFC patch a couple of days ago [0] that fixes both the
> deadlock and the infinite loop bug so it would be great if you can
> review/test so I can post a proper patch.

Fantastical timing.:) I gave you a same opinion almost simultaneous.
Check your email thread.

Thanks,
Inki Dae

> 
> And then we can look how to better refactor the exynos drm driver.
> 
> Best regards,
> Javier
> 
> [0]: http://www.spinics.net/lists/linux-samsung-soc/msg39106.html
> 

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Inki Dae]

Hi Javier,

On 2014년 11월 18일 22:53, Javier Martinez Canillas wrote:
> The Exynos DRM driver register its sub-devices platform drivers in
> the probe function but after commit 43c0767 ("of/platform: Move
> platform devices under /sys/devices/platform"), this is causing
> a deadlock in __driver_attach(). Fix this by moving the platform
> drivers registration to exynos_drm_init().

Could you re-base this patch on top of exynos-drm-next? I tried to
separate sub drivers into independent drivers but it seems that we need
more times. So I will merge your patch.

Thanks,
Inki Dae

> 
> Suggested-by: Andrzej Hajda 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
> This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman [1].
> 
> Inki Dae said that he will fix it property by separating the Exynos DRM
> driver in different sub-modules but I post this patch as RFC anyways so
> others can test if this fixes their boot issue.
> 
> [0]: https://lkml.org/lkml/2014/11/6/125
> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39050.html
> 
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 163 
> 
>  1 file changed, 79 insertions(+), 84 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index e277d4f..5386fea 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -559,15 +559,58 @@ static const struct component_master_ops exynos_drm_ops 
> = {
>  static int exynos_drm_platform_probe(struct platform_device *pdev)
>  {
>   struct component_match *match;
> - int ret;
>  
>   pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>   exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>  
> + match = exynos_drm_match_add(>dev);
> + if (IS_ERR(match))
> + return PTR_ERR(match);
> +
> + return component_master_add_with_match(>dev, _drm_ops,
> +match);
> +}
> +
> +static int exynos_drm_platform_remove(struct platform_device *pdev)
> +{
> + component_master_del(>dev, _drm_ops);
> + return 0;
> +}
> +
> +static struct platform_driver exynos_drm_platform_driver = {
> + .probe  = exynos_drm_platform_probe,
> + .remove = exynos_drm_platform_remove,
> + .driver = {
> + .name   = "exynos-drm",
> + .pm = _drm_pm_ops,
> + },
> +};
> +
> +static int exynos_drm_init(void)
> +{
> + int ret;
> +
> + /*
> +  * Register device object only in case of Exynos SoC.
> +  *
> +  * Below codes resolves temporarily infinite loop issue incurred
> +  * by Exynos drm driver when using multi-platform kernel.
> +  * So these codes will be replaced with more generic way later.
> +  */
> + if (!of_machine_is_compatible("samsung,exynos3") &&
> + !of_machine_is_compatible("samsung,exynos4") &&
> + !of_machine_is_compatible("samsung,exynos5"))
> + return -ENODEV;
> +
> + exynos_drm_pdev = platform_device_register_simple("exynos-drm", -1,
> + NULL, 0);
> + if (IS_ERR(exynos_drm_pdev))
> + return PTR_ERR(exynos_drm_pdev);
> +
>  #ifdef CONFIG_DRM_EXYNOS_FIMD
>   ret = platform_driver_register(_driver);
>   if (ret < 0)
> - return ret;
> + goto err_unregister_pdev;
>  #endif
>  
>  #ifdef CONFIG_DRM_EXYNOS_DP
> @@ -591,21 +634,10 @@ static int exynos_drm_platform_probe(struct 
> platform_device *pdev)
>   goto err_unregister_mixer_drv;
>  #endif
>  
> - match = exynos_drm_match_add(>dev);
> - if (IS_ERR(match)) {
> - ret = PTR_ERR(match);
> - goto err_unregister_hdmi_drv;
> - }
> -
> - ret = component_master_add_with_match(>dev, _drm_ops,
> - match);
> - if (ret < 0)
> - goto err_unregister_hdmi_drv;
> -
>  #ifdef CONFIG_DRM_EXYNOS_G2D
>   ret = platform_driver_register(_driver);
>   if (ret < 0)
> - goto err_del_component_master;
> + goto err_unregister_hdmi_drv;
>  #endif
>  
>  #ifdef CONFIG_DRM_EXYNOS_FIMC
> @@ -636,9 +668,27 @@ static int exynos_drm_platform_probe(struct 
> platform_device *pdev)
>   goto err_unregister_ipp_drv;
>  #endif
>  
> - return ret;
> +#ifdef CONFIG_DRM_EXYNOS_VIDI
> + ret = exynos_drm_probe_vidi();
> + if (ret < 0)
> + goto err_unregister_ipp_dev;
> +#endif
> +
> + ret = platform_driver_register(_drm_platform_driver);
> + if (ret)
> + goto err_remove_vidi;
> +
> + return 0;
> +
> +err_remove_vidi:
> +#ifdef CONFIG_DRM_EXYNOS_VIDI
> + exynos_drm_remove_vidi();
> +err_unregister_pd:
> +#endif
>  
>  #ifdef CONFIG_DRM_EXYNOS_IPP
> +err_unregister_ipp_dev:
> + exynos_platform_device_ipp_unregister();
>  err_unregister_ipp_drv:

[RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

[Inki Dae]

On 2014년 11월 20일 22:19, Andrzej Hajda wrote:
> On 11/20/2014 11:24 AM, Inki Dae wrote:
>> This patch makes kms drivers to be independent drivers.
>> For this, it removes all register codes to kms drivers
>> from exynos_drm_drv module and adds module_init/exit
>> for each kms driver so that each kms driver can be
>> called independently.
>>
>> Changelog v3:
>> - Use module_platform_driver macro instead module_init/exit.
>> - Configure all kms drivers to be built in kernel image.
>>
>> Changelog v2:
>> - none
>>
>> Signed-off-by: Inki Dae 
>> ---
>>  drivers/gpu/drm/exynos/exynos_dp_core.c  |2 ++
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 
>> +++---
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |2 ++
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++
>>  drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
>>  drivers/gpu/drm/exynos/exynos_mixer.c|2 ++
>>  7 files changed, 13 insertions(+), 45 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index ed818b9..30ebf5d 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = {
>>  },
>>  };
>>  
>> +module_platform_driver(dp_driver);
> 
> If you try to build exynosdrm as module you will receive errors due to
> multiple definitions of init_module, ie module_init/module_*_driver
> macros can be used once per module.

Ah, right. we had ever tried same way before but failed in same problem.
I didn't realize that. Anyway, I will try to find out a better way. I'd
really like to remove all register codes of sub drivers from
exynos_drm_drv somehow.

> 
> Anyway I am afraid exynosdrm seems to be still fragile to order of
> successful probes of their components.
> It can be easily observed on the system with two display pipelines with
> one of them probe deferring. For example universal with fimd/dpi + vidi:
> 1. fimd defers probe because panel is not yet probed.
> 2. vidi probes ok.
> 3. drmdev is initialized.
> 4. fimd probes ok, but it is too late!!!
> 
> So you can reproduce the scenario on any target when one of the
> components defers and vidi is present (vidi never defers I suppose).

Thanks for checking,
Inki Dae

> 
> Regards
> Andrzej
> 
>> +
>>  MODULE_AUTHOR("Jingoo Han ");
>>  MODULE_DESCRIPTION("Samsung SoC DP Driver");
>>  MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index eab12f0..02d4772 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -484,12 +484,6 @@ static struct component_match 
>> *exynos_drm_match_add(struct device *dev)
>>  
>>  mutex_lock(_component_lock);
>>  
>> -/* Do not retry to probe if there is no any kms driver regitered. */
>> -if (list_empty(_component_list)) {
>> -mutex_unlock(_component_lock);
>> -return ERR_PTR(-ENODEV);
>> -}
>> -
>>  list_for_each_entry(cdev, _component_list, list) {
>>  /*
>>   * Add components to master only in case that crtc and
>> @@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops 
>> = {
>>  .unbind = exynos_drm_unbind,
>>  };
>>  
>> -static struct platform_driver *const exynos_drm_kms_drivers[] = {
>> -#ifdef CONFIG_DRM_EXYNOS_FIMD
>> -_driver,
>> -#endif
>> -#ifdef CONFIG_DRM_EXYNOS_DP
>> -_driver,
>> -#endif
>> -#ifdef CONFIG_DRM_EXYNOS_DSI
>> -_driver,
>> -#endif
>> -#ifdef CONFIG_DRM_EXYNOS_HDMI
>> -_driver,
>> -_driver,
>> -#endif
>> -};
>> -
>>  static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
>>  #ifdef CONFIG_DRM_EXYNOS_G2D
>>  _driver,
>> @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct 
>> platform_device *pdev)
>>  pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>  exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>>  
>> -for (i = 0; i < ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
>> -ret = platform_driver_register(exynos_drm_kms_drivers[i]);
>> -if (ret < 0)
>> -goto err_unregister_kms_drivers;
>> -}
>> -
>>  match = exynos_drm_match_add(>dev);
>> -if (IS_ERR(match)) {
>> -ret = PTR_ERR(match);
>> -goto err_unregister_kms_drivers;
>> -}
>> +if (IS_ERR(match))
>> +return PTR_ERR(match);
>>  
>>  ret = component_master_add_with_match(>dev, _drm_ops,
>>  match);
>>  if (ret < 0)
>> -goto err_unregister_kms_drivers;
>> +return ret;
>>  
>>  for (j = 0; j < ARRAY_SIZE(exynos_drm_non_kms_drivers); ++j) {
>>  ret = platform_driver_register(exynos_drm_non_kms_drivers[j]);
>> @@ -632,10 +602,6 

[PATCH 1/2] drm/atomic: check mode_changed *after* atomic_check

[Daniel Vetter]

On Thu, Nov 20, 2014 at 03:55:06PM -0500, Rob Clark wrote:
> The intention is that drivers can set crtc_state->mode_changed in their
> atomic_check() fxns if they encounter a scenario that requires full
> modeset.
> 
> Signed-off-by: Rob Clark 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index fad2b93..5ae5b25 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -332,7 +332,7 @@ mode_fixup(struct drm_atomic_state *state)
>  }
>  
>  static int
> -drm_atomic_helper_check_prepare(struct drm_device *dev,
> +drm_atomic_helper_check_modeset(struct drm_device *dev,
>   struct drm_atomic_state *state)
>  {
>   int ncrtcs = dev->mode_config.num_crtc;
> @@ -430,10 +430,6 @@ int drm_atomic_helper_check(struct drm_device *dev,
>   int ncrtcs = dev->mode_config.num_crtc;
>   int i, ret = 0;
>  
> - ret = drm_atomic_helper_check_prepare(dev, state);
> - if (ret)
> - return ret;
> -
>   for (i = 0; i < nplanes; i++) {
>   struct drm_plane_helper_funcs *funcs;
>   struct drm_plane *plane = state->planes[i];
> @@ -477,6 +473,10 @@ int drm_atomic_helper_check(struct drm_device *dev,
>   }
>   }
>  
> + ret = drm_atomic_helper_check_modeset(dev, state);
> + if (ret)
> + return ret;
> +
>   return ret;
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_check);
> -- 
> 1.9.3
> 

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

[PATCH 2/2] drm/atomic: shutdown *current* encoder

[Daniel Vetter]

On Thu, Nov 20, 2014 at 03:55:07PM -0500, Rob Clark wrote:
> In disable_outputs() we need to shut down the outgoing encoder, not the
> incoming one (we have already swapped-state at this point).  Without
> this, we end up telling the driver to crtc->dpms(OFF) without first
> encoder->dpms(OFF), and that makes some hw quite unhappy.
> 
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5ae5b25..8e4f3fc 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -502,7 +502,7 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>   if (!old_conn_state || !old_conn_state->crtc)
>   continue;
>  
> - encoder = connector->state->best_encoder;
> + encoder = old_conn_state->best_encoder;
>  
>   if (!encoder)

I wanted a if (WARN_ON(!encoder)) here for my r-b, since this really
shouldn't ever happen. And these kinds of cross-checks tend to be useful
ime.
-Daniel

>   continue;
> -- 
> 1.9.3
> 

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

[PATCH for 3.18-rc5] drm/ttm: Avoid memory allocation from shrinker functions.

[Tetsuo Handa]

>From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Thu, 13 Nov 2014 22:21:54 +0900
Subject: [PATCH] drm/ttm: Avoid memory allocation from shrinker functions.

Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid
deadlock.") caused BUG_ON() due to sc->gfp_mask containing flags
which are not in GFP_KERNEL.

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

Changing from sc->gfp_mask to (sc->gfp_mask & GFP_KERNEL) would
avoid the BUG_ON(), but avoiding memory allocation from shrinker
function is better and reliable fix.

Shrinker functions are already serialized by commit 71336e011d1d2312
("drm/ttm: Fix possible stack overflow by recursive shrinker calls.") and
commit 22e71691fd54c637 ("drm/ttm: Use mutex_trylock() to avoid deadlock
inside shrinker functions."), and clean up functions are called only after
shrinker functions are unregistered. Therefore, we can use static buffer
when called from shrinker functions and clean up functions.

Signed-off-by: Tetsuo Handa 
Cc: stable  [2.6.35+]
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 26 +++---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 25 +++--
 2 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 09874d6..025c429 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -297,11 +297,12 @@ static void ttm_pool_update_free_locked(struct 
ttm_page_pool *pool,
  *
  * @pool: to free the pages from
  * @free_all: If set to true will free all pages in pool
- * @gfp: GFP flags.
+ * @use_static: Safe to use static buffer
  **/
 static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,
- gfp_t gfp)
+ bool use_static)
 {
+   static struct page *static_buf[NUM_PAGES_TO_ALLOC];
unsigned long irq_flags;
struct page *p;
struct page **pages_to_free;
@@ -311,7 +312,11 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
if (NUM_PAGES_TO_ALLOC < nr_free)
npages_to_free = NUM_PAGES_TO_ALLOC;

-   pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
+   if (use_static)
+   pages_to_free = static_buf;
+   else
+   pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
+   GFP_KERNEL);
if (!pages_to_free) {
pr_err("Failed to allocate memory for pool free operation\n");
return 0;
@@ -374,7 +379,8 @@ restart:
if (freed_pages)
ttm_pages_put(pages_to_free, freed_pages);
 out:
-   kfree(pages_to_free);
+   if (pages_to_free != static_buf)
+   kfree(pages_to_free);
return nr_free;
 }

@@ -383,8 +389,6 @@ out:
  *
  * XXX: (dchinner) Deadlock warning!
  *
- * We need to pass sc->gfp_mask to ttm_page_pool_free().
- *
  * This code is crying out for a shrinker per pool
  */
 static unsigned long
@@ -407,8 +411,8 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
if (shrink_pages == 0)
break;
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
-   shrink_pages = ttm_page_pool_free(pool, nr_free,
- sc->gfp_mask);
+   /* OK to use static buffer since global mutex is held. */
+   shrink_pages = ttm_page_pool_free(pool, nr_free, true);
freed += nr_free - shrink_pages;
}
mutex_unlock();
@@ -710,7 +714,7 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
}
spin_unlock_irqrestore(>lock, irq_flags);
if (npages)
-   ttm_page_pool_free(pool, npages, GFP_KERNEL);
+   ttm_page_pool_free(pool, npages, false);
 }

 /*
@@ -849,9 +853,9 @@ void ttm_page_alloc_fini(void)
pr_info("Finalizing pool allocator\n");
ttm_pool_mm_shrink_fini(_manager);

+   /* OK to use static buffer since global mutex is no longer used. */
for (i = 0; i < NUM_POOLS; ++i)
-   ttm_page_pool_free(&_manager->pools[i], FREE_ALL_PAGES,
-  GFP_KERNEL);
+   ttm_page_pool_free(&_manager->pools[i], FREE_ALL_PAGES, true);

kobject_put(&_manager->kobj);
_manager = NULL;
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c96db43..01e1d27 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -411,11 +411,12 @@ static void ttm_dma_page_put(struct dma_pool *pool, 
struct dma_page *d_page)
  *
  * @pool: to free the pages from
  * @nr_free: If set to true will 

[Bug 86413] Euro Truck Simulator 2: Severe stuttering with Kernel >=3.17

[bugzilla-dae...@freedesktop.org]

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

Andreas Grois  changed:

   What|Removed |Added

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

--- Comment #8 from Andreas Grois  ---
In my opinion: Yes. I'll mark it as resolved/fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/ec5890d5/attachment-0001.html>

[PATCH 3/3] drm/exynos: avoid leak if exynos_dpi_probe() fails

[Gustavo Padovan]

From: Gustavo Padovan 

The component must be deleted if the probe fails.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0673a39..173d135 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1202,8 +1202,10 @@ static int fimd_probe(struct platform_device *pdev)
fimd_manager.ctx = ctx;

ctx->display = exynos_dpi_probe(dev);
-   if (IS_ERR(ctx->display))
-   return PTR_ERR(ctx->display);
+   if (IS_ERR(ctx->display)) {
+   ret = PTR_ERR(ctx->display);
+   goto err_del_component;
+   }

pm_runtime_enable(>dev);

-- 
1.9.3

[PATCH 2/3] drm/exynos: avoid race condition when adding a drm component

[Gustavo Padovan]

From: Gustavo Padovan 

exynos_drm_component_add() correctly checks if a component is present on
drm_component_list however it release the lock right after the check
and before we add the new component to the list. That just creates room
to add the same component more than once to the list.

The lock should be held for the whole journey while adding a new
component.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index cb3ed9b..230573d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -402,10 +402,8 @@ int exynos_drm_component_add(struct device *dev,
 * added already just return.
 */
if (cdev->dev_type_flag == (EXYNOS_DEVICE_TYPE_CRTC |
-   EXYNOS_DEVICE_TYPE_CONNECTOR)) {
-   mutex_unlock(_component_lock);
-   return 0;
-   }
+   EXYNOS_DEVICE_TYPE_CONNECTOR))
+   goto unlock;

if (dev_type == EXYNOS_DEVICE_TYPE_CRTC) {
cdev->crtc_dev = dev;
@@ -417,14 +415,11 @@ int exynos_drm_component_add(struct device *dev,
cdev->dev_type_flag |= dev_type;
}

-   mutex_unlock(_component_lock);
-   return 0;
+   goto unlock;
}
}

-   mutex_unlock(_component_lock);
-
-   cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
+   cdev = kzalloc(sizeof(*cdev), GFP_ATOMIC);
if (!cdev)
return -ENOMEM;

@@ -436,10 +431,9 @@ int exynos_drm_component_add(struct device *dev,
cdev->out_type = out_type;
cdev->dev_type_flag = dev_type;

-   mutex_lock(_component_lock);
list_add_tail(>list, _component_list);
+unlock:
mutex_unlock(_component_lock);
-
return 0;
 }

-- 
1.9.3

[PATCH 1/3] drm/exynos: free DP if probe fails to find a panel or bridge

[Gustavo Padovan]

From: Gustavo Padovan 

DP was leaked everytime function returns EPROBE_DEFER, free it before
returning.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 85762cf..6fd4a46 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1336,8 +1336,10 @@ static int exynos_dp_probe(struct platform_device *pdev)
if (panel_node) {
dp->panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
-   if (!dp->panel)
-   return -EPROBE_DEFER;
+   if (!dp->panel) {
+   ret = -EPROBE_DEFER;
+   goto free_dp;
+   }
}

endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
@@ -1346,10 +1348,14 @@ static int exynos_dp_probe(struct platform_device *pdev)
if (bridge_node) {
dp->bridge = of_drm_find_bridge(bridge_node);
of_node_put(bridge_node);
-   if (!dp->bridge)
-   return -EPROBE_DEFER;
-   } else
-   return -EPROBE_DEFER;
+   if (!dp->bridge) {
+   ret = -EPROBE_DEFER;
+   goto free_dp;
+   }
+   } else {
+   ret = -EPROBE_DEFER;
+   goto free_dp;
+   }
}

exynos_dp_display.ctx = dp;
@@ -1359,6 +1365,9 @@ static int exynos_dp_probe(struct platform_device *pdev)
exynos_drm_component_del(>dev,
EXYNOS_DEVICE_TYPE_CONNECTOR);

+free_dp:
+   devm_kfree(dev, dp);
+
return ret;
 }

-- 
1.9.3

[PATCH 3/3] drm/exynos: move Exynos platform drivers registration to init

[Gustavo Padovan]

From: Gustavo Padovan 

Registering the Exynos DRM subdevices platform drivers in the probe
function is causing an infinite loop. Fix this by moving it to the
exynos_drm_init() function to register the drivers on module init.

Registering drivers in the probe functions causes a deadlock in the parent
device lock. See Grant Likely explanation on the topic:

"I think the problem is that exynos_drm_init() is registering a normal
(non-OF) platform device, so the parent will be /sys/devices/platform.
It immediately gets bound against exynos_drm_platform_driver which
calls the exynos drm_platform_probe() hook. The driver core obtains
device_lock() on the device *and on the device parent*.

Inside the probe hook, additional platform_drivers get registered.
Each time one does, it tries to bind against every platform device in
the system, which includes the ones created by OF. When it attempts to
bind, it obtains device_lock() on the device *and on the device
parent*.

Before the change to move of-generated platform devices into
/sys/devices/platform, the devices had different parents. Now both
devices have /sys/devices/platform as the parent, so yes they are
going to deadlock.

The real problem is registering drivers from within a probe hook. That
is completely wrong for the above deadlock reason. __driver_attach()
will deadlock. Those registrations must be pulled out of .probe().

Registering devices in .probe() is okay because __device_attach()
doesn't try to obtain device_lock() on the parent."

 INFO: task swapper/0:1 blocked for more than 120 seconds.
   Not tainted 3.18.0-rc3-next-20141105 #794
 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 swapper/0   D c052534c 0 1  0 0x
 [] (__schedule) from [] 
(schedule_preempt_disabled+0x14/0x20)
 [] (schedule_preempt_disabled) from [] 
(mutex_lock_nested+0x1c4/0x464

 [] (mutex_lock_nested) from [] (__driver_attach+0x48/0x98)
 [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
 [] (bus_for_each_dev) from [] (bus_add_driver+0xe4/0x200)
 [] (bus_add_driver) from [] (driver_register+0x78/0xf4)
 [] (driver_register) from [] 
(exynos_drm_platform_probe+0x34/0x234)
 [] (exynos_drm_platform_probe) from [] 
(platform_drv_probe+0x48/0xa4)
 [] (platform_drv_probe) from [] 
(driver_probe_device+0x13c/0x37c)
 [] (driver_probe_device) from [] 
(__driver_attach+0x94/0x98)
 [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
 [] (bus_for_each_dev) from [] (bus_add_driver+0xe4/0x200)
 [] (bus_add_driver) from [] (driver_register+0x78/0xf4)
 [] (driver_register) from [] (exynos_drm_init+0x70/0xa0)
 [] (exynos_drm_init) from [] (do_one_initcall+0xac/0x1f0)
 [] (do_one_initcall) from [] 
(kernel_init_freeable+0x10c/0x1d8)
 [] (kernel_init_freeable) from [] (kernel_init+0x8/0xec)
 [] (kernel_init) from [] (ret_from_fork+0x14/0x2c)
 3 locks held by swapper/0/1:
  #0:  (>mutex){..}, at: [] __driver_attach+0x48/0x98
  #1:  (>mutex){..}, at: [] __driver_attach+0x58/0x98
  #2:  (>mutex){..}, at: [] __driver_attach+0x48/0x98

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 124 +++-
 1 file changed, 59 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 91891cf..cb3ed9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -548,6 +548,38 @@ static const struct component_master_ops exynos_drm_ops = {
.unbind = exynos_drm_unbind,
 };

+static int exynos_drm_platform_probe(struct platform_device *pdev)
+{
+   struct component_match *match;
+
+   pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
+
+   match = exynos_drm_match_add(>dev);
+   if (IS_ERR(match)) {
+   return PTR_ERR(match);
+   }
+
+   return component_master_add_with_match(>dev, _drm_ops,
+  match);
+}
+
+static int exynos_drm_platform_remove(struct platform_device *pdev)
+{
+   component_master_del(>dev, _drm_ops);
+   return 0;
+}
+
+static struct platform_driver exynos_drm_platform_driver = {
+   .probe  = exynos_drm_platform_probe,
+   .remove = exynos_drm_platform_remove,
+   .driver = {
+   .owner  = THIS_MODULE,
+   .name   = "exynos-drm",
+   .pm = _drm_pm_ops,
+   },
+};
+
 static struct platform_driver *const exynos_drm_kms_drivers[] = {
 #ifdef CONFIG_DRM_EXYNOS_FIMD
_driver,
@@ -582,13 +614,24 @@ static struct platform_driver *const 
exynos_drm_non_kms_drivers[] = {
 #endif
 };

-static int exynos_drm_platform_probe(struct platform_device *pdev)
+static int exynos_drm_init(void)
 {
-   struct component_match *match;
int ret, i, j;

-   

[PATCH 2/3] Revert "drm/exynos: fix null pointer dereference issue"

[Gustavo Padovan]

From: Gustavo Padovan 

This reverts commit cea24824ab432f8acabb254d6805e9aa756de6af.

Moving subdriver probe to exynos_drm_platform_probe() was making
exynos_drm_device_subdrv_probe() fail because the platform data wasn't set
yet. It only gets set in exynos_drm_load.

We need to find a smarter way to fix this issue.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b94c9d1..91891cf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -108,6 +108,11 @@ static int exynos_drm_load(struct drm_device *dev, 
unsigned long flags)
if (ret)
goto err_unbind_all;

+   /* Probe non kms sub drivers and virtual display driver. */
+   ret = exynos_drm_device_subdrv_probe(dev);
+   if (ret)
+   goto err_cleanup_vblank;
+
/*
 * enable drm irq mode.
 * - with irq_enabled = true, we can use the vblank feature.
@@ -133,6 +138,8 @@ static int exynos_drm_load(struct drm_device *dev, unsigned 
long flags)

return 0;

+err_cleanup_vblank:
+   drm_vblank_cleanup(dev);
 err_unbind_all:
component_unbind_all(dev->dev, dev);
 err_mode_config_cleanup:
@@ -146,6 +153,8 @@ err_free_private:

 static int exynos_drm_unload(struct drm_device *dev)
 {
+   exynos_drm_device_subdrv_remove(dev);
+
exynos_drm_fbdev_fini(dev);
drm_kms_helper_poll_fini(dev);

@@ -608,14 +617,8 @@ static int exynos_drm_platform_probe(struct 
platform_device *pdev)
if (ret < 0)
goto err_unregister_non_kms_drivers;

-   /* Probe non kms sub drivers and virtual display driver. */
-   ret = exynos_drm_device_subdrv_probe(platform_get_drvdata(pdev));
-   if (ret)
-   goto err_unregister_resources;
-
return ret;

-err_unregister_resources:
 #ifdef CONFIG_DRM_EXYNOS_IPP
exynos_platform_device_ipp_unregister();
 #endif
@@ -637,8 +640,6 @@ static int exynos_drm_platform_remove(struct 
platform_device *pdev)
 {
int i;

-   exynos_drm_device_subdrv_remove(platform_get_drvdata(pdev));
-
 #ifdef CONFIG_DRM_EXYNOS_IPP
exynos_platform_device_ipp_unregister();
 #endif
-- 
1.9.3

[PATCH 1/3] drm/exynos: revert fixes for the infinite loop issue

[Gustavo Padovan]

From: Gustavo Padovan 

This reverts commit 06a2f5c2c4e0cb4ff38ca3769ae1f81cc2d030cf and
f7c2f36f4395f12d8ecb25c28ee88ec87b457089.

These two patches were trying to fix an issue that was causing an
infinite loop at the load of the exynos-drm but they were not tackling the
source of the problem.

A new patch that move the platform driver registration exynos_drm_init()
follows this revert and fix the issue properly.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index eab12f0..b94c9d1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -484,12 +484,6 @@ static struct component_match *exynos_drm_match_add(struct 
device *dev)

mutex_lock(_component_lock);

-   /* Do not retry to probe if there is no any kms driver regitered. */
-   if (list_empty(_component_list)) {
-   mutex_unlock(_component_lock);
-   return ERR_PTR(-ENODEV);
-   }
-
list_for_each_entry(cdev, _component_list, list) {
/*
 * Add components to master only in case that crtc and
@@ -674,18 +668,6 @@ static int exynos_drm_init(void)
 {
int ret;

-   /*
-* Register device object only in case of Exynos SoC.
-*
-* Below codes resolves temporarily infinite loop issue incurred
-* by Exynos drm driver when using multi-platform kernel.
-* So these codes will be replaced with more generic way later.
-*/
-   if (!of_machine_is_compatible("samsung,exynos3") &&
-   !of_machine_is_compatible("samsung,exynos4") &&
-   !of_machine_is_compatible("samsung,exynos5"))
-   return -ENODEV;
-
exynos_drm_pdev = platform_device_register_simple("exynos-drm", -1,
NULL, 0);
if (IS_ERR(exynos_drm_pdev))
-- 
1.9.3

[PATCH 0/3] drm/exynos: Fix exynos-drm initialization

[Gustavo Padovan]

From: Gustavo Padovan 

These patches were tested both in drm-exynos-next and linux-next (with
drm-exynos-next merged in) and it solves the infinite loop and parent device
lock deadlock. It was tested with Ajay's DP patches applied. A tree based on
drm-exynos-next can be found here:

https://git.kernel.org/cgit/linux/kernel/git/padovan/drm-exynos.git/log/?h=dp-integ

The first patch reverts the other tries to fix this problem.

The second patch is a revert and fixes a regression with the subdriver probe
function getting a NULL drvdata and thus failing drm_exynos_init()

The third patch is a port to drm-exynos-next of Javier patches that moves the
platform driver registration to init.

Gustavo Padovan (3):
  drm/exynos: revert fixes for the infinite loop issue
  Revert "drm/exynos: fix null pointer dereference issue"
  drm/exynos: move Exynos platform drivers registration to init

 drivers/gpu/drm/exynos/exynos_drm_drv.c | 159 ++--
 1 file changed, 68 insertions(+), 91 deletions(-)

-- 
1.9.3

[PATCH 1/2] drm/exynos: fix null pointer dereference issue

[Gustavo Padovan]

2014-11-13 Inki Dae :

> This patch fixes null pointer dereference issue incurred
> when ipp driver is enabled and Exynos drm driver is closed.
> 
> Non kms driver should register its own sub driver to setup necessary
> resources, which is done by load(). So null pointer dereference
> occurs when ipp driver is enabled and Exynos drm driver is closed
> because ipp core device is registered after component_master_add_with_match
> call.
> 
> This patch makes exynos_drm_device_subdrv_probe() to be called after all non
> kms drivers are registered.

This patch is breaking exynos initialization, exynos_drm_device_subdrv_probe()
needs the drvdata but it is still NULL at this point which make the whole
exynos init fails. The drvdata is only set in exynos_drm_load() so we need
call exynos_drm_device_subdrv_probe() after that.

Do you have the crash output for this? What is the issue you are fixing?
Usually you should add this kind of information to you commit message, it
helps us understand what you are fixing, specially in cases when a regression
is introduced, like this patch for example

Gustavo

[Bug 82186] [r600g] BARTS GPU lockup with minecraft shaders

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from EoD  ---
Mesa 10.3.1:
I can confirm that minecraft+shaders with R600_DEBUG=notiling does not lock up
my system, although there a plenty of errors like:

EE r600_shader.c:157 r600_pipe_shader_create - translation from TGSI failed !
EE r600_state_common.c:751 r600_shader_select - Failed to build shader variant
(type=1) -1


Without R600_DEBUG=notiling, behaviour hasn't changed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/42a0929f/attachment.html>

[PATCH] drm_atomic_helper: Copy/paste fix for calling already disabled planes

[Jasper St. Pierre]

This code was in drm_plane_helper, but missing from drm_atomic_helper,
causing various crashes when the plane was already disabled. Just copy
over the quick return there to prevent a crash.

Signed-off-by: Jasper St. Pierre 
Reviewed-by: Rob Clark 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index fad2b93..d96dac3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1246,6 +1246,11 @@ int drm_atomic_helper_disable_plane(struct drm_plane 
*plane)
struct drm_plane_state *plane_state;
int ret = 0;

+   /* crtc helpers love to call disable functions for already disabled hw
+* functions. So cope with that. */
+   if (!plane->crtc)
+   return 0;
+
state = drm_atomic_state_alloc(plane->dev);
if (!state)
return -ENOMEM;
-- 
2.1.0

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Pankaj Dubey]

On 20 November 2014 15:22, Vivek Gautam  wrote:
> Hi Javier,
>
>
> On Thu, Nov 20, 2014 at 2:15 PM, Javier Martinez Canillas
>  wrote:
>> Hello Vivek,
>>
>> On 11/20/2014 08:51 AM, Vivek Gautam wrote:
>>>>
>>>> I tested linux-next on Exynos5800 peach-pi board with linux-next and and 
>>>> the two
>>>> patches $Subject and [0].
>>>>
>>>> Below is my git hash:
>>>> 4d9e6ee drm/exynos: Move platform drivers registration to module init
>>>> 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for 
>>>> dp phy
>>>> 36391a5 Add linux-next specific files for 20141119
>>>> 9b1ced1 Merge branch 'akpm/master'
>>>> 282497e mm: add strictlimit knob
>>>
>>> used exynos_defconfig
>>>
>>
>> Same here.
>>
>>>>
>>>> With this display works for me.
>>>> Without $Subject patch i get lookup in drm.
>>>>
>>
>> I tested with today linux-next (next-20141120) and display is indeed
>> working for me. So it seems that whatever caused the error in the
>> phy-exynos-mipi-video driver reported by Paolo, got fixed recently.
>>
>> My working git hash is:
>>
>> 65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>> a9b43cb drm/exynos: Move platform drivers registration to module init
>> 5b83d7a Add linux-next specific files for 20141120
>> 1172916 mm: add strictlimit knob
>>
>> I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel
>> did not boot due the issue reported previously by Kevin.
>>
>>>> Javier can you tell me your git hash. Was it on yesterday's linux-next ?
>>>
>>
>> In fact, my branch where I could reproduce the phy-exynos-mipi-video issue
>> was not based on yesterday's next but next-20141117. The git hash is:
>>
>> 9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>> f740096 drm/exynos: Move platform drivers registration to module init
>> efefb5c Add linux-next specific files for 20141117
>> 8c944d7 mm: add strictlimit knob
>>
>>> With 3.18-rc5 i could see display on Exynos5800 peach-pi with
>>> following git hash:
>>>
>>> b6dca11 drm/exynos: dp: Remove support for unused dptx-phy
>>> 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support
>>> d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>>> fc14f9c Linux 3.18-rc5
>>> e35c5a2 Merge tag 'armsoc-for-rc5' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
>>>
>>> I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig).
>>>
>>
>> Yes, that works because the commit that caused the Exynos DRM lockup was:
>>
>> 43c0767 ("of/platform: Move platform devices under /sys/devices/platform")
>>
>> which landed in next-20141105.
>>
>> Reverting 43c0767 and only applying [0] should have the same effect.
>>
>>> I am checking further with linux-samsung, coz i could see weird
>>> behavior as mentioned
>>> in [1] with linux-samsun/for-next merged with above git hash.
>>>
>>
>> Great, it should be good to know what caused:
>
> On linux-samsung tree the only patch that's missing apart from dptx-phy 
> patches
> is the syscon patch from Pankaj Dubey:
> b784b98 mfd: syscon: Decouple syscon interface from platform devices
>

This patch has landed in mfd/for-next and linux-next. Without this on
kgene/for-next, any driver
seeking PMU register via syscon API will fail to get regmap handles.

Thanks,
Pankaj Dubey

> So with below git hash, linux-samsung/for-next display works fine along with
> other devices that request PMU system controller :
>
> 7bd219e drm/exynos: dp: Remove support for unused dptx-phy
> e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> 7099bde Revert "Revert "ARM: exynos_defconfig: Enable options for
> display panel support""
> 713a994 mfd: syscon: Decouple syscon interface from platform devices
> 7552917 Revert "ARM: exynos_defconfig: Enable options for display
> panel support" /* This is Kukjin's for-next today */
> ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next
> 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next
> cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next
> 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
> 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device
> 0526f27 ARM

[RFC PATCH v3 4/4] drm/exynos: clean up machine compatible string check

[Inki Dae]

Use 'for' statemant instead of hard-coded 'if' statement.

Changelog v3:
- none

Changelog v2:
- none

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 3ac39b6..4579186 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -587,9 +587,16 @@ static struct platform_driver exynos_drm_platform_driver = 
{
},
 };

+static const char * const strings[] = {
+   "samsung,exynos3",
+   "samsung,exynos4",
+   "samsung,exynos5",
+};
+
 static int exynos_drm_init(void)
 {
-   int ret;
+   bool is_exynos = false;
+   int ret, i;

/*
 * Register device object only in case of Exynos SoC.
@@ -598,9 +605,14 @@ static int exynos_drm_init(void)
 * by Exynos drm driver when using multi-platform kernel.
 * So these codes will be replaced with more generic way later.
 */
-   if (!of_machine_is_compatible("samsung,exynos3") &&
-   !of_machine_is_compatible("samsung,exynos4") &&
-   !of_machine_is_compatible("samsung,exynos5"))
+   for (i = 0; i < ARRAY_SIZE(strings); i++) {
+   if (of_machine_is_compatible(strings[i])) {
+   is_exynos = true;
+   break;
+   }
+   }
+
+   if (!is_exynos)
return -ENODEV;

exynos_drm_pdev = platform_device_register_simple("exynos-drm", -1,
-- 
1.7.9.5

[RFC PATCH v3 3/4] drm/exynos: make vidi driver to be independent driver

[Inki Dae]

This patch makes vidi driver to be independent driver.
For this, it removes register codes to vidi driver
from exynos_drm_drv module and adds module_init/exit
for vidi driver so that this driver can be called
independently.

In addition, this patch adds component support to vidi driver
so that this driver can be bound independently.

Changelog v3:
- none

Changelog v2:
- none

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   12 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |9 
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |   81 +++---
 3 files changed, 54 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 7f1186e..3ac39b6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -608,19 +608,12 @@ static int exynos_drm_init(void)
if (IS_ERR(exynos_drm_pdev))
return PTR_ERR(exynos_drm_pdev);

-   ret = exynos_drm_probe_vidi();
-   if (ret < 0)
-   goto err_unregister_pd;
-
ret = platform_driver_register(_drm_platform_driver);
if (ret)
-   goto err_remove_vidi;
+   goto err_unregister_pd;

return 0;

-err_remove_vidi:
-   exynos_drm_remove_vidi();
-
 err_unregister_pd:
platform_device_unregister(exynos_drm_pdev);

@@ -630,9 +623,6 @@ err_unregister_pd:
 static void exynos_drm_exit(void)
 {
platform_driver_unregister(_drm_platform_driver);
-
-   exynos_drm_remove_vidi();
-
platform_device_unregister(exynos_drm_pdev);
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 5b3305c..7c2ba06 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -310,14 +310,6 @@ exynos_dpi_probe(struct device *dev) { return NULL; }
 static inline int exynos_dpi_remove(struct device *dev) { return 0; }
 #endif

-#ifdef CONFIG_DRM_EXYNOS_VIDI
-int exynos_drm_probe_vidi(void);
-void exynos_drm_remove_vidi(void);
-#else
-static inline int exynos_drm_probe_vidi(void) { return 0; }
-static inline void exynos_drm_remove_vidi(void) {}
-#endif
-
 /* This function creates a encoder and a connector, and initializes them. */
 int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display);
@@ -333,5 +325,4 @@ extern int exynos_drm_non_kms_register(unsigned int 
device_type);
 extern void exynos_drm_non_kms_unregister(unsigned int device_type);

 extern struct platform_driver exynos_drm_common_hdmi_driver;
-extern struct platform_driver vidi_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 50faf91..e1153aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -14,6 +14,7 @@

 #include 
 #include 
+#include 

 #include 

@@ -48,10 +49,10 @@ struct vidi_win_data {

 struct vidi_context {
struct drm_device   *drm_dev;
+   struct platform_device  *pdev;
struct drm_crtc *crtc;
struct drm_encoder  *encoder;
struct drm_connectorconnector;
-   struct exynos_drm_subdrvsubdrv;
struct vidi_win_datawin_data[WINDOWS_NR];
struct edid *raw_edid;
unsigned intclkdiv;
@@ -561,14 +562,13 @@ static struct exynos_drm_display vidi_display = {
.ops = _display_ops,
 };

-static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
+static int vidi_bind(struct device *dev, struct device *master, void *data)
 {
-   struct exynos_drm_manager *mgr = get_vidi_mgr(dev);
-   struct vidi_context *ctx = mgr->ctx;
-   struct drm_crtc *crtc = ctx->crtc;
+   struct drm_crtc *crtc = vidi_manager.crtc;
+   struct drm_device *drm_dev = data;
int ret;

-   vidi_mgr_initialize(mgr, drm_dev);
+   vidi_mgr_initialize(_manager, drm_dev);

ret = exynos_drm_crtc_create(_manager);
if (ret) {
@@ -586,20 +586,42 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
return 0;
 }

+static void vidi_unbind(struct device *dev, struct device *master,
+   void *data)
+{
+}
+
+static const struct component_ops vidi_component_ops = {
+   .bind   = vidi_bind,
+   .unbind = vidi_unbind,
+};
+
 static int vidi_probe(struct platform_device *pdev)
 {
-   struct exynos_drm_subdrv *subdrv;
struct vidi_context *ctx;
int ret;

+   ret = exynos_drm_component_add(>dev, EXYNOS_DEVICE_TYPE_CRTC,
+   vidi_manager.type);
+   if (ret)
+   return ret;
+
+   ret = exynos_drm_component_add(>dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
+

[RFC PATCH v3 2/4] drm/exynos: make non kms drivers to be indenpendent drivers

[Inki Dae]

This patch makes non kms drivers to be independent drivers.
For this, it removes all register codes to non kms drivers
from exynos_drm_drv module and adds module_init/exit
for each non kms driver so that each non kms driver can be
called independently.

In addition, this patch adds non kms register/unregister functions
to exynos_drm_core module and also modifies existing codes relevant
to sub driver.

The idea is that non kms driver is registered by entry point,
module_init, of each non kms driver and sets its own sub driver
to registered non kms driver object when the sub driver is probed.
For this, this patch adds a new structure, exynos_drm_non_kms_dev,
to exynos_drm_core module.

Changelog v3:
- fix the use of mutex lock.
- fix g2d device node check.
- use module_platform_driver macro instead of module_init/exit.

Changelog v2:
- check if available g2d device node.
- return 0 instead of -EPROBE_DEFER in case of no non kms device
  registered. This case is not error.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_core.c|  164 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   50 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   28 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|1 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |   48 
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |1 +
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   39 ++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 +
 8 files changed, 243 insertions(+), 90 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 4c9f972..6c38308 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -19,6 +19,13 @@
 #include "exynos_drm_fbdev.h"

 static LIST_HEAD(exynos_drm_subdrv_list);
+DEFINE_MUTEX(list_lock);
+
+struct exynos_drm_non_kms_dev {
+   struct list_head list;
+   struct exynos_drm_subdrv *subdrv;
+   unsigned int device_type;
+};

 int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display)
@@ -55,12 +62,66 @@ err_destroy_encoder:
return ret;
 }

+int exynos_drm_non_kms_register(unsigned int device_type)
+{
+   struct exynos_drm_non_kms_dev *dev;
+
+   dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+   if (!dev)
+   return -ENOMEM;
+
+   dev->device_type = device_type;
+
+   mutex_lock(_lock);
+   list_add_tail(>list, _drm_subdrv_list);
+   mutex_unlock(_lock);
+
+   return 0;
+}
+
+void exynos_drm_non_kms_unregister(unsigned int device_type)
+{
+   struct exynos_drm_non_kms_dev *dev, *next;
+
+   mutex_lock(_lock);
+   list_for_each_entry_safe(dev, next, _drm_subdrv_list, list) {
+   mutex_unlock(_lock);
+   if (dev->device_type == device_type) {
+   list_del_init(>list);
+   kfree(dev);
+   mutex_lock(_lock);
+   break;
+   }
+   mutex_lock(_lock);
+   }
+   mutex_unlock(_lock);
+}
+
 int exynos_drm_subdrv_register(struct exynos_drm_subdrv *subdrv)
 {
+   struct exynos_drm_non_kms_dev *dev;
+
if (!subdrv)
return -EINVAL;

-   list_add_tail(>list, _drm_subdrv_list);
+   mutex_lock(_lock);
+   if (list_empty(_drm_subdrv_list)) {
+   mutex_unlock(_lock);
+   return -ENODEV;
+   }
+   mutex_unlock(_lock);
+
+   mutex_lock(_lock);
+   list_for_each_entry(dev, _drm_subdrv_list, list) {
+   mutex_unlock(_lock);
+   if (dev->device_type == subdrv->device_type) {
+   dev->subdrv = subdrv;
+   mutex_lock(_lock);
+   break;
+   }
+   mutex_lock(_lock);
+   }
+   mutex_unlock(_lock);

return 0;
 }
@@ -68,94 +129,149 @@ EXPORT_SYMBOL_GPL(exynos_drm_subdrv_register);

 int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv)
 {
+   struct exynos_drm_non_kms_dev *dev;
+
if (!subdrv)
return -EINVAL;

-   list_del(>list);
+   mutex_lock(_lock);
+   list_for_each_entry(dev, _drm_subdrv_list, list) {
+   mutex_unlock(_lock);
+   if (dev->device_type == subdrv->device_type) {
+   dev->subdrv = NULL;
+   break;
+   }
+   mutex_lock(_lock);
+   }
+   mutex_unlock(_lock);

return 0;
 }
 EXPORT_SYMBOL_GPL(exynos_drm_subdrv_unregister);

-int exynos_drm_device_subdrv_probe(struct drm_device *dev)
+int exynos_drm_device_subdrv_probe(struct drm_device *drm_dev)
 {
-   struct exynos_drm_subdrv *subdrv, *n;
+   struct exynos_drm_non_kms_dev *dev, *n;
int err;

-   if (!dev)
+   if (!drm_dev)
return -EINVAL;

[RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

[Inki Dae]

This patch makes kms drivers to be independent drivers.
For this, it removes all register codes to kms drivers
from exynos_drm_drv module and adds module_init/exit
for each kms driver so that each kms driver can be
called independently.

Changelog v3:
- Use module_platform_driver macro instead module_init/exit.
- Configure all kms drivers to be built in kernel image.

Changelog v2:
- none

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c  |2 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 +++---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |2 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
 drivers/gpu/drm/exynos/exynos_mixer.c|2 ++
 7 files changed, 13 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index ed818b9..30ebf5d 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = {
},
 };

+module_platform_driver(dp_driver);
+
 MODULE_AUTHOR("Jingoo Han ");
 MODULE_DESCRIPTION("Samsung SoC DP Driver");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index eab12f0..02d4772 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -484,12 +484,6 @@ static struct component_match *exynos_drm_match_add(struct 
device *dev)

mutex_lock(_component_lock);

-   /* Do not retry to probe if there is no any kms driver regitered. */
-   if (list_empty(_component_list)) {
-   mutex_unlock(_component_lock);
-   return ERR_PTR(-ENODEV);
-   }
-
list_for_each_entry(cdev, _component_list, list) {
/*
 * Add components to master only in case that crtc and
@@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops = {
.unbind = exynos_drm_unbind,
 };

-static struct platform_driver *const exynos_drm_kms_drivers[] = {
-#ifdef CONFIG_DRM_EXYNOS_FIMD
-   _driver,
-#endif
-#ifdef CONFIG_DRM_EXYNOS_DP
-   _driver,
-#endif
-#ifdef CONFIG_DRM_EXYNOS_DSI
-   _driver,
-#endif
-#ifdef CONFIG_DRM_EXYNOS_HDMI
-   _driver,
-   _driver,
-#endif
-};
-
 static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
 #ifdef CONFIG_DRM_EXYNOS_G2D
_driver,
@@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct 
platform_device *pdev)
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);

-   for (i = 0; i < ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
-   ret = platform_driver_register(exynos_drm_kms_drivers[i]);
-   if (ret < 0)
-   goto err_unregister_kms_drivers;
-   }
-
match = exynos_drm_match_add(>dev);
-   if (IS_ERR(match)) {
-   ret = PTR_ERR(match);
-   goto err_unregister_kms_drivers;
-   }
+   if (IS_ERR(match))
+   return PTR_ERR(match);

ret = component_master_add_with_match(>dev, _drm_ops,
match);
if (ret < 0)
-   goto err_unregister_kms_drivers;
+   return ret;

for (j = 0; j < ARRAY_SIZE(exynos_drm_non_kms_drivers); ++j) {
ret = platform_driver_register(exynos_drm_non_kms_drivers[j]);
@@ -632,10 +602,6 @@ err_unregister_non_kms_drivers:
 err_del_component_master:
component_master_del(>dev, _drm_ops);

-err_unregister_kms_drivers:
-   while (--i >= 0)
-   platform_driver_unregister(exynos_drm_kms_drivers[i]);
-
return ret;
 }

@@ -654,9 +620,6 @@ static int exynos_drm_platform_remove(struct 
platform_device *pdev)

component_master_del(>dev, _drm_ops);

-   for (i = ARRAY_SIZE(exynos_drm_kms_drivers) - 1; i >= 0; --i)
-   platform_driver_unregister(exynos_drm_kms_drivers[i]);
-
return 0;
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 262a459..352a9f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -331,11 +331,6 @@ int exynos_drm_component_add(struct device *dev,
 void exynos_drm_component_del(struct device *dev,
enum exynos_drm_device_type dev_type);

-extern struct platform_driver fimd_driver;
-extern struct platform_driver dp_driver;
-extern struct platform_driver dsi_driver;
-extern struct platform_driver mixer_driver;
-extern struct platform_driver hdmi_driver;
 extern struct platform_driver exynos_drm_common_hdmi_driver;
 extern struct platform_driver vidi_driver;
 extern struct platform_driver g2d_driver;

[RFC PATCH v3 0/4] separeate sub drivers into independent drivers

[Inki Dae]

Hi all,

   This patch set separeates sub drivers into independent drivers.

   patch 1/4:
   - make all kms drivers - fimd, hdmi, dp and dsi - to be independent
 drivers.

   patch 2/4:
   - make all non kms drivers - g2d and ipp - to be independent drivers.

   patch 3/4:
   - make vidi driver to be independent driver.

   patch 4/4:
   - just clean up codes for checking if it's Exynos SoC.

   This patch series had been posted like below with different subject,
   v1: http://www.spinics.net/lists/linux-samsung-soc/msg39116.html
   v2: http://www.spinics.net/lists/linux-samsung-soc/msg39145.html,
   and only one modified patch was posted.

   DRM driver should be single driver so it's not reasonable for sub
   drivers to be built as independent modules. So I changed previous
   subjects to new ones by reverting existing Kconfig.
   With this change, all sub drivers will be built-in kernel image.

   Thanks,
   Inki Dae

Inki Dae (4):
  drm/exynos: make kms drivers to be independent drivers
  drm/exynos: make non kms drivers to be indenpendent drivers
  drm/exynos: make vidi driver to be independent driver
  drm/exynos: clean up machine compatible string check

 drivers/gpu/drm/exynos/exynos_dp_core.c |2 +
 drivers/gpu/drm/exynos/exynos_drm_core.c|  164 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.c |  125 
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   42 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|2 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |   48 
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |1 +
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   39 ++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|   81 -
 drivers/gpu/drm/exynos/exynos_hdmi.c|2 +
 drivers/gpu/drm/exynos/exynos_mixer.c   |2 +
 14 files changed, 326 insertions(+), 187 deletions(-)

-- 
1.7.9.5

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Javier Martinez Canillas]

Hello,

For completeness I'll comment what we talked with Kevin on IRC
since probably this is the same issue that Paolo is facing.

On 11/20/2014 05:41 PM, Kevin Hilman wrote:
> Peach # setenv preboot "usb start; sleep 1"setenv bootargs console=tty1 
> console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait 
> rootfstype=ext3

My kernel command line is almost the same with the difference that I'm using
clk_ignore_unused and I just checked that not passing that parameter, makes
linux-next to hang showing the same output log that Kevin reported.

Now, the question is why this does not happen with 3.18-rc+? My guess is that
the clock been disabled by the common clock framework got added recently and
it used to be unmanaged and left with the state set by the bootloader since
the kernel didn't know about it. That's why clk_ignore_unused was not needed.

Any ideas?

Best regards,
Javier

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Javier Martinez Canillas]

Hello Paolo,

On 11/20/2014 04:57 PM, Paolo Pisati wrote:
> On Thu, Nov 20, 2014 at 03:22:23PM +0530, Vivek Gautam wrote:
>>
>> On linux-samsung tree the only patch that's missing apart from dptx-phy 
>> patches
>> is the syscon patch from Pankaj Dubey:
>> b784b98 mfd: syscon: Decouple syscon interface from platform devices
>> 
>> So with below git hash, linux-samsung/for-next display works fine along with
>> other devices that request PMU system controller :
>> 
>> 7bd219e drm/exynos: dp: Remove support for unused dptx-phy
>> e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>> 7099bde Revert "Revert "ARM: exynos_defconfig: Enable options for
>> display panel support""
>> 713a994 mfd: syscon: Decouple syscon interface from platform devices
>> 7552917 Revert "ARM: exynos_defconfig: Enable options for display
>> panel support" /* This is Kukjin's for-next today */
>> ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next
>> 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next
>> cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next
>> 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
>> 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device
>> 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow
>> fc14f9c Linux 3.18-rc5
> 
> are you using a clean exynos_defconfig?
> don't you need Javier's "drm/exynos: Move platform drivers registration to
> module init" patch too?
> 

Since Kukjin's for-next is based on Linux 3.18-rc5, the OF patch that causes
the Exynos DRM deadlock is not there. That commit landed in next20141105.

> kgene/for-next at:
> 
> 7552917 Revert "ARM: exynos_defconfig: Enable options for display panel 
> support"
> 
> plus:
> 
> 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> 36d908e drm/exynos: dp: Remove support for unused dptx-phy
> 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices
> 68944e3 Revert "Revert "ARM: exynos_defconfig: Enable options for display 
> panel support""
> 
> hangs with a black screen (albeit backlight seems to be on) on boot.
> I'm betting on Javier's patch at this point (i even tried disabling 
> SND_SOC_SNOW
> but that didn't help).
> 

I only tested with next20141120 but Vivek tested with Kukjin for-next AFAIU.

What's your kernel command line and u-boot env vars?

Best regards,
Javier

[Bug 88501] AMD/ATI RS690M Console blanks to white

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #8 from business.kid at gmail.com ---
Yes. I tested in order
1. 3.18.0-rc4 with no patch - white 2nd time.
2. 3.18.0-rc4 with the boot option - dark every time
3. 3.18.0-rc4 with your patch applied and no boot option - white 2nd time 
4. 3.18.0-rc4 with a syntax error :-/ module did not load.
5. 3.18.0-rc4 with the attached suggested fix, and no boot option. - dark every
time.

I have built ~ 20 kernels in the last few days, and am not keeping any of them.
The only reason I edited the patch was that I felt it unsafe to put an 'if'
below an 'else' in the same chain bracket. I have met some compilers that don't
respond to that as one would expect. I don't know what gcc does, and can't
swear that the logic follows correctly. I just tried it.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] drm/atomic: shutdown *current* encoder

[Rob Clark]

In disable_outputs() we need to shut down the outgoing encoder, not the
incoming one (we have already swapped-state at this point).  Without
this, we end up telling the driver to crtc->dpms(OFF) without first
encoder->dpms(OFF), and that makes some hw quite unhappy.

v2: missing WARN_ON() hunk and comment

Reviewed-by: Daniel Vetter 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_atomic_helper.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 5ae5b25..61bec0b 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -502,9 +502,12 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
if (!old_conn_state || !old_conn_state->crtc)
continue;

-   encoder = connector->state->best_encoder;
+   encoder = old_conn_state->best_encoder;

-   if (!encoder)
+   /* We shouldn't get this far if we didn't previously have
+* an encoder.. but WARN_ON() rather than explode.
+*/
+   if (WARN_ON(!encoder))
continue;

funcs = encoder->helper_private;
-- 
1.9.3

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Paolo Pisati]

On Thu, Nov 20, 2014 at 03:22:23PM +0530, Vivek Gautam wrote:
>
> On linux-samsung tree the only patch that's missing apart from dptx-phy 
> patches
> is the syscon patch from Pankaj Dubey:
> b784b98 mfd: syscon: Decouple syscon interface from platform devices
> 
> So with below git hash, linux-samsung/for-next display works fine along with
> other devices that request PMU system controller :
> 
> 7bd219e drm/exynos: dp: Remove support for unused dptx-phy
> e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> 7099bde Revert "Revert "ARM: exynos_defconfig: Enable options for
> display panel support""
> 713a994 mfd: syscon: Decouple syscon interface from platform devices
> 7552917 Revert "ARM: exynos_defconfig: Enable options for display
> panel support" /* This is Kukjin's for-next today */
> ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next
> 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next
> cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next
> 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
> 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device
> 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow
> fc14f9c Linux 3.18-rc5

are you using a clean exynos_defconfig?
don't you need Javier's "drm/exynos: Move platform drivers registration to
module init" patch too?

kgene/for-next at:

7552917 Revert "ARM: exynos_defconfig: Enable options for display panel support"

plus:

5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
36d908e drm/exynos: dp: Remove support for unused dptx-phy
624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices
68944e3 Revert "Revert "ARM: exynos_defconfig: Enable options for display panel 
support""

hangs with a black screen (albeit backlight seems to be on) on boot.
I'm betting on Javier's patch at this point (i even tried disabling SND_SOC_SNOW
but that didn't help).
-- 
bye,
p.

[PATCH 2/2] drm/atomic: shutdown *current* encoder

[Rob Clark]

On Thu, Nov 20, 2014 at 3:55 PM, Rob Clark  wrote:
> In disable_outputs() we need to shut down the outgoing encoder, not the
> incoming one (we have already swapped-state at this point).  Without
> this, we end up telling the driver to crtc->dpms(OFF) without first
> encoder->dpms(OFF), and that makes some hw quite unhappy.
>

bleh, missed a hunk that added a WARN_ON()..  will resend this

> Reviewed-by: Daniel Vetter 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5ae5b25..8e4f3fc 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -502,7 +502,7 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
> if (!old_conn_state || !old_conn_state->crtc)
> continue;
>
> -   encoder = connector->state->best_encoder;
> +   encoder = old_conn_state->best_encoder;
>
> if (!encoder)
> continue;
> --
> 1.9.3
>

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Javier Martinez Canillas]

Hello Inki,

On 11/20/2014 04:06 PM, Inki Dae wrote:
>> BTW, it would be great if exynos-drm-next is pulled in linux-next. That is
>> what most people use to test integration issues so you can catch earlier any
>> regression that may arise.
>> 
>> You have to email Stephen Rothwell  and point to 
>> your
>> tree and branch and he will be able to add it to linux-next.
> 
> Thanks for information. Actually, I received a similar email privately
> before. However, exynos-drm-next should go to drm-next first and than to
> mainline by Dave who is DRM subsystem maintainer. I think all vendor
> specific drm drivers would need to be checked by drm subsystem
> maintainer because these changes might be affect drm subsystem or other
> vendor specific drm drivers before go to mainline.
>

This is orthogonal to the normal upstreaming path. linux-next is an integration
tree that is created daily. So all the remote branches are merged and a git tag
published. The branch does not get rebased and history is not preserved between
two published linux-next tags.

This is just to test the integration of different subsystems to be sure that a
commit in one tree does not cause a regression in another one so issues can be
spot earlier. For example in the case of $subject, a change in the OF caused a
regression in the Exynos DRM driver.

> If needed, I will make a new branch, which is based on top of linux-next
> so other people can check their systems.
>

You don't really need another branch, git will take care of merge everything
in linux-next :)

> Thanks,
> Inki Dae
> 

Best regards,
Javier

[PATCH] drm/vgem: implement virtual GEM

[Zach Reizner]

This patch implements the virtual GEM driver with PRIME sharing which
allows vgem to import a gem object from other drivers for the purpose
of mmap-ing them to userspace.

Reviewed-by: Stéphane Marchesin 
Signed-off-by: Adam Jackson 
Signed-off-by: Ben Widawsky 
Signed-off-by: Zach Reizner 
---
 drivers/gpu/drm/Kconfig |   9 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/vgem/Makefile   |   4 +
 drivers/gpu/drm/vgem/vgem_dma_buf.c | 169 +++
 drivers/gpu/drm/vgem/vgem_drv.c | 407 
 drivers/gpu/drm/vgem/vgem_drv.h |  62 ++
 6 files changed, 652 insertions(+)
 create mode 100644 drivers/gpu/drm/vgem/Makefile
 create mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c
 create mode 100644 drivers/gpu/drm/vgem/vgem_drv.c
 create mode 100644 drivers/gpu/drm/vgem/vgem_drv.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index e3b4b0f..39909bc 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -165,6 +165,15 @@ config DRM_SAVAGE
  Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister
  chipset. If M is selected the module will be called savage.

+config DRM_VGEM
+   tristate "Virtual GEM provider"
+   depends on DRM
+   help
+ Choose this option to get a virtual graphics memory manager,
+ as used by Mesa's software renderer for enhanced performance.
+ If M is selected the module will be called vgem.
+
+
 source "drivers/gpu/drm/exynos/Kconfig"

 source "drivers/gpu/drm/vmwgfx/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index c3cf64c..c1e4a0e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_DRM_SIS)   += sis/
 obj-$(CONFIG_DRM_SAVAGE)+= savage/
 obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
 obj-$(CONFIG_DRM_VIA)  +=via/
+obj-$(CONFIG_DRM_VGEM) += vgem/
 obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
 obj-$(CONFIG_DRM_EXYNOS) +=exynos/
 obj-$(CONFIG_DRM_GMA500) += gma500/
diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
new file mode 100644
index 000..1055cb7
--- /dev/null
+++ b/drivers/gpu/drm/vgem/Makefile
@@ -0,0 +1,4 @@
+ccflags-y := -Iinclude/drm
+vgem-y := vgem_drv.o vgem_dma_buf.o
+
+obj-$(CONFIG_DRM_VGEM) += vgem.o
diff --git a/drivers/gpu/drm/vgem/vgem_dma_buf.c 
b/drivers/gpu/drm/vgem/vgem_dma_buf.c
new file mode 100644
index 000..8450124
--- /dev/null
+++ b/drivers/gpu/drm/vgem/vgem_dma_buf.c
@@ -0,0 +1,169 @@
+/*
+ * Copyright © 2012 Intel Corporation
+ * Copyright © 2014 The Chromium OS Authors
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Ben Widawsky 
+ *
+ */
+
+#include 
+#include "vgem_drv.h"
+
+#define VGEM_FD_PERMS 0600
+
+static struct sg_table *vgem_gem_map_dma_buf(struct dma_buf_attachment *attach,
+enum dma_data_direction dir)
+{
+   struct drm_vgem_gem_object *obj = attach->dmabuf->priv;
+   struct sg_table *sg;
+   int ret;
+
+   ret = vgem_gem_get_pages(obj);
+   if (ret)
+   return ERR_PTR(ret);
+
+   /* VGEM assumes cache coherent access. Normally we might have to flush
+* caches here */
+
+   BUG_ON(obj->pages == NULL);
+
+   sg = drm_prime_pages_to_sg(obj->pages, obj->base.size / PAGE_SIZE);
+   if (!sg) {
+   vgem_gem_put_pages(obj);
+   return NULL;
+   }
+
+   return sg;
+}
+
+static void vgem_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
+   struct sg_table *sg,
+   enum dma_data_direction data_direction)
+{
+   sg_free_table(sg);
+   kfree(sg);
+}
+
+static void *vgem_kmap_atomic_dma_buf(struct dma_buf *dma_buf,
+ unsigned long page_num)
+{
+   return NULL;
+}
+
+static void 

[Bug 86490] Some Unreal Engine 4.5 Demos render only black on radeonsi

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Andy Furniss  ---
If your llvm is new enough could be -

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/91225cb7/attachment.html>

[PATCH 2/2] drm/atomic: shutdown *current* encoder

[Rob Clark]

In disable_outputs() we need to shut down the outgoing encoder, not the
incoming one (we have already swapped-state at this point).  Without
this, we end up telling the driver to crtc->dpms(OFF) without first
encoder->dpms(OFF), and that makes some hw quite unhappy.

Reviewed-by: Daniel Vetter 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_atomic_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 5ae5b25..8e4f3fc 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -502,7 +502,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
if (!old_conn_state || !old_conn_state->crtc)
continue;

-   encoder = connector->state->best_encoder;
+   encoder = old_conn_state->best_encoder;

if (!encoder)
continue;
-- 
1.9.3

[PATCH 1/2] drm/atomic: check mode_changed *after* atomic_check

[Rob Clark]

The intention is that drivers can set crtc_state->mode_changed in their
atomic_check() fxns if they encounter a scenario that requires full
modeset.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_atomic_helper.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index fad2b93..5ae5b25 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -332,7 +332,7 @@ mode_fixup(struct drm_atomic_state *state)
 }

 static int
-drm_atomic_helper_check_prepare(struct drm_device *dev,
+drm_atomic_helper_check_modeset(struct drm_device *dev,
struct drm_atomic_state *state)
 {
int ncrtcs = dev->mode_config.num_crtc;
@@ -430,10 +430,6 @@ int drm_atomic_helper_check(struct drm_device *dev,
int ncrtcs = dev->mode_config.num_crtc;
int i, ret = 0;

-   ret = drm_atomic_helper_check_prepare(dev, state);
-   if (ret)
-   return ret;
-
for (i = 0; i < nplanes; i++) {
struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = state->planes[i];
@@ -477,6 +473,10 @@ int drm_atomic_helper_check(struct drm_device *dev,
}
}

+   ret = drm_atomic_helper_check_modeset(dev, state);
+   if (ret)
+   return ret;
+
return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_check);
-- 
1.9.3

[Bug 88501] AMD/ATI RS690M Console blanks to white

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #7 from Alex Deucher  ---
The code should be fine as is.  Are you sure you tested the right kernel?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 88501] AMD/ATI RS690M Console blanks to white

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #6 from business.kid at gmail.com ---
Created attachment 158261
  --> https://bugzilla.kernel.org/attachment.cgi?id=158261=edit
Your patch slightly adjusted

This seems to work. I know little of C, and less of graphics programming, but I
got suspicious of the second 'if' construct inside a chain bracket, so I
tweaked syntax. I built it here and tried it.

I now am sorted out, thank you. If you want something else tried, let me know.
Otherwise, I assure you, I will *not* be building another kernel on that box
for quite some time!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Javier Martinez Canillas]

Hello Inki,

On 11/20/2014 03:07 PM, Inki Dae wrote:
> Could you re-base this patch on top of exynos-drm-next? I tried to
> separate sub drivers into independent drivers but it seems that we need
> more times. So I will merge your patch.
> 

Sure, I'll rebase on top of exynos-drm-next and re-post so you can apply it.

BTW, it would be great if exynos-drm-next is pulled in linux-next. That is
what most people use to test integration issues so you can catch earlier any
regression that may arise.

You have to email Stephen Rothwell  and point to your
tree and branch and he will be able to add it to linux-next.

> Thanks,
> Inki Dae
> 

Best regards,
Javier

[RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

[Andrzej Hajda]

On 11/20/2014 02:56 PM, Inki Dae wrote:
> On 2014년 11월 20일 22:19, Andrzej Hajda wrote:
>> On 11/20/2014 11:24 AM, Inki Dae wrote:
>>> This patch makes kms drivers to be independent drivers.
>>> For this, it removes all register codes to kms drivers
>>> from exynos_drm_drv module and adds module_init/exit
>>> for each kms driver so that each kms driver can be
>>> called independently.
>>>
>>> Changelog v3:
>>> - Use module_platform_driver macro instead module_init/exit.
>>> - Configure all kms drivers to be built in kernel image.
>>>
>>> Changelog v2:
>>> - none
>>>
>>> Signed-off-by: Inki Dae 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_dp_core.c  |2 ++
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 
>>> +++---
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
>>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |2 ++
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++
>>>  drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
>>>  drivers/gpu/drm/exynos/exynos_mixer.c|2 ++
>>>  7 files changed, 13 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> index ed818b9..30ebf5d 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = {
>>> },
>>>  };
>>>  
>>> +module_platform_driver(dp_driver);
>>
>> If you try to build exynosdrm as module you will receive errors due to
>> multiple definitions of init_module, ie module_init/module_*_driver
>> macros can be used once per module.
> 
> Ah, right. we had ever tried same way before but failed in same problem.
> I didn't realize that. Anyway, I will try to find out a better way. I'd
> really like to remove all register codes of sub drivers from
> exynos_drm_drv somehow.

I have proposed once solution with sparse arrays, using linker scripts
[1]. Something similar is used with clock controllers as I remember.
I do not see other possibilities to fully separate components of
exynos_drm_drv.

[1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/103816

Regards
Andrzej

> 
>>
>> Anyway I am afraid exynosdrm seems to be still fragile to order of
>> successful probes of their components.
>> It can be easily observed on the system with two display pipelines with
>> one of them probe deferring. For example universal with fimd/dpi + vidi:
>> 1. fimd defers probe because panel is not yet probed.
>> 2. vidi probes ok.
>> 3. drmdev is initialized.
>> 4. fimd probes ok, but it is too late!!!
>>
>> So you can reproduce the scenario on any target when one of the
>> components defers and vidi is present (vidi never defers I suppose).
> 
> Thanks for checking,
> Inki Dae
> 
>>
>> Regards
>> Andrzej
>>
>>> +
>>>  MODULE_AUTHOR("Jingoo Han ");
>>>  MODULE_DESCRIPTION("Samsung SoC DP Driver");
>>>  MODULE_LICENSE("GPL v2");
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> index eab12f0..02d4772 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> @@ -484,12 +484,6 @@ static struct component_match 
>>> *exynos_drm_match_add(struct device *dev)
>>>  
>>> mutex_lock(_component_lock);
>>>  
>>> -   /* Do not retry to probe if there is no any kms driver regitered. */
>>> -   if (list_empty(_component_list)) {
>>> -   mutex_unlock(_component_lock);
>>> -   return ERR_PTR(-ENODEV);
>>> -   }
>>> -
>>> list_for_each_entry(cdev, _component_list, list) {
>>> /*
>>>  * Add components to master only in case that crtc and
>>> @@ -545,22 +539,6 @@ static const struct component_master_ops 
>>> exynos_drm_ops = {
>>> .unbind = exynos_drm_unbind,
>>>  };
>>>  
>>> -static struct platform_driver *const exynos_drm_kms_drivers[] = {
>>> -#ifdef CONFIG_DRM_EXYNOS_FIMD
>>> -   _driver,
>>> -#endif
>>> -#ifdef CONFIG_DRM_EXYNOS_DP
>>> -   _driver,
>>> -#endif
>>> -#ifdef CONFIG_DRM_EXYNOS_DSI
>>> -   _driver,
>>> -#endif
>>> -#ifdef CONFIG_DRM_EXYNOS_HDMI
>>> -   _driver,
>>> -   _driver,
>>> -#endif
>>> -};
>>> -
>>>  static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
>>>  #ifdef CONFIG_DRM_EXYNOS_G2D
>>> _driver,
>>> @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct 
>>> platform_device *pdev)
>>> pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>> exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>>>  
>>> -   for (i = 0; i < ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
>>> -   ret = platform_driver_register(exynos_drm_kms_drivers[i]);
>>> -   if (ret < 0)
>>> -   goto err_unregister_kms_drivers;
>>> -   }
>>> -
>>> match = exynos_drm_match_add(>dev);
>>> -   if (IS_ERR(match)) {
>>> -   ret = PTR_ERR(match);
>>> -   goto err_unregister_kms_drivers;
>>> -   }
>>> +   if 

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Vivek Gautam]

Hi Javier,


On Thu, Nov 20, 2014 at 2:15 PM, Javier Martinez Canillas
 wrote:
> Hello Vivek,
>
> On 11/20/2014 08:51 AM, Vivek Gautam wrote:
>>>
>>> I tested linux-next on Exynos5800 peach-pi board with linux-next and and 
>>> the two
>>> patches $Subject and [0].
>>>
>>> Below is my git hash:
>>> 4d9e6ee drm/exynos: Move platform drivers registration to module init
>>> 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
>>> phy
>>> 36391a5 Add linux-next specific files for 20141119
>>> 9b1ced1 Merge branch 'akpm/master'
>>> 282497e mm: add strictlimit knob
>>
>> used exynos_defconfig
>>
>
> Same here.
>
>>>
>>> With this display works for me.
>>> Without $Subject patch i get lookup in drm.
>>>
>
> I tested with today linux-next (next-20141120) and display is indeed
> working for me. So it seems that whatever caused the error in the
> phy-exynos-mipi-video driver reported by Paolo, got fixed recently.
>
> My working git hash is:
>
> 65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> a9b43cb drm/exynos: Move platform drivers registration to module init
> 5b83d7a Add linux-next specific files for 20141120
> 1172916 mm: add strictlimit knob
>
> I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel
> did not boot due the issue reported previously by Kevin.
>
>>> Javier can you tell me your git hash. Was it on yesterday's linux-next ?
>>
>
> In fact, my branch where I could reproduce the phy-exynos-mipi-video issue
> was not based on yesterday's next but next-20141117. The git hash is:
>
> 9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> f740096 drm/exynos: Move platform drivers registration to module init
> efefb5c Add linux-next specific files for 20141117
> 8c944d7 mm: add strictlimit knob
>
>> With 3.18-rc5 i could see display on Exynos5800 peach-pi with
>> following git hash:
>>
>> b6dca11 drm/exynos: dp: Remove support for unused dptx-phy
>> 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support
>> d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>> fc14f9c Linux 3.18-rc5
>> e35c5a2 Merge tag 'armsoc-for-rc5' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
>>
>> I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig).
>>
>
> Yes, that works because the commit that caused the Exynos DRM lockup was:
>
> 43c0767 ("of/platform: Move platform devices under /sys/devices/platform")
>
> which landed in next-20141105.
>
> Reverting 43c0767 and only applying [0] should have the same effect.
>
>> I am checking further with linux-samsung, coz i could see weird
>> behavior as mentioned
>> in [1] with linux-samsun/for-next merged with above git hash.
>>
>
> Great, it should be good to know what caused:

On linux-samsung tree the only patch that's missing apart from dptx-phy patches
is the syscon patch from Pankaj Dubey:
b784b98 mfd: syscon: Decouple syscon interface from platform devices

So with below git hash, linux-samsung/for-next display works fine along with
other devices that request PMU system controller :

7bd219e drm/exynos: dp: Remove support for unused dptx-phy
e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
7099bde Revert "Revert "ARM: exynos_defconfig: Enable options for
display panel support""
713a994 mfd: syscon: Decouple syscon interface from platform devices
7552917 Revert "ARM: exynos_defconfig: Enable options for display
panel support" /* This is Kukjin's for-next today */
ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next
26c6283 Merge branch 'v3.18-samsung-fixes' into for-next
cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next
98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
839275c ARM: exynos_defconfig: Use 16 minors per MMC block device
0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow
fc14f9c Linux 3.18-rc5


>
> exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
> [mem 0x10040714-0x1004071f]

The only reason i see this fails is since PMU is now requesting the
entire memory
region with base 0x1004. We should convert the mipi-phy pmu
register handling
too through syscon.

>
> even when I could not reproduce it anymore with today's linux-next.
>
>>>> [0]: https://lkml.org/lkml/2014/10/30/394
>>>> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html



-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India

[RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

[Javier Martinez Canillas]

Hello Inki,

On Thu, Nov 20, 2014 at 2:56 PM, Inki Dae  wrote:
>> If you try to build exynosdrm as module you will receive errors due to
>> multiple definitions of init_module, ie module_init/module_*_driver
>> macros can be used once per module.
>
> Ah, right. we had ever tried same way before but failed in same problem.
> I didn't realize that. Anyway, I will try to find out a better way. I'd
> really like to remove all register codes of sub drivers from
> exynos_drm_drv somehow.
>

Maybe as an immediate fix we can move the platform driver registration
out of probe as suggested by Andrzej?

I posted an RFC patch a couple of days ago [0] that fixes both the
deadlock and the infinite loop bug so it would be great if you can
review/test so I can post a proper patch.

And then we can look how to better refactor the exynos drm driver.

Best regards,
Javier

[0]: http://www.spinics.net/lists/linux-samsung-soc/msg39106.html

[RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

[Andrzej Hajda]

On 11/20/2014 11:24 AM, Inki Dae wrote:
> This patch makes kms drivers to be independent drivers.
> For this, it removes all register codes to kms drivers
> from exynos_drm_drv module and adds module_init/exit
> for each kms driver so that each kms driver can be
> called independently.
> 
> Changelog v3:
> - Use module_platform_driver macro instead module_init/exit.
> - Configure all kms drivers to be built in kernel image.
> 
> Changelog v2:
> - none
> 
> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c  |2 ++
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 
> +++---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |2 ++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++
>  drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
>  drivers/gpu/drm/exynos/exynos_mixer.c|2 ++
>  7 files changed, 13 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index ed818b9..30ebf5d 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = {
>   },
>  };
>  
> +module_platform_driver(dp_driver);

If you try to build exynosdrm as module you will receive errors due to
multiple definitions of init_module, ie module_init/module_*_driver
macros can be used once per module.

Anyway I am afraid exynosdrm seems to be still fragile to order of
successful probes of their components.
It can be easily observed on the system with two display pipelines with
one of them probe deferring. For example universal with fimd/dpi + vidi:
1. fimd defers probe because panel is not yet probed.
2. vidi probes ok.
3. drmdev is initialized.
4. fimd probes ok, but it is too late!!!

So you can reproduce the scenario on any target when one of the
components defers and vidi is present (vidi never defers I suppose).

Regards
Andrzej

> +
>  MODULE_AUTHOR("Jingoo Han ");
>  MODULE_DESCRIPTION("Samsung SoC DP Driver");
>  MODULE_LICENSE("GPL v2");
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index eab12f0..02d4772 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -484,12 +484,6 @@ static struct component_match 
> *exynos_drm_match_add(struct device *dev)
>  
>   mutex_lock(_component_lock);
>  
> - /* Do not retry to probe if there is no any kms driver regitered. */
> - if (list_empty(_component_list)) {
> - mutex_unlock(_component_lock);
> - return ERR_PTR(-ENODEV);
> - }
> -
>   list_for_each_entry(cdev, _component_list, list) {
>   /*
>* Add components to master only in case that crtc and
> @@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops 
> = {
>   .unbind = exynos_drm_unbind,
>  };
>  
> -static struct platform_driver *const exynos_drm_kms_drivers[] = {
> -#ifdef CONFIG_DRM_EXYNOS_FIMD
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_DP
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_DSI
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_HDMI
> - _driver,
> - _driver,
> -#endif
> -};
> -
>  static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
>  #ifdef CONFIG_DRM_EXYNOS_G2D
>   _driver,
> @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct 
> platform_device *pdev)
>   pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>   exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>  
> - for (i = 0; i < ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
> - ret = platform_driver_register(exynos_drm_kms_drivers[i]);
> - if (ret < 0)
> - goto err_unregister_kms_drivers;
> - }
> -
>   match = exynos_drm_match_add(>dev);
> - if (IS_ERR(match)) {
> - ret = PTR_ERR(match);
> - goto err_unregister_kms_drivers;
> - }
> + if (IS_ERR(match))
> + return PTR_ERR(match);
>  
>   ret = component_master_add_with_match(>dev, _drm_ops,
>   match);
>   if (ret < 0)
> - goto err_unregister_kms_drivers;
> + return ret;
>  
>   for (j = 0; j < ARRAY_SIZE(exynos_drm_non_kms_drivers); ++j) {
>   ret = platform_driver_register(exynos_drm_non_kms_drivers[j]);
> @@ -632,10 +602,6 @@ err_unregister_non_kms_drivers:
>  err_del_component_master:
>   component_master_del(>dev, _drm_ops);
>  
> -err_unregister_kms_drivers:
> - while (--i >= 0)
> - platform_driver_unregister(exynos_drm_kms_drivers[i]);
> -
>   return ret;
>  }
>  
> @@ -654,9 +620,6 @@ static int exynos_drm_platform_remove(struct 
> platform_device *pdev)
>  
>   component_master_del(>dev, _drm_ops);
>  
> -   

[PATCH] Fix SIGSEGV in libdrm for heigth = 0 and width = 0

[Damien Lespiau]

On Fri, Nov 07, 2014 at 07:43:04PM +0100, Thomas Meyer wrote:
> 
> drm_intel_gem_bo_free() crashes because the list bo_gem->vma_list is not
> yet initialised, but the error path tries to free it.
> 
> See also https://bugs.freedesktop.org/show_bug.cgi?id=75844
> 
> Reviewed-by: Chris Wilson 
> Signed-off-by: Thomas Meyer 

Thanks for the patch and review tag. Sorry it took so long to push, it
wasn't clear who was going to do it.

-- 
Damien

> ---
> 
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index f2f4fea..b3e9dba 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -759,15 +759,16 @@ retry:
>   bo_gem->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
>   bo_gem->stride = 0;
>  
> + /* drm_intel_gem_bo_free calls DRMLISTDEL() for an uninitialized
> +list (vma_list), so better set the list head here */
> + DRMINITLISTHEAD(_gem->name_list);
> + DRMINITLISTHEAD(_gem->vma_list);
>   if (drm_intel_gem_bo_set_tiling_internal(_gem->bo,
>tiling_mode,
>stride)) {
>   drm_intel_gem_bo_free(_gem->bo);
>   return NULL;
>   }
> -
> - DRMINITLISTHEAD(_gem->name_list);
> - DRMINITLISTHEAD(_gem->vma_list);
>   }
>  
>   bo_gem->name = name;
> 
> 
> 

[Bug 86490] Some Unreal Engine 4.5 Demos render only black on radeonsi

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 86490
   Summary: Some Unreal Engine 4.5 Demos render only black on
radeonsi
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: haagch at frickel.club

Hardware:
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Wimbledon XT [Radeon HD 7970M] (rev ff)

So I'm using radeonsi with PRIME and latest mesa git, recent llvm 3.6 revision.

I foolishly deleted the old Unreal Engine Demos so I can't make a recent test,
but they worked decently last time I checked.

Now the Unreal Demos have been updated to UE 4.5:
https://wiki.unrealengine.com/Linux_Demos

"Tappy Chicken": Works fine on intel and radeonsi.
"Shooter Game": Works fine on intel, but shows only game HUD and text on
radeonsi
"Light Room Interior Day Demo": Works fine on intel but is completely black on
radeonsi

Apitrace says the only problems are:

$ DRI_PRIME=1 glretrace Lightroominteriorday.trace
882: glDebugOutputCallback: Medium severity API other issue 1, FBO incomplete:
no attachments [-1]

0 4096 glXSwapIntervalMESA(interval = 0) = 0
4096: warning: unsupported glXSwapIntervalMESA call
context mis-match in pipe_sampler_view_release()
Rendered 191 frames in 13.88 secs, average of 13.7608 fps

Here is the trace from which I got the above output:
http://haagch.frickel.club/files/Lightroominteriorday.trace.xz
It renders fine on intel, but only black on radeonsi.

(Careful: When creating a trace on intel, the engine will use
glCopyImageSubData which is not supported on radeonsi. When creating a trace on
radeonsi it will not.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/ddb19643/attachment-0001.html>

[pull] radeon drm-next-3.19

[Alex Deucher]

Hi Dave,

More radeon patches for 3.19.  Highlights:
- More CI dpm fixes
- Initial DPM fan control for SI/CI (disabled by default)
- GPUVM multi-ring efficiency improvements
- Some cursor fixes

The following changes since commit cc5ac1ca79b4976ed3a779d7ea157f078207b56b:

  Merge branch 'amdkfd-v6' of git://people.freedesktop.org/~gabbayo/linux into 
drm-next (2014-11-20 14:32:32 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~agd5f/linux drm-next-3.19

for you to fetch changes up to 2f2624c23511b4bf0dd3d4c5ae167715513f351d:

  drm/radeon: update the VM after setting BO address v4 (2014-11-20 13:00:20 
-0500)


Alex Deucher (9):
  drm/radeon: work around a hw bug in MGCG on CIK
  drm/radeon/dpm: add smc fan control for SI (v2)
  drm/radeon/dpm: add smc fan control for CI (v2)
  drm/radeon/dpm: add thermal dpm support for CI
  drm/radeon: fix PCC debugging message for CI DPM
  drm/radeon/ci: apply disp voltage changes before clk changes
  drm/radeon/ci: use different smc command for pcie dpm
  drm/radeon/ci: force pcie level before sclk and mclk
  drm/radeon/ci: disable needless sclk changes

Christian König (11):
  drm/radeon: rework vm_flush parameters
  drm/radeon: stop re-reserving the BO in radeon_vm_bo_set_addr
  drm/radeon: remove unnecessary VM syncs
  drm/radeon: split semaphore and sync object handling v2
  drm/radeon: fence PT updates manually v2
  drm/radeon: track VM update fences separately
  drm/radeon: use one VMID for each ring
  drm/radeon: fence BO_VAs manually
  drm/radeon: sync PD updates as shared
  drm/radeon: sync PT updates as shared v2
  drm/radeon: update the VM after setting BO address v4

Michel Dänzer (2):
  drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
  drm/radeon: Move radeon_cursor_move(_locked) to replace forward 
declaration

 drivers/gpu/drm/radeon/Makefile   |   3 +-
 drivers/gpu/drm/radeon/ci_dpm.c   | 426 --
 drivers/gpu/drm/radeon/ci_dpm.h   |   6 +
 drivers/gpu/drm/radeon/cik.c  |  48 ++--
 drivers/gpu/drm/radeon/cik_sdma.c |  42 ++-
 drivers/gpu/drm/radeon/cikd.h |  40 ++-
 drivers/gpu/drm/radeon/evergreen_dma.c|  18 +-
 drivers/gpu/drm/radeon/ni.c   |  20 +-
 drivers/gpu/drm/radeon/ni_dma.c   |  17 +-
 drivers/gpu/drm/radeon/ppsmc.h|  14 +
 drivers/gpu/drm/radeon/pptable.h  |   8 +
 drivers/gpu/drm/radeon/r600.c |  18 +-
 drivers/gpu/drm/radeon/r600_dma.c |  18 +-
 drivers/gpu/drm/radeon/r600_dpm.c |   9 +
 drivers/gpu/drm/radeon/r600_dpm.h |   3 +
 drivers/gpu/drm/radeon/radeon.h   | 102 ---
 drivers/gpu/drm/radeon/radeon_asic.h  |  18 +-
 drivers/gpu/drm/radeon/radeon_cs.c|  12 +-
 drivers/gpu/drm/radeon/radeon_cursor.c| 229 +---
 drivers/gpu/drm/radeon/radeon_display.c   |   2 +-
 drivers/gpu/drm/radeon/radeon_fence.c |   1 +
 drivers/gpu/drm/radeon/radeon_gem.c   |  66 -
 drivers/gpu/drm/radeon/radeon_ib.c|  16 +-
 drivers/gpu/drm/radeon/radeon_kms.c   |   2 -
 drivers/gpu/drm/radeon/radeon_mode.h  |  16 +-
 drivers/gpu/drm/radeon/radeon_object.c|  19 ++
 drivers/gpu/drm/radeon/radeon_object.h|   2 +
 drivers/gpu/drm/radeon/radeon_semaphore.c | 154 +--
 drivers/gpu/drm/radeon/radeon_sync.c  | 220 +++
 drivers/gpu/drm/radeon/radeon_vm.c| 164 +++-
 drivers/gpu/drm/radeon/rv770_dma.c|  18 +-
 drivers/gpu/drm/radeon/si.c   |  24 +-
 drivers/gpu/drm/radeon/si_dma.c   |  37 ++-
 drivers/gpu/drm/radeon/si_dpm.c   | 330 ++-
 drivers/gpu/drm/radeon/si_dpm.h   |   5 +
 drivers/gpu/drm/radeon/sid.h  |  40 ++-
 drivers/gpu/drm/radeon/sislands_smc.h |  25 ++
 drivers/gpu/drm/radeon/smu7_discrete.h|  30 ++-
 38 files changed, 1646 insertions(+), 576 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_sync.c

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Vivek Gautam]

Hi,


On Thu, Nov 20, 2014 at 12:36 PM, Vivek Gautam
 wrote:
> Hi Javier, Kevin,
>
>
>
> On Wed, Nov 19, 2014 at 10:22 PM, Javier Martinez Canillas
>  wrote:
>> [adding Paolo and Vivek as cc]
>>
>> Hello,
>>
>> On 11/18/2014 07:41 PM, Kevin Hilman wrote:
>>>
>>> It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
>>> it proceeds to panic in the workqueue code called by the asoc max98090
>>> codec[1].
>>>
>>> If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
>>> but I still don't have display output.
>>>
>>
>> Paolo Pisati pointed out in another thread that he needed the patch
>> "[PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
>> phy"
>> is also needed to get display working for exynos on linux-next.
>>
>> I've pinged Kukjin to apply this as a -rc fix since is needed after
>> a5ec598 ("phy: exynos-dp-video: Use syscon support to control pmu register")
>> landed in 3.18 which broke the Exynos Display Port PHY:
>>
>> exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap
>>
>> I've an Exynos5800 Peach Pi now so I wanted to test display on it. Just 
>> $subject
>> and [0] should be enough to have display working on Peach Pi with linux-next 
>> but
>> it fails to me with:
>>
>> exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
>> [mem 0x10040714-0x1004071f]
>>
>> The same issue was reported by Paolo a couple of days ago [1].
>>
>> Vivek,
>>
>> Any idea what could cause this regression on linux-next? As reported by 
>> Paolo this
>> works well for me in 3.18-rc5.
>
> I tested linux-next on Exynos5800 peach-pi board with linux-next and and the 
> two
> patches $Subject and [0].
>
> Below is my git hash:
> 4d9e6ee drm/exynos: Move platform drivers registration to module init
> 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
> phy
> 36391a5 Add linux-next specific files for 20141119
> 9b1ced1 Merge branch 'akpm/master'
> 282497e mm: add strictlimit knob

used exynos_defconfig

>
> With this display works for me.
> Without $Subject patch i get lookup in drm.
>
> Javier can you tell me your git hash. Was it on yesterday's linux-next ?

With 3.18-rc5 i could see display on Exynos5800 peach-pi with
following git hash:

b6dca11 drm/exynos: dp: Remove support for unused dptx-phy
7cc5c2d ARM: exynos_defconfig: Enable options for display panel support
d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
fc14f9c Linux 3.18-rc5
e35c5a2 Merge tag 'armsoc-for-rc5' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig).

I am checking further with linux-samsung, coz i could see weird
behavior as mentioned
in [1] with linux-samsun/for-next merged with above git hash.

>> [0]: https://lkml.org/lkml/2014/10/30/394
>> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html




-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India

Adding a DRM slave encoder based on device_nodeJean-Francois Moine <moin...@free.fr>

[Jyri Sarha]

Hi,
I was thinking of adding a function to drm_encoder_slave.c for attaching 
the slave endcoder based on its device_node.

This would make the i2c slave encoder adding more elegant in device tree 
based environments.

My idea is to use the function in tilcdc_slave.c.

I am just wondering if someone has already done this outside mainline 
(Jean-Francois?) or if there is a pressing reason for not to add such a 
function.

Best regards,
Jyri

FIX ME in mga_dma.c

[nick]

David and the maintainers of mga_dma.c I am wondering about remove this 
function and whether I can or do I need to keep it around for other parts of 
this driver to work. In addition I will paste the function below from your 
convience.
Nick
 #if 0
FIXME: Still needed?
*/
static void mga_freelist_reset(struct drm_device *dev)
{
 struct drm_device_dma *dma = dev->dma;
 struct drm_buf *buf;
 drm_mga_buf_priv_t *buf_priv;
 int i;

for (i = 0; i < dma->buf_count; i++) {
buf = dma->buflist[i];
buf_priv = buf->dev_private;
   SET_AGE(_priv->list_entry->age, MGA_BUFFER_FREE, 0);
   }
 }
#endif

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Vivek Gautam]

Hi Javier, Kevin,



On Wed, Nov 19, 2014 at 10:22 PM, Javier Martinez Canillas
 wrote:
> [adding Paolo and Vivek as cc]
>
> Hello,
>
> On 11/18/2014 07:41 PM, Kevin Hilman wrote:
>>
>> It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
>> it proceeds to panic in the workqueue code called by the asoc max98090
>> codec[1].
>>
>> If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
>> but I still don't have display output.
>>
>
> Paolo Pisati pointed out in another thread that he needed the patch
> "[PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
> phy"
> is also needed to get display working for exynos on linux-next.
>
> I've pinged Kukjin to apply this as a -rc fix since is needed after
> a5ec598 ("phy: exynos-dp-video: Use syscon support to control pmu register")
> landed in 3.18 which broke the Exynos Display Port PHY:
>
> exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap
>
> I've an Exynos5800 Peach Pi now so I wanted to test display on it. Just 
> $subject
> and [0] should be enough to have display working on Peach Pi with linux-next 
> but
> it fails to me with:
>
> exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
> [mem 0x10040714-0x1004071f]
>
> The same issue was reported by Paolo a couple of days ago [1].
>
> Vivek,
>
> Any idea what could cause this regression on linux-next? As reported by Paolo 
> this
> works well for me in 3.18-rc5.

I tested linux-next on Exynos5800 peach-pi board with linux-next and and the two
patches $Subject and [0].

Below is my git hash:
4d9e6ee drm/exynos: Move platform drivers registration to module init
4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
36391a5 Add linux-next specific files for 20141119
9b1ced1 Merge branch 'akpm/master'
282497e mm: add strictlimit knob

With this display works for me.
Without $Subject patch i get lookup in drm.

Javier can you tell me your git hash. Was it on yesterday's linux-next ?

>
> Best regards,
> Javier
>
> [0]: https://lkml.org/lkml/2014/10/30/394
> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India

[pull] radeon drm-fixes-3.18

[Alex Deucher]

Hi Dave,

Just two small fixes for radeon.

The following changes since commit bcfef97398972de555e6e1dbf4dac33f0db38d52:

  Merge tag 'drm/tegra/for-3.18-rc5' of 
git://people.freedesktop.org/~tagr/linux into drm-fixes (2014-11-14 07:03:02 
+1000)

are available in the git repository at:


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

for you to fetch changes up to 28731d5818ae25b92d1fb82fe0ac196e97102c1b:

  drm/radeon: fix endian swapping in vbios fetch for tdp table (2014-11-20 
11:13:18 -0500)


Alex Deucher (2):
  drm/radeon: disable native backlight control on pre-r6xx asics (v2)
  drm/radeon: fix endian swapping in vbios fetch for tdp table

 drivers/gpu/drm/radeon/r600_dpm.c| 2 +-
 drivers/gpu/drm/radeon/radeon_encoders.c | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

[Bug 86432] llvm Unreal Elemental rendering regression

[bugzilla-dae...@freedesktop.org]

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

--- Comment #12 from Andy Furniss  ---
(In reply to Matt Arsenault from comment #11)
> I've posted an improved patch here:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141117/245415.
> html
> 
> This should swap the operands and still work with unordered compares

Doesn't work for me with the 2 patches from there on llvm tree from yesterday.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/e7edd061/attachment.html>

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Kevin Hilman]

Javier Martinez Canillas  writes:

> Hello,
>
> For completeness I'll comment what we talked with Kevin on IRC
> since probably this is the same issue that Paolo is facing.
>
> On 11/20/2014 05:41 PM, Kevin Hilman wrote:
>> Peach # setenv preboot "usb start; sleep 1"setenv bootargs
>> console=tty1 console=ttySAC3,115200 debug earlyprintk rw
>> root=/dev/mmcblk1p3 rootwait rootfstype=ext3
>
> My kernel command line is almost the same with the difference that I'm using
> clk_ignore_unused and I just checked that not passing that parameter, makes
> linux-next to hang showing the same output log that Kevin reported.

Ah!  Good find.  I confirm that adding clk_ignore_unused is getting me
booting again, but of course that is just masking a problem, so I hope
someone can shed light on which clock isn't being correctly managed.

Might I also suggest that folks have their default command-line to *not*
use clk_ignore_unused, since it's primary job is to workaround clock
bugs.

Kevin

[PATCH] drm/atomic: Add missing ERR_PTR casting

[Thierry Reding]

On Thu, Nov 20, 2014 at 09:53:35AM +0100, Daniel Vetter wrote:
> This is an oversight from
> 
> commit f52b69f1ecfdd7ef6867a257620258c09e569552
> Author: Daniel Vetter 
> Date:   Wed Nov 19 18:38:08 2014 +0100
> 
> drm/atomic: Don't overrun the connector array when hotplugging
> 
> Cc: Dave Airlie 
> Cc: Rob Clark 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3624632084e2..d3b46746b611 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -318,7 +318,7 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
> *state,
>*/
>   if (index >= state->num_connector) {
>   DRM_DEBUG_KMS("Hot-added connector would overflow state array, 
> restarting\n");
> - return -EAGAIN;
> + return ERR_PTR(-EAGAIN);
>   }
>  
>   if (state->connector_states[index])

=)

Reviewed-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/3cbf636d/attachment.sig>

[PATCH 1/2] drm/msm: Register irq handler for each sub-system in mdss

[Thierry Reding]

On Sun, Nov 16, 2014 at 09:18:47AM -0500, Rob Clark wrote:
> On Fri, Nov 14, 2014 at 5:42 PM, Hai Li  wrote:
> > All the sub-systems in mdss share the same irq. This change provides
> > the sub-systems with the interfaces to register/unregister their own
> > irq handlers.
> >
> > With this change, struct mdp5_kms does not have to keep the hdmi or
> > edp context.
> >
> 
> So, I think the point of this is to better deal w/ different hw
> variants which do or do-not have hdmi, edp, dsi, etc..
> 
> But, just playing devil's advocate here, it seems like it would be
> simpler to instead just do something like:
> 
> if (priv->hdmi && (intr & MDP5_HW_INTR_STATUS_INTR_HDMI))
> hdmi_irq(0, priv->hdmi);
> 
> if (priv->edp && (intr & MDP5_HW_INTR_STATUS_INTR_EDP))
> edp_irq(0, priv->edp);
> 
> ... etc ...
> 
> It is a little less elegant.  But it is also less lines of code.  I
> guess there will be plenty of necessary complexity as we add support
> for all mdp5 features.  So avoiding some unnecessary complexity might
> be a good thing in the long run.
> 
> If we really did want to make it more dynamic, we could always extend
> 'struct mdp_irq' to take both an irq mask and an initiator id, I
> suppose.  I'm not sure if that is overkill.  AFAICT we really only
> have 5 different subsystems to dispatch to (mdp5 itself, and
> dsi0/dsi1/hdmi/edp), so simply adding some if-not-null checks in
> mdp5_irq() seems pretty reasonable to me.

To me this just seems like a regular interrupt multiplexer, so
implementing it as an irq_chip would be the most appropriate. That way
you get all the goodness of a well-tested code base for free and you can
simply pass in the request_{threaded_,}irq()'s dev parameter.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/31163462/attachment.sig>

[PATCH] drm/gem: Warn on illegal use of the dumb buffer interface v2

[Thomas Hellstrom]

It happens on occasion that developers of generic user-space applications
abuse the dumb buffer API to get hold of drm buffers that they can both
mmap() and use for GPU acceleration, using the assumptions that dumb buffers
and buffers available for GPU are
a) The same type and can be aribtrarily type-casted.
b) fully coherent.

This patch makes the most widely used drivers warn nicely when that happens,
the next step will be to fail.

v2: Move drmP.h changes to drm_gem.h. Fix Radeon dumb mmap breakage.

Signed-off-by: Thomas Hellstrom 
Acked-by: Daniel Vetter 
Acked-by: Alex Deucher 
---
Although I don't think this patch should break anything, it's only
compile-tested.
---
 drivers/gpu/drm/i915/i915_drv.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h|  5 +++--
 drivers/gpu/drm/i915/i915_gem.c| 28 +++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  3 +++
 drivers/gpu/drm/nouveau/nouveau_display.c  |  9 +
 drivers/gpu/drm/nouveau/nouveau_gem.c  |  3 +++
 drivers/gpu/drm/radeon/radeon_gem.c| 26 ++
 drivers/gpu/drm/radeon/radeon_object.c |  3 +++
 include/drm/drm_gem.h  |  7 +++
 9 files changed, 74 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2404b2b..c743908 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1593,7 +1593,7 @@ static struct drm_driver driver = {
.gem_prime_import = i915_gem_prime_import,

.dumb_create = i915_gem_dumb_create,
-   .dumb_map_offset = i915_gem_mmap_gtt,
+   .dumb_map_offset = i915_gem_dumb_map_offset,
.dumb_destroy = drm_gem_dumb_destroy,
.ioctls = i915_ioctls,
.fops = _driver_fops,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f830596..4ba1aca 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2523,8 +2523,9 @@ void i915_vma_move_to_active(struct i915_vma *vma,
 int i915_gem_dumb_create(struct drm_file *file_priv,
 struct drm_device *dev,
 struct drm_mode_create_dumb *args);
-int i915_gem_mmap_gtt(struct drm_file *file_priv, struct drm_device *dev,
- uint32_t handle, uint64_t *offset);
+int i915_gem_dumb_map_offset(struct drm_file *file_priv,
+struct drm_device *dev, uint32_t handle,
+uint64_t *offset);
 /**
  * Returns true if seq1 is later than seq2.
  */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3e0cabe..50b8422 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -346,6 +346,7 @@ static int
 i915_gem_create(struct drm_file *file,
struct drm_device *dev,
uint64_t size,
+   bool dumb,
uint32_t *handle_p)
 {
struct drm_i915_gem_object *obj;
@@ -361,6 +362,7 @@ i915_gem_create(struct drm_file *file,
if (obj == NULL)
return -ENOMEM;

+   obj->base.dumb = dumb;
ret = drm_gem_handle_create(file, >base, );
/* drop reference from allocate - handle holds it now */
drm_gem_object_unreference_unlocked(>base);
@@ -380,7 +382,7 @@ i915_gem_dumb_create(struct drm_file *file,
args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 64);
args->size = args->pitch * args->height;
return i915_gem_create(file, dev,
-  args->size, >handle);
+  args->size, true, >handle);
 }

 /**
@@ -393,7 +395,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_i915_gem_create *args = data;

return i915_gem_create(file, dev,
-  args->size, >handle);
+  args->size, false, >handle);
 }

 static inline int
@@ -1773,10 +1775,10 @@ static void i915_gem_object_free_mmap_offset(struct 
drm_i915_gem_object *obj)
drm_gem_free_mmap_offset(>base);
 }

-int
+static int
 i915_gem_mmap_gtt(struct drm_file *file,
  struct drm_device *dev,
- uint32_t handle,
+ uint32_t handle, bool dumb,
  uint64_t *offset)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1793,6 +1795,13 @@ i915_gem_mmap_gtt(struct drm_file *file,
goto unlock;
}

+   /*
+* We don't allow dumb mmaps on objects created using another
+* interface.
+*/
+   WARN_ONCE(dumb && !(obj->base.dumb || obj->base.import_attach),
+ "Illegal dumb map of accelerated buffer.\n");
+
if (obj->base.size > dev_priv->gtt.mappable_end) {
ret = -E2BIG;
goto out;
@@ -1817,6 +1826,15 @@ unlock:
return ret;
 }

+int

3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Maarten Lankhorst]

Op 20-11-14 om 05:06 schreef Michael Marineau:
> On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst
>  wrote:
>> Hey,
>>
>> On 19-11-14 07:43, Michael Marineau wrote:
>>> On 3.18-rc kernel's I have been intermittently experiencing GPU
>>> lockups shortly after startup, accompanied with one or both of the
>>> following errors:
>>>
>>> nouveau E[   PFIFO][:01:00.0] read fault at 0x000734a000 [PTE]
>>> from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown]
>>> nouveau E[ DRM] GPU lockup - switching to software fbcon
>>>
>>> I was able to trace the issue with bisect to commit
>>> 809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared
>>> fences for readable objects". The lockups appear to have cleared up
>>> since reverting that and a few related followup commits:
>>>
>>> 809e9447: "drm/nouveau: use shared fences for readable objects"
>>> 055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1"
>>> e3be4c23: "drm/nouveau: specify if interruptible wait is desired in
>>> nouveau_fence_sync"
>>> 15a996bb: "drm/nouveau: assign fence_chan->name correctly"
>> Weird. I'm not sure yet what causes it.
>>
>> http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisect=86be4f216bbb9ea3339843a5658d4c21162c7ee2
> Building a kernel from that commit gives me an entirely new behavior:
> X hangs for at least 10-20 seconds at a time with brief moments of
> responsiveness before hanging again while gitk on the kernel repo
> loads. Otherwise the system is responsive. The head of that
> fixed-fences-for-bisect branch (1c6aafb5) which is the "use shared
> fences for readable objects" commit I originally bisected to does
> feature the complete lockups I was seeing before.
Ok for the sake of argument lets just assume they're separate bugs, and we 
should look at xorg
hanging first.

Is there anything in the dmesg when the hanging happens?

And it's probably 15 seconds, if it's called through nouveau_fence_wait.

Try changing else if (!ret) to else if (WARN_ON(!ret)) in that function, and 
see if you get some dmesg spam. :)


>> On the EDITED patch from fixed-fences-for-bisect, can you do the following:
>>
>> In nouveau/nv84_fence.c function nv84_fence_context_new, remove
>>
>> fctx->base.sequence = nv84_fence_read(chan);
>>
>> and add back
>>
>> nouveau_bo_wr32(priv->bo, chan->chid * 16/4, 0x);
> Making your suggested change on top of each 86be4f21 and 1c6aafb5 made
> no noticeable difference in either of the two behaviors.
>
>> If that fails you should compile your kernel with trace events, to get some 
>> debugging info from the fences. I'll post debugging info if this does not 
>> fix it.
> Happy to gather whatever debug log or tracing data you need :)
>

[PATCH] drm/atomic: Add missing ERR_PTR casting

[Daniel Vetter]

This is an oversight from

commit f52b69f1ecfdd7ef6867a257620258c09e569552
Author: Daniel Vetter 
Date:   Wed Nov 19 18:38:08 2014 +0100

drm/atomic: Don't overrun the connector array when hotplugging

Cc: Dave Airlie 
Cc: Rob Clark 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3624632084e2..d3b46746b611 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -318,7 +318,7 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
*state,
 */
if (index >= state->num_connector) {
DRM_DEBUG_KMS("Hot-added connector would overflow state array, 
restarting\n");
-   return -EAGAIN;
+   return ERR_PTR(-EAGAIN);
}

if (state->connector_states[index])
-- 
2.1.1

[PATCH 3/6] drm/atomic: Don't overrun the connector array when hotplugging

[Thierry Reding]

On Wed, Nov 19, 2014 at 06:38:08PM +0100, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
[...]
> @@ -304,6 +306,21 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
> *state,
>  
>   index = drm_connector_index(connector);
>  
> + /*
> +  * Construction of atomic state updates can race with a connector
> +  * hot-add which might overflow. In this case flip the table and just
> +  * restart the entire ioctl - no one is fast enough to livelock a cpu
> +  * with physical hotplug events anyway.
> +  *
> +  * Note that we only grab the indexes once we have the right lock to
> +  * prevent hotplug/unplugging of connectors. So removal is no problem,
> +  * at most the array is a bit too large.
> +  */
> + if (index >= state->num_connector) {
> + DRM_DEBUG_KMS("Hot-added connector would overflow state array, 
> restarting\n");
> + return -EAGAIN;

This function returns a pointer, so this needs to be ERR_PTR(-EAGAIN).

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/89b61ef0/attachment-0001.sig>

[PATCH v14 3/3] dt-bindings: video: Add documentation for rockchip vop

[Mark Yao]

This adds binding documentation for Rockchip SoC VOP driver.

Signed-off-by: Mark Yao 
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem

Changes in v3: None

Changes in v4: None

Changes in v5: None

Changes in v6: None

Changes in v7: None

Changes in v8: None

Changes in v9: None

Changes in v10: None

Changes in v11: None

Changes in v12: None

Changes in v13: None

Changes in v14: None

 .../devicetree/bindings/video/rockchip-vop.txt |   58 
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-vop.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-vop.txt 
b/Documentation/devicetree/bindings/video/rockchip-vop.txt
new file mode 100644
index 000..d15351f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-vop.txt
@@ -0,0 +1,58 @@
+device-tree bindings for rockchip soc display controller (vop)
+
+VOP (Visual Output Processor) is the Display Controller for the Rockchip
+series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3288-vop";
+
+- interrupts: should contain a list of all VOP IP block interrupts in the
+order: VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+
+- clock-names: Must contain
+   aclk_vop: for ddr buffer transfer.
+   hclk_vop: for ahb bus to R/W the phy regs.
+   dclk_vop: pixel clock.
+
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - axi
+  - ahb
+  - dclk
+
+- iommus: required a iommu node
+
+- port: A port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+SoC specific DT entry:
+   vopb: vopb at ff93 {
+   compatible = "rockchip,rk3288-vop";
+   reg = <0xff93 0x19c>;
+   interrupts = ;
+   clocks = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
+   clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = < SRST_LCDC1_AXI>, < SRST_LCDC1_AHB>, < 
SRST_LCDC1_DCLK>;
+   reset-names = "axi", "ahb", "dclk";
+   iommus = <_mmu>;
+   vopb_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   vopb_out_edp: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint=<_in_vopb>;
+   };
+   vopb_out_hdmi: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint=<_in_vopb>;
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH 1/2] drm/msm: Register irq handler for each sub-system in mdss

[Rob Clark]

On Thu, Nov 20, 2014 at 3:57 AM, Thierry Reding
 wrote:
> On Sun, Nov 16, 2014 at 09:18:47AM -0500, Rob Clark wrote:
>> On Fri, Nov 14, 2014 at 5:42 PM, Hai Li  wrote:
>> > All the sub-systems in mdss share the same irq. This change provides
>> > the sub-systems with the interfaces to register/unregister their own
>> > irq handlers.
>> >
>> > With this change, struct mdp5_kms does not have to keep the hdmi or
>> > edp context.
>> >
>>
>> So, I think the point of this is to better deal w/ different hw
>> variants which do or do-not have hdmi, edp, dsi, etc..
>>
>> But, just playing devil's advocate here, it seems like it would be
>> simpler to instead just do something like:
>>
>> if (priv->hdmi && (intr & MDP5_HW_INTR_STATUS_INTR_HDMI))
>> hdmi_irq(0, priv->hdmi);
>>
>> if (priv->edp && (intr & MDP5_HW_INTR_STATUS_INTR_EDP))
>> edp_irq(0, priv->edp);
>>
>> ... etc ...
>>
>> It is a little less elegant.  But it is also less lines of code.  I
>> guess there will be plenty of necessary complexity as we add support
>> for all mdp5 features.  So avoiding some unnecessary complexity might
>> be a good thing in the long run.
>>
>> If we really did want to make it more dynamic, we could always extend
>> 'struct mdp_irq' to take both an irq mask and an initiator id, I
>> suppose.  I'm not sure if that is overkill.  AFAICT we really only
>> have 5 different subsystems to dispatch to (mdp5 itself, and
>> dsi0/dsi1/hdmi/edp), so simply adding some if-not-null checks in
>> mdp5_irq() seems pretty reasonable to me.
>
> To me this just seems like a regular interrupt multiplexer, so
> implementing it as an irq_chip would be the most appropriate. That way
> you get all the goodness of a well-tested code base for free and you can
> simply pass in the request_{threaded_,}irq()'s dev parameter.

yup, that is what I did here:

http://cgit.freedesktop.org/~robclark/linux/commit/?h=msm-next=d9a7093329225ae29bae370823af13290b133a7e

there is a bit of awkwardness related to threaded handlers..  for now
I don't need threaded handlers so the solution was to not use them

> Thierry

[PATCH v14 2/3] dt-bindings: video: Add for rockchip display subsytem

[Mark Yao]

This add a display subsystem comprise the all display interface nodes.

Signed-off-by: Mark Yao 
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
  the graphics subsystem.

Changes in v3: None

Changes in v4: None

Changes in v5: None

Changes in v6: None

Changes in v7: None

Changes in v8: None

Changes in v9: None

Changes in v10: None

Changes in v11: None

Changes in v12: None

Changes in v13: None

Changes in v14: None

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-drm.txt 
b/Documentation/devicetree/bindings/video/rockchip-drm.txt
new file mode 100644
index 000..7fff582
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-drm.txt
@@ -0,0 +1,19 @@
+Rockchip DRM master device
+
+
+The Rockchip DRM master device is a virtual device needed to list all
+vop devices or other display interface nodes that comprise the
+graphics subsystem.
+
+Required properties:
+- compatible: Should be "rockchip,display-subsystem"
+- ports: Should contain a list of phandles pointing to display interface port
+  of vop devices. vop definitions as defined in
+  Documentation/devicetree/bindings/video/rockchip-vop.txt
+
+example:
+
+display-subsystem {
+   compatible = "rockchip,display-subsystem";
+   ports = <_out>, <_out>;
+};
-- 
1.7.9.5

[PATCH v14 1/3] drm: rockchip: Add basic drm driver

[Mark Yao]

This patch adds the basic structure of a DRM Driver for Rockchip Socs.

Signed-off-by: Mark Yao 
Signed-off-by: Daniel Kurtz 
Acked-by: Daniel Vetter 
Reviewed-by: Rob Clark 
---
Changes in v2:
- use the component framework to defer main drm driver probe
  until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
  master device and each vop device can shared the drm dma mapping.
- use drm_crtc_init_with_planes and drm_universal_plane_init.
- remove unnecessary middle layers.
- add cursor set, move funcs to rockchip drm crtc.
- use vop reset at first init
- reference framebuffer when used and unreference when swap out vop

Changes in v3:
- change "crtc->fb" to "crtc->primary-fb"
Adviced by Daniel Vetter
- init cursor plane with universal api, remove unnecessary cursor set,move 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

Changes in v6:
- set gem buffer pitch 64 bytes align, needed by mali gpu.
Adviced by Daniel Kurtz
- fix some mistake, bugs, remove unused define, more better code style etc. 
- use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable()
  at runtime instead of clk_prepare_enable().
- provide a help function from vop for encoder to do mode config, instead of
  using drm_diaplay_mode private method.
- change vop mode_set timing to make it more safely. 

Changes in v7:
- fix memory leakage problem

Changes in v8:
- fix iommu crash when use dual crtc.
- use frame start interrupt for vsync instead of line flag interrupt,
because the win config take affect at frame start time, if we use ling flag
interrupt, the address check often failed.
Adviced by Daniel Kurtz
- fix some bugs, mistake, remove unused function
- keep clock and vop disabled when probe end
- use drm_plane_helper_check_update to check update_plane if vaild

Changes in v9:
- fix suspend and resume bug, make iommu attach and detach safely.

Changes in v10:
Adviced by Andrzej Hajda
- check drm_dev if it's NULL at PM suspend/resume
Adviced by Sean Paul
- use drm_fb_helper_prepare to init fb_helper funcs
- Optimized code structure and remove some unnecessary variables.

Changes in v11:
- fix mistake that use wrong variable at rockchip sys_resume/sys_suspend.

Changes in v12:
- fix compile problem with drm-next
Adviced by Daniel Kurtz
- Optimization framebuffer reference/unreference
- Optimization Code structure
- fix pm suspend/resume problem
- fix vblank irq can't close problem

Changes in v13:
- fix vop compile warning.
Adviced by Daniel Vetter
- directly call rockchip_drm_load before register instead of
call ->load at the middle of drm register.

Changes in v14:
- revert v13 directly call rockchip_drm_load at bind, connector,
  crtc _init should before dev-node kms object lookup idr and
  conector sysfs need below minor node register, I don't like 
  split the connector init and register, so just call ->load at
  the midile of drm register.

 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/rockchip/Kconfig  |   17 +
 drivers/gpu/drm/rockchip/Makefile |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  483 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  200 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  210 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   21 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  294 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1459 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  201 
 14 files changed, 3033 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/Kconfig
 create mode 100644 drivers/gpu/drm/rockchip/Makefile
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
 create mode 100644 

[PATCH v14 0/3] Add drm driver for Rockchip Socs

[Mark Yao]

This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices. Future patches will add additional encoders/connectors,
such as eDP, HDMI.

The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two similar
Vop devices. Vop devices support iommu mapping, we use dma-mapping API with
ARM_DMA_USE_IOMMU.

Changes in v2:
- add DRM master device node to list all display nodes that comprise
  the graphics subsystem.
- use the component framework to defer main drm driver probe
  until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
  master device and each vop device can shared the drm dma mapping.
- use drm_crtc_init_with_planes and drm_universal_plane_init.
- remove unnecessary middle layers.
- add cursor set, move funcs to rockchip drm crtc.
- add vop reset.

Changes in v3:
- change "crtc->fb" to "crtc->primary-fb"
Adviced by Daniel Vetter
- init cursor plane with universal api, remove unnecessary cursor set,move 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

Changes in v6:
- set gem buffer pitch 64 bytes align, needed by mali gpu.
Adviced by Daniel Kurtz
- fix some mistake, bugs, remove unused define, more better code style etc. 
- use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable()
  at runtime instead of clk_prepare_enable().
- provide a help function from vop for encoder to do mode config, instead of
  using drm_diaplay_mode private method.
- change vop mode_set timing to make it more safely. 

Changes in v7:
- fix memory leakage problem.

Changes in v8:
- fix iommu crash when use dual crtc.
- use frame start interrupt for vsync instead of line flag interrupt,
  because the win config take affect at frame start time, if we use
  ling flag interrupt, the address check often failed.
Adviced by Daniel Kurtz
- fix some bugs, mistake, remove unused function
- keep clock and vop disabled when probe end
- use drm_plane_helper_check_update to check update_plane if vaild

Changes in v9:
- fix suspend and resume bug, make iommu attach and detach safely.
- fix mail info style.

Changes in v10:
Adviced by Andrzej Hajda
- check drm_dev if it's NULL at PM suspend/resume
Adviced by Sean Paul
- use drm_fb_helper_prepare to init fb_helper funcs
- Optimized code structure and remove some unnecessary Variables.

Changes in v11:
- fix mistake that use wrong variable at rockchip sys_resume/sys_suspend

Changes in v12:
- fix compile problem with drm-next
- Optimization framebuffer reference/unreference
- Optimization Code structure
- fix pm suspend/resume problem
- fix vblank irq can't close problem

Changes in v13:
- fix vop compile warning.
Adviced by Daniel Vetter
- directly call rockchip_drm_load before register instead of
  call ->load at the middle of drm register.

Changes in v14:
- revert v13 directly call rockchip_drm_load at bind, connector,
  crtc _init should before dev-node kms object lookup idr and
  conector sysfs need below minor node register, I don't like 
  split the connector init and register, so just call ->load at
  the midile of drm register.

Mark yao (3):
  drm: rockchip: Add basic drm driver
  dt-bindings: video: Add for rockchip display subsytem
  dt-bindings: video: Add documentation for rockchip vop

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +
 .../devicetree/bindings/video/rockchip-vop.txt |   58 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/rockchip/Kconfig   |   17 +
 drivers/gpu/drm/rockchip/Makefile  |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  483 +++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  200 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  210 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   21 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  294 
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1459 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  201 +++
 16 files changed, 3110 insertions(+)

-- 
1.7.9.5

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Javier Martinez Canillas]

Hello Vivek,

On 11/20/2014 08:51 AM, Vivek Gautam wrote:
>>
>> I tested linux-next on Exynos5800 peach-pi board with linux-next and and the 
>> two
>> patches $Subject and [0].
>>
>> Below is my git hash:
>> 4d9e6ee drm/exynos: Move platform drivers registration to module init
>> 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
>> phy
>> 36391a5 Add linux-next specific files for 20141119
>> 9b1ced1 Merge branch 'akpm/master'
>> 282497e mm: add strictlimit knob
> 
> used exynos_defconfig
>

Same here.

>>
>> With this display works for me.
>> Without $Subject patch i get lookup in drm.
>>

I tested with today linux-next (next-20141120) and display is indeed
working for me. So it seems that whatever caused the error in the
phy-exynos-mipi-video driver reported by Paolo, got fixed recently.

My working git hash is:

65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
a9b43cb drm/exynos: Move platform drivers registration to module init
5b83d7a Add linux-next specific files for 20141120
1172916 mm: add strictlimit knob

I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel
did not boot due the issue reported previously by Kevin.

>> Javier can you tell me your git hash. Was it on yesterday's linux-next ?
> 

In fact, my branch where I could reproduce the phy-exynos-mipi-video issue
was not based on yesterday's next but next-20141117. The git hash is:

9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
f740096 drm/exynos: Move platform drivers registration to module init
efefb5c Add linux-next specific files for 20141117
8c944d7 mm: add strictlimit knob

> With 3.18-rc5 i could see display on Exynos5800 peach-pi with
> following git hash:
> 
> b6dca11 drm/exynos: dp: Remove support for unused dptx-phy
> 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support
> d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> fc14f9c Linux 3.18-rc5
> e35c5a2 Merge tag 'armsoc-for-rc5' of
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
> 
> I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig).
> 

Yes, that works because the commit that caused the Exynos DRM lockup was:

43c0767 ("of/platform: Move platform devices under /sys/devices/platform")

which landed in next-20141105.

Reverting 43c0767 and only applying [0] should have the same effect.

> I am checking further with linux-samsung, coz i could see weird
> behavior as mentioned
> in [1] with linux-samsun/for-next merged with above git hash.
>

Great, it should be good to know what caused:

exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
[mem 0x10040714-0x1004071f]

even when I could not reproduce it anymore with today's linux-next.

>>> [0]: https://lkml.org/lkml/2014/10/30/394
>>> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html

Best regards,
Javier

3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Maarten Lankhorst]

Op 20-11-14 om 00:08 schreef Tobias Klausmann:
> On 19.11.2014 09:10, Maarten Lankhorst wrote:
>> ...
>> On the EDITED patch from fixed-fences-for-bisect, can you do the following:
>>
>> In nouveau/nv84_fence.c function nv84_fence_context_new, remove
>>
>> fctx->base.sequence = nv84_fence_read(chan);
>>
>> and add back
>>
>> nouveau_bo_wr32(priv->bo, chan->chid * 16/4, 0x);
>>
>> ...
>
> Added the above on top of your "fixed-fences-for-bisect" branch and guessed 
> it would work, but did not :/
> Anyway, as this "initializes" the fence to a known state, maybe you should 
> consider pushing that.
Hey,

There is a reason I don't set it to a known state on nv84+.

Channel 2 is created, fence seqno ends up being 100, other channel waits on 
seqno reaching 100.
Channel 2 is destroyed, and immediately recreated. Seqno is reset to 0.
Other channel waits for channel 2's seqno being 100.

The other channel can keep waiting indefinitely.

I guess it might be useful to reset the contents of the bo to zero on 
allocation, but it should not be done in fence_context_new.

~Maarten

[Bug 88501] AMD/ATI RS690M Console blanks to white

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #5 from business.kid at gmail.com ---

Yes, this fixes the issue on 3.18-rc4


No, it does not. I get the same behaviour - first time it blanks to dark, every
other time it blanks to white.

I am a very rusty amateur at C, but I will adjust that patch very slightly here
and have another go.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

How to fill out a Mode for a Panel Fitter

[Rian Quinn]

Working on getting cloning to work on a laptop, and realized that laptop
panel's only provides a single resolution. At least with Intel, these
usually have a panel fitter that allows you to set the CRTC to any
resolution, and the panel fitter scales for you.

We also figured out that you can use DRM_MODE_SCALE_FULLSCREEN
with drmModeConnectorSetProperty and the "scaling mode" property to tell
the panel fitter how you want it to scale.

The problem that I have is, how exactly should we fill in the modeInfo
structure. Right now, we have gotten it to work on all of our test
equipment (two laptops) by just taking the preferred mode, and changing
it's vdisplay and hdisplay to the resolution that we want. The rest of the
settings are left unchanged, which in my mind makes no sense.

One option that I was thinking of was to take the mode from the other
monitor that is not being scaled. Most of the settings in the modeInfo
struct should be good, except I noticed in testing that the flags field is
different between the panel and a VGA monitor (and I really have no idea
what the flags field should be set to).

I also noticed that there is a DRM_MODE_TYPE_USERDEF type, and it would
make sense to me that the type should be changed to this since I am
defining it in software, but I'm not sure if it is actually used.

At any rate, do any of you have any insight on the proper way to fill out
this modeInfo struct when using the panel fitter and a user defined mode?

Thanks a ton,
- Rian
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/c3ff2a63/attachment.html>

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Kevin Hilman]

Hi Vivek,

Vivek Gautam  writes:

[...]

> I tested linux-next on Exynos5800 peach-pi board with linux-next and and the 
> two
> patches $Subject and [0].
>
> Below is my git hash:
> 4d9e6ee drm/exynos: Move platform drivers registration to module init
> 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
> phy
> 36391a5 Add linux-next specific files for 20141119
> 9b1ced1 Merge branch 'akpm/master'
> 282497e mm: add strictlimit knob
>
> With this display works for me.
> Without $Subject patch i get lookup in drm.

The current linux-next (next-20141120) is still not fully booting for
me.  I do see the penguins come up on the display, but it doesn't finish
booting.   Full boot log below.

I'm building using exynos_defconfig with CONFIG_SND_SOC_SNOW=n due to
other errors previously reported.  (Vivek, BTW, I'm curious how your peach-pi
is booting with the audio support enabled.)

Here's how I'm creating the tree, which appears to be the same as what
you guys are doing, but just to be thorough:

$ git reset --hard next/master
HEAD is now at 5b83d7ad9106 Add linux-next specific files for 20141120

$ pwclient git-am 5197701
Applying patch #5197701 using 'git am'
Description: [v2,2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for 
dp phy
Applying: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

$ pwclient git-am 5328881
Applying patch #5328881 using 'git am'
Description: [RFC,1/1] drm/exynos: Move platform drivers registration to module 
init
Applying: drm/exynos: Move platform drivers registration to module init

$ git log --oneline -n5
b16800da58a3 drm/exynos: Move platform drivers registration to module init
87541edf8a17 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
5b83d7ad9106 Add linux-next specific files for 20141120
fd7e97b09f45 Merge branch 'akpm/master'
11729160b2d7 mm: add strictlimit knob

Kevin


[1] 
Connected to chromebook2 console [channel connected] (~$quit to exit)
(user:khilman) is already connected


# PYBOOT: console: connected.
~$hardreset

Command(chromebook2 console)> hardreset
(user:khilman) Reboot chromebook2
Reboot: chromebook2 ; phidget 4 2 :  ('off', 1, 'on')


U-Boot 2013.04-gb98ed09 (Apr 30 2014 - 16:57:31) for Peach

CPU:Exynos5422 at 1800MHz

Board: Google Peach Pi, rev 13.6
I2C:   ready
DRAM:  3.5 GiB
PMIC max77802-pmic initialized
CPU:Exynos5422 at 1800MHz
TPS65090 PMIC EC init
MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
In:cros-ec-keyb
Out:   serial
Err:   lcd
SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
ELOG: Event(17) added with size 13
Net:   No ethernet found.
Hit any key to stop autoboot:  2 

# PYBOOT: u-boot: taking control.
 0 
Exynos DP init done
Peach # 
Peach setenv stdout serial
# setenv stdout serialversion

Peach # versionsetenv preboot "usb start; sleep 1"


U-Boot 2013.04-gb98ed09 (Apr 30 2014 - 16:57:31) for Peach
armv7a-cros-linux-gnueabi-gcc.real (4.7.2_cos_gg_c8f69e0) 4.7.x-google 20130114 
(prerelease)
GNU ld (binutils-2.22_cos_gg_2) 2.22
Peach # setenv preboot "usb start; sleep 1"setenv bootargs console=tty1 
console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait 
rootfstype=ext3

Peach # setenv bootargs console=tty1 console=ttySAC3,115200 debug earlyprintk 
rw root=/dev/mmcblk1p3 rootwait rootfstype=ext3if test -n ${initenv}; then run 
initenv; fi

Peach # if test -n ${initenv}; then run initenv; fiif test -n ${preboot}; then 
run preboot; fi

Peach # if test -n ${preboot}; then run preboot; fisetenv autoload no; setenv 
autoboot no

(Re)start USB...
USB0:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
   scanning usb for ethernet devices... 1 Ethernet Device(s) found
Peach # dhcp
dhcp
Waiting for Ethernet connection... done.
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.1.110
Peach # setenv serverip 192.168.1.2
setenv serverip 192.168.1.2
Peach # if test -n ${netargs}; then run netargs; fi
if test -n ${netargs}; then run netargs; fi
Peach # tftp 0x4100 192.168.1.2:tmp/chromebook2-3T8ptb/uImage-48m8WK
tftp 0x4100 192.168.1.2:tmp/chromebook2-3T8ptb/uImage-48m8WK
Using asx0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.110
Filename 'tmp/chromebook2-3T8ptb/uImage-48m8WK'.
Load address: 0x4100
Loading: *#
 #
 #
 ##
 1.2 MiB/s
done
Bytes transferred = 3473930 (35020a hex)
Peach # 

[PATCH 1/1] DRM-vmwgfx: Deletion of an unnecessary check before the function call "vfree"

[Thierry Reding]

On November 19, 2014 5:57:13 PM SF Markus Elfring 
 wrote:
> From: Markus Elfring 
> Date: Wed, 19 Nov 2014 17:50:19 +0100
>
> The vfree() function performes also input parameter validation. Thus the test
> around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 14b2f50..f9a67b8 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -889,8 +889,7 @@ static int vmw_driver_unload(struct drm_device *dev)
>
>   if (dev_priv->ctx.res_ht_initialized)
>   drm_ht_remove(_priv->ctx.res_ht);
> - if (dev_priv->ctx.cmd_bounce)
> - vfree(dev_priv->ctx.cmd_bounce);
> + vfree(dev_priv->ctx.cmd_bounce);
>   if (dev_priv->enable_fb) {
>   vmw_fb_close(dev_priv);
>   vmw_kms_restore_vga(dev_priv);

Reviewed-by: Thierry Reding 

[PATCH 1/1] DRM-UDL: Deletion of an unnecessary check before the function call "vunmap"

[Thierry Reding]

On November 19, 2014 5:42:26 PM SF Markus Elfring 
 wrote:
> From: Markus Elfring 
> Date: Wed, 19 Nov 2014 17:33:32 +0100
>
> The vunmap() function performes also input parameter validation. Thus the test
> around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/udl/udl_gem.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
> index 8044f5f..2979625 100644
> --- a/drivers/gpu/drm/udl/udl_gem.c
> +++ b/drivers/gpu/drm/udl/udl_gem.c
> @@ -164,8 +164,7 @@ void udl_gem_vunmap(struct udl_gem_object *obj)
>   return;
>   }
>
> - if (obj->vmapping)
> - vunmap(obj->vmapping);
> + vunmap(obj->vmapping);
>
>   udl_gem_put_pages(obj);
>  }

Reviewed-by: Thierry Reding 

[PATCH 1/1] DRM-tilcdc: Deletion of an unnecessary check before the function call "drm_fbdev_cma_hotplug_event"

[Thierry Reding]

On November 19, 2014 5:28:59 PM SF Markus Elfring 
 wrote:
> From: Markus Elfring 
> Date: Wed, 19 Nov 2014 17:05:20 +0100
>
> The drm_fbdev_cma_hotplug_event() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 000428e..335b1dc 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -58,8 +58,7 @@ static struct drm_framebuffer *tilcdc_fb_create(struct 
> drm_device *dev,
>  static void tilcdc_fb_output_poll_changed(struct drm_device *dev)
>  {
>   struct tilcdc_drm_private *priv = dev->dev_private;
> - if (priv->fbdev)
> - drm_fbdev_cma_hotplug_event(priv->fbdev);
> + drm_fbdev_cma_hotplug_event(priv->fbdev);
>  }
>
>  static const struct drm_mode_config_funcs mode_config_funcs = {

Reviewed-by: Thierry Reding 

[PATCH 1/1] DRM-EDID: Deletion of an unnecessary check before the function call "release_firmware"

[Thierry Reding]

On Nov 19, 2014 4:41 PM, "SF Markus Elfring" 
wrote:
>
> From: Markus Elfring 
> Date: Wed, 19 Nov 2014 16:33:17 +0100
>
> The release_firmware() function tests whether its argument is NULL and
then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/drm_edid_load.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid_load.c
b/drivers/gpu/drm/drm_edid_load.c
> index 0a235fe..732cb6f 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -254,8 +254,7 @@ static void *edid_load(struct drm_connector
*connector, const char *name,
> name, connector_name);
>
>  out:
> -   if (fw)
> -   release_firmware(fw);
> +   release_firmware(fw);
> return edid;
>  }
>

Reviewed-by: Thierry Reding 
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/a928aba2/attachment.html>

[PATCH 3/3] drm/edid: Tighten checksum conditions for CEA blocks

[Stefan Brüns]

Checksumming was disabled for CEA blocks by

commit 4a638b4e38234233f5c7e6705662fbc0b58d80c2
Author: Adam Jackson 
Date:   Tue May 25 16:33:09 2010 -0400

drm/edid: Allow non-fatal checksum errors in CEA blocks

If only the checksum is wrong, reading twice should result in identical
data, whereas a bad transfer will most likely corrupt different bytes.
Comparing checksums is not sufficient, as there is a considerable chance
of two bad transfers having the same checksum.

Signed-off-by: Stefan Brüns 
---
 drivers/gpu/drm/drm_edid.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3a10f3f..55963d5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1203,6 +1203,7 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)
 {
int i, j = 0, valid_extensions = 0;
u8 *block, *new;
+   u8 *saved_block = NULL;
bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & 
DRM_UT_KMS);

if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
@@ -1233,12 +1234,27 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)

for (j = 1; j <= block[0x7e]; j++) {
u8 *ext_block = block + (valid_extensions + 1) * EDID_LENGTH;
+   u8 csum, last_csum = 0;
for (i = 0; i < 4; i++) {
if (drm_do_probe_ddc_edid(adapter, ext_block, j, 
EDID_LENGTH))
goto out;
-   if (drm_edid_block_valid(ext_block, j, print_bad_edid)) 
{
+   csum = drm_edid_block_csum(ext_block);
+   if (!csum) {
valid_extensions++;
break;
+   } else if (ext_block[0] == CEA_EXT) {
+   /*
+* Some switches mangle CEA contents without fixing the 
checksum.
+* Accept CEA blocks when two reads return identical 
data.
+*/
+   if (saved_block && csum == last_csum &&
+   !memcmp(ext_block, saved_block, 
EDID_LENGTH)) {
+   valid_extensions++;
+   break;
+   }
+   kfree(saved_block);
+   saved_block = kmemdup(ext_block, EDID_LENGTH, 
GFP_KERNEL);
+   last_csum = csum;
}
}

@@ -1249,6 +1265,9 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)

connector->bad_edid_counter++;
}
+
+   kfree(saved_block);
+   saved_block = NULL;
}

if (valid_extensions != block[0x7e]) {
@@ -1270,6 +1289,7 @@ carp:
connector->bad_edid_counter++;

 out:
+   kfree(saved_block);
kfree(block);
return NULL;
 }
-- 
2.1.2

[PATCH 2/3] drm/edid: calculate address of current extension block only once

[Stefan Brüns]

Signed-off-by: Stefan Brüns 
---
 drivers/gpu/drm/drm_edid.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b072041..3a10f3f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1232,12 +1232,11 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)
block = new;

for (j = 1; j <= block[0x7e]; j++) {
+   u8 *ext_block = block + (valid_extensions + 1) * EDID_LENGTH;
for (i = 0; i < 4; i++) {
-   if (drm_do_probe_ddc_edid(adapter,
- block + (valid_extensions + 1) * EDID_LENGTH,
- j, EDID_LENGTH))
+   if (drm_do_probe_ddc_edid(adapter, ext_block, j, 
EDID_LENGTH))
goto out;
-   if (drm_edid_block_valid(block + (valid_extensions + 1) 
* EDID_LENGTH, j, print_bad_edid)) {
+   if (drm_edid_block_valid(ext_block, j, print_bad_edid)) 
{
valid_extensions++;
break;
}
-- 
2.1.2

[PATCH 1/3] drm/edid: new drm_edid_block_checksum helper function

[Stefan Brüns]

The function will also be used by a later patch, so factor it out.

Signed-off-by: Stefan Brüns 
---
 drivers/gpu/drm/drm_edid.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ec4f91f..b072041 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1048,8 +1048,7 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid)
}
}

-   for (i = 0; i < EDID_LENGTH; i++)
-   csum += raw_edid[i];
+   csum = drm_edid_block_checksum(raw_edid);
if (csum) {
if (print_bad_edid) {
DRM_ERROR("EDID checksum is invalid, remainder is 
%d\n", csum);
@@ -1188,6 +1187,17 @@ static bool drm_edid_is_zero(u8 *in_edid, int length)
return true;
 }

+static u8
+drm_edid_block_checksum(u8 *raw_edid)
+{
+   int i;
+   u8 csum = 0;
+   for (i = 0; i < EDID_LENGTH; i++)
+   csum += raw_edid[i];
+
+   return csum;
+}
+
 static u8 *
 drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
 {
-- 
2.1.2

[PATCH] drm/edid: shorten log output in case of all zeroes edid block

[Stefan Brüns]

There is no need to dump the whole EDID block in case it contains no
information. Just print a single line stating the block is empty instead
of 8 lines containing only zeroes.

Signed-off-by: Stefan Brüns 
---
 drivers/gpu/drm/drm_edid.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3bf9991..ec4f91f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1080,9 +1080,13 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid)

 bad:
if (print_bad_edid) {
-   printk(KERN_ERR "Raw EDID:\n");
-   print_hex_dump(KERN_ERR, " \t", DUMP_PREFIX_NONE, 16, 1,
+   if (drm_edid_is_zero(raw_edid, EDID_LENGTH)) {
+   printk(KERN_ERR "EDID block is all zeroes\n");
+   } else {
+   printk(KERN_ERR "Raw EDID:\n");
+   print_hex_dump(KERN_ERR, " \t", DUMP_PREFIX_NONE, 16, 1,
   raw_edid, EDID_LENGTH, false);
+   }
}
return false;
 }
-- 
2.1.2

[Bug 85376] Dolphin emulator has bad colors

[bugzilla-dae...@freedesktop.org]

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

Matthew Woehlke  changed:

   What|Removed |Added

 CC||mw_triad at users.sourceforge.
   ||net

--- Comment #15 from Matthew Woehlke  ---
Not sure if this is fixed or not, but I was able to isolate the GLSL where
things go sideways.

This is broken:

prev.rgb = (prev.rgb * (256 - ifog) + cfogcolor.rgb * ifog) >> 8;

The above apparently should have the same effect as the following, which works
correctly:

prev.r = (prev.r * (256 - ifog) + cfogcolor.r * ifog) >> 8;
prev.g = (prev.g * (256 - ifog) + cfogcolor.g * ifog) >> 8;
prev.b = (prev.b * (256 - ifog) + cfogcolor.b * ifog) >> 8;

So something is going sideways distributing the above operations across vector
components. Seems reasonable to suspect code generation.

I tried splitting just the bitshift step with no effect, so my guess is that at
least multiplying an int3 by an int is doing something wrong.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/325769e8/attachment-0001.html>

[Bug 86471] Unreal Engine 4.6 Editor dont start

[bugzilla-dae...@freedesktop.org]

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

Michel Dänzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #1 from Michel Dänzer  ---
(In reply to Thomas Kowaliczek from comment #0)
> Assertion failed: !((UPTRINT)Ptr & (PageSize-1))
> [File:Runtime/Core/Public/HAL/MallocBinned.h] [Line: 625] 
> 
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x77bcf0c9 in raise () from /usr/lib/libpthread.so.0
> (gdb) bt
> #0  0x77bcf0c9 in raise () from /usr/lib/libpthread.so.0
> #1  0x770a9bbd in DebugBreak () at
> Runtime/Core/Public/Linux/LinuxPlatformMisc.h:32
> #2  StaticFailDebug (Error=0x7ffe8790 L"Assertion failed: !((UPTRINT)Ptr
> & (PageSize-1))", File=0x7754aaac
> "Runtime/Core/Public/HAL/MallocBinned.h", Line=625,
> Description=0x7ffe97b0 L"", bIsEnsure=false)
> at
> /home/linuxdonald/UnrealEngine/Engine/Source/Runtime/Core/Private/Misc/
> OutputDevice.cpp:190
> #3  0x7706a19b in FDebug::AssertFailed (Expr=0x7754ac0c
> "!((UPTRINT)Ptr & (PageSize-1))", File=0x7754aaac
> "Runtime/Core/Public/HAL/MallocBinned.h", Line=625, Format=0x775700e4
> L"")
> at
> /home/linuxdonald/UnrealEngine/Engine/Source/Runtime/Core/Private/Misc/
> OutputDevice.cpp:223
> #4  0x76e560c0 in FMallocBinned::FreeInternal (this=0x77f03010,
> Ptr=0x8a55010) at Runtime/Core/Public/HAL/MallocBinned.h:625

Looks like an assertion failure in Unreal Engine code. Not obviously directly
related to the driver.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/78e80678/attachment.html>

[Bug 85696] r600g+nine: Bioshock shader failure after 7b1c0cbc90d456384b0950ad21faa3c61a6b43ff

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from Ilia Mirkin  ---
(In reply to David Heidelberg (okias) from comment #4)
> It's bug in Nine.
> 
> Instead of one available ADDR[0], we try use DCL ADDR[0..1].
> 
> ADDR[0] is allocated by LOOP (for counter purposes) and then later is
> allocated ADDR[1].
> 
> 0 is the address register (already allocated by LOOP, but in this case
> unused)
> 1 is UBO index register (misused by location for MOVA (coverted)-> ARR)
> 2 is sampler index register (not used, correctly).

While the opengl state tracker uses ADDR in this way, it is not in any way
required by TGSI or gallium that this be the case. ADDR registers can be used
however you want, they're just registers like any other, except that they can
be used for indirect indexing into TEMP and CONST registers (perhaps IN and OUT
as well, not sure), and with ARB_gs5, into SAMP as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/1d4ba617/attachment.html>

[Bug 85696] r600g+nine: Bioshock shader failure after 7b1c0cbc90d456384b0950ad21faa3c61a6b43ff

[bugzilla-dae...@freedesktop.org]

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

David Heidelberg (okias)  changed:

   What|Removed |Added

   Keywords|bisected, regression|
Summary|[regression] r600g+nine:|r600g+nine: Bioshock shader
   |Bioshock shader failure |failure after
   |after   |7b1c0cbc90d456384b0950ad21f
   |7b1c0cbc90d456384b0950ad21f |aa3c61a6b43ff
   |aa3c61a6b43ff   |

--- Comment #4 from David Heidelberg (okias)  ---
It's bug in Nine.

Instead of one available ADDR[0], we try use DCL ADDR[0..1].

ADDR[0] is allocated by LOOP (for counter purposes) and then later is allocated
ADDR[1].

0 is the address register (already allocated by LOOP, but in this case unused)
1 is UBO index register (misused by location for MOVA (coverted)-> ARR)
2 is sampler index register (not used, correctly).

Axel had idea we could do something like:

. if wants to use rL to index constant register
. . if a0 is used somewhere in the shader
. . then copy the content to temp. load rL to a0. do the op. restore a0
. . else copy rL to a0 and use it
. else do nothing particular

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/9881d46b/attachment-0001.html>

[Bug 88481] Kernel oops leaves system without graphical output [radeon]

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #9 from Christopher Frömmel  ---
Thanks to everyone involved. Report and fix within 20 hours. Awesome!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 86432] llvm Unreal Elemental rendering regression

[bugzilla-dae...@freedesktop.org]

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

--- Comment #11 from Matt Arsenault  ---
I've posted an improved patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141117/245415.html

This should swap the operands and still work with unordered compares

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/2a7a23f8/attachment.html>

3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Tobias Klausmann]

On 19.11.2014 09:10, Maarten Lankhorst wrote:
> ...
> On the EDITED patch from fixed-fences-for-bisect, can you do the following:
>
> In nouveau/nv84_fence.c function nv84_fence_context_new, remove
>
> fctx->base.sequence = nv84_fence_read(chan);
>
> and add back
>
> nouveau_bo_wr32(priv->bo, chan->chid * 16/4, 0x);
>
> ...

Added the above on top of your "fixed-fences-for-bisect" branch and 
guessed it would work, but did not :/
Anyway, as this "initializes" the fence to a known state, maybe you 
should consider pushing that.

Going to compile the kernel with trace events (lets see how) ...

Tobias